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

[Michael Niedermayer]

On Thu, May 27, 2010 at 08:18:08PM +0200, Cyril Russo wrote:
>
> Le 27/05/2010 18:37, Michael Niedermayer a ?crit :
>>
>>    
>>> 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
>>    
> I think I don't understand what you're saying. 

> Currently, I'm using 
> threads, and I have to copy packet because if I don't, it crashes while 
> decoding.

ffplay uses threads, it does not always copy and it doesnt crash


> If I had my own allocate_packet function in the context, then I would 
> probably allocate them in a thread's specific buffer.
> The default function could simply act like it does currently (we would keep 
> the "returned packet is valid until next av_read_frame" part, but add 
> "unless you provide your own allocate_packet function").

you dont seem to understand the problem at all or i dont understand you.

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/b9ab056e/attachment.pgp>