First off, thanks to the staffers who set up live streaming. I'm using HD unicast, and the quality is great.
That said, is it possible to have the camera zoom in to the presenter a bit? The whole room is shown, and even on a 24" screen I still can't really see the presenters very clearly, since there's some pixellation.
Thanks,
TJ
Thank you, now I can see the presenter.
Next challenge, can you put an overlay of the slides on the upper right quarter of the screen? 
TJ
First off, thanks to the staffers who set up live streaming. I'm using HD
unicast, and the quality is great.That said, is it possible to have the camera zoom in to the presenter a bit?
The whole room is shown, and even on a 24" screen I still can't really see
the presenters very clearly, since there's some pixellation.
Could just be your monitor. On mine, I can see the laptop screens
of the people in the back of the room. Fun to watch what they're during
the talks. 
(I like the large view of room plus screens on side, myself)
Matt
I'm using a 24" iMac in full screen so the resolution is pretty decent. But I hadn't thought about the side benefit of watching what people are doing on their laptops, good entertainment value I suppose.
TJ
Glad it looks decent for folks out there.
In case anyone is interested, below is a quick rundown of what it took to get Nanog49 (shot with a Sony z1u hdv camera with firewire output, thanks Merit!) on the net' this time around.
The VLC team has kicked lots of butt in recent months, fixing threading on win32 for x264 and ffmpeg-supplied codecs. This means that HD encoding win32 platforms (and handy things like directshow supported devices) can finally work again. Previous to this, we had relayed a ~25 megabit unicast UDP stream of the direct-from-camera mp2ts data (i.e. 'raw' hdv MPEG2 video+audio) up to Merit (or iris networks, netflix at DR nanog, others I forget), performing transcoding there on a multi-core system.
Of course, reducing 25 megabits/sec to ~1 megabits/sec through on-site encoding means that TCP can easily conceal most network losses on our uplink. This is not to suggest that there are many, but *any* loss is plainly visible on un-protected mpeg TS's. Because we can operate at such a low bitrate, the quick re-transmission of lost TCP segments doesn't represent a large enough under-run to disturb the relay servers' mpeg transport stream demultiplexer--its software PLL stays synchronized with the embedded PCR, and things happily hum along amidst random packet drop.
Encoder box: core2quad i5, 2.67 ghz, clocked at 3ghz (and decent ddr3 sdram), 32 bit windows XP sp3, VLC 1.0.5
Encoder command line: vlc.exe dshow:// :dshow-vdev="Microsoft AV/C Tape Subunit Device" :dshow-adev= --sout="#transcode{vcodec=h264,threads=8,deinterlace,vb=900,acodec=mp4a,ab=128,channels=1,venc=x264{keyint=90,ref=8,partitions=all,8x8dct,non-deterministic}}:std{access=http,mux=ts,dst=:xxxx}" --sout-mux-caching=500
(runs with ~75% overall load)
Relay box @ Merit: 3 ghz p4 HT, linux 2.6, vlc 1.x.x, gige port, etc...
Relay command line: vlc -vvv http://x.x.x.x:xxxx --sout=#duplicate{dst=std{access=udp{ttl=255},mux=ts,dst=233.0.236.10:1234},dst=std{access=http,mux=ts,dst=:8080}} -L --sout-keep
(runs with <1% load with 50 stream clients)
HTH,
-Tk
Does anyone have the video bits from the Haitian panel? I'd like to
run it within our loop at the ICANN meeting next week in Brussels.
Tia!
Eric