Pergunta

Over what time frame does variable bit rate use for averaging? For example, say I want to encode 60 seconds of 640 x 280 25 fps video at 2000 kilobits per second.

Does the codec look at the first second (25 frames) of video, determine how to compress those 25 frames into 2000 kilobits, then move onto the next second of video (25 frames)?

Or does it analyse the whole video (maybe the first 10 seconds are pure black) and calculate that it can use more than 2000 kilobits for the last 50 seconds, but still maintain a 2000 kilobit average over the entire video?

Or is it based on the key frame interval of the particular codec. If I had the keyframe interval set to 250 (10 seconds of video), would the codec assign 20,000 kilobits over that 10 second period?

I'm sure it's actually different for all different codecs, but I figure there must be a best practice (or at least a term I can Google).

Foi útil?

Solução

I don't know the definitions of any particular codec or implementations of encoders but I am familiar with the rational and motivation behind VBR (more as it concerns audio, but I believe the concept is the same).

There are two main categories in play here: single pass and multi pass. Single pass (on-the-fly) encodes much faster. It just passes through the video once and encodes. It can be done in real time for broadcasts and other situations that the whole video isnt available for prior analysis. Your question seems to mainly concern multi-pass. Though it is called multi-pass, it usually means just two. More so, you seem to be asking about multi-pass VBR encoding in which an average (ABR) is specified and must be adhered to.

VBR allows higher bit rates for sections that demand it due to higher color depth, amount of , amount of edges, etc (or in audio - lots of polyphony, mixed frequencies, etc) and lower rates for "plainer" sections with less of those qualities (audio: single voice, sections with only rhythm, etc) the extreme of this being entire frames of a solid color or close to it (silence). Basically the same criteria that effect the compression of still images.

As such, it seems to me that the most effective way for an encoder to stick to a specified average would be to sample individual frames at a certain periodic frequency throughout the entirety of the file. Say, twice a second for the entirety of the video. (I don't know if this is even in the ballpark of a realistic estimate, but you get the idea). This hopefully gives a good estimate of the videos character (for lack of a better word) and allows for most efficient distribution of those precious resources.

It should also be noted that there is sometimes a range of minimum and maximum bit rates that can be employed so that at no time can the bit rate be less than X, or more than Y. Well chosen ranges obviously depend on the resolution.

As for terms to google - try multi-pass encoding and AVR. And as usual, wikipedia sketches a pretty good rough picture, enough so you'd know where to go for further readiong http://en.wikipedia.org/wiki/Variable_bitrate#Multi-pass_encoding_and_single-pass_encoding

Outras dicas

A term you could google - multi-pass encoding & rate prediction.

What it does (beyond providing the best quality encodes) is that the codec effectively encodes the video twice, first time recording the quality loss resulting from a fixed bitrate, second time, incorporating that information in order to maintain the same level of quality regardless on the amount of changes in the video.

Rate prediction/Rate control, is a very fascinating topic, especially for real time, one-pass encoding. The codec has to make a good estimate of the future scene complexity, in order to keep the overall bitrate on target.

Restrictions on maximum bitrate permitted by channel (for instance, you might want a 1MBit/s average bitrate, but the content cannot exceed 2MBit/s for longer than 5s, because of buffering in the players) make this task even more challenging.

Take a look here for more hints: http://www.pixeltools.com/rate_control_paper.html

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top