Closed Bug 1258930 Opened 9 years ago Closed 9 years ago

Answer from Firefox should contain H264 codecs if offer contains H264 codecs .

Categories

(Core :: WebRTC, defect)

Product:
Core
Component:
WebRTC
Version:
45 Branch
Platform:
All
Windows 8
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: rohitnine, Unassigned)

Details

Expected : If offer to Firefox contains ,H264 CODEC , the answer should also contain H264 CODEC Actual : Answer DOES NOT contain H264 CODEC , instead it contains VP8 CODEC. Steps : Set the offer descriptor on mozilla with H264 CODECS : (OFFER SDP) s=- t=0 0 a=ice-lite m=audio 64146 RTP/SAVPF 106 0 8 100 102 96 97 9 101 111 98 99 105 3 107 108 109 4 18 110 103 104 112 113 114 c=IN IP4 10.255.76.51 b=TIAS:64000 b=AS:41 a=sendrecv a=rtpmap:106 AMR-WB/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:100 SILK/8000 a=fmtp:100 useinbandfec=0 a=rtpmap:102 SILK/16000 a=fmtp:102 useinbandfec=0 a=rtpmap:96 EVS/16000/1 a=fmtp:96 evs-mode-switch=1;mode-change-capability=2;max-red=0 a=rtpmap:97 opus/48000/2 a=fmtp:97 maxaveragebitrate=20000;maxplaybackrate=16000;sprop-maxcapturerate=16000 a=rtpmap:98 opus/48000/2 a=fmtp:98 maxaveragebitrate=12000;maxplaybackrate=8000;sprop-maxcapturerate=8000 a=rtpmap:9 g722/8000/1 a=ptime:20 a=rtpmap:99 EVS/16000/1 a=fmtp:99 bw=nb a=rtpmap:101 EVS/16000/1 a=fmtp:101 bw=wb a=rtpmap:103 EVS/16000/1 a=fmtp:103 bw=swb a=rtpmap:104 EVS/16000/1 a=fmtp:104 bw=fb a=rtpmap:105 GSM-EFR/8000 a=maxptime:20 a=rtpmap:3 GSM/8000 a=rtpmap:107 GSM-HR-08/8000 a=rtpmap:108 AMR/8000/1 a=fmtp:108 mode-change-capability=2;max-red=60 a=rtpmap:109 iLBC/8000 a=fmtp:109 mode=20 a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6.3;annexa=no a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:110 AMR/8000/1 a=fmtp:110 mode-change-capability=2;max-red=60;octet-align=1 a=rtpmap:111 AMR-WB/16000/1 a=fmtp:111 mode-change-capability=2;max-red=60;octet-align=1 a=rtpmap:112 telephone-event/8000 a=rtpmap:113 telephone-event/16000 a=rtpmap:114 telephone-event/48000 a=fingerprint:sha-256 5A:32:29:2A:97:FD:F0:4B:70:22:E9:49:04:68:1A:B2:0D:A1:54:6D:FB:BB:0A:12:19:95:19:26:ED:1A:29:EF a=ice-pwd:61593d2f42aabe12bc2bf5 a=ice-ufrag:53d3be5b a=candidate:1 1 udp 1 10.255.76.51 64146 typ host a=candidate:1 2 udp 1 10.255.76.51 64147 typ host a=rtcp:64147 IN IP4 10.255.76.51 a=setup:actpass m=video 64148 RTP/SAVPF 96 97 98 99 c=IN IP4 10.255.76.51 a=framerate:15 a=rtpmap:96 H264/90000 a=framesize:96 352-288 a=fmtp:96 profile-level-id=42800d;packetization-mode=1 a=rtpmap:97 H264/90000 a=framesize:97 352-288 a=fmtp:97 profile-level-id=42800c;packetization-mode=1 a=rtpmap:98 H264/90000 a=framesize:98 320-240 a=fmtp:98 profile-level-id=42800c;packetization-mode=1 a=rtpmap:99 H264/90000 a=framesize:99 176-144 a=fmtp:99 profile-level-id=42900b;packetization-mode=1 a=extmap:9 urn:3gpp:video-orientation a=fingerprint:sha-256 5A:32:29:2A:97:FD:F0:4B:70:22:E9:49:04:68:1A:B2:0D:A1:54:6D:FB:BB:0A:12:19:95:19:26:ED:1A:29:EF a=ice-pwd:6a1f0ba64dc46fe22ddc41 a=ice-ufrag:235f3141 a=candidate:1 1 udp 1 10.255.76.51 64148 typ host a=candidate:1 2 udp 1 10.255.76.51 64149 typ host a=rtcp:64149 IN IP4 10.255.76.51 a=setup:actpass Step 2 . If offer description to mozilla contains H264 CODECS , the answer description contains VP8 CODECS . (ANSWER SDP) o=mozilla...THIS_IS_SDPARTA-45.0.1 3547372667031491000 0 IN IP4 127.0.0.1 s= t=0 0 a=sendrecv a=fingerprint:sha-256 FF:51:94:0A:85:C4:AD:A7:AA:6C:17:1B:C0:38:3B:3E:D8:6F:05:B2:36:2B:E1:6C:59:F5:4F:0A:7B:9D:59:D1 a=ice-options:trickle a=msid-semantic:WMS * m=audio 52005 UDP/TLS/RTP/SAVPF 0 c=IN IP4 10.143.8.199 a=candidate:0 1 UDP 2122252543 10.143.8.199 52005 typ host a=candidate:0 2 UDP 2122252542 10.143.8.199 52006 typ host a=sendrecv a=end-of-candidates a=ice-pwd:118c7655bd27ef3c8f3da00aa4c6e99f a=ice-ufrag:adf01035 a=msid:{227729c4-586d-41d9-9339-ce5ab4f7465d} {838fad24-0db8-4bce-89ce-da3ffedb25c0} a=rtcp:52006 IN IP4 10.143.8.199 a=rtpmap:0 PCMU/8000 a=setup:active a=ssrc:2355909969 cname:{b592ce28-4d92-414b-84a0-3917c63d0bfe} m=video 0 UDP/TLS/RTP/SAVPF 120 c=IN IP4 127.0.0.1 a=sendrecv a=rtpmap:120 VP8/90000
Summary: WebRTC Bug → Answer from Firefox should contain H264 codecs if offer contains H264 codecs .
Severity: major → critical
Per the H264 spec, an answer must use the same profile-level-id as the offer (excluding rules for modifying the level). As the 264 offers don't match the profile used by Firefox for H264, no H264 payload would be accepted, and so it accepts VP8. Answerers can accept any one or more (or none) of the payloads offered. So answering with VP8 to that offer is *always* valid.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
I agree that profile-level-id used is NOT MATCHING . But in offer we DO NOT have VP8 codec at all . Then why mozilla is answering with VP8.
Aha. You misunderstand - we did not accept VP8. We rejected H.264 by returning port 0. When we do so, we're required to provide a payload, however the value is basically irrelevant and nothing I know of in the spec constrains it (since the entire m-line has been rejected). It might be marginally better (or less likely to be confusing) to return an offered payload -- but it shouldn't matter.
(In reply to Randell Jesup [:jesup] from comment #1) > Per the H264 spec, an answer must use the same profile-level-id as the offer > (excluding rules for modifying the level). As the 264 offers don't match the > profile used by Firefox for H264, no H264 payload would be accepted, and so > it accepts VP8. > > Answerers can accept any one or more (or none) of the payloads offered. So > answering with VP8 to that offer is *always* valid. What are the supported profile-level ids for H264? I'm having this issue too, in the offer we are getting the following profile levels: 42800c 42800b And firefox answer is the same described from Randell.
(In reply to joao.cpp.sca from comment #4) > (In reply to Randell Jesup [:jesup] from comment #1) > > Per the H264 spec, an answer must use the same profile-level-id as the offer > > (excluding rules for modifying the level). As the 264 offers don't match the > > profile used by Firefox for H264, no H264 payload would be accepted, and so > > it accepts VP8. > > > > Answerers can accept any one or more (or none) of the payloads offered. So > > answering with VP8 to that offer is *always* valid. > > What are the supported profile-level ids for H264? > I'm having this issue too, in the offer we are getting the following profile > levels: > > 42800c > 42800b > > And firefox answer is the same described from Randell. 42800c is not correct for constrained baseline -- it's plain Baseline. - Firefox currently uses 42e0xx (constrained baseline, and set2 set as well, which is Constrained Baseline additionally constrained by set2 -- Extended profile - conforms to A.2.3 in the spec). The extra constraint is largely irrelevant in practice, but causes negotiation problems since profile and constraints need to match (level has separate rules). 42C00C would be plain Constrained Baseline level 1.2. We inherited the 42e0 from somewhere (archaeology says SIPCC, our original SIP stack transformed into JSEP, since removed and largely replaced by a native JSEP impl), but I think was based on an old misreading of the H264 spec. We should probably start offering alternative payloads for 42c0xx, and eventually remove 42e0xx (we need to keep them for a while (around a year or so) for backwards compatibility.) In the meantime you should support answering with 42e0xx if we offer 42e0xx. If offering, it would be best to offer both 4280 and 42e0 (on different payload values). We should also look to add Constrained High Profile 1.3 when it's supported in OpenH264
(In reply to Randell Jesup [:jesup] from comment #5) > (In reply to joao.cpp.sca from comment #4) > > (In reply to Randell Jesup [:jesup] from comment #1) > > > Per the H264 spec, an answer must use the same profile-level-id as the offer > > > (excluding rules for modifying the level). As the 264 offers don't match the > > > profile used by Firefox for H264, no H264 payload would be accepted, and so > > > it accepts VP8. > > > > > > Answerers can accept any one or more (or none) of the payloads offered. So > > > answering with VP8 to that offer is *always* valid. > > > > What are the supported profile-level ids for H264? > > I'm having this issue too, in the offer we are getting the following profile > > levels: > > > > 42800c > > 42800b > > > > And firefox answer is the same described from Randell. > > 42800c is not correct for constrained baseline -- it's plain Baseline. - > Firefox currently uses 42e0xx (constrained baseline, and set2 set as well, > which is Constrained Baseline additionally constrained by set2 -- Extended > profile - conforms to A.2.3 in the spec). The extra constraint is largely > irrelevant in practice, but causes negotiation problems since profile and > constraints need to match (level has separate rules). > > 42C00C would be plain Constrained Baseline level 1.2. > > We inherited the 42e0 from somewhere (archaeology says SIPCC, our original > SIP stack transformed into JSEP, since removed and largely replaced by a > native JSEP impl), but I think was based on an old misreading of the H264 > spec. We should probably start offering alternative payloads for 42c0xx, > and eventually remove 42e0xx (we need to keep them for a while (around a > year or so) for backwards compatibility.) > > In the meantime you should support answering with 42e0xx if we offer 42e0xx. > If offering, it would be best to offer both 4280 and 42e0 (on different > payload values). > > We should also look to add Constrained High Profile 1.3 when it's supported > in OpenH264 Thanks for the explanation. I've made a simple modification to change the offered baseline: from 80 to e0 and interestingly it works correctly.
You need to log in before you can comment on or make changes to this bug.