[FFmpeg-devel] [libav-devel] [ffmpeg-devel] [PATCH 1/2] lavfi: make AVFilteFormats use int64_t lists to support channel layouts.

Michael Niedermayer michaelni at gmx.at
Sun Jun 12 20:30:34 CEST 2011


On Sun, Jun 12, 2011 at 08:00:25PM +0200, Stefano Sabatini wrote:
> On date Sunday 2011-06-12 14:42:17 +0300, Mina Nagy Zaki encoded:
> > On Thursday 09 June 2011 17:36:16 Stefano Sabatini wrote:
> > > On date Thursday 2011-06-09 13:25:25 +0300, Mina Nagy Zaki encoded:
> > > > The list type was changed to int64_t to be able to hold
> > > > channel layouts.
> > > > 
> > > > Usage of avfilter_make_format_list for PixelFromats/[AV]SampleFormats
> > > > had to be changed to use int64_t[] instead of enums, as they are 32bit.
> > > 
> > > I discussed this with Mina and this looked like the best solution for
> > > avoiding separate int/int64_t functions. If you have reasons to think
> > > there are better solutions, please comment.
> > > 
> > [...]
> > 
> > Ok, I just realized there's a *third* option. Keep all the 32 bit ints and 
> > drop support for any channel layouts that have more than 32 channels. I was 
> > told that it was originally int64 to support formats that can do more than 32 
> > channels. Right now though, the only value defined that's outside the int32 
> > range is the value for AV_CH_LAYOUT_NATIVE which is unapplicable to channel 
> > layout negotiation anyway.
> > 
> > This way, no breaking ABI/API, no losing type-safety. It's just that filters 
> > will not support more than 32 channels. FFmpeg itself doesn't support it, and 
> > int64 is only there for *possibly* supporting it. So I don't see what's wrong. 
> > If we ever support it in FFmpeg, we can make the int64 change in lavfi then. 
> 
> So resuming:
> 
> 1) make AVFilterFormats contain int64_t, and implement two separate:
> 
> AVFilterFormats *avfilter_make_format_list  (const int     *fmts)
> AVFilterFormats *avfilter_make_format64_list(const int64_t *fmts)
> 
> Type-safe, but requires some code duplication (source code duplication
> would be avoided by using a macro DEFINE_AVFILTER_MAKE_FORMAT_LIST(type)).
> 
> 2) always use avfilter_make_format_list(const int64_t *fmts)
> 
> in this case we don't need two distinct avfilter_make_format*_list
> functions, but we lose type-safety/debuggability and we need to update
> current filters enum PixelFormat pix_fmts lists.
> 
> 3) always use avfilter_make_format_list(const int *fmts)
> 
> but we can't support non-int and AV_CH_LAYOUT_NATIVE channel layouts
> if we want to add support to them.
> 
> ...
>

4)
static AVFilterFormats *make_format_list  (const void *fmts, int format_elem_size)
AVFilterFormats *avfilter_make_pixfmt_list  (const enum PixelFormat *fmts){
    return make_format_list(fmts, sizeof(...
}
...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110612/91fcd69f/attachment.asc>


More information about the ffmpeg-devel mailing list