Quantcast

Please, explain about PushSrc.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Please, explain about PushSrc.

wl2776
Administrator
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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.


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Loading...