Burst-Aware Dynamic Rate Control for H.264/AVC Video Streaming

[jsaunders]

Hello All,

I found the paper titled :

Burst-Aware Dynamic Rate Control for H.264/AVC Video Streaming

The abstract is:

The state-of-the-art video coding standard H.264 provides efficient compression and rate control for various video applications. However, by using the current rate control mechanism of H.264 for a video streaming, the output end users would experience a serious video distortion when a data burst happens in the input video. In order to ensure the output video quality and maintain a stable output bit stream, a new adaptive bit-allocation scheme is proposed in this paper. To be compatible with the widely used H.264, our adaptive bit allocation scheme incorporates a set of new allocation criteria in the rate control mechanism of H.264. Experimental results show that the proposed adaptive bit allocation scheme could produce a more stable output stream given a bursty video input stream.

Has anyone seen x264/h264 encode source that implements this?

Here is the IEEE link:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5599884&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5599884

Thanks,
Joe

[Blue_MiSfit]

What exactly do you mean by a burst? Do you just mean a spike in the complexity of the video? If so, isn't it the job of the VBV buffer to absorb these fluctuations?

[LoRd_MuldeR]

"In this paper, in place of the standard frame-level rate con-trol mechanism, we propose a macroblock (MB) level rate control scheme"

Yes, x264 has that for a long time now. Search for "MB-Tree" rate-control ;)


"The results demonstrate that our method can yield a more stable bit-rate than JM, the current method used in H.264/AVC, but maintain similar video quality as JM in the high motion cases."

Claiming that the rate-control algorithm of JM is the one currently used by H.264/AVC is kind of a hair-raising statement, because the standard doesn't stipulate how the encoder has to manage bitrate. Rate-control is a pure encoder-side decision and every encoder can have its own rate-control algorithm(s). JM is only one H.264/AVC encoder out of many - and certainly not a very optimized one.

Also: Without having read the details, the fact that they compared their own solution against a "proof of concept" encoder (JM) rather than a mature one (e.g. x264) doesn't give me a good feeling about their algorithm...