X264 krijgt ook commerciële licentiemogelijkheid

De ontwikkelaars van de x264-encoder hebben aangekondigd met een commerciële licentie te komen. Voorheen was de broncode alleen onder gpl-licentie beschikbaar, waardoor deze niet in gesloten software mocht worden gebruikt.

Jason Garrett-Glaser, de hoofdontwikkelaar achter de encoder, liet dat weten in een post op de mailinglist van het project. Met de nieuwe licentie kunnen softwarefabrikanten de broncode van x264 in hun programma's implementeren, ook als de broncode van deze software niet wordt vrijgegeven. Hoewel de klanten vrij zijn om met de code te doen wat ze willen, moeten ze eventuele aanpassingen wel openstellen voor de organisatie achter x264. Deze beoordeelt dan of de aanpassingen goed genoeg zijn om in de hoofdversie van het project te worden doorgevoerd.

Bedrijven die van de nieuwe licentieconstructie gebruik willen maken, moeten minimaal 10.000 units à 1 dollar afnemen. Daarbij kunnen nog patentkosten komen. In landen waar patenten op software-algoritmen worden erkend, moet boven de 100.000 units geld worden afgedragen voor het gebruik van de h.264-codec. Online-video's die gebruikmaken van h.264 en gratis worden aangeboden, zijn tot 2015 vrijgesteld van deze royalty fees.

De opbrengsten van de nieuwe licentie vloeien terug naar de ontwikkelaars, die met de nieuwe inkomsten naar eigen zeggen meer tijd aan de ontwikkeling van de encoder kunnen besteden. Daarnaast zien ze mogelijkheden om eventueel andere opensource-projecten te sponsoren.

Reacties (69)

[albatross]

Ik ontving dit nieuws met gemengde gevoelens. Zelf maak ik zeer veel gebruik van x264 (heb er zelfs net een i7 980x voor gekocht). Een grotere verspreiding zou ik dus eigenlijk toe moeten juichen. En in zekere zin doe ik dat ook.

Maar ik zie ook een keerzijde. Het lijkt een beetje op het MySQL verhaal. met een 'Community' en een 'Enterprise' versie, waarbij de nadruk bij de ontwikkeling toch vooral is komen liggen bij de laatste. Zeker nu er belangrijke nieuwtjes aankomen, zoals 10-bit encoding (4:4:4 colorspace) en 3D support, hoop ik dat ook de 'Community' versie van x264 blijft bloeien; maar ik hou mijn hart vast.

[dj_tjerk]

De developers hebben dan ook een clausule opgenomen waarin staat dat de code opgenomen wordt in de gratis versie mits goed/nuttig genoeg, en ze zichzelf gebonden hebben aan het niet oprichten van een proprietary fork:

2. However, you must give your modifications back to us, x264 LLC.
If they're useful, we'll roll them back into the official x264. No
proprietary forks! If a change helps you, it should help the
community, too.

En

Our promise to the x264 community:

1. We (x264 LLC) are legally obliged, by our own contribution
agreement, to never create a proprietary fork of x264. Specifically,
if we distribute a modified version of x264, we must open-source the
modifications too. No exceptions.
2. The vast majority of all profits will be returned to the
developers of x264 to allow them to dedicate more time to improving
x264. A small portion will go to paying off legal fees and a
rainy-day fund. We might also choose to use a small portion of it in
the future for other open source-related purposes, such as sponsoring
useful ffmpeg projects, like implementing 4:2:2 and 4:4:4 H.264
decoding support in ffmpeg.

Dit hebben ze zo besloten juist omdat, zoals je zegt, in het verleden is gebleken dat de focus anders verschuift naar de betaalde versie. Dus daar zou je je geen zorgen over hoeven maken

EDIT:
Je zet 4:4:4 colorspace tussen haakjes na 10-bit, maar je weet dat de twee los van elkaar staan?

[Reactie gewijzigd door dj_tjerk op 3 augustus 2024 12:22]

[fevenhuis]

Inderdaad hangt alles af van in hoeverre men x264 voor het pro gedeelte functionerend krijgt, voorlopig is het dus nog niet zover.

Ik denk dat de huigie beslissing vooral samenhangt met dit (wikpedia): "In April 2010, the x264 project announced full Blu-ray compliant video encoding capability making x264 the first Blu-ray compliant free software H.264 encoder". link

Er wordt dus geclaimt dat men Bluray compliant videos kan maken met x264, nu nog even GPU acceleratie maken en het kan nog wat worden.

[mashell]

Dit klinkt een beetje als van twee walletjes willen eten, wel symphatiek open source maar ook willen cashen. Ik geloof er niet dat het gaat werken voor ze.

[morrowyn]

open source is niet inherent aan gratis, als dat hetgeen is waarop je doelt met van twee walletjes eten.

[Zoijar]

Niet in op een directe manier, maar wel indirect, zoals ik hierboven ook aanhaal. Stukje van het net geplukt, een reply van GNU op een vraag.

> 2. Does the GPL give my customers the right to give
> away my application for free, after they buy it from
> me, simply because a small part of my application is
> based on a GPL’ed project?

Yes. When you use that GPLed code, you must release your own work under the GPL as well; this is required by section 2(b) of the license. As a result, when your customers receive it from you, they’ll have the right to distribute it however they wish; this is permitted in section 1.

