Декодировать видео h264

Я ищу способ декодировать h264 (или любой другой формат видео) с помощью С#. Конечная цель состоит в том, чтобы иметь возможность декодировать изображения и строго контролировать воспроизведение в режиме реального времени. Проект, над которым я работаю, представляет собой произведение нелинейного видеоарта, в котором HD-материал должен зацикливаться и редактироваться на лету, воспроизводить определенные диапазоны кадров, а затем плавно переходить к следующему случайно выбранному диапазону кадров.

Я создал приложение, которое считывает файлы изображений (jpeg) с диска и воспроизводит их на экране по порядку, у меня есть полный контроль над тем, какой кадр загружается и когда он отображается, но при полном разрешении HD это занимает немного больше времени, чем я хочу. для загрузки изображений с жесткого диска (каждое размером около 500 КБ), я думаю, что использование сжатого формата видео будет меньше и, следовательно, быстрее для чтения и декодирования в конкретный кадр, однако я не могу найти какой-либо доступный способ сделать это.

Есть ли библиотеки, которые могут это сделать? т.е. извлечь произвольный кадр из видеофайла и передать его моему приложению за меньшее время, чем требуется для отображения кадра (работает со скоростью 25 кадров в секунду), я просмотрел библиотеки vlc и оболочки для ffmpeg, но я не знаю, что быть лучше или если бы был другой, еще лучший вариант. Кроме того, я не знаю, какой кодек будет лучшим выбором, поскольку некоторые из них основаны на ключевых кадрах, что делает извлечение произвольного кадра, вероятно, очень сложным.

Приветствуются любые советы, спасибо


c# ffmpeg codec video decode
person john bowring    schedule 28.08.2011    source источник
comment
Если у вас уже есть работающее решение, почему бы вам просто не загрузить файлы JPEG в память? Это должно дать еще лучшую производительность... вы также можете использовать MemoryMappedFile, чтобы сделать чтение очень быстрым...   -  person Yahia    schedule 28.08.2011
comment
Если вам нужен полный контроль, вы можете изучить API Microsoft DirectShow msdn.microsoft.com/en-us/library/dd390351(v=VS.85).aspx   -  person Douglas    schedule 28.08.2011
comment
Программное декодирование видео HD H264 со скоростью 25 кадров в секунду — довольно сложная задача!   -  person James    schedule 28.08.2011
comment
-Yahia: Кэширование, вероятно, является областью, которую я хотел бы избежать, потому что я не знаю длины клипов, слишком длинных и не хватает памяти, и у меня быстро возникнут проблемы. Однако ваша идея использования карты памяти весьма интригующая.   -  person john bowring    schedule 28.08.2011
comment
Переход к любому кадру в H264 представляет собой небольшую проблему, если только это не ключевой кадр. Это можно сделать, конечно, но это может оказаться довольно медленным. Возможно, потребуется декодировать до 16 опорных кадров, хотя я не знаю, насколько это распространено. 2 системы отсчета должны быть достаточно общими. В HuffYUV каждый кадр является ключевым кадром, и его также можно быстро распаковать в программном обеспечении. Может быть стоит посмотреть.   -  person harold    schedule 28.08.2011
comment
-Yahia - Если я вас правильно понял, я мог бы кэшировать все кадры в виртуальной памяти как статический файл в файловой системе, а затем использовать его в своей программе для получения готовых кадров. Я думаю о том, чтобы получить твердотельный накопитель для этого проекта, поэтому доступной памяти на нем может быть достаточно. В качестве дополнительного бонуса мое видео будет аккуратно заперто на карте памяти, поэтому его также будет сложно скопировать. Можете ли вы предоставить какие-либо известные вам хорошие ссылки на ресурсы, касающиеся карт памяти? Спасибо   -  person john bowring    schedule 28.08.2011
comment
Yahia: Скажем, например, как я могу сохранить количество изображений в формате jpeg в карте памяти и как я могу получить их позже? Спасибо за всю вашу помощь кстати   -  person john bowring    schedule 28.08.2011

Ответы (2)


arrow_upward
4
arrow_downward

Я бы сказал, что использование H.264 не такая уж хорошая идея. Причиной этого являются различные типы кадров, из которых состоит поток.

  • I-кадры или ключевые кадры: все необходимое для декодирования кадра доступно напрямую, т. е. не существует никаких зависимостей от других кадров.

  • P-кадры (предсказанные кадры): состоят из разностных данных по сравнению с ранее декодированными кадрами.

  • B-кадры (двунаправленные): состоят из разностных данных по сравнению с ранее декодированными кадрами и кадрами, которые находятся в будущем.

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

В крайнем случае, контент H.264 может иметь только 1 I-кадр в начале клипа. Если вам нужно отобразить последний кадр, каждый промежуточный кадр должен быть декодирован до последнего кадра включительно, чтобы он отображался.

Использование JPEG, как вы и пытались сделать, — неплохая идея. Вы можете поиграться с уровнем сжатия, чтобы найти окончательный размер файла по отношению к качеству и времени декодирования.

Выход видеодекодера почти во всех случаях 4:2:0 субдискретизированный YUV несжатый необработанный -данные. Один кадр 1080p будет 1920*1080*1.5=3110400 bytes. Использование этого формата вместо JPEG (который также декодирует в YUV4:2:0) сократит время декодирования вашего «приложения», оставив просто время просмотра. Imagemagick и множество других инструментов могут конвертировать из JPEG в YUV4:2:0. Это не может сочетаться с отображением памяти, описанным в комментариях.

Если вы чувствуете, что необработанный формат занимает много места на диске, взгляните на huffyuv кодек YUV без потерь.

Что касается зрителя, то в прошлом у меня был большой опыт использования SDL, который понимает формат YUV, что очень упрощает написать зритель. К счастью, уже написан один, который вы можете использовать в качестве шаблона для дальнейшей разработки. Взгляните на yay

person Fredrik Pihl    schedule 29.08.2011

arrow_upward
0
arrow_downward

Я просто хочу отметить, что размер файла не всегда соответствует скорости. Иногда чем меньше файл, тем выше стоимость распаковки. Вы могли бы (и я подчеркиваю могли бы) повысить производительность, перейдя на несжатый формат, такой как BMP или, возможно, WMF.

person Chris Haas    schedule 29.08.2011