Visualizzatore filmati in Basic, Con tanto di nuovo formato!

Tutto assolutamente chiarissimo, eheh!


( )

Grazie Gigio, ora estrapolerò la modifica e la adatterò all'ultima versione del programma che ho postato, poi ti saprò dire. Riguardo al gosub si tratta di un comando temporaneo per semplificare il tutto, poi lo sostituirò con le sub e le function, ci tenevo solo a sapere se la struttura sostanzale funzionava a dovere.
Restate sintonizzati, tornerò quanto prima sia con l'audio stereo che con la grafica ad alta risoluzione!

Ciao!!!

Riekkime, volevo fare una domanda: c'è per caso un modo per accedere alle informazioni sui file stoccate nella FAT? Per la precisione FAT16 dato che lavoro in dos puro. C'è insomma un modo per far si che da Basic sia possibile leggere le informazioni sui file e soprattutto il numero di files contenuti in una determinata directory? Questo velocizzerebbe il conteggio da parte del programma del numero di file-fotogramma contenuti nella relativa directory, prima della creazione del filmato. Questo numero serve a due sezioni del programma, ovvero alla sezione di sequenzializzazione dei fotogrammi e alla barra progressiva.
Grazie infinite a chi mi saprà rispondere

Siiiiiiii!!!!!!!! ^_________^
Gigio sei un genio!
Grazie!!! ^___________^

Sei ancora in ballo con l'algoritmo di Huffman?

Ahah, beh intanto goditi il bel tempo e "assorbilo" per bene, così lo terrai in caldo per l'inverno

Intanto voglio farti partecipe degli ultimi sviluppi sul formato audio/video che sto perfezionando. Ho notato, studiando le specifiche e le funzioni VESA, che le modalità a 24 bit per pixel in realtà gestiscono 32 bit per pixel, un byte quindi viene deliberatamente ignorato dalla scheda video. La ragione è che è più facile usare variabili con dimensione in byte che sia divisibile per 4, così rende meno complicata sia la codifica che la decodifica delle immagini e, per esteso, dei filmati. Allora ho pensato di utilizzare quel byte, anzichè per le informazioni sul colore, per contenere invece l'audio stesso. Perchè no? In fondo non è una cattiva idea, basta solo istruire a dovere il programma a codificare e decodificare correttamente il filmato, in modo che sappia dove prendere il video e l'audio.
Qui di seguito mostro uno schema strutturale di un video AVM nel caso della codifica a 32 bit per pixel:



Come si può vedere, ogni pixel è appunto formato da 3 byte, uno per colore primario, mentre nel quarto byte viene codificato l'audio col sistema PCM. E' un formato perfettamente compatibile quindi con la maggior parte delle piattaforme operative, ma la cosa più importante è che l'audio e il video sono inscindibilmente connessi e non accadrà mai che vi siano sfasamenti temporali tra il sonoro e le immagini. Io lo chiamo sistema "dei pixel cantanti", perchè ogni pixel è sia immagine che sonoro
E' un formato che può essere facilmente trasmesso in streaming e, anche se non ho ancora effettuato prove di trasmissione via web, secondo me può garantire velocità di trasmissione elevate proprio grazie all'uniformità del file stesso.
Ho anche definito finalmente la struttura ufficiale dell'header del file, che è la seguente:

HEX
0x00: Stringa di 3 caratteri. Mostra la dicitura "AVM"

0x03: Quad word (8 bytes). Dimensione del file completo (compreso l'header)

0x0b: Byte. Posizione dei dati audio/video dall'inizio del file (offset)

0x0c: Word (2 bytes). Larghezza del video in pixel.

0x0e: Word. Altezza del video in pixel.

0x10: Byte. Numero di bit utilizzati per pixel. Mostra 4 per immagini a 16 colori, 8 per immagini a 256 colori, 16 per immagini a 65536 colori, 24 per immagini a 16777216 colori (true-color), 32 per la codifica dei pixel con audio integrato (vedi sopra)

0x11: Byte. Numero di fotogrammi visualizzati al secondo.

0x12: Double word (4 bytes).Numero di bytes audio+video trasferiti al secondo

0x16: Byte. Numero di canali audio. Mostra 1 per mono, 2 per stereo, 3 per stereo+canale centrale, 4 per Dolby Surround, 5 per Dolby 5+1

0x17: Word (2 bytes). Numero di campioni audio al secondo (sample rate)

0x19: Byte. Numero di bit per campione audio. 8 o 16. E' la definizione audio, ovvero il numero di possibili livelli che può assumere il suono. Maggiore è il numero di bit utilizzati, maggiore è la qualità del suono.

0x1a: Word (2 bytes). Numero di campioni per fotogramma. E' il numero di campionamenti audio presenti all'interno del segmento di flusso comprendente un singolo fotogramma.

0x1c: Word (2 bytes). Numero di pixel per campione audio. Nelle codifiche a 4,8,16 e 24 bit per pixel questo valore definisce quanti pixel separano i campioni audio, ovvero dopo quanti pixel il programma trova, nel flusso, il campione audio da inviare alla scheda sonora. Nella codifica a 32 bit questo valore è sempre 0 e significa che ogni pixel è formato da 4 bytes (32 bit, appunto) di cui il 4° contiene il campione o la parte di campione audio (a seconda dei canali e del bit-dept utilizzato).

0x1e: Stringa di 4 caratteri. Mostra la dicitura "DATA" che indica la posizione di inizio dati audio/video (offset). Il byte immediatamente successivo (HEX 0x22) quindi è il primo byte del flusso audio/video.

Questo è per adesso la prima traccia sulla struttura dell'header del file, ma ovviamente prima di renderla definitiva dovrò valutare attentamente molte cose. Non escludo però che possa rimanere tale quale com'è, divenendo quindi l'header ufficiale del formato video AVM!

Che ne dite?

Edited by yareol - 23/9/2010, 18:14

Incredibile! Sono riuscito a visualizzare il filmato in modalità 800x600 con colore rgb e una velocità di riproduzione appropriata, tanto che si può vederlo anche a 28 fps! Siiiiiiii!!!!
Ho solo qualche problema di stabilizzazione dell'immagine, che per chissà quale strano motivo tende a traslare a destra durante la riproduzione... comunque vedrò più avanti di tenerla centrata.
Il mio più grande e impellente problema invece adesso è che non riesco a ottenere lo scambio dei banchi di memoria (bank-switching) e scrivere sul banco successivo. Ho provato col metodo proposto dal tutorial che ho tradotto, ovvero con l'interrupt 10h e la funzione VESA 4F05h, che poi mi sembra sia anche l'unico, ma il sistema si rifiuta di effettuarlo, o forse sono io che sbaglio qualcosa, non so, sto diventando matto per capire perchè caspita non lo fa!

Beorn tu per caso avresti qualche idea?

Ahahahah!! Forte questa! xD

Gigio, avrei da farti una proposta, sempre se hai tempo e sei d'accordo. Mi sono reso conto, da alcuni calcoli fatti in passato, che il formato AVM se viene salvato sul supporto di memorizzazione così com'è, occupa uno spazio decisamente spropositato, qualcosa come 300 GB per due sole ore di filmato (!!!), per fartene un'idea posso dirti che nemmeno il più capace blu-ray potrebbe mai contenerlo tutto!
Pertanto avrei bisogno di applicare un algoritmo di compressione abbastanza efficiente per poter almeno dimezzare lo spazio necessario e, considerato che per un film in DVD di due ore servono solo circa 5 GB, direi che mi serve un algoritmo davvero straordinario per riuscire a raggiungere dimensioni almeno accettabili.
So che tempo fa studiavi l'algoritmo di Huffman, non è che riusciresti a progettarne uno per il formato AVM? Io lo farei volentieri ma ho scoperto che sono decisamente più bravo a progettare algoritmi di criptazione che di compressione...
Ti preeeegoooo!

Che ne pensi?