Voorbeeldje: Adobe implementeert h.264 support in photoshop dmv de x264 codec. Ze nemen geen licentie. Heel photoshop valt dan onder de GPL voor minder dan 1% functionaliteit. Ik koop photoshop dan, dwing ze om de source af te staan volgens de GPL, begin een website 'freephotoshop.com', compile een release build van de sources, en tenslotte biedt ik beide gratis aan op die website. Ik ben dan volstrekt legaal bezig. Adobe verkoopt waarschijnlijk maar 1 exemplaar.

Nou kan Adobe misschien de licentie nog wel betalen (hoewel het er ook dik inzit dat ze dan maar gewoon geen h.264/x264 support doen), maar hoe zit dat voor een startend bedrijfje? Kunnen die even $10k neerleggen als ze beginnen? Of misschien zelfs wel $100k? Wat als ze maar $2 voor hun product vragen? Moeten ze dan de helft van hun omzet afstaan. Dat kan natuurlijk niet. Kleine bedrijfjes moeten dus of hun software gratis weggeven, of terugvallen op andere codecs. Dat laatste zal gebeuren en geeft ze een heel oneerlijk nadeel als dit tot grote standaard wordt gemaakt.

[Reactie gewijzigd door Zoijar op 3 augustus 2024 12:22]

[elmuerte]

Voorbeeldje: Adobe implementeert h.264 support in photoshop dmv de x264 codec. Ze nemen geen licentie. Heel photoshop valt dan onder de GPL voor minder dan 1% functionaliteit. Ik koop photoshop dan, dwing ze om de source af te staan volgens de GPL

Nee, dat is niet zo. Als jij niet voldoet aan de voorwaarden van de GPL pleeg je gewoon auteursrecht schending. Het betekend niet meteen dat je al je code moet vrijgeven onder de GPL. Hoe deze auteursrecht schending uiteindelijk opgelost wordt is afhankelijk van de beide partijen waarmee ze akkoord gaan.

[Zoijar]

Dat is natuurlijk een onzinnige redenering: het moet wel, maar als je je er gewoon niet aan houdt, dan hoeft het niet.

[YaPP]

Je kunt voor twee opties kiezen als je niet aan de voorwaarden van de GPL voldeed:
- je code vrijgeven
- het product niet meer verkopen/distribueren

In beide gevallen los je zo de schending van auteursrecht op; de tweede optie wordt door de GPL toegelaten.

Op ieder werk zit nl. auteursrecht. De auteur geeft je expliciet toegang tot gebruik, meestal met bepaalde voorwaarden. Als je die licentie negeert, heb je sowieso geen recht tot gebruik van het product. Daarom kan de GPL goed afgedwongen worden, en is dat doorgaans geregeld voordat een rechtzaak gestart hoeft te worden.

[Zoijar]

Ik snap het punt niet? Wat is dan de keuze in het Adobe voorbeeld die per se geen betaalde licentie willen afnemen? Hun code en dus hun hele product vrijgeven voor gratis distributie onder de GPL of hun product niet meer verkopen; ja, dat lijkt me duidelijk, als je geen product hebt hoef je je niet druk te maken om licenties.

Volgens de GPL moet je dus wel al je code vrijgeven onder de GPL. En nu komen jullie met het argument 'dan houdt je je gewoon niet aan de GPL en pleeg je auteursrechtenschending'; wat je dan kan "oplossen" door je product niet meer te verkopen. Wat is dat nou voor oplossing?

[arjankoole]

Dit klinkt een beetje als van twee walletjes willen eten, wel symphatiek open source maar ook willen cashen. Ik geloof er niet dat het gaat werken voor ze.

Nee, ze hebben weinig keuze als ze meer bereik willen creeeren voor hun product. Veel bedrijven zijn namelijk erg allergisch voor de GPL licentie, hoe dol ze misschien ook zijn op de software zelf. Dat is de grote beperking die OSS heeft gekend in de adaptatie.

Daarnaast wil je als developer ook een inkomen hebben. Dit is een goeie methode waarbij commercieele licensering het gehele project vooruit helpt. Als de developers fulltime er aan kunnen werken, is dat alleen maar gunstig nietwaar?

[Reactie gewijzigd door arjankoole op 3 augustus 2024 12:22]

[Zoijar]

Waarom dan GPL en geen LGPL? Zou jet hetzelfde effect mee bereiken -- min het licentie geld uiteraard.

[mbb]

beter A-GPL, zodat zelfs als je de encoder in een webservice gebruikt de code toch vrijgegeven moet wordn

[Maurits van Baerle]

Wat is er mis met geld verdienen met Open Source software?

[Zoijar]

Niks. Nokia doet dat ook met Qt, wat wel gewoon onder de LGPL valt, maar waar mensen toch commerciele licenses voor nemen voor extra voordelen (oa. het aanpassen van de Qt source zelf).

Ik vind niet dat toekomstige webstandaarden onder een restrictieve licentie moeten vallen. Sowieso gaan kleine bedrijfjes dan weer hun eigen codecs gebruiken en zit je waarschijnlijk nog steeds met incompatibiliteiten. Gewoon een goede standaard codec waar door een grote open source community aan gewerkt wordt. Ik weet nog wel wat een gedoe het altijd was met verschillende vormen zoals divx 3.11a etc.

