Optimización para trabajar con video en el DAW

#1 por Javier Zumer el 07/06/2012
Hola. He estado buscando por el foro y de este tema he encontrado solo unos pocos hilos antiguos que no resuelven demasiado.
Por eso os enlazo este artículo que acabo de colgar en mi blog. Agradecería mucho que deis sugerencias o me habléis de vuestra experiencia para completar la información.

Un saludo!

http://www.javierzumer.com
contactme[arroba]javierzumer.com

Subir
#2 por TLM The Last Monkey el 07/06/2012
Muy interesante!

Yo he de decir algo al respecto de lo que comentas. Tengo comprobado que así me funciona siempre:

Película de QT (no mp4) en códec h.624 y a 720p. Esto me funciona perfectamente en un Imac con 2G de RAM (generación de los blanquitos) con ProTools LE8, pero me parece interesante lo de la secuencia de imagenes, aunque creo que consumirá más que el h.264. Lo probaré en el futuro! (aún queda pendiente lo de las ganancias, pero aún no he tenido tiempo!!!)

Un abrazo!

--
TLM The Last Monkey: Producción de Sonido

Jorge Flor: 651 17 87 43
Leti Argudo: 680 36 10 19
info@tlm-thelastmonkey.com
http://www.tlm-thelastmonkey.com

Subir
#3 por zaratero el 08/06/2012
Hola,
Yo utilizaría un formato no comprimido y un archivo grande, que necesitará más lectura de HD ( utilizando un disco exclusivo para video, igual que con audio) pero menos CPU. MJPG va bien y no consume CPU, sino disco, porque no tiene que procesar los frames ni crearlos, solo lanzarlos en sincro, al contrario que H264, que pesa muy poco, pero los frames tienen que descomprimirse a tiempo real, poco HD, mucha CPU.

H264 es genial para preview, pero en sincro a mi me parece poco fiable, los frames engañan a veces, por lo menos en mis ordenadores. Creo que salvando distancias es un problema que pasa con todos los formatos comprimidos alguna vez.
He hecho algún proyecto sencillo y rápido en H264 por comodidad y me ha funcionado OK, pero de vez en cuando ocurría que tenía que hacer un scroll breve para estar seguro de que iban juntos, y no me fío para nada en proyectos más serios.

Un ordenador más viejo con MTC sobre LAN puede funcionar muy bien y quitar toda la carga del ordenador principal también. Especialmente asequible si usamos formatos no comprimidos para estos ordenadores viejos que los reproducen sin sudar.

cueaudio.org

Subir
#4 por TLM The Last Monkey el 10/06/2012
Interesante!! Muy interesante!! Haré pruebas de lo que comentáis!

--
TLM The Last Monkey: Producción de Sonido

Jorge Flor: 651 17 87 43
Leti Argudo: 680 36 10 19
info@tlm-thelastmonkey.com
http://www.tlm-thelastmonkey.com

Subir
#5 por Javier Zumer el 12/06/2012
Gracias por vuestras respuestas.
Muy interesante lo que apuntas, Zaratero.

Una duda. Cuando dices lo de usar un HD diferente, supongo que te refieres a diferentes discos físicos no particiones, ¿verdad?
Entonces, serían 3 HD's:

-S.O. + Pro Tools.
-La sesión de Pro Tools con la carpeta Audio Files.
-El vídeo de marras.

¿Estos discos duros "extras" pueden ser firewire/usb o deben comunicarse más rápido?
¿Y en todo esto como encajan los discos SSD?

Gracias.
Un saludo!

http://www.javierzumer.com
contactme[arroba]javierzumer.com

Subir
#6 por zaratero el 15/06/2012
Hola,
Sí, me refiero a 3 discos como describes Javier. Las particiones a mi me van peor que sin particionar. Pueden ser de cualquier tipo, siempre que no les pidas más de lo que dan. Lo mejor es hacer tests de rendimiento y comparar y apuntar los límites del sistema (en datos/s), que dependerán de un montón de cosas, y poder monitorizar en los grandes proyectos por dónde nos estamos pegando con el límite. Si usas VIs, ese disco debe ser rápido, si usas muchas pistas el de audio,....

Mis esquemas:
*g5 > SO HD interno( 3 particiones con 3 SOs) >Audio HD interno > Librerías HD ext eSATA > BCKUP HD ext eSATA > Video HD FW800 > Time Machine HD USB dock

*Macbook > SO HD interno > Audio HD FW800 > Librerías en g5 por RED > BCKUP en g5 por RED > Video en G5 esclavo por MTC sobre RED > Time Machine HD USB dock

cueaudio.org

Subir
Respuesta rápida

Regístrate o para poder postear en este hilo