Software-update: HandBrake 1.4.0

Versie 1.4.0 van HandBrake is verschenen. Dit opensourceprogramma, dat beschikbaar is voor Windows, Linux en macOS, kan filmmateriaal omzetten naar bestanden met onder meer een h.264-, h265- of mpeg4-beeldindeling en een aac-, ac3-, mp3- of Ogg Vorbis-geluidsindeling. Er zijn presets aanwezig voor veelgebruikte apparatuur, zoals een iPad, AppleTV of Android tablet en er kan ook met zaken als hoofdstukindeling en ondertiteling rekening gehouden worden. Versie 1.4.0 voegt onder meer ondersteuning voor hdr10 en 10- en 12bit-encoding toe, en heeft onder Windows .Net 5.0 nodig. De complete changelog voor deze uitgave kan hieronder worden gevonden.

General

• The HandBrake engine is now 10 and 12bit capable. Please note that not all filters support 10 and 12 bits. Using an 8bit filter will cause the pipeline to run at 8bit. Please see the documentation for more information.
• HDR10 metadata will be passed through from the source file if present.
• Static Previews that are generated during file scans are now stored in compressed jpeg format (previously stored as YUV420). Temporary disk space usage and disk writes are massively reduced. This uses libjpeg-turbo

Filters

• New Filter: Chroma Smooth
• New Filter: Colourspace Selection.
• New Filter: Support for QuickSync hardware accelerated Crop/Scale when using full path.

Hardware Encoding

• New Encoder: Media Foundation
  • For Windows based ARM64 devices powered by Qualcomm Chipsets.
• Updates to the AMD VCN encoder:
  • Quality tuning for VCN's constrained vbr rate control mode. Results are the same or better than cqp mode, and bit rate is much more predictable.
• Included optimised H265 presets for 1080p and 4K content.
• Updates to the Intel QuickSync encoder:
  • Minor performance improvement by skipping VFR and Crop/Scale filters when they are not required.
  • Overhauled memory management including improved zero-copy support where software filters are not used which should also improve performance.

Audio

• MP2 Audio Passthru support.

Subtitles

• New General purpose subtitle decoder
  • Added support for DVB Subtitles (Passthru and Burn-In)
  • Added support for EIA608 Closed Captions.
  • Replaced current decoders for PGS, SRT and SSA with those in ffmpeg. This should correct a number of rendering issues on Burn-In
• Reduced default CC burn-in font-size.

Third-party libraries

• The following 3rd party libraries have changed:
  • ffmpeg 4.4
  • AMF 1.4.18 (AMD VCN encoding)
  • nv-codec-headers 11.0.10.1 (Nvidia NVENC encoding)
  • libmfx 1.34
  • freetype 2.10.4
  • fribidi 1.0.10
  • harfbuzz 2.8.1
  • jansson 2.13.1
  • libass 0.15.1
  • libbluray 1.3.0
  • libdvdnav 6.1.1
  • libdvdread 6.1.1
  • dav1d 0.9.0
  • libvorbis 1.3.7
  • libvpx 1.10.0
  • x264 161 r3043
  • x265 3.5
  • zimg and libjpeg-turbo are new dependencies.

General UI Updates (Applies to Windows, macOS and Linux)

• The "Dimensions" tab has been redesigned.
  • The Rotate and Flip filter has been moved from the filters tab.
  • Added support for padding
  • Added support to control the resolution limit.
  • Added limited support for upscaling

Linux

• Minor usability tweaks and fixes.
• Updated translations (levels of completeness vary)

Mac

• Support for Apple Silicon (macOS only)
• Support for running multiple simultaneous jobs.
• Support eyetv packages with .ts enclosed media file
• Improved UI navigation
  • Added two menu items to quickly switch between titles
  • Improved undo/redo support
  • Drag & drop import/export support in the presets popover
• Preference Updates:
  • Added a preference to control whether the current edited preset should be re-applied when changing title
• Improved Security Scoped Bookmarks management
• Minor improvements and fixes for macOS 11
• Updated Sparkle Updater library.
• Updated translations (levels of completeness vary)

Windows

• Please note, the Windows UI now requires "Microsoft .NET 5 Desktop Runtime"
• Process Isolation
  • When enabled, any encodes that are started are run under a separate "handbrake.worker.exe" process.
  • This protects the main UI from any crashes that could occur whilst processing a file and allows the queue to continue.
  • Multiple jobs can be run simultaneously to improve CPU utilisation on high core count systems.
• Audio Tab
  • Minor improvement to the usability of auto-passthru. To prevent confusion, the "auto-passhtru" audio "encoder" option is now only available on the defaults screen and not the main audio tab.
• Queue Improvements
  • Restored lost "Stop" functionality in the new queue design that landed in 1.3.
• Presets
  • The legacy preset side panel has been removed. The presets button on the toolbar will now offer a "preset manager" and list the available for selection.
  • The inline-preset view from 1.3 is now permanent.
• Installer Improvements
  • Existing NSIS installer: Option to create a shortcut for "all users" as the last step.
• Preference Updates:
  • New Auto Name option: Always use the default path for each new source / title selected
  • "Send File To" Arguments now supports "{source}" and "{destination}" replacement placeholders.
  • Added a preference to configure the "Pause on Low Battery" feature.
  • Check for Updates is now "opt-in" for new installs.
• UI Performance: Optimisations to allow better performance when handling large sets of files (1000+)
• Updated translations (levels of completeness vary)
• Miscellaneous bug fixes and improvements

Versienummer	1.4.0
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, macOS, Windows 8, Windows 10
Website	HandBrake
Download	https://handbrake.fr/downloads.php
Bestandsgrootte	15,51MB
Licentietype	GPL

Reacties (31)

[Radiodurans]

The HandBrake engine is now 10 and 12bit capable. Please note that not all filters support 10 and 12 bits. Using an 8bit filter will cause the pipeline to run at 8bit. Please see the documentation for more information.

Dit is de documentation waar de incompatible filters worden genoemd. Ik zie daar decomb tussen staan voor deinterlace maar Yadif niet. Hoe zou ik kunnen controleren of ik met Yadif deinterlace wel de volledige pipeline in 10bit kan runnen?

[- peter -]

Kijken of resultaat 8 bit is?

[Radiodurans]

Hah, ja, dat resultaat is altijd wel 10bit geweest, ook met handbrake 1.3.3 Ik ga maar even aan de slag met een source met lastige color banding problemen en veel donkere scenes met rook om te zien wat het resultaat is met deze nieuwe versie.

[The Third Man]

Weet jij een manier om dit emperisch vast te stellen voor een 10 bit output? Het probleem is namelijk dat een encode best op 10 bit gedaan kan zijn, maar als de content ondertussen 8 bit is geworden dan zijn die twee extra bits ineffectief voor het eindresultaat geworden. Ik zoek dus eigenlijk een analyzer die het palet kan analyseren of er meer dan 8 bit kleurinformatie in zit.

[Tranquility]

Ik gebruik al een tijdje de Nightly's voor dit doel (HDR10) en op het Handbrake forum wordt gezegd dat de 10-bits pipeline pass through alleen werkt met alle filters uit omdat die nog voor 8-bit zijn ontworpen.

edit:
typo

[Reactie gewijzigd door Tranquility op 24 juli 2024 13:50]

[StartAdress]

't Kostte wat tijd maar hiermee dus wel zo'n 200 Dvd's mee geconverteerd naar een voor Plex behapbaar formaat. Aanrader voor dit soort (en vast vele andere) conversies.

[Tourmaline]

Waarom niet meteen naar een mkv?

[StartAdress]

@Nasizen & @Tourmaline : Naar H264/AAC. Dit omdat Plex dan zonder conversie (veel minder CPU overhead) de film kan serveren.

