[MPlayer-dev-eng] [PATCH] man page: Where do you want to go tommorow?

[Arpi]

Hi,

> > > 1. eq intensity
> > > I don't know much about *_intensity, but I didn't find them in 
> > > cfg* and now I'm not sure if they exist at all and if the range
> > 
> > they were added by Nick at time of vidix but was removed by me
> > recently as it was not implemented at teh other end (driver side).
> 
> So, I'll remove them from the manpage too? Or is it going to be added soon?
no it won't be added

> > > really is from -1000 to 1000 (from manpage/html docs) and not
> > > from -100 to 100. Also I couldn't set eq settings to -vo xmga
> > > with mplayer (I had to use the device to change them) and they
> > > went from  -128 to 128. IMHO it's a big a mess and nobody is 
> > > sure if eq setting xy is supported for his vo/card...
> > 
> > eq values are -100 .. +100 everywhere, 0 is the 'normal' setting
> 
> ok. But for mga_vid it still is 128 and needs to be changed manually  
> afaik.

you mean the module parameters of teh kernel module mga_vid ?
yes it is, but you can control it using mplayer and then it's -100..100

> > > it. From patch:
> > >     MPG/RM/OGG: 0-31 AVI: 1-99 ASF: 0-127 VOB: 128-159 PCM: 160-191
> > > Is it AC3+PCM, VOB+PCM, just VOB and could those values be 
> > > correct (I got them from some source files, it was ac3 instead 
> > > of vob there)?
> > mpeg/vob has different layers for audio and video, so tehir numbering is
> > independent.
> > 
> > so video is numbered from 0..31
> > mpeg audio layer 1/2/3 (mpeg1, svcd, DV_B_ mpeg2) is numbered 0..31
> 
> ok, but they were already mentioned before.
so?

> > lpcm/ac3/dts audio (VOB / DV_D_ mpeg2) is numbered 128..(128+31)
> > subtitles are numbered 0..31
> 
> >From libmpdemux/open.c:
> int ac3aid = 128
> int mpegaid = 0
> int pcmaid = 160
> 
> See bellow...
forget it, it's used for IFO parsing afair, .so's hack

> > > Is OGG/RM like MPG, like AVI or completely different?
> > like avi and asf
> 
> 2nd try:
> 
> MPG/SUB: 0-31 AVI/OGM: 1-99 ASF/RM: 0-127 AC3/DTS: 128-159 LPCM: 160-191

lcpm vob:
==> Found audio stream: 160

so, you're right... it's 160.. then

anyway i don;t think teh above list has any sense.
users should do -v and see the reporetd track list.
demuxers call teh new_sh_audiovideo which prints the above message (==>
Found audio stream: id)

> > > filters), till end of 3 (controls) and more.  It's also easier 
> > > to maintain the docs this way. IMHO, the html docs should more 
> > > be like an accumulation of guides, donno...  Diego?
> > 
> > agree.
> > maybe we should review tech/ section, move options (like lavc-*, swscaler-*
> > etc) to manpage, and keep only developer files (interfaes, how does the
> > demuxer work, file format details etc) in tech/
> 
> hmm, I actually ment to _base_ the manpage on the tech/* docs.
> Shouldn't it be that the manpage is a subset of the particular 
> tech docs? On the other side it is even better if the developers 
> themself write the actual manpage section (as long as it's 
> "user-readable" ;)

i'm against redundant docs. it just results desync.
the option description parts of tech/* (mainly written by Michael) imho
belongs to teh manpage, even if they are more technical than r=1 users.
but don't forget that mplayer and especially mencoder is for advanced users
(others should use xine or virtualdub with their mouse). and the advanced
users usually want to know the meaning of teh options, in more detail than 2
words per option (which is actually useless).

the tech/* area should kept for topic 'read this if you want to hack the
code but you don't need this if you just want to use it'

> > maybe make a new section in manpage, so you don't haveto mix the detailed
> > explanation of -lavcopts etc to the common options.
> > 
> > like:
> > 
> > LIBAVCODEC options:
> > ... (files from tech/libavc*.txt)
> > 
> > SWSCALER options: 
> > ...
> 
> hmm, I don't like it but maybe/probably you're right. I just hate 
> separated docs and like the way it is now. Also I don't think 
> it's necessary to include all aspects of the options in the 
> manpage (for example chroma skipping in -vop scale), maybe in a 
why? the purpose of the manpage is to describe all options.

> guide section where they are needed. I have a new idea:
i hate the 'docs is separated to 4 parts, guess where is what you're seeking
for' approach. they will read only one, maybe 2 of them (usually html and
faq, sometimes manpage only, sometimes mplayer -h only) but none all.

> Keep it the way it is now and (in future) move all recommend messages
> (use this for this, this is a good choice, this is fast, what to do 
> in which cases, bitrate?,..) to a encoding guide. Maybe with separated
> sections (dvd, vcd (mencvcd), tv, ..., donno).
it's the tutorial.
but i'm talking about the description of -lavcopts etc which imho belongs to
teh manpage rather than tech/*

> > imho manpage should not have big complete examples, it's the job of the
> > tutorial-like docs. manpage may have simple example, like
> > -vop filter[=param[:param2]][,filter2...]
> >    ...
> >    example: 
> >    -vop scale=640:-2,rgb2bgr,pp=0x22
> 
> I more like centralized examples of _basic_ really often 
> used things, they belong in a manpage IMHO as it's the first 
> place someone looks at. Otherwise users have to search them
> in the whole documentation which they probably won't do.
> But I agree for specific long guides (dxr3,dvb,tvout,etc).

imho the real-life examples (how to encode a file etc) should be in the
tutorial, never in the manpage.
if an example demonstrates more than 1 options, then it belongs to the
tutorial rather than an option description.

> > > 4. messages
> > > For me it just looks a bit messy: -quiet, -v (-v), normal 
> > > output, &>/dev/null </dev/null, etc... -quiet should at least 
> > > produce zero output IMHO, now it showed all pp changes with divx4 
> > > (autoq)! -> filled my terminal with messages...
> > 
> > no. -quiet just disables status display, but keep the startup messages.
> > and it's right imho.
> 
> I know, I just would have liked a general interface more than 
> all those variants. And sorry, I have to consider all those pp 
> autoq change outputs (with -quiet!) as a bug (hmm, forgot to report ;).

report it

> > > 5. TODO/some ideas (see 3.)
> > > sw hue,saturation,intensity eq filter?
> > intensity==brightness
> I meant red_intensity etc...
ah, so per-channel brightness/contrast...
afair the current eq filter is yuv-only. it should support packed yuv and
rgb modes (at least 24/32 bpp) too.

> > saturation = contrast of U,V planes (easy to implement)
> > hue = hard to implement and who needs it?
> Can't it be used to inverse colors? (someone wrote about crpyted 
> tv channel who does this)
yes... read this line:

> > the only use of hue is UV swapping, writing a simple U<->V swapper filter is
uv swap will invert colors...

> > easier (using fourcc trick so it doesn't slow things down)
> > 
> > > Write down patch rule to separate cosmetics/spellcheck and real
> > >   changes, for general syntax changes: Write down procedure 
> > >   ('>' -> '&gt;').
> > huh?
> 
> IMHO the patch rules should include one which say that cosmetics 
> in the docs are allowed as long as they are clearly separated by 
> the real changes. The example bellow replaced all '>' with the 
> html version '&gt;' to avoid a broken html. If you translate, 
> it's easier to just follow the rules of the cvs comment than 
> browsing all changes and find it out yourself.

agree. fix it :)

> > > pre7 today? ;)
> > with the above changes included :)

go go we've only 2.5 hours left :)

> > > Damn, I wanted to write a one line mail, now I've got over 50. 
> > no. it's just one line, but that shitty mailer wrapped it :)
> :)
> 
> I just remember the question I wrote the first mail for (I didn't 
> even include it ;)):
> 
> Where is the "-value w/h = original+value" vop parameter 
huh?

> description from? I haven't found sthg like this in vop.txt and 
> now I'm not sure if it applies to all w/h params, if it doesn't 
> exist of if it's only for scale.

i don't even understand what are you talking about :)



A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu