H.265, prima approvazione per il nuovo standard di encoding video

[Lord Infamia]

Wow ho creato un mostro! Mi è bastato scrivere T2 per far riempire questo thread di commenti

Ma veniamo a noi:

Originariamente inviato da Benjamin Reilly

[...] praticamente l'hardware dovrebbe beneficiarne con un notevole risparmio operativo; si potrebbe desumere che il problema dei video ad alta risoluzione non dovrebbe costituire più un limite nemmeno per i vecchi processori mono-core.

Ora sarei interessato a capire quali requisiti hardware e software occorre rispettare per poter fruire della codifica h.265. Spero alcuno in particolare.

Originariamente inviato da EmaGuzzetti

Bisogna attendere un po per saperlo per certo, ma non sembra ci sia un circuito hardware dedicato al decoding, è il chip broadcom che lo fa ma solosia "solo" un potentissimo arm quad core

Scusate la mia ignoranza (sul serio, niente ironia o sarcasmo), ma non ho capito se h.265 graverà di più o di meno sulle specifiche hw (a parità di bitrate o qualità) rispetto a h.264...

Bisogna poi anche dire che le impostazioni a bassissimo bitrate spremendo al massimo il codec interessano solo noi utenti per i backup e alla pirateria.

E i fansubber, che ultimamente hanno iniziato a convertire i loro file a 10bit, rispetto agli 8 precedentemente usati (operazione che però aumenta la soglia minima di prestazioni hardware per vedere il video)...

Comunque, avevo letto anch'io da qualche parte che l'idea probabile era quella di arrivare prima o poi (molto ma molto più poi che prima) ad un secondo switch-off, da t1 a t2+H.265, per liberare banda da dare alle reti mobili, sempre più affamate, mettendo nella metà dello spazio gli stessi mux attualmente in uso.

PS: preciso, per chi non se ne fosse ancora accorto, che le mie conoscenze in ambito video sono più o meno a questo livello, dall'alto dei miei 2 tentativi di encodare un video personale (...miseramente falliti, con video effetto mosaico da pochi secondi a diversi giga di dimensione XD):
http://i1.kym-cdn.com/photos/images/...34/739/fa5.jpg

[Benjamin Reilly]

alcune dimostrazioni e spiegazioni tratte da youtube:

http://www.youtube.com/watch?v=PZP75PEQo6E

http://www.youtube.com/watch?v=rGifAEK7iQc

[maxmax80]

Originariamente inviato da calabar

Ho riletto ponendo enfasi alla parola "tecnicamente", ma trovo ancora insensata la tua affermazione secondo cui "passare dal h.264 all' h.265 [...] è pur sempre una perdita di qualità".
Passare ad h265 mantenendo lo stesso bitrate è un guadagno di qualità, altrimenti che senso avrebbe far uscire un nuovo codec?

La domanda vera è: con quale bitrate h265 è in grado di ottenere una qualità paragonabile ad h264?
Sicuramente un bitrate inferiore (ci mancherebbe altro), se quanto annunciato corrisponde a verità sarà un bitrate dimezzato.

PS: se mai hai seguito il mondo del ripping video, allora ben sai che anche a parità di bitrate si possono ottenere, con lo stesso codec, risultati ben differenti...Magari h265 ottiene parte del proprio vantaggio proprio dalla capacità di fare automaticamente "sintonia fine" in base al source.

ripeto, non discuto che il codec h265 sia ottimizzato meglio, sia migliore dell' h264, ottenendo la stessa qualità con un bitrate inferiore.

ma a livello puramente di numeri, il bitrate è inferiore.

[AleLinuxBSD]

Chiaramente l'approccio sarà di tipo assimetrico, che richiederà molta potenza di calcolo in fase di codifica e poca in fase di decodifica, ma ci saranno differenze significative rispetto all' h.264 oppure no, in termini di risorse computazionali richieste?

[jappilas]

Originariamente inviato da fano

E' come dire che un MPEG1 con bitrate di 8 MB/s si vede meglio di un H264 a 768 KB/s... sì MPEG1 ha più "informazione" (nel senso che il file è più grosso), ma si vede di m*rda

Da notare, comunque, che tutti i formati digitali hanno sempre una perdita dovuta al campionamento: nel campo audio si parla dei famosi 44 KHz (vale anche per i cosiddetti formati lossless anche WAV e FLAC campionano l'analogico!)

i famosi 44 khz sono stati scelti proprio perchè strettamente maggiori del doppio della più elevata frequenza della banda dell' udibile - cosa che per il teorema del campionamento avrebbe consentito un campionamento accurato del segnale sonoro

mentre nel campo video d'altro canto si "sacrificano" parti della terna RGB almeno per i codec consumer...

l' uso dello spazio colore in luminanza e crominanza fa parte della pipeline di trasmissione video già dai tempi dell' analogico...

se non sbaglio H264 usa la codifica colore 4:2:0, esatto il blu non è manco memorizzato: è interpolato dal codec

...per cui da una parte quei numeri non vanno interpretati come R, G e B ma Y (luminanza), Cb e Cr (quindi il blu è memorizzato - in compenso non lo è nemmeno in forma differenziale, il verde, ricostruito da Y e U tramite apposita formula)
dall' altra, "4:2:0" denota che l' informazione di crominanza sia trasmessa a metà frequenza rispetto alla luminanza, con Cb e Cr campionate a righe alterne - cosa perfettamente in linea con il sistema televisivo PAL / SECAM, interlacciato e con risoluzione di crominanza dimezzata rispetto all' NTSC...

I formati professionali usano anche 4:2:2 e il D-Cinema dovrebbe usare 4:4:4 il più vicino che si possa immaginare all'analogico... ma, probabilmente, anche con H265 avremmo un'occupazione di 1 TB al minuto

quello è il meno, i formati professionali impiegano anche elevate risoluzioni, precisioni in bit, algortmi, e spesso e volentieri salvano frame per frame, senza applicare compressioni a perdita d' informazione (che è quello che i codec mainstream fanno per risparmiare spazio e banda)...

L'unico tentativo di fare un vero codec audio lossless fu il formato DSD di Sony usato nei (defunti) Super Audio CD...

un sistema di memorizzazione e trasmissione di segnali è lossless quando preserva l' informazione - quando le eventuali tecniche di compressione impiegate non impediscono di ricostruire a destinazione/riproduzione, la stessa informazione digitale di partenza - e lossy quando l' informazione ricostruita è un' (accettabile) approssimazione di quella di partenza, questo a prescindere dalla maggiore o minore qualità / precisione data dalla specifica codifica
in questo senso il CD (o un file wav codificato in PCM) è lossless tanto quanto il DSD (che pur cercava di aumentare la gamma dinamica e migliorare la risposta in frequenza del sistema audio attraverso il sovracampionamento - e che per questo doveva trasportare molti più dati binari - ma d' altro canto portava con sè problematiche tecniche non indifferenti)

"campionava" a 1 Bit,

il DSD campiona (senza virgolette) a 1 bit, ma alla frequenza di 2.8 MHz (64 volte il cd) e usando una modulazione differente

nei fatti la forma d'onda ottenuta approssimava molto una graziosa sinusoide analogica

veramente quella che nonostante gli "scalini" dati dal campionamento e dalla discretizzazione, approssima maggiormente la sinusoide continua di riferimento,sembrerebbe la codifica PCM...

Purtroppo, un segnale del genere, era difficile da trasmettere all'amplificatore in particolare nella versione Multicanale... la SPDIF non aveva la banda sufficiente per trasmettere il flusso DSD <...>

più che altro, la spd/if lavora in PCM a 44-48 khz quindi in ogni caso avrebbe richiesto una conversione - demodulazione dalla PDM nativa del SACD

a parte ciò pare ci fossero problemi di ordine diverso, nel senso da una parte di una codifica soggetta a distorsione per via dell' usare solo 1 bit per campione (motivo per cui si impiegava un noise shaper e dei filtri per fare in modo che le componenti di rumore finissero oltre il range dell' udibile)
dall' altra che nonostante il dsd permettesse una qualità paragonabile a quella di audio PCM campionato a 96 khz, un sistema PCM con campioni a 24 bit avrebbe avuto un migliore rapporto S/N - con il vantaggio inoltre di semplificare le elaborazioni in locale (i DSP hanno difficoltà a lavorare a 1 bit, quindi anche l' equalizzatore digitale avrebbe prima efettuato una conversione in PCM) e in studio (giacchè i tool professionali erano/sono sostanzialmente PCM oriented - quindi molte produzioni SACD erano sostanzialmente PCM convertite, senza la migliore qualità teoricamente consentita dal mezzo)

[calabar]

Originariamente inviato da maxmax80

ma a livello puramente di numeri, il bitrate è inferiore.

Il bitrate lo decidi tu, a seconda del risultato che vuoi ottenere.
Posso scegliere un bitrate alto anche per h265 (ci mancherebbe altro), otterrò una qualità molto alta (e molto spreco di banda, probabilmente, dato che molti miglioramenti legati ad una bitrate alto saranno impercettibili).

[Benjamin Reilly]

OT: io non ho mai capito perchè tv e monitor utilizzano la terna giallo verde e rosso e non giallo blu e rosso, ossia i colori originari.

IT: quello che ho capito confrontandomi con altre utenze è che la cpu dovrebbe purtroppo essere oberata maggiormente nella codifica, quindi ad una repentina acquisizione della traccia dovrebbe corrispondere un peggioramento nelle prestazioni hardware, a meno che qualche tecnico non implementi qualche script che applichi il calcolo parallelo delle cpu, come ad esempio le istruzioni sse2.

[Benjamin Reilly]

Originariamente inviato da Bivvoz

Scusa non usano rosso, verde e blu?
Red, Green, Blue = RGB?

Infatti sharp ha fatto la linea quattron con anche il giallo.



Comunque non ho capito manco io perchè si è sempre usato rosso, verde e blu.

no, usano red, green and blue. rosso, verde e blue.

R G B Y= rosso verde blue e giallo.... sostanzialmente il verde è superfluo in questo caso, mentre è più utile il K (key black) perchè risalta i colori con un nero abbastanza intenso, solitamente afferisce a questa combinazione alternativa di colori, indicata con la sigla CYMK: cyan (blue), yellow (giallo), magenta(rosso) e kay black.

[zappy]

Originariamente inviato da Benjamin Reilly

no, usano red, green and blue. rosso, verde e blue.

R G B Y= rosso verde blue e giallo.... sostanzialmente il verde è superfluo in questo caso, mentre è più utile il K (key black) perchè risalta i colori con un nero abbastanza intenso, solitamente afferisce a questa combinazione alternativa di colori, indicata con la sigla CYMK: cyan (blue), yellow (giallo), magenta(rosso) e kay black.

codificare il nero in un'immagine luminosa è inutile: il nero è "no luce", non hasenso fare la codifica.

sul perchè si usi il verde, penso sia perchè è il colore a cui la retina umana è più sensibile, o meglio a cui sono più sensibili i bastoncelli (http://it.wikipedia.org/wiki/Bastoncello)

[Benjamin Reilly]

Originariamente inviato da zappy

codificare il nero in un'immagine luminosa è inutile: il nero è "no luce", non hasenso fare la codifica.

sul perchè si usi il verde, penso sia perchè è il colore a cui la retina umana è più sensibile, o meglio a cui sono più sensibili i bastoncelli (http://it.wikipedia.org/wiki/Bastoncello)

potrebbe essere la spiegazione, grazie.

probabilmente il colore giallo lo otterranno per sottrazione blue dal verde.