[FFmpeg-devel] dcp encoding + new pixel format request/sponsorship

[Michaël Cinquin]

On 23 janv. 2013, at 05:49, Dave Rice wrote:
> On Jan 22, 2013, at 10:54 AM, Michaël Cinquin <mc at michaelcinquin.com> wrote:
>> On the output, you get jpeg-2000 .j2c files DCI-compliant, XYZ encoded, with a 2.6 gamma, 12 bpc, ready to pack into an mxf by asdcp-test.
> 
> To point out another barrier to FFmpeg as one-stop DCP, FFmpeg does not currently support muxing jpeg2000 into mxf. This would require an implementation of SMPTE 422m. There is a ticket for this request here: https://ffmpeg.org/trac/ffmpeg/ticket/1542.

So much the better if dci mxf packaging comes to FFmpeg ! 

In the meanwhile skipping a 16-bit TIFF intermediate will bring quite a saving in terms of disk i/o and space
1 hour film 1998x1080 in 16 bpc TIFF +- 1TB
1 hour film 1998x1080 j2c DCI +- 100 GB
1 hour film mxf : packs j2c +- 100 GB

present opensource workflow : 1 TB (tiff) + 100 GB (j2c) + 100 GB (mxf)

new opensource workflow when FFMpeg is ready : 100 GB (tiff) + 100 GB (mxf)


On 23 janv. 2013, at 05:38, Michael Bradshaw wrote:
> It's a bit more involved than that, particularly because those GBR pix fmts
> are planar, whereas all the RGB ones are packed.
> 
> I was about to start working on your request to be able to have 12 bit (or
> any other >8 and < 16) by using shifts, like Reimar suggested. However, I
> just noticed OpenJPEG 2.0 has been released and I spend some time trying to
> get the encoder & decoder updated to use OpenJPEG 2.0 (while maintaining
> backwards compatibility with older versions).
> 
> I'm just about to post a patch for 9-15 bit RGB output for the encoder. I
> haven't looked at the decoder yet; it should be fairly simple but not as
> dead simple as it was for the encoder.

Amazing ! Can't wait to test it