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

Stefano Sabatini stefano.sabatini-lala
Fri Mar 20 23:59:18 CET 2009


On date Thursday 2009-03-19 01:32:55 +0100, Michael Niedermayer encoded:
> On Thu, Mar 19, 2009 at 01:27:45AM +0100, Stefano Sabatini wrote:
> > 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
> 
> as i said tere is no problem
> gray16 means gray16 in native endian, one of le/be is native the returned
> is what the user asked for

My point was all about to allow the user to bypass a (moderately)
fancy function and give her the opportunity to do the simple
thing.

Anyway since I can't find for this specific case a realistic case of
use for which the new behaviour of avcodec_get_pix_fmt() could be
painful, I'll give up.

New patch simply extends the old behaviour, micro is bumped
accordingly.

If you prefer I'll split the patch as implementation+documentation.

Regards.
-- 
FFmpeg = Foolish Friendly Mournful Practical Encoding/decoding Genius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extend-get-pix-fmt.patch
Type: text/x-diff
Size: 2344 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090320/a40d5ce1/attachment.patch>



More information about the ffmpeg-devel mailing list