DR kan ikke bruge HTML5 til video

Danmarks Radio har ingen planer om at skifte Flash-afspilleren ud med en kombination af HTML5 og H.264-videoformatet, selvom der kan være fordele ved de nye teknologier.

Den kommende HTML5-standard, som giver mulighed for indlejring af video i en webside uden behov for plugins, får ikke umiddelbart Danmarks største website til at skifte hest.

»Vil vil ikke ændre noget i vores netbroadcast på grund af HTML5. Vi vil efter sommer komme med et nyt Dr.dk-tv med H.264, afviklet i Flash, og med direkte links for dem, som vælger at afvikle i en anden player. Men vi følger HTML5 nøje. Det ser ud som om, der er både fordele og ulemper,« skriver Erik Nørgård Gravesen, som er redaktør i DR's ON Demand-afdeling, i en email.

Blandt ulemperne ved kombinationen af HTML5 og H.264 nævner han:

»Firefox understøtter HTML5, men ikke H.264, så hvis vi valgte HTML5 vil vi udelukke mange. Vi er ikke sikre på, at man kan det samme med hensyn til navigation i videofeltet, som man kan med Flash. Det vil bl.a. forringe mulighederne i fuldskærmsversion. Man kan ikke streame med HTML5, men kun bruge progressiv download. Dette vil forringe oplevelsen i forbindelse med at spole.«

Ved progressiv download overførers videosignalet via HTTP-protokollen, men med begrænsede muligheder for at hoppe frem og tilbage i videoklippet.

Men der er også forhold, som taler for HTML5 og mod Adobes Flash-afspiller:

»H.264, som afvikles i en Flash-player, kan være belastende for CPU'en, specielt hvis computeren ikke har et hardware-acceleret grafikkort og Flash-player i version 10.1. Det kan give problemer med f.eks de nye små netbooks. Hvor vidt det er et problem, er vi ved at undersøge. Hvis vi tilbyder video i HTML 5, vil det ikke være et problem. Nye telefoner og f.eks. den nye iPad understøtter HTML 5, hvilket giver muligheder for at afspille video på almindelige websider.«

Der kan på sigt også blive tale om en kombination af teknologier, skriver han:

»Vi vil følge HTML5 og dets muligheder og begrænsninger og se, om HTML 5 kan være et spændende supplement til H.264 i Flash-player og direkte links, men vi har pt. ikke nogle konkrete planer.«

Microsoft har for nylig tilkendegivet, at H.264-formatet vil blive det eneste, som firmaet vil understøtte i den implementering af HTML5, der følger med den kommende version af Internet Explorer. Det samme gælder Apple. Begge firmaer har i øvrigt en ejerandel af konsortiet MPEG LA, som har retten til det beskyttede H.264-codec.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (45)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jimi Hansen

http://camendesign.com/code/video_for_everybody

Video for Everybody is simply a chunk of HTML code that embeds a video into a website using the HTML5 <video> element, falling back to Flash automatically, without the use of JavaScript or browser-sniffing. It therefore works in RSS readers (no JavaScript), on the iPhone / iPad (don’t support Flash) and on many, many browsers and platforms.

  • 0
  • 0
Bjarne Rasmussen

DR's holdning er helt rigtigt. De skal på ingen måde være frontløbere i teknologiræset, men der i mod holde hus med de surt betalt licenspenge de har fået stillet til deres rådighed.

HTML 5 er som stadart kun er i sin vorden og forventes først godkendt om ti år og der forgår lige nu en mindre kamp om video-standarten i HTML 5 (VP8 vs. H.264)

En investering i HTML 5 står slet ikke må med de få brugere som pt. kan tilgå denne og når først procentdelen af bruger med HTML 5 browsere er røget i vejret er standarten formodentlig alligevel ændret og der skal en ny løsning/investering til.

  • 0
  • 0
Martin Andersen

Nu er der jo ingen forskel på om du vil afvikle H.264 i HTML5 eller Flash mht. graffikkort, så den information kan godt være lidt misvisende.
Det eneste som er relevant er om brugeren har Flash 10.1, og så er det jo bare et spørgsmål om lidt tid, inden inden største delen har Flash 10.1.

  • 0
  • 0
Anton Lauridsen

Jeg er ikke 100% sikker, men er h.264 ikke dækket af et patent, og kræver at der betales licens til MPEG konsortiet? Som jeg har forstået det var det årsagen til at HTML5 kommiteen indtil videre helt har droppet at uddybe <video> tagget.

Vi der ikke benytter Windows har i forvejen svært ved at have glæde af vores medie-licens, jeg synes ikke det vil være rart hvis DR gør det endnu sværere at se DR's programmer på nettet.

  • 0
  • 0
Jørgen Larsen

En lang række firmaer har del-patenter i H.264/AVC i gennem MPEG LA bla. Apple, Microsoft, Sony, Panasonic. Formatet er delvist royalty frit for slutbrugere indtil 2015 og patentet udløber i 2028 (Nok lidt teoretisk at en specifik videokompressionsteknologi skal overleve så længe)

  • 0
  • 0
Anton Lauridsen

Om software patenter er tvivlsomme skal jeg ikke kunne sige, jeg har hørt begge dele, og er ikke selv vidende nok til at kunne modsige hverken den ene eller den anden ekspert.

I forb. med HTML5 er tvivlen vel ligegyldig, da standarden er en global ting.

  • 0
  • 0
Johnny Olesen

Det sjove er, at DR sagtens kan finde ud af at streame via HTTP. Man tager sin iPhone og går ind på m.dr.dk og vælger et af DR Updates videoklip og wupti så ser man video via HTTP og der virker fint.

Hvorfor kan DR ikke gøre det samme på DR.dk? Måske skulle de bare gøre som Jimmi Hansen foreslår i det første indlæg - men det er måske for svært for DR?

  • 0
  • 0
Johnny Olesen

"Man kan ikke streame med HTML5, men kun bruge progressiv download. Dette vil forringe oplevelsen i forbindelse med at spole."

Hmmm - Det med at spole virker ellers ganske udemærket på YouTube via HTML5 og Chrome - også selvom videoklippet ikke er hentet 100% ned.

  • 0
  • 0
Nick Frederiksen

YouTube streamer heller ikke. Videoen hentes før den vises. Dvs. når den er hentet kan du spole frem og tilbage uden at den skal hente klippet igen. Ved streaming skal der hentes data fra det sted du ønsker at se klippet, også selvom du lige har set det. Med mindre dataene stadig ligger i bufferen.

  • 0
  • 0
Bjarne Rasmussen

"...patentet udløber i 2028... Nok lidt teoretisk at en specifik videokompressionsteknologi skal overleve så længe"

Gif-animationen lever vist stadig i bedste velgående (gif 1987), så hvis først H.264 bliver en del af HTML standarten kan det godt gå hen og få betydning.

For mig virker det tit som om at de store hader hinanden (f.eks M$ vs. Appel) men når det gælder om at mule opkomlingen står de samme og bruger løs af deres patenter.

  • 0
  • 0
Nils Bøjden

Dette er faktisk en klokkeklart dilemma:

Skal staten/fællesskabet/DR satse/bruge patenterede teknologier med risiko for at ikke alle er i stand til at modtage udsendelserne, men hvor de patenterede teknologier enten er teknologisk overlegne eller massivt sponsoreret af distributører.

Eller skal der satses på ikke patenterede teknologier som alle kan bruge, men hvor der enten skal ydes en særlig indsats for at bruge teknologien grundet manglende sponsorering af distributører, eller produktet er teknologisk underlegent.

  • 0
  • 0
Martin Kofoed

Med valget af h.264 står DR stadig en hel del bedre end konkurrenterne hos TV2, der med sin Sputning-satsning stadig maler sig op i WMV-hjørnet.

Video på nettet er stadig under modning. En dag har vi et royalty-frit og åbent format at putte i vores video-tags, men desværre går der nok lidt tid endnu. Selv om Google så skulle åbne op for On2/VP8, kræver det stadig support fra Apple og Microsoft. Med mindre Google tør gå linen ud og KUN tilbyde VP8 på YouTube, naturligvis! Det kunne være et frisk træk.

Jeg mener ikke, man kan klandre DR for at vælge h.264 her og nu. Det er det tætteste, vi kommer på en defacto-standard, og der findes åbne encoders i rigtig høj kvalitet.

  • 0
  • 0
Jakob Damkjær

Eftersom stort set alle digital bokse (dem som vi alle har i en eller anden form som vi fik med det digitale sendenet...) har mpeg4 og dermed h.264 (mpeg4 part 10)... Så DRs indhold er allerede kodet i h.264.

Om VP8 virkelig er konkurance dygtig på kvalitet og baseret på så radikalt anderledes teknologi at MPEG-LAs patent portfolio udgør en så begrænset risiko at virksomheder vil vudere risikoen for blive sagsøgt er minimal.

Hvis man vil se på hvor grundigt Google undersøger patenter, så kan man se hvor langt HTC kom med at tro på at fordi Android OS var gratis skulle de ikke betale... Istedet kom HTC istedet til at betale microsoft i et forlig uden for retsalen og Apple er ved at få deres del af HTC android kagen. Den juridiske sårbarhed som HTC addopterede fra Google gennem Android er HTC sikker fantastisk lykkelige over ligeså deres aktieejere...

  • 0
  • 0
Thomas Christensen

Mig bekendt er Ogg Theora et helt frit og åbent format?!

Jeg er klar over den mangelfulde browserunderstøttelse, men hvis jeg kunne få noget for tvangslicensen, så ville jeg stemme for, at det åbne format blev default, evt. med et fallback til h.264, så alle kan være med. Dog kan Theora afspilles i IE med fx VLC-plugin.

  • 0
  • 0
Anton Lauridsen

@THOMAS
Som jeg husker det var både h.264 og Ogg Theora på banen i forb. med HTML5 video tagget. Men Microsoft ville ikke acceptere Ogg og problemerne med patenter på H.264 gjorde at begge forslag røg ud i kulden, med det resultat at alle detail specs omkring video tagget - indtil videre - blev pillet ud af forslaget til HTML5.

Uden at være ekspert synes jeg dog det ser ud til at DR gør det rigtige omkring brugen af HTML5 og <video> tagget.

  • 0
  • 0
Jakob Damkjær

på mobil platformen. Manglen på hardware acceleration er en nogo, samtidigt med at Ogg T for tiden ikke kan levere samme kvalitet som de bedste h.264 encodere...

Og bare fordi noget er gratis betyder det ikke at det ikke er dækket af patenter.
Yes yes der har ikke været nogen patentsøgsmål endnu og FUD FUD FUD men den sag virker det som om snart bliver afgjort eftersom MPEG-LA gruppen for tiden samler materiale til at undersøge om de mener om Ogg T overtræder nogen af de patenter som de håndtere.

Desuden så kan alle dem der mener at MPEG-LA bare venter til 2015 med at lave en Unisys GIF redo (for et hvert firma som tjener penge på h.264 vil sikkert gerne ha at deres samlede format øjeblikkeligt afgår ved døden). Desuden er Unisys MPEG-LA sammenlignningen ret meget ude i hampen af andre årsager. MPEG-LAs MPEG4 format er dækket af MPEG-LAs egne patenter, Unisys solgte ikke GIF formatet. Derfor havde de ingen interesse i at gif forsatte med at være et format, det har MPEG-LA da MPEG4 er deres levebrød.

Samtidigt er det en del af MPEG-LA forhandlings kontrakten at de faktiske priser maksimalt kan stige med 10% ved hver genforhandling... og pt er deres horible priser ca 0,01 USD per DVD man sælger hvis man fx laver bryllupsvideoer... wow virkeligt totalt CRAZY priser. Men hvis ens marginer er så lave at et par cent gør en forskel så har man for små marginer.

