I did that anyway all the time in case of Mencoder as its much more faster than Mencoders internal engine and ..... I didnt test IF Libavcodec just "crops" the lumarange from 0-255 to 16-235 or if it SCALES the range from 0-255 to 16-235 which affects the image in a sginificant way as the lumarage would be compressed.

CCE and TmpgEnc do it by default! "Output YUV as CCIR instaed of full .. bla bla bla".

TmpgEnc does it in a significant diff. way compared to libavcodec or CCE.
TmgEnc does SCALE the 16-235 incoming Luma based YUV stream to full 0-255 rgb24 and rescales it back to 16-235 again when doing the encoding. Thats why a "limiter()" in case of a TmpgEnc usage is nonsense, that was also often stated by DialHot.

CCE Uses FORCED YUY2 input, so a YV12 one has to be conderted before (via script or by the YV12 supporting systemcodec like XVID).

So in this case Mencoder/Libavcodec is the only one which doesnt touch the Colorspace as it will be kept as YV12 in the whole progress.
So a simple crop by using limiter is perfect in case of mencoder/libavcodec.


Ok, but then the advantage of Mencoder will be blown away compared to HC, CCE etc. So thats a wrong approach.

Now we are at a state when using your line above that the Quality is a touch better, but the needed Time is decreased from almost 50fps(CCE) to 7fps (Mencoder). And that has to be taken into account if its worth it for the individual purpose.

Don't forget that in a first approach mencoder has to be tested (again) for its rate control. So you can remove all filters that are here just to enhance quality.

WHEN mencoder will go trustly between the white lines concerning the bitrates, then it will be time to look for the quality of the result it can output. But this is an other question.

The question for sagittaire is : among all the settings you suggested to remove to speed up the encoding, are you positive that none of them will modify the compliancy of mencoder concerning bitrate control ? Else, we should keep the lines as they are for the moment.

I think that we can at least change safely the diamond size and the function that cmp uses.

Note: My opinion is still that all this is just lost of time as RC module never changed in mencoder sources... but why not.

Fully agree!

IMO all ME speed improvement are good ...


I read your old Mencoder sub-forum: there was 2 problems:
- Motion Vector Range problem : solved with me-range setting
- Rate Control with underflowing problem : IMO multipass can partialy solved this problem. At this time Mencoder can't make Superbit DVD but IMO can make high quality encoding in low/medium bitrate scenario like KDVD profil

What about the minbitrate argument in the Commandline? I know it isnt supported officialy, but when I "tested" it, it made Mencoder the ONLY encoder which kept the minbitrate at the setted value! Even CCE when setting minrate to i.E. 500kbit often underruns that value.

In my tests I almost never had buffer underflows or bitrate underruns and IF then in a same way CCE does it. The only problem where the Spikes, ok for my SAP no Problem, but we are talking about official DVD compilancy in here.
And even in resulting streams where min and max where kept, sometimes it was reported that within that safe range also here the ratecontrol sometimes got messed up.

I had a look at the Q curve in BV viewer and imho sometimes when using common Comandlines the curve wasnt optimal, means not very logical.

My personal test would be: IF an encoder recognises a very low lit and very low complex scene, he shouldnt keep the Q at straight 3 or 4 for example, but he should lower the Q instead, so you will end up in a very good quality low light scene (Try to encode Underwater Scenes like you can see in Titanic or Das Boot - here youll see what I mean.
BTW: also CCE and TmpgEnc dont handle that optimal.
Is that a subject for Lumimasking?

DID you have a look at Freenc? Seems to be more easy for users as parameters easely can be tweaked in the ini file. AFAIK also MeRange is adjustable.
I dont know which build of Libavcodec it includes but it should be no Problem to recompile it using DevC++ as Vmesquita made it open source.
But that investigation of time will only be done if the "main" subject above related to DVD compilancy above will be proofed as positive.

Hi,

I tried to encode a full movie (the 18 hours encoding one) with a average bitrate of 2005 (at 704x576), and according to rempeg2, the absolute max bitrate is 8006 (I set it to 8000). According to mpeg validator, the peak on 1 sec is 7042.

So it seems that on this movie (four fantastics), it's ok. mpeg validator is giving me some errors, that I don't get with hc:
I'll make more test this we.

Salu2
Fabrice

The seq end code = nomen est omen.
The stream in regular gots a flag at the end where other apps. will recognise that this stream gots its end.
Imho this should be no problem, its more difficult if you for example do stream Episodes using DVB and every stream gots its seq end code. Do "merge" these ones without using an option for "remove seq end code" like using the DOS copy /b command ... and every demuxer could STOP at that "still existing" seq end code at the half of the merged mpeg2 stream.

I had that issue a long time ago when I streamed via DVB two episodes.
I treated them each using ProjectX and simply "merged" them after that for later cutting purposes. BUT when I wanted to "demux" again that full resulting mpg to get the separate m2v and Ac3 ... even ProjectX stopepd demuxing after approx. the half of the merged mpg ;)


