Я бы сказал, что использование 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