DGMPGDec 1.5.6

neuron2 · 5th November 2009, 20:59

1. Added Unix-style CLI parsing. The legacy parsing is also supported. The new parsing allows for commas and spaces within file names.

2. Revised the audio header emulation check to prevent it from rejecting some valid audio.

3. Increased the timeout for finding transport packets from 3 to 5 seconds.

4. Properly ignore some program stream filler packets that do not specify the correct packet length.

5. When a new transport stream is loaded without exiting DGIndex, the PIDs are now re-determined (without requiring the user to reset them as was previously the case).

6. Fixed a bug in which normalization was being used erroneously when demuxing audio (could happen if you were decoding AC3 to WAV with normalization enabled and then you set the mode to demux audio without unchecking the normalization option).

7. Fixed a bug in the Cropping dialog such that the height field was not properly set after changes were made.

8. Improved reliability of stream type detection upon file open.

http://neuron2.net/dgmpgdec/dgmpgdec.html

b66pak · 5th November 2009, 21:13

thanks a lot...
_

MatLz · 5th November 2009, 21:30

Just out and already in intense usage for me!...no bug to signal...not yet...

THANX A LOT!

Egh · 6th November 2009, 03:53

LOL I was checking for a new version just two days ago.

Thanks alot!

Nomolu · 6th November 2009, 18:47

Good job Neuron2! DGIndex is now handling everything I throw at it without any problems.

Zarxrax · 6th November 2009, 23:07

I'm posting this on behalf of someone else. Apparently he has some PAL video that's got pulldown, but dgindex apparently doesn't have any way of handling this kind of pulldown, and he wonders if you can add support for it.
-------------------------------------------------
I have an issue with DGIndex and PAL footage.
I'm positive that my source is soft telecined PAL, stored as 24fps progressive and with the 2:2:2:2:2:2:2:2:2:2:2:3 pulldown enabled.
The issue is that, if I try to either honor or ignore the pulldown flag, the output will be 25fps, which isn't what I want. On the other hand, if I try to force FILM, I get a 20fps output, which I suppose is wrong (also, AFAIK, force FILM is supposed to be used on NTSC only anyway).
The source's Video Type is reported as 82.94% Video and the Frame Type is Progressive.
I demuxed an m2v along with audio and muxed them in a ts so that you can check for yourself and see what's to be done.
Sample: http://www.sendspace.com/file/jpzzjo

Atak_Snajpera · 7th November 2009, 00:08

Your sample looks like normal 25 fps. I checked part from 0:31 to 0:34 and every frame was different. It looks like simple speedup from 23.976 fps -> 25 fps. I wouldn't change enything.

thewebchat · 7th November 2009, 00:46

Zarxzarx. Huh, this is an interesting sample with soft-telecined PAL. If it's consistent, you can use "Ignore Pulldown Flags" and then do an AssumeFPS(24) later. Otherwise, process it with "Honor Pulldown Flags" and then use TIVTC with a decimation cycle of 25.

Edit: I also think you set the delay wrong because it says it's -600000000000ms.
Edit2: I'm also interested in what they did with the 60i/VFR segments in ep 15. Probably some blend garbage.
Edit3: FFMS2 says that the framerate is 23.976, although simple PAL ivtc would return 24 fps. FFMS2 is probably (?) right.

SilaSurfer · 12th November 2009, 15:56

hey Neuron2 great tool thanks. I wanted to ask you which iDCT Algorithm do you suggest, i have a Pentium IV dual core processor and is there a quality
difference between them. I'm backing up my DVDs

neuron2 · 12th November 2009, 16:10

It doesn't make much difference. You can have a look at Appendix B in the DGDecode user manual for more discussion about it.

SilaSurfer · 12th November 2009, 16:14

Then basicly I should use 32-SSE2 MMX Algorithm it is optimized for my Cpu?

neuron2 · 12th November 2009, 16:24

You can do some testing and then decide what you prefer to use. But as I said, you'll probably not discover any more than is already documented in the Appendix I mentioned. If you do, please report it here.

SilaSurfer · 12th November 2009, 17:38

Ive read somewhere I'cant really remember where somebody had problems with macroblocks with IEEE-1180 Reference algorithm . It was with Dgindex 1.50 version on DVD source input. Is this true?

neuron2 · 12th November 2009, 17:41

There was an early bug but it was fixed long ago. Anyway there's no need to use that one as it is slower.

SilaSurfer · 12th November 2009, 17:51

Slow for quality I don't mind as its written in the manual:
Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD)
Speedwise: SSE2/MMX and SSE/MMX (Skal)

SilaSurfer · 14th November 2009, 18:22

Hey Neuron, could you please close this thread that I created, I asked the same question here and in thread, I'm sorry about it it won't happen again. Thanks
http://forum.doom9.org/showthread.php?t=150756

5th November 2009, 20:59	#1 \| Link
neuron2 _ Join Date: Jan 2002 Posts: 16,634	DGMPGDec 1.5.6 1. Added Unix-style CLI parsing. The legacy parsing is also supported. The new parsing allows for commas and spaces within file names. 2. Revised the audio header emulation check to prevent it from rejecting some valid audio. 3. Increased the timeout for finding transport packets from 3 to 5 seconds. 4. Properly ignore some program stream filler packets that do not specify the correct packet length. 5. When a new transport stream is loaded without exiting DGIndex, the PIDs are now re-determined (without requiring the user to reset them as was previously the case). 6. Fixed a bug in which normalization was being used erroneously when demuxing audio (could happen if you were decoding AC3 to WAV with normalization enabled and then you set the mode to demux audio without unchecking the normalization option). 7. Fixed a bug in the Cropping dialog such that the height field was not properly set after changes were made. 8. Improved reliability of stream type detection upon file open. http://neuron2.net/dgmpgdec/dgmpgdec.html Last edited by neuron2; 5th November 2009 at 21:03.

5th November 2009, 21:30	#3 \| Link
MatLz Now, in negative mode. Join Date: Jul 2009 Location: Under my fur Posts: 265	Just out and already in intense usage for me!...no bug to signal...not yet... THANX A LOT! __________________ We are spitting food to these hungry eyes. You see they ask, we know they are greedy of our rot. Better than to give jam to pigs.

7th November 2009, 00:08	#7 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Dublin (but born in Poland) Posts: 2,961	Your sample looks like normal 25 fps. I checked part from 0:31 to 0:34 and every frame was different. It looks like simple speedup from 23.976 fps -> 25 fps. I wouldn't change enything. __________________ RipBot264 - Simple and easy to use GUI -> iPOD . iPhone . AppleTV . PSP . PS3 . XBOX360 . BluRay Mediainfo - Simple GUI with basic command line support

7th November 2009, 00:46	#8 \| Link
thewebchat Advanced Blogging Join Date: May 2009 Posts: 460	Zarxzarx. Huh, this is an interesting sample with soft-telecined PAL. If it's consistent, you can use "Ignore Pulldown Flags" and then do an AssumeFPS(24) later. Otherwise, process it with "Honor Pulldown Flags" and then use TIVTC with a decimation cycle of 25. Edit: I also think you set the delay wrong because it says it's -600000000000ms. Edit2: I'm also interested in what they did with the 60i/VFR segments in ep 15. Probably some blend garbage. Edit3: FFMS2 says that the framerate is 23.976, although simple PAL ivtc would return 24 fps. FFMS2 is probably (?) right. Last edited by thewebchat; 7th November 2009 at 01:14. Reason: Updates

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

5th November 2009, 21:13	#2 \| Link
b66pak Registered User Join Date: Aug 2008 Location: Romania (EU) Posts: 330	thanks a lot... _

6th November 2009, 03:53	#4 \| Link
Egh Registered User Join Date: Jun 2005 Posts: 618	LOL I was checking for a new version just two days ago. Thanks alot!

6th November 2009, 18:47	#5 \| Link
Nomolu Registered User Join Date: Oct 2006 Posts: 14	Good job Neuron2! DGIndex is now handling everything I throw at it without any problems.

6th November 2009, 23:07	#6 \| Link
Zarxrax Registered User Join Date: Dec 2001 Location: Concord, NC Posts: 941	I'm posting this on behalf of someone else. Apparently he has some PAL video that's got pulldown, but dgindex apparently doesn't have any way of handling this kind of pulldown, and he wonders if you can add support for it. ------------------------------------------------- I have an issue with DGIndex and PAL footage. I'm positive that my source is soft telecined PAL, stored as 24fps progressive and with the 2:2:2:2:2:2:2:2:2:2:2:3 pulldown enabled. The issue is that, if I try to either honor or ignore the pulldown flag, the output will be 25fps, which isn't what I want. On the other hand, if I try to force FILM, I get a 20fps output, which I suppose is wrong (also, AFAIK, force FILM is supposed to be used on NTSC only anyway). The source's Video Type is reported as 82.94% Video and the Frame Type is Progressive. I demuxed an m2v along with audio and muxed them in a ts so that you can check for yourself and see what's to be done. Sample: http://www.sendspace.com/file/jpzzjo

12th November 2009, 15:56	#9 \| Link
SilaSurfer Registered User Join Date: Oct 2009 Posts: 19	hey Neuron2 great tool thanks. I wanted to ask you which iDCT Algorithm do you suggest, i have a Pentium IV dual core processor and is there a quality difference between them. I'm backing up my DVDs

12th November 2009, 16:10	#10 \| Link
neuron2 _ Join Date: Jan 2002 Posts: 16,634	It doesn't make much difference. You can have a look at Appendix B in the DGDecode user manual for more discussion about it.

12th November 2009, 16:14	#11 \| Link
SilaSurfer Registered User Join Date: Oct 2009 Posts: 19	Then basicly I should use 32-SSE2 MMX Algorithm it is optimized for my Cpu?

12th November 2009, 16:24	#12 \| Link
neuron2 _ Join Date: Jan 2002 Posts: 16,634	You can do some testing and then decide what you prefer to use. But as I said, you'll probably not discover any more than is already documented in the Appendix I mentioned. If you do, please report it here.

12th November 2009, 17:38	#13 \| Link
SilaSurfer Registered User Join Date: Oct 2009 Posts: 19	Ive read somewhere I'cant really remember where somebody had problems with macroblocks with IEEE-1180 Reference algorithm . It was with Dgindex 1.50 version on DVD source input. Is this true?

12th November 2009, 17:41	#14 \| Link
neuron2 _ Join Date: Jan 2002 Posts: 16,634	There was an early bug but it was fixed long ago. Anyway there's no need to use that one as it is slower.

12th November 2009, 17:51	#15 \| Link
SilaSurfer Registered User Join Date: Oct 2009 Posts: 19	Slow for quality I don't mind as its written in the manual: Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD) Speedwise: SSE2/MMX and SSE/MMX (Skal)

14th November 2009, 18:22	#16 \| Link
SilaSurfer Registered User Join Date: Oct 2009 Posts: 19	Hey Neuron, could you please close this thread that I created, I asked the same question here and in thread, I'm sorry about it it won't happen again. Thanks http://forum.doom9.org/showthread.php?t=150756