ffdec
Thierry Panthier
thierry.devel at gmail.com
Tue Nov 1 17:07:58 PDT 2011
Hi Tim,
Thanks for your quick reply. Here's a description of my pipeline:
udpsrc ! gstrtpbin ! rtpjpegdepay ! ffdec_mjpeg ! queue ! videoflip !
videocrop ! videoscale ! ffmpegcolorspace ! ximagesink
The entire application is written in Python.
I noticed this problem when I started running some stress tests.
Basically I create this pipeline and then I enter a loop setting it to
READY => PAUSED => PLAYING and then PAUSED => READY => NULL.
If my computer is _only_ running this test then everything works
perfectly fine. It's when I start other processes and the CPU usage
goes really high that the execution flow path changes (at least
according to the GStreamer logs).
I've been using GStreamer for a while now and I quite like it but I
don't have much experience with plugin development. By taking a look
at my pipeline would you be able to "guess" where the problem might
be? I can spend more time looking the at the logs and the source code
but I have no idea where to start.
BTW if I switch from ffdec_mjpeg to jpegdec the pipeline *never*
fails. But jpegdec is a lot more CPU intense than ffdec_mjpeg and I'm
decoding 6 streams simultaneously, which does make a difference.
I'm using the GStreamer 0.10.35.
Regards,
Thierry
On Wed, Nov 2, 2011 at 10:19 AM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> On Wed, 2011-11-02 at 09:58 +1100, Thierry Panthier wrote:
>
> Hi Thierry,
>
>> I'm using the latest version of gst-ffmpeg (0.10.12) and I've been
>> getting the following error from ffdec_mjpeg:
>>
>> "ffmpeg gstffmpegdec.c:2748:gst_ffmpegdec_chain:<ffdec_mjpeg7>
>> warning: ffdec_mjpeg: input format was not set before data start"
>>
>> This only happens in certain scenarios, normally when the system is
>> busy (over 50% of CPU usage).
>>
>> After adding more verbose logging to gstffmpegdec.c I found out that
>> *sometimes* the function "gst_ffmpegdec_chain" gets called *before*
>> the function "gst_ffmpegdec_setcaps".
>>
>> Why this happens I still don't know. It might be because of the
>> multi-threaded nature of GStreamer but at the moment I don't have time
>> to debug the rest of the library.
>>
>> The problem is that "gst_ffmpegdec_setcaps" is responsible for calling
>> "gst_ffmpegdec_open", which initializes the decoder. And since the
>> decoder is not initialized when "gst_ffmpegdec_chain" is called, the
>> function raises an error and returns GST_FLOW_ERROR.
>>
>> So I implemented a small patch that simply prints a warning message
>> and discards the buffer when that happens. The plugin now works fine
>> for me.
>>
>> I'd like to know if you agree with this implementation.
>
> This doesn't sound right at first glance.
>
> It sounds like the problem is upstream. It should've sent a buffer with
> caps set on it. There might be a problem with an element upstream and/or
> you're missing a typefind element or parser somewhere.
>
> Cheers
> -Tim
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
More information about the gstreamer-devel
mailing list