Pixalation Ausgabe in mp4

392
Dinesh Gaikwad

Wir verwenden den folgenden ffmpeg-Befehl für die Erstellung von mp4-Dateien. Ausgabe zeigt die Pixalation. Ich habe mehrere Parameter im Befehl geändert, aber die Pixalation wird nicht reduziert. Ich möchte die Bitrate konstant auf 2000 kbps halten.

Unter folgendem Befehl finden Sie die vollständige Ausgabe.

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" ist für 1080p sehr niedrig. Falls Sie später '-crf 1' eingestellt haben, wird dies verwendet. Gyan vor 5 Jahren 0
Sie sollten CBR wirklich nicht verwenden. Es wird Daten in Szenen mit geringer Komplexität verschwenden, während für Szenen mit hoher Komplexität nicht genügend Platz vorhanden ist. Wenn Sie * wirklich * eine durchschnittliche Bitrate oder Zieldateigröße haben müssen, verwenden Sie stattdessen die 2-Pass-Kodierung. Daniel B vor 5 Jahren 2
Siehe auch https://slhck.info/video/2017/03/01/rate-control.html slhck vor 5 Jahren 0

3 Antworten auf die Frage

0
gronostaj

Ihr Video hat eine recht hohe Auflösung (1920 x 1080) und eine relativ niedrige Bitrate (2 MBit / s). Komprimiertes Video wird pixelig dargestellt, insbesondere in Bezug auf eingebetteten Text, da in 2 Megabits Daten nicht so viele Details pro Sekunde angepasst werden können. Sie können nicht viel mehr herausdrücken, ohne die Bitrate zu erhöhen.

0
Yorik

Das optimale Kompressionsverhältnis scheint für h264 um 14x zu schwanken.

Die Basisberechnung für den Durchsatz von unkomprimiertem RGB-Video mit 8 Bit pro Kanal ist die Flächenabmessung mal 3 Farbkanäle mal die Bildfrequenz. Wenn Sie dieses Ergebnis (in Bytes) in kb konvertieren und dann durch 14 teilen, erhalten Sie etwas, das sich dem subjektiv optimalen Kompressionsverhältnis nähert.

Viele Rechner verwenden den Bewegungsfaktor von 1 (niedrig) bis 4 (hoch) anstelle der Anzahl von Kanälen, um die Art und Weise zu berücksichtigen, in der die Kompression angewendet wird, und multiplizieren mit .07. Beachten Sie, dass 1 /.07es ungefähr 14 ist.

Ihre Ausgabe schlägt 25fps @ 1920 x 1080 vor, also 1080 * 1920 * 3 * 25 / 1024 / 14im ersten Fall oder (unter Annahme einer mittelhohen Bewegung) 1080 * 1920 * 3 * 25 / 1024 * .07für den zweiten Fall.

Da ich mich für einen Bewegungsfaktor von 3 entschieden habe, sind die Ergebnisse sehr nahe: Ca. 10.000 kps. Bei einem Bewegungsfaktor von 2 wären das etwa 7.000. Wie von Kommentaren und anderen Antworten vorgeschlagen, ist Ihr Ziel von 2.000 etwas niedrig.

