Open
Bug 932390
Opened 12 years ago
Updated 3 years ago
Implement a fixed point vorbis encoder
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
NEW
| backlog | parking-lot |
People
(Reporter: rillian, Unassigned)
References
Details
We have a fixed-point vorbis decoder (the 'tremor' library) we use on platforms with poor floating point performance. For encoding, only the floating-point implementation in libvorbis is available
It would be nice to have a fixed-point encoder version so we could record WebM (VP8+Vorbis) and .ogg files with the MediaEncoder API.
Monty estimates this would take about a month of his time:
I agree with derf that it would take about a month, much of that in initial conformance testing and debugging. The largest pure coding time would be the forward MDCT, which is a relatively known quantity of work.
The first cut of the Tremor decoder took two weeks; an encoder should be relatively simpler. I should be able to shake off the rust in a week or so. So a month sounds right.
(https://bugzilla.mozilla.org/show_bug.cgi?id=883749#c29)
| Reporter | ||
Comment 1•12 years ago
|
||
While this would be nice to have, I don't think it's a good use of Monty's time. We already have the newer Opus codec which does have a fixed-point encoder. Support will not be as widely deployed as for v1 WebM (or .ogg!) when we release the MediaEncoder API, but it won't be far behind and this could help it along.
The worry that we'd have to pair Opus-in-WebM2 with the more expensive VP9 codec for video seems to be moot.
Blocks: 883749
Updated•10 years ago
|
Component: Audio/Video → WebRTC: Audio/Video
Updated•10 years ago
|
backlog: --- → parking-lot
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•