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.

1

Saturday, June 2nd 2012, 12:55am

[softhddevice] Konfiguration für intel-vaapi?

Hallo,
ich hab jetzt angefangen meinen ersten "richtigen" VDR aufzusetzen und muss feststellen das ich vieles sehr viel schneller hinbekommen habe als gedacht, doch jetzt komme ich nicht mehr weiter:

Mein Fernseher kann leider nur 720p vernünftig, bei nativer Auflösung (1366x768) akzeptiert er nur 60Hz. Habe X.org daher auf 1280x720 50Hz eingerichtet:

Erster Versuch mit vaapi / intel treiber aus Ubuntu 12.04, softhddevice ist immer auf beste Scaling-Qualität und TemporalSpatial-Deinterlace:
720p (öff.-recht. HD): Bild perfekt, kein Ruckeln, Lauftext geht perfekt
576i (alle SD Sender): Scaling unterirdisch (wie "next-neighbor"), man hat das Gefühl deinterlacing funktioniert durch halbieren der vertikalen Auflösung, kein Ruckeln, Lauftext geht perfekt
1080i (Servus TV HD, BBC HD, Channel 4 HD, private): Qualität nicht optimal aber fürs erste akzeptabel, immer kleine Ruckler, Bild läuft nicht flüssig

Zweiter Versuch mit selbst kompilierter aktueller libva / Intel-treiber (1.1.0):
720p (öff.-recht. HD): Bild perfekt, kein Ruckeln, Lauftext geht perfekt (kein Unterschied festzustellen)
576i (alle SD Sender): Scaling gut, deinterlacing erzeugt "wackliges Bild", zwischen den Frames gibt es einen Versatz (extrem ausgedrückt das Senderlogo geht immer hoch-runter-hoch-runter...), kein zeitliches Ruckeln
1080i (Servus TV HD, BBC HD, Channel 4 HD, private): Qualität besser, immer kleine Ruckler, Bild läuft nicht flüssig

Gibt es bestimmte Patches/Einstellungen mit den man die Probleme bei 576i und 1080i in Griff bekommt? Ich hab was gelesen von libva-ext, sind da Dinge enthalten die Version 1.1.0 noch fehlen?
softhddevice ist die aktuelle Git-Version vom 29.5.2012

Vielen Dank


System:
VDR: 1.7.27
OS: Ubuntu 12.04 64-Bit (alternate install ohne Desktop, mit Kernel 3.3.7)
CPU: Intel Core i5-2390T
CPU-Kühler: Scyte Kozuti (durch Bios runtergeregelt, ab 1m Abstand selbst bei totaler Stille unhörbar)
Mainboard: Gigabyte G1.Sniper M3 (mATX mit Z77)
SDD: Intel SSD 520 Series 120GB
RAM: 8GB DDR3L 1333MHz CL7
Netzteil: picoPSU-90 12V (derzeit noch an 12V Labornetzteil, Verbrauch im VDR-Betrieb ca. 2,3A an 12V (ca. 28W), Leerlauf ca. 1,65A (ca. 20W))
Gehäuse: Silverstone ML03B (mATX low-profile)
DVB: SaTiX-S2 Sky Xpress Dual (baugleich mit DVBsky S952)

2

Saturday, June 2nd 2012, 12:58pm

Moin,

Die geringe Auflösung kommt durch den Bob Deinterlacer.
Das 1080i Problem kommt vom Zusammenspiel Plugin/VA-API, du kannst mal xine-lib für vaapi testen, da habe ich das Gefühl das es nicht ist.

Soweit ich weiss ist der besser Deinterlacer nur im Branch staging und vaapi-ext drin.

http://cgit.freedesktop.org/vaapi/intel-driver/
http://cgit.freedesktop.org/vaapi/libva/

Wie man es Distribution conform macht, weiss ich leider nicht.
Ich habe einfach über die Distributions VA-API installiert.

Source code

1
2
3
4
5
6
7
8
rm -rf /usr/lib/va /usr/include/va /usr/lib/libva*
git clone git://anongit.freedesktop.org/vaapi/libva
cd libva
git checkout staging
./autogen.sh --prefix=/usr --with-drivers-path=/usr/lib64/va/drivers
make
make install
....


Danach muß man das Plugin neu bauen!

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

3

Saturday, June 2nd 2012, 5:11pm

Du kannst auch den Software Deinterlacer testen: Software Spatial.
Das ist meine yadif Adaption in C, reicht aber nur für SDTV mit G620.
Die C Vector oder sse Version sind leider noch nicht fertig,

Wie immer ist da Hilfe willkommen.

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

4

Saturday, June 2nd 2012, 11:03pm

Nun, ich hab jetzt libva-staging installiert (1.2.0pre) und auch den aktuellen intel staging treiber, kann kein Unterschied zu libva 1.1.0 feststellen (ist ja auch erst vor 5 Tagen released worden).

Quoted

Das 1080i Problem kommt vom Zusammenspiel Plugin/VA-API, du kannst mal xine-lib für vaapi testen, da habe ich das Gefühl das es nicht ist.
Was genau meinst du damit?

yadif geht bei mir auch nur mit 576i, aber da ist die Qualität von TemporalSpatial besser (desweiteren steigt der Stromverbrauch um rund 5 Watt gegenüber TemporalSpatial). Das wackeln ist hier auch da. Das ist grundsätzlich bei allen Deinterlacern außer bei weave.
Bei 576i fällt auch sehr deutlich auf das bei jedem zweiten frame die oberste Zeile schwarz ist. Das kann doch nicht richtig sein, insbesondere da das bei weave nicht ist. Da scheint irgendwo ein Problem zu sein.

5

Sunday, June 3rd 2012, 2:34pm

TemporalSpatial gibts für Intel nicht, oder meinst du da im Vergleich zu VDPAU?

Bei 1080i meine ich, daß die Demo putsurface von VA-API funktioniert.
Wenn ich ein Frontend mit [ANNOUNCE] xine-lib vaapi support verwende, es mir auch nicht auffällt.
Somit die Ursache an der Kombination SoftHdDevice + VAAPI liegen könnte.

Im Staging sind zwar die besseren Deinterlacer vorhanden, aber werden scheinbar nicht mehr verwendet.
Ich hatte es ja schon vermutet, warum seht hier http://lists.freedesktop.org/archives/li…rch/000808.html
vaapi-ext scheint noch zugehen, aber damit gibt es GPU Hänger.

Man muß schon besonders dumm sein, wenn man etwas was gut funktioniert ausbaut, nur weil es nicht so vorgesehen ist, ohne die Alternative fertig zuhaben.

Da bleibt nur NVidia zukaufen, solange die noch Video Dekodierung mit Linux unterstützen.
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

6

Monday, June 4th 2012, 5:18am

Quoted

TemporalSpatial gibts für Intel nicht, oder meinst du da im Vergleich zu VDPAU?
Nein, was auch immer passiert wenn ich TemporalSpatial in softhddevice einstelle, es sieht besser aus als das interne yadif. Aber erst seit libva 1.1, davor war das eine Katastrophe.

Quoted

Bei 1080i meine ich, daß die Demo putsurface von VA-API funktioniert.
Wenn ich ein Frontend mit [ANNOUNCE] xine-lib vaapi support verwende, es mir auch nicht auffällt.
Somit die Ursache an der Kombination SoftHdDevice + VAAPI liegen könnte.
Ich bekomme xine-lib-vaapi nicht kompiliert, der mault das vaCreateSurface mehr Parameter braucht, da ist die API wohl nicht kompatibel.

Ich habe putsurface ausprobiert, ich kann ein ganz leichtes ruckeln feststellen, sowohl bei 720p (putsurface -g 1280x720+0+0 -w 1280 -h 720 -r 50), als auch bei 1080p (putsurface -g 1280x720+0+0 -w 1920 -h 1080 -r 50), das ist aber beide mal gleich und deutlich geringer als bei softhddevice 1080i, kann sein das der Fernseher gar nicht echte 50Hz kann und das ruckeln daher kommt (und nur bei diesem Extremtest auffällt), werde es nochmal mit meinem PC-Monitor überprüfen der ganz sicher echte 50Hz kann.

Quoted

Im Staging sind zwar die besseren Deinterlacer vorhanden, aber werden scheinbar nicht mehr verwendet.
Ich hatte es ja schon vermutet, warum seht hier http://lists.freedesktop.org/archives/li…rch/000808.html
vaapi-ext scheint noch zugehen, aber damit gibt es GPU Hänger.

Man muß schon besonders dumm sein, wenn man etwas was gut funktioniert ausbaut, nur weil es nicht so vorgesehen ist, ohne die Alternative fertig zuhaben.

Da bleibt nur NVidia zukaufen, solange die noch Video Dekodierung mit Linux unterstützen.
Das sind ja tolle aussichten, aber bei open-source kann man ja patchen und zur Not forken (auch wenn das nicht immer im Sinne der Benutzer ist, siehe libav vs. ffmpeg)... Ist denn jemand von hier bei vaapi auf den mailing-listen aktiv und weist auf die Probleme hin?
Bevor ich eine Nvidia-Grafikkarte kaufe macht das deinterlacing lieber die cpu, ist vermutlich immer noch effizienter (und leiser) als eine Graka.
Hier ist ein bis SSSE3 optimierter GPL yadif source: http://avisynth.org.ru/yadif/yadif17.zip
Der deinterlacer scheint auch keine abhängigkeiten zu haben, der assembler-code muss aber natürlich an 64-bit angepasst werden (SSSE3 reicht ja, alle Prozessoren mit vaapi können ja auch SSSE3, der andere kram fliegt raus) und die calling-conventions an Linux.

7

Monday, June 4th 2012, 12:21pm

TemporalSpatial ist bei VA-API nur Bob Deinterlacer.
Und mein Software Deinterlacer ist nur Spatial, ich hatte mich da vertan, temporal fehlt noch.
Ich habe dann nicht weitergemacht, wenn schon spatial zulangsam ist, dann lohnt es sich nicht weiterzumachen.

Es kann sein das ich für Ruckeln unanfälliger bin, mir ist nichts aufgefallen.
putsurface gibt aber die 'Wiederholrate' aus, wenn da 50 Hz steht bzw. 20ms, dann arbeitet zumindest der Rechner zum Fernseher in 50Hz.

Ich verstehe die VA-API Developer nicht, die haben fast alles fertig und hat ja schon gut funktioniert. Was noch fehlt ist die Funktion über die neue API zur Verfügung zustellen.
Und noch ein Test/Demo Programm dazu. Zumindest war es bei meinem letzten Test noch so.

Ich weiß nicht ob es den Compiler für die Shaderprogramme öffentlich gibt, wenn ja, dann kann man selbst noch an den Deinterlacern spielen.

Temporal ist in meinen Plugin noch schwierig, aber machbar. Die Frage ist, lohnt sich die Arbeit bzw. ist es überhaupt lösbar.
Wenn 1080i mit sse4 yadif nicht ohne Framedrops machbar ist, dann kann man es auch gleichbleiben lassen.
mplayer kann auch va-api, ich weiß aber nicht ob man yadif mit va-api kombinieren kann. Damit könnte man testen ob die CPU Leistung reicht.
Zur Not kann man yadif noch als Multithread lösen.

Und der Temporale Deinterlacer im Inteltreiber war auch nicht schlecht.

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

8

Wednesday, June 6th 2012, 9:19am

Quoted

TemporalSpatial ist bei VA-API nur Bob Deinterlacer.
Und mein Software Deinterlacer ist nur Spatial, ich hatte mich da vertan, temporal fehlt noch.
Ich habe dann nicht weitergemacht, wenn schon spatial zulangsam ist, dann lohnt es sich nicht weiterzumachen.
Wo stand den was von Software temporal? Ich hab einfach mal den yadif von libav eingebaut, bis jetzt schafft er aber nur genau ein Bild, dann stürzt der vdr ab. Ich habe für die Puffer ein Array aus 5 Pointern auf die einzelnen Bilder angelegt (selbstdefinierter Datentyp, kein VAImage) in dem decoder struct. Die werden auf null initialisiert und wenn der deinterlacer das erste mal startet und die pointer null sind holt er sich mit malloc den Speicher. Funktioniert auch alles, die ersten beiden Bilder kommen auch und werden angezeigt, doch dann passiert folgendes: Irgendwas beschädigt den Puffer, ich habe das mit printf verfolgt: Bis zum ende der funktion VaapiSyncRenderFrame ist noch alles in Ordnung, doch direkt am Anfang des nächsten Aufrufs von VaapiSyncRenderFrame sind die Puffer verändert (beliebig, einzelne Werte haben sich verändert, jedes mal anders).
Gibt es dafür irgendeine sinnvolle Erklärung warum sich speicher, der nur von einer vorher unbekannten Variablen referenziert wird, verändert während unveränderter Code ausgeführt wird? Ist da irgendeine Speicherbereinigung, darf man kein malloc verwenden oder was ist das Problem? Da ich praktisch nie was größeres unter Linux programmiere habe ich auch keine Idee wie ich das debuggen soll außer das Programm mit printf vollzumüllen.

VA-API Bob macht interessanterweise das bessere Bild als Software Spatial für 576i. Liegt vielleicht am zusammenspiel mit dem resizer. Komisch das die ältere libva (bzw. der ältere Intel-Treiber) ein grauenhaftes Bild macht bei den gleichen einstellungen.

Quoted

Es kann sein das ich für Ruckeln unanfälliger bin, mir ist nichts aufgefallen.
putsurface gibt aber die 'Wiederholrate' aus, wenn da 50 Hz steht bzw. 20ms, dann arbeitet zumindest der Rechner zum Fernseher in 50Hz.
Ich habe es jetzt an meinem Monitor gestestet der sicher 50Hz nativ darstellen kann: Auch hier hat putsurface leichte ruckler, egal ob 720 oder 1080. Bei softhddevice kann ich bei 720p keine Ruckler feststellen, bei 1080i sind sie sehr viel deutlicher als bei putsurface. Vielleicht mach ich mal so ein ruckel-testvideo so ähnlich wie von putsurface fertig (oder gibts das irgendwo als video?) das man dem vdr dann als aufnahme unterjubeln kann, dann kann man besser vergleichen.

Quoted

Ich verstehe die VA-API Developer nicht, die haben fast alles fertig und hat ja schon gut funktioniert. Was noch fehlt ist die Funktion über die neue API zur Verfügung zustellen.
Und noch ein Test/Demo Programm dazu. Zumindest war es bei meinem letzten Test noch so.

Ich weiß nicht ob es den Compiler für die Shaderprogramme öffentlich gibt, wenn ja, dann kann man selbst noch an den Deinterlacern spielen.
Das Problem ist ja nicht das sie das über eine neue (bessere?) API zur Verfügung stellen wollen, sondern das das vermutlich keine Frage von Wochen oder ein paar Monaten ist, sondern beim Entwicklungstempo von libva eher Jahre.
Wenn das an sich soweit funktioniert hat, könnte man doch einfach einen patch gegen die stabile libva-version pflegen bis die neue API fertig ist. Kommt halt darauf an wie viel Arbeit das ist.

Quoted

Temporal ist in meinen Plugin noch schwierig, aber machbar. Die Frage ist, lohnt sich die Arbeit bzw. ist es überhaupt lösbar.
Wenn 1080i mit sse4 yadif nicht ohne Framedrops machbar ist, dann kann man es auch gleichbleiben lassen.
mplayer kann auch va-api, ich weiß aber nicht ob man yadif mit va-api kombinieren kann. Damit könnte man testen ob die CPU Leistung reicht.
Zur Not kann man yadif noch als Multithread lösen.
Wo siehst du das Problem mit temporal? Sofern das Audio verzögert werden kann, sehe ich keins. Theoretisch werden in meinem Code die ersten beiden Bilder jetzt doppelt ausgegeben und dann ist das audio immer 40ms voraus. Ich hab die drei puffer prev, current und next, das neue bild wird next, die puffer werden einfach am ende immer gedreht so das next current wird, current wird prev, und prev wird wieder next und beim nächsten aufruf durch das neue bild überschrieben (die Puffer sind alle yadif-intern, nichts mit VA-API).
SSSE3 hab ich noch nicht zum laufen bekommen, dieser furchtbare inline-assembler beschwert sich das dort falsche register verwendet werden und so, ich weiß nicht ob da was mit den 5000 pre-prozessoren irgendwas nicht stimmt oder ob die fehlermeldung falsch ist und ich das mit einem compiler-switch wegbekomme (besonders toll sind die dann die fehlermeldungen die sich auf eine zeile 457 beziehen, die datei aber nur 263 zeilen hat!). Das Problem scheinen aber viele mit yadif zu haben. Bevor aber die c version nicht läuft kümmere ich mich erstmal nicht um ssse3. danach gibt es noch optimierungsmöglichkeiten für nv12->planar mit sse2 bzw. planar->nv12 mit ssse3

9

Wednesday, June 6th 2012, 11:05am

Moin,

Quoted

Wo stand den was von Software temporal?

Ich bezog mich auf meine eingebaute Lösung, und meine Aussage ein paar Posts vorher, ich dachte die wäre schon fertig und wäre somit yadif.


Den Rest versuche ich gemeinsam zubeantworten.
Im Moment erfolgt der Deinterlacer so:

VaapiCpuDerive wird bei Intel aufgerufen. Die Surface enthält 2 Halbbilder.
Der Speicherbereich für diese wird für die CPU gemapped.
Arbeiten mit diesem kann extrem langsam sein.
Deshalb ich mit verschiedenen Methoden experimentiert.
Für Yadif diese Halbbilder konvertieren bzw. speichern.
Dann erzeuge ich aus diesen zwei Halbbilder zwei Vollbilder.
Für diese werden wieder zwei Surface in den Speicherbereich der CPU gemapped und diese mit den CPU Vollbildern gefüllt.
Danach kommen die zwei Surface in die Ausgabe Queue.

Diese gemappten Surface sind nur wärend des Funktionsaufruf gültig, könnte sein das hier dein Problem liegt.
Dann arbeitet yadif mit Halbbildern und VA-API sind Vollbilder.

Also man speichert 2 Surface: S0, S1 diese werden dann immer rotiert, die älteste fällt weg, die neue kommt dazu: S2, S3.
Eine Surface enthält die Halbbilder Top und Bottom: S0 = T0B0.
yadif braucht nun Future, Current und Past: T0B0 T1B1 das wäre dann zb.
Past T0, Current B0 und Future T1
Past B0, Current T1 und Future B1

Ein Problem meiner Lösung ist, das ich zwei neue Surface gleichzeitig erzeuge, habe aber nur 20ms Zeit.
Dafür mache ich dann 20ms nichts.
Entweder löst man den Deinterlacer durch 1-2 Threads oder baut den Aufruf an eine andere Stelle

Ich würde Threads nehmen, da man da dann zumindest 2 Deinterlacer Threads parallel laufen lassen kann.

Bei va-api ist noch die Demo mpeg2vldeo dabei die dekodiert und anzeigt.
Ansonsten ist der Anfang meines Testcode in Vappi1080i, muß mal gucken ob mein extra Test Programm neuer ist.

Edit:
In ffmpeg ist auch noch eine Assembler yadif Lösung.

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

10

Wednesday, June 6th 2012, 1:04pm

So hier mein Test Programm für das 1080i Problem.
Beim letzten Test vor ein paar Monaten, ist es einfach abgestürzt,
Deshalb vaapi-killer :)
Habe es mehrmals versucht auf der VA-API Mailingliste zuposten, aber deren Maintainer schläft
oder die Deppen wissen gar nicht was dies ist.

Source code

1
2
3
chmod +x vaapi-killer.c
./vaapi-killer.c
./vaapi-killer


Mit VDPAU Funktionert es, aber auch ohne v-sync.
Wenn es funktioniert kann man es langsam erweitern bis die Probleme mit dem 1080i v-sync auftreten und dann entweder den Fehler in VA-API suchen oder nochmal versuchen auf der Mailiingliste eine Antwort zubekommen.

Edit:
Mit export VDPAU_VIDEO_PUTSURFACE_FAST=0 funktioniert es mit VA-API/VDPAU und v-sync.

Edit: aktuelle version der demo ist in neueren posts.

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

This post has been edited 3 times, last edit by "johns" (Jun 11th 2012, 7:15pm)


11

Wednesday, June 6th 2012, 9:55pm

So habe ich yadif implementiert (der restliche code ist unverändert aus libav/ffmpeg):

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
typedef struct {
	uint8_t* yuv[3];
	int height[3];
	int width[3];
	int pitch[3]; // stored width
	int yuvsize;
} vaapi_yadif_img;

static void nv12ToUV(uint8_t *dstU, uint8_t *dstV, uint8_t *src, int width)
{
	int i;
	width>>=1;
	for(i=0;i<width;i++) {
		dstU[i]=src[i*2];
		dstV[i]=src[i*2+1];
	}
}

static void UVTonv12(uint8_t *dst, uint8_t *srcU, uint8_t *srcV, int width)
{
	int i;
	width>>=1;
	for(i=0;i<width;i++) {
		dst[i*2]=srcU[i];
		dst[i*2+1]=srcV[i];
	}
}

#define YADIF_PITCH(w,a) (w%a==0) ? w : w+a-(w%a)

static void CopyVAImg2YadifImg_alloc(VADisplay *display, VAImage *src, vaapi_yadif_img *dst)
{
	uint8_t *srcp, *srcuv, *dstU, *dstV;
	int i;
	vaMapBuffer(display, src->buf, (void**)&srcp);
	dst->width[0] = src->width;
	dst->width[1] = dst->width[2] = dst->width[0]>>1;
	dst->height[0] = src->height;
	dst->height[1] = dst->height[2] = dst->height[0]>>1;
	if(src->format.fourcc == VA_FOURCC_NV12) {
		dst->pitch[0] = src->pitches[0];
		dst->pitch[2] = dst->pitch[1] = YADIF_PITCH(dst->width[1],16);
		dst->yuvsize = dst->pitch[0]*dst->height[0]+dst->pitch[1]*dst->height[1]+dst->pitch[2]*dst->height[2];
		dst->yuv[0] = malloc(dst->yuvsize);
		dst->yuv[1] = dst->yuv[0]+dst->pitch[0]*dst->height[0];
		dst->yuv[2] = dst->yuv[1]+dst->pitch[1]*dst->height[1];
		memcpy(dst->yuv[0], srcp+src->offsets[0], src->height*src->pitches[0]);
		srcuv=srcp+src->offsets[1];
		dstU=dst->yuv[1];
		dstV=dst->yuv[2];
		for(i=0;i<dst->height[1];i++) {
			nv12ToUV(dstU,dstV,srcuv,src->width);
			srcuv+=src->pitches[1];
			dstU+=dst->pitch[1];
			dstV+=dst->pitch[2];
		}
	}
	if (vaUnmapBuffer(display, src->buf) != VA_STATUS_SUCCESS) {
		Error(_("video/vaapi: can't unmap image buffer\n"));
    }
}

static void CopyVAImg2YadifImg(VADisplay *display, VAImage *src, vaapi_yadif_img *dst)
{
	uint8_t *srcp, *srcuv, *dstU, *dstV;
	int i;
	vaMapBuffer(display, src->buf, (void**)&srcp);
	if(src->format.fourcc == VA_FOURCC_NV12) {
		memcpy(dst->yuv[0], srcp+src->offsets[0], src->height*src->pitches[0]);
		srcuv=srcp+src->offsets[1];
		dstU=dst->yuv[1];
		dstV=dst->yuv[2];
		for(i=0;i<dst->height[1];i++) {
			nv12ToUV(dstU,dstV,srcuv,src->width);
			srcuv+=src->pitches[1];
			dstU+=dst->pitch[1];
			dstV+=dst->pitch[2];
		}
	}
	if (vaUnmapBuffer(display, src->buf) != VA_STATUS_SUCCESS) {
		Error(_("video/vaapi: can't unmap image buffer\n"));
    }
}

static void CopyYadifImg2VAImg(VADisplay *display, vaapi_yadif_img *src, VAImage *dst)
{
	uint8_t *dstp, *dstuv, *srcU, *srcV;
	int i;
	vaMapBuffer(display, dst->buf, (void**)&dstp);
	if(dst->format.fourcc == VA_FOURCC_NV12) {
		memcpy(dstp+dst->offsets[0], src->yuv[0], src->height[0]*src->pitch[0]);
		dstuv=dstp+dst->offsets[1];
		srcU=src->yuv[1];
		srcV=src->yuv[2];
		for(i=0;i<src->height[1];i++) {
			UVTonv12(dstuv,srcU,srcV,dst->width);
			dstuv+=dst->pitches[1];
			srcU+=src->pitch[1];
			srcV+=src->pitch[2];
		}
	}
	if (vaUnmapBuffer(display, dst->buf) != VA_STATUS_SUCCESS) {
		Error(_("video/vaapi: can't unmap image buffer\n"));
    }
}

static void InitVaapiYadif(VADisplay *display, VAImage *src, vaapi_yadif_img *buf_imgs[])
{
	buf_imgs[0]=malloc(5*sizeof(vaapi_yadif_img));
	buf_imgs[1]=buf_imgs[0]+sizeof(vaapi_yadif_img);
	buf_imgs[2]=buf_imgs[1]+sizeof(vaapi_yadif_img);
	buf_imgs[3]=buf_imgs[2]+sizeof(vaapi_yadif_img);
	buf_imgs[4]=buf_imgs[3]+sizeof(vaapi_yadif_img);

	CopyVAImg2YadifImg_alloc(display,src,buf_imgs[0]);

	memcpy(buf_imgs[1],buf_imgs[0],sizeof(vaapi_yadif_img));
	memcpy(buf_imgs[2],buf_imgs[0],sizeof(vaapi_yadif_img));
	buf_imgs[1]->yuv[0] = malloc(buf_imgs[1]->yuvsize);
	buf_imgs[2]->yuv[0] = malloc(buf_imgs[2]->yuvsize);
	memcpy(buf_imgs[1]->yuv[0],buf_imgs[0]->yuv[0],buf_imgs[1]->yuvsize);
	memcpy(buf_imgs[2]->yuv[0],buf_imgs[0]->yuv[0],buf_imgs[2]->yuvsize);
	buf_imgs[1]->yuv[1] = buf_imgs[1]->yuv[0]+buf_imgs[1]->pitch[0]*buf_imgs[1]->height[0];
	buf_imgs[1]->yuv[2] = buf_imgs[1]->yuv[1]+buf_imgs[1]->pitch[1]*buf_imgs[1]->height[1];
	buf_imgs[2]->yuv[1] = buf_imgs[2]->yuv[0]+buf_imgs[2]->pitch[0]*buf_imgs[2]->height[0];
	buf_imgs[2]->yuv[2] = buf_imgs[2]->yuv[1]+buf_imgs[2]->pitch[1]*buf_imgs[2]->height[1];
	memcpy(buf_imgs[3],buf_imgs[0],sizeof(vaapi_yadif_img));
	memcpy(buf_imgs[4],buf_imgs[0],sizeof(vaapi_yadif_img));
	buf_imgs[3]->yuv[0] = malloc(buf_imgs[3]->yuvsize);
	buf_imgs[4]->yuv[0] = malloc(buf_imgs[4]->yuvsize);
	buf_imgs[3]->yuv[1] = buf_imgs[3]->yuv[0]+buf_imgs[3]->pitch[0]*buf_imgs[3]->height[0];
	buf_imgs[3]->yuv[2] = buf_imgs[3]->yuv[1]+buf_imgs[3]->pitch[1]*buf_imgs[3]->height[1];
	buf_imgs[4]->yuv[1] = buf_imgs[4]->yuv[0]+buf_imgs[4]->pitch[0]*buf_imgs[4]->height[0];
	buf_imgs[4]->yuv[2] = buf_imgs[4]->yuv[1]+buf_imgs[4]->pitch[1]*buf_imgs[4]->height[1];
}


void VaapiYadif (VADisplay *display, VAImage *src, VAImage *dst1,
    VAImage *dst2, vaapi_yadif_img *buf_imgs[], int tff, int skip_spatial)
{
	vaapi_yadif_img *tmp;

	if(buf_imgs[2]==NULL) { InitVaapiYadif(display, src, buf_imgs); }
	else { 	CopyVAImg2YadifImg(display, src, buf_imgs[2]); }
	
	skip_spatial<<=1;
	int y, i;

	for (i = 0; i < 3; i++) {
		int w = buf_imgs[3]->width[i];
		int h = buf_imgs[3]->height[i];
		int refs = buf_imgs[3]->pitch[i];

		for (y = 0; y < h; y++) {
			if ((y ^ tff) & 1) {
				uint8_t *prev = &buf_imgs[0]->yuv[i][y*refs];
				uint8_t *cur  = &buf_imgs[1]->yuv[i][y*refs];
				uint8_t *next = &buf_imgs[2]->yuv[i][y*refs];
				// vdr_plg_shddev_yadif_filter_line_ssse3
				filter_line_c(&buf_imgs[3]->yuv[i][y*refs], prev, cur, next, w, y+1<h ? refs : -refs, y ? -refs : refs, 0, (y==1 || y+2==h) ? 2 : skip_spatial);
				memcpy(&buf_imgs[4]->yuv[i][y*refs], &buf_imgs[1] ->yuv[i][y*refs], w);
			} else {
				uint8_t *prev = &buf_imgs[0]->yuv[i][y*refs];
				uint8_t *cur  = &buf_imgs[1] ->yuv[i][y*refs];
				uint8_t *next = &buf_imgs[2]->yuv[i][y*refs];
				filter_line_c(&buf_imgs[4]->yuv[i][y*refs], prev, cur, next, w, y+1<h ? refs : -refs, y ? -refs : refs, 1, (y==1 || y+2==h) ? 2 : skip_spatial);
				memcpy(&buf_imgs[3]->yuv[i][y*refs], &buf_imgs[1] ->yuv[i][y*refs], w);
			}
		}
	}

	CopyYadifImg2VAImg(display,buf_imgs[3],dst1);
	CopyYadifImg2VAImg(display,buf_imgs[4],dst2);

	tmp = buf_imgs[0];
	buf_imgs[0] = buf_imgs[1];
	buf_imgs[1] = buf_imgs[2];
	buf_imgs[2] = tmp;
}

In der video.c (ich geb den speicher bis jetzt noch nirgendwo wieder frei):

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
im decoder struct:
...
    VAImage DeintImages[5];		///< deinterlace image buffers
    vaapi_yadif_img* yadif_images[5];
    int GetPutImage;			///< flag get/put image can be used
...
in VaapiNewHwDecoder:
...
    decoder->Image->image_id = VA_INVALID_ID;
    memset(decoder->yadif_images,0,5*sizeof(void*));
    for (i = 0; i < CODEC_SURFACES_MAX; ++i) {
...
in VaapiCpuDerive:
...
	case VideoDeinterlaceSoftSpatial:
	    VaapiSpatial(decoder, image, dest1, dest2);
	    break;
	case VideoDeinterlaceSoftTemporal:
	    VaapiYadif(decoder->VaDisplay, image, dest1, dest2, decoder->yadif_images, decoder->TopFieldFirst, 1);
	    break;
	case VideoDeinterlaceSoftTemporalSpatial:
	    VaapiYadif(decoder->VaDisplay, image, dest1, dest2, decoder->yadif_images, decoder->TopFieldFirst, 0);
	    break;
    }
...
Dazu natürlich noch die beiden Methoden auf den Listen ergänzt. Das Problem is das sich das height-Array einzelner yadif_images verändert, und zwar nach beendigung von VaapiSyncRenderFrame und vor dem erneuten Aufruf von VaapiSyncRenderFrame. Woran kann das liegen?


Ich werden den vaapi-killer gleich mal ausprobieren, VDPAU kann ich aber nicht testen.

12

Thursday, June 7th 2012, 5:26am

Also vaapi_killer macht bei mir gar nichts, das ist die Ausgabe:

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
libva: VA-API version 0.33.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva: Found init function __vaDriverInit_0_33
libva: va_openDriver() returns 0
video/vaapi: libva 0.33 (Intel i965 driver - 1.0.18) initialized
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
0 ms / frame
done
Auf dem Bildschirm passiert nichts.

Ich habe das Problem bei yadif nochmal weiter gesucht: Irgendwas überschreibt den Speicher, und zwar außerhalb des vaapi-Moduls. Dies muss während einer Initialisierung sein nachdem das erste Bild dekodiert wurde. Ich habe es bis jetzt dreimal geschafft das yadif läuft ohne das er abstürzt. Wenn der zweite Aufruf in Ordnung ist passiert auch nichts mehr, dann läuft er stabil. Es ist egal ob man auf dem Sender startet oder von 720p dahinwechselt, die Wahrscheinlichkeit für einen Absturz nach einem Bild liegt bei etwa 95%. Wenn er die Hürde geschafft hat gehts.
kann es sein das dort irgendwas nicht thread-safe ist oder sowas und der speicher von einem anderen Thread überschrieben wird?
Bei 1080i (nicht fake) schafft er im TemporalSpatial-Modus etwa 3 Bilder pro Sekunde :( Ob das der SSE-Code tatsächlich verzwanzigfachen kann bezweifel ich, aber für 576i wird das sicher mehr als ausreichend sein (das hinkt nur ein ganz kleines bisschen im Moment). Multithreading sollte nicht so kompliziert sein, so wie ich das sehe wäre es eine Möglichkeit das Bild einfach horizontal zu teilen, da yadif pro zeile arbeitet und jede ausgegebene Zeile unabhängig von der vorherigen ist.
Ich hab den Code einfach mal (in einem sehr unaufgeräumten Zustand) in den Anhang getan, vielleicht findest du eine Lösung für dieses Speicherproblem. Ich werd da nicht schlau draus.

Nachtrag: Ich hab den Fehler beim ASM-Code gefunden, da war an einer Stelle 64-Bit nicht definiert und deshalb kam murks raus. Jetzt weigert er sich zu linken, da "-fPIC" fehlt. Habe "-fPIC" im makefile ergänzt (für C und CXX), mault aber immer noch. Er benennt explizit die datei mit dem inline-assembler, doch die ist gnaz sicher mit -fPIC kompliert. Linkt er noch gegen irgendwas was ich mit "-fPIC" neu kompilieren muss?
x_v has attached the following file:

This post has been edited 1 times, last edit by "x_v" (Jun 7th 2012, 7:22am)


13

Thursday, June 7th 2012, 10:12am

Also vaapi_killer macht bei mir gar nichts, das ist die Ausgabe:
Auf dem Bildschirm passiert nichts.


IIRC hatte ich auch das Problem, "#if 0" -> "#if 1" VA-API scheint erst nach einen Zugriff die Flächen anzulegen.

Quoted

Ich habe das Problem bei yadif nochmal weiter gesucht: Irgendwas überschreibt den Speicher, und zwar außerhalb des vaapi-Moduls. Dies muss während einer Initialisierung sein nachdem das erste Bild dekodiert wurde. Ich habe es bis jetzt dreimal geschafft das yadif läuft ohne das er abstürzt. Wenn der zweite Aufruf in Ordnung ist passiert auch nichts mehr, dann läuft er stabil. Es ist egal ob man auf dem Sender startet oder von 720p dahinwechselt, die Wahrscheinlichkeit für einen Absturz nach einem Bild liegt bei etwa 95%. Wenn er die Hürde geschafft hat gehts.
kann es sein das dort irgendwas nicht thread-safe ist oder sowas und der speicher von einem anderen Thread überschrieben wird?
Bei 1080i (nicht fake) schafft er im TemporalSpatial-Modus etwa 3 Bilder pro Sekunde :( Ob das der SSE-Code tatsächlich verzwanzigfachen kann bezweifel ich, aber für 576i wird das sicher mehr als ausreichend sein (das hinkt nur ein ganz kleines bisschen im Moment). Multithreading sollte nicht so kompliziert sein, so wie ich das sehe wäre es eine Möglichkeit das Bild einfach horizontal zu teilen, da yadif pro zeile arbeitet und jede ausgegebene Zeile unabhängig von der vorherigen ist.
Ich hab den Code einfach mal (in einem sehr unaufgeräumten Zustand) in den Anhang getan, vielleicht findest du eine Lösung für dieses Speicherproblem. Ich werd da nicht schlau draus.


Ich werde es mir mal angucken. Im Normalfall nehme ich da valgrind der findet solche Fehler schnell. Ansonsten kann man noch mit GDB einen Speicher Watchpoint erstellen.

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

14

Thursday, June 7th 2012, 12:23pm

Source code

1
        buf_imgs[1]=buf_imgs[0]+sizeof(vaapi_yadif_img);


Ist doppelt gemoppelt hier wird die Größe noch mit der Größe von buf_imgs multipliziert.

Source code

1
       buf_imgs[1]=(void*)buf_imgs[0]+sizeof(vaapi_yadif_img);


(void*) geht nur bei gcc. ansonsten erst nach (char*) casten und das Ganze zu void* oder typeof(buf_imgs[1]).

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

15

Thursday, June 7th 2012, 4:50pm

Die Version läuft, killt nur X11 beim Beenden.

  • video/vaapi: libva 0.34 (Intel i965 driver - 1.0.16.pre1) initialized
  • kernel 3.4
  • xserver 1.12.2




Johns
johns has attached the following file:
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

16

Friday, June 8th 2012, 12:36am

Quoted

Die Version läuft, killt nur X11 beim Beenden.

video/vaapi: libva 0.34 (Intel i965 driver - 1.0.16.pre1) initialized
kernel 3.4
xserver 1.12.2
Ich weiß nicht was passieren soll, jetzt sagt 39ms/frame (am Anfang 37, am Ende 39.92), die Ausgabe ist aber nur grün, und der X-Server sagt folgendes:

Source code

1
2
(EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable
(EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable

Abstürzen tut er auch nicht. Hat das einen Grund das du den alten Intel-Treiber mit der neusten VA-API verwendest?

Quoted

Ist doppelt gemoppelt hier wird die Größe noch mit der Größe von buf_imgs multipliziert.
Ahhh... Anscheinend waren die Zeiger die da berechnet wurden immer noch im Speicher vom vdr. Also wurde nicht der yadif-Speicher überschrieben sondern yadif hat einfach anderen Speicher überschrieben. Vielen Dank!
Jetzt geht es (grundsätzlich gesprochen, umschalten kann man nicht auf Sender mit anderen Bildformaten, speicher wird auch noch nicht wieder freigegeben) :)
Ich habe die nv12 <-> u+v planes c-Funktionen durch sse2/ssse3 Funktionen ersetzt, der Geschwindigkeitsgewinn ist bei 576i minimal spürbar (aber immer noch nicht flüssig), bei 1080i kein spürbarer Unterschied. Ich bekomme den yadif-assembler bloß nicht gelinkt, hast du da eine Idee? Hab den source wieder in en Anhang getan. Ich hab überhaupt keine Ahnung wie diese Makefiles aufgebaut sind, ich weiß nicht wie ich die Assembler-Datei da einbaue damit die mit yasm übersetzt wird, hab das dann manuell gemacht ("yasm -f elf -m amd64 -DPIC -g dwarf2 nv12_uv.asm").
x_v has attached the following file:

17

Friday, June 8th 2012, 4:56am

Hab den Fehler gefunden: Da war noch ein makro falsch für den inline-assembler, dadurch wird der nicht pic kompiliert, egal was man tut. Mit ssse3 ist 576i in Echtzeit kein problem, sieht auch sehr gut aus. Für 1080i wie erwartet zu langsam, aber sehr viel schneller als die c-version. habe auch schon multithreading angefangen, bis jetzt arbeitet aber nur ein streifen, entweder nur ein thread macht etwas oder alle threads deinterlacen den gleichen streifen, ist mir jetzt zu mühsam zum debuggen (insbesondere ohne debugger). Kann man in vaapi_yadif.h ein- und ausschalten.
Was sonst noch zu tun ist:

Source code

1
2
3
4
5
6
7
8
-Audiosynchronisation: Das Bild hängt wie erwartet um 40ms, da muss der Ton angepasst werden
-Speicher Clean-Up: Bei Senderwechsel (zumindest bei Formatwechsel) muss der Speicher wieder freigegeben und die threads beendet werden,
                    damit yadif sich beim nächsten mal neu initialisiert und nicht abstürzt
-Makefile: yasm integrieren
-Komplett ungetestet auf 32 Bit
-Eine config.h / config.asm erstellen, welche die nötigen infos enthält (32/64 Bit, sse2/ssse3 vorhanden)
-Skip Chroma ist noch nicht implementiert
-Das erste Bild scheint fehlerhaft zu sein

Zusatzfeature (gerade für Kinofilme/US-HD-Serien sinnvoll): Deinterlaceing über fernbedieung ausschaltbar machen.

Dann mal schauen wie man der vaapi temporal-spatial beibringt.
x_v has attached the following file:

18

Friday, June 8th 2012, 10:18am

Quoted

Die Version läuft, killt nur X11 beim Beenden.

video/vaapi: libva 0.34 (Intel i965 driver - 1.0.16.pre1) initialized
kernel 3.4
xserver 1.12.2
Ich weiß nicht was passieren soll, jetzt sagt 39ms/frame (am Anfang 37, am Ende 39.92), die Ausgabe ist aber nur grün, und der X-Server sagt folgendes:

Source code

1
2
(EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable
(EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable

Abstürzen tut er auch nicht. Hat das einen Grund das du den alten Intel-Treiber mit der neusten VA-API verwendest?


Muß mal gucken, aber ich habe keine Fehlermeldung gesehen.
Es soll nichts darstellenen. also das grüne Bild ist richtig.
Der Treiber scheint die ersten Frames zupuffern und dadurch werden es keine 40ms.
Der Intel-Treiber ist die GIT Version Branch:staging und da haben sie diese Versionnummer drin.

Jetzt muß ich mal das Testprogramm erweitern bis kein v-sync mehr klappt.

Quoted

Jetzt geht es (grundsätzlich gesprochen, umschalten kann man nicht auf Sender mit anderen Bildformaten, speicher wird auch noch nicht wieder freigegeben) :)
Ich habe die nv12 <-> u+v planes c-Funktionen durch sse2/ssse3 Funktionen ersetzt, der Geschwindigkeitsgewinn ist bei 576i minimal spürbar (aber immer noch nicht flüssig), bei 1080i kein spürbarer Unterschied. Ich bekomme den yadif-assembler bloß nicht gelinkt, hast du da eine Idee? Hab den source wieder in en Anhang getan. Ich hab überhaupt keine Ahnung wie diese Makefiles aufgebaut sind, ich weiß nicht wie ich die Assembler-Datei da einbaue damit die mit yasm übersetzt wird, hab das dann manuell gemacht ("yasm -f elf -m amd64 -DPIC -g dwarf2 nv12_uv.asm").


Ich würde mal die GetMsTicks einbauen, dann sieht man wo die Probleme liegen.
Eine lange Zeit wird für das Runterladen und Hochladen der Flächen verbraucht.

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

19

Friday, June 8th 2012, 2:57pm

Ich glaube ich habe den v-sync Bug gefunden.

Anbei ein Patch gegen die aktuelle GIT Version, ich kann im Moment VA-API auf Intel nicht testen.
Aber mit VDPAU Backend schaut es gut aus.

Dann die aktuelle vaapi-killer Version. Ohne Parameter stimmt der v-sync nicht, mit beliebigen Parameter sollte der v-sync klappen.
Es sollten ~40ms bei 50Hz Bildschirm sein.

Ist auch ein nettes Demo für alle die sich mit VA-API Programmierung beschäftigen wollen.

Edit: so konnte nun mit Intel HD2000 testen, leider ist es nicht gefixt.
Aber das Test Programm funktioniert sehr gut, mit 1080i Auflösung sind die Streifen am flimmern wie Sau, mit geringerer Auflösung funktioniert es.

Edit2: Je nach Version sind die Fehler unterschiedlich.

Gemeinsam ist das ab 1281 Breite die Ausgabe anfängt zuflimmern. Die Höhe spielt keine Rolle.

Edit3: Ist nun vaapi-demo und man kann nun mit dem Parametern spielen ohne immer neu zu kompilieren.

Source code

1
2
3
gunzip vaapi-demo.c.gz
chmod +x vaapi-demo.c
./vaapi-demo.c && ./vaapi-demo -h


Johns
johns has attached the following file:
  • vsync_patch.diff (2.11 kB - 40 times downloaded - latest: Sep 25th 2014, 11:58pm)
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

This post has been edited 5 times, last edit by "johns" (Jun 11th 2012, 7:16pm)


20

Saturday, June 9th 2012, 7:44am

Ich hab mit vaapi-demo gespielt: Bei mir flimmert nichts mit 1920x1080, egal wie ich die Parameter kombiniere. Woran erkennt man das den genau bei grünen Bild? Sieht bei bir absolut statisch aus. X-Server gibt kein Fehler mehr aus.

Ich hab mal getticks bei yadif eingebaut und das Ergebnis war in der Tat überraschend (bei 1440x1080, in Klammern bei 720x576):

Ein Bild von Vaapi zu Yadif kopieren: 35ms (7ms)
Bild deinterlacen mit zwei Ausgabeframes: 22ms (4ms)
Zwei(!) Bilder von Yadif zu Vaapi kopieren: 8ms (1ms)

Ich habe dann CopyVAImg2YadifImg untersucht und es kam folgendes bei raus: memcpy der Y-Plane: 22ms! UV interleaved nach UV planes kopieren: 11ms (der rest ist VAMapBuffer)
Die SSE2 Funktion von libav für nv12->uv ist nicht so gut, das kann man mit SSSE3 dank pshufb bestimmt mehr als doppelt so schnell machen.
Aber memcpy 22ms?? Mein erster Gedanke: Alignment: Beide pointer sind immer vielfache von 16. Nächster Hinweis: Angeblich soll memcpy schneller sein wenn die Differenz der Zeiger ein vielfaches von 64 ist: Das ist hier fast nie der Fall, bei YadifImg2VAImg aber auch nicht, und hier brauch memcpy maximal 1ms. Irgendeine Idee dazu?

Wenn ein Bild von Vaapi nach Yadif genau so schnell geht wie andersrum bräuchte das Deinterlacen von 1080i nur noch 34ms und wäre damit im Bereich des machbaren. Mit Multithreading kann man das vermutlich noch weiter senken.


Nochmal zur Intel-Treiberversion, auch staging hat bei mir die version 1.0.18? Hab ich von hier: http://cgit.freedesktop.org/vaapi/intel-driver/

Nachtrag: Ich hab die Zeiten mal mit abgeschaltetem SSE gemessen: Ergebnis: Yadif selber braucht mehr als 7x soviel Zeit, bei Vaapi-zu-Yadif ändert sich nichts, Yadif-zu-Vaapi braucht minimal länger.
Der Flaschenhals ist eindeutig der lesende Zugriff auf das VAAPI-Bild:
Ich habe in der asm-Funktion für nv -> UV planes alles auskommentiert außer das lesen: praktisch kein Geschwindigkeitsunterschied, nur das lesen auskommentiert: nv -> UV planes braucht maximal 1ms statt 11ms. Die Frage ist warum? Ich hab probiert das Bild schon eher zu mappen und dann prefetch zu machen, ändert aber nichts. Gibt es irgendwelche speziellen VAAPI-prefetch Funktionen die irgendwie mit der GPU zusammenhängen?

This post has been edited 1 times, last edit by "x_v" (Jun 9th 2012, 11:16am)