Quantcast FFmpeg vs FFvfw vs Mencoder ? - Page 17 - digitalFAQ.com Forums [Archives]
  #321  
03-18-2004, 05:32 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,
I still find your results surprising, compared to my tests results. I'm with you that the better is finding a common way to use mencoder for everybody. But as I'm in PAL land, I cannot help with NTSC films. And if I find a nice way that just helps with PAL films, I won't through it away, but will post it, since it can help other people (as you do). Anyway, I'm not completely sure that the differences in our results are due to being NTSC or PAL, but don't know what the reason is.

I'm also with you with vbitrate=vrc_maxrate (lowering maxrate to 5000), but for long length films this will mean fitting just 1 film per DVD media. If you want to fit at least 2 films, you will have to lower vbitrate (with 1500 it worked for me) and maybe raise quantizers.

BTW: you could ask in mencoder news if it is possible to have working floating values for quantizers, it would be of much help.

I see you get no differences at all between vqcomp=0 or =1 when vbitrate=maxrate. I didn't reproduce that in my tests, I got differences.
And filesize differences between vbitrate=min or max are very little, taht again wasn't my case. You even get very little differences in avg and peak bitrate, but just in quantizers...

I'll keep making tests. But we could advise to employ notch-matrix, vqblur=0, naq (and scplx_mask), and vbitrate close or equal to vrc_maxrate. And for quality, use trellis+cbp+mv0. Quantizers min at 2 and max maybe at 10 (but if filesize too big it may be necessary to lower vbitrate and raise min quantizer). About vqcomp... I just would advise to test both and see results, by now. Let's see if we can come to a conclusion .

... and related to b-frames, I don't see much "enworsement", and it also helps to decrease filesize (and quality may be tweaked).
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
  #322  
03-18-2004, 06:18 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
I'm also with you with vbitrate=vrc_maxrate (lowering maxrate to 5000), but for long length films this will mean fitting just 1 film per DVD media. If you want to fit at least 2 films, you will have to lower vbitrate (with 1500 it worked for me) and maybe raise quantizers.
Nothing beats 2-pass encoding in this area
Quote:
... and related to b-frames, I don't see much "enworsement", and it also helps to decrease filesize (and quality may be tweaked).
I'll try now with progressive streams, maybe B-frames are buggy with interlaced streams only. So I'll avoid them anyway, but PAL-only encoder won't need to

Now testing vbitrate=vrc_maxrate without naq...
EDIT: Quantizers decrease even with vbitrate=9800. It never lost much quality in real life movies, will now test on anime ...
EDIT2: Tested. Still no good.

Bilu
Reply With Quote
  #323  
03-18-2004, 07:58 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Confirmed: B-frames work fine with progressive streams but not with NTSC. I'll try to find info on this subject. Removed every interlace-related setting before encode and it worked.

Will now repeat the vqcomp/vbitrate tests.

EDIT: Same conclusion, better to use vbitrate=vrc_maxrate. vqcomp=0 or vqcomp=1 is irrelevant.

EDIT2: A progressive stream done with interlaced parameters can do B-frames. An interlaced stream gets screwed up

@digitall.doc
Please read this whole thread:
http://www1.mplayerhq.hu/pipermail/m...er/040946.html


Bilu
Reply With Quote
  #324  
03-18-2004, 09:17 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
BATCH
====
PAL: mencoder -include settings.ini -lavcopts keyint=15 movie.vob -o movie.m2v
NTSC: mencoder -include settings.ini -vf-pre softpulldown -lavcopts keyint=18 movie.vob -o movie.m2v

SETTINGS.INI
========
of=rawvideo=1
ovc=lavc=1
nosound=1
noskip=1
lavcopts=vcodec=mpeg2video:vrc_buf_size=1835:
vqblur=0reme=2recmp=2:vqcomp=1:vrc_minrate=300 :
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:

vbitrate=9800:vrc_maxrate=9800:
ildct=1:ilme=1:vstrict=-1:ildctcmp=2:
autoaspect=1:
scplx_mask=0.3:naq=1:
vmax_b_frames=2:
trell=1:cbp=1:mbd=2:mv0=1

vf=il=d,hqdn3d,il=i,yuvcsp
Bold: Denoiser.May help with compressibility. il=d,il=i are for interlaced filtering.
Blue: needed for interlaced and NTSC encodes.
Violet: settings that improve quality at CPU cost.
Orange: May also help with compressibility. (raises quantizers)
Red: Only when using VOB sources directly.
Brown: Only with non-interlaced and non-telecined sources.
Green: Bitrate settings - using vbitrate=vrc_maxrate is recommended.

I said in the "brown" item that it was for non-interlaced and non-telecined sourced. I didn't said progressive because some guys call progressive to telecined sources (like Mencoder says :"24fps progressive detected, changing framerate...").


Bilu
Reply With Quote
  #325  
03-19-2004, 02:46 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
I've abandoned scplx_mask=0.3:naq and quality improved a lot. Despite using naq, the spatial mask was raising quantizers even when I specified vbitrate=9800

Not anymore....

Bilu
Reply With Quote
  #326  
03-19-2004, 01:20 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
@bilu,
I still have lots of tests to do (very busy at the moment, don´t have spare time). I even didn't read that thread you pointed me to (just read first post, and lost myself a little, but I want to read it thoroughly).

Quote:
Originally Posted by bilu
Nothing beats 2-pass encoding in this area
Well bilu, I think KVCD "philosophy" (and maybe I'm not the right person to talk about this forum philosophy, since I'm very new to this. And of course, you may already know the following) is not that. I think we try here to get the best results with 1pass encoding, and with constant quality. And with some other "flavours" (like notch-matrix, GOP, avisynth MA script,...) is what make the "miracle" . I don't remember many people here doing 2pass. And don't think that doesn't mean it hasn't to be done, since here people are very open-minded and accept suggestions out of the "official" (if any) line, but we're, in general, very happy with 1pass results.

Quote:
Originally Posted by bilu
I've abandoned scplx_mask=0.3:naq and quality improved a lot. Despite using naq, the spatial mask was raising quantizers even when I specified vbitrate=9800
Yes, I remember I tried this once. And maybe it works with high bitrates and low quantizers,... but this also means biiiig file sizes, isn't it?. And the advantage of making KDVD (apart from quality) is manage to fit 2, or even 3 films per DVD+-R media. And I'm afraid that without naq, if you have to lower bitrate to fit films, image will get worse (at least is what happened to me). For high bitrate encoding (that is, vbitrate=vrc_maxrate=9800), maybe is not necessary... but maybe also is not necessary notch-matrix, or filtering the film, since you will just be able to fit one film per media, and you'll have lots of bits to spare in standard matrix.

But, of course, this is just my opinion, and I'm not a very knowledge person

And, as everything that is suggested here and sounds intelligent to me, I'll also test it to see if it really raises filesize so much.

As some posts before, I'll say again that I feel sad that we're the only ones posting here our results with this encoder and our settings. It would be nice if other people posted here their results with these (vqcomp=0 or =1) settings to see if we can get at a point, and find a better way to employ this tool... since it looks thst it worth th effort.

Cheers.
Reply With Quote
  #327  
03-19-2004, 01:51 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
Nothing beats 2-pass encoding in this area
Time always beats 2-pass

-kwag
Reply With Quote
  #328  
03-19-2004, 08:32 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
New tests, 1-pass encoding without B-frames:

- p_mask=1 increases quality;
- naq isn't worth it (better not to use scplx_mask at all);
- vrc_maxrate does the 1-pass bitrate control, vbitrate isn't worth it;
- using scplx_mask without naq can be used as an alternative to B-frames in interlaced encodings. And it's very good at lowering bitrates since it distributes the "damage", probably the best alternative in 1-pass encodings.But be careful with anime, edges are very sensitive to quantizing;

Couln't test vqblur=1 because I was working a very small sample.
But I don't think that is what we're looking for


Bilu
Reply With Quote
  #329  
03-20-2004, 03:33 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
Quote:
Originally Posted by kwag
Quote:
Originally Posted by bilu
Nothing beats 2-pass encoding in this area
Time always beats 2-pass

-kwag
Yes kwag, you're right. I just said that we try here to encode 1pass, and take out the best of 1pass encoding, but didn't explain why. Of course, the reason is 2pass doubles encoding time.
Reply With Quote
  #330  
03-20-2004, 03:47 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
Quote:
Originally Posted by bilu
New tests, 1-pass encoding without B-frames:

- p_mask=1 increases quality;
- naq isn't worth it (better not to use scplx_mask at all);
- vrc_maxrate does the 1-pass bitrate control, vbitrate isn't worth it;

.....

Couln't test vqblur=1 because I was working a very small sample.
But I don't think that is what we're looking for
bilu, what are sample length (in time) and what the file sizes you get?. I explained in my previous post that I wouldn't drop naq, since it helps when you have to lower vbitrate to shrink file size. If not, there begin to appear blocks all over

When you state that vrc_maxrate does the 1pass bitrate control, and vbotrate doesn't worth it, what do you mean?. Does it mean that you don't give vbitrate a value since bitrate is adjusted through maxrate (so, you leave it default=800)?. I ask because I noticed that when I lower vbitrate for filesize reasons, avg bitrate lowers...

Do you know how p_mask works?. I wanted to test it, but I don't know really how it works (and I think, as a *_mask it is, it will benefit from naq )

BTW, I read the thread you pointed me at. If I understood well, it was on b_frames. And sorry me if I didn't get it, but I took no conclusion. In a post was stated that knowledge "people" dropped b-frames (but no explanation why, and I even believe that they were mainly refering to mpeg4). In other post they argumented that b-frames gave little advantage in file size,... I have different experience, filesize decreased without noticeable loss of quality. And you always can adjust b-frames quality through qfactor,... Well, no conclusion for me.

Please, take a look at filesizes and stimated file size for the whole movie, and make me know. In my first tests I was also surprised by the quality I got, but then I realised I had to lose quality if I wanted to compare mencoder to other encoder in my real life KDVD encodings (at least, 2 films per media). For 1 film we have lots of tools out their (of course, without KDVD quality )
Reply With Quote
  #331  
03-20-2004, 06:14 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 digitall.doc
Of course, the reason is 2pass doubles encoding time.
If I remember correctly, the original reason was that Tmpgenc does a much better job in CQ mode than in 2-pass VBR. But later when I created CCE templates, I found the quality to be pretty much the same (1pass vs 2 pass), but 2-pass was of course much slower.
Reply With Quote
  #332  
03-20-2004, 08:06 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 digitall.doc
I explained in my previous post that I wouldn't drop naq, since it helps when you have to lower vbitrate to shrink file size. If not, there begin to appear blocks all over
If you don't want blocks, don't use scplx_mask at all.
I compared scplx_mask+naq against no scplx_mask at all and strangely the bitrates through the encoded sample are about the same but quantizers were bigger. No matter if I tried scplx_mask=0.1, 0.2 or 0.3, quantizers allways got bigger than using no scplx_mask but the bitrates were almost unchanged. Tried with vbitrate=300,1000 and 9800 and it never helped keeping the bitrate.
But using no scplx_mask looked better of course. Try it yourself comparing small samples through Bitrate Viewer.

But one of the most effective ways to lower the bitrate by distributing the quantizer increasing is scplx_mask *WITHOUT* naq.
Not a specific value, but it would be nice if we could somewhat do a compressibility test and increase scplx_mask as needed: scplx_mask=0.2, 0.3 ....
B-frames are a better method of course, if you're doing progressive encodes.
Quote:
Originally Posted by digitall.doc
When you state that vrc_maxrate does the 1pass bitrate control, and vbotrate doesn't worth it, what do you mean?. Does it mean that you don't give vbitrate a value since bitrate is adjusted through maxrate (so, you leave it default=800)?. I ask because I noticed that when I lower vbitrate for filesize reasons, avg bitrate lowers...
On all my tests so far (longest samples are 5 minutes long) it didn't made that much of a difference if I used vbitrate=300,1000 or 9800 - results were almost the same.
But vbitrate=vrc_maxrate looks a tiny bit better.
Quote:
Originally Posted by digitall.doc
Do you know how p_mask works?. I wanted to test it, but I don't know really how it works (and I think, as a *_mask it is, it will benefit from naq )
It won't benefit from naq IMHO because it's already seems to be kind of a temporal naq
Quote:
Originally Posted by digitall.doc
BTW, I read the thread you pointed me at. If I understood well, it was on b_frames. And sorry me if I didn't get it, but I took no conclusion. In a post was stated that knowledge "people" dropped b-frames (but no explanation why, and I even believe that they were mainly refering to mpeg4). In other post they argumented that b-frames gave little advantage in file size,... I have different experience, filesize decreased without noticeable loss of quality. And you always can adjust b-frames quality through qfactor,... Well, no conclusion for me.
Well, you're right: no conclusion for you
It's about MPEG-2, interlaced support and B-frames. It explains why it doesn't work well with interlaced encodings:
Quote:
Unless I'm very much mistaken ffmpeg encodes MPEG-2 with interlaced support
and B frames off. These are on by default in mpeg2enc. If you turn them off
mpeg2enc runs a little over twice as fast (17 fps vs. 9 fps on my Athlon/XP
2100+). These features are expensive to code properly... B frames require
big motion estimate search radii and are unfriendly to predictive motion
estimators and interlaced coding requires you to motion estimate a frame once
as a frame and then a second time as two fields.


The upcomng release of mpeg2enc has the defaults set to ffmpeg like
behaviour...
Quote:
Originally Posted by digitall.doc
Please, take a look at filesizes and stimated file size for the whole movie, and make me know. In my first tests I was also surprised by the quality I got, but then I realised I had to lose quality if I wanted to compare mencoder to other encoder in my real life KDVD encodings (at least, 2 films per media). For 1 film we have lots of tools out their (of course, without KDVD quality )
I'm getting to these conclusions:

Low-motion movies: Reduce vrc_maxrate.
High-motion movies: Use scplx_mask without naq. Don't reduce vrc_maxrate.
Anime: Just use a denoiser. Don't even try quantizing limits.

On low-motion most stuff won't get restricted so you can specify a max rate that you can trust (unlike vbitrate).

On high-motion it's important not to limit the max rate: explosions, blasts, pursuits, whatever, consume a lot of bitrate. So the bitrate decreasing must be distribuited though the whole stream. Besides B-frames, this is the best alternative left. Using naq here would cut the downsizing effect and you'd have to force a lower maxrate again.

Anime: every quantizer looks bad on edges
Denoiser is the best choice to decrease bitrate, but still no garantees.

PS: I didn't kept the files for measuring bitrates and filesizes, but I remember my conclusions and BV comparisons well. I can repeat the tests if it's that important, but I already know the conclusions I'll get

Bilu
Reply With Quote
  #333  
03-20-2004, 08:16 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
@digitall.doc

I'd like you to do a comparison between scplx_mask=0.3:naq and no scplx_mask or naq at all, in Bitrate Viewer.

You'll notice that quantizers are much higher using scplx_mask=0.3:naq but the bitrates will be almost untouched.

I know, it sounds strange
But check it yourself to see what I mean


EDIT: Maybe the problem is that I'm asking too much from the rate control with such small samples, I shouldn't try with less than 30 minutes.
But I have a PIII-500 laptop that I need for other stuff, so don't blame me
If that wasn't the problem maybe I'd be doing two pass instead of one

Bilu
Reply With Quote
  #334  
03-21-2004, 11:30 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
Quote:
Originally Posted by bilu
Quote:
Originally Posted by digitall.doc
BTW, I read the thread you pointed me at. If I understood well, it was on b_frames. And sorry me if I didn't get it, but I took no conclusion. In a post was stated that knowledge "people" dropped b-frames (but no explanation why, and I even believe that they were mainly refering to mpeg4). In other post they argumented that b-frames gave little advantage in file size,... I have different experience, filesize decreased without noticeable loss of quality. And you always can adjust b-frames quality through qfactor,... Well, no conclusion for me.
Well, you're right: no conclusion for you
...
Quote:
Unless I'm very much mistaken ffmpeg encodes MPEG-2 with interlaced support
and B frames off. These are on by default in mpeg2enc. If you turn them off
mpeg2enc runs a little over twice as fast (17 fps vs. 9 fps on my Athlon/XP
2100+). These features are expensive to code properly... B frames require
big motion estimate search radii and are unfriendly to predictive motion
estimators and interlaced coding requires you to motion estimate a frame once
as a frame and then a second time as two fields
.


The upcomng release of mpeg2enc has the defaults set to ffmpeg like
behaviour...
They talk about b-frames in interlaced coding. And I live in a PAL country, no interlaced sources at all (maybe yes when I begin to encode my TV captures, but NOT now).
So, again, no conclusion for me. I keep with b-frames, and advise them for progressive source encoding.
Reply With Quote
  #335  
03-21-2004, 12:04 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
On all my tests so far (longest samples are 5 minutes long) it didn't made that much of a difference if I used vbitrate=300,1000 or 9800 - results were almost the same.
Well, I did get differences in smaller samples, related to filesize and visual quality, of course being better with vbitrate=vrc_maxrate.

Quote:
Originally Posted by bilu
Quote:
Originally Posted by digitall.doc
Do you know how p_mask works?. I wanted to test it, but I don't know really how it works (and I think, as a *_mask it is, it will benefit from naq )
It won't benefit from naq IMHO because it's already seems to be kind of a temporal naq
So, do you already know what p_mask is supposed to do?. I still don't, even didn't test it at all. If I thought that naq could help, it was because it was stated in man_page (naq helps when using *_mask).

Quote:
Originally Posted by bilu
But one of the most effective ways to lower the bitrate by distributing the quantizer increasing is scplx_mask *WITHOUT* naq.
Not a specific value, but it would be nice if we could somewhat do a compressibility test and increase scplx_mask as needed: scplx_mask=0.2, 0.3 ....
Quote:
Originally Posted by bilu
I'd like you to do a comparison between scplx_mask=0.3:naq and no scplx_mask or naq at all, in Bitrate Viewer.
You'll notice that quantizers are much higher using scplx_mask=0.3:naq but the bitrates will be almost untouched.
bilu, I followed your last thoughts,... and got surprising results indeed .
Even if don't completely agree with you , always test (most of) your suggestions. My main objections to your suggestions were related to good quality but with very big filesizes (you erased your tests but I kept them, and they were too big). But here are my lasts results:
- with naq and scplx=0.5 33683 kB BR 4924-1634 Q 7.07-3.63
- without naq and without scplx 35917 kB BR 4764-1742 Q 7.64-3.46 (well different bitrates, and higher max quantizer with lower avg... not what we expected at all )
- no naq scplx=0.5 18858 kB BR 3784-915 Q 9.00-7.37 --> hey, hey wait a minute, quantizers raised a lot, and bitrate lowered a lot as file size, may it be a way? (you already suggested). Maybe 0.5 too high... and was done with maxrate=5000 and avg=1500. Let's change them:
- no naq scplx=0.2 vbitrate=maxrate=9800 33364 kB BR 5599-1619 Q 4.29-3.45
BINGO!!! file size similar to the first ("gold standard") test, better quantizers,... good.

Did several tests else, with this approach: vbitrate=vrc_maxrate=9800 (even =5000 with similar quality results, and little decrease in filesize), vrc_eq=tex (keep on ), naq=0 (you were right), and variable scplx_mask values... I have realised that scplx_mask accepts more figures (I even tested =0.255, and gave different results than =0.256), what helps us to adjust final filesize... very good.

Vissually it seems to me that image gets a little blurred (what does scplx_mask do?, does it filter/blur the image or just acts on quantizers?. Do you know the answer?), but very little, and NO blocks at all. Nice.

And with this high bitrates, quantizers keep low (but surprisingly didn't see them go under 3, even I set vqmin=2), independently what vrc:eq setting you use... but I prefer to keep at =tex, because it may be needed in other films-settings, and in my previous tests it helped more.

To sum up (too long post): better approach to use scplx_mask=0.15-0.35 (even 3 decimals) without naq. The rest, as we were using (I see you already opened a thread with this new settings, I post there some suggestions).

Keep on testing here
Reply With Quote
  #336  
03-21-2004, 04:51 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
IMHO p_mask=1 averages between inter-MB quantizers, but I don't know if it does it spatially or temporally. Quality does improve a bit, bitrate rises a bit, may be a good thing to use with scplx_mask.

Best values for scplx_mask are between 0.2 and 0.3, I think.
0.3 is my favorite I've tried 0.5 but it was too much.

A little blurred is not that bad considering that you'll watch them on a TV output It will allways be better than VCD and at least as good as a sharp SVCD, the quality is prettty good.

The *_mask settings just act on quantizers.

I'd suggest 0.2 for better quality and 0.3 for better bitrates.
But for anime we should only use denoisers, even scplx_mask=0.1 is bad

And as you've seen from my previous tests using scplx_mask=0.3 without naq together with hqdn3d the bitrates got allways under 3000 Kbps.
Maybe without the denoiser results are still that nice, and would be faster.
And my tests were without B-frames.

Bilu
Reply With Quote
  #337  
03-21-2004, 05:29 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
IMHO p_mask=1 averages between inter-MB quantizers, but I don't know if it does it spatially or temporally. Quality does improve a bit, bitrate rises a bit, may be a good thing to use with scplx_mask.
It sounds like naq function...

Quote:
Originally Posted by bilu
Best values for scplx_mask are between 0.2 and 0.3, I think.
0.3 is my favorite I've tried 0.5 but it was too much.
Remember that you can use 0.22 and even 0.222 (maybe, this way, it can fit more to your taste)

Quote:
Originally Posted by bilu
A little blurred is not that bad considering that you'll watch them on a TV output It will allways be better than VCD and at least as good as a sharp SVCD, the quality is prettty good.

The *_mask settings just act on quantizers.
So, if it just acts on quantizers, it shouldn't blur the image, isn't it?.
And... no, even to be seen on a TV set, I prefer not to have a blurred KDVD. Other thing is KVCD, that needs some blurring to make file smaller. But for KDVD I want the best image possible, since I don't know if the day after tomorrow I'll have a 60 inch TV set, and suffer of little image definition (that's why I encode in 16/9 aspect, the keep the best quality possible).

BTW: I did some encodings without mbd=2, without trellis and without predia and dia=-2, and speed changed from 4-5 to 5-6. Not a big difference. What would really make a difference is that mencoder accepted avs files (or better, mencoder included avisynth built-in, and encode directly from vobs, with internal avisynth filtering... a dream?).
Reply With Quote
  #338  
03-21-2004, 05:53 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
Quote:
Originally Posted by digitall.doc
What would really make a difference is that mencoder accepted avs files (or better, mencoder included avisynth built-in, and encode directly from vobs, with internal avisynth filtering... a dream?).
I'm with you digitall.doc.
I also encode in 16/9 AR and I dream on buying a TV projector or a big TV set.
I'm pretty sure I'll have to live with a flat square 100Hz 32" TV set and a bit of blurring won't
be so noticable.
But when I joined the community I always aimed for best quality / fastest encoding.
That's what makeAVIS/mencoder seem to deliver.
But I also live in doubt: what if mencoder could internally read avs scripts?
Maybe it would be a bit faster than it already is.
Other doubt: most of the arguments that both you and bilu are trying right now. Do they blur?
If so there's no point in using them and avsynth filtering at the same time, right?
If mencoder could read avs internally I think I would only ask for one thing more.
And that is avisynth 4 linux. I've been working all day on a Linux box that has mplayer/mencoder.
But it lacks Avisynth scripting!!!
Hey, sh0dan Can you hear me Guys from Linux can use avs scripts...
Think he heard me
Think he can do anything about it
Hope he can surprise me one of these days
__________________
Rui
Reply With Quote
  #339  
03-21-2004, 06:37 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
@rds_correia,
did you try mplayer/mencoder linux versions?, what about speed?.
Yes, it would be nice to have avisynth built-in mencoder, or at least mencoder compatible with avs script.

@all,
I could encode directly from vobs with vmesquita compilation, but couldn't with bilu compilation, and I know bilu is using his own compilation to encode from vobs. Have anybody met the same problems I did?. How can I solve them?
Reply With Quote
  #340  
03-21-2004, 06:47 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Bigger quantizers lose detail hence they blur the image.
In terms of detail a resize to a lower resolution can also be considered a sort of blur. And when you aim at lower bitrates you end up attacking higher frequencies by denoising or increasing quantizers, hence you blur.

If you don't want any blur, don't expect lower bitrates
IMHO the most important is HOW you blur.

I think hqdn3d is good enough to allow me to abandon Avisynth

Avisynth is at the moment too dependent on Windows-specific assembly code, although the VFW part could be replace by the Linux AVIFile library.
This was my opinion the last time I checked, there are some threads on this subject in Doom9.

EDIT: The IVTC techniques from Avisynth are far superior to those from Mencoder. If you ever want to do NTSC to PAL conversions then you'll need Avisynth for sure. The only settings I'm using that lower bitrate are hqdn3d and scplx_mask=0.3, remove them for the best possible quality.

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

Thread Tools



 
All times are GMT -5. The time now is 09:41 PM  —  vBulletin © Jelsoft Enterprises Ltd