Newsgroup: it.comp.software.divx
Titolo: ma perchè tutti sti codec ?

eh già
quello che mi chiedo è perchè non va piu bene il divx5. Che problema dà?
Occuperà piu spazio, e posso pure capirlo, ma alla fine cosa cambia?
Un dvd vuoto ormai costa una stupidaggine, risparmiare un po' di mega non mi 
pare sia così conveniente...
A questo punto quindi se tutti i nostri filmati li codifichiamo in dvx5 e se 
scarichiamo solo dvx5 non c'è neanche bisogno di ammazzarsi per cercare 
lettori dvd particolari o aggiornamenti firmware.
Perchè allora ci si intestardisce? C'è qualche altra motivazione piu 
interessante per preferire versioni superiori di divx o xvid? 

Luigi L ha scritto:

Anche se non sarebbe corretto farlo, ti rispondo con un'altra domanda: 
perchè ad esempio la Fiat non ha continuato a costruire le vecchie 500 
negli anni 60 invece di studiare ogni volta modelli nuovi più veloci, 
più comodi, più economici, ecc.? In fondo anche con la vecchia 500 si 
viaggiava, si andava al lavoro, e ci stava bene anche in un piccolo 
garage... :)
Ciao.
-- 
Michele - Too far from America
MSN ID: myksto dot hotmail dot com
"It's the world we live and life in general..."


Bè ma a me non sembre che un Xvid e un Divx5 abbiano tra loro differenze 
abissali come quelle tra una 500 e una macchina moderna.
Gli stessi identici risultati si ottengono pure con il codec MPEG2, 
evidentemente sembra trattarsi SOLO di un problema di spazio occupato.
O Sbaglio?

 O Sbaglio?
Non si tratta SOLO di un problema di spazio. Non a caso i codec xvid e 
divx fanno parte della famiglia del MPEG4 e non MPEG2.
Fanno parte di una generazione successiva, molto più ottimizzata. MPEG2, 
ormai vecchio di decenni, è in piedi per motivi di marketing che poi ne 
ha "causato" la sua diffusione.
Gli MPEG4 sono stati purtroppo associati ai video scadenti, a bassa 
risoluzione anche se questi sono stati i motivi che hanno permesso la 
loro diffusione.
Per rendersi effettivamente conto della maggiore bontà di questi codec 
si dovrebbe avere sotto mano un master digitale di un film e poi farne 
la compressione prima con il vecchio MPEG2 e poi con MPEG4: si 
noterebbe, oltre al minor spazio occupato dal secondo, una qualità nei 
colori, nella brillantezza, nettamente superiore.
Io ho fatto queste prove con i filmati della mia videocamera digitale. 
Oltre a farmi il classico DVD da vedere sul lettore di casa, mi faccio 
anche la copia in Xvid da tenere a parte beh: è un'altra cosa...
Poi in rete e su questo ng ci sono persone veramente competenti che 
sapranno svelarti le differenze dal punto di vista strettamente tecnico 
ma che dovrebbero comunque, avvalorare la mia tesi.


O Sbaglio?
sbagli.
Paragona un video ottenuto col vecchio ma affidabile divx3 low, ad uno
ottenuto col nemmeno poi molto recente ma poco sfruttato (per ora)
h264.
noterai la differenza che passa tra una 500 vecchio modello ed una
Musa di adesso.
certo, tra il divx5 ed il 6, o tra l'xvid 1.0 e l'1.1 final non
intercorrono queste differenze, ma e' giusto cosi' essendo queste
release separate da pochi mesi di vita.
Se googli un po' trovi interessanti guide e confronti, anche con altri
tipi di codec ancora piu' nuovi e performanti.
Diciamo che come hai giustamente detto anche tu, ormai non e' una
questione di spazio...i dvd li trovi a 30centesimi, gli hd ci sono da
500gb,le chiavette usb viaggiano sui 4+ gb... e' proprio diventata
solamente una questione di prestazioni: si cerca di ottenere un codec
che offra una qualita' paragonabile,o magari anche superiore,allo
standard del momento; e lo standard di questo periodo e' il dvd.
------------------------------------------------
Nike:"Non chiamatela fortuna ma potere della casualita'!"
Kill Bill e' il mio vangelo,Tarantino il mio profeta!
Captain Tsubasa 5...the best ever!

 che dovrebbero comunque, avvalorare la mia tesi.
Ecco..ma quindi quello che continuo a non capire è perchè ad esempio su 
internet continuano a diffondere film con codec recenti quando in realtà si 
vedono già male all'inizio perchè presi da un'altra fonte? 

 standard del momento; e lo standard di questo periodo e' il dvd.
Ma scusa: se in giro su internet mettono i film rippati da dvd come possono 
pretendere di migliorare la fonte?
A quel punto non conviene usare ugualmente un codec classico, ed 
eventualmente aumentare il bitrate?
Questa storia dell'uscita continua dei codec a me sembra una scusa per far 
continuare a comprare nuovi lettori quando sappiamo benissimo che l'uso 
maggiore è per vedere dei film che nella gran parte dei casi non sono di 
qualità video iniziale ottimale, e che probabilmente se fossero codificati 
con vecchi codec si vedrebbero poche differenze, sebbene venga impiegato 
qualche mb in piu...

 vedono già male all'inizio perchè presi da un'altra fonte? 
Ascolta, io parlo della "bontà" dei codec recenti. Lo so che una ferrari 
non la sfrutti se giri nel traffico congestionato di roma o milano.
Ti ho detto infatti che la diffusione di mpeg4 è dovuta in gran parte 
all'abitudine di comprimere filmati già compressi con altri codec (es. i 
dvd compressi con mpeg2) per ridurne le dimensioni.
E' ovvio che in questo caso la qualità si degrada!
Il succo, se non fosse chiaro, è questo: i codec recenti, come divx5-6 o 
xvid sono sena dubbio migliori dei precedenti divx3 e mpeg2 poi ognuno 
li usa come crede.
Io per esempio codifico i miei filmati in alta definizione in xvid o 
divx in alta definizione. Usando un bitrate medio di 10.000, ottengo dei 
filmati di qualità eccelsa cosa che, a paritò di impostazioni, non 
otterresti mai con un codec mpeg2.


 qualche mb in piu...
Ormai divx e xvid sono standardizzati in quasi tutti i lettori e non 
credo ci sia una corsa dei produttori ad affinare i loro strumenti.
Non condivido quindi il tuo pensiero.


 ha "causato" la sua diffusione.
non proprio decenni, diciamo poco piu' di un decennio, che e' comunque
un sacco di tempo in questo ambito.
Colgo l'occasione di questo thread per raccontare un po' la storia di
questi standard di compressione video digitale.
Innanzitutto, chi e' che fa gli "standard"?
Gli standard sono fatti da organizzazioni internazionali preposte a tale
scopo (ISO, CCITT poi ITU ecc), e le persone fisiche coinvolte nello
sviluppo degli standard sono incaricate di volta in volta da tali
organizzazioni; si tratta di ingegneri o informatici che tipicamente
lavorano per grosse aziende oppure per delle universita'.
Questi sono gli standard "ufficiali", cioe' progettati per diventare
standard in seno alla comunita' internazionale.
Poi ci sono gli "standard de facto", quelli cioe' che non vengono
progettati da organismi internazionali, ma da entita' private: chiunque
puo' inventarsi nuovi formati e nuove tecnologie; se riesce a far si'
che una certa massa critica di gente al mondo usi i suoi formati, allora
questi diventano uno standard de facto. In pratica questo non succede
quasi mai, nemmeno se i formati sono effettivamente molto validi rispetto
agli alternativi, a meno che l'entita' privata che ha sviluppato il
formato non abbia il potere di imporlo: e' questo il caso di una grossa
azienda di software statunitense, che ha il potere di imporre come
standard de facto qualsiasi suo formato (anche se e' una cagata di
formato) infischiandosene della comunita' informatica internazionale,
semplicemente sfruttando l'abnorme diffusione del suo sistema operativo.
Un caso molto diverso di formato sviluppato da entita' private e'
quello del contenitore Matroska (MKV). Si tratta di un contenitore
multimediale molto carino e ben fatto, che non e' stato realizzato da
alcun organismo internazionale, ma da un gruppo di volontari che
lavorano su di esso tramite la rete. Nonostante gli autori di Matroska,
per quanto ne sappia, non abbiano il potere di imporre alcunche', in
questi ultimi anni ha riscosso un notevole successo e si e' diffuso tra
molti appassionati. (Resta da vedere se le prossime generazioni di
lettori multimediali hardware lo supporteranno... ma sembrerebbe facile
prevedere che i produttori si orienteranno quasi esclusivamente
sull'alternativa "standard", cioe' MP4).
Torniamo agli standard internazionali. Le organizzazioni che si sono
occupate della stesura degli standard di compressione video digitale
(e anche audio, e non solo compressione) sono ISO e ITU.
La prima ha istituito un gruppo di lavoro soprannominato MPEG (motion
picture expert group) e il secondo il gruppo VCEG (video coding expert
group). Il primo e' quello che definisce gli standard soprannominati
appunto MPEG, mentre il secondo e' quello che ha definito la serie di
standard H.261, H.262, H.263, H.264.
In realta' i due gruppi (e i relativi standard) non sono tra loro del
tutto indipendenti; trattandosi di organismi ufficiali c'e' una buona
dose di cooperazione, anzi, capita che parti dei due gruppi si fondano
per formare nuovi gruppi al fine di progettare standard comuni. Quando
uno standard viene definito da gruppi facenti capo a entrambi gli
organismi, ognuno pubblica lo stesso documento con sigle diverse. Ad
esempio, il documento che descrive la tecnologia di compressione H.262
(ITU-T Recommendation H.262) e' lo stesso di quello pubblicato da ISO
per descrivere MPEG-2 (ISO/IEC 13818). Va notato che il gruppo MPEG,
al contrario del VCEG (ITU), non si occupa solo strettamente di
compressione video, ma di tutta una serie di altre cose (compressione
audio, contenitori e "system streams", e delle problematiche relative
a queste tecnologie...).
Il primo codec degno di nota (cioe' dove venne introdotta la "motion
compensation" che sfrutta la ridondanza temporale tra frame che fanno
parte della stessa sequenza video; in altre parole, i P-frame...)
fu H.261 (CCITT, in seguito ITU-T Recommendation H.261), seguito da
MPEG-1 (ISO). Salto la storia di MPEG-1 altrimenti la faccio troppo
lunga...
Passiamo a MPEG-2. Quando si parla di MPEG-2 il piu' delle volte ci
si intende riferire a un codec video, ma MPEG-2 e' una serie di
documenti ISO siglati "ISO/IEC 13818".
Lo stesso avviene per MPEG-4: con questo termine si dovrebbe intendere
la serie di documenti siglati "ISO/IEC 14496" e intitolati globalmente
"Information Technology - Coding of audio-visual objects".
Questi documenti sono attualmente una ventina, e non sono stati redatti
tutti insieme, ma un po' alla volta nel corso degli anni, e ogni tanto
vengono anche aggiornati con appendici o "errata corrige"...
Ogni documento della serie ha un numero progressivo.
Ad esempio, i documenti MPEG-4 che piu' interessano i frequentatori di
questo Ng sono il secondo (ISO/IEC 14496-2, intitolato "Visual") e il
decimo (ISO/IEC 14496-10, intitolato "Advanced Video Coding").
Ma voglio ricordare che tra questi documenti c'e' anche il terzo che
descrive AAC (Advanced Audio Coding), e soprattutto quelli che
descrivono il contenitore multimediale "MP4" (purtroppo non c'e' un
unico documento per MP4: anche se il quattordicesimo si intitola
"MP4 file format", in realta' la descrizione e' distribuita tra il
primo, il dodicesimo e il quattordicesimo... inoltre esistono delle
estensioni specifiche che si trovano da altre parti...).
Perche' e' importante il secondo documento (MPEG-4 Visual)?
Be', questo Ng si chiama it.comp.software.divx e "DivX" e' un codec
che e' conforme alla descrizione contenuta in quel documento.
A questo punto e' necessario fare una precisazione: cos'e' un
codec? Cioe', il codec e' DivX oppure lo e' il documento
"MPEG-4 Part 2 - Visual"?
Da quanto ho letto in giro, molte persone usano il termine codec
per entrambe le cose, comunque l'importante e' tenere bene in mente
la distinzione tra "definizione di una tecnologia di compressione
video" e una specifica implementazione di tale tecnologia.
Quindi, "MPEG-4 Part 2 - Visual" (ISO/IEC 14496-2) e' il documento
che descrive una tecnologia di compressione video, mentre DivX e'
soltanto la sua implementazione piu' famosa. Naturalmente non e'
la sua unica implementazione, ma esistono molte alternative, sia
commerciali (come quella di Nero, oppure "3ivx"), sia open source:
la piu' famosa e diffusa e' XviD, ma ne esiste un'altra molto
valida che fa parte della libreria libavcodec del progetto ffmpeg.
A questo punto accenno brevemente alla storia del DivX, che pur
essendo commerciale, per un certo periodo e' stato un progetto
"open source" (alcuni anni fa molte aziende si sono avvalse del
modello di sviluppo open source, in quanto presenta dei vantaggi
non indifferenti, primo fra tutti il fatto che viene debuggato
*gratuitamente* da volontari sparsi per tutto il mondo :-)).
Nel suo periodo open source, si chiamava "OpenDivX", veniva
sviluppato essenzialmente sotto linux e il sito di riferimento
del progetto (Project Mayo) era 
http://www.projectmayo.com
 .
A un certo punto, i detentori dei diritti (quelli che avevano fatto
partire il progetto e che sono i fondatori dell'azienda "DivX
Networks") richiusero il codice sorgente, cioe' lasciarono il sito
http://www.projectmayo.com
 abbandonato e puntarono sulla
commercializzazione del codec in ambito esclusivamente Windows
sul sito 
http://divx.com
 .
Nel frattempo si era formata una "comunita' di sviluppatori di
open divx", cioe' dei programmatori che avevano volontariamente
contribuito allo sviluppo del codec, organizzati sulla classica
"mailing list degli sviluppatori"... Comprensibilmente la chiusura
del codice da parte dei titolari di "DivX Networks" fu un po'
deludente, sebbene probabilmente fosse stata prevedibile fin dal
principio.
Il punto e' che "DivX Networks" aveva tutto il diritto di chiudere
il codice sorgente e continuarne lo sviluppo e la commercializzazione
secondo il classico modello di sviluppo chiuso.
D'altra parte, quelli che avevano contribuito al progetto, avevano
tutto il diritto di prendere il codice sorgente al punto in cui era
arrivato e partire da quello per continuare a svilupparlo in modo
indipendente dalla "DivX Networks". Bastava cambiare il nome al
codec... e cosi' nacque XviD (DivX al contrario) :-)
Un fenomeno di questo tipo, nell'ambito dei progetti software,
si chiama "fork" (il termine "fork" e' molto significativo in
informatica, ad esempio "fork" e' una chiamata di sistema unix
che provoca la creazione di un processo dal processo che esegue
la "fork", in modo che dopo la chiamata si abbiano due processi
che proseguono ciascuno per proprio conto).
Ma torniamo a MPEG-4 Part 2 (Visual).
Questo documento, nelle intenzioni del gruppo di lavoro, doveva
descrivere la tecnologia di compressione successiva al precedente
MPEG-2 (lo standard impiegato nei DVD e nelle trasmissioni
satellitari). Nel frattempo, dalla parte di ITU era stato definito
lo standard H.263 che gia' aveva introdotto vari miglioramenti a
MPEG-2/H.262.
Allora, semplicemente il gruppo MPEG prese H.263 come punto di
partenza, e in effetti il profilo SP (simple profile) coincide
praticamente con H.263. Ma MPEG-4 Visual e' in realta' un progetto
molto ambizioso, che prevedeva fin dall'inizio un numero enorme di
"profili" per coprire una vasta gamma di utilizzi dello standard.
Quindi, nei profili successivi introdussero tutta una serie di
nuove features. A noi (frequentatori del Ng) interessa praticamente
solo il profilo ASP (advanced simple profile), ma ne esistono una
ventina per gli usi piu' disparati (si noti che H.264 al confronto
ha soltanto tre profili! In effetti H.264 e MPEG-4 Visual hanno
campi di utilizzo differenti, quindi non andrebbero visti come
l'uno il successore dell'altro).
Ad esempio, cosa introduce il profilo ASP, rispetto al SP?
Be', introduce i B-frames, la possibilita' di usare vettori di
movimento che riferiscono a blocchi interpolati a livello piu'
profondo ("quarter pixel", o qpel) e un tipo di motion
compensation facente uso di "sprite" utile nelle scene di
movimenti globali ("global motion compensation", o GMC).
Queste feature dell'advanced simple profile non erano ancora state
implementate nell' "Open DivX", ma furono implementate nel DivX 5
commerciale, quando era gia' stato chiuso, e vennero chiamate come
"DivX Pro"... In realta', tutti questi concetti non sono stati
inventati dal DivX (come spesso ho letto in giro qua e la'):
semplicemente gli sviluppatori stipendiati di DivX Networks non
hanno fatto altro che implementare tali feature sulle basi delle
specifiche (il documento ISO/IEC 14496-2), cosa che, per non
essere da meno, fecero anche gli sviluppatori dell'alternativa
open source XviD.
Concludo con qualche cenno a H.264.
Come dicevo sopra, non sarebbe del tutto giusto considerare H.264
la successiva evoluzione di MPEG-4 Visual, in quanto sono quasi
contemporanei e molte parti delle due tecniche sono state definite
contemporaneamente dalle stesse persone (MPEG-4 Visual e' stato
pubblicato nel 1999, contemporaneamente alle prime bozze di H.26L,
in seguito divenuto H.264); inoltre sono entrambi pubblicati nella
stessa serie di documenti MPEG-4 (mentre MPEG-2 e MPEG-1 erano altre
due serie distinte, definite in tempi diversi).
Mentre definiva la parte Visual (avendo tra gli obiettivi
primari piu' le caratteristiche di flessibilita' che quelle di
efficienza di compressione), il gruppo MPEG stava gia' progettando
la parte 10 della famiglia MPEG-4, cioe' "Advanced Video Coding"
(AVC) che, rispetto alla parte 2, aveva come unico obiettivo
primario l'efficienza di compressione (a scapito di altre proprieta'
generalmente desiderabili, come la semplicita' di implementazione
e altre questioni...).
Per la parte 10 (AVC) e per H.264, i gruppi di lavoro ISO e ITU
hanno unito i loro sforzi, progettando questi standard in comune
(come gia' avevano fatto in passato per MPEG-2/H.262). Nelle
parti finali della progettazione e' stato istituito un gruppo
congiunto "Joint Video Team" (JVT, formato da persone di entrambi
i gruppi) allo scopo di redigere la versione finale (pubblicabile)
del documento.
Alle fine (fine del 2003) lo stesso documento e' stato pubblicato
come documento ISO (ISO/IEC 14496-10) e ITU (ITU-T Recommendation
H.264), quindi, quando si parla di H.264 e di MPEG-4 AAC
(o Part 10) ci si sta sempre riferendo alla stessa cosa.
Per finire, vorrei chiarire un punto che spesso genera confusione.
Che differenza c'e' tra H.264 e x264?
Be', x264 e' un'implementazione open source dello standard H.264
(proprio come XviD e' un'implementazione open source del profilo
"advanced simple" dello standard MPEG-4 Visual o Part 2).
In altre parole: H.264 e' la tecnologia di compressione descritta
in un certo documento pubblicato alla fine del 2003;
x264 e' invece un'implementazione open source di tale tecnologia.
Esistono molte altre implementazioni di H.264, solitamente
commerciali.
Una domanda interessante e' la seguente: ma i gruppi di lavoro
che fanno gli standard, si limitano a inventare definizioni e
specifiche oppure scrivono anche programmi?
Questa e' una bella domanda :-) perche' non e' possibile definire
una tecnologia complessa come H.264 ignorando tutte le
problematiche che sorgono durante la sua implementazione!
In effetti, i membri dei gruppi di standardizzazione producono
sempre, insieme ai documenti, il cosiddetto "software di
riferimento dello standard", che consiste nell'implementazione di
una versione del codec aderente alle specifiche dello standard.
Ad esempio, in rete e' possibile scaricare il software di
riferimento di H.264 (chiamato "jm"), che comprende il codice
sorgente (in C liscio) di un encoder e di un decoder H.264.
Sia l'encoder che il decoder sono perfettamente funzionanti:
chiunque puo' compilarli e divertirsi a comprimere dei filmati
ottenendo bitstream H.264 del tutto validi (anzi, sono sicuramente
validi per definizione! :-)).
Oltretutto, sia l'encoder che il decoder di riferimento sono i
piu' completi che esistano tra le implementazioni di H.264 (ad
esempio, x264 e il decoder open source di ffmpeg non implementano
tutte le feature definite in H.264, mentre il software di
riferimento lo fa).
Allora perche' non si usa il software di riferimento in pratica?
Perche' purtroppo e' totalmente inefficiente: esso non viene
scritto allo scopo di essere utilizzato in pratica, ma allo
scopo di testare le idee dei progettisti (puo' accadere che
un'idea che in teoria sembra buona, alla prova dei fatti dia
pessimi risultati, o viceversa) e di illustrare i concetti a
chiunque voglia o debba studiare lo standard; quindi ha anche
uno scopo didattico. Inoltre serve a dimostrare che lo standard
non e' campato in aria, e che non e' impossibile da implementare.
Quindi, nel software di riferimento, le varie feature non sono
mai sfruttate fino ai limiti delle loro potenzialita';
inoltre e' scritto in C liscio (neanche troppo bene), non ci
sono ottimizzazioni, e, se paragonato con x264 e' lentissimo
(si parla di 20-30 volte piu' lento!) quindi inutilizzabile...
E' per questo che esistono x264 e le altre implementazioni :-)
Ammazza quanto ho scritto... chiedo scusa per gli eventuali
errori, ma ho scritto di getto e ora non posso rileggere e
correggere...
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

 correggere...
Diavolo, che documento! Da salvare e studiare.
Complimenti davvero.
Grazie, ciao.


 otterresti mai con un codec mpeg2.
Sicuramente.
Però torno a ripetere, secondo me questi codec avanzati sono sprecati se 
impiegati per un film rippato.
Il divx classico a mio avviso sarebbe sufficiente. 

 ci sia una corsa dei produttori ad affinare i loro strumenti.
Mi pare che però continuino ad esserci di continuo lamentele di persone che 
non riescono a vedere filmati sul lettore da tavolo, anche se recente, 
proprio perchè escono continuamente aggiornamenti di codec.
I produttori poi come al solito non rilasciano nuove versioni di firmware, 
se non in casi particolari, così possono vendere il modello successivo.

 se non in casi particolari, così possono vendere il modello successivo.
Ma tu fammi capire, cercavi delle delucidazioni su di un argomento, tra 
l'altro ampiamente espresse da frank sinapsi, o volevi solo fare una 
semplice polemica?
Se già sei convinto della tua tesi che pensi non possa essere in alcun 
modo messa in discussione, è inutile che posti un thread, non credi? :)


 modo messa in discussione, è inutile che posti un thread, non credi? :)
Non è che voglia fare una polemica: semplicemente volevo capire se ci 
fossero particolari motivazioni oltre alla dimensione di un file.

 fossero particolari motivazioni oltre alla dimensione di un file.
Per l'ennesima e ultima volta:
le motivazioni, oltre alla dimensione di un file, risiedono nella 
qualità a parità di bitrate, negli algoritmi di codifica, nelle opzioni 
selezionabili, nella migliorata velocità di encoding (grazie anche allo 
sfruttamento delle tecnologia dual core delle cpu per esempio).
Spero di essere stato esaustivo.
Io ho finito.


 Ammazza quanto ho scritto...
Fenomenale come sempre. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
"È duro essere negro. Ti è mai capitato di esserlo?"
"A me sì, una volta, quando ero povero." - Larry Holmes

qualche mb in piu...
Personalmente io uso sempre XVID quando comprimo qualcosa, mi trovo
molto bene e viene digerito da quasi tutti i lettori.
Ciao
-- 
Fritz
Togli *ERASE* per rispondere in e-mail.

 molto bene e viene digerito da quasi tutti i lettori.
Io quello o libavcodec.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Maybe we can't stroll to the music of the lutes. We must march to
the sound of drums. - Captain Kirk - Star Trek TOS


Hai mai sentito parlare di progresso? Di maggiore qualità, efficacia ed
efficienza?
Questo avviene per i servizi così come per il software, per fortuna 
aggiungo.
Prova a confrontare un film 720p codificato in h26x con un divx5 a 
512*non_so_che e poi capirai perchè vengono creati nuovi formati di 
codifica e contenitori...
Il problema dei player stand alone che non vanno con certi formati è 
colpa dei produttori: fin tanto che non si decidono a fare prodotti di 
qualità e aggiornabili continueremo a dover comprare ogni 2-3 anni 
player di bassa qualità appena sufficienti anche se li paghiamo solo 
50-80€. A molti clienti va bene così (spendo poco e cambio spesso, la 
qualità è quella che è ma mi accontento).
  ciao
-- 
Un ottimo forum sui player DVD/divx/xvid/mpeg4: 
http://www.quellicheilpc.com/forum/


Il produrre lettori non aggiornabili ed economici è il motivo che ti 
costringe a cambiarli. La xbox era molto aggiornabile (un PC 
praticamente) e stava completamente al passo con qualunque nuovo codec 
(fin tanto che la CPU gli stava dietro...). L'infrastruttura hardware 
dei player stand alone è invece alquanto non aggiornabile con nuovo 
software (la codifica viene fatta via hardware poco versatile ma 
economico e quindi a livello software si possono fare update poco 
significativi, la xbox invece aveva un processore molto versatile 
sebbene più costoso e quindi poteva fare qualunque decodifica se 
pilotato da software adeguato aggiornato nel tempo. Ho utilizzato un 
abuso di linguaggio ma giusto per farmi capire ;) ).


 
Evidentemente se si lamentano vuol dire che non si erano informate a 
sufficienza delle scarse possibilità di update future dell'hardware che 
hanno comprato.
Se ci fosse un player stand alone che decodifica perfettamente i nuovi 
stream audio/video in altissima risoluzione, con ottimo supporto di 
sottotitoli, ottime connessioni anche a livello di 
rete/usb/wireless/lan_wired ad un buon prezzo e continuamente 
aggiornabile lo compreremmo in tanti ma non esiste (o io non ne sono a 
conoscenza).
Se uno non vuole le restrizioni dei player stand alone che colleghi il 
PC portatile al TV o al videoproiettore.... quello lo aggiorni sempre 
(fin tanto che la CPU sta dietro alla potenza richiesta dai nuovi codec).


 qualità è quella che è ma mi accontento).
Anche io giuro, ce l'ho messa tutta per farglielo capire... :)


 
Più varie ed eventuali: chi lo sa cosa faranno domani?
