2011/7/8 Måns Rullgård <[email protected]> > Joseph Artsimovich <[email protected]> writes: > > > 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. > > I guess we should improve the documentation. > > > 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. > > Scaling to 16-bit after decoding if required by something external to > libav is probably faster than doing the decoding in full 16-bit once > optimisations are done. If it can be combined with some other > conversion, it should have no added cost at all.
>From an assembly perspective, 10-bit padded to 16-bit is much easier to work with than the full 16-bit range. See all the 10-bit x86 H.264 optimizations added.
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
