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

Mon Mar 19 17:39:22 CET 2007

Hi

On Mon, Mar 19, 2007 at 04:48:07PM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > 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
> 
> That is false, muxer only writes "esds" in presence of aac or mpeg4, it
> does not for h264 and specs does not specify to write it. Here you
> should see the ambiguity.
> You can put whatever you want with any tag atm, assuming tag is "stsd"
> tag, and isom identify that tag as reference:
> 
> The `protocol' and `codingname' fields are registered identifiers that
> uniquely identify the streaming protocol or
> compression format decoder to be used. A given protocol or codingname
> may have optional or required
> extensions to the sample description (e.g. codec initialization
> parameters). All such extensions shall be within
> boxes; these boxes occur after the required fields. Unrecognized boxes
> shall be ignored.
> 
> class VisualSampleEntry(codingname) extends SampleEntry (codingname){
> 
> ISO 14496-1 (mp4) overrides ISO media though, but our brand is "isom"
> and not "mp41" nor "mp42", and we cannot use those brands because we
> miss "iods", and "odsm" tracks, 

> mp4 sucks anyway.

fully agree

> 
> A compromise would be to have a sub_tag.

yes, but that will make any generic handling of codec_tag harder
every AVInputFormat and AVOutputFormat has several lists of
supported codec_id-codec_tag pairs (const struct AVCodecTag **codec_tag)

with these it should be possible to check if the codec_tag of the
source container is supported by the destination container or to choose
a supported one if one exists for the codec_id

now if we split codec_tag these lists have to be extended to codec_tag,
sub_id, codec_id triplets, still for matroska, mxf/gxf? it still wouldnt
work completely

so IMHO if we do add a extended codec_tag it should be a generic arbitrary
length binary thing similar to extradata

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- 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/fed9ab5a/attachment.pgp>