GNOME Bugzilla – Bug 753661
dashdemux: Reverse playback doesn't work well
Last modified: 2015-08-16 13:38:45 UTC
See the validate.dash.playback.reverse_playback.* tests ========================================= Running scenario seek_backward on pipeline playbin0 ========================================= Executing (subaction) seek: name=Backward-seek playback-time=0:00:05.000000000 rate=1 start=0:00:00.000000000 flags=accurate+flush Executing (subaction) seek: name=Backward-seek playback-time=0:00:10.000000000 rate=1 start=0:00:05.000000000 flags=accurate+flush Executing (subaction) seek: name=Backward-seek playback-time=0:00:15.000000000 rate=1 start=0:00:10.000000000 flags=accurate+flush Executing (subaction) stop: playback-time=0:00:15.000000000 ed: 1,000000 /> seek_backward --> State change request NULL, quiting mainloop warning : buffer timestamp is out of the received buffer timestamps' range Detected on <avdec_aac0:src> Description : a buffer leaving an element should have its timestamps in the range of the received buffers timestamps. i.e. If an element received buffers with timestamps from 0s to 10s, it can't push a buffer with with a 11s timestamp, because it doesn't have data for that issue : SEGMENT events that are part of the same pipeline 'operation' should have the same seqnum Detected on <souphttpsrc0:src> Detected on <souphttpsrc1:src> Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum warning : a field in caps has an unexpected value Detected on <avdec_aac0:src> Description : fields set on a sink pad should be propagated downstream via set caps warning : a serialized event received should be pushed in the same order as it was received Detected on <aacparse0:src> Description : serialized events should be pushed in the same order they are received. warning : received the same caps twice Detected on <avdec_aac0:sink> Detected on <avdec_h264-0:sink> Issues found: 5
Actually this was just me being confused and putting the wrong log here, this the issue is with reverse playback and not reverse seeking.
commit ae5befef5f2c148c7358c7413ff7dd8e24f1e3db Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Sun Aug 16 08:49:35 2015 -0300 dashdemux: fix off by one seeking issue When seeking to the last second of a mpd it would reject the seek because the comparison was < instead of <= This fails the important use case of seeking to the end of a file to play it back in reverse from the end