SPS/PPS/VPS/VUI
VPS, SPS, and PPS contain general video parameters. They provide a robust mechanism for conveying data that is essential to the decoding process. They can be either a part of a bitstream or can be stored separately. Sequence parameter set (SPS) — a syntax structure containing syntax elements that apply to zero or more entire coded layer video sequences. SPS contains syntax elements such as the picture’s width, height, and bit depth. Picture parameter set (PPS) — a syntax structure containing syntax elements that apply to zero or more entire coded pictures. PPS contains information on entropy coding mode, slice groups, motion prediction, quantization parameters (QP), and deblocking filter. Video parameter set (VPS) includes syntax elements for session negotiation such as profile and level. SPS has an optional part that includes the video usability information (VUI) — parameters, which provide additional information about higher-level properties of video content such as aspect ratio, color space, chroma location, bitstream restrictions, timing, etc.
Что заставляет кодировщик часто генерировать SPS\PPS?
Хочу записывать mp4 из webrtc стрима. Проблема в том, что кодировщик chrome почему то слишком часто (с каждым IDR) посылает ещё и SPS\PPS пакеты. Парсил и сравнивал эти SPS\PPS, они все одинаковые (за исключением битов выравнивания в конце rbsp_alignment_zero_bit). Разрешение в потоке идет постоянное, не изменяется
Смотрел другие видео, везде 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?
Не охота пока дебажить хром, может кто подскажет куда копать )
Что такое CTR, CPM, PPC, CPA?

Типизировать партнерские программы можно в зависимости от того, за что они платят деньги. Существует несколько схем по которым могут производится выплаты участникам:
- оплата за продажу (PPS) — человек, пришедший по партнерской ссылке, оплачивает определенный товар, вебмастер, привлекший его получает вознаграждение. Человек, пришедший по партнерской ссылке, оплачивает определенный товар; вебмастер, привлекший его, получает вознаграждение. К этому типу партнерских программ относятся программы по продаже казуальных игр, физических товаров – книг, цветов, контактных линз и виртуальных предметов – карт оплаты, хостинга, медиафайлов.
- оплата за действие (PPM) — деньги перечисляются за совершение определенного действия, обычно заполнения регистрационных форм, подписку на рассылку и др. К этому типу можно отнести программы сайтов знакомств, онлайн-игр, обменных пунктов виртуальных валют и другие.
- оплата за клик (PPC) — система при которой оплачивается определенное количество переходов (кликов) на сайт с ссылки, размещенной в рекламном объявлении.
- оплата за показ (PPI) — оплачиваются все показы страницы, где размещена рекламное объявление, не зависимо от того, был ли совершен переход на сайт партнера или нет.
- многоуровневый маркетинг – система, выплаты в которой распределяются по иерархической сети рефералов и подписчиков.
Оплата за трафик
Партнерские программы, выплачивающие деньги за клик или за показ баннеров могут быть объединены, как программы с оплатой за трафик.
PPI-программа требует от публикующего партнёра (ПП) просто разместить рекламку на своем сайте и показывать его посетителям, чтоб получить свои комиссионные. PPC-система требуют еще один шаг со стороны посетителя. Посетитель должен не только увидеть объявление, но и кликнув по нему, перейти на сайт рекламодателя.
Первоначально PPC был более распространен, но его использование значительно сократилось из-за искусственного накручивания кликов. Контекстная реклама, такая как Бегун, Яндекс.Директ, Google AdSense, не учитывается в данной статистике. На данный момент не существует единого мнения, можно ли отнести контекстную рекламу к партнерскому маркетингу.
Оплата за клик превалирует как метод выплат в PPC-системах, базирующихся на показе контекстной рекламы. Оплата за показ является самой распространенной моделью выплат за показ рекламных объявлений (баннеров). PPM используется Google в системе AdSense/AdWords, но это скорее исключение в поисковом маркетинге.
Наиболее распространенная модель оплаты на сегодняшний день в Интернете это PPC.
Pay per click (англ. оплата за клик ) — это рекламная модель, применяемая в интернете, в которой рекламодатель размещает рекламу на сайтах, и платит их владельцам за нажатие пользователем на размещенный баннер (текстовый или графический). Таким образом рекламодатель как бы покупает себе клиентов в интернете.
Системы контекстной рекламы, являющиеся посредниками между рекламодателями и владельцами веб-сайтов называются PPC-системами.
CPC (от англ. cost per click — цена за клик) — это сумма, которую рекламодатель платит поисковым системам и другим интернет издателям за один клик по его рекламе, который принес одного пользователя на его сайт.
Цена за клик зависит от многих факторов, таких как поисковое слово/фраза, географическое местонахождение человека, выполняющего поиск, время суток, в которое производится поиск и т. д.
CTR — (синоним — кликабельность, от англ. click-through rate — показатель кликабельности) CTR определяется как отношение числа кликов на баннер к числу показов, измеряется в процентах.
Например: ваш рекламный блок показан 100 раз и на него кликнул один человек. Значит его CTR — 1 %. Формула вычисления CTR:
CTR = количество кликов / количество показов * 100
CTR является важным показателем эффективности любой рекламной кампании. Показатель CTR может быть применим к любой гипертекстовой ссылке в интернете, если учитываются её показы и клики.
CTR для динамических баннеров в Рунете обычно колеблется от 0,1 % до 2 %. При хорошем медиапланировании и эффективном таргетинге значение CTR может быть значительно выше и составлять десятки процентов. Самый высокий CTR может обеспечить контекстная реклама в поисковых системах, когда объявления рекламодателей показываются в зависимости от поисковых запросов пользователей.
Важное влияние на CTR (кликабельность) рекламы оказывают её размер, яркость, контрастность и место расположения на веб-странице.
Зачастую CTR считают мерой качества рекламного блока или рекламной площадки. Однако нужно иметь в виду, что для имиджевой, а не «продающей» рекламы значение CTR гораздо менее существенно, чем количество пользователей, которые её увидят, и то внимание, которое они ей уделят.
CPM акроним (от англ. Cost Per Millenium (Thousand)), обозначающий модель взаимоотношений с рекламодателем, которая предусматривает фиксированную оплату за тысячу показов рекламы. Количественный показатель прибыльности страницы. Показывает прибыль полученную за клики с 1000 показов, и дает возможность рассчитать возможную прибыль, зная количество показов страницы. Поскольку рассмотренный выше CTR является качественным показателем — несущим процентную информацию о соотношении кликов с показами, для разных сайтов он может быть одинаков при разном количестве кликов и показов объявления. Именно поэтому он не отражает количественных характеристик, напрямую связанных с прибыльностью страницы Сайт с 1000 показов и 10 кликами имеет СТR 0,01 также как и сайт с 10000 и 100 показами. Для получения более конкретных цифр с учетом цены за клик вводят понятие CPM.
*в приведенной формуле цена клика — цена получаемая площадкой за клик по объявлению, отличная от CPC.
CPA акроним (от англ. Cost Per Action), обозначающий модель взаимоотношений с рекламодателем, которая предусматривает оплату рекламы в случае совершения пользователем определенного покупки или действия.
Трансляция h264 видео без перекодирования и задержки
А почему не передавать записанные SPS и PPS перед каждым IDR NAL? Я пишу SPS + PPS и передаю преред каждым IDR. Кроме того, отдельно храню IDR и при первом подключении клиента сыплю сохраненный IDR+SPS+PPS (можно хранить и сыпать все налы между IDR), с минимальным интервалом между датаграммами, что позволяет получить картинку сразу после подключения.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
С SPS и PPS кадрами в нашем случае проблем не было: наша камера шлет их регулярно, с каждым кадром (см. парсинг потока камеры ELP). Что касается сохранения старых IDR кадрой, то в таком случае в начале трансляции будет показан старый IDR кадр, но последующие Non-IDR кадры буду накладываться на старый IDR, что будет давать плохую картинку. Нас такая ситуация не устраивала, к тому же небольшая задержка старта видео (менее секунды) нас не беспокоила.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
ничего накладываться не будет. При подключении посылаете записанные IDR+NIDRы, только не с интервалом 20-30мс, как при трансляции, а 3-4мс. Получаете готовый кадр и приемник готов к приему след. нонидров. Можно послать идр и игнорить все налы до след. идра, тогда вы получите статическую картинку на пару секунд. Все это верно и при трансляции записанного AnnexB файла, когда, как правило SPS/PPS передаются только раз.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В условиях ограниченной пропускной способности сети и ограниченной производительности планшета мы не можем сильно поднять скорость передачи кадров (максимум на 20-50 процентов). Таким образом мы будем ждать пока видео синхронизируется с реальным временем где-то секунду. При текущем подходе мы ждем примерно столько же.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
(ошибся веткой)
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Есть еще GStreamer с кучей плагинов и вроде с плагином от интела в том числе (GStreamer Media SDK plugins) В первом комменте в статье про mjpg-streamer его тоже вспоминают. Его не пробовали?
Всего голосов 6: ↑6 и ↓0 +6
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Пробовали, практически в самом начале разработки. Чем-то он нам сразу не подошел, уже точно не помню чем. По-моему, не удалось передавать видео без перекодирования.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Значит просто не разобрались в gstreamer.
Обычно то, что нерешает vlc и ffmpeg можно небольшими шаманствами с плагинами решить gstreamer’ом. Притом что в gstreamer’е можно спокойно использовать ffmpeg
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Может и так. GStreamer конечно мощная и лаконичная штука. Если подскажете, как передать с помощью gstreamer’а видео без перекодирования, будем благодарны.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Если у вас камера выдает картинку в mjpg или в raw, а вы хотите h264, то перекодировать придется.
Если же камера сама умеет выдавать h264, то это будет что-то вроде:
gst-launch v4lsrc ! video/x-h264,width=640,height=480 ! rtph264pay ! udpsink host=127.0.0.1 port=5555
Писал по памяти, скорее всего нагнал, пишите в личку, если не взлетит.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Спасибо, завтра попробую
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
в данном конкретном случае capsfilter (тот элемент пайплайна который «video/x-h264,width=640,height=480») даже не нужен наверно, так как rtph264pay по своей природе на вход просит следующее:
video/x-h264, stream-format=(string)avc, alignment=(string)au
video/x-h264, stream-format=(string)byte-stream, alignment=(string)
а вот если паковать в какой-то мультиформатный контейнер (у меня для стриминга в свое время очень хорошо mpegtsmux себя показал) то конечно стоит прописать капсфильтр чтобы исключить перекодирование.
Кроме того, если передача будет вестись по не самому надежному каналу (а тут у нас именно такой, БПЛА же) возникает проблема потерь udp пакетов (возникнет как только выйдете из лаборатории) соответственно я бы все же советовал tcp использовать, иначе рискуете вообще никакой картинки не получить. MJPEG кстати в этом отношении лучше, так как нет межкадрового, что получил то и отобразил, в худшем случае теряя фреймрейт.
Так вот, если использовать tcp то помимо той задержки которую вы видите на старте появляется назойливая «накапливающаяся» задержка.
Выглядит это следующим образом: связь устанавливается, картинка отображается, задержка небольшая. вдруг откуда ни возьмись возникают проблемы в канале связи, картинка фризится, стример/приемник начинает увеличивать буферы чтобы давать плавную картинку. В итоге через пару таких фризов имеем вместо стартовой задержки в 200 мс аж 2-3 секунды задержки. что конечно неприемлемо.
Всех путей решения данной проблемы я если честно и не вспомню уже сейчас, года 3-4 назад занимался. один из вариантов добавить leaky queue который будет дропать слишком старые, все равно никого не интересующие данные если есть более новые.
Кстати. vlc имеет настроечку network-caching позволяющую настроить политику кеширования. если его в качестве клиента использовать — отлично работает