decoder for dnxhr hqx 10 bit for avisynth+

[Andrew Placid]

Hi.
I have mov file with dnxhr hqx with 10 bit depth. Unfortunately ffms2 decoded correctly only 12 bit dnxhr hqx source. Is there any way to decode this file with avisynth+?

[FranceBB]

If FFMpesource2 failed, then try LWLibavVideoSource. http://avisynth.nl/index.php/LSMASHSource

[Andrew Placid]

If FFMpesource2 failed, then try LWLibavVideoSource. http://avisynth.nl/index.php/LSMASHSource

Thanks, but same result as ffms2. :(

[poisondeathray]

Did you specify the format parameter explicitly ? e.g format=""YUV422P10" or whatever matches your source. See the readme for the list of parameters

[dipje]

Does the latest ffmpeg even recognize the file ? If not you can give up. If so, latest ffms2 (2.23.1 ?) should work OK.

Is the bitstream the same between dnxhd and dnxhr? If so you could try changing the codec header (vtag) or remixing through ffmpeg with specifying a vtag .

I know dnxhd 10bit works fine, both in 422 and 444 / RGB. Dnxhr is a maybe.

[mp3dom]

DNXHD is just fine (it's also quite "standard") but DNXHR is not. Got the same result some months ago with both ffms2 (2.23.1) and LSMASH.
I think the bitstream is different because you see lot of pixelisation of different size and other kind of artifact.
If you're in hurry you can try to convert to a more classical DNXHD using the Avid DNXHD codecs and inside QuickTime Pro. Something quite "dirty" but better than nothing.

[Andrew Placid]

Did you specify the format parameter explicitly ? e.g format=""YUV422P10" or whatever matches your source. See the readme for the list of parameters

Yes, I try all parameters.

I think the bitstream is different because you see lot of pixelisation of different size and other kind of artifact.
If you're in hurry you can try to convert to a more classical DNXHD using the Avid DNXHD codecs and inside QuickTime Pro. Something quite "dirty" but better than nothing.

Yes, bug colors and strange pixelate.
It's regrettable. I would like to encode directly from source. :(

[richardpl]

Could you share short sample, I'm interested in fixing this issue.

[Andrew Placid]

Could you share short sample, I'm interested in fixing this issue.

https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c

[richardpl]

How you created such file?
Is there something that can play this correctly?

[kolak]

It's DNxHR HQX UHD. It's HQX profile and it's not properly supported by ffmpeg, even latest build.
File works fine in Switch player and AME.

[poisondeathray]

If you have quicktime installed with the free avid codecs you can use qtinput() in avisynth; however it will become 8bit 422

[Andrew Placid]

How you created such file?
Is there something that can play this correctly?

Yes, Davinci Resolve shows this video correctly. The issue in 10 bit, as I know dnxhr hqx usually have 12 bit and ffms2 may decode correctly only 12 bit, but not 10 bit.

If you have quicktime installed with the free avid codecs you can use qtinput() in avisynth; however it will become 8bit 422

Yes, but I need 10 bit output. :(

[richardpl]

I posted patch on mailing list to fix this issue. Hopefully it will be applied to FFmpeg master git branch soon.

[Andrew Placid]

I posted patch on mailing list to fix this issue. Hopefully it will be applied to FFmpeg master git branch soon.
Thank you. We'll be waiting.

[kolak]

It has been already approved, but you would need to compile new ffms2 against latest ffmpeg code.

Patch fixes decoding of this sample and others which use to not work (e.g. ones from AME).

[kolak]

I posted patch on mailing list to fix this issue. Hopefully it will be applied to FFmpeg master git branch soon.

Just a quick question- do you know if there are any plans for HQX and 444 encoding profiles?

[richardpl]

Just a quick question- do you know if there are any plans for HQX and 444 encoding profiles?

There is no any internal FFmpeg plan. Officially there is just trac to report bugs and feature requests.

[kolak]

So whoever feels like adding it or if some company sponsors it:)

[Andrew Placid]

It has been already approved, but you would need to compile new ffms2 against latest ffmpeg code.

Patch fixes decoding of this sample and others which use to not work (e.g. ones from AME).
I cheked last ffmpeg. Yes, it fixed this issue. Waiting for ffms2 compile.

[dipje]

btw, just as cineform rgb... the whole 10bit / 12bit can be a bit misleading. Most often these codecs are just 10bit internally. 12bit is then output only or it only comes into play with alpha or something like that.

Prores 4444 is also listed as 12bit sometimes while it really is 10bit, same as Cineform RGB(A).


Just guessing here btw, as I know dnxhd more than dnxhr.

[kolak]

Hmm...Cineform should be able to do real 12bit internally.
When it comes to ProRes this is bit grey area. Apple says it also can be 12bit, but no one has seen such a sample. ProRes alpha channel is either 8 or 16bit and losslessly encoded.
DNxHR can be also 12bit.

Some encoders simply don't use all codec possibilities. For example Adobe Media Encoder encodes DNxHR 444 and HQX at 10bit, where Resolve at 12bit.

[richardpl]

Can anyone of you be so kind and share short 4:2:0 DNxHR sample?

[kolak]

There is no such a thing as far as I know. All DNxHR are at leas 4:2:2.

[kolak]

btw, just as cineform rgb... the whole 10bit / 12bit can be a bit misleading. Most often these codecs are just 10bit internally. 12bit is then output only or it only comes into play with alpha or something like that.

Prores 4444 is also listed as 12bit sometimes while it really is 10bit, same as Cineform RGB(A).


Just guessing here btw, as I know dnxhd more than dnxhr.

I've checked ProResXQ and I don't know what ffmpeg decoder does to it, but output is definitely not the same as from other tools. Looks like ProREsXQ is 12bit not 10bit.
Create some gradient, encode to ProResXQ with Resolve or AE.
Load back to AE and apply heavy YUV curves (more than 1). Decode same ProResXQ with ffmpeg to e.g. 16bit TIFF and compare in AE to original ProRes or TIFF decoded with other tool, eg. Resolve. You will see that ffmpeg output it showing banding much quicker. Something is not right with ffmpeg decoded ProRes XQ or 4444.

[dipje]

Creating a gradient that is subtle enough that it changes in values of ¹ in 12bit space should be easy enough. AE works with a Max of 32767 , so if you make a few grey scale blocks with steps of 8 in the colors it should be a good check . If it truncates to 10bit some of the color patches should disappear , or dithering should appear. (AE dithering is crude and ugly it should be easy to spot ).

I can't do the test since I don't have an official prores encoder .

I always believed that if someone encoder at 12bit, but our fffmpeg decoders interpret it as 10bit _and it works_, it must be 10bit internally. Of course there can be headers to present the output as 12bit, but internally it looses some precision.. where the marketing speak of 12bit comes from is not something that concerns me.

But on the other hand the whole world talking about 12bit makese think it can't possibly be sneakily 10bit only.

And the test is easy enough to do.

[kolak]

Well, I see clear difference between ProResHQ, ProResXQ and also DNxHR 10bit and DNXHR 12bit out of Resolve.
Both ProResXQ and DNxHR 12bit give very similar results, where others also give very similar results, but different (way more banding). DNxHR definitely has 12bit mode and ProResXQ looks at least as good when it comes to preserving gradient. Decode same ProRes over ffmpeg to 16bit TIFF and it looks way different (more like ProResHQ, so 10bit).

Maybe they internally doing some processing (like storing as LOG data etc), but it works.

[dipje]

Like I said, just use a colorpicker to see what values you get in the encoded file. Should be easy to see if you get 12bit precision out of it.
I kinda expect 12bit to be 12bit.. but I can't explain why fffmpeg (or other decoders ) can decode it with 10bit tables no problem.

I can only do the test with dnxhr since there are no official prores encoders for me to use. I'm kinda getting curious now :).

[dipje]

Oh btw, this is a copy and paste from the Miraizon prores FAQ:
ProRes, all video components are stored with a fixed depth of 10 bits, regardless of what you send in. If you send in 8 bit data, the codec will upsample it to 10 bits before encoding. Likewise, despite Apple's marketing documents, if you send in 12 bit data it must be downsampled to 10 bits before encoding.
So there are very confusion signals for both sides to the story.
Maybe the improvement in antibanding you see is just the bitrate increase ? Prores 4444 is a bit starved for bitrate , the reason why prores xq was defined in the first place.

Let's be clear on my stance, I'm very open to what happens to be true any way .. but I want to see some real proof for one of the two sides :)

[kolak]

I've done test with bars in AE. Starting with 16bit TIFF with gradients at 1024/1032/1040

DNxHR 12bit resolves 12bit (there is some levels shift, but precision seams to be kept).
Cineform 12bit RGB mode resolves 12bit (perfect levels result in AE).
JPEG2000- AME 12bit RGB mode- same as Cineform- perfect levels.
ProRes 444 and XQ- 12bit is sort of kept. 1024 and 1032 levels are flatten (maybe edges of the 12bit steps). Looks like there is also some other crap going on.
Here is how bars look like from ProRes (boosted for better visibility):

https://s15.postimg.org/jqpxbd5rv/Screen_Shot_2017-04-30_at_13.38.35.png

In the same time decoding same ProRes XQ file with ffmpeg flattens all bars, so it looks like ffmpeg does "convert" to 10bit, or in other words behaves differently than official ProRes decoder.

Any 10bit codec (ProResHQ, DNxHR, Cineform in 10bit mode etc) = flat bars.

Weirdest thing is that Cineform decoded with ffmpeg (saying gbrp12le (10bpc)) to 16bit TIFF is still ok- perfect levels. Don't get this at all. Does this have anything to do with wavelet nature of Cineform?

[dipje]

I've done some testing as well, creating a few bars with steps of '8' in AE. Then in AE I render them to MagicYUV 12bit RGB and MagicYUV 10bit RGB so confirm what will happen when truncating to 10bit.
This is what the source looks like with a heavy (legacy)contrast on it to enhance the differences:
https://snag.gy/C0Wnc9.jpg
And yes, 12bit MagicYUV looks _exactly_ the same (like expected).

This is what 10bit MagicYUV looks like:
https://snag.gy/1Xzhk4.jpg

So what's what we're looking for.
Now, like I said, I can only test with DNXHR cause that's the only encoder I have available to test that will do 12bit officially. I only have ffmpeg and the miraizon v2 codecs to test prores and those don't even claim 12bit so useless in this test.
I rendered the AE project with the bars to DPX 16bit (and re-imported them in AE to check if they are indeed the same, to prevent level-changes later on).

Imported the DPX sequence into Resolve 14 public beta (and set the clip to full-range) and I export the result to DNXHR 444 12bit, DNXHR 444 10bit and DNXHD 1080p 8bit.
Now try to follow me. To make sure Resolve is doing what it is claiming, I import those 3 DNXxx clips back into Resolve and export them as 16bit DPX to test in After Effects (bypassing the AE DNXHD/DNXHR decoder). I say 3 clips, but I only did this with the 12bit and 10bit one.

So after a few round trips, the resulting files back into After Effects (boosted with contrast) look like this for 12 bit:
https://snag.gy/qzeOHv.jpg and this for 10bit: https://snag.gy/ql4bN6.jpg

The 12bit results looks perfect.. so.. proofing that at least DnxHR 12bit 444 in Resolve 14 is actually 12bit. Our original '10bit example' file resulted in two colors (one bar) visible. This 10bit output test is showing 3 colors (two bars) and a difference in levels. So another way of rounding values somewhere I guess + levels difference (which maybe my fault, who knows)

Now, lets' throw to DNX files directly into After Effects to see what the AE built-in decoder (not the Avid codecs!!) makes of them.
The original 12bit DnxHR file already proven to actually contain 12bit data:

https://snag.gy/FnpZL3.jpg
What? No bars at all, a single color??? So it decodes the 12bits to 8bits?? This is the .MXF file directly from Resolve. There is also a pretty hefty levels difference in there..

I also did the test in Resolve by writing dnxhr 12bit 444 to a Quicktime file instead of a .MXF file. That Quicktime file in AE looks like this:
https://snag.gy/mIaxOy.jpg

Well that seems to contain more bitdepth but is just kinda broken. The stripe artifacts (throughout the whole picture! Not just the bars!) that kolak had. I make the conclusion that 12bit DNXHR 444 files should just not be used in AE with the built-in decoders. Be it Quicktime or MXF, none is what you expect. The 12bit Quicktime file is labeled as '10bit' btw, so it's somewhat expected for things to go wrong then.

Then we move over to the 10bit DNXHR 444 file as MXF in AE:
https://snag.gy/l9I3Ew.jpg
There is bitdepth in there, 2 colors (one bar) like the original 10bit example, but there is a levels difference somewhere. The 10bit file in Quicktime shows 3 colors (2 bars) again + a levels difference:
https://snag.gy/sFEH57.jpg

It seems this is extreme tricky to get right? Or just don't expect to do roundtrips between two programs and expect consistency?
Resolve is in beta of course, so we must give it some slack, but I don't trust AE to be correct either :).

The 8bit DNXHD file n MXF from Resolve directly in AE gives what you expect, no bars at all (or a single color), but yes, a levels difference.

Ok, so how does opensource (ffmpeg of course) do with this.
The DNXHR 444 12bit files from Resolve I convert to a 16bit dpx sequence by doing this:
ffmpeg -i inputfile -c:v dpx -vf zscale=rin=full:r=full:min=709:m=709:d=none,format=pix_fmts=rgb48 -y outputfolder\%04d.dpx
I use zimg / zscale, and I tell it to not do any dithering but to be honest, zscale is only used for subsampling / matrix / levels conversion and I think pixel-format changes in ffmpeg this way are still done by the old swscale converter. The zscale filter in front helps me by setting the correct flags so that swscale interprets it how I want though. I tell it to go from full range to full range and from 709 to 709, basically a no-op but setting correct flags for the next filter in line. I have no clue if this really is supposed to work.. or works, but anyway.
The DPX files in AE look this _after_ I reduced the contrast-boost I have been using all the time:
https://snag.gy/t02kce.jpg
There is something like the bars still in there, so some bitdepth is actually decoded (And ffmpeg reports the file correctly as yuv444p12 btw) (I kinda expect codecs to claim 'rgb' to actually use YUV-full-range these days). But the levels / brightness is clearly wrong. The color-values I get in AE do seem to go in jumps of around '8 to 9', making me think it's actually the decoder creating this, not some ffmpeg error. But you never know.

I tested the .MXF file the same way (and with zscale to be sure) but it gave the exact same output as the 12bit Quicktime file.
I got better results by removing the 'r=full' part (but _do_ specifying the 'rin=full' part), so'll get this:
ffmpeg -i inputfile -c:v dpx -vf zscale=rin=full:min=709:m=709:d=none,format=pix_fmts=rgb48 -y outputfolder\%04d.dpx
You can even let the 'min=709:m=709' part out, doesn't seem to do anything. This got me way closer, you clearly see the bars of the 12bits of bitdepth, but there is a slight level difference in there. A slight one. Maybe I have the gamma transfer characteristics wrong or something?

The same results with the 10bit file btw. The bitdepth seems alright but levels change.


So a long story in this is that Resolve 14 DNXHR 444 12bit -is- really 12bit (like I said, can't test for prores here, no Mac) but I didn't manage to decode the file correctly in AE or ffmpeg without some kind of levels shift or gamma shift.

I've done similar tests like this with going from Vapoursynth RGB48 mounted as virtual b64a .AVI into AE, there encoded as MagicYUV 10bit RGB back into Vapoursynth back into virtual avi etc.. I tested with 10bit values though, but even though you upscale to RGB30 to RGB48 in Vapoursynth and then back to RGB30 in AE, all was preserved nicely and I got (sort of) lossless roundtripping that way.
Never tested it with Cineform or DNX-family but I'm kinda suspicious now :).

Let's be clear, we're nitpicking here. Normally I check for levels-differences by just toggling an layer on/off and looking for differences zoomed in. But small differences like in my (and kolak's) screenshots can have quite an effect when grading later on and input luts and stuff, and the bitdepth is getting more important in the HDR10 and Dolby HDR age...

DNXHR 12bit is at least not lying, but omg you gotta be careful when mixing software suites :).

[kolak]

DNxHR definitely has real 12bit mode.
Cineform also seams to work fine.
ProRes444/XQ- hmmm, definitely there is way more than 10bit there, but these strange patterns are worrying. ffmpeg decoder will make them only 10bit for sure- this is "strange" part.

What version of AE are you using?
You need latest for native DNxHR support. You may also need to edit Adobe xml codecs rule file to make sure DNxHR is imported over 16bit depth. Based on your grab I can tell that your AE imported DNxHR at 8bit.
What does it say when you import DNxHR- Million of Colors or Trillion?
AE is actually not that bad at all in been "correct" for many codecs.

[dipje]

Latest 2017.something.
Exporting from ae and back into ae is also fine. Importing 10bit from resolve is fine( if you watch the levels / ranges ). But importing 12bit seems to fail.

Editing the XML file is of no use since that's only for the QuickTime subsystem, and the dnxhd/dnxhr is all native. And yes, all is reported trillions.

Ae native decoder just chokes on the 12bit files from resolve , and calls them 10bit so I expect weirdness.

A 12bit file being decoded with a decoder that only assumes 10bit SHOULD produce artifacts :).

That is what worries me about prores in the past. People saying their 12bit files were decoded as 10bit but looking just fine. That signals 'internal 10bit prores file ' to me.

So your prores 12bit files looking a bit weird when decoded by ffmpeg as 10bit IS GOOD NEWS. it means it decoded the file wrong which is exactly what should happen if there is something else than 10bits inside of it :). It's the first real world proof I see that there .ight be real 12bit inside of those files .

Or.. ffmpeg decoded the 12bit, dithers it and presents it as yuv444p10. But that seems like a lot of trouble instead of just presenting it as yuv444p12 and letting the world deal with it .

Maybe post your 12bit sample file to an 'issues ' repository somewhere so that the ffmpeg devs have something to work with ?

[kolak]

I already asked this question some time ago.
Answer was that if files are 12bit they should produce bad output, which is not the case.
This is puzzling me. Same with Cineform which even if says in ffmpeg 10bpc provides perfect levels back in AE.

[dipje]

While these days it is outputted as gbr12p. Like you I'm puzzled about the 10bpc after it in braces.

Now someone get me a prores windows encoder that can do 12bit in the speclist :).

[kolak]

ArriRAW converter should do it for free.
http://www.arri.com/camera/alexa/tools/arriraw_converter/
As far as I understand it does ProRes on PC.

You just have to start with ARRI RAW footage.
Grab from here:
http://www.arri.com/camera/alexa/learn/alexa_sample_footage/