[MPlayer-users] [BUG] ratecontrol.c:693: ff_rate_estimate_qscale: Assertion `pict_type == rce->new_pict_type' failed.

[Michael Niedermayer]

Hi

On Wed, May 24, 2006 at 10:43:27AM -0700, Corey Hickey wrote:
> Corey Hickey wrote:
> >>btw, something else which seems noone knows about (and i forgot) is
> >>-lavcopts aic (does enable ac prediction in intra MBs of mpeg4 ...)
> >
> >Hmm. I'd always ignored that based on the description in the mplayer man 
> >page:
> >
> >aic
> >    ac prediction (advanced intra prediction for H.263+)
> >    NOTE: vqmin should be 8 or larger for H.263+ AIC.
> >
> >The description indicates that it's only for H.263+, which I guess isn't 
> >accurate. What does AC stand for? It's hard to find definitions for 
> >acronyms like that on google.
> >
> >I just did a very quick test, and enabling aic raised psnr from 40.10 to 
> >40.13. I can't look at the video itself from here, but I have a longer 
> >test started that might be finished by the time I get home.
> 
> Argh, the power went out, so I had to run the test overnight and have a 
> quick look this morning.
> 
> for i in 1:turbo:vb_strategy=2 2 ; do
>   mencoder matrix.vob -nosound -vf crop=718:356:0:60,scale=640:272 \
> -sws 9 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=581:psnr:mbd=2:mv0:\
> trell:cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\
> last_pred=2:vmax_b_frames=2:qpel:sc_factor=6:\
> vrc_eq="(tex+10^8*mcVar)^0.6":vpass=$i -ofps 24000/1001 -o default.avi
> done
> 
> Pass 1:
> PSNR: Y:40.48, Cb:44.46, Cr:44.83, All:41.48
> user    110m12.246s
> 
> Pass 2:
> PSNR: Y:42.20, Cb:45.25, Cr:46.04, All:43.07
> user    174m14.320s
> 
> 
> Now, adding aic to the above options:
> 
> Pass 1:
> PSNR: Y:40.48, Cb:44.47, Cr:44.83, All:41.48
> user    110m35.194s
> 
> Pass 2:
> PSNR: Y:42.22, Cb:45.26, Cr:46.06, All:43.09
> user    176m34.086s
> 
> 
> 
> Visually, I couln't see much of an overall difference. I only had time 
> to look at two scenes, though. On the first scene, many frames of the 
> aic encode looked very very slightly worse. On the second scene, several 
> frames of the aic encode looked somewhat better and one or two looked 
> very slightly worse. Both of these are probably due to the normal 
> variation induced by adding an option; I don't think they're indicative 
> of any actual change in visual quality.

yes, if all parameters (quantization parameters, motion vectors) are held
constant and ac prediction is enabled then the quality/PSNR/the decoded
video will stay exactly equal, only the number of bits needed will decreas
a little (this might not be exactly true for aic in h263+)


> 
> With encoding times that close, the difference can be largely due to 
> experimental error. Just now, I ran several short encodes with default 
> lavc options (besides vbitrate) and found that aic consistently slowed 
> down mencoder by 1%. ...which actually matches the difference shown 
> above, though that might be a coincidence. I wouldn't expect aic to make 
> as much of a difference when several other options slow the encoding 
> down by a much larger factor, so I did a short test of that as well, and 
> found there to be no consistent change.
> 
> Since aic seems to improve PSNR, albeit slightly, and only slow the 
> encoding down by a negligable amount, I would say there's no reason not 
> to use it.
> 
> Michael, I'd like to change the mplayer man page description of aic. 
> Currently it only mentions h.263+, and we know it works for MPEG-4. Are 
> there any other lavc encoders that support aic?

no, ac prediction is supported by h263+, mpeg4 and h264 but x264 IIRC
always uses ac prediction (disabling it completely in h264 is pretty
stupid)
also ac prediction in h263+ (advanced intra coding) and mpeg4 (ac prediction)
is done somewhat differently

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is