This document describes a way to use the new MAGMA-specs for streaming media. With the new MAGMA-specs it will be possible to stream radio streams over p2p-Networks. They can be set to play at a certain time, so all listeners listen to the same content at the same time, but they have to be pre-prepared to do so (a time lag of 5 to 30 minutes should be accounted for, as the files need time to spread in the network. Partial Filesharing makes it possible to keep the lag small, because Users automatically upload the parts they already have to other Users. For this I defined some parameters to be used with p2p-streaming. I'll explain them in an example MAGMA-streaming file. There are two types of streams: Timed streams, which shall be played at a certain time, and untimed streams, which shall be played as soon as the first part of the stream is finished. This first example covers timed-streams. =====BEGIN EXAMPLE FILE===== #MAGMAv0.2 magnet:?mt=.&as=http://files.gnufu.net/magma-streaming-example.magma # This example would be a file which could be used by a radio-station. # If some of the files are already on the users hard-disk, # the programs should recognize them and use them directly # instead of downloading them. # With this one further capability of magnets gets incorporated. list-type: timed stream, updating file update-interval-ms: 60000 update-source: http://files.gnufu.net/magma-updating-streaming-example.magma title: # For static magma-files the next-update-source parameter can be used # instead of the update-source parameter. # This way multiple MAGMA-files can be pre-prepared for a few hours in advance # and can be delivered as soon as the next magma-file is ready. # In this case the list type needs to be "stream, static". # The list-type parameter should be given before the update-parameters. # Example follows: list-type: timed stream, static file next-update-source: "magnet:?xt=und:sha1:&as=http://files.gnufu.net/magma-static-streaming-example2.magma next-update-time: title: creator: : nickname: homepage: e-mail: birthdate-yyyy-mm-dd: # There can be any number of additional information about the creator. # By making the additional Infos subfields of the name, more than one creator # can be given. list: - "" time-to-play: # this might look like time-to-play: 2004-06-30 15h06m15s00ms GMT-0300 # All times are in GMT as it is done in E-Mails. MIME-type: length-ms: bitrate-KBit: size-Bytes: # the size should be used by the p2p programm to determine # how much lag it should take into consideration # and if it will be able to fetch the file completely before the time-to-play. track-name: artist: album: # These can be used by the p2p-App to locate different versions of the file, # Which don't share the same hash, but contain the same music. # To ensure that the content matches, the length of the track # should be off by at most 200ms. lag-expected-ms: # This can be used to make it easier for the program to determine which files # it can get early enough to play them in time. # While some programs may rely on this, they should rather determine the # expected lag themselves. This serves mainly to make the stremaing easier # to implement. Stats how much lag is expected for which filesizes # according to the upload speed you have and the size of your audience # will follow.