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

Mon Mar 19 16:26:01 CET 2007

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

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

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

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/a9b4dad3/attachment.pgp>