[MSE] Can't replay MP4 YouTube videos

VERIFIED FIXED in Firefox 36

Status

()

Core
Audio/Video
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Trevor Rowbotham, Assigned: mattwoodrow)

Tracking

(Blocks: 1 bug)

Trunk
mozilla36
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
When MSE is enabled and the video is using MP4, clicking on the replay button after the video has finished playing results in it getting stuck at the start.  The only way to play the video again is to refresh the page.  This works perfectly fine when the video is using webm.  Querying the currentTime property on the video object indicates that it has in fact seeked back to the beginning of the video, however, the video refuses to play.  Possibly related to Bug 793069 and Bug 777051?

Please let me know if I can provide anymore information.

Comment 1

3 years ago
I can reproduce this with today's (24/11/2014) nightly moz central build (win32 on 64bit Win8.1, D2D etc enabled).

https://www.youtube.com/watch?v=3x0rbtq2rVs
Blocks: 1083588, 778617
(Assignee)

Comment 2

3 years ago
Created attachment 8528120 [details] [diff] [review]
Parse the edts block in MoofParser

What do you think about something like this?

This only fixes the MoofParser, we'd need to update MPEG4Extractor too.

This is enough to get replaying working for videos though.
Attachment #8528120 - Flags: feedback?(ajones)
Comment on attachment 8528120 [details] [diff] [review]
Parse the edts block in MoofParser

Review of attachment 8528120 [details] [diff] [review]:
-----------------------------------------------------------------

We also need to make sure this offset is applied correctly in MPEG4Extractor.

::: media/libstagefright/binding/MoofParser.cpp
@@ +354,5 @@
> +    mMediaStart = reader->Read64();
> +  } else {
> +    uint32_t segment_duration = reader->ReadU32();
> +    mMediaStart = reader->Read32();
> +  }

We get something like this on YouTube:

segmentDuration = 0 (0x00000000)
mediaTime = 3600 (0x00000e10)
mediaRate = 1 (0x0001)
reserved = 0 (0x0000)

We should check that segmentDuration=0 and use mediaTime. Looking at the MPEG4Extractor the mediaTime is in header timescale units from 'mvhd'. We'll need to parse that as well.

::: media/libstagefright/binding/include/mp4_demuxer/ByteReader.h
@@ +94,5 @@
>        return 0;
>      }
>      return mozilla::BigEndian::readUint64(ptr);
>    }
> +  

Whitespace
Attachment #8528120 - Flags: feedback?(ajones)
(Assignee)

Comment 4

3 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3)
 
> We get something like this on YouTube:
> 
> segmentDuration = 0 (0x00000000)
> mediaTime = 3600 (0x00000e10)
> mediaRate = 1 (0x0001)
> reserved = 0 (0x0000)
> 
> We should check that segmentDuration=0 and use mediaTime. Looking at the
> MPEG4Extractor the mediaTime is in header timescale units from 'mvhd'. We'll
> need to parse that as well.

This is basically what I have, though I want to confirm that segmentDuration=0 and warn if it's not.

According to the spec mediaTime is "in media time scale units, in composition time". I'm pretty sure this is matches the value we parse in from mdhd, and what we're converting from already.

segment_duration is in timescale units from the movie header box.
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> This is basically what I have, though I want to confirm that
> segmentDuration=0 and warn if it's not.

Sweet.

> According to the spec mediaTime is "in media time scale units, in
> composition time". I'm pretty sure this is matches the value we parse in
> from mdhd, and what we're converting from already.
> 
> segment_duration is in timescale units from the movie header box.

You are right. It looks like MPEG4Extractor might be wrong but it needs fixing up anyway.

Updated

3 years ago
Blocks: 1105066

Updated

3 years ago
No longer blocks: 1105066
(Assignee)

Comment 6

3 years ago
Created attachment 8528781 [details] [diff] [review]
Parse the edts block in MoofParser v2

This is a bit painful because we encounter elst before mdhd.

I also got rid of the 'halfscale' rounding up to the nearest timescale, since this was giving us incorrect results (-1 composition timestamps).
Assignee: nobody → matt.woodrow
Attachment #8528120 - Attachment is obsolete: true
Attachment #8528781 - Flags: review?(ajones)
Attachment #8528781 - Flags: review?(ajones) → review+
https://hg.mozilla.org/mozilla-central/rev/21a338c8ce9e
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37

Updated

3 years ago
Target Milestone: mozilla37 → mozilla36
Reproduced the initial issue on a old Nightly build from 2014-11-25, 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
Depends on: 1145037
No longer depends on: 1145037
You need to log in before you can comment on or make changes to this bug.