MPEG 2 Average vs Constant Bitrate for Capture

[Alwyn]

Yes yes yes I know!

A program I'm involved with has the option of analogue capturing in MPEG 2. All parameters are user-selectable. I'm interested in the thoughts of the experts on capturing at Constant Bitrate verses Variable.

I know VBR is better from a space POV, but would CBR be better, from a "master file" POV, considering that the file might be used in the future to create a MP4?

[jagabo]

If the peak in average mode is the same as the constant bitrate, the average bitrate mode can only be worse than the constant bitrate mode.

If the average bitrate mode has the same average bitrate as the contstant bitrate the average mode is likely better.

For example, it the constant birate is 15 Mb/s, and the average bitrate ranges from 0 to 15 MB/s, constant bitrate is likely better. If the average bitrate ranges from 0 to 30 mB/s, the average bitrate encoding is likely better.

[Alwyn]

Thanks Jagabo, by "better" you mean better quality?

I am able to set the average bitrate (as well as Max BR) and the program conforms closely to it. In effect, the CBR and VBR files have similar bitrates.

From an export-to-MP4 POV, would it be "better" (quality-wise) to have a VBR or CBR master?

[Sharc]

If filesize doesn't matter I would suggest to capture at the highest possible CBR bitrate. Depending on the performance of your on-the-fly mpeg2 encoder it may prevent blocking artifacts which may otherwise materialize if the VBR encoder would drop the bitrate too much in dark low motion scenes for example.
Your mpeg2 encoder may have some other settings constraints though for CBR and VBR, so you have to try. Maxing out the bitrate does usually no harm for "master" copies.

[Alwyn]

Thanks Sharc.

[lollo]

If filesize doesn't matter I would suggest to capture at the highest possible CBR bitrate. Depending on the performance of your on-the-fly mpeg2 encoder it may prevent blocking artifacts which may otherwise materialize if the VBR encoder would drop the bitrate too much in dark low motion scenes for example.

And more, the CBR allows lower computational effort, reducing the risk of dropped frames for real-time encoding while capturing on low performance systems.

[pandy]

For capture i strongly recommends using low constant quantizer if possible - this will create pure VBR file however if bitrate can be unlimited (i.e. HW encoder may create non standard conformant bitstream) - constant quantizer has advantage of not involving mostly feedback so remove potential problems that can be outcome of errors in decision process. Fixed Qp remove most of issues - or move them to this point where decision about increasing Qp is taken when bitrate from encoder approaching maximum allowed bitrate. Yes, i know - most of you will not agree with this but from my perspective such strategy works best for software and HW encoders.

[Alwyn]

@Lollo, thank you.

@Pandy, the only options I've got are VBR or CBR (and the bitrate). I don't have a selectable Quantiser.

[Cornucopia]

Since this is a live capturing situation, you would not be able to take advantage of 2pass vbr efficiencies, and since you are discussing bitrate, that sounds like you don't have cfr/cq as an option, so the option of cbr, assuming sufficient bitrate is given for the most complex parts, would certainly be less of a burden, as was mentioned, and give assurance of quality & compatibility.


Scott

[Alwyn]

@Scott, thanks, CBR it is.

[jagabo]

MPEG encoding is pretty simple by modern standards so that's probably not an issue if you have a modern computer.

As I pointed out earlier, a bigger issue is whether or not the VBR mode allows for higher peak bitrates than the highest CBR bitrate. High peak bitrates will allow complex shots to get more bitrate and hence better quality than encoding CBR. A VBR encoding may deliver higher quality than a CBR encoding at the same average bitrate.

Of course, all this depends on the particular encoder. And you shouldn't be using an MPEG encoder for capture anyway. Why discard detail and create DCT blocking and ringing artifacts right off the bat?

[pandy]

@Lollo, thank you.

@Pandy, the only options I've got are VBR or CBR (and the bitrate). I don't have a selectable Quantiser.

Then i would choose VBR to relax encoder restrictions.

[Bwaak]

FYI: most commercial software that captures into DVD-compatible format use 8 Mbps CBR as the highest-quality format. Technically, DVD-video is limited to 10 Mbps overall, so 8 Mbps for the video and the rest is for the audio, subtitles, and just to stay below the limit for better compatibility.

you shouldn't be using an MPEG encoder for capture anyway. Why discard detail and create DCT blocking and ringing artifacts right off the bat?

Because for many cases it is good enough, small enough, fast enough for encoding, fast enough for editing, the resulting file usually has correct metadata regarding interlacing, field dominance and aspect ratio. So, it is watchable and compatible. Yes, sometimes it is blocky. I've switched to MPEG-2 for capturing a bunch of tapes with music videos - I capture them, I chop off the beginning and the end without re-encoding, and I upload them to Wayback Machine, because YT keeps blocking them. Then whoever downloads them can decide whether they want to plop it on a DVD or deinterlace, upscale and upload to YT or watch as is.

Just for fun I attached all four default profiles from AverMedia Capture Studio. So, they use 6 Mbps for MPEG-2, not 8 Mbps. Looks like it is hardware-encoded. AVI seems to be uncompressed, VDub says it uses internal DIB decoder for it.

There is a separate dialog for deinterlacing!

[Sharc]

8 .... 10 Mbps are DVD constrained. Many early Blu-ray discs were mpeg2 encoded using full Blu-ray bitrates, and some pro camcorders used mpeg2 up to 300 Mbit/s (422P@HL)

[Bwaak]

8 .... 10 Mbps are DVD constrained. Many early Blu-ray discs were mpeg2 encoded using full Blu-ray bitrates, and some pro camcorders used mpeg2 up to 300 Mbit/s (422P@HL)

20 years ago 50 Mbit/s 4:2:2 MPEG-2 was the gateway to proper broadcast HD. MPEG SHD422 is 85 Mbit/s. I don't know of any camcorder that recorded 300 Mbit/s using MPEG-2 (and too lazy to search ). HDCAM is not MPEG-2, AFAIK.

[pandy]

MP@ML is limited to 15Mbps but MP@HL is limited to 80Mbps so if your encoder is able to go over 15 Mbps then it is fine for most decoders to deal with such stream. Personally i would avoid to use B frames and made short GOP's from I and few P frames only this provide usually best MPEG-2 quality with sufficiently high bitrate is available.
I agree with Bwaak - nowadays MPEG-1, MPEG-2 are probably most versatile video codecs free from patents - MPEG-1 has nice feature - is able support up to 4096x4096 resolution and can be supported natively from any modern web browser ( https://phoboslab.org/log/2013/05/mpeg1-video-decoder-in-javascript ), MPEG-2 is better for interlaced content and has few other nice improvements over MPEG-1.

[Alwyn]

And you shouldn't be using an MPEG encoder for capture anyway. Why discard detail and create DCT blocking and ringing artifacts right off the bat?

It's the only option I have with this particular program, unfortunately.

[jagabo]

And you shouldn't be using an MPEG encoder for capture anyway. Why discard detail and create DCT blocking and ringing artifacts right off the bat?

It's the only option I have with this particular program, unfortunately.

And you have to use that program?

And keep in mind that this entire discussion has been theoretical. The only way to know for sure is to try the different methods with the program yourself.

[Alwyn]

@Jagabo, yes, we're persevering with it.