Questions about video bitrates, keyframes and such.

[mr_lou]

I need some advice regarding bitrates for video encoding.

I'll be recording some 1280x720@50fps videos from my CPC soon, and encode them into blu-ray m2ts video files.
For these m2ts files I'm trying to find the optimal bitrate to use. I.e. one that is as low as it can be without damaging quality of the video.

The socalled Kush Gauge formula looks like this:

Bitrate (kbps) = Width * Height * Framerate * Motionfactor * 0,07 / 1000

The Motionfactor can be 1 or 2 or 4 depending on how much is happening in the video.
I don't know what the 0,07 represents in the Kush Gauge formula. Compression maybe?

Anyway, for my video it'll then be:

1280 * 720 * 50 * 1 * 0,07 / 1000 = 3225,6 kbps

I think it's safe to say that most games on the CPC doesn't have a whole lot of motion though. Most of the screen doesn't change, so maybe a motion-factor of 1 is too high. Maybe it should be 0,5 or even 0,25.
And sure enough. Even a bitrate as low as 500 kbps seems to produce a decent result. It would be nice to find some mathematical formula to explain this though.

Like, an explanation could be: "Movement only happens on about 25% of the screen, so the bitrate = 3225,6 * 0,25 = 806,4 kbps"

But where's the "bits per pixel" value in this formula? I'm assuming 24 bits is used per pixel to indicate a colour.
So one uncompressed full frame consists of 1280*720 pixels * 24bpp /1000 = 22118,4 kbits.
Adding the 0,07 variable (assuming that's the compression factor) I get that one full frame requires roughly 1548,29 kbit of data.
With my limited knowledge, that logically means that the bitrate shouldn't be lower than 1548,29 kbps, because it should be able to send that amount in one frame, right? (I'm thinking keyframes here).
In that case, 806,4 kbps isn't enough. I should probably stick with 1600 kbps or above.

But all of this a purely speculation and guesses.
Does anyone know more? Am I way off? Do you know of other calculation methods for finding a good bitrate?

Thanks

[chinnyhill10]

I need some advice regarding bitrates for video encoding.

I'll be recording some 1280x720@50fps videos from my CPC soon, and encode them into blu-ray m2ts video files.
For these m2ts files I'm trying to find the optimal bitrate to use. I.e. one that is as low as it can be without damaging quality of the video.

You are overthinking it. Encode some video. See how it looks. Take it to a lower bitrate. see how it looks, etc. Good quality tools will give you a file size estimate while you are setting up so you'll know what ballpark you are operating in.


Also VBR will lend itself well to this so it can drop low when it needs to.

[mr_lou]

You are overthinking it. Encode some video. See how it looks. Take it to a lower bitrate. see how it looks, etc. Good quality tools will give you a file size estimate while you are setting up so you'll know what ballpark you are operating in.

Also VBR will lend itself well to this so it can drop low when it needs to.

Yes it's true that the bitrate drops when there's just a black screen.
However, it only drops to a relative low value. If using a bitrate of say 1000 kbps, it may drop to 100 kbps on a black screen. But if using 2000 kbps it may drop to 200 kbps.
This is revealed when playing the video with VLC while looking at the stats window.
It's not "intelligent" enough to only use the exact bitrate it "needs". That would have been awesome.
I don't understand how, when choosing a bitrate of 13000 kbps, it manages to actually send 13000 kbps. I guess it just chooses to resend data that's already displayed despite it not being a keyframe. There ought to be a setting called --optimal-bitrate, or --use-exactly-what-you-need.

I also thought that the vbr bitrate would be low whenever very little was happening. Not just on a black screen, but also like e.g. when/if a still image is shown. I.e. the same picture for a few hundred frames. This doesn't seem to be the case though.
As soon as data is displayed, regardless of animation or not, the bitrate appears to be high, compared to a black screen.

In the end of course it's true that it's all trial and error. I'm just thinking it would be nice with some mathematical formula to back up the choice.
Even more nice with a --use-exactly-what-you-need parameter.

[andycadley]

I don't understand how, when choosing a bitrate of 13000 kbps, it manages to actually send 13000 kbps. I guess it just chooses to resend data that's already displayed despite it not being a keyframe. There ought to be a setting called --optimal-bitrate, or --use-exactly-what-you-need.

I think that's mostly a fabrication on the part of the players, which are just reporting the approximate rate of the video. Just because it says it's sending 13000 kbps, doesn't mean that's exactly how many bits are coming through.

And on the subject of "optimal", it's quite difficult to judge and may even depend on the decoding software. There is a certain amount of overhead in switching rates and you don't necessarily want to be doing it for just a couple of frames if you're going to have to switch right back up again.

[mr_lou]

I think that's mostly a fabrication on the part of the players, which are just reporting the approximate rate of the video. Just because it says it's sending 13000 kbps, doesn't mean that's exactly how many bits are coming through.

I didn't mean that it sends exactly 13000 kbps. I mean, it seems to send roughly the bitrate you set, even if it could or should settle for a lot less. If I choose to have a keyframe every 50 frames, then sending 13000 kbit that particular frame might make sense. But not for the other 49 frames - even if I've told it can use a bitrate of 100.000.000 Mbps.
But for keyframes there should also be the logical limit of resolution * bits-per-pixel, because logically there can't be any more data than that for a keyframe.
So, for a 50 frame second showing a still image, there should be a keyframe + 49 "almost no changes" frames.
Data-wise that ought to be resolution * bits-per-pixel + very little.
But as far as I can see, it sends a lot more than that. In other words, it's like setting a higher bitrate merely creates more keyframe-like frames.

And on the subject of "optimal", it's quite difficult to judge and may even depend on the decoding software. There is a certain amount of overhead in switching rates and you don't necessarily want to be doing it for just a couple of frames if you're going to have to switch right back up again.

I don't see how it's difficult to judge what the optimal bitrate is.
It ought to be "a full frame for keyframes + only the difference for other frames", shouldn't it?
I don't understand why encoders don't have an option to run through a video file and analyze it to find the optimal bitrate.

[chinnyhill10]

In the end of course it's true that it's all trial and error. I'm just thinking it would be nice with some mathematical formula to back up the choice.
Even more nice with a --use-exactly-what-you-need parameter.

I'll say it again, you are over thinking it.


A black screen may look like a black screen but probably isn't. They'll be all sorts of noise in there. With any source there is noise* and the encoder needs to deal with it. Just because your eye can't see it doesn't mean it isn't there.


Just encode some footage as 2 pass VBR and see what works within your budget. I'm looking at my encoder here. It lets me set the minimum, target and maximum bitrates. And yes, the encoder will try as hard as it can to stay within the constraints you set. Although you are strongly advised to keep the parameters sensible.


* aside from screen recording which is partly why those codecs can be so aggressive.

[mr_lou]

I'll say it again, you are over thinking it.

And you really gotta stop saying that.

Listen, try to understand that this is an interest of mine. A hobby.
Saying I'm over thinking it is like someone telling you that you're overdoing it when you insist on recording from the real machines rather than just using emulators, when everyone else with equal or more success on YouTube just uses emulators.

There'll be a lot of content on this project I'm creating, and I do have a space limitation. I need to fit a lot of videos and music into 25 gb. I can't waste bytes, but I can't waste quality either. So I need to make an effort in finding the optimal procedure here.
Spending some time experimenting with bitrates and asking advice in that regard hardly qualifies as over thinking it. 

If you do want to assist, you could tell me what values you typically use for your minimum and maximum bitrate for 1280x720 resolution CPC videos. That could be interesting to hear. Although I'm guessing you're using rather high values, like the YouTube recommendations of 7,500 Mbps.

[andycadley]

Video codecs aren't designed for long periods of unchanging images, nor for pixel perfect imagery. They use lossy compression on keyframes and are geared around the basic assumption that things will change from frame to frame.

Sure you could bulk up the format to optimize better in such edge cases, but it would end up adding a lot of overhead for more "ordinary" situations where you're just encoding typical footage.

Gameplay footage from 8-bit video games is about as far from the "typical" scenario as you can get, it has low colour density, lots of sharp edges and relatively low amounts of movement. It shouldn't be a surprise that it doesn't necessarily encode optimally in formats designed for cinematic film footage.

[mr_lou]

Alright, I've found the answer I was looking for. Posting here for anyone else finding this thread in the future.

The socalled "Kush Gauge" that I mentioned in my first post is apparently created by a guy called Kush Amerasinghe who works for Adobe.
He wrote this interesting document about H.264 in which he comes up with the formula.

In short, the 0,07 value does indeed represent the compression rate of H.264.

Another guy on StackOverflow.com had done similar observations and reached a value of 0,074.

So, when doing calculations like this, we can use 0,07 as the compression ratio value. This corresponds to a compression factor of about 14 for H.264. (For MPEG-4 the value is 0,114 giving a compression factor of 8,77).

Looking at CPC videos in HD we get that:

1280 width * 720 height * 50 frames per second * 1 motion-rank * 0,07 compression ratio / 1000 = 3225,6 kbps

You should look at the motion-rank here: You may create a 50 fps video, but if changes only happen every 2nd frame, then the motion-rank could be lowered. And if changes only happen on a small part of the frame, then motion-rank can be lowered again. And that's of course why I manage to get a decent quality even at 1000 kbps when experimenting; because most CPC games actually only have 25 fps, and very little change per frame.

And that's exactly the kind of guidance I was looking for.

It'll be easier determining a bitrate for each video now.

[mr_lou]

Video codecs aren't designed for long periods of unchanging images, nor for pixel perfect imagery. They use lossy compression on keyframes and are geared around the basic assumption that things will change from frame to frame.

Sure you could bulk up the format to optimize better in such edge cases, but it would end up adding a lot of overhead for more "ordinary" situations where you're just encoding typical footage.

Gameplay footage from 8-bit video games is about as far from the "typical" scenario as you can get, it has low colour density, lots of sharp edges and relatively low amounts of movement. It shouldn't be a surprise that it doesn't necessarily encode optimally in formats designed for cinematic film footage.

You can tell the encoder whether it's a film or an animation it's encoding, and it'll do the encoding differently. With x264 you have a few options for tuning like this; "film", "animation", "grain", "stillimage". Explained here.
I use "animation" for my CPC videos.

[chinnyhill10]

And you really gotta stop saying that.

Why? I've tried to help you? Do you want to waste time over thinking the video encoding side rather than worrying about content? You can fiddle to your hearts content but you will make only the slightest of differences to the output. You'll probably save more by skimping slightly on the audio encoding side by going for DTS 2.0 at a lower bitrate rather than uncompressed PCM.


Your best bet is to start with the Adobe presets and do a rough bitrate calculation. Then encode 5 minutes of sample footage at a setting that looks right on paper. Look at the size/quality, and then tweak.


When happy that everything fits and it looks OK, encode the lot.


That is literally how I've ended up authoring commercial DVD's when I've wanted the maximum quality. VBR codecs are very useful when you have scenes with large static areas and you'd be surprised how far you can push them.


You can do all the sums on paper you like, but with video encoding nothing equals looking at the encoded image on a good screen. No sums will tell you how the finished footage will end up looking.

[chinnyhill10]

Gameplay footage from 8-bit video games is about as far from the "typical" scenario as you can get, it has low colour density, lots of sharp edges and relatively low amounts of movement. It shouldn't be a surprise that it doesn't necessarily encode optimally in formats designed for cinematic film footage.

Indeed. Even dedicated screen capture codecs would have issues with real hardware as although areas of colour look solid, there may be very slight variations due to the analogue video signal.


Which is why I'm saying forget the sums, just encode and see how far you can push it before there are problems. The codecs aren't designed for an analogue video signal from a 30 year old computer. They are neither animation, film, etc, etc.

[mr_lou]

Why? I've tried to help you?

I appreciate you trying to help out.
The problem is, that when I ask for advice about "going in direction west", your response is usually something along the lines of "Don't go west! I'm going south - and I'm a pro!".
There's always more than one way you can do things, and sometimes going in a different direction than one had set out for, is fine. Therefore it's always good to hear these suggestions, and I do appreciate your input that way.
But you seem to have a slight problem accepting that I don't want to do it like you're doing it, and that's when it just becomes irritating instead of helpful.

As far as I remember it was the same when I asked for ways to record from the real machines. You shared how you're doing it, which I appreciated, and I considered doing it that way, but chose to go in a different direction. Like in this thread, you then kept posting that I should do it your way - and that's not helpful in relation to the question I'm asking. That's just kinda annoying.

I don't mean to offend you. As I said, it's great to hear your input. But you gotta be prepared to accept that the recipient might not want to do it like you're doing it.