Nuovi iMac 24" con Core 2 Duo e upgrade MacMini

[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.

 

[Girmi]

Esempio banale e neanche del tutto corretto, ma che può dare un'idea:
Sistema Pull: …
Sistema Push: …
Quale sistema richiede più forza bruta?

Quindi quale sistema più push-pull di quello che ho detto io realtivamente all'acquisizione di PAL analogico non compresso (ca. 25 MB/s di flusso dati) e compresso in realtime in H.264 (ca. 8 Mb/sec)?

Ciao.

 

[Girmi]

Mi accorgo che stiamo andando off topic ... sorry al limite ne parliamo altrove.

Grazie della sensbilità Antonio.

Qui dobbiamo solo adorare e glorificare la superba bellezza delle nuove opere di mamma Apple :ave: :ave: :ave:


(cavolo, mi sto Sasadfizzando )

Ciao.

 

[Girmi]

…(senza sapere bitrate, quantita di dati in arrivo, complessità dei pacchetti dati, stato degli stessi), …

Rileggo solo ora.
Sinceramente non sono un profondo conoscitore di trasmissioni sat, tutt'altro, ma per quanto ne so, sono pur sempre trasmissioni di dati "pacchettizzate" (mi si perdoni il termine, magari improprio) in cui ogni pacchetto ha un suo header che ne descrive il contenuto.
La sola differenza, rispetto ad altri tipi di trasmissione è di essere unidirezionali. Cosa che rende impossibile all'emittente conoscere il buon esito dell'invio dei dati effettuato e che necessita di qualche sistema di correzzione o cancellazione dei pacchetti corrotti da parte del ricevente.

Probabilmente è questa l'unica differenza significativa fra la ricezione di segnali e la lettura da disco, dove un pacchetto "errato" viene semplicemente riletto.

I due sistemi possono anche dare differenze di visione notevoli, dato che la cancellazione di alcuni dati dal flusso può generare artefatti e/o approssimazioni assenti nella lettura da HD, ma come dice bene Ciuchino, tutto questo comporto un maggior impiego di CPU molto limitato.


Ciao.


p.s.:

(in realtime/non in realtime).

Parlando di sistemi video, il contrario di Realtime è Offline

 

[lucalazio]

Sì vabbè ma strigni, strigni (come se dice a Roma) quale Mac potrebbe andar bene per Media Center?
A quanto pare il Mini base non è niente male con il proce aggiornato ma gli manca il DVD-R (la Apple su questa cosa è ridicola ) ma se si passa all'altro a 800 euro ci si avvicina pericolosamente all' Imac da 1200 perchè con 400 euro hai il proce Core 2 Duo eek: ) a 2 Ghz, il video da 17", 512 Mb di RAM in più, il doppio del disco e una scheda grafica decente.
Insomma si parte da 619 euro e tra un ragionamento ed un altro si arriva al doppio.........
E poi ci sarebbero i portatili che alla mancanza di alcune cose come il Mini ed al prezzo più alto come l'Imac rispondono con la loro bellezza e compattezza.......e poi te lo porti dove vuoi!!!!!
Mi sa che sono indeciso
E voi cosa decidereste?
Ciao, Luca.

 

[Girmi]

quale Mac potrebbe andar bene per Media Center?

Penso dipenda da cosa ci si vuole fare.
Per la visione di DVD, la musica, le foto e contenuti online può bastare il Mini base.
La mancanza del masterizzatore DVD è una rottura, ma con un centinaio di euri si prende un DVD-R (ovviamente in stile), con il quale puoi anche fare duplicazioni in Real Time.

Però concordo che l'iMac 17" da € 1.200 è probabilmente quello col miglio rapporto prezzo/prestazioni.

Potendo pilotare un display esterno, io lo vedo anche molto utile per chi ha un proiettore, che può essere noioso dover accende solo per selezionare un brano da iTunes o prepare lo slide show delle vacanze con iPhoto, da far veder poi la sera agli amici.

Inoltre la scheda grafica è indisplensabile se uno vuol fare anche giochi 3D decentemente. La GMA 950 è ottimitazzata perle prestazioni video, ma nel gaming spinto è na' ciofeca.

Quanto al discorso dei portatili leggi il thread sul MacBook.
Considera perà che anche i MacBook hanno la GMA 950. Per avere la X1600 bisogna passare al MacBook Pro e sei ai costi del 24".

