Open Bug 932390 Opened 12 years ago Updated 3 years ago

Implement a fixed point vorbis encoder

Categories

(Core :: WebRTC: Audio/Video, defect)

ARM
All
defect

Tracking

()

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)
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
Component: Audio/Video → WebRTC: Audio/Video
backlog: --- → parking-lot
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.