x264: now with adaptive streaming support
You’re running a video chat program on a relatively weak upstream connection. Someone else opens a video chat program on the same connection and your available bandwidth immediately drops. What do you do?
You’re running a streaming video server that sends live video to an iPhone. The client moves into an area of weaker reception and the stream begins to break up. What do you do?
You’re running a streaming video server and it has currently maxed out your connection with the current viewers, but you want another person to be able to connect. You’d rather not restart the whole server though. What do you do?
Well, before, you didn’t have any options. But now you do…
x264_param_t p;
x264_encoder_parameters( handle, &p );
p.rc.i_vbv_buffer_size /= 2;
p.rc.i_vbv_max_bitrate /= 2;
x264_encoder_reconfig( handle, &p );
Bam, the max bitrate of the stream was just reduced by half, applicable instantly. You can also change the CRF when in CRF mode, adjust maxrate/bufsize arbitrarily, and change the bitrate in CBR mode. The only restriction is that you can’t change the mode itself and you can’t change the bitrate in ABR mode.
Cool beans, eh? Thanks to SayMama video calling for sponsoring this feature.
扫一扫
2918
到【灌水乐园】发言
February 16th, 2010 at 3:06 pm
This is really nice Dark Shikari! Just as I was in the middle of whipping up an application using the recent error resilience features of x264 in a real world live (Television) streaming application, now I need to look at how I can use this new feature!
In my current app, I am using RTP. What do you think of using RTCP Receiver Reports to detect the presence and rate of packet loss in order to then figure out the vbv-* parameter adaptations? My only worry is that these reports (due to the rate-limiting nature of RTCP) may be out-of-date by the time they give me sufficient information.
In any case, thanks. x264 is fast becoming the encoder without compare.
February 17th, 2010 at 8:17 am
You can use RFC 4585 which is the early feedback profile for RTP. In that case, RTCP reports will make sense to adapt to congestion.
February 18th, 2010 at 1:49 am
Is bitstream hrd conformant after changing bitrate like this? Or it doesn’t matter in such use case?
February 18th, 2010 at 9:18 am
@nick
This is actually a very good question. Currently HRD support isn’t in trunk yet, but when it will be, we do plan to support it in bitrate-changing mode. Here’s how:
1) Send a new SPS containing the new buffer information.
2) If the ratecontrol reconfiguration results in bits being thrown away due to being larger than the buffer, we will insert filler bits accordingly.
Of course this won’t be bothered with outside of HRD mode.
February 20th, 2010 at 4:51 pm
@Zipped. Looked at it. Just what I need. Thanks! Does not seem to be implemented in any open library yet, so will try and implement it on Live555.
February 23rd, 2010 at 8:00 pm
I actually came across this code yesterday while snooping through the x264 source trying to track down a seg fault (was my bad btw, not x264s). Haven’t had a chance to try it out yet but looks incredibly useful. I’m just a bit confused about what exactly isn’t supported in ABR mode. You say that you can’t change the bitrate in ABR mode but does that mean changes to p.rc.i_bitrate or p.rc.i_vbv_max_bitrate aren’t supported?
February 26th, 2010 at 6:17 pm
@brendan
The former.
February 27th, 2010 at 9:00 pm
I can’t wait to use the first (?) x264-based videochat application.
February 28th, 2010 at 4:07 pm
@kierank
Thanks, that’s what I thought.
April 26th, 2010 at 10:28 am
What are your thoughts on x264 and SVC encoding?
May 25th, 2010 at 1:18 am
I’m just wondering if it would be possible to double the bit rate too? Or maybe make it a 3rd or a fraction (2/3 e.g.) of the original? Or is it only possible to halve the stream?
July 27th, 2010 at 10:42 pm
@Hakon: it should be possible to change the encoding bit-rate either ways (both high and low). That’s what “x264_encoder_reconfig()” does based on values you set in:
- ‘p.rc.i_vbv_buffer_size’ and
- ‘p.rc.i_vbv_max_bitrate.’
October 3rd, 2010 at 5:12 am
Where is SayMama now ?
Add ability to adjust ratecontrol parameters on the fly
encoder_reconfig and x264_picture_t->param can now be used to change ratecontrol parameters.
This is extraordinarily useful in certain streaming situations where the encoder needs to adapt the bitrate to network circumstances.
What can be changed:
1) CRF can be adjusted if in CRF mode.
2) VBV maxrate and bufsize can be adjusted if in VBV mode.
3) Bitrate can be adjusted if in CBR mode.
However, x264 cannot switch between modes and cannot change bitrate in ABR mode.
Also fix a bug where x264_picture_t->param reconfig method would not always be frame-exact.
Commit sponsored by SayMama video calling.