search

MaartenBaert / ssr

SimpleScreenRecorder, a screen recorder for Linux
http://www.maartenbaert.be/simplescreenrecorder/
GNU General Public License v3.0
2.53k stars 286 forks source link

Feature request: Multiple X11inputs. #23

Open nikod opened 11 years ago

nikod commented 11 years ago

I know livestreaming is not the main focus of this but I would like to ask for some basic features that would be useful mostly for livestreaming.

Being able to record multiple things at the same time and overlay them all in one video would be useful. This should work like this:

BlankInput: this would be the base of the video, would have the final resolution, as an option would be nice to be able to use an image for this (as a background, or it could be the first and/or bigger input).

InputVideo#: This would be the input video and it would overlay on top of the prev overlay, if this is the first Input it would be on top of BlankInput, if this is the second Video it would be on top of BlankInput+InputVideo1... This input would have a position X and Y on top of the prev overlay and Width and Height (It should be scaled most of the time).

FinalOverlay: This is what is going to be send to the encoder.

As an example, I get this using ffmpeg and some python code to make my life easier, this should be the final product: http://www.twitch.tv/uyniko/c/2775743

You should be able to use Libavfilter to do this and you should only need to provide multiple Inputs, but I'm not really sure of this. As an extra would be nice if you would be able to handle Images and Text as an input.

MaartenBaert commented 11 years ago

Maybe this will happen in the future, but it is a LOT of work. You're asking for a complete compositing system. It is something I have considered, and parts of the backend have been written with multiple inputs in mind, but I need more than just code that draws one frame on top of another frame (that's probably the easiest part of it all). I would have to deal with inputs that don't have the same frame rate (by duplicating frames), I would have to change the audio/video sync system (which means I would probably have to add variable-rate audio resampling), I would have to add more input types, and I would have to create a graphical interface for all of that. libavfilter isn't much help since it lacks the synchronization that I need.

If I ever get these features, I don't think it will fit in with the existing GUI. It would make it far too complex for the average user. I would have to create a separate program with the same backend but a different GUI that's more suitable for this kind of usage.

Everything combined, it would probably take at least a few months, assuming I could work on it all the time (which is very unlikely). And there's still a long list of other features (that are much easier to implement, luckily). So don't hold your breath ;).

Lucki commented 10 years ago

I think this should be a seperate program, which only focus at the composing part (I have XSplit in mind). This composing program can use multiple inputs (Images, Videos and arrange them).

So my idea is to start SSR two times, both generates a live output (Like DxTory DirectShow) for the composing.

MaartenBaert commented 10 years ago

@Lucki That's not practical, cross-process communication introduces massive overhead (zero-copy is hard or impossible, and memory usage is always higher than necessary). X11Input is perfectly stable, I have no reason to move it to a separate process. I might do it for less stable input types though (for example, pre-recorded video files that need to be decoded with ffmpeg).

If/when I do add support for multiple video inputs, I will probably write a completely new 'advanced' GUI so I don't have to clutter the existing GUI with options that most users won't need. The new GUI would probably have separate tabs for each input. So that's no reason to run the program twice.