Add CMAF CC support

[gkolb]

This PR will...

Add CMAF CC support

Why is this Pull Request needed?

CC was not supported for cmaf streams

Are there any points in the code the reviewer needs to double check?

When testing this make sure to turn renderNatively: true in config.ts or you won't see cc in the demo player.

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[gkolb]

I added the parsing of mp4 boxes into the passthrough-remuxer. Initially I wanted to add it to the mp4Demuxer but I needed initData for parsing. I wasn't sure what file would be the best place to add this logic because there have been many changed in the 1.0.0 branch and a lot of dummy tracks. Please leave comments and recommendations I plan to update this branch as needed.

[robwalch]

Hi @gkolb,

Very cool! 😎

Do you have sample streams we could use in test/test-streams.js? If hosting is an issue, I can provide hosting, or if you could provide encoding instructions for creating HLS with CMAF embedded CCs I can create and add test streams.

My main concern is - Does Safari have support for this? I would like to confirm with a test stream, and I would like us to add an integration test to maintain this feature. Apple's been adding more metadata features (emsg) and we may be a little behind there too. I like to have test vectors to validate the features so we either match Safari's implementation or file feature requests/bugs with Apple where necessary.

ATM we only have 3 non-drm fmp4 test vectors (it's not clear which conform to CMAF) so more are very welcome (just merged #2625 which had no impact on test vectors).

When testing this make sure to turn renderNatively: true in config.ts or you won't see cc in the demo player.

Heads up, I will be merging in changes from v0.14.0-beta.1 that renames renderNatively to renderTextTracksNatively. The default will be true to match the behavior in releases so you no change in demo config needed. Apologies if that requires any rebasing here (hopefully not for the passthrough-remuxer and mp4-tools).

[victor-at-work]

Hi @gkolb, We have our own fork of hls.js, and I am trying to see if I can apply some of your changes to it. This might be kind of a silly question, but why was it branched off of feature/v1.0.0 as opposed to master?

[gkolb]

@victor-at-work I can't remember specifically why I chose that branch. I think it just made more sense because 1.0.0 had more classes and features in place for CMAF and MP4 support.

[victor-at-work]

@gkolb That makes a lot of sense. FYI I was able to pull your changes into our fork, and I figure it's worth putting it up (#3016) if anyone else would like to use it before 1.0.0 is released.

[robwalch]

Hi @gkolb,

Sorry I didn't get around to merging in these changes earlier. There have been some changes made from the LL-HLS work. Please rebase or merge the changes from video-dev:feature/v1.0.0 into your branch.

I never received a response to the request for a sample stream, so if I don't hear back, I'll be going with @victor-at-work's contribution and then work on getting those changes merged into v1 from master rather than this PR - provided everything checks out in terms of feature comparison with Safari <video src=''> playback and testing.

Thanks!

[gregdolby]

I will try and get a sample stream and that rebase done this week.

[gregdolby]

@robwalch I've haven't found time to get a test stream or clean up this branch. You can go ahead and merge @victor-at-work's branch if thats easier