Closed Bug 1128332 Opened 5 years ago Closed 5 years ago

mediasource-duration.html test doesn't fire loadeddata


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




Tracking Status
firefox38 --- fixed
firefox39 --- fixed


(Reporter: jya, Assigned: jya)


(Blocks 1 open bug)



(5 files, 1 obsolete file)

This started after upgrading to m-c last Friday (last version where everything worked was 29b05d283b00) using patch queue from 1125776

loadeddata event is never fired in the webref test mediasource-duration.html 'Test abort in the middle of an initialization segment.' causing it to timeout.

This only seems to appear on Windows 8 and 7 on try.
same issue with mediasource-append-buffer.html

which does the same thing as mediasource-duration.html: waiting for loaded data after adding the same segments as above.

I had it happening once on Windows XP (over 20+ runs)
Interestingly, I now get it consistently for mediasource-append-buffer.html Test abort in the middle of an initialization segment.

and it succeeds on mediasource-duration.html on W7..
Priority: -- → P2
Attached file
Test to reproduce the problem.

The what's happening is that we have a partial mediasegment (complete moof but partial mdat).

MDSM calls RequestAudioData with mLastAudioTime=0 ; this fails as no audio data is available yet.

MediaSourceReader::OnAudioNotDecoded is called back with END_OF_STREAM.
mLastAudioTime is then adjusted to the end of the current stream to see if another one is available and that we could switch to.

And the audio mediapromise is rejected with WAITING_FOR_DATA

The 3rd appendBuffer does add the audio, however is audio add is between 0 and 0.5s.
As mLastAudioData was adjusted to be 0.53s we will never get audio data.

So loadeddata is never fired, and the test timeout.

This is a racey behaviour as if appendData happened to run before RequestAudioData is called, the test will succeed.
Assignee: nobody → jyavenard
Comment on attachment 8577994 [details] [diff] [review]
Part1. Add useful informations to logging

carrying r+ by :mattwoodrow
Attachment #8577994 - Flags: review+
Comment on attachment 8577995 [details] [diff] [review]
Part2. Don't consider decoding error as fatal

Carrying r+ from :mattwoodrow
Attachment #8577995 - Flags: review+
Retry from last failing position.
Attachment #8578012 - Flags: review?(matt.woodrow)
update webref accordingly
Attachment #8578013 - Flags: review?(karlt)
Comment on attachment 8578012 [details] [diff] [review]
Part3. Re-attempt to decode from last failed position

This causes failure of test_WaitingOnMissingData_mp4.html

I don't think we actually fail as such, but we don't pass the test on where playback stall.
Attachment #8578012 - Attachment is obsolete: true
Attachment #8578012 - Flags: review?(matt.woodrow)
Only use previous location if we were well within the current buffered range
Attachment #8578375 - Flags: review?(matt.woodrow)
Attachment #8578013 - Flags: review?(karlt) → review+
Test still occasionally timing out, will open a new bug 1143999 as the cause for this one was identified
Attachment #8578375 - Flags: review?(matt.woodrow) → review+
Comment on attachment 8577994 [details] [diff] [review]
Part1. Add useful informations to logging

Approval request for all patches.

Approval Request Comment
[Feature/regressing bug #]:1128332
[User impact if declined]:Less spec compliant. webref test failing
[Describe test coverage new/current, TreeHerder]:in m-c for over a week.
[Risks and why]: Low, it prevents a race condition that would cause intermittent failure
[String/UUID change made/needed]: None
Attachment #8577994 - Flags: approval-mozilla-aurora?
Flags: needinfo?(jyavenard)
Attachment #8577994 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I had W3 failure on my aurora try run, that's why I didn't push it. Obviously missing a dependency :(
Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.