Re: Fwd: Helix-client-dev Digest, Vol 54, Issue 11
Greg Wright <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
Mahmoud Hammoud wrote: > Hello Greg, > > I did cc the mailing list the last time I wrote you, should I expect > answers from other developers? (I have unfortunately never received any > feedback from mailing list members). Could you please give me some > insight on the questions in Topic 1 below (relating to client side rate > control) when you have some time? I really appreciate it. To anyone else > reading this, please be kind to post your valuable comments. I will respond to another email, but first, please keep your subject line consistent. Not many of us have time to respond to every thread on here and if we have responded to a thread we generally keep an eye out for the same subject line, if you keep changing them it is hard for us to follow the conversation. --greg. > > All the best, > > Mahmoud > > ---------- Forwarded message ---------- > From: **<[email protected] > <mailto:[email protected]>> > Date: Fri, Aug 1, 2008 at 5:25 AM > Subject: Helix-client-dev Digest, Vol 54, Issue 11 > To: [email protected] > <mailto:[email protected]> > > > Send Helix-client-dev mailing list submissions to > [email protected] > <mailto:[email protected]> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > or, via email, send a message with subject or body 'help' to > [email protected] > <mailto:[email protected]> > > You can reach the person managing the list at > [email protected] > <mailto:[email protected]> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Helix-client-dev digest..." > > > Today's Topics: > > 1. Re: Buffering in the Helix Client (Mahmoud Hammoud) > 2. Re: .mp4 progressive download using RTP (Milko Boic) > 3. hxclientkit question (Tran Hoang Thanh) > 4. RE: hxclientkit question (ljun) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 31 Jul 2008 13:39:46 +0200 > From: "Mahmoud Hammoud" <[email protected] > <mailto:[email protected]>> > Subject: [Helix-client-dev] Re: Buffering in the Helix Client > To: "Greg Wright" <[email protected] <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]> > Message-ID: > <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="iso-8859-1" > > **Dear Greg, > > I found your proposed solution to my problem very appealing, but could you > please elaborate a little more on that? I will formulate my questions in a > list so that you can quickly provide me with some brief remarks, and I > really appreciate you taking time off your very busy schedule to answer me: > > 1) How to know whether client side or server side rate control is being > used? > > 2) What modules contain the implementation of these rate control mechanisms? > (I'm guessing rateadaptinfo.cpp is one of the essential source files but I'm > sure there's more to it than that). That being said, is a rate adaptation > request (e.g. tell the server to send at a higher bit rate) done at the RTSP > level? Can you tell me which functions usually perform that? > > 3) When the server sends at a higher/lower bit-rate, how does that affect > the playback quality? Is that taken into consideration? From what I know a > client generally has a playout schedule which is a delayed version of the > encoding/sending curve at the transmitter. So I guess the client initially > starts playing at the original clip-rate (i.e. according to the initially > agreed upon playout schedule) and in my case tells the server at some > point to send at a higher bit-rate (because bad connection quality will be > encountered soon). What does the client do then, when its rate adaptation > request is "accepted", with respect to its playback rate? > > Thank you a lot, > > Mahmoud > > On Tue, Jul 29, 2008 at 7:33 PM, Greg Wright <[email protected] > <mailto:[email protected]>> wrote: > > > Mahmoud Hammoud wrote: > > > >> Dear Greg, > >> I am writing you directly because I didnt really get meaningful answers > >> the last time I tried the mailing list, and my problem is really > urgent, so > >> I appreciate your understanding and you taking time to answer me. I > am using > >> the hxclient_1_5_0_cayenne branch (Profile helix-client-all-defines, > >> SYSTEM_ID = win32-i386-vc6), and I am trying to implement a way of > >> controlling the amount of buffering to be done by the client based on > >> external measurements (independent of the state of the player, or the > >> congestion/connection quality it experiences). For example I would > like to > >> be able to pass a "prediction" (supposedly obtained from an outside > module > >> that interfaces with the Helix core) telling/forcing the core to > buffer data > >> for a certain amount of time (say because we will experience bad > connection > >> quality soon). After reading the "devdocs" related to buffering in > the Helix > >> client, and thoroughly examining the corresponding parts of the > code, some > >> of my issues remained unanswered and here is where I need your help: > >> 1) Rebuffering seems to be done only for audio streams (when > accelerated > >> delivery doesnt make up for the data shortage). Where does the > rebuffering > >> of video streams take place? Here I am making reference to > >> HXSource::ReportRebufferStatus which gets exclusively called by audio > >> renderes (so the else clause where DoRebuffer( ) is called for video > streams > >> is somehow never executed). > >> > > > > We never rebuffer due to video. The idea is that the audio playback, > > what the person is hearing at any given instant, is the master time > > line. It drives everything else. So, it is imperative that we never > > allow the audio to run dry or otherwise break up. This is why we > > rebuffer the audio stream. For video, it is not as important. We have > > chosen to go ahead and let the video drop frames (even back to showing > > only key frames) as long as we can keep the audio from breaking up. > > > > We could have equally well decided to rebuffer if we are unable to > > keep the video playing well. However, given the history of where > > and when the media engine was used, that is not a decision we made. > > > > It would not be hard to change this (see client/audiosvc/*) behavior > > and have rebuffering caused by video renderers as well. That would be > > a valid choice in a lot of scenarios I would guess; where video has > > to be shown with all frames or none at all. > > > > 2) When rebuffering is to be done for an audio stream, accelerated packet > >> delivery is stopped, and the chain DoRebufferIfNeeded( ) - > DoRebuffer( ) - > >> ReBuffer( ) - m_pBufferManager->Rebuffer(preroll increment). Is this > >> accurate? Does this mean that rebuffering consists of merely > incrementing > >> our preroll by a constant amount of time? Is there some actual > buffering of > >> the media packets that I am not seeing here? I appreciate it if you > would > >> point it out to me. > >> > > > > If we encounter a rebuffering event we assume that the connection is > > not that good and that rebuffering more data will help keep the > > amount of rebuffers down. So, that is why you see an increment there. > > This increment only goes up to some maximum value. It is easy to > > change how much, if any, of an increment you get. > > > > Rebuffering itself is just the act of pausing playback until we have > > satisfied all the pre-roll requirements of each renderer in the > > playback chain. This includes any *extra* we have added (above). > > > > 3) If a simple solution to my initial problem description comes to your > >> mind, please be kind to provide me with your valuable thoughts. > >> > > > > If you can somehow detect impending degradation of the connection > > ahead of time, then I would just look at accelerating delivery of > > the packets from the server. You can ask the server to send you > > data at just about any rate. We start off very fast (to fulfill > > the pre-roll as fast as we can) and then change it to just about > > the clip bit-rate. If the engine senses the data getting low it > > will tell the server to increase the rate. This applies only to > > client side rate control. If the connection is using server side > > rate control then you really can't do anything except maybe lie > > to the server about how much data you have. > > > > --greg. > > > > Adding helix-client-dev, please keep all discussion on a helix > > list. If you want you can always email and point me to a > > discussion, but I don't have that much time right now and emails > > directed only to me may not get answered. > > > > > > > > Best Regards, > >> Mahmoud Hammoud > >> > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080731/bea596c0/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 31 Jul 2008 13:01:15 -0700 > From: Milko Boic <[email protected] <mailto:[email protected]>> > Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP > To: "Shivaji Patil" <[email protected] > <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]> > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > Shivaji, > > Capture of standard RTP stream and its recording into a mp4 file format > would be accomplished via dtdriver framework. > The framework would use rtspfformat as the source. Some modifications to > this format would be needed to support .sdp files (extensions) to be able > to open RTP streams w/o any RTSP. > Modification to the existing renderer plugins would be needed to support > packet assembly w/o decoding. > mp4 filewriter would be used to write-out the file. > > Documents on mp4 file format are available from ISO and RTP from IETF. > dtdriver framework information is available in Helix Community at > https://datatype.helixcommunity.org/2005/devdocs/DTR-USR-DtdriveFramework.txt > . > > Please direct specific questions in regard what you would like to do to > [email protected] > <mailto:[email protected]>. > > Thanks, > Milko > > At 09:36 AM 7/31/2008, Shivaji Patil wrote: > >Hi, > > I am working on .mp4 file progressive download using RTP. Please > > proved me some documents or info if possible. > > > >Many Thanks > >-Shivaji > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 31 Jul 2008 19:37:00 -0700 (PDT) > From: Tran Hoang Thanh <[email protected] <mailto:[email protected]>> > Subject: [Helix-client-dev] hxclientkit question > To: Milko Boic <[email protected] <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]> > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=us-ascii > > Hi Milko, > > I am using Helix DNA for integrating it into Moblin. However, I got the > following issues when working with hxclientkit: > > 1. I have downloaded and followed instructions at > https://player.helixcommunity.org/2005/doc/hxclientkit/build-instructions.html#hxclientkit_Specifics > However, when building hxclientkit, I could not run "umake", my error > was: umake: command not found > Then, I still run make, everything went fine > > 2. I cd to test directory in order to test "main.cpp". At this point, I > could not run make clean, umake or make. The errors were as follows: > make: *** No rule to make target "clean". Stop > umake: command not found > make: *** No targets specified and no makefile found. Stop > > 3. I tested to build "main.cpp" (which is in test directory) by Eclipse. > I also included libhxclient.so.1.0. as a shared library for compilation. > However, when I built the code, I got the errors as follows: > > undefined reference to 'ClientPlayerClose' > undefined reference to 'ClientPlayerCreate' > undefined reference to 'ClientPlayerOpenUrl' > undefined reference to 'ClientPlayerPlay' > > Do you have any idea or advice for me? Anyway, thanks a lot for your time > > > > > Best regards, > > Tran Hoang Thanh > > > > --- On Fri, 8/1/08, Milko Boic <[email protected] <mailto:[email protected]>> > wrote: > > > From: Milko Boic <[email protected] <mailto:[email protected]>> > > Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP > > To: "Shivaji Patil" <[email protected] > <mailto:[email protected]>> > > Cc: [email protected] > <mailto:[email protected]> > > Date: Friday, August 1, 2008, 4:01 AM > > Shivaji, > > > > Capture of standard RTP stream and its recording into a mp4 > > file format > > would be accomplished via dtdriver framework. > > The framework would use rtspfformat as the source. Some > > modifications to > > this format would be needed to support .sdp files > > (extensions) to be able > > to open RTP streams w/o any RTSP. > > Modification to the existing renderer plugins would be > > needed to support > > packet assembly w/o decoding. > > mp4 filewriter would be used to write-out the file. > > > > Documents on mp4 file format are available from ISO and RTP > > from IETF. > > dtdriver framework information is available in Helix > > Community at > > > https://datatype.helixcommunity.org/2005/devdocs/DTR-USR-DtdriveFramework.txt > > . > > > > Please direct specific questions in regard what you would > > like to do to > > [email protected] > <mailto:[email protected]>. > > > > Thanks, > > Milko > > > > At 09:36 AM 7/31/2008, Shivaji Patil wrote: > > >Hi, > > > I am working on .mp4 file progressive download > > using RTP. Please > > > proved me some documents or info if possible. > > > > > >Many Thanks > > >-Shivaji > > > > > > > > _______________________________________________ > > Helix-client-dev mailing list > > [email protected] > <mailto:[email protected]> > > http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > > > > ------------------------------ > > Message: 4 > Date: Fri, 1 Aug 2008 11:22:38 +0800 > From: "ljun" <[email protected] <mailto:[email protected]>> > Subject: RE: [Helix-client-dev] hxclientkit question > To: [email protected] <mailto:[email protected]>, "'Milko Boic'" > <[email protected] <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]> > Message-ID: <003301c8f385$ddd98840$6401a8c0@reald867064935> > Content-Type: text/plain; charset="gb2312" > > Comments inline. > > Best regards > > Eric Li (Àî¾ü) > > www.realnetworks.com <http://www.realnetworks.com/> > > -----Original Message----- > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Tran > Hoang > Thanh > > Sent: Friday, August 01, 2008 10:37 AM > > To: Milko Boic > > Cc: [email protected] > <mailto:[email protected]> > > Subject: [Helix-client-dev] hxclientkit question > > > > Hi Milko, > > > > I am using Helix DNA for integrating it into Moblin. However, I got > the following issues when working with hxclientkit: > > > > 1. I have downloaded and followed instructions at > > > https://player.helixcommunity.org/2005/doc/hxclientkit/build-instructions.html#hxclientkit_Specifics > > However, when building hxclientkit, I could not run "umake", my error > was: umake: command not found > [Eric Li] You haven't setup helix build system yet. Have you installed > python? And make sure you've checked out the ribosome/build > and "ribosome/build/bin" is in your PATH variable. You can refer to this > page: > https://helixcommunity.org/developers/get_connected_to_cvs/quickstart > > Then, I still run make, everything went fine > > > > 2. I cd to test directory in order to test "main.cpp". At this point, > I could not run make clean, umake or make. The errors were > as > > follows: > > make: *** No rule to make target "clean". Stop > > umake: command not found > > make: *** No targets specified and no makefile found. Stop > [Eric Li] I suppose that you have not generated Makefile via umake > command, so you can't make. Set up Helix build system and run > umake firstly. > > > > 3. I tested to build "main.cpp" (which is in test directory) by > Eclipse. I also included libhxclient.so.1.0. as a shared library > for > > compilation. However, when I built the code, I got the errors as follows: > > > > undefined reference to 'ClientPlayerClose' > > undefined reference to 'ClientPlayerCreate' > > undefined reference to 'ClientPlayerOpenUrl' > > undefined reference to 'ClientPlayerPlay' > [Eric Li] Setup build system and then use make, after that see if these > errors still exist. > > > > Do you have any idea or advice for me? Anyway, thanks a lot for your time > > > > > > > > > > Best regards, > > > > Tran Hoang Thanh > > > > > > > > --- On Fri, 8/1/08, Milko Boic <[email protected] > <mailto:[email protected]>> wrote: > > > > > From: Milko Boic <[email protected] <mailto:[email protected]>> > > > Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP > > > To: "Shivaji Patil" <[email protected] > <mailto:[email protected]>> > > > Cc: [email protected] > <mailto:[email protected]> > > > Date: Friday, August 1, 2008, 4:01 AM > > > Shivaji, > > > > > > Capture of standard RTP stream and its recording into a mp4 > > > file format > > > would be accomplished via dtdriver framework. > > > The framework would use rtspfformat as the source. Some > > > modifications to > > > this format would be needed to support .sdp files > > > (extensions) to be able > > > to open RTP streams w/o any RTSP. > > > Modification to the existing renderer plugins would be > > > needed to support > > > packet assembly w/o decoding. > > > mp4 filewriter would be used to write-out the file. > > > > > > Documents on mp4 file format are available from ISO and RTP > > > from IETF. > > > dtdriver framework information is available in Helix > > > Community at > > > > https://datatype.helixcommunity.org/2005/devdocs/DTR-USR-DtdriveFramework.txt > > > . > > > > > > Please direct specific questions in regard what you would > > > like to do to > > > [email protected] > <mailto:[email protected]>. > > > > > > Thanks, > > > Milko > > > > > > At 09:36 AM 7/31/2008, Shivaji Patil wrote: > > > >Hi, > > > > I am working on .mp4 file progressive download > > > using RTP. Please > > > > proved me some documents or info if possible. > > > > > > > >Many Thanks > > > >-Shivaji > > > > > > > > > > > > _______________________________________________ > > > Helix-client-dev mailing list > > > [email protected] > <mailto:[email protected]> > > > http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > > > > _______________________________________________ > > Helix-client-dev mailing list > > [email protected] > <mailto:[email protected]> > > http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > > > > > ------------------------------ > > _______________________________________________ > Helix-client-dev mailing list > [email protected] > <mailto:[email protected]> > http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > > > End of Helix-client-dev Digest, Vol 54, Issue 11 > ************************************************ > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev