[Bug 763780] flvdemux: don't emit pad-added until caps are ready

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #1)
> Review of attachment 324135 [details] [review]:
> 
> Somehow it would be nice to describe the fix, it's rather simply as you only
> move some parsing earlier. Otherwise, looks good. We should consider this
> for 1.8.1 too.

Sure!

I am always expecting to be able to call gst_pad_get_current_caps in a
pad-added callback from a demuxer, to know what to link this pad onwards to.
Currently this is not the case for flvdemux, since you *do* get a pad-added for
H.264 and AAC even though the caps has not yet been decided. This forces you to
jump through hoops with adding an additional caps-event pad-probe in the
pad-added callback, and then being able to finally complete the linking on this
new callback. There are also issues with stream-start then being sent on a pad
that is not yet linked.

The proposed fix, as you say, is simply moving the special-casing for AAC and
H.264 to before the section of code that "adds the pad". If the caps can not
yet be determined, the code, as it used to, now jumps to "beach" (the end), but
because the section is moved, this does now also mean that the pad will not be
added as well.

The supplied tests uses a "generic" pad-added callback that will do
gst_pad_get_current_caps and fail if the caps is not present, making sure this
functionality is maintained even though the code might be refactored further!

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