On my machine, this video with a timestamp in its link does not play even though the video attempts load.
Error Console reports: Media resource mediasource:https://www.youtube.com/80753176-fb4d-415e-96db-f141f9ec3875 could not be decoded. watch Use of getAttributeNode() is deprecated. Use getAttribute() instead. html5player.js:36
Video plays without the timestamp url tacked on.
Thanks for the report. The element is blocked in the seek request waiting for buffers with a time of 70.042000. The two buffers contained in the file top out at 70.008 and 70.003: -1891649792[7fde7fa67e40]: MediaSourceReader(7fde7ee43400)::WaitForTimeRange(70042000) waiting -1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92aa0)::GetBuffered ranges=[(35.035000, 70.003000)] -1287424128[7fdeb21455c0]: MediaSource(7fde7ee13c10)::DurationChange(aNewDuration=70.008000 fuzz=0.001000) -1287424128[7fdeb21455c0]: MediaSource(7fde7ee13c10) Dispatch event 'sourceended' -1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92a10)::GetBuffered ranges=[(30.042000, 70.008000)] -1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92aa0)::GetBuffered ranges=[(35.035000, 70.003000)] I don't know why it's waiting for a time range of 70 vs the 40 we've requested to seek to from the time in the URL. Perhaps the bug lies there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The call the the reader's seek method shows it has a start time: -1891649792[7fde7fa67e40]: MediaSourceReader(7fde7ee43400)::Seek(aTime=70042000, aStart=30042000, aEnd=100047000, aCurrent=30042000) Note that aTime-aStart is actually the time we want to seek to. This is what the Seek call looks like on the same video but manually seeked instead of using the URL parameter: 524662528[7f75150d9da0]: MediaSourceReader(7f75101e9800)::Seek(aTime=40471640, aStart=0, aEnd=70005000, aCurrent=1401020)
This is what the WebMReader seek method gets when in a non-mse enabled firefox: WebMReader::Seek(aTarget=40000000 aStartTime=0 aEndTime=70087000 aCurrentTime=0 I wonder why MSE gets different values?
This happens because we compute the start time of the video (and the origin of the media timeline) as the time of the first frame provided to use by the media resource (see https://html.spec.whatwg.org/multipage/embedded-content.html#media-timeline). We then treat seek times as being relative to this start time/media timeline origin. In this case the true start time of the video is at 0 seconds, but with the timestamp provided the first frame we receive is at 30 seconds so we assume this is the start. Seeking to 40 seconds then gets adjusted to 70 seconds, and we try seek to a position past the end of the video. It looks like chrome/blink always uses a start time of 0 when working with MSE to avoid this problem. They create a ChunkDemuxer when working with a MediaSource: https://code.google.com/p/chromium/codesearch#chromium/src/media/blink/webmediaplayer_impl.cc&sq=package:chromium&type=cs&rcl=1414389207&l=893 and ChunkDemuxer::GetStartTime always returns 0: https://code.google.com/p/chromium/codesearch#chromium/src/media/filters/chunk_demuxer.cc&sq=package:chromium&type=cs&rcl=1414389207&l=1151
Attachment #8512381 - Flags: review?(cajbir.bugzilla) → review+
sorry Matt, had to back this out for test m-2 bustage on Linux, Windows like https://treeherder.mozilla.org/ui/logviewer.html#?job_id=3345868&repo=mozilla-inbound
5 years ago
Sadness, it appears that the Video/AudioQueue held by the MediaDecoderReader is not the same as the queue held by MediaDecoderStateMachine.
Attachment #8512956 - Flags: review?(cajbir.bugzilla) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Reproduced the initial issue on a old Nightly build from 2014-10-27, verified that the issue is fixed on Windows 7 64bit, Mac OS X 10.9.5 and Ubuntu 14.04 32bit using Firefox 36 beta 4.
Status: RESOLVED → VERIFIED
status-firefox36: --- → verified
You need to log in before you can comment on or make changes to this bug.