VDub2 Canopus HQX 16-bit negotiation issue

[Hotte]

Hi,
I've recently started to pass HBD-Footage (i.e. 10 bit) through AVS+ with VDub2 de- and recompressing with the Canopus HQX codec. Everything worked fine with 8-bit. The clip is export from Edius-X NLE using the Canopus (Grassvalley) HQX Codec which is capable of up to 8K, 10bit, 4:2:2 all-intra in AVI-Containers.

They arrive as YUV422P16 in AVS+ (due to info() and ffmpeg -i) loaded with FFmpegSource2(FILNAM, atrack=-1), further processing works fine. Results appear correctly in VDub2. The trouble starts with "Save as AVI" with constant "Video format negoation error". Output codec again is HQX, mode ist Fast Recompress.

Menu > Video > Decode Format... shows P216 as current format. Whatever I select as at least 10bit-output format: Error persists. Compression menu shows: "Valid pixel formats RGB RGBA YUY2" although the codec is listed under "Similar to Source: P216".

Any ideas ?

[StainlessS]

You might want to say which version VD2 you got.
[Latest is build 44282, 19 Mar 2020:- https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/version%2020/ ]

[Hotte]

Hi StainlessS,
installed latest build 44282, no improvements :(

[Richard1485]

They arrive as YUV422P16 in AVS+ (due to info() and ffmpeg -i) loaded with FFmpegSource2(FILNAM, atrack=-1), further processing works fine. Results appear correctly in VDub2. The trouble starts with "Save as AVI" with constant "Video format negoation error". Output codec again is HQX, mode ist Fast Recompress.

Are you doing this further processing in VirtualDub2? Depending on the filter, you might not be able to use "fast recompress". Try another mode.

[Hotte]

@Richard
all processing / Filtering is done in the avs file, I only use VDub2 as AVS+ host.

Even the following avs:
FFmpegSource2("F:\myhqx.avi", atrack=-1)
Return info(last)

Will not be saved with fast recompress due to the negotiation error - although info() shows that YUV422P16 is being returned.

I`d be happy to change the mode to "Normal recompress" and adjust "Video > Decode format...", but I cannot find a 10-16bit mode that does not return "Unable to initialize video compression. Check that the video codec is compatible with the video frame size and that the settings are correct.."

This message seems inappropriate.

EDIT:
I was retrying to load the hqx-Exportfile directly (without avs+) into VDub2 to do a Fast Recompress with the same codec, no filters. This time HQX it is NOT in the P216 list.
But I am pretty sure the codec must be able to handle this as it produces YUV422P16 itselves. Maybe the handshake information is false or misinterpreted ?

[kolak]

Hi,
I've recently started to pass HBD-Footage (i.e. 10 bit) through AVS+ with VDub2 de- and recompressing with the Canopus HQX codec. Everything worked fine with 8-bit. The clip is export from Edius-X NLE using the Canopus (Grassvalley) HQX Codec which is capable of up to 8K, 10bit, 4:2:2 all-intra in AVI-Containers.

They arrive as YUV422P16 in AVS+ (due to info() and ffmpeg -i) loaded with FFmpegSource2(FILNAM, atrack=-1), further processing works fine. Results appear correctly in VDub2. The trouble starts with "Save as AVI" with constant "Video format negoation error". Output codec again is HQX, mode ist Fast Recompress.

Menu > Video > Decode Format... shows P216 as current format. Whatever I select as at least 10bit-output format: Error persists. Compression menu shows: "Valid pixel formats RGB RGBA YUY2" although the codec is listed under "Similar to Source: P216".

Strange enough: VDub2 has absolutely no problem to take any 10/16bit "hqxin.avi" and save it as "hqxout.avi" without AVS+ as Fast recompress with the same codec.

Any ideas ?

There must be some false detection/reporting.
VFW/DirectShow etc. version of Canopus HQX doesn't support anything above 8bit. It never did. Only Edius and Resolve can export/read 8bit+ data for HQX.

[Hotte]

Kolak, meanwhile I have the same impression: In vfw the HQX-codec is somehow false-detected:

VDub2 reports the codec with: Valid pixel formats: rgb rgba yuy2. This was true for its predecessors (Canopus-HQ/HQ lossless) but not for HQX.

Of course the producer is asked but they won´t probably give a damn about vfw and VDub...

So is there a way to override the check in VDub2 and just let compression go ?

[kolak]

Force YUY2 as pixel format. This will work.
There is no way to do any 8bit+ pixel formats with HQX- nothing you can do about it. It's the way how VFW/directshow codec is written.
Resolve uses native support over low level integration- it doesn't touch VFW/directshow.

rgb rgba yuy2 are still only valid pixels formats for HQX. Well- last time I touched it was was years ago, but I doubt anything changed. VFW/directshow are not very good technologies and pro companies don't touch them anymore.
As I said- HQX outside Edius (Resolve) is 8bit only.

[Hotte]

Thanks kolak.

I have had a look at other high-quality 10-bit all-intra codecs and there we have:

huffyuv, FV1
not compatible with Edius

cineform
compatible but very bad timeline performance

ProRes
compatible, relatively good timeline performance, very fast encoding, 422HQ has IQ pretty close to HQX at highest quality setting (to split hair: HQX superfine has a close to invisible advantage in preserving detail)

DNxHD
compatible but not available

Any other suggestions ?
HEVC / H.264 are not all intra so probably not the best intermediate choice...

My questions:
ProRes could be an candidate. I wonder why this proprietary codec is available in vfw from a technical pov (I thought vfw could not manage >8 bit ?) and from a license pov ? I mean 422HQ is pretty good and XQ freely available - how come ?
Are there any other hq-codecs available and installable - how does that work ?

Thanks for some elucidation

[poisondeathray]

cineform
compatible but very bad timeline performance


Interesting, it's faster in other programs than HQX. Probably the fastest CPU based high quality intermediate . (There are faster GPU ones, like Daniel2, NotchLC)



DNxHD
compatible but not available

You can use ffmpeg as alternative (unless you require something specific in vdub2 ?)


Any other suggestions ?
HEVC / H.264 are not all intra so probably not the best intermediate choice...


HEVC will be too slow to decode.

h264 can be set intra, but even with the fastest decode settings (tune fastdecode, intra) , is typically more sluggish on the timeline (high latency) compared to prores, cineform. (However, some editors can use GPU accelerated decoding of h264, but usually not 10bit422, only the 8bit variants)

But x264 can be significantly higher quality at qp 1 than prores xq4444 or HQX - PSNR is typically ~8-15 db higher)


My questions:
ProRes could be an candidate. I wonder why this proprietary codec is available in vfw from a technical pov (I thought vfw could not manage >8 bit ?) and from a license pov ? I mean 422HQ is pretty good and XQ freely available - how come ?
Are there any other hq-codecs available and installable - how does that work ?

The prores version in vdub2 is the libavcodec/ffmpeg version . It's not VFW.

[Richard1485]

I'd go with ProRes over DNxHD, which can cause problems with levels/gamma. It's a shame that Cineform gives you slow performance with Edius. Normally, I'd have picked that.

[shekh]

Hi,
maybe the issue with "Similar to Source: P216" was because the codec was selected before choosing "Similar to source"? This filtering of codecs does not remove the selected one even if it appears inappropriate.

[Hotte]

Thanks posiondeathray and Richard.

Tried cineform again with other settings - doesn`t help: Too bad: Horribly slow on the timeline. Btw. Cineform is either interleaved YUV oder RGB - right ?

X264 wouldn't play at all if settings are very HQ / all-Intra but that might need more testing in detail.

DNxHD (generated with ffmpeg) is by far the fastest on the timeline - of course, it is the native codec of Grassvalley. Cannot see levels / gamma issues at first sight, but I will watch out for that, also I will be doing more detail comparison with ProRes - thanks Richard.

My question to @poisondeathray: With ffmpeg you mean I should call ffmpeg from outside taking the avs-script as input and output to DNxHD - right ?
For some setup reason I`d prefer to continue using VDub2 as host. So the question is if there is a way to integrate ffmpeg-DNxHD into the compression list of VDub2 ?

[Hotte]

Hi,
maybe the issue with "Similar to Source: P216" was because the codec was selected before choosing "Similar to source"? This filtering of codecs does not remove the selected one even if it appears inappropriate.

Yes that could pretty much have been the case. It does not appear anymore if I do things right.

[poisondeathray]

My question to @poisondeathray: With ffmpeg you mean I should call ffmpeg from outside taking the avs-script as input and output to DNxHD - right ?
For some setup reason I`d prefer to continue using VDub2 as host. So the question is if there is a way to integrate ffmpeg-DNxHD into the compression list of VDub2 ?

Yes, ffmpeg directly, with avs input

It should be possible to implement DNxHD in avlib-1.vdplugin (I don't know how to write vdub plugin - it would have to be shekh or someone else)

[Hotte]

Yeah! ***** The DNxHD would be a great addition to the compression menu as it seems to play some not unimportant role in professional video exchange and looks like being an excellent codec, also encoding is fully supported by ffmpeg.

I'd be ready to support that in any way that makes sense. I`d be happy to hear Shekh`s evaluation of the matter. I have no idea if that is a lot of work to do.


What I haven't quite understood is how you guys work with lossless codecs that are not supported by our NLEs ? I mean its nice to have encoders like huffyuv, FV1,Daniel2(?), NotchLC(?)... But how do you use these ? VDub2 is a great host but a very basic editor - isn`t it ?

Could somebody try to explain that to me?

[poisondeathray]

What I haven't quite understood is how you guys work with lossless codecs that are not supported by our NLEs ? I mean its nice to have encoders like huffyuv, FV1,Daniel2(?), NotchLC(?)... But how do you use these ? VDub2 is a great host but a very basic editor - isn`t it ?

Could somebody try to explain that to me?

(Daniel2 and NotchLC are not "lossless")

It depends on which ones - what codec, what NLE host, and what versions of the NLE host. Each editor has little quirks, and sometimes certain point releases of each editor might change behaviour

Many "lossless" codecs, especially "YUV" lossless, are not lossless in some NLE's. Many get converted to RGB for example - Huffyuv is a prime example. I don't know of any professional NLE that treats huffyuv as lossless (some ffmpeg based ones do, such as shotcut)

eg. Edius has a YUV capable timeline (some editors do not, such as resolve, vegas) , but some formats are converted to RGB in Edius.

e.g Premiere has a YUV capable timeline too, but all "lossless YUV" codecs do not work as lossless - they get converted to RGB. The exception is x264 lossless in certain point releases
for certain pixel formats

Float RGB can technically be lossless for anything (including conversion to/from YUV), but only if the program handles it correctly everywhere. For example, Resolve uses float RGB internally, but it does not do the timeline RGB to YUV conversion correctly, so exported YUV assets lose precision. You have to use full float formats, such as EXR image sequences to maintain true lossless in/out

What you should do is perform some tests in the editor that you're using

[StainlessS]

Many "lossless" codecs, especially "YUV" lossless, are not lossless in some NLE's. Many get converted to RGB for example - Huffyuv is a prime example. I don't know of any professional NLE that treats huffyuv as lossless (some ffmpeg based ones do, such as shotcut)

I'm currently not able to use HuffYUV on W7, [tried install but not showing up in VD2/VDMod].
But cant you just select "Fast Recompress" and in HuFFYUV select "Convert To YUV", "Predict Median", [or I think also 2 other modes]
or something like that [for lossless].

[poisondeathray]

I'm currently not able to use HuffYUV on W7, [tried install but not showing up in VD2/VDMod].


Was it for x64 ? There is a procedure to install it, I can't recall the exact steps

I think something like this
https://forum.videohelp.com/threads/381944-unable-to-install-huffy-codec-on-windows-7-%5Bsolved%5D



But cant you just select "Fast Recompress" and in HuFFYUV select "Convert To YUV", "Predict Median", [or I think also 2 other modes]
or something like that [for lossless].

The problem is not the codec. It's not just huffyuv, it's all VFW based "lossless" codecs

eg. They work fine in ffmpeg, avisynth , or libavcodec/ffmpeg based programs like shotcut

The problem is how other programs treat UT Video, huffyuv, lagarith, magicyuv, etc... in YUV mode

[Hotte]

Thanks for all your contributions.
Just a short Question: DNxHR (which is the successor of DNxHD) is not supported by ffmpeg. If you buy that codec is there a way to use ffmpeg as host with it ?

[poisondeathray]

DNxHR (which is the successor of DNxHD) is not supported by ffmpeg. If you buy that codec is there a way to use ffmpeg as host with it ?

ffmpeg supports DNxHR, you have to set the profile


Encoder dnxhd [VC3/DNxHD]:
General capabilities: threads
Threading capabilities: frame and slice
Supported pixel formats: yuv422p yuv422p10le yuv444p10le gbrp10le
dnxhd AVOptions:
-nitris_compat <boolean> E..V....... encode with Avid Nitris compatibility (default false)
-ibias <int> E..V....... intra quant bias (from INT_MIN to INT_MAX) (default 0)
-profile <int> E..V....... (from 0 to 5) (default dnxhd)
dnxhd 0 E..V.......
dnxhr_444 5 E..V.......
dnxhr_hqx 4 E..V.......
dnxhr_hq 3 E..V.......
dnxhr_sq 2 E..V.......
dnxhr_lb 1 E..V.......


But there are some differences that differ from official Avid DNxHR vs. ffmpeg DNxHR - e.g. adaptive color transform is not implemented in ffmpeg version

[Hotte]

Yes, I found the post again where sbd explained how to apply HR modes to DNxHD to also achive the high resolutions.

I just tried this and out and compared the results to native Edius-X DNxHR exports:

ffmpeg -i F:\Temp\inputhqx.avi -c:v dnxhd -profile:v dnxhr_hqx -c:a pcm_s16le output.avi

Sorry to tell that the quality is not outstanding and noticeably less sharp than native HR or ProRes high quality. Although file sizes are all in the same range.

So probably less interesting to integrate as ffmpeg VDub2 Encoder...

[kolak]

Hmmm....
DNxHR is about as efficient as GV HQX if you manage to encode to around same file size. ProRes is maybe 1-2dB in PSNR better, but this is totally meaningless in real world.

If you doing such a test make sure source was not encoded earlier at all (I mean it doesn't come from eg. Alexa which was set to ProRes encoding). You will get so wrong results.
Use REAL uncompressed source or one which did not go through any DCT codec (if you testing DCT codec). Other solution is shifting image few pixels horizontally and vertically, so you break old block boundaries.

[kolak]

cineform
compatible but very bad timeline performance


Where?

Cineform is top choice for editing. In app which properly supports it (Premiere, Resolve, Scratch, Vegas if I'm correct) you have amazing performance and at any time you can increase it by miles just by swapping decoding to 1/2 (or further) resolution.

[Hotte]

Let's be precise: There is no real world difference between Prores HQ in the best setting and native DNxHR out of Edius.

But there is a clearly visble difference between native DNxHR exports (which I just realized are also significantly smaller) and DNxHD with DNxHR_HQX profile only.

It is difficult to describe: I would not say there is less resolution but contrast is lower like a very slight haze covering the scene and also some ringing in the original file at very large zoom levels become less obstrusive. I would instinctively push microcontrast a tiny bit which could cure it - don`t know really.

[kolak]

Sounds like issue unrelated to codec itself, but its implementation (or just preview?)
Edius use AVID libraries. Ffmpeg uses own DNxHR encoder, but I tested it some time ago (year or more) and it was actually slightly better than AVID (and better than DNxHD itself). Maybe ffmpeg people messed things.

You also have to be aware than DNxHR is slightly different than ProRes and both are very different than HQX or Cineform.
DNxHD/R are strict CBR codecs, so each frame is exactly same size (easy or difficult scene = sam bitrate), which has its good and bad sides. ProRes is VBR, but restricted VBR. It can go low with bitrate for very easy scenes, but it can peak only 10% above predefined target bitrate. HQX and Cineform are "very VBR" (specially Cineform). They are design to keep relatively same quality between frames, but this means some frames can be 2x bigger than others, so bitrate is very VBR.
Side note- Cineform was design more for high-end finish/film and film scanning. It behaves differently when you feed it with uncompressed (eg. film scan with all grain etc.) source compared to something already encoded (specially DCT encoded). FS3 mode was introduced specially for anime where Cineform tend to use "too low" bitrate (no noise, grain etc) which companies like Disney did not like. For "normal" footage FS3 is overkill- you getting quality improvements, but for the cost of relatively high bitrate raise.

In real world all of those codecs are good and there is not much difference between them.
HQX is only 10bit 4:2:2 (+alpha). ProRes is always YUV internally (for 4:4:4 12bit YUV+ losslessly compressed alpha). Cineform and DNxHR can be both 10bit 4:2:2 YUV and 12bit RGB+uncompressed alpha.

[Hotte]

Where?

Cineform is top choice for editing. In app which properly supports it (Premiere, Resolve, Scratch, Vegas if I'm correct) you have amazing performance and at any time you can increase it by miles just by swapping decoding to 1/2 (or further) resolution.

Horribly slow (1-2 Frames/s at 4K 10 bit) timline performance in Edius-X. But I am happy to learn.

So this is what I do:

- I do not have any raw video file but just a 4K 10bit 4.2.2 25bit mov out of a Panasonic G9
- I export this from Edius-X with Canopus HQX 10 bit. Normally this is perfect input for AVS+, but today I just load it into VDub2
- In VDub2 this becomes YUV422P16
- Select Cineform as compressor, 10 bit, YUV422, Fast Recompress: Negotiation Error
- Select Cineeform 16-bit, YUV422, Fast Recompress: Negotiation Error
- So what do you recommend to do next ? Normal / Decode Format - Which ?

[kolak]

Edius has no native support for Cineform. It all goes over VFW/directshow which is not the way to do it.
In Ends 7 Cineform was fine with performance. Edius X has new engine, so things must changed.
Cineform in Edius is also 8bit only.
You need a codec with native support, so in case of Edius: ProRes, DNxHR or HQX.

[kolak]

So this is what I do:

- In VDub2 this becomes YUV422P16
- Select Cineform as compressor, 10 bit, YUV422, Fast Recompress: Negotiation Error
- Select Cineeform 16-bit, YUV422, Fast Recompress: Negotiation Error
- So what do you recommend to do next ? Normal / Decode Format - Which ?

You get YUV422P16 because you import over ffmpeg source plugin. Then when you try exporting you use VFW system HQX codec, which only supports 8bit.

Try before you hit import using options button- this may let you force VFW HQX decoder not ffmpeg.
If not when you go to Compression and choose GV HQX then go to Pixel Formats and switch to YUY2. This should let you export to GV HQX. If not try also forcing Decode format to YUY2. You will loose 10bit precision.

Instead all of this use virtual AVI file system in AVS. Mount your AVS script as fake AVI and then import that AVI back to Edius. Not sure if AVS+ supports it but in vapoursynth you can mount final script result as v210 format, so this way you can preserve 10bit. Edius should be fine with 10bit (v210 ) AVI. If not use YUY2. No need for any intermediate files. You can use "AVS filters" directly in Edius.

[Hotte]

Thanks Kolak, you are incredibly qualified!

I start to love DNxHR. Its HQXmode is some 70% the size of Canopus HQX and the quality is really, really good.

My setup is:
- I export with Canopus HQX into AVS+ and do some 16-bit filtering
- I need to come back from AVS+ into Edius to do the final things
- I want to keep 10-bit and loose as little IQ as possible

So export Canopus HQX 10-bit is fine. It goes on very well with AVS+. The trouble is to come back. I'd love to go for Canopus HQX which is part of VDub2 but it is only 8-bit. Ouch!

ProRes422HQ could do. But has less timeline performance than DNx.
Is there a way for DNxHR ?
Or any other ?

EDIT: We`re overtaking each other with questions and hints - funny, sorry :) . I remebered to work with mounting some releases ago and I had a not so good experience. Everything became so horribly slow. But maybe I will come back to that later.

[kolak]

I left Edius forum long time ago. I think I recognise your name :P

Learn to use avisynth virtual file system as I said. Then no need to use any intermediate files and rendering.
You load source to avs , do your filtering and then present result as fake AVI file which you can load to Edius. If you don't do crazy processing in avs all should still work realtime. With avs+ all should work fine I think.

Other way. Instead of using VDub download ffmpeg and just convert your avs directly with ffmpeg back to desired codec. Can be DNxHR or ProRes.
Ffmpeg support avs script as source, so you convert it like any file: ffmpeg -i source.avs ......

[Hotte]

Thank you so much, Kolak.

[poisondeathray]

Let's be precise: There is no real world difference between Prores HQ in the best setting and native DNxHR out of Edius.

But there is a clearly visble difference between native DNxHR exports (which I just realized are also significantly smaller) and DNxHD with DNxHR_HQX profile only.

It is difficult to describe: I would not say there is less resolution but contrast is lower like a very slight haze covering the scene and also some ringing in the original file at very large zoom levels become less obstrusive. I would instinctively push microcontrast a tiny bit which could cure it - don`t know really.


To summarize - You're saying no problem with official DNxHR exports from Edius; the problem is with ffmpeg DNxHR encoding variant

"contrast is lower" , "haze covering the scene" sounds suspiciously like the dreaded gamma shifts of old.

Did you use MOV or MXF wrapper ?

[Hotte]

Did you use MOV or MXF wrapper ?

AVI. I will redo with MXF.

EDIT: MXF is rejected bei Edius (although it wraps DNxHR into MXF itselves ?!), MOV works.
Same effect. If i manipulate the gamma curve a tiny bit I am not getting closer to the original. I'd now guess that I am losing a whiff of microcontrast whereas resolution could be quite close. But we tend to perceive a loss of microcontrast as a loss of resolution. Yes it could be resolution also.

[poisondeathray]

- I do not have any raw video file but just a 4K 10bit 4.2.2 25bit mov out of a Panasonic G9
- I export this from Edius-X with Canopus HQX 10 bit. Normally this is perfect input for AVS+, but today I just load it into VDub2
- In VDub2 this becomes YUV422P16
- Select Cineform as compressor, 10 bit, YUV422, Fast Recompress: Negotiation Error
- Select Cineeform 16-bit, YUV422, Fast Recompress: Negotiation Error
- So what do you recommend to do next ? Normal / Decode Format - Which ?


For a native 10bit file (not stacked), Cineform in vdub2 requires normal or full recompress. It might be the same for stacked , not sure. I would avoid stacked all together if possible.

You can verify output with other tools, such as 10bit waveforms. ffmpeg has one, and avisynth does too now. If you test a 0-1023 gradient, you will see if there were problems somewhere , such as an 8bit intermediate step somewhere, which will manifest as gaps


One bizarre issue with some DCT based codecs like DNxHR/DNxHD and prores to a lesser extent is severe noise on some types of patterns like small checkers. It's not subsampling related (4:4:4 is affected too). Official Avid and ffmpeg implementations are affected. I've reproduced it on other patterns, other colors, other grid sizes. You can see some of the disussion here starting around post 672 . x264 (also dct based) , cineform (wavelet based) are unaffected
https://forum.doom9.org/showthread.php?p=1855173

[kolak]

I just done quick test and ffmpeg DNXHR is fine.
BM RAW 12K file converted to v210 in Resolve and this to DNxHR. ffmpeg one look as good (bit better) as Resolve direct encode to DNxHR. Direct ProRes encode is just slightly better (2dB in PSNR). HQX and Cineform are also very close. All codecs around 60dB PSNR (source is clean and god quality), so all looks fine.

Only issue is DNxHR encode out of Resolve which has strangely lower Y PSNR value. BM recently had some bug in DNxHR encoder, so looks like there may be still some left over.

[Hotte]

I just done quick test and ffmpeg DNXHR is fine. Only issue is DNxHR encode out of Resolve which has strangely lower Y PSNR value.

With Edius-X it is the other way round. Direct DNxHR export quality is excellent whilst filesizes are only 70% compared to the rest of the bunch whereas DNxHD reimport (compared in Edius) is sth Edius seems to be suspicious of...
CineForm needs larger filesizes to look almost like ProRes422HQ at highest quality level. So cineform appears to be very marginally weaker compared to ProRes.

Cineform needs normal recompress in VDub2 to convert from YUV422P16 to V210. Reimported into Edius-X it carries on having bad TL-performance of about 3 fps. It does not look like I lose the 10-bit with Cineform, I have a very fine sky gradient in my sample, but I will check that.
Thanks all!

[kolak]

Cineform is slightly less efficient than other codecs, but this is fine thanks its other features, like partial resolution decoding. Small bitrate raise to be "the same" is not a big deal.
GV HQX, DNxHR are similar if you match bitrate. ProRes is most efficient, but by margin (but also always).
Best feature of ProRes is fact that all tools which have an official encoder have it implemented well. Apple doesn't allow for bad implementations and this is easily visible when you work with many apps (performance is good, no level issues, alpha works etc.). with allotter codes it's not always true.

Your issue may be due to fact that you're encoding from HQX (bug may be in ffmpeg HQX decoder). Export v210 uncompressed and use this as a start.

[kolak]

It does not look like I lose the 10-bit with Cineform, I have a very fine sky gradient in my sample, but I will check that.
Thanks all!

If you import to Edius you will (unless GV added ability to read 10bit formats in VFW which I don't believe in). In order to prove it, looking is not enough as Edius preview surface is 8bit anyway, so you never will see proper 10bit data in its GUI preview.
Try applying very heavy curve and then real 10bit data and 8bit will show difference.

[Hotte]

Best feature of ProRes is fact that all tools which have an official encoder have it implemented well.


That sounds coherent. Edius does all sorts of ProRes exports.

Your issue may be due to fact that you're encoding from HQX (bug may be in ffmpeg HQX decoder). Export v210 uncompressed and use this as a start.

I tried that just for fun. 4K V210 uncompressed export is nothing less than crazy, not feasible with larger projects. No improvement, TL-perf is bad. I suspect Edius hates the cineform codec ;-)

[Hotte]

Try applying very heavy curve and then real 10bit data and 8bit will show difference.

Thanks. Will check that some day. But because off the timeline issue cineform is out of the race anyway.

[Hotte]

Edius preview surface is 8bit anyway, so you never will see proper 10bit data in its GUI preview.


Are you sure ? This is the workgroup version where you have the 8bit/10bit Preview option. Cant imagine that the 10bit is pure fake preview.

[Hotte]

One bizarre issue with some DCT based codecs like DNxHR/DNxHD and prores to a lesser extent is severe noise on some types of patterns like small checkers. It's not subsampling related (4:4:4 is affected too). Official Avid and ffmpeg implementations are affected. I've reproduced it on other patterns, other colors, other grid sizes. You can see some of the disussion here starting around post 672 . x264 (also dct based) , cineform (wavelet based) are unaffected
https://forum.doom9.org/showthread.php?p=1855173

I fear if I dive into this, no codec will be left for me. So I am probably doing better to keep my eyes a bit shut :cool:

[kolak]

That sounds coherent. Edius does all sorts of ProRes exports.



I tried that just for fun. 4K V210 uncompressed export is nothing less than crazy, not feasible with larger projects. No improvement, TL-perf is bad. I suspect Edius hates the cineform codec ;-)

I meant to encode DNxHR from it in ffmpeg.

[kolak]

Are you sure ? This is the workgroup version where you have the 8bit/10bit Preview option. Cant imagine that the 10bit is pure fake preview.


It's not really preview. It's switching whole engine to work in 8bit to gain performance.
In order to have 10bit preview you need some card- BM/AJA or GV one. GUI is always 8bit. 99% sure :)

[Hotte]

I meant to encode DNxHR from it in ffmpeg.

That sounded like a good idea.
Sorry to tell you, that there is practically no difference between an uncompressed V210 > DNxHD
and a Canopus HQX > DNxHD

Both where generated using ffmpeg and the fine Haze is in both. Strange - isn't it ?
It also shows how good Canopus HQX is. It is such a pity it is an 8-bit compressor outside!

[poisondeathray]

Are "fine haze" and "lower contrast" Edius specific problems ? Maybe the decoder, or some setting ?

Is there an actual problem with the file ? If you open the ffmpeg DNxHR in another application (e.g. mpv, ffplay, avisynth, or resolve) , how does it look ?


Did you explore proxy workflows ? In general, they can offer significantly faster timeline performance for complex, multiple layer projects. (Higher quality too, depending on how you set it up)

[kolak]

That sounded like a good idea.
Sorry to tell you, that there is practically no difference between an uncompressed V210 > DNxHD
and a Canopus HQX > DNxHD

Both where generated using ffmpeg and the fine Haze is in both. Strange - isn't it ?
It also shows how good Canopus HQX is. It is such a pity it is an 8-bit compressor outside!

What ffmpeg version is it?

[Hotte]

I have made the recommended outside comparison and I chose VDub2 as viewer (and frame TIFF exporter).
This are probably also some technical transients, there is codecs, tiff compression, website compression... I know.
But the relative findings I had all point into the same direction: COMPLETELY different insights.

Samples now! Unfortunately they are heavily jpeg'ed on imgur and rich in artifacts so will give you only an idea of what I am taking about. But you can pretty much trust on the evaluations below. If interested and sbd knows a better dowload source (no google or other sniffer please) where I can drop 8MB tiffs I`d be happy to upload them.

1. Out of camera MOV H.264 4K 10bit 4.2.2
https://imgur.com/LCWcIHe

2. Edius Export Canopus HQX superfine
https://imgur.com/cX8YC01

3. Edius Export V210 uncompressed
https://imgur.com/jK34YI9

4. Edius Export DNxHR HQX native MXF
https://imgur.com/fo16rfQ

5. ffmpeg Edius V210 uncompressed > DNxHD profile dnxhr_hqx
https://imgur.com/ZZs3ixW

6. ffmpeg Edius V210 uncompressed > ProRes HQ 4.2.2 10-bit Highest Quality
https://imgur.com/QfgHtYd

My findings after pic-on-pic comparisons with 1000% magnification:

Edius Canopus HQX
Edius HQX and V210 uncompressed are practically identical down to the extreme detail. No contrast, saturation or sharpness shifts. This is an excellent, neutral codec.

Edius Export DNxHR HQX native MXF
increases micro contrast (fakes more resolution) and overall contrast/saturation. Nice look for people who like it and are ready to accept e.g. more pronounced ringing artifacts (that were already there). Apart from that it preserves resolution very well.

ffmpeg DNxHD profile dnxhr_hqx
in this setup has to be compared to its source file uncompressed V210 or to Canopus HQX to see which codec does better. There is NO HAZE. Resolution is kept very well, about as well as HQX. Like its native brother it introduces a very small amount of additional microcontast but way less than Edius DNxHR - it's ok. What I do not like is the slight increase of overall contrast/saturation to about the same amount as Edius DNxHR although it appears less evident because of less push in microcontrast. Overall an excellent performer for a free codec if you play with levels to tame it. poisondeathray was right!

ffmpeg ProRes HQ
this is an excellent neutral codec, no shifts, no sharpness push, very good detail preservation (although Canopus HQX has an ever so tiny advance in this respect). But you have to push the VDub2 compressor quality slider to the very left to get there. This increases file size by some 10% compared to Canopus HQX. ffmpeg ProRes is relatively slow on an Edius-X timeline and buffer will run out in seconds with 4K 10bit full res. Its not as bad as Cineform in this respect, but also not great.

Bottom line: I was tricked by some Edius internal transients. Sorry for that.

But finally it was you to help me find my 10-bit codec: ffmpeg DNxHD. DNxHD would have well-deserved to be implemented in VDub2 but I will be able to work around it.

Kolak, poisondeathray and all the others: Thank you very much.

[poisondeathray]

There are some issues with the color in the presented screenshots - there are 601/709 mismatches. It's most easily visible on the grass

edius v210 and canopus hqx are similar in one group in terms of color;

original, v210 to (ffmpeg) dnxhr_hqx, and edius direct dnxhr_hqx are similar in the other group.

If you correct for the mismatch (one group to the other) they all become the similar in terms of color

For example, vdub uses 601 to convert from YUV to RGB for display, instead of 709 . If you used vdub for all of them, they should all be the same color. So there is something else going on with the procedure you've used that is not explained