Log in

View Full Version : DGMPGDec 1.4.9 Final


Pages : 1 2 3 [4] 5 6 7 8 9

Guest
20th January 2007, 03:54
* This version now correctly renders the video within DGIndex for streams with frame repeats. Also, Field Operation=Raw is now supported for such streams.

* Added two new fields to the info dialog: number of frame repeats, and number of field repeats.

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

PuppZ
20th January 2007, 12:17
Works fine. Thanks :-)

Guest
20th January 2007, 16:14
There's a problem with beta 12 and frame repeats. It's erroneously kicking in the field order correction. I included a check for that but it isn't working right. So turn off the Correct Field Order option when your stream has frame repeats. I'll fix that tonight.

mimage
21st January 2007, 19:24
I read a few pages back neuron2 said that vfapi has been deprecated, does this mean that it will not be included soon in future releases? Me and a few buddies of mine like to use it still for editing avs in vegas, is this not good? I edited this one music video to evangelion and I always get comments about it with people saying it's the best quality they've ever seen in an eva music video. I don't know any other better method for editing avs files that use d2vs from vobs. So can I get a bit of info on what's going on with that program? Do you prefer MakeAVIS?

Guest
22nd January 2007, 02:16
You'll notice, I'm sure, that DGVfapi is there in every new beta release. It will never go away, don't worry. The reason it is "deprecated" is that it forces conversion to RGB and it lacks some of the advanced options of mpeg2source().

You've helped a lot with DGMPGDec in the past; I wouldn't let you down. :)

mimage
22nd January 2007, 05:28
You'll notice, I'm sure, that DGVfapi is there in every new beta release. It will never go away, don't worry. The reason it is "deprecated" is that it forces conversion to RGB and it lacks some of the advanced options of mpeg2source().

You've helped a lot with DGMPGDec in the past; I wouldn't let you down. :)
Thanks! ^_^

Guest
24th January 2007, 03:45
* The Correct Field Order option is removed and the field order correction function is now available through the Tools menu: Fix D2V. I did this because this correction should not be applied to streams with frame repeats, and trying to prevent it via a code check runs into technical complications.

* A first attempt has been made to add a progress percentage field to the DGIndex window title bar.

* When in CLI mode, DGIndex no longer grabs the foreground focus and beeps at the end of a Save Project operation.

* Fixed a bug in the LumaYV12() filter (part of DGDecode) that could cause a crash in some circumstances.

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

Guest
24th January 2007, 03:48
and what about a check box in the save window ? I just don't see minor GUI changes as worth my limited time. Sorry.

Zarxrax
25th January 2007, 20:28
Are the frame repeats only found in HD material? If that is the case, couldn't you leave the automatic d2v fixing only for DVDs or standard definition video?

Guest
26th January 2007, 01:52
Any MPEG2 stream can have frame repeats.

G_M_C
3rd February 2007, 00:11
Hey Neuron2, about my last remark (about the "hanging of DGindex when selecting a .TS). It proved to be a problem in BitDefender. An update of the scanner solved the problem.

But, i might have found somthing else;

I've recently bought myself the DVD of Pink Floyd latest tour; The P.U.L.S.E. DVD (i've been seen that concert/tour, i'm TA+HAT old ;) ). I wanted to make a back-up of the DVD, but fopund out that DGIndex doesnt recognise the 2nd audio-track correctly.

The DVD has 3 audio tracks;
1 - DD AC3 3/2 - 448 kbps
2 - DD AC3 3/2 - 640 kbps
3 - DD AC3 2.0 - ??? kbps

The problem is that DGindex doesnt recoginse the 2nd track as 640, it says it's 448 kbps. DGindex even says ALL tracks are 448 kbps, even the 2.0 track (The DVD-cover and the audio-menu all say it 640, dont know how to check with something else).

Hope you can find out what's up, and succes with the development :)

Guest
3rd February 2007, 00:39
The cover could be lying/incorrect. Please provide an unprocessed VOB fragment that can use to duplicate the issue.

Pashator
3rd February 2007, 08:02
No, it's really 640, I can confirm this. I have original if you need I can provide you with a sample.

Guest
3rd February 2007, 14:33
Yes, please provide the VOB fragment as I already asked for above.

shon3i
10th February 2007, 17:39
@neuron2, any chance to make dgdecode.dll work on Vista 32bit.

mvdzwaan
10th February 2007, 19:15
@neuron2, any chance to make dgdecode.dll work on Vista 32bit.

DGDecode already works on Vista 32bit

shon3i
10th February 2007, 20:15
Well, not i my case, every time when i load avs script into virtualdub, megui, or other program, i got error message, dgdecode unable to open d2v file.

I am using, Vista RTM, Avisynth 2.57 and DGIndex 1.4.8 from MeGUI Auto Update.

Did 1.4.9 works?

mvdzwaan
10th February 2007, 20:35
Well, not i my case, every time when i load avs script into virtualdub, megui, or other program, i got error message, dgdecode unable to open d2v file.

I am using, Vista RTM, Avisynth 2.57 and DGIndex 1.4.8 from MeGUI Auto Update.

Did 1.4.9 works?

I did have major problems, and have reverted to avisynth 2.56 (directshowsource with wmv file problems). I also had to add a registry setting to get WMP11 to play avs files.

Guest
10th February 2007, 21:38
@neuron2, any chance to make dgdecode.dll work on Vista 32bit. If you can contribute a legal copy of Vista to me, I'll be happy to investigate it.

shon3i
11th February 2007, 00:15
If you can contribute a legal copy of Vista to me, I'll be happy to investigate it.
Well, i can give you mu serial number, but you can activate it, because i alredy activate it, but you have 90 days without activation, plus i can give you working crack.

pinkie_1
11th February 2007, 00:54
a legal copy of Vista
i can give you working crack
and, finally...
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature, asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.
Is it that hard to read/understand/abide by a simple set of rules ?

Guest
11th February 2007, 01:48
@shon3i

I appreciate your offer but will decline based on rule 6 and my own ethics as a developer.

As an alternative, are you willing to work with me, testing debug builds, etc.? Thank you.

The Scientist
11th February 2007, 02:56
If a sample of the VOB file is available I can test. I have Vista x86 latest AVISynth and DGIndex e.t.c., never had any problems with either.

shon3i
11th February 2007, 11:51
@shon3i

I appreciate your offer but will decline based on rule 6 and my own ethics as a developer.

As an alternative, are you willing to work with me, testing debug builds, etc.? Thank you.
OK, neuron, i will help you much as i can.

Guest
11th February 2007, 14:46
Well, not i my case, every time when i load avs script into virtualdub, megui, or other program, i got error message, dgdecode unable to open d2v file. Please post a screenshot showing the error. I ask because what you cited does not exist as a string in DGDecode, so I cannot locate the error point in the code.

I assume you have triple checked the obvious stuff, like you typed the path wrong?

mvdzwaan
11th February 2007, 18:39
Please also look at my post in the 'Avisynth usage' group about vista and avisynth problems.

I had to perform a registry trick to get my programs to recognize avs files.

Guest
11th February 2007, 20:56
* Adding checking for audio file names to not be already open in another application before trying to demux to them.

* Added a new tool in the Tools menu: Analyze Sync.

* Revised the indexing code to support the case where an indexed unit (especially packs) might contain more than one I frame. Previously random navigation in DGDecode failed for this rare scenario.

* D2V file format is bumped to 16.

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

Please give this a good workout because random navigation has changed. There is now a "skip" field in each D2V file data line right after the position field. The DGIndex users manual explains its purpose.

Terranigma
12th February 2007, 16:40
Thanks for the Update. :)
I'll be testing Analyze Sync A.S.A.P.

mrcoolboy15
13th February 2007, 03:07
Will this program change the stream on an mpg2 file?

MacAddict
18th February 2007, 16:55
Analyze Sync looks pretty cool although I haven't put it to work yet. The 'log time stamps' setting doesn't seem to stick after I exit the application and open it back up. Anyone else? Maybe this is normal behavior.

Guest
18th February 2007, 19:31
The 'log time stamps' setting doesn't seem to stick after I exit the application and open it back up. Anyone else? Maybe this is normal behavior. From the users manual:

"Note that this option setting is not stored in the DGIndex INI file."

MacAddict
18th February 2007, 19:42
Thanks Donald, sorry for the false alarm. Been awhile since I read the manual, think I'll have a look later this afternoon.

Wilbert
18th March 2007, 20:53
A possible bug in 1.4.8 (and probably also in latest beta):

http://forum.doom9.org/showthread.php?p=972296#post972296

When saving a frame to BMP, the colorimetry info is not used. I suspect Rec.601 is used (when converting to BMP) )in the examples in that post (screenshots of HeadBangeR77 in the post above the linked one), but the extension field of the m2v is empty:

http://xasonline.info/headbanger/BlackPearl.m2v

HeadBangeR77
18th March 2007, 21:53
I can confirm that with 1.4.8, 1.4.9 beta7 and beta14. Since there was no colorimetry info in the source stream, the DGIndex /DGDecode used to assume ITU-R BT.709, yet now both the preview and saved screen grabs look as if it was Rec.601 (info window showing ITU-R BT.709 though).

@ neuron2:
For me both the preview and the BMPs I've taken look exactly the same. Yet the supposed or real colorimetry is not used. I think that's what Wilbert meant above.

Guest
19th March 2007, 14:41
When saving a frame to BMP, the colorimetry info is not used. The Save BMP code simply outputs the preview screen. There is no additional processing. The two should always be the same. Are you saying that you can demonstrate an instance when they are not?

Guest
19th March 2007, 14:51
I can confirm that with 1.4.8, 1.4.9 beta7 and beta14. Since there was no colorimetry info in the source stream, the DGIndex /DGDecode used to assume ITU-R BT.709, yet now both the preview and saved screen grabs look as if it was Rec.601 (info window showing ITU-R BT.709 though).

@ neuron2:
For me both the preview and the BMPs I've taken look exactly the same. Yet the supposed or real colorimetry is not used. I think that's what Wilbert meant above. I gather you are saying DGIndex 1.4.7 does it the way you expect and 1.4.8 and later do not. Is that correct? If so, please point me to a stream I can use to see that.

I don't see any code difference that could explain it. Are you sure you have the Video/YUV->RGB option set correctly? You can see that toggling it changes the preview colors.

Guest
19th March 2007, 15:03
Save BMP output from 1.4.7 and 1.4.9 for BlackPearl are binary identical.

So, no problem found. Please advise how to duplicate your issue.

HeadBangeR77
19th March 2007, 17:03
Save BMP output from 1.4.7 and 1.4.9 for BlackPearl are binary identical.
So, no problem found. Please advise how to duplicate your issue.
Hello,

No, I used to have some ancient version, that I can't recall atm (sorry) - it wasn't 1.4.7 for sure.

To clear the things a bit:
The output with 1.4.8 and 1.4.9 is identical to that without ColorMatrix(mode="Rec.709->Rec.601"), while the stream is supposed to be ITU-R BT.709 (see the screenshots in the thread linked above). It was Wilbert who used to have different results with 1.4.6 - they were identical to those with ColorMatrix. So I can only assume it happened somewhere between 1.4.6 and 1.4.8, because after he had installed 1.4.8 he started to get the same results as I was getting. If you need any additional info, plz let me know. Also, it would be good Wilbert joined this thread again, since it was him who has discovered the difference.

cheers,
HDBR77

Guest
19th March 2007, 19:50
To clear the things a bit:
The output with 1.4.8 and 1.4.9 is identical to that without ColorMatrix(mode="Rec.709->Rec.601"), while the stream is supposed to be ITU-R BT.709 That's not clear.

Output without 709->601 should be 709, which is what you claim the stream specifies. And you're complaining that DGIndex shows it as 709???

Please clarify your clarification. :)

HeadBangeR77
19th March 2007, 20:42
Output without 709->601 should be 709, which is what you claim the stream specifies. And you're complaining that DGIndex shows it as 709???
Wilbert, where are you?
:D :D :D

Please clarify your clarification. :)
Sorry, I wasn't precise again. Those conversion matters have caused a lot of mind-boiling recently. ;)
The output I'm getting with DGIndex 1.4.8 & 1.4.9 is identical to (here we go ;)) :
AVSP preview and VDub preview, as well as to sample encodes without ColorMatrix(mode="Rec.709->Rec.601").

Wilbert says the colours are improperly scaled then, and I'm getting the wrong colorimetry (see the thread he has linked). He used to get different results from mine with DGIndex 1.4.6 (as in previews/encodes with the above conversion), and after installing 1.4.8 it's changed.

Neuron2, excuse me if I'm not clear again - I ain't a complete noob, yet I'm new to ColorMatrix, and I'm completely puzzled atm (especially since I'm sure Wilbert must be right as to technical matters, though I like my results better i.e. I find them more naturally looking, at least to my eyes).

cheers,
HDBR77

PS.
Wilbert's screen shots (http://forum.doom9.org/showthread.php?p=971796#post971796) and
... and mine. (http://forum.doom9.org/showthread.php?p=972274#post972274)

PS2. I see some kind of discussion is carrying on in the ColorMatrix thread. I really don't want to cause any more fuss, so unless Wilbert appears to clear the matter, just plz ignore the "issue". ;)

PS3. Hope he has made things much clearer than I did. ;)

Wilbert
19th March 2007, 20:54
Save BMP output from 1.4.7 and 1.4.9 for BlackPearl are binary identical.

So, no problem found. Please advise how to duplicate your issue.
I used 1.4.6 and 1.4.8 (dunno about 1.4.7).

The bmp from 1.4.6 looks exactly the same as AviSynth with ConvertToRGB(matrix="Rec709"). The bmp from 1.4.8 looks differently (i think it looks like ConvertToRGB(matrix="Rec601")). Note that DGIndex reports it as Rec.709 in both cases, which is good afaics.

This is what HeadBangeR77 meant, but i simplified it a bit :)

Guest
19th March 2007, 21:28
OK, 1.4.6 versus 1.4.8. I will check it tonight.

Guest
19th March 2007, 22:50
I found the bug. DGIndex is indeed using 601 for its preview and BMP when it should be using 709. But the Info window is OK.

The problem is that he defaults to 601 until he sees an MPEG2 sequence extension and then he changes the default to 709. But he sets the values via setRGBValues() in between those two events and doesn't call setRBGValues() again after the sequence extension() arrives.

I'll fix that and release a new beta later tonight. I'll also check that DGDecode isn't afflicted the same way. I think it isn't but I'll check it to be sure.

Thanks for pointing this out.

Wilbert
19th March 2007, 22:54
I'll fix that and release a new beta later tonight. I'll also check that DGDecode isn't afflicted the same way. I think it isn't but I'll check it to be sure.

Thanks for pointing this out.
Thank you very much!

HeadBangeR77
20th March 2007, 02:49
Glad it's been cleared. :)
And waiting for a new beta. ;)
cheers,
HDBR77

PS. It's already here - thanks a bunch!

Guest
20th March 2007, 06:46
* Fixed a bug that caused DGIndex to sometimes use 601 colorimetry in the preview window and when doing Save BMP when 709 should have been used. The Info Dialog was correct, however.

* Added support for M2TS (Blueray Disk MPEG2) files.

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

Terranigma
20th March 2007, 15:59
Wow! Thanks neuron2 :cool:

Guest
21st March 2007, 02:09
* Fixed incorrect audio demuxing for M2TS files. At this time AC3 is known to be good. All other formats are untested but may work.

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

ACrowley
22nd March 2007, 10:02
* Fixed incorrect audio demuxing for M2TS files. At this time AC3 is known to be good. All other formats are untested but may work.

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


DTS Tracks are not suppoted on m2ts ?
Dgindex can detect the dts Audio from KingdomOfHeaven m2ts.

And one question :
When i load to m2ts Streams into gdindex, both m2ts which contains the movie in 2 streams, is it safe to create one d2v for encoding ? Are the m2ts joined properly in the d2v ?

I think so, the runtime of the d2v is correct

greets

Guest
22nd March 2007, 13:15
DTS Tracks are not suppoted on m2ts ?
Dgindex can detect the dts Audio from KingdomOfHeaven m2ts.
I clearly said anything other than AC3 is untested but may work. I can't test it because I don't have an M2TS stream with DTS. Would you like to provide one?

It is safe to concatenate by loading multiple files if they all have the same properties.