martes, febrero 28, 2006
El Mini mac Intel
Después de mucha expectación, hoy Apple presentó un par de productos nuevos.
El primero es un Mac mini basado en Intel, 2500 veces más rápido que el de antes o algo así... Lleva Intel Core, versión Solo y versión Duo según el modelo. Tiene Front Row. A mí me podría interesar algo similar para el salón, pero se empeñan en no ponerle DVR, así que nada.
El otro producto también podría ir en mi salón; es el iPod Hi Fi, una especie de equipo de alta fidelidad para el iPod. El único problema es que el iPod no reproduce mis CDs ni mis DVDs...
El primero es un Mac mini basado en Intel, 2500 veces más rápido que el de antes o algo así... Lleva Intel Core, versión Solo y versión Duo según el modelo. Tiene Front Row. A mí me podría interesar algo similar para el salón, pero se empeñan en no ponerle DVR, así que nada.
El otro producto también podría ir en mi salón; es el iPod Hi Fi, una especie de equipo de alta fidelidad para el iPod. El único problema es que el iPod no reproduce mis CDs ni mis DVDs...
El vídeo del que todo el mundo habla
Ya lo digo yo que este es el año de los vídeos. Algunos parecen tan buenos como si estuvieran hechos por profesionales, como esta parodia sobre Microsoft:
Pero Microsoft también hace buena publicidad, por ejemplo, este anuncio de la XBox 360.
Por cierto, otro producto de Microsoft del que se habla mucho últimamente es Origami y, cómo no, también tiene su vídeo de presentación para que hablemos de él en los blogs:
Pero Microsoft también hace buena publicidad, por ejemplo, este anuncio de la XBox 360.
Por cierto, otro producto de Microsoft del que se habla mucho últimamente es Origami y, cómo no, también tiene su vídeo de presentación para que hablemos de él en los blogs:
domingo, febrero 26, 2006
Seagate compró Maxtor
Pues eso: Seagate compró Maxtor. Ya fue hace un par de meses pero no lo había comentado y si no lo apunto aquí, se me olvidará.
Para el escritorio, ahora sólo se puede escoger entre estos fabricantes: Seagate, Western Digital, Hitachi y Samsung.
Para el escritorio, ahora sólo se puede escoger entre estos fabricantes: Seagate, Western Digital, Hitachi y Samsung.
Los problemas de la PS3
Genial frase de un artículo de Ars Technica sobre la Playstation 3:
Es decir, que el procesador Cell de la Playstation tiene mucho hardware, lo que presupone que tiene mucha potencia, pero hacer software que sea capaz de aprovecharlo es muy difícil. En general, creo que con el freno en la carrera de los megahertzios y el paso a los núcleos dobles y demás es algo que vamos a ver en todos los sitios: si programar ya era difícil con programas secuenciales, con programas paralelos es un orden de magnitud más difícil (al menos).
Estaría bien que hubiera herramientas que paralelizasen por nosotros, compiladores paralelos como intenta ser el Octopiler para la Playstation. Pero, aunque existen y ya desde hace mucho tiempo en ciertos ámbitos, son difíciles de hacer y no producen ni mucho menos código que aproveche totalmente el hardware disponible. Y eso cuando el problema es paralelizable, que no todos lo son.
Lo que dicen en Ars Technica es que a base de investigación igual se llega a conseguir algo bueno... en 10 años. Y la PS3 debería salir este año.
Y eso que dicen en Ars Technica no se metieron con lo verdaramente difícil en un entorno paralelo: depurar.
See, Cell's greatest strength is that there's a lot of hardware on that chip. And Cell's greatest weakness is that there's a lot of hardware on that chip.
Es decir, que el procesador Cell de la Playstation tiene mucho hardware, lo que presupone que tiene mucha potencia, pero hacer software que sea capaz de aprovecharlo es muy difícil. En general, creo que con el freno en la carrera de los megahertzios y el paso a los núcleos dobles y demás es algo que vamos a ver en todos los sitios: si programar ya era difícil con programas secuenciales, con programas paralelos es un orden de magnitud más difícil (al menos).
Estaría bien que hubiera herramientas que paralelizasen por nosotros, compiladores paralelos como intenta ser el Octopiler para la Playstation. Pero, aunque existen y ya desde hace mucho tiempo en ciertos ámbitos, son difíciles de hacer y no producen ni mucho menos código que aproveche totalmente el hardware disponible. Y eso cuando el problema es paralelizable, que no todos lo son.
Lo que dicen en Ars Technica es que a base de investigación igual se llega a conseguir algo bueno... en 10 años. Y la PS3 debería salir este año.
Y eso que dicen en Ars Technica no se metieron con lo verdaramente difícil en un entorno paralelo: depurar.
A Woz no le gusta lo que hace Jobs
Steve Wozniak suele ser representado como un gran ingeniero (muchos consideran suyo el mérito del Apple ][) de buen corazón: se dedica a obras de caridad y no suele criticar a la gente. Sin embargo, en una entrevista reciente que comentan en Ars Technica, cuenta que no le gusta mucho lo que está haciendo Apple en los últimos tiempos.
Para empezar, no le gusta el cambio a Intel. Sus razones:
Es decir, que no le gusta desde el punto de vista moral, aunque tiene claro que Intel tiene mejores diseños últimamente. Yo, la verdad, creo que si con IBM no les iba bien, podían haberse pasado a AMD y hubiesen quedado mejor.
Parece que el iPod tampoco le ilusiona: a él le gusta más que Apple se centre en los ordenadores.
Definitivamente, es un idealista :-)
Actualización: Publican una actualización en Ars Technica en la que Woz dice que no dijo eso, que se lo inventaron los periodistas. Ya decía yo que era conocido por no hacer críticas :-)
Para empezar, no le gusta el cambio a Intel. Sus razones:
"It's like consorting with the enemy. We've had this long history of saying the enemy is the big black-hatted guys, and they kind of represent evil. We are different, and by being different we're better," he said. "All of a sudden we're the same in this hardware regard, so it's a little hard to swallow your words from the past."
"Still, the switch to Intel is a necessary one from an engineering standpoint," he said. "Intel just did a very good logic design. [However] if it wasn't needed, I would say we shouldn't do it. And I still have some questions as to how much it's needed."
Es decir, que no le gusta desde el punto de vista moral, aunque tiene claro que Intel tiene mejores diseños últimamente. Yo, la verdad, creo que si con IBM no les iba bien, podían haberse pasado a AMD y hubiesen quedado mejor.
Parece que el iPod tampoco le ilusiona: a él le gusta más que Apple se centre en los ordenadores.
Definitivamente, es un idealista :-)
Actualización: Publican una actualización en Ars Technica en la que Woz dice que no dijo eso, que se lo inventaron los periodistas. Ya decía yo que era conocido por no hacer críticas :-)
sábado, febrero 25, 2006
Vlogs y vídeo en Flash
Otra entrada más sobre vídeo digital. He descubierto un buen artículo resumiendo el estado de la cuestión sobre vlogs, es decir, video blogs. Desde ahí he llegado a videoblogging.info, un sitio con consejos para hacer vlogs, que me ha proporcionado un enlace de refencia: guía para hacer vídeo en Flash.
Con respecto al vídeo en Flash, el otro día hablé de mis primeras experiencias con YouTube, que al igual que Google utiliza FLV (Flash Video). He intentado ahondar más en el tema. Para empezar, me bajé el vídeo de 25 MB que yo había subido a través de la herramienta de Javi Moya. Me encontré con un fichero .flv de 7 MiB, lo que claramente demuestra que ha habido un proceso de recodificación. Si no me he equivocado en los cálculos, en mi conexión de 640 kbps un archivo de ese tamaño debería bajarse, en el mejor de los casos, en 91.7 segundos, es decir, minuto y medio. Como el vídeo duraba tres minutos, con un pequeño buffer debería ser capaz de verlo en tiempo real, pero no lo he conseguido. Creo que el problema es más del ancho de salida de YouTube que de mi conexión.
El fichero .flv me ha servido para más cosas. En primer lugar, quise reproducirlo. La manera más sencilla que encontré fue utilizar el-reproductor-que-lo-reproduce-todo-sin-bajarte-códecsTM: el VLC. Gracias a su ventana de información descubrí que el vídeo estaba a 320x240, así que creo que no tiene sentido renderizarlo a 400x300 como dije el otro día.
En la página de Macromedia que cité antes aclaran otra duda qué tenía: el códec usado en FLV es On2 VP6 en Flash 8 (Sorenson Spark en Flash 7). Dan unos buenos consejos sobre cómo capturar vídeo de calidad: utilizar un trípode, buena iluminación, buena cámara.. . Tienen también unas buenas prácticas para codificar en FLV y una interesante tabla con configuraciones recomendadas. Me parece también bastante buena la explicación de conceptos básicos de vídeo.
Con respecto al vídeo en Flash, el otro día hablé de mis primeras experiencias con YouTube, que al igual que Google utiliza FLV (Flash Video). He intentado ahondar más en el tema. Para empezar, me bajé el vídeo de 25 MB que yo había subido a través de la herramienta de Javi Moya. Me encontré con un fichero .flv de 7 MiB, lo que claramente demuestra que ha habido un proceso de recodificación. Si no me he equivocado en los cálculos, en mi conexión de 640 kbps un archivo de ese tamaño debería bajarse, en el mejor de los casos, en 91.7 segundos, es decir, minuto y medio. Como el vídeo duraba tres minutos, con un pequeño buffer debería ser capaz de verlo en tiempo real, pero no lo he conseguido. Creo que el problema es más del ancho de salida de YouTube que de mi conexión.
El fichero .flv me ha servido para más cosas. En primer lugar, quise reproducirlo. La manera más sencilla que encontré fue utilizar el-reproductor-que-lo-reproduce-todo-sin-bajarte-códecsTM: el VLC. Gracias a su ventana de información descubrí que el vídeo estaba a 320x240, así que creo que no tiene sentido renderizarlo a 400x300 como dije el otro día.
En la página de Macromedia que cité antes aclaran otra duda qué tenía: el códec usado en FLV es On2 VP6 en Flash 8 (Sorenson Spark en Flash 7). Dan unos buenos consejos sobre cómo capturar vídeo de calidad: utilizar un trípode, buena iluminación, buena cámara.. . Tienen también unas buenas prácticas para codificar en FLV y una interesante tabla con configuraciones recomendadas. Me parece también bastante buena la explicación de conceptos básicos de vídeo.
viernes, febrero 24, 2006
Todo lo que siempre quisiste saber y no te atreviste a preguntar sobre los 64 bits
Por supuesto, la respuesta, en la Wikipedia.
Muchas cosas ya las sabía, pero me parece especialmente interesante la sección Pros and cons. Por ejemplo, yo creía que si no tenías más de 4 GB no ganabas nada con respecto a la capacidad de direccionamiento, pero no es así porque con 32 bits en realidad no puedes tener 4 GB de RAM reales porque parte del espacio de direcciones está reservado para el sistema operativo, así que se te acaban las direcciones antes.
La mayor desventaja de los 64 bits es que los datos y las instrucciones pueden ocupar más en memoria (por el tamaño de los punteros y por aspectos de alineamiento), lo que tiene consecuencias sobre la cantidad de memoria principal requerida y sobre los fallos de caché... Pero, como explican en Ars Technica, hacen trampa: no utilizan todo de 64 bits, sino que mezclan datos de distinto tamaño, así que no tiene por qué haber esta penalización más que cuando sea necesario.
Muchas cosas ya las sabía, pero me parece especialmente interesante la sección Pros and cons. Por ejemplo, yo creía que si no tenías más de 4 GB no ganabas nada con respecto a la capacidad de direccionamiento, pero no es así porque con 32 bits en realidad no puedes tener 4 GB de RAM reales porque parte del espacio de direcciones está reservado para el sistema operativo, así que se te acaban las direcciones antes.
La mayor desventaja de los 64 bits es que los datos y las instrucciones pueden ocupar más en memoria (por el tamaño de los punteros y por aspectos de alineamiento), lo que tiene consecuencias sobre la cantidad de memoria principal requerida y sobre los fallos de caché... Pero, como explican en Ars Technica, hacen trampa: no utilizan todo de 64 bits, sino que mezclan datos de distinto tamaño, así que no tiene por qué haber esta penalización más que cuando sea necesario.
jueves, febrero 23, 2006
Las CPUs de AMD en el 2006
El otro día hice un resumen del estado de la situación en Intel y hoy voy a comentar un poco AMD.
Estoy leyendo la madre de todas las comparativas en su apartado dedicado a AMD. Lo primero que cuenta es que AMD ha tenido problemas con los chipsets. Ella no se dedica a fabricarlos, así que cuando salen al mercado no están tan bien probados como los de Intel, aunque con el tiempo se van puliendo los detalles. En cualquier caso, destacan claramente a nVidia como el mejor fabricante de chipsets para AMD.
Luego hablan de los problemas de nomenclatura. Si con Intel el problema es que hay demasiados nombres, con AMD el problema es que hay pocos: existen procesadores con el mismo nombre que son distintos. Por ejemplo, el Athlon 64 3500+ lo puede haber con y sin extensiones SSE3 y con núcleo de 90 nm o de 130. Las diferencias entre uno y otro son significativas en cuanto a rendimiento y consumo. La solución que han adoptado los fabricantes es poner el nombre del núcleo al lado del modelo. En el mismo artículo hay una tabla con un resumen de núcleos y características.
Destacan los datos que dan de disipación. En las CPUs de 90 nm midieron que a plena carga disipaban 31.4 W y cuando se activaba la tecnología Cool'n'Quiet (el equivalente al SpeedStep de Intel) bajaba hasta 3.2 W. Impresionante.
Con respecto a los dual-core de AMD, una de las grandes diferencias con su máximo competidor es que, como comentaba el otro día, Intel tuvo que bajar la frecuencia para meter dos cores en un chip sin que se quemasen, mientras que AMD pudo mantener la frecuencia en su versión de doble núcleo. Estas versiones del procesador se llaman Athlon 64 X2.
Según Tom's Hardware, estas CPUs son mejores en rendimiento que las de Intel, en gran parte debido a que integran el controlador de memoria en el propio chip mediante la tecnología Hyper Transport. También su consumo, 110 W, es menor: un 15% de ventaja frente a Intel.
En la rama performance, donde se encuentran los procesadores caros para jugones, también AMD ofrece mejor rendimiento que Intel.
En resumen, la comparativa pone mucho mejor a AMD en casi todo, aunque falta la compración con el Intel Core Duo y con las versiones de 65 nm (el CedarMill).
Por otra parte, el artículo no habla de portátiles. En esa línea, AMD tiene el Turion 64, que es el procesador pensado para competir con el Pentium M. Funciona sobre socket 754, pero se espera que este año salga un nuevo socket, el S.
Por cierto, en cuanto a sockets, AMD tiene la versión 754 en plan barato y la 939 en verisón cara. En la Wikipedia analizan las diferencias. La más destacada es que el 754 no permite dual channel. En la entrada del socket 939, ponen esta lista de sockets de AMD en orden cronológico: A, 754, 939, 940 (para Opterons y Athlon 64-FX), AM2 y F. Según comentan en la entrada del socket AM2, el socket S1 será la versión del AM2 para móviles y el F, para servidores.
Por cierto, acabo de ver que hace dos días Tom's Hardware sacó un artículo sobre el socket AM2. Dicen que el paso a DDR2 (que AMD de momento parece que no soporta) no va a hacer que se gane mucho «because the integrated memory controller suffers more from relaxed memory timings than it can gain from speeding up clock speed via DDR2».
Pero creo que el análisis de la situación de la memoria lo voy a dejar para otro día...
Estoy leyendo la madre de todas las comparativas en su apartado dedicado a AMD. Lo primero que cuenta es que AMD ha tenido problemas con los chipsets. Ella no se dedica a fabricarlos, así que cuando salen al mercado no están tan bien probados como los de Intel, aunque con el tiempo se van puliendo los detalles. En cualquier caso, destacan claramente a nVidia como el mejor fabricante de chipsets para AMD.
Luego hablan de los problemas de nomenclatura. Si con Intel el problema es que hay demasiados nombres, con AMD el problema es que hay pocos: existen procesadores con el mismo nombre que son distintos. Por ejemplo, el Athlon 64 3500+ lo puede haber con y sin extensiones SSE3 y con núcleo de 90 nm o de 130. Las diferencias entre uno y otro son significativas en cuanto a rendimiento y consumo. La solución que han adoptado los fabricantes es poner el nombre del núcleo al lado del modelo. En el mismo artículo hay una tabla con un resumen de núcleos y características.
Destacan los datos que dan de disipación. En las CPUs de 90 nm midieron que a plena carga disipaban 31.4 W y cuando se activaba la tecnología Cool'n'Quiet (el equivalente al SpeedStep de Intel) bajaba hasta 3.2 W. Impresionante.
Con respecto a los dual-core de AMD, una de las grandes diferencias con su máximo competidor es que, como comentaba el otro día, Intel tuvo que bajar la frecuencia para meter dos cores en un chip sin que se quemasen, mientras que AMD pudo mantener la frecuencia en su versión de doble núcleo. Estas versiones del procesador se llaman Athlon 64 X2.
Según Tom's Hardware, estas CPUs son mejores en rendimiento que las de Intel, en gran parte debido a que integran el controlador de memoria en el propio chip mediante la tecnología Hyper Transport. También su consumo, 110 W, es menor: un 15% de ventaja frente a Intel.
En la rama performance, donde se encuentran los procesadores caros para jugones, también AMD ofrece mejor rendimiento que Intel.
En resumen, la comparativa pone mucho mejor a AMD en casi todo, aunque falta la compración con el Intel Core Duo y con las versiones de 65 nm (el CedarMill).
Por otra parte, el artículo no habla de portátiles. En esa línea, AMD tiene el Turion 64, que es el procesador pensado para competir con el Pentium M. Funciona sobre socket 754, pero se espera que este año salga un nuevo socket, el S.
Por cierto, en cuanto a sockets, AMD tiene la versión 754 en plan barato y la 939 en verisón cara. En la Wikipedia analizan las diferencias. La más destacada es que el 754 no permite dual channel. En la entrada del socket 939, ponen esta lista de sockets de AMD en orden cronológico: A, 754, 939, 940 (para Opterons y Athlon 64-FX), AM2 y F. Según comentan en la entrada del socket AM2, el socket S1 será la versión del AM2 para móviles y el F, para servidores.
Por cierto, acabo de ver que hace dos días Tom's Hardware sacó un artículo sobre el socket AM2. Dicen que el paso a DDR2 (que AMD de momento parece que no soporta) no va a hacer que se gane mucho «because the integrated memory controller suffers more from relaxed memory timings than it can gain from speeding up clock speed via DDR2».
Pero creo que el análisis de la situación de la memoria lo voy a dejar para otro día...
lunes, febrero 20, 2006
Historia reciente de las CPUs de Intel
Estoy intentando hacerme un esquema de los modelos de procesadores que tiene Intel en la actualidad. Desde que cambió al sistema de numeración, estoy hecho un lío, así que voy a ir escribiendo según voy leyendo y buscando por la web a ver si me aclaro. Cualquier corrección será bienvenida.
Todo empezó con el Pentium 4... Bueno, el 4 indica que debe de ser la cuarta parte, pero en estos tiempos de precuelas nunca se sabe. El caso es que hasta el Pentium 4 todo iba más o menos claro: Tenían la rama Pentium 4 para procesadores mainstream, la rama Pentium M para portátiles y la rama Celeron como versión barata. Tocaron techo con los megaherztios e introdujeron el sistema de números de modelo.
Para el socket 478 servían los Pentium 4 con core Northwood o su sucesor, Prescott. Prescott también lo hay con versión para el nuevo socket, el 775, en el que funcionan todos los procesadores modernos hasta el Core, que utiliza FCPGA6 (de 478 pines).
En el sistema de números, las distintas series van más o menos así:
El repuesto del Pentium 4 tiene como nombre en código Conroe y es una arquitectura totalmente nueva.
Enlaces fundamentales:
Y ahora, un comentario personal porque no me puedo aguantar: ya podían haber sido más claros con los nombrecitos estos de Intel. El colmo de los colmos llamar a los procesadores «Core», es decir, núcleo. ¿Qué pasa, que quisieron copiar a Microsoft para quien su Word Processor es simplemente el «Word»?
Actualización: En un artículo de hace tres días de Ars Technica cuentan el futuro de la arquitectura Intel y también se lían con el nombre. No saben cómo llamarla: si Conroe, Merom o NGA (Next Generation Architecture). Intel parece que prefiere este último nombre, siendo Conroe y Merom dos ejemplos de chips que implementan la arquitectura, uno para ordenadores de escritorio y otro para portátiles, respectivamente.
Todo empezó con el Pentium 4... Bueno, el 4 indica que debe de ser la cuarta parte, pero en estos tiempos de precuelas nunca se sabe. El caso es que hasta el Pentium 4 todo iba más o menos claro: Tenían la rama Pentium 4 para procesadores mainstream, la rama Pentium M para portátiles y la rama Celeron como versión barata. Tocaron techo con los megaherztios e introdujeron el sistema de números de modelo.
Para el socket 478 servían los Pentium 4 con core Northwood o su sucesor, Prescott. Prescott también lo hay con versión para el nuevo socket, el 775, en el que funcionan todos los procesadores modernos hasta el Core, que utiliza FCPGA6 (de 478 pines).
En el sistema de números, las distintas series van más o menos así:
- Celeron D Serie 3xx: FSB a 133 MHz QDR. El núcleo es Prescott.
- Celeron M Serie 3xx: FSB a 100 MHz QDR. El núcleo es el de un Pentium M (Banias o Dothan) pero sin SpeedStep y con la mitad de caché, con lo que la batería dura menos.
- Pentium 4 Serie 5xx: FSB a 200 MHz QDR. El núcleo es Prescott.
- Pentium 4 Serie 6xx: FSB a 200 MHz QDR. El núcleo es Prescott 2M (el 2M viene de que tienen 2MB de caché, pero con mayor latencia, con lo que se gana poco). Las versiones 6x1 y 6x3 utilizan otro núcleo, llamado CedarMill, que es básicamente un Prescott en 65 nm en lugar de los 90 nm habituales.
- Pentium D Serie 8xx: FSB a 200 MHz QDR. El núcleo es Smithfield, que no es más que dos Prescott con frecuencias más bajas, uno al lado del otro. Consume unos 155 vatios gracias a que utilizan frecuencias más bajas (un Prescott a frecuencias normales consume unos 115 W).
- Pentium M Serie 7xx: FSB a 133 MHz QDR (los 7x0) o 100 MHz QDR (el resto). Los 7x5 utilizan core Dothan de 90 nm (sucesor del Banias de 130 nm). Los 7x8 son versiones con menos frecuencia y de bajo voltaje, con lo que se gana autonomía. Los 7x3 tienen decrementan todavía más la frecuencia y el voltaje y aumentan la autonomía. Los 7x0 son los sucesores del Dothan, llamados Sonoma, con el aumento del FSB a 133 MHz QDR.
- Pentium D Serie 9xx: Versión en 65 nm de los 8xx.
- Intel Core Duo serie T2xxx: FSB a 166 MHz QDR. Es el sucesor del Pentium M y es doble núcleo. El primer núcleo es el Yonah, fabricado con 65 nm. Es el que utilizan los primeros ordenadores de Apple con procesador Intel. No tiene EM64T, pero se espera que su sucesor, Merom, lo tenga.
- Intel Core Duo serie L2xxx: Versión de baja tensión y frecuencia de la T2xxx.
- Intel Core Solo serie T1xxx: FSB a 166 MHz QDR. Versión de un núcleo del Duo.
El repuesto del Pentium 4 tiene como nombre en código Conroe y es una arquitectura totalmente nueva.
Enlaces fundamentales:
- La Wikipedia. Perfecta explicación histórica del Pentium 4, el Pentium M, el Celeron y el Core.
- La madre de todas las gráficas de CPUs en Tom's Hardware.
- Información de Intel. Se ven claramente tres ramas: la Pentium 4/M, la Core y la Xeon.
Y ahora, un comentario personal porque no me puedo aguantar: ya podían haber sido más claros con los nombrecitos estos de Intel. El colmo de los colmos llamar a los procesadores «Core», es decir, núcleo. ¿Qué pasa, que quisieron copiar a Microsoft para quien su Word Processor es simplemente el «Word»?
Actualización: En un artículo de hace tres días de Ars Technica cuentan el futuro de la arquitectura Intel y también se lían con el nombre. No saben cómo llamarla: si Conroe, Merom o NGA (Next Generation Architecture). Intel parece que prefiere este último nombre, siendo Conroe y Merom dos ejemplos de chips que implementan la arquitectura, uno para ordenadores de escritorio y otro para portátiles, respectivamente.
domingo, febrero 19, 2006
Configuración de vídeos en YouTube
Dije hace poco que este va a ser el año del video y, cómo no, ya me ha tocado probarlo.
Lo primero fue escoger dónde subirlo. Las dos opciones que valoré, por ser las más conocidos, fueron Google Video y YouTube. Hay muchas más, como se puede ver en esta comparativa.
Resumiendo: Google Video tiene la ventaja de que puedes descargarte los vídeos para verlos off-line (también con YouTube, pero haciendo trucos) y la desventaja de que los vídeos tardan un tiempo desde que los subes hasta que están listos para verse, ya que pasan un proceso de revisión, se supone que para evitar material con copyright.
Me decidí por YouTube más que nada porque parece más social (deja poner comentarios) y más usado. Me registré, contesté al correo de confirmación y me dispuse a subir el primer vídeo.
El proceso de subida es fácil y cómodo: rellenas un formulario sencillo y esperas. Lo que esperas depende de tu conexión y de la longitud del vídeo, lógicamente, pero con las conexiones asimétricas que tenemos el común de los mortales (españoles), lo normal es esperar mucho. El vídeo acabó subiendo en algo menos de una hora sin problemas.
Pero me gusta hacer las cosas bien, o al menos saber si las estoy haciendo bien. Así que me puse a buscar cuál era la configuración óptima para subir vídeos a YouTube. Mi Google-fu debe de estar en horas bajas porque no encontré ningún sitio en el que lo describieran.
La configuración que escogí finalmente fue:
- 400x300 de resolución porque esa es la con la que se muestran por defecto los vídeos de YouTube. Actualización: Después de investigar más descubrí que la configuración real es 320x240.
- DivX con un bitrate medio de 1000 Mbps.
- El sonido comprimido en MP3 a 160 Kbps.
- El vídeo provenía de una cámara MiniDV PAL, pero en la herramienta que usé para editarlo, Vegas Video, tuve que escoger a la hora de renderizar utilizar una proporción de pixel 1.0 en lugar de la típica de PAL (1.0296) porque, si no, me salían unas rayas negras por los lados. Actualización: También puse el vídeo como progresivo en lugar de entrelezado.
Para mi vídeo de tres minutos, y tras tres pasadas, acabé con unos 25 megas y una calidad aceptable. Pero sigo con la duda de si será la mejor configuración...
Actualización: He estado pensando (y ahora, por la falta de costumbre, tengo una luxación en mi neurona) que 25 megas en tres minutos significa 1165.1 kbps. Por eso a los que tenemos una conexión de 640 kbps se nos para el vídeo y no podemos verlo en tiempo real. Habría que bajar la calidad, pero ya está al límite de lo aceptable.
Actualización 2: En realidad hay una recompresión del vídeo a FLV y lo que te bajas acaba ocupando 7 MiB, con lo que para mi vídeo de 25 MB sólo se necesitan 326.2 kbps. Más datos en la entrada sobre vídeo en flash.
Lo primero fue escoger dónde subirlo. Las dos opciones que valoré, por ser las más conocidos, fueron Google Video y YouTube. Hay muchas más, como se puede ver en esta comparativa.
Resumiendo: Google Video tiene la ventaja de que puedes descargarte los vídeos para verlos off-line (también con YouTube, pero haciendo trucos) y la desventaja de que los vídeos tardan un tiempo desde que los subes hasta que están listos para verse, ya que pasan un proceso de revisión, se supone que para evitar material con copyright.
Me decidí por YouTube más que nada porque parece más social (deja poner comentarios) y más usado. Me registré, contesté al correo de confirmación y me dispuse a subir el primer vídeo.
El proceso de subida es fácil y cómodo: rellenas un formulario sencillo y esperas. Lo que esperas depende de tu conexión y de la longitud del vídeo, lógicamente, pero con las conexiones asimétricas que tenemos el común de los mortales (españoles), lo normal es esperar mucho. El vídeo acabó subiendo en algo menos de una hora sin problemas.
Pero me gusta hacer las cosas bien, o al menos saber si las estoy haciendo bien. Así que me puse a buscar cuál era la configuración óptima para subir vídeos a YouTube. Mi Google-fu debe de estar en horas bajas porque no encontré ningún sitio en el que lo describieran.
La configuración que escogí finalmente fue:
- 400x300 de resolución porque esa es la con la que se muestran por defecto los vídeos de YouTube. Actualización: Después de investigar más descubrí que la configuración real es 320x240.
- DivX con un bitrate medio de 1000 Mbps.
- El sonido comprimido en MP3 a 160 Kbps.
- El vídeo provenía de una cámara MiniDV PAL, pero en la herramienta que usé para editarlo, Vegas Video, tuve que escoger a la hora de renderizar utilizar una proporción de pixel 1.0 en lugar de la típica de PAL (1.0296) porque, si no, me salían unas rayas negras por los lados. Actualización: También puse el vídeo como progresivo en lugar de entrelezado.
Para mi vídeo de tres minutos, y tras tres pasadas, acabé con unos 25 megas y una calidad aceptable. Pero sigo con la duda de si será la mejor configuración...
Actualización: He estado pensando (y ahora, por la falta de costumbre, tengo una luxación en mi neurona) que 25 megas en tres minutos significa 1165.1 kbps. Por eso a los que tenemos una conexión de 640 kbps se nos para el vídeo y no podemos verlo en tiempo real. Habría que bajar la calidad, pero ya está al límite de lo aceptable.
Actualización 2: En realidad hay una recompresión del vídeo a FLV y lo que te bajas acaba ocupando 7 MiB, con lo que para mi vídeo de 25 MB sólo se necesitan 326.2 kbps. Más datos en la entrada sobre vídeo en flash.
Contra los frameworks
Una divertida entrada contra los frameworks. Dice la gente que es contra los frameworks en Java, que en Ruby molan mucho. Yo ni sé ni contesto, pero me interesa la comparación de framework con librería (o biblioteca) que da el mismo autor de la entrada pero en los comentarios:
También es muy buena esta cita:
The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library.
A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.
A library is something *contained* within my code.
A framework is a *container* for my application.
También es muy buena esta cita:
Any computing problem can be solved by adding another level of abstraction—except the problem of having too many layers of abstraction.
Comparación de sistemas de almacenamiento de ficheros
Una interesante comparación de sistemas de almacenamiento de ficheros en Internet tipo YouSendIt, que es tal vez el más famoso. Hay un más de 50, con los límites de tamaño, número de descargas y duración. ¿Cuál es vuestro favorito?
Vía Ruf, que a ver si se abre un blog para poder enlazarlo :-)
Vía Ruf, que a ver si se abre un blog para poder enlazarlo :-)
viernes, febrero 17, 2006
Hacia el ordenador de salón
Llevo tiempo con ganas de iniciar una serie sobre cómo montar un ordenador de salón, pero tengo más preguntas que respuestas y me da miedo empezar y no acabar. De todas formas, no quería dejar de poner este gran enlace que encontrado hoy: Kubycsystem: la primera página en español dedicada al mundo del HTPC. Es justo lo que andaba buscando: un sitio con experiencias con este tipo de ordenadores.
Por ejemplo, un detalle que acabo de leer y que me ha llamado la atención: cómo reducir el ruido del reproductor de CD/DVD:
Por ejemplo, un detalle que acabo de leer y que me ha llamado la atención: cómo reducir el ruido del reproductor de CD/DVD:
El ruido de un lector de DVD o CDROM se reduce considerablemente con programas que bajen la velocidad de giro del lector, por ejemplo Drivespeed o una utilidad de Ahead que se instala junto con el Nero, el Nero Drivespeed. Tanto en lector de CD o disco duro, al girar a menos revoluciones, leen a menos velocidad, no obstante, para usos normales de reproduccion de peliculas, no es perceptible esa merma en la velocidad.
jueves, febrero 16, 2006
Historia visual de los discos duros
Vía Microsiervos, una historia de los discos duros con fotos.
Cestas de fruta para Google
Gran artículo de Cory Doctorow explicando por qué las editoriales deberían enviar cestas de fruta a Google. Una cita:
Me parece una justificación al menos muy original de la importancia del aspecto social más que del contenido que hay en mucho seguimiento cultural.
Any overland commuter train has is dominated by phone-conversations, with readers in an ever-dwindling minority.
It's easy to see why: content isn't king; conversation is. If you had the choice of bringing your friends or your books to a desert island, we'd call you a sociopath if you took the books over the breathing humans.
Me parece una justificación al menos muy original de la importancia del aspecto social más que del contenido que hay en mucho seguimiento cultural.
viernes, febrero 03, 2006
del.icio.us (que aproveche)
Yo también he caído en la fiebre de las etiquetas. Aunque hace siglos que empecé a escuchar a mucha gente cantando las alabanzas de del.icio.us, he tardado bastante en hacerme una cuenta. Al principio tampoco la utilicé mucho, pero últimamente estoy enganchado, en especial desde que he descubierto la extensión oficial para Firefox, que permite tanto meter como utilizar bookmarks con mucha facilidad. Es un ejemplo de aplicación bien hecha.
Por si queda alguien en el mundo mundial sin convencer, aquí van mis dos razones para usar del.icio.us:
1. Puedes compartir tus favoritos fácilmente entre varios ordenadores.
2. Puedes encontrar cosas muy interesantes navegando por las etiquetas de otra gente.
Como ejemplo de esto último, hoy me ha dado por mirar lo más popular de la etiqueta bestof y he encontrado cosas muy interesantes, como un framework para CSS. Y ya digo que es casi tan cómodo como el menú bookmarks del navegador.
Por si queda alguien en el mundo mundial sin convencer, aquí van mis dos razones para usar del.icio.us:
1. Puedes compartir tus favoritos fácilmente entre varios ordenadores.
2. Puedes encontrar cosas muy interesantes navegando por las etiquetas de otra gente.
Como ejemplo de esto último, hoy me ha dado por mirar lo más popular de la etiqueta bestof y he encontrado cosas muy interesantes, como un framework para CSS. Y ya digo que es casi tan cómodo como el menú bookmarks del navegador.
miércoles, febrero 01, 2006
µTorrent: Pequeño pero matón
Sé que a algunos jovenzuelos les parecen leyendas, mitos inventados por viejos que no se acostumbran a utilizar el Messenger ni a escribir sin vocales y con ca en vez de cu. Pero es verdad: hubo un tiempo en el que había programas tremendos que cabían en 64K, o en 32 o incluso en 16.
Ahora, a poco que te descuides, en esos tamaños no cabe ni la pantalla de splash del programa más inútil. Por eso asombra encontrarse con algo como µTorrent, un cliente para BitTorrent que ocupa 130K y, sin embargo, no le falta ninguna característica ni tiene una interfaz fea. Estoy totalmente impresionado.
Lo leí en «Can great software live in 130 kilobytes?». Hasta hoy, yo utilizaba Linux para los torrents. En Windows había probado Azureus pero no me había convencido: se me quedaban a la mitad los ficheros o algo así, ya no lo recuerdo. Ahora no cambio µTorrent ni por diez cajas de Ariel ;-) (¿Seguirán echando en la tele los míticos anuncios de detergentes que coindieron en el tiempo con los ordenadores de 8 bits?)
Por cierto, que sigo prefiriendo el eMule para P2P, por la facilidad para buscar, pero para algunas cosas BitTorrent va mucho más rápido: lo que antes tardaba un día y pico en bajar ahora me baja en dos horas, aprovechando casi desde el principio todo mi ancho de banda. Lo he probado, por ejemplo, con Facade, un juego gratis que recomendaban en un artículo sobre juegos diferentes en Wired.
También utilizan µTorrent en esta explicación sobre cómo enviar ficheros por BitTorrent. No es del todo cómodo, pero con un cliente tan fácil de usar y de instalar (al ejecutarlo por primera vez te pregunta si quieres crear los iconos y asociar los archivos y ya está) como µTorrent, además de la demo interactiva de la página enlazada, puede ser una solución para intercambiar esos archivos que son demasiado grandes para el correo electrónico. Y no, el Messenger no es una alternativa válida.
Ahora, a poco que te descuides, en esos tamaños no cabe ni la pantalla de splash del programa más inútil. Por eso asombra encontrarse con algo como µTorrent, un cliente para BitTorrent que ocupa 130K y, sin embargo, no le falta ninguna característica ni tiene una interfaz fea. Estoy totalmente impresionado.
Lo leí en «Can great software live in 130 kilobytes?». Hasta hoy, yo utilizaba Linux para los torrents. En Windows había probado Azureus pero no me había convencido: se me quedaban a la mitad los ficheros o algo así, ya no lo recuerdo. Ahora no cambio µTorrent ni por diez cajas de Ariel ;-) (¿Seguirán echando en la tele los míticos anuncios de detergentes que coindieron en el tiempo con los ordenadores de 8 bits?)
Por cierto, que sigo prefiriendo el eMule para P2P, por la facilidad para buscar, pero para algunas cosas BitTorrent va mucho más rápido: lo que antes tardaba un día y pico en bajar ahora me baja en dos horas, aprovechando casi desde el principio todo mi ancho de banda. Lo he probado, por ejemplo, con Facade, un juego gratis que recomendaban en un artículo sobre juegos diferentes en Wired.
También utilizan µTorrent en esta explicación sobre cómo enviar ficheros por BitTorrent. No es del todo cómodo, pero con un cliente tan fácil de usar y de instalar (al ejecutarlo por primera vez te pregunta si quieres crear los iconos y asociar los archivos y ya está) como µTorrent, además de la demo interactiva de la página enlazada, puede ser una solución para intercambiar esos archivos que son demasiado grandes para el correo electrónico. Y no, el Messenger no es una alternativa válida.
