[SOLVED] ffmpeg recording problems (framedrop)

neverscaired · 2015-12-07 16:22:13

Generraly, I wanna record some videos from X using ffmpeg. Everything seems to be ok, but I get framedrops in output mp4 file.
I guess my HDD or filesystem or smth else cann't write information so fast as needed.
So, the question is : "Is there any fast filesystem for fast writing data to file ? "
Now I'm using ext4 one.

PS Sorry I don't know how to hide this to spoiler

Output #0, mp4, to 'record.mp4':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 1280x720, q=-1--1, 60 fps, 15360 tbn, 60 tbc
    Metadata:
      encoder         : Lavc56.60.100 libx264
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
Past duration 1.179390 too large
Past duration 0.990013 too large
Past duration 0.778679 too large
Past duration 0.788506 too large
frame=   36 fps=0.0 q=18.0 size=     508kB time=00:00:00.48 bitrate=8601.9kbits/Past duration 0.681572 too large
Past duration 0.979866 too large
frame=   66 fps= 64 q=19.0 size=     730kB time=00:00:00.98 bitrate=6083.1kbits/Past duration 1.140648 too large
Past duration 1.154793 too large
Past duration 0.945107 too large
Past duration 1.341393 too large
Past duration 1.194191 too large
frame=   96 fps= 63 q=23.0 size=    1145kB time=00:00:01.48 bitrate=6322.0kbits/Past duration 1.101418 too large
Past duration 1.655907 too large
Past duration 1.613106 too large
frame=  129 fps= 62 q=19.0 size=    2101kB time=00:00:02.03 bitrate=8466.2kbits/Past duration 0.694176 too large
Past duration 0.896111 too large
Past duration 1.558266 too large
Past duration 1.531898 too large
Past duration 1.658653 too large
Past duration 1.692238 too large
Past duration 1.637306 too large
Past duration 1.631767 too large
Past duration 1.581947 too large
Past duration 1.625191 too large
Past duration 1.616386 too large
Past duration 1.558174 too large
Past duration 0.844398 too large
frame=  160 fps= 62 q=18.0 size=    2745kB time=00:00:02.55 bitrate=8819.3kbits/frame=  190 fps= 62 q=18.0 size=    2967kB time=00:00:03.05 bitrate=7969.5kbits/frame=  220 fps= 61 q=18.0 size=    3130kB time=00:00:03.55 bitrate=7222.2kbits/Past duration 0.767815 too large
Past duration 0.759438 too large
frame=  250 fps= 61 q=18.0 size=    3377kB time=00:00:04.05 bitrate=6831.1kbits/Past duration 0.744392 too large
frame=  264 fps= 61 q=-1.0 Lsize=    3812kB time=00:00:04.40 bitrate=7097.7kbits/s dup=132 drop=0    
video:3810kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.049336%
[libx264 @ 0x564a80067700] frame I:2     Avg QP:18.00  size:295466
[libx264 @ 0x564a80067700] frame P:262   Avg QP:20.10  size: 12635
[libx264 @ 0x564a80067700] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 0x564a80067700] mb P  I16..4:  1.9%  0.0%  0.0%  P16..4: 18.6%  0.0%  0.0%  0.0%  0.0%    skip:79.4%
[libx264 @ 0x564a80067700] coded y,u,v intra: 61.6% 17.5% 15.1% inter: 9.7% 2.4% 2.2%
[libx264 @ 0x564a80067700] i16 v,h,dc,p: 26% 28% 28% 18%
[libx264 @ 0x564a80067700] kb/s:7093.15
Exiting normally, received signal 2.

.

Last edited by neverscaired (2015-12-11 02:41:13)

R00KIE · 2015-12-08 11:51:44

I would start by checking if you are not cpu limited in the encoding process. If you are not cpu limited then you probably have to try a few different filesystems and see which one works better. I'd say that depending on how much ram you have and how large the final file will be you could use tmpfs to store the recording while you are doing it.

esa · 2015-12-08 12:14:12

I've not had any issues on a ext4 partition.
Even on my old laptop (2x1.7ghz, 2 gb ram, 320 gb hdd, intel hd) played very well with ffmpeg, no 'tearings' no laggisch fps.

Also, without seeing the command, cant say what might have an influence on the overall peformance.
This said, me have no issues recording my screen using my VHS (see sig): "vhs -S", if you would like to try that, or share your acual executed command.

hth

Lone_Wolf · 2015-12-08 17:23:41

"Past duration too large" appears to be a warning,not an error.

http://superuser.com/questions/902661/f … -too-large
http://stackoverflow.com/questions/3078 … large-mean

mpan · 2015-12-08 18:28:53

@neverscaired
The fastest filesystem is no filesystem at all. ffmpeg usually has no problems writing directly to a block device. If stream output works, consider chaining ffmpeg (via pipe:# construct) with dd to optimize write block size. This way you should get maximum write speed, assuming that nothing is simulatenously performing I/O on the same device.

I'm not sure, however, if the gain is worth the fight. Most probably CPU will be the limiting factor.

neverscaired · 2015-12-10 02:21:50

I've checked some other filesystems (btfs reiserfs jfs xfs)and recording results differ. So I guess this factor has some influence to result.
Do you mean that CPU is a bottleneck in my case? Or some software blocks ffmpeg's CPU usage ?
Okay, I will try pipe method and report results to this thread.

Used command:

ffmpeg -f x11grab -video_size 1280x720 -i :0+320,180 -c:v libx264 -preset ultrafast -r 60 record.mp4

Some info some one needs

 Intel Core i5 3470 3.3GHz 
 Asus Geforce GT 730 (2gb ggr5) with nvidia 358.16-2.1 driver
 Two HDDs, second of them is empty and used for tests

EDITED:
I've tryed to record to /tmp (tmpfs) and get no changes for output framerate. So, filesystem isn't a big problem in this situation.

Last edited by neverscaired (2015-12-10 02:55:59)

R00KIE · 2015-12-11 01:41:30

neverscaired wrote:

Do you mean that CPU is a bottleneck in my case? Or some software blocks ffmpeg's CPU usage ?

That is something you have to check, I have no idea if it is not. Check with top if when you have problems ffmpeg is pegged at 100% cpu usage if the encoder is running only in one thread. If you don't max out any cpu cores then the cpu should be able to handle de encoding task and the problem is somewhere else.

neverscaired · 2015-12-11 02:37:39

Thank you all for help. My mistake was in not using multythreading.
Parsing -threads 4 solved the problem.
Used command (hope will be usefull for someone.)

 ffmpeg -f x11grab -video_size 1280x720  -c:v libx264 -preset ultrafast -framerate 60 -threads 4  -qp 0 output.mp4

DrZaius · 2015-12-11 21:13:03

By default libx264 will automatically choose the optimal number of threads.

You should use -framerate as an input option. This is a private option for the x11grab input device. As an output option it is ignored by libx264. If you want to change output frame rate use -r, but that is not recommended because you would be converting the default input frame rate of 25 to 60 thus duplicating frames for no reason.

You can test without write overhead with:

ffmpeg -i input [output options] -f null -

Last edited by DrZaius (2015-12-11 21:19:46)

Arch Linux

#1 2015-12-07 16:22:13

[SOLVED] ffmpeg recording problems (framedrop)

#2 2015-12-08 11:51:44

Re: [SOLVED] ffmpeg recording problems (framedrop)

#3 2015-12-08 12:14:12

Re: [SOLVED] ffmpeg recording problems (framedrop)

#4 2015-12-08 17:23:41

Re: [SOLVED] ffmpeg recording problems (framedrop)

#5 2015-12-08 18:28:53

Re: [SOLVED] ffmpeg recording problems (framedrop)

#6 2015-12-10 02:21:50

Re: [SOLVED] ffmpeg recording problems (framedrop)

#7 2015-12-11 01:41:30

Re: [SOLVED] ffmpeg recording problems (framedrop)

#8 2015-12-11 02:37:39

Re: [SOLVED] ffmpeg recording problems (framedrop)

#9 2015-12-11 21:13:03

Re: [SOLVED] ffmpeg recording problems (framedrop)

Board footer