Si querés mostrar flash video, tenés 3 opciones primarias:

1. Ignorar el ancho de banda del usuario y solo mostrar una versión del archivo usando un buffer estimado.
2. Mostrar diferentes versiones del mismo archivo (por ejemplo alta y baja resolución) dependiendo del ancho de banda del usuario y usando un buffer con un tamaño estimado o bien, calculando el bufer adecuado.
3. Mostrar una versión encodeada razonablemente y usar un buffer dependiendo de la conexión del usuario

Tomá en cuenta que me refiero a progressive download y no al Streaming (que es la mejor opción en caso de videos grandes), tampoco me refiero al video incrustado en la linea de tiempo de flash.

Volviendo a lo anterior, basandonos en como y donde querés mostrar el video la opción 1 solo es recomendable si el video está muy bien codificado y si conoces perfectamente a quién irá dirigido, la opción 2 es la más laboriosa (tener que crear las diferentes versiones…) pero funciona si puedes vivir con el hecho de que quienes tengan un menor ancho de banda van a ver una versión de mala calidad y pobre del video. La opción 3, ronda en medio de las opciones 1 y 2, además de que es algo que podés hacer siempre sin demasiado esfuerzo.

Muy bonito, pero cómo calculo el buffer?

Necesitás conocer tres valores:

1. El largo de tu flv en segundos
2. El bitrate de tu flv en kilobits por segundo
3. El ancho de banda del usuario en kilobits por segundo

Si conocés estos valores podés calcular el tamaño del buffer con una formula bastante simple. Que de donde sacás esos numeritos? El primero (el largo del flv) puede encontrarse en el
metadata del flv propiamente y se incluye cuando se codifica el video, el segundo (el bitrate) se encuentra también en el bendito metadata. El tercero, como era de esperar, es más complicado de conseguir y no hay una propiedad o metodo en flash que nos dé el ancho de banda del usuario, entonces hay que conseguir ese valor mediante un chequeo la primera vez que el usuario descarga la aplicación, por ejemplo.

La formula es la misma que podés encontar en el DevNet de Adobe con la principal diferencia de que aquí ya está encapsulada en una clase.
Podés encontrar algo exagerado poner solo un método con unas cuantas lineas de código en su propia clase pero es conveniente si lo deseas reutilizar en otros proyectos, y en lo personal, prefiero tener cada cosa con su cosa. Además podrías agregarle otros métodos que sean útiles para el manejo de videos y cambiarle el nombre a “VideoUtil” o algo por el estilo.

Acá está el BufferCalculator.as:

class cr.yeco.video.BufferCalculator {

// relleno del buffer en seg.
// Debe ser al menos el doble de largo que el intervalo de frames por segundo, ex:
// intervalo de 30 en 30fps --> min. 2 sec.
public static var BUFFER_PADDING:Number = 3;

public function BufferCalculator() {

}

// Largo del FLV en seg., flv Bitrate y ancho de banda in kBits/Seg
public static function calculate(flvLength:Number, flvBitrate:Number, bandwidth:Number):Number {

var bufferTime:Number;

if (flvBitrate > bandwidth) {
bufferTime = Math.ceil(flvLength - flvLength/(flvBitrate/bandwidth));
} else {
bufferTime = 0;
}

bufferTime += BUFFER_PADDING;

return bufferTime;

}

}

Ya tengo la clase, pero con qué la lleno?

Bien, la próxima parte es como obtener los valores con los que vas a correr el método calculate(). Si no tenés tu forma de calcular el ancho de banda podés usar esta clase (descargar), en el archivo que se descarga al final del post hay un ejemplo comentado sobre cómo usar la clase.

Básicamente carga un archivo que vos especificás por unos cuantos segundos y luego calcula y te dice cual es el ancho de banda. Lo bueno es que solo es necesario correrlo una vez (por ejemplo al iniciar la aplicación). La clase guarda los valores en objetos compartidos y corre nuevamente cuando el tiempo ha expirado. Desde luego que no es un método a prueba de balas: el ancho de banda del usuario puede variar mientras usa la aplicación etc. Pero es mucho mejor que nada. Lo siguiente es un ejemplo de como usar las dos clases juntas con el componente FLVPlayback (el código puesto en el frame 1):

Stage.scaleMode= "noScale";

import cr.yeco.loading.BandwidthDetector;
import cr.yeco.video.BufferCalculator;
import mx.utils.Delegate;

var BANDWIDTH:Number;

function onBwDetect(evObj:Object):Void {

BANDWIDTH = evObj.data.kBitsSec;
fp.contentPath = "flv/trusted_computing.flv";

}

