Ayer, Apple actualizó un documento de apoyo donde reflejaba el problema que algunos usuarios reportaron con iMovie para iOS. El problema en sí, era los formatos de vídeo que son compatibles con la aplicación. Por ejemplo conectamos a el iPad una cámara de video a través del kit de la cámara de conexión oficial o de escritorio a través de iTunes, estos clips de vídeo no aparecen en el navegador de vídeo en iMovie.

iMovie para IOS está diseñado para trabajar con vídeos grabados con un iPad 2, un iPhone 4 o un iPod touch (4ª generación). Para garantizar un rendimiento óptimo, los videos deben provenir de los anteriores dispositivos.

La solución que propone Apple es la siguiente:

Tienes que importar el clip a tu Mac y volver a codificar a formatos iOS, después los videos pueden ser importados a iTunes para sincronizar con el dispositivo. Hoy en día hay una gran cantidad de aplicaciones de terceros que pueden codificarlo directamente en tu dispositivo.

Vía | 9 to 5 Mac

Para hacer la prueba, se fueron a una Apple Store y probaron con todos los Mac que había allí. Para empezar, importaron un vídeo de dos minutos grabado desde un iPod touch 4G al iMovie del iPad 2 (a través del Camera Connection Kit) y al iMovie de los Mac (a través de la función de Importar desde la cámara).

Los resultados sorprendieron a todos, pues el iPad era con mucha diferencia el más rápido entre todos los Mac, incluso más rápido que el MacBook Air con disco SSD. El más cercano fue el Mac Pro, al cual el iPad 2 doblaba en velocidad. Pero claro, estos resultados aunque ciertos, hay que cogerlos con pinzas:

• El vídeo del iPod touch que recoge el iPad es totalmente nativo a su formato, por lo que añadido al procesador gráfico optimizado para descodificar vídeo en H.264, la tarea es coser y cantar.

• iMovie en Mac hace una reconversión de todos los vídeos que importamos para supuestamente trabajarlos más fluidamente después. A eso hay que añadirle que iMovie para Mac funciona a 32 bits, y no está optimizado para ninguna de las tecnologías de las que Snow Leopard está preparado (véase: Open CL y Grand Central). En un Mac, este trabajo le toca al procesador, el cual no está optimizado para estas tareas. De ahí que el iPad gane.

En el segundo test, crearon un proyecto en blanco en iMovie, al que añadieron el mismo vídeo y posteriormente lo exportaron a 720p. El resultado fue otra vez a favor del iPad, que tardó 1 minuto 56 segundos. Sí, el iPad 2 tardó menos en codificar el vídeo de lo que dura en sí:

• Esto pasa porque ni siquiera la propia Apple (que invita a los desarrolladores a programar sus aplicaciones en 64 bits, y que las preparen para múltiples hilos de ejecución), no es capaz de dar ejemplo utilizando las tecnologías que ponen a disposición de todos en sus propias aplicaciones. Sin ir más lejos, Final Cut es incapaz de aprovechar toda la potencia en un Mac Pro de 16 núcleos porque éste es no utiliza todos los hilos de ejecución de los procesadores.

En el test final, hicieron algo más complejo, como añadir títulos y música al vídeo original, añadiendo una imagen que abría y cerraba el vídeo. En esta ocasión el iPad no fue tan rápido, pues aquí ya no se convertía vídeo a H.264 a pelo, sino que entraba en juego la CPU que tenía que renderizar los efectos. Por ello, el MacBook Pro de 17″ ganó al iPad 2, y el resto de Macs no se alejaron tanto de los resultados del iPad 2.

Esperemos que algún día Apple se de cuenta, y sea capaz de hacer aplicaciones de escritorio que realmente aprovechen las máquinas sobre las que corren. Un iMovie en 64 bits realmente optimizado para trabajar conjuntamente con varios núcleos de la CPU y ayudado de la GPU, sería increíblemente rápido. En el iPad, estando optimizado ya vemos cómo puede rendir; ahora sólo nos falta ver cómo sería un iMovie optimizado para Mac.

En cuanto al apartado de vídeo, la Flip Video M2120 alcanza el primer puesto seguido muy de cerca por el iPhone -aunque la calidad de audio no es del todo buena-, dejando el último lugar al HTC EVO. (Todos los vídeos aquí). Con todo esto, sólo faltaba esperar algo de tiempo para que algún usuario creara algo bueno usando esta cámara y las posibilidades de la edición con la aplicación de iMovie, y ya ha llegado el momento, el resultado: muy bueno.

Por cierto, mientras escribíamos estas líneas ha surgido un vídeo donde podemos comprobar que la app de iMovie ha sido portada con éxito para utilizarse en un iPhone 3GS y aunque algunas características se encuentren con lentitud y otras ni funcionen -exportar a 720p, ya que no graba a esa resolución- parece ser una buena solución para la edición de vídeo.

Vía MacWorld | iPhoneros

Como seguro que estáis cansados de escuchar millones de cosas sobre el nuevo iPhone 4, simplemente os dejamos con el vídeo de su presentación, que enseña todas las nuevas prestaciones, para ir poniéndonos con los dientes largos hasta julio. Sin más, el iPhone 4:

Ayer Apple lanzó una nueva actualización de iMovie. En principio corrige sólo fallos como comúnmente hacen este tipo de aplicaciones. Sin embargo, también trae consigo el soporte a un nuevo códec de vídeo llamado iFrame. Esta nueva inclusión podría haber sido incluída en iMovie ’10, pero Apple ha decidido lanzarlo dentro de una actualización menor. A continuación pasamos a profundizar en este nuevo formato:

¿Qué es iFrame?

Apple ha creado iFrame con el objetivo de tener disponible un códec que acelere la importación y edición del vídeo conservando el formato nativo en el que se graba evitando así conversiones y pérdida de calidad innecesarias. iFrame está basado en estándares como H.264 y AAC y genera archivos pequeños además de simplificar el proceso de trabajo con los vídeos grabados con nuestra cámara.

Para trabajar con este nuevo formato, obviamente necesitamos cámaras que lo utilicen. De momento sólo dos cámaras de Sanyo lo soportan: la HD2000A y la FH1A.

El códec iFrame captura vídeo en formato H.264 a una resolución de 960×540 (un cuarto de resolución de Full HD 1080p). Debido a que este formato no es Full HD, podemos cambiar el formato de grabación de la cámara a 1080p sin ningún tipo de problema.

Un poco de Historia

Las primeras cámaras de vídeo digitales empezaron grabando en MJPEG (Motion JPEG, un conjunto de imágenes fijas JPG). Debido a la enorme ineficacia de este códec se pasó al tan popular DV. El DV nos proporcionaba una buena calidad de imágen, pero no estaba especialmente indicado para su edición bajo QuickTime, puesto que usa píxeles no cuadrados que están orientados a la resolución y aspect ratio de la TV convencional.

Los píxeles no cuadrados o non-square pixels

Los píxeles en el ámbito informático son cuadrados. En una pantalla de ordenador, una línea de 100 píxeles verticales tiene el mismo tamaño que una línea de 100 píxeles horizontales.

Los píxeles en el ámbito de la TV que no es de alta definición no son cuadrados. En una pantalla televisión, una línea de 100 píxeles verticales no tiene el mismo tamaño que una línea de 100 píxeles horizontales.

En el ámbito de la Alta Definición (720p y 1080p) los píxeles sí son cuadrados

El término que describe la cuadradicidad de un píxel es el píxel aspect ratio (no confundir con Picture aspect ratio de las pantallas: 4:3 o 16:9). Éste expresa en forma de fracción el tamaño de los píxeles horizontales (x) dividido por el tamaño de los horizontales (y). El aspect ratio de para los píxeles cuadrados es 1/1.

La imagen que se muestra a continuación ilustra mucho mejor lo que os acabo de explicar. Para más información de los Non-square píxel podéis acceder a esta página.

JVC, Canon, Sony y Sharp decidieron mejorar el ya ampliamente instaurado DV con el códec HDV, que usaba compresión MPEG-2 (similar a la de un DVD). A diferencia del DV que usa Program Stream, el HDV usa (al igual que el DVD) Transport Stream que está mucho más optimizado para la transmisión de datos.

Uno de los principales problemas del HDV es que está mayormente orientado a la reproducción en vez de a la edición, por lo que importar una película HDV a iMovie necesita un códec intermedio que haga más liviana la edición del vídeo, pero que a su vez requiere de mayor espacio en disco.

Por último apareció el AVCHD, que es el más extendido hoy día en las cámaras de Alta Definición. El AVCHD está basado el códec H.264. Sin embargo, las cámaras aún generan un archivo MPEG en vez de un sencillo MP4, que es mucho más fácil de editar. Es por ello que para editar los vídeos AVCHD de las cámaras, iMovie sigue necesitando importar y recodificarlos en el códec intermedio Apple Intermediate Codec, que necesita gran cantidad de espacio en disco. En el caso de Final Cut Pro, se convierte al AppleProRes.

¿Por qué iFrame?

Por fin, iFrame usa el mismo estándar MPEG-4 H.264. Con esto Apple pretende simplificar el proceso de importación a los usuarios, haciéndo más facil y rápida la edición de vídeo de videocámaras.

El nombre de este nuevo formato parece ser la fusión de la clásica i de los productos de Apple, y los Intraframes de los MPEG (son los Fotogramas Clave o Keyframes en la grabación de vídeo).

Lo que aún no me queda muy claro es por qué el iFrame no es Full HD considerando los días en los que estamos, y se queda en algo más que un VGA de alta resolución panorámico. Quizás Apple opte por implementar el iFrame HD en Final Cut Pro, el cual no se ha visto aún beneficiado de iFrame.

Vía: Apple Insider