Jeg har lige opgraderet min server fra en P2200 til en A2000. Med den indbyggede ffmpeg i MCEbuddy på A2000 encoder jeg med 5,11×. Med v6.0 er jeg mere end dobbelt så hurtig, nemlig 11,9×. Jeg gentager min anmodning om at opdatere ffmpeg i MCEbuddy.
@techpro2004, mens du venter, kan du prøve at kopiere en nyere FFMPEG ind i MCEBuddy’s programmappe kaldet “ffmpeg”. Du skal blot erstatte ffmpeg.exe og ffprobe.exe-filerne fra den nye version.
Jeg bruger “essentials”-buildet af FFMPEG 6.0 til Win10x64 fra Builds - CODEX FFMPEG @ gyan.dev
Hvis du bygger din egen, vil du inkludere dine GPU-biblioteker og statisk linke alt.
Jeg foretrækker at bruge den officielle mcebuddy ffmpeg-build, da den er blevet tjekket grundigt indvendigt og udvendigt.
Goose, opdater venligst igen ffmpeg-build’en i mcebuddy. Og lad os venligst vide, at du arbejder på det.
Tak.
Goose, er du der?
Hej Goose.
Et nærmere kig på Handbrake viser, at de slet ikke bruger FFMPEG til hardware-baseret AV1-kodning. De bruger SVT-AV1 til det.
- Tilføjet SVT-AV1 (software, v1.4.1) og Intel QSV AV1 (hardware) videoenkodere
Så måske er det ikke det rigtige at bede om en opgradering af FFMPEG her. Det kan være grunden til, at Goose tidligere sagde, at “det er kompliceret”.
Hvis du har brug for det med det samme, har du en løsning: erstat med den nye FFMPEG efter eget valg, endda kompileret og optimeret specifikt til din platform, OS, CPU og GPU. (Som du i øvrigt ikke har delt).
Hvis du kan vente (som du sagde tidligere) på, at Goose og MCEBuddy-udviklerne udfører test og regressionstest for alle kombinationer af platforme, operativsystemer, CPU’er og GPU’er, der bruges af alle MCEBuddy-brugere, så vent.
Hvis du har et presserende behov kun for dig selv, kan du altid spørge om pris på en udviklingskontrakt til at lave en brugerdefineret version, kun til dig, efter dine specifikationer og en aftalt tidsplan.
ingen hast, vil bare vide, at de arbejder på det.
sagde også for fem dage siden, hvilken gpu min server bruger, og goose ved, hvad mit andet system bruger fra trådens første indlæg.
Gås??? Nogle ord???
Vi oplever stabilitetsproblemer med Intel-hardware
Jeg oplever stabilitetsproblemer med buildet i mcebuddy nu samt med det nuværende build på nvidia-hardware. Det er ikke ffmpeg-buildet, der forårsager det. Se venligst min anden tråd. Mit gæt (blot et gæt) er, at det har noget med hardware-dekoderen at gøre. Leg venligst lidt rundt med dette. Tak.
Gås, er der en opdatering på dette? Tak.
Lige en sidebemærkning. Hvis man kigger på nVidias GPU-kodnings-/afkodningsunderstøttelse for A2000, er der ingen GPU-understøttelse for AV1.
Kilde: Video Encode and Decode Support Matrix | NVIDIA Developer
Desuden vil MCEBuddy, når det bruger Comskip, benytte den indlejrede FFMPEG, der er linket ind i Comskip-binærfilen. Når MCEBuddy bruger Handbrake til omkodning, vil Handbrake bruge den indlejrede FFMPEG, der er linket ind i Handbrake CLI-binærfilen.
At erstatte med en nyere FFMPEG påvirker derfor kun omkodning, der udføres med FFMPEG. Afhængigt af dine workflow-indstillinger i MCEBuddy kan flere forskellige versioner af FFMPEG blive brugt i de forskellige faser af dit workflow.
Jeg har 2 systemer – ét med et 4080 til encoding og et andet med et A2000 til serving.
Jeg er ikke bekymret for comskip, kun encoding.
Goose, testede du uden hardware-decoding? Tak.
Jeg bemærkede også, at selvom min transcoding er indstillet til at bruge HandBrake, bruger “Fast Remux”-delen af behandlingen ffmpeg, og det bruger ikke hardware-dekodning. Jeg er ikke sikker på, om der findes en måde at tilføje brugerdefinerede kommandolinjeparametre til MCEBuddy, når ffmpeg eller comskip bruges. Selvom man kan angive en brugerdefineret sti til comskip, ser det ikke ud til at være muligt at inkludere kommandolinje-specifikke muligheder fra de nyere donator-versioner (der findes ingen tilsvarende konfigurationsindstillinger – --cuvid skal sendes med på kommandolinjen).
Min transcoding er konfigureret i MCEBuddy til at bruge HandBrakeCLI, og den bruger helt klart nVidia til at transcode til x.265 (et 2060-kort).
Mike808, mcebuddy bruger hardware-dekodning til encode-trinnet i ffmpeg. Tak for at bekræfte, at HandBrake ikke bruger cuvid, og at det virker. Næste skridt kunne være, at du tester ffmpeg-encode med et bredt udvalg af materiale for at bekræfte min teori. Jeg bruger en OTA-antenne, så nogle gange er modtagelsen ikke den bedste. Jeg synes, HandBrake er meget mere tilgivende end ffmpeg. Mit gæt er, at det ikke bruger cuvid. Test det venligst på denne måde.
Goose, nogen melding om at teste det uden cuvid?
Jeg tror, du har misforstået det, jeg har observeret.
MCEBuddy bearbejder medier i cirka 3 trin.
Trin 1 behandles med Comskip. Comskip-udgaven i MCEBuddy er donor-versionen, men når Comskip henviser til HWAssist, betyder det ikke GPU. Det betyder de indbyggede CPU-funktioner (integreret GPU) i Intel-CPU’er og AMD-APU’er med mediekodeks på chippen. Resultatet er, at Comskip ikke bruger din GPU og er CPU-begrænset.
Den nyeste version af Comskip har GPU-dekoder-muligheder, men de er ikke tilgængelige i MCEBuddy lige nu. Jeg har oprettet en feature-request for at tilføje en måde at sende “-cuvid” eller “-vdpau” som ren kommandolinje-parameter. Igen er Comskip stadig CPU-begrænset, selv hvis du bruger en brugerdefineret Comskip og det er den nyeste donor-version.
Trin 2 er demux, hvor video- og lydsporene opdeles, og der bruges dekodning. Her ser det ud til, at MCEBuddy bruger FFMPEG (uanset indstilling af HandBrake til encoding/konvertering), og FFMPEG-versionen har godt nok GPU-encodere, men den har ikke GPU-decodere. Kun den nyeste FFMPEG-version har det, og MCEBuddy påkalder ikke GPU-indstillingen for dekodning, da den ikke ved, om den findes i en fremtidig FFMPEG-version, selv hvis du kopierer den ind.
Trin 3 er videokonverteringen, hvor annonce-klippene (EDL-fil) fra Comskip anvendes på de opdelte video- og lydspor (dekodning igen) og kodes til den kombinerede outputform uden annoncer.
I trin 3 ser dekodningen af sporene ud til at bruge CPU, mens sammenlægning og transcode-del bruger GPU. Det gør trin 3 både CPU- og GPU-begrænset. HandBrake bruger sin internt statisk-linkede FFMPEG og bruger ikke GPU til dekodning, men bruger CPU’ens indbyggede afspilnings- og encode-funktioner i den integrerede GPU på CPU-chippen, hvis tilgængelig, og vil bruge GPU, når den er aktiveret i MCEBuddy. Det samme gælder, hvis du har konfigureret MCEBuddy til at bruge FFMPEG i stedet for HandBrake.
Jeg tror ikke, at FFMPEG-versionen, der er bagt ind i HandBrake CLI (MCEBuddy-versionen, 1.3.3?), har GPU-dekodning, og den nyeste version (1.6.1?) får ikke MCEBuddy til at bruge indstillinger, der ikke findes for den version, den bruger, selv hvis du kopierer den ind. Så denne del af ”videokonvertering” er stadig CPU-begrænset.
Opsummeringsvis er det ret kompliceret, hvornår og om MCEBuddy kan eller vil bruge nyere versioner af disse underprogram-dele af MCEBuddy, og selv hvis den gjorde, skal det gøres flere steder separat i Comskip, FFMPEG og HandBrake CLI. Selv da afhænger alle HandBrake-indstillinger udelukkende af den statisk-linkede FFMPEG indeni, og den er adskilt fra den selvstændige FFMPEG, som MCEBuddy kalder.
Gås, hvad foregår der? har du prøvet det uden hardware-dekodning. Tak.
Må jeg foreslå, at I flytter samtalen til privat besked med Goose.
Når du har et opslag på forummet, er det for at fællesskabet kan forsøge at hjælpe. Det er ikke hjælpsomt at angribe nogen, der forsøger at hjælpe eller forstå, hvad opslaget handler om.
God idé, for din information troede jeg ikke, jeg angreb. Jeg troede, jeg var ret tolerant i lang tid.
Du sagde, og jeg citerer:
“når man bruger ffmpeg, tilføjer mcebuddy automatisk mulighederne for gpu-dekodning”
Jeg har konstateret, at dette simpelthen ikke kan passe. Den version af FFMPEG, der følger med MCEBuddy, kan ikke bruge GPU’en til dekodning, fordi denne evne ikke findes i netop den version af FFMPEG.
Jeg har frivilligt brugt min tid på at undersøge dine påstande og har offentliggjort mine testresultater, fordi jeg selv var interesseret i opdaterede binære filer (emnet for denne tråd), og jeg har fundet, at det, du mener MCEBuddy gør, strider imod, hvad softwaren rent faktisk gør og ikke gør.
Jeg har også påpeget, at de nyere versioner af softwaren faktisk er i stand til at gøre det, du beder MCEBuddy om, men at den nuværende version hverken gør det eller kan gøre det.
Jeg har desuden vist dig og Goose og de andre MCEBuddy-udviklere, hvor der muligvis kan tilføjes mere GPU-acceleration. Ikke alle GPU’er er dog ens, og antallet af dedikerede encode- og decode-enheder kan være afgørende for, hvordan de finindstiller MCEBuddy til brug af den bredest mulige brugergruppe. Eksempelvis har min 2060 kun én encode/decode-pipeline, og det giver fuld mening for transkodning (“video conversion”, som MCEBuddy-status viser), at TS-dekodningen foregår i CPU (med CPU’ens HW-assist), mens encodingen sker parallelt i GPU. Ellers ville det skulle serialiseres som to separate GPU-trin uden paralleliseringsfordele.
Jeg beklager, hvis virkeligheden om, hvordan MCEBuddy faktisk fungerer, er mere kompliceret, end du ønsker, den skal være.
Hvis du ønsker en tilpasset version af MCEBuddy optimeret udelukkende til dit hardware og dine brugsscenarier, bør du måske tage en samtale med MCEBuddy om at finansiere denne skræddersyede udvikling efter dine specifikationer. Selv da er det, du beder om, muligvis ikke tilgængeligt, hvis det ikke findes i de open source-komponenter (FFMPEG og Handbrake) og de proprietære komponenter (donator-versionen af comskip), som MCEBuddy afhænger af.
Måske er MCEBuddy i sidste ende ikke det rette værktøj til dine behov.