Technotrend S2-3200 HDTV-S2

Zitat

Original von rnissl
Hi,

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.

Hi,

das kommt mir auch so vor. Ich habe bei mir wenn ich mit top meine CPU Last anschaue ca. 40% auf einem HDTV Kanal. Aber trotzdem stockt das Bild und hat keinen Ton.

Meine Hardware steht ja im Wiki...sowie auch die Softwareversionen usw...

Auch bei mir ruckelt es bei (nur) ca. 70% Prozessorlast auf einem dual core System (40% total).
Wenn ich in den xine libs in src/xine-engine/video_out.c, Zeile 1192 die Routine
"expire_frames(this,upts); auskommentiere ruckelt nichts mehr!.
Mein Eindruck ist, das xine jede Menge Frames verwirft, weil es mit den pts timestamps nicht einverstanden ist.

Bleibt zu hoffen, dass es wirklich xine ist. Hat überhaupt jemand von Euch irgendein H.264-1080i-File mal flüssig unter Linux zum Laufen bekommen?

Habe einen AMD X2 4200 mit GeForce 8800 am WE nach swen4s Anleitung (1000 Dank!!!) zum Laufen gebracht, aber auch bei mir: Ruckler ohne Ende. Die xvmc-Settings von Reinhard habe ich nicht drin, aber die gelten ja wohl wirklich nur für MPEG2. CPU-Belastung: max. 130%. Auch Aufnahmen direkt mit xine wiedergegeben laufen nicht ruckelfrei, wenn auch etwas besser als Live-TV.
Der Gegencheck heute früh unter Windows mit mplayer-win32: Alles flüssig, auch hier haben die CPUs eine Belastung von jeweils rund 50%-70%.

Ich habe Bedenken, dass auch die Grafikkarten-Treiber ein Wörtchen mitreden könnten, denn am Freitag habe ich bei der Einrichtung eines (SD-)VDR wirklich massive Probleme mit einer 8800er gehabt: Angeschlossen an einem Röhren-Monitor war alles in Butter, bei einem TrueHD-LCD jedoch war es weder möglich, die 1920x1080 zu nutzen (geschweige denn über die nvidia-settings auszuwählen), noch war eine performante Nutzung möglich, weil Xorg teilweise eine CPU-Belastung von bis zu 80% anzeigte und das VDR-Menü regelmäßig einfror, das Bild gelegentlich ruckelte. Zugegeben: Mit einer GeForce 7900 ging es, es liegt wohl an der schlechten Unterstützung der neuen Chips.

In unserem Fall ist eine Xorg-CPU-Belastung ja wohl nicht das Problem, aber dennoch traue ich wegen dieser Erfahrungen dem nVidia-Treiber noch den einen oder anderen Bug zu. Ich glaube allerdings, hier in diesem Thread auch jemanden gesehen zu haben, der auch mit einer ATI keinen Erfolg hatte...

Der Tipp von mumpitz ist sehr interessant, kann ihn aber erst heute Abend ausprobieren - hoffe mal, dass es das wirklich ist...

Hi JK1974,
dass Problem mit der Auflösung kenne ich, habe aber nicht rausfinden können, ob es nun der Treiber , X oder Suse? ist. Bin dann wieder zu Ubuntu(vielleicht gehen auch andere Distris) zurück, denn hier kann ich jede Auflösung einstellen. Ist nicht wirklich eine Lösung, aber ich kann damit gut leben

mfg bugfix

Hi,

Zitat

Original von JK1974
Ich habe Bedenken, dass auch die Grafikkarten-Treiber ein Wörtchen mitreden könnten, denn am Freitag habe ich bei der Einrichtung eines (SD-)VDR wirklich massive Probleme mit einer 8800er gehabt: Angeschlossen an einem Röhren-Monitor war alles in Butter, bei einem TrueHD-LCD jedoch war es weder möglich, die 1920x1080 zu nutzen (geschweige denn über die nvidia-settings auszuwählen), noch war eine performante Nutzung möglich, weil Xorg teilweise eine CPU-Belastung von bis zu 80% anzeigte und das VDR-Menü regelmäßig einfror, das Bild gelegentlich ruckelte. Zugegeben: Mit einer GeForce 7900 ging es, es liegt wohl an der schlechten Unterstützung der neuen Chips.