Så meget af det usikkerhed der fare rundt på internettet pt er en storm i et glas vand.

For valget står ikke mellem Ogg T og h.264, men mellem h.264 i html5 og h.264 i flash.

Grunden til at DR pt vælger flash er i hovedsagen at firefox kun vil understøtte et h.264 gennem et proprietært plug in (Adobes flash).

Lidt hyklerisk hvis man er på den høje opensource hest, at det er ok at
bruge h.264 iso mpeg4 formatet men kun så længe det er pakket ind i
en ikke isostandart proprietær indpakning...

Desuden så kan man bruge Sublime eller ligende javascript så kan alle browsere få hvad de vil ha men det er nok ikke kompatibelt med DRs medie CMS system...

http://jilion.com/sublime/video

/Jakob

  • 0
  • 0
Martin Kofoed

Desuden så kan man bruge Sublime eller ligende javascript så kan alle browsere få hvad de vil ha men det er nok ikke kompatibelt med DRs medie CMS system...

Øhm.. Har du set, hvad det er Sublime gør?

[code=xml]
<source src='' title='http://medias.jilion.com/sublimevideo/dartmoor.mov&#039; type='video/mp4' />
<source src='' title='http://medias.jilion.com/sublimevideo/dartmoor.mp4&#039; type='video/mp4' />
<source src='' title='http://medias.jilion.com/sublimevideo/dartmoor.ogv&#039; type='video/ogg' />
[/code]

De gør det, som ingen i virkeligheden ønsker: vedligeholder tre udgaver/transcodings af det SAMME indhold. Det har intet med DR's CMS at gøre.

Jeg tror, det bliver et valg mellem h.264 og VP8 (hvis ellers Google selv går all-in). Lige nu får man den bredeste understøttelse ved at have alt sit indhold som h.264. Nogle browsere kan benytte det direkte i video-tag'et, andre skal via en indlejret flash-applikation.

Ogg Theora tror jeg heller ikke på mere, men det skyldes mere manglende kvalitet per kb bitrate end om det lige er et åbent eller lukket format.

  • 0
  • 0
Mikkel Kruse Johnsen

"Grunden til at DR pt vælger flash er i hovedsagen at firefox kun vil understøtte et h.264 gennem et proprietært plug in (Adobes flash)."

Firefox må ikke inkludere en h.264 afspiller, med mindre de betaler MPEG LA group. Det koster vist 5 mio om året. Men det vil ikke give linux versionerne ret til at afspille det, de de om compiler firefox og licensen kan ikke nedarves på den møde. Så det er ikke muligt. Adobe må have betalt for at få lov at afspille h.264 og deres plugin er binært kan de bruges.

"og pt er deres horible priser ca 0,01 USD per DVD"

Du skal huske at du ikke må bruge dit digitale kamera til commercial brug, med mindre du betaler MPEG-LA for retten.

Når du så har købt retten til at lave commacielle videoer, skal du betaler for alle som ser den på nette. Det kan godt være at DVD'en er billig nok. Men vi lever i en digital alder hvor man ser tingene på nettet.

"priser maksimalt kan stige med 10%"

Ja men efter 2015 kan de ændre retten til at vise ikke commacielle klip på nettet. Dvs. så skal alle som viser noget optage med deres kamera betale for det og den som ser det skal også.

  • 0
  • 0
Anton Lauridsen

@JAKOB: Personligt tror jeg ikke det er hykleri, Mozilla Foundation har ganske simplet ikke noget valg. Der har over tid været så mange forskellige mennesker der har givet patches til Firefox baseret på MPL.

De betingelser der stilles for at linke H.264 direkte ind i koden er uforenelige med MPL, Mozilla kan ikke - selvom de skulle ønske dig - gå bort fra MPL, uden at få accept fra samtlige copyright holdere, hvilket i praksis er umuligt.

Jeg tror snarre at vi - endnu engang - ser hvordan "copy-lefts" og "copy-right" er totalt inkompatible.

  • 0
  • 0
Christoffer Holm Kjølbæk

Ja, men de streamer ikke, de sende blot hele klippet og så kan de afspiller vise det.

Som der står i artiklen "kan man ikke streame med HTML5, men kun bruge progressiv download. Dette vil forringe oplevelsen i forbindelse med at spole."

Det er muligt dette virker på Youtube med 2 minutter i dårlig kvalitet, men vil man se de sidste fem minutter af et program på 60 minutter, så skal de første 55 minutters video hentes først. Hvorimod med flash løsningen kan afspilleren fortælle serveren at den skal starte efter 55 minutter.

Dog kan man i f.eks. Firefox resume et download, hvilket vel må betyder at man i sit HTML request kan fortælle hvor langt inde i filen der skal sendes fra. Så hvis man kunne fortælle browseren at 1 minut svarer til xx MB, så kunne man vel godt lave en spol function?

  • 0
  • 0
Johnny Olesen

Ja, jeg kan ikke se at det skulle være så svært.

Faktisk så har DR alle filerne klar til streaming i en ekstern afspiller. Filerne ligger i deres podcast sektion - de skal bare sætte en websnedker til at lave deres XML fil om til en HTML fil, og så kan vi alle sammen ENDELIG få adgang til DR programmer i MPEG4 uden brug af flash. Den løsning som DR først kan have klar efter sommerferien findes allerede - se f.eks. http://vpodcast.dr.dk/feeds/21_soendagrss.xml

Det vil tage en middelmådig websnedker en eftermiddag at lave en side, hvorfra man kan hente MPEG4 filerne ned og afspille dem i f.eks. quicktime, VLC eller en anden afspiller. Ja filerne virker sågar på en iPhone og en Android telefon.

Men kan DR afsætte en eftermiddag til dette "komplicerede" projekt? Nej nej - det er skam en ultra kompliceret løsning, som tager helt indtil efteråret... Ja måske efteråret i år - måske næste år.

Er der ikke en eller anden klog person der kan forklare mig, hvorfor DR skal bruge SÅ LANG TID på at lave en løsning, der ligger lige til højre benet?

  • 0
  • 0
Anton Lauridsen

@Johnny & Kristoffer
Det virker på mig som om i taler om helt almindelig streaming af video, som det allerede bruges i dag, og ikke det nye <video> tag der er en del af HTML5.

Hvis vi endelig skal "bashe" DR for deres nuværende implementering er det vel at deres løsning ikke fungerer synderlig godt på alle platforme.

  • 0
  • 0
Christoffer Holm Kjølbæk

@Johnny Deres Videopodcast er ikke i særlig god opløsning, men du kan hente rigtig mange af deres programmer den vej. Men det ændre jo ikke på, at hvis du vil se de sidste 5 min af en udsendelse, så skal du hente hele filen.

Jeg ser pt. Spise med Price der streames og har mulighed for at spole, hvilket virker glimrende på Linux med VLC.

@Anton Mit indlæg var nu ikke for at bashe DR, da jeg synes det levere nogle gode ting. Det var primært for at fortælle at DR ikke streamer over HTTP på deres mobil side som Johnny skrev. Plus at jeg har svært ved at se, hvorfor HTML5 ikke understøtter at spole, da jeg synes det lyder "simpelt" at implementere.

  • 0
  • 0
Johnny Olesen

@Anton Lauridsen: Jeg basher DR for begge dele. DR kan sagtens begynde at bruge HTML5 samtidig med at de stadigvæk har deres flash løsning som backup.

@ Christoffer Holm Kjølbæk: Jeg har formuleret mig forkert så. DR benytter progressiv download som overførerer videosignalet via HTTP-protokollen, når man f.eks. ser DR update på iPhone eller Android. Det virker helt fint og jeg forstår ikke hvorfor DR ikke bare giver mulighed for at benytte samme teknik på ALLE DRs udsendelser til f.eks. mobile-enheder.
At videokvaliteten af f.eks. DRs podcast ikke er helt i top kan heldigvis relativt let ændres.
Jeg kan bare ikke forstå at DR ikke bare for lagt alle disse direkte links til podcast ud på DR.dk. De kan lade sig gøre på Dr.dk/ding - hvorfor kan det så ikke lade sig gøre på resten af DR.dk?

  • 0
  • 0
