Re: [PATCH] Make Makefile recursion unconditional by default

On Mon, Jul 31, 2006 at 03:41:50AM +0300, Uoti Urpala wrote:
> Attached patch changes the top-level Makefile to invoke all subdirectory
> Makefiles by default to make rebuilding a changed tree more robust.
> Creating a file named "norecurse" disables recursion to directories
> where the .a file is newer than both other files in the same directory
> and the norecurse file (so creating it with a timestamp in the far past
> gives current behavior).

I'm fine with the patch.  Maybe the file should be called .norecurse to
make it less obtrusive, though.

Diego

Re: [PATCH] channel reordering for 6ch audio

Alexander 'Lazy Ranma' Ponyatikh wrote:
> Mplayer's support for 6 ch sound is crappy. The only thing that works
> correctly is AC3 audio (at least with -ao dsound). Every codec
> produces or requests channels in its own order, and mplayer almost
> never reorders them. As result channels are often mixed up.
> 
> I made some research on channel ordering of various codecs and
> drivers, and made some patches to make them correctly reorder channels
> to/from mplayer default order. I took L R SL SR C LFE sequence as
> mplayer default, since it's used by ad_liba52.c, af_hrtf.c,
> ao_dsound.c.
> 
> ao_dsound.c
> Native order:   L R C  LFE SL SR (windows default)
> Expected input: L R SL SR  C LFE (mplayer default)
> Driver correctly reorders channels
> 
> ao_pcm.c
> Native order: L R C LFE SL SR (windows default)
> Expected input: native
> Reordering required
> 
> ad_faad.c
> Native order: C L R  SL SR LFE
> Output order: native
> Reordering required
> 
> ad_liba52.c
> Native order: L R SL SR C LFE converted from planar LFE L C R SL SR
> (using MMX)

Re: [PATCH] vo_caca using the new caca API

Hi, no one has commented on my patch, is there something wrong with it?
I think it is important for mplayer to update this driver so it will
work in the future.

Sean D'Epagnier

On Wed, Jul 19, 2006 at 08:35:09PM -0600, Sean D'Epagnier wrote:
>  Hi, I have found that libcaca has changed their api recently. The vo_caca driver does not work with the
latest libcaca.
> 
> I have a patch that ports vo_caca to use the new api.  I am not sure what is prefered, to apply this patch, wait
and apply it in a few months as more distributions ship the new library, or distribute the patch so that it is
applied if the library is detected to be the newer version.
> 
> Thanks,
> Sean D'Epagnier

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] vo_caca using the new caca API

On Tuesday, 01 August 2006 at 12:04, Sean D'Epagnier wrote:
> Hi, no one has commented on my patch, is there something wrong with it?
> I think it is important for mplayer to update this driver so it will
> work in the future.

I don't like CACA_OLD, why not call it by version, like it was done with
ALSA? i.e. CACA09 or something like that.

And #ifndef CACA_OLD looks weird. Isn't there some API revision number
you can compare against?

Looks clean otherwise...

Regards,
R.

--

-- 
MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan

Re: [PATCH] Make Makefile recursion unconditional by default

On Tue, 2006-08-01 at 08:42 +0200, Diego Biurrun wrote:
> I'm fine with the patch.  Maybe the file should be called .norecurse to
> make it less obtrusive, though.

I'm not sure whether a control file like that should be a dotfile or
not. Anyway committed with the '.norecurse' name.

Re: Re: [PATCH] channel reordering for 6ch audio

Frank Aurich wrote:
> Alexander 'Lazy Ranma' Ponyatikh wrote:
>> Mplayer's support for 6 ch sound is crappy. The only thing that works
>> correctly is AC3 audio (at least with -ao dsound). Every codec
>> produces or requests channels in its own order, and mplayer almost
>> never reorders them. As result channels are often mixed up.
>>
>> I made some research on channel ordering of various codecs and
>> drivers, and made some patches to make them correctly reorder channels
>> to/from mplayer default order. I took L R SL SR C LFE sequence as
>> mplayer default, since it's used by ad_liba52.c, af_hrtf.c,
>> ao_dsound.c.
>>
>> ao_dsound.c
>> Native order:   L R C  LFE SL SR (windows default)
>> Expected input: L R SL SR  C LFE (mplayer default)
>> Driver correctly reorders channels
>>
>> ao_pcm.c
>> Native order: L R C LFE SL SR (windows default)
>> Expected input: native
>> Reordering required
>>
>> ad_faad.c
>> Native order: C L R  SL SR LFE
>> Output order: native
>> Reordering required
>>
>> ad_liba52.c
>> Native order: L R SL SR C LFE converted from planar LFE L C R SL SR

make clean and make distclean behavior

So our behavior on make clean and make distclean is somewhat
non-standard - *surprise* ...

distclean is recursive while clean is not and distclean does not remove
all generated files, config.h and config.mak get left behind.

I think there was a reason for this behavior back in the day, but, for
the life of me, I cannot remember it - if I ever knew.

So is there any reason nowadays to keep things as they are?  I think I
want to have a bit more standard semantics with recursive clean and a
distclean that returns pristine sources.

Diego

Re: make clean and make distclean behavior

2006/8/2, Diego Biurrun <diego <at> biurrun.de>:
> So our behavior on make clean and make distclean is somewhat
> non-standard - *surprise* ...
>
> distclean is recursive while clean is not and distclean does not remove
> all generated files, config.h and config.mak get left behind.
>
> I think there was a reason for this behavior back in the day, but, for
> the life of me, I cannot remember it - if I ever knew.
>
> So is there any reason nowadays to keep things as they are?  I think I
> want to have a bit more standard semantics with recursive clean and a
> distclean that returns pristine sources.

No objections.

Just test it more carefully.

Re: [PATCHES] iec958 and unichrome

  Hi Diego !

> version.h is included by mistake, there are some cosmetics in the patch,
> plus
> 
>   #if defined(HAVE_XVMC)|defined(HAVE_XVMC_VLD)
> 
> is incorrect syntax, use
> 
>   #if defined(HAVE_XVMC) || defined(HAVE_XVMC_VLD)
> 
> instead and yes, please also add the spaces, it makes it more readable.

  Ok, it's fixed. Try again at the same location. It applies and compiles. I
haven't tested the binary yet. 
http://remus.gotdns.com/the2nd//mplayer-1.0pre8-unichrome-0.5.patch

  Please note that I'm not the maintainer of the patch. I barely ported it to
1.0pre8. The code that was there in the pre6 patch ended up in the ported
version  ...

> Dunno about the rest of the patch, Ivan should review it.  I remember
> that Guillaume was interested in Via xvmc support as well.

  What about the iec958 patch ? Could this be included in the mainstream
mplayer ?

    remus

Re: [PATCHES] iec958 and unichrome

  Hi !

> Are you sure there weren't any patch for at least pre7?

  No, I'm not  ... The latest unichrome patch on the unichrome site was for
pre6. So I assumed that this is the latest available.

> Please check the archives to spare yourself un-necessary trouble.

  Well, I already ported it  ...

> http://remus.gotdns.com/the2nd/mplayer-1.0pre8-unichrome-0.5.patch
>
> I don't have any hardware that can take advantage of these patches,

  I have the hardware and I tested it. It works pretty well. Depending on the
case the use of the xvmc device gives you between 10%-30% less CPU utilization.
Let me know if you need more help with that.

> yet I figured that it would be good if these patches were merged because 
> they are valuable.

  Agree with that one. That's why I would like to have it included so it
doesn't have to be ported again for the next version. 

> The problem is that their design doesn't fit quite too nicely with 
> MPlayer's, so it makes it quite hard to merge them properly (a bit the 
> same kinda problem as DVDnav patches).