On Mon Oct 16 23:45:59 2023 +0000, Zebediah Figura wrote:
If Windows never sets the sample time for video samples after the first then we should probably make this check more restrictive to explicitly check that.
It's Complicated™
(Apologies if you know some of this already, better too much information than too little.)
The MPEG video format contains two layers of framing - the program stream tells which bytes are audio and which are video, but it's just arbitrarily arranged bytes, with no relation to video frame boundaries.
Windows' MPEG splitter parses the program stream, reads the first few bytes of the video stream (the codec data) to determine image size, and emits that. Determining the frame boundaries is the video codec's job.
GStreamer's mpegpsdemux doesn't read the codec data because why would it. To make the splitter's media type contain image size, I needed to put the mpegvideoparse on this side.
Which means that, unlike Windows, each submitted packet is exactly one frame. ``` Windows video0 hr=00000000 len=1214 audio0 hr=00000000 len=2037 audio1 hr=00000000 len=2037 audio2 hr=00000000 len=2025 audio3 hr=00000000 len=2025 audio4 hr=80040249 len=653
Wine video0 hr=00000000 len=859 audio0 hr=00000000 len=1253 video1 hr=80040249 len=195 audio1 hr=00000000 len=1254 video2 hr=80040249 len=84 audio2 hr=00000000 len=1254 video3 hr=80040249 len=76 audio3 hr=00000000 len=1254 audio4 hr=00000000 len=1254 audio5 hr=00000000 len=1254 audio6 hr=00000000 len=1254 ```
Yes, it's messy, but I don't think we can do any better unless I move the mpegvideoparse into the codec object. Which would be more accurate to native, but it would require writing my own decoder for the codec data, would require reintroducing https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_46588, and would improve nothing except our test suite.
That said, the VFW_S_NO_STOP_TIME check catches nothing. I'll drop it.