[gst-devel] Please, explain about PushSrc.

[Edward Hervey]

On Sun, 2010-11-28 at 23:48 -0800, wl2776 wrote:
> It is recommended that network sources, as ftpsrc should subclass from
> PushSrc.
> That is, if I understood, they always drive the pipeline.
> 
> Suppose, I have a gigabit network and play a movie from an FTP-server with
> my ftpsrc in the playbin2.
> If the movie bitrate is about 5Mb/s, then it can be downloaded much faster
> than the playbin2 plays it.
> 
> Who will tell the FTP server to pause transmission for a while, because our
> buffers are full?
> Or, will this end with the whole file stored in RAM? I'd like to avoid the
> latest case.

  For TCP based transmission, it'll be ... the point-to-point network
stack that will throttle the bandwidth.

  In the same way that when you download through your 512kb/s adsl
connection something from a server with Gb/s of bandwidth you will be
throttled by your connection speed. No, it's not filling up mystical
queues located on the internet, the server will be pushing out no faster
than the bottleneck in the point-to-point connection.

  So provided you have got limits on the various queues in your pipeline
(which is the default in playbin2), the moment the pushsrc queue is
blocked (waiting for data to be consumed downstream so it can get the
next packet from the socket), the TCP stack throughout the connection
(server to client) will make sure it doesn't push more data than the
available total bandwidth (in this case the bottleneck will be the speed
at which you're consuming).

  Warning : this doesn't apply for UDP which can't throttle the bandwith
alone due to lack of packet reception confirmation.

  So basically.... don't worry :)

   Edward

P.S. Yes, there are small queues at the kernel level, but those are too
small to care about.