DGMPGDec 1.5.3 Final

[Guest]

* Pop-up warning message boxes are now suppressed for CLI operation.

* PSIP PID detection has been added.

* PIDs are now displayed in decimal as well as hexadecimal.

* A new option, Looped Playback, was added. When the end of the timeline is reached during a Play or Preview operation, playback is automatically restarted at the beginning of the timeline.

* A bug was fixed in the transport packet length detection code. This caused some M2TS streams to be parsed incorrectly.

* The file type .m2t was added to the open dialog.

* Some array sizes were increased to prevent crashes in the debugger.

* The next_start_code() function was enhanced to add error resiliency for abnormal slice terminations.

* Because the code never writes to the DirectDraw surface anymore (removed long ago!), the DirectDraw Overlay option was removed. DGIndex now never seizes the overlay.

* When the Use Full Paths option is turned off, relative paths are used. This allows for the source files to be in a different directory than the D2V file. If they are in the same directory, the behavior is the same as before.

* In CLI mode, if a field order transition is detected, it is silently corrected.

* Fixed two problems with .m2ts files: 1) audio on PRIVATE_STREAM_1 was not processed correctly, and 2) video demuxing was broken.

* Fixed a problem that resulted in an abort of processing with the message box popup "Force film mode is not supported with frame repeats".

* Removed the limitation that the AVS and D2V files must be in the same directory when the Use Full Paths option is disabled. Thanks to Rainy for showing the way.

* Added checks for extra robustness against emulated audio start codes for MPEG audio in program streams. This fixes some known streams with emulated audio start codes.

* The infamous GOP warning popup has been removed. The D2V Parse log now shows the open/closed status of the GOPs, so if you need to know if your opening GOP is open, look there.

* The Info dialog position is no longer pegged to the main DGIndex window. It can be independently positioned and its position is saved and restored via the INI file. Also, its font size has been decreased and all the group boxes are now arranged vertically.

* An option was added to control how HD videos are displayed. You can now shrink by half (the previous behavior) or you can view any quadrant of the video. This allows the interlace structure of HD videos to be inspected.

* Fixed a problem that caused DGIndex to miss some audio streams. For example, if AC3 substream 0x80 was present, and MPA stream 0xC0 was present, both would be viewed as Track 1, and only the first one encountered would be detected. The concept of track number is removed (as it is a DVD-specific construct), and it is replaced with the concept of audio id. See the users manual for details.

* For MPEG audio streams, the Info dialog now shows full information: audio id, layer, number of channels, sampling rate, and bitrate. This information is also included in the filename of demuxed MPEG audio streams.

* Whenever the Info dialog is closed, a log file is (optionally) created that contains the same information. This may be invoked by the CLI to silently query the nature of the input file. Please see the users manual for details.

* When a stream does not declare the colorimetry, matrix_coefficients=1 is assumed for HD video and matrix_coefficients=5 is assumed for SD video.

* Fixed a bug that caused automatic PID setting for transport streams to use the last audio stream encountered instead of the first.

* Added an MRU list to the File menu.

* Leading B frames for field structure streams were not counted correctly, causing a possibility to display bad starting frames when serving with DGDecode. Fixed.

* Fixed possible crashes when exiting DGIndex while a play/preview is in progress.

* DGIndex no longer beeps and brings its window to the foreground when a Save Project operation is complete.

* The quants displayed by DGDecode's showQ=true did not match the avg/min/max values displayed for info=1 (the showQ display was not re-ordered for display order). Fixed.

* Only half a screenful of values were shown with showQ=true for field structure streams.

* The funny transparency for the showQ display was fixed.

* The Info display now shows the picture coding type (I/P/B).

* Added a maximum bitrate field to the Info display.

* Demuxed MPEG audio files are now given the extension mp1/mp2/mp3 depending on the audio layer. The old behavior can be enabled via an INI file option (see users manual).

* Transport packet resync and M2TS file detection were made more robust.

* Fixed a bug in the Log Timestamps function, whereby a video DTS value was incorrectly shown as a PTS value.

* Fixed a bug in demuxing of DTS audio from transport streams.

* The aspect ratio field of the Info dialog now shows the raw value of the field as well as the corresponding string.

* The display size from a sequence_display_extension is now shown in the Info dialog. This, together with the change above, allows the sample aspect ratio (SAR) to be inferred, according to the MPEG2 specification.

* A default path for saving BMPs can now be specified.

* Fixed a bug whereby tracks selected for demuxing in the INI file were not actually enabled for demuxing until the track selection dialog was saved. Now they are honored on startup as they should be.

* Fixed the CLI to also parse for the = sign at the end of the options to avoid false option detection. E.g., the substring '-aif' anywhere in a file name would be parsed as an option specification.

* Other miscellaneous CLI parsing bugs fixed.

* When doing a preview via the CLI, the playback speed is set to maximum.

* When a Play/Preview/Save Project Operation begins, the focus is now left on the main window. Previously, it annoyingly moved to the Info window.

* Don't check for field order transitions for streams with only frame repeats.

* Use lowest numbered audio ID to expand __aud__ instead of the first audio stream encountered in the source files.

* Fix parsing with log timestamps enabled.

* Correct handling of default matrix coefficients for hints.

* Add option for beeping and focusing when save project finishes.

* Save BMP is now enabled during play/preview.

* Fix regression in transport stream detection.

* The Full Paths option is now honored for CLI invocation.

* Fixed the audio delay calculation, timestamps dump, and analyze sync tool for streams that do not contain GOP headers.

* The analyze sync tool now prompts for the audio ID instead of a track number.

* Fixed incorrect audio demuxing when demuxing audio only.

* Fixed display of field order for field structure streams.

* Fixed bug: Open file, Save Project, then File -> Open -> OK gives an error messge.

* Fixed bug: Save project with decode AC3 to WAV. Repeat that. Each time the WAV file becomes longer. The size was not reset to zero.

* Fixed a problem that caused some program streams to be detected as transport streams.

* Fixed a problem with video demuxing that sometimes caused an extra partial first GOP to be demuxed at the start of the stream.

* Added mousewheel support.

* Added a -RG option to the CLI (define project range).

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

[3ngel]

It seems to work.

I have two question:

Can you add the ability to recognize DTS-HD MA?
You have an example in the stream i sent to you.

It's possible to add the ability to "Select the Main Movie" from a pool of m2ts (movie spread in different m2ts)?

Thanks

[Atak_Snajpera]

Could you add a switch to close DGIndex automatically in case of error?

[buzzqw]

Could you add a switch to close DGIndex automatically in case of error?

i disagree. Rarely and only caused by users are error of DGIndex.

If something goes wrong is most probably due to input file tipe/wrong command line.. and for me is better to inform the user of the error.

I would prefer, about Pop-up warning message boxes are now suppressed for CLI operation.
that in case of "Field Order Transition Detected" error that dgindex (with an option of command line) fix automatically the wrong field order

anyway .. :thanks: for this update!

BHH

[Atak_Snajpera]

I'm just talking about extra optional switch in CLI not in GUI! It wouldn't be used by default!

[ankurs]

also could it tell the field order of the source itself and accurately.. because also meGUI and GK sometimes are wrong in thier analysis and then it has to be checked and tested manually :( .. btw thanks for the playback optionn :D !! sjuperb as usual :)

[Sharktooth]

i think ill add this version and not 1.4.9 to megui due to this:
* Pop-up warning message boxes are now suppressed for CLI operation.

[Terranigma]

Oh nice. Thanks for the update. :D

--
neuron2, could it be a possibility that the iDCT Algorithm, IEEE-1180 reference, was broken or wasn't working properly in the previous (1.49 Final) version, because with this newer version, my custom scripts seems to be decoding at a slower pace, so as a workaround, I have to increase the maximum amount of memory to compensate for the speed loss. Not a big deal, but I am curious to know if there's been some changes made to the algortihms as well that could affect the decoding speed.

[Guest]

Nothing has changed in that regard. Your logic is rather contorted. "My script is running slow, so is the IDCT broken in the old version?" It makes no sense.

[Terranigma]

Your logic is rather contorted. "My script is running slow, so is the IDCT broken in the old version?" It makes no sense.

Well, I was thinking that maybe you had found something that was faulty with that algorithm and maybe corrected it in the new version; so that's where I was coming from. :p
Anyways, that's for the reply, my computer was the culprit-It was updating itself while I was previewing my scripts. :rolleyes:

[G_M_C]

Here is DGMPGDec 1.5.0 beta 1:

* Pop-up warning message boxes are now suppressed for CLI operation.

* PSIP PID detection has been added.

* PIDs are now displayed in decimal as well as hexadecimal.

* A new option, Looped Playback, was added. When the end of the timeline is reached during a Play or Preview operation, playback is automatically restarted at the beginning of the timeline.

* A bug was fixed in the transport packet length detection code. This caused some M2TS streams to be parsed incorrectly.

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

Good to see you're still updating & improving the MPEG2-tools in your portfolio Neuron2 !

Hopefully you AVC-tools will be of equal high quality

[map1742]

Nice. Will try this shortly.

I am using HDVsplit and DGMPGDec to process my Sony HC3/HC7 50i movies. In my experience Sony Vegas 7, Cineform Connect and Canopus Procoder all lose fields at the start and end of a file when compared to DGMPGDec.

One feature request: please add ".m2t" as a file extension in the DGindex open file dialog for MPEG and transport stream files. This is the default type for HDV files from HDVsplit and Vegas.

Thanks :)

[Isochroma]

Thanks for the PID addition!

[SpAwN_gUy]

anything about "relativity" of filepath? ;)

[krisq]

anything about "relativity" of filepath? ;)

do you mean 'options\use full paths'?

[SpAwN_gUy]

do you mean 'options\use full paths'?exaclty ;)
as i wrote in here (http://forum.doom9.org/showthread.php?p=1023814#post1023814)

[Guest]

Refresh my memory please. What is the specific case that necessitates new path handling? Give me the full paths to the D2V, AVS, and source files in your specific case, and tell me how you think DGIndex should handle it.

[SpAwN_gUy]

Refresh my memory please. What is the specific case that necessitates new path handling? Give me the full paths to the D2V, AVS, and source files in your specific case, and tell me how you think DGIndex should handle it.well.. the big part is in the post on the link... and for the rest:

AVS:G:\DVDRiP\AFRO\DVD1\AS01\AS01.VD_LS.avs
G:\DVDRiP\AFRO\DVD1\AS01\AS01.d2v
G:\DVDRiP\AFRO\DVD1\01\VTS_02_1.VOB
AVS Internals:
LoadPlugin("..\filters\DGDecode.dll")
DGDecode_Mpeg2Source("AS01.d2v", info=3)
Crop(2,4,-2,-4)
Lanczos4Resize(864,480)
.d2v internals
DGIndexProjectFile16
7
..\01\VTS_02_1.VOB
Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=5
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x480
Field_Operation=0
Frame_Rate=29970 (30000/1001)
Location=0,0,1,209c6

d00 1 0 2048 0 1 1 d2 f3 e0 f1 f2 e3 f0 f1 e2 f3 f0 e1
d00 1 0 411648 0 1 1 d2 f3 e0 f1 f2 e3 f0 f1 e2 f3 f0 e1

aviSynth plugins are in here
G:\DVDRiP\AFRO\DVD1\filters\DGDecode.dll
and the AVS, d2v, VOBs are also available from the LAN with theese paths
\\controllerPC\x264farm\
\\controllerPC\x264farm\AFRO\DVD1\AS01\AS01.VD_LS.avs
\\controllerPC\x264farm\AFRO\DVD1\AS01\AS01.d2v
\\controllerPC\x264farm\AFRO\DVD1\01\VTS_02_1.VOB
\\controllerPC\x264farm\AFRO\DVD1\filters\DGDecode.dll so in this situation evrything is working fine.. video is rendered on anotherPC..

the only thing that in nonautomatic is storing of relative paths in the d2v internals.. there are: Full-paths (with "G:\..") and Just-file-names (just "VTS_02_1.VOB")

[Guest]

@SpAwN_gUy

Please explain why it is so important to you to have your D2V and AVS files in a location other than the source files. This will be a non-trivial development so it's up to you to justify the feature request.

[SpAwN_gUy]

heh.. well.. i'm trying to keep things separate (unlike stuff at home :) )..
VOBs are usually in the VOB folder, while d2v's and avses - in separate..
AutoGK stores it's temp-files in separate folder,.. meanwhile storing "fullpaths" in d2v..

but the network part is.. for.. x264farm. agen-based encoding over the network (try first tutorial in my signature). agent-based is when avs-internals are decoded and processed on other farmPC's (it gives a huge speedUP, and lowers controllerPC's CPU usage).
so, suddenly i've discovered a way to organize everything, by changing full-paths to relative-paths manually.
Well, offcource, i have in my mind, that i can open VOBs through Network-path (through the ass, actually), and store full-network-paths... but..

[Guest]

... but.. But what?

[SpAwN_gUy]

But what?

But, maybe, such an option will be more convinient and more universal(can i use this word in this context?)

[Guest]

* The file type .m2t was added to the open dialog.

* Some array sizes were increased to prevent crashes in the debugger.

* The next_start_code() function was enhanced to add error resiliency for abnormal slice terminations.

* Because the code never writes to the DirectDraw surface anymore (removed long ago!), the DirectDraw Overlay option was removed. DGIndex now never seizes the overlay.

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

[Boulder]

Are you interested in taking a look at a sample in which the delay is way off target?

The reason why I ask you first is that the bad VOB is the result of RipIt4Me+FixVTS, a good delay value is found when the disc is decrypted using DVDFab HD Decrypter. PGCDemux does show the correct value from the bad VOB so it is there somewhere ;) The disc is ARccOS protected (a Sony release) if I'm not mistaken.

Since many people still use RipIt4Me, it might be interesting to know whether this odd behaviour could be avoided in DGIndex (which is used by many applications).

[Guest]

Sure. Post a fragment of the start of the VOB. Don't cut the start.

[Boulder]

Here it is : http://www.savefile.com/files/1052641

DGIndex 1.5.0 beta 2 reports delay 81112ms, the correct is apparently -128ms which PGCDemux reports, it is also the same value that DGIndex reports when processing the DVDFab HD Decrypter-ripped VOB.

[SeeMoreDigital]

I've just run your .VOB sample thru' EVOdemux and it reports the same delay time as DGIndex.... Strange eh!

http://img210.imageshack.us/img210/1848/evodemuxhx6.png


Cheers

[Boulder]

Funny thing is that PGCDemux doesn't find any audio tracks when opening the corresponding .ifo file and using "by PGC" mode. The whole audio track can only be found if I use "by VOBId" and choose the correct VOBId. (choosing "by cell" works as well but it shows the delay only for the cell in question)

Maybe this is the reason for the weird delay?

[Guest]

File sharing sites are blocked by my employer so I can't get to it until tonight. But did you try the standard trick of starting the project in by several GOPs (e.g., hit > 5 times and then [ before saving the project)?

[Boulder]

Actually no, this is the first time I've run into this problem. If it solves the issue, what about those applications that use DGIndex, such as DVD-RB? That trick cannot be used with them.

[Boulder]

Yep, jumping a few GOPs seems to work. I wonder how DVD-RB or MeGUI would behave..I think I'll need to run a test project and see what comes out.

[Guest]

Well, it means that there is crap at the beginning and it is confusing the delay calculation. I'll have to think about what can be done for DVDRB, etc., in this regard.

[Guest]

the only thing that in nonautomatic is storing of relative paths in the d2v Just to be completely clear about this...

1. When you say 'relative', do you mean relative to the path location of the D2V file? That path is to be the base location for everything else, yes?

2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?

[Guest]

Yep, jumping a few GOPs seems to work. This has come up so many times now that I have added a warning popup when a large audio delay is calculated. The popup explains the GOP skipping trick.

[Boulder]

That's a good idea - especially because it has been quite rare but apparently has become more common due to the structure crippling protections.

[Rainy]

2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?

Just force the storage of absolute paths. Though it doesn't seem that he'd like to use the relativeness feature this way, but simply being able to move the directory structure including the project file from a local hard drive to a network store, without editing d2v internals manually.

[SpAwN_gUy]

1. When you say 'relative', do you mean relative to the path location of the D2V file? That path is to be the base location for everything else, yes? yes. path to VOBs relative to .d2v-file path.
2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?
Just force the storage of absolute paths. Though it doesn't seem that he'd like to use the relativeness feature this way, but simply being able to move the directory structure including the project file from a local hard drive to a network store, without editing d2v internals manually.yep. exactly. (as i can remember) Windows stores "relative-paths" when files are on the same drive, and "full-paths" when on different..
just store "d:\path\file.vob"

it is, like, for moving files from one drive to another without loosing playability and encodeability.. without editing .d2v's or making another Indexing..

[Guest]

You're not answering my question. What is the point of me adding relative path handling for this networking scenario, which you cited as a reason for adding it? We can already store full paths. If you don't make things clear I'm going to move on.

it is, like, for moving files from one drive to another without loosing playability and encodeability.. without editing .d2v's or making another Indexing.. But if I store the full path, you can't have this movability.

I'm just not seeing the point of all this.

[Rainy]

You're mixing things up: Absolute paths have to be stored whenever the project and video files don't share a common prefix, i.e. are located on different drives, *even* if the user chooses paths to be stored relatively. This is a special handling for the scenario you've mentioned before, since there's no such a thing as relativity between different drives ;) In any other case you simply store relative paths, which makes it possible to move files around and never have to edit the project file.

[Guest]

Ha ha, I'm not an idiot. I'm asking for justification for the feature. If the only thing he wants is to store his source files away from his D2V, then it's too minor to jump ahead of other stuff on my to-do list. If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.

[SpAwN_gUy]

If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.the reason i started this is just because of "farm" and agent-based encoding.
well, i've been able to handle evrything with "full paths" when i was encoding(and am) on my localPC. (i.e. custom aviSynth filters were in daefault avisynth plugin folder, VOBs on one drive, avses somewhere else.. and with full paths everything worked just fine..).
but when i started farming.. i've noticed, that "d_mn.. my files are NOT encoding at all. Why?"
- because no one can open a C:\path\file.vob from another PC from the network..
then i've UNchecked option "Store full paths".. and what do i get.. i get NO PATHS at all..


well. okay. i give up..
a) yes i've mentioned that behaviour only with x264farm.
b) yes i can do it with my hands.
c) cmon... if you are not in to implementing that.. okay i'll continue doing what i'm doing..
and there allways be a step in "the guide" for x264farm agent-based encoding about "sh@.. you have to modify paths to vobs on your own"

i'm tired to keep asking (i guess today is my bad day..).. i know that this is some kind of minor request (i always did thought so) and i'm thinking of implementing that ONLY IF you have time..
(maybe i'll try to get sources.. and we'll see how could i help you..)

cheers, warezmasta.

[dk75]

You must explain it simpler.

And thats whats going on:
1. one have VOB and do GDIndex and make AVS script
2. one have 6 computers over LAN and want to use them to parallel encode of this VOB to H264
3. to lowering LAN overhaul one use x264farm to that by installing agents at 5 computers and server at 1 computer
4. server program cut this VOB to smaller parts and send them to agents with his part of AVS script
5. each agents works on its part of VOB independently and send done encodings to server
6. server merge encoded parts to final file and you have 5 time faster encodings

For that, first AVS made on server side must work correctly at each agents, but at each computer agents might be installed at different place.

I hope that I've didn't mixed up anything?

[Guest]

dk75, thank you. Someone finally made it clear.

i'm tired to keep asking spawnguy, I've been adding requested features, small and large, for over 4 years. I simply want to understand what I am doing. And if you want to contribute code, it will always be appreciated and properly credited.

[SpAwN_gUy]

You must explain it simpler.
:) ... no coments

And thats whats going on:
1. one have VOB and do GDIndex and make AVS script
2. one have 6 computers over LAN and want to use them to parallel encode of this VOB to H264
3. to lowering LAN overhaul one use x264farm to that by installing agents at 5 computers and server at 1 computer
4. server program cut this VOB to smaller parts and send them to agents with his part of AVS script
5. each agents works on its part of VOB independently and send done encodings to server
6. server merge encoded parts to final file and you have 5 time faster encodings

For that, first AVS made on server side must work correctly at each agents, but at each computer agents might be installed at different place.

I hope that I've didn't mixed up anything?
just few corrections..
there is only ONE AVS, and controller just splits total framecount to some little number of frames..
agents do the encode.
then controller makes ratecontrol and goes to second pass
for x264.exe on an agentPC it looks something like that:
\\controllerpc\farm\x264.exe --seek 4450 -frames 250 \\controllerpc\farm\somedvd\movie.avs
evry agent gets its own startFrame and frameCount..

[Rainy]

Ha ha, I'm not an idiot. I'm asking for justification for the feature. If the only thing he wants is to store his source files away from his D2V, then it's too minor to jump ahead of other stuff on my to-do list. If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.

I didn't mean to be offensive, just wanted to help. But as I see, I should stop posting and let everyone else speak for themselves, since I prevent them from doing this all the time.

[Guest]

@Rainy

It's cool. I didn't mean to imply any censure of you. Keep right on speaking up.

[Guest]

Let me know if this does what you want:

http://neuron2.net/guest/DGIndexTest.zip

Don't forget to turn off Use Full Paths.

[SpAwN_gUy]

Let me know if this does what you want:
http://neuron2.net/guest/DGIndexTest.zip
this one works completely incorrect.. :( ..
as i've noticed it stores "nothing", when output=source
and just one "..\" when output != source (on the same drive)
and correctly saves full-path, when on different drives.

but modded 1.4.9 from Rainy (i've got this night) works great..
i've checked:
output=source (stores ".\", maybe that one is not needed..)
output - somewhere in the different folder.. (correctly stores lots of "..\") i.e.
VOB:
G:\DVDRiP\Bakumatsu\DVD1\01\VTS_02_1.VOB
.d2v:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\ddd.d2v
.d2v internals:
DGIndexProjectFile16
1
..\..\..\..\01\VTS_02_1.VOB
tes.avs:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\test.avs
DGDecode.dll:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\DGDecode.dll
test.avs internals:
LoadPlugin("dgdecode.dll")
mpeg2source("ddd.d2v") shows nice picture ;)
and on a different drive.. (stores full-path)

maybe, neuron2, you could use part of theese sources?
http://home.no/rainy/dgindex149src.zip

[Guest]

I was not aware of the PathRelativePathTo() API call, and my attempt to write it from scratch was buggy. I have it working now using that API and it will be in the next beta release.

[SpAwN_gUy]

I was not aware of the PathRelativePathTo() API call, and my attempt to write it from scratch was buggy. I have it working now using that API and it will be in the next beta release.i haven't found it either... when i was searching for som realization..

and :thanks: :)