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.
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.
- Determine the bitrate and length of your broadcast. To do this for a file, do ffmpeg -i myfile.mpeg /dev/null.
- 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.
- Start each client using the foo.tstream created by the server.
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
- 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.
- Get rid of INTERESTED/NOT_INTERESTED msgs. NOT: JD says this has value (CHECK)
- Long-playing bug (player stops playing after > 24 hours)
- 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.