GNOME Bugzilla – Bug 665887
multipartdemux: boundary specified manually but gst quits because "Boundary not found"
Last modified: 2018-11-03 14:45:04 UTC
I have a D-Link DCS-930L IP camera and when I get mjpeg from it, it looks something like this: # wget http://user:pass@192.168.1.15/video/mjpg.cgi mjpg.cgi contents: Content-length: 45536 Date: 10-04-2011 07:41:20 PM IO_00000000_PT_000_000 Content-type: image/jpeg (jpeg data) --video boundary-- Content-length: 45607 Date: 10-04-2011 07:41:20 PM IO_00000000_PT_000_000 Content-type: image/jpeg (jpeg data) So the boundary is "--video boundary--" - I try to specify this to gstreamer with: multipartdemux boundary="--video boundary--" Yet I still get the following whether I specify the boundary or not: Boundary not found in the multipart header ERROR: pipeline doesn't want to preroll.
Can you include a real sample (the elided one above will have wrong Content-length, the value of which is used by the element when scanning for the boundary).
Also, I think it should be: boundary="video boundary", ie without the leading and trailing double dashes, please try with that.
Oh wait... The first boundary has a "--" at the end. This is supposed to mark the end of the parts... See 7.2.1 in http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html. Then a boundary of "video boundary--" should work, though it will never see the end, but that might be OK in this case.
I tried multipartdemux boundary="video boundary--" - no difference. This for example works: ( echo "--video boundary--"; curl ${URL}mjpeg.cgi; ) | gst-launch -e -v \ matroskamux name=mux ! filesink location="out.mkv" \ fdsrc do-timestamp=true ! multipartdemux boundary="video boundary--" ! image/jpeg,width=640,height=480 ! mux. But if I use souphttpsrc, it just says: "Boundary not found in the multipart header" Here is live access to the specific IP camera: http://admin:@82.13.197.168:82/video.cgi
I just had a look at that stream, and you're right, it's just missing the boundary at start. However, looking at the RFC, this still might stilll be supposed to work, with the first image, in the absence of that boundary, to be considered to be a prologue. Since there is no "Content-type: multipart/mixed" in the stream, I'm far from certain what's the expected behavior...
It seems that right now gstreamer doesn't really care if there is a "Content-type: multipart/mixed" or not but strictly speaking, yeh, pretty shameful of D-Link not to include it in their multipart stream :( - unfortunately it isn't just D-Link and quite a range of IP cameras don't follow the RFC very well. FFMPEG and VLC don't appear to care and figure out the boundary on their own - at the very least it would be nice for gstreamer to not look for a boundary in the multipart header if a boundary is specified manually. What do you think?
Sorry, I was not commenting on the actual gst code, saying it would work if multipart/mixed was present, but on the RFC (of wihch I know just what I read the last few days, I'd never done anything with multipart stuff before). It would seem best if gst would parse this fine (though I'm always a bit wary of encouraging writing bad data by accepting it), I'm not sure yet of all the issues as I've only looked at this a few minutes at a time so far :)
Just tried latest git version and this is still a problem. This works fine: ( echo "--video boundary--"; curl http://admin@192.168.0.108/mjpeg.cgi; ) | gst-launch -e -v matroskamux name=mux ! filesink location="out.mkv" fdsrc do-timestamp=true ! multipartdemux boundary="video boundary--" ! image/jpeg,width=640,height=480 ! mux. However this does not: ( curl http://admin@192.168.0.108/mjpeg.cgi; ) | gst-launch -e -v matroskamux name=mux ! filesink location="out.mkv" fdsrc do-timestamp=true ! multipartdemux boundary="video boundary--" ! image/jpeg,width=640,height=480 ! mux. I get the error: Boundary not found in the multipart header. I still don't understand the rationale behind forcing a boundary in the header check when a boundary is provided manually via the "boundary" property. Anyone?
Nobody's hacked on it yet. The rationale is to follow the spec. Someone has to do the code to support this particular brokenness. Shouldn't be too long once someone gets to it.
Created attachment 208126 [details] [review] Patch to not ignore specified boundary This patch seems to fix the problem for me
Comment on attachment 208126 [details] [review] Patch to not ignore specified boundary [Fixing wrong mime type and set "patch" flag so it can be queried for.]
At a glance, that patch still seems valid but: * Quite a few changes went into multipartdemux so the patch should be rebased * It would be great to have a new test stream to test against Roman do you still have the stream available somewhere ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/52.