H264 Profile Support in Chrome

[Nimi Wariboko Jr]

I'm trying to play a h264 stream using this example from pion:

https://github.com/webrtc-rs/examples/tree/5a0e2861c66a45fca93aadf9e70a5b045b26dc9e/examples/play-from-disk-h264

For streams with the profile level of `4D4020`, I am able to see playback in Chrome. However with streams with a profile level of `64001F`. I'm inclined to believe that Chrome only supports baseline profiles in WebRTC (as seen here https://stackoverflow.com/a/70665723), but this doesn't seem officially documented.

Furthermore, these streams play just fine when downloading the video or even with MediaSource Extensions. Am I right that I can't use WebRTC tracks for this use case (and switch to something like data channels + MSE?)

Thanks

[Bang He]

do you have some logs for that?

[Nimi Wariboko Jr]

The Javascript console shows no logs and there is no indication that there is any issue. When turning on verbose logging in Chromium I get:

[18788:30979:0515/174936.714832:INFO:decoder_database.cc(105)] Initializing decoder with payload type '114'. [18788:30979:0515/174936.714865:INFO:generic_decoder.cc(253)] Decoder implementation: DecoderInfo { prefers_late_decoding = implementation_name = 'ExternalDecoder (VDAVideoDecoder)', is_hardware_accelerated = true } [18788:30979:0515/174936.723450:warning:generic_decoder.cc(296)] Failed to decode frame with timestamp 182840869, error code: -13

Where error code -13 seems to be `WEBRTC_VIDEO_CODEC_FALLBACK_SOFTWARE`. This same video plays back fine with MediaSource extensions; might it be better to use WebRTC's data channels + MSE for this use case?

I posted this information to the Chromium group as I thought it would be Chromium specific; but I thought this group may be able to confirm whether or not profiles other than CB were supported in WebRTC.

[Vitaly Ivanov]

I'm using Constrained High profile with Chrome on Win, macOS and Linux, never had a problem. What does https://webrtc.github.io/samples/src/content/peerconnection/change-codecs/ say on your hardware? Do you see any 0x64 records?

--

---
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/0cb60e4d-702a-4cbf-a53f-b308713250c7n%40googlegroups.com.

[Nimi Wariboko Jr]

I see 0x640032, which corresponds to High Profile 5.0; so I guess my problem has to be with my stream? If I hardcode my `sdp_fmtp_line` to include profile-level-id=640032 the stream still doesn't work. My only guess can be there's a problem with how I'm sending the stream then; when I chunk the stream into fragmented mp4 moof/mdat, it plays fine with Chrome MSE; and the decoding error isn't helpful. I can only imagine there's something subtly wrong with how I'm sending each NAL, but I don't understand why I can successfully playback CB content.

[Nimi Wariboko Jr]

Solved (on Chrome):

1. I had to filter out all NALUs except IDR, Non-IDR, SPS and PPS

2. I had to ensure there were start codes (0x000001) before each NALU 

Now on Safari I can sometimes get the video to play (it just seems very inconsistent on whether the stream plays or not) and Firefox doesn't play at all.

[Vitaly Ivanov]

2 is more like "make sure 4-byte Annex B start codes (00 00 00 01) are used exclusively". I've seen Intel QSV producing a mix of  3- and 4-byte start codes within a single frame delivery, i.e. SPS and PPS start with 00 00 00 01 and then IDR NALU itself starts with 00 00 01, and this doesn't play well with Chrome's AVC decoder (even though it's perfectly valid)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6b630acb-98c4-435e-845f-d0d107a93a67n%40googlegroups.com.