LINUX.ORG.RU

Что заставляет кодировщик часто генерировать SPS\PPS?

 , ,


0

3

Хочу записывать mp4 из webrtc стрима. Проблема в том, что кодировщик chrome почему то слишком часто (с каждым IDR) посылает ещё и SPS\PPS пакеты. Парсил и сравнивал эти SPS\PPS, они все одинаковые (за исключением битов выравнивания в конце rbsp_alignment_zero_bit). Разрешение в потоке идет постоянное, не изменяется

Вот пример двух SPS https://www.diffchecker.com/rABX2dvT


Смотрел другие видео, везде SPS посылается один, в начале видео. В моем же случае они сыпятся с каждым IDR

Вот примерный порядок NAL (вырезал nal_unit_type=1, т.к. их слишком много)

nal_unit_type     00111 = 7 (SPS)
nal_unit_type     01000 = 8 (PPS)
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5 (IDR)
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7
nal_unit_type     01000 = 8
nal_unit_type     00101 = 5
nal_unit_type     00111 = 7

Последовательность такая SPS PPS IDR, SPS PPS IDR, SPS PPS IDR... Ничего не понимаю, зачем слать каждый раз SPS, если он не меняется. Что ещё может меняться в стриме, что заставляет кодировщик слать эти SPS?

Не охота пока дебажить хром, может кто подскажет куда копать )

★★★★

Не охота пока дебажить хром, может кто подскажет куда копать )

пфф

SPS,PPS,IDR необходимое и достаточное, чтобы начать показывать картинку

anonymous
()

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

Harald ★★★★★
()
Ответ на: комментарий от Harald

Параметры не меняются, их благополучно кэширует стриминговый сервер в самом начале потока, потом их выдает подключеному клиенту вместе с IDR. По идее, дальше в потоке должен только IDR отсылаться переодически (вот без него как раз новый клиент и не получит картинки), но не как не набор параметров SPS/PPS

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

С тем что их отсутствие приводило к проблемам сталкивался (при разрезании по ключевому кадру), а с тем чтоб их наличие чему-то мешало нет. От SPS/PPS в каждом кадре с IDR есть какой-то вред или заметное увеличение размера?

GPFault ★★
()
Ответ на: комментарий от GPFault

От SPS/PPS в каждом кадре с IDR есть какой-то вред

В моем случае да, видео в хроме на Win7 зависает после очередного изменения SPS, при аппаратном декодировании (при софтварном все ок). Если SPS послать единожды в начале, то все норм

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Параметры не меняются, их благополучно кэширует стриминговый сервер в самом начале потока, потом их выдает подключеному клиенту.

Полно вариантов когда «стриминговый сервер» знать не знает какие у него клиенты и когда они подключиись.

Kosyak ★★★★
()
Последнее исправление: Kosyak (всего исправлений: 1)

Это хорошо. Когда я стримлю спецом делаю, чтобы перед каждым ключевым кадром шли SPS и PPS. Откуда хром знает что там на другом конце? Кэширует ли? А чё с потерями в сети? И т.д. Не ной. Наслаждайся.

anonymous
()
Ответ на: комментарий от Kosyak

То есть? Клиент подключился, отдал sps, pps, дальше либо отдал сразу закешированный gop, либо клиент ждет в потоке idr

gobot ★★★★
() автор топика
Ответ на: комментарий от anonymous

Я нашел баг в хроме уже давно, там буферов не хватает, я увеличил с 5 до 10, пересобрал и проблема исчезла. В багрепорте хромиума попросили меня найти оптимальное кол-во буферов. Они влияют на расход памяти. Композиту не хватает буферов, чтобы показать кард, поэтому он ждет новых данных, а буферов свободных нет.

Потом я спросил, а как быть со старыми версиями, в них же не будет испрвлений. Они сказали чтобы я в первую очередь избавился от частых sps/pps. И вот я тут) Тоже не понимаю чем мешают эти спс...

gobot ★★★★
() автор топика
Ответ на: комментарий от anonymous

А как я их починю, если их openh264 в хроме делает? Да и причем тут они...

gobot ★★★★
() автор топика
Ответ на: комментарий от anonymous

Хотя, они потом перебиваются и подсовываются в avcodec ffmpeg... Как размер пакета как может влиять? Я смотрел есть около 4 пакета длительностью 90ms в видео длинной в 8 минут. Но в средем там на несколько порядядков больше идет. Хотя в других «нормальных» видео идут пакеты длительностью 512 в основном и не зависают

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

да вроде тут уже написали много раз.

клиент может подключиться когда хочет, ему нужны эти sps/pps

webrtc из той тусовки, где не принято слать sps/pps в sdp, но любят прислать в потоке.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

Насколько я знаю, спс/ппс не меняются, их можно отдавать каждому клиенту лишь в начале потока(предварительно кешируя стрим сервером). Другое дело idr или gop, которые тоже можно кешировать, но лучше чтобы клиент их сам подождал в потоке, вот их как раз и нужно посылать каждые 2-3 сек, но никак не спс/ппс

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

не, у тебя смешалось.

SPS как правило меняется крайне редко, если не меняются настройки видео.

PPS обычно не меняется (ну или с SPS), но иногда меняется часто, если стукнутый на голову источник. Есть у нас такие примеры, когда на каждый кадр чередующийся PPS.

А вот IDR — это фактически жпег. Ты можешь забуферизовать последний gop начиная с IDR и выслать его препушем клиенту, но это не «посылать каждые 2-3 секунды», а «послать последние 2-3 секунды».

Ну и к webrtc это не относится, потому что там вообще приняты гопы по 10 минут (!)

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

SPS как правило меняется крайне редко, если не меняются настройки видео

Вот это я и хочу понять, чего он тогда отсылается вместе с IDR каждые 2-3 сек. Настройки видео не меняются.

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

это просто обычная стандартная практика в подобных протоколах.

Можно отслеживать, кому из клиентов уже послал SPS/PPS, а можно просто всем рассылать.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

Какая практика?

клиент может подключиться когда хочет, ему нужны эти sps/pps

Вообще webrtc это протокол точка-точка, то есть для каждого клиента создается отдельное соединение. Вообще там оба участника клиенты, нет сервера. Поэтому посылать постоянно спс/ппс не разумно, если они не меняются

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Они мизерные по размеру. Не понимаю из-за чего столько проблем. Там весь поток может быть засран разделителями. После каждого nal юнита вставляют. А ты к няшным sps и pps прицепился.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Из-за этого аппаратный декодер в хроме сбрасывается каждый раз, когда приходят СПС

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

очевидно что весь интеловский webrtc построен на гугловской webrtc либе

зачем долбить хром не понятно

хром <-> хром никаких левых pps sps не отправляет

значит насилуй интеловскую обертку над гугловским webrtc

anonymous
()
Ответ на: комментарий от anonymous

хром <-> хром никаких левых pps sps не отправляет

Возможно. Вы это как определили?

gobot ★★★★
() автор топика

Проблема заключалась в настройке кодировщика OpenH264 в стеке webrtc хрома.

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

давайте уже точнее, или ближе к телу, как испрвляется

или это на стороне хрома и разрабы обязались починить ?

тогда тикет сюда давайте

anonymous
()
Ответ на: комментарий от anonymous

или это на стороне хрома и разрабы обязались починить ?

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

Проблема заключалась в том что в настройке кодера OpenH264 использовался параметр(eSpsPpsIdStrategy.INCREASING_ID), каждый раз увеличивался sequence_id в SPS, что в свою очередь вызывало постоянное
сбрасывание декодера(DXVAVDA), что в свою очередь вызывало другой баг и это останавливало видео.

Они исправили как кодировщик так и аппаратный декодер

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

линку на ихний фикс в теме тогда оставьте

anonymous
()

ибо webrtc реализован для работы в негарантироанной сети а не для записи в файл

anonymous
()
Ответ на: комментарий от anonymous

Да, для избыточной гарантии доставки СПС они всегда меняли номер, но потом все же пересмотрели и изменили алгоритм

gobot ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.