DVDrebuilder and IVTC

[solvalou]

I was wondering how dvdrebuilder deals with progressive material.

1 - When it reencodes in CCE does it do an IVTC before feeding CCE ?

2 - Also how it deals with hybrid sources ? Will the progressive sections be IVTCed and pulldowned ?

regards

[wmansir]

DVD-RB recreates the progressive/interlaced state of the original EXACTLY. It basically copies the original TFF/RFF flags, encodes the RAW video, then applies the flags from the original to the output. That means you don't have to worry about progressive/Interlaced, pulldown, IVTC or even Field Order.

[Noah]

When you enable "Deinterlace with Decomb," are the flags changed to reflect this?

EDIT: If not, will setting Pulldown=1 in rebuilder.ecl do this?

[wmansir]

Originally posted by Noah
When you enable "Deinterlace with Decomb," are the flags changed to reflect this?

EDIT: If not, will setting Pulldown=1 in rebuilder.ecl do this?

I don't know. That setting wouldn't fix it if it were a problem, the change would have to be in the .flg files or be corrected on-the-fly during rebuild.

[solvalou]

Just one more question. Ok now I know that IVTC is not needed and the flags are encoded exactly like the original mpeg2 but I was wondering how the "progressive", "zigzag" and the other specifically designed options to encode progressive materials are dealt with in CCESP for hybrid sources. In the same sequence you can have pure progressive material that should be encoded with the "progressive" option turned on on CCESP and also video interlaced material that should have this option turned off. How does it work ?

[wmansir]

I think (although I am not sure) the 'progressive' setting is one of the flags restored on rebuild, it has no impact on image quality but just informs the DVD player what kind of material it is dealing with.

So the only real setting that can be non-optimal is the scan order. Unfortunately, this has to be set for one or the other for each encoded segment, depending on whether DVD-RB treats the segment as interlaced or progressive. But the good news is this setting has very little impact on image quality in my experience.

[solvalou]

nice :)

Thanks for all the info !

[Trahald]

just as a side note.. can you do ivtc? if there is hard telecining then you would actually gain quality by doing so.

[fritzdis]

I don't have a full enough understanding of the inner workings of all the programs involved in the process or of the exact structure of a DVD to know if what I'm about to say is accurate, but I think it's worth putting the idea out there. Also, it may seem at times like I'm trying to sell the idea as worthwhile. That is because DVD-RB is so close to perfect in this area already that it may not seem worth addressing. Anyway, here goes.

Originally posted by wmansir
I think (although I am not sure) the 'progressive' setting is one of the flags restored on rebuild, it has no impact on image quality but just informs the DVD player what kind of material it is dealing with.

So the only real setting that can be non-optimal is the scan order. Unfortunately, this has to be set for one or the other for each encoded segment, depending on whether DVD-RB treats the segment as interlaced or progressive. But the good news is this setting has very little impact on image quality in my experience.
With the ConvertToYUY2() option checked, the inclusion or exclusion of interlaced=true would also result in some (possibly unnoticable) image degradation, right? Though the extent to which this setting and the scan order setting will affect image quality is debatable, they will, as a matter of theory at least, have a negative impact, correct?

Hybrid material is about as difficult to get "right" as anything a backup solution can encounter. If the two problems listed above are the only problems DVD-RB has to deal with when it is fed hybrid material, then it exceeds the capabilities of any other one-click solution that I know of (as well as the capabilites of many of the more complicated methods). However, there is still room for improvement.

It seems to me that DVD-RB is uniquely capable of "perfect" reproduction of hybrid sources. It is the only backup solution I know of that retains the exact flag structure of the original. It is one of the few that regularly breaks the video down into segments and then recombines those segments. These two facts could, I believe, could allow DVD-RB to encode every bit of progressive material as progressive and every bit of interlaced material (truly interlaced, that is; progressive material flagged as interlaced might be another issue) as interlaced.

Here is where my lack of knowledge about DVD structure could be a problem. How easily/exactly could one identify a series of frames (of any length) as progressive or interlaced? This identification is the key to the idea and the part I know the least about. If segments (not segments as DVD-RB currently sees them, but rather, any series of frames) of the video can be identified as entirely progressive or entirely interlaced, then corresponding AVS and FLG files for that segment could be created and CCE (or any other encoder that has settings specific to progressive or interlaced material) could encode the AVS as either progressive or interlaced. My feeling is that recombining these segments would not be that difficult, but again, I lack the knowledge to say for sure.

Some potential pitfalls that come to mind are:

Would there be a danger of identifying a single frame as a "segment" and would this cause problems in the recombination? If so, perhaps a minimum segment length could be imposed.

Would the recombination interfere with GOP structure?

If there are lots of small segments, would the benefits of multipass VBR enoding be lost since each segment will have to be assigned a bitrate? Even in DVD-RB's current form, this issue could be raised, but segments are generally big enough that this isn't currently a problem.

What would be done with originally progressive material that was encoded as interlaced? It seems that this material could be IVTC'd and DVD-RB could then adjust the flag structure appropriately. If not, this material would still end up no worse off than if it were processed by the current version of DVD-RB. In fact, it might still be improved by treating it as interlaced.

I forgot a few of the issues I had considered because it took so long to write this, and I'm sure there are other issues that I haven't thought of. Feel free to point out all the problems I've overlooked in my thickheaded excitement :).

For now, I'm mostly trying to find out whether such a solution would be possible. The issue of practicality is something I'd like to put off somewhat until the possibleness of the idea is examined.

If you're still reading, thanks. That was a really long message.

[jdobbs]

There is a flag in the extension start code for each frame that identifies whether or not the frame is progressive.

Trying to break the source down to the level you suggest would definitely nullify the advantages of VBR and result in extremely poor video quality. On a hybrid input stream you would get thousands of segments.

Using IVTC is never a recommended method (at least from me). At least not in the context of the the slew of inverse telecining filters. If someone took a FILM source and encoded it as interlaced, the damage is done -- and can't be undone. The exception is truly progressive sources that only have the flags set as if it were interlaced (which sometimes happens in PAL -- but not generally in NTSC (converting FILM to NTSC requires framerate changes -- PAL just alters the temporal view slightly). You may run across an occasional NTSC source the was first done as telecined and then the telecined output was input into an encode as interlaced... but that is very, very rare and is an indicator of truly poor authoring. You are better off leaving these messes only slightly butchered rather than butchering it more.

[Note Added] When DVD-RB does encoding of properly telecined sources, they keep their progressive nature through the encode -- DVD-RB examines the MPEG stream directly, not an output that includes pseudo frames created by the telecining process.