Johnny Olesen

Jeg tager min iPhone, går ind på DR.dk/ding finder en udsendelse og vælger "se programmet med mac". iPhones filmafspiller begynder at afspille filen lige så flot og jeg springer hen midt i udsendelsen, et par sekunder senere forsætter udsendelsen. Det virker sgu da fint - jeg kan sagtens spole selvom filen ikke bliver streamet. Hvorfor er det så lige at det ikke kan lade sig gøre med HTML5? Hvad er forskellen?

  • 0
  • 0
Jakob Damkjær

"Jeg tror, det bliver et valg mellem h.264 og VP8 (hvis ellers Google selv går all-in). Lige nu får man den bredeste understøttelse ved at have alt sit indhold som h.264. Nogle browsere kan benytte det direkte i video-tag'et, andre skal via en indlejret flash-applikation. "

måske om lang tid... VP8 er pt en pie in the sky og selv om den har mulighed for hardware accelererer decode så er der pt intet hardware der har implementeret det eftersom det ikke eksistere endnu i andet end reklame materiale.

Og selv om Google har idiotisk meget regnekraft i data centrene vil det stadig tage et godt stykke tid at transcode hele Youtube...

Men lad os se giraffen og om de er konkurancedygtige med de bedste encodere der findes idag og om det er lykkedes dem at gøre det på en radikalt anderledes måde så de ikke kommer i kambolage med eksistrende patenter...

Jakob

  • 0
  • 0
Anton Lauridsen

@Christoffer Udfordringen med at spole ligger ikke i HTML som sådan, men specifikt med det nye <video> tag der er en del af den - langt ude i fremtiden kommende - HTML5 standard.

Den nyeste working draft (http://www.w3.org/TR/html5/video.html#video) er meget lidt sigende om hvordan HTML5 kompatible browsere skal implementere dette tag, bl.a. hvordan det skal være muligt at spole i indholdet, som det siges i WD af 12. maj "Which frame in a video stream corresponds to a particular playback position is defined by the video stream's format."

Men da der ikke er enighed om hvilke formater der skal understøttes af video tagget, kan jeg godt forstå at DR mener de har problemer med f.eks. at spole i en sådan video. Især når man indtænker den øgede kompleksitet som "controls" attributten vil give på en løsning der kan spole.

DR's indspark i debatten skal nok ses som et svar på Apples udmelding om at de ikke vil understøtte Flash på iPhone og iPad, men derimod ser HTML5 kombineret med video tagget som det eneste de ønsker at understøtte.

  • 0
  • 0
Anders Sørensen

Synes egentlig godt de kan begynde på lidt nytænkning hos DR. Tv over nettet er fremtiden, og når mange gerne vil ha mulighed for at benytte html5 ka de godt hæve licensen lidt for at få penge til at få det programmeret, testet etc., og få betalt de licenser således vi kan se programmer i ordentligt kvalitet.

  • 0
  • 0
Christian Schmidt

De gør det, som ingen i virkeligheden ønsker: vedligeholder tre udgaver/transcodings af det SAMME indhold.

Tja, det er måske lidt bøvlet, men der er nok ikke nogen vej uden om, hvis man både vil nå ud til alle brugere, og samtidig benytte moderne formater, der giver den bedste billedkvalitet for en given båndbredde.

Det kan godt være, at de fleste browsere og mobiltelefoner for tiden understøtter H.264, men lur mig om ikke der løbende kommer nye og bedre formater, som sikkert er omgærdet med tilsvarende patentproblemstillinger eller anden jura/politik som forhindrer dem i at blive alt for udbredt. Om få år vil H.264 sikkert være håbløst gammeldags og i øvrigt ikke længere royalty-frit, så der har vi balladen igen.

Derfor tror jeg lige så godt man som indholdsleverandør kan indrette sig på at kunne levere det samme indhold i forskellige formater. Det kræver selvfølgelig en investering i programmering, diskplads og CPU, men når først infrastrukturen er på plads, er det trods alt en automatiseret proces.

Pga. det evindelige bøvl med at få video til at fungere i selve browseren vil det i en årrække endnu også være et vist behov for at give brugerne forskellige muligheder for at afspille filerne, hhv. via <video>-tagget, via Flash-plugin og i en ekstern videoafspiller via et direkte link - og helst via såvel HTTP som en streamprotokol. I lighed med Johnny Olesen herover forstår jeg ikke, hvorfor DR gemmer de direkte links så langt væk.

  • 0
  • 0
Steen Petersen

Formatet er vel mindre væsentligt når den nødvendige kapacitet til at levere populære programmer i "høj kvalitet" ikke er til stede hos DR.

Da første omgang af "Forbrydelsen" var i gang, kunne man sagtens se programmet på et andet tidspunkt end kl. 20.00 søndag aften i det DR kalder "høj kvalitet".

Da anden omgang rullede over skærmen var det umuligt. Og DR's "mellem kvalitet" er altså anstrengende ringe at se på.

  • 0
  • 0
Anton Lauridsen

For at kunne spole, skal man vide hvor i bytestrømmen der skal læses fra.

Slideren til at spole er en del den brugergrænseflade som browseren stiller til rådighed. Når brugeren skubber til slideren, f.eks. 25% frem, skal der sendes en HTTP request til serveren, problemet er at vide hvor i bytestrømmen en placering på 25% er.

Denne placering er afhængig af det codec der benyttes. Da HTML5 ikke har nogen præcisering af hvilken codec der benyttes, har browseren ingen mulighed for at omregne de 25% til den præcise byte offset.

På samme side som du linker til kan læses:
"If the user agent can seek to anywhere in the media resource, e.g. because it a simple movie file and the user agent and the server support HTTP Range requests, then the attribute would return an object with one range, whose start is the time of the first frame (typically zero), and whose end is the same as the time of the first frame plus the duration attribute's value (which would equal the time of the last frame)."

  • 0
  • 0
Mikkel Kruse Johnsen

"Denne placering er afhængig af det codec der benyttes. Da HTML5 ikke har nogen præcisering af hvilken codec der benyttes, har browseren ingen mulighed for at omregne de 25% til den præcise byte offset."

Det er da noget fjolerig, selvfølgelig ved browseren hvilket format det er i. Det er angivet i "source" f.eks.

<source src='film.mp4' type='video/mp4' />

Browseren læser den første frame for at lave et thumbnail den viser. De fleste formater angiver også længde og andre ting, i en header i starten af filen som browseren kan læse.

  • 0
  • 0
Mikkel Blanné

Det er klart at hvis man kræver at kunne springe til et bestemt punkt i tid, og formatet ikke er med konstant bitrate, så skal headeren fx. indeholde en tabel med sekunder og byte offsets. Men det er vel alt sammen noget som codec'et håndterer?

Alternativt ville det da være tilstrækkeligt at kunne springe i procenter af bytestrømmen.

Men uanset hvad ser spoling da ret tydeligt ud til at være muligt i en eller anden form - i modsætning til hvad alle andre her i artiklen og kommentarerne påstår.

  • 0
  • 0
Hasse Hagen Johansen

Så vidt jeg har læst KAN man ikke spole hvis man bruger MP4 contain formatet som h.264 typisk bliver brugt i, men man kan benytte tricket med progressiv download hvilket dog ikke er så smart da man ikke virkeligheden delere videofilen op i mindre dele som man så downloader som hele stykker

matroska og googles nye webm(som sikkert typisk vil blive brugt med VP8) understøtter streaming, og der kan man derfor spole lidt smartere

Dette har intet at gøre med video tag'et i html5. Det er browseren der bestemmer om en given container+codec er understøttet.

  • 0
  • 0
Log ind eller Opret konto for at kommentere