DNxHD colorspace issue.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Converting files to DNxHD .movs
2.
3.

What is the expected output? What do you see instead?
Expect the colorspace to be Rec.709 for HD, but get the Rec.709 colorspace used 
for SD.

What version of the product are you using? On what operating system?
I am using a third party buid of FFmbc-0.7-rc4. My operating system is Windows 
7. It is about time for me to learn how to build it by myself, but I am not 
there yet.

Please provide any additional information below:
I have solved the issue with an interesting workaround. By using "-vf 
colormatrix=bt601:bt709" I can change the Rec.709 input colorspace to another 
non-standard colorspace that, when transcoded into DNxHD in Rec.601 will 
actually be in Rec.709. It works. My guess is there is a flag that needs to be 
set to automatcally go to Rec.709 colorspace. With this workaround, I can now 
import footage quickly into Avid Media Composer. Here is the full commandline 
that I put in a .bat file for drag-n-drop encoding:

ffmbc -threads 8 -i %1 -vf colormatrix=bt601:bt709 -pix_fmt yuv422p -vcodec 
dnxhd -b 175M -ar 48k -acodec pcm_s16le %~n1_FFM_601-709.mov
pause

Thank you very much for this project. I hope this helps!

- Full commandline run (with -v 3) and everything the program printed
without
the repeating parts.
- Upload your sample somewhere and supply url

Original issue reported on code.google.com by mjack...@gmail.com on 14 Jan 2012 at 4:10

[GoogleCodeExporter]

Sorry, this should read thus:

What is the expected output? What do you see instead?
Expect the colorspace to be Rec.709 for HD, but get the Rec.601 colorspace used 
for SD.

Original comment by mjack...@gmail.com on 14 Jan 2012 at 4:12

[GoogleCodeExporter]

encoding does not change the colorspace used.
If you are going from SD to HD you need to convert use colormatrix, the same 
goes
when converting to HD to SD.

I'm gonna close this as invalid because this is the expected behavior currently.
The interesting behavior you mentioned is actually what must be done, and is 
not considered a workaround :)
Colormatrix is made for this, converting from 601 to 709 and vice versa.
I think it could be done automatically when doing SD<->HD

Original comment by baptiste...@gmail.com on 14 Jan 2012 at 4:24

• Changed state: Invalid

[GoogleCodeExporter]

Sorry, but the input files that I am using are HD in the Rec.709 colorspace. 
After conversion, without using "-vf colormatrix=bt601:bt709", the DNxHD file 
that is created is in the Rec.601 colorspace. I have confirmed this with 
multiple tests. When Avid is used to import the material diectly into a 
project, the colorspace is correct (Rec.709 to Rec.709). When I fast import the 
files created with FFmbc, they are in Rec.601. Believe me when I say that 
anytime you are creating DNxHD files for Avid fast import or AMA linking,"-vf 
colormatrix=bt601:bt709" must be used.

Original comment by mjack...@gmail.com on 14 Jan 2012 at 4:38

[GoogleCodeExporter]

Could you please clarify what you mean by "multiple tests" ? For example 
Quicktime is know to stuff funky with the colorspace for example. If you use 
ffmpeg decoder, you will find that the picture decoded is the same than the 
picture given to the encoder.
Doing colormatrix 601 to 709 on an already 709 colorspace produce an unknown 
colorspace, obviously.
It's well known that Quicktime and DNxHD is a funky mess regarding colorspace. 
Also there is a notion of full range YUV vs normal range. You can try to tweak 
it to see if it does what you want by modifying movenc.c and write_avid_tag, 
you'll find reference to full range YUV there.

Original comment by baptiste...@gmail.com on 14 Jan 2012 at 10:54

[GoogleCodeExporter]

I work in the film industry as a video assist operator. With the new HD cameras 
(Arri Alexa, Red Epic, etc.), I recieve a 1080p (true P of PsF) 23.976 fps 
Rec.709 feed from the film cameras and record them on a recording system 
designed specificaly for motion picture reference video. This system uses the 
Decklink Extreme HD cards and records using their 8bit MJPEG codec. These files 
will not be used as the final product, but I keep a library on set for future 
reference and some pre-editing. For the editing, I use Avid Media Composer. The 
reason that I use ffmbc is because it is a much faster way to encode the MJPEG 
files for use in Avid. Now that you know where I am coming from...

I spent the last week perfecting my workflow for media ingestion. This would be 
the multiple tests that I mentioned. I have created a paper explaining the 
testing that I performed so that I could present it to my colleagues in the 
video assist world. I wourked with various formats including Quicktime. I am 
well aware of the problems associated with the gamma difficulties. This is 
noted in my paper. I do agree the perfoming the color matrix change from 601 to 
709 on an already 709 source is quite strange. The space that it enters is not 
really a true space, but when brought back from this space with what I believe 
is a 709 to 601 change, it re-enters the 709 color space. It works.

Please have a look at the paper. It deals with the color space issue, and with 
a field swap issue inherent to the Decklink MJPEG 8bit codec.

As I say in the paper, I do not know how to work with the source code, but that 
is my next project. Time to brush up on my engineering degree from college!

If you want to contact me via e-mail, please do. mjacks1 at earthlink dot net. 
I can send you the example files that I was using for the tests.

Thanks again for the project,

Maury Jacks

Original comment by mjack...@gmail.com on 14 Jan 2012 at 11:25

Attachments:

• Encoding_for_Avid_with_FFmbc_120113.pdf

[GoogleCodeExporter]

I made a small edit on the test results table concerning the 264 formats. 
Please use this enclosed version.

Original comment by mjack...@gmail.com on 14 Jan 2012 at 11:51

Attachments:

• Encoding_for_Avid_with_FFmbc_120114.pdf