On Sun May 17 11:49:44 2026 +0000, Akihiro Sagawa wrote:
Good point. Actually, quality control is something I already have in mind. As I understand it, GStreamer expects the running time for a QoS event (ref. gst_event_new_qos). So as long as the running time is used, it works better with my changes, because the running time (on the GStreamer side) is based on the beginning of the segment. However, according to the comment added in commit 5e222064ab27266c0f44ec3986872f611772ff10, wg_parser_stream_notify_qos() is expected to receive stream time. On the other hand, the newly added gst_segment_to_running_time() in that commit converts a position within the segment into running time. I find this discrepancy confusing. I would appreciate it if you could clarify the intention behind this design. Once the intention behind these behaviors becomes clear, I plan to make the necessary changes for QC. Regarding the offset, you can see the following output from `ffprobe -show_packets dlls/quartz/tests/test.mpg`:
[PACKET]
codec_type=video
stream_index=0
pts=48600
pts_time=0.540000 <-- (a)
dts=45000
dts_time=0.500000
duration=3600
duration_time=0.040000
size=859
pos=30
flags=K__
[/PACKET]
(...)
[PACKET]
codec_type=audio
stream_index=1
pts=47618
pts_time=0.529089 <-- (b)
dts=47618
dts_time=0.529089
duration=2351
duration_time=0.026122
size=1253
pos=2048
flags=K__
[/PACKET]
(...)
PTS values in MPEG-1 streams typically do not start at zero because encoders may apply an initial offset to keep PTS/DTS values in a convenient positive range. GStreamer (specifically mpegpsdemux) returns these PTS values as they are --- for example, 0:00:00.540000000 for the first video buffer (ref. a) and 0:00:00.529088888 for the first audio buffer (ref. b). On native, it returns 55 as the REFERENCE_TIME for the first audio sample and 109,166 for the first video sample. I suspect the audio timestamp is derived from (b) with an additional processing delay applied, whereas the video timestamp reflects (a) adjusted by the offset between (a) and (b). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10864#note_140277