headers
darkshikari | 1 Sep 2009 10:12
Picon

[ffmpeg.org]: r383 - trunk/src/shame

Author: darkshikari
Date: Tue Sep  1 10:12:11 2009
New Revision: 383

Log:
Remove Carbon Coder from the Wall of Shame; it never belonged on there in the first place.

Modified:
   trunk/src/shame

Modified: trunk/src/shame
==============================================================================
--- trunk/src/shame	Mon Aug 24 17:33:35 2009	(r382)
+++ trunk/src/shame	Tue Sep  1 10:12:11 2009	(r383)
 <at>  <at>  -101,8 +101,6  <at>  <at> 
 <a href="http://roundup.ffmpeg.org/roundup/ffmpeg/issue925">issue tracker entry</a></li>
 <li><a href="http://www.redkawa.com" rel="nofollow">Red Kawa</a>,
 <a href="http://roundup.ffmpeg.org/roundup/ffmpeg/issue923">issue tracker entry</a></li>
-<li><a href="http://www.rhozet.com/carbon_coder.html" rel="nofollow">Rhozet Carbon Coder</a>,
-<a href="http://roundup.ffmpeg.org/roundup/ffmpeg/issue484">issue tracker entry</a></li>
 <li><a href="http://www.senstic.com/iphone/airtv/airtv.aspx" rel="nofollow">Senstic Air TV</a>,
 <a href="http://roundup.ffmpeg.org/roundup/ffmpeg/issue1266">issue tracker entry</a></li>
 <li><a href="http://www.cctvhw.com/english/" rel="nofollow">ShenZhen Hawell</a>,
Permalink | Reply | 0 comments |
headers
Diego Biurrun | 1 Sep 2009 14:43
Picon
Gravatar

Re: r19609 - in trunk: common.mak configure

On Sun, Aug 09, 2009 at 05:05:27PM +0300, Uoti Urpala wrote:
> On Sat, 2009-08-08 at 20:27 +0200, mru wrote:
> > Log:
> > Generate dependencies while compiling if supported by compiler
> 
> > +    CC_DEPFLAGS='-MMD'
> 
> You should add -MP here. Without it 'make' will fail when you rename
> headers because the .d file has a now unsatisfiable dependency on the
> old header name. With -MP the compiler will add a phony target, so a
> "missing" header just triggers a recompile that will either update the
> dependencies or fail if it's a real error.

Mans?

Diego
Permalink | Reply | 0 comments |
headers
Benoit Fouet | 1 Sep 2009 17:07
Picon
Favicon

Re: r19742 - trunk/libavutil/internal.h

On 2009-08-30 00:44, Måns Rullgård wrote:
> ramiro <subversion <at> mplayerhq.hu> writes:
> 
>> Author: ramiro
>> Date: Sun Aug 30 00:38:48 2009
>> New Revision: 19742
>>
>> Log:
>> Add CHECKED_ALLOC macro.
>> It works the same as CHECKED_ALLOCZ except that it does not zero the allocated
>> memory.
>>
>> Modified:
>>    trunk/libavutil/internal.h
>>
>> Modified: trunk/libavutil/internal.h
>> ==============================================================================
>> --- trunk/libavutil/internal.h	Sat Aug 29 23:04:18 2009	(r19741)
>> +++ trunk/libavutil/internal.h	Sun Aug 30 00:38:48 2009	(r19742)
>>  <at>  <at>  -249,6 +249,15  <at>  <at>  if((y)<(x)){\
>>  #define perror please_use_av_log_instead_of_perror
>>  #endif
>>
>> +#define CHECKED_ALLOC(p, size)\
>> +{\
>> +    p= av_malloc(size);\
>> +    if(p==NULL && (size)!=0){\
>> +        av_log(NULL, AV_LOG_ERROR, "Cannot allocate memory.");\
>> +        goto fail;\
>> +    }\
(Continue reading)

Permalink | Reply | 12 comments |
headers
Måns Rullgård | 1 Sep 2009 17:16

Re: r19742 - trunk/libavutil/internal.h

Benoit Fouet <benoit.fouet <at> free.fr> writes:

> On 2009-08-30 00:44, Måns Rullgård wrote:
>> ramiro <subversion <at> mplayerhq.hu> writes:
>> 
>>> Author: ramiro
>>> Date: Sun Aug 30 00:38:48 2009
>>> New Revision: 19742
>>>
>>> Log:
>>> Add CHECKED_ALLOC macro.
>>> It works the same as CHECKED_ALLOCZ except that it does not zero the allocated
>>> memory.
>>>
>>> Modified:
>>>    trunk/libavutil/internal.h
>>>
>>> Modified: trunk/libavutil/internal.h
>>> ==============================================================================
>>> --- trunk/libavutil/internal.h	Sat Aug 29 23:04:18 2009	(r19741)
>>> +++ trunk/libavutil/internal.h	Sun Aug 30 00:38:48 2009	(r19742)
>>>  <at>  <at>  -249,6 +249,15  <at>  <at>  if((y)<(x)){\
>>>  #define perror please_use_av_log_instead_of_perror
>>>  #endif
>>>
>>> +#define CHECKED_ALLOC(p, size)\
>>> +{\
>>> +    p= av_malloc(size);\
>>> +    if(p==NULL && (size)!=0){\
>>> +        av_log(NULL, AV_LOG_ERROR, "Cannot allocate memory.");\
(Continue reading)

Permalink | Reply | 11 comments |
headers
diego | 1 Sep 2009 18:00
Picon

r19751 - trunk/libavutil/internal.h

Author: diego
Date: Tue Sep  1 18:00:45 2009
New Revision: 19751

Log:
whitespace cosmetics, prettyprinting

Modified:
   trunk/libavutil/internal.h

Modified: trunk/libavutil/internal.h
==============================================================================
--- trunk/libavutil/internal.h	Mon Aug 31 07:48:17 2009	(r19750)
+++ trunk/libavutil/internal.h	Tue Sep  1 18:00:45 2009	(r19751)
 <at>  <at>  -56,7 +56,7  <at>  <at> 
 #endif

 #ifndef INT16_MIN
-#define INT16_MIN       (-0x7fff-1)
+#define INT16_MIN       (-0x7fff - 1)
 #endif

 #ifndef INT16_MAX
 <at>  <at>  -64,7 +64,7  <at>  <at> 
 #endif

 #ifndef INT32_MIN
-#define INT32_MIN       (-0x7fffffff-1)
+#define INT32_MIN       (-0x7fffffff - 1)
 #endif
(Continue reading)

Permalink | Reply | 2 comments |
headers
Diego Biurrun | 1 Sep 2009 18:01
Picon
Gravatar

Re: r19742 - trunk/libavutil/internal.h

On Sat, Aug 29, 2009 at 11:44:29PM +0100, Måns Rullgård wrote:
> Finally, it could do with some beautifying, but that's secondary.

No longer.

Diego
Permalink | Reply | 0 comments |
headers
Måns Rullgård | 1 Sep 2009 18:11

Re: r19751 - trunk/libavutil/internal.h

diego <subversion <at> mplayerhq.hu> writes:

> -    __asm__ volatile ("umull %1, %0, %2, %3"
> -                      : "=&r"(r), "=&r"(t) : "r"(a), "r"(ff_inverse[b]));
> +    __asm__ volatile("umull %1, %0, %2, %3"
> +                     : "=&r"(r), "=&r"(t) : "r"(a), "r"(ff_inverse[b]));

Why did you remove that space (and others like it)?  I thought the
general rule was space after keywords, no space after function names.

--

-- 
Måns Rullgård
mans <at> mansr.com
Permalink | Reply | 1 comment |
headers
Diego Biurrun | 1 Sep 2009 18:54
Picon
Gravatar

Re: r19751 - trunk/libavutil/internal.h

On Tue, Sep 01, 2009 at 05:11:05PM +0100, Måns Rullgård wrote:
> diego <subversion <at> mplayerhq.hu> writes:
> 
> > -    __asm__ volatile ("umull %1, %0, %2, %3"
> > -                      : "=&r"(r), "=&r"(t) : "r"(a), "r"(ff_inverse[b]));
> > +    __asm__ volatile("umull %1, %0, %2, %3"
> > +                     : "=&r"(r), "=&r"(t) : "r"(a), "r"(ff_inverse[b]));
> 
> Why did you remove that space (and others like it)?  I thought the
> general rule was space after keywords, no space after function names.

Hmm, I considered the inline asm a function call..  Apparently it should
rather be the other way around..

Diego
Permalink | Reply | 0 comments |
headers
Diego Biurrun | 2 Sep 2009 11:19
Picon
Gravatar

Re: r19695 - trunk/libavcodec/twinvq.c

On Fri, Aug 28, 2009 at 01:11:53PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 25, 2009 at 10:50:50AM +0200, Diego Biurrun wrote:
> > On Tue, Aug 25, 2009 at 04:16:37AM +0200, Vitor Sessak wrote:
> > > Diego Biurrun wrote:
> [...]
> > > >>--- trunk/libavcodec/twinvq.c	Mon Aug 24 15:43:33 2009 (r19694)
> > > >>+++ trunk/libavcodec/twinvq.c	Mon Aug 24 19:35:47 2009 (r19695)
> > > >> <at>  <at>  -458,7 +458,7  <at>  <at>  static void add_peak(int period, int wid
> > > >> 
> > > >>-    for (j=-width/2; j < (width+1)/2 && shape < shape_end; j++)
> > > >>+    for (j=-width/2; j < (width + 1)/2 && shape < shape_end; j++)
> > > >
> > > >There are still some operators on this line that could benefit from
> > > >whitespace, especially / and =.
> > > 
> > > I try to stick to K&R for most of the things but it goes a little too 
> > > far on extra whitespaces for my taste. I particularly hate doing
> > > 
> > > for (i = 0; i < 10; i++)
> > > 
> > > instead of
> > > 
> > > for (i=0; i < 10; i++)
> > 
> > That's the good thing about common styles: Nobody gets to be the
> > privileged person whose style gets picked.  Everybody has to adapt.
> 
> There is nothing good on "Everybody has to adapt"

You misunderstand.  It is much better to make everybody get used to a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Niedermayer | 2 Sep 2009 14:31
Picon
Picon

Re: r19695 - trunk/libavcodec/twinvq.c

On Wed, Sep 02, 2009 at 11:19:58AM +0200, Diego Biurrun wrote:
> On Fri, Aug 28, 2009 at 01:11:53PM +0200, Michael Niedermayer wrote:
> > On Tue, Aug 25, 2009 at 10:50:50AM +0200, Diego Biurrun wrote:
> > > On Tue, Aug 25, 2009 at 04:16:37AM +0200, Vitor Sessak wrote:
> > > > Diego Biurrun wrote:
> > [...]
> > > > >>--- trunk/libavcodec/twinvq.c	Mon Aug 24 15:43:33 2009 (r19694)
> > > > >>+++ trunk/libavcodec/twinvq.c	Mon Aug 24 19:35:47 2009 (r19695)
> > > > >> <at>  <at>  -458,7 +458,7  <at>  <at>  static void add_peak(int period, int wid
> > > > >> 
> > > > >>-    for (j=-width/2; j < (width+1)/2 && shape < shape_end; j++)
> > > > >>+    for (j=-width/2; j < (width + 1)/2 && shape < shape_end; j++)
> > > > >
> > > > >There are still some operators on this line that could benefit from
> > > > >whitespace, especially / and =.
> > > > 
> > > > I try to stick to K&R for most of the things but it goes a little too 
> > > > far on extra whitespaces for my taste. I particularly hate doing
> > > > 
> > > > for (i = 0; i < 10; i++)
> > > > 
> > > > instead of
> > > > 
> > > > for (i=0; i < 10; i++)
> > > 
> > > That's the good thing about common styles: Nobody gets to be the
> > > privileged person whose style gets picked.  Everybody has to adapt.
> > 
> > There is nothing good on "Everybody has to adapt"
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane