DGMPGDec 1.2.0 Final

Guest · 18th February 2005, 02:19

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 · 18th February 2005, 03:15

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 · 18th February 2005, 10:26

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

Guest · 18th February 2005, 14:32

Quote:

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.

Guest · 18th February 2005, 15:20

Quote:

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!

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

bond · 18th February 2005, 15:27

neuron2, did you look at the yv12 issue described here already?

Guest · 18th February 2005, 16:01

Quote:

Originally posted by bond
neuron2, did you look at the yv12 issue described here already?

In view of this:

Quote:

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 · 18th February 2005, 16:46

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.

Guest · 18th February 2005, 19:02

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

fewtch · 18th February 2005, 19:30

Quote:

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.

bond · 18th February 2005, 19:45

Quote:

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)?

Guest · 18th February 2005, 19:54

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

tritical · 18th February 2005, 19:59

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 · 18th February 2005, 20:29

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

tritical · 18th February 2005, 20:49

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 · 19th February 2005, 01:18

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 · 19th February 2005, 01:27

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 · 19th February 2005, 02:46

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.

Guest · 19th February 2005, 03:30

@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 · 19th February 2005, 04:13

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.

18th February 2005, 02:19	#1 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	DGMPGDec 1.2.0 Final 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. Last edited by Guest; 18th February 2005 at 02:32.

18th February 2005, 10:26	#3 \| Link
Krismen Vacuum tube addict Join Date: Sep 2003 Location: Poland Posts: 122	@neuron2 Did you look at audio delay issue (-336ms vs. -256ms) in a file I've send to your ftp? __________________ 130F02041B18AB "... a gdybym był młotkowym, w fabryce z młotkiem szalał..."

18th February 2005, 15:27	#6 \| Link
bond Registered User Join Date: Nov 2001 Posts: 9,770	neuron2, did you look at the yv12 issue described here already? __________________ Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ \| AVC/H.264 FAQ \| AAC FAQ \| MP4 FAQ \| MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora \| Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free

18th February 2005, 16:46	#8 \| Link
Doom9 clueless n00b Join Date: Oct 2001 Location: somewhere over the rainbow Posts: 10,579	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. __________________ For the web's most comprehensive collection of DVD backup guides go to www.doom9.org

18th February 2005, 19:59	#13 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	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. Last edited by tritical; 18th February 2005 at 20:01.

18th February 2005, 03:15	#2 \| Link
fewtch Registered User Join Date: Feb 2002 Posts: 208	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)...

18th February 2005, 19:02	#9 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	Exactly. Thank you, Doom9, for your perceptive, and, as always, both acute and accurate, observation.

18th February 2005, 19:54	#12 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	That's a reasonable question. I'll investigate and report my results.

18th February 2005, 20:29	#14 \| Link
zettai Fascinated Lurker Join Date: Feb 2002 Location: Durham, UK Posts: 243	does swapping the UV in avisynth not hyper-correct this?

18th February 2005, 20:49	#15 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	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.

19th February 2005, 01:18	#16 \| Link
Luminaria Registered User Join Date: Dec 2003 Location: South Carolina, USA Posts: 22	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 (576432), 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 640480 and 640352, 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 (576432). Not sure what's going on here :\

19th February 2005, 01:27	#17 \| Link
Luminaria Registered User Join Date: Dec 2003 Location: South Carolina, USA Posts: 22	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.

19th February 2005, 02:46	#18 \| Link
Luminaria Registered User Join Date: Dec 2003 Location: South Carolina, USA Posts: 22	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.

19th February 2005, 03:30	#19 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	@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. Last edited by Guest; 19th February 2005 at 09:45.

19th February 2005, 04:13	#20 \| Link
raymod2 Registered User Join Date: Jan 2005 Posts: 96	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.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode