[127163] in North American Network Operators' Group
(OT) recipe for Live streaming from NANOG49
daemon@ATHENA.MIT.EDU (Anton Kapela)
Wed Jun 16 12:41:04 2010
From: Anton Kapela <tkapela@gmail.com>
In-Reply-To: <4C17A9DD.3080506@kniveton.com>
Date: Wed, 16 Jun 2010 09:40:46 -0700
To: T.J. Kniveton <tj@kniveton.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 15, 2010, at 9:27 AM, T.J. Kniveton wrote:
> 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.
Glad it looks decent for folks out there.=20
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.=20
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=3D"Microsoft AV/C =
Tape Subunit Device" :dshow-adev=3D =
--sout=3D"#transcode{vcodec=3Dh264,threads=3D8,deinterlace,vb=3D900,acodec=
=3Dmp4a,ab=3D128,channels=3D1,venc=3Dx264{keyint=3D90,ref=3D8,partitions=3D=
all,8x8dct,non-deterministic}}:std{access=3Dhttp,mux=3Dts,dst=3D:xxxx}" =
--sout-mux-caching=3D500
(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=3D#duplicate{dst=3Dstd{access=3Dudp{ttl=3D255},mux=3Dts,dst=3D233.0=
.236.10:1234},dst=3Dstd{access=3Dhttp,mux=3Dts,dst=3D:8080}} -L =
--sout-keep
(runs with <1% load with 50 stream clients)
HTH,
-Tk=
