jpegparse required after multipartdemux?

[Guillermo Rodriguez Garcia]

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?)


>
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190807/b32b86cc/attachment.html>