SoupHttpSrc and MJPEG Source

[RobAtBCIS]

I have an Http MJPEG Source that is providing video to my pipeline.
SoupHttpSrc ! MultipartDemux ! JpegDec ! AutoVideoSink

If the video has movement then no issue at all, the video will keep up like expected.
However when the Source notices no movement it will stop sending MJPEG frames and then when movement come back it will begin again.
The AutoVideoSink will not pick back up showing the new movement.
It can take 5-10 seconds before the video will show 'live' again and all the movement within that time is never shown.
I know the Source is sending the new frames because their Web Browser picks up the new video changes.
Wireshark also show the receiving of the packets

I have tried most of the settings but no combination works.
SoupHttpSrc
  * is-live
  * do-timestamp
  * keep-alive
  * tried reducing the blocksize
MultipartDemux
  * single-stream

I just updated to 1.8 from 1.6.3 to see if it would help but it did not.

Any other options to stream an HTTP MJPEG Source.  This source requires cookies, authorization and other settings that the SOUP can handle (multiple extra-headers entries).
Any Suggestions would be appreciated.
Thanks

[Sebastian Dröge-3]

On Fr, 2016-04-15 at 08:58 -0700, RobAtBCIS wrote:

> I have an Http MJPEG Source that is providing video to my pipeline.
> SoupHttpSrc ! MultipartDemux ! JpegDec ! AutoVideoSink
>
> If the video has movement then no issue at all, the video will keep up like
> expected.
> However when the Source notices no movement it will stop sending MJPEG
> frames and then when movement come back it will begin again.
> The AutoVideoSink will not pick back up showing the new movement.
> It can take 5-10 seconds before the video will show 'live' again and all the
> movement within that time is never shown.
> I know the Source is sending the new frames because their Web Browser picks
> up the new video changes.
> Wireshark also show the receiving of the packets

Can you run with a fakesink silent=false and the -v flag on gst-launch-
1.0? This is most likely a timestamp problem, for each frame a
continuous timestamp is probably created which then makes all the
frames after the pausing be too late.

Using sync=false on the video sink should work as a workaround, but
that's not really a solution and has other problems in general. Can you
report this in bugzilla too?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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