Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1 261

Freitag, 1. April 2011, 12:18

Quoted from "Maniac"
Die Option --hud=opengl nutzt, im Gegensatz zur Option --opengl, ein Window(kein opengl) zu darstellen solange kein OSD sichtbar ist. Erst wenn man ein OSD öffnet, wird das Bild in eine Pixmap umgeleitet. Dafür wird an xine ein drawable_changed gesendet und xine wechselt dann auf die Pixmap.
Leider mag das aber vdpau so noch nicht gerne.

Grade noch mal ausprobiert. Funktioniert hier seit 30 minuten auch relativ problemlos (kein segfault mehr wie bei meinem letzten Versuch vor einigen Tagen). Speziell bei den ÖR HD-Sendern kommt es beim Menüaufruf allerdings manchmal zu 1-2 Sekunden Bildstörung.
Da es anscheinend Senderabhängig ist und vermutlich mit der Datenrate zusammenhängt, (bei dir die ÖR die ja gute Datenraten haben, ich hab bis jetzt immer auf einem HD-Sender getestet), kam mir die Vermutung das dies eventuell damit zusammenhängt das irgendwas nicht Threadsafe ist.
Dabei bin ich dann auch gleich auf die Zeile 2130 im xine_sxfe_frontend.c gestossen. Dort wird XINE_VISUAL_TYPE_X11 benutzt welches wohl nicht Threadsafe ist, XINE_VISUAL_TYPE_XCB soll Threadsafe sein.
Da ich nicht weiß wann und ob ich heute zum testen komme, bitte mal jemand testen die entsprechende Zeile so abzuändern:

Quellcode

1
this->x.xine_visual_type = XINE_VISUAL_TYPE_XCB;

1 262

Samstag, 2. April 2011, 02:32

keine "dropped frames" mehr beim Abspielen von Aufnahmen mit diesem patch

Mit diesem patch wird man die Meldungen
video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy)
die man mit xine --verbose=2 beim Abspielen von HD Aufnahmen mit vdpau sieht los.
Der patch sorgt dafür, dass der Cpu Peak viel kürzer und kleiner wird. Dies war vor allem auf langsamen Systemen ein Problem, insbesondere bei höherer Last. Auf schnellen Systemen ist es vermutlich nicht besonders störend aufgefallen.
Die ganze Geschichte mit allen Details steht hier.

Ich bitte alle Tester um Feedback.
»jrie« hat folgende Datei angehängt:
  • dvbplayer.c.diff (1,83 kB - 66 mal heruntergeladen - zuletzt: 14. August 2016, 22:04)

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 42.2 64bit, Kernel 4.4.36 mit dddvb 0.9.26, nvidia 375.20, vdr 2.2.0 mit Patchen (checkts, naludump, statusleds, ...)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »jrie« (2. April 2011, 13:03)


1 263

Sonntag, 3. April 2011, 11:07

df-xine-lib-extensions-patch v23

Hallo,

auf vdr-developer.org steht version 23 des extensions patch bereit. Der OSD Patch im vdpau ist entfallen da es damit
auf langsamen Systemen Probleme gibt.

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1 264

Sonntag, 3. April 2011, 12:58

@durchflieger: Bedeutet das im Umkehrschluss, dass man den OSD-Patch auf schnelleren Systemen problemlos nutzen kann oder ist dort dann auch it anderen Problemen zu rechnen?

1 265

Montag, 4. April 2011, 20:53

Jetzt wollte ich gerade mal testen obs mit XINE_VISUAL_TYPE_XCB einen Unterschied macht, also erstmal aktuelle xine-lib neu gebaut (einmal mit df-Patch einmal ohne) und xineliboutput (mit Bugfix für opengl) neugebaut.

Allerdings funktioniert es schon ohne Änderung des Visual Type nicht mehr mit --hud=opengl. Wenn ich das OSD öffnen will hält einfach das Bild an und kurz danach kommt fifo buffer full. Es hilft dann nur noch ein Neustart von vdr-sxfe.

Edit: Das hängt anscheind mit dem Wert bei video.output.vdpau_display_queue_length zusammen.
2 = das fifo buffer full verhalten
3 = meistens kein OSD aber auch keine Meldungen
8 = preemption callback

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Maniac« (4. April 2011, 21:01)


1 266

Montag, 4. April 2011, 23:10

schon mal das probiert?

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 42.2 64bit, Kernel 4.4.36 mit dddvb 0.9.26, nvidia 375.20, vdr 2.2.0 mit Patchen (checkts, naludump, statusleds, ...)

1 267

Dienstag, 5. April 2011, 08:26

Ja, ist im aktuellen df-Patch mit drin. Ich will jetzt mal versuchen den Stand zu finden, bei dem es immer gewechselt hat von Window auf Pixmap, aber halt der preemption callback aufgetreten ist.
Ich glaube das war ca. zu der Zeit bevor der OSD-Patch wieder rausgenommen wurde.

1 268

Dienstag, 12. April 2011, 21:20

im moment läuft das xine-plugin bombenfest mit aktueller libxine.
leider bietet das shq eine merkwürdige sache ... das osd wird der videogrösse angepasst ;(
das sieht recht merkwürdig aus.

vdr-sxfe (git aktuell) getestet geht hier leider nichts mehr, läuft das bei euch ??
ich bekomm damit nur das :

Quellcode

1
2
3
4
5
Apr 12 21:08:50 zotac-natty vdr: [3250] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
Apr 12 21:08:55 zotac-natty vdr: last message repeated 1000 times
Apr 12 21:08:55 zotac-natty vdr: [3250] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
Apr 12 21:08:55 zotac-natty vdr: [3250] [xine..put] cXinelibServer::Play Write/Queue error (TCP/PIPE)
Apr 12 21:08:55 zotac-natty vdr: [3250] [xine..put] Closing connection 0


die config ist dabei die "gleiche" wie beim xine-plugin bzgl. puffer

1 269

Mittwoch, 13. April 2011, 07:12

eine merkwürdige sache ... das osd wird der videogrösse angepasst

siehe hier...

Gruß
iNOB

Mein VDR

Hartware: Gehäuse: Ahanix MCE 302, Mobo: Kontron 986LCD-M/mITX, CPU: Intel Core2 Duo Mobile T7400 2,16GHz, 2GB RAM, SAT: Digital Devices DuoFlex S2 miniPCIe, Graka: ASUS GeForce GT 730 ( GK208 ) Silent, 4x4TB 3,5" WD Red HD, 1x DVD-Brenner Pioneer, Atric IR-Einschalter+Empfänger, FB One-For-All URC-7960, SoundGraph iMON LCD ( MFP5I, 15c2:0038 )
Weichware: Jessie (x86_64), Kernel 3.16, NVidia v364.19, VDR 2.2.0 gepatched

1 270

Mittwoch, 13. April 2011, 09:51

Alternativer "vdpau h264 decoder"

hallo,

@durchflieger: sorry für's "hijacking" - dachte mir aber, daß es in diesen thread am besten passt (geht eh gleich wieder unter :) )

crisalide (=xine developer) hat einen neuen verbesserten vdpau h264 decoder für die aktuelle xine-lib-1.2 veröffentlicht. er liegt als patch unter: http://hftom.homelinux.org/tmp/alter_vdpau-2.diff

hier geht's zum originalen "announcement": http://www.nvnews.net/vbulletin/showthre…563#post2417563

gruß, ciax:

btw: neuer "stable" (official prerelease) 270.41.03 nvidia-treiber wurde gestern auch veröffentlicht (allerdings mit wenig neuem)
Lascala LC17 - tribute to viking ;o) + atric IR / AMD X2 BE-2400 / OctopusNet S4 / yavdr-(testing) vdr / output: graphTFT-fe via 6.4" TFT & DVB-S/S2 via FullHD / NVidia GT220 passiv

1 271

Mittwoch, 13. April 2011, 10:36

leider bietet das shq eine merkwürdige sache ... das osd wird der videogrösse angepasst ;(

Der Modus heißt ja auch "Einpassen", means scaling, hier wählbar in verschiedenen Qualitätsstufen, wobei SHQ das "Beste" sein soll.

Soll aber jeder selber urteilen, ob das S(uper)H(igh)Q(uality) ist, wenn er das Einpassen des OSDs auf einem der Musiksender gesehen hat, vor allem wenn auch noch der Autocrop zugeschlagen hat ... :(

SHQ ist für mich nur der Overlay Modus, der mit den letzten Version(en) leider nicht mehr funktioniert, warum auch immer ...

Regards
fnu
>> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610T, 2x1GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, CIR, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 35W)
[²] Modu CD21, MeanWell (80W)/PicoPSU (90W), Futaba MDM166A, ASRock Q1900M, 2x1GB DDR3, Intel 320 SSD 40GB, WD10JFCX, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, mceusb, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 22W)
[³] HP ProLiant ML10 v2, Xeon E3-1225v3, 2x8GB DDR3 ECC, Intel 320 SSD 120GB (Sys & HostCache), HPVSA B120i, HPSA P420 256MB BBWC, 4x WD7500BPKX, 5x WD1003FBYX, VMWare ESXi 6.0 (6 VM)(x64, 48W)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »fnu« (13. April 2011, 10:58)


1 272

Mittwoch, 13. April 2011, 10:39

ja fnu, ich hab endlich kapiert was du meinst :D
und du hast schon recht, schade das es nur mit einpassen geht.
schöner wäre das mit osd-grösse = tv bildgrösse
für was gibt es das einpassen überhaupt ?

1 273

Mittwoch, 13. April 2011, 11:09

ja fnu, ich hab endlich kapiert was du meinst :D

Meinst Du vielleicht eher schmerzvoll selbst erfahren ... ?

für was gibt es das einpassen überhaupt ?

Evtl. Altlast? Aber wenn man es anders kennt, eben SHQ@Overlay(X11), ist das noch nicht mal schade, das geht irgendwie gar nicht und ärgert mich mal wieder, das ich nicht das Talent habe hier was zu "bewirken" ...
>> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610T, 2x1GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, CIR, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 35W)
[²] Modu CD21, MeanWell (80W)/PicoPSU (90W), Futaba MDM166A, ASRock Q1900M, 2x1GB DDR3, Intel 320 SSD 40GB, WD10JFCX, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, mceusb, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 22W)
[³] HP ProLiant ML10 v2, Xeon E3-1225v3, 2x8GB DDR3 ECC, Intel 320 SSD 120GB (Sys & HostCache), HPVSA B120i, HPSA P420 256MB BBWC, 4x WD7500BPKX, 5x WD1003FBYX, VMWare ESXi 6.0 (6 VM)(x64, 48W)

1 274

Mittwoch, 13. April 2011, 16:14

Neuer Branch df-osd-handling

Hallo,

auf vdr-developer.org habe ich für die xine-lib-1.2 einen neuen Branch 'df-osd-handling' commited.
Dieser Branch enthält den überarbeiteten OSD-Handling Patch für den vdpau Ausgabetreiber.
Bei mit funktioniert damit die X11-Overlayausgabe im vdr-xine-plugin wieder vernüftig (allerdings nur getestet gegen vdr 1.7.16).

Weiterhin hoffe ich nun, dass der Patch auf "schwacher" vdpau Hardware jetzt nicht mehr schlechtere Ergebnisse liefert. Dass
kann ich allerdings nicht testen.

Interresant wäre auch ob der Patch die erwartete Darstellung bei den verschiedenen OSD Betriebsmodis der xine und xineliboutput plugins liefert,
z.B. im Vergleich zum xv Ausgabetreiber.
Das alles zu testen ist mir im augenblick einfach zu aufwendig und ich hoffe auf eure Hilfe.

Hier die Beschreibung zum Patch:

Zitat

Complete rewrite of vdpau output driver osd handling.
The new implementation has the following advantages towards the existing one:
There is now a unique processing of RLE coded images and ARGB based overlay images.
For both formats scaled and unscaled images and a video window are supported.
Both formats are rendered now in given order into the same output surface not using
a dedicated output surface for scaled, unscaled and ARGB images any more.
Processing of YCBCR overlay images now uses corresponding vdpau upload functions
eliminating the existing (possible slower) conversation to RGB images.
Optimized processing of first overlay from stack avoiding unnecessary surface initialization and rendering operations.
Currently the new implementation does only take the dirty rect information of a ARGB overlay into account for optimization
if this is the only one object that should be displayed.

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1 275

Mittwoch, 13. April 2011, 17:50

hallo,

@durchflieger: sorry für's "hijacking" - dachte mir aber, daß es in diesen thread am besten passt (geht eh gleich wieder unter :) )

crisalide (=xine developer) hat einen neuen verbesserten vdpau h264 decoder für die aktuelle xine-lib-1.2 veröffentlicht. er liegt als patch unter: http://hftom.homelinux.org/tmp/alter_vdpau-2.diff

hier geht's zum originalen "announcement": http://www.nvnews.net/vbulletin/showthre…563#post2417563

gruß, ciax:

btw: neuer "stable" (official prerelease) 270.41.03 nvidia-treiber wurde gestern auch veröffentlicht (allerdings mit wenig neuem)

Hallo,

ich habe mal einen neuen Thread dazu angelegt.
klick mich
Gruss Björn.

mein System


-- P4 Dual-Core (E5300), 2 x TT-1600, GigaByte GA-E7AUM-DS2H, 2 x 640 GB Samsung, 16 GB SSD --
-- OpenSuse 11.4, v4l-dvb, vdr 2.2.0 mit softhddevice, nvidia 270.26 --


SilverGreen-Skin

1 276

Mittwoch, 13. April 2011, 18:06

Nabend,

die grosse Frage ist jetzt, wie man den neuen Vdpau-h264-Decoder mit den df-Patches verheiratet?

Gibt es da große Differenzen? => dann wäre das natürlich wieder eine große Patchorgie, wenn es überhaupt geht?

Eventuell kann ja Durchflieger dass mal Zusammenführen/Anschauen, gerne auch in einem seperaten Branch.

Gruß
Wolfgang
Hardware: -
Software: -

1 277

Mittwoch, 13. April 2011, 18:33

So wie es aussieht wäre nur der Profiling Changeset betroffen, beim kurzen drüber gucken konnte ich da auf Anhieb nichts anderes finden.

1 278

Mittwoch, 13. April 2011, 18:45

Neuer Branch 'df-osd-handling+alter-vdpau-h264-decoder' ist commited!

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1 279

Mittwoch, 13. April 2011, 18:48

Neuer Branch 'df-osd-handling+alter-vdpau-h264-decoder' ist commited!

Gruss
durchflieger
Na dann sage ich mal fettes Danke!

Gruß
Wolfgang
Hardware: -
Software: -

1 280

Mittwoch, 13. April 2011, 19:22

Mann das geht ja schneller als man schauen kann!

Vielen Dank!
iNOB

Mein VDR

Hartware: Gehäuse: Ahanix MCE 302, Mobo: Kontron 986LCD-M/mITX, CPU: Intel Core2 Duo Mobile T7400 2,16GHz, 2GB RAM, SAT: Digital Devices DuoFlex S2 miniPCIe, Graka: ASUS GeForce GT 730 ( GK208 ) Silent, 4x4TB 3,5" WD Red HD, 1x DVD-Brenner Pioneer, Atric IR-Einschalter+Empfänger, FB One-For-All URC-7960, SoundGraph iMON LCD ( MFP5I, 15c2:0038 )
Weichware: Jessie (x86_64), Kernel 3.16, NVidia v364.19, VDR 2.2.0 gepatched

Immortal Romance Spielautomat