Fwd: Helix-client-dev Digest, Vol 54, Issue 11

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.

All the best,

Mahmoud

---------- Forwarded message ----------
From: <[email protected]>
Date: Fri, Aug 1, 2008 at 5:25 AM
Subject: Helix-client-dev Digest, Vol 54, Issue 11
To: [email protected]


Send Helix-client-dev mailing list submissions to
       [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]

You can reach the person managing the list at
       [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]>
Subject: [Helix-client-dev] Re: Buffering in the Helix Client
To: "Greg Wright" <[email protected]>
Cc: [email protected]
Message-ID:
       <[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]> 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]>
Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP
To: "Shivaji Patil" <[email protected]>
Cc: [email protected]
Message-ID: <[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].

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]>
Subject: [Helix-client-dev] hxclientkit question
To: Milko Boic <[email protected]>
Cc: [email protected]
Message-ID: <[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]> wrote:

> From: Milko Boic <[email protected]>
> Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP
> To: "Shivaji Patil" <[email protected]>
> Cc: [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].
>
> 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]
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev



------------------------------

Message: 4
Date: Fri, 1 Aug 2008 11:22:38 +0800
From: "ljun" <[email protected]>
Subject: RE: [Helix-client-dev] hxclientkit question
To: [email protected], "'Milko Boic'" <[email protected]>
Cc: [email protected]
Message-ID: <003301c8f385$ddd98840$6401a8c0@reald867064935>
Content-Type: text/plain;       charset="gb2312"

Comments inline.

Best regards

Eric Li (Àî¾ü)

www.realnetworks.com
> -----Original Message-----
> From: [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]
> 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]> wrote:
>
> > From: Milko Boic <[email protected]>
> > Subject: [Helix-client-dev] Re: .mp4 progressive download using RTP
> > To: "Shivaji Patil" <[email protected]>
> > Cc: [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].
> >
> > 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]
> > 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




------------------------------

_______________________________________________
Helix-client-dev mailing list
[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