DGMPGDec 1.4.3 Final!

[mic]

They can come as text or bitmap formats. The bitmap formats must be converted to a text form using OCR. A program called SubRip does this, and it can directly extract from the Vobs.

Is Close-Captioning also considered a 'subtitle'? Or does it have yet another stream(s)?

You'll probably have to parse the IFO file to get languages, but this has the advantage that you can also get the AUDIO languages identified too.
Subs are an overlay video track of sorts on a DVD, so you'll always get a stream. It can be OCRed to convert to text, but as when stripping an ac3, you don't always need to. As far as other prog. that strip sub streams, think they do it as DGIndex does tracks -- let the user decide which is which, sort them out.

As far as CC on DVD, there is often a stream, plus CC being stored in the mpg2 itself. Vobsub I think can strip the stream -- I'm unsure if there's a way to access that part stored in the mpg2 other then parsing it with Graphedit (see SCC Tools site).

While CC data is text, it can require a bit of editing to suit a lot of folks. This is changing (or has changed?) with newer DVDs & even digital cable etc. using same basic text as subs, ending the biggest hassle of all, converting from all caps. And that's one difference between subs and CC, the other being the inclusion of sound effects or cues, which are a trivial matter to remove in Subtitle Workshop.

[tritical]

Sure, I'll do it tonight. I don't care too much about backwards compatibility for upConv. I never liked the name anyway.
If you're gonna change it, could I also suggest the ability to have dgdecode output rgb24 as well as yuy2? I've been looking at the other color conversion routines in dgdecode (422->444 and 444->rgb24), and the 422->444 routine is ok except it needlessy duplicates 7 pixels on the right side of the image instead of interpolating, also an isse version could be significantly faster than the current mmx routine. The 444->rgb24 routine is ok except that it always uses BT.709 coefficients instead of following the matrix_coefficients value. Currently those issues would only effect dgvfapi or anyone using the methods at the bottom of AVISynthAPI.cpp. I've got a fix for the 422->444 routine and made an isse version, wondering if I could get the current source to play with? Thanks

[Guest]

How's about I give you the 141b5 source and you can make all the changes? :)

[Guest]

@tritical

Here is the source code for 141b5:

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

@all

This is not an official release. Please do not redistribute it. Thank you.

[Guest]

Version 1.4.1 beta 6 includes various changes/fixes for upsampling by tritical. These apply as appropriate for DGDecode, DGIndex, and DGVfapi:

* upConv can now be set to 3 values: 0, 1, and 2. 0 = do nothing,
1 = YUY2 output, 2 = RGB24 output... for the case that the input is 4:2:2
then 1 is the same as 0.

* Added iCC parameter. iCC=true uses interlaced YV12->YUY2 upsampling,
iCC=false uses progressive YV12->YUY2 upsampling, and leaving iCC unset
makes it switch based on the progressive_frame flag.

* Fixed a little problem with the 422->444 conversion, fixed a problem with
the 444->RGB24 conversion where it wasn't correctly handling pixel values
that came out as < 0, and added a faster isse 422->444 conversion. I also
modified the 444->RGB24 conversion so that it uses the correct coefficients
(indicated by the matrix_coefficients value).

* Added a way to force DGVfapi (and the DLL access functions) to follow
the progressive_frame flag.

* Added a Colorimetry box to the DGIndex Info dialog.

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

Thank you, tritical!

[Guest]

Version 1.4.1 beta 7 provides these major changes:

* Top-level picture decoding (slice and macroblock layers) was completely
redesigned to dramatically improve resilience to video errors, and to correct
some spurious video errors due to bugs in the old approach. The previous
design is a legacy of the original MSSG reference decoder, and was inherited
from DVD2AVI. The new design was adapted from fccHandler's
excellent VirtualDub MPEG2.

* Modified the Info dialog display of video errors to show text reasons
instead of numbers.

This version solves the known outstanding issues with "weird blocks". However, it required a major re-write, actually performed twice, once for DGIndex and once for DGDecode. Although I was very careful and regression tested things for several hours, there could be new minor problems introduced. This version is close to what I want for 1.4.1 final, so your feedback will be greatly appreciated.

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

EDIT: See post below!

[Guest]

Oops. If you downloaded before this current post, please redownload. I had uploaded a local hack (to test no-I-frame streams) instead of the real beta. :)

[Chez_Wimpy]

Sorry if this was asked before, but I just upgraded after a long interval, and I noticed that with DGIndex (as compared to dvd2avi) that the most recent directory saved to (for "Save Project") is not remembered. This is a minor nit, but is it possible to include an option to make it default to the used last directory? Thanks for a great piece of software (and the constant updates!).

[Guest]

I just fixed that last night after Jem pointed it out at my forum. It was a result of adding the default save path feature. It will be in the next beta/RC.

[Zep]

wow great work you two (three?) Just keeps getting better and better
by huge leaps and bounds!


Thx for all the hard work!



Zep

[Guest]

Let's get this puppy out the door! Version 1.4.1 RC1 provides these changes from 1.4.1 Beta 7:

* The Save Project path is now properly saved.

* Added "fccHandler" to the credits listing in the DGDecode manual.

* Revised the playback speed option. It now gives 5 checkable menu
choices: super slow (5fps), slow (10fps), normal (plays reliably at the
correct frame rate for the stream), fast (2 times normal), maximum (as fast
as possible).

* A warning box is popped up if Force Film is used inappropriately. The user
can decide whether to proceed anyway or to cancel.

* The leading number on the file path lines at the top of the file was
eliminated. This makes editing the D2V file to change paths easier. The D2V
file format version is therefore bumped to 11, and you will need to remake
existing projects.

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

[Guest]

wow great work you two (three?) All the users who kindly provide feedback need to be acknowledged too.

You're just in time for 141RC1. Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).

[fccHandler]

* Added "fccHandler" to the credits listing in the DGDecode manual.
*blush*

I don't think I've ever thanked you for DGMPGDec. I don't do much DVD ripping, but if I did I wouldn't dream of using any other tool. Thanks!

[SeeMoreDigital]

Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).The revised playback features work very well indeed now... many thanks.

Given that we now have the "Super Slow" feature. Would it be possible to include "Frame Accurate Seeking" by using main slide bar and the keyboards "left" and "right" arrows, while the Preview box is still open?


Cheers

[scharfis_brain]

I have a feature request for DGindex.

I like to create demuxed sound and video off a DVD-ROM-Drive with dgindex.
But after creation of the project file/demuxing, I need to re-run DGindek over the demuxed m2v again, because the initially written d2v-project file refers to my DVD-ROM-Drive instead to the demuxed m2v.

[Guest]

Given that we now have the "Super Slow" feature. Would it be possible to include "Frame Accurate Seeking" by using main slide bar and the keyboards "left" and "right" arrows, while the Preview box is still open? That thought occurred to me as well. The mechanism for pacing playback just inserts a delay before displaying each frame. So if the delay is changed to a wait for a button to be pressed, we could have single-stepping forward. But it would not allow for stepping backward, nor would it allow for performing the other actions that frame accuracy implies, such as arbitrary cut points. However, if it was thought useful, it might be worth adding a new mode called Single Step, and then enabling the right arrow button when in that mode.

Another problem that should probably be fixed, because this mode would make it more noticable, is the possibility of displaying a few macroblocked frames at the beginning of a play/preview. This occurs because the full random navigation code of DGDecode is not present in DGIndex. But adding that code would begin approaching full frame accuracy and would mitigate the need for the single step mode described above.

So I'm still thinking about where to go with this.

[buzzqw]

@scharfis_brain

you can edit the d2v changing the path of m2v... (last time i used this trick the d2v resulting was OK)

BHH

[Guest]

I like to create demuxed sound and video off a DVD-ROM-Drive with dgindex. But after creation of the project file/demuxing, I need to re-run DGindex over the demuxed m2v again, because the initially written d2v-project file refers to my DVD-ROM-Drive instead to the demuxed m2v. Why does it matter? The video served by DGDecode will be the same in both cases. I'm missing your point.

[xDrJx]

Don't know if this belong here but I do know it's more then deserved: :thanks: for all the hard work, it's more then appreciated
:thanks: again

[Guest]

you can edit the d2v changing the path of m2v... (last time i used this trick the d2v resulting was OK) No, because the file offsets recorded in the D2V will be wrong. Linear play from the start might be OK, but random access will be totally screwed up.

scharfi's idea could be difficult to implement. I'll think about it but I am not optimistic.

[SeeMoreDigital]

... we could have single-stepping forward. But it would not allow for stepping backward, nor would it allow for performing the other actions that frame accuracy implies, such as arbitrary cut points. However, if it was thought useful, it might be worth adding a new mode called Single Step, and then enabling the right arrow button when in that mode..... So I'm still thinking about where to go with this.Thanks for the reply.

A "Single Step" forward (or Frame Advance) mode would be very useful for what I use DGIndex for. Would it be possible to make the main slide bar active also? So if you miss the frame you want, you can go back and try again.


Cheers

[Guest]

Would it be possible to make the main slide bar active also? So if you miss the frame you want, you can go back and try again. No, that would require too much hacky stuff. You'd have to stop preview, navigate, and start again.

[Inc]

* The leading number on the file path lines at the top of the file was
eliminated. This makes editing the D2V file to change paths easier. The D2V
file format version is therefore bumped to 11, and you will need to remake
existing projects.

Hi Donald,

I think thats quite a big change for other Apps. which in their state now do parse the resulted d2v for accessing the used source VOB(s). Im not shure but some Apps do readout the d2v at the given line and parse the VOB file for getting informations of the stream which aren't served by openMPEG2Source() i.e..
In most programming Environments does exist a command for eleminating Letters in a string at a given startpos. using a given count, so I think there would be less trouble for exisiting Apps. then just using a string handling command when coding.

;)

Thanks

[Guest]

@incredible

I cannot decipher what you are suggesting or asking.

If you are objecting to a change in the D2V file format, be advised that there have been several since the apps you mentioned were created. If they want to be compatible with the latest DGMPGDec, then they will have to be revised. I cannot halt evolution just because some third-party apps exist.

If you are objecting to the loss of the count field, be advised that it can be easily regenerated programmatically by using strlen().

[len0x]

I was wondering, if CLI was updated to allow multiple audio tracks to be demuxed in one go - does it make sense to do the same for audio PIDs in transport streams?

[Amit]

@neuron2,

I ran the latest build v1.4.1 Beta 7 on a very peculiar movie (NTSC R1). This is an interlace movie but has RFF flags which are playing with the field order. You can get a sample clip and more information at http://forum.doom9.org/showthread.php?t=98921

I would like to see this kind of support in your program since you are basically improving and doing things that original DVD2AVI cannot do.

TIA
-Amit

[Guest]

I would like to see this kind of support in your program Old news; it's already there: Tools/Fix D2V.

[Guest]

I was wondering, if CLI was updated to allow multiple audio tracks to be demuxed in one go - does it make sense to do the same for audio PIDs in transport streams? And multiple video demuxing, too, right? :)

Is this something you really need, or are you just epitomizing Emerson's hobgoblin?

[len0x]

Mutiple video demuxing? Nah :) As a matter of fact I don't find video demuxing a particulary useful feature at all.

About audio: I'm not sure how many people actually process multiaudio TS, but in Europe its pretty common I guess to have multiple languages in digital broadcasts, so if people want to keep some of them then its useful to be able to demux multiple ones. But its not something crucial to the process that I really need - just a thought since normal audio demuxing was improved this way.

[midnightsun]

Hey there neuron2,

would it be possible for dgindex to have the capability to write a .txt-like file of all the I-frames positions in a given video stream? Some sort of "parse .D2V and write I-frames' positions" option; something like

0
12
24
36
44
56
68
78
90
......

[Guest]

would it be possible for dgindex to have the capability to write a .txt-like file of all the I-frames positions in a given video stream? Some sort of "parse .D2V and write I-frames' positions" option Tools/Parse D2V already makes this information available, e.g.:

[GOP]
15 [B]: 15,15...................2
16 [B]: 16,16...................2
17 [I]: 17,17...................2
18 [B]: 18,18...................2
19 [B]: 19,19...................2
20 [P]: 20,20...................2
21 [B]: 21,21...................2
22 [B]: 22,22...................2
23 [P]: 23,23...................2
24 [B]: 24,24...................2
25 [B]: 25,25...................2
26 [P]: 26,26...................2
27 [B]: 27,27...................2
28 [B]: 28,28...................2
29 [P]: 29,29...................2
[GOP]
30 [B]: 30,30...................2
31 [B]: 31,31...................2
32 [I]: 32,32...................2
33 [B]: 33,33...................2
34 [B]: 34,34...................2
35 [P]: 35,35...................2

If you are looking for the specific output format you've given, then you could write a simple utility to generate it from the Parse D2V output, for example (using 'awk'). What is the motivation?

[zettai]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5

I've uploaded a demuxed section which should show the problem on frame 150 or so. Look for file VTS_28_PGC_01_1.demuxed.m2v on the ftp to confirm. This problem doesnt appear when using virtualdubmod to load the m2v.

I dont know if this is also a problem with older versions of dgindex yet.

[Esc]

Hi Donald,
I have a problem with RC1. If I drag the scroller with mouse, the information window is closed. I really hope it's not a new feature. :)
Thanks for the great work!

[Guest]

Hi Donald,
I have a problem with RC1. If I drag the scroller with mouse, the information window is closed. Yes, it's a new feature. The information is intended to be valid only during a play/preview operation. What were you using it for?

[Guest]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5

I've uploaded a demuxed section which should show the problem on frame 150 or so. Look for file VTS_28_PGC_01_1.demuxed.m2v on the ftp to confirm. This problem doesnt appear when using virtualdubmod to load the m2v. I see that the first two frames are bad because the stream claims that the first GOP is closed but it isn't. If it was properly marked as open, then they would be replaced with the first decodable frame. VirtualDub MPEG2 just discards those frames.

But I don't see any blocking at or around frame 150. Please give me your script and tell me the exact frame number. Also give me the DGIndex settings. I'm not reproducing the problem. A screenshot of the blocking would be useful, too.

[Guest]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5. The problem is that every GOP is marked as closed when they aren't. Did you rip this directly off a commercial DVD? I need to know the origin of this VOB before deciding what to do. Is it something you encoded and erroneously forced the setting of the closed GOP flag?

Technical note: If the GOPs are closed, DGDecode doesn't need to decode the previous GOP when trying to decode randomly-accessed leading B frames. But your stream has leading B frames that require the previous GOP, but the GOPs are marked as closed. So strictly it is a bad stream. I could work around it by always assuming GOPs are open, but that would degrade responsiveness of random access.

This problem is present in previous versions because it is in fact a stream problem.

Note that this affects only random access; it doesn't occur if you just play linearly from the start, so your encodes will be OK.

Finally, it's possible to edit the D2V file to make it work (clear the bits that say the frames don't require the previous GOP). It might be worth adding a utility to do that.

[zettai]

It's a commercial DVD I'm afraid. Plus, I actually need to be able to view this with random access if at all possible as I'm editing it in a NLE. I'd be happy to hack the d2v file if that will fix the problem.

[Guest]

OK. I'll add a new entry to the option menu tonight and release a new RC.

[Esc]

Yes, it's a new feature. The information is intended to be valid only during a play/preview operation. What were you using it for?
Those PGC numbers are very handy for tracing anime episodes that are recorded as 1 program. I would slide the scroller looking at them. And if I see 1-3, 1-4, etc., then I am still on ep1. If they have switched to 2-1, 2-2, it's time to stop and go back. Eventually I zero out on the moment where first 1 becomes 2 and it's the best place to cut off the first episode. I mark this point as the end of selection, make my d2v and continue with the second ep, and so on.
Why don't you just blank the incorrect information at the time of scrolling? Isn't that what you used to do in earlier versions, anyway?

[Guest]

@zettai

Try Version 1.4.1 RC2:

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

Set the "Force Open GOPs in D2V File" option before saving your project.

[Guest]

Those PGC numbers are very handy for tracing anime episodes that are recorded as 1 program. Would you be happy if that information appeared in the DGIndex window's title bar?

[Esc]

Would you be happy if that information appeared in the DGIndex window's title bar?
I just need the information. I don't care where does it come from as long as it's usable. :D
How about using status bar instead, btw?

[Guest]

I just need the information. I don't care where does it come from as long as it's usable. I'm going to pretend that you said "That would be fine. Thank you very much."

[Esc]

THANK YOU A GREAT BUNCH! Your work is valuable beyond all limits. DGIndex is one of the most useful utilities in video processing and I praise your talent and dedication every time I open it. I had no intention of offending you since I fully comprehend the fact that your work is one hundred percent voluntary and unrewarded.
I humbly suggest using status bar though. But only because I think it would look cooler and not overcrowd the title bar. Of course, if it is not too much bother.

[Guest]

What have we here?

* New DGIndex users manual created by Cyberia.

* VOB/CELL IDs now displayed in the title bar.

* Log quant matrices menu item moved to Options.

Thank you Cyberia, for the great users manual!

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

[Zep]

All the users who kindly provide feedback need to be acknowledged too.

You're just in time for 141RC1. Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).

Avery is helping out now too? wow you have one heck of good team i must say :)

What is funny I DL a new version come back 2 days later and there is a
newer version. I can't keep up! (that is a VERY good thing lol )

Thx

[SeeMoreDigital]

Avery is helping out now too? wow you have one heck of good team i must say :)Agreed.... I use DGindex all the time for my part-time projects... I don't know where I'd be without it...

Many, many, thanks guys

[zettai]

Just to let you know, my problems are now fixed with the new GOP options. Thanks!

[Guest]

Avery is helping out now too? Not formally as in contributing code. I had posted at the VirtualDub forum asking how he achieved playback pacing in VirtualDub, and he responded with some valuable ideas. Here is the posting for those interested to see it:

http://forums.virtualdub.org/index.php?act=ST&f=11&t=9985

[Cyberia]

Thank you Cyberia, for the great users manual!

Gonna make me blush. :p

Thank YOU for the great work!