|
LOGIN |
|
Thread Tools | Search this Thread | Display Modes | Translate |
#1
|
|||
|
|||
Ai più esperti: delucidazioni sul webcasting peer to peerTecnologia Peer to Peer (P2P) applicata alla distribuzione del flusso video:in pratica, la sorgente di streaming inizia a segmentare e fornire il flusso ad un numero limitato di utenti che a loro volta lo ridistribuiscono agli altri che intendono connettersi attraverso un meccanismo di condivisione a cascata.
Bene, avrei alcune domande su tale meccanismo di distribuzione...ditemi, ma tutte le applicazioni iptv di cui si parla nel nostro forum si basano su questo meccanismo di condivisione? Qualcuno di voi ha degli articoli, degli schemi, qualunque cosa riguardi la tecnologia in questione? Non sarebbe interessante approfondire anche questo aspetto più prettamente tecnico dell'iptv in tale forum, soffermandosi magari su vantaggi e svantaggi di una tale tecnologia? Sono nuovo del forum,magari nn ho cercato abbastanza.. Ciao ciao Ste |
#2
|
|||||
|
|||||
Quote:
bravo 8+ pare preso da wikipedia o dal De Mauro. Quote:
Tranne il MediaCenter qui si parla SOLO di P2P streaming. Quote:
Manuali esplicativi ne abbiamo fatti tanti. c'è una sezione apposta. Quote:
se cerchi un posto dove si parla di questo sei arrivato al posto giusto. sebbene a molti utenti interessa solo uno dei vantaggi delle p2pTV (le partite trasmesse dalla Cina e che arrivano fin qui), noi stiamo qui x questo. Volendo fare in breve i vantaggi e svantaggi più evidenti del webTV rispetto al p2ptv: webtv - vantaggi parte più velocemente (ci si collega direttamente alla fonte primaria) fino alla saturazione della banda portante, segnale ingenere stabile svantaggi limitatissimo numero di utenti che possono assistere allo streaming al contrario: P2Ptv - vantaggi in ricezione: la (quasi) certezza di ricevere sempre il segnale, a prescindere dal numero di utenti già connessi. vantaggi in trasmissione: con una banda un upload minima si può riuscire a trasmettere ad una platea soprendentemente ampia: un segnale accettabile si riesce a comporre già attorno ai 200kbs, e oramai gran parte degli utenti hanno una banda di upload (teorica) sui 256kbs... teoricamente diviene distribuito all'infinito. I limiti sono per ora solo sulla qualità dei segnali, giacchè nè il formato WMV nè il più complesso RealVideo hanno un buon segnale a risoluzioni così basse. In SOPCAST (uno dei due principali programmi che permettano lo streaming in uscita) è, con qualche accorgimento, usabile il codec H264, che permette(-rebbe) una qualità ben migliore. Esperimenti di trasmissione di formati AVI (GoCool) sono x il momento fermi. svantaggi il segnale è "affidato" alla banda di uscita dei "telespettatori" e alla loro capacità di restanre buonini. Gli italiani hanno la capacità di fare zapping su tutto. questo interrompe qualsivoglia rete, anche la più potente. Quote:
vedrai che c'è molto da vedere ciao ABN
__________________
«Fino a quando il colore della pelle sarà più importante del colore degli occhi ci sarà sempre la guerra.» Bob Marley |
#3
|
|||
|
|||
[QUOTE=ABNormal]bravo 8+
pare preso da wikipedia o dal De Mauro. No, dal sito di streamerone! |
#4
|
|||
|
|||
|
#5
|
|||
|
|||
Quote:
Ok...ottimo. Altro? Io nn ho trovato moltissimo in giro a dire il vero. Il concetto è sempre quello, pure io, che vado cercando? Comunque mi piacerebbe avere altro materiale, vi ringrazio e vi saluto, ciaociao, Stefania |
#6
|
|||
|
|||
Quote:
Interessantissimo quanto hai detto, Abnormal. Purtroppo non sono un esperto di tecnologia P2P, e sopratutto non so se si tratta di software aperto, ma a livello di logica avrei un paio di ideuzze per risolvere parzialmente gli svantaggi (e se fossero buone e fattibili perchè non proporle a StreamerOne?) 1. Problemi di qualità/definizione. Perchè non streammare ANCHE a bitrate superiore (almeno 1000 Kbps), escludendo dalla catena P2P chi non ha Upload sufficiente (test automatico di UL prima di consenso a connessione)? In questo modo almeno chi ha banda può goderne, e chi non na ha a sufficienza si connette comunque su canali a minor definizione (vedi esempio CCTV5 che trasmette anche ad 800Kbps). Se poi fosse utilizzabile la codifica H264 ancora meglio per tutti!... 2. Problemi di interruzione catena per zapping. Perchè non attivare, per ogni postazione P2P, stream di output sul canale che ne ha più bisogno (quello con banda più penalizzata), indipendentemente dal canale ricevuto per la visione? In questo modo si può zap...pare in modo indolore, perchè la ritrasmissione non viene interrotta. E' chiaro che il software dovrebbe essere implementato in modo da ricevere due canali, di cui uno per la visione e l'altro per la ritrasmissione, per cui la richiesta di banda utente risulterebbe pressochè raddoppiata in DL ed inalterata in UL; ma come ben si sa la carenza generale (ADSL) è in banda di UL, mentre sono molto più elevati i valori di DL, per cui si andrebbe a sfuttare banda di DL comunque disponibile e sottoutilizzata!... Ditemi cosa ne pensate. Se qualcuno di voi ha motivo di ritenere che non ho detto cazzate, sarebbe da spingere la cosa... rispondete se sapete... |
#7
|
|||
|
|||
Quote:
Premetto che non sono un esperto neanche io, però così ad occhio ho qualche perplessità sul secondo punto o forse non ho capito bene. Tu dici in buona sostanza di "deviare" la banda in upload libera che ognuno ha per "sostenere" il canale messo peggio. Il problema è che col passare del tempo, il canale messo peggio potrebbe cambiare (cioè invece di essere X diventa Y) quindi ci sarebbero degli spostamenti da un canale all'altro (per sostenere Y) generendo in pratica lo stesso problema dello zapping. Last edited by sgt. pepper : 03-17-2006 at 04:30 PM. |
#8
|
|||
|
|||
Quote:
Ho scritto di getto in un momento di allucinazione tecnologica. Ora che non sono più in trans mi spiego meglio, comunque rivedendo l'idea mi pare tutto OK. Non si tratta di deviare banda UL ma di utilizzarla per due funzioni. Il tutto si comporta come se ci fossero due programmi in funzione, uno P2P, per avventura sincronizzato su un canale X a bassa disponibilità di banda totale, che tieni attivo ma di cui non ti interessa la visione, che è disattivata, ed uno normalissimo di ricezione (ad esempio un VLC o chi per lui) che tieni in piedi per la visione, sintonizzato sull'URL del canale Y da te scelto per la visione, che per avventura potrebbe essere trasmessa con tecnologia P2P dallo stesso BroadCaster di cui stai streammando il canale X. Poichè canale X non ti tinteressa per la visione, lo lasci così, al servizio altrui, e l'eventuale zapping lo fai su Y che diventerà Y1, Y2, Y3, senza intaccare la ritrasmissione di X, che nessuno sposta. In definitiva, a livello di software, basta agire sulla versione Client, quella che ogni postazione P2P utilizza, lasciando fortunatamente inalteraro il software del Server BroadCasting (emittente delle trasmissioni). Il P2P cliente dovrebbe essere un "doppio P2P": una sezione è un P2P tradizionale senza la parte che ripete in streaming output il segnale d'ingresso (a questo punto equivale ad uno Stream Player in grado di supportare protocollo P2P utilizzato); l'altra sezione è lo stesso tipo di P2P tradizionale, al quale è stata (non necessariamente) tolta l'uscita su Player, che anzichè ricevere il canale scelto dall'utente, lo sceglie lui in base alle necessità di banda dello stesso al momento, e su quello resta (perchè vorresti farlo zap...pare in automatico? tanto i prossimi utenti che si collegheranno riequilibreranno le cose andando a selezionare il canale al momento svantaggiato). Le due sezioni lavorano chiaramente in contemporanea. Aggiungerei che questa seconda sezione magari sceglierebbe il canale da ripetere in stream anche in funzione della capacità di UL del Client, cercando tra i canali che la sua banda di UL può soddisfare; se non ne trova non lo connette (un utente con UL inferiore alla media crea solo un danno), pur continuando la prima seaione a ricevere (se il client ha poca banda ed ha scelto un canale veloce, fatti suoi, vedrà male, ma non compromette la catena di straming). Bah, mi sembra che non ho farneticato male, ai posteri l'ardua sentenza. Ciao PS: Ho farneticato male (parzialmente), ma forse ho la soluzione; mando in onda questo post poi ne aggiungo un altro, per ora ciao. |
#9
|
|||
|
|||
Aspetto il tuo nuovo post però così ad occhio avresti il problema su Y. Io ho capito che tu intendi:
1) X lo ricevi, lo uploadi ma non lo vedi perchè non ti interessa 2) Y lo ricevi, lo vedi perchè ti interessa ma non lo uploadi (parli di Streamer Player) A questo punto, Y come fa a stare su se tutti i client facessero così? Last edited by sgt. pepper : 03-17-2006 at 05:54 PM. |
#10
|
|||
|
|||
Quote:
Mo ti dico l'arcano: quello che per me è Y per altri è magari X. Comunque, con i bilanciamenti che avvengono nel tempo che ti ho accennato, ognuno degli n. canali di quel BroadCaster tende ad avere un Througput, ossia un flusso complessivo di streaming, statisticamente bilanciato: gli u. utenti che si guardano indisturbati gli n. canali inconsapevolmente sostengono proprio quegli n. canali, ognuno streammando quello che al momento della sua connessione era il più meritorio, ma siccome la candidatura dei più bisognosi tu stesso mi dici che varia nel tempo, alla fine tutto si equilibra. Ti anticipo il vero problema nell'errore di farneticazione: lo zapping purtrppo non avviene tento tra i vari canali di uno stesso sistema di BrodCasting ma spesso tra sistemi (NetWork) eterogenei (quanto eteregonei è il busillis), segue Post |
Thread Tools | Search this Thread |
Display Modes | |
|
|