Quantcast FFmpeg vs FFvfw vs Mencoder ? - Page 2 - digitalFAQ.com Forums [Archives]
Go Back    digitalFAQ.com Forums [Archives] > Video Production Forums > Video Encoding and Conversion

Reply
 
LinkBack Thread Tools
  #21  
02-17-2004, 06:17 PM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Looks like I just found a possible way (maybe?). I just downloaded the latest CVS of mplayer (which includes mencoder) and compiled under cygwin. Looks like all rate control code is in a file called ratecontrol.c . Maybe we could change it for our purposes, doesn't look so hard to understand. Anyone with C knowledge is invited!
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #22  
02-17-2004, 06:20 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Aha! Now you're talking VM.
What did I tell you? This guy is a genious!
I'm just sad because I don't know C. That is I don't know any language but pascal, and that was a looooong time ago...
Any volunteers?
Cheers
__________________
Rui
Reply With Quote
  #23  
02-17-2004, 06:44 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
That is I don't know any language but pascal..
Yeah, but Pascal is more English, while C/C++ is Martian .. "take me to your
leader, ..'Bush?' .."

-vhelp
Reply With Quote
  #24  
02-17-2004, 07:22 PM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
This function holds the key:
Quote:
static void update_predictor(Predictor *p, double q, double var, double size)
{
double new_coeff= size*q / (var + 1);
if(var<10) return;

p->count*= p->decay;
p->coeff*= p->decay;
p->count++;
p->coeff+= new_coeff;
}

static void adaptive_quantization(MpegEncContext *s, double q){
int i;
const float lumi_masking= s->avctx->lumi_masking / (128.0*128.0);
const float dark_masking= s->avctx->dark_masking / (128.0*128.0);
const float temp_cplx_masking= s->avctx->temporal_cplx_masking;
const float spatial_cplx_masking = s->avctx->spatial_cplx_masking;
const float p_masking = s->avctx->p_masking;
float bits_sum= 0.0;
float cplx_sum= 0.0;
float cplx_tab[s->mb_num];
float bits_tab[s->mb_num];
const int qmin= s->avctx->lmin;
const int qmax= s->avctx->lmax;
Picture * const pic= &s->current_picture;

for(i=0; i<s->mb_num; i++){
const int mb_xy= s->mb_index2xy[i];
float temp_cplx= sqrt(pic->mc_mb_var[mb_xy]); //FIXME merge in pow()
float spat_cplx= sqrt(pic->mb_var[mb_xy]);
const int lumi= pic->mb_mean[mb_xy];
float bits, cplx, factor;
#if 0
if(spat_cplx < q/3) spat_cplx= q/3; //FIXME finetune
if(temp_cplx < q/3) temp_cplx= q/3; //FIXME finetune
#endif
if(spat_cplx < 4) spat_cplx= 4; //FIXME finetune
if(temp_cplx < 4) temp_cplx= 4; //FIXME finetune

if((s->mb_type[mb_xy]&CANDIDATE_MB_TYPE_INTRA)){//FIXME hq mode
cplx= spat_cplx;
factor= 1.0 + p_masking;
}else{
cplx= temp_cplx;
factor= pow(temp_cplx, - temp_cplx_masking);
}
factor*=pow(spat_cplx, - spatial_cplx_masking);

if(lumi>127)
factor*= (1.0 - (lumi-12*(lumi-12*lumi_masking);
else
factor*= (1.0 - (lumi-12*(lumi-12*dark_masking);

if(factor<0.00001) factor= 0.00001;

bits= cplx*factor;
cplx_sum+= cplx;
bits_sum+= bits;
cplx_tab[i]= cplx;
bits_tab[i]= bits;
}

/* handle qmin/qmax cliping */
if(s->flags&CODEC_FLAG_NORMALIZE_AQP){
float factor= bits_sum/cplx_sum;
for(i=0; i<s->mb_num; i++){
float newq= q*cplx_tab[i]/bits_tab[i];
newq*= factor;

if (newq > qmax){
bits_sum -= bits_tab[i];
cplx_sum -= cplx_tab[i]*q/qmax;
}
else if(newq < qmin){
bits_sum -= bits_tab[i];
cplx_sum -= cplx_tab[i]*q/qmin;
}
}
if(bits_sum < 0.001) bits_sum= 0.001;
if(cplx_sum < 0.001) cplx_sum= 0.001;
}

for(i=0; i<s->mb_num; i++){
const int mb_xy= s->mb_index2xy[i];
float newq= q*cplx_tab[i]/bits_tab[i];
int intq;

if(s->flags&CODEC_FLAG_NORMALIZE_AQP){
newq*= bits_sum/cplx_sum;
}

intq= (int)(newq + 0.5);

if (intq > qmax) intq= qmax;
else if(intq < qmin) intq= qmin;
//if(i%s->mb_width==0) printf("\n");
//printf("%2d%3d ", intq, ff_sqrt(s->mc_mb_var[i]));

intq=1000;


s->lambda_table[mb_xy]= intq;


}
}
This finds the quantisizer for 1pass vbr for
If we add the line in blue (not originally in the code), mencoder starts encoding with fixed quantisizer 8. (of course, I did this just to test) So it's only a matter to understand how it works and use a fixed quantisizer unless predicted filesize is too big. We'll get there.
Reply With Quote
  #25  
02-18-2004, 05:08 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
I found ou that if you set the parameter vqscale=x in the commandline, you will receive a linear Q curve! BUT very fast blocky pictures on dark areas at lower vqscale's like 3.
IF you set vqmin=500 and vqmax=5000 including a vbitrate=xxxx (was it that command for bitrate? Im at work now) the blocks at dark scenes are almost away BUT on the other hand blocks will appear on fast moving scenes! By this - said without determine the vqscale in the line - the Q curve isn't constant anymore BUT more adaptive to the scene contend which results in less blocks in underwater scenes. But to avoid on the other hand the blocks in moving parts, you have at least to set a vqbitrate=3000.

By this BTW I obtain an encoding-speed of 25fps (my system), means realtime including Avisynth on a 25fps 704x576 stream even a little bit faster than CCE.

But thats all for regular DVD encodings, not KDVD to put 2-3 Moves on one DVD-R Media.

Inc.

PS: So it would be interesting to see in what quality and what vbitrate value does fit the LOTR II SpecialEdition on one DVD-R including AC3. But I don't have that special Edition on my own, so I can't test it.
Reply With Quote
  #26  
02-18-2004, 05:43 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by vmesquita
Looks like what we want is constant quantisizer, if the resulting filesize does not goes beyond the max or below the minimmum. In those cases (and only on those cases), we want the quantisizer to be shiftet up/down to respect max/min. And I don't see a way to do that using any of this options...
So looks like a 1-pass VBR quality based, respecting max/min is impossible with mencoder, unless some changes are made in the source code. Doesn't it?
I have a different opinion: you want constant quality within the bitrate limits. Constant quality can not be the same as constant quantizer if you want to respect those limits. More important than the filesize is the bitrate specification.

What seems to be difficult is having a vqsquish-like parameter for bitrate, using the best quantizer but trying to keep the frame within the bitrate boundaries. And that would mean change the quantizer on a bitrate criteria, not a filesize criteria.

EDIT: From my post above, taken from a mailing list:
Quote:
Then there is a difference between vqscale=n and vqcomp=1. With vqcomp=1 you get the best possible constant quantizer at the desired bitrate while you have to specify the quantizer manually (bitrate is ignored) in the vqscale=n mode.
Solution seems to have been found!

Quote:
vqcomp=<value>
quantizer compression, depends upon vrc_eq (pass 1/ 2) (default: 0.5)

vrc_eq=<equation>
main ratecontrol equation (pass 1/2):
1 constant bitrate
tex constant quality
1+(tex/avgTex-1)*qComp approximately the equation of the old rate-control code
tex^qComp with qcomp 0.5 or something like that (default)
vqcomp=0 -> vrc_eq=tex^0=1 -> constant bitrate
vqcomp=1 -> vrc_eq=tex^1=tex -> constant quality

And this parameter seems to respect the bitrate, not like vqscale. Could someone test it, please?

Bilu
Reply With Quote
  #27  
02-18-2004, 06:28 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
I have a different opinion: you want constant quality within the bitrate limits. Constant quality can not be the same as constant quantizer if you want to respect those limits.
Sorry, but this is about the same thing I said.
Quote:
More important than the filesize is the bitrate specification.
No it's not. Unless you want to use 2-pass VBR. But you can't have a good One Pass VBR mode that respects some average bitrate. Because you'll see something like I said: the encoder can vary the bitrate for a while, but it will get back to the average, ruining the picture, even if the high action is still happening. You can't have good quality and completelly predictable file size in 1 Pass Quality Based, it's impossible. So you must be thinking : why you want that anyway? Because this way I can use prediction (my CCE method) and do 1 pass, what is much faster than 2-pass VBR and has a accuracy of about 3% with every encoder, enough for most people.
Quote:
Solution seems to have been found! (for CBR encodes at least)
But CBR is always known to produce bad quality in high action scenes and wast bitrate in low action scenes... Why would anyone want that?
Reply With Quote
  #28  
02-18-2004, 06:32 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
vqcomp=1 -> vrc_eq=tex^1=tex -> constant quality
Now this is interesting. I'll test it.
Reply With Quote
  #29  
02-18-2004, 06:44 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
I was referring to respecting minimum and maximum bitrates to be DVD compliant.

IMHO this is even more important than filesize.

Bilu
Reply With Quote
  #30  
02-18-2004, 07:31 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
vqcomp=1 -> vrc_eq=tex^1=tex -> constant quality
I tested... But it doesn't woked as I expected. There are many places where this did not work, but the worst example is one high motion scene that got the quantisizer 30 to achive bitrates around 600, while I specified the max 2500.
Maybe we should try some other rate control equations...
Reply With Quote
  #31  
02-18-2004, 08:08 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
I was referring to respecting minimum and maximum bitrates to be DVD compliant.

IMHO this is even more important than filesize.

Bilu
I agree with you, but I think DVD standard does not define a minimmum bitrate... Actually I never got bitrate beyond 9800 using fixed quantisizer. I guess it's more problematic if we're trying to do a KSVCD/KVCD...
I am playing with vqcomp=1 and different rate controls.
Reply With Quote
  #32  
02-18-2004, 08:45 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
This will work:

vrc_minrate=300
vrc_maxrate=2500
vbitrate=2500
vqsquish=1
vqcomp=1
vrc_eq=tex

Unlike it seems, it won't produce 2500 CBR, but will make almost what I want, that would be use quantisizer 2 unless bitrate needed is too high. In this case, use the lowest quantisizer possible to don't go over the maximmum (2500). Seems like using maxrate equal to bitrate makes the encoder don't care about average bitrate (what we want after all)

EDIT: I just have no idea how to rise the quantisizer used when Maximum is not exceeded. I've tried mbqmin and vqmin, but looks like after some time it goes to 2 again. Also I can't use fractional values...
Reply With Quote
  #33  
02-18-2004, 09:38 AM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Hi guys,
Though not having posted anything yet I've been trying VM's last post arguments except for vqcomp=1 & vrc_eq=tex.
Didn't find a way to constrain bitrate and try maintaining quality as constant as possible...
Damn, if you find a way to this let me know .
Maybe the next day one German guy we all know very well has come up with a nice GUI to it too
Cheers
__________________
Rui
Reply With Quote
  #34  
02-18-2004, 09:45 AM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
What I posted will work, but the final size will be unpredictable. And I don't know yet how to lower the constant-when-possible quality to have less filesize.
Also lower bitrate doesn't seem to be working, but this is easy to understand, looks like even using quantisizer 2 (tjhe lowest possible) some scenes fall below the minimmum bitrate.
Reply With Quote
  #35  
02-18-2004, 12:29 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
@vmesquita

Maybe using vqcomp=0 (without messing with the default vrc_eq) will do the trick. After all, it will aim at constant bitrate - so if you equal the average and maximum quantizer it will try the keep at the lowest possible quantizer for that bitrate. And filesize will be more predictable because bitrate will be more constant

EDIT: Rewriting this post, see if this is what you want:

vrc_maxrate = vbitrate -> average will be the maximum bitrate (nice idea VM );
vqcomp=0 -> tries to keep as close to bitrate as possible;

Seems to me that vqcomp=1 tries to keep as close to the original quality as possible but then there is the matter of how is Mencoder perceiving quality from a frame. Mencoder may find a high-motion scene to be low quality and decrease the bitrate (that's probably what happened to VM in a earlier post).

With vqcomp=0 it will try to encode in the closest possible way to the average bitrate regardless of the perceived quality, so using vrc_maxrate = vbitrate together with vqcomp=0 serves our purposes I think

Really cool is the fact that it won't care about texture complexity - just fit it all into maximum bitrate!

Someone willing to try?

vrc_minrate=300
vrc_maxrate=2500
vbitrate=2500
vqsquish=1

vqcomp=0 OR vrc_eq=1 (if you use a vrc_eq without qComp, the vqcomp becomes irrelevant)

EDIT2: vqmin and mbqmin already default to 2, so you don't need to mess with this parameter. If a frame gets less than 2500 at quantizer 2, it won't change to quantizer 1 just to fill the avg bitrate request.

EDIT3: Since this means:

- Lowest possible quantizers;
- respected maximum bitrate;

I don't know what kind of advantages a 2-pass encoding process would bring in this case. None, I think

Just calc the average/maximum bitrate and you're all set!
You won't even need prediction methods

It's like a HiQ CBR


Bilu
Reply With Quote
  #36  
02-18-2004, 02:39 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
vqsquish=1 ?

If using vqcomp=0 and vbitrate=vrc_maxrate there is a small chance that sometimes it goes over the maximum bitrate to fit the average - it depends on how much the vrc_maxrate is respected when using vqsquish=1.

If so we have to use vqsquish=0.

vqsquish=<0,1>
specify how to keep the quantizer between qmin and qmax (pass 1/2):
0 use clipping
1 use a nice differentiable function (default)

But it may not be a problem at all.

Bilu
Reply With Quote
  #37  
02-18-2004, 02:44 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Does anybody know if these work?

v4mv
Allow 4 motion vectors per macroblock (slightly better quality). (default: disabled)
(is this MPEG-2 compliant?)

autoaspect
Same as the aspect option, but automatically computes aspect, taking into account all the adjust- ments (crop/expand/scale/etc.) made in the filter chain.


Bilu
Reply With Quote
  #38  
02-18-2004, 02:48 PM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
bilu,

Yes, what you proposed is like a hi-quality CBR, but note, this is not what we want (or at least me). Because you still can't lower the average quality, you see? I want mencoder to keep constant quantisizer, except when this will result in bitrate higher than specified. If this constant quantisizer could be specified in fractional way, that would be solved, but minimmum quantisizer can only have integer values (it seems)...
Reply With Quote
  #39  
02-18-2004, 02:51 PM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
v4mv, if I remember correctly, crashes if used with MPEG2 in mencoder.
Reply With Quote
  #40  
02-18-2004, 03:04 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by vmesquita
bilu,

Yes, what you proposed is like a hi-quality CBR, but note, this is not what we want (or at least me). Because you still can't lower the average quality, you see? I want mencoder to keep constant quantisizer, except when this will result in bitrate higher than specified. If this constant quantisizer could be specified in fractional way, that would be solved, but minimmum quantisizer can only have integer values (it seems)...
Quantizer=2 -> Maximum quality
Average=Maximum -> Pull the bitrate to the maximum (quantizer to the minimum -> q=2 unless bitrate > maxrate)

In this specific case (q=2) I can't understand the difference. Can you explain a bit more?

Bilu
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
FFMPEG: Ffvfw VIDEO CODEC kwag Video Encoding and Conversion 364 08-12-2005 07:49 AM
FFMPEG: Curious about H.263 in ffvfw poerschr Video Encoding and Conversion 14 02-25-2004 07:54 PM
FFMPEG: Observation about ffvfw poerschr Video Encoding and Conversion 28 02-24-2004 05:50 PM
FFMPEG: Do ffvfw and mencoder/ffmpeg give the same results? Razorblade2000 Video Encoding and Conversion 4 02-06-2004 04:23 PM
FFMPEG: XMPEG 5.03 and ffvfw kwag Video Encoding and Conversion 2 02-05-2004 10:57 AM




 
All times are GMT -5. The time now is 08:32 AM  —  vBulletin © Jelsoft Enterprises Ltd