H264 profile supported by Chrome?

[David Soto]

Hi All, 

   We work with customers that use GstWebRTC (developed by RidgeRun) [1] on embedded devices to get WebRTC support and normally the client is Chrome/Chromium. It works really well. However,  with one customer we are having some problems receiving H264 Main profile, do you know if the H264 decoder in Chromium/Chrome supports Main Profile? I found this reference but I am not sure if something has changed since then [2].

Thanks for your guidance on this topic.

-David

RidgeRun

[1] https://developer.ridgerun.com/wiki/index.php?title=GstWebRTC

[2] https://groups.google.com/d/msg/discuss-webrtc/EKLBlSaiYdU/JJhZ1mKtDwAJ

[Harald Alvestrand]

(repeating comment from private conversation)

The decoder in chrome is ffmpeg, I am not sure what it can decode. We use baseline with some elements from high in most applications.

Others know more.

--

---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/76a10cc1-60a5-4575-be38-4346e1bca2ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[anil2...@gmail.com]

chrome can decode main profile. we have verified it some time back by sending h264 main profile encoded stream from a sender to chrome receiver in our system.

On Monday, April 23, 2018 at 7:29:49 PM UTC+5:30, Harald Alvestrand wrote:

(repeating comment from private conversation)

The decoder in chrome is ffmpeg, I am not sure what it can decode. We use baseline with some elements from high in most applications.

Others know more.

On Sat, Apr 21, 2018 at 11:07 PM, David Soto <david...@ridgerun.com> wrote:

Hi All, 

   We work with customers that use GstWebRTC (developed by RidgeRun) [1] on embedded devices to get WebRTC support and normally the client is Chrome/Chromium. It works really well. However,  with one customer we are having some problems receiving H264 Main profile, do you know if the H264 decoder in Chromium/Chrome supports Main Profile? I found this reference but I am not sure if something has changed since then [2].

Thanks for your guidance on this topic.

-David

RidgeRun

[1] https://developer.ridgerun.com/wiki/index.php?title=GstWebRTC

[2] https://groups.google.com/d/msg/discuss-webrtc/EKLBlSaiYdU/JJhZ1mKtDwAJ

--

---
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.

[Brad Thomas]

We tried h264 baseline at 6mbps. The problem we ran into is the bitrate drastically jumped all over the place. Sometimes it would stay around 6mbps, other times it would jump down to below 1.5mps which would cause the stream to freeze for a second or two. We couldn't figure out how to tweak settings so we were stuck using baseline. Are you saying you can currently adjust certain elements of the baseline profile? 

On Monday, April 23, 2018 at 6:59:49 AM UTC-7, Harald Alvestrand wrote:

(repeating comment from private conversation)

The decoder in chrome is ffmpeg, I am not sure what it can decode. We use baseline with some elements from high in most applications.

Others know more.

On Sat, Apr 21, 2018 at 11:07 PM, David Soto <david...@ridgerun.com> wrote:

Hi All, 

   We work with customers that use GstWebRTC (developed by RidgeRun) [1] on embedded devices to get WebRTC support and normally the client is Chrome/Chromium. It works really well. However,  with one customer we are having some problems receiving H264 Main profile, do you know if the H264 decoder in Chromium/Chrome supports Main Profile? I found this reference but I am not sure if something has changed since then [2].

Thanks for your guidance on this topic.

-David

RidgeRun

[1] https://developer.ridgerun.com/wiki/index.php?title=GstWebRTC

[2] https://groups.google.com/d/msg/discuss-webrtc/EKLBlSaiYdU/JJhZ1mKtDwAJ

--

---
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.

[Harald Alvestrand]

Remember to differentiate between the encoder and the decoder.

The Chrome software encoder is OpenH264 - https://github.com/cisco/openh264

Contributions are welcome, but the encoder currently doesn't support either High or Main (or even full Baseline), according to the README file.

Hardware encoders vary greatly in their capabilities.

To unsubscribe from this group and stop receiving emails from it, 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/e7602bc4-92b3-47df-be5d-c37f9a801743%40googlegroups.com.

[Brad Thomas]

ah yes, very good point. We've actually been trying to figure out a way to bump vp8 up to 6mbps instead. No luck yet. Right now we're stuck at 2.5mbps. 

[David Soto]

Could you provide more details on how you tested it? I would like trying to reproduce your results.

-David

[cweh...@fuze.com]

@Harald: we've actually been facing issues related to the different profiles support with OpenH264 and the hardware encoders. Wouldn't it make more sense for Chrome to only offer profiles supported by both? Here's the bad corner case we hit: we were accidentally picking a profile only supported by the hardware encoder on Mac. As a result, when Chrome detected CPU issues for instance, it would try to reduce quality to a level not supported by the hardware encoder which actually led to a fallback to the software encoder... which didn't support the profile. There didn't seem to be a good way to handle this scenario as the other side would just stop receiving anything.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e7602bc4-92b3-47df-be5d-c37f9a801743%40googlegroups.com.

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

*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*

[Dominik Balogh]

I'm actually trying to figure out how to choose a profile that is supported by the hardware encoder on Mac. For our use case this is actually optimal. How did you enforce hardware-accelerated H.264 on Mac for WebRTC and how did you determine/debug that it's true? Thanks!

[Mada Aflak]

Hello, 

I am trying to integrate High Profile on Webrtc, and for some reason webrtc allows devices to have high profile only with OMX.Exynos. 

Does someone understand why ? 

cf: 

private boolean isH264HighProfileSupported(MediaCodecInfo info) {
    return this.enableH264HighProfile && VERSION.SDK_INT > 23 && info.getName().startsWith("OMX.Exynos.");
}

Many thanks

[Neil Young]

A couple of years later I'm having the same question, since I seem to have a problem with a camera providing H.264 High at level 4 (if I read profile_idc = 100 (dec) and level_idc = 40 (dec)) correctly from the SPS NAL unit.
Chrome is Version 118.0.5993.117, macOS Sonoma, ARM

[Neil Young]

Answer: For the SDP negotiation it seems CB, 3.1 is required. But internally the decoders don't really care about the real content of the NAL units. I was able to agree on 42e1f with all browsers but sending High Profile level 4 afterwards in HD. That was decoded w/o problem.

[Neil Young]

Addition: For SDP negotiation Baseline 3.1 (42001f) seems to work too

Sorry for bother