Importing DNxHD to Avisynth [Archive]

kolak

7th May 2012, 21:47

There use to be a bug in ffmpeg and DNxHD 10bit decoding in ffmpeg, so I assume there is one in ffmpegsource. I thought it was fixed, but recently saw it in latest LAV filters, so I assume it's still in ffmpeg itself. Problem appears in high contrast areas and can be missed. If you want just detect black frames than it's not an issue in your case, but for decoding itself it can be.
Use QT input instead.

Keiyakusha

17th June 2012, 02:23

I just used mentioned FFMS2 and opened my 10bit DNxHD correctly. Did some tests to verify it and all was alright. You just need to make sure that DNxHD encoder doesn't set to scale levels and remember that it uses bt709 colorimetry but avisynth (and some other opensource stuff) works in bt601, so you will see wrong colors if you open script lets say in VirtualDub... Don't know about LAVfilters.

Back to business, opening DNxHD is not that hard, but how to do it while keeping it 10bit? As stacked or interleaved clip. Is there any ways? Anyone brave enough to compile fresh hacked FFMS2 to do it?

cretindesalpes

17th June 2012, 05:46

Keiyakusha

17th June 2012, 08:10

SAPikachu built a few FFMS2 versions (http://www.sapikachu.net/近期ep作品汇总/) with stack16 output, although they are sporadically updated. Just add enable10bithack=true to the FFVideoSource parameters. It works wonders on AVC sources, but I don't know for other codecs.

Thanks! I wonder how i missed that...
I just tested FFMS2 r656 on v210 stream in .mov container (Because I have something to compare it to. DNxHD is not lossless so its hard to compare it to something, but it behaves similar.)

So here is FFMS2 input (http://hcd-1.imgbox.com/aavE9nB7.png), and here is readv210 (http://hcd-1.imgbox.com/aapzuz6U.png) of the same source.
Result is similar, which indicates that it works, but as you can see there is some difference. This is because v210 (same as DNxHD) have 4:2:2 chroma subsampling, but FFMS2 opens clips only as YV12.
On my screenshot ConvertToYV12() was used after readv210 input to make them even (maybe not the best idea).
I tried to add "colorspace=yuy2" switch to FFVideosource, but then it opens video without 10bit hack.
Should I configure something else or that's how it works right now? If latter, this is certainly step forward but unfortunately still not enough.
And this is how opened as YV12 DNxHD (http://i.imgbox.com/aap3tVGM.png) looks (110 mbps). And 4:4:4 profile for some reason kills libswscale ^__^

SAPikachu

27th June 2012, 14:17

Just built a new FFMS that supports 4:2:2 and 4:4:4 videos, you can download it at: http://nmm.me/kx

I tested this version using a DNxHD sample (http://static.clipcanvas.com/sample/clipcanvas_14348_Avid_DNxHD.mov) posted on this page (http://www.clipcanvas.com/a/video-clip-downloads/). Seems it works correctly, the LSB part come out without problem. AvsP incorrectly reports the clip as YV12, subtitle("IsYV16: " + string(IsYV16)) shows the clip is actually YV16.

Hope this helps. :)

kolak

27th June 2012, 14:24

Does it mean that we can import DNxHD at 10bit and dither to 8bit inside avisynth?

Please note: there is a bug in DNxHD 10bit decoder, which shows up on high contrast areas as a sort of halo/ringing. It has been reported long time ago to ffmbc developer and it's fixed there, but eg latest LAV filter still introduce this problem, so I'm not sure if it was ever fixed with ffmpeg.

SAPikachu

27th June 2012, 14:35

Yes, that's possible, and we can keep full 4:2:2 colorspace now.

I'm not sure whether the bug has been fixed either, maybe you can check change log of libav to see it.

kolak

27th June 2012, 14:39

I'm bit busy, but will check on some sample and report.

Keiyakusha

27th June 2012, 15:12

Just built a new FFMS that supports 4:2:2 and 4:4:4 videos, you can download it at: http://nmm.me/kx
...

Hope this helps. :)
Just tried and it works!
I try to use free alternative to professional software where possible. This is huge help, thanks! (^o^)

kolak

27th June 2012, 15:19

Can you post your import script please, so I can quickly check if decoding is fine.
Please include whole script with dithering. Just looked at some source, which clearly shows problem in LAV filter.

Keiyakusha

27th June 2012, 15:23

What do you mean by import script? You don't need anything except ffms2 call to open file...

Edit:
Ffvideosource("Comp 1.mov",enable10bithack=true)
f3kdb_dither()

is this what you want?

can it be that ffmbc developer fixed it but didn't sent fix upstream to ffmpeg? If so, he really should.

kolak

27th June 2012, 16:10

Yes- problem is there, so whoever is using it be careful!

Artefacts on high contrast areas, eg white text on black background. It creates sort of halo, contouring- something like mosquito noise on eg. mpeg2 encodes.

It's definitely fixed in ffmbc.

http://i48.tinypic.com/4qekn.jpg

http://i48.tinypic.com/24uzymv.jpg

I resized and applied levels filter to make it more obvious.

kolak

27th June 2012, 16:27

Yes, that's possible, and we can keep full 4:2:2 colorspace now.

I'm not sure whether the bug has been fixed either, maybe you can check change log of libav to see it.

As far as I understand it will work for ProRes also- yes?

SAPikachu

28th June 2012, 00:58

As far as I understand it will work for ProRes also- yes?

Yes, it should support most formats that libav supports, seems libav can decode ProRes but I haven't tested it.

By the way, is there any patch for the bug? I can check whether it can be applied to current version.

kolak

28th June 2012, 12:11

Tried 10bit ProRes and all seams to be fine:) Sometimes decoding is bit unstable during seeking, but during convert seams to be ok. Overall speed is also good- 2x faster than RT on my i7 990x on 24p HD source.

DNxHD 10bit decoding is fixed in ffmbc, so I assume it can be ported to ffmpeg.

SAPikachu

28th June 2012, 14:47

Just downloaded source code of ffmbc to have a quick check, their DNxHD decoder diverged from the one of official libav/ffmpeg, and they didn't provide any code history. So it's very hard to extract a patch from it and I don't have time to do that. Maybe someone can ask them for the related patch?

kolak

28th June 2012, 16:29

http://code.google.com/p/ffmbc/

Guy is responsive so you can ask him.

Keiyakusha

28th June 2012, 17:00

I asked but no response so far. Well it was only few hours ago so too early to say something.

Keiyakusha

28th June 2012, 19:14

Developer said he is not aware of any bugs with DNxHD. It was caused by something else but he doesn't remember himself.

On the other hand I did some tests myself (http://i.imgbox.com/aamGlTXi.png) (levels adjusted but no resize applied), and can't figure out where you see the problem. Here is 10-frames 10bit DNxHD (http://www.mediafire.com/?xxm3588k3di6yei) file that i just created. What you can see around the letters on my screenshot i believe is just compression artifacts. DNxHD is not lossless codec and artifacts near edges are to be expected. If I load this .mov file back to After Effects and rise levels (exposure in comp window at +22 stops shows things nicely) - i see the same artifacts. (16 or 32bit composition must be used or extra bits will be discarded).

kolak

28th June 2012, 21:05

Well- it was me, who reported it to ffmbc developer and he approved it (means confirmed that there is problem) and fixed it. My grabs are from ffmbc and Ffvideosource and it obvious that there is a problem. Same problem is in LAV decoder. Are you sure that your file is 10bit- how did you create it? 8bit decoding is fine.
These are not encoding artefacts on my grabs- as you can see 1st one is clean and this is correct one. Same result comes from DNxHD QT decoder and AE. It always shows on high contrats areas. Maybe it has to do with 709/RGB levels- way how DNxHD was encoded- don't know. I've seen this problem on every DNxHD source which I had and always use ffmbc if needed- not ffmpeg.

Keiyakusha

28th June 2012, 21:22

About 10bit, if your composition is set to be anything more than 8 bits, anything you create from scratch will obviously be 16 or more bits. Exception is some effects that do not support above 8 bits but each of them marked with an icon that shows what it capable of and you will be notified about this in effect controls. You can also see that values of the color are way above white or you can just look at LSB part to see that there really is something. In fact, most of the artefacts comes from extra bits values.

Your screenshot doesn't reminds me compression artefact, it does looks like something wrong. What I say is that I can't duplicate it. How you produced your test source? Also which settings of DNxHD should I select to get as clean video as yours? My file is 110mbps profile that machetes source which is 720p 29.97 10bit

EDIT: i just repeated test cause noticed that in previous the color I selected wasn't exactly pure white. but results was the same. I see same kind of artefacts. I selected 220mbps profile which is I believe highest possible quality setting but still cant get as clean video as yours. Maybe in your clean example extra bits was discarded since most of the artefacts are located in extra bits and if you discard them but not dither - you will see a lot less of them (if at all). Or maybe some post processing was applied?

kolak

28th June 2012, 22:08

Create a proper 10bit DNxHD file- use After Effects for this and make sure you choose Trillion of Colors and proper 10bit mode in QT settings.
If you don't see a problem than, I think, your file is 8bit. Not sure why you can't get such a clean file. My sample was a proper 10bit file, zoomed in 4x and 1st, properly decoded image shows good quality and no problems. DNxHD comes from AVID.
You look into compression and other "problems" to much- its simple bug, which you can clearly see. I've seen this problem long time ago and it's still present in ffmpeg, where in ffmbc it was fixed (after my report). There is no magic- if ffmpeg would be fine than there would be no difference compared to ffmbc. ffmbc is exactly the same as DNxHD QT decoder.

Keiyakusha

28th June 2012, 22:12

Create a proper 10bit DNxHD file- use After Effects for this and make sure you choose Trillion of Colors and proper 10bit mode in QT settings.
I did selected this all the time before. Sorry I forgot to mention it.

You look into compression and other "problems" to much- its simple bug, which you can clearly see.
The same file looks relatively the same (http://i.imgbox.com/aanImKab.png) in after effects and in virtual dub using ffms2. "Relatively" because dithering by f3kdb does some changes. I can't see any bugs.

EDIT:
My idea is - on your example these are artefacts too they just looks bigger compared to letters because your letters actually really small you just upscaled it a lot and mine are created big in 720p project. Artefacts have very weak luma values so with wrong TV-PC conversion may be gone. For example by default DNxHD files created with PC levels so if opened in VirtualDub lets say - artefacts will be clipped because it always does TV-PC conversion if input is YUV. My files created with TV levels so after conversin to RGB-PC levels I still can see artefacts.
Also this matches with response of the developer. maybe there was problem but it wasn't related to decoding but to recognition/conversion of the levels.
This also explains why I can't create so clean file as yours, because in your example artefacts probably was clipped.

kolak

28th June 2012, 23:10

Yes- it's small font- something like size 14.

Try different setting in QT- 709 and RGB- maybe only one mode is affected. Also try red text on black background- as far as I remember this was visible a lot.

Keiyakusha

28th June 2012, 23:14

Try different setting in QT- 709 and RGB- maybe only one mode is affected. Also try red text on black background- as far as I remember this was visible a lot.

This mode affects levels. The name of these options is a big misleading. I'm not going to explain the process also I can make a lot of mistakes but if short: 709 applies TV->PC conversion and RGB passes your video to encoder "as is". Something like that.

kolak

28th June 2012, 23:24

Yes, but even so maybe the way how DNxHD is encoded is the issue, so my smaples shows problem and yours don't. Mine are rather encoded with 709 mode.

It was fixed by ffmbc developer:

http://code.google.com/p/ffmbc/issues/detail?id=60&can=1&q=problem

There is a link to some sample there- try it. I did and problem is there- big outline around some color bars edges.

Keiyakusha

28th June 2012, 23:29

Yes, but even so maybe the way how DNxHD is encoded is the issue, so my smaples shows problem and yours don't. Mine are rather encoded with 709 mode.

I see. But if they really do, they need special treatment to be opened via our beloved opensource tools. I was having problems with this before until figured that out. You can prepare color bars in after effects and encode using both modes. Encode them even in 8 bit and open through avisynth in virtual dub. The one encoded as 709 will be wrong. You need to add some filter before. I dont remember but I guess I solved this with colormatrix plugin.

EDIT: Judging from what he says he fixed issue that can't affect video in a way as shown at your images... I will find sample and try it later

kolak

28th June 2012, 23:40

Keiyakusha

29th June 2012, 00:14

Sorry- bars borders may be bit changed due to chroma sampling, but this is irrelevant to ffmpeg decoding problem. It's something totally different and ONLY FFMPEG is affected.
Try sample from link above and compare to QT or ffmbc decoding.

I'm not sure what to tell you about this colorbars sample. Especially related to the initial issue...
The same sample opened differently through QT and FFMS2 because of 2 reasons: levels and colorimetry
I already tired with this DNxHD stuff so as I said i can make some stupid mistakes but as I understand that sample is Fullrange AND uses bt709 colorimetry. Both are not something avisynth works with by default and can lead to crushed blacks/whites AND wrong colors. By Opening it like that i got same result:
ffvideosource("dnxhd10bit.mov",enable10bithack=true)
f3kdb_dither()
converttoyv12() #note that converttoyv12() was only needed because ColorMatrix probably doesn't supports yv16 colorspace.
ColorMatrix(mode="Rec.709->Rec.601") #this is because avisynth works with 601 not 709 colorimetry
converttorgb32(matrix="PC.601") #this is because we need conversion without modifying levels and VDub scales any YUV input

This script was opened in VirtualDub. As I said, from this sample I cant figure out anything related to initial issue that you mentioned. Not sure if this is really should be done like that, and that is optimal but it works.
Maybe the last converttorgb is not needed. But that would mean that the video is TV levels and Quicktime is the one who doesn't do scaling. My only goal was to match outputs.

kolak

29th June 2012, 00:27

This is how this issue shows up on color bars.

It does not open differently in any way, except ffmpeg. It opens properly in AE, QT player, decoded through ffmbc to v210 etc. It's just ffmpeg which has problem.
It may be not related not directly to DNxHD decoder itself, but to some internal ffmpeg conversion between colorspaces.

Your scrpit makes no sense for me and also does not fix anything- it actually introduces even more problems. Problematic outlines are still there.

Here are grabs of properly decoded bars and ffmpeg ones:

http://ffmbc.googlecode.com/issues/attachment?aid=600012000&name=test.zip&token=osu8ZlXL9nDLeZDA-jyNGsEpZPM%3A1340926008769

Keiyakusha

29th June 2012, 00:37

With this script:
ffvideosource("dnxhd10bit.mov",enable10bithack=true)
f3kdb_dither()
converttoyv12() #note that converttoyv12()
ColorMatrix(mode="Rec.709->Rec.601")
I get the same result as decoded bars from that issue. as I expected converttorgb is not needed this probably was my mistake so lets just forget it.
All opensource tools assume rec601 colorimetry. that file is bt709. You need to correct that if you want to preview result in correct colors.
EDIT: ^most tools, not all. not ffmbs!

kolak

29th June 2012, 00:39

In other words- decode this sample to v210 with ffmpeg and ffmbc- they should be identical, but they are not!

Keiyakusha

29th June 2012, 00:40

In other words- decode this sample to v210 with ffmpeg and ffmbc- they should be identical, but they are not!
This is true. This is totally expected.

kolak

29th June 2012, 00:46

Why?
Sorry, but I'm lost with your logic.
Create bars as v210 encode to DNxHD than decode to v210- it should look almost identical and it will in case of ffmbc, but ffmpeg will introduce some artefacts and these are not encoding artefacts, because ffmbc won't introduce them :)

Why every other method except ffmpeg gives the same and proper results? It's only ffmpeg (not even talking about ffms2, but simple ffmpeg decoding to v210) is different? For me this makes no sense+ ffmbc use to do the same, but has been fixed now. I just call it bug in ffmpeg, you can call it other way :)
At the end output from ffmpeg is not as it should be- and this what counts.
You can also do the same with ProRes and it will be fine with ffms2, as ProRes decoding in ffmpeg works fine :)

This is what I'm talking about- strange ghosting lines, which are not encoding artefacts or other problems as they appear only on ffmpeg decoding:

http://i47.tinypic.com/1z1v7ds.jpg

Not really visible on this jpeg (web hosting encoded bmp to jpeg), but you can check it on full quality.

Keiyakusha

29th June 2012, 01:00

Why?
Because ffmpeg assumes one colorimetry and one range and processed file may have another. It will use wrong way of conversion unless you configure it properly. FFMBC on the other hand not so conservative as ffmpeg and modified its behavior. I'm not 100% sure since I'm not using either of CLI's on daily basis but this is how I understand it. We're going too far with that I think. I'm not the one who should explain why these tools works this way and not another.
The only thing I can tell is that with my personally created files I have no issues when open them with FFMS2 10bit hack.
Regarding your files: 1st have crushed levels, the one below - not (you crushed them by hand on top of that so we can't tell that just by looking on these images). That's why you see crystal clear image top and artefacts bottom. How that happenned and why, I don't know. This may be bug in ffmpeg, or rather bad "feature" or in ffmbc, or somewhere else. But personally I don't care if I can configure it to give results that I expect.

kolak

29th June 2012, 01:04

Makes sense, but this is bug or at least something what could be improved as it has been done in ffmbc.
You have no way to make it working fine with ffms2 and you never know what sort of DNxHD file are you getting from other people- it should always work as it happens in case of other decoders. My files comes from AVID which is source of probably 80% of DNxHD files passed between people and these are not working fine, so it's not good.
I hope it will be improved :)

Keiyakusha

29th June 2012, 01:27

I was able to see the picture you posted only now. I won't deny that there may be problem with "ghost" lines but even if there is, It is not related to the Issue you was talking on 1st page of this thread.
I just rechecked things. Yes there seems to be some bug with chroma and this appears to be the same bug as ffmbc developer fixed. But this needs separate investigation and we probably need to contact ffmbc developer again, cause last time I really asked him for patch to something he didn't touched. Also most of this thread until post #36 can be ignored. Only image in this post shows real problem.

kolak

29th June 2012, 10:32

All problems reported by me are related to this problem- as I said- this is just the way how it shows up on bars. On real footage it's hard to see, but if you look close you will find that there is some issue mainly on high contrast areas. Text problem is caused by exactly the same issue and this is what ffmbc developer has fixed- after his fix ALL problems which I saw are gone (problems on bars, problem on text and other high contrast areas).

I told you that you were looking into some "other problems" to much, where issue is clear and obvious.

Keiyakusha

29th June 2012, 14:07

Your screenshots at post #14 show nothing near related to the actual problem that sample with colorbars shows. They only show that you was having problems with levels clipping
You say Artefacts on high contrast areas and show 2 screenshots one with artefacts and one without. But absence artefacts on one screen and presence on another explained by clipping on 1st screen and just encoding artefacts on another. The real problem only can be seen in colorbars sample and it behaves way differently than these artefacts. Its not my fault that i was looking into wrong things, I was looking at what you was showing to me.

kolak

29th June 2012, 15:24

Fro me it's all related to same bug in ffmpeg (even if this is more than one problem inside ffmpeg) and I hope it will be fixed.

Keiyakusha

29th June 2012, 15:32

Screens at post #14 cant be related. I proved it 2 times. You only see disappearing of the weak encoding artefacts when deal with levels in a wrong way. If you can post sample from which these screens was taken I believe I can prove the same with your sample, not the one created by myself. This is too obvious now. DNxHD not lossless it always creates atrefacts even with highest possible settings. Image can't look as clean as on your 1st image if handled properly. But if you clip the levels - sure this is can be reproduced.
Colorbars sample shows totally different issue. It is reproduseable very easily and can be seen even regardless of possible levels issue due to different nature of the bug. Problem is only one - ghost lines as shown in color bars. It only can be seen in colored video, its not possible to reproduce bug with black and white material. No wonder, cause bug comes from issues with chroma.

kolak

29th June 2012, 15:57

Here is some sample so you can play with it (comes from the same file as text samples)

http://www.sendspace.com/file/v86w3w

Look at the artefacts around text.

Keiyakusha

29th June 2012, 16:02

Here is some sample so you can play with it (comes from the same file as text samples)

http://www.sendspace.com/file/v86w3w

Look at the artefacts around text.
This is not the same thing you taken screens from so I can't show you where you was wrong using this one. Sample does shows problem but again its not the same as at screens in post #14. The problem comes from chroma, even if the chroma have weak color values. Screes at post #14 are black and white and cant show real problem. All confusion if because for some reason it looks similar to you.

The conclusion: bug exists, and can be easily duplicated with colored video. It can be seen best on colorbars video but on the last posted sample too. Video doesnt even have to be real 10bit just encoded as 10bit DNxHD tdo see this issue. However post #14 can't and doesn't show the problem. It may be looks similar but nothing more than mistake with levels. Second screenshot shows correct output, first, the clean one - not correct, none of these two illustrates bug. If you will highlight these artefacts on 2nd screen in better way you will see that they are actually not even lines but blocks - macroblocks, compression artefacts. If you still don't believe - I give up.

kolak

29th June 2012, 16:33

Keiyakusha

29th June 2012, 16:37

I never said what is/causes the problem as I don't know. FFmpeg output is wrong this what I know and I tried to warn other people to be careful. Fro me it's all the same problem and it=ffmpeg decoding- that's it. Output from other decoders is fine- simple as this.

Then why you posy screenshots at all? If you post examples means you know where exactly problem is. But turned yout you post some unrelated screenshots. Would be way better if you would linked to that thread at google code to begin with. But anyway I'\m happy that we know that problem is there, now we need to solve it somehow. Thanks for notifying.

kolak

2nd July 2012, 00:23

SAPikachu

2nd July 2012, 01:42

I have problems to load 90min feature ProRes files using ffms2. Simple import sript+f3kbd_dither makes Vdub freeze on loading- nothing happens. It works fine on shorter samples- any hint?

When vdub freezes, is your hard drive operating? FFMS needs to scan the whole before it open the file first time, it may be because of this, just wait until your HD stops.

If it freezes after your HD stops, then it may be some compatibility issues of libav/ffms. Not much we can do, if possible try splitting the file into small parts and load them separately in your script.