Re: Reminder: Issue 11
"Mahmoud Hammoud" <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
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]> 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