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

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>>> 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

Ok, it can be done in the RTSP muxer, then ;-)


>> 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

Sorry, I was thinking about real-time encoding/streaming from a live
source. In this case, to perform bandwidth smoothing a streamer needs
to buffer some frames before sending them (so that it can be able to
send the high bitrate parts of the stream in advance).
A "low latency" encoder/streamer, on the other hand, will try to send
frames as soon as the are ready (in the assumption that there is enough
network bandwidth for streaming them without delays - this happens when
you stream on a local network).


> take our mpeg-ps muxer
> -> remove the buffering code, the demuxer/decoder will fail due to
> buffer overflows and underflows
[...]

I know... In my understanding, this is due to violation of the
buffering constraints that are mandated by the MPEG PS or TS
standard (if I remember well).
AFAIR, RTP does not say anything about buffers.

But I do agree that having some (configurable) buffering code in
the muxer is a good idea (and is needed in many situations, for
especially when streaming from files).


				Luca