当前位置: 首页 > 知识库问答 >
问题:

解决ffmpeg/ffplay客户端RTSP RTP UDP*多播*问题

杜翰林
2023-03-14

我在使用udp\U多播传输方法时遇到问题,该方法使用ffmpeg或ffplay作为网络摄像头的客户端。

TCP传输工作原理:

ffplay -rtsp_transport tcp rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm

UDP运输工程:

ffplay -rtsp_transport udp rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm

多播传输不工作:

ffplay -rtsp_transport udp_multicast rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm

选择udp_multicast时的错误消息如下:

[rtsp @ 0x7fd6a8000b80] Could not find codec parameters for stream 0 (Video: mjpeg, none(bt470bg/unknown/unknown)): unspecified size

使用-v调试运行:观察UDP多播信息是否出现在SDP中,即使为此运行选择的传输是单播的。单播或多播的SDP内容不变。

[tcp @ 0x7f648c002f40] Starting connection attempt to 192.168.1.100 port 554
[tcp @ 0x7f648c002f40] Successfully connected to 192.168.1.100 port 554
[rtsp @ 0x7f648c000b80] SDP:
v=0
o=- 621355968671884050 621355968671884050 IN IP4 192.168.1.100
s=/videoinput_1:0/mjpeg_3/media.stm
c=IN IP4 0.0.0.0
m=video 40004 RTP/AVP 26
c=IN IP4 237.0.0.3/1
a=control:trackID=1
a=range:npt=0-
a=framerate:25.0

Failed to parse interval end specification ''
[rtp @ 0x7f648c008e00] No default whitelist set
[udp @ 0x7f648c009900] No default whitelist set
[udp @ 0x7f648c009900] end receive buffer size reported is 425984
[udp @ 0x7f648c019c80] No default whitelist set
[udp @ 0x7f648c019c80] end receive buffer size reported is 425984
[rtsp @ 0x7f648c000b80] setting jitter buffer size to 500
[rtsp @ 0x7f648c000b80] hello state=0
Failed to parse interval end specification ''
[mjpeg @ 0x7f648c0046c0] marker=d8 avail_size_in_buf=145103 
[mjpeg @ 0x7f648c0046c0] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x7f648c0046c0] marker=e0 avail_size_in_buf=145101
[mjpeg @ 0x7f648c0046c0] marker parser used 16 bytes (128 bits)
[mjpeg @ 0x7f648c0046c0] marker=db avail_size_in_buf=145083
[mjpeg @ 0x7f648c0046c0] index=0
[mjpeg @ 0x7f648c0046c0] qscale[0]: 5
[mjpeg @ 0x7f648c0046c0] index=1
[mjpeg @ 0x7f648c0046c0] qscale[1]: 10
[mjpeg @ 0x7f648c0046c0] marker parser used 132 bytes (1056 bits)
[mjpeg @ 0x7f648c0046c0] marker=c4 avail_size_in_buf=144949
[mjpeg @ 0x7f648c0046c0] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x7f648c0046c0] marker=c0 avail_size_in_buf=144529
[mjpeg @ 0x7f648c0046c0] Changing bps from 0 to 8
[mjpeg @ 0x7f648c0046c0] sof0: picture: 1920x1080
[mjpeg @ 0x7f648c0046c0] component 0 2:2 id: 0 quant:0
[mjpeg @ 0x7f648c0046c0] component 1 1:1 id: 1 quant:1
[mjpeg @ 0x7f648c0046c0] component 2 1:1 id: 2 quant:1
[mjpeg @ 0x7f648c0046c0] pix fmt id 22111100
[mjpeg @ 0x7f648c0046c0] Format yuvj420p chosen by get_format().
[mjpeg @ 0x7f648c0046c0] marker parser used 17 bytes (136 bits)
[mjpeg @ 0x7f648c0046c0] escaping removed 676 bytes
[mjpeg @ 0x7f648c0046c0] marker=da avail_size_in_buf=144510
[mjpeg @ 0x7f648c0046c0] marker parser used 143834 bytes (1150672 bits)
[mjpeg @ 0x7f648c0046c0] marker=d9 avail_size_in_buf=2
[mjpeg @ 0x7f648c0046c0] decode frame unused 2 bytes
[rtsp @ 0x7f648c000b80] All info found vq=    0KB sq=    0B f=0/0
[rtsp @ 0x7f648c000b80] rfps: 24.416667 0.018101
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.500000 0.013298
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.583333 0.009235
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.666667 0.005910
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.750000 0.003324
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.833333 0.001477
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.916667 0.000369
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.000000 0.000000
[rtsp @ 0x7f648c000b80] rfps: 25.083333 0.000370
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.166667 0.001478
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.250000 0.003326
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.333333 0.005912
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.416667 0.009238
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.500000 0.013302
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.583333 0.018105
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 50.000000 0.000000
[rtsp @ 0x7f648c000b80] Setting avg frame rate based on r frame rate
Input #0, rtsp, from 'rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm':
  Metadata:
    title           : /videoinput_1:0/mjpeg_3/media.stm
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0, 21, 1/90000: Video: mjpeg (Baseline), 1 reference frame, yuvj420p(pc, bt470bg/unknown/unknown, center), 1920x1080 [SAR 1:1 DAR 16:9], 0/1, 25 fps, 25 tbr, 90k tbn, 90k tbc
[mjpeg @ 0x7f648c02ad80] marker=d8 avail_size_in_buf=145103

这是使用udp_multicast时相同的调试部分。SDP与前面提到的相同,SDP后面包含[mjpeg]编解码器信息的块完全丢失(以标记=d8开头)——流永远不会被识别。这会在瞬间发生,没有超时等待RTP数据包不成功的迹象,尽管这也可能只是驱动程序中的调试信息不足。另请注意,ffmpeg知道帧是MJPEG帧,颜色原色是PAL,它只是不知道大小。同样奇怪但与问题无关的是,用于流的单播UDP传输目标端口没有出现在上面显示的ffmpeg调试转储中,这意味着RTSP/RTP驱动程序的一部分隐藏了和服下的重要信息,即端口号以及它如何知道帧将是MJPEG。

[tcp @ 0x7effe0002f40] Starting connection attempt to 192.168.1.100 port 554
[tcp @ 0x7effe0002f40] Successfully connected to 192.168.1.100 port 554
[rtsp @ 0x7effe0000b80] SDP:aq=    0KB vq=    0KB sq=    0B f=0/0
v=0
o=- 621355968671884050 621355968671884050 IN IP4 192.168.1.100
s=/videoinput_1:0/mjpeg_3/media.stm
c=IN IP4 0.0.0.0
m=video 40004 RTP/AVP 26
c=IN IP4 237.0.0.3/1
a=control:trackID=1
a=range:npt=0-
a=framerate:25.0

Failed to parse interval end specification ''
[rtp @ 0x7effe0008e00] No default whitelist set
[udp @ 0x7effe0009900] No default whitelist set
[udp @ 0x7effe0009900] end receive buffer size reported is 425984
[udp @ 0x7effe0019c40] No default whitelist set
[udp @ 0x7effe0019c40] end receive buffer size reported is 425984
[rtsp @ 0x7effe0000b80] setting jitter buffer size to 500
[rtsp @ 0x7effe0000b80] hello state=0
Failed to parse interval end specification '' 
[rtsp @ 0x7effe0000b80] Could not find codec parameters for stream 0 (Video: mjpeg, 1 reference frame, none(bt470bg/unknown/unknown, center)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, rtsp, from 'rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm':
  Metadata:
    title           : /videoinput_1:0/mjpeg_3/media.stm
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0, 0, 1/90000: Video: mjpeg, 1 reference frame, none(bt470bg/unknown/unknown, center), 90k tbr, 90k tbn, 90k tbc
    nan M-V:    nan fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

这是流量的TCPDUMP。两个流中的信息看起来完全相同。

19:21:30.703599 IP 192.168.1.100.64271 > 192.168.1.98.5239: UDP, length 60
19:21:30.703734 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.703852 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704326 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704326 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704327 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704327 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704504 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704813 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704814 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704872 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 732
19:21:30.704873 IP 192.168.1.100.59869 > 237.0.0.3.40005: UDP, length 60
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705594 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705774 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 732

我希望这是一个配置问题,我可以在我的ffplay/ffmpeg行中解决这个问题,而这不是ffmpeg中的错误。谢谢你的提示。

共有1个答案

郭俊拔
2023-03-14

仅支持udp或tcp传输

[rtsp @ 000002cadaac4140] Unsupported lower transport method, only UDP and TCP are supported for output.
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Error initializing output stream 0:0 --
 类似资料:
  • 客户端播放:30秒示例 我当地的咖啡馆设有摇摇欲坠,不稳定的无线网络,并由市议会慷慨地赞助纳税人的钱。连接后,您将被重定向到一个受SSL保护的页面,提示您输入用户名和密码。输入详细信息后,您就可以自由地享受间歇性的辍学,类似难题的速度以及配置错误的透明代理。 我倾向于在第一时间使这种事情自动化,因为从长远来看,现在花费的时间将超过所花的时间。在这种情况下,我可能会使用Firebug来过滤表单发布参

  • 我们试图用任何google帐户登录我的worklight混合移动示例应用程序。 下面是创建google gmail API和创建OAuth 2.0客户端ID的屏幕截图步骤 错误日志中没有错误,只有这里引用的页面加载错误。我们得到这样的屏幕截图错误

  • CCLive直播客户端是CC视频的一款直播推流客户端,支持讲师使用电脑发起直播,学员通过电脑或手机实时观看直播。 客户端支持文档模式和大屏模式等不同模板,支持视频连麦、桌面共享、聊天问答、问卷签到等多种互动功能。 电脑及网络配置要求 在直播开始前,讲师端需先 检查电脑及网络配置 是否符合直播要求,如下: 电脑配置要求: 1)操作系统:Windows 7/8/10 2)CPU:双核 2.4G及以上

  • 问题内容: 因此,我读了一些有关扩展Socket.IO的文章。由于种种原因,我不想使用内置的Socket.IO缩放机制(大多数情况似乎效率低下,因为从我的角度来看,它向Redis发布了很多东西)。 所以我想出了一个简单的想法: 每个Socket.IO服务器都创建Redis发布/订阅/存储客户端,连接到Redis并订阅频道。现在,当我要广播数据时,我只是将其发布到Redis,所有其他Socket.I

  • 本文向大家介绍完美解决mysql客户端授权后连接失败的问题,包括了完美解决mysql客户端授权后连接失败的问题的使用技巧和注意事项,需要的朋友参考一下 在本地(192.168.1.152)部署好mysql环境,授权远程客户机192.168.1.%连接本机的mysql,在iptables防火墙也已开通3306端口。 如下: mysql> select host,user,password from

  • 我使用的是kafka-clients-0.10.1.1(单节点单代理) auto.create.topics.enable的默认值为true。 1.我正在使用以下方式向主题发送消息: 用于消费: