[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
decoding.
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").
Cheers,
Cyril
More information about the ffmpeg-devel
mailing list