Use lewton instead of libvorbis and some little improvements

[est31]

• Use lewton instead of libvorbis. Fixes #29
• Improve mutability correctness for the video decoder API
• Fix some compilation warnings

I didn't exchange libogg with the ogg crate yet because of API restrictions. I need to come up with a better concept for this upstream.

[est31]

Out of similar reasons as to why I didn't use the ogg crate, I didn't do a PR for the gif crate yet.

[pcwalton]

This looks good to me, but I'd like sign-off from a Vorbis expert.

@metajack Do you have thoughts on lewton?

[est31]

A few points about lewton:

• Floor0 is probably not relevant anymore, but its still supported, just like libvorbis does. stb_vorbis doesn't do it for example.
• On rust nightly-2016-10-19, it is about 20% slower than libvorbis for floor 1, but for floor 0 its faster (not that floor 0 is relevant, but hey, its faster xD). Performance in both scenarios should be fast enough for all purposes.
• all uses of unsafe in the crate are two one liner functions doing something terribly trivial.
• For all files I've tested it produces almost exactly the same results as libvorbis. This means that in all the floor 1 files I've tested, I haven't found a single sample where the two decoders would be farther away than 1 (for 16 bit signed samples). For a floor 0 file I found one sample where the two implementations differed by 2. Given that vorbis is lossy, these tiny differences are okay I think.
• You can play around yourself by cd'ing to the dev/cmp directory and running cargo run --release vals <file name here> to compare the output or cargo run --release perf <file name here> to compare the speed with libvorbis. cargo test --release and cargo run --release bench will run benchmarks and value comparisons for a set of test files.

[metajack]

This looks a lot simpler, and I'm a big fan of the removal of most unsafe code. We should make sure we are opting into the ieee754 feature when used.

Also, we should probably have some unit tests that decode simple files just as a sanity check.

I'd love to see benchmarks of this vs. libvorbis so we know what optimization work needs to be done down the road.

[est31]

@metajack when I run the benchmark tool I described in the post above, I get (these files are automatically downloaded from fairly stable locations):

Comparing speed for bwv_1043_vivace.ogg : libvorbis=0.8301s we=1.0253s difference=1.24x
Comparing speed for bwv_543_fuge.ogg    : libvorbis=1.3267s we=1.6383s difference=1.23x
Comparing speed for maple_leaf_rag.ogg  : libvorbis=0.3890s we=0.4762s difference=1.22x
Comparing speed for hoelle_rache.ogg    : libvorbis=0.6277s we=0.7707s difference=1.23x
Comparing speed for thingy-floor0.ogg   : libvorbis=0.3503s we=0.2717s difference=0.78x

Overall time spent for decoding by libvorbis: 3.5238s
Overall time spent for decoding by us: 4.1823s
Overall ratio of difference: 1.19x

[est31]

@metajack I've enabled the ieee754 feature as requested.

About the sanity test unit tests: Where do you want them, here or in the lewton repo, because there are already such test files inside the lewton repo (you cd into dev/cmp then run cargo test --release)?

[pcwalton]

I think here is a good place for the tests.

[metajack]

I'm totally fine with 20% perf regression in exchange for safety. We can optimize lewton if needed.

I would like some sanity tests here, but they can be cursory since lewton is already also testing. Mostly I want to protect against the error case where rust-media still builds but doesn't actual work; that situation is common on Servo for android where we don't have any smoke tests.

[est31]

Added an unit test. I couldn't use the ogg container decoder from rust-media as it isn't exposed via the high level API yet.

[pcwalton]

Awesome, thanks!