GStreamer-devel

jpegparse required after multipartdemux?

Classic

List

Threaded

5 messages Options

Guillermo Rodriguez Garcia-2

jpegparse required after multipartdemux?

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?

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...

I am a bit confused about the interaction between all these plugins. Also I checked the examples in the documentation, but that didn't help -- the docs for multipartdemux show an example pipeline that includes jpegparse, while the docs for a jpegparse show a similar example pipeline that does not include multipartdemux...

Is there a "canonical" or recommended way to decode a mjpeg stream from a live HTTP source?

Thank you,

Guillermo Rodriguez Garcia
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Nicolas Dufresne-5

Re: jpegparse required after multipartdemux?

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.

>
> 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 am a bit confused about the interaction between all these plugins. Also I checked the examples in the documentation, but that didn't help -- the docs for multipartdemux show an example pipeline that includes jpegparse, while the docs for a jpegparse show a similar example pipeline that does not include multipartdemux...
>
> Is there a "canonical" or recommended way to decode a mjpeg stream from a live HTTP source?
>
> Thank you,
>
> Guillermo Rodriguez Garcia
> [hidden email]
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Guillermo Rodriguez Garcia-2

Re: jpegparse required after multipartdemux?

Hi Nicolas,

El mié., 7 ago. 2019 a las 3:54, Nicolas Dufresne (<[hidden email]>) 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

[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Carlos Rafael Giani-2

Re: jpegparse required after multipartdemux?

In reply to this post by Guillermo Rodriguez Garcia-2

It is generally preferred to keep parsers and decoders separate. Older elements do both, newer elements don't (usually). This design allows for better modularity.

That's why there's also h264parse, h265parse, vc1parse, aacparse, mpegaudioparse etc. for example.

On 06.08.19 10:54, Guillermo Rodriguez Garcia wrote:

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?

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...

I am a bit confused about the interaction between all these plugins. Also I checked the examples in the documentation, but that didn't help -- the docs for multipartdemux show an example pipeline that includes jpegparse, while the docs for a jpegparse show a similar example pipeline that does not include multipartdemux...

Is there a "canonical" or recommended way to decode a mjpeg stream from a live HTTP source?

Thank you,

Guillermo Rodriguez Garcia
[hidden email]
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Nicolas Dufresne-5

Re: jpegparse required after multipartdemux?

In reply to this post by Guillermo Rodriguez Garcia-2

Le mer. 7 août 2019 04 h 10, Guillermo Rodriguez Garcia <[hidden email]> a écrit :

Hi Nicolas,

El mié., 7 ago. 2019 a las 3:54, Nicolas Dufresne (<[hidden email]>) 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
[hidden email]
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel