softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin

johns · 5. März 2012

Zitat von rudirabbit

Hallo, Ich will das Thema "decoder render too slow" nochmals aufgreifen.

Im Log sind sie aber selten noch drin.

Nachtrag:
Dies gerade im Log, vor dem "decoder render too slow" war ein "empty video packet 115 bytes" hängt dies zusammen, bzw kann dies die Ursache sein ?

Immer wenn der Hardware Dekoder aus dem Tritt kommt kann es passieren.
Also nach dem Umschalten oder wegen dem "empty" Packet. Wobei da genau eine Frame fehlt.
Ich könnte mal probieren ob die "leeren" packete nicht doch gebraucht werden und diese zum Dekoder weiterleiten.
Oder es sind Reste von Fehlern im VDR (du benutzt ja kein streamdev?).

Zitat von Samael

Da ich das bei mir zuhause produktiv einsetze und das auch bei den
von mir "Betreuten" tun möchte, ist mir soeben ein Problem aufgefallen.
Bei einem Anlernprozess für Fernbedienung / Tastatur,
die remote.conf ist also nicht vorhanden, bleibt der Bildschirm dunkel
und das Anlernen läuft irgendwann in den Timeout. Man müßte den Anlernprozess
quasi im Blindflug erledigen, wobei man eigentlich nicht mal weiß,
daß dieser gerade aktiv ist (Git-Stand 01.03.).

Zudem wird das Log bei Benutzung der Grab-Funktionalität mit

"zugemüllt", wobei zumindest hier mit VDPAU das Skaling wunderbar funktioniert.
johns: Magst du diese Ausgaben (zumindest für VDPAU) rausnehmen?

Alles anzeigen

Ich habe den ersten Punkt ins Todo aufgenommen, sprich so schnell keine Lust zum Suchen.
Der zweite ist im GIT rausgenommen.

Johns

Samael · 5. März 2012

johns: Super, vielen Dank.

Dann mache ich nachher zwischen den Timern mal ein Update :).

Samael

CafeDelMar · 5. März 2012

Hallo johns,

leider kann ich es erst nächste Woche testen, aber bei Nutzung von Xine muss ich ALSA folgende Parameter übergeben, da ansonsten der Dekoder im verwendeten Boxenset nicht korrekt arbeitet:

Bei Passthrough: AES0=0x06,CARD=1
Dies nagelt den Ton für den Dekoder als zu dekodierenden Datenstrom, sprich AC3, fest.
Alle anderen: AES0=0x04,CARD=1
Dies nagelt den Ton für den Dekoder als Audio, sprich nicht zu dekodieren, fest.

Eventuell geht das ja schon bei Deinem Plugin oder das Flag wird eh schon von Deinem Plugin gesetzt (schadet ja auch nicht), ansonsten wäre es super bzw. für mich absolut notwendig, dass dies mit eingebaut werden würde. Test folgt so oder so innerhalb der nächsten Woche.

CafeDelMar

BTW: Es heißt "Paket" und nicht "Packet" im Deutschen, nur als Hinweis.

CKone · 5. März 2012

Zitat von Samael

johns: Super, vielen Dank.

Dann mache ich nachher zwischen den Timern mal ein Update :).

Samael

genauso hab ichs gerade gemacht, und das log sieht gleich besser aus.

Christian

ciax · 5. März 2012

Zitat von rudirabbit

ciax : wie ich in deinen Logs sehe, hast du auch dieses Problem (und viel extremer als ich).
Was für einen Nvidia Treiber verwendest du ? Welche Linux Distrie ? (Oder ist deine Sig Aktuell)

ich merk da gar nicht so die beeinträchtigungen (mykroruckler,audio,...). die sig ist aktuell, so ziemlich ..

das mit den xorg.conf parametern müßte ich noch austesten - vllt. sieht's im log dann besser aus .. ich "grep" mal auf "empty video packet 115 bytes".

//edit:

Code

Mar  4 20:46:29 pvr vdr: video/vdpau: decoder render too slow 140 ms
Mar  4 20:47:54 pvr vdr: [softhddev] empty video packet 731 bytes
Mar  4 20:48:15 pvr vdr: video/vdpau: decoder render too slow 87 ms
Mar  4 20:48:15 pvr vdr: video/vdpau: decoder render too slow 87 ms
Mar  4 20:48:24 pvr vdr: [softhddev] empty video packet 579 bytes
Mar  4 20:48:58 pvr vdr: video/vdpau: decoder render too slow 41 ms
Mar  4 20:48:58 pvr vdr: video/vdpau: decoder render too slow 40 ms
Mar  4 20:51:15 pvr vdr: video/vdpau: decoder render too slow 80 ms
Mar  4 20:51:15 pvr vdr: video/vdpau: decoder render too slow 66 ms
Mar  4 20:51:51 pvr vdr: video/vdpau: decoder render too slow 36 ms
Mar  4 20:52:01 pvr vdr: video/vdpau: decoder render too slow 55 ms
Mar  4 20:53:34 pvr vdr: video/vdpau: decoder render too slow 90 ms
Mar  4 20:53:34 pvr vdr: video/vdpau: decoder render too slow 96 ms
Mar  4 20:54:25 pvr vdr: [softhddev] empty video packet 63 bytes
Mar  4 20:54:58 pvr vdr: [softhddev] empty video packet 223 bytes
Mar  4 20:55:30 pvr vdr: video/vdpau: decoder render too slow 102 ms

Alles anzeigen

//

.. ist jetzt auch wieder 23:08, johns "macht kurze pause" .. im git ist jetzt wieder ruhe (-->
Revision d6c6818e). update

ciax

Copperhead · 5. März 2012

Zitat von johns

Immer wenn der Hardware Dekoder aus dem Tritt kommt kann es passieren.
Also nach dem Umschalten oder wegen dem "empty" Packet. Wobei da genau eine Frame fehlt.
Ich könnte mal probieren ob die "leeren" packete nicht doch gebraucht werden und diese zum Dekoder weiterleiten.
Oder es sind Reste von Fehlern im VDR (du benutzt ja kein streamdev?).

Also ich habe diese Meldungen auch und ich benutze kein streamdev.

ciax · 5. März 2012

Zitat von Copperhead

Also ich habe diese Meldungen auch und ich benutze kein streamdev.

.. hier ist streamdev-server aktiv. client ist nur sporadisch aktiv / ohne softhddev ..

rudirabbit · 6. März 2012

Zitat von ciax

ich "grep" mal auf "empty video packet 115 bytes".

grep mal auf "empty video packet" , es müssen ja nicht immer 115 Bytes sein.
streamdev-server habe ich nicht.
Wobei die Änderungen in der xorg.conf zumindest subjektiv was gebracht haben - evtl. ist es nur ein placebo effekt.
Die xorg.conf Infos sind von dort
Evtl. könnte sich jemand zu Wort melden, der sich mit der optimaler config des X-Servers gut auskennt.

johns · 6. März 2012

Zitat von CafeDelMar

leider kann ich es erst nächste Woche testen, aber bei Nutzung von Xine muss ich ALSA folgende Parameter übergeben, da ansonsten der Dekoder im verwendeten Boxenset nicht korrekt arbeitet:

Bei Passthrough: AES0=0x06,CARD=1
Dies nagelt den Ton für den Dekoder als zu dekodierenden Datenstrom, sprich AC3, fest.
Alle anderen: AES0=0x04,CARD=1
Dies nagelt den Ton für den Dekoder als Audio, sprich nicht zu dekodieren, fest.

Eventuell geht das ja schon bei Deinem Plugin oder das Flag wird eh schon von Deinem Plugin gesetzt (schadet ja auch nicht), ansonsten wäre es super bzw. für mich absolut notwendig, dass dies mit eingebaut werden würde. Test folgt so oder so innerhalb der nächsten Woche.

BTW: Es heißt "Paket" und nicht "Packet" im Deutschen, nur als Hinweis.

Alles anzeigen

Also ich habe dafür keinen Support drin, aber ich verhindere es auch nicht.
Ich denke das muß Alsa können, also -p device mit AES String.

Johns

rollercontainer · 6. März 2012

Ich finde diese Thema unheimlich spannend und wollte mir mal eine Testplattform holen. Welche CPU braucht man mindestens?
Johns hat ja den G620, kann man da noch drunter gehen? (Celeron?)

johns · 6. März 2012

Kannst alle Sandy Bridge nehmen. Nur den aller kleinsten Celeron Single Core würde ich nehmen, da da das Energiemangement auch beschnitten wurde.
Ein paar Probleme kommen auf dich zu:

1080i läuft nicht ganz rund
vaapi staging oder vaapi ext (Library + intel Treiber) mußt du aus GIT selber bauen
Qualität etwas (dies ist relativ und Geschmackssache) schlechter als VDPAU

wenn dich das nicht stört ist es ein billiger Test HTPC.

Johns

kaminkehrer · 6. März 2012

Hallo,

Zitat

Ich finde diese Thema unheimlich spannend und wollte mir mal eine Testplattform holen. Welche CPU braucht man mindestens?
Johns hat ja den G620, kann man da noch drunter gehen? (Celeron?)

Meine Testplattform ist eine Activy 300 mit einer 1,1GHZ Celeron CPU und einer Nvidia 8400GS im PCI slot.
Als TV out nutze ich aktuell den VGA mit einer 800x600 Auflösung am alten 19" Monitor.
Ich bin mir aber sicher das das auch mit HD ready Auflösung ganz passabel läuft.

Grüße
kaminkehrer

rollercontainer · 6. März 2012

Ich habe auch einen alten AMD 3800 mit G210 zum testen, aber ich finde die Option ohne GraKa mit onboard HDMI besonders gut. Dann bleiben alle drei Slots (Riser-Gehäuse) für Sat Karten frei (Die G210 wird mir auch viel zu heiß...)

kaminkehrer · 6. März 2012

Hallo,

Zitat

Ich habe auch einen alten AMD 3800 mit G210 zum testen, aber ich finde die Option ohne GraKa mit onboard HDMI besonders gut. Dann bleiben alle drei Slots (Riser-Gehäuse) für Sat Karten frei (Die G210 wird mir auch viel zu heiß...)

Dann sind aus meiner Sicht die IONitx ganz gut. In meiner Signatur kannst Du sehen welche.
Es gibt einige threads von franky, er hat mal ion1 gegen ion2 Plattformen verglichen.
Ich würde die ion mit atom 330 und Geforce 9400 immer wieder kaufen. Wenig Stromverbrauch für ausreichende Leistung.

Wenn du die DVB Karten von DigitalDevices verwendest, kannst Du 4 Tuner an einem PCIe oder mini PCIe nutzen.

Nun wird es hier aber sehr off topic, wenn mehr Details, dann bitte im neuen Thread.

Grüße
kaminkehrer

Copperhead · 6. März 2012

Weil ich jetzt grad sehe, dass du was wegen dem Spulen machst.

Anbei eine Log in der in einer Aufnahme von VOX HD gespult wird. An der Stelle, an der sich die Log "verändert" hängt das Bild dann und der VDR spult nicht mehr.

AV_INFO ist aus, USE_AUDIO_DRIFT_CORRECTION ist an. Sonst ist alles Standard. Während des Tests war das Deinterlacing auf Weave/None und SkipChroma aktiv um maximale Leistung zu erreichen.

ciax · 6. März 2012

so, wieder ein kleines feedback für rev. d6c6818e:

die "decoder render too slow" meldungen hatte ich noch gestern nacht - heute den ganzen tag nicht mehr:

Code

Mar  6 00:27:46 pvr vdr: video/vdpau: decoder render too slow 73 ms
Mar  6 00:27:46 pvr vdr: video/vdpau: decoder render too slow 80 ms
Mar  6 00:30:07 pvr vdr: video/vdpau: decoder render too slow 108 ms
Mar  6 00:30:07 pvr vdr: video/vdpau: decoder render too slow 122 ms
Mar  6 00:32:29 pvr vdr: video/vdpau: decoder render too slow 114 ms
Mar  6 00:32:29 pvr vdr: video/vdpau: decoder render too slow 97 ms
Mar  6 00:34:50 pvr vdr: video/vdpau: decoder render too slow 114 ms
Mar  6 00:34:50 pvr vdr: video/vdpau: decoder render too slow 98 ms
Mar  6 00:37:13 pvr vdr: video/vdpau: decoder render too slow 109 ms
Mar  6 00:37:13 pvr vdr: video/vdpau: decoder render too slow 117 ms
Mar  6 00:39:33 pvr vdr: video/vdpau: decoder render too slow 107 ms
Mar  6 00:39:34 pvr vdr: video/vdpau: decoder render too slow 137 ms

Alles anzeigen

(alsa) underrun einträge sehe ich grundsätzlich nur bei kanalwechsel (und da nicht bei jedem) - ab und zu mal ein eintrag zwischendurch ohne kanalwechsel:

Code

Mar  6 09:40:55 pvr vdr: [1428] switching to channel 7
Mar  6 09:40:57 pvr vdr: [1428] switching to channel 8
Mar  6 09:40:57 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 09:40:58 pvr vdr: [1428] switching to channel 9
Mar  6 09:40:59 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 09:41:05 pvr vdr: [1428] switching to channel 10
Mar  6 09:41:10 pvr vdr: [1428] switching to channel 11
.
.
Mar  6 09:41:26 pvr vdr: [1428] switching to channel 17
Mar  6 09:41:27 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 09:41:35 pvr vdr: [1428] switching to channel 18
Mar  6 09:41:37 pvr vdr: [1428] switching to channel 19
Mar  6 09:41:38 pvr vdr: [1428] switching to channel 18
Mar  6 09:41:39 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 09:42:05 pvr vdr: [1428] switching to channel 19
.
.
Mar  6 09:42:23 pvr vdr: [1428] switching to channel 24
Mar  6 09:42:23 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 10:06:24 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 10:32:22 pvr vdr: [2060] switching to channel 24
Mar  6 10:32:22 pvr vdr: [2060] switching device 3 to channel 8
Mar  6 13:35:24 pvr vdr: [2060] switching to channel 59
Mar  6 13:35:25 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 14:01:35 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  6 14:01:35 pvr vdr: [2060] switching to channel 59
Mar  6 15:07:00 pvr vdr: [2060] switching device 3 to channel 59
Mar  6 16:20:16 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'

Alles anzeigen

"empty video packet":

Code

Mar  6 00:35:43 pvr vdr: [softhddev] empty video packet 815 bytes
Mar  6 01:18:17 pvr vdr: [softhddev] empty video packet 107 bytes
Mar  6 01:19:06 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 01:21:57 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 01:26:39 pvr vdr: [softhddev] empty video packet 131 bytes
Mar  6 01:32:18 pvr vdr: [softhddev] empty video packet 131 bytes
Mar  6 01:37:25 pvr vdr: [softhddev] empty video packet 107 bytes
Mar  6 01:46:28 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 01:46:29 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 01:48:35 pvr vdr: [softhddev] empty video packet 99 bytes
Mar  6 01:53:12 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 01:55:30 pvr vdr: [softhddev] empty video packet 147 bytes
Mar  6 02:00:05 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 02:02:41 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 02:03:48 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 02:29:45 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 02:35:05 pvr vdr: [softhddev] empty video packet 139 bytes
Mar  6 02:46:40 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 02:49:32 pvr vdr: [softhddev] empty video packet 139 bytes
Mar  6 02:57:19 pvr vdr: [softhddev] empty video packet 131 bytes
Mar  6 02:59:23 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 03:01:33 pvr vdr: [softhddev] empty video packet 139 bytes
Mar  6 08:09:30 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 08:18:22 pvr vdr: [softhddev] empty video packet 139 bytes
Mar  6 08:29:06 pvr vdr: [softhddev] empty video packet 131 bytes
Mar  6 08:33:33 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 08:41:35 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 08:41:38 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 08:41:55 pvr vdr: [softhddev] empty video packet 147 bytes
Mar  6 08:49:15 pvr vdr: [softhddev] empty video packet 123 bytes
Mar  6 08:55:38 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 09:13:24 pvr vdr: [softhddev] empty video packet 115 bytes
Mar  6 09:42:03 pvr vdr: [softhddev] empty video packet 139 bytes
Mar  6 12:34:54 pvr vdr: [softhddev] empty video packet 138 bytes

Alles anzeigen

mikroruckler konnte ich hier deshalb keine feststellen - da hat eher mein auge gestern so spät etwas geruckelt. rudirabbit: die parameter habe ich mal in die xorg.conf eingebaut - mal sehen ob's was bewirkt.

alles in allem - ziemlich top. umschaltzeiten sind teilw. recht unterschiedlich - (hängt aber vermtl. von meinen 3 dvb-devices + debug-log ab) - aber trotzdem schnell. noch ein kleines standardlog:

Code

Mar  6 17:30:07 pvr vdr: video: slow down video
Mar  6 17:30:07 pvr vdr: video:  8:57:31.280  +47  730 240/\ms  25 v-buf
Mar  6 17:30:07 pvr vdr: video: speed up video
Mar  6 17:30:07 pvr vdr: video:  8:57:31.320  -15  670 240/\ms  24 v-buf
Mar  6 17:30:07 pvr vdr: video:  8:57:31.340  -15  746 240/\ms  27 v-buf
Mar  6 17:30:07 pvr vdr: video: dropping frame (340/1247386)
Mar  6 17:30:09 pvr vdr: codec/audio: drift(  -288)  	600us   288
Mar  6 17:30:13 pvr vdr: video: slow down video
Mar  6 17:30:13 pvr vdr: video:  8:57:37.360  +68  671 240/\ms  25 v-buf
Mar  6 17:30:15 pvr vdr: video: slow down video
Mar  6 17:30:15 pvr vdr: video:  8:57:39.900  +48  770 240/\ms  24 v-buf
Mar  6 17:30:16 pvr vdr: video: speed up video
Mar  6 17:30:16 pvr vdr: video:  8:57:40.040  -15  710 240/\ms  24 v-buf
Mar  6 17:30:16 pvr vdr: video:  8:57:40.060  -15  690 240/\ms  24 v-buf
Mar  6 17:30:16 pvr vdr: video: dropping frame (341/1247820)
Mar  6 17:30:17 pvr vdr: video: slow down video
Mar  6 17:30:17 pvr vdr: video:  8:57:41.520  +47  687 240/\ms  20 v-buf
Mar  6 17:30:20 pvr vdr: codec/audio: drift(  -288)  	600us   288
Mar  6 17:30:20 pvr vdr: video:  8:57:44.420   +6  768 240/\ms  25 v-buf
Mar  6 17:30:30 pvr vdr: codec/audio: drift(  -298)  	622us   298
Mar  6 17:30:31 pvr vdr: video: slow down video
Mar  6 17:30:31 pvr vdr: video:  8:57:55.880  +49  708 240/\ms  21 v-buf
Mar  6 17:30:40 pvr vdr: codec/audio: drift(  -298)  	622us   298
Mar  6 17:30:50 pvr vdr: codec/audio: drift(  -293)  	611us   293
Mar  6 17:31:00 pvr vdr: codec/audio: drift(  -298)  	622us   298
Mar  6 17:31:10 pvr vdr: codec/audio: drift(  -304)  	633us   304
Mar  6 17:31:20 pvr vdr: codec/audio: drift(  -304)  	633us   304
Mar  6 17:31:20 pvr vdr: video:  8:58:44.400   -4  752 240/\ms  23 v-buf
Mar  6 17:31:30 pvr vdr: codec/audio: drift(  -304)  	633us   304
Mar  6 17:31:40 pvr vdr: codec/audio: drift(  -298)  	622us   298
Mar  6 17:31:50 pvr vdr: codec/audio: drift(  -304)  	633us   304

Alles anzeigen

gruß, ciax

johns · 6. März 2012

Zitat von Copperhead

Weil ich jetzt grad sehe, dass du was wegen dem Spulen machst.

Anbei eine Log in der in einer Aufnahme von VOX HD gespult wird. An der Stelle, an der sich die Log "verändert" hängt das Bild dann und der VDR spult nicht mehr.

AV_INFO ist aus, USE_AUDIO_DRIFT_CORRECTION ist an. Sonst ist alles Standard. Während des Tests war das Deinterlacing auf Weave/None und SkipChroma aktiv um maximale Leistung zu erreichen.

Habe mal etwas mehr Platz gelassen, die "no empty slot in packet ringbuffer" sollten nun weg sein, aber ob das mein Spulen hilft?

Dies trat hier auch auf, wenn man die Schnittmarken zuschnell verschob.

Johns

traxanos · 6. März 2012

johns

kann es sein das beim resume bzw generell ein funktion fähiger kanal benötigt wird beim startup. das osd ist erst sichtbar nachdem ich auf einen sender schalte den ich auch empfangen kann. sonst ist alles schwarz.

Copperhead · 6. März 2012

Zitat von johns

aber ob das mein Spulen hilft?

Ja, das wars. Jetzt wird die Log nur noch mit "display buffer empty, duping frame" und "missed frame" geflutet. Ist das eigentlich normal?

CafeDelMar · 6. März 2012

Zitat von johns

Also ich habe dafür keinen Support drin, aber ich verhindere es auch nicht.
Ich denke das muß Alsa können, also -p device mit AES String.

OK, es war mir nicht klar, dass die "-p" und "-a" Parameter auch zusätzliche ALSA-Parameter schlucken, aber ist ja eigentlich logisch.

Aber wäre es nicht möglich die Ausgabe direkt bei Dolby Digital Passthrough auf "Non-Audio" und bei Stereo auf "Audio" zu "flaggen"? Oder geht das seitens ALSA nicht?
Wenn es gehen sollte, sehe ich hier keinen Nachteil. Im Prinzip wird dadurch das iecset aufgerufen.

CafeDelMar

softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin

Jetzt mitmachen!

Teilen

Tags

Benutzer online in diesem Thema