Hast du openSUSE 10.3 verwendet? 10.3 verwendet anscheinend eine xcb basierte libX11, und seit dem Umstieg kann ich xxmc mit libXvMCNVIDIA.so.100.14.19 nicht mehr verwenden, weil es in kürzester Zeit zu Deadlocks innerhalb xcb kommt, obwohl xine nur libX11-Aufrufe (wie auch vorher unter 10.2) macht. Verwende deswegen zur Zeit -V xv.

Bye.

Hi,

ich beziehe mich bei der 80%-Xorg-Geschichte und den Auflösungs-Problemen auf ein Setup mit sidux (Debian sid), die jetzigen HD-Tests sind aber auf einem openSUSE 10.3-Setup.
Du hattest aber ein paar Seiten vorher davon gesprochen, dass Du in irgendeiner Datei den Namen der libXvMCNVIDIA.so eingefügt hast, um xxmc nutzen zu können, und ich wollte anmerken, dass ich das (glücklicherweise) noch nicht probiert habe.

Bin mal gespannt, ob der Tipp von mumpitz bei mir funktioniert, und hoffe, dass hier nicht "Nomen-est-Omen" zutrifft

Bye.

Hi,

Zitat

Original von mumpitz
Auch bei mir ruckelt es bei (nur) ca. 70% Prozessorlast auf einem dual core System (40% total).
Wenn ich in den xine libs in src/xine-engine/video_out.c, Zeile 1192 die Routine
"expire_frames(this,upts); auskommentiere ruckelt nichts mehr!.
Mein Eindruck ist, das xine jede Menge Frames verwirft, weil es mit den pts timestamps nicht einverstanden ist.

Hmm, es könnte vielleicht mit Fields und Frames zusammen hängen. Ich schicke mitunter Fields zum FFmpeg Dekoder, d. h. es entstehen doppelt so viele Images, die xine anzeigen möchte. Womöglich hat aber jedes dieser Images die Dauer eines Frames und nicht nur die Dauer eines Fields, d. h. es muss jedes zweite weggeworfen werden, weil in der Zeitleiste kein Platz mehr dafür da ist.

Hat jemand noch 'ne VDR-Aufnahme von EinsFestival HD rumliegen? Das war 720p und folglich sollten nur Frames vorliegen. Wenn diese Aufnahmen problemlos abspielen, dann haben wir den Grund wohl schon gefunden.

BTW: ich hätte schon 5 Minuten rumliegen, sind aber 389 MB, und meine Kiste ist zu langsam um das in der Praxis zu probieren, und theoretisch ist es halt äufwendig

Bye.

Hi,

Zitat

Original von rnissl
BTW: ich hätte schon 5 Minuten rumliegen, sind aber 389 MB, und meine Kiste ist zu langsam um das in der Praxis zu probieren, und theoretisch ist es halt äufwendig

Es hat mir keine Ruhe gelassen. Das Problem scheint in der Anbindung von FFmpeg zu liegen. Irgendwie ist die Dauer eines Frames unbekannt. Dann nimmt xine-lib später 25 Frames Per Second an, was natürlich bei der Zuspielung mit 50 FPS zu obigen Problemen führt.

Oh je, jetzt muss ich mich schon wieder da reinwühlen, obwohl ich doch das gar nicht machen will

Bye.

Arghhhhh ...

Fuer alle die, die keinen Ton bei den HD-Sendern haben: Schaltet mal im
DVB-Menue den Dolby-Digital Ton ein

Gruss,
elgreco

PS: Habe jetzt auch einen smp-Kernel fuer meinen Core Duo gebastelt und
siehe da, ich bekomme auch top-Werte von > 100% ...

So, wieder ein paar Tests gemacht

Der Hinweis von mumpitz hat tatsächlich etwas gebracht, flüssig lief es hier aber dennoch nicht, weder live, noch bei der direkten Wiedergabe des Files.
Und bezüglich mplayer-Wiedergabe unter Windows habe ich etwas geschummelt: Habe eine TS-Aufzeichnung, erstellt mit dem Windows-TV-Tool DVBViewer, wiedergegeben - eigentlich um in erster Linie zu testen, ob die Performance meines Systems für das Software-Decoding ausreicht.

Und jetzt eine überraschender Gegentest: Ich habe das TS-File unter Linux mit dem kompilierten xine wiedergegeben, und siehe da: Es läuft nahezu flüssig. "Nahezu" bedeutet hier, dass es kleinere Darstellungsfehler gibt, vielleicht wegen Problemne mit dem TS-Container - es gibt diese Fehlermeldungen:

[h264 @ 0xb66ee2f0]error while decoding MB 113 59, bytestream (-4)
[h264 @ 0xb66ee2f0]concealing 1016 DC, 1016 AC, 1016 MV errors
[h264 @ 0xb66ee2f0]error while decoding MB 115 59, bytestream (-6)
[h264 @ 0xb66ee2f0]concealing 1014 DC, 1014 AC, 1014 MV errors
[h264 @ 0xb66ee2f0]error while decoding MB 112 59, bytestream (-7)

Das gedemuxte Videofile lässt sich leider nicht mit xine wiedergeben (oder ich kenne den passenden Parameter nicht), ansonsten hätten wir den Beweis, dass irgendetwas mit dem Datenstrom, der an xine geschickt wird, tatsächlich nicht stimmt.

rnissl: Beispielfile(s) kann ich zur Verfügung stellen, auch auf zwei EinsFestival-Aufnahmen habe ich Zugriff, aber nur im DVBViewer-TS-Format. Könnte auch Deine VDR-Aufnahme testen, Details zum Dateiaustausch ggf. per PN

Hi,

Zitat

Original von rnissl
Oh je, jetzt muss ich mich schon wieder da reinwühlen, obwohl ich doch das gar nicht machen will

Kann mal jemand folgenden Hack ausprobieren:

diff -r 5d6c41c7070c src/libffmpeg/ff_video_decoder.c
--- a/src/libffmpeg/ff_video_decoder.c  Mon Oct 22 00:39:56 2007 +0200
+++ b/src/libffmpeg/ff_video_decoder.c  Mon Oct 22 20:50:22 2007 +0200
@@ -539,7 +539,7 @@ static int ff_handle_mpeg_sequence(ff_vi
     xine_event_send(this->stream, &event);
   }
   this->video_step = this->mpeg_parser->frame_duration;
-
+fprintf(stderr, "E video_step: %d\n", this->video_step);
   return 1;
 }


@@ -1076,7 +1076,7 @@ static void ff_handle_mpeg12_buffer (ff_


       img->crop_right  = this->crop_right;
       img->crop_bottom = this->crop_bottom;
-
+fprintf(stderr, "A img->duration: %.3lf ms\n", img->duration / 90.0);
       this->skipframes = img->draw(img, this->stream);


       if(free_img)
@@ -1095,6 +1095,7 @@ static void ff_handle_mpeg12_buffer (ff_
         img->pts       = 0;
         img->duration  = this->video_step;
         img->bad_frame = 1;
+fprintf(stderr, "B img->duration: %.3lf ms\n", img->duration / 90.0);
         this->skipframes = img->draw(img, this->stream);
         img->free(img);
       }
@@ -1195,7 +1196,8 @@ static void ff_handle_buffer (ff_video_d
           }
         }
       }
-
+fprintf(stderr, "this->context->time_base: %.6lf\n", av_q2d(this->context->time_base));
+this->video_step = (int)(90000 * av_q2d(this->context->time_base));
       /* aspect ratio provided by ffmpeg, override previous setting */
       if ((this->aspect_ratio_prio < 2) &&
          av_cmp_q(this->context->sample_aspect_ratio, avr00)) {
@@ -1298,7 +1300,10 @@ static void ff_handle_buffer (ff_video_d


         img->crop_right  = this->crop_right;
         img->crop_bottom = this->crop_bottom;
-
+fprintf(stderr, "this->av_frame->interlaced_frame: %d\n", this->av_frame->interlaced_frame);
+if (this->av_frame->interlaced_frame)
+  img->duration /= 2;
+fprintf(stderr, "C img->duration: %.3lf ms\n", img->duration / 90.0);
         this->skipframes = img->draw(img, this->stream);


         if(free_img)
@@ -1320,6 +1325,7 @@ static void ff_handle_buffer (ff_video_d


       img->duration  = this->video_step;
       img->bad_frame = 1;
+fprintf(stderr, "D img->duration: %.3lf ms\n", img->duration / 90.0);
       this->skipframes = img->draw(img, this->stream);
       img->free(img);
     }
@@ -1334,6 +1340,7 @@ static void ff_decode_data (video_decode


   if (buf->decoder_flags & BUF_FLAG_FRAMERATE) {
     this->video_step = buf->decoder_info[0];
+fprintf(stderr, "F video_step: %d\n", this->video_step);
     _x_stream_info_set(this->stream, XINE_STREAM_INFO_FRAME_DURATION, this->video_step);
   }

Es wird nun die Dauer eines Frames aus dem Stream ausgelesen (time_base) und bei Interlace-Material halbiert in das xine-Image eingetragen. Damit müsste das Zeitverhalten eigentlich passen.

Kann das aber bei mir nicht testen, da meine Kiste grundsätzlich zu langsam dafür ist.

Bye.

Super, Reinhard, bin begeistert - aber bitte noch nicht zu früh freuen

Die gute Nachricht:
Astra HD funktioniert hier jetzt (anscheinend) flüssig (mit deaktiviertem Deinterlacer)!!!

this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 0
C img->duration: 40.000 ms
this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 0
C img->duration: 40.000 ms
this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 0
C img->duration: 40.000 ms
this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 0

Und jetzt leider die negativen Punkte:
Erstens: Bei ProSiebenHD, Sat.1HD und AnixeHD ruckelt es (wohl je nach Material) mal weniger und mal mehr, und wenn Letzteres über längere Zeit hinweg der Fall ist, bleibt xine irgendwann stehen:

this->context->time_base: 0.040000
D img->duration: 40.000 ms
this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 1
C img->duration: 20.000 ms
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
this->context->time_base: 0.040000
D img->duration: 40.000 ms
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented
this->context->time_base: 0.040000
this->av_frame->interlaced_frame: 1
C img->duration: 20.000 ms
this->context->time_base: 0.040000

Und der Zweite: Leider gab's beim Patch ein paar Rejects, wohl wegen Copy & Paste. Kannst Du den Patch evtl. nochmal für andere als File einfügen (ich müsste im Gegensatz zu Dir erst nachschlagen, wie man ein korrektes diff erstellt - brauche ich als Enduser nicht so oft :))

P.S.: Bin auch vom RTL-Problem betroffen...

Zitat

Original von rnissl
Hi,

Es wird nun die Dauer eines Frames aus dem Stream ausgelesen (time_base) und bei Interlace-Material halbiert in das xine-Image eingetragen. Damit müsste das Zeitverhalten eigentlich passen.

Kann das aber bei mir nicht testen, da meine Kiste grundsätzlich zu langsam dafür ist.

Bye.

Alles anzeigen

ich habe die relevanten zeilen gerade per Hand eingetragen (patch klappte irgendwie nicht). Alles funktioniert prima. Kein ruckeln mehr.
Bei einem hochgetakteten core2 doppelprozessor mit 3.2 GHz bekomme ich eine Last von 70-75% fuer xine und total etwas <40%.

Vielen Dank fuer den schnellen patch!

mumpitz:

Wie sieht die Performance bei den Nicht-Astra-HD-Sendern aus? Bekommst Du auch Meldungen wie die von mir beschriebenen? Von wann ist Deine ffmpeg-Version (ich habe wie in der Anleitung beschrieben die vom 18.10. genommen)?
Und noch etwas: Irgendwie scheinen die Deinterlacer bei mir nicht oder nur schlecht zu funktionieren - ich sehe immer noch Kamm-Artefakte. Habe es sowohl über -D als auch über das GUI probiert.

@rnissel

Zitat

Kann das aber bei mir nicht testen, da meine Kiste grundsätzlich zu langsam dafür ist.

Hast Du schon mal mit den verschiedenen -lavdopts (beim MPlayer) gespielt?

-lavdopts skiploopfilter=all:skipframe=nonref:fast:threads=2:lowres=1

...sollte theoretisch die geringste CPU Last verursachen. Leider klappt bei mir die lowres Option nicht

JK1974

Zitat

[h264 @ 0xb66da2f0]Interlaced pictures + spatial direct mode is not implemented

... da klemmts halt noch beim ffmpeg-support!

BTW, wie betreibt man denn Xine ohne Xv support? Selbst wenn ich -V x11 angebe, crasht mir xine weg

Gruß, ollo

Hi,

Zitat

Original von ollo
BTW, wie betreibt man denn Xine ohne Xv support? Selbst wenn ich -V x11 angebe, crasht mir xine weg

Tja, xine --help listet für -V ja auch kein x11 auf

Probier mal -V xshm.

Ein großes Problem ist, dass xine nicht meckert, wenn man was angibt, das es nicht gibt. --verbose=2 könnte helfen, herauszufinden, welchen Ausgabetreiber xine tatsächlich verwendet hat.

Bye.

Der Patch hats gebracht. Mit meinem Core2Duo e6300 @2GHz laufen die HD-Kanäle abgesehen von den FFmpeg-Interlaced-Problemen absolut flüssig bei ca. 60% Prozessorauslastung. Vielen Dank Reinhard.

Gehen bei Euren Core2Duos also auch ProSieben/Sat1HD und AnixeHD trotz der Fehlermeldungen flüssig?

Zitat

Original von JK1974
mumpitz:

Wie sieht die Performance bei den Nicht-Astra-HD-Sendern aus? Bekommst Du auch Meldungen wie die von mir beschriebenen? Von wann ist Deine ffmpeg-Version (ich habe wie in der Anleitung beschrieben die vom 18.10. genommen)?
Und noch etwas: Irgendwie scheinen die Deinterlacer bei mir nicht oder nur schlecht zu funktionieren - ich sehe immer noch Kamm-Artefakte. Habe es sowohl über -D als auch über das GUI probiert.

ich bin aktuell unterwegs und kann erst am Freitag weiter testen. Meine ffmpeg
Version ist von gestern (kann man ja schnell mit "svn update" aktualisieren).
Beim Deinterlacer bin ich mir nicht sicher, es scheint zumindest mit -D besser zu
sein.
Insgesamt ist das System aus den unterschiedlichsten Gründen noch etwas
instabil, Abstürze von xine beim vor- zurückspringen in Aufnahmen, der Kanalwechsel
dauert manchmal sehr lange oder geht gar nicht. ffmpeg reagiert auf defekte stream etwas empfindlich, unterstützt auch noch nicht alle h264 features, ca. alle 2 Min. stockt das Bild für 2 sec etc.
Aber kommt Zeit kommt hd...

Hi,

Zitat

Original von mumpitz
Insgesamt ist das System aus den unterschiedlichsten Gründen noch etwas
instabil, Abstürze von xine beim vor- zurückspringen in Aufnahmen, der Kanalwechsel
dauert manchmal sehr lange oder geht gar nicht. ffmpeg reagiert auf defekte stream etwas empfindlich, unterstützt auch noch nicht alle h264 features, ca. alle 2 Min. stockt das Bild für 2 sec etc.

Kanalwechsel (vorallem von H.264 zurück nach MPEG2) sollte sich in vdr-xine-0.8.0 verbessert haben. Obiger Hack ist mittlerweile in xine-lib-1.2 eingeflossen.

Bye.