Why not ? the verifier can check different things depending on the source type (muxed or elementary streams). And then, yes, that means that the muxer has a problem.

Indeed, that's why I posted in my earlier results only the elementary stream. It seems muxers produce various errors. I was very amazed that even commercial DVD's produces errors 8O. But that was an ILVU disc so maybe that's the problem (star wars 3).

Interesting would be: how does the muxer errors influence the mpeg compliancy?

On my todo list is a comparison of muxers, as in ifoedit, muxman, dvd lab pro, tmpg and spruce dvd maestro. But I'll need some time for that :D

IMHO there is no question like this. It has to be checked into the doc of the soft but for me the tool does not verify the same things when you give to it a muxed or an elementary stream.
In other word, checking the muxed vob gives you only the "muxing errors" while cheking the demuxed stream really give you the mpeg compliancy.

:oops: I meant "DVD" instead of "MPEG". You're right, the muxer doesn't change the compliancy of the encoded file, but is responsible for the overall DVD compliancy.

When checking a muxed vob, the verifier does check muxer errors as well as mpeg errors. The total errors are the mpeg errors + the muxer errors + navigational errors + ....

I think that non linear quantisation is adaptative quantisation (I am not sure here ... perhaps not). Anyway Libacodec can use adaptive quantisation in two differents mode:

- RDO for each macroblock
- Masking for each macroblock (lumi, dark, spacial, temporal)

TMPGEnc use certainely something like spacial/temporal masking for Adaptative quantisation. AQ is certainely very usefull too to respect vbv limitation ...

Well I use OSD in ffdshow and I see that vqscale=2 (only for MPEG2) done q=4, vqscale=3 done q=6 on OSD ... etc etc etc

two solutions:
- Mencoder MPEG2 is buggy and use only quantizer with X2 scaling
- Libavcodec decoder OSD is buggy

I make encoding with same setting (source, custom matrix, dc ...)
- Mencoder encoding vqscale=2 done 4406 Kbps and q4 for OSD
- TMPGEnc CQ78 encoding done 4692 Kbps and ~q4 for OSD
- TMPGEnc CQ100 encoding done exactly q1 for OSD

Conclusion: Mencoder MPEG2 is buggy and use only quantizer with X2 scaling. It is not a fatal bug but mencoder can't simply use impair quantizer. Perhaps volunteer limitation from libavcodec dev for better compatibility with actual libavcodec Rate Control.

well try this:
http://oss.netfarm.it/mplayer-win32.php

be carefull :

- final bitrate must be always inferior to fast first pass at q6. Ik you want know compressibility Q6 make little compressibility test (5% is enougth with source=SelectRangeEvery(source, 300, 15) for example).

- this configuration is insame quality setting. Use CCIR601 space color for better compressibility. I use this profil only for very low bitrate with adaptative avs script.

My suggestion for easier File input handling .....

So just drag'n drop the source .avs to this bat and an encoding using the source's filename but with a suffix of .m2v will be the result.

I just want to be sure. The bitrate is given by what parameter ?
Isn't it this one :
IF yes, 4000 us not really what I call low bitrate.
What (range) value do you generally use ?

Other question : is it a 3-pass encoding ?

@Inc
Thanks for your trick.

@Phil

Yes it seems so, if I understood correctly, that given 3pass approach above avoids ratecontrol issues/spikes ?

And enhance quality as the third pass introduces the "adaptative B-frame" feature. For testing purpose I don't mind doing 3-pass, just "to see".

I have a question more : in all passes there is the "pnsr" parameter. Is it for computing metrics while encoding ?
(I'm sure I should read a fucking manual... :))

It would really be interesting if also you could do a testing. Reports from diff. users always make more sense (not beeing generylly in doubt of you Sagittaire ;) you know what I mean).
I havn't (had) that much time for backups and testings the last weeks as I focussed my eyes on c/c++ understanding . :expert:
:lol:

- by first fast pass at Q6 : final bitrate must be always inferior
- by compressibility test with modified source avs script
source=SelectRangeEvery(source, 300, 15) is 5% test
source=SelectRangeEvery(source, 150, 15) is 10% test


well 4000 is for very complexe source. I test these particulars sources only for profil validation.


First adaptative bframe is DVD compliant (CCE use adapt BF but not TMPGEnc). Second it's better for quality. Two mode are possible with libavcodec : fast adaptative based on simple motion level and full (slow) search level.


3 pass done better quality and no underflow problem if you respect bitrate limitation (lower than Q6 constant quant)

see this example:

- first pass is fast Q6 pass : done high number underflow and 4575 Kbps
(you must use less than 4575 Kbps for final bitrate here)
- second pass done little number underflow with 4009 Kbps
- third pass done no underflow with 4004 Kbps

Sagittaire
 

@Sagittaire

