Google Chrome dropper H.264

kjeLL// · 15. januar 2011

trenger vp8 mer eller mindre maskinkraft for å bli software decodet? (kontra software decoding av h264)

b-real · 15. januar 2011

trenger vp8 mer eller mindre maskinkraft for å bli software decodet? (kontra software decoding av h264)

Litt lesestoff,type fornuftig lesing:

hvakrg · 15. januar 2011

Jeg skjønner virkelig ikke hva Google mener de skal oppnå. Det er allerede fullt av enheter på internett som støtter H.264 i hardware (mobiler, spillkonsoller og mediesentere) hvor det ikke er 100% praktisk å bytte til en softwareimplementering av VP8. Dette betyr at innholdsleverandører må kode i H.264 for å nå disse brukerne, og da kan de like gjerne wrappe det i Flash for å nå Firefox, Opera og Chrome som ikke støtter H.264 i <video>. Vinneren her er altså Adobe så vidt jeg kan forstå.

Du må tenke mer langsiktig. Det var ikke mye hardware som taklet H.264 før. H.264 er ikke ønskelig i forhold som eneste alternativ da Apple har sine klamme fingre rundt det.

Hva er det som er best for fobrukeren? En codec hvor mange selskaper deler på "eierskapet" eller en codec hvor ett selskap sitter med all makt?

Ellers så har Firefox støtte for H.264 takket være Microsoft.

the_fire · 15. januar 2011

Ellers så har Firefox støtte for H.264 takket være Microsoft.

Men bare i Windows 7?

mandela · 15. januar 2011

syns opera sin forklaring er best jeg

http://my.opera.com/haavard/blog/2011/01/13/openness

Dette er ikke Operas offisielle kommentar:

The views stated herein are my own, and do not necessarily represent those of Opera Software.

ATWindsor · 15. januar 2011

Open source har ikke noe med dette å gjøre egentlig, og H.264 er implementert i x264 og ffmpeg som er open source. H.264 er en åpen standard sertifisert av ISO, i motsetning til VP8 (WebM er bare kontaineren).

Det som gjør at ting skurrer her er at Chrome støtter MP3 og AAC i <audio>, selv om disse heller ikke er uten lisenskostnader. De er ikke konsekvente og jeg kan ikke se at dette er noe annet enn et spill. Mozilla derimot er konsekvense og støtter ikke disse formatene i <audio> av samme grunn som at de ikke støtter H.264 i <video>

Ja, jeg er også litt nysgjerrig på hvordan x264 passer inn i dette, og royalties osv.

AtW

eisa01 · 15. januar 2011

x264 trenger ikke bry seg om lisenskostnadene fordi de kun distribuerer kildekoden. Jeg tror rasjonalet for at det er lov er fordi det er en åpen standard, og kildekoden bare beskriver standarden. Det er først når man kompilerer til maskinkode at man har en implementasjon man evt. må betale royalties for å bruke.

JohndoeMAKT · 15. januar 2011

Hva er det som er best for fobrukeren? En codec hvor mange selskaper deler på "eierskapet" eller en codec hvor ett selskap sitter med all makt?

Hva om jeg omformulerer det til:

Hva er det som er best for forbrukeren? En codec hvor 26 av verdens største multinasjonale konglomerater og bedrifter sitter på deleierskap og har sammen gitt full kontroll til et firma (MPEG LA) som tar inn et ukjent antall milliarder dollar i lisenser årlig på vegne av sine eiere og som også er gjennomsyret av hemmelighet og både ekstern og intern kritikk eller en codec hvor ett selskap sitter på alle patenter og har gitt ut en blanko fri bruk lisens til alle i verden som effektivt gjør at de har gitt all makt fra seg?

Jeg syntes det Google har valgt å gjøre er positivt. Før dette valget var det bare Firefox (Opera er så liten at den ikke teller) som krevde videofiler i et sekundært format om du ønsket god avspilling på alle enheter. Den beste løsningen var derfor å bruke Flash som dekoder i Firefox og dermed kompromitere på opplevelsen da Flash er crap i forhold til nativ avspilling. Nå derimot er prosentdelen som kan spille av h.264 native redusert kraftig til fordel av WebM som gjør at den beste løsningen (om du er opptatt av god opplevelse for brukeren) nå er å dual-encode til både h.264 og WebM og ha native avspilling på alle enheter, inkludert Firefox og Opera. Altså går vi nå fra single format encoding og crappy fallback til dual format encoding og native til alle og enhver. Hurra for native decoding, død over Flash. Hurra for frie (kan alle, inkludert artikkelforfatter slutte å bruke stempelet open source når det ikke har noe med saken å gjøre?) løsninger, død over programvarepatenter.

Endret 15. januar 2011 av JohndoeMAKT

Turgon · 15. januar 2011

Jeg tror det er verdt å se på hvorfor vi ha video-tag i første omgang: Vi ønsker å erstatte flash video. Hvordan kan vi gjøre dette attraktivt for webutviklere?

1: Gi støtte for h264 (som det meste av internetts videoer allerede er encodet til (faktisk vil jeg tro mesteparten av video som produseres i dag er i dette formatet), slik at det bare er å endre siden fra en flash-spiller til en html5 video-tag.

2: Kreve transkoding til V8, med prosessorkraften og kvalitetstapet dette medfører i tillegg.

Jeg tror alternativ 2 kommer til å gjøre at mange bare holder seg til flash, eller bruker en hybridløsning der opera, firefox og chrome bruker flash, mens safari og IE bruker html5 taggen. På lang sikt kan dette endre seg, men på kort sikt kan dette være løsningen..

En annen ting er at med kjøpssummen for On2 (mener å huske dette var $180 mill. så kunne de handlet h264 lisens til seg selv ($6,5 mill. per år) og til mozilla i 180 / 13 ≈ 13,8 år, noe som fører oss til 2025 da patentene går ut (og her er bare kjøpssummen med, og ikke kostnadene på å pusse opp og sjekke legaliteten til formatet). Virker som de har brukt veldig mye penger på å spare penger i dette tilfellet....

ZiggyStardust · 15. januar 2011

trenger vp8 mer eller mindre maskinkraft for å bli software decodet? (kontra software decoding av h264)

Litt lesestoff,type fornuftig lesing:

http://arstechnica.com/open-source/news/2010/02/ogg-theora-vs-h264-head-to-head-comparisons.ars

http://arstechnica.com/web/news/2010/05/google-opens-vp8-codec-aims-to-nuke-h264-with-webm.ars

http://arstechnica.com/web/news/2011/01/googles-dropping-h264-from-chrome-a-step-backward-for-openness.ars/

Denne Peter Bright ser ut til å være i overkant opphengt i Microsoft og er kanskje således ikke den beste, ihvertfall ikke den eneste, kilden å vise til i en debatt om åpne og frie formater? Det er ganske tydelig at han er veldig mot WebM8 og Theora og argumentene hans i forhold til åpenhet er ikke akkurat solide.

hernil · 15. januar 2011

Litt lesestoff,type fornuftig lesing:

http://arstechnica.com/open-source/news/2010/02/ogg-theora-vs-h264-head-to-head-comparisons.ars

http://arstechnica.com/web/news/2010/05/google-opens-vp8-codec-aims-to-nuke-h264-with-webm.ars

http://arstechnica.com/web/news/2011/01/googles-dropping-h264-from-chrome-a-step-backward-for-openness.ars/

Ble i grunn ganske skuffet over Ars siste artikkel om emnet. Masse feil og lite relevante fakta. Syns Haavard fra Opera svarer ganske godt på mye av det. Kan forøvrig nevnes at artikkelforfatter har tittelen "Microsoft Contributor" hos Ars.

Ellers så har Firefox støtte for H.264 takket være Microsoft.

Men bare i Windows 7?

Såvidt jeg vet bare Win7 og hvertfall ikke noe annet enn Windows. Jeg håper selv folk flest har innsett at det nå finnes andre plattformer. Dessuten er hele poenget med native avspilling å slippe plugins. I praksis overlater man forvalteransvaret for video fra Adobe til MS når poenget var å gjøre det tilgjengelig for alle!

Jeg tror det er verdt å se på hvorfor vi ha video-tag i første omgang: Vi ønsker å erstatte flash video. Hvordan kan vi gjøre dette attraktivt for webutviklere?

1: Gi støtte for h264 (som det meste av internetts videoer allerede er encodet til (faktisk vil jeg tro mesteparten av video som produseres i dag er i dette formatet), slik at det bare er å endre siden fra en flash-spiller til en html5 video-tag.

2: Kreve transkoding til V8, med prosessorkraften og kvalitetstapet dette medfører i tillegg.

Jeg tror alternativ 2 kommer til å gjøre at mange bare holder seg til flash, eller bruker en hybridløsning der opera, firefox og chrome bruker flash, mens safari og IE bruker html5 taggen. På lang sikt kan dette endre seg, men på kort sikt kan dette være løsningen..

En annen ting er at med kjøpssummen for On2 (mener å huske dette var $180 mill. så kunne de handlet h264 lisens til seg selv ($6,5 mill. per år) og til mozilla i 180 / 13 ≈ 13,8 år, noe som fører oss til 2025 da patentene går ut (og her er bare kjøpssummen med, og ikke kostnadene på å pusse opp og sjekke legaliteten til formatet). Virker som de har brukt veldig mye penger på å spare penger i dette tilfellet....

Hvor mange tror du legger ut det de filmer ut på nett uten noen form for bearbeiding? Og kvalitetstap?

Sånn som du presenterer tallene taler jo dette bare enda mer for at Google faktisk gjør dette ut fra idealer mer enn bare lommeboken. Dessuten er ikke poenget selskaper som Google - de kan betale og du kan også sponse aktører som Opera. Mozilla kan uansett ikke gi ut Firefox med H.264 dekoder med lisensen de benytter i dag. Poenget er også som jeg nevnte i trådens første svar at dette effektivt dreper innovasjon!

Endret 15. januar 2011 av hernil

Turgon · 15. januar 2011

Jeg tror det er verdt å se på hvorfor vi ha video-tag i første omgang: Vi ønsker å erstatte flash video. Hvordan kan vi gjøre dette attraktivt for webutviklere?

1: Gi støtte for h264 (som det meste av internetts videoer allerede er encodet til (faktisk vil jeg tro mesteparten av video som produseres i dag er i dette formatet), slik at det bare er å endre siden fra en flash-spiller til en html5 video-tag.

2: Kreve transkoding til V8, med prosessorkraften og kvalitetstapet dette medfører i tillegg.

Jeg tror alternativ 2 kommer til å gjøre at mange bare holder seg til flash, eller bruker en hybridløsning der opera, firefox og chrome bruker flash, mens safari og IE bruker html5 taggen. På lang sikt kan dette endre seg, men på kort sikt kan dette være løsningen..

En annen ting er at med kjøpssummen for On2 (mener å huske dette var $180 mill. så kunne de handlet h264 lisens til seg selv ($6,5 mill. per år) og til mozilla i 180 / 13 ≈ 13,8 år, noe som fører oss til 2025 da patentene går ut (og her er bare kjøpssummen med, og ikke kostnadene på å pusse opp og sjekke legaliteten til formatet). Virker som de har brukt veldig mye penger på å spare penger i dette tilfellet....

Hvor mange tror du legger ut det de filmer ut på nett uten noen form for bearbeiding? Og kvalitetstap?

Sånn som du presenterer tallene taler jo dette bare enda mer for at Google faktisk gjør dette ut fra idealer mer enn bare lommeboken. Dessuten er ikke poenget selskaper som Google - de kan betale og du kan også sponse aktører som Opera. Mozilla kan uansett ikke gi ut Firefox med H.264 dekoder med lisensen de benytter i dag. Poenget er også som jeg nevnte i trådens første svar at dette effektivt dreper innovasjon!

Jeg tror det er ganske mange, særlig de som for eksempel laster opp video til facebook eller youtube direkte fra mobilen, hvor omkoding er upraktisk på samtlige tilgjengelige mobiler. I det heletatt så vil webM per i dag kreve at video går innom en eller annen form for datamaskin før det kan legges ut på nettet. Jeg regner med at du forstår at kvalitetstap er et resultat av transkoding og at v8 er et noe dårligere format enn h264.

Du kan tolke det den veien, eller at google søker mer kontroll over internett. Det er viktig å huske på at google sitter med patenter til dette formatet og dermed har mer eller mindre full kontroll over dets vidre utvikling. Det er ikke garrantert at google vil være et godt selskap i fremtiden.

Hvis de gjør dette på bakgrunn av prinsipper, så er det sikkert fint på sin måte, men jeg ser heller at ting utvikles på bakgrunn av hva som er praktisk. WebM er ikke per i dag praktisk (blandt annet pga nevnte grunner).

Både Mozilla, Opera og andre mindre nettlesere kan utnytte 3. parts kodekker (f.eks. den som følger med windows, OSX eller det alle likevel legger inn selv i linuxdistrubisjoner (gjennom gstreamer), dersom de av lisensgrunner ikke kan legge inn støtte selv. Både iE og Safari fungerer på denne måten, og jeg har ikke sett noen skikkelig forklaring på hvorfor Firefox ikke kan fungere på denne måten (Opera fungerer allerede slik under linux).

Til slutt et spørsmål: Tror du innholdslevrandører (slik som Hulu, Netflix, osv) kommer til å reenkode sine videoer til webM (en prosess som antaglig koster en god del penger), eller bare fortsette å bruke flash (husk, dette er selskaper som vil tjene penger og det er sannsynlig at de bryr seg mindre om edle prinsipper [Dette gjelder antaglig også flesteparten av brukerne])?

JohndoeMAKT · 15. januar 2011

2: Kreve transkoding til V8, med prosessorkraften og kvalitetstapet dette medfører i tillegg.

Her kan jeg skyte inn litt informasjon som setter dette alternativet litt i perspektiv.

Mange her i landet sitter med både dårlige nettlinjer og enten teknisk trege maskiner (gamle) eller software-trege (Windows råte etter mange års bruk) som gjør at de ikke greier å dekode mye over en halv megapixel video og megabit båndbredde. Det gjør at du må støtte tilbakefall på en lavkvalitesversjon. Samtidig tillater også kamera samt en stor mengde brukeres systemer og nettlinjer bruk av høykvalitesvideo (720p @2+ Mbit f.eks) som gjør at du kan velge å gjøre en slik versjon tilgjengelig. For bruk på PC er H.264 High Profile ingen problem å bruke. Men i dag er det også forventet av video er tilgjengelig til mobile enheter hvor f.eks Apple iPhone hadde en sperre på 640x480@1500kbps Main Profile 3.1 som jeg tror er satt opp til 720p i iOS 4.1, men det har jeg ikke testet. For å få en applikasjon godkjent for Apple iPad MÅ du også levere en fil med bitrate på 64kbps som betyr en oppløsning på max 320x180. Android er vanskelig å ha med å gjøre da det er forskjellig hva som er implementert av leverandørene, men f.eks Samsung Galaxy S har en sperre på omtrent 512x3xx og støtter bare en eller annen versjon av Baseline Profile. Neste problem er protokoll og metode data blir servert. Flash støtter streaming over HTTP eller RTMP(-/E/T/ET), iOS støtter HTTP eller deres egen (draft til åpen spesifikasjon levert til IETF, good work Apple!) fragmentert HTTP-streaming hvor siste er påkrevd ved bruk i iPad-applikasjoner. Android (i bruk i dag) støtter bare streaming over RTP-protokollen.

Med andre ord er dette hva som må til for "full" og optimal video på web: (Linjer i grått er ikke påkrevde men kan gjøre tjenesten bedre)

320x180x64kbps@High Profile, Apple HTTP streaming -> mobilnett i iPad applikasjoner

512x288@Baseline Profile, RTP protokoll -> Legacy Android

640x360@High Profile, HTTP protokoll -> lavkvalitet HTML5 & Flash

640x360@High Profile, RTMP protokoll -> lavkvalitet Flash

640x360@Main Profile, HTTP protokoll -> iPhone

854x480@High Profile, HTTP protokoll -> normal HTML5 & Flash

854x480@High Profile, RTMP protokoll -> normal Flash

1024x576 eller 1280x720@High Profile, Apple HTTP streaming -> iPad applikasjoner

1280x720@High Profile, HTTP protokoll -> høykvalitet HTML5 & Flash

1280x720@High Profile, RTMP protokoll -> høykvalitet Flash

Med andre ord krever god støtte omtrent seks forskjellige H.264-filer servert over tre systemer/protkoller og vil du ha native størrelse på iPad blir det en syvende. Dersom du går ned til Main Profile der det er duplikatstørrelser blir det likevel fem/seks filer. En ekstra 854x480 WebM over HTTP vil for oppsett av denne kompleksiteten ha minimalt å si når det kommer til transkoding av nytt innhold, lagring av ekstra fil og streaming av den. Ved full overgang til WebM for all PC-bruk og H.264 kun på håndholdte enheter er faktisk antall filer fortsatt syv.

Endret 15. januar 2011 av JohndoeMAKT

kjeLL// · 15. januar 2011

@Turgon

når man laster opp en video h264 fra mobil, blir den alikevell transcodet av nettstedet du laster den opp til. dette er for å sikre avspilling, gi valg til kvalitet publikum vil ha og spare bandbredde. så det spiller ingen trille om den blir transcodet til h264 eller vp8 for cpu'en på servern.

om folk måtte sitte å transcode alt sammen selv før det ble lasta ut på nettet ville kun omtrent halvparten av youtube videoene fungert som planlagt.

Endret 15. januar 2011 av kjeLL//

Turgon · 15. januar 2011

2: Kreve transkoding til V8, med prosessorkraften og kvalitetstapet dette medfører i tillegg.

Her kan jeg skyte inn litt informasjon som setter dette alternativet litt i perspektiv.

Mange her i landet sitter med både dårlige nettlinjer og enten teknisk trege maskiner (gamle) eller software-trege (Windows råte etter mange års bruk) som gjør at de ikke greier å dekode mye over en halv megapixel video og megabit båndbredde. Det gjør at du må støtte tilbakefall på en lavkvalitesversjon. Samtidig tillater også kamera samt en stor mengde brukeres systemer og nettlinjer bruk av høykvalitesvideo (720p @2+ Mbit f.eks) som gjør at du kan velge å gjøre en slik versjon tilgjengelig. For bruk på PC er H.264 High Profile ingen problem å bruke. Men i dag er det også forventet av video er tilgjengelig til mobile enheter hvor f.eks Apple iPhone hadde en sperre på 640x480@1500kbps Main Profile 3.1 som jeg tror er satt opp til 720p i iOS 4.1, men det har jeg ikke testet. For å få en applikasjon godkjent for Apple iPad MÅ du også levere en fil med bitrate på 64kbps som betyr en oppløsning på max 320x180. Android er vanskelig å ha med å gjøre da det er forskjellig hva som er implementert av leverandørene, men f.eks Samsung Galaxy S har en sperre på omtrent 512x3xx og støtter bare en eller annen versjon av Baseline Profile. Neste problem er protokoll og metode data blir servert. Flash støtter streaming over HTTP eller RTMP(-/E/T/ET), iOS støtter HTTP eller deres egen (draft til åpen spesifikasjon levert til IETF, good work Apple!) fragmentert HTTP-streaming hvor siste er påkrevd ved bruk i iPad-applikasjoner. Android (i bruk i dag) støtter bare streaming over RTP-protokollen.

Med andre ord er dette hva som må til for "full" og optimal video på web: (Linjer i grått er ikke påkrevde men kan gjøre tjenesten bedre)

320x180@High Profile, Apple HTTP streaming -> mobilnett i iPad applikasjoner

512x288@Baseline Profile, RTP protokoll -> Legacy Android

640x360@High Profile, HTTP protokoll -> lavkvalitet HTML5 & Flash

640x360@High Profile, RTMP protokoll -> lavkvalitet Flash

640x360@Main Profile, HTTP protokoll -> iPhone

854x480@High Profile, HTTP protokoll -> normal HTML5 & Flash

854x480@High Profile, RTMP protokoll -> normal Flash

1024x576 eller 1280x720@High Profile, Apple HTTP streaming -> iPad applikasjoner

1280x720@High Profile, HTTP protokoll -> høykvalitet HTML5 & Flash

1280x720@High Profile, RTMP protokoll -> høykvalitet Flash

Med andre ord krever god støtte omtrent seks forskjellige H.264-filer servert over tre systemer/protkoller og vil du ha native størrelse på iPad blir det en syvende. Dersom du går ned til Main Profile der det er duplikatstørrelser blir det likevel fem/seks filer. En ekstra 854x480 WebM over HTTP vil for oppsett av denne kompleksiteten ha minimalt å si når det kommer til transkoding av nytt innhold, lagring av ekstra fil og streaming av den. Ved full overgang til WebM for all PC-bruk og H.264 kun på håndholdte enheter er faktisk antall filer fortsatt syv.

WebM vil antaglig føre til en duplisering av alle filer som har med pc og android å gjøre, så det blir en god neve ekstra kompleksitet hvis webM nettlesere skal ha samme utvalg som H264 browsere. I tillegg MÅ ikke hver video være optimalisert for alle overføringsprotokollene.

Turgon · 15. januar 2011

@Turgon

når man laster opp en video h264 fra mobil, blir den alikevell transcodet av nettstedet du laster den opp til. dette er for å sikre avspilling, gi valg til kvalitet publikum vil ha og spare bandbredde. så det spiller ingen trille om den blir transcodet til h264 eller vp8 for cpu'en på servern.

om folk måtte sitte å transcode alt sammen selv før det ble lasta ut på nettet ville kun omtrent halvparten av youtube videoene fungert som planlagt.

Det er ikke noe behov for å transkode h264 til samme kvalitetsnivå, noe det er med WebM, altså vil webM kreve minst en ektra transkoding, i tillegg til at enkoderne til V8 per dags dato er betydelig trengere enn h264, altså koster dette mer (dette vil antaglig endre seg, men det må endre seg før man endrer formatstøtten).

SÅ per dags dato tror jeg nok dette spiller en rolle.

kjeLL// · 15. januar 2011

du får ta å teste selv. ta en 2min test video med mobilen din, kameraet ditt eller webcam. pass på at det blir encodet til h264 mp4 med aac eller gjør det selv etterpå. ta crc32 eller md5 av fila. last den opp på youtube. finn høyeste kvalitet og last den ned til din pc. ta crc32 eller md5 av fila. er det samme fil skal jeg faenmeg spise en ps3 kontroll.

oj88 · 15. januar 2011

Google eier YouTube. Punktum. De sitter på makten over video på nettet.

Hvis Google dekoder alle videoene til WebM (så vidt jeg vet har de drevet på med dette lenge), og etterhvert faser ut Flash og krever WebM for å vise YouTube-klipp, vil WebM-støtte i løpet av kort tid finnes i det meste av nettlesere, i alle fall på desktopen. De nettleserne som ikke støtter WebM ut av boksen, kan Google bare lage en plugin til, som blir lastet ned som et vanlig nettlesertillegg når man prøver å spille av en YouTube-film. Dette klarer alle brukere.

Det er nok litt verre med mobilnettlesere o.l., men jeg er helt overbevist om at leverandører fort vil oppdatere sin programvare hvis Google går over til å kun streame YouTube i WebM. Ingen vil levere et produkt uten YouTube-støtte. Selv Apple vil oppdatere sin YouTube-klient fort pga brukerstorm når YouTube ikke lenger fungerer.

Den makten Google sitter på med YouTube må de utnytte. De kan tvinge weben over på et fritt format. Steve Jobs med flere mener jo at det finnes "ingen formater som ikke bryter med lisensene til MPEG-LA", så det er ikke vits å lage noe annet format. De vil bli saksøkt, og tape, tror Jobs. Bare den uttalelsen er til å bli kvalm av. Det kan være han har rett - i så fall er det grunn nok til å stille noen folk der ute for en menneskerettsdomstol. INGEN skal eie video. Punktum. Sånt kan ikke menneskeheten la seg hemme av. At Jobs med flere ser ut til å ikke uttrykke bekymring rundt deres valg er skremmende. Et eksempel på hvor idiotisk patentene er er et innlegg jeg leste her i går, der en bruker med et nytt kamera siterte lisensen som fulgte med kameraet. Pga at det bruke h.264 hadde han ikke lov til å ta betalt for eventuelle videoer han måtte filme med det kameraet. Hallo?

Og når det gjelder HW-aksellerasjon: Min HTPC med Intel Atom spiller 1080p med mellom 0-10% CPU-bruk takket være NVIDIA VDPAU på GNU/Linux. Vil tro at WebM-støtte kan dukke opp etterhvert om det ikke allerede finnes.

Turgon · 15. januar 2011

du får ta å teste selv. ta en 2min test video med mobilen din, kameraet ditt eller webcam. pass på at det blir encodet til h264 mp4 med aac eller gjør det selv etterpå. ta crc32 eller md5 av fila. last den opp på youtube. finn høyeste kvalitet og last den ned til din pc. ta crc32 eller md5 av fila. er det samme fil skal jeg faenmeg spise en ps3 kontroll.

Jeg har verken tid eller ork til å utføre dette eksprimentet, og det vil heller ikke gi meg noen spesiell glede om du spiser nevnte kontroll (som koster betydelig mer enn lisens til H264 btw). I argumentet mitt går jeg simpelthen ut ifra at youtube fungerer på en nogenlunde fornuftig måte, og at det er mulig å unngå minst en konvertering emd H264.

JohndoeMAKT · 15. januar 2011

Jeg tror det er ganske mange, særlig de som for eksempel laster opp video til facebook eller youtube direkte fra mobilen, hvor omkoding er upraktisk på samtlige tilgjengelige mobiler. I det heletatt så vil webM per i dag kreve at video går innom en eller annen form for datamaskin før det kan legges ut på nettet.

Alt av brukervideo blir transkodet. Video fra mobiltelefoner og forbrukerkamera er av så vanvittig varierende form (formater, codecs, codec-versjoner, codec-profiler, fargesystem, bitrate og selvsagt, om standardene er fulgt i det hele tatt, noe som i veldig, veldig stor grad ikke skjer på enkle enheter) at du må transkode til en garantert felles standard for alt av innhold du skal streame. Om det er WebM eller H.264 har lite å si i den grad selv om H.264 har tekniske fordeler.

Jeg regner med at du forstår at kvalitetstap er et resultat av transkoding og at v8 er et noe dårligere format enn h264.

Ja, men du transkoder normalt fra orginal eller fra høyere kvalitet enn målformatet. Kvalitet på arkiv er langt fra like viktig som på nytt innhold hvor orginal er tilgjengelig.

Du kan tolke det den veien, eller at google søker mer kontroll over internett. Det er viktig å huske på at google sitter med patenter til dette formatet og dermed har mer eller mindre full kontroll over dets vidre utvikling. Det er ikke garrantert at google vil være et godt selskap i fremtiden.

Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8.

irrevocable.

Hvis de gjør dette på bakgrunn av prinsipper, så er det sikkert fint på sin måte, men jeg ser heller at ting utvikles på bakgrunn av hva som er praktisk. WebM er ikke per i dag praktisk (blandt annet pga nevnte grunner).

Jeg syntes det er praktisk. Dersom du skal utnytte video i et produkt hvor H.264s patenter er gyldige er den tekniske overgangen til WebM ingenting i forhold til det juridiske arbeidet som må gjøres for å kunne bruke H.264.

Til slutt et spørsmål: Tror du innholdslevrandører (slik som Hulu, Netflix, osv) kommer til å reenkode sine videoer til webM (en prosess som antaglig koster en god del penger), eller bare fortsette å bruke flash (husk, dette er selskaper som vil tjene penger og det er sannsynlig at de bryr seg mindre om edle prinsipper [Dette gjelder antaglig også flesteparten av brukerne])?

Først: Hulu bruker ikke Flash fordi de liker H.264, de bruker Flash fordi innholdsleverandørene krever DRM.

Sekundært: Adobe har uttalt at Flash vil få støtte for WebM.

Tetriært: Ja.

WebM vil antaglig føre til en duplisering av alle filer som har med pc og android å gjøre, så det blir en god neve ekstra kompleksitet hvis webM nettlesere skal ha samme utvalg som H264 browsere. I tillegg MÅ ikke hver video være optimalisert for alle overføringsprotokollene.

Som sagt faller du ned på seks filer dersom du ikke optimaliserer for hvert system. Og kompleksiteten med WebM vil ikke stige med antall filer samt at som jeg prøvde å vise er allerede kompleksiteten såpass høy at å servere WebM er et veldig lite steg.

Det er ikke noe behov for å transkode h264 til samme kvalitetsnivå, noe det er med WebM, altså vil webM kreve minst en ektra transkoding, i tillegg til at enkoderne til V8 per dags dato er betydelig trengere enn h264, altså koster dette mer (dette vil antaglig endre seg, men det må endre seg før man endrer formatstøtten).

Som jeg skrev tidligere i denne posten blir alt av video allerede transkodet, selv om orginalkilden er H.264, det kan jeg nesten garantere. Og ja, implementasjoner av WebM-transkoding er for øyeblikket tregt. x264 som er en kick-ass encoder er omtrent dobbelt så rask som libvpx (ffvp8 har vi enda ikke testet) ved bruk av FFmpeg.

Google Chrome dropper H.264

Anbefalte innlegg

Lenke til kommentar

Videoannonse

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Opprett konto

Logg inn

Hvem er aktive 0 medlemmer