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 734608 - avvidec: decoded frames lost on EOS
avvidec: decoded frames lost on EOS
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
unspecified
Other Linux
: Normal normal
: 1.4.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-11 12:22 UTC by Aleix Conchillo Flaqué
Modified: 2014-08-12 07:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
reall keep trying to decode frames (1.37 KB, patch)
2014-08-11 12:23 UTC, Aleix Conchillo Flaqué
none Details | Review
test video (29.67 KB, video/quicktime)
2014-08-11 12:36 UTC, Aleix Conchillo Flaqué
  Details
frame loss on EOS (4.29 KB, patch)
2014-08-11 15:01 UTC, Aleix Conchillo Flaqué
committed Details | Review

Description Aleix Conchillo Flaqué 2014-08-11 12:22:35 UTC
When the videodecoder receives an EOS and has already pushed all the frames, it will call the decoder drain() function and then send EOS downstream.

avviddec has a try loop to get remaining frames. The loop stops when len=0 and have_data=0;

  if (len < 0 || have_data == 0)
    break;

This causes loss of buffers.
Comment 1 Aleix Conchillo Flaqué 2014-08-11 12:23:46 UTC
Created attachment 283088 [details] [review]
reall keep trying to decode frames

This is a simple fix. Not sure if correct but solves the issues and really keeps trying unless there's an error.
Comment 2 Aleix Conchillo Flaqué 2014-08-11 12:25:36 UTC
You can see the problem with any video, using a gst-launch with fakesink.

In 0.10 all frames are shown in the fakesink messages, but not in 1.x.
Comment 3 Sebastian Dröge (slomo) 2014-08-11 12:34:43 UTC
That would mean that libav returns no data for some calls in between but later does without getting more input. That seems weird.

Which codec is this? Do you have a sample stream you can share?
Comment 4 Aleix Conchillo Flaqué 2014-08-11 12:36:57 UTC
Created attachment 283091 [details]
test video

Video sample.
Comment 5 Aleix Conchillo Flaqué 2014-08-11 12:37:59 UTC
(In reply to comment #3)
> That would mean that libav returns no data for some calls in between but later
> does without getting more input. That seems weird.
> 
> Which codec is this? Do you have a sample stream you can share?

Yes, it is weird.

On the attached file, just run:

gst-launch-0.10 filesrc location=video-second.mov ! decodebin ! fakesink silent=false -v

and:

gst-launch-1.0 filesrc location=video-second.mov ! decodebin ! fakesink silent=false -v

Hopefully, you'll see that 1.0 doesn't show the last frames.
Comment 6 Aleix Conchillo Flaqué 2014-08-11 14:35:12 UTC
(In reply to comment #3)
> That would mean that libav returns no data for some calls in between but later
> does without getting more input. That seems weird.
> 

After some debugging, I think libav is returning have_data correctly. I'm now looking into gstavviddec. there might be something wrong there.
Comment 7 Aleix Conchillo Flaqué 2014-08-11 15:01:50 UTC
Created attachment 283110 [details] [review]
frame loss on EOS

From the commit log:

    have_data is not propagated from gst_ffmpegviddec_video_frame to
    gst_ffmpegviddec_frame. have_data is only set to 1 in
    gst_ffmpegviddec_frame if a frame pointer is passed. However, this is
    not true while draining, which means that have_data from libav will be
    ignored.
Comment 8 Sebastian Dröge (slomo) 2014-08-11 15:06:55 UTC
commit 1307b31e1cf9548ad3c9896fc0e9afe3d0516e40
Author: Aleix Conchillo Flaqué <aleix@oblong.com>
Date:   Mon Aug 11 14:16:55 2014 +0200

    avviddec: Don't lose frames on EOS
    
    have_data is not propagated from gst_ffmpegviddec_video_frame to
    gst_ffmpegviddec_frame. have_data is only set to 1 in
    gst_ffmpegviddec_frame if a frame pointer is passed. However, this is
    not true while draining, which means that have_data from libav will be
    ignored.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=734608