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: