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 699972 - videodecoder: Output segment can be undefined before a call to gst_segment_clip
videodecoder: Output segment can be undefined before a call to gst_segment_clip
Status: RESOLVED DUPLICATE of bug 702502
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 701391
 
 
Reported: 2013-05-09 01:41 UTC by Mathieu Duponchelle
Modified: 2013-07-11 08:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch to fix the issue (1008 bytes, patch)
2013-05-09 01:44 UTC, Mathieu Duponchelle
rejected Details | Review

Description Mathieu Duponchelle 2013-05-09 01:41:40 UTC
The order of operation is : get a new segment, flush the decoder, which sets output_segment.format to UNDEFINED, then gst_video_decoder_clip_and_push_buf tries to clip the output_segment and fails.

The proposed patch fixes the issue, I don't know if it's correct.
Comment 1 Mathieu Duponchelle 2013-05-09 01:44:30 UTC
Created attachment 243658 [details] [review]
Proposed patch to fix the issue
Comment 2 Sebastian Dröge (slomo) 2013-05-09 14:15:33 UTC
Review of attachment 243658 [details] [review]:

This is not correct, you should set the output segment only from the output side of things, not the input side.

Also receiving a new segment event will not reset the segments, only when gst_video_decoder_flush() is called with TRUE it will do that. Or am I missing something here? How can it be reproduced?

::: gst-libs/gst/video/gstvideodecoder.c
@@ +2000,2 @@
         g_list_prepend (decoder->priv->current_frame_events, event);
   }

Right above this here the input segment is initialized and a segment event is enqueued. This will cause the output segment to be set later when a frame is finished.
Comment 3 Mathieu Duponchelle 2013-05-09 22:00:59 UTC
That was a bad observation on my part sorry, fixed in #699960.
Comment 4 Mathieu Duponchelle 2013-05-09 22:05:22 UTC
Oh I'm sorry actually still reproducible, by running my branch :
https://github.com/MathieuDuponchelle/PitiviGes/tree/rendering
and GST_DEBUG=test_transition make ges/render.check , in the second test suite run with ogv files
Comment 5 Sebastian Dröge (slomo) 2013-05-13 10:12:24 UTC
This test seems to be racy in general btw, I get many different g_warnings() each run about different things :)
Comment 6 Sebastian Dröge (slomo) 2013-05-13 10:18:48 UTC
Ok, I can't really debug with this because it's exploding in thousands of places elsewhere too :) Could you please clean up this test case or provide a new one that only triggers this error?
Comment 7 Sebastian Dröge (slomo) 2013-05-23 20:50:14 UTC
I was able to reproduce this in bug #700537
Comment 8 Sebastian Dröge (slomo) 2013-06-18 11:14:21 UTC
Bug #702502 has a potential patch for the segment_clip warning.
Comment 9 Sebastian Dröge (slomo) 2013-07-10 07:57:29 UTC
Mathieu, any news here?
Comment 10 Mathieu Duponchelle 2013-07-10 18:43:31 UTC
(In reply to comment #8)
> Bug #702502 has a potential patch for the segment_clip warning.

Edward's patch removed that bug for us.
Comment 11 Sebastian Dröge (slomo) 2013-07-11 08:03:18 UTC
Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.

*** This bug has been marked as a duplicate of bug 702502 ***