DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   CineForm Software Showcase (https://www.dvinfo.net/forum/cineform-software-showcase/)
-   -   Behaviour of Cineform in Resolve 12 (https://www.dvinfo.net/forum/cineform-software-showcase/531609-behaviour-cineform-resolve-12-a.html)

Bryan Worsley April 13th, 2016 01:42 PM

Behaviour of Cineform in Resolve 12
 
Not sure if my query would be best addressed here or on the BlackMagic forum, but I'll start here.

I'm giving the standalone Windows version of DaVinci Resolve 12 a try and have been doing some preliminary testing to examine the behavior of different input and output video formats with respect to luma levels.....always a good idea.

Testing some native AVCHD.mts and HD-AVC mp4/mov sample clips from various camcorders and DSLR's and I'm delighted to find that when rendered out to Cineform (as avi or mov), with no effects/transforms applied (i.e. "pass-through"), the original YUV scaling of the source clips is preserved.

Taking, for example, a 1080/29.97PF.mts clip from a Canon HF-G10, here's the 'raw' YUV Histogram of the source:

http://i.imgur.com/BuuN8wa.jpg

and here's the histogram of the Cineform.avi (Best quality) render:

http://i.imgur.com/1Ic6Czz.jpg

So there the original 16-255 range YUV scaling is preserved - and with very little quality loss (97.7 % score as measured by SSIM - 100% being lossless).

Looking at the Histogram and Parade scopes with the native test clips on the timeline it would appear that, to all intents, Resolve is mapping 0-255 YUV (Y'CbCr) > [0,0,0]- [255,255,255] RGB and thence back to 0-255 range YUV, (Y'CbCr). So no clamping or compression, with Cineform at least (DNxHD and H264 are another story).

And here's what 1080/29.97PF mts clip looks like on the Resolve scopes. The source 16-255 YUV (Y'CbCr) range gets mapped to 16-255 RGB:

http://i.imgur.com/6Eg7YY0.png

Fine with that. Vegas (by default) interprets native AVCHD clips in the same way.

Now, if I take the Cineform.mov render and put it through Resolve and render out to Cineform again, the luma scaling is still preserved. Great. But, here's the twist. If I instead use the Cineform.avi render as source the outcome is different. In the case of the 1080/29.97PF clip, the 16-255 luma range gets stretched out to 0-255:

http://i.imgur.com/ZD7YlKT.jpg

If I'm interpreting this correctly, in this case Resolve is applying regular Rec709 conversion to 16-255 range Cineform render, so mapping only 16-235 YUV (Y'CbCr) data values > [0,0,0]- [255,255,255] RGB. That's evident from the scopes:

http://i.imgur.com/qLJhbeq.png

But Cineform still applies full range mapping back to YUV. So the net result is a composite of clamping/clipping to 16-235 and then out-scaling to 0-255. Not at all desirable, for my purposes at least. Clearly then, Cineform avi and mov encodes are interpreted very differently by Resolve and I can only assume this in someway relates to metadata flags?

My question is whether there is any way to get Resolve to interpret Cineform files encoded in avi format in the same manner as the Cineform (QT) mov encodes?

Edit:

Re: "..DNxHD and H264 are another story"

Just for completeness, this is what happens when that Canon HF-G10 1080/29.97PF clip is (pass-through) rendered out to DNxHD (220):

http://i.imgur.com/guTuxbq.jpg

and H264 (Best quality):

http://i.imgur.com/0xE8uV0.jpg

In both cases the luma is compressed to 32-235. Similarly, when HD-AVC mp4/mov clips recorded with full range luma, are "pass-through" rendered to DNxHD or H264, the luma gets compressed (not clamped) to 16-235. Example - testing a 1080/25p HD-AVC.mov clip from a Canon EOS M3:

Original clip (and same for Cineform render):

http://i.imgur.com/no5X3uz.jpg

and DNxHD render:

http://i.imgur.com/ciztcKf.jpg

