[Live-devel] embedded use of live classes?

Ross Finlayson finlayson at live.com
Sun Feb 8 15:35:33 PST 2004


>we are investigating the live.com media classes for usage in an embedded
>environment; XScale running Linux.

Leon,

The "LIVE.COM Streaming Media" code was specifically intended for use 
within embedded systems, and several organizations have already used it in 
embedded environments.

>- Floating point operations are very expensive, and having many of them
>in the signal path (i.e. recurring often and repeatedly) is bad for
>performance.

Floating point is used in a few places in the code, but not 
extensively.  It's currently used mostly for some statistics gathering each 
time a network packet is sent or received.  (Some of these uses of floating 
point could perhaps be replaced with fixed point if necessary.)  So, even 
if the host environment uses software for floating point emulation, there 
is unlikely to be a significant performance impact.

>- Limited memory and performance available.
>- No user that can solve errors or read error messages.

To run the LIVE.COM code within a custom environment (such as an embedded 
system), people typically develop their own subclasses of the 
"UsageEnvironment" and "TaskScheduler" abstract base classes (see 
"UsageEnvironment/include/UsageEnvironment.hh").  Note that the released 
source code includes one particular implementation of these classes - the 
"BasicUsageEnvironment" library.  This uses the Unix (or Windows) console 
for I/O, and so allows you to develop applications that you can run on 
conventional OSs - e.g., for prototyping and debugging.  But then, by using 
your own custom subclasses of "UsageEnvironment" and "TaskScheduler" (i.e., 
instead of "BasicUsageEnvironment" and "BasicTaskaScheduler"), the same 
code will run on your custom (e.g., embedded) environment.

>Depending on our findings, we will either develop our own minimal
>implementation, or use live.com classes and change them to our needs. In
>either case, we would like to work in an open way; (L)GPL.

In most cases you should not need to make many changes to the LIVE.COM code 
proper.  Instead, the code was designed so that - in most cases - new 
functionality can be added by subclassing.  Then, you can link your new 
custom code with the existing libraries (and you will not be under any 
obligation to release the source code to your new custom code).

However, if find that you need to make changes/improvements to the LIVE.COM 
code proper - and these changes are of general applicability - then please 
post them to this mailing list, so they can be included in future releases.

>Is live.com available as an CVS project, or will it be in the future?

No - for a code base as small as this, CVS tends to be more trouble than 
it's worth, especially since 99% of the time that people want to use CVS, 
it's just to download the latest version of the complete source 
code.  (Note that you can easily see what's changed in each new release by 
running "diff -r".)


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>



More information about the live-devel mailing list