Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Feb 1997 00:27:56 -0800
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        Don Yuniskis <dgy@rtd.com>
Cc:        multimedia@freebsd.org
Subject:   Re: broadcast video 
Message-ID:  <199702120827.AAA28321@rah.star-gate.com>
In-Reply-To: Your message of "Tue, 11 Feb 1997 23:02:10 MST." <199702120602.XAA06072@seagull.rtd.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

h.261 is okay what you really want if you can get your hands on
is h.263 or h.323 which incorporates audio, video and control 
protocol.


----
From: Sassan Pejhan <sassan@Sarnoff.COM>
Date: Tue, 11 Feb 1997 16:43:38 GMT
To: hasty@rah.star-gate.com
Subject: Re: MPEG Support In MBONE Tools
> >From The Desk Of jcole@precept.com :
> > Also am curious if H263 video will likely be added as a supported video type 
> > to vic anytime soon?
> 
> Is there a publicly available H263 codec? My understanding is that H263
> is a propieratory format which if used in a public domain tool one
> may have to pay royalties. The same goes for G.763 .
>

You may want to check out Telenor's site:

http://www.fou.telenor.no/brukere/DVC/h263_software/

-----

On a fast network lets say 1mbit or more you can get 20 to 30 frames
per second with h.261 using 352x288 frames. You will need a fast cpu 
P166 or higher. It helps to have fast memory such as SDRAM for
video datacompression and in the win95/winnt MMX instruction set.
Well, the MMX is more of an issue of native compiler support
rather than OS .

In an embedded system you  may be able to get away with ultra
fast video capture by not having to go thru the PCI bus.
There are other hardware issues such a Trimedia chipset with 
2 billion instructions/sec vs a PC specially for video data
compression. 

So yes, the mbone audio/video stuff is real if you have the
bandwith. With h323 that is h.263 video codec plus G.723
low bandwith or more reasonable data rate requirements is
a reality. For instance, it is possible to send a qcif size
picture at 30 frames per second with less than 64kb or 
you can actually send acceptable frame rate and audio
with 28.8 kb.

The best way to learn about this stuff is to equip a PC with
the appropiate gear and play with it to see if it can meet
your requirements think about it as a "model" . The PC should
have win95 and freebsd installed . FreeBSD because it can 
show the optimal performance and win95 so you can play with
the audio/video apps which are not available for freebsd.

o video Matrox Meteor or Intel Smart Video Recorder III

o sound GUS PnP because it is a *true* full duplex audio card.

o S3 968 based card because it has VRAM and it fast enough for
  video display

o CPU P166 try to avoid PPRO 200Mhz till the PCI chipset gets
  debugged


	Well I am well over my .25 cent limit, have fun	
	Amancio


>From The Desk Of Don Yuniskis :
> Greetings!
>    Forgive my obvious ignorance but could someone give me
> the 25 cent explanation of the issues involved in broadcast
> video (i.e. mbone) technology?
>    In particular:
> * what types of compression rates are used in the video codecs
> * what sort of network bandwidth is consumed
> * is this "full motion" video (or something at a slower frame rate)
> * how much involvement is required on the part of the processor
> * to what extent can hardware (i.e. codecs) affect these values
> * what are the hidden "down side" issues
> 
>    I'm looking into using such a scheme in an embedded application.
> As such, I can control the other traffic on the network, etc.
> But, is this stuff "real"?  Or, still too experimental??
> 
> Thanks for your time!
> --don





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702120827.AAA28321>