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

[Jonas Jermann]

On Tue, Aug 27, 2002 at 09:57:44PM +0200, Arpi wrote:
> > > > 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
ok

> > > > 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 somehow didn't work for me, probably (90%) my fault (I'm too 
lazy to analyze it as I don't need it).

> > > > 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?
Nothing, sorry: The explanation was very helpfull. :)
 
> > > 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)

Agree. It was a request by some users and I was just interested 
how the situation was...
 
> > > > 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).

After some thoughts -> agree :)

> 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'
Agree.
 
> > > 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.
Ouff, some options need really _long_ descriptions. I always 
thought my patch made them too long ;)
scale is the only one which doesn't explain _everything_ at the 
moment -> see last question, [:c[:p]], and some others...
 
> > 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.
ok, 100% agree on this issue.

> > 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/*
I know, agree. But no new sections IMHO.
 
> > > 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.
hmm, I partly agree: Sometimes it's good imho to have a basic 
working example for sthg (tv recording/whatever)

If there will be a good encoding guide, some/many/most of the mencoder  
examples should go there. IMHO the actual "guide" is not 
detailed enough, for example: it should include a guide to 
lavcoptions (b frames, bitrate, all others etc).

> > > > 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

Too lazy, I don't use divx4 very often anyway...
 
> > > > 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.
-> IDEAS list ;)

> > > 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 :)
If I find time...

> > > > pre7 today? ;)
> > > with the above changes included :)
> 
> go go we've only 2.5 hours left :)
of coouurse :)

> > 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?

hmm, ok: in the vop documentation you'll find a parameters 
section. There's a description about w,h values which can be 
(value,0,-1 or _-value_). The description of _-value_ of w,h
is: "original+value".

> > 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 :)

I understand the description but I didn't find it in the 
tech/vop.txt and was not sure if it applies to all w/h params 
(crop, rectangle, expand, scale), if it is possible to used it 
as described at all or if it's only used for -vop scale scale. 

Please tell me what I need to change in the manual till it's 
commitable...


Regards
    Jonas