gstreamer-vaapi on AMD

[David W. Harks]

With rapier wit and elegant prose, Sebastian Dröge wrote:
> On Do, 2014-05-22 at 10:40 -0500, David W. Harks wrote:
> > With rapier wit and elegant prose, Sebastian Dröge wrote:
> > > On Mi, 2014-05-21 at 15:38 -0500, David W. Harks wrote:
> > > > I was trying to play an H.264 video today using gstreamer-vaapi master from git. It fails for me, and I’m not sure where else to look to understand why. How can I debug this further? I’ve included the debug output from vaapidecode and vainfo output from my system. (I’m on an AMD-based system; using the fglrx driver, with XvBA.)
> > > > 
> > > > Thanks in advance for any pointers!
> > > > 
> > > > -d
> > > > 
> > > > Using Gst: 1.3.2.1
> > > > 
> > > > GST_DEBUG=vaapidecode:5 gst-launch-1.0 playbin uri=file:///scratch/excite/content/Trickshots_02_h264_rf20.mp4
> > > > [...]
> > > 
> > > Does it work with a manual pipeline that uses vaapisink?
> > > 
> > > > gst-launch-1.0 filesrc location=/scratch/excite/content/Trickshots_02_h264_rf20.mp4 ! qtdemux ! queue ! vaapidecode ! queue ! vaapisink
> > 
> > Yes, this works, but at the end of the stream, gst-launch gives me:
> > 
> > xvba_video: XVBA_DestroySurface(): status 2
> > 
> > and then does not exit cleanly.
> 
> Thanks, could you file a bug about that at http://bugzilla.gnome.org
> against gstreamer-vaapi?

Done. See https://bugzilla.gnome.org/show_bug.cgi?id=730650 .

I did some further digging and included a trace from xvba-driver and a
stack trace from GDB that shows a deadlock and corrupted stack when
XVBA_DestroySurface() returns that status of 2.

If there's anything else I can do to help get to the bottom of this,
please let me know. The system I'm working on has a CPU that's too weak
to do what we want without using the hardware acceleration, and this
issue makes things very dicey -- if we hit EOS, we are locked up.

Thanks!