Programación para +3E: player de video

[mcleod_ideafix]

Para este video se ha usado un Spectrum +2A reconvertido a +2E, y con una interface ZXMMC para tarjetas SD/MMC.
La tarjeta SD desde la que se ha reproducido el video contiene una partición de tipo 0F (Movie type) con frames a todo color.

El resultado, aquí:
http://www.youtube.com/watch?v=79VO9MdZI9Q

[winston]

¡Qué mola!

También creo que Gasman ha hecho algo similar para el DivIDE (por cierto, su programa lee el video block por block en vez de usar el sistema de ficheros - creo que el SF sería demasiado lento para mostrarlo). (además si el foro de WOS funcionara, podría dar una enlace... pero nos da el mensaje "Quick maintenance session. Be back in a bit!")

Y ahora, necesito hacer algo así con el Spectranet, el video que tengo no es en color. (Creo que hay suficiente tiempo de CPU para los 768 bytes de attributes...)

[mcleod_ideafix]

Yo también lo hago así. Uso una partición completa y ahí pongo la película. Leugo leo a bajo nivel. La primera versión usaba el sistema de ficheros, y la película en cuestión era un fichero más dentro de la partición de datos, pero hay dos problemas con esta opción:
- +3DOS admite como máximo ficheros de 8MB. Puedes tener ficheros más grandes que eso, pero el Spectrum no será capaz de leer correctamente más allá de 8MB.
- El algoritmo de lectura secuencial de ficheros no está optimizado. Cuanto más avanzas en la lectura del fichero, más tarda en localizar el próximo bloque a leer. Los primeros segundos es capaz de leer a full-frame rate, pero a partir de ahí, se ralentiza, cada vez más, cada vez más. Tengo que comentárselo a Garry en cuanto tenga ocasión.

Con el método que uso, y que es el que aparece en el video, leo siempre a toda velocidad, y no estoy sujeto a la limitación de 8MB. De hecho, no habría limitación excepto porque el contador de frames reproducidos es de 16 bits, lo que significa que con esta versión del software sólo puedo reproducir 65535 frames como máximo. A 25 frames por segundo, esto me da un tiempo máximo de 43 minutos.

Lo bueno de hacerlo con el +3E es que toda la infraestructura para poder leer sectores a bajo nivel ya está implementada, y es independiente del medio físico. Si no fuera porque suena a broma, diría que la plataforma +3E es la que tiene más futuro en Spectrum (con permiso de ResiDOS).

Por cierto, ¿conocías Mazinger Z?

[winston]

Supongo que el video es una secuencia de SCREEN$, ¿verdad? (Eso es el método que uso para el video de Spectranet)

[zxbruno]

Impresionante. El resultado es mucho mejor que lo que se obtenía con bmp2scr. Me recuerda los nuevos resultados que Omega ha obtenido y también la nueva utilidad que ha sido enviada a WOS hace algunas semanas atrás. ¿Tiene nombre el algoritmo?

¿Acaso han acompañado el nuevo proyecto de Gasman? He estado intercambiando e-mails con él y hemos hablado sobre lo siguiente:

-Acceso 'random' a archivos sin estar limitado a los layers de los firmwares que se encuentran en uso, o una forma de usar el low-level pero más facil para el usuario.
-Lectura de audio de la misma manera que se ha hecho con el video. De ahí salió la idea del WavIDE, pero aún está en desarrollo. Para los que aún no lo han visto en funcionamento, se trata de un player de archivos WAV que no está limitado a la memoria del Spectrum, sino a la capacidad del medio que se encuentre conectado al interface IDE
-Mezcla de video y audio al mismo tiempo. Ya hace 2 años que he estado hablando con natxcross y Gasman sobre esto. Desde los dias de los anuncios del Videoface la idea de video y audio digitalizado me ha fascinado. Les he pedido que me ayudaran a buscar una manera de hacer posible la reproducción de video y audio "simultaneamente". Hasta ahora la idea más impresionante fue la de Natxcross, pues le añadió 2 barras de atributo negro al clip de video y escondió el audio detrás de ellas. De esta manera solo tenía que leer un bloque a la vez para poder mostrar el frame y hacer playback del audio digitalizado a través del AY.

Ruego que sigan los experimentos. Este tipo de cosas son buenas para poner en YouTube, mostrar a los amigos, hacer demos en parties, etc. etc!

Si yo tuviera los conocimientos de electronica necesarios, ¡inventaría un videoface moderno aprovechando los nuevos algoritmos de conversión y le añadiría entrada de audio para convertir audio en samples de AY en tiempo real!

[winston]

Video y sonido será dificil. Un ordenador moderno tiene un buffer y DSP para sonido digital, y por eso, es posible almacenar el sonido en este buffer y entonces hacer otras cosas mientras el sonido está reproduciendo gracias del DSP. (De hecho, sería muy dificil hacer un reproductor tal como WinAMP si no fuera así)

Pero el Spectrum no tiene un DSP. Hay que enviar la onda forma* continuamente, en "realtime" - mientras el video está reproduciendo. Creo que es posible, pero la calidad del sonido no sería bueno

(quiero decir "waveform")

[mcleod_ideafix]

Supongo que el video es una secuencia de SCREEN$, ¿verdad? (Eso es el método que uso para el video de Spectranet)

Sí. Me he inventado un formato que he llamado ZXMOVIE. Es de lo más sencillo. El primer sector contiene la palabra ZXMOVIE en el offset 0. En el offset 16 hay una palabra de 16 bits que indica cuántos frames contiene el video, y en el offset 18, otra palabra que indica la longitud en bytes de cada frame. El resto del sector está a 0, así que se puede ampliar con más opciones. La película comienza en el siguiente sector.

Cada frame está grabado de tal forma que ocupe un número entero de sectores. Cuando es en blanco y negro (6144 bytes) no hay problema, ya que son 12 sectores. Para color la cosa se complica un pelín, ya que 6912 bytes ocupa 13.5 sectores, así que para color uso en realidad 7168 bytes (256 más de los necesarios) y por tanto son 14 sectores.

En color, el frame contiene 256 bytes al principio, seguidos de los 6912 bytes de la pantalla en sí. La razón de poner estos 256 bytes de relleno al principio y no al final es porque de esta forma, puedo cargar o bien a partir de la dirección (16384-256) para la primera pantalla, o bien a partir de (49152-256) para la segunda pantalla. Lo que pretendo es que las cargas no rebasen la zona de atributos. Si hubiera puesto el relleno al final, en la pantalla shadow no hay problemas, pero en la pantalla principal, los 256 bytes que sobran se irían a lo que antiguamente era el buffer de impresora, pero que en el +3E guarda información importante.

[mcleod_ideafix]

Impresionante. El resultado es mucho mejor que lo que se obtenía con bmp2scr. Me recuerda los nuevos resultados que Omega ha obtenido y también la nueva utilidad que ha sido enviada a WOS hace algunas semanas atrás. ¿Tiene nombre el algoritmo?

Sí. Es el "solid color" del BMP2SCR . Si sale tan bien es precisamente porque el video original son dibujos animados, y éstos tienen colores planos, por lo que la conversión al limitado espacio de color del Spectrum da un resultado que no difiere tanto del original que si fuera video fotográfico.
De todas formas tengo que probar la rutina de color en alta resolución que escribí hace unos meses con esta historia, a ver si sería posible video con más riqueza de color y sin perder (demasiados) frames por segundo.

-Acceso 'random' a archivos sin estar limitado a los layers de los firmwares que se encuentran en uso, o una forma de usar el low-level pero más facil para el usuario.

El framework del +3E yo lo veo lo suficientemente sencillo como para poder hacer esto, lo de leer a bajo nivel puenteando el sistema de ficheros, el cual tiene un problema de rendimiento bastante importante cuando los archivos empiezan a ser grandes (varios cientos de KB).

-Lectura de audio de la misma manera que se ha hecho con el video. De ahí salió la idea del WavIDE, pero aún está en desarrollo. Para los que aún no lo han visto en funcionamento, se trata de un player de archivos WAV que no está limitado a la memoria del Spectrum, sino a la capacidad del medio que se encuentre conectado al interface IDE

Pero dado que en un Spectrum "bare bones" no hay DMA, el archivo WAV no se podría reproducir con fluidez... salvo que leyeras directamente del medio físico con IN y OUT en lugar de usando un framework

-Mezcla de video y audio al mismo tiempo. Ya hace 2 años que he estado hablando con natxcross y Gasman sobre esto. Desde los dias de los anuncios del Videoface la idea de video y audio digitalizado me ha fascinado. Les he pedido que me ayudaran a buscar una manera de hacer posible la reproducción de video y audio "simultaneamente". Hasta ahora la idea más impresionante fue la de Natxcross, pues le añadió 2 barras de atributo negro al clip de video y escondió el audio detrás de ellas. De esta manera solo tenía que leer un bloque a la vez para poder mostrar el frame y hacer playback del audio digitalizado a través del AY.

¿Y le funcionó? ¿Hay algún enlace o video para verlo?
Yo la idea que tengo es añadir un sector más, con 512 bytes de audio (en 8 bits, claro). A 11025 Hz tengo justo la cantidad de audio necesaria para cubrir un frame de video (unos 40 ms) aunque quizás sería necesario tener un poco más audio del que se va a reproducir. Pero claro, en mi caso usaré algo de hardware extra...

[winston]

Sí. Me he inventado un formato que he llamado ZXMOVIE.

¿Tienes una herramienta que convierte formatos tales como MP4 etc. a este formato?

(He tratado de usar la herramienta que LCD ha hecho, pero aún no he conseguido éxito)

[mcleod_ideafix]

No, esto fue lo que hice:
- Con VirtualDub, preparar el video, es decir, pasarlo a una resolución de 256x192, no comprimido, y sin sonido.

- Con BMP2SCR pasar el video preparado a una secuencia de archivos SCR. Para blanco y negro uso la opción "error difussion" que funciona muy bien tanto para video de imagen real como dibujos animados, y para color, pues la que mejor vea que le quede. En el caso del video de ejemplo usé "solid color". Para blanco y negro uso tamaño 6144 bytes.

- Para el caso de color: a cada archivo le antepongo un trozo de 256 bytes a cero. Este trozo no es más que un archivo con 256 bytes, todos a 0, que se llama padding.dat . Lo hago en Windows, pero usando la BASH, así:

Código: Seleccionar todo

for i in *.scr
do
  cat padding.dat $i > $i.zxf
done

Y luego uno todos los archivos ZXF, así:

Código: Seleccionar todo

copy/b *.zxf moviecolor.zxm

- Para el caso de blanco y negro: directamente hago la unión de los archivos que ha generado BMP2SCR, así:

Código: Seleccionar todo

copy/b *.scr moviebw.zxm

- Ahora hay que meter esto en una partición dentro de la tarjeta de memoria que uso en el +3E. Para ello, primero desde el propio +3E, creo una partición (por ejemplo una de swap) con el tamaño necesario para albergar la película completa. Por ejemplo, para el video de color hice una de 10 MB, así:

Código: Seleccionar todo

NEW EXP "moviecolor",10

Después se pone la tarjeta de memoria en el PC y usando la utilidad '3e' lista la tabla de particiones para obtener el sector donde comienza la partición que hemos creado.

Código: Seleccionar todo

PARTITION TABLE

Num. Name             Type    CH Begin  CH End   LBA Begin LBA End   Size
---------------------------------------------------------------------------
   0 PLUSIDEDOS       System     0/0       0/0   0         127       0   MB
   1 moviebw          Other    128/1     192/0   32896     49279     8   MB
   2 intercambio      +3DOS C    0/1     128/0   128       32895     16  MB
   3 moviecolor       Other    192/1     272/0   49280     69759     10  MB
   4 ---------------- FREE     272/1     954/1   69760     244479    85  MB

124 partition entries remain unassigned.

- Se abre un edtor de sectores (yo uso el HxD). Primero, en la tabla de particiones, se toca el tipo de partición y se pasa de 02 (swap) a 0F (movie). Luego vamos directamente al primer sector de la partición (para el caso de la peli en color está en 49280).

- El primer sector de la partición se pone a 0 (luego pondremos ahí la información de cabecera). Copiamos el archivo ZXM a partir del segundo sector.

- De vuelta al primer sector: en el offset 0 de ese sector escribimos ZXMOVIE. En el offset 16 ponemos (en notación Intel como siempre) un número de 16 bits que indica cuántos frames hay en la película, y en el offset 18, el tamaño en bytes de cada frame, que será 1C00h (7168 bytes) para color, y 1800h (6144 bytes) para blanco y negro. El número de frames de la película lo saco con VirtualDub (o mirando el número del último fichero SCR que generó BMP2SCR).

Y ya está Seguramente todo esto sea objeto de una actualización en '3e' para que lo haga automáticamente (al menos la parte en la que escribe el contenido del ZXM en la tarjeta de memoria).

[zxbruno]

-Mezcla de video y audio al mismo tiempo. Ya hace 2 años que he estado hablando con natxcross y Gasman sobre esto. Desde los dias de los anuncios del Videoface la idea de video y audio digitalizado me ha fascinado. Les he pedido que me ayudaran a buscar una manera de hacer posible la reproducción de video y audio "simultaneamente". Hasta ahora la idea más impresionante fue la de Natxcross, pues le añadió 2 barras de atributo negro al clip de video y escondió el audio detrás de ellas. De esta manera solo tenía que leer un bloque a la vez para poder mostrar el frame y hacer playback del audio digitalizado a través del AY.

¿Y le funcionó? ¿Hay algún enlace o video para verlo?

Sí. Mira esto: http://www.youtube.com/watch?v=I4FdzeYgEdY

Pero en un Spectrum real es más lento que lo que se ve en YouTube.

Aquí se explica como se hizo todo:

http://www.ys3.org/?p=106

Creo que se podría hacer varias cosas para acelerar todo, pero algo se tendría que sacrificar.

[mcleod_ideafix]

Sí. Mira esto: http://www.youtube.com/watch?v=I4FdzeYgEdY
Pero en un Spectrum real es más lento que lo que se ve en YouTube.

Tsk tsk, no me vale. En emulador el acceso a la CF está virtualizado y es muchísimo más rápido que en hardware real. A ver si termino la tesis y lo hago como tengo pensado...

[zxbruno]

¿Hay alguna manera de emular el acceso IDE correctamente, añadiendo el retraso necesario? ¿O es algo que depende de varios factores?

[mcleod_ideafix]

¿Hay alguna manera de emular el acceso IDE correctamente, añadiendo el retraso necesario? ¿O es algo que depende de varios factores?

Depende fundamentalmente del chisme IDE que enchufes al DivIDE. En el protocolo de lectura lo verás mejor:

Código: Seleccionar todo

;Execution includes the transfer of one or more 512 byte (>512 bytes on Read
;Long) sectors of data from the drive to the host.
;   a) The host writes any required parameters to the Features, Sector Count,
;      Sector Number, Cylinder and Drive/Head registers.
;   b) The host writes the command code to the Command Register.
;   c) The drive sets BSY and prepares for data transfer.
;   d) When a sector of data is available, the drive sets DRQ and clears BSY
;      prior to asserting INTRQ.
;   e) After detecting INTRQ, the host reads the Status Register, then reads
;      one sector of data via the Data Register.  In response to the Status
;      Register being read, the drive negates INTRQ.
;   f) The drive clears DRQ.  If transfer of another sector is required, the
;      drive also sets BSY and the above sequence is repeated from d).

Para pasar del paso D al E hay que esperar a que el DivIDE baje BSY y suba DRQ. Este paso hay que hacerlo para cada sector que se lee, así que al tiempo de lectura de varios sectores (12 para un frame monocolor del Spectrum) hay que sumarle el tiempo de espera del paso D, multiplicado por 12. El tiempo que pasa desde que se envía el comando hasta que DRQ sube y BSY baja depende exclusivamente del medio (disco, tarjeta CF, etc.) que esté pinchado en el DivIDE. En los DivIDE emulados, los datos están inmediatamente disponibles (desde el punto de vista del Z80 emulado) desde que se envía el comando en el paso B. En un disco real, el pequeño microcontrolador que hay dentro del disco/tarjeta necesita tiempo para hacer la traducción interna CHS -> LBA -> dirección interna/CHS real. Se usa CHS real al final de la traducción si el dispositivo es un disco duro magnético, y dirección interna si es una tarjeta de memoria.

Es decir, indendientemente de que estemos trabajando con el dispositivo IDE en modo CHS o modo LBA, ninguno de estos dos sistemas de coordenadas se corresponden realmente con cómo está organizada la información realmente en el dispositivo. A menudo, los parámetros CHS que el dispositivo "exporta" al programador son los adecuados para ser amigables con antiguas BIOS (no más de 1024 cilindros, etc.). Así te puedes encontrar con discos que aparentemente tienen 10 o más cabezales, y cuando los abres, ¡tienen sólo 2!

LBA a menudo es más rápido que CHS, y practicamente cualquier cosa IDE que le enchufes al DivIDE lo soportará. CHS de hecho es un vestigio de la época de los discos duros MFM y ESDI, que fueron los primeros en ser incorporados a los IBM PC, y por tanto, las BIOS, y el software de arranque que se diseñaron en la época necesitan que el CHS se siga soportando, en el caso de los IDE, a nivel de dispositivo. La cosa es que con un disco duro magnético, LBA no es la forma natural de guardar información en el disco, sino que se usa CHS, pero no el CHS exportado, sino el "interno" del dispositivo. Para el caso de una CF, lo que hay es una matriz de memoria, que estará direccionada por bytes, o palabras de 32 bits, o vaya usted a saber, con lo que se necesita también una traducción.

En los emuladores que soporten dispositivos IDE bastaría con un parámetro configurable que fuese el retardo desde que se envía el comando hasta que el dispositivo sube DRQ y baja BSY. Ese retardo podría aparecer en la ventana de configuración en forma de microsegundos, o bien que se midieran retrasos reales en algunos dispositivos tipo (una tarjeta CF SanDisk, otra de Maxwell, un disco duro Seagate, otro Maxtor, etc. y poner en la ventana de configuración si quieres un retraso equivalente al de la tarjeta CF marca tal, o cual...)

[Z80user]

y no se podria ir pidiendo el segundo bloque al terminar el anterior e ir haciendo algo mientras se espera que se lean los datos (aun no tengo divide)
1-pedir bloque al disco
2-tocar melodia por el AY
3-leer datos del disco, colocarlos y reproducir alguna nota cada x bytes leidos