Live Streaming

This page is a quick guide to using the second Live Streaming development branch, which is based on the new Tribler Core, and can be found at [source:abc/branches/jandavid/d08-03-06-swarmplayer-livestreaming-r6955]. This guide was written for revision 7528.

Status

Live Streaming works, but:

  • Broadcasts can use the same .torrent, as long as piece size, duration, name and source authentication parameters remain the same. Duration is just a parameter to "set window size" as we now have wraparound.
  • Currently the name + source auth info makes the .torrent unique. In particular, the 'live' field in the 'info' dict now is a dict that contains an 'authmethod' field indicating what method of source auth is being used. We support one method at the moment, ECDSA signatures. For this method the 'live' dict contains an extra 'pubkey' field containing a binary EC public key. ECDSA signature now also handles replays and reordering of pieces.
  • Broadcasts cannot be downloaded with a different BitTorrent client (but a different client can be easily modified to support it).
  • The delay between channel and end-user varies greatly (10 seconds to several minutes).
  • Batched G2G_XFER messages: We send list of [piece,perc (1byte)] every 4 seconds, instead of for every chunk.
  • Is tested at only the lab (100 Mbit links).

How to use

The following steps are required to start and watch a broadcast. First, have an URL for the source stream.

  1. Determine the bitrate and length of your broadcast. To do this for a file, do ffmpeg -i myfile.mpeg /dev/null.
  1. Start the server, with a stream named foo, which is read from url http://myurl. For streaming from file, omit the scheme. For streaming from a pipe, use pipe:script.sh. A file called foo.tstream will be created. 
./runmac.command Tribler/Tools/createlivestream.py --name foo --source http://myurl

If the stream needs to be limited in speed (for instance, when it is read from file), use the --bitrate 1024 parameter to limit the stream to 1kbyte/s.

  1. Start each client using the foo.tstream created by the server.

Codecs

The perceived quality depends on several factors, among which the codec that is used.

server video codec audio codec container notes
VLC mp2v mp2 ts Used for early demos. Ancient codecs though.
ffmpeg mpeg1video - mpeg ffmpeg -s 320x240 -an -f video4linux -i /dev/video -vcodec mpeg1video -vb 1024000 -minrate 1024000 -f mpeg
ffmpeg mpeg4 - mpegts ffmpeg -s 320x240 -f video4linux -i /dev/video -vcodec mpeg4 -vb 428288 -s 320x240 -an -f mpegts - ; good quality
ffmpeg mpeg4 mp3 mpegts ffmpeg -i /dev/video -vcodec mpeg4 -vb 428288 -s 320x240 -acodec mp3 -ab 96000 -ac 1 -f mpegts -
VLC h264 mp3 mpegts internal VLC (0.8.6a) plays H2.64 ; problem is generating good input with ffmpeg/x264, motion issues when putting it in mpegts

Todo

High priority:

Jan David:

  • Allow readers to re-tune-in when the source goes away for a while.
  • Related: may sure a reader can survive a stall, i.e., if it is stalled, it should not start throwing away HAVEs from the source as being invalid.
  • = External moving play pos and selective dropping.
  • Optimizations from simulations.

Arno:

  • Get rid of INTERESTED/NOT_INTERESTED msgs. NOT: JD says this has value (CHECK)
  • Long-playing bug (player stops playing after > 24 hours)

Middle priority:

  • Adjusting stream to match situation (speedup at full buffer, slowdown at empty buffer?).
  • Find good codecs (good = nice quality and no vlc problems).
  • Proper timing of starting playback.
  • Prebuffer minimalisation
  • GUI for webcam interface.

Low priority: