[FFmpeg-devel] [RFC] RTP hint tracks in the mov muxer
Tue Apr 20 08:48:31 CEST 2010
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:
(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. :-)
More information about the ffmpeg-devel