html5 HTML5 + <audio> & <video>

[JoWa]

Hm? Inget ”läppstift” i mitt testsystem. DivX Setup var det du skulle ha kört och däri markerat de komponenter du ville ta bort. Inte ett spår av DivX i Chrome efter avinstallationen.

 

 

Nåja, denna tråd handlar primärt om att kunna spela upp video och ljud i webbläsaren utan behov av insticksprogram, och där är det nog VP9 snarare än HEVC som kommer att gälla. Jag tyckte dock att det var intressant att se att HEVC redan kan fungera så pass väl, om än med hjälp av ett insticksprogram.

 

För Chrome finns f.ö. H.265 / HEVC player (NaCl-program), baserat på libde265. Räkna med hög CPU-användning vid uppspelning av HEVC i full HD.

[plastiq]

Hm? Inget ”läppstift” i mitt testsystem. DivX Setup var det du skulle ha kört och däri markerat de komponenter du ville ta bort. Inte ett spår av DivX i Chrome efter avinstallationen.

 

Körde med den med Pale, och det fanns inga spår någonstans förutom i registret .

[JoWa]

Update on WebM/VP9 (YouTube)

 

 

Där talas om förbättringar av VP9-implementeringen libvpx. Det har dock inte släppts någon ny officiell version, utan det handlar om interna versioner, som används i Chromium och YouTubes kodare. Det är rätt betydande förändringar, som troligen snart kommer att bli tillgängliga i en ny version.

 

Demystifying encodes and decodes of WebM (YouTube)

 

Redigerad Juni 26, 2014 av JoWa

[JoWa]

Fyra ljudkodekar som används i HTML5 har testats (detaljer): AAC-LC (Apple iTunes 11.2.2), Vorbis (AoTuV b6.03), Opus (LibOpus 1.1), mp3 (Lame 3.99.5). De tre första testades vid drygt 100 kbps, och mp3 vid 136 kbps (kvalitet ”V5”). Resultat: http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106354&view=findpost&p=874674

 

Genomsnittspoäng (5 är högsta poäng):

• Opus: 4,65
• AAC-LC: 4,40
• Vorbis: 4,24
• mp3: 4,24

Vorbis-kodaren är från 2011-04-25 och Opus-kodaren från 2013-12-05. AoTuV har förvisso uppdaterats i år, men inte på något sätt som påverkar ljudkvaliteten. Den använda versionen av iTunes släpptes i våras, men av inlägg på Hydrogenaudio att döma, har AAC-kodaren inte uppdaterats i år. Lame 3.99.5 är från 2012-02-28, och behöver 30 kbps högre dataflöde för att kunna konkurrera med modernare kodekar.

 

Medan AAC, Vorbis och (i synnerhet) mp3 är gamla kodekar, vilkas implementeringar troligen inte kan göras mycket bättre, är Opus en ny kodek, och den testade versionen av kodaren LibOpus, 1.1, är den första ljudpåverkande uppdateringen sedan den första stabila versionen, 1.0 (2012-09-11). Det innebär vi kan vänta oss än bättre kvalitet med framtida versioner av LibOpus, eller någon alternativ kodare. Att optimera kodare är dock ett långtidsprojekt. I ett tidigare test, våren 2011, d.v.s. långt innan LibOpus 1.0 hade släppts, vann Opus över HE-AAC och Vorbis vid ~64 kbps.

[JoWa]

För att kunna se YouTube-videor i VP9-format i Firefox, behöver man göra en ändring i about:config. Sök efter media.mediasource.enabled och dubbelklicka på sökresultatet, så att värdet ändras till True.¹ Aktivera html5-spelaren på https://www.youtube.com/html5/. Klart!

 

¹ https://developer.mozilla.org/en-US/docs/Web/API/MediaSource

Redigerad November 8, 2014 av JoWa

[JoWa]

Jag jämförde dataflödet i en högupplöst video på YouTube, kodad med VP9 och AVC High Profile. Videon laddades upp (från en OnePlus One) den 4 november, och är således kodad med rätt uppdaterad mjukvara.

Sammanfattning av jämförelsen: den som vill minimera bandbredden gör klokt i att använda en webbläsare som stöder VP9 (och MSE).

Tyvärr har Firefox en gammal version (1.3.0, januari 2014) av libvpx, som avkodar VP9 långsamt. Förhoppningsvis släpps nästa version av libvpx snart, och förhoppningsvis dröjer det sedan inte länge förrän den uppdaterade versionen hamnar i Firefox. Chromium får ofta nya versioner av libvpx, och har nu betydligt snabbare VP9-avkodning än då libvpx 1.3.0 släpptes.

Detaljer från MediaInfo:

AVC

Format                                   : dash
Codec ID                                 : dash
File size                                : 62.8 MiB
Duration                                 : 23s 733ms
Overall bit rate                         : 22.2 Mbps
Encoded date                             : UTC 2014-11-04 11:46:02
Tagged date                              : UTC 2014-11-04 11:46:02

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L5.1
Format settings, CABAC                   : No
Format settings, ReFrames                : 2 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 23s 733ms
Bit rate                                 : 22.2 Mbps
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.089
Stream size                              : 62.8 MiB (100%)
Encoded date                             : UTC 2014-11-04 11:46:02
Tagged date                              : UTC 2014-11-04 11:46:02

VP9

Format                                   : WebM
Format version                           : Version 2
File size                                : 35.3 MiB
Duration                                 : 23s 700ms
Overall bit rate                         : 12.5 Mbps
Writing application                      : google
Writing library                          : google

Video
ID                                       : 1
Format                                   : VP9
Codec ID                                 : V_VP9
Duration                                 : 23s 700ms
Bit rate                                 : 12.0 Mbps
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 fps
Bits/(Pixel*Frame)                       : 0.048
Stream size                              : 33.9 MiB (96%)
Language                                 : English
Default                                  : Yes
Forced                                   : No

12,5 Mbps för VP9 och 22,2 Mbps för AVC High, och skillnaden kommer att öka ytterligare allteftersom VP9-kodaren blir mer optimerad (AVC-kodaren, x264, kan inte bli mycket bättre). Lägre dataflöde leder också till snabbare avkodning.

[JoWa]

YouTube har börjat att använda ljudkodeken Opus. Varje ljud- och videoström på YouTube har en formatkod, ett s.k. itag-värde. De tre Opus-kodningar som nu har börjat att dyka upp har nummer 249, 250 och 251. För en musikvideo är dataflödet för dessa tre format (andra exempel kan ge andra dataflöden):

• 249: 47 Kbps
• 250: 62 Kbps
• 251: 155 Kbps

Av dess har jag inte sett/hört 249 användas. 250 används ihop med VP9-video, 256×144 och 15 bilder per sekund. 251 används vid alla högre kvaliteter/upplösningar. Omkring 159 räcker för att Opus skall ge mycket hög ljudkvalitet, i de allra flesta fall är kodningen perceptuellt transparent (= ingen hörbar kvalitetsförsämring). Som tidigare har rapporterats är Opus testvinnare vid låga dataflöden (~64 Kbps, ~100 Kpbs). Ju högre dataflöde, dess mindre skillnad mellan olika kodekar och kodare.

 

Genom att högerklicka på en video och välja Statistik för nördar kan man se vilka format som spelas upp. I mitt bildexempel videoformat 248 (VP9, 1920×1080, 23,976 bilder per sekund) och ljudformat 251 (Opus, 155 Kbps).

 

 

När YouTube använder DASH är ljud och video separata strömmar, som kan kombineras hur som helst, om webbläsaren stöder alla format. T.ex. spelar Chrome upp VP9-video med AAC-ljud (140) då Opus saknas. Då DASH-tekniken inte används, spelas en fil med både ljud och video, t.ex. format 43, WebM med VP8-video, 640×360, och Vorbis-ljud, eller format 18, MPEG-4 med AVC-video, 640×360, och AAC-ljud.

Redigerad November 16, 2014 av JoWa

[JoWa]

Den långa striden om vilken videokodek som skall vara obligatorisk att implementera i WebRTC-klienter ser nu ut att ha fått en lösning. De två förslagen har varit VP8, som ingår i WebM, och AVC/H.264 Baseline Profile.

 

Den av Google, Mozilla och Cisco föreslagna lösningen är att både VP8 och AVC skall vara obligatoriska att implementera i WebRTC-klienter.

• [rtcweb] MTI Video Codec: a novel proposal
  
• VP8 and H.264 to both become mandatory for WebRTC
  

[Nicklas]

 

Den av Google, Mozilla och Cisco föreslagna lösningen är att både VP8 och AVC skall vara obligatoriska att implementera i WebRTC-klienter.

Du som är påläst JoWa, är det bra eller dåligt? Brett stöd är väl inte fel men samtidigt kan väl EN fokuserad standard ha sin fördel också.

[JoWa]

Bra är väl att dödläget bryts (om så sker). Ingen av de två sidorna har visat någon vilja att vika för den andra.

 

Men att ha AVC som obligatorisk att implementera är inte problemfritt. AVC är nedlusat med patent och MPEG LA kräver att den som använder AVC betalar licensavgifter till dem. Den utvecklare som vill använda en egen implementering eller använda en befintlig sådan med öppen källkod, t.ex. x264, får betala till MPEG LA. Utvecklare som inte kan eller vill betala licensavgiften får hålla till godo med Ciscos OpenH264, för vilken Cisco står för licensavgiften. Namnet OpenH264 är dock något missvisande. Visst, källkoden är tillgänglig och öppen (BSD-licens), och visst kan man kompilera en kodare och avkodare från koden, men då får man själv stå för licensavgiften: ”Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user’s computer or device.” (FAQ).

 

Ett slutet insticksprogram från Cisco känns inte som en önskvärd lösning, om det alls skall ses som en lösning. Det är snarare ett sätt att kringgå problemet med licensavgifter, till priset av att användaren blir påtvingad Ciscos slutna mjukvara, något som inte var en av tankarna bakom WebRTC.

 

Firefox 33+ har detta insticksprogram. Om Chrome kommer att använda OpenH264 eller någon annan kodare vet jag inte. Avkodare har Chrome redan.

[JoWa]

VP9 i WebRTC: https://plus.google.com/+JustinUberti/posts/3FLVapCvDaG

 

Troligen ganska långsamt nu, men implementeringen (libvpx) blir stadigt snabbare, och VP9 därmed allt mer användbart också för videosamtal, som innebär samtidig kodning och avkodning.

[JoWa]

• The Case for VP9 (Streaming Media)
• Google’s Web-video ambitions bump into hard reality (CNET)

I den senare artikeln sägs bl.a. att efter VP10, som nu utvecklas, är planen att släppa en ny VP-version var artonde månad. Min gissning är att dessa kommande versioner (VP11+) kommer att vara smärre uppdateringar. Den gissningen grundar jag på att det tar mer än 18 månader att optimera en kodare och avkodare. Det tar förstås också längre tid att göra större förändringar i specifikationen. Den höga utvecklings- och utgivningstakten omöjliggör kodekspecifika hardvaruimplementeringar. Innan sådan hårdvara kommer ut på marknaden har en ny VP-version släppts. Istället är det optimerad mjukvara, som utnyttjar SIMD i stor omfattning, som behövs. OpenCL kan också förbättra prestandan.

[JoWa]

Internet Explorer på Windows 10 stöder WebM med VP8, VP9 och Vorbis!

 

https://html5test.com/s/d7d8dd2544a097e0.html

 

Förhoppningsvis läggs stöd för Opus, helst i både WebM och Ogg, till innan Windows 10 släpps. Stöd för Vorbis i Ogg vore också trevligt.

[JoWa]

Engineering and Developers Blog: YouTube now defaults to HTML5 <video>

[JoWa]

libvpx 1.4.0 ”Indian Runner Duck” har äntligen släppts: Indian Runner Duck Release   

 

Alla versioner av libvpx: https://git.chromium.org/gitweb/?p=webm/libvpx.git;a=tags

[JoWa]

YouTube Engineering and Developers Blog: VP9: Faster, better, buffer-free YouTube videos

[JoWa]

StreamingMedia.com har jämfört VP9 med HEVC/H.265 kodat med x265, MainConcept och HEVC IP Provider.

 

The Great UHD Codec Debate: Google's VP9 Vs. HEVC/H.265

 

HEVC är förstås minst lika patenterat som sin föregångare AVC. Den som vill använda (t.ex. inkludera en kodare/avkodare i ett program) AVC får betala licensavgifter till patentpoolen MPEG LA. För HEVC räcker det inte att betala till en patentpool, utan man måste även betala till HEVC Advance, som dök upp för en månad sedan.    VP9 och VP8 är gratis att använda.

 

Monty: Today’s WTF Moment: A Competing HEVC Licensing Pool

[JoWa]

Nu vill Cisco utveckla ett nytt videoformat, och har presenterat projektet Thor: 

• World, Meet Thor – a Project to Hammer Out a Royalty Free Video Codec

Tydligen skall resultatet bli en kombination av Thor och Daala (Xiph/Mozilla), och kanske fler format som kan komma att tillföras projektet.

 

En anledning till att Cisco drog igång detta projekt är patentsituationen för HEVC/H.265, med två patentpooler som vill ha licenspengar för formatet. (Se förra inlägget.)

 

I blogginläggets inledning står ”Google’s proprietary VP9 codec”. Skribenten har en egen definition av proprietär. Han menar att VP9 är proprietärt då det inte utvecklats ”under the purview of a standards development organization (SDO) in which participants have an opportunity to be involved in the development process”. Se kommentarerna. Utanför skribentens lilla värld är VP9 (liksom VP8) inte proprietär, då källkoden är öppen, släppt under en BSD-licens och kan användas/implementeras utan kostnad. Proprietära (patenterade och belagda med licensavgifter) videoformat är t.ex. AVC/H.264 och HEVC/H.265.

[JoWa]

Microsoft, Google, Mozilla, Cisco, Intel, Netflix och Amazon har bildat en allians för öppen media, Alliance for Open Media.

 

Någon som väntade sig att Apple skulle ingå i alliansen?   

 

Microsoft, Google, Amazon, others, aim for royalty-free video codecs (Ars Technica)

[Nicklas]

Nej det var väl ingen högoddsare. Men det kan väl vara bra med flera läger, det brukar driva utvecklingen framåt. Till skillnad från korkade patentlagar som verkligen inte är incitament till utveckling som en del hävdar. 

Jag tror dock Alliance for Open Media kommer vinna eftersom de lär ha de 2 största spelarna bakom sig, porrsajter och piratscenen.

 

[e-son]

Jag tror dock Alliance for Open Media kommer vinna eftersom de lär ha de 2 största spelarna bakom sig, porrsajter och piratscenen.

 

Vad får dig att tro att piratscenen stöder Alliance for Open Media? Jag tvivlar starkt, eftersom alliansens egentliga syfte är att säkerställa drm-stödet i en framtida standard. Hade det inte varit för drm, skulle förmodligen fler av de stora varit lika ointresserade som fruktbolaget.

 

Redigerad September 3, 2015 av e-son

[Nicklas]

Jag var uppenbarligen inte tillräckligt insatt. Om det stämmer blir det lite motsägelsefullt, får hoppas du har fel. 

[JoWa]

DRM har vi i form av EME. Det har inget med video-, ljud- och bildformat att göra, det är ett eget ”lager” i paketet. Och det är inte organisationerna i alliansen som vill ha DRM. Det är Hollywood-maffian och andra ”innehållsleverantörer”.

 

Men Nicklas har rätt i att de har de två största spelarna med sig, men då tänker jag på YouTube och Netflix. Det är strömning det handlar om. Att ha de stora på klientsidan med sig är också en förutsättning, och det är nytt att Microsoft nu är på samma sida som Mozilla och Google.

[e-son]

"Hollywood-maffian och andra innehållsleverantörer" och flera av alliansorganisationerna är i princip grenar på samma träd. Jag vidhåller att drm är en betydande del av "limmet" i den här alliansen, men det är naturligtvis inte enda komponenten. "Bättre att förekomma, än att förekommas" som någon klok människa lär ha sagt en gång i tiden.

[JoWa]

Om stöd för video- och ljudformat i Edge:

• VP9: In Development: https://dev.modern.ie/platform/status/vp9videocodec/
• Opus: Under Consideration, ”Roadmap Priority: High — We intend to begin development soon.”: https://dev.modern.ie/platform/status/opusaudiocodec/
• Vorbis: Under Consideration, ”Roadmap Priority: Medium — Development is likely for a future release.”: https://dev.modern.ie/platform/status/vorbisaudiocodec/
• WebM:  In Development:  https://dev.modern.ie/platform/status/webmcontainer/