[RESOLVED] Processing PAL DVDs

[Aleron Ives]

I have a similar question to the recent discussion in the Best practice for deinterlacing 25FPS TS? thread, but I'm dealing with PS (VOB) from a DVD, rather than TS from HDTV, so a separate thread seemed appropriate.

I've inspected the content of my DVD in VirtualDub without any deinterlacing, and I haven't noticed any combing artifacts, so it seems that the stream is progressive. I'm wondering if there is anything special I need to do to process it, as this script:

Code: Select all

LoadPlugin("...\DGDecodeNV.dll")
LoadPlugin("...\Decomb.dll")
DGSource("vts.dgi")
AssumeBFF()
Telecide(guide=2,post=0)
Crop(8,0,-8,-0)

and this script:

Code: Select all

LoadPlugin("...\DGDecodeNV.dll")
LoadPlugin("...\Decomb.dll")
DGSource("vts.dgi")
Crop(8,0,-8,-0)

seem to both produce visually identical results and also are equally fast. Is there any reason to invoke Telecide when post-processing seems unnecessary (e.g. if the PAL guidance is still useful for reconstructing the progressive frames), and if I did have a PAL DVD that exhibited combing artifacts, would Telecide (with post-processing, of course) be a better way to handle it than using deinterlace=1 to invoke nVidia's deinterlacer?

My guess is that both nVidia and Decomb are capable of providing similar results, so the decision of which to use is mostly a matter of preference, but I wanted to make sure I wasn't overlooking something, as I'm unfamiliar with handling PAL content and didn't want to process multiple discs using faulty settings. Thanks!

[admin]

Hi Aleron.

There is a thing called a one-field phase shift that can cause a progressive stream to look combed. Normally if we denote a frame boundary by [] and the fields by letters, we would have:

[aa][bb][cc]...

But sometimes a field can be lost or edited out so we have:

[ab][bc][cd]...

Then the frames look combed and the WRONG thing to do is deinterlace it! That's where Telecide() comes in. It rematches the fields to make the original progressive frames.

If you know that the stream has no phase-shift sections, then you can omit Telecide(). But sometimes there are multiple phase shifts due to bad editing, etc., and Telecide() will automatically correct them all.

Feel free to follow up if you have any further questions about it.

[Aleron Ives]

Thank you for the information! I had a feeling Telecide's decision making ability would prove beneficial over the simple deinterlacing nVidia offers. Would I also be correct in assuming that Telecide is able to match the fields correctly even without post-processing enabled (as that's for ameliorating combing that still exists after the match process)?

[admin]

Yes, it is possible to turn off postprocessing. But bad edits can leave orphaned fields, which cannot be matched. So study the source carefully and use postprocessing when it appears needed. You can set a high threshold so good matched frames are not touched but gross mismatched frames get deinterlaced.

Some streams are well behaved and you can get away with no processing at all other than DGSource(). Everything depends on the specific source stream. You have to look at it in some detail before deciding how to process it.

[Aleron Ives]

Yes, I had skimmed the clip in VirtualDub to see if I could find any sections that had artifacts, but I couldn't find any, so it seemed like post=0 was safe for this clip. In the interest of making an informed decision, however, I decided to process the clip again with post=2, and I discovered that one of my assumptions about postprocessing was incorrect. I had thought that calculating the vmetrics would slow the encode, even if deinterlacing didn't occur, which doesn't seem to be the case: with vthresh=90, my encode proceeded at the same speed (and actually ~0.1 fps faster, probably due to variations in system load between encodes), and I created a bit-perfect match to the post=0 encode, since none of the frames (including the ones I didn't check) had a vmetric > 89.

I guess this just proves that for this particular clip my guess that postprocessing wasn't needed was correct, but since I don't have the time to check every frame in every clip I intend to encode and postprocessing with a high vthresh doesn't reduce the encoding speed the way I erroneously thought it would, I will leave postprocessing enabled to prevent severe combing from slipping through on future clips. If my conclusions are correct, I think that this thread is now resolved. Thanks again.

[Aleron Ives]

As a follow-up, do the above benefits of Telecide also apply when DGIndexNV reports a Sequence of "Frame Only" and Field Order of "Progressive"? The main episodes on this DVD appear as Field/Frame with a TFF Field Order, but the special features appear as Sequence: Frame Only and Field Order: Progressive, which would seem to indicate that neither AssumeTFF() nor Telecide are required for them. The strange thing is that, unlike NTSC sources, selecting the wrong field order does not produce jerky motion; neither AssumeTFF() nor AssumeBFF() seem to have any effect, even on the episodes that DGIndexNV reports as being interlaced.

For comparison, DGMPGDec reports TFF and Progr Sequence/Frame: False for the main episodes with info=1 in the MPEG2Source command, while the special features register as BFF and Progr Sequence/Frame: True. Since the field order doesn't seem to have any effect, I'm not even sure if I should be setting it. As I recall, TFF is the default in AviSynth, so using AssumeTFF() and omitting the command would be the same. Since neither seem to have any effect, does that mean it doesn't matter?

Is this an example of the fact mentioned in the manual that the way the streams are flagged does not necessarily represent their content (thus requiring a manual examination), or am I missing something? (Also, is there an equivalent to info=1 for the DGSource command to make it display the same type of information as DGMPGDec? Judging by the manual, there is not.) I'm guessing that there is still a danger of the "one-field phase shift" you mentioned happening due to poor editing in a stream that registers as progressive, so I should still use Telecide to be safe, but should I also omit explicitly setting the field order when DGIndexNV reports it as being progressive?

[admin]

As a follow-up, do the above benefits of Telecide also apply when DGIndexNV reports a Sequence of "Frame Only" and Field Order of "Progressive"? The main episodes on this DVD appear as Field/Frame with a TFF Field Order, but the special features appear as Sequence: Frame Only and Field Order: Progressive, which would seem to indicate that neither AssumeTFF() nor Telecide are required for them. The strange thing is that, unlike NTSC sources, selecting the wrong field order does not produce jerky motion; neither AssumeTFF() nor AssumeBFF() seem to have any effect, even on the episodes that DGIndexNV reports as being interlaced.

If the order does not matter, then the *content* is progressive.

For comparison, DGMPGDec reports TFF and Progr Sequence/Frame: False for the main episodes with info=1 in the MPEG2Source command, while the special features register as BFF and Progr Sequence/Frame: True. Since the field order doesn't seem to have any effect, I'm not even sure if I should be setting it. As I recall, TFF is the default in AviSynth, so using AssumeTFF() and omitting the command would be the same. Since neither seem to have any effect, does that mean it doesn't matter?

Field order does not matter if the content is progressive.

Is this an example of the fact mentioned in the manual that the way the streams are flagged does not necessarily represent their content (thus requiring a manual examination)

I don't think so, maybe you could explain that a bit more. It seems to me that the encoder flagging and the content are both indicating progressive video.

Also, is there an equivalent to info=1 for the DGSource command to make it display the same type of information as DGMPGDec? Judging by the manual, there is not.)

Refer to the debug option described in the DGDecodeNV manual.

I'm guessing that there is still a danger of the "one-field phase shift" you mentioned happening due to poor editing in a stream that registers as progressive, so I should still use Telecide to be safe, but should I also omit explicitly setting the field order when DGIndexNV reports it as being progressive?

You have to understand what DGIndexNV reports. It describes the encoding and not the content. It's crucial to understand that distinction. You have to manually inspect the content to decide the proper treatment. The encoding parameters may sometimes give you some clues but it's the content that really matters.

[Aleron Ives]

You have to understand what DGIndexNV reports. It describes the encoding and not the content. It's crucial to understand that distinction.

With that in mind, would I be correct in thinking that DGIndexNV is reporting the pulldown pattern used to convert the progressive content into interlaced format for display on SDTVs? It was my understanding that all DVD-Video discs will specify a pattern to ensure their content will display on interlaced sets, since progressive content would need converting to display on a CRT (and progressive film content would need converting from 23.976 -> 29.97 fps).

Refer to the debug option described in the DGDecodeNV manual.

Thanks.

Now that I have determined my content is progressive, would I be correct in thinking that I can just process it with DGSource alone and omit Telecide? I've never come across an NTSC source that was so clean, so I thought I must have been missing something.

[admin]

With that in mind, would I be correct in thinking that DGIndexNV is reporting the pulldown pattern used to convert the progressive content into interlaced format for display on SDTVs? It was my understanding that all DVD-Video discs will specify a pattern to ensure their content will display on interlaced sets, since progressive content would need converting to display on a CRT (and progressive film content would need converting from 23.976 -> 29.97 fps).

It's all in the documentation. You have to read it. Yes, if soft pulldown flagging is present it is reported. Hard pulldown may also be present and it can be seen only by inspecting the content.

Now that I have determined my content is progressive, would I be correct in thinking that I can just process it with DGSource alone and omit Telecide? I've never come across an NTSC source that was so clean, so I thought I must have been missing something.

As we have discussed, if you are sure there are no orphaned fields or phase-shifted segments, then you can process using only the source filter, without field matching or adaptive deinterlacing.

[Aleron Ives]

Thanks for all the help. A few of the special features weren't progressive and needed cleanup, but the main episodes were fine.

[admin]

Good to hear! Thanks for the status update.