[AG-TECH] High res video streams, in AG VIC session

[Christoph Willing]

On Sat, 2003-01-25 at 08:19, Lawrence A. Rowe wrote:
> "Osland, CD (Chris)" wrote:
> > 
> > Hi all,
> > 
> > We're interested in sending and receiving video streams, preferably
> > as part of a regular AG VIC session, that run at higher than the
> > AG default VIC resolution (388x288 or somesuch?).  We would be
> > interested in 640x480, 768x576 and 1024x768.
> > 
> > [BTW Some months ago one of the UK sites unknowingly switched to a
> > different resolution on the fly; this has the spectacular effect
> > of killing the display machines on all nodes in the VV.]
> ---
> This is a known bug in ag/uclvic.
> ---
> > 
> > 1.  Is anyone currently using higher resolution already with
> > whom we could test our ability to receive?  Is this using
> > a standard VIC or a modified one, either to send or to
> > receive?
> ---
> We have used RTPtv to generate high bitrate, high quality images (jpeg)
> that
> can be played by omvic.  We haven't tested it on P4's, but on older P3's
> you could pixel-double CIF images and the quality was better than
> expected. You can try to decode full-sized images but I doubt you can
> get 60 fields/second that is produced by RTPtv.  Of course, you can
> configure RTPtv to send different frame rates if you wanted to play with
> this. This won't work with ag/uclvic because of the large image problem
> mentioned above.  We had to fix it in omvic to handle the RTPtv streams.
> ---
> > 
> > 2.  Is anyone else interested in taking part in such experiments,
> > and if so, what is you main interest - live video, application
> > sharing, ...?  Also, what is you area of expertise?
> ---
> We'd be happy to send you RTPtv streams to experiment with if you want.
> ---
> > 
> > 3.  Has anyone a concise idea of the current state of VIC and
> > OpenMASH in this area?  I don't know what has already been
> > written or what remains to be done.
> ---
> One of the last things I hope we can finish before the end of this
> academic year is to complete an H.263 encoder/decoder that will produce
> reasonable quality images at tolerable bitrates.  The current omvic
> source tree has two relevant codecs: h.263+ and h.263.  the h.263+ code
> is the code from uclvic. I'm not sure it works - i am playing with it
> right now and it crashes both talking to another omvic and talking to
> uclvic.  still need to test it with agvic.  the h.263 codec pair is
> non-functional at the moment.  the h.263 encoder works but is very
> limited - just sends i-blocks for ever frame (i.e., jpeg-like images). 
> the h.263 decoder in the current source tree doesn't work, and from
> looking at the code, i'm not sure it ever worked.
> 
> Before being layed off, Lloyd Lim had partially completed an h.263
> decoder. I am checking that code in the OM source tree right now.  I've
> seen it decode some streams but it gets confused on some of the advanced
> coding options produced by the Polycom units.  I'm working with some
> ugrads to fix the large image problem (still happens with h.263+ and
> current h.263 code) and to improve the h.263 encoder.  I assume we'll
> fix bugs in the h.263 decoder as well.  And, depending on how things go,
> we'll add some more coding heuristics to improve the quality/bitrate. 
> Probably add some of the high payoff features from h.263+ and h.263++.
> 
> And FYI: we discovered that the uclrat/uclvic code does not support
> audio/video synchronization even though it was advertised as doing so. 
> I have another student working to re-implement the mbus commmands in
> omvic and to modify the synch algorithms to try to get synchronized
> streams to work. Having already done this in RTPtv, we know how hard it
> is to get this right while minimizing latency and guaranteeing 24-hour
> synch.  I doubt we'll get it to work as well as RTPtv, which still needs
> more work to adapt to varying network delays.
> 	Larry


We have a continuous RTPtv stream running for demo/testing purposes
between our two labs. Hopefully you could see it too at
233.2.178.9/17038 (video only). It can be viewed with OpenMash vic (not
at full resolution though) or RTPtv's own vclient program and I'd be
interested in how it performs long distance.

chris


-- 
Chris Willing                      Telephone   (61-2) 9351 3005
VisLab, A28                        Facsimile   (61-2) 9351 1880
University of Sydney
NSW 2006 Australia                http://www.vislab.usyd.edu.au