1102666 - [MSE] Can't replay MP4 YouTube videos

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Trevor Rowbotham [:rowbot]]

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

[timbugzilla]

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

Comment 2

[Matt Woodrow (:mattwoodrow)]

Attachment: 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.

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

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

Comment 4

[Matt Woodrow (:mattwoodrow)]

(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.

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(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.

Comment 6

[Matt Woodrow (:mattwoodrow)]

Attachment: 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).

Comment 7

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fe0fa358d7bc

Comment 8

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/260e64bc02d4, https://treeherder.mozilla.org/logviewer.html#?job_id=4212706&repo=mozilla-inbound

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/21a338c8ce9e

Comment 10

[Bogdan Maris, Desktop Test Engineering]

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.