The logical explanation - full scale mapping of source YUV to RGB, but then Rec709 mapping back to YUV.

So good reasons why I would not use the built-in H264 encoder for rendering and would choose Cineform as an output intermediate format for encoding to H264 deliverables in another system; and for me that would be AVISynth frame-served to MeGUI or ffmpeg for encoding x264, so requiring Cineform in avi format.

Out of interest though, is it possible that Resolve uses ffmpeg for rendering DNxHD, as you see the exact same behavior when transcoding full scale (0-255) HD-AVC mov/mp4 clips to DNxHD with ffmpeg Same goes for ffmpeg ProRes. The reason for that is that the full range pixel format flag (pix_format yuvj422p) is not respected and defaults back to limited 16-235 range scaling. Just wondering.

Anton Shekhovtsov April 14th, 2016 01:53 AM

Re: Behaviour of Cineform in Resolve 12
 
Maybe this adds to discussion
When doing similar tests with cineform vfw codec 9.0.5 I discovered strange behavior.
The codec has options like enc:video rgb / dec:video rgb.
enc:video rgb works as expected (rgb is converted as either full range or not) except that this option is not stored in any way within the avi file (I have no evidence of any tag or single byte). So when decoding the avi back the only chance to get it right is to set conversion mode manually.
At the same time the other option, enc:709, is obviously stored within avi file.

I am curious if this behavior is confirmed and or has some explanation.

Bryan Worsley April 14th, 2016 09:28 PM

Re: Behaviour of Cineform in Resolve 12
 
Perhaps someone from the Cineform/GoPro team could respond on that point ?

There is no option for configuring the Cineform vfw codec in Resolve, but I did try changing the default "ITU.BT.709" setting to "Video Systems RGB" with the Cineform VFW Control Panel opened in VirtualDub, just to see if changed the way the Resolve Cineform.avi renders were interpreted by Resolve when used as input, and it made no difference.

I also looked at creating some Cineform.avi files with the vfw codec using VirtualDub and AVISynth to see how they behaved with different configuration settings. What surprised me in that case is that none of them were recognized by Resolve at all - just didn't appear in the Media Files selection window. Wasn't expecting that.

Next thought - well OK, so lets see how Resolve treats Cineform files created with GoPro Studio. GoPro Studio doesn't accept AVCHD.mts files, but I managed to transcode a couple of full-range HD-AVC mp4/mov clips from Canon/Nikon DSLR's and one 16- 255 range HD-AVC.mp4 clip from a Panasonic FZ330. The Cineform encodes (in both avi and mov format) all retained the YUV scaling of the source clips. What's more, all were recognized and accepted for input by Resolve. But when I came to examine how they were interpreted by Resolve, all of them behaved just like the Cineform.avi renders that were created when the original native clips were used for input.

Whether Cineform files produced by Vegas or Premiere behave any differently, I really don't know - I don't use either.

As it stands, the only only way I can see to produce Cineform transcodes that that are accepted by Resolve and which perpetuate the luma scaling and behavior of the original native clips, is to use Resolve as the "pass-through" transcoder and render in QT (mov) format only....unless (returning to my original query) there is some way to force/dupe Resolve into interpreting Cineform.avi transcodes in the same manner. And if there isn't, maybe there should be. This is a standalone version for Windows after all.

Bryan Worsley April 15th, 2016 08:16 AM

Re: Behaviour of Cineform in Resolve 12
 
As regards:

Quote:

Originally Posted by Bryan Worsley (Post 1912597)
So good reasons why I would not use the built-in H264 encoder for rendering and would choose Cineform as an output intermediate format for encoding to H264 deliverables in another system; and for me that would be AVISynth frame-served to MeGUI or ffmpeg for encoding x264, so requiring Cineform in avi format.

On the bright side:

http://www.dvinfo.net/forum/cineform...ml#post1912728

Now that ffmpeg has an open Cineform decoder there is at least an option for transcoding Resolve Cineform renders (mov or avi) to x264 directly with ffmpeg, as well as converting to linux-compatible lossless formats (UTVideo, HuffYUV etc).

As for the behaviour I observed with DNxHD files . Appears that this is a long-standing issue:

https://forums.creativecow.net/thread/277/14750

Bryan Worsley April 16th, 2016 08:22 AM

Re: Behaviour of Cineform in Resolve 12
 
Quote:

Originally Posted by Bryan Worsley (Post 1912711)
As it stands, the only only way I can see to produce Cineform transcodes that that are accepted by Resolve and which perpetuate the luma scaling and behavior of the original native clips, is to use Resolve as the "pass-through" transcoder and render in QT (mov) format only....unless (returning to my original query) there is some way to force/dupe Resolve into interpreting Cineform.avi transcodes in the same manner. And if there isn't, maybe there should be. This is a standalone version for Windows after all.

Ah, OK, I've figured it. To force the "pass-through" Cineform.avi render to behave in the same manner as the original native clip (whether 16-255 or 0-255 range), and so perpetuate the luma scaling, it's simply a matter of resetting the Clip Attributes > Levels from Auto to Data Levels 0-1023, which flags the clip as being full scale.

Same applies to importing Cineform.avi or mov transcodes from GoPro Studio, and also Cineform.avi files rendered (as a Custom AVI profile) from Vegas; I tested it with the trial version of Vegas Pro 13.

As for issue with the DNxHD and H264 renders where the luma gets compressed to 32-235 with 16-255 range sources and to 16-235 with 0-255 range sources, that can be resolved by resetting the Video/Data Level, tucked away in the +More Options drop-down under Render Settings, from Auto to Data (0-1023), which forces full scale output.

So, a satisfactory conclusion all round.

Still a bit disappointed though that Cineform avi files created with AVISynth/VirtualDub are not recognized at all by Resolve. But there is at least the option of frame-serving to ffmpeg for encoding DNxHD.mov or ProRes.mov files, which are accepted by Resolve.

Bryan Worsley April 20th, 2016 09:40 AM

Re: Behaviour of Cineform in Resolve 12
 
That said, just discovered that Resolve won't import AC3 audio from AVCHD.mts files. Didn't pay much attention to the audio streams (or lack of) when doing these video luma and quality metric tests, and figured it would be just a question of selecting the right audio settings. But no:

https://forum.blackmagicdesign.com/v...p?f=21&t=39643

Not an issue for Vegas Pro and/or PP users of course, who can "pass-through" render to Cineform/PCM or use Adobe Media Encoder to transcode, but for me it severely limits the options.

GoPro Studio doesn't accept mts files and Resolve doesn't accept Cineform/PCM avi files created with AVISynth/VirtualDub. Also just tried converting some native AVCHD.mts (1080/29.97PF, AC3) clips to mts files re-muxed with the transcoded AC3>WAV audio, but Resolve doesn't recognize them at all.

As for the workaround suggested in the above linked BlackMagic forum thread - using ffmpeg to "re-wrap" the H264 stream with PCM audio as a mov file. Well I tried that with some native 1080/30PF and 1080/60i AVCHD.mts clips. The files were recognized by Resolve, but correct interpretation of the interlace flagging gets messed up along with the timecode and the loaded files are unusable. If anyone has got this to work, I'd love to know how.

The only acceptable workarounds I can come up with for creating Cineform edit intermediates are:

Encoding the native mts files (with ffmpeg) to "Lossless" x264 (AVC, High 4:4:4 Predictive Intra) with aac audio in mp4 or mov format. The transcodes are a little too resource hungry for smooth native editing/grading in Resolve (on my PC anyway), but at least provide a lossless intermediate for "pass-through" conversion of AVCHD (AC3).mts files to Cineform.

Or else, pre-converting the demuxed AC3 audio to WAV, loading the native mts clips and respective WAV files into Resolve, matching them up on the timeline and "pass-through" rendering out to Cineform. Rather tedious.

So do-able, but all things considered, direct transcoding to DNxHD-PCM.mov with ffmpeg does seem the better option.

I'm just surprised to find that one has to resort to these measures to work with AVCHD.mts material in Resolve.

Anton Shekhovtsov April 21st, 2016 01:23 AM

Re: Behaviour of Cineform in Resolve 12
 
Quote:

Originally Posted by Bryan Worsley (Post 1913048)
...Resolve doesn't accept Cineform/PCM avi files created with AVISynth/VirtualDub

Sorry if too obvious, but did you contact Resolve support? Sounds like the defect belongs to them (I assume you can open the same avi with every other program?)

Bryan Worsley April 21st, 2016 05:58 AM

Re: Behaviour of Cineform in Resolve 12
 
Well I was rounding up to raising this and a few other points on the BM forum, but I thought I might have got some response from the GoPro/Cineform team; probably off at NAB.

Yes, Cineform.avi files created with vfw codec (accessible through VirtualDub) open with other Windows programs that can work with accessible third-party vfw lossless codecs - UTVideo, FFV1, MagicYUV and the like. There again Resolve doesn't support these other formats (as avi or mov files) either, which is perhaps the more general point. VFW/VCM is oft proclaimed as being an obsolete/deprecated format that has waning value in the Professional realm - maybe so, but other Professional level windows-based programs still support it, at least for input. And it's not as if Resolve doesn't support AVI - it's just that for some reason they have chosen to restrict that to Cineform and Uncompressed.

Edit: Well I never did ! One thing I hadn't tried was converting ("re-wrapping") the Cineform/PCM.avi files (encoded with the vfw codec) to mov files. Just tried that, lo and behold the "re-wrapped" mov files open in Resolve just fine. Only thing is, just like the Cineform.avi files produced by Resolve, the Data Level (in the Clip Attributes) needs to be set to "Full" (as it now appears in 12.5 beta) in order to preserve the luma range of the original clips.

Oooh, suits me Sir ! (Brits will understand).

Christopher Young April 22nd, 2016 11:15 AM

Re: Behaviour of Cineform in Resolve 12
 
Quote:

Originally Posted by Bryan Worsley (Post 1912711)
Whether Cineform files produced by Vegas or Premiere behave any differently, I really don't know - I don't use either.

From memory to the best of my knowledge no they don't behave any differently. Or if they do I don't recall it.

I've found the best application on Windows that handles Cineform, ProRes and DNxHD correctly from virtually any source is FootageStudio4K. FootageStudio4K also has a host of other useful tools beside transcoding. Check out their trial version:

Acrovid - FootageStudio - Format conversions, Video Standard conversions, Frame rate conversions, SD-HD conversions, Video Denoise, Overcrank.

I have no association with Acrovid but when I see useful software I will pass the word along.

Chris Young
CYV Productions
Sydney

Bryan Worsley April 22nd, 2016 10:07 PM

Re: Behaviour of Cineform in Resolve 12
 
Thanks Christopher,

After that post I did go on to test some Cineform.avi files produced with the trial version of Vegas Pro 13 and yes they are accepted by Resolve and behave (with respect to luma scaling) in the same manner as the Cineform.avi files created by Resolve and GoPro Studio:

Quote:

Originally Posted by Bryan Worsley (Post 1912777)
....Same applies to importing Cineform.avi or mov transcodes from GoPro Studio, and also Cineform.avi files rendered (as a Custom AVI profile) from Vegas; I tested it with the trial version of Vegas Pro 13.

One thing I didn't explain, and part of the reason why I was keen to find a way for Resolve to accept these Cineform.avi files created via AVISynth/VirtualDub, is that I (still) prefer to do some of my PP with AVISynth filters (luma levels adjustment, for one ) and I want keep that flexibility whilst accommodating Resolve in my workflow. Using DNxHD.mov as the exchange intermediate in that context is workable but would be a little more involved than using Cineform.avi. So that's why I wanted to explore all of the options.

