1357484 - MP4 Video won't play in Firefox in some circumstances, but will in Chrome

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Benjamin Smedberg]

This is an MP4 video I created using a screen-capture tool. It's encoded using H264.

It plays back correctly in the following circumstances:
* Firefox when uploaded to Google drive and played
* Chrome-Windows (loaded any way)
* Chrome-Linux (loaded any way)
* Edge (loaded any way)

It does not play back correctly in the following circumstances:
* Firefox loaded via file:
* Firefox served from my local machine via HTTP (python -m SimpleHttpServer)

In the case where it does not play back correctly, I have the following symptoms:
* The first frame shows
* The video controls are active and the scrubber slides along
* No video frames are shown

Also I tried to use .seekToNextFrame() on this, and it appears to seek to the end, as if there were no frames.

Jean-Yves, padenot said to NEEDINFO you. This is urgent to me because this blocks some quantum analysis of video screen captures.

Comment 1

[Benjamin Smedberg]

Oh, link! https://drive.google.com/file/d/0Bw3-54eJ7D8OQkxUelE3RzVZcWs/view?usp=sharing

Comment 2

[Jean-Yves Avenard [:jya]]

it doesn't play for me even when hosted on drive.google.com

Comment 3

[Jean-Yves Avenard [:jya]]

at a guess it's the sniffer that doesn't recognise this file.. and via drive.google.com (it only works if I'm logged in for some reason) the mimetype is provided by the server.

Comment 4

[Jean-Yves Avenard [:jya]]

[ftyp] size=8+24
  major_brand = M4V 
  minor_version = 1
  compatible_brand = M4V 
  compatible_brand = M4A 
  compatible_brand = mp42
  compatible_brand = isom

that's not a standard mp4 as per ISOBMFF, and we only check the major_brand.
The sniffer should be extended to check more than the first 32 bits.

Comment 5

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1357484: [mp4] Add m4v major type support.

Review commit: https://reviewboard.mozilla.org/r/133344/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/133344/

Comment 6

[John Lin [:jhlin][:jolin]]

Comment on attachment 8861356 [details]
Bug 1357484: [mp4] Add m4v major type support.

https://reviewboard.mozilla.org/r/133344/#review137128

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/c81d8164fe03
[mp4] Add m4v major type support. r=jolin

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/c81d8164fe03

Comment 9

[Blake Wu [:bwu][:blakewu]]

it should be worth adding some test case.

Comment 10

[Ciprian Georgiu, Desktop QA]

I cannot reproduce this anymore with 55 beta 3 (20170619141703) on Mac OS X 10.11.6.

Instead, on Windows 10 x64, Windows 7 x64/86 and Ubuntu 16.04 x64 LTS this issue is still reproducible with 55 beta 3 (20170619141703). The following behaviors can be seen when the video file from comment 1 is loaded in Firefox:
 - Ubuntu: video is not displayed at all, only the video controls
 - Windows: video is not playing and only the first frame is shown as mentioned in comment 0 

Jean, what do you think about this?

Comment 11

[Jean-Yves Avenard [:jya]]

WFM on Win10 64bits and Ubuntu 17.04 (I have no doubt it would play on 16.04 too)

Comment 12

[Ciprian Georgiu, Desktop QA]

Attachment: video issue.gif

(In reply to Jean-Yves Avenard [:jya] from comment #11)
> WFM on Win10 64bits and Ubuntu 17.04 (I have no doubt it would play on 16.04
> too)

This seems very odd, because I've retested on 3 different machines (fresh profiles each time) with Windows 10 x64, Ubuntu 16.04 and the video still does not play on 55 beta 3. I attached a screencast with this issue, where I loaded the video from comment 1 in Firefox via drag and drop, I also assumed that it will play through a HTTP local server (python -m SimpleHttpServer) but it did not.

Do you have any idea what could be wrong here? Thanks!

Comment 13

[Jean-Yves Avenard [:jya]]

I've tried with 55 beta 4, on bother Ubuntu 17.04 and Windows 10. And it plays fine on both system using the link...

When played from the local file, it only shows the first frame... how puzzling.

Comment 14

[Jean-Yves Avenard [:jya]]

there's a similar behaviour with nightly, except that the first frame doesn't show at all.

Comment 15

[Jean-Yves Avenard [:jya]]

issue is with the rust demuxer...

it only detects the audio track. Setting media.rust.mp4parser to false works.

Comment 16

[Ciprian Georgiu, Desktop QA]

(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #10)
...
> 
> Instead, on Windows 10 x64, Windows 7 x64/86 and Ubuntu 16.04 x64 LTS this
> issue is still reproducible with 55 beta 3 (20170619141703). The following
> behaviors can be seen when the video file from comment 1 is loaded in
> Firefox:
>  - Ubuntu: video is not displayed at all, only the video controls
>  - Windows: video is not playing and only the first frame is shown as
> mentioned in comment 0 

Hi Benjamin,

I see that the issues mentioned above are fixed in bug 1374194 but only in Firefox 56. (I can confirm that are not repro anymore with latest Nightly 56.0a1, 2017-07-21)

Can you please let me know if the patch from bug 1374194 is going to be uplifted in 55 Beta too, or it will ride the trains? 

Thank you!

Comment 17

[Benjamin Smedberg]

Ciprian as the bug filer for this I don't know anything about uplifts plans: I think you need to ask the owner of the bugs.

Comment 18

[Ciprian Georgiu, Desktop QA]

Thanks!

Since this issue can still be reproduced on Beta with Windows/Ubuntu (see comment 13, comment 12) and the patch from bug 1374194 which fixed this is not going to be uplifted in FF 55 (per comment https://bugzilla.mozilla.org/show_bug.cgi?id=1374194#c13), I will change the status flag for 55 to affected, and let the qe+ to be verified in 56 Beta as well.