OverlayNetworks - Cronologia

VittorioPalmisano: /* References */

2007-07-06T18:39:54Z

‎References

2007-07-06T16:00:02Z

‎P2P Overlay Network for content delivery

2007-04-26T12:44:15Z

2007-04-03T12:56:55Z

‎Adaptive audio/video codecs

2007-04-03T12:55:02Z

‎Adaptive audio/video codecs

2007-04-03T12:53:19Z

‎Adaptive audio/video codecs

2007-03-20T16:10:15Z

‎Adaptive audio/video codecs

2007-03-20T16:09:24Z

‎Adaptive audio/video codecs

2007-02-09T18:15:56Z

‎End-to-end transport protocol

2007-02-09T18:12:05Z

‎Adaptive audio/video codecs

@@ Riga 136: / Riga 136: @@
 The Impact of Heterogeneous Bandwidth Constraints on DHT-Based Multicast
 </paper>
-<paper authors="Sripanidkulchai, K. and Ganjam, A. and Maggs, B. and Zhang, H." conference="Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications" date="2004 ([http://msw3.stanford.edu/~ivmsjc/esetton/jc_feb16.pdf PDF])" place="ACM Press New York, NY, USA" >
+<paper authors="Sripanidkulchai, K. and Ganjam, A. and Maggs, B. and Zhang, H." conference="Proceedings of the SIGCOMM 2004 conference on Applications, technologies, architectures, and protocols for computer communications" date="2004 ([http://msw3.stanford.edu/~ivmsjc/esetton/jc_feb16.pdf PDF])" place="ACM Press New York, NY, USA" >
 The feasibility of supporting large-scale live streaming applications with dynamic application end-points
 </paper>

@@ Riga 101: / Riga 101: @@
 ** Use a '''central node''' in order to organize peers join/leave?
 ** Use '''Distributed Hash Tables''' ('''DHT''') routing in order to reduce paths depth?
 * Fragmentation:
 ** In the case of file download, more fragments can be received and reordered

←Older revision		Revisione 12:44, 26 Apr 2007
Riga 1:		Riga 1:
−	~~<accesscontrol>Lab</accesscontrol>~~
	=Peer to Peer Overlay Networks for Multimedia Distribution=		=Peer to Peer Overlay Networks for Multimedia Distribution=

←Older revision		Revisione 12:56, 3 Apr 2007
Riga 76:		Riga 76:

	[[Immagine:fgs.png\|center\|thumb\|800px\|''FGS video streaming'']]		[[Immagine:fgs.png\|center\|thumb\|800px\|''FGS video streaming'']]
		+
		+	We use the [http://gstreamer.org GStreamer] development platform for the implementation of test client/server applications.

	===References===		===References===

@@ Riga 69: / Riga 69: @@
 * [http://speex.org Speex]: is an Open Source/Free Software patent-free audio compression format that allows to change the encoding rate on fly
 * '''H.264/AVC''' (and his free implementation [http://www.videolan.org/developers/x264.html X264]): is a video codec standard that can achieve both high data compression at low bitrates (~100 Kbit/s) and high video quality at high bitrates (~4 Mbit/s).
-* [http://dirac.sourceforge.net/ Dirac] ([http://schrodinger.sourceforge.net/ here] an optimized and portable implementation): is a free and open source video codec producing very high image quality video developed by [http://www.bbc.co.uk/rd BBC Research and Development]. We have modified the schrodinger implementation in order to customize the encoded bitstream: we select a subset of the encoded bands in order to achieve the required bitrate at the server side.
+* [http://dirac.sourceforge.net/ Dirac] ([http://schrodinger.sourceforge.net/ here] an optimized and portable implementation): is a free and open source video codec producing very high image quality video developed by [http://www.bbc.co.uk/rd BBC Research and Development]. We have modified the schrodinger implementation in order to customize the encoded bitstream: the required bitrate is achieved at the server side selecting a subset of the encoded video subbands.
 Video scalability can be assured by using two different techniques:

@@ Riga 31: / Riga 31: @@
 Our purpose is to design and implement in user space a protocol a-la Westwood+ which will be able to scale from low bandwidth links (few Kbps such as GSM) to very high bandwidth links (such as gigabit networks).
-As we aim at seamless multimedia delivery over a wide range of link capacities and technologies (wired and wireless), the transport protocol must guarantee its functioning even in the case of lossy links such as GPRS, UMTS, WiFi and WiMax.
+As we aim at seamless multimedia delivery over a wide range of link capacities and technologies (wired and wireless), the transport protocol must guarantee its functioning even in the case of lossy links.
 Moreover we aim at integrating the congestion control algorithm with a quality adaptation layer which is in charge of adapting the quality in the underlying encoder in order to get the maximum audio/video quality without congesting the network and losing packets.

@@ Riga 63: / Riga 63: @@
 == Adaptive audio/video codecs==
-Streaming of live contents requires low '''packet latency'''. This can be accomplied reducing '''buffer levels''' on sender, so the audio/video '''encoding''' level should be adapted to the transport sending rate.
+Streaming of live contents requires low '''packet latency'''. This can be accomplished reducing '''buffer levels''' on sender, so the audio/video '''encoding''' level should be adapted to the transport sending rate.
 Adaptive audio and video codecs can accomplish this task.