Technotrend S2-3200 HDTV-S2

... mein Reden

ehm, könnte es sein das mit dem neuen Treibern die Skystar HD nicht mehr geht???
dmesg:

[   38.556981] stb0899_attach: STB0899 PLL Unlocked!
[   38.557000] budget-ci: A frontend driver was not found for device 1131/7146 subsystem 13c2/1019

oder brauch ich da neuerdings wieder ein paar patches?

Edit: Die Treiber von 12.10 gehen noch!

Hallo bugfix3k,

ja, geht nicht mehr.
Werde mal Manu fragen wozu das gut ist.

bis dann Lordzodiac

Hi LordZodiac,
danke für deine Antwort, dachte schon das Problem sitzt vorm Rechner...

mfg bugfix

... der hier ist wohl der Übeltäter.

Gruß, ollo

Hallo,

die Änderung ist wieder raus.

bis dann LordZodiac

Danke, werde es heute abend mal probieren...

Hallo.

Ich habe mich auch mal an DVB-S2 versucht. Grundlage war die Installationsanleitung im
Wiki - vielen Dank dafuer - einzig dass mein unterliegendes Systen nicht OpenSuse ist,
sondern easyVdr 0.5ß4.

Leider haben bei mir die HD-Sender - bis auf Astra HD - keinen Ton, die SD-Sender funktionieren alle.
Per Fernzugriff ueber das streamdev-Plugin ist Ton da (VLC beendet sich zwar wegen fehlender
PAFF-Unterstuetzung ziemlich schnell, aber um zu hoehren ob Ton da ist, reicht es).

Die HD-Sender sehen schon toll aus, aber ohne Ton fehlt irgendwie etwas
Woran kann das liegen?

Gruss & Danke,
elgreco

PS: Das ganze laueft auf einem ASUS P5B-VM mit onboard Sound (das zugehoerige Modul
ist snd-hda-intel).

Nur mal so geraten: Liba52 fehlt beim config von libxine oder ffmpeg?

Hi,

Zitat

Original von elgreco
Die HD-Sender sehen schon toll aus, aber ohne Ton fehlt irgendwie etwas
Woran kann das liegen?

Vermutlich ist der Rechner zu langsam. Hast wohl auch jede Menge

video_out: Verwerfe Bild mit pts 326795390, weil es zu alt ist (Unterschied: 482712).

Meldungen (ggf. --verbose=2 angeben).

Hast du schon multithreaded decoding aktiviert (in xine-ui's Einstellungen-Dialog, Reiter Video, ganz unten, mindestens 2 einstellen).?

Bye.

Mit Xine geht es auch bei mir eher stockend. Während, wie schon berichtet, der selbstkompilierte MPlayer unter Win32 zumindest progressives Material und in letzter Zeit merkwürdigerweise auch Pro7 ruckelfrei wiedergibt, gibt es bei Xine eher ein "Stop-Motion-Show".
Da Top bei h264-Sendern eine Prozessorauslastung zwischen 120 und 140% auwirft (ja, Zweikernprozessoren können was, die liegen weit über 100% :)), gehe ich mal davon aus, dass zwei FFmpeg-Threads laufen.
Andererseits gab der Test mir endlich mal eine gute Gelegenheit, mir mal wieder einen Linux-Desktop einzurichten, von dem ich, von der enttäuschenden Xine-Performance mal abgesehen, bisher restlos begeistert bin.

Hi,

Zitat

Original von udobroemme
Mit Xine geht es auch bei mir eher stockend. Während, wie schon berichtet, der selbstkompilierte MPlayer unter Win32 zumindest progressives Material und in letzter Zeit merkwürdigerweise auch Pro7 ruckelfrei wiedergibt, gibt es bei Xine eher ein "Stop-Motion-Show".
Da Top bei h264-Sendern eine Prozessorauslastung zwischen 120 und 140% auwirft (ja, Zweikernprozessoren können was, die liegen weit über 100% :)), gehe ich mal davon aus, dass zwei FFmpeg-Threads laufen.
Andererseits gab der Test mir endlich mal eine gute Gelegenheit, mir mal wieder einen Linux-Desktop einzurichten, von dem ich, von der enttäuschenden Xine-Performance mal abgesehen, bisher restlos begeistert bin.