Je zal bijvoorbeeld geen applicaties die gebruik maken van X264 in een apple store oid zien. Die applicaties worden verkocht voor maar $2 oid en kunnen dus nooit $1 licentie kosten betalen. Andere optie is om je code dan ook onder de GPL te versrpeiden, er nog steeds $2 voor vragen, maar iedereen is dan vrij om vervolgens jouw hele programma gratis aan te bieden. Mensen krijgen dan de keuze: $2 of gratis, en we weten wel hoe dat gaat natuurlijk.

[Reactie gewijzigd door Zoijar op 3 augustus 2024 12:22]

[Dreamvoid]

Open source heeft niets wel of niet cashen te maken. "Free as in speech, not as in beer", enzo...

[kozue]

En wat is er mis met betaald willen krijgen voor je werk? Ze geven je een keuze. Iedereen kan het nog steeds als open source gebruiken, maar voor wie open source niet werkt, kunnen ze tegen een vergoeding ook een closed source versie krijgen. Dit heeft dus geen invloed op het open source zijn, sterker nog, de open source code zou er mogelijk een boost van kunnen krijgen.
Het is vergelijkbaar met wat commerciële Linux aanbieders, zoals Redhat en Novell, doen. Ik als groot open source voorstander wens ze dus ook het beste toe met het "cashen" en hoop dat ze hier de codec nog beter mee gaan maken. Ik maak er iedere week toch wel weer gebruik van als ik op m'n Linux bak h264 video afspeel

[ltcom]

Als je iets als standaard wilt hebben moet het gewoon vrij beschikbaar én vrij te gebruiken zijn. De huidige twee opties zijn - zoals zo vaak hierboven gezegd - geen vrije opties. Je moet óf betalen, óf je moet je gehele product weggeven. Even flauw, maar stel je voor: W3C stelt voor dat iedereen die HTML wil gebruiken óf moet betalen per page-view/site, óf de gehele website's source (incl. de javascripts etc) moet vrijgeven.

toevoeging: open source is een ontwikkel model, (L)GPL betreft het auteursrecht. Opensource kan prima beperkingen hebben in het auteursrecht; andersom niet: 'Free software' =! Open source <http://www.gnu.org/philosophy/open-source-misses-the-point.html>

Edit: boel geneuzel

[Reactie gewijzigd door ltcom op 3 augustus 2024 12:22]

[Rob Coops]

Nou nee ik denk het niet ik denk eigenlijk dat het de enige manier is voor veel grotere open source projecten om echt te blijven door ontwikkelen en de concurrentie van andere projecten voor te blijven.
Als je kijkt naar RedHat, Suse, Apache en MySQL dan zie je steeds het zelfde om het hoofd boven water te houden als het project eenmaal echt established is is er maar een optie en dat is geld binnen harken omdat de core developers tegen die tijd gewoon een dag taak hebben aan het bijhouden van het project en de ontwikkelingen in de markt er om heen.

Het is onredelijk dat een core Apache ontwikkelaar instaat zou zijn om van lucht alleen te leven en toch wordt er door de grote van het project de complexiteit van de ontwikkelingen en de hoeveelheid administratief werk er om heen van ze verwacht dat ze minimaal 20 uur per week voor het project beschikbaar zijn. Een aantal projecten heeft bijvoorbeeld core ontwikkelaars bij bedrijven als Google en IBM geplaatst waar ze een vast inkomen hebben maar ook de garantie dat ze een goed deel van hun tijd aan het project kunnen besteden. Andere ontwikkelaars worden bijvoorbeeld door een support organisatie als RedHat betaald om support op het pakket te leveren en natuurlijk om verbeteringen in het project door te voeren etc.

Van alle echt grote open source projecten kan ik er niet een bedenken die niet een betaalde variant heeft. Kijk naar de Google Summer of Code projecten en andere vergelijkbare projecten waar Google studenten een mooie beloning in het vooruitzicht stelt als ze een goed deel van hun zomer vakantie op willen geven om aan de ontwikkeling van een open source project. De laatste paar jaar zijn redelijk wat projecten op die manier een flink stuk vooruit geholpen omdat er op eens een fulltime developer een maand of meer zich volledig kan richten op de ontwikkeling van een nieuwe feature of de verbetering van een bestaande functie, het porten naar een nieuw platform etc...

Je moet niet vergeten dat veel van de ontwikkelaars van deze encoder het grootste deel van het werk hebben gedaan in hun vrije tijd, dat is dus tijd die ze niet met de kinderen, de partner of vrienden en familie kunnen doorbrengen. Dat houd dus in dat het veel al een paar uur per dag en zo af en toe een weekend is dat op geofferd wordt voor de hobby. De meeste van deze mensen zijn developers overdag en offeren hun vrije tijd op om zo'n encoder te schrijven, gewoon omdat het leuk is. Maar een hobby die zo veel tijd in beslag gaat nemen dat je op een bepaald moment moet kiezen tussen de hobby, werk of een sociaal leven is vaak een hobby die het verliest. Zonder inkomen kun je nu eenmaal niet leven en je sociaal leven is veel al toch een stuk belangrijker dan een hobby. Dat is voor veel open source projecten het punt waarop ze instorten omdat de core ontwikkelaars het project nood gedwongen moeten verlaten (een promotie, een familie situatie etc) de overgebleven ontwikkelaars zijn vaak niet instaat om het project door te ontwikkelen, onderhouden gaat vaak nog wel maar nieuwe ontwikkelingen zijn veel al erg moeilijk.
Als je door een commerciële licentie aan te bieden dit kunt voorkomen en bijvoorbeeld twee of drie van de core developers kunt betalen voor hun diensten dan zullen ze niet snel bij het project weg rennen en doen ze het wel dan heb je een redelijke mogelijkheid om iemand anders over te halen een flinke hoeveelheid tijd te besteden aan dit project.

[Recoil]

Dit lijkt me erg goed nieuws, op deze manier kunnen ook de grote softwarebakkers X264 gebruiken waardoor de codec nog meer mainstream wordt. Hoe groter het draagvlak, hoe groter de kans op een 'standaard' codec.

Een groot nadeel is dat een grote commerciële speler zoals Youtube in 2015 mogelijk kiest voor een ander codec dan h.264. Hierdoor wordt het draagvlak juist minder groot.

[Reactie gewijzigd door Recoil op 3 augustus 2024 12:22]

[Fuzzillogic]

Waarom is het groter worden van een niet-royalty-free codec goed nieuws?? Zeker nu VP8, on par met h.264, wél royalty free en open source beschikbaar is?

Het is pas goed nieuws als een goede royalty-free/patent-free mainstream beschikbaar en ondersteund wordt, en h.264 is dat dus beslist niet!

[Jazco2nd]

Omdat als het open source is (en dus onder GPL valt) het niet in gesloten software mag worden gebruikt. Dus X264 kan nu in meer software worden gebruikt dan VP8.

[Fuzzillogic]

WebM en VP8 is royalty free. De code die Google released heeft valt onder een BSD-licentie. Het kost bedrijven dus geen cent en ze hoeven niks te openbaren.

[Verwijderd]

Precies, daarmee is X264 eigenlijk achterhaald.

Dat VP8 patenten schendt is de bekende FUD (fear, uncertainty, or doubt) die bedrijven als Microsoft ook zo graag verspreiden over Linux om hun concurrenten dwars te zitten.

Als er patentkwesties zijn laat die dan maar eerst eens boven tafel komen, zolang dat niet gebeurt zijn ze er niet. En ja iedereen kan nonsense rechtzaken aanspannen dat bewijst SCO wel. Maar een rechtzaak winnen dat is nog iets anders. En ik neem aan dat Google bedrijven zeker bij zal staan in zulke rechtzaken want het is haar belang, om VP8 rechtenvrij te houden. En Google heeft hele diepe zakken.

Bovendien is het nonsense argument, want juist het argument van patentrechten geldt veel sterker voor H264. Want niemand kan garanderen dat de prijs daarvan in de toekomst niet fors gaat stijgen. Logisch dat men in eerste instantie genoegen neemt met weinig om H264 tot defacto standaard te verheffen. Eerst afnemers binden en ze dan uitmelken, dat is gewoon een normaal commercieel concept. Je moet wel erg blond zijn als je daar in trapt.

Google heeft heus VP8 goed laten bekijken door specialisten op patentinbreuk. Die zeggen dat het vrij eenvoudig is om deze patenten te omzeilen omdat patenten vereisen dat dingen nogal specifiek worden omschreven, wat een workaround vrij gemakkelijk maakt.

Ook wordt weer even als feit gepresenteerd dat H264 beter zou zijn. Met evenveel recht kan je het omgekeerde beweren, het is maar waar je het meeste waarde aan hecht. VP8 en H264 ontlopen elkaar niet veel, en VP8 zal ongetwijfeld doorontwikkeld worden. Maar VP8 wint het op het een belangrijk gebied: het is een vrij formaat.

Met H264 is de bizarre situatie ontstaan dat ook al koop je allerduurste videocamera je nog steeds niet rechtenvrij kan filmen. Absurd gewoon. Voor de mensheid als geheel is het van vitaal belang dat de peilers van de infrastuctuur van internet rechtenvrij zijn.

Belasting betalen aan de overheid is een ding. De overheid is tenslotte ons gemeenschappelijk belang en wij zijn aan de gemeenschap verplicht. Maar belasting betalen aan grote corporatie die met slimme manipulaties bezig zijn ons standaarden op te dringen, dat is een heel ander ding. Van dat soort belasting moet de mens vrij gehouden worden, anders creer je een wereld van slavernij, waarin de mens schatplichtig wordt gemaakt aan anderen nog voor hij geboren is.

Verder, Het is te begrijpen dat de makers van X264 naar wegen zoeken om hun inspanningen om te zetten geldelijk gewin, nu het idieele belang van een vrije coder voor H264 is afgenomen. Dat vind ik heel normaal. Maar om nu H264 te gaan promoten boven VP8, dat is denk ik niet wat deze mensen beogen. Verder is H264 natuurlijk nog lang niet dood, omdat er nogal wat grote bedrijven een aandeel in hebben en dus ook een belang om het verder te blijven pushen.

Maar met de komst van VP8 zijn hun dromen om flink aan H264 te verdienen in rook op gegaan. Het zal nu toch echt moeten concurreren met een gratis open source alternatief. En dat is waarom mensen als Steve Balmer Open Source vanuit de grond van hart haten.

Eigenlijk zou het zo moeten zijn dat er een supernationaal orgaan is dat de publieke standaarden ontwikkelt en er op toeziet dat ze open zijn. Standaarden die niet open zijn zouden niet eens toegestaan moeten worden op het web. Als bedrijven zo graag een afwijkende of verbeterde standaard willen gebruiken dan moeten ze maar on GNU-licentie aanbieden. Dat zou een zegen zijn voor de mensheid. We moeten eens af van het kolderieke idee dat op alles geld verdiend moet worden. Egoisme moet niet tot het leidende principe van het bestaan gemaakt worden. Dat betekent namelijk dat we egoisten de macht geven over de samenleving en dat haalt alleen het slechtste uit de mens.

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 12:22]

[OddesE]

Omdat als het open source is (en dus onder GPL valt)

Dit is precies verkeerd om geformuleerd. Een beetje alsof je zegt: 'Omdat het een auto is (en dus een BMW)', of 'Omdat het een boom is (en dus een eik)'.

Niet alle Open Source software is GPL licensed, net zoals niet elke auto een BMW is en niet elke boom een eik. En alleen de GPL heeft deze eigenschap dat het niet in gesloten software gebruikt kan worden. Apache, BSD of MIT style licenties zijn ook Open Source en kun je wel gewoon in gesloten software paketten gebruiken. Dit is typisch een GPL iets.

Het dual license model lijkt verder leuk, maar raakt eigenlijk kant noch wal. Dit komt doordat de uitgever van de software alleen een andere licentie dan GPL aan de software mag plakken doordat zij zelf het copyright heeft. Echter als mensen uit de community bijdragen maken, dan kunnen deze niet onder de dual license vallen, omdat de uitgever deze niet zelf gemaakt heeft.

Het hele idee van Open Source is dat je met een community deelt en samen werkt, maar door het dual license principe kunnen de bijdragen van andere community leden niet terug stromen naar het hoofdproject, tenzij de auteurs expliciet hun copyright erop afstaan aan de uitgever van het hoofdproject (iets wat onder de GPL niet het geval is). En zonder de dual license kan het pakket niet gebruikt worden in commerciele software...

Ik blijf de GPL een erg problematische licentie vinden. Zie ook alle compatibiliteits problemen tussen deze en andere Open Source licenties (die overigens altijd aan de andere licentie liggen volgens de GPL aanhangers).

[Verwijderd]

Zeker nu VP8, on par met h.264, wél royalty free en open source beschikbaar is?

De door Google gereleasede codec voor VP8 is tot wel 50% slechter dan x.264 main profile en ook nog heel veel trager. (en met 50% slechter bedoel ik dat je tot 50% meer data nodig hebt voor een gelijke kwaliteit video)

Dat zou ik geen on par willen noemen.

VP8 is wel on par met de x.264 baseline profile een lichtere h.264 codec variant die bepaalde features mist en die is geoptimaliseerd voor snelheid en bedoeld voor bijvoorbeeld mobiele devices en videobellen. Die lichtere codec variant is echter ook 50% slechter dan main profile x.264

[Fuzzillogic]

Ligt maar net aan wie je het vraagt. Besides, VP8 is erg nieuw en kent nog geen optimalizaties. Dat kan bijzonder veel schelen, kijk maar naar Theora 1.1.

Persoonlijk vind ik Theora al goed genoeg voor online video - niet alles hoeft 50Mibit/s 1080p@60fps te zijn. Vrije codecs die gewoon wijd ondersteund zijn vind ik dan al snel belangrijker dan iets betere kwaliteit met gezeik met licenties en royalties. H.264 lijkt door zijn patentgezeik al geen kans te maken in Opera en Firefox, terwijl die Theora en WebM al out-of-the-box ondersteunen.

[Reactie gewijzigd door Fuzzillogic op 3 augustus 2024 12:22]

[Verwijderd]

Besides, VP8 is erg nieuw en kent nog geen optimalizaties

Het kan jaren duren voor die optimalisaties er zijn en dan nog is het zo dat er dan talloze niet geoptimaliseerde implementaties op basis van de nu gereleasde Google codec in omloop zullen zijn. En als er echt zoveel optimalisaties mogelijk zijn dan had Google een jaartje door moeten ontwikkelen en dan een goede codec voor vP8 moeten releasen in plaats van een slechte variant die nu door veel partijen wordt gekopieerd en ingebouwd.
En zelfs na optimalisaties nog blijft dat VP8 bepaalde functionaliteiten mist tov h.264 die je niet met optimalisaties kunt inhalen.

Persoonlijk vind ik Theora al goed genoeg voor online video - niet alles hoeft 50Mibit/s 1080p@60fps te zijn

Theora is zo slecht dat je effectief een willekeurig Theora video altijd kan vervangen door een half zo grote x.264 bestand. Gezien de impact van video op de hoeveelheid data op het internet betekent h.264 dus een gigantische besparing in opslag en bandbreedte.

[Fuzzillogic]

en dan nog is het zo dat er dan talloze niet geoptimaliseerde implementaties op basis van de nu gereleasde Google codec in omloop zullen zijn

En waarom is dat mijn probleem? Het gaat erom dat de bitstream compatible blijft met de decoder. Precies wat Theora 1.1 doet: veel betere kwaliteit die gewoon met de oude decoder weer te geven is. Voor MPEG heeft meen ik Panasonic destijds ook zo'n truukje uitgehaald. 7Zip kan kleinere zipjes maken. Etcetc.

Theora is zo slecht dat je effectief een willekeurig Theora video altijd kan vervangen door een half zo grote x.264 bestand.

Ja. /care. JPEG2000 doet hetzelfde voor JPEG, maar JPEG blijkt gewoon goed genoeg te zijn.

Vaak genoeg dat ik gewoon een filmpje online wilde mikken op m'n eigen site, zonder gelijk de youtube en soortgelijke meuk te moeten gebruiken. Gewoon, een filmpje invoegen zoals je dat normaal met een plaatje kunt doen. Maar dankzij de industrie was dat dus *onmogelijk*. Nu Theora en WebM daar eindelijk eens verandering in brengen grijp ik dat aan. De wat mindere kwaliteit en/of meer data lig ik niet wakker. Voor de grote jongens zal het duurder zijn, maar youtube pompt nu al vrolijk 1080p door dus dataopslag en -transport is schijnbaar zeer, zeer goedkoop.

[Verwijderd]

Maar dankzij de industrie was dat dus *onmogelijk*.

En dat is dus onzin.
Dat kan prima met h.264 en is gewoon gratis.

[Fuzzillogic]

Nee want er is nog steeds geen standaard codec in alle browsers. Enerzijds de onwil van Microsoft en Apple (Theora, WebM), anderszijds de patent- en licentiedruk van h.264 waarvoor Opera en Firefox niet willen betalen.

Er is nu hooguit een work-around door met de video-tag twee formaten aan te bieden, h.264 en vp8/theora. Niet echt ideaal.

[Verwijderd]

JPEG2000 doet hetzelfde voor JPEG, maar JPEG blijkt gewoon goed genoeg te zijn

De hoeveelheid data opslag/traffic in jpeg is een fractie van die van video zodat de bestandsgrootte daar minder relevant is.

Bovendien heeft jpeg2000 geen brede support terwijl h.264 juist door vrijwel iedereen al gebruikt wordt en ook brede ondersteuning kent in hardware.

[Buggle]

VP8 is (zeker technisch gezien) niet 'on-par' met H264 (x264 implementatie, that is). Daarnaast is het nog maar de vraag of VP8 niet tóch patenten schendt. Zie ook hier (Goed, het is een beetje een wij-van-wc-eend, maar het lijken mij gewoon feiten). Ik zie de toekomst zonnig tegemoed als VP8 actief ontwikkeld gaat worden, een grote organisatie als Google erachter zal er in ieder geval voor zorgen dat er voldoende juridische stootkracht is in het geval er toch mensen gaan bitchen over patenten.

[TheGhostInc]

Het grote verschil is het signaal dat de industrie afgeeft.

Als er nu actief een alternatief wordt ontwikkeld, gepromoot en ondersteund dan komen we misschien een keer in de situatie dat partijen minder zullen kiezen voor de gepatenteerde oplossingen.

Patenten hebben best een functie, maar als een industrie standaard ophangt aan een licentiemodel dan weet je zeker dat de grote bedrijven ervan profiteren en de kleine bedrijven er last van hebben. (De grote bedrijven onderhandelen vaak al tijdens de ontwikkeling een gunstige positie)

[Kwastie]

X264 is geen codec maar een H.264 encoder. zie http://en.wikipedia.org/wiki/X264. En h.264 is al redelijk mainstream.

[Reactie gewijzigd door Kwastie op 3 augustus 2024 12:22]

[Verwijderd]

X264 is geen codec maar een H.264 encoder. zie http://en.wikipedia.org/wiki/X264. En h.264 is al redelijk mainstream.

x.264 is wel een codec. Een h.264 encoder is namelijk ook een codec.

Zie http://en.wikipedia.org/wiki/Codec

A codec is a device or computer program capable of encoding and/or decoding a digital data stream or signal

[SoundWave729]

Uh, je mist het punt van Kwastie. Met x264 encode je naar h264. De videostream is gewoon h264 dan, geen x264 en dat maakt x264 geen codec maar een encoder.

[Dreamvoid]

H.264 is de standaard, x264 is de codec (coder/decoder). x264 is 1 van de vele H.264 codecs. Concurrerende codecs zijn oa Quicktime, Nero, MainConcept, LEAD, Dicas, DivX, ProCoder en Elemental.

[Reactie gewijzigd door Dreamvoid op 3 augustus 2024 12:22]

[SoundWave729]

x264 is a free software library and application for encoding video streams into the H.264/MPEG-4 AVC format, and is is released under the terms of the GNU GPL.

Een encoder dus. Lijkt me sterk dat deze mensen het fout hebben.
Bron: http://www.videolan.org/developers/x264.html

[Verwijderd]

je mist het punt van Kwastie... en dat maakt x264 geen codec maar een encoder

Nee, jij mist het punt. Een digitale encoder is per definitie een codec.

[TheGhostInc]

Helaas mis je dan de helft van je Codec

Een codec is een encoder en decoder. Zolang het hier alleen gaat over de X264 encoder heb je dus geen complete codec.

[Verwijderd]

De definitie in wikipedia die ik citeerde is het in ieder geval niet met je eens.

encoding and/or decoding

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 12:22]

[merethan]

Codec is een beetje hetzelfde als Modem.

Modem = Modulator-Demodulator
Codec = Coder-Decoder

