convert from bt601 to bt709

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

convert from bt601 to bt709

Gregory Ducatel
Hi Guys,
I am trying to convert a DPX image sequence into a DNXHD movie.
My issue is that I am not able to properly convert the data from bt601 into
an output of bt701 using the following command line (on Windows 7 x64).


*Command line:*

ffmpeg.exe -y -threads 8 -f image2 -r 24000/1001 -i "Source_file.%04d.dpx"
-sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info -c:v
dnxhd -pix_fmt yuv422p -b:v 115M -vf "[in]scale=1920:1080,
colormatrix=bt601:bt709[out]" -movflags +faststart -aspect 1.777778
"c:\test_dnxhd.mov"


*Output result:*

ffmpeg version N-63746-gfbaf73a Copyright (c) 2000-2014 the FFmpeg
developers
  built on Jun  3 2014 22:10:20 with gcc 4.8.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls
--enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca
--enable-libfreetyp
e --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug
--enable-
libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libope
njpeg --enable-libopus --enable-librtmp --enable-libschroedinger
--enable-libsox
r --enable-libspeex --enable-libtheora --enable-libtwolame
--enable-libvidstab -
-enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-
libxavs --enable-libxvid --enable-decklink --enable-zlib
  libavutil      52. 89.100 / 52. 89.100
  libavcodec     55. 66.100 / 55. 66.100
  libavformat    55. 42.100 / 55. 42.100
  libavdevice    55. 13.101 / 55. 13.101
  libavfilter     4.  5.100 /  4.  5.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, image2, from 'R:\test.%04d.dpx':
  Duration: 00:00:06.67, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: dpx, gbrp10le, 1920x1080 [SAR 1:1 DAR 16:9], 23.98
tbr,23.98 tbn, 23.98 tbc
[swscaler @ 0000000000383fc0] bicubic scaler, from gbrp10le to yuv422p10le
using MMXEXT
[swscaler @ 00000000003a7960] bicubic scaler, from yuv422p10le to yuv422p
using MMXEXT
[swscaler @ 00000000003a7960] using unscaled yuv422p10le -> yuv422p special
converter
Output #0, mov, to 'c:\test_dnxhd.mov':
  Metadata:
    encoder         : Lavf55.42.100
    Stream #0:0: Video: dnxhd (AVdn / 0x6E645641), yuv422p, 1920x1080 [SAR
1:1 D
AR 16:9], q=2-1024, 115000 kb/s, 23.98 fps, 19184 tbn, 23.98 tbc
    Metadata:
      encoder         : Lavc55.66.100 dnxhd
Stream mapping:
  Stream #0:0 -> #0:0 (dpx -> dnxhd)
