Как изменить тип полезной нагрузки rtp при использовании gst-launch с rtph264pay
Я транслирую h264 из файла с помощью gst для python и запускаю отправку видео с помощью gst.parse_launch(...). Мне нужно изменить тип полезной нагрузки на 35 по умолчанию 96. В соответствии с примерами и документацией кажется, что можно сделать это, установив свойство pt в rtph264pay, "rtph264pay pt = 35". ПРИМЕЧАНИЕ: BOSCH использовал 35 при отправке данных h264.
Если установить значение в диапазоне от 0 до 95, при проверке пакета rtp в wireshark я вижу, что он все еще установлен на 96. Установка значения выше 95 принимается и попадает в отправленный пакет rtp.
Другой вопрос здесь - попытаться достичь почти того же, но на принимающей стороне и реализовать на C, а не на python. Gstreamer, rtspsrc и тип полезной нагрузки
Пример из документации: https://gstreamer.freedesktop.org/documentation/tools/gst-launch.html См. Сетевая трансляция
Базовый класс полезной нагрузки rtp имеет свойство: https://www.freedesktop.org/software/gstreamer-sdk/data/docs/latest/gst-plugins-base-libs-0.10/gst-plugins-base-libs-gstbasertppayload.html
Производный класс полезной нагрузки h264, по-видимому, имеет ограничение диапазона pt: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtph264pay.html
Мои аргументы командной строки для gst-launch выглядят так:
video / x-h264, ширина =352, высота =288, частота кадров =(фракция)25/1! идентичность время сна =15000 синхронизация = правда! h264parse! rtph264pay config-interval=1 pt=35! очередь! udpsink sync=true
Есть идеи как обойти это? Нужно ли исправлять функцию установки свойств pt или есть менее инвазивный способ?
Обновления: я не могу найти, где в коде происходит фактическое применение>95, реализация rtph264pay даже не упоминает свойство pt, а реализация rtpbasepayload, похоже, не налагает никаких других ограничений на свойство, кроме min(0) и max(127), все остальные операции являются просто присваиваниями, которые в итоге оказываются в заголовке пакета rtp.
g_object_class_install_property (G_OBJECT_CLASS (klass), PROP_PT,
g_param_spec_uint ("pt", "payload type",
"The payload type of the packets", 0, 0x7f, DEFAULT_PT,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
С включенным выходом отладки (pay: 6) можно заметить, что он говорит об использовании равноправного pt 96, к сожалению, при настройке pt=35(которая устанавливается по умолчанию 96) вывод точно (кроме фактического #) совпадает с pt =. 97, который сохраняет pt=97, так что никоим образом не указывает, что запрошенное значение было заменено значением по умолчанию.
Используя pt=35:
rtpbasepayload gstrtpbasepayload.c:843:gst_rtp_base_payload_negotiate:<rtph264pay0> using peer pt 96
...
rtpbasepayload gstrtpbasepayload.c:901:gst_rtp_base_payload_negotiate:<rtph264pay0> with peer caps: application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)"Z2QAFKzZQXCH5v/AXEBcBAAUXYwExLQCPFCmWA\=\=\,aOvssiw\=", payload=(int)96, ssrc=(uint)23420509, timestamp-offset=(uint)66866867, seqnum-offset=(uint)11269
против использования pt=97:
rtpbasepayload gstrtpbasepayload.c:843:gst_rtp_base_payload_negotiate:<rtph264pay0> using peer pt 97
...
rtpbasepayload gstrtpbasepayload.c:901:gst_rtp_base_payload_negotiate:<rtph264pay0> with peer caps: application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)"Z2QAFKzZQXCH5v/AXEBcBAAUXYwExLQCPFCmWA\=\=\,aOvssiw\=", payload=(int)97, ssrc=(uint)23420509, timestamp-offset=(uint)66866867, seqnum-offset=(uint)11269