Комментарии 25
Решал похожую задачу через mkvmerge. Система обрабатывала загруженный файл на сервере. Командная строка для вызова была вида:
После обработки файл без проблем открывался как в vlc, так и через opencv.
/usr/bin/mkvmerge -o video.mp4 source_video.raw
После обработки файл без проблем открывался как в vlc, так и через opencv.
Автор вообще в курсе существования ffmpeg?
Для решения конкретной задачи конвертации кроме него вообще ничего не нужно.
Ну или статью надо было называть «Автор изучил формат хранения видео и решил написать об этом. При этом популярные контейнеры (mp4, mkv) автор не осилил.»
Для решения конкретной задачи конвертации кроме него вообще ничего не нужно.
Ну или статью надо было называть «Автор изучил формат хранения видео и решил написать об этом. При этом популярные контейнеры (mp4, mkv) автор не осилил.»
Не мешайте изобретателям лисапедов.
Тьфу на вас ffmpegшников! Gstreamer!
Для записи не спорю, а вот интересно, как бы ffmpeg помог автору в случае чтения. По описанию битового потока, там явно проприетарный формат контейнера собранный на коленках.
ffmpeg умный. Он ну очень много форматов и контейнеров знает. И он очень хорошо демуксеры подбирает для любого говна.
Я не встречал файлов которые он не сумел бы распознать и перепаковать в нормальный контейнер.
Я не встречал файлов которые он не сумел бы распознать и перепаковать в нормальный контейнер.
У меня завалялось «любое говно» тоже с видеорегистратора, внутри которого вроде бы H.264, и ffmpeg его не осиливает, вываливая тонну ошибок. Воспроизвести его осиливает только плеер, идущий в комплекте с видеорегистратором. (Поделиться файлом не могу, там секретики)
Если даже это принять на веру. В конце концов все в жизни бывает. Тогда надо понять почему он не понимает этот формат и сделать препроцессор который превратит файлик во что-то понимаемое ffmpeg. Или в крайнем случае сделать свой демуксер. Это не так сложно.
Это избавит от проблем создания муксера и добавит поддержку любых выходных форматов. Ну и велосипед заметно уменьшится в размерах.
А вообще не надо связывать с железками которые пишут видео в собственный проприетарный формат. Просто не надо.
Это избавит от проблем создания муксера и добавит поддержку любых выходных форматов. Ну и велосипед заметно уменьшится в размерах.
А вообще не надо связывать с железками которые пишут видео в собственный проприетарный формат. Просто не надо.
сделать препроцессор который превратит файлик во что-то понимаемое ffmpeg
Вроде бы об этом и пост?)
А вообще не надо связывать с железками которые пишут видео в собственный проприетарный формат. Просто не надо.
На практике нередко бывает, что выбора по каким-то причинам просто не было
Нет. Статья о полном велосипеде. От начала и до конца и демуксим и муксим сами.
Значит задача плохо поставлена. Железка стоила ~10к рублей. Реверсинжиниринг + написание кода + тесты + ловля багов которые в таком будут точно выйдет больше месяца трудозатрат. Оно того не стоит. Дешевле железки обновить.
Значит задача плохо поставлена. Железка стоила ~10к рублей. Реверсинжиниринг + написание кода + тесты + ловля багов которые в таком будут точно выйдет больше месяца трудозатрат. Оно того не стоит. Дешевле железки обновить.
К сожалению там нет никакой «магии», поверьте. Так получилось, что из-за текущих проектов мне приходится очень плотно сидеть в исходниках ffmpeg. На самом деле, форматов там очень даже счетное количество, множество из которых старые, никому не нужные, богом забытые экзотические форматы всяких редакторов, консолей, приставок и т.д. Все его «распознавание» — это вызов функции Probe() для каждого муксера для тестового набора данных и поиск заранее известных сигнатур. У меня с легкостью получалось записывать контейнеры ffmpeg-ом которые он же не мог прочитать и наоборот. Редкие или кастомные форматы он не в состоянии читать.
Магии нет. Есть очень хороший анализатор форматов и контейнеров. Простой ну и тем лучше. Важно что работает хорошо. Поддержка древних и забытый форматов это то что и надо автору статьи. Какой-то левый формат. Есть большой шанс что он как раз и будет одним из тех старых экзотических форматов.
Анализатор у ffmpeg не плохой, но он не распарсит формат которого он не знает. Как вы оцениваете шанс, что любой придуманный вами из головы формат случайно совпадет с одним из известных (примерно сотня) ffmpeg-у форматом? То, что иногда ffmpeg удается считать незнакомый ему файл это не его заслуга, а разработчиков MPEG 1,2,4. Дело в том, что поток MPEG запросто может обходится без контейнера, так как он сам им и является, по сути и он приспособлен для передачи по ненадежным каналам связи. Это приводит к тому, что незнакомый файл воспринимается как «битый» MPEG-поток в котором ffmpeg, без проблем находит хорошо подобранные стандартные сигнатуры.
Я адекватно оцениваю шанс на наличие стандартного формата в железке. Пусть экзотического, но стандартного. Разработчикам железок самим же дешевле взять стандартный формат и не делать велосипед. Ну максимум заголовок могут свой дописать. Смысл контейнер свой делать?
Не будет там стандартного формата, т.к. просто не существует формата, который одновременно:
1. Поддерживал бы возможность дозаписи
2. Поддерживал бы при этом растущий индекс
3. Был бы при этом надежным (транзакционным) в случае зависания или сбоя
Это я вам говорю с уверенностью, т.к. уже второй раз за сою карьеру разрабатываю систему записи видео-потоков 24/7, в которой приходится использовать свой проприетарный способ хранения из-за того, что стандартного просто не существует в природе. Если вы подскажет мне стандартный формат который бы отвечал всем трем требованиям одновременно, то я был бы вам очень благодарен.
1. Поддерживал бы возможность дозаписи
2. Поддерживал бы при этом растущий индекс
3. Был бы при этом надежным (транзакционным) в случае зависания или сбоя
Это я вам говорю с уверенностью, т.к. уже второй раз за сою карьеру разрабатываю систему записи видео-потоков 24/7, в которой приходится использовать свой проприетарный способ хранения из-за того, что стандартного просто не существует в природе. Если вы подскажет мне стандартный формат который бы отвечал всем трем требованиям одновременно, то я был бы вам очень благодарен.
fmp4 ну или m2ts чем не устраивают? Недописанный конец фрагмента это не страшно. Даже сам фрагмент будет читаемым.
m2ts сразу отпадает в случае если скорость носителя или сети слишком медленная ( <= 100Mb) для бинарного поиска по пакетам по большим файлам, т.к. нет поддержки индекса.
fmp4- используется в MPEG DASH, но сильно стандартным вне Web я бы его не стал называть. Ffmpeg, относительно, недавно научился правильно его записывать. Не проигрывается очень многими сплитерами. Для настоящей транзакционности его не достаточно, т.к. необходим еще один файл который бы описывал бы сами фрагменты.
На само деле MPEG DASH — наиболее близкий к желаемому стандарт, но и он, к сожалению, слишком комплексный и сложный, имеет кучу проблем и косяков если его использовать в режиме отличном от Read-Only.
fmp4- используется в MPEG DASH, но сильно стандартным вне Web я бы его не стал называть. Ffmpeg, относительно, недавно научился правильно его записывать. Не проигрывается очень многими сплитерами. Для настоящей транзакционности его не достаточно, т.к. необходим еще один файл который бы описывал бы сами фрагменты.
На само деле MPEG DASH — наиболее близкий к желаемому стандарт, но и он, к сожалению, слишком комплексный и сложный, имеет кучу проблем и косяков если его использовать в режиме отличном от Read-Only.
m2ts можно резать на кусочки и обеспечивать индекс любыми внешними средствами. hls вполне справляется и проще некуда.
Так я и предложил новый модный формат и добрый старый. Выбирать по вкусу. Один проверен временем и поддерживается всем, второй новый больше возможностей внутри, но с поддержкой пока не очень.
А то что они для веба оба, так с чем работаю что знаю то и предлагаю.
Так я и предложил новый модный формат и добрый старый. Выбирать по вкусу. Один проверен временем и поддерживается всем, второй новый больше возможностей внутри, но с поддержкой пока не очень.
А то что они для веба оба, так с чем работаю что знаю то и предлагаю.
m2ts можно резать на кусочки и обеспечивать индекс любыми внешними средствами. hls вполне справляется и проще некуда.Можно много чего делать, но это уже не будет являться стандартным решением, которые мы тут обсуждаем. Как вы собираетесь резать открытые GOP-ы? А если источником вы не управляете?
HLS, при всем уважении к нему, не является стандартным форматом обмена видео, а является одним из многих протоколов стриминга в сети.
Так я и предложил новый модный формат и добрый старый. Выбирать по вкусу. Один проверен временем и поддерживается всем, второй новый больше возможностей внутри, но с поддержкой пока не очень.Fragmented MPEG-4 далеко не новый формат, просто от из-за своей кривизны не использовался нигде, пока разработчики MPEG-DASH не обратили на него внимание. Все эти Web-протоколы (MPEG-DASH, HLS, Smooth Streaming) не создавались для удобства решения тех задач которые мы обсуждаем. Они создавались для обхода проблемы лицензирования для разных браузеров.
А то что они для веба оба, так с чем работаю что знаю то и предлагаю.
Еще раз, стандартного контейнера (именно контейнера) для видео — простого, поддерживающего легкую дозапись, поддерживающего растущий индекс, и обеспечивающего надежность в случае сбоев — не существует. Именно в таких случаях всегда приходится изобретать «велосипед», хоть и используя отдельные стандартные «блоки».
У вас философские вопросы в основном. Понятно что с ключевыми кадрами 1 раз на часовое видео ничего резать не выйдет. Я когда такое видео увидел был в шоке.
Зато HLS проще некуда и задачу навигации RO клиента за медленным каналом выполняет на ура.
Если быть совсем честным, то задачу писать на диск ролики с видеорегистратора решает обычный mp4. Сам регистратор режет ролики на заранее настроенные промежутки и обзывает по времени. Все задачи решаются полностью. Совместимо со всем. Дуракоустойчиво. Никаких велосипедов. Найти нужный отрезок или склеить что можно типовыми средствами абсолютно примитивно.
Зато HLS проще некуда и задачу навигации RO клиента за медленным каналом выполняет на ура.
Если быть совсем честным, то задачу писать на диск ролики с видеорегистратора решает обычный mp4. Сам регистратор режет ролики на заранее настроенные промежутки и обзывает по времени. Все задачи решаются полностью. Совместимо со всем. Дуракоустойчиво. Никаких велосипедов. Найти нужный отрезок или склеить что можно типовыми средствами абсолютно примитивно.
У вас философские вопросы в основном.Ну я вообще-то овечаю вам на ваше же утвержение:
Разработчикам железок самим же дешевле взять стандартный формат и не делать велосипед. Ну максимум заголовок могут свой дописать. Смысл контейнер свой делать?Не понимая какие задачи и проблемы решали разработчики нельзя ничего точно утверждать.
Понятно что с ключевыми кадрами 1 раз на часовое видео ничего резать не выйдет.И с нормальными ключевыми кадрами (раз в секунду) может ничего не выйти. Вы же не знаете какой у них там H.264 поток. Может быть там встроенный чип, который генерирует поток с B-кадрами и открытыми GOP-ами, где есть ссылки на предыдущие кадры. Как в этом случае вы будете разбивать фалы на куски?
А если отрезок по какой-то причине окажется не дописан? Вышеупомянутый ffmpeg читать урезанные mp4-файлы лично у меня тоже упорно отказывается, например
Технически статья интересная. Практический вывод — не покупать регистратор QCM-08DL, т.к. он пишет файлы в неподдерживаемом виде.
Самое забавное — что производитель регистратора тоже это понимает, раз предлагает программу конвертации в комплекте.
Ну у них не очень богатый выбор был:
Всякие: AVI, MPEG4 и MOV отпадают, так как в случае потери питания данные превратятся в тыкву.
Из стандартных остаются TS или сырой H264. C ними проблема в том, что нет заголовков, где-бы отражалась информация о длительности и индексах. Возможно, без этого, напрямую с флешь-памяти проблематично переходить на произвольную позицию в случае перемотки. Пришлось изобретать «велосипед».
Всякие: AVI, MPEG4 и MOV отпадают, так как в случае потери питания данные превратятся в тыкву.
Из стандартных остаются TS или сырой H264. C ними проблема в том, что нет заголовков, где-бы отражалась информация о длительности и индексах. Возможно, без этого, напрямую с флешь-памяти проблематично переходить на произвольную позицию в случае перемотки. Пришлось изобретать «велосипед».
Большинство людей утверждают что автор поста просто не знаком с ffmpeg, но я подтверждаю что ffmpeg не всегда способен распознать структуру файла, например я работал с тем, чтобы с IP камер Bovotech (ActiveCam и прочих ему) преобразовать структуру файлов, которые он записывает на флешку и заверяю что ffmpeg не справлялся с этой задачей, в итоге я разобрался с тем чтобы распарсить файл на аудио+видео и затем уже через ffmpeg накладывал дорожки и сделал это кстати даже лучше, чем приложение от вендора камер, которое смещало аудио и не всегда корректно воспроизводило файл если fps на камере при записи было скажем 10 кадров в секунду.
P.S на регистраторе первыми байтами идут характеристики файла, длительность и все прочее, включая параметр по которому видео записывалось, либо по детекции, либо постоянная запись, либо там еще много всяких приблуд и т.д. И если этот регистратор связан с облаком xm, то на него есть SDK, в котором можно скачивать файл в avi формате вместе с дорожкой звука, либо можно на китайских форумах нарыть документацию(она точно есть)
P.S на регистраторе первыми байтами идут характеристики файла, длительность и все прочее, включая параметр по которому видео записывалось, либо по детекции, либо постоянная запись, либо там еще много всяких приблуд и т.д. И если этот регистратор связан с облаком xm, то на него есть SDK, в котором можно скачивать файл в avi формате вместе с дорожкой звука, либо можно на китайских форумах нарыть документацию(она точно есть)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка конвертера видео из 264 в avi для видеорегистратора QCM-08DL