2008/Conexión - Historial de revisiones

D1d4c en 14:58 21 oct 2012

D1d4c — Sun, 21 Oct 2012 14:58:28 GMT

← Revisión anterior		Revisión de 14:58 21 oct 2012
Línea 1:		Línea 1:
-	[[Categoría:Grupo red]][[Categoría:~~Grupo de trabajo~~]][[Categoría:Red]]	+	[[Categoría:Grupo red]][[Categoría:Grupos]][[Categoría:Red]]
	{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}		{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}

D1d4c en 13:56 31 jul 2010

D1d4c — Sat, 31 Jul 2010 13:56:00 GMT

← Revisión anterior		Revisión de 13:56 31 jul 2010
Línea 1:		Línea 1:
-	[[Categoría:Grupo red]][[Categoría:Grupo de trabajo]]	+	[[Categoría:Grupo red]][[Categoría:Grupo de trabajo]][[Categoría:Red]]
	{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}		{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}

Marc ro en 04:14 12 feb 2009

Marc ro — Thu, 12 Feb 2009 04:14:30 GMT

← Revisión anterior		Revisión de 04:14 12 feb 2009
Línea 1:		Línea 1:
-	~~[[Categoría:Coordinación]]~~[[Categoría:Grupo red]][[Categoría:Grupo de trabajo]]	+	[[Categoría:Grupo red]][[Categoría:Grupo de trabajo]]
	{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}		{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}

Marc ro: Revertida a la última edición por Caraconan

Marc ro — Thu, 12 Feb 2009 04:14:06 GMT

Revertida a la última edición por Caraconan

← Revisión anterior		Revisión de 04:14 12 feb 2009
Línea 1:		Línea 1:
-	[[Categoría:~~Documentación~~]]	+	[[Categoría:Coordinación]][[Categoría:Grupo red]][[Categoría:Grupo de trabajo]]
	{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}		{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}

Marc ro en 04:11 12 feb 2009

Marc ro — Thu, 12 Feb 2009 04:11:02 GMT

← Revisión anterior		Revisión de 04:11 12 feb 2009
Línea 1:		Línea 1:
-	[[Categoría:~~Coordinación]][[Categoría:Grupo red]][[Categoría:Grupo de trabajo~~]]	+	[[Categoría:Documentación]]
	{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}		{{info\|Esta página está dedicada a documentar las necesidades de conexión para poder establecer los mínimos necesarios}}

Caraconan en 12:43 23 sep 2008

Caraconan — Tue, 23 Sep 2008 12:43:57 GMT

← Revisión anterior		Revisión de 12:43 23 sep 2008
Línea 19:		Línea 19:
	*Otro ADSL solo para el stream (indiferente si vecinal o linea propia)		*Otro ADSL solo para el stream (indiferente si vecinal o linea propia)
	*El mismo DSL para todo, y QoS.		*El mismo DSL para todo, y QoS.
-	*Conseguir 2 ~~lÃneas~~ ADSL con cableado (sin wifi vecinal). Lo ideal es tener las dos ADSL en la invisible, pero no pasa nada si una llega por cable desde un vecino y el vecino nos ayuda no usando p2p esos 3 dÃas.	+	*Conseguir 2 lineas ADSL con cableado (sin wifi vecinal). Lo ideal es tener las dos ADSL en la invisible, pero no pasa nada si una llega por cable desde un vecino y el vecino nos ayuda no usando p2p esos 3 dÃas.
	**una para una cosa i la otra para publico.		**una para una cosa i la otra para publico.
	**incluso se puede hacer una para video y la otra compartida entre audio y la gente va al hm.		**incluso se puede hacer una para video y la otra compartida entre audio y la gente va al hm.

D1d4c en 18:51 2 ago 2008

D1d4c — Sat, 02 Aug 2008 18:51:57 GMT

← Revisión anterior		Revisión de 18:51 2 ago 2008
Línea 26:		Línea 26:


-		+	=Necesidades según grupo=
		+	*[[2008/Radio/Conexión\|Necesidades de conexión de la radio]]
		+	*[[2008/Video/Conexión\|Necesidades de conexión del grupo video]]


	http://sindominio.net/hackmeeting/images/b/be/Conexiones_por_pais.png		http://sindominio.net/hackmeeting/images/b/be/Conexiones_por_pais.png

Aswarp: /* Tema streaming: Difusión de contenidos multimedia en tiempo real */

Aswarp — Sat, 02 Aug 2008 18:30:01 GMT

Tema streaming: Difusión de contenidos multimedia en tiempo real

← Revisión anterior		Revisión de 18:30 2 ago 2008
Línea 12:		Línea 12:
	Para hacer streaming de vídeo se requieren 512 kbps para transmitir una pantalla de ordenador a baja resolución (640512 pixels) en la que pueda distinguirse vagamente el texto. Para grabar a un conferenciante es suficiente, pero si la charla se basa en textos escritos en una terminal en pantalla, o si lo que se graba no es la salida de vídeo directamente, sino la imagen de un proyector, por ejemplo, sería aconsejable contar con 1024 kbps al menos.		Para hacer streaming de vídeo se requieren 512 kbps para transmitir una pantalla de ordenador a baja resolución (640512 pixels) en la que pueda distinguirse vagamente el texto. Para grabar a un conferenciante es suficiente, pero si la charla se basa en textos escritos en una terminal en pantalla, o si lo que se graba no es la salida de vídeo directamente, sino la imagen de un proyector, por ejemplo, sería aconsejable contar con 1024 kbps al menos.
	*NOTA: Las medidas en kbps se refieren a medidas reales, sostenidas, garantizadas. Es decir, que hará falta más en todo caso y que hay que evitar a otda costa los cortes y desconexiones durante la retransmisión. Por ejemplo: 128 kbps reales pueden corresponder a unos 196 medidos, dado que se pierde ancho de banda en ruidos de señal, latencias y otras zarandajas. Para el caso de vídeo, no se aconseja intertarlo con menos de 640 kbps (mejor si son 1024) en el caso de baja resolución, y dos megas (2048 kbps) en el caso de alta resolución. ¿Qué puede pasar si el ancho de banda se queda estrecho? Pues que la información que no queda por el canuto se descartará aleatoriamente, produciéndose pérdida de información, lo que los oyentes/televidentes percibirán como cortes y saltos en la señal de audio/vídeo. Además, esta información no podrá ser recuperada salvo que se efectúe una grabación "in situ" en paralelo con las tareas de streaming.		*NOTA: Las medidas en kbps se refieren a medidas reales, sostenidas, garantizadas. Es decir, que hará falta más en todo caso y que hay que evitar a otda costa los cortes y desconexiones durante la retransmisión. Por ejemplo: 128 kbps reales pueden corresponder a unos 196 medidos, dado que se pierde ancho de banda en ruidos de señal, latencias y otras zarandajas. Para el caso de vídeo, no se aconseja intertarlo con menos de 640 kbps (mejor si son 1024) en el caso de baja resolución, y dos megas (2048 kbps) en el caso de alta resolución. ¿Qué puede pasar si el ancho de banda se queda estrecho? Pues que la información que no queda por el canuto se descartará aleatoriamente, produciéndose pérdida de información, lo que los oyentes/televidentes percibirán como cortes y saltos en la señal de audio/vídeo. Además, esta información no podrá ser recuperada salvo que se efectúe una grabación "in situ" en paralelo con las tareas de streaming.
-	Caso óptimo: Dado que puede llegar a haber hasta cuatro ponencias simultáneas, y que además pasan cosas fuera de las charlas que sería interesante registrar em modo reporteril, lo ideal sería emitir cinco canales de vídeo simultáneos a alta resolución. Añadiendo cinco canales de audio, más la radio de HM nos quedaría algo como: (52048)+(6*256)+10% (control y ruido) = 12500 kbps (12,5 Mbps de SUBIDA). Como cada ADSL viene a tener de media unos 250 kbps reales de subida, ~~cara~~ el caso idílico super-chachi harían falta 50 líneas ADSL normales (o 7 líneas SDSL de 2MB simétricos) perfectamente balanceadas y coordinadas entre sí.	+	Caso óptimo: Dado que puede llegar a haber hasta cuatro ponencias simultáneas, y que además pasan cosas fuera de las charlas que sería interesante registrar em modo reporteril, lo ideal sería emitir cinco canales de vídeo simultáneos a alta resolución. Añadiendo cinco canales de audio, más la radio de HM nos quedaría algo como: (52048)+(6*256)+10% (control y ruido) = 12500 kbps (12,5 Mbps de SUBIDA). Como cada ADSL viene a tener de media unos 250 kbps reales de subida, para el caso idílico super-chachi harían falta 50 líneas ADSL normales (o 7 líneas SDSL de 2MB simétricos) perfectamente balanceadas y coordinadas entre sí.
	*Caso plausible: Emitir en tiempo real la emisora de radio y subir en diferido los canales de audio y vídeo capturados en charlas y reportajes.		*Caso plausible: Emitir en tiempo real la emisora de radio y subir en diferido los canales de audio y vídeo capturados en charlas y reportajes.
	*Alternativas: La principal alternativa al streaming en tiempo real es la difusión "fuera de línea" ("off-line", o "en diferido"), que consiste en la grabación de los contenidos in situ a la máxima calidad posible, seguida de su posterior recodificación (para comprimirla) y ulterior subida a un servidor de difusión de contenidos digitales multimedia, desde donde puedan descargarse bajo demanda. Sería aconsejable hacer la subida en franjas horarias en que la red no tenga mucho uso, como la franja entre las 4:00 y las 8:00 am. Esta opción es la más práctica, aunque se reduce la "emoción del directo". Lo ideal sería un punto medio mixto, pero llevando un control cuidadoso de todo el material multimedia que se genera y emite.		*Alternativas: La principal alternativa al streaming en tiempo real es la difusión "fuera de línea" ("off-line", o "en diferido"), que consiste en la grabación de los contenidos in situ a la máxima calidad posible, seguida de su posterior recodificación (para comprimirla) y ulterior subida a un servidor de difusión de contenidos digitales multimedia, desde donde puedan descargarse bajo demanda. Sería aconsejable hacer la subida en franjas horarias en que la red no tenga mucho uso, como la franja entre las 4:00 y las 8:00 am. Esta opción es la más práctica, aunque se reduce la "emoción del directo". Lo ideal sería un punto medio mixto, pero llevando un control cuidadoso de todo el material multimedia que se genera y emite.

Aswarp: /* Tema streaming: Difusión de contenidos digitales multimedia en tiempo real */

Aswarp — Sat, 02 Aug 2008 18:29:20 GMT

Tema streaming: Difusión de contenidos digitales multimedia en tiempo real

← Revisión anterior		Revisión de 18:29 2 ago 2008
Línea 7:		Línea 7:
	*Ahora mismo la wifi está abierta pero con limitaciones y muchos vecinos de la calle la tienen que estar disfrutando. Pero se puede usar de forma exclusiva si fuese necesario, durante el hackmeeting.		*Ahora mismo la wifi está abierta pero con limitaciones y muchos vecinos de la calle la tienen que estar disfrutando. Pero se puede usar de forma exclusiva si fuese necesario, durante el hackmeeting.

-	=Tema streaming: Difusión de contenidos ~~digitales~~ multimedia en tiempo real=	+	=Tema streaming: Difusión de contenidos multimedia en tiempo real=
	*Para el tema de streaming podriamos mirar como está el tema de ADSL por la zona, quizás podamos hablar con alguno de los vecinos y aquel mes le pagamos la conexión ADSL (25-50€), ponemos un router con una WPA2+PSK y la destinamos sólo para el streaming... y después le volvemos a colocar su router como lo tenía, claro está.		*Para el tema de streaming podriamos mirar como está el tema de ADSL por la zona, quizás podamos hablar con alguno de los vecinos y aquel mes le pagamos la conexión ADSL (25-50€), ponemos un router con una WPA2+PSK y la destinamos sólo para el streaming... y después le volvemos a colocar su router como lo tenía, claro está.
	*Para hacer streaming de audio se requieren aproximadamente 128 kbps (kilobits por segundo REALES), aunque si es radio a menudo se emplea una calidad menor, como 96 kbps. Lógicamente, a más caudal, mejor calidad del sonido, que deberá ser filtrado antes para eliminar ruido estático, chasquidos y chispeos.		*Para hacer streaming de audio se requieren aproximadamente 128 kbps (kilobits por segundo REALES), aunque si es radio a menudo se emplea una calidad menor, como 96 kbps. Lógicamente, a más caudal, mejor calidad del sonido, que deberá ser filtrado antes para eliminar ruido estático, chasquidos y chispeos.

Aswarp: /* Puntos sueltos */ Streamingas

Aswarp — Sat, 02 Aug 2008 18:28:43 GMT

Puntos sueltos: Streamingas

← Revisión anterior		Revisión de 18:28 2 ago 2008
Línea 6:		Línea 6:
	*Le hicimos un test y nos dío 6 megas de bajada y poco más de medio de subida		*Le hicimos un test y nos dío 6 megas de bajada y poco más de medio de subida
	*Ahora mismo la wifi está abierta pero con limitaciones y muchos vecinos de la calle la tienen que estar disfrutando. Pero se puede usar de forma exclusiva si fuese necesario, durante el hackmeeting.		*Ahora mismo la wifi está abierta pero con limitaciones y muchos vecinos de la calle la tienen que estar disfrutando. Pero se puede usar de forma exclusiva si fuese necesario, durante el hackmeeting.
-	*Para el tema de streaming podriamos mirar como está el tema de ADSL por la zona, quizás podamos hablar con alguno de los vecinos y aquel mes le pagamos la conexión ADSL, ponemos un router con una WPA2+PSK y la destinamos sólo para el streaming...

		+	=Tema streaming: Difusión de contenidos digitales multimedia en tiempo real=
		+	*Para el tema de streaming podriamos mirar como está el tema de ADSL por la zona, quizás podamos hablar con alguno de los vecinos y aquel mes le pagamos la conexión ADSL (25-50€), ponemos un router con una WPA2+PSK y la destinamos sólo para el streaming... y después le volvemos a colocar su router como lo tenía, claro está.
		+	*Para hacer streaming de audio se requieren aproximadamente 128 kbps (kilobits por segundo REALES), aunque si es radio a menudo se emplea una calidad menor, como 96 kbps. Lógicamente, a más caudal, mejor calidad del sonido, que deberá ser filtrado antes para eliminar ruido estático, chasquidos y chispeos.
		+	Para hacer streaming de vídeo se requieren 512 kbps para transmitir una pantalla de ordenador a baja resolución (640512 pixels) en la que pueda distinguirse vagamente el texto. Para grabar a un conferenciante es suficiente, pero si la charla se basa en textos escritos en una terminal en pantalla, o si lo que se graba no es la salida de vídeo directamente, sino la imagen de un proyector, por ejemplo, sería aconsejable contar con 1024 kbps al menos.
		+	*NOTA: Las medidas en kbps se refieren a medidas reales, sostenidas, garantizadas. Es decir, que hará falta más en todo caso y que hay que evitar a otda costa los cortes y desconexiones durante la retransmisión. Por ejemplo: 128 kbps reales pueden corresponder a unos 196 medidos, dado que se pierde ancho de banda en ruidos de señal, latencias y otras zarandajas. Para el caso de vídeo, no se aconseja intertarlo con menos de 640 kbps (mejor si son 1024) en el caso de baja resolución, y dos megas (2048 kbps) en el caso de alta resolución. ¿Qué puede pasar si el ancho de banda se queda estrecho? Pues que la información que no queda por el canuto se descartará aleatoriamente, produciéndose pérdida de información, lo que los oyentes/televidentes percibirán como cortes y saltos en la señal de audio/vídeo. Además, esta información no podrá ser recuperada salvo que se efectúe una grabación "in situ" en paralelo con las tareas de streaming.
		+	Caso óptimo: Dado que puede llegar a haber hasta cuatro ponencias simultáneas, y que además pasan cosas fuera de las charlas que sería interesante registrar em modo reporteril, lo ideal sería emitir cinco canales de vídeo simultáneos a alta resolución. Añadiendo cinco canales de audio, más la radio de HM nos quedaría algo como: (52048)+(6*256)+10% (control y ruido) = 12500 kbps (12,5 Mbps de SUBIDA). Como cada ADSL viene a tener de media unos 250 kbps reales de subida, cara el caso idílico super-chachi harían falta 50 líneas ADSL normales (o 7 líneas SDSL de 2MB simétricos) perfectamente balanceadas y coordinadas entre sí.
		+	*Caso plausible: Emitir en tiempo real la emisora de radio y subir en diferido los canales de audio y vídeo capturados en charlas y reportajes.
		+	*Alternativas: La principal alternativa al streaming en tiempo real es la difusión "fuera de línea" ("off-line", o "en diferido"), que consiste en la grabación de los contenidos in situ a la máxima calidad posible, seguida de su posterior recodificación (para comprimirla) y ulterior subida a un servidor de difusión de contenidos digitales multimedia, desde donde puedan descargarse bajo demanda. Sería aconsejable hacer la subida en franjas horarias en que la red no tenga mucho uso, como la franja entre las 4:00 y las 8:00 am. Esta opción es la más práctica, aunque se reduce la "emoción del directo". Lo ideal sería un punto medio mixto, pero llevando un control cuidadoso de todo el material multimedia que se genera y emite.

	=Opciones=		=Opciones=