DGMPGDec 1.5.3 Final

[hajj_3]

just to remind people of the new options in RC4...

in the DGIndex.ini file if you want the old behaviour of the window coming to foreground and beeping use option 3 from below, default is now 0:

Notify_When_Done:
0=no notify
1=window to foreground
2=beep
3=foreground and beep

If you want audio to be created as a .mpa file like before change the following from 0:

Use_MPA_Extensions=1

thanks alot for your hard work neuron, loving this build

[Terranigma]

Thanks for the update, neuron2. You know how much I appreciate your work.

[Guest]

I do indeed.

The great users and their feedback are the heroes. I'm a lowly coder.

[plugh]

Using RC4 I indexed a transport stream, with Timestamps enabled. The first part of the output says:

DGIndex Timestamps Dump

frame rate = 29.970030
V PTS 4056924629 [45076940ms]
V DTS 4056917121 [45076856ms]
Decode picture: temporal reference 831[I]
 A0 PTS 4056881918 [45076465ms]
PCR 1217062932236 [45076404ms]

I subtract the (converted) 'A0 PTS' from the 'V PTS'
45076465 - 45076940 = -475
which matches the delay in the ac3 filename.

I then did an 'Analyze Sync->Track 1' and gave it this timestamp file. The first part of the output says:

Delay Analysis Output (Track 1)

Decode picture: temporal reference 831[I]
delay = 27252
Decode picture: temporal reference 845[I]
delay = 27711
Decode picture: temporal reference 859[I]
delay = 28170
Decode picture: temporal reference 873[I]
delay = 28630
Decode picture: temporal reference 887[I]
delay = 29122
Decode picture: temporal reference 901[I]
delay = 29581
Decode picture: temporal reference 915[I]
delay = 30040
Decode picture: temporal reference 929[I]
delay = 30499
Decode picture: temporal reference 943[I]
delay = 30990
Decode picture: temporal reference 957[I]
delay = 31449
Decode picture: temporal reference 971[I]
delay = 31909
Decode picture: temporal reference 985[I]
delay = 32368
Decode picture: temporal reference 999[I]
delay = 32859
Decode picture: temporal reference 1013[I]
delay = 33318
Decode picture: temporal reference 3[I]
delay = -390
Decode picture: temporal reference 17[I]
delay = 69

which I can't make any sense out of, given the description of this function in the docs. In particular, I would expect the first 'delay =' line to be either "-475" or "-42711".

Am I misunderstanding the docs, or is there a numerical rollover occuring in your calculations?

Thanks!

EDIT: PS - RC4 is giving me identical 'field transition' and AC3 output files from 'Save Project' with or without Timestamps enabled. (Thanks!) However, 'Demux Audio only' is still producing bad AC3 output file.

[Guest]

You know the rule. I need the stream so I can duplicate the issues.

[GrofLuigi]

Feature request (or something to think about):

A "close project" menu item that would clear all traces of current processing (reload the .ini?).

Basically, the same functionality as "Del All" but in a more 'common' or 'usual' place for Windows programs - in the 'File' menu.

I often use DGIndex on more than one project at a time and find myself confused what to click when switching between projects. That's not to say that current functionality is bad, but... it would be more user friendly for me. If others agree...

GL

[agilpwc]

I have use_full_path set to zero in the ini, but when I call dgindex from the command line like
call dgindex.exe -IF=[%~n2.mpg] -OF=[%~n2] -OM=2 -IA=3 -minimize -exit
The full path of the source file appears in the d2v file.

I reported this earlier and just tested rc4.

[plugh]

Originally Posted by neuron2

You know the rule. I need the stream so I can duplicate the issues.

The link I provided to a sample here is sufficient to demonstrate the "Save Project" vs "Demux Audio only" AC3 problem.

I'll have to create/upload a sample for the other item.

EDIT: The first 50MB of the TS that produced the above output is available here

[Guest]

@plugh

Thank you for taking the time to provide samples. I will fix the issues.

@agilpwc

Thank you for reminding me about that. I'll do my best to fix it for 1.5.0 final.

[plugh]

Originally Posted by neuron2

@plugh

Thank you for taking the time to provide samples.

No problem...

On a related topic:

Is it reasonable to assume that if a 'V PTS' or 'A PTS' record is present in the timestamp file, then there is a corresponding video or audio frame output by dgindex?

In the context of glitchy transport streams, can I correlate the timestamps with the output, or is it possible for your code to recognize / output a timestamp but then decide, due to some error in the associated frame, to drop the frame? (or vice versa - ie output a frame with no associated timestamp)?

Or perhaps even better, would it be possible to include in the timestamp file 'something' that would unambiguously tie the PTS to an audio / video frame? For example, with audio, perhaps the output file address of the start of the ac3 frame? For video I'm not sure what would be useful, given coded vs flagged frames... perhaps frame number??

FYI and FWIW, I've been pondering how to approach maintaining A/V sync in the presence of TS glitches, wherein sometimes A or V frames get dropped. As a first step, it occurred to me that a tool that would 'put' each frame on a timeline at its specified PTS (for its implied duration), and thus allow one to 'see' where the gaps occur might give clues on strategies to 'fix-up' such streams to maintain A/V sync.

As one (extreme) example - I recently had a stream with a major glitch, where I ended up hacking out about 40 frames from the AC3 file to bring the A back in line with the V. (Apparently dgindex skipped a chunk of video but managed to output audio, leading to the desync). I had to do this by trial and error, cutting out larger / smaller audio section until things looked 'ok' on playback (ie in sync after the glitch). Being able to tie timestamps to A/V frames (and 'seeing' the gaps) would have made this a snap.

Anyway - perhaps that explains my interest in the timestamp file and why I ask about correlating them...

[sidewinder711]

Originally Posted by neuron2

...The great users and their feedback are the heroes....

hehe... well said, BUT...

we have to thank you for your hard work... very much appreciated, neuron

Greetz

[Guest]

@sidewinder711

Thank you.

@plugh

I have the bad AC3 demux with audio only fixed. The issue with the timestamps arises because that stream has no GOP headers (legal but unusual). I'm going to have to think that one over for a while because there is no obvious simple solution. Regarding your new questions, patience, please, I want to fix the bugs first.

@GrofLuigi

Sorry but 1.5.0 is frozen for new features. Maybe in the next version.

[plugh]

Originally Posted by neuron2

@plugh

I have the bad AC3 demux with audio only fixed.

Cooll! Will it include 'delay' value in the filename?

The issue with the timestamps arises because that stream has no GOP headers (legal but unusual). I'm going to have to think that one over for a while because there is no obvious simple solution.

Ah - I assumed you were just keying off I-frames for the delay calc.
Does this mean the info in the timestamp file is invalid? The actual PTS's are ok, correct?
Is there something in that file (or d2v or log files) that would alert one to this case? If 'Analyze Sync' doesn't work for this 'unusual' case, so be it - as long as we know that.

Regarding your new questions, patience, please, I want to fix the bugs first.

OK - Thought you might know off-hand if the timestamps were 'correlatable' or not. Adding info to timestamp file would be new functionality (though only you can judge if it is a trivial mod or not) so I'll understand if you want to defer that.

Many Thanks for ALL your efforts.

[Guest]

Originally Posted by plugh

Cooll! Will it include 'delay' value in the filename?

Not for Demux Audio Only.

Ah - I assumed you were just keying off I-frames for the delay calc.

The code incorrectly assumed that the first frame in coding order has temporal_order 0, which it would if it was preceded by a GOP header. So my calculation goes haywire when GOP headers are missing. I have redesigned it and am now regression testing it.

Does this mean the info in the timestamp file is invalid? The actual PTS's are ok, correct?

Correct.

Is there something in that file (or d2v or log files) that would alert one to this case? If 'Analyze Sync' doesn't work for this 'unusual' case, so be it - as long as we know that.

I'm fixing it so that GOP headers are not required.

OK - Thought you might know off-hand if the timestamps were 'correlatable' or not.

I haven't had time to think about it yet. Didn't I ask you to be patient?

[stax76]

@neuron2

I'm currently puzzled if StaxRip should stay with RC3 or update to RC4, I'm also working towards a stable release.

[Guest]

RC5 will be out shortly, so upgrading to RC4 seems pointless. I'm trying to get to 1.5.0 Final, but people keep finding new issues.

I think we're getting close.

[stax76]

Good to know, thanks.

[Guest]

Originally Posted by agilpwc

I have use_full_path set to zero in the ini, but when I call dgindex from the command line like
call dgindex.exe -IF=[%~n2.mpg] -OF=[%~n2] -OM=2 -IA=3 -minimize -exit
The full path of the source file appears in the d2v file.

I reported this earlier and just tested rc4.

I'm not able to duplicate this. Can you provide a command line that fails without all the %~n2 stuff? There's no way I can verify that it expanded out correctly for you.

I ran with this:

dgindex -IF=[G:\THE_MATRIX_16X9LB_N_AMERICA\VIDEO_TS\VTS_02_1.VOB] -OF=[G:\THE_MATRIX_16X9LB_N_AMERICA\VIDEO_TS\VTS_02_1]

...and the resulting D2V has:

DGIndexProjectFile16
1
VTS_02_1.VOB

So, the onus is on you to show that there is a problem. The code looks correct to me.

[Guest]

Originally Posted by neuron2

I'm not able to duplicate this.

I investigated some more and found the failing case. It is when your -OF option does not specify a full path. I have fixed that and now my testing shows everything working as it should for the CLI. I'll release RC5 later tonight.

[Guest]

* 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.

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