[MPlayer-dev-eng] [PATCH] [TEST FUNC] Multi-channel reorder function
ulion2002 at gmail.com
Wed Dec 5 17:38:15 CET 2007
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.
More information about the MPlayer-dev-eng