|
|
Since no new bugs have been reported for quite a while, I pulled the trigger and released DGMPGDec 1.2.0:
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.
Just a suggestion -- maybe finally give DGMPGDec its own true page, instead of as a quot;decoder fixquot; to DVD2AVI (who cares about the latter anymore, it's dead).
How about DGMPGDec/ (with redirect for old link since so many other places link to it)...
@neuron2
Did you look at audio delay issue (-336ms vs. -256ms) in a file I've send to your ftp?
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.
Originally posted by fewtch
Just a suggestion -- maybe finally give DGMPGDec its own true page, instead of as a quot;decoder fixquot; to DVD2AVI (who cares about the latter anymore, it's dead).
How about 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!
Thanks for the idea. Next I will rewrite the page and write a really good guide.
neuron2, did you look at the yv12 issue described here already?
Originally posted by bond
neuron2, did you look at the yv12 issue described here 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?
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.
Exactly. Thank you, Doom9, for your perceptive, and, as always, both acute and accurate, observation.
Originally posted by neuron2
Weird. I tried your link above and it worked!
Thanks for the idea. Next I will rewrite the page and write a really good guide.
LOL... glad you liked the idea.
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 quot;colorbars(352,288).converttoYV12()quot; 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)?
That's a reasonable question. I'll investigate and report my results.
dgdecode outputs i420... quot;colorbars(352,288).converttoYV12()quot; 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.
does swapping the UV in avisynth not hyper-correct this?
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-gt;yv12 conversion as well.
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 quot;Avisynth: caught an access violation at 0x00f63b0b attempting to read from 0x00000000quot;.
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 :\
the video source is mpeg4, xvid. Simple avs used is as follows.
avisource(quot;video.aviquot;,audio=false).blindpp()
I've used blindpp() many times in the past with xvid encoded avi's.
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.
@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.
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. |
|
Post at 2011-4-15 15:29
| This Author's Posts Only
