GNOME Bugzilla – Bug 604711
Handling of mime type in multipartdemux
Last modified: 2010-02-16 20:12:07 UTC
Created attachment 149828 [details] [review] Patch for the header parsing in multipartdemux The handing of the mime type within the "boundary" is a bit naive in multipartdemux. The standard for MIME allows parameters to follow the "type" / "subtype" clause separated from the mime type by ';'. This patch modifies the multipartdemuxer's header parsing so it doesnt assume the whole line after "content-type:" is the mime type and thus makes it a bit more resilient to finding absurd mime types in the case where parameters are added.
Did you have any particular problem? the 'mime-type' is only used for finding the different streams in a multipart file. I would guess that when there are multiple streams with the same mime-type but with different properties, your patch would consider both streams as equal.
Yes, it is from a real world problem. I receive an AAC stream from an previous generation network camera that sets the Content-Type as follows: --- --myboundary Content-Type: audio/mpeg4-generic; streamtype=5; profile-level-id=15; config=1588; mode=AAC-hbr; sizeLength=13; indexLength=3; indexDeltaLength=3; bitrate=32000 [data] --myboundary --- This leads to a caps that is not possible to use and ends up in the program dying to an ASSERT on caps != NULL. This small patch fixes at least this. The way I interpret the definition it's not illegal to use parameters in a multipart stream, and even if it is, Gstreamer should be able to handle it in a better way than dying to an ASSERT :-) PS The "mpeg4-generic" needs to be translated too, but that's a separate issue.
And yes, when I read you reply again. There probably should be code added to the demuxer to handle the actual parameters and make sane caps values out of them too. But IMHO this simple patch does not make things than they are atm.
"make things worse"*
commit 6a877b2e6daae21772768d1973fa801143d312e6 Author: Anders Skargren <anders.skargren at axis.com> Date: Tue Feb 16 21:05:24 2010 +0100 multipartdemux: improve header mime-type parsing Make the handing of the mime type within the "boundary" a bit less naive. The standard for MIME allows parameters to follow the "type" / "subtype" clause separated from the mime type by ';'. Modifies the multipartdemuxer's header parsing so it doesnt assume the whole line after "content-type:" is the mime type and thus makes it a bit more resilient to finding absurd mime types in the case where parameters are added. Fixes #604711