Do look in the mencoder docu if theres a special argument for applying that seq.end.code.

I will try to update profil:
- VCD, SVCD, DVD profil
- PAL, NTSC profil
- progressive, telecine, interlaced profil
- Fast, normal, high and insame profil

Stream bug and quality optimisation
- Little bug issue (no fatal bug I think) like end sequence, field, first GOP
- Very important end credit option for low bitrate encoding.

@ All
If you do end up with a choma swapped result

do modify the -vf comand of each! pass of the mencoder lines below from

-vf yuvcsp

to

-vf yuvcsp,swapuv

First try and ..... same problem as before:

I used a 5% sliced sample of a typical averaged movie including action, low ligth scenes, bright light scenes, explosions, smooth surfaces, action and calm passages.

Using the exact bat file from Sagittaire.

Each pass of mencoder ran at 17fps where CCE (also 2pass) did ist job at 50fps.

First the Log .... as you can see in the third pass still buffer underruns did occur.

Then .... I reconised that even if the avgbitrate in mencoder was set at 4000kbit, the result ended up in 3556kbit in average.

AND! Even when using a max bitrate of 9000kbit we .... got .... SPIKEs up to almost 9900kbit.

See the right window of mencoders Bitrateviewer output:

http://www.digitalfaq.com/archives/i.../2006/03/1.gif

And now why is that final encoding that undersized? Very easy, we did set a wanted avg bitrate of 4000 and ended up in 3556, ... thats cause Mencoder doesn't get lower then a Q of 2. That could be handled, but still ... we do end in unwanted spikes and for my personal taste it isnt worth that much more needed time to do an encode as the VISUAL quality in my eyes (and they arent bad at all) is miiiiiiinimal. The surfaces of the mencoder result ended up a tiny bit more plain, but in a style like beeing a bit erased. The CCE result ended up a minimal more uneasy in the surfaces, but on the other side it appears more natural and not like too much like beeing denoised. I do repeat: Im talking about MINIMAL impressions now.

And all this at the very first try :(

My Conclusion: I still do like Mencoder/Libavcodec for my very "own" purposes, but I do keep myself away from agreeing that it changed to a fully DVD compilant encoder. Not mention the still undersizing result issue etc.



Btw. the result from CCE.
(keep in mind this is NON-Linear! thats why you cant compare the Q values from CCE to mencoder 1:1). Just keep your eye on the right window resulted values.
I used in the CCE encode the resulted avg bitrate from mencoder: 3556kbits. Ok CCE also did undersize a bit, but not that much like mencoder.

http://www.digitalfaq.com/archives/i.../2006/03/2.gif



EDIT:

I have here a QuEnc062-alpha4 release which looks much more promising than Mencoder!

Also here set to 4000avg and 9000max.

http://www.digitalfaq.com/archives/i.../2006/03/3.gif

Final avg is almost reached and NO spikes. Q is almost lowered to 1 sometimes which makes higher avg bitrate results possible.

I was about to start testing when I saw your post, Andrej.
Yep, good old Mencoder still has a loong way to go...
BTW, did you wrote down a speed comparison between Mencoder and QuEnc 0.62-alpha4?
Just curious ;).

well read my faq

1) first pass at q6 (vqscale=3) done 2711 Kbps. If you want no underflow you must use less than 2700 Kbps for final bitrate.

2) you want for final bitrate 4000 Kbps

You can't make encoding with your target bitrate simply because my mencoder profil have q4 saturation with this bitrate (like as you see on bitrate viewer). Use mencoder with this source for this target bitrate is simply useless here because all MPEG2 encoder will make high quality encoding with low average quant encoding (certainely something like average ~q3.5 for your source). For your source TMPGEnc KDVD profil use certainely something like ~CQ85 for target bitrate at 4000 Kbps and ~CQ70 for target bitrate at 2700 Kbps.


PS: Quantizer info from bitrate viewer seem false. FFDSHOW OSD done other result and IMO good result. IMO bitrate viewer don't analyse frame quantizer but read simply frame info. For example my profil use adaptative quantisation for IFrame and PFrame and bitrate viewer say "Linear Quantisation".

Problems
 

@Sagitaire

I'm not getting have Mencoder working properly! Please, take an eye in this Mencoder's log.txt:

I'm using a simple AVS script which just calling the MPEG2 decoder and
delivers the frames to Mencoder:

I'm using the Inc's modified profile in which I added the -ofps 24000/1001 -nosound options to profile!

