When parsing a VOB through DgIndex I've encountered a "field order transition detected" and DgIndex offers to fix the d2v but says it cannot detect if it should be done. When do you want to fix it? I've read that it could be related to a decryption error, but how do I know that it is the case and not something else? (And can DgIndex fix the d2v correctly or not?)
+ Reply to Thread
Results 1 to 9 of 9
Did you read what the DGIndex User Manual has to say about it?
Sometimes streams are encountered that contain mixtures of TFF and BFF material. In MPEG2, these field order transitions are fixed at display time via the TFF/RFF flags. But we usually want to output a stream with one consistent field order, and some tools, such as Telecide and (Leak)KernelDeint, require a fixed field order. Indeed, AVI does not carry a field order property!
This tool adjusts the TFF/RFF flags so that a stream with a single field order is output. This affects only streams containing field order transitions, of course. When field order correction is applied using this tool, the uncorrected D2V file is renamed so that it ends with the extension ".bad". The corrected version is output as the usual D2V file.
This tool should be used only when you have reason to believe that field order transitions are present in the stream. For some pathological streams, however, you may find that the field order correction causes problems that you don't encounter when using the ".bad" D2V file. Therefore, it is always advisable to treat the correction as an advisory and to test both the good and bad D2V files.
Note that field order correction should not be applied to streams containing frame repeat RFFs.
In most cases you want to use the 'fixed' D2V file.
Yes and unfortunately it's a little obscure.
should be used only when you have reason to believe that field order transitions are present in the stream (...) should not be applied to streams containing frame repeat RFFs
Just look at the file it saves. It's where the 0's change to 2's or vice-versa. The field order switches. You don't want that and it royally screws up TIVTC if you're IVTCing the thing and it won't let you IVTC until it's been fixed.
Decryption has nothing to do with it.
The fix file says
D2V Fix Output Field order transition: 0 -> 2 d00 6 1 776994816 0 1 6 90 b0 b0 a0 b0 b0 a0 b0 a0 d00 5 1 777056256 0 1 7 92 ff corrected... d00 6 1 776994816 0 1 6 90 b0 b0 a0 b0 b0 a0 b0 a1 d00 5 1 777056256 0 1 7 92 ff
But then again I'm not entirely convinced it's interlaced, it looks like it was deinterlaced very poorly, because I can see some weird square pattern... so it might be unrelated to the field transition. Especially since when using the fixed d2v the combing is untouched
[Attachment 49391 - Click to enlarge]
TFM does the trick, but is it safe to TFM the whole video, or should I encode both parts independently?
TMF() can sometimes cause problems. It may see alternating thin horizontal lines (like window blinds) as comb artifacts and deinterlace the frame causing moire artifacts. TFM(pp=0) can usually alleviate that. But that may sometimes let interlaced frames through -- like when you have orphaned fields.
There's no need to encode the parts separately though. You can just split the video within the script and filter the parts differently.
WhateverSource() part1 = Trim(0,10000).Filters() part2 = Trim(10001,0).OtherFilters() part1++part2
Last edited by jagabo; 17th Jun 2019 at 08:23.
Perfect, thank you, both of you!