GNOME Bugzilla – Bug 558261
[mp3parse] could fix quickly the src caps
Last modified: 2010-12-27 00:25:11 UTC
if sink caps inform mp3parse about stream capabilities we could perform more quickly the resolution src caps. We don't need wait for the first buffers to fix src caps so decodebin could select a decoder more quickly. Other information:
Created attachment 121520 [details] [review] patch to quickly fix src caps
Hi, thanks for the patch. This makes sense in theory but you should better implement this in the setcaps function of the pad.
Hi, I have done this in set_link_function to avoid this case in decodebin: decodebin gstdecodebin.c:1002:close_pad_link:<mpegaudioparse0:src> many possible types decodebin gstdecodebin.c:1007:close_pad_link:<mpegaudioparse0:src> setting up a delayed link By setting src caps only at sink set_caps the selection of an audio decoder by decodebin is perform later on the first buffer. The caps are already knows when the link pad function is call so the decodebin could select the next element in the graph sooner. this solve some issues with when queue-size property of playbin it set at very low values. I will provide a patch for set caps function and link function, I hope it will be more acceptable.
Created attachment 123320 [details] [review] mp3parse patch
It is not a good idea to do this because all of those redundant properties in the caps can change for each buffer.
the case of changing properties in the caps for each buffer is still manage gst_mp3parse_chain function, this patch doesn't change this. it's only set sooner the source pad caps.
Is the patch acceptable ? or should I rework it ?
I'm not sure, we don't usually want to do negotiation in the link function.
No action for ages, closing this as INCOMPLETE or WONTFIX. Issues with the patch: - negotiation in the link function - GST_PAD_LINK_OK is not a gboolean - mp3parse in -ugly is being replaced with mpegaudioparse from -bad/gst/audioparsers/