As it turns out, the solution - "re-wrapping" the Cineform.avi files as mov files - is simpler than I first thought. And apparently, if you use QT 7 Pro (which I don't) it's even simpler - just a matter of creating a QT reference file.

So, I'm confident that I now have all the options covered, even if the methods involved might seem a little convoluted to some folks.

But thanks for the heads-up on the FootageStudio4K. I will have a look at the trial version when I have a moment - for one thing, I'm always intrigued by any software that purports to do native frame accurate trimming of AVCHD/H264....and I've tried most of them.

Cheers.

Christopher Young April 23rd, 2016 05:25 AM

Re: Behaviour of Cineform in Resolve 12
 
Bryan

Also if you want to quickly re-wrap Cineform AVIs to MOV or vice-a-versa just download 'Another GUI' it's quick and simple. Built around FFMPEG. Also good for creating ProRes on Windows should you or clients need it.

Chris Young
CYV Productions
Sydney

Bryan Worsley April 23rd, 2016 10:09 AM

Re: Behaviour of Cineform in Resolve 12
 
Thanks again Christopher,

I had come across Another GUI before. As the same suggests - "another" ffmpeg front-end GUI, so nothing that I can't do already with ffmpeg CLI, and I still prefer to work that way. But I can appreciate why such tools would be useful to some - and this one is at least free.

I had a look at FootageStudio4K also - yes I agree, it's a well designed and versatile standalone video conversion suite - and so it should be for the price ;) Like Resolve it requires GoPro Studio to be installed to access the Cineform vfw codec interface and the Cineform outputs, in both avi and mov format, are accepted by Resolve.

It doesn't do true native frame accurate cut-editing of AVCHD/H264 by the way - by which I mean re-constructing and re-encoding only those frames around a cut/re-splice point to maintain GOP integrity i.e. so called "Smart Rendering". So it's just trimming prior to transcoding.

Interesting though that these video conversion tools have absolutely no problem decoding AC3 audio sources, presumably using ffmpeg to do so. According to this thread BM had to withdraw AC3 support because Dolby went after them for an exorbitant licensure fee:

https://forum.blackmagicdesign.com/v...37632&start=50

Christopher Young April 23rd, 2016 09:56 PM

Re: Behaviour of Cineform in Resolve 12
 
Hi Bryan

I've not tried cutting H.264 in FS4K I've just used it to produce primarily Cineform.avi clips plus the occasional ProRes or DNxHD clips. A couple of the editors I work with are not really up to speed with CLI commands so getting them to use Another GUI was quick and simple.

Interesting the BM and Dolby thing. Dolby have never had a reputation of letting their IP rights go cheaply so it doesn't surprise me that they chase the bigger players who they think may sufficient $$$'s to cough up. Chasing all the little GUI apps like ClipToolz and others of that ilk based around FFMPEG probably isn't worth their while if the prospect of getting any money out of them is slim. All I can say is thanks for FFMEG.

Chris Young
CYV Productions
Sydney

Christopher Young April 23rd, 2016 10:02 PM

Re: Behaviour of Cineform in Resolve 12
 
Duplicated

Bryan Worsley May 15th, 2016 06:15 PM

Re: Behaviour of Cineform in Resolve 12
 
Quote:

Originally Posted by Bryan Worsley (Post 1912777)
Ah, OK, I've figured it. To force the "pass-through" Cineform.avi render to behave in the same manner as the original native clip (whether 16-255 or 0-255 range), and so perpetuate the luma scaling, it's simply a matter of resetting the Clip Attributes > Levels from Auto to Data Levels 0-1023, which flags the clip as being full scale.

BTW, as I've just discovered, the same applies to transcoding native clips to Cineform.avi or DNxHD.mov using the Transcode function in Media Management. The 'Data Level' (as 'Levels' is now called in Resolve 12.5 beta) in the Clip Attributes needs to be changed from (default) 'Auto' to 'Full' in order to preserve the luma scaling of the native clip(s).


All times are GMT -6. The time now is 12:16 AM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2024 The Digital Video Information Network