[Zsub]

En Wikipedia is foutloos sinds wanneer?

Sorry, maar op deze manier raakt je opmerking kant noch wal.

Bekijk het zo: je biedt als vendor mensen een 'codec' aan volgens die definitie. Daarmee kunnen mensen alleen encoden en niet decoden. Hoeveel mensen denk je dat dat zullen accepteren als een 'volledige' codec? Ik denk erg weinig.

[i-chat]

gelul - denk maar eens aan alle populaire win32 codecs - hoeveel encorders zitten daar tussen, toch noemt iedereen het een codec-pack -

een codec is dus een stukje hard of software dat een video (of audio) stream kan verwerken tot iets dat kan worden afgepeeld, een opgenomen beeld / geluid kan omzetten naar een stream.

in de meeste gevallen overigens, ben je als klant enkel geinteresserd in OF de encoder OF de Decoder. en dus zelden in iets dat beiden kan.

het kan natuurlijk wel zo zijn dat 1 natuurlijke persoon, voor meedere apparaten verschillende dingen wil met het zelfde formaat ... een encoder in z'n camera en een decoder in zijn media speler (en ga zo maar door) ... al zal een encoder in je ipod bijv totaal nutteloos zijn.

[MicGlou]

Iedereen zegt het net weer ff anders, misschien dat dit het duidelijk maakt.

Codec is een afkorting van 'coder-decoder'', waarin in dit geval h264 de codec is. x264 is de encoder die rondom deze codec is opgebouwd om bestanden te encoden. X264 is dus de projectnaam van die encoder die is opgebouwd rondom de h264 codec, uiteindelijk is het af te spelen bestand een h264 bestand en niet een x264. Had men een andere naam voor het project gekozen dan x264, dan was er ook niet zoveel verwarring romdom geweest, zal misschien zelfs een bewuste keuze zijn geweest om exact de reden waarom het nu niet duidelijk is.

Kortom, een encoder en een codec zijn niet hetzelfde, de ene heeft de ander nodig om het werk te doen. h264 is dus op zichzelf géén encoder, maar de codec die de encoder nodig heeft om de bestanden te coderen of te decoderen.

[Reactie gewijzigd door MicGlou op 3 augustus 2024 12:22]

[Korben]

Klopt nog steeds voor geen meter. Een codec is simpelweg een stuk hardware of software wat data kan omzetten van of naar een bepaald formaat. Een encoder is een deel van een codec, het andere deel is een decoder. x264 is een codec voor het H.264 videoformaat, net als MainConcept en Nero Digital.

[MicGlou]

Nee, dat heb je onjuist. Heel simpel gezegd (nogmaals) is de encoder het stukje software wat wordt opgebouwd rond de codec... Jij zegt het dus precies verkeerd om, X264 is een encoder voor de codec die videobestanden omzet naar de h264 codering-standaard, de codec is dus onderdeel van de encoder, niet visa versa.

Om het te projecteren op de eeuwige vergelijking met de auto; zie de codec als een motor. Een motor ansich heb je weinig aan, daar moet een carrosserie, stuur, wielen en remmen omheen gebouwd worden om te kunnen functioneren, die onderdelen zijn dan de vergelijkbaar met de encoder.

Overigens zit het bij hardware decoding weer net even anders, dat kan je niet naast het een software codec zetten.

Deze wiki-pagina is misschien wat duidelijker: http://nl.wikipedia.org/wiki/H.264

Daar staat het allemaal netjes beschreven zonder verwarringen met andere soorten van encoders. decoders en codecs. Ik wil er even 2 zinnetje van aantippen:

H.264, MPEG-4 Part 10 of AVC (Advanced Video Coding) is een digitale video codec, die een zeer sterke compressie van videobeelden nastreeft..... .....De encoder voor H.264/MPEG-4 AVC video streams is het open source pakket x264. Deze toepassingen maken reeds gebruik van de x264 encoder:

[Reactie gewijzigd door MicGlou op 3 augustus 2024 12:22]

[albatross]

Gokje: x264 zal zijn naam waarschijnlijk wel te danken hebben aan de 'x' als programma (= encoder) voor h264, waarbij je 'x' dan moet zien als het UNIX 'executable' file attribuut.

[SinergyX]

Deels. H.264 is de 'compressie methode', MPG4 variant. X.264 kan het afspelen

[Carbon]

X.264 kan het afspelen

Nee, x264 is enkel een encoder die video omzet naar h264

[neeecht]

x264 is een encoder. (Geen decoder dus, en dus ook geen codec.)

x264 krijgt straks wel de mogelijkheid om audio te encoden en decoderen, maar dit gaat dan via ffmpeg, dan is dus ffmpeg de decoder en daar maar x264 dan weer gebruik van.
Voor het afspelen heb je dan een aparte video decoder en een aparte audio decoder nodig.

extra info: ook komt er een "native" .mp4 container als output met x264.
Dan heb je dus: .264(raw)/mkv/mp4/flv als output formaten.

Ik ben blij dat dit nieuws hier is opgepakt, als ik het weer zelf zou insturen voelt het zo opdringerig.

Groeten,
x264.nl

[cdwave]

Ik lees "zijn tot 2015 vrijgesteld " als:

"Na 2015 moet je gaan betalen om de home-videos die je met je H264 camera hebt geschoten aan je familie te laten zien."

