bit rate again

I took Strypes advice from 11 months ago to limit the DVD bit rate to 6.8/8.2 Mbps (well, he said 8.0). I burned about 80 Verbatim discs, and not one recipient complained of unplayability.
But now it's time to make an mpeg2 master for pressing -- not burning -- DVDs. I believe that DVD players can all handle 9.8 Mbps from pressed discs. Isn't it reasonable then to grab the extra quality the higher bitrate will yield?
Thanks,
dcouzin

Dennis Couzin
Berlin, Germany

I see a couple of issues here for you to consider.

First off, whilst DVDs can technically cope with a video bitrate of 9.8, the total bitrate for all elements of your disc, including audio, subtitles, additional graphics and so on must not exceed 10.08mbps. If you encode your video to 9.8, then your audio can only be around 192kbps... i.e. AC3 at the lowest stereo setting.

Secondly, whilst 9.8Mbps is a higher bitrate, and theoretically should be a better quality, there is a law of diminishing returns at play here. If you can see a clear visual difference between 8 and 9.8 I'd be surprised. Much depends on your source footage. If your source is of average to good quality, nothing will be improved by raising the bitrate. If your source is pristine and excellent then you might have something to gain by increasing the bitrate, but a compromise must be found if you want to have the best audio, too (and let's face it, audio is 60% of what it is all about... or perhaps even more).

In days gone by it would be important to hit the 'sweet spot' of balancing the content of the DVD against its actual capacity, and the higher bitrates not only improved visual quality but also increased file size so as to make the disc most efficient in a player. However, that doesn't seem to be important anymore, and players are improving all the time in what they can deal with.

In general then, if the rule of thumb for a DVD-R is to max the bitrate at 7.4Mbps (a little lower than perhaps has been suggested already), the same or similar might hold true for a DVD-Video disc, despite what the spec tells us is possible. The old adage - "just because you can, doesn't mean you should" - is well remembered!

You need to encode what you consider to be the 'busiest' portion of your footage at different bitrates (and start as low as 4.5) to see if you can actually spot any difference with the different versions. When you get to a bitrate that you are happy with, use it. There is no hard and fast rule of compression that applies to every single piece of footage you make - each will be different, each will need the encoding settings tweaked accordingly, and only taking the time to explore what works best is going to give you the best results.

Hal MacLean, I'm glad you emphased the importance of audio. Temporal perception is unusually sharp. If raising the bitrate from 8 to 9.8 were wasted on spatial resolution, I agree that you probably couldn't see it. (The 22% increase is in two dimensions, so the one-dimensional improvement, which is what can be noticed, is just 11%.) But what if raising the bitrate from 8 to 9.8 is used in the time dimension? What if you could have I-frames every 6 frames instead of every 12 frames? You'd see that difference. [My rough calculation of GOP size assumed that each non-I frame uses 1/4 as many bits as each I frame. 2+10/4 and 1+11/4 are in the approximate ratio 9.8 to 8. The point is that GOP size is changed by more than the bitrate ratio.]

Dennis Couzin
Berlin, Germany

Yep - you certainly would see the difference if you introduced I frames more frequently, since these are full picture frames and not mathematical projections as B and P frames are. The more I frames you introduce the more quality your footage would have, but the more inefficient it would be at playing back which might, in some players, introduce stutters... however, it's worth a shot.

If you want to play with things like the intra precision, quantization matrix and other such lovelies - get a copy of MegaPEG.X where you can get to do all sorts of things like that!

Hal MacLean, thanks for the MegaPEG.X tip.
Compressor has its role for making a quick-and-dirty mpeg2. It's visibly better than Toast. But it sure would be nice to make scene-by-scene decisions on how to "spend" the 8 or 10 million bits/second.

Dennis Couzin
Berlin, Germany

>The more I frames you introduce the more quality your footage would have, but the more
>inefficient it would be at playing back which might, in some players, introduce stutters...

>What if you could have I-frames every 6 frames instead of every 12 frames?

Interesting. I tried it out on Compressor a while ago, and my conclusion was that although having shorter GOP length may benefit sections with fast action and quick movements, it actually diminishes the overall video quality on most videos. I suspect that is due to the maximum bitrate limit on Mpeg2, which increases the compression on I-frames when you shorten the GOP length to keep within a specified bitrate.

Also, DVDs do not use a fixed GOP structure. If you export a SCQT with compression markers, Compressor is able to read where the edit points are, and insert I frames where the cut was made. So to some degree, a "scene detection" feature isn't as important. However, for its merits, it doesn't go through quantization matrixes or maximize your GOPs.

You could also check out BitVice, which seems to do pretty well for some guys here.



www.strypesinpost.com

Thanks strypes. Your diagnosis is plausible. Whatever bits are given to additional I-frames must come from somewhere, such as from color quality or resolution. The matter of player overload is different. Each I-frame, except in uncompressed formats, needs to be spatially decoded. Each non-I-frame, on the other hand, needs to be constructed from I-frames and some added data. I-frames certainly require more bits, but do they require more processing work than non-I-frames? I wonder.

I'd like to find compression software written by vision scientists, not coding geeks. My first impressions of MegaPEG are not encouraging. I want to be able to make second-by-second adjustment of the compression parameters, so as to apportion color, resolution, and motion more or less independently in the total bit-rate. I want all the controls and settings to be fully, mathematically documented. Apple Compressor also has hocus-pocus qualities. It says one thing and does another. Maybe your suggested BitVice is cleaner and straighter. (I wish they spelled it BitVise though.)

Dennis Couzin
Berlin, Germany

Not sure if you've seen this yet..

[www.omni-cinemacraft.com]



www.strypesinpost.com

Thanks again strypes. I hadn't seen it and it seems very relevant.
The hardware based CINEMA CRAFT Xtream Encoder, which provides the engine for the CCE-MP plugin, sounds great. It does something it calls Segment Re-Encoding (re-encoding just a segment you specify) which I think is essential. It's unclear whether the CCE-MP plugin offers this function. I don't see it in the CCE-MP User's Guide.
------------------------
Note added: Damn, the plugin doesn't do Segment Re-Encoding.

Dennis Couzin
Berlin, Germany

Sorry not been about!! No internet at home since mid-2008!!! Hope to be back online March 2nd...

CCE MP doesn't allow segment re-encoding and wont give you the control you want. At first we thought we'd be getting the control but it never materialized...

You'll want CCE SP2 (Windows only!!) if you can't go for the 'big boy' cinemacraft systems. You can segment re-encode (VBR bit allocation) but not just that you can take it as far as you want, even apply custom quant matrices on a segment by segment basis.

CCESP2 Manual (PDF)

Avoid BitVice. The new one s_cks!!

In all the high-end studio's I've ever worked, most of the bandwidth was always used for replication projects. 9.8 - audio streams (5.1, stereo, DTS) then - another say 0.2Mbps (ish) and thats your max.

The thing is, not all the bits are always needed and many encoders might output macro blocks cause there are too many (similar to when there are not enough) as they aren't able to handle the stuffing of the bits to keep to the avg required... I suggest you also buy MPressionist Pro. It will let you see the bitrate of the m2v files, stuffing bits, quant matrices as well as a whole host of other things!

Digigami MPressionist Pro - Not as many screenshots or info on the site as there used to be!!

Oh another workflow thing - You are asking for big trouble if you get sign-off with a DVD-R then re-encode and send off something else to the rep house. You really need to work with the client to ensure they can play your high bitrate DVD-R's, then output to DLT/DDP images and where possible have the check discs QC'd & signed off.

Setting the max to 9.5Mbps doesn't mean that you'll gain a whole bunch of quality and doesn't mean the encoder needs those bits. It may help but not always...

Good luck,

Thanks Jake Russell for the rich information.
So the Premier users got the better software encoder from CinemaCraft. What does this say about the standing of FCP?
Still it's good to know that CCESP2 exists.
I did know of Digigami MPressionist.
I need to do mpeg2 compression approximately once per year, so I can't realistically get either of these programs. Now to find a "high-end studio" in Berlin Germany and put my money where my mouth is.

Starting with a DV-PAL original, a puny 720x576 8-bit 4:2:0 thing compressed to about 27 Mbps, it should be possible to make a DVD almost as good as the original. The DV has no inter-frame compression at all, and some degree of inter-frame compression, certainly averaging 3:1, should look fine. The problem, of course, are the moments here and there in the film, where inter-frame compression bombs -- where it ruins the action. This isn't just mega action, athletes and race cars, it can be subtle motion, tremblings of flesh, etc. which need every frame an I frame. But 27 Mbps isn't allowed. In these shots something else has to be chosen to give up the 18 Mbps. I'd rather an artist than a software engineer make the decisions.

You might replace your link with this: CCESP2 Manual Pdf

Thanks again.

Dennis Couzin
Berlin, Germany