Расшифровка имен видеофайлов

Серийный номер. Отсортировал бы по дате - увидел бы что эти числа тоже всегда растут.

Действительно, похоже на серию. И даже можно догадываться, зачем она нужна.
А как так быстро догадался? :=) Имел дело с DVR?

Не имел. Имел дело в созданием гарантированно уникальных имен файлов.

Ок, спасибо! :=)

Вторая необычность видеофайлов подстерегла, когда понадобилось скопировать множество этих файлов на десктоп.

DVR и сам умеет это делать, но ну ооооочень медленно, буквально часами, поскольку его процессор на уровне Intel 386, да и по размеру чипов где-то такой же.

Поэтому решил ускорить это дело - извлек из DVR жесткий диск и воткнул его в док-станцию.
Каково же было мое удивление, когда на диске не оказалось ни одного видеофайла!

А вместо них увидел множество одинаковых по размеру файлов каждый ровно по размеру 256 MB.
Видать, DVR пишет видео в каком-то своем удивительном смешанном формате, поэтому и превращение его в AVI-файлы идет крайне медленно.

Отсюда возникает вполне естественной вопрос - существует ли утилита, которая раскодирует эти непонятные файлы в AVI-файлы?

Конечно, если можно, желательно под Linux :=)

Понимаю, вопрос не из стандартных. Хорошо, тогда вот попроще :=)

Это регистратор сваливает все AVI-файлы в одну кучу, за исключением каталогов, в которые они раскладывает - /CH01, /CH02 и т.д.

Поделитесь, плиз, бешевским скриптиком, который дополнительно раскладывал бы эти файлы еще и в создаваемые каталоги, соответствующие их датам.

К примеру, CH02_20231124163049-163131_0-28-14.avi --> в /2023/11/24/ и т.д.

Отсюда возникает вполне естественной вопрос - существует ли утилита, которая раскодирует эти непонятные файлы в AVI-файлы?

Чтобы ответить на этот вопрос, нужно больше данных. Тип ФС, где эти загадочные файлы лежат; структура каталогов; что говорит о файлах утилита file; что говорит о них mediainfo.

Инструкцию бы тебе, барин, покурить. Ну, или букавки на корпусе, чуда та заморскага, пачитать бы.

ЗЫЖ из треда в тред одно и тоже у ТС-а - контекст задачи не определен, масштаб ужат так, что ничего не разглядеть. Но пляшит(-еш:) задорно.

Чтобы ответить на этот вопрос, нужно больше данных.

Думал, что вы уже на более простой вопрос отвечаете, по скриптику, поэтому сразу даже не понял, какие нужно данные.
А вы оказывается, по уже загадочным файлам и ФС спрашиваете?
Ну, это завсегда пожалуйста :=), щас подготовлю запрашиваемые данные.

Инструкцию бы тебе, барин, покурить... контекст задачи не определен

Дык я предварительно спросил, если шанс расковырять этот загадочный формат, а уточнения уже по ходу дела.
А какую, кстати, инструкцию - на DVR? Так она давно зачитана до дыр, из полезного только то, что софт этой железки основан на Linux.

А вчерась набрел на подобный разбор полетов, и аж за голову схватился....

Не знаю что был за регистратор, но однажды разбирал дамп с жесткого диска – там наоборот все потоки с камер были влеплены в один файл и с интервалом в 4 секунды менялись. Т.е. открываешь файл - проигрывается 4 сек съекмки с первой камеры, 4 сек со второй и т.п.

Обычным ффмпегом нарезалось без проблем.

Тут наоборот может разрезаны как, хрен знает.

что говорит о файлах утилита file; что говорит о них mediainfo.

Что говорит о них утилита binwalk

Раз барин сказал в инструкции нет того «как формируются имена видеофайлов», значит нет. И модель DVR называть негоже, кто ж в словах барина сомневаться удумает?! Лучше уж поплавть в размытом контексте, так больше неожиданных поворотов всплывет. Кстати, инструкция на англицком, аль по китайской грамоте?

Что говорит о них утилита rm.

И модель DVR называть негоже

Мудель уже указывал в - предыдущей теме, которая увы, закочилась фиаско, а в этой забыл указать, сорри.
Терпение, господа, терпение,все еще готовлю данные для вас :=)

