Or: H264 codec isn't always available even after waiting when doing things like mozregression While trying to repro various issues around WebRTC using H264, I came across this error a lot. I tried doing a mozregression on it, since it appeared to either happen every time or not at all, but it seems arbitrary as none of the ranges make sense. Maybe this is could be some unreported failure of failing to pull down the openH264 plugin, since mozregression I believe starts from the same profile starting point by default? But aren't we supposed to be using MS STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV): 1. Open https://jsfiddle.net/jib1/02j8q6h9/show (leave ☑h264 checked) 2. Hit the `gUM!` button (and allow camera) Expected results: - two videos appear (receiver and sender) Actual result: ``` Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp: v=0 o=mozilla...THIS_IS_SDPARTA-99.0 6807228323487549301 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 E5:A3:84:D9:A0:FD:2F:5D:76:B1:8F:1C:A6:27:B8:EC:D4:94:43:FF:02:05:0B:31:F2:87:9D:93:00:84:13:EC a=group:BUNDLE 0 a=ice-options:trickle a=msid-semantic:WMS * m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:5 urn:ietf:params:rtp-hdrext:toffset a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:124 apt=120 a=fmtp:121 max-fs=12288;max-fr=60 a=fmtp:125 apt=121 a=ice-pwd:11cba9cf8403403446cf3db31730584b a=ice-ufrag:31cb9670 a=mid:0 a=msid:- {36d47d96-b735-4d9a-9edd-904d17d15f69} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 goog-remb a=rtcp-fb:120 transport-cc a=rtcp-fb:121 nack a=rtcp-fb:121 nack pli a=rtcp-fb:121 ccm fir a=rtcp-fb:121 goog-remb a=rtcp-fb:121 transport-cc a=rtcp-mux a=rtcp-rsize a=rtpmap:120 VP8/90000 a=rtpmap:124 rtx/90000 a=rtpmap:121 VP9/90000 a=rtpmap:125 rtx/90000 a=setup:actpass a=ssrc:1870026881 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc:4270559034 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc-group:FID 1870026881 4270559034 ``` Only observed on Windows 10.
Bug 1766037 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Or: H264 decoder isn't always available even after waiting when doing things like mozregression While trying to repro various issues around WebRTC using H264, I came across this error a lot. I tried doing a mozregression on it, since it appeared to either happen every time or not at all, but it seems arbitrary as none of the ranges make sense. Maybe this is could be some unreported failure of failing to pull down the openH264 plugin, since mozregression I believe starts from the same profile starting point by default? But aren't we supposed to be using MS STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV): 1. Open https://jsfiddle.net/jib1/02j8q6h9/show (leave ☑h264 checked) 2. Hit the `gUM!` button (and allow camera) Expected results: - two videos appear (receiver and sender) Actual result: ``` Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp: v=0 o=mozilla...THIS_IS_SDPARTA-99.0 6807228323487549301 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 E5:A3:84:D9:A0:FD:2F:5D:76:B1:8F:1C:A6:27:B8:EC:D4:94:43:FF:02:05:0B:31:F2:87:9D:93:00:84:13:EC a=group:BUNDLE 0 a=ice-options:trickle a=msid-semantic:WMS * m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:5 urn:ietf:params:rtp-hdrext:toffset a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:124 apt=120 a=fmtp:121 max-fs=12288;max-fr=60 a=fmtp:125 apt=121 a=ice-pwd:11cba9cf8403403446cf3db31730584b a=ice-ufrag:31cb9670 a=mid:0 a=msid:- {36d47d96-b735-4d9a-9edd-904d17d15f69} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 goog-remb a=rtcp-fb:120 transport-cc a=rtcp-fb:121 nack a=rtcp-fb:121 nack pli a=rtcp-fb:121 ccm fir a=rtcp-fb:121 goog-remb a=rtcp-fb:121 transport-cc a=rtcp-mux a=rtcp-rsize a=rtpmap:120 VP8/90000 a=rtpmap:124 rtx/90000 a=rtpmap:121 VP9/90000 a=rtpmap:125 rtx/90000 a=setup:actpass a=ssrc:1870026881 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc:4270559034 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc-group:FID 1870026881 4270559034 ``` Only observed on Windows 10.
Or: H264 codec isn't always available even after waiting when doing things like mozregression While trying to repro various issues around WebRTC using H264, I came across this error a lot. I tried doing a mozregression on it, since it appeared to either happen every time or not at all, but it seems arbitrary as none of the ranges make sense. Maybe this is could be some unreported failure of failing to pull down the openH264 plugin, since mozregression I believe starts from the same profile starting point by default? But aren't we supposed to be using MS STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV): 1. Open https://jsfiddle.net/jib1/02j8q6h9/show (leave ☑h264 checked) 2. Hit the `gUM!` button (and allow camera) Expected results: - two videos appear (receiver and sender) Actual result: ``` Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp: v=0 o=mozilla...THIS_IS_SDPARTA-99.0 6807228323487549301 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 E5:A3:84:D9:A0:FD:2F:5D:76:B1:8F:1C:A6:27:B8:EC:D4:94:43:FF:02:05:0B:31:F2:87:9D:93:00:84:13:EC a=group:BUNDLE 0 a=ice-options:trickle a=msid-semantic:WMS * m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:5 urn:ietf:params:rtp-hdrext:toffset a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:124 apt=120 a=fmtp:121 max-fs=12288;max-fr=60 a=fmtp:125 apt=121 a=ice-pwd:11cba9cf8403403446cf3db31730584b a=ice-ufrag:31cb9670 a=mid:0 a=msid:- {36d47d96-b735-4d9a-9edd-904d17d15f69} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 goog-remb a=rtcp-fb:120 transport-cc a=rtcp-fb:121 nack a=rtcp-fb:121 nack pli a=rtcp-fb:121 ccm fir a=rtcp-fb:121 goog-remb a=rtcp-fb:121 transport-cc a=rtcp-mux a=rtcp-rsize a=rtpmap:120 VP8/90000 a=rtpmap:124 rtx/90000 a=rtpmap:121 VP9/90000 a=rtpmap:125 rtx/90000 a=setup:actpass a=ssrc:1870026881 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc:4270559034 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc-group:FID 1870026881 4270559034 ``` Only observed on Windows 10.
Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp While trying to repro various issues around WebRTC using H264, I came across this error a lot. I tried doing a mozregression on it, since it appeared to either happen every time or not at all, but it seems arbitrary as none of the ranges make sense. Maybe this is could be some unreported failure of failing to pull down the openH264 plugin, since mozregression I believe starts from the same profile starting point by default? But aren't we supposed to be using MS STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV): 1. Open https://jsfiddle.net/jib1/02j8q6h9/show (leave ☑h264 checked) 2. Hit the `gUM!` button (and allow camera) Expected results: - two videos appear (receiver and sender) Actual result: ``` Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp: v=0 o=mozilla...THIS_IS_SDPARTA-99.0 6807228323487549301 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 E5:A3:84:D9:A0:FD:2F:5D:76:B1:8F:1C:A6:27:B8:EC:D4:94:43:FF:02:05:0B:31:F2:87:9D:93:00:84:13:EC a=group:BUNDLE 0 a=ice-options:trickle a=msid-semantic:WMS * m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:5 urn:ietf:params:rtp-hdrext:toffset a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:124 apt=120 a=fmtp:121 max-fs=12288;max-fr=60 a=fmtp:125 apt=121 a=ice-pwd:11cba9cf8403403446cf3db31730584b a=ice-ufrag:31cb9670 a=mid:0 a=msid:- {36d47d96-b735-4d9a-9edd-904d17d15f69} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 goog-remb a=rtcp-fb:120 transport-cc a=rtcp-fb:121 nack a=rtcp-fb:121 nack pli a=rtcp-fb:121 ccm fir a=rtcp-fb:121 goog-remb a=rtcp-fb:121 transport-cc a=rtcp-mux a=rtcp-rsize a=rtpmap:120 VP8/90000 a=rtpmap:124 rtx/90000 a=rtpmap:121 VP9/90000 a=rtpmap:125 rtx/90000 a=setup:actpass a=ssrc:1870026881 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc:4270559034 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc-group:FID 1870026881 4270559034 ``` Only observed on Windows 10.
Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp While trying to repro various issues around WebRTC using H264, I came across this error a lot. I tried doing a mozregression on it, since it appeared to either happen every time or not at all, but it seems arbitrary as none of the ranges make sense. Maybe this is could be some unreported failure of failing to pull down the openH264 plugin, since mozregression I believe starts from the same profile starting point by default? But aren't we supposed to be using MS STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV): 1. Open https://jsfiddle.net/jib1/02j8q6h9/show (leave ☑h264 checked) 2. Hit the `gUM!` button (and allow camera) Expected results: - two videos appear (receiver and sender) Actual result: ``` Error: Couldn't find offset 0 of codec H264 while looking for offset 0 in sdp: v=0 o=mozilla...THIS_IS_SDPARTA-99.0 6807228323487549301 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 E5:A3:84:D9:A0:FD:2F:5D:76:B1:8F:1C:A6:27:B8:EC:D4:94:43:FF:02:05:0B:31:F2:87:9D:93:00:84:13:EC a=group:BUNDLE 0 a=ice-options:trickle a=msid-semantic:WMS * m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:5 urn:ietf:params:rtp-hdrext:toffset a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:124 apt=120 a=fmtp:121 max-fs=12288;max-fr=60 a=fmtp:125 apt=121 a=ice-pwd:11cba9cf8403403446cf3db31730584b a=ice-ufrag:31cb9670 a=mid:0 a=msid:- {36d47d96-b735-4d9a-9edd-904d17d15f69} a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 goog-remb a=rtcp-fb:120 transport-cc a=rtcp-fb:121 nack a=rtcp-fb:121 nack pli a=rtcp-fb:121 ccm fir a=rtcp-fb:121 goog-remb a=rtcp-fb:121 transport-cc a=rtcp-mux a=rtcp-rsize a=rtpmap:120 VP8/90000 a=rtpmap:124 rtx/90000 a=rtpmap:121 VP9/90000 a=rtpmap:125 rtx/90000 a=setup:actpass a=ssrc:1870026881 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc:4270559034 cname:{58bd6b8c-668b-434b-af3b-02d002e28a80} a=ssrc-group:FID 1870026881 4270559034 ``` Only observed on Windows 10.