Closed Bug 1186943 Opened 10 years ago Closed 10 years ago

Intermittent test_video_playback.py TestVideoPlaybackBase.test_video_playback_full or TestVideoPlaybackBase.test_video_playback_partial

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox42 --- affected

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure)

No description provided.
I have temporarily disabled these tests. This failure is a result of "new MSE" implementation being enabled by default in Nightly. These tests depend on the the notion of an "active stream" (as reported by mozMediaSourceObject.mozDebugReaderData) which no longer makes sense in the new MSE. Instead, we need a test that checks whether NextGetSampleIndex and NextInsertionIndex are both 0 when we detect a playback stall, for example. needinfo to :jya to confirm that my description of the new test is accurate.
Flags: needinfo?(jyavenard)
A stall would more likely be linked to NextGetSampleIndex being 0. This would indicate an internal failure (but only if there's an actual stall) Also of interest, would be if the currentTime is contained in the buffered range. Here is what it would typically display: https://www.youtube.com/watch?v=XqLTe8h0-jo mediasource:https://www.youtube.com/0f35d4c4-75bd-ee45-a767-0ba8c2aa347c currentTime: 129.844222 SourceBuffer 0 start=0 end=97.128594 start=120.000725 end=169.0639 SourceBuffer 1 start=0 end=97.2 start=124.2 end=168.96 Internal Data: Dumping data for demuxer 141ea5000: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 131.076598 NumSamples:6296 Size:3402996 NextGetSampleIndex:4660 NextInsertionIndex:6296 Buffered: ranges=[(0.000000, 97.128594), (120.000725, 169.063900)] Dumping Video Track Buffer(video/avc) - mLastVideoTime: 130.760000 NumSamples:3416 Size:21207069 NextGetSampleIndex:2461 NextInsertionIndex:3416 Buffered: ranges=[(0.000000, 97.200000), (124.200000, 168.960000)] Here you can notice that the buffered ranges have a discontinuity, that's because we just seeked to a non-buffered position. mLastAudioTime is the expected time of the next audio sample we are about to demux from the audio track buffer. mLastVideoTime is the expected time of the next video sample we are about to demux from the video track buffer. It really should be mNextAudioTime/mNextVideoTime but I wanted to keep small consistency with the previous MSE. if mLastAudioTime or mLastVideoTime isn't found in the respective buffered ranges: a stall will happen as soon as currentTime has caught up.
Flags: needinfo?(jyavenard)
Pull request: https://github.com/mjzffr/firefox-media-tests/pull/10 :maja_zf, please review.
So, what is the logic for detecting a stall, then? How would I know the video is stalled looking at this output? Is "NextGetSampleIndex == 0" a sufficient test?
Flags: needinfo?(jyavenard)
Component: Audio/Video → Audio/Video: Playback
The only way to tell if we have a genuine stall is currentTime value not progressing. The index being 0 may indicate a stall, but they can also just indicate a temporary state where we've been unable to retrieve data. But that situation is recoverable. Value will be set to 0 when data is evicted (either through self-eviction or an explicit call to sourcebuffer.remove) and the data being evicted overlaps with the data we are currently reading from. When that happens, and if no new data is appended, there will be a stall.
Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.