Når jeg kigger på FFMPEG-versionen i MCEBuddy, står der “N-95085-g525de95679”, hvilket ikke afslører meget om datoerne/versionerne af FFMPEG. Der står, at den er bygget med gcc 20190918, men det er ikke klart, om det er datoen for GCC-compileren, der blev brugt til at bygge denne version af FFMPEG, eller datoen for hvornår FFMPEG blev hentet fra git-kildearkivet og bygget.
Jeg kan se, at Gyan Doshi offentliggør ugentlige builds, der inkluderer NVENC- og NVDEC-encoder/decoder.
Se her: Builds - CODEX FFMPEG @ gyan.dev
Handbrake ser ud til at være version 1.3.3 med NVENC version 12.0.
Den nuværende version er 1.5.1. Jeg ved ikke, om Handbrake inkluderer NVDEC-decoderen eller kun NVENC-encoderen.
Mit spørgsmål er, om vi kan drop-in erstatte .exe-filerne for FFMPEG og HandbrakeCLI med nyere versioner?
Hvis ikke, hvornår kan vi forvente, at disse kritiske hjælpeprogrammer opgraderes til de nyeste versioner i MCEBuddy?
Er det muligt at udnytte GPU decodere til comskip?
Vi tester nyere versioner af de forskellige værktøjer. Vi er nødt til at teste for stabilitet og ydeevne (samt kompatibilitet). Ofte har nyere versioner fejl eller undertiden dårligere ydeevne; for eksempel har vi forskellige builds af HandBrake til Intel QSV-konverteringer og til NVEnc-konverteringer. Hver testcyklus tager uger med 24x7-test på mange maskiner og hundredtusindvis af filer, før de certificeres til generel brug med MCEBuddy.
Men til personlig brug, absolut gå videre og foretag en direkte erstatning, test det og del endelig din feedback.
Opdateret FFMPEG er også noget, jeg utålmodigt venter på.
Jeg bruger ikke længere MCEBuddy til at re-encode mine optagelser, fordi det ikke håndterer AC-4-lyd brugt i ATSC 3.0. I stedet lader jeg det blot kopiere og omdøbe filerne og lader Emby transcode dem, da Emby har en opdateret FFMPEG, der kan håndtere det. Men jeg vil virkelig gerne begynde at bruge MCEBuddy igen, da jeg har langt flere konfigurations- og kontrolmuligheder med det.
Ffmpeg udgivelsesversioner understøtter endnu ikke ac-4. Det er stadig under udvikling, men hvis du har de forudgående udviklingsversioner, kan du altid placere dem og bruge dem med MCEBuddy.
Emby-builds er baseret på en FFMPEG 5-træstruktur.
I transcode-loggene ser jeg:
*01:56:01.333 ffmpeg version 5.1-emby_2022_10_11 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC*
*01:56:01.334 built with gcc 10.3.0 (Rev5, Built by MSYS2 project)*
Jeg prøvede at erstatte dem med MCEBuddy-builds, men så ville opgaverne ikke køre. Det er et stykke tid siden, men så vidt jeg husker, var det kommandoen, som MCEBuddy sendte til FFMPEG, der ikke fungerede.
Jeg smed Handbrake-CLI v1.5.1 i, og indtil videre går det fint. Ingen problemer. Win10x64 22H2 (19045.2364), i5-4430, RTX-2060.
Det lader til, at GPU-blæserne kører lavere end fuld skrue. GPU-udnyttelsen ligger på 60-70 %, måske en tand lavere? CPU-udnyttelsen er stadig omkring 95 % under encoding.
Jeg har ikke kørt den samme fil igennem med begge versioner, men den samme udsendelse fra samme kanal, der tidligere blev behandlet med MCE Buddy og Handbrake 1.3.1, ser ud til at have en lavere chroma end udsendelsen behandlet med 1.5.1, da jeg afspillede dem side om side og synkroniserede videoen for at se, hvordan de adskilte sig mellem de to Handbrake-versioner.
Jeg ved ikke, om behandlingstiden er langsommere eller hurtigere mellem versionerne af Handbrake. Jeg transkoder til H.265 og AC3 i en MKV-container.
Comskip - 0.80.003. Nuværende donator-version er 0.82.012.
Usikkert om den bruger ekstern ffmpeg eller har sin egen indlejrede version.
Forhåbentlig vil den bruge den fra MCEBuddy.
Lige en note om udgivelsen af HandBrake 1.7, der lige er blevet offentliggjort på GitHub. Blandt andet vil den indlejrede FFMPEG være v6.1, og der kommer understøttelse af AV1, herunder NVENC. Den bør være officielt tilgængelig i løbet af de næste par dage; den findes allerede i nightly builds.
Bemærkelsesværdigt i ovenstående er inklusionen af NVENC SV1 (nVidia-hardwarekodning til SV1).
Dette findes nu i Handbrake-nightly-builds, og Handbrake 1.7.0 burde udkomme inden længe.
NVENC SV1 GPU-kodning er dog kun tilgængelig på de nye Ada-kort (RTX40-serien).
Det er uvist, om nVidia vil backporte encoderen til RTX10-serien (Pascal), RTX20-serien (Turing) eller RTX30-serien (Ampere). Jeg har ikke selv et RTX40-serie-kort, så jeg ser ikke muligheden.
Hvis jeg skaffer et RTX40-serie-kort, vil det være det afgørende øjeblik for mig til at skifte fra x265.
Den åbne kodeks-lydekvivalent til SV1 er Opus. Desværre er der indtil videre kun begrænset understøttelse i enheder for kodekset, og der er betydelig indgroet medie- og understøttelse af IP-belagte kodeks som AAC, AC3, E-AC3 og Dolby 5.1.
Så indtil videre ser min fremtidige mediekodning ud til at blive SV1 og AAC.