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

[Baptiste Coudurier]

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 ?

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

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