support rgb48le in ffv1

[dave rice]

Summary of the bug:

As ffv1 is used for some rgb content from film scans and other high resolution images I propose adding support for rgb48le. Current yuv444p16le is selected.

How to reproduce:

ffmpeg -f lavfi -i testsrc -pix_fmt rgb48le -vframes 1 -c:v ffv1 -level 3 rgb_test.mkv
ffmpeg version 2.8 Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.8 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc --enable-libxvid --enable-libfreetype --enable-libfaac --enable-libass --enable-ffplay --enable-libopenjpeg --disable-decoder=jpeg2000 --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.2_1/include/openjpeg-1.5 ' --enable-nonfree --enable-vda
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Incompatible pixel format 'rgb48le' for codec 'ffv1', auto-selecting format 'yuv444p16le'
[ffv1 @ 0x7fa082000600] bits_per_raw_sample > 8, forcing coder 1
Output #0, matroska, to 'rgb_test.mkv':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv444p16le, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.60.100 ffv1
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=-0.0 Lsize=       7kB time=00:00:00.04 bitrate=1386.4kbits/s    
video:6kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 15.919732%

[Carl Eugen Hoyos]

Replying to dericed:

As ffv1 is used for some rgb content from film scans

Do you have an example for a rgb48 film scan?

[art1]

You could find DNG files (for next 7days) found on ​https://upload.slub-dresden.de/owncloud/public.php?service=files&t=5b243e556292d42a07480fcf0d5ac652

The files were produced to test FFV1 codec and are raw 4k. To produce 16-bit-RGB, try ff. instructions:

$> ufraw-batch --noexif --out-depth=16 --output-type=tiff $i --output=tiff4k/$(basename $i ".dng").tiff;

This should produce 16-bit TIFFs

Then test it with ffmpeg:

$> ffmpeg -threads 2 -f image2 -i tiff4k/AWEBA000245_%07d.tif -c:v ffv1 -level 3 -g 1 -coder 1 -context 1 -slices 16 -slicecrc 1 -y outputvideo_ffmpeg_threads.mkv

Hope, it helps…

(PS.: It would be wonderful if anyone could code direct DNG support :) )

[Carl Eugen Hoyos]

Are these DNG files 16 bit per component?
I believe what you request (which is of course valid) is not easy to implement but actual 16 bit per component samples are possibly rare.

[art1]

Replying to cehoyos:

Are these DNG files 16 bit per component?
I believe what you request (which is of course valid) is not easy to implement but actual 16 bit per component samples are possibly rare.

The DNGs are 12bit, CFA pattern 0, 1, 1, 2 which means AFAIK CYYM ​https://en.wikipedia.org/wiki/CYYM_filter.

The ufraw command (described in previous comment) converts this to RGB16.

[Carl Eugen Hoyos]

12 bit per component are supposed to work fine with current FFmpeg.

[art1]

Replying to cehoyos:

12 bit per component are supposed to work fine with current FFmpeg.

The TIFFs are 16bit RGB, not 12, because CFA converted to RGB

[art1]

Replying to cehoyos:

Are these DNG files 16 bit per component?
I believe what you request (which is of course valid) is not easy to implement but actual 16 bit per component samples are possibly rare.

If you using film scanners (for movie digitization) you could get 16bit TIFFs, example: ​http://www.dft-film.com/downloads/datasheets/DFT-SCANITY-Datasheet.pdf

Because FFV1 is prefered for digital preservation, it would be fine to support 16bit RGB, too.

[Peter B.]

@art1:
Would definitely be fine. If professionals are interested in this feature, what about contacting some of them to pool financial resources to have this feature implemented?

For example, this was already done in the past for 14bpc RGB support in FFV1.

[compn]

​http://trac.ffmpeg.org/ticket/4364 is the ticket for dng support

[Carl Eugen Hoyos]

Implemented by Michael in ce2217b25eccda9f5c14022bd69792e71b417b73

[Carl Eugen Hoyos]

This should be easier to use since 62f5e601aa4d42cf17f5f4331a2b7e2b533d4e69