Thanks for reporting this.

I see you are using the gallium driver. Which graphics card are you using? Is it a Nvidia?

(In reply to Víctor Manuel Jáquez Leal from comment #1) 
> I see you are using the gallium driver. Which graphics card are you using?
> Is it a Nvidia?

No. This is a AMD Radeon HD 6310M (AMD PALM), integrated into AMD E-350 processor.

$ glxinfo
[...]
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD PALM (DRM 2.43.0 / 4.5.5-300.fc24.x86_64, LLVM 3.8.0) (0x9802)
    Version: 11.3.0
    Accelerated: yes
    Video memory: 384MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
[...]

(In reply to Egor Zaharov from comment #2)
> No. This is a AMD Radeon HD 6310M (AMD PALM), integrated into AMD E-350
> processor.

I'm afraid that hardware and the gallium driver are not well tested in gstreamer-vaapi, but I'm all to support them.

Can you upload the log output of this command:

gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=clutterautovideosink --gst-debug=vaapi*:5 --gst-debug-no-color

Created attachment 328877 [details]
Output of gst-play-1.0

(In reply to Víctor Manuel Jáquez Leal from comment #3)
> Can you upload the log output of this command:
> 
> gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=clutterautovideosink
> --gst-debug=vaapi*:5 --gst-debug-no-color

Done.

$ rpm -q gstreamer1-vaapi
gstreamer1-vaapi-1.8.1-1.fc24.x86_64

Thanks. This is interesting: two things

1)  "vaGetSurfaceBufferWl(): the requested function is not implemented"

It seems that the gallium backend doesn't support Wayland.

2) Sadly, my pipeline is not correct for your setup, because it used vaapisink sink, not cluttersink. Could you upload the output of this command too?

GST_DEBUG_NO_COLOR=1 GST_DEBUG=vaapi*:5 totem Ad\ that\ make\ me\ mad.mp4

Created attachment 328886 [details]
Output of totem

(In reply to Víctor Manuel Jáquez Leal from comment #5)
> Thanks. This is interesting: two things
> 
> 1)  "vaGetSurfaceBufferWl(): the requested function is not implemented"
> 
> It seems that the gallium backend doesn't support Wayland.

Well, this is something. How does it work under mpv then?

When patches for support of DRI3 at gallium video driver landed, someone removed `return VA_STATUS_ERROR_UNIMPLEMENTED;` from Wayland case. [1]

But still, SurfaceBuffer for Wayland is UNIMPLEMENTED. And this is weird.

> 2) Sadly, my pipeline is not correct for your setup, because it used
> vaapisink sink, not cluttersink. Could you upload the output of this command
> too?
> 
> GST_DEBUG_NO_COLOR=1 GST_DEBUG=vaapi*:5 totem Ad\ that\ make\ me\ mad.mp4

Done. There was a black screen. But audio played fine, until it stopped at 0:19. And I closed it.


[1]: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/context.c?id=2cee0d0f9c9e9e269885b1d943ff123e033d9b52#n129

Comment on attachment 328886 [details]
Output of totem

GLTextureUpload is negotiated, so it tries to upload the VASurface into a pixmap and then onto a texture, but it fails:

 "vaPutImage(): resource allocation failed"

(In reply to Egor Zaharov from comment #6)
> Created attachment 328886 [details]
> Output of totem
> 
> (In reply to Víctor Manuel Jáquez Leal from comment #5)
> > Thanks. This is interesting: two things
> > 
> > 1)  "vaGetSurfaceBufferWl(): the requested function is not implemented"
> > 
> > It seems that the gallium backend doesn't support Wayland.
> 
> Well, this is something. How does it work under mpv then?

Three hypothesis: 

1\ mpv uses vdpau natively
2\ mpv uses vaapi but it downloads the VASurfaces into system memory buffers
3\ mpv uses vaapi and support the dmabuf exportation into a EGLImage

I place my chips on 1.

> When patches for support of DRI3 at gallium video driver landed, someone
> removed `return VA_STATUS_ERROR_UNIMPLEMENTED;` from Wayland case. [1]
> 
> But still, SurfaceBuffer for Wayland is UNIMPLEMENTED. And this is weird.

Perhaps gallium driver supports the "download to system memory buffers" use-case.

You can test it with

gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=waylandsink

As these issues seems to be related with the gallium driver, let's close this bug. If you think that something should be done in gstreamer-vaapi on this regard, please re-open the bug.

(In reply to Víctor Manuel Jáquez Leal from comment #8)
> Three hypothesis: 
> 
> 1\ mpv uses vdpau natively

Nope.

$ mpv --hwdec=vaapi Ad\ that\ make\ me\ mad.mp4
Playing: Ad that make me mad.mp4
 (+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=und (*) (aac)
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
AO: [pulse] 44100Hz stereo 2ch float
Using hardware decoding (vaapi).
VO: [opengl] 1280x720 vaapi
AV: 00:00:39 / 00:00:51 (77%) A-V:  0.000
Track switched:
 (+) Video --vid=1 (*) (h264)
     Audio --aid=1 --alang=und (*) (aac)
V: 00:00:41 / 00:00:51 (80%)
Track switched:
 (+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=und (*) (aac)
AO: [pulse] 44100Hz stereo 2ch float
AV: 00:00:47 / 00:00:51 (93%) A-V:  0.000 ct:  0.080


Exiting... (Quit)

And the video plays fine. And based on that output, we can tell what it's uses OpenGL to output video.

> > When patches for support of DRI3 at gallium video driver landed, someone
> > removed `return VA_STATUS_ERROR_UNIMPLEMENTED;` from Wayland case. [1]
> > 
> > But still, SurfaceBuffer for Wayland is UNIMPLEMENTED. And this is weird.
> 
> Perhaps gallium driver supports the "download to system memory buffers"
> use-case.
> 
> You can test it with
> 
> gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=waylandsink

This does not work.

$ gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=waylandsink
Press 'k' to see a list of keyboard shortcuts.
Now playing /home/nexfwall/Downloads/Ad that make me mad.mp4
WARNING Could not initialise Wayland output
WARNING debug information: gstwaylandsink.c(289): gst_wayland_sink_find_display (): /GstWaylandSink:waylandsink0:
Failed to create GstWlDisplay: 'Failed to connect to the wayland display '(default)''

(In reply to Víctor Manuel Jáquez Leal from comment #9)
> As these issues seems to be related with the gallium driver, let's close
> this bug. If you think that something should be done in gstreamer-vaapi on
> this regard, please re-open the bug.

If we can figure out how mpv does this, we can do a fallback workaround, maybe?

Oh, I made a mistake in comment 10. I forgot what I had switched back to X temporarily. So, the output of programs is all wrong.

I did it again under Wayland, and here is the real output:

$ mpv --hwdec=vaapi Ad\ that\ make\ me\ mad.mp4
Playing: Ad that make me mad.mp4
 (+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=und (*) (aac)
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[vo/opengl/vaapi-egl] vaDeriveImage(): invalid VASurfaceID
[vo/opengl/vaapi-egl] mapping VAAPI EGL image failed
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[vo/opengl/vaapi-egl] vaDeriveImage(): invalid VASurfaceID
[vo/opengl/vaapi-egl] mapping VAAPI EGL image failed
VO does not support requested hardware decoder, or loading it failed.
AO: [pulse] 44100Hz stereo 2ch float
Using software decoding.
VO: [opengl] 1280x720 yuv420p
AV: 00:00:51 / 00:00:51 (99%) A-V:  0.000 Dropped: 5


Exiting... (End of file)

So, VAAPI does not work at all in Wayland. I had decided what this is working, because I had used gnome-mpv. And I did'nt saw this output at all in terminal.

But gstreamer1(or at least totem) does not want to fall back to other ways of playing this video so easily. And then vaapisink fails to play this video, this is fatal.

I don't know is this behaviour is bad, but at least it's strange. So, if VAAPI does not work at the moment, you can't play videos at all. Or need to know how these debug ENV variables work, to force gstreamer to use working sink.

But still, gst-play-1.0 can't do this in Wayland.

$ gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=waylandsink
Press 'k' to see a list of keyboard shortcuts.
Now playing /home/nexfwall/Downloads/Ad that make me mad.mp4
WARNING Could not initialise Wayland output
WARNING debug information: gstwaylandsink.c(289): gst_wayland_sink_find_display (): /GstWaylandSink:waylandsink0:
Failed to create GstWlDisplay: 'Could not bind to wl_scaler. Either it is not implemented in the compositor, or the implemented version doesn't match'

I'm openning a new bug at Freedesktop. Maybe someone there can help with my problem, or just implement needed functionality.

Because, personally, only not working VAAPI holds me back from using Wayland every day.

https://bugs.freedesktop.org/show_bug.cgi?id=96350

(In reply to Egor Zaharov from comment #10)
> $ mpv --hwdec=vaapi Ad\ that\ make\ me\ mad.mp4
> Playing: Ad that make me mad.mp4
>  (+) Video --vid=1 (*) (h264)
>  (+) Audio --aid=1 --alang=und (*) (aac)
> libva info: VA-API version 0.39.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/r600_drv_video.so <---
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0

Please note that in this case, libva loads the libva-xvba-driver. And it works in X.

(In reply to Egor Zaharov from comment #12)
> $ mpv --hwdec=vaapi Ad\ that\ make\ me\ mad.mp4
> Playing: Ad that make me mad.mp4
>  (+) Video --vid=1 (*) (h264)
>  (+) Audio --aid=1 --alang=und (*) (aac)
> libva info: VA-API version 0.39.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so <--
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0

And when you switch to Wayland, libva loads the libva-mesa-driver. Why?

Are you exporting different LIBVA_DRIVER_NAME variables per session?

> So, VAAPI does not work at all in Wayland. 

Just to be exact (or nitpicking), libva supports Wayland, but the available drivers for your hardware do not.

And I forgot that vdpau doesn't work with Wayland, at least in downstream (there are patches in upstream for the library, but I don't know the state of drivers).

> But gstreamer1(or at least totem) does not want to fall back to other ways
> of playing this video so easily. And then vaapisink fails to play this
> video, this is fatal.
> 
> I don't know is this behaviour is bad, but at least it's strange. So, if
> VAAPI does not work at the moment, you can't play videos at all. Or need to
> know how these debug ENV variables work, to force gstreamer to use working
> sink.

Yes, it is bad. That is why, in master, we already landed a patch which bails out the gstreamer-vaapi elements when the driver is not in a "white-list", and only the intel and gallium drivers are in that list (bug 764673).

> 
> But still, gst-play-1.0 can't do this in Wayland.
> 
> $ gst-play-1.0 Ad\ that\ make\ me\ mad.mp4  --videosink=waylandsink
> Press 'k' to see a list of keyboard shortcuts.
> Now playing /home/nexfwall/Downloads/Ad that make me mad.mp4
> WARNING Could not initialise Wayland output
> WARNING debug information: gstwaylandsink.c(289):
> gst_wayland_sink_find_display (): /GstWaylandSink:waylandsink0:
> Failed to create GstWlDisplay: 'Could not bind to wl_scaler. Either it is
> not implemented in the compositor, or the implemented version doesn't match'

mmmh... waylandsink needs the scaler extension and your setup doesn't provide it. I wonder why. But that is another issue.

(In reply to Egor Zaharov from comment #13)
> I'm openning a new bug at Freedesktop. Maybe someone there can help with my
> problem, or just implement needed functionality.

Good.

> Because, personally, only not working VAAPI holds me back from using Wayland
> every day.

You can use the software decoders. But yeah, it would be much better if the drivers get in shape.

(In reply to Víctor Manuel Jáquez Leal from comment #14)
> Please note that in this case, libva loads the libva-xvba-driver. And it
> works in X.

Nope. This is my `r600_drv_video.so -> gallium_drv_video.so` symlink. This was done to avoid problems, when programs trying to poke r600 driver for va and does not find it. But later I've done LIBVA_DRIVER_NAME export using systemd user.conf DefaultEnvironment. And forgot about it.

I don't know why in this particular case this ENV variable was not exported. But it's still the same gallium driver.

And, I don't know what libva-xvba-driver is at all, because it does not exist on Fedora.

> > So, VAAPI does not work at all in Wayland. 
> 
> Just to be exact (or nitpicking), libva supports Wayland, but the available
> drivers for your hardware do not.

Yep. I'm talking about driver, not the libva itself.

But also, later I found, what VAAPI is working on Wayland in mpv. But only of you use "vaapi" video output (vo). I don't know what kind of "magic" it uses to do that, but it was actually working. But forgot to save the output. If you need it, I can try again.

> Yes, it is bad. That is why, in master, we already landed a patch which
> bails out the gstreamer-vaapi elements when the driver is not in a
> "white-list", and only the intel and gallium drivers are in that list (bug
> 764673).

And if driver is in white list, and fails to play video, Gstreamer will not try to fall back to software decoding? Maybe I just misunderstood you (damn language barrier), that is not what I meant.

I think gstreamer-vaapi can't be installed by default in distribution, only because if it fails, then this is fatal. E.g. if this kind of hardware does not have video decoding capatibilities, or just fails because of the driver, then it can't play the video at all. But it should not be like that.

I think if it fails to play video using hardware acceleration, Gstreamer should try to fall back to other plugin/sink which CAN play this codec. E.g. software implementation. Just like mpv did it.

And then, the distributions can install it by default, without the fear what user will get his Totem (or other gstreamer-based player) not playing videos. Just a WARNING (output? dialog with "do not show this again" tick?) when it can't do so using vaapi.

> mmmh... waylandsink needs the scaler extension and your setup doesn't
> provide it. I wonder why. But that is another issue.

This is Fedora 24, if you wonder. You can check why. But I don't understand what is wrong.

> > Because, personally, only not working VAAPI holds me back from using Wayland
> > every day.
> 
> You can use the software decoders. But yeah, it would be much better if the
> drivers get in shape.

Software decoders can do it, but it will mean more CPU usage. And it feels like I wasted it, because my hardware actually can decode it.

Hardware decoding saves CPU, so you can just leave your Firefox opened, while you playing your favourite serial/anime in player. AMD E-350 is not beefy, it's meant for low-cost machines and netbooks.

Also, Firefox can use gstreamer, so it kind of can use this plugin too.

(In reply to Egor Zaharov from comment #15)
> 
> > Yes, it is bad. That is why, in master, we already landed a patch which
> > bails out the gstreamer-vaapi elements when the driver is not in a
> > "white-list", and only the intel and gallium drivers are in that list (bug
> > 764673).
> 
> And if driver is in white list, and fails to play video, Gstreamer will not
> try to fall back to software decoding? Maybe I just misunderstood you (damn
> language barrier), that is not what I meant.

If the play fails in a white-listed drive then it is a bug that need to be addressed either in gstreamer-vaapi or the driver.

We did the white-list because there are unmantained drivers. But it is not you case, the problem is to fix something in the gallium driver when Wayland is used.

> I think gstreamer-vaapi can't be installed by default in distribution, only
> because if it fails, then this is fatal. E.g. if this kind of hardware does
> not have video decoding capatibilities, or just fails because of the driver,
> then it can't play the video at all. But it should not be like that.

Right now, with vaapidecode, if a codec is not supported by the hardware, the element bails and decobebin will try another decoder.

(In reply to Víctor Manuel Jáquez Leal from comment #16)
> If the play fails in a white-listed drive then it is a bug that need to be
> addressed either in gstreamer-vaapi or the driver.
> 
> We did the white-list because there are unmantained drivers. But it is not
> you case, the problem is to fix something in the gallium driver when Wayland
> is used.

I just saying, what if driver fails to play the video because of internal problems (not because the driver can't decode this codec, as you stated below), this fail should not be fatal, and prevent the video playback. But show a warning dialog, there clearly states, what this is a bad thing, and you should report it, because this should not happen. And, if possible (I'm kinda read the K&R book, but still not a developer, so maybe I'm just talking nonsense), throw an error, which "bug catcher" software like ABRT will catch, and offer user to send a report. But still does not close the player.

And then the user clicks OK button, gstreamer will try to look for a software decoder alternative to play it. And if user did put a tick on "don't show this again", just throw error for "bug catcher" silently, but don't show the dialog.

This is just my opinion on how this should work. I don't saying this is the only way. It's just how I see the things.

> Right now, with vaapidecode, if a codec is not supported by the hardware,
> the element bails and decobebin will try another decoder.

Okay. I got it. Thanks for the explanation.