976211 - MozAudioAvailable skips data at end of stream

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Ralph Giles (:rillian)]

Re-enabling content/media/test/test_framework.html in bug 964559 I find three problems:

1. audio.mozChannels is returning the native channel count again since we moved downmixing to the AudioStream object. Easy to switch the count back to 6.

2. the audioAvailable() check fails because the timestamp offset is too large. I don't entirely understand the intent here, but it's requiring that MozAudioAvailable fire with a new timestamp at less than 10 ms after the last. The final buffer we get is 200ms after the previous one. Can bump the limit but...

3. The test finally fails because only 5120 of 15360 samples are returned. It looks like we get four 1024-sample buffers as expected, and then a final 1024-sample buffer from the end of the stream after a 200ms gap. This is what's causing the interval test above to fail.

Comment 1

[Ralph Giles (:rillian)]

I've only intestigated with the one test file, but it looks like support is now buggy. Given the feature is deprecated and pref'd off, do we want to fix it, or just disable the test?

Comment 2

[Matthew Gregan [:kinetik]]

I don't think there's any point fixing the test, this code is going away very soon.

Comment 3

[Ralph Giles (:rillian)]

Attachment: Disable test_framerate.html

This was attached to bug 975640 accidentally. Moving here, carrying across r=kinetik.

Comment 4

[Ralph Giles (:rillian)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5e4b40a4da7c

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/5e4b40a4da7c