Closed
Bug 1242841
Opened 9 years ago
Closed 9 years ago
Make MDSM::mDecodedAudioEndTime zero-based
Categories
(Core :: Audio/Video: Playback, defect)
Core
Audio/Video: Playback
Tracking
()
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: jwwang, Assigned: jwwang)
Details
Attachments
(1 file)
Since the timestamps received by MDSM are always zero-based, we should also make mDecodedAudioEndTime zero-based. We will be able to remove checks like |mDecodedAudioEndTime == -1| to simplify the code.
Assignee | ||
Comment 1•9 years ago
|
||
Assignee: nobody → jwwang
Assignee | ||
Comment 2•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/32397/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32397/
Attachment #8711998 -
Flags: review?(kikuo)
Comment 3•9 years ago
|
||
Note that while MSE per spec has a time range of [0, oo); it is not uncommon to have the first video frame have a negative time. This happens rather regularly with YouTube videos.
We had to explicitly allow a leeway for negative values close to 0 for start time (as if we were to drop that frame (a keyframe) we would have to drop all frames to the next keyframe leaving a gap which would cause a stall.
So it's important to be aware that negative frames are allowed even for MSE (which doesn't adjust the times to start at 0 unlike the other player.
Assignee | ||
Comment 4•9 years ago
|
||
https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoderStateMachine.cpp#900
We adjust the timestamps by the start time. So the timestamps are still zero-based.
Comment 5•9 years ago
|
||
not for MSE we don't.
When using MSE, MediaFormatReated::ForceZeroStartTime() will return false. So times will not be adjusted (as with MSE, in particular with live stream, time will *not* start at 0 nor do we want them to)
Comment 6•9 years ago
|
||
Comment on attachment 8711998 [details]
MozReview Request: Bug 1242841 - Make MDSM::mDecodedAudioEndTime zero-based. r=kikuo.
https://reviewboard.mozilla.org/r/32397/#review29293
Attachment #8711998 -
Flags: review?(kikuo) → review+
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #5)
> not for MSE we don't.
>
> When using MSE, MediaFormatReated::ForceZeroStartTime() will return false.
> So times will not be adjusted (as with MSE, in particular with live stream,
> time will *not* start at 0 nor do we want them to)
I thought it is the other way around.
MediaFormatReader::ForceZeroStartTime() returns |!mDemuxer->ShouldComputeStartTime()| and MediaSourceDemuxer::ShouldComputeStartTime() returns false. So MediaFormatReader::ForceZeroStartTime() should return true for MSE, right?
Comment 8•9 years ago
|
||
My bad, the value I put was reverted, but what I describe is still the case.
ForceZeroStartTime is true, means it starts at 0 no matter the time of the first sample returned.
That is, the time of the first sample is not to be used to determine the reference time frame.
So if ForceZeroStartTime was false, every time will be adjusted according to the first sample's time so the first sample will appear as 0 no matter what.
But with MSE this is not the case, so the MDSM can see negative timestamp (even though per spec we should drop those frames)
Assignee | ||
Comment 9•9 years ago
|
||
Negative timestamps are fine since we take the greater value when updating mDecodedAudioEndTime in OnAudioDecoded(). (mDecodedAudioEndTime = std::max(audio->GetEndTime(), mDecodedAudioEndTime)) Negative timestamps are ignored in that sense.
So it still makes sense to initialize mDecodedAudioEndTime with 0 instead of -1.
Comment 10•9 years ago
|
||
Comment 11•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment 12•9 years ago
|
||
bugherder |
You need to log in
before you can comment on or make changes to this bug.
Description
•