FFmpeg 3.2

Ровно как и своё делают и параметры запуска не ломают. Собственно GPL и опенсорс - есть что интересное, почему не дёрнуть в обратку.

Такая схема работы обусловлена особенностью работы кодеков и многих существующих API. В том числе - аппаратных. Вообще, теоретически, возможны ситуации генерации нескольких фреймов из одного пакета, и такой подход позволяет более лаконично обрабатывать такие ситуации.

А интелевское ускорение кодирования mpeg2 заработало? Файлы-то оно пережимает из h.264 нормально, а вот с потоковым видео лажает, иногда вплоть до полного зависания сервера.

H265 уже готов для мощных рипов, достойных рутрекера? Если ли смысл выкладывать фильмы в h265 с битрейтом 8-10 Мбит в сек?

H265 уже готов для мощных рипов, достойных рутрекера? Если ли смысл выкладывать фильмы в h265 с битрейтом 8-10 Мбит в сек?

Офигеть можно! И сколько один такой фильм весит?

P.S.
Лет 10 назад, я ещё думал, что фильм с DVD качеством это идеал.

Кстати, выкладывают на рутрекер рипы в VP8/9?

Вообще, теоретически, возможны ситуации

Если верить заметке (выше треду), то такой ситуации пока нет. И не факт, что будет.

Я регулярно качаю фильмы h264 с битрейтом 20 мбит в сек, весят около 20-40 Гигов. Качается за 2 часа :)

Мне кажется, имеет смысл пережимать 20 Мбит h.264 в 8 Мбит h.265.

Нет. Чтобы сжать фильм с этими кодеками с потоком 5-10 Мбит в секунду и с хорошим качеством - нужно ОЧЕНЬ ОЧЕНЬ много процессорного времени. Порядка 3 суток непрерывного кодирования на core i7 3770 4 Ггц.

Начиная с хасвелла побыстрее будет, у тебя проц старше.

Они там даже в основном выкладывают без полных возможностей h264 с ограниченным level до 3*, чтобы на аппаратных недоплеерах везде открывалось.

Нет. Ибо смысла нет. Поддержка у него хуже, чем у h264 или h265

К тому же скоро будет AV1 им на замену https://en.wikipedia.org/wiki/AOMedia_Video_1

Уже 2 года h265 кодируют, это примерно как с h264-hi10p — в него кодировали когда ещё ни один софтварный плеер не умел в него, только форки форков. Правда тут ситуация получше.

Аппаратный энкодер будет хуже всегда. Т. к. разрабатывается с целью снизить вычислительную нагрузку, например, путём нахождения субоптимального представления видеоряда с компенсацией движения в системе безисных лексем посредством упрощённых вычислений. В основе кодеров стандартов MPEG лежат четыре принципа:

1. поблочный поиск векторов движения по оному из критериев ошибки предсказания;
2. поблочное корреляционное преобразование (например, ДКП) для последующего компактного представления информации об изображении;
3. передискретизация (снижение точности чисел, которыми представлены коэффициенты преобразования) и отбрасывание незначимых (и снова по какому-нибудь критерию ошибки)скалярных произведений коэффициентов корреляции с базисными функциями коэффициентов преобразования;
4. благодаря декорреляции (временно́й по п.1 и пространственной по п.2) исходного видеоряда, а также в результате устранения избыточности по п.3, повышается вероятность оптимального (по критерию наименьшей ширины выходного потока данных) представления последовательности лексем, в которые превратился видеоряд после хитрокрученных преобразований пп.1-3, через арифметическое кодирование, понижающее энтропию данных.

Обращаю внимание, что наиболее нагруженным по вычислениям является п.1; он же имеет ярко выраженный очевидный компромисс: можно вести поиск коротких векторов движения (т. е. ограничивать область поиска наименьшей площадью кадра), обеспечив таким образом максимальные возможности для параллельного поиска в независимых вычислительных потоках, а можно вместо этого увеличить зону поиска движения с целью получить общую картину векторов движения, как можно ближе соответствующую перемещению объектов, различимому человеческим зрительным восприятием, т. е. приблизиться к оптимальному предсказанию движения.

Но это половина беды. В п.4 не вполне очевидно, что весь процесс пп.1-4 является итерационным: так для оценки движения в п.1 обеспечивается вариативность каждого законченного решения по предсказанию движения (т. к. в зависимости от данных, которыми станут лексемы от последующих пунктов, не очевидна оптимальность каждого отдельного решения после энтропийного кодирования); а п.2-3 параметризуются с целью формулирования оптимизационной задачи и последующего её решения относительно параметров (например, значения квантователя) и ширины потока данных на выходе.

Таким образом в нашей программе появляется многопетлевая отрицательная обратная связь, которая ставит массивный бетонный могильный камень над перспективой массовой параллелизации вычислений. Сама задача поиска компенсации движения сформулирована так, что для её решения предпочтительнее один быстрый камень, чем несколько медленных. Т. е. прощай куда-чуда-юда.

