Jeg bruger et GTX 1650 og har… forsøgt at få det til at virke igen. Det fungerede fint for cirka 3 måneder siden, tilbage i september med MCEBuddy Build Version 2.5.1 fra 5/9/2019 – jeg ville elske at beholde den version, da det var den hurtigste udgave af MCEBuddy; selv med de nye versioner var den cirka dobbelt så hurtig (for mig, jeg ved ikke hvorfor). Nu får jeg ADVARSLER og FEJL, men konverteringstiden er cirka 6 minutter med den nye MCEBuddy 2.5.3 fra 24/12/2019, mod cirka 2 minutter med 2.5.1 fra 5/9/2019… Beklager, jeg har ikke loggene fra dengang, kun de nye. Jeg har forsøgt at genskabe alt fra dengang – fra de samme drivere til at bruge DDU igen og igen, til forskellige FFmpeg-versioner og til at eksperimentere med forskellige profiler.
Dette er det eneste, jeg stadig har tilbage fra september; jeg tror, den brugte cirka 70 % af CPU-en
Dine logs viser, at MCEBuddy registrerer din nvenc encoder, men ffmpeg kan ikke bruge den:
2019-12-30T21:56:20 MCEBuddy.AppWrapper.FFmpeg → [h264_nvenc @ 00000000028e5d40] No NVENC capable devices found
Handbrake kan dog bruge den med en anstændig konverteringshastighed på cirka 98 fps.
Det lyder som om din grafikdriver muligvis er blevet ændret og forårsager problemer for ffmpeg. Prøv at skifte til en mere stabil driverversion eller rul den tilbage.
Angående GPU-anvendelse se dette emne for flere detaljer.
Jeg har brug for hjælp til at konvertere videoer fra high 10 ned til 8 bit
dette er hvad jeg bruger
[MP4 Fast]
Description=Fast MP4 (H.264/AAC)
order=ffmpeg,handbrake
ffmpeg-general=-threads 0 -hwaccel auto
ffmpeg-video=-ss 0 -vcodec libx264 -b 1000k -x264opts cabac=0:ref=2:bframes=1:weightp=0:8x8dct=0:trellis=0:subq=6:me=hex:b-adapt=0:threads=auto -map 0:v -sn
ffmpeg-audio=-acodec aac -ab 128k -map 0:a
ffmpeg-audioac3=-acodec aac -ab 160k -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
handbrake-general=–loose-anamorphic --verbose=2 -f mp4 -O
handbrake-video=–start-at duration:0 -e x264 -b 1000 -x cabac=0:ref=2:bframes=1:weightp=0:8x8dct=0:trellis=0:subq=6:me=hex:b-adapt=0:threads=auto
handbrake-audio=-E faac -R auto -B 128 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E faac -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-ext=.mp4
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=false
Plex skal i øjeblikket transcode alt med high 10
Den slags er over mit niveau; al hjælp modtages med kyshånd
Transkoderer Plex ikke baseret på afspilningsenhedens kapacitet? Måske skulle du starte med at finde ud af, hvilket format afspilningsenheden understøtter, og derefter vælge en profil, der matcher.
hvordan får jeg mine videoer fra high 10 ned til 8 bit? ffmpeg-video=-ss 0 -vcodec libx264 -b 1000k -x264opts cabac=0:ref=2:bframes=1:weightp=0:8x8dct=0:trellis=0:subq=6:me=hex:b-adapt=0:threads=auto -map 0:v -sn
jeg forstår ikke hvad nogen af det betyder
Jeg er ikke bekendt med ffmpeg-indstillingerne, men de er dokumenteret på ffmpeg.org-siden.
Hvis du brugte Handbrake, findes der separate encodere til 10 og 12 bit. F.eks. er “x264” 8-bit encoderen, og “x264_10bit” er 10-bit encoderen. Så ud fra indstillingerne i din profil kan du se, om du nedkonverterer til 8-bit.
Jeg ville ikke blive overrasket, hvis ffmpeg-encoderindstillingerne vælges på lignende vis. Hvis du vil være sikker, konfigurer da prioriteten for transkodningsmotoren til at bruge Handbrake med 8-bit encoderen i profilen og brug ikke FFMPEG.
x264 understøtter 8- til 10-bit farverum. Den præcise bitdybde styres ved x264’s konfigurationstidspunkt. FFmpeg understøtter kun én bitdybde i én bestemt build. Med andre ord er det ikke muligt at bygge én FFmpeg med flere versioner af x264 med forskellige bitdybder.
Så det rigtige svar er: hvem/hvor fik du din libx264-codecbibliotek fra, og hvilke indstillinger konfigurerede de, da det blev kompileret.
Pengene er på, at alle kompilerer libx264 med et 8-bit farverum. Du ville også skulle have den samme farverumsunderstøttelse i afspilningsprogrammet/enheden – f.eks. VLC, Plex osv.
Goose kan sandsynligvis svare på, hvordan libx264 blev bygget til FFMPEG, og MCEBuddy FFMPEG siger blot, at den standard/medfølgende libx264 blev brugt.
