GNOME Bugzilla – Bug 318663
http mjpeg stream from axis 213 PTZ camera
Last modified: 2006-12-10 19:41:53 UTC
Please describe the problem: stream is not displayed when trying to read from a axis 213 ptz ip camera. Steps to reproduce: 1. gst-launch gnomevfssrc location=http://192.168.0.2/axis-cgi/mjpg/video.cgi?resolution=CIF ! multipartdemux ! jpegdec ! ffmpegcolorspace ! xvideosink 2. 3. Actual results: Can't see the stream Expected results: Does this happen every time? Other information: More docs about the http commands can be found here: http://www.axis.com/techsup/cam_servers/dev/cam_http_api_index.htm
Created attachment 53367 [details] stream from camera
the problem seems to be the following (thx for the help on irc) static gchar *toFind = "--ThisRandomString\nContent-type: "; This --ThisRandomString is --myboundary in the axis header. Why can't we just put this: static gchar *toFind = "Content-type: "; or make a property boundary="--myboundary" for the element.
Updating to 0.9. This is really peculiar, the server sends in fact multipart via http. This is more a problem in gnomevfssrc.... but how would they handle that ? It's one URI, therefore it should only return one file (and not multiple)... http://www.axis.com/techsup/cam_servers/dev/cam_http_api.htm#api_blocks_jpeg_mjpg_mjpg_response
Created attachment 55809 [details] [review] make it works in cvs head This patch: - remove the hardcoded prefix - add a "prefix" property. The default is the old hardcoded one. - add a "autoscan" property (default false). If you set the autoscan to true it tries to find the prefix looking at the beginning of the first buffer. - add a finalize function to free the prefix I can now play the file using: ./gstreamer/tools/gst-launch-0.10 filesrc location="/home/luogni/stream.mjpg" ! multipartdemux autoscan=true ! image/jpeg,framerate:fraction=10/1 ! jpegdec ! ffmpegcolorspace ! ximagesink or ./gstreamer/tools/gst-launch-0.10 filesrc location="/home/luogni/stream.mjpg" ! multipartdemux prefix="boundary" ! image/jpeg,framerate:fraction=10/1 ! jpegdec ! ffmpegcolorspace ! ximagesink
it would be nice also to have a typefind function for these streams (multipart). Would this be possible ?
These files start with something like: PREFIX\r\nsome_http_like_options\r\n\r\n Then there is the data, \r\n and then a new header. The prefix always (at least in every ip camera that i've seen) starts with "--" We can do an alg that looks for: --\s+\r\n\s+\r\n\r\n I can work on a similar alg if you think it would be ok. If we do typefinding we should also enable multipartdemux's autoscan feature by default. Would this break element compatibility ?
Created attachment 56116 [details] [review] updated patch against current cvs
*** Bug 324382 has been marked as a duplicate of this bug. ***
There are some problem with a pipeline like: /home/luogni/Sorgenti/devel/0.9/gstreamer/tools/gst-launch-0.10 gnomevfssrc location=http://stareat.it.helsinki.fi/mjpg/video.mjpg ! multipartdemux prefix=boundary ! identity ! jpegdec ! fakesink -v We should see the same amount of buffers on identity and on fakesink. Instead it seems that jpegdec "eats" some buffers.. I don't know if it's a problem with multipartdemux or with jpegdec or just a broken stream (firefox can play it w/o problems)
jpegdec's parser seems to be a bit generous when resyncing to the next jpeg frame, so there's definitively a bug in jpegdec as well (it should do the right thing in this case even without the multipartdemux element in a perfect world). However, multipartdemux should probably also add a 'framed=true' value to the caps or something like that, that would by-pass jpegdec's parsing and be more efficient (jpegdec would need to be fixed to honour that, but that's a 2-line change in its setcaps function; currently it only assumes framed input when the sink pad caps have a framerate set).
anoying thing really.. the boundary string is normally conveyed to the demuxer in the http response headers. gnomevfssrc does not really pass that info along. A property is a bit useless, scanning looks nicer although I have no idea how many false positives it gives.
ok, tested and it gives quite a few false positives currently. It should probably also scan for Content-type: after the \r\n etc.
* gst/multipart/multipartdemux.c: (gst_multipart_demux_base_init), (gst_multipart_demux_class_init), (gst_multipart_demux_init), (gst_multipart_demux_finalize), (gst_multipart_find_pad_by_mime), (gst_multipart_demux_chain), (gst_multipart_demux_change_state), (gst_multipart_set_property), (gst_multipart_get_property): Applied #318663. Gives quite a few false positives in autoscan mode, but it's better than nothing. Not closing yet.
does this work?
What's the status here? Can this be closed or is there anything that should still be implemented?
closing, reopen if needed info was given.