[MPlayer-dev-eng] XviD 1.1.x support

[Guillaume POIRIER]

Hi,
Le jeu 30/09/2004 à 23:29, Reimar Döffinger a écrit :
> > Ok, I'm gonna first commit a patch that features that cosmetics that, I
> > agree, don't change anything besides readability, but have to be done in
> > order to have this front-end in sync with Edouard's.
> 
> Is there a chance of him getting his frontend a bit more in sync with 
> ours? ;-)

I see the smiley at the end of your sentence... But just so that we do
talk about the same Edouard, here's what he wrote some days ago (Sat, 25
Sep 2004):
> > I haven't seen that rule written in stone anywhere, I doubt patches
> > for it would be rejected.
> 
> They've been rejected, so now we end up with mencoder users having to
> tune xvid module options to catch up with the quality provided by
> default values on the win32 frontend or even the transcode module.
> 
> Same goes for lot of little things i had to discard from the xvid4
> module before he got accepted by mplayers' commiters, where most
> refusing reasons were just "we have that behavior with xvid 0.9, so
> xvid
> 1.0 should behave the same". To me that was clearly saying something
> like: "guy you worked well on xvid 1.0, but let's face it, our users
> will have no benefit from all the new stuff because we choose to stall
> default behavior" *sigh*.
> 
> I just decided to continue improving the module separately so i'm not
> bounded by mplayer commit rules. If someonee wants to merge changes
> into mplayer, then he can do so. That's the beauty of GPL.

So I guess that's a no from Edouard for now. :-(
My goal/my idea (if that wasn't clear already) is to have Edouard's
front-end included just the way it is now (except some indentations
differences, and some spaces all around)

That way, we (or at least, I) prove that we care about XviD and welcome
new patches from Edouard.


> And an extra patch with cosmetics to be applied _afterwards_ would 
> probably be more acceptable for most.

Darn, I didn't think it was that much of a problem....
How shall I put it.... I guess I'm not a good enough developer to trust
me enough for doing that (change code, and then cosmetics).
Plus, this task is now done, and quite frankly, I really don't want to
re-do it the other way, just because it took me a _lot_ of time to come
up with those patches, to test them, etc...
Like everyone else, I have a life too, so if you guys tell me that my
goal, and my work is useless the way it goes, I guess I'll just let that
work to others more enlightened devs and grab Edouard's front-end
instead, as it just work fine.


> >>Doxygen style comments are required now, see 
> >>DOCS/tech/code-documentation.txt
> > 
> > Hum... Given that it's not my code, I wonder if it would be a good idea
> > for me to write " maybe wrong" comments.
> > Heck, if it's required, I'll do it, just be warned!
> 
> I guess even those maybe-wrong comments are better than none. If they're 
> wrong they will be corrected somewhen, if there are none that will 
> probably stay like that.

Aren't those kinda cosmetics things that everybody _hates_? ,-)
Ok, I don't mind converting the comments into doxygen.


> > The attached patch feature the name change that'll make the move to
> > 1.1.x smoother.
> > I no one complains, I'll commit that in 3 day...
> 
> I don't like it, but if you want do it. Although I thought about that 
> renaming and I am not sure that it really improves readability.
> It changes the variable names to be the same as the type names, which 
> doesn't fit the criteria that variable names should describe what they 
> do / what they are used for. Not that the old names seem to be better...

I agree with that. I guess Edouard has his own reasons.

Anyway, thanks Reimar for your feedback; it's nice to see that I'm not
alone with that issue.

Regards,

Guillaume
-- 
Les Belges ont inventé les chaussettes à quartz; c'est pratique, ça 
remonte tout seul.
        -+- Coluche -+-