Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
7th April 2021, 19:46 | #21 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Code:
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....... |
|
7th April 2021, 20:47 | #22 | Link |
Registered User
Join Date: Oct 2014
Posts: 209
|
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: Code:
ffmpeg -i F:\Temp\inputhqx.avi -c:v dnxhd -profile:v dnxhr_hqx -c:a pcm_s16le output.avi So probably less interesting to integrate as ffmpeg VDub2 Encoder... |
7th April 2021, 21:01 | #23 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. Last edited by kolak; 7th April 2021 at 21:14. |
7th April 2021, 21:09 | #24 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. Last edited by kolak; 7th April 2021 at 21:13. |
7th April 2021, 21:18 | #25 | Link |
Registered User
Join Date: Oct 2014
Posts: 209
|
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. |
7th April 2021, 21:21 | #26 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. Last edited by kolak; 7th April 2021 at 23:34. |
7th April 2021, 21:36 | #27 | Link | |
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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 ? |
|
7th April 2021, 21:41 | #28 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. |
7th April 2021, 21:47 | #29 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
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. Last edited by kolak; 7th April 2021 at 21:51. |
|
7th April 2021, 21:52 | #30 | Link |
Registered User
Join Date: Oct 2014
Posts: 209
|
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. Last edited by Hotte; 7th April 2021 at 21:59. |
7th April 2021, 22:02 | #31 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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 ...... Last edited by kolak; 7th April 2021 at 22:04. |
7th April 2021, 22:18 | #33 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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 ? |
|
7th April 2021, 22:45 | #34 | Link |
Registered User
Join Date: Oct 2014
Posts: 209
|
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. Last edited by Hotte; 7th April 2021 at 23:09. |
7th April 2021, 23:07 | #35 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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 Last edited by poisondeathray; 7th April 2021 at 23:16. |
|
7th April 2021, 23:26 | #36 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. |
7th April 2021, 23:45 | #37 | Link | |
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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! Last edited by Hotte; 7th April 2021 at 23:49. |
|
7th April 2021, 23:52 | #38 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. Last edited by kolak; 7th April 2021 at 23:58. |
8th April 2021, 00:02 | #39 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
Try applying very heavy curve and then real 10bit data and 8bit will show difference. |
|
8th April 2021, 00:09 | #40 | Link | |
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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 ;-) |
|
|
|