Bei mir zeigt top für xine Werte > 160 % an (für den Sender ASTRA HD). Verwende derzeit -V xv und keinen Deinterlacer.

Bitte auch mit --verbose=2 kontrollieren, ob wirklich video_out_xv zur Anwendung kommt. xine meckert nicht, wenn es das angegebene Modul nicht findet und verwendet womöglich video_out_opengl oder video_out_xshm. Sonst hinkt der Vergleich mit mplayer, wenn unterschiedliche Ausgabetreiber verwendet werden.

Bye.

Zitat

Original von rnissl
Hi,

Bei mir zeigt top für xine Werte > 160 % an (für den Sender ASTRA HD). Verwende derzeit -V xv und keinen Deinterlacer.

Bitte auch mit --verbose=2 kontrollieren, ob wirklich video_out_xv zur Anwendung kommt. xine meckert nicht, wenn es das angegebene Modul nicht findet und verwendet womöglich video_out_opengl oder video_out_xshm. Sonst hinkt der Vergleich mit mplayer, wenn unterschiedliche Ausgabetreiber verwendet werden.

Bye.

Alles anzeigen

Ich habe das jetzt nochmal mit expliziter Angabe des xv- und des xxmc-Treibers getestet (ich habe eine Nvidia 7600GT-Grafikkarte mit den neuesten Nvidia-Treibern im Einsatz). Diese werden laut Xine-Log auch verwendet. Deinterlacing und Postprocessing sind deaktiviert. Das Bild ruckelt...

Hi,

Zitat

Original von udobroemme
Ich habe das jetzt nochmal mit expliziter Angabe des xv- und des xxmc-Treibers getestet (ich habe eine Nvidia 7600GT-Grafikkarte mit den neuesten Nvidia-Treibern im Einsatz). Diese werden laut Xine-Log auch verwendet. Deinterlacing und Postprocessing sind deaktiviert. Das Bild ruckelt...

Hmm, ist dies bei Live-TV der Fall?
Wie ist es, wenn eine Aufnahme abgespielt wird?
Und wie ist es, wenn die Aufnahme direkt mit xine (d. h. ohne VDR und vdr-xine) abgespielt wird?

Für letzteres: xine ... /path/to/001.vdr#demux:mpeg_pes

Bitte auch --post vdr_video verwenden und folgende Änderung in xine-lib einkompilieren:

diff -r ffb350dd93b7 src/vdr/post_vdr_video.c
--- a/src/vdr/post_vdr_video.c  Tue Oct 16 21:41:21 2007 +0200
+++ b/src/vdr/post_vdr_video.c  Sun Oct 21 13:11:51 2007 +0200
@@ -458,6 +458,13 @@ static int vdr_video_draw(vo_frame_t *fr
     frame->next->pts = 0;
   }
 */
