INVALID_MP4_CEA error being thrown when shouldn't be

[mikeszutu]

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

If the problem is related to FairPlay, have you read the tutorial?

What version of Shaka Player are you using?

Latest

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?
Yes and both

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

What browser and OS are you using?
Chrome and macOS

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

What are the manifest and license server URIs?

N/A

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

What did you do?

Start playback and 2010 will be thrown depending on the segments being pulled

What did you expect to happen?
Error not to be thrown for 2010

What actually happened?

2010 is thrown and playback halts since we're catching a critical error.

I believe the issue is this change 12 months ago:

mp4_cea_parser
if (parsedTRAF.baseMediaDecodeTime === null) {
// This field should have been populated by the Base Media Decode
// Time in the tfdt box.
shaka.log.alwaysWarn(
'Unable to find base media decode time for CEA captions!');
throw new shaka.util.Error( <- This
shaka.util.Error.Severity.CRITICAL,
shaka.util.Error.Category.TEXT,
shaka.util.Error.Code.INVALID_MP4_CEA);
}
Why are we loggin a warning but throwing an error? Should this be treated as a warning instead? We're currently treating this a failure when attempting playback since it's a critical error that can't be recovered.

Are you planning to send a PR to fix it?
No

[avelad]

@gkatsev @tykus160 any opinon?

[gkatsev]

yeah, if captions can't work properly without that value, it should probably stop displaying the captions rather than stop playback altogether.
Though, it seems like that throw has been around for ~5 years #2660
It's possible that this recent change caused it to happen more often? #6878

[avelad]

yeah, if captions can't work properly without that value, it should probably stop displaying the captions rather than stop playback altogether.

Do you want work on it?

[gkatsev]

I'm not sure if I'll be able to get to it this week. Would a potential fix to make the error not be a critical error? I guess one concern is whether there are any issues with segments that don't have the baseMediaDecodeTime?

Also, I did just see this issue briefly for me this morning when testing with v4.15.2 but in our fork based on 4.10 I didn't see the issue. Both have the change from #6878, so, must be another change that caused it to happen more often.

Also, is there a particular stream that can reproduce this readily?

[mikeszutu]

@gkatsev I personally only seen it once but it halts our playback. I think the issue is that we're now cycling all the parsedTRAFs instead of looking at the last parsedTRAFs for baseMediaDecodeTime === null. So I believe this increases the frequency of the error being thrown now.