[FFmpeg-devel] DVCPRO HD: request for review
Roman V. Shaposhnik
Fri Aug 29 18:54:25 CEST 2008
On Fri, 2008-08-29 at 05:52 +0200, Michael Niedermayer wrote:
> > I'll commit everything today and this piece
> Iam not sure if this and your commit of 170k of unapproved code is a joke.
> If it is, i do not like you humor.
No it isn't. It is an honest attempt to continue as a DV maintainer.
> Please revert it and commit the parts that have been approved cleanly
> in several seperate commits.
No. And if treating maintainers in this manner is your kind of humor
I don't think I appreciate it either. Moreover, this is not the first
time when you ridicule me after I honestly tried to work all the issues
with you and had an impression that they were all resolved. I do have
commitments as far as DVCPRO HD is concerned so I'm willing to tolerate
your behavior while I'm trying to integrate decoder and encoder.
But once that happens, I believe I have no place in the project like
this. So, please start finding another maintainer for DV stuff. Heavens
are my witness I tried to work with you. I tried to be helpful to the
project. I'm not as smart as you are. But I believe I can be helpful.
You know that I went over the roundup yesterday and saw a couple of
areas where my puny coding skills are a match. But you, know, I really
don't need this aggravation...
Anyway, now for the technical part...
Yes. I will revert the commit once I get to a place where svn works.
This likely to happen by COB today. However, I have no clue what you're
talking about when you say that I have committed unapproved code. As
far as I'm concerned everything in:
libavformat/isom.c has been approved
libavformat/dv.c has been approved
libavcodec/dv.c has been approved
the only bit you didn't *explicitly* approved is the tables. And given
that I explained two times why I am adding them and why they have
a high chance of going away real soon once I transition to any
scheme that proves to be faster. It is all documented in the
thread -- look it up.
Now, as for committing individual changes. There's none to be committed
(except for isom.c) so that you have a *working* DV codec between the
commits. I have always though that people are using changesets for a
reason. Mainly to indicate when a group of changes in the code represent
a transaction. What you're asking me to do is to split that transaction.
I don't view it as a smart request.
> Especially the huge tables should be reverted, adding roughly 100kb to the
> size of ffmpeg by completely bypassing review and without any kind of
> justification of why these tables are unavoidable is kinda nasty.
I gave that justification in my original email and given that you didn't
say a word assumed that you were fine with them for the time being.
> Several people including me and vitor try hard to cleanup codecs that had
> been added without passing through proper review, we really do not need
> more such code.
More information about the ffmpeg-devel