0

We are using below ffmpeg command for mp4 creation. output showing the pixalation. I have alter multiple parameter in command but pixalation not getting reduce. I want to kept bitrate constant to 2000kbps.

Please find below command full output..

C:\Users\Iplay>"D:\DG\FFAStrans0.9.2 (1)\Processors\ffmpeg\x64\ffmpeg.exe" -i "D:\AFSAR_BITIYA_EP159_CREATIVE_MASTER - Copy.mxf" -c:v libx264 -s 1920x1080 -r 25 -aspect 16:9 -b:v 2000k -minrate 2000k -maxrate 2000k -bufsize 78000k  -preset veryslow -vprofile high -vlevel 4.1 -crf 1 -coder 1 -pix_fmt yuv420p -movflags +faststart -g 30 -bf 2 -c:a aac -b:a 320k -write_tmcd 0 -map 0:0 -map 0:1 -af "pan=stereo|c0=c6|c1=c7" -vf "drawtext=fontfile=/Windows/Fonts/arial.ttf:fontsize=80:x=800:y=900:box=1:boxcolor=black@0.5:rate='25000/1001':fontcolor=white:timecode='09\:59\:55\:00" "D:\test.mp4"ffmpeg version N-91398-gd08d4a8c73 Copyright (c) 2000-2018 the FFmpeg developers built with gcc 7.3.0 (GCC)configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth libavutil      56. 18.102 / 56. 18.102 libavcodec     58. 20.104 / 58. 20.104 libavformat    58. 17.101 / 58. 17.101 libavdevice    58.  4.101 / 58.  4.101 libavfilter     7. 25.100 /  7. 25.100 libswscale      5.  2.100 /  5.  2.100 libswresample   3.  2.100 /  3.  2.100 libpostproc    55.  2.100 / 55.  2.100[mxf @ 0000000001e65e80] Stream #0: not enough frames to estimate rate; consider increasing probesize Guessed Channel Layout for Input Stream #0.1 : 7.1Input #0, mxf, from 'D:\AFSAR_BITIYA_EP159_CREATIVE_MASTER - Copy.mxf':Metadata:
uid             : 682d6935-8748-11e8-bc3a-6cab31f179f2
generation_uid  : 682d6936-8748-11e8-9e20-6cab31f179f2
company_name    : Adobe Systems Incorporated
product_name    : Adobe Media Encoder
product_version : 12.0.0
application_platform: Mac OS X
product_uid     : 0c3919fe-46e8-11e5-a151-feff819cdc9f
modification_date: 2018-07-14T09:29:29.000000Z
material_package_umid: 0x060A2B340101010501010D1113000000A8600902138305BA6E516CAB31F179F2
timecode        : 09:59:55:00 Duration: 00:20:19.76, start: 0.000000, bitrate: 123289 kb/s
Stream #0:0: Video: h264 (High 4:2:2 Intra), yuv422p10le(pc, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Metadata:
  file_package_umid: 0x060A2B340101010501010D12130F8533A8600902138305BA70266CAB31F179F2
  file_package_name: Source Package
  track_name      : Track 1
Stream #0:1: Audio: pcm_s24le, 48000 Hz, 7.1, s32 (24 bit), 9216 kb/s
Metadata:
  file_package_umid: 0x060A2B340101010501010D12130F8533A8600902138305BA70266CAB31F179F2
  file_package_name: Source Package
  track_name      : Track 2 File 'D:\test.mp4' already exists. Overwrite ? [y/N] y Stream mapping:Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native)) Press [q] to stop, [?] for help [Parsed_pan_0 @ 0000000002dbfd80] Pure channel mapping detected: 6 7[libx264 @ 0000000001e6e9c0] using SAR=1/1[libx264 @ 0000000001e6e9c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2[libx264 @ 0000000001e6e9c0] profile High, level 4.1[libx264 @ 0000000001e6e9c0] 264 - core 155 r2901 7d0ff22 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options:cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=34 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=2 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=30 keyint_min=3 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=2000 vbv_bufsize=78000 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'D:\test.mp4':Metadata:uid             : 682d6935-8748-11e8-bc3a-6cab31f179f2
generation_uid  : 682d6936-8748-11e8-9e20-6cab31f179f2
company_name    : Adobe Systems Incorporated
product_name    : Adobe Media Encoder
product_version : 12.0.0
application_platform: Mac OS X
product_uid     : 0c3919fe-46e8-11e5-a151-feff819cdc9f
modification_date: 2018-07-14T09:29:29.000000Z
material_package_umid: 0x060A2B340101010501010D1113000000A8600902138305BA6E516CAB31F179F2
timecode        : 09:59:55:00
encoder         : Lavf58.17.101
Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 25 fps, 12800 tbn, 25 tbc Metadata:
  file_package_umid: 0x060A2B340101010501010D12130F8533A8600902138305BA70266CAB31F179F2
  file_package_name: Source Package
  track_name      : Track 1
  encoder         : Lavc58.20.104 libx264
Side data:
  cpb: bitrate max/min/avg: 2000000/0/2000000 buffer size: 78000000 vbv_delay: -1
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp (24 bit), 320 kb/s
Metadata:
  file_package_umid: 0x060A2B340101010501010D12130F8533A8600902138305BA70266CAB31F179F2
  file_package_name: Source Package
  track_name      : Track 2
  encoder         : Lavc58.20.104 aac[mp4 @ 000000000302e6c0] Starting second pass: moving the moov atom to the beginning of the fileframe=29387 fps= 23 q=-1.0 Lsize=  327414kB time=00:19:36.06 bitrate=2280.6kbits/s speed=0.915x video:290809kB audio:35787kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.250163% [libx264 @ 0000000001e6e9c0] frame I:1175  Avg QP:28.61  size: 68899b[libx264 @ 0000000001e6e9c0] frame P:10535 Avg QP:32.59  size: 13694 [libx264 @ 0000000001e6e9c0] frame B:17677 Avg QP:35.32  size:  4105 [libx264 @ 0000000001e6e9c0] consecutive B-frames:  6.1% 14.7% 79.2% [libx264 @ 0000000001e6e9c0] mb I  I16..4: 28.2% 65.6%  6.2% [libx264 @ 0000000001e6e9c0] mb P  I16..4:  3.6%  5.1%  0.1%  P16..4: 34.1%  3.0%  5.6%  0.0%  0.0%    skip:48.4% [libx264 @ 0000000001e6e9c0] mb B  I16..4:  0.2%  0.3%  0.0%  B16..8: 36.6%  1.0%  0.2%  direct: 0.5%  skip:61.2%  L0:41.1% L1:57.9% BI: 1.1% [libx264 @ 0000000001e6e9c0] 8x8 transform intra:61.9% inter:80.2% [libx264 @ 0000000001e6e9c0] direct mvs  spatial:98.2% temporal:1.8% [libx264 @ 0000000001e6e9c0] coded y,uvDC,uvAC intra: 38.1% 42.5% 10.9% inter: 3.3% 3.7% 0.1% [libx264 @ 0000000001e6e9c0] i16 v,h,dc,p: 21% 21% 12% 47% [libx264 @ 0000000001e6e9c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11%  6% 11% 11% 15% 13% 12% 11% 10% [libx264 @ 0000000001e6e9c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17%  7%  4% 11% 13% 15% 11% 11% 11%[libx264 @ 0000000001e6e9c0] i8c dc,h,v,p: 38% 34% 18% 10% [libx264 @ 0000000001e6e9c0] Weighted P-Frames: Y:1.8% UV:1.3 [libx264 @ 0000000001e6e9c0] ref P L0: 60.2% 14.2% 19.9%  5.5%  0.1%  0.0% [libx264 @ 0000000001e6e9c0] ref B L0: 83.9% 14.1%  2.1%[libx264 @ 0000000001e6e9c0] kb/s:2026.66[aac @ 0000000001e97200] Qavg: 65535.969

-Dinesh

  • 2000k is very low for 1080p. In case, you've later set -crf 1 so that will be used. – Gyan Aug 1 '18 at 14:40
  • 2
    You really should not use CBR. It will waste data on low-complexity scenes while there’s insufficient room for high-complexity scenes. Instead, if you really must have an average bitrate or target filesize, use 2-pass encoding. – Daniel B Aug 1 '18 at 14:56
  • See also slhck.info/video/2017/03/01/rate-control.html – slhck Aug 1 '18 at 18:58
0

Your video has quite a high resolution (1920x1080) and relatively low bitrate (2Mbps). Compressed video will appear pixelated, especially around embedded text, because you just can't fit that much details per second in 2 megabits of data. You won't be able to squeeze much more out of it without increasing bitrate.

0

The optimal compression ratio seems to hover around 14x for h264.

The basic calculation for throughput of uncompressed RGB 8-bit per channel video is the area dimensions times 3 color channels times the framerate. If you take that result (in bytes) and convert to kb and then divide by 14, you get something approaching the subjectively optimal compression ratio.

Many calculators use the motion factor from 1 (low) - 4 (high) instead of # of channels to account for the manner in which compression is applied and then multiply by .07. Note that 1 /.07 is about 14.

Your output suggests 25fps @ 1920 x 1080, so 1080 * 1920 * 3 * 25 / 1024 / 14 in the first case or (assuming medium-high motion) 1080 * 1920 * 3 * 25 / 1024 * .07 for the second case.

Obviously, since I chose a motion factor of 3, the results are very close: approx. 10,000kps. With a motion factor of 2, it would be about 7,000. So as suggested by comments and other answers, your target of 2,000 is a little low.

  • "The optimal compression ratio seems to hover around 14x for h264." — where does that number come from? – slhck Aug 1 '18 at 15:29
  • its in the math. (1920 * 1080 * 3 * 25 / 1024 / 1024) / x = n mbits. Quick google shows recommendations for proper throughput to expect to be able to watch 1080p with good quality at about 8-12mbit depending on framerate. So if n is 10, then x needs to be 14. – Yorik Aug 1 '18 at 18:44
  • It is really important to understand that there are a lot of knobs to twiddle here though. Constant vs variable vs method vs audio encoding vs amount of motion etc etc. – Yorik Aug 1 '18 at 18:48
  • Yes, though the encoder itself and the encoding speed will have a much greater impact. You can get quite good 1080p H.264 video at 3.5 Mbit/s, too. The throughput recommendations are typically somewhat higher than the necessary video bitrate to achieve “good” quality, in order to compensate for bitrate spikes and allow for better buffering. – slhck Aug 1 '18 at 18:56
  • PS: these rate-distortion curves are non-linear and dependent on the resolution of the video (and its motion, as you correctly said), so it's not a simple linear factor of bitrate vs. quality. The relationship is logarithmic. See also: medium.com/netflix-techblog/… Do you have a reference for those calculators you mentioned? Would be interested in seeing what they're doing. – slhck Aug 1 '18 at 19:00
0

As others have mentioned, 2 Mbit/s is a little bit low for good quality H.264 video at 1080p. If you have a decent encoder and enough time or CPU resources for encoding, and if the content is easy to encode, it might still look acceptable without a lot of distortions.

What you can try is a two-pass encode at the veryslow preset:

ffmpeg -y -i input -c:v libx264 -b:v 2000k -pass 1 -preset veryslow -an -f mp4 /dev/null
ffmpeg -i input -c:v libx264 -b:v 2000k -pass 2 -preset veryslow -c:a aac -b:a 128k output.mp4

On Windows, replace /dev/null with NUL. See the H.264 wiki enrty for more info.

For your particular command, you have added the -crf 1 setting which is useless if you at the same time specify a target bitrate. So, remove -crf 1 from your command.

  • If this does not work, please show a screenshot comparing Handbrake and ffmpeg and show the exact settings you were using in Handbrake. – slhck Aug 2 '18 at 11:36

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.