Problems using ffmpeg (Solved)
Problems using ffmpeg (Solved)
ffmpeg, in my opinion, is one of the greatest pieces of software ever written. It can do so many different things and is used in a large variety of other applications.
In earlier versions it was quite easy to convert video formats or capture desktop activity from the command line. In the later versions this seems no longer the case. Is it just me or is ffmpeg severely broken?
When recording the desktop I can get either excellent video or sound but not both together. When combined the video works fine but the sound is very stuttery so much it's inaudable.
I understand there have been a lot of improvements and added switches but I'm having trouble finding the commands to record my desktop with sound.
Any ideas?
In earlier versions it was quite easy to convert video formats or capture desktop activity from the command line. In the later versions this seems no longer the case. Is it just me or is ffmpeg severely broken?
When recording the desktop I can get either excellent video or sound but not both together. When combined the video works fine but the sound is very stuttery so much it's inaudable.
I understand there have been a lot of improvements and added switches but I'm having trouble finding the commands to record my desktop with sound.
Any ideas?
Last edited by smokey01 on Wed 13 Jul 2016, 03:09, edited 1 time in total.
Hello smokey01,
Actually, I'm nearing completion of a new screen capture app with gtkdialog frontend using libav-tools.sfs (made from FFmpeg2sfs) in DebianDog (XenialDog actually), where avconv is actually a simlink to the provided /usr/bin/ffmpeg in there. There certainly are some big improvements in the underlying ffmpeg code, but to avoid audio stutters when recording video with audio you need to use a couple of switches now (see below). The core of the app I'll be releasing is based on the following commandline (which works well for me when simply run from a terminal). Others could also make some nice gui frontends for this to maybe compete with Simple Screen Recorder quality but without needing to install Qt. The commandline is the most important thing but other tricky concern (for a gui utility) is to get coordinates for selected window or screen area, which is main thing I've been working on (successfully as it turns out - just polishing app up now prior to release):
Hope that helps. Easy to modify the above for higher/lower quality, but above is pretty good quality on my system anyway.
William
Note: you might have to play around with the thread_queue_size values a little, but should be fine.
Actually, I'm nearing completion of a new screen capture app with gtkdialog frontend using libav-tools.sfs (made from FFmpeg2sfs) in DebianDog (XenialDog actually), where avconv is actually a simlink to the provided /usr/bin/ffmpeg in there. There certainly are some big improvements in the underlying ffmpeg code, but to avoid audio stutters when recording video with audio you need to use a couple of switches now (see below). The core of the app I'll be releasing is based on the following commandline (which works well for me when simply run from a terminal). Others could also make some nice gui frontends for this to maybe compete with Simple Screen Recorder quality but without needing to install Qt. The commandline is the most important thing but other tricky concern (for a gui utility) is to get coordinates for selected window or screen area, which is main thing I've been working on (successfully as it turns out - just polishing app up now prior to release):
Code: Select all
ffmpeg -y -thread_queue_size 384 -f alsa -ac 1 -ar 44100 -i plughw:0,0 -thread_queue_size 64 -f x11grab -framerate 60 -s 1200x800 -i :0.0+0,0 -filter_complex asyncts -c:v libx264 -preset veryfast -crf 24 -pix_fmt yuv420p -c:a libmp3lame -ac 1 -ar 44100 -b:a 128k xcaptureout.mkv
William
Note: you might have to play around with the thread_queue_size values a little, but should be fine.
Last edited by mcewanw on Wed 13 Jul 2016, 01:45, edited 2 times in total.
github mcewanw
It's the real McCoy included in Fatdog64-710.
Code: Select all
ffmpeg -version
ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.8.3 (GCC)
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --enable-gpl --enable-version3 --enable-nonfree --disable-static --enable-shared --disable-debug --enable-libass --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-x11grab --enable-libfaac --enable-libfreetype --enable-libopenjpeg --enable-libspeex --enable-libxvid --enable-openssl --enable-libgsm --enable-avresample --enable-fontconfig --enable-libmodplug --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-librtmp --enable-libtwolame --enable-libv4l2 --enable-libschroedinger
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
#
You should probably drop the x11cap -framerate down from 60 to 30 (I was experimenting with screen capture of fast games...).
William
William
Last edited by mcewanw on Wed 13 Jul 2016, 01:56, edited 1 time in total.
William I didn't see your post before you posted a second time. Too busy testing. I've just tried your suggestion and it worked perfectly. I just needed to change the screen resolution to suit mine.mcewanw wrote:I thing the commandline I gave you should work in that original ffmpeg, or with very little modification.
William
Code: Select all
ffmpeg -y -thread_queue_size 384 -f alsa -ac 1 -ar 44100 -i plughw:0,0 -thread_queue_size 64 -f x11grab -framerate 30 -s 1366x768 -i :0.0+0,0 -filter_complex asyncts -c:v libx264 -preset veryfast -crf 24 -pix_fmt yuv420p -c:a libmp3lame -ac 1 -ar 44100 -b:a 128k xcaptureout.mkv
Thanks.
Last edited by smokey01 on Wed 13 Jul 2016, 03:12, edited 1 time in total.
I did drop the frame rate back to 30, in fact I probably only need about 10 as I will use it for tutorials. At 30, 60 or 10 fps I get:
Not sure if this is important. Next I need to test to see if the video and audio are in sync, and they are.
Code: Select all
[swscaler @ 0x9b8c00] Warning: data is not aligned! This can lead to a speedloss
Unfortunately, the optimal commandline values to use depend on machine specs. That ffmpeg commandline I gave was pretty much optimal on my Intel Core2 duo 2GHz laptop but some error warnings don't seem to be critical anyway.
Just curious what specifications are for the machine you are running this on?
William
Just curious what specifications are for the machine you are running this on?
William
github mcewanw
My Slacko 5.6 derivative didnt like the command:
Code: Select all
# ffmpeg -y -thread_queue_size 384 -f alsa -ac 1 -ar 44100 -i plughw:0,0 -thread_queue_size 64 -f x11grab -framerate 60 -s 1200x800 -i :0.0+0,0 -filter_complex asyncts -c:v libx264 -preset veryfast -crf 24 -pix_fmt yuv420p -c:a libmp3lame -ac 1 -ar 44100 -b:a 128k xcaptureout.mkv
ffmpeg version 2.0 Copyright (c) 2000-2013 the FFmpeg developers
built on Jul 16 2013 10:17:34 with gcc 4.7.1 (GCC)
configuration: --prefix=/usr --cpu=i686 --enable-libmp3lame --enable-libx264 --enable-libfaac --enable-pthreads --enable-small --enable-postproc --enable-libvorbis --enable-gpl --enable-shared --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-debug --enable-bzlib --enable-zlib --enable-libspeex --enable-version3 --enable-runtime-cpudetect --enable-x11grab --enable-libdc1394 --enable-libschroedinger --enable-libtheora --enable-libxvid --enable-swscale --enable-libvpx
libavutil 52. 38.100 / 52. 38.100
libavcodec 55. 18.102 / 55. 18.102
libavformat 55. 12.100 / 55. 12.100
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 79.101 / 3. 79.101
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 3.100 / 52. 3.100
Unrecognized option 'thread_queue_size'.
Error splitting the argument list: Option not found
#
@smokey01
As mcewanw wrote, it depends on your machine specs.
What you can also try is selecting codecs which are lighter on your cpu and system resources.
Codecs like H264 and especially H265 require much more power than say MP4 or avi.
The PCM (or wav) audio format is also lighter than say MP3 or AAC.
Since you intend to make tuts, you could select "lighter" codecs, at the expense of bigger file sizes, then use ffmpeg a second time to further compress the video and audio and use the resulting files as your tuts to post online.
@mcewanw
Those warnings normally mean that the sync is out or about to go out or the encoder cannot keep up in grabbing the X11 frames and encode/compress them fast enough.
This could cause problems for some users if they intend to then take the captures and stick then into a NLE.
Certain codecs are very specific about the data and any deviation could cause problems especially in a NLE that tries to be frame accurate.
Generally media players are more forgiving.
I'm not sure how close to completion your program is, but think about possibly giving the user some feedback from ffmpeg.
Armed with this, they can then decide if they want to drop frame rate or increase buffer size or change video and/or audio formats until no errors/warnings are emitted from ffmpeg.
This, IMO would make for a much more solid and versatile application.
EDIT:
You may also want to give an option for selecting with or without audio.
There are times where only the screen captures are important and need to be of the highest quality and audio is not needed or will be added later.
As mcewanw wrote, it depends on your machine specs.
What you can also try is selecting codecs which are lighter on your cpu and system resources.
Codecs like H264 and especially H265 require much more power than say MP4 or avi.
The PCM (or wav) audio format is also lighter than say MP3 or AAC.
Since you intend to make tuts, you could select "lighter" codecs, at the expense of bigger file sizes, then use ffmpeg a second time to further compress the video and audio and use the resulting files as your tuts to post online.
@mcewanw
Those warnings normally mean that the sync is out or about to go out or the encoder cannot keep up in grabbing the X11 frames and encode/compress them fast enough.
This could cause problems for some users if they intend to then take the captures and stick then into a NLE.
Certain codecs are very specific about the data and any deviation could cause problems especially in a NLE that tries to be frame accurate.
Generally media players are more forgiving.
I'm not sure how close to completion your program is, but think about possibly giving the user some feedback from ffmpeg.
Armed with this, they can then decide if they want to drop frame rate or increase buffer size or change video and/or audio formats until no errors/warnings are emitted from ffmpeg.
This, IMO would make for a much more solid and versatile application.
EDIT:
You may also want to give an option for selecting with or without audio.
There are times where only the screen captures are important and need to be of the highest quality and audio is not needed or will be added later.
HP Probook Laptop 4540s I7 8xcore 4G RAM. @2.2GHzmcewanw wrote:Unfortunately, the optimal commandline values to use depend on machine specs. That ffmpeg commandline I gave was pretty much optimal on my Intel Core2 duo 2GHz laptop but some error warnings don't seem to be critical anyway.
Just curious what specifications are for the machine you are running this on?
William
Plenty gutsy enough I would think.
Last edited by smokey01 on Wed 13 Jul 2016, 08:59, edited 1 time in total.
Even version 3.0.2 does not have all of the switches, for example:
Code: Select all
[AVFilterGraph @ 0xc56ff20] No such filter: 'asyncts'
Error initializing complex filters.
Invalid argument
I just built the latest version, 3.1.1, for fatdog64-710 and made a sfs.
http://smokey01.com/fd710/sfs/
http://smokey01.com/fd710/sfs/