Проблема Pixalation в mp4

331
Dinesh Gaikwad

Мы используем ниже команду 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

0
`2000k` очень низок для 1080p. В случае, если вы позже установите `-crf 1`, так что это будет использоваться. Gyan 5 лет назад 0
Вы действительно не должны использовать CBR. Это приведет к потере данных в сценах с низкой сложностью, тогда как для сцен с высокой сложностью будет недостаточно места. Вместо этого, если вы * действительно * должны иметь средний битрейт или целевой размер файла, используйте 2-проходное кодирование. Daniel B 5 лет назад 2
Смотрите также https://slhck.info/video/2017/03/01/rate-control.html slhck 5 лет назад 0

3 ответа на вопрос

0
gronostaj

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

0
Yorik

Оптимальная степень сжатия, кажется, колеблется около 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 5 лет назад 0
это в математике. (1920 * 1080 * 3 * 25/1024/1024) / x = n мбит. Быстрый Google показывает рекомендации по правильной пропускной способности, чтобы ожидать возможность просмотра 1080p с хорошим качеством на 8-12Мбит в зависимости от частоты кадров. Поэтому, если n равно 10, тогда x должно быть 14. Yorik 5 лет назад 0
Очень важно понимать, что здесь есть много ручек, которые нужно вертеть. Константа против переменной против метода против аудио кодирования против количества движения и т. Д. И т. Д. Yorik 5 лет назад 0
Да, хотя сам кодер и скорость кодирования будут иметь гораздо большее влияние. Вы также можете получить неплохое видео в формате 1080p H.264 со скоростью 3,5 Мбит / с. Рекомендации по пропускной способности обычно несколько выше, чем необходимая битрейт видео для достижения «хорошего» качества, чтобы компенсировать скачки битрейта и обеспечить лучшую буферизацию. slhck 5 лет назад 0
PS: эти кривые искажения скорости нелинейны и зависят от разрешения видео (и его движения, как вы правильно сказали), так что это не простой линейный коэффициент битрейт против качества. Отношение логарифмическое. См. Также: https://medium.com/netflix-techblog/per-title-encode-optimization-7e99442b62a2. У вас есть ссылка на упомянутые вами калькуляторы? Было бы интересно посмотреть, что они делают. slhck 5 лет назад 0
Спасибо за информацию ... Я транскодировал файл, используя программное обеспечение ручного тормоза с битрейтом 2000 кбит / с. На выходе не было пикселов. я сохранил тот же параметр в ffmpeg, вывод является pixalate .. Dinesh Gaikwad 5 лет назад 0
@DineshGaikwad Handbrake использует совершенно другой режим кодирования (переменная скорость передачи в один или два прохода), если вы устанавливаете скорость передачи в графическом интерфейсе. Ваша команда ffmpeg форсирует постоянный битрейт, что вредно для качества. Какого результата вы хотите достичь в итоге? Должен ли файл иметь определенный размер или вам нужно ограничить изменение битрейта? (Пожалуйста, ответьте `@ slhck`, иначе я не получу уведомление.) slhck 5 лет назад 0
@slhck Я проверил конвертированный файл с ручного тормоза .. Он показывает 2 кбит / с ... с хорошим качеством .. есть какой-то способ улучшить количество в ffmpe при низком битрейте .. Dinesh Gaikwad 5 лет назад 0
@DineshGaikwad Вы все еще не объяснили, каков ваш фактический вариант использования. slhck 5 лет назад 0
@slhck Мне нужно небольшое изменение в битрейте ... Dinesh Gaikwad 5 лет назад 0
@Dinesh Что такое "немного"? А зачем тебе? Как это видео будет транслироваться или храниться? slhck 5 лет назад 0
Нам нужно сохранить это видео. Вариант +1 Мбит / с будет приемлем для меня .. Dinesh Gaikwad 5 лет назад 0
0
slhck

Как уже упоминали другие, 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 5 лет назад 0

Похожие вопросы