Nuovi iMac 24" con Core 2 Duo e upgrade MacMini

[charger2000]

...

ma infatti la mia curiosita', e credo anche quella di PynkyZ, era legata all'argomento, molto attuale, della decodifca dei flussi DVB-S2 H.264/AVC, ma non essendoci una scheda Mac, per il PC c'e' ora la Technotrend S2-3200, questa disquisizione e' puramente accademica...

[Girmi]

…, se posso usare un Celeron 533 ( ) per creare (encoding) un file Divx in H.264 ed impiegarci 10 ore invece delle 2 ore che ci vorrebbero con un P4 attuale, un Celeron 533 non riuscirebbe MAI a decodificare in tempo reale un flusso H.264, si avrebbe a malapena 1fps ..., …

Ehm…, io parlavo di acquisizione e conseguente compressione in RT (RealTime), non di postprocessing.

Sul nonnetto "G4" dotato di giurassica ATI 8500, un PAL in H.264 va a 25fps tranquillamente e il postprocessing, ad esempio da DV a H.264, lo fa ca. in 1:1 (parlando sempre di PAL).

…, in ambito PC …

solito discorso, l'H.264 è una bestia nera per i PC, un agnellino per i Mac

Ciao.

[PynkyZ]

C'è una scheda USB2 anche, però non so se ci siano driver per Mac.

La (grande) differenza fra Pull e Push, detta in soldoni eh, e che nel primo caso è il decodificatore (che sia HW, che sia SW) che guida e comanda il flusso dei dati (di cui dispone già dall'inizio l'intera struttura, e quindi può anche permettersi di saltare da un punto all'altro del flusso senza problemi) e quindi ottimizza quest'ultimo secondo i propri bisogni (se è fatto bene), con la possibilità di bufferizzare al meglio, temporizzare le varie componenti audio/video/altro come meglio crede, rileggere una data sequenza se c'è qualcosa che non gli risulta corretto etc, nel secondo caso il flusso dati è assolutamente non controllabile da parte del decodificatore che quindi deve riuscire a elaborare tutti i dati "as they come, on the fly" senza possibilità di metterli in coda: se quindi c'è un picco (ed è abbastanza normale ci sia), è facilissimo che il decodificatore s'ingolfi e cominci a droppare pacchetti dati per riuscire a rimanere in real-time, ma anche senza picchi il carico elaborativo è chiaramente molto maggiore...

[PynkyZ]

Ehm…, io parlavo di acquisizione e conseguente compressione in RT (RealTime), non di postprocessing.

Sul nonnetto "G4" dotato di giurassica ATI 8500, un PAL in H.264 va a 25fps tranquillamente e il postprocessing, ad esempio da DV a H.264, lo fa ca. in 1:1 (parlando sempre di PAL).

solito discorso, l'H.264 è una bestia nera per i PC, un agnellino per i Mac

Ciao.

Pal HD? E non ottimizzati Quicktime/Apple? Quelli di Apple li faccio girare anche io su un computer senza ausilio scheda grafica (intendo accelerazione Hardware): usano il profilo H.264 meno impegnativo...

[pacchio]

un conto e' avere dei files gia' belli e pronti sull'hd da riprodurre , come dei MOV codificati in H.264, un conto e' la riproduzione di un flusso MPEG4 ricevuto tramite scheda satellitare

Mi sfugge perché un flusso compresso proveniente da satellite sia più pesante da decomprimere e visualizzare che uno letto dall'hd?

ciao
Pacchio

[charger2000]

Mi sfugge perché un flusso compresso proveniente da satellite sia più pesante da decomprimere e visualizzare che uno letto dall'hd?

ciao
Pacchio

non ho le prove, ma si sembrerebbe che sia cosi', le SVGA di ultima generazione aiutano parecchio i PC che vogliono ricevere i flussi DVB-S2, mentre non sono cosi' necessarie in fase di riproduzione

[PynkyZ]

Perché pacchio, leggere file da PC è un sistema pull dei dati, mettere in chiaro in realtime un flusso video da satellite invece è un sistema push.

[PynkyZ]

Esempio banale e neanche del tutto corretto, ma che può dare un'idea:
Sistema Pull: sapete come si fanno (insaccano) le salsicce no? La carne già preparata, messa in contenitore, attaccato a una specie di macinatore che ha l'uscita a becco su cui è infilato il budello: giri la manovella (mettiamo che sia una macchina vecchio tipo a manovella), la macchina tira dentro man mano la carne, la fa passare per il becco e la fa uscire, quantità costante, dentro il budello che si riempie quindi costantemente.
Sistema Push: hai un pallone da basket, e c'è una fessura su un muro del diametro di una palla da tennis: devi spingere il pallone da basket dall'altra parte attraverso la fessura. E no, non puoi sgonfiare il pallone...
Quale sistema richiede più forza bruta?

[pacchio]

Perché pacchio, leggere file da PC è un sistema pull dei dati, mettere in chiaro in realtime un flusso video da satellite invece è un sistema push.

Scusa ma sono di coccio.
Facciamo conto che sia l'hd che la scheda sat siano collegate al Mac in firewire.

La scheda sat riceve un flusso compresso e lo manda al processore che lo decodifica, il tutto poi arriva alla scheda grafica per la visualizzazione.

Lo stesso avviene se la fonte e l'hd, visto che i dati vanno comunque decompressi dal processore, e la scheda grafica fa lo stesso lavoro che nell'ipotesi precedente.

Dove sbaglio?

ciao
Pacchio

[PynkyZ]

Sbagli sul come arrivano i dati, e quindi su come vengono processati. Nel primo caso deve fare tutto on-the-fly senza la benché minima intercezza (senza sapere bitrate, quantita di dati in arrivo, complessità dei pacchetti dati, stato degli stessi), nel secondo caso no (i dati sono già tutti presenti in locale, e c'è una lettura costante dei dati). Un film, letto in locale, ha un throughoutput costante (anche se magari le scene del film stesso hanno un bitrate che varie, com'è ovvio), decodificato da satellite on-the-fly no.

[pacchio]

Sbagli sul come arrivano i dati, e quindi su come vengono processati.

Ok, allora spiegami tecnicamente, perché l'esempio che mi hai fatto non mi dice nulla.

ciao
Pacchio

[ciuchino]

Secondo me' se il flusso e' in chiaro cambia poco che venga da satellite o HD , non e' esattamente la stessa cosa ma l'impegno in piu' e' limitato.
Diverso il discorso se e' necessario decriptarlo.

Ciao
Antonio

[PynkyZ]

E invece no ciuchino: è stato fatto un esperimento.
Flusso HD H.264 da satellite: nel primo caso, visto live (mettiamo con Dvbviewer): non perfetto, stuttering frequente. Nel secondo caso, stesso canale H.264 HD satellitare, con Dvbviewer che salva il flusso in un file formato TS, e contemporaneamente un lettore di file .TS che apre quel file: visione pressoché perfetta senza stuttering. Stesso filmato trasmesso dal canale, stesso HW, stessi codec, solo che nel primo caso il flusso è in modalità Push, il secondo in modalità Pull. Ovvero non è la potenza totale del sistema il problema, ma il modo in cui i dati devono essere elaborati (in realtime/non in realtime). Puoi provarci anche tu se vuoi

[ciuchino]

Stiamo parlando di sistemi funzionanti ... uno che stuttera non lo e' .
Online e' piu' complicato ottimizzare il flusso ma se lo splitter principale lavora a dovere ed i decoder anche si parla di pochi punti percentuali di differenza.
Pensavo ti riferissi al consumo CPU , se faccio quella prova consumo di piu' .
Mi accorgo che stiamo andando off topic ... sorry al limite ne parliamo altrove.

Ciao
Antonio

[Girmi]

Pal HD?
… usano il profilo H.264 meno impegnativo...

Chi ha mai parlato di PAL HD?
Io parlo di PAL.
Quanto al flusso H.264 dei trailer Apple hai ragione, ma se leggi i link che ho messo alla mia prova sul vecchio MacMini o se leggi questa che fatto sul mio MacBook vedrai che i file che uso io sono FullHD "autoprodotti" con rate da 60 Mb o size a 2.5Kpx , il doppio della FullHD

Ciao.