Wrong framerate with command line

[Rumbah]

I just noticed a bug with the new DGIndex 1.4.8.

I have a normal PAL mpeg2 video file without audio with a framerate of 25fps. Using MeGui to create a d2v file, it uses this command line:

-AIF=[E:\Ghost1.mpv] -OF=[E:\Ghost1] -exit -minimize -OM=2

I got the following d2v File:

DGIndexProjectFile13
1
E:\Ghost1.mpv

Stream_Type=0
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=4:3
Picture_Size=528x576
Field_Operation=1
Frame_Rate=23976 (24000/1001)
Location=0,0,0,1EC66
...
FINISHED 100.00% VIDEO

Obviosly that is wrong because it i a 25 fps file.

If I create the d2v file with the DGIndex Gui, I get this file:

DGIndexProjectFile13
1
E:\Ghost1.mpv

Stream_Type=0
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=4:3
Picture_Size=528x576
Field_Operation=0
Frame_Rate=25000 (25/1)
Location=0,0,0,1EC66
...
FINISHED 100.00% VIDEO

This one is correct.
I hope this can be fixed so that I can use MeGui to create D2V files again.

[neuron2]

It's a MeGui issue. The command line does not specify the field operation (-FO), so DGIndex will use whatever is in the INI file associated with the copy of DGIndex that is being invoked. Ask the MeGui guys to generate a full command line. Or maybe you had a MeGui option set wrong; I don't know that program.

[Sharktooth]

what should be added to the commadline?
it seems to me that the commandline does NOT specify -OF but Field Operation is ENABLED Field_Operation=1

[neuron2]

As I said, if the command line does not specify the field operation, the INI file will rule, and that may contain the setting from the last time MeGui was run. To avoid that, the command line should always specify the required field operation with -FO.

[Rumbah]

@neuron2: I don't know if this a only a MeGui issue because if I replace DGIndex 1.4.8 with DGIndex 1.4.7, the same command line leads to a correct D2V file (without any ini changing (both times Field_Operation=0), I just replaced the exe file). So there was a change between 1.4.7 and 1.4.8 in the command line handling.

[foxyshadis]

I see, the default field operation in the absense of an ini must have changed, so it just needs -FO=0 now. That makes sense, thanks.

[Sharktooth]

will -FO=0 hurt interlaced/telecined detection?

[Doom9]

will -FO=0 hurt interlaced/telecined detection?It corresponds to the "Honor Pulldown flags" option which apparently was the default for commandline use in pre 1.4.8.
I wonder who is using the FO option though.. after all the best thing you can do is run it through dgindex to figure that out.

[neuron2]

@neuron2: I don't know if this a only a MeGui issue because if I replace DGIndex 1.4.8 with DGIndex 1.4.7, the same command line leads to a correct D2V file (without any ini changing (both times Field_Operation=0), I just replaced the exe file). So there was a change between 1.4.7 and 1.4.8 in the command line handling. I cannot duplicate your results using a manual command line like yours in a DOS window with 1.4.8. If you can give me a way to duplicate it without running MeGui, then I am willing to look at it some more.

[Rumbah]

I just noticed that I cannot get the error with a manual command line. So I'll have to wait for a new MeGui version and stick to DGIndex 1.4.7 till then.

[Sharktooth]

Before you get a new MeGUI build we need to track down the issue.
What are the differences from 1.4.7 to 1.4.8 in commandline handling?

[Carpo]

I just noticed that I cannot get the error with a manual command line. So I'll have to wait for a new MeGui version and stick to DGIndex 1.4.7 till then.

or use 1.4.8 as a standalone app - like i have been doing since i saw this issue pop up, then just load the d2v into megui and your good to go :)

[Doom9]

@neuron2: I don't find anything about changed commandline handling in the changelog.. could you tell us what has been changed between 1.4.7 and 1.4.8 in that department? Thanks

[neuron2]

The only relevant change was the addition of 'Open With' operation.

When DGIndex starts, it looks at the first CLI argument after "DGIndex" on the command line (first non-white-space character after 'DGIndex'). If that argument starts with a '-' character, it is assumed to be normal CLI invocation, which is otherwise unchanged from previous operation. If it is not, then it is assumed that a series of file names is presented, and that is used for the 'Open With' operation.

If necessary, I'll install MeGui and debug the issue (as long as I can duplicate it). What is suspicious to me is that the input file is claimed to be 25fps and Force Field was enabled (Field_Operation=1), so the frame rate should be 4/5 * 25 = 20, but it is 23.976 in the D2V. I don't know how that could happen, and as I say I cannot duplicate that.

[Sharktooth]

During the creation the d2v file has F_O=0 and F_R=25.
Once finished it gets changed to F_O=1 and F_R=23976

[neuron2]

Changed by MeGui? If so, it is not a good thing to apply inverse 3:2 telecine to PAL material.

[Sharktooth]

No, MeGUI doesnt edit the d2v file, it only reads it.

[neuron2]

Once finished it gets changed to F_O=1 and F_R=23976 Well, you wrote this. What are you suggesting changed it? It doesn't happen with DGIndex used stand-alone.

[Sharktooth]

Well... it's not megui. The only thing that can change it is dgindex but im not familiar with dgindex source and have very little time to do some serious debugging (since i've been again in the hospital for some days).

[Carpo]

nevermind

[Sharktooth]

well, we need to identify and fix the problem ASAP.

[neuron2]

I'll install MeGui and try to get to the bottom of it if someone will tell me the exact steps I need to follow to make the problem happen.

[Sharktooth]

Create a D2V of a progressive PAL source with "D2V Creator" in MeGUI.
Check the .d2v file during (correct values) and after (altered FPS and field operation) it's done.

If you replace the files with the ones of 1.4.7 it will work flawlessly.

[iNFO-DVD]

Got interested in this post so decided to do my own tests using avi.NET and can NOT mimic this problem. From my own tests it seems DGIndex v1.4.8 is fine with this issue.

I load in a PAL Progressive and both during the creation and after creation it gives the proper -FO and FPS.

Even removing the '-FO=0' from the arguments I'm sending to DGIndex it still works fine. I can force some kind of problem but removing the '-FO=0' from the CLI I'm sending and before running DGIndex change the 'ini' file to 'Field_Operation=1' which will then pop up a dialog warning that I shouldn't really be doing this with a PAL source e.t.c.

Anyway, just thought I should mention it. DGIndex appears fine from my own tests.

[neuron2]

Yes, that is what I found too.

I think Rumbah must have messed something up in his process. Unless he gives me the steps to reproduce this, I won't spend any more time on it.

[Rumbah]

As I posted before, I cannot produce the error by a normal command line call. That way, it works without a problem.

But you can reproduce it with MeGui 2185 just as Sharktooth wrote:

Create a D2V of a PAL source with "D2V Creator" in MeGUI (and DGIndex 1.4.8). Then the created D2V file is wrong.
If you replace DGIndex 1.4.8 with DGIndex 1.4.7 and use "D2V Creator" in MeGui, everything is fine.

So the problem only occurs with MeGui and DGIndex 1.4.8 and is reproducable as described above.

[Deckard2019]

With a NTSC source, using the 1.4.8 gui gives :
Field_Operation=0
Frame_Rate=29970 (30000/1001)

With MeGUI :
Field_Operation=1
Frame_Rate=23976 (24000/1001)


Using the 1.4.5 gui (D2V v11) for the same source, it gives :
Field_Operation=0
Frame_Rate=29970

With AutoGK 2.26 (1.4.5 cli) :
Field_Operation=1
Frame_Rate=23976

Does the difference comes from a mistake in the cli options ?
Thank you.

[Jeffster]

Okay guys, I don't know anything about MeGui but after reading this thread thought I'd install it and look for myself. Not only was I able to reproduce what Rumbah describes but it was immediately obvious why...

MeGui thinks the VOB is NTSC instead of PAL and treats it as such including forcing the framerate to 23.976 in the d2v. This line in the MeGui log after running D2v Creator gives it away: "Film percentage 100 meets force film threshold Successfully applied force film."

Prior to 1.4.8 DGIndex reports FINISHED 0.00% FILM at the end of the d2v file for a PAL vob, but in version 1.4.8 it now reports FINISHED 100.00% VIDEO.

That is what has changed between 1.4.8 and earlier versions which appears to be confusing MeGui.


From 1.4.8. changelog:
* When showing the film versus video percentage, DGIndex always now shows film percentage if it is greater than or equal to 50%, or video percentage if it is greater than 50%. Of course the sum is 100%.

[carlo_0000]

i have the same probleme change 25fps to 23.9 end the output video is shorter than the audio stream

[neuron2]

* When showing the film versus video percentage, DGIndex always now shows film percentage if it is greater than or equal to 50%, or video percentage if it is greater than 50%. Of course the sum is 100%. Yes, I agree. Good work.

Do you people want me to make a 1.4.9 backing out this change? Or do you want to adjust MeGui?

[Jeffster]

Yes, I agree. Good work.
Thanks neuron2.

Actually the decision by MeGui seems a bit odd when I read back on it, because if a vob is indeed 100% VIDEO then naturally one wouldn't use force film in that case anyway... I guess it is programmed to only look at the percentage not whether it's a % of FILM or VIDEO.

Yep, I just tested a NTSC interlaced vob (100% VIDEO) and D2v Creator activates force film on that too, so it's not restricted to PAL only... I guess it wasn't noticed by MeGui users because 23.976 is a valid NTSC framerate.

[iNFO-DVD]

Do you people want me to make a 1.4.9 backing out this change?No, please, I beg you, don't change it, it's much better as it is. Apart from avi.NET other programs have also now changed over to account for the mentioned change.

Please ;)

[neuron2]

Please ;) OK, it will stay as is.

[Sharktooth]

uhm, i must be blind...
need a new pair of googles...

[Doom9]

guess it is programmed to only look at the percentage not whether it's a % of FILM or VIDEO.Considering that since the stone age dgindex never reported anything but the film percentage in the d2v file, there's no point in bothering to parse the whole last line in a d2v file.
it's much better as it is.Would you care to explain? It's simple math... 100 = % Film + % Video. It makes very little difference what is written in the d2v file, so the only reason you consider it "much better" is because you changed AVI.NET and don't want to change back.

[iNFO-DVD]

Considering that since the stone age dgindex never reported anything but the film percentage in the d2v file, there's no point in bothering to parse the whole last line in a d2v file.The FILM/VIDEO issue was discussed a while ago, like a few weeks ago when it initially surfaced that the changed had been made, I already discovered this and made the relevant change to avi.NET. Another program author in the thread did the same and I'm sure others have followed. It just seems strange that we now go back to the old method just because the author of MeGUI included the DGIndex program that had changed without checking or it's users updated DGIndex without being aware of the change.

It makes very little difference what is written in the d2v file, I agree as long as we all know what it is.

[Sharktooth]

As a workaround i forced the megui autoupdate to downgrade from 1.48 to 1.47 until we come to a solution.

[check]

When I first read the problem that was identified it took me a few reads to actually see what the problem was, my eyes were not noticing that one line said 'film' and the other 'video'.
When viewing a single d2v by itself without any context to show what all the values could be this could turn out to be extremely confusing, it would seem to be a far better design choice to keep the output as consistant as possible across all output scenarios. So I would like to see consistant usage of 'Video' or 'Film'.

As to which I'd prefer, sticking with what has been used so far seems the best method. There is little to recommend one over the other so again - a consistant output (this time with previous versions) would be most logical.

[Sharktooth]

agreed

[Doom9]

well, it's don's decision and I've just updated the SVN.. the new code works with both old and new version and it's just a simple one liner.
because the author of MeGUI included the DGIndex program that had changed without checkingI bet you you check every single line of each d2v file when you ship a new version :P

[iNFO-DVD]

I bet you you check every single line of each d2v file when you ship a new version :Plol, ok, you got me there... :D

[neuron2]

It seems to me that regressing to the old way wouldn't break apps that have been updated. Since they should be looking for "Film" and "Video", they will just see "Film" all the time and everything will be fine. Am I wrong?

I didn't think that such a small change could create this mess. Sorry.

[Doom9]

I didn't think that such a small change could create this mess. Sorry.Well, I guess the problem mostly came from nobody realizing that this particilar line in the changelog not only refers to the indicator in the GUI but the d2v file as well. It took about a minute to fix it, most of which I spent looking for the right file. Maybe it would be prudent to spell out this change in the changelog just in case.

Am I wrong?In case of MeGui you are correct. The line in question is if (line.IndexOf("FINISHED") != -1 && line.IndexOf("FILM") != -1) // dgindex now reports VIDEO % if it's > 50%

[squid_80]

Don't you need to check the percentage as well, in case the user is still using an old version?

[iNFO-DVD]

regressing to the old way wouldn't break apps that have been updatedincorrect in my case
see "Film" all the time and everything will be finenot fine
I guess the problem mostly came from nobody realizingThis change occured back in June.....

It wouldn't matter what method was used as programmers would just make the relevant amendments to their programs but considering this was discussed back in June and programs changed, we now might have to change back..... Just seems weird.

[Doom9]

Don't you need to check the percentage as well, in case the user is still using an old version?What I posted is the if that decides if we even bother to look at the percentage ;) It wouldn't be such a great mechanism if all it took was FILM.. imagine 1% FILM in old versions... ewww. But not finding film means there's certainly no force film to be applied.

we now might have to change back..... Why? The change has been made.. so far I've not heard compelling arguments why the old way of doing things would be better or worse.. it's just different.

[squid_80]

What I posted is the if that decides if we even bother to look at the percentage
I guessed it probably worked that way, but I was also addressing Neuron2's post about new apps being (not) fine if things reverted. IMO any app that has been changed to accept the new syntax should be able to handle the old as well, that way if it is decided at any point to change back there won't be any problems. Also it would be a bit of a pain if an older unmaintained program "X" required dgindex <1.4.8 and program "Y" required dgindex >= 1.4.8.

[iNFO-DVD]

if it is decided at any point to change back there won't be any problemsand when does that usually happen? When would a programmer change something in a program because of an update in another program and think, oh yes, I'll leave the old commands in incase the programmer doesn't like it and changes it back?
bit of a pain if an older unmaintained program "X" required dgindex <1.4.8well that would be normal wouldn't it, would you expect an unmaintained program to work with all future versions of DGIndex? The programmer can't see the future, using that thinking DGIndex wouldn't be able to change it's D2V format ever again.....

This thread is getting funny :D

[squid_80]

When would a programmer change something in a program because of an update in another program and think, oh yes, I'll leave the old commands in incase the programmer doesn't like it and changes it back?

A smart programmer would look at it and say if I check the percentage I can support both old AND new versions.
well that would be normal wouldn't it, would you expect an unmaintained program to work with all future versions of DGIndex? The programmer can't see the future, using that thinking DGIndex wouldn't be able to change it's D2V format ever again.....
No, I'd expect the program to check the .d2v version string. Unfortunately that's not sufficient in this case as there can be 2 different styles for DGIndexProjectFile13. Hence if your app accepts ProjectFile13 files it should handle both cases and if DGIndex is going to stick with VIDEO/FILM the project file version should be incremented ASAP.

[iNFO-DVD]

both old AND new versionsno, DGIndex gets included with my installed program so I only have to have it work with that version, you assume the DGIndex with avi.NET is interchangable. A 'Smart' user would use versions not tested for a particular program.
should handle both casesno it shouldn't. The program was changed, I amended.

Shall I add code to my AVISynth scripts incase someone want to uninstall v2 and put v1 in instead, best add code and filters then for v1.

[squid_80]

no it shouldn't. The program was changed, I amended. I wasn't talking about your program in particular, I was talking about *any* program that was changed. Look at Doom9's change for MeGUI - one single line and it can handle both cases. If you think supporting both cases is wrong, that's your choice. If it causes problems then you'll have to deal with it, whereas you could guard against that with very little effort.