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

[Michael Niedermayer]

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


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

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

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/20070318/4f1003ad/attachment.pgp>