Page 1 of 4

[RESOLVED] not able to feed the encoder

Posted: Sat Sep 09, 2017 9:53 am
by mparade
Hello there,

I would like to feed x265 encoder using DGDecNV via Vapoursynth.
The source is HDR10. My card is: Nvidia GTX 1060 6GB with latest driver package installed.
DGDecNV version is from 08.2017.
The error code I always got includes:
Script evaluation failed:
Python exception: name 'true' is not defined
Traceback (most recent call last):
  File "src\cython\vapoursynth.pyx", line 1821, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:36464)
  File "C:\TEMP\encodingTempSynthSkript_15_59_51_0810.vpy", line 7, in <module>
    clip = core.avs.DGSource("C:/TEMP/15_59_51_0810.dgi", fulldepth=true)
NameError: name 'true' is not defined
Can you help on this? Please let me know if you need some additional info to support.

Thank you very much.

Re: not able to feed the encoder

Posted: Sat Sep 09, 2017 11:21 am
by admin
Try True instead of true. If that doesn't work then you'll have to ask the Vapoursynth guys.

Re: not able to feed the encoder

Posted: Sat Sep 09, 2017 9:30 pm
by hydra3333
Hey mparade, when you find an answer could you post it here ?

Re: not able to feed the encoder

Posted: Sun Sep 10, 2017 3:50 am
by mparade
Still no success.

Using True instead of true I got an error message from the encoder:
x265 [error]: unable to open input file
Programmer said: "Guessing that 'True' wasn't the right way to go.
Seems like this isn't possible atm."

Sorry for asking it but before asking Vapoursynth can we exclude a bug in DGDecNV (I am using DGDecNV since 2011 without any problem)?

Thank you for your help!

Re: not able to feed the encoder

Posted: Sun Sep 10, 2017 6:08 am
by admin
True is the correct constant in Python. So that is not the issue.

There is no known bug in DGDecNV. fulldepth works fine with Avisynth+.

Ask the Vapoursynth guys about it.

Re: not able to feed the encoder

Posted: Sun Sep 10, 2017 11:43 am
by admin
I'm following your thread at another forum but I do not post there, so I give some information here.

This Avisynth+ script works fine when opening in VirtualDub 64:

loadplugin("d:\don\Programming\C++\dgdecnv\DGDecodeNV\x64\Release\dgdecodenv.dll")
dgsource("H:\Streams\HEVC\10 Bit\ES\Philips_Ultra-HD_Beach_Life_supershop-demo-3.dgi",fulldepth=true)
convertbits(8)

If you have an application that accepts 16 bit you can omit the convertbits call. Or you can change it to convertbits(10) if your application accepts 10 bit.

It looks to me like Vapoursynth simply does not support HDR from Avisynth source filters. Or maybe it doesn't support 16 bit and you need to convert it to 10. Ask the author about that.

Re: not able to feed the encoder

Posted: Mon Sep 11, 2017 12:10 pm
by admin
Any news, mparade?

Re: not able to feed the encoder

Posted: Tue Sep 12, 2017 4:06 pm
by mparade
It seems the guys at Vapoursynth cannot/don't want to solve this issue (got no usable reply yet).

Re: not able to feed the encoder

Posted: Tue Sep 12, 2017 5:31 pm
by Guest
Looks like they have no intention to solve the bug in Vapoursynth

Re: not able to feed the encoder

Posted: Tue Sep 12, 2017 7:57 pm
by admin
A couple points...

The Vapoursynth author could reproduce it with a different Avisynth source filter that delivers 16-bit (vi.pixel_type = VideoInfo::CS_YUV420P16). Or maybe even BlankClip() can generate that color space. That might be something for you to pursue, mparade.

DGDecodeNV(fulldepth=true) demonstrably works fine with Avisynth+.

Loading my Avisynth+ script into VirtualDub without the convertbits(8) call gives the expected error popup about an unsupported color space. VirtualDub does not crash. Conversely, stax76 reports that the Vapoursynth script crashes VirtualDub. Draw your own conclusions.

Marking resolved as no problem in DGDecodeNV has been established. But feel free to post again if there is pertinent new info.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 2:36 am
by jpsdr
And maybe if you use VirtualDubFilterMod, it may even work properly without the need of ConvertBits(8).

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 3:54 am
by admin
Thanks, I didn't know about VirtualDubFilterMod. I'll give it a try.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 10:52 am
by jpsdr
The DOOM9 thread about it is this one : https://forum.doom9.org/showthread.php?t=172021

Euh.... I don't understand why the url is not displayed properly in the post, it's correct when i edit... :?:

It seems that ??? concatened transform in ???

The thread is VirtualDub deep color modification

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 11:14 am
by admin
It triggered my banned words list. Sorry about that, it is what it is.

I did try VirtualDubFilterMod and it said I needed a VFW codec for fourcc P016. I sent Anton a PM on sourceforge asking about it. Obviously I cannot control what fourcc Avisynth+ delivers. Hopefully he'll respond with some useful information.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 11:34 am
by admin
OK, Anton needs to accept P010, P012, and P016 as synonyms for his supported fourccs. Or we need a way to force Avisynth+ to use his. Worst case we can fork VDFM but hopefully Anton will fix it up for us.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 12:24 pm
by admin
Great news, guys. Anton replied and sent me a test build. It works great with the Avisynth script returning P016. He will release it after some testing.

Now the question is what fourccs does x265.exe expect to see and which one is being passed by Vapoursynth? It's clear that DGDecodeNV itself is just fine.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 3:00 pm
by mparade
I can confirm your statement now. Using latest DGDecNV, HDR-10 source and Avisynth+ (came with Staxrip), the encoding just have started using 16 bit input and 10-bit output. Encoding speed is 35-40% faster than the software decoding was without my GPU's support.

So, if someone would like to use DGDecNV with Avisynth+, it will definitely work. Additionally, no ConvertBits(x) is required at the end of the script, because x265 can handle 16-bit input correctly.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 3:10 pm
by admin
Great to hear, mparade. Thanks for the update.

So all remaining issues are only with Vapoursynth? Or have you got that working as well?

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 4:02 pm
by mparade
Unfortunately, the standpoint of the author of Vapoursynth , that I know, is as follows:
"I already support all the avs+ formats. This is something else. I also have no intention of paying (I mean compulsory donation hahahahaha) to debug this. Or buying an nvidia graphics card for that matter.

Let the butthurt commence!"

I think it means it is very far from him to debug Vapoursynth.

Re: [RESOLVED] not able to feed the encoder

Posted: Wed Sep 13, 2017 7:01 pm
by admin
If you can reproduce it with a different source filter or even blankclip() with appropriate parameters maybe he would look at it, since DG stuff would be out of the picture.

BTW, I have always given free licenses to developers (and even to people who have difficulties to donate). I even have a few unused nVidia cards that I would be happy to donate.

Anyway, I see you have things going fine with Avisynth+, so that makes me happy.

Re: [RESOLVED] not able to feed the encoder

Posted: Sat Sep 16, 2017 3:46 am
by mparade
I have completed my first HDR encode using DGDecNV, but unfortunately I saw some artifacts during decoding the output:
http://www.mammutmail.com/hu/download/b ... 54b6fea0dd
I don't know yet if it is only a decoding problem now or if it is involved in the encode itself already due to some "problem" with decoding the original HDR content through DGDecNV.

It seems these artifacts are encoded into the output (the source material can be decoded without them).

Re: [RESOLVED] not able to feed the encoder

Posted: Sat Sep 16, 2017 12:55 pm
by admin
Those are strange artifacts.

Open your script for the source video directly in VirtualDubFilterMod and move to a place a little ahead of where the artifact occurs. Then play from there. Does the artifact show up? If so, it may be a CUVID issue, and you can please cut a sample around it for me.

Re: [RESOLVED] not able to feed the encoder

Posted: Sat Sep 16, 2017 2:15 pm
by mparade
The artifacts are the same in VdubFilterMod. I had to use ConvertBits(8) because otherwise the program displayed some error message.
But without ConvertBits(x) the results will be the same surely, because my 10bit encodes (16bit input, 10bit output in x265) has the same artifacts:

http://www.mammutmail.com/hu/download/c ... 3e06a78a02

Re: [RESOLVED] not able to feed the encoder

Posted: Sat Sep 16, 2017 3:55 pm
by admin
This is not the source stream. I need to see the original, not your re-encode.

Re: [RESOLVED] not able to feed the encoder

Posted: Sun Sep 17, 2017 9:52 am
by mparade
Please find as an attachement the original.

http://s1.toldacuccot.hu/letoltes?sid=7 ... ginal1.zip