[FFmpeg-devel] [RFC] Avoid av_read_frame memory copy in implementation
Thu May 27 18:37:38 CEST 2010
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 :
>>>> 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
>>>>> data and copy the data, because initial memory is reused when calling
>>>>> av_read_frame again.
> 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;
> 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
>> 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
>> or a "static" buffer could contain data from several demuxer packets.
>> its theoreticall possibly to reduce the coping outside libavformat for
>> if we could keep track of all the packets refering to packets, but that
>> 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel