Hej alle,
Jeg er lige begyndt at bruge MCEBuddy.
Jeg prøver at konvertere nogle af mine videofiler til x265 for at spare lidt plads.
Nogle af de konverterede videoer har lavere bitrate end originalen og fylder cirka 25 % mindre, mens andre videoer har højere bitrate end originalen og fylder cirka 25 % mere.
Ved nogen, hvorfor det med samme profil giver lavere bitrate for nogle videoer og højere for andre, og/eller hvordan man forhindrer det?
Er de oprindelige opløsninger de samme? x265-koderen arbejder på en glidende skala fra meget tabsfyldt til placebo-tabsfyldt og indstilles ikke rigtigt med en “bitrate”-indstilling.
Jeg gør det samme med OTA-optagelser og har to profiler, én til HD-optagelser og én til SD-optagelser. Til HD-optagelserne kan jeg sætte profilen til at være mere “tabsfyldt” (f.eks. 25 til 27), end jeg kan med SD-optagelserne (20-25).
Hvis jeg laver efterfølgende transkodning, bruger jeg Handbrake med et lignende valg af en brugerdefineret profil. Jeg bruger også en nyeste nightly-build af Handbrake.
Jeg har stadig planer om (en dag) at bruge tid på Custom Cuts eller MCEBuddy-kommandolinjen til at genbehandle filer, der ikke transkoder, men blot “opfrisker” metadataene til serierne, da MCEBuddy indlejrer det hele i MKV-containeren, og jeg har mange serier fra flere år tilbage, hvor metadata ikke var så god, som det er nu med eksplosionen af streaming og alles søgen efter indhold at streame.
Nej, jeg arbejder med SDTV, 720 og 1080.
Måske burde jeg oprette flere profiler og på en eller anden måde filtrere efter opløsning.
Problemet er, at filerne af lavere kvalitet ender med at blive større, mens dem af højere kvalitet ender med at blive mindre. Så hvis jeg indstiller SD-filerne til at være mindre tabsfyldte, som nævnt, ville det gøre problemet endnu værre.
Jeg bemærkede, at Handbrake har en bitrate-indstilling til x265 (ingen idé om, om den er funktionel eller ej).
Hvis det er en parameter, som FFMPEG eller Handbrake kan bruge, kan @Goose måske eksponere den i GUI’en (eller sende den manuelt til transkoder-motoren).
Det ville sandsynligvis være nyttigt at forhindre forøgelse af bitraten på noget kildemedie, men jeg ved ikke, om den eksisterende gennemsnitlige bitrate kan kendes, da det er et gennemsnit, og codec’erne er adaptive.
Det ville være fantastisk, hvis der var en måde at begrænse, at bithastigheden ender højere end kilden.
Hvis det kunne åbnes op i GUI’en, ville det være gavnligt. Det kan måske endda være muligt at gå ind i konfigurationen og tilføje den parameter. Ikke sikker.
Du kunne opsætte to (eller flere) profiler baseret på dine inputmediers bitrater og derefter manuelt vælge den pågældende profil via kommandolinjen (eller kun behandle den pågældende profil, hvis filen ligger i en bestemt mappe, og derefter trække og slippe den ind i den "rigtige" mappe, så MCEBuddy anvender den rigtige profil).
Hvis bitrate var et metadatafelt, som MCEBuddy kan se uden at skulle læse hele filen (dvs. en stor fil) for at beregne den gennemsnitlige bitrate, så kunne jeg godt forestille mig at tilføje bitrate som en variabel pladsholder, der kan bruges i filtrering, profilvalg eller logik til behandling af filnavne.
Jeg ønsker dog ikke at bede @Goose om konstant at tilføje funktioner til MCEBuddy, som bedre håndteres via batch/script og kommandolinjebehandling for disse edge cases. For alt, hvad han tilføjer, skal han også vedligeholde og finde ud af, hvordan det skal integreres i brugergrænsefladen uden at ende med at rode appen til med en masse indstillinger eller skulle dokumentere og supportere enkelte brugere for engangstilpasninger, der er begravet i konfigurationerne. Det er en balancegang.
Jeg forstår det, men det virker som om det ville være til gavn for mange at forhindre større filstørrelser. MCEBuddy kan allerede afgøre filens bitrate, så jeg tænker ikke, det behøver være et metadatafelt eller noget specifikt/anderledes.
Lad mig spørge dig om dette: Jeg har opsat cirka fire forskellige profiler baseret på bithastigheder for delvist at løse problemet. Jeg ved, at der er et bitrate-valgfilter i ekspertindstillingsvinduet.
Mit problem er: Lad os sige, jeg har en fil på 10.000 bitrate, og jeg har et valg for alt over 2.000 og et valg for alt over 6.000. Hordan kan jeg få den kun til at udføre konverteringsopgaven for den over-6.000 kbps-bitrate-opgave i stedet for begge?
Det ville være rart, hvis man kunne angive et interval.
Hvis jeg kan finde ud af, hvordan jeg får den kun til at udføre én konverteringsopgave/profil, kan jeg forsøge at omgå problemet og give en mere konsekvent konvertering uden at nogle filer bliver større end originalen. Det er ikke ideelt, men det kunne virke godt nok.
Tak for hjælpen.
Hvis jeg kan ændre noget i en konfigurationsfil eller lignende, så MCEBuddy ville gøre dette, ville det være fantastisk, men jeg prøvede at undgå at skulle skrive kommandoer manuelt og planlægge en opgave, da det desværre fjerner hele formålet/beovet for MCEBuddy for mig.
Du kan bruge omdøbning og arkivering/sletning efter konvertering til at behandle filerne i faldende bitrate-profil-rækkefølge, dvs. 6K-transcode-profilen først og derefter 2K-transcode-profilen. Hvis 6K-transcode-profilen lykkes, behandles 10K-filen og eksisterer derefter ikke længere, så 2K-transcode-profilen ikke kan udløses.
Tak Mike, det var faktisk det, jeg tænkte på at gøre. Grundlæggende ville jobsene blive oprettet, men kun det første ville blive behandlet.
Det ville fungere helt fint, tror jeg.
Desværre virkede det ikke som tiltænkt. Jeg kan bekræfte, at det flyttede filen til arkivmappen, men på en eller anden måde konverterede den den alligevel to gange med 2 forskellige profiler. Det viser, at den oprindelige fil var den helt samme fil i hændelserne.
Har du begrænset antallet af job, der behandles samtidigt, til kun ét?
Hvis du tillader flere job, vil det starte det første og derefter gå videre til det næste, og du har brug for, at de kører sekventielt.
Der er ingen reel fordel, hvis du bruger HW-transkodning, da de to (eller flere) job vil konkurrere om GPU’en, og det samme gælder for CPU’en, da transkodningen også kan indstilles til brug af flere kerner.
Ja, jeg har det sat til én. Jeg vil verificere og teste igen.
Jeg forstår virkelig ikke, hvordan det næste job fungerede.
Måske har jeg bare uheld, det ved jeg ikke.
Det ser ud til, at programmet venter med at flytte filen, indtil alle konverteringsjobs for den fil er færdige. Det konverterede den tre gange og flyttede den derefter til arkivmappen. Det er det eneste, jeg kan komme i tanke om; ellers burde det ikke kunne konvertere den efter første gang.
Der er også en “vent indtil sidst tilgået”-parameter. Har du skruet den helt ned til nul, eller har du slået “opdater sidst tilgået”-flaget fra i dit filsystem?
Du skal muligvis uploade logfilerne eller din konfiguration til @Goose for at få den undersøgt. Det er et FTP-sted, og vejledningen er slået op her på forummet.
Nej, det gør jeg ikke, men "wait until last accessed" er i øjeblikket sat til ét minut.
Okay, det kan jeg gøre.
Jeg har min forsinkelse sat til 5 minutter. Måske skrue den op, hvis der er en “off-by-one”-fejl et eller andet sted.
Tak igen Mike. Jeg vil prøve med en længere forsinkelse.