Google Chrome dropper H.264

[Turgon]

Dette er grunnen til at jeg mener FSF er fanatiske. De kan potensielt hindre gode ting, som Android, ved å tolke "fri programvare" på en måte som gjør programvaren veldig upraktisk å bruke for kommersielle aktører.

 

De er fanatiske fordi de hypotetisk sett kan komme emd en "fantasik" tolkning? På samme måte som jeg er en fantiker fordi jeg hypotetisk sett kunne vært en selvmordsbomber da eller?

 

AtW

Hæ? Jeg sikter til GPL v3, som jeg også skriver i innlegget, dette er altså ikke hypotetisk.

[ATWindsor]

Dette er grunnen til at jeg mener FSF er fanatiske. De kan potensielt hindre gode ting, som Android, ved å tolke "fri programvare" på en måte som gjør programvaren veldig upraktisk å bruke for kommersielle aktører.

 

De er fanatiske fordi de hypotetisk sett kan komme emd en "fantasik" tolkning? På samme måte som jeg er en fantiker fordi jeg hypotetisk sett kunne vært en selvmordsbomber da eller?

 

AtW

Hæ? Jeg sikter til GPL v3, som jeg også skriver i innlegget, dette er altså ikke hypotetisk.

 

Så den "potensielle hindringen av gode ting" du sikter til er ikke hypotetisk? Har de konkret hindret noen av de gode tingene du sikter til? Eller er det en hypotetisk situasjon?

 

AtW

[Turgon]