[Yzord]

Met een simpele handeling kan je H265 serveren zonder de cpu te belasten

x265 video's, waarom eet dit veel resources, what to do?

[mischaatje2]

Met x265 belast je je cpu altijd meer dan met x264 met identieke kenmerken. Dat is nu eenmaal inherent aan het formaat. Het kost ook meer stroom om het af te spelen. Het is een persoonlijke keuze maar ik heb liever x264. Stroomrekening is al hoog genoeg.

Even ontopic:
Handbrake is een heerlijk programma. Het enige waar ik nog wel eens last van heb is die 1px of 2px black border die hij om m'n frames heen zet. Spuuglelijk.

[Reactie gewijzigd door mischaatje2 op 24 juli 2024 13:50]

[supersnellehenk]

Mwah, ligt niet helemaal aan het formaat. Het ligt aan de ondersteuning van de client. Als voorbeeld pak ik Plex, deze heeft de makkelijkste clients. Als je HEVC (x265 is officieel gezien een encoder) afspeelt via de Plex voor Windows app hoeft Plex niks te converteren, dus kost het op de server geen extra CPU kracht. Via Tautulli (Plex monitoring, laat mooi zien wat Plex doet) zul je ook zien dat overal 'Direct Play' staat. @StartAdress speelt de bestanden via de browser af of een Chromecast (gokje), dan is AVC (x264) in een mp4 container inclusief AAC audio het meest ondersteunde.

De link van @Yzord legt uit hoe je op een Synology NAS kunt instellen dat Plex de mogelijkheid heeft om hardwarematig HEVC om te zetten naar AVC dmv Intel QuickSync. Deze chip is hier dan ook voor gemaakt en vergt inderdaad geen tot weinig CPU belasting. Audio/ondertitels willen nog wel eens moeilijk doen, maar dit kost weinig CPU kracht om te converteren.

HEVC in de browser is echt een drama, Nvidia wilt persé licensing fees ontvangen, vandaar de slechte support in browsers. AV1 moet dit als het goed is op gaan lossen, dit is wel open source maar de encoding tijden zijn nog veels te hoog. Decoden in software kost ook de nodige hoeveelheid CPU kracht, de nieuwere generatie CPU & GPUs (Nvidia 3000 series, AMD 6000 series, Intel 11th gen uit m'n hoofd) hebben hiervoor een hardwarematige oplossing waardoor dit praktisch geen CPU kracht vergt, want dit doet een andere chip. Ik weet niet precies welke chips dit zijn voor Intel en AMD, maar voor Nvidia kaarten heb je de NVENC en de NVDEC chips.

Terug naar het gevecht HEVC vs AVC: als jouw clients HEVC ondersteunen, zou ik het persoonlijk converteren. Dit vergt inderdaad wat stroom, maar als je veel AVC bestanden hebt levert dit redelijk wat vrije ruimte op de schijf op. HEVC kan voor dezelfde kwaliteit als AVC een 25-50% lagere bitrate gebruiken. AV1 dan weer zo'n 30% op HEVC, maar hiervan is de ondersteuning nog slecht. Het stroomverbruik kan je verminderen door een hardwarematige encoder te gebruiken zoals een QuickSync, deze converteren een stuk sneller dan CPU, verbruiken minder stroom maar je krijgt minder compressie voor dezelfde kwaliteit.

Ik gebruik persoonlijk een stukje software genaamd Tdarr die het converteren een stuk makkelijker maakt voor grote bibliotheken. Voor mensen met veel bestanden scheelt dit terabytes aan schijfruimte. Op mijn systeem heb ik 3031 bestanden geconverteerd, dit heeft mij zo'n 3,5 TB bespaard.

Edit: reactie van @SadisticPanda erbij gekomen, wil ik ook even op aanhaken. libx265 in ffmpeg schaalt het beste tot 8 threads, daarna daalt inderdaad hoeveel iedere extra thread oplevert. Maar je kunt zeker een CPU volledig belasten met x265. Ik converteer persoonlijk weinig vanaf een ouder formaat naar AVC, maar dit wil je dan ook niet verder converteren om de kwaliteit enigsinds nog te behouden.

Animatie is een vlak opzich qua encoder settings waar ik mijzelf nog niet mee bezig gehouden heb, maar dit zijn zeker niet dezelfde encoder settings als voor een gewone film. Veel encoders hebben hier ook speciale presets voor zover ik weet.

[Reactie gewijzigd door supersnellehenk op 24 juli 2024 13:50]

[SadisticPanda]

Tot, tegenwoordig hebben meeste apparaten ondersteuning voor hevc dus dan valt stroomverbruik wel mee.

Plus op huidige machines .....x265 schaalt slecht op machines met veel Cores.. Op deftige settings is slechts 60 a 70 percent Max belasting maar duurt het encoden wel 4 keer zo lang. Bij x264 wordt CPU maximaal belast voor kortere tijd.

Zou eens moeten kijken hoeveel het effectieve verbruik is op het einde van de streep. Zal wel meer zijn maar of het echt zoooo veel scheelt.

Hangt ook beetje af van content. Voor traint sources verkies ik ook nog altijd x264 om te encoden, voor animatie en gewone film, x265 10bit. Voor uploads wel nog 264 for reasons....

[Radiodurans]

Wat zijn veel cores? Op een Ryzen 3600 met 6 cores encode ik gewoon met 100% op alle 12 threads?

[SadisticPanda]

Vanaf 16 ga je meer en meer idle Cores zien staan. Op 3900x heb je al idle Cores. Op mijn 2950x zeker. Je kan wel gaan klooien met Numa-pools voor alle Cores te belasten maar teveel Cores is dan ook minder 'goed" kan je beter meerdere HB/x265 tegelijk draaien als je dan toch vol wil belasten (sneller voor bulk encodes zoals tv-shows)

[Wildfire]

Je kunt in Handbrake zelf aangeven in welke mate er cropping moet zijn. Mocht Handbrake het verkeerd detecteren dan pas je het zelf aan.

[Yzord]

Heb je uberhaupt wel gekeken naar de link die ik plakte? Sinds ik dat heb gedaan speel ik x265 movies af zonder dat het ook maar enigszins de cpu belast.

[mischaatje2]

Jouw link, ik had 'm gelezen, lost alleen maar een software glitch op. Iets dat er nooit in had mogen zitten. Het doet geen ruk om rekenkracht te bezuinigen. Als het ene programma het met x berekeningen af kan afspelen, dan moet elk programma dat kunnen. Maar je hebt nog steeds x berekeningen nodig om af te spelen; dat is niet veranderd. En die x is bij hevc hoger dan bij x264, ongeacht of je het softwarematig of hardwarematig doet. Dat laatste bepaalt alleen maar WAAR de berekeningen worden gedaan. Nu zal het hardwarematig wat minder stroom kosten, maar datzelfde geldt voor hardwarematige x264 support.

Een auto vergelijking dan maar. Als je elk jaar 50.000 km rijdt dan maakt het veel verschil of je dat doet in een Citroen C5 (1 op 25) of een SUV (1 op 10). Tenminste, als je zelf de benzine moet betalen. Voor de te rijden afstand of de snelheid waarmee je kan rijden maakt het niet uit. Met een zuinige rijtechniek kan je wat besparen maar die besparing is in % gelijk voor beide auto's. De SUV (hevc) BLIJFT echter de slurper.

Edit:
@Wildfire In het verleden wilde Handbrake m'n handmatige aanpassing nog wel eens negeren, of ineens overgaan op een heel andere resolutie of preset. Ik zou het eigenlijk eens moeten proberen met de nieuwe versie. Moet ik eerst de oude laptop van stal halen; m'n huidige desktop en laptop hebben geen dvd drive meer.

[Reactie gewijzigd door mischaatje2 op 24 juli 2024 13:50]

[supersnellehenk]

Zou jij wellicht een bron kunnen plaatsen waarin staat dat HEVC meer stroom kost? Ik heb net even zelf getest met een aantal test bestanden van https://jell.yfish.us/, namelijk de 'jellyfish-250-mbps-4k-uhd-h264.mkv' en 'jellyfish-250-mbps-4k-uhd-hevc-10bit.mkv'. Op een 2080 Super, met dezelfde kloksnelheden van de GPU krijg ik op de AVC variant zo'n 32% belasting op de video decoder, met de HEVC variant valt dat toch wat lager uit op 26-28%. Als ik voor de grap ook eens de 180 mbit versie pak van HEVC (25-50% besparing op bitrate tov AVC) kost het zelfs maar 21-22%.

Ik weet dat dit een kleine sample size is, maar heb geen laptop of iets om op te testen.

Jouw link, ik had 'm gelezen, lost alleen maar een software glitch op. Iets dat er nooit in had mogen zitten. Het doet geen ruk om rekenkracht te bezuinigen. Als het ene programma het met x berekeningen af kan afspelen, dan moet elk programma dat kunnen.

In principe kan ieder programma het ook, zolang deze maar goed ingesteld staat. Het is geen software glitch wat die link oplost, dit is simpelweg de manier waarop je QuickSync 'aanzet' voor Plex op een Synology. Hetzelfde gezeik heb je met Docker en een Nvidia kaart bijvoorbeeld. Zie een VLC op Windows die automatisch gebruik maakt van de hardwarematige oplossing om stroom te besparen.

[Reactie gewijzigd door supersnellehenk op 24 juli 2024 13:50]

[The Third Man]

Ik heb zeer m'n twijfels of je theorie klopt voor een hardwaredecoder, want die is niet zoals een CPU meer cycles actief 'aan het werk'. Het is een dataprocessor met een ingebouwde processing pipeline die ontworpen is voor de maximale specs (zeg 4k 60 fps). Dat betekent dus ook dat hij evenveel cycles draait op H.264 als H.265. Dat er bij H.265 'meer gedaan moet worden' betekent niet dat bij H.264 de chip opeens half uit staat, de chip is volledig aan alleen delen werken niet mee in het decoding proces. Dat is niet iets wat inherent stroom bespaart, want dan moet je die delen effectief van de voedingsspanning loshalen, wat naar mijn weten niet intern bij dataprocessors gebeurt. Vergeet niet dat bij een actieve voedingsspanning een chiponderdeel actief in rust gehouden moet worden om niet door veldeffecten en andere invloeden rare dingen te gaan doen wat problemen kan geven, dus je bent nog steeds electronen er doorheen aan het stromen, zij het niet om data te verwerken. Of een gate altijd op 0 output geeft of wisselt doordat die video mede aan het verwerken is kost evenveel stroom.

Het hele eieren eten waarom een (moderne) CPU koeler wordt als je weinig doet is omdat die een actieve implementatie heeft: de HLT instructie. Daarmee worden delen van de CPU uitgeschakeld wat dus de warmte uit de CPU haalt. Mij is het niet bekend dat er decoders zijn die dergelijke uitschakelingen kunnen verwerken voor codec A terwijl codec B actief verwerkt wordt, omdat grote delen van de chip ten allen tijde gebruikt worden voor het 'data schuiven', het is niet een soort package met losse decoders voor A, B, C enzovoort. Het is 1 enkele decoder die meerdere codecs kan verwerken. Ergo wil je dan stroom besparen dan moet de hele decoder uit, meer is er niet mogelijk.

Een auto vergelijking dan maar. Als je elk jaar 50.000 km rijdt dan maakt het veel verschil of je dat doet in een Citroen C5 (1 op 25) of een SUV (1 op 10). Tenminste, als je zelf de benzine moet betalen. Voor de te rijden afstand of de snelheid waarmee je kan rijden maakt het niet uit. Met een zuinige rijtechniek kan je wat besparen maar die besparing is in % gelijk voor beide auto's. De SUV (hevc) BLIJFT echter de slurper.

Dat is wel een behoorlijk kromme vergelijking. De SUV moet wel meer slurpen omdat hij natuurkundige eigenschappen heeft die het hem onmogelijk maken dezelfde beweging te veroorzaken per liter brandstof. Dat is nog redelijk on point voor een CPU, maar die vlieger gaat niet op voor de hardwaredecoder. Je gooit dus de hardwaredecoder-peer op de hoop met de CPU-appels en past er dezelfde retoriek op toe.

[MrMonkE]

Niet zijn reden maar ik denk ik zeg het even: Omdat je MKV niet in een browser kan afspelen ..

[Nasizen]

Dat was een flinke klus. Naar formaat heb jij de dvds geconverteerd?

[Tranquility]

Heb de Nightly's al een tijdje gebruikt om 4KUHD remuxes met HDR10 te comprimeren en dat gaat uitstekend. Wel enorm langzame conversie met de preset Slow in vergelijking tot x264. Dit duurt echt twee dagen per film met een AMD Ryzen 3700X CPU maar het resultaat is dan ook geweldig. Mooi dat HDR10 nu officieel ondersteunt wordt.

[SvenG]

dat doe je , omdat je Plex bv gebruikt ? en / of hdd ruimte besparing ?

Ik brand ze nog steeds op BR / BDXL

[Tranquility]

Ik gebruik geen Plex maar heb alle films op een Synology NAS staan. De meeste 4K BD remuxes zitten zo rond de 60 'a 70GB. Dat is net te veel bij afspelen via het netwerk. Na veel testen vind ik de sweetspot zo rond de 25 'a 30GB wat ik een mooi formaat vind met behoud van nagenoeg dezelfde beeldkwaliteit. Dat speelt prima af via mijn netwerk en zie ik geen verschil op mijn 65" LG OLED.

[jaaoie17]

Krijg steeds als ik handbrake wil starten deze melding:

to run this application, you must install.net

the framework microsoft.windows.desktop.app version 5.0.0 was not found. Terwijl ik die wel geïnstalleerd heb.

Heb de verkeerde gepakt nu gaat tie wel.

[Reactie gewijzigd door jaaoie17 op 24 juli 2024 13:50]

[andalouse]

Wat heb je juist gedaan om dit te verhelpen? Ik krijg dezelfde foutmelding.

[jaaoie17]

Deze pakken.

https://dotnet.microsoft....0.8-windows-x64-installer

[jumjum]

zelfde probleem hier, wat heb je gekozen?
ik heb de X64 gekozen op een X64 windows 10

[rovabu]

Je moet Microsoft .NET SDK 5.0.205 x64 gebruiken: https://dotnet.microsoft.com/download/dotnet/5.0

[jumjum]

Dankjewel, het werkt nu wel.

[pandit]

Ik ben een fervent gebruiker van Vidcoder, dat Handbrake als engine gebruikt, voor het omzetten van DVD's naar MKV. Nadeel is dat via de CPU dit een langdurig proces is, Voor Blu-ray kost het dagen op mijn IVY\I7 , sinds 2017 wil ik deze taak laten doen door een videokaart Nvidia GTX1060 die ik toen net even te duurt vond. Nu 4 jaar later blijkt deze videokaart niet goedkoper te zijn geworden, maar verdubbeld in prijs.

Ik loop al 43 jaar rond in ICT land en heb prijzen alleen zien zakken na introductie. Misschien is de GTX1060 nu in 2021 niet de beste keus voor deze klus. en zijn er betere&goedkopere alternatieven. Iemand een suggestie. Ik heb nu een GTX 660 Ti , maar is niet geschikt voor video-encoding zover ik begrijp.