Created attachment 64652 [details] [review]
adds typefind changes

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)?

I'll cleanup the comments, but honestly no idea about ASF/WMV/matroska demuxing. Any examples I should look at?

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 :)

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

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

this should be reconsidered for 0.11. Having "audio/x-m4a" for video too is just bad.

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

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).

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?

Created attachment 94693 [details] [review]
typefind tweaks to differentiate between audio/x-m4a and video/x-mp4

Created attachment 94694 [details] [review]
its video/mp4 and not video/x-mp4

> 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

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.

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).

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.

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.

Created attachment 95723 [details] [review]
Fix ISO/IEC 14496-12 typefinding.

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

-- 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.