jpegparse required after multipartdemux?

[Nicolas Dufresne]

Le mer. 7 août 2019 04 h 10, Guillermo Rodriguez Garcia <
guille.rodriguez at gmail.com> a écrit :

> Hi Nicolas,
>
> El mié., 7 ago. 2019 a las 3:54, Nicolas Dufresne (<nicolas at ndufresne.ca>)
> escribió:
>
>> Le mardi 06 août 2019 à 10:54 +0200, Guillermo Rodriguez Garcia a
>> écrit :
>> > Hello all,
>> >
>> > I am trying to decode a live mjpeg stream from an IP camera using
>> souphttpsrc ! multipartdemux ! avdec_ffmpeg, but I get not-negotated errors:
>> >
>> > 0:00:01.216966334   326   0xaba920 WARN                 basesrc
>> gstbasesrc.c:3055:gst_base_src_loop:<souphttpsrc0> error: Internal data
>> stream error.
>> > 0:00:01.217129000   326   0xaba920 WARN                 basesrc
>> gstbasesrc.c:3055:gst_base_src_loop:<souphttpsrc0> error: streaming
>> stopped, reason not-negotiated (-4)
>> > ERROR: from element /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0:
>> Internal data stream error.
>> >
>> > If I add jpegparse between multipartdemux and avdec_ffmpeg, then all
>> works fine.
>> >
>> > But, once I add jpegparse, do I need multipartdemux at all ?
>> souphttpsrc ! jpegparse ! avdec_ffmpeg *also* seems to work fine. Is there
>> any reason to keep multipartdemux then?
>>
>> jpegparse is able to skip over corruption in between jpeg files, in
>> this case the multipart stuff. If you look at the templates,
>> avdec_mjpeg requires the field parsed=TRUE in the caps. That field is
>> used to indicate an already parsed (aka framed) jpeg stream. This is
>> needed as this element does not have a internal parser, unlike jpegdec.
>> Ideally there should be a way to get this field out of multipartdemux
>> if the content is frames, but I'm not familiar enough to give more
>> advise.
>>
>
> OK so jpegparse con handle the "demux" part by skipping over the "garbage"
> between frames (the multipart headers).
> It would then seem that multipartdemux is unnecessary if jpegparse is used.
>
> Or is there any advantage in keeping it? (for example, would it be more
> reliable, or perhaps faster?)
>

I don't have numbers to support it, but performance should be better if you
keep it.


>
>>
>> >
>> > Moreover, if I replace avdec_ffmpeg with jpegdec, then I don't seem to
>> need neither multipartdemux nor jpegparse; I can just have souphttpsrc !
>> jpegdec and that seems to work as well...
>>
>> jpegdec element has an internal parser. Note that it will be slower if
>> you pass random data then if you use multipartdemux.
>>
>
> I understand. Does the same also apply to jpegparse? (i.e. is it slower in
> skipping over the garbage than if I use multipartdemux?)
>
> How does jpegdec compare to avdec_ffmpeg? Which one is recommended? Any
> known drawbacks?
>
> Thank you,
>
> Guillermo Rodriguez Garcia
> guille.rodriguez at gmail.com
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190807/91e632a5/attachment-0001.html>