Werkgroep stelt eerste draft op voor hevc-codec
Er is een draft opgesteld voor de High Efficiency Video Coding-codec. Deze codec, die ook wel h.265 wordt genoemd, zou een betere videokwaliteit weten te behalen bij een gelijkblijvende bitrate en tot twee maal betere compressie bieden dan h.264.
De ISO/IEC Moving Picture Experts Group en de ITU-T Video Coding Experts Group hebben samen in het Joint Collaborative Team on Video Coding de draft opgesteld. De codec moet de veelgebruikte h.264-codec gaan opvolgen. Er zijn diverse algoritmen toegevoegd om de beeldkwaliteit te verbeteren. Hevc zou onder andere toegepast kunnen worden voor ultra-hdtv dat een resolutie heeft van 7680x4320 pixels, maar vergt door de toegenomen complexiteit wel meer processorkracht bij het decoderen.
Gedurende het ontwikkelproces van de nieuwe codec moet de nieuwe Joint Collaborative Team on Video Coding-werkgroep enkele drafts opstellen van de specificatie. Met het aannemen van de committee draft is daar nu een belangrijke mijlpaal behaald. Volgens de planning moet de definitieve hevc-standaard in januari 2013 klaar zijn om daarna geratificeerd te kunnen worden als een officiële standaard.
Reacties (44)
Dat betekend dus indirect dat ook Hardware Accelerated chips (zoals de Broadcom Crystal HD) sneller moeten worden of betekend het alleen dat een normale pc er meer moeite mee zou hebben? Ik snap dat de chip sneller moet zijn, maar of hij ook complexer moet zijn?Hevc zou onder andere toegepast kunnen worden voor ultra-hdtv dat een resolutie heeft van 7680 x 4320 pixels, maar vergt door de toegenomen complexiteit wel meer processorkracht bij het decoderen.
[Reactie gewijzigd door FireDrunk op donderdag 9 februari 2012 17:38]
Het betekend gewoon dat je datastroom nog redelijk binnen de beperkingen blijft met als nadeel dat je wel meer rekenkracht nodig hebt voor het decoderen van de video stream.
Iets wat momenteel niet zo veel uitmaakt omdat dit met de huidige technologie prima mogelijk is.
Een paar jaar geleden zou deze resolutie niet kunnen omdat de benodigde bandbreedte en doening snelheid nog niet voorhanden was ( en voor sommige mensen nog steeds is, ikzelf zet op een 2.2Mbit verbinding).
Iets wat momenteel niet zo veel uitmaakt omdat dit met de huidige technologie prima mogelijk is.
Een paar jaar geleden zou deze resolutie niet kunnen omdat de benodigde bandbreedte en doening snelheid nog niet voorhanden was ( en voor sommige mensen nog steeds is, ikzelf zet op een 2.2Mbit verbinding).
De huidige BR standaard geeft voor 36Mbit/s doorvoer, dat zou beteken dat men 36 / 2 = 18 x 16 = 288Mbit/s = 36Mbyte/s aan bandbreedte nodig hebt.
Dat zijn/zouden de maximale door voeren zijn, aan de hand van de uitspraken.
Als ik zelf een BR re-encode, kom ik met maximale compressie, en nagenoeg geen kwaltijdsverlies, uit op 3Mbit/s, dit is wel een langdurig proces, daar ik alle instelling in Handbreak op maximale kwaliteit heb staan.
Waar je bij een normale 2 pass video encoding ongeveer een uur nodig zou hebben, heb ik wel +4 uur nodig, voor de veel diepere analyseren van de video data.
En door de hogere compressie, kunnen mijn video's niet meer worden afgespeeld op de meeste Mediaspelers, en zijn dus eigenlijk alleen nog geschikt voor HTPCs.
Ik vraag me alleen af wat CPU men voor deze codec nodig hebt, en een hogere compressie is altijd welkom, maar waar een een AMD A50M Fusion, meer dan voldoende is voor afspelen van alle huidige codec's, hoop ik dat het ook mogelijk blijft met deze nieuwe codec.
Want zelfs een nieuwe budget kaartje (zo iets als de HD6450) hardwarematig het kan zal het een probleem zijn voor de x.265 variant om hardware support te krijgen.
Tenzij tegen die tijd OpenCL ver genoeg is gevorderd, en mogelijk om het te gebruiken op Fusion CPUs, en budget GPUs/
Dat zijn/zouden de maximale door voeren zijn, aan de hand van de uitspraken.
Als ik zelf een BR re-encode, kom ik met maximale compressie, en nagenoeg geen kwaltijdsverlies, uit op 3Mbit/s, dit is wel een langdurig proces, daar ik alle instelling in Handbreak op maximale kwaliteit heb staan.
Waar je bij een normale 2 pass video encoding ongeveer een uur nodig zou hebben, heb ik wel +4 uur nodig, voor de veel diepere analyseren van de video data.
En door de hogere compressie, kunnen mijn video's niet meer worden afgespeeld op de meeste Mediaspelers, en zijn dus eigenlijk alleen nog geschikt voor HTPCs.
Ik vraag me alleen af wat CPU men voor deze codec nodig hebt, en een hogere compressie is altijd welkom, maar waar een een AMD A50M Fusion, meer dan voldoende is voor afspelen van alle huidige codec's, hoop ik dat het ook mogelijk blijft met deze nieuwe codec.
Want zelfs een nieuwe budget kaartje (zo iets als de HD6450) hardwarematig het kan zal het een probleem zijn voor de x.265 variant om hardware support te krijgen.
Tenzij tegen die tijd OpenCL ver genoeg is gevorderd, en mogelijk om het te gebruiken op Fusion CPUs, en budget GPUs/
[Reactie gewijzigd door player-x op donderdag 9 februari 2012 18:53]
Het zal nog wel een paar jaar duren voor deze standaard ook in praktijk gebruikt wordt. Tegen die tijd is zo'n fusion toch wel aan vervanging toe.
Ik probeer dit te begrijpen, maar ik snap niet hoe je komt aan 36 / 2 = 18 * 16.De huidige BR standaard geeft voor 36Mbit/s doorvoer, dat zou beteken dat men 36 / 2 = 18 x 16 = 288Mbit/s = 36Mbyte/s aan bandbreedte nodig hebt.
Dat zijn/zouden de maximale door voeren zijn, aan de hand van de uitspraken.
Wiskunde protesteerd bij mij.
Een BR word nu met max 36Mbit/s gecodeerd, als die zelfde BR met h.265 word gecodeerd zou dat een vermindering van 50% aan data zijn voor de zelfde kwaliteit, hens de 36Mbit/s / 2 = 18Mbit/s
Daar naast is het beeldresolutie vergroot met 4x zo breed en 4x hoog, dan heb je 4 x 4 = 16, dat is met 4320p heb je 16x de megapixels van 1080p.
En dan kom je dus uit op 18Mbit/s x 16 = 288Mbit/s
Daar naast is het beeldresolutie vergroot met 4x zo breed en 4x hoog, dan heb je 4 x 4 = 16, dat is met 4320p heb je 16x de megapixels van 1080p.
En dan kom je dus uit op 18Mbit/s x 16 = 288Mbit/s
1. wanneer je de resolutie verdubbelt in beide assen (of dus 4x zoveel pixels hebt) heb je maar 3x zoveel bandbreedte nodig voor hetzelfde resultaat. Nu is dat nog steeds veel 
.
2. Maximale kwaliteit? Enkele verbeteringen: kies Uneven multi-hexagon ipv hexagon (beperkte winst), kies 16 ref frames ipv 6 (weinig winst), idem voor de b-frames (redelijke winst). Jouw settings zijn niet zo optimaal als je de tijd toch wat wil beperken en de kwaliteit heel hoog wil. Meer dan 5 ref frames zijn niet nuttig en ME 10 is ook niet nuttig, neem 7 of eventueel 9.
3. Wat voor een bak heb jij dat je een bluray aan die settings op 4u kan encoden (ik ga dan even uit van een film van gemiddelde lengte)?
.2. Maximale kwaliteit? Enkele verbeteringen: kies Uneven multi-hexagon ipv hexagon (beperkte winst), kies 16 ref frames ipv 6 (weinig winst), idem voor de b-frames (redelijke winst). Jouw settings zijn niet zo optimaal als je de tijd toch wat wil beperken en de kwaliteit heel hoog wil. Meer dan 5 ref frames zijn niet nuttig en ME 10 is ook niet nuttig, neem 7 of eventueel 9.
3. Wat voor een bak heb jij dat je een bluray aan die settings op 4u kan encoden (ik ga dan even uit van een film van gemiddelde lengte)?
Het gaat er niet om alleen om of het technisch mogelijk is, maar ook wat de kosten zijn om de technische oplossing te implementeren.Iets wat momenteel niet zo veel uitmaakt omdat dit met de huidige technologie prima mogelijk is.
Hardwarematig decoderen van H264 L5.1 heeft een behoorlijke tijd geduurd (word nog steeds niet op alle chips ondersteund) omdat de hoeveelheid geheugen die ervoor nodig was de oplossingen te prijzig maakte.
Het probleem van toegenomen rekenkracht gaat wel spelen in de CCTV markt waar je al meerdere video streams tegelijkertijd ziet lopen.
Eerst was er al een hype op h.264 maar men merkt nu al snel dat als je 16 h.264 streams tegelijkertijd hebt lopen de client PC's het aardig zwaar beginnen te krijgen.
Men blijft nog hangen op MPEG4 en gebruikt h.264 daar waar nodig (HD cameras)
Voor de CCTV markt zie ik weinig heil voor h.265, behalve voor gebruik bij megapixel camera's (1080+). Misschien als de (nog) PC's krachtiger worden.
Eerst was er al een hype op h.264 maar men merkt nu al snel dat als je 16 h.264 streams tegelijkertijd hebt lopen de client PC's het aardig zwaar beginnen te krijgen.
Men blijft nog hangen op MPEG4 en gebruikt h.264 daar waar nodig (HD cameras)
Voor de CCTV markt zie ik weinig heil voor h.265, behalve voor gebruik bij megapixel camera's (1080+). Misschien als de (nog) PC's krachtiger worden.
Die hardware decoders zijn fixed function, oftewel met een nieuwe codec kunnen ze helemaal niets beginnen. Maar het zal nog wel een hele tijd duren voordat h.265 veel gebruikt gaat worden. De eerste versie van h.264 komt uit 2003, terwijl het pas vanaf +/- 2006 op redelijke schaal werd gebruikt.
Eindelijk de eerste voorbereidingen voor ultra HD zitten er aan te komen nu alleen nog even een tablet en een telefoon die deze resoluties ondersteunen
Meest briljante reactie tot nu toe. Vind al dat HD gebeuren op telefoonschermpjes van 3,4 inch ook onzin. Mensen willen hogere resoluties alleen weten niet waarom. Enige 'echte' verbetering die ik de laatste tijd gezien heb op telefoon schermen is de retina dpi. Dat is echt fijn!
eerst vind je een hoge resolutie (HD) onzin en vervolgens gebruik je de retina schermpjes als voorbeeld van de enige verbetering van de laatste tijd? Mis ik iets of spreek je jezelf tegen.
Alleen zijn er ook mobieltjes en tablets die een HDMI poort hebben om 1080p over te gooien. Verder zijn er al telefoons van 5", dus wie weet hebben we binnenkort mobieltjes met 1080p schermen. Ik zou zeggen, kijk eens over de muren van je afgeschermde tuin, voordat je ander mensen begint af te zeiken. http://www.electronista.c...vs.retina.display.326ppi/
Zo ben ik aan het kijken of ik een tablet kan vinden die als mediaplayer kan dienen. In theorie mag het scherm zelf 800*480 zijn, zolang hij maar wel netjes 1080p over de HDMI poort gooit.
Zo ben ik aan het kijken of ik een tablet kan vinden die als mediaplayer kan dienen. In theorie mag het scherm zelf 800*480 zijn, zolang hij maar wel netjes 1080p over de HDMI poort gooit.
Makkelijke keus: de Blackberry Playbook heeft 1024x600 resolutie en een HDMI poort en ondersteunt 1080p zowel in film opnames als afspelen via HDMI. Voor 200 euro echt een superkoopje.Zo ben ik aan het kijken of ik een tablet kan vinden die als mediaplayer kan dienen. In theorie mag het scherm zelf 800*480 zijn, zolang hij maar wel netjes 1080p over de HDMI poort gooit.
Ik ben er zelf heel tevreden over. De kwaliteit is state of the art en de appstore groeit boven verwachting snel (nu als 60.000 apps). Deze maand komt OS v. 2.0 uit met Android player en dan zal het aantal apps nog sneller groeien. Maar het mooiste vind ik toch de uitmuntende hardware. Je kan er echt stottervrij hoge resolutie opnames mee maken.
Heb je een Blackberry phone dan kan je blackberry playbook op afstand bedienen, waardoor je hem als media player kan gebruiken.
Ik neem hem graag me op reis, waar ik hem zelf het meest voor gebruik is echter als video telefoon. Verschillende mensen bij ons in de familie hebben er nu een gekocht en hij is druk in gebruik. je kunt hem namelijk standby zetten en dan kunnen anderen je nog steeds bellen en kan je direct een gesprek beginnen. Het heeft bij ons in de familie Google talk een beetje vervangen omdat je niet achter de computer meer hoeft te zitten. In v.2.0 zal het ook mogelijk zijn om te zien wie er allemaal on line is.
[Reactie gewijzigd door Magalaan op donderdag 9 februari 2012 20:19]
Ik heb al een Archos 80, maar die is niet krachtig genoeg om alle 1080p content af te spelen. Volgens mij is de Playbook net zo snel en dus te langzaam voor mij. Verder heb ik een Android mobieltje, dus die Playbook is dan helemaal niet handig. Archos heeft natuurlijk wel een remote app voor Android.
HDMI poort heb je waarschijnlijk niet meer nodig, daar is immers MHL voor uitgevonden zodat het gewoon via "standaard" USB kan, terwijl de tablet / smartfoon ook nog opgeladen wordt.
MHL gebruikt nog steeds HDMI. De huidige implementaties gebruiken USB voor het opladen en data en HDMI voor beeld en geluid. Even je huiswerk doen.
MHL op Wikipedia:
"Other than the connectors being used, no USB nor HDMI technology is being used. It is exclusively MHL signalling through the connectors and over the cable."
Misschien zelf huiswerk doen?
"Other than the connectors being used, no USB nor HDMI technology is being used. It is exclusively MHL signalling through the connectors and over the cable."
Misschien zelf huiswerk doen?
Van de meeste briljante naar een meest geniale post! Heerlijk, ik heb genoten.
"Retina" op 4,3" houd als HD-ready beeld in.
"Retina" op 4,3" houd als HD-ready beeld in.
betekent dit dan dat een file van 4.2 gig h.264
na omvorming nog maar 2.1gig h.265
na omvorming nog maar 2.1gig h.265
"betekent dit dan dat een file van 4.2 gig h.264 na omvorming nog maar 2.1gig h.265"
Dit staat in princiepe zo
Dit staat in princiepe zo
Dus maximaal 2 maal betere compressie tov h.264en tot twee maal betere compressie bieden dan h.264.
Zo lees ik dat ook inderdaad maar dat zou imho wel bizar zijn.
Ik tref regelmatig video materiaal waarbij men 720P video in een file van 700 MB propt en er nog mee wegkomt ook. Als dat nog twee keer zo goed kan zou je dus wellicht zelfs een 1080P film op een CD kunnen persen.
Zo bezien had Toshiba eigenlijk groot gelijk met HDDVD: 15GB is eigenlijk wel zat voor een film.
Ik tref regelmatig video materiaal waarbij men 720P video in een file van 700 MB propt en er nog mee wegkomt ook. Als dat nog twee keer zo goed kan zou je dus wellicht zelfs een 1080P film op een CD kunnen persen.
Zo bezien had Toshiba eigenlijk groot gelijk met HDDVD: 15GB is eigenlijk wel zat voor een film.
Dat dacht microsoft voor de Xbox 360 games ook van DVD's... Maar daarmee hebben ze zichzelf ook wel een beetje in de voet geschoten.
Dan moet je toch echt eens een bril opzetten, of op een normaal formaat display kijken, want 720p in 700MB is gewoon dikke vette RUK..
De meeste van mijn foto's proppen makkelijk 1080p in minder dan 10MB, zonder zichtbaar kwaliteitsverlies, zelfs voor pixeln..kers. 
m.a.w. het maakt nogal uit hoeveel frames je wil coderen.
m.a.w. het maakt nogal uit hoeveel frames je wil coderen.
'beter' kan ook sneller betekenen. Of bepaalde maxima of minima. Ergo, een vrij nutteloze uitspraak.
Ben benieuwd naar de exacte specs. Zou geweldig zijn als het ook bij de huidige resoluties een verbetering zou opleveren, maar de kans is dat het pas bij hoge resoluties echt heel effectief wordt, wat je bij H264 nu ook al ziet (maar waar het effect nog beperkt is).
Ben benieuwd of er ook vanuit de open-source kant (WebM) wordt gekeken naar een alternatief. Dat kan een serieuze bedreiging worden voor corporate codec bouwers. Wel gok ik dat die laatste om die reden ook deze codec gratis zullen houden voor internetgebruik, zoals nu ook bij H264 het geval is.
Ben benieuwd of er ook vanuit de open-source kant (WebM) wordt gekeken naar een alternatief. Dat kan een serieuze bedreiging worden voor corporate codec bouwers. Wel gok ik dat die laatste om die reden ook deze codec gratis zullen houden voor internetgebruik, zoals nu ook bij H264 het geval is.
ook een leuke - hoeveel pattenten gaat deze standaard omvatten (anders gezegd: hoeveel moet je er schenden om er gebruik van te maken...
Je hoeft helmaal geen enkel patent te scheden om er gebruik van de maken als je een licentie neemt, zoals dat gewoon hoort...
Leuk, dus open source software kan het wel weer vergeten (tenzij er een groot bedrijf achter zit).
Dat zit allemaal een heel stuk complexer vandaag de dag:
-Ten eerste worden decoders vandaag de dag voor mobiele toepassingen meestal ingebakken in hardware. Bijvoorbeeld in de IVA van TI's OMAP SoC.
Dit geld zowel voor H.264 als in toenemende mate voor VP8 (Google's WebM). Dus degene die de hardware levert, moet de licenties betalen. Vervolgens maakt de hardware een of andere interface beschikbaar voor de software.
Dus de tijden dat Open Source software geen gesloten gepatenteerde video-formaten konden weergeven zonder 'ugly'-softwarevergaarbak zijn achter ons, hardwarebouwers regelen dat vandaag de dag - voor mobiele apparaten althans. Voor desktops biedt de ugly-bak nog wel uitkomst, omdat individuele gebruikers momenteel niet actief vervolgd worden.
-Ten tweede heeft de 'h.264'-lobby er altijd mee geschermd dat betaalde h.264 implementaties - zoals die van Microsoft - zogenaamd 'veilig' waren omdat de leverancier niet aangeklaagd werd voor patenten - die had er immers een licentie op.
Er werd door dezelfde lobby (ook hier op Tweakers aanwezig ) op gewezen dat de 'legale' status van Theora / WebM minder zeker was, omdat die ieder moment aangeklaagd konden worden voor 'inbreuk' op de patenten die in de h.264-'pool' zaten.
Niets is echter minder waar gebleken, en waar ik al jaren voor waarschuw is gebeurd: Microsoft is alsnog keihard aangeklaagd voor verkoop van haar h.264 implementatie, en wel voor het gebruik van Motorola-technologie waarop ze dachten al een licentie te hebben. Motorola eist nu 2.25% van de verkoopprijs van Windows, en nu zijn Apple en Microsoft allicht nogal boos, omdat ze dachten dat er 'FRAND' gold, dus dat Motorola licenties moest verstrekken tegen 'eerlijke' prijzen. Over die eerlijke prijzen is nu een hoop onenigheid, en nota bene de grootste patent-agressievelivg aller tijden (Apple dus) doet momenteel hele dikke boehoe dat het niet eerlijk is dat anderen hun patenten nu willen uitmelken ten koste van Apple.
Wat potentieel een super grappige situatie oplevert:
-Vorig jaar nog deed Google dikke boehoe over hoe het niet eerlijk was dat grote bedrijven voor h.264 moest betalen en kwamen ze met het 'gratis' WebM,
-Microsoft begon kleine bedrijfjes 'af te persen' om toch vooral 10 dollar te schuiven voor ieder Android / Linux-met-FAT-bestandssysteem apparaat dat verkocht werd, dus voor ieder "Google Android" apparaat dat wordt verkocht krijgt MSFT geld,
-Google's toekomstige dochterbedrijf Motorola begint Microsoft en Apple 'af te persen' om te betalen voor 'essentiele standaard' patenten, waaronder 3G/WiFi en h.264, zodat Apple en MSFT straks aan Google mogen betalen voor iedere verkochte Lumia / iPhone. En Google doet niet langer dikke boehoe over dat ze voor h.264 moeten betalen, want andere bedrijven gaan nu (mogelijk) voor h.264 aan Google betalen... Heerlijk consistent Google!
Maw: Het hele circus is nu compleet, MSFT, CSCO en AAPL lopen te lobbyen dat 3G en h.264 licenties (waar ze zelf geld op verdienen!) toch vooral onder eerlijke prijzen moeten worden verkocht - maar lopen wel zelf flink te cashen op hun patenten, en AAPL probeert met haar 'essentieel ontwerppatent' iedere vierkante tablet met vlak beeldscherm van de concurrentie uit de winkel te vegen. Google ondertussen liep WebM te pushen als h.264 alternatief, maar verdient door overname van Motorola juist ook op h.264, dus mogelijk proberen ze h.264 zo duur te maken om het uit de markt te prijzen, zodat WebM weer de goedkoper oplossing wordt.
Uiteindelijk draait de consument op voor al die onzin en dat geschuif met geld, maar die support voor videoformaten wordt toch wel ingebakken in de hardware. En dat is overigens de eigen schuld van diezelfde consument, hadden ze maar massaal moeten klagen tégen software-patenten, op dezelfde manier waarop ze lopen te klagen tegen ACTA/SOPA/PIPA.
Voor degenen die op de hoogte willen blijven van de snelle ontwikkelingen in de MSFT/AAPL boehoe-soap waarin ze niet te veel willen betalen voor software-essentiele patenten, maar zelf wel andere bedrijven uit de markt willen drukken / willen uitmelken / afpersen met hun eigen patentportfolio's (lekker hypocriet!), zie FOSS PATENTS.
-Ten eerste worden decoders vandaag de dag voor mobiele toepassingen meestal ingebakken in hardware. Bijvoorbeeld in de IVA van TI's OMAP SoC.
Dit geld zowel voor H.264 als in toenemende mate voor VP8 (Google's WebM). Dus degene die de hardware levert, moet de licenties betalen. Vervolgens maakt de hardware een of andere interface beschikbaar voor de software.
Dus de tijden dat Open Source software geen gesloten gepatenteerde video-formaten konden weergeven zonder 'ugly'-softwarevergaarbak zijn achter ons, hardwarebouwers regelen dat vandaag de dag - voor mobiele apparaten althans. Voor desktops biedt de ugly-bak nog wel uitkomst, omdat individuele gebruikers momenteel niet actief vervolgd worden.
-Ten tweede heeft de 'h.264'-lobby er altijd mee geschermd dat betaalde h.264 implementaties - zoals die van Microsoft - zogenaamd 'veilig' waren omdat de leverancier niet aangeklaagd werd voor patenten - die had er immers een licentie op.
Er werd door dezelfde lobby (ook hier op Tweakers aanwezig
) op gewezen dat de 'legale' status van Theora / WebM minder zeker was, omdat die ieder moment aangeklaagd konden worden voor 'inbreuk' op de patenten die in de h.264-'pool' zaten.Niets is echter minder waar gebleken, en waar ik al jaren voor waarschuw is gebeurd: Microsoft is alsnog keihard aangeklaagd voor verkoop van haar h.264 implementatie, en wel voor het gebruik van Motorola-technologie waarop ze dachten al een licentie te hebben. Motorola eist nu 2.25% van de verkoopprijs van Windows, en nu zijn Apple en Microsoft allicht nogal boos, omdat ze dachten dat er 'FRAND' gold, dus dat Motorola licenties moest verstrekken tegen 'eerlijke' prijzen. Over die eerlijke prijzen is nu een hoop onenigheid, en nota bene de grootste patent-agressievelivg aller tijden (Apple dus) doet momenteel hele dikke boehoe dat het niet eerlijk is dat anderen hun patenten nu willen uitmelken ten koste van Apple.
Wat potentieel een super grappige situatie oplevert:
-Vorig jaar nog deed Google dikke boehoe over hoe het niet eerlijk was dat grote bedrijven voor h.264 moest betalen en kwamen ze met het 'gratis' WebM,
-Microsoft begon kleine bedrijfjes 'af te persen' om toch vooral 10 dollar te schuiven voor ieder Android / Linux-met-FAT-bestandssysteem apparaat dat verkocht werd, dus voor ieder "Google Android" apparaat dat wordt verkocht krijgt MSFT geld,
-Google's toekomstige dochterbedrijf Motorola begint Microsoft en Apple 'af te persen' om te betalen voor 'essentiele standaard' patenten, waaronder 3G/WiFi en h.264, zodat Apple en MSFT straks aan Google mogen betalen voor iedere verkochte Lumia / iPhone. En Google doet niet langer dikke boehoe over dat ze voor h.264 moeten betalen, want andere bedrijven gaan nu (mogelijk) voor h.264 aan Google betalen... Heerlijk consistent Google!
Maw: Het hele circus is nu compleet, MSFT, CSCO en AAPL lopen te lobbyen dat 3G en h.264 licenties (waar ze zelf geld op verdienen!) toch vooral onder eerlijke prijzen moeten worden verkocht - maar lopen wel zelf flink te cashen op hun patenten, en AAPL probeert met haar 'essentieel ontwerppatent' iedere vierkante tablet met vlak beeldscherm van de concurrentie uit de winkel te vegen. Google ondertussen liep WebM te pushen als h.264 alternatief, maar verdient door overname van Motorola juist ook op h.264, dus mogelijk proberen ze h.264 zo duur te maken om het uit de markt te prijzen, zodat WebM weer de goedkoper oplossing wordt.
Uiteindelijk draait de consument op voor al die onzin en dat geschuif met geld, maar die support voor videoformaten wordt toch wel ingebakken in de hardware. En dat is overigens de eigen schuld van diezelfde consument, hadden ze maar massaal moeten klagen tégen software-patenten, op dezelfde manier waarop ze lopen te klagen tegen ACTA/SOPA/PIPA.
Voor degenen die op de hoogte willen blijven van de snelle ontwikkelingen in de MSFT/AAPL boehoe-soap waarin ze niet te veel willen betalen voor software-essentiele patenten, maar zelf wel andere bedrijven uit de markt willen drukken / willen uitmelken / afpersen met hun eigen patentportfolio's (lekker hypocriet!), zie FOSS PATENTS.
[Reactie gewijzigd door kidde op donderdag 9 februari 2012 22:08]
Voorlopig moet er eerst maar eens ondersteuning komen voor Hi10P (10-bit H.264), dat scheelt al ladingen aan schijfruimte en heeft een iets betere beeldkwaliteit dan 'gewone' H.264.
Ook is het zo dat er genoeg computers zijn die tegenwoordig nog niet eens 8-bit H.264 kunnen afspelen, dus meer moeite hebben met 10-bit, en waarschijnlijk zal H.265 dus ook nauwelijks af te spelen zijn met C2D's bijvoorbeeld gok ik zo omdat Hi10P bij mij al op de 90% CPU zit.
Ook is het zo dat er genoeg computers zijn die tegenwoordig nog niet eens 8-bit H.264 kunnen afspelen, dus meer moeite hebben met 10-bit, en waarschijnlijk zal H.265 dus ook nauwelijks af te spelen zijn met C2D's bijvoorbeeld gok ik zo omdat Hi10P bij mij al op de 90% CPU zit.
Zolang geen 1 mediaplayer en of tv dit ondersteunt heeft het voorlopig dus nog nut on 10bit teondersteunen, en voor die paar mb's hoef je het ook niet telaten.
Die ondersteuning is er al bij meerdere mediaspelers. De anime fansubbing lijkt koploper te zijn met betrekking tot de adoptie ervan. Ik heb al diverse bestanden in Hi10P gekeken, in zowel mediaplayer classics met de codecs van het cccp als ook in potplayer. Dacht dat VLC het ook ondersteunde.
@Xthemes.us
Inderdaad, anders had ik er waarschijnlijk ook nog nooit van gehoord als ik geen anime keek. Het scheelt echt behoorlijk veel in schijfruimte, zeker als je hele seizoenen van series en films hebt.
@devil-strike
Dat is waar, maar net zoals bij alle standaarden, als er niemand komt die het gaat ondersteunen, zal de rest het ook niet gaan doen.
Inderdaad, anders had ik er waarschijnlijk ook nog nooit van gehoord als ik geen anime keek. Het scheelt echt behoorlijk veel in schijfruimte, zeker als je hele seizoenen van series en films hebt.
@devil-strike
Dat is waar, maar net zoals bij alle standaarden, als er niemand komt die het gaat ondersteunen, zal de rest het ook niet gaan doen.
Nog een paar jaar en de vinding van Jan Sloot wordt toch nog werkelijkheid....
Nou goed, daar geloof ik eigenlijk niet in, maar betere video compressie is wel de sleutel tot bruikbare hoogwaardigere video kwaliteit.
Computerpower hebben we voldoende (en anders hebben we dat binnenkort). Prima dus dat er mensen zijn die nog knappere algoritmes kunnen maken en h.264 files nog eens kunnen halveren.
Met toekomstige standaarden zoals Ultra HD zullen we dat hard nodig hebben, vermelde ruwe bandbreedte is 24 Gb/s http://en.wikipedia.org/w...igh_Definition_Television
Hebben we dat nodig dan? Ja, wel als je in de bios een significant hogere kwaliteit wilt ervaren dan nu mogelijk. Uiteindelijk ook thuis, waar je in je woonkamertje met een tv van 2 meter diagonaal een immersive experience ondergaat. Ook bij nadere bestudering van het beeld blijft de illusie intact.
De eerder deze week aangekondigde Nikon D800 heeft een foto resolutie die bijna 1:1 overeenkomt met UHD. Over 5 jaar film je dit met een betaalbare camera, en over 10 jaar zit dit in de Galaxy S XII ofzo.
Nou goed, daar geloof ik eigenlijk niet in, maar betere video compressie is wel de sleutel tot bruikbare hoogwaardigere video kwaliteit.
Computerpower hebben we voldoende (en anders hebben we dat binnenkort). Prima dus dat er mensen zijn die nog knappere algoritmes kunnen maken en h.264 files nog eens kunnen halveren.
Met toekomstige standaarden zoals Ultra HD zullen we dat hard nodig hebben, vermelde ruwe bandbreedte is 24 Gb/s http://en.wikipedia.org/w...igh_Definition_Television
Hebben we dat nodig dan? Ja, wel als je in de bios een significant hogere kwaliteit wilt ervaren dan nu mogelijk. Uiteindelijk ook thuis, waar je in je woonkamertje met een tv van 2 meter diagonaal een immersive experience ondergaat. Ook bij nadere bestudering van het beeld blijft de illusie intact.
De eerder deze week aangekondigde Nikon D800 heeft een foto resolutie die bijna 1:1 overeenkomt met UHD. Over 5 jaar film je dit met een betaalbare camera, en over 10 jaar zit dit in de Galaxy S XII ofzo.
Leuk dat ze 7680 x 4320 'Ultra HDTV' noemen, de resolutie komt enigszins overeen met de kwaliteit van analoge film waar we in de bioscoop vroeger naar keken.
De claim dat deze h.265 codec 2x zo efficiënt is moet ik nog wel eerst zien. Ditzelfde werd namelijk al eens vaker geclaimed bij de overgang van MPG2 (DVD) naar MPG4 (XviD/DivX) en zelfs tussen MPG4 en MPG4-AVC (h.264) werden fors kleinere bestanden beloofd.
In mijn ogen zijn de overgangen van MPG1->MPG2->MPG4 enorm geweest maar is de rek er nu grotendeels wel uit. Twee keer hogere compressie dan h.264 lijkt mij zeer sterk, 10% zou nog wel kunnen en zou ik al heel blij mee zijn (zonder kwaliteitsverlies). Laten we eerst maar eens de testen afwachten. Ik doe dit al lang, sinds de eerste CDi-video uitkwam zo'n beetje.
Oh, enneh, niet zeggen dat Xvid bagger is, die mensen vergelijken altijd 700MB films van 90 minuten met de originele DVD van 4GB MPG2 (en de videostream is dan 30% van het origineel..).
De claim dat deze h.265 codec 2x zo efficiënt is moet ik nog wel eerst zien. Ditzelfde werd namelijk al eens vaker geclaimed bij de overgang van MPG2 (DVD) naar MPG4 (XviD/DivX) en zelfs tussen MPG4 en MPG4-AVC (h.264) werden fors kleinere bestanden beloofd.
In mijn ogen zijn de overgangen van MPG1->MPG2->MPG4 enorm geweest maar is de rek er nu grotendeels wel uit. Twee keer hogere compressie dan h.264 lijkt mij zeer sterk, 10% zou nog wel kunnen en zou ik al heel blij mee zijn (zonder kwaliteitsverlies). Laten we eerst maar eens de testen afwachten. Ik doe dit al lang, sinds de eerste CDi-video uitkwam zo'n beetje.
Oh, enneh, niet zeggen dat Xvid bagger is, die mensen vergelijken altijd 700MB films van 90 minuten met de originele DVD van 4GB MPG2 (en de videostream is dan 30% van het origineel..).
Ik moet daar ook nog vaak aan terugdenken. Philips had toen een serieus probleem. Het lukte eigenlijk niet om een standard definition film op een CD te persen zonder zichtbaar kwaliteitsverlies.sinds de eerste CDi-video
Met h.264 kun je DVD's er zonder merkbaar kwaliteitsverlies op proppen en zelfs HD video (wel 'maar' 720P) kun je er op kwijt mits het films zijn die niet te lang duren en zich goed lenen voor wat zwaardere compressie. Denk aan animatiefilms als Ice Age.
De processors waren er toen nog niet klaar voor (H.264 decoden zou niet in real-time hebben gekund), anders was het misschien heel anders gelopen met CDi...
Ik geloof niet dat de bestanden kleiner gaan worden. We zullen de kwaliteit wel weer verder gaan opschroeven. H264 is onder eigenlijk alle omstandigheden efficienter dan XViD. Toch zijn in praktijk de H264 bestanden meestal groter. Je krijgt daar veel voor terug (hogere resolutie, hogere bitrate, meerdere audiotracks, surround, etc) maar uiteindelijk is het bestand groter.
Dat is natuurlijk geen probleem, HD's zijn groter geworden en internet-verbindingen sneller.
Voordat we een auto hadden waren we ook iedere dag een uur kwijt met reizen. Nu reizen we verder, niet korter.
Dat is natuurlijk geen probleem, HD's zijn groter geworden en internet-verbindingen sneller.
Voordat we een auto hadden waren we ook iedere dag een uur kwijt met reizen. Nu reizen we verder, niet korter.
Ze worden kleiner, voor de target resolutie en kwaliteit waarvoor de codec is ontwikkeld. Voor HEVC is dat 3k-4k in verticale resolutie, voor H264 was dat 1k-2k in verticale resolutie, voor MPEG-2 was dat DVD kwaliteit (720x576@25fps of 720x480@30fps) en voor MPEG-1 was dat postzegel-resolutie.De claim dat deze h.265 codec 2x zo efficiënt is moet ik nog wel eerst zien. Ditzelfde werd namelijk al eens vaker geclaimed bij de overgang van MPG2 (DVD) naar MPG4 (XviD/DivX) en zelfs tussen MPG4 en MPG4-AVC (h.264) werden fors kleinere bestanden beloofd.
In mijn ogen zijn de overgangen van MPG1->MPG2->MPG4 enorm geweest maar is de rek er nu grotendeels wel uit.
M.a.w., als ik een H264 op 3k-4k verticale resolutie encodeer, wordt 't een gigantische troep, omdat de codec daarvoor niet bedoeld is, en HEVC doet dat duidelijk beter (up to 2x). De opvolger van HEVC zal voor verticale resolutie 6k-8k bedoeld zijn en zal dat, vergeleken met HEVC, ook weer 2x zo goed doen, simpelweg omdat HEVC daarvoor niet bedoeld is en daarvoor dus niet optimaal ontwikkeld is voor dat doel.
Oh, je wilt weten hoe goed HEVC standaard postzegel-video (lage resolutie Youtube) comprimeert? Ongeveer net zo goed als H264, misschien 5%-10% beter gemiddeld (i.e. zelfde kwaliteit kost 5%-10% lagere bitrate).
Dat h264 geoptimaliseerd is voor HD resoluties is vrij recent. H264 is begonnen als low-bitrate codec, vooral voor dingen zoals Skype. Vandaar ook dat de eerste Blu-rays MPEG-2 hebben omdat het betere kwaliteit opleverde dan de 'niet-voor-HD-geoptimaliseerde' h.264.
owja dat heb je ook nog zo`n codec... allemaal problemen, ene wel ondersteunend ander niet, eerst converteren voordat dat ene filmpje van mn ene mobiel t eens op de ander doet... mot er niet gewoon een verplichte standaard komen die elk apparaat MOET kunnen afspelen? zou zoveel makkelijker maken.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
