tearing when record ffmpeg

[Ram3zani]

Hello
I use i3wm+compton. I use ffmpeg to make videocast.output video ffmpeg have tearing. if i kill compton and try again ffmpeg , output video is fine. is there any way i have both theme. compton were running and ffmpeg record fine . is it possible?
compton config

# Thank you code_nomad: http://9m.no/ꪯ鵞

#################################
#
# Backend
#
#################################

# Backend to use: "xrender" or "glx".
# GLX backend is typically much faster but depends on a sane driver.
backend = "glx";

#################################
#
# GLX backend
#
#################################

glx-no-stencil = true;

# GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
# My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
# but a 20% increase when only 1/4 is.
# My tests on nouveau show terrible slowdown.
# Useful with --glx-swap-method, as well.
glx-copy-from-front = false;

# GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
# My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
# May break VSync and is not available on some drivers.
# Overrides --glx-copy-from-front.
# glx-use-copysubbuffermesa = true;

# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
# Recommended if it works.
# glx-no-rebind-pixmap = true;


# GLX backend: GLX buffer swap method we assume.
# Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
# undefined is the slowest and the safest, and the default value.
# copy is fastest, but may fail on some drivers,
#2-6 are gradually slower but safer (6 is still faster than 0).
# Usually, double buffer means 2, triple buffer means 3.
# buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
# Useless with --glx-use-copysubbuffermesa.
# Partially breaks --resize-damage.
# Defaults to undefined.
glx-swap-method = "undefined";

#################################
#
# Shadows
#
#################################

# Enabled client-side shadows on windows.
shadow = true;
# Don't draw shadows on DND windows.
no-dnd-shadow = true;
# Avoid drawing shadows on dock/panel windows.
no-dock-shadow = true;
# Zero the part of the shadow's mask behind the window. Fix some weirdness with ARGB windows.
clear-shadow = true;
# The blur radius for shadows. (default 12)
shadow-radius = 5;
# The left offset for shadows. (default -15)
shadow-offset-x = -5;
# The top offset for shadows. (default -15)
shadow-offset-y = -5;
# The translucency for shadows. (default .75)
shadow-opacity = 0.5;

# Set if you want different colour shadows
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;

# The shadow exclude options are helpful if you have shadows enabled. Due to the way compton draws its shadows, certain applications will have visual glitches
# (most applications are fine, only apps that do weird things with xshapes or argb are affected).
# This list includes all the affected apps I found in my testing. The "! name~=''" part excludes shadows on any "Unknown" windows, this prevents a visual glitch with the XFWM alt tab switcher.
shadow-exclude = [
    "! name~=''",
        "name = 'Notification'",
            "name = 'Plank'",
                "name = 'Docky'",
                    "name = 'Kupfer'",
                        "name = 'xfce4-notifyd'",
                            "name *= 'VLC'",
                                "name *= 'compton'",
                                    "name *= 'Chromium'",
                                        "name *= 'Chrome'",
                                            "class_g = 'Conky'",
                                                "class_g = 'Kupfer'",
                                                    "class_g = 'Synapse'",
                                                        "class_g ?= 'Notify-osd'",
                                                            "class_g ?= 'Cairo-dock'",
                                                                "class_g ?= 'Xfce4-notifyd'",
                                                                    "class_g ?= 'Xfce4-power-manager'",
                                                                        "_GTK_FRAME_EXTENTS@:c"
                                                                        ];
# Avoid drawing shadow on all shaped windows (see also: --detect-rounded-corners)
                                                                        shadow-ignore-shaped = false;

#################################
#
# Opacity
#
#################################

menu-opacity = 1;
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;
alpha-step = 0.06;

# Dim inactive windows. (0.0 - 1.0)
# inactive-dim = 0.2;
# Do not let dimness adjust based on window opacity.
# inactive-dim-fixed = true;
# Blur background of transparent windows. Bad performance with X Render backend. GLX backend is preferred.
# blur-background = true;
# Blur background of opaque windows with transparent frames as well.
# blur-background-frame = true;
# Do not let blur radius adjust based on window opacity.
blur-background-fixed = false;
blur-background-exclude = [
    "window_type = 'dock'",
        "window_type = 'desktop'"
        ];

#################################
#
# Fading
#
#################################

