Mit nye grafikkort kan køre 4 samtidige kodningssessioner. Jeg bekræftede dette tidligere ved hjælp af FFmpeg Batch AV Converter. Jeg kører det samme i MCEBuddy lige nu, og min CPU-udnyttelse er 100 % med ffmpeg som encoder, og MCEBuddy GUI’en er uresponsiv, og min maskine er sløv. Jeg vil fortsætte med at bruge MCEBuddy, men jeg kan ikke have min maskine lammet for at gøre det. Jeg var nødt til at lukke GUI’en ned for at kunne gøre noget som helst med min maskine. Jeg åbnede derefter GUI’en igen, og den viste fremskridtet for alle fire konverteringer i cirka 5 sekunder, før den låste og blev uresponsiv igen. Programmet er ikke brugbart på denne måde. Gør jeg noget forkert, og hvordan retter jeg det?
Profilen til MKV HEVC er ikke kompatibel med hardware-kodning, så hvordan sender MCEBuddy parametre videre til ffmpeg? Eller bruger det bare standardindstillingen i ffmpeg? Er der nogen måde at ændre parametrene til HW-kodning på?
Jeg skar ned til 2 samtidige konverteringer, og det holder sig under 90 %, mens andre ting kører samtidigt, så min computer i det mindste er brugbar. Jeg elsker MCEBuddy, men jeg vil gerne vide, hvordan jeg får CPU-forbruget ned for 4 samtidige konverteringer for at få hastighedsforbedringen. Jeg brugte en brugerdefineret profil i det andet program og kunne klare 4 på omkring en time uvrigt uden problemer og CPU-udnyttelse omkring 65 %.
Hvis Hardware Acceleration er markeret i konverteringsopgaven, vil den bruge hardware, hvis den registrerer, at det er tilgængeligt. Hvis du kunne vedhæfte en af logfilerne fra en konvertering, der bruger så meget CPU, kan vi måske se, hvad der foregår, og komme med nogle forslag.
Som standard forsøger den profil at bruge Handbrake først; afhængigt af dit GPU kan det dog mislykkes, fordi “medium”-forudindstillingen ikke er tilgængelig.
Desuden bliver lyden genkodet, hvilket kan tage noget CPU, da det ikke håndteres af GPU, men dette burde være en meget lille mængde. Jeg vælger at kopiere lyden i stedet.
Her er MKV HEVC-profilen.
Description=HEVC i MKV (H.265/AC3) konvertering. Opretter en mindre fil (50 % mindre end H.264) med sammenlignelig kvalitet, men meget langsom.
order=handbrake,ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec libx265 -preset medium -crf 26 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 160k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 256k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-general=--decomb --loose-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e x265 --encoder-preset medium -q 26
handbrake-audio=-E ffac3 -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
Jeg ønskede lidt mere fra profilen og ville fastlåse encoderen til det specifikke GPU, jeg bruger. Skift blot order=, hvis du foretrækker ffmpeg. Her er et par eksempler:
Intel:
[HEVC MKV Intel]
Description=HEVC i MKV fastlåst til Intel.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_qsv -preset slow -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e qsv_h265 --encoder-preset quality -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
NVidia
[HEVC MKV AnyStream NVidia]
Description=HEVC i MKV fastlåst til NVidia.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_nvenc -preset hq -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e nvenc_h265 --encoder-preset hq -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-DisableSoftwareEncoderFallback=true
AllowAllCopyRemuxing=true
Ud over at bruge hardware-kodere og optimere profiler kan du også se dette emne for detaljer om, hvordan du begrænser de ressourcer, der bruges til videoenkodning:
SystemIdleProcess…skal jeg tilføje [HEVC MKV AnyStream NVidia] som en profil til min profiles-fil for at afprøve den? I så fald skal jeg blot tilføje den under den nuværende HEVC-profil, som bruger software-encoding?
Jeg fandt svagheden i den nuværende hardware-accelererede profil i MCEBuddy, da jeg så en film i går aftes. Problemet opstår i svagt lys, hvor det meste af skærmen består af sorte, hvide og grå nuancer, fordi det er meget mørkt. Der opstår en halo- eller båndeffekt, som ringe eller gradienter af nuancer, der ligner en skydeskive med enten midten af skærmen som bullseye eller centreret omkring en person, der bevæger sig i det svage lys. Så snart rigtig farve kommer ind i scenen, forsvinder effekten eller bliver så minimal, at den ikke er mærkbar. I god belysning er billedet næsten perfekt. Jeg skiftede frem og tilbage mellem denne H.265-encoding og samme film i H.264, og i sidstnævnte er effekten ikke synlig.
Jeg vil bruge denne film til at eksperimentere med encoding-parametre, da jeg gerne vil have effekten til at forsvinde, men beholde filstørrelserne så små som muligt. Har du nogle forslag til, hvilke parametre jeg skal lege med for at rette det? Jeg regner med at encode filmen 5-6 gange med gradvist forbedret kvalitet, indtil effekten forsvinder, og bruge det som min nye profil – i hvert fald på gyserfilm, da normale lysforhold ser fine ud, som de er nu. Dette er første gang, jeg har stødt på denne anomali.
EDIT…Ok, jeg tilføjede profilen, valgte den i MCEBuddy og kører kun den film som baseline.
Tak
Jeg ved præcis, hvad du mener med de mørke/sorte scener. Jeg har ikke haft meget tid til at eksperimentere med at løse det endnu, men du er på rette spor med at øge kvaliteten (teknisk set sænke qualifier-værdien, 26 i profilen), indtil det forsvinder. Ud over det har jeg ikke rigtig nogen forslag til parameterjusteringer. Du er muligvis nødt til at bruge software til den slags film/serier også. Og måske endda bruge en main10-profil, så du får en ordentlig HDR10-rip. Eller H264 kan være vejen frem. Jeg har ærligt talt ikke svaret.
Tak for hjælpen; hvis vi begge eksperimenterer, finder vi måske svaret. Hvis jeg løser det, opretter jeg måske bare en profil til gyserfilm, da de ofte har mange mørke scener, især med bevægelse. Jeg opdagede det først, fordi jeg så “The Amityville Murders” i går, og den sidste halvdel er stort set mørk. Jeg har set effekten i almindelige film, hvor meget mørke scener mest er sort med bevægelse, men da de kun varer et sekund eller mindre, har jeg ikke fundet det værd at øge filstørrelsen for noget, de fleste ikke bemærker … jeg lægger mærke til alt.
Min H.264-kodning af filmen har kun bedre kvalitet i de mørke scener, men den er også software-kodet, så jeg vil prøve en HW-accelereret H.264 og se, om problemet fortsætter. På den ene eller anden måde finder jeg en løsning – eller også lever jeg bare med det, hvis filstørrelsen ellers bliver for stor. Jeg har set gyserfilm hver nat i ugevis, og først nu var problemet tydeligt.
Jeg lagde mærke til det i Bright, og jeg har det på samme måde; min kone bemærkede det ikke eller bekymrede sig ikke, men jeg syntes, det så forfærdeligt ud.
En genvej, du kan bruge for at spare tid, er at benytte MCEBuddy Custom Cuts-applikationen til at fjerne de andre dele af filmen, så du kun får den/de scene(r), du vil teste med. Eller brug andet software til at klippe resten væk, så du kun har den/de scene(r), du vil teste, som din kildefil.
Det er en god idé, jeg kan bare fjerne et 5-minutters afsnit, hvor jeg lagde mest mærke til det, og jeg husker det tidspunkt, så jeg kan klare al encoding på under en time.
Jeg kørte filmen igennem med din profil, som den er, én gang med crf 23 og én gang med crf 20, og der var ingen forskel mellem nogen af de tre resulterende filer. Alle havde samme størrelse og samme kvalitet med problemet stadig til stede.
Hmmm… det er underligt. Er du sikker på, at det brugte ffmpeg? Kan du vedhæfte en logfil for en af de filer, du konverterede?
[Uploading: The Amityville Murders STZEH.ts-Convert to MP4-2020-11-04T14-25-49.log…]
Dette er loggen for den sidste jeg lavede, hvor jeg indstillede crf til 20
Jeg kan ikke uploade det af en eller anden grund; den siger hele tiden “Forskellen mellem anmodningstidspunktet og det aktuelle tidspunkt er for stor”.
…Men ifølge loggen bruger den ffmpeg …men hvorfor bruger den comskip? Jeg har aldrig kørt det program; hvordan slår jeg det fra?
Det kan kalde comskip uden at gøre noget med det. Jeg ville ikke bekymre mig om det. Ser du “MCEBuddy.AppWrapper.Handbrake” et sted mod slutningen af loggen?
Nej, der er intet som det med handbrake til sidst; det bruger handbrake i starten til at tjekke ting, men derefter går det til MCEBuddy.Transcode.ConvertWithFfmpeg
Her er nogle andre muligheder for nvenc_hevc encoder presets.
-preset <int> E..V..... Indstil encoding-preset (fra 0 til 11) (standard medium) default 0 E..V..... slow 1 E..V..... hq 2 gennemløb medium 2 E..V..... hq 1 gennemløb fast 3 E..V..... hp 1 gennemløb hp 4 E..V..... hq 5 E..V..... bd 6 E..V..... ll 7 E..V..... lav latency llhq 8 E..V..... lav latency hq llhp 9 E..V..... lav latency hp lossless 10 E..V..... lossless losslesshp 11 E..V..... lossless hp
Slow kører 2 gennemløb af hq, hvilket kan give bedre resultater. Men ærligt talt, vi er måske på vildspor. Måske skulle vi bare søge lidt rundt på internettet efter ffmpeg og nvenc_hevc.
Ærligt talt, jeg har primært brugt Intel hardware encoding på det seneste, fordi det er det, jeg har på min sekundære maskine, hvor jeg laver det meste af min optagelse/encoding.
Jeg fandt ud af, hvorfor ændring af crf-værdien ingen effekt havde på den resulterende video…crf er kun til software-kodning, du skal bruge en cq-værdi med nvenc.
Desuden har alle de profiler, du postede, endnu en fejl…de bruger software-kodning til alt før nvenc-parameteren, f.eks. deinterlacing. Du kan bruge yadif i nvenc, og jeg testede det i ffmpeg Batch, og når du lader GPU’en stå for deinterlacing, er kodningstiden halvt så lang som med MCEBuddy…jeg har bare ikke fundet ud af, hvordan jeg succesfuldt sender alle parametre til nvenc i MCEBuddy, som profilerne er struktureret. Jeg bliver ved med at få fejl.