I've tested Inc's modified batch file out with a smal clip and I've got this error:

I don't understand this because 2997/125 fps = 23.976 fps which is a standard framerate for MPEG2!!

Any help is appreciated.

TIA,

Hi,

@Danpos: this is a daily build of mencoder, so just try to download a new daily version, to check if it has been fixed.

Speaking about that: can't we use a more stable version to play with mencoder? Because this way, everybody will be playing with a different version....

3 comment about my very first tests:
- Shouldn't be the vpass value 2 in the second encoding line? Or it doesn't matter?
- Looking at a 5% samples, comparing HC and mencoder, the image looks better with mencoder (I'm not speaking about SSIM value! :-) ). It looks, hmmm, cleaner?! And I checked mencoder against HC using SSIM, and on the frame where mencoder get real lower values than HC, the image looks like cleaned (something like a temporal cleaner). It's during a fast changing scene, so you can't see it, but HC is closer to the original, even if the original is of poor quality. I could post pictures, if you want..
- It's damned slow: each encoding pass gets 6fps (so it last more or less 4 times the length of the movie), so with 3 pass, for a 1h30 movie, it will last 18h! 8O . No way to speed up the thing a bit?

After encoding a full movie, I'll check the movie, burning a DVD-RW...


salu2
Fabrice

That's why I asked the purpose of the "pnsr" filter in the command line but did not receive any answer. If the purpose is just to compute metrics while encoding, it does nothing but slowing the process. But I don't know if mencoder needs these info to enhance the detail.

Nevertheless I hope to find a couple of hour this we to test a little all that.

Oh my, oh my...
Here we go again testing mencoder :P.
Count me in guys.
But just to make one thing straight: if 3 passes is the only way to correct mencoder's bugs and if it takes ~18 hours to encode a full movie, then I don't think I'll ever start using mencoder regularly.
And on a side note, I agree with fabrice: we should pick a stable and full featured build for our tests.
Otherwise we'll end up using different releases and the results can be veeery different ;).
Andrej, where are you? :lol:
Build us a mencoder.exe for our tests, will you? :)
Cheers

Yes please ... pictures do say much more than words.
Better: t would be very nice if we would upload results using an approx. 20sec clip for obtaining a "mas o menos" impression on a moving example.
Use www.mytempdir.com or www.rapidshare.com.

Related to the vpass=3 Line:
http://www.kvcd.net/forum/viewtopic.php?p=122355#122355

Thats exactly the point, so someone has to make the decision for himself if the result worth it.

Rui, Sagittaire already gave that link for precompiled binaries ;) :
http://oss.netfarm.it/mplayer-win32.php

That page I also visit to update the daily Libs compiles for my MinGW install.

scroll down to the section "[Precompiled Mencoder binaries - XviD 1.1.0 - x264 svn]".
There you can download K7 or P3 or P4 optimized binaries. Actual build is from Mar 23, 2006 .... these builds are updated almost daily.

BUT! From the ./configure shown further below I do see that --enable-largefiles has NOT been set. So if you go in it using a 1piece big VOB > 2GB you could get into trouble. Avs input should not be a problem as bitstream frameserving is a diff. thing compared to filehandling.

Fair enough :).
But we should pick a build, let's say from May 20th, everybody should have to use that one for the test runs.

See? That's why I was calling you. :lol:
But for the tests we should find a small 30 seconds clip that would be submitted in mytempdir and we should all work on such a clip.
BTW, Karl has a nice movie he always uses for his tests.
That's Red Planet.
I wonder if he has a small clip like the one we're needing?
Kaaaaarl?? :lol:

add −ofps 24000/1001 or −ofps 30000/1001 option

I test only PAL progressive source but it's possible to make interlaced encoding too (from lavc documentation ... but I don't test that)


vpass1 : make stat file with quant mode or bitrate mode
vpass2: make encoding with first pass stat file
vpass3: make encoding N with N-1 pass stat file. stat file is updated.


be carefull space color for my profil is not complete YV12 but CCIR 601 space color. If you want make visual/metric comparison use same space color for all encoder:
- Use "limiter" in your avs script
- desactive "-vf yuvcsp" in mencoder CLI

CCIR 601 done softer pictures but compressibilily is better and quality for low bitrate is better (like as you see). CCE and TMPGEnc can use CCIR 601 space color too ...

Actually Libavcodec done better result than HC, TMPGEnc or CCE for metric ...


Well, psnr computation don' use high CPU ressource. I use actually psnr computation for my personnal quality evaluation of internal mencoder video filter (average quantizer gain, average metric gain ... etc etc). desactive psnr if you want ...


like I say my profil is insame quality profil.

You can use another ME setting if you want like:
- desactived RDO
- Trelli
- lower diamond size
- SAD for cmp
- no chroma search for cmp
- fast or no adaptative bframe

... etc etc etc

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.