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]

You know the rule. I need the stream so I can duplicate the issues.
The link I provided to a sample here (http://forum.doom9.org/showthread.php?p=1121930#post1121930) 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 (http://www.megaupload.com/?d=69201BRT)

[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]

@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]

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

hehe... well said, BUT...

we have to thank you for your hard work...:thanks: 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]

@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]

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]

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]

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

[CodeOptimist]

Thanks for your great work on DGIndex, neuron! I had an AC3 audio decoding issue with an earlier version, but after upgrading to RC4 it works like a charm.

Keep up the good work - it's definitely appreciated!

[josey_wells]

I am using DGIndex to parse Das-Boot The Director's Cut Disc 1. The movie has 4 VOB's. VOB 1-3 are progressive and VOB 4 is interlaced.

When I run all 4 VOB's simulatenously through DGIndex it reports the entire series as interlaced.

Shouldn't DGIndex report the movie as progressive or majority progressive since the interlaced part is only 10%?

[Guest]

When I run all 4 VOB's simulatenously through DGIndex it reports the entire series as interlaced. DGIndex reports progressive/interlaced on a per-frame basis, so your statement makes no sense.

[burfadel]

It depends whether you select 'honour pull down flags', 'ignore pull down flags', or 'forced film'.

Try 'ignore pull down flags'?

[josey_wells]

Let me see if I can make this more clear:

I am talking about the summary dialog and log file here.
A video can be purely progressive, purely interlaced, or a hyrbid of the two.

When I run VOB's 1, 2, & 3 through seperately DGIndex reports progressive in the summary window.

When I run VOB's 4 through seperately DGIndex reports interlaced in the summary window.

When I run VOB's 1-4 through as a group the summary window reports interlaced.

My question is why can't the summary window list the percantage of progressive or interlaced frames since it is checking each frame, i.e. Progressive(90%), Interlaced(10%)

[Guest]

Sorry, but this is the thread for 1.5.0, which is now frozen for new features. You'll have to ask again when the next version thread starts.

[SeeMoreDigital]

Hi Donald,

Is the "Display Size" outputting the correct information?

For example DGIndex reports this about the elementary 720x576 MPEG-2 stream with 16:9-PAL (aka: 64:45) aspect ratio signalling: -

http://i30.tinypic.com/2mrdsmu.png


Whereas DGAVCIndex reports this about the elementary 720x576 MPEG-4 stream with 64:45 aspect ratio signalling: -

http://i28.tinypic.com/bjijyp.png


Cheers

[Guest]

Please post a link to a sample of the stream.

EDIT: I've looked at the code and DGIndex just prints the display size values from the stream. So I would assume that the problem is in the stream itself.

[SeeMoreDigital]

Please post a link to a sample of the stream.Here you go: -

http://www.sendspace.com/file/fzu9m7


Cheers

[Guest]

The stream is specifying the display size as 720x576, just as I supposed.

[vlada]

Hi,

I have a question - is there a CLI switch to let DGIndex process only a part of an MPEG file?

I would like to explain my situation and idea. I'm working on an Avisynth transcoding application. During onpening a file, I want to use AviSynth and Autocrop filter to detect cropping. But I don't want it to take to much time. My idea is to index only 1s pieces from 10 parts of a DVD and use them to detect cropping.

Is this a good idea? Can this be done? If I use GUI I can select only a part of and MPEG file, so I do believe I can do the same from command line, but I couldn't find it in manual.

[Guest]

@vlada

Features are frozen for 1.5.0. Ask again when the next development thread starts.

[SeeMoreDigital]

The stream is specifying the display size as 720x576, just as I supposed.In that case, I suspect all MPEG-2 DVD sources will report a "Display Size" of 720x576 (for PAL) or 720x480 (for NTSC)... ie: it will be exactly the same as the "Frame Size"....

EDIT: Yes, this seems to be the case.... Does anybody have any spec MPEG-2 files where the "Display Size" and "Frame Size" are different?


Cheers

[vlada]

neuron2> Sorry, I thought the possibility might be there and just isn't mentioned in manual.

Another question - I use this command line:
exe\dgindex.exe -if=[D:\VIDEO_TS\VTS_01_1.VOB,D:\VIDEO_TS\VTS_01_2.VOB] -OM=2 -OF[C:\video\index] -EXIT


During the indexing the video preview window is black. Is this normal? If I do the same from GUI, the video is displayed.

Thank you for your reply and work on your applications.

[Guest]

neuron2>During the indexing the video preview window is black. Is this normal? If I do the same from GUI, the video is displayed. It's normal. No decode thread is kicked off when you tell the CLI to make a D2V file.

[stax76]

@vlada

Another thing you could try is the ffdshow source filter that appeared some time ago.

[vlada]

It's normal. No decode thread is kicked off when you tell the CLI to make a D2V file.

And can this be changed via a CLI parameter or should I keep this possibility for my 1.6 wishlist? ;-)


@vlada
Another thing you could try is the ffdshow source filter that appeared some time ago.

I never heard about it before. But ffdshow is "only" a video/audio decoder, it doesn't contain any splitters/demuxers. Also I'm afraid this wouldn't be a portable solution. I want to make my application portable. Thanks to avs2yuv and SoundOut it is possible to use Avisynth even if it's not installed.

Could point me to a source with more information about ffdshow source? I can't find anything myself.

Sorry for the OT.

[plugh]

I have the bad AC3 demux with audio only fixed.Cooll! Will it include 'delay' value in the filename?Yes.
I did a 'Demux Audio Only' on a VOB with RC5 (have not tried a TS yet).

No delay value in filename.

[stax76]

@vlada

I've confused it with ffmpegsource.

[Guest]

I did a 'Demux Audio Only' on a VOB with RC5 (have not tried a TS yet).

No delay value in filename. 'Demux audio only' does not give a delay value by design. What would it be referenced to, the non-existent video? If the delay is significant, then there is video. If there is video, then you use Save Project.

[plugh]

It is demuxed from a source that has video; seems reasonable to me that you would provide the time offset between the two, just like when indexing the video.

Refering to the work-flow I posted at the beginning of this post -
http://forum.doom9.org/showthread.php?p=1121930#post1121930
--I wanted both the original ac3 5.1 and a decoded stereo mix-down wave--

opened files in dgindex, quick preview.
set audio for 'decode to wave', selected channel 0
made first pass to do the 'prescale decision'
made next pass with Save Project, yeilding .wav and .d2v
made next pass with 'Demux audio only' yeilding .ac3

Neither of the above audio output files indicates the delay to be used in the filename. Soooo... I made another short, _aborted_ "save project" pass simply to create another ac3 output file WITH the delay value in the name.
Yes I can get the delay, by indexing the video twice.

If that is 'by design' so be it. It seems like an oversight.

[Guest]

Make your second pass with Save Project. Is it so hard to understand that Demux Audio Only is intended for streams without video? I explicitly say that in the User Manual. Isn't it clear?

[plugh]

I apologize. I missed that statement. The work-flow and the available menu functions seemed to be made for each other.

Many thanks for your efforts and patience.

BTW, is now a good time to revisit my questions about correlating the timestamps?

[G_M_C]

Make your second pass with Save Project. Is it so hard to understand that Demux Audio Only is intended for streams without video? I explicitly say that in the User Manual. Isn't it clear?

Yes i've read that too ... and if i remember correctly i asked why that is/was exactly. Cause i used this option to demux the audio only from my Pink Floyd "The Wall" DVD, for intentions of making a CD of the music for @ work (in the car and so forth). Didn't really matter, cause save project & demux audio gave me the audio anyways, but demux the audio only would have been a bit simpler

(in an ideal world " demux audio only" while also splitting the audio on chapterpoints would have been the most ideal option, giving me ready-to-convert audio indexed to tracknumber for my CD ;) But hey ... the world isn't ideal, and i made my CD anyways :) )

[Guest]

Yes i've read that too ... and if i remember correctly i asked why that is/was exactly. Cause i used this option to demux the audio only from my Pink Floyd "The Wall" DVD, for intentions of making a CD of the music for @ work (in the car and so forth). Didn't really matter, cause save project & demux audio gave me the audio anyways, but demux the audio only would have been a bit simpler If you are just taking the audio to make an audio CD, the delay value is useless. You're not making any sense. And I don't see how it is simpler either.

Maybe I need to change the option string to:

Demux 'Audio Only'

[plugh]

That might be enough to trigger people to read that section of the docs. ;) I confess I interpreted the function to mean 'ONLY demux the audio', versus Save Project == 'index the video AND demux the audio'.

Hmmm... Is 'decode to wave' "mode" applicable to the 'demux audio only' "function"? If so, 'demux' probably isn't the best choice. Perhaps " Process 'Audio Only' " or some such?? That phrase would definitely have prompted me to check the docs.

[SeeMoreDigital]

How about: -

http://i27.tinypic.com/zwzy1u.png


Cheers

[Guest]

How about using text to say it, as I am blocked from storage sites at work?

[unskinnyboy]

Feature request: In the DGIndex GUI, can a menu item be added under Options (or under maybe File if it makes more sense) to say After indexing and with sub-options Do nothing (the current default), Close DGIndex, Shutdown, Hibernate & Sleep. I am requesting this feature because often I open multiple DGIndex windows and set DGIndex to index 8-10 set of VOBs in a shot. Once done, I'd like for all of the windows to automatically close and not wait for me to get back to the PC and close them manually. So, to be precise, I am currently interested in only the Close DGIndex option, but maybe someone else might the other options useful.

I hope this wouldn't be too difficult to implement. If it is, then I can live with how things currently are. Thanks.

[Guest]

I'm not paying any attention to new feature requests until 1.5.0 is out. I didn't hear a word you said. :) Please wait for the next development thread and repost your request there.