Frage von Matthias Degenkolb:Hallo zusammen,
Ich bitte alle Wissenden um kurze Hilfestellung zum Thema Linux und DVB-T.
Mein Linuxserver (; ~ 466 MHz, 256 MB RAM, Debian Sarge ) soll mit einer
DVB-T Karte erweitert werden, so dass Sendungen entweder
- auf lokaler Platte mitgeschnitten werden können
- als Stream ins lokale Ethernet wandern, um dort von
einem/mehreren(;Multicast?) Clients empfangen
werden zu können. - (;lokales Fernsehen am System selbst muss NICHT
möglich sein)
Zu diesem Vorhaben stellen sich mir mehrere Fragen:
- Gibt es Lösungen(;PCI-Karten) mit Hardwaredecodierung? Wenn ja: Zu
welchem Preis ?
Soweit ich weiss, senden die Budgetkarten ein komprimiertes MPEG2-Signal
aus, das dann von der CPU decodiert werden muss um dann als MPEG2-Stream
auf Platte zu landen oder nochmals dekomprimiert im Mediaplayer zu
landen. Wenn dem so ist: Gibt es DVB-T Karten bei denen die erste
Dekomimierung onboard geschieht bzw Videoschnittkarten, die die CPU
dabei entlasten? (;Der Server hat noch anderes zu tun ;-)
- Welche Software eignet sich?
Ich bin bis jetzt auf MythTV als ziemlich komplettes Mediacenter
gestoßen. Gibt es was besseres? Kann man in MythTv
Infrarotfernbedienungen (;Lirc) zum Umschalten nutzen?
- Wie schauts mit dem Empfang aus?
Ich wohne im ersten Stock eines Mehrfamilienhauses und habe keinen
Zugang zum Dach und keine Chance auf eine Außenantenne. Dem
entsprechend muss eine Zimmerantenne mit Verstärker genügen. Ist dies
ausreichend?
- Zum Thema Stream im Ethernet: Wieviel Traffic fällt an?
Ich nutze 100MBps LAN und 54 MBit WLAN. Reicht das in der Praxis an
Bandbreite?
Ich bitte die vielen grundlegenden Fragen zu entschuldigen, aber selbst
nach stundenlanger Recherche im Netz habe ich keine eindeutigen und
stimmigen Aussagen zu obigen Problemen finden können.
Für (;möglichst konstruktive) Kommentare im Voraus vielen Dank :)
Gruß,
Matthias D.
Antwort von Matthias Eller:
Matthias Degenkolb schrieb:
> Hallo zusammen,
Hi,
> (;Multicast?)
brauchst du nicht, willst du nicht, und kannst du auch nicht wirklich
> - Gibt es Lösungen(;PCI-Karten) mit Hardwaredecodierung?
sicher, Encoden musste nix, das macht der TV sender für dich ;-)
Du musst nur das MPEG2 "weiterleiten". Die CPU muss dabei gar nix tun.
Auch beim Aufnehmen macht die CPU nix. Da wird nur das MPEG2 auf die
Platte geschrieben. Wenn die CPU decodieren würde währe es ja kein MPEG2
mehr sonder unkomprimierte Vollbilder.
Decoden tut dann erst der Client.
-> wenn du den Rechner nicht als SetTopBox nehmen willst, dann reicht ne
Budget vollkommen aus.
> - Welche Software eignet sich?
> Ich bin bis jetzt auf MythTV als ziemlich komplettes Mediacenter
> gestoßen. Gibt es was besseres? Kann man in MythTv
> Infrarotfernbedienungen (;Lirc) zum Umschalten nutzen?
der VDR mit streamdev plugin is dafür bestens geeignet.
Umgeschalten wird Cleintseitig via Stream URL
Da haste auch noch gleich n Videorecorder, wenn die Platte groß genug is.
Falls dazu noch fragen sind, schreib einfach...
Hab das hier schon zig mal aufgesetzt
> - Wie schauts mit dem Empfang aus?
da überlasse ich anderen das Wort
> - Zum Thema Stream im Ethernet: Wieviel Traffic fällt an?
> Ich nutze 100MBps LAN und 54 MBit WLAN. Reicht das in der Praxis an
> Bandbreite?
sicher, das ist mehr als genug. Was der Rechner versendet sind unicasts.
Also pro Client 1 Datenstrom. Und deren Bandbreiten entsprechen den
Bitraten der MPEGströme vom DVB-Signal. Also je 2-3 MBit.
Hier ist eher der Server und nicht das Netz der Flaschenhals.
MfG
Matthias Eller
Antwort von Andre Beck:
Matthias Eller
writes:
> Matthias Degenkolb schrieb:
>
>> (;Multicast?)
> brauchst du nicht, willst du nicht, und kannst du auch nicht wirklich
Wieso?
Ich wöllte auf jeden Fall, dass mehrere Empfänger, die gerade das selbe
Programm sehen, das per Multicast tun. Alles andere ist sinnlose Ver-
geudung von Bandbreite. Mag sein, dass man es in der 0815-Home-Umgebung
nicht wirklich braucht, weil 100Base genug Platz lässt, da auch alles
mehrfach parallel zu Unicasten. Clever ist das aber nicht. Ideal wäre
ein Sender, der automatisch von Unicast auf Multicast schaltet, wenn
der zweite Client das selbe Programm anfordert.
Und wieso sollte er das nicht können? VLC/VLS zeigen, wie einfach das
sein kann. Und AFAIR gibt es im Rahmen dieses Projektes Lösungen für
DVB-Recasting. Dass einige der Leute aus dem Projekt inzwischen Profi-
Headends für sowas bauen ist evtl. auch bekannt.
Ich sehe im Urposting nur ein Argument gegen Multicast: WLAN. Aufgrund
der spezifischen Funktionsweise von 802.11 sobald es um Broad-/Multi-
casts geht ist man ausgerechnet hier (;Funk - das Broadcastmedium über-
haupt!) eher schlecht dran. Jedenfalls, sobald man nichtideale Empfangs-
bedingungen hat. Dazu kommt der Bandbreitendeckel, wenn man neben 11g
auch noch 11b-Geräte unterstützen wöllte. Was rauskommt ist ein Tri-
lemma aus Reichweite, Empfangsqualität und Maximalbandbreite, in dem
man oft kein wirklich brauchbares Optimum findet.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Matthias Eller:
Andre Beck schrieb:
> Wieso?
Ganz einfach, weil Mulitcast ein Protokoll für Gruppenkommunikation ist.
Sinnvoll ist es erst, wenn man es mit verschiedenen Subnetzen oder VLans
zu tun hat. Es wird von Routern genutzt um Pakete zu gewissen Gruppen
zuzuordnen und entsprechend der Gruppenzugehörigkeit der Clients die
Pakete in die entsprechende Subnetze zu routen. Innerhalb dieser
Subnetze verhält sich der Multicast dann wie ein Broadcast. Moderne
Managbare Switches können sogenanntes IGMP-Snooping. Damit sind sie in
der Lage zu "wissen" welche Hosts an welchen Ports zu welchen Gruppen
gehöhren und können somit die Pakte selektiv weiterleiten.
> Ich wöllte auf jeden Fall, dass mehrere Empfänger, die gerade das selbe
> Programm sehen, das per Multicast tun.
Setzt wie oben gesagt Spezielle Hardware vorraus.
> Alles andere ist sinnlose Ver-
> geudung von Bandbreite. Mag sein, dass man es in der 0815-Home-Umgebung
> nicht wirklich braucht, weil 100Base genug Platz lässt, da auch alles
> mehrfach parallel zu Unicasten.
Ich glaube kaum, dass man zuhaus so viele Clients hat, dass die 100 MBit
bei den DVB üblichen Bitraten eng werden. Ich finde es übertrieben bei 5
mal 4Mbit von Verschwendung zu sprechen. Genauso währe es übertrieben
extra dafür teue Switches zu kaufen.
> Und wieso sollte er das nicht können?
Weil ich nicht glaube, dass der OP entsprechende Switches hat.
Ohne kann er auch gleich n Broadcast machen und das währe erst recht
Verschwendung.
> VLC/VLS zeigen, wie einfach das
> sein kann. Und AFAIR gibt es im Rahmen dieses Projektes Lösungen für
> DVB-Recasting. Dass einige der Leute aus dem Projekt inzwischen Profi-
> Headends für sowas bauen ist evtl. auch bekannt.
wir setzen im Rahmen eines Forschungsprojektes (;bei dem es genau um
soetwas geht) DVBStream ein und selbst in unserem sehr gut ausgebauten
Campusnetz (;http://www.fem.tu-ilmenau.de) funktioniert Multicast mehr
schlecht als recht.
-> Multicast ist was sehr exotisches
Antwort von Andre Beck:
Matthias Eller writes:
> Andre Beck schrieb:
>
>> Wieso?
>
> Ganz einfach, weil Mulitcast ein Protokoll für Gruppenkommunikation ist.
Richtig. Und genau darum geht es bei Videostreaming meistens: Um eine
1:n-Gruppenkommunikation. Es gibt nicht nur einen Empfänger (;Unicast),
aber es interessiert auch nicht jedes Gerät im Netz (;Broadcast), sondern
eine definierte Untergruppe. Folglich ist Multicast ideal, denn es ist
exakt dafür erfunden worden. Einige Hersteller haben das vor mehr als
10 Jahren begriffen, leider agieren sie eher hinter den Kulissen.
> Sinnvoll ist es erst, wenn man es mit verschiedenen Subnetzen oder VLans
> zu tun hat.
Falsch. IP-Multicast hat den Vorteil, dass es *auch* in einer gerouteten
Umgebung noch funktioniert (;es abstrahiert dazu L2-Multicast). Das ist
aber keine Einschränkung, IP-Multicast kommt auch wunderbar ohne eine
geroutete Umgebung aus. Es funktioniert in der simpelsten Broadcast-
domain, wie man mit VLC leicht zeigen kann.
> Es wird von Routern genutzt um Pakete zu gewissen Gruppen
> zuzuordnen und entsprechend der Gruppenzugehörigkeit der Clients die
> Pakete in die entsprechende Subnetze zu routen.
Das ist ein Bonus von IP-Multicast über die reine L2-Funktion, es
erlaubt IP-Multicast, die lokale Broadcastdomain zu verlassen und
im Idealfall global zu funktionieren (;mein Upstream zur globalen
Multicastwolke ist leider weggebrochen, waren das Zeiten als man
NASA-TV etc sehen konnte).
> Innerhalb dieser Subnetze verhält sich der Multicast dann wie ein
> Broadcast.
Nein, wenn er sich wie ein Broadcast verhalten würde, wäre es ein
Broadcast. Es ist und bleibt aber ein Multicast. In einer trivialen
Broadcastdomain heißt das, die Frames kommen zwar bei jedem Gerät
an, können aber bereits von der NIC gedropped werden, wenn sich
niemand für die Sendung interessiert. Broadcast-Frames müssen immer
angenommen und an die Software hochgereicht werden. Multicast ist
also immer effektiver als Broadcast, selbst mit einem Hub. Würde
man eine vergleichbare Datenrate broadcasten, würden zahlreiche
Geräte im LAN schlicht sterben, weil sie die Interruptrate von
der NIC mit ihrer CPU nicht mehr verdauen können (;vor allem wird
das ältere PCs und Netzwerkgeräte wie Terminalserver und managebare
Bridges/Switches betreffen).
> Moderne Managbare Switches können sogenanntes IGMP-Snooping. Damit sind
> sie in der Lage zu "wissen" welche Hosts an welchen Ports zu welchen
> Gruppen gehöhren und können somit die Pakte selektiv weiterleiten.
Es handelt sich weniger um selektive Weiterleitung an Interessierte
als vielmehr um selektive Unterdrückung der Weiterleitung an Nicht-
interessierte. IGMP-Snooping hilft, unnötiges Flooding von IP-Multi-
cast zu verhindern, es ist *nicht* *nötig*, damit IP-Multicast (;oder
Multicast überhaupt) funktioniert. Das tut es immer, auch an Coax,
auch mit einem Hub oder simplen Switch.
>> Ich wöllte auf jeden Fall, dass mehrere Empfänger, die gerade das selbe
>> Programm sehen, das per Multicast tun.
>
> Setzt wie oben gesagt Spezielle Hardware vorraus.
In keinster Weise. In einer gerouteten Umgebung erfordert es natürlich
Router mit der Fähigkeit zu Multicastrouting, aber welches SOHO-LAN
ist schon geroutet. In jeder simplen Broadcastdomain funktioniert
Multicast out of the Box, sofern keine defekte Hardware im Einsatz ist.
>> Alles andere ist sinnlose Ver-
>> geudung von Bandbreite. Mag sein, dass man es in der 0815-Home-Umgebung
>> nicht wirklich braucht, weil 100Base genug Platz lässt, da auch alles
>> mehrfach parallel zu Unicasten.
>
> Ich glaube kaum, dass man zuhaus so viele Clients hat, dass die 100 MBit
> bei den DVB üblichen Bitraten eng werden. Ich finde es übertrieben bei 5
> mal 4Mbit von Verschwendung zu sprechen.
Wenn ich DVB auf IP remuxen möchte, kann ich sehr schnell auf die Idee
kommen, das für mehr als eine handvoll STBs zu tun. Man kann das
durchaus als Verteillösung für ganze Häuser sehen. Und schon sieht
die Rechnung ganz anders aus. Wie gesagt, als optimal sehe ich eine
automatische Umschaltung von Unicast auf Multicast an. Man kann die
auch noch vom Client steuerbar gestalten, so dass ein WLAN-attached
Client vielleicht doch Unicast bekommt, um die Designschwächen von 802.11
auszubügeln. Im Idealfall würde sowas erst im Access-Layer wieder von
einem Multicast zu einem Unicast.
> Genauso währe es übertrieben extra dafür teue Switches zu kaufen.
Das wäre es sicher, wenn man das müsste. Muss man aber nicht, es
sei denn man will wirklich Gebäudeverteilung machen.
>> Und wieso sollte er das nicht können?
>
> Weil ich nicht glaube, dass der OP entsprechende Switches hat.
Die er nicht zwingend braucht. Also *kann* er es. Das Effizienz-Tradeoff
muss er natürlich selbst finden, und dabei kann rauskommen, dass er
Multicast nicht will. Aber das ist was anderes als "nicht kann".
> Ohne kann er auch gleich n Broadcast machen und das währe erst recht
> Verschwendung.
Ja, weil ein Broadcast auch unbeteiligte Endgeräte sinnlos belästigt.
Sicher wäre es besser, wenn man IGMP-Snooping-Switches hätte, um die
Sendung von unbeteiligten Ports zu prunen - aber das ist kein Killer-
kriterium, es geht auch prächtig ohne - nur nicht so effektiv.
>> VLC/VLS zeigen, wie einfach das
>> sein kann. Und AFAIR gibt es im Rahmen dieses Projektes Lösungen für
>> DVB-Recasting. Dass einige der Leute aus dem Projekt inzwischen Profi-
>> Headends für sowas bauen ist evtl. auch bekannt.
>
> wir setzen im Rahmen eines Forschungsprojektes (;bei dem es genau um
> soetwas geht) DVBStream ein und selbst in unserem sehr gut ausgebauten
> Campusnetz (;http://www.fem.tu-ilmenau.de) funktioniert Multicast mehr
> schlecht als recht.
Euer Netz ist ziemlich groß und funktionierendes Multicast darin sicher
eine Herausforderung, aber auch eine enorme Chance. Wenn es mehr schlecht
als recht funktioniert, sollte man das fixen statt auf Multicast zu ver-
zichten. Du willst nicht ernsthaft ein TV-Programm an 1500 User per
Unicast streamen, wenn Du es Multicasten könntest. Die 6509 wird kaum
das Problem sein, die 3548XL schon eher, da CGMP nicht ganz so rund
läuft wie Cisco das gern hätte. Keinesfalls "[fast] leave processing"
anschalten, auch wenn es weht tut. Die Procurve laufen sicher als reine
L2 Access-Switches und sind daher außer mit IGMP Snooping auch un-
kritisch. Kernfrage ist, wer routet und wie gut ist der beim Mrouting.
Ein ordentliches Design (;üblicherweise PIM Sparse Mode mit fest defi-
niertem Anycast-RP auf die Core-Router, die dann MSDP-Peering fahren)
sollte da aber Stabilität und Qualität reinbringen. Bei mir hat das
mit einfacherer Technik sogar mal global funktioniert.
> -> Multicast ist was sehr exotisches
Nicht wirklich. Es wird vielmehr von zu vielen Leuten beim Software-
und Systemdesign ignoriert. VLC konnte auch anfänglich zwar an Unicast-
und an Broadcast-IPs streamen, aber nicht an Multicast-Gruppen. Das
deutet auf eine Bildungslücke hin, das Konzept ist in breiten Teilen
der Entwicklerwelt, aber auch unter System- und Netzdesignern offenbar
völlig unbekannt. Die Exotik ist nicht inhärent, sondern eine Folge
dieser Ignoranz. Deswegen auch meine Gegenrede: Ein "Du willst das
nicht, brauchst das nicht und Du kannst es auch gar nicht" hilft uns
überhaupt nicht dabei, dieses Konzept endlich mal vernünftig ver-
breitet unterstützt zu bekommen. Warum soll auch ein absoluter Billig-
switch nicht IGMP Snooping beherrschen? In den nächsten Jahren wird
sich die Herstellerschar mit irgendwas differenzieren müssen, warum
nicht mit besserer Multicasteignung? Das ganze Gestreame von multi-
medialen Inhalten ist doch ein riesiger Zukunftsmarkt, es wäre doch
großartig, wenn man das mal ausnahmsweise richtig angehen würde statt
wieder nur Schund zu liefern (;heute wird ja oft der Zugriff über
remote file access Protokolle wie NFS oder CIFS/SMB als Streaming
bezeichnet, da sträubt sich mir jegliche Körperbehaarung). Also Druck
von Seiten der Softwareindustrie, dass Multicast geht, und schon wird
sich der Gerätemarkt mit Unterstützung überschlagen. Aber lass mich
raten: M$' neuester UPnP-Hack für Mediastreaming tut so, als hätte
es Mcast nie gegeben - oder sollte ich mich irren?
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
