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 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.
--
Joseph Artsimovich
Software Developer
MirriAd Ltd
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
