Workaround for streams with hvc1.0.4 codec signalling?

[ftyp]

Have you read the Tutorials? Yes

Have you read the FAQ and checked for duplicate open issues? Yes

What version of Shaka Player are you using? 4.3.4

We encountered problems with H.265 DASH streams using "hvc1.0.4..." codec config. Streams using "hvc1.2.4" work on the other hand. Both codec configs are spec compliant in my understanding.

hvc1.0.4 indicates an unknown general_profile_idc and Main10 general_profile_compatibility_flag set
hvc1.2.4 indicates an Main10 general_profile_idc and Main10 general_profile_compatibility_flag set

Modifying the codec string in the manifest alone is not sufficient and initialization segments have to be updated as well changing just 1 bit for the general_profile_idc in moov/trak/mdia/minf/stbl/stsd/(hvc1|encv)/hvcC

https://d3sw8jxc8xznn6.cloudfront.net/hvc1.0.4/stream.mpd
https://d3sw8jxc8xznn6.cloudfront.net/hvc1.2.4/stream.mpd

You should be able to reproduce this behaviour using the demo player with Chrome on Windows.

Is there any way to modify this during initialization e.g. using a response filter? Or is this something that should be addressed internally in content workarounds?

This applies to other codec configs without proper profile idc as well, e.g. Main Profile "hvc1.0.2" or "hvc1.0.6" while other odd configs like "hvc1.1.0" and "hvc1.2.0" with unset profile compatibility flags work.

Thank you!

[ftyp]

After further looking into this I assume this could be achieved using a SEGMENT type response filter and an external library to modify the mp4 boxes. Is there a way to further differentiate between initialization and "regular" segments besides looking at specifics of the response URL?

[theodab]

A response filter is probably the correct way to handle this on your end, yes. We could potentially convert the content on our end, like how we handle TS transmuxing and such, but this might be too niche to be worth building into the player, I'm not sure.

Anyway, as you said you're going to have to look at the URL. Unfortunately there's no built-in way to tell if a segment is an init segment or not from the filter end; I would say we could add a new shaka.net.NetworkingEngine.RequestType value for init segments, but that would ruin backwards compatibility for a lot of existing filters.

I guess we could add a new field to the shaka.extern.Response, like an isInitSegment boolean or something. That would work, and wouldn't break backwards compatibility, but it would be a pretty ugly and unintuitive solution.

[ftyp]

Thanks for looking into this. It is niche and I guess usually one would opt to "fix" the content instead of having a workaround in the player.

While there are some options to guess the segment type, e.g. file naming, content-type or additional headers but they all require a pretty strict setup on content or delivery side which might not be possible.

I agree breaking backwards compatibility is not an option and using the response object for this is not great. Would it be conceivable to have an additional optional subtype parameter for response filters instead?

[theodab]

Yeah, I guess that would work...

Okay, I have a design in mind. I'm thinking of an optional paramater of a new shaka.net.NetworkingEngine.AdvancedRequestType enum type, which describes sub-types of normal request types. So it's passed in as null for a normal segment request, but passed in as shaka.net.NetworkingEngine.AdvancedRequestType.INIT_SEGMENT if it's an init segment.
This will convey that information without breaking backwards compatibility. It will also allow for more detailed information in other situations... say, maybe HLS media playlists also get an advanced request type, to express how they are a sub-type of MANIFEST requests.

I'll put this together now, while I'm thinking about it. Shouldn't take too long.