Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > DVD2AVI / DGIndex

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th May 2005, 17:26   #1  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
DGMPGDec 1.4.0 Final!

This version provides the following new features relative to version 1.3.0:

1. Standard call wrappers for dgdecode.dll access functions for use by Visual Basic, etc. E.g.: getRGBFrame_SC().

2. Fix for slice error recovery bug that caused some (rare) picture decoding errors.

3. Program streams with video stream IDs other than 0xE0 are now supported.

4. The preview info box of DGIndex now shows the audio type of all the audio tracks. This is populated when doing a Preview (F5).

5. Fixed decoding errors due to improper recovery from corruption of transport streams.

6. Fixed the pitch=width assumption, thereby allowing proper operation under newer versions of Avisynth that modify the alignment rules (revisions kindly contributed by 'tritical').

7. Fixed the emulated header problem by properly parsing the pack or transport layer when getting the initial sequence header.

8. Corrected an error in the D2V format document (bits 6 and 7 of the per-frame flags byte was erroneously reversed).

9. The process priority can now be changed in DGIndex during a Save Project operation.

10. A bug in the PAT/PMT parser was repaired that could cause DGIndex to erroneously think that a PAT/PMT is not present.

11. Added the .vro and .mpv file types to the DGIndex open dialog.

12. Fixed the Reference IDCT (type 4). Changes by jackei derived from his latest DVD2AVI version.

13. MPEG1 is now supported.

14. DGVfapi now supports multiple instantiation, i.e., multiple "fake" AVIs served at the same time. It can also open AVS scripts as well as D2V files. Thanks to "tritical" for these enhancements.

15. DGParse and DGFix have been integrated into a new menu pulldown of DGIndex called "Tools".

16. The integrated DGParse info now shows the GOP structure, and properly shows the effect of the field operations.

17. Fixed a bug such that during preview the info dialog did not show the audio track information for transport streams and PVA streams.

18. The Detect PIDs dialog now has a "Done" button.

19. Fixed a bug in parsing of transport streams.

20. Removed YV12toYUY2() and YV12toRGB24() because they duplicate Avisynth native filters.

21. Replaced the buggy LumaFilter() with a new, optimized LumaYV12() filter by ARDA.

22. Added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps.

23. Added a new CLI option, -SD, that allows setting of a custom delimiter character.

24. "Process WAV" functionality was removed. SRC/normalization can no longer be applied to LPCM.

25. LPCM support was improved: 1) 48K/96K, 16bit/24/bit, and mono/stereo are now supported. 2) The format info is included in the filename and the info dialog. 3) Demux Track and Demux All Tracks now work for LPCM (no special handling).

26. The D2V format version is now checked when loading a D2V file.

27. IDCT support was fixed: 1) The IDCT algorithm specified in the INI or D2V file is now not automatically promoted (e.g., previously if you had IDCT=1 in the INI file and then started DGIndex, you'd end up with IDCT=3). However, the IDCT is scaled down if it is not supported by the processor. 2) A bug in DGDecode was fixed that caused SSEMMX to be used when SSE2MMX was requested. 3) The IDCT algorithm is now consistently numbered between the CLI, D2V, etc.

28. Added audio processing to the Quick Start guide.

29. Fixed a problem that caused failure of AC3 audio demuxing from a
transport stream if the audio stream was not contained in the PAT/PMT
tables.

30. Fixed a problem in DGVfapi that caused conversion of AVS scripts
to fail when they delivered RGB32. [fix by 'tritical']

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

Last edited by Guest; 12th July 2005 at 01:50.
Guest is offline   Reply With Quote
Old 8th May 2005, 18:13   #2  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,144
Did you notice the problem with the latest Avisynth beta?

http://forum.doom9.org/showthread.ph...0&pagenumber=5
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 8th May 2005, 18:57   #3  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
I made a quick fix for this... it took a few more changes then I thought it would because of the way field based PP is done. The changes were in store.cpp where the postprocess() call is made, in postprocess I added a new parameter called iPP so that the fast_copy code would work in field based mode when the pitches weren't the same, and then in avisynthapi.cpp I changed the postprocess() calls in blindpp. Also, there seemed to be a bug in YV12 BlindPP with iPP=true, the src pitch needed to be doubled and wasn't being. I tested it with the new avisynth and it seemed to work fine... the changed files are in the zip below, originally from v1.3 source.

EDIT: needed another small change to the main postprocess routine for field based pp to work when pitch and width weren't equal.

Last edited by tritical; 10th May 2005 at 16:40.
tritical is offline   Reply With Quote
Old 8th May 2005, 19:26   #4  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Nope, I didn't notice that. I'll incorporate the fixes and release a new beta. Thank you Boulder for pointing it out, and tritical for the patches.
Guest is offline   Reply With Quote
Old 8th May 2005, 22:06   #5  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Thought about it some more and my patch is still busted for field based PP when pitch doesn't match width. The copying will work, and it will process all the pixels, but the QP pointer will be incorrect for the second half of each line due to the extra pixels in the middle. Possible fixes I can think of: change a lot of stuff in the post-processing code, forget changing the pping code and just add in an extra copy step where needed so that field based post-processing is always done on a buffer with pitch==width, or forget about changing that other stuff and simply change the env->NewVideoFrame calls to return 16/8 byte aligned frames as before. There is probably another, better option that I am not thinking of, hopefully you or someone else can .

Last edited by tritical; 8th May 2005 at 22:23.
tritical is offline   Reply With Quote
Old 10th May 2005, 01:21   #6  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Was making another fix today just using copies where field based post-processing is used, and realized this problem runs deeper then just post-processing. Specifically, the copy functions at the bottom of vfapidec.cpp are broken if width != pitch and you pass the larger one first so it only shows up if rff's are present. Those can be fixed easily, but then some of the colorspace conversions seem to depend on width == pitch as well (420 to 422 and 422 to 444). That can also be fixed without too much hassle, but who knows if there are still other places that need changing. It seems to be quite a mess when width != pitch .

Last edited by tritical; 10th May 2005 at 16:39.
tritical is offline   Reply With Quote
Old 10th May 2005, 01:42   #7  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
I want to know why the author made this change to Avisynth and why it is seen as so important that he is happy to break existing applications, and important ones at that. To be quite honest, I can't say I'm particularly motivated to fix all this, especially when I had no say in the decision. Maybe the author will clean up the mess?

How about some polymorphism, so that existing applications can work the old way?

And just in case anyone wants to rag on me, I inherited all this code assuming pitch = width; I didn't write a single line of it. All the precursors of DGDecode are going to be broken too.

Last edited by Guest; 10th May 2005 at 02:36.
Guest is offline   Reply With Quote
Old 10th May 2005, 02:46   #8  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Don't know that, though I suspect the change was mainly for sse2/sse3 optimization purposes. Its only a beta so I'm sure there is some room for discussion on the change.

env->NewVideoFrame() already allows one to call with a negative align argument that will force a specific alignment even if it is less then the default. That could be used to get the same alignment as before, but the filters that request frames from a clip (blindpp, etc..) could still get 32byte aligned frames as input. Though technically it is possible they could get that type of alignment now if another filter up the chain calls env->NewVideoFrame() with an align value other then the default. However, fixing those few filters for when pitch!=width would definitely be much easier then the core stuff.

I'm sure no one is blaming you for it. I forgot that this would also break previous mpeg2dec3 versions as well.
tritical is offline   Reply With Quote
Old 10th May 2005, 02:54   #9  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
OK, I'll chill. It's only been a day since it came to light, and, as you say, it's a beta.

And oh, thanks for your analyses! Saves me quite a bit of thinking, which gets harder as I get older, and, anyway, I'm obsessed with the metaphysics of QM these days, which limits my available cerebral bandwidth, sad to say. Some argue it was quite limited to start with, but I won't dignify that.

Last edited by Guest; 10th May 2005 at 02:58.
Guest is offline   Reply With Quote
Old 10th May 2005, 14:17   #10  |  Link
Nic
Moderator
 
Join Date: Oct 2001
Location: England
Posts: 3,285
"I'm obsessed with the metaphysics of QM"
So, your too involved with unimportant things like a formula for it god exists or not when you could be adding MPEG-1 support to your DVD2AVI suite?

If you need to me look at any particular pitch != width problems let me know...

Cheers,
-Nic
Nic is offline   Reply With Quote
Old 10th May 2005, 15:32   #11  |  Link
Gabrielgoc
Member
 
Join Date: Jun 2002
Location: Buenos Aires - Argentina
Posts: 43
neuron,

It is possible to add the sample rate to each audio stream, in the information window?

thx

Gabriel
Gabrielgoc is offline   Reply With Quote
Old 10th May 2005, 16:06   #12  |  Link
CyberGuy
Registered User
 
CyberGuy's Avatar
 
Join Date: Oct 2004
Posts: 51
Iím not sure if this is a problem with MPlayer 1.0pre7, AviSynth 2.5.6b3 or the DGDECODE alignment issue, but I can play the following script fine in Windows Media Player, but it is garbage when played in MPlayer 1.0pre7. Is there something I can add to the script to make it work? Iím using MPlayer to convert the file to raw I420.

LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0)
Return(Source)
CyberGuy is offline   Reply With Quote
Old 10th May 2005, 17:16   #13  |  Link
Cyberia
Moderator
 
