Проблема Pixalation в mp4


0

Мы используем ниже команду ffmpeg для создания mp4. вывод, показывающий пикселяцию. Я изменил несколько параметров в команде, но пикселирование не уменьшается. Я хочу, чтобы битрейт оставался постоянным до 2000 кбит / с.

Ниже приведен полный вывод команды.

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очень низкий для 1080p. В случае, если вы позже установите -crf 1так, что будет использоваться.
Гьян

2
Вы действительно не должны использовать CBR. Это приведет к потере данных в сценах с низкой сложностью, тогда как для сцен с высокой сложностью будет недостаточно места. Вместо этого, если вам действительно нужен средний битрейт или целевой размер файла, используйте двухпроходное кодирование.
Даниэль Б

Ответы:


0

Ваше видео имеет довольно высокое разрешение (1920x1080) и относительно низкую скорость передачи данных (2 Мбит / с). Сжатое видео будет отображаться точечно, особенно вокруг встроенного текста, потому что вы просто не можете уместить столько деталей в секунду в 2 мегабитах данных. Вы не сможете выжать намного больше из этого без увеличения битрейта.


0

Оптимальная степень сжатия колеблется около 14x для h264.

Базовым расчетом пропускной способности несжатого 8-битного RGB-видео на канал является размер области, умноженный на 3 цветовых канала, умноженный на частоту кадров. Если вы возьмете этот результат (в байтах) и преобразуете в kb, а затем разделите на 14, вы получите нечто, приближающееся к субъективно оптимальной степени сжатия.

Многие калькуляторы используют коэффициент движения от 1 (низкий) до 4 (высокий) вместо количества каналов, чтобы учесть способ применения сжатия, а затем умножить на .07. Обратите внимание, что 1 /.07это около 14.

Ваш вывод предполагает 25fps при 1920 x 1080, поэтому 1080 * 1920 * 3 * 25 / 1024 / 14в первом случае или (при условии среднего-высокого движения) 1080 * 1920 * 3 * 25 / 1024 * .07для второго случая.

Очевидно, что поскольку я выбрал коэффициент движения 3, результаты очень близки: прибл. 10,000kps. При коэффициенте движения 2 это будет около 7000. Так что, как подсказывают комментарии и другие ответы, ваша цель в 2 000 немного ниже.


«Оптимальная степень сжатия, кажется, колеблется около 14x для h264». - откуда этот номер?
slhck

это в математике. (1920 * 1080 * 3 * 25/1024/1024) / x = n мбит. Быстрый Google показывает рекомендации по правильной пропускной способности, чтобы ожидать возможность просмотра 1080p с хорошим качеством на 8-12Мбит в зависимости от частоты кадров. Так что, если n равно 10, то x должно быть 14.
Йорик

Очень важно понимать, что здесь есть много ручек, которые нужно вертеть. Константа против переменной против метода против аудио кодирования против количества движения и т. Д. И т. Д.
Йорик

Да, хотя сам кодер и скорость кодирования будут иметь гораздо большее влияние. Вы также можете получить довольно хорошее видео 1080p H.264 со скоростью 3,5 Мбит / с. Рекомендации по пропускной способности обычно несколько выше, чем необходимая битрейт видео для достижения «хорошего» качества, чтобы компенсировать скачки битрейта и обеспечить лучшую буферизацию.
Slhck

PS: эти кривые искажения скорости нелинейны и зависят от разрешения видео (и его движения, как вы правильно сказали), поэтому это не простой линейный коэффициент битрейт в зависимости от качества. Отношение логарифмическое. Смотрите также: medium.com/netflix-techblog/… У вас есть ссылка на упомянутые вами калькуляторы? Было бы интересно посмотреть, что они делают.
slhck

0

Как уже упоминали другие, 2 Мбит / с немного низко для хорошего качества видео H.264 при 1080p. Если у вас есть приличный кодер и достаточно времени или ресурсов ЦП для кодирования, и если контент легко кодировать, он все равно может выглядеть приемлемым без большого количества искажений.

Что вы можете попробовать, так это двухпроходное кодирование в предустановке veryslow:

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

В Windows замените /dev/nullна NUL. См. H.264 wiki enrty для получения дополнительной информации.

Для вашей конкретной команды вы добавили -crf 1параметр, который бесполезен, если вы одновременно указываете целевой битрейт. Итак, удалите -crf 1из вашей команды.


Если это не работает, пожалуйста, покажите скриншот, сравнивающий Handbrake и ffmpeg, и укажите точные настройки, которые вы использовали в Handbrake.
Slhck
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.