[Mplayer-cvslog] CVS: main/libmpcodecs vd_xvid4.c, 1.2, 1.3 FORWARD

[Arpi]

Hi,

i've reviewed the whole thread again, starting with the banned commit.
reminder: it was pure cosmetics, by renaming 2 variables, nothing else.

note: i'm not g1 developer, and no, i did not came back to g1, i just
reply because the offending cvs rule was originally made (and enforced
over years) by me.

> Hi, I received that email from Edouard Gomez, how'd like to explain how

[usual bla bla cutted]

> The only rule my module breaks is rule 4. And that's the only

reminder:

4. Do not change behavior of the program (renaming options etc) without
   first discussing it on the mplayer-dev-eng mailing list. Do not remove
   functionality from the code. Just improve!

wtf? how is rule 4 related to the rejected cosmetics commit???
he renamed the variables (in the code, invisible to users), not the options!

> argument you have to refuse it as is. All the changes do have
> a meaning to me, like eg: making the code similar for both
> transcode/mplayer modules, so i can sync things more easily.

> You consider that being cosmetic, i call that maintainability.
> Are you really wanting to limit user experience with xvid, and
> harden my work for really no good reason but a stupid rule
> that is not even applied to all mplayer code... you do copy
> libavcodec just as is (cosmetic changes or not), i request
> ve_xvid4.c to be treated the exact same way.

please explain this!
IMHO:
- libavcodec is an external lib, which should be copied as-is
to be possible to link static, for better performance and
compatibility (less exported symbols). it is developed outside
mplayer cvs, it is NOT copied to mplayer cvs, and so it is not
different from the mainstream version (like libmpeg2 does), so
rules like 'sync to external source' cannot be applied here.
- ve_xvid4.c is a wrapper written for mplayer, it's mplayer
only (such file or even similar file does not exists in
other projects like transcode or frontends, or am i wrong?)
the only thing this file does, is:
  - describe commandline options in mplayer's config structure
  - convert options from mplayer config to xvid structure
  - convert en/decoding calls between mplayer and xvid codec api
ie. if this file (or similar) exists in other project, it means
that other project has same codec API as mplayer, so it's probably
mplayer itself, as transcode and other players has very different
codec api. or maybe it's an mplayer fork, in the worst case...

so, please explain, why and how should this file be in sync
with any external project or file?
if you can prove, that this file (or a similar one) exists in
a non-mplayer project too, and it's developed outside mplayer
cvs, then your change will be accepted (at least it should be, as
cosmetics changes of loader/* and some other libs coming from
external projects' cvs are accepted).

> So now for my name sake on top of the xvid module file,
> respect my work and accept the patches as they are.

why? because you ask so?

> PS: CC me anwsers because i'm not subscribed to mplayer's lists

then let's subscribe, i never do cc:


A'rpi / MPlayer, Astral & ESP-team

--
MPlayer's new image: happiness & peace & cosmetics & vmiklos