[Bug 743973] playbin: Need replace suburidecoderbin's segment with normal uridecoderbin's segment

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=743973

--- Comment #12 from kevin <kevinbing.song at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> Review of attachment 301147 [details] [review]:
> 
> Please describe in more detail what this is supposed to fix, and in which
> situation this problem can appear
> 

External subtitle don't sync with Audio/Video after seek. The root cause is
external subtitle's segment is different with Audio/Video's segment after seek.
The solution is replace subtitle's segment with Audio/Video's segment.

> ::: gst/playback/gstplaybin2.c
> @@ +3055,3 @@
> +
> +        GST_SOURCE_GROUP_LOCK (group);
> +        _uridecodebin_event_probe_wait (group);
> 
> I think it's cleaner to use a blocking pad probe for this instead of using a
> custom cond. Especially a block pad probe will handle things properly for
> flushing and pad deactivation
> 

Accept. Can reuse function gst_play_bin_suburidecodebin_block() to block the
subtitle segment event? When we should add the block probe? Add the block probe
when playbin received seed event?

> @@ +3058,3 @@
> +        if (segment.format == GST_FORMAT_TIME) {
> +          segment.start = group->nonsub_segment.start;
> +          segment.time = group->nonsub_segment.time;
> 
> Why only these two? Should probably replace the whole segment
> 
Accept.
> @@ +5322,3 @@
>        }
>        gst_element_set_state (suburidecodebin, GST_STATE_READY);
> +      g_cond_init (&group->suburidecodebin_segment_cond);
> 
> Here you would init the cond on every group switch... it should only be done
> exactly once when playbin is created (and then cleared in finalize)
> 
Needn't custom cond any more.
> @@ +5500,3 @@
> +    group->got_nonsub_segment = TRUE;
> +    g_cond_broadcast (&group->suburidecodebin_segment_cond);
> +    g_cond_clear (&group->suburidecodebin_segment_cond);
> 
> Especially this will probably cause problems as at this time another thread
> is actually still using the cond
Needn't custom cond any more.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.