[FFmpeg-devel] ffmpeg mp4 muxer - support for HTTP progressive downloads

[Tomas Härdin]

On Wed, 2010-05-05 at 21:52 +0100, declan harrison wrote:
> Hi
> 
> I was hoping to be able to use the ffmpeg API to encode the MP4 container
> format on-the-fly over a network streams so as it could be viewed
> progressively over HTTP.
> 
> However the MP4 muxer in ffmpeg does not allow you to write the output out
> to a network stream.  I had planned to look at amending the muxer to acheive
> this.  However the more I have looked into this issue the more I wonder if
> indeed it is possible to achieve this for this container format.
> 
> For example ffmpeg has a version of the command line utility
> "qt-faststart.c" that shifts the location of the "moov" atom from the end to
> near the begiining of the file thus enabling the mp4 file to be played
> progressively over HTTP.  The implication that I infer from this is that it
> isnt possible to do this on one in the muxer or they would have done it.
> 
> Is this a limitation of the MP4 container format? Is it because the location
> of certain metadata require absolute offsets of atom locations in files
> rather than relative offsets?
> 
> Is it possible to achieve on-the-fly encoding of MP4 container over a
> network stream?  If not are the only alternatives to use one of the
> streaming protocols e.g. RTSP or RTMP.
> 
> Is the ffmpeg-devel the correct mailing list for this question?
> 
> Declan

In short: yes, it's a limit of the format. Getting around it is tricky
to say the least.

I've been experimenting with a moov-before-mdat patch which we have been
using successfully for a few weeks. It does still rely on being able to
seek though, but only requires an estimate for the number of packets per
stream.

In order to be able to stream everything the size of every packet needs
to be known in advance. There are two reasons for this: the moov tag
needs to be figured out before the packets arrive, which in turn
requires knowing the packet sizes and offsets (the latter of which can
be calculated). Secondly the size of the mdat tag also needs to be known
in advance, which is simply the sum of the size of each packet. It might
be possible to write zero for the size of the mdat tag to signal "all
data from here until EOF is mdat", but I'm not sure.

What this means is that in general you can't perform any transcoding
when writing such a file - only remuxing. In that case one could extract
the required metadata in advance, which is something I've been
experimenting with (external essence via the dref tag).

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100506/3e8db17a/attachment.pgp>