Souphttpsrc 'error: Server does not support seeking'

[Hans Maree]

Hi,

I'm recording a mjpeg stream from an ip-camera using the following pipeline:

souphttpsrc location='http://172.23.42.161/videostream.cgi?rate=15' do-timestamp=true is_live=true timeout=5 ! multipartdemux ! image/jpeg,width=640,height=480,framerate=1 ! matroskamux ! filesink location=test.mkv

I have implemented this pipeline using pygst: http://pastebin.com/6FHEraPm

At first it seems to work fine but after what seems to be a random amount of time the recording stops and the logs show the message:

gstsouphttpsrc.c:874:gst_soup_http_src_got_headers_cb:<source> error: Server does not support seeking.
gstsouphttpsrc.c:874:gst_soup_http_src_got_headers_cb:<source> error: Server does not accept Range HTTP header, URL: http://172.23.42.161/videostream.cgi?rate=15

I've included the full output (with many repetitive lines removed) of the command:

GST_DEBUG=3,python:5,gnl*:5 ./record.py

here:
http://pastebin.com/Rcwkw4pY

The command:

gst-launch-0.10 -evt --gst-debug-level=3 souphttpsrc location='http://172.23.42.161/videostream.cgi?rate=15' do-timestamp=true is_live=true timeout=5 ! multipartdemux ! image/jpeg,width=640,height=480,framerate=1 ! matroskamux ! filesink location=test.mkv

gives similar results, but seems to run longer, although this may be coincidence.

I've looked at gstsouphttpsrc.c to see where it goes wrong, but I can't quite figure it out, because I'm not familiar with the gstreamer source code.

Any help would be greatly appreciated,
Hans

[Hans Maree]

After some further investigation using tcpdump and wireshark I tracked down the
source of the errors. It seems that the connection is interrupted (It is a
wireless connection so this happens from time to time) just before the errors
occur.

The souphttpsrc element then sends a new request to the ip-camera as expected,
however it adds a Range HTTP header field to the request. The ip-camera ignores
the Range header field since it serves a live stream. The souphttpsrc then
sends the warnings I mentioned in my previous post and closes the connection.

So this seems to be a bug in souphttpsrc, since I have indicated that the
source is a live source by specifying 'is_live=true', so to my understanding it
should not try to seek at all, or at least not break when the server ignores
the Range header field.

Before I file a bug report I would like to be sure it is indeed a bug, so
please give some feedback on that matter.  Also does anyone know a workaround
to this problem? I am using the ip-camera as security camera so I would like to
make it reliable as soon as possible.

By the way I am using the following versions of gstreamer and plugins:
gstreamer0.10 0.10.35.2 (pre release)
gstreamer0.10-base 0.10.35.2 (pre release)
gstreamer0.10-base-plugins 0.10.35.2 (pre release)
gstreamer0.10-good 0.10.30.2 (pre release)

[Mailing List SVR]

Il 02/01/2012 20:54, Hans Maree ha scritto:

After some further investigation using tcpdump and wireshark I tracked down
the
source of the errors. It seems that the connection is interrupted (It is a
wireless connection so this happens from time to time) just before the
errors
occur.

The souphttpsrc element then sends a new request to the ip-camera as
expected,
however it adds a Range HTTP header field to the request. The ip-camera
ignores
the Range header field since it serves a live stream. The souphttpsrc then
sends the warnings I mentioned in my previous post and closes the
connection.

So this seems to be a bug in souphttpsrc, since I have indicated that the
source is a live source by specifying 'is_live=true', so to my understanding
it
should not try to seek at all, or at least not break when the server ignores
the Range header field.

Before I file a bug report I would like to be sure it is indeed a bug, so
please give some feedback on that matter.  Also does anyone know a
workaround
to this problem? I am using the ip-camera as security camera so I would like
to
make it reliable as soon as possible.

I think this is a bug too, in souphttpsrc there is something like this:

/* The server disconnected while streaming. Reconnect and seeking to the
     * last location. */
    src->retry = TRUE;

instead souphttpsrc should retry the connection without seeking for a live stream,

reading the souphttpsrc code seems there is a lot of code for seeking, this should be completly disabled for live sources,

I should open a bug,

Nicola

By the way I am using the following versions of gstreamer and plugins:
gstreamer0.10 0.10.35.2 (pre release) 
gstreamer0.10-base 0.10.35.2 (pre release)
gstreamer0.10-base-plugins 0.10.35.2 (pre release)
gstreamer0.10-good 0.10.30.2 (pre release)

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Souphttpsrc-error-Server-does-not-support-seeking-tp4239793p4254350.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Mailing List SVR]

Il 02/01/2012 20:54, Hans Maree ha scritto:

> After some further investigation using tcpdump and wireshark I tracked down
> the
> source of the errors. It seems that the connection is interrupted (It is a
> wireless connection so this happens from time to time) just before the
> errors
> occur.
>
> The souphttpsrc element then sends a new request to the ip-camera as
> expected,
> however it adds a Range HTTP header field to the request. The ip-camera
> ignores
> the Range header field since it serves a live stream. The souphttpsrc then
> sends the warnings I mentioned in my previous post and closes the
> connection.
>
> So this seems to be a bug in souphttpsrc, since I have indicated that the
> source is a live source by specifying 'is_live=true', so to my understanding
> it
> should not try to seek at all, or at least not break when the server ignores
> the Range header field.
>
> Before I file a bug report I would like to be sure it is indeed a bug, so
> please give some feedback on that matter.  Also does anyone know a
> workaround
> to this problem?

as workaround try this:

curl --retry 3 http://172.23.42.161/videostream.cgi?rate=15 | gst-launch
-v fdsrc do-timestamp=true ! multipartdemux ! jpegdec ! xvimagesink
sync=false

and report us if this continue to work when souphttpsrc fails,

thanks
Nicola

> I am using the ip-camera as security camera so I would like
> to
> make it reliable as soon as possible.
>
> By the way I am using the following versions of gstreamer and plugins:
> gstreamer0.10 0.10.35.2 (pre release)
> gstreamer0.10-base 0.10.35.2 (pre release)
> gstreamer0.10-base-plugins 0.10.35.2 (pre release)
> gstreamer0.10-good 0.10.30.2 (pre release)
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Souphttpsrc-error-Server-does-not-support-seeking-tp4239793p4254350.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

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

[Hans Maree]

Filed a bug report of the issue:
https://bugzilla.gnome.org/show_bug.cgi?id=667175