Arch Linux

dodo3773

Member

Registered: 2011-03-17

Posts: 820

ffmpeg screencast problem

I am trying to do a screencast with ffmpeg but when I view it after everything looks like it's in slow motion. The original instructions I got were

ffmpeg -f alsa -i pulse -f x11grab -r 25 -s 1920x1080 -i :0.0 -acodec pcm_s16le -vcodec huffyuv -sameq test.avi

I even tried to remove the audio completely and used

ffmpeg -f x11grab -r 120 -s 1920x1080 -i :0.0 -vcodec huffyuv -sameq test.avi

I increased the framerate on the second but that did not help either. I even tried ffcast. Has anyone else had this problem? I cannot seem to figure out what I am doing wrong.

DrZaius

Member

Registered: 2008-01-02

Posts: 193

Re: ffmpeg screencast problem

Looks fine to me when using -r 25 using mplayer and ffplay. You never mentioned what player you're using or anything about your CPU which is the most likely bottleneck. Your FFmpeg output would be useful to see if you're dropping frames. Does it look normal if you use ffplay to view your output? Why are you using -sameq?

$ ffmpeg -h 2>&1 | grep sameq
-sameq              use same quantizer as source (implies VBR)

I doubt x11grab and huffyuv share the same quantizer scale, and if they did you wouldn't need it anyway as huffyuv is lossless.

For a good guide see:
How to do Proper Screencasts on Linux Using FFmpeg

Last edited by DrZaius (2011-05-10 21:34:23)

dodo3773

Member

Registered: 2011-03-17

Posts: 820

Re: ffmpeg screencast problem

Looks fine to me when using -r 25 using mplayer and ffplay. You never mentioned what player you're using or anything about your CPU which is the most likely bottleneck. Your FFmpeg would be useful to see if you're dropping frames. Does it look normal if you use ffplay to view your output? Why are you using -sameq?

$ ffmpeg -h 2>&1 | grep sameq
-sameq              use same quantizer as source (implies VBR)

I doubt x11grab and huffyuv share the same quantizer scale, and if they did you wouldn't need it anyway as huffyuv is lossless.

For a good guide see:
How to do Proper Screencasts on Linux Using FFmpeg

My processor is a dual core amd from like 3 years ago. I tried to watch it with totem and vlc. I have a nvidia 128mb on board laptop. My current setup is gnome3 fallback / openbox / xcompmgr. But, I had this problem even before I came to Arch. Maybe my computer is just not powerful enough not sure. gtk-recordmydesktop works though. Not sure if it is less heavy on resources than ffmpeg. As to your questions I am not sure why I am using -sameq I got that from the original tutorial I used. ffplay gives me the same results though. I will look more into that link.

ChemBro

Member

Registered: 2008-10-22

Posts: 704

Re: ffmpeg screencast problem

Maybe another videocodec. Dunno.

dodo3773

Member

Registered: 2011-03-17

Posts: 820

Re: ffmpeg screencast problem

Maybe another videocodec. Dunno.

Tried a couple. No luck. Oh well. recordmydesktop works it is what I've been using till now.

Wintervenom

Member

Registered: 2008-08-20

Posts: 1,011

Re: ffmpeg screencast problem

I have been using...

#!/bin/bash
ffmpeg -f x11grab -s $(xrandr | pcregrep -o '(?<=current )\d+ x \d+' | tr -d ' ') -r 15 -b 1000 -g 300 -i :0.0 -qmin 2 -qmax 5 -f alsa -ac 2 -i pulse -acodec libmp3lame -ab 128k ~/screencast.mp4

...to record my screen.  The MPEG encoders do a good job of not eating up too much CPU (my machines are all old single-cores, and it doesn't take much to drag them down to the depths of hell) and playing it back in MPlayer and on YouTube works fine.

Last edited by Wintervenom (2011-05-11 03:24:21)

dodo3773

Member

Registered: 2011-03-17

Posts: 820

Re: ffmpeg screencast problem

I have been using...

#!/bin/bash
ffmpeg -f x11grab -s $(xrandr | pcregrep -o '(?<=current )\d+ x \d+' | tr -d ' ') -r 15 -b 1000 -g 300 -i :0.0 -qmin 2 -qmax 5 -f alsa -ac 2 -i pulse -acodec libmp3lame -ab 128k ~/screencast.mp4

...to record my screen.  The MPEG encoders do a good job of not eating up too much CPU (my machines are all old single-cores, and it doesn't take much to drag them down to the depths of hell) and playing it back in MPlayer and on YouTube works fine.

Just tried it. Same thing again on this end. Maybe I have a buggy machine. That is the only thing I can think of. The videos look fine quality wise everything except the speed. It is like a delayed reaction. Tried it without composting too (xcompmgr) with the same result.