Closed Bug 1684126 Opened 3 years ago Closed 3 years ago

Fail to play radio on "hichannel.hinet.net"

Categories

(Core :: Audio/Video: Playback, defect, P3)

Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
86 Branch
Tracking Status
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- verified

People

(Reporter: alwu, Assigned: alwu)

Details

Attachments

(2 files)

STR.

  1. go to https://hichannel.hinet.net/radio/index.do (VPN needed, the website is only available in Taiwan)
  2. wait for ad ended

Expect.
3. the radio starts successfully

Actual
4. the radio fails to start

This issue only happens on Windows.

Summary: Hi → Fail to play radio on "hichannel.hinet.net"

This is the root cause, we should change the original time as well. The decoding failed here because of incorrect original time.

The start time of the last frame we sent to MFT decoder is 22034000, but the start time decoder returned to us is 22033999. As we want to adjust that frame to the last frame time, so we would modify the start time to 22034000. Then, when we were doing trimming, the end time of the trimmer window was larger than mOriginalTime + originalDuration (only larger 1), which causes returning an error.

In AudioData, we use mOriginalTime to store the original start time before trimming, which should keep sync to mTime if data hasn't been trimmed before. Otherwise, if they are not equal, it would cause a problem when handling trimming.

For example.
If audio data's time is X, original time is X-1 and duration is T. When MDSM performs seeking, it would use (X + T) as trimming window's end time. However, in AudioData::SetTrimWindow(), original time + duration (X - 1 + T) would be less than the trimming end time, which causes an error.

Alastor, what does the website look like? Does it look like it's using hls (downloading a manifest then .ts files), or dash maybe (a manifest, and then fragmented mp4) ? It would be nice to write a test for this.

Flags: needinfo?(alwu)

I made a stupid mistake, the reason I could not reproduce the issue on the file I captured was because I didn't play it via MSE API, I simply played it in a normal playback path. Now you should be able to see the error when opening this page on Windows10.

Will add test and ask for a review again, thanks!

Flags: needinfo?(alwu)

Depends on D100825

Attachment #9195495 - Attachment description: Bug 1684126 - modify `mTime` and `mOriginalTime` together. → Bug 1684126 - part1 : modify `mTime` and `mOriginalTime` together.
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/30501df4232b
part1 : modify `mTime` and `mOriginalTime` together. r=padenot,bryce
https://hg.mozilla.org/integration/autoland/rev/ccdcd06ee7d9
part2 : add test. r=padenot
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Flags: qe-verify+

Reproduced on Firefox Nightly 86.0a1 (20201223092736) on Windows 10x64.
Verified fixed on Firefox beta 86.0b4 (20210131185630) on Windows 10x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: