MP4 CEA parser does not know that there could be multiple TRUN boxes

[avelad]

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

What version of Shaka Player are you using? Main branch

Can you reproduce the issue with our latest release version? Yes

Can you reproduce the issue with the latest code from main? Yes

Are you using the demo app or your own custom app? Demo

If custom app, can you reproduce the issue using our demo app? Yes

What browser and OS are you using?
Chrome, macOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

https://d2zihajmogu5jn.cloudfront.net/advanced-fmp4/master.m3u8

What configuration are you using? What is the output of player.getConfiguration()?

Default

What did you do?

Load the previous stream and enable the CC

What did you expect to happen?
CC are shown correctly

What actually happened?

Only bop! is shown. bip! is not displayed.

The problem is that the analyzer assumes that there is only one box trun, and that is not true, in this case there are 2 TRUN boxes, See: https://github.com/shaka-project/shaka-player/blob/main/lib/cea/mp4_cea_parser.js#L180

[avelad]

Info from https://thumb.co.il/

[joeyparrish]

Ah, I see. So if there are multiple truns, that means multiple mdats, too, correct?

That shouldn't be too difficult to fix.

[joeyparrish]

I was wrong. One segment I'm analyzing has, for example:

• moof
  • traf
    • trun
    • trun
• mdat
• moof
  • traf
    • trun
    • trun
• mdat
• moof
  • traf
    • trun
    • trun
• mdat

So per moof, there are two trun boxes and one mdat. So parsing needs to reset on every moof, and I need to understand how to interpret the extra trun box. It looks like the samples need to be combined.

[joeyparrish]

This suggests that the samples from both trun boxes need to be processed: https://bugzilla.mozilla.org/show_bug.cgi?id=1143491