this leads to Firefox ignoring Chrome's offer of H264.

https://github.com/fippo/testbed/tree/rawh264issue shows a test with the issue. Clone the repo, npm i, put a firefox openh264 so into the h264profile directory) and npm start (jansson can help if there are issues).
Munging the missing fmtp in the middle of things makes things work.

If that is easier: the same failure happens on apprtc with chrome offering and ?vsc=H264&vrc=H264 set in the url parameter. 

We wouldn't ignore it for lack of an fmtp line with packetization-mode=1 -- though packetization mode 1 is preferred by most devices overall for interactive H.264.

If interop isn't working, it's probably because we're being pedantic about matching the profile-level-id according to the spec - 42e0xx doesn't match (per the spec) with (say) 4280xx or 4200xx (different constraints on baseline).

It would help if the full SDP was included from both ends

If Firefox doesn't accept packetization mode 0 despite advertising it, that's a problem.

Can someone with the testbed running quote the full a=fmtp lines from both the offer and the answer when setting up chrome->firefox calls?

TODO
- do we send packetization mode 0 or 1?
- do we accept packetization mode 0, 1 or both when we have negotiated packetization mode 0?
- can we fix this bug by negotiating packetization mode 1?

attached are webrtc-internals dumps from sessions with both chrome and firefox being the offerer. The chrome-offer fails, probably, as Randell points out, because chrome does not send any profile-level-id.

From the Firefox offer it seems that the h264 variant with packetization-mode=1 and PT=126 is picked by Chrome. I'll see if I can munge things to check that PT=97 works too.

Deleted: chrome_h264offer.json 173 KB

chrome_h264offer.json 173 KB View Download

Deleted: firefox_h264offer.json 79.9 KB

firefox_h264offer.json 79.9 KB View Download

hrm. Not sure if I am even seeing H264 at all when not munging. The googCodecName stats suggests VP8 so Firefox doesn't even use the H264 chrome picks -- works when enabling https://github.com/fippo/testbed/commit/62fb6a3a287dd1c3f52fda95c439a1011510b0ae#diff-1f9dbb19ecd8ca348a4b7045422110ecR62

at least with SDP munging I see video from chrome to Firefox with googCodecName=h264 both with and without packetization mode 1.

I think to really fix this bug you need to offer both modes in the SDP with different payload types and fmtp lines. The short-term solution would be to pick one and add a fmtp line.

Thanks, Philipp! I think I'll start by only offering packetization mode 1, it being the one mandated by the spec, and then work on offering both as a lower priority goal.

https://tools.ietf.org/html/rfc6184#section-6.2 says that all receivers MUST support packetization mode 0. I suggest offering mode 1 only, and filing a new bug to support packetization mode 0.

I've been having the same issue of trying to stream some video from WebRTC standalone to Firefox with h264. It works for streaming to Chrome, but not Firefox which simply shows no video, despite seeming to accept the SDP answer.

The answer SDP sent to FF is missing the FMTP packetization lines for 126 and 97, which I've suspected was the cause.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/a6b99448eec51527eca0bc59f6da71061d02e807

commit a6b99448eec51527eca0bc59f6da71061d02e807
Author: hta <hta@webrtc.org>
Date: Tue Apr 12 17:29:17 2016

Generate FMTP parameters for the H.264 codec.

This CL generates FMTP parameters that allow H.264 interoperation
with Firefox for the default codec list.

BUG= chromium:591971 

Review URL: https://codereview.webrtc.org/1880963002

Cr-Commit-Position: refs/heads/master@{#12333}

[modify] https://crrev.com/a6b99448eec51527eca0bc59f6da71061d02e807/webrtc/api/webrtcsdp.cc
[modify] https://crrev.com/a6b99448eec51527eca0bc59f6da71061d02e807/webrtc/api/webrtcsdp_unittest.cc
[modify] https://crrev.com/a6b99448eec51527eca0bc59f6da71061d02e807/webrtc/media/base/mediaconstants.cc
[modify] https://crrev.com/a6b99448eec51527eca0bc59f6da71061d02e807/webrtc/media/base/mediaconstants.h
[modify] https://crrev.com/a6b99448eec51527eca0bc59f6da71061d02e807/webrtc/media/engine/webrtcvideoengine2.cc

+CC pbos. Making hta the owner for the time being to indicate who is working on this atm.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

Please merge your change to M51 branch 2704 ASAP (before 5:00 PM PST, today) so we can take it in for M51 last Dev release tomorrow.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/9b89249e81ab81830d780c9926dfd8242afa66ed

commit 9b89249e81ab81830d780c9926dfd8242afa66ed
Author: Harald Alvestrand <hta@google.com>
Date: Tue Apr 19 08:57:03 2016

FMTP parameters for the H.264 codec (merged)

CL 2:
Don't write spaces after semicolons in FMTP lines.

Reference: RFC 6184 section 8.2.1 and examples.

BUG= webrtc:5793 

Review URL: https://codereview.webrtc.org/1888373002

Cr-Commit-Position: refs/heads/master@{#12383}
(cherry picked from commit 62a216ee1e7359882b1b7d084a6897746ad0dd20)

CL 1:
Generate FMTP parameters for the H.264 codec.

This CL generates FMTP parameters that allow H.264 interoperation
with Firefox for the default codec list.

BUG= chromium:591971 

Review URL: https://codereview.webrtc.org/1880963002

Cr-Commit-Position: refs/heads/master@{#12333}
(cherry picked from commit a6b99448eec51527eca0bc59f6da71061d02e807)

R=tommi@webrtc.org

Review URL: https://codereview.webrtc.org/1898063002 .

Cr-Commit-Position: refs/branch-heads/51@{#3}
Cr-Branched-From: 5045337133d1da4a657b99e0590eb401515163bd-refs/heads/master@{#12279}

[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/api/objctests/RTCSessionDescriptionTest.mm
[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/api/webrtcsdp.cc
[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/api/webrtcsdp_unittest.cc
[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/media/base/mediaconstants.cc
[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/media/base/mediaconstants.h
[modify] https://crrev.com/9b89249e81ab81830d780c9926dfd8242afa66ed/webrtc/media/engine/webrtcvideoengine2.cc

Per comment #19, this is already merged to M51. So removing "Merge-Approved-51" label.