Quantcast FFmpeg vs FFvfw vs Mencoder ? - Page 4 - digitalFAQ.com Forums [Archives]
  #61  
02-19-2004, 05:23 PM
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
Quote:
Originally Posted by bilu
MPEG-4 uses much more keyframes (I frames) than MPEG-2, so MPEG-2 has to preserve better the inter frames (P and B frames), hence using lower quantizers on them.
Sorry you misunderstand.

mpeg4 does have much more Frames within the I frame interval!
Means much more non intra frames! And therefore LESS I frames within a whole stream. Do look at somem Divx or Xvids as they come with about 300 Frames within the Intra Frame steps. But as mpeg4 uses a diff. algor. way, you can cut the non intra frames more agressive.
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
  #62  
02-20-2004, 04:46 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Understood now: MPEG-4 uses less I-frames and still can compress P and B frames more aggressively. Evolution indeed


Bilu
Reply With Quote
  #63  
02-20-2004, 01:48 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
Quote:
Originally Posted by bilu
4) Ever wondered if fractional quantizers would break MPEG-2 compatilibity?
No, because the generated file has fractional quantisizers in many points (check with BitRate Viewer)
Do you know if Bitrate Viewer is just reporting an average mabroblock quantizer instead? Maybe fractional quantizers don't really exist, and the frame quantizer is an average of macroblock quantizers.

Bilu
Reply With Quote
  #64  
02-20-2004, 03:21 PM
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
Do you know if Bitrate Viewer is just reporting an average mabroblock quantizer instead? Maybe fractional quantizers don't really exist, and the frame quantizer is an average of macroblock quantizers.
Bilu
Maybe you're right... I see no other reason for mencoder to don't accept fractional min quantisizer and round vqscale values..
Reply With Quote
  #65  
02-20-2004, 04:10 PM
Hydeus Hydeus is offline
Free Member
 
Join Date: Dec 2003
Location: Omicron Persei 8
Posts: 322
Thanks: 0
Thanked 0 Times in 0 Posts
Maybe this is non exactly related, but in ffvfw (also libavcodec) it is impossible to even type fractial quantizer value. It don't accept dots, and when you force it (copy x.y value into box) it gets red. So maybe this is libavcodec behavior
__________________
Go for SECAM =)
Reply With Quote
  #66  
02-21-2004, 04:31 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Has anyone here ever seen a MPEG-1/2/4 codec that supported fractional quantizers?

I never did


Bilu
Reply With Quote
  #67  
02-22-2004, 06:05 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Hi bilu, hi all:
well, I followed this difficult-to-follow thread (difficult for me, no idea in mpeg encoding, even less mencoder parameters), and tested every suggestion you did. To my eyes, the best ones where the last ones:
vqsquish=0:vqcomp=0:vrc_eq=1
and HiBitrate VBR --> vqsquish=0:vqblur=0:vqcomp=1:vrc_eq=tex
...but
I tried to improve image and raise bitrate in HiBitrate VBR test (already using naq: trell: cbp: scplx_mask=0.5: mv0) and changed vqmax=4:mbqmax=4 from default values I was using. The file size grew a little.
...but
when I tried to employ higher bitrates (thinking in KDVD) and changed vrc_maxrate=8000:vbitrate=8000, I got NO change in file size, neither in quality. I don't have BitrateViewer installed (already enough things installed in my poor PC), but it seems bitrate doesn't raise, and for what I understood in this thread, it had to raise after raising vbitrate and vrc_maxrate.
Am I doing anything wrong?, how can I make bitrate raise?. I'm not even sure if with my previous settings (vrc_maxrate=5000:vbitrate=5000) I'm really getting to these bitrates in bit-demanding scenes. Help please.
Reply With Quote
  #68  
02-22-2004, 06:46 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Hi digitall.doc,

------------------------------------
Settings for 1-pass HiBitrate VBR are:

vrc_maxrate=vbitrate
vrc_eq=tex
vqblur=0

vqsquish should be left as 1 (default).
------------------------------------
vqcomp setting is not needed when using vrc_eq=tex or vrc_eq=1, it's just a part of the original vrc_eq formula (tex^qComp).
------------------------------------
trell
cbp
mbd=2
mv0

all of this settings improve quality.
------------------------------------
-scplx_mask=0.5
-naq

scplx_mask works like a deblocker and increases compressibility, lowering bitrate and quality. Not what you're looking for

naq is used with *_mask settings only.
------------------------------------
Don't mess with vqmax and mbqmax, only with vqmin and mbqmin.

