I need a quick guesstimate, quickly

[ajmoss]

For the past couple of years I have been capturing analogue PAL TV broadcasts at 352x288 in MPEG-1 at 2.4 Mbit/s. This is about 60% more than the recommended MPEG-1 video bit rate of 1.5 Mbit/s, but I'm happy with it. Trial and error has shown that 2.0 Mbit/s is not enough to capture tricky images (such as snow scenes) without bad pixellation, whereas 2.4 Mbit/s does the job adequately.

My new video capture card, a Pinnacle PCTV Deluxe USB, only allows me to capture in MPEG-2 format at 352x576 (or 480x576 or 720x576, but I'm choosing 352 so I can reduce it to VCD format without having to deinterlace).

I need a quick guesstimate, to the nearest 0.5 Mbit/s, of how high the video bit rate should be to generate the same quality picture, as near as possible. I know this can't be answered precisely; that's why I only want an approximation.

Since the number of pixels has doubled, should I double the bit rate to 5.0 Mbit/s?

Since I will ultimately throw away the extra resolution, can I get away with keeping the bit rate the same as before, i.e. 2.5 Mbit/s?

Is the system-supplied preset, "DVD Longplay" (352x576, 3.5 Mbit/s) the most sensible compromise?

[Boulder]

Originally posted by ajmoss

I'm choosing 352 so I can reduce it to VCD format without having to deinterlace.

You do have to deinterlace (or discard one field) if you capture 576 lines regardless of the width.

[ajmoss]

Actually it's OK. MPEG-2 is a VBR format, which means it doesn't pad out the unused bytes with zeros; the quoted bit rate is no more than a maximum. I can confidently set the maximum bit rate at 6-8 Mbit/s, and still be sure that I can record an hour without going over 2GB.

[ajmoss]

Originally posted by Boulder
You do have to deinterlace (or discard one field) if you capture 576 lines regardless of the width.
Do you know if TMPGEnc or TMPGEnc Plus do that automatically, when converting ???x576 to VCD format at 352x288?

[Boulder]

TMPGEnc can deinterlace, but you'd get a _much_ better result by using Avisynth.

[ajmoss]

Originally posted by Boulder
TMPGEnc can deinterlace, but you'd get a _much_ better result by using Avisynth.
Using VerticalReduceBy2, I presume?

[Boulder]

No, that doesn't deinterlace/IVTC, it only halves the height.

I'd suggest Decomb (Telecide or FieldDeinterlace from that package) or TomsMoComp. See the capture guide, it contains some information on how to deal with the situation.

[jggimi]

I would only use fast deinterlacers like VerticalReduceBy2 when my final output is VCD or a similar small resolution. That's because while they work, they do so by merely cutting vertical resolution in half. The only advantage over other methodologies is speed, but because resolution is reduced 50%, resizing back to original size provides a significant loss of content compared to more complex deinterlacing filters.

But there are better "fast deinterlacing" methods than VerticalReduceBy2. For example, Gknot replaced VerticalReduceBy2 with SeparateFields / SelectEven for fast deinterlacing several releases ago.

[EDIT: Boulder was faster. Selecting only one field per frame prior to resizing (as Gknot does) will deinterlace content, though it will not IVTC. These "fast deinterlacers" are fast because they do not examine the content at all, and neither blend nor interpolate to remove artifacts. They reduce the content to do so. For examle, if I capture at 480 and my final size is 240, then I'm not concerned about retaining both fields of 100% interlaced content, and SeparateFIelds().SelectEven() produces the results I'm looking for.]

[Boulder]

Ah, I didn't remember that the side effect of VerticalReduceBy2() is deinterlacing:o

[ajmoss]

Originally posted by jggimi
I would only use fast deinterlacers like VerticalReduceBy2 when my final output is VCD or a similar small resolution. That's because while they work, they do so by merely cutting vertical resolution in half.
But I'm happy with the idea of deinterlacing to reduce vertical resolution, and my final output files are all at 352x288. Common sense dictates that the TMPGEnc deinterlacing method ("Even field" or "Odd field") does the same thing as VerticalReduceBy2, so is there any reason why I shouldn't deinterlace in TMPGEnc and save myself an Avisynth / VirtualDub step?

Incidentally, I'm thinking of using the "Double" deinterlace method in TMPGEnc to reduce the resolution from 352x576 to 352x288. I don't mind if this makes the deinterlacing slower. The help file gives the caveat that this makes still frames twice as large, but if the overall bit rate is restricted (as is the case with VCD files), surely this effect won't come into play?

[jggimi]

I don't "speak" TMPGEnc very well.

A search of the TMPG forum for "double" and "deinterlace" had three hits, none of which answered your question directly. You may want to open a new post there specifically about the filter.

[Wilbert]

No, that doesn't deinterlace/IVTC, it only halves the height.
By doing so, it deinterlaces. From the docs

The filter kernel used is (1/4,1/2,1/4), which is the same as in VirtualDub's "2:1 reduction (high quality)" filter. (...)
Iow, lines are used from different fields.

Of course, you will get much better quality (as other people notice) if you use (assuming width must remain the same):

SeparateFields
SelectEven # or SelectOdd

But also in this case you are throwing away information.


Common sense dictates that the TMPGEnc deinterlacing method ("Even field" or "Odd field") does the same thing as VerticalReduceBy2
No, it does something better. It does the same as SeparateFields.SelectEven / SeparateFields.SelectOdd.

The only difference is that it is converting to RGB first before deinterlacing. I don't know whether that is done correctly when feeding an interlaced clip.

edit: I thought by using "Double" that it duplicates a field?

[Boulder]

Out of curiosity,

wouldn't deinterlacing with FieldDeinterlace or TomsMoComp and then resizing to 352x288 obtain higher quality (in theory) since they do consider the data that the two fields contain?

IMHO I wouldn't trust TMPGEnc's capabilities concerning handling interlaced material:D

Reading the TMPGEnc help file makes me head really dizzy:confused: