[FFmpeg-user] Desktop Capture 'Jerky'

[derekg]

On 06/03/17 15:17, Moritz Barsnick wrote:
> On Mon, Mar 06, 2017 at 14:29:14 +0000, derekg wrote:
>> I apologise if not using the correct protocol and hope that I'm also
>> following the 'Top Posting' format correctly .
> No, that's just fine now.
>
>> bash script and about thirty (30) seconds of execution of that script
>> together with the 'out.txt' console log . I hope that is what you've
>> requested .
> Yes.
>
>> #!/bin/sh
>> ffmpeg -f alsa -f pulse -ac 2 -i default -f x11grab -s 1920x1080 -r 60 -i :0.0 -qscale 0 -f mpeg -ar 48000 -s wvga -y /media/sda5/sample.mkv > out.txt 2>&1
>> exit
> First of all:
> * "-f alsa" isn't doing anything. You're overwriting it with "-f
>    pulse", so pulseaudio is being used.
> * You're using "-f mpeg" but an output file named "*.mkv". This is
>    certainly not what you expect! You do not get a Matroska file, and
>    you're using outdated default codecs, which may or may not be okay
>    for you.
>
> That said, these outdated codecs may (or may not) be faster than
> others.
>
> Usually, you would omit "-f mpeg", then ffmpeg would automatically
> choose the Matroska output format (because it recognizes you file
> suffix), and choose other codecs. Probably libx264 for video and aac
> for audio. These may be slower, but we can tune them to be faster.
>
> Next, did you read this?:
>
>> [pulse @ 0x357d2c0] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
> I have no idea if it's of any importance though.
>
>> [x11grab @ 0x35873e0] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
> Same here. These may be performance issues (I don't know these warnings
> good enough).
>
>> frame=  462 fps= 38 q=0.0 size=    4312kB time=00:00:07.65 bitrate=4611.9kbits/s speed=0.625x
> Indeed, 0.625x is too slow for your realtime encoding.
>
> Do you really need to capture your desktop at 60 fps? Try reducing that
> to 30, and see if that helps. Or even 15, if that's enough for you.
>
> Do you really need qscale 0? That quality setting puts extra load on
> the processor.
>
> Next step: If you want to go for real Matroska with H.264: Add
>    -c:v libx264 -preset veryfast
> ("-c:v libx264" is probably default anyway, I guess)
> and see how that performs (do you reach > 1.0x?).
>
> If it's still too slow, try
>    -c:v libx264 -preset ultrafast
>
> If that's not enough, you can reduce the video quality further by using
>    -c:v libx264 -preset ultrafast -crf 25
> (a CRF of 23 is default, higher numbers are less quality).
>
> You could also choose a somewhat faster codec, such as mpeg4:
>    -c:v mpeg4
> (I don't know how speed and quality exactly compare to libx264,
> though.)
>
> If, on the other hand, it's more than fast enough, use
>    -c:v libx264 -preset slow
> if you want better compression (smaller filesize), or even
>    -c:v libx264 -preset slow -crf 21
> if you want to use the extra CPU for better quality.
>
> (See: you can trade off encoding speed, quality, and size.)
>
> Hope this helps,
> cheers,
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

Dear Fellow Users (Carl Eugen/Moritz) ,

Thank you for your helpful suggestions which have allowed me to set up 
ffmpeg working versions of my screen capture requirement . However my 
main usage is simply to record a sport webstream which only provides 
download support for M$ and Apple operating sytems and I've installed 
SimpleScreenRecorder on my 'Live' Linux Mint 17 LTS and it works 
perfectly , with the bonus of synchronised audio and video , which I'm 
afraid would need more trial and error work by me on the ffmpeg routines 
before it was right !

Derek