1

I'm running Linux and have AMD CPU with integrated graphics.

I want to capture my screen and encode it in mp4 format. Here's what I tried:

1. Capture screen and encode it directly to mp4;

ffmpeg -y -f x11grab -i :0.0 -codec:v libx264 test.mp4 

2. Capture screen and save it as raw data file, then encode it to mp4;

ffmpeg -y -f x11grab -i :0.0 -vcodec copy output.nut  
ffmpeg -i output.nut -c:v libx264 -crf 24 -vsync 2 test.mp4

3. Capture screen in lossless and then encode it to mp4;

ffmpeg -y -f x11grab -i :0.0 -framerate 60 -codec:v huffyuv lossless.mkv  
    ffmpeg -i lossless.mkv -c:v libx264 out.mp4

4. Encode raw data or lossless video to vp9 first (which is displayed correctly) and then convert to mp4;

5. Use VAAPI hardware acceleration (same as above but with hardware flags and h264_vaapi or hevc_vaapi as codecs, or kmsgrab instead of x11grab)

6. Download OBS studio and record screen with default options (since OBS uses ffmpeg as backend);

7. Set scale, screen_size or aspect ratio options for stream.

In all cases mp4 videos produced by ffmpeg seem to be broken in some ways. If a video player (VLC, MPV) supports hardware acceleration, my screen on video will look like this:

enter image description here

As you can see, the screen is rather blurry, has wide black border on the right and excessive pixels at the bottom repeating my taskbar, which should not be there. With hevc video looks simply misaligned (has wider black border on the right but no excessive pixels at the bottom)

However, if I disable hardware acceleration in MPV or VLC themselves the problem disappears and video displays correctly, but instead you could see video "jumping" in the player itself on each play, as if player was trying to align video in the window. Same behavior could be seen in chrome player, in Telegram player, in firefox player.

Neither of this happens if I encode my input to .mkv or .webm, happens only with hevc or h264. Also I had no problems with using ffmpeg on Windows.

My questions are: is this expected behavior? Should I submit this to ffmpeg bug tracker? Is there any workaround to this?

1 Answer 1

2

Your input pixels are coded as RGB but video is typically YUV. ffmpeg will convert the input to the best YUV format available among those supported by the encoder. In this case, that's yuv444p. However, this pixel format does not have wide support. Also, the encoder sets profile High Predictive 4:4:4 due to this pixel format which is playable by a few players only.

So, use

ffmpeg -y -f x11grab -i :0.0 -codec:v libx264 -pix_fmt yuv420p test.mp4
2
  • That is interesting. Since you've mentioned profile I've also added -profile:v baseline to this command and it replaced black border on the right side with extra pixels like it was on the bottom in original post screenshot, if I play it in MPV with hardware accel. It totally fixed videos in chrome, firefox and telegram though.
    – faex
    Aug 6, 2020 at 14:05
  • Technically, the encoder requires dimensions to be a multiple of 16. When the input doesn't meet that, it adds extra pixels and then writes metadata so the player can crop those padded pixels out. Sounds like mpv doesn't do that with h/w accel on linux. Strictly speaking, this is a limitation / bug of the h/w decoder being used.
    – Gyan
    Aug 6, 2020 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .