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

Michael Niedermayer michaelni
Thu Feb 11 17:30:32 CET 2010


On Thu, Feb 11, 2010 at 08:35:41AM +0100, Luca Abeni wrote:
> Hi Michael,
>
> Michael Niedermayer wrote:
> [...]
>>> 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).
>
> Yes, I agree with this. This kind of "bandwidth smoothing" should be
> implemented (either at application level or in the RTSP muxer). But I

doing it at application level is unrealistic


> believe it should be configurable/optional, because if the network
> provides enough bandwidth (for example, when streaming over a local
> ethernet) this mechanism is useless and only increases the delay.

Iam not sure why you think delay would increase or even how you define
delay exactly
but

take our mpeg-ps muxer
-> remove the buffering code, the demuxer/decoder will fail due to
buffer overflows and underflows -> the decoder will need much larger
buffers and larger delay to compensate this (and it no longer knows
how large because the stream is no longer compliant so it has to
conservativly overestimate)

or look at it from the other side
a decoder/demuxer that receives a stream that it knows can be decoded
correctly with 0.5sec buffering can use 0.5 + (what it estimates it needs
for variable network latency)
OTOH a decoder/demuxer that receives a stream with unknown buffering
requirements needs (what it estimates the streams inherent bitrate
variation needs at the available network bandwidth) + 
(what it estimates it needs for variable network latency)
thats larger OR it estimated to low and could stalls playback OR
the 0.5 was incorrect and the stream actually has lower buffering
requirements.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20100211/f2c8fb18/attachment.pgp>



More information about the ffmpeg-devel mailing list