DGMPGDec 1.2.0 Final

[neuron2]

Since no new bugs have been reported for quite a while, I pulled the trigger and released DGMPGDec 1.2.0:

http://neuron2.net/fixd2v/decodefix.html

The only changes from RC5 are: 1) Fixed crashing problem in BlindPP() with YUY2 data. 2) Allowed DGIndex to report any audio delay, no matter how wild it seems to be.

Right after the release is when the big bug is usually discovered. I'm waiting, please disappoint me.

[fewtch]

Just a suggestion -- maybe finally give DGMPGDec its own true page, instead of as a "decoder fix" to DVD2AVI (who cares about the latter anymore, it's dead).

How about http://neuron2.net/DGMPGDec/ (with redirect for old link since so many other places link to it)...

:)

[Krismen]

@neuron2
Did you look at audio delay issue (-336ms vs. -256ms) in a file I've send to your ftp?

[neuron2]

Originally posted by Krismen
Did you look at audio delay issue (-336ms vs. -256ms) in a file I've send to your ftp? Yes. The first GOP is IBBP..., so the I frame is preceded by two B frames in display order. DGIndex corrects for this, per ISO spec.

[neuron2]

Originally posted by fewtch
Just a suggestion -- maybe finally give DGMPGDec its own true page, instead of as a "decoder fix" to DVD2AVI (who cares about the latter anymore, it's dead).

How about http://neuron2.net/dgmpgdec/dgmpgdec.html (with redirect for old link since so many other places link to it)...
Weird. I tried your link above and it worked! :eek:

Thanks for the idea. Next I will rewrite the page and write a really good guide.

[bond]

neuron2, did you look at the yv12 issue described here (http://forum.doom9.org/showthread.php?s=&threadid=89977) already?

[neuron2]

Originally posted by bond
neuron2, did you look at the yv12 issue described here (http://forum.doom9.org/showthread.php?s=&threadid=89977) already? In view of this:If this is true, then the problem lies in /libmpdemux/demux_avs.h, line 151. That macro avs_is_yv12() assumes that I420 and YV12 are the same thing, but they obviously aren't (swapped chroma planes).

The patch seems to convert automatically whatever non-YV12 video returned by the script to YV12, but if the input is I420 there's no conversion due to the reason above. ...is there something that you think should be changed in DGDecode?

[Doom9]

sounds like a mencoder problem to me. avs2yuv, and other applications consuming avs files (like VDub, tons of MPEG-2 encoders, etc) seem to have no problem, so that's a strong indicator that the source is not to be blamed.

[neuron2]

Exactly. Thank you, Doom9, for your perceptive, and, as always, both acute and accurate, observation. :p

[fewtch]

Originally posted by neuron2
Weird. I tried your link above and it worked! :eek:

Thanks for the idea. Next I will rewrite the page and write a really good guide.
LOL... glad you liked the idea. :D

[bond]

Originally posted by neuron2
In view of this: ...is there something that you think should be changed in DGDecode? well, i wonder why a generic "colorbars(352,288).converttoYV12()" stream works fine in mencoder, a should-be yv12 stream output by dgmpgdec doesnt work...

does dgmpgdec output I420 or YV12 (and is there a difference between the two)?

[neuron2]

That's a reasonable question. I'll investigate and report my results.

[tritical]

dgdecode outputs i420... "colorbars(352,288).converttoYV12()" produces a YV12, not i420, clip so it works. The difference between yv12 and the i420 output by dgdecode is the chroma planes are swapped in memory. The problem with the avs support in libmpdemux is, while it does call converttoyv12 on anything not yv12, it assumes yv12 and i420 are the same so converttoyv12 is never called. However, even if you change this in libmpdemux so that yv12 != i420 and converttoyv12 is called on i420 input, avisynth's actual converttoyv12() routine will do nothing when feed with i420. So libmpdemux/demux_avs.c eithers needs to have its own i420 to yv12 conversion to swap the planes, or in the place where it fills the buffer the code needs to be changed so that the planes are copied in the right order, thats how it appears to me anyways.

[zettai]

does swapping the UV in avisynth not hyper-correct this?

[tritical]

It should, I think someone on the other thread said it did. libmpdemux/demux_avs.c could simply invoke swapuv on i420 input for a i420->yv12 conversion as well.

[Luminaria]

I may have found a problem with blindpp. With 1.2.0, when I use blindpp() in combination with avisource() on a mod-16 resolution video (576*432), avisynth errors with the following "Avisynth: caught an access violation at 0x00f63b0b attempting to read from 0x00000000".

I was worried something may have gone wrong on my end, so I rebooted and tried it again, with the same result. I resized the video to 640*480 and 640*352, both mod-16 as well, and there was no error. Both mpeg2source's cpu= fuction and blindpp() worked on a .d2v file unresized, and resized to the resolution of my problem avi (576*432).

Not sure what's going on here :\

[Luminaria]

the video source is mpeg4, xvid. Simple avs used is as follows.

avisource("video.avi",audio=false).blindpp()

I've used blindpp() many times in the past with xvid encoded avi's.

[Luminaria]

Did some extra testing. blindpp() when called using the 1.0.12 version of dgdecode works normally in my case. 1.1.0 and 1.2.0 remain problematic.

[neuron2]

@tritical

You modified BlindPP() and I incorporated your changes. Did you want to fix this or should I back out your changes? Thank you.

EDIT: I found an old bug that was there before tritical's changes (see below). trit, I think we're OK for now.

[raymod2]

Don, there still appears to be problems with the audio delay calculations. I ran DGIndex 1.0.12 on one of my DVDs (Cutaway) and it reported the following audio track delays:

cutaway AC3 T01 2_0ch 192Kbps DELAY 16ms.ac3
cutaway AC3 T02 2_0ch 192Kbps DELAY 16ms.ac3
cutaway AC3 T03 2_0ch 192Kbps DELAY 16ms.ac3

Then I tried it with your latest version (1.2.0) and it reported the following audio track delays:

cutaway AC3 T01 2_0ch 192Kbps DELAY 0ms.ac3
cutaway AC3 T02 2_0ch 192Kbps DELAY 66ms.ac3
cutaway AC3 T03 2_0ch 192Kbps DELAY 133ms.ac3

According to my tool the track delays should all be 0ms.

[neuron2]

Cut the start of the VOB, place it on my ftp server, and notify me here. Thank you.

(I thought you said your tool only processes the first track?!)

[raymod2]

Originally posted by neuron2
(I thought you said your tool only processes the first track?!)

s/0x80/0x81/
make

Not too hard to modify. ;) I'm ftp'ing the first VOB file to you now.

[neuron2]

I found another crashing cause in BlindPP(). I hope it is the last one. BlindPP::GetFrame() was getting write pointers on the child frame. When getting a write pointer on a child frame you have to call env->MakeWritable(), otherwise you'll get a null pointer if the child still holds a reference to the frame. But in this case, read pointers are sufficient, so I changed them to be read pointers.

Here is a beta of the fix. Please test it. When we get BlindPP() stable, I'll make a DGMPGDec 1.2.1 patch release.

http://neuron2.net/dgmpgdec/DGDecode121b1.zip

[bond]

Originally posted by tritical
dgdecode outputs i420... "colorbars(352,288).converttoYV12()" produces a YV12, not i420, clip so it works. The difference between yv12 and the i420 output by dgdecode is the chroma planes are swapped in memory. so dgdecode outputs i420 and not yv12 even if the input source is yv12 (dvd)...

shouldnt this be changed to yv12 output? i assume its not a big colorconversion, but its one, right? doesnt this cost speed?

[tritical]

@neuron2
Actually, I had a question about something you mentioned in the other thread about BlindPP. That the QP_Store array size needed increasing for YUY2? The QP array only depends on the size of the luma plane doesn't it? ...at least that was my understanding. What part was it crashing on when it was /256 and doesn't when it is /128? The getwriteptr() was my fault, it was left over from before and I simply forgot to change it to getreadptr when I rearranged the getframe function.

EDIT: I know where the problem is and why changing it to /128 fixed the crashing. In the main pp function, in the chroma loop, in the "if (mode & PP_DEBLOCK_C_H)" case, there should be a check for is422 and then it should use y>>4 if it is and y>>3 if it isn't. Atm it is always using y>>3. Seems I added that check to the "if (mode & PP_DEBLOCK_C_V)", but not the other :angry:. I was really not having a good day when YUY2 support was added, not sure why none of this showed up when I initially tested it :mad:.

@bond
so dgdecode outputs i420 and not yv12 even if the input source is yv12 (dvd)...

shouldnt this be changed to yv12 output? i assume its not a big colorconversion, but its one, right? doesnt this cost speed? Well, atm there is no conversion cause the decoder decodes straight into the avisynth frame buffer. Thinking about it, dgdecode could probably be made to output yv12 instead of i420 by simply changing:

vi.pixel_type = VideoInfo::CS_I420;

to

vi.pixel_type = VideoInfo::CS_YV12;

in the mpeg2source constructor. Wouldn't even need to change anything else. Doubt it would have any noticeable effect on speed.

[neuron2]

Originally posted by bond
so dgdecode outputs i420 and not yv12 even if the input source is yv12 (dvd) I420 and YV12 refer to memory representations of decoded video. It is not correct to call a DVD YV12.

shouldnt this be changed to yv12 output? i assume its not a big colorconversion, but its one, right? doesnt this cost speed? It's perfectly reasonable to output I420.

The Avisynth docs say this:
Other possibilities are:

CS_BGR24,
CS_BGR32,
CS_YUY2,
CS_YV12, // y-v-u, planar
CS_I420, // y-u-v, planar
CS_IYUV // same as above
The last two are automatically converted to YV12, so filter writers should not worry about these. and this:

bool IsYV12()

Note that I420 is also reported as YV12, because planes are automatically swapped. I assume that the swap is achieved for filters by simply returning the appropriate pointer when GetReadPtr() or GetWritePtr() is called. That would not require any time-consuming processing. I don't know if the auto swap is done for video delivered to external applications. Apparently it is not. You could ask sh0dan about it.

[neuron2]

Originally posted by tritical
I know where the problem is and why changing it to /128 fixed the crashing. In the main pp function, in the chroma loop, in the "if (mode & PP_DEBLOCK_C_H)" case, there should be a check for is422 and then it should use y>>4 if it is and y>>3 if it isn't. Atm it is always using y>>3. Seems I added that check to the "if (mode & PP_DEBLOCK_C_V)", but not the other. Thanks, I'll fix that.

Well, atm there is no conversion cause the decoder decodes straight into the avisynth frame buffer. Thinking about it, dgdecode could probably be made to output yv12 instead of i420 by simply changing:

vi.pixel_type = VideoInfo::CS_I420;

to

vi.pixel_type = VideoInfo::CS_YV12;

in the mpeg2source constructor. Wouldn't even need to change anything else. We could have a new option to output YV12 or I420.

[neuron2]

I made a new version with the PP fix and added the i420 parameter. It defaults to output YV12 (if tritical is right). For I420, set i420=true. I tried with VirtualDub and TMPGEnc with YV12 output and everything seemed fine. Bond, please try it with mencoder.

http://neuron2.net/dgmpgdec/DGDecode121b2.zip

EDIT: Several users report that this fixes the problem with mencoder.

[neuron2]

Originally posted by raymod2
I'm ftp'ing the first VOB file to you now. Dan, I don't have unlimited FTP space! I said cut the first part of the VOB but it looks like you're uploading the entire 1GB. I'm gonna have to kill it. I've got enough of it; the important PTSs are right at the beginning. :)

[neuron2]

@Dan

I found the problem. DGIndex was reapplying the frame re-ordering adjustment again for each subsequent track after the first! I fixed it and released DGMPGDec 1.2.1 Beta 2. You can find it in the thread of that title. Thank you for pointing out this problem.