[FFmpeg-devel] [PATCH] ffv1: more than 8 bit per RGB channel
michaelni at gmx.at
Thu Aug 23 02:58:42 CEST 2012
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
> 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
> >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
> 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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel