Live preview of Mencode output file
 

Hi,

There is no mencode forum so I post there (even if I actually using pack-shot ;-)).

:arrow: as mencode doesn't lock the m2v it produces, you can watch what is already encoded with vlc (videolan) :idea:

I'm currently at 55% of my first encoding (kvcdx3). The quality is AMAZING.
If the estimated size is correct, the final video will be 744 MB, right in the target.
Earlier this afternoon I predicted the same movie with CQMatic and after 5 hours (1 more that needed by mencode) TMPGENC gave me a ... 840 MB file :-( :banghead:

As Kwag said, tmpgenc is probably on the edge to be... history :-)

Note: thank you to all people involved in the mencode adventure. I missed the best part because of my personnal problems :cry:

1pass or 2pass encoding?? in mencoder

btw CCE also doesnt lock the actual encoding of an m2v ;-)

1 pass for the moment. Why ?

Sure. But I already know the quality of CCE output, I do not need to preview it :-D

If you set i.E. the desired average bitrate in mencoder at lets say 900kbit .... nealry 900kbit often will come out!
One the one hand thats sexy BUT ... as I recognised the encoder does VBR but tries during the movie to keep the avg bitrate, ... so if he comes near to the end he sees if enough room is available and then he "tunes" the bitrate so it does mach .... and that means in 1pass you should watch out as this does mean - non quality based 1pass VBR :!: (IMHO)!

;-)

Re: Live preview of Mencode output file
 

No, for me it already went over the edge, and down the cliff :mrgreen:

-kwag

All what you are saying there is that 2pass result is always better than 1pass. That is not new :-). But is doesn't means that 1pass result is bad.
And there it seems damn good. I just saw a big mosquitoes problem during a hunt scene but I have to check the source to see how it was because camera really jerk in all directions in this scene.

@Phil,
I think the only problem of 1pass is that if the movie is low motion but at the very end turns into a lot of action we can blow our max bitrate.
That also will only be a problem for those shooting for (S)KVCD since in KDVD we'll be probably safe IMHO.
Cheers

You will have the same whatever the number of passes !

Do you thing that during second pass, while it is processing the begining of the movie, the encoder looks (or remembers) what happened at the end of the movie during the first pass ? For sure not !

The adjustment is done locally. It' like an anti-aliasing algorythm that is processed on the bitrate curve. Each pass will smooth the curve a little more than the previous one, that's all. But if the curve reaches the roof somewhere in the process, it will always reach it even after the 1000th pass.

Yes It does
:D
And it makes a hell of a difference, from 1-pass to 2-pass.
I know what Rui is refering too, because I experienced it the other day. I had encoded a movie in 1-pass, and at the end, it was very blocky on fast scenes. So I did a 2-pass of the movie, and it cleaned it up. So it distributed the bitrate correctly.

-kwag

Kwag this can't be done ! It's barely impossible !
How do you imagine the tool can, for each second of the video, verify what happened for every other second of the video :?:
(there is no reason to verify only the end, is it ?)

:arrow: it would take forever to process the second pass :!:

Note: I mencode need 2pass to obtain a correct encoding it will be slower than TMPGENC. I don't see any reason to drop this old pal in this case. ;-)

Edit: ohoh... I just watched the video and the result is really good the first two third of the video but... unwatchable after that ! Like a CQ=20 under tmpgenc. I will see tomorrow with 2 pass. Tmpgenc is still on my disc and probably for a long time...

Sorry to crash your party guys, but isn't the whole idea of a 2 pass encoding that the encoder analyzes the video in the first pass and then distributes the bits in the most fitting way in the second pass :?:

That's what the first pass log is for :!:
To map the complete characteristics of the of the material, and take those factors into consideration on the second pass.
Or, did I miss something :roll:

-kwag

@kwag
That's exactly what I thought too...

Doesn't seem to be thaaaat diffculat after all...

in the log file of the first pass he only has to analyze motion vectors of the source material and the amount of bitrate it would need if encoded at 100% quality...
--> the more and longer vectors, the more motion, the higher the bitrate

and all this has to be scaled down...
The encoder could calculate the middle of all the bitrate used and assume this middle is the bitrate you told him to do...
Now he could make "Percentages" for each GOP/Frame
e.g. frame 2345 has 150% of the average bitrate
--> the encoder will allocate 150% of the wanted bitrate for this frame

or maybe this was a revolutionary new idea :D

Hi Phil,
Not that I want to change your idea on libavcodec-based encoders but how come MEncoder 2-pass is slower than Tmpgenc 1-pass on your PC?
Mine wasn't much slower from the tests I did before changing CPU :roll:
If you can double check that I'll run a last test here because the difference was insignificant using light MA on both.
Again Phil, what were the arguments used on MEncoder.
Are you using MencodeMe? PackShot? Your own command line?
I haven't done so many full encodes lately but the few I did are right on the average I asked MEncoder to do.
That would be exactly the opposite of what I told you before on this thread.
I've done 2 full 2-pass encodes and 4 full 1-pass encodes.
The 1-pass encodes are more bitrate demanding in the final 10% of the movie.
The 2-pass encodes are not so much demanding on the final 10% of the movie but I think I can still see MEncoder using a bit more bitrate there too 8O
In the end all my encodings are very good looking with average bitrates of 2000-2200. You see I am aiming for 2 movie per KDVD.
So please post your setting as there is definitely something wrong with the encoding you did.

:!: :!: UPDATE :!: :!:
@all,
Ran a test of TMPGEnc and MEncoder&makeAVIS with the same script that just do resizing. No filtering at all.
Tried to maintain every encoding parameters as equal as possible: same GOP size, same GOP structure, same VBV, etc.
But I set TMPGEnc in CQ mode.
:lol: In fact I don't even know other mode to use TMPGEnc, besides CQ_VBR :lol:
Of course MEncoder was set to average bitrate.
In 60 seconds of encoding:
Menc gave me 2019 frames
Tmpg gave me 802 frames
You can do the tests yourselves :wink: but to me that seems that MEncoder can be working in 2pass and still be faster than TMPGEnc 1pass CQ mode
Note: not that I will use 2pass very often, but if we can prove that an encoding done with :vpass=1: has the same quality as an encoding done without that argument...
Then, if so, I think it would be wise to change MencodeMe and PackShot CLI arguments to use :vpass=1: even if user doesn't want to do 2pass.
But that way, with the divx2pass.log, we can still do a 2nd pass and make the movie look better :D
Cheers m8

Phil, even if Mencoder "would" take a bit more when using two pass ...... well as you also sometimes say ... quality counts not time :lol:

I didnt make tests on low bitrate encodings like for one CD but on DVD encodings where i.E. an avg bitrate about 2000kbit is used. And there Mencoder was better.

So I should ask again ... whish way did you choose for your encode?
Via MencodeMe, Packshot or directly copied/typed commandline?

There is a log file ? Where :?: I do not see it.
If there is a log file, for sure no. But either I missed this log file, or the 2pass doesn't work like you think it is.

Note : I'd finished the 2pass encoding of my previous 1pass job. Thje result is exactly the same ! Action scene in the last third of the movie are unwatchable.

Now, the source is hard to encode because the output of tmpgenc , with a CQ of 77, is abnormally blocky on these scenes too. But much better than mencoder.

I thing that there is just a matter of tuning of the parameters as the result is really good in the first part of the video.

Note: I was doing a cartoon, and we all know that these sources are particular.

To answer to both you and rds at the same time : mencoder 2pass took 6 hours and tmpgenc (1pass so) needed 5hours. So don't bother rds, memconder is near 2x faster even on my little 1.4GHz P4.

Now Inc, I agree with you, the problem is as I told in the previous post, memcoder didn't give me a better result on this job :-)

I did a KVCD but a short one : 1h20 -> avg was 1240. I think that can be take as "confortable" for a KVCD. Now, this is a cartoon...

Read the very fist line of my very first post :-)

While doing the first pass using mencoder a "divx2pass.log" will be written in the folder where mencoder.exe is.


Ok u do use Packshot (as I understood that - Im too lazy to scroll up now :P)

So take the EXACT same mencoder commandline in the bat file and change the "lmin=0.x" to lmin=1
And do encode again ....
As it would be interesting .. RSD or DigiDoc told me afterwards that when doing low Bitrate encodes that should be not less 1 ... I did set it to 0.3 as by this the quantizer can be lower than 1 means you can go up to very high avg bitrates in case of kDVD and as this "Packshot" was purposed to do kDVDs ... so you should test again with lmin=1 ;-)

Am I supposed to encode the whole movie in 2pass or can I do just a sampel including the involved scenes ?
In the first case... you will have your answer in 6 hours, no less :wink:

Phil,

Drop AviSynth :!:
Encode directly from the VOB, using mencoder internal filters.
You'll see a hell of a difference in speed too.

-kwag

Come on Phil, don't tease with us :wink: :lol:
Just make a sample of the involved scenes.
Hope that can come up in 30 minutes cause I'd like to know the results :wink:
Cheers m8

I'm doing kvcdx3 for the moment. SO I need :
1/ correct A/R taht only movie stacker can insure to me
2/ 544*576 res that is not implemented yet in pack-shot
3/ filters that are not currently into mencoder and/or can't be replaced easily with what are implemented.

But I will do my next KDVD with mencoder and no avisynth.

@Dialhot
Please try MencodeMe with the DVD filtering combo. It's aimed to reproduce optimal script effect without M.A. MencodeMe can also do resizing calculation taking A.R. in consideration for 544x480. :wink:

Methode a)
Try MencodeME like VM told

or ... do all the settings in Packshot, choose just a "fake" resizing like 352x576, ... start encoding and "break" the console process by quitting the console.
Enter the bat file and change the resolution vaules to the ones outputted from moviestacker (explained in the suggestions thread!). resafe ... and run the bat file again ... while encoding you can check in zoomplayer/vdub if scale is correct ;-)

So I did this test tonight and somethign weird happens :

1/ the quality of the previous problematic scenes is better, REALLY better. Better than the 2pass test I did yesterday (I also used 2pass for the present attemps) and better also than the output from tmpgenc (CQ=77).

BUT

2/ the file size is 90 MB UNDER the target !

Remember taht with 0.3 the file was 744 MB, exactly what I wanted to. Today it is 656 MB !

:arrow: better quality, file 10% smaller :-)

Now I didn't compared the overall quality to see if this small size affects the video; I only focused on the action scene where mencoder failed yesterday.

Hi Phil :D
Good news huh?
Buddy, just raise the vbitrate option until you find your target size :wink:
Cheers

Thats what I assumed :wink:

lmin finally "acts like" a quantisation barrier, means the quantisation wont go under the value which is set by lmin (the official explanation is another but we do see things how they do affect finally 8) ). So do set it to 100kbit higher and you wont reach it 8)
Thats why I did tell VM to lower lmin in case of HQ dvd encodings when high avg's are used.

And as we know .. the less quantisation, the bigger the size ... well you see the result.

BUT!: It seems that this lmin factor also affects the qunatizer curve, ... so you should maybe go up to 0.5 and maybe the result will be perfect?!

Thats why I dont just implementate OneCD encoding options like just adding target sizes. There are many things which are different than doing DVD encodings using mencoder.

Maybe we can get more testing results the following days... as I do have to keep a bit the focus on my internal resolution calculation engine.
So I would apreciate your future testing/comparing results.

Greets Inc.

@Inc. and Phil,
Since I am very much interested in getting the best options package for both MencodeMe and Packshot, what kind of tests would you suggest?
Be as much specific as you can, please.
Maybe we could split tasks between us.
Just like when Digi.doc and bilu were very active on mencoder settings :D .
Cheers

PS-BTW where did that guy (bilu) go, anyway. I just can't seem to find him anywhere :(
He sure was a very valuable member to help us with the settings :)

Yes and not. That means that this is the return of the size prediction from which 2pass was supposed to save us all :-)

The problem is that I do KVCD where you are focused mainly on KDVD. Tests can't be the same.

If you put lmin bigger than just run the 2pass (if I understood you right that in your case the lmin caused to low final size at 1pass encoding,right?)

@Dialhot
This undersize problem tends to happen when mencoder simply can't quantisize lower the movie, except for the areas where bitrate is clipped by "Max". This can be fixed by tweaking scplx_mask and other variables. :wink:

All that does not explain why the result is BETTER !

As I told at lower avg bitrates the behaviour of the Q curve by this is better allocated! Thats why lmin affects the q curve diff. according to avg bitrates.

Hi all,
Dialhot, it's good you are testing this tools. Your comments are always helpful, are your critic attitude makes us improve a lot. All your opinions are based on tests and experience. That's why many of us admire you and take you in good consideration (... do you want to be my friend :lol: :lol: :lol: )
And what I'm going to tell also won't. But sometimes I have noticed that, if lmin set too low, quantizer curve behaves in an strange way: "tries" to keep very low, and suddenly raises a lot (when needed according to the film), even higher than when lower lmin value is used. And that can make appear the image worst. Usually this behaviour is smoothed in second pass, but when I see this effect, I usually raise lmin value.

Don't erase anything from your HD by now, if you don't want to,... but, come on, stay with us playing with mencoder, MencodeMe, and PackShot. I think we're in the right way (at least for some weeks :roll: )

I even print the man page today at work and I'm dying waiting for my laptop PC with a 2.4GHZ CPU (normally) that I should have soon; I will be abble to encode during my working time :-P

ok guys ! if u're interested, here's a piece of my continuous mencoder testing (now i'm above 200 test run but i'm more confused than before) see what lmin can do :

short comment : its a part of a very long test sequence so there's much more involved than needed here (say, the column q2 means the average bitrate i got with cons.quant2) ... so ...
lmin : going downward with lmin makes the bitrate curve variation more narrow (in paralel, the variance of the q curve increases) on the contrary, raising it increases the bitrate variation, max_rate pushes away, so the visible effect is an increase in quality (see psnr) while keeping the target bitrate constatnt(!)

why i'm a bit confused is that this relationship is neither linear nor monotonous (so the changes does not go this way forever. see lmin=0.01!)
the other problem is that the numbers are quite relative. i've tested lmin with 5 different clips and the values and the curves were (more or less) different.
further, with some clips i found some kinda 'disturbances ' (short reversals) in the curve so take the aboves as a 'rough guide'

some possible answers to hotdial (lower filesize/higher quality)
- if u go with lmin above qmin (not forbidden but not recommended!) maxrate increases further but the average starts to decrease. so mencoder gets unable to keep the target anymore. this way u got sg u mentioned.
- if u increase lmin (& so the maxrate) u got lower quantizers (so higher quality) for the high bitrate scenes. that's an other possibilitie.
- in general, any change increasing the local bitrate (decresing the local quantizers) gives higher quality. of course, just locally.

any comments ?

the bests
y