DGIndex 1.3.0 beta 5

[len0x]

Originally posted by Cyberia
How the heck do you manage to get 1700+ views on this thread in TWO DAYS!!!

The thread was linked from front page news on doom9.net

[Wilbert]

Graft, is this pc_scale/tv_scale supposed to work with VFAPI Reader Codec v1.05?

It doesn't do anything, that's why I ask. If I create a m2v with Y=16,U=V=128, two d2v from it using pc_scale and tv_scale, two fake avis from those, both clips have R=G=B=0.

[neuron2]

I mentioned in the other thread that VFAPI forces TV scale RGB.

[Wilbert]

You mean PC scale (cause it does YUV [16,235] -> RGB [0,255])?

[neuron2]

Correct, sorry.

[Trahald]

is it possible to have the save file use the .d2v filename .. i loaded a m2v file with the idea of cutting it down via the demux option, but it overwrote my original. im assuming since it was intended for files with .vob extension as source?

[D3s7]

I had this issue as well..

Opened a .m2v file, set my input/output range and did "save project and demuxed"

it created a .d2v file and killed my .m2v... (was left with a 1k file that wasn't even the clip of the original)

This was with saving into a different directory as well.. not same as original

[neuron2]

OK, I never thought people might use it to cut elementary streams, but why not? I'll fix it to use a different filename in that case. Thank you for bringing it to my attention.

[Cyberia]

Originally posted by Trahald
is it possible to have the save file use the .d2v filename .. i loaded a m2v file with the idea of cutting it down via the demux option, but it overwrote my original. im assuming since it was intended for files with .vob extension as source?

Oops. I had intended to mention this to Don but I forgot.

The m2v file uses the name of the original vob, but the audio files and the avs script use the name of the d2v project.

For consistency, I recommend that the m2v file use the project name as well, however..... please default the project name to the name of the original vob.

Currently there is no default project name provided when saving.

[Cyberia]

Originally posted by D3s7
I had this issue as well..

Opened a .m2v file, set my input/output range and did "save project and demuxed"

it created a .d2v file and killed my .m2v... (was left with a 1k file that wasn't even the clip of the original)

This was with saving into a different directory as well.. not same as original

In this case, we should have simply generated an error dialog saying "Cannot write m2v file" and gone on.

We shouldn't be able to overwrite the file we are reading from!

[neuron2]

The user could specify a project name (D2V file) that has the same base as the input file, e.g., input Cyberia.m2v and project file Cyberia.d2v, so I have to allow for that.

This is what I will do:

d2v_base.demuxed.m2v

So, in the example, it would be Cyberia.demuxed.m2v.

If the input file is Cyberia.demuxed.m2v, then the output will be Cyberia.demuxed.demuxed.m2v, etc.

[neuron2]

I posted 1.3.0 beta 3:

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

It fixes the M2V overwrite issue.

But watch out! This really is a beta. I made some major changes to EOF handling. If there is not an incomplete picture at the end, the frame counts should be correct, and the last picture should display normally when previewing. I also added exception handling to both DGIndex and DGDecode, so that we don't crash on an incomplete picture.

If there *is* an incomplete picture at the end, you can get an incorrect frame count when previewing in DGIndex.

But finally I have a version that works correctly with my test files that have exactly one, two, and four frames.

[cw_uk]

I have been working with some HDTV transport streams lately did you know that DGIndex will lock up should you select more then 10 files at once when loading your sources.

[Cyberia]

Originally posted by cw_uk
I have been working with some HDTV transport streams lately did you know that DGIndex will lock up should you select more then 10 files at once when loading your sources.

CONFIRMED!

I just checked and both 1.2.1 and 1.3.0b3 lockup (cpu usage goes to 99% and stays) when opening more than 10 vobs at once. ONLY THROUGH THE FILE/OPEN DIALOG. DRAG-AND-DROP SEEMS UNAFFECTED.

It's intermittant at 11 vobs, but consistently happens with 16+ vobs.

[neuron2]

I opened 20 by loading the same 5 four times. Nothing wrong happened. Does that fail for you, or do I have to open all 20 at once?

[Cyberia]

You have to open them all at once via the File/Open dialog.

Follow these steps:

Close all DGIndexes.
Open DGIndex.
Select File/Open/Add.
(Windows File Select dialog appears.)
Select 16+ vobs at once.
Click Open. --> [lockup 99% cpu usage]
(DGIndex does not return to it's File/Open dialog)

I can reproduce this on two different systems.

Drag-and-Drop seems to work fine for the same set of vobs.

[neuron2]

OK, the file dialog buffer that returns the file list must be too small. I'll fix that when I get back from LA. In the meantime, the workaround is to load in bunches.

[Backwoods]

I figured out my problem from the previous threads and your betas. The problem I had was when saving, DGIndex would lock up.

Now it does the same, but if I let it sit for about 20sec the save runs. But before I could let it sit for a minute or longer and it would still not save.

Is there anything that can be done about that? I'm uploading the type of files I use, it could be because of them.

[Cyberia]

Originally posted by Backwoods
I figured out my problem from the previous threads and your betas. The problem I had was when saving, DGIndex would lock up.

Now it does the same, but if I let it sit for about 20sec the save runs. But before I could let it sit for a minute or longer and it would still not save.

Is there anything that can be done about that? I'm uploading the type of files I use, it could be because of them.

What's the file name(s)?

[Backwoods]

backwoods_sample.mpg

I doubt it's my machine...could be, but doubt it. Other MPG2s work fine.