# Fade windows during opacity changes.
fading = true;
# The time between steps in a fade in milliseconds. (default 10).
fade-delta = 8;
# Opacity change between steps while fading in. (default 0.028).
fade-in-step = 0.03;
# Opacity change between steps while fading out. (default 0.03).
fade-out-step = 0.03;
# Fade windows in/out when opening/closing
# no-fading-openclose = true;

# Specify a list of conditions of windows that should not be faded.
fade-exclude = [ ];

#################################
#
# Other
#
#################################

# Try to detect WM windows and mark them as active.
mark-wmwin-focused = true;
# Mark all non-WM but override-redirect windows active (e.g. menus).
mark-ovredir-focused = true;
# Use EWMH _NET_WM_ACTIVE_WINDOW to determine which window is focused instead of using FocusIn/Out events.
# Usually more reliable but depends on a EWMH-compliant WM.
use-ewmh-active-win = true;
# Detect rounded corners and treat them as rectangular when --shadow-ignore-shaped is on.
detect-rounded-corners = true;

# Detect _NET_WM_OPACITY on client windows, useful for window managers not passing _NET_WM_OPACITY of client windows to frame windows.
# This prevents opacity being ignored for some apps.
# For example without this enabled my xfce4-notifyd is 100% opacity no matter what.
detect-client-opacity = true;

# Specify refresh rate of the screen.
# If not specified or 0, compton will try detecting this with X RandR extension.
refresh-rate = 0;

# Set VSync method. VSync methods currently available:
# none: No VSync
# drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some drivers.
# opengl: Try to VSync with SGI_video_sync OpenGL extension. Only work on some drivers.
# opengl-oml: Try to VSync with OML_sync_control OpenGL extension. Only work on some drivers.
# opengl-swc: Try to VSync with SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the effect of --sw-opti unlike other methods. Experimental.
# opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
# (Note some VSync methods may not be enabled at compile time.)
vsync = "opengl-swc";

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;
# Painting on X Composite overlay window. Recommended.
paint-on-overlay = true;

# Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
# This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
sw-opti = true;

# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
# paint-on-overlay may make the flickering less obvious.
unredir-if-possible = true;

# Specify a list of conditions of windows that should always be considered focused.
focus-exclude = [ ];

# Use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time.
detect-transient = true;
# Use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time.
# WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
detect-client-leader = true;

#################################
#
# Window type settings
#
#################################

wintypes:
{
   tooltip =
      {
        # fade: Fade the particular type of windows.
          fade = true;
        # shadow: Give those windows shadow
          shadow = false;
        # opacity: Default opacity for the type of windows.
          opacity = 0.85;
        # focus: Whether to always consider windows of this type focused.
          focus = true;
                       };
};

[kevinchappell]

@behroozramezani Same issue here. Did you ever find a work around?

[kn00tcn]

are you guys saying the recorded video permanently has tearing in the exact same spots when paused, not that the video player is tearing?

heh, why are those excludes indenting more each line

[kevinchappell]

@kn00tcn The video itself has tearing.

[kn00tcn]

other vsynced compositors dont? i will try this eventually, but giving me the right ffmpeg command will help me try it quicker

edit: another interesting test would be a game with vsync that ffmpeg records... i think OBS uses ffmpeg so that would make it easier (for a fullscreen game to use hotkey record)

[kevinchappell]

I have only tried xrender and glx backends. Here is my ffmpeg command:

ffmpeg -f x11grab -framerate 60 -s 3440x1440 -i :0.0 -preset ultrafast tearing-example.mkv

That command produced this example video

videos created with Simple Screen Recorder look pretty much the same

[Ram3zani]

I find solution for this issue. my issue was tearing in recored video from desktop with intel VGA, at first i think this issue was for compton but i was wrong. I've two issue. first issue was high usage Xorg cpu. for fix this issue i changed acceleration method from UXA to SNA. this issue fixed. but i have new issue. second issue was tearing on video when recorded with ffmpeg or any application for record video cast. at first i think this issue for compton config but i was wrong. after search in google and arch forum. i find solution for it. i installed xf86-video-intel on arch linux for driver intel HD 4000. for fix this issue i removed xf86-video-intel and modesetting driver instead of Intel's . so my issue fixed

cheers

[kmatheussen]

I'm using obs to record video instead. It has an option to record directly from the compositor, so you won't get tearing whether you run compton or not at the same trime. Obs is also much faster than ffmpeg, so I can record 1900x1000 60hz with quite good picture quality. https://obsproject.com/

[kevinchappell]

@behroozramezani thanks for the update.

I am already using SNA on ubuntu but I see others are also having issues with Intel HD 620 (my graphics) so will look deeper into that. A patch was added to kernel 4.9 which sounds like it may fix the problem so I can either wait for 4.10 or compile from the drm-tip branch referenced here. Either way its looking less and less like a compton issue.

[kevinchappell]

@kmatheussen I was under the impression Obs used ffmpeg but have wanted to try it anyways so thanks for the tip, will give it a go now.

edit: just read your edit about recording from compositor- that's perfect thanks.

[kmatheussen]

Yeah, it does link to ffmpeg, but I don't think it uses ffmpeg to record with. I would also guess that it has additional encoders, since I haven't been able to make ffmpeg record with the same quality.

[kmatheussen]

It has an option to record directly from the compositor

This sentence was unclear, because I don't know what happens, but I would guess that obs creates it's own xcompositor to record from.

[Brottweiler]

@kmatheussen

It has an option to record directly from the compositor

Where is this option?

Edit: Do you mean when adding a new Source, you can add a Window Capture (Xcomposite)? That's what I am doing, and that's what causing things to tear. When playing games fullscreen with vsync, they tear when I start OBS and I have the window selected as "window capture".

[Hritik14]

Did anyone ever found a solution that works with ffmpeg ?

[kmatheussen]

@Brottweiler

Edit: Do you mean when adding a new Source, you can add a Window Capture (Xcomposite)? That's what I am doing, and that's what causing things to tear. When playing games fullscreen with vsync, they tear when I start OBS and I have the window selected as "window capture".

