Quantcast FFmpeg vs FFvfw vs Mencoder ? - Page 6 - digitalFAQ.com Forums [Archives]
  #101  
02-24-2004, 12:41 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 bilu
@rds_correia

I'd like to know specifically what you're not understanding.
If you understand you can help me explain to others

Please post your questions, I'm sure someone else will have the same doubts.
Ok buddy,
Maybe I'll start by posting my current command line and avs script:
The Avs script:
Code:
Mpeg2Source("c:\xxxxx.d2v")
undot()
Limiter()
asharp(1, 4)
BicubicResize(688,400,0,0.6,4,12,712,552)
STMedianFilter(3, 3, 1, 1 )
MergeChroma(blur(1.5))
MA_Soft() #light MA function made by Inc., faster BTW.
AddBorders(8,80,8,96)
Limiter()
#Slicer(2,15,30,2,0) #sampler function made by Inc. for Ping-Pong prediction. Pretty cool BTW.
And the mencoder command line:
Code:
mencoder -of mpeg  -ovc lavc -lavcopts vcodec=mpeg2video:
intra_matrix:inter_matrix: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_qoffset=0.75:vqblur=0.3:vlelim=-4:vcelim=2:vfdct=6:
aspect=4/3 -nosound c:\zzzzz.avi -o c:\wwwww.mpg
Notice that I don't post the intra/inter matrices. I'm using Notch matrix.
The way I see it the tricky part is:
Code:
: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_qoffset=0.75:vqblur=0.3:vlelim=-4:vcelim=2:vfdct=6:
So I have vrc_minrate=300 & vrc_maxrate=8000 & vbitrate=3000.
From what I understood so far these are for min & MAX & average bitrate.
I have been using these since the days I saw russiansexpat using mencoder in Linux.
Then there are keyint=15 for max GOP size and vrc_buf_size=1835 for vbv buffer size, right?
Then I have vqmin=2 and vqmax=24 for quantizer settings. I understand how these work,
but since we're already using min, MAX & avg bitrate do we need these?
Last one that I know is vmax_b_frames=2 for 2 b frames like IBBPBBPBBP.
All the others I don't understand how they work (lack of good manual/linux manpages always disapointed me a bit)
and don't know what they are doing there.
More what would you change in my command line to seek for 2 movie KDVD.
Last but not least where do I get more or less quality?
This baby is way different in settings when comparing with CCE/tmpg...
Quote:
Originally Posted by bilu
About FFVFW, maybe some of the misconceptions made before with mencoder (like the abusive use of vqscale which doesn't respect bitrates) are the same being done in FFVFW.
Could someone post what's being used in FFVFW now?
Bilu
I can't because I haven't been using ffvfw for a while.
Only use the makeAVIS that comes with it to make a fake avi for mencoder.
Hope you can give me some help with the above issue.
Cheers
__________________
Rui
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
  #102  
02-24-2004, 02:12 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
Hay guys,

I've got an ... can we all agree upon a "standard" in the command
line params "layout".

So that when we are working out issues w/ a given param string(s) we can
knew exactly where to look for it, when we're all dealing with params.

Here's an example.

Lets all keep things w/in a "group", and those that think a given param or
set of params belong in a "group", lets all agree to keep them together,
especially if they work w/ relation to other params, or "group"'s of params.
.
.
Then, we can include the new agree upon "standard" inside a Sticky post

But, if you all think it's not necessary, then by all means, just ignore my
idea and

In the mean time, I'll start the first part, and you can include/add in yours.
Later, I'll add this feature inside my GUI as a guage Then, in my GUI,
I'll "sectionalize" the items, for easy minipulations w/in the GUI
(which I hope to share with you all here and elsewheres soon)

Quote:
Bitrate:
mbd=0:vrc_minrate=1200:vrc_maxrate=8000:vbitrate=2 800:vrc_buf_size=1835:keyint=18
Noise:
Filters:
** etc etc

keyint is set to 18, because, if I understood, this is for GOP. But, I thought
it was for KEYFRAMES, as in divX and AVI's

Also, if we can agree upon exacly, which param string does "exactly" what,
we can add that into our Sticky. A glossary. I know there is an .HTML doc,
but it's confusing, and it has left all of us to discover what all these cryptic
param string/options/subgroups are for ourselves. And, being that we are
all working together (I use that loosely) we may as well work as a consortium
and in the process, create a "standard" glossary of commands/params or
whatever you want to call it

Think about it
-vhelp
Reply With Quote
  #103  
02-24-2004, 06:52 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
@bilu,
hmmm, if I encode a film without b-frames, won't the file grow really a lot?. And, is it DVD compliant?. I mean, GOP for DVD must be 15, isn't it?. And GOP structure for DVD compliancy must be
IBBPBBPBBPBBPBBI... isn't it?
I'm not just looking for a solution for my scene, but learning the way to do our encodings, to get the better quality possible, but always compliant with DVD standard.
It will grow a lot, but I don't believe that abandoning B-frames would break up compatibility with standards. I'll have to check.
But a parameter like this has a reason to exist, right:
Quote:
vb_strategy=<0-1>
strategy to choose between I/P/B frames (pass 2):
0 always use the maximum number of B frames (default)
1 avoid B frames in high motion scenes (will cause bitrate misprediction
For 1-pass encodes, and if you still want to use B-frames to be sure of compatibility, you can use b_qfactor=1.0 and vb_qoffset=0. This would make it use B-frames but use the same quantizer as P-frames. Filesize will grow but you will be able to see if it was a overquantized B-frames problem on that high-action scene.

A middle-term between filesize and quality once you discover that this was the problem will be using b_qfactor=1.0 and playing with vb_qoffset between 0 and 1.25 (default value). This will assure a fixed quantizer increase over P-frames, not a multiplied one like when using b-qfactor > 1.
Remember that Bquant=Pquant * b_qfactor +vb_qoffset.


Bilu
Reply With Quote
  #104  
02-24-2004, 06:57 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
A middle-term between filesize and quality once you discover that this was the problem will be using b_qfactor=1.0 and playing with vb_qoffset between 0 and 1.25 (default value). This will assure a fixed quantizer increase over P-frames, not a multiplied one like when using b-qfactor > 1.
Remember that Bquant=Pquant * b_qfactor +vb_qoffset.
Understood now (I think)
Nice explanation.
Now at work. I'll try tomorrow.
Lots of tests to do tomorrow. Maybe my wife will leave me....
Reply With Quote
  #105  
02-24-2004, 07:02 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 kwag
Removing B frames will make worse quality, no matter what encoder
That is, if bitrate is kept at the same reference.
Removing P frames is even worse quality.
If you remove B frames, you have to compensate with a higher bitrate, and then quality is better.
Removing B and P frames is the BEST quality, but only at very high bitrates ( ~50,000Kbps or more ).
MPEG-2 is used that way in broadcast studios.
I agree with you. B-frames compress about 4x better (at least in MPEG-4) than P-frames, which means much more bitrate freed for use in P and I frames.

But they make you loose quality in high action (explosions,etc.) and anime movies and they're not recommended in this case. But as I mentioned on my previous post, playing a bit more with vb_qoffset and less with b_qfactor can improve a lot on this field.
Quote:
Default
=====
Pquant= 4 -> Bquant= 4*1.25 +1.25 = 6.25
Pquant=20 -> Bquant= 20*1.25 +1.25 = 25 + 1.25 = 26.25

difference between P and B quants:

P=4 -> 2.25
P=20 -> 6.25

B_qfactor=1
========
Pquant= 4 -> Bquant= 4*1 +1.25 = 5.25
Pquant=20 -> Bquant= 20*1 +1.25 = 21.25

difference between P and B quants:

P=4 -> 1.25
P=20 -> 1.25
Until digitall.doc shows what quantizers does Bitrate Viewer shows for that scene, this approach may be helpful.


Bilu
Reply With Quote
  #106  
02-24-2004, 07:16 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 incredible
I underline that as P Frames ONLY work predictious means they refer to the Frames BEFORE where B Frames also do refer to FOLLOWING frames.

If you would only use P Frames you could receive a stream where an visible sudden quality "refresh" occurs when the playback reads an I Frame.
Cause in the Frame run within the I Frame Interval the Frames would get only worse and worse
I don't quite agree and I'll explain why.
Every guy doing MPEG-4 anime encodes right now disables B-frames completely because it damages the edges. So the fact that B-frames get info from the next frame may not necessarily garantee better frame quality. Usually it does get better quality, but high action and anime are exceptions.

But as said before, B-frames are better compressed precisely because they have information of both the previous and the next frames, so probably a lot of info becomes redundant and hence discarded. But when forcing a B-frame to be more compressed than a P-frame and you're doing high action or anime you probably won't get pleased with the results.

IMHO B-frame compression factor (relative to P or I frames) should be dynamic, changing as much as the previous and next frames differ.
High-action B-frames compression factor should be lower than doing low-action. Slower movements keep much more info from one frame to another and are so much easier to compress.

Maybe no one did this until now because on high-action P and I frames also get much lower quantizers, so the factor's influence will be less.
Nevertheless on those scenes it may be too much


Bilu
Reply With Quote
  #107  
02-24-2004, 08:04 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
: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_qoffset=0.75:vqblur=0.3:vlelim=-4:vcelim=2:vfdct=6
Use mbd=2 instead of mbd=0. Use vqblur=0 instead of vqblur=0.3 or else it may hurt on sudden high-action scenes.
Quote:
Then I have vqmin=2 and vqmax=24 for quantizer settings. I understand how these work,
but since we're already using min, MAX & avg bitrate do we need these
vqmin=2 is default, vqmax=24 is optional. So no need for them
Quote:
Last one that I know is vmax_b_frames=2 for 2 b frames like IBBPBBPBBP. All the others I don't understand how they work (lack of good manual/linux manpages always disapointed me a bit) and don't know what they are doing there.
About

vb_qfactor=1.2
vi_qfactor=0.8
vb_qoffset=0.75

Formulas explained above. Something like this:

Iquant= Pquant * Ifactor + Ioffset
Bquant= Pquant * Bfactor + Boffset

both factors and offsets are related to P-frames quantizers.

In this case B quantizer = P quantizer * 1.2 + 0.75

vqblur=0.3 averages a frame quantizer with previous quantizers, bad for sudden high-action.
It would make terror movies even more terrifying

vlelim=-4
vcelim=2
vfdct=6

Quote:
vlelim=<-1000-1000>
single coefficient elimination threshold for luminance. Negative values will also consider the dc coefficient (should be at least -4 or lower for encoding at quant=1):
0 disabled (default)
-4 (JVT recommendation)

vcelim=<-1000-1000>
single coefficient elimination threshold for chrominance. Negative values will also consider the dc coefficient (should be at least -4 or lower for encoding at quant=1):
0 disabled (default)
7 (JVT recommendation)

Mencoder's vfdct=<0-10>
dct algorithm:
0 automatically select a good one (default)
1 fast integer
2 accurate integer
3 mmx
4 mlib

FFMPEG's `-dct_algo algo'
set dct algorithm to algo. Available values are:
`0' FF_DCT_AUTO (default)
`1' FF_DCT_FASTINT
`2' FF_DCT_INT
`3' FF_DCT_MMX
`4' FF_DCT_MLIB
`5' FF_DCT_ALTIVEC
vcelim and vlelim: http://www.mplayerhq.hu/DOCS/tech/encoding-tips.txt
Quote:
TIPS FOR ENCODING

That being said, with video you have some tradeoffs you can make. Most
people seem to encode with really basic options, but if you play with
single coefficient elimination and luma masking settings, you can save lots
of bits, resulting in lower quantizers, which means less blockiness and
less ugly noise (ringing) around sharp borders. The tradeoff, however, is
that you'll get some "muddiness" in some parts of the image. Play around
with the settings and see for yourself. The options I typically use for
(non-animated) movies are:

vlelim=-4
vcelim=9
lumi_mask=0.05
dark_mask=0.01

If things look too muddy, making the numbers closer to 0. For anime and
other animation, the above recommendations may not be so good.

============
ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART I: LUMA & CHROMA


The l/c in vlelim and vcelim stands for luma (brightness plane) and chroma
(color planes). These are encoded separately in all mpeg-like algorithms.
Anyway, the idea behind these options is (at least from what I understand)
to use some good heuristics to determine when the change in a block is less
than the threshold you specify, and in such a case, to just encode the
block as "no change". This saves bits and perhaps speeds up encoding. Using
a negative value for either one means the same thing as the corresponding
positive value, but the DC coefficient is also considered. Unfortunately
I'm not familiar enough with the mpeg terminology to know what this means
(my first guess would be that it's the constant term from the DCT), but it
probably makes the encoder less likely to apply single coefficient
elimination in cases where it would look bad. It's presumably recommended
to use negative values for luma (which is more noticable) and positive for
chroma.

The other options -- lumi_mask and dark_mask -- control how the quantizer
is adjusted for really dark or bright regions of the picture. You're
probably already at least a bit familiar with the concept of quantizers
(qscale, lower = more precision, higher quality, but more bits needed to
encode). What not everyone seems to know is that the quantizer you see
(e.g. in the 2pass logs) is just an average for the whole frame, and lower
or higher quantizers may in fact be used in parts of the picture with more
or less detail. Increasing the values of lumi_mask and dark_mask will cause
lavc to aggressively increase the quantizer in very dark or very bright
regions of the picture (which are presumably not as noticable to the human
eye) in order to save bits for use elsewhere.
So vcelim and vlelim are thresholds to be used to consider a macroblock on one frame different from the macroblock from the frame before. This saves on motion vectors, increases image stability and saves bitrate. IMHO we should follow the JVT recommendations here.

About vfdct, as you can see from both Mencoder's and FFMPEG's documentation the value 6 is not existant or at least not documented. Better should auto (default).
Quote:
More what would you change in my command line to seek for 2 movie KDVD. Last but not least where do I get more or less quality
Unless you're aiming at high-bitrate encode which doesn't seem to be the case you're much better with a two-pass process, no doubt about it. Or else low-action will get low quantizers and high-action will be screwed up by high quantizers trying to fit in the average bitrate.
The only way to get a fair bitrate distribuition is called 2-pass. High bitrates work for 1-pass because every frames gets as good as the max quantizer lets.

About parameters, look at my posts above for digitall.doc . Trell, mbd=2,cbp and mv0. At least these got my attention, there may be others around.


Bilu
Reply With Quote
  #108  
02-24-2004, 08: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
Quote:
Originally Posted by bilu
Maybe no one did this until now because on high-action P and I frames also get much lower quantizers, so the factor's influence will be less.
Well, according to your example, that's just what may happen:
Quote:
Default (b_quant=1.25)
=====
Pquant= 4 -> Bquant= 4*1.25 +1.25 = 6.25
Pquant=20 -> Bquant= 20*1.25 +1.25 = 25 + 1.25 = 26.25

difference between P and B quants:

P=4 -> 2.25
P=20 -> 6.25
Even with default value (1.25), with P low quantizer difference is 2.25, with P high quantizer, difference is 6.25.

Er, what about a 2 pass command example Noone already tested it?.
Don't know what to begin with.
Willing to have more to play with...
Reply With Quote
  #109  
02-24-2004, 08:09 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 was posting when you were posting... again, nice explanation in last post.
vhelp asked for something like this in other htread: to know what functions to use, and what parameters, and what are those parameters for. This way, we can tweak it better for our purpose.
Cool.
Reply With Quote
  #110  
02-24-2004, 08:13 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
About 2-pass encoding

I don't know which would be better as a 1st pass (when fitting one movie per DVD):

1) Encode with vqscale=2;
2) Encode with avg bitrate = max bitrate;

The information would probably be different in all those scenes where vqscale=2 would have gone over the max bitrate limit. And probably the information would be worse, or else there wouldn't be a problem doing 1st passes with vqscales bigger than 2.

But on the other side if the 1st pass fitted the DVD there would be no need for a 2nd pass...


Bilu
Reply With Quote
  #111  
02-24-2004, 08: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
Sorry bilu, big noob here
I need, if possible, one or two steps backward...: how do I say mencoder to encode first pass with some settings and second pass with other. I mean:
1st pass:
vqscale, vbitrate=vrc_maxrate, 2 B frames, ... whatever
2nd pass:
no B frames, vqblur, trell, mv0, vbitrate=desired average bitrate,...
Don't know if I explain well myself. I can't still think about how to encode in every pass, if I even don't know how to make mencoder encode in each pass with different settings... if possible.
Sorry if I'm like a pain.
Reply With Quote
  #112  
02-24-2004, 08: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 digitall.doc
Even with default value (1.25), with P low quantizer difference is 2.25, with P high quantizer, difference is 6.25.

Willing to have more to play with...
Well you could start by telling us about the quantizers on that Star Wars explosion. It's a good place to start testing the b_qfactor influence...


Bilu
Reply With Quote
  #113  
02-24-2004, 08:34 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
Sorry bilu, big noob here
I need, if possible, one or two steps backward...: how do I say mencoder to encode first pass with some settings and second pass with other. I mean:
1st pass:
vqscale, vbitrate=vrc_maxrate, 2 B frames, ... whatever
2nd pass:
no B frames, vqblur, trell, mv0, vbitrate=desired average bitrate,...
Don't know if I explain well myself. I can't still think about how to encode in every pass, if I even don't know how to make mencoder encode in each pass with different settings... if possible.
Sorry if I'm like a pain.
2-pass example (for MPEG-4, but the important stuff is here):
http://www.mplayerhq.hu/DOCS/HTML/en...eat-divx4.html

As you see, it's easy

Meanwhile, I found that I'll use Linux instead of FreeBSD for encoding:
http://www.bsdnewsletter.com/2003/10/Features110.html

IMPORTANT NOTE: Except for vqscale=2 or vbitrate=vrc_maxrate if used on 1st pass, DON'T CHANGE PARAMETERS BETWEEN PASSES!!!!

Bilu
Reply With Quote
  #114  
02-24-2004, 08:38 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
@ bilu,

which explosion is that from (scenewise) ??

..the one where the plain lands (the decoy gal is on) or some other scene?

I have another scene that I"m working on, which I think is a pretty good one
to work with, because it's got low-light in those scenes, and there is lots of
fire, and then it finishes off w/ another quiet low-light (red) scene.
.
.
That scenes is from my Fifth Element disk. You can find it at end of chp 6
and leads right into 7. If you got this DVD, take a look, and let me know
what you think of it, as a test scenario to use in mencoder/ffvfw etc etc

-vhelp
Reply With Quote
  #115  
02-24-2004, 08:42 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
@vhelp

I don't know what scene it is, digitall.doc didn't told

Big explosions and very fast action scenes are allways good for this sort of test. I have that DVD at home and will take a look, but I trust your judgement - it's an explosion, so it must be good

Off to bed now. Bye.


Bilu
Reply With Quote
  #116  
02-25-2004, 05:27 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Obligatory reading about Mencoder:

http://www.mplayerhq.hu/MPlayer/rele.../man_page.html
http://www.mplayerhq.hu/DOCS/HTML/en/mencoder.html
http://www.mplayerhq.hu/DOCS/tech/encoding-tips.txt

Note: Most docs are MPEG-4 focused, but there's lot of common information.

Bilu
Reply With Quote
  #117  
02-25-2004, 10:47 AM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
Hi bilu,

I've U/L'ed that clip I mentioned last night. The one from
the dvd, "The Fifth Element".. chp 6/7.

There were other encoding tests that I performed on this same
scene (ie, TMPG, ffvfw, and now, w/ MEncoder)

In any event, since you already have the DVD, (mine is NTSC)
You can run your own tests, and compare against mine. See
if you get the same results, or whatever.

The only problem I still have w/ mencoder is the caos of
error messages it spits out. IMO, MEncoder is very picky/fussy about
everything !!

DOWNLOAD:

* 5_enc.m2v

-vhelp
Reply With Quote
  #118  
02-25-2004, 12:17 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
Hi vhelp,
I'm sorry for not having posted about my experiences with mencoder under windows 98 se but right when I was going to try it, the harddrive of the laptop died...
Since parts for such an old laptop are very expensive, the company gave me a new one with XP Home preloaded...
But I promisse if I find a PC with windows 98 I'll give it a shot.
As to mencoder being very picky with options, I haven't been experiencing much messages on my latest trials.
Have you downloaded your build from the official site? That's the one I've been using along with the files provided by Vmesquita to recognize makeAVIS.
Or maybe the problem is OS version related

@all
Can someone post their experiences with mencoder under windows 98?

Cheers
__________________
Rui
Reply With Quote
  #119  
02-25-2004, 12:44 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
@ rds,

I've tried the log file thing, but its only for 2pass encodes and I only do
one pass - - so, nothing gets writen to file. FWIW, I use the following
param in my string for mencoder:

Code:
-passlogfile=h:\mencoder\5_enc.txt
** But, even w/out the .txt it still will not write any log file.

From the .HTML docs:
--------------------
Quote:
-passlogfile <filename>
......When encoding in 2pass mode, MEncoder dumps first pass' informations to the
......given file instead of the default divx2pass.log.
@ rds, and others...

I'm really desporate to find out HOW to avoide the errors. It sounds to me, like
the settings ALL have to work in concert, else the errors poor out. And, if a
given area ina scene is too much for a diven mencoder setting, errors will poor
out still.
.
.
I refuse to believe that its an OS thing. We are all working from the same build
and same command-line param strings, and values. But, one thing I did notice, and
that is, when ever I try others param string (when they are posted) I almost alwasy
get a different quality result. Sometimes, I get nothing but green video. ie,
when you posted amenophis's code, and I used it as a test, I got nothing but green
in my video, but, when I comment that line out, and used MY param string, I got a
perfect video (minus the errors, of course)

-vhelp
Reply With Quote
  #120  
02-25-2004, 12:48 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
PS: oh, did anyone D/L the sample I posted earlier here, I did w/ mencoder yet ??

You should be able to open it w/ all apps, except DVD2AVI. Even bviewer
opens it fine. I even got the green flat-line in bviewer's windoer

-vhelp
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:31 AM  —  vBulletin © Jelsoft Enterprises Ltd