[BUG] Growing Invalid fragment length with Disney

[0x0x0x0x0]

Something that looked like a resurgence of the truncation bug and turned out to be something different; but 1.1.1.0 and 1.1.1.1 give different magnitudes of error:-

1.1.1.0 gives

00:02:20.869 - [Error] [Pump:audio1:disney] Invalid fragment length 175

1.1.1.1 gives

00:00:29.351 - [Error] [Pump:audio1:disney] Invalid fragment length 6

A-V deSync occurs at around 48s into the presentation in the downloaded file, but playing the same title in a web browser results in a contiguous synchronised playback well past that time.

Edit:-

2nd run with 1.1.1.1 gives

00:35:45.017 - [Error] [Pump:audio1:disney] Invalid fragment length 344

3rd run:

00:38:08.712 - [Error] [Pump:audio1:disney] Invalid fragment length 513

4th run:

00:40:29.995 - [Error] [Pump:audio1:disney] Invalid fragment length 682

and to get to an even 5:

00:42:56.982 - [Error] [Pump:audio1:disney] Invalid fragment length 851

I've updated the .1 log file to reflect the extra runs.

 

[0x0x0x0x0]

@Pete, having played around with it, I think I know what the problem is: AS is mishandling an error condition related to a damaged fragment file.

The short story is: it appears that that particular CDN node had a damaged fragment file as in the mp4a itself was corrupted, but kicking over to another node downloaded the correct version, here's the culprit:

Parsing ../lab/corrupt.mp4a [86017]
[moof, 1604]
.[mfhd, 16] version+flags: 0x00000000
        sequence_number: 5
.[traf, 1580]
..[tfhd, 24] version+flags: 0x00020028
        track_ID: 1
        default_sample_duration: 1024
..[tdft, 20] version = 0x1
        baseMediaDecodeTime: 1920000
..[trun, 1520] version: 0x01, flags: 0x000201
        sample_count: 375
        data_offset: 1612
        sample_size: 328
..[free, 8]
size of the `0x6d646174' box (125555) is above limit (84413)
done parsing

of course, the `0x6d646174' is the mdat box, and limit is the maximum payload size of the outer box less space used up by previous boxes at the same level

 

[Pete]

Thanks for all that info - it's the strangest thing.
I'll have to do some testing. It's tricky when you can't reproduce it.

 

[Pete]

BTW, that log message is misleading and needs to be changed - the number doesn't refer to the length, it's an internal counter. You can ignore that entirely, it's useless.

 

[0x0x0x0x0]

Ah, that makes sense now; I was scratching my head trying to figure out where the number was coming from and how AS could get to that small a number given the discrepancy

I can zip over the fragments just past that point to you if you need me to, it's early enough in the sequence.