[MPlayer-dev-eng] [PATCH] [TEST FUNC] Multi-channel reorder function

Ulion ulion2002 at gmail.com
Mon Dec 10 18:00:24 CET 2007


2007/12/9, Ulion <ulion2002 at gmail.com>:
> 2007/12/6, Ulion <ulion2002 at gmail.com>:
> > 2007/12/2, Ulion <ulion2002 at gmail.com>:
> > > 2007/12/2, Ulion <ulion2002 at gmail.com>:
> > > > 2007/11/30, Ulion <ulion2002 at gmail.com>:
> > > > > 2007/11/30, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > > > > Hello,
> > > > > > On Thu, Nov 29, 2007 at 06:38:15PM +0800, Ulion wrote:
> > > > > > [...]
> > > > > > > 3. I'm not familar with inline function and not sure whether inline
> > > > > > > function can be optimized same with macro version, so is current macro
> > > > > > > version acceptable for commit?
> > > > > >
> > > > > > Yes, it can. If necessary gcc can be forced to behave by using the
> > > > > > always_inline attribute. But since speed is not really that relevant
> > > > > > here a normal static inline function would be much preferable over
> > > > > > macro-mess.
> > > > >
> > > > > macro removed, lefted macroes are only for save lines of same code but
> > > > > different type (uint8_t, uint16_t...).
> > > > > If no objects, commit in 5 days.
> > > >
> > > > If there are no objections, I will commit this patch in 3 days.
> > >
> > > After some review, I decide to supply functions use audio
> > > source/target (alsa, aac, lavc ac3, waveex) type with a channel number
> > > as parameter to simply caller's code. Here's the updated patch, it
> > > looks cleaner than earlier patch. If there are no objections, I'd
> > > prefer to commit this patch after 5 days.
> >
> > Updates: support channel reorder for ad_ffmpeg (ac3, liba52, dca,
> > libfaad), and remove a channel reorder example for ffdca, also, fix
> > two reorder wrong channel places.
> > Since the patch updated again, I'd like to wait 3 days to commit.
>
> I will commit it after midnight (GMT), any objects?

Finally commited.

-- 
Ulion



More information about the MPlayer-dev-eng mailing list