1037910 - H264 fmtp files have 0 for the payload value unless you set a max_fs or max_fr pref

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

H264 SDP a=fmtp values have a 0 for the payload instead of 126 or 97, unless you have max_fs or max_fr set.  This was exposed by the latest change to H264 SDP (that removed mode 0, among other changes, and fixed a bug that forced fmtp values for vp8). 

The fix is clear - move the setting of the payload to occur no matter which place we create the fmtp.

Should be considered to 2.0, though for OMX H.264 we need to set max_fs, so that wallpapers over this bug.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Set H264 FMTP payload value even if max_fs/fr aren't set

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8454953 [details] [diff] [review]
Set H264 FMTP payload value even if max_fs/fr aren't set

f+ ekr, r+ ehugg on irc

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b4396d308894

Comment 4

[bhavana bajaj [:bajaj]]

jesup,

Can you explain how not uplifting this bug would result in for an end user to consider it a blocker for 2.0?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

I'm not certain we need it for 2.0.  OMX H.264 for the 8x10 requires use of a max_fs value (max framesize), which makes the code avoid the bug.  If a partner tried to merge OpenH264 into 2.0, or used a different OMX H.264 hardware setup and didn't set max_fs, it would fail.  However, in that case they could workaround it by setting max_fs to the default value for the h.264 level supported.

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b4396d308894

Comment 7

[bhavana bajaj [:bajaj]]

(In reply to Randell Jesup [:jesup] from comment #5)
> I'm not certain we need it for 2.0.  OMX H.264 for the 8x10 requires use of
> a max_fs value (max framesize), which makes the code avoid the bug.  If a
> partner tried to merge OpenH264 into 2.0, or used a different OMX H.264
> hardware setup and didn't set max_fs, it would fail.  However, in that case
> they could workaround it by setting max_fs to the default value for the
> h.264 level supported.

OK, in that case. I'll not block but I could request aurora approval here and get this fixed in our platform code if this is low risk.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

For desktop, 32 isn't important since OpneH264 is targeted to 33.  Thanks.