Minimum syntax for DVD compatibility, simplified :)

This will be a simple to use command line, quality settings should be put on settings.ini (they're not set in this example), supports fractional framerates and interlaced encodes, and has all the needed parameters for DVD compatibility :)

Autoaspect will be default is you don't define aspect on the command-line.


Bilu

Posted our work at Doom9 ;)

http://forum.doom9.org/showthread.php?s=&threadid=71991


Bilu

Link to search on the MPlayer mailing lists, add to Favorites :)


Bilu

Hi bilu, is it really necessary ildct=1 and ilme=1 for every encode, or just for interlaced sources?. And if we encode in PAL, without fractional framerate, do we still need vstrict=-1?.
I don't understand this completely. If I frameserve to mencoder through an avs script, and in the script I already crop/resize/addborders/letterbox, do I need to include autoaspect?. What will it do then?. I've not used it till now, and I think my output got correct aspect, even with 16:9 encodes.
Nice idea Settings.ini :wink: , do we have to make a separate file named settings.ini, isn't it?. And we have to store it in mplayer directory, with codecs.conf, don't we?.

...keep us informed on feedback you all get at forum9, to improve our KDVD encodings :D

No need for none of those settings on PAL progressive :)
No need for none of those settings on Avisynth sources ;)
Store it wherever you want, provided that you mention it in -include .
Well, not really tested since I put it on Mencoder's directory, but makes sense :)


Bilu

About quality tests: these should be made with vqscale=2, so that rate control doesn't mess with filesizes.


Bilu

Well friend, your example was correct anyway, since in your command-line you used a vob file as a source
Again, you're right. My questions where just to be sure I understood your way. :D

Quality test results - fixed quantizer

11.482.354 default.m2v
11.312.817 mbd2.m2v
11.291.988 mbd2_mv0.m2v
10.347.085 mbd2_mv0_vle_vce.m2v
9.960.207 trell.m2v
9.539.090 all.m2v

Tests made using vqscale=2. Since these are rate-distortion parameters the smaller the file gets the better the parameters are.

And trellis quantization is a clear winner: mbd=2,mv0, vcelim=7 and vlelim=-4 together couldn't get even near trellis alone :)

All the *_mask parameters work around quantization, so they give absolutely no result here. Believe me, I tested ;)

Also trellis-related parameters beside trell were no good here: cbp works around quantization, qprd crashes, qns is slow as hell even with the rest as default :?

alt increases filesize.

Filters
====
8.656.030 hqdn3d.m2v

This denoiser alone gives better results even then trellis and it's faster :)


Bilu

Hi digitall,

as far as -include goes (and your .ini settings file) as long as you point to
it in your .BAT file, you can pretty much store your "options config" file
anywheres :) I've ben using this technique for the last week now (I had
posted how to write an .INI "options config" file last week, in my other
thread, which I changed for obvious reasons, the SUBJ title for w98/se/me :wink:

* MEncoder under W98 / SE / ME - (work in progress) ..

Later on, I'll be adding instructions on how to read in vdub --> avisynth
script, for even more flexibility :mrgreen: (I was debuggin if over the weekend
to be sure it worked well) and I know RDS was on my tail about it :wink:
sorry rds, I've ben brain-storming other things, and I couldn't post sooner.
Anyways..

Now, W98/SE/ME do not have to suffer anymores (me for instance) and can
join in the fun :mrgreen:

Well, I gotta get going for an apointment now, and I'm late. If I forget to
take care of the above, just remind me later on.. thanks.

Cheers guys,
-vhelp

Sorry if making too much questions :oops: , but I'm trying to learn how to tweak this encoder. I understood if you use vqscale=2 (just for test purpose) and leave the rest to default (what default?. vrc_maxrate=9800, vrc_minrate=300, vrc_but_size=1835, vbitrate=...) this fixes quantizer to 2 (just Iframes quantizer, P and B frames will receive more, if you use B frames). So the rest of parameters you use just can have effect on bitrate and how quantitation is applied, isn't it? (I don't know a single word on mpeg encoding, that's why I ask things that maybe so clear to everybody, be patient). But what I didn't understand is why the better the parameters are (in terms of quality) the smaller the file will get. Could you explain me how. I thought that at fixed quantizer, the encoder played with bitrate to compress the film (the higher the better, and the bigger file size). But I see I was wrong :(

Yes, I like trellis a lot. But even if mbd and mv0 aren't better, can't we make use of all of them?. And I don't like the results I get with vcelim and vlelim with these parameters, seems to me that colours get poorer, more plain

Sorry, lost again. I thought trellis was a way to apply quantitation, and not a denoiser. Can we then substitute trellis with hqdn3d?. What about your source, did it need a denoiser, doesn't hqdn3d make look the film too smooth? (I didn't test it).

@vhelp
thanx for your advises. I would also put in settings.ini the Notch inter/intra matrix. I'm willing totake a look at your GUI for mencoder friend.

@all,
again, thank you for being patient :?

EDIT: BTW bilu, did you take a look at your tests in bitrate viewer?, how did they perform?. And did you a visual comparison?, are the smaller files still "good looking"?.

From http://www.bretl.com/mpeghtml/mpeg2vc1.HTM :
In english, this means that using rate-distortion settings like trellis to find the better macroblocks will make the error prediction even smaller.
And the better the macroblock gets predicted, the smaller the filesize will be :)
That's why I made this tests aiming at a fixed quantizer, so they wouldn't be affected by rate control.

Of course you can ;) About vlelim and vcelim, plainer colours are more easily compressed. It's the only reason why you would use it.

Not quite a replacement, of course. Trellis keeps all the quality of the movie. But if you like this denoiser output, then you'll have faster and more efficient compression ;)

In terms of Bitrate Viewer, that's how I learned that the mask parameters work through quantization :)
With lumi_mask=0.3 and dark_mask=0.3 this file got as small as 2Mb when not using fixed quantizer.
On Bitrate Viewer it showed a lot of quantizers 6 and 7 and still looked pretty :)
But when using fixed quantizer they didn't work at all.

This leaves us with a second conclusion: if you want to use mask parameters on a 2-pass encode, use them only on 2nd pass, and with naq.
Because they wouldn't have any effect at all during the 1st pass.And naq will allways help trying to keep things within average bitrate.

Visually all files looked good. And you really have to look at the output of this denoiser, it looks very nice to me ;)


Bilu

Quality test results - variable quantizer

Well, since I liked the denoiser output so much I didn't made the test with trellis related parameters like cbp or qns. :twisted:

But I'll show you how to test: don't use naq. If it visually looks good and got much smaller then it's a good parameter :)

The winner here is scplx_mask=0.3 . It provided much better results than lumi_mask or dark_mask (tested on a panning trees scene, a bit dark) in terms of filesize. Tried scplx_mask=0.5 , but it's way too much and gets blocky.

Of course that when doing real encodes we should use naq. It will try to keep the average bitrate so that encoding filesize is still predictable.

Bilu

My settings for 1-pass VBR encodes

NOTE: You can notice that I've disabled B-frames and limited the maximum quantizer to 10. That's because I've tested with a very bitrate-demanding sample from an interlaced anime. The anime is done like this:

A B C
A AC C

Where A,B and C are normal fields and AC is a blend from the previous and next frame. So periodically you have an interlace frame because one of the fields is blended. Try to imagine bitrate peaks like 10080 kbps with vqscale=2. And blended fields. And high-action anime. 8O

When trying to do a VBR encode at 3000 kbps I got lots of lose blocks in one scene. I realized then that it was an high-bitrate scene and B-frame compression was showing more info from the next field than the current one in some macroblocks.Those lose blocks looked like coming from the next frame. That in a high-action, blended field, interlaced anime is a complete disaster :roll:

When I disabled B-frames the problem stopped.
Probably that's the reason why this parameter exists:
But that parameter is for 2-pass encodes only.
So this was the best solution I came up with so far.

Since trell also works with macroblocks, I'm testing trell with vmax_b_frames=2 with the same denoiser filter, just to see if trell can help with B-frames.

EDIT: It didn't help at all. So I'll use no B-frames in 1-pass encodes and try vb_strategy=1 in 2-pass encodes. If the bitrate misprediction caused by this parameter can't be compensated by the 2-pass algorithm then I'll abandon B-frames there as well.


Bilu

Did you try to adjust B frames quantitation through offset?. Although, from your explanation of the problem (B frames encoding info from next field), I'm afraid it won't solve it.
You dropped the strategy employing vrc_maxrate=vbitrate... just for this test?. It works nice for me, but I still don't know if it makes file prediction impossible to be done... :?:
Why not using trell?, is it because you like more the denoiser?.
Limiting vqmax and mbqmax, how does bitrate raise in your bitrate demanding test?, does it still respect vrc_maxrate?
I'm trying to figure out some basic parameters (applyable in majority of encodings), and will try to select a set of parameters to apply in specific situations (bitrate demanding film, dark film, slow motion film,...). But still stuck in basic parameters.
Also, already started to try to encode SKVCD with mencoder (maxrate 2500, avg vbitrate with formula), to substitute KVCD encodings with TMPGEnc. But get lots of blocks in fast scenes (well still beging, just 1 encode).

