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 766190 - vtdec: corrupted rendering on OSX
vtdec: corrupted rendering on OSX
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal blocker
: 1.8.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-09 17:39 UTC by Philippe Normand
Modified: 2016-06-02 07:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vt*:5,videodecoder:6 log (831.05 KB, text/plain)
2016-05-10 06:33 UTC, Philippe Normand
Details

Description Philippe Normand 2016-05-09 17:39:04 UTC
When the video dimensions change the rendering gets corrupted and all I see is a green rectangle in the video window.

This is easy to reproduce on a smooth-streaming sample with playbin, such as: http://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest

A video with fixed dimensions renders fine here.
Comment 1 Philippe Normand 2016-05-09 17:40:14 UTC
For a short moment I can see the first video frame correctly rendered but then everything goes HULK :/
Comment 2 Philippe Normand 2016-05-10 06:30:21 UTC
This appears to be a regression due to:

commit 5228238715a3d73bbfe9a7de1c02941096e95576
Author: Alessandro Decina <alessandro.d@gmail.com>
Date:   Wed May 4 11:30:11 2016 +1000

    applemedia: vtdec: output sysmem by default
Comment 3 Philippe Normand 2016-05-10 06:33:26 UTC
Created attachment 327556 [details]
vt*:5,videodecoder:6 log
Comment 4 Alessandro Decina 2016-06-02 03:16:18 UTC
This commit fixes the green frames

commit 4a83686a57818e182672b25e5040ea5ba0141f03
Author: Alessandro Decina <alessandro.d@gmail.com>
Date:   Thu Jun 2 13:10:51 2016 +1000

    vtdec: fix switching from GLMemory to Sysmem

    When renegotiating from GLMemory to Sysmem do teardown the texture_cache.

    Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=766190
Comment 5 Alessandro Decina 2016-06-02 06:38:54 UTC
This fixes another issue with multiple bitrate streams

commit 3d8d60baa87442b5a38383309481bc15c3fade15
Author: Alessandro Decina <alessandro.d@gmail.com>
Date:   Thu Jun 2 16:30:02 2016 +1000

    vtdec: make vtdec_hw fallback to software on renegotiation

    When renegotiating mid stream - for example with variable bitrate
    streams - and therefore destroying and recreating VTSessions, the
    hw decoder might become temporarily unavailable.

    To deal with this and avoid erroring out on bitrate changes,
    vtdec_hw now falls back to using the software decoder if the hw
    one was available at some point but isn't anymore. At
    renegotiation/bitrate change time, it will still retry to open
    the hardware one.
Comment 6 Alessandro Decina 2016-06-02 07:03:28 UTC
And one more which minimizes the number of VTSessions recreated during negotiation

commit bf44430
Author: Alessandro Decina <alessandro.d@gmail.com>
Date:   Thu Jun 2 11:36:57 2016 +1000

    vtdec: optimize renegotiation

    ::negotiate can be called several times before the CAPS event is sent downstream
    so use the currently configured output state caps instead of the pad current
    caps when deciding whether to recreate the VTSession or not.

    This leads to creating/destroying less VTSessions which makes renegotiation more
    reliable especially when using hw decoding.