As can be seen in ticket:362#comment:6, it seems to be possible for a framewrapper to fall out of scope before it has been freed by avcodec.
This is caused by the buffer management code in #350 (r3976)
Please post log with XPRA_AVCODEC_DEBUG=1
for just 2 or 3 frames as per ticket:350#comment:6.
Do you need to use a specific application to trigger those warnings? Can you reproduce with a simple xterm? Did you apply any patches when you built the installer for win32? What version of ffmpeg did you build against? I've uploaded a new win32 beta - please compare this with your build.
Built new x264 and ffmpeg
ftp://ftp.videolan.org/pub/x264/snapshots/x264-snapshot-20130801-2245-stable.tar.bz2 http://www.ffmpeg.org/releases/ffmpeg-1.2.2.tar.bz2
No more AVFrameWrapper messages after packaging a new installer with r4041
Great - closing as INVALID
, must have been an old version of ffmpeg.
(may cause problems for us on some versions of libav/ffmpeg though..)
I see the problem with latest Archlinux (ffmpeg 2.0).
Please post some output with XPRA_AVCODEC_DEBUG=1
Edit by totaam: large comment moved to out-of-scope-debug.log attachment.
Is that enough?
It seems to me like this happens when a window is destroyed, or resized, right? Is this with ffmpeg 2.x? Can I get a bit more context?
What I think is happening is that when we clean the decoder context, we clone the pixel data which calls xpra_free()
, then when we call avcodec_close
it calls av_free()
and all is well. We lose all the references to the wrappers, they get garbage collected and we check that it is safe to free the reference (as the buffer should already have been freed by then).
That's on *my* version of ffmpeg... (Linux, OSX and win32)
But here, I am not seeing a single av_free
at all. It looks like the avcodec_release_buffer
function is never called.
This is with ffmpeg 2.0. I did not check if it happened when a window was destroyed or resized, but I think it is a reasonable assumption - I remember I got my terminal flooded with those messages when I resized a xterm from very small to very big.
I am closing this ticket after testing on most supported platforms with ffmpeg 1.2.x. If this problem re-occurs with a supported version of ffmpeg, then we can re-open this ticket.
Support for ffmpeg 2.0 is now moved to #415
Note: the buffer support change was messy (esp compat for older versions - patches, etc):
(actually closing it)
log sample for comment:7 (moving large waste of space comment to an attachment)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/398