On Thu Apr 17 07:54:50 2025 +0000, Rémi Bernon wrote:
> Have you tried GstVideoTimeCodeMeta / do you know what it does?
No, I didn't look at that. But taking a look now, it looks like it might be good for Video PTS/DTS, but wouldn't work for audio. I'm not sure for duration either.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101244
On Wed Apr 16 08:20:27 2025 +0000, Brendan McGrath wrote:
> Oops (again). I just tried using the `preserve_timestamps` boolean and
> it doesn't work. The `timestamp/x-wg-transform` is a flag that lets
> `video_decoder.c` know that an input timestamp has been provided (and
> that it should use it). It will otherwise fall back to the behavior
> defined by `provide_timestamps`.
> But if we want to get rid of the need for the GUID, I guess we could
> move the existing logic in `video_decoder.c` (for generating our own
> timestamp) in to `wg_transform.c`.
Hmm, I'm not sure that moving timestamp generation to the unix side is better. Can't we simply fill the sample timestamps from the input provided timestamps instead of the GStreamer-generated timestamps we don't really care about?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101242
On Wed Apr 16 01:09:24 2025 +0000, Brendan McGrath wrote:
> On well formed media, that `dts < 0` should only ever be true once (as
> after adding ts_offset, we should never get a value below 0 again). It's
> mainly there in case we get media with malformed timestamps (and dts
> goes backwards).
IMO the offset should only be updated once, and there should be a check and warning/fixme message if that assumption is broken.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101241