idea folle per codec video

[Jak696]

ciao a tutti!
in uno dei miei soliti deliri informatici (:D) mi è venuta in mente un'idea, che di sicuro al primo post verrà smontata, ma che sono comunque curioso di proporvi.

prendiamo un fotogramma di un video a di 1920x1080:
-sono circa 2 milioni di pixel (quindi, suddividendoli in righe, in un ipotitetico file di testo 2073600 righe)
-ogni pixel può avere 1 colore su 16777216
quindi, il risultato per descrivere una cosa del genere sarebbe:
pixel 1: #00FFCC
pixel 2: #00B3C7
pixel 3: #002367
.........
pixel 2073600: #AA443C
/*il programma si occupa semplicemente di generare su schermo pixel per pixel col giusto colore

ora, al posto che un fotogramma, prendiamo un secondo di video (quindi 60 fotogrammi):
nei file di testo successivi (uno per ogni fotogramma) si potrebbero salvare righe solo per i pixel che cambiano -stile backup incrementali- ottimizzando il tutto.
probabilmente il disco rigido non sarebbe abbastanza veloce per leggere tutti quei file di testo così in fretta, ma anche qui si potrebbe per esempio caricare tutto in ram all'apertura del video o anche inglobare il tutto al posto che in lenti file di testo in un mini-db ultra ottimizzato o chissà che altro si potrebbe fare per rendere tutto più veloce...

il video risultante sarebbe di qualità pari all'originale e di dimensioni microscopiche e volendo potrebbe anche benissimo essere generato via javascript senza codec vari...

sicuramente è un'idea completamente stupida pensata da chi ha conoscenze nulle in materia, però volevo proprio togliermi lo sfizio di parlarne a qualcuno :p

[Mattyfog]

non so esperto eh... ho solo 14 anni..
comunque se non sbaglio c'è già qualche codec che si basa su qualcosa di simile...
fatto sta che non perdere qualità sarebbe impossibile: confrontando due immagini sarà molto difficile che 2 pixel corrispondenti siano dello stesso preciso identico colore (magari cambia di poco e quindi si potrebbe cercare il colore di mezzo ma così si perderebbe in qualità).
Forse funzionerebbe con alcuni cartoni animati che, non presentando (almeno alcuni) delle sfumature ma solo colori piatti potrebbero essere compressi.
;)

[VICIUS]

Cosa succede se faccio una panoramica? In tutti i frame tutti i pixel sarebbero sempre nuovi e dovresti salvare ogni volta un nuovo frame completo. Lo stesso discorso vale se la fonte è molto disturbata.

[Jak696]

Cosa succede se faccio una panoramica? In tutti i frame tutti i pixel sarebbero sempre nuovi e dovresti salvare ogni volta un nuovo frame completo. Lo stesso discorso vale se la fonte è molto disturbata.
quello si chiaro... ma comunque la dimensione del video sarebbe pesantemente più contenuta!

[Jak696]

2 milioni di righe in un file di testo sono almeno 2 MB, solo per un frame? per quale motivo su 2 milioni di pixel le differenze dei pixel tra frame successivi dovrebbero essere talmente minime da giustificare un file risultante di "dimensioni microscopiche"?:mbe:
addirittura 2mb? allora forse con la dimensione dei file di testo sono rimasto all'era windows 3.1 :doh:

EDIT:
beh ma in ogni caso il file di testo era un semplice esempio... sono sicuro che si possa fare molto di meglio!

[nuovoUtente86]

addirittura 2mb? allora forse con la dimensione dei file di testo sono rimasto all'era windows 3.1 :doh:

EDIT:
beh ma in ogni caso il file di testo era un semplice esempio... sono sicuro che si possa fare molto di meglio!

calcola 1byte per codificare 1 char e i conti sono presto fatti, non è questione di sistema operativo ma di codifica.

[Jak696]

calcola 1byte per codificare 1 char e i conti sono presto fatti, non è questione di sistema operativo ma di codifica.
pensandola così si conclude che è un'idea estremamente stupida! :doh:

e vabbeh, ci ho provato :D

[nuovoUtente86]

pensandola così si conclude che è un'idea estremamente stupida! :doh:

e vabbeh, ci ho provato :D

scusa come avresti voluto codificarli?

[Jak696]

scusa come avresti voluto codificarli?
boh sai era un'idea così campata per aria... non avevo ancora pensato al fatto che un carattere occupa un byte

[Silma]

boh sai era un'idea così campata per aria... non avevo ancora pensato al fatto che un carattere occupa un byte

Senza contare il fatto che tu auspichi 2 milioni di righe, non di singoli caratteri, ed ogni riga contiene al minimo 6 caratteri che sono il colore, quindi 12 MB per frame nel caso peggiore... il che, considerando 24 fps, è un fantastico 2880 MB al minuto (sempre nel caso peggiore, ma si programma per il caso peggiore).

Non esattamente dimensioni ridottissime :wtf:

[Jak696]

Senza contare il fatto che tu auspichi 2 milioni di righe, non di singoli caratteri, ed ogni riga contiene al minimo 6 caratteri che sono il colore, quindi 12 MB per frame nel caso peggiore... il che, considerando 24 fps, è un fantastico 2880 MB al minuto (sempre nel caso peggiore, ma si programma per il caso peggiore).

Non esattamente dimensioni ridottissime :wtf:
beh dai, un buon rapporto di compressione!
:asd: ma si, sono quelle idee che in testa sembrano tanto geniali e a conti fatti... non esattamente

[Silma]

:asd: ma si, sono quelle idee che in testa sembrano tanto geniali e a conti fatti... non esattamente

Una buona metafora della vita! :muro:

...:asd:

[Jak696]

Una buona metafora della vita! :muro:

...:asd:
anche, o... il prodotto di una giornata di "lavoro" senza nulla da fare :asd:

[Johnn]

L'idea delle differenze tra frame è buona, tanto che è già usata. L'implementazione, usare file di testo, tipo di codifica, ecc. è moooooolto rudimentale.

non so esperto eh... ho solo 14 anni..
comunque se non sbaglio c'è già qualche codec che si basa su qualcosa di simile...
fatto sta che non perdere qualità sarebbe impossibile: confrontando due immagini sarà molto difficile che 2 pixel corrispondenti siano dello stesso preciso identico colore (magari cambia di poco e quindi si potrebbe cercare il colore di mezzo ma così si perderebbe in qualità).
Forse funzionerebbe con alcuni cartoni animati che, non presentando (almeno alcuni) delle sfumature ma solo colori piatti potrebbero essere compressi.
;)

Perdere in qualità potrebbe essere una scelta, cioè risparmiare il più possibile perdendo un po' di informazione (compressione lossy) o risparmiare di meno ma non perdere niente (compressione lossless).
Inoltre la probabilità che due pixel nella stessa posizione abbiano la stessa intensità è abbastanza alta! E con una codifica efficiente mantenere solo piccole differenze porta a vantaggi potenzialmente notevoli.

a parte che esistono tecniche di compressione infinitamente più raffinate basate sulle differenze tra frame in domini trasformati, devo capire per quale motivo il file risultante sarebbe microscopico scusa?

2 milioni di righe in un file di testo sono almeno 2 MB, solo per un frame? per quale motivo su 2 milioni di pixel le differenze dei pixel tra frame successivi dovrebbero essere talmente minime da giustificare un file risultante di "dimensioni microscopiche"?:mbe:

Partendo dal fatto che le prestazioni di un algoritmo di compressione non si misurano con "microscopico" :D , mantenere differenze può essere vantaggioso.
Esempio: assumiamo che un pixel possa assumere valori da 0 a 255 (scala di grigio, 0 nero 255 bianco). Nell'istante 1 il pixel vale "145", nell'istante 2 vale "138". Per codificare questo pixel mi servono per forza 8 bit per ogni frame. Quindi senza compressione sono necessari 16 bit. Se si mantengono solo differenze bastano 11 bit, usando una codifica ottimale. 8 bit per il primo pixel e 3 bit per coficare "7", cioè "145"-"138". In più mantere le differenze porta probabilmente ad avere molti valori uguali, una situazione ideale per certi algoritmi di compressione.

Cosa succede se faccio una panoramica? In tutti i frame tutti i pixel sarebbero sempre nuovi e dovresti salvare ogni volta un nuovo frame completo. Lo stesso discorso vale se la fonte è molto disturbata.
Difficilmente in un video normale i pixel sarebbero sempre tutti nuovi. Per la maggior parte delle volte e per la maggior parte di essi sono sempre gli stessi, con piccole differenze al massimo.

calcola 1byte per codificare 1 char e i conti sono presto fatti, non è questione di sistema operativo ma di codifica.

Ma infatti non si usa una codifica del genere per comprimere. :D

[rеpne scasb]

■

[nuovoUtente86]

In qubit.

Seppure con un solo qubit si potrebbe rappresentare tutta l' informazione voluta, nel discreto la quantità rappresentabile (stato 1 o 0) è identica al bit.

[fero86]

ciao a tutti!
in uno dei miei soliti deliri informatici (:D) mi è venuta in mente un'idea, che di sicuro al primo post verrà smontata, ma che sono comunque curioso di proporvi.

prendiamo un fotogramma di un video a di 1920x1080:
-sono circa 2 milioni di pixel (quindi, suddividendoli in righe, in un ipotitetico file di testo 2073600 righe)
-ogni pixel può avere 1 colore su 16777216
quindi, il risultato per descrivere una cosa del genere sarebbe:
pixel 1: #00FFCC
pixel 2: #00B3C7
pixel 3: #002367
.........
pixel 2073600: #AA443C
/*il programma si occupa semplicemente di generare su schermo pixel per pixel col giusto colore

ora, al posto che un fotogramma, prendiamo un secondo di video (quindi 60 fotogrammi):
nei file di testo successivi (uno per ogni fotogramma) si potrebbero salvare righe solo per i pixel che cambiano -stile backup incrementali- ottimizzando il tutto.
probabilmente il disco rigido non sarebbe abbastanza veloce per leggere tutti quei file di testo così in fretta, ma anche qui si potrebbe per esempio caricare tutto in ram all'apertura del video o anche inglobare il tutto al posto che in lenti file di testo in un mini-db ultra ottimizzato o chissà che altro si potrebbe fare per rendere tutto più veloce...

il video risultante sarebbe di qualità pari all'originale e di dimensioni microscopiche e volendo potrebbe anche benissimo essere generato via javascript senza codec vari...

sicuramente è un'idea completamente stupida pensata da chi ha conoscenze nulle in materia, però volevo proprio togliermi lo sfizio di parlarne a qualcuno :p
l'hanno giá inventato, peró senza passare per i file di testo visto che é uno spreco di spazio enorme e inutile. da quel pochissimo che ne so MPEG funziona in modo analogo: solo alcuni frames sono completi (quelli necessari a permettere di spostarsi in un punto arbitrario del video), i successivi sono costituiti da informazioni incrementali.

[Tommy81]

In qubit.

:sofico:

[yorkeiser]

Non è un'idea folle: qualsiasi algoritmo di compressione, che sia video, audio o semplici file (zip, rar et similia) sfrutta la ridondanza dei dati da comprimere.

[Ikon O'Cluster]

ELIMINATO

[Ikon O'Cluster]

ELIMINATO

[Ikon O'Cluster]

l'hanno giá inventato, peró senza passare per i file di testo visto che é uno spreco di spazio enorme e inutile. da quel pochissimo che ne so MPEG funziona in modo analogo: solo alcuni frames sono completi (quelli necessari a permettere di spostarsi in un punto arbitrario del video), i successivi sono costituiti da informazioni incrementali.

Copio e incollo alcuni miei appunti del corso di PPM del prof. Rizzo (Ing. Informatica - UniPI). Forse non si capiscono tutti i concetti, ma fondamentalmente il principio si capisce...

Una sequenza video è una serie di immagini dette “frames” o “fotogrammi” spaziate nel tempo ad una distanza regolare che dipende dalle caratteristiche dell’utilizzatore. In particolare l’occhio umano non riesce a percepire variazioni inferiori a 10 ms pertanto un soddisfacente “frame rate”, ovvero il numero di fotogrammi visualizzati in un secondo, è 20-50 fps (frames al secondo). Pertanto un frame rate più basso di 20 fps fa sì che la sequenza venga vista a scatti, mentre un frame rate superiore a 50 fps fa sì che molti fotogrammi siano superflui poiché non apprezzabili. In base a quanto detto la distanza in termini di tempo tra fotogrammi consecutivi dovrà essere di 20-50 ms. Tuttavia in alcuni casi non ha senso mantenere questa distanza temporale tra i fotogrammi: ad esempio se stiamo visualizzando una scena fissa è più vantaggioso visualizzare solo il primo fotogramma dato che i successivi saranno invariati. In una scena reale però i soggetti sono in continuo movimento. Possiamo pensare allora di comprimere ogni fotogramma con le classiche tecniche di compressione per le immagini, ma in questo caso la compressione non sarà molto efficace. Infatti è più efficiente considerare che generalmente in due fotogrammi consecutivi parte della scena rimane invariata e quindi comprimere una sola volta la parte comune facendo poi riferimento ad essa in tutti i fotogrammi che la condividono. La tecnica di base nella compressione video è quella di trasmettere un fotogramma come differenza rispetto ai fotogrammi precedenti. Ciò permette di sfruttare le situazioni in cui, malgrado traslazioni, rotazioni o cambiamenti di scala dei soggetti nella scena, questi rimangono comunque presenti in fotogrammi consecutivi, determinando tra questi delle somiglianze. Le somiglianze tuttavia non possono essere rilevate attraverso una ricerca lineare dei bit all’interno dei fotogrammi, ma attraverso una ricerca di tipo bidimensionale andando a confrontare tra loro aree (blocchi) bidimensionali dell’immagine. In tal caso quando una certa area di un fotogramma B coincide con un’area del fotogramma A, allora è possibile codificare tale area facendo riferimento al fotogramma A ed alle coordinate dell’area corrispondente. [...] La tecnica fin qui vista è valida quando un soggetto occupa la scena ed eventualmente tende ad uscirne. Supponiamo invece di avere un soggetto che entra nella scena. In tal caso i blocchi che costituiscono il nuovo soggetto non verranno trovati nei fotogrammi precedenti, ma nei fotogrammi successivi. Per poter inserire dei riferimenti a fotogrammi successivi è necessario che l’esecuzione venga ritardata, mantenendo l’ordine di visualizzazione dei fotogrammi, ma alterandone l’ordine di invio al decodificatore. In questo modo i riferimenti incontrati dal decodificatore riferiranno sempre fotogrammi già ricevuti da questo. Nell’effettuare questa operazione è necessario però porre dei limiti al ritardo d’esecuzione per evitare che la visualizzazione risulti insoddisfacente. Il principale svantaggio prodotto in questo modo è quello di porre dei vincoli in fase di decompressione in quanto è necessario rispettare un ordinamento dei fotogrammi che è diverso da quello di visualizzazione. Questo svantaggio si traduce in problemi nella riproduzione degli stream video, dove l’utente è generalmente abituato a riavvolgere, avanzare o riprodurre da un punto casuale lo stream. Quindi per poter fornire questa possibilità all’utente è necessario prevedere dei punti all’interno dello stream dai quali la riproduzione può essere avviata senza dover riferire altri fotogrammi. Avremo quindi varie tipologie di fotogrammi:

@ I-Frame. Gli I-Frame (Indipendent Frame) sono particolari fotogrammi emessi ad intervalli regolari che vengono compressi senza fare riferimento ad altri fotogrammi. Dato che un I-Frame contiene sempre la codifica di una intera immagine è opportuno ridurre il più possibile la loro frequenza in base ai limiti imposti dal tipo di applicazione considerata.
@ P-Frame. I P-Frame (Previous Frame) sono fotogrammi che fanno riferimento a fotogrammi precedenti.
@ B-Frame. I B-Frame (Bidirectional Frame) sono fotogrammi che fanno riferimento a fotogrammi precedenti e successivi. Data la loro maggiore probabilità di riferimento ad altri fotogrammi, i B-Frame possiedono una maggiore capacità di compressione rispetto ai P-Frame, ma tuttavia determinano al loro aumentare un ritardo crescente in decodifica in quanto il decodificatore deve attendere che tutti i frame riferiti siano disponibili.

[Ikon O'Cluster]

Scusate per i messaggi replicati, avevo confermato più volte l'invio a causa di forti rallentamenti nella comunicazione col server...

[cdimauro]

Più che altro tu, come altri utenti, avete la pretesa di scrivere messaggi quando il server del database del forum è in manutenzione (a quell'ora). :p

[Ikon O'Cluster]

Eh allora è meglio metterlo DOWN se succedono questi disastri... sennò una manutenzione più "SAFE" non si può fare? Al limite inibire la scrittura e permettere solo la lettura, notificando che momentaneaente ogni modifica al forum è bloccata a causa di manutenzione :D

[cdimauro]

A chi lo dici. Non sai quante volte è capitato a me. :asd: