-
Is ProRes HQ 444 useless?
This was based on some observations with FFMBC, but it appears that it’s using a version of prores_kostya so results should be very similar. I apologize for the strangeness of my writing, this was adapted from an FFMBC issue report, I didn’t feel like retyping it conversationally.
1. Encode file with 10bit RGB codec (ex. Aja RGB)
2. encode using following line:ffmbc.exe -i rgb.mov -threads 16 -vcodec prores -profile hq -pix_fmt yuv444p10 -acodec copy -vf “format=yuv422p,colormatrix=bt601:bt709” rgb_out.mov
Expected to use cleaner command line, for example:
ffmbc.exe -i rgb.mov -threads 16 -vcodec prores -profile hq -pix_fmt yuv444p10 -acodec copy rgb_out.movCurrently, the line directly above leads to a huge color shift. Some people point out this is because of SWS_CS_DEFAULT value in swscale.h – I have altered and recompiled with no success. ProresEnc.c also claims to use Rec 709 primaries and matrix for HD sized frames.
-vf “format=yuv422p,colormatrix=bt601:bt709” is a work around but does not maintain color precision as the matrix conversion is done in 422 8-bit. This is also dangerous because -vf “colormatrix=bt601:bt709″ alone falls back on yuv420p precision.
Since no professional YUV 444 10bit codecs exist, there is no way to feed ffmbc an RGB encoded video and maintain fidelity to ProRes HQ 444. This renders ProRes HQ 444 useless as ProRes HQ 422 can be fed a 422 YUV codec and is not prone to conversion/precision issues.
I’m on Windows 8, FFMBC 0.7rc8 32-bit and 64-bit
——
C:\Users\Angelo>”C:\Users\name\Desktop\ffmbc.exe” -v 3 -i “D:\watch\green_rgb.
mov” -threads 16 -vf “format=yuv422p,colormatrix=bt601:bt709” -vcodec prores -pr
ofile hq -pix_fmt yuv444p10 -acodec copy “D:\watch2\green_rgb.mov”
FFmbc version 0.7-rc7
Copyright (c) 2008-2012 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘D:\watch\green_rgb.mov’:
Metadata:
major_brand: qt
minor_version: 537199360
compatible_brands: qt
creation_time: 2013-05-10 10:20:19
timecode: 00:00:00:00
Duration: 00:00:01.62, start: 0.000000, bitrate: 500246 kb/s
Stream #0.0(eng): Video: qtrle, rgb24, 1920x1080p, 500211 kb/s, PAR 1:1 DAR
16:9, 23.98 fps
Metadata:
codec_name: Animation
Stream #0.1(eng): Data: unknown (tmcd)
File ‘D:\watch2\green_rgb.mov’ already exists. Overwrite ? [y/N] y
[scale @ 03742660] w:1920 h:1080 fmt:rgb24 -> w:1920 h:1080 fmt:yuv422p flags:0x
4
[colormatrix @ 03737B00] bt601 -> bt709
[scale @ 03742200] w:1920 h:1080 fmt:yuv422p -> w:1920 h:1080 fmt:yuv444p10le fl
ags:0x4
Output #0, mov, to ‘D:\watch2\green_rgb.mov’:
Metadata:
encoder: FFmbc 0.7
Stream #0.0(und): Video: prores, yuv444p10le, 1920x1080p [PAR 1:1 DAR 16:9],
263977 kb/s, 23.98 fps
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame= 5 fps= 19 q=1.0 size= 5614kB time=00:00:00.20 bitrate=220531.6kbits
…..
s/s
video:43777kB audio:0kB global headers:0kB muxing overhead 0.002324%—
FFMPEG’s legacy ProRes encoder (not prores_kostya) seems to handle RGB material without a color shift but it is limited to yuv422p10. It may be a place to revisit when crafting a solution.
ffmpeg.exe -i rgb.mov -threads 16 -vcodec prores -profile:v 3 -acodec copy rgb_out.mov”
——
Am I missing something? Or is this a development issue?
——————–
Angelo LorenzoNeed to encode ProRes on your Windows PC?
Introducing ProRes Helper, an awesome little app that makes it possible
Fallen Empire Digital Production Services – Los Angeles
RED transcoding, on-set DIT, and RED Epic rental services
Fallen Empire – The Blog
A blog dedicated to filmmaking, the RED workflow, and DIT tips and tricks
Can your post production question fit in a tweet? Follow me on Twitter -
5 Replies
-
I’m not sure what you are asking.
yuv444p10 is somewhat pointless. It offers no advantage over plain RGB. The whole point of YUV colorpspace is to lower the bitrate by reducing chrominance samples. But if you are not dropping chrominance samples, why store it in a YUV colorspace to begin with? If you are concerned enough about color fidelity to be using full chrominace 10 bit sampling, you are just as well off to store the data as an image sequence.
You can force the color space of the input by specifying it’s pix_fmt in front of the “-i” option. If there’s still color issues, then either the color transform is incorrect, or you are doing it wrong.
-
The current ProRes encoder does not support RGB or RGBA color directly, which is why I am forced into using yuv444p10. The RGB -> YUV conversion uses the Rec 601 color matrix which is non-user selectable. You can do a conversion using the video filters, but the fidelity of the calculation is too low.
As it stands, there is no other professional format that would allow me to encode from a program, say Adobe Media Encoder, to an intermediate file and use ffmpeg or ffmbc to encode ProRes 444 with no color shifts or lossy color matrix conversions.
-pix_fmt in front input errors on the most recent builds of FFMBC and FFMPEG. Forcing it wouldn’t guarantee a pristine conversion though, kind of a moot point.
I may just dive into the color matrix filter code and up the fidelity. Pain in the butt to maintain a private build.
——————–
Angelo LorenzoNeed to encode ProRes on your Windows PC?
Introducing ProRes Helper, an awesome little app that makes it possible
Fallen Empire Digital Production Services – Los Angeles
RED transcoding, on-set DIT, and RED Epic rental services
Fallen Empire – The Blog
A blog dedicated to filmmaking, the RED workflow, and DIT tips and tricks
Can your post production question fit in a tweet? Follow me on Twitter -
Seems like I’ve come across a better solution. “-color_primaries bt470bg” as an argument after input seems like a cleaner conversion (whatever it’s doing exactly, I’ve yet to look in source) with no minute color shift and better accuracy than the video filter color matrix.
——————–
Angelo LorenzoNeed to encode ProRes on your Windows PC?
Introducing ProRes Helper, an awesome little app that makes it possible
Fallen Empire Digital Production Services – Los Angeles
RED transcoding, on-set DIT, and RED Epic rental services
Fallen Empire – The Blog
A blog dedicated to filmmaking, the RED workflow, and DIT tips and tricks
Can your post production question fit in a tweet? Follow me on Twitter -
It sounds like the source of your problem is with conversion between systems the use full range luma and systems using 16-235 luma.
However that sounds a bit odd, since bt470bg is for the older 601 standard-def transform for PAL. You might want to check and see if you shouldn’t be using bt709 color primaries.
-
So far as I know, the RGB -> YUV conversion uses the Rec. 601 primaries (a known source of complaints in the FFMPEG project that no one cares add a switch for). Tagging the output as using these primaries, for whatever reasons, either aids in or completely avoids a matrix transformation, even if the material is Rec. 709.
Not sure why it works, or exactly what the logic is in the processing chain, but it works and colors match from input to output.
——————–
Angelo LorenzoNeed to encode ProRes on your Windows PC?
Introducing ProRes Helper, an awesome little app that makes it possible
Fallen Empire Digital Production Services – Los Angeles
RED transcoding, on-set DIT, and RED Epic rental services
Fallen Empire – The Blog
A blog dedicated to filmmaking, the RED workflow, and DIT tips and tricks
Can your post production question fit in a tweet? Follow me on Twitter
Reply to this Discussion! Login or Sign Up