Page 2 of 4
Re: [RESOLVED] not able to feed the encoder
Posted: Thu Oct 05, 2017 8:09 pm
by admin
Three blind mice!
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 06, 2017 2:15 am
by jpsdr
Another thing not helping, it's that the button was withint the facebook and twitter advertisings.
Most of the time, on pages of hosted files, all the big download buttons like this in the middle of advertisings download a lot of things/crap, but never the file you're looking for...
Most of the time you have to look for a little text like this "File is
here" lost in all the big download crap advertisings.
So, my brain automaticaly masked/rejected this big button...
Until after a search and not found, my brain decided to make me noticed it, and i realised putting the mouse over it (without clicking !) that the link was indeed the file !
By default, on this kind of pages, i never trust big "download" buttons.
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 06, 2017 5:50 am
by Guest
By default, on this kind of pages, i never trust big "download" buttons
I did a test download and played it, it seems clean
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 06, 2017 9:54 am
by admin
It's not so much a matter of trusting the downloaded file as it is of trusting that the download button will actually deliver that file rather than some unwanted application. As jp pointed out, very often we see big prominent download buttons that deliver unasked-for things while a small hard-to-find button or link gives the file you are really after. OK, it's a business model that allows us to have free downloads. We just have to be careful.
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 06, 2017 11:24 am
by Guest
Yeah, I get that, but on my browser if I pause the cursor on the link it will display the url of the "download".
This helps with the I click or not decision
Same as the email client and links
But I do understand, the internet isn't so friendly anymore, and one has to take care with which websites they visit or links they click.
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 06, 2017 12:24 pm
by admin
Thanks for the link, Luis!
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 13, 2017 3:18 pm
by admin
Good news, girls and boys!
I just updated to Nvidia driver version 387.92 and, lo-and-behold, the HEVC 10-bit decoding glitch issue appears to have been fixed. All of my test streams that showed the issue now run clean.
Thank you, nVidia.
@mparade
Your further testing would be helpful and appreciated. Chow!
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 13, 2017 4:22 pm
by Guest
Just did a quick test and it appears OK.
OT
My next system will require 2 video cards, I just did an encode with DGDecodeNV frame serving a 10 bit 4K HEVC video and NVEnc encoding on one video card and It did it at 2X playback speed (50 fps)
I might get 100 fps with two cards to split the work
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 13, 2017 4:32 pm
by admin
Thank you for your confirmation, Luis. It feels really good to now have a fully functioning GPU-accelerated solution for UHD. Maybe I'll re-install Vapoursynth and try to figure out why it won't accept P016 from Avisynth+.
Regarding your dual GPU idea, how do you intend to pull that off? It seems to me you would have to break the stream into two and process them with multiple instantiations. Of course DGDecNV can't currently support any kind of transparent multiple-GPU parallelism. Maybe it should.
Re: [RESOLVED] not able to feed the encoder
Posted: Fri Oct 13, 2017 5:08 pm
by Guest
Well sir...
It would be reasonably easy
Your source filter ( and filters ) allow me to assign a video card to use ( int device or default first found)
NVEnc allows the same
DGSourceNV on first card... NVEnc on second card
Frame serving and preprocessing card 1/2
Encoding card 2/1
I will wait to see if the 20xx cards will have B frames to help with compressibility
Also want to see if AMDs Threadripper comes up with a 24 core CPU
Oy Vey, this is going to get expensive.... but you only live once and its only money, gotta have some fun along the way, and this is one of the ways.
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 9:43 am
by admin
gonca wrote: ↑Fri Oct 13, 2017 5:08 pm
DGSourceNV on first card... NVEnc on second card
Ah, so simple.
I think to maximize things you need a mobo with two PCIEx16 slots and lots of PCI lanes.
but you only live once and its only money, gotta have some fun along the way, and this is one of the ways.
Ditto that!
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 10:07 am
by Guest
Ah, so simple
Simple minds, simple solutions.
I think to maximize things you need a mobo with two PCIEx16 slots and lots of PCI lanes
An AMD Ryzen or Threadripper compatible mobo will carry enough PCIEx16 slots and the CPU will support the required lanes
Intel might require an extreme edition CPU with the extra cost
Either way, the key is the NVidia cards and the VPU chip in them
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 4:44 pm
by admin
i7-8700K + X370 mobo is begging to be my next beast, although it might be worth giving AMD a look, or skipping a generation.
https://www.tweaktown.com/news/59247/in ... index.html
Core i7-8700K: 6C/12T @ 3.7GHz base/4.7GHz boost, 95W TDP.
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 5:12 pm
by Guest
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 5:15 pm
by admin
The link I gave asserts 40 lanes. Still, I suppose, 64 is better.
Re: [RESOLVED] not able to feed the encoder
Posted: Sat Oct 14, 2017 5:27 pm
by Guest
Re: [RESOLVED] not able to feed the encoder
Posted: Mon Oct 16, 2017 3:34 pm
by admin
Back to feeding Vapoursynth with DGSource(fulldepth=True)
I've found out why Vapoursynth doesn't like CS_YUV420P16 returned by DGSource(fulldepth=True). Following is the code in avisynth_compat.cpp. It's pretty obvious that Vapoursynth simply does not accept CS_YUV420P16 from Avisynth+. It should be easy to add support.
Code: Select all
static void VS_CC avisynthFilterInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core, const VSAPI *vsapi) {
WrappedClip *clip = (WrappedClip *) * instanceData;
if (!clip->preFetchClips.empty())
clip->fakeEnv->uglyNode = clip->preFetchClips.front();
const VideoInfo &viAvs = clip->clip->GetVideoInfo();
::VSVideoInfo vi;
vi.height = viAvs.height;
vi.width = viAvs.width;
vi.numFrames = viAvs.num_frames;
vi.fpsNum = viAvs.fps_numerator;
vi.fpsDen = viAvs.fps_denominator;
vs_normalizeRational(&vi.fpsNum, &vi.fpsDen);
if (viAvs.IsYV12())
vi.format = vsapi->getFormatPreset(pfYUV420P8, core);
else if (viAvs.IsYV24())
vi.format = vsapi->getFormatPreset(pfYUV444P8, core);
else if (viAvs.IsYV16())
vi.format = vsapi->getFormatPreset(pfYUV422P8, core);
else if (viAvs.IsYV411())
vi.format = vsapi->getFormatPreset(pfYUV411P8, core);
else if (viAvs.IsColorSpace(VideoInfo::CS_YUV9))
vi.format = vsapi->getFormatPreset(pfYUV410P8, core);
else if (viAvs.IsY8())
vi.format = vsapi->getFormatPreset(pfGray8, core);
else if (viAvs.IsYUY2())
vi.format = vsapi->getFormatPreset(pfCompatYUY2, core);
else if (viAvs.IsRGB32())
vi.format = vsapi->getFormatPreset(pfCompatBGR32, core);
else
vsapi->setError(out, "Avisynth Compat: Only YV12, YUY2 and RGB32 supported");
vi.flags = 0;
vsapi->setVideoInfo(&vi, 1, node);
}
It seems we just have to add two lines to the if-else:
Code: Select all
else if (viAvs.IsColorSpace(VideoInfo::CS_YUV420P16))
vi.format = vsapi->getFormatPreset(pfYUV420P16, core);
That will at least get Vapoursynth to accept the colorspace. Whether it then will correctly take the 16-bit data from Avisynth+ remains to be seen, although it seems like a pretty good bet that it will be OK.
Interestingly, the vs_normalizeRational() call is a bit surprising, considering how not so long ago Myrsloik refused to do that and insisted all filters must do it themselves.
Re: [RESOLVED] not able to feed the encoder
Posted: Mon Oct 16, 2017 5:46 pm
by Guest
Not a Vapoursynth user but I tried.
Posted in Myros' thread
Wonder how bad He'll abuse me
Boy, you are patient
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 8:08 am
by admin
Seems we have to make a Vapoursynth fork. Does anyone have a Windows build environment set up?
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 3:20 pm
by Guest
With your help and patience I can try to set one up
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 4:14 pm
by admin
Thanks, Luis, but I have already started setting it up on my machine.
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 4:19 pm
by Guest
If there is anything I can do to help let me know
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 4:22 pm
by admin
Will do.
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 5:34 pm
by admin
That was easier than I hoped.
You only have to rebuild the AvsCompat project and then use the AvsCompat.dll to replace the one in the Vapoursynth install directory. With two minor changes (one already given above) I have this script opening and displaying just fine in VirtualDubFilterMod (delivers P016 to VDFM):
import vapoursynth as vs
core = vs.get_core()
core.avs.LoadPlugin(path="D:/Don/Programming/C++/DGDecNV/DGDecodeNV/x64/Release/DGDecodeNV.dll")
video = core.avs.DGSource('d:/tmp/vapoursynth/beach10bit.dgi',fulldepth=True)
video.set_output()
I'll just do a bit more testing and then I will release the patched DLL (with source changes).
Re: [RESOLVED] not able to feed the encoder
Posted: Tue Oct 17, 2017 6:02 pm
by Guest
That was quick