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

[Michael Niedermayer]

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


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

well, maybe CODEC_ID_PCM_* should be merged into one, but thats a seperate
issue


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

stsd for mov
object type id for the 500 mp4 variants


> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070319/eac365f4/attachment.pgp>