By messing with vqmax and mbqmax you could be limiting the encoders capability to decrease quality if needed to avoid max bitrate overflows.

Leave vqmin=2 and mbqmin=2 for maximum quality.
------------------------------------
vrc_maxrate=8000:vbitrate=8000 seems fine to me
------------------------------------

When aiming for high bitrates, the HiBitrate VBR method is perfectly fine: is goes for the less compression possible unless it goes over the maximum bitrate specified.

However, if you ever want to decrease size to fit in a DVD/CD/whatever, you're better with a two pass process.

The main difference in the settings (plus the 2-pass specific ones of course) is that vqblur will not be used and vbitrate should be calculated like this (vrc_maxrate will still be the same):

(CD size (MB) * 1024 (KB) * 8 (Kb) ) / movie time (sec) = avg bitrate

CD size is not the whole media size, just what's left after the audio/structures/whatever.

EDIT: This is for the 2nd pass, 1st pass must be done without any vbitrate setting and using vqscale=2.

As you can read through my posts I've never used mencoder myself... yet

Bilu
Reply With Quote
  #69  
02-22-2004, 08:36 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
hi bilu,

I'm now on the mencoder encoding side of things here these days

I've also used ffvfw too, and I do like it, though I'm still a little lost/puzzled
about other's findings (spiky bitrates etc) but since I'm now working w/
mendocoder, (creating a GUI) I am having issues with this bitrates. I posted
this question (similar) in another thread here. Anyways..

I'm trying to find out which mencoder command-line param(s) are the ones
responsible for raising/lowering the final encodes filesize.

I have adjusted the following params (latest is what you see now) and they
are staying the same, in filesize. I can't actually see any difference though,
when I view the video:

Quote:
vrc_minrate=1200:vrc_maxrate=4000:vbitrate=1800:vr c_buf_size=3400
One more question, I can't seem to find the param that is responsible of
changing the VBV value. ie, bviewer is showing 208 as my value. I want
to get it to show 224 (as in my DVD encodes are, in TMPG) Actually, I want
to be able to change it to whatever value I want, but I can't figure this one
out

Oh, and listen, thanks for taking the time to demonstrate and discuss your
findings/research (through hard work/trial 'n error) and sharing it here on
kvcd

-vhelp
Reply With Quote
  #70  
02-23-2004, 06:30 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 vhelp
I'm trying to find out which mencoder command-line param(s) are the ones
responsible for raising/lowering the final encodes filesize.

I have adjusted the following params (latest is what you see now) and they are staying the same, in filesize. I can't actually see any difference though, when I view the video:

Quote:
vrc_minrate=1200:vrc_maxrate=4000:vbitrate=1800:vr c_buf_size=3400
Increase/decrease vbitrate. To raise filesize you can also decrease vqmax and mbqmax quantizers. There's also the option to add/remove noise.
Quote:
Originally Posted by vhelp
One more question, I can't seem to find the param that is responsible of
changing the VBV value. ie, bviewer is showing 208 as my value. I want
to get it to show 224 (as in my DVD encodes are, in TMPG) Actually, I want
to be able to change it to whatever value I want, but I can't figure this one
out
Other guys will have to answer this question...
I never did an MPEG-2 encode. Ever. I want to do it on a old Pentium 200 w/ 64 MB RAM running Linux or FreeBSD, but all I've did before was MPEG-4 and have no MPEG-2 experience. I've been searching docs based on my MPEG-4 knowledge that is similar to MPEG-2, like bitrate control, quantizers, or rate distortion. YOU guys have been testing, I've only got the docs and some theory for you

I'm still trying to find what VBV is. This is what I found so far about VBV for MP@ML (Main Profile @ Main Level) used for DVDs:

http://www.mpeg.org/MPEG/DVD/Book_B/Video.html
http://www.ee.columbia.edu/~eleft/e6...s/is138182.pdf

Still checking for more. If someone explained or pointed a good resource it would be nice

Quote:
Originally Posted by vhelp
Oh, and listen, thanks for taking the time to demonstrate and discuss your
findings/research (through hard work/trial 'n error) and sharing it here on
kvcd
Thank YOU guys for sharing your testing effort with me. I never used Bitrate Viewer and have no previous MPEG-2 experience that could provide me with comparison references


Bilu
Reply With Quote
  #71  
02-23-2004, 07:12 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
http://zebra.fh-weingarten.de/~maxi/.../msg01147.html

Code:
The mplex manpage states 46KB for VCD and 230KB for SVCD.
Tsunami MPEG encoder templates default to 224KB for DVD, 112KB for SVCD
and 40KB for VCD.

vrc_buf_size == (x*1024*8/1000)

vrc_buf_size    mplex      tsunami
VCD              376         327
SVCD            1884         917
DVD             1884        1835
vrc_buf_size=<value> buffer size in kbit

VCD: 40 KB *(1024*8/1000) = 40 * 8,192 = 327,68
SVCD: 112 KB * 8,192 = 917,504
DVD: 224 KB * 8,192 = 1835,008

So here lies the answer about VBV. Now I'm trying to find out where did Tsunami and Mplex got those values...

EDIT1: 224 KB for DVD makes sense to me now: 1835008 bits is the maximum VBV buffer in the MP@ML specification

Conclusion: for VBV parameters use the vrc_buf_size setting with this formula:

Quote:
value for Mencoder/FFMPEG = value for TMPGEnc * 8,192
Bilu
Reply With Quote
  #72  
02-23-2004, 07:54 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 Vhelp,
I have already posted it several times in answer to your question
"vrc_buf_size=vbv"
According to equation mentioned by Bilu: vbv=vbv_you_want*1024*8/1000
So for VCD case vbv should be 40*1024*8/1000. Use vrc_buf_size=328
For SVCD case vbv should be 112*1024*8/1000. Use vrc_buf_size=918
For (K)DVD case vbv should be 224*1024*8/1000. Use vrc_buf_size=1835
Here is my last trial using Incs or Amenophis command:
@echo off
mencoder -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29, 34,9,10,14,
26,27,29,34,37,12,14,18,27,29,34,37,38,22,26,27,31 ,36,37,38,40,26,27,29,36,39,38,40,48,27,29,
34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38 ,40,48,58,69,79:inter_matrix=16,18,20,22,
24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26,28 ,30,32,34,22,24,26,30,32,32,34,36,24,26,28,
32,34,34,36,38,26,28,30,32,34,36,38,40,28,30,32,34 ,36,38,42,42,30,32,34,36,38,40,42,44:mbd=0:
vbitrate=3000:vrc_maxrate=8000:vrc_minrate=300:
vrc_buf_size=1835:keyint=15:vqmin=2:vqmax=24:
vmax_b_frames=2:vb_qfactor=1.2:vi_qfactor=0.8:vb_q offset=0.75:vqblur=0.3:vlelim=-4:vcelim=2:
vfdct=6:aspect=4/3 -nosound c:\video\mplayer\bttf_i.avi -o c:\video\mplayer\encoded.mpg
pause
bbdmux encoded.mpg 0xe0 decoded.m2v
pause

In fact bitrate viewer will always claim you're using a vbv buffer half the size you chose. But it's all working perfectly because it does it with all encoders out there.
As for rising or lowering the bitrate I'm also a bit puzzled about it so better wait for a more clear explanation.
Don't get me wrong Bilu. but I didn't understand it with your effort to explain it.
Hope I helped.
Cheers
__________________
Rui
Reply With Quote
  #73  
02-23-2004, 09:11 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
About that command-line: try mbd=2 and vqblur=0. You won't regret.

About rising/lowering bitrate:

If you add noise, you increase bitrate.
If you remove noise, you decrease bitrate.

If you increase vbitrate (speaking of a 2-pass process, not that HiBitrate VBR 1-pass stuff) you'll increase the average bitrate, so it will use lower quantizers, increasing the filesize.

If you decrease vqmax and mbqmax quantizers you limit the capability of the encoder to compress the stream. This will also increase filesize, but may limit your filesize prediction when doing 2-pass. Good only for normal 1-pass (not high-bitrate oriented)

If this is not enough explanation please post a specific doubt.

Bilu
Reply With Quote
  #74  
02-23-2004, 09:26 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 rds_correia
According to equation mentioned by Bilu: vbv=vbv_you_want*1024*8/1000
So for VCD case vbv should be 40*1024*8/1000. Use vrc_buf_size=328
For SVCD case vbv should be 112*1024*8/1000. Use vrc_buf_size=918
For (K)DVD case vbv should be 224*1024*8/1000. Use vrc_buf_size=1835
VCD: 40 KB * 8,192 = 327,68
SVCD: 112 KB * 8,192 = 917,504
DVD: 224 KB * 8,192 = 1835,008

Since this is a maximum buffer size it's better to round down IMHO.

VCD = 327
SVCD = 917
DVD=1835


Bilu
Reply With Quote
  #75  
02-23-2004, 11:20 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
From http://www.doom9.org/mpg/dvd2svcd_advref.html#cce :
Quote:
Bitrate limitation ---In the DVD standard, the maximum bitrate of Video ES is limited to 9.8 Mbps. In the MPEG-2 VIDEO international standard (ISO/IEC 13818-2), the size of an individual picture is limited using the concept of ?VBV (Video Buffering Verifier)?. In the concept of VBV, a stream having a 9.8 Mbps bitrate can create GOP which has a size equivalent to a maximum of 11 Mbps. This perfectly
conforms to the MPEG-2 VIDEO international standard (ISO/IEC 13818-2), but whether it conforms to the 9.8 Mbps restriction of DVD depends on interpretation.

If DVD compliant is selected, instantaneous bitrate in GOP units is controlled to be a maximum of 9.8Mbps. During VBR operation, 9.8 Mbps is always written to the sequence header regardless the specified maximum bitrate. 9.8 Mbps is the maximum bitrate allowed under the DVD standard. 9.8 Mbps is used here because in the case of the VBV model in VBR, bit allocation planning by the encoder becomes more flexible as the maximum bitrate becomes higher, therefore higher image quality can be achieved.
From http://www.mpeg.org/MPEG/DVD/Book_B/Video.html :
Quote:
The maximum bitrate of 9.8 Mbit/sec is more restrictive than MP@ML's 15 Mbit/sec limit. However, the point of diminishing returns (no visual difference between original video and compressed video) is widely known to be around 9 Mbit/sec.
IMHO there is no greater gain in exploring VBV formulas and bitrates over 9,8 Mbps.

Bilu
Reply With Quote
  #76  
02-23-2004, 11:41 AM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Hi bilu:
thanx for all your answers. As you can see, we keep coming back to the thread to share our results. And your help is much appreciated (I still don't know how you manage to avoid temptation to make a encode at a friends' computer, or even at a cybercoffee )
Well, in my post I asked how could I raise bitrate, because using vbitrate=5000 and vrc_maxrate=5000 gave the same file size than vbitrate=8000 and vrc_maxrate=8000, and the same "visual" aspect (in a scene a aircraft explodes... in lots of macroblocks ). To get rid of those macroblocks I thought I could raise bitrate from 5000 to 8000, but same filesize and same visual aspect. I didn't test it in bitrateviewer to see if bitrate does increase, but it looks as it didn't change between 5000 and 8000. Any hints?
Another question: what are vb_qfactor, vi_qfactor, vb_qoffset, suppossed to be useful for?. I don't understand manpage explanation, I understand you better. I see that rds, inc and amenophis are using them... so they must be useful. But, what for?, and how tweak them?.
Reply With Quote
  #77  
02-23-2004, 11:58 AM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Posting again,... sorry:
I forgot to say:
- I made two tests with the same parameters, but in one I resized via avisynth script (no GripFit, but Inc method with MovieStacker) and in the other I resized internally in mencoder with crop/scale/expand.
The visual result the same. But MUCH slower with -vf internal filters, to my surprise. It dropped from 8 fps with avisynth, to 4 fps with internal filters
- I'm thinking about testing 2 pass mode... could someone post a example command line (with vqscale in first pass, vqblur in second pass, vbitrate settings for first and second,... and a possible way to make first pass faster to shorter encoding time). Am I asking too much?.
Thanx
Reply With Quote
  #78  
02-23-2004, 12:59 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 digitall.doc
Well, in my post I asked how could I raise bitrate, because using vbitrate=5000 and vrc_maxrate=5000 gave the same file size than vbitrate=8000 and vrc_maxrate=8000, and the same "visual" aspect (in a scene a aircraft explodes... in lots of macroblocks ). To get rid of those macroblocks I thought I could raise bitrate from 5000 to 8000, but same filesize and same visual aspect. I didn't test it in bitrateviewer to see if bitrate does increase, but it looks as it didn't change between 5000 and 8000. Any hints?
Did you use this?

vrc_eq=tex
vqblur=0

trell
cbp
mbd=2
mv0

Also try this, decreases bitrate but works as a deblocker:

-scplx_mask=0.5
-naq

About noise, you should know better than me from the FFVFW noise threads

Quote:
Originally Posted by digitall.doc
Another question: what are vb_qfactor, vi_qfactor, vb_qoffset, suppossed to be useful for?. I don't understand manpage explanation, I understand you better. I see that rds, inc and amenophis are using them... so they must be useful. But, what for?, and how tweak them?.
Quote:
b_qfactor=<-31.0-31.0>
quantizer factor between B and non B frames (pass 1/2) (default: 1.25)

vi_qfactor=<-31.0-31.0>
(pass 1/2) (default: 0.8 )

vb_qoffset=<-31.0-31.0>
quantizer offset between B and non B frames (pass 1/2) (default: 1.25)

vi_qoffset=<-31.0-31.0>
(pass 1/2) (default: 0.0)
All of these values establish a relation between P-frame quantizers and the rest.

vi_qfactor is a quantizer factor between I and P frames. default 0.8 means that I = 0.8 * P -> lower quantizers on keyframes.

b_qfactor is a quantizer factor between B and I/P frames. B-frames are generated with info from both the previous and the next frame and generally can be more compressed than I/P frames.

v{b|i}_qoffset is an offset to formulas like:
Bquant=Pquant * Bfactor +Boffset

Quote:
if v{b|i}_qfactor > 0
I/B-Frame quantizer = P-Frame quantizer * v{b|i}_qfactor + v{b|i}_qoffset else do normal ratecontrol (dont lock to next P frame quantizer) and set q= -q * v{b|i}_qfactor + v{b|i}_qoffset
I must agree with you that this explanation ***SUCKS***.
I'm glad I learned a lot of those concepts through XVid, they're much better at explanations.

According to this explanation

if {b|i}factor > 0 then {b|i}quant = Pquant * {b|i}factor + {b|i}offset;
if {b|i}factor < 0 then {b|i}quant = -Pquant * {b|i}factor + {b|i}offset;
if {b|i}factor = 0 then {b|i}quant = {b|i}offset; (not recommended)

These negative quantizer values seem to exist just to avoid locking on the next P-frame quantizer and use normal rate control. Probably not recommended, but who knows???

Quote:
Tip: To do constant quantizer encoding with differ- ent quantizers for I/P and B frames you can use:

vqmin= <ip_quant>:vqmax= <ip_quant>:vb_qfactor= <b_quant/ip_quant>
This is XVid-like. B-frames will have an increased compression factor over I/P frames, usually around 1.25, and that's the default.

But the default is vmax_b_frames=0, which means no B-frame encoding.

Bilu
Reply With Quote
  #79  
02-23-2004, 01:22 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 rds_correia
In fact bitrate viewer will always claim you're using a vbv buffer half the size you chose. But it's all working perfectly because it does it with all encoders out there.
According to http://www.ee.columbia.edu/~eleft/e6...s/is138182.pdf :
Quote:
vbv_buffer_size -- vbv_buffer_size is an 18-bit integer. The lower 10 bits of the integer are in
vbv_buffer_size_value and the upper 8 bits are in vbv_buffer_size_extension. The integer defines the
size of the VBV (Video Buffering Verifier, see Annex C) buffer needed to decode the sequence. It is
defined as:
B = 16 * 1024 * vbv_buffer_size
where B is the minimum VBV buffer size in bits required to decode the sequence (see Annex C).
So Bitrate Viewer does

VBV = B / (1024*16)

(B is minimum VBV buffer size needed, in bits)

while we do

VBV = (x*1024*8/1000)

(x is the VBV buffer size from TMPGEnc, in KB)

I think Bitrate Viewer checks how many bits it needs to decode the sequence ( the B value ) and calculates VBV according to the specs.

Unless the minimum VBV size is half the max VBV size, there is something strange here. Also as you can see from posts above I was able to prove that the DVD values from TMPGEnc make sense according to the spec


Bilu
Reply With Quote
  #80  
02-23-2004, 01:51 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
Did you use this?

vrc_eq=tex
vqblur=0

trell
cbp
mbd=2
mv0

Also try this, decreases bitrate but works as a deblocker:

-scplx_mask=0.5
-naq

About noise, you should know better than me from the FFVFW noise threads
Well, I already used all this settings, with lots of macroblocks during the explosion, that didn't improve raising bitrate from 5000 to 8000. I didn't try adding noise, but I still don't understand why the encoder doesn't make use of higher bitrate avaliable to improve the image and avoid this macroblocks...
I didn't try SATD instead of default (?) SAD to see if this improves quality (avoids these macroblocks), but I didn't want to make encoding even slower...
From a theoretical point of view... what values, thinking in quality terms, would you advise for b_qfactor, vi_qfactor, vb_qoffset, and vi_qoffset

And what about a command line for 2pass encoding
Thank you again for support
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

Thread Tools



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