On Wed Apr 9 00:27:39 2025 +0000, Brendan McGrath wrote:
Oh. I thought I had seen a game specific hack that required PTS to run to a certain value (in order for the game to progress after the video). So I had been thinking some applications had a dependency on this value. But in searching for that hack, I instead found this comment:
/* FIXME: sample time is inconsistent across windows versions, ignore it */So, in light of that (and your findings), I guess testing for a specific sample time makes no sense. Instead, maybe I should check the difference between PTS and DTS (possibly adding tolerance for being off by one due to different rounding techniques). I'll mark this as draft while I make that change. The other thing I've been thinking I should test is the difference between Audio and Video PTS. Although that will require the creation of new test media as these media files only have Video. But that can be a future MR.
Actually - I'm not sure testing the difference between PTS and DTS will work either. Looking at the values you got from Sample 1: ``` sample 1: Unexpected sample time 1333333, expected 2666665 sample 1: Unexpected sample dts 0, expected 999999 ```
The difference there is 1333333 (i.e. 1333333-0) for the received values, but the difference in the expected values is 1666666 (i.e. 2666665-999999). Looking directly at the file, I can see it has composition offset of 500 (at a timescale of 3000). So 10000000 * 500 / 3000 = 1666666.667. It should be 1666666. Which means Windows 11 doesn't honor what is in the media file. Maybe because 1333333 - 1666666 would be negative (and DTS on Windows is carried by the `MFSampleExtension_DecodeTimestamp` attribute; which is unsigned). So I don't know if we want to replicate that?