Support forum for DG Tools

I have a bluray m2ts I've frameserved with DGDecNV. When I transcode using x264 there is a small glitch in the encoded video.

I've then performed the next tests/tryouts:

1) Serving the dgi through an avs script loaded in virtualdub - seems clean and dandy at the problematic spot.
2) 2nd encode using the exact same dgi -
3) 3rd encode using a fresh dgi - glitch at the exact same spot.
4) 4th encode using ffdshow as directshow source instead of dgi - no glitch .
5) 5th encode - moved the m2ts to a difference HDD and made a new dgi - glitch in the same spot.
6) Chopped a 60 seconds m2ts file off the source (the bit that contains the glitch). encoded it (using dgi) ...no glitch. Was hoping to recreate it on a short clip which I can then submit for checking.

All the above ofc serving dgi through an avs script:

dgsource("video.dgi")
Spline36resize(1280,720)

using DGDecNV 2040 and nvidia vp5 card.

any ideas ?

What kind of glitch? Screenshot? One frame or a bunch of frames?

You'll need to give me a stream that I can use to duplicate the issue. You say just opening the script in VirtualDub causes no issue. Therefore, we need to look at your encoding process. Maybe it is making some nonlinear requests that confuse my random access. I don't think it's likely but you never know.

Can you specify your system, OS, encoding parameters, etc.?

It's a 3 frames glitch. here's a screenshot http://imageshack.us/photo/my-images/846/glitch3.jpg/

As I mentioned I tried to replicate the issue by cutting a 60 seconds clip from the approx time the glitch happens. Encoding just those 60 seconds resulted in no glitches. I'm not sure how giving you that clip will help and obviously I can't
upload 12gb of m2ts for you to try it on the full video file. Unless you think you can figure it out from a clip that doesn't replicate the glitch. I used TSMuxer's cut & split option to make the clip. perheps the output isn't 100% 1:1 identical
to the original source? I don't really know.

operating system is win7 pro. encoding parms are standard 2-pass x264:

x264.exe --pass 1 --level 4.1 --stats movie.stats --bitrate 5566 --preset slow --keyint 240 --min-keyint 24 -o NUL movie.avs
x264.exe --pass 2 --level 4.1 --stats movie.stats --bitrate 5566 --preset slow --keyint 240 --min-keyint 24 -o movie.mkv movie.avs

sandy_geser wrote:I used TSMuxer's cut & split option to make the clip. perheps the output isn't 100% 1:1 identical
to the original source? I don't really know.

Please try DGSplit.

just tried with DGSplit. an encoded m2ts clip containing the problematic spot results in no glitches. it seems to happen only when I encode the full video.

I've just tried the same source on a 2nd pc with vp4 card. Same results....Even tried with v2039 to see if that makes a difference and it's the same. I also found a similiar glitch on a different encoded video I did using a dgi project.
I see v2041 is out guess I can give that a whirl too.

update: same with v2041. Tried it with the DIAVC tool. no glitch at that spot.

Please specify the BluRay so I can buy it to try to reproduce your issue. A link to where to purchase it would be great.

http://www.amazon.com/Camelot-Complete- ... 525&sr=1-2

Disc 2, 00103.m2ts at 40m46s

hi, any news?

hi admin, any progress on this issue? you said you'll try and get the disc and try and recreate the issue. Sadly I've stopped using the excellent app since discovering this issue on 2 different transcodes and would really like to start using it again if this issue can be fixed. thanks

I'd not blame DG if he balked at buying a relatively expensive TV "set" as you've reported here. Maybe you have another example you can provide?

@sandy_geser

Indeed. Can you point me to a single bluray, preferably in English?

What happens if you use Big Buck Bunny as input? Something public domain like that would be ideal, because we could ask a bunch of users to try it. Then maybe we could identify the critical factor.

I used VP4 on a 460 for a long time and never saw anything like this.

Exactly what cards were they that you saw these problems with? It's speculated that this is limited to the 2xx series. Have you tried it on (say) a 460?

I have thousands of users and have reports of this from about 3 people. To me, that suggests system issues. It sucks to be one of the 3, and it sort of puts the onus on you to help me try to replicate it.

sandy_geser wrote:I have a bluray m2ts I've frameserved with DGDecNV. When I transcode using x264 there is a small glitch in the encoded video.

I've then performed the next tests/tryouts:

1) Serving the dgi through an avs script loaded in virtualdub - seems clean and dandy at the problematic spot.

As this works, i suggest you to first save your file with VDub using a lossless codec (UT Video, Lagarith), and then, using this file as input for x264.

neuron2 wrote:@sandy_geser

Indeed. Can you point me to a single bluray, preferably in English?

What happens if you use Big Buck Bunny as input? Something public domain like that would be ideal, because we could ask a bunch of users to try it. Then maybe we could identify the critical factor.

I used VP4 on a 460 for a long time and never saw anything like this.

Exactly what cards were they that you saw these problems with? In the Doom9 thread, it's speculated that this is limited to the 2xx series. Have you tried it on (say) a 460?

I have thousands of users and have reports of this from about 3 people. To me, that suggests system issues. It sucks to be one of the 3, and it sort of puts the onus on you to help me try to replicate it.

I was hoping being this is a fairly recent title it can be rented to save costs. I'm not sure what Big Buck Bunny is. I'm not suggesting every single encode ends up with such glitches, I don't always have time to sit down and watch every back up encode.
the initial encode was done on a GT 520 card and I also tried it on a vp4 4xx series card. I don't remember the exact model right now but I can check it out later if it's important. think it was 460.
Another title I noticed such a glitch on after transcoding is Count of Monte Cristo from 2002. I'll have to get back to you with the exact timecodes etc if that's something you think you can get your hands on more easily.

jpsdr wrote:

sandy_geser wrote:I have a bluray m2ts I've frameserved with DGDecNV. When I transcode using x264 there is a small glitch in the encoded video.

I've then performed the next tests/tryouts:

1) Serving the dgi through an avs script loaded in virtualdub - seems clean and dandy at the problematic spot.

As this works, i suggest you to first save your file with VDub using a lossless codec (UT Video, Lagarith), and then, using this file as input for x264.

I was never quite sure how to use the lossless codecs on vdub, i.e do I run vdub in full processing mode to save or some other mode, apply any filters or not etc. think I tried with huffy once and wasn't quite sure what to use in terms of codec settings or vdbub settings. I do remember though the saving process was quite long and slow and the oputput was huge so not quite sure this is a great solution spending hours on saving a source file to something else just so I can maybe use DGNV.

sandy_geser wrote:Another title I noticed such a glitch on after transcoding is Count of Monte Cristo from 2002.

Can you provide a link for purchase so I can be sure to get the same one you have?

Thank you. My order was placed. Would you also please confirm your script and x264 invocation for this bluray sufficient to display the issue you are having?

neuron2 wrote:Thank you. My order was placed. Would you also please confirm your script and x264 invocation for this bluray sufficient to display the issue you are having?

dgsource("count.dgi")
crop(0,20,-0,-20)
spline36resize(1280,696)

x264.exe --pass 1 --level 4.1 --stats count.stats --bitrate 4455 --preset slow --keyint 240 --min-keyint 24 -o NUL count.avs
x264.exe --pass 2 --level 4.1 --stats count.stats --bitrate 4455 --preset slow --keyint 240 --min-keyint 24 -o count.mkv count.avs

the glitch was around 00:42:38 over several frames. I then also tried without resize to 720p which had the same glitches in the same spot (so just comment out the resize part). the with ffdshow which didn't have it.
I found a couple of screenshots I took from the non-resized test:

http://i.imgur.com/sKGfo.jpg
http://i.imgur.com/jt26q.jpg

I didn't do as many tests with this title as with the other one. so this one was only done on the 520 card.

I need a few more things, please:

The top 25 lines of the DGI file.
The version number of x264 that you used, with download link if possible.

