[FFmpeg-devel] rtp streaming x264+audio issues (and some ideas to fix them)

[Michael Niedermayer]

On Tue, Feb 09, 2010 at 08:47:56AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Feb 9, 2010, at 8:14 AM, Luca Abeni <lucabe72 at email.it> wrote:
>> If you want to avoid large buffering in the client, the buffering
>> must be in the streamer. This can be done at muxer level, by using
>> something like Martin's RTSP muxer (it does not implement buffering
>> right now, but this feature can be implemented later), or at
>> application level (by using avstreamer instead of ffmpeg).
>
> Doesn't lavf do that for you when using av_write_frame_interleaved()?

that is only correct when each frame is encoded to the same number of bits
(much much stricter than cbr and very low quality, noone does this)

If your streams are CBR/VBR and transmitted over a channel of constant maximum
rate then your "streamer" must before high bitrate parts transmit data ahead
of time to fill the decoders buffers (which are mandatory anyway).
I dont know how RT*P handles these things or if its just undefined random
"guess and do what works 98% of the time"
but in mpeg there is an exact buffer model 
and the muxer is completely aware of how much the decoder has
in its buffers and how large these buffers are.
That way the muxer also knows exactly how much it can transmit ahead saftely
(a decoder can of course have arbitrary larger buffers or use a different
 model as long as its less strict)

You should maybe read our mpeg PS muxer code or some text related to high
quality VBR mpeg muxing or VBV.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100210/a9429c9f/attachment.pgp>