Re: [discuss-webrtc] Re: PSA: H264 profile level changed from 3.1 to 4.2

[PhistucK]

Should this kind of change go through the Chromium/Blink intent process perhaps? Especially given the already indicated breakage?

☆PhistucK

On Fri, Jul 26, 2024 at 7:49 AM 伍炫树 <shushu...@gmail.com> wrote:

Hi, does this change need to be carried in M128? Our project may be affected and unavailable because of matching the '42e01f'.

在2024年7月4日星期四 UTC+8 04:49:14<Sergio Garcia Murillo> 写道：

tl;dr; ignore if you are properly implementing level-asymmetry-allowed

As Philip Hancke noticed me, a recent change I contributed adding missing SW decoding profiles also increased the level supported on decoding from 3.1 to 4.2 (as 3.1 doesn't support 1080p streams):

https://webrtc-review.googlesource.com/c/src/+/355001

also has changed the profile-level-id in the SDPs from XXXX1f to XXXX2a. So if you are doing string matching looking for 42e01f and not properly implementing level-asymmetry-allowed, you might be in trouble. I am not aware of any other side issue, please let me know if I am wrong.

I don't think this should be affecting anyone, but if there is a big impact I can submit a CL reverting the level change.

Best regards

Sergio

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7ecb2eb1-579d-4618-9a0b-f6bdf645010bn%40googlegroups.com.

[Alex Russell]

Is it possible to understand the scale of potential breakage?

On Friday, July 26, 2024 at 7:24:39 AM UTC-7 PhistucK wrote:

Should this kind of change go through the Chromium/Blink intent process perhaps? Especially given the already indicated breakage?

☆PhistucK

On Fri, Jul 26, 2024 at 7:49 AM 伍炫树 <shushu...@gmail.com> wrote:

Hi, does this change need to be carried in M128? Our project may be affected and unavailable because of matching the '42e01f'.

在2024年7月4日星期四 UTC+8 04:49:14<Sergio Garcia Murillo> 写道：

tl;dr; ignore if you are properly implementing level-asymmetry-allowed

As Philip Hancke noticed me, a recent change I contributed adding missing SW decoding profiles also increased the level supported on decoding from 3.1 to 4.2 (as 3.1 doesn't support 1080p streams):

https://webrtc-review.googlesource.com/c/src/+/355001

also has changed the profile-level-id in the SDPs from XXXX1f to XXXX2a. So if you are doing string matching looking for 42e01f and not properly implementing level-asymmetry-allowed, you might be in trouble. I am not aware of any other side issue, please let me know if I am wrong.

I don't think this should be affecting anyone, but if there is a big impact I can submit a CL reverting the level change.

Best regards

Sergio

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

[Philipp Hancke]

I haven't heard many complaints from the larger vendors using H264 yet.

And I know many of them test in Chromium Canary and Beta as they should.

Bear with me... the original change is quite good as it makes the announced capabilities match the actual software decoder capabilities:

  https://webrtc-review.googlesource.com/c/src/+/355001

I believe this fixes a ton of nasty issues with decoder fallback from hardware decoders so is a great contribution!

That it changes the profile-level-id field in the SDP is somewhat subtle and I only noticed ten days later by chance,

reached out to Sergio who authored the CL and asked him to send a PSA to discuss-webrtc (webrtc developers generally read that and not blink-dev).

Now if that had been known upfront it would have been nice to wait until after a branch cut to ensure maximum runway.

But sometimes these changes slip through (which is why we have Canary and Beta)

The risk of getting this wrong seemed low as H264 SDP negotiation is quite particular about how to negotiate this field.

Hardcoding 42e01f which seems to be the root cause of https://issues.chromium.org/issues/354143228

is *not* how you do it and even the expectation that you get that is not satisfied by the RFC which only requires

  https://datatracker.ietf.org/doc/html/rfc7742#section-6.2

  Constrained Baseline Profile Level 1.2 (MUST) and

  Constrained Baseline Profile Level 1.3 (SHOULD)

which translate to (using Harald Alvestrands magic decoder ring) should be 42e00c and 42e00d respectively

(level determines number of macroblocks you can decode and hence resolution)

Sadly the somewhat more backward compatible solution to add the new profile in addition to the old one turned out to cause more issues in

  https://webrtc-review.googlesource.com/c/src/+/357740

because we spend so payload types on the zoo of H264 variants that the usable id space from 96-127 is overcrowded (this issue has details)

Reverting the original change from M128 as done by Sergey

  https://webrtc-review.googlesource.com/c/src/+/357861

and then relanding it in a more planned fashion seems like a good way forward.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7ecb2eb1-579d-4618-9a0b-f6bdf645010bn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec37d049-7b67-4ad9-9352-2df7c2634a4fn%40chromium.org.