[NUUG video] Innspill til NRK ang. fremtidens nett-tv

Håvard Espeland gus at ping.uio.no
Thu May 21 12:57:26 CEST 2009


Denne mailen begynner å bli veldig lang, så jeg tar meg frihet til å
kutte litt.

On Thu, May 21, 2009 at 10:44:03AM +0200, Jarle Bjørgeengen wrote:
(...)
>>
>> Det spørs litt på hvilket bruksscenario man ser for seg. Skal man  
>> gjøre
>> livestreaming ønsker man gjerne hardware-kodere for å sikre stabilt
>> signal slik som denne for VC-2 (brukt av BBC under OL):
>>
>
> Vi snakker da internt ( hardware til hardware ?) i BBC , for å få mest  
> mulig ut av linjer med med lav båndbredde ?
>

VC-2 er for postproduksjon, redigering, osv. BBC og sikkert andre på
sikt bruker bl.a denne kodeken internt til dette.

>> http://www.numediatechnology.com/brochures/dp1.5lowres.pdf
>>
>> Hvis ikke realtime er en krav er det selvfølgelige enklere;
>
> Silverlight er vel kun software ? Jeg tror kanskje vurderingen begrenser 
> seg til softwarløsninger ?

Silverlight er software, men kodeken som koder livesendinger i høy
oppløsning er neppe det.

>
>> da kan
>> referanseimplementasjonen brukes om man så må fordi ytelse ikke er så 
>> viktig.
>> Uansett mener jeg det største problemet er på avspillersiden. Nå
>> argumenterer jeg for uerfarne Windows-brukere - de som er den største
>> brukermassen. Så vidt jeg vet er vlc den eneste avspilleren av Dirac  
>> for
>> Windows, og min erfaring er at dette er et program som integrerer  
>> dårlig
>> i nettlesere i forhold til Flash eller SilverLight. Det er for øvrig
>> ingenting i veien for at de to sistnevnte skal på sikt støtte Dirac  
>> hvis
>> den bli en standard, eller at andre avspillere blir tilgjengelig, men
>> per dags dato er avspiller et problem.
>>
>
> Ingenting som ikke kan fikses med innkjøp av utviklertjenester ,  
> istedenfor lisensavgifter.

Sant.

>
>> Jeg har dessverre ikke brukt Dirac selv og vet dermed ingenting om
>> ytelsen, men min magefølelse er at avspillingen er rimelig
>> prosessorkrevende - først og fremst fordi den er såpass umoden. Dette
>> kan kanskje noen andre her svare på? Når det gjelder ytelsen på andre
>> kodeker, og da spesielt h.264 er dette noe som er (og vil bli)
>> hardwareakselerert på mange maskiner. Dette vil først og fremst ha noe 
>> å
>> si for kommende svake maskiner som Netbooks og lette klienter.
>>
>
> En løsning bør vel ikke _kun_ basere seg på h.264 eller evt. dirac, men 
> ha alternativer som er mindre prosessorkrevende. Det er vel også slik at 
> oppløsning og bildekvalitet har en viss betydning for prosesseringsbehov 
> selv innenfor h.264 og dirac ?
>

Det er en god løsning å tilby innholdet i flere formater. Når det
gjelder prosesseringsbehov er dette noe som er veldig
implementasjonsavhengig. Det er ikke slik at bare fordi en kodek er
standardisert eller "ferdig" at man vet hvordan enkoderen og dekoderen
skal skrives; det kommer hele tiden nye vitenskaplige artikler om
tenkikker som kan brukes i f.eks h.264 og som er fullt ut kompatibelt
med formatet. Dessverre kommer noen av disse også som patenter samtidig.

(...)

>> Alternativet er å tenke nytt og benytte teknikker som ikke er gjort
>> før. Honnør til BBC som er sitt ansvar bevisst og bruker penger på å
>> utvikle Dirac, men selv de bruker ikke dette som streamingløsning  
>> utad!
>> På lang sikt skjer det nok mye når det gjelder videoformater og
>> -løsninger, men som nevnt tidligere oppfattet jeg forespørselen som et
>> litt kortere perspektiv.
>>
>
> Jeg synes det er fint at vi ikke utelukker de langsiktige vurderingene, 
> da de er viktige. NRK kan bruke innspillene for det de er verdt uansett.
>
>
>> Jeg tror derfor man bør satse på å sikre at materialet blir
>> tilgjengelig med full kvalitet i et standardisert format som h.264  
>> eller
>> vc-1.
>
> Jeg tror det er viktig at man driver frem en standard som i realiteten  
> er helt åpen, og er forberedt på ta evt. rettsaker for å tilbakevise  
> latterlige patent-tildelinger. Komersielle private selskaper kommer ikke 
> til å kjøre slike rettsaker til endes. En sammenslutning av europeiske 
> allmennkringkastere _bør_ gjøre nettopp det.

Denne lille diskusjonen har vist at det er viktig å skille mellom flere
ting for å kunne komme med en slags anbefaling:

 - Kort og langsiktig perspektiv

 - Kodek og avspiller

 - Standard og produsentstyrt spesifikasjon

Jeg har i hovedsak argumentert for kodek- og avspillervalg på kort sikt.
På lengre sikt er jeg enig med deg; NRK bør benytte et format og en
plattform som er tilgjengelig for alle og kan implementeres og benyttes
av alle - uten vederlag!

Problemet her er at det ikke finnes noen ferdig tilgjengelig løsning
hvor man kan si "Velg dette produktet i stedet for Silverlight så er
alle fornøyd". For å lage en slik løsning trengs det store beløp og
kanskje år med utvikling. Selvsagt, jeg mener at NRK bør være sitt
ansvar som allmennkringkaster bevisst og gjennomføre dette. Men de må
være ganske klar over hvorfor de skal bruke så mye ressurser i stedet for
å bare kjøpe en løsning av Microsoft for en rimelig penge.

Den åpenlyse "løsningen" på kort sikt er å tilby innholdet i Theora. Da
dette er en langt dårligere kodek enn den de bruker i dag ville jeg hatt
store problemer med å erstatte den. En mulighet er, som du nevnte, å
tilby Theora som et alternativ. For NRK vil dobbeltlagring av alle klipp
og høyere båndbredde for å vise i samme kvalitet som "primærkodeken"
være klare ulemper. Alternativt kan man sette ned kvaliteten på
Theora-klippene i forhold til primærkodeken for å bruke like mye disk og
båndbredde for å vise dem.

Som sluttbruker (og Linuxbruker) er det viktigste for meg at jeg får
innholdet i best mulig kvalitet til lavest mulig båndbredde i en godt
støttet avspiller. Hvis samme video er tilgjengelig i h.264/vc-1 og
samtidig i Theora er det knekkende likegyldig for meg om NRK har betalt
patentløsepenger for å kjøpe enkoderen, så valget er ganske enkelt.
Samtidig er det like uviktig for Nrk om jeg har betalt løsepenger via
Microsoft til patentinnehaverne som en del av Windows-lisensen, eller om
jeg har lastet ned en fri implementasjon av kodeken som i vlc.

(...)

-- 
Håvard Espeland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3622 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/video/attachments/20090521/311f2a5e/attachment.bin 


More information about the video mailing list