Det er noen problemer med WebM i forhold til H264: Spesifikasjonen er svært dårlig dokumentert, og en så lenge ikke starndardisert via et standardiseringsorgan (det siste kommer nok på plass etter hvert). WebM kan dermed potensielt være noe dyrere å implementere dekoder og enkoder til (uten at dette reelt sett behøver å være utslagsgivende.

 

Er ikke dette bare spekulering og FUD?

Jeg har fortsatt ikke sett noe påstå dette og kommet med rimelig dokumentasjon på påstanden hittil.

Så litt for circa året siden, mens VP8 fortsatt ble utviklet videre, og derfor ingen endelig spec på tidspunktet.

VP8 spesifikasjonene har vært fryst siden google annonserte WebM forje vår. Specen til formatet er innkomplett og inneholder kode, i stede for beskrivelse. Du kan lese om det her fra en person som faktisk har utviklet mot spekken: http://x264dev.multimedia.cx/archives/486

 

Mener du fortsatt det er FUD?

[Turgon]

Dette er grunnen til at jeg mener FSF er fanatiske. De kan potensielt hindre gode ting, som Android, ved å tolke "fri programvare" på en måte som gjør programvaren veldig upraktisk å bruke for kommersielle aktører.

 

De er fanatiske fordi de hypotetisk sett kan komme emd en "fantasik" tolkning? På samme måte som jeg er en fantiker fordi jeg hypotetisk sett kunne vært en selvmordsbomber da eller?

 

AtW

Hæ? Jeg sikter til GPL v3, som jeg også skriver i innlegget, dette er altså ikke hypotetisk.

 

Så den "potensielle hindringen av gode ting" du sikter til er ikke hypotetisk? Har de konkret hindret noen av de gode tingene du sikter til? Eller er det en hypotetisk situasjon?

 

AtW

Det er hypotetisk så lenge linux-kernelen er under GPL v2, men det er jo neppe FSF sin fortjeneste. Slik jeg forstår dette vil ting som kindle, android-enheter, TiVo osv. være umulig med linux under GPL v3.

[del_diablo]

Det er noen problemer med WebM i forhold til H264: Spesifikasjonen er svært dårlig dokumentert, og en så lenge ikke starndardisert via et standardiseringsorgan (det siste kommer nok på plass etter hvert). WebM kan dermed potensielt være noe dyrere å implementere dekoder og enkoder til (uten at dette reelt sett behøver å være utslagsgivende.

 

Er ikke dette bare spekulering og FUD?

Jeg har fortsatt ikke sett noe påstå dette og kommet med rimelig dokumentasjon på påstanden hittil.

Så litt for circa året siden, mens VP8 fortsatt ble utviklet videre, og derfor ingen endelig spec på tidspunktet.

VP8 spesifikasjonene har vært fryst siden google annonserte WebM forje vår. Specen til formatet er innkomplett og inneholder kode, i stede for beskrivelse. Du kan lese om det her fra en person som faktisk har utviklet mot spekken: http://x264dev.multimedia.cx/archives/486

 

Mener du fortsatt det er FUD?

 

Ikke ferdigutviklet != Mangel på dokumentasjon

Ergo: FUD

[Turgon]

Det er noen problemer med WebM i forhold til H264: Spesifikasjonen er svært dårlig dokumentert, og en så lenge ikke starndardisert via et standardiseringsorgan (det siste kommer nok på plass etter hvert). WebM kan dermed potensielt være noe dyrere å implementere dekoder og enkoder til (uten at dette reelt sett behøver å være utslagsgivende.

 

Er ikke dette bare spekulering og FUD?

Jeg har fortsatt ikke sett noe påstå dette og kommet med rimelig dokumentasjon på påstanden hittil.

Så litt for circa året siden, mens VP8 fortsatt ble utviklet videre, og derfor ingen endelig spec på tidspunktet.

VP8 spesifikasjonene har vært fryst siden google annonserte WebM forje vår. Specen til formatet er innkomplett og inneholder kode, i stede for beskrivelse. Du kan lese om det her fra en person som faktisk har utviklet mot spekken: http://x264dev.multimedia.cx/archives/486

 

Mener du fortsatt det er FUD?

 

Ikke ferdigutviklet != Mangel på dokumentasjon

Ergo: FUD

Google sier jo selv at spesifikasjonen er ferdig (eller, mer presist, at de ikke vil gjøre noe mer med det):

 

Are VP8 or WebM subject to change?

 

The VP8 and WebM specifications as released on May 19th, 2010 are final. We believe that the code and tools can evolve and improve for many years without requiring changes to the core specifications. We'll maintain a separate branch of the code, however, for bold new ideas that could alter the specifications. If there are significant improvements that warrant a revision we might adopt them, but only after careful consideration and after discussing suggested changes with the WebM community.

 

Kilde: http://www.webmproject.org/about/faq/#licensing

 

Mener du fortsatt dette er FUD?

[del_diablo]

Det er noen problemer med WebM i forhold til H264: Spesifikasjonen er svært dårlig dokumentert, og en så lenge ikke starndardisert via et standardiseringsorgan (det siste kommer nok på plass etter hvert). WebM kan dermed potensielt være noe dyrere å implementere dekoder og enkoder til (uten at dette reelt sett behøver å være utslagsgivende.

 

Er ikke dette bare spekulering og FUD?

Jeg har fortsatt ikke sett noe påstå dette og kommet med rimelig dokumentasjon på påstanden hittil.

Så litt for circa året siden, mens VP8 fortsatt ble utviklet videre, og derfor ingen endelig spec på tidspunktet.

VP8 spesifikasjonene har vært fryst siden google annonserte WebM forje vår. Specen til formatet er innkomplett og inneholder kode, i stede for beskrivelse. Du kan lese om det her fra en person som faktisk har utviklet mot spekken: http://x264dev.multimedia.cx/archives/486

 

Mener du fortsatt det er FUD?

 

Ikke ferdigutviklet != Mangel på dokumentasjon

Ergo: FUD

Google sier jo selv at spesifikasjonen er ferdig (eller, mer presist, at de ikke vil gjøre noe mer med det):

 

Are VP8 or WebM subject to change?

 

The VP8 and WebM specifications as released on May 19th, 2010 are final. We believe that the code and tools can evolve and improve for many years without requiring changes to the core specifications. We'll maintain a separate branch of the code, however, for bold new ideas that could alter the specifications. If there are significant improvements that warrant a revision we might adopt them, but only after careful consideration and after discussing suggested changes with the WebM community.

 

Kilde: http://www.webmproject.org/about/faq/#licensing

 

Mener du fortsatt dette er FUD?

 

Ja, fordi google har samtidlig sagt at WebM ikke er 100% ferdig, ergo så er poenget et skal fungere sånn.

[Del]

GPL krevet også at du distribuerer alle endringer du gjør til koden, dvs at hvis du blander din proprietære kode med GPL kode (uten tilstrekkelige barriærer), så må du publisere din lukkede kode under GPL.

Nei, det er feil. Det følger ingen distribusjonsplikt med GPL. Så lenge du beholder koden for deg selv kan du gjøre hva faen du vil. Hvis du derimot velger å distribuere koden, så slår GPL inn. Det er derfor det heter copyleft, den som mottar koden får rettigheter. Dette er som sagt en mekanisme for å stimulere både folk og bedrifter til å samarbeide. Hvis man ikke ønsker den modellen velger man eksempelvis BSD type lisens, som FSF på lik linje anser som åpen. Da trenger man ikke dele en dritt. Google valgte den på Android, og kunne fritt gjøre det selv om kjernen er linux og GPL. Det som GPL lisensen for linux derimot betyr er at drivere som distribueres med Android må åpnes. På den måten blir det også mulig for andre å fikse drivere selv om fabrikanten ikke gidder.

Men det jeg sikter spesifikt til her, er GPL 3s "tiltak" mot at åpen kode benyttes på lukket maskinvare (det FSF kaller "tivolization").

Jeg mistenker at du surrer her og. GPL3 tar spesielt og utdyper i forhold til patenter, men det er korrekt at den også går skyen litt i møte, og det er kanskje det du tenker på? Dette er en gråsone, når skybaserte tjenester bruker GPL kode (slik som Google gjør med gmail), skal de da slippe å dele koden tilbake? Her er fortsatt GPL v.3 relativt liberal, men det skader jo da også viljen til å bidra, og truer dermed det som har gjort GPL så utrolig vellykket. Endret 27. januar 2011 av Del

[Turgon]

Det er noen problemer med WebM i forhold til H264: Spesifikasjonen er svært dårlig dokumentert, og en så lenge ikke starndardisert via et standardiseringsorgan (det siste kommer nok på plass etter hvert). WebM kan dermed potensielt være noe dyrere å implementere dekoder og enkoder til (uten at dette reelt sett behøver å være utslagsgivende.

 

Er ikke dette bare spekulering og FUD?

Jeg har fortsatt ikke sett noe påstå dette og kommet med rimelig dokumentasjon på påstanden hittil.

Så litt for circa året siden, mens VP8 fortsatt ble utviklet videre, og derfor ingen endelig spec på tidspunktet.

VP8 spesifikasjonene har vært fryst siden google annonserte WebM forje vår. Specen til formatet er innkomplett og inneholder kode, i stede for beskrivelse. Du kan lese om det her fra en person som faktisk har utviklet mot spekken: http://x264dev.multimedia.cx/archives/486

 

Mener du fortsatt det er FUD?

 

Ikke ferdigutviklet != Mangel på dokumentasjon

Ergo: FUD

Google sier jo selv at spesifikasjonen er ferdig (eller, mer presist, at de ikke vil gjøre noe mer med det):

 

Are VP8 or WebM subject to change?

 

The VP8 and WebM specifications as released on May 19th, 2010 are final. We believe that the code and tools can evolve and improve for many years without requiring changes to the core specifications. We'll maintain a separate branch of the code, however, for bold new ideas that could alter the specifications. If there are significant improvements that warrant a revision we might adopt them, but only after careful consideration and after discussing suggested changes with the WebM community.

 

Kilde: http://www.webmproject.org/about/faq/#licensing

 

Mener du fortsatt dette er FUD?

 

Ja, fordi google har samtidlig sagt at WebM ikke er 100% ferdig, ergo så er poenget et skal fungere sånn.

Hæ? Google sier her at de ikke kommer til å gjøre noe mer med spesifikasjonen (i overskuelig fremtid). Uavhengig om de sier det er ferdig eller ikke, så må det jo være riktig å falle det final? Er jeg helt på jordet her?

 

Den orginale påstanden min var jo at spesifikasjonene var dårlige og lite lesbare, og dermed potensielt vanskeligere å utvikle for. Hvordan kan du fortsatt mene dette er FUD?

[Turgon]

GPL krevet også at du distribuerer alle endringer du gjør til koden, dvs at hvis du blander din proprietære kode med GPL kode (uten tilstrekkelige barriærer), så må du publisere din lukkede kode under GPL.

Nei, det er feil. Det følger ingen distribusjonsplikt med GPL. Så lenge du beholder koden for deg selv kan du gjøre hva faen du vil. Hvis du derimot velger å distribuere koden, så slår GPL inn. Det er derfor det heter copyleft, den som mottar koden får rettigheter. Dette er som sagt en mekanisme for å stimulere både folk og bedrifter til å samarbeide. Hvis man ikke ønsker den modellen velger man eksempelvis BSD type lisens, som FSF på lik linje anser som åpen. Da trenger man ikke dele en dritt. Google valgte den på Android, og kunne fritt gjøre det selv om kjernen er linux og GPL. Det som GPL lisensen for linux derimot betyr er at drivere som distribueres med Android må åpnes. På den måten blir det også mulig for andre å fikse drivere selv om fabrikanten ikke gidder.

Her har du selvsagt rett, men jeg formulerte meg også litt dumt. Det jeg prøvde å si er at du må distrubiere kode dersom du ønsker å distribuere binærfiler som inneholder GPL kode (og ikke er tilstrekkelig kapsulert).

Men det jeg sikter spesifikt til her, er GPL 3s "tiltak" mot at åpen kode benyttes på lukket maskinvare (det FSF kaller "tivolization").

Jeg mistenker at du surrer her og. GPL3 tar spesielt og utdyper i forhold til patenter, men det er korrekt at den også går skyen litt i møte, og det er kanskje det du tenker på? Dette er en gråsone, når skybaserte tjenester bruker GPL kode (slik som Google gjør med gmail), skal de da slippe å dele koden tilbake? Her er fortsatt GPL v.3 relativt liberal, men det skader jo da også viljen til å bidra, og truer dermed det som har gjort GPL så utrolig vellykket.

Jeg skal prøve å finne tid og lese en oversikt over GPL v3 igjen, slik at jeg ikke bare synser her.

[del_diablo]

Hæ? Google sier her at de ikke kommer til å gjøre noe mer med spesifikasjonen (i overskuelig fremtid). Uavhengig om de sier det er ferdig eller ikke, så må det jo være riktig å falle det final? Er jeg helt på jordet her?

 

Den orginale påstanden min var jo at spesifikasjonene var dårlige og lite lesbare, og dermed potensielt vanskeligere å utvikle for. Hvordan kan du fortsatt mene dette er FUD?

 

Enkelt og greit: Vis spesifikasjonene og formatet er ferdig utviklet, kan man si at dokumentasjonen mangler. Er ikke formatet ferdig utviklet, så kan man ikke klage på annet en dokumentasjon under veis.

De søkte ikke på IEFA(mulig jeg skrive feil, poenget er at de tilsvarer ISO) før en noen dager siden, og når den er på plass er det litt mer arbeid.

Etter dette punktet derimot, kan man begynne å klage.

RC != Final

[hernil]

Hvis hele verden bruker H.264 så ser du jo bra dum ut der du står med mobilnettleseren du nettopp har laget som kun støtter WebM. Og penger til å betale MPEG-LA har du jo ikke ... Lykke til med å komme inn på markedet da

Også var det dette med å benytte seg av OS-codecene da (så vidt jeg vet er dette mulig, også på den "lukkede" plattformen iOS).

 

Tar jeg helt feil når jeg sier dette muliggjør støtte for codecene OSet støtter uten at man må betale lisenser og uten at det bryter med populære opern-source lisenser?

Det blir så kortsiktig ... Her går du utifra at alle som lager OS per idag og i fremtiden velger å legge med dekodere man har tilgang på. Igjen, hvis noen vil utvikle et tredjeparts OS som av diverse grunner (være seg kostnad eller lisensvilkår) ikke distribuerer kodek så står du der med skjegget i postkassa. Det kan også være at OS-et bundler et medieavspillingsprogram til avspilling av video, men som ikke åpner for at andre programmer på enheten kan benytte dets kodeker.

 

Det blir så lukket og krampeaktig når alt kan løses på en bedre måte med et royaltyfritt format. Du vil de neste to årene ikke få full glede av det på din nyinnkjøpte iphone (vet ikke om du har dette), men innen et par år (og lenge før flash har blitt faset ut på området) så er alle ulempene WebM per idag har mot h.264 så godt som jevnet ut. Dog avhenger det at man tar riktig valg fra starten av og ikke lar h.264 feste seg og få spire og gro som de facto standard.

[Turgon]

Hvis hele verden bruker H.264 så ser du jo bra dum ut der du står med mobilnettleseren du nettopp har laget som kun støtter WebM. Og penger til å betale MPEG-LA har du jo ikke ... Lykke til med å komme inn på markedet da

Også var det dette med å benytte seg av OS-codecene da (så vidt jeg vet er dette mulig, også på den "lukkede" plattformen iOS).

 

Tar jeg helt feil når jeg sier dette muliggjør støtte for codecene OSet støtter uten at man må betale lisenser og uten at det bryter med populære opern-source lisenser?

Det blir så kortsiktig ... Her går du utifra at alle som lager OS per idag og i fremtiden velger å legge med dekodere man har tilgang på. Igjen, hvis noen vil utvikle et tredjeparts OS som av diverse grunner (være seg kostnad eller lisensvilkår) ikke distribuerer kodek så står du der med skjegget i postkassa. Det kan også være at OS-et bundler et medieavspillingsprogram til avspilling av video, men som ikke åpner for at andre programmer på enheten kan benytte dets kodeker.

 

Det blir så lukket og krampeaktig når alt kan løses på en bedre måte med et royaltyfritt format. Du vil de neste to årene ikke få full glede av det på din nyinnkjøpte iphone (vet ikke om du har dette), men innen et par år (og lenge før flash har blitt faset ut på området) så er alle ulempene WebM per idag har mot h.264 så godt som jevnet ut. Dog avhenger det at man tar riktig valg fra starten av og ikke lar h.264 feste seg og få spire og gro som de facto standard.

Senarioet ditt virker veldig veldig hypotetisk. Jeg tror faktisk vi står ganske trygt om vi velger å eventuelt spesifisere WebM i video-tagen NÅR det kommer et OS, som er brukt av en betydelig mengde mennesker, som ikke har denne muligheten.

 

Faktisk vil jeg si at bruk av OS codecer per i dag er den beste løsningen, siden det gir best gjennbruk av programvare. De som lager nettleserne bør etter min mening konsentrere seg om selve nettleseren, ikke om å finne opp hjulet på nytt i forhold til dekodere til video.

 

H264 er allerede en de-facto standard, og kan egentlig ikke få særlig større markedsandel på nettvideo, spiller ingen rolle hva slags valg vi gjør nå, da situasjonen ikke kan bli særlig bedre for H264. I tillegg burde jo overgangen fra H264, selv med lik støtte, være kjapp, dersom WebM viser seg å bli et bedre format på alle punkter fremover.

 

Du må også huske på, som jeg har påpekt flere ganger, at H264 ikke blir borte, selv om nettleserne fjerner støtten. Flash vil fortsatt eksistere, og for tilbyderne vil det mest sannsynlig være billigere å bare beholde flash, fremfor å reenkode alt. Det vil altså eksistere et behov for å beholde flash installert for legacy, noe som er betydelig verre enn å bare bruke OS-støtten for H264 (uansett hvor kortsiktig du føler dette er).

[Turgon]

Hæ? Google sier her at de ikke kommer til å gjøre noe mer med spesifikasjonen (i overskuelig fremtid). Uavhengig om de sier det er ferdig eller ikke, så må det jo være riktig å falle det final? Er jeg helt på jordet her?

 

Den orginale påstanden min var jo at spesifikasjonene var dårlige og lite lesbare, og dermed potensielt vanskeligere å utvikle for. Hvordan kan du fortsatt mene dette er FUD?

 

Enkelt og greit: Vis spesifikasjonene og formatet er ferdig utviklet, kan man si at dokumentasjonen mangler. Er ikke formatet ferdig utviklet, så kan man ikke klage på annet en dokumentasjon under veis.

De søkte ikke på IEFA(mulig jeg skrive feil, poenget er at de tilsvarer ISO) før en noen dager siden, og når den er på plass er det litt mer arbeid.

Etter dette punktet derimot, kan man begynne å klage.

RC != Final

Hello! Google sier at det ikke kommer bedre dokumentasjon, og akter å bruke formatet AS IS. Det kan da ikke være feil å da klage på at dokumentasjonen er dårlig?

 

Mener du det ville være feil å klage på nedetid hos f.eks. Gmail, dersom google bestemte seg for å å aldri fjerne beta merkingen og i tillegg sa at de anser produktet som godt nok, og aldri vil gjøre det bedre?

[del_diablo]

Hæ? Google sier her at de ikke kommer til å gjøre noe mer med spesifikasjonen (i overskuelig fremtid). Uavhengig om de sier det er ferdig eller ikke, så må det jo være riktig å falle det final? Er jeg helt på jordet her?

 

Den orginale påstanden min var jo at spesifikasjonene var dårlige og lite lesbare, og dermed potensielt vanskeligere å utvikle for. Hvordan kan du fortsatt mene dette er FUD?

 

Enkelt og greit: Vis spesifikasjonene og formatet er ferdig utviklet, kan man si at dokumentasjonen mangler. Er ikke formatet ferdig utviklet, så kan man ikke klage på annet en dokumentasjon under veis.

De søkte ikke på IEFA(mulig jeg skrive feil, poenget er at de tilsvarer ISO) før en noen dager siden, og når den er på plass er det litt mer arbeid.

Etter dette punktet derimot, kan man begynne å klage.

RC != Final

Hello! Google sier at det ikke kommer bedre dokumentasjon, og akter å bruke formatet AS IS. Det kan da ikke være feil å da klage på at dokumentasjonen er dårlig?

 

Mener du det ville være feil å klage på nedetid hos f.eks. Gmail, dersom google bestemte seg for å å aldri fjerne beta merkingen og i tillegg sa at de anser produktet som godt nok, og aldri vil gjøre det bedre?

 

La oss si du skriver et plugin mot Gmail, så lenge betamerket er der, har du ikke mye å klage på vis de forander på kode som gjør at plugin du lager blir inkompatibel.

Vis selve tjenesten feiler, så er det en annen sak.

[hernil]

Senarioet ditt virker veldig veldig hypotetisk. Jeg tror faktisk vi står ganske trygt om vi velger å eventuelt spesifisere WebM i video-tagen NÅR det kommer et OS, som er brukt av en betydelig mengde mennesker, som ikke har denne muligheten.

Det er faktisk ikke så fjernt som du skal ha det til. Mindre produsenter som vil slå gjennom med sine egne løsninger. F.eks mediespillere, mobiltelefoner, nettbrett eller tv-er for den saks skyld er ikke gitt at har ressurser eller mulighet til å betale royalties. Ikke noe problem i dag for deg kanskje, men når det neste Google eller en liten aktør vil starte "Spotify for video" med streaming fra nett, så vil ikke det være mulig uten å betale royalties og det dreper innovasjonen!

 

Faktisk vil jeg si at bruk av OS codecer per i dag er den beste løsningen, siden det gir best gjennbruk av programvare. De som lager nettleserne bør etter min mening konsentrere seg om selve nettleseren, ikke om å finne opp hjulet på nytt i forhold til dekodere til video.

Kanskje, men hva hvis noen har laget en dekoder til mediespilleren sin som er langt mer effektiv og som andre vil benytte seg av? F.eks Mozilla finner en implementasjon i sin nettleser til mobile enheter svært gunstig da den er strømsparende? Da er de låst til OS-ets dårligere kodeker som kanskje aldri vil bli oppdatert hvis de sitter på noe annet enn det nyeste av det nye.

H264 er allerede en de-facto standard, og kan egentlig ikke få særlig større markedsandel på nettvideo, spiller ingen rolle hva slags valg vi gjør nå, da situasjonen ikke kan bli særlig bedre for H264. I tillegg burde jo overgangen fra H264, selv med lik støtte, være kjapp, dersom WebM viser seg å bli et bedre format på alle punkter fremover.

Selvfølgelig spiller det en stor rolle hvilke valg vi tar nå! At situasjonen nå er ille betyr ikke at vi ikke skal endre på dette? Så siden situasjonen egentlig ikke kan bli bedre for Adobe og flash så burde vi ikke gjøre noe? Skjønner virkelig ikke tankegangen ... Poenget med denne overgangen er at noen må ta det første skrittet. Sitter man bare på gjerdet og venter vil ingen benytte seg formatet, ingen vil implementere det og ingen vil utvikle hardwarestøtte og sånn har du skapt en loop det ikke er enkelt å komme seg ut av - særlig hvis et annet format har kuppet posisjonen.

Du må også huske på, som jeg har påpekt flere ganger, at H264 ikke blir borte, selv om nettleserne fjerner støtten. Flash vil fortsatt eksistere, og for tilbyderne vil det mest sannsynlig være billigere å bare beholde flash, fremfor å reenkode alt. Det vil altså eksistere et behov for å beholde flash installert for legacy, noe som er betydelig verre enn å bare bruke OS-støtten for H264 (uansett hvor kortsiktig du føler dette er).

La oss anta man er avhengig av flash for legacy. Om en stund vil flash støtte WebM og argumentet er ikke lenger gyldig. Og uansett så har jeg stor tro på at flash ikke vil være nødvendig for å se video på nettet om 5 år. Det er klart tilbyderne tenker seg om to ganger før de konverterer hele biblioteket sitt til et format som ikke er sikkert vil ta av (situasjonen per idag), men når det er etablert som standard er det ingen grunn til at de ikke skulle kunne gjøre det. Hvis youtube kan konvertere alt innholdet sitt så kan alle andre det også. Dessuten er ikke dette noe som er uvanlig å gjøre i bransjen uansett hvis vi skal tro JohndoeMakt som jobber med dette

[Turgon]

Hæ? Google sier her at de ikke kommer til å gjøre noe mer med spesifikasjonen (i overskuelig fremtid). Uavhengig om de sier det er ferdig eller ikke, så må det jo være riktig å falle det final? Er jeg helt på jordet her?

 

Den orginale påstanden min var jo at spesifikasjonene var dårlige og lite lesbare, og dermed potensielt vanskeligere å utvikle for. Hvordan kan du fortsatt mene dette er FUD?

 

Enkelt og greit: Vis spesifikasjonene og formatet er ferdig utviklet, kan man si at dokumentasjonen mangler. Er ikke formatet ferdig utviklet, så kan man ikke klage på annet en dokumentasjon under veis.

De søkte ikke på IEFA(mulig jeg skrive feil, poenget er at de tilsvarer ISO) før en noen dager siden, og når den er på plass er det litt mer arbeid.

Etter dette punktet derimot, kan man begynne å klage.

RC != Final

Hello! Google sier at det ikke kommer bedre dokumentasjon, og akter å bruke formatet AS IS. Det kan da ikke være feil å da klage på at dokumentasjonen er dårlig?

 

Mener du det ville være feil å klage på nedetid hos f.eks. Gmail, dersom google bestemte seg for å å aldri fjerne beta merkingen og i tillegg sa at de anser produktet som godt nok, og aldri vil gjøre det bedre?

 

La oss si du skriver et plugin mot Gmail, så lenge betamerket er der, har du ikke mye å klage på vis de forander på kode som gjør at plugin du lager blir inkompatibel.

Vis selve tjenesten feiler, så er det en annen sak.

Hvis de sier at deres produkt er final, så kan jeg jo selvagt klage, selv om de beholder betamerket.

 

Hele poenget her er jo at det kan være vanskelig å utvikle for WebM spesifikasjonene, fordi det er dårlig dokumentert. Google vil at vi skal utvikle for WebM, men sier samtidig at dokumentasjonen er final. Da mener jeg at man kan klage på dokumentasjonen.

[del_diablo]

Hvis de sier at deres produkt er final, så kan jeg jo selvagt klage, selv om de beholder betamerket.

 

Hele poenget her er jo at det kan være vanskelig å utvikle for WebM spesifikasjonene, fordi det er dårlig dokumentert. Google vil at vi skal utvikle for WebM, men sier samtidig at dokumentasjonen er final. Da mener jeg at man kan klage på dokumentasjonen.

 

Vil anbefale deg å lese hva RC(Release Candidate) betyr.

Men kan du linke til en blogg som ikke er hostet av MPEG-LA, hvor posten er mindre enn en uke gammel, som sier at speccen er uforkommen og mangelful?

Eller en plass på google sin bugtracker som sier det samme?

[Turgon]

Hvis de sier at deres produkt er final, så kan jeg jo selvagt klage, selv om de beholder betamerket.

 

Hele poenget her er jo at det kan være vanskelig å utvikle for WebM spesifikasjonene, fordi det er dårlig dokumentert. Google vil at vi skal utvikle for WebM, men sier samtidig at dokumentasjonen er final. Da mener jeg at man kan klage på dokumentasjonen.

 

Vil anbefale deg å lese hva RC(Release Candidate) betyr.

Men kan du linke til en blogg som ikke er hostet av MPEG-LA, hvor posten er mindre enn en uke gammel, som sier at speccen er uforkommen og mangelful?

Eller en plass på google sin bugtracker som sier det samme?

Herregud, dette er snakk om en x264 utvikler som også er med å utvikler enkoder til WebM (med store hastighetsforbedringer). Dette er altså en kar som har vært igjennom spesifikasjonen og vet hva han snakker om.

 

Hvis du vil knytte denne personen til MPEG-LA, så må du dokumentere denne påstanden.

 

Jeg vet hva RC betyr. Hvor står det forresten at spesifikasjonen til WebM har denne merkelappen (selv om det ikke har noe å si, siden de ikke vil gjøre noe mer med det)?

[Turgon]

Senarioet ditt virker veldig veldig hypotetisk. Jeg tror faktisk vi står ganske trygt om vi velger å eventuelt spesifisere WebM i video-tagen NÅR det kommer et OS, som er brukt av en betydelig mengde mennesker, som ikke har denne muligheten.

Det er faktisk ikke så fjernt som du skal ha det til. Mindre produsenter som vil slå gjennom med sine egne løsninger. F.eks mediespillere, mobiltelefoner, nettbrett eller tv-er for den saks skyld er ikke gitt at har ressurser eller mulighet til å betale royalties. Ikke noe problem i dag for deg kanskje, men når det neste Google eller en liten aktør vil starte "Spotify for video" med streaming fra nett, så vil ikke det være mulig uten å betale royalties og det dreper innovasjonen!

Klarer ikke å se at dette blir et problem for noen av tingene du nevner. Nettsider kan jo velge WebM dersom de skal driver kommersielt, eller H264 gratis dersom de skal drive ikke-kommersielt.

 

Hardware-enheter koster vanligvis penger, så det skulle ikke være noe problem å betale for codecstøtte. Koster jo ikke allverden per enhet heller.

Faktisk vil jeg si at bruk av OS codecer per i dag er den beste løsningen, siden det gir best gjennbruk av programvare. De som lager nettleserne bør etter min mening konsentrere seg om selve nettleseren, ikke om å finne opp hjulet på nytt i forhold til dekodere til video.

Kanskje, men hva hvis noen har laget en dekoder til mediespilleren sin som er langt mer effektiv og som andre vil benytte seg av? F.eks Mozilla finner en implementasjon i sin nettleser til mobile enheter svært gunstig da den er strømsparende? Da er de låst til OS-ets dårligere kodeker som kanskje aldri vil bli oppdatert hvis de sitter på noe annet enn det nyeste av det nye.

Først og fremst, så vil jeg si det virker usannsynlig for meg at nettleserutviklere har nødvendig ekspertise på video-dekodere til å lage signifikant bedre støtte enn det OS-produsentene kan, i hvertfall uten å ha seriøst dårlig sans for prioritering.

 

For det andre. De kan fint gjøre dette for WebM om de ønsker. Det ville jo i så fall kunne styrke WebM i forhold til H264.

 

Uansett burde slik utvikling skje på lavest mulig nivå, slik at andre programmer kan nyte godt av endringene.

H264 er allerede en de-facto standard, og kan egentlig ikke få særlig større markedsandel på nettvideo, spiller ingen rolle hva slags valg vi gjør nå, da situasjonen ikke kan bli særlig bedre for H264. I tillegg burde jo overgangen fra H264, selv med lik støtte, være kjapp, dersom WebM viser seg å bli et bedre format på alle punkter fremover.

Selvfølgelig spiller det en stor rolle hvilke valg vi tar nå! At situasjonen nå er ille betyr ikke at vi ikke skal endre på dette? Så siden situasjonen egentlig ikke kan bli bedre for Adobe og flash så burde vi ikke gjøre noe? Skjønner virkelig ikke tankegangen ... Poenget med denne overgangen er at noen må ta det første skrittet. Sitter man bare på gjerdet og venter vil ingen benytte seg formatet, ingen vil implementere det og ingen vil utvikle hardwarestøtte og sånn har du skapt en loop det ikke er enkelt å komme seg ut av - særlig hvis et annet format har kuppet posisjonen.

Tankegangen er som følger: Slik situasjonen er per i dag vil støtte for begge formatene mest sannsynlig føre til en kjapp overgang til video-tag. Det er også slik at man kan bruke H264 uten nevneverdige problemer. Og siden H264 ikke kan bli særlig større, så er det heller ikke noe poeng per i dag å hindre veksten. Skulle forholdene endre seg derimot, så kan man jo eventuelt droppe H264 støtte.

 

Du må skjønne at jeg ikke ser på overgang fra H264 til WebM som et mål i seg selv.

 

Du må også huske på, som jeg har påpekt flere ganger, at H264 ikke blir borte, selv om nettleserne fjerner støtten. Flash vil fortsatt eksistere, og for tilbyderne vil det mest sannsynlig være billigere å bare beholde flash, fremfor å reenkode alt. Det vil altså eksistere et behov for å beholde flash installert for legacy, noe som er betydelig verre enn å bare bruke OS-støtten for H264 (uansett hvor kortsiktig du føler dette er).

La oss anta man er avhengig av flash for legacy. Om en stund vil flash støtte WebM og argumentet er ikke lenger gyldig. Og uansett så har jeg stor tro på at flash ikke vil være nødvendig for å se video på nettet om 5 år. Det er klart tilbyderne tenker seg om to ganger før de konverterer hele biblioteket sitt til et format som ikke er sikkert vil ta av (situasjonen per idag), men når det er etablert som standard er det ingen grunn til at de ikke skulle kunne gjøre det. Hvis youtube kan konvertere alt innholdet sitt så kan alle andre det også. Dessuten er ikke dette noe som er uvanlig å gjøre i bransjen uansett hvis vi skal tro JohndoeMakt som jobber med dette

Med "legacy" mente jeg at dersom man dropper H264 støtte fra video-tagen, så vil man trenge flash for å spille H264 video, til alt er erstattet med WebM (som realistisk sett aldri kommer til å skje).

 

Spiller ingen rolle om flash får støtte for WebM for dette, eller er det jeg som surrer?

 

Youtube, eid av Google (rikt selskap og utgiver av WebM) har både ressurser og motivasjon til å gjøre denne konverteringen. Andre nettvideoleverandører har ikke nødvendigvis disse tingene.