After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 604711 - Handling of mime type in multipartdemux
Handling of mime type in multipartdemux
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.16
Other Linux
: Normal normal
: 0.10.19
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-12-16 12:22 UTC by Anders Skargren
Modified: 2010-02-16 20:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for the header parsing in multipartdemux (1.29 KB, patch)
2009-12-16 12:22 UTC, Anders Skargren
none Details | Review

Description Anders Skargren 2009-12-16 12:22:22 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.
Comment 1 Wim Taymans 2009-12-17 16:15:24 UTC
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.
Comment 2 Anders Skargren 2009-12-21 08:31:47 UTC
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.
Comment 3 Anders Skargren 2009-12-21 15:14:04 UTC
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.
Comment 4 Anders Skargren 2009-12-21 15:15:01 UTC
"make things worse"*
Comment 5 Wim Taymans 2010-02-16 20:12:07 UTC
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