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 340375 - Typefinding: differentiate between mp4 audio/video and quicktime etc.
Typefinding: differentiate between mp4 audio/video and quicktime etc.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: git master
Assigned To: Stefan Sauer (gstreamer, gtkdoc dev)
GStreamer Maintainers
: 156937 503589 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-02 06:35 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2018-11-03 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adds typefind changes (4.59 KB, patch)
2006-05-02 06:36 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
reviewed Details | Review
typefind tweaks to differentiate between audio/x-m4a and video/x-mp4 (2.15 KB, patch)
2007-08-31 08:19 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
its video/mp4 and not video/x-mp4 (2.14 KB, patch)
2007-08-31 08:35 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
Fix ISO/IEC 14496-12 typefinding. (4.08 KB, patch)
2007-09-17 12:02 UTC, Felipe Contreras (banned)
none Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-02 06:35:37 UTC
currently mp4 clips are detected incorrectly as "audio/x-m4a" in typefind. So, we would like to introduce new "video/mp4" mimetype for this purpose. The main point is that we need to distinguish the difference between clips with and without video content (since we have separate players for audio and video).
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-02 06:36:28 UTC
Created attachment 64652 [details] [review]
adds typefind changes
Comment 2 Tim-Philipp Müller 2006-05-02 08:15:30 UTC
The patch contains c++-style comments, those should probably be changed to C-style comments.

Just out of curiosity - how are you going to handle ASF/WMV or matroska files for example? Implement mini-demuxers in typefindfunctions as well?

What about audio content that has a video component that isn't really a video (like a still image representing cover art)?

Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-02 10:03:14 UTC
I'll cleanup the comments, but honestly no idea about ASF/WMV/matroska demuxing. Any examples I should look at?
Comment 4 Tim-Philipp Müller 2006-05-02 10:19:20 UTC
Not really, I was just curious how you were going to solve those (if at all).

Basically I think doing this stuff in typefinding is the wrong approach to solve the problem you're trying to solve (=differentiate between audio/video media), at least to solve it in general. If you're only ever interested about this particular media type, your approach might be useful of course.

IMHO typefinders should be robust and if we turn them into mini-demuxers we're making them brittle and error-prone.

Anyway, leaving this to people who know actually more about the media types in question here :)
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-07 17:08:43 UTC
2006-05-07  Stefan Kost  <ensonic@users.sf.net>

	* gst/typefind/gsttypefindfunctions.c: (mp4_find_box),
	(mp4_type_find), (plugin_init):
          Add typefind to distinguish between "audio/x-m4a" and new type
          "video/mp4". Fixes #340375
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-09 06:42:25 UTC
These elements may need fixing:

$ find . -name "*.c" -exec grep -l "/x-m4a" {} \;
./gst-ffmpeg-0.10.1/ext/ffmpeg/gstffmpegcodecmap.c
./gst-plugins-bad-0.10.3/gst/qtdemux/qtdemux.c
$ find . -name "*.c" -exec grep -l "/x-m4v" {} \;
$ find . -name "*.c" -exec grep -l "/mp4" {} \;
./gst-ffmpeg-0.10.1/gst-libs/ext/ffmpeg/libavformat/mov.c
./gst-ffmpeg-0.10.1/gst-libs/ext/ffmpeg/libavformat/movenc.c
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2006-05-12 14:22:19 UTC
this should be reconsidered for 0.11. Having "audio/x-m4a" for video too is just bad.
Comment 8 Tim-Philipp Müller 2006-10-02 10:08:16 UTC
*** Bug 156937 has been marked as a duplicate of this bug. ***
Comment 9 Tim-Philipp Müller 2006-10-02 10:14:00 UTC
So the basic question is (see bug #156937) whether we want a general mime type for all of these similar formats (if so we should probably change the media type to application/x-iso or application/x-quicktime or so) or not. The answer to this probably depends also on whether there is a real need to plug different demuxers depending on the exact type.

Doing all this differentiation just to be able to easily distinguish between audio and video files isn't worth the hassle and lack of robustness IMHO (but can always be overridden by custom typefinders that do that of course in case anyone feels really strongly that this is required).
Comment 10 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-31 08:18:09 UTC
Many media player need to differenciate where a file is video (video+audio) or only audio. For audio the will e.g. show visualizations.

The xiph foundation suggests something like this of ogg
http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
Although it differently handled in the shared-mime database
> grep ogg /usr/share/mime/packages/freedesktop.org.xml

Okay to apply the attached patch, that in my case helps with the mp4/m4a issue?
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-31 08:19:10 UTC
Created attachment 94693 [details] [review]
typefind tweaks to differentiate between audio/x-m4a and video/x-mp4
Comment 12 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-31 08:35:41 UTC
Created attachment 94694 [details] [review]
its video/mp4 and not video/x-mp4
Comment 13 Tim-Philipp Müller 2007-08-31 10:18:42 UTC
> Okay to apply the attached patch, that in my case helps with the mp4/m4a issue?
> 

I feel this breaks API/ABI, the issue is still really very much the same as it was in [1] IMHO.

Nothing keeps you from registering your own typefinders that do though as part of whatever plugin you use for demuxing the different types.

[1] http://thread.gmane.org/gmane.comp.video.gstreamer.cvs/22709/focus=15335
Comment 14 Benjamin Otte (Company) 2007-08-31 12:51:27 UTC
1) As far as I know caps were never meant to be proper mime types. (application/x-id3 anyone?) 

2) Caps are intended to differentiate the capabilities required by _pads_. So caps should not tell if something contains audio or video (What about AVIs with just audio?) or other features that are determined by a pipeline. If you need to know stuff that requires a pipeline, use a pipeline.
Comment 15 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-02 15:58:50 UTC
Main issue for me is that "audio/x-m4a" is plain wrong. We need typefinders for both:
application/x-iso-mp4
application/x-quicktime

Even though they are common, neither one is a subset of the other.

Now after having said that, For media player it is quite convinient to know quickly wheter a file has only audio or both audio&video. The reason is that they would like to treat it differently (different UI elements).
Comment 16 Benjamin Otte (Company) 2007-09-02 17:37:40 UTC
Contrary to popular opinion using a playbin with two fakesinks and seeing if it finds an audio and a video stream is really fast. And it is definitely so fast that it's not worth writing lots of code and adding hacks to typefinding to figure out if something has audio or video.
Comment 17 Felipe Contreras (banned) 2007-09-17 12:02:18 UTC
I'm attaching a patch that properly detects all the audio/video types from http://www.ftyps.com/

It seems instead of audio/x-m4a we should have audio/mp4, even better would be application/x-iso-mp4 since that's what the demuxer will receive.
Comment 18 Felipe Contreras (banned) 2007-09-17 12:02:59 UTC
Created attachment 95723 [details] [review]
Fix ISO/IEC 14496-12 typefinding.
Comment 19 Tim-Philipp Müller 2007-12-17 18:03:43 UTC
*** Bug 503589 has been marked as a duplicate of this bug. ***
Comment 20 GStreamer system administrator 2018-11-03 11:12:37 UTC
-- 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-base/issues/3.