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

[Baptiste Coudurier]

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 ?

>> Anyway using "stsd" tag as codec_tag is not wrong, even for mp4 (mp4v
>> and avc1 for example). lavf is not broken, mplayer must remap
>> CODEC_ID_VORBIS correctly.
> 
> this is not about what mplayer must do, it is what codec_tag is also
> not every codec tag has a codec_id, just the ones for which we have
> a codec do
> 
> codec_tag is a container specific integer identifying the codec if you
> cannot map from codec_tag to codec_id then you violate that already

Strictly speaking that's not always true raw audio almost also depends
on bps.

> it seems you belive codec_tag to be something else though its not clear
> to me what else it should be, if it doesnt identify the codec then what
> else should it do, please try to define what codec_tag is in your oppinion
> and i think you will see that you either end up with a useless value or
> one which must contain a value from which the codec can be identified

Point is that codec_tag refering to mov/mp4/3gp becomes ambiguous in
that precise case. "stsd" fourcc or object type id ? And what about
CODEC_ID_MP3ON4 using same object type id as aac ?

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