Вот первые съемки с натуры -

- http://share.bashtel.ru/files/655067
- http://share.bashtel.ru/files/655068

Как видите, структура файлов сплошь линейная, никаких каталогов.
Всего на 1 ТБ диске помещается 3725 одинаковых по размеру файлов по 256 Mib / 268435456 байт каждый с одинаковыми датами модификации от балды - 2098-12-14 07:08:12.

Не исключено, что они образуются все сразу после процедуры, которая в DVR называется «Форматирование», а потом уже наполняются по мере видеозаписи, но это лишь предположение.

Upd.
Некоторые их этих файлов Thunar распознает как text/x-matlab, другие как text/x-microdvd, text/x-mpl2 и т.д.
Возможно, он ошибается и присваивает им что попало.


Продолжение следует...

Продолжение:

Утилита file классифицирует эти файлы просто - data
Консольная утилита mediainfo никак не классифицирует эти файлы.
Но ее GUI-версия изобразила такое: http://share.bashtel.ru/files/655072

И наконец, что говорит об этих файлах утилита binwalk:

binwalk  0001

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
9198790       0x8C5CC6        MySQL ISAM index file Version 3
30890081      0x1D75861       MySQL ISAM index file Version 3
67676269      0x408A86D       Uncompressed Adobe Flash SWF file, Version 56, File size (header included) 54591348
78955353      0x4B4C359       XAR archive, version: 10504, header size: 22720, TOC compressed: 976817428873910169, TOC uncompressed: 469089780392157073
83406479      0x4F8AE8F       Intel x86 or x64 microcode, sig 0x00190090, pf_mask 0x9000119, 1919-11-09, rev 0x9000000, size 151060489
88344419      0x5440763       Intel x86 or x64 microcode, sig 0x19009000, pf_mask 0x00, 1900-10-09, size 160501785
89708428      0x558D78C       Intel x86 or x64 microcode, sig 0x91199000, pf_mask 0x1190000, 1990-10-19, rev 0x1919100, size 6409
89760815      0x559A42F       Intel x86 or x64 microcode, pf_mask 0x19090, 1910-19-19, rev 0x9009100, size 4096
90416673      0x563A621       Intel x86 or x64 microcode, sig 0x10900109, pf_mask 0x1000000, 1909-10-19, size 151032064
90802246      0x5698846       Intel x86 or x64 microcode, sig 0x90100900, pf_mask 0x32001000, 1900-10-19, rev 0x-6ffe6f6f, size 2673664
91474172      0x573C8FC       MySQL MISAM index file Version 10
91479834      0x573DF1A       Intel x86 or x64 microcode, sig 0x00009190, pf_mask 0x9000, 1991-01-19, rev 0x-6ffee6e7, size 2048
141999039     0x876BBBF       COBALT boot rom data (Flat boot rom or file system)
155524319     0x9451CDF       Intel x86 or x64 microcode, sig 0x00000090, pf_mask 0x9000090, 1991-19-10, rev 0x1090000, size 1085440
156119584     0x94E3220       Intel x86 or x64 microcode, sig 0x00000091, pf_mask 0x1000000, 1991-01-09, rev 0x9001, size 1638400
157024574     0x95C013E       Intel x86 or x64 microcode, sig 0x00091019, pf_mask 0x90091, 1909-09-10, rev 0x10000091, size 2048
180709068     0xAC566CC       Intel x86 or x64 microcode, sig 0x77636433, pf_mask 0xe400000c, 1990-01-10, rev 0x911009, size 16777216
183117688     0xAEA2778       Intel x86 or x64 microcode, sig 0x01099119, pf_mask 0x90910100, 1990-10-19, rev 0x910000, size 4240
188117738     0xB3672EA       MySQL ISAM compressed data file Version 7
200270778     0xBEFE3BA       Intel x86 or x64 microcode, sig 0x09100900, pf_mask 0x91911919, 1900-01-19, rev 0x9000000, size 2048
200474205     0xBF2FE5D       Intel x86 or x64 microcode, pf_mask 0x09, 1919-01-09, size 6400
201322255     0xBFFEF0F       Intel x86 or x64 microcode, sig 0x00910000, pf_mask 0x109000, 1909-10-19, rev 0x1900000, size 2048
217458096     0xCF625B0       Intel x86 or x64 microcode, sig 0x01191909, pf_mask 0x109010, 1919-10-19, rev 0x-6feff66f, size 65552
217671117     0xCF965CD       Intel x86 or x64 microcode, sig 0x09101900, pf_mask 0x100019, 1919-09-01, rev 0x-6ffeeff7, size 9474305
217910235     0xCFD0BDB       Intel x86 or x64 microcode, sig 0x01000900, pf_mask 0x910090, 1919-10-19, rev 0x19000090, size 1675280
239978319     0xE4DC74F       Intel x86 or x64 microcode, sig 0x00109001, pf_mask 0x10, 1990-10-09, rev 0x101990, size 281
240262186     0xE521C2A       Intel x86 or x64 microcode, sig 0x10090019, pf_mask 0x10, 1991-09-01, size 2048
240315000     0xE52EA78       Intel x86 or x64 microcode, sig 0x00100910, pf_mask 0x00, 1909-09-01, rev 0x9100, size 36864
240359473     0xE539831       Intel x86 or x64 microcode, sig 0x90010001, pf_mask 0x00, 1919-19-19, rev 0x9910000, size 9437184
240607930     0xE5762BA       Intel x86 or x64 microcode, sig 0x01190901, pf_mask 0xa863, 1909-09-10, rev 0x199100, size 787202
256902566     0xF5005A6       HPACK archive data
260378386     0xF850F12       MySQL ISAM index file Version 1
264568558     0xFC4FEEE       Intel x86 or x64 microcode, sig 0x00009100, pf_mask 0x10000010, 1990-10-09, rev 0x11090000, size 4240
267058615     0xFEAFDB7       Intel x86 or x64 microcode, sig 0x10090000, pf_mask 0xdf001388, 1910-10-09, rev 0x9000091, size 3075

Судя по многообразию гипотез врет, наверное :=)

Итак, господа, все ваши пожелания выполнил, жду вердикта(ов)

Ну, если уж бинволк спасовал, то я точно не разберу файл лучше)

Да, намудрили, видать, с свои проприетарным форматом.
Не понимаю,какую выгоду дает это производителям, ну да ладно.

Ладно, давайте вернемся к более простому вопросу :=)

Этот регистратор сваливает все AVI-файлы в одну кучу, за исключением каталогов, в которые они раскладывает - /CH01, /CH02 и т.д.
Поделитесь, плиз, бешевским скриптиком, который дополнительно раскладывал бы эти файлы еще и в создаваемые каталоги, соответствующие их датам.
К примеру, CH02_20231124163049-163131_0-28-14.avi --> в /2023/11/24/ и т.д.

А то очень неудобно ориентироваться в каталогах с тысячами файлов...

Как вам, например, этот скрипт, который мне прислали добрые люди, нет ли в нем ошибок?

#!/bin/bash

# Перебор всех файлов .avi в текущей директории и поддиректориях:
find . -type f -name "*.avi" | while read file; do
    # Получение даты создания файла
    date=$(stat -c %y "$file" | cut -d ' ' -f 1)
    year=$(echo $date | cut -d '-' -f 1)
    month=$(echo $date | cut -d '-' -f 2)
    day=$(echo $date | cut -d '-' -f 3)

    # Создание директории с именем год/месяц/день, если она еще не существует:
    directory="./$year/$month/$day"
    mkdir -p "$directory"

    # Перемещение файла в новую директорию:
    mv "$file" "$directory/"
done

А там (в регистраторе) разве фтп нет? Поднять фтп на отдельной машине и туда сливать.

в UNIX-подобных системах дата создания файла обычно не записывается

какие-то сказания давних времен, я сейчас и не вспомню широко используемую *nix-овую ФС, не сохраняющую creation/birth time.

тут имхо лучше дату из имени файла вытащить.

А там (в регистраторе) разве фтп нет?

Все что в нем есть, это -

PORT      STATE SERVICE
85/tcp    open  mit-ml-dev
554/tcp   open  rtsp
9000/tcp  open  cslistener
49152/tcp open  unknown

сам столкнулся со странными файлами с камеры наблюдения, мне помогла утилита Broken 264 fixer. https://mercmobily.github.io/broken264fixer/