29 Marzo 2018
ITU (International Telecommunication Union) e il consorzio MPEG hanno fornito i risultati dei primi test relativi al codec che dovrebbe in futuro sostituire HEVC. La novità, nome in codice JEM (Joint Exploration Mode), promette di abbattere considerevolmente il consumo di banda. A parità di qualità delle immagini, JEM ha mostrato un'efficienza superiore del 35 - 60% rispetto a HEVC. Si tratta quindi di prestazioni molto buone, considerando lo stato ancora tutt'altro che definitivo del codec. I miglioramenti permetterebbero di veicolare più facilmente i video a maggiore risoluzione (ad esempio in 8K) o con un frame rate superiore (100 o 120 fps), senza andare ad appesantire eccessivamente le infrastrutture e senza pesare troppo sulle connessioni mobili.
I test hanno evidenziato anche alcune problematiche. Il tempo richiesto per l'encoding è tra le 12 e le 60 volte superiore. Questo significa che una trasmissione in diretta con HEVC può essere realizzata quasi istantaneamente, mentre per JEM attualmente si può arrivare ad un minuto in più. Anche le risorse richieste per la decodifica sono decisamente più alte: si parla di tempi fino a 10 volte superiori. Va però specificato che JEM è al momento gestito interamente via software. L'accelerazione hardware arriverà solo prossimamente e sicuramente migliorerà sensibilmente le prestazioni.
La prima versione stabile è indicativamente prevista per l'autunno del 2020.
Commenti
o ho frainteso, oppure mi è parso che tu intendessi "sarà anche meglio, ma è troppo lento" e ho replicato che non è una battaglia alla pari potendo AL MOMENTO effettuare qualsiasi decodifica / codifica solo via software su questo nuovo codec. Tutto qua.
E si, ho capito :-D
NO! Io dico che una diretta con 60 secondi NON SI PUÓ FARE.
Né con 6, né con 60, né con 600, né con 6000 secondi di ritardo. La mia non é una puntualizzazione semantica (sopra i 10 secondi non é definibile "diretta") ma logica.
Finché i sistemi non saranno in grado di processare in tempo reale, le dirette saranno impossibili.
L'articolista si é inventato che si possono fare con 60 secondi di ritardo, ma non spiega da dove discenda tale ragionamento.
O si possono fare (quindi la potenza per farlo in tempo reale esiste giá) o non si possono fare. Che si possano fare con 60 secondi di ritardo non ha giustificazione logica, almeno non nella potenza di calcolo come scritto nell'articolo.
AAAAH, ora ho capito il tuo dubbio. Una diretta con 60 secondi di ritardo su ogni secondo non è una diretta, chiaro!
Infatti! Non capisco da dove l'articolista avrebbe dedotto che la diretta si potrebbe fare, ma con un minuto di ritardo. Semplicemente non si può fare!
e beh dai...
allora aspetto il 2020 per p1sc1are...
( non so... spero dopo sia almeno dal 35 al 60% più efficente la p1sc1at4 ).
Tnx.
Grazie.
E infatti non funziona :D l'articolo dice proprio che questo è il promo scoglio da affrontare e al momento teoricamente si risolverebbe con 60 volte la potenza computazionale, tenuto conto però che ancora l'encoder è software e non hardware (dettaglio assolutamente da non sottovalutare).
Ecco vedi, era la risposta che volevo sapere, grazie dell'informazione, anche la mia risposta è stata garbata e ironica, saluti
Ora mi sono calmato dai.
Generalmente ogni codec nuovo è un casino, richiede un supporto HW dedicato. Quelli vecchi li diamo per scontati dato che esistono già, ma per esempio fino a due anni fa (circa) non c'era ancora il supporto H265 sulle GPU e tutto veniva fatto dalla CPU (con limiti incredibili)
Se ero nato imparato non facevo la domanda, ma qui ci sono solo i sapientoni. Grazie.
Si, tutto corretto, ma cosa c'entra con quello che ho scritto io?
HEVC è già BEN supportato via HW da tanti componenti, quindi gode di offload e benefici vari. JEM in quanto 'nuovo' NO: tutto via software (direi tutto a carico della CPU, e se non vien detto con quale macchina han eseguito il test....)
è un nuovo algoritmo di codifica non un nuovo profilo per quelli esistenti, quindi NO.
AHAHAHAHAH!
Apri un H265 su un portatile di qualche anno fa e dimmi come gira bene.
CERTO CHE NO CHE DOMANDA È
Infatti il codec non é ad uso esclusivo dello streaming, quindi il discorso é più generico.
Il resto del tuo discorso non lo capisco, visto che
1. "Il tempo richiesto per l'encoding è tra le 12 e le 60 volte superiore"
2. "si parla di tempi fino a 10 volte superiori"
quindi si parla di tempi e non di quantità di dati: non vuol dire che JEM richieda una pacchettizzazione come presumi tu (nell'ordine delle centinaia/migliaia di frame)
Vero, così come è stato spiegate ha poco senso: o gli apparati di codifica riescono a stare dietro al flusso oppure no.
Nel primo caso si può fare la diretta, nel secondo no.
Dal tuo post, non era così evidente che fosse chiaro.
Proprio perché si parla di streaming, infatti, non c'entra nulla la potenza di calcolo: se infatti il problema fosse quello che hai indicato tu, non si potrebbe proprio parlare di streaming.
Premesso che l'articolo è un po' fumoso, immagino che la questione sia riferita alla quantità di dati, necessaria all'algoritmo per poter operare.
Se HEVC opera su 1 s di video per volta, JEM richiederà (in questa prima bozza) fra i 12 ed i 60 s di video.
Naturalmente sì
grazie per averlo puntualizzato, in effetti qui non se ne era accorto ancora nessuno
Si sta parlando di streaming video.
non devi guardare il nr di core ma il prezzo , il CONFRONTO VA FATTO SUL PREZZO :)
Cmq LG è 1080p...
Affidabili?
Bass8 e OnlineStore
Dove li hai trovati questi prezzi?
https://uploads.disquscdn.c...
te ne do una io brutta, allo stesso prezzo esce uno skylake 7900X che esce stracciato dal confronto, nell'encoding , anzi viene superato anche dal Threadripper 1920 da 799 dollari,cosi, per dire https://uploads.disquscdn.c...
"La prima versione stabile è indicativamente prevista per l'autunno del 2020."
Sicuramente compatibile...
Discuto sull'illogicità del ragionamento.
Il primo secondo arriva con un minuto di ritardo. Appena terminato di codificare il primo secondo (in 1 min) il sistema passa a codificare il secondo secondo (e ci mette 1 altro minuto). Passati 2 minuti, comincerá a codificare il terzo secondo (mettendoci ancora 1 minuto).
Quindi io (spettatore) vedró un secondo di trasmissione ogni minuto: una pessima qualità di servizio.
É l'equivalente di Youtube ad alta definizione con connessione lenta: se youtube ci mette 1 minuto ad inviarmi 1 secondo di video, io passeró 59 secondi ad aspettare il buffering. Se anche decidessi di mettere pausa per 1 minuto e facilitare il buffer, potrei solo godermi 2 secondi continuativi di video prima che ricominci il buffering.
In breve, l'unico modo per avere una diretta fluida é che i dati in un sistema escano alla stessa velocitá con cui entrano, quindi che il sistema di codifica possa funzionare in tempo reale.
Guarda secondo me la risposta di gioboni è valida. Hai una partita da mandare in diretta? Con encoding hevc sei in ritardo di 1 secondo sulla diretta, con encoding Jem saresti 1 minuto in ritardo. Se il dato è corretto non lo so, non ho letto la fonte e sto dando fiducia a quanto scritto qui. Detto questo non capisco se il tuo dubbio cade sulla veridicità del dato sul ritardo o su come lo hanno calcolato.
Compatibile con tutto quello che c'è già?
Da profano ecco trovato il meccanismo per tagliare quello che non deve essere visto e ne sentito, e vai con la diretta per il 99% di chi guarda, ascolta e non sa.
Ma no, ogni secondo di programma arriva con un minuto di ritardo.
Ma perché, fanno programmi che durano 1 secondo?
Perché il tempo per fare codifica aumenta di pari passo:
1s programma --> 1m codifica
2s programma --> 2m codifica
1m programma --> 1h codifica
1h programma --> 2,5g codifica
e cosí via.
Quindi va da se che il ritardo di un minuto é valido solo per trasmissioni di 1 secondo e qualsiasi trasmissione deve essere effettuata in differita
Questo lo immagino anche io. Ma da dove discende la seconda affermazione?
Penso sia stato preso in considerazione un ritardo di codifica con HEVC di 1s che in ambiente broadcasting è sostanzialmente "diretta": da questo, valuntando il caso peggiore per JEM, si arriva al citato 1m di tempo per l'elaborazione dei video.
Ovviamente parliamo di prestazioni a parità di HW, ma considera che non si può mica sempre far eil discorso "ci serve più potenza quindi aggiungiamo risorse".
Evidentemente non esiste/non si può implementare un sistema 60 volte più potente degli attuali sistemi che si utilizzano per effettuare l'encoding.
Chi mi spiega la sequenzialità logica tra queste 2 affermazioni?
"Il tempo richiesto per l'encoding è tra le 12 e le 60 volte superiore." e "Questo significa che una trasmissione in diretta con HEVC può essere realizzata quasi istantaneamente, mentre per JEM attualmente si può arrivare ad un minuto in più."
Presumo che con un sistema "tra le 12 e 60 volte" più potente si possa effettuare una trasmissione in diretta.
Se invece il sistema non soddisfa i requisiti occorre necessariamente passare alla differita.
Non riesco a capire in alcun modo come si sia arrivati al dato di "un minuto in più"
Mi fa piacere.
Se cerchi un 55" io vedrei di racimolare qualcosa in più per un XE90 Sony.
Ti consiglio il Samsung MU7000 da 55” a 999€. Se puoi salire a 1199€ c’è l’OLED A7V di LG.
Entro i 1000.
Migliore in senso assoluto? Probabilmente l’OLED top di Panasonic, ma costa un sacco. Che esigenze e budget hai?
Grazie per la risposta.
Ma me la aspetto da Joel, so che è il migliore in questo campo.
Non sono un esperto, ma direi Sony Bravia Oled.
Hai vinto!
So che te ne intendi di TV.
Secondo te quale è la migliore in commercio?
Vedi io la devo cambiare.
Mica male! Peccato per la tempistica di rendering