Importing DNxHD to Avisynth

[Keiyakusha]

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 (levels adjusted but no resize applied), and can't figure out where you see the problem. Here is 10-frames 10bit DNxHD 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]

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]

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]

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]

Originally Posted by kolak

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.

Originally Posted by kolak

You look into compression and other "problems" to much- its simple bug, which you can clearly see.

The same file looks relatively the same 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]

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]

Originally Posted by kolak

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]

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/issue...an=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]

Originally Posted by kolak

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]

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.

[Keiyakusha]

Originally Posted by kolak

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]

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/a...A1340926008769

[Keiyakusha]

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]

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

[Keiyakusha]

Originally Posted by kolak

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]

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:



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

[Keiyakusha]

Originally Posted by kolak

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]

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]

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]

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.