Re: Reminder: Issue 11

Dear Mahmoud,

In Cayenne 1.5, the packet pulling is done in 
RTSPClientProtocol::UDPResponseHelper::EventPending in 
protocol/rtsp/rtspclnt.cpp. This function extracts the packet then 
forwards it to the appropriate tranport layer (see 
RTSPClientProtocol::ReadFromDone).

The A/V socket are setup in RTSPClientProtocol::CreateUDPSockets.

Regards,
David

Mahmoud Hammoud wrote:
> Dear Greg,
> 
> Thanks a lot for your comments. But I was already aware of all these 
> concepts. Is it some kind of convention that detailed references to the 
> code are avoided within the mailing lists? I would really like it if 
> someone could point me to where in the code does this "pulling" of the 
> packets from the network layer takes place for example. Again, your help 
> is very appreciated.
> 
> Thank you in advance,
> 
> Mahmoud
> 
> On Mon, Aug 11, 2008 at 7:38 PM, Greg Wright <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Mahmoud Hammoud wrote:
> 
>         Hi All,
> 
>         I posted some questions related to packet reception by the
>         client sockets,
>         Jyotsana preferred that someone else take a shot at those. Your
>         contributions are DEARLY APPRECIATED.
> 
>         1) How many levels of buffering is there in the client? That is,
>         we know
>         that the packets first received by the network interface
>         (whether UDP or
>         TCP) are first accumulated within calls to HandleRead( ) in a
>         structure of
>         type HXSocketData; then, "read" events issued by the client core
>         result in
>         the packets being read from this initial buffer within calls to
>         ReadFrom(...,...) (is this accurate? What is the basis for
>         issuing such
>         events?) What happens next? I mean arent the streams contained
>         in the media
>         clip then buffered in different places, for the "just-in-time"
>         delivery to
>         take place?
> 
> 
>     Just some brief comments...
> 
>     After the core (hxcleng.cpp) reads the packets(events) from the
>     network layer (jitter
>     buffer it is sometimes called) the packets are then sent to each
>     renderer
>     in some amount of time before they are needed. This amount of time
>     is roughly
>     the pre-roll of the clip. The renderers then take the packets and
>     de-packetize
>     them into input frames for the decoders, which output decoded frames.
> 
> 
>     Basically, the core *pulls* packets from the network side of the media
>     framework and *pushes* them on the other side (renderers) in a
>     just-in-time
>     fashion.
> 
>     I assume you have read:
>     https://client.helixcommunity.org/2006/devdocs/buffering
> 
> 
> 
> 
>         2) I'm finding this a little confusing: on one hand, the UDP
>         sockets for the
>         different streams involved in a media session are created with
>         RTSPClientProtocol::InitSockets( ) (which in turn also calls
>         CreateUDPSockets(..)) and on the other hand the actual
>         reading/reception of
>         the packets from the network interface seems to take place in
>         HXThreadedSocket where the code looks relatively "low-level".
>         Could you
>         please give me some hints on how these 2 different modules
>         relate to one
>         another? Just a small summary about how the packets are received and
>         the "event-driven" playout that then takes place would do..
> 
> 
>     Does the above help with how packets are received?
> 
>     Again, the engine read packets from the network layer. In the network
>     layer we are pulling packets off of the sockets. At that layer we are
>     also asking for re-sends of lost, late or out-of-order packets. The
>     Engine pulls packets out of the network layer as needed and pushed them
>     into the renderers ahead of the presentation time.
> 
>     --greg.
> 
> 
> 
>         Best Regards,
> 
>         Mahmoud
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Helix-client-dev mailing list
> [email protected]
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev


_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev