Gå till innehåll

HTML5 + <audio> & <video>


Recommended Posts

  • 2 veckor senare...
  • 2 veckor senare...

VP8-kodare ingår i Android 4.3:

VP8 encoder
 
Android 4.3 introduces built-in support for VP8 encoding, accessible from framework and native APIs. For apps using native APIs, the platform includes OpenMAX 1.1.2 extension headers to support VP8 profiles and levels. VP8 encoding support includes settings for target bitrate, rate control, frame rate, token partitioning, error resilience, reconstruction and loop filters. The platform API introduces VP8 encoder support in a range of formats, so you can take advantage of the best format for your content.
 
VP8 encoding is available in software on all compatible devices running Android 4.3. For highest performance, the platform also supports hardware-accelerated VP8 encoding on capable devices, such as Nexus 7 (2013), Nexus 4, and Nexus 10 devices.

 

https://developer.android.com/about/versions/jelly-bean.html

 

Främsta användningsområdet är nog WebRTC.

Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...
  • 4 veckor senare...
  • 2 veckor senare...
  • 1 månad senare...

Cisco har meddelat att de kommer att släppa källkoden till sin H.264/MPEG-4 AVC-implementering under BSD-licens. De kommer också att göra kodeken i form av en ”binärmodul” fritt tillgänglig för flera system, och stå för licenskostnaden till MPEG LA. BSD-licensen gäller endast källkoden, medan Cisco står för licenskostnaden endast om Ciscos binärmodul används: ”In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints.”

 

Licenser…  :rolleyes:

 

[rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees

 

Mozilla kommer att inkludera denna kodek i Firefox: Video Interoperability on the Web Gets a Boost From Cisco’s H.264 Codec

 

Ciscos ”generositet” sträcker sig dock inte längre än till den lägsta profilen Baseline. ”Profilerna” i AVC är separata kodekar, med separata licenser. AVC Baseline har föreslagits som obligatorisk att implementera i WebRTC-tillämpningar, och Cisco, som genom åren har investerat mycket i formatet, gör sin implementering fritt tillgänglig för att stärka AVC som kandidat i det sammanhanget. Cisco tillägger: ”The initial code has the baseline profile. We look forward to working with the open source community to add high profile and others.” High är den profil som används för högupplöst video på nätet, t.ex. YouTube. Ciscos erbjudande inkluderar heller inte någon ljudkodek (lämpligen AAC), som skulle behövas för användning av AVC i <video>-taggen.

 

Vidare kan påpekas att, även om AVC är en mycket använd kodek, är den en förra generationens kodek. Dess efterträdare HEVC/H.265 har lanserats, och VP9 har i år lanserats som efterträdare till VP8. Samtidigt arbetar Xiph och Mozilla med en nästa generations videokodek, Daala. Så det återstår att se hur stor betydelse Ciscos implementering har på längre sikt.

 

Se även Monty Montgomery (Xiph): Comments on Cisco, Mozilla, and H.264

 

Nästa vecka skall IETF fatta beslut om obligatorisk videokodek i WebRTC.

Länk till kommentar
Dela på andra webbplatser

  • 3 veckor senare...
  • 3 veckor senare...
  • 1 månad senare...
  • 2 veckor senare...

Medan libOpus utvecklas för fullt och får den mesta uppmärksamheten, har det varit väldigt lugnt på Vorbis-fronten, och det gäller både libVorbis och aoTuV. Min gamla Vorbis-tråd har därför arkiverats. Nu har emellertid libVorbis uppdaterats till version 1.3.4, nära två år efter libVorbis 1.3.3. Inga ljudförbättrande ändringar i 1.3.4, men kodaren är nu kompaktare än förr.

 

”Monty” Montgomery: Libvorbis 1.3.4 released

 

libVorbis 1.3.4 released

Länk till kommentar
Dela på andra webbplatser

  • 5 veckor senare...

FFmpeg har haft en egen VP8-avkodare, ffvp8, sedan den 22 juni 2010: Native VP8 decoder. Den 23 juli presenterades ffvp8 som världens snabbaste VP8-avkodare (i konkurrens med endast referensimplementeringen libvpx): Announcing the world’s fastest VP8 decoder: ffvp8. Chrome använder ffvp8 från och med ”milsten” 15 (revision 97421).

 

Sedan oktober 2013 har FFmpeg också en egen VP9-avkodare, ffvp9: Native VP9 decoder. ffvp9 skapades av Ronald S. Bultje (tillika en av skaparna av ffvp8, och delaktig i utvecklingen av VP9) och Clément Bœsch. I går presenterades ffvp9 på liknande sätt som tidigare ffvp8, som världens snabbaste (med samma ensamma konkurrent): The world’s fastest VP9 decoder: ffvp9 Läs gärna hela artikeln, skriven av Ronald S. Bultje.

 

Enligt jämförelsen är ffvp9 25–50 % snabbare än libvpx. Mätningarna, som även inkluderar ffvp8 (VP8) och ffh264 (AVC/H.264) gjordes vid samma kvalitet (SSIM-värde) för de olika kodekarna, d.v.s. vid olika dataflöden, beroende på hur effektiv kodaren var. ffvp9 är omkring 15 % långsammare än ffvp8, vilket är imponerande då VP9 är en effektivare (mer komplex) kodek än VP8, och även med tanke på att ffvp8 har optimerats i snart fyra år, medan ffvp9 är fyra månader. ffvp9 utnyttjar ännu inte AVX2, vilket förklarar att skillnaden mellan ffvp9 och libvpx inte är så stor på Intel Haswell. De flesta av optimeringarna (SIMD) fungerar endast på 64-bit.

Länk till kommentar
Dela på andra webbplatser

  • 2 månader senare...
  • 3 veckor senare...
Med anledning av WebM:s fyraårsdag kommer här en liten tillbakablick, som summerar vad som har hänt under det senaste året.

 

Det största som har hänt är förstås att videokodeken VP9 har utvecklats färdigt, och specifikationen frystes den 17 juni 2013. Chromium hade då haft stöd för en icke slutgiltig version av VP9 i drygt ett halvår. Från och med Chromium 29 (Opera 16) är det den slutgiltiga versionen som stöds.

 

Den första versionen av referensimplementeringen libvpx (kodare och avkodare), med stöd för VP9 var 1.3.0, som dök upp i ändringsloggen den 15 november 2013. Den släpptes som ”repository snapshot” den 10 januari 2014.

 

Medan VP9 är en imponerande kodek, är implementeringen libvpx 1.3.0 ett trögt elände. Videokvaliteten slår den men får från den extremt optimerade och sofistikerade kodaren x264 då den kodar AVC High Profile. Att koda VP9 går för närvarande extremt långsamt, och skillnaden i kvalitet mot AVC High Profile (x264) är så liten att VP9 i de flesta fall inte är värt priset (den längre kodningstiden). Detta gäller alltså vintern/våren 2014. Att optimera en kodare tar lång tid. x264 har optimerats sedan 2004. VP8-delen av libvpx har också optimerats under flera år, och att koda VP8 går nu rimligt snabbt. 

 

Utvecklingen av libvpx går givetvis vidare, och jag gissar att en ny version (troligen 1.4.0) kommer att släppas under sommaren, och den måste vara betydligt snabbare, t.ex. genom att stödja trådning.

 

Det är dock inte endast kodning av VP9 som är långsam, utan även avkodning, d.v.s. uppspelning. Att se en video med upplösningen 1280×720 på YouTube med en AMD Athlon 64 3800+ ”NewCastle”, 2,4 GHz (Windows 7, Chrome 34) är inte helt lyckat. Omkring var tionde bildruta tappas, fler vid sekvenser med rörligt innehåll, färre vid sekvenser med stilla innehåll. En mer optimerad avkodare behövs, och en sådan finns sedan några månader: FFmpegs ffvp9! 

 

Redan i februari i år, efter fyra månaders utvecklingsarbete, var ffvp9 betydligt snabbare än libvpx, och mycket optimeringsarbete återstår förstås. Med tiden kommer Chromium sannolikt att använda ffvp9; ffvp8 har använts sedan Chromium 15. Givetvis måste även libvpx bli snabbare som VP9-avkodare. Många program, som Firefox, kommer att fortsätta att använda endast libvpx som avkodare (och kodare). Med en modern processor (jag har en Intel i5) är varken 1280×720 eller 1920×1080 något problem, men förutom att video måste kunna spelas upp även på inte helt nya datorer, måste också mindre kraftfulla mobila enheter (även utan dedicerad hårdvara för videoavkodning) kunna spela upp video utan att tömma batteriet på fem minuter.

 

Ett annat sätt att göra avkodningen snabbare är att göra kodaren effektivare. Ja, med en effektivare kodare kan dataflödet sänkas ytterligare, och lägre dataflöde innebär mindre data att behandla, och därmed snabbare avkodning. 

 

Faktiskt kan ffvp9 avkoda video med en viss kvalitet snabbare än ffvp8, i vissa fall (t.ex. en brusig video med rörligt innehåll som kräver högt dataflöde), där VP8 behöver så mycket högre dataflöde än VP9, att det väger upp VP8:s lägre komplexitet och ffvp8:s mer optimerade prestanda. ffvp9 är också något snabbare än ffh264.

 

För att sammanfatta videoläget: VP9 innebär ett stort steg framåt jämfört med VP8, men utvecklingsarbetet har bara börjat, och mycket återstår innan implementeringen är i närheten av att utnyttja formatets hela potential. Att VP9 redan är bättre än AVC/H.264 räcker inte i längden, då HEVC/H.265 har lanserats och är en kommande konkurrent. Som webbvideoformat har VP9 dock ett försprång, och även fördelar, som att det är lättare att avkoda.

 

VLC 2.1.1+ stöder VP9 ”depending on the platform”. Firefox stöder VP9 från och med version 28, men då Firefox inte stöder Media Source Extensions, kan Firefox inte spela upp VP9-video på YouTube.

 

Även på ljudsidan har det hänt saker. WebM kan nu även (utöver Vorbis) innehålla ljud i Opus-format. Opus är effektivare än Vorbis, vilket innebär att ett lägre dataflöde kan användas. Liksom videokodare, måste ljudkodare optimeras för att utnyttja formatet till fullo. Vorbis-kodarna (libVorbis och aoTuV) optimera inte längre (åtminstone har inget hänt på ett par år). Opus-kodaren libopus utvecklas däremot för fullt, och i december 2013 släpptes den första större uppdateringen, 1.1, med förbättrad ljudkvalitet (vid ett visst dataflöde) och andra förbättringar. I videosammanhang, där ljudet endast utgör några få procent av det totala dataflödet är skillnaden mellan libopus 1.0 och 1.1, och även mellan Opus och Vorbis, närmast försumbar, och att optimera videokodaren bara ytterst litet gör mycket större skillnad, men i en ren ljudtillämpning märks det tydligare.

 

YouTube började tidigt att erbjuda video i VP9-format, som ett experimentellt alternativ. Nu är VP9, där det är tillgängligt, standardformatet. VP8 finns kvar endast som ett lågupplöst (640×360) reservformat, som används då VP9 saknas och webbläsaren inte stöder AVC. Nyligen blev YouTubes HTML5-baserade spelare standardvalet då Chrome används. De flesta videor jag ser på YouTube, med Chrome (som också stöder AVC) är i VP9-format. Genom att högerklicka på en YouTube-video och välja ”Statistik för nördar” kan man se vilken videokodek som används, och hur många (om några) bildrutor som tappas under uppspelningen. Vid uppspelning av VP9, 1920×1080, tappar jag inga bildrutor, och belastningen är jämnt fördelad på i5:ans fyra kärnor, varierande mellan 15 och 25 %. Notera att det är libvpx som används, och dess avkodare inte är särskilt bra på trådning (att utnyttja flera kärnor eller processorer).

 

Länkar





Länk till kommentar
Dela på andra webbplatser

För den som är intresserad av HEVC/H.265, den videokodek som har utvecklats för att ersätta AVC/H.264, har DivX en demonstrationssida, där bl.a. Sintel och Tears of Steel kan ses i upplösningar upp till 4k. http://www.divx.com/en/hevc-showcase

HEVC stöds för närvarande inte av någon webbläsare, och därför behövs ett insticksprogram, DivX Web Player, för uppspelning. Videorna kan också laddas ned (via spelaren) för uppspelning med t.ex. VLC eller DivX Player.

 

DivX Converter kan koda HEVC, och gör det snabbare än libvpx 1.3.0 kodar VP9.

 

Om HEVC framgent kommer att stödjas av webbläsare, och därmed bli användbart i html-taggen <video> återstår att se. Troligen kommer Google inte att implementera stöd för HEVC i Chrome, och inte att använda det på YouTube, utan satsa VP9. Eventuellt stöd i Firefox skulle förutsätta att avkodare finns i systemet, på samma sätt som Firefox nu kan avkoda AVC om avkodare finns i systemet. Därmed får formatet det svårt att uppnå någon större användning.

Länk till kommentar
Dela på andra webbplatser

Postad (redigerade)

Har du DivX Web Player? Jag testade med Chrome 36 i min virtuella W7 64, och det fungerade. Jag fick bild, som dock var upp och ned! Det var den även i den fristående DivX Player. I VLC var det rättvänt, i både W7 och Ubuntu.

 

Tears of Steel kan även laddas ned utan att ha DivX Web Player installerad: http://labs.divx.com/node/127909 Välj ”Muxed Files (MKVs)”.

Redigerad av JoWa
Länk till kommentar
Dela på andra webbplatser

Postad (redigerade)

Hmmm, kommer inte ens i närheten med divx som vlc presterar. Rätt kul att du fick en inverterad bild.

 

Edit : nu fungerar det jättebra, ljud och bild är utmärkta ( gjorde en omistallation av spelaren).

Har endast problem med streaming, fungerar helt utmärkt annars. Bra tips igen  (som vanligt ) :)

Redigerad av plastiq
Länk till kommentar
Dela på andra webbplatser

Postad (redigerade)

Var i tusan hamnar divx på disken ? har försökt att leta efter en avinstallationspunkt, kollat även med revo uninstaller, får "pluggisar" in i  webbläddraren, "sitter som läppstift på kragen", (opptokopterns välmyntade ide om besvärligheter)

 

Edit : kan visserligen gå via registret, undrar mestadels om jag har missat något ?

 

Edit2 : körde igenom registret och raderade den vägen,, inga plugins längre.

 

Hmmm, gick in via hkey_local_machine\software\mozillaplugins\

Nu är det toppen igen, men tack för tipsen :)

Redigerad av plastiq
Länk till kommentar
Dela på andra webbplatser

Delta i dialogen

Du kan skriva svaret nu och registrera dig senare, Om du har ett konto, logga in nu för att svara på inlägget.

Gäst
Svara i detta ämne...

×   Du har klistrat in innehåll med formatering.   Ta bort formatering

  Only 75 emoji are allowed.

×   Din länk har automatiskt bäddats in.   Visa som länk istället

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Skapa nytt...