Field order transition?

[Karl Beem]

I'm working on a 720p HDTV video. This is a glitchy clip that required a Videoredo quickstream fix before anything could be done with it. The file was then edited with Videoredo. When demuxed with the latest DGIndex, I got the Field Order Transition message. I chose to accept the fix. After encoding, the audio became more and more out of sync. However when I used the .d2v.bad file, the result was perfectly in sync. Since this is a progressive video, Should field order be important? Is this a result of the video's glitchiness?:confused:

[Guest]

From the users manual:

"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."

Field order doesn't matter for progressive video, but telecining can complicate that simple statement.

Probably the stream errors are the cause.

[Karl Beem]

:thanks:

[hkazemi]

The DGIndex manual says:
Note that field order correction should not be applied to streams containing frame repeat RFFs.

How does one know if there are frame repeat RFFs?

Can this be detected automatically? (the manual says there TFF and RFF flags...so does that mean if any RFF flags are present, field order correction shouldn't be used? )

The manual also says:
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.
Do all deinterlacers need consistent field order to work correctly? Is there a general rule for filters and field order like "Any filter that needs to work on a pair of fields also needs consistent field order?"

Why would letting DGIndex correct the field order possibly lead to a loss of audio sync? Is that because DGIndex is inserting or removing video frames to make the field order consistent?

If fields are being inserted/removed to get the field order back in line, then I think a good strategy would be to alternate the addition and removal of a single field on each field order transition, so that there isn't an overall buildup or shortfall in the total video fields. Alternatively, if a deinterlacer knows there are field transitions taking place, I think it could use this information to do a better job of deinterlacing the affect frames, possibly by scaling that field to a full height frame. This would probably also need to be a 'hint' to the deinterlacer.

[Guest]

How does one know if there are frame repeat RFFs? There is a field in the Info dialog that gives a count of frame repeats encountered.

Can this be detected automatically? (the manual says there TFF and RFF flags...so does that mean if any RFF flags are present, field order correction shouldn't be used? ) You can generate the info log dump through the CLI and check for frame repeats. RFF may mean field repeat or frame repeat (depending on other syntax fields). You want correction only for field repeats.

Do all deinterlacers need consistent field order to work correctly? Some do and some don't. Typically if they have a parameter for field order, then they need it.

Is there a general rule for filters and field order like "Any filter that needs to work on a pair of fields also needs consistent field order?" No. For example, FieldDeinterlace() doesn't care about field order.

Why would letting DGIndex correct the field order possibly lead to a loss of audio sync? Is that because DGIndex is inserting or removing video frames to make the field order consistent? Each correction can insert or delete a field.

If fields are being inserted/removed to get the field order back in line, then I think a good strategy would be to alternate the addition and removal of a single field on each field order transition, so that there isn't an overall buildup or shortfall in the total video fields. Alternatively, if a deinterlacer knows there are field transitions taking place, I think it could use this information to do a better job of deinterlacing the affect frames, possibly by scaling that field to a full height frame. This would probably also need to be a 'hint' to the deinterlacer. Field order transitions are highly pathological. It would make much more sense to resolve that problem at the source.

[hkazemi]

There is a field in the Info dialog that gives a count of frame repeats encountered.

Each correction can insert or delete a field.

Field order transitions are highly pathological. It would make much more sense to resolve that problem at the source.

I agree that fixing the problem in the source would be much better, but the reality is these problems are going to be present in a lot of ATSC MPEG2 content broadcast recorded over the air. I think ATSC recording and processing is going to be the next big area in handling digital video. A few years ago (~2000) the tools and techniques for processing DVD content were in a similar situation of not handling stress test cases very well.

I have a ~3 minute 350 mb clip of ATSC 1080i recorded off PBS in the Twin Cities that I've been using as a stress test. The signal strength during original recording was poor, making this a pathological stream. This makes it a good test case for the handling of damaged digital video. I'm very interested in putting together a robust scripted processing chain; my hunch is that any processing chain that handle the stress test videos should be perfectly fine on regular recordings. (This also explains my interest in starting a library of broken transport streams that I explained in detail a new thread in the HDTV subforum.) My goal is to be able to take a MythTV recorded mpeg2 .ts file and turn it into an MKV container, holding AVC video encoded by x264, original AC3 audio, and closed captions/subtitles.

I first processed it thru mpeg2repair, then thru VideoRedo's QuickStream Fix. The DGIndex 100 frame preview log (command line option -preview) does not show any frame or field repeats. Manually loading the file into the DGIndex GUI and previewing it there shows me the field repeats begin around 850 frames in. I was not able to get field repeat information using any command line options, the command line preview doesn't play far enough into the file, and the command line full processing doesn't generate a log with this information.

My DGIndex command lines are:
dgindex -SD=" -IF="video.ts" -IA=2 -FO=0 -YR=1 -OM=2 -OF="video.ts" -PREVIEW -EXIT

and

dgindex -IF=[video.ts] -IA=2 -FO=0 -YR=1 -OM=2 -OF=[video.ts] -AT=[processingtemplate.avs] -EXIT

My questions are:
1.) would it be possible for DGIndex to output the full 'info' log when doing a complete processing, like the info displayed during a preview?
2.) do you know of any tools that can process a .ts to fix the field repeats without losing sync? (i.e. something that could alternate between inserting and removing the repeated field? (only a repeated field should be considered for removal; unique fields shouldn't be removed)).

[Guest]

1.) would it be possible for DGIndex to output the full 'info' log when doing a complete processing, like the info displayed during a preview? Doesn't it already do that if you enable the Info log in the INI file and you do not use the Hide option in the CLI?
2.) do you know of any tools that can process a .ts to fix the field repeats without losing sync? (i.e. something that could alternate between inserting and removing the repeated field? (only a repeated field should be considered for removal; unique fields shouldn't be removed)). It would be a simple application that processes the D2V file. Can you provide a test stream that generates the large audio offset that you are claiming is common?

[hkazemi]

Doesn't it already do that if you enable the Info log in the INI file and you do not use the Hide option in the CLI?

Not in my observations. This command:
dgindex -IF=[1022_20080103210000_Fixed 5min vrdo.ts] -IA=2 -FO=0 -YR=1 -OM=2 -OF=[1022_20080103210000_Fixed 5min vrdo.ts] -PREVIEW -EXIT

outputs one file (1022_20080103210000_Fixed 5min vrdo.log) containing:
Stream Type: Transport [188]
Profile: main@high
Frame Size: 1920x1080
Aspect Ratio: 16:9
Frame Rate: 29.970030 fps
Video Type: NTSC
Frame Type: Interlaced
Coding Type: B
Colorimetry: BT.709*
Frame Structure: Frame
Field Order: Top
Coded Number: 99
Playback Number: 99
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate: 13.524 Mbps
Bitrate (Avg): 13.754 Mbps
Bitrate (Max): 13.985 Mbps
Audio Stream: 0: AC3 3/2 384
Timestamp: 0:00:02
Elapsed: 0:00:15
Remain: 0:18:38
FPS: 5.43
Info:

Now I deleted this log file just in case it would clash with the next command:
dgindex -IF=[1022_20080103210000_Fixed 5min vrdo.ts] -IA=2 -FO=0 -YR=1 -OM=2 -OF=[1022_20080103210000_Fixed 5min vrdo.ts] -EXIT
This ran pretty quickly (showed the GUI, but the video was static in the GUI, although the progress bar moved across). The output files were:
1022_20080103210000_Fixed 5min vrdo.ts.d2v
1022_20080103210000_Fixed 5min vrdo.ts.d2v.bad
1022_20080103210000_Fixed 5min vrdo.ts.fix.txt
and an .avs file
(no .log file was created, just the above three)

DGIndex.ini says:
DGIndex_Version=DGIndex 1.5.0 RC 2
Window_Position=341,136
Info_Window_Position=100,115
iDCT_Algorithm=2
YUVRGB_Scale=1
Field_Operation=0
Output_Method=2
Track_List=
DR_Control=2
DS_Downmix=0
SRC_Precision=0
Norm_Ratio=100
Process_Priority=2
Playback_Speed=3
Force_Open_Gops=0
AVS_Template_Path=C:\1 video processing\dgindex\processingtemplate.avs
Full_Path_In_Files=0
Fusion_Audio=0
Loop_Playback=0
HD_Display=0
MRUList[0]=C:\1 video processing\test\1022_20080103210000_Fixed 5min vrdo.ts
MRUList[1]=dgindex\processingtemplate.avs
MRUList[2]=k:\go\1022_20080103210000_Fixed 5min vrdo.ts
MRUList[3]=K:\go\1022_20080103210000_Fixed 5min vrdo.ts
Enable_Info_Log=1

It would be a simple application that processes the D2V file. Can you provide a test stream that generates the large audio offset that you are claiming is common?
I'm not the original poster (Karl Beem) who reported a file with progressively losing sync, but I believe I have a file that will have sync problems if the comments about field transitions are consistent. The full file is 350mb...do you have a 'testing' ftp folder?

P.S.: filenames with spaces are not handled properly when also enclosed in quotes, if the delimiter is not set to quote. The quotes come from Windows autocompleting filenames. e.g.
dgindex -IF=["1022_20080103210000_Fixed 5min vrdo.ts"] .... doesn't work right (I reported this on your forum).

[Guest]

no .log file was created It's a bug. I'll fix it for 1.5.0 final.

I'm not the original poster (Karl Beem) who reported a file with progressively losing sync, but I believe I have a file that will have sync problems if the comments about field transitions are consistent. The full file is 350mb...do you have a 'testing' ftp folder? Yes, I do, but you say you only "believe" you have a good test file. Before I get 350MB from you please test it and tell me what the reported delay is and what you think the cumulative sync offset becomes. It would be useful if you post links to the bare and fixed D2V files.

IIRC, I believe tritical at one time made a better Fix D2V application, but I don't remember the details.

[hkazemi]

It's a bug. I'll fix it for 1.5.0 final.

Yes, I do, but you say you only "believe" you have a good test file. Before I get 350MB from you please test it and tell me what the reported delay is and what you think the cumulative sync offset becomes. It would be useful if you post links to the bare and fixed D2V files.

IIRC, I believe tritical at one time made a better Fix D2V application, but I don't remember the details.

Searching for 'tritical Fix D2V' found me numerous posts in the thread TDeint and TIVTC, including these that seem to be most relevant to our thread on field order transitions:
http://forum.doom9.org/showthread.php?t=82264#post998969&highlight=d2v
http://forum.doom9.org/showthread.php?t=82264#post1003932
http://forum.doom9.org/showthread.php?t=82264#post1005957

http://bengal.missouri.edu/~kes25c/#c3
td2vfix and td2vparse - 12/22/2005 v1.3.3 (Released)
td2vfix is a command line tool that corrects illegal field order transitions in d2v files, and td2vparse is another command line tool that parses a d2v file and outputs some useful information such as: encoded to display frame mappings, field order, trf flags, gop starts/offsets, 3:2 pattern starts/breaks, illegal transitions, ignored rff flags, and more. The supported d2v formats include dvd2avi 1.76/1.77, dgindex, and dvd2avidg d2vs. These programs are based on D2VFix/D2VParse by Donald Graft.

Here is another mention of field order problems with ATSC recordings, that you responded to, but no one made any followup posts if it was resolved or not:

Field Order Switching on ATSC OTA Capture
http://forum.doom9.org/showthread.php?t=114764

I'm getting the impression that Tritical's TFM tool may be part of the answer to fixing field order transitions.

If you're interested, I've posted a 40 mb clip that has numerous field order changes in it. Granted the clip has more drop outs than I'd like for a 'keeper', however it is a dense collection of field order changes. Processed first by mpeg2repair, then VideoRedo Plus QuickStream Fix.
https://netfiles.umn.edu/users/kaze0010/brokenstreamlibrary/1022_20080103210000_Fixed%2020%20seconds%20vrdo.ts

Here is the start of the broken stream library I described at http://forum.doom9.org/showthread.php?t=134693 :
https://netfiles.umn.edu/users/kaze0010/brokenstreamlibrary/

[Guest]

Does the clip you linked show an appreciable cumulative AV sync loss due to the correction of the transitions? That's what I am interested in. I'm not interested in any old file with a bunch of errors in it.

[NorthPole]

I first processed it thru mpeg2repair, then thru VideoRedo's QuickStream Fix.

@hkazemi
Just curious as to why you use both mpeg2repair and then quickstream fix?

@neuron2
Is there way for DGIndex to generate a field corrected .d2v only if it does not find any frame repeats?


Thanks

[hkazemi]

@hkazemi
Just curious as to why you use both mpeg2repair and then quickstream fix?


Both are present in my program chain because they fix errors at different levels, and I'm trying to put together a video processing sequence I can use on my ATSC recordings without manual intervention. This description by VideoRedo's DanR may help:
http://www.videoredo.net/msgBoard/showpost.php?p=23056&postcount=37
VideoReDo fixes errors primarily at the stream level; Mostly sync issues and temporal references. I don't know what you mean by not seeing what's being repaired, they are all the in log file.

MPEG2Repair fixes errors at a lower level than VRD, down to the slice/macroblock level, but doesn't address some of the issues that VRD does.

@neuron2: I'm not done trying things with the clip, so I can't answer your sync question yet. The clip may not be so good for monitoring sync afterall, because of all the cut scenes where a loss of sync would not be obvious.

Thanks