Closed Bug 1102666 Opened 10 years ago Closed 9 years ago

[MSE] Can't replay MP4 YouTube videos

Categories

(Core :: Audio/Video, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla36
Tracking Status
firefox36 --- verified

People

(Reporter: rowbot, Assigned: mattwoodrow)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

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.
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
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)
(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.
Blocks: 1105066
No longer blocks: 1105066
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
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
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
Depends on: 1145037
No longer depends on: 1145037
You need to log in before you can comment on or make changes to this bug.