On Tue Apr 8 09:58:08 2025 +0000, Nikolay Sivov wrote:
Are negative timestamps encoded in media data directly? P.S. we'll need someone to review winegstreamer parts.
This is in the MFT, which can be used by the application directly. In theory, they can assign any value they want (which is how I test the negative values on Windows).
But in terms of media data, I'll use the MPEG4 container as an example (as that's the one where I saw FFmpeg produce negative values). You get given three values/tables: 1. [Media Time](https://developer.apple.com/documentation/quicktime-file-format/edit_list_at...); 2. [Time to Sample](https://developer.apple.com/documentation/quicktime-file-format/time-to-samp...); and 3. [Composition Offset](https://developer.apple.com/documentation/quicktime-file-format/composition_...)
The composition offset is only used when you have a codec that needs decoding in a different order than presentation. For example, H.264 which uses B-Frames.
And it seems Windows, GStreamer and FFmpeg all use these values differently and produce different results.
As an example, say we have: 1. Media Time = 0.666666s 2. Time to Sample 1 = 0s 3. Composition Offset for Sample 1 = 0.333333s
DTS is calculated as PTS minus composition offset.
Windows asserts, due to a Media Time of 0.666666s, then that will be the first PTS: ``` PTS = 0.666666s, DTS = 0.333333 ```
GStreamer asserts that the first DTS will be 0s: ``` PTS = 0.333333s, DTS = 0s ```
FFmeg assets that the first PTS will be 0s: ``` PTS = 0, DTS = -0.333333s ```
In addition, I've seen FFmpeg produce a negative PTS on audio, but I'll have to double check the code to see how it got there. But I did note a couple of possibilities: 1. The value was the negative value of Media Time; 2. The value was the negative value of the duration, and the packet was flagged with `AV_PKT_FLAG_DISCARD`