Каковы способы отладки некорректных ответов RTSP DESCRIBE от серверов RTSP - PullRequest
0 голосов
/ 09 июля 2020

Я пишу программное обеспечение, которое позволяет пользователям просматривать ранее записанные видео, сохраненные на NVR. Видео можно воспроизводить, вызывая RTSP-сервер для воспроизведения определенного c файла, и информация отправляется обратно через веб-сокет.

Однако, хотя большинство файлов работают, некоторые из файлов ( около 20% из них) играть не будет. Кажется, что sdpInfo, возвращенный из ответа DESCRIBE, указывает, что существует только одна дорожка, дорожка G.711A, а не дорожка H264.

Каковы некоторые причины, по которым сервер RTSP будет возвращать непоследовательно неправильные ответы для видеофайлов , и что я могу сделать, чтобы это отладить? Кажется, я не могу получить доступ к самому RTSP-серверу, поэтому я застрял в отладке этой клиентской стороны. Я проверил количество кластеров, имя файла и даже могу воспроизвести указанный отснятый материал в другом приложении. Поэтому я очень сомневаюсь, что файлы плохие, но RTSP не отправляет мне правильные ответы DESCRIBE.

Я попытался обмануть сервер, добавив информацию о видеодорожке в ответ DESCRIBE и направив ее в мой видеоплеер и на запрос SETUP, и в результате я получаю пакеты обратно в виде сообщений для моего веб-воркера, но это поток не декодируемых H264 534-байтовых данных, которые кажутся сообщениями только для аудио-воркера, и мой Video Worker никогда не получает уведомления.

Вот пример ответа DESCRIBE:

Хорошо (аудио / видео):

RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.1.199:80//mnt/dvr/2020-07-07/000/dav/07/0/1/320149/07.00.00-07.09.00[R][0@0][0].dav/
Cache-Control: must-revalidate
Content-Length: 527
Content-Type: application/sdp

v=0
o=- 2269126519 2269126519 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=0-540.000000
m=video 0 RTP/AVP 98
a=control:trackID=0
a=framerate:25.000000
a=rtpmap:98 H264/90000
a=fmtp:98 profile-id=1;sprop-sps=QgEBAQAAAwAAgAAAAwAAAwC0oAFQIAXxY2lksrZrlxAIAAADAAgAAAMAyfxYlA==;sprop-pps=RAHA4eLwMFFJ;sprop-vps=QAEMAf//AQAAAwAAgAAAAwAAAwC0pQJA
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/8000
a=recvonly

Плохо (только аудио дорожка):

RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.1.199:80//mnt/dvr/2020-07-07/000/dav/04/0/1/311166/04.00.00-05.00.00[R][0@0][0].dav/
Cache-Control: must-revalidate
Content-Length: 261
Content-Type: application/sdp

v=0
o=- 2269129531 2269129531 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=0-3600.000000
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/8000
a=recvonly

Это пример плохого RTSP-пакета (с разрывами строки):

$DHAV�-;��Q6�F��X��������������UU�������������������U�����UUUU��U�U
�U��U�U����UU�U��UUU��UUUUU�UUUUU���UUUU�UUUUUU�UUUUU�UU�U����UUU�UU�UUU��
UUUUU������������U����U�U���UUU������U���UU�U����U�����������U�U�U�UUU��UU
UUU�U�UU��UU�UUUU�UUUUUUU�U�UUU�U�UU�UUUU�U��U�U�U��U�U����U�UU��UUU����U�
�U���UUUU�����UU�UUUU�UUUUU�����UU���U�UUU��UUUU�UUUUU����UUUUUUUU�U��UUUU
U��UUU��UUUUUUU�UUUUUUUUU��UUUUU��U�UUU�UUUUUU�UU�����U�������������U�����
��U�����U�U�U�UU�����UU���U�U����UUUU��UUUUUUUUUUU��UUUUUU�UUUUdhav

И наглядный пример: Изображение в инспекторе

1 Ответ

0 голосов
/ 18 июля 2020

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

...