Lees de handleiding van je camera maar eens door....

[leuk_he]

Je camera (ik betwijfel of die H264 gebruikt) heeft een licentie voor niet commercieel gebruik. Als jij je "amateur homevideos" opeens gaat verkopen zou je een aandere licentie nodig hebben. Dat zou in 2015 wel eens in de papieren kunnen lopen, maar waarschijnlijk zijn het net zo'n bedrag dat ze vervelend zijn, maar niet onoverkomelijk.

[Verwijderd]

Óf er komen recoders op de markt die het materiaal ombouwt naar, bijvoorbeeld VP8/WebM. Gezien het feit dat ffmpeg dit al ondersteunt moet dat geen probleem zijn.

[Fuzzillogic]

Héél véél camera's gebruiken h.264 tegenwoordig.

[Verwijderd]

Ook dat is onzin want de kans is ten eerste heel groot dat na 20105 on line video sowieso gratis blijft zoals ook nu hetgeval is omdat de betrokken patenthouders geen onredelijke verhogingen van tarieven kunnen doorvoeren van hege hun commitments aan standaardisatieorganisaties.
Maar als er al tarieven komen voor het broadcasten van internet video's dan is er al toegezegd in de licentievoorwaades dat die ongeveer gelijkgesteld aan huidige tarieven voor TV uitzendingen. Dat betekent dus dat alleen hele grote uitzendpartijen die honderduizenden of miljoenen video's verspreiden tarieven zouden moeten betalen, bedrijven dus zoals televisiemaatschappijen die internet televisiekanalen opzetten. Dat zijn trouwens ook partijen die vanwege de veel betere efficientie van h.264 sowieso die codec moeten gebruiken omdat ze anders veel te veel traffic kosten genereren.

Er is dus volstrekt geen sprake van dat individuen of doorsnee websites voor hun video's zouden moeten gaan betalen.
Dat soort broodje aap verhalen worden wel graag gebruikt door 'open' fanatici maar zijn niet gebaseerd op een basis in de realiteit.

[farlane]

Een term als '...de kans is heel groot...gratis...' impliceert dat er nog altijd dat er ook een kleine kans is dat je wel moet betalen. De fanatici hebben dus een punt: de patenthouders/makers zouden garanties moeten geven.

[mbb]

Dus stel dat je moeder was op vakantie en plaatst dat leuke filmpje online voor vrienden - blijkt op de achtergrond net de finish van een groot evenement zichtbaar, en de volgende dag heb je al 2 miljoen hits. Ze denkt, 'leuk' en weet niets van H264, video is video
Tegen de tijd dat ze thuiskomt is het huis alvast inbeslag genomen om de licentliekosten te dekken.

Zal niet veel voorkomen, maar je zal die ene pineut toch zijn. (Zoals die gast die 30 miljoen voor 7 liedjes moest betalen aan de RIAA)

[Dreamvoid]

Ze hebben zich met MP3 en MPEG-2 prima gedragen anders.

[Jasper Janssen]

Zijn er dan werkelijk -- ondanks het GPL karakter van dit stuk software -- maar zo weinig contributors dat ze iedereen (dus ook die patch van het ene +je drie jaar geleden) hierbij om toestemming kunnen vragen en dan nog toestemming kijgen ook?

Met de Linux kernel kun je het gerust vergeten dat er ooit een non-GPL versie van beschikbaar komt. Er zijn zoveel contributors dat het fysiek onmogelijk is, en bovensdien zijn er genoeg daarvan die nooit akkoord zouden gaan.

[Djesko]

En nu maar hopen dat dit opgepikt wordt door Microsoft en dus de Xbox360.

Alleen DivX / XviD support is toch echt wat te summier voor de functie van media center i.m.h.o.

[LeechGuy]

En waarom zou Microsoft willen dat jij je video's met je Xbox 360 gaat encoden? x264 is een encoder en heeft dus niks te maken met een decoder die je nodig hebt om je video's te bekijken.

[Dreamvoid]

Xbox360 doet ook H.264 video hoor...

[morrowyn]

Voorheen was de broncode alleen onder gpl-licentie beschikbaar, waardoor deze niet in gesloten software mocht worden gebruikt.

Volgens mij kan dit juist wel, want GPL is niet besmettelijk zodat ander code ook geGPL'd dienen. Je moet alleen als je aanpassingen aan de GPL'de code maakt, de broncode onder GPL uitbrengen. Dit is een wezenlijk verschil, tussen linken met gpl code en gpl code aanpassen.

Voor de rest, goede zet, deze concurrentie strijd leidt hopelijk tot betere video kwaliteit

[Little Penguin]

Nee, als je code die je ontvangen hebt onder de GPL statisch linkt aan een closed source toepassing moet je de broncode van de gehele toepassing openbaar maken. Als je dat niet doet ben je in overtreding t.o.v. de GPL.

Waar jij op doelt is de LGPL - als je die gebruikt hoef je de broncode van het totaalproduct niet (per definitie) openbaar te maken...

[morrowyn]

Ok, bij static linken, maar dan link je hem lekker dynamic, geen probleem dan, lijkt me

edit: oh wait, na het lezen van gpl is het inderdaad zo, dat het gehele software product dan onder de GPL moet vallen.

[Reactie gewijzigd door morrowyn op 3 augustus 2024 12:22]