on (un-)supported data formats (WAS: Re: [MPlayer-users] Quicktime help)

Paul Stoeber paul.stoeber at stud.tu-ilmenau.de
Mon Sep 2 15:21:02 CEST 2002


On Mon, Sep 02, 2002 at 03:15:24PM +0200, Arpi wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi,
> 
> > > > machine archs should be stated explicitly in error messages and in
> > > > codecs.conf (not only in the comments, which isn't even done in the
> > > > "AUDIO CODECS" part).
> > > 
> > > ???
> > > if it prints "enable it at compile time!" it means the codec is supported,
> > > but the support was not enabled/detected by ./conigure (requires external
> > > dlls, libs etc to be installed).
> > 
> > By "codec is supported", you mean(?) that you have written all the glue C
> > code you could to make it available in mplayer (good work!  I appreciate
> 
> "codec is supported" it is supported on my computer, using linux on x86.
> it may not be working on extreme configurations like linux-ppc, dec-alpha
> irix etc etc, but they will work at leats on linux and freebsd on x86.
> 
> if "codec is supported", then there is either native implementation of teh
> codec in mplayer source tree, available as native lib (libavcodce, libvorbis
> libmad etc), uses win32 DLLs, uses realplayer plugins, uses xanim plugins
> etc. some of them may not be available for your platform, it's actually your
> problem... but on the primary platform of mplayer (linux/x86) it's supported.
> 
> > sees "enable it at compile time!", she'll think that's possible and try
> > hard to do it.  But since it wasn't possible in the first place (she
> 
> yes, so then go and suggest a better message to be printed.
> i was lazy writting that and it's still better than nothing.
> 
> but don't as me to add big bloat of code to guess if the given codec is
> available for the user's platform... it's nonsense.
> he should read teh docs and read if its available or not.
> 
> > So you are tempted to remove the hint message, because it disturbs me?
> > Wrong move, IMHO. 
> agree. patches welcomed. i'm busy with much more important things than a
> fuckin message which disturbs you...
> 
> i don't think that there are so many ppc users here
> especially as no real altivec etc support in mplayer so it'll be slow as
> hell on ppc
> 
> mplayer's primary target is still linux/x86
> if ppl port it to ppc, it's their problem.
> we cannot support ppc etc as we don't own such hw and we have no interest

Thanks for pointing this out.  Sorry that I have wasted your time
on this mailing list.  Perhaps this message of yours belongs in the FAQ.




More information about the MPlayer-users mailing list