肖文良 wrote:
Built from the latest git source seems not help.
following command runs about 15+ seconds. nothing was captured. If I add
-loglevel debug, this log keep being printed:
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x3234840] PACKET SIZE: 4196352, STRIDE: 5464
Here is the whole command line and output:
➜ ffmpeg git:(master) ✗ ./ffmpeg -s 1366x768 -f x11grab -i :0.0 -c libx264
-crf 28 -preset ultrafast /tmp/output.mp4
ffmpeg version N-82294-g6f0a171 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.9.2 (Debian 4.9.2-10)
configuration: --disable-yasm --enable-x11grab --enable-gpl --enable-libx264
I would install yasm and remove --disable-yasm it can make a lot of
difference perf wise.
libavutil 55. 35.100 / 55. 35.100
libavcodec 57. 66.101 / 57. 66.101
libavformat 57. 57.100 / 57. 57.100
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 66.100 / 6. 66.100
libswscale 4. 3.100 / 4. 3.100
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
[x11grab @ 0x363f4e0] Stream #0: not enough frames to estimate rate; consider
increasing probesize
Input #0, x11grab, from ':0.0':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1366x768, 29.97
fps, 1000k tbr, 1000k tbn, 1000k tbc
File '/tmp/output.mp4' already exists. Overwrite ? [y/N] y
No pixel format specified, yuv444p for H.264 encoding chosen.
Using libx264rgb will give better quality (but bigger files) than 444.
It also avoids the conversion to 444 which saves some CPU load.
If you need to make "normal" files you could recode to 420 later.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x3649060] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
AVX2 FMA3 LZCNT BMI2
[libx264 @ 0x3649060] profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit
[libx264 @ 0x3649060] 264 - core 142 r2431 a5831aa - H.264/MPEG-4 AVC codec -
Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1
deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0
me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1
chroma_qp_offset=6 threads=6 lookahead_threads=1 sliced_threads=0 nr=0
decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0
keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=28.0
qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
Output #0, mp4, to '/tmp/output.mp4':
Metadata:
encoder : Lavf57.57.100
Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p,
1366x768, q=-1--1, 29.97 fps, 30k tbn, 29.97 tbc
Metadata:
encoder : Lavc57.66.101 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[swscaler @ 0x3655080] Warning: data is not aligned! This can lead to a
speedloss
frame= 3 fps=0.1 q=-1.0 Lsize= 335kB time=00:00:00.06
bitrate=41099.8kbits/s dup=0 drop=464 speed=0.0024x
I can't reproduce this, if I make my self too slow for your command
(--disable-yasm)
I get dups rather than drops. Maybe something else is going on, or you
are way too slow.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
