Video Tuturial now available

[Lutz Vieweg]

On 02/18/2013 09:02 AM, Robert C. Helling wrote:
> I have two suggestions, though: It seems archive.org's bandwith is quite limited, at home (where
> usually I have no problems watching streamed video) it stopped several times due to the buffer
> running low and I had to wait about a minute to restart.

I just tried a plain download of the 1080p30.mp4 file, and it was transferred in 2m 34s -
so about 4 times faster than required for realtime playback.

I tried streaming replay using three different browsers on an Android device, and
it seems to me that it is not the bandwidth of archive.org, but a stupid implementation
of buffering by some browsers that causes the described behaviour:
The Android-internal browser and Chrome both seem to fill their buffers based
solely on an amount of bytes, not considering any Presentation Time Stamps
within the video container format. Since the bandwidth of the tutorial video
is very low in the beginning, but increases steeply for a short while
when the underwater clips are displayed, those browsers suddenly realize
that the amount of bytes they buffered in advance does not by far cover
as many seconds of replay as they thought - in the standard Android browser,
you can see that the "brighter" part of the timeline control that indicates the
position until which data is buffered becomes actually _shorter_ when the
start of the complex scene is reached!

In contrast, Firefox on android did not expose any such problem, it replayed
the video without any buffer underrun.

TCP over a long distance is probably not the best of all protocols for
video streaming, yet if those players would not put back-pressure on the
sender too early, it should still work quite well.

What I can try is to artificially limit the volatility of bandwidth in the
next version of the video. This will spoil some bytes on more or less static
content without increasing its quality, but it might be enough to make the
"buffer size computation from bytes of data instead of presentation time stamps"
less inaccurate.

> Now I am in the office (with a 100MBit
> uplink more or less directly attached to the German backbone) and it does not start at all (spinning
> dots of death).

Hmmm.. maybe there are corporate firewall chicanery dwarfs bopping around
on your network line?


> Maybe you should consider uploading it to vimeo.com as well? It's free (i.e. no money, no ads) and
> also hosting CC licensed stuff.

If you want everyone to be able to download the uploaded video files,
this is not possible on vimeo.com without a paid "PLUS" account.
Also, AFAIK, vimeo.com does not support any patent-free codecs,
such as webm, which would exclude all users of non-pimped Linux
distributions - a standard Firefox cannot replay a vimeo video
(and no, infecting ones system with Adobe malware is not an option).

Also, the upload limit for vimeo free accounts is 500 MB - which would not
be sufficient to provide more than one version of the file, and which
would be annoying if a replacement of the existing file was required
due to some bug.

But of course I don't mind if anyone wants to re-publish my video
on whatever video hoster is compatible with the CC-BY-SA license...

> You only notice in the cuts where it drops to silence for a second or two. Maybe you want to add a
> 'comfort noise' track?

I'll consider to use some more low-volume "scuba breathing noise" for that
purpose :-)

Regards,

Lutz Vieweg