FFmpeg vs FFvfw vs Mencoder ? - Page 8

digitall.doc · #**141** 02-28-2004, 11:37 AM

Hi vhelp,
don't know if understood you well, but if you wanted a list of software to be installed in this 2nd PC, look at the nice sticky rds wrote, and is at the begining of thread list. And there you'll find also a mencoder command-list to begin testing with.
Sorry if I don't give any feedback with your W98 problems, but I don't have the way neither the knowledge to help you.
Hope you'll be able to solve it soon.

digitall.doc · #**142** 02-28-2004, 12:32 PM

Well, this maybe something like double posting, but I wanted to share with people coming to this thread a test I did comparing ffvfw and mencoder two-pass encoding.
To sum up, mencoder was faster (about 10 fps in each pass, vs 7 fps max in ffvfw), with a Q value far stable around 2 (some people consider that a stable Q value is not as good, but I guess this is true when bitrate goes above maximum, and in my tests max bitrate was around 5700 in mencoder and 5600 in ffvfw). Ffvfw took around 2 seconds to change from an initial Q value of 4 down to 2, and Q also didn't change along the test.
My sample is as always 1000 frames of StarWars II.
Maybe the difference is due to different settings in both "encoders", but these are my results. And again fingers up for mencoder.
BTW, is there a new release of mencoder for windows. I don't know, just asking (and too lazy to look for mencoder homepage...)

bilu · #**143** 02-28-2004, 02:03 PM

Guys,

I didn't had time to test since my last post and won't have the time to test until at least the next Friday.

But I have an idea that can become a greater contribution if I or somebody else does it: the MPlayer team has been focused on porting MPlayer for Windows, with Mencoder being carried behind as part of the code.

I'm almost sure that, unlike MPlayer, there is little need for Windows-specific code for Mencoder to work.

So it may be possible to do a direct CVS compile of Mencoder that would bring a lot of neat features to the Windows port, namely the capability for interlaced encodes that would enable us to do direct NTSC KDVDs without need for IVTC and pulldown or deinterlacers.

From what I know so far the SVCD resolutions also have the same vertical lines as DVDs, the only exception being VCDs. So only VCDs would need treatment when working with NTSC Telecined sources - selecting one field would not be enough.

When the direct CVS compile is done, someone has also to convert the CVS man page to HTML.

If nobody does it during next week I'll do it on the week after

Cheers,
Bilu

rds_correia · #**144** 02-28-2004, 02:37 PM

Good thinking Portuguese friend

.
The problem is I don't have the needed knowledge/skills to do that.
Can someone give it a shot?
Cheers

bilu · #**145** 02-28-2004, 10:20 PM

Had a look at the current CVS man page. Here's a list of interesting stuff:

Quote:

================================================== ===========================

kerndeint[=thresh[:map[rder[:sharp[:twoway]]]]]

Donald Graft's adaptive kernel deinterlacer.
Deinterlaces parts of a video if a configurable threshold is exceeded.

"thresh (0 - 255)" Threshold (default 10).
"map (0 or 1)" Paint pixels which exceed the threshold white (default: 0).
"order (0 or 1)" Swap fields if 1 (default: 0).
"sharp (0 or 1) Enable additional sharpening (default: 0).
"twoway (0 or 1)" Enable twoway sharpening (default: 0).

================================================== ===========================

filmdint[=options] (only needed for IVTC)

Inverse telecine filter, similar to the pullup filter above.
It is designed to handle any pulldown pattern, including mixed soft and
hard telecine and limited support for movies that are slowed down or sped
up from their original framerate for TV.
Only the luma plane is used to find the frame breaks.
If a field has no match, it is deinterlaced with simple linear
approximation.
If the source is MPEG-2, and this must be the first filter to allow
access to the field-flags set by the MPEG-2 decoder.
Depending on the source mpeg, you may be fine ignoring this advice, as
long as you do not see lots of "Bottom-first field" warnings.
With no options it does normal inverse telecine, and should be used
together with mencoder -fps 29.97 -ofps 23.976.
When this filter is used with mplayer, it will result in an uneven
framerate during playback, but it is still generally better than using
pp=lb or no deinterlacing at all.
Multiple options can be specified separated by /.

crop=w : h : x : y

Just like the crop filter, but faster, and works on mixed hard and soft
telecined content as well as when y is not a multiple of 4.
If x or y would require cropping fractional pixels from the chroma
planes, the crop area is extended.
This usually means that x and y must be even.

io=ifps

fps

For each ifps input frames the filter will output ofps frames.
The ratio of ifps/ofps should match the -fps/-ofps ratio.
This could be used to filter movies that are broadcast on TV at a frame
rate different from their original frame rate.

luma_only=n

If n is nonzero, the chroma plane is copied unchanged.
This is useful for YV12 sampled TV, which discards one of the chroma
fields.

mmx2=n

On x86, if n=1, use MMX2 optimized functions, if n=2, use 3DNow!
optimized functions, othewise, use plain C.
If this option is not specified, MMX2 and 3DNow! are auto-detected, use
this option to override auto-detection.

fast=n

The larger n will speed up the filter at the expense of accuracy.
The default value is n=3.
If n is odd, a frame immediately following a frame marked with the
REPEAT_FIRST_FIELD mpeg flag is assumed to be progressive, thus filter
will not spend any time on soft-telecined MPEG-2 content.
This is the only effect of this flag if MMX2 or 3DNow! is available.
Without MMX2 and 3DNow, if n=0 or 1, the same calculations will be used
as with n=2 or 3.
If n=2 or 3, the number of luma levels used to find the frame breaks is
reduced from 256 to 128, which results in a faster filter without losing
much accuracy.
If n=4 or 5, a faster, but much less accurate metric will be used to
find the frame breaks, which is more likely to misdetect high vertical
detail as interlaced content.

verbose=n
If n is nonzero, print the detailed metrics for each frame.
Useful for debugging.

dint_thres=n
Deinterlace threshold.
Used during de-interlacing of unmatched frames.
Larger value means less deinterlacing, use n=256 to completely turn off
deinterlacing.
Default is n=8.

comb_thres=n
Threshold for comparing a top and bottom fields.
Defaults to 128.

diff_thres=n
Threshold to detect temporal change of a field.
Default is 128.

sad_thres=n
Sum of Absolute Difference threshold, default is 64.

================================================== ===========================

lmin=<0.01-255.0>
Minimum lagrange multiplier for ratecontrol, you probably want it to be
equal to or lower than vqmin. (default: 2.0)

lmax=<0.01-255.0>
Maximum lagrange multiplier for ratecontrol. (default: 31.0)

Where did this came from?? Default rate control equation is still tex^qComp, so where is this used?
================================================== ===========================

inter_threshold <-1000-1000>
Does absolutely nothing at the moment.

================================================== ===========================

sc_threshold=<-1000000-1000000>
Threshold for scene change detection.
Libavcodec inserts a keyframe when it detects a scene change.
You can specify the sensitivity of the detection with this option.
-1000000 means there is a scene change detected at every frame, 1000000 means
no scene changes are detected (default 0).

NOTE: complementary to keyint
================================================== ===========================

vrc_buf_size=<value>
buffer size in kbit (pass 1/:2).
For MPEG1/2 this also sets the vbv buffer size, use 327 for VCD,
917 for SVCD and 1835 for DVD.

We were right
================================================== ===========================

vrc_buf_aggressivity
currently useless

vrc_strategy
Dummy, reserved for future use.

================================================== ===========================
vrc_init_cplx=<0-1000>
initial complexity (pass 1)

Already on the Windows port, may be an interesting parameter.
================================================== ===========================

ildct
use interlaced dct

ilme
use interlaced motion estimation

alt
use alternative scantable

top=<-1-1>
-1 automatic
0 bottom field first
1 top field first

ildctcmp=<0-2000>
comparison function for interlaced dct decision

================================================== ===========================

qprd (for use with trellis)
rate distorted optimal QP for the given lambda of each macroblock

nr=<0-100000>
noise reduction, 0 is disabled

qns=<0-3>
quantizer noise shaping, reduces ringing artefacts, larger values are slower
but may not result in better quality
this can and should be used together with trellis quantization, in which case
the trellis quantization (optimal for constant weight) will be used as startpoint
for the iterative search.

0 disabled (default)
1 only lower the absolute value of coefficients
2 only change coefficients before the last non zero coefficient + 1
3 try all

vqmod_amp
experimental quantizer modulation

vqmod_freq
experimental quantizer modulation

================================================== ===========================

About CVS compile, I haven't looked yet to to process, but I've seen that I have to compile Mplayer also: theres a configure --disable-mencoder switch for the compile, but there is no --disable-mplayer switch

Explanations for the parameters I posted will come later

Bilu

digitall.doc · #**146** 02-29-2004, 05:01 AM

Hi bilu,
you always illustrate me

Sorry me if i don't give too much feedback on NTSC, inverse telecine, encoding interlaced, and so on, since I don't run into problems with this issues and don't have much experience. Cannot help much.
I hope that your next CVS compile will give us much improvements, and as I see by your last post, it seems it will do (I read new parameters to play with)

Here I am, waiting for your next post, explaining these new toys...

rds_correia · #**147** 02-29-2004, 07:19 AM

Hya,
It's good to have a guy on our team interested in ntsc picture treatment.
Even if he lives in PAL land

Forgive me for my ignorance, but since I live in PAL land I don't think I need to do any deinterlacing, right?
At least all my movies look ok

But anyway, doesn't avisynth correct that issue too, bilu

Or are you just thinking about using internal filtering to gain speed

Ok, maybe one day we notice that with all the avisynth filters being imported by mencoder,
we don't need avisynth anymore

Anyway, I was wondering, how have the Linux guys dealt with such issues since they use Mencoder, anyway?
Has it been implemented in the Linux version for some time?
Keep up with the good work

Cheers

vhelp · #**148** 02-29-2004, 09:48 AM

Morning guys.

Yes, I could see avisynth "moving" towards (or shall I say, into) MEncoder
artchitecture world

but actually, MEn already has many powerful filter
rich features. And most are optimized for MEn. The only thing we need to
do at this stage (after working out the other kinks) is to figure them out in
our daily MEncoding projects. ** note, don't get me wrong.. I'm not about
to drop TMPG, but for the moment, I'm

'ing away at MEn for now

Also, I'm undoubtlely run comparison test between the two

My next encounter w/ MEn will be the IVTC stage. As we speak, I use the
following procedure to do a perfect IVTC (when source is TRUE film) This is
specific to TMPG projects of mine:

* dvd rip (if from dvd - these are only test, I have no need t rip my dvds)
...But, for captures.. if source is TRUE film ... skip over these items..
* smartripper
* dvd2avi v1.85 using 29.970 fps
* VFAPI to suedo .AVI
* open inside vdub
* do my "special" vdub filtering

* now, import into my "special" IVTC script in avisynth
* next, frameserve to TMPG and encode to perfect IVTC.
...I have other IVTC methods that I debug, but the one I'm using
...seems to yield the best results. You'r mileage will vary w/ your method

Of course, if your source is based off a "capture" project, then you could
skip the DVD stuff and move on to "open inside vdub.."

Yes, there are too many steps in between. MEn could quite possibly solve
that problem in one shot. But, it requires a little learning curve. I'm on
to it now.. and I don't know a thing about my first step in MEn's IVTC process.

I'm not sure what bilu means by Interlace (if someone were to port or comiple
thew new CVS under windows) I know that MEn has Interlace features. There is
even a param string for it: xvidencopts=interlacing (yes/no) but I did
do a few Interlaced source, and I felt that MEn did them very well. But, even
if you can't work out interlacing w/ MEn, at least you can now use your favorite
.AVS Interlace/deInterlace script inside MEn :P

For now, MEncoder is very interesting to me, and I'm having some fun working
with it (though I've had lots of upsets) but for now, I'll continue messing
around with it.

Cheers guys,
-vhelp

vmesquita · #**149** 02-29-2004, 11:13 AM

Ok, I am compiling this beast...

Now it's just a matter of finding the right configure options. Till now I found out this ones are needed:

Code:

./configure --enable-runtime-cpudetection --enable-static --confdir=mplayer/

I am using cygwin, looks like the guy who did the previous compile used MinGW (probably with MSYS), but I am more familiarized with cygwin.

I'll post a download link as soon as everything is ready.

digitall.doc · #**150** 02-29-2004, 11:54 AM

Quote:

Originally Posted by vmesquita

I'll post a download link as soon as everything is ready.

hey vinicius, here we are all waiting like

,

and when you get it we'll

,
and

for you.

BTW, is there any mencoder forum where we could keep informed of latest improvements in new mencoder versions. Or we could ask our doubts (for instance, I would like to activate mpeg_quant since, AFAIK, we are encoding with H.263 quantization, and everytime I tried to activate it, mencoder crashes). I would also like to know how to improve speed (if possible tweaking settings), take advantage of internal filters,... well, questions, questions, questions.
I browsed the page from I downloaded mencoder, but didn't find where to investigate this.

EDIT: I would also ask about those f**king PTS SCR errors, and how to sort them out

vmesquita · #**151** 02-29-2004, 01:47 PM

Here it goes:

http://www.jltoca.uaivip.com.br/file...-29-2-2004.zip

This is the compiled from today's CVS and libavcodec has also been updated from today's FFMPEG CVS. I also updated the manpage and included in docs folder, along with some extra documentation. The package also included the correct codecs.conf file. I hope you enjoy.

rds_correia · #**152** 02-29-2004, 01:52 PM

GREAT stuff VM
Got only three words for you buddy: Good, Damn, Job

I'm gonna try it ASAP.
Cheers

digitall.doc · #**153** 02-29-2004, 02:02 PM

Hi vmesquita:

(I promised

)
Already downloading...
I should take it a look before asking, but I can't wait:
- first I see the filesize is smaller than version we use, did you manage to make it smaller (you see, I don't know a word on compiling

)?, is it also faster (I know, I know: test it)?
- in man_page, do they specify what are the changes, bugfixes,... from previous version?
Well, I'll take a look.
Thanx a lot, very helpful indeed.

EDIT: I knew i should have taken a look first. Since there's no mplayer, the file is smaller. But mencoder still got smaller, does this mean anything?. There's also a cygwin1.dll, I suppose that needed to make work the compilation, that wasn't in the previous release. Won't it also slow down performance?. Just curiosity, I'm, We're all very grateful to your job and effort helping us.

vmesquita · #**154** 02-29-2004, 02:07 PM

Quote:

Originally Posted by digitall.doc

- first I see the filesize is smaller than version we use, did you manage to make it smaller (you see, I don't know a word on compiling

)?, is it also faster (I know, I know: test it)?

The package is smaller because it doesn't include mplayer... Nobody is using it here, so I thought people would enjoy better a smaller download.

I don't know if it's faster, I did using cygwin, the previous compilation was done with MinGW. But it can be faster by optimizing for each CPU. But you would need many compiles this way. A fast test showed that compiling specific for atlhonXP makes it 10% faster.

Quote:

- in man_page, do they specify what are the changes, bugfixes,... from previous version?

I just converted the man page to HTML, but didn't take a deep look...

vhelp · #**155** 02-29-2004, 02:09 PM

Hi vmes..

Great

I'm D/L'ing it as we speak. And, I will test it out. But, my question to you
is this..

* all you did was re-compile it ??
* and, as such, we are just testing it to see if it works in command-line mode,
....aren't we ??

Please let me (us drones) know what else is in store, but I'd like to know
what exactly it is that I'm am about to tinker with

Great, Cheers, and thanks again pal,
-vhelp

vmesquita · #**156** 02-29-2004, 02:26 PM

@digitall.doc
Like I said, the previous compilation was done using MinGW. I compiled using cygwin, and cygwin-compiled stuff need this dll cygwin1.dll. About performance, I have no idea, I did a fast test and it seems to perform about the same as the old executable.

@vhelp
I just got the latest source from CVS and recompiled. The latest source has the features bilu described. I also included the updated manual with that features. Mencoder uses libavcodec from FFMPEG (you have to grab it separatelly when downloading from CVS), so I decided to use the latest libavcodec.
I didn't took the time to do extensive tests (playing with it right now).

rds_correia · #**157** 02-29-2004, 03:05 PM

Quote:

Originally Posted by vmesquita

The package is smaller because it doesn't include mplayer... Nobody is using it here, so I thought people would enjoy better a smaller download.

Hi VM,
In fact I've been using it for a while already.
I just drop the avi/m2v/vob over the mplayer.exe and watch mencoder's results with mplayer.
Not a big issue though.
I'll keep using powerdvd that came with my DVD.
Thanks anyway

digitall.doc · #**158** 02-29-2004, 05:12 PM

Hi vmesquita and all around here,
I already tested your new mencoder compilation (just two samples, to "taste" it).
Related to speed I think is faster: this samples I made earlier with previous version, run at 6 fps. With your compilation it varies between 6 and 7 fps (I know, slow, but encoding at 16:9, 704x576, maxrate 8000 and high quality functions,... and my PC is not a Ferrari

)
Related to error messages: I was already getting this message, always at the begining of the encoding, with previous compilation:

Quote:

Unknown block type, possibly non-MPEG stream!

But doesn't stop encoding and later I don't see errors in stream. I thought it might be due to makeAVIS, but I fed mencoder directly with a vob file, and got the same message. I get it also with new compilation. Any idea about how to sole this?.
And I get two new erros. The first one appears before starting encoding:

Quote:

[mpeg2video @ 0xa04bf50]Warning min_rate > 0 but min_rate != max_rate isnt recommanded!

Doesn't seem dangerous, just a warning, since I used minrate=300 and maxrate=8000.
The second error worries me more:

Quote:

[mpeg2video @ 0xa04bf50]rc buffer underflowin

Also appears at the begining of the encoding (after Unknown block type error), doesn't stop encoding, and I don't see any errors later in the stream. But I'n afraid it will give me later errors when muxing. What do you think?.

vhelp · #**159** 02-29-2004, 05:24 PM

@ digitall,

try doing TWO types of encodes, using the same distance (time/length)

* one for clip w/ high action, and
* another, for low to no action.

I have a fealing that the reason we (I know I do) get errors in my MEn encodes
is because when we reach a certain point in high action in our frames to
encode, the encoder goes kookoo, and the "threshhold" is over-bearing to
the encoding process. I know I get various kinds of error, but if I feed in a
quite scenes, so far, I get no errors or warnings, and encodes go smoothely.

What puzzles me is the fact that dispite the many errors that can poor down
one's pc screen, when the final encode is played, all looks well. It makes me
go

hmmm....

Other times, when I'm encoding small clips, the encode will go smooth, and
then all the sudden, screen poors with errors, then things go smooth again,
(no errors) and then more errors poor out. This is dependant on the scenes
and sources that I encode in my various stages. I'm trying to narrow it down
to certain scene "threshold" quite vs. high, quiet-to-high vs. quiet-semi-high
etc etc.

OT: by the way, does anybody KNOW HOW TO crop "manually", instead of
having MEn do it automacally ??
I need to crop manaully, and the auto is not for me. Please, help anybody !! Thanks..
-vhelp

rds_correia · #**160** 02-29-2004, 06:02 PM

Hi vhelp,
Imagine you have a DVD 720x576.
Also imagine that the black bands on that DVD are 12 on top and 12 on bottom.
Open up FitCD or MStacker and get the resizing figures.
It would give you for a non-anamorphic 704x576 XVCD:
Crop 712x552
Resize 688x400
Note: values taken from FitCD 1.1.3pre1!
As far as I know from "shh" the developer of FitCD on which MSatcker is based, MStaker needs
to be updated on some of the calculations.
Now put these arguments in mencoder:
:crop=720,552:size=688,400:expand=704,576:
These would go on the -lavcopts arguments.
Worked for me.
Anyway bilu may give you better advise.
Cheers