[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Sun, Jan 16, 2011 at 05:32:45PM +0100, Reimar D?ffinger wrote:
> On Sun, Jan 16, 2011 at 05:15:10PM +0100, Diego Biurrun wrote:
> > On Sun, Jan 16, 2011 at 04:23:44PM +0100, Reimar D?ffinger wrote:
> > > On Sun, Jan 16, 2011 at 03:53:52PM +0100, Diego Biurrun wrote:
> > > > If this is supposed to help porting filters, publish a branch and write
> > > > a filter porting HOWTO that instructs people where to pull that branch
> > > > from.  There is absolutely no need to have this code in trunk/master.
> > > 
> > > Well, it would allow testing reimplementations against the libmpcodecs
> > > versions via FATE. Also it has exposed some significant performance
> > > differences already, so there's some suspicion that this might make
> > > people actually bother to compare performance.
> > 
> > Michael wrote the code already, devs working on filters know where to
> > find it.  There is no need to bloat FFmpeg with libmpcodecs.
> 
> They knew that before, and it still seems nobody bothered.
> Sometimes convenience is the only thing that matters in the end.

also my patch as posted contains bugs, at least one ive fixed locally and some
that need investigating
It would be tremendously helpfull to have the code available over the main
checkout to everyone for people to help working on it

I remember myself often hearing of various RE efforts and other out of main
branch work. And i practically never bothered to check them out. Theres a
good chance i would have contributed minor fixes here and there had the code
been easier available
Thats also why i always wanted the mplayer docs team to have write access to
ffmpeg, so they could just fix minor uncontroversal typos ...


> 
> > > > I also see that Carl Eugen just committed the tab removal that directly
> > > > conflicts with my uncrustify work without any previous discussion, even
> > > > though Reimar mentioned that I am working on something related.
> > > 
> > > I have to say I didn't expect there to be any conflict, while suboptimal
> > > with concern to history, does this kind of change cause issues for your
> > > work?
> > 
> > It does not cause direct issues for my work, but Carl Eugen could not know
> > that.  The least thing he could do is ask, in the appropriate forum.  On
> > top of that I remember him being against cosmetic changes in the past.
> > 
> > Then there is the issue of bloating the history with huge and completely
> > pointless commits and causing conflicts for every single developer with
> > changes in one of the affected files.
> 
> I agree it wasn't optimal, and I don't disagree that you are justified
> to complain. I just see the agressiveness as neither helping not justified.

I cant say more than i agree.
The lack of having this discussed at the appropriate list was a unfortunate
mistake.

Id also like to make it clear that iam perfectly fine if it is reverted


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110116/59bd32b3/attachment.pgp>