html5 player pauses at startup of web page, MP4 movie clip, since FF 35, Chrome works OK




2 years ago
a year ago


(Reporter: clackey3, Unassigned)



48 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)





2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Firefox 35, and newer versions, the HTML-5 player fails on startup of my web-ready brief MP4 streaming movie clips.  Symptoms are pauses and restarts until more data is buffered.
Google Chrome has no prolems at all.

Recent versions (since 45) have gotten much worse.

My clips for determining  which version introduced the problem are here:

First failure is found in Firefox-setup 35 and newer.
Firefox-setup 34.0b4 fails
Firefox-setup 34.0.5 works okay. (??why)

Firefox versions back to Firefox Version 31 works fine. I did not test any prior releases.
I am sure bug 1112683 is similar, but it states audio. It fails with same FF version 35

Actual results:

Video pauses quickly after it starts playing, pause, start agian... recursive untill it get buffered.  Longer clips take about 20 seconds to get buffered, than it play okay. Page refrash plays as it should have the first time.

Expected results:

An Older Firefox version worked correclty and matched performance of Google Chrome.


2 years ago
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Comment 1

2 years ago
Firefox Release (I tested) 31 and 33 work correctly.  The startep graphic "frame" does not display in newer releases (u 20 47, now current).  See Screen capture:
OS: Unspecified → Windows 7
Priority: -- → P3
Hardware: Unspecified → x86_64
Version: 47 Branch → 34 Branch

Comment 2

2 years ago
As I switched through various Firefox releases, I never installed Flash.
I assume that the flash plugin was not involved with my test results.
With Quicktime and VLC uninstalled, WMP is the only player on the machine.

Clicking on a LOCAL mp4, Firefox 47 launches and it works great!

Considering that Microsoft has chosen to avoid HTML5 video, and instead, uses WMP, I have to conclude that the pauses at mp4 startup of my web server (Server: Apache/2.4.12) MP4 video clip is a Firefox hosting environment that fails starting with FF Release 34.
(Google Chrome still works for me)

Comment 3

2 years ago
I changed the url to show the folder with many of my clips.  Current experience with Firefox 48... it sometimes works on some of the clips.  Chrome always works.

As of this moment, the original sample movie that failed... is working with FF, but yesterday it did not!  Chrome did work.

Several in the list are working, many are not... at startup, they do... pause-go, pause-go for several seconds, then run correctly.  Refresh always works, but kill Firefox, and repeat the test... same ones fail... but one day they will work. I repeat... Chrome works.  

My being a dedicated Firefox bigot, and having converted many peers and family, it is embarrassing to put a note on my web page to use Chrome if experience pauses.

Raw clips from the camera behave the same as clips processed through my editor (Cyberlink PowerDirector 13).

Comment 4

2 years ago
In your media list, which MP4 file shows the buffering issue?

I tested myself this file online and locally:
There is a playback stop after 3 sec, but I can reproduce it with Firefox, WMP and VLC, so I assume it's a video recording issue.

Any other file with the issue only in Firefox?

Comment 5

2 years ago
Sorry... that is not a pause.  With my editor, I pause the movie clip, then Capture a screen shot, and insert it for 1 sec (I can choose duration), and you experience a 1 second display of it. It is an editor built-in feature.

I am a VLC bigot and never have any issues with that.  My clips come from Sony Action Cam, three different models (version upgrades).  I don't know how or what to diagnose when I have 100% success with VLC locally and Chrome with streaming.  _Why does Firefox 33 always work?_ FF V34 fails.  If I can solve the issue with an editor, it might be helpful to know that and it would be a clue as to what is the problem...

Another confusion with me is the FF 48 sometime works, even with the original deer jumping video I referenced first.  What is Google Chrome doing different. It can't (?) be an html-5 issue.

Comment 6

2 years ago
Correction:  FF 33 does NOT play correctly It simply is not streaming! The test file is small and downloads relatively quickly.

I created a new test clip with no editor features (subtitles).
It is in the same folder as the former 'deer' clip,
and has the same FF 48 streaming pause behavior as former test file.
Chrome plays/streams it fine from the internet.

Firefox plays it correctly from local file.

New information:
I have several movies that usually... Firefox streams correctly;
Sample, is 7 minute movie: (notice different folder from above) "pause" close to the beginning ( 00:12 )where I inserted a 1 sec toddler screenshot.

This is another one that usually streams instantly, but does occasionally get the startup pauses. (2 minutes)

They have been clipped, subtitles added, and more.

After several good tests, I have occasionally experienced the streaming startup pauses that I am not sure it's the same issue, but ?



2 years ago
Component: Audio/Video: Playback → Activity Streams: General
Product: Core → Firefox
Hardware: x86_64 → x86
Version: 34 Branch → 48 Branch


2 years ago
Component: Activity Streams: General → Audio/Video: Playback
Product: Firefox → Core

Comment 7

2 years ago
(In reply to from comment #6)
> Correction:  FF 33 does NOT play correctly It simply is not streaming! The
> test file is small and downloads relatively quickly.
> I created a new test clip with no editor features (subtitles).
> It is in the same folder as the former 'deer' clip,
> and has the same FF 48 streaming pause behavior as former test file.

Could your provide directly the link of the MP4 video instead of the folder, please.

Comment 8

2 years ago
This is the url for the original Failing video:

Comment 9

2 years ago
I think I know what Chrome is doing.
Disclaimer, I do NOT know anything about the frames control structure in movies!
My conclusion is information regarding a tool explaining some of it's function.
I used tool AVS Video Remaker to remove "stuff?" (frames?) from the video preceding the first "Key Frame". It cut 0.9 seconds!
The result:


Comment 10

2 years ago
It sounds like more a buffering issue, maybe due to low network bandwidth. After the video has been completely loaded, the replay is fine, no playback pause.

Comment 11

2 years ago
This is a Firefox PLAYER issue, well, the player needs the movie to be "cleaned up" before it tries to play it... much like Youtube and Vimeo do their own processing of uploaded videos.  Apparently so does Chrome.

There exists a tool (Smart Cutter) that has a lot of elaboration regarding splitting video without regard to the Keyframes.

One keyframe every second in 30fps produces a true framerate of 29.97 becaue the keyfram has extra data in it.

The movies I split/edit with Cyberlink PowerDirector are the ones that have (Firefox Player, only) startup issues when streaming from a server. Firefox playerworks great on the same file, locally.

Cyberlink support lost interest quickly when I informed them that my test link examples which I provided, have to be opened with Firefox to  show the problem.

Using Firefox, Youtube player has no issue, same with VIMEO, but they re-process all uploads, so that's not a good test example. 

Chrome works fine. Microsoft browsers do not play the Streaming game at all. They pass it to their player.

All of my raw movies, from 4 different cameras, work correctly on Firefox streaming startup. Only when the product of a split within a keyframe's "managed block of frames..." is used to start the new movie clip.  

I can "fix it" with an editor/tool that saves it's output starting with a valid keyframe. I am using "AVS Video Remaker".

My guess is that the Google Chrome Player starts only with a valid keyframe and it's subsequent managed frames. Orphaned frames preceding that keyframe are ignored, or something more sophisticated.

I have three test movies online.
One is the original 20 second video that fails with Firefox.

One is link to the video after I trimmed off the leading orphaned frames.

Additional video, my system showing how the failure looks to me.

Comment 12

2 years ago
(In reply to from comment #11)
> One is the original 20 second video that fails with Firefox.

I'm not able to reproduce the isue with this video. Despite the pause due to the buffering of the video during the 1st playback (probably due to the bandwidth of your server), it replays fine.
And no issue when the video is played locally on my machine in Firefox or another media player.

IMHO you are just seeing buffering during video data loading.

Comment 13

2 years ago
It sure would be helpful if I could receive some elaboration explaining how buffering issues occur only with Firefox, never with Chrome. 

...and I can permanently solve the "buffering problem" with my "repair action" involving the clip's first keyframe.

Firefox show buffering bar under the Play position, and buffering is always well ahead of play positon Some sessions, buffering is much faster than others, but a failed video or good makes no difference.

But I have others testers consistently reproduce it in 4 states coast-to-coast:
 Hunington Beach California, Columbus Indiana, Rochester New York, and Raleigh North Carolina?

I can observe in Firefox, the buffering is proceeding ahead of the current playing position! It is not a buffering problem, else it would not always work after I 'fix' them.

I have two domains on two hosting providers; GODADDY and HOSTGATOR:

Once in a great while it almost works (only one pause).  ...and Local files never fail.

I have another internet folder with many failing clips and have indeed fixed them with the same tool (remove 1st keyframe).

I am on 50 Mbps service that tests out at 54 Mbps concurrent WHILE PLAYING a failing movie clip..

Chrome works 100% of the time.
    probably uses a different codec (maybe proprietary).

I can fix EVERY failing clip with the procedure I stated which deletes the orphaned first frames that used to be children of the first keyframe..

The two other editors I have do not create failing clips... but do have issues... which is why I normally have quit using them.
All  that may mean: they are using a different codec (performs the compression tasks and keyframes (rate) ).


Comment 14

2 years ago
Another editor (NCH Software; Videopad) usually has the same streaming issue at startup.
This is the test file created with Videopad:



Comment 15

2 years ago
I  consistently work around the issue by processing the final edited video with "AVS Video Remaker" to remove the orphaned frames at the beginning of the movie. That process ensures that the video begins with a valid key frame. I found an H.264 informative (aged) discussion regarding key frame intervals at this url:
I still do not possess enough detail knowledge to understand why this works. How / why does Chrome and other players work? What are they doing?
Keywords: html5

Comment 16

2 years ago
Jean-Yves, could you check this issue and if it's not a bug in the Firefox decoder, explain to the reporter how to encode properly his MP4s for online usage. Thank you.
Flags: needinfo?(jyavenard)
Firefox will pause playback once it has nothing left to play, either because the video is finished, or because it has run out of buffered data.

If it has stalled due to the file being slow to download, it will wait until it has once again buffered enough data and calculated it can play without interruption.

Here I see that it takes a while for the video to start. There are two reasons for this:
1- The server bandwidth is low.
2- The moov (the MP4 metadata) is located at the end of the file, so in effect the video must be downloaded in its entirety for playback to start. I don't know how you create those videos, but they aren't web optimised. You could use a tool like ffmpeg to remux the file so that the moov box is located at the beginning. Use the -movflags faststart option when remuxing. You'll find that it starts much quicker that way.

With all those videos, I saw that playback started, then paused while it was rebuffering and then it resumed once again.
I got the exact same behaviour with Chrome, with the exception that Chrome resumed quicker once it has stalled (but it paused one more time than Firefox)..

One thing chrome did better is that when reloading the video, playback started instantly and there was no interruption. While firefox rebuffered everything once again, and is very slow.

JW, any opinion on the matter? why is it that reloading the video is always slow, and why is startup so slow (chrome starts much quicker)
It sounds like the content is never cached.
	currentTime: 0 readyState: 2
	Quality: 100% (total:6 dropped:0 corrupted:0)
	Buffered ranges: [(0.015158, 0.181992)(0.215358, 0.248725)]
	Internal Data:
	audio decoder: apple CoreMedia decoder
	audio frames decoded: 38
	audio state: ni=1 no=1 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:38 out:38 qs=0 pending:0 waiting:0 sid:4294967295
	video decoder: apple software VT decoder
	hardware video decoding: disabled
	video frames decoded: 1 (skipped:0)
	video state: ni=0 no=1 ie=1 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:6 out:1 qs=5 pending:0 waiting:0 sid:4294967295
Flags: needinfo?(jyavenard) → needinfo?(jwwang)

Comment 18

2 years ago
Thanks for the comments.  I should have mentioned this.
I have confirmed the "Web Optimized" indeed helps the problem on the small clips.  
It doesn't make much sense with a1 GB file of which I have several

I do not think it is useful to this discussion since I don't have to optimize for other browser or player services.

Indeed there are late evenings and weekends where it seems nothing works, even the ones I fixed. The buffering bar still advances rapidly, but play does not happen for a long wait.
But CHROME still works.

Sorry Chrome isn't working as well for your testing as it has been for me and my family, coast to coast. Your testing is very much appreciated! (more coming soon)
(In reply to from comment #18)
> Thanks for the comments.  I should have mentioned this.
> I have confirmed the "Web Optimized" indeed helps the problem on the small
> clips.  
> It doesn't make much sense with a1 GB file of which I have several

Oh it will... and even more so than small videos.

To play a non "web optimized" video, the player must seek to the end. Seeking via http is an extremely slow and heavy operation. Once it has seeked to the end to find the metadata, it then has to seek again at the beginning to start playing.
That alone would typically add about 4s to the time it takes for playback to start.

> I do not think it is useful to this discussion since I don't have to optimize for other browser or player services.

I think you're wrong there, it's called web optimized for a reason. Having to seek at the end and back is something every player will have to do.
even using ffplay to play, it takes over 10s for playback to start here, that's for a 5s video!

I agree that Firefox waits too long to start, we can probably lower the threshold... I guess it's then a matter to decide on what is best: waiting longer and then have continuous playback, or don't wait but stall multiple times during playback.

Comment 20

2 years ago
Since I thought I have a workaround that solves the FF issue on startup, I have published several clips that are working for me... until I have run into another show-stopper.  I was writing up the text for this new bug... when the latest update here interrupted me.
I think it's is related only because Chrome has not exhibited the failure yet.

I've published a 9 minute clip for VIMEO. After VIMEO has processed it.  (It is 1/3 file size of the Full HD movie I uploaded! (?)
    I downloaded it and am working / testing it in my testing environment.
    I wanted to eliminate the consideration that I am the creator of the problem,
    so I am using a know, good file created elsewhere.

It does not fail like my failing previous clips, (I expected that)
... but it does have a brief startup hesitation, not an issue.

My newly identified (Streaming) problem DOES exist in the VIMEO processed file (with Firefox, only).

It abruptly ends the playing at random, various places, but is very infrequent.  Sometimes (seldom) it makes it through the entire 9 minutes.
Notice: The problem is only with Streaming, not my local machine.

I am still testing recursively with Chrome. So far, no failures(6 passes).

Comment 21

2 years ago
First fail was 8:04 into 9 minute movie.
...and one at 56 seconds.
Stops are at random locations, stops "like at the end" of normal movie.
    The frame which is displayed is the last frame played, (not at the end)
    but "current play indicator" went to the end of the track, and it displays the location to be at the end of the movie, (equivalent of the length indicator)

    One "click" on the window and movie starts over.

This is streaming, not local play.

Should this be a separate bug?
(In reply to from comment #21)
> Observations:
> First fail was 8:04 into 9 minute movie.
> ...and one at 56 seconds.
> Stops are at random locations, stops "like at the end" of normal movie.
>     The frame which is displayed is the last frame played, (not at the end)
>     but "current play indicator" went to the end of the track, and it
> displays the location to be at the end of the movie, (equivalent of the
> length indicator)
>     One "click" on the window and movie starts over.

sorry, I don't fully understand what you're saying here.

We have a skip to next keyframe logic, where if you machine is too slow to keep A/V sync, it will attempt to skip video playback to the next keyframe, if there are none it could be jumping to the end of the file. This is to ensure that audio plays continuously without stopping. Audio playback always have priority over the video.

Chrome just pause when the machine is too slow instead.

This is not a bug, it's a desired behaviour (and similar to how the flash video player works)

Comment 23

2 years ago
My workstation: Windows-7
Intel i-5-4460 CPU @ 3.20 GHZ; RAM 8GB 64-Bit
2 TB HDD, 2GB RAM drive; Firefox profile on the Ram Drive.
%TEMP% on the Ram drive.

The sudden stop is like it branched to the end. Audio stopped. ...but the "last end frame" is not displayed. 
The Play indicater parked at the end, and shows 09:07; and the movie duration indicator shows 09:07.
The display shows the frame where it branched.  I find that location by playing the local file and finding that timeline location using VLC.
The VIMEO file has keyframes at 3 seconds.  The source file I uploaded to VIMEO, keyframes at 1 sec. (Recorded at 30 FPS). Both have the problem.

9 full length streaming plays on Chrome, no failures at all.
(In reply to Jean-Yves Avenard [:jya] from comment #17)
> JW, any opinion on the matter? why is it that reloading the video is always
> slow, and why is startup so slow (chrome starts much quicker)
> It sounds like the content is never cached.
LoadResource() looks up the table and tried to clone the MediaResource when possible. The cloned MediaResource will share the same data in MediaCache with its original and save us time/bandwidth from downloading the whole file again from the network.
However, InitializeDecoderForChannel() doesn't do so. This is something we need to fix.
Flags: needinfo?(jwwang)

Comment 25

2 years ago
Raw Helmet Cam (mp4) movies convert to faststart with ffmpeg quite well.

After I edit the Helmet Cam movie file, the published mp4 clips cannot stream well..
the moov atom seems to be 'missing'.

When I use ffmpeg to make my clips to be 'faststart', I get an error on every clip I want to convert.

Before I edited any working raw camera mp4 file, ffmpeg faststart finds the moov atom and produces this telltale usefull clue:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from (filename) :

After the file has been edited, apparently the moov atom can't be found.
The 'input #0....' message is missing.

We have the telltale RED message as the indicator:
"Output file #0 does not contain any stream"

Since my edited clips get pre-processed by VIMEO and Youtube, now I know why they have to do it.

Google owns Youtube, and that may be helpful in making the Chrome browser better with this issue.

I hope this info is useful.
What arguments did you pass to ffmpeg?

Comment 27

2 years ago
ffmpeg MAH00107_3.mp4 -movflags faststart output.mp4
You need to set which tracks to use!

Add -codec copy, or to manually select the tracks: -c:v copy -c:a copy etc... see ffmpeg documentation for more details.

Comment 29

2 years ago
(sheepish grin)
Thanks for saving my life.
Little things mean a lot!

Comment 30

2 years ago
Now that I am partially trained better om ffmpeg! (thanks),
New test for you.
Chrome works.
Firefox fails on 3 of my 5 conversions.
  (moving the moov atom to the beginning of the file)

This is 11 seconds.
The ffmpeg log:
Important Note:
  Firefox fails in this windows-7, and 2 Windows 10.

  Firefox works on Windows-7, Firefox version 31 ESR. I reported this exception early in this long-winded  adventure.

Comment 31

2 years ago
Regarding raw, edited clips that have not utilized moving the moov atom to the start,
Similar to Chrome, Windows-10, the new Edge browser  plays the clip just fine...

Edge is not quite as quick as Chrome, but it is quite acceptable.

Comment 32

2 years ago
I am experiencing a pause at the start of my web-ready clips updated with ffmpeg. When I open the mp4 movie with Firefox, I get the pause. Chrome does not usually). 

I found a 'solution' learning how properly to embed the video into my web page and setting the width and height.  If the height is left for default, you may get the pause. I wonder if Chrome is dong some pre-processing on the video attributes.
more likely because you've played them before in Chrome and so the video is cached.
Firefox doesn't cache some content and as such will reload the content, hence the pause

Comment 34

2 years ago
Is this a related problem? It  the jerkiness I first experienced in this bug-report.

Run it on Chrome, and on Firefox. It is a 4-page auto-run step through the images.
I is different in stepping from image 4, back to (1), it does not just wrap. Is scrolls backward to image (1).

It waits about a minute to start unless you get busy with the mouse.
After a while, it stops.

If you move the mouse to left /and right margins, it responds.
I am unable to determine if the speed is different with Chrome.

No mater which action I trigger, it is not nice.

Chrome is not always perfect, but it is always nice.

Comment 35

2 years ago
Firefox work-around 
(not needed with Chrome about 90% of the time... sensitive to various mp4 videos)

When I avoid the raw video link, and put it into a <Video> tag, and provide window and type attributes, the video works as designed.

Comment 36

a year ago
This has gotten worse and not recently.  Status now, Firefox player is totally not unusable for my MP4 movies. It has to buffer a lot of it first.  Chrome works great.  VIMEO and You tube players work.

My movies stare quickly, but within a second or so, start buffering.  I hate leaning on Chrome so much.
Format Factory makes it work okay, but if Chrome can do it, why not the Firefox player. Format Factory is not a solution.

Comment 37

a year ago
After several days of discussion in,, topic:
 "What else can I do? Firefox Player is not up to Chrome, Vimeo and YouTube"
evidence is strong that I am not the only one (I use 2 Windows 7, and one Windows 10).

Using same Sony camera as before.

Very early in this thread, I posted comment that this problem first showed up in FF Version 34.

Chrome is always very reliable in playing my movies hosted on my GODADDY hosted domain. I have an upscale (costs more) shared domain.  I did the upgrade in response to this problem. It did not help. Firefox (FF 54)still has what looks like a buffering problem, but the discussion caused me to ponder this perspective, and inquiry...

Your comment regarding "bit rate" is a new area of interest to me.

When I download my video after it has been processed by (Youtube and/or VIMEO) it is a much  smaller file, and works with a slightly diminished video clarity.  No one but me can see that.

Format Factory also produces a file even smaller than does VIMEO and Youtube... with similar, minimal quality impact. My movie clips are on VIMEO or processed with Format Factory. I hate having to do that in order to keep using Firefox.

Just Guessing...
is changing bit-rate what Chrome is doing?
Inline processing diminishing bit rate?
    That has to make the frame smaller, and quicker to download to the user.  In the STREAMING environment, that seems like a useful trick.

The other possibility is interlace.  Chrome is doing something!   ...but that should be a developer issue, not mine.

Test link, movie is autoplay... after it buffers a long time. (Chrome plays instantly)

The June 26 movie:

You need to log in before you can comment on or make changes to this bug.