You are not logged in.

#1 2011-10-03 12:31:20

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,676

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...

Offline

#2 2011-10-03 13:15:59

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,676

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...

Offline

#3 2011-10-03 22:02:24

DrZaius
Member
Registered: 2008-01-02
Posts: 166

Re: Decent options for ffmpeg x11grab?

lolilolicon wrote:

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).

lolilolicon wrote:

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.


Damned dirty ape.

Offline

#4 2011-10-04 17:11:20

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,676

Re: Decent options for ffmpeg x11grab?

Thank you for the insights, much appreciated.

DrZaius wrote:
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.

DrZaius wrote:

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 big_smile

DrZaius wrote:

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 wink 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 big_smile Seriously though, I think every user should put together a wrapper script around FFcast and feed to it whatever options they like.

DrZaius wrote:

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.

DrZaius wrote:

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.

DrZaius wrote:
lolilolicon wrote:

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...

Offline

Board footer

Powered by FluxBB