"Das optimale Kompressionsverhältnis scheint für h264 um das 14-fache zu schwanken." - Woher kommt diese Nummer? slhck vor 5 Jahren 0
Es ist in der Mathematik. (1920 * 1080 * 3 * 25/1024/1024) / x = n mbits. Quick google zeigt Empfehlungen für den richtigen Durchsatz an, um zu erwarten, 1080p mit guter Qualität bei 8-12 MBit je nach Bildfrequenz zu sehen. Wenn also n 10 ist, muss x 14 sein. Yorik vor 5 Jahren 0
Es ist wirklich wichtig zu verstehen, dass hier viele Knöpfe zu drehen sind. Konstante vs. Variable vs. Methode vs. Audiokodierung vs. Bewegungsumfang usw. Yorik vor 5 Jahren 0
Ja, obwohl der Encoder selbst und die Codierungsgeschwindigkeit eine viel größere Auswirkung haben werden. Mit 3,5 Mbit / s erhalten Sie auch ein ziemlich gutes 1080p-H.264-Video. Die Durchsatzempfehlungen sind in der Regel etwas höher als die erforderliche Video-Bitrate, um eine „gute“ Qualität zu erreichen, um Bitraten-Spitzen zu kompensieren und bessere Pufferung zu ermöglichen. slhck vor 5 Jahren 0
PS: Diese Rate-Distortion-Kurven sind nicht linear und hängen von der Auflösung des Videos (und seiner Bewegung, wie Sie richtig gesagt haben) ab. Es handelt sich also nicht um einen einfachen linearen Faktor für die Bitrate und die Qualität. Die Beziehung ist logarithmisch. Siehe auch: https://medium.com/netflix-techblog/per-title-encode-optimization-7e99442b62a2 Haben Sie eine Referenz für die von Ihnen erwähnten Rechner? Würde mich interessieren, was sie tun. slhck vor 5 Jahren 0
Vielen Dank für Informationen ... Ich habe die Datei mit der Handbremsen-Software mit einer Bitrate von 2000 kbps transcodiert. Die Ausgabe zeigte keine Pixalation. Ich habe den gleichen Parameter in ffmpeg beibehalten, die Ausgabe ist pixalate .. Dinesh Gaikwad vor 5 Jahren 0
@DineshGaikwad Handbrake verwendet einen vollständig anderen Codierungsmodus (variable oder einstellbare Bitrate mit variablen Durchgängen), wenn Sie die Bitrate in der GUI festlegen. Ihr Befehl ffmpeg erzwingt eine konstante Bitrate, die für die Qualität schädlich ist. Welches Ergebnis möchten Sie am Ende erreichen? Soll die Datei eine bestimmte Größe haben oder müssen Sie die Variation der Bitrate einschränken? (Bitte antworten Sie mit `@ slhck`, ansonsten erhalte ich keine Benachrichtigung.) slhck vor 5 Jahren 0
@slhck Ich hatte die konvertierte Datei von der Handbremse geprüft. Es werden 2 Kbit / s angezeigt ... mit guter Qualität .. Es gibt keine Möglichkeit, die Menge in ffmpe bei niedriger Bitrate zu verbessern. Dinesh Gaikwad vor 5 Jahren 0
@DineshGaikwad Sie haben immer noch nicht erklärt, was Ihr tatsächlicher Anwendungsfall ist. slhck vor 5 Jahren 0
@slhck Ich brauche nur wenig Bitrate ... Dinesh Gaikwad vor 5 Jahren 0
@ Dinesh Was ist "ein bisschen"? Und warum brauchst du es? Wie wird dieses Video gestreamt oder gespeichert? slhck vor 5 Jahren 0
Wir müssen dieses Video speichern. +1 Mbps-Variation wird für mich akzeptabel sein .. Dinesh Gaikwad vor 5 Jahren 0
0
slhck

Wie andere bereits erwähnt haben, ist 2 Mbit / s für gutes H.264-Video bei 1080p etwas niedrig. Wenn Sie über einen guten Encoder verfügen und über genügend Zeit oder CPU-Ressourcen zum Codieren verfügen, und wenn der Inhalt einfach codiert werden kann, sieht er dennoch ohne große Verzerrungen akzeptabel aus.

Was Sie ausprobieren können, ist eine Zwei-Pass-Codierung im 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

Ersetzen Sie unter Windows /dev/nullmit NUL. Weitere Informationen finden Sie in der H.264-Wiki-Umgebung .

Für Ihren speziellen Befehl haben Sie die -crf 1Einstellung hinzugefügt, die unbrauchbar ist, wenn Sie gleichzeitig eine Ziel-Bitrate angeben. Also -crf 1von deinem Befehl entfernen .

Wenn dies nicht funktioniert, zeigen Sie bitte einen Screenshot zwischen Handbrake und ffmpeg und die genauen Einstellungen, die Sie in Handbrake verwendet haben. slhck vor 5 Jahren 0

Verwandte Probleme