After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701391 - Reverse playback not working
Reverse playback not working
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
1.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 699972 700537 701813
Blocks:
 
 
Reported: 2013-05-31 20:03 UTC by Nicolas Dufresne (ndufresne)
Modified: 2013-10-01 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicolas Dufresne (ndufresne) 2013-05-31 20:03:49 UTC 
While trying to test some reverse playback cases in GNonLin (git master), we endup not being to do reverse playback with any thing. Using gst-plugins-base/tests/examples/playback seems to expose issues. So far I have tested this video and videotestsrc.

http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4

I'm creating this bug as this may need larger investigation. An assertion that is visible in mostly all cases is:

GStreamer-CRITICAL **: gst_segment_clip: assertion `segment->format == format' failed

to be continued ...
Comment 1 Tim-Philipp Müller 2013-05-31 22:07:05 UTC 
I think there might be a bug for this already
Comment 2 Wim Taymans 2013-06-04 08:28:06 UTC 
It's something in the video decoder base class. The input segment event is stored in the current_frame_events lists but because there is never a new frame created (somehow) the segment never gets pushed on the srcpad and clipping fails.
Comment 3 Nicolas Dufresne (ndufresne) 2013-06-04 14:38:27 UTC 
So that one could have been newly introduced by the event ordering fixes. I think it's worth keeping it open then.
Comment 4 Sebastian Dröge (slomo) 2013-06-04 14:58:26 UTC 
Hm, if no new frame is created, how is it finishing a frame at all then? If it's an old frame that is finished, it would mean that the segment event arrived after the input buffer that created the segment
Comment 5 Sebastian Dröge (slomo) 2013-06-07 11:06:25 UTC 
There are some other bugs about this already btw, especially about this assertion: bug #699972 and bug #700537
Comment 6 Nicolas Dufresne (ndufresne) 2013-06-07 14:39:31 UTC 
The direction relation with reverse playback is not obvious to me. So instead of marking as dup, I suggest adding dependencies for tracking. The end goal is to regain reverse playback, and track the progress.
Comment 7 Sebastian Dröge (slomo) 2013-06-10 11:42:44 UTC 
Yes, there's probably more than just this involved here. My guess for the relation between these problems would be, that the segment event is attached to the frame with the lowest timestamp... which in the reverse playback case would be the last frame of a GOP that is actually pushed.
Comment 8 Sebastian Dröge (slomo) 2013-06-18 11:14:09 UTC 
Bug #702502 has a potential patch for the segment_clip warning.
Comment 9 Nicolas Dufresne (ndufresne) 2013-10-01 14:13:04 UTC 
This seems to work for most file now except mkv, so there is not generalized regression anymore, shall be close ?
Comment 10 Tim-Philipp Müller 2013-10-01 14:49:12 UTC 
Let's close it then.

If there are still issues, it's best to file them specific to the demuxer (plus parser plus decoder) in question.