Chrome maybe deprecates Theora

[rwill]

https://groups.google.com/a/chromium.org/g/blink-dev/c/qqDdLkeyk7Y/m/ajHePzglAwAJ

A hard blow for Internet Human Rights, it is planned that Chrome will deprecate the Theora Video Codec support.

[nevcairiel]

Internet Human Rights? What?

We have better patent-free and opensource video codecs, and if the usage of Theora is practically near zero, any remaining use can be replaced by a polyfill, and it faces emerging security threats without rapid responses in place... time to move on to VP9 and AV1.

[birdie]

https://groups.google.com/a/chromium.org/g/blink-dev/c/qqDdLkeyk7Y/m/ajHePzglAwAJ

A hard blow for Internet Human Rights, it is planned that Chrome will deprecate the Theora Video Codec support.

A hard blow to pretty much no one, because I bet out of all videos posted online, there are like 0.000001% using this abandoned irrelevant codec.

Browsers mustn't support something just because 10 people in the whole world need it. At the same time, 99.999999% people are exposed to possible vulnerabilities hidden in this codec. It's just not worth it.

You wanna play such videos? Compile ffmpeg and have fun.

Let's not waste time discussing this nothingburger.

[Ritsuka]

Doesn't Wikipedia already use a webassembly Theora decoder for unsupported browsers? Or was it only for vorbis?

[birdie]

Doesn't Wikipedia already use a webassembly Theora decoder for unsupported browsers? Or was it only for vorbis?

It was Vorbis and it was by Firefox, not Wikipedia, AFAIK.

[Ritsuka]

It seems it has been used since 2015 on wikipedia, and Theora is supported too: https://github.com/brion/ogv.js/

[benwaggoner]

It seems it has been used since 2015 on wikipedia, and Theora is supported too: https://github.com/brion/ogv.js/
Wow. That's the only place I've seen Theora in the wild for over a decade.

For those who weren't there for the blow-by-blow, it started in the late 90's when On2 released VP3, and tried giving decoders away for free to drive an encoder market. They released free decoders for QuickTime and other platforms. Didn't get much traction (rate control in the available encoder was horrifically bad). By the time they had a roadmap to having VP6 in Flash (I forget if VP4 or 5 were used for anything significant), they wanted to dump it. They tried to give it away for free to Terran Interactive where I worked, among other places. No takers.

So when there was a need for a royalty-free codec, they offered it up. And it worked, but it was still a pretty mediocre mid-90's CD-ROM codec. The open source version got some extensions and tuning, so it was better than stock VP3, but there was only so far it could be pushed. Theora launched with compression efficiency well behind the RealVideo and Windows Media codecs available at the time. I actually demonstrated that a well-tuned MPEG-1 could outperform it for some reason.

[Selur]

Wow. That's the only place I've seen Theora in the wild for over a decade.
I second that, I didn't even know that there were browsers supporting theora. :)

Cu Selur

[microchip8]

F* Theora. Move on, nothing to see!

[FranceBB]

Rip Theora.
You've never been good, but you paved the way for what AV1 is today and for that we will always be thankful.

https://i.imgur.com/ikRNsNh.png

[benwaggoner]

Rip Theora.
You've never been good, but you paved the way for what AV1 is today and for that we will always be thankful.
Figuratively in the sense of being a royalty-free video codec. Although arguably MPEG-1 and H.263 were also royalty free and available earlier. SO many proprietary codecs of the 90's were basically H.263 with some extra features.

And literally in that VP3 became Theora, and also VP4-7, and with Google's purchase of On2, VP8 and VP9. AV1's code base started with the VP10 in-progress implementation, with contributions from other stakeholders and efforts (Thor and Daala most notably).

[kurkosdr]

Figuratively in the sense of being a royalty-free video codec. Although arguably MPEG-1 and H.263 were also royalty-free and available earlier. SO many proprietary codecs of the 90's were basically H.263 with some extra features.
H.263 could not possibly be royalty-free at the time, it relies too much on H.262 aka MPEG-2 (which at the time was heavily patented), and let's not forget that MPEG-4 ASP has had a sizeable patent pool too (the last US patent expires next week), so I doubt at least some of those patents didn't also affect H.263.

Proprietary codecs of the 90s operated on the principle of "keep the spec secret and hope nobody takes the time to find out we step on a ton of H.263 patents". WMV is a good example of this: the moment the spec was opened as VC-1, patent holders started pointing at parts of the spec and saying "Hey! We have a patent on that", and soon after a MPEG LA patent pool was assembled for VC-1 (which is active to this day).

Theora was the first format to withstand patent lawsuits even with an open spec. And considering the MPEG LA assertions against VP8 were settled, it's the only format with an open spec that had no patent assertions against it at all. I know, irrelevant after the MPEG LA assertions against VP8 were settled, but it's worth mentioning: Theora was crap because it had to avoid a patent thicket.

And let's not forget Theora and VP8 are the reason the H.264 patent holders agreed to not charge "content fees" for free web video, which made H.264 a truly universal standard.

[monsterogv]

zero day attack, I got it on streaming. codecs like vp9 a donation. zero day attack on mpeg streaming, how does the revised technology experience this?

[benwaggoner]

H.263 could not possibly be royalty-free at the time, it relies too much on H.262 aka MPEG-2 (which at the time was heavily patented), and let's not forget that MPEG-4 ASP has had a sizeable patent pool too (the last US patent expires next week), so I doubt at least some of those patents didn't also affect H.263.
It's been a long time, but I thought there was some sort of agreement not to enforce H.263 patents, like there had been for MPEG-1.

Proprietary codecs of the 90s operated on the principle of "keep the spec secret and hope nobody takes the time to find out we step on a ton of H.263 patents". WMV is a good example of this: the moment the spec was opened as VC-1, patent holders started pointing at parts of the spec and saying "Hey! We have a patent on that", and soon after a MPEG LA patent pool was assembled for VC-1 (which is active to this day).
IIRC, there were a bunch of VC-1 patents that Microsoft had been waiting to file until the standard was done, but that other companies had figured out from the reference code implementation (which was pretty much just the production code with all the fun optimizations), and filed first. I didn't have any real engagement with the VC-1 design or patent process; I joined Microsoft after the bitstream was frozen.

Theora was the first format to withstand patent lawsuits even with an open spec. And considering the MPEG LA assertions against VP8 were settled, it's the only format with an open spec that had no patent assertions against it at all. I know, irrelevant after the MPEG LA assertions against VP8 were settled, but it's worth mentioning: Theora was crap because it had to avoid a patent thicket.
Theora was almost entirely an open-source implementation of VP3; On2 started to engineer around software patents a long time back. I remember stuff like scanning from the bottom of the frame instead of top, just trying to do things differently than the "obvious" way to get around swaths of patents that assumed coding would always be from the upper left.

And let's not forget Theora and VP8 are the reason the H.264 patent holders agreed to not charge "content fees" for free web video, which made H.264 a truly universal standard.
I think that was more VP6, which was the "good" codec for Flash before they added H.264. On2 had a whole lot of predatory pricing around encoders, decoders, distribution; pretty much anything you could think of monetizing. A memorable object lesson in "how to kill your ecosystem with greed."

A whole lot of the subjective quality of VP6 was due to its advanced postprocessing, far beyond any other codec did. Noise synthesis, deblocking, deringing, all of that. When that got turned off in a decoder (through configuration, or because fps dropped too much), the actual baseband video was not great. VP6 was handily outperformed by VC-1 Main Profile and H.264 Baseline.

That said, VP7 also gave us http adaptive streaming! Move Networks' stuff was all based on VP7. I was involved in getting them to use VC-1, but the company sort of cratered soon after. Big fees and poor flexibility for business model tanked them. It turned out to cheaper just to reimplement. Microsoft had done a technology cross-licensing deal with Move, hence Smooth Streaming, which begat DASH.

Sometime I'll tell the story of the fight to use fragmented MPEG-4 instead of ASF (https://en.wikipedia.org/wiki/Advanced_Systems_Format). What finally sealed the deal was my demonstrating how the lack of ASF support for B-frames would make H.264 support infeasible (H.264's max 16 b-frames is a lot of a 48 frame GOP)!

Both ASF and QuickTime were originally designed without any consideration of bidirectional prediction, which required a whole lot of reearchitecting to make work. This is one reason why VC-1 was optimized around not using more than 1 b-frame in a row.

Sorenson Video 3 in QuickTime just offset the frame indices by 2 frames so it could also use a single b-frame (so the payload of "Frame 4" was actually the second frame). So audio sync would be off two frames. It took me ages to get the post-Terran Interactive Media Cleaner Pro team to just implement a two frame audio shift to compensate.

B-frames in ASF did the same thing, although the audio offset was built in so didn't become an issue.

QuickTime was years late in supporting MPEG-1 because of the lack of B-frame support; having three in a row with Open GOP was just impossible to do within QuickTime without major refactoring. That was why MPEG-1 decode was implemented as a format playback plug-in, not as a QuickTime codec. I think that finally got fixed in QuickTime 7.

Fortunately the QuickTime-derived MPEG-4 file format got b-frames figured out from the start.

[FranceBB]

I'm always fascinated when I read about these stories. :)
Back when I was still playing around, Ben was living what has then become history.
It's always nice to have these things narrated by those who actually lived/were part of it.
Oh and by the way, I had no idea you were working for M$ in 2006! :eek:
I feel like this is the Doom9 video codec version of the Professor Brailsford tales on Computerphile :D

[Blue_MiSfit]

As always, thanks for sharing your war stories, Ben :)

[benwaggoner]

I'm always fascinated when I read about these stories. :)
Back when I was still playing around, Ben was living what has then become history.
It's always nice to have these things narrated by those who actually lived/were part of it.
Oh and by the way, I had no idea you were working for M$ in 2006! :eek:
I feel like this is the Doom9 video codec version of the Professor Brailsford tales on Computerphile :D
Thanks!

My first encode was with Macromind Director Accelerator back in 1989. I was taking a grad level 3D animation class at Mass in my 2nd year at Hampshire College, and we needed a way to move our rendered frames around on 1.4 MB Mac floppy disks (dorm room access to school servers was only via 1200 baud modem). I turned out to be a terrible animator, and got a D in the class, but started designing (terrible) video codecs in my head in class after that. The teachers and some students went on to create Infini-D if anyone remembers that.

I remember the revelation that was Apple Compact Video (later renamed Cinepak). And when IMA audio came out, and we could do (mediocre) 16-bit audio in half the bitrate of 8-bit. We could do 22 kHz mono instead of 11 at 1x CD-ROM bitrates.

CD-ROM itself became popular after I'd already been doing encoding for money (trade show and kiosk use initially). I used to buy blank CD-R discs for $18 for our $2000 1x burner.

Oddly, much of my early career happened by accident when I was trying to become a screenwriter and movie producer. I actually scripted a 2-page scene of people flirting over video compression ratios back in 1993 - what I've done since seems almost fated. I didn't finally realize that compression was my actual career until 1997.

[Emulgator]

1987, my penultimate year of studying for my Diplom-Ingenieur grade.

I was sitting behind my implementation of a Signal Processing PCB
(Programmable preamp, Antilaliasing filtering, Sample & Hold around an industrial-grade 15-bit ADC feeding a TMS32000 Signal processor.

My tutor and his master pupil had the FFT butterfly algo ready and then somebody else (our professor) came in
and while reconsidering the project from a recent meeting perspective he mentioned something along the lines:
"...and one day we will need to perform data reduction, it is done already in the states..."

I was like: Eek, Devil's craft. Now we finally have good, clean data, and lots of them.
Well, how and why to reduce what we just gained ?
This would introduce faults wouldn't it ?

37 years and some Terawatthours later: What an art that has become. ;-}

[benwaggoner]

1987, my penultimate year of studying for my Diplom-Ingenieur grade.

I was sitting behind my implementation of a Signal Processing PCB
(Programmable preamp, Antilaliasing filtering, Sample & Hold around an industrial-grade 15-bit ADC feeding a TMS32000 Signal processor.

My tutor and his master pupil had the FFT butterfly algo ready and then somebody else (our professor) came in
and while reconsidering the project from a recent meeting perspective he mentioned something along the lines:
"...and one day we will need to perform data reduction, it is done already in the states..."

I was like: Eek, Devil's craft. Now we finally have good, clean data, and lots of them.
Well, how and why to reduce what we just gained ?
This would introduce faults wouldn't it ?

37 years and some Terawatthours later: What an art that has become. ;-}
Two years head start on me!

Yeah, I remember so many philosophical arguments about lossy versus lossless compression in the early days (and it still comes up sometimes, particularly with audio).

It generally got down to something like "do you want to spend your bits on 96x72 of perfect pixels, or 320x240 of good pixels? Downscaling is lossy too!"

[kurkosdr]

Two years head start on me!

Yeah, I remember so many philosophical arguments about lossy versus lossless compression in the early days (and it still comes up sometimes, particularly with audio).

It generally got down to something like "do you want to spend your bits on 96x72 of perfect pixels, or 320x240 of good pixels? Downscaling is lossy too!"
Another big problem of lossless video compression is that it wouldn't help in the broadcast world where the bitstream has to fit in a given bits per second capacity of the multiplex, because lossless compression does not guarantee any bitrate reduction. This means you'd essentially be capped to the same resolution you'd have with uncompressed video (and lossless compression would only help viewers reduce their storage costs when recording/timeshifting). This means that even a state-of-the-art DVB-T2 multiplex could only do 352x288 or so, and that's generous (you'd have to use fragile 256QAM FEC 2/3 modulation to get ~40Mbps out of DVB-T2, and you'd have to pick an even worse FEC to accommodate uncompressed/lossless audio too).

Of course, lossy compression has the problem that too low bitrates are too often used. The temptation to cram yet another channel is just too big for broadcasters. Every time I see 4Mbps average bitrates on digitalbitrate.com for FullHD and H.264 channels, it just makes me sad. I mean, some of us pay a subscription to some "public broadcaster" whether we want it or not, so at the very least, they should give us artifact-free broadcast video, yes even when there is lots of stuff going on in the video.

IMO an ideal solution would be to have a minimum statistical bitrate per channel legislated. Divide the mux reasonably instead of cramming an ever-increasing number of channels in. Governments legislate for all kinds of specs, so why not? Unfortunately, most people don't even know that quality loss due to lossy compression is not only a thing but can be very significant too. Most people only know resolution is a thing and that's it.

[FranceBB]

Every time I see 4Mbps average bitrates for FullHD and H.264 channels, it just makes me sad.

Yeah, I know your pain. Some channels airing on terrestrial TV are really appalling...
The bad thing is that the situation ain't much better in the satellite world either.
In our case, we're airing with DVB-S2 QPSK on the satellite and although the streams are live hardware encoded (which is NEVER as efficient as offline software encoding), 2.5 Mbit/s for MPEG-2 25i BT601 SD, 12 Mbit/s for H.264 25i BT709 FULL HD and 25 Mbit/s for H.265 50p BT2020 HLG UHD are not actually bad.
Then again, Hotbird is so overcrowded that the cost of keeping the channels running at those bitrates is incredibly high and there's a fierce competition for bandwidth from quite literally every other broadcaster in Europe.
Just take a look at the whole Hotbird 13F beam:

https://lyngsat-maps.com/footprints/images/Hotbird-13F-Wide.png

that's just one single satellite with plenty of companies in every nation desperately trying to get a chunk of that... :(


Unfortunately, most people don't even know that quality loss due to lossy compression is not only a thing but can be very significant too. Most people only know resolution is a thing and that's it.


Yep, yep... it's really sad...

[kurkosdr]

Yeah, I know your pain. Some channels airing on terrestrial TV are really appalling...
The bad thing is that the situation ain't much better in the satellite world either.
In our case, we're airing with DVB-S2 QPSK on the satellite and although the streams are live hardware encoded (which is NEVER as efficient as offline software encoding), 2.5 Mbit/s for MPEG-2 25i BT601 SD, 12 Mbit/s for H.264 25i BT709 FULL HD and 25 Mbit/s for H.265 50p BT2020 HLG UHD are not actually bad.
For FULL HD H.264, I am happy with 7-8Mbps. As long as there isn't anything obviously wrong with the video, I am good. 7-8Mbps allows for 3 channels on DVB-T and 4 channels on DVB-T2 with 64QAM modulation and a reasonable FEC of 2/3 (actual bitrate depending on guard interval choice and audio bitrates). You'd assume at least 3 channels for what used to be one analog channel would be good enough, but nope: add this useless "+1" subchannel, add this even more useless telemarketing channel, sell some spectrum to 5G (from the already decimated spectrum after the admittedly necessary 4G auction), and that's how we ended up with 4Mbps for FULL HD on terrestrial being considered "normal" now.

I don't know any broadcaster who does 12Mbps even on satellite please give me the name of the channel and satellite if you know one.

Also, some broadcasters are realizing HotBird isn't worth the squeeze and move to Eutelsat, and somehow manage to run out of spectrum there.

[FranceBB]

I don't know any broadcaster who does 12Mbps even on satellite please give me the name of the channel and satellite if you know one.

Us at Sky of course. :)
This is Sky Sports Football from the website you used to check the bitrate before (digitalbitrate) Link (https://www.digitalbitrate.com/dtv.php?mux=C067&pid=2003&live=209&sec=0&lang=en) and you can see that it does spike to 12 Mbit/s when needed and Sky Sports UHD Link (https://www.digitalbitrate.com/dtv.php?mux=C069&pid=1001&live=209&sec=0&lang=en) which is consistently at 25 Mbit/s.

[kurkosdr]

Us at Sky of course. :)
This is Sky Sports Football from the website you used to check the bitrate before (digitalbitrate) Link (https://www.digitalbitrate.com/dtv.php?mux=C067&pid=2003&live=209&sec=0&lang=en) and you can see that it does spike to 12 Mbit/s when needed and Sky Sports UHD Link (https://www.digitalbitrate.com/dtv.php?mux=C069&pid=1001&live=209&sec=0&lang=en) which is consistently at 25 Mbit/s.
Cable doesn't really count though, I was referring to terrestrial and satellite. Nobody on terrestrial or satellite does 7Mbps average or even 6.5Mbps.

[FranceBB]

Oooops, that's my bad for not using the site search properly, I didn't notice it said "cable". Sorry.
Still, the hardware live encode is actually the same, so you're gonna see the same results.
Here's Sky Sport F1 on satellite: Link (https://www.digitalbitrate.com/dtv.php?mux=11170&pid=17&live=61&sec=0&lang=en)
Just like the other FULL HD sports channel, it goes to 12 Mbit/s when it really needs to. :)
And here's Sky Sport UHD on satellite Link (https://www.digitalbitrate.com/dtv.php?mux=11797&pid=553&live=61&sec=0&lang=en)
Again, steadily at 25 Mbit/s.

[rwill]

Funny that the statmux had 14.9Mbit peak for the Beate Uhse HD channel at one point ...

But 45Mbit allocated to 6 channels is ok I guess. For broadcast anyway.

[kurkosdr]

Funny that the statmux had 14.9Mbit peak for the Beate Uhse HD channel at one point ...

But 45Mbit allocated to 6 channels is ok I guess. For broadcast anyway.
Video is 40.10Mbps only, so that's ~6.7Mbps per channel, which is still a bit on the cramped side for a premium service that you have to pay a good amount of money for, but I've seen much worse, even from premium satellite services (see here (https://www.digitalbitrate.com/dtv.php?live=68&mux=12168&liste=1&lang=en) for an example of a really cramped mux of a premium service and here (https://imgbox.com/s98sqL95) for the quality it gives, the channel is FHD despite not saying so in the channel name, this is considered "broadcast-quality FHD video" somehow).

One more thing about Sky's channels: I wonder why their UHD channel needs 576kbps for E-AC3 audio. Maybe E-AC3+JOC (aka Dolby Digital Plus Atmos)? I know the site says only E-AC3 5.1, but 576kbps is too much for E-AC3 5.1, and JOC is an extension on top of "core" E-AC3 5.1 bitstream, so the site may not be picking it up.

[FranceBB]

One more thing about Sky's channels: I wonder why their UHD channel needs 576kbps for E-AC3 audio. Maybe E-AC3+JOC (aka Dolby Digital Plus Atmos)? I know the site says only E-AC3 5.1, but 576kbps is too much for E-AC3 5.1, and JOC is an extension on top of "core" E-AC3 5.1 bitstream, so the site may not be picking it up.

It is indeed.
So essentially, when you see 384 kbit/s 48000Hz E-AC3, then it truly only is 5.1 which is the live lossy encode of the original stream where 5.1 is carried by another lossy codec, namely DolbyE 5.1 20bit at 1.3 Mbit/s. On the other hand, when you see E-AC3 at 576 kbit/s 48000Hz then it's actually Atmos (so E-AC3 + JOC) coming from a DolbyE 5.1.4 20bit stream at 2.6 Mbit/s.

p.s speaking of DolbyE, if you use VLC you may wanna help on commenting and upvoting my feature request here Feature Request: Implement DolbyE Audio Decoding in VLC (FFMpeg supports it) (https://code.videolan.org/videolan/vlc/-/issues/27218)

[kurkosdr]

p.s speaking of DolbyE, if you use VLC you may wanna help on commenting and upvoting my feature request here Feature Request: Implement DolbyE Audio Decoding in VLC (FFMpeg supports it) (https://code.videolan.org/videolan/vlc/-/issues/27218)
Keep in mind most people don't care about DolbyE, it's a format that doesn't leave the studio/TV station. And VideoLAN doesn't care about more important edge cases. For example I've tried to make them seriously consider implementing forced subs support for DVD-Video, which is a problem much more users come across, and they still haven't more than a decade later. I just use Kodi for my DVD-Video needs instead.

I will upvote when I get some time, but I wouldn't hold my breath.

[benwaggoner]

Funny that the statmux had 14.9Mbit peak for the Beate Uhse HD channel at one point ...

But 45Mbit allocated to 6 channels is ok I guess. For broadcast anyway.
Statmux certainly can produce a lot better quality than if each channel had a fixed CBR! Of course, if all the channels happen to be showing a complex opening sequence at about 10 seconds after the hour...

[ShortKatz]

After Chrome, now Mozilla has removed Theora support as well.
https://bugzilla.mozilla.org/show_bug.cgi?id=1860492

[j7n]

I wonder by how many kB the browser actually became smaller, which would be a valid reason for the removal. But a program shrinking would break the laws of progress. The exe size of the oldest codecs is only growing, aside from the exceptional case where they actualy shrunk Vorbis. I might have seen a Theora video file only once or twice. If they simply allowed to save a video in an unknown format to disk, you could watch it normally like before browsers became OSes.

[benwaggoner]

I wonder by how many kB the browser actually became smaller, which would be a valid reason for the removal. But a program shrinking would break the laws of progress. The exe size of the oldest codecs is only growing, aside from the exceptional case where they actualy shrunk Vorbis. I might have seen a Theora video file only once or twice. If they simply allowed to save a video in an unknown format to disk, you could watch it normally like before browsers became OSes.
The low-level optimization required for codecs and media pipelines have long made them a prime target for hacking, and a major source of real-world intrusions.

If I'm trying to make a very secure platform to which pretty much any sequence of bits can be sent, like a web browser, I'd want to get rid of anything with assembly optimization I didn't need. A web browser has orders of magnitude higher security bar than something like ffmpeg.

It's bad practice to keep around code that isn't extensively tested every version, and that's a lot of burden for something that <0.1% of browsers have ever seen in the last five years.

[monsterogv]

https://chromestatus.com/feature/5158654475239424

Theora was removed from Chrome, with a note :
- Zero day attacks against media codecs have spiked.
- Usage has fallen below measurable levels in UKM.
- The sites we manually inspected before levels dropped off were incorrectly preferring Theora over more modern codecs like VP9.
- It's never been supported by Safari or Chrome on Android.
- An ogv.js polyfill exists for the sites that still need Theora support.
- We are not removing support for ogg containers.

[benwaggoner]

https://chromestatus.com/feature/5158654475239424

Theora was removed from Chrome, with a note :
- Zero day attacks against media codecs have spiked.
- Usage has fallen below measurable levels in UKM.
- The sites we manually inspected before levels dropped off were incorrectly preferring Theora over more modern codecs like VP9.
- It's never been supported by Safari or Chrome on Android.
- An ogv.js polyfill exists for the sites that still need Theora support.
- We are not removing support for ogg containers.
Sensible justifications. Media playback has always been a high security risk area given the low level access and optimization required.

"Fallen below measurable levels" was probably the killer. I can't think of any semi-popular site that ever used Theora, and I don't think I've seen an embedded Theora file in at least a decade, outside of pages specifically for testing media playback support.

[monsterogv]

I think resolution is not something to consider because bitrate contains all frames. I only have experience with theora encoder, and the beginning of uploading with a file that is certainly large. Tremor decode does not need large and small files.

[kurkosdr]

- An ogv.js polyfill exists for the sites that still need Theora support.
Why can't they add the JavaScript code contained in the ogv.js polyfill to the Chrome codebase? That way, no C code (prone to buffer overruns and pointer mishaps) is required to support Theora. I will never understand the ways of Mountain View...

Yes, Theora was crap, but breaking compatibility is never good. Just like in Windows-land "nobody" needed the 256-color mode of Direct3D or some DirectDraw functions, until sometime later it became apparent some games did use them.

[benwaggoner]

Why can't they add the JavaScript code contained in the ogv.js polyfill to the Chrome codebase? That way, no C code (prone to buffer overruns and pointer mishaps) is required to support Theora. I will never understand the ways of Mountain View...

Yes, Theora was crap, but breaking compatibility is never good. Just like in Windows-land "nobody" needed the 256-color mode of Direct3D or some DirectDraw functions, until sometime later it became apparent some games did use them.
WebAssembly seems like a great way to implement old codecs like this. Given Moore's Law, any PC that can use the modern web can easily decode all of that old stuff in pure software.

I don't know how well WASM is tied into the browser media object stuff, though. Back in Silverlight we had a generic codec interface where .NET bytecode could generate a pixel or audio sample however it liked. A mad genius built a web Commodore 64 emulator with that.

[monsterogv]

there seems to be no way around this at all. WebAssembly, especially. someone is already out of context.

[benwaggoner]

there seems to be no way around this at all. WebAssembly, especially. someone is already out of context.
I mean that if decoder security is the concern, we don't need to use C++ with all its challenges for old compute-efficiency codecs. We could build them in WebAssembly, which is vastly more secure.