[FFmpeg-devel] [PATCH] Define endian variant for PIX_FMT_RGB/BGR_5X5

[Stefano Sabatini]

On date Wednesday 2009-03-18 23:48:50 +0100, Michael Niedermayer encoded:
> On Wed, Mar 18, 2009 at 11:44:58PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2009-03-18 22:30:26 +0100, Michael Niedermayer encoded:
> > > On Tue, Mar 17, 2009 at 09:14:32PM +0100, Stefano Sabatini wrote:
> > [...]
> > > > Index: ffmpeg/libavcodec/avcodec.h
> > > > ===================================================================
> > > > --- ffmpeg.orig/libavcodec/avcodec.h	2009-03-17 21:06:43.000000000 +0100
> > > > +++ ffmpeg/libavcodec/avcodec.h	2009-03-17 21:09:56.000000000 +0100
> > > > @@ -2702,6 +2702,19 @@
> > > >  const char *avcodec_get_pix_fmt_name(int pix_fmt);
> > > >  void avcodec_set_dimensions(AVCodecContext *s, int width, int height);
> > > >  enum PixelFormat avcodec_get_pix_fmt(const char* name);
> > > > +
> > > > +/**
> > > > + * Returns the pixel format corresponding to the name \p name.
> > > > + *
> > > > + * If \p search_ne_variant is zero works like avcodec_get_pix_fmt().
> > > > + * If \p search_ne_variant is non-zero and if there is no pixel format
> > > > + * with name \p name, then a pixel format with the name corresponding
> > > > + * to the native endian format of \p name is searched.  For example in
> > > > + * a little-endian system, first is looked "gray16", then "gray16le".
> > > > + *
> > > > + * Finally if both forms are not found, returns \c PIX_FMT_NONE.
> > > > + */
> > > > +enum PixelFormat avcodec_get_pix_fmt2(const char* name, int search_ne_variant);
> > > >  unsigned int avcodec_pix_fmt_to_codec_tag(enum PixelFormat p);
> > > >  
> > > >  #define FF_LOSS_RESOLUTION  0x0001 /**< loss due to resolution change */
> > > 
> > > i dont see why a API change would be needed if no be/le postfix is used then
> > > the machine endianness canbe filled in
> > 
> > Since we're changing the behaviour of avcodec_get_pix_fmt() then I think
> > it should be a new function, for example
> > avcodec_get_pix_fmt("gray16")
> > 
> > currently fails with PIX_FMT_NONE, extending it it would return
> > PIX_FMT_GRAY16XE
> > 
> > or we could break compatibility, although the likeliness that this
> > may create problems are very low.
> > 
> 
> the user asks for gray16 the user gets gray16 i see no problem

If the user asks for gray16 the user actually gets a failure, changing
avcodec_get_pix_fmt it will return PIX_FMT_GRAY16[LB]E.

As I said the problem is more theoretical than practical, but I'd feel
uncomfortable because this is changing the assumed behaviour of the
function, so it would technically be compatibility breakage (well this
argumentation is not so effective especially considering the current
floating state of the API due to the lavu major bump).

But I also think the user should have the possibility to ask the library:
"get the pixel format exactly corresponding to this name, please don't
do fancy things", which wouldn't be possible with an extended version
of avcodec_get_pix_fmt().

Regards.
-- 
FFmpeg = Free and Frightening Mysterious Portable Ecumenical God