[sgt. pepper]

Originally Posted by rockroll

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

Scusami, non sono ancora convinto. La tua idea funziona in un sistema ideale ma all'atto pratico (cioè durante una partita) ci sono due o tre canali (es. X-Y-Z) che hanno un numero di utenti molto superiori rispetto agli altri. Se su questi canali si inizia a fare zapping cioè gente che entra ed esce, nel tuo sistema bisogna che ci sia altrettanta gente o cmq parecchia gente che non stia guardando quei canali ma che sostenza X-Y-Z e questo di solito non succede mai.

[rockroll]

Allora (ma mano che parliamo si affinano le idee), vediamo il problema "zapping eterogenei infraNetWork", e come risolverlo.

S1, S2, S3, ... Sn sono collegati su Sopcoast, P1, P2, ... Pn, su PPlive, O1, O2 ..., On su StreamerOne, e potrei così continuare.
Nessun proplema se ognuno zap...pa nell'ambito del suo sistema, chiamiamolo di NetWork, cioè se un Sa divente un Sb o un Oc diventa un Od), ma se uno zompa da un sistema all'altro, magari disconnettendo (uccidendone il Task) il sistema che abbandona (cioè se un Pf ad esempio diventa un Og e nel far questo uccide il Task che ristreammava un flusso Px che il sistema, PPlive nel caso, gli aveva assegnato come meritorio)? - Tutte le mie belle teorie salva zap andrebbero a put...tane? Temo di si, a meno che.... segue post

[rockroll]

Originally Posted by sgt. pepper

Scusami, non sono ancora convinto. La tua idea funziona in un sistema ideale ma all'atto pratico (cioè durante una partita) ci sono due o tre canali (es. X-Y-Z) che hanno un numero di utenti molto superiori rispetto agli altri. Se su questi canali si inizia a fare zapping cioè gente che entra ed esce, nel tuo sistema bisogna che ci sia altrettanta gente o cmq parecchia gente che non stia guardando quei canali ma che sostenza X-Y-Z e questo di solito non succede mai.

Esaminiamo cosa dici (ho interrotto i problemi di zapping infrasistemi per risponderti)

Funziona!
La gente che entra e che esce non entra ed esce dalla catena di Streaming, ma unicamente cambia indirizzo URL di lettura della sezione Stream Player); la sezione Stream Resending (ritrasmissione, chiamiamola così), continua a rimandare lo stesso canale assegantole in partenza come meritorio di streaming. La ricezione, anche zap...pata, è totalmente indipendente dalla ritrasmissione, che resta stabile. Sei convinto, dai, dimmi di si...

[rockroll]

Anzi, ti dirò di più: la troppa gente che guarda i pochi canali supergettonati rende questi più candidabili alla ritrasmissione perchè più bisognosi di banda, e tutto si riequilibra. Il trucco è proprio quello di far scegliere adeguatamente all'automatismo il canale più bisognoso di sostentamento. I supergettonati acquisiscono servizio banda in modo privilegiato. Vado a riprendere Post Salti InfraNetWork:

[rockroll]

Purtoppo devo uscire, ma questa discussione è troppo interessante (ed innovativa) per essere abbandonata. Accenno solo una mezza idea da affinare per evitare cadute di catena P2P dovuta a Zappin tra sistemi eterogenei.

Premesso che non so quanto i Broadcaster cinesi siano eteregenei tra di loro, e magari non lo sono per niente, sicuramente è eterogeneo StramerOne rispetto ai P2P cinesi. Dico ciò perchè se i vari sistemi P2P cinesi sono omogenei, nel senso che sono supportati dallo stesso protocollo di trasmissione, potremmo al limite costruire un supermonitor conglobante tutti i vari PPlive, QQlive, PPstream, TVKoo e via dicendo in modo da essere visti come un unico BroadCaster dentro il quale si può zap...pare senze uccidere alcun task di Resending, ma questo mi pare già fantascientifico... molto più terra terra è invece impedire l'uccisione (disconnessione) di un task di Resending almeno per un certo periodo di tempo, in modo da scoraggiare l'utente a farlo volontariamente ...

Devo affinare l'idea, al momento non mi soddisfa abbastanza ora ... devo uscire. Ciao

[ABNormal]

credo che qui ci sia roba che possa interessare:

http://vtt.vatata.com/v/node/24

[rockroll]

Originally Posted by ABNormal

credo che qui ci sia roba che possa interessare:

http://vtt.vatata.com/v/node/24

Avevo lasciato perdere la discussione perchè non vedevo risposte o contributi alla mie pensate notturne. Cercavo critiche costruttive ma non ce n'erano più.
Mi sono anche reso conto che senza conoscere il meccanismo di acquisizione nodi per ridistribuzione del segnale, e soprattutto il sistema diciamo di "parzializzazione" dello stesso a fronte di utenti a valle con minor banda DL o di utenti a monte con maggior banda UL, avrei continuato a fare congetture inapplicapili o del tutto false.

Ho visto la tua indicazione e vado a documentarmi.

Nel frattempo però, come corollario banale della mia "idea", qualcosa penso si possa fare da subito, partendo dalla considerazione pratica che l'esigenza di zapping si ha inizialmente, primo dell0inizio dell0evento stesso, quando si cerca di verificare se riusciamo ad accedere decentemente allo stesso (o anche altro) evento da un canale di un network piuttosto che da un altro canale di un altro network (metti caso Juve-Canicattì è prevista su CCTV5 di PPlive ed anche su Guandong di SopCast).
La mia proposta è quella di fare zapping solo in ricezione, evitando di emettere stream che crerebbero catene a valle che poi sarebbero interrotte cambiando canale.
Una volta stabilito, mediante zapping in sola lettura, su quale canale di quale network vogliamo posizionarci, ripartiamo utilizzando il sistema standard P2P (quello che fa da ponte al flusso streammato), e restando d'obbligo su quel canale/programma fino alla fine dell'evento.
Purtroppo non conosco bene il meccanismo, ma per trasformare un programma P2P in un banale Player penso basti bloccare, ad esempio con Firewall, le porte di uscita dello stream, se non esistono altri sistemi, piuttosto che modificare il programma stesso per evitare il flusso di output.
Credo che utilizzare sorgenti P2P da Media Center non risolva, perchè questo sistema aggancia il P2P standard e non una versione "solo input".

Se quel che ho detto è tutto giusto, basta porre in evidenza delle regole comportamentali... ed il problema dello zapping è praticamente risolto, senza penalizzare l'utente "zappante" ne' quello "zappato" (= a valle), semplicemente perchè costui ancora non esisterebbe.

Ripeto la lezione di comportamento: l'utente bloccherebbe le porte output interessate ai programmi P2P che intende usare, quindi farebbe zapping a piacere. Uno volta scelto il canale buono, basta sbloccare le porte interessate, e poi godersi l'evento.... ma guai a staccarsi fino all fine!

Visto che siamo in argomento, delucidatemi: io sono FastWeb Fibra, pertanto ricevo a meraviglia gli stream P2P, anzi più sono di elevato BitRate e più godo..., e sopratutto ho banda a volontà in DL per servire altrettanti utenti a valle del mio nodo; ma se è vero che all'esterno di FW non sono visibile (secondo me a volte lo sono), tutto il ben di Dio che emetterei sarebbe appannaggio dei soli utenti Fw, o addirittura dei soli FW Fibra? Come stanno le cose? Non è che la mia potenza è praticamente inutilizzata dai poveri ADSL perchè, ammesso che mi "vedano", sono troppo lenti per avere priorità di aggancio al mio nodo, e lo beccherebbero proprio se nessun altro più veloce (quindi Fibra) gli si frapponga?

Io cerco di essere utile agli altri, se non mi è possibile me ne dispiace.

Attendo risposte e sopratutto critiche costruttive, ciaooooo

[rockroll]

Nessuno mi risponde?

[ABNormal]

io credo che una preview sia irrealizzabile per semplici motivi di saturazione del segnale.
il p2p è un equilibrio tra dati IN e dati OUT che ognuno degli utenti crea e preleva. Se 100 sharers (utenti collegati tradizionalmente) lasciano pronto un segnale per altri 100 e metà di questa banda viene succhiata per le preview io credo che il segnale si esaurirebbe a breve.
Forse si può immaginare una preview "a scatti": i 25 frames al secondo che compongono un'immagine potrebbero essere suddivisi tra 12 "zappatori" (quelli che fanno zapping) in modo da ricevere due fotogrammi al secondo, più che sufficente per avere un'idea di cosa trasmetta il canale.
Addirittura potrebbe essere previsto, ad inizio della connessione una prima fase di qualche secondo a scatti programmati e, dopo cinque secondi dal collegamento un aggangio alla rete vero e proprio in forma di p2p. in questo modo lo zapping è garantito in forma poco traumatica per chi è in visione stabile (in fondo lo zappatore preleva una porzione irrilevante di segnale) e la connessione è automatizzata per chi resta connesso a quel segnale.
credo che la cosa non sia così semplice, avendo visto che tvkoo, che pure ad una "preview" fotografica ha pensato, ha grossi problemi a mostrare anche il singolo fotogramma.

[staff]

guarda qui anche:
http://www.coolstreaming.us/forum/showthread.php?t=8250