View Full Version : 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
Boulder
8th May 2005, 18:13
Did you notice the problem with the latest Avisynth beta?
http://forum.doom9.org/showthread.php?s=&threadid=85826&perpage=20&pagenumber=5
tritical
8th May 2005, 18:57
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.
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.
tritical
8th May 2005, 22:06
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 :).
tritical
10th May 2005, 01:21
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 :D.
Guest
10th May 2005, 01:42
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.
tritical
10th May 2005, 02:46
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.
Guest
10th May 2005, 02:54
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.
"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
Gabrielgoc
10th May 2005, 15:32
neuron,
It is possible to add the sample rate to each audio stream, in the information window?
thx
Gabriel
CyberGuy
10th May 2005, 16:06
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)
Cyberia
10th May 2005, 17:16
DGDecode can output I420, just set i420=True.LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)
Guest
10th May 2005, 17:17
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.
CyberGuy
10th May 2005, 17:18
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.
Guest
10th May 2005, 17:18
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
10th May 2005, 17:20
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.
CyberGuy
10th May 2005, 17:22
Originally posted by Cyberia
DGDecode can output I420, just set i420=True.LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)
Same problem.
CyberGuy
10th May 2005, 17:28
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... :)
Guest
10th May 2005, 18:43
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.
CyberGuy
11th May 2005, 00:06
Originally posted by neuron2
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.
It still returns a Video Pitch of 736 bytes with AviSynth 2.5.6b3 when it should be 720 bytes.
LoadPlugin("DGDECODEX.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0)
Return(Source)
Cyberia
11th May 2005, 00:06
FYI: This didn't fix it.
Guest
11th May 2005, 04:44
Hellooooo?! Didn't you guys read my EDIT?
Download using the same link to get the one I just put up. It uses -8. Please test that one. Thank you!
Cyberia
11th May 2005, 05:58
Fixed
CyberGuy
11th May 2005, 06:25
Originally posted by neuron2
Hellooooo?! Didn't you guys read my EDIT?
Download using the same link to get the one I just put up. It uses -8. Please test that one. Thank you!
It works! Thanks for the quick fix. Now I notice that LanczosResize/Lanczos4Resize breaks it again, but I guess that's a post for another thread.
Guest
11th May 2005, 10:14
@CyberGuy
Please post the script that breaks. Thank you.
CyberGuy
11th May 2005, 15:21
Originally posted by neuron2
@CyberGuy
Please post the script that breaks. Thank you.
LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("VIDEO.D2V", iDCT=4, CPU=0)
Source = Trim(Source, 70, 3145)
Source = Crop(Source, 0, 76, -0, -76)
Source = LanczosResize(Source, 720, 304, Taps=8)
Return(Source)
If I comment out "Source = LanczosResize(Source, 720, 304, Taps=8)", then it plays correctly in MPlayer. The LancosResize changes the Video Pitch from 720 to 736. The original source is 720x576. If resizing to 704x304, then the video pitch is 704, so this appears to happen when width is not changed.
cw_uk
14th May 2005, 21:34
Is it possible thats theres a problem with DGIndex not flushing the last frames from a previously loaded file, Whilst backing up Agent Cody Banks i noticed on the finished file that the first frame or two was from the menu which i had loaded just to check it out before hand. the finished file had audio/video sync issues which might have been down to this. im reencoding the file now to confirm.
Guest
15th May 2005, 00:46
Originally posted by CyberGuy
The LancosResize changes the Video Pitch from 720 to 736. You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.
@cw_uk
It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.
CyberGuy
15th May 2005, 00:49
Originally posted by neuron2
You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.
It's not a problem after all, I had read in one of the forum posts mod 16, but it's actually mod 32, so AviSynth 2.5.6 is working correctly.
See: http://forum.doom9.org/showthread.php?s=&threadid=90527&perpage=20&pagenumber=2
Guest
15th May 2005, 02:44
Here is beta 4. This version corrects a decoding error caused by improper recovery from an MPEG2 syntax error (caused by corruption of a transport stream). The issue is described in this thread:
http://forum.doom9.org/showthread.php?s=&threadid=94382
Here is the fixed version:
http://neuron2.net/dgmpgdec/dgmpgdec131b4.zip
guada 2
15th May 2005, 21:32
Gently but surely. :)
I appreciate your step of work.
Thank you very much Neuron2 and long life with DGindex and the devellopor which contribute to waitings of the listeners of planet.
Goodbye ;)
cw_uk
15th May 2005, 21:49
Originally posted by neuron2
@cw_uk
It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.
Reripped it and this time all is fine no more stray few frames knocking everything out of sync, The only thing that i did diffrently though was not check the menu (Vob 0) this time. I thought the same as you to begin with but if i had forgot to remove the entire menu vob from the list i would have the entire menu appended to the beginning of the movie.
Guest
15th May 2005, 22:12
Originally posted by cw_uk
The only thing that i did diffrently though was not check the menu (Vob 0) this time. I don't know what you are talking about. "Check the menu"? That doesn't sound like a DGIndex operation.
cw_uk
15th May 2005, 22:30
Originally posted by cw_uk
Is it possible thats theres a problem with DGIndex not flushing the last frames from a previously loaded file, Whilst backing up Agent Cody Banks i noticed on the finished file that the first frame or two was from the menu which i had loaded just to check it out before hand. the finished file had audio/video sync issues which might have been down to this. im reencoding the file now to confirm.
Originally posted by neuron2
You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.
@cw_uk
It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.
Originally posted by cw_uk
Reripped it and this time all is fine no more stray few frames knocking everything out of sync, The only thing that i did diffrently though was not check the menu (Vob 0) this time. I thought the same as you to begin with but if i had forgot to remove the entire menu vob from the list i would have the entire menu appended to the beginning of the movie.
VTS_01_0 <-- menu VOB
apologies for my lack of words and effort but im off to bed and couldnt be bothered to type out a explaination.
sh0dan
16th May 2005, 11:22
Originally posted by neuron2
EDIT: It appears I need -8 instead of -16. I'll put up another version tonight.
DON'T DO THAT, unless you realign frames afterwards (by a bitblit). Planar images returned by your filter MUST have mod 16 on the Y-plane pitch. This is not guaranteed by using "-8". You risk breaking a bunch of filters that process 16 bytes/loop. Snippet from the documentation (from WorkingWithPlanarImages (http://www.avisynth.org/WorkingWithPlanarImages)):
Some (producing) filters may want to set a forced pitch. Per default, when you request a videoframe with a specific modX pitch it might be overruled by AviSynth.(You do this by using env->NewVideoFrame(VideoInfo, [alignment])) In this (very rare case), you can use a negative alignment. This will make the alignment forced.
If you force an alignment you MUST also apply the AlignPlanar(!PClip) filter after your own, otherwise your filter will not produce valid output. See source.cpp for examples.
Guest
16th May 2005, 13:36
The -8 sets up 8-alignment on the chroma and 16-alignment on the luma under the new beta.
Guest
18th May 2005, 01:29
Here is 1.3.1 beta 5. This beta adds a fully correct fix for the pitch=width assumption, thereby allowing correct operation under the current Avisynth 2.5.6 beta, as well as the stable 2.5.5 version. Our friend tritical kindly developed and contributed this code revision. Thank you, tritical!
tritical also removed the limitation of a maximum of 1,000,000 frames.
I added a fix for the emulated header problem by properly parsing the pack layer or transport layer if needed when getting the initial sequence header.
I also corrected an error in the D2V file format document.
Please beat up on this hard because the changes are extensive. Thank you.
http://neuron2.net/dgmpgdec/dgmpgdec131b5.zip
iNFO-DVD
18th May 2005, 02:17
Just tried your beta5, remember that 'green line' (earlier post) I was getting down the left side on certain clips..... well it's now gone.
Well done.
Guest
18th May 2005, 03:08
@iNFO-DVD
Thank you for your test result. That is good to know.
ccfilms
19th May 2005, 04:35
I must've missed this earlier today - downloading now. :)
jarthel
19th May 2005, 16:53
if i'm using an avisynth version prior to 2.5.6beta3., should I stick with older versions of dgmpgdec?
AlexeyS
19th May 2005, 18:36
2 neuron2
Is this possible to DGMPGDec automatically made deinterlace (all types of pulldown removal)?
I have some "problem" movies, when movie has interlaced NTSC and FILM parts. Avisynth can't make ideal deinterlace with such movie. :(
Guest
19th May 2005, 19:44
Originally posted by jarthel
if i'm using an avisynth version prior to 2.5.6beta3., should I stick with older versions of dgmpgdec? No need for that. The new version should work fine with Avisynth 2.5.5 and below. If not, please let me know. :)
Guest
19th May 2005, 19:50
Originally posted by AlexeyS
Is this possible to DGMPGDec automatically made deinterlace (all types of pulldown removal)?
I have some "problem" movies, when movie has interlaced NTSC and FILM parts. Avisynth can't make ideal deinterlace with such movie. I don't understand what you are asking for. You say you have a hybrid with mixed 24 and 30fps sections? Define how you'd like that processed and I'll tell you if it is possible.
DGDecode serves an AVI, which can have only one frame rate. You can use Force Film to remove the pulldown, but you'll get jerkiness in the 30fps sections. Decomb (and others) are designed to give you more options for these kinds of clips.
If you have a magic bullet to share with us, please speak up.
Originally posted by neuron2
If you have a magic bullet to share with us, please speak up.
You know, somehow the term "sharing a magic bullet" sounds quite painful and deadly to me... :D
*runs for cover*
ccfilms
19th May 2005, 20:42
http://www.redgiantsoftware.com/magbulsuit.html
;) Pun intended. lol.
EDIT:
For my own personal, I'm looking for a filter that does pulldown removal professionally the same way Adobe Premiere, Final Cut Pro, Sony Vegas, and Adobe After Effects and Avid Xpress Pro do it. So that I can take footage shot on, say, an XL2 or DVX100A that uses either 2:3 (24p) or 2:3:3:2 (24pa) pulldown and remove it really quickly, just like those apps do. They don't seem to need to process the DV footage (at least it doesn't seem like it) and the footage is just as crisp as a pure progressive frame and no resolution loss. And do it quickly. Actually, they do it in real time. And when you import footage into them, it says "DV (removing 2:3:3:2 pulldown)". I wonder if anyone will be able to come up with a filter that does just that to DV footage that is 24p or 24pa since it always follows one of those two specs.
But that might be a little bit too much. I think there's gotta be a way since those apps all know how to read that type of DV footage.
AlexeyS
19th May 2005, 20:43
Originally posted by neuron2
[B]I don't understand what you are asking for. You say you have a hybrid with mixed 24 and 30fps sections? Define how you'd like that processed and I'll tell you if it is possible.
I'm asking about automatic deinterlace. For example, user open MPEG2 file in DGMPGDec and DGMPGDec automatically makes best deinterlace (pulldown removal) or automatically makes sample of AVS script, such as you recommended for my Matrxi movie:
MPEG2Source("d:\Matrix\matrixhd.d2v")
telecide(order=1,post=0)
I think it will be greatest help for 95% of DGMPGDec users and especially bewbies.
DGDecode serves an AVI, which can have only one frame rate. You can use Force Film to remove the pulldown, but you'll get jerkiness in the 30fps sections. Decomb (and others) are designed to give you more options for these kinds of clips.
I've I've asked already on our local forum and heard same answer. :(
Cyberia
20th May 2005, 05:58
Deinterlacing is not the purpose of DGMPGDec. The newbiew can learn about deinterlacing plugins, and then they won't be newbies.
AlexeyS
20th May 2005, 09:08
Originally posted by Cyberia
Deinterlacing is not the purpose of DGMPGDec. The newbiew can learn about deinterlacing plugins, and then they won't be newbies.
Yes, but I still can't imagine how to know what type of deinterlace I need for movie. Also, I usually can't be 100% sure that I use right deinterlace method. :(
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.