Log in

View Full Version : Clarification of DVD-RB's D2V generation


SansGrip
21st July 2004, 20:10
DVD-RB now keeps the original frame structure intact through all three phases

I interpret this, and the fact that DVD-RB generates a D2V file with every frame set to "TFF no RFF", to mean that upon rebuilding DVD-RB sets the field flags in the new video stream to be consistent with those in the old video stream.

Is that correct?

That's a pretty clever way of handling it, and means the new video will never be "worse" (wrt interlace artifacts etc.) than the original. However, I see two drawbacks to this approach, both stemming from the fact that Avisynth and the encoder aren't seeing the frames as they're "meant" to be seen:

1) Filters (except deinterlacers and some/all resizers) should be run on progressive material. While a lot of DVDs are encoded and authored properly so that no corrective procedures are necessary, this is often not the case. Some titles really do benefit from some preprocessing, whether it be a smart IVTC (telecide/decimate) because of a sloppy application of telecine or editing done after telecine has been applied, or have a great deal of noise which will eat up precious bitrate when re-encoding. Such corrective measures are currently impossible, or suboptimal.

2) The encoder is, for a lot of titles which have been "hard telecined" (had pulldown applied prior to being encoded as "interlaced"), not seeing the original material. It's actually seeing a telecined version of it. This means the encoder is working with decidedly suboptimal material which adversely affects overall compressibility.

For example, I'm currently re-encoding The Shield Season 1 Volume 1 (R1), containing four episodes of a 4:3 TV show. It was mastered a little sloppily and is decidedly "hybrid" -- the D2V from DVD2AVI shows many long stretches of 2s throughout the usual 0 1 2 3 telecined material, and also a large number of oddities like 0 1 2 2 3 2 0 1 2 ...). Normally I would use Decomb to correct this kind of thing and feed the filters and encoder genuinely progressive material. I can't do this with DVD-RB at the moment, and (particularly with this title) the original mastering errors are clearly visible as artifacts when played on my HDTV (just as they are when I play the source disc, of course).

I propose one way to enable this kind of "cosmetic surgery" to be used with DVD-RB:

Default to "forced TFF, no RFF," but provide another mode which generates "vanilla" D2Vs containing the actual field flags for each frame. You would still only need to produce one D2V file for the entire stream.

Advanced users could then use the available Avisynth tools to correct badly mastered originals, and feed the encoder as close to the original, progressive source as we can get.

DVD-RB could then, in the rebuild phase, set the field flags to indicate a pulldown over the entire stream.

Of course, this provides enormous potential to mess things up (which is why DVD-RB should of course default to the current mode), but that comes with the territory when doing things like selective IVTC in Avisynth.

DVD-RB is an awesome tool, and I bow to the author wrt the remuxing portion alone. But just because DVD-RB has an outstanding "one-click" mode doesn't mean it can't provide more control to advanced users who aren't satisfied with simply duplicating the mastering errors of the original, but want to produce a backup that's even better than the source.

P.S. I just initiated a transfer from my bank account to PayPal and shall be donating as soon as it goes through (usually 5-6 days because it's coming from Canada). I wish I was able to donate what I think the author really deserves, but if I do that the kids won't be eating for a month or so ;).

TheSeeker
21st July 2004, 21:10
You say that normally you would use decomb to fix these mastering errors... Why cant you use the decomb filter in dvdrb?? I must have missed that.

SansGrip
21st July 2004, 21:14
Originally posted by TheSeeker
Why cant you use the decomb filter in dvdrb??
I believe in DVD-RB Decomb is only used to deinterlace, and not to do any kind of IVTC.

SansGrip
22nd July 2004, 18:15
Bump. Don't want this one getting lost before JDobbs has a chance to respond :).

jdobbs
24th July 2004, 01:14
Originally posted by SansGrip
I believe in DVD-RB Decomb is only used to deinterlace, and not to do any kind of IVTC. That could cause a problem because DVD-RB wouldn't be able to predict the frame count (since it is unpredictable what the results of an inverse telecine might produce).

SansGrip
24th July 2004, 03:19
Originally posted by jdobbs
That could cause a problem because DVD-RB wouldn't be able to predict the frame count (since it is unpredictable what the results of an inverse telecine might produce).
It's true the code wouldn't be able to predict the resulting frame count, but could it not do a pre-scan of the ES and count the picture start headers? This would of course result in longer processing time, but that would be an unavoidable cost of quality.

jdobbs
24th July 2004, 04:21
I don't know. It sounds like a lot of work for something that doesn't happen that often.

SansGrip
24th July 2004, 05:06
Well, I figure you must already have code for MPEG-2 ES scanning, since you'd have to have that in order to mux. It wouldn't be too hard to adapt the code to count up the picture start headers.

Alternatively, an external tool could do it. Basically I envisage this as a "custom phase 2": DVD-RB would generate its files as usual in phase 1, except that the D2V file would reflect the actual field flags. Then an external tool would do the encode phase, and update the FLG files accordingly. DVD-RB could then get the new frame counts from the FLG files, since one byte equals one frame. I think that would add an enormous amount of flexibility for the power user.

As for it not happening often, personally I use filters more often than not when re-encoding. Often it can be for a single scene where I notice bad combing, or to pull down the noise level a little for better bit distribution. While it's possible to (sort of) do those things right now, it's not optimal because what Avisynth sees is not always the "real" progressive video, for example in the case of material that's been telecined before encoding.