Beiträge von joew

Wie gesagt: damals (2004) gab es Sat-IP nicht. Laut Wikipedia wurden die ersten Sat-IP Geräte 2012 vorgestellt.

Damals waren auch weder VDR noch der Server-Teil vom VLC (das gab es damals noch, VLS hiess der glaube ich) in der Lage, mit einem 450MHz Einkern-Pentium gleichzeitig mehrere hundert Streams auszuliefern.

Und was an diesem Server so exotisch sein soll, ist mir auch noch nicht so ganz klar. Die URLs der verfügbaren Streams sind per .m3u verfügbar. Mit "mplayer http://server:8000/3sat" können die URLs aber auch direkt angesteuert werden.

Können wir jetzt vielleicht wieder zum konstruktiven Modus zurückkommen?

Zitat von M-Reimer

Scheint mir alles sehr exotisch zu sein.

Dann ist VDR auch exotisch?

Zitat

Warum machst du nicht "standardkonformes" Sat-IP um die Streams ins Netz zu bekommen?

Erstens, weil ich diesen Server geschrieben habe, noch lange bevor Sat-IP existiert hat (2004).

Zweitens, weil Sat-IP immer ganze Transponder streamt, und man dann noch einen weiteren Client benötigt, um das gewünschte Programm rauszufiltern.

Und drittens, weil der extrem auf Effizienz getrimmt ist.

Zitat

Nimmt dein "eigener Server" auch auf? Wenn nein, dann spricht doch vieles dafür die Daten erstmal durch den VDR zu fahren (IPTV-Plugin).

Warum sollte er aufnehmen?

Im einfachsten Fall ist eine Aufnahme mittels

wget -O Meine-Aufnahme http://mein-server/zdf

zu bewerkstelligen.

Im besseren Fall ist das ein Perl-Skipt, das Anfang/Ende-Zeitpunkte der Aufnahmen sauber behandelt. Das ist mit weniger als 100 Zeilen Perl leicht zu bewerkstelligen. Ich sehe keinen Grund, diese Funktionalität in den Server zu integrieren und damit unnötig die Komplexität zu erhöhen.

Naja, wie oben geschrieben, habe ich (schon vor längerer Zeit) einen Server geschrieben, der Content von DVB-S/DVB-S2 als HTTP-Streams ausliefert.

Diesen Server möchte ich nun in die bestehende Infrastruktur (VDR+Kodi) einbinden.

Da erschien es mir am naheliegendsten, diesem Server das VNSI-Protokoll beizubringen, da der Kodi-PVR das bereits implementiert hat. Damit wären auch all die anderen Möglichkeiten offen (Aufnahmen ausliefern, EPG, Timer setzen, etc/pp).

Wenn es eine andere Möglichkeit gibt das mit einem guten WAF einzubinden (zB über eine .m3u-Kanalliste), wäre das natürlich auch ein gangbarer Weg.

Eine andere Alternative wäre, dass dieser Server das VNSI des VDR "forwarden" würde. Dann müsste ich im Kodi-PVR nur den Server eintragen und hätte die vom VDR bereitgestellten Inhalte ebenfalls (über diesen Umweg) zur Verfügung.

Zitat von M-Reimer

VNSI ist eigentlich ein reines VDR-Streaming-Protokoll.

OK

Zitat

HTTP sollte Kodi direkt streamen können. Ganz ohne Addon.

Ja, aber das ist dann nicht ganz so schön zu bedienen wie die Kanalauswahl bzw die Aufnahmen-Auswahl über das PVR-Plugin

Zitat

Und: Nein, VNSI verbindet mit genau einem VDR. Es ist schließlich ein PVR-Addon und davon kann immer nur eines aktiv sein.

Zitat

https://kodi.wiki/view/Internet_video_and_audio_streams

Naja, .m3u kann mein Server bereits, das ist nicht das Problem. Das auf .pls und .strm zu erweitern sollte auch kein Problem darstellen.

Aber solch eine Playlist ist halt für den alltäglichen Gebrauch (WAF-Faktor!) doch nicht ganz so toll. Da ist die Kanalauswahl über Nummern-Tasten oder eine Kanal-Liste doch angenehmer.

Oder gibt es für den Kodi ein Plugin, mit dem man die Einträge solcher Playlists wie bei einem herkömmlichen Fernseher auswählen kann?

Habe einen Server, der TS/PS streams per HTTP ausliefert. Diesen möchte ich erweitern, damit er auch den Kodi bedienen kann.

BTW: kann man bei Kodi einen zweiten Server eintragen?

Das hatte ich fast schon befürchtet

Hallo,

ich suche die Protokollbeschreibung von VNSI. Weiss jemand, wo ich diese finden kann?

Hallo,

im Wiki-Eintrag zur scr.conf ist die Rede von committed und uncommited switches.

Hat jemand eine Ahnung, was der Unterschied ist?

Zitat von jrie

Viele Vermutungen, wenige Fakten.

Ich habe ja bereits oben geschrieben, dass nach einem Download der mplayer bei lokaler Wiedergabe die gleichen Klötzchen zeigt wie Kodi auf Raspberry. Das ist für mich erst einmal ein klarer Hinweis, dass die Aufnahme kaputt ist.

Zitat

vdr-checkts (nicht der Patch, sondern das ausführbare Programm)

Naja, wenn Du darauf bestehst:

joew@bu201.zuhause.lan:/home/joew/vdr-checkts-master$ scp vdr2.zuhause.lan:/media/multimedia/vdr/recordings/ZDF-Mittagsmagazin/2018-12-14.12.58.1000-0.rec/*.ts .
00001.ts                           100%  325MB   4.9MB/s   01:06    
00002.ts                           100% 2000MB   3.5MB/s   09:37    
00003.ts                           100% 2000MB   3.5MB/s   09:40    
00004.ts                           100% 1369MB   2.9MB/s   07:48    
joew@bu201.zuhause.lan:/home/joew/vdr-checkts-master$ ./vdr-checkts .
Errors: 409
joew@bu201.zuhause.lan:/home/joew/vdr-checkts-master$

Zitat

Dann weisst du erst mal, ob die Aufnahmen ok sind oder nicht.

Nebenbei bemerkt: das Programm ist buggy.

Es berücksichtigt nicht, dass der Continuity_counter nicht inkrementiert wird wenn adaptation_field_control==0 ist

Es berücksichtigt nicht, dass in einem Transport stream unter gewissen Voraussetzungen Duplikate erlaubt sind. Hierbei wird ebenfalls der CC nicht inkrementiert

Es berücksichtigt auch nicht, dass der der discontinuity_indicator eine erlaubte Diskontinuität ankündigen kann.

Details findet man in iso13818-1.pdf auf Seite 20.

Insofern liefert mir dieses Programm auch nicht viel mehr Fakten als mein Test mit mplayer.

Zitat

Nochmal: Originaldatenstrom hat in der Kombination reelvdr/reelbox nicht funktioniert wegen Bildaussetzern. Wenn Du so willst also noch schlechtere Bildqualität.

War das denn wirklich der Originaldatenstrom? Dann würde mich brennend interessieren, wieso es ruckelt während der andere Originaldatenstrom (vom Raspi) einwandfrei wiedergegeben wird?

Wenn auf demselben TV an demselben HDMI-Eingang mit demselben HDMI-Kabel der eine ruckelt und der andere nicht, dann handelt es sich nicht um einen identischen Datenstrom. Das heisst, mindestens einer der beiden Datenströme ist nicht der Originaldatenstrom.

Zitat

Heute habe ich folgendes Szenario: RasPi/kodi hängt per vnsi an der selben Reelbox, gibt das Live-TV und die Aufnahmen von dort bzw. über den Zwischenschritt am Nas abgelegt wieder und jetzt habe ich super Bildqualität.

VDR legt ja die Aufnahmen als Original-TS-Datenstrom ab. Auch per VNSI liefert vdr den originalen Datenstrom. Wenn Raspi das 1:1 an den TV durchreicht, dann hast Du hier die besten Voraussetzungen.

Eine Skalierung/Anpassung erfolgt ja erst bei der Ausgabe auf das Endgerät. Hier muss IMHO bei der Fehlersuche (auf der Reelbox) angesetzt werden.

Überprüf doch nochmal die Ausgabe-Einstellungen der Reelbox...

Auch das würde ich in meinem Fall ausschliessen wollen.

VDR läuft auf echter Hardware (ich hasse VMs!)

Von den 8GB RAM sind 4GB frei, 1.2GB belegt und 2.8GB für Puffer/Cache verwendet. Hier ist also noch viel Luft.

Auch ist bei mir die Klötzchenbildung nicht nur kurz, sondern nahezu immer. Je bewegter das Bild ist, um so mehr. Wenn der Tagesschau-Sprecher gezeigt wird, habe ich nahezu keine Klötzchen. Sobald (bewegte) Filmeinblendungen kommen, geht es los mit den Klötzchen. Das deutet IMHO schon irgendwie auf ein Bandbreitenproblem hin.

Keine Auswirkungen hat es hingegen, wenn im Hintergund viel passiert. Ob nun mehrere Aufnahmen im Hintergrund laufen oder auch viel Plattenaktivität (zB Backups inklusive Komprimierung+Verschlüsselung) hat überhaupt keine Auswirkungen.

Zitat von ReelChris

Ich glaube, das wird hier jetzt zu off topic.

Ich denke nicht, dass das off-topic ist.

Schliesslich geht es hier um die Frage, ob ein Smart-TV als Client brauchbar ist oder nicht. Und die Frage, welche Fehler bei der alternativen Variante (nämlich separate-Set-Top-Box) möglich sind, ist in dieser Hinsicht durchaus relevant.

Zitat

Nur noch kurz: Das Ausgabeformat der Reelbox/des vdr war schon auf das Format des TV eingestellt (Full-HD und Framerate). Variable Einstellmöglichkeiten für Live-TV und Aufzeichnung gibt es nicht.

Das ist aber doch genau das, was ich oben geschrieben habe: Weder VDR noch Reelbox geben in Deinem Fall den Originalstrom an den TV, sondern haben daran Modifikationen vorgenommen. Wie das Ergebnis ausschaut ist dabei stark abhängig von den verwendeten Algorithmen und Einstellungen. Das hat nicht wirklich was mit der Qualität der verwendeten Hardware zu tun.

Und hier schliesst sich wieder der Kreis zur Ursprungsfrage: Idealerweise wird am Datenstrom maximal ein mal herumgefummelt.

Im Falle eines Smart-TV als Client ist das trivial: es existiert nur eine einzige Komponente, die herumfummeln kann (nämlich der TV). Und diese Komponente hat auch noch präzise Informationen über die verwendete Ausgabe-Hardware. Es ist also trivial, die Aufbereitung des Datenstromes auf dessen physikalische Eigenschaften zu optimieren.

Bei einer separaten Set-Top-Box haben wir nun plötzlich zwei Komponenten, die sich berufen fühlen könnten, den Datenstrom zu manipulieren. Hier bin ich der Meinung, dass sich die Set-Top-Box idealerweise zurückhalten sollte und den originalen Datenstrom unmodifiziert durchreichen sollte. Der TV ist in einer besseren Position, den Datenstrom an die Physik anzupassen.

Dass die STB sich nicht immer zurückhalten kann, wird einem spätestens bei OSD und PIP oder auch beim oben erwähnten hbbtv klar.

Anders sieht die Sache aus, wenn man einen TV mit sehr eingeschränkten Bearbeitungsmöglichkeiten hat. Einen alten Röhren-TV zum Beispiel. Damals musste die STB eine Bearbeitung vornehmen, um überhaupt ein brauchbares Bild auf die Scheibe zu bekommen.

Wenn wir all das berücksichtigen, dann muss man auch den obigen Ratschlag, sich den TV im Shop anzuschauen kritisch hinterfragen: Das Ergebnis ist davon abhängig, wie die gesamte Kette aufgebaut ist. Es macht einen erheblichen Unterschied, ob der TV im Shop mit seinem eingebauten Tuner direkt am SAT-ZF-Kabel hängt, oder ob er bei mir zu Hause den Datenstrom durch VDR+RasPi serviert bekommt. Wenn man sich den TV unbedingt im Shop anschauen möchte, dann sollte man den VDR+Raspi in den Shop mitbringen und darauf bestehen, diese auch anzuschliessen ;-))

Zitat von ReelChris

Bei meiner Reelbox war das Problem, dass das Szenario nicht exakt gleich herstellbar war, weil in der Einstellung "Quellauflösung" die Ausgabe geflackert hat. Die Einstellung "maximale Auflösung" liefert leider ein sehr vermatschtes Bild.

Na das sind doch schon einmal zwei wichtige Hinweise:

Flackern: da drängt sich doch unmittelbar auf, dass irgendwo in der Kette entweder die originale Framerate nicht verarbeitet werden kann oder aus irgendwelchen anderen Gründen an der Framerate herumgeschraubt wird.

maximale Auflösung: hier wird skaliert. Das ist also nicht mehr der originale Datenstrom. Gerade in diesem Bereich gibt es unzählige Algorithmen, die ein mehr oder weniger gutes Ergebnis liefern.

Vermutlich wurde bei Deiner "maximalen Auflösung" also sowohl die Framerate (evtl gar mehrfach) als auch die Auflösung angepasst. Es wurde also in zweierlei Hinsicht eine Nachbearbeitung vorgenommen. Mit dem originalen Datenstrom hat das nicht mehr viel zu tun. Dass das ein matschiges Ergebnis liefert muss also nicht wirklich wundern.

Zitat

Der lustige ReelMultimedia Support hat das auf den Fernseher geschoben. Dass es mit Raspi funktioniert ist der beste Nachweis, wo der Fehler tatsächlich liegt.

Ich glaube nicht, dass man das so pauschal sagen kann.

Wenn zB der Raspi den Original-Datenstrom ausgibt, dann wird die Skalierung und framerate-Anpassung auf dem TV vorgenommen. Die Algorithmen des TV sind (logischerweise) auf die Hardware des TV optimiert. Dass das ein anderes Ergebnis liefert als eine Skalierung/Anpassung auf der reelbox ist doch logisch. Denn die reelbox hat ja keinerlei Informationen darüber, wie die Hardware des TV konkret ausschaut.

Extrem wird es, wenn die Reelbox zB zuächst eine Skalierung/anpassung vornimmt und der ausgegebene Datenstrom dann doch nicht exakt zum TV passt. Dann nimmt der TV eine zweite Skalierung/Anpassung vor. Dass das Ergebnis dadurch nicht besser wird, sollte auf Anhieb einleuchten.

Zitat

Nochmal lustigerweise funktioniert auf der ReelBox die Ausgabe in Quellauflösung von Aufzeichnungen. Noch ein Nachweis, dass das ganze Teil total verbuggt war.

Bugs kann es überall geben. Aber selbst wenn man von bugs absieht, kann es bei sub-optimalen Konstellationen durchaus Qualitätsverlust geben. Daraus direkt Schlussfolgerungen auf eine einzelne Komponente zu ziehen ist aber gewagt. Man muss da schon die gesamte Kette betrachten.

Das beste Ergebnis wird man immer genau dann haben, wenn Auflösung und Framerate der Original-Daten EXAKT zur physikalischen Auflösung des TV passen UND keine Komponente in der Kette am Datenstrom herummodifizeirt.

Dummerweise gibt es nur noch 4k-TVs zu kaufen und vom SAT gibt es (derzeit) bestenfalls HD. Daraus folgt, dass mindestens eine Komponente am Datenstrom herumfummeln muss. Blöd wird es, wenn mehr als eine Komponente sich berufen fühlt, Anpassungen vorzunehmen.

IMHO wird man das beste Ergebnis dann erhalten, wenn man diese Anpassungen dem TV überlässt, der ja hoffentlich seine physikalischen Eigenschaften am besten kennt. Alle anderen Komponenten in der Kette sollten den Datenstrom idealerweise unmodifiziert durchreichen.

Zitat von Dumpfbacke

Da muss ich doch dran rütteln. Der VDR gibt ja nicht den Datenstrom aus, sondern das Ausgabeplugin, z.B. SoftHDdevice über die Grafikkarte. Und da gibt es anscheinend schon Unterschiede, was da aus dem Hdmi Ausgang rauskommt.

Wer auch immer den Datenstrom ausgibt: sofern nicht eine Nachbearbeitung erfolgt ist der Datenstrom identisch. (zB Skalierung, Schärfe, framerate-Anpassung, OSD-Überlagerung, wasauchimmer)

Zitat

Ich muss allerdings ReelChris recht geben, dass das Bild vom Raspi (auch ohne Kodi) besser ist, als das von meinem Haupt-VDR. Also gibt es schon Unterschiede zwischen den einzelnen Implementierungen.

Bei identischer Ausgabe-Konfiguration?

derselbe TV?

an demselben HDMI-Eingang,?

dieselbe Auflösung/Wiedergaberate?

dieselbe HDMI-Version?

dasselbe HDMI-Kabel?

dieselben Einstellungen?

Zitat von Dumpfbacke

Erstmal, traue KEINEM Vergleichstest, egal ob in einem Magazin gedruckt, oder online in diversen Magazinen. Eigentlich gibt es da doch nur noch Testsieger und Spitzenklasse.

Natürlich kann man nicht blind irgendwelchen Tests glauben. Ich habe ja auch oben schon geschrieben, dass man nicht Sponsoring-Tests für einen seriösen Test hält.

Ich unterstelle jetzt aber mal, dass die Tests zB in der CT nicht nur oberflächlich sind, sondern auch häufige Abstürze oder auch träge Fernbedienungen in die Bewertung mit einfliessen lassen. Wenn ich bedenke, welchen Aufwand CT in die Tests steckt, so ist das um Grössenordnungen mehr als ich es jemals könnte.

Zitat

Und den Fernseher nur als Monitor für den VDR, da ist Bildqualität verschenkt (leider). Ich habe es bisher mit dem VDR nicht hinbekommen, auch nur annähernd so ein Bild wie direkt vom Sat-Tuner meines Panasonic zu bekommen.

Huh?

Das Bild ist digital. Nach der Decodierung liefert VDR exakt das Bild, das vom Sender bereit gestellt wurde. Da gibt es nichts zu rütteln.

Unterschiede kann es allenfalls in der Nachbearbeitung/Aufbereitung (zB Up-Scaling) geben.

Wenn das Bild des VDR auf Deinem Panasonic anders aussieht als vom eingebauten Tuner, dann kann es IMHO nur daran liegen, dass der Fernseher den Datenstrom vom HDMI-Eingang anders aufbereitet/optimiert als den Datenstrom des Tuners. Das Problem ist also nicht VDR, sondern Dein Panasonic.

Zitat von TheChief

Hier bekommst Du vermutlich eher den Rat, dir den TV in einem Geschäft anzuschauen und nach der Bildqualität auszusuchen.

Was soll ich mir im Geschäft denn anschauen? Erstens ist das eh nicht die Umgebung, wo er später stehen wird. Zweitens ist da der Demo-Modus aktiv, um daneben stehende Modelle zu überstrahlen.

Da halte ich Vergleichstests für realistischer, wo verschiedene Geräte (von Fachleuten) verglichen und auch mal Messungen gemacht werden. Hier muss man natürlich aufpassen, dass die Tests auch unabhängig sind.

Zitat

Was mit so ein bisschen fehlt in Kodi, sind diese ganzen netten hbbtv features, die heute jeder Fernseher kann. Andererseits nerven auch die ganzen Werbeeinblendungen teilweise. Scheint aber irgendwie schwierig zu sein, einen HTML Renderer einzubauen.

Hmmm Mit hbbtv weiss ich im Moment noch nicht wirklich was anzufangen. Könnte tatsächlich interessant sein, wenn es nicht nur für Werbung missbraucht wird.

Die Schwierigkeit dürfte sein, die zwei Streams (einerseits DVB, andererseits die non-linearen Inhaltsdaten) zu verschmelzen. Dazu müssen beide Streams dekodiert und (wie auch immer) verschmolzen werden. Das Ganze evtl auch noch synchron. Das ist eine ganz andere Hausnummer, als einen Stream von Quelle A zu Ziel B durchzureichen. Da ist einiges an CPU-Power nötig. All die Geräte, die einen HW-Decoder verwenden, haben da IMHO keine Chance.

Der Server (auf dem ja VDR die Aufnahmen lokal macht) läuft unter Ubuntu-18.04.

Der Kodi-Client kommt erst bei der Wiedergabe ins Spiel. Da ist die Aufnahme ja bereits verhunzt.

Da ist IMHO nicht viel, was die Aufnahmen verhunzen könnte: VDR holt die Daten von der lokalen Max-S8 ab und speichert sie lokal auf das oben erwähnte aufs-Dateisystem. Da sind weder VNSI noch Kodi im Spiel.

Es scheint sich allgemein herauszukristallisieren, dass die in TVs eingebauten SmartTV-Funktionalitäten bei Weitem nicht an Kodi heranreichen. Und das nicht nur bei Tizen, sondern auch bei AndroidTV und den anderen Alternativen.

Derzeit scheint die beste Varianate zu sein, den TV lediglich als "Monitor" zu verwenden und den "Smart"-Teil über eine externe Kodi-Box hinzuzufügen. Die oben erwähnte Nvidea Shield scheint durchaus ein leistungsfähiges und problemloses Gerät zu sein. Das werde ich mir mal genauer anschauen.

Zum TV: In allen möglichen Testberichten sind Samsung-TVs durchgehend mit bestem Preis-Leistungs-Verhältnis vertreten. Sucht man bei anderen Herstellern, so muss man nahezu doppelt so tief in die Tasche greifen, wenn man vergleichbare Leistung haben möchte. Insofern tue ich mir schwer, auf einen anderen Hersteller umzuschwenken.

Passt diese Zusammenfassung, oder habe ich hier grobe Denkfehler drin?

Zitat von TheChief

Einfach einen kleinen Client dranhängen (eine S905x-Chinabox mit CoreElec zum Besipiel), dann kann man ja trotzdem die Smartfunktionen einen TV verwenden.

Joh, ich denke darauf wird es hinauslaufen.

Das dumme ist: bei den S905 Boxen gibt es auch ein heilloses durcheinander. Die Diskussionen in den Foren dazu gehen auch kreuz und quer und sind zudem auch noch recht angestaubt.

Zitat von CvH

[ ... ] eine vernünftige Konfigurationsmöglichkeit (auch mit beiden Augen zudrücken sind SSH und conf Dateien keine).

Das sehe ich anders: Mittel-/langfristig sind Config-Dateien wesentlich sinnvoller als irgendwelche grafischen Oberflächen, weil man das scripten kann.

Mein VDR läuft (seit 2007) auf Ubuntu. Installiert/konfiguriert wird das Ganze VOLLSTÄNDIG über ein (selbst geschriebenes) Konfigurationssystem, das alle meine Rechner (von den Laptops bis zu den Servern) installiert/konfiguriert. Der VDR wurde in dieser Zeit mindestens für jede LTS neu installiert. Mit einer Klickediklack-Konfiguration wäre ich da schon wahnsinnig geworden.

Zurück zum Thema:

• IMHO ist Wakeup den Aufwand nicht wert. Dieses Thema habe ich erschlagen, indem ich extrem sparsame Hardware verwende (basierend auf einem C'T-Bauvorschlag)
• Ubuntu verwende ich nicht etwa weil es besser ist als andere Lösungen, sondern schlicht weil mein Konfigurationssystem an Ubuntu am besten angepasst ist.
• Die bei Ubuntu enthaltenen VDR-Pakete mögen veraltet sein, aber sie funktionieren. Und sie reichen vollkommen für meinen Bedarf.
• e-tobi hatte ich in der Anfangszeit auch verwendet. Das ist dann aber regelmäßig in einem Chaos ausgeartet. Das mag sich in der Zwischenzeit gebessert haben.