HTML5 is very much a media techology built like a web browser. But while the presentation layer is important, it only part of what makes a good media experience.
Smooth Streaming is dynamically and seamlessly between multiple bitrates based on real-time measurements of bandwidth, availble CPU, and window size. And it requires a decoder architecture like MediaStreamSource where demuxing happens in the sandbox, with decoders that can take appended sequences of raw audio and video samples.
The key thing about a runtime like Silverlight or Flash is that the bytecode engine, decoders, and rendering layer are tightly coupled, and so can make assumptions about how long it takes a video sample to get from networking stack to demuxer to decoder to rendering engine to screen. It's complex stuff, and it's hard to see HTML5 specified tightly enough to make that kind of thing feasible.
For another extreme, there's the Raw AV pipeline: video and audio decoders running inside the managed code sandbox. Javascript is getting faster, sure, but it's a long way from being THAT fast.
Or to look at it another way, it'd be easier to support HTML5 in Silverlight than it would be to replace Silverlight with HTML5.
SMIL was pretty simple; it was very much a early HTML like way to control media presentation. And it has been long-supported by Windows Media Player and QuickTime Player.
But it never really supported anything as rich as Flash and Silverlight, particulary in terms of interactivity.
Smooth Streaming uses SMIL for its manifest files indicating what bitrates are available for a partcular asset.
I've never seen anything in the wild beyond SMIL 2.0, which RealNetworks used heavily way back when. There are 2.1 and 3.0 versions, but I've not seen them used by anything.
Well, I suppose if browsers evolve to the point that they're providing full OS level functionality.
I could see something like this happening a few years after browsers start commonly running in hypervisors.
I don't really see the point. The parts of browsers tha are good for an OS migrate to the OS anyway. Something like the Palm Pre is more about basing the UX rendering layer on browser techology. And yes, presentation is an important part of the OS, but hardly the major part of it.
Operating systems do the things browsers do well a lot better than browsers do the things that operating systems do well. A browser that did those things too would be much, much more like today's operating systems than today's browsers.
I don't know about useless, but Outline mode certainly has made me be a better writer. I wasn't able to use Pages at all because it didn't have a "Normal" (non page preview) mode the first couple of versions. I don't CARE where my page breaks are going to be when I'm doing a 1st draft, because that's not where the page breaks are going to be.
I want to write an outline, then write my words with styles applied, and THEN see how it actually lays out on the page. And then be able to go back to just text without layout, and even back to the outline to rearrange. Being able to switch between those is key to my word processing workflow for longer documents (I've written a couple of books, plenty of whitepapers, and dozens of trade magazine articles).
Expression Design isn't really meant as a general purpose consumer drawing program. It's more focused on high-touch authoring of XAML objects for WPF/Silverlight use.
That said, XAML is just XML, so there are a variety of exporters from other tools. Like this one for Illustrator (Mac/Win)
Pick a bunch of winners... Motion blur can be a problem!
File size is a decent heuristic here. A frame with a lot of motion blur won't have higher frequencies, and so with a fixed-quantization encode like JPEG, it'll be a smaller file size.
The biggest files will correlate with the frames with the most detail, mathematically.
Now, that's not saying that it wouldn't be a tight shot of a screen window, but it's a start:).
I think we're saying the same thing here; PSNR is not an ironclad indicator of quality on its own. While PSNR is a reasonably useful first-order hint, one should never assume that two PSNR values that are only somewhat appart means there will be a proporational difference in quality.
But the farther apart two encodes are in PSNR, the more likely there's going to be a visible difference. It's be very surprising to have a clip with a 10 dB worse PSNR actually look better. But within 1-2 dB, not surprising at all.
This is probably because the YV12 color space itself "bakes in" a fair amount of perceptual optimization, in terms of chroma subsampling, luma precision, and in particular the use of a perceptually uniform gamma curve. If we were talking about PSNR versus the Raw input from a camera's Beyer pattern CCD, it'd be much less useful in predicting subjective quality. One simple example of something that improves visual quality while lowering PSNR is dithering; it reduces banding by adding LSB noise.
You you believe that one codec can look very good with uncharacteristically poor PSNR, yet you still believe PSNR is useful for comparing different codecs...?
I imagine such a codec is theoretically possible, but doesn't exist. So it's had no imapct on any actual PSNR tests to date:).
Sure it will. PSNR just doesn't work that way. It is utterly useless for comparing the values of different encoders.
No argument it's not perfect, but it is useful, and is used to good effect by people making codecs. PSNR is a pretty accurate way to measure the effect of changes to any part of the codec other than perceptual optimizations.
Or will you just accept, on PSNR figures alone, that On2's proprietary crap vastly outperforms H.264, as well as every other codec on the planet?
Absolutely not, since they didn't give enough info to really understand what they did. We'd need to get Dark Shakiri or someone like that to do their best x264 encodes to get a useful comparison.
Yes, an archive for future transoding is a perfect use for Lossless. There have been various MP3/WMA + diff technologies proposed over the years, which would enable a "good enough" mobile encode plus entropy data to get back to lossless from there. That said, modern CPUs are probably fast enough to transcode from lossless faster than the transfer rate of portable devices, so I don't know if there's any point in preencoding anyway.
Personally, I think there's a pretty good value for lossy codecs better than MP3.
And what if they offer you 48 KHz 20-bit lossy versus 44.1 KHz 16-bit lossless:)?
We think about the CD master or YV12 as being "lossless" but both represent a lot of perceptually tuned compromises well before they hit a codec. You can't estimate quality with a diff or a spec; it requires good ears, good content, and good reproduction equipment to figure out what's a difference that matters and what's a difference that doesn't.
We care about how it is percieved by the human auditory system here; it's not like we're trying to make bats dizzy.
Really, there's no more point to mathematically lossless audio than for video or images. We've got good models to know what kinds of artifacts are audible, and modern VBR codecs do an excellent job of raising bitate where it's needed to prevent those. And both AAC and WMA have better theoretical maximum accuracy than MP3, even if one is a golden ear sensetive to a few MP3 edge cases.
And its not like it's lossless from the mix anyway, it's lossless from the 16-bit 44.1 master. Those are bigger percetpual compromises than the difference between lossless and a good lossless.
And even if capacity is cheap, saving bits on audio leaves more for video or files or whatever. And makes for much faster syncs.
Well, I think it's overstated to call PSNR Utterly worthless. In practice, it's a useful ballpark indicator of how a codec is doing. For a car analogy, it's perhaps like trying to figure out speed from the RPM gauge; relevant, but not the whole story. And while there are all kinds of theoretical things that can be done to fake out PSNR, in the real world an encode with a bad PSNR is almost alwasy going to look pretty bad. It's certainly possible for two clips with a PSNR difference of 2 dB to have the mathematically less accurate one actually look better, but it's rare to have a big PSNR difference not indicate a big perceptual difference.
You can easily write a codec that is very strict in storing the "easy bits" exactly right, while completely and terribly distorting everything else on screen, while still getting a great PSNR. Your eyes just don't work that way. Things like adjusting the level of HF noise on screen negatively effects PSNR, yet it's something that is only barely consciously perceived by humans.
I think that would be harder to do in practice; a codec that looks good with poor PSNR, sure, there's tons of tricks. But one that looks bad with great PSNR? It cerrtainly isn't going to happen by accident, although perhaps someone with a very... specific sense of humor could build something like taht for their own amusement. And as tickled as I am by the idea, I can't think of any of the various oodec-related practical jokes over the years that involved buildn't an actual new encoder.
With H.264 in particular (which is the comparison point here) the strong in-loop deblocking filter will soften the kinds of sharp lines where human vision cares more than PSNR. That loop filter is probably the strongest single innovation in H.264, since it lets video degrade into softness, without introducing new erroneous detail at high quantization like older codecs did. So, unlike MPEG-2, having a highly compressed frame doesn't have the same negative impact on a later frame predicted from it.
But the loop filter softens detail, which makes it hard to have a few bad pixels and lots of great pixels in the way you desribe; instead it'll get blurring a a bunch of pixels will be off. Sure, it can be disabled, but then overall PSNR goes down a bunch as well.
All that said, I think SSIM is a better metric than PSNR for today's codecs in today's usage.
And being in the industry, I can state that big content companies and all the device companies have been well aware of this coming for some time, and they're a pretty frequest topic of discussion.
MPEG-2 and the original MPEG-4 codec had somewhat similar termrs, so this is really just business as usual in the digital media industry. Things are actually a lot more affordable with VC-1 and H.264 than with MPEG-2.
...although without rate control and with such a short clip (12.5 sec?) it really hard to make much of these numbers even if PSNR was calculated correctly.
We need to see a few minutes of video, with a VBV constraint.
Also, interframe encoding with wavelets has never been done well. Say what you will about classic Discreet Cosine Transformation codecs, those small blocks make it easy to track motion vectors between frames and get efficient interframe coding.
While I like wavelets for still images, they're not so much better than DCT that it makes up for DCT's advantages for interframe coding.
And implementations matter more than the transform. H.264 High Proifle can outperfom JPEG2000 for still image coding. That in-loop deblocking filter and CABAC are big helps.
The Raw AV pipeline would allow Ogg demuxing with Vorbis and Theora decoding to happen inside managed code in Silverlight/Moonlight.
So users who had either installed wouldn't need to install Ogg to get playback. The web site could just detect the plugin and embed a Silverlight player that includes the decoders.
Remember WMA? and AAC? no, the "big boys" ignored FLAC not because it wasn't popular enough, it was because both have *very* strong NIH sentiments against it, as they did with MP3.
Er, it was more that FLAC requires around, what 4-6x higher bitrate beyond a perceptually lossless codec?
Putting lossles files on a capacity constrained device like a portable media player is spending a lot of bits for a placebo effect.
Both AAC and WMA offer substantially bettter audio quality than MP3 at lower bitrates. WMA implementations also offer a 2-pass VBR mode, allowing predictible file size with the qualtiy advantages of VBR. And again, if you trying to put as much high quality music into as small enough space, those matter.
Edit: HAHAHA! We figured out what was wrong--thanks a ton, gmaxwell, for coming on IRC and resolving this! Turns out his testing methodology was flawed... but not in the way I thought! Turns he out he did everything correctly... but he used ffmpeg for outputting the raw y4m file to have its quality measured by dump_psnr (but not for theora). Apparently, ffmpeg flags the output chroma as "420mpeg2" instead of "420", which results in over 4db of PSNR being slashed off of x264's results unfairly. Oops. We already have a patch submitted to ffmpeg for the problem and a retraction of the Theora comparison results is in the works. Thanks to gmaxwell for taking the initiative and David Conrad (Yuvi) for finding the bug!
Anyway, given H.264 is a more recent codec that is highly optimized for PSNR and has had many years of refinement in a number of implementations, it's hard to conceive of how Theora could even approach it in compression efficiency, let alone beat it.
Even later when Word was released for early PowerMacs, I found that Windows Word could not read the Word documents from my Macintosh.
Mac Office 4.2? The Mac and Win versions of Office have used the same file format since at least Office 97/98. Mac Office 6.0 was a dog, no doubt, on many levels. But that was also 15 years ago.
If you consider that the Office '97 formats still remain interoperable today, that's actually quite a good track record for these things. Through the 80's and 90's most major releases of most word processors and spreadsheets would introduce a new file format and varying degrees of interoperability issues.
Slashdot Mirror
Yeah, but can it do this?
http://www.nextcdn.com/Silverlight.htm
HTML5 is very much a media techology built like a web browser. But while the presentation layer is important, it only part of what makes a good media experience.
Smooth Streaming is dynamically and seamlessly between multiple bitrates based on real-time measurements of bandwidth, availble CPU, and window size. And it requires a decoder architecture like MediaStreamSource where demuxing happens in the sandbox, with decoders that can take appended sequences of raw audio and video samples.
http://msdn.microsoft.com/en-us/library/system.windows.media.mediastreamsource_members(VS.95).aspx
http://alexzambelli.com/blog/2009/02/10/smooth-streaming-architecture/
Flash has something somewhat similar with Dynamic Streaming.
http://www.adobe.com/devnet/flashmediaserver/articles/dynstream_advanced_pt1_04.html
The key thing about a runtime like Silverlight or Flash is that the bytecode engine, decoders, and rendering layer are tightly coupled, and so can make assumptions about how long it takes a video sample to get from networking stack to demuxer to decoder to rendering engine to screen. It's complex stuff, and it's hard to see HTML5 specified tightly enough to make that kind of thing feasible.
For another extreme, there's the Raw AV pipeline: video and audio decoders running inside the managed code sandbox. Javascript is getting faster, sure, but it's a long way from being THAT fast.
Or to look at it another way, it'd be easier to support HTML5 in Silverlight than it would be to replace Silverlight with HTML5.
SMIL was pretty simple; it was very much a early HTML like way to control media presentation. And it has been long-supported by Windows Media Player and QuickTime Player.
But it never really supported anything as rich as Flash and Silverlight, particulary in terms of interactivity.
Smooth Streaming uses SMIL for its manifest files indicating what bitrates are available for a partcular asset.
I've never seen anything in the wild beyond SMIL 2.0, which RealNetworks used heavily way back when. There are 2.1 and 3.0 versions, but I've not seen them used by anything.
http://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language
JavaFX may be trailing Flash and Silverlight, but it's the only RIA framework that has a snowball's chance in hell of being open sourced.
Then you should be pleased about about Moonlight:
http://www.mono-project.com/Moonlight
Interoperable GPL'ed implementation of Silverlight, based on Mono.
They've got full Silverlight 1.0 compatibility, much of Silverlight 2, and even some features from Silveright 3 (which is still in beta).
http://www.mono-project.com/MoonlightRoadmap
Well, I suppose if browsers evolve to the point that they're providing full OS level functionality.
I could see something like this happening a few years after browsers start commonly running in hypervisors.
I don't really see the point. The parts of browsers tha are good for an OS migrate to the OS anyway. Something like the Palm Pre is more about basing the UX rendering layer on browser techology. And yes, presentation is an important part of the OS, but hardly the major part of it.
Operating systems do the things browsers do well a lot better than browsers do the things that operating systems do well. A browser that did those things too would be much, much more like today's operating systems than today's browsers.
I don't know about useless, but Outline mode certainly has made me be a better writer. I wasn't able to use Pages at all because it didn't have a "Normal" (non page preview) mode the first couple of versions. I don't CARE where my page breaks are going to be when I'm doing a 1st draft, because that's not where the page breaks are going to be.
I want to write an outline, then write my words with styles applied, and THEN see how it actually lays out on the page. And then be able to go back to just text without layout, and even back to the outline to rearrange. Being able to switch between those is key to my word processing workflow for longer documents (I've written a couple of books, plenty of whitepapers, and dozens of trade magazine articles).
Expression Design isn't really meant as a general purpose consumer drawing program. It's more focused on high-touch authoring of XAML objects for WPF/Silverlight use.
That said, XAML is just XML, so there are a variety of exporters from other tools. Like this one for Illustrator (Mac/Win)
http://www.mikeswanson.com/xamlexport/
Or Kaxaml:
http://www.kaxaml.com/
Pick a bunch of winners... Motion blur can be a problem!
File size is a decent heuristic here. A frame with a lot of motion blur won't have higher frequencies, and so with a fixed-quantization encode like JPEG, it'll be a smaller file size.
The biggest files will correlate with the frames with the most detail, mathematically.
Now, that's not saying that it wouldn't be a tight shot of a screen window, but it's a start :).
I think we're saying the same thing here; PSNR is not an ironclad indicator of quality on its own. While PSNR is a reasonably useful first-order hint, one should never assume that two PSNR values that are only somewhat appart means there will be a proporational difference in quality.
But the farther apart two encodes are in PSNR, the more likely there's going to be a visible difference. It's be very surprising to have a clip with a 10 dB worse PSNR actually look better. But within 1-2 dB, not surprising at all.
This is probably because the YV12 color space itself "bakes in" a fair amount of perceptual optimization, in terms of chroma subsampling, luma precision, and in particular the use of a perceptually uniform gamma curve. If we were talking about PSNR versus the Raw input from a camera's Beyer pattern CCD, it'd be much less useful in predicting subjective quality.
One simple example of something that improves visual quality while lowering PSNR is dithering; it reduces banding by adding LSB noise.
Eh? He's talked about PSNR plenty of times as a way to compare implementations and codecs.
Yep. 16-bit is something you master to, not master from.
You you believe that one codec can look very good with uncharacteristically poor PSNR, yet you still believe PSNR is useful for comparing different codecs...?
I imagine such a codec is theoretically possible, but doesn't exist. So it's had no imapct on any actual PSNR tests to date :).
Sure it will. PSNR just doesn't work that way. It is utterly useless for comparing the values of different encoders.
No argument it's not perfect, but it is useful, and is used to good effect by people making codecs. PSNR is a pretty accurate way to measure the effect of changes to any part of the codec other than perceptual optimizations.
Or will you just accept, on PSNR figures alone, that On2's proprietary crap vastly outperforms H.264, as well as every other codec on the planet?
Absolutely not, since they didn't give enough info to really understand what they did. We'd need to get Dark Shakiri or someone like that to do their best x264 encodes to get a useful comparison.
Yes, an archive for future transoding is a perfect use for Lossless. There have been various MP3/WMA + diff technologies proposed over the years, which would enable a "good enough" mobile encode plus entropy data to get back to lossless from there. That said, modern CPUs are probably fast enough to transcode from lossless faster than the transfer rate of portable devices, so I don't know if there's any point in preencoding anyway.
Personally, I think there's a pretty good value for lossy codecs better than MP3.
In-loop deblocking, sure. But the H.264 combined with adaptive block size in High Profile, seems particularly well suited.
Sure, many enjoy the psychological effect of knowing it's lossless. Storage is cheap enough that it coudl be worth it.
Pesonally, I tend to be more annoyed at my earbuds to enjoy that :).
And what if they offer you 48 KHz 20-bit lossy versus 44.1 KHz 16-bit lossless :)?
We think about the CD master or YV12 as being "lossless" but both represent a lot of perceptually tuned compromises well before they hit a codec. You can't estimate quality with a diff or a spec; it requires good ears, good content, and good reproduction equipment to figure out what's a difference that matters and what's a difference that doesn't.
We care about how it is percieved by the human auditory system here; it's not like we're trying to make bats dizzy.
15 megapixel cameras still support JPEG :).
Really, there's no more point to mathematically lossless audio than for video or images. We've got good models to know what kinds of artifacts are audible, and modern VBR codecs do an excellent job of raising bitate where it's needed to prevent those. And both AAC and WMA have better theoretical maximum accuracy than MP3, even if one is a golden ear sensetive to a few MP3 edge cases.
And its not like it's lossless from the mix anyway, it's lossless from the 16-bit 44.1 master. Those are bigger percetpual compromises than the difference between lossless and a good lossless.
And even if capacity is cheap, saving bits on audio leaves more for video or files or whatever. And makes for much faster syncs.
Well, I think it's overstated to call PSNR Utterly worthless. In practice, it's a useful ballpark indicator of how a codec is doing. For a car analogy, it's perhaps like trying to figure out speed from the RPM gauge; relevant, but not the whole story. And while there are all kinds of theoretical things that can be done to fake out PSNR, in the real world an encode with a bad PSNR is almost alwasy going to look pretty bad. It's certainly possible for two clips with a PSNR difference of 2 dB to have the mathematically less accurate one actually look better, but it's rare to have a big PSNR difference not indicate a big perceptual difference.
You can easily write a codec that is very strict in storing the "easy bits" exactly right, while completely and terribly distorting everything else on screen, while still getting a great PSNR. Your eyes just don't work that way. Things like adjusting the level of HF noise on screen negatively effects PSNR, yet it's something that is only barely consciously perceived by humans.
I think that would be harder to do in practice; a codec that looks good with poor PSNR, sure, there's tons of tricks. But one that looks bad with great PSNR? It cerrtainly isn't going to happen by accident, although perhaps someone with a very... specific sense of humor could build something like taht for their own amusement. And as tickled as I am by the idea, I can't think of any of the various oodec-related practical jokes over the years that involved buildn't an actual new encoder.
With H.264 in particular (which is the comparison point here) the strong in-loop deblocking filter will soften the kinds of sharp lines where human vision cares more than PSNR. That loop filter is probably the strongest single innovation in H.264, since it lets video degrade into softness, without introducing new erroneous detail at high quantization like older codecs did. So, unlike MPEG-2, having a highly compressed frame doesn't have the same negative impact on a later frame predicted from it.
But the loop filter softens detail, which makes it hard to have a few bad pixels and lots of great pixels in the way you desribe; instead it'll get blurring a a bunch of pixels will be off. Sure, it can be disabled, but then overall PSNR goes down a bunch as well.
All that said, I think SSIM is a better metric than PSNR for today's codecs in today's usage.
http://en.wikipedia.org/wiki/SSIM
But PSNR plots on a rate distortion curve are a good initial indication of compression efficiency in practice.
And being in the industry, I can state that big content companies and all the device companies have been well aware of this coming for some time, and they're a pretty frequest topic of discussion.
MPEG-2 and the original MPEG-4 codec had somewhat similar termrs, so this is really just business as usual in the digital media industry. Things are actually a lot more affordable with VC-1 and H.264 than with MPEG-2.
...although without rate control and with such a short clip (12.5 sec?) it really hard to make much of these numbers even if PSNR was calculated correctly.
We need to see a few minutes of video, with a VBV constraint.
Also, interframe encoding with wavelets has never been done well. Say what you will about classic Discreet Cosine Transformation codecs, those small blocks make it easy to track motion vectors between frames and get efficient interframe coding.
While I like wavelets for still images, they're not so much better than DCT that it makes up for DCT's advantages for interframe coding.
And implementations matter more than the transform. H.264 High Proifle can outperfom JPEG2000 for still image coding. That in-loop deblocking filter and CABAC are big helps.
Well, Moonlight's new preview release includes support for Silveright's Raw AV Pipeline:
http://on10.net/blogs/benwagg/First-Moonlight-20-Preview-Out-ndash-with-Smooth-Streaming/
The Raw AV pipeline would allow Ogg demuxing with Vorbis and Theora decoding to happen inside managed code in Silverlight/Moonlight.
So users who had either installed wouldn't need to install Ogg to get playback. The web site could just detect the plugin and embed a Silverlight player that includes the decoders.
Hmmm. Looks like someone's even working on one for Vorbis at least:
http://tirania.org/blog/archive/2009/Mar-24-1.html
I'd suspect:
QuickTime's H.264 gets the largest number of unique files, due to iPod etecetra transcoding.
Main Concept gets the most eyeball-hours, since it's used inside the tools used for lots of the big web sites.
x264 would e the leader for user generated content, both from the big UGC sites, and from hobbyist encoders.
Remember WMA? and AAC? no, the "big boys" ignored FLAC not because it wasn't popular enough, it was because both have *very* strong NIH sentiments against it, as they did with MP3.
Er, it was more that FLAC requires around, what 4-6x higher bitrate beyond a perceptually lossless codec?
Putting lossles files on a capacity constrained device like a portable media player is spending a lot of bits for a placebo effect.
Both AAC and WMA offer substantially bettter audio quality than MP3 at lower bitrates. WMA implementations also offer a 2-pass VBR mode, allowing predictible file size with the qualtiy advantages of VBR. And again, if you trying to put as much high quality music into as small enough space, those matter.
Turns out there was an error in the methadology used in the original comparison, which hit x264 for more than 4 dB of difference.
http://www.reddit.com/r/programming/comments/8iphn/theora_encoder_improvments_comparable_to_h264/c09eyvc
Edit: HAHAHA! We figured out what was wrong--thanks a ton, gmaxwell, for coming on IRC and resolving this! Turns out his testing methodology was flawed... but not in the way I thought!
Turns he out he did everything correctly... but he used ffmpeg for outputting the raw y4m file to have its quality measured by dump_psnr (but not for theora). Apparently, ffmpeg flags the output chroma as "420mpeg2" instead of "420", which results in over 4db of PSNR being slashed off of x264's results unfairly.
Oops. We already have a patch submitted to ffmpeg for the problem and a retraction of the Theora comparison results is in the works. Thanks to gmaxwell for taking the initiative and David Conrad (Yuvi) for finding the bug!
The Doom9 thread on the same topic:
http://forum.doom9.org/showthread.php?t=146893
Anyway, given H.264 is a more recent codec that is highly optimized for PSNR and has had many years of refinement in a number of implementations, it's hard to conceive of how Theora could even approach it in compression efficiency, let alone beat it.
Even later when Word was released for early PowerMacs, I found that Windows Word could not read the Word documents from my Macintosh.
Mac Office 4.2? The Mac and Win versions of Office have used the same file format since at least Office 97/98. Mac Office 6.0 was a dog, no doubt, on many levels. But that was also 15 years ago.
If you consider that the Office '97 formats still remain interoperable today, that's actually quite a good track record for these things. Through the 80's and 90's most major releases of most word processors and spreadsheets would introduce a new file format and varying degrees of interoperability issues.