Another questions is related to your FAQ: It isn't clear the way (procedure) to know which the final bitrate must to be set up in profile. I'd appreciate a better explanation about the issue.

Any advise is highly appreciated, mate!

TIA,

1) Well unfurtunaly mencoder-cvs-20060323 seem buggy. This version drop first frame and broke multipass stat file.

Use previous versions like mencoder-cvs-20060321. Here mencoder/mpalayer package (don't forget .dll for this compilation)
http://ffdshow.faireal.net/mirror/mplayer/

2) Make simply compressibility test at Q6 (vqscale=3)

If your encodage.avs script is

add simply source=SelectRangeEvery(source, 300, 15) command for make 5% encoding and partial compressibility test like this:

source=SelectRangeEvery(source, 300, 15) -> 5% of frame tested
source=SelectRangeEvery(source, 150, 15) -> 10% of frame tested

If your compressibility test at Q6 (first pass in my profil) done 2500 Kbps then you must use less than 2500 Kbps for complete encoding.

bug is confirmed by DBZ : Quantizer info from Bitrate Viewver are simply totaly false for all Libavcodec codec like Mencoder or QEnc ... :wink:

Thanks.
 

@Sagittaire

Thanks a lot, mate!! As a matter of fact, the combo Mencoder/Mplayer which I was using were buggy. Using Mencoder/Mplayer CVS-20060321 did a trick.

Regard on my question about the procedure to be used for find out which average bitrate must to be set up into profile, I've to say that now I got it!! :D

Follows my result with a small clip from a DVD of mine:

The average bitrate set up into profile was 1790 Kbit/s! (error of -0.014%).

No buffer underrun errors at all.

Bitrate graph (by DVD-Lab tool):

http://www.digitalfaq.com/archives/i.../2006/03/1.jpg

(Max bitrate set up into profile was 5500 Kbit/s - It was respected).

Encoded sample: Donwload it here.

Re: Thanks.
 

Except that DBDLabPro gives an average value of 2190 (VERY far from 1790) and a peak about 4364 where the graph shows a position above 5000 (possibly a diff in the unit used for both informations)

And now this is Bitrate viewver that is buggy and of course not this wonderfull, marvelous, amazing fully 1000% percent best MPEG12345678 encoder ever.

For me this is enought. This lavcodec joke is definitely over me. Bye.

Re: Thanks.
 

Yep, I already there was noted this behaviour. Bitrate Viewer from TECO also shows diferent values for average bitrate (and when pulldown is applied to videostream, the bitrate viewers apps increase artificially the average bitrate showed, this is a PITA).

Regard on the bitrate graph from Lab I did see this peak and it is lower than 5500 Kbits/s. Regard on the informations showed by BG from DVDLab, we can see the instant bitrate as a histogram (which are coloured with purple) and a continuous distribution (which is a approach done in a way that I don't know) coloured by blue. Seems to me that the informations about average/max bitarate are related to continous distribution, but I'm not sure.

BTW, VDM shows that average bitrate is 1790 Kbits/s (which is the correct since the it matches the target file size).

Regards,

Bitrate graphs.
 

@Dialhot

Considering still the bitrate graphs question:

*Source (ripped DVD):

http://www.digitalfaq.com/archives/error.gif

*Encoded with Mencoder (Sagittaire/Inc profile - this is from the Sample.iso which I provided for download here):

http://www.digitalfaq.com/archives/error.gif

Considering the informations from BV, both strems are in compliance with DVD spec.

Regard on the second screenshot, we can se that peak/average bitrate are so far away the values showed by BV from Lab (yeah, this is crazy! 8O ). We can see that max bitrate was respected.

Regards,

Do you think these arguments just are enough to do encode in a non-linear mode? Even if they do "sound" so? Gimme a clear documentation if this from somewhere - like the mencoder docu.

When using ffdshows Q value info output a Q of constant 4 is shown and only integer Q's are supported (floats are up rounded!).

However .... there was a clear spike in the encoding.

Ill do focus more the developing of Qenc as it seems more DVD compilant (if just beleiving in values). I dont need to do complex tasks like first pass Q resulted bitrate into account taking etc. like in mencoder.

Also ..... That slow encoding process and up to this in a three pass to me its not worth just for these little math values behind comma. Especially not when doing a 1:1 VISUAL comparison.


The easiest comparison is.

Do take both m2v resulted streams to compare and process them by using Dgindex. After this use this script:

a=dgdecode_mpeg2source("MyMencoderOutput.d2v").Sub title("Mencoder")
b=dgdecode_mpeg2source("MyXXXencoderOutput.d2v").S ubtitle("XXXencoder")
interleave(a,b)

now .... you simply can switch between both streams just using back and forth in the frame steps. And thats what what Im interested in. And sorry to say .. not in a math value taken from an average.