incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
Date Fri, 12 Aug 2011 09:32:28 GMT
okay,

well those specs from the 08.11.2011 :) Really cutting edge information:
http://www.whatwg.org/specs/web-apps/current-work/webrtc.html

However there is hardly any information about some really (and already
industry standard features):
- Echo Cancellation
- Buffering and behaviour in low bandwidth scenarios (usually the audio is
the first thing that start stuttering, modern Real-Time Protocols throw
Events or at least *claim* they could detect bandwidth issues and throw an
appropriate event). Some protocols even do some kind of *auto-measuring* of
bandwidth and *dynamically* adjust the streaming to the currently
- Usage of UDP for the media streaming (sorry but no modern protocol does
use UDP these days? We are not in the 60's where people had 50% loss of
packets, we use fiber channel with GigaFlops and they want us to use UDP for
that?)
- They say hardly anything about the *Peer-2-Peer* concept or how they want
to fix the Firewall problem. Sure you can leave that problem for the
industry, but you should not wonder if there is hardly then a Streaming
Server that is Open Source. I mean the server side part or who you manage
those streams is what makes the conferencing system work well. The specs do
not say much about it. So is their expectation that we will all end up using
proprietary software and networks to do the Conferencing?
- There is ZERO 100% Peer-2-Peer Video-Conferencing Solution out there ...
Everybody, even Skype uses a solution as backup where they proxy all media
data on a central server that does then the necessary routing of the
packets, so a backup system for the clients that can't connect via
Peer2Peer. The Specs say nothing about such possibilities.
- Codecs. Sure the Codecs used for the Audio/Video is an implementation
question so I can understand that you do not sth. like that into Specs ...
but practically its THE ESSENTIAL question.... Well with Google OpenSourcing
vp8 there might be an option for the video part. But also I doubt that vp8
can handle HD Video-Conferencing. Speex might be a Codec solution for Audio.
But Video-Conferencing is not only doing Webcam sharing, ScreenSharing is an
integral part of Conferencing, vp8 is Open Source but its no ScreenSharing
Codec, ScreenSharing Codecs work different from usual codecs. The specs say
nothing about the possibility to send screen captures in real-time. There
are of course already such Codecs like the SHA1 that is used in Flash.

So it might be possible if people put a lot of effort into it to do sth with
those spec but it seems to me that existing technologies are already better
then what those specs define.

Sebastian

2011/8/12 Scott Wilson <scott.bradley.wilson@gmail.com>

>
> On 12 Aug 2011, at 08:22, seba.wagner@gmail.com wrote:
>
> > Yes,
> >
> > the Java Servlet Spec 3.0 also contains methods for push mechanisms. We
> > could already use similar technologies for pushing data packets around.
> >
> > However there is zero support for *real* streaming in the JavaScript
> world.
> > RTMP is not just about pushing some messages around, it is about
> streaming,
> > buffering ... and there is no equivalent for doing that in HTML5. So you
> > will hardly have the chance to build a web-conferencing with 100%
> JavaScript
> > and no external plugins.
> >
>
> Take a look at WebRTC:
>
> http://www.webrtc.org/
> http://www.w3.org/2011/04/webrtc/
>
> > The only at least acceptable solution might be using a Java-Applet/JNLP
> to
> > do the necessary multimedia part, that way you have at least full control
> > about it and are not forced to use a "black-box" like Adobe Flash or
> > Silverlight and still people don't need to install anything. However
> > implementing a cross-platform Java-Applet/Webstart-App that accesses the
> > Webcam/Microphone on any device is also not that trivial. Once the so
> > produced stream reaches the server you might be able that users can use
> the
> > HTML5-video tag to watch it.
> >
> > Sebastian
> >
> > 2011/8/11 Kalle Korhonen <kalle.o.korhonen@gmail.com>
> >
> >> 2011/8/11 seba.wagner@gmail.com <seba.wagner@gmail.com>:
> >>> I have updated the Proposal to be more clear on the external
> dependencies
> >>> and possibilities to move away from them:
> >>>
> >>
> http://wiki.apache.org/incubator/OpenmeetingsProposal#External_Dependencies
> >>
> >> From the sidelines, WebSockets would seem like a strong contender to
> >> replace RTMP. GlassFish's Atmosphere is under CDDL (which is allowed
> >> as appropriately labeled).
> >>
> >> Kalle
> >>
> >>
> >>> 2011/8/11 Jim Jagielski <jim@jagunet.com>
> >>>
> >>>> I've signed up for Mentor, in case we go ahead...
> >>>> On Jul 29, 2011, at 5:46 AM, dsh wrote:
> >>>>
> >>>>> Sebastian and Alexei,
> >>>>>
> >>>>> your are welcome! Btw, here is my +1
> >>>>>
> >>>>> On Fri, Jul 29, 2011 at 9:47 AM, Alexei Fedotov
> >>>>> <alexei.fedotov@gmail.com> wrote:
> >>>>>> Daniel,
> >>>>>> Thank you for an excellent report!
> >>>>>>
> >>>>>> --
> >>>>>> With best regards / с наилучшими пожеланиями,
> >>>>>> Alexei Fedotov / Алексей Федотов,
> >>>>>> http://dataved.ru/
> >>>>>> +7 916 562 8095
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jul 28, 2011 at 10:20 PM, dsh <
> daniel.haischt@googlemail.com
> >>>
> >>>> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> please find my feedback below:
> >>>>>>>
> >>>>>>> OS X Lion:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 5.0.1 and Adobe Flash Player 10.3
> >>>>>>> ** Safari 5.1 and Adobe Flash Player 10.3
> >>>>>>> * Observations:
> >>>>>>> ** Openmeetings did not work with Firefox/Safari if using
a
> >> webcam/mic
> >>>>>>> cause on the adobe flash player settings dialog it was not
possible
> >> to
> >>>>>>> click allow nor deny
> >>>>>>> ** In Safari clicking the share/record screen button N times
did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> OS X Snow Leopard:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 5.0.1 and Adobe Flash Player 10.3
> >>>>>>> ** Safari 5.1 and Adobe Flash Player 10.3
> >>>>>>> * Observations:
> >>>>>>> ** Openmeetings did not work with Firefox cause the initial
screen
> >> did
> >>>>>>> not load after signing up
> >>>>>>> ** In Safari clicking the share/record screen button N times
did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> Windows 7 Ultimate:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 4.0.1 and Adobe Flash Player 10.3
> >>>>>>> ** Firefox 5.0.1 and Adobe Flash Player 10.3
> >>>>>>> ** Safari 5.1 and Adobe Flash Player 10.3
> >>>>>>> * Observations:
> >>>>>>> ** In Firefox clicking the share/record screen button N
times did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** In Safari signing up did open a new window instead of
opening a
> >> new
> >>>>>>> tab which is different to Firefox"s behaviour (maybe this
can be
> >>>>>>> changed in the Safari prefs)
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> Fedora Core 15 Gnome Edition:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 4.0.1 and Adobe Flash Player 11
> >>>>>>> * Observations:
> >>>>>>> * I had to download the JNLP file and execute it using javaws
on
> the
> >>>>>>> command line. Did expect it would be run more seamlessly
cause the
> >>>>>>> IcedTea-Web plug-in is installed
> >>>>>>> ** In Firefox clicking the share/record screen button N
times did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> Fedora Core 15 KDE Edition:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 5.0 and Adobe Flash Player 11
> >>>>>>> * Observations:
> >>>>>>> * The JNLP app was started using IcedTea-Web on the fly.
So I guess
> >> on
> >>>>>>> Fedora Core Gnome Edition one would need to manually setup
some
> mime
> >>>>>>> types etc. in firefox to recognize JNLP files accordingly
> >>>>>>> ** In Firefox clicking the share/record screen button N
times did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> Ubuntu 11.04 (Natty):
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 5.0 and Adobe Flash Player 10.3
> >>>>>>> * Observations:
> >>>>>>> * The JNLP app was started using IcedTea-Web on the fly.
So I guess
> >> on
> >>>>>>> Fedora Core Gnome Edition one would need to manually setup
some
> mime
> >>>>>>> types etc. in firefox to recognize JNLP files accordingly
> >>>>>>> ** In Firefox clicking the share/record screen button N
times did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** pressing the share/record screen button did not lead
to an
> >>>>>>> immediate screen sharing session. Maybe you could provide
some
> >>>>>>> indication that the screen sharing session is being initialized
to
> >>>>>>> prevent clicking the share/record screen button multiple
times.
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>>
> >>>>>>> Debian 6.0.1:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Iceweasl 3.5.16 and Adobe Flash Player 10.1
> >>>>>>> * Observations:
> >>>>>>> ** After signing up the application did not load. I suppose
this is
> >>>>>>> due to using Gnash that comes together with Debian (I could
read
> the
> >>>>>>> autoconnect message but the progressbar did not appear).
Installing
> >>>>>>> the official Adobe Flash 11 for 64bit systems player fixed
this.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** On some Linux distributions (including Debian) the web
browser
> >>>>>>> window was resized after clicking sign-up. This might be
annoying
> to
> >>>>>>> some users.
> >>>>>>> ** Pressing the allow button on the flash player prefs pane
caused
> >>>>>>> Iceweasle to crash (this did happen after upgrading to the
official
> >>>>>>> adobe flash player)
> >>>>>>>
> >>>>>>> Openindiana Build 148:
> >>>>>>>
> >>>>>>> * tested with:
> >>>>>>> ** Firefox 3.6.8 and Adobe Flash Player 10.3
> >>>>>>> * Observations:
> >>>>>>> * The JNLP app was started using JavaWS on the fly. So I
guess on
> >>>>>>> Fedora Core Gnome Edition one would need to manually setup
some
> mime
> >>>>>>> types etc. in firefox to recognize JNLP files accordingly
> >>>>>>> ** In Firefox clicking the share/record screen button N
times did
> >> open
> >>>>>>> the screen sharing app N times (maybe you want to check
whether an
> >>>>>>> instance of the app is already running)
> >>>>>>> ** I understand if sharing screens everybody has control
over your
> >>>>>>> screen. you may consider adding a view only mode too.
> >>>>>>> ** you might check while signing up whether popup blockers
are
> >> active.
> >>>>>>> if yes you could prompt the user to disable popup blockers
first
> >>>>>>> before signing in.
> >>>>>>> ** pressing the share/record screen button opens a new,
blank
> window
> >>>>>>> just to download the JNLP app. maybe you want to change
that to not
> >>>>>>> open a separate window that needs to be closed after starting
the
> >> JNLP
> >>>>>>> app
> >>>>>>> ** pressing the share/record screen button did not lead
to an
> >>>>>>> immediate screen sharing session. Maybe you could provide
some
> >>>>>>> indication that the screen sharing session is being initialized
to
> >>>>>>> prevent clicking the share/record screen button multiple
times.
> >>>>>>> ** It looks like after stopping screen sharing the shared
screen
> >> still
> >>>>>>> remains on each participants screen. Maybe it would make
sense to
> >>>>>>> provide a message to each participant that the host stopped
sharing
> >>>>>>> its screen.
> >>>>>>> ** On some operating systems (including Openindiana) the
web
> browser
> >>>>>>> window was resized after clicking sign-up. This might be
annoying
> to
> >>>>>>> some users.
> >>>>>>>
> >>>>>>> PCBSD 9 Isotope Edition (KDE 4.6.3 Desktop):
> >>>>>>>
> >>>>>>> ** Firefox 4.0.1 and Linux Adobe Flash Player 10
> >>>>>>> * Observations:
> >>>>>>> * Gave up in the end because the flash play didn't work
accordingly
> >>>>>>> and installing Java is a real PITA. Guess even if it's called
> PCBSD,
> >>>>>>> it's not a real end user (aka desktop) system because it
heavily
> >>>>>>> depends on the FreeBSD system.
> >>>>>>>
> >>>>>>> Overall observation:
> >>>>>>>
> >>>>>>> The only thing which is introducing some issues on certain
> platforms
> >>>>>>> is Java/Flash as a plug-in on certain platforms cause they
are not
> >>>>>>> treated as 1st class citizen of the operating systems. For
instance
> >> on
> >>>>>>> OS X Lion Java has been removed and must be installed first
prior
> to
> >>>>>>> be able to use Java-based apps. Linux seems to be exposing
some
> >>>>>>> difficulties with both Flash and Java (i.e. webstart).
> >>>>>>>
> >>>>>>> So maybe working on the above identified Java/Flash issues
could be
> >>>>>>> one objective for the incubation phase.
> >>>>>>>
> >>>>>>> If I would have a free wish I'd like to see OpenMeetings
supporting
> >>>>>>> the capability to join an Asterisk phone conference call.
That way
> I
> >>>>>>> could be using real phones I am using at home connected
to an
> >> Askozia
> >>>>>>> PBX for instance to have conference calls using OpenMeetings.
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>> Daniel
> >>>>>>>
> >>>>>>> On Tue, Oct 27, 2009 at 12:22 PM, Sebastian Wagner
> >>>>>>> <seba.wagner@gmail.com> wrote:
> >>>>>>>> hi,
> >>>>>>>>
> >>>>>>>> we would like to propose Openmeetings project to join
the
> >> incubator.
> >>>>>>>>
> >>>>>>>> Full Proposal:
> >>>>>>>> http://wiki.apache.org/incubator/OpenmeetingsProposal
> >>>>>>>>
> >>>>>>>> Quick summary:
> >>>>>>>> OpenMeetings is Web Conferencing application that fits
into
> >>>> educational or
> >>>>>>>> business sector. You can make conference sessions in
different
> >>>> room-types
> >>>>>>>> with up to 100 peoples in a Room. It contains all main
features of
> >> Web
> >>>>>>>> Conferencing: Audio/Video, Whiteboard, Screen Sharing,
Chat and
> >>>> Moderation
> >>>>>>>> System. It is translated into more then 20 languages
and its a
> >> basic
> >>>> goal of
> >>>>>>>> OpenMeetings to be easy to embed into existing environments.
It
> >>>> already uses
> >>>>>>>> many of Apache Technologies like Tomcat, Mina, Velocity,
Commons,
> >> ...
> >>>>>>>>
> >>>>>>>> You may find all existing documents and further material
on the
> >>>> GoogleCode
> >>>>>>>> pages: http://code.google.com/p/openmeetings/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> We appreciate any feedback and comments on the proposal.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> sebastian wagner
> >>>>>>>> --
> >>>>>>>> Sebastian Wagner
> >>>>>>>> http://www.webbase-design.de
> >>>>>>>> http://openmeetings.googlecode.com
> >>>>>>>> http://www.laszlo-forum.de
> >>>>>>>> seba.wagner@gmail.com
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Sebastian Wagner
> >>> http://www.webbase-design.de
> >>> http://openmeetings.googlecode.com
> >>> http://www.wagner-sebastian.com
> >>> seba.wagner@gmail.com
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Sebastian Wagner
> > http://www.webbase-design.de
> > http://openmeetings.googlecode.com
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message