我有一个c++应用程序，它使用gstreamer从相机获取RTSP和H264格式的视频，并使用webrtcbin重新发送视频。我遵循了这个链接中的示例，当使用VP9编码时，我可以通过firefox看到视频(带有本文中建议的技巧(。
我使用的管道是：
rtspsrc location=rtsp://192.168.1.162/z3-1.mp4 ! application/x-rtp,encoding-name=H264 ! rtph264depay ! nvv4l2decoder ! nvv4l2vp9enc ! video/x-vp9 ! rtpvp9pay ! application/x-rtp,media=video,clock-rate=90000,encoding-name=VP9,payload=96,framerate=25/1 ! webrtcbin async-handling=true name=sendrecv
虽然我遵循了帖子中的建议(，但我看不到使用Chrome的视频，但从中的统计数据来看chrome://webrtc-internals/很明显，我得到了视频，但铬没有显示视频。
独立于浏览器，我有一些问题流媒体和观看视频在4k。因此，我决定取消VP9编码(以加快处理速度(，并直接在H264中从相机重新发送数据。要做到这一点，我使用管道：
rtspsrc location=rtsp://192.168.1.162/z3-1.mp4 ! application/x-rtp,encoding-name=H264 ! webrtcbin async-handling=true name=sendrecv
在使用这个管道之后，我没有在firefox或chrome中看到视频。有趣的是，如果我用firefox分析流量，浏览器似乎没有得到任何数据。然而，在这种情况下，chrome获得了MB的数据，但我没有看到视频。
谈判的答案是：
Firefox
v=0
o=mozilla...THIS_IS_SDPARTA-95.0.2 5069762040601189414 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 ED:70:D8:AF:49:E9:B1:F8:47:83:1B:2B:13:D3:67:AD:F6:43:9D:36:59:8B:74:93:34:1D:AB:D5:67:1A:E4:07
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 0 UDP/TLS/RTP/SAVPF 120
c=IN IP4 0.0.0.0
a=inactive
a=mid:video0
a=rtpmap:120 VP8/90000
铬
v=0
o=- 2541702691192041899 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ssce
a=ice-pwd:eWXfMAvg/KEFxesG2nS3aNTt
a=ice-options:trickle
a=fingerprint:sha-256 E0:79:E1:50:F6:9F:CB:8B:80:8A:40:5A:B9:1B:35:27:EF:A2:45:EC:A1:A7:58:B5:24:98:0C:8D:B0:41:3B:1C
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
你知道firefox或chrome中没有视频吗？任何提示都会非常有用。非常感谢！
浏览器仅支持baseline profile编码的h264流的一个可能原因。您可以尝试在rtph264pay和webrtcbin之间添加类似capssetter caps="application/x-rtp,profile-level-id=(string)42c015"的内容来欺骗浏览器，但这只会在某些情况下有所帮助。