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

[Michael Niedermayer]

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


> > 
> > 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.
Either way a patch that improves the performance is certainly welcome
if reasonable clean ...

also a patch making the memory allocation for packets user overrideable is
not unwelcome if it speed things up.


> > 
> 
> It's not what the doc of av_read_frame says:
> 
> ?The returned packet is valid until the next av_read_frame() or until av_close_input_file() and must be freed with av_free_packet.?

correct

also see av_dup_packet()
which makes sure you have a lasting packet


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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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/20100526/de3175c7/attachment.pgp>