Один и тот же медиаформат для аудио и видео в RTSP.

Наша компания разрабатывает программное обеспечение для видеонаблюдения, и мы в основном используем RTSP для связи с устройствами (но мы поддерживаем любой необходимый протокол), и мы разработали собственный клиент RTSP и парсеры.

Сегодня мы работали над интеграцией новой камеры и обнаружили интересный сценарий, в котором камера сопоставляет динамическую полезную нагрузку 96 с аудио- и видеопакетами, см. описание SDP:

RTSP/1.0 200 OK
CSeq: 2
Date: Sat, Jan 01 2000 19:39:38 GMT
Content-Base: rtsp://10.1.39.174:8557/PSIA/Streaming/channels/2?videoCodecType=H.264/
Content-Type: application/sdp
Content-Length: 830

v=0
o=- 946754247689123 1 IN IP4 10.1.39.174
s=RTSP/RTP stream from IPNC
i=2?videoCodecType=H.264
t=0 0
a=tool:LIVE555 Streaming Media v2010.07.29
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from IPNC
a=x-qt-text-inf:2?videoCodecType=H.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:4000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-   sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgC3YCqQAAAMABAAAAwJZgQAB6EgAAiVQve+F4RCNQAAAAAE=,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:128
a=rtpmap:96 PCMU/16000
a=control:track2
m=application 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:64
a=rtpmap:96 vnd.onvif.metadata/90000
a=control:track3

Как вы видете:

m=video 0 RTP/AVP 96
m=audio 0 RTP/AVP 96

Проблема в том, что мы используем это сопоставление для определения сжатия полученных RTP-пакетов. Я всегда думал, что каждый носитель будет иметь свое сопоставление, например, 96 для видео и 97 для аудио (или даже статическое сопоставление, такое как 0 для PCMU), но это устройство использует одно и то же сопоставление для всех медиа, поэтому наш анализатор не будет работать, потому что он идентифицирует аудиопакеты, полученные с полезной нагрузкой 96, как видеопакеты и отправит их непосредственно в видеодекодер, и, конечно, это не сработает...

Я проверил, что VLC работает нормально, но я твердо верю, что VLC не использует это сопоставление для разделения пакетов, а использует идентификаторы каналов (в TCP) или разные порты UDP, чтобы определить, какие пакеты принадлежат какому носителю.... Но мы уже построили нашу архитектуру для разделения пакетов в зависимости от типа полезной нагрузки.

Поэтому я спрашиваю... Правильно ли отображать аудио и видео на один и тот же номер динамической полезной нагрузки (96)???

Это первый раз, когда я столкнулся с этой проблемой, и мне нужно знать, придется ли нам менять весь наш RTSP-клиент, чтобы идентифицировать носители, используя каналы вместо формата полезной нагрузки, или есть ошибка реализации на стороне камеры, которая они должны были связать другие номера полезной нагрузки с каждым различным медиа (видео 96, аудио 97, приложение 98...)

Кто-нибудь знает, действительна ли такая практика (использование одного и того же номера полезной нагрузки для всех носителей)???

Мы реализовали клиент RTSP и парсеры SDP с использованием спецификаций RFC, но я не нашел ничего, связанного с использованием одного и того же номера полезной нагрузки для всех носителей, во всех примерах они всегда назначают разные номера полезной нагрузки для каждого носителя...


person Eric    schedule 26.02.2013    source источник


Ответы (3)


Это очень хороший вопрос. Из семантики опубликованного вами SDP следует, что эта камера реализует спецификацию RTSP из RFC 2326. на основе наличия поля a=control.

В этой спецификации можно заметить, что каждая полезная нагрузка мультимедиа имеет определенный управляющий параметр, связанный с первым управляющим оператором, равным a=control:*. На странице 83 спецификации я чувствую, что аудио- и видеопотоки могут быть настроены как

audio = rtsp://10.1.39.174:8557/PSIA/Streaming/channels/track2

и

video = rtsp://10.1.39.174:8557/PSIA/Streaming/channels/track1
person Ganesh    schedule 07.03.2013

Хороший вопрос, диапазон 96-127 определен для динамических типов полезной нагрузки, и в RFC не указано, должны ли используемые типы быть уникальными для нескольких дескрипторов. Конечно, вещи были бы яснее, если бы они были уникальными. Однако им не нужно как кажется. Типы полезной нагрузки не смешиваются, потому что все они определяются отдельно в своем собственном медиа-объявлении, то есть использование видео 96 и аудио 96 выглядит допустимым. Не говоря уже о том, что если устройства реального мира определяют сеансы таким образом, то клиенты RTSP должны быть к этому готовы.

person Roman R.    schedule 26.02.2013
comment
Дело в том, что я уже многое повидал, и не сомневаюсь, что у этого китайского производителя есть какие-то проблемы с RTP-стримингом... но было бы неплохо узнать, должна ли полезная нагрузка быть уникальной во всем анонсе или нет. - person Eric; 26.02.2013
comment
Разделы 5.14 и 6 RFC 4566 говорят, что это атрибут уровня мультимедиа, поэтому я бы сказал, что этот SDP действителен. - person Roman R.; 26.02.2013
comment
Я бы сказал, что оригинальный SDP действителен. Атрибут Media сообщает вам аудио или видео. 'м=' - person Jay; 12.03.2013

Вышеупомянутое SDP действительно на мой взгляд. Я видел, что тип мультимедиа включает одинаковые номера полезной нагрузки для аудио- и видеоканалов мультимедиа.

Пара идей: 1. Посмотрите, можете ли вы попросить эту камеру независимо передавать только аудио или видео. Таким образом, технически у вас может быть два сеанса RTSP (один для аудио, один для видео); таким образом вы могли бы точно знать, какой RTP-трафик идет к вам; и на основе этой информации используйте аудио- или видеодекодер.

  1. Если это действительно большой подъем на вашей стороне, проверьте, не содержат ли входящие RTP-пакеты какой-либо другой дополнительной информации, которая могла бы позволить вам сделать вывод, является ли это аудио- или видеоканалом.
person Aki    schedule 26.02.2013