Open nealmcb opened 8 years ago
Unless I'm misunderstanding your question, this option already exists:
He refers to the fact that, if another window overlaps the selected window (partially or full), it will be recorded too and he would like to have only the selected window recorded, without the overlapping one(s). See the attached video (its mp4) - i have only the browser window selected for capture but other overlapping windows are still recorded.
@laszlokertesz - looks like pop ups from other programs (in this case, SSR) are recorded. I don't have a solution, but a workaround could be to use a tiling window manager or work with different workspaces (virtual desktops).
There is no general solution for this, because in the case of stacking window managers, the content of the window essentially doesn't exist unless the window is on top. The exception is OpenGL, in that case you can use ssr-glinject.
Edit: I meant stacking window manager, not tiling.
I'm not entirely sure how on the technical aspect but I do know that OBS has this option and it works even when the window is minimised I use this for recording the "Now Playing" section of VLC. Would something like that be possible?
On Thu, Apr 14, 2016 at 4:38 PM, MaartenBaert notifications@github.com wrote:
There is no general solution for this, because in the case of tiling window managers, the content of the window essentially doesn't exist unless the window is on top. The exception is OpenGL, in that case you can use ssr-glinject.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/416#issuecomment-210138657
Just checked the OBS source, as I suspected it only works with compositing window managers. From wikipedia:
A compositing window manager is a window manager that provides applications with an off-screen buffer for each window. The window manager composites the window buffers into an image representing the screen and writes the result into the display memory.
With such a window manager, it is possible to capture the offscreen buffer. OpenGL applications always have this buffer, which is how OpenGL recording in SSR works. Non-OpenGL applications don't have this buffer unless you use a compositing window manager. In that case it is possible to capture the window but it is harder. If you use a non-compositing window manager (i.e. stacking window manager), this buffer doesn't exist at all, the image is just written directly to the (global) frame buffer. This is what is normally captured by SSR.
I don't like adding features that only work for some configurations. It just produces endless questions from users asking why it doesn't work for them. So if I'm going to add something like this, I need a solution for all reasonable configurations. This is even more important for this specific case because I am actively recommending users to move away from compositing window managers, because they introduce overhead that reduces the performance and leads to higher (and less predictable) latency, especially with demanding games. I don't think it's reasonable to expect users to switch between compositing and non-compositing window managers all the time, because many desktop environments don't even provide such an option (Xfce and KDE have it though, but it breaks some effects).
I suppose I could write something like GLInject which hijacks the connection with the window system so that it can trick the application into rendering stuff that isn't even visible on-screen and then store it in RAM. This would probably work for modern GTK and Qt apps because they render everything internally to a single image and then send that image to the window system. But there's a problem: the X11 window system also has its own graphics system which many older applications still use. I haven't checked, but I doubt that I can trick the X11 window manager to render graphics for an area that's not visible on-screen. So I would be stuck with another implementation that only works in some cases. I don't like that.
Thats good to know, so this kind of thing is possible but in order to maintain cross the board compatibility you won't?
On Sun, Apr 17, 2016 at 6:31 PM, MaartenBaert notifications@github.com wrote:
Just checked the OBS source, as I suspected it only works with compositing window managers. From wikipedia:
A compositing window manager is a window manager that provides applications with an off-screen buffer for each window. The window manager composites the window buffers into an image representing the screen and writes the result into the display memory.
With such a window manager, it is possible to capture the offscreen buffer. OpenGL applications always have this buffer, which is how OpenGL recording in SSR works. Non-OpenGL applications don't have this buffer unless you use a compositing window manager. In that case it is possible to capture the window but it is harder. If you use a non-compositing window manager (i.e. stacking window manager), this buffer doesn't exist at all, the image is just written directly to the (global) frame buffer. This is what is normally captured by SSR.
I don't like adding features that only work for some configurations. It just produces endless questions from users asking why it doesn't work for them. So if I'm going to add something like this, I need a solution for all reasonable configurations. This is even more important for this specific case because I am actively recommending users to move away from compositing window managers, because they introduce overhead that reduces the performance and leads to higher (and less predictable) latency, especially with demanding games. I don't think it's reasonable to expect users to switch between compositing and non-compositing window managers all the time, because many desktop environments don't even provide such an option (Xfce and KDE have it though, but it breaks some effects).
I suppose I could write something like GLInject which hijacks the connection with the window system so that it can trick the application into rendering stuff that isn't even visible on-screen and then store it in RAM. This would probably work for modern GTK and Qt apps because they render everything internally to a single image and then send that image to the window system. But there's a problem: the X11 window system also has its own graphics system which many older applications still use. I haven't checked, but I doubt that I can trick the X11 window manager to render graphics for an area that's not visible on-screen. So I would be stuck with another implementation that only works in some cases. I don't like that.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/416#issuecomment-211124634
I'm not saying I will never do it, but I'm not terribly motivated to invest time in a hard to implement feature that will only work for half of the users. I still have a long todo list and this is not high on the list. But if someone else implements it I will gladly accept it (provided that it's stable of course).
By the way: I realize that you asked for the 'now playing' area of VLC, which I assume is not the video output. But if the thing you're trying to record is in fact the video output, then I have a much simpler and more reliable solution for you: go the the VLC settings, and switch the video output to 'OpenGL GLX video'. Now you can use OpenGL recording on VLC and capture just the video area, tear-free. This does work even when the window is minimized.
I'm not referring to the video output, I'm referring to recording a little snippet of the player that shows what is currently playing so that I can have the song name on screen while streaming. However thanks for the info. :D
On Sun, Apr 17, 2016 at 6:54 PM, MaartenBaert notifications@github.com wrote:
I'm not saying I will never do it, but I'm not terribly motivated to invest time in a hard to implement feature that will only work for half of the users. I still have a long todo list and this is not high on the list. But if someone else implements it I will gladly accept it (provided that it's stable of course).
By the way: I realize that you asked for the 'now playing' area of VLC, which I assume is not the video output. But if the thing you're trying to record is in fact the video output, then I have a much simpler and more reliable solution for you: go the the VLC settings, and switch the video output to 'OpenGL GLX video'. Now you can use OpenGL recording on VLC and capture just the video area, tear-free. This does work even when the window is minimized.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/416#issuecomment-211126040
Great info, thanks @MaartenBaert. Knowing a bit of the ageing architecture of X11, I was afraid it would be tricky and hard to generalize.
My original goal was to locally record a screencast via a google hangout.
I looked at ssr-glinject - first finding this page without a README https://github.com/MaartenBaert/ssr/tree/master/glinject , then the script itself with a visible Usage statement at https://github.com/MaartenBaert/ssr/blob/master/scripts/ssr-glinject
So are you saying I could run my browser under ssr-glinject and then somehow just record the window, without seeing popups?
GLInject only works if the application uses OpenGL, it's mostly meant for games. It's unlikely that it will work with Google Hangouts, but I suppose you could try.
Maarten, you are welcome to run my program to test SSR. My program is at http://www.github.com/aquila62/util The program is called clock.c. Just run inst.sh to set it up.
I don't really understand the problem. If you set SSR to 'record a fixed rectangle', it records a rectangle that you set in advance and won't move. If you select 'follow the cursor', then of course it will follow the cursor. That's the point.
If you just want to record the entire screen, then just use 'record the entire screen' ...
Your program doesn't do what you describe though. It doesn't actually fill the entire screen when I test it. Also, this program would be 10 times simpler if you just used an existing graphical framework like Qt or GTK, and then it would be trivial to go maximized or fullscreen etc.
Finally, it works like a dream. I saw a contradiction between rectangle and window. But when you combine rectangle with window, it selects the entire window, as it should, and it does not truncate any part of the window. The only caveat is that you have to plug in the exact dimensions of the window, otherwise truncation occurs.
Please delete all of my comments above and just retain this comment, because this comment summarizes what you told me, and gives the correct way to use your program.
I appreciate your help very much. Thanks, Maarten.
Hi, Can somebody tell me how to record one workspace, for example a whole browser window in full-display mode, and in that time to switch to another workspace and working there, but recording will be only first workspace? Now if i switch to another workspace, it will be recording. I have Ubuntu 14.04 with 4 workspace.
@makshima-shougo unfortunately due to the way that most WM's handle workspaces there is no way that you can record a single workspace unless things have changed in the past few years. See issue #302
On Thu, Feb 2, 2017 at 6:29 AM, makishima-shougo notifications@github.com wrote:
Hi, Can somebody tell me how to record one workspace, for example a whole browser window in full-display mode, and in that time to switch to another workspace and working there, but recording will be only first workspace? Now if i switch to another workspace, it will be recording. I have Ubuntu 14.04 with 4 workspace.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/416#issuecomment-276933342, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2RIwvPPGK9NsiVDvCJ7shLqo79xnGks5rYb4WgaJpZM4G8Vvg .
So I see, Thank you for the answer!
Hi I would like if you could consider anyway to add such function to SimpleScreenRecording in some form, because there are really too few programs under Linux that can capture directly a single window, instead of a single portion of desktop. Actually only OBSstudio and VokostationNG has such function, and both these are a lot less flexible than SSR in terms of options. I record often playthrough with emulators, and many of these don't use OpenGL as output. I found that SSR records much better than OBS, but if happens that the window moves for accident you have to trash the work done... I would like replace OBS for these tasks, but the lack of the single-window capture makes it a lot less ideal. I feel Linux really lacks of a program with this function that has the same functionality of SSR. You have better offers on Windows in this niche.
Maybe could be acceptable make a separated add-on for this function, separated from the main program: those users that have a composing manager could install it, but the main program remains universal. Maybe in a similar way how the libraries are handled on Ubuntu, where if you have need of support for 32bit, you install the extra package. Just an idea.
I'd often like to record just a single window, e.g. a web browser, even though it might occasionally be obscured by another window which I don't want recorded. E.g. Kazam can do this, allowing the user to point to the window they want to record. I guess I might miss some changes in the window which are masked by the overlaying window, but usually nothing is happening when I'm busy in another window.