05-21-2004, 09:39 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hi:
I am testing encoding with avs, makeavis, makeavis combo, and I have some questions.
Quote:
Originally Posted by temp.conf (MakeAvis combo)
of=rawvideo=1
ovc=lavc=1
nosound=1
sws=2
lavcopts=vcodec=mpeg2video:vrc_eq=tex:vmax_b_frame s=2:vrc_maxrate=2500:aspect=1.3333:keyint=24:vrc_b uf_size=917 reme=2 recmp=2:vstrict=-1:autoaspect=1:scplx_mask=0.3:vqblur=0: mbqmin=1:vqmin=1:mbqmin=1:lmin=1:intra_matrix=(notch matrix)
ofps=25
|
1 - When we use avs script, almost for sure, we have resize with bicubic or lanczos. Why sws (maybe if not needed not used) is present, as autoaspect too. I think that both option, could use resources and make encoding slower.
2 - Quote:
"Autoaspect" automatically computes aspect, taking into account all the adjustments (crop/expand/scale/etc.) made in the filter chain. As "aspect", store movie aspect internally, just like MPEG files (but i think mpeg files store movie aspect without using aspect or autoaspect). Much nicer solution than rescaling, because quality isn't decreased. Only MPlayer will play these files correctly, other players will display them with wrong aspect. The aspect parameter can be given as a ratio or a floating point number..
|
Maybe it is useful and this option would be better only available for, mplayer reproduction. (MencodeMe would send this option only for play preview with mplayer).
3 - "mbqmin" is present twice. Is it well? Quote:
mbqmin=1:vqmin=1:mbqmin=1
|
4 - About "vqmin" we can read:
Quote:
vqmin=<1-31>
minimum quantizer (pass 1/2)
1
Not recommended (much larger file, little quality difference and weird side effects: msmpeg4, h263 will be very low quality, ratecontrol will be confused resulting in lower quality and some decoders will not be able to decode it).
|
and
Quote:
3
Recommended for h263(p)/msmpeg4. The reason for preferring 3 over 2 is that 2 could lead to overflows (this will be fixed for h263(p) by changing the quantizer per MB in the future, msmpeg4 cannot be fixed as it does not support that)
|
Why don't use option 3? Maybe can solves buffer underflow issue.
In fact, I just finish a test with this temp.cofg
Quote:
Originally Posted by temp.conf (MakeAvis combo) modified
of=rawvideo=1
ovc=lavc=1
nosound=1
sws=2
lavcopts=vcodec=mpeg2video:vrc_eq=tex:vmax_b_frame s=2:vrc_maxrate=2500:aspect=1.3333:keyint=24:vrc_b uf_size=917 reme=2 recmp=2:vstrict=-1:autoaspect=1:scplx_mask=0.3:vqblur=0: mbqmin=1:vqmin=3:lmin=1:intra_matrix=(notch matrix)
ofps=25
|
Original sample was 6997KB.
Modified sample was 5661KB.
No so difference related to quality.
Can somebody to confirm this?
----------------------
Visit: Intermediate guide: MencodeMe/Win32 - Avisynth - MakeAvis by Prodater64.
Visit: KVCD - MencodeMe - Auxiliar Task - KVCD Docking Gate by Prodater64.
Visit: Mencoder scripting with AVSEdit and Guide for Multiple Files by Prodater64.
Visit: Mini-guide quick and easy - DVD to (S)KVCD with MencodeMe by Maurus.
Visit: Mencode-me: a newbie oriented GUI - 0.23 is out! by VMesquita.
----------------------
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
05-21-2004, 11:19 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
05-22-2004, 07:55 AM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
1 - When we use avs script, almost for sure, we have resize with bicubic or lanczos. Why sws (maybe if not needed not used) is present, as autoaspect too. I think that both option, could use resources and make encoding slower.
|
Don't worry : these option tell to mencoder wich resizer to use and what behavior to have (keeping aspect) IF A RESIZE IS NEEDED.
As you don't do any resize in your process, these option are just useless. You don't lose any time.
|
05-22-2004, 09:44 AM
|
Free Member
|
|
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hi Prodater. That's good, from time to time sit down and review hoew things are being done...
Quote:
Originally Posted by Prodater64
1 - When we use avs script, almost for sure, we have resize with bicubic or lanczos. Why sws (maybe if not needed not used) is present, as autoaspect too. I think that both option, could use resources and make encoding slower.
|
Already answered. Didn't know that, Dialhot.
Quote:
3 - "mbqmin" is present twice. Is it well? Quote:
mbqmin=1:vqmin=1:mbqmin=1
|
|
I think I commented this in the bug thread some time ago. Yes, it's not needed at all. Not really a bug, just useless.
Quote:
4 - About "vqmin" we can read:
Quote:
vqmin=<1-31>
minimum quantizer (pass 1/2)
1
Not recommended (much larger file, little quality difference and weird side effects: msmpeg4, h263 will be very low quality, ratecontrol will be confused resulting in lower quality and some decoders will not be able to decode it).
|
and
Quote:
3
Recommended for h263(p)/msmpeg4. The reason for preferring 3 over 2 is that 2 could lead to overflows (this will be fixed for h263(p) by changing the quantizer per MB in the future, msmpeg4 cannot be fixed as it does not support that)
|
|
Also this has been commented. I tested encoding with vqmin=2 and vqmin=1, and VBR, and the difference in final filesize isn't that big.
I know in man-page it's said what you posted/pasted. But there are two things:
- Is refering to mpeg4 encodings, but maybe also to mpeg2...
- I think this may be true when encoding with constant quantizer (vqscale=1 or vqscale=2). In this case, mencoder keeps quantizers at the given value, and yes, 1 maybe would be too low.
But in our encodings, with VBR and variable quantizers, you can see in BitrateViewer (even if little to be trusted in) that quantizers vary a lot, and usually keep above the vqmin value, and around 1.5-2. But setting vqmin at 1, mencoder has the possibility to lower quantizers a lot when needed (dark scenes,...) and obtain maximum quality possible.
I would keep with vqmin=1 (believe me: it has been hard-tested ). In very few cases, when mencoder has difficulties to get to desired vbitrate, I had to raise vqmin=2 to let mencoder work Ok. But as a general advice keep at 1.
Cheers
|
05-22-2004, 10:35 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by DigiDoc
But setting vqmin at 1, mencoder has the possibility to lower quantizers a lot when needed (dark scenes,...) and obtain maximum quality possible.
|
Exact!
I remeber very well when I had that dicussion with bilu in the mencoder thread where a vqmin at 2 is a too high quantizer in dark underwater scenes.
So you wont recognise a difference now prodater with the low avg bitrate u used and with the content of your movie.
But if you are going to DVD for example there you will see clearly the difference.
Also IF we wouldnt allow to less quantize in dark scenes .... the still higher quantize at 2 would cause even lower bitrates!
|
05-22-2004, 11:10 AM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
05-22-2004, 11:17 AM
|
Free Member
|
|
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
But, does somebody test if with "vqmin=3" dissapears buffer underflows?
|
Well, if the warning refers to a too low bitrate, I think Inc already gave an answer.
But as those buffer underflows (who was the one who said it just was a warning when buffer was empty, but didn't mean nothing...) are not giving me a single trouble, and if I raise vqmin I can see blocks ( ), I still keep the advise to, in general, stick at 1.
|
05-24-2004, 06:05 AM
|
Free Member
|
|
Join Date: Aug 2003
Posts: 40
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by digitall.doc
Quote:
Originally Posted by Prodater64
But, does somebody test if with "vqmin=3" dissapears buffer underflows?
|
Well, if the warning refers to a too low bitrate, I think Inc already gave an answer.
But as those buffer underflows (who was the one who said it just was a warning when buffer was empty, but didn't mean nothing...) are not giving me a single trouble, and if I raise vqmin I can see blocks ( ), I still keep the advise to, in general, stick at 1.
|
@digi.doc
sure i was (not the one but one of that ) but ... i never told it meant nothing. it means what it says; no more bit in the buffer so no way of feeding the apparent bitrate need any more. if it gets steady it may distort the bitrate significantly (& also worsen the quality) it would occur not only in the low but also in the high br region.
however, i'm not sure whether menc can distinguish 'under' & 'over'flow. sometimes i feel it does not.
@prodater
imho, vqmin has no direct effect on buffer insufficiency if u keep the same settings in each pass ... & if ratecontrol is good. but it's very frequent in my encodes that it occurs even where it did not happen in the 1st pass so ... ???
it's trivial effect is narrowing the quant distribution producing more even quality. some ppl do prefer it but instead of limiting the quants they rather use quant matrices producing such quant distributions.
all in all, i would not recommend to use qmin=1 unless it's really necessary (say, high bitrate encodings of very compressible stuffs) . it may produce jerks in the quality a/o in the bitrate which may lead to buffer exhaust. the risk of quant noise may also increase. safe usage needs a good & tricky bitrate (quantizer) distribution algo. do we have it ?
the bests
y
|
05-24-2004, 08:51 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Well in case even of vqmin=2 we found out after many tests, that dark areas and underwaterareas etc. (means areas where normally the bitrate drops significantly) ... will end up too much quantized.
As by vqmin=2 at those parts the bitrate drops even more and also by having a vqmin =2 on those parts you see blocks immediately.
I did tests on "Titanic" as it gots a wonderful mix of parts of underwater- / fast moving- and (very important) uneasy watersurface- scenes. Means the whole range of VBR when encoding is given.
Vqmin=1 gave me the best quality as the quantize (not bitrate) value at the needed scenes - like underwater - dropped down(=less blocks) and kept the low bitrate above our wanted limit.
BUT there are still "problems" (well not if I use MY StandAlone Player) in scenes where the screen is "Black", ... like in slow scene changes etc.
But as Kwag did tests on mencoders intern. NoiseGenerator these Problems got less.
Prodater, I took a look at your samples ... yep, almost no difference, but that sample does not contain such a VBR dynamic as If you would do a test on a sliced one like the example I did mention above (Titanic).
So we should look at these "BIAS" Settings of Mencoder as in CCE this affects the bitrate dynamic.
But someone did say in here that this will only have an effect on mencoder mpeg4 encodings !?
|
05-24-2004, 09:44 AM
|
Free Member
|
|
Join Date: Aug 2003
Posts: 40
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@inc
i got your point. of course, if u drop lower quantizer onto a frame u got better looking output (quant ~ drf) but ...
- what about the other frames. in general, decreasing min quant means increasing the max so as to keep the same target rate. i.e. the price of having better frames here is having worse frames there. sure it is. here the average bitrate is a crucial point.
- the other point is that q1 is not restricted to scenes having low luma variation ('dark' scenes as u called it ) any frame may benefit from it. everything depends on the codecs choice.
- imho, imposing fine noise is much more effective against blocking then quant lowering. using a higher bitrate matrix is an other way. sharpening is the third ... so we've got possibilities.
i'm sure u deal with high bitrate encodes (only?) where these probplems are not so serious. just get back & try some mid or low bitrate encodes. u can better see what u gain & what u loose with some tweak. imho, the options can be tested much better in that region, in general.
i hope u don't find me too offensive. it wasn't meant. i highly appreciate your results here around.
the bests
y
|
05-25-2004, 10:30 AM
|
Free Member
|
|
Join Date: Sep 2002
Location: Lahti, Finland
Posts: 1,652
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I think I'm going to keep from using MEncoder till the rate control is rewritten (I've heard that it's in the works).
I just encoded Star Trek 2: The Wrath of Khan with both MEncoder (2-pass, 1360kbps avg bitrate) and CCE (one-pass variable, Q=22) and MEncoder gave me pure crap in some scenes. When I looked at the Bitrate Viewer graph, I noticed that the rate control doesn't always deliver the necessary bits whereas CCE came out much better.
With ordinary scenes MEncoder does a good job but I'm not prepared to start tweaking the settings to get it working with scenes like this. The settings I used were the ones that PackShot uses.
Here's MEncoder:
Here's CCE:
Here are the Bitrate Viewer graphs from the surrounding region:
You can probably guess which one belongs to MEncoder and which one to CCE
Notice that in CCE the max bitrate was 5000kbps and in MEncoder it was 7500kbps.
|
05-25-2004, 11:31 AM
|
Invalid Email / Banned / Spammer
|
|
Join Date: Aug 2002
Location: Brasil - MG - third stone from the sun
Posts: 5,570
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Boulder,
was using CCE250 ?
i ask cos i saw some posts showing opinions that 250 is slow but give better quality then others versions,this is mine too!
great tests!
thanks.
|
05-25-2004, 11:38 AM
|
Free Member
|
|
Join Date: Sep 2002
Location: Lahti, Finland
Posts: 1,652
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I've used the latest version, I never noticed any quality differences between 2.50 and 2.67. Plus it's faster on my P4 system
|
05-25-2004, 12:14 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hi Boulder,
Have you tried any NTSC sources
I think the issue is related to PAL high resolutions (+ 704x576)
I haven't been able to duplicate or see that at 704x480.
-kwag
|
05-25-2004, 12:44 PM
|
Free Member
|
|
Join Date: Sep 2002
Location: Lahti, Finland
Posts: 1,652
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
No, I've not tested any NTSC sources. I could try encoding the same movie to NTSC resolution and see if it breaks up again.
Another thing to test would be to encode a similar 2-pass but use different filenames for both passes. I'm suspecting that the second pass screws up the encode as based on BV it looks as if the rate control spent all the bits just before that spot!
|
05-25-2004, 02:58 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Boulder that strange, in my case it was the opposite!
I did a test on The core (beside many others) and the samples (and the whole movie) got much less blocks on exactly such scenes you showed here
And I do use Packshots settings already for a long time manually when I did used the .bat file way.
Well ... seems that there are many things which do affect mencoders quality
@ yaz
Quote:
i hope u don't find me too offensive. it wasn't meant. i highly appreciate your results here around.
|
No, I defenitely didnt see that as an offense!
Thanks for your words!
|
05-26-2004, 08:00 AM
|
Free Member
|
|
Join Date: Aug 2003
Posts: 40
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@boulder
imho, no freeware can beat multipass cce (at the moment) in the mid-low bitrate region. especially when min/max bitrate restrictions are also important. but at high bitrates mencoder is pretty good.
imho, cce 2.67.xx is much(!) better than any cce 2.5x.
the bests
y
|
All times are GMT -5. The time now is 05:48 PM — vBulletin © Jelsoft Enterprises Ltd
|