WebM HD
James Haigh
I realise that the codecs for '.webm' are fixed for good reason of
interoperability, and to avoid confusion, but I would very much like
to see a lossless audio codec such as FLAC, and a less lossy video
codec in the future.
Dirac is an open royalty-free HD video codec developed and used by the
BBC, and capable of high-quality compression of 'Ultra HDTV'. Dirac
even supports fully lossless compression!
I propose that the next generation of WebM uses FLAC as the audio
codec, Dirac as the video codec, and is named 'WebM HD', with a
differentiating filename extension and MIME type.
It may be a long way off considering the next generation, since WebM
is still quite young, but make sure that you do keep in mind both FLAC
and Dirac when you do get to that stage.
Best regards,
James Haigh.
Ralph Giles
> I propose that the next generation of WebM uses FLAC as the audio
> codec, Dirac as the video codec, and is named 'WebM HD', with a
> differentiating filename extension and MIME type.
That just leaves finding a name for it and, the hard part, convincing
people to use it.
I don't particularly like 'WebM HD' as a name, though. WebM already
does HD video.
-r
John Koleszar
> On Wed 13 Jun 2012 11:35:50 PM PDT, James Haigh wrote:
>
>> I propose that the next generation of WebM uses FLAC as the audio
>> codec, Dirac as the video codec, and is named 'WebM HD', with a
>> differentiating filename extension and MIME type.
>
>
> You can do that now, putting Dirac and FLAC in the Matroska container. That
> just leaves finding a name for it and, the hard part, convincing people to
> use it.
>
distinction of WebM is about what features are useful to support in a
web browser. I expect lossless video will be part of the next
iteration, as there have been cases identified where it would be
useful to send at least certain frames losslessly. I think that the
case for lossless audio in the browser is less well defined. If you
have ideas for use cases for this, by all means, put them forward.
James Haigh
On Jun 15, 2012 4:23 PM, "John Koleszar" <jkoleszar@google.com> wrote:
The web isn't just about web browsers on old PCs anymore. Take Miro for example, or Internet TVs, or apps on a HD Android tablet. Lossless audio in the browser could still be appreciated with headphones or earphones, and some people do have high-quality speaker systems hooked up to their computer.
There may also be use-cases for VP8+FLAC and Dirac+Vorbis. So the codecs of WebM 1G should carry across, but WebM 2G should still be restricted to allow easy popularisation. It should only allow VP8 or Dirac video, with Vorbis or FLAC audio.
On further consideration of the name, 'WebM HD' is perhaps not the best. Yes, WebM is capable of HD, but the typical compression artifacts of low-bitrate videos are ugly. I actually prefer high-quality SD over low-quality HD. However, just because something is encoded in a codec capable of unrivaled quality, doesn't mean that it /is/ of high-quality. Even FLAC could be low-quality if for example someone converted an mp3 to FLAC, not realising that the lossiness is preserved in perfect detail, and that the conversion merely wastes space. So 'WebM HD' is misleading, and would cause confusion.
So what are the alternatives? What will promote these 4 codecs as the next generation of video? Here are some suggestions:
* WebM 2G (.webm2, .webm2g)
* WebM 2 (.webm2)
* WebM Plus (.webm+, .webmplus)
* WebM NG (.webmng)
I'm leaning towards WebM Plus, which signifies extension. WebM is VP8+Vorbis. WebM Plus is either Dirac+Vorbis, VP8+FLAC, or Dirac+FLAC. This would ensure that encoding a video into VP8+Vorbis, would not accidentally be incompatible with the current web just because of it's MIME type or file extension.
WebM Plus would not hinder the adoption of WebM because for a browser to be WebM Plus compliant, it would have to support all 4 codecs and would naturally implement WebM first. On the other hand, a WebM compliant browser such as Firefox, would pretty much only have to include 2 more Free codecs to become WebM Plus compliant.
James.
Harald Alvestrand
On Jun 15, 2012 4:23 PM, "John Koleszar" <jkoleszar@google.com> wrote:
>
> On Thu, Jun 14, 2012 at 10:01 PM, Ralph Giles <giles@thaumas.net> wrote:
> > On Wed 13 Jun 2012 11:35:50 PM PDT, James Haigh wrote:
> >
> >> I propose that the next generation of WebM uses FLAC as the audio
> >> codec, Dirac as the video codec, and is named 'WebM HD', with a
> >> differentiating filename extension and MIME type.
> >
> >
> > You can do that now, putting Dirac and FLAC in the Matroska container. That
> > just leaves finding a name for it and, the hard part, convincing people to
> > use it.
> >
>
> As Ralph said, you can already do this with other containers. The
> distinction of WebM is about what features are useful to support in a
> web browser. I expect lossless video will be part of the next
> iteration, as there have been cases identified where it would be
> useful to send at least certain frames losslessly. I think that the
> case for lossless audio in the browser is less well defined. If you
> have ideas for use cases for this, by all means, put them forward.The web isn't just about web browsers on old PCs anymore. Take Miro for example, or Internet TVs, or apps on a HD Android tablet. Lossless audio in the browser could still be appreciated with headphones or earphones, and some people do have high-quality speaker systems hooked up to their computer.
Steve Lhomme
to be viewable in a web browser. Most people don't already have enough
bandwidth to play a 1080p file over YouTube. But the web browser is
become the center of attention for a lot of application development.
They are not necessarily served remotely or on constrained bandwidth.
So it would make sense to have much bigger files when high playback
quality is required. It is clear that lossy video even at high bitrate
can still be noticeable from the end user, lossless audio advantage is
less clear.
My $.02
On Sun, Jun 17, 2012 at 1:38 PM, Harald Alvestrand <h...@google.com> wrote:
>
>
> On Sat, Jun 16, 2012 at 1:06 AM, James Haigh <james....@gmail.com>
> wrote:
>>
> You received this message because you are subscribed to the Google Groups
> "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to
> webm-discuss...@webmproject.org.
> For more options, visit this group at
> http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
--
Steve Lhomme
Matroska association Chairman
Carlo Strata
What a beautiful thing seeing my ancient (24/08/2010 00:16) proposal
somewhat reborn... :-)
http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/c6f376f539a0ae53/79f364175207d432
I also had posted it on my blog
http://blog.libero.it/Spunti/9186819.html
and I had direct contacted both Xiph people and Dirac/Schr�dinger people.
Is now the right time? ;-)
Have a sunny sunday,
Carlo
--
ing. Carlo Strata
-
via Botticelli 1/4
30031 Dolo - VE
Italia - Italy
-
tel./fax +39.041.822.0665
cell. +39.347.85.69.824
skype carlo.strata
-
carlo....@tiscali.it
PEC: carlo....@ingpec.eu
John Koleszar
>
>
> On Sat, Jun 16, 2012 at 1:06 AM, James Haigh <james....@gmail.com>
> wrote:
>>
possible with Theora, improved quality in the cases Theora is suitable
for, and will hopefully be mandatory to implement in the browser
anyway for WebRTC.
The question to me is what use cases can we enable by having true
lossless support that you can't get with high rate Opus. I don't mean
to give the impression I'm against FLAC, and this question isn't
rhetorical. FLAC is already used in Chrome for voice search, and it's
supported for playback on Android iirc. With FLAC over RTP maybe we
could do something like what Apple is doing with AirPlay. Just a
couple examples. But we need to identify these use cases and see if
they're compelling enough to make another codec mandatory.
Silvia Pfeiffer
> On Sun, Jun 17, 2012 at 4:38 AM, Harald Alvestrand <h...@google.com> wrote:
>>
>>
>> On Sat, Jun 16, 2012 at 1:06 AM, James Haigh <james....@gmail.com>
>> wrote:
>>>
>>> On Jun 15, 2012 4:23 PM, "John Koleszar" <jkol...@google.com> wrote:
>
> Opus support is a no-brainer in my opinion, as it brings features not
> possible with Theora, improved quality in the cases Theora is suitable
> for, and will hopefully be mandatory to implement in the browser
> anyway for WebRTC.
Silvia.
John Koleszar
Um, yes. :-)
James Haigh
On Jun 17, 12:38 pm, Harald Alvestrand <h...@google.com> wrote:
> On Sat, Jun 16, 2012 at 1:06 AM, James Haigh <james.r.ha...@gmail.com>wrote:
[...]
> > The web isn't just about web browsers on old PCs anymore. Take Miro for
> > example, or Internet TVs, or apps on a HD Android tablet. Lossless audio in
> > the browser could still be appreciated with headphones or earphones, and
> > some people do have high-quality speaker systems hooked up to their
> > computer.
>
> Of course anyone who wants to think about what "lossless audio" means need
> to read Monty's article on the subject:
>
> http://people.xiph.org/~xiphmont/demo/neil-young.html
>
> Being an WebRTC addict, I woiuld argue that WebM Plus SHOULD include OPUS
> as an audio codec option.
That's an excellent article. Please distinguish lossless from sample rate. I don't disagree that an excessively high sample rate of 192kHz is of inferior quality in typical end-user use-cases, but I'm primarily thinking of lossless audio at typical values of 16 or 24bit, 44.1 or 48kHz.
I did consider Opus, I thought it was optimised for speech rather than general audio (hey, I'd like to see this more in telecommunications). I'd still hope for a lossless audio codec just to be future-proof. Be aware that just because one person - or even most people - can't see or hear compression artifacts doesn't mean to say that they're not humanly visible/audible. I for one will be glad to see the end of the block artifacts of discrete cosine transform based compression which I find very irritating, and don't find some mp3 files very nice to listen to either.
Keep in mind Moore's law. It will take some time to implement and finalise, then it has to be adopted and deployed. We're looking at 1 or 2 years up to 1 or 2 decades say. Take a look at the last couple of decades, it has surprised us at times. There will be unforeseen use-cases, and transfer and storage is already becoming throwaway. We don't want it to start showing it's age before it has even been widely deployed.
Considering this, I think a lossless audio codec is more appropriate than Opus. By all means include Opus /as well/, as long as it won't put a significant burden on adoption. FLAC itself may be ready for a refresh. It may be able to improve compression with new techniques. I don't know, but if so, it would be worth synchronising with this, and if so would reduce the continuously diminishing size disadvantage.
Note that even though lossless audio is only a marginal improvement over high-bitrate lossy compression for most people, it would also help WebM to fend off any kind of silly marketing from Apple and the likes, as noted in that article, and would thus help adoption.
Also, I've contacted the BBC about Dirac and WebM. I'll update you on this later.
James.
James Haigh
> > Being an WebRTC addict, I woiuld argue that WebM Plus SHOULD include OPUS
> > as an audio codec option.
Ps. Sorry, yes, I've just realised what WebRTC is (I was focusing on the article before). That looks like a really great part of HTML5! Ok, 5 codecs (2, +3), that's not too bad is it?
Ralph Giles
> Ok, 5 codecs (2, +3), that's not too bad is it?
various next-generation video codec efforts start to bear fruit.
Like John, I expect vp8+opus to happen in some form. Those will be the
baseline codecs for WebRTC, and WebRTC has a recording requirement. The
most natural thing to do is to put both in the matroska container as
they come in. Whether such files get the extension .mkv or .webm
or .webm2 I don't know.
We (Xiph and Mozilla) have also been promoting Opus in the Ogg container
as a new candidate for a baseline audio format for the web. See for
example http://people.xiph.org/~giles/2012/opus/.
On 12-06-15 8:23 AM, John Koleszar wrote:
> I think that the
> case for lossless audio in the browser is less well defined. If you
> have ideas for use cases for this, by all means, put them forward.
traditional sense than with media players, editing suites, and mastering
applications which happen to be written in HTML. Those will want support
for lossless audio (and high-bitrate or lossless video) as more
traditional implementations do.
-r
James Haigh
On Jun 19, 2012 5:53 PM, "Ralph Giles" <gi...@thaumas.net> wrote:
>
> On 12-06-19 4:29 AM, James Haigh wrote:
>
> > Ok, 5 codecs (2, +3), that's not too bad is it?
>
> Sounds like quite a lot to me! Next year it will be 3+3, when the
> various next-generation video codec efforts start to bear fruit.
The web needs flexibility to innovate, these 5 codecs seem to cover the different use-cases needed now or starting to emerge. Here's a summary of how I understand it:
Video:
Dirac: less lossy wavelet video compression for less space than discrete cosine transform, also supports lossless.
VP8: CPU-cheap discrete cosine transform for old hardware
Audio:
FLAC: lossless audio compression - due to Moore's law the extra space will matter less and less, and it will become preferred for more things.
Vorbis: general purpose lossy audio compression
Opus: low-latency speech-optimised compression
I think this portfolio is pretty future proof, so if done right, it shouldn't need a new generation for quite some years (consider how long GIF and JPEG 1992 are lasting).
>
> Like John, I expect vp8+opus to happen in some form. Those will be the
> baseline codecs for WebRTC, and WebRTC has a recording requirement. The
> most natural thing to do is to put both in the matroska container as
> they come in. Whether such files get the extension .mkv or .webm
> or .webm2 I don't know.
>
> We (Xiph and Mozilla) have also been promoting Opus in the Ogg container
Mozilla? Hey, hi. I've used Firefox since version 2.
I would hope that Firefox supports all these 5 formats at some point anyway, and that others follow suit. In fact, I'm pretty sure it has flac .oga support.
> as a new candidate for a baseline audio format for the web. See for
I think any _baseline_ format has to be flexible enough to cater for the _whole_ web.
> example http://people.xiph.org/~giles/2012/opus/.
Looking forward to VoIP in the browser.
>
> On 12-06-15 8:23 AM, John Koleszar wrote:
>
> > I think that the
> > case for lossless audio in the browser is less well defined. If you
> > have ideas for use cases for this, by all means, put them forward.
>
> The usecase for lossless has less to do with browsing web pages in the
> traditional sense than with media players, editing suites, and mastering
> applications which happen to be written in HTML. Those will want support
> for lossless audio (and high-bitrate or lossless video) as more
> traditional implementations do.
HTML5 media players etc. can't be forgetten and will increase, but like I said previously, it's not just about browsers. Many applications use http.
James.
>
> -r
Ralph Giles
> I would hope that Firefox supports all these 5 formats at some point
> anyway, and that others follow suit. In fact, I'm pretty sure it has
> flac .oga support.
effects matter, and as well as fragmenting the adoption space, each
codec imposes a support burden so it's best to use the minimum
reasonable subset. That's why Firefox doesn't have native support for
Speex, or FLAC, or mpeg-in-avi, or ALAC, or mng, etc.
Note that Moore's law (and jit research) have made it possible to decode
a lot of of audio formats in javascript. See
http://labs.official.fm/codecs/flac/ for some recent demos. Video still
needs native code to be useful.
-r
James Haigh
On Jun 19, 2012 9:04 PM, "Ralph Giles" <gi...@thaumas.net> wrote:
>
> On 12-06-19 11:11 AM, James Haigh wrote:
>
> > I would hope that Firefox supports all these 5 formats at some point
> > anyway, and that others follow suit. In fact, I'm pretty sure it has
> > flac .oga support.
>
> Mozilla's position has been that format proliferation is bad. Network
> effects matter, and as well as fragmenting the adoption space, each
Supporting a single lossless format is by no means fragmentation. I too, would like harmonisation of Free formats on the web, but if the the formats are fundamentally different, they cannot be harmonised. I see 3 audio 'profiles': lossless, lossy speech, and lossy general-purpose.
> codec imposes a support burden so it's best to use the minimum
> reasonable subset. That's why Firefox doesn't have native support for
> Speex, or FLAC, or mpeg-in-avi, or ALAC, or mng, etc.
Hey? Doesn't Firefox have FLAC .oga?
James.
Ralph Giles
> Hey? Doesn't Firefox have FLAC .oga?
Mozilla codebase.
-r
James Haigh
Quite right. Disappointing. I was excited the other day to find I could play a .oga file, but, err, I'd mixed it up with a .ogg.
I'm sad to see Mozilla opposing a Free format. If you really want Opus a as 'baseline' format for everyone, then you need to add a lossless mode to the Opus standard. Otherwise, include FLAC and stop being so stubborn.
I was least expecting resistance from Mozilla, who are for openness not restriction.
James.
>
> -r
Ralph Giles
> I was least expecting resistance from Mozilla, who are for openness not
> restriction.
of openness. If Firefox supports FLAC, but no other browser does, how is
that different from a feature that only works in Internet Explorer?
What's valuable are cross-platform features. Not just something everyone
*can* implement, but something most user agents *do* implement.
We're suggesting Opus because there are many reasons to implement it,
and it will be attractive enough on those merits that browsers which
don't already implement ogg and webm will adopt it. That would be a step
toward breaking the mpeg-vs-free codec deadlock we've had since the HTML
media elements were introduced.
None of which addresses your usecase for lossless audio, I know. I'd
like to see native FLAC support too! But it's more complicated than
you're giving it credit for here.
Openness means you can write a patch and reopen
https://bugzilla.mozilla.org/show_bug.cgi?id=586568, and distribute your
own builds of the mozilla codebase with the patch applied. But you need
to address those arguments, and the ones John brought up in the context
on WebM, to convince enough people to change the larger projects.
Sincerely,
-r
James Haigh
Hey! I've just realised that Apple Lossless is Free, royalty-free, and licensed under the Apache 2 licence.
https://en.wikipedia.org/wiki/Apple_Lossless
If this was used instead of FLAC, it could get Apple on board. After all, the only major platform that WebM can't be applied to is iOS, because it is so locked down. If using ALAC helps get Apple interested, then this could end the deadlock.
Furthermore, I suspect that Safari already supports ALAC through QuickTime.
On Jun 20, 2012 1:18 AM, "Ralph Giles" <giles@thaumas.net> wrote:
>
> On 12-06-19 4:33 PM, James Haigh wrote:
>
> > I was least expecting resistance from Mozilla, who are for openness not
> > restriction.
>
> I think you've misunderstood the argument. There is more than one kind
> of openness. If Firefox supports FLAC, but no other browser does, how is
> that different from a feature that only works in Internet Explorer?
> What's valuable are cross-platform features. Not just something everyone
> *can* implement, but something most user agents *do* implement.
If at least one cross-platform browser supports it, then it too is available cross-platform.
h.264-promoting IE and Safari aren't cross-platform anyway, which makes h.264 unsuitable as a baseline standard. WebM is gaining traction as the baseline, it's just a matter of time.
>
> We're suggesting Opus because there are many reasons to implement it,
> and it will be attractive enough on those merits that browsers which
> don't already implement ogg and webm will adopt it. That would be a step
> toward breaking the mpeg-vs-free codec deadlock we've had since the HTML
> media elements were introduced.
Is there any reason why lossless audio can't be included without promoting it as _the_ baseline?
>
> None of which addresses your usecase for lossless audio, I know. I'd
> like to see native FLAC support too! But it's more complicated than
> you're giving it credit for here.
I just want to see native lossless support, I don't care which royalty-free codec is used.
James.
Ralph Giles
> Furthermore, I suspect that Safari already supports ALAC through QuickTime.
alacconvert, but my Safari 5.1.7 (7534.57.2) wouldn't play it. However,
alacconvert uses the CAF container, and some online descriptions mention
m4a, so it might work in the iso mp4 container.
-r
James Haigh
On Jun 20, 2012 7:34 PM, "Ralph Giles" <gi...@thaumas.net> wrote:
>
> On 12-06-20 10:57 AM, James Haigh wrote:
>
> > Furthermore, I suspect that Safari already supports ALAC through QuickTime.
>
> Can you check? It would be nice to know for sure. I made a file with
I absolutely cannot check. Safari is not cross-platform. It does not support Ubuntu Linux or Android, the 2 systems I use.
> alacconvert, but my Safari 5.1.7 (7534.57.2) wouldn't play it. However,
> alacconvert uses the CAF container, and some online descriptions mention
> m4a, so it might work in the iso mp4 container.
Firstly does it play in QuickTime? Apparently Safari uses QuickTime and can play any QuickTime-supported file.
Secondly, I think ALAC is primarily used in the .m4a container.
James.
>
> -r
Mike Melanson
> available cross-platform.
to be run in a sandbox within the browser.
Chrome is cross-platform.
Ergo, port FFmpeg to NaCl. Then you'll have *11* lossless audio codecs to
choose from, and it would be cross platform.
By your stated criteria, this should be good enough.
Get porting.
--
-Mike Melanson
Ralph Giles
> Firstly does it play in QuickTime? Apparently Safari uses QuickTime and
> can play any QuickTime-supported file.
> Secondly, I think ALAC is primarily used in the .m4a container.
-r
Mike Melanson
http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.m4a
--
-Mike Melanson
James Haigh
On Jun 20, 2012 8:18 PM, "Mike Melanson" <mi...@multimedia.cx> wrote:
>
> > If at least one cross-platform browser supports it, then it too is
> > available cross-platform.
>
> Google's Chrome web browser supports Native Client which allows C/C++ code
> to be run in a sandbox within the browser.
Awesome! It even supports LLVM! So I can use code in any language, and could eventually ditch crappy JavaScript!
But it doesn't support Firefox.
James.
>
> Chrome is cross-platform.
>
> Ergo, port FFmpeg to NaCl. Then you'll have *11* lossless audio codecs to
> choose from, and it would be cross platform.
>
> By your stated criteria, this should be good enough.
>
> Get porting.
>
> --
> -Mike Melanson
>
Ralph Giles
> Samples archive to the rescue:
>
> http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.m4a
So my earlier test was incorrect. Safari supports ALAC playback in .caf
and .m4a containers on both MacOS and the random iOS device we tried.
-r
James Haigh
[...]
The bitrate of that file works out as less than 896kbps:
>>> 6719490*8./60
895932.0
Which is less than 3-fold above mp3@320:
>>> 6719490*8./60/320000
2.7997875
Taking the half-life for Moore's law at -18months, this makes ALAC
less than 27months behind mp3@320 in terms of filesize:
>>> 2**(27./18)
2.8284271247461903
Refusing native support for lossless is not future-proof.
James.
James Haigh
> On 20/06/2012, Mike Melanson <mi...@multimedia.cx> wrote:
> [...]
>> Samples archive to the rescue:
>>
>> http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.m4a
>
> The bitrate of that file works out as less than 896kbps:
>>>> 6719490*8./60
> 895932.0
>
> Which is less than 3-fold above mp3@320:
>>>> 6719490*8./60/320000
> 2.7997875
>
> Taking the half-life for Moore's law at -18months, this makes ALAC
> less than 27months behind mp3@320 in terms of filesize:
>>>> 2**(27./18)
> 2.8284271247461903
>>> import math
>>> abs(math.log(2.7997875, 2)*-18)
26.735711989799317
Mike Melanson
> [...]
>> Samples archive to the rescue:
>>
>> http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.m4a
>
> The bitrate of that file works out as less than 896kbps:
>>>> 6719490*8./60
> 895932.0
>
> Which is less than 3-fold above mp3@320:
>>>> 6719490*8./60/320000
> 2.7997875
>
> Taking the half-life for Moore's law at -18months, this makes ALAC
> less than 27months behind mp3@320 in terms of filesize:
>>>> 2**(27./18)
> 2.8284271247461903
>
> Refusing native support for lossless is not future-proof.
calculations? Are you dismayed that lossless audio codecs do not approach
the compression of perceptual audio codecs? That's a basic property of
compression.
--
-Mike Melanson
James Haigh
years behind the highest-quality mp3 in terms of filesize. The size
disadvantage will exponentially diminish over time and lossless will
become more common.
SMC
>
> years behind the highest-quality mp3 in terms of filesize. The size
> disadvantage will exponentially diminish over time and lossless will
> become more common.
ISP still can't or won't provide faster connections and the available cell data providers want to charge
a fortune for limited data downloads.
Arguably, Moore's Law suggests that CPU processing power will make compression complexity irrelevant
by permitting more complicated calculations for better compression/decompression with better but still
lossy fidelity, rather than encouraging comparatively lower complexity (I'm assuming here, correct me
if I'm wrong) lossless compression.
I'd DEFINITELY like to see Opus support, however - given how much interest there seems to be for using it in
VoIP applications and WebRTC, it seems like there'll be a good chance for common hardware-accelerated
implementations popping up from many different suppliers.
(Not that I actually have any objection to FLAC support either as an optional audio component for "WebmPlus"
or whatever it will be called or just as support for .flac files in browsers, just saying that the usefulness of
FLAC for web-distribution or streaming of audio seems pretty small compared to its utility as an archival format.
)