Главная | Информация | Long GOP видео
Про Long GOP видео кодеки
При практической работе в Премьере можно заметить что материал с разных камер по разному нагружает компьютер. DSLR обрабатывается легче чем материал с GoPro, DJI и подобных камер использующих так называемые Long GOP кодеки.
Long GOP обозначает длинный GOP, а GOP это дословно "группа кадров" которые сжимаются вместе. За счет того что алгоритм сжатия использует информацию всех кадров группы, сжатый размер получается в 2-3 раза меньше чем при сжатии каждого кадра по отдельности.
Посмотрим насколько фактически длинный Long GOP, и насколько он труднее для обработки компьютером.
Анализировать будем при помощи ffprobe (из состава ffmpeg) файл с камеры sony fdr-ax100:
ffprobe -select_streams 0 -show_frames r:\ax100.mp4 > r:\ax100.txt
получившийся лог закидываем в chrome и поиском смотрим сколько кадров всего

и сколько из них ключевых

Long GOP для Sony AX100 это всего 12 кадров (360/30), причем, если ax100 писала в режиме 100 fps, то GOP оказывается по 48 кадров, что кратно меньше увеличения скорости.
Этим методом получена следующая таблица:
Камера | Структура GOP | Размер |
---|---|---|
Samsung Galaxy Tab 4 | IP | 30 |
iPad 3 | IP | 30 |
iPhone 6 | IP | 30 |
iPhone 8+/1080p30 8mbps HEVC | IBBBP | 30 |
GoPro HERO 3 | IP | 15 |
GoPro HERO 4/1080p24-8bit420 45mbps | IP | 12 |
FujifilmX-H1/2160p30 100mbps | IP | 15(30) |
Olympus E-M1 Mark II/2160p24 175mbps | IBBP (All-I) | 12 |
Panasonic G7 | IBBP | 12 |
Panasonic GX7 | IP | 12 |
Panasonic GX80/1080p50 | IBBP | 24 |
Panasonic GH4 | IBBP | 24 |
Panasonic GH5/1080p25-10bit422 100mbps | IBBP | 12 |
Panasonic GH5/1080p25-10bit422 200mbps | All-I | 1 |
Panasonic GH5/2160p50-8bit420 150mbps | IBBP | 24 |
Panasonic GH5/2160p25-10bit420 400mbps | All-I | 1 |
Panasonic S1/2160p25-8bit420 100mbps | IBBP | 12 |
Panasonic S1/2160p25-10bit420 72mbps HEVC | IP | 12 |
Panasonic UX180/4k50-8bit420 150mbps | IBBP | 24 |
Panasonic AG350/4k50-8bit420 150mbps | IBBP | 24 |
Panasonic AG350/1080p25-10bit422 50mbps | IBBP | 12 |
Panasonic AG350/1080p100-10bit422 200mbps | IBBP | 12 |
Nikon D5100 | IP | 15 |
Nikon D750 | IBBP | 15 |
Canon 700D | IP | 12 |
Canon 5D mark 2 | IP | 12 |
Canon 5D mark 3/1080p25-8bit420 30mbps | IBBP | 12 |
Canon 5D mark 4/4096p24-8bit422 526mbps MJPG | All-I | 1 |
Canon 6D/1080p29,97-8bit420 30mbps | IBBP | 15 |
Canon G60/4k25-8bit420 150mbps | IBBP | 12 |
Canon EOS R/4k24-8bit420 120mbps | IBBP | 12 |
Canon EOS R6/4k25-10bit422 163mbps HEVC | IBBP | 12 |
Canon XF405/1080p50 35mbps | IBBP | 24 |
Canon XF405/2160p50 150mbps | IBBP | 24 |
Canon C200/2160p50 150mbps | IBBP | 24 |
Sony NEX-5 | IBP | 12 |
Sony FDR-AX100E/720p100 | IP | 48 |
Sony FDR-AX100E/2160p25-8bit420 100mbps | IBBP | 12 |
Sony FDR-AX700E/2160p25-8bit420 100mbps | IBBP | 12 |
Sony FS7 | IPBBB | 25 |
Sony FX3/2160p120-10bit422 280mbps HEVC | IB | 120 |
DJI Phantom 4 Pro/2160p29.97 100mbps | IP | 30(120) |
DJI Mavic Air/2160p29.97 100mbps | IP | 44 |
DJ Osmo Pocket/4k25-8bit420 100mbps | IP | 120 |
DJ Osmo Pocket/4k50-8bit420 100mbps | IP | 120 |
GOP в 12 кадров, это столько же сколько и в MPEG-2 DVD. GOP у фотоаппаратов Canon и камер GoPro по 12 кадров. Из этого можно сделать вывод, что трудности с обработкой материала подобного GoPro по сравнению с DSLR связаны не столько с Long GOP, сколько с использованием алгоритмов разной сложности сжатия из арсенала h.264. Причем в Premiere всё усложняется, потому-что он работает так, что если он не успевает распаковать один кадр, то задержка стремительно нарастает и нормальное проигрывание становится не возможным. Особняком стоят камеры коптеров DJI, у них реально длинный GOP - до 120 кадров. Не смотря на такой размер, I (ключевые) кадры идут каждый 30-й кадр. Это уже не так много, но судя по задержке на таймлайне, Премьер всё же распаковывает видео начиная с первого кадра в группе, а не с ближайшего ключевого.
Проведём простой эксперимент - перекодируем исходник DJI UHD 100 mbps в тот-же h.264 с тем же битрейтом но с GOP 12 кадров, это в 10 раз меньше, и если размер GOP имеет значение, то это будет заметно. В результате загрузка процессора при работе на таймлайне с перекодированным видео меньше не стала, но уменьшилась задержка при переносе плейхеда по таймлайну, это ожидаемо, т.к. при установке плайхеда на кадр в середине GOP, нужно распаковать 6 кадров по сравнению с 60 в оригинале.
Проведём второй эксперимент: понизим битрейт до 40 mbps. В итоге разница разительная, никаких задержек и пропусков кадра.
Olympus E-M1, камера с высоким битрейтом, но видео обрабатывается несколько легче чем видео с квадрокоптеров. В заголовке файла заявлен GOP в 12 кадров, но прямой анализ данных показывает, что все кадры I (т.е. ключевые). Вялость работы на таймлайне объясняется тем, что Премьер в любом случае распаковывает несколько (много) кадров в буфер в памяти, и этот процесс вступает в конкуренцию с процессом отображения кадра из буфера на экране. Тут срабатывает еще такая особенность, P и B кадры распаковать легче чем I, т.е чтобы проиграть 100 кадров IBBP видео нужно существенно меньше ресурсов чем для 100 кадров All-I.
Таким образом, в большинстве случаев у кодеков h.264, h.265 первостепенное значение для комфортной работы имеет битрейт как мера количества работы по рапаковке сжатой информации. Методы кодирования (P и B-кадры, CABAC) вторые по значимости. Замыкает эту очередность размер GOP. Если программа не успевает распаковывать видео в реалтайме, то нормальная работа не возможна и размер GOP значения не имеет, если программа успевает распаковывать и видео и плавно проигрывать его, то размер GOP будет влиять на задержку при перемещении по таймлайну: если кадр распаковывается за 30 миллисекунд, то при распаковке последнего кадра в группе из 120 кадров задержка составит 3.6 сек, кадра из середины 1.8 сек, первого кадра в группе .03 сек.
Если программа не успевает обрабатывать видео, то нужно или увеличивать процессорную мощность, или использовать декодирование видео с помощью GPU.
Второй вывод - как прокси например для UHD можно использовать перекодирование в UHD h264 c потоком 40 Мб/сек, GOP длиной 5 кадров, структурой IP.
http://www.tiliam.com/Blog/2015/07/06/effective-use-long-gop-video-codecs