Re: [Debconf-video] video annotations for DebConf13
On Fri, Aug 09, 2013 at 12:26:49AM +0200, Ben Hutchings wrote:
> On Thu, 2013-08-08 at 21:07 +0200, Wouter Verhelst wrote:
> > On 08-08-13 19:59, Axel Beckert wrote:
> > > Hi,
> > >
> > > On Thu, Aug 08, 2013 at 05:33:11PM +0200, Holger Levsen wrote:
> > >>> What is the bandwidth at the site like?
> > >>
> > >> 100mbit symetric, afaik. cc: abe@d.o to confirm
> > >
> > > That's what I have been told. But it seems to be more.
> > >
> > > Over a long time (mirror sync) I got 33 MB/s easily and peaks up to
> > > 126 MB/s which smells suspiciously like the 1 GBit/s others were
> > > mentioning.
> >
> > Maybe that just means that the SLA is 100mbit, but that we can use more
> > if the bandwidth is available?
>
> In any case, I would not suggest we rely on being able to use more than
> a fraction of that bandwidth for video streams.
>
> Daf, the way we've done streaming at DebConf so far (7 years now?) is
> shown in:
> http://anonscm.debian.org/gitweb/?p=debconf-video/package.git;a=blob;f=doc/network-debconf.png;h=f958a0b472c1150df3e6b3feefdcb2429c0050bd;hb=a1522ac272ccd3f211cec9e806a0df4f197252a5
> Each stream is sent to a single internal server (localstream1). There
> is a single external relay (krusty) pulling from localstream1, and then
> multiple additional relays pulling from krusty. Thus, streams are
> available to internal and external viewers without multiple copies being
> sent over the WAN link.
>
> I'm still unclear on whether you can use Icecast for the subtitled WebM
> streams. If so, then a similar arrangement should be possible. Ideally
> we could use the same set of relay servers.
We don't produce subtitled streams; any annotations are distributed
out of band. (In the future I expect we will support some combination
of WebVTT and SRT export.)
Currently, we do produce our own streams which differ only in having
timestamps reset to starting from 0, mainly (IIRC) to work around some
unfortunate bugs in Firefox (the currentTime attribute on the <video>
tag is not relative to the stream join time) Chrome (doesn't support
seeking in files which don't start at t=0) and ffmpeg (produces output
with broken indexes when transcoding files which don't start at t=0).
(We instead preserve the absolute and relative start times of our
stream recording and communicate those out of band.)
We also publish a dynamically produced WebM file to support rewinding
in the live stream. I.e. this is a resource that looks like a normal
static WebM file to a web browser, and supports seeking accordingly,
but which is continuously updated with frames from the stream.
If bandwidth usage is a concern, we could try to work out a setup that
only involves a single upload per stream.
Asa a reference, looking at some of our output from OHM, our WebMs
were encoded at approximately 241kbps, or 1.7MiBytes per minute. I
think this means that at 100mbit, 4 viewers would saturate the uplink.
At 1gbit, it would take roughly 40.
(I looked at one file with size 7650556 which contained 6334 frames,
which is 253s at 25fps. 7650556 / 253 is 30239 bytes per second, or
241914 bits per second, or 236 kibibits per second.)
Reply to: