Software-update: OBS Studio 29.0.0

Versie 29.0.0 van OBS Studio is uitgekomen. Open Broadcaster Software Studio is opensource- en crossplatformsoftware bedoeld voor het opnemen en streamen van videobeelden van een of meer bronnen, zoals een webcam, microfoon, mediabestanden en de desktop. In versie 29 is onder meer ondersteuning voor Intels hevc-encoder onder Windows en macOS toegevoegd. De complete changelog voor deze uitgave is hieronder te vinden:

Features

• Added support for the AMD AV1 Encoder for the RX7000 series GPUs on Windows
• Added support for the Intel AV1 Encoder for Arc GPUs on Windows
  • Note: CQP is available but not fully supported
• Added support for the Intel HEVC Encoder on Windows
• Added an upward compressor filter
• Added a 3-band equalizer filter
• Added support for native HEVC and ProRes encoders on macOS, including P010 and HDR
• Added support for macOS Desk View
• Added update channels for opting into receiving beta/release-candidate builds to Windows
  • Work is still underway to get everything ready on the server side, updating via the built-in updater may not be available until later in the OBS 30.0 beta-testing period
• Websockets updated to 5.1.0, which has a number of bug fixes, UI improvements, and new stream reconnect events.

Tweaks and Improvements

• The Replay Buffer's memory limit is now set to 75% of installed system RAM rather than fixed to 8GB
• Added media key support in Linux
• Various improvements to NVIDIA Video and Audio filters, including a Mask Refresh slider and support for temporal processing, which provides better quality masking
• Improved Display Capture screen naming & saving on Windows; indexes should now match regardless of Mode, and reconnected displays should show the correct monitor
  • Note: This does mean existing Display Capture sources will be blank until manually configured, to avoid showing the wrong display
• Added support for encryption and authentication for SRT and RIST outputs
• Disabled ScreenCaptureKit Display & App capture on macOS 12 due to various issues; users should either update to macOS 13 or use the existing Screen Capture source
• Removed the automatic numbering on Multiview labels
• Added the ability to mute individual browser docks
• Added the ability to right click and 'Inspect' individual browser docks
• Changed the default Simple Output NVENC preset to P5 for better compatibility & performance
• Added support for higher refresh rates in the Video Capture Device source on Windows
• Added the Apple VT Hardware encoder to the Auto Configuration Wizard
• Improved FFmpeg VA-API enablement by directly using Libva to check device capabilities
• Various minor UX/accessibility tweaks in the UI
• Raised the speed at which dynamic bitrate recovers after a drop
• Audio should now be automatically captured for most capture card brands using the Video Capture Device source on Windows
• Added a slide counter to the Source Toolbar when an Image Slide Show is selected

Bug Fixes

• Fixed issues with async filters (such as Delay) not rendering correctly
• Various performance improvements to Decklink preview output
• Fixed an issue where source Projector windows wouldn't close when a source was deleted
• Fixed an issue where cursors would disappear or display incorrectly on screen captures on Windows
• Fixed issues with CQP rate control for SVT and AOM AV1 encoders
• Fixed an issue with CQP rate control for AMD HEVC and b64
• Fixed Virtual Camera not working with Webex and GoToMeeting
• Fixed capturing UHD/4K YUV on the AJA Kona HDMI
• Fixed a bug where slideshow sources wouldn't remove cleared files when removing missing files
• Fixed slideshow counter on the source context toolbar showing "1/0" when empty, now shows "-/-" instead
• Fixed chroma location for VAAPI
• Fixed a case where macOS' VideoToolBox HEVC encoder would be parsed as AVC
• Allow SRT streams to disconnect after timeout
• Fixed color space being incorrect for some video devices running in MJPEG video format on Windows
• Fixed monitor names in the Fullscreen Projector & Multiview menus on Windows

Versienummer	29.0.0
Releasestatus	Final
Besturingssystemen	Linux, macOS, Windows 10, Windows 11
Website	OBS Studio
Download	https://github.com/obsproject/obs-studio/releases/tag/29.0.0
Licentietype	GPL

Reacties (13)

Weet iemand of het plugin probleem inmiddels opgelost is?
Bij de introductie van de vorige versie bleken veel plugins niet goed meer te werken

Info daarover op de officiele knowledge base
https://obsproject.com/kb/obs-studio-28-plugin-compatibility

TL;DR -> Alle belangrijke plugins zijn overgezet, enkele kleine zijn in progress.

[Reactie gewijzigd door 33Fraise33 op 8 januari 2023 21:03]

OBS is toch wel een monster goed programma voor streams.
alleen mogen ze van mij betreft een nieuwe features pauze in lassen en een tijdje bug fixes doen.
zie veel streams die toch wel 1 of ander probleem met het programma hebben.

het is een open source community project, wat wil zeggen dat iedereen kan werken aan wat hij wil

Dat is wel een versimpeling van hoe open source projecten werken. Het is namelijk niet zo dat alles waar mensen aan werken zonder meer wordt gemerged in de hoofd code. Het is ook niet zo dat er altijd puur willekeurig aan features of zaken wordt gewerkt.

Een open source project heeft nog altijd eigenaren, de groep mensen die de repository beheren en die de bevoegheid hebben om zogenaamde pull requests na reviewen te mergen. Daaromheen heb je dan vaak nog een kerngroep aan mensen die vaker bijdraagt, maar niet dezelfde rechten heeft om code te mergen.

