[AG-TECH] AccessGrid 3: What information is available
Andrew Rowley
Andrew.Rowley at manchester.ac.uk
Tue May 31 03:29:26 CDT 2005
Hi,
I have not experienced this so far; as I said, my H.261 encoder was slow
because I did not spend much time on it. I am not sure what version of JMF
this was - I am using the most recent which is 2.1.1e. As far as I can
tell, this uses a lot of native code so I imagine it uses DirectShow on
Windows for example.
In a quick experiment with my desktop webcam on my computer (3Ghz P4 with
512MB Ram), I ran vic and JMStudio (the built in JMF media tool)
transmitting my webcam with both set to 30fps and the highest bitrate and
using the H.263 codec (as this exists natively in both). vic transmitted at
just under 6fps most of the time and JMStudio transmitted at just over 6fps
(as reported in a receiving vic). I imagine that the codec is similar,
showing that in this case there was no obvious performance difference.
This is obviously not a very thorough experiment, but it does show that JMF
can as well as native code.
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 Osland, CD (Chris)
> Sent: 25 May 2005 11:29
> To: ag-tech at mcs.anl.gov
> Subject: RE: Re: [AG-TECH] AccessGrid 3: What information is available
>
> 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