[MPlayer-users] Parsing whole Youtube mp4 file before playing?

wm4 nfxjfg at googlemail.com
Fri Jun 5 14:08:55 CEST 2015

On Fri, 5 Jun 2015 13:49:19 +0200
Rasz <citizenr at gmail.com> wrote:

> On 6/5/15, wm4 <nfxjfg at googlemail.com> wrote:
> > libavcodec. It's because the mp4 file is "fragmented". It works if you
> > disable indexing.
> "fragmented" was a good clue
> found http://stackoverflow.com/questions/18178405/mpeg-dash-and-fragmented-mp4
> now I get it, its like hosting a bunch of mp4 files glued ass to
> mouth, and mplayer insists on parsing every single one of them before
> decoding anything.

libavformat does. (Also I write libavcodec, but that was wrong. It's a
libavformat issue.)

These mp4s can most likely be read just fine without stepping through
the whole file by reading some (yet unsupported) index elements.

> I found a bug, or at least very undesirable result of the way mplayer
> handles streams like that currently.
> I tried VLC, it will also parse every single fragment, but VLC is
> "clever" about it, it only fetches header data, 8MB out of 56MB file,
> before it starts playing ("clever" in quotation marks because despite
> fetching only essential data its doing it very slowly).
> Mplayer on the other hand first fetches _whole_ file to parse
> individual fragments .. and then it fetches that very same data again
> while playing it, result is 112MB downloaded to watch 56MB stream.
> It seems libavcodec is not at fault here, VLC uses it and acts differently?

It might just be a difference in buffering.

> I would still love to know how YT players are able to seamlessly start
> playing without preloading anything :( Even better if there was a way
> of incorporating it into mplayer, or at the very least copy VLC
> "clever" method of only fetching essential (not that essential if YT
> flash player can live without it) metadata.

More information about the MPlayer-users mailing list