It could also be a gstreamer-vaapi bug since it happens only since gstreamer 1.14, but I have seen nobody else complain anywhere, so it must work for some people at least. RX 480, recent mesa git revisions, Linux 4.15 - drm-next-4.18-wip To test: gst-launch-1.0 videotestsrc ! vaapih264enc ! "video/x-h264,profile=baseline" ! h264parse ! matroskamux ! filesink location=output.mkv With gstreamer 1.14 this never starts encoding and produces a 0 byte file when cancelling with ctrl+c. With gstreamer 1.12.4 it worked fine.
remco on #radeon figured out that it works when adding stream-format=byte-stream to the video format, like this: gst-launch-1.0 videotestsrc ! vaapih264enc ! "video/x-h264,profile=baseline,stream-format=byte-stream" ! h264parse ! matroskamux ! filesink location=output.mkv
I was on older gits for gstreamer when I saw this around 1.13<something> matroska and mp4mux didn't work, but raw 264 and avimux did. I updated to current gits before seeing the workaround and now it seems gstreamer produces junk whatever I do :-).
FWIW I found the "nothing works" cause = the next commit in gstreamer-vaapi after 1.14 tag = fa77b2bf vaapiencode: h264: find best profile in those available With that reverted the additional stream-format=byte-stream makes mkv/mp4 work again.
According to gstreamer IRC my issue is something that should be reported as a bug to gstreamer. Yours probably too.
Yea, I filed a bug for the gastreamer-vaapi regression https://bugzilla.gnome.org/show_bug.cgi?id=795340
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.