Movies from my 3GP phone are Quicktime files. Attached is the extra sniff and glob.
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)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.