Überlegungen zur channels.conf für DVB-C/S/T Mischbetrieb

  • Es bleibt die Frage, ob es in den Header für die Senderalternativengruppe der Channels.conf gehört, oder vielleicht besser anderswo aufgehoben ist.


    Ich denke in die channels.conf sollten wirklich nur die technischen Sendeparameter der Sender. Die Grupierungsmöglichkeit (per ":") sollte da auch rausfliegen. Wobei das jetzt schon ne konkrete Implementierungsfrage ist, erstmal sollte ja geklärt werden was das neue System leisten können soll.


    Prioritäten von Aufnahme zu Aufnahme ändern. Wie seht ihr das?


    Naja, die Prioritäten sind Individuelle Userwünsche welche Senderalternativen er bevorzugt.
    Jemand der auf HD steht wird die HD Varianten der Sender auf die höchste Priorität setzen. Jemand der Platz sparen will (weil die Aufnamhen z.B. gerne ohne Konvertierung auf dem SmartPhone angeschaut werden) wird die Sendervarianten mit der niedrigsten Bitrate auf die höchste Priorität setzen. Jemand mit ner DBV-C/DVB-S Mischbestückung in ner Gewitterschneise wird die Sendervarianten die über DVB-C reinkommen auf die höchste Priorität setzen. Die Prioritätsverteilung ist also etwas was sich jeder User dann selber für seine genutzten Sender über einen Prioritätseditor einstellt (für Sender für die er das nicht tut werden sie halt zufällig vergeben).


    So würde ich das jedenfalls sinnvoll finden.


    cu

  • erstmal sollte ja geklärt werden was das neue System leisten können soll.


    dazu sollte das schellstmöglich in die Mailingliste, um international bedacht zu werden. Ansonsten macht man sich viel Arbeit und muss letztendlich doch alles wieder aufräufeln.


    Gruß Fr@nk

  • Noch ein paar Gedanken:


    Auf der Sat-Position S28.2E gibt es viele +1-Kanäle: Beispiel: Zum Kanal "ITV1" gibt es einen Kanal "ITV1+1". Dort läuft das gleiche Programm, aber um 1 Stunde verschoben, so dass jemand, der ITV1 anzappt und eine interessante Sendung vor sich sieht, deren Anfang er gerade verpasst hat, trotzdem noch die Chance hat, sie komplett anzusehen, wenn er den +1-Kanal benutzt. Dies wäre auch ein Anwendungsfall für den hier diskutierten Mischbetrieb.


    Idee mit Brainstorming-Charakter: Jemand könnte ein Tool schreiben, welches die komplette epg.data durchwühlt und analysieren kann, ob zwei Kanäle miteinander "verwandt" sind, weil sie
    a) komplett das gleiche EPG haben (gleiche Sendungen zur gleichen Zeit)
    b) bis auf die absoluten Zeiten das gleiche EPG haben (gleiche Sendungen, aber zeitlich verschoben, also die "+1" Kanäle)
    c) teilweise deckungsgleiches EPG haben (Nachrichten zur gleichen Zeit, regionale Unterschiede zwischen zwei oder mehr Regionalsendern tolerieren, Halbtags-Sender)


    Bisher haben wir immer vom Sendernamen her gedacht: "ZDF" und "ZDF HD" gehören zusammen, weil sie offensichtlich den gleichen Namen haben. Wir haben aber kein Tool, um zu sehen, ob das EPG tatsächlich auch bis ins Detail übereinstimmt. Was hilft uns ein Kanalnamenmatching, wenn das EPG nur zu 80% übereinstimmt? Nehmen wir zum Beispiel mal an, "Wetten Dass..." würde nur auf ZDF überziehen dürfen, bei ZDF HD würde aber hart abgeschnitten werden zum planmäßigen Ende der Sendung.


    Gruß
    hepi

  • Hi,


    auch wenn der Fred schon leicht angestaubt ist, möchte ich trotzdem noch einen Kommentar loswerden.


    Noch vor 2 Monaten hätte ich gesagt: Au ja, klasse! Danach habe ich schon lange gesucht.


    Inzwischen sieht es etwas anders aus. Gerade der vielzitierte Sender zdf bringt mich noch dazu, mir alle Haare zu raufen.
    Gut, wie sich gezeigt hat, bin ich nicht gerade der Schnellmerker - dachte ich doch vor Kurzem noch, alles was auf HD-Sendern läuft wäre auch HD - und dank Lola weiß ich jetzt auch, dass in der Leberwurst keine Leber ist ;)


    Naja - langer Rede kurzer Sinn:
    Die SD-Sendungen auf HD-Sender aufgenommen sind ungenießbar - zumindest bei 2df, denn das interlaced Material wird bei denen einfach so als progressiv ausgestrahlt, ohne es durch einen Deinterlacer zu jagen. Nicht mal vdpau kann von dem Schrott noch ein akzeptables Bild zaubern. Die meisten so entstandenen Aufnahmen habe ich alle wieder gelöscht.
    Inzwischen bin ich dazu übergegangen und nehme SD-Sendungen bei 2df nur noch auf dem SD-Sender auf. Dank vdpau lässt sich das Material kaum noch von "echtem" Schmalspur-HD unterscheiden.


    Insofern bin ich nimmer dafür, gleichnamige Sender zu vereinheitlichen.


    Was gut wäre, wäre eine Möglichkeit Sendungen nach Qualität den einzelnen Sendern zuzuordnen. Eben HD-Sendungen sollen bei zdfHD aufgenommen werden, SD-Sendungen auf einem der 2df-SD-Sender. Derzeit verwende ich die Möglichkeit der Kanalgruppen bei epgsearch dafür.
    Alternativ könnte man auch den Sendungskategorien eine Reihenfolge von Sendern zuordnen, sodass auch andere Qualitätsunterschiede berücksichtigt werden könnten.


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    Einmal editiert, zuletzt von geronimo ()

  • und dank Lola weiß ich jetzt auch, dass in der Leberwurst keine Leber ist


    schlecht aufgepasst - "...im Leberkäse ist weder Leber noch Käse..." 8) :D


    Zitat

    Eben HD-Sendungen sollen bei zdfHD aufgenommen werden, SD-Sendungen auf einem der 2df-SD-Sender


    Wer soll denn das identifizieren? Alternativ könnte man beides parallel aufnehmen und dann nach Sicht selektieren.
    Aber mal eine Frage dazu. Normalerweise müsste doch ein hochskalierter Film in Mpeg4 mit dem Informationsgehalt von SD dank der besseren Kompression gegenüber Mpeg2 klar im Vorteil sein, wenn man die nalus abgestreift hat. Kann das jemand bestätigen, der beides parallel mal überprüft hat?


    Gruß Fr@nk

  • schlecht aufgepasst - "...im Leberkäse ist weder Leber noch Käse..."


    Schlecht recherchiert -Im Leberkäae ist, außer in Bayern, sehr wohl Leber drin.


    Zitat

    [...]
    Leberkäse in Deutschland
    In Deutschland gilt nach den Leitsätzen des Deutschen Lebensmittelbuchs für die Verkehrsbezeichnung Leberkäse, dass so bezeichnete Lebensmittel außerhalb Bayerns Leber enthalten müssen ....

    Quelle

  • -Im Leberkäae ist, außer in Bayern, sehr wohl Leber drin.


    "...Ursprünglich wurde dem Leberkäse Leber beigemengt, heute ist die Bezeichnung Fleischkäse (ursprünglich ein Schweizer Wort) treffender, da zumeist auf Leber verzichtet :lehrer1 wird. Die Bezeichnung als Käse leitet sich lediglich von der Form der Laibe ab..."


    gleiche Quelle


    man sollte also nicht erwarten,. das dort Leber drin sein muss (und darum ging es hier)


    Gruß Fr@nk

  • Wenn wir OT sind:


    Mit oder ohne Käse,hab ich das immer gern gegessen :D .


    Sogenannten "Gotterspeise" wie frikadelle "Unter motto nur der Liebe Gott weisst was da drin ist" :]



    Aber mal auf thema zurück zukommen:Findet ihr nicht das es zuviel von VDR verlangt ist so ne Monstar aufgabe zu erledigen,geschweige wer soll diese ganze parameter coden.


    Wäre es nicht machbar wie bei Enigma oder Neutrino so ne art channels/boquet editor auf Win oder Linux basis zum schreiben,der das zb. VDR komform alles apfragt,passend qonvertiert und das dann VDR übergibt als fertige channels.


    Hatt man zb. damit problem auserweg das VDR bei diese aufgabe,irgenteine andere cfg. durschen.. haut.wie zb. diseq cfg.Bringt mir nichts super schöne sortierte mischchannels.cfg,wenn die diseq,oder andere cfg. weg ist und ich wieder suchen muss,wo der hund begraben ist.


    Bin zwar kein linux kenner,
    aber damals wo ich bissen mit Acess DB gefummelt hab,und eine neue Funktion in bestehnde DB integrieren wollte,die neu Funktion hat zwar gefunzt,aber drei alte haben dann versagt :D .


    Ich denke mal bei VDR wird es nicht viel anderes sein.



    Nur so als anstoss nicht eingleisig zu fahren.
    MfG.Veni

    Meine VDR Spielzeuge VDR1 -Yavdr 0.6*SilverStone SST-M02B-MXR-GIADA MG-C1037SL -Imon Lcd-Imon FB-
    Intel Celeron 1037U*4GB RAM*GT-630*DD-Cine V5.5*


    Client1-Yavdr
    0.4 -MSI Media LiveGehäuse mit Original board-2 GB Ram60 GB SSD -
    Nvidia Gt210 -DM140 Plugin-Pearldpf display-Harmony
    One
    Onkyo TX-NR906
    Sony-KDL Serie
    Teufel Concept E


    Client2
    Raspberry XBMC auf XBIAN Basis mit xvdr

    2 Mal editiert, zuletzt von veni32 ()

  • Hi,


    Zitat

    Wer soll denn das identifizieren? Alternativ könnte man beides parallel aufnehmen und dann nach Sicht selektieren.


    Hm, ich hatte ja mal einen kurzen Abstecher zu einem angeblichen Konkurrenten des VDR gemacht.
    Die reine VDR-Funktionalität des Konkurrenten hat mir nicht mal ansatzweise gefallen und xbmc als Frontend wollte ich nicht ausprobieren ...
    Aber die Konfiguration und auch die EPG-Daten, bzw. die entsprechende Suche - also da kann man(n) sich mehr als eine Scheibe abschneiden.
    Dort war es z.B. problemlos möglich, nur die Sendungen anzuzeigen, die auch in HD ausgestrahlt werden.


    Deshalb gehe ich mal davon aus, dass die Information durchaus in den EPG-Daten zu finden ist.
    Ein derartiger Filter sollte also auch mit dem VDR machbar sein.


    Zitat

    Aber mal eine Frage dazu. Normalerweise müsste doch ein hochskalierter Film in Mpeg4 mit dem Informationsgehalt von SD dank der besseren Kompression gegenüber Mpeg2 klar im Vorteil sein, ...

    ... soweit es die Theorie betrifft, gebe ich Dir völlig Recht.


    Aber wenn Du den Schrott gesehen hättest, der im 2df gesendet wurde ...
    Auf einige Filme hatte ich mich richtig gefreut, weil ich dachte, die wären auch restauriert und neu gescannt worden ...
    Nichts da!
    Schräge Linien (z.B. Schulterpartie o.ä.) waren treppenförmig und es gab Verzahnungen in den Bildern ...
    Ein Film war besonders krass, der hatte einen rel. schnellen Abspann - den in Einzelbild angeschaut, konnte man keinen einzigen Buchstaben erkennen.
    Da war klar, dass Halbbilder als Vollbilder gesendet worden waren.
    Da ließ sich softwaremäßig natürlich nix mehr retten.


    Wenn ich dagegen SD-Filme mit der Handbremse verarbeite, dann gibt das ein wunderbares progressives Bild (auch wenn die CPU dafür nen halben Tag abgekocht wird).


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Deshalb gehe ich mal davon aus, dass die Information durchaus in den EPG-Daten zu finden ist.


    aber doch nicht im "internen" EPG - sprich man müsste Zusatzinfos aus externer Quelle zuladen? Vielleicht etwa sowas in der Art --> http://hdtv.the-media-channel.com/daserste-hd.html


    Gruß Fr@nk

  • Zitat

    aber doch nicht im "internen" EPG


    Hm, davon bin ich ausgegangen.


    Ich hatte das proggy einfach auf dem backend-Rechner installiert gehabt und nach Einrichtung der Karten einen Scan ausgeführt.
    Danach waren die Epg-Daten da und es konnte nach HD-Sendungen gefiltert werden.


    Der Rechner hatte möglicherweise Zugang zum Internet, ich musste jedoch nichts konfigurieren und bin auch bei keinem EPG-Dienst angemeldet.
    Müsste ich nomml ausprobieren, ob es auch ohne die netten Inder funzen würde ...


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Evtl. wird dort die Angabe des Videocodec ausgewertet?


    Aber das da wirklich ein HD Flag (also ob echtes HD oder hochscaliert) drinsteht kann ich mir nicht vorstellen. Es sei denn es wird das proprietäre Provider EPG (einige senden ja EPG Infos in privaten streams) zusätzlich ausgewertet?



    Wenns erst mal im EPG steht kanns der VDR ja auch, epgsearch kann ja Listen mit Sendungen die auf bestimmte Filterbedingungen passen ausgeben. Ferner kann man dort auch Suchtimer erstellen die alle HD Filme aufnehmen oder ähnliches.


    cu

  • Moin moin,


    Zitat

    Evtl. wird dort die Angabe des Videocodec ausgewertet?

    Hm, ist es nicht so, dass auf zdfHD auch SD-Sendungen als h264 in 720p gesendet werden? Sonst gäbe es die ganzen Probleme ja garnicht.


    Zitat

    Aber das da wirklich ein HD Flag (also ob echtes HD oder hochscaliert) drinsteht kann ich mir nicht vorstellen.

    So, gerade eben habe ich dem VDR den Zugang zu den netten Indern wechgenommen und das annere backend gestartet (siehe Bild).
    Ich habe mal die debug-Meldungen aktiviert, damit man sehen kann, dass dort tatsächlich auf den DVB-Karten rum genudelt wird.
    Wo die Informationen also herkommen? - Ihr wisst ja: ich habe keine Ahnung - und davon jede Menge!


    In der Auswahlbox gibt es 2 interessante Einträge: einmal HD und einmal HDTV (so als ob sich die Sender nicht einig wären, was sie schicken sollen).
    Wählt man HD aus, bleibt die Liste leer (vielleicht sind damit auch nur verschlüsselte Sendungen getaggt?).
    Wählt man dagegen HDTV aus, dann kommt die Liste auf dem Bild.


    Wie man unschwer erkennen kann, sind nicht alle Sendungen der ersten Reihe aufgeführt, muss also doch dazu dienen, Sendungen zu unterscheiden.
    ... und so kam ich zu der Aussage, was andere können, dürfte für die VDR-Mannschaft auch nicht unmöglich sein.
    Vielleicht mag sich ja jemand das Backend etwas genauer anschauen ...


    Gruß Gero


    P.S. ganz interessant finde ich auch den Ansatz, Aufnahmen im mkv-Format abzulegen. Das spart die aufwändige Nachbehandlung und die Dateien sind mit den meisten Standardplayern abspielbar - also auch nicht ganz schlecht ;)

  • Bisher haben wir immer vom Sendernamen her gedacht: "ZDF" und "ZDF HD" gehören zusammen, weil sie offensichtlich den gleichen Namen haben. Wir haben aber kein Tool, um zu sehen, ob das EPG tatsächlich auch bis ins Detail übereinstimmt. Was hilft uns ein Kanalnamenmatching, wenn das EPG nur zu 80% übereinstimmt? Nehmen wir zum Beispiel mal an, "Wetten Dass..." würde nur auf ZDF überziehen dürfen, bei ZDF HD würde aber hart abgeschnitten werden zum planmäßigen Ende der Sendung.


    Ich denke das würde die Sender ins totale Chaos stürzen, weil dann die Nachfolgesendungen nicht mehr synchron laufen würden. Spätestens mit der nächsten Live-Sendung müsste so eine Differenz wieder korrigiert werden, was im Normalfall die Nachrichten sein dürften. Auch vom Aufwand her bräuchte man dauernd zwei Sendezentren, und mir ist auch noch keine Fernsehzeitung begegnet die HD und SD trennt.


    Ich nutze aktuell auch einen Mischbetrieb aus DVB-T und DVB-C. Schon weil mir die Grundverschlüsselung gestohlen bleiben kann. Antenne ist natürlich Störanfälliger, wobei Ich bevorzugt über ÖR und Kabel aufzeichne. Da wäre es schon hilfreich die Antennen-Transponder als Fallback nutzen zu können, ohne drei Identische Sender in der Liste zu haben.

    Hardware: Point of View ION/ATOM330, 2GB, 160GB (Lokal), 2TB über NFS, Hauppauge Nova-T Stick (2040:7070), SoundGraph IMON (15c2:0036 VFD)
    System: Debian Squeeze, Kernel 3.1.2 (self build), Nvidia 285.05.09, lcdproc 0.5.5, lirc 0.9.0
    VDR: vdr 1.7.21 (etobi) + xvdr (git), xineliboutput, markad
    XBMC: opdenkamp PVR branch (git)

  • Moin!


    Heute morgen beim Spaziergang in die Firma hab ich noch mal über das Thema "Channel Bonding" (nennen wir's einfach mal so) nachgedacht.
    Es müssten so viele kleine Stellen überall im vdr angepasst werden, dass ich erst mal wieder Abstand davon genommen habe.


    Aber dabei ist mir eine andere (Plugin-)Lösungsmöglichkeit eingefallen, die ich gerne mal überprüfen möchte.
    Man ordnet die zusammengehörigen Kanäle in einer "Qualitätsliste" und das Plugin läuft immer mal wieder (bzw. bei Änderungen) über die erstellten Timer, um abhängig von der Priorität und den Konflikten dann den passenden Kanal einzusetzen.
    Keine Ahnung, ob das so machbar ist und was man da alles beachten muss (Zuordnung zum Event usw.), aber irgendwie sagt mein Gefühl, dass es einfacher wäre als die "Komplettumsetzung".
    Dann hat man zumindest bei den Aufnahmen die "beste" Qualität aber nicht beim Zappen. Da mein letztes "Live-TV-Erlebnis" schon ziemlich lange her ist, würde ich das auch nicht direkt vermissen... vdr sei Dank. :)


    Lars.

  • Zitat

    Aber dabei ist mir eine andere (Plugin-)Lösungsmöglichkeit eingefallen

    Also für mich ist die Frage, ob eine bestimmte Funktionalität vom VDR(-core) oder von einem Plugin zur Verfügung gestellt wird erstmal eine rein polititsche - nämlich die, ob Klaus alleine bestimmen möchte, wie die Funktionalität aussehen soll.
    Dort wo Anwender der Meinung sind, dass etwas anders funktionieren sollte, als im Standard, da gibt es Patches. Bei Plugins dürfen Anwender (bzw. die Plugin-Entwickler) von vornherein entscheiden, wie die Funktionalität aussehen soll ...
    ... für den Anwender ist es letzlich Jacke wie Hose, ob eine Funktionalität per Standard, per Patch oder per Plugin geliefert wird. Hauptsache es funzt ;)


    Zitat

    Man ordnet die zusammengehörigen Kanäle in einer "Qualitätsliste" und das Plugin läuft immer mal wieder (bzw. bei Änderungen) über die erstellten Timer, um abhängig von der Priorität und den Konflikten dann den passenden Kanal einzusetzen.

    Das ist genau der Punkt, der mir auch fehlt, bzw. die Funktionlität, die ich mir schon lange wünsche.


    Nenn es Qualitätsliste, Prio oder Reihenfolge - völlig Banane.
    Ablauf soll doch so sein, dass man eine (gewichtete) Reihenfolge (gibt es auch andere?) festlegt, in der verschiedene Möglichkeiten überprüft werden.
    Die Reihenfolge wäre für Timer festzulegen - wobei es hier die Möglichkeit geben sollte festzulegen, welcher Sender von welcher DVB-Karte "gezogen" werden soll.
    Gleichermaßen sollte eine andere Reihenfolge für Life-Glotzing pro Client festgelegt werden können. Beide Reihenfolgen könnten gleich sein, könnten aber auch unterschiedlich sein. Dann könnte ich z.B. den Empfänger der SD-FF für Life verwenden, für Aufnahmen aber sperren (würde in meinem Setup einiges entspannen).


    Wenn man dann noch die Reihenfolge/Prio(-liste) mit "Viehtschern" aus dem EPG verknüpfen könnte (wie z.B. HD <> nicht HD, verschlüsselt <> nicht verschlüsselt, Radio <> TV, ...), dann wäre das schlicht genial.


    Bei der Zusammenführung der EPG-Daten gleicher Sender unterschiedlicher technischer Parameter würde ich auf EPG-Ebene nur das unterscheiden, was anhand von EPG-Kriterien unterschieden werden kann. Also eine SD-Sendung, die auf HD-Sender und auf SD-Sender läuft, wäre z.B. ein EPG-Event, eine HD-Sendung, die auf HD-Sendern in HD läuft und auf SD-Sendern in SD bliebe 2 separate EPG-Events. So könnte z.B. epgsearch reagieren, wenn man eine Sendung nur in HD aufnehmen will ...
    Auf dieser Basis könnte jedem EPG-Event eine Sender-DVB-Karten-Prio-Liste verpasst werden, sodass jede Zuordnung eindeutig bestimmt werden kann.


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Haben wir überhaupt die Möglichkeit am EPG zu erkennen ob eine Sendung auf einem HD-Sender wirklich HD ist? Ich würde dem Timer gerne selber sagen welche Qualitätsstufe ich bevorzuge.


    So nehme ich trotz HD, viele Sendungen bevorzugt über SD auf, denn ich habe mir eine halbautomatische Verarbeitung gebastelt. Mit einer modifizierten Version von Project-X, welche MarkAd und Titeldaten als Batch direkt aus dem VDR-Verzeichnis liest. Dort muss ich lediglich die Schnittmarken kontrollieren, und der Rest läuft Automatisch. Leider gibts immer noch nichts vergleichbares natives für HD unter Linux, und so mache ich mir den Aufwand dort nur wo es für mich lohnt.

    Hardware: Point of View ION/ATOM330, 2GB, 160GB (Lokal), 2TB über NFS, Hauppauge Nova-T Stick (2040:7070), SoundGraph IMON (15c2:0036 VFD)
    System: Debian Squeeze, Kernel 3.1.2 (self build), Nvidia 285.05.09, lcdproc 0.5.5, lirc 0.9.0
    VDR: vdr 1.7.21 (etobi) + xvdr (git), xineliboutput, markad
    XBMC: opdenkamp PVR branch (git)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!