[AG-TECH] AccessGrid 3: What information is available

Osland, CD (Chris) C.D.Osland at rl.ac.uk
Wed May 25 05:29:13 CDT 2005


My only experience of JMF was that it dramatically reduced
performance compared with hand coded interfaces - most things were
about a factor of 3 slower.  In the AG context, if this is still
true, that could be a real bummer.

Cheers

Chris

____________________________________________________________________
Chris Osland                                               Office tel: +44 (0) 1235 446565
Digital Media and Access Grid                          Medialab tel: +44 (0) 1235 446459
BIT Department                                     Access Grid room tel: +44 (0) 1235 445666
e-mail:   C.D.Osland at rl.ac.uk                                       Fax: +44 (0) 1235 445597
CCLRC Rutherford Appleton Laboratory (Bldg. R18)
Chilton, DIDCOT, Oxon OX11 0QX, UK
[The contents of this email are confidential and are for the use of the intended recipient only.
If you are not the intended recipient do not take any action on it or show it to anyone else,
but return this email to the sender and delete your copy of it.]





> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov]On
> Behalf Of Andrew A Rowley
> Sent: 25 May 2005 08:40
> To: bcorrie at sfu.ca
> Cc: Andrew.Rowley at manchester.ac.uk; ssmith at vislab.usyd.edu.au;
> Rhys.Hawkins at anu.edu.au; barz at nchc.org.tw; ag-tech at mcs.anl.gov
> Subject: Re: Re: [AG-TECH] AccessGrid 3: What information is available
> 
> 
> Hi,
> 
> I am unsure of how much more work Sun is planning to 
> provide to the JMF.  From my experience with 
> ScreenStreamer, I found the current JMF very easy to use.  
> 
> As you say, one of the problems is with a lack of codecs.  
> However, Java does support the use of other native 
> libraries and so it should be relatively easy to import 
> any codecs used in vic into JMF with a little work, or to 
> use libraries such as ffmpeg for MPEG4 support (I think 
> JMF uses native libraries anyway, but this is all hidden 
> from the programmer).  Alternatively, writing codecs in 
> pure Java would be very nice - I have written a basic 
> H.261 encoder which is slow currently due to the small 
> amount of time I spent on it (the slowness is due to the 
> fact I wrote a quick and simple DCT algorithm).  I expect 
> most people will be afraid of Java being too slow, but 
> modern Java VMs can run easily as fast as native 
> equivalents.
> 
> The main thing that is good about the JMF is the way that 
> it handles the RTP/RTCP for you.  This means that the main 
> body of your proram can stay fairly static once it has 
> been developed.  If you want to add codecs, you just add 
> an option to your program to use your codec (as I did with 
> H.261) and it uses this instead of the built in ones.  
> File handling is similar to reading from a camera, so it 
> would be very easy to write something that takes an MPEG 
> and streams that in RTP.
> 
> I would recommend JMF as a good starting ground for 
> developing cross-platform media tools.  I will reiterate 
> that I have already done a lot of work towards this in 
> ScreenStreamer and anyone who wants to see the code for 
> this is more than welcome.
> 
> Andrew :)
> 
> > Hi Andrew,
> > 
> > Is JMF receiving much development as a Java toolkit. We 
> did some work a 
> > few years ago on a JMF based video transcoder. It has a 
> lot of potential 
> > in that regard because of its architecture. As you say, 
> you just plug in 
> > new codecs as they are developed.
> > 
> > What we found was that there was no much capability to 
> encode to very 
> > many formats, and therefore we could decode a number of 
> formats but we 
> > could only encode back to h261. Not the best for a 
> transcoder 8-)
> > 
> > I would be interested in hearing what the status is at 
> the moment. We 
> > haven't done any JMF work for a while.
> > 
> > Brian
> > 
> > 
> > Andrew Rowley wrote:
> > 
> > > Hi,
> > > 
> > > The ScreenStreamer code (http://www.memetic-
> vre.net/software/ScreenStreamer)
> > > at one point in the development cycle had some 
> features that would allow it
> > > to be a vic/rat replacement.  This is Java code using 
> Java Media Framework,
> > > so it is already platform independent.  If you have 
> used this, you will
> > > notice that the interface already looks a bit like 
> vic.  This has been
> > > slimmed down to only support screen sending, but it 
> would not take much work
> > > to add the video sending back in.  It also had some 
> support for audio
> > > transmission and reception so this would allow audio 
> and video from one
> > > client.
> > > 
> > >>From what I remember, the main problems were that 
> > > a) The H.261 encoder is a bit slow as I wrote this 
> from scratch and have not
> > > spent much time on it
> > > b) JMF doesn't include the AG audio codec so this 
> would need implementing.
> > > This should not be very hard given that AG audio is 
> uncompressed as far as I
> > > know.
> > > 
> > > JMF already has H.261 video decoding, and Java video 
> encoding and decoding
> > > for better quality than H.261.  The framework is quite 
> nice in that JMF
> > > handles most of the RTP things, and you can just plug 
> in new codecs as they
> > > are written.
> > > 
> > > Just a suggestion - if anyone wants the ScreenStreamer 
> code to look at, let
> > > me know and I will arrange access.
> > > 
> > > Andrew :)
> > > 
> > > ============================================
> > > Access Grid Support Centre,
> > > RSS Group,
> > > Manchester Computing,
> > > Kilburn Building,
> > > University of Manchester,
> > > Oxford Road,
> > > Manchester, 
> > > M13 9PL, 
> > > UK
> > > Tel: +44(0)161-275 0685
> > > Email: Andrew.Rowley at manchester.ac.uk 
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-
> tech at mcs.anl.gov] On
> > >>Behalf Of Steve Smith
> > >>Sent: 24 May 2005 09:15
> > >>To: Rhys Hawkins
> > >>Cc: barz at nchc.org.tw; ag-tech at mcs.anl.gov
> > >>Subject: Re: [AG-TECH] AccessGrid 3: What information 
> is available
> > >>
> > >>
> > >>>Agreed! Parts of VIC/RAT are worth reusing (eg 
> libcommon) but I think
> > >>>its time to get rid of the TCL/TK reliance. I think 
> there is enough
> > >>>people working in the area of video tools for the 
> AccessGrid to start
> > >>>a community development aimed a replacing VIC in the 
> AG.
> > >>
> > >>I agree with this in principle, but that will take 
> some time and while
> > >>that effort is taking place we need knock the worst of 
> the issues out of
> > >>current tools (redirecting your efforts to a new 
> implementation while
> > >>ignoring the existing is always disaster, Joel Spolsky 
> has written about
> > >>this extensively).
> > >>
> > >>In particular I think the following would be major 
> leaps forward in
> > >>usability:
> > >>
> > >>        * Being able to change the venue in Vic and 
> Rat without
> > >>        restarting them
> > >>        * Multiple video inputs to Vic (which would 
> remove the necessity
> > >>        of multi-machine nodes)
> > >>
> > >>Cheers,
> > >>Steve
> > >>
> > >>
> > >>
> > > 
> > > 
> > 
> 
> 
> 




More information about the ag-tech mailing list