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 732130 - vaapidecode: h.264 streams have stuttering playback
vaapidecode: h.264 streams have stuttering playback
Status: RESOLVED FIXED
Product: gstreamer-vaapi
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks: 720305
 
 
Reported: 2014-06-23 21:00 UTC by Joseph McDonald
Modified: 2014-06-25 21:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decoder: h264: fix marking of non-reference picture into DP (1.61 KB, patch)
2014-06-25 20:48 UTC, Gwenole Beauchesne
none Details | Review

Description Joseph McDonald 2014-06-23 21:00:32 UTC
No issues observed prior to 0.5.8, but at some point during the recent h264 modifications to the h264 decoder something has broken where now all my streams playback in a very stuttery way.  Ideally this would be rectified before release of 0.5.9

Basic background information:
Platform: Ubuntu 14.04
Gstreamer: 1.3.2 (GIT)
Gstreamer-vaapi: git-master (compared to 0.5.8 to confirm issue is recent).  

Stream information:
test_src1.ts
Format                                   : AVC
Format profile                           : High@L4.0
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 fps
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Color primaries                          : BT.709

test_src2.mp4
Format                                   : AVC
Format profile                           : High@L4.0
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 59.940 fps
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Color primaries                          : BT.709

test_src3.mp4
Format                                   : AVC
Format profile                           : High@L5.0
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 24.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Stream size                              : 13.1 MiB (94%)
Writing library                          : x264 core 94 r1583 7608d73
Comment 1 Joseph McDonald 2014-06-23 21:09:19 UTC
Of note, the CPU/GPU utilization is the same between the two versions of vaapidecode, no notification of dropped buffers is observed during playback and no errors/warnings are shown with GST_DEBUG=*vaapi*:5
Comment 2 Gwenole Beauchesne 2014-06-24 04:01:09 UTC
Hi, is there a way to get some of the streams that exhibit the reported behaviour? Thanks.
Comment 3 Gwenole Beauchesne 2014-06-24 04:13:17 UTC
BTW, are you using playbin (including vaapisink) or some other sink element?
Comment 4 Joseph McDonald 2014-06-25 02:24:14 UTC
Hi Gwenole,

One of the test streams is the h264 encoded Sintel Trailer available here:
http://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4

As for my test pipeline, I'm not using playbin or decodebin (although if they use vaapidecode they show the same behavior).  My test pipeline is as follows:

gst-launch-1.0 filesrc location=sintel_trailer-1080p.mp4 ! qtdemux ! vaapidecode ! vaapisink
Comment 5 Gwenole Beauchesne 2014-06-25 04:06:06 UTC
(In reply to comment #4)
> One of the test streams is the h264 encoded Sintel Trailer available here:
> http://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4

Could you please provide the md5sum of the file you use? And possibly the name of the mirror server you used?

Reason:
In my experience, on this specific trailer (and 720p), the videos are not fully the same from server to server. i.e. some of them are encoded differently. :)

> As for my test pipeline, I'm not using playbin or decodebin (although if they
> use vaapidecode they show the same behavior).  My test pipeline is as follows:
> 
> gst-launch-1.0 filesrc location=sintel_trailer-1080p.mp4 ! qtdemux !
> vaapidecode ! vaapisink

OK thanks, I will have a look.
Comment 6 Gwenole Beauchesne 2014-06-25 14:13:12 UTC
Confirmed. I will look into it. Thanks.
Comment 7 Gwenole Beauchesne 2014-06-25 20:48:41 UTC
Created attachment 279265 [details] [review]
decoder: h264: fix marking of non-reference picture into DP

This patches fixes your issue. Would you mind trying with your other clips that had issues too? Thanks.

Another factorization is possible but I would like you to verify this one first. :)
Comment 8 Joseph McDonald 2014-06-25 21:07:54 UTC
On the test streams I have available that patch appears to rectify the problem.  

Thanks!
Comment 9 Gwenole Beauchesne 2014-06-25 21:23:49 UTC
commit bea0d07042862be1fb741647bb5a7a3b8b014bce
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Wed Jun 25 22:26:32 2014 +0200

    decoder: h264: fix marking of non-reference picture into DPB.
    
    Fix search for a picture in the DPB that has a lower POC value than
    the current picture. The dpb_find_lowest_poc() function will return
    a picture with the lowest POC in DPB and that is marked as "needed
    for output", but an additional check against the actual POC value
    of the current picture is needed.
    
    This is a regression from 1c46990.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=732130