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

[Andrew A Rowley]

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
> >>
> >>
> >>
> > 
> > 
>