Draft: mfplat/tests: Add tests for Byte Stream Output.
This MR adds tests that examine the values of the samples output by the byte stream handlers.
It is marked as draft as it is dependent on the fixes included within MR !7569 (merged).
I've also renamed the tests as they previously exclusively tested the sample output timestamps. The tests now also look at the number of buffers included in a sample and total size of the buffers within a sample.
Merge request reports
Activity
requested review from @nsivov
added 29 commits
-
0e865040...215a1043 - 22 commits from branch
wine:master
- 56e0e2b8 - mfplat/tests: Fix crash in MFShutdown on Windows.
- 27e94740 - mfplat/tests: Fix leak of media events.
- 75022764 - mfplat/tests: Fix leak of media source.
- 01dfc84b - winegstreamer: Allow NULL for time_format.
- e661f19b - mfsrcsnk: Allow NULL for time_format.
- 5977a7a9 - mfplat/tests: Add tests for Byte Stream Output.
- 44fcec32 - mfplat/tests: Add tests for MP3 Byte Stream Output.
Toggle commit list-
0e865040...215a1043 - 22 commits from branch
mentioned in merge request !7569 (merged)
added 67 commits
-
44fcec32...8e2aea62 - 65 commits from branch
wine:master
- 99b9186d - mfplat/tests: Add tests for Byte Stream Output.
- f2f4927b - mfplat/tests: Add tests for MP3 Byte Stream Output.
-
44fcec32...8e2aea62 - 65 commits from branch
Given MR !7569 (merged) has been merged, this one no longer needs to be in draft.
This is what I get on Win11:
14 mfplat.c:13880: Test failed: mp4/h-264 timestamps: sample 0: Unexpected sample time 0, expected 1333332 15 mfplat.c:13894: Test failed: mp4/h-264 timestamps: sample 0: Got unexpected hr 0xc00d36e6 when requesting DTS, expected 0. 16 mfplat.c:13898: Test failed: mp4/h-264 timestamps: sample 0: Unexpected sample dts -1, expected 666666 17 mfplat.c:13880: Test failed: mp4/h-264 timestamps: sample 1: Unexpected sample time 1333333, expected 2666665 18 mfplat.c:13898: Test failed: mp4/h-264 timestamps: sample 1: Unexpected sample dts 0, expected 999999 19 mfplat.c:13880: Test failed: mp4/h-264 timestamps: sample 2: Unexpected sample time 666666, expected 1999998 20 mfplat.c:13898: Test failed: mp4/h-264 timestamps: sample 2: Unexpected sample dts 0, expected 1333332 21 mfplat.c:13880: Test failed: mp4/h-264 timestamps: sample 3: Unexpected sample time 333334, expected 1666666 22 mfplat.c:13880: Test failed: mp4/h-264 timestamps: sample 4: Unexpected sample time 1000000, expected 2333332 23 mfplat.c:13898: Test failed: mp4/h-264 timestamps: sample 4: Unexpected sample dts 666667, expected 1999999
I haven't checked if it's from previous MR or this one, but likely related to one or another.
Edited by Nikolay SivovOh. 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?