Cyberia's Avatar
 
Join Date: Nov 2002
Location: Inside
Posts: 718
DGDecode can output I420, just set i420=True.
Code:
LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)
Cyberia is offline   Reply With Quote
Old 10th May 2005, 17:17   #14  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
First try reverting to Avisynth 2.5.5. If it still plays bad in MPlayer 1.0pre7, then it is likely a problem in MPlayer.
Guest is offline   Reply With Quote
Old 10th May 2005, 17:18   #15  |  Link
CyberGuy
Registered User
 
CyberGuy's Avatar
 
Join Date: Oct 2004
Posts: 51
Quote:
Originally posted by neuron2
First try reverting to Avisynth 2.5.5. If it still plays bad in MPlayer 1.0pre7, then it is likely a problem in MPlayer.
It plays fine with AviSynth 2.5.5 and MPlayer 1.0pre7.
CyberGuy is offline   Reply With Quote
Old 10th May 2005, 17:18   #16  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
Originally posted by Gabrielgoc
It is possible to add the sample rate to each audio stream, in the information window?
I'll have a look. Thanks for the suggestion.
Guest is offline   Reply With Quote
Old 10th May 2005, 17:20   #17  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
Originally posted by CyberGuy
It plays fine with AviSynth 2.5.5 and MPlayer 1.0pre7.
Then you'll have to wait for a resolution to the alignment issue before you can use DGDecode under the Avisynth beta. It's only been 2 days, so please be patient.
Guest is offline   Reply With Quote
Old 10th May 2005, 17:22   #18  |  Link
CyberGuy
Registered User
 
CyberGuy's Avatar
 
Join Date: Oct 2004
Posts: 51
Quote:
Originally posted by Cyberia
DGDecode can output I420, just set i420=True.
Code:
LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)
Same problem.
CyberGuy is offline   Reply With Quote
Old 10th May 2005, 17:28   #19  |  Link
CyberGuy
Registered User
 
CyberGuy's Avatar
 
Join Date: Oct 2004
Posts: 51
Quote:
Originally posted by neuron2
Then you'll have to wait for a resolution to the alignment issue before you can use DGDecode under the Avisynth beta. It's only been 2 days, so please be patient.
Thank you. Return(Source).Info returns a Video Pitch of 720 with AviSynth 2.5.5 and a Video Pitch of 736 with AviSynth 2.5.6.b3. I just wanted confirmation that it was the same problem, since it played fine in Windows Media Player. I'll be patient...
CyberGuy is offline   Reply With Quote
Old 10th May 2005, 18:43   #20  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
env->NewVideoFrame() already allows one to call with a negative align argument that will force a specific alignment even if it is less then the default
As a quick test, here is a hack that does this (mpeg2source() only). Someone please test it under 2.5.6b3.

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

I just did this:

PVideoFrame frame = env->NewVideoFrame(vi, -16);

EDIT: It appears I need -8 instead of -16. I'll put up another version tonight.

Last edited by Guest; 10th May 2005 at 20:52.
Guest is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.