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