Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#4882 closed enhancement (fixed)

support rgb48le in ffv1

Reported by: dericed Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: ffv1
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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%

Change History (11)

comment:1 in reply to: ↑ description Changed 3 years ago by cehoyos

Replying to dericed:

As ffv1 is used for some rgb content from film scans

Do you have an example for a rgb48 film scan?

comment:2 Changed 3 years ago by 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 :) )

comment:3 follow-ups: Changed 3 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 3 years ago by 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.

comment:5 follow-up: Changed 3 years ago by cehoyos

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

comment:6 in reply to: ↑ 5 Changed 3 years ago by 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

comment:7 in reply to: ↑ 3 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by compn

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

comment:10 Changed 2 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to closed

Implemented by Michael in ce2217b25eccda9f5c14022bd69792e71b417b73

comment:11 Changed 2 years ago by cehoyos

This should be easier to use since 62f5e601aa4d42cf17f5f4331a2b7e2b533d4e69

Note: See TracTickets for help on using tickets.