[FFmpeg-devel] [RFC] [PATCH] ffmpeg: fix streamcopy with side data

Michael Niedermayer michaelni at gmx.at
Fri Aug 15 05:49:47 CEST 2014


On Thu, Aug 14, 2014 at 12:24:47PM +0200, Christophe Gisquet wrote:
> Hi,
> 
> the attached patch seems to fix ticket #3773, but streamcopy is such a
> core feature of ffmpeg that I assume I'm missing a use case or
> incorrectly handle the buffers referencing.
> 
> Another note is that this patch was developed without a memory tracer
> like valgrind: I have just validated that the test case doesn't crash
> and passes fate-h264-bsf-mp4toannexb.
> 
> Last point, I think this bug raises a few questions/issues:
> - API may not be abundantly clear that AVPacket::data is refcounted
> and should not be meddled with directly;
> - For lack of a way to do it, ffmpeg.c streamcopy meddles with AVPacket::data;
> - AVPacket::side_data is not ref-counted; because of such things as
> av_format_inject_global_side_data, it could make sense to have it
> separate from AVPacket::data ref-counting.
> 
> That last point is probably a major, API-breaking, undertaking. I have
> no plan to start on it, in particular because I feel unqualified for
> it.
> 
> Best regards,
> -- 
> Christophe

>  ffmpeg.c |    2 ++
>  1 file changed, 2 insertions(+)
> f1a906a5c330dff16b266f80e14e9f1727a3a3bf  0001-ffmpeg-fix-streamcopy-with-side-data.patch
> From 7848e2eed0780d5d2b3190b90174d580257a7ec9 Mon Sep 17 00:00:00 2001
> From: Christophe Gisquet <christophe.gisquet at gmail.com>
> Date: Wed, 13 Aug 2014 18:40:17 +0200
> Subject: [PATCH] ffmpeg: fix streamcopy with side data
> 
> The issue is that, when the main packet data buffer is changed, streamcopy
> uses a temporary new packet to store that buffer, frees the old packet, and
> replace it with the new packet.
> 
> However, in doing so, it forgets about the side data, which gets freed, but
> is still needed and referenced. Then, when the packet gets freed again in
> the normal code path, it attempts to free its side data which has already
> been freed.
> 
> Therefore, simply avoid the first free on side data by removing that side
> data from the packet.
> 
> Fixes ticket #3773.

patch looks correct

applied
thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140815/1a396f6b/attachment.asc>


More information about the ffmpeg-devel mailing list