It's an interesting idea.

Regarding the existing filters you mentioned, why don't they work with MadVR?

Everything looks fine with force film, which is what you should be using. The anomaly with T/D and MEGUI can be due to jumping around on the timeline, maybe MEGUI is doing some silliness with previews or something that causes Telecide() or Decimate() to see a frame history that is different from jus...

I don't like to speculate on things without the sample clip, so I will wait for that.

1. If it's 99% film, you should use Force Film mode rather than Telecide/Decimate. Assuming the flagging is accurate, that will not only solve your problem completely, but it will also be much faster. 2. I already use a windowed algorithm. Such small changes have always been a challenge for adaptive...

Something does seem to be amiss. Investigating...

Thank the guy that suggested it. I just coded it.

Anyway, glad you find it useful.

Serve the video with DGSource(debug=true) and play it in VirtualDub. It gives the frame type and number.

UncleBob wrote:Do you know if it's somehow possible to utilize nVidia card under guest OS under Win 2008 Hyper-V?

I don't know anything about that, sorry. I suppose you'll have to ask Nvidia support about it.

One thing to try is 258.96 driver as the newer ones have caused issues for some people.

I cannot duplicate that so I suppose you have a hardware or driver problem.

First, please use the correct forum in the future. I've moved this to the DGDecNV forum. Second, I need you to post a link to an unprocessed VOB sample that I can use to recreate the problem. You can use DGSplit to cut it. Upload it to mediafire.com and post the link here. Third state your graphics ...

Also state your video driver version.

Did you just cut the M2TS off the disk leaving the EOF completely intact, or did you demux or something? If it's a straight cut from the M2TS including the full EOF, then it's in the stream.

rack04 wrote:Thank you for investigating the problem. I guess I need to spend a little time figuring out whether the problem is in the source or perhaps anydvd or eac3to caused the problem.

Why bother about it?

It's a stream problem and so not a bug.

Be happy that you are missing only a single black frame at the end of the file.

Well, it's a big deal, because the crop usually comes before the resize, so if you want the resize done on the GPU, the crop must be done there too. I know you can calculate things backwards but it's more difficult and unintuitive. And the resize coming first unnecessarily acts on more pixels, thoug...

Yes, I'm aware of all those cases. But it's quite valid to say "I have progressively sampled video; there's no reason to deny me a mod 2 top crop". So my idea was to allow it, just as Avisynth does. A warning is always useful, just as in the Avisynth documentation. My basic position is that it's not...

Cr*p. I only tested DGIndexNV which simulates the GPU cropping, and it appears that the GPU cropping must be mod 4. I am confirming this with Nvidia, but if true, it means I have to back out the mod 2 change.

Thanks for alerting me to this.

It should become comparable to TS parsing.

I want nothing to do with VideoRedo. Don't ask me and don't tell me about it. I get slightly different results using DVIndexNV. Selecting the entire clip and using Output Trimmed TS results in an output file with EXACTLY the same size and the same problem. Exactly the same as what? Just describe the...

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. (...

The final GOP is: RPS 18880259063 I 18880259071 FRM 6 116 0 1 FRM 6 117 0 1 FRM 7 118 0 1 FRM 6 119 0 1 FRM 6 120 0 1 FRM 5 121 0 1 FRM 6 122 0 1 FRM 6 123 0 1 FRM 5 124 0 1 FRM 6 125 0 1 FRM 5 126 0 1 FRM 6 127 0 1 FRM 6 128 0 1 FRM 5 129 0 1 FRM 6 130 0 1 FRM 6 131 0 1 FRM 5 132 0 1 FRM 6 133 0 1 ...

DGDecNV will open your .mts files without any problem.

When I did the performance changes I did not do it for the MKV parser code. That still needs to be done. I'll move it up on the priority list.

That code from the MKV guys needs quite a bit of work to run fast.

Load the AVS script in VirtualDub and do File/information. How many frames are shown.

Post a link to the complete DGI file.

One might argue, then, that ... No, you can't argue that. I told you already that a file format up rev is guaranteed to mean that something will be wrong if you do not re-index to make a properly formatted DGI file that is compatible with the new software. I'm thinking in particular of my most rece...