[SoftHdDevice] PIP Picture in Picture Hilfe/Diskussion

Zitat von rudirabbit

Also ein erster kurzer worst case Test (2x 1080i) schaut mit der GT430 gut aus.

ist schon witzig: bis gestern galt ne GT430 also oversized, jetzt sind die jungs die vorher belächelt wurden wieder ganz weit vorn

Christian

Zitat von CKone

ist schon witzig: bis gestern galt ne GT430 also oversized,

Na ja, die PIP-Funktion über softhddevice ist ja nur eine weitere Möglichkeit ein vernünftiges PIP darzustellen.
Für alle, mit weniger starker GPU ist die Lösung mit einer 2. VDR-Instanz, die in yaVDR implementiert ist, einfach perfekt.
Die yaVDR-PIP-Funktion funktioniert wirklich einwandfrei mit allen SD- und HD- und auch HD+Sendern!
Eine einfache und geniale Lösung, die die yaVDR-Entwickler hier geschaffen haben.

Paulaner

Zitat von Paulaner

Na ja, die PIP-Funktion über softhddevice ist ja nur eine weitere Möglichkeit ein vernünftiges PIP darzustellen.
Für alle, mit weniger starker GPU ist die Lösung mit einer 2. VDR-Instanz, die in yaVDR implementiert ist, einfach perfekt.
Die yaVDR-PIP-Funktion funktioniert wirklich einwandfrei mit allen SD- und HD- und auch HD+Sendern!
Eine einfache und geniale Lösung, die die yaVDR-Entwickler hier geschaffen haben.

Danke für die Blumen, aber ich kann jetzt nicht erkennen warum unsere Lösung signifikant weniger Resourcen verbrauchen sollte als Johns PIP. Das sollte sogar eher mehr sein. Ich würde doch annehmen wenn unser PIP bei dir zufriedenstellend läuft, dann sollte es mit Johns Lösung auch keine Probleme geben. Hast du es selbst probiert und schlechte Erfahrungen damit gemacht?

Gerald

Zitat von CKone

ist schon witzig: bis gestern galt ne GT430 also oversized, jetzt sind die jungs die vorher belächelt wurden wieder ganz weit vorn

Christian

Verstehe nicht so ganz wieso die GT430 (GF108\) der GT520/610 (GF119) da so überlegen sein soll. Was das Deinterlacing angeht ist schon klar, da sind die GF108 Chips mit ihrer relativ großen Anzahl an CUDA-Cores und dem breiteren Datenbus dem GF119 überlegen. Wenn es aber ums reine Decoding geht, so glänzt wieder der GF119 mit seiner moderneren Video-Einheit die wohl auch in den aktuellen Kepler GPUs steckt.

Wäre sowas eigentlich machbar?

Compressed Video-Stream (Main) ---> VdpDecoder ---> VdpVideoSurface ---> VdpVideoMixer (temporal)  ---
                                                                                                      |
                                                                                                      |------> VdpOutputSurface ---> ...
                                                                                                      |
Compressed Video-Stream (PIP) ---> VdpDecoder ---> VdpVideoSurface ---> VdpVideoMixer (bob + scale) --

...also wenn PIP aktiv und wenn deaktiviert, dann wieder auf temporal_spatial wechseln?

Zitat von gda

Danke für die Blumen, aber ich kann jetzt nicht erkennen warum unsere Lösung signifikant weniger Resourcen verbrauchen sollte als Johns PIP.

Habe ich mir nur so gedacht, weil hier von potenten Grafikkarten geredet wurde, die für das PIP mit softhddevice notwendig sei.
Denn das yaVDR-PIP hat bei mir auch mit der onboard-Grafik nvidia8300 bestens funktioniert hat, egal ob SD oder HD.

Deswegen bin ich ja auch so begeistert von eurer YaVDR-PIP-Lösung! Die funktioniert wirklich bestens!
Was eben nicht ging war "temporal spatial", sondern maximal "temporal", aber das ist ja eine andere Baustelle!

Paulaner

Funktioniert das ganze jetzt schon einigermaßen stabil? Würds auch gern mal probieren.

IMHO kann man es riskieren. Abstürze hatte ich dadurch keine, wenn man die Grafikkarte mit dem Decodieren überfordert, fängt der Treiber an zu spinnen (insbesondere auf Sendern mit hoher Bitrate), was sich nach einem Reboot aber wieder legt.

Hi,

wenn ich PIP beende, sehe ich immer 2..4 Meldungen über freigegebene, aber nicht verwendete Surfaces:

Jan  7 17:46:18 vdr vdr: (video.c:8120) video: slow down video, duping frame
Jan  7 17:46:18 vdr vdr: (video.c:8125) video: slow down video, duping frame
Jan  7 17:46:18 vdr vdr: (video.c:8171) video: 24:28:51.871  +84  684 240/\ms  23+7 v-buf
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000015, which is not in use
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000016, which is not in use
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000017, which is not in use
Jan  7 17:46:31 vdr vdr: [13641] (thread.c:264) TS buffer on device 1 thread ended (pid=13610, tid=13641)
Jan  7 17:46:31 vdr vdr: [13639] (ringbuffer.c:43) buffer stats: 112236 (2%) used
Jan  7 17:46:31 vdr vdr: [13639] (thread.c:264) receiver on device 1 thread ended (pid=13610, tid=13639)
Jan  7 17:46:36 vdr vdr: [13636] (outputserial.c:650) Aurora: size=5268192, speed=8780 Byte/s

Gruß
e9hack

Anyone have a screenshot of what softhddevice PIP looks like?

Zitat von tecfreak

Verstehe nicht so ganz wieso die GT430 (GF108\) der GT520/610 (GF119) da so überlegen sein soll.

Es wurde in dem Thread auch so herausgearbeitet, und ich habe auch nicht gesagt die GT430 sei besser, da bei den G119 basierenden das Deocding viel schneller ist (Wie du ja auch schon beschreibst)

Ich habe manchmal das Problem, das PIP ein DVB Device blockiert. (Git Version von gestern)
Kann dann z.b wenn PIP aktiv nur auf Kanäle zappen die auf dem selben Transponder liegen.
Schalte ich PIP aus, kann ich auch nicht mehr auf 2 verschiedenen Transpondern aufnehmen und live TV schauen.

Das ganze tritt nur manchmal auf, ich habe bis jetzt nicht festmachen können was ich tun muss um dies zu provozieren.
Ich habe allerdings auch eine Mystique SaTix-S2 Sky Xpress, und verwende demzufolge auch andere Treiber als die meisten hier, ob es daran liegt ?

Zitat

Anyone have a screenshot of what softhddevice PIP looks like?

Upps, das ist jetzt aber ein bisschen mickrig, geht das auch größer das PIP?

Gerald

Natürlich, du kannst es nach Belieben positionieren und skalieren.

OT:

rudirabbit
Ich meinte eigentlich CKone damit.
Bin aber grad am überlegen, ob ich mir nicht die GT640 holen soll - Da hat man die Stärken der GF108 und der GF119 in einer GPU und damit hoffentlich erstmal Ruhe...

Zitat von tecfreak

Bin aber grad am überlegen, ob ich mir nicht die GT640 holen soll -

OT: Gibt es die Karte nun als normale PCI_ex , normal doch nur für Notebooks

Zitat von rudirabbit

Thanks for the screenshot rudirabbit. The PIP window is very small but looks like it works. Hopefully it can be scaled and works with VDPAU.

Zitat von jinx

Thanks for the screenshot rudirabbit. The PIP window is very small but looks like it works. Hopefully it can be scaled and works with VDPAU.

Yes you can scale it as you wish.

aktuelles git hat mir beim pip vorhin einen buffer overflow geworfen:

Jan  8 03:58:58 vdr vdr: [2181] ERROR: TS packet not accepted in Transfer Mode
Jan  8 03:58:59 vdr vdr: [2181] ERROR: TS packet not accepted in Transfer Mode
Jan  8 03:58:59 vdr vdr: [2182] ERROR: driver buffer overflow on device 1

Passiert is es, als ich die alternative PIP swap position in die normale gewechselt hatte, kann es aber nicht reproduzieren.
Ansonsten läuft es prima!