AW: Timestamping problem

[Thornton, Keith]

I did try with GST_EVENT:6 but this just gave me 

0:01:57.056119884  5936 00000000496255A0 INFO               GST_EVENT gstevent.c:1139:gst_event_new_seek: creating seek rate 1.000000, format TIME, flags 5, start_type 1, start 0:00:06.442000000, stop_type 1, stop 0:00:16.442000000
0:01:57.062572687  5936 00000000496255A0 DEBUG              GST_EVENT gstevent.c:302:gst_event_new_custom: creating new event 00000000265984D0 seek 51201
0:01:57.062593214  5936 00000000496255A0 LOG                GST_EVENT gstevent.c:219:_gst_event_free: freeing event 00000000265984D0 type seek

Which didn't help me. Do you have a suggestion which logging switches might deliver mor useful information.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] Im Auftrag von Nicolas Dufresne
Gesendet: Donnerstag, 17. Dezember 2015 21:48
An: Discussion of the development of and with GStreamer
Betreff: Re: Timestamping problem

Le jeudi 17 décembre 2015 à 10:30 +0000, Thornton, Keith a écrit :
> Hi
> I have a pipeline in which my encoder (using Intel INDE on Windows 7
> x64) encodes an H264 Stream and passes the encoded frames to qtmux.
> My encoder sets the pts and dts timestamps as I would expect.
> When playing the resulting video qtmux adds a value of 39:01:18 to the 
> PTS. While this doesn’t affect the playback, it makes seeking 
> impossible.
> Presumably my encoder is not setting some initial value correctly.
> Can anyone explain what this mysterious addition is.
> I am using the current Git Master on Windows7 Regards

What do you set in the segment ?

Nicolas