HEVC: initialize Format.codecs (#8393)#8401
Conversation
| final int generalProfileSpace = bitArray.readBits(2); | ||
| final boolean generalTierFlag = bitArray.readBit(); | ||
| final int generalProfileIdc = bitArray.readBits(5); | ||
| final int generalProfileCompatibilityFlags = bitArray.readBits(32); |
There was a problem hiding this comment.
@equeim I think the order of bits in the resulting int is reversed compared to what's needed to build the codecs string. Please could you confirm whether that's consistent with your understanding or if I'm missing something?
I will take care of making the change if it's needed when merging this, so please just let me know whether it is correct. Thanks!
There was a problem hiding this comment.
I'm not sure, actually. MPEG-DASH for DVB specification says that bits must be reversed, but MPEG-4 Part 15 (where codecs string for HEVC is defined officially) doesn't mention it. Although I don't have access to the latest version of MPEG-4 Part 15 yet so I can't check whether it was added later.
It seems that almost all HLS/DASH manifests out there have it reversed though, and that was google/shaka-packager does too (https://github.com/google/shaka-packager/blob/d90cf9a0fd87833f7d9210ffe65d175dcf994c42/packager/media/codecs/hevc_decoder_configuration_record.cc#L133).
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.
equeim
changed the title
|
Updated PR to build codec string from HEVCDecoderConfigurationRecord instead of SPS in case of MP4/Matroska. |
Are there any particular benefits to doing it this way round? I was going to parse in one place for both |
|
Not really, aside from the fact that specification mentions HEVCDecoderConfigurationRecord specifically. I just though that code in HevcConfig would be clearer that way. More interesting, in Apple sample HLS stream with HEVC and MP4 segments (https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8), I discovered that information in HEVCDecoderConfigurationRecord and in SPS are not the same. In particular, generalProfileCompatibilityFlags in HEVCDecoderConfigurationRecord seems to have its bit order inverted compared to SPS. I'm not sure how it conforms to MP4 specification (probably doesn't), and I haven't seen other MP4 files like this (and ffmpeg generates MP4 with SPS and HEVCDecoderConfigurationRecord equivalent). |
|
Thanks for the info. I'll test with that stream to make sure the compatibility flags look right in the output string. |
|
This was merged in ff8c864, although for some reason our tooling didn't update the pull request to reflect this. Closing manually since it's now merged. Thanks! |
|
Just in case you are trying out ff8c864 on the development branch: I introduced a bug in how the buffer limit is set. I plan to submit a fix for that soon. Sorry for the inconvenience. |
*** Original commit *** Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393) Imported from GitHub PR #8401 This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources. Merge e582fb9 into 1347d57 Issue: #8393 *** PiperOrigin-RevId: 350871621
*** Original commit *** Rollback of ff8c864 *** Original commit *** Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393) Imported from GitHub PR #8401 This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media so... *** PiperOrigin-RevId: 351139861
3 participants
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.