HDTV (DVB-S2 und h264) mit VDR und Xine-Plugin

hallo,

ich möchte niemandem zu nahe treten (schon gar nicht reinhard/rnissl) wegen der vielleicht auch nicht zum thread passenden frage, doch ein neuer thread wäre wohl überzogen - also, nur eine kleine abweichung hier, ok ?

--> ist es möglich, HD-Kanäle auch mittels "vdr-xineliboutput" auszugeben od. basiert die ganze sache ausschließlich auf dem xine-plugin??

(irgendwie ist für mich das ganze thema - trotz ständigem mitlesen - noch etwas schwammig)

ausschnitt history des aktuellen xineliboutput - v1.0.1:
------------------
- Added support for xine-lib 1.2 hg branch
- Initial support for H.264 video
- Support for HD-resolution OSD (Petri Helin). Requires patched vdr. (--> welcher patch ist hier wohl gemeint? doch nicht: h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff?)
------------------

wäre für eine kurze klarstellung echt dankbar!

gruß, ciax

Hallo ciax,

jepp HDTV geht auch mit xineliboutput ohne Probleme.

Voraussetzung: VDR mit multiproto-Treibern, => Schau dir doch mal den ext-Patch von Zulu an, da ist alles dabei.

Den OSD-Patch für den VDR gibts hier:

http://www.linuxtv.org/piperma…/2007-January/011744.html

Gruß
Wolfgang

hi wbreu!

danke für deine schnelle antwort! .. das ist super (kenn mich mit xineliboutput etwas besser aus als mit xine-plug - nur deshalb ..).

Zitat

Voraussetzung: VDR mit multiproto-Treibern, => Schau dir doch mal den ext-Patch von Zulu an, da ist alles dabei.

multiproto sind schon aktiv - den ext-patch von zulu hab ich auch, allerdings nicht die letzte versione (noch ohne "h264-syncearly-framespersec..diff" - der ist "händisch" dabei).

bzgl. xineliboutput - Support for HD-resolution OSD (Petri Helin). Requires patched vdr.

also sollte es mit aktuellem ext-patch ok sein? (//EDIT: hinfällig --> siehe oben)

danke, ciax

//EDIT: .. hab dein edit zu spät gesehen - danke!

Ich hab teilweise bei HD Aufnahmen den Effekt, daß sobald ich ein schwarzes Bild habe (z.B. bei Szenenwechsel) setzt der Ton aus.
Hat jemand das Gleiche Problem oder kann mir sagen woran das liegen kann ??

Hallo Leute,

zwar gehoert es nicht hierher, aber ich poste es jetzt mal trotzdem.
Weil weiter oben im Thread berichten einige Leute ueber Empfangsprobleme von ZDF und anderen speziellen Sendern mit der TT S2-3200 HD.

Zitat

Originally posted by ollo
... nix Treiber Bug der TT S2-3200! Nachdem ich die Schüssel nachjustiert habe, klappts auch mit dem ZDF wieder

von wegen...

Es ist, wie ich vermutet habe, tatsaechlich ein Treiber/Hardwareproblem.

Einen Workaround gibt's hier: TT S2-3200 HD / SkyStar HD Hardware- und Treiberfragen

Fuer weitere Infos bitte dort weiterposten.

- sparkie

Alter Thread, aber da es genau zu diesem Thema gehört, poste ich es hier, anstatt einen neuen Thread aufzumachen:
Ich bin mit xineliboutput nicht zufrieden - die Umschaltzeit bei HD-Sendern liegt bei teilweise über 5 Sekunden, und Einstellungen, die ich in der config vornehme, um das zu beheben, sind beim nächsten Mal überschrieben.nMit xine sieht es hier weitaus besser aus.
Allerdings weiß ich momentan nicht, wie ich zwei Probleme lösen kann:
1. Im Gegensatz zu vdr-sxfe habe ich keine --reconnect-Option gefunden. Sollte der VDR also beendet oder neu gestartet werden, beendet sich auch xine. Gibt es doch eine automatische Reconnect-Möglichkeit oder muss ich über das Startscript ständig überprüfen, ob der VDR läuft und xine direkt danach mitstarten.
2. Beim Umschalten zwischen den HD-Sendern beenden sich hier gelegentlich xine und X - die letzten Meldungen n der Konsole sind:

...
vdpau_set_property : property=13, value=100
xiTK received SIGSERV signal, RIP.


waiting for X server to shut down  ddxSigGiveUp: Closing log

Auch zum Beheben dieses Problems wäre Punkt 1 hilfreich.
Irgendwelche Ideen?

Ich rufe xine (derzeit noch als root) wie folgt in der Konsole auf - unter GNOME habe hier hier Probleme v.a. mit dem Ton per SPDIF:

xinit /usr/bin/xine -D -V vdpau -F -r auto --post vdr_video --post vdr_audio --post upmix_mono --post vdr --verbose=2 vdr:/tmp/vdr-xine/stream#demux:mpeg_pes &

Ich verwende die aktuelle "stabile" Version 190.53 der NVidia-Treiber, Basis ist Ubuntu 9.10 (32-Bit) mit den Paketen von LP-PPA-the-vdr-team (derzeit VDR 1.7.10 mit xine 0.9.3).

Welche Logfiles wären relevant? In /var/log/messages sowie /var/log/syslog finde ich nichts Relevantes - außer vielleicht Buffer overflows, die aber wohl auch bei jedem Umschalten angezeigt werden, auch ohne xine-/X-Absturz.

Besten Dank im Voraus

Jörg

JK1974

zu 1. Nein, es gibt keine Reconnect Option, die gibt es bei sxfe auch nur für den Connect über TCP. Xine-ui verbindet auf eine Socket Datei, das kann sxfe auch, dann aber auch nur ohne reconnect. Ich meine "bexbier" hat mal ein paar Zeilen Code geschrieben, das das xine-plugin direkt das Frontend mitstartet, schau mal im Wiki unter xine-plugin.

Zu 2. und dem Rest: Ich meine die Libraries des Repos sind gegen Nvidia Beta 195.30 kompiliert. Könnte sein, das Du deshalb diese Stabilitätsprobleme hast. "rnissl's" xine-plugin@xine-ui ist IMHO sonst ein herausragendes Beispiel an Stabilität.

Einzig das "Problem" das ich kenne ist, wenn das Backend wegbricht, das man manuell irgendwie für einen "reconnect" sorgen muß.

Der mitgelieferte xineplayer ist in Verbindung mit dem mplayer-Plugin auch super stabil und performant. Es fehlen allerdings ein paar wenige Dinge wie Fortschrittsbalken, Pause, eine Art Sprungfunktion, aber das wird wohl noch werden...

Gruß
Frank

Hi,

Zitat

zu 1. Nein, es gibt keine Reconnect Option, die gibt es bei sxfe auch nur für den Connect über TCP. Xine-ui verbindet auf eine Socket Datei, das kann sxfe auch, dann aber auch nur ohne reconnect. Ich meine "bexbier" hat mal ein paar Zeilen Code geschrieben, das das xine-plugin direkt das Frontend mitstartet, schau mal im Wiki unter xine-plugin

kleine Ergänzung noch zu 1: Hier findest Du die von fnu genannte Codeerweiterung incl. VDPAU-Parameter:

http://www.vdrportal.de/board/thread.php?threadid=89920

Grüsse
Matthias

Hi,

Ich meine die Libraries des Repos sind gegen Nvidia Beta 195.30 kompiliert.

Die hatte ich gerade drauf und hatte genau da die Probleme beim Umschalten der HD-Channels. Ich schaffe es bei schnellem Umschalten quasi nach maximal 2 Minuten, xine und/oder X zu crashen.

Habe gerade die genannten Stable-Treiber draufgemacht und werde nochmal genauer testen, habe aber gerade gemerkt, dass der VDRAdmin nach dem Update nicht mehr tut - erstmal diesen Brand löschen

EDIT: Habe es mir gerade im Wiki angeschaut, aber eigentlich läuft das dem Prinzip des Paketmanagements zuwider, wenn ich etwas in den Sourcen verändere, nur damit xine synchron zum VDR startet. Zudem möchte ich noch XBMC parallel laufen lassen, und während ich XBMC nutze, möchte ich den VDR im Hintergrund weiterlaufen lassen, damit die Timer funktionieren.
Wie habt Ihr das denn mit dem Neustart geregelt, oder benötigt Ihr den nicht? Oder macht Ihr den Neustart einfach über die Fernbedienung?

Hi,

Zitat

Wie habt Ihr das denn mit dem Neustart geregelt, oder benötigt Ihr den nicht? Oder macht Ihr den Neustart einfach über die Fernbedienung?

Bei mir läuft's unter der Suse recht stabil (Details siehe Signatur). Ab und an habe ich einen Segfault im text2skin plugin. Dann geht aber der VDR ganz runter und der VDR und ein entsprechender xine-Prozess werden neu gestartet.

XBMC habe ich (noch) nicht drauf. Demzufolge habe ich das Problem mit dem Weiterlaufen des VDR nicht.

Mehr Probleme hatte ich mit der Suse 11.1, da habe ich den Ton über HDMI ausgegeben. Da hatte ich auch ziemlich bescheidene Umschaltzeiten. Durch einen Bug im Nvidia-Treiber muss ich nach dem Update auf Suse 11.2 den Ton per SPDIF ausgeben (siehe auch http://www.vdrportal.de/board/…?postid=870766#post870766).

Grüsse
Matthias

Hab´s gerade nochmal mit den Stable-Treibern gegengecheckt, und auch hier schaffe ich es, xine/X nach einigem Umschalten der HD-Sender (nicht SD!) zum Absturz zu bringen.
Werde mir nochmal die Buffer-Settings von wbreu anschauen und übernehmen - vielleicht sorgt ja Datenmüll beim Decoding für die Probleme, der durch falsche Puffer-Einstellungen hervorgerufen werden.
Ein Bugfix wäre aber dennoch schön...

Zitat

Original von JK1974
Wie habt Ihr das denn mit dem Neustart geregelt, oder benötigt Ihr den nicht?

Auf dem HD Test System benötige ich den tatsächlich erfreulicherweise nicht, läuft unglaublich stabil. Die ganz selten Hänger behebe ich z.Zt. mit einem Reset, da das System innerhalb 30sek. wieder hochkommt ...

Da es ein Testsystem ist, habe ich mir auch noch keine Gedanken gemacht. Aber wenn, würde ich mir aber ein Lösung suchen, bei welcher der VDR Watchdog das Frontend durch eine Script-Anpassung wieder neu mitstartet.

Mein Haupt-VDR (softdevice) benötigt das zweimal nicht, der hatte in 2 Jahren nicht einen einzigen Absturz und wenn würde softdevice ja wieder mitstarten, da das Frontend beinhaltet ist.

[OT]
Mit XMBC habe ich kein Problem, nutze ich nicht, möchte ich auch nicht nutzen, ich mag den VDR wie er ist. Klaus hat da ein wunderbares Stück Software mit einer genialen (einfachen) Bedienung geschaffen, was IMHO primär den Erfolg ausmacht. Die Skins sind nicht so schlecht und ausserdem muß das Material gut aussehen und nicht die Oberfläche ...
[/OT]

Gruß
Frank

Habe weiterexperimentiert - und bin fast am verzweifeln...

Zunächst habe ich mal angefangen, ein kleines Startskript zu bauen, das die xine-/X-Abstürze abfangen soll:

#!/bin/sh
SERVICE='xinit /usr/bin/xine -D -V vdpau -F -r auto --post vdr_video --post vdr_audio --post upmix_mono --post vdr --verbose=2 vdr:/tmp/vdr-xine/stream#demux:mpeg_pes' 


while (true) do
   $SERVICE
   if ps ax | grep -v grep | grep '/usr/bin/xine' > /dev/null; then exit; fi
   /etc/init.d/alsa-utils stop
   alsa force-reload
   /etc/init.d/alsa-utils start
   sleep 5
done

Aber ich habe jetzt ein neues Problem, wie man sehen kann: Sehr oft funktioniert nach dem Restart der MP2-Ton nicht mehr. Ich habe daher versucht, das durch einen Reload der alsa-Treiber zu korrigieren, aber leider hilft das nichts. Auch ein Check mit alsamixer hilft nicht weiter - selbst wenn alle Regler offen sind, höre ich nichts. Ich weiß also nicht, wie ich, abgesehen von einem "service gdm start" oder reboot wieder MP2-Ton per SPDIF bekomme. Noch irgendwelche Tipps?

Langsam bekomme ich das Gefühl, dass das alles - auch die teilweise langen Umschaltzeiten und Syncprobleme bei vdr-sxfe und natürlich die Abstürze von xine - mit der SPDIF-Ausgabe in Zusammenhang steht. Auch bei XBMC geht´s mal und mal nicht.
Von Usern, die die HDMI-Ausgabe nutzen, hört man dagegen eher seltener, dass sie es nicht zum Laufen bekommen.

Zitat

Original von JK1974
Von Usern, die die HDMI-Ausgabe nutzen, hört man dagegen eher seltener, dass sie es nicht zum Laufen bekommen.

Ob Du da mal nicht auf dem Holzweg bist und Dir etwas einredest.

Soweit ich mich erinnere, gibt es noch keine brauchbaren Treiber um den Sound über eine HDMI Grafikkarte auszugeben. Wenn jemand das heute über HDMI ausgibt, schleift er IMHO das S/P-DIF Signal durch einen internes Kabel vom Mainboard an die Grafikkarte und damit auf des HDMI Kabel, somit bleibt Alsa im Spiel. Ich kann mich aber auch täuschen und lasse mich gerne eines besseren belehren.

Und ja, Sound kann Deine Instabilität verursachen, aber lösen mußt Du die durch strukturierte Fehlersuche, nicht durch Prinzip Hoffnung.

Gruß
Frank

PS.: Ich kann problemlos alle Tonspuren mit Alsa über die OnBoard Soundkarten beider VDRs über den S/P-DIF Ausgang der Mainboards nutzen.

Hi,

würde gerne strukturiert vorgehen, aber ich weiß nicht, in welchen Logfiles ich die Antwort auf die Absturzprobleme finde - in der /var/log/messages ist ebenso wenig etwas zu finden wie in der /var/log/syslog.

Darüber hinaus habe ich hier im AC3-Bereich mal meine Probleme gepostet - und jeder hatte irgendwelches Gezeter. Gleiches gilt, wenn man nach M3N78Pro und XBMC sucht. Und wenn ich bei XBMC nix höre, in den Settings auf "analog" umschalte und dann wieder zurück auf "digital" und es dann funktioniert, ist es entweder ein Bug in XBMC oder ein Problem in der Treiberinitialisierung.

Daher meine Vermutung, den Bug im Bereich der SPDIF-Audioausgabe zu suchen. Zudem weisen alle Guides zu diesem Board auf eine Ausgabe z.B. über hw:0,3 hin, also HDMI-Ton, nicht auf hw:0,1, also SPDIF (z.B. http://www.vdr-wiki.de/wiki/in…onsanleitung_Ubuntu#Audio).
Hinzu kommt, dass v.a. XBMC erst seitdem unter Ubuntu 9.10 mit SPDIF gut/besser funktioniert, nachdem ich ein Alsa-Update-Skript laufen gelassen habe.
Gut, vielleicht ist es auch Ubuntu selbst und ich sollte es mal mit Debian probieren...

Aber wie gesagt: Wenn mir jemand sagen kann, wo ich ein detailiertes Log für xine/X finde, wäre ich auch sehr dankbar, denn ich stochere tatsächlich derzeit im Dunkeln.

Also ich hatte auch diverse Alsa-probleme(p5n7a), und bei mir half es, zum einen Pulseaudio zu deinstallieren und dann noch plug:iec958 statt hw:0,1 anzugeben.

So läufts jetzt ziemlich gut, ac3 passthrought und auch stereo Ausgabe kommt alles wie es soll.

Nur manchmal beim umschalten xbmc<->vdr-sxfe fehlt der ton, nochmaliges umschalten hilft dann aber. Evtl sollte ich da nochmal einen angepasste .asoundrc einrichten

JK1974

Zitat

Sehr oft funktioniert nach dem Restart der MP2-Ton nicht mehr.

Dieses Problem hatte ich auch, DTS Ton war jedoch weiter vorhanden.
Die Lösung war bei mir:

iecset audio on

Das mit den Abstürzen beim Umschalten auf einen HD-Kanal habe ich seit dem letzten Update (->xinelibs-1.2) auch, allerdings beendet sich bei mir nur xine. Bin aber bisher davon ausgegangen, dass es am Rumspielen der Parameter in der ~/.xine/config lag...

Zitat

Original von fnu

Ob Du da mal nicht auf dem Holzweg bist und Dir etwas einredest.

Soweit ich mich erinnere, gibt es noch keine brauchbaren Treiber um den Sound über eine HDMI Grafikkarte auszugeben. Wenn jemand das heute über HDMI ausgibt, schleift er IMHO das S/P-DIF Signal durch einen internes Kabel vom Mainboard an die Grafikkarte und damit auf des HDMI Kabel, somit bleibt Alsa im Spiel. Ich kann mich aber auch täuschen und lasse mich gerne eines besseren belehren.

Was ich hiermit auch tun werde
Zumindestens mit einem Ion funktioniert die Tonausgabe über HDMI ohne irgendwelche Durchschleifkabel.
Aber Alsa bleibt natürlich in jedem Fall im Spiel, denn Tonausgabe über HDMI bedeutet nichts anderes, als das Alsa das übernimmt (wenn es den Chip kennt).

Allerdings hatte ich mit Ton bis jetzt die allerwenigstens Probleme, eher im (HD-)Videobereich...

Zitat

Original von Razorblade
Was ich hiermit auch tun werde
Zumindestens mit einem Ion funktioniert die Tonausgabe über HDMI ohne irgendwelche Durchschleifkabel.
Aber Alsa bleibt natürlich in jedem Fall im Spiel, denn Tonausgabe über HDMI bedeutet nichts anderes, als das Alsa das übernimmt (wenn es den Chip kennt).

Allerdings hatte ich mit Ton bis jetzt die allerwenigstens Probleme, eher im (HD-)Videobereich...

Razorblade

Danke für die Info, aber gleich die Gegenfrage. Wird beim ION zur Tonausgabe wirklich die Grafikkarte genommen, wie es bei einer GF Einsteckkarte oder OnBoard Unit genommen werden sollte?

Oder ist es nicht eher so, das sich auf ION Board ein Sound Chip nach "Intel HD" Spezifikation befindet der wie OnBoard Soundchips aller anderen Boards per Alsa angesteuert wird und sein Signal einfach nur durch passende interne Verschaltung an den HDMI Ausgang weitergibt?

Gruß
Frank

Zitat

Original von fnu

Razorblade

Danke für die Info, aber gleich die Gegenfrage. Wird beim ION zur Tonausgabe wirklich die Grafikkarte genommen, wie es bei einer GF Einsteckkarte oder OnBoard Unit genommen werden sollte?

Oder ist es nicht eher so, das sich auf ION Board ein Sound Chip nach "Intel HD" Spezifikation befindet der wie OnBoard Soundchips aller anderen Boards per Alsa angesteuert wird und sein Signal einfach nur durch passende interne Verschaltung an den HDMI Ausgang weitergibt?

Gruß
Frank

Alles anzeigen

ja genau so denke ich das auch

unter also ist es auch nur eine weitere soundkarte