wenn man sich die Seite zum Plugin mal ansieht, dann kann man recht schnell sehen, dass man nur das runterladen kann was man auch selber empfangen kann.
Also wenn Du selber kein Premiere hast, dann wirst Du auch kein Premiere aus dem p2p bekommen.
Klar gäbe es da Möglichkeiten. Jedoch bin ich strikt dagegen. Wenn wir das hier besprechen, dann wäre es der Todesstoß für ein interessantes Projekt bevor es wirklich gestartet ist.
Also bitte keine Frage oder Anleitungen wie man das Plugin anders benutzen kann.
VDR goes p2p
- Sledge Hammer
- Geschlossen
-
-
-
wie schon einer sagte - dann gibtshalt ein "ghost" plugin, was die aufnahme
halt vorgaukelt, aber halt 99% fehlt.-- randy
-
Bis die Uploadgeschwindigkeiten der DSL allg. auf verwendbares Niveau angehoben werden, ist es vorallem für "Hausgemeinschaften" interessant. Dort wo mehrere isolierte VDR-Rechner in einem 100Mbit Netz zusammen werkeln.
Die Idee zur Nutzung von "fremden" Aufnahmekapzitäten über nicht verwendete DVB-Karte ist hier sicherlich die beste Komponente. Das verteilen der Aufnahme ist allerdings aus meiner Sicht relativ simple wenn man auf bestehende P2P Strukturen (denke da an Bittorent) aufsetzt.
AleX
-
Hat es wer am laufen?
Georg
-
-
-
Zitat
Original von mag128
checking for SHA1 in -lssl... no
configure: error: ssl not foundopenssl-devel?
-- randy
-
small patch
Diff
Alles anzeigen--- node.cc~ 2005-11-30 14:59:43.000000000 +0100 +++ node.cc 2005-12-01 14:20:14.000000000 +0100 @@ -813,7 +813,7 @@ dbg.print(dbg.NODE, 6, "in handlemsg_data_client\n"); ///\todo do some checking // set source - if m->source().empty() + if (m->source().empty()) m->setsource(_myref); // send the message int routeret = route(m);
sonst bekommt man Fehler beim kompilieren node.cc
-
Zitat
Original von free-x
small patch
...sonst bekommt man Fehler beim kompilieren node.cc
Danke, ist eingebaut. Die neue Version kommt zur vollen Stunde auf den Webserver.
Kendy
-
Hi,
Ich bekomm heir auch mit der 0.1.1'Er Igor Version folgende Meldung beim Kompilieren.
Code
Alles anzeigenmake source='libigor.cc' object='libigor.lo' libtool=yes \ depfile='.deps/libigor.Plo' tmpdepfile='.deps/libigor.TPlo' \ depmode=gcc /bin/sh ./depcomp \ /bin/sh ./libtool --mode=compile g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1.1\" -DPACKAGE_STRING=\"igor\ 0.1.1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1 -I. -I. -g -O2 -c -o libigor.lo libigor.cc g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1.1\" "-DPACKAGE_STRING=\"igor 0.1.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1 -I. -I. -g -O2 -c libigor.cc -Wp,-MD,.deps/libigor.TPlo -fPIC -DPIC -o .libs/libigor.o In file included from libigor.cc:35: libigor.h:80: invalid exception specifications libigor.h:82: invalid exception specifications libigor.cc:48: invalid exception specifications libigor.cc:49: invalid exception specifications libigor.cc:56: ANSI C++ forbids data member `connection' with same name as enclosing class libigor.cc:220: confused by earlier errors, bailing out make: *** [libigor.lo] Error 1
[EDIT:]
Achso, der gcc hat die Version 2.95.3 -
Bekomme weiterhin diesen Fehler, auch mit gcc version 3.0.1 (SuSE).
Hat jemand nen Tipp woran das liegen könnte?Code
Alles anzeigensource='libigor.cc' object='libigor.lo' libtool=yes \ depfile='.deps/libigor.Plo' tmpdepfile='.deps/libigor.TPlo' \ depmode=gcc /bin/sh ./depcomp \ /bin/sh ./libtool --mode=compile g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\ "igor\" -DPACKAGE_VERSION=\"0.1\" -DPACKAGE_STRING=\"igor\ 0.1\" -DPACKAGE_BUGRE PORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES _H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE _DLFCN_H=1 -DHAVE_LIBSSL=1 -I. -I. -g -O2 -c -o libigor.lo libigor.cc mkdir .libs g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1\ " "-DPACKAGE_STRING=\"igor 0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -D VERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE _STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYP ES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1 -I. -I. -g -O2 -c libigor.cc -Wp,-MD,.deps/libigor.TPlo -fPIC -DPIC -o .libs/libigo r.o In file included from libigor.cc:35: libigor.h:80: invalid exception specifications libigor.h:82: invalid exception specifications libigor.cc:48: invalid exception specifications libigor.cc:49: invalid exception specifications libigor.cc:56: ANSI C++ forbids data member `connection' with same name as enclo sing class libigor.cc:220: confused by earlier errors, bailing out make: *** [libigor.lo] Error 1
-
Möchte mal wissen, wie die das Problem gelöst haben, dass ich beim Download von einer bestimmten Sendung mehrere Anbieter haben kann. Die Dateien unterscheiden sich doch von Rechner zu Rechner. Je nachdem wie genau die Uhren gehen und wieviel Vorlauf im VDR eingestellt ist, wie der Empfang ist etc. etc.
Die gleichen Probleme musste doch auch damals schon das ShareMarks-Plugin zum Austauschen von Schnittmarken-Positionen lösen (was ist eigentlich daraus geworden?)Cool (bzw. besser) wäre es, wenn die VIDEGOR-Entwickler die Datei GOP-weise zerlegen würden (Vielleicht kann man die Adress-Offsets der GOPs und deren eindeutige ID ja schon beim Aufnehmen in eine Index-Datei abspeichern.)
Die gesharten GOPs kann man dann problemlos zusammenfuegen auch wenn sie von verschiedenen Anwendern kommen.
Wie üblich beim Filesharing hat man dann die zig-fache Bandbreite beim Download wenn man die GOPs nicht nur von einem Rechner holen könnte, sondern von zehn oder gar hunderten von Nutzern. Das Bottleneck weil nur jeweils einer eine bestimmte Sendung uploaden kann wäre damit sehr stark verringert.Ich hoffe jedenfalls, dass es keinen Ärger wegen dieses Plugins geben wird. Schon allein wegen der Arbeit die drinsteckt.
Mir ist noch nicht ganz klar, wie sowas als wissenschaftliche Studie durchgeht. Die Filesharing-Theorie und -Praxis ist doch hinlänglich bekannt und Implementationen gibts genug. Ok, in einer Videorekordersoftware wurde es bisher noch nicht integriert. Vielleicht gings auch mehr um den Teil mit der Timersynchronisation/Verteilung.Gruß
Jarny -
Zitat
Das Videotransport Plugin ermöglicht dieses Nachladen von Aufzeichnungen über das Netz. Dazu werden alle Aufzeichnungen pro Sender in Blöcke von je einer Minute Länge unterteilt. Diese Blöcke werden vom jeweils nächst gelegenen Videgor Rekorder geladen. Dabei werden verschiedene Blöcke typischerweise von verschiedenen Rekordern geladen, um so die Netzwerkbelastung gleichmäßig zu verteilen.
Wenn man sich die technische Doku anschaut, scheint diese Problem gelöst zu sein( Es wird aber nicht abschließend erklärt wie der Zeittakt der Minuten syncronisiert wird. Den Ansatz mit GOPs halte ich für wahrscheinlich) , die Aufnahmen werden in Blöcke von einer Minute aufgeteilt..... Es ist scheinbar richtig P2P, also auch mit Parallelen Downloads.
-
Interesant! Die einzelnen GOPs sind wahrscheinlich zu klein um sie sinnvoll ohne zuviel Verwaltungs-Overhead zu sharen. Deshalb haben die evtl. 120 GOPs ( ~ 1 Minute) zusammengefasst als kleinste Einheit.
Sehr interessantes Projekt.
Gruß
Jarny -
Jedes Stück Sendung wird pro Sender (z.B. ARD) in Blöcke von gut einer Minute zerlegt. Weil die Uhren der Rechner nicht exakt übereinstimmen, sind diese Blöcke unterschiedlich. Jeder Block wird nun in GOPs zerlegt (i.a. 120) zu denen ein Hash berechnet wird. Die Liste der Hash-Werte wird im Peer-to-Peer System veröffentlicht. Dabei wird zu jedem Hash-Block auch eine kurze Liste einiger Rechner angelegt, die diese GOP besitzen (Stichwort Aggregation). Weil die Uhren, wie gesagt, nicht synchron sind, wird dabei auch immer eine Anpassung der Hash-Listen vorgenommen (Stichwort: Matching und Merging). I.a. wird die Hash-Liste also länger. Anhand dieser Listen kann dann die entsprechende Sendeminute geladen werden. Dabei werden mehrere Threads gestartet, die jeweils aufeinanderfolgende GOPs laden. Jeder Thread beginnt mit GOPs die eine Minute Abstand haben. So muss nicht für jede GOP eine neue Verbindung begonnen werden. Hat eine Quelle einen besseren Upstream, ist der Thread früher fertig und kann mit dem nächsten offenen Stück GOPs beginnen. Auf diese Weise mitteln sich die verschiedenen Upstream-Bandbreiten heraus. Im Prinzip könnte aber jede GOP einzeln geladen werden. Wenn z.B. eine Quelle sehr langsam ist, könnte eine andere Quelle für diese GOP gewählt werden. Da aber alle GOPs über die Abfolge der Hash-Werte eindeutig zugeordnet werden können, ergibt sich stets eine identische Kopie des originalen Datenstroms so wie er urpsrünglich gesendet wurde. (Für alle die das jetzt im Quellcode nachvollziehen wollen das kleine Eingeständnis, dass das noch nicht 100% so implementiert ist. Es soll aber in Kürze umgestellt werden.)
-
Willkommen im Forum und danke für die Erleuterungen.
Ich geh mal davon aus, dass du ein Projektmitarbeiter bist. Jedenfalls wünsch ich euch viel Erfolg mit dem Projekt. Ich hoffe ihr habt auch die rechtliche Seite abgeklärt. Würde mich freuen, wenn VIDEGOR populär würde. Ohne Popularität nutzt einem eine Sharing-Plattform nicht viel.
Gruß
Jarny -
Ahh, der Entwicklungschef und der Erfinder von IGOR persönlich...
Herzlich Willkommen auch vion mir :welcome, jetzt ist es mit der Ruhe vorbei... (aber bitte nicht weglaufen)
Da kann ich ja direkt ein paar Fragen loswerden:
Wie werden die Sender Identifiziert (Name ? PID ?)
Welche Ports werden für die Kommunikation genutzt ?
"Pingt" sich jeder Client seinen weg durch die Firewall oder müssen bestimmte Ports bei NAT geforwardet werden ?
Wie funktioniert das erste Finden eines anderen Clients ?
In welcher Größenordnung ist das ganze schon in Betrieb (Wohnheim scheint mir ein gutes High-Speed Testumfeld aber was ist mit DSL ?) ?
Kleiner Tip: Wenn Ihr ein Patch für LINVDR 7.0 erstellt (oder Cody bei der Erstellung helft) wird die Anzahl der Nutzer (Tester) schnell in die 100e gehen....:welcome
-
Ups, so schnell kann ich die vielen Fragen gar nicht beantworten. Ich versuche es mal:
1. Bei den rechtlichen Aspekten gilt wie immer in der Juristerei, es kommt auf den Einzelfall an. Bis zur ersten Abmahnung stehe ich aber auf dem Standpunkt, dass Videgor von Paragraph 44a Urheberrechtsgesetz gedeckt ist. Man kann eben nur das anschauen, was man auch hätte selbst aufnehmen können. Wenn die erste Abmahnung kommt, können wir ja Geld sammeln für einen Musterprozess.
2. Das eigentliche Peer-to-Peer-System ist der IGOR. Beim Starten gibt man einen Bootstrap-Rechner an. Momentan ist das ein Rechner hier bei uns (siehe Installationsanleitung). Das kann aber jeder IGOR Rechner sein, so dass wirklich eng begrenzte Netze entstehen können, z.B. im Wohnheim.
3. Für den IGOR gibt man auch die Ports an, die verwendet werden sollen. Wenn man von außen erreichbar sein will, muss der Netz-Port vom NAT-Gateway an den IGOR-Rechner weitergeleitet werden. Wenn der VDR innerhalb des privaten Netzes läuft muss der Client-Port nicht freigeschaltet werden. Wenn man ein privates IGOR-Netz will, schaltet man den Netz-Port auf der Firewall zu.
4. Die Übertragung der Videodaten ist getrennt von IGOR. Auch dafür müssen NAT und Firewall offen sein. Hier eine gute Lösung zu implementieren ist gerade in Arbeit. Momentan geht's also nur wenn die NAT-Box auch für den Videotransport geöffnet wird.
5. Eine LinVDR-Version wäre prima. Bis dahin wird es aber noch eine ganze Menge Bugs zu finden geben. Auch die NAT-Problematik sollte bis dahin gelöst sein. Wir freuen uns auf jeden Fall über tatkräftige Unterstützung beim Suchen der Bugs!
A propos: Wir haben ein zweites Projekt, das in wenigen Wochen Online gehen wird und das sich mit der Frage der Vernetzung von privaten Subnetzen befasst. Damit kann man dann einzelne W-LAN-Netze verbinden, so dass die Videorekorder gar nicht mehr durch den DSL-Anschluss durch müssen.
-
zu 5.:
ich denke das sich die LinVDR Nutzer auch jetzt schon über ein nicht ganz Bug freies Plugin freuen würden (auch andere Plugins haben noch hier und da ein paar Macken) ;-).
Außerdem würde das die Testergemeine gewalltig vergrößern. (ich würde es testen!)
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!