Thank you.

neuron2 wrote:I need a few more things, please:

The top 25 lines of the DGI file.
The version number of x264 that you used, with download link if possible.

Thank you.

SEQ 798 0 1 0 1
ENTRY 820 0 64
0:FRM 0 0 0
1:FRM 3 0 0
2:FRM 2 0 0
3:FRM 3 0 0
4:FRM 2 0 0
5:FRM 3 0 0
6:FRM 2 0 0
7:FRM 3 0 0
8:FRM 2 0 0
9:FRM 3 0 0
10:FRM 2 0 0
11:FRM 3 0 0
12:FRM 2 0 0
13:FRM 3 0 0
14:FRM 2 0 0
15:FRM 3 0 0
16:FRM 2 0 0
17:FRM 3 0 0
18:FRM 2 0 0
19:FRM 3 0 0
20:FRM 2 0 0
21:FRM 3 0 0
22:FRM 2 0 0
23:FRM 2 0 0
SEQ 182814 0 1 0 1
ENTRY 182836 0 0


http://mirror02.x264.nl/x264/32bit/8bit ... 4/x264.exe

admin, as you haven't mentioned it I assume the nvidia drivers can't be the cause for such an issue, right? there was an update this week so I will give it a go anyway with current versions of all components. I don't have the movie handy so I will do it with the tv episode.

on a different subject, is it possible the machine id changes when new nvidia drivers are installed? I was just doing a new project file for this video and DGIndexNV claimed my license is invalid. This happened to me before. Both times generating a new license fixed it.

update: same glitch at the same spot with the new nvidia driver, DGDecNV 2041, and current x264

Thanks, but may I ask again for the *top* 25 lines, please. You omitted the part I really need, from the first line onwards, containing the file list and other header data. I have to ensure to use the same files, range, etc.

It's VC1 I see.

Installing a new driver shouldn't change the machine ID, but I rely on Windows API return values, so with Windows, nothing can be ruled out. If you run out of licenses I will happily reset you (or anybody) back to 0.

neuron2 wrote:Thanks, but may I ask again for the *top* 25 lines, please. You omitted the part I really need, from the first line onwards, containing the file list and other header data. I have to ensure to use the same files, range, etc.

It's VC1 I see.

DGVC1IndexFileNV12 DGIndexNV 2040 X32
C:\DGAVCDecNV\

D:\THE_COUNT_OF_MONTE_CRISTO\BDMV\STREAM\00283.m2ts 30522009600

DEVICE 0
STREAM 1
PKTSIZ 192
VPID 4113
CLIP 0 0 0 8
RANGE 0 0 30522009599 0
AUDIO 1100,1101,1102,1103

SEQ 798 0 1 0 1
ENTRY 820 0 64
0:FRM 0 0 0
1:FRM 3 0 0
2:FRM 2 0 0
3:FRM 3 0 0
4:FRM 2 0 0
5:FRM 3 0 0
6:FRM 2 0 0
7:FRM 3 0 0
8:FRM 2 0 0
9:FRM 3 0 0
10:FRM 2 0 0
11:FRM 3 0 0
12:FRM 2 0 0
13:FRM 3 0 0
14:FRM 2 0 0
15:FRM 3 0 0
16:FRM 2 0 0
17:FRM 3 0 0
18:FRM 2 0 0
19:FRM 3 0 0
20:FRM 2 0 0
21:FRM 3 0 0
22:FRM 2 0 0
23:FRM 2 0 0
SEQ 182814 0 1 0 1
ENTRY 182836 0 0

hope that's better. I wasn't sure what to copy the first time. yes, this one is VC1. the other one was h264.

neuron2 wrote:Installing a new driver shouldn't change the machine ID, but I rely on Windows API return values, so with Windows, nothing can be ruled out. If you run out of licenses I will happily reset you (or anybody) back to 0.

ok, thanks!

Thank you! I'll attempt to replicate it as soon as the bluray arrives. But I'll use 2041 rather than 2040.