DGMPGDec 1.2.1 Beta 2

[neuron2]

Here's a new beta. The changes are as follows:

1. Fixed crashing bug in BlindPP().

2. Fixed incorrect DGDecode postprocessing for YUY2.

3. Changed DGDecode to deliver YV12 by default. For I420, use
DGDecode(...,i420=true). This fixes interoperability with some
applications, such as mencoder.

4. Fixed erroneous audio delays for multiple tracks.

5. Added i420 parameter to DGDecode help file, and added an Appendix
on BlindPP() usage.

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

[len0x]

Originally posted by neuron2
4. Fixed erroneous audio delays for multiple tracks.

Did that happen during "demux all" or just demuxing any track after first one?

[neuron2]

Only during Demux All with multiple tracks.

[neuron2]

I'm gonna drop a 1.2.1 release unless somebody has an issue.

Going once, going twice...

[JetlagMk2]

Would it be difficult to add a field_operation option to dgdecode (to override what's specified in the d2v)? Also D2V_Format_v08.txt says:

C. The Field_Operation line now may specify 3 for raw encoded frames.

I think that should be a "2", right?

[Cyberia]

Originally posted by JetlagMk2
Would it be difficult to add a field_operation option to dgdecode (to override what's specified in the d2v)?

Can't you just remake the d2v? This seems silly.

[neuron2]

Or you can edit the D2V file. Change the field operation and the frame rate accordingly. That's all that needs to change.

@JetlagMk2

Regarding 3 -> 2 in the format doc, you're right. Thank you.

[GrofLuigi]

neuron2,

Now that hints are getting more fashionable, could you consider passing hints to telecide?

(sory if I don't know what I'm talking about, or if it is already implemented or planned... DGdecode is working flawlessly here, but telecide could use some help too - not that it isn't OK itself, it's the sources I'm struggling with...)

And thank you for your great work!

GL

[neuron2]

Originally posted by GrofLuigi
Now that hints are getting more fashionable, could you consider passing hints to telecide?

I could pass them easily enough, but then I'd have to modify Telecide to use them!

The problem is that the progressive_frame flag is notoriously unreliable.

If you need any help with the Telecide sources, I'll be happy to assist you via PM.

[GrofLuigi]

Originally posted by neuron2
I could pass them easily enough, but then I'd have to modify Telecide to use them!

That was the idea.

The problem is that the progressive_frame flag is notoriously unreliable.

I know, that's why I said "to help telecide", like to provide an optional mechanism, and us the poor users will find a way to (mis)use it.

If you need any help with the Telecide sources, I'll be happy to assist you via PM.

Oh, not the Telecide sources, my DVD sources! All store-bought and pressed originals, but bad telecine conversions, like this:

http://forum.doom9.org/showthread.php?s=&threadid=85639

Now I don't seek help for myself (I've already finished with those movies), but I think every idea for improving great programs is worth considering (and that may be my contribution since I can't do programming myself).

GL

[neuron2]

My current attitude is that if the flagging is good enough for Telecide to use, then it is good enough to use FORCE FILM. I'm open to alternative thinking, however.

[BlueIce]

I tried using DGMPGDec v1.2.1 beta 2 instead of DVD2AVIT3 for making a .d2v of a transport stream captured by an MyHD MDP-120 but when I try to cut commercials it goes much slower than if i make the .d2v with DVD2AVIT3, is there a reason for this?

[neuron2]

What goes much slower? Please describe exactly what you are doing, what you expect to see, and what you are seeing.

[za222]

I have a problem:

When I use DGMPGDec 1.2.1 Beta 2 i get
MOVIE AC3 T02 3_2ch 384Kbps DELAY 40ms

with DVD2Avi i get:
MOVIE AC3 T02 3_2ch 384Kbps DELAY -40ms

So the delay is negative like also ifoEdit shows up.


But the curious thing is the in both cases, if i enter the delay excactly as shown in filename when muxing to .avi it is in sync.

So i think there has to be a difference in the created .d2v since the 2 .ac3 files have identical content!

[eb]

... famous problem with 2 frames at file start ...

eb

[za222]

Originally posted by eb
... famous problem with 2 frames at file start ...

Well, so what delay will i have to use after Encoding with GordianKnot?
In this special case for me +80ms (+2frames) seem to be sync.

[neuron2]

You use the value that gives you the best sync!

DGIndex just reports the offset between the video and the audio at the starting point. But the streams could have been multiplexed already slightly out of sync.

My process is to try a short encode using the DGIndex value. If that appears OK, I use that. If not, I experiment until I find the right value. Most of the time DGIndex is close, but not always.

[za222]

I think i found out why i needed to use +80ms instead of -40 as in .ifo:

The .d2v file is exactly 3 frames longer (at the begining) as the original .vob files.
So these 3 frames are the the 120ms difference.

[neuron2]

You think DGIndex just invented three frames and inserted them?

[Cyberia]

Originally posted by za222
I think i found out why i needed to use +80ms instead of -40 as in .ifo:

The .d2v file is exactly 3 frames longer (at the begining) as the original .vob files.
So these 3 frames are the the 120ms difference.

Nothing is wrong.

Read the FAQ, Q34.

In short, the old versions dropped 3 frames, which affected the delay.