function onFlvMetaData(evObj:Object):Void {
fp.bufferTime = isNaN(BANDWIDTH) ? 3 : BufferCalculator.calculate(fp.metadata.duration, fp.metadata.videodatarate, BANDWIDTH);
}

function init():Void {

fp.addEventListener("metadataReceived", Delegate.create(this, onFlvMetaData));

var bwDetector:BandwidthDetector = new BandwidthDetector(this, 0);
bwDetector.addEventListener("onDetect", Delegate.create(this, onBwDetect));
bwDetector.expireTime = 86400;
bwDetector.detect("img/bandwidthCheck.jpg", 3);

}

init();

Podrías mejorarlo más, por ejemplo poniendo este codigo en una clase separada en lugar del frame 1 y encapsulando el detector de ancho de banda y el calculador de buffer en una clase de decoración para el componente FLVPlayback y así cada vez que se crea una instancia de FLVPlayback el tamaño del buffer se configura de forma automática, sería un buen addon, pero aún más importante es asegurarse de que el flv fué encodeado con el bitrate correcto, y el intervalo entre keyframes adecuado.

Recordá que en DevNet siempre hay textos interesantes con respecto al tema, además de buenas practicas trabajando con video.

Acá podés descargar todos los archivos.

No uses getURL(); en ninguna parte de tu código, SWFAddress usa ExternalInterface internamente y van a haber serios bugs si usas getURL (para llamar el urchinTracker();, por ejemplo). Simplemente usa ExternalInterface y todo va a ir bien. No sé si es un problema con getURL(); y ExternalInterface en general o solo pasa en esta combinación en particular.

SWFAddress llama al urchinTracker(); internamente. Esto podría ser bueno si solamente necesitas trackear cambios de url o cosas sencillas… pero si deseas un reporte mas detallado lo mejor es que dependas de tu propia aplicacion para llamar el urchinTracker(); y no de SWFAddress, para esto, creas tu script y luego comentas “track.call(this)” en las lineas 202 y 303 de swfaddress.js.

Eso es todo.

Hasta aquí todo perfecto. El problema surge cuando queremos incorporar a nuestro proyecto (en mayor o menor medida) algunos módulos basados en FDS (Flex Data Services), ahora conocido como LiveCycle Data Services. Esto nos obliga a montar un servidor de aplicaciones J2EE (como Tomcat) junto a nuestro Apache.

La verdad es que para mi proyecto, dadas las dimensiones que ya tiene y a los tiempos de desarrollo tan ajustados, me resulta inviable plantear un refactoring del código para basar el proyecto totalmente en LCDS. Al menos para la primera revisión estable, he decidido mantener AMFPHP e incorporar LCDS para implementar un módulo de Reporting y quizás alguno más para generación de listados de datos y gráficas empresariales a tiempo real (mediante data-push).

Todo esto me hace plantear lo siguiente: ¿a caso no es posible, o incluso deseable, desarrollar un proyecto Flex en el que se incluyan partes con AMFPHP, LCDS e incluso Red5?

En un intento rápido, he tratado de cargar un módulo de generación de PDF existente en Tomcat desde la aplicación principal (basada en Flex+AMFPHP) sin muy buenos resultados.

El problema es que hay muchos problemas y me explico: el app principal corre en Apache (puerto 80) y tomcat en el 8080. Mi aplicación principal es un Flex compilado, mientras que la parte en LCDS es MXML compilado en el servidor. Al llamar de uno a otro, podemos tener problemas de violación de la sandbox y lo que es peor, problemas con los contextos:

En LCDS, configuramos la compilación, linkado, “destinations” y demás mediante ficheros de configuración xml. Concretamente, en el fichero services-config.xml especificamos los endpoints de cada uno de los canales con los que queremos trabajar. Esto es el extracto perteneciente a AMF:

[code]

He observado que, cuando se llama al módulo desde la aplicación principal (en Apache), dicha información es desconocida y por lo tanto, el módulo no funciona ni para atrás.

Seguramente todo es más fácil de lo que pienso, pero ante todo soy desarrollador, NO administrador; por eso, aunque esos parámetros pueden indicarse tanto en el fichero flex-config.xml como en la propia linea de comandos del compilador, creo muy tedioso e indeseable el estar trasteando con esos parámetros. De hecho y por experiencia, creo que estar “chapuceando” las instalaciones para salir del paso se convierte en un problema insalvable a la larga.

Para mis necesidades, creo que la mejor solución es la siguiente: hacer hablar correctamente a Apache con Tomcat.

Para esto último, lo único que necesitamos es instalar Apache Tomcat Connector. Esto es simplemente un módulo de Apache como otro cualquiera que canaliza, según un fichero de reglas, todas las llamadas necesarias a Tomcat una vez recibidas por Apache y de forma transparente.

Esto nos proporciona enormes posibilidades no sólo para integrar en nuestras aplicaciones módulos de distintas procedencias de manera sencilla; sino que además nos permitirá servir aplicaciones J2EE desde varios servidores a través de Apache (Apache se convierte en una especie de “proxy”), habilitar mecanismos de balanceo de carga, etc….

Al grano….

Instalación de Apache+PHP+MySQL+AMFPHP.

Creo que este apartado no requiere de muchas explicaciones y hay montones de tutoriales por toda la red. En resumen y para los impacientes: descarga XAMPP para Mac Osx, Windows o Linux y descarga e instala AMFPHP como corresponda.

Instalación de Apache Tomcat y LCDS

- Descarga Apache Tomcat desde la web oficial e instala de la manera convencional. Arranca el servicio para comprobar que todo está OK y a continuación paralo nuevamente.

- Descarga el instalador de LiveCycle Data Services desde la web de Adobe.

- Inicia la instalación indicando que quieres una instalación sobre un servidor J2EE existente (no con el JRun integrado). Selecciona como directorio de instalación el directorio principal de aplicaciones de tu Tomcat (por ejemplo, D:\Tomcat_5.5_lcds\webapps). Esto añadirá a dicha carpeta varios ficheros .war que habilitarán LCDS sobre Tomcat.

- Inicia Tomcat y espera un pelín. Tomcat automáticamente se encargará de expandir los ficheros .war de LCDS, creando sobre nuestro directorio webapps correspondiente una nueva carpeta por cada fichero .war existente.

- Una vez compruebes de que todo está arrancado, abre las aplicaciones de ejemplo de LCDS para comprobar que todo está OK: http://localhost:8080/samples.

¡¡Ya casi estamos!!

Instalación y configuración del Apache Tomcat Connector.

Lo primero que deberemos hacer es descargar el módulo correspondiente a nuestra versión de Apache desde esta dirección.

Dentro encontrarás una serie de ficheros, entre los cuales están las librerías .so para nuestro Apache y que tienen la siguiente forma:

[code]mod_jk-apache-(version_apache).so[/code]

Tan sólo deberemos descargar el fichero correspondiente a la (version_apache) que tenemos instalada.

Ahora guardamos el fichero descargado en el directorio de módulos de apache (en Windows suele ser c:\apache\modules) y renombrar el fichero al nombre mod_jk.so. Este paso es muy importante si queremos evitar problemas a posteriori.

Para mantener las cosas en orden, vamos a crear un fichero de configuración .conf independiente del principal (htttpd.conf).

Creamos un nuevo fichero de texto llamado tomcat.conf con el siguiente contenido:

[code]# Carga del módulo apache
LoadModule jk_module modules/mod_jk.so
# Si tenemos instalado una versión de Apache < 2.x quizás debamos
# descomentar esta línea para habilitar
# AddModule mod_jk.c
# Ubicación del fichero de configuración del conector (workers.properties)
# Es deseable que ubiques el fichero en el directorio conf para que esté cerca
# del httpd.conf y lo tengamos todo controlado
JkWorkersFile conf/workers.properties
# Dónde poner el fichero de memoria compartida del módulo
JkShmFile logs/mod_jk.shm
# Dónde poner el fichero de log del módulo
# Es deseable que ubiques el fichero en el directorio de logs de
# Apache para tenerlo todo controlado
JkLogFile logs/mod_jk.log
# Especificamos el nivel de log [debug/error/info]
JkLogLevel info
# Especificamos el formato timestamp para el fichero de log
JkLogStampFormat “[%a %b %d %H:%M:%S %Y] ”
##################################################
# REGLAS DE REDIRECCIÓN A TOMCAT
##################################################
# Aquí añadiremos tantas reglas de redirección como sean necesarias.
# Es importante dejar claro que cada regla de redirección va dirigida a
# un “worker” particular. Podemos tener tantos workers como queramos
# y cada uno de ellos puede ser un Tomcat diferente.
###################################################
#
# Enviamos todo para el contexto /samples al worker llamado “worker1″
JkMount /samples/* worker1[/code]

Ahora creamos el fichero workers.properties en la ubicación que hayamos indicado en el fichero anterior y lo rellenamos con el siguiente contenido:

[code]#Definimos un worker real usando ajp13 (más sobre esto en la doc oficial)
worker.list=worker1
# Propiedades del worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009[/code]

Por último, tan sólo nos queda incluir nuestro fichero de configuración para su carga con Apache:

Edita el fichero httpd.conf y añade al final del mismo las siguientes líneas:

[code]# Configuración del conector Apache-Tomcat
Include conf/tomcat.conf[/code]

Pruebas y conclusiones finales.

Para probar que todo está OK, tan sólo debemos abrir http://localhost/samples. Si todo ha ido bien, ¡¡estamos viendo los ejemplos de LCDS sin usar el puerto 8080!!.

Fantástico, a mi me ha facilitado muchísimo el trabajo.

Si tienes algún problema, seguramente Apache ni te cargue correctamente. Intenta arrancar Apache desde consola para así poder ver posibles errores de sintaxis en alguno de los fichero que hemos creado. Lo más probable es que hayas descargado la versión del mod_jk.so errónea para tu versión de Apache.

Ahora podemos demostrar de manera muy rápida la integración y uso directo de Flex en el que cargamos un módulo en Tomcat+LCDS desde una aplicación con Flex+AMFPHP:

Código en aplicación ERP.swf (Apache+AMFPHP):

[as]
url=”http://localhost/samples/pdfgen/pdfgenModule.swf”
height=”100%” width=”100%” x=”0″/>

[/as]
Este es el contenido (simplificado) de pdfgenModule.swf:

[as]




fault=”faultHandler(event)”
result=”resultHandler(event)” />[/as]

Como podemos observar, en este código usamos LCDS para llamar a un destination de tomcat. Lo más importante es que ahora gracias a nuestro conector, el funcionamiento es transparente y se simplifica mucho la realización de módulos independientes e incluso, que varias personas trabajemos en cada parte sin saber muchos detalles acerca de la instalación y configuración puntual que haya sobre Apache, Tomcat, etc.

Si te sirve me cuentas.

Bret Victor de WorryDream publicó recientemente un documento llamado Magic Ink: Information Software and the Graphical Interface en el que muestra de un modo bastante claro y con ejemplos una perspectiva diferente del diseño de interfaces y su aplicación a productos de información.

Muy bueno

Entre sus novedades están – Soporte transparente de aplicaciones HTML, mejoras en el API de windows, navegador de archivos nativo, API de conectividad a servidores y servicios, Drag and drop, soporte para el clipboard (copy, paste) y posibilidad de integrar una base de datos entre otras cosillas.

También sacó a la luz su Adobe AIR Extension para Dreamweaver… que vendría siendo una utilidad que permitiría crear y previsualizar aplicaciones .air dentro de nuestro querido Dreamweaver CS3 permitiendonos crear aplicaciones de escritorio usando nuestras habilidades para crear web, esto suena interesante no?…

Un poco más de info disponible en la web de Adobe®

http://labs.adobe.com/wiki/index.php/AIR:Dreamweaver_CS3_Extension

Además en caso de no tener instalado Flash Player, sIRF lo detecta y nos muestra el texto original. Por otra parte no es recomendable para textos grandes, sino para títulos, encabezados y muy pequeños párrafos.

Entonces, si tenemos un texto como este:

Con sIRF veremos:

En el ejemplo se ve el texto con la fuente Scriptina . Y aca no hay limite, se puede utilizar cualquier fuente…

Implementación

En primer lugar necesitaremos 4 archivos que vienen dentro del paquete de descarga [ Bajar ]

- sifr.js : Es el script que permitirá intercambiar el texto HTML.

- sIFR-screen. css y sIFR-print.css : son los estilos en cascada necesarios para mostrar el .SWF. Ademas debemos contar con nuestro propio estilo en cascada principal, con las reglas que formatearán los textos originales (en caso de no tener habilitado el Flash Player)

- tipografia.swf: Es el archivo Flash que contendrá la fuente que se utilizará. En el paquete de descarga vienen dos: tradegothic.swf y vandenkeere.swf. Es decir que uno de los archivos contendrá la fuente Trade Gothic y el otro VandenKeere.

Lo primero que se hace es añadir los CSS y el JS. Para eso entre y ponemos:

<link rel=”stylesheet” href=”sIFR-screen.css” type=”text/css” media=”screen” />
<link rel=”stylesheet” href=”sIFR-print.css” type=”text/css” media=”print” />
<script src=”sifr.js” type=”text/javascript”></script>

Luego supongamos que tenemos un encabezado con la etiqueta H1:

<h1><a href=”http://www.google.com” target=”_self”>Google</a>

Finalmente debemos incorporar un pequeño codigo JS con los parámetros de sIRF. Los más importantes son:

- sSelector: La etiqueta HTML a reemplazar;

- sFlashSrc: El archivo Flash;

- sColor: El color de las letras, en hexadecimal (#C0C0C0);

- sLinkColor: El color en caso de ser un link;

- sHoverColor: El color cambiante en caso de ser un link;

- sBgColor: El color de fondo.

Existen varios parámetros más, en el wiki de sIFR explican que es cada uno [sección Replacement Syntax]

Por lo tanto agregaremos un pequeño codigo JavaScript con los parámetros arriba puestos:

<script type=”text/javascript”>
if(typeof sIFR == “function”){
sIFR.replaceElement(named({sSelector:”h1″, sFlashSrc:”actionIs.swf”, sColor:”#99C137″, sLinkColor:”#99C137″, sBgColor:”#C0C0C0″, sHoverColor:”#508A15″}));
};
</script>

De esta forma estamos indicando que se debe reemplazar el texto entre las etiquetas H1 por el archivo actionIs.swf (que contiene la fuente Action Is ). Además el color de las letras debe tener tonos verdes con un fondo gris.

En caso de querer agregar más reemplazos tenemos:

<script type=”text/javascript”>
if(typeof sIFR == “function”){
sIFR.replaceElement(named({sSelector:”h1″, sFlashSrc:”actionIs.swf”, sColor:”#99C137″, sLinkColor:”#99C137″, sBgColor:”#c0c0c0″, sHoverColor:”#508A15″}));
sIFR.replaceElement(named({sSelector:”h2″, sFlashSrc:”vandenkeere.swf”, sColor:”#FFFFFF”, sLinkColor:”#FFFFFF”, sBgColor:”#CCCCCC”, sHoverColor:”#F5F8FF”}));
};
</script>

En este caso se agrego para que reemplace a la etiqueta H2. Y eso es todo, si tenemos algo así:

Implementando sIFR quedaría:

Algo más que agregar…

Existe un addon para sIFR que permite darle la posibilidad al usuario de ver o no los textos en Flash. Este addon viene en el paquete de descarga y se llama sifr-addons.js. De esta forma si agregamos este archivo entre <head> y </head>

<script src=”sifr-addons.js” type=”text/javascript”></script>

Y luego agregamos un link asi haremos que se desabilite sIFR:

<a href=” javascript:sIFR.rollback();”>Quitar sIFR</a>
También hay varios plugins para los distintos CMS: WordPress , Joomla , Drupal.

Se trata de llamar a un método de un objeto local con varios parámetros y una función de vuelta y recibir los resultados. No hay que preocuparse de cómo se envian o reciben los datos, el cliente y el servidor (Flash y PHP) están sincornizados para ello. Te permite preocuparte sobre las características de tu aplicación más que por como se implementa, a parte de ofrecer un navegador que permite realizar los servicios y probrarlos antes de que se empiece a desarrollar el cliente.

Permite conectar PHP con: Flash y Flex con Remoting, JavaScript y Ajax con JSON y clientes XML con XML-RPC. Y entre las características que nos ofrece, nos encontramos con que es compatible con PHP4 y PHP5, sin necesidades de extensiones, es rápido y ligero, ofrece herramientas para ayudarnos en el desarrollo y es posible incluirlo en el framework que usemos.

Ejemplos de desarrollo usando Amfphp que nos pueden ayudar:

• Editar una tabla
• Base de datos
• Obtener datos de Drupal
• AWI – Amfphp WordPress Integration
• Formularios
• Hello World
• Tienda online

Podés descargar el Amfphp acá

Con esto Adobe consigue dos beneficios inmediatos: por un lado la posibilidad de congregar en torno a Flex una comunidad de desarrolladores que le ayuden con la plataforma; por otro permitir que terceros integren Flex en sus herramientas de desarrollo y plataformas. Todo un golpe de mano frente a Microsoft y sus posibles anuncios en el MIX y frente a OpenLaszlo, la “plataforma libre para creación de Rich Internet Aplications” por excelencia hasta ahora.

La licencia MPL (Mozilla Public License) fue la elegida por el Adobe para el nuevo SDK Flex. Un SDK es un “Software Development Kit”, o Kit de desarrollo de software, “un conjunto de aplicaciones para desarrollar programas en un determinado lenguaje o para un determinado entorno”.

Muy bonito… muuy bonito.