[MEncoder-users] Re: Re: Re: Re: Re: Tutorial?

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
The Wanderer 
<mencoder-users at mplayerhq.hu>], who wrote in article <452831C2.4090901 at comcast.net>:
> > There is nothing "obvious" with software (unless one knows it is an
> > extremely dumb software).
> 
> This isn't a matter of software, though - it's a matter of simple "a + b
> + c" concepts.
> 
> There *is no such thing* as the "total bitrate" of the produced file -

Yeah, right.  Next time you will tell me that there is no such thing
as the total size of produced size too, right?  1/4 ;-)

Hint: if you do not understand these concepts, think about streaming video.

> It is not the domain of the MPlayer documentation (at least not the man
> page) to explain such basic ideas in more than the most general of
> terms, if indeed at all. If people really don't understand these things
> from the information which *is* provided, then they need to educate
> themselves elsewhere before they can make meaningful use of *any* video
> encoder - not just MEncoder.

Feel free to make all the wonderful effort which went into mencoder to
vane, since the documentation is intentionally made pretty useless.

> The MEncoder documentation should not need to explain basic,
> field-universal terminology. Again, if someone does not understand those
> basics already, they should not be trying to use any encoding program at
> all.

On one hand, it looks like you live in a different universe than all
the rest of people...  Let me assure you: grand-grandmothers around
the world (which have difficulty in understanding why the mouse has
more than one button) use video encoding programs right and left.

On the other hand, bitrate of a audio+video stream IS a "basic,
field-universal terminology".

On the gripping hand, please keep things in perspective.  Let me
recall that this subthread of the discussion stems from the following
ambiguity: documentation of `bitrate' option of `xvidencopts' does not
specify whether it is video bitrate, or total bitrate.

To fix it is to add one or two words.  Do you feel your invectives on
"explain basic ... terminology" are in place in discussion of such a
change?

> > E.g., mencoder could inform XviD of the current offset into the
> > output file, and XVID could take this into account when writing its
> > log.
> 
> ...huh? I don't even understand what you're suggesting. Or if I do, I
> don't see how it would relate to determining the overall
> size/bitrate/what-have-you of the output file.

If you do not understand, ask questions.

E.g., one possible implementation of total_bitrate option to XviD:
make another entry point into XviD:

  void xvid_remember_current_offset(offset_t c_offset);

Then call it (during pass=1) before start of encoding, and after start
of encoding.  XviD knows how much data it provided, so can subtract it
and take notice of the "overhead" of the other components of the
stream; so it will be able to write them down to take into account on
the second pass.

To implement max_total_bitrate, one would need to call it more often,
so XviD knows about the "overhead" bitrate on smaller timescale.

> If you think that this is a possible valid interpretation, then I really
> do doubt that you have even a basic understanding of the concepts
> involved.

Let's look at our discussion from a bird fly perspective.  I ask some
questions, and get answers like "you are just a useless hopeless moron".

On the other hand, it is YOU who writes "I haven't been able to THIS"
and "I haven't been able to THAT" - about absolutely trivial matters.
I suspect that you DO know ways more about video than myself, but I
definitely can't tell this from your postings in this thread...

So could you please refrain from "you are just a useless hopeless
moron" arguments in the future?  Are you ABSOLUTELY sure that I'm as
stupid as you imply this?

Thanks,
Ilya