Дополнительно расскажу, что со времён H.261 и его предшественников принципы неизменны, а развитие идёт по пути усложнения инструментов представления (расширение набора лексем) видеоряда. Грубо говоря, с каждой следующей версией к идее компенсации движения добавляют новых костылей, которые сильно увеличивают вычислительную сложность и дают небольшое приближение к оптимальному кодированию по критерию наименьшей заметности потерь при высоком коэффициенте сжатия. Качественно набор лексем ограничивается профилями современных стандартов (например, в H.264 есть их восемь), и количественно ограничивается уровнями. При этом производитель специализированной микросхемы (или ПЦОС-блока) не заинтересован в том, чтобы поехать на отличненько в попытке реализовать все мыслимые в стандарте лексемы и аппаратную синхронизацию вычислительных потоков, а потом всё это отладить и оптимизировать (скромно напомню, что в железе ошибки исправлять и искать не в пример сложнее, чем в программе). Посему программные кодеры, как правило, существенно сложнее, что в случае, например, libx264 обеспечивает существенный выигрыш в приближении к оптимальному сжатию.

Да, и про всё это русским языком написано в Википедии, но школьники из треда, конечно же, не читатели, да.

Такие дела.

Пользуясь случаем спрошу у зала: хочу выдрать кадр из видео, обязательно ли для этого нужен ключевой кадр? Как я понял ffmpeg сначала ищет этот кадр, на это уходит определенное время и это время варьируется от видеоролика, иногда доходит до 5 сек.(много). Видос в mp4/flv

Обязательно.

Отличная новость!

Да, обязательно. Причём в случае H.264 для восстановления произвольного кадра потребуется предварительно восстановить не только ключевой кадр, но и все ссылочные, которые в случае high profile могут быть и B-кадрами, и даже со ссылками высшего порядка (т. е. ссылаться на другие B-кадры). B-кадром называется такой кадр, который содержит хотя бы один макроблок (единицу предсказания движения), ссылающийся одновременно на макроблоки одного из предыдущих и одного из следующих кадров. Стандарт ограничивает общее число ссылочных кадров таким хитрым параметром как Reference Frames (опция --ref у x264); суть его — максимальное число кадров, которые требуется восстановить гипотетическому декодеру для восстановления произвольного кадра.

Т. о. если вы выбрали произвольный кадр, то восстановить потребуется не только ключевой кадр, но и до N-1 прочих ссылочных, где N — число reference frames, указанное в секции codec pivate вначале первого или каждого ключевого кадра закодированной последовательности. Школота отмечена не только рукоблудной страстью к Hi10P, но и стремлением не жалеть ни своё ни Ваше время путём разрешения большего числа reference frames.

Естественно. ТЫ же не процессоры используешь разные, а разные кодеки. Один программный, на процессоре, а другой аппаратный, на видеокарте.

массивный бетонный могильный камень

Ну ты прям загнул! Даже если решать честно (допустим так же честно как в ffmpeg, там тоже хаков хватает) и пытаться сделать все прям оптимально-оптимально, то все равно есть очень много мест для распараллеливания кода.

ИМХО, ниша у хардверных решений ближе к рилтайму. А там в любом случае ни о какой оптимальности не может идти речи...

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

допустим так же честно как в ffmpeg, там тоже хаков хватает

В libavcodec предсказатель движения распараллелен в зависимости от критерия оптимальности весьма хорошо: в основном в два треда.

очень много мест для распараллеливания кода

Не затруднит показать? Если что, что заметка об обратном у меня заготовлена.

H.263
2016

Бу-га-га. А чего сразу не MPEG1?

4-8k 60fps кое-какую нагрузку на проц создаст, думаю.

Хотя бы потому, что ролики в старых форматах не исчезли из-за появления новых.

Кто-нибудь ffplay пользуется? Где, на чем?

Для тестов?

А если в видео одна картинка статичная с длительеостью в час(звук), получается что можно 1 ключевой кадр в начале и 1 в конце запихать? И что мне нужно будет ждать этот час для выдирания картинки?

И что мне нужно будет ждать этот час для выдирания картинки?

Если имелась в виду необходимость восстановления всех кадров последовательности, то её в случае H.261/H.262/H.263/H.264/H.265 при доступе к произвольному кадру нет, т. к. одной из принципиальных частей стандарта является спецификация на гипотетический декодер с ограниченным видеобуфером, в котором храниться весьма небольшое число кадров, которые ранее использованы кодером как ссылочные, т. е. в закодированной последовательности для любого произвольного кадра ограничено число ссылочных.

