El Mon, 21 Dec 2009 10:20:29 -0300, Gabriel escribió:

2009/12/21 Carlos E. R.:

...

Así que cuando me digas envio esos cinco trozos por correo. O si alguien sabe de algún sitio similar a picpaste que admita videos (o zips), pues que lo diga y pruebo.

http://www.4shared.com/ =P

Añado: http://www.sendspace.com/ Y para que nos añadan a la "Lista de Sinde [1]", los típicos "rebeldes" P-) http://www.megaupload.com/ http://www.rapidshare.com/ [1] http://lalistadesinde.net/ Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-21 14:20, Gabriel wrote:

2009/12/21 Carlos E. R. :

...

Así que cuando me digas envio esos cinco trozos por correo. O si alguien sabe de algún sitio similar a picpaste que admita videos (o zips), pues que lo diga y pruebo.

http://www.4shared.com/ =P

¡Gracias! :-) Vale, lo he puesto en http://www.4shared.com/file/178023986/bcaa1b11/test_audio.html Pero hay otro problema peor, culpa del corte. Hay algo horrible con el cortado, que aunque el mpeg se ve bien, al convertirlo a avi no se puede ver con xine (foto fija) y el mplayer protesta mucho. No se que rayos pasa. Necesito una herramienta que no sea avidemux que permita extraer un trozo de un fichero mpeg sin alterarlo, para poder hacer las pruebas de audio con ese trocito nada más. No usar el fichero que he enviado, tiene que estar mal. Que fastidio, ¡es que es un problema detrás de otro! :-/ - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksviRIACgkQU92UU+smfQWCmACgh7g5VeJCzyMQleKRrzDYBIr5 Fe8AnR/dEy3HkEgvZNB8J4XoRHhmUmXM =YsT5 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-21 a las 15:35 -0000, Camaleón escribió:

El Mon, 21 Dec 2009 15:41:22 +0100, Carlos E. R. escribió:

...

Necesito una herramienta que no sea avidemux que permita extraer un trozo de un fichero mpeg sin alterarlo, para poder hacer las pruebas de audio con ese trocito nada más.

¿Aún estás "asín"? :-)

-ss 00:08:00 -t 00:00:60

Para que empiece a grabar en el minuto 8 y que grabe 60 segundos.

Lo sé, pero no, no vale. No vale porque el ffmpeg recodifica, no copia. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksvo30ACgkQtTMYHG2NR9WshwCePAJg1vvPhmrybwmiGohqBrAy YA0An2UsjX+quGxc+HdR7b1Sf+f1+LJT =Hc35 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-12-21 a las 17:12 -0000, Camaleón escribió:

El Mon, 21 Dec 2009 17:34:00 +0100, Carlos E. R. escribió:

...

El 2009-12-21 a las 15:35 -0000, Camaleón escribió:

...

...

...

Necesito una herramienta que no sea avidemux que permita extraer un trozo de un fichero mpeg sin alterarlo, para poder hacer las pruebas de audio con ese trocito nada más.

¿Aún estás "asín"? :-)

-ss 00:08:00 -t 00:00:60

Para que empiece a grabar en el minuto 8 y que grabe 60 segundos.

Lo sé, pero no, no vale. No vale porque el ffmpeg recodifica, no copia.

Dile que "copie", tanto el vídeo como el audio :-)

-vcodec copy -acodec copy

Ya me sé las opciones de memoria :-P

Ahhhh... Fale. <=:-) [...] De acuerdo, hecho. Ya he generado el trozo correctamente hecho con el salto de sonido en mpeg, unos 90 segundos, y el trozo convertido a avi, que muestra el desfase del audio, en el segundo 16. Voy a subirlos. [...] Vale, el mpeg está aqui: http://www.4shared.com/file/178257073/34032292/corte_problematicompeg.html - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksv5NsACgkQtTMYHG2NR9UUswCfRxE56q8lIkjk8dyqdl29PGeN evQAn1sOGnttIUbt31HMjL9ut9VA21t2 =Ey4S -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-12-21 a las 23:34 -0300, Alfredo Jesús Delaiti escribió:

...

De acuerdo, hecho. Ya he generado el trozo correctamente hecho con el salto de sonido en mpeg, unos 90 segundos, y el trozo convertido a avi, que muestra el desfase del audio, en el segundo 16.

Yo no me doy cuenta que haya desface, o eres muy sensible a este tipo de falla o el corte que has subido esta bien. Creo que 0,5 segundos de diferencia entre imagen y sonido lo tendría que notar con facilidad.

El retardo aparece unicamente en el avi generado a partir de ese mpeg, por ejemplo con ffmpeg. Tienes que generar el avi, o lo subo yo. Lo voy a subir. [...] http://www.4shared.com/file/178697906/5a98d442/corte_problematico_destino.ht... El problema es generar ese avi sin el retardo en la segunda mitad. A ser posible de manera automática. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkswuOwACgkQtTMYHG2NR9U00gCfQ5kUdeu6iFX1mbSrf8IP9i1i +PkAnjuEwlayRuAjKcqt1Kw0kp6//5aW =15rh -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-22 a las 09:30 -0300, Alfredo Jesús Delaiti escribió:

El 22/12/09 09:17, Carlos E. R. escribió:

...

http://www.4shared.com/file/178697906/5a98d442/corte_problematico_destino.ht...

El problema es generar ese avi sin el retardo en la segunda mitad. A ser posible de manera automática.

Ahora entiendo. Voy a analizar el formato de salida de lo que has puesto ahora y tratare de reproducirlo en mi máquina a partir del trozo que se supone bueno.

Al fin... Gracias :-) Es que hasta ahora no tenía máquina suficiente para hacer estas conversiones, soy nuevo en esto. Y me sorprende que exista este problema. O el flujo no tiene marcas de tiempo, o se procesan mal. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkswvrMACgkQtTMYHG2NR9VxqACgg5WC0om29/Y7pOaz+ubSAPFg be8AnifWNgZ2Aw+K8q/P/6md7CdqNUyC =f49Z -----END PGP SIGNATURE-----

El Tue, 22 Dec 2009 13:17:43 +0100, Carlos E. R. escribió:

El 2009-12-21 a las 23:34 -0300, Alfredo Jesús Delaiti escribió:

...

...

De acuerdo, hecho. Ya he generado el trozo correctamente hecho con el salto de sonido en mpeg, unos 90 segundos, y el trozo convertido a avi, que muestra el desfase del audio, en el segundo 16.

Yo no me doy cuenta que haya desface, o eres muy sensible a este tipo de falla o el corte que has subido esta bien. Creo que 0,5 segundos de diferencia entre imagen y sonido lo tendría que notar con facilidad.

El retardo aparece unicamente en el avi generado a partir de ese mpeg, por ejemplo con ffmpeg. Tienes que generar el avi, o lo subo yo.

Lo voy a subir.

[...]

<http://www.4shared.com/file/178697906/5a98d442/ corte_problematico_destino.html>

El problema es generar ese avi sin el retardo en la segunda mitad. A ser posible de manera automática.

-async 1 Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Martes, 22 de Diciembre de 2009 18:54:37 Carlos E. R. escribió:

El 2009-12-22 a las 15:49 -0000, Camaleón escribió:

...

El Tue, 22 Dec 2009 13:17:43 +0100, Carlos E. R. escribió:

...

<http://www.4shared.com/file/178697906/5a98d442/

corte_problematico_destino.html>

...

El problema es generar ese avi sin el retardo en la segunda mitad. A ser posible de manera automática.

-async 1

¿Huh? [...man...] ¡Ah! [...]

¡¡ BBBB I N N GG OO !! ¡¡ B B I NN N G O O !! ¡¡ BBBB I N N N GGGG O O !! ¡¡ B B I N NN G G O O !! ¡¡ BBBB I N N GG OO !!

Ostras, ¡funciona! ¡YIIAAAJUUUU!

Pues lo leí, sin darme cuenta de su significado. Caray... ¿Como te has dado cuenta?

-async samples_per_second

Audio sync method. "Stretches/squeezes" the audio stream to match the timestamps, the parameter is the maximum samples per second by which the audio is changed. -async 1 is a special case where only the start of the audio stream is corrected without any later correction.

Fíjate que pensé que al decir que altera sólo el principio no iba a funcionar, porque el error se produce en el centro.

-copyts Copy timestamps from input to output.

He probado también -copyts, no va. Y, por curiosidad, con -acodec copy (con la idea de no alterar el sonido), pero claro, entonces no puede alterar el flujo y no corrige el error. Y comprime menos.

También me llama la atención esto otro:

-dts_delta_threshold Timestamp discontinuity delta threshold.

Estas cosas necesitan que las expliquen un poco más, poner ejemplos, caray... desde luego, muchos programadores son malos escritores de documentación. Se ganan la fama a pulso.

Te equivocas, casi todos los programadores ODIAN escribir documentación. Al fin y al cabo, el codigo es autoexplicativo. :-)

Ahora tendré que probarlo con dos canales de audio, y grabarlo en un llavero usb para ver si el reproductor del salón traga, antes de convertir mi pequeña colección.

¡Gracias!

-- Saludos Lluis

El día 22 de diciembre de 2009 15:56, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-22 a las 19:20 +0100, Lluis escribió:

...

On Martes, 22 de Diciembre de 2009 18:54:37 Carlos E. R. escribió:

...

...

...

Estas cosas necesitan que las expliquen un poco más, poner ejemplos, caray... desde luego, muchos programadores son malos escritores de documentación. Se ganan la fama a pulso.

Te equivocas, casi todos los programadores ODIAN escribir documentación. Al fin y al cabo, el codigo es autoexplicativo. :-)

X'-)

¡Te vi'a dar!

Despues de tantas idas y vueltas, conseguiste un archivo avi mas chico que el mpeg2 original? Como hiciste? Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 22 de diciembre de 2009 22:17, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-22 a las 19:21 -0300, Juan Erbes escribió:

...

El día 22 de diciembre de 2009 15:56, Carlos E. R. <> escribió:

...

Despues de tantas idas y vueltas, conseguiste un archivo avi mas chico que el mpeg2 original?

Sí, eso sí, desde el principio.

...

Como hiciste?

Pues tengo dos posibilidades: codificar a avi con mpeg-4, que lo hace bien y con mucha calidad, pero sólo puedo ver en el ordenador, o con codec xvid que tarda casi el triple, pero puedo ver en el salón.

Acabo de poner los detalles y la linea de comandos en otro correo hace un minuto. Pero para aclarlo un poco más:

mpeg-4 (default):

 ffmpeg -threads 4 -i ENTRADA.mpeg    -ss "00:09:30.000" -t "90"    -async 1    -qscale 1 -croptop 122 -cropbottom 108 -aspect 720:346    SALIDA.avi -newaudio

xvid (vídeo) y MPEG-1 Layer 3 (sonido):

 ffmpeg -threads 4 -i ENTRADA.mpeg    -ss "00:09:30.000" -t "90"    -async 1    -vcodec libxvid -acodec libmp3lame    -qscale 2    -croptop 122 -cropbottom 108 -aspect 720:346    SALIDA.avi -newaudio

Esa es la codificación habitual de los vídeos que se encuentran por "ahí", por cierto, aunque con un sólo canal de audio. Sin especificar codec de audio saca mpeg Layer 1, que encima ocupa un poco menos.

Porque lo recortas tanto de abajo y de arriba?. Te está quedando en una relación > 2:1, (ancho:alto), cuando los monitores HD, tienen una relación < 2:1 (16:9). Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 23 de diciembre de 2009 09:10, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-23 a las 08:41 -0300, Juan Erbes escribió:

...

...

Porque lo recortas tanto de abajo y de arriba?. Te está quedando en una relación > 2:1, (ancho:alto), cuando los monitores HD, tienen una relación < 2:1 (16:9).

Pues porque la peli viene así, en realidad. Viene en tres cuartos, pero con unas bandas negras arriba y abajo grandes, que es inútil grabarlas. Así se me visualiza más grande en el monitor de 16:9 que si lo dejo como viene.

Créeme, no le estoy quitando nada de imagen, yo en eso soy maniático. En tiempos fuí proyeccionista de cine amateur (35mm, lámpara de arco), y tenía mucho cuidado de respetar el formato, y de proyectar hasta el último rótulo sin luces >:-)

Mi televisor del salón, 16/9, relativamente pequeño para lo que venden, lo tengo puesto en automático: eso quiere decir que veo casi todas las cadenas con bandas negras a izquierda y derecha, en formato tres cuartos. Odio ver los televisores con una programación de tres cuartos ensanchada a toda la pantalla, y la gente con unos caretos enormes. Pero claro, la gente, sobre todo las tiendas, quieren presumir de pantalla grande y no quieren ver zonas negras. Absurdo.

Yo lo tengo en automático, y cuando doy con un programa que transmite en 16:9, se me llena la pantalla, como debe ser.

Yo tengo un monitor de 24" para el decodificador/vdr hdtv, pero como la tarjeta de captura no tiene entrada hdmi (aunque soporte hdtv), solamente puedo entrar por la entrada de video compuesto + sonido estereo y me permite grabar en calidad video dvd. Como el video es para otra persona, lo dejo en la relación 4:3, como viene. Como el microprocesador tiene 3 nucleos, cambié a -threads 3. Esta es la captura de pantalla: ffmpeg -threads 3 -i entrada.mpg -async 1 -vcodec libxvid -acodec libmp3lame -qscale 2 salida.avi -newaudioFFmpeg version UNKNOWN, Copyright (c) 2000-2009 Fabrice Bellard, et al. built on Dec 15 2009 22:35:29 with gcc 4.4.1 [gcc-4_4-branch revision 150839] configuration: --shlibdir=/usr/lib --prefix=/usr --mandir=/usr/share/man --libdir=/usr/lib --enable-shared --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libfaad --enable-libfaac --enable-nonfree --enable-libxvid --enable-postproc --enable-gpl --enable-x11grab --enable-libschroedinger --enable-libdirac --enable-libgsm --enable-version3 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libdc1394 --enable-pthreads libavutil 50. 5. 1 / 50. 5. 1 libavcodec 52.43. 0 / 52.43. 0 libavformat 52.41. 0 / 52.41. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0. 7. 2 / 0. 7. 2 libpostproc 51. 2. 0 / 51. 2. 0 [mpeg @ 0x807bb20]max_analyze_duration reached Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001) Input #0, mpeg, from 'entrada.mpg': Duration: 01:55:02.29, start: 0.254544, bitrate: 4975 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3], 8000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, 2 channels, s16, 224 kb/s Output #0, avi, to 'salida.avi': Stream #0.0: Video: libxvid, yuv420p, 720x480 [PAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc Stream #0.1: Audio: libmp3lame, 48000 Hz, 2 channels, s16, 64 kb/s Stream #0.2: Audio: mp2, 48000 Hz, 2 channels, s16, 64 kb/s Stream mapping: Stream #0.0 -> #0.0 Stream #0.1 -> #0.1 Stream #0.1 -> #0.2 Press [q] to stop encoding frame=49394 fps= 21 q=2.0 size= 1351803kB time=1647.82 bitrate=6720.4kbits/s Que valores te da la ultima linea? A mi me da esos valores, un una temperatura del micro de 42ºC, a la maxima velocidad 2,6 GHz, y una utilización promedio del 50% global de cpu (3 nucleos). Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-26 17:47, Juan Erbes wrote:

El día 23 de diciembre de 2009 09:10, Carlos E. R. <> escribió:

Sin recortar el tamaño de la imagen, con cualquiera de los 2 metodos, me da archivos mas grandes.

Con xvid (vídeo) y MPEG-1 Layer 3 (sonido), cuando el archivo original pesaba 4 GB, y duraba 1 hora 55 minutos, el avi convertido cuando pesaba 4,1 GB, la duración era de 1 hora 26 minutos, y directamente corté el proceso.

Con mpeg-4, también me da archivos mas grandes: El archivo mpeg original, pesaba 522 MB, y el resultante es de 715 MB.

Sí, he observado que a veces el tamaño no se reduce o aumenta. Si estás jugando con -qscale, hay que aumentar su valor. Supongo que es porque ha salido con un bitrate mayor que el del original. Hay que hacer pruebas con todos los ficheros que vayas a convertir. No te puedes fiar y usar siempre el mismo comando, por lo menos con ffmpeg. Creo que incluso aunque todas las películas vengan del mismo aparato (tdt), hay variaciones según que emisora es y que película es. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks2qPYACgkQU92UU+smfQUV7gCcDIPwppXvoJEzJ0/txdS53eMe NikAnidKlaHcxa41hcQa7V+siYvJseRt =g3rx -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-27 a las 08:48 -0300, Juan Erbes escribió:

El día 26 de diciembre de 2009 21:23, Carlos E. R. <> escribió:

...

Sí, he observado que a veces el tamaño no se reduce o aumenta. Si estás jugando con -qscale, hay que aumentar su valor. Supongo que es porque ha salido con un bitrate mayor que el del original.

Supones mal:

Input #0, mpeg, from 'entrada.mpg': Duration: 01:55:02.29, start: 0.254544, bitrate: 4975 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3], 8000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, 2 channels, s16, 224 kb/s

Output #0, avi, to 'salida.avi': Stream #0.0: Video: libxvid, yuv420p, 720x480 [PAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc

Lo raro, es que en la entrada aparecen 2 valores: bitrate: 4975 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3], 8000 kb/s

En la salida dice 200 kb/s, pero por lo visto.

Podrían ser los 8000 kb/s, que es mucho.

...

Hay que hacer pruebas con todos los ficheros que vayas a convertir. No te puedes fiar y usar siempre el mismo comando, por lo menos con ffmpeg. Creo que incluso aunque todas las películas vengan del mismo aparato (tdt), hay variaciones según que emisora es y que película es.

Por allí estube leyendo: DivX is a digital video compression format based on the MPEG-4

O sea, que ponerlo en divx, o mpeg-4, no hace a la diferencia, y eso lo vi en el tamaño de los archivos de entrada/salida, e incluso, en la velocidad de conversión, para divx, me convertía a razón de 21 fps, mientras que en mpeg4, lo hacía a 121 fps, nada menos que 6 veces mas rapido. estaba en la duda, de que pueda haber tomado la parte final de los titulos, pero no, lo volvi a lanzar, y ahora me promediaba los 130 fps (arrancó en casi 150).

Si tiene diferencia. Aunque esté "basado en" no significa que sean iguales. Posiblemente sea una mejora. Y, teniendo en cuenta que gasta mucha más cpu al comprimir, no pueden ser iguales.

En ambos casos, el tamaño de salida es el mismo 720x480, salvo la calidad, que en mpeg4 es 1, y en divx es 2.

La cuestión es que si con qscale 1 o 2 no te comprime bastante, tienes que aumentar a 3 o 4. O más si lo necesitas. Comprimes primero un trozo de unos dos minutos, y observas el resultado.

En tu caso, es posible que hallas logrado reducir el tamaño, porque estabas recortando el tamaño, pero como yo lo tengo que dejar en 4:3, y el formato "original" es 16:9, quedaría totalmente deformado, si lo recortaba de abajo y de arriba.

La diferencia de tamaño que obtengo quitando o no quitando las franjas negras es pequeña. Es "negro", foto fija, se comprime una barbaridad, y no afecta casi al tamaño total. Vamos a ver, siempre que haya franjas negras tienes que quitarlas. Eso es por narices. Independientemente de donde se vaya a reproducir. Si el aparato donde se vaya a ver es de 3/4, eso no tiene importancia alguna: es responsabilidad de ese aparato de ampliar la imagen sólo hasta que los bordes de la imagen tocan el borde de la pantalla, dejando el resto con franjas negras. Si el aparato lo que hace es ampliar una imagen de 16/9 hasta los bordes superior e inferior, sin dejar franjas negras, y sacando fuera de la pantalla los bordes laterales, es que ese aparato está mal configurado.

Acabo de lanzarlo nuevamente para mpeg4 con qscale 3:

Stream mapping: Stream #0.0 -> #0.0 Stream #0.1 -> #0.1 Stream #0.1 -> #0.2 Press [q] to stop encoding frame= 5565 fps=124 q=3.0 size= 63220kB time=185.69 bitrate=2789.1kbits/s

Ahora si, logré un tamaño ligeramente inferior: de 534 MB a 509 MB. Pero lo que acabo de observar, es que en los objetos en movimiento, aparece un "serrucho" en sus bordes.

Al reducir la calidad, pues claro, se notan cosas... esos son probablemente los "motion filters" que dice Camaleón. Son fáciles de ver en el avidemux; aquí, como son opciones de linea de comandos, son más difíciles de encontrar. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks3T+AACgkQtTMYHG2NR9VCLwCglU1J015H/rYsMCaU6fPkH6+s 8/sAnjqNI7yyW7A+Vg7FUD4Uzl2mHD+F =e8zE -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-12-27 a las 08:56 -0300, Juan Erbes escribió:

Me olvidaba:

Que tdt tienes tú?

Ya lo he comentado otras veces, un Gigaset (Siemens) "customizado" para Carrefour, el último que les quedaba y rebajado, modelo M740AV. En el foro han comentado que van a sacar otro cacharro "oyendo" las peticiones de los usuarios, incluyendo la de que sea "cacharreable". Me pone los dientes largos. El mio tiene dos sintonizadores, y el disco duro es externo y opcional. También puede grabar en el ordenador mediante samba. El disco externo es una pega y una ventaja: la transferencia de ficheros por ethernet es lenta (no usa toda la banda), por lo que desenchufo el disco y se lo pongo al ordenador.

Ahh!. a nivel del micro, a cuantos grados por encima de la temperatura ambiente se te pone?

No lo he mirado. La proxima vez que lo intente lo miro, pero teniendo en cuenta que es invierno, y que no ocupa el 100% de la CPU (la tengo puesta creo que es en modo "governor", poca). Está al 70% de frecuencia. Luego lo miro, ahora está apagada.

Cuantos fps te da a 720x480? (ya te puse los vaores mios 121 a 130 fps)

Tendré que mirarlo. ¿No lo puse hace unos correos? [...] Sí, alrededor de 68 en mpeg (qscale 1) y 26 en xvid (qscale 2), para un trozo de 90 segs. mpeg frame= 2247 fps= 68 q=2.0 Lsize= 18699kB time=90.00 bitrate=1702.1kbits/s video:17049kB audio:1406kB global headers:0kB muxing overhead 1.320397% xvid frame= 2247 fps= 26 q=2.0 Lsize= 20318kB time=90.00 bitrate=1849.4kbits/s video:18668kB audio:1406kB global headers:0kB muxing overhead 1.213710%

A mi, con 27ºC de temp. ambiente, el micro se va a 34ºC, con una carga promedio del 50%, pero con la velocidad al maximo, 2,6 GHz.

Todavía no sé porque no sube la ocupación al 100% durante el proceso. Debe haber un freno. ¿Disco? Tampoco va al máximo... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks3Uy8ACgkQtTMYHG2NR9ULHwCbBrDR5x4X3DZlSSnjqauO7axe y98An01XSYjtxfA710w+EkhG8IzGQGF3 =9+Nn -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-27 23:07, Juan Erbes wrote:

El día 27 de diciembre de 2009 09:29, Carlos E. R. <> escribió:

...

Todavía no sé porque no sube la ocupación al 100% durante el proceso. Debe haber un freno. ¿Disco? Tampoco va al máximo...

En mi caso, no vi que tenga acceso a disco al maximo. A mi modo de ver, el problema es de acceso a memoria, que en el caso de mi equipo, usa 3 nucleos el micro, com memoria DDR3.

No, tampoco es ese el problema. Me puse a convertir simultaneamente 4 peliculas, sin threading, y fué a toda pastilla, la cpu al 100% cada nucleo, y mantenidos. Es algo del propio proceso, no está optimizado. Ese es el truco, como tengo directorios con varias peliculas, hacer un script e ir convirtiendo de cuatro en cuatro al mismo tiempo.

En el caso tuyo, que micro y memoria tienes?

Intel Q9550 @ 2.83GHz. La memoria es ddr3 también. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks4C4kACgkQU92UU+smfQWwTgCfehbZ4xz3AmG4k3YNnwnfFb17 Ws0An2qf13wBbthClApXdJm7C98K5clS =VwYm -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 28 de diciembre de 2009 20:41, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-28 a las 02:36 +0100, Carlos E. R. escribió:

...

On 2009-12-27 23:07, Juan Erbes wrote:

...

El día 27 de diciembre de 2009 09:29, Carlos E. R. <> escribió:

...

...

Todavía no sé porque no sube la ocupación al 100% durante el proceso. Debe haber un freno. ¿Disco? Tampoco va al máximo...

En mi caso, no vi que tenga acceso a disco al maximo. A mi modo de ver, el problema es de acceso a memoria, que en el caso de mi equipo, usa 3 nucleos el micro, com memoria DDR3.

No, tampoco es ese el problema. Me puse a convertir simultaneamente 4 peliculas, sin threading, y fué  a toda pastilla, la cpu al 100% cada nucleo, y mantenidos. Es algo del propio proceso, no está optimizado.

Hipótesis: supongamos que usa un thread para el códec de vídeo, y otro para el sonido. De vez en cuando espera a que estén los trozos terminados y juntarlos. Y esas esperas reducen el rendimiento.

En cambio, al no usar threads, y en cambio procesar varias películas simultáneamente, el rendimiento sube una barbaridad.

Cuantos fps te da en ese caso? (por cada core). Si no me equivoco, el tuyo es de 4 cores, y el mio es de 3, pero sin embargo, de mpeg2 a mpeg4, el mio rinde el doble que el tuyo. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 29 de diciembre de 2009 11:21, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-28 a las 21:24 -0300, Juan Erbes escribió:

...

El día 28 de diciembre de 2009 20:41, Carlos E. R. <> escribió:

...

...

Hipótesis: supongamos que usa un thread para el códec de vídeo, y otro para el sonido. De vez en cuando espera a que estén los trozos terminados y juntarlos. Y esas esperas reducen el rendimiento.

En cambio, al no usar threads, y en cambio procesar varias películas simultáneamente, el rendimiento sube una barbaridad.

Cuantos fps te da en ese caso? (por cada core).

No lo he apuntado, pero no se puede saber los fps por core. Se puede saber los fps por pelicula simultanea. Bastante más alto que en modo threaded con una sola pelicula.

...

Si no me equivoco, el tuyo es de 4 cores, y el mio es de 3, pero sin embargo, de mpeg2 a mpeg4, el mio rinde el doble que el tuyo.

La cifra que puse era para xvid. Para mpeg4, en modo 4 threads, una sola pelicula, oscila entre 200 y 300 fps, con picos de 400.

Pero sin embargo, segun el texto que pegaste previamente, para xvid, te daba 26 fps y para mpeg4, te daba 68 fps, en modo 4 threads, una sola pelicula. Si revisas el hilo, verás lo que pusiste. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-29 17:01, Carlos E. R. wrote:

El 2009-12-29 a las 12:04 -0300, Juan Erbes escribió:

...

...

La cifra que puse era para xvid. Para mpeg4, en modo 4 threads, una sola pelicula, oscila entre 200 y 300 fps, con picos de 400.

...

Pero sin embargo, segun el texto que pegaste previamente, para xvid, te daba 26 fps y para mpeg4, te daba 68 fps, en modo 4 threads, una sola pelicula.

...

Si revisas el hilo, verás lo que pusiste.

Varía mucho. Los ultimos que he hecho, que son los que recuerdo, rondan los 200..300 fps.

A ver, he lanzado cuatro pruebas simultaneas: #!/bin/bash TH="-threads 4" PARAMETROS="-async 1 -t 90 -croptop 62 -cropbottom 58 -aspect "774:456"" CLASS=".mpeg" X=1 #PARAMETROS="-async 1 -t 90 -vcodec libxvid -acodec libmp3lame -croptop 62 -cropbottom 58 -aspect "774:456"" #CLASS=".xvid" #X=2 rm "Los 4400 T3E07 (20090926).$X$CLASS.avi" "Los 4400 T3E11 (20090927-1).$X$CLASS.avi" \ "Los 4400 T3E10 (20090927-2).$X$CLASS.avi" "Los 4400 T3E12 (20090928-3).$X$CLASS.avi" xterm -hold -e time ffmpeg -threads 4 -i "Los 4400 T3E07 (20090926).m2p.mpeg" \ -qscale $X $PARAMETROS \ "Los 4400 T3E07 (20090926).$X$CLASS.avi" -newaudio & xterm -hold -e time ffmpeg -threads 4 -i "Los 4400 T3E11 (20090927-1).m2p.mpeg" \ -qscale $X $PARAMETROS \ "Los 4400 T3E11 (20090927-1).$X$CLASS.avi" -newaudio & xterm -hold -e time ffmpeg -threads 4 -i "Los 4400 T3E10 (20090927-2).m2p.mpeg" \ -qscale $X $PARAMETROS \ "Los 4400 T3E10 (20090927-2).$X$CLASS.avi" -newaudio & xterm -hold -e time ffmpeg -threads 4 -i "Los 4400 T3E12 (20090928-3).m2p.mpeg" \ -qscale $X $PARAMETROS \ "Los 4400 T3E12 (20090928-3).$X$CLASS.avi" -newaudio & De esta manera tengo acceso a la salida de los cuatro comandos independientemente: frame= 2247 fps=195 q=1.0 Lsize= 28705kB time=90.00 bitrate=2612.8kbits/s video:27054kB audio:1407kB global headers:0kB muxing overhead 0.857291% 10.87user 0.48system 0:11.55elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 64000inputs+57456outputs (0major+3715minor)pagefaults 0swaps frame= 2239 fps=223 q=1.0 Lsize= 19981kB time=90.00 bitrate=1818.7kbits/s video:18330kB audio:1407kB global headers:0kB muxing overhead 1.235914% 9.37user 0.25system 0:10.08elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 50688inputs+40008outputs (0major+3987minor)pagefaults 0swaps frame= 2247 fps=220 q=1.0 Lsize= 19561kB time=90.00 bitrate=1780.5kbits/s video:17910kB audio:1407kB global headers:0kB muxing overhead 1.263241% 9.45user 0.34system 0:10.27elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 53248inputs+39168outputs (0major+3989minor)pagefaults 0swaps frame= 2248 fps=224 q=1.0 Lsize= 17958kB time=90.00 bitrate=1634.5kbits/s video:16307kB audio:1407kB global headers:0kB muxing overhead 1.377218% 9.33user 0.30system 0:10.14elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 52736inputs+35960outputs (0major+3631minor)pagefaults 0swaps Tengo una sospecha, repito una segunda vez. frame= 2248 fps=236 q=1.0 Lsize= 17958kB time=90.00 bitrate=1634.5kbits/s video:16307kB audio:1407kB global headers:0kB muxing overhead 1.377218% 9.26user 0.25system 0:09.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+35960outputs (0major+3631minor)pagefaults 0swaps frame= 2247 fps=204 q=1.0 Lsize= 28705kB time=90.00 bitrate=2612.8kbits/s video:27054kB audio:1407kB global headers:0kB muxing overhead 0.857291% 10.99user 0.24system 0:11.04elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+57456outputs (0major+3715minor)pagefaults 0swaps frame= 2239 fps=234 q=1.0 Lsize= 19981kB time=90.00 bitrate=1818.7kbits/s video:18330kB audio:1407kB global headers:0kB muxing overhead 1.235914% 9.29user 0.23system 0:09.59elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+40016outputs (0major+3986minor)pagefaults 0swaps frame= 2247 fps=232 q=1.0 Lsize= 19561kB time=90.00 bitrate=1780.5kbits/s video:17910kB audio:1407kB global headers:0kB muxing overhead 1.263241% 9.39user 0.23system 0:09.84elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+39168outputs (0major+3989minor)pagefaults 0swaps La diferencia son los "0input", los trozos de fichero de entrada están en el caché del kernel. Si la I/O del disco influyera, se notaría ahora. Y sí, parece que se nota un poquito. No es seguro. Repito sin "-threads", mpeg4 frame= 2247 fps=211 q=1.0 Lsize= 28636kB time=90.00 bitrate=2606.5kbits/s video:26986kB audio:1407kB global headers:0kB muxing overhead 0.859380% 10.32user 0.12system 0:10.77elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+57312outputs (0major+3469minor)pagefaults 0swaps frame= 2239 fps=243 q=1.0 Lsize= 19939kB time=90.00 bitrate=1814.9kbits/s video:18288kB audio:1407kB global headers:0kB muxing overhead 1.238670% 9.00user 0.11system 0:09.26elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+39928outputs (0major+3738minor)pagefaults 0swaps frame= 2247 fps=240 q=1.0 Lsize= 19508kB time=90.00 bitrate=1775.6kbits/s video:17857kB audio:1407kB global headers:0kB muxing overhead 1.267024% 9.12user 0.11system 0:09.39elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+39056outputs (0major+3747minor)pagefaults 0swaps frame= 2248 fps=241 q=1.0 Lsize= 17901kB time=90.00 bitrate=1629.3kbits/s video:16250kB audio:1407kB global headers:0kB muxing overhead 1.381670% 9.08user 0.12system 0:09.37elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+35856outputs (0major+3366minor)pagefaults 0swaps Son valores similares. Ahora pruebo con xvid; Calidad 2, no 1, porque la "1" es buggy. frame= 2250 fps=126 q=2.0 Lsize= 18378kB time=90.14 bitrate=1670.2kbits/s video:16726kB audio:1408kB global headers:0kB muxing overhead 1.346665% 16.83user 0.17system 0:17.86elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+36808outputs (0major+4824minor)pagefaults 0swaps frame= 2250 fps=122 q=2.0 Lsize= 29715kB time=90.14 bitrate=2700.4kbits/s video:28063kB audio:1408kB global headers:0kB muxing overhead 0.828653% 18.14user 0.15system 0:18.43elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+59464outputs (0major+4901minor)pagefaults 0swaps frame= 2253 fps=130 q=2.0 Lsize= 20183kB time=90.14 bitrate=1834.2kbits/s video:18530kB audio:1408kB global headers:0kB muxing overhead 1.225577% 16.94user 0.15system 0:17.38elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+40408outputs (0major+5159minor)pagefaults 0swaps frame= 2244 fps=125 q=2.0 Lsize= 20669kB time=90.14 bitrate=1878.4kbits/s video:19017kB audio:1408kB global headers:0kB muxing overhead 1.195947% 16.83user 0.22system 0:17.95elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+41384outputs (0major+5191minor)pagefaults 0swaps Y ahora, xvid con threads (y los cuatro procesos simultáneos, cuatro películas distintas): frame= 2250 fps= 16 q=2.0 Lsize= 18378kB time=90.14 bitrate=1670.2kbits/s video:16726kB audio:1408kB global headers:0kB muxing overhead 1.346665% 20.02user 102.32system 2:23.15elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+36976outputs (0major+4955minor)pagefaults 0swaps frame= 2253 fps= 16 q=2.0 Lsize= 20183kB time=90.14 bitrate=1834.2kbits/s video:18530kB audio:1408kB global headers:0kB muxing overhead 1.225577% 20.28user 98.86system 2:24.37elapsed 82%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+40584outputs (0major+5300minor)pagefaults 0swaps frame= 2250 fps= 15 q=2.0 Lsize= 29715kB time=90.14 bitrate=2700.4kbits/s video:28063kB audio:1408kB global headers:0kB muxing overhead 0.828653% 21.18user 110.36system 2:26.60elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+59648outputs (0major+5058minor)pagefaults 0swaps frame= 2244 fps= 16 q=2.0 Lsize= 20669kB time=90.14 bitrate=1878.4kbits/s video:19017kB audio:1408kB global headers:0kB muxing overhead 1.195947% 20.02user 102.29system 2:22.82elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+41560outputs (0major+5320minor)pagefaults 0swaps ¡Mucho más lento con threads activados (xvid)! Por cierto: la salida de "time" no es la habitual, porque se trata de "/usr/bin/time", no del comando interno de la shell. Ahora toca probar con calidad 6 (sin threads), que comprime mucho más. Mpeg primero: frame= 2247 fps=263 q=6.0 Lsize= 10063kB time=90.00 bitrate= 915.9kbits/s video:8412kB audio:1407kB global headers:0kB muxing overhead 2.485006% 8.29user 0.07system 0:08.62elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+20128outputs (0major+3336minor)pagefaults 0swaps frame= 2239 fps=290 q=6.0 Lsize= 8007kB time=90.00 bitrate= 728.9kbits/s video:6357kB audio:1407kB global headers:0kB muxing overhead 3.142656% 7.60user 0.07system 0:07.79elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+16016outputs (0major+3667minor)pagefaults 0swaps frame= 2248 fps=281 q=6.0 Lsize= 7510kB time=90.00 bitrate= 683.5kbits/s video:5859kB audio:1407kB global headers:0kB muxing overhead 3.357390% 7.74user 0.09system 0:08.04elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+15024outputs (0major+3320minor)pagefaults 0swaps frame= 2247 fps=287 q=6.0 Lsize= 7872kB time=90.00 bitrate= 716.5kbits/s video:6221kB audio:1407kB global headers:0kB muxing overhead 3.199792% 7.76user 0.07system 0:07.86elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+15744outputs (0major+3677minor)pagefaults 0swaps Aumenta la velocidad... curioso. Veamos con xvid. frame= 2250 fps=132 q=6.0 Lsize= 7138kB time=90.14 bitrate= 648.7kbits/s video:5486kB audio:1408kB global headers:0kB muxing overhead 3.542451% 16.47user 0.11system 0:17.08elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+14280outputs (0major+4739minor)pagefaults 0swaps frame= 2244 fps=134 q=6.0 Lsize= 7956kB time=90.14 bitrate= 723.0kbits/s video:6303kB audio:1408kB global headers:0kB muxing overhead 3.167059% 16.56user 0.10system 0:16.86elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+15920outputs (0major+5104minor)pagefaults 0swaps frame= 2253 fps=128 q=6.0 Lsize= 7796kB time=90.14 bitrate= 708.5kbits/s video:6144kB audio:1408kB global headers:0kB muxing overhead 3.235942% 16.91user 0.11system 0:17.69elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+15600outputs (0major+5090minor)pagefaults 0swaps frame= 2250 fps=129 q=6.0 Lsize= 10072kB time=90.14 bitrate= 915.3kbits/s video:8419kB audio:1408kB global headers:0kB muxing overhead 2.485036% 17.40user 0.11system 0:17.53elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+20152outputs (0major+4763minor)pagefaults 0swaps Un poquito mejor. Conclusión: el modo "threaded" empeora considerablemente la velocidad de conversión xvid. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks6d+4ACgkQU92UU+smfQX9ZgCfS+wT+2cLuQb5bCQG9mZXwHKb z/wAn35O349J+ckt3rQpyc8aiwpLwNhO =r2JA -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-30 a las 09:30 +0100, Rafa Grimán escribió:

Hola :)

On Tuesday 29 December 2009 22:43:10 Carlos E. R. wrote:

...

On 2009-12-29 17:01, Carlos E. R. wrote:

...

El 2009-12-29 a las 12:04 -0300, Juan Erbes escribió:

[...]

...

Conclusión: el modo "threaded" empeora considerablemente la velocidad de conversión xvid.

¿Has probado a desactivar el SMT o HyperThreading o como lo llame Intel? Se hace desde la BIOS.

Lo pregunto porque he visto en demos de la propia Intel que hay veces que el tenerlo activado no es del todo bueno. También lo he visto en pruebas realizadas por nosotros en determinadas aplicaciones HPC.

Interesante. A ver si me acuerdo de mirarlo. Pero ten en cuenta que sí veo mejora con esa aplicación generando mpeg4. Según el códec que elijas, se usa una librería u otra, que creo desarrolladas por diferentes equipos. Y en los foros se comenta precisamente que libxvid va lenta incluso en modo threaded. Que sólo separan un hilo para el video, otro para el sonido, y otro para la multiplexación. Si fuera una aplicación realmente paralelizada, el vídeo se dividiría en varios hilos. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks7Yu8ACgkQtTMYHG2NR9VGKgCeNUCirxpwNtdcbKHUeilnjUnY gGQAoJMEIGgfreuQM6dMkY8oh5UCzmHQ =HTlB -----END PGP SIGNATURE-----

El día 30 de diciembre de 2009 12:34, Juan Erbes escribió:

El día 30 de diciembre de 2009 11:25, Carlos E. R. escribió:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-30 a las 09:30 +0100, Rafa Grimán escribió:

...

Hola :)

On Tuesday 29 December 2009 22:43:10 Carlos E. R. wrote:

...

On 2009-12-29 17:01, Carlos E. R. wrote:

...

El 2009-12-29 a las 12:04 -0300, Juan Erbes escribió:

[...]

...

Conclusión: el modo "threaded" empeora considerablemente la velocidad de  conversión xvid.

¿Has probado a desactivar el SMT o HyperThreading o como lo llame Intel? Se hace desde la BIOS.

Lo pregunto porque he visto en demos de la propia Intel que hay veces que el tenerlo activado no es del todo bueno. También lo he visto en pruebas realizadas por nosotros en determinadas aplicaciones HPC.

Interesante. A ver si me acuerdo de mirarlo.

Pero ten en cuenta que sí veo mejora con esa aplicación generando mpeg4. Según el códec que elijas, se usa una librería u otra, que creo desarrolladas por diferentes equipos. Y en los foros se comenta precisamente que libxvid va lenta incluso en modo threaded. Que sólo separan un hilo para el video, otro para el sonido, y otro para la multiplexación. Si fuera una aplicación realmente paralelizada, el vídeo se dividiría en varios hilos.

Lastima que en Linux no tengamos ningun software de codigo abierto para hacer esa conversión mediante ATI Stream o Nvidia Cuda:

http://foros.3dgames.com.ar/hardware.31/493181.respuesta-ati-cuda-ati-stream...

http://www.pcper.com/article.php?aid=745

Bueno, al menos del lado de ATI, publicaron el sdk 2.0 con OpenCL 1.0 para Opensuse y ubuntu hace menos de 10 dias: http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx#five Hacen falta los programadores, que desarrollen las aplicaciones de conversión, usando esa tecnología. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 30 de diciembre de 2009 13:33, Rafa Grimán escribió:

Hola :)

On Wednesday 30 December 2009 16:44:18 Juan Erbes wrote:

...

El d�a 30 de diciembre de 2009 12:34, Juan Erbes escribi�:

...

El d�a 30 de diciembre de 2009 11:25, Carlos E. R.

escribi�:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-30 a las 09:30 +0100, Rafa Grim�n escribi�:

...

Hola :)

On Tuesday 29 December 2009 22:43:10 Carlos E. R. wrote:

...

On 2009-12-29 17:01, Carlos E. R. wrote: > El 2009-12-29 a las 12:04 -0300, Juan Erbes escribi�:

[...]

...

Conclusi�n: el modo "threaded" empeora considerablemente la velocidad de �conversi�n xvid.

�Has probado a desactivar el SMT o HyperThreading o como lo llame Intel? Se hace desde la BIOS.

Lo pregunto porque he visto en demos de la propia Intel que hay veces que el tenerlo activado no es del todo bueno. Tambi�n lo he visto en pruebas realizadas por nosotros en determinadas aplicaciones HPC.

Interesante. A ver si me acuerdo de mirarlo.

Pero ten en cuenta que s� veo mejora con esa aplicaci�n generando mpeg4. Seg�n el c�dec que elijas, se usa una librer�a u otra, que creo desarrolladas por diferentes equipos. Y en los foros se comenta precisamente que libxvid va lenta incluso en modo threaded. Que s�lo separan un hilo para el video, otro para el sonido, y otro para la multiplexaci�n. Si fuera una aplicaci�n realmente paralelizada, el v�deo se dividir�a en varios hilos.

Lastima que en Linux no tengamos ningun software de codigo abierto para hacer esa conversi�n mediante ATI Stream o Nvidia Cuda:

http://foros.3dgames.com.ar/hardware.31/493181.respuesta-ati-cuda-ati-str eam-computing.html

http://www.pcper.com/article.php?aid=745

Bueno, al menos del lado de ATI, publicaron el sdk 2.0 con OpenCL 1.0 para Opensuse y ubuntu hace menos de 10 dias: http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx#five

Cierto, es una pena que las GPGPUs no se estén tomando más ne serio ... es cuestión de tiempo ;)

Tanto STREAM de ATI como CUDA/Tesla de NVIDIA son buenas tecnologías siempre y cuando las aplicaciones que vayas a portar tengan instrucciones SIMD. Además de eso, hace falta tener las herramientas de desarrollo: librerías, compiladores, ...

Hoy por hoy, esta tecnología está en su infancia y aún queda. Cada vez hay más aplicaciones que están adoptando esta tecnología:

       http://www.nvidia.com/object/cuda_home.html

       http://www.amd.com/us/products/technologies/stream- technology/commercial/Pages/partners.aspx

       http://developer.amd.com/samples/streamshowcase/Pages/default.aspx

Pero no es "main stream".

...

Hacen falta los programadores, que desarrollen las aplicaciones de conversi�n, usando esa tecnolog�a.

Efectivamente, pero he visto que en algunas Universidades se imparten cursos de programación de GPGPUs. A ver con qué nos sorprenden las nuevas generaciones ;)

En todo caso, tanto Intel como AMD dijeron que su meta era que la GPGPU fuera parte del socket. Es decir, que fuera un "core más". Según los roadmaps publicados de Intel, es lo que va a empezar a hacer con Westmere y continuar desde allí.

Ya, ya sé que Westmere lo que incluye es un core gráfico, no realmente una GPGPU, pero desde allí avanzar ese core gráfico para convertirlo en una GPGPU, es decir, el famoso proyecto Larrabee. Ya veremos lo que saldrá.

Esto deja a NVIDIA cojo porque tanto AMD como Intel tienen su CPU y GPU.

Si, y además, tanto AMD como Intel, la están dejando afuera a Nvidia con el tema de los chipsets para los mobos. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Wednesday 06 January 2010 21:07:25 Alfredo Jesús Delaiti wrote:

Hola

...

...

Ya, ya sé que Westmere lo que incluye es un core gráfico, no realmente una GPGPU, pero desde allí avanzar ese core gráfico para convertirlo en una GPGPU, es decir, el famoso proyecto Larrabee. Ya veremos lo que saldrá.

Esto deja a NVIDIA cojo porque tanto AMD como Intel tienen su CPU y GPU.

Si, y además, tanto AMD como Intel, la están dejando afuera a Nvidia con el tema de los chipsets para los mobos.

Lo que van a lograr es que Nvidia se alíe con VIA o IBM o Motorola o ... y saquen un competidor fuerte en CPU+GPU y les terminen tomando buena parte del mercado :-D

Todo puede ser, puede ser...

Saludos,

Alfredo

¿Por que no ARM? ;) Produce procesadores para móviles y también tiene productos para netbooks. O pueden dedicarse a vender su capital intelectual y dejar de lado la fabricación de tarjetas. AMD se dividió en 2, ¿no? una parte hace investigación y la otra se encarga de poner musculo en la fabricación, y cualquiera le puede contratar. (Si es que recuerdo bien lo que leí hace tiempo). Las empresas se tienen que reinventar si quieren sobrevivir, ya paso, pasa y seguirá pasando. ;) -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 30 de diciembre de 2009 13:33, Rafa Grimán escribió:

Hola :)

On Wednesday 30 December 2009 16:44:18 Juan Erbes wrote:

...

El d�a 30 de diciembre de 2009 12:34, Juan Erbes escribi�:

...

El d�a 30 de diciembre de 2009 11:25, Carlos E. R.

escribi�:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2009-12-30 a las 09:30 +0100, Rafa Grim�n escribi�:

...

Hola :)

On Tuesday 29 December 2009 22:43:10 Carlos E. R. wrote:

...

On 2009-12-29 17:01, Carlos E. R. wrote: > El 2009-12-29 a las 12:04 -0300, Juan Erbes escribi�:

[...]

...

Conclusi�n: el modo "threaded" empeora considerablemente la velocidad de �conversi�n xvid.

�Has probado a desactivar el SMT o HyperThreading o como lo llame Intel? Se hace desde la BIOS.

Lo pregunto porque he visto en demos de la propia Intel que hay veces que el tenerlo activado no es del todo bueno. Tambi�n lo he visto en pruebas realizadas por nosotros en determinadas aplicaciones HPC.

Interesante. A ver si me acuerdo de mirarlo.

Pero ten en cuenta que s� veo mejora con esa aplicaci�n generando mpeg4. Seg�n el c�dec que elijas, se usa una librer�a u otra, que creo desarrolladas por diferentes equipos. Y en los foros se comenta precisamente que libxvid va lenta incluso en modo threaded. Que s�lo separan un hilo para el video, otro para el sonido, y otro para la multiplexaci�n. Si fuera una aplicaci�n realmente paralelizada, el v�deo se dividir�a en varios hilos.

Lastima que en Linux no tengamos ningun software de codigo abierto para hacer esa conversi�n mediante ATI Stream o Nvidia Cuda:

http://foros.3dgames.com.ar/hardware.31/493181.respuesta-ati-cuda-ati-str eam-computing.html

http://www.pcper.com/article.php?aid=745

Bueno, al menos del lado de ATI, publicaron el sdk 2.0 con OpenCL 1.0 para Opensuse y ubuntu hace menos de 10 dias: http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx#five

Cierto, es una pena que las GPGPUs no se estén tomando más ne serio ... es cuestión de tiempo ;)

Tanto STREAM de ATI como CUDA/Tesla de NVIDIA son buenas tecnologías siempre y cuando las aplicaciones que vayas a portar tengan instrucciones SIMD. Además de eso, hace falta tener las herramientas de desarrollo: librerías, compiladores, ...

Hoy por hoy, esta tecnología está en su infancia y aún queda. Cada vez hay más aplicaciones que están adoptando esta tecnología:

       http://www.nvidia.com/object/cuda_home.html

       http://www.amd.com/us/products/technologies/stream- technology/commercial/Pages/partners.aspx

       http://developer.amd.com/samples/streamshowcase/Pages/default.aspx

Pero no es "main stream".

...

Hacen falta los programadores, que desarrollen las aplicaciones de conversi�n, usando esa tecnolog�a.

Efectivamente, pero he visto que en algunas Universidades se imparten cursos de programación de GPGPUs. A ver con qué nos sorprenden las nuevas generaciones ;)

En todo caso, tanto Intel como AMD dijeron que su meta era que la GPGPU fuera parte del socket. Es decir, que fuera un "core más". Según los roadmaps publicados de Intel, es lo que va a empezar a hacer con Westmere y continuar desde allí.

Ya, ya sé que Westmere lo que incluye es un core gráfico, no realmente una GPGPU, pero desde allí avanzar ese core gráfico para convertirlo en una GPGPU, es decir, el famoso proyecto Larrabee. Ya veremos lo que saldrá.

Esto deja a NVIDIA cojo porque tanto AMD como Intel tienen su CPU y GPU.

Algo mas sobre OpenCL: http://www.youtube.com/watch?v=IEWGTpsFtt8&feature=related http://www.youtube.com/watch?v=7PAiCinmP9Y&feature=related Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-27 a las 19:11 -0300, Juan Erbes escribió:

Hablando de invierno, por lo que vi en los noticieros, Europa, está bastante fresquita, aunque claro, Uds junto con Italia, son los que mas cerca del ecuador están.

Como los trata el frio?

Yo estoy en la zona más templada, la punta sur-este, a la altura del mar. La casa no tiene calefacción, y hoy es un dia bueno, así que estoy a 18.5 grados en este cuarto con 80% de humedad, y 9 grados en el exterior (según el termómetro del aeropuerto de San Javier, Murcia). Hace unos dias llegó a 14 grados, dentro de casa. Las casas modernas, o en otras ciudades más al norte, pueden tener calefacción centralizada. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks3/WAACgkQtTMYHG2NR9WBlQCeNW5Yhq4a2Gy5oaPEIdITyuMC fgcAn3UScSZ8qM47a7lbqATbMA2yr5FJ =djWQ -----END PGP SIGNATURE-----

El Tue, 22 Dec 2009 19:54:48 +0100, Carlos E. R. escribió:

El 2009-12-22 a las 18:54 +0100, Carlos E. R. escribió:

...

...

Ahora tendré que probarlo con dos canales de audio,

Pues el segundo canal, el español, no termina de encajar.

Lo estoy haciendo así:

ffmpeg -i corte_problematico-2.mpeg -qscale 1 -async 1 \ corte_problematico-2.avi -async 1 -newaudio

He probado poniendo el "-newaudio" antes y después del segundo async (el manual dice que después). Na. Hay un ligero desfase en la segunda voz, que se nota en los pocos monosílabos del trocito.

¿Se te ocurre como? Hoy que estás inspirada me tengo que aprovechar O:-)

Aprovecha porque mañana me voy para Valencia y estaré "fuera de servicio" unos días :-)

(Si es preciso subo ese mpeg con las dos voces).

Sube, anda, sube, a ver qué podemos sacar... que nos vas a dar las fiestas con tanta "zambomba ffmpegera" :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Tue, 22 Dec 2009 21:27:00 +0100, Carlos E. R. escribió:

El 2009-12-22 a las 19:10 -0000, Camaleón escribió:

...

El Tue, 22 Dec 2009 19:54:48 +0100, Carlos E. R. escribió:

...

...

He probado poniendo el "-newaudio" antes y después del segundo async (el manual dice que después). Na. Hay un ligero desfase en la segunda voz, que se nota en los pocos monosílabos del trocito.

¿Se te ocurre como? Hoy que estás inspirada me tengo que aprovechar O:-)

Aprovecha porque mañana me voy para Valencia y estaré "fuera de servicio" unos días :-)

¡ARGH! ¡Se me va la musa! >:-) :-p Habría que prohibir las vacaciones. To el mundo a trabajar. Mmm... esto... si yo estoy de vacaciones... Na, no he dicho na. :-p

Que lo pases bien :-)

X-) Gracias.

...

...

(Si es preciso subo ese mpeg con las dos voces).

Sube, anda, sube, a ver qué podemos sacar... que nos vas a dar las fiestas con tanta "zambomba ffmpegera" :-P

O:-)

[...]

He tenido que salir un rato, y el bisho este lleva subiendo 24 minutos y le faltan otros 2.

[...]

http://www.4shared.com/file/179055608/a9ab735b/ corte_problematico-2mpeg.html

Bueno, a ver, te comento. En ese archivo que has subido (mpeg) el audio de la pista en español lo escucho a destiempo (empieza a "romperse" en el segundo 19). Me refiero "antes" de aplicarle ninguna conversión. Estoy usando SMPlayer aunque también lo probado con Totem, por si acaso. La pista en inglés se escucha "acompasada", sin problemas. Sólo falla la española. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Tue, 22 Dec 2009 22:39:17 +0100, Carlos E. R. escribió:

...

En ese archivo que has subido (mpeg) el audio de la pista en español lo escucho a destiempo (empieza a "romperse" en el segundo 19). Me refiero "antes" de aplicarle ninguna conversión.

Estoy usando SMPlayer aunque también lo probado con Totem, por si acaso.

La pista en inglés se escucha "acompasada", sin problemas. Sólo falla la española.

¿Falla la española en el mpeg que puse? Ostras. De eso no me dí cuenta. A ver, lo compruebo. [...] Tienes razón, esa copia está mal. Pues eso es un artefacto que mete el ffmpeg al copiar un trocito en el segundo canal de audio, porque acabo de mirar en el mpeg completo y ese cachito está bien.

Entonces, lo que tengo que probar, es a hacer la conversión a avi con todos los parametros que hemos ido sacando, pero sólo del cacho de tiempo en el que está el artefacto.

Luego te cuento que sale.

Okis.

Otro problema que acabo de descubrir, es que al cacharro del salón no le gusta el codec de video de esos avis: tengo que usar otro codec. Es cuestion de probar a ver cual le gusta. Eso debe ser fácil.

Y yo que pensaba comerme el turrón con tranquilidad... Ya me imagino la escena: la gente cantando villancicos y yo pensando en los parámetros a pasarle al "ffmpeg" :-) Oye, ¿y no te saldría más a cuenta mantener el contenedor "mpeg" original (con los dos canales) y sólo recortar las bandas para reducir el tamaño del archivo? A lo mejor resulta factible y te olvidas de descompases auditivos y de códecs de vídeo incompatibles, porque supongo que el asincronismo viene al realizar la conversión a AVI... (... a ver si cuela) (:-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Wed, 23 Dec 2009 02:01:21 +0100, Carlos E. R. escribió:

Hecho.

Codificación por defecto:

(...)

Y eso produce estos resultados:

(...)

Observad que la codificación con libxvid, calidad 1, produce un fichero enorme, más grande incluso que el original mpeg, que tiene unos 54235136 bytes. Con calidad 2 sale un tamaño similar a la codificación "por defecto", unos veinte megas. Y da la casualidad que de todos esos, mi reproductor de salón sólo traga los hechos con xvid.... o sea, que me quedo con el de -qscale 2, marcado con un asterisco.

La pega es que éste códec es considerablemente más lento que los demás:

mpeg 4 -qscale 1 (la que usa por defecto):

frame= 2247 fps= 68 q=2.0 Lsize= 18699kB time=90.00 bitrate=1702.1kbits/s video:17049kB audio:1406kB global headers:0kB muxing overhead 1.320397%

real 0m33.153s user 0m47.007s sys 0m0.886s

libxvid -qscale 2

frame= 2247 fps= 26 q=2.0 Lsize= 20318kB time=90.00 bitrate=1849.4kbits/s video:18668kB audio:1406kB global headers:0kB muxing overhead 1.213710%

real 1m25.237s user 0m49.871s sys 1m44.019s

O sea, que la pelicula de 6440.120S tardará en codificarla 6099 segs en xvid o 2372S en mpeg-4.

¡¿Que hago?!

Si la quiero ver en el salón me tarda casi el triple en prepararse... ¿porqué será tan lento? Si comprime lo mismo... Jolines :-(

Vaya... ¿Y si pruebas con dos de los "tips" que ponen en la faq de ffmpeg? *** If your computer is not fast enough, you can speed up the compression at the expense of the compression ratio. You can use '-me zero' to speed up motion estimation, and '-intra' to disable motion estimation completely (you have only I-frames, which means it is about as good as JPEG compression). *** O buscando por Google, a ver qué se comenta: http://www.google.com/intl/en/#hl=en&q=ffmpeg+speed+up+xvid+encoding Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sun, 27 Dec 2009 15:15:28 +0100, Carlos E. R. escribió:

On 2009-12-27 12:09, Camaleón wrote:

...

...

Si la quiero ver en el salón me tarda casi el triple en prepararse... ¿porqué será tan lento? Si comprime lo mismo... Jolines :-(

Vaya...

¿Y si pruebas con dos de los "tips" que ponen en la faq de ffmpeg?

*** If your computer is not fast enough, you can speed up the compression at the expense of the compression ratio. You can use '-me zero' to speed up motion estimation, and '-intra' to disable motion estimation completely (you have only I-frames, which means it is about as good as JPEG compression). ***

Ah, pero es que quitar calidad no es una opción. Caray, que no tengo un procesador lento, precisamente...

Prueba, que no te cuesta nada... si no te sirve, lo descartas y listo.

...

O buscando por Google, a ver qué se comenta:

http://www.google.com/intl/en/#hl=en&q=ffmpeg+speed+up+xvid+encoding

http://forum.doom9.org/archive/index.php/t-100143.html

Dicen que el xvid no está optimizado para usar varios cores. Y que con 64 bits tampoco se nota mucha mejoría. Eso era en el 2005.

¿En el 2.005 ya había 64 bits? :-)

En http://www.ffmpegx.com/video.html, un programa para Mac, comparan varios métodos. Y comentan que el ffmpeg convirtiendo a mpeg4 es el más rápido, y de alta calidad. Pero que xvid es el mejor.

Sí, en todos los tests aparece como el más eficiente. Además, con el equipo que tienes, no sé por qué tarda tanto :-? Si tienes montado ya el sistema de 64 bits en una partición "chrooteada", podrías probarlo desde ahí. (...)

Ese enlace me parece muy recomendable, compara no se si todos los formatos, pero muchos. Muy instructivo.

http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-xvid.html

Explica los ajustes de mencoder para producir xvid.

http://ffmpeg.org/ffmpeg-doc.html

manual de ffmpeg.

En http://forum.videohelp.com/topic343387.html alguien plantea una pregunta muy similar la mia, convertir .mpeg de hdtv a .avi. No parecen llegar a una conclusión, pero los pasos que siguió son similares a los mios.

Otra cosa que estaba pensando... no sé si obtendrías mayor velocidad en la codificación si utilizaras un segundo disco duro, es decir, procesar la entrada (mpeg) desde un disco y enviar la salida (avi) al otro. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sun, 27 Dec 2009 21:10:04 +0100, Carlos E. R. escribió:

On 2009-12-27 19:52, Camaleón wrote:

...

El Sun, 27 Dec 2009 15:15:28 +0100, Carlos E. R. escribió:

...

...

...

¿Y si pruebas con dos de los "tips" que ponen en la faq de ffmpeg?

*** If your computer is not fast enough, you can speed up the compression at the expense of the compression ratio. You can use '-me zero' to speed up motion estimation, and '-intra' to disable motion estimation completely (you have only I-frames, which means it is about as good as JPEG compression). ***

Ah, pero es que quitar calidad no es una opción. Caray, que no tengo un procesador lento, precisamente...

Prueba, que no te cuesta nada... si no te sirve, lo descartas y listo.

Psee... se me acabaron las vacaciones, ya no puedo probar muchas cosas.

En las próximas fiestas.

...

...

Dicen que el xvid no está optimizado para usar varios cores. Y que con 64 bits tampoco se nota mucha mejoría. Eso era en el 2005.

¿En el 2.005 ya había 64 bits? :-)

Imagino. No es tan moderno, ¿no?

Supongo que en el 2.005 no estaría tan afinado y los programas no estarían preparados para trabajar sacando el máximo partido.

...

Si tienes montado ya el sistema de 64 bits en una partición "chrooteada", podrías probarlo desde ahí.

No, no lo tengo. Y el espacio libre lo he ocupado de momento con una partición temporal que contiene los datos de uno de mis discos de respaldo que ha petado con 500 horas de uso:

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 001 001 036 Pre-fail Always FAILING_NOW 30748

Tengo que intentar devolverlo en garantía, a ver como va eso, por cierto.

Para que luego digas que los discos externos por usb, siempre en una leja, y alimentados por SAI, no fallan nunca, que los discos duros duran más que los DVD y eso. No se quien me decía eso hace poco >:-)

Al menos te ha avisado. Un DVD te hubiera grabado mal los datos, lo hubieras guardado en su cajita de oro y al intentar leerlo dentro de una semana te hubieras dado con un canto en los dientes.

...

Otra cosa que estaba pensando... no sé si obtendrías mayor velocidad en la codificación si utilizaras un segundo disco duro, es decir, procesar la entrada (mpeg) desde un disco y enviar la salida (avi) al otro.

Lo he hecho. Las pruebas con el trocito de la del coleccionista de huesos fueron así.

Pero no es el caso con libxvid. Ahora mismo estoy probando unas series de 90 segundos a varias calidades (temperatura: 68..58, cpu 200% (de 400), modo "on demand" @2Ghz, 70..100%), y el disco apenas se mueve, ni registra en el gkrellm. Los fps oscilan entre 60 y 30, parece. Cuando está generando mpeg-4, entonces sí se ve la velocidad de grabación o lectura en el disco, pero es suficiente para cargar el sistema I/O, que lo he visto chascar a más de 50MiB/S sostenidos con rsync (o sea, con miles de ficheros sueltos).

Me está ocupando todos los cores, pero a una media del 50%.

Debería hacer un uso más elevado de cada núcleo.

Creía que había una manera de ver los "threads", pero en el top no lo veo, y en el "system monitor" me sale un cuadro en gris, se ha colgado. Lo arranco otra vez, y se llena, pero salta el bugbuddy, y se cierra. Lo arranco una tercer, y ya veo los gráficos. Mmmm... al clickar la pestaña "system" se cuelga. Le doy otra vez, y funciona.... nada de interés, sigo sin ver los threads de cada proceso.

En el top... pone algo en su manual: *** -H : Threads toggle Starts top with the last remembered ’H’ state reversed. When this tog‐ gle is On, all individual threads will be displayed. Otherwise, top displays a summation of all threads in a process. *** Pero si lo activo no veo los datos :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sun, 27 Dec 2009 21:55:18 +0100, Carlos E. R. escribió:

...

...

No, no lo tengo. Y el espacio libre lo he ocupado de momento con una partición temporal que contiene los datos de uno de mis discos de respaldo que ha petado con 500 horas de uso:

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 001 001 036 Pre-fail Always FAILING_NOW 30748

Tengo que intentar devolverlo en garantía, a ver como va eso, por cierto.

Para que luego digas que los discos externos por usb, siempre en una leja, y alimentados por SAI, no fallan nunca, que los discos duros duran más que los DVD y eso. No se quien me decía eso hace poco >:-)

Al menos te ha avisado.

No, no me ha avisado. Lleva fallando probablemente varios meses, pero lo que yo veía era corrupción en el sistema de ficheros reiserfs, que tardaba horas en corregir; y que curiosamente se presentaba con el oS 11.0, pero no con el 10.3 ni el 11.1, por lo que escribía en él a través de un 11.1 en vmware. Ahora ya no sé si fallaba el oS 11.0, fallaba el disco, o ambos.

Me he enterado al conectarlo al ordenador nuevo via eSATA, y avisarme la BIOS durante el arranque, nada menos. Si no es por eso no me entero.

Una corrupción en el sistema de archivos ya es un aviso de que algo no va bien. Tendrías que haberlo analizado pinchándolo en algún puerto de la placa o desde el Windows, donde sí puedes hacerle un chequeo con las herramientas del fabricante, aunque lo tengas pinchando en la caja USB.

Es el problema con los malditos chipsets de USB storage, que no soportan SMART. Han hecho lo mínimo para que funcionen, pero te pueden dar unos sustos de tres pares de narices - y más teniendo en cuenta que al ser discos externos reciben más vibraciones y golpes que los normales.

Hay cajas con chipsets que sí soportan los comandos de smart. No me preguntes cuáles son ni dónde conseguirlas en España, pero sé que las hay porque lo pone (o lo ponía) en la página de smartmontools.

...

Un DVD te hubiera grabado mal los datos, lo hubieras guardado en su cajita de oro y al intentar leerlo dentro de una semana te hubieras dado con un canto en los dientes.

No, si te tomas la molestia de comprobar la imagen completa, y son de calidad. Eso todavía no me ha pasado con ninguno de mis DVDs. Podría pasar, desde luego, pero para eso tomo mis precauciones. Incluyendo par2, a falta del equivalente a bajo nivel.

Ya... o te tomas la molestia de poner un bug para saber que tienes que usar wodim en lugar de growisofs porque con growisofs falla. Te recuerdo que hace unos días no podías grabar imágenes iso como siempre has hecho >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sun, 27 Dec 2009 22:31:38 +0100, Carlos E. R. escribió:

On 2009-12-27 22:05, Camaleón wrote:

...

...

No, no me ha avisado. Lleva fallando probablemente varios meses, pero lo que yo veía era corrupción en el sistema de ficheros reiserfs, que tardaba horas en corregir; y que curiosamente se presentaba con el oS 11.0, pero no con el 10.3 ni el 11.1, por lo que escribía en él a través de un 11.1 en vmware. Ahora ya no sé si fallaba el oS 11.0, fallaba el disco, o ambos.

Me he enterado al conectarlo al ordenador nuevo via eSATA, y avisarme la BIOS durante el arranque, nada menos. Si no es por eso no me entero.

Una corrupción en el sistema de archivos ya es un aviso de que algo no va bien.

Salvo por el pequeño detalle de que en 10.3 no producía errores, ni en 11.1. Sólo en la 11.0. Ese "pequeño detalle" es significativo.

¿Pero el disco sata está muerto, no puedes acceder a los datos de ninguna de las maneras?

...

Tendrías que haberlo analizado pinchándolo en algún puerto de la placa

El disco es sata y la placa no tiene sata. La antigua no. Y no compré tarjeta eSATA porque cuando iba a comprar una que me gustaba desapareció de la lista de ventas, y entonces me decidí a comprarme un PC nuevo - lo cual ha tardado varios meses.

Yo diría que en tu caso se han dado varias coincidencias circunstanciales inoportunas.

...

o desde el Windows, donde sí puedes hacerle un chequeo con las herramientas del fabricante, aunque lo tengas pinchando en la caja USB.

Eso no lo sabía. ¿Desde el windows o desde el msdos? Las seatools vienen en ambas versiones. Y el windows de ese PC es el Me, no creo que lo soporte nadie.

*** SeaTools for Windows <http://www.seagate.com/ww/v/index.jsp?locale=en- US&name=SeaTools&vgnextoid=720bd20cacdec010VgnVCM100000dd04090aRCRD> SeaTools for Windows tests USB, 1394, ATA (PATA/IDE), SATA and SCSI drives. It installs onto your system. SeaTools for Windows is completely data safe. *** Es para Windows 2000, XP o Vista (y supongo que también para el 7). Del Windows Me o el 98 no dice nada y no me extraña porque están sin soporte por parte del fabricante (MS). Deberías pensar en jubilarlo.

Ah, y no me vengas con que los seagate no te gustan, porque ese disco lo compré antes de que se destapara "ese" problema, que te conozco.

:-) No, no te iba a decir eso. Todos mis discos son Seagate.

...

Hay cajas con chipsets que sí soportan los comandos de smart. No me preguntes cuáles son ni dónde conseguirlas en España, pero sé que las hay porque lo pone (o lo ponía) en la página de smartmontools.

He oído el rumor.

Sí, acabo de poner el enlace donde las enumeran.

...

...

...

Un DVD te hubiera grabado mal los datos, lo hubieras guardado en su cajita de oro y al intentar leerlo dentro de una semana te hubieras dado con un canto en los dientes.

No, si te tomas la molestia de comprobar la imagen completa, y son de calidad. Eso todavía no me ha pasado con ninguno de mis DVDs. Podría pasar, desde luego, pero para eso tomo mis precauciones. Incluyendo par2, a falta del equivalente a bajo nivel.

Ya... o te tomas la molestia de poner un bug para saber que tienes que usar wodim en lugar de growisofs porque con growisofs falla.

Te recuerdo que hace unos días no podías grabar imágenes iso como siempre has hecho >:-)

Pero ahora sí. Ya sabes que esas cosas de que funcionen o no pasan en linux. Tampoco me funcionaba el sonido, y he tenido que comprar otra tarjeta. Tampoco me funciona la webcam del monitor (no me dí cuenta de su existencia hasta que encendí la luz del techo), y no se si funciona su micrófono.

Que de repente no vaya la deuvedera al cambiar de máquina... pues normal.

Sí, es normal. La diferencia es que con la unidad de DVD es "esperable" que falle (o te dé problemas) pero con un disco duro no, no esperas que una nueva versión de linux te vaya a dar problemas para copiar los datos con un simple "cp"

:-)

Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Mon, 28 Dec 2009 01:10:53 +0100, Carlos E. R. escribió:

El 2009-12-27 a las 22:10 -0000, Camaleón escribió:

...

¿Pero el disco sata está muerto, no puedes acceder a los datos de ninguna de las maneras?

Sí, si funciona. He grabado todo en una partición enorme del ordenador, donde iba a instalar el sistema. Pero lo he quitado, su fuente de alimentación se la he puesto a otro disco igual que está con la TDT y que estaba petando, y mi intención es sacar el disco para enviarlo en garantía. Que por cierto, tengo que mirarlo esta noche para empaquetarlo mañana, si me sale la confirmación de la garantía de seagate. (Salió. pero hay que pagar el envío :-( ).

El disco ha agotado el espacio de remapeo de sectores malos, y da aviso de fallo en 24 horas.

He pasado el seatools, que canta un código de error para retornar el disco (lo he probado varias veces) y luego lo he borrado entero.

Pues menos mal que al menos has podido sacar los datos. No sé si hubieras tenido la misma suerte con un DVD "defectuoso" >:-)

...

Yo diría que en tu caso se han dado varias coincidencias circunstanciales inoportunas.

Es posible. Pero el caso es que las bios que hacen el chequeo de SMART al arrancar, que es el aviso que tienen la gente normal, no chequean los discos en USB, que yo sepa. Linux tampoco puede.

Eso es cierto. Los discos externos se conectan y no se suelen verificar. Pero tampoco es habitual que fallen, no sé... yo ahora mismo no recuerdo haber tenido un disco fallando de esa guisa pero sí tengo varios CD y DVD ilegibles :-?

...

Es para Windows 2000, XP o Vista (y supongo que también para el 7). Del Windows Me o el 98 no dice nada y no me extraña porque están sin soporte por parte del fabricante (MS). Deberías pensar en jubilarlo.

Y me pongo un XP pirata, ¿no? >:-P

No, lo compras, como hacemos todos... bueno, vale, como hacemos 4 gatos

:-)

...

...

Ah, y no me vengas con que los seagate no te gustan, porque ese disco lo compré antes de que se destapara "ese" problema, que te conozco.

:-)

No, no te iba a decir eso. Todos mis discos son Seagate.

Ah, ¿siiii? ¡JUASSS! X'-)

Jo...

Menos mal que no son horas de reirme a carcajadas, despertaría a los vecinos. Con la bronca que me echaste por usar seagate después del megafallo... ¿No te has podido deshacer de ellos? X'-)

Bueno, me daban la opción de cambiarlos sin problemas pero ya había instalado un windows xp 32 bits, un windows xp 64 bits y había clonado a la suse 10.3. El resto de unidades de disco eran para almacenamiento de datos, así que casi era peor el remedio que la enfermedad: actualicé el firmware de todas las unidades y problema resuelto. Son discos de la serie empresarial, aunque lo que más me gusta de los Seagate es que generan poco calor y son silenciosos.

:-)

La verdad, es que es el segundo que me falla en un mes. Uno que no he podido ni estrenar con el ordenador, la bios no lo reconoce. Y ahora el externo.

Ya te digo... eso es algo poco común.

...

...

Que de repente no vaya la deuvedera al cambiar de máquina... pues normal.

Sí, es normal.

La diferencia es que con la unidad de DVD es "esperable" que falle (o te dé problemas) pero con un disco duro no, no esperas que una nueva versión de linux te vaya a dar problemas para copiar los datos con un simple "cp"

...

:-)

Ah, ¿nooo? No se, ¿que problemas se oyeron con las bios raid, que si promise si, que si no, que si tienes el driver o no, que si nosecuantos, que si tienes que instalar el linux con la sata en modo compatibilidad (lentoooo!)?

Claro que hubieron problemas. Y los hay. Vamos, que vas a la tienda a comprar un disco duro y dices que es para linux y son capaces de decirte que eso anula la garantía. Y gracias que las seatools pueden venir en una iso botable.

Vaya, que no es habitual que un disco duro de problemas de esa clase. Sí, vale, ya sé que las grabadoras son bastante... volubles. No es la mejor de las tecnologías. Pero mira, también fallan los discos duros grabados con un montón de datos. No te puedes fiar de que funcionen siempre tampoco.

Para eso están las copias de seguridad y yo no dejo el backup primario en un DVD ni "jarta" de vino... bueno sí, la copia de seguridad nº 5 puede ir en DVD, pero la 1, 2 la 3 y la 4 se quedan en el disco duro :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Mon, 28 Dec 2009 16:32:18 +0100, Carlos E. R. escribió:

On 12/28/2009 11:51 AM, Camaleón wrote:

...

El Mon, 28 Dec 2009 01:10:53 +0100, Carlos E. R. escribió:

...

Pues menos mal que al menos has podido sacar los datos. No sé si hubieras tenido la misma suerte con un DVD "defectuoso" >:-)

Pues en el caso peor hubiera perdido 4 Gigas de datos, en vez de 300 del disco duro inaccesible...

Y en el caso normal, igual no pierdo nada, porque: a) quemo dos DVDs, a veces en marcas distintas. b) uso par2.

Pero eso son cosas que nadie hace. Al igual que tampoco analizas el disco usb para prevenir errores pues la gente tampoco hace copias duales en los DVD (menudo gasto :-P) o usa herramientas de recuperación o verificación para comprobar los datos que hace de cada copia. Y no te olvides de que también te puede fallar no sólo la copia sino el medio físico.

...

Eso es cierto. Los discos externos se conectan y no se suelen verificar. Pero tampoco es habitual que fallen, no sé... yo ahora mismo no recuerdo haber tenido un disco fallando de esa guisa pero sí tengo varios CD y DVD ilegibles :-?

Es que hasta que lo he conectado via eSATA ni sabía que estaba falluto. Y todavía no tengo ningún DVD guardado como backup que sea ilegible :-)

Pero sí tendrás unos cuantos que hayas tirado...

...

...

Vaya, que no es habitual que un disco duro de problemas de esa clase. Sí, vale, ya sé que las grabadoras son bastante... volubles. No es la mejor de las tecnologías. Pero mira, también fallan los discos duros grabados con un montón de datos. No te puedes fiar de que funcionen siempre tampoco.

Para eso están las copias de seguridad y yo no dejo el backup primario en un DVD ni "jarta" de vino... bueno sí, la copia de seguridad nº 5 puede ir en DVD, pero la 1, 2 la 3 y la 4 se quedan en el disco duro :-P

:-)

Guardo dos DVDs de cada, más el disco duro de archivo/backup, para acceso "random" rápido. Y lo único que ha fallado es el disco duro. Es más, me temo que me confié en el disco duro y no tengo respaldo en DVD de todo, tengo que ponerme. Dejé de hacerlos por el problema con xfs primero y reiserfs después, que han resuelto ahora.

Mala planificación por tu parte >:-). Los datos se copian en disco duros separados y se guarda una tercera copia a modo de archivo en una unidad externa (usb, red...). Luego haces todas las copias en DVD que quieras :-)

Te digo una cosa, el método más fiable _eran_ los disquetes grabados por el pcbackup de las pctools. Tengo tiradas de 80 disquetes hechas en la década de los ochenta que todavía funcionan. Ojo, con uno o dos errores de lectura recuperables, esa es la clave: ese software grababa con códigos de detección y corrección de errores. Y funciona.

Lamentablemente, la capacidad de los disquetes hace impracticable el sistema hoy en dia, y de todos modos, su calidad ahora es terriblemente mala. Antes no, eran muy fiables.

Me parece que hoy en día pocas cosas hay que sean fiables, ni de hardware ni de software :-( Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Mon, 28 Dec 2009 21:30:50 +0100, Carlos E. R. escribió:

El 2009-12-28 a las 17:15 -0000, Camaleón escribió:

...

Al igual que tampoco analizas el disco usb para prevenir errores pues la gente tampoco hace copias duales en los DVD (menudo gasto :-P) o usa herramientas de recuperación o verificación para comprobar los datos que hace de cada copia.

Sí analicé el disco usb, hasta donde pude.

Je, eso es como decir que revisaste la superficie del DVD "hasta donde pudiste", y como no la viste rayada, pensabas que estaba bien >:-)

...

Y no te olvides de que también te puede fallar no sólo la copia sino el medio físico.

Pues claro. Me ha fallado el medio físico "disco duro".

No me refería al disco duro sino al DVD, al disco. Que no sólo es fácil que te falle el proceso de la copia de datos sino el propio DVD.

...

...

Es que hasta que lo he conectado via eSATA ni sabía que estaba falluto. Y todavía no tengo ningún DVD guardado como backup que sea ilegible :-)

Pero sí tendrás unos cuantos que hayas tirado...

Sólo cuando hago pruebas.

O cuando hay un bug...

Una vez que tengo un sistema, lo sigo y no falla. Si fallara, seguiría otro sistema.

Ya, pero no te avisa como lo hace el disco duro con SMART. Es que ni siquiera tienes esa opción de chequeo con los DVD. ¿Cómo sabes (con qué programa o aplicación) que el DVD no tiene ningún error físico? Sencillamente no está implementado, salvo que vayas a un laboratorio y analices el medio por completo, pista a pista. En cambio, en los discos duros sí se han tenido en cuenta estrategias de fallos en el propio medio, como la implementación de SMART o las configuraciones en RAID. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Tue, 29 Dec 2009 15:39:43 +0100, Carlos E. R. escribió:

El 2009-12-29 a las 07:37 -0000, Camaleón escribió:

...

...

Sí analicé el disco usb, hasta donde pude.

Je, eso es como decir que revisaste la superficie del DVD "hasta donde pudiste", y como no la viste rayada, pensabas que estaba bien >:-)

No exactamente. Grabé un patrón en todo el disco sin formatear y lo comparé.

¿Y ese "patrón" qué es, exactamente? ¿Una copia exacta, una imagen? ¿Qué garantías tienes de que el patrón no falle pero la copia sí?

...

...

Pues claro. Me ha fallado el medio físico "disco duro".

No me refería al disco duro sino al DVD, al disco.

Que no sólo es fácil que te falle el proceso de la copia de datos sino el propio DVD.

Claro, me ha fallado el propio disco duro. Exceso de sectores malos malosos, nada menos.

Y nada más fácil que sacar los datos y llevarlos a otro lado porque siguen estando accesibles. La comparación es muy sencilla: En los DVD puede fallar: a) DVDera b) Programa de grabación c) Discos DVD En los discos duros puede fallar: a) El disco duro :-) Luego, es mucho más probable que falle un sistema con 3 puntos susceptibles de fallo que un sistema con uno solo. Pura matemática. ¿Por qué crees que los videograbadores domésticos han incluido discos duros en lugar de dejar la grabadora DVD? Porque no hay quien se acalre con los formatos que admiten (DVD-R, DVD+RW pero no DVD-RW) y son mucho más inflexibles, limitados... los usuarios prefieren volcar a disco, más rápido, más espacio, fácilmente ampliable...

...

...

...

...

Es que hasta que lo he conectado via eSATA ni sabía que estaba falluto. Y todavía no tengo ningún DVD guardado como backup que sea ilegible :-)

Pero sí tendrás unos cuantos que hayas tirado...

Sólo cuando hago pruebas.

O cuando hay un bug...

Que sólo se produce en el cambio de versión de opensuse, y se descubre en el proceso de pruebas de la versión.

Pues eso, que te obliga a estar alerta de los cambios.

...

...

Una vez que tengo un sistema, lo sigo y no falla. Si fallara, seguiría otro sistema.

Ya, pero no te avisa como lo hace el disco duro con SMART. Es que ni siquiera tienes esa opción de chequeo con los DVD.

¿Cómo sabes (con qué programa o aplicación) que el DVD no tiene ningún error físico? Sencillamente no está implementado, salvo que vayas a un laboratorio y analices el medio por completo, pista a pista.

En cambio, en los discos duros sí se han tenido en cuenta estrategias de fallos en el propio medio, como la implementación de SMART o las configuraciones en RAID.

La comparación no es exacta, porque el smart no verifica realmente la superficie con un microscopio. Graba un patrón y lo lee de nuevo, o bien simplemente lo lee y comprueba si es correcto con el CRC. Los dvd también tienen checksums de sus sectores. El aparato lector podría informar (pero no lo hace) de si las lecturas son marginales o sólidas, cosa que si hace un disco duro.

Y no lo hace porque... ¿cuestan 25€? No son sistemas que se hayan fabricado para ser fiables (las unidades grabadoras) ni que hayan pasado por las pruebas a las que someten a los discos duros. Por no hablar de los medios...

Muchas de las medidas del smart son realmente parámetros de la unidad, no del medio "superficie". Cierto, las unidades lectoras/grabadoras de dvd no dan esa información. Podrían. Es posible que haya software comercial caro, quizás asociado a buenas grabadoras, que hagan cosas de esas.

"Deberían" dar esa información. Yo prefiero pagar más por una unidad que sea capaz de analizar y reparar errores (por software, por hardware, como prefieran) que tener una "ruleta rusa" por DVD.

Pero el hecho es que, a mi, los DVDs que archivo no me fallan, y los discos duros sí. De momento.

Esa es un afirmación muy parcial. Primero tendrás que hacer cuentas, fallos por cada byte escrito o leído, y luego, podrás sacar conclusiones.

En parte porque uso DVDs cuyo modelo está listado por una entidad/ asociación como "archival best quality" después de los informes de clientes o socios que han grabado miles de deuvedés.

Eso carece de validez alguna. ¿Cuál es la garantía que tienes por cada DVD? Ninguna. ¿A quién lo retornas si te falla un DVD? A nadie si no quieres perder el tiempo.

Y en parte porque no hago cosas como hacer grabaciones parciales para cerrar luego, ni copiar fichero a fichero, ni tonterías de esas que permite el windows.

Aunque no te guste, lo que es un estándar y está catalogado como tal debería estar soportado. Como el UDF, que yo aún no sé cómo utilizarlo con linux.

Y los discos duros que me han fallado están sin moverse en la misma leja, alimentados por una SAI... no han tenido ningún tipo de maltrato, como no sea el del transporte desde el fabricante hasta el cliente

Eso es otro problema: los discos duros mejor comprarlos en mano o mantenerlos en cuarentena durante algún tiempo.

- y eso escapa a mi control. Porque ni siquiera los de Alternate siguen la normativa de Seagate para empaquetado y envio de discos duros, un PDF de 15 páginas. ¡Me han llegado a veces discos duros con piececitas de la placa rotas...!

Reclama.

Francamente, los DVDs son más robustos y estables, bien guardados. No es que me fie de ellos, por algo quemo dos copias de cada. Pero oye... es lo que hay, y de los discos duros tampoco me puedo fiar.

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Tue, 29 Dec 2009 17:52:59 +0100, Rafa Grimán escribió:

On Tuesday 29 December 2009 16:27:06 Camaleón wrote:

...

El Tue, 29 Dec 2009 15:39:43 +0100, Carlos E. R. escribió:

...

El 2009-12-29 a las 07:37 -0000, Camaleón escribió:

[...]

...

...

Claro, me ha fallado el propio disco duro. Exceso de sectores malos malosos, nada menos.

Y nada más fácil que sacar los datos y llevarlos a otro lado porque siguen estando accesibles.

No del todo cierto, puedes encontrarte lo que se llama "silent data corruption". Si te encuentras con eso ... no hay recuperación de datos :(

...

Luego, es mucho más probable que falle un sistema con 3 puntos susceptibles de fallo que un sistema con uno solo. Pura matemática.

Nopes, los "silent data corruption" son errores de 3 tipos:

checksum mismatches: checksum/dato incorrecto y se puede deber a:

- datos corruptos en el camino al disco

- torn write: sólo se escribe correctamente una parte de los datos en el bloque

- misdirected write: los datos se escriben al disco equivocado o un sitio incorrecto en el disco

Esto da lugar a datos corruptos y se detectan al leer los datos (lectura normal de datos, data scrubs, reconstrucción RAID). Si no los lees, no lo detectas

identity discrepancies: cuando se hace un block identity check durante una lectura. Se puede deber a:

- una escritura perdida: el sistema de ficheros/operativo cree que se ha escrito el dato, pero realmene no se ha escrito

¿Y eso cada cuantos eones pasa? O:-) (...) porque

ha quedado en la caché, pero no ha llegado al platter, si se

produce

una pérdida de energía/luz que afecta a ese disco, los datos de

la

caché se pierden.

- misdirected write, no se actualiza la dirección en disco

De nuevo, se detectan al hacer una lectura del dato.

parity inconsistencies: paridad calculada de los bloques de datos y paridad almacenada en el disco difieren. Se puede deber a:

- misdirected writes

- corrupción de datos en memoria

- errores de cálculo del procesador

Se detectan durante data scrubs.

Además de eso, puedes encontrarte ataques de tipo "race condition" que te modifican datos sin que lo sepas entre una escritura y una lectura.

Algo me dice que en discos de almacenamiento definitivo (es decir, que se encienden de uvas a peras) no es probable que se den esos problemas.

Luego hay más cosas que pueden fallar, no es sólo el disco: memoria, CPU, cableado, ...

Sí, sí... que no son infalibles, eso tá claro. Pero entre un disco duro y un DVD, prefiero el almacenamiento magnético.

...

¿Por qué crees que los videograbadores domésticos han incluido discos duros en lugar de dejar la grabadora DVD? Porque no hay quien se acalre con los formatos que admiten (DVD-R, DVD+RW pero no DVD-RW) y son mucho más inflexibles, limitados... los usuarios prefieren volcar a disco, más rápido, más espacio, fácilmente ampliable...

Y porque: - se puede almaenar más info (programas)

- puedes borrar si no te gusta lo que has grabado

- la grabación es "más fiable" porque aseguras un flujo de datos constante a la grabadora

- ...

Eso :-) Son mucho más eficientes.

...

...

La comparación no es exacta, porque el smart no verifica realmente la superficie con un microscopio. Graba un patrón y lo lee de nuevo, o bien simplemente lo lee y comprueba si es correcto con el CRC. Los dvd también tienen checksums de sus sectores. El aparato lector podría informar (pero no lo hace) de si las lecturas son marginales o sólidas, cosa que si hace un disco duro.

Y no lo hace porque... ¿cuestan 25€?

No son sistemas que se hayan fabricado para ser fiables (las unidades grabadoras) ni que hayan pasado por las pruebas a las que someten a los discos duros.

Por no hablar de los medios...

En HDD tienes los enterprise y los que no son enterprise. Los que todos tenemos en nuestros PCs y portátils son NO-enterprise. Mucha gente compra para su empresa y sus datos queridos y críticos los qu eno son enterprise (porque son más baratos) ... luego se quejan cuando pierden datos.

Claro, y seguro que ese era el disco que compró Carlos, precisamente, los de la serie Barracuda, típicos de Seagate >:-)

...

...

Muchas de las medidas del smart son realmente parámetros de la unidad, no del medio "superficie". Cierto, las unidades lectoras/grabadoras de dvd no dan esa información. Podrían. Es posible que haya software comercial caro, quizás asociado a buenas grabadoras, que hagan cosas de esas.

"Deberían" dar esa información. Yo prefiero pagar más por una unidad que sea capaz de analizar y reparar errores (por software, por hardware, como prefieran) que tener una "ruleta rusa" por DVD.

La ruleta rusa la tienes en los discos no-enterprise ;)

Y en los "enterprise". Hace poco tuve que actualizar el firmware por un fallo en esos discos, concretamente. El error (cuando se daba) era grave: la BIOS no podía acceder a los datos y el sistema operativo no podía iniciar.

...

...

Pero el hecho es que, a mi, los DVDs que archivo no me fallan, y los discos duros sí. De momento.

Esa es un afirmación muy parcial.

Primero tendrás que hacer cuentas, fallos por cada byte escrito o leído, y luego, podrás sacar conclusiones.

Esto depende un poco del ámbito (IMHO).

En un ámbito oméstico, por ejemplo, más que por byte leído y/o escrito yo lo mediría por fichero perdido o no porque puedes tener un byte o bloque perdido o corrupto, pero sigues accediendo a la info y no notas gran cambio. Por ejemplo, en un juego, puedes perder algún que otro byte/bloque en un fichero de imagen y tu vista no lo percibe (mejor dicho, tu cerebro no lo percibe). También te puede ocurrir en una foto del verano o el vídeo que has grabado del bautizo de tu sobrino o el MP3 de turno que te has descargado. Generalmente, ese tipo de ficheros está grabado con algún tipo de compresión de tipo lossy, es decir, con périda de información por lo que no notarás gran diferencia si un byte o bloque está corrupto. Además de eso, no son datos "vitales".

Lo mismo no se puede decir cuando trabajas, por ejemplo a 4k en cine o en entornos científicos en los que el cambio de un byte puede interferir en un cálculo de pesos o fuerzas o cualquier otra cosa dando lugar a una medición incorrecta: errores al predecir el tiempo, correas que no soportan el peso que deberían soportar, puentes no soportan determinadas velocidades de viento, errores clínicos, ... En el caso dle cine, el realismo no es el mismo o bien, al comprimir, puedes tener errores en la imagen que hagan que la imagen se vea mal (y los clientes se quejen).

En el caso de audio profesional, hay gente de ese mundo que te detecta cosas inimaginables y te dicen si hay un error en lo que están escuchando y que la calidad no es la correcta. Obviamente, si hablamos del MP3 que se acaban de bajar, te da igual porque MP3 es lossy.

[...]

...

...

Francamente, los DVDs son más robustos y estables, bien guardados. No es que me fie de ellos, por algo quemo dos copias de cada. Pero oye... es lo que hay, y de los discos duros tampoco me puedo fiar.

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales.

Y los discos duros que usamos en casa también ... :(

Vale, pero en comparación con el uso que se les da [1] fallan menos :-P [1] ¿Os imagináis lo que duraría un CD-RW (o un DVD-RW) que llevara un sistema operativo instalado? Ni un mes en funcionamiento, tienen límite de escrituras... y doy fe de ello :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Tue, 29 Dec 2009 21:31:25 +0100, Carlos E. R. escribió:

On 2009-12-29 18:29, Camaleón wrote:

...

El Tue, 29 Dec 2009 17:52:59 +0100, Rafa Grimán escribió:

...

...

En HDD tienes los enterprise y los que no son enterprise. Los que todos tenemos en nuestros PCs y portátils son NO-enterprise. Mucha gente compra para su empresa y sus datos queridos y críticos los qu eno son enterprise (porque son más baratos) ... luego se quejan cuando pierden datos.

Claro, y seguro que ese era el disco que compró Carlos, precisamente, los de la serie Barracuda, típicos de Seagate >:-)

Por supuesto. Un "Seagate Barracuda 7200.10". Yo comparo los HD asequibles para mí con los DVD asequibles para mí.

No son tan caros como se piensa. Y creo que merece la pena destinar parte del presupuesto a ese tipo de discos. Hoy en día (con las capacidades actuales de los discos y con la reducción de las garantías por parte de los fabricantes -que entiendo implican procesos de producción menos controlados-), sí.

...

...

...

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales.

Y los discos duros que usamos en casa también ... :(

Vale, pero en comparación con el uso que se les da [1] fallan menos :-P

En mi limitada estadística, fallan más.

Por cierto, los discos duros pueden ser borrados a distancia, con golpes electromagnéticos. Y los CDs con bacterias. Un fallo de la fuente de alimentación puede destruir el disco duro. En el caso de los dvds, simplemente reemplazas la unidad.

Cuando alguien te borre un disco duro a distancia o una bacteria devoradora se zampe unos de tus DVD, me avisas :-)

Cada tecnología tiene sus ventajas e inconvenientes: yo trato de usar las dos, simultáneamente.

Sí. Pero puedes trabajar sin discos DVD aunque no podrías trabajar sin discos duros. Es una pequeña diferencia pero implica que ese medio (discos ópticos) es perfectamente prescindible. Es decir, los DVD/CD desde mi punto de vista son un "accesorio" prescindible.

...

[1] ¿Os imagináis lo que duraría un CD-RW (o un DVD-RW) que llevara un sistema operativo instalado? Ni un mes en funcionamiento, tienen límite de escrituras... y doy fe de ello :-)

Claro, pero es que ese es un uso no recomendado, y no es el que yo le doy. Yo los RW los uso como cosas como las imágenes de factory, y luego grabo otra encima, o para grabar una iso que voy a probar. Y marco una raya de rotulador por cada uso. Jamás se me ocurre usarlos para archivado.

Los discos DVD+RW (o -RW) no son "legibles" en todas las unidades lectoras. Si sólo tienes un equipo, pues no importa. Si tienes varios, con que uno sólo de ellos no lo admita, ya te ha fastidiado la estrategia de instalación.

Y yo estoy hablando de discos para archivado permanente.

Vale. Pero ten en cuenta que los discos duros están preparados para estar en funcionamiento 24/365 (los profesionales). Si los usas como medio de archivo definitivo (como medio "offline" sin escritura ni lectura de datos salvo para hacer la copia) proteges tanto la electrónica como la mecánica y elevas así el tiempo de vida que haya sido estimado por el fabricante. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-30 a las 10:17 +0100, Rafa Grimán escribió:

Hola :)

...

Eso se ha olvidado, damos por supuesto que la grabación ha sido correcta y no la verificamos por sistema. De hecho, si hago una copia de seguridad con rsync, no tengo manera fácil de comprobar la copia bit a bit.

Cierto, cada vez/año hay más estudios sobre esto mismo (en las USENIX y Linux Symposium) patrocinados por Universidades (MIT, Berkley, ...), Google y Yahoo, IBM, NetApp, LSI, ... porque las empresas/usuarios cada vez pierden más datos.

Pues a ver si llegan a algo. Con los discos tan gigantescos que tenemos, damos por supuesto que nuestros datos están seguros, pero no es así.

Vamos que unos por otros y la casa sin barrer.

Todo va mucho más deprisa y no hay tiempo para verificaciones de ningún tipo. Además, eso de verificar (depurar, probar, ...) es caro y nadie quiere invertir. Cada vez hay más líneas de código (leí hace poco que un firmware de un HDD puede tener 400 mil líneas de código!!!)

Ostras.

Un ejemplo de velocidad: Intel sacó hace poco el Nehalem (también conocido como i7). Se espera que saque ahora el Westmere, en el 2010 otro y en el 2011 otro. Y eso que es sólo para Enterprise, porque luego tienes la gama de desktop y luego los Atom. Esto es una salvajada, MHO.

Bastante. Mira, ayer hice una comparativa casera, y encontré que la conversión con ffmpeg a xvid de video es considerablemente más lenta usando threads que sin usarlo. Es más rápido convertir cuatro peliculas simultaneamente que una sóla con threads. O sea, que los desarrolladores no tienen claro todavía como paralelizar un proceso que se supone relativamente fácil de paralelizar, a priori.

También hay tecnologías que no acaban de salir e intentan exprimir hasta el límite más absurdo tecnologías antiguas. Por ejemplo, los 4 kb en discos duros. Hace 10 años (o más) que se lleva hablando de usar bloques de 4 KBytes en vez de 512 bytes en los discos duros. Hasta ahora nadie los había sacado y Western Digital anunció ya una gama de ellos para principios del 2010 (si es que no los acaba de sacar). 10 años hablando paja para sacarlo ahora que tenemos los SSD.

O el no poner cabezas indepedientes para cada plato...

Otro ejemplo es la tecnología RAID. RAID está bien cuando tienes discos <= 500 GBytes. Más que nada porque reconstruir un disco de 1 TB puede suponerte unas 22 horas, 22 horas de périda de rendimiento, de probabilidad de fallo, ... Pues echad números para reconstruir 2 GB de disco. Ahora es cuando se dan cuenta de este problema ...

Pues eso, dos cabezales independientes. Hasta saturar el bus, hay sitio de sobra.

Por cierto, el otro día leí algo de hacer a los programadores responsables de los fallos en el sw que escriben. No me parece mal.

¡Je! Creo que saqué ese tema hace algún tiempo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks7UlkACgkQtTMYHG2NR9VTAACfaVy7blVoXnqDlAL9PLPGdRlP zGwAn2xoV5DcECSAzDZUiQnHL7lwb6AF =lOXc -----END PGP SIGNATURE-----

Hola :) On Tuesday 29 December 2009 18:29:56 Camaleón wrote:

El Tue, 29 Dec 2009 17:52:59 +0100, Rafa Grimán escribió:

...

On Tuesday 29 December 2009 16:27:06 Camaleón wrote:

...

El Tue, 29 Dec 2009 15:39:43 +0100, Carlos E. R. escribió:

...

El 2009-12-29 a las 07:37 -0000, Camaleón escribió:

[...]

...

...

Claro, me ha fallado el propio disco duro. Exceso de sectores malos malosos, nada menos.

Y nada más fácil que sacar los datos y llevarlos a otro lado porque siguen estando accesibles.

No del todo cierto, puedes encontrarte lo que se llama "silent data corruption". Si te encuentras con eso ... no hay recuperación de datos

:(

¿Y eso cada cuantos eones pasa? O:-)

Más habitual de lo que pensamos. En un estudio de NetApp durante 41 meses, se analizaron: 358000 eran no-enterprise y fallaron 3088 (0.862%) 1.17 millones eran enterprise y fallaron 767 (0.065%) Es decir, los discos Enterprise fallan 10 veces menos (a ojímetro ;) Dirás que es un % bajo y lo es, pero lo malo de las partes negativas de los porcentajes es que son binarios, es decir: o te toca o no te toca, no es que te toque a medias. En castellano sería: o se corrompen datos o no. Además, a este % hay que sumar los otros % de fallos debidos a fallos de cableado, motas de polvo, picos eléctricos, pérdida de caché, ... Por lo que el %, como se suele decir, es: suma y sigue ;) El pobre Carlos (según nos ha dicho) ya ha tenido varias experiencias negativas con HDD por lo que Carlos sí se ha encontrado en/con ese 0.862% + x%. Seguro que Carlos no lo ve como un % tan bajo ;) En cambio tu no habrás tenido problemas con HDDs por lo que es un % bajo, ínfimo o insignificante. De ahí que tú sí te fíes de los HDDs y Carlos no. [...]

...

Además de eso, puedes encontrarte ataques de tipo "race condition" que te modifican datos sin que lo sepas entre una escritura y una lectura.

Algo me dice que en discos de almacenamiento definitivo (es decir, que se encienden de uvas a peras) no es probable que se den esos problemas.

No depende del uso del disco. Muchas veces, los errores son del firmware ... y no veas si hay firmware por medio :( Tenemos: - firmwares de CPUs: * del servidor * de las controladoras (HBAs/HCAs y/o las de las cabinas, dependiendo si tenemos cabina o no) * de los discos También puede haber errores de memoria o de la propia CPU (u otros chips). Suma y sigue ;) Es decir, es cuando toca (hablando de tocar y de estadísticas, a ver si me toca la "Lotería del Niño" porque en Navidad el doble que el año pasado: ná de ná). Puedes tener la mala suerte que de 2 veces que lo has encendido, 1 ha fallado. En cuanto a almacenamiento definitivo, se sigue usando la cinta ... más elementos y puntos de fallo ;) Aunque, también hay tecnología de cinta que falla menos. [...]

...

En HDD tienes los enterprise y los que no son enterprise. Los que todos tenemos en nuestros PCs y portátils son NO-enterprise. Mucha gente compra para su empresa y sus datos queridos y críticos los qu eno son enterprise (porque son más baratos) ... luego se quejan cuando pierden datos.

Claro, y seguro que ese era el disco que compró Carlos, precisamente, los de la serie Barracuda, típicos de Seagate >:-)

Pobre Carlos, no te metas con él que bastante sufre con la informática ;)

...

...

...

Muchas de las medidas del smart son realmente parámetros de la unidad, no del medio "superficie". Cierto, las unidades lectoras/grabadoras de dvd no dan esa información. Podrían. Es posible que haya software comercial caro, quizás asociado a buenas grabadoras, que hagan cosas de esas.

"Deberían" dar esa información. Yo prefiero pagar más por una unidad que sea capaz de analizar y reparar errores (por software, por hardware, como prefieran) que tener una "ruleta rusa" por DVD.

La ruleta rusa la tienes en los discos no-enterprise ;)

Y en los "enterprise". Hace poco tuve que actualizar el firmware por un fallo en esos discos, concretamente. El error (cuando se daba) era grave: la BIOS no podía acceder a los datos y el sistema operativo no podía iniciar.

Vaya, te ha tocado el 0.065% ;) [...]

...

...

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales.

Y los discos duros que usamos en casa también ... :(

Vale, pero en comparación con el uso que se les da [1] fallan menos :-P

[1] ¿Os imagináis lo que duraría un CD-RW (o un DVD-RW) que llevara un sistema operativo instalado? Ni un mes en funcionamiento, tienen límite de escrituras... y doy fe de ello :-)

Hay que volver a las tabletas de barro y las piedras cinceladas, han pasado cientos de años y se siguen leyendo ;) Hmmm ... tarjetas perforadas xD Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Wednesday 30 December 2009 14:35:03 Carlos E. R. wrote:

Así es. Cierto que son discos no enterprise, pero aún y todo... caray, que el disco que me acaba de petar es un disco de archivado, esto es: encender, grabar, apagar. Tiene sólo 500 horas de uso, y la garantía acaba en diciembre del 2012, luego tiene un año. Espera, que no me salen las cuentas: ¿son cuatro años de garantía? 2009, 2010, 2011, 2012.

Pues a ver como la haces efectiva. Segun la pelicula que nos contaron cuando se rompio uno de 1Tb hay que mandarlo a Belgica y los portes son 60 euros. Menos mal que le pase la pelota al de compras, al mes y pico me llego otro disco, pero me parece que no en muy buenas condiciones, solo lo probe un rato y me dio mala espina. saludos y buen fin de año (mañana vacas) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-29 17:52, Rafa Grimán wrote:

Hola :)

On Tuesday 29 December 2009 16:27:06 Camaleón wrote:

...

...

¿Por qué crees que los videograbadores domésticos han incluido discos duros en lugar de dejar la grabadora DVD? Porque no hay quien se acalre con los formatos que admiten (DVD-R, DVD+RW pero no DVD-RW) y son mucho más inflexibles, limitados... los usuarios prefieren volcar a disco, más rápido, más espacio, fácilmente ampliable...

El CD/DVD no es un uso recomendable para esa aplicación, y dista mucho del uso de archivado que yo le doy. Respecto a la diferencia entre - y + R, tengo por ahí un enlace que lo explica. No es sutil,, es transcendental. Lo tengo en el otro ordenador, no puedo empastarlo aquí.

Y porque: - se puede almaenar más info (programas)

- puedes borrar si no te gusta lo que has grabado

- la grabación es "más fiable" porque aseguras un flujo de datos constante a la grabadora

- ...

El hecho de poder borrar la información en cualquier momento es un inconveniente para ciertas aplicaciones, como las legales, en las que se debe asegurar que los datos históricos no se han alterado. ¿Leiste 1984? La historia se alteraba con fines de control del gobierno sobre la gente, alterando los registros históricos a conveniencia.

En HDD tienes los enterprise y los que no son enterprise. Los que todos tenemos en nuestros PCs y portátils son NO-enterprise. Mucha gente compra para su empresa y sus datos queridos y críticos los qu eno son enterprise (porque son más baratos) ... luego se quejan cuando pierden datos.

Pues claro. Los mios no son enterprise. Yo pensaba que los parámetros de los enterprise son para uso 24*7, que no es el mio: mi disco fallado tenía sólo 500 horas de uso, y tiene algo más del año, me parece. Ah, por cierto, ya me ha mandado un email Seagate confirmando que me lo envían, y yo se lo mandé el lunes por Seur... Muy rápido. Podría tenerlo mañana con suerte.

...

...

Pero el hecho es que, a mi, los DVDs que archivo no me fallan, y los discos duros sí. De momento.

Esa es un afirmación muy parcial.

Primero tendrás que hacer cuentas, fallos por cada byte escrito o leído, y luego, podrás sacar conclusiones.

Esto depende un poco del ámbito (IMHO).

En un ámbito oméstico, por ejemplo, más que por byte leído y/o escrito yo lo mediría por fichero perdido o no porque puedes tener un byte o bloque perdido o corrupto, pero sigues accediendo a la info y no notas gran cambio. Por ejemplo, en un juego, puedes perder algún que otro byte/bloque en un fichero de imagen y tu vista no lo percibe (mejor dicho, tu cerebro no lo percibe). También te puede ocurrir en una foto del verano o el vídeo que has grabado del bautizo de tu sobrino o el MP3 de turno que te has descargado. Generalmente, ese tipo de ficheros está grabado con algún tipo de compresión de tipo lossy, es decir, con périda de información por lo que no notarás gran diferencia si un byte o bloque está corrupto. Además de eso, no son datos "vitales".

Así es.

Lo mismo no se puede decir cuando trabajas, por ejemplo a 4k en cine o en entornos científicos en los que el cambio de un byte puede interferir en un cálculo de pesos o fuerzas o cualquier otra cosa dando lugar a una medición incorrecta: errores al predecir el tiempo, correas que no soportan el peso que deberían soportar, puentes no soportan determinadas velocidades de viento, errores clínicos, ... En el caso dle cine, el realismo no es el mismo o bien, al comprimir, puedes tener errores en la imagen que hagan que la imagen se vea mal (y los clientes se quejen).

O, por ejemplo, en fotografías de astronomía. No puedes comprimir con jpeg, tienes que usar gif, png, formatos de esos. Si la cámara es de precisión, los ficheros son tremendos. Se necesita la foto original para tratamiento posterior, como por ejemplo, realzar a falso color una zona de la imagen para poder ver un detalle que tiene sólo una variación de menos de 10 tonos en un rango de 255. Si comprimes con jppeg destruyes la posibilidad de estudio: no se trata de tener fotos bonitas. Y quien dice astronomía dice fotografías de satélite espía, es similar en este aspecto.

...

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales.

Y los discos duros que usamos en casa también ... :(

Hay DVDs de uso profesional para archivado permanente a 200 años. Y cuestan una pasta. La capa óptica es de "piedra". - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks6cT8ACgkQU92UU+smfQW52gCeKZj+KS2Y5dxIhGaePULyOc+p KXwAn1cY5bWRfMpdkH65JFQ6TsJgUEzB =UAY8 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-12-30 a las 10:37 +0100, Rafa Grimán escribió:

Hola :)

On Tuesday 29 December 2009 22:14:39 Carlos E. R. wrote:

...

Respecto a la diferencia entre - y + R, tengo por ahí un enlace que lo explica. No es sutil,, es transcendental. Lo tengo en el otro ordenador, no puedo empastarlo aquí.

Una vez me leí las diferencias, pero no me acuerdo, si lo puedes pegar, se agradece (es por no buscarlo yo, estoy en modo vago 0;)

http://www.digitalfaq.com/reviews/dvd-media.htm Reviews > Blank DVD Media Quality De ahí saco la calidad de cada modelo de dvd, independientemente del fabricante. Los DVD tienen un código (que se puede leer con dvd+rw-mediainfo), por el que mediante tablas, puedes saber quien realmente lo ha fabricado. Puede ser un disco de marca de renombre y estar fabricado en un sitio del montón de otro pais. Hay pocos clasificados como "de primera calidad". http://adterrasperaspera.com/blog/2006/10/30/how-to-choose-cddvd-archival-me... Lo empasto: Why DVD+R? - ---------- This is the most technical section of the article. If you don’t understand the basics of how CD/DVD media works, or find such technical discussions boring, skip to the next section. As I said earlier, DVD-R sucks for data preservation for three reasons: inferior error correction, inferior ‘wobble’ tracking, and the fact its data writing methods look like an un-needed halfway point between CD-R and DVD+R. The wobble tracking I shall explain first, then the error corrections method, then the specifics of ATIP/pre-pit/ADIP optimum power settings. For a CD/DVD burner to track where it is on the disc, it uses three things: the ‘wobble’ of the data track (where it actually wobbles back and forth instead of in a straight line) to tell where it is in the track, the position of the track to tell where it is on the disc, and some additional information on the disc to tell where the track (singular, as CDs and DVDs only have one track, and it is written in a concentric spiral) begins and ends. This additional information on a CD-R is called the ATIP (Absolute Time In Pregroove), which contains how long the track is, where it begins, what the maximum and minimum writing speeds are, what formula dye it uses, who actually made it, optimum power control settings, and error correction data. The ATIP is stored as a frequency modulation in the wobble itself. However, since the wobble changes subtly to encode data, it is impossible to use with the small size of tracks DVD requires, as electric noise in the laser pickup and wobbles introduced by the electric motor spinning the disc, these could easily be read as frequency changes in the real track itself. On DVD-R, they tried to solve the problem with something called ‘pre-pits’ where spikes in the amplitude of the wobble appear due to pits fully out of phase with the rest of the track (ie, between two spirals of the track, where there is no data). This can be viewed as a simple improvement over CD-R as it makes it easier to track the wobble (since the wobble is constant except for the easy to detect and remove spikes). Unfortunately, this method as one flaw: due to electric noise in the laser pickup, it would be very easy to miss the pre-pit (or read one that wasn’t actually there) if the disc were damaged or spun at fast speeds. The time to read a pre-pit is 1T (roughly .0000000038th of a second), which even for a computer can be easy to miss. DVD-R traded hard to track frequency changes for hard to read wobble-encoded data. On a DVD+R, however, they came up with a much better method. Instead of changing the frequency of the wobble, or causing amplitude spikes in the wobble, they use complete phase changes. Where CD-R’s and DVD-R’s methods make you choose between either easy wobble tracking or easy ATIP reading, DVD+R’s method makes it very easy to track the wobble, and also very easy to encode data into the wobble. DVD+R’s method is called ADIP (ADdress In Pre-groove), which uses a phase change method. With ADIPs’ phase changes, the direction of the wobble changes and continues on going in the exact opposite direction (ie, counter-clockwise to clockwise, or the reverse). For example, if the wobble was ‘going up’, the phase change causes it to instantly reverse direction start ‘going down’ no matter where it in the wobble cycle. The phase change is very easy to detect, and also continues for a set period (in this case, one 32T section of the track, or 32 times longer than the pre-pit method of DVD-R). The state of the phase change (clockwise or counter-clockwise) encodes the individual bits in each block In essence, with the phase change method, not only do you have an easy way of tracking the wobble, but you now have an easy way of reading wobble-encoded data. As I mentioned earlier, this wobble-encoded data includes error correction of wobble-encoded data itself. Error correction is the most important part of media, because if it does not work, then you’ve lost your data, even if there is nothing seriously wrong with the disc. The DVD-R specification states that for every 192 bits, 64 of them are not protected under any scheme, 24 of them are protected by 24 bits of parity, and the last 56 bits are protected by another 24 bits of parity. This weird (to put it mildly) scheme allows you to easily scramble or lose 25% of the data that is required to read your disk! This information is almost more important than the actual data burned on the disc itself. The DVD+R specification, however, states that for every 204 bits of information, it is split into four blocks of 52 bits containing 1 sync bit to prevent misreading because of phase changes, 31 bits of data, and a 20 bit parity (that protects all 32 bits of data). The sync bit is always the same value in all four blocks, and exists only to prevent phase inversions. Now, the third item on the list: how DVD+R discs burn better. As I said earlier, ATIP/pre-pit/ADIP stores information about optimum power control settings. This information is basically formulas stating how much output power is needed, what the laser startup power should be, and other pieces of information you require to properly burn a DVD. Optimum power control output is dependent on three things: burning speed, laser wavelength, and information given to the drive about the media. DVD-R basically fails on all three accounts because DVD+R simply includes far more information about the media in the ADIP data than DVD-R does in it’s pre-pit data. DVD+R includes four optimum profiles, one for four major burning speeds (usually 2x, 4x, 6x, and 8x, though this can change as speeds increase). Each of these profiles include optimum power output based on laser wavelength, more precise laser power settings, and other additional information. With this information, any DVD+R burner can far more optimize it’s burning strategy to fit the media than it can with DVD-R, consistently providing better burns. For comparison, DVD-R includes one profile, optimum power output based for that one profile only and uncalibrated towards what wavelength it is for, less precise laser power settings, and no other additional information. Typically, DVD-R burners have to already know how to burn a certain piece of media (and include this information in their firmwares) before they can properly burn to it. New media often is not properly supported. In addition to the optimum power control profiles, DVD+R also gives four times more scratch space for the drive to calibrate the laser on; more space can only improve the calibration quality. So, in short, DVD+R media exists to simply produce better burns and protect your data better.

...

...

Y porque: - se puede almaenar más info (programas)

- puedes borrar si no te gusta lo que has grabado

- la grabación es "más fiable" porque aseguras un flujo de datos constante a la grabadora

- ...

El hecho de poder borrar la información en cualquier momento es un inconveniente para ciertas aplicaciones, como las legales, en las que se debe asegurar que los datos históricos no se han alterado. ¿Leiste 1984? La historia se alteraba con fines de control del gobierno sobre la gente, alterando los registros históricos a conveniencia.

Sí, en los clientes de TV y seguridad que tenemos necesitan un sistema de archivado específico para eso que se llama "copia legal" y tienen que garantizar durante no sé cuánto tiempo la fiabilidad y la inmutabilidad de los datos. La banca y seguros también lo tienen.

Aunque claro, siempre se puede quemar un edificio ... ;)

Je! Se supone que debes tener dos edificios al menos, y bunkerizados, para esas aplicaciones. Creo que mi colegio de ingenieros alquila o lo que sea espacio de ese a un banco para guardar los proyectos (en PDF firmado).

Hace un mes, un cliente del mundo HPC me eneseñaba su primer cluster hecho con PCs. Le dije de broma que si se quería deshacer de toda esa metralla qu eme llamase que yo pasaba a recogerlo ;) Me dijo qu ela Ley le obliga a que los datos sean accesibles durante 20 años. Le dije que no quería los disocs duros y me dijo que no es eso, que el sistema tiene que arrancar y ser perfectamente funcional dentro de 20 años por temas legales y que no le apetecía migrar TODOS los datos al nuevo cluster así que se quedaba con el cluster antiguo.

¿Que tenía que garantizar el funcionamiento de los ordenadores con sus discos y todo dentro de 20 años? Imposible.

Me gustaría ver a los jueces, abogados, notarios y políticos que sacaron esa estúpida ley dentro de 20 años ... Como no estarán por aquí, les da igual: que apechugue el que viene detrás. Si es que les ponía yo a trabajar a todos a pleno sol ...

X'-)

...

Ah, por cierto, ya me ha mandado un email Seagate confirmando que me lo envían, y yo se lo mandé el lunes por Seur... Muy rápido. Podría tenerlo mañana con suerte.

A ver si hay suerte :)

Pues de momento, no ha llegado.

...

Hay DVDs de uso profesional para archivado permanente a 200 años. Y cuestan una pasta. La capa óptica es de "piedra".

Si valoras tus datos ...

Yo no tanto... lo que hago es tener dos, o más, copias. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks7YQoACgkQtTMYHG2NR9UuwACfR8FE+8E5wSmUE3ALSvC55fcj QmIAoJUYyaYcSnv78TXUxv2yE8dE48ha =d9AN -----END PGP SIGNATURE-----

El Wed, 30 Dec 2009 02:29:18 +0100, Carlos E. R. escribió:

...

...

Pero el hecho es que, a mi, los DVDs que archivo no me fallan, y los discos duros sí. De momento.

Esa es un afirmación muy parcial.

Bueno, es que soy parcial en esto, obviamente. Hablo por mi experiencia personal. Me han jodido.

Eso sí. Pero que "te hayan jodido" no es una variable de peso para calificar una tecnología. Mañana te puede pasar con los DVD que tienes de backup ¿y vas a decir que también son una porquería? Eso no es un análisis serio >:-)

...

...

- y eso escapa a mi control. Porque ni siquiera los de Alternate siguen la normativa de Seagate para empaquetado y envio de discos duros, un PDF de 15 páginas. ¡Me han llegado a veces discos duros con piececitas de la placa rotas...!

Reclama.

El que tiene daños visibles, que se vieron después de abrir todos los envoltorios, lleva funcionando varios años. Los daños no visibles, en ese o en otros, no los puedes demostrar, porque los discos duros no llevan etiqueta visible de daños por exceso de G.

Sí la llevan. O llevaban. El disco (Seagate) que puse ayer en la caja USB para probar el SMART (disco fabricado en el año 2.003 y en perfecto estado de funcionamiento y acceso) sí muestra ese dato en la pegatina del disco. Obviamente, ni el vendedor ni el transportista sabe lo que "transporta" como no lo indiquen expresamente en el paquete. También es posible que el disco haya salido mal de fábrica y que en la tienda, al probarlo, no les diera problemas. Las variables de error pueden venir de distintas fuentes.

...

...

Francamente, los DVDs son más robustos y estables, bien guardados. No es que me fie de ellos, por algo quemo dos copias de cada. Pero oye... es lo que hay, y de los discos duros tampoco me puedo fiar.

Los medios ópticos que tenemos en los equipos actuales son como una escopeta de feria, no son una alternativa profesional, pero viene bien en entornos caseros: son baratos, accesibles y no requieren cuidados especiales.

Pero los discos duros a los que tengo acceso también son caseros. Y los DVD también puedes manejarlos profesionalmente. Si lo haces, no fallan tanto como supones. Lo que pasa es que no son cómodos de usar, y los fabricantes han cortado demasiadas esquinas.

Existen DVDs garantizados por 200 años. Cuestan una burrada.

Desde que Seagate dejó de proporcionar una garantía de 5 años en toda su gama de discos duros y la rebajó a 3 años, intento comprar discos duros que sean de gama profesional, que es la única que ha mantenido la garantía anterior. Y aunque pueda parecer extraño, este tipo de discos duros "profesionales" no cuestan una "burrada" (250GB/62€, 500GB/86€, 1TB/96€). Tampoco necesito que duren 200 años :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Wed, 30 Dec 2009 08:25:17 +0100, carlopmart escribió:

Camaleón wrote:

...

Y aunque pueda parecer extraño, este tipo de discos duros "profesionales" no cuestan una "burrada" (250GB/62€, 500GB/86€, 1TB/96€).

Tampoco necesito que duren 200 años :-)

Einch??? Por curiosidad: ¿de que marca son esos discos de 1TB por 96€ de gama "profesional"?? Muy muy baratos para serlo ...

Cierto, ese dato está mal. Se ve a ojímetro que el precio no puede ser de sólo 10€ mayor que el de 500GB :-) El precio del disco del terabyte es de 134,90€, el de 250GB y 500GB es correcto. Todos son los de la serie Barracuda ES.2 (con interfaz SATA) que están disponibles en Alternate. Y no, no me parece un precio "desorbitado" para las prestaciones que ofrece. Casi cuesta más una tarjeta gráfica de gama media/baja >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sun, 03 Jan 2010 22:31:51 +0100, Carlos E. R. escribió:

El 2009-12-30 a las 02:29 +0100, Carlos E. R. escribí:

...

...

b) Programa de grabación

Programa de backup, kernel, filesystem (¿te recuerdo los bugs que he sufrido con xfs, reiserfs, ext3, con perdida de datos en todos ellos?), kernel.

Vaya. El bug del XFS que se bloquea sigue activo en 11.2, me he topado con él.

Jan 3 21:49:14 bombadillo kernel: [230760.519016] INFO: task xfsdatad/0:813 blocked for more than 120 seconds.

Y mucho más. Bloqueo de todos los filesystems XFS del ordenador, bloqueo de varias tareas, particiones imposbles de desmontar, tareas imposibles de matar, ordenador imposible de obedecer al halt. Necesita un botonazo.

Jovar... Y yo que lo creía resuelto. :-/

Ugh, qué feo :-( Espero que al menos no estuvieras con una operación de escritura en disco que te haya hecho perder datos. <comentario malvado on> Vas a tener que cambiar el nombre del equipo, de "bombadillo" a "ugluk" :- P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

hola yo tengo XFS en el home sabrias decirme que secuencia produce el fallo mencionado? es para evitar en lo posible, aunque nunca me ha pasado... Salu2 El Martes, 5 de Enero de 2010 00:37:28 Carlos E. R. escribió:

El 2010-01-04 a las 09:14 -0000, Camaleón escribió:

...

El Sun, 03 Jan 2010 22:31:51 +0100, Carlos E. R. escribió:

...

...

Vaya. El bug del XFS que se bloquea sigue activo en 11.2, me he topado con él.

Jan 3 21:49:14 bombadillo kernel: [230760.519016] INFO: task xfsdatad/0:813 blocked for more than 120 seconds.

Y mucho más. Bloqueo de todos los filesystems XFS del ordenador, bloqueo de varias tareas, particiones imposbles de desmontar, tareas imposibles de matar, ordenador imposible de obedecer al halt. Necesita un botonazo.

Jovar... Y yo que lo creía resuelto. :-/

Ugh, qué feo :-(

Bastante. Es el bug de antiguo... que creí resuelto, pero que continúa.

...

Espero que al menos no estuvieras con una operación de escritura en disco que te haya hecho perder datos.

Sí que estaba escribiendo, pero era una copia. Estaba preparando cuatro dvds de backup.

...

<comentario malvado on>

Vas a tener que cambiar el nombre del equipo, de "bombadillo" a "ugluk" :-P

¡Grrrr! :-)

-- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ El Universo es una de esas cosas que sucede de vez en cuando... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Si tengo XFS en LVM (supongo que LVM usa DM si no me equivoco) Nunca me habia pasado nada ( ano ser cloaro que los cuelgues que tengo se deban a esto y no al PLASMA de los coj***), no obstante en la 10.3 tenia el mismo setup y nunca me ocurrió nada... Miraré en los Logs por si encuentro alguna referencia Gracias y Salu2 On Martes, 5 de Enero de 2010 15:28:05 Carlos E. R. escribió:

Content-ID:

El 2010-01-05 a las 12:05 +0100, Angel Alvarez escribió:

...

hola

yo tengo XFS en el home

sabrias decirme que secuencia produce el fallo mencionado? es para evitar en lo posible, aunque nunca me ha pasado...

No te afecta salvo que esté cifrada, o quizás si accedes via DM.

La secuencia es simplemente al escribir un montón de datos (gigas), aunque me ha llegado a saltar con menos de 100 megas.

http://bugzilla.novell.com/show_bug.cgi?id=345039 http://bugzilla.novell.com/show_bug.cgi?id=567912 http://oss.sgi.com/bugzilla/show_bug.cgi?id=860

La gente de SGI dice que es un bug en el DM (device mapper). Ni 24 horas han tardado en decirmelo... la gente de Novell lleva dos años sin resolverlo.

-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Miércoles, 6 de Enero de 2010 17:47:35 Carlos E. R. escribió:

El 2010-01-06 a las 16:19 +0100, Angel J. Alvarez Miguel escribió:

...

Si tengo XFS en LVM (supongo que LVM usa DM si no me equivoco)

No lo se. Y no sé si es todos los DM, o sólo los encriptados. La gente de Novell hace tiempo que no hace caso a los informes de este bug. Sólo los de SGI me han respondido.

...

Nunca me habia pasado nada ( ano ser cloaro que los cuelgues que tengo se deban a esto y no al PLASMA de los coj***), no obstante en la 10.3 tenia el mismo setup y nunca me ocurrió nada...

Miraré en los Logs por si encuentro alguna referencia

No suele haber nada en el log. Depende de la versión del sistema, se presenta de una forma o de otra. El síntoma principal es que todas las lecturas y escrituras de cualquier fichero montado en XFS se bloquea, así como los procesos que lo hagan. No se puede desmontar esas particiones, ni se puede parar el sistema.

Yo lo que hago es desmontar todas las particiones, una a una:

umount -l ALGO &

Hay que hacerlo "lazy" o no funciona, y en background, o no retorna la consola.

Vaya parace pues una interaccion entre dm.-crypt y XFS ¿Has podido reproducirla con otros sistemas de ficheros? No incita a usar particiones encriptadas ¿eh? yo de momento uso encfs y pensabe pasarame el nuevo sistema, eto ¿como se llama? ah si! ecryptfs! aun no lo he probado pero parece interesante... Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Jueves, 7 de Enero de 2010 00:28:40 Carlos E. R. escribió:

Content-ID:

El 2010-01-06 a las 22:24 +0100, Angel J. Alvarez Miguel escribió:

...

On Miércoles, 6 de Enero de 2010 17:47:35 Carlos E. R. escribió:

...

Vaya parace pues una interaccion entre dm.-crypt y XFS

Sip.

...

¿Has podido reproducirla con otros sistemas de ficheros?

No. Me viene pasando desde la suse 10.3, y sólo con XFS. De hecho, creía que la 11.2 no tenía el problema.

...

No incita a usar particiones encriptadas ¿eh? yo de momento uso encfs y pensabe pasarame el nuevo sistema, eto ¿como se llama? ah si! ecryptfs!

aun no lo he probado pero parece interesante...

Por el nombre no conozco ninguna, no estoy tan ducho. Lo que uso es la que conoce el YaST, que ahora es tipo LUKS. Me gusta que se puedan montar los discos transparentemente.

Fíjate, que yo quemo DVDs encriptados con sistemas de ficheros XFS o Reiserfs; hasta FAT he usado, y el gnome los reconoce: meto el DVD y me pide la contraseña.

Eso está muy bien, creo recordar que ya lo mencionaste hace tiempo, pero no sé si diste la receta que usas para hacerlo, sería interesante saberla. :-) Salu2 -- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ MySQL3: Bueno, realmente ¿para que necesitas transacciones? -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Jueves, 7 de Enero de 2010 15:28:30 Carlos E. R. escribió:

El 2010-01-07 a las 09:24 +0100, Angel Alvarez escribió:

...

...

Fíjate, que yo quemo DVDs encriptados con sistemas de ficheros XFS o Reiserfs; hasta FAT he usado, y el gnome los reconoce: meto el DVD y me pide la contraseña.

Eso está muy bien, creo recordar que ya lo mencionaste hace tiempo, pero no sé si diste la receta que usas para hacerlo, sería interesante saberla. :-)

Puede que sí, pero luego si tengo un rato lo vuelvo a poner. Tengo mi propio readme para acordarme ;-)

Ok Se te agradece! :-) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-07 a las 21:15 +0100, Carlos E. R. escribí:

A ver, procedimiento para crear una imagen cifrada que se puede quemar directamente en un DVD para tener DVDs cifrados montables por el sistema. Funciona a partir de la 10.3, creo recordar. Antes era otro sistema (el de ahora es "LUKS").

Ah, se me olvidaba algo importante. Todo ese procedimiento se hace una sola vez, para crear la imagen cifrada. Una vez hecha, sólo teneis que: · montarla · copiar a ella todos los ficheros que querais guardar, con konqueror, mc, etc. Es transparente. · desmontarla · quemarla · comprobarla. Si quereis cambiar la contraseña, me temo que si hay que repetir casi todo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktGQxUACgkQtTMYHG2NR9XKbgCbBaxFktoO3qUK+VwAQ83b7lpP wGAAoJME29bfgVb2GqXRviDaAzUKbzrf =eLxf -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-07 a las 22:12 +0100, Angel J. Alvarez Miguel escribió:

On Jueves, 7 de Enero de 2010 21:15:18 Carlos E. R. escribió:

...

A ver, procedimiento para crear una imagen cifrada que se puede quemar

Muchas gracias de verdad, muchos aspectos los tenia mas o menos claros y habia probado cosas pero en conjunto me ha sorprendido.

Ignoro si más gente hace algo similar, casi todo es investigación mia.

...

Yo compruebo el quemado así (hacer un eject antes o fallará):

cmp --bytes=$(wc -c

Curioso, nunca se me ocurrió usar ese comando ... he llegado a hacer barbaridades con cut y md5sum para el mismo proposito

Eso no es idea mia O:-) Me la dieron en la lista inglesa o en la de seguridad hace tiempo, porque antes comparaba el dvd con su imagen y fallaba, aún siendo correcto. Al parecer el tamaño del dvd se completa el ultimo sector, y mi imagen era un poquito menor. Así que llegamos a la conclusión de que había que contar los bytes de la imagen, y esa fué la solución más guay, con diferencia. Y comparar a lo bruto todos los bytes es igual de rápido que hacer el md5sum de ambos (dvd e imagen), y marginalmente más seguro.

...

en mi script de qemado. Para montar el DVD, basta con sacarlo y meterlo, al menos el gnome os pedirá la contraseña y lo montará.

Ojo: no podeis tener simultaneamente montados el fichero imagen y el DVD, porque tienen el mismo uuid. Se podría cambiar el uuid después de quemarlo, supongo. No lo he probado. Eso es nuevo de la 11.2.

O supongo que te refiereres al uuid del XFS

Si pero no. Antes era el sólo el XFS el que tenía ese comportamiento, pero ahora es también el reiser. Todas las particiones tienen un identificador, que se ve en el /dev/disk/by-uuid/. Ahora mismo tengo cuatro imágenes de esas montadas en 11.2, y veo sus uuids apuntando a loop0, loop1, etc.

...

Y ya está. Creo que no me he olvidado de nada, o nada importante. Puede haber erratas.

Por cierto tendra algo qu ver el error de XFS y dmcrypt con las allocation units (ag groups) creo que xfs tiene un thrad por cada uno de estos ags.

Ni idea. No me han contestado nada los desarrolladores de suse/novell al respecto :-(

Eso me recuerda que nunca he sabido calcular los parametros del mkfs de XFS de manera optima (creo que mi /home en un pelin lento)

Yo tampoco sé, tengo los valores por defecto.

En definitiva gracias por la receta me la voy a leer bien varias veces (si plasma me deja)

Ya contarás :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktGcW0ACgkQtTMYHG2NR9WrogCeOBZduT+14qsW4kWemFLZKA9n 0ncAnjikr/18sgezrEDzh2g+aUcCfpMg =HH0B -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-08 a las 15:21 +0100, Rafa Grimán escribió:

En algunos casos, tener el log en otro disco mejora el rendimiento (si tenemos muchos ficheros pequeños y se hace mucho I/O, por ejemplo).

Hay una posibilidad interesante que sería tener el log en un disco duro "ram" (con pilas) o similar. No digo flash, ojo, esos escriben lento. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktHQZUACgkQtTMYHG2NR9WHDwCfU1p24cb6RFZcLUQ5Yg4dYEhm pi8AnjCPkTpBUIEV/shftOtjqJLeBVSM =f+6n -----END PGP SIGNATURE-----

El Sun, 27 Dec 2009 21:05:47 +0000, Camaleón escribió:

...

Es el problema con los malditos chipsets de USB storage, que no soportan SMART. Han hecho lo mínimo para que funcionen, pero te pueden dar unos sustos de tres pares de narices - y más teniendo en cuenta que al ser discos externos reciben más vibraciones y golpes que los normales.

Hay cajas con chipsets que sí soportan los comandos de smart. No me preguntes cuáles son ni dónde conseguirlas en España, pero sé que las hay porque lo pone (o lo ponía) en la página de smartmontools.

Parece que hay varias cajas externas USB que usan chipsets con soporte de SMART: http://sourceforge.net/apps/trac/smartmontools/wiki/Supported_USB-Devices De hecho, me pedí una para reyes (combo sata + ide) y parece que usa uno de esos chipsets: Bus 001 Device 003: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge La caja es esta: MS-TECH LU-377PS <http://www.alternate.es/html/product/Cajas_de_dispositivos_USB/MS-TECH/ LU-377PS/331932/?tn=HARDWARE&l1=Cajas&l2=Cajas+de+dispositivos&l3=USB> En cuanto tenga un momento miraré a ver si funciona con el smartmontools. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-29 19:46, Camaleón wrote:

El Sun, 27 Dec 2009 21:48:04 +0000, Camaleón escribió:

...

Parece que hay varias cajas externas USB que usan chipsets con soporte de SMART:

SMART Health Status: OK

Y el SystemRescueCD lleva la versión 5.38 también :-(. Tendré que esperar a que saquen la 5.39 que es la que actualmente está en el SVN para probar de nuevo:

*** Our work in the field USB bridges goes on. Experimental support for Sunplus USB bridges is available now with new option -d usbsunplus. JMicron USB to (S)ATA bridges with option -d usbjmicron[,1]. Thanks to the vendors for handing over the necessary specs. We are very interested in your test results with the new device types and collect all feedback on our USB-Support Wiki-Page. Get the ''current version'' from SVN and tell us about your experiences on the smartmontools-support mailing list. Binaries for Windows are available here. ***

O sea, hay que esperar. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks6Z5QACgkQU92UU+smfQWCUQCeLw31QSYEbVdpbyFp3pHUpjVl mbMAnRxNcmaLRKz2pXWFYeHzDYIjTNJu =lLgA -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-27 21:10, Carlos E. R. wrote:

Pero no es el caso con libxvid. Ahora mismo estoy probando unas series de 90 segundos a varias calidades (temperatura: 68..58, cpu 200% (de 400), modo "on demand" @2Ghz, 70..100%), y el disco apenas se mueve, ni registra en el gkrellm. Los fps oscilan entre 60 y 30, parece. Cuando está generando mpeg-4, entonces sí se ve la velocidad de grabación o lectura en el disco, pero es suficiente para cargar el sistema I/O, que lo he visto chascar a más de 50MiB/S sostenidos con rsync (o sea, con miles de ficheros sueltos).

Me está ocupando todos los cores, pero a una media del 50%.

Por curiosidad, los diferentes tamaños obtenidos a diferentes calidades: 27M Los 4400 T3E07 (20090926).1.copy.avi 18M Los 4400 T3E07 (20090926).1.mpeg.avi 58M Los 4400 T3E07 (20090926).1.xvid.avi 27M Los 4400 T3E07 (20090926).2.copy.avi 18M Los 4400 T3E07 (20090926).2.mpeg.avi 18M Los 4400 T3E07 (20090926).2.xvid.avi 27M Los 4400 T3E07 (20090926).3.copy.avi 12M Los 4400 T3E07 (20090926).3.mpeg.avi 13M Los 4400 T3E07 (20090926).3.xvid.avi 27M Los 4400 T3E07 (20090926).4.copy.avi 9.3M Los 4400 T3E07 (20090926).4.mpeg.avi 9.3M Los 4400 T3E07 (20090926).4.xvid.avi 27M Los 4400 T3E07 (20090926).5.copy.avi 7.9M Los 4400 T3E07 (20090926).5.mpeg.avi 8.0M Los 4400 T3E07 (20090926).5.xvid.avi 27M Los 4400 T3E07 (20090926).6.copy.avi 7.4M Los 4400 T3E07 (20090926).6.mpeg.avi 7.0M Los 4400 T3E07 (20090926).6.xvid.avi El ".1", ".2", es el factor qscale. Los mpeg4 son la codificación por defecto, y los xvid con - -vcodec libxvid -acodec libmp3lame. Los "copy" son la copia de 90 segundos del original para pocer comparar los tamaños resultantes. Los tamaños de xvid y mpeg son comparables, excepto el de calidad 1, que resulta mayor que el del original. Eso debe ser algún "extraño" del software. Hay otra manera de ocupar el sistema a tope, que es codificar varios ficheros simultáneamente. Ahora sí tengo la CPU al 100% todos los cores, los cuatro núcleos a alta frecuencia, la temperatura a 70, y el ventilador a casi 1200. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks3zx0ACgkQU92UU+smfQWFlQCgkrKB2YHi/XOpL2NsF7MfJ76n zLUAn2MYluc0f0i7kxzZWB8sANSnv1QZ =v/9S -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-12-22 a las 16:27 -0300, Alfredo Jesús Delaiti escribió:

Hola

He estado probando con cinelerra, que por cierto ya esta para bajar de packman y con lo que mejor queda son con los formato que he comentado anteriormente.

Ah.

Las pruebas que hice con mpg4 no salen bien. Pero puede que le este errando a algún parámetro.

Hay muchos, es verdad.

Lo que si te permite ver el flujo de imagen y sonido en la vista previa y se observan desfases entre voz e imagen.

Ah, ¿si? Pero la lastima es que en la máquina donde pondré el cinelerra no tengo sonido, salvo que me compre otra tarjeta - y tendré que hacerlo, me temo. No es plan. Me sugirieron una baratita aquí en la lista, miraré.

También permite ver más de un canal de sonido (por ejemplo castellano e inglés, puede que no se diga canal), por lo que sería bueno si tenes un poco de tiempo que lo instales (16 MB) de descarga si mal no recuerdo.

Desde luego que lo instalaré, cuando se libere la subida que tengo en marcha. Ahora mismo ni correo consigo enviar. Y luego quitaré unos cuantos de los que he probado que no sirven para nada, me lian el menú con tanta entrada no funcional. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksxK60ACgkQtTMYHG2NR9Xi/wCdGrU+gj9H3x9lkSM+4G/A2Spt mBAAnjWmae1OctOr3fpgNpugviYIM3R7 =by6b -----END PGP SIGNATURE-----

Hola El 22/12/09 22:49, Carlos E. R. escribió:

Uau. Que programa...

Tiene tantas cosas que el ffmpeg me parece sencillo :-O

Caray.

--

Si es algo complejo, de hecho en páginas de Cinelerra aconsejan a los recién iniciado que utilicen otros programas. Pero bueno lo profesional tiene esto, pero en contrapartida su potencia es "mucho" mayor. Si una persona se toma su tiempo para aprenderlo luego no lo cambia. Yo solo he hecho cortes y algún que otro efecto, pero creo que vale la pena aprender a usarlo. Saludos, Alfredo -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Carlos E. R. wrote:

Yo es que no edito videos, no tengo ni cámara. Como no sea la del movil (celular), que es malísima, y graba en 3gp...

- -- Saludos Carlos E. R.

Hola de nuevo, Carlos: Perdona si importuno (porque no estoy siguiendo el hilo mensaje a mensaje) pero como ya te dije también ando tras una solución para editar videos y, dado que la última vez estabas atascado con la sincro de audio, no se si habrás visto esto: "If you are editing a file with variable bitrate audio, run Audio->Build VBR Time Map before you do any editing. Otherwise your audio will be out of sync." de aquí: http://avidemux.org/admWiki/index.php?title=Cutting Saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Carlos E. R. wrote:

Voy a tener que hacer una lista con todos los sitios interesantes que hemos visto en este hilo.

- -- Saludos Carlos E. R.

Te lo agradecería mucho; se han dicho cosas muy interesantes, pero el hilo es tan largo que es muy difícil orientarse. Feliz Navidad a todo el mundo Toni -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-22 a las 00:02 -0300, Alfredo Jesús Delaiti escribió:

Hola

Con *Cinelerra* se puede poner el retardo de sonido en donde quieras, pero hay que hacerlo manual.

Pero de manera constante para todo el video. El inicio del video está sincronizado, y la segunda parte tiene un retardo de imagen (adelanto de sonido) de más de medio segundo.

Para ver si se podía bajar de manera aceptable el tamaño hice una conversión:

No preste atención a la configuración que tenía puesta por defecto, (NTSC) pero se ve que baja considerablemente el tamaño del archivo. El único problema que vas a tener de ahora en más es buscar donde hay retardos y corregirlos manualmente, puesto que el software no tiene suficiente nivel como para detectar el movimiento de la boca y sincronizar con el sonido de lo que se esta diciendo.

Pero se supone que hay marcas de tiempo, timestamps, en el código. Si han hecho un formato sin esas marcas es que son idiotas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkswsg0ACgkQtTMYHG2NR9XILACgk+ivUL1NdoGrkDbO1d5xG9VO 4z0An2cwAcCotfMaZx1T3vZwVPALRev/ =cIHa -----END PGP SIGNATURE-----