Closed Bug 1255760 Opened 8 years ago Closed 8 years ago

Problems with fragmented mp4 playback in recent versions of Firefox

Categories

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

44 Branch
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: ondrej.perutka, Assigned: jya)

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160211124446

Steps to reproduce:

We have a problem with playback of our fragmented mp4 streams in recent versions of Firefox. Everything worked just fine a few versions back and we have no problems with playing these streams in Chrome, VLC, ffplay and other players.

We have tried to debug it somehow. Unfortunately, we were unable to get any useful debug messages from Firefox.

Here you can generate a stream URL that you can use for testing:

http://www.provider.dev.angelcam.com/mp4

Note: Access to the stream URL is secured using an access token (it's part of the URL). The token is valid only for one hour. You can generate a new one simply by refreshing the page.


Actual results:

Only the first frame from the stream is displayed.


Expected results:

We expect it to play the whole stream :) .
In which version of Firefox did the stream use to work? I tested 42, 39, I see the 1st frame but the stream does't play.
Component: Untriaged → Audio/Video: Playback
Flags: needinfo?(ondrej.perutka)
Product: Firefox → Core
I have tested all versions from 38 to 43 (official Fedora packages on x86_64). Note that we don't use the video tag directly. We use Clappr:

<html>
  <head>
    <script type="text/javascript" src="http://cdn.clappr.io/latest/clappr.min.js"></script>
  </head>
  <body>
    <div id="player"></div>
    <script>
      var player = new Clappr.Player({source: "http://e3-eu2.angelcam.com/m2-na3/232/stream.mp4?token=...", parentId: "#player"});
    </script>
  </body>
</html>

It generates a code like this:

<video preload="metadata" src="http://e3-eu2.angelcam.com/m2-na3/232/stream.mp4?token=..." data-html5-video="">
  <source src="http://e3-eu2.angelcam.com/m2-na3/232/stream.mp4?token=..." type="video/mp4">
  <style class="clappr-style">[data-html5-video]{position:absolute;height:100%;width:100%;display:block}</style>
</video>

Anyway, here are the results of the testing:

38, 39, 40 - It works; however, it shows the first frame and then it takes ~15 seconds before the playback starts.
41 - Playback starts immediately after clicking on the play button.
42 - Playback starts immediately after clicking on the frame (the play button is not shown for some reason).
43 - This is the first version where our problems started.
Flags: needinfo?(ondrej.perutka)
On Win 7, none of these builds are able to start the playback of the stream.
OK, it works in other players, so I'd expect it to work in Firefox as well. Is there anything we can do to help you with resolving this issue? We haven't been able to get any debug info related to video playback/decoding from Firefox. Is there a way to get it? The video stream is muxed using Libav 9. We use regular mp4 muxer with disabled moov and custom fragmentation (on the edge of every frame).
jya: Can you take a look at this?

If this is a regression, we should fix it.
Flags: needinfo?(jyavenard)
Priority: -- → P1
Flags: needinfo?(jyavenard)
Assignee: nobody → jyavenard
Shouldn't it get fixed even if it is not a regression? As I mentioned earlier, our streams work in other browsers/players, so clearly I'd expect them to work in Firefox as well.
This fragmented MP4 is invalid.

here, the Sample Table box contains a single entry.

Per ISO/IEC 14496-12:2005 8.14:
"The sample table contains all the time and data indexing of the media samples in a track. Using the tables here, it is possible to locate samples in time, determine their type (e.g. I-frame or not), and determine their size, container, and offset into that container.
"

So quite clearly, it contains *ALL* time and data related to the media samples.
The Decoding Time to Sample Box (stts), Chunk Offset Box (stco), Sample To Chunk Box (stsc) all provides a table with ONE sample.

Now FFmpeg (As used by chrome) just ignore that sample table if it detects a moov. This just gets around what is ultimately an invalid file.

But as far as the moov is concerned, this video is made of a single frame and with a duration of 0 at that.

This is why you only see a single frame being displayed.

Being a fragmented MP4, it shouldn't have a sample count set in the moov:

From:
http://w3c.github.io/media-source/isobmff-byte-stream-format.html
"3. Initialization Segments"

"The user agent must run the append error algorithm with the decode error parameter set to true if any of the following conditions are met:

    1-A File Type Box contains a major_brand or compatible_brand that the user agent does not support.
    2-A box or field in the Movie Box is encountered that violates the requirements mandated by the major_brand or one of the compatible_brands in the File Type Box.
    3-The tracks in the Movie Box contain samples (i.e. the entry_count in the stts, stsc or stco boxes are not set to zero).
    4-A Movie Extends (mvex) box is not contained in the Movie (moov) box to indicate that Movie Fragments are to be expected.
"

So per 3, a fragmented MP4 *must* have entry_count set to 0.

Closing as Invalid.

You need to fix your moov.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
If we were to follow the spec to the letter, we should error when attempting to play this file.

Unfortunately, when attempting to play as a plain html video file, we can't tell this is a fragment mp4 at the time of check.
Thanks for the investigation, I'll try to fix it. However, we cannot affect contents of the mp4 atoms directly. As I've already mentioned, we use Libav 9 for creating our fragmented mp4 streams.
Libav9 is ancient. Just upgrade to ffmpeg 3.0.

You could also just pass the generated stream to the bento4 tools, and it would fix it for you
You need to log in before you can comment on or make changes to this bug.