+  {
+    int a = 0, b = 0, c = 0, d = 0;
+    if (stream)
+      _x_query_buffer_usage(stream, &a, &b, &c, &d);
+    fprintf(stderr, "buffer usage: %3d, %2d, %2d, %2d, %p\n", a, b, c, d, stream);
+  }
+
   if (!this->enabled
       || frame->bad_frame
       || (frame->format != XINE_IMGFMT_YUY2

Das gibt dann die Füllstände von xine-lib's FIFOs an und zwar VideoInput, AudioInput, VideoOutput, AudioOutput. VideoOutput sollte für eine flüssige Wiedergabe dabei nicht unter 3 fallen.

Bye.

Eine Aufnahme (ich gehe jetzt mal nicht darauf ein, woher ich sie habe) mit progressivem Material ruckelt auch, egal ob im vdr oder direkt mit Xine abgespielt. Mit dem o.a. Patch findet sich im Log:
buffer usage: 498, 0, 4, 0, 0x8395ef0
buffer usage: 498, 0, 5, 0, 0x8395ef0
buffer usage: 498, 0, 3, 0, 0x8395ef0

Diese Ausgabe wiederholt sich dann immer.

Hi,

Zitat

Original von udobroemme
Eine Aufnahme (ich gehe jetzt mal nicht darauf ein, woher ich sie habe) mit progressivem Material ruckelt auch, egal ob im vdr oder direkt mit Xine abgespielt. Mit dem o.a. Patch findet sich im Log:
buffer usage: 498, 0, 4, 0, 0x8395ef0
buffer usage: 498, 0, 5, 0, 0x8395ef0
buffer usage: 498, 0, 3, 0, 0x8395ef0

Diese Ausgabe wiederholt sich dann immer.

Tja, habe gerade mal eine aufgearbeitete ASTRA HD Aufnahme mit mplayer abgespielt. Vorallem mit

-lavdopts threads=2

ist es deutlich schneller als mit xine. Aber wie gesagt, in mplayers Statuszeile stehen bei mir bis auf wenige Ausnahmen Werte > 100% d. h. die Kiste ist nicht schnell genug und mplayer verwirft keine Frames.

Obwohl mplayer FFmpeg verwendet, wird der Code von FFmpeg aber mit eigenen Optionen übersetzt. Es sieht so aus, als würde mplayer von sich aus Optionen wählen, die optimal zum Zielsystem passen (-O4 -march=native -mtune=native), während FFmpeg ohne weiteren Angaben nur allgemein optimierten Code erzeugt. Evtl. mal folgende Optionen für FFmpegs configure angeben:

--arch=i686 --cpu=pentium4

oder

--arch=i686 --cpu=native

Unterstüzte Argumente für --arch finden sich in configure bei der Suche nach

case "$arch" in

Trotz allem sieht es wohl so aus, als wäre FFmpeg in xine-lib nicht so effizient angebunden wie es in mplayer der Fall ist.

Bye.

Die Compileroptimierungen hatte ich bei FFmpeg schon angegeben.
Grundsätzlich ist es ja auch kein Problem, dass es noch nicht hinhaut. Wie schon zuvor geschrieben mangelt es mir eh noch an einem entsprechenden Ausgabegerät, so dass momentan nur der sportliche Ehrgeiz da ist, HDTV nur mit Opensource-Komponenten zum Laufen zu bringen. Die übrigen VDR-Komponenten funktionieren trotz VDR-Developer-Version einfach zu gut, als dass sie meinen Basteltrieb ausreichend befriedigen könnten

@rnisssl:
Funktioniert der TT3200-Treiber bei Dir jetzt eigentlich besser? Ich habe auf der DVB-Mailingliste gesehen, dass Du Probleme mit dem RTL-Transponer hast. Ich hatte übrigens anfänglich auch Tuning-Probleme, die aber dann verschwanden, als ich den PCI-Slot gewechselt hatte.

ich wollte auch mal meinen Senf dazugeben
bei mir siehts so aus und ruckelt trotzdem ordentlich

buffer usage: 498,  0,  9, 14, 0x9e54c0
buffer usage: 498,  0, 10, 14, 0x9e54c0
buffer usage: 498,  0, 11, 14, 0x9e54c0
buffer usage: 498,  0,  9, 15, 0x9e54c0
buffer usage: 498,  0, 10, 15, 0x9e54c0
buffer usage: 498,  0, 11, 15, 0x9e54c0

Also bei einem Wert von 14-15 sollte es wohl daran nicht liegen oder?

Hiho,

kurz zu den tuning problemen bei rtl. die hatte ich auch .. habe gestern aber die treiber neu geholt aus dem hg und seit dem gehts wieder ...

bis denne mentox

Hallo.

Ich habe immer noch kein Ton bei den HD-Sendern (nur bei Astra HD). Die
liba52 ist vorhanden und auch bei config von ffmpeg mit angegeben. Bei der
xinelib nicht, da stand irgend etwas von "Benutzung externer a52dec nicht
ratsam".

Vielleicht ist mein Rechner wirklich zu langsam - ich habe einen Intel E6600,
d.h. ein Core 2 Duo mit 2 x 2.4Ghz - ich finde den aber so langsam nicht.
Apropos, merkt Linux automatisch, dass ein zweiter Kern da ist - ich habe
bei xine noch nie top-Werte von ueber 100% gesehen, eher 60%-95%
bei Astra HD und < 10% bein Das Erste & Co.?

Ich habe auch mal versucht, xine als Streaming Client zu verwenden, dann
kommt bei den HD-Senden Ton (!), aber kein fluessiges Bild ...

Bzgl. der Fuellstaende der xinelib FIFOs, bekomme ich an der ersten und
dritten Stelle, d.h. fuer AudioIn- und Output, immer eine 0 bei den HD-Sendern
(ausser bei Astra HD). Hat das etwas zu sagen?

Gruss,
elgreco