Support for streamed fMP4?

[jaron....@ddvtech.com]

Hello everyone,

I'm a developer of media server software, and one of the live delivery methods we support is streamed fMP4.
To clarify in MSE-speak: this is a valid ISO BMFF initialization segment followed by multiple ISO BMFF media segments, all pseudostreamed as a single MP4 file.
This delivery method works beautifully practically everywhere, in practically any browser (even with scripting completely disabled) and on practically any device... except in Firefox.

Is there anything we can do server-side to make this delivery method work equally well in Firefox? (Or: how can I figure out why it isn't working as-is?) I can also provide a sample stream, if that would help.

My apologies if this is not the correct place to ask - in that case please point me in the right direction.

Thanks in advance,
Jaron Viëtor

[Ralph Giles]

Fragmented mp4 files generally play outside the MSE api, if that's
what you're asking. It's hard to say more about why your stream
doesn't work without an example. Can you share a url which illustrates
the problem? Off the top of my head it could be some difference in
recognized headers, lack of seek support, or a number of other things.

Is there a reason you can't use the MSE api to play your streams,
assuming they work there?

-r

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

[Jaron Viëtor]

Hello Ralph,

An example can be found here: http://patchy.ddvtech.com:8080/live.mp4
Opening that in any other browser than Firefox results in a playing stream,
while in Firefox it seems to load forever.

We can indeed use the MSE api, and are working on that angle now.
We'd prefer to have this playing without any client-side scripting, however.
This playback method is our fallback for when end-users have scripting
disabled in the browser, and it works as such in the other major browsers.
Having something more-or-less universally compatible to fall back on would
be great.

Any assistance you can provide to shed more light on this matter would be
most welcome! It is very well possible we're simply doing something wrong
and are unaware of it.

Thanks again,
Jaron

[Ralph Giles]

On Mon, Sep 26, 2016 at 10:48 AM, Jaron Viëtor <jaron....@ddvtech.com> wrote:

> An example can be found here: http://patchy.ddvtech.com:8080/live.mp4

Thanks. We certainly shouldn't hang on loading, but I think the file
is invalid. mp4info reports:

ReadAtom: "live.mp4": invalid atom size, extends outside parent atom -
skipping to end of "" "mdat" 598610 vs 598206

> Opening that in any other browser than Firefox results in a playing stream,
> while in Firefox it seems to load forever.

It plays for me in Chrome (and ffmpeg) and Edge, but not Safari or Quicktime.

-r

[Jaron Viëtor]

On Mon, Sep 26, 2016 at 9:21 PM, Ralph Giles <gi...@mozilla.com> wrote:

> Thanks. We certainly shouldn't hang on loading, but I think the file
> is invalid. mp4info reports:
>
> ReadAtom: "live.mp4": invalid atom size, extends outside parent atom -
> skipping to end of "" "mdat" 598610 vs 598206
>

That's odd, I'm getting this mp4info output from a download that I let run
for a few seconds:

Track Type Info
1 audio MPEG-4 AAC LC, 123.832 secs, 0 kbps, 1000 Hz
2 video H264 Baseline@3, 120.840 secs, 0 kbps, 854x480 @ 0.000000
fps

The invalid size for the mdat atom is probably caused by the file being
partially received - after all, mdat is a top-level atom and has no parent
(and the file has infinite length, so partial downloading is expected).
MP4Box also shows no errors on the file.

It plays for me in Chrome (and ffmpeg) and Edge, but not Safari or
> Quicktime.

Yes, same here. We don't really care about Safari/Quicktime because on
iOS/OSX we can already use HLS as native playback method (also, iOS seems
to disable video altogether when scripting is turned off - so that is a
lost case anyway).
I agree with you that something is likely not valid, but have no idea what
it could be. It doesn't seem to be something structural with the MP4 atoms,
at least. So it must be something more subtle...
Sadly, the only applications that refuse to play it have zero debug output
(as far as I can tell - if there is a way to get more output that I am
unaware of, please enlighten me!), making this really hard to track down.
I was hoping somebody might be able to provide some information on how to
figure out why Firefox specifically dislikes the stream.

Perhaps helpful: if I download a portion of the stream to disk and attempt
to play that in Firefox, it does play, but only for ~5 seconds despite ~2
minutes of data being available. As if only the first fragment is
considered or something like that.

Thanks again for your time!

- Jaron

[Cyril Concolato]

Hi Jaron,

FYI, MP4Client indeed does not play your stream (and does not report any
problem!!). I quickly checked. The HTTP response does not use
chunk-transfer encoding and does not contain the content-length header,
nor any IceCast or ShoutCast headers. I don't think that's correct and
this is probably why Firefox is not playing it too. We will fix
MP4Client, at least to warn about the problem, and probably to play it.

HTH,
Cyril

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

--
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/
@cconcolato

[jaron....@ddvtech.com]

Op dinsdag 27 september 2016 15:15:33 UTC+2 schreef Cyril Concolato:

> Hi Jaron,
>
> FYI, MP4Client indeed does not play your stream (and does not report any
> problem!!). I quickly checked. The HTTP response does not use
> chunk-transfer encoding and does not contain the content-length header,
> nor any IceCast or ShoutCast headers. I don't think that's correct and
> this is probably why Firefox is not playing it too. We will fix
> MP4Client, at least to warn about the problem, and probably to play it.
>
> HTH,
> Cyril

Hello Cyril,

True, we do not use chunked transfer encoding, nor do we set a content-length; but for server responses this is actually not required. See: https://tools.ietf.org/html/rfc2616#section-4.4
In this case, the server indicates end of response by closing the connection (which happens when the live stream ends, potentially never), which is both valid HTTP/1.1 and HTTP/1.0. :-)
(Also, icecast/shoutcast headers were never formally standardized in any document and are never mandatory, as far as I am aware - if I am wrong about this please let me know)

Thank you for thinking along though! I do appreciate it. And having MP4Client play it correctly would be a nice touch indeed. Extra ways to test are always a good thing.

Further suggestions or help (from anyone) would still be very welcome!

- Jaron

[jaron....@ddvtech.com]

A small update from my side.

I recently discovered a few more interesting points:
- If the transfer is interrupted (e.g. the server unexpectedly closes the connection mid-download/stream), playback of the so-far-downloaded segment starts, and works.
- If the first track is a video track, playback works as expected, even while still pseudostreaming. If the first track is an audio track, the behavior as described before still happens.

Do either of those ring a bell with anyone?

I'm currently writing a work-around that simply swaps around tracks to make the video track the first one in the pseudostreamed file, but would love to figure out what actually causes this problem in the first place, and tackle the issue at the root (if possible).

- Jaron