mpv, vlc players show constant errors every .5 sec:

[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20
[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20
[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20

I'm just a user, so take this with a grain of salt, but I found that radeon with vaapi only works with the nv12 color format and produces something broken like this with i420.

The last time I tried it, vaapipostproc format=nv12 did not work, so I had to do the color space conversion on the CPU with videoconvert.

Here is a pipeline that last worked for me:

gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! videoconvert ! video/x-raw,framerate=60/1,format=NV12 ! vaapih264enc ! h264parse ! matroskamux ! filesink location=output.avi

Can't really test right now because it hangs my GPU, but I see it saves one frame that has this vertically doubled image too, with correct colors though.

(In reply to Christoph Haag from comment #2)
> I'm just a user, so take this with a grain of salt, but I found that radeon
> with vaapi only works with the nv12 color format and produces something
> broken like this with i420.
> 
> The last time I tried it, vaapipostproc format=nv12 did not work, so I had
> to do the color space conversion on the CPU with videoconvert.
> 
> Here is a pipeline that last worked for me:
> 
> gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0
> endx=1919 endy=1079 ! videoconvert ! video/x-raw,framerate=60/1,format=NV12
> ! vaapih264enc ! h264parse ! matroskamux ! filesink location=output.avi
> 
> Can't really test right now because it hangs my GPU, but I see it saves one
> frame that has this vertically doubled image too, with correct colors though.

Tested, it produces similar corrupted video.

Since recentish mesa change you have to set the env

VAAPI_DISABLE_INTERLACE=1

(In reply to Andy Furniss from comment #4)
> Since recentish mesa change you have to set the env
> 
> VAAPI_DISABLE_INTERLACE=1

You will still need to feed the encoder NV12 as well.

(In reply to Andy Furniss from comment #5)
> (In reply to Andy Furniss from comment #4)
> > Since recentish mesa change you have to set the env
> > 
> > VAAPI_DISABLE_INTERLACE=1
> 
> You will still need to feed the encoder NV12 as well.

Though I420 will work, it may be better to let gstreamer convert the BGRx as it may be faster than letting the driver do it. The driver will just use C gstreamer may (or may not) use SIMD.

(In reply to Andy Furniss from comment #6)
> (In reply to Andy Furniss from comment #5)
> > (In reply to Andy Furniss from comment #4)
> > > Since recentish mesa change you have to set the env
> > > 
> > > VAAPI_DISABLE_INTERLACE=1
> > 
> > You will still need to feed the encoder NV12 as well.
> 
> Though I420 will work, it may be better to let gstreamer convert the BGRx as
> it may be faster than letting the driver do it. The driver will just use C
> gstreamer may (or may not) use SIMD.

LOL fail post, to clarify, the driver will not convert BGRx to anything (would be a nice feature if the GPU could do it).

If you tell gstreamer to convert BGRx to I420 then the driver will just change it to nv12 using CPU C code, so you may as well tell gstreamer to convert to  NV12 in the first place.

(In reply to Tom from comment #1)
> mpv, vlc players show constant errors every .5 sec:
> 
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20

If your gstreamer is the latest, they have changed the default profile from baseline to high which tries to use b-frames, but they are not yet supported/working.

I don't think dct8x8=true will do anything, though I could be wrong.

I notice your command used matroskamux, which is good, but you call the file mp4 - it will likely ignpre that and make mkv. For screen recording with gstreamer I would avoid mp4 as when you stop it it hasn't for me finalized properly = unplayable file. Maybe I am just crap with gstreamer and control c is not the best way to stop it!

Something like this should work, though 3Mbit will be way too low if much is happening when recording recording 1080p60, cqp may be a better choice - but then it will potentially use far more bits and everything may grind to a halt (by default) when Linux does one of its all stopping flushes to disk (though there are workarounds)

Pasted from notes, not intended to be better that anything else, just an example - could/should be improved as needed (eg. how to use 709 for CSC as players will tend to assume 1080p is 709.

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! queue ! videoconvert ! video/x-raw,framerate=60/1,format=NV12  ! queue ! vaapih264enc rate-control=cbr bitrate=3000 ! video/x-h264,profile=baseline ! h264parse ! matroskamux ! filesink location=out.mkv

(In reply to Christoph Haag from comment #2)
> I'm just a user, so take this with a grain of salt, but I found that radeon
> with vaapi only works with the nv12 color format and produces something
> broken like this with i420.

There was a bug with I420 that reversed U and V, but that's fixed now - though NV12 is still the format the enc needs so where you have a choice is best.

(In reply to Andy Furniss from comment #9)
> (In reply to Christoph Haag from comment #2)
> > I'm just a user, so take this with a grain of salt, but I found that radeon
> > with vaapi only works with the nv12 color format and produces something
> > broken like this with i420.
> 
> There was a bug with I420 that reversed U and V, but that's fixed now -
> though NV12 is still the format the enc needs so where you have a choice is
> best.

Thank you Andy for explanation. After setting env var VAAPI_DISABLE_INTERLACE video looks correctly. You're right about video format it should be mkv. I'll experiment more with this and I'll try to get smoother motion in videos. In metadata I can see that videos are 60 fps but for my eyes they look like 30 fps. Maybe X11 frames are not captured efficiently. Thank you again for help with resolving it.

(In reply to Tom from comment #10)

> Thank you Andy for explanation. After setting env var
> VAAPI_DISABLE_INTERLACE video looks correctly. You're right about video
> format it should be mkv. I'll experiment more with this and I'll try to get
> smoother motion in videos. In metadata I can see that videos are 60 fps but
> for my eyes they look like 30 fps. Maybe X11 frames are not captured
> efficiently. Thank you again for help with resolving it.

The CPU X11 grabbing and NV12 conversion are quite expensive and single threaded.

On my old Phenom II x4 3.4GHz CPUs forced to perf (cpufreq) I get about 69 fps testing like -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 endy=1079 num-buffers=1000 ! queue ! videoconvert ! video/x-raw,framerate=100/1,format=NV12  ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.408948605

1000/14.408948605 = 69.4

You could extend the test to include encode to fakesink and see what you get.

I would try cqp (default 26) as well as cbr.

If you can do the first test OK but not with encode maybe start playing with forcing GPU to high rather than auto.

Also omx may be a bit faster if you can get that to work - it should, what is in your /etc/xdg/gstomx.conf?

omx doesn't work properly with cbr. You can control cqp as needed, plus b-frames work with omx maybe "free" for bonaire (but will be x2 slower with more recent GPUs than yours).

Thanks for your tips, quite some new information for me.

I am using this pipeline now:
gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12,framerate=60/1 ! multiqueue ! vaapih264enc rate-control=cqp bitrate=5000 ! video/x-h264,profile=baseline ! h264parse ! multiqueue ! matroskamux name=muxer. ! progressreport name=Rec_time ! filesink location=output.mkv

This one runs nicely and doesn't cause GPU hangs.


Are we using this bug report to talk about omx too?

This is my equivalent omx pipeline:
gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12,framerate=60/1 ! multiqueue ! omxh264enc control-rate=2 target-bitrate=11000000 ! h264parse ! multiqueue ! matroskamux name=muxer. ! progressreport name=Rec_time ! filesink location=output.mkv

omxregister-bellagio produces a broken ~/.omxregister for me, but it really only needs to be a text file with two lines:

/usr/lib/bellagio/libomxvideosched.so
/usr/lib/bellagio/libomx_mesa.so

Sometimes (?) the gst-omx plugin is blacklisted. Check with gst-inspect-1.0 | grep omx whether there is something. If not, delete ~/.cache/gstreamer-1.0/registry.x86_64.bin and try again.

That's all I know about reasons omx may not be working.


For the performance, there is a chance you're also affected by bug 97075. Try running
vblank_mode=0 glxgears
and then starting the encoding. Make sure it's really not throttled to 60 fps. Either it improves the performance of the hardware encoder a lot or it does nothing.

Good tips on OMX, in the past (maybe because I had gstomx.conf in the wrong place) I've seen it randomly stop working because my browser tried to use gstreamer.

For Christoph on Polaris10 you may sometime hit this dual instance issue with vaapi -

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

I notice your first example above is slightly wrong should be cbr

rate-control=cqp bitrate=5000

While OMX may appear to work with cbr IME it doesn't work properly = you don't end up getting the rate you asked for other than by luck.

(In reply to Andy Furniss from comment #13)

> While OMX may appear to work with cbr IME it doesn't work properly = you
> don't end up getting the rate you asked for other than by luck.

While testing with just one sample is probably not the best thing - I just revisited this and it does seem to work as long as bitrate isn't too high max 85M.

Though I have vague memories of thinking it was OK before and then it went inconsistent.

It could be because OMX does less/different setup of the h/w compared to vaapi WRT rate control/hrd stuff (I have see this by adding printfs) and when testing vaapi and omx some stated get carried over between the two.

(In reply to Andy Furniss from comment #14)

> While testing with just one sample is probably not the best thing - I just
> revisited this and it does seem to work as long as bitrate isn't too high
> max 85M.

It seems that cbr with omx doesn't work with dual instance (cards newer or = TONGA). though the file sizes were OK up to a point the quality was terrible, with corruption.

Maybe bonaire will be OK, but another difference between omx and vaapi is the latter has cabac on (for me using TONGA). This is better, though you can hack it on for omx.

I use AUR package in arch for gst-omx and it fails to initialize. I can see that other people have the same problem. It is quite old package though (2015-11-08). I think that I'd have to try get fresh source and compile it by myself.

gst-inspect-1.0 /usr/lib/gstreamer-1.0/libgstomx.so
Could not load plugin file: File "/usr/lib/gstreamer-1.0/libgstomx.so" appears to be a GStreamer plugin, but it failed to initialize

gst-omx 1.2.0-1  (2015-11-08 03:09)