Visualizzazione Stampabile
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)?Citazione:
Originariamente scritto da PynkyZ
Ciao.
Grazie della sensbilità Antonio.Citazione:
Originariamente scritto da ciuchino
Qui dobbiamo solo adorare e glorificare la superba bellezza delle nuove opere di mamma Apple :ave: :ave: :ave:
(cavolo, mi sto Sasadfizzando :eek: )
Ciao.
Rileggo solo ora.Citazione:
Originariamente scritto da PynkyZ
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.:Parlando di sistemi video, il contrario di Realtime è Offline ;)Citazione:
(in realtime/non in realtime).
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.
Penso dipenda da cosa ci si vuole fare.Citazione:
Originariamente scritto da lucalazio
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.
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".
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.
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.
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).Citazione:
Originariamente scritto da 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.
Non ho detto che sia senza problemi, ma di certo è meno problematica. E poi non si parla di differenza di consumo totale, ma di realtime o meno: come si diceva, al 95% del consumo, un sistema push (realtime-time critical) comincia ad andare in crisi, un sistema pull no. La differenza fra vedere direttamente in Dvbviewer "live" e far creare a Dvbviewer un TS da aprire con un altro programma contemporaneamente non sta nel consumo, ma nel fatto che è molto facile che nel primo caso si abbiano stuttering e pixel/frame persi (tanto più facile quanto si sia vicini al limite delle capacità HW della macchina), nel secondo caso no (anche se si è cmq vicini ai limiti HW). Solo che nel primo caso hai una visione live realtime, il secondo è cmq paragonabile a un timeshift, non time critical quindi.
Scusami ma se non ho problemi a vedere in live perche' me li devi creare :D ;)
Citazione:
Originariamente scritto da PynkyZ
Ragazzi scusate,Citazione:
Originariamente scritto da ciuchino
colpa mia che riattivato l'OT, ma dato che per ora l'argomento non riguarda il Mac la si potrebbe chiudere qui.
Però l'argomento è interessante ed è probabile che molti HTPCisti potrebbero contribuire.
Forse merita di non essere lasciato cadere ma di un topic a sè.
Ciao.