[MPlayer-dev-eng] incoming/Vorbis_in_MP4_lavf_fail.mp4

Mon Mar 19 16:48:07 CET 2007

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Mon, Mar 19, 2007 at 01:40:07AM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Sun, Mar 18, 2007 at 11:21:22PM +0100, Baptiste Coudurier wrote:
>>>> Michael Niedermayer wrote:
>>>>> Hi
>>>>>
>>>>> On Sun, Mar 18, 2007 at 07:11:30PM +0100, Baptiste Coudurier wrote:
>>>>>> Michael Niedermayer wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> On Sat, Mar 17, 2007 at 06:04:04PM +0100, Baptiste Coudurier wrote:
>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On Sat, Mar 17, 2007 at 12:39:59AM +0100, Baptiste Coudurier wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 16, 2007 at 06:36:46PM +0100, Reimar Döffinger wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> On Fri, Mar 16, 2007 at 03:56:58PM +0100, Nico Sabbi wrote:
>>>>>>>>>>>>> Compn wrote:
>>>>>>>>>>>>>> ffplay and mplayer detects audio correctly
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> mplayer -demuxer lavf does not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> adding format 0x6134706D to audiocodec vorbis allows it to play
>>>>>>>>>>>>>> but its still trying faad first.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
>>>>>>>>>>>>>> FAAD: Failed to initialize the decoder!
>>>>>>>>>>>>>> ADecoder init failed :(
>>>>>>>>>>>>>> ADecoder init failed :(
>>>>>>>>>>>>>> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
>>>>>>>>>>>>>> AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
>>>>>>>>>>>>>> Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis decoder)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> try with svn blame who broke it, please.
>>>>>>>>>>>> I think this was never fixed. The problem IIRC is that lavf demuxer uses
>>>>>>>>>>>> a different mov atom to detect the format, but that one only contains
>>>>>>>>>>>> "mp4a".
>>>>>>>>>>> if codec_tag is mp4a then this is wrong, codec_tag should contain the thing
>>>>>>>>>>> which is looked up in ff_mov_obj_type
>>>>>>>>>>>
>>>>>>>>>>> grep ff_mov_obj_type in lavf/mov.c set codec_tag to it run regression tests
>>>>>>>>>>> check if this fixes the mplayer+lavf problem send patch
>>>>>>>>>>>
>>>>>>>>>> Humm well it makes sense for mp4, not sure for mov, dunno if other
>>>>>>>>>> codecs use "mp4a" as stsd tag in mov but stores something else and use
>>>>>>>>>> "esds" atom, and tag will be a simple int, but I've no real objection.
>>>>>>>>> hmm esds in mov? i thought esds is mp4 specific, ive checked the QT spec
>>>>>>>>> i have theres no match for "esds" ...
>>>>>>>> yes, aac and mpeg4 put "esds" in "stsd" as decoder specific info.
>>>>>>>>
>>>>>>>>> my idea was that mov would set codec_tag like it does currently and .mp4
>>>>>>>>> would set it based on esds (= whats in ff_mov_obj_type)
>>>>>>>> well that will be problematic with stream copy since it honor codec_tag
>>>>>>>> first atm, and I feel like having an int as codec_tag will surely
>>>>>>>> conflicts with wav tags or something. Reimar's solution is probably safest.
>>>>>>> setting codec tag to 0 is wrong
>>>>>>> setting it to what is in esds is the correct thing to do for .mp4
>>>>>>> also i dont see an immedeate problem with stream copy, for mp4->mp4
>>>>>>> its correct and for other containers the codec_tag must be remaped anyway
>>>>>>> "divx" wont work in .mov or .mp4 either
>>>>>> there is an immediate problem until muxer is changed. If you set
>>>>>> codec_tag to esds object type id in demuxer, it will put that in "stsd"
>>>>>> atom, for mov/mp4/3gp.
>>>>> mp4 clearly specifies what should be put in stsd IIRC if the muxer puts 
>>>>> something else there its buggy
>>>> It puts codec_tag if present.
>>>>
>>>> Also mp4 uses same codec table as 3gp and mov atm, tables should be
>>>> split then, I did not have time to do that yet, feel free to beat me at it.
>>>>
>>>> IIRC last time this was discussed, you argued about generic
>>>> container characteristic, now you seem to prone the inverse, which I was
>>>> arguing, did you change your mind ?
>>> i never suggested to set codec_tag to 0 for all codecs in a container or
>>> to set it to mp4v for all codecs in .mp4 also i see no relation to a single
>>> vs multiple tables which was what we disscussed
>>>
>>> also setting codec_tag correctly is critical to simplifying the codec_tag
>>> mapping between containers
>>> its also critical for stream copy, you cannot currently stream copy things
>>> for which there is no codec_id in mp4 also the object id is not preserved
>>> with stream copy if there are several choices MPEG2 Main profile will become
>>> MPEG2 Simple profile in the stream copy case ...
>> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-November/018571.html
>>
>> Are you stating now that we should not put a custom codec tag in a
>> container since it is critical ?
> 
> the current implementation makes it impossible to put ANY codec_tag
> into the mp4 container custom or taken from the source mp4 by stream copy
> neither works, and exporting the codec_tag doesnt work either as has been
> seen

That is false, muxer only writes "esds" in presence of aac or mpeg4, it
does not for h264 and specs does not specify to write it. Here you
should see the ambiguity.
You can put whatever you want with any tag atm, assuming tag is "stsd"
tag, and isom identify that tag as reference:

The `protocol' and `codingname' fields are registered identifiers that
uniquely identify the streaming protocol or
compression format decoder to be used. A given protocol or codingname
may have optional or required
extensions to the sample description (e.g. codec initialization
parameters). All such extensions shall be within
boxes; these boxes occur after the required fields. Unrecognized boxes
shall be ignored.

class VisualSampleEntry(codingname) extends SampleEntry (codingname){

ISO 14496-1 (mp4) overrides ISO media though, but our brand is "isom"
and not "mp41" nor "mp42", and we cannot use those brands because we
miss "iods", and "odsm" tracks, mp4 sucks anyway.

A compromise would be to have a sub_tag.

> also it should be clear that the source codec_tag should be preserved if
> its amongth the known standard codec_tags for the destination container, 
> if its not then one of the known standard codec_tags for the codec and
> container should be choosn. If there is no such then as last resort a
> custom tag which might match the source codec_tag again could be used
> 
> 
>>>> And what about
>>>> CODEC_ID_MP3ON4 using same object type id as aac ?
>>> MP3ON4 is a ugly hack
>>> designs should not be based on broken hacks but rather on correct 
>>> and clean things, the broken crap then can be dealt woth by whatever 
>>> workarounds are needed
>>>
>> An ugly hack defined by ISO, and standardized, deal with it.
>> According to your last statement in the thread I mentioned above, that
>> is some proof of validity.
> 
> MP3ON4 is valid according to spec sure, does this mean we should base our
> API design on it? i dont think so, we should suport it somehow thats enough

I totally agree here.

> also the relevant part here is that the current codec_tag code produces a
> collision for MP3ON4 as well as the code suggested by me, so i cant see
> how the MP3ON4 validity would affect the decission between the 2 codec_tag
> variants

Well your suggestion will immediatly break stream copy if you don't
change muxer first.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312