Nogle skuffende nyheder til MCEBuddy-fans, der bruger den nye Handbrake 1.7.1 i MCEBuddy 2.6.2-betaen.
Det ser ud til, at vi bliver nødt til at opgradere Handbrake til 1.7.2 (GitHub) før snarere end senere – dvs. manuelt erstatte MCEBuddy’s Handbrake CLI-binær (og ‘hb.dll’, fordi den på GitHub ikke er linket ind i hoved-CLI-binæren, som den er i MCEBuddy), hvis du har brug for rettelserne, før de bliver flettet ind i en fremtidig beta.
Jeg har selv oplevet problemet med NVENC og VP9/AV1-kodning, der skaber usædvanligt små filer med urimeligt lange varigheder. Eksempelvis en 2-minutters video, der ser lidt lille ud, men hvor afspilningstiden viser, at AV1-versionen er næsten 2 timer lang. Sådan manifesterer “indsætning af overdrevne keyframes”-buggen sig. Dette udover at (på Windows) den nye NVDEC (GPU-dekodning)-funktion, der lige er blevet tilføjet, ikke bliver brugt.
Fejl rettet i Handbrake 1.7.2 (i forhold til Handbrake 1.7.1, der i øjeblikket følger med MCEBuddy 2.6.2 20231221-beta):
Video
Forbedret automatisk valg af Dolby Vision Level
Rettet et problem i AMD VCN, MPEG-2, MPEG-4, NVIDIA NVENC og VP9-kodere, der kunne føre til oprettelse af overdrevne mængder keyframes (#5530)
Rettet utilsigtet automatisk gennemgang af closed caption-side-data ved brug af NVIDIA NVENC-koder
Diverse fejlrettelser og forbedringer
Linux
Forbedret ydeevne ved fjernelse af dublerede grafikressourcer og reduceret filstørrelse
Rettet Flatpak-filvælger, der åbnede hjemmemappen i stedet for den tidligere valgte mappe
Rettet, at det sidste element i køen nogle gange fik den forkerte destinationssti
Rettet nogle memory leaks i det grafiske interface
Mac
Tilføjet workaround for at forhindre systemnedbrud ved brug af VideoToolbox-kodere med macOS 14 Sonoma på Apple Silicon Ultra
Tilføjet workaround for at undgå problemer med dekodning af H.264-video ved at deaktivere VideoToolbox-hardwaredekodning for Level 6.1 og 6.2
Rettet nedbrud ved åbning af en tom mappe
Windows
Tilføjet Automation Properties til nogle kontrolelementer på lydfanen for at hjælpe skærmlæsere
Rettet, at NVIDIA NVDEC-indstillingen blev ignoreret (#5569)
Rettet opstarts-nedbrud relateret til tema-indlæsning (#5567)
Rettet, at undertekstsprogrækkefølgen ikke blev overholdt (#5590)
Det ser ud til at Goose har været en travl nisse!
Handbrake 1.7.2-udgivelsen findes i 20231225-buildet af MCEBuddy 2.6.2 beta.
Bemærk også at du kun behøver at inkludere “hb.dll” sammen med CLI-binary’en, hvis du bruger Nightly-builds. Den er inkluderet i de primære udgivelsesbuilds.
For at give kontekst til techpro2004s anmodning om at inkludere AC-4-codecs i FFmpeg-binærfilerne (og dem indbygget i HandBrake), som MCEBuddy bruger, er AC-4 navnet på Dolby Atmos-codecen og – vigtigere – en lydcodec, der bruges i ATSC3-udsendelser. Efterhånden som flere bruger ATSC3-tunere sammen med DVR’er, vil vi sandsynligvis se flere MCEBuddy-brugere ende op med bearbejdede videoer uden lyd, fordi FFmpeg ikke kan afkode AC-4-lyden i de oprindelige ATSC3-streams.
Anmodningen er at bruge denne patch midlertidigt, indtil FFmpeg-udviklerne tilføjer understøttelse af AC-4, hvilket sandsynligvis vil ske, men der er ingen tidsplan, og patchen er tilgængelig nu.
Jeg har ikke selv en ATSC3-tuner, men tilføjede dette til dem, der undrer sig.
Der ser ud til at være juridiske problemer med alt relateret til AC4.
FCC godkendte ATSC 3.0 uden et åbent alternativ til AC-4, hvilket tvinger forbrugerne til at købe Dolby-licenseret hardware blot for at høre udsendelser.
“Det er dybt problematisk, at ATSC 3.0 påkræver en proprietær codec (Dolby AC-4) til lyd på gratis over-the-air (OTA) tv i USA og andre regioner, der vedtager standarden. Dette udelukker effektivt open-source-software som FFmpeg, VLC, Plex og Kodi, og forhindrer offentligheden i fuldt ud at få adgang til udsendelser, der burde være gratis.”
Plex-teamet har allerede sagt, at de ikke vil understøtte AC4-lyd, så vidt jeg husker. Så der vil ikke være nogen mulighed for at understøtte noget med AC4-lyd i Plex, hverken DVR eller blot filer med AC4-lyd.
Kernen i problemet er, at de kommercielle aktører bag ATSC3 vil tilbagekalde licenser og sagsøge enhver, der laver en form for “transcoder” fra AC4 til noget andet, da det “omgår” deres forsætlige indholdsextortion-skema bakket op af DMCA og patentbelagte standarder, der er påkrævet til offentlig brug. Så vi vil ikke se transkodning indbygget i DVR-enheder som HDHR eller Tablo, ej heller noget nedstrøms fra en DVR-enhed (som MCE Buddy).
(se Setting the Record Straight on Dolby AC-4 and MPEG-H | SIGNAL )
Jeg ved, at det ikke er det svar, vi ønsker at høre, men jeg er ikke sikker på, at jeg ønsker, at MCE Buddy skal blive et mål for tv-mediernes dyre advokater, der leder efter at retfærdiggøre deres honorarer og gøre et eksempel i bestræbelsen på at privatisere og udbytte profit fra det, der engang var en offentlig ressource.
@mike808 silicondust tilbyder en cloud-transkodningstjeneste til ac4 for klientenheder, der ikke understøtter det, og som bruger deres app. Desuden er ffmpeg-binærfilerne med ac4-understøttelse, som jeg har postet ovenfor, kompileret fra open source-kode tilgængelig på github. Hvis de vil gå efter nogen, ville det give mening for dem at gå efter det tredjeparts ffmpeg github-repo. Det er et velkendt repo med links til det overalt på internettet. Desuden har det repo været oppe i mange år med regelmæssige opdateringer, og ingen har gjort noget ved det endnu. Så hvis de ville gå efter nogen, ville de have gjort det nu. Jeg er fuldstændig overbevist om, at mcebuddy er sikker med ac4-understøttelse, og at der ikke vil ske retsforfølgelse (men det er bare min mening).
