[Imc-tech] live video upload via wireless network:

Mon Feb 10 14:58:59 CST 2003

Hi all,

Below is an _extremely_ interesting test of feeding video via a wireless
network over the internet.  It is definitely worth a read, and the
researchers went to great length to document the different hardware and
software they were using.  For the UCIMC, it provides an opportunity for
investigating live video uploading; for the CU Wireless Project, it's
another great addition to the possibilities of a wireless network and
could add substantially to our public access TV offerings.

--Sascha

>TITLE: Wireless Broadcast: Public WiFi Network 2 Public Cable Network
>
>What is the Project About?
>
>The goal of the project is to establish procedure and criteria for
>broadcasting to the cable or satellite TV network from remote locations,
>using a laptop, camera and any type of available broadband Internet
>connection - preferably WiFi.
>
>The motivation for such an exercise is the attempt to break away from
>classical TV production requiring hundreds of thousands of dollars in
>specialized infrastructure and enable immediate and on-the-fly transmission
>from remote locations to the TV network, ultimately leading toward creative
>production of programming from within a P2P network.
>
>How Is It Done?
>
>The primary concept uses current consumer-level technology coupled with
>broadband internet to offer a viable framework for distributed TV
>production via the Internet. Hardware and software are deliberately
>composed to be within the reach of a mid-skilled Internet user. Public
>wireless nodes provide enough bandwidth to carry IP video streams at
>sufficiently high quality, acceptable for TV transmission. Prior to the
>experiments, the following quality thresholds were established:
>
>   * Video quality of 320x240 pixels in size, minimum of 8 frames per
>     second, encoded using a standards-compliant video codec (MPEG4)
>   * Audio quality of 16 bit stereo sound, encoded at a minimum of 32kbps
>     using a standards-complaint audio codec (AAC).
>
>Although "broadcast-quality" video is loosely defined as 640x480 pixels at
>30 fps, we have found that most viewers will accept the look of 320x240
>video doubled in size (NTSC standard-definition video has a maximum of 525
>lines of vertical resolution) and that a minimum of 8 fps was "acceptable"
>for watching short video clips of 30 seconds or less with 15 fps (the
>minimum rate at which the human eye sees fluid motion) preferable.
>
>The system works much like standard live media encoding/streaming. Video
>and audio is captured from a consumer-level camcorder into a computer where
>it is encoded as MPEG4/AAC streams and sent out as a unicast stream via a
>broadband connection. Instead of sending the video+audio to a replication
>server, a client computer with a static-IP address receives the stream from
>across the internet and plays the media out to a video switcher and onto
>the cable channel/satellite broadcast.
>
>the chain: camera > firewire/vid-in+aud-in card > computer w/encoding
>software > eth/802.11 > internet > eth > computer w/media player > scan
>converter/pci card w/ svid out > video/audio switcher > community
>television network_
>
>Testing The Concept.
>
>2003.01.14 - The Bryant Park Test.
>
>Our first public wireless test was performed on January 14, 2003 using the
>wireless Internet connection at Bryant Park ( http://www.bryantpark.org )
>in New York. Bryant Park is one of the largest public WiFi access points
>with more than enough bandwidth to carry streaming video and audio back to
>our Home Base, the community cablecast center at Manhattan Neighborhood
>Network ( http://www.mnn.org ).
>
>'On Location' hardware consisted of a 600MHz Apple iBook (256MB RAM, OS
>10.1.5, Airport 802.11b Card, QuickTime Broadcaster 1.0) coupled via
>FireWire to a Sony PC100 DV Camcorder. The alternative, and more preferable
>solution would be a fully Open Source solution: a PC laptop with Linux
>operating system, an inexpensive video capture PC Card, and MPEG4IP
>software bundle.
>
>The Internet broadcast was then unicast via WiFi network installed in
>Bryant Park by NYCWireless, ( http://www.nycwireless.net ), to the client
>computer at Manhattan Neighborhood Network. The signal was then channeled
>into a video mixer and played to a QC monitor as if it were a regular
>broadcast stream.
>
>Video quality and motion varied according to the bitrate and frame rate
>specified while using the MPEG4 codec, but as a general rule we concluded
>that the image quality was very good but that we would need additional
>resources (more efficient live encoding software or more powerful CPU) to
>achieve our goal of a constant 15 fps. It would be interesting to test an
>x86/Linux/MPEG4IP combination in the same setup. Some preliminary tests
>from a PC desktop show slightly better results.
>
>After completing the tests, we realized that there were several points for
>further investigation. When operating off of battery power, the computer's
>operating system automatically adjusts for longer battery life at the
>expense of processing power. This is a user-customizable setting that we
>failed to check before running our tests. Because we never checked It could
>be that the 600MHz G3 processor was fast enough to encode video at the
>quality we wanted. It was very cold that day which could easily affect two
>important variables: the amount of bandwidth available (there are very few
>users logged in on a cold winter day) and the amount of battery life
>available (the batteries in both the camcorder and the laptop drained in
>under 90 minutes, faster than we expected). We should conduct these tests
>again in warmer weather (with presumably less bandwidth and longer battery
>life) to see if we get significantly different results.
>
>The most important result from this test is that the concept is valid: the
>current consumer-level technology, coupled with broadband Internet, offers
>a viable framework for distributed TV production via the Internet.
>
>Test equipment: 600MHz Apple iBook (256MB RAM, OS 10.1.5, Airport 802.11b
>Card, QuickTime Broadcaster 1.0), Sony PC100 DV Camcorder, Sony TRV-18 DV
>Camcorder, 300MHz Apple PowerMac G3 (128MB RAM, OS 9.2.2, QuickTime Player
>6.0), AverMedia iAverKey ProDV scan converter, Sony DSR-20 DVCAM deck,
>Tektronix WFM 1730 Waveform Monitor_
>
>Test personnel: Kenyatta Cheese < kenyatta at mnn.org > (MNN), Jay Dedman <
>jay at mnn.org > (MNN), Martin Lucas < mlucas at igc.org > (Hunter College),
>Drazen Pantic < drazen at location1.org > (Location One), Lourdes-Marie
>Prophete < loudi at mnn.org > (MNN).
>
>2003.02.07 - The Community Node Test.
>
>Our second public wireless test was performed on February 7, 2003 using a
>WiFi access point (and NYCWireless node) in the Clinton Hill neighborhood
>of Brooklyn, New York. The purpose of this test was to run a laptop on
>battery power at full processor speed to potentially increase the frame
>rate and determine whether the resizing and transcoding from 720x480 DV to
>480x320 MPEG4 was a major factor in the low frame rates of the Bryant Park
>test.
>
>This node sits between two other (private) access points on the same block,
>both with a decent amount of traffic during the late afternoon (determined
>through tcpdump) and both operating on channel 6, probably in interference
>with one another. In order to add some more noise to our network (and mimic
>probable network traffic), we set our AP to also use channel 6 and began
>encoding MPEG4 video and audio from a laptop on the street back to two
>Windows clients on the same subnet.
>
>Our laptop (a 500MHz Apple PowerBook G4, 512MB RAM, OS 10.2.3, Airport
>802.11b Card, QuickTime Broadcaster 1.0) was connected to a Sony PC100 DV
>Camcorder. Although the same 'blocky' artifacts showed up in the encode, we
>were successful in sending 320x480 video + audio at 15 fps back to the two
>client computers on the LAN. Video was encoded at 100kbps, 300kbps, and
>500kbps with little difference between the 300kbps and 500kbps streams. We
>then sent the 300kbps stream successfully over the Internet to a client
>computer at the Manhattan Neighborhood Network studio for 12+ hours.
>
>Although the increased frame rate made this test a success, the artifacting
>in the DV to MPEG4 transcode was still there. As a future test we should
>try the video encode using a video source that doesn't have to be
>uncompressed before compressing into MPEG4.
>
>_*Test equipment: *500MHz Apple PowerBook G4 (512MB RAM, OS 10.2.3, Airport
>802.11b Card, QuickTime Broadcaster 1.0), Sony PC100 DV Camcorder, 900MHz
>Celeron Sony VAIO (256MB, Windows NT 4.0, QuickTime Player 6.0), 800MHz IBM
>Thinkpad X22 (256MB, Win2K Pro, QuickTime Player 6.0), 400MHz Apple
>PowerMac G4 (256MB, OS 10.2.1, QuickTime Broadcaster 1.0)
>
>Test personnel: kenyatta cheese < kenyatta at mnn.org > (MNN), Lourdes-Marie
>Prophete < loudi at mnn.org > (MNN).
>
>20030208 - The PCI Card Test.
>
>Our first test with a Linux-based desktop solution used the now defunct
>D-Link DSB-V100 USB video capture device to bring 320x240 pixel video into
>a 2.0GHz P4 ASUS-based system running RedHat Linux 7.3 and MPEG4IP. Because
>of the limited bandwidth available to the D-Link device, 320x240 at 8fps
>was the highest quality video we could get.
>
>We switched inputs to a Formac ProTV PCI video capture card (unknown
>Nogatech chipset) and found that the increase in bandwidth made available
>by the PCI bus gave us a high quality 320x480 pixel video at a steady
>15-20fps. Video was streamed to a replication server and viewed by a client
>computer running QuickTime Player with no problems.
>
>Once we can find some test hardware to borrow, we want to test several
>PCMCIA analog video capture cards (Nogatech PCMCIA-TV, ZVPort Video-X)
>connected to a PC laptop although PCMCIA video capture cards are limited to
>320x240 video at 30fps.
>
>Test equipment: 2.0GHz ASUS-based P4 system (256MHz, RedHat Linux 7.3,
>MPEG4IP 0.9.7+, Formac ProTV PCI, DLink DSB-V100 USB), 500MHz Apple
>PowerBook G4 (512MB RAM, OS 10.2.3, Airport 802.11b Card, QuickTime Player
>6.0.2)
>
>Test personnel: Kenyatta Cheese < kenyatta at mnn.org > (MNN), Drazen Pantic <
>drazen at location1.org > (Location One).
>
>What is the Road Map For The Future?
>
>   * Upload video clips *from the January/February 2003 experiments.
>   * Assemble a PC version of the remote broadcaster*, based fully on open
>     source software and conduct equivalent tests.
>   * Compile easy plug-and-play software setup*, convenient for standard low
>     to mid-level skilled users.
>   * Create AppleScripts and a custom interface to QuickTime Broadcaster to
>     enable effortless setup for low-skilled users.
>   * Set up Darwin Streaming Server to authenticate and accept video streams
>     from public broadcaster clients.
>   * Make a bootable Linux CD, with all of the software needed, including
>     MPEG4 encoder, as many WiFi, audio, and video capture device drivers as
>     possible.
>   * Enable the immediate negotiation of DHCP addressing and establishing of
>     broadcast services upon boot.
>   * Put the call out to the community media activist, open source
>     technology communities for assistance.
>   * Attend the February 2003 NYCWireless meeting to inform them of the
>     project, see if they are interested in creating a formal partnership.
>
>Links.
>
>software. MPEG4IP - http://mpeg4ip.sourceforge.net
>QuickTime Broadcaster - http://www.apple.com/quicktime/products/broadcaster
>Darwin Streaming Server - http://developer.apple.com/darwin
>
>orgs.
>
>NYCWireless - http://www.nycwireless.net
>Open Source Streaming Alliance - http://www.streamingalliance.org
>Manhattan Neighborhood Network - http://www.mnn.org
>Location One - http://www.location1.org
>
>similar projects. remote-tv (Berlin) - http://www.remote-tv.de[26]
>
>Project Web Page & Contacts. http://www.mnn.org/tech/projects/laika
>kenyatta cheese < kenyatta at mnn.org >, Drazen Pantic < drazen at location1.org
>
>Next 5 Minutes 4 : http://www.n5m.org