GNOME Bugzilla – Bug 606859
Get mp4mux request pad during decodebin2's new-decoded-pad event fails.
Last modified: 2010-01-13 18:43:23 UTC
Created attachment 151343 [details] Example program that illustrates the failure. I'm filing this bug by request of Mark Nauwelaerts on the GStreamer mailing list message titled 'Requesting a sink pad from a muxer in the "new-decoded-pad" callback?' (http://sourceforge.net/mailarchive/forum.php?thread_name=de4879e81001130224l19645a9flb9e223fb51b13904@mail.gmail.com&forum_name=gstreamer-devel). The function gst_element_get_request_pad on an mp4mux element fails if called during the "new-decoded-pad" event.
Created attachment 151344 [details] Test wmv file A very simple wmv file containing only one video stream. It is sufficient to illustrate the problem.
Edit: bug report was requested by Thiago Sousa Santos, not Mark.
As mentioned, the recommended (and really safe) approach is to ensure the muxer does not reach PAUSED state until all the request pads are properly setup, which the attached sample program does not do. On the other hand, there are situations where qtmux might complain more than other muxers and as such also more than is actually convenient (e.g. in case of some basic gst-launch remuxing pipeline). As such, for sake of more consistency and convenience, following commit relaxes request_new_pad check somewhat. Note that such relaxing opens the door for 'programming approaches' that may or may not (depending on non-deterministic threading effects) turn out to work, or may happen to work because one is 'protected' by decodebin2 mechanics etc [though if qtmux happens not to complain in a particular instance/case, it still means one should be ok in that particular run] commit dbc1f9f2d66fd282e61baca0977361510f457a90 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Jan 13 19:30:45 2010 +0100 qtmux: provide request pads under wider conditions Fixes #606859.