PDA

View Full Version : Possible Bug in either .d2v or .avs creation


DrChair
23rd July 2004, 16:47
Just did a backup of a PAL interlaced DVD using 0.55b and all seemed to have gone well.

However when I viewed the result with powerdvd, I noticed that 1 chapter on the dvd contained huge blocks (way bigger than macroblocks).

I opened the corresponding .avs (from the D2VAVS folder) with VirtualDub, and also noticed the same blocks
(for a screenshot check wrong.jpg (http://www.xs4all.nl/~drchair/wrong.jpg))

After that I demuxed the cell in question (Vobid 2, cellid 1), used dvd2avidg.exe to create a .d2v file for it and created a .avs for that .d2v.
That .avs showed no blocking.
(for a screenshot check good.jpg (http://www.xs4all.nl/~drchair/good.jpg))

Also, if i open the original .avs with Virtualdub, and directly jump to frame 21 (the frame from the screenshots) it also looks fine.

After that, I took the original .avs, and changed trim(114680,122791) into trim(114679,122790). This also gives a block-free .avs.
To me, this indicates a possible error in the fieldorder.

According to Bitrateviewer, the whole dvd is BFF

I hope it sounds familiar to someone, and a solution can be found.

Greetz DrChair

BTW, i worked around the error by manually encoding one of the .avs files that did work, in combination with rebuilder.ecl. After that I moved the correct .m2v into the d2vavs folder, and did a rebuild again.

SansGrip
23rd July 2004, 22:11
Check the D2V file. Does it contain a bunch of 2s repeated over and over?

If so, that might be the issue. In DVD2AVI parlance "2" means "top field first, don't repeat first frame." Because yours is BFF, perhaps the D2V should have 0s instead of 2s.

Though this shouldn't make any difference, since DVD-RB sets all the flags back to how they were originally (it caches them in the FLG files). I don't really know enough about how DVD-RB works internally to suggest anything else, but my vote is on the D2V. That said, it could be an off-by-one error in the AVS...

DrChair
24th July 2004, 14:22
The d2v generated by DVDRB indeed contains all 2's

The d2v created by dvd2avidg contains mostly 10's, and sometimes a couple of 0's

SansGrip
24th July 2004, 14:43
Mostly 10s? I've never seen a frame flag above 3, but then I've never used any "newer" version of DVD2AVI. Anyway, the point is they aren't all 2s. Though I still can't think why this would cause a problem -- DVD-RB is designed specifically to avoid all the usual is-it-interlaced-tff-or-bff-or-is-it-progressive issues by simply reencoding the frames as they appear in the MPEG stream.

Trahald
25th July 2004, 23:21
the new d2v format gives a 1 (Xx) in the second position if the frame does not need to reference the previous gop to be decoded. so 0 would be bff with reference needed / and 10 would be bff and no reference needed to prior gop.

SansGrip
26th July 2004, 02:57
Originally posted by Trahald
the new d2v format gives a 1 (Xx) in the second position if the frame does not need to reference the previous gop to be decoded.
Ahh, the closed GOP flag. That doesn't really help explain the problem, though. The way DVD-RB does it right now should work for all field flag combinations (basically because it ignores them). If it were a field order problem then the entire disc would be messed up, not just one cell.

What does the complete AVS look like?

DrChair
26th July 2004, 22:53
The .avs is pretty straigtforward:

#------------------
# AVS File Created by DVD Rebuilder
# VOBID:02, CELLID:01
#------------------
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mpeg2dec3dg.dll")
mpeg2source("V01.D2V")
trim(114680,122791)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())



The first few lines that correspond with the cell in question of the .d2v generated by DVD-RB:

7 2 5E54B 2 2 2 2 2 2 2 2 2 2
7 2 5E5FE 2 2 2
7 2 5E639 2
7 2 5E643 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5E6DA 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5E7B4 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5E86F 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5E92C 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5E9EE 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5EAAA 2 2 2 2 2 2 2 2 2 2 2 2 2
7 2 5EB69 2 2 2 2 2 2 2 2 2 2 2 2 2


The first few lines that correspond with the cell in question of the .d2v generated by dvd2avidg (1.77.3dg1.1.0 from decodefix110.zip):

7 2 5E54B 10 10 10 10 10 10 10 10 10 10
7 2 5E5FE 0 0 10
7 2 5E639 10
7 2 5E643 0 0 10 10 10 10 10 10 10 10 10 10
7 2 5E6DA 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5E7B4 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5E86F 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5E92C 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5E9EE 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5EAAA 10 10 10 10 10 10 10 10 10 10 10 10 10
7 2 5EB69 10 10 10 10 10 10 10 10 10 10 10 10 10


If I use the .avs above with the first .d2v, the video gets corrupted. If I use the same .avs with the second .d2v, the video is oke.

So it seems to me that the .d2v that DVD-RB generates, isn't totally compatible with MPEG2Dec3dg.dll (v1.0.1.0, from decodefix110.zip)

DVD-RB shouldn't ignore fieldorder if it messes up Avisynth...
But still it's strange that it only happens with one cell.

DrChair
2nd August 2004, 23:26
Just stumbled across an older post by Obi Wan Celeri, about the same problem:

http://forum.doom9.org/showthread.php?postid=497652

jdobbs
3rd August 2004, 19:37
Not sure, but you may have a problem with mixed versions. You have to be careful that you don't use a .D2V created by one version of MPEGDEC series of decoders with the .DLL of another. dvd2avidg creates a format incompatible with MPEG2DEC3DG.DLL and vice-versa.