[FFmpeg-devel] [RFC] Windows issues with av_destruct_packet_nofree

[avcoder]

On Thu, Feb 19, 2009 at 1:17 AM, Art Clarke <aclarke at xuggle.com> wrote:

> Hi folks,
>
> I just spent somewhere between 2-3 weeks tracking down a weird bug that
> resulted in our code creating corrupted files on Windows but working fine
> on
> Linux and Mac.  The issue, it turns out, affects people who allocate their
> own AVPackets, and then try to use av_interleaved_write_frame on Windows.
> That's because on Windows, "av_destruct_packet_nofree" outside of the libav
> DLL's themselves is NOT the same as "av_destruct_packet_nofree" inside the
> libav DLLs.  As a result when using av_interleaved_write_frame on Windows,
> packet you might think FFMPEG is copying, aren't actually duplicated and
> memory corruption results.
>
> My suggestion is to add a comment to avformat.h above
> av_destruct_packet_nofree warning users in Windows to not use this method
> outside of libav, and instead set AVPacket->destruct to 0 (or NULL) if they
> want to manage their own packet memory.  I'd like people's thoughts on that
> (although at the end of this missive I put some other options that I, um,
> recommend against).
>
> Why is this happening?  Read on for the gritty details of the issue:
>
> The API doc for av_interleave_packet_per_dts suggest that setting
> AVPacket->destruct to av_destruct_packet will result in the packet being
> freed inside that function.  Separately there is a function called
> av_destruct_packet_nofree without documentation (I'm presuming if something
> is in avformat.h it's meant as part of the public API).  Reviewing
> libavformat/utils.c, especially av_dup_packet, it suggests if you create
> your own AVPacket's, and set AVPacket->destruct to
> av_destruct_packet_nofree, then av_dup_packet will copy (malloc/memcpy)
> your
> data if it needs to keep it around for writing interleaved files.  All good
> so far.
>
> So here's the issue: av_destruct_packet_nofree on Windows gets exported in
> the DLL with a thunking-wrapping function around it (generated by the
> compiler).  That means the following code:
>
> // In External Windows executable or library that dynamically links
> AVFORMAT.DLL
> AVPacket pkt;
> av_init_packet(&pkt);
> pkt.destruct = av_destruct_packet_nofree;
>
> AVPacket dupPkt;
> dupPkt = pkt;
> av_dup_packet(&dupPkt);
>

I am very curious, why do you call  av_destruct_packet_nofree()  outside of
AVFORMAT DLL ?

it should be OK if you only call av_init_packet(&pkt) which already includes
the setting of av_destruct_packet_nofree() .

-- 
----------------------------------------------
Inspired by http://nextchat.mobi
Your potential. Our passion.