car-20120827-86.mp4 has buggy tfdt

[ntrrgc]

The second fragment of car-20120827-86.mp4 has its baseMediaDecodeTime in tfdt set to 450450 units (at a timescale of 90000, 5.005s), but the first fragment is actually 450480 units* long (at a timescale of 90000, about 5.005333333s).

* Calculated by multiplying the default_sample_duration by sample_count (all frames use the default duration in trun).

In consequence, the last frame of the first fragment and the first frame of the second fragment have a small yet numerically significant overlap.

In implementations that do not implement frame slicing, when the first fragment is added after the second fragment this will trigger the deletion of the first frame of the second fragment and any frame depending on it. This is the reason 67. AppendH264VideoOutOfOrder fails e.g. on Chrome when run with ?novp9=true.

This muxing error also introduces other subtle problems:

• Since third and following fragments also have the same problem, the track will have a small drift that increases each fragment against any properly muxed track. This has the potential to cause small audio sync errors in long videos.
• Some implementations may ignore the tfdt for sequential fragments. In consequence, the same frame in the middle of the file will have different timestamps depending on whether it was loaded in a random-access manner or sequentially after all the other previous frames.

My questions are:

• Does the actual YouTube serve files affected by this issue?
• Are implementations expected to deal with it (e.g. by implementing frame slicing) for certification?

[tdedecko]

Yes, implementations should be able to handle this case.