[FFmpeg-devel] [RFC] RTP hint tracks in the mov muxer

[Martin Storsjö]

On Mon, 19 Apr 2010, Ronald S. Bultje wrote:

> On Mon, Apr 19, 2010 at 9:31 AM, Martin Storsj? <martin at martin.st> wrote:
> > Brief background: When serving an on-demand .mov/.3gp/.mp4 using some RTSP
> > servers (notably, darwin streaming server), the server itself isn't able
> > to do the RTP packetization, but relies on the files containing hints on
> > how to packetize it. In QuickTime apps, this can be done by checking an
> > "Enable streaming" box when exporting, or alternatively, the hint tracks
> > can be added with third party applications such as MP4Box/GPAC.
> >
> > These hint tracks are standardized in the ISO base media file format.
> 
> Can you briefly describe the content of these packets, how often they
> are transmitted, etc.?

Sure! Each packet (or sample in mov terms) contains one or more RTP 
packets, and every RTP packet generated from the streams are stored. But 
instead of storing all the payload data twice (once in the normal 
audio/video tracks and once in the hint tracks), the hint track data 
format allows references to the original samples. So for most RTP payload 
formats, you'll end up with an initial block with some immediate bytes for 
the payload header, with the rest of the packet being a reference to parts 
of the original packet. Or for audio RTP formats, you'd have one reference 
to each of the original audio frames that are bundled within the frame.

Here's a quick overview of this format: 
http://tools.ietf.org/html/draft-singer-rtp-qtfile-01#page-10

(The ISO 14496-12 standard is more up to date, I think, but this one is 
easier to link to.)

When I enabled RTP hinting, the "muxer overhead" went up from slightly 
less than 1% to around 5%, depending on what codecs I used. And of course, 
this feature shouldn't be enabled by default, so the only ones suffering 
from it would be the ones that actually need it. :-)

// Martin