GNOME Bugzilla – Bug 739990
basesink: set the last position to minimum value after rewind
Last modified: 2018-11-03 12:24:01 UTC
Created attachment 290452 [details] [review] Set the last position to minimum value after rewind Set the last position to minimum value after rewind Overview: Let's suppose the video file is encoded with wrong pts value If we rewind this file and wait until the video play again at first, then the basesink sets the last position to wrong value. So in this case, basesink chooses the minimum value to set the last position. Steps to Reproduce: rewind the video and wait until it play again at start position. Actual Results: the play(current) time temporarily increases to the wrong position. and play again at start. Expected Results: play well without increasing the play time to the wrong position.
Created attachment 290674 [details] [review] basesink set the last position to minimum value
Can you provide a unit test or other kind of easily reproducible testcase for this, or explain in more detail what exactly goes wrong here when and why?
There are some files which the un-sequential PTS stored in the index table. It means that the PTS did not increase or decrease sequentially, so the PTS can suddenly increase or decrease in the middle of playing. I use embedded systems in special platform so I cannot provide the unit test. Anyway, I can see the progress bar in my test environment. Test case: Rewind these files and wait until the play time goes to the begining(usually 0 sec). Problem: The progress bar suddenly goes to random position. Expected Result: If the rewind finished at the begining of file, then the normal playback start and the position increase sequentially. Root cause: When the playback position reach the beginig of file, the pipeline status changed PLAYING to PAUSED for restarting the file. Then the pipeline get the wrong last position in PAUSED status. - The last position is the base position when the file restart after some playback event(Fast forward or rewind).
If there's DTS on the buffers, the DTS is used in the sink. In which case the DTS must monotonically increase (rate > 0) or decrease (rate < 0). Everything else would be a bug in upstream elements. If there's no DTS on buffers, the PTS is used in the sink. In which case the PTS must monotonically increase or decrease... etc :) So it seems like something is producing wrong values in your pipeline. Nonetheless basesink should compensate for that somehow, but I think it should already do that in the beginning of it's chain function.
As you said, normal files must monotonically increase or decrease their DTS/PTS value. But there are abnormal files - not increase or decrease monotonically - so the problem occurs in this case. The files I tested are index files, container is asf, wmv, mp4 files. I'm sure if there is no progress bar, then it's not a problem. But if we can see the progress bar by player program, then the bar is abnormally jumped to some point. I think the person who use the gstreamer in linux, or some OS by command line don't need this patch, but the person who make a player program by using gstreamer need this patch.
(In reply to Myoungsun Lee from comment #5) > As you said, normal files must monotonically increase or decrease their > DTS/PTS value. But there are abnormal files - not increase or decrease > monotonically - so the problem occurs in this case. > > The files I tested are index files, container is asf, wmv, mp4 files. I'm not talking about files here, but that the audio/video decoders at latest should fix up such broken PTS/DTS. > I'm sure if there is no progress bar, then it's not a problem. > But if we can see the progress bar by player program, then the bar is > abnormally jumped to some point. > > I think the person who use the gstreamer in linux, or some OS by command > line don't need this patch, but the person who make a player program by > using gstreamer need this patch. I still think that this patch is doing things too late. The fixup for broken PTS/DTS shouldn't be in the position reporting, but earlier in the chain function already. It would be good if you could provide a testcase and sample file, or at least a very detailed list of things that are happening inside basesink to lead to this situation (e.g. a debug log with basesink:6 would be a good start, with some explanations what times are seen when and what would be expected instead).
Created attachment 304123 [details] compare basesink timestamp log I attached the log file about basesink:6 level. [Summary] I pushed REWIND command and wait until the video reached start point(0 sec). Then I can see the progress bar pop-up to any time position, not 0 sec. Because the last time is set "stop" value in gst_base_sink_get_position(), the progress bar is abnormal. -before basesink gstbasesink.c:4627:default_element_query:<videosink> position query in format time basesink gstbasesink.c:4416:gst_base_sink_get_position:<videosink> using clock and base time 0:37:31.851788888 basesink gstbasesink.c:4443:gst_base_sink_get_position:<videosink> in PAUSED using last 0:00:05.000000000 basesink gstbasesink.c:4477:gst_base_sink_get_position:<videosink> using last seen timestamp 0:00:05.000000000 basesink gstbasesink.c:4549:gst_base_sink_get_position:<videosink> res: 1, POSITION: 0:00:05.000000000 basesink gstbasesink.c:4746:default_element_query:<videosink> query position returns 1 ======> The progress bar is set by the last time value. It is set "5" sec, so the progress bar is pop-up this position. It need to start from "0" sec. -after patch basesink gstbasesink.c:4627:default_element_query:<videosink> position query in format time basesink gstbasesink.c:4416:gst_base_sink_get_position:<videosink> using clock and base time 0:46:34.971955555 basesink gstbasesink.c:4443:gst_base_sink_get_position:<videosink> in PAUSED using last 0:00:00.000000000 basesink gstbasesink.c:4477:gst_base_sink_get_position:<videosink> using last seen timestamp 0:00:00.000000000 basesink gstbasesink.c:4549:gst_base_sink_get_position:<videosink> res: 1, POSITION: 0:00:00.000000000 basesink gstbasesink.c:4746:default_element_query:<videosink> query position returns 1 ===> Then the last position is set the smallest time value. In REWIND case, the last time has to mean the smallest one that the basesink remembered.(In FORWARD case, it means the largest one.)
Required information has been provided. Setting back to NEW.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/79.