On Fri, Jul 08, 2011 at 12:00:34PM +0100, Joseph Artsimovich wrote: > On 08/07/2011 11:49, Måns Rullgård wrote: > >Joseph Artsimovich<[email protected]> writes: > > > >>On 08/07/2011 11:38, Måns Rullgård wrote: > >>>Joseph Artsimovich<[email protected]> writes: > >>> > >>>>Hello, > >>>> > >>>>Some time ago my company added support for 10-bit DNxHD encoding and > >>>>decoding to ffmpeg / libav. I've been trying to get this code > >>>>accepted into ffmpeg.org branch first, but this process is taking > >>>>ages. I wonder if it will get accepted here more easily. > >>>> > >>>>The patch implements both encoding and decoding for 10-bit DNxHD. > >>>>It's currently quite slow due to the lack of assembly optimizations > >>>>for 10-bit-safe DCT and IDCT code. We may be adding assembly > >>>>optimizations when we actually start working with 10-bit DNxHD files. > >>>>The color model used in 10-bit mode is YUV422P16 with 10-bit samples > >>>>scaled to 16-bit. > >>>Why do you scale the value up to 16 bits? Keeping them 10-bit in a > >>>16-bit container is likely to make many assembler optimisations much > >>>easier since intermediate values will still fit in 16 bits for some > >>>operations. > >>10-bit samples in a 16-bit container? Is such a thing supported by > >>libswscale? > >Should be. See the various PIX_FMT_*10 pixel formats > I didn't realize those formats are using 16 bit containers. The > comment for PIX_FMT_YUV422P10BE says "planar YUV 4:2:2, 20bpp", > which sounds like bit-packing to me.
It is, just not very tight packing with some unused space left in every second byte :) > I am willing to go with 10-bit in a 16-bit container, though it > means extra work for us, as we'll have to add that kind of a > colormodel to libquicktime and to our custom colormodel converter. It would pay off since there are other 10-bit codecs out there (H.264, for example). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