Tested mencoder for KVCD. I tried maxrate=2800, vbitrate=1211 (trying to fit a film on 1 CD), but got lots of blocks in transitions from slow to high action (in bitrate viewer there was a sharp raise in Q value at 29, and sharply down).
I tweaked a bit, lowering vqmax an mbqmax to 10, but still the same. Maxbitrate was respected more or less (max 3100 in BV), file size slightly higher. Tried again raising vbblur at 0.3 to avoid those sharp changes in Q value, to see if improved something, but didn't get better.
Still testing. I'll try not to use trellis...

vrc_maxrate=vbitrate only works good for high-bitrates, that's what it was designed for.
About file size predition, still don't know since I've been working with very small samples ( VOBs < 50 MB)
Trell is slower and doesn't bring as much compression as denoiser, but keeps all the details.
But since I like this denoiser output I don't have the need for trellis to encode on a PIII-500 :D

Limiting vqmax and mbqmax forces the 1-pass VBR algorithm to compress more the scenes that are less bitrate-demanding to keep the average.
It respects the maxrate, but it isn't able to keep the average on small samples like the ones I'm testing, which is normal.
I have to start making tests with a minimum half movie to make sure about file size prediction.

Meanwhile I tested that scene again without using naq. As I knew, quantizers got raised since it's not trying to keep an avg bitrate through the naq parameter.
But the 1-pass VBR algorithm still tries to keep that average so the more bitrate-demanding scenes have more room to grow and overall quality gets much better.
Still I have to tune it decreasing scplx_mask=0.3 to 0.2 or 0.1, because although overall quality got much better, it's still a bit too blocky.

I think that naq is more appropriate for 1-pass CBR than 1-pass VBR.
Don't know yet about 2-pass VBR, probably is better to use it as well.
But it seems better to have a smaller mask than to use naq.


Bilu

Good news: problem was not B-frames, but the denoiser settings in the settings.ini file :)

I tried before
vf=hqdn3d=1

Now replaced them with the default values
vf=hqdn3d=4:3:6

And everything works like a charm ;)

EDIT:Wrong again, tried lower bitrates and the B-frame shit comes back :evil:

Bilu

Hi bilu,
I don't know if you feel the same, but it seems to me that less people is posting in this forum... :( Don't say people is not testing, neither they dropped mencoder/ffvfw, it's just no posts.
I'm glad you solved your ghosting problem.
I'm still struggling with mencoder settings to get rid off blocks in low bitrate (as low as max 2800 avg 1211). I'll try without naq as you did. But there's a scene (film: Spirit, Disney, animation) where it's snowing, and snow becomes lots of blocks. I'm begining to feel lost.
But you're using max 9800 and avg 3000, and maybe that can be considered high bitrate. You could give it a try (maybe you already did). The tests I did, in fast action and complex scenes, with vbitrate=vrc_maxrate=9800, avg bitrate still was about 2200 (even below your avg 3000)
I didn't know that was the effect. I mean, I thought that in high bitrate scenes, when encoder finds that bitrate will go over maxrate, it raises quantizer in order to keep bitrate about maxrate. But if quantizer gets also to vqmax, and bitrate about maxrate, what does the encoder then?. I ask because in my SKVCD tests it happens that bitrate is at 3000 (maxrate 2800), quantizer at 15 (vqmax=15), and it mantains those values for a while. And I believe that happens in my snow-blocking scenes... And for less bitrate demanding scenes, I thought that encoder just lowered bitrate and mantained quantization... just a believe, I don't really know how it works.
I'll give it a try in my SKVCD blocky test :wink:
BTW, did you give notch-matrix a try?. You could set it in ypur settings.ini file. You'll see that file size decrease, without loosing quality :)
Well friend, wait your feedback while making tests... tests... tests... :roll:

Sad to read that :?

One parameter to rule them all 8)

preme=2

and the B-frame problem is no more :wink:

EDIT: Wrong again :( in a bigger sample the problem showed again.
Still this parameters is really good :)

Bilu