[FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-01 Thread Derek Buitenhuis
This fixes a double free in he error case. Signed-off-by: Derek Buitenhuis --- This does fix the double free, but I am unsure if it is the correct free to removed to fix it. Comments welcome. --- libavfilter/vf_paletteuse.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavfilter/vf_palett

Re: [FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-02 Thread Nicolas George
Derek Buitenhuis (2018-01-01): > This fixes a double free in he error case. > > Signed-off-by: Derek Buitenhuis > --- > This does fix the double free, but I am unsure if it is the correct free > to removed to fix it. Comments welcome. > --- > libavfilter/vf_paletteuse.c | 1 - > 1 file changed,

Re: [FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-02 Thread Clément Bœsch
On Mon, Jan 01, 2018 at 11:28:37AM -0500, Derek Buitenhuis wrote: > This fixes a double free in he error case. > > Signed-off-by: Derek Buitenhuis > --- > This does fix the double free, but I am unsure if it is the correct free > to removed to fix it. Comments welcome. > --- > libavfilter/vf_pal

Re: [FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 9:53 PM, Clément Bœsch wrote: > That's some weird ownership semantic for the error-path, but Nicolas knows > better this API so I'll trust him on this one. Yeah it was weird for me to, but I looked into its implementation to find out. - Derek __

Re: [FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-03 Thread Nicolas George
Clement Boesch (2018-01-02): > That's some weird ownership semantic for the error-path, but Nicolas knows > better this API so I'll trust him on this one. I agree it is not the most obvious behaviour, but it is the most convenient with the logic of dualinput (which you introduced, IIRC, based on t