Press [q] to stop, [?] for help
frame=    4 fps=0.0 q=1.0 size=    2368kB time=00:00:00.16
bitrate=116296.4kbits
frame=    7 fps=6.5 q=1.0 size=    4144kB time=00:00:00.29
bitrate=116295.9kbits
frame=   10 fps=6.1 q=1.0 size=    5920kB time=00:00:00.41
bitrate=116295.7kbits
frame=   13 fps=5.9 q=1.0 size=    7696kB time=00:00:00.54
bitrate=116295.6kbits
frame=   16 fps=5.8 q=1.0 size=    9472kB time=00:00:00.66
bitrate=116295.3kbits
frame=   19 fps=5.8 q=1.0 size=   11248kB time=00:00:00.79
bitrate=116295.3kbits
frame=   22 fps=5.7 q=1.0 size=   13024kB time=00:00:00.91
bitrate=116295.3kbits
frame=   25 fps=5.7 q=1.0 size=   14800kB time=00:00:01.04
bitrate=116295.3kbits
frame=   28 fps=5.7 q=1.0 size=   16576kB time=00:00:01.16
bitrate=116295.2kbits
frame=   31 fps=5.7 q=1.0 size=   18352kB time=00:00:01.29
bitrate=116295.2kbits
frame=   34 fps=5.6 q=1.0 size=   20128kB time=00:00:01.41
bitrate=116295.2kbits
frame=   37 fps=5.6 q=1.0 size=   21904kB time=00:00:01.54
bitrate=116295.2kbits
frame=   40 fps=5.6 q=1.0 size=   23680kB time=00:00:01.66
bitrate=116295.1kbits
frame=   43 fps=5.6 q=1.0 size=   25456kB time=00:00:01.79
bitrate=116295.1kbits
frame=   46 fps=5.6 q=1.0 size=   27232kB time=00:00:01.91
bitrate=116295.1kbits
frame=   49 fps=5.6 q=1.0 size=   29008kB time=00:00:02.04
bitrate=116295.1kbits
frame=   52 fps=5.6 q=1.0 size=   30784kB time=00:00:02.16
bitrate=116295.1kbits
frame=   55 fps=5.6 q=1.0 size=   32560kB time=00:00:02.29
bitrate=116295.1kbits
frame=   58 fps=5.6 q=1.0 size=   34336kB time=00:00:02.41
bitrate=116295.1kbits
frame=   61 fps=5.6 q=1.0 size=   36112kB time=00:00:02.54
bitrate=116295.1kbits
frame=   64 fps=5.6 q=1.0 size=   37888kB time=00:00:02.66
bitrate=116295.0kbits
frame=   67 fps=5.6 q=1.0 size=   39664kB time=00:00:02.79
bitrate=116295.0kbits
frame=   70 fps=5.6 q=1.0 size=   41440kB time=00:00:02.91
bitrate=116295.1kbits
frame=   73 fps=5.6 q=1.0 size=   43216kB time=00:00:03.04
bitrate=116295.0kbits
frame=   76 fps=5.5 q=1.0 size=   44992kB time=00:00:03.16
bitrate=116295.0kbits
frame=   79 fps=5.5 q=1.0 size=   46768kB time=00:00:03.29
bitrate=116295.0kbits
frame=   82 fps=5.5 q=1.0 size=   48544kB time=00:00:03.41
bitrate=116295.0kbits
frame=   85 fps=5.5 q=1.0 size=   50320kB time=00:00:03.54
bitrate=116295.0kbits
frame=   88 fps=5.5 q=1.0 size=   52096kB time=00:00:03.66
bitrate=116295.0kbits
frame=   91 fps=5.5 q=1.0 size=   53872kB time=00:00:03.79
bitrate=116295.0kbits
frame=   94 fps=5.5 q=1.0 size=   55648kB time=00:00:03.91
bitrate=116295.0kbits
frame=   97 fps=5.5 q=1.0 size=   57424kB time=00:00:04.04
bitrate=116295.0kbits
frame=  100 fps=5.5 q=1.0 size=   59200kB time=00:00:04.17
bitrate=116295.0kbits
frame=  103 fps=5.5 q=1.0 size=   60976kB time=00:00:04.29
bitrate=116295.0kbits
frame=  106 fps=5.5 q=1.0 size=   62752kB time=00:00:04.42
bitrate=116295.0kbits
frame=  109 fps=5.5 q=1.0 size=   64528kB time=00:00:04.54
bitrate=116295.0kbits
frame=  112 fps=5.5 q=1.0 size=   66304kB time=00:00:04.67
bitrate=116295.0kbits
frame=  115 fps=5.5 q=1.0 size=   68080kB time=00:00:04.79
bitrate=116295.0kbits
frame=  118 fps=5.5 q=1.0 size=   69856kB time=00:00:04.92
bitrate=116295.0kbits
frame=  121 fps=5.5 q=1.0 size=   71632kB time=00:00:05.04
bitrate=116295.0kbits
frame=  124 fps=5.5 q=1.0 size=   73408kB time=00:00:05.17
bitrate=116295.0kbits
frame=  127 fps=5.5 q=1.0 size=   75184kB time=00:00:05.29
bitrate=116295.0kbits
frame=  130 fps=5.5 q=1.0 size=   76960kB time=00:00:05.42
bitrate=116295.0kbits
frame=  133 fps=5.5 q=1.0 size=   78736kB time=00:00:05.54
bitrate=116295.0kbits
frame=  136 fps=5.5 q=1.0 size=   80512kB time=00:00:05.67
bitrate=116295.0kbits
frame=  139 fps=5.5 q=1.0 size=   82288kB time=00:00:05.79
bitrate=116295.0kbits
frame=  142 fps=5.5 q=1.0 size=   84064kB time=00:00:05.92
bitrate=116295.0kbits
frame=  145 fps=5.5 q=1.0 size=   85840kB time=00:00:06.04
bitrate=116295.0kbits
frame=  148 fps=5.5 q=1.0 size=   87616kB time=00:00:06.17
bitrate=116295.0kbits
frame=  151 fps=5.5 q=1.0 size=   89392kB time=00:00:06.29
bitrate=116295.0kbits
frame=  154 fps=5.5 q=1.0 size=   91168kB time=00:00:06.42
bitrate=116295.0kbits
frame=  157 fps=5.5 q=1.0 size=   92944kB time=00:00:06.54
bitrate=116295.0kbits
frame=  160 fps=5.5 q=1.0 size=   94720kB time=00:00:06.67
bitrate=116295.0kbits
[mov @ 00000000003836c0] Starting second pass: moving the moov atom to the
beginning of the file
frame=  160 fps=5.4 q=1.0 Lsize=   94721kB time=00:00:06.67
bitrate=116296.8kbits/s
video:94720kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.001571%



When I open the file inside QuickTime, it is like the color matrix was not
apply and the gamma is always set to 2.2... Any advice or help?
Thanks.

Greg
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
On 5 June 2014 05:03, Gregory Ducatel <[hidden email]> wrote:

> Hi Guys,
> I am trying to convert a DPX image sequence into a DNXHD movie.
> My issue is that I am not able to properly convert the data from bt601 into
> an output of bt701 using the following command line (on Windows 7 x64).
>
>
> *Command line:*
>
> ffmpeg.exe -y -threads 8 -f image2 -r 24000/1001 -i "Source_file.%04d.dpx"
> -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info -c:v
> dnxhd -pix_fmt yuv422p -b:v 115M -vf "[in]scale=1920:1080,
> colormatrix=bt601:bt709[out]" -movflags +faststart -aspect 1.777778
> "c:\test_dnxhd.mov"
>
>
> *Output result:*
>
> ffmpeg version N-63746-gfbaf73a Copyright (c) 2000-2014 the FFmpeg
> developers
>   built on Jun  3 2014 22:10:20 with gcc 4.8.2 (GCC)
>   configuration: --enable-gpl --enable-version3 --disable-w32threads
> --enable-av
> isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls
> --enab
> le-iconv --enable-libass --enable-libbluray --enable-libcaca
> --enable-libfreetyp
> e --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug
> --enable-
> libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb
> --enable-libope
> njpeg --enable-libopus --enable-librtmp --enable-libschroedinger
> --enable-libsox
> r --enable-libspeex --enable-libtheora --enable-libtwolame
> --enable-libvidstab -
> -enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
> --enable-libvpx
> --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
> --enable-
> libxavs --enable-libxvid --enable-decklink --enable-zlib
>   libavutil      52. 89.100 / 52. 89.100
>   libavcodec     55. 66.100 / 55. 66.100
>   libavformat    55. 42.100 / 55. 42.100
>   libavdevice    55. 13.101 / 55. 13.101
>   libavfilter     4.  5.100 /  4.  5.100
>   libswscale      2.  6.100 /  2.  6.100
>   libswresample   0. 19.100 /  0. 19.100
>   libpostproc    52.  3.100 / 52.  3.100
> Input #0, image2, from 'R:\test.%04d.dpx':
>   Duration: 00:00:06.67, start: 0.000000, bitrate: N/A
>     Stream #0:0: Video: dpx, gbrp10le, 1920x1080 [SAR 1:1 DAR 16:9], 23.98
> tbr,23.98 tbn, 23.98 tbc
> [swscaler @ 0000000000383fc0] bicubic scaler, from gbrp10le to yuv422p10le
> using MMXEXT
> [swscaler @ 00000000003a7960] bicubic scaler, from yuv422p10le to yuv422p
> using MMXEXT
> [swscaler @ 00000000003a7960] using unscaled yuv422p10le -> yuv422p special
> converter
> Output #0, mov, to 'c:\test_dnxhd.mov':
>   Metadata:
>     encoder         : Lavf55.42.100
>     Stream #0:0: Video: dnxhd (AVdn / 0x6E645641), yuv422p, 1920x1080 [SAR
> 1:1 D
> AR 16:9], q=2-1024, 115000 kb/s, 23.98 fps, 19184 tbn, 23.98 tbc
>     Metadata:
>       encoder         : Lavc55.66.100 dnxhd
> Stream mapping:
>   Stream #0:0 -> #0:0 (dpx -> dnxhd)
> Press [q] to stop, [?] for help
> frame=    4 fps=0.0 q=1.0 size=    2368kB time=00:00:00.16
> bitrate=116296.4kbits
>
> frame=  160 fps=5.4 q=1.0 Lsize=   94721kB time=00:00:06.67
> bitrate=116296.8kbits/s
> video:94720kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: 0.001571%
>
>
>
> When I open the file inside QuickTime, it is like the color matrix was not
> apply and the gamma is always set to 2.2... Any advice or help?
> Thanks.
>
> Greg
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>

My first advice would be to not use QuickTime for color accurate viewing.
However I've yet to find a good/trustable viewer for this kind of work.
VLC/DJV/Lightworks seem to work nice on my Linux workstation though. If
anybody has any good suggestions they'd me more than welcome.

On the DNxHD question I've yet to find a good way of actually getting a
good dependable color accurate DNxHD QT.
Maybe try not to use the sws_flags at all and only use filters_complex.
sws_flags have never really worked for me.
But to be honest I've not really looked at this problem in quite a while.
We've settled for a DPX -> Prores work flow internally for workable
previews.

--
C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Carl Eugen Hoyos
Rio Kierkels <riokierkels <at> gmail.com> writes:

> > bicubic scaler, from gbrp10le to yuv422p10le using MMXEXT
> > bicubic scaler, from yuv422p10le to yuv422p using MMXEXT
> > using unscaled yuv422p10le -> yuv422p special converter

I wonder if it would help to use an intermediate
pixel format like yuv444p

> Maybe try not to use the sws_flags at all and only use
> filters_complex. sws_flags have never really worked for me.

Did you report this?

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
>
> > Maybe try not to use the sws_flags at all and only use
> > filters_complex. sws_flags have never really worked for me.
>
> Did you report this?
>
> Carl Eugen
>

I should have of course but haven't been able to make a good test case yet.

An intermediate pixel format wouldn't be a bad idea at all.
I actually assumed that ffmpeg internally did all its calculations in the
best space possible like Nuke does it for example.

--
C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Gregory Ducatel
Hi guys,

I totally agree regarding Quick Time. Unfortunately one of our client wants
to review using Quick Time file and ask us to match the look With Quick
Time player.

Could it be that the color atom are not valid from ffmpeg? Can we set them
manually?

The same quick time file outputed with Nuke, provide a prefered transfer
set at 1.8

Ffmpeg on the other hand provide a prefered transfer always set at 2.2?

Is there a way to change that?

Thank you for your help!
On Jun 5, 2014 4:08 AM, "Rio Kierkels" <[hidden email]> wrote:

> >
> > > Maybe try not to use the sws_flags at all and only use
> > > filters_complex. sws_flags have never really worked for me.
> >
> > Did you report this?
> >
> > Carl Eugen
> >
>
> I should have of course but haven't been able to make a good test case yet.
>
> An intermediate pixel format wouldn't be a bad idea at all.
> I actually assumed that ffmpeg internally did all its calculations in the
> best space possible like Nuke does it for example.
>
> --
> C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
> Could it be that the color atom are not valid from ffmpeg? Can we set them
> manually?

Unfortunately ffmpeg doesn't write the 'colr/nclc' atom with primaries &
matrix information - which may or may not actually affect you in this
case because Avid has their own way of doing things in their Windows/Mac
Quicktime codecs..

Avid's DNxHD Quicktime codecs are a screwed-up mess themselves and will
give different results depending on how the file was encoded.  They have
an additional flag which gets stored (for reasons I don't understand)
defining if the original input was RGB or 709 levels (0-255 or 16-235
respectively in 8-bit) and will inexplicably change the way the codec
decodes depending on how it is set.  I think it's in an atom called
ACLR;  I doubt ffmpeg writes this either, and I'm not sure what the
codec's default behavior is if it's missing (though it sounds like it
could behave as if it's set to 709, which the Quicktime codec then
scales the data to 16-235 even though it already IS 16-235 in the file..)

I'll have to do some tests and refresh my memory of what all is wrong..

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
> I think it's in an atom called ACLR;  I doubt ffmpeg writes this either...

So in looking at the source, ffmpeg _does_ write this Avid extension if
the codec is DNxHD, and hard-codes it as 'RGB range' which sounds wrong
but the Avid codecs give the right result and it looks right in
Quicktime Player.  This was converting v210 (Uncompressed 4:2:2 10-bit)
to DNxHD.

With that said, I just did some tests from a 10-bit RGB DPX source to
DNxHD and I can't make it right either.  The range gets re-scaled to
16-235 (even though it already is) and the color primaries aren't
right... but the math for this is starting to go out of my territory,
and trying to figure out the path through the code is going even further.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Tim Nicholson-2
On 06/06/14 00:18, Bob Maple wrote:

>> I think it's in an atom called ACLR;  I doubt ffmpeg writes this either...
>
> So in looking at the source, ffmpeg _does_ write this Avid extension if
> the codec is DNxHD, and hard-codes it as 'RGB range' which sounds wrong
> but the Avid codecs give the right result and it looks right in
> Quicktime Player.  This was converting v210 (Uncompressed 4:2:2 10-bit)
> to DNxHD.
>
> With that said, I just did some tests from a 10-bit RGB DPX source to
> DNxHD and I can't make it right either.  The range gets re-scaled to
> 16-235 (even though it already is) and the color primaries aren't
> right... but the math for this is starting to go out of my territory,
> and trying to figure out the path through the code is going even further.

ISTR that if you give ffmpeg RGB it assumes its full range, it also by
default converts using 601 matrices. Although it has a number of
colourspaces defined which can be accessed in the libs using the API,
ffmpeg itself makes no use of them (Although I have a nagging feeling
that that may not be completely true anymore either).

There have been various threads on this subject over the years.


> [..]

--
Tim.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Carl Eugen Hoyos
In reply to this post by Bob Maple
Bob Maple <bobm-ffmpeg <at> burner.com> writes:

> I just did some tests from a 10-bit RGB DPX source to
> DNxHD and I can't make it right either.  The range
> gets re-scaled to 16-235

Imo, that's mostly because so far, nobody has uploaded
a RGB image which is not full-scale.

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/6/2014 12:46 AM, Carl Eugen Hoyos wrote:

> Imo, that's mostly because so far, nobody has uploaded
> a RGB image which is not full-scale.

Where would you like one?  I can provide an unlimited number of them
(they are pretty easily made.)  I can collect together all kinds of
samples when I get to the office tomorrow.

I found some references to -color_range but browsing quickly through the
source it seems only hooked up to a few specific codecs.

On 6/6/2014 12:28 AM, tim nicholson wrote:

> ISTR that if you give ffmpeg RGB it assumes its full range

That's what I've found;  Giving it 10-bit RGB DPX files already at 709
levels (64-940 and 709 color matrix) and going to DNxHD it was scaling
the levels again, as if the input was full range.

> it also by default converts using 601 matrices.

That's probably true as well; 601 and 709 are kinda close, and my test
images weren't particularly saturated so the shift I was seeing was not
dramatic.

I could make things worse though using -vf colormatrix=bt601:bt709 :)

Ignoring the overall range scaling, not using colormatrix in this
instance gets pretty close -- maybe only as close as is possible for
RGB->YUV->RGB (since I was inevitably looking at the results as RGB) but
I'll have to revisit in the morning because I don't completely remember
-- my number of test compression files last night was getting out of
control :)

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Andy Furniss-2
In reply to this post by Bob Maple
Bob Maple wrote:

>> I think it's in an atom called ACLR;  I doubt ffmpeg writes this
>> either...
>
> So in looking at the source, ffmpeg _does_ write this Avid extension
> if the codec is DNxHD, and hard-codes it as 'RGB range' which sounds
> wrong but the Avid codecs give the right result and it looks right
> in Quicktime Player.  This was converting v210 (Uncompressed 4:2:2
> 10-bit) to DNxHD.
>
> With that said, I just did some tests from a 10-bit RGB DPX source
> to DNxHD and I can't make it right either.  The range gets re-scaled
> to 16-235 (even though it already is) and the color primaries aren't
> right... but the math for this is starting to go out of my
> territory, and trying to figure out the path through the code is
> going even further.

Recalling some tests I did in another thread, the only way I know to get
rgb -> yuv without getting the ranges changed is to use yuvj. I guess
there is another way as this gets described as depreciated, but using
the range parameter only seems to work when doing yuv -> yuv.


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
In reply to this post by Carl Eugen Hoyos
> Imo, that's mostly because so far, nobody has uploaded
> a RGB image which is not full-scale.

Here's a link to a zip archive of some sample images and a text
explanation of what they all are/what ffmpeg seems to be doing with them.

http://clients.idolum.com/get/7a39da115ec0

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Carl Eugen Hoyos
In reply to this post by Gregory Ducatel
Gregory Ducatel <gducatel <at> gmail.com> writes:

> ffmpeg.exe -y -threads 8 -f image2

The dpx decoder is currently not multi-threading
capable: This would be trivial to add but I wonder if
it helps performance in any case (I/O should be slower
than dpx decoding).

> -r 24000/1001

(Unrelated: This may be unnecessary because FFmpeg
does read the framerate field from dpx images now.
It is of course necessary with the workaround below.)

> -i "Source_file.%04d.dpx"
> -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info
> -c:v dnxhd -pix_fmt yuv422p -b:v 115M
> -vf "[in]scale=1920:1080,colormatrix=bt601:bt709[out]"
> -movflags +faststart -aspect 1.777778 "c:\test_dnxhd.mov"

I was unable to find a possibility to make FFmpeg assume
MPEG range for the input sample (and I was unable to find
any hint within the dpx file that it is not full scale
which is expected for rgb afaict, if somebody could help
with the detection, it would be useful!), you currently
have to cheat:

$ ffmpeg -i input.dpx -f rawvideo
-sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info
-pix_fmt yuvj422p out

(You could probably compress the output, in any case you
can use -f image2 -vcodec rawvideo if that suits your
needs better.)

$ ffmpeg -f rawvideo -s 1920x1080 -r 24000/1001 -pix_fmt yuv422p
-i out -vcodec dnxhd -vb 115M -movflags +faststart out.mov

Note the different colour spaces used for writing and reading.
Above may not be perfect but since you are converting
from 10bit to 8bit with subsampling I would (perhaps
wrongly?) assume that the output does not have to
be perfect.
In any case: Please test and let me know if this is
closer to what you expect.

I would open a ticket but I am still hoping for a
checkerboard or at least a dpx sample with large
white and black areas.

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
On 10 June 2014 16:39, Carl Eugen Hoyos <[hidden email]> wrote:

> Gregory Ducatel <gducatel <at> gmail.com> writes:
>
> > ffmpeg.exe -y -threads 8 -f image2
>
> The dpx decoder is currently not multi-threading
> capable: This would be trivial to add but I wonder if
> it helps performance in any case (I/O should be slower
> than dpx decoding).
>
> > -r 24000/1001
>
> (Unrelated: This may be unnecessary because FFmpeg
> does read the framerate field from dpx images now.
> It is of course necessary with the workaround below.)
>
> > -i "Source_file.%04d.dpx"
> > -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info
> > -c:v dnxhd -pix_fmt yuv422p -b:v 115M
> > -vf "[in]scale=1920:1080,colormatrix=bt601:bt709[out]"
> > -movflags +faststart -aspect 1.777778 "c:\test_dnxhd.mov"
>
> I was unable to find a possibility to make FFmpeg assume
> MPEG range for the input sample (and I was unable to find
> any hint within the dpx file that it is not full scale
> which is expected for rgb afaict, if somebody could help
> with the detection, it would be useful!), you currently
> have to cheat:
>
> $ ffmpeg -i input.dpx -f rawvideo
> -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info
> -pix_fmt yuvj422p out
>
> (You could probably compress the output, in any case you
> can use -f image2 -vcodec rawvideo if that suits your
> needs better.)
>
> $ ffmpeg -f rawvideo -s 1920x1080 -r 24000/1001 -pix_fmt yuv422p
> -i out -vcodec dnxhd -vb 115M -movflags +faststart out.mov
>
> Note the different colour spaces used for writing and reading.
> Above may not be perfect but since you are converting
> from 10bit to 8bit with subsampling I would (perhaps
> wrongly?) assume that the output does not have to
> be perfect.
> In any case: Please test and let me know if this is
> closer to what you expect.
>
> I would open a ticket but I am still hoping for a
> checkerboard or at least a dpx sample with large
> white and black areas.
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>

I've got a nice sequence in Full range RGB BT.709 dpx. 1920x1080 with a
checkerboard, ARIB-STD B28 colorbars, a resolution chart and of course
Kodak's Marcie.
I'll zip it up and put it somewhere to download in the next half hour.

--
C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
>
>
> I would open a ticket but I am still hoping for a
>> checkerboard or at least a dpx sample with large
>> white and black areas.
>>
>> Carl Eugen
>>
>
The 100 frame test sequence can be found here. These are Full Range BT.709
HD DPX files.

http://theambassadors.nl/lab/color/ARIB_STD-B28_FULLRANGE_BT709_Test_Sequence.zip

Here is the colorbar's implementation in OpenEXR and it's PDF spec along
with some values in BT.709, sRGB and Linear.

http://theambassadors.nl/lab/color/ARIB_STD-B28_Spec_And_Implementation.zip


By all means if there is anything that can be improved upon any of the
files like the readout document or any other part of the sequence let me
know!

Rio

--
C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/10/2014 11:01 AM, Rio Kierkels wrote:

> The 100 frame test sequence can be found here. These are Full Range BT.709
> HD DPX files.
>
> http://theambassadors.nl/lab/color/ARIB_STD-B28_FULLRANGE_BT709_Test_Sequence.zip

Hmm...  I can't seem to interpret these correctly;  They appear to have
a strange gamma applied to them or something - at least the bars are not
correct interpreted as either full-range RGB (0-255/0-1023) or 709 range
(16-235/64-940), I can't make them match any of my SMPTE bars.

?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
That is interesting. Could you maybe take the exr from the other zip file
and render it to dpx so we cant get an idea about what you expect to see?

These dpx files are rendered from it in nuke going from linear to 709 with
2.2 gamma if i remember correctly. What sofware are you testing in?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/10/2014 2:30 PM, Rio Kierkels wrote:

> That is interesting. Could you maybe take the exr from the other zip file
> and render it to dpx so we cant get an idea about what you expect to see?

The EXR seems right.  Here's a re-export of it as 10-bit RGB DPX at 709
levels:

http://clients.idolum.com/get/cd62f6feb896

Here's also a capture of my scope from the DPX sequence and of the EXR.
 You can see the arc in the ramp on the DPX, the elevated chroma levels,
etc.

DPX Imported: http://clients.idolum.com/get/6714cf583c5b
EXR Imported: http://clients.idolum.com/get/08f993a4c57c

It seems like maybe the DPX is either tagged wrong, or some operation
happened twice.  If I apply a 'Remove Rec709 Transform' LUT to the DPX,
it winds up correct.

> These dpx files are rendered from it in nuke going from linear to 709 with
> 2.2 gamma if i remember correctly. What sofware are you testing in?

Autodesk Flame or Avid DS.

Bob

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
In reply to this post by Carl Eugen Hoyos
On 6/10/2014 8:39 AM, Carl Eugen Hoyos wrote:

> I was unable to find a possibility to make FFmpeg assume
> MPEG range for the input sample (and I was unable to find
> any hint within the dpx file that it is not full scale
> which is expected for rgb afaict, if somebody could help
> with the detection, it would be useful!)

It's the "Transfer" byte at 0x321 right after the descriptor byte (0x320
in the header which specifies RGB, RGBA, etc.)  ffmpeg currently skips
over it (along with the Colorimetric byte that follows it at 0x322.)

While it can be a bunch of different things (Linear, Log..) in general
it will be 6 for 709 levels, or 0 for full-range RGB levels (which is
actually "user defined")

> you currently have to cheat:
>
> $ ffmpeg -i input.dpx -f rawvideo
> -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+print_info
> -pix_fmt yuvj422p out
>
> (You could probably compress the output, in any case you
> can use -f image2 -vcodec rawvideo if that suits your
> needs better.)

I can't get this to work for more practical applications like going to
DNxHD or even uncompressed 8 or 10-bit.  The -sws_flags seem to have no
affect on the result. And you can't use -pix_fmt yuvj422p because DNxHD
(and others) don't allow it:

  Incompatible pixel format 'yuvj422p' for codec 'dnxhd', auto-selecting
format 'yuv422p'

(Really we want the _source_ format to be able to be interpreted as
yuvj422p (I think?) or whatever it means so as NOT to scale the dynamic
range when going to other formats like yuv422p, yuv422p10, etc.)

> $ ffmpeg -f rawvideo -s 1920x1080 -r 24000/1001 -pix_fmt yuv422p
> -i out -vcodec dnxhd -vb 115M -movflags +faststart out.mov
>
> Note the different colour spaces used for writing and reading.
> Above may not be perfect but since you are converting
> from 10bit to 8bit with subsampling I would (perhaps
> wrongly?) assume that the output does not have to
> be perfect.

Sure (although it's worth pointing out there are some 10-bit versions of
DNxHD, which ffmpeg supports though I haven't played with it extensively
- but yuv422p10 at 175M could be substituted in the above example)

> I would open a ticket but I am still hoping for a
> checkerboard or at least a dpx sample with large
> white and black areas.

Here's a very simple 10-bit RGB DPX at 709 levels.  It's 1920x1080; the
top 540 lines are black 64/64/64.  The bottom 540 lines are white
940/940/940.

http://clients.idolum.com/get/3f8e593cd892

The goal would be to be able to convert it to DNxHD Quicktime,
Uncompressed 8/10-bit Quicktime, or even ProRes Quicktime for instance
and not have ffmpeg re-scale the levels when it converts RGB->YUV,
because they are already scaled in the source.

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Carl Eugen Hoyos
Bob Maple <bobm-ffmpeg <at> burner.com> writes:

> Incompatible pixel format 'yuvj422p' for codec
> 'dnxhd', auto-selecting format 'yuv422p'

Just to make sure we understand each other:
Did you test the command lines I provided?
Or did you test them, found out that they
don't work and improved them?
I ask because I am not sure how I can
reproduce above error message with the
command lines I provided.

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
12