Hi all, I'm trying to use libavcodec to 1-pass encode an h.263 stream which has limits on both the maximum size-per-picture and total datarate. I can't work out what the right way is to respect both limitations using the ratecontrol settings, whilst maintaining the best possible QP for any given frame (so long as it doesn't end up larger than X bytes - or push the total datarate for over Y kbits/s). I assume I can do this with a custom rc_eq formula and/or adjusting qcompress - but I can't see an obvious formula for capping the picture-size. Alternatively, is there another way to force ffmpeg to adjust the qp so that pictures are never larger than a given size? Any suggestions would be very much appreciated indeed :) cheers; Matthew
On Tue, 10 May 2005, Matthew Hodgson wrote:
I'm trying to use libavcodec to 1-pass encode an h.263 stream which has limits on both the maximum size-per-picture and total datarate. I can't work out what the right way is to respect both limitations using the ratecontrol settings, whilst maintaining the best possible QP for any given frame (so long as it doesn't end up larger than X bytes - or push the total datarate for over Y kbits/s).
I assume I can do this with a custom rc_eq formula and/or adjusting qcompress - but I can't see an obvious formula for capping the picture-size. Alternatively, is there another way to force ffmpeg to adjust the qp so that pictures are never larger than a given size?
Any suggestions would be very much appreciated indeed :)
You can't cap per-frame bits using rceq, because rceq is unitless. lavc will multiply the output of rceq by whatever factor it takes to fill up your desired average bitrate. But if you don't mind modifying a few lines of code, look in modify_qscale() line 435 or so. Currently that limits per-frame bits based on the number of bits left in the VBV buffer; you could put in your own cap similarly. (Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.) --Loren Merritt
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow... Rich
Rich Felker wrote:
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow...
This was the hack I was going to resort to if I couldn't get lavc's RC engine to try to cap the framesize internally. As it stands, though, I'm going to try Loren's suggestion by doing something along the lines of bits= qp2bits(rce, q); ... if (bits > max_frame_size) q = bits2qp(rce, max_frame_size); else // use existing if(max_rate) code in modify_qscale() - assuming that the bits value returned by qp2bits is a guess of the current frame's size at the given picture QP. It's not a complete disaster if the framesize sometimes drifts slightly over the maximum. huge thanks for the advice :) M.
Hi folks, After a bit of a hiatus, I finally got 'round to trying to cap frame sizes generated by ffmpeg in 1-pass h.263 encoding. Unfortunately, things did not go smoothly - I tried Loren's advice of: Loren Merrit wrote:
But if you don't mind modifying a few lines of code, look in modify_qscale() line 435 or so. Currently that limits per-frame bits based on the number of bits left in the VBV buffer; you could put in your own cap similarly. (Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
...but unfortunately the predicted size of a frame given by qp2bits(rce, q) in modify_qscale seems even more inaccurate than I feared. The problem seems to be that the estimate of the frame size has to converge over time - which is fine for a longish talking-head style video; after ~60 frames it gets pretty accurate and you can detect potential large framesizes and clobber their QP. However, when a video is made up of a series of different still images (e.g. non-scrolling credits) it takes much longer (~120 frames or so). And whilst it's converging, it guesses the framesize pretty badly - 32 bits rather than the actual 14296 for the first frame, 500 bits rather than 25480 for the 30th frame, 153315 bits rather than 74776 for the 77th frame, etc. (However, frame 91 is almost right (30767 v. 26312), and by frame 121 it's pretty close (30546 v. 30144)). Am I using the wrong metric for estimating the end frame size in 1-pass encoding? And does anyone know which of the various counters & predictors starts off initialised incorrectly, causing this convergence effect? Alternatively, I need a way to tell the ratecontrol to encode a sudden change in static image as a small I + several incremental P frames - rather a single huge monolithic I frame and a subsequent string of 'empty' P frames. Is there any way to force ffmpeg to encode in this way? Rich Felker wrote:
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow...
I've also tried going down this line of attack, but it seems that ffmpeg doesn't make multiple executions of the encode_thread for a given frame very easy - all the rtp callbacks and bitstream output happen directly from within the thread. I take this to mean that I have to completely isolate the encode_thread and buffer all its sideeffects in order to run it in a sandbox to see how big its output is going to be, and then re-run it with a higher QP as needed. This seems relatively tricky - is there a better way of doing it, or is this the only way to go? I've also tried doing a two-pass encode and fiddling the stats file between passes by boosting the perceived i_tex/p_tex/var on frames which were too big, hoping that the next pass would overcompensate and shrink them down. This doesn't seem to work at all - i'm assuming that some kind of blurring or smoothing is annihilating my hacky tweaks, or I'm completely misunderstanding how the multipass encoding is mean to work. any suggestions would be enormously appreciated. cheers; M.
Hi -- I have also noticed the same phenomena where the h263 encoder will take a number of seconds to converge to a sharp image. My observation is that when a quick movement is made, the image becomes quite blurry and will slowly converge. I've also had trouble picking parameters in the encoder so that the frames are encoded up to a desired maximum data rate and the quality remains decent. (I'm using ffmpeg from cvs a couple of weeks back.) If you happen across a solution to this, could you please pass it my way ! I'll be glad to test it... Thanks, Dan At 07:12 PM 7/25/2005, Matthew Hodgson wrote:
Hi folks,
After a bit of a hiatus, I finally got 'round to trying to cap frame sizes generated by ffmpeg in 1-pass h.263 encoding. Unfortunately, things did not go smoothly - I tried Loren's advice of:
Loren Merrit wrote:
But if you don't mind modifying a few lines of code, look in modify_qscale() line 435 or so. Currently that limits per-frame bits based on the number of bits left in the VBV buffer; you could put in your own cap similarly. (Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
...but unfortunately the predicted size of a frame given by qp2bits(rce, q) in modify_qscale seems even more inaccurate than I feared. The problem seems to be that the estimate of the frame size has to converge over time - which is fine for a longish talking-head style video; after ~60 frames it gets pretty accurate and you can detect potential large framesizes and clobber their QP.
However, when a video is made up of a series of different still images (e.g. non-scrolling credits) it takes much longer (~120 frames or so). And whilst it's converging, it guesses the framesize pretty badly - 32 bits rather than the actual 14296 for the first frame, 500 bits rather than 25480 for the 30th frame, 153315 bits rather than 74776 for the 77th frame, etc. (However, frame 91 is almost right (30767 v. 26312), and by frame 121 it's pretty close (30546 v. 30144)).
Am I using the wrong metric for estimating the end frame size in 1-pass encoding? And does anyone know which of the various counters & predictors starts off initialised incorrectly, causing this convergence effect?
Alternatively, I need a way to tell the ratecontrol to encode a sudden change in static image as a small I + several incremental P frames - rather a single huge monolithic I frame and a subsequent string of 'empty' P frames. Is there any way to force ffmpeg to encode in this way?
Rich Felker wrote:
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.) While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow...
I've also tried going down this line of attack, but it seems that ffmpeg doesn't make multiple executions of the encode_thread for a given frame very easy - all the rtp callbacks and bitstream output happen directly from within the thread. I take this to mean that I have to completely isolate the encode_thread and buffer all its sideeffects in order to run it in a sandbox to see how big its output is going to be, and then re-run it with a higher QP as needed. This seems relatively tricky - is there a better way of doing it, or is this the only way to go?
I've also tried doing a two-pass encode and fiddling the stats file between passes by boosting the perceived i_tex/p_tex/var on frames which were too big, hoping that the next pass would overcompensate and shrink them down. This doesn't seem to work at all - i'm assuming that some kind of blurring or smoothing is annihilating my hacky tweaks, or I'm completely misunderstanding how the multipass encoding is mean to work.
any suggestions would be enormously appreciated.
cheers;
M.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi Dan, Thanks for responding... on re-reading my original mail, I realise that it may have been a bit confused^Wverbose; for the end problem I have is ironically *not* that static images take a long time to resolve, but the opposite - my ffmpeg tends towards single large keyframes, which don't subsequently get updated at all by any predictive frames! Instead, I actually want the blur-convergence behaviour, in the hope that it'll reduce the average size of the frames :) What settings are you using to get the blur-convergence behaviour? When avoiding it, I've been using qmin=3, i_q_factor=2.0, and qdiff=15 without strict VBV ratecontrol, which gives me huge I-frames every GOP, and empty P-frames in between. I'm trying to find a way of reducing the size of those I-frames whilst not compromising the minimum quantisation of I & P frames for normal talking-head style content. thanks; Matthew. On Thu, 28 Jul 2005, Dan Finkelstein wrote:
Hi --
I have also noticed the same phenomena where the h263 encoder will take a number of seconds to converge to a sharp image. My observation is that when a quick movement is made, the image becomes quite blurry and will slowly converge. I've also had trouble picking parameters in the encoder so that the frames are encoded up to a desired maximum data rate and the quality remains decent. (I'm using ffmpeg from cvs a couple of weeks back.)
If you happen across a solution to this, could you please pass it my way ! I'll be glad to test it...
Thanks, Dan
At 07:12 PM 7/25/2005, Matthew Hodgson wrote:
Hi folks,
After a bit of a hiatus, I finally got 'round to trying to cap frame sizes generated by ffmpeg in 1-pass h.263 encoding. Unfortunately, things did not go smoothly - I tried Loren's advice of:
Loren Merrit wrote:
But if you don't mind modifying a few lines of code, look in modify_qscale() line 435 or so. Currently that limits per-frame bits based on the number of bits left in the VBV buffer; you could put in your own cap similarly. (Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.)
...but unfortunately the predicted size of a frame given by qp2bits(rce, q) in modify_qscale seems even more inaccurate than I feared. The problem seems to be that the estimate of the frame size has to converge over time - which is fine for a longish talking-head style video; after ~60 frames it gets pretty accurate and you can detect potential large framesizes and clobber their QP.
However, when a video is made up of a series of different still images (e.g. non-scrolling credits) it takes much longer (~120 frames or so). And whilst it's converging, it guesses the framesize pretty badly - 32 bits rather than the actual 14296 for the first frame, 500 bits rather than 25480 for the 30th frame, 153315 bits rather than 74776 for the 77th frame, etc. (However, frame 91 is almost right (30767 v. 26312), and by frame 121 it's pretty close (30546 v. 30144)).
Am I using the wrong metric for estimating the end frame size in 1-pass encoding? And does anyone know which of the various counters & predictors starts off initialised incorrectly, causing this convergence effect?
Alternatively, I need a way to tell the ratecontrol to encode a sudden change in static image as a small I + several incremental P frames - rather a single huge monolithic I frame and a subsequent string of 'empty' P frames. Is there any way to force ffmpeg to encode in this way?
Rich Felker wrote:
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.) While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow...
I've also tried going down this line of attack, but it seems that ffmpeg doesn't make multiple executions of the encode_thread for a given frame very easy - all the rtp callbacks and bitstream output happen directly from within the thread. I take this to mean that I have to completely isolate the encode_thread and buffer all its sideeffects in order to run it in a sandbox to see how big its output is going to be, and then re-run it with a higher QP as needed. This seems relatively tricky - is there a better way of doing it, or is this the only way to go?
I've also tried doing a two-pass encode and fiddling the stats file between passes by boosting the perceived i_tex/p_tex/var on frames which were too big, hoping that the next pass would overcompensate and shrink them down. This doesn't seem to work at all - i'm assuming that some kind of blurring or smoothing is annihilating my hacky tweaks, or I'm completely misunderstanding how the multipass encoding is mean to work.
any suggestions would be enormously appreciated.
cheers;
M.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi Matthew, My settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax Other values were left at default values. I'm not sure what you mean by i_q_factor and strict VBV ratecontrol-- can you explain? With these settings I get I frames of around 8K bytes and P frames of about 50 -> 1000 bytes depending on the motion. Also, I find that the bit_rate varies a lot -- it might be quite a bit higher than 118000. What I'm trying to achieve is an encoding that keeps the quality to a certain level with the frame rate at or below a certain size. Dan At 04:34 PM 7/28/2005, Matthew Hodgson wrote:
Hi Dan,
Thanks for responding... on re-reading my original mail, I realise that it may have been a bit confused^Wverbose; for the end problem I have is ironically *not* that static images take a long time to resolve, but the opposite - my ffmpeg tends towards single large keyframes, which don't subsequently get updated at all by any predictive frames! Instead, I actually want the blur-convergence behaviour, in the hope that it'll reduce the average size of the frames :)
What settings are you using to get the blur-convergence behaviour?
When avoiding it, I've been using qmin=3, i_q_factor=2.0, and qdiff=15 without strict VBV ratecontrol, which gives me huge I-frames every GOP, and empty P-frames in between. I'm trying to find a way of reducing the size of those I-frames whilst not compromising the minimum quantisation of I & P frames for normal talking-head style content.
thanks;
Matthew.
On Thu, 28 Jul 2005, Dan Finkelstein wrote:
Hi --
I have also noticed the same phenomena where the h263 encoder will take a number of seconds to converge to a sharp image. My observation is that when a quick movement is made, the image becomes quite blurry and will slowly converge. I've also had trouble picking parameters in the encoder so that the frames are encoded up to a desired maximum data rate and the quality remains decent. (I'm using ffmpeg from cvs a couple of weeks back.)
If you happen across a solution to this, could you please pass it my way ! I'll be glad to test it...
Thanks, Dan
At 07:12 PM 7/25/2005, Matthew Hodgson wrote:
But if you don't mind modifying a few lines of code, look in modify_qscale() line 435 or so. Currently that limits per-frame bits based on the number of bits left in the VBV buffer; you could put in your own cap similarly. (Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.) ...but unfortunately the predicted size of a frame given by qp2bits(rce, q) in modify_qscale seems even more inaccurate than I feared. The
On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
(Warning: anything done by a 1pass encode will be an approximate/soft limit, since you don't know in advance excatly how many bits a given QP will take. So you'll need to fudge the limit a little if you care about strict compliance.) While true, this isn't an inherent limitation, just a flaw in lavc's rate control engine. It's easy to implement strict limits in 1pass encoding: just repeatedly reencode the frame at different values of qp until you find one that gives the size you want. With binary search it shouldn't even be that slow... I've also tried going down this line of attack, but it seems that ffmpeg doesn't make multiple executions of the encode_thread for a given frame very easy - all the rtp callbacks and bitstream output happen directly from within the thread. I take this to mean that I have to completely isolate the encode_thread and buffer all its sideeffects in order to run it in a sandbox to see how big its output is going to be, and then re-run it with a higher QP as needed. This seems relatively tricky - is
Hi folks, After a bit of a hiatus, I finally got 'round to trying to cap frame sizes generated by ffmpeg in 1-pass h.263 encoding. Unfortunately, things did not go smoothly - I tried Loren's advice of: Loren Merrit wrote: problem seems to be that the estimate of the frame size has to converge over time - which is fine for a longish talking-head style video; after ~60 frames it gets pretty accurate and you can detect potential large framesizes and clobber their QP. However, when a video is made up of a series of different still images (e.g. non-scrolling credits) it takes much longer (~120 frames or so). And whilst it's converging, it guesses the framesize pretty badly - 32 bits rather than the actual 14296 for the first frame, 500 bits rather than 25480 for the 30th frame, 153315 bits rather than 74776 for the 77th frame, etc. (However, frame 91 is almost right (30767 v. 26312), and by frame 121 it's pretty close (30546 v. 30144)). Am I using the wrong metric for estimating the end frame size in 1-pass encoding? And does anyone know which of the various counters & predictors starts off initialised incorrectly, causing this convergence effect? Alternatively, I need a way to tell the ratecontrol to encode a sudden change in static image as a small I + several incremental P frames - rather a single huge monolithic I frame and a subsequent string of 'empty' P frames. Is there any way to force ffmpeg to encode in this way? Rich Felker wrote: there a better way of doing it, or is this the only way to go? I've also tried doing a two-pass encode and fiddling the stats file between passes by boosting the perceived i_tex/p_tex/var on frames which were too big, hoping that the next pass would overcompensate and shrink them down. This doesn't seem to work at all - i'm assuming that some kind of blurring or smoothing is annihilating my hacky tweaks, or I'm completely misunderstanding how the multipass encoding is mean to work. any suggestions would be enormously appreciated. cheers; M. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
My settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax
Other values were left at default values. I'm not sure what you mean by i_q_factor and strict VBV ratecontrol-- can you explain?
With these settings I get I frames of around 8K bytes and P frames of about 50 -> 1000 bytes depending on the motion. Also, I find that the bit_rate varies a lot -- it might be quite a bit higher than 118000.
You should also set rc_max_rate and rc_buffer_size for strict CBR operation. Quality will certainly degrade, but bitrate behaves much better with this. Regards, Dario Andrade
I have tried your suggestion and added these initialization parameters: c->rc_max_rate = c->bit_rate * 2; c->rc_buffer_size = c->bit_rate * 2; When I run this, the error "rc buffer underflow" is displayed repeatedly in my debug monitor. Can you comment on whether the values that I have set these parameters to is reasonable? Also, is there another parameter that I need, perhaps something like rc_initial_buffer_occupancy? Thanks very much, I'm a bit puzzled how the encoder should be properly initialized, Dan At 11:17 PM 7/28/2005, Dario Andrade wrote:
My settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax
Other values were left at default values. I'm not sure what you mean by i_q_factor and strict VBV ratecontrol-- can you explain?
With these settings I get I frames of around 8K bytes and P frames of about 50 -> 1000 bytes depending on the motion. Also, I find that the bit_rate varies a lot -- it might be quite a bit higher than 118000.
You should also set rc_max_rate and rc_buffer_size for strict CBR operation. Quality will certainly degrade, but bitrate behaves much better with this.
Regards, Dario Andrade
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
I have tried your suggestion and added these initialization parameters:
c->rc_max_rate = c->bit_rate * 2; c->rc_buffer_size = c->bit_rate * 2;
When I run this, the error "rc buffer underflow" is displayed repeatedly in my debug monitor. Can you comment on whether the values that I have set these parameters to is reasonable? Also, is there another parameter that
What is the frame size, fps and codec you're using? Regards, Dario Andrade
Hi -- Here are the details. In particular, the frame size is set to 320x240, the frames per second is set to 30 and I'm using the h263 encoder. My other settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax Thanks very much ! Dan At 10:47 AM 8/11/2005, Dario Andrade wrote:
I have tried your suggestion and added these initialization parameters:
c->rc_max_rate = c->bit_rate * 2; c->rc_buffer_size = c->bit_rate * 2;
When I run this, the error "rc buffer underflow" is displayed repeatedly in my debug monitor. Can you comment on whether the values that I have set these parameters to is reasonable? Also, is there another parameter that
What is the frame size, fps and codec you're using?
Regards, Dario Andrade
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
My other settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax
Dan, In my opinion, bitrate is too low for a qvga 30fps video. Underflow happens when in the theoretic buffering model "detects" that the produced bitstream will take longer than it needs to correctly be consumed by a hypothetical decoder. So I'd try reducing parameters or increasing bitrate. Cheers, Dario Andrade
Thanks very much ! Dan
I have tried your suggestion and added these initialization
c->rc_max_rate = c->bit_rate * 2; c->rc_buffer_size = c->bit_rate * 2;
When I run this, the error "rc buffer underflow" is displayed
repeatedly
in my debug monitor. Can you comment on whether the values that I have set these parameters to is reasonable? Also, is there another parameter
At 10:47 AM 8/11/2005, Dario Andrade wrote: parameters: that
What is the frame size, fps and codec you're using?
Regards, Dario Andrade
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
On Sat, 2005-08-13 at 11:33 -0300, Dario Andrade wrote:
My other settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax
Hi, I am facing with the same problems (even if I am using MPEG4 encoder). These are the parameters I am using: c->width = 640; c->height = 480; c->frame_rate = 3; c->frame_rate_base= 1; c->gop_size = 6; c->bit_rate = 128*1024; //512*1024 //1024*1024; c->bit_rate_tolerance = c->bit_rate * 20 / 100; c->flags |= CODEC_FLAG_AC_PRED; c->flags |= CODEC_FLAG_4MV; c->flags |= CODEC_FLAG_PART; And the video I obtain is really chopped when motion happens. Maybe there are other parameters I have to set? I have tryed to use also qmin and qmax but almost nothing has changed. If someone could help me I would be glad. Cheers, Luca
On Sat, Aug 13, 2005 at 06:38:29PM +0200, Luca Zappella wrote:
On Sat, 2005-08-13 at 11:33 -0300, Dario Andrade wrote:
My other settings are set dynamically but tend to be like this: gop_size = 60 bit_rate = 118000 time_base.num = 1 time_base.den = 30 bit_rate_tolerance = 118000/5 qmin = 3 qmax = 10 mb_lmin = FF_QP2LAMBDA * qmin mb_lmax = FF_QP2LAMBDA * qmax
Hi, I am facing with the same problems (even if I am using MPEG4 encoder). These are the parameters I am using:
c->width = 640; c->height = 480; c->frame_rate = 3; c->frame_rate_base= 1; c->gop_size = 6; c->bit_rate = 128*1024; //512*1024 //1024*1024; c->bit_rate_tolerance = c->bit_rate * 20 / 100; c->flags |= CODEC_FLAG_AC_PRED; c->flags |= CODEC_FLAG_4MV; c->flags |= CODEC_FLAG_PART;
And the video I obtain is really chopped when motion happens.
WTF do you expect with 3 fps?!? Anyway it looks like you're using a very very old version of lavc since frame_rate does not exist anymore. Rich
participants (6)
-
dalias＠aerifal.cx -
dario＠sinistro.net -
df1＠nosimpler.com -
lorenm＠u.washington.edu -
luca.zappella＠gmail.com -
matthew＠mxtelecom.com