Пример со статичной картинкой неудачный, т. к. там нет предпосылок к двусторонней компенсации движения, все вектора из оптимального решения задачи поиска движения нулевые, и все ссылки, соответственно, ведут к первому кадру, являющемуся ключевым и по совместительству единственным ссылочным. В приведённом случае для восстановления такой последовательности потребуется получить два кадра: ближайший ключевой и Ваш произвольный. Но это если при кодировании статичной картинки тот, кто кодировал правильно настроил кодер, т. е. выключил компенсацию движения (указав нулевую область поиска) и B-макроблоки. На практике, картина будет несколько отличаться, но для видеопоследовательности, соответствующей уровням и профилям стандартов H.262/H.263/H.264/H.265 всю последовательность из, например, нескольких десятков кадров воспроизводить для доступа к произвольному кадру не потребуется в любом случае. Плюс ко всему, даже изготовить такую последовательность при помощи отлаженного кодера не то, чтобы очень просто, т. к. кодеру должен получить оптимальное по ширине потока решение, в которое не может вписаться большое число ссылочных кадров, т. к. каждая ссылка — это дополнительный трафик, а решение о каждой дополнительной ссылке для любого макроблока даёт убывающий возврат (т. е. экономия трафика в целом от увеличения числа ссылочных кадров на единицу убывает с числом ссылочных кадров, и довольно быстро).

Не затруднит показать?

Конкретный код обсуждать не буду. DCT и квантование я так понимаю вообще нет смысла обсуждать, там само собой параллелится по количеству макроблоков.

А про motion compensation - основная сложность найти что куда переместилось. Не знаю как сейчас решают, но раньше чуть ли не в наглую брутфорсили каждый макроблок в ограниченном диапазоне алгоритмами вида «а если сюда, то какая будет ошибка, а если сюда и т.д.», а потом выбирали результаты с минимальной ошибкой (или точнее с допустимой ошибкой). По количеству изменившихся блоков и по диапазону поиска такой алгоритм должен неплохо параллелится. Решение потом придется принимать в один поток (после барьера наверное), но там уже вроде как и не нужны серьезные вычислительные мощности. Барьер тоже может снизить эффективность от распараллеливания, но вряд ли превратит задачу в «однопоточную».

С некоторыми стадиями сжатия наверное ничего не сделаешь. Например, когда-то давно в глубоком детстве я подбирал таблицу Хаффмана методом, отдаленно похожим на динамическое программирование. Наверное ту реализацию никак не получилось бы распараллелить... Так что с variable size motion compensation можно и встрять, или с решениями типа P-frame или B-frame, или с решениями типа перемещение блока или полная замена. Но если внутри распараллелить, то может и не нужно эти стадии пытаться снаружи оптимизировать...

Аппаратно кодит специальный чип с ограниченными возможностями и настройками. Не столько качество хуже, сколько хуже эффективность сжатия. Говорят хардварные кодеры жмут на уровне superfast veryfast пресетов x264. Качество обеспечить можно, но нужно больше битрейта. То есть, чем слабее сжимаемость, тем больше нужно битрейта для того же качества. Поэкспериментируйте сами в x264, сожмите с crf, например 18, на разных пресетах от ultrafast до placebo и посмотрите на получившийся битрейт. Так то и ultrafast может сжать вообще без потерь при crf=0.

Это декодирование при воспроизведении, для этого есть специальный чип. А для кодирования современные кодеки используют CUDA, DXVA + CPU, и соответственно настройки можно установить какие тебе угодно.

А для кодирования современные кодеки используют CUDA, DXVA + CPU, и соответственно настройки можно установить какие тебе угодно.

Серьёзно? А пруфануть ссылкой? Вот кое-какие соображения от разработчика: http://forum.doom9.org/showthread.php?p=1135399#post1135399 https://www.researchgate.net/publication/220810465_An_efficient_parallel_moti... https://sites.google.com/site/x264cuda/Home/x264-cuda.pdf?attredirects=0

Это декодирование при воспроизведении, для этого есть специальный чип.

Для кодирования тоже. Небольшой ликбез специально для тебя. См. http://www.nvidia.ru/object/tesla-gpu-accelerated-libraries-video-codec-sdk-r...

API NVIDIA NVENC... доступ к высокопроизводительному кодировщику видео H.264... специальное аппаратное обеспечение для осуществления кодировки видео...
ядра GPU с поддержкой CUDA... свободны для выполнения других задач...

NVENC — это отдельная кучка транзисторов на кристалле GPU, которая ничего кроме кодирования видео не умеет, да и настройки там совсем не любые. И да, эффективность сжатия весьма сомнительна. Даже настолько, что выигрыш в скорости при примерно той же эффективности сжатия у профиля ultrafast/superfast библиотеки libx264 не воплне очевиден.

См. также https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

dedicated video encoding and decoding hardware core.

Т. е. всё то же самое. Отдельная кучка транзисторов, специально для кодирования видео с убогим набором опций. Как и в случае с NVENC, здесь гораздо больше маркетинга, чем практически целесообразных технологий.