Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
О, хороший топик чтоб спросить: Представим, что на Земле правит мировой заговор и нас всех облучают 25 кадром.
- Не сойдут ли с ума современные кодеки от такого видео?
- На сколько увеличится средний объем файлов?
Зачем представлять, вы на улицу давно смотрели?
1. А какая кодеку разница — ставите
2. Размер можно оставить и тем же — включить доп. кадры за счёт объёма остальных. Если хочется оставить качество, внедрив дополнительные кадры, то размер получится раза в полтора больше — за счёт большого количества переходов между сценами.
1. А какая кодеку разница — ставите
-r 25 -g 24 (это для того, чтобы нужный кадр точно не потерялся)2. Размер можно оставить и тем же — включить доп. кадры за счёт объёма остальных. Если хочется оставить качество, внедрив дополнительные кадры, то размер получится раза в полтора больше — за счёт большого количества переходов между сценами.
Количество переходов конечно будет огромным, но если там не каждый 25й кадр разный, а просто 5 минут одна картинка, потом 5 минут другая и т.д. — разве GOP это не вытянет, на каждом 25м кадре говоря — отмотай и покажи 25й предыдущий кадр, а на каждом 26м — отмотай и покажи 2й предыдущий кадр вот с такими-то изменениями…? Интересно, на сколько объём увеличится.
Да, для статичного изображения можно наоборот сделать большой GOP. Как при этом поведёт себя reference finder кодека большой вопрос, кстати. Кодеки не рассчитаны на подобное применение (т.е. их поведение может быть не оптимальным), хотя, уверен, можно сделать утилиту, генерирующую синтаксически верный, оптимизированный H264 файл, размер которого (с сохранением качества) будет не на много больше исходного видео без вставок.
Вы хотите использовать ответ, как контр-аргумент для людей с параноидным или параноидальным состоянием?
А не подскажете, где почитать, каким образом кодеки обрабатывают движение? В смысле — перемешение фрагментов кадра. Судя по тому, как искажается картинка при потере ключевого кадра — оно там не пиксельное (если не ошибаюсь, вектора хранятся для блоков 8*8), но и не полностью блочное. Пытался играть с детектором оптического потока, но воспроизвести не сумел.
Рекомендую к прочтению www.technosphera.ru/lib/book/191
Навскидку не подскажу; принял комент от xLoSyAsHx с рекомендацией литературы. Если сильно нужно, напишите мне в личку — посмотрю для вас отдельно.
Есть рипы с BlueRay, MediaInfo показывает стерео канал в который свели оригинальные 6 каналов звука, и слушать это невозможно, т.к. громкость окружения выше голоса. Почему бы, делая рип, не выравнивать громкость всех каналов? Как это сделать в ffmpeg?
Смысла таких рипов очень не много. Аудио занимает мало место по сравнению с видео. В большинстве рипов как минимум DD 5.1 звук либо чаще dts hd ma
Специального фильтра для многоканального выравнивания я не знаю, однако уверен, можно придумать какой-то жуткий однострочник, используя "-filter_complex". Или написать скрипт, который разведёт каналы, проанализирует среднюю громкость с помощью "-af volumedetect", нормализует через "-af 'volume=...'" и сведёт обратно.
А рипы такие пригодятся для просмотра на, допустим, телефонах.
А рипы такие пригодятся для просмотра на, допустим, телефонах.
Хотелось бы сделать небольшие уточнения:
Если ваш источник — не стримы игр или экшн-видео, то имеет смысл ограничить верхнее значение фреймрейта 25-30 кадрами — чем их меньше, тем больше остаётся данных для описания отдельного кадра.Если говорить именно о кодеке, то значение фреймрейта ему не важно. При кодировании оно не используется, также как соотношение сторон. Важны только сам текущий кадр, его размер и, возможно, соседние кадры. Если кодек использует межкадровое кодирование, то на обычных видео чем больше фреймрейт, тем меньше разница между соседними кадрами и тем меньше будет занимать сам кадр. Так что зависимость по битрейту не такая простая. Проблемы могут возникнуть при показе видео с высоким фреймрейтом, но большинство плееров используют аппаратное ускорение и это уже не так критично.
Увеличение размера GOP повышает эффективность кодека в обмен на повышение требований к памяти.Не всегда. Это очень сильно зависит от структуры GOP-а. Если там присутствуют только P-кадры (зависящие только от предыдущих), то буфер не нужен. А вот на скорость позиционирования в потоке размер GOP влияет всегда.
широкоформатные DVD, где 16:9 видео имеет разрешение 702×576Стандартные ширина/высота DVD PAL — 720х576, DVD NTSC — 720x480, для любых пропорций.
Если говорить именно о кодеке, то значение фреймрейта ему не важно. При кодировании оно не используется, также как соотношение сторон.Именно так. Но важно знать, что битрейт делится между кадрами и, увеличивая фреймрейт, нужно пропорционально увеличивать и битрейт. Несмотря на очевидность, этот факт оказывается иногда открытием.
Не всегда. Это очень сильно зависит от структуры GOP-а.Тоже верно для частных случаев; в статье я описываю общие зависимости для некоторого объёма видео.
Стандартные ширина/высота DVD PAL — 720х576, DVD NTSC — 720x480Не совсем точно:
en.wikipedia.org/wiki/DVD-Video#Video_data
Из близких: 720×576, 704x576, 720x480, 704x480.
Упомянутого мной 702×576 в списке разрешений нет, хотя я точно помню, что обрабатывал такое. Видимо, запомнилось из-за нестандартности. Сути это, правда, не меняет и DVD — хороший пример анаморфности. В статье поменял на 704x480.
Не совсем точно:Согласен что очень все запутано с этими аналоговыми разрешениями. Вообще, в PAL — 704 аналоговые точки в строке, вы правы. Это минимально необходимое количество точек чтобы сохранить строку PAL без потерь. Сам DVD стандарт очень гибкий и, теоретически (не по стандарту), может хранить видео любого разрешение, даже менять его динамически, но спроектирован он так чтобы видео и аудио занимали фиксированное место в пересчете на время. Там используются константный битрейт, все пакуется фиксированными пакетами по 2048 байт и так далее. Поэтому для удобства, так как многие диски издавались и в стандарте PAL и в стандарте NTSC, разрешение PAL по горизонтали сделали 720, так как 720х576х25 == 720х480х30. 704х480 разрешение взялось не понятно от куда, так как NTSC всегда был 720х480 при 4:3 — квадратная точка, очень удобно для старого телека.
en.wikipedia.org/wiki/DVD-Video#Video_data
Возникли некоторые вопросы — если я кодирую с переменным битрейтом (в моём случае может помочь выиграть достаточно много — к примеру 20м ролик в 720p может занимать от 70 до 300мб), то при кодировании в один проход части кадра могут размещаться не последовательно? и для того, чтобы всё было строго последовательно нужно два прохода?
можно ли делать двухпроходное кодирование одной командой ffmpeg? (немного более организационный вопрос, но это немного бы упростило мне жизнь)
если у меня есть набор команд для обычного однопроходного кодирования достаточно ли просто добавить -pass 1/2 и поменять выходной файл? или есть ограничения на какие-то параметры?
есть ли какие-то ограничения на двухпроходное кодирование?
можно ли делать двухпроходное кодирование одной командой ffmpeg? (немного более организационный вопрос, но это немного бы упростило мне жизнь)
если у меня есть набор команд для обычного однопроходного кодирования достаточно ли просто добавить -pass 1/2 и поменять выходной файл? или есть ограничения на какие-то параметры?
есть ли какие-то ограничения на двухпроходное кодирование?
От кодера и количества проходов порядок блоков не зависит, только от формата контейнера. Но, насколько мне известно, блоки видео в файле размещаются последовательно во всех популярных контейнерах. Если есть какие-то странности с кешированием, попробуйте сменить, например, mp4 на mkv с сохранением кодеков, может помочь разобраться.
Одной строкой два прохода сделать, думаю, нельзя, однако написание .sh или .bat файла для этой задачи тривиально (почти псевдокод);
Также необходимо учитывать, что при кодировании файлов с несколькими видеопотоками оба прохода придётся делать для каждого потока отдельно, потребуется более сложный скрипт.
Одной строкой два прохода сделать, думаю, нельзя, однако написание .sh или .bat файла для этой задачи тривиально (почти псевдокод);
ffmpeg -i $1 -pass 1 -passlogfile $1.logfile $2
ffmpeg -i $1 -pass 2 -passlogfile $1.logfile $2
rm $1.logfileТакже необходимо учитывать, что при кодировании файлов с несколькими видеопотоками оба прохода придётся делать для каждого потока отдельно, потребуется более сложный скрипт.
Писал коммент на телефоне, дописался до нечаянного клика по ссылке…
Задела меня опция -slice, до этого о ней не слышал. Начал копать, оказалось не всё так просто, а информации мало:
Для h264/x264 есть slice, а есть frame-based кодирование и последнее новее.
Slice режет один кадр на части и кодирует их отдельно (нет, это не «solid» архивы. Именно, что кадры будут делиться на равные части, и по сути, кодирование частей происходить «асинхронно»). Поэтому: для frame («threaded») нужен буфер кадров, чтобы отдать каждому потоку по кадру. Больше потоков — больше задержка на выходе. У sliced обрабатывается кадр за кадром, задержка меньше, но:
И всё таки, у sliced можно лучше распараллелить декодирование. И судя по комментарию в [1], это также помогает при аппаратном ускорении, для Blu-ray должно быть 4 slices. Если оно так, то это должно помочь при декодировании Hi10P, которое у меня ни на старом, ни на новом телефонах (Samsung Galaxy S2 (2c), Asus Zenfone 2 ZE551ML (4c)) без тормозов не проигровалось. Надо тестировать!
Удалось разгадать путаницу из первого вопроса-источника:
При замере, с -tune zerolatency, кодирование кадра получилось дольше (по-умолчанию sliced для zerolatency), чем с threaded (frame-based). Объяснение просто: да, параллелизм sliced хуже, поэтому время кодирования больше. Но если распараллелить на frame-based, то время кодировки каждого отдельного кадра будет ниже, зато буфер и отсюда задержка будут намного выше.
Или начать декодировать первый кадр всеми силами или же ждать заполнения буфера, чтобы можно было заполнить потоки — разница есть.
Итого:
slices не нужны для обычного проигрывания видео (за искл. быстрого декодирования). Они просто хуже. Для стриминга в реальном времени — самое оно, но желательно ограничивать столькими потоками, сколько минимально надо для обеспечения кодирования (иначе — накладные расходы). Для трансляций с секундными буферами можно принудительно выключать slices, таким образом лучше загружать процессор и улучшить сжатие.
Много написал, фух, вроде не ошибся. Может написать статью, с тестами и обязательной КПДВ?
Источники:
[1] stackoverflow.com/questions/33624016/why-sliced-thread-affect-so-much-on-realtime-encoding-using-ffmpeg-x264
[2] Ссылка на док из [1], обязательно к прочтению
[3] stackoverflow.com/questions/20963042/encoding-for-fastest-decoding-with-ffmpeg
Задела меня опция -slice, до этого о ней не слышал. Начал копать, оказалось не всё так просто, а информации мало:
Для h264/x264 есть slice, а есть frame-based кодирование и последнее новее.
Slice режет один кадр на части и кодирует их отдельно (нет, это не «solid» архивы. Именно, что кадры будут делиться на равные части, и по сути, кодирование частей происходить «асинхронно»). Поэтому: для frame («threaded») нужен буфер кадров, чтобы отдать каждому потоку по кадру. Больше потоков — больше задержка на выходе. У sliced обрабатывается кадр за кадром, задержка меньше, но:
- Распараллеливание у frame лучше, а у sliced намного хуже. Есть части кодировщика последовательные, которые и будут тормозить процесс.
- Sliced также значительно уступает в сжатии, а еще PSNR пляшет, в отличии от frame-based (у обрезков кадра нет информации за границами нарезка, а также нужно больше служебных данных, мы как бы делим один поток видео на четыре)
И всё таки, у sliced можно лучше распараллелить декодирование. И судя по комментарию в [1], это также помогает при аппаратном ускорении, для Blu-ray должно быть 4 slices. Если оно так, то это должно помочь при декодировании Hi10P, которое у меня ни на старом, ни на новом телефонах (Samsung Galaxy S2 (2c), Asus Zenfone 2 ZE551ML (4c)) без тормозов не проигровалось. Надо тестировать!
Удалось разгадать путаницу из первого вопроса-источника:
При замере, с -tune zerolatency, кодирование кадра получилось дольше (по-умолчанию sliced для zerolatency), чем с threaded (frame-based). Объяснение просто: да, параллелизм sliced хуже, поэтому время кодирования больше. Но если распараллелить на frame-based, то время кодировки каждого отдельного кадра будет ниже, зато буфер и отсюда задержка будут намного выше.
Или начать декодировать первый кадр всеми силами или же ждать заполнения буфера, чтобы можно было заполнить потоки — разница есть.
Итого:
slices не нужны для обычного проигрывания видео (за искл. быстрого декодирования). Они просто хуже. Для стриминга в реальном времени — самое оно, но желательно ограничивать столькими потоками, сколько минимально надо для обеспечения кодирования (иначе — накладные расходы). Для трансляций с секундными буферами можно принудительно выключать slices, таким образом лучше загружать процессор и улучшить сжатие.
Много написал, фух, вроде не ошибся. Может написать статью, с тестами и обязательной КПДВ?
Источники:
[1] stackoverflow.com/questions/33624016/why-sliced-thread-affect-so-much-on-realtime-encoding-using-ffmpeg-x264
[2] Ссылка на док из [1], обязательно к прочтению
[3] stackoverflow.com/questions/20963042/encoding-for-fastest-decoding-with-ffmpeg
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Своя видео-платформа — ffmpeg и качество кодирования видео. Part 2