Arch Linux

lolilolicon

Member

Registered: 2009-03-05

Posts: 1,722

Decent options for ffmpeg x11grab?

I don't really do screencasts myself, but my script FFcast needs a decent set of default options... so I'd like to ask, what is a good combination of options for x11grab?

The current default is something like this:

ffmpeg -v 1 -r 25 -f x11grab -s 640x480 -i :0.0+0,0 -vcodec libx264 cast.mkv

as you can see it's really simple- I don't want to rush and swallow options I don't know if I should add...

Thanks in advance.

---

This silver ladybug at line 28...

lolilolicon

Member

Registered: 2009-03-05

Posts: 1,722

Re: Decent options for ffmpeg x11grab?

I got a problem- the colors in terminal are off in the screencast:

The actual thing looks like this (scrot):  http://ompldr.org/vYW13bQ
The screencast looks like this (played with mplayer -vf screenshot): http://ompldr.org/vYW13cA

The command line I used is:

ffmpeg -v 1 -r 25 -f x11grab -s 640x480 -i :0.0+0,0 -vcodec libx264 -vpre lossless_slow -threads 0 cast.mkv

Any reason why? And a solution?

---

This silver ladybug at line 28...

DrZaius

Member

Registered: 2008-01-02

Posts: 193

Re: Decent options for ffmpeg x11grab?

The command line I used is:

ffmpeg -v 1 -r 25 -f x11grab -s 640x480 -i :0.0+0,0 -vcodec libx264 -vpre lossless_slow -threads 0 cast.mkv

This is a good start in my opinion, but I would change it to:

ffmpeg -v 1 -r 30 -f x11grab -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast -crf 0 -threads 0 cast.mkv

This change will allow FFcast to also work on FFmpeg from current Git head as well as the 0.7 release series in the repo and I expect this new syntax would also encode at a slightly faster rate. The text based lossless presets were dropped upstream because the presets are now directly accessed via libx264 instead of being roughly mimicked like they used to be.  Also, with screencasting, encoding speed should be more important than output file size (you want a smooth mouse movement), so use the fastest preset available which is "ultrafast".

Perhaps FFcast could offer a second encoding command to re-encode cast.mkv if desired due to the potentially huge file sizes of lossless outputs. Or maybe give an additional option for a lossy default command instead:

ffmpeg -v 1 -r 30 -f x11grab -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast -crf 18 -threads 0 cast.mkv

My i7 does fine with either at 1680x1050, but I don't know how much of a performance hit the additional compression would introduce and I was just capturing a terminal and browser and not a game or anything fancy.

I removed +0,0 which is probably superfluous with 0 values, but it doesn't really matter if it is there or not.

Frame rate was changed from 25 to 30. Faster looks better and if the encoder can't keep up it will just go as fast as it can I think (I guess the output should still be 30 frame rate, but the captured input might be lower).

Any reason why? And a solution?

Your input from x11grab is RGB and your output is YV12, so I think there is some color loss during that conversion. Your png output is RGB, so it avoids going to YUV and does not lose additional information. I believe x264 supports rgb output (or maybe YV24 would help?), but it's something I'm not familiar with at all.

lolilolicon

Member

Registered: 2009-03-05

Posts: 1,722

Re: Decent options for ffmpeg x11grab?

Thank you for the insights, much appreciated.

ffmpeg -v 1 -r 30 -f x11grab -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast -crf 0 -threads 0 cast.mkv

This change will allow FFcast to also work on FFmpeg from current Git head as well as the 0.7 release series in the repo and I expect this new syntax would also encode at a slightly faster rate. The text based lossless presets were dropped upstream because the presets are now directly accessed via libx264 instead of being roughly mimicked like they used to be.

Good stuff, much saner than the old syntax.

Also, with screencasting, encoding speed should be more important than output file size (you want a smooth mouse movement), so use the fastest preset available which is "ultrafast".

Yeah, I guess that's obvious

Perhaps FFcast could offer a second encoding command to re-encode cast.mkv if desired due to the potentially huge file sizes of lossless outputs. Or maybe give an additional option for a lossy default command instead:

ffmpeg -v 1 -r 30 -f x11grab -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast -crf 18 -threads 0 cast.mkv

Nope, one set of default options is troublesome enough for FFcast The point is that FFcast should know little about irrelevant FFmpeg options.
There is a default set of options simply because I'm a kind man Seriously though, I think every user should put together a wrapper script around FFcast and feed to it whatever options they like.

My i7 does fine with either at 1680x1050, but I don't know how much of a performance hit the additional compression would introduce and I was just capturing a terminal and browser and not a game or anything fancy.

Let's just say... anything fancy enough deserves the user's effort to choose something suitable for it.

Frame rate was changed from 25 to 30. Faster looks better and if the encoder can't keep up it will just go as fast as it can I think (I guess the output should still be 30 frame rate, but the captured input might be lower).

Noted.

Any reason why? And a solution?

Your input from x11grab is RGB and your output is YV12, so I think there is some color loss during that conversion. Your png output is RGB, so it avoids going to YUV and does not lose additional information. I believe x264 supports rgb output (or maybe YV24 would help?), but it's something I'm not familiar with at all.

It seems there's no easy way around this... I don't know much about this stuff tbh.

---

This silver ladybug at line 28...

kristianlm

Member

Registered: 2013-04-24

Posts: 5

Re: Decent options for ffmpeg x11grab?

I know I'm a bit late for the party here, but I wanted to comment in case someone ends up here.

I'd had great success previously with -c:v h264 -crf 0 -preset ultrafast before. The idea is to compress just a little bit so the video file doesn't get out of hand, but still fast enough to keep up. Since it's lossless we can re-encode later on without quality loss twice. However, when I increased the resolution to 1920x1080 I started getting dropped frames. I think this may be caused by the conversion in pixel formats. Just setting -pix_fmt, unfortunately didn't work.

But then I came across the RGB-based encoder for h264: libx264rgb. This avoids the need to convert from the bgr0 pixel-format, coming from x11grab, to yuv422 or something similar, the default lib264 encoder needs. Adding multithreading with -threads 0, I'm able to record FullHD 60fps without any dropped frames. The final video-size is very large but manageable.

> ffmpeg -s 1920x1080 -f x11grab -r:v 60 -i "$DISPLAY"+0,0 -c:v libx264rgb -threads 0 -crf 0 -preset ultrafast /tmp/out.mkv

I also found that lossless h264 works very well for keeping the original footage. Recompressing to h264 lossless -preset medium often yields 10% of the original -preset ultrafast, since screen content is often easily compressible.