Rate control discrepancy

GoogleCodeExporter commented 9 years ago

When video is still for a long time and when some movement appears, bitrate 
grows to huge values.

For example on 720p @ 30fps with target_bitrate = 2000 kbps, instantaneous 
bitrate could grow up to 13 MBps.

It is expected that bitrate not to be changed so dramatically.

libvpx 0.9.5 and same behavior on latest from GIT. Using Windows, but this is 
OS-independent

We explored situation and seems that this happens because cpi->bits_off_target 
и cpi->gf_overspend_bits grow unrestrictedly. Proposed changes are attached.

Original issue reported on code.google.com by webmas...@trueconf.com on 9 Dec 2010 at 12:00

Attachments:

proposed_patch.zip

GoogleCodeExporter commented 9 years ago

I assume this problem is principally one that occurs with fast (e.g. real time) 
one pass encodes where the recode loop is disabled.

Can you tell me a little more about your use case and parameters.

Original comment by paulwilk...@google.com on 10 Dec 2010 at 10:06

GoogleCodeExporter commented 9 years ago

We are using VP8 in videoconferencing. Yes, it is real time, one pass and we do 
not add recode loop. If you need exact sample parameter values, I can add them 
on Monday. Also we can try to record sample sequence, but note that it happens 
on rather long time spans.

Original comment by webmas...@trueconf.com on 10 Dec 2010 at 4:06

GoogleCodeExporter commented 9 years ago

Encoding details:
1) standard interface

   #define interface_cx (&vpx_codec_vp8_cx_algo)

2) we are using defaults

   vpx_codec_enc_cfg_t cfg;
   vpx_codec_enc_config_default(interface_cx, &cfg, 0);

3) initialization

        cfg.g_usage = 0;
        cfg.g_profile = 0;
        cfg.g_w = width;
        cfg.g_h = height;
        cfg.g_timebase.num = 1;
        cfg.g_timebase.den = 10;
        cfg.rc_target_bitrate = bitrate;
        cfg.rc_end_usage = VPX_CBR;
        cfg.rc_min_quantizer = 0;
        cfg.rc_max_quantizer = 63;
        if (cfg.rc_end_usage == VPX_CBR) {
                cfg.rc_buf_initial_sz = 2000;
                cfg.rc_buf_optimal_sz = 2000;
                cfg.rc_buf_sz = 3000;
        }
        cfg.rc_dropframe_thresh = 0;
        cfg.rc_overshoot_pct = 0;
        cfg.rc_undershoot_pct = 0;
        cfg.g_pass = VPX_RC_ONE_PASS;
        cfg.g_error_resilient = 0;
        cfg.g_threads = 1;
        cfg.kf_mode = VPX_KF_AUTO;
        cfg.kf_max_dist = 1000;
        cfg.g_lag_in_frames = 0;

        ...

        res = vpx_codec_enc_init((vpx_codec_ctx_t*)m_pCodec, interface_cx, &cfg, 0);

        vpx_codec_control_((vpx_codec_ctx_t*)m_pCodec, VP8E_SET_CPUUSED, -4);
        vpx_codec_control_((vpx_codec_ctx_t*)m_pCodec, VP8E_SET_STATIC_THRESHOLD, 800);

4) changing bitrate while coding

       m_Cfg - is a structure with settings used  while initialized

       m_Cfg.rc_target_bitrate = bitrate;
       res = vpx_codec_enc_config_set((vpx_codec_ctx_t*)m_pCodec, &m_Cfg);

5) encoding

   vpx_codec_encode((vpx_codec_ctx_t*)m_pCodec, m_pImage, m_iFrameCnt, 1, (*param == 0) ? VPX_EFLAG_FORCE_KF : 0, VPX_DL_REALTIME);
   m_iFrameCnt++;
That is all VPX API's we are using
Compiler is MS visual studio 2008. version 0.9.5 for ms visual studio

Original comment by webmas...@trueconf.com on 13 Dec 2010 at 4:50

GoogleCodeExporter commented 9 years ago

Original comment by iss...@webmproject.org on 16 Mar 2011 at 2:51

GoogleCodeExporter commented 9 years ago

Original comment by yunqingw...@google.com on 6 Apr 2011 at 12:42

GoogleCodeExporter commented 9 years ago

Sorry, this seems to have fallen off the radar and was just passed back to me.

The one pass code uses a heuristic that adapts over time to the clip 
complexity. If it is really easy for long time it will therefore max out (or 
min out depending on which way you look t it) in terms of its complexity 
expectations.  If you then get a sudden radical change in how hard the video is 
this could cause a big overshoot for a few frames till it adapts to the new 
state. The same is actually true in the converse situation.

The recode loop obviously allows the worst excesses of such behavior to be 
ironed out, as it will decide the frame is way to big or small and adjust the 
heuristics before having another go. In the absence of recodes it is hard 
prevent this absolutely though this issue has been raised elsewhere and there 
is some possibility that we could for example notice the change after a few 
macro blocks and using the segmentation tools switch to a higher Q for the rest 
of the frame.. This is not ideal but might help. 

Adjustments to the mode decision process and things like zero bin and rounding 
might be another partial solution....In the mean time you may be able to 
moderate the effect by setting a slightly higher minQ value.. This will lower 
the best quality achievable but also limit the size of the oversize frame a bit.

If you have a particularly heinous sample that you can send to us to test 
against and try and improve on then that would be really helpful.

Regards and apologies,  Paul Wilkins

Original comment by paulwilk...@google.com on 6 Apr 2011 at 2:35

Changed state: Accepted

GoogleCodeExporter commented 9 years ago

Update: Ongoing investigations are still underway to improve this behavior.

Original comment by paulwilk...@google.com on 16 May 2011 at 11:37

GoogleCodeExporter commented 9 years ago

Original comment by paulwilk...@google.com on 20 Jun 2011 at 2:40

Added labels: Priority-Low
Removed labels: Priority-Medium

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 7 Mar 2012 at 11:32

Changed state: Unconfirmed

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 8 Mar 2012 at 12:09

Added labels: Pri-3, Type-Bug
Removed labels: Priority-Low, Type-Defect

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 15 Mar 2012 at 6:10

Changed state: Started
Added labels: Mstone-10

GoogleCodeExporter commented 9 years ago

we still have to apply this patch to recent versions.

We will try to record test stream for you, but actually stream is rather simple 
- still image for 10 minutes, then some movement in video will add  several 
huge frames in video sequence.

I am guessing this bug still affects all videoconferencing applications.

Original comment by webmas...@trueconf.com on 16 Mar 2012 at 10:42

GoogleCodeExporter commented 9 years ago

Trying for M10.

Original comment by albe...@google.com on 29 Mar 2012 at 6:13

Added labels: MoveFrom-10, Mstone-11, Pri-2
Removed labels: Mstone-10, Pri-3

GoogleCodeExporter commented 9 years ago

Half of your patch is already effectively done in the code today:   

you had:  

if (cpi->oxcf.end_usage == USAGE_STREAM_FROM_SERVER) 
{
   if (cpi->bits_off_target > cpi->bits_max_off_target) 
        cpi->bits_off_target = cpi->bits_max_off_target;
}

but you set bits_max_off_target to cpi->oxcf.maximum_buffer_size;

In the tip of webm we now have:  

// Clip the buffer level to the maximum specified buffer size
    if (cpi->bits_off_target > cpi->oxcf.maximum_buffer_size)
        cpi->bits_off_target = cpi->oxcf.maximum_buffer_size;

The other part of your patch seems to us to provide only a minor difference on 
the clips we've tested.    

Have you tried with the tip of libvpx with the above change in?  If not can you 
retest with it on or help us to duplicate the problem.

Original comment by jimbankoski@google.com on 2 Apr 2012 at 8:25

GoogleCodeExporter commented 9 years ago

Original comment by jimbankoski@google.com on 24 May 2012 at 9:46

Added labels: Action-FeedbackNeeded

GoogleCodeExporter commented 9 years ago

No activity on the bug for almost a year, closing the bug

Original comment by albe...@google.com on 28 Mar 2013 at 10:15

Changed state: Invalid

GoogleCodeExporter commented 9 years ago

This issue was closed by revision 602a00f93f9f.

Original comment by jz...@google.com on 19 Feb 2015 at 10:52

Changed state: Fixed

GoogleCodeExporter commented 9 years ago

restoring state; code.google is broken with multiple repos / issues that match 
the subject. #243 was from webp.

Original comment by jz...@google.com on 19 Feb 2015 at 11:08

Changed state: Invalid

GoogleCodeExporter commented 9 years ago

JFYI - this bug was fixed somewhere in 2013 , thank you
and it was not Invalid.

Original comment by webmas...@trueconf.com on 20 Feb 2015 at 12:18

GoogleCodeExporter commented 9 years ago

Original comment by jz...@google.com on 20 Feb 2015 at 6:52

Changed state: Fixed

GoogleCodeExporter commented 9 years ago

This issue was closed by revision 77544d5f5b47.

Original comment by jz...@google.com on 4 Mar 2015 at 2:51

shshankjain / webm

Rate control discrepancy #243