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

Cyril Russo stage.nexvision
Thu May 27 20:18:08 CEST 2010

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 
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").


More information about the ffmpeg-devel mailing list