Bug 1608

Created attachment 1086 [details] [review]
Sniff and glob for 3GP

Urgh, it turns out that this isn't QuickTime, but just looks a lot like QuickTime.

Fight over -- this is The Right Thing to do.

And from the database of file(1), you'll find the following additional top-level
atoms (ie. all those could be used to find a QuickTime file):

# Apple Quicktime: Scan for all known top-level QT atom markers
4       string          moov            Apple QuickTime movie file (moov)
4       string          mdat            Apple QuickTime movie file (mdat)
4       string          ftyp            Apple QuickTime movie file (ftyp)
4       string          free            Apple QuickTime movie file (free)
4       string          junk            Apple QuickTime movie file (junk)
4       string          pnot            Apple QuickTime movie file (pnot)
4       string          skip            Apple QuickTime movie file (skip)
4       string          wide            Apple QuickTime movie file (wide)
4       string          pict            Apple QuickTime movie file (pict)

At least moov, mdat and ftyp should be in the database, they are the more common
ones.

IANA MIME Media Types and RFC 3839 recommend audio/3gpp and video/3gpp for those
files, not video/quicktime.

http://www.iana.org/assignments/media-types/
http://www.rfc-editor.org/rfc/rfc3839.txt

Stanislav, it's again an "alias" issue.
All 3gpp movies and audio files are quicktime (it's an MPEG-4, ie. Quicktime
container), but not all quicktime are 3gpp.
There's no way to know whether it's a 3gpp file without opening it.
See also bug #1272.

Looking at exact wording of RFC 2045 and RFC 2046, all container data types
should be application/ or multipart/. But IANA registry contain some container
data types, which has different type. It causes problems in Nautilus, if
shared-mime-info for container data type contains magic, but for contents data
type not: video/quicktime (can be a problem for video/3gpp), image/tiff (is a
problem for unregistered image/x-dcraw .nef), text/xml (is a problem for
text/html and can be problem for image/svg), text/sgml etc...

Nautilus is also not familiar with this "conflict exception" for application/
and multipart/ and rejects to open many file types.

Is "alias" keyword usable (and indented) for these situations?

From RFC:

   In general, the top-level media type is used to declare the general
   type of data, while the subtype specifies a specific format for that
   type of data.  Thus, a media type of "image/xyz" is enough to tell a
   user agent that the data is an image, even if the user agent has no
   knowledge of the specific image format "xyz".  Such information can
   be used, for example, to decide whether or not to show a user the raw
   data from an unrecognized subtype -- such an action might be
   reasonable for unrecognized subtypes of text, but not for
   unrecognized subtypes of image or audio.  For this reason, registered
   subtypes of text, image, audio, and video should not contain embedded
   information that is really of a different type.  Such compound
   formats should be represented using the "multipart" or "application"
   types.

Maybe "sub-class-of" will better fit here than "alias". But it seems, that
Nautilus does not understand any of them.

Marking #1272 as a duplicate for that bug, it points to this url
http://community.roxen.com/developers/idocs/rfc/rfc3839.html for more information.

*** Bug 1272 has been marked as a duplicate of this bug. ***

Is it possible to recognize audio/3gpp and video/3gpp files by looking at the
content of the ftyp atom?

Should be:
$ hexdump -C /home/data/Documents/Samples/3gpp-mpeg4.mov | head -1
00000000  00 00 00 14 66 74 79 70  33 67 70 34 00 00 02 00  |....ftyp3gp4....|

There's no easy way to differentiate audio and video though.

Yeah, ideally we'd use application/3gpp, but it probably isn't a registered mime
type. I'd go with video/3gpp since I'd expect a video player to be able to play
both video and audio files, while an audio player may not be able to handle
video files.

Agreed.

I already fixed that...

2005-07-25  Bastien Nocera  <hadess@hadess.net>

        * freedesktop.org.xml: add video/3gpp with associated magic
        (from: http://www.faqs.org/rfcs/rfc3839.html)