[FFmpeg-devel] [RFC] Avoid av_read_frame memory copy in implementation

[Michael Niedermayer]

On Thu, May 27, 2010 at 11:51:44AM +0200, Cyril Russo wrote:
>
> Le 26/05/2010 20:10, Michael Niedermayer a ?crit :
>> On Wed, May 26, 2010 at 04:45:16PM +0200, Jean-Daniel Dupas wrote:
>>    
>>> Le 26 mai 2010 ? 16:39, Ronald S. Bultje a ?crit :
>>>
>>>      
>>>> Hi,
>>>>
>>>> On Wed, May 26, 2010 at 7:06 AM, Cyril Russo
>>>> <stage.nexvision at laposte.net>  wrote:
>>>>        
>>>>> Currently, one must allocate another buffer to store the returned 
>>>>> packet's
>>>>> data and copy the data, because initial memory is reused when calling
>>>>> av_read_frame again.
>>>>>          
>> wrong
>>    
> My tests shows that it's the case (at least for AAC + H264 in mp4).
> The pseudo code is:

here h264 in mp4 does produce lastinng packets created with av_malloc()


>
> AVPacket packet[10];
> foreach packet in array: av_read_frame(packet[i])
> [... later ...]
> avcodec_decode_[...](packet[i]) => corruption / crash in avcodec_decode
>
> And the documentation says so.
>
>>
>>    
>>>> Huh? That sounds like a bug, demuxers freshly allocate memory for each 
>>>> packet.
>>>>        
>> most do, after parsers it can be reused memory though, thats a complicated
>> issue as one demuxer packet can end up being used for several parsed 
>> packets
>> or a "static" buffer could contain data from several demuxer packets.
>> its theoreticall possibly to reduce the coping outside libavformat for 
>> these
>> if we could keep track of all the packets refering to packets, but that 
>> would
>> then also require thread sync and become somewhat complex.
>>    
> Which demuxer use threads currently ?

the user application can use threads



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

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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/ffmpeg-devel/attachments/20100527/ccc4b8d5/attachment.pgp>