GNOME Bugzilla – Bug 701976
flvdemux: Forwards CAPS events from upstream
Last modified: 2013-06-11 10:30:50 UTC
I have attached a sample code. This is derived from the basic example at : http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-helloworld.html with the following changes : 1. audio elements were replaced with video 2. filesrc was replaced with appsrc & the code related to it I compiled this using : gcc -Wall -g ./gst_dynamic_padding_expt.c -g $(pkg-config --cflags --libs gstreamer-1.0) -lgstapp-1.0 -o dynamic_padding If I run this with a sample input flv file, I get "Internal data flow error" due to following reason : 1. After adding video pad of the demuxer dynamically, appsrc renegotiation is getting called 2. The caps video/x-flv are received by flvdemux sink & then forwarded to src pad 3. Src pad says that negotiation failed, and stores the event as pending since it is a sticky event 4. In future, whenever we try to push any data through the src pad, it checks all the pending sticky events & says that negotiation failed What am I missing here? Is it a bug in appsrc or flvdemux? Thanks in anticipation
Created attachment 246479 [details] example code The example code that gives error.
Sounds like a bug in flvdemux - it shouldn't forward the caps event received on its sink pad.
But I wonder why it doesn't happen in other cases as well, since linking source pads always sends a reconfigure event upstream.
commit ab275b62a8b3b0303fd121c734546d6789c844d0 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Tue Jun 11 12:25:46 2013 +0200 flvdemux: Don't forward CAPS events from upstream Just use the default pad event handler. https://bugzilla.gnome.org/show_bug.cgi?id=701976