Flashvideo krijgt hardware-ondersteuning in Mac OS X

Apple en Adobe hebben hun geschillen omtrent Flash opzijgezet en hebben samengewerkt om flashvideo hardwarematig te decoderen. Apple heeft Adobe daartoe directe toegang gegeven tot de hardware van enkele veelgebruikte gpu's.

De samenwerking tussen Adobe Labs en Apple-ontwikkelaars heeft geresulteerd in Gala, een flashspeler voor Mac OS X 10.6.3. De flashspeler bevindt zich nog in een preview-stadium en Gala is de codenaam van het project. Op termijn moet Gala-functionaliteit zijn weg vinden naar Flash Player 10.1 voor de Mac, dat later dit kwartaal moet verschijnen. Wanneer flashvideo in de preview-versie hardwarematig via de gpu wordt gedecodeerd, wordt dit kenbaar gemaakt door een wit vierkantje in een hoek van het beeld te tonen.

De hardwarematig versnelde decodering van flashvideo werkt alleen met h264-gecodeerde video. Ook moet de OS X-versie 10.6.3 zijn en worden slechts drie gpu's ondersteund: de GeForce 9400M, de GeForce 320M en de GT330M. De drie gpu's van Nvidia verzorgen echter wel de video voor het gros van courante Apple-hardware. Met de gpu-decodering van flashvideo moet de processor worden ontlast, wat moet leiden tot minder energieverbruik en een soepelere weergave van video in de browser.

Reacties (109)

[arjankoole]

Opzich is het artikel niet helemaal correct, aangezien Apple de documentatie voor de benodigde API's publiek heeft gemaakt.

Dat sluit natuurlijk niet uit dat ze niet hebben samengewerkt.

[Maurits van Baerle]

Inderdaad, Apple heeft afgelopen maart de 10.6.3 update uitgebracht waar onder meer een nieuwe API in zit om direct de h.264 hardware decoders aan te spreken.

Iedereen kan daar gebruik van maken en dus ook Adobe. Het is waarschijnlijk een kwestie van tijd voor bijvoorbeeld Chrome of VLC ook met updates uitkomen die er gebruik van maken. Ik heb niet de indruk dat dit specifiek iets met Adobe te maken heeft.

Overigens betwijfel ik ook of dit Flash eindelijk minder zal laten crashen. Het zou hoogstens kunnen betekenen dat je ook Flash videos kan bekijken met minder dan 8 CPU cores.

[84hannes]

Als het zo "simpel" is, is zoiets dan ook te verwachtwen onder Linux? Als de Open Source Community vergelijkbare API's ontwikkeld kan Flash for MacOS X misschien (door de lui van Adobe) naar Linux geport worden.

@RM-rf
Het gaat me er ook niet omdat de OS-community dezelfde softwarelaag schrijft, het gaat me er om dat ze vergelijkbare API calls maken. Dat maakt het voor Adobe makkelijker om het te porten. Adobe houdt namelijk niet zo van goede code voor UNIX schrijven, dus als ze het maar een keer hoeven te doen scheelt dat wellicht.

[Reactie gewijzigd door 84hannes op 23 juli 2024 16:00]

[RM-rf]

de API is bekend, dat betekent niet dat de achterliggende techniek 'open' is of mogelijk ook door patenten beschermd wordt.
eveneens is het goed mogelijk dat het zeer specifiek ontwikkeld is om optimaal gebruik te maken van de hardware die apple zelf toepast (in de documentatie zelf staat al direkt dat het toepasbaar is op modellen die uitgerust zijn met drie specifieke grafische kaarten: de NVIDIA GeForce 9400M, GeForce 320M en/of de GeForce GT 330M)

[Dreamvoid]

Dat doet de OS community al, VDPAU heet dat.

[mddd]

Inderdaad. Het artikel beschrijft het alsof het een 1-2-tje is tussen Apple en Adobe. In werkelijkheid is het zo dat deze hardware accelleratie nu voor alle ontwikkelaars ter beschikking is.

Omdat Flash toch nog steeds een belangrijk deel van het video-gebeuren voor zijn rekening neemt, is het wel logisch dat ze in de testperiode al met Adobe hebben overlegd zodat ze zeker weten dat het met Flash player in elk geval goed samenwerkt.

[johnbetonschaar]

Hardware acceleratie was al veel langer beschikbaar, alleen niet op de manier waarop Adobe het graag had gezien. Uit mijn hoofd kan ik al zo al 3 manieren verzinnen waarop Adobe zijn Flash video al hardware versneld had kunnen decoden: OpenCL (sinds 10.6 beschikbaar), GLSL, en via de QuickTime API's.

Blijft een beetje vreemd dat Adobe doet alsof ze nu pas GPU acceleratie kunnen gebruiken voor Flash terwijl er 1001 programma's op OS X zijn die dat allang doen.

[ppl]

Dat OpenCL is een vreemde eend in de bijt omdat niets met hardwarematige video acceleratie te makenb heeft maar in theorie wel voor enige acceleratie kan zorgen. Het is voor algemene computing zaken, het is puur en alleen een rekenkundig iets. OpenCL maakt hiervoor gebruik van de cpu en de gpgpu (wat maar 1 onderdeel is van wat wij kennen als "de videokaart"; het is dus nietde videokaart zelf!). Het huidige probleem met Flash is de rekenkundige kracht die je nodig hebt en die zul je met OpenCL nog steeds hebben. Het enige voordeel is dat bij hoge load je nu de cpu en de gpgpu aan het werk kunt zetten. Als je computer weinig staat te doen is je voordeel dus eigenlijk 0,0. Het is nog maar de vraag of je met OpenCL acceleratie hebt. Je moet OpenCL dan ook zien als een lokale Xgrid waarbij de cpu en gpgpu onderdeel zijn van het rekencluster. Als je rekenkundigheid mee wilt nemen in je verhaal zou je Xgrid er ook eigenlijk bij moeten vermelden.

Het idee van deze video acceleratie door de videokaart is het verminderen van de benodigde rekenkundige kracht door de cpu (of gpgpu in geval van iets als OpenCL). Deze acceleratie is iets wat je juist wel merkt ongeacht of je machine nou druk is of niet.

Ander aardig detail is het feit dat eind maart Apple het betreffende support artikel over deze api voor de hardwarematige video acceleratie online heeft gezet aldus de datum van het artikel. Er is dus zeker sprake van stemmingmakerij in het Apple-Adobe Flash oorlogje. De vraag is alleen of het Apple is die antidatering heeft toegepast zodat het lijkt dat het artikel voor Adobe's kritiek is verschenen of Adobe heeft onterecht lopen schreeuwen omdat ze dat artikel niet hebben gezien. Het is wel tekenend voor dit hele gedoe rondom Flash.

Edit: wegvallende zin weggehaald.

[Reactie gewijzigd door ppl op 23 juli 2024 16:00]

[johnbetonschaar]

Uhm, OpenCL is een implementatie taal voor onder andere GPGPU toepassingen, dus wel degelijk geschikt om GPU acceleratie in je video decoder te bouwen. Dat er ook backends zijn die op je CPU draaien, of op de SPE's van een Cell of wat dan ook doet hier niet direct ter zake: Apple levert een OpenCL implementatie bij OS X die gebruik kan maken van de GPU en daar ging het om. Je zou het eigenlijk kunnen zien als een veel flexibelere en veel handigere manier om zware rekentaken op verschillende soorten hardware uit te voeren dan met bijvoorbeeld GLSL, Cuda, etc. Je opmerking over 'de gpgpu' volg ik niet helemaal, het woordje GPGPU gaat helemaal niet over hardware maar staat voor het idee 'general purpose' berekeningen uit te voeren op 'de GPU'. Je bent dus wel degelijk de hardware van je GPU aan het gebruiken voor andere dingen dan 3D rendering, precies dezelfde hardware (stream processors) die ook gebruikt worden voor shaders wanneer je de GPU voor 'normale' rendering taken gebruikt.

Overigens was mijn punt dat Adobe altijd naar Apple heeft gewezen omdat die ze de video acceleratie niet in hapklare brokken aan Adobe heeft aangeleverd, waarschijnlijk omdat de API's daarvoor pas sinds kort afgerond en beschikbaar zijn. Maar dat neemt niet weg dat er nog steeds voldoende andere mogelijkheden waren om het op een andere manier te doen, misschien met iets meer moeite maar je mag toch van een bedrijf als Adobe verwachten dat ze dat wel voor elkaar krijgen.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 16:00]

[ppl]

Uhm, OpenCL is een implementatie taal voor onder andere GPGPU toepassingen, dus wel degelijk geschikt om GPU acceleratie in je video decoder te bouwen.

Op de een of andere rare manier blijven mensen geheel ten onrechte denken dat OpenCL iets met de videokaart mogelijkheden kan doen. Dat is absoluut onjuist, het heeft helemaal niets met de videokaart te maken omdat het alleen maar om pure rekenkracht gaat. De videokaart moet je zien als 2e computer binnen je computer waarbij de GPGPU de CPU moet voorstellen. Zowel de GPGPU als de CPU doen in dit verhaal alleen maar berekeningen, niets meer en niets minder. De GPGPU is daarin alleen beter dan de CPU vanwege de parallelle manier van dingen afhandelen. Dat heeft men op het idee gebracht om de GPGPU ook voor algemene berekeningen te gebruiken wat weer tot technieken als CUDA en het wat uniformere OpenCL geleidt. Het is dus exact hetzelfde als wat men bij CUDA poogt te doen, alleen werkt het ook op niet-Nvidia hardware. Zo staat het ook omschreven in de OpenCL Brief van Apple (zie vooral ook de conclusion).

Het is nog altijd rekenkracht dat nodig is en dat is wat anders dan video acceleratie van de videokaart.

Je opmerking over 'de gpgpu' volg ik niet helemaal, het woordje GPGPU gaat helemaal niet over hardware maar staat voor het idee 'general purpose' berekeningen uit te voeren op 'de GPU'.

Juist wel want niet alle GPU's kunnen general purpose berekeningen uitvoeren. Degenen die dat wel kunnen worden daarom ook als zodanig aangeduid (dus GPGPU). Kijk maar eens bij Nvidia hardware, niet al hun GPU's zijn er geschikt voor. Ik doelde er eigenlijk op dat niet de gehele videokaart wordt gebruikt, alleen het gedeelte wat de berekeningen kan uitvoeren (zie ook uitleg hier boven).

Maar dat neemt niet weg dat er nog steeds voldoende andere mogelijkheden waren om het op een andere manier te doen, misschien met iets meer moeite maar je mag toch van een bedrijf als Adobe verwachten dat ze dat wel voor elkaar krijgen.

Daar ben ik het ook helemaal mee eens maar ik denk niet dat iets als OpenCL daar de meest handige optie voor is, juist omdat het niet altijd een toegevoegde waarde heeft.

[Dreamvoid]

Open CL is general purpose via de shaders, maar die nVidia gpu's hebben dedicated video decoders aan boord waar Open CL ook niet bij kan. GLSL is ook shader-based. Via de Quicktime API's had je tot voor kort geen toegang tot de video decoders.

Zie Open CL als tegenhanger van CUDA, en deze nieuwe API als tegenhanger van DXVA2.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 16:00]

[WoBaDijk]

Een positieve ontwikkeling vind ik. Er zijn nog erg veel websites die Flash gebruiken en het is daarom erg prettig om als Apple gebruiker deze website goed te kunnen bekijken. Zelfs als Flash al uitgefaseerd wordt zijn er op het moment nog dermate veel websites met Flash dat het fijn is dat hier nog een goede ondersteuning voor wordt geboden.

[mddd]

Even voor de duidelijkheid, het gaat niet om hardware ondersteuning voor Flash. Het gaat om hardware ondersteuning voor het afspelen van H.264 video. Een Flash site die video afspeelt zal dus minder cpu-belasting geven, maar Flash in het algemeen wordt er niet beter of efficiënter door.

[_beevee_]

natuurlijk wel, Flash maakt een composiet van video en overlays / geanimeerde bitmaps.

Bovendien zitten er nog meer optimalisaties in 10.1

[rdwagenaar]

leuk en aardig, maar over een paar jaar bestaat flash denk ik niet eens meer...

html5 is al in opmars en biedt dezelfde, zo niet meer, mogelijkheden zonder alle nadelen van flash

[Relief2009]

html5 biedt helemaal niet dezelfde mogelijkheden. Ik zie niemand met html5 een flashachtige website maken.

[TDeK]

Wat demo's:
http://www.craftymind.com...ml5video/CanvasVideo.html
http://people.mozilla.com/~vladimir/demos/photos.svg
http://9elements.com/io/projects/html5/canvas/

Wat websites:
http://www.radio1.nl/ --> audioplayer is HTML5 in Safari en Chrome
http://www.apple.com/ipad/ready-for-ipad/ --> bieden html5 content aan voor de iPad
Youtube werd hierboven al aangehaald.

En dit is nog maar het begin

[Reactie gewijzigd door TDeK op 23 juli 2024 16:00]

[seppevs]

Nu misschien nog niet, omdat het nog in draft status is. Maar HTML5 biedt zeker wel dezelfde mogelijkheden als Flash. Alleen moet je bij HTML5 op dit moment nog veel meer low level werken (bv met de Canvas tag) terwijl je in Flash hetzelfde veel makkelijker kan doen mbv prefab modules. Maar ik ben er zeker dat er mooie libraries aan gaan komen die HTML5 een échte flash killer zullen maken!

[Reactie gewijzigd door seppevs op 23 juli 2024 16:00]

[_beevee_]

Nou ik ben zeer bekend met beide en ik kan je verzekeren dat is *helaas* bij lange na níet het geval! Natuurlijk kunnen we straks met HTML5 veel meer dan tot nu toe maar het blijft maar een fractie van wat met Flash kan, bovendien zal Flash veel sneller vernieuwen dan de HTML standaard. Het 'open' standaardisatie proces duurt helaas een eeuwigheid en dat zal in de toekomst niet veranderen.

Maar goed we zijnweer offtopic

[R4gnax]

Nou ik ben zeer bekend met beide en ik kan je verzekeren dat is *helaas* bij lange na níet het geval! Natuurlijk kunnen we straks met HTML5 veel meer dan tot nu toe maar het blijft maar een fractie van wat met Flash kan

Daar zou ik toch niet al te zeker van zijn: http://code.google.com/p/quake2-gwt-port/

[voodooless]

Dat is ook logisch: het is nog lang geen gemeengoed. Flash is er al vele jaren en is zo'n beetje ingeburgerd. Bovendien zijn er massa's tools aanwezig om Flash troep te maken.

Nu flash steeds brakker begint to worden (ik ken eigenlijk geen enkel platform waar het goed op wil draaien...) en de browsers zelf al steeds meer kunnen, willen mensen graag wat anders en beters. HTML5 gaat dat zeker brengen. Tot het zover is zal er echter nog wel enige tijd voorbijgaan. Als er nu zelfs al complete 3D shooters in HTML5 gemaakt kunnen worden, biedt dat zeer zeker potentieel voor de toekomst.

Adobe heeft echter nog wel wat tijd om flash te verbeteren.. Wie weet maken ze het ooit nog zo dat het niet blijft hanger, niet schokkerig is, en niet 100% CPU hoeft te gebruiken...

[Verwijderd]

Flash is wel meer dan een videootje embedden hoor. Het is niet omdat OSX en de iPhone/iPad een beetje dwars doen dat je Flash kan afschrijven.

Doe dit maar in html 5 http://www.gnarlsbarkley.com/
Je moet gewoon verder kijken dan de irritante flash-advertenties die Flash zo'n slechte reputatie gaven.

Ik vermoed anderzijds dat Silverlight de boel zal overnemen door de zeer uitgebreide mogelijkheden, goede support, integratie en eenvoud

edit: Knappe voorbeelden! Ik moet toegeven dat ik de kracht van HTML 5 onderschat heb! wow!

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:00]

[Verwijderd]

Doe dit maar in html 5 http://www.gnarlsbarkley.com/
Je moet gewoon verder kijken dan de irritante flash-advertenties die Flash zo'n slechte reputatie gaven.

Even wat voorbeelden van wat er mogelijk is:

• Torus (Tetris in 3D)
• Een (eenvoudige) animatie
• Dynamic shadow
• Paint maar dan mooi

En dat is dan nu, wacht maar tot het straks volwassen is en de Dreamweavers, Frontpages, iWeb's etc. HTML5 functionaliteit krijgen.

Beginning with Gala, Mac users will also benefit from hardware decoding of H.264 video in Flash Player, the number one platform for video on the Web.

[Vul kostende smiley in]

[Spruit_elf]

Dat, plus dat http://www.gnarlsbarkley.com/ waarschijnlijk ook prima te doen is met pre html5 technieken. Een paar hovers en wat bewegende gifjes en wat extra javascript en je krijgt een vergelijkbaar resultaat.

Scheelt je klanten een hoop ergernissen qua cpu gebruik, privacy issues etc.

Flash is gewoon naar en onveilig.
http://www.imasuper.com/6...he-silent-privacy-killer/

[TDeK]

Die moet in HTML5 met SVG en/of Canvas te maken zijn, al zijn de browsers nog niet dermate geoptimaliseerd dat dat ook soepel zal werken, maar dat is een kwestie van tijd. Maar het kan dus wel. Check bijvoorbeeld ook Spritely.
Het enige wat HTML5 volgens mij niet kan is streaming video (bijvoorbeeld live-events), al zijn ze daar wel mee bezig bij het W3C meen ik, en 3d omgevingen tekenen (ala http://fanvaneco-marathon.nl/movie), tenzij je bijvoorbeeld een canvas 'hol' kunt trekken en daar je video op gaat renderen.
More works needs to be done!

[Reactie gewijzigd door TDeK op 23 juli 2024 16:00]

[ppl]

Een website maken in HTML5 stelt vrij weinig voor bij wat Palm heeft gedaan. Palm heeft middels HTML5, CSS en JavaScript een compleet OS uit de grond gestampt met SDK erbij. De apps dien je in die talen te schrijven. De reden waarom men deze weg is ingeslagen is vrij simpel: de meeste mensen kennen deze talen al en zijn er al mee bezig waardoor er maar weinig aan kennis gedaan hoeft te worden om te kunnen programmeren voor webOS. Dat zorgt voor een lage instapdrempel waardoor Palm hoopte op het aantrekken van veel ontwikkelaars.

Palm heeft dan ook laten zien dat het gelul is dat je iets als HTML5, CSS en JavaScript niet zou kunnen gebruiken voor zeer complexe zaken en dat je iets als Flash dus prima kunt vervangen. Apple laat hetzelfde zien met haar iAd systeem. Je moet dus inderdaad verder kijken dan alleen de Flash banners en YouTube content maar dat geldt ook voor dingen als HTML5, CSS en JavaScript.

Overigens stelt de genoemde website zo op het oog ook vrij weinig voor. Het is veel optisch vertoon middels allerlei animaties. Dat heb ik wel vaker gezien met diverse andere niet-Flash technieken. Daar hoef je dus beslist geen Flash voor te gebruiken. Maar ja, dat hadden anderen middels het technische plaatje ook al aangetoond.

[voodooless]

Doe dit maar in html 5 http://www.gnarlsbarkley.com/

Wat is daar zo speciaal aan? Dat stelt toch geen reet voor.. HTML5 kan dat zonder problemen..

Hell, zelfs de

quote: http://code.google.com/p/quake2-gwt-port/

Quake II engine

werkt in HTML5

[Verwijderd]

Alleen een beetje jammer van de h.264 codec.

[_JGC_]

HTML5 heeft gewoon belang bij een opensource codec die wel fatsoenlijke bitrates haalt. Het lijkt erop dat die binnenkort ook gaat komen:
nieuws: 'Google geeft VP8-codec volgende maand opensource-licentie'

HTML5 is leuk, maar als de grootste browser het niet ondersteunt, Safari alleen h264 en quicktime doet en de opensource browsers alleen Theora doen, dan wordt het nooit wat. Ik hoop dan ook dat VP8 uitgegeven wordt onder BSD of MIT licentie, hebben we eindelijk een codec die vrij te gebruiken is in elke browser.

[Dreamvoid]

Browsers moeten helemaal geen videoplayer willen zijn, daar heb je de ingebouwde codecs van het OS al voor.

Uiteraard denken de browserbouwers daar heel anders over.

[TDeK]

En waar denk je dat de browser aan de achterkant tegenaan praat? Of heeft jouw browser al drivers voor je videokaart aan boord?
Het hele idee van het html5 video element is dat ik als webdeveloper nu eindelijk eens kan bepalen hoe die player er bij de gebruiker uit komt te zien, zonder afhankelijk te zijn van welke media player de user op zijn systeem heeft staan, of door gebruik te maken van een plugin als Flash.

[Dreamvoid]

Als de browser (zoals het voorstel nu is) zijn eigen codecs aan boord krijgt, praat het tegen de drivers aan (al dan niet via OpenGL/DirectX), niet met de multimedia frameworks van het OS.

Er zijn 3 mogelijkheden:
- browsers gaan hun eigen codecs schrijven en meecompileren (de browser wordt een monolitisch blok bloat dat alles zelf doet).
- browsers gebruiken een QuickTime/WMF/GStreamer 'passthrough' plugin en gebruiken de systeem codec (houdt de browsers lekker licht en 'centraliseert' video playback op het systeem. Nadeel: elk OS heeft weer een ander media framework, en ze kunnen niet allemaal hetzelfde.)
- browsers gebruiken een Flash/Silverlight/JavaFX plugin en gebruiken de codecs in die players (die natuurlijk veel meer doen dan alleen video, maar dat terzijde). Ook dit houdt de browsers simpel, en verlegt de focus naar de plugin bouwers: die moeten per OS een fatsoenlijke player schrijven (of zoals bij Silverlight, laten schrijven door de OS community).

De browserbakkers gaan voor optie 1. Logisch, want dat is meer werk voor hun devs en maakt de browser een veel groter en belangrijker deel van het OS. Er moet toch brood op de plank. Of het voor de gebruiker zo leuk is om zulke bloated browsers te krijgen, is een heel andere vraag.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 16:00]

[TDeK]

en maakt de browser een veel groter en belangrijker deel van het OS

Van mij mag de browser zelfs het OS worden. Trek het internet uit een computer en je kunt er 'niks' meer mee. Maar dat is bezijden het punt. Ik heb liever dat de browserbouwers de codecs meecompileren, want dan weet ik als webdevver tenminste zeker dat een bepaalde browser die functionaliteit heeft. Nu moet ik maar gokken dat de user een bepaalde codec heeft. En bloated, dat zal ook wel meevallen. Wat hebben we nu? Gigantische codec packs waarvan de gemiddelde users er nog geen 5 gebruikt, nee dat is niet bloated...

[Dreamvoid]

MPEG codec in een MPEG container zou voldoende moeten zijn. [rant] Helaas zijn er alleen nog halsstarrige volksstammen die liever een exotische Matroska container gebruiken die nergens standaard ondersteund wordt (voor H.264) of nog erger, AVI buiten de specs met een los geknutseld sub formaat (XviD). Ik weet dat 'de scene' een conservatief volkje is, maar is het werkelijk teveel gevraagd om je illegale zut in een formaat te gieten dat iedereen standaard kan afspelen?[/rant]

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 16:00]

[ZpAz]

Ze moeten helemaal geen plaatjes toner willen zijn...

[Dreamvoid]

Er is een aardig verschil in complexiteit van plaatjes renderen en video renderen.

Overigens zaten in diverse plaatjes renderers (oa die van Safari) enorme exploits dus wat dat betreft zou het qua security ook geen gek idee zijn om 1 centrale plaatjes library te hebben op je systeem ipv dat elke browserbouwer zijn eigen exploits verzint.

[blouweKip]

Standaarden zijn altijd een goed idee, maar als de browsermaker met het grootste (kunstmatige) browser daar geen heil in zit dan krijg je versnippering.
Overigens geld met images hetzelfde gezeik als met h264: licentiemeuk..

[ppl]

Safari in OS X doet het via het QuickTime framework. Daardoor kan het standaard h.264 doen maar als je dingen als Perian en Flip4Mac installeert maakt het ook gebruik van die codecs. Perian bevat de Ogg Theora codec waardoor Safari in OS X zowel h.264 als Ogg Theora content kan afspelen. Chrome kan het ook maar Google maakt daar gebruik van haar eigen code om dat te doen. Dan houdt je alleen nog Opera (Ogg Theora), Firefox (Ogg Theora) en Internet Explorer (geen van beide) over en waarschijnlijk de Windows versie van Safari (wegens gebrek aan Perian voor QuickTime in Windows).

Het gaat dan ook niet om de ondersteuning van de webbrowsers, het gaat om de verdeling welke codec er ondersteund moet worden. Er was een hevige strijd tussen h.264 en Ogg Theora waardoor men maar heeft besloten om de codec restrictie in HTML5 weg te laten. Erg dom omdat je nu iedere soort codec kan gebruiken en gebruikers moeten gaan zorgen dat hun systeem dat ondersteund. Het probleem wordt nu bij de gebruikers neergelegd. Aangezien HTML5 nog in ontwikkeling is zou het een beter idee zijn geweest als men hierover nog geen beslissing had genomen of dat men het zou beperken tot een x aantal codecs (denk aan Ogg Theora, h.264 en dat nieuwe VP8). Als je iets verder de toekomst in kijkt dan lijkt VP8 meer toekomst te hebben om gebruikt te worden in HTML5 dan Ogg Theora en h.264 omdat het niet de nadelen heeft waar men bij die andere 2 codecs zo vaak over zeurt (licentie en performance zaken).

Edit: op neowin.net kwam ik een artikel tegen dat Microsoft per IE9 de h.264 codec ondersteunt in HTML5: Microsoft: HTML5 is the future of the web, will only support H.264. Saillant detail is de laatste alinea van het stuk waarin Microsoft zegt met Adobe samen te blijven werken om de diverse Flash problemen op te lossen. Kennelijk is Adobe nu nog de enige die Flash zo geweldig vindt...

[Reactie gewijzigd door ppl op 23 juli 2024 16:00]

[Dreamvoid]

Internet Explorer (geen van beide)

IE speelt gewoon video via de Windows Media Foundation player af (net zoals Safari met QT)

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 16:00]

[Hexley]

"worden slechts drie gpu's ondersteund: de GeForce 9400M, de GeForce 320M en de GT330M."

Lekker is dat en wat is er met de GeForce 9600M GT?

[Brantje]

Dat apple deze niet standaard gebruik in hun apple's denk ik zo.
Misschien dat dat nog in de toekomst komt, je weet maar nooit met adobe

[ZpAz]

Die zit in de 'net oudere' MBP's, in mijn MBP zit een 8600GTM welke ook niet ondersteund wordt? Minder

[arjankoole]

Die zit in de 'net oudere' MBP's, in mijn MBP zit een 8600GTM welke ook niet ondersteund wordt? Minder

Die hardware ondersteund volgens mij niet wat ze hier pogen te doen. Op geen enkel OS/platform trouwens. Alleen de meer recente chips kunnen daarmee overweg.

[ZpAz]

OpenCL werkt wel op de 8600GTM, alsook HD-decoding als ik me niet vergis. Vandaar dat ik ook wel verwachte dat dit ook wel zou werken.

[Hexley]

De net iets? Heel veel van de 15" en 17" MacBook Pro's (unibody) hebben een 9400M en een 9600M GT, het laatste instap model had alleen een 9400M maar de rest.

Nee dat betekent straks dus dat ik voor even snel wat surfen tussen de kaarten moet wisselen? Omdat het op de mindere kaart beter loopt, dat zou echt te gek voor woorden wezen of niet dan,...?

En dit geintje heb ik al eerder gehad met die fijne nieuwe Apple toetsenborden die niet 100% op alle intel Mac's werken. Even een EFI update dat is dan weer teveel werk voor ze.

Heb het idee dat je het nieuwste van het nieuwste moet hebben,...
Als ze het niet meer verkopen, dan laten ze je dus direct vallen.... Tsss,...

[Reactie gewijzigd door Hexley op 23 juli 2024 16:00]

[ZpAz]

Sinds 14? April zijn er nieuwe MBP's uitgekomen met de GT330M en de GT320M, dus inderdaad 'net iets oudere'.

[TDeK]

Als ze het niet meer verkopen, dan laten ze je dus direct vallen....

Je krijgt bij OSX toch iets van 5 jaar updates voor het OS? Volgens mij heeft Ubuntu LTS als enige iets soortgelijks. Ik heb dus niet het beeld dat ze je direct laten vallen, integendeel juist. Mijn iPhone krijgt deze zomer al zijn 3e OS.
@RatSAT: Ja, vervelend hè, deden ze het maar net als de concurentie: gewoon geen updates. Weet je tenminste waar je aan toe bent .

[Reactie gewijzigd door TDeK op 23 juli 2024 16:00]

[ppl]

Die 8600M werkt niet om de doodeenvoudige reden dat deze geen hardwarematige video acceleratie heeft voor h.264 video. Dat is er pas sinds de 9400M/9600M gekomen. De afwezigheid van de 9600M is dan ook raar. In het introductie verhaal richt men zich op de huidige line-up van de Mac notebooks. De enige videokaarten die daarin gebruikt worden zijn de 9400M (MacBook en MacBook Air), de 320M (13" MacBook Pro) en de GT 330M (de 15" en 17" MacBook Pro). Als je in de FAQ kijkt naar het antwoord op de vraag "What will Mac users experience with this H.264 hardware decoding?" zul je het volgende stukje tegenkomen:

Mac models currently supported include MacBooks shipped after January 21st, 2009, Mac Minis shipped after March 3rd, 2009 and MacBook Pros shipped after October 14th, 2008.

Daaruit opmakend gaat het over de al eerder genoemde videokaarten maar ook de 9600M want die zit in de MBP's "shipped after October 14th, 2008".

Kijk je echter een vraag verder ("Will all Macs be able to take advantage of H.264 hardware video decoding?") dan is het lijstje ineens ingekort:

Hardware accelerated decode requires Mac OS X 10.6.3 and either NVIDIA GeForce 9400M, GeForce 320M or GeForce GT 330M GPUs.

Kennelijk weten ze het bij Adobe zelf ook niet meer of die 9600M nou wel of niet werkt...
Ik gok op een foutje want volgens mij werkt het gewoon met iedere videokaart die hardwarmatige h.264 acceleratie heeft en daar hoort die 9600M ook bij.

[Reactie gewijzigd door ppl op 23 juli 2024 16:00]

[Verwijderd]

Ah yes... het aloude verhaal van Apple. WIJ krijgen het in ons bol en verlaten bepaalde platformen. En alles en iedereen wat financieel niet bij machte is om ons bij te benen of nieuw wilt kopen, kan lekker de boom in.
Daar doen ze daar niet moeilijk over natuurlijk...... Geld moet rollen, toch?

[bollewolle]

Probeer het eerst een. Kan het momenteel zelf niet testen, maar heb eergisteren dit getest met geoptimaliseerde patch voor Plex (zie reactie verder beneden) en bij mij leek deze gpu acceleratie ook te werken op de 9600M GT. Ik ga straks als ik thuis ben iig deze flash build ook eens uitproberen.

[Verwijderd]

ik vrees dat als je een mac book pro unibody (revisie < 2010) op performance hebt geconfigureerd, dwz de discrete gpu 9600M GT hebt ingeschakeld, dat ie dan niet de ook aanwezige maar uitgeschakelde 9400 in de chipset kan gebruiken voor 'accelerated flash' .

op de 9600gt werkt deze flash hardware acceleratie in elk geval niet wat wel weer saillant is.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:00]

[Dreamvoid]

9600M gebruikt in OSX dezelfde kext driver als de 9400M en is alleen qua aantal shaders/klok anders - dus die doet het neem ik aan ook gewoon.

[smeerbartje]

En de ATI 4670??

[Verwijderd]

Ik begrijp niet helemaal wat dit voor nut heeft? Flash loopt prima op OS X?
Nu bouwen ze een soort Flash Lite dus speciaal voor Mac, maar waarom doen ze dit dan niet voor iPhone en iPad? Persoonlijk heb ik er geen last van maar dat is toch iets waar veel mensen (blijkbaar) tegenaan lopen bij Apple's portables?

[tweak_dude]

Flash geeft onder OSX een VEEL hogere cpu load dan onder Windows. Mijn Macbook begint bij een beetje youtube al snel te loeien. Niet dat ik met mijn oude Macbook iets aan de hardware versnelling heb

[Verwijderd]

ik kan de 'click to flash' safari plugin van harte aanbevelen.

deze voorkomt dat allerhande flash tierlantijnen je computer laten loeien (banners etc) en het internet beeld wordt er ook veel rustiger van.

daarnaast werkt de plugin samen met youtube doordat de filmpjes niet in flash maar in native h.264 gestreamed worden dmv html5 icm de quicktime h.264 codec van apple.

Features:

* Block evil Adobe Flash
Flash only when you want it.
* One-click Flash loading
View blocked Flash with just one click.
* Higher quality YouTube
Play videos in QuickTime, not Flash.
* Website Whitelist
Allow Flash on certain websites.

* Lowered CPU usage
Browse the web more quickly.
* Better battery life
Browse the web longer on your laptop.
* Less fan usage and heat
Browse the web quietly and cooly.
* Automatic Updating
Download updates when they're ready.

http://clicktoflash.com/

[alienfruit]

Nu nog zoiets voor HTML5 en het wereldwijde web is verlost van irritant banners (kijk naar iAds voor mogelijk HTML5-based banners)

[Verwijderd]

voor reclame banner blocken adviseer ik http://glimmerblocker.org/

GlimmerBlocker is implemented as an http proxy, so the stability of Safari isn't compromised because it doesn't use any hacks. It is even compatible with all other browsers and other native Mac OS X applications which uses http, e.g. NetNewsWire.

werkt als een proxy die reclames uitfiltert

[ZpAz]

Nee het is geen flash lite, het is flash met GPU acceleratie, wat er ook onder Windows is als ik me niet vergis.

[Justice]

minder stroomverbruik, zie bron

[wvdburgt]

Als er iets ruk loopt is het wel flash in os x. 50% cpu gebruik op beide keren ol een core 22 duo 3 ghz moet niet kunnen.

[_beevee_]

Deze ontwikkeling is toch net bedoeld om jouw hoge CPU load aan te pakken?

[wvdburgt]

Ja dus ipv gewoon iets fatsoenlijks te maken gaan we maar de acccu via de gpu leegtrekken. Ik zie iig een probleem verplaatsing. Overigens zie ik ook niet verdwijnen dat ie om de haverclap crasht.

[kiang]

Ben ik de enige die niet begrijpt waarom die beperkt wordt tot enkele GPUs??? Als Adobe OpenCL gebruikt (onderdeel van ALLE 10.6 versies) kunnen ze elke GPU ondersteunen...

conclusie: flauw nieuws: grootse titel, magere inhoud

@maurits & mddd: aha, bedankt voor de duiding

[Reactie gewijzigd door kiang op 23 juli 2024 16:00]

[Maurits van Baerle]

Dit heeft niets met OpenCL te maken, dat is hier niet voor bedoeld. Sommige GPU's hebben hardwarematige support voor specifieke videocodecs. In dit geval maakt Adobe gebruik van hardwarematige support voor h.264 die in de genoemde GPU's aanwezig is.

[mddd]

OpenCL maakt het mogelijk om bepaalde rekentaken door de GPU uit te laten voeren in plaats van de CPU. Theoretisch gezien is het dus inderdaad mogelijk om een software decoder sneller te laten werken door hem zo te schrijven dat hij via OpenCL de GPU benut.

In dit geval is dat echter niet zo lonend voor Adobe. Immers, moderne videokaarten hebben zelf al h264 decoding. Decoderen in software -al dan niet met gebruik van de GPU- is dan dus niet zo nuttig, als je het ook meteen door de videokaart zelf kunt laten doen. Wat nu dus kan, via de API in OS X.

[Brantje]

Nooit verwacht dat adobe en apple nog samen zouden gaan werken om Flash mogelijk te maken op OS X. Het was er al wel, maar dan zonder hardware ondersteuning waardoor het niet lekker liep.

Ik vind dit wel een goede vooruit gang.

Alleen jammer dat ze 3 gpu's ondersteunen, maar zoals het in het artikel staat zijn dat toch de meest gebruikte GPU's van apple.

[Reactie gewijzigd door Brantje op 23 juli 2024 16:00]

[blouweKip]

Het is echter een misvatting dat flash niet lekker liep omdat apple die api's niet zo hebben vrijgegeven, dat ligt meer aan het feit dat de *nix versies van flash gewoon slechte producten zijn, dat ze nu meer de gpu gaan gebruiken om dat feit te maskeren doet daar niets aan af.

[Reactie gewijzigd door blouweKip op 23 juli 2024 16:00]

[_beevee_]

Die API is pas zeer recent beschikbaar gekomen hoor dus onmogelijk dat ze daartoe eerder toegang hadden. Ander optimalisaties zijn ook aanstaande in 10.1 voor OSX.

Kortom Apple had eerder die API's moeten beschikbaar stellen en andere hardware API's die mogelijk nog niet beschikbaar zijn moeten ze ook gaan openstellen. En Adobe had waar mogelijk al in eerdere versies verdergaande optimalisaties moeten doorvoeren en n.a.v nieuwe mogelijkheden nieuwe optimalisaties doorvoeren.

Anyway IMHO: "oude koeien"!

Dit is een zeer mooie vooruitgang, laten we daarom BEIDE partijen eens complimenteren voor deze vruchtbare samenwerking

[Reactie gewijzigd door _beevee_ op 23 juli 2024 16:00]

[blouweKip]

Het is gewoon gebruikt als een excuus, ook zonder die zgn api's zou het gewoon fatsoenlijk moeten draaien, het gaat hier niet alleen over h264 + flash accel.

flash is gewoon slecht op osx en linux, dat heeft niets met apple's api's te maken en alles met flash.

[Verwijderd]

Sowieso is het allemaal gelul natuurlijk heh. Als ik een stuk hardware fabriceer, en ik laat het toe dat die hardware direct aangesproken kan worden, dan hoeft het OS niets anders te zijn dan een pijpleiding die die instructies doorlaat en het resultaat op beeld neerzet. Dat dat onder Windows wel goed zou kunnen en onder *nix (en dus ook os*nix) niet, is absolute machtspelletjes quatsch en heeft meer te maken met dat feit en het feit dat een bepaalde OS-veranderaar niet via zijn os toegang wil geven tot wat dan ook, zonder hun expliciete toestemming. De discussie die daar weer aan vasthangt is een onderwerp an sich.

Maar goed, wat het hele bruikbaarheids-versus-veiligheid/stabiliteit betreft, zijn we toch massaal de verkeerde kant op aan het lopen. Helaas noodgedwongen. Hiermee doel ik ook op IPv6 etc etc.

Ipv iets geheel nieuws te ontwikkelen bouwen we een soort van noodgedwongen door op oude technieken waarbij veiligheid in beginsel nooit een rol heeft gespeeld en er tot op de dag van vandaag alleen maar lapmiddelen zijn gebruikt om het spul werkend te houden.

And that, my friends, is gonna bite us in the @ss...

[tehsojiro]

mooi wordt mijn cpu ook niet meer volledig belast bij het afspelen van een youtube filmpje

[Verwijderd]

Loopt YouTube niet al op HTML5?

[himlims_]

http://www.youtube.com/html5

[jorde]

Dat is verreweg niet het geval bij de meeste filmpjes (heb ik er zelf helemaal geen kunnen vinden).

Bovendien is de HTML5 player nou niet bepaald stabiel/bug free. (knoppen die niks doen, knoppen die iets anders doen dan wat ze zouden moeten doen. Video die maar half geladen wordt etc. Zowel in chrome als safari heb ik dit ervaren).

[Verwijderd]

Raar, mijn ervaring is dat de meeste fimplpjes juist wel in dehtml5 player te bekijken zijn en zelf geen last gehad van halve video's enzo.

Moet ik overigens wel zeggen dat ik niet zo veel youtube bekijk.

[Verwijderd]

Owh? Bij mij laden bijna alle filmpjes in h264 / HTML5?
En HTML5 player is de implementatie van je browser he Niet van Youtube zelf, dus..

alhoewel ik die van mijzelf (Safari 4) ook nog niet echt geweldig vind, kan bijvoorbeeld alleen maar mute doen ipv hele volume regeling, en dat is heel irritant op Youtube.

[bollewolle]

Plex heeft eergisteren ook een test patch uitgebracht die van deze nieuwe gpu acceleratie gebruik maakt. Nu, ik vermeld dit maar omdat het lijkt dat dit niet enkel gelimiteerd is tot de 3 vermelde gpu's. Uit de reacties blijkt namelijk dat bijvoorbeeld de 9400 (zonder de M dus) ook zou werken. Daarbij heb ik het zelf ook getest met een MBP September 2008 model, met de GeForce 9600M GT geactiveerd en bij dit model leek de cpu load ook een heel stuk lager te liggen bij het afspelen van 1080p materiaal. In deze laatste steekt ook wel een 9400M, maar de Higher Performance optie in de Energy Settings staat aan, dus dat betekend dat de 9600M GT actief is, niet de 9400M ...

[Reactie gewijzigd door bollewolle op 23 juli 2024 16:00]

[Justice]

Het gaat erom dat het voor bepaalde configuraties geen zin heeft om het aan te zetten omdat het stroomverbruik omhoog gaat.

The primary reason this API exists is because we have been working with Apple to come up with a way to reduce power consumption on Macs. As we see more and more HD content on the web it is critical that we take advantage of hardware resources when available.
http://blog.kaourantin.net/?p=89

[bollewolle]

Het hoeft niet specifiek over stroomverbruik te gaan. In Plex wilde 1080p materiaal al wel eens haperen, frames droppen, ... Dit bij 80-90% (of meer) cpu verbruik. Nu er een deel door de gpu wordt verwerkt loopt dit materiaal perfect EN bij slechts een cpu verbruik van een 25-30%. Dat de gpu nu misschien meer verbruikt maakt niets uit (voor mij toch niet) als het uiteindelijke resultaat (het beeld) daardoor beter is geworden. Maar dat is uiteraard slecht mijn opinie.

[Dreamvoid]

Er zijn geen Macs met de 9400-zonder-M. Hebben ze t hier over Hackintoshes?

(edit: ah er zitten in die comments sectie een paar figuren die denken dat ze een 9400 in hun Mac hebben )

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 16:00]

[Pykow]

Flash mag dit ook bij windows doen hoor.
Ik heb namelijk een Nvidia GT320 in mijn pc zitten en ze ondersteunen nu al 320Mobile op de mac.

Flash en apple hebben een sterke relatie. In mijn ogen is het Windows + Office en Mac + Adobe

[ppl]

Met 10.1 was het de bedoeling dat er voor Windows en Linux hardwarematige videoacceleratie was. Voor OS X was dit niet mogelijk aldus diverse techneuten en wat Adobe mensen. Nu blijkt dat er sinds ergens eind maart al een of andere API is waardoor ontwikkelaars gebruik kunnen maken van de hardwarematige acceleratie voor H.264 content in OS X. Flash 10.1 kan nu dus ook voor OS X de video acceleratie bieden die ze voor Windows en Linux bieden. Daardoor komt Flash voor alle platformen weer op dezelfde hoogte wat features betreft (qua performance is dat nog afwachten).

[majic]

Alleen jammer dat Apple veel meer innovatie bied al jaren lang op het Windows platform.

De reden dat er zo iets als Final Cut Studio bestaat is omdat Premiere niet naar Apple geport werd.

De Adobe Suit (Photoshop Indesign etc) zijn héél lang erg traag geweest op OS-X omdat ze nog niet op basis van universal binary waren.

Het hele Flash perikel is weer een nieuw probleem wat aantoont dat Adobe en Apple echt geen hele grote vrienden zijn (maar meer elkaar als afzetmarkt zien...en meer niet).

Nee, voor ultieme prestatie van Adobe pakketten kan je beter op wintel werken. Zo kan je nog steeds niet meer dan 3 gig geheugen aanspreken voor Photoshop onder OS-X (Bij windows in principe onbeperkt). Dat ga je flink merken bij grote bestanden, professioneel gebruik.