[FFmpeg-devel] [PATCH v5] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data

Mats Peterson matsp888 at yahoo.com
Mon Jan 11 07:05:19 CET 2016

On 01/11/2016 01:46 AM, Michael Niedermayer wrote:
> On Sun, Jan 10, 2016 at 04:04:47AM +0100, Mats Peterson wrote:
>> How about this one, Michael? Rather than using the obviously
>> dangerous av_realloc() it uses av_malloc() to allocate new memory
>> for the private data, then copies the private data to it, frees the
>> pointer to the original private data, and finally sets
>> track->codec->priv_data to the newly allocated memory.
> that documentation is misleading, av_malloc() is if one is really
> pedantic not safe to be passed to av_free or av_realloc()
> if one isnt pedantic it safe to be passed to both
> but of course theres nothing wrong with seperating them if you want
> to seperate them in your code. Theres a small theretical chance that
> some future platform will not work with mixed aligned memory and
> realloc but would be able to mix both with free()
> patch applied
> thanks

Well, I think I understand what you mean now, at least when it comes to 
av_malloc() and av_free(). From the manpage for memalign():

"POSIX requires that memory obtained from posix_memalign() can be  freed 
using free(3). Some systems provide no way to reclaim memory allocated 
with memalign() or valloc() (because one can only pass to  free(3) a 
pointer gotten from malloc(3), while, for example, memalign() would call 
malloc(3) and then align the obtained value). The glibc implementation 
allows memory obtained from any of these functions to be reclaimed with 


More information about the ffmpeg-devel mailing list