You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

61

Saturday, August 25th 2012, 8:24pm

G220 schlechter als GT430... ? Eher nicht :


Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
NVIDIA GPU GeForce GT 220 (GT216) at PCI:1:0:0 (GPU-0)
VDPAU API version : 1
VDPAU implementation :
NVIDIA VDPAU Driver Shared Library 195.30 Fri Dec 18 17:11:08 PST 2009

SURFACE GET BITS: 772.668 M/s
SURFACE PUT BITS: 820.283 M/s

MPEG DECODING (1920x1080): 72 frames/s
MPEG DECODING (1280x720): 163 frames/s
H264 DECODING (1920x1080): 66 frames/s
H264 DECODING (1280x720): 138 frames/s
VC1 DECODING (1440x1080): 48 frames/s
MPEG4 DECODING (1920x1080): 72 frames/s

MIXER WEAVE (1920x1080): 1056 frames/s
MIXER BOB (1920x1080): 1790 fields/s
MIXER TEMPORAL (1920x1080): 480 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 316 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 640 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 177 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 146 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 195 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 626 fields/s
MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 295 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 72 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 370 fields/s

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
NVIDIA GPU GeForce GT 430 (GF108) at PCI:1:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library 290.10 Wed Nov 16
18:06:51 PST 2011

SURFACE GET BITS: 979.277 M/s
SURFACE PUT BITS: 1091.96 M/s

MPEG DECODING (1920x1080): 107 frames/s
MPEG DECODING (1280x720): 239 frames/s
H264 DECODING (1920x1080): 65 frames/s
H264 DECODING (1280x720): 135 frames/s
VC1 DECODING (1440x1080): 83 frames/s
MPEG4 DECODING (1920x1080): 72 frames/s

MIXER WEAVE (1920x1080): 232 frames/s
MIXER BOB (1920x1080): 329 fields/s
MIXER TEMPORAL (1920x1080): 148 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 127 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 186 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 76 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 68 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 84 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 222 fields/s
MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 145
fields/s

MULTITHREADED MPEG DECODING (1920x1080): 107 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 138 fields/s


Das du mit der GT220 keine Probleme mehr hast, wundert mich nicht. Hättes du auch in Kombi mit deinem alten Sockel 775 System nicht mehr gehabt.
Das Problem liegt nicht an der Hardware. Der ION schafft laut vdpautest mit temporal + ship-chroma rund 160 fields/sec. Das reicht hardwaremäßig voll kommend aus.


Gruß
Oc86
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

rudirabbit

Professional

Posts: 1,352

Occupation: Kfz Elektroniker

  • Send private message

62

Sunday, August 26th 2012, 7:49am

Hmm,
Einen vdpau Vergleich test habe ich nicht gemacht, von den Technischen Daten her sollte die GT430 die bessere sein 8o
Die vdpau Werte sagen aber was anderes :wow
Man lernt nie aus.

Die GT220 war vorher in dem 775 System und damit gab es definitv Ruckler.
Allerdings ist dieser Vergleich auch schon wieder nicht aussagekräftig, da damals eine ältere Version von softhddevice installiert war.

Es braucht anscheinend deutlich bessere Werte als 160 fields/sec um keine Ruckler zu haben.
Dann wird wohl doch unnötig Zeit in der Software verbraten.
VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

63

Sunday, August 26th 2012, 10:26pm

Die Frage ist wo kommt der Fehler her: Sender -> Tv-Karte -> Kernel -> Vdr -> Plugin?

Ich habe mit der GT 430 auch ein paar "render too slow" im Log, die kommen immer nach einem Kanalwechsel,
und liegen zwischen 30ms - 500ms.

Die GPU/Treiber braucht also eine gewisse Zeit die Fehler zuverkraften.

Puffer sind schon vorhanden und können kleinere Fehler korrigieren.
Ein Problem sind die längeren Hänger, wo man einfach die Puffer mal leeren muß
um wieder in den Takt zukommen. Aber die 3s Pause kann man fast nicht verhindern.

Eine weiter Möglichkeit wäre, wenn der Mpeg/H264 Parser Fehler erkennt und VDPAU
besser ansteuert, so daß es keine Pause geben.

Da die Probleme aber nur vereinzelt auftreten, lohnt sich im Moment der Aufwand nicht.

Johns
Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
Sag mir, wo die Developer sind. Was ist geschehn?

Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
Server0: Dockstar TT-S2-3600-USB / streamdev
Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

Posts: 5,291

Location: Main-Spessart

  • Send private message

64

Sunday, August 26th 2012, 10:36pm

Speziell stelle ich diese Fehler bei HD+ fest. Kann es evtl. auch senderabhängig sein? Evtl. kommen durch einen der beiden Software CAM Plugins auch ein paar Puffer durcheinander.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

65

Monday, August 27th 2012, 5:31pm

hab hier noch ein interessantes log: Auf einen HD+ Serber habe ich nach einem decoder render too slow, haufenweise slow down/speed up video hintereinander. Endet dann an einem driver buffer overflow an der Sat-Karte:

http://pastebin.com/LKBk4UJ0


Kannst du mir vielleicht sagen, warum das Plugin dort zwanghaft versucht ein bestimmten Video-Audio Abstand(bzgl. Zeitstempel) zu erzwingen. Anders kann ich mir dass nicht erklären.


Gruß

Oc86
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

66

Monday, August 27th 2012, 6:07pm

Zu den längeren Hängern:
Wenn man in einem eigenem Thread einen Wächter für den Decoder laufen lässt, und sobald dieser länger als z.B. 40 ms (am besten konfigurierbar) hängt, den Decoder neu initialisiert, dann müsste das eigentlich ruck-zuck gehen.
Selbst wenn man vorsichtshalber auf neue Daten im Stream wartet, dauert das bei 15 Bildern bis der Decoder los läuft bei 720p50 bzw. 1080i25 nur 15 x 20 bzw. 40 ms = 300 bzw. 600 ms zusätzlich.
Oder übersehe ich was?

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

rudirabbit

Professional

Posts: 1,352

Occupation: Kfz Elektroniker

  • Send private message

67

Monday, August 27th 2012, 6:54pm

Speziell stelle ich diese Fehler bei HD+ fest.
Ich auch.
Es ist schon Senderabhängig - HD+ und Sky beide 1080i bei Sky kaum Probleme bei HD+ schon öfter.
HD+ hat laut femon höhere Datenraten als SKY HD.

Der Vorschlag von jrie hört sich gut an - wenn sich dies realisieren lässt ?
VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

68

Monday, August 27th 2012, 8:17pm

[vdr] video: slow down video, duping frame_

Mein LCD-TV läuft mit 60Hz, also muss im SoftHDdevice 60Hz enabled werden, dann sind zumindest weniger solcher Meldungen im Log.
Gelegentlich habe ich allerdings noch einige dazwischen.
Weiß nicht genau, ob das gemeint war ...?

astra
[Haupt-VDR] ....... Gen2vdr-V4, vdr-2.0.2, softhddevice, AsRock H77 Pro4-M, Zotac GeForce GT 630 ZONE Edition, V4L-Cine-S2-V6.5, TT-FF-S2-6400 (Tuners only), URC 7140 @ CIR
[VDR-2] ............... Gen2vdr-V3(32bit)-V4-Scripts mixed ;), vdr-2.0.2, softhddevice, Biostar Viotech 3100+, Skystar S2, URC 7140
[Bastel-Projekt] .. Cubietruck (vdr auf Arm-Architektur), Software wechselt ständig

69

Monday, August 27th 2012, 10:02pm

hab hier noch ein interessantes log: Auf einen HD+ Serber habe ich nach einem decoder render too slow, haufenweise slow down/speed up video hintereinander. Endet dann an einem driver buffer overflow an der Sat-Karte:

http://pastebin.com/LKBk4UJ0


Kannst du mir vielleicht sagen, warum das Plugin dort zwanghaft versucht ein bestimmten Video-Audio Abstand(bzgl. Zeitstempel) zu erzwingen. Anders kann ich mir dass nicht erklären.


Wie bereits weiter oben beschrieben, versucht das Plugin den Ton welcher ja weiterläuft wieder einzuholen.
Dazu werden nicht alle Frames ausgeben. Da dies im Normalfall nur kurze Verzögerungen sind, klappt es dort gut.
Leider scheint der ION auf diese Reglung wieder mit Verzögerungen zu reagieren oder es sind neue Störungen.

Ganz klar sind mir diese

Source code

1
2
3
4
Aug 27 17:02:20 HTPC vdr: video: speed up video, droping frame
Aug 27 17:02:20 HTPC vdr: video:  9:17:09.864  -16  334   0/\ms  25 v-buf
Aug 27 17:02:20 HTPC vdr: video: slow down video, duping frame
Aug 27 17:02:20 HTPC vdr: video:  9:17:09.984  +45  331   0/\ms  23 v-buf

+-60ms Schwankungen nicht. Kann aber durch die Verminderung der Debugausgaben kommen, da werden mehrere drop bzw. dup zusammengefasst.

Zu den längeren Hängern:
Wenn man in einem eigenem Thread einen Wächter für den Decoder laufen lässt, und sobald dieser länger als z.B. 40 ms (am besten konfigurierbar) hängt, den Decoder neu initialisiert, dann müsste das eigentlich ruck-zuck gehen.
Selbst wenn man vorsichtshalber auf neue Daten im Stream wartet, dauert das bei 15 Bildern bis der Decoder los läuft bei 720p50 bzw. 1080i25 nur 15 x 20 bzw. 40 ms = 300 bzw. 600 ms zusätzlich.
Oder übersehe ich was?


Ja, die 600ms blockiert der NVidia Treiber, solange kann der Dekoder auch nicht neugestartet werden.

Ich würde erstmal herausfinden, woran es liegt und dann die Ursachen abstellen und nicht an den Symptomen herumdoktern.
Also ich habe mal 24 Stunden Test mit "ServusTV HD Oesterreich" am laufen, mit GT430 keine Probleme, nun läuft er mit der GT210
und bisher auch keine Probleme.

Source code

1
2
3
Aug 27 21:48:02 e35lm1 vdr: video:  9:10:33.901  +33 1139   0/\ms  49 v-buf
Aug 27 21:49:02 e35lm1 vdr: video:  9:11:33.901   -2 1107   0/\ms  46 v-buf
Aug 27 21:50:02 e35lm1 vdr: video:  9:12:33.901  +33 1138   0/\ms  46 v-buf


Hin und wieder ist diese 35ms Schwankung drin.

Johns
Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
Sag mir, wo die Developer sind. Was ist geschehn?

Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
Server0: Dockstar TT-S2-3600-USB / streamdev
Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

Posts: 5,291

Location: Main-Spessart

  • Send private message

70

Monday, August 27th 2012, 10:33pm

Probiere es bitte mit Prosieben HD. Dort habe ich es öfter bei schnellen Szenenwechseln
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

71

Monday, August 27th 2012, 11:27pm

@johns Welchen nvidia Treiber benutzt du zum testen? 295.59? 304.43?

Mit meiner 8400GS hatte ich viel mehr Hänger als mit der G210. Mehr Gpu Power scheint zu helfen. Und auf arg Cpu schwachen Rechnern auch mehr Cpu Power.

@Oc86: Mit dem 260er nvidia Treiber kann man sich die GPU Auslastung anzeigen lassen (nvidia-smi -q -a -l).
Wär mal interessant, wie sehr dein Ion ausgelastet ist.
Was sagt die letzte Spalte von "sar -u 1 1000" bei deinem Atom, wenn du z.B. eine Aufnahme laufen lässt und mit grün und gelb schnell hin und her springst? Irgendwie glaube ich nicht an 20% maximale Last.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

72

Tuesday, August 28th 2012, 8:31am

Probiere es bitte mit Prosieben HD. Dort habe ich es öfter bei schnellen Szenenwechseln
Oder Sky Sport HD. Ich hatte gestern Nacht meine htpc auf Servus TV Deutschland laufen lassen. 5 Stunden lang hatte ich kein einzigen decoder too slow. Nachher verabschiedet sich meine SAT Karte mit einem buffer overflow.

@jrie: Hier mal ein Auszug von sar, als ich Sky Sport HD guckte:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
CPU %user %nice %system %iowait %steal %idle
08:06:46 all 2,24 0,50 0,75 0,00 0,00 96,51
08:06:47 all 3,51 0,00 1,00 0,00 0,00 95,49
08:06:48 all 4,25 0,25 1,50 1,00 0,00 93,00
08:06:49 all 4,00 0,25 1,00 0,00 0,00 94,75
08:06:50 all 3,75 0,00 1,50 0,00 0,00 94,75
08:06:51 all 4,25 0,25 1,75 0,00 0,00 93,75
[color=#ff0000]08:06:52 all 4,25 0,25 17,00 0,00 0,00 78,50[/color]
08:06:53 all 3,25 0,25 1,25 0,00 0,00 95,25
08:06:54 all 4,51 0,25 1,25 1,00 0,00 92,98
08:06:55 all 2,75 0,00 1,25 0,00 0,00 96,00
08:06:56 all 3,49 0,25 1,25 0,00 0,00 95,01


An der rot gekennzeichnete Zeile hatte ich ein decoder too slow mit etwa 500ms. Ob die zusätzliche CPU-LAST mit dem Error-Handling in Verbindung steht.. Keine Ahnung....
Das mit der GPU-Auslastung muss ich mir mal nachher angucken.

Gruß

Oc86
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

This post has been edited 1 times, last edit by "Oc86" (Aug 28th 2012, 9:26am)


73

Tuesday, August 28th 2012, 10:10am

Ok, dann ist deine Cpu Auslastung ok. Bei xine liegt der Anstieg am Error handling, bei softhddevice weiss ich es nicht, aber ist ja anhand des Logs zu vermuten. Mit beinahe 80% frei ist das aber noch kein Problem.

Dass Hänger, die an Stream Fehlern liegen, reproduzierbar an der selben Stelle auftreten ist klar. Interessanter wäre, was mit Hängern ist, die ohne Stream Fehler auftreten.
Du könntest also auch mal testen, ob Hänger, die nicht an Stream Fehlern liegen, bei dir immer an der selben Stelle auftreten. Also in deiner Aufnahme wäre das der Fehler bei 21:20:45 + 47, falls ich richtig gerechnet habe. Also einfach dreimal durchlaufen lassen und die Logs posten (möglichst inklusive Startzeit).

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

74

Tuesday, August 28th 2012, 12:07pm

@jrie: bei der Wiedergabe der Aufnahmen habe ich an der genannten Stelle keine Rückler. Siehe hierzu den Log:

http://pastebin.com/xg4HfMUp



Grüße

Oc86
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

75

Tuesday, August 28th 2012, 1:03pm

Also falls du tatsächlich über die fragliche Stelle (Post 57) ohne Hänger kommst, bei der du im früheren Log einen Hänger hattest, dann sind diese Hänger (ohne Stream Fehler) doch nicht reproduzierbar. Aber für mich ohne mehrmals laufen lassen mit kompletten Log nicht wirklich nachvollziehbar.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

76

Tuesday, August 28th 2012, 4:47pm

Ich habe noch eine weitere Aufnahme gemacht, bei dem ich zwei Rückler hatte :

http://ossi01.freeunix.net/vdr2.rar


Hier findet man die Log der Aufnahme: http://pastebin.com/FfuqzhEu

Laut TS-Doctor hat diese Aufnahme aber keine Fehler. Die Rückler sind aber hier bei der Wiedergabe der Aufnahme reproduzierbar. Machen Sie dann wieder mit einem decoder too slow im log bemerkbar.

Grüße

Oc86

Edit: Bitte bevorzugt diesen Mirror benutzen: https://www.rapidshare.com/#!download|31…vdr2.rar|681522
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

This post has been edited 1 times, last edit by "Oc86" (Aug 29th 2012, 5:44pm)


77

Tuesday, August 28th 2012, 7:26pm

Probiere es bitte mit Prosieben HD. Dort habe ich es öfter bei schnellen Szenenwechseln


Habe ich leider nicht.

Gibt neue Version im GIT, diese loggt noch die gepufferten Ausgabe Frames.

Source code

1
Aug 28 19:19:15 vdr vdr: video:  4:08:56.424  +24  490   0/\ms  31+6 v-buf


+6 v-buf sind 6 Videoframes. Kann sein daß die Schwankungen durch Falschberechnungen kommen.
Bei Interlace werden mindestens 4 Frames benötigt. 8 ist max für interlaced und 4 für Progressive.

Und die Probleme mit dem "render too slow" können auch durch "duping"/"droping" kommen.

Johns
Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
Sag mir, wo die Developer sind. Was ist geschehn?

Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
Server0: Dockstar TT-S2-3600-USB / streamdev
Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

78

Wednesday, August 29th 2012, 10:45am

@Johns
Eine Bitte: würdest du bitte bei der "render too slow" Ausgabe auch die PTS mit ausgeben?
Vorteil: Wenn man vergleichen will, wo bei einer Aufnahme Hänger auftreten, sieht man sofort, ob es sich um dieselbe Stelle handelt.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

79

Wednesday, August 29th 2012, 11:31am

@johns: Mit der neuen Version aus dem GIT habe ich mal einen Test auf Sky Sport HD gemacht. Hier ist das Log dazu:


http://pastebin.com/sVzfRUBp


Die gepufferten Frames liegen immer zwischen 5 und 7 Frames.(zumeist auf 6 Videoframes) Für mich sieht es aus, als würde die "render too slow" durch "duping"/"droping" kommen. Was sagst du dazu?




Grüße


Oc86
Zotac D2550-ITX Wifi Supreme | 1*2GB | Technisat SkyStar 2 eXpress HD | 320gb WD Blue | yaVDR 0.5

80

Wednesday, August 29th 2012, 2:05pm

Die Aufnahme von Oc86 aus Post 77 ist sehr interessant!
Bei wiederholtem Abspielen bekomme ich mit dem 195.30 keinerlei "render too slow" und auch xine zeigt keine Fehler.
Mit dem 295.59 und dem 260.19.44 bekomme ich jedes Mal mit softhddevice "render too slow" und auch häufig "missed frame"s. Diese liegen oft an denselben Stellen, aber nicht jedes Mal. In der Aufnahme sind das die Stellen ca. 5:47, 4:17, 3:06 und 1:59.
Auch xine wirft manchmal Frames weg, aber nicht immer und seltener.
Die Gpu Last mit meiner G210 lag mit dem 260er bei 80% (xine) bzw. 86% (softhddevice).

Es wäre sehr spannend, wie das auf anderer Hardware aussieht und ob das auch für andere „wahrscheinlich reproduzierbar“ ist.

Seit über 2 Jahren hat niemand das Hänger Problem mit einer bestimmten Aufnahme reproduzieren können (VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?). Vielleicht hilft diese Aufnahme weiter(?)
Da nvidia mit mplayer testet, ist die Frage, was beim Abspielen mit mplayer passiert. Hierzu ist der patch mplayer_watchdog.patch.bz2 aus http://www.nvnews.net/vbulletin/showpost…651&postcount=7 hilfreich.
Ich bekomme bei mir mit gepatchtem mplayer und 295.59 oder 304.37 folgendes:

Source code

1
2
3
4
5
========== vdp_decoder_render() returned after 85.102 ms ==========
call 9260

========== vdp_decoder_render() returned after 40.688 ms ==========
call 17308

Der bei 9260 kommt bisher immer. Das dürfte dem bei 3:06 entsprechen.
Mit dem 195.30 gibt es diese Meldungen in mplayer nicht (195.30 braucht für call 9260 nur 8ms(!), das sieht man, wenn man im patch 35 durch 1 ersetzt).

Falls das von genügend Leuten hier bestätigt wird, werde ich das bei nvidia posten.
Allerdings ist eine Verzögerung von 85ms bei 1080i25 nicht sichtbar, das sind gerade mal etwas mehr als 2 Frames und wird abgepuffert.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.22 + BER/UNC-Patch für stv090x, nvidia 343.22, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

This post has been edited 1 times, last edit by "jrie" (Aug 29th 2012, 4:37pm)