(New emails aren't sent out when editing a previous message. I just saw this coincidentally)

I don't have OBS right now, so I don't remember exactly the option. Anyway, if you mean that you still get tearing when playing, that might happen, but there shouldn't be tearing on the recorded video file.

[Brottweiler]

@kmatheussen It's unrelated to compton actually, but when using Window Capture in OBS, that introduces horrible tearing. I can use compton with glx backend and vsync, then have unredir-if-possible disabled (so compton runs "ontop" of fullscreen windows) and that "fixes" the tearing, but that can have performance issues (framerate drops in Rocket League for me).

I cannot seem to find such an option you describe in OBS settings, though.

[kmatheussen]

Yes, you should ask this on an OBS forum. I still don't know whether you talk about tearing on the screen, or tearing on the video file though. All I know is that you don't get tearing on the recorded video file by using the xcomposite mode in OBS.

[Brottweiler]

@kmatheussen Yeah, it's OBS related. I was just interested in the "record directly from the compositor". and yes, it's tearing on the screen, the video is fine. The tearing on the screen just makes the experience of playing the game worse.

[kmatheussen]

@Brottweiler Oh, in that case, your problem is a compton issue. The compositor in OBS doesn't change what you see on the screen. It's only used to record video from (at least I would think so).

[Brottweiler]

@kmatheussen It happens even if comton isn't running. Not sure why OBS causes it to happen.

[kmatheussen]

(What does "it" refer to? Tearing?) You mean that the tearing starts to happen when OBS is running, and that there is no tearing when only compton is running?

[Brottweiler]

@kmatheussen "It" is tearing, yeah. If I run compton with glx backend and opengl-swc vsync, there's no tearing anywhere. If I run a game in fullscreen, compton "unredirects" or whatever so that it's not really running ontop of the game. So when a game is fullscreen, compton isn't running, and tearing isn't an issue because of vsync in the game and possibly NVIDIA sync to vblank.

If I fullscreen a game, regardless if I run compton or not, and start OBS and select the game in Window Capture, that introduces tearing. A horrible line at the top of the screen.

If I run the game windowed, or disable unredir-if-possible, that means compton runs ontop of the game and that fixes the tearing OBS introduces, but in Rocket League specifically I've noticed performance issues, the frames drop sometimes if compton runs ontop of the game.

So it's not a compton issue since OBS introduces tearing even if compton isn't even running.

[psy-q]

I (and others) also have tearing on-screen when using Nvidia cards with OBS' Xcomposite mode. The videos have no tearing but show other crazy artifacts, like flickering triangles on top of the game scene. I believe this might be an Nvidia driver issue and unrelated to Compton, but I don't have a non-Nvidia setup to try with.

[kn00tcn]

@psy-q which game? all games? which gpu? also if compton is disabled? proprietary driver? i thought nvidia can enable its own vsync so compton wouldnt be needed and/or fullscreen games should be set to bypass the compositor so they or the driver handles vsync

compton looks quite dead anyway...

[Brottweiler]

@kn00tcn As long as you have unredir-if-possible = true; (or kill compton), nvidia's "sync to vblank" will fix tearing in OpenGL games. But @psy-q is talking about that the Xcomposite source in OBS introduces very bad tearing that only shows on the screen, but not in the video file. This affects all games.

I don't know if this also affects @psy-q, but when I use compton with the xrender backend, I get a similar tearing issue. I have screen tearing when I don't use compton, but it's not very noticable. Using compton with xrender gives me this one very obvious tear that is extremely distracting. glx fixes this, but makes everything laggier, like moving windows around.

It's most likely a nvidia driver issue...

[psy-q]

All games I've tested so far, yes. Nvidia proprietary driver 390.25 with a GTX 1060. I don't really have a way to test the built-in Intel iGPU because switching out Nvidia libGL for Mesa is always such a hassle.

I believe Nvidia's own vsync is behaving properly, there is no tearing in the games themselves and no tearing in the video file when playing normally. Heavy tearing as soon as Xcomposite is enabled and targetting the game window. OBS doesn't even have to be recording for this to happen, it's enough to just select the window.

It happens on Plasma with Kwin compositing on or off, and with compton running or not running, nothing makes a difference. That's why I'm almost entirely convinced it has nothing to do with compton and is related to how Xcomposite behaves in Nvidia's proprietary driver.

/u/ragger on Reddit had exactly the same issue and he didn't even run compton, it just gets worse running compton in xrender mode.

[kn00tcn]

is xcomposite the only usable source? on reddit you're implying you cant run 60fps fullscreen, does that mean you run games in a smaller window or that fullscreen recording has a performance drop? if you run in a window, can you run the fullscreen at lower resolution & record+see fine that way?

note: i almost never use OBS, if i do it's in windows, but if i'm in windows i prefer fraps, so i dont have much experience with every recording mode of OBS

[psy-q]

I hit 60 fps in the games I have, but what I meant on Reddit is that XSHM recording mode can't keep up with that. It also seems to produce irregular frame pacing in recordings and feels more like 30 fps, but that may be a separate issue.

Using Xcomposite I can record and stream at 60 fps, but with the tearing on-screen and the strange graphics artifacts/flicker in the recordings as described above.

Maybe I should post in the Nvidia devtalk forum to see if others have this problem (well, we know for a fact that at least 3 people do, so there could be more). AMD and Intel users appear not to have this issue.

[kn00tcn]

are these the only two recording modes on linux?

bad pacing reminds me of windows OBS, where you need to disable aero (desktop compositing) to record without the choppy fps, even though some other tools can record the entire desktop (maybe not windowed) at 60fps

if you intentionally disabled vsync everywhere, maybe capped the game to 57 or 63 fps, what would happen?

i've been wanting to switch to hardware/secondcomputer recording for years, that way i can never worry about performance changes, incompatibilities, & could finally record my ps3 or even simple things like an OS installation process without doing it in a VM

otherwise i've been fraps on windows for over a decade & very highly satisfied, have to transcode afterward but that's ok, a live encoder cannot be as good quality so i wouldnt be encoding live in the first place

edit: so i guess i dont have much to add other than random things to test based on my experience/interest in testing every variable (in the past i have discovered workarounds for amd driver issues breaking games)

[psy-q]

Yes, those are the only ones. I remember OBS' author saying that neither of them is good, and I think he commented specifically that bugs in some drivers' Xcomposite handling will make it impossible to get decent recording in many cases.

I've tried enabling and disabling vsync now but it appears to make no difference for the tearing. I think this tearing is not related to the kind of tearing that usually appears; the desktop, games and videos are tear-free unless OBS is targetting window via Xcomposite.

I'd love to use the NVENC that's in my graphics card because I bloody well paid for the feature and it doesn't seem to work correctly :) I don't mind the bad encoding quality. If I can, I will test on Intel to see if we can really narrow it down to the Nvidia driver. Edit: Tested on Intel, no such issue there. Don't have an AMD machine to test with though, would be good to compare all three.

I posted a thread at Nvidia devtalk. Note that their forum system appears to be broken and you can only log in when allowing third-party cookies.

If I were serious about this hobby I'd get an UVC-based USB3 HDMI grabber because they can do 1080p60 now, a splitter, a good mic and an audio mixer. On a dedicated machine, x264 software encoding would probably be possible at any quality level imaginable, and that'd solve all the problems, plus it works on Linux as opposed to some other capture solutions.

[kn00tcn]

NVENC is not (or not working for you) on linux in any form or just in OBS? i thought NVENC is being replaced by a newer API, not sure where i heard that, if windows or OBS or phoronix or nouveau

edit: ffmpeg is compiled with NVENC? can you use it manually outside of OBS to transcode an existing video?

edit2: i dont think it can solve anything though, isnt the window/screen capture the stage BEFORE the encoder, so i assume it doesnt matter if it's nvenc/x264/something/uncompressed

what if you dual boot windows just for games? if this is your only computer

mic/mixer imply you want to talk over it, i'm only interested in quality recording & minimalism, so even a splitter might not be needed (there are certain capture devices that can display their image live in windows with single digit milisecond response time)

i'd also live with the tearing if it's ONLY during recording while the videos are ok & if it's not obstructing your view much, the whole point of recording is for the resulting output for others to see, as long as i can still play without stutters or lag

[psy-q]

The encoder doesn't matter indeed, because the problem appears also when nothing is recording or streaming. NVENC works fine in other situations (e.g. Steam in-home streaming). I won't be dual-booting Windows, I only had a brief stint with it for some games but want to get rid of it.

The tearing is unacceptable for me though, sometimes it will even produce what looks like two tearing seams at the same time with very different frames on either side of the seam, so it makes 2D games unplayable (you can't visually track a projectile anymore since the seam goes through its trajectory for example).

I'm not overly bummed by this since I don't need to stream, but I thought I'd just add my tests to this issue as well. Let's wait to see if Nvidia answers. And if I can find an AMD card I'll test with that, but judging from the results with Mesa on Intel I would guess that AMD would work fine.

[psy-q]

It seems to be fixed in the current OBS master, I was able to record and stream at 60 fps using Xcomposite today with no issues. Edit: This was a coincidence and only seems to work with specific games. See below. Apologies for the misleading results.

[Brottweiler]

@psy-q have you located which commit might fix this? Sounds surprising, but I will test and find out as well when there's a new release.

[psy-q]

Unfortunately not, I threw away my previous compile because of the issues and tried a completely fresh master today on a whim. Didn't expect it to work. I will go through OBS' changelog to see if there's a likely commit.

The Nvidia driver at least is the same (390.25), kernel is the same version but probably contains some of Debian's backported security fixes now (4.9.0-6-amd64 instead of 4.9.0-4-amd64). It would be weird if that had anything to do with it.

Edit: Looked through the changelog and commit log and didn't see anything referencing Xcomposite or other changes to how Linux capture is handled. Will now retry with the most problematic games from February, maybe it only affects certain titles and I was lucky this time.

Edit 2: Sorry, Ignore all I've said. The problem is still there in those games that were problematic before (e.g. JYDGE). It just doesn't appear in some others (like Beat Hazard). Maybe there is a difference in how the graphics are initialized, e.g. double buffering, triple buffering, number of prerendered frames requested, glSwap stuff, and some games happen to work fine while others are a mess?

[kn00tcn]

sometimes you can control some of those buffering/sync modes in certain games/engines

this raises interesting test ideas: vsync on vs off, double vs triple, windowed vs fullscreen, ogl versions, whether performance is still way above your refresh (lightweight vs demanding game)

would be nice if github sent an email during edits, hah

[WyldeLaRue]

This thread has sort of devolved into OBS discussion. Did anyone ever find a fix to get a smooth recording using ffmpeg?

[arcogabbo]

Anyone found a solution yet? Tried almost everything to get a smooth recording with ffmpeg and nothing worked, currently using the latest Nvidia drivers and no Compton.