[Ffmpeg-cvslog] r8204 - trunk/libavformat/mov.c
Sun Mar 4 03:53:22 CET 2007
On Sun, Mar 04, 2007 at 02:16:54AM +0100, Baptiste Coudurier wrote:
> >>> ive fixed the mess, ive also found that WMV3 was removed in the
> >>> change which the commit message had not mentioned and baptiste
> >>> apparently forgot
> >>> baptiste please be more carefull in the future
> >> Well, for sure, I won't clean any mess in the future. Yes im quite
> >> upset, and tired.
> > it was not my intent to piss you off, you are a valuable developer
> > and your cleanups are welcome, just this one was done in an
> > unaccpetable way ive fixed it not you so why are you angry?
> Basically because I was looking at that table and thought that it would
> need some big cleanup, chose to clean it up, and to reuse it for muxing,
> then spent some time checking if I did not break anything and compared
> both tables, and then added missing tags in demuxing table, then chose
> to commit. Now if I just choose to think "Well no Im tired and lazy", it
> won't ever be done anyway, and I clearly think this attitude is bad, so
> I chose a compromise and commit it all in once mentionning what I had done.
> Im all for strict rules and I hope you clearly saw it, now Im sometimes
> quite pissed when strict rules lead to avoid doing things because
> laziness. IMHO difference between developpers and patch senders should
> be made sometimes.
its not about rules at all, but about the reasons why the rules exist in the
first place, if that reason doesnt apply then i dont care at all if you
violate them all, the reason against cosmetic-functional mixes is that
they are very hard to review/read/debug/understand and that pure cosmetic
changes can be skiped by anyone debuging a problem or reading svnlog ...
which can save alot of time
the reason applies no matter if patch sender or commiter, so should the
> >>> btw why was WMV3 removed?
> >> cleanup, wmv3 is not needed since vc1 fourcc will pick up
> >> CODEC_ID_VC1 for demuxing first, and never wmv3.
> > but for muxing WMV3 will fail to find the tag while if it where in
> > the table it would succeed, at least that seems to be the case, the
> > table is used on the muxer side too of course it might be wrong to
> > use that tag for wmv3 i dont know but its not a cosmetical change if
> > a entry is removed from a table
> Well, point is that muxing is not concerned by this commit, it might be
> concerned one commit after.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-cvslog