Что такое элементы moov atom в начало файла
Я вижу тонны вопросов о перемещении атома moov из конца видеоконтейнера MP4 в начало, чтобы сделать видео "web optimized" или более легким для потоковой передачи. Похоже, что большинство инструментов требуют явной опции для этого при первом кодировании видео, если оно вообще доступно.
Если размещение атома в начале делает потоковую передачу лучше, а это дорого обходится after-the-fact, то зачем мне вообще кодировать видео с атомом в конце? В чем же выгода?
2 ответа
Я ищу способ создать атом MOOV, который позволил бы пользователю воспроизвести файл MP4, пока он все еще транскодируется (например, транскодирование бесконечного потока, такого как тот, что был снят с камеры безопасности) Я думаю, что единственный способ сделать это-иметь каждый кусок и образец.
Я разрабатываю приложение, в котором мне нужно воспроизводить прогрессивное дымящееся видео из файла mp4. Но я столкнулся с ошибкой PVMFErrContentInvalidForProgressivePlayback . Я думаю, что эти видео не удовлетворяют ни одному из этих требований - для контейнеров 3GPP и MPEG-4 атом moov должен.
Кодирование MOOV в конце файла обычно является операцией по умолчанию для видеокодеров, поскольку они, как правило, работают, записывая выходной файл за один проход, а точное содержимое и размер атома MOOV могут быть известны только после полной записи аудио-и видеоданных, поскольку он содержит абсолютные размеры файлов.
FFmpeg позволяет сделать второй проход и переместить атом в начало с -movflags +faststart .
Наличие атома MOOV в конце не имеет особых преимуществ, это просто не так неудобно в ситуациях локального воспроизведения, когда поиск в end-of-file перед воспроизведением не так затратен, как при прогрессивной доставке загрузки.
Вы всегда захотите поместить информацию об индексе в начало файла, для этого макета нет никаких скрытых затрат, за исключением единственного: при захвате/перекодировании вы можете заранее не знать, сколько места вам нужно для этого атома MOOV в начале, и его данные еще недостаточно доступны. Таким образом, вы обычно записываете полезную нагрузку непосредственно в файл, и они завершают запись, добавляя MOOV и обновляя rest файла.
Похожие вопросы:
У меня есть сервер, который транслирует mp4(h264). Я использую MP4Box, чтобы поместить атом moov в начало файла и чередовать по умолчанию 500 мс. Однако я заметил, что в пиковые часы, когда сервер.
Я работаю на прямую устройства для потокового сервера в android. Я могу отправлять данные в байтах на сервер, но когда я проигрываю этот файл во время записи на сервере VLC , говорю, что MOOV atom.
Я разрабатываю серверное приложение, которое хранит живой видеопоток H.264 как MP4 для последующего использования браузерами. Поскольку сервер должен будет обрабатывать как можно больше.
Я ищу способ создать атом MOOV, который позволил бы пользователю воспроизвести файл MP4, пока он все еще транскодируется (например, транскодирование бесконечного потока, такого как тот, что был снят.
Я разрабатываю приложение, в котором мне нужно воспроизводить прогрессивное дымящееся видео из файла mp4. Но я столкнулся с ошибкой PVMFErrContentInvalidForProgressivePlayback . Я думаю, что эти.
Я пытаюсь воспроизвести MP4-поток. Поток отправляется с моего телефона android. Проблема в том, что Moov atom, который необходим для воспроизведения mp4, записывается только в том случае, если.
Сейчас я записываю видео с prorecorder конфигурация. Я перекодирую видео on-the-fly в видеоконтейнер mp4 с помощью ffmpeg. Продолжительность неизвестна, так как я транскодирую .ts, который.
Я использую процессор qtfaststart и gem paperclip-ffmpeg в Rails для преобразования файла mp4 в ogg, webm или flv. Однако у меня не было никакого успеха в преобразовании файла mp4 в эти форматы для.
На данный момент я успешно сгенерировал MP4 файлов через MediaCodec, но не могу воспроизвести их в Instagram или Whatsapp после загрузки. Прямо сейчас я предполагаю, что проблема заключается в том.
Прогрессивная развертка (не чересстрочная)
Высокий профиль
2 последовательных B-кадра
Закрытая группа изображений (GOP). GOP равняется половинной частоте кадров.
CABAC (контекстно-адаптивное двоичное арифметическое кодирование)
Переменный битрейт. Ограничений для битрейта не предусмотрено. Рекомендуемые битрейты приведении ниже.
Цветовое пространство: 4.2.0
Помещайте элементы moov atom в начало файла (быстрый старт).
Я пытался найти программу которая бы закодировала бы видео по этим рекомендациям, но не нашел такой программы, чтобы все одновременно было, где есть cabac - нет 2 b фрейма и гоп итд. Затем я узнал про существование FFMPEG - по инфе интернета ютуб использует в своих серверах эту программу для сжатия поступаемого туда видео, но пока я не смог разобраться как точно выставить желаемые параметры для кодирования.
Теперь вопрос к тем, кто разбирается в FFMPEG encoder, как добиться таких настроек в этом кодере?
Свою неудачную попытку я обрисую так
Видео захваченное на 50 кадров/сек в цветовом пространстве glRGB в формате тга я конвертировал в программе вегас в формат uncompressed, добавив фильтры unsharp mask, sony levels , sony soft contrast и преобразовав в частоту кадров 30fps с помощью размытия.
Затем, покопавшись в гугле я скачал FFMPEG я закодировал видео с такими параметрами: ffmpeg -i Video.avi -pix_fmt yuv420p -c:v libx264 -qp 0 -bf 2 -g 150 -coder 1 -b:a 192k Video1.mp4 , так же я прогнал закодированное в мп4 видео через программу mp4box, которая переносит элементы moov atom в начало файла
и качество меня не устроило, возможно я не достиг нужного потому что параметры ffmpeg не настроены правильно и какая-либо опция упущена
-
Exact33139 писал(а):
Закрытая группа изображений (GOP). GOP равняется половинной частоте кадров.
-
Exact33139 писал(а):
где есть cabac
Качество его очень схоже визуально с транслируемым 720 с опцией 144, только разрешение ниже, также я могу скачать файл лучшего качества мп4 или вебм 720, качество которых на порядок выше, чем новое 720p c режимом 144,и соответствует качеству ютуба до весеннего "обновления", когда еще не было режима 144p, Это разница отчетливо видна в динамичных моментах видео с большим количеством деталей, четкие линии и контуры начинают распадаться на квадраты у флв, в отличии от мп4:
На 720 для мп4 и вебм отводился битрейт 3000 (Кб/c):
large.flv, разрешение которого является 854х480 (409920 пикселей) и битрейт 1291:
Это говорит о том, что гипотетически hd flv с разрешением 1280х720 (921600 пикселей)- качество которого меня интересует и имеет пикселей в 2.25 раз больше, имеет битрейт во столько же раз больший и эта цифра составляет 2900, что аналогично битрейту мп4 файла с качеством без 144p.
Из всего этого можно сделать вывод, что отличия старого ютуба от "нового" в качестве сжатия. Flv файл, что транслируется новым ютубом по умолчанию, вместо трансляции мп4, как это было раньше, до внедрения 144p, при аналогичном битрейте значительно проигрывает мп4 в качестве.
Поиски методов кодирования здесь бесполезны и нужно идти другим путём, а именно выяснить тонкости сжатия hd flv с битрейтом 3000Кб\c, каких оттенков или деталей избегать, чтобы картинка не сыпалась в динамичных моментах и какие фильтры накладывать.
К инструкция по расширенной настройке кодирования, которая написана до внедрения 144p, и которая ранее хорошо работала, теперь нужно добавить еще и фильтры, убирающие те или иные детали и цвета, которых боится flv, чтобы избежать развала картинки на квадраты.
Я не опытен в обработке видео, но думаю более опытные люди поделяться интересными мыслями о тонкостях этого формата и как бороться с его недостатками. blblTb [15.10.2013 12:18] :
1. А кто вам сказал, что внутри контейнера flv не мp4?
Раздражающая маслянистая неестественность "идеального", с вашей точки зрения" видео, лично меня выхихикивает.
2. Тонких ценителей лицезрения волшебных полётов маловато, особенно тех, кто вместо самого процесса игры ставит перед собой целью увидеть как смешной персонаж, плавно воспаряет над хаосом в высоком разрешении.
Я уже много раз вам пытался донести, что суть кинематографа не в бессмысленно наращивании частоты и мегапикселов. Чем плавнее ваше видео, тем меньше сопереживаешь неподдельному страданию и жертвам персонажа.
Похоже, что многие сайты, такие как YouTube, предлагают moov atom в начале файла (быстрый запуск).
ffmpeg не делает это поведением по умолчанию, но вы можете указать это с -movflags faststart . Мне интересно, есть ли недостаток всегда использовать этот параметр?
3 ответа 3
В зависимости от размера вашего ввода, может потребоваться некоторое время, чтобы выполнить второй проход, чтобы переместить атом moov в начало файла.
Без -movflags +faststart
С -movflags +faststart
Вы должны использовать +faststart вместо просто faststart , потому что он будет добавлен к любым флагам по умолчанию / другим / существующим вместо их отмены (но я никогда не проверял это).
По общему признанию, использование nullsrc было не лучшим вводом, так как он не мог создать последовательный вывод, но я был нетерпелив и хотел чего-то быстрого, но достаточно динамичного, чтобы обеспечить размер файла (но я не хотел чистого шума). Кроме того, я выполнил только один тест на команду, так что это небольшой размер выборки. Несмотря на это, разница во времени очевидна.
Я думаю, что эта тема нуждается в обновлении. На последнем ffmpeg (3.4.1) я получаю:
Те же результаты. Теперь попробуйте с реальным видео:
Как вы, возможно, уже знаете, информация, необходимая для записи атома moov или даже для определения его размера, недоступна до тех пор, пока не будет обработан весь файл.
Недостатки наличия атома moov в начале и причина, по которой многие инструменты не делают этого по умолчанию, поэтому все связаны с этим фактом.
Если ни одно из следующих действий не является для вас проблемой, то вы можете поставить Moov на передний план и не иметь никаких недостатков.
Второй проход обязателен. Это удваивает объем дискового ввода-вывода, поскольку данные должны быть считаны с ввода, записаны на диск, затем прочитаны с диска и перезаписаны. Это может быть нецелесообразно, когда скорость ввода-вывода очень низкая, например, при записи на сетевой диск.
Вывод не может быть передан другой команде / отправлен на стандартный вывод на лету, потому что эти механизмы не могут выполнить второй проход.
Прогрессивная развертка (не чересстрочная) Высокий профиль 2 последовательных B-кадра Закрытая группа изображений (GOP). GOP равняется половинной частоте кадров. CABAC (контекстно-адаптивное двоичное арифметическое кодирование) Переменный битрейт. Ограничений для битрейта не предусмотрено. Рекомендуемые битрейты приведении ниже. Цветовое пространство: 4.2.0 Помещайте элементы moov atom в начало файла (быстрый старт).
Покопавшись в гугле я скачал FFMPEG я закодировал лослесс видео 30фпс высочайшего качества, которое состоит из тга-скриншотов с такими параметрами: ffmpeg -i Video.avi -pix_fmt yuv420p -c:v libx264 -qp 0 -bf 2 -g 150 -coder 1 -b:a 192k Video1.mp4 , так же я перенёс элементы moov atom в начало файла
и качество меня не устроило, возможно я не достиг нужного потому что параметры ffmpeg не настроены правильно и какая-либо опция упущена
Хочешь в р264 лучше чем в lossless, лол? Вроде, можно добиться, чтобы видео не проходило конвертацию на их сервере, которая собственно и убивает качество.
libx264 с -qp 0 дает такой же lossless, как и huffyuv, только ролик весит меньше. Качественнее исходного video.avi оно не будет.
Крайне интересно узнать как это делается, верится с трудом что оное возможно.
Я имею ввиду как выставить правильно рекомендуемые параметры в ффмпег такие как: переменный битрейт,Закрытая группа изображений (GOP),CABAC - я поставил -coder 1, но не известно включилось ли это.
Для -qp 0 всё это не имеет значения, всё равно возьмет битрейта ровно столько, сколько нужно для кадра без потерь.
-g 15 - половина частота кадров
-profile high - высокий профиль
-flags +cgop - закрытая группа изображений
-movflags +faststart - moov atom в начало файла
-coder 1 - можно не указывать, CABAC для x264 используется по умолчанию.
На -pix_fmt yuv420p теряются мелкие детали. Других ухудшений относительно исходного материала не должно быть. Без учета хостера, который перекодирует твой материал.
Читайте также: