Log in

View Full Version : Automatic Fix on PAL stream


mg262
18th September 2005, 23:58
I've been re-creating all my index files for an episodic project using DGIndex 1.4.4 RC1 with all settings at default and the arguments:

C:\Capture\dgmpgdec144rc1\DGIndex.exe -OM 0 -IF=[E:\dub\dvd\BS_1\VTS_01_PGC_06_1.VOB] -OF=[4 dvd] -EXIT

and I find that error correction and creation of a .bad file occurs. (I'm aware that this is automatic in the latest version.) The manual suggests that this is caused by: Rarely, a stream will be encoded with illegal transitions of the TFF/RFF (pulldown) flags.My source is PAL (and is detected as such), so I don't understand what's happening -- could someone be kind enough to explain why there are pulldown flags in the input at all? (Cf. this (http://forum.doom9.org/showthread.php?p=682478#post682478) post.) If it's any help, the bottom fields are one field out -- i.e. I was using this to fix it:

separatefields()
interleave( selecteven(), selectodd().trim(1,0) )
weave()

The video reports as interlaced while being previewed, but after the project is saved reports as progressive. All of the above persist across multiple episodes and also occur without using the command line interface.

Also, in previous versions I used the un-fixed d2v file in a number of scripts... is there any possibility that e.g. my trim commands are invalid with the fixed version?

Here is the relevant text file:

D2V Fix Output

Illegal transition: 0 -> 2
900 6 0 1256925184 7 2 90 b0 b0 a0 b0 b0 a0
d00 6 0 1257185280 7 3 d2
corrected...
900 6 0 1256925184 7 2 90 b0 b0 a0 b0 b0 a1
d00 6 0 1257185280 7 3 d2

And the two index files can be found at:
http://people.pwf.cam.ac.uk/mg262/posts/fixedd2v.zip

I hope that is all the relevant information... as ever, any help would be very much appreciated.

Edit: I can certainly try and cut out a small section of the source if that will be useful... but if so, please recommend a cutter -- I've had trouble finding a reliable one.

Guest
19th September 2005, 04:20
It affects only the last two frames of the file, so it's not worth worrying about. Is there another case worth worrying about?

mg262
19th September 2005, 05:41
Thank you for the reply.
Is there another case worth worrying about?
No, but the dialog box that warns of the error interferes with batch-file CLI processing.

Guest
19th September 2005, 14:15
Thank you for the reply.
No, but the dialog box that warns of the error interferes with batch-file CLI processing. There's not supposed to be a message box when CLI is active. I'll check that.

EDIT: It's a bug. I squashed it for the next release. Thank you for pointing it out.

mg262
19th September 2005, 14:50
Thank you for fixing it!

Cyberia
19th September 2005, 17:51
May I ask a question in the sincere hope I'm not committing blasphemy?

Why do we need FIXD2V? Why can't we integrate the functionality into the d2v generation process, so all d2v files are error-free initially? Would it slow the d2v process tremendously? Or is this one of those things that is easier to do once the whole d2v is parsed, than to do it *while* we are parsing?

Guest
19th September 2005, 21:18
The time difference is too small to be of consequence. So if it is already coded and working as a postprocess, what is the motivation to rewrite it? Also, there may be cases in the future where the automatic fix is wrong or where the "bad" file is needed. Theoretically it shouldn't be, but surprises do occur. Is it always right to do Fix D2V? Could there be some weird combinations of field structure, flags, etc., that makes it go astray? I don't know yet. So, until we know, it's better to keep the "bad" file around, as it accurately reflects the actual stream contents.

Cyberia
20th September 2005, 02:10
That makes sense. But if there was some kind of checking during the parse, you could pop up a mesage box that said "hey there was something fishy about that video, maybe you should run FixD2V"

As it is now, I don't know if I should use it unless something OBVIOUS went wrong.

Guest
20th September 2005, 02:21
As it is now, I don't know if I should use it unless something OBVIOUS went wrong. You've lost me there. Fix D2V is automatically applied at the end of the D2V creation. The D2V that results will never have illegal transitions. You don't have to decide to use it or not. If errors are found (and CLI is not active) you get a popup message box telling you that the bad transitions were repaired. Did I misunderstand you?

Are you perhaps arguing that the menu option Fix D2V should be removed? That's a sustainable argument in my view.

Cyberia
20th September 2005, 05:17
Fix D2V is automatically applied at the end of the D2V creation.
Oops. I had forgotten that fact.

Are you perhaps arguing that the menu option Fix D2V should be removed? That's a sustainable argument in my view.
Errr, ya! That's what I was suggesting. Exactly! Well Done.