[FFmpeg-devel] [PATCH] ffv1: more than 8 bit per RGB channel

[Michael Niedermayer]

On Thu, Aug 23, 2012 at 02:20:27AM +0200, Georg Lippitsch wrote:
> Am 22.08.2012, 23:52 Uhr, schrieb Michael Niedermayer <michaelni at gmx.at>:
> 
> >On Wed, Aug 22, 2012 at 08:04:04PM +0200, Georg Lippitsch wrote:
> >>Add support for GBRP9, GBRP10, GBRP12 and GBRP14 pix formats in ffv1.
> >>---
> >> libavcodec/ffv1.c |   85
> >>++++++++++++++++++++++++++++++++++++++++++----------
> >> 1 files changed, 68 insertions(+), 17 deletions(-)
> >
> >this breaks encoding and decoding of -pix_fmt bgr0
> 
> Ah indeed, sorry. Patch with trivial fix will follow.
> 
> But besides that, I came across another thing I do not completely
> understand: Does bgr0 mean that the last byte is guaranteed to be
> zero, or that it is simply not taken into account by the
> encoder/decoder?
> I ask because I'm not able to get equal framemd5 when comparing with
> bgr0. But it does work with bgr24.

decoders should set the 4th byte to something consistent
that is 0 or 0xFF. encoders should not depend on the value of the 4th
byte


> 
> 
> >also what effect does this has on en/decoding speed of 8/8/8 rgb ?
> >(that is once it works again)
> 
> I have not measured, but it will be slower because of the
> if(s->avctx->bits_per_raw_sample<=8)
> Micheal, do you think it's worth doing measurements, or shall I just
> duplicate the function to avoid the if(), and thus any possible
> speed loss?

i think its worth doing measurements, i certainly would prefer if
duplicating the function could be avoided
a local variable may also be faster than a context field

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20120823/816908bb/attachment.asc>