Wat je dan ook vaak ziet is dat de kern groep vaak wel nadenkt over een richting of volgende grote stappen (al dan niet met inspraak van de grotere community) en dit ook documenteert. Naar github kijkende heb je dan vaak een de lijst met alle "issues" die dan vervolgens worden voorzien van labels en aan milestones gehangen.

De kerngroep en mensen die vaker bijdragen zullen zich vaak dan ook focussen op deze zaken en misschien algemene bugs die gerapporteerd worden. Op het moment dat iemand een pull request opent voor iets waar geen issue voor is (dus niet van te voren besproken) zal er naar diverse zaken worden gekeken:

• Is het een feature die men überhaupt wil opnemen.
• Als dat zo is, wordt de feature geïmplementeerd op een manier die past binnen het programma (UI, etc).
• Is de kwaliteit van de code goed genoeg en volgt het de standaarden die door het project worden voorgeschreven.

Afhankelijk van bovenstaande zaken kan de bijdrage in zijn geheel worden afgewezen en in sommige gevallen zal er gevraagd worden om aanpassingen. Je kan dan ook zien dat heel veel pull requests lang open blijven staan of nooit worden opgenomen in het project.

Natuurlijk kan het zijn dat zaken soms blijven liggen want het merendeel van de betrokken personen draagt code bij in hun vrije tijd. Maar er is wel degelijk sprake van coördinatie, planning en prioriteren waar mogelijk.
Samenvatting: Open source betekent niet dat de code pure willekeur is en alles, maar wordt opgenomen.

uiteraard is het een simpele voorstelling. Ik probeerde het bewust niet te ingewikkeld te formuleren zonder dieper in te gaan op hoe (open source) projecten werken, want ik denk niet dat hij daar zo hard in geïnteresseerd is gezien z'n statement dat er niet aan features gewerkt mag worden als er nog bugs open staan.

Het is geen bedrijf met een hiërarchie die kan opleggen wie wat MOET doen, want alle bijdragen zijn vrijwillig gedaan. Ben je het niet eens, dan kan je gewoon je eigen versie maken (een zogenaamde fork) door de bestaande code te nemen, je aanpassingen te doen en/of stukjes code die anderen hebben voorgesteld (zogenaamde pull requests) en heel de boel zelf te compilen tot een nieuw programma.

want ik denk niet dat hij daar zo hard in geïnteresseerd is gezien z'n statement dat er niet aan features gewerkt mag worden als er nog bugs open staan.

Behalve dan dat dit in iets andere vorm regelmatig gebeurt in de open source wereld. Zoals ik al eerder aangaf kan men besluiten pull requests niet te mergen of er nog mee te wachten. Het is niet ongewoon voor open source projecten om voor een milestone te besluiten alleen maar pull requests te mergen die bijdragen aan de stabiliteit. Op dat moment zullen pull requests aangaande nieuwe features even geparkeerd worden en pas later gemerged.

Ja, mensen kunnen software forken. In de praktijk gebeurt dat relatief weinig omdat succesvol forken inhoud dat je de gehele organisatie ook moet opzetten en onderhouden.

crunchen gebeurt idd regelmatig, maar op momenten dat het nodig is en het is vaak een onderdeel van het werkproces. Zonder inhoudelijke kennis of betrokkenheid zomaar wat zeggen getuigd niet van veel inzicht in hoe projecten lopen. Een defecte klok geeft 2x per dag het juiste uur weer

Nee, ik heb het niet over crunchen. Ik heb het over releases die puur focussen op onderhoud. Waar ik puur mee wil aangeven dat het niet ongehoord is om te doen waar raro007 aan refereerde.

Waar de rest van je reactie over gaat, ontgaat me even. Als het naar mij verwijst, vind ik het namelijk nog al ironisch als je er iets anders mee bedoelt, mis ik daar even de context.

Het getuigd eerder aan gebrek van inzicht aan uw kant. Crunchen is giga veel overwerken om een deadline te halen en nee dat hoeft niet eens specifiek het oplossen van bugs te zijn. Crunchen is ook echt geen onderdeel van het werk process maar is een bij product van onrealistische deadlines te stellen en te handhaven. Vaak opgelegd door managers die geen idee hebben wat er moet gebeuren.

Als jij daadwerkelijk geloofd dat crunchen een onderdeel van het werkproces is ben jij een deel van het probleem en niet van de oplossing.

ja jij snapt het en wat ik dus bedoel is wat nu wine doet: download: Wine 8.0 RC2
What's new in this release:
Bug fixes only, we are in code freeze

jij snapt het maar waarom hij het niet snapt snap ik weer niet...

Inderdaad, als de bugs mensen in de weg zitten kunnen ze dit oplossen (of door zelf de code in te duiken, of door geld te doneren om dit specifieke probleem op te lossen of door een groot deel van de community over te halen). Als bugs heel klein zijn en nagenoeg komt het tegen dan ligt de prioriteit bij de mensen die het onderhouden ook niet heel hoog. Ze zullen die bug meepakken als ze toevallig rondom die bug iets anders oppakken.

Tja, dat is een zwak punt waar veel ontwikkelaars zich in zullen herkennen. Het is natuurlijk veel leuker om (in je vrije tijd) te werken aan nieuwe, toffe features, dan de fouten van een ander oplossen. Dat gezegd hebbende, als het echt nodig is, zal het vast wel prioriteit krijgen.