After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689936 - avdec: leak when skipping frames while Video Decoding
avdec: leak when skipping frames while Video Decoding
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
1.0.3
Other Windows
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-12-09 16:41 UTC by Michael Rubinstein
Modified: 2013-12-01 13:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Rubinstein 2012-12-09 16:41:38 UTC
Memory was leaked in a pipeline that does MPEG2 Video decoding.  The leaks occurred when there was a discontinutiy in the input transport stream.

In /ext/libav/gstavviddec.c we're supposed to call either:
 gst_video_decoder_finish_frame or
 gst_video_decoder_drop_frame
to finish frame processing.

When qos processing determines that we should skip a frame, we, sometimes, don't call either function.

This results in a memory leak of, at least, GstVideoCodecFrame objects.

I'm not clear on how to handle the return values of avcodec_decode_video2, so I disabled frame skipping as an experiment.  That fixed the leak.

--- a/ext/libav/gstavviddec.c
+++ b/ext/libav/gstavviddec.c
@@ -1086,6 +1086,14 @@ gst_ffmpegviddec_video_frame (GstFFMpegVidDec * ffmpegdec,
    * else we might skip a reference frame */
   decode = gst_ffmpegviddec_do_qos (ffmpegdec, frame, &mode_switch);
 
+  // twc/mlr: temp
+  if (!decode)
+  {
+    GST_INFO("Not skipping");
+  }
+  decode = TRUE;
+  ffmpegdec->context->skip_frame = AVDISCARD_DEFAULT;
+
   if (ffmpegdec->is_realvideo && data != NULL) {
Comment 1 Sebastian Dröge (slomo) 2012-12-09 21:27:00 UTC
Does this fix it?
--- a/ext/libav/gstavviddec.c
+++ b/ext/libav/gstavviddec.c
@@ -1082,7 +1082,7 @@ gst_ffmpegviddec_video_frame (GstFFMpegVidDec * ffmpegdec,
 
   /* no data, we're done */
   if (len < 0 || have_data <= 0)
-    goto beach;
+    goto no_output;
 
   /* get the output picture timing info again */
   out_dframe = ffmpegdec->picture->opaque;
Comment 2 Michael Rubinstein 2012-12-10 12:30:03 UTC
Changing to "goto no_output" causes other problems.
It looks like we're skipping frames and I see lots of messages like:

0:00:05.739328000  7660    2d96f38 WARN            videodecoder gstvideodecoder.c:2246:gst_video_decoder_prepare_finish_frame:<bcst_vid_mpeg_decoder> decreasing timestamp (0:00:05.584468963 < 0:00:05.667880075)

In my previous testing I noticed that:
(len < 0 || have_data <= 0)
was often true during normal, not leaking, operation.

I'm curious, I noticed "goto beach" in several places.  What does the word "beach" refer to?
Comment 3 Sebastian Dröge (slomo) 2012-12-10 14:21:50 UTC
Oh right, hm. We somehow need a different way of knowing when libav dropped a frame (and which)

The "beach" label is just used as an alternative to "exit" or something like that. "go out of here asap" :)
Comment 4 Mark Nauwelaerts 2013-12-01 11:16:17 UTC
Due to improved cleaning of pending frames, this should be fixed along with bug #693772.

Feel free to re-open if somehow not the case.