[Webkit-unassigned] [Bug 202592] New: H264 packetization-mode 0 or 1 support should be reflected in SDP seperately

Fri Oct 4 11:46:51 PDT 2019

https://bugs.webkit.org/show_bug.cgi?id=202592

            Bug ID: 202592
           Summary: H264 packetization-mode 0 or 1 support should be
                    reflected in SDP seperately
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: All
                OS: macOS 10.14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lcheng at compunetix.com
                CC: youennf at gmail.com

The failure senario was, we configured our MCU to accept packetization-mode 0. Then our WebRTC client on Safari just fail immediately. It says "InvalidAccessError: Failed to set remote answer sdp: Failed to set remote video description send parameters." It seems that Safari accept packetization-mode 1 only. However, packetization-mode 1 capability should implicitly support packetization-mode 0, shouldn't it? Then we tested to play a packetization-mode 0 video on Safari, and that works. So, could you clarify if Safari supports packetization-mode 0 or not? If it does, why do I see that failure error? Also, my colleague Justin believes you should have individual a=fmtp lines for each packetization mode that you support. Please read the following message:

Per my colleague Justin:

Hello, I’d like to report an issue with iOS 13 and the matching Safari build for mobile devices as well as OS X 10.14.6 with Safari 13. During our testing we have found that the SDP supplied by your WebRTC library is incorrect (see SDP below). I have also included two paragraphs from RFC 6184 that will help explain what is wrong. First, in the SDP generated from the browser we see the H.264 packetization mode 1 listed for two different H.264 capabilities. The issue is that support for the single NAL unit mode 0 packetization is not listed. According to the standard (section 6.2) all receivers must support the single NAL unit mode 0 packetization. Which can be signaled by leaving out the packetization-mode parameter, or setting it to 0. Also if you look at the description for the packetization-mode parameter from section 8.1 it says that for each packetization supported you must have a separate fmtp line or “configuration point” as they call it. Which would mean if Apple supports mode 0 and mode 1 then they must have 4 separate fmtp lines in the SDP to correctly signal the two H.264 capabilities they support. Instead of the two that are currently there which indicate support for the mode 1 packetization only.

v=0
o=- 8950189586340287026 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
a=group:BUNDLE 0 1
m=audio 53920 UDP/TLS/RTP/SAVPF 9 0 8
c=IN IP4 164.52.242.49
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtcp:51582 IN IP4 164.52.242.49
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:actpass
a=mid:0
a=msid:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
08d1a7d3-72cf-49c3-9616-32c107317349
a=sendrecv
a=ice-ufrag:Vpck
a=ice-pwd:XXLchxH6w/TO/sV/HbzA4UOM
a=fingerprint:sha-256 C9l44lEC:E9l0El89lB6lC3l18lFDl1El71lC6lBFl82l3Al
10lB4l9D:BA:F3lDBl2Al8Fl4Dl48lBAl27l8Dl6Al9F:F5
a=candidate:1551725144 1 udp 2113937151 10.4.35.76 55419 typ host generation
0 network-cost 999
a=candidate:842163049 1 udp 1677729535 164.52.242.130 55419 typ srflx raddr
10.4.35.76 rport 55419 generation 0 network-cost 999
a=candidate:385583182 1 udp 33562623 164.52.242.49 53920 typ relay raddr
164.52.242.130 rport 55419 generation 0 network-cost 999
a=ssrc:648368737 cname:33DXolPQ9CtlzMnF
a=ssrc:648368737 msid:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
08d1a7d3-72cf-49c3-9616-32c107317349
a=ssrc:648368737 mslabel:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
a=ssrc:648368737 label:08d1a7d3-72cf-49c3-9616-32c107317349
a=rtcp-mux
m=video 63606 UDP/TLS/RTP/SAVPF 96 98 100
c=IN IP4 164.52.242.49
b=ASl1024
b=TIASl1024000
a=rtpmap:96 H264/90000
a=rtpmap:98 H264/90000
a=rtpmap:100 VP8/90000
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-levelid=
640c1f;x-google-start-bitrate=1024
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-levelid=
42e01f;x-google-start-bitrate=1024
a=fmtp:100 x-google-start-bitrate=1024
a=rtcp:55403 IN IP4 164.52.242.49
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-ccextensions-
01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:actpass
a=mid:1
a=msid:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0 c9e2ff72-
ba62-4124-8e16-2c72ee9f119f
a=sendrecv
a=ice-ufrag:Vpck
a=ice-pwd:XXLchxH6w/TO/sV/HbzA4UOM
a=fingerprint:sha-256 C9l44lEC:E9l0El89lB6lC3l18lFDl1El71lC6lBFl82l3Al
10lB4l9D:BA:F3lDBl2Al8Fl4Dl48lBAl27l8Dl6Al9F:F5
a=candidate:1551725144 1 udp 2113937151 10.4.35.76 60412 typ host generation
0 network-cost 999
a=candidate:842163049 1 udp 1677729535 164.52.242.130 60412 typ srflx raddr
10.4.35.76 rport 60412 generation 0 network-cost 999
a=candidate:385583182 1 udp 33562623 164.52.242.49 63606 typ relay raddr
164.52.242.130 rport 60412 generation 0 network-cost 999
a=ssrc:486170583 cname:33DXolPQ9CtlzMnF
a=ssrc:486170583 msid:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0 c9e2ff72-
ba62-4124-8e16-2c72ee9f119f
a=ssrc:486170583 mslabel:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
a=ssrc:486170583 label:c9e2ff72-ba62-4124-8e16-2c72ee9f119f
a=ssrc:857398219 cname:33DXolPQ9CtlzMnF
a=ssrc:857398219 msid:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0 c9e2ff72-
ba62-4124-8e16-2c72ee9f119f
a=ssrc:857398219 mslabel:c9cbbd9b-3ae1-4ba1-b0db-b0b7409c27f0
a=ssrc:857398219 label:c9e2ff72-ba62-4124-8e16-2c72ee9f119f
a=ssrc-group:FID 486170583 857398219
a=rtcp-mux
a=rtcp-rsize

IETF rfc6184
RTP Payload Format for H.264 Video
https://tools.ietf.org/html/rfc6184

6.2.  Single NAL Unit Mode
   This mode is in use when the value of the OPTIONAL packetization-mode
   media type parameter is equal to 0 or the packetization-mode is not
   present.  “All receivers MUST support this mode.”  It is primarily
   intended for low-delay applications that are compatible with systems
   using ITU-T Recommendation H.241 [3] (see Section 12.1).  Only single
   NAL unit packets MAY be used in this mode.  STAPs, MTAPs, and FUs
   MUST NOT be used.  The transmission order of single NAL unit packets
   MUST comply with the NAL unit decoding order.

8.1.  Media Type Registration
…
packetization-mode:
         This parameter signals the properties of an RTP payload type or
         the capabilities of a receiver implementation.  “Only a single
         configuration point can be indicated; thus, when capabilities
         to support more than one packetization-mode are declared,
         multiple configuration points (RTP payload types) must be used.”

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191004/43f1159b/attachment-0001.html>