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 ;-) |
Quote:
Quote:
|
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
Quote:
-kwag |
Quote:
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 |
Quote:
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. |
Quote:
: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 |
Quote:
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 :?:
|
Quote:
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 |
Quote:
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. Quote:
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? |
Quote:
Quote:
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. |
Quote:
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 :-) Quote:
Quote:
Quote:
|
Quote:
Quote:
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 ;-) |
Quote:
In the first case... you will have your answer in 6 hours, no less :wink: |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.