Chrome 56 h264 profile-level-id parsing errors

[Eric Green]

Hi all,

We are having some difficulty with Chrome 56. I understand that profile-level-id parsing was added as part of Chrome 56. This appears to have broken interop with some h264 endpoints that were working previously.

If Chrome receives a profile that it does not handle it rejects the SDP as a whole with the message: DOMException: Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters..

It appears that Chrome h264 renderer is only supporting the baseline-constrained profile (42E01F). I am not sure if this has changed from 54 to 56. I have tried mucking with the profile in the SDP before passing it to the browser to see if that resolves my issue. This works with a minority of endpoints fully. While the browser no longer flat out rejects the modified SDP, it does not render the video, and therefore does not render the audio. Here is a gist of sample SDP offers from h264 capable endpoints: https://gist.github.com/egreenmachine/f9f55c71b3fb35a30a59737264add39e. Additionally, simply removing the fmtp line appears to offer the same results. 

It appears that Firefox requires the h264 profile to be the baseline constrained profile. However, modifying the sdp before passing it to Firefox causes it to render the video in all of our testing.

Is there some way we could modify the sdp to get Chrome to behave as it was in Version 54? While parsing the profile-level-id header should definitely be a benefit, it currently seems like a step backward in terms of interoperability.

Thank you for the help,

-Eric Green

[Warren McDonald]

I suppose the intent is to not try to start a video session that will likely fail. Should this be different to codec top level negotiation. It looks like a sub negotiation, like error correction method, but it is acting like top level and rejecting completely, which is correct if the peer VC unit is not offering the Baseline profile.

A bigger question for general interoperability is: why is FF using Constrained and Chrome using Baseline.

Thinking about what H.264 is supposed to be for in browsers? If there is going to be this narrow a profile support, then interoperability with traditional H.264 endpoints via proxy or gateway is likely to be a very very small set without some conversion smarts in the gateway. So we are left with modern software to software interoperability where the game will just be implementing the small set of profiles to get Safari, Edge, Firefox and Chrome to play. Which actually looks more like VP8 than H.264 today.

[Eric Green]

It appears both browsers are using constrained. My test cases are to various non-webrtc endpoints through RTPEngine for dtls/ice negotiation. The media simply relayed, there is no manipulation in the middle.

My issue is really that it does work on Chrome 54 and stops working on Chrome 56. Additionally it mostly works on Firefox. This seems like a regression that should be addressed. Additionally, it should be clear which profiles are supported. 

We are surprised that not many other people have encountered this. There is at least one other instance that I am aware of: https://groups.google.com/forum/#!topic/sip_js/0X6VllUBVd8.

[Eric T]

I'd agree with Eric Green.  I had a bunch of interop working with h264 devices - Desktop video phones, security cameras etc.  It all broke after chrome changed how fmtp parameters are checked.  Definitely a regression.

[mar...@ceperley.com]

I'm also seeing a regression using H.264 on M58 using the iOS framework, where I am not able to receive incoming video. Reverting to M57 solves the issue, as does switching to VP8. Unsure if it is related to the fmtp parameters.

[mag...@webrtc.org]

Chrome only supports Constrained Baseline Profile right now. We are working on adding support for more profiles, like (unconstrained) Baseline Profile, Main Profile, High Profile, etc. We didn't look at the SDP previously and accepted any profile, and that might work depending on what H264 decoder you end up with (SW or one of the HW decoders). Since we now look at the profile-level-id, we reject anything else than Constrained Baseline Profile. We are working on adding support for more profiles, but we need to properly enumerate the capabilities of the H264 decoder before accepting other profiles. You can work around the new profile enforcement in Chrome by setting profile-level-id to 42E01F if you want to get the old behavior back, but it's undefined behavior and we can't guarantee it will work.

[Cliff Olmstead]

I see a regression as well.  Between 54 and 56 all my network cameras fail to work via WebRTC. 

Faking the profile-level-id doesn't do anything.

54 works great.  I'm not certain what profile of H264 these cameras are but they have always worked with Firefox and Chrome.  I understand Chrome technically only supports constrained baseline but I don't see a reason to actively break existing features.... 

[Warren McDonald]

Also, as I was reminded in another discussion, the decode process for H.264 is actually ffmpeg in Chrome, which does support higher profiles. So for receive only connections this is actually throwing away decodable connections.

I am not sure what the rules are re asymmetric capabilities, but this is a clearly a case where that logic could apply. 

Could Chrome accept a video track that ffmpeg can decode, even if it can only encode a lower profile track for sending?

[Cliff Olmstead]

So lets see...

Google is part of a group that designs spec for plugin replacement (in the name of security).

Google is forced to include H264 open codec in addition to their (preferred) VP8/WebM codec (THANK YOU CISCO!)

I quote (from an earlier appleinsider article):

"Google hoped to leverage its own strong position in web video, including its YouTube video sharing service and its popular Chrome web browser, to force adoption of WebM across the web".

Now google sees that it can completely hinder H264 by following the letter of the law ("Constrained baseline") which NEITHER EDGE OR FIREFOX DO...

Now we will see if google gets its way and people start switching to WebM or people start switching away from chrome (unlikely with android out there).

ANTITRUST anyone? ;)

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/EKLBlSaiYdU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/cdf1504c-b20a-4516-a64f-eba6ff52d1be%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

Il giorno martedì 20 giugno 2017 17:43:04 UTC+2, Cliff Olmstead ha scritto:

So lets see...

Google is part of a group that designs spec for plugin replacement (in the name of security).

Google is forced to include H264 open codec in addition to their (preferred) VP8/WebM codec (THANK YOU CISCO!)

I quote (from an earlier appleinsider article):

"Google hoped to leverage its own strong position in web video, including its YouTube video sharing service and its popular Chrome web browser, to force adoption of WebM across the web".

Now google sees that it can completely hinder H264 by following the letter of the law ("Constrained baseline") which NEITHER EDGE OR FIREFOX DO...

Now we will see if google gets its way and people start switching to WebM or people start switching away from chrome (unlikely with android out there).

ANTITRUST anyone? ;)

The same way Apple "forgot" to do VP8 in Safari to force everybody to use H.264?

L.

 

On Tue, May 30, 2017 at 12:23 AM, Warren McDonald <warren....@gmail.com> wrote:

Also, as I was reminded in another discussion, the decode process for H.264 is actually ffmpeg in Chrome, which does support higher profiles. So for receive only connections this is actually throwing away decodable connections.

I am not sure what the rules are re asymmetric capabilities, but this is a clearly a case where that logic could apply. 

Could Chrome accept a video track that ffmpeg can decode, even if it can only encode a lower profile track for sending?

    

On Thursday, 11 May 2017 17:05:27 UTC+10, Cliff Olmstead wrote:

I see a regression as well.  Between 54 and 56 all my network cameras fail to work via WebRTC. 

Faking the profile-level-id doesn't do anything.

54 works great.  I'm not certain what profile of H264 these cameras are but they have always worked with Firefox and Chrome.  I understand Chrome technically only supports constrained baseline but I don't see a reason to actively break existing features.... 



On Tuesday, April 11, 2017 at 7:30:22 AM UTC-4, mag...@webrtc.org wrote:

Chrome only supports Constrained Baseline Profile right now. We are working on adding support for more profiles, like (unconstrained) Baseline Profile, Main Profile, High Profile, etc. We didn't look at the SDP previously and accepted any profile, and that might work depending on what H264 decoder you end up with (SW or one of the HW decoders). Since we now look at the profile-level-id, we reject anything else than Constrained Baseline Profile. We are working on adding support for more profiles, but we need to properly enumerate the capabilities of the H264 decoder before accepting other profiles. You can work around the new profile enforcement in Chrome by setting profile-level-id to 42E01F if you want to get the old behavior back, but it's undefined behavior and we can't guarantee it will work.

On Tuesday, April 11, 2017 at 9:15:28 AM UTC+2, mar...@ceperley.com wrote:

I'm also seeing a regression using H.264 on M58 using the iOS framework, where I am not able to receive incoming video. Reverting to M57 solves the issue, as does switching to VP8. Unsure if it is related to the fmtp parameters.

On Wednesday, March 29, 2017 at 2:23:12 AM UTC-4, Eric T wrote:

I'd agree with Eric Green.  I had a bunch of interop working with h264 devices - Desktop video phones, security cameras etc.  It all broke after chrome changed how fmtp parameters are checked.  Definitely a regression.

On Monday, February 13, 2017 at 2:03:40 PM UTC-7, Warren McDonald wrote:

I suppose the intent is to not try to start a video session that will likely fail. Should this be different to codec top level negotiation. It looks like a sub negotiation, like error correction method, but it is acting like top level and rejecting completely, which is correct if the peer VC unit is not offering the Baseline profile.

A bigger question for general interoperability is: why is FF  using Constrained and Chrome using Baseline.

Thinking about what H.264 is supposed to be for in browsers? If there is going to be this narrow a profile support, then interoperability with traditional H.264 endpoints via proxy or gateway is likely to be a very very small set without some conversion smarts in the gateway. So we are left with modern software to software interoperability where the game will just be implementing the small set of profiles to get Safari, Edge, Firefox and Chrome to play. Which actually looks more like VP8 than H.264 today.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/EKLBlSaiYdU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Cliff Olmstead]

Apple came late to the game with Safari's webrtc implementation.  Honestly at this point it was safe to safe H264 was winning the battle and given  that it's not owned by their competitor I can see why they would implement only H264.

To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/98630434-f92c-4f62-8556-e22e294680f0%40googlegroups.com.

[Cliff Olmstead]

Also given that Safari is just NOW releasing webrtc (Its still alpha or beta isn't it??) I would slow your roll..  I would bet Apple will implement it eventually especially since its MTI in the specs.

Hell it took how many months for Chrome to support H264?!?!?

[Lorenzo Miniero]

Il giorno martedì 20 giugno 2017 19:24:53 UTC+2, Cliff Olmstead ha scritto:

Also given that Safari is just NOW releasing webrtc (Its still alpha or beta isn't it??) I would slow your roll..  I would bet Apple will implement it eventually especially since its MTI in the specs.

VP8 was already there, they simply took it out. But yeah, let's wait (won't hold my breath though).

L.

 

[Iñaki Baz Castillo]

2017-06-20 20:27 GMT+02:00 Lorenzo Miniero <lmin...@gmail.com>:
> VP8 was already there, they simply took it out.

Could that be due to legal stuff?

--
Iñaki Baz Castillo
<i...@aliax.net>

[Lorenzo Miniero]

Il giorno giovedì 22 giugno 2017 17:37:21 UTC+2, Iñaki Baz Castillo ha scritto:

2017-06-20 20:27 GMT+02:00 Lorenzo Miniero <lmin...@gmail.com>:
> VP8 was already there, they simply took it out.

Could that be due to legal stuff?

I don't think so, as even Microsoft added VP8 to Edge. But who knows...

L.

[Cliff Olmstead]

I believe the software encoding/decoding of VP8 is free for everyone to use (forever supposedly).  The hardware is most likely a different story although I don't know.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/EKLBlSaiYdU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6f74e892-3ed9-4618-8e6b-0447327db740%40googlegroups.com.

[Cliff Olmstead]

All joking aside though is there any estimated release/date for chrome with support for the additional profiles that were removed? 

Cliff

On Tuesday, April 11, 2017 at 7:30:22 AM UTC-4, mag...@webrtc.org wrote: