Closed Bug 976211 Opened 6 years ago Closed 6 years ago

MozAudioAvailable skips data at end of stream

Categories

(Core :: Audio/Video, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: rillian, Assigned: rillian)

References

Details

Attachments

(1 file)

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.
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?
Flags: needinfo?(kinetik)
I don't think there's any point fixing the test, this code is going away very soon.
Flags: needinfo?(kinetik)
This was attached to bug 975640 accidentally. Moving here, carrying across r=kinetik.
Assignee: nobody → giles
Attachment #8381014 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/5e4b40a4da7c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.