15 Apr
2009
15 Apr
'09
2:10 a.m.
Maybe I am hammering he pleasure of contradiction but streaming in
java servlets definitely is possible and done. The best example I know
of is red5:
http://osflash.org/red5
which is the backbone, among others, of DimDim, one of the
teleconferencing software.
In general, however, I am rather a fan of Darwin Streaming Server,
open-source C++, but I have almost done no programming with it. The
best documentation I found for it is at soundscreen.com.
Storage at xwiki side definitely needs a fix before videos can be made
attachment but that doesn't seem like an impossible mission. Re-
encoding for streaming maybe is the hardest.
paul
Le 14-avr.-09 à 22:18, Niels Mayer a écrit :
On Sat, Apr 11, 2009 at 10:20 PM, Asiri Rathnayake
<
asiri.rathnayake(a)gmail.com> wrote:
I was thinking of a usecase where users can play
an attachment for an
example.
I'm pretty new to streaming content, but to enable streaming of
attachments
(audio, video) we would have to store them on files instead in
database
entries right? and then may be we can use JMF (
http://java.sun.com/products/java-media/jmf/index.jsp) for streaming.
If you're playing back an Xwiki attachment as streaming media, there's
plenty of problems because the entire stack is not designed for
streaming...
On the server-end, things are limited not by Xwiki itself, but by
the use of
Java and Servlets, which ends up being incredibly heavy-weight for
streaming
large data files. The issue with large-files and streaming media (e.g.
video) is that the "download" happens over a very long period of time;
streaming playback by definition means you're not downloading entire
files
before play-back; instead, you use a small buffer and hope that
network can
keep the buffer filled while the data plays back at a slow "real-time"
data-rate.
Even if xwiki's db access could be made "incremental" or "paged",
with
multiple users streaming simultaneously, a java/servlet based system
requires huge amounts of overhead per connection. It's easy to run
out of
memory, or max-threads. The worst part about this architecture, as
opposed
to more traditional practices in C/C++ using
select()<http://en.wikipedia.org/wiki/Select_%28Unix%29>and
nonblocking
I/O<http://en.wikipedia.org/wiki/Non-blocking_I/O#Select.28.2Fpoll.29_lo…
,
is that most of those threads are
basically doing *nothing* most of
the
time, and when they are, they are sending out packet of data and
then going
back to sleep... Of course, the servlet spec allows streaming, and
there are
implementations of servlet-streaming that are quite straightforward to
implement, but may have performance/overhead issues anyways in real-
use,
e.g.:
http://www.longtailvideo.com/support/forum/Modules/14410/Servlet-Streaming
IMHO, the leading implementations are still in C/C++ -- just find
one that's
active, mature, and widely used, treat it as a black box, and use
whatever
combination of arcane configuration commands needed to get it
integrated:* *The
most interesting option for Xwiki integration is
mod_h264_streaming<http://h264.code-shop.com/trac/>since it would run
in Apache and many already "front" their Xwiki with
apache and mod_jk. (This option might provide and easier
authentication&access-control integration w/ Xwiki). Some other
standalone
implementations include: Darwin Streaming Server by
Apple<http://developer.apple.com/darwin/projects/streaming/>g/>,
ViTooKi <http://vitooki.sourceforge.net/>,
Catra<http://www.catrasoftware.it/Streaming/
CatraStreamingPlatform.htm>.
Those might do the job better for managing a site full of streaming
servers, but may be harder to integrate.
I haven't looked at JMF solution for streaming.... nor do I see
anything
about it that would make the task easier or the issues I mentioned
go away.
Please let us know what you find out regarding JMF's performance and
integration capabilities!
Niels
http://nielsmayer.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs