Max bredde 720 virker ikke altid

Fejl / Funktionsanmodninger Bugs
1

Jeg kører MCEBuddy 2.7 Beta 7.

Jeg har en konverteringsopgave, hvor jeg konverterer OTA-optagelser til en maksimal bredde på 720p. Det skaber dybest set en optimeret version til Plex.

Konverteringerne foregår, men ikke altid i 720p. Langt størstedelen af tiden er den endelige version stadig 1080p.

Jeg har uploadet en log over en konvertering, der virkede korrekt, og en version, der ikke virkede korrekt. Der står i logfilerne (selv dem, der ikke virker), at den maksimale bredde skulle være 720, men det ender bare ikke sådan.

conversion task

2

Er du ved at forveksle max bredde-parameteren med en max højde-parameter?
720p og 1080p er højdeparametre, ikke breddeparametre.

De er desuden maksimale parametre, ikke tvungen opskalering. Så hvis originalen er mindre end 720 bred, sker der ikke noget.

Eller har @Goose ændret parameteren til at være højde i stedet for bredde og glemt at opdatere teksten i dialogen?

3

Åh ja, det ser ud til, at jeg kludrede i det – MEN jeg forsøger at få MCEBuddy til at lave en 1280×720-version. Så jeg indtastede 720, da jeg i virkeligheden burde have sat 1280 for bredden.

Selv hvis jeg sætter 720, burde det betyde, at den laver en endnu mindre størrelse, end jeg ønskede, ikke?

Jeg går tilbage og retter min maksimale bredde til 1280 og ser, hvad den gør.

4

Jeg kan bekræfte, at breddeværdien virkelig er width.

Jeg havde den forkert sat til 720, og som nævnt virker det nogle gange og andre gange ikke. Jeg fandt ud af, at det konverterede et show korrekt og producerede en video, der var 720x406.

Som Mike nævnte, lavede jeg en fejl, men det ser stadig ud til, at systemet nogle gange ignorerer eller ikke er i stand til at behandle maksimumbreddeværdien korrekt.

5

Jeg kom i tanke om, hvor jeg prøvede at gøre det samme som dig, dvs. tvunget opskalering/nedskalering til en bestemt skærmbredde.

Det er ikke i MCEBuddy. Maksimal bredde bruges til nedskalering af et rå mpeg2 OTA 1920x1080i HD-video til et mindre billede for at opnå bedre kompression. Jeg tror, lagerplads er billigere nu, så det er ikke rigtig et problem længere. Jeg får også god kompression med x265 i stedet for MP4/x264.

Tilbage til tvunget skærmstørrelse. Det var i indstillingerne for Handbrake. Så det du måske kan gøre, er at opsætte ekstra parametre i din konfig og tvinge handbrake til at foretage konverteringerne, eller finde det tilsvarende med FFMPEG (den anden encoder, MCEBuddy bruger).

Jeg ved, at der er nogle indlæg her om folk, der prøver at tvinge FFMPEG eller Handbrake, og nogle andre, hvor de ønskede at sende særlige indstillinger til encoderne. Det tror jeg, du har brug for her.

Jeg serverer også mit indhold med Plex, men jeg har al transcoding slået fra og sender videoen til afspilleren og lader afspilleren klare eventuel transcoding. Indtil videre ingen problemer med afspilning af 1280x720p eller 1920x1080i (OTA) transcodet til maksimal bredde 1280 (det nedskalerer 1920x1080, men det er altid interlaced for mine tv-stationer). Jeg har endnu ingen ATSC3.0-tuner for at se, hvad der er i 4K eller et 4K (UHD)-tv, så ingen problemer der endnu.

Og med x265 og nVidia 2060 HW-kodning på en gammel i5 Haswell (4. gen), har det ikke været et problem at transcode, og et 1-times program fylder cirka 350 MB i „god nok“ kvalitet til OTA HD-indhold.

MCEBuddy flytter originalen til arkivmappen, og jeg planlægger en opgave, der sletter alt ældre end 10 dage. På den måde kan jeg manuelt køre MCEBuddy til at klippe reklamer med en anden profil på alt, jeg vil beholde i fuld opløsning/lav kompression (men selvfølgelig i x265) inden for de 10 dage.

Afspilning fungerer fint på mobil og VLC på pc og endda på min Tivo Roamio OTA via Tivo Plex-app’en.

6

Tak for logfilerne. I den, der fejler, kan jeg se, at videoen er beskadiget, hvilket får HandBrake til at fejle, hvorefter den falder tilbage til ffmpeg, som forsøger at bruge qsv-grafikdriveren til at skalere videoen, men det mislykkes. Kan du også uploade den oprindelige video, der fejler (Late Show), så vi kan analysere den og se, hvordan vi løser det?

7

Vi har udgivet en opdatering til BETA 2.5.7, som burde løse problemet. Prøv dagens 2.5.7 beta-build, og hvis det ikke virker, har vi brug for en kopi af den fejlende video for at analysere den yderligere.

8

OK, jeg har opgraderet til den nye build. Jeg lader den køre og ser, hvad der sker.

9

OK, jeg melder tilbage. Indtil videre går det godt. Den nye build kan korrekt tilpasse størrelsen på videoerne!

Tak.