[MPlayer-cvslog] r26411 - trunk/libmpdemux/demuxer.c
Michael Niedermayer
michaelni at gmx.at
Fri May 30 23:28:45 CEST 2008
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
> On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
> > On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote:
[...]
> Has it occurred to you that you might be overreacting in this case?
Has it occured to you that you always play things down when uoti is
involved but you turn every tiny fly into a dinosour when its related to
iive or arpi.
>
> > > Uoti committed a bunch of cosmetic cleanups of different types together
> > > and labeled his commit as "indent". That was not good and I dislike bad
> > > commit messages more than the next guy, but it was not catastrophic.
> > > Plus, it was neither malicious, nor intentional. Uoti honestly did not
> > > expect this to be controversial.
> > >
> > > Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer
> > > standards, erupts. I speak with Reimar, I speak with Uoti, Reimar
> > > eventually calms down again. As suggested by me, Uoti speaks with
> > > Reimar, they decide to find a way to work better together with less
> > > friction.
> > >
> > > Everything should be fine and dandy again, should it not? No, wait, of
> > > course flaming has not subsided, but reached epic proportions instead.
> > > The tides of the discussion go ever higher and none of the participants
> > > is helping it in any way. On the contrary, all sides are stubborn or
> > > prone to flames or both and generally have a number of character traits
> > > not conducive to resolving conflicts.
> > >
> > > But what has really happened? Whatever you may think of the policy, it
> > > does not contain a paragraph that forbids committing different types of
> > > cosmetic changes together.
> >
> > It contains parts about not mixing cosmetics and functional changes it also
> > contains parts about not commiting to code maintained by others and something
> > about sending patches.
>
> None of this applies in this particular case.
copy and paste below for your memory, this commit was to demux_mkv.c
which has been written and is activly maintained by aurel
> @@ -43,7 +43,7 @@
> #include "libavutil/intreadwrite.h"
> #include "libavutil/avstring.h"
>
> -static unsigned char sipr_swaps[38][2]={
> +static const unsigned char sipr_swaps[38][2]={
> {0,63},{1,22},{2,44},{3,90},{5,81},{7,31},{8,86},{9,58},{10,36},{12,68},
> {13,39},{14,73},{15,53},{16,69},{17,57},{19,88},{20,34},{21,71},{24,46},
> {25,94},{26,54},{28,75},{29,50},{32,70},{33,92},{35,74},{38,85},{40,56},
> @@ -54,12 +54,13 @@ static unsigned char sipr_swaps[38][2]={
> #define SIPR_FLAVORS 4
> #define ATRC_FLAVORS 8
> #define COOK_FLAVORS 34
> -static int sipr_fl2bps[SIPR_FLAVORS] = {813, 1062, 625, 2000};
> -static int atrc_fl2bps[ATRC_FLAVORS] = {8269, 11714, 13092, 16538, 18260, 22050, 33075, 44100};
> -static int cook_fl2bps[COOK_FLAVORS] = {1000, 1378, 2024, 2584, 4005, 5513, 8010, 4005, 750, 2498,
> - 4048, 5513, 8010, 11973, 8010, 2584, 4005, 2067, 2584, 2584,
> - 4005, 4005, 5513, 5513, 8010, 12059, 1550, 8010, 12059, 5513,
> - 12016, 16408, 22911, 33506};
> +static const int sipr_fl2bps[SIPR_FLAVORS] = {813, 1062, 625, 2000};
> +static const int atrc_fl2bps[ATRC_FLAVORS] = {8269, 11714, 13092, 16538, 18260, 22050, 33075, 44100};
> +static const int cook_fl2bps[COOK_FLAVORS] = {
> + 1000, 1378, 2024, 2584, 4005, 5513, 8010, 4005, 750, 2498,
> + 4048, 5513, 8010, 11973, 8010, 2584, 4005, 2067, 2584, 2584,
> + 4005, 4005, 5513, 5513, 8010, 12059, 1550, 8010, 12059, 5513,
> + 12016, 16408, 22911, 33506};
>
> typedef struct
> {
Mix functional changes and cosmetics, revert.
Ciao,
Roberto
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080530/1355e285/attachment.pgp>
More information about the MPlayer-cvslog
mailing list