WebRTC(使用 gstreamer 和 webrtcbin)适用于 VP9 但不适用于 H264
WebRTC (using gstreamer and webrtcbin) works with VP9 but not with H264
我有一个 c++ 应用程序,它使用 gstreamer 从摄像机获取 RTSP 和 H264 格式的视频,然后使用 webrtcbin 重新发送视频。当使用 VP9 编码时,我遵循了此 link and I can see the video trough firefox (with the tips suggested in this post) 中的示例。
我用过的管道是:
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
虽然我听从了the post的建议),但我看不到使用Chrome的视频,但是从chrome://webrtc-internals/中的统计数据可以清楚我正在获取视频,但 chrome 不显示视频。
独立于浏览器,我在流式传输和观看 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 正在获取数兆字节的数据,但我看不到视频。
谈判的答案是:
火狐
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
Chrome
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\"
的内容来尝试愚弄浏览器,但它仅在某些情况下有用。
我有一个 c++ 应用程序,它使用 gstreamer 从摄像机获取 RTSP 和 H264 格式的视频,然后使用 webrtcbin 重新发送视频。当使用 VP9 编码时,我遵循了此 link and I can see the video trough firefox (with the tips suggested in this post) 中的示例。
我用过的管道是:
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
虽然我听从了the post的建议),但我看不到使用Chrome的视频,但是从chrome://webrtc-internals/中的统计数据可以清楚我正在获取视频,但 chrome 不显示视频。
独立于浏览器,我在流式传输和观看 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 正在获取数兆字节的数据,但我看不到视频。
谈判的答案是:
火狐
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
Chrome
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\"
的内容来尝试愚弄浏览器,但它仅在某些情况下有用。