Feel free to use --preset ultrafast for the 2nd pass, and see it fly along. However, be prepared for reduced quality. The point is that the 1st pass doesn't need to put much effort into motion search, RD stuff, and whatnotelse. Basically, it's only there to figure out where to put I-, P- and B-frame...

Oh my. Samples usually shouldnt't be 1 GigaByte in size. One or two hundred frames would've been plenty enough ... The flicker does have some of the mentioned "rolling shutter" characteristics. Maybe that's why VD deflick doesn't work very well. I'm not used anymore to use VirtualDub filters, since ...

Tiny details that might be of interest: - did you crosscheck that the error does not occur when using another soure filter If it's really specific to DGDecodeNV, (and also if not), then ... - the script as a whole - kind of source video - Avisynth version: 32 or 64 bit, MT version or official, ... -...

Perhaps it wasn't quite clear ... my comment wasn't targeting you, but only Nvidia. I perfectly understand them to allow only mod4, in order to avoid potential problems. And after all, this is an Avisynth filter. A script has to be made anyway, and writing a crop() command manually is not a big deal...

There is a good reason for this mod4 restriction - think about e.g. interlaced mpeg2 :evil: This restriction can be loosened in several cases (horizontal-only cropping, progressive content, ...), but not universally . So, the easiest way to prevent the user from doing silly things is to impose a gen...

Oh, this report reminds me of .... when I did the stacked comparison of DGSource(deinterlace=2) with other bobbers, the GPU-bobbed stream was off by one frame compaired to all other filters which were fed by DGDecode_mpeg2source. Not sure anymore if it was one frame early or late, but off it was. (E...

I started writing a somewhat longish explanation about the what's and how's and why's of how AVC and deblocking is working ... but I lost mood. (But saved it ... if you insist by all means, I can show it) Short report from the practical side: I can't reproduce. Please show a source segment where DGD...

Still, shouldn't it be considered to add some sort of deblocking to DGDecodeNV ? In particular for Mpeg-2 sources. Fact is, the white bearded man DGDecode can do quantiser-adaptive deblocking on mpeg-1/2, but the young guy DGDecodeNV can do not. One could argue this is a regression.

The deblocking is performed. As you noted (with slight misspelling), H.264 is doing "in-loop deblocking". That means that deblocking is not done "after the fact" like you do when e.g. playing back Xvid videos. In H.264, the deblocking is an essential "inner" process of both encoding and decoding. If...

No additional bucks are gained. The idea is this: Step 1: - Have "Adapter#1" active -> get machine ID -> generate license ID (#1) Step 2: - Have "Adapter#2" active -> get machine ID -> generate license ID (#2) Step 3: - Put both license IDs into one file license.txt, like so: 0123456789abcdef0123456...

A hybrid version of MVTools+CUDA doesn't sound very promising to me. If you look at e.g. MDegrain2, you'll find the whole thing spends like 65% of its time on SuperClip+VectorSearch, 25% on the (block overlapped) compensation while the denoiser fetches pixels, and only 10% time on the actual denoisi...

OH COOL!!! I hope your first one will be a denoiser. Avisynth script denoisers can be painfully slow (like mc_spuds, MCTemporalDenoise, etc...). Those are highly sophisticated denoising scripts, making very big effort to come to an optimal result. An important part of the big effort is active motio...