Кратко

  • BMPEG задавал целые видеосрезы и аудиокадры, 90-кГц метку изображения, длину аудио и знаковое смещение его начала.
  • Эти поля описывали упаковку; своевременное получение, состояние MPEG, lip-sync, физический вывод и присутствие аудитории оставались отдельными событиями.

Пакет, похожий на программу

В BMPEG сначала располагалось видео, затем полные аудиокадры, покрывающие длительность сегмента. Заголовок RTP показывал порядок, время изображения и его конец. Специальный заголовок добавлял тип I/P/B, признак изменения MPEG-заголовков, число аудиобайтов и временное смещение начала звука.

Для VOD 1998 года это имело смысл. Одна программа использовала один порт. Уже чередующийся материал не требовалось делить на две сессии. Общий заголовок уменьшал overhead, а буфер мог стать меньше. В примере 4 Мбит/с RFC оценивал экономию примерно в один процент.

Документ называл связь implicit synchronization. Это означало, что временное отношение выражено в пакете, а не что экран и громкоговоритель были измерены.

Выигрыш оплачивался modularity

RFC 2343 имел статус Experimental и не являлся Internet standard. Bundling предлагался тогда, когда его преимущества стоили отказа от независимости аудио- и видеопотоков.

Единая конструкция объединяла и ущерб. Потеря могла затронуть обе среды. Выбрать только одну становилось сложнее. Большой пакет мог превысить path MTU и быть фрагментирован ниже.

Формат удалял сведения MPEG systems layer, считавшиеся дублирующими RTP. Ответственность не исчезала: она переходила packetizer, receiver и приложению. Два узла могли принять одинаковый синтаксис, но по-разному восстановить состояние и скрыть потерю.

Границы codec становились границами packet

Video_Sequence_Header начинал payload. GOP_header начинал его или следовал за sequence header. Picture_Header начинал payload или следовал за GOP. В каждом пакете было целое число video slices.

Это облегчало поиск точки возобновления, но не запрещало IP fragmentation. Приложение подбирало размер slice и их количество под MTU. При превышении нижние слои фрагментировали пакет, увеличивая последствия потери и усложняя классификацию RSVP.

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

Parser подтверждал структуру, но не знал о потерянном фрагменте, слышимом повторе или опустевшем buffer.

Транспортный порядок не был порядком показа

32-битная метка на частоте 90 кГц обозначала sampling time изображения. Все пакеты picture имели одно значение, а Marker отмечал пакет с её концом.

B pictures могли передаваться не в порядке presentation, поэтому timestamp не обязан был расти. Пакет только с headers использовал время следующей picture. Sequence number при этом сохранял транспортный порядок.

Audio Offset задавал в знаковых samples расстояние от начала аудиокадра до timestamp пакета. При 44,1 кГц диапазон составлял около ±750 мс. Для одной картинки в секунду RFC допускал непригодность формата.

Аудио не переставлялось вместе с B pictures. Offset указывал, когда оно должно прозвучать. Верная координата не доказывала преобразование clocks, latency устройства и воспринятую синхронность.

Обнаружение потери не возвращало содержание

Sequence gaps и timestamps обнаруживали пропуски. Номер slice и позиция первого macroblock помогали оценить область. При потере внутри одной picture decoder мог повторить pixels предыдущей. Вместо утраченного audio можно было подать background noise, чтобы скрыть разрыв и поддержать lip-sync.

Это concealment, а не восстановление. Повторные pixels и вставной звук не являлись оригиналом.

N bit сообщал об изменении sequence, extension, GOP или picture header. Если новое состояние было потеряно, безопаснее было отбросить данные до следующего picture start. После тяжёлых потерь требовался новый sequence header.

BMPEG не включал отдельный picture counter наподобие temporal reference RFC 2250. Потеря GOP_header могла остаться незамеченной и испортить декодирование последующих B pictures. Разбираемый пакет не гарантировал правильный контекст.

За форматом следовала цепочка доказательств

Нужно было отдельно видеть своевременную доставку, reassembly фрагментов, полноту picture, состояние headers, decoder output, перевод timestamps в реальные времена, согласование audio/video clocks, renderer, физические выходы, mute/hidden state и присутствие зрителя.

RTP не резервировал ресурсы и не гарантировал QoS. Валидный пакет мог опоздать. Полная picture могла зависеть от утраченного состояния. Decoded frame мог быть отброшен. «Playing» мог существовать в фоне. Включённый экран мог стоять перед пустым креслом.

RFC 2343 точно определил утверждение packetizer. Именно поэтому предел очевиден: payload свидетельствовал об упаковке, но не о просмотре.