GNOME Bugzilla – Bug 708276
pipeline: fix potential overflow getting the new base time
Last modified: 2013-09-28 15:49:52 UTC
Clock changes where 'now' is smaller than the start_time result in negative values for the new base time. From gst_pipepline_update_base_time: start_time=0:00:00.251270779, now=24:32:21.246680292, base_time 24:32:20.995409513 start_time=0:00:00.171604615, now=0:00:00.000000000, base_time 5124095:34:33.537947001
Created attachment 255163 [details] [review] pipeline: fix potential overflow getting the new base time
When exactly does this happen? This sounds like a non-monotonic clock and/or something broken with the start_time handling.
I was happening in scenario in which a demuxer was changing state READY_TO_PAUSED synchronously when it should do it async, so the pipeline was going to PAUSED and PLAYING without any sink. The sink was being added afterwards (when the demuxer exposes the new pad) and the pipeline goes to PAUSED than PLAYING because of buffering messages and the new base time is distributed again, this time using the audio sink's clock (I think) I have fixed that in the demuxer, which now changes state async, but looking at the code in gstpipeline.c, there can be weird use cases in which this can still happen.
Ah so the clock was changing... if the clock is changing (clock-lost message) you need to go back to PAUSED (setting start_time with the new clock) and then back to PLAYING (setting base_time with new start_time and new clock).
I don't have any clock lost and the clock is not the same. Also going to PAUSE/PLAY does not fixes the issue once base_time is wrong, only a seek does it, resetting start_time to 0. reset start_time to 0 selecting clock and base_time Need to update start_time Need to update clock. start_time=0:00:00.000000000, now=1:30:36.897877665, base_time 1:30:36.897877665 start_time=0:00:00.302430723, now=1:30:37.200308388, base_time 1:30:36.897877665 start_time=0:00:00.302502953, now=1:30:37.200380618, base_time 1:30:36.897877665 selecting clock and base_time Need to update start_time Need to update clock. start_time=0:00:00.302502953, now=1:30:37.213690249, base_time 1:30:36.911187296 start_time=0:00:00.587327066, now=1:30:37.498514362, base_time 1:30:36.911187296 start_time=0:00:00.588077746, now=1:30:37.499265042, base_time 1:30:36.911187296 selecting clock and base_time Need to update start_time Need to update clock. start_time=0:00:00.588077746, now=0:00:00.000000000, base_time 5124095:34:33.121473870 start_time=0:00:01.580015246, now=0:00:00.991937500, base_time 5124095:34:33.121473870 start_time=0:00:01.788077746, now=0:00:01.200000000, base_time 5124095:34:33.121473870 selecting clock and base_time Need to update start_time Need to update clock. start_time=0:00:01.788077746, now=0:00:01.200000000, base_time 5124095:34:33.121473870 start_time=0:00:02.234411079, now=0:00:01.646333333, base_time 5124095:34:33.121473870 start_time=0:00:02.448077746, now=0:00:01.860000000, base_time 5124095:34:33.121473870
Wim, what do you think about this? If I'm not mistaken the base time can be wrong with the attached patch if an overflow was prevented... as start_time was not taken into account at all.
Andoni, can you also provide a testcase for this?
I have been able to reproduce it with a simple test case in 0.10, were the base_time is corrupted but I can't reproduce it in 1.0 were the base_time is reset to 0 correctly.And in the test case I received a clock-lost message correctly so I will close this bug.