[FFmpeg-devel] [PATCH] mem: Make function attribute usage consistent

2016-07-30 Thread Timothy Gu
---
 libavutil/mem.h | 47 +--
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 2f53b47..a6bb6b7 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -80,7 +80,9 @@
  * be allocated.
  * @see av_mallocz()
  */
-void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+av_alloc_size(1)
+void *av_malloc(size_t size);
 
 /**
  * Allocate a block of size * nmemb bytes with av_malloc().
@@ -90,7 +92,9 @@ void *av_malloc(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * be allocated.
  * @see av_malloc()
  */
-av_alloc_size(1, 2) static inline void *av_malloc_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+av_alloc_size(1, 2)
+static inline void *av_malloc_array(size_t nmemb, size_t size)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -115,7 +119,9 @@ av_alloc_size(1, 2) static inline void 
*av_malloc_array(size_t nmemb, size_t siz
  *  some libc implementations.
  * @see av_fast_realloc()
  */
-void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
+av_malloc_attrib
+av_alloc_size(2)
+void *av_realloc(void *ptr, size_t size);
 
 /**
  * Allocate or reallocate a block of memory.
@@ -125,6 +131,8 @@ void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
  * - It frees the input block in case of failure, thus avoiding the memory
  *   leak with the classic "buf = realloc(buf); if (!buf) return -1;".
  */
+av_malloc_attrib
+av_alloc_size(2, 3)
 void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
 
 /**
@@ -145,6 +153,7 @@ void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
  *  some libc implementations.
  */
 av_warn_unused_result
+av_alloc_size(2)
 int av_reallocp(void *ptr, size_t size);
 
 /**
@@ -164,7 +173,9 @@ int av_reallocp(void *ptr, size_t size);
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) void *av_realloc_array(void *ptr, size_t nmemb, size_t 
size);
+av_malloc_attrib
+av_alloc_size(2, 3)
+void *av_realloc_array(void *ptr, size_t nmemb, size_t size);
 
 /**
  * Allocate or reallocate an array through a pointer to a pointer.
@@ -183,7 +194,8 @@ av_alloc_size(2, 3) void *av_realloc_array(void *ptr, 
size_t nmemb, size_t size)
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t 
size);
+av_alloc_size(2, 3)
+int av_reallocp_array(void *ptr, size_t nmemb, size_t size);
 
 /**
  * Free a memory block which has been allocated with av_malloc(z)() or
@@ -203,7 +215,9 @@ void av_free(void *ptr);
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  * @see av_malloc()
  */
-void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+av_alloc_size(1)
+void *av_mallocz(size_t size);
 
 /**
  * Allocate a block of nmemb * size bytes with alignment suitable for all
@@ -215,7 +229,9 @@ void *av_mallocz(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * @param size
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  */
-void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+av_malloc_attrib
+av_alloc_size(1, 2)
+void *av_calloc(size_t nmemb, size_t size);
 
 /**
  * Allocate a block of size * nmemb bytes with av_mallocz().
@@ -226,7 +242,9 @@ void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
  * @see av_mallocz()
  * @see av_malloc_array()
  */
-av_alloc_size(1, 2) static inline void *av_mallocz_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+av_alloc_size(1, 2)
+static inline void *av_mallocz_array(size_t nmemb, size_t size)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -239,7 +257,8 @@ av_alloc_size(1, 2) static inline void 
*av_mallocz_array(size_t nmemb, size_t si
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strdup(const char *s) av_malloc_attrib;
+av_malloc_attrib
+char *av_strdup(const char *s);
 
 /**
  * Duplicate a substring of the string s.
@@ -249,7 +268,9 @@ char *av_strdup(const char *s) av_malloc_attrib;
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strndup(const char *s, size_t len) av_malloc_attrib;
+av_malloc_attrib
+av_alloc_size(2)
+char *av_strndup(const char *s, size_t len);
 
 /**
  * Duplicate the buffer p.
@@ -257,6 +278,8 @@ char *av_strndup(const char *s, size_t len) 
av_malloc_attrib;
  * @return Pointer to a newly allocated buffer containing a
  * copy of p or NULL if the buffer cannot be allocated.
  */
+av_malloc_attrib
+av_alloc_size(2)
 void *av_memdup(const void *p, size_t size);
 
 /**
@@ -368,6 +391,8 @@ void av_memcpy_backptr(uint8_t *dst, int back, int 

Re: [FFmpeg-devel] [PATCH 2/2] mem: Make function attribute usage consisten

2016-07-30 Thread Michael Niedermayer
On Fri, Jul 29, 2016 at 10:30:38PM -0700, Timothy Gu wrote:
> ---
>  libavutil/mem.h | 42 +++---
>  1 file changed, 27 insertions(+), 15 deletions(-)

doesnt build here:

make distclean ; ./configure && make -j12
..
CC  libavdevice/alldevices.o
In file included from ./libavutil/common.h:464:0,
 from ./libavutil/avutil.h:288,
 from ./libavutil/log.h:25,
 from libavdevice/avdevice.h:46,
 from libavdevice/alldevices.c:22:
./libavutil/mem.h:96:1: error: expected ‘,’ or ‘;’ before ‘{’ token
./libavutil/mem.h:238:1: error: expected ‘,’ or ‘;’ before ‘{’ token
./libavutil/mem.h:95:21: warning: ‘av_malloc_array’ declared ‘static’ but never 
defined [-Wunused-function]
./libavutil/mem.h:237:21: warning: ‘av_mallocz_array’ declared ‘static’ but 
never defined [-Wunused-function]
make: *** [libavdevice/alldevices.o] Error 1

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing]

2016-07-30 Thread Mark Thompson
On 30/07/16 15:50, Jens Ziller wrote:
> Am Samstag, den 16.07.2016, 17:27 +0200 schrieb Jens Ziller:
>> Hello Rodger and wm4,
>>
>> for interlaced frames I need AVFrame->interlaced_frame. For invoke
>> MMAL
>> components like deinterlacer and renderer added a pointer data[2] to
>> existing MMAL_ES_FORMAT_T. I don't have find a better solution to
>> give
>> a pointer to user app. I have added a patch as suggestion. Please
>> help 
>> me that I can release my code.
>>
>> regards Jens
>>
>>
>>  Weitergeleitete Nachricht 
>> Von: Michael Niedermayer 
>> Reply-to: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> An: FFmpeg development discussions and patches > rg
>>>
>>>
>> Betreff: Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add
>> interlaced_frame and format struct to AVFrame for deinterlacing
>> Datum: Sat, 16 Jul 2016 14:41:50 +0200
>>
>> On Sat, Jul 16, 2016 at 11:08:12AM +0200, Jens Ziller wrote:
>>>
>>>
>>> Am Sonntag, den 03.07.2016, 19:36 +0200 schrieb Jens Ziller:


 Am Sonntag, den 03.07.2016, 18:05 +0200 schrieb Moritz Barsnick:
>
>
>
> On Sun, Jul 03, 2016 at 17:20:41 +0200, Jens Ziller wrote:
>>
>>
>>
>>
>> Am Samstag, den 02.07.2016, 17:54 +0200 schrieb Moritz
>> Barsnick:
>>>
>>>
>>>
>>>
>>> On Sun, Jun 26, 2016 at 17:12:14 +0200, Jens Ziller wrote:





 +ctx->interlaced_frame = !(interlace_type.eMode
 ==
 MMAL_InterlaceProgressive);
>>> What's wrong with using the "!=" operator instead?
>> "!=" is a comparing. "= !()" assign with a negate. Here is "=
>> !()"
>> needed.
> I meant the comparison, not the assignment, so replacing:
>   ctx->interlaced_frame = !(interlace_type.eMode ==
> MMAL_InterlaceProgressive)
> with
>   ctx->interlaced_frame = (interlace_type.eMode !=
> MMAL_InterlaceProgressive)
>
> The former is rather ... convoluted.
> (Brackets optional, but probably better for readability.)
>
> Moritz
 Oh, sorry! I'am so blind. Yes, that's not really smart. I changed
 that.
 The new patch is attached.

 Regards Jens

>>> Hello Michael and list,
>>>
>>> this patch was discussed and improved on the ML. What can I still
>>> do
>>> that my app get interlaced_frame and a pointer to the existing
>>>
>>> MMAL_ES_FORMAT_T from ffmpeg? mmaldec.c have unfortunately no
>>> maintainer.
>> But it has authors,
>> you can ask rodger combs and wm4
>>
>> If they do not reply then please explain why you need this structure
>> in data[2]
>> Also what is the lifetime of this structure and what is the liftime
>> of the AVFrame that contains it. Its neccessary that the struct stays
>> valid as long as the AVFrame could be
>>
>> [...]
>>
> 
> Hello Michael,
> 
> I have ask rodger combs and wm4 two weeks ago, but unfortunately no
> reply. Please integrate the attached patch.
> 
> MMAL_ES_FORMAT_T is needed for invoke the MMAL deinterlacer and
> renderer in an application.
> 
> This struct give the decoder before the first frame gives out.
> In mmaldec.c line 689 ask the flag MMAL_EVENT_FORMAT_CHANGED and if
> this flag is set MMAL_ES_FORMAT_T is filled. This struct was cleaned if
> the decoder was stopped in mmaldec.c line 150. There are no lifetime
> issue.

Does this also do the right thing if the decoder is reconfigured with frames 
outstanding?  To me (without really knowing the code) it looks like it will 
overwrite the old format (line 702) and therefore mess with existing frames, 
though there are multiple levels of indirection so the frame could be holding 
onto a reference by some route I'm not seeing.

Similarly for stopping the decoder - there may be output frames which are still 
valid, and it looks to me like the format structure will have disappeared.  (Is 
there some internal reference via the MMAL_BUFFER_HEADER_T which solves both of 
these cases, maybe?  If so, it might be clearer if you could use that internal 
reference to set the value rather than going via the decoder.)

Also, will this structure always be available with sufficient lifetime for MMAL 
frames produced by things other than the decoder?  Your documentation on the 
pixfmt is phrased such that it is always required - given that it appears to be 
for a specific use-case, maybe it would be better if it were optional.

Thanks,

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing]

2016-07-30 Thread Jens Ziller
Am Samstag, den 16.07.2016, 17:27 +0200 schrieb Jens Ziller:
> Hello Rodger and wm4,
> 
> for interlaced frames I need AVFrame->interlaced_frame. For invoke
> MMAL
> components like deinterlacer and renderer added a pointer data[2] to
> existing MMAL_ES_FORMAT_T. I don't have find a better solution to
> give
> a pointer to user app. I have added a patch as suggestion. Please
> help 
> me that I can release my code.
> 
> regards Jens
> 
> 
>  Weitergeleitete Nachricht 
> Von: Michael Niedermayer 
> Reply-to: FFmpeg development discussions and patches  de...@ffmpeg.org>
> An: FFmpeg development discussions and patches  rg
> > 
> > 
> Betreff: Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add
> interlaced_frame and format struct to AVFrame for deinterlacing
> Datum: Sat, 16 Jul 2016 14:41:50 +0200
> 
> On Sat, Jul 16, 2016 at 11:08:12AM +0200, Jens Ziller wrote:
> > 
> > 
> > Am Sonntag, den 03.07.2016, 19:36 +0200 schrieb Jens Ziller:
> > > 
> > > 
> > > Am Sonntag, den 03.07.2016, 18:05 +0200 schrieb Moritz Barsnick:
> > > > 
> > > > 
> > > > 
> > > > On Sun, Jul 03, 2016 at 17:20:41 +0200, Jens Ziller wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Am Samstag, den 02.07.2016, 17:54 +0200 schrieb Moritz
> > > > > Barsnick:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sun, Jun 26, 2016 at 17:12:14 +0200, Jens Ziller wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > +ctx->interlaced_frame = !(interlace_type.eMode
> > > > > > > ==
> > > > > > > MMAL_InterlaceProgressive);
> > > > > > What's wrong with using the "!=" operator instead?
> > > > > "!=" is a comparing. "= !()" assign with a negate. Here is "=
> > > > > !()"
> > > > > needed.
> > > > I meant the comparison, not the assignment, so replacing:
> > > >   ctx->interlaced_frame = !(interlace_type.eMode ==
> > > > MMAL_InterlaceProgressive)
> > > > with
> > > >   ctx->interlaced_frame = (interlace_type.eMode !=
> > > > MMAL_InterlaceProgressive)
> > > > 
> > > > The former is rather ... convoluted.
> > > > (Brackets optional, but probably better for readability.)
> > > > 
> > > > Moritz
> > > Oh, sorry! I'am so blind. Yes, that's not really smart. I changed
> > > that.
> > > The new patch is attached.
> > > 
> > > Regards Jens
> > > 
> > Hello Michael and list,
> > 
> > this patch was discussed and improved on the ML. What can I still
> > do
> > that my app get interlaced_frame and a pointer to the existing
> > 
> > MMAL_ES_FORMAT_T from ffmpeg? mmaldec.c have unfortunately no
> > maintainer.
> But it has authors,
> you can ask rodger combs and wm4
> 
> If they do not reply then please explain why you need this structure
> in data[2]
> Also what is the lifetime of this structure and what is the liftime
> of the AVFrame that contains it. Its neccessary that the struct stays
> valid as long as the AVFrame could be
> 
> [...]
> 

Hello Michael,

I have ask rodger combs and wm4 two weeks ago, but unfortunately no
reply. Please integrate the attached patch.

MMAL_ES_FORMAT_T is needed for invoke the MMAL deinterlacer and
renderer in an application.

This struct give the decoder before the first frame gives out.
In mmaldec.c line 689 ask the flag MMAL_EVENT_FORMAT_CHANGED and if
this flag is set MMAL_ES_FORMAT_T is filled. This struct was cleaned if
the decoder was stopped in mmaldec.c line 150. There are no lifetime
issue.

regards jensFrom b724bbe3a13addb055da883cbe802eee74d7c65e Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Sun, 3 Jul 2016 19:25:23 +0200
Subject: [PATCH] v4 fill AVFrame->interlaced_frame with
 MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T, add a pointer data[2] to
 MMAL_ES_FORMAT_T that user application can invoke MMAL components like
 deinterlacer and renderer with it

---
 libavcodec/mmaldec.c | 17 +
 libavutil/pixfmt.h   |  3 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 099a8c5..2e7b43c 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+