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

Hi bilu, now that I see you around here :twisted: ,
preme=2 already in my command, even I don't really know what I am supposed to notice in the file... 8)
Did you try the suggestions I did (BTW, just your suggestions): try again with vrc_maxrate=vbitrate, and try notch-matrix...
Tell me how does it work with your tests.

I already tried removing naq from my KSVCD command: it was a disaster, because I left scplx_mask at 0.5. File dimished to half!(from 13 Mb to 6.6 Mb), but looked horrible. I think avg bitrate came down to 900 and avgQ raised a lot...
I then changed scplx_mask to 0.3, and file size got 9 Mb and image improved, but far more blocks than with naq. I will still try scplx_mask=0.2 or 0.1, but I'm afraid I'll be using naq again, because with SVCD compliant (at least for my standalone) bitrates, quality really gets worse without it.

@ digitall,

Well, I didn't drop any of them, I'm still testing some MEncoder stuff out, but
for the most part, I took a step back from my GUI of MEn because it's really
a big/major job, when you realize the many parameters it requires, and even
finding the right combo of them to use prove harder - every day there is a
new finding w/ a given param (you drop it, or you keep it, or you mix yet,
another param w/ what you thought was the right set of params to use)
It can be mind-boggling. And, it was for me. So, I took a step back, and
said, "hay, there's already a 'basic' GUI out there (or two)) so I say, take
it easy to myself :lol: ..Plus, I'm going through some really tough times
w/ my job and it's waring me down. So, it sort of puts a damper on my
excitement here and all these projects. Well, thats my excuse regarding your
comment above.
And, I'm sorry if that upsets anyone here, but really, I'm soo distrought
w/ my other personal life matters that some things just aren't as much fun as
they can be (usually) w/ all this nonsense going on in my life. Anyways..

Cheers,
-vhelp

vbitrate=vrc_minrate, limited quantizers, vqblur=0 and scplx_mask play a big role for the filesize vs quality here, and preme=2 helps a lot.

On my tests so far it's fast (7fps on a PIII-500), clean, and makes great filesizes. I'm not aiming at bitrates anymore with 1-pass, but at the best filesizes possible maintaining a quite acceptable quality.

Of course this is my opinion: I don't like blocks or blurs, but I like a clean and compressible image. If you think it's too clean and don't mind a bigger filesize, reduce scplx_mask from 0.3 to 0.1 or remove it.

Haven't tried with the Notch matrix yet.
I'd like to see some feedback from this on your sources.

About error messages like:
"Error in stream: PTS earlier than SCR!"
"Error in stream: PTS to SCR delay 0 is too little!"

See this mail from the mailing list:
http://www1.mplayerhq.hu/pipermail/m...ry/042750.html

Since we demux the MPG file the container problems won't affect us.
VBV buffer size is still respected :)

I'll look at your posts now :)

Bilu

@vhelp
Hi v, very happy :D to see you around here. I see you still come to visit us and
read our slooow improvements. Also happy to know that you keep on working with
mencoder, since your help is very apreciated.
Of course, NOT. Never can get upset with friends. I know this is a hobby for almost all of us,
and I even thought sometime to drop it because of little time, and just focus on keep making
backups as until now. No need of sorry... its's just I missed friends with us (Rui, Vinicius,
Amenophis, Incredible, Dialhot, Kwag, and many others...)

@bilu,
notch-matrix: it slows a little the encoding. But lowers max bitrates and file sizes. And keeps quality. I really recommend it. Give it a try. I encoded the same file and got smaller size, and visually didn't notice the difference, no blocks.
Did you try the vrc_maxrate=vbitrate strategy?. If you keep maxrate at 9800 I guess you're aiming to make DVD mpeg2 file, so you have bits to spare. You could test this and compare with you're new vrc_minrate=vbitrate. The last one may be useful with my problems with SKVCD, I'll try.
I see you keep without naq (this really helps with file size, but image gets really worse. Maybe not so worse for you because you use a denoiser and don't use trellis, but not sure since the denoiser works before encoding and creating these ugly blocks...), this really helps with file sizes, but in my low bitrates tests really appear too much blocks without it.
You also dropped vrc:eq=tex, didn't you? (or does vqcomp the same effect?). It's not I don't want to use hqdn3d, I encode through avisynth script, and my source is already filtered and resized (BTW, I see you don't do any resize, just autoaspect). If I encoded directly from vob, I would use it.
And I didn't understand:
Again, if you try to make DVD, there's no problem with high bitrates and big file sizes, you have a lot media to fill. Did you try to encode a whole film?, how many minutes long the film, and what filesize?. If you want later to fit 2 or 3 DVD in a media, you can lower vrc_maxrate to 5000, and maybe play with other settings. And of course notch-matrix will help a lot.
I think we're working in different ways. I look for two kind of settings:
- one for KDVD, 2 (or 3 in some cases) films in a DVD-R media. maximum quality possible, high bitrates, low quantizers. I think I got it (I'll post my command, but I think you already know it), with notch-matrix and little filtering in the script. I have to find the way to make it faster...
- other for SKVCD, for backups of less intersting films (my son animations), to substitute (if possible) the KVCD way I was doing, with maxrate 3000 and average to fit film in media. Less quality, but I still work on it, because of lots of blocks that make it look worse than KVCD. I'm afraid I won't get it.
--> and what about you?. In your last post I understood you aim for great filesizes (the minimum possible, I guess you mean) keeping quality... difficult I'm afraid, if also lowering bitrates. Did I understand your point?
BTW: very nice link. I'm less worried now about PTS SCR's, but I think this slows down the encoding.
Go back to tests

morning all.

@ digitall..

Just so long as you all know/understand, that I'm really pooped w/ my issues
with work. And, they tend to take it's toll on (here and other forums) but I
try to slip in every so often, for a pump-up or something. I'll continue to do research as I can. Anyways..

I did some test encodes w/ CCE v2.50 and MEn, although MEn is (IMO) ben
giving pretty results, it's not measuring up to cce's quality. In MEn, I do see
lots of DCT (I hope I'm refereing to those square blocks correctly guys) in
solid areas (was using "Dogma" for some tests) using 3 pass. But, most everything
else seems to be pretty good. I must do a CCE vs. TMPG vs. MEN soon.

I'm wondering if the reason for our poor tests results are due to the fact that
everyone seems to be trying to aim for 1 CD results, and that because of
this, we are finding it harder to reach our destination :?:
.
.
I think that maybe we should not be trying for tiny bitrates just yet, but rather
get MEn within an area of reasonable quality. I guess I seem to be the only
one not shooting for 1 CD results. Then again, I'm still stumped about the
overall best "bitrate" settings for a given project. but, I'm still researching :roll:

@ all,

It seems that I did not post my instruction on "option config" at my other
thread:
* MEncoder under W98 / SE / ME - (work in progress) ..

My applogies. Now I have to retype it again, but since I usually type every
thing in notepade and save it, I think I might be able to post it soone :lol:
So, keep an eye out for this - W98/SE/ME users :mrgreen:

One more thing about MEn param settings. There's lots of them!! Too many!!
I'm wondering if there is a "general" or mininal required sets of params to
use in a given project to use as a "starting point" for all encoding projects.
If there is such, (and of which we can add on later, "advanced" settigings)
this would/could help us all out, in finalizing a set of param string layouts
for:

* Bitrate and
* Quality

entries.

In my GUI, I want to set up a TAB layout (I have started on a few already)
and I'd like to have one just for Bitrates. If we can consort w/ a standard
set of param strings for bitrate control/settings, that would be a great step
in MEncoder process. Then, we can have another TAB for Quality. I've
got both TABs setup, but I need to know which ones you guys would prefer
on in each TAB. This way, we could test, in a more organized mannor.
Then, later, other advance items can be added to these tabs, or a new tab
could be added for special features or quality control or whatever.

So far, I have the following tab layout for:
* Bitrate
* Quality
* Filtering

But, if this all sounds not so interesting, thats ok too. I'm not gonna rush
this.

-vhelp

@ vhelp,
very nice idea, that of basic settings. Maybe taking a look to this thread you could come to a conclusion... because I still don't feel capable to decide what settings to use. And, as you see, all depends where do we put the strength on: for KDVD I don't mind to spare bits and make use of higher settings, but bilu seems to prefer the better quality possible in the lesser file size.
Some minimum settings would be:
vrc_minrate=300
vrc_maxrate=9800 (in KDVD case)
intra and inter notch matrix (sorry you can't use it) --> don't know if bilu tested it, for me is nice
vrc_buf_size=1835 (VBV for KDVD)
vmax_b_frames=2 (don't know if we all agree on this)
vqblur=0
vrc_eq=tex
keyint=15 (PAL) or 18 (NTSC)
preme=2 (following bilu advice: don't really know what is useful for --> too lazy to read man_page :oops: )
vqsquish=1 (agree?)
mv0 (agreement?)

... and from here on, don't know if we can come to an agreement. With high bitrates (I use vbitrate=vrc_maxrate strategy) I also use trellis (and cbp), and naq (with scplx_mask=0.3-0.5). And to change file size (still didn't dare to make prediction...) I play with b qfactor and qoffset, vqmax and mbqmax, vbitrate, scplx_mask value,... Too much still to do, at least for me.

And this is the case for KDVD (the way I see it, easier). If we change to SKVCD (I don't think it worth it to try MPEG1, but didn't test it) to try to fit a film on a CD,... buff, I don't find the way. I did lots of tests, and get nice filesizes, but don't like the quality I get, even with MA script and notch-matrix. And if I cannot get the same quality as with KVCD and TMPGEnc, I don't see the point to change to mencoder for storing on CD (other thing is KDVD). But don't misunderstand me: keep on test and trying it, but I don't find the way to improve the quality.
Hope this help you, but I'm sure that bilu (or anybody else) can give you better hints. :wink:

Progress so far:

My mode posted in the last post has better quality and less file size :!: without B-frames than with B-frames :twisted:

Still I had to go back on investigations: I found out that despite supporting interlaced encodes, mencoder is developed for monitors rather than for TVs and whenever it finds out Telecine sources it does IVTC even if you don't want it to.

I've seen developers calling Telecine "horribly evil" and saying "why not buy a projector or progressive TV" ... :evil:

On a post I've seen a Linux Dxr3 complaining about it since automatic IVTC was consuming CPU without need, since it's output supported interlaced encodes. Some guy suggested him to force input framerate with -fps 29.97, believing that stopping the framerate detection would also stop the MPEG-2 flag detection. It doesn't.

Still checking alternatives: first will be posting this on the mailing list.

Of course it shouldn't be a problem using AVisynth sources since they don't export MPEG-2 flags, but still will have to check since it can detect hard-telecine and do the same.

The impact of this procedure is that you can't do NTSC encodes with using a pullup 3rd party tool to do 23.976 -> 29.97. And that you CAN'T do mixed 30/24 (30 fps progressive + 24to30 telecined) sources.

The only hope may be forking Mencoder and modify the behaviour with MPEG-2 RFF flags, since this seems more like an attitude problem than a real problem. :evil:

EDIT: http://www1.mplayerhq.hu/pipermail/m...ry/030162.html


Bilu

If I remember well, the change in your last post was vbitrate=vrc_minrate=300, isn't it?. I tested it with my low bitrate SKVCD encodings and got small filesize, and quality more homogeneus, but with blocks all over it :( . For 1 CD encodings, I find KVCD encoded through TMPGEnc better. Anyway, I still have to test it with no b-frames and see if my player "likes" it. May no b'frames is the key.

Related to the rest of your post, I cannot help you with NTSC and interlaced material.

What do you think about minimal settings I posted to answer vhelp?.

And what am I doing wrong with my SKVCD tests?, can you give me any feedback?

Cheers :wink:

My settings are my opinion, at least for now.
If you find it blocky with these settings (no B-frames at all, you ***DON'T HAVE*** to use them) try reducing scplx_mask=0.3 to 0.2 or 0.1 .

I only found a small part in a dark stream where I think it could get better if I reduce scplx_mask, but haven't tested yet.

I'm pretty satisfied with the rest of my settings and will try remove some parameters just to check if I'm not using too much stuff :)

Right now my priority is solve this Telecine problem, which may mean doing a fork of Mencoder if necessary. I posted a link about it on my post above.

Cheers,
Bilu

I've reported the Telecine problem on Mplayer's mailing list.

You can check it anytime at:
http://news.gmane.org/gmane.comp.video.mplayer.user

Thread is called "Telecine output - needed for NTSC DVD encoding"

Status so far:
Have been suggested to try -vf softpulldown and ildct.
That doesn't work and I've shown that all that softpulldown does is cutting the first field from the first frame, and the field order gets reversed. And this is done over the IVTCed source, so it doesn't even avoid IVTC.


Bilu

-vf yuvcsp -> Clamps YUV color values to the CCIR 601 range without doing real conversion.

This is good for TV outputs. Like unixfs pointed here:
http://forum.doom9.org/showthread.php?s=&threadid=71991

and as you can see on Vmesquita's CVS build man page, or here:

http://www1.mplayerhq.hu/pipermail/m...er/017612.html


Bilu

NTSC Problem solved

http://article.gmane.org/gmane.comp....yer.user/27180

My NTSC settings now are like this:
One important thing to notice is that there is no -vf switches in the settings.ini file now.

That's because I'm using the same settings.ini file for PAL and NTSC encodes, and the -vf filters in this file ***ALLWAYS RUN BEFORE*** the -vf settings in the command line.

So what I was doing wrong was setting -vf softpulldown in the command line and running a denoiser in the -include file, because the denoiser was running before softpulldown.

I'm happy :D

EDIT: Now I'll have to tune the denoiser (probably remove any temporal influence) because the duplicates make motion a bit jerky.


Bilu

New compile, CVS dated today
====================

Main reason to do it: use -of rawvideo instead of -of mpeg, you can do the M2V directly! No need to demux ;)

http://clientes.netvisao.pt/bilu/bru...r20040310a.zip

Done with MinGW, including an HTML version of the man page ;)
Codecs.conf is built-in (already was in VMesquita's, look at the output) so you don't need any more files.

Compiled with this flags: --enable-largefiles --enable-runtime-cpudetection --enable-static --with-codecsdir=D:/mingw/projects/mplayer/codecs

I think the --enable-largefiles enables you to deal with AVI >2GB, still don't know if it can affect M2V output


Bilu

This is great Bilu! :D 8)

Thanx bilu,
did you do the compilation?, is there any change in libavcodec, or shares the same like vmesquita's?.

BTW, I didn't forget about you all. Doing lotssss :roll: of tests (well, not that much, but compared with the spare time I have, believe me if I say they are lotsss). I'll post my results soon.

Thank you again, since you're also very busy :wink: (I followed your posts here and at doom9)

Source
====
You can find the latest daily snapshot tarball of the MPlayer+libavcodec CVS repository at
http://www1.mplayerhq.hu/MPlayer/cvs...urrent.tar.bz2

MinGW install
========

Download MSYS-1.0.9 and MinGW-3.1.0-1.exe at

http://prdownloads.sf.net/mingw/MSYS-1.0.9.exe?download
http://prdownloads.sf.net/mingw/MinG...1.exe?download

Install MinGW first, and then MSYS and tell the MSYS postinstall that MinGW is installed.

Then decompress this http://www.videolan.org/vlc/dx7headers.tgz into the /mingw/include/

Any doubts look here: http://www.mplayerhq.hu/DOCS/HTML/en/windows.html

Compiling
======

Run MSYS, it opens a terminal.

BASIC UNIX knowledge:

CD works like in DOS or Windows.
LS is the same as DIR.

Go to the Mplayer source directory (paths like d:/mingw/mplayer/, not d:\mingw\mplayer\) and do:

./configure --enable-largefiles --enable-runtime-cpudetection --enable-static --with-codecsdir=D:/mingw/projects/mplayer/codecs

or whatever your Windows codecs directory is. Then run

make

It will compile. Last part:

make install

And it's done :)

Files will be a bit spread on the middle of the Mplayer source, but you'll see an Mencoder.exe there ;)


Cheers,
Bilu

Actually, it's :arrow: cd /d/mingw/mplayer/

Thanks for the compile bilu :)

-kwag

Thanx again bilu,
nice explanation, don't know if I'll dare to try it, but you explained clearly;
very kind of you to share with us your compilation,
you're a generous man :wink: .

Kwag, thank you for the tip.
Nice to see you visit us, what do you think of this all? :)

EDIT: the link http://www.videolan.org/vlc/dx7headers.tgz is not working now.
I found the dx7headers.tgz file at: http://ftp.lug.udel.edu/MPlayer/rele...-beta/contrib/
Hope is the correct one.

Grande Bruno :!:
Thanks buddy.
Now we can remove the bbdmux step to shorten the whole process :)
I'm currently working with mencoder4win32 and HybridFupp script.
I have 3 tests until now with Hybrid vs MA script and I have to say that Hybrid is unbielivably but
also marginally faster than MA and the average output quality is also
somehow slightly better than MA.
Also if you have a slow PC and use MA you will notice how much the fps drops on very dark
scenes like on the intro of a movie.Sometimes on my PC I get to 1 fps...
HybridFupp doesn't have that problem at all :)
I know kwag is not very disapointed with this outcome but I feel strange when I write these comparison...
My current goal is to fully understand the method/mechanism of mencoder so I can predict a file size.
I really haven't understood how to do that yet :roll:
Then I would update the newbie guide with this new stuff.
Hope someone can give me a hand.
Cheers

It is :)

If you look here http://www.mplayerhq.hu/DOCS/HTML/en/windows.html
you'll see it works both ways :) I did it like I posted and it worked.

Bilu