GNOME Bugzilla – Bug 667116
inputselector: wrong segment processing on gst_input_selector_set_active_pad
Last modified: 2013-11-18 14:27:21 UTC
There is a segment that is not properly processed on gst_input_selector_set_active_pad on input-selector element at frequent input source change. If there is no subsequent call of gst_selector_pad_chain between two gst_input_selector_set_active_pad function call, second gst_input_selector_set_active_pad call make wrong NEWSEGMENT event to a fallowing basesink element. Fallowing patch may fix this bug. Index: plugins/elements/gstinputselector.c =================================================================== --- plugins/elements/gstinputselector.c (revision 39354) +++ plugins/elements/gstinputselector.c (working copy) @@ -1038,6 +1038,7 @@ GST_TIME_ARGS (start_time)); /* schedule a new segment push */ gst_segment_set_start (&new->segment, start_time); + gst_segment_set_last_stop (&new->segment, new->segment.format, start_time); new->segment_pending = TRUE; }
I think this makes sense. Looking at the code, the following may be a better way to fix the issue, as _set_start and _set_last_stop do not use the same "base" for timestamps (_set_last_stop uses the given time directly, but _set_start transforms it from accum, rate, and segment start). I'm far from comfortable with segments though, so won't say my patch is fully correct. Does it also fix your issue ? diff --git a/plugins/elements/gstinputselector.c b/plugins/elements/gstinputselector.c index 4da4735..a74871c 100644 --- a/plugins/elements/gstinputselector.c +++ b/plugins/elements/gstinputselector.c @@ -1190,6 +1190,8 @@ gst_segment_set_start (GstSegment * segment, gint64 running_time) /* move position in the segment */ segment->time += duration; segment->start += duration; + if (segment->last_stop < 0 || new_start > segment->last_stop) + segment->last_stop = new_start; } /* this function must be called with the SELECTOR_LOCK. It returns TRUE when the
Hyunwoo.Park, does patch from comment#1 fix crash as well ?
Akhil Laddha, I don't have enough time to test the patch. But, my one is applied to LG Smart TV and, it does not make any problem on the TV. And it will take time to test the patch, comment 1. Vincent Penquerc'h, Above issue can be easly reproducable on a video file that has multi internal subtitle track such as divx. When the subtitle trach change frequently without data passing through the input selector, fallowing subtitles are not synced with video. If your patch also fix this issue, it will ok to replace my one.
I tried changing subtitles at a moment where no subtitles appear, twice in a row, then wait for the next subtitles to appear. I do not see out of sync subtitles in the first place, so can't tell whether my patch would fix the issue. Since your patch fixes an issue you're seeing, and I'm not totally certain about mine, it's best to merge your patch, so I'm putting this in NEW for now, and hope someone who's comfortable with segments may comment.
Not sure how exactly this fixes anything but I'll take a look at this tomorrow. Do you have debug logs or anything for this issue?
If I understand the problem correctly this would be solved be sending *all* pending newsegment events (from all the stream changes that happened since last _chain()) downstream instead of just the latest.
Is this still relevant with 1.0 ?
I believe this is fixed in 1.x. Please re-open if this is not the case, thanks!