Insomma portatili come HTPC?
Solo se serve un portatile da usare, ogni tanto, anche come HTPC.

Ciao.

 

[PynkyZ]

Questo viene dal forum di Dvbviewer, dal coder di Dvbviewer GE:
"If data is coming too quickly the Cyberlink (nb. il codec per H.264) gets into trouble with its buffer management, and it will start to drop data sooner or later (it does here on my AMD 64 3200+ PC). Maybe your PC is just a bit too slow, or just at certain moments. It's not so critical in case of file playback, since the data is pulled from a "very large buffer" (the file on your hard disk ) on demand.
In case of push mode live playback the data has to be processed when it comes. And if the buffers are not able to absorb surplus data, the whole thing may profoundly get out of rythm. "Pull" and "push" are very different modes of operation, with different requirements.
...
I wouldn't assume buffering problems in general. All software components that use buffering may get into trouble if the PC is working close to its limits, particularly in the "push" mode of operation. Time critcal processes are likely to cease to work properly on 95% CPU load. Live playback is time critical, file playback is not... that's what I wanted to explain".

 

[ciuchino]

Quindi il problema sono i Cyberlink.
Ma se chiedi a Cyberlink il problema e' di DVBviewer.

Il problema e' far lavorare un PC al 95% di consumo CPU ... punto piu' punto meno li' fa' parecchia differenza.

 

[Girmi]

Quindi gli eventuali problemi di push-pull altro non sono se non i problemi del buffer del cazzillo che presiede la ricezione?
Allora il problema è del cazzillo progettato male non del Mac o del PC che lo usa.

Ad ogni modo, da quanto leggo, le prestazioni degli AMD 64 3200+ sono imparagonabili a quelle dei Core 2 Duo, quindi…problema risolto

Ciao.

 

[PynkyZ]

Quindi il problema sono i Cyberlink.
Ma se chiedi a Cyberlink il problema e' di DVBviewer.

Il problema e' far lavorare un PC al 95% di consumo CPU ... punto piu' punto meno li' fa' parecchia differenza.

Leggi la seconda parte che inizia "I wouldn't assume buffering problems in general...". Quando dice "..All software components that use buffering may get into trouble if the PC is working close to its limits, particularly in the "push" mode of operation" non parla di Cyberlink in specifico, ma parla di qualsiasi componente software (di chichessia) che quando è in push mode, entra in crisi nel management del buffering quando è quasi al massimo del consumo risorse. Questo non è il caso nei sistemi pull, che anche se stanno al 95% del consumo risorse, non vanno incontro a questi problemi: perchè? Perché il push mode (in questo caso, ma in tutti i casi simili) è un sistema che deve per forza funzionare in realtime (per chi usa PC con sistemi WinXP o simili, credo che sappia cosa significhi settare il thread di un programma su "realtime" invece che su "normal": il consumo risorse schizza in alto, nonostante il programma sia lo stesso e faccia la stessa cosa) perché l'utente finale deve poter vedere e sentire il flusso il prima possibile susseguentemente la ricezione (vi ricordate le lamentele durante i Mondiali perché Sky HD "arrivava" 3 secondi dopo l'analogico terrestre? Ecco, questo è quello che qualsiasi programma DVB vuole evitare (il timeshifting dev'essere una scelta, non imposto per design architetturale del programma, no?), per evitare ciò deve funzionare in modalità push). In modalità pull, come dice Griga, è come se ci fosse il buffer completo sempre disponibile dell'intero flusso: ecco perché si può iniziare al punto che si preferisce, mettere in pausa, andare a doppia velocità: non è time-critical, ovvero il fattore "qui e subito" non sussiste in questo caso. Con trasmissioni satellitari invece ogni momento è "qui e subito" (tranne se si sceglie di timeshiftare, chiaramente).

 

[ciuchino]

Pynkyz le prove le ho fatte e la differenza di consumo CPU e' irrisoria tra online/offline.
Ho capito che la gestione e' diversa e che quella online e' piu' problematica.
Ma non e' neanche vero che la gestione offline non sia senza problemi , ci sono anche li' buffer e latency.
Nel grafico c'e' sempre chi detta i tempi per tenere sincronizzato audio e video ... basta vedere dove sta' il clock di riferimento.
Guarda caso c'e' qualcosa che si chiama quartz.dll.