[ANNOUNCE] Avards-Plugin 0.2.0

FireFly · 29. März 2009

Hallo,

ich habe einige Änderungen an der Methode gemacht, wie Avards die Bilder einliest.

Das Avards-Plugin dient zur automatischen Erkennung und Unterdrückung der schwarzen Ränder bei der Ausstrahlung von Breitbild-Material im 4:3-Modus (Letterbox-Format), indem dem Fernseher über das WSS-Signal ein Zoomfaktor mitgeteilt wird.

Die Änderungen zwischen Avards 0.1.5 und 0.2.0:
-------------------------------------------------------------
- Das Einlesen der Bilder wurde auf V4L2 umgestellt (Danke an kls für den Codeteil in VDR 1.7.3)
- optionale Unterstützung hinzugefügt für das Einlesen der Bilder über die GrabImage-Funktion des VDR anstatt von /dev/video (neuer Parameter -g) (basierend auf dem Patch von e9hack)
- Filedescriptor-Werte und Überprüfungen korrigiert (Danke an e9hack für den Patch)

Durch die Umstellung auf V4L2 ist jetzt teilweise auch der gleichzeitige Zugriff mehrerer Anwendungen auf /dev/video möglich.

Hier geht es zur Homepage
und hier direkt zum Download

Happy compiling
FireFly

heifisch · 29. März 2009

Hallo FireFly,

leider bringt das neue Plugin bei mir keine Besserung.

Code

BUG: Bad page map in process vdr  pte:10101010 pmd:0d341067
addr:b7bf3000 vm_flags:08000075 anon_vma:(null) mapping:cf4c59d4 index:c
vma->vm_ops->fault: filemap_fault+0x0/0x267
vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x3b
Pid: 932, comm: vdr Tainted: G    B      2.6.29 #13
Call Trace:
 [<c013cf9d>] print_bad_pte+0x168/0x179
 [<c013d7a1>] zap_pte_range+0x1a8/0x1ff
 [<c013d8bc>] unmap_page_range+0xc4/0xdc
 [<c013d98d>] unmap_vmas+0xb9/0x15f
 [<c013ff72>] exit_mmap+0x79/0xd9
 [<c0113e41>] mmput+0x1b/0x58
 [<c011665c>] exit_mm+0x9f/0xa6
 [<c0124114>] hrtimer_try_to_cancel+0x35/0x40
 [<c011781b>] do_exit+0x110/0x1e3
 [<c011792e>] do_group_exit+0x40/0x66
 [<c011dad8>] get_signal_to_deliver+0x1a2/0x1b2
 [<c01024d7>] do_signal+0x56/0x102
 [<c0101bb2>] __switch_to+0x11d/0x13c
 [<c0262524>] schedule+0x20e/0x22a
 [<c010e05d>] do_page_fault+0x0/0x37f
 [<c026264e>] schedule_timeout+0x79/0x8e
 [<c011b5a3>] process_timeout+0x0/0x5
 [<c010e05d>] do_page_fault+0x0/0x37f
 [<c010293c>] do_notify_resume+0xd/0x31
 [<c0102b3e>] work_notifysig+0x13/0x25
BUG: unable to handle kernel paging request at 8a8d8aa4
IP: [<c0151cea>] do_poll+0xa1/0x1dd
*pde = 00000000
Oops: 0000 [#1]
last sysfs file:
Modules linked in: lirc_serial lirc_dev


Pid: 960, comm: vdr Tainted: G    B      (2.6.29 #13)
EIP: 0060:[<c0151cea>] EFLAGS: 00010286 CPU: 0
EIP is at do_poll+0xa1/0x1dd
EAX: 8a8d8a88 EBX: cf8bfc3c ECX: 8b8c8a87 EDX: cf82bda0
ESI: cf8bfe8c EDI: cf82bda0 EBP: cf8bfe84 ESP: cf8bfbec
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process vdr (pid: 960, ti=cf8be000 task=cf833990 task.ti=cf8be000)
Stack:
 cf8bfc3c cf8bfe84 cf8bfc3c 00000000 00000000 00000000 0000c350 cf8bfe94
 c0151e34 cf8bfc54 00000001 cf8bfc3c cf8bfe84 00000000 00000001 c0151f64
 cf8bff9c cf8bff9c b7203290 b7203298 c015298f 00000000 cf833990 00000000
Call Trace:
 [<c0151e34>] free_poll_entry+0xe/0x16
 [<c0151f64>] do_sys_poll+0xdc/0x143
 [<c015298f>] __pollwait+0x0/0x45
 [<c01529d4>] pollwake+0x0/0x39
 [<c0111d89>] update_curr+0x5e/0x8d
 [<c0113133>] dequeue_task_fair+0x12/0x1a
 [<c01112de>] dequeue_task+0x4b/0x58
 [<c0262524>] schedule+0x20e/0x22a
 [<c026264e>] schedule_timeout+0x79/0x8e
 [<c011b5a3>] process_timeout+0x0/0x5
 [<c01dae74>] saa7146_i2c_writeout+0x141/0x43f
 [<c01db3eb>] saa7146_i2c_transfer+0x279/0x28c
 [<c01db40f>] saa7146_i2c_xfer+0x11/0x16
 [<c0212389>] i2c_transfer+0x60/0x67
 [<c01f5c33>] tda8083_readregs+0x50/0x88
 [<c01f5c02>] tda8083_readregs+0x1f/0x88
 [<c01f61a0>] tda8083_read_status+0x38/0x8a
 [<c01ff1f6>] av7110_fe_read_status+0x15/0x3c
 [<c01f2140>] dvb_frontend_ioctl_legacy+0x3c5/0x638
 [<c0111d89>] update_curr+0x5e/0x8d
 [<c0113133>] dequeue_task_fair+0x12/0x1a
 [<c01112de>] dequeue_task+0x4b/0x58
 [<c0262524>] schedule+0x20e/0x22a
 [<c0129195>] unqueue_me+0x51/0x56
 [<c0129462>] futex_wait+0x2c8/0x2d5
 [<c0123f05>] hrtimer_wakeup+0x0/0x18
 [<c0129000>] get_futex_key+0x63/0xf5
 [<c0129746>] futex_wake+0xaf/0xb9
 [<c01267c1>] getnstimeofday+0x4c/0xca
 [<c011818c>] timespec_add_safe+0x1f/0x3e
 [<c0151bef>] poll_select_set_timeout+0x4b/0x65
 [<c0152120>] sys_poll+0x48/0x93
 [<c0102aa2>] syscall_call+0x7/0xb
Code: c6 89 44 24 1c eb 6d 8b 06 85 c0 0f 88 1b 01 00 00 8d 54 24 28 e8 dc 6f ff ff 85 c0 89 c7 0f 84 fd 00 00 00 8b 40 10 85 c0 74 13 <8b> 48 1c 85 c9 74 0c 8b 54 24 08 89 f8 ff d1 89 c2 eb 05 ba 45
EIP: [<c0151cea>] do_poll+0xa1/0x1dd SS:ESP 0068:cf8bfbec
---[ end trace 603310f43225a159 ]---

Alles anzeigen

Mit der Option -g geht es auch kurz, jedoch führt es schon nach kurzer Zeit zu einer Kernel Panic.

Vielleicht doch ein Problem mit dem Treiber?

Viele Grüße

heifisch

FireFly · 29. März 2009

Hei heifisch,
geht das femon Plugin bei Dir?

heifisch · 29. März 2009

Hab gerade mal femon 1.6.6 kompiliert und vdr damit gestartet.
Es läuft absolut stabil bei mir.

LiamHD · 30. März 2009

Zitat

Original von FireFly
- optionale Unterstützung hinzugefügt für das Einlesen der Bilder über die GrabImage-Funktion des VDR anstatt von /dev/video (neuer Parameter -g) (basierend auf dem Patch von e9hack)

Was ist der Vor- bzw. Nachteil von /dev/video bzw der GrabImage-Funktion? Könnte man die GrabImage-Funktion auch für das Atmo-Plugin nutzen?

Zitat

Original von FireFly
Durch die Umstellung auf V4L2 ist jetzt teilweise auch der gleichzeitige Zugriff mehrerer Anwendungen auf /dev/video möglich.

Was bedeutet "teilweise"?

FireFly · 30. März 2009

Zitat

Original von LiamHD
Was ist der Vor- bzw. Nachteil von /dev/video bzw der GrabImage-Funktion?

Vorteil von GrabImage ist, dass der VDR nur noch einmal /dev/video liest und das Bild dann mehreren Anwendungen wie vdradmin, Atmo-Plugin oder Avards zur Verfügung stellt. Dazu sollte die GrabImage-Funktion im VDR gepatched sein, damit es auch mehrere gleichzeitig bedienen kann. Wenn man das alles nicht benutzt, dann kann man genauso gut weiterhin /dev/video benutzen.

Zitat

Original von LiamHD

Was bedeutet "teilweise"?

Bei mir gings bisher immer gleichzeitig, d.h. mehrere Anwendungen konnten /dev/video öffnen, ich habe es aber nicht ausführlich getestet. Aufgefallen ist mir, dass in xawtv dann immer kurz ein Bild fehlt wenn Avards eins zur Auswertung bekommt. Immerhin muss der Device nicht ständig auf- und zugemacht werden, was deutlich Overhead spart. Ich sehe das aber eher als netten Nebeneffekt; wichtiger ist, dass V4L1 demnächst irgendwann mal wegfällt und deshalb sowieso auf V4L2 umgerüstet werden musste.

Samael · 30. März 2009

Moin,

der Vorteil der /dev/video-Variante ist, daß man dort mit einer Art
Double-Buffering arbeiten kann. Man bekommt das aktuelle Bild und
der Treiber meldet sich wieder, wenn er das nächste zur Verfügung
stellen kann usw.
Ist für Anwendungen, die zeitkritisch auf dem Framebuffer-Inhalt arbeiten,
notwendig und ist z.B. im Atmolight so umgesetzt.

Samael

e9hack · 30. März 2009

Zitat

Original von FireFly

Bei mir gings bisher immer gleichzeitig, d.h. mehrere Anwendungen konnten /dev/video öffnen, ich habe es aber nicht ausführlich getestet. Aufgefallen ist mir, dass in xawtv dann immer kurz ein Bild fehlt wenn Avards eins zur Auswertung bekommt.

So wie ich das verstehe, können zwar mehrere Anwendungen /dev/video öffnen. Es kann aber nur einer die Buffer-Queue belegen. Wenn das dann kontinuierlich gemacht wird, kommt nur noch die Anwendung zum Zug, die zuerst Zugriff auf die Queue hat. Daher habe ich ja für Avards/Atmo/Aurora/Live/VdrAdmin den GrabImage-Patch geschrieben. Wenn GrabImage() aufgerufen wird, startet ein Thread, der kontinuierlich grabbt. GrabImage() liefert dan das nächste verfügbare Image zurück. Wenn man GrabImage() kontinuierlich aufruft, bekommt man dann auch alle Einzelbilder. Man muß die nur schnell genug verarbeiten. Wenn gegrabbte Bilder nicht mehr per GrabImage() abgerufen werden, gibt der Thread /dev/video wieder frei und legt sich schlafen. Die Methode hat allerdings auch einen Nachteil: Das Grabben erfolgt immer mit voller Auflösung. Wenn GrabImage() mit niedrigerer Auflösung aufgerufen wird, muß das Bild erst noch runterskaliert werden.

Gruß
e9hack

e9hack · 30. März 2009

Hi,

es ist noch ein kleiner Bug in Avards. Die Variable ImageHeight wird nur gesetzt bzw. initialisiert, wenn ein Image gegrabbt wird. Startet der Vdr mit einer 16:9 Sendung, bleibt die Variable auf 0. Da wird dann die OSD-Größe falsch berechnet. Benutzt man das Skinsoppalusikka-Plugin, stürtzt der Vdr beim betätigen der Menu-Taste mit einem Segfault ab. Betätigt man die OK-Taste, wird die Senderinfo auf halber Bildhöhe, anstatt an der gewünschten Position angezeigt. Startet der Vdr mit einer 4:3-Sendung und schaltet später auf 16:9 um, ist alles perfekt. Der folgende Patch fixt das Problem:

Diff

diff -u avards-0.2.0/detector.c avards/detector.c
--- avards-0.2.0/detector.c     2009-03-29 17:41:45.000000000 +0200
+++ avards/detector.c   2009-03-30 22:21:12.000000000 +0200
@@ -536,7 +536,7 @@


                if (isPAL) { // PAL: setup WSS
                   isyslog("avards: switching WSS to %s", aAspectInfo[iAspectInfo].pszName);
-                  int BlackLines = ImageHeight - aAspectInfo[iAspectInfo].Lines;
+                  int BlackLines = iAspectInfo == 5 ? 0 : ImageHeight - aAspectInfo[iAspectInfo].Lines;
                   wssoverdrive->SetWSS(aAspectInfo[iAspectInfo].iWssData);
                   newtop    = iAspectInfo?Setup.OSDTop + BlackLines/2 : Setup.OSDTop;
                   newheight = iAspectInfo?Setup.OSDHeight - BlackLines : Setup.OSDHeight;

Alles anzeigen

Gruß
e9hack

heifisch · 31. März 2009

Hallo e9hack,

bei mir kommt es leider nach kurzer Funktion auch mit diesem Patch zum Absturz:

Code

Mar 31 08:12:59 vdr user.err vdr: [920] avards-detector thread started (pid=900, tid=920)
Mar 31 08:13:00 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:01 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:01 vdr user.err vdr: [920] avards: switching WSS to 4:3
Mar 31 08:13:01 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:02 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:03 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:04 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:05 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:05 vdr user.alert kernel: BUG: unable to handle kernel paging request at 4fb8fa4f
Mar 31 08:13:05 vdr user.alert kernel: IP: [<4fb8fa4f>] 0x4fb8fa4f
Mar 31 08:13:05 vdr user.warn kernel: *pde = 00000000
Mar 31 08:13:05 vdr user.emerg kernel: Oops: 0000 [#1]
Mar 31 08:13:05 vdr user.emerg kernel: last sysfs file:
Mar 31 08:13:05 vdr user.warn kernel: Modules linked in: lirc_serial lirc_dev
Mar 31 08:13:05 vdr user.warn kernel: Pid: 919, comm: tail Not tainted (2.6.29 #13)
Mar 31 08:13:05 vdr user.warn kernel: EIP: 0060:[<4fb8fa4f>] EFLAGS: 00257282 CPU: 0
Mar 31 08:13:05 vdr user.warn kernel: EIP is at 0x4fb8fa4f
Mar 31 08:13:05 vdr user.warn kernel: EAX: ca488000 EBX: b6f84db6 ECX: c02e44e8 EDX: ceb26a20
Mar 31 08:13:05 vdr user.warn kernel: ESI: 4eb7f94d EDI: f94eb7f9 EBP: b8fa4eb7 ESP: ca489f48
Mar 31 08:13:05 vdr user.warn kernel:  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Mar 31 08:13:05 vdr user.emerg kernel: Process tail (pid: 919, ti=ca488000 task=cf8b5350 task.ti=ca488000)
Mar 31 08:13:05 vdr user.emerg kernel: Stack:
Mar 31 08:13:05 vdr user.warn kernel:  00000000 00000001 0000c350 bfdbc070 c01244b2 c8dffb95 cedf9efc 00000000
Mar 31 08:13:05 vdr user.emerg kernel:  99704266 0000000e 996f7f16 0000000e c0123f05 c02ecc0c 00000000 ca489f84
Mar 31 08:13:05 vdr user.emerg kernel:  ca489f84 00000000 ca489fa8 bfdbc070 00000000 ca488000 c0124552 00000001
Mar 31 08:13:05 vdr user.emerg kernel: Call Trace:
Mar 31 08:13:05 vdr user.emerg kernel:  [<c01244b2>] hrtimer_nanosleep+0x6f/0xcc
Mar 31 08:13:05 vdr user.emerg kernel:  [<c0123f05>] hrtimer_wakeup+0x0/0x18
Mar 31 08:13:05 vdr user.emerg kernel:  [<c0124552>] sys_nanosleep+0x43/0x4f
Mar 31 08:13:05 vdr user.emerg kernel:  [<c0102aa2>] syscall_call+0x7/0xb
Mar 31 08:13:05 vdr user.emerg kernel: Code:  Bad EIP value.
Mar 31 08:13:05 vdr user.emerg kernel: EIP: [<4fb8fa4f>] 0x4fb8fa4f SS:ESP 0068:ca489f48
Mar 31 08:13:05 vdr user.warn kernel: ---[ end trace e96ecd4e1399f945 ]---
Mar 31 08:13:05 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:06 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:07 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:08 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:09 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:10 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:11 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:12 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:13 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:14 vdr user.err vdr: [920] grabbing to PNM 100 768 576
Mar 31 08:13:14 vdr user.alert kernel: BUG: unable to handle kernel paging request at dcf8cad9
Mar 31 08:13:14 vdr user.alert kernel: IP: [<dcf8cad9>] 0xdcf8cad9
Mar 31 08:13:14 vdr user.warn kernel: *pde = 00000000
Mar 31 08:13:14 vdr user.emerg kernel: Oops: 0000 [#2]
Mar 31 08:13:14 vdr user.emerg kernel: last sysfs file:
Mar 31 08:13:14 vdr user.warn kernel: Modules linked in: lirc_serial lirc_dev
Mar 31 08:13:14 vdr user.warn kernel: Pid: 920, comm: vdr Tainted: G      D    (2.6.29 #13)
Mar 31 08:13:14 vdr user.warn kernel: EIP: 0060:[<dcf8cad9>] EFLAGS: 00010282 CPU: 0
Mar 31 08:13:14 vdr user.warn kernel: EIP is at 0xdcf8cad9
Mar 31 08:13:14 vdr user.warn kernel: EAX: 00000000 EBX: d9e7ffd6 ECX: cd3172c0 EDX: e4ffcfdb
Mar 31 08:13:14 vdr user.warn kernel: ESI: f7d0dfff EDI: 00000000 EBP: cedf8000 ESP: cedf9fa4
Mar 31 08:13:14 vdr user.warn kernel:  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Mar 31 08:13:14 vdr user.emerg kernel: Process vdr (pid: 920, ti=cedf8000 task=cf8b1990 task.ti=cedf8000)
Mar 31 08:13:14 vdr user.emerg kernel: Stack:
Mar 31 08:13:14 vdr user.warn kernel:  d1def9cd f9d1def9 e0fdd1dc d3defbd5 fccfdaf9 defed4df d4deffd5 ffd5deff
Mar 31 08:13:14 vdr user.emerg kernel:  e1ffd5df d5e0ffd7 ffd5defe e0ffd4e0 d0e1ffd0 0000007b 00000000 00000036
Mar 31 08:13:14 vdr user.emerg kernel:  b7c67c04 00000073 00000246 b79cdf98 0000007b c2839e74 c2fd4a0f
Mar 31 08:13:14 vdr user.emerg kernel: Call Trace:
Mar 31 08:13:14 vdr user.emerg kernel: Code:  Bad EIP value.
Mar 31 08:13:14 vdr user.emerg kernel: EIP: [<dcf8cad9>] 0xdcf8cad9 SS:ESP 0068:cedf9fa4
Mar 31 08:13:14 vdr user.warn kernel: ---[ end trace e96ecd4e1399f946 ]---

Alles anzeigen

Allerdings bleibt der VDR bedienbar. Nur das Bild bleibt in diesem Fall auf 4:3 auch wenn eine 16:9 Sendung vorliegt und auch wenn ich die Erkennung ausgeschalten habe.

Mit welchen Treibern funktioniert es dann bei euch?

Mit dem im Kernel 2.6.29 enthaltenen und fest eincompilierten hab ich große Probleme.

Oder kann noch ein Fehler in der Kernelkonfiguration sein?

Viele Grüße

heifisch

udobroemme · 31. März 2009

Du suchst an der falschen Stelle. Falls Du noch andere Plugins o.ä. laufen hast, die die GrabImage-Funktion nutzen (z.B. Atmolight), musste Du die entsprechenden Patches von e9hack einspielen. Ich habe sie hier nochmals angehängt.
Avards muss in der neuen Version nicht mehr gepatcht werden.

heifisch · 31. März 2009

Hallo udobroemme,

Original von udobroemme

Zitat

Du suchst an der falschen Stelle. Falls Du noch andere Plugins o.ä. laufen hast, die die GrabImage-Funktion nutzen (z.B. Atmolight), musste Du die entsprechenden Patches von e9hack einspielen. Ich habe sie hier nochmals angehängt.
Avards muss in der neuen Version nicht mehr gepatcht werden.

Meintest Du mich?

Ich benutze, um andere Ursachen auszuschließen, zum Testen nur:
- Vanilla-Kernel 2.6.29,
- Vanilla-VDR 1.6.0.2,
- nur das Avards-Plugin,

Wenn es denn da bei mir stabil läuft, packe ich es mit in mein Produktiv-System.
Bis dahin teste ich mit ungepatchtem VDR und ausschließlich dem Problem verursachenden Plugin.
Wobei der Fehler nicht im Plugin liegen muss...

heifisch

LiamHD · 31. März 2009

Zitat

Original von FireFly
..wichtiger ist, dass V4L1 demnächst irgendwann mal wegfällt und deshalb sowieso auf V4L2 umgerüstet werden musste.

Was ist denn nun wieder V4L1 und V4L2?

heifisch · 31. März 2009

Zitat

Original von LiamHD

Was ist denn nun wieder V4L1 und V4L2?

video4linux

V4L2 ist die 2. Generation

Infos gibt es hier:

http://linuxtv.org/v4lwiki/

e9hack · 31. März 2009

Zitat

Original von heifisch
bei mir kommt es leider nach kurzer Funktion auch mit diesem Patch zum Absturz

Der Absturz bei den beschriebenen speziellen Bedingung hat nichts mit Deinem Absturz zu tun. Die von Avards gelieferte OSD-Höhe ist negativ und das Skinsoppalusikka-Plugin berechnet vermutlich irgenwelche Offsets mit falschem Vorzeichen und greift im User-Mode auf nicht belegte Adressbereiche zu.

Zitat

Mit welchen Treibern funktioniert es dann bei euch? Mit dem im Kernel 2.6.29 enthaltenen und fest eincompilierten hab ich große Probleme.

Ich verwende normalerweise das aktuelle Repository von LinuxTV. Ich kann das Problem mit fest einkomplierten Modulen bei Kernel 2.6.29 nicht nachstellen. Bei mir ist es aber 64bittig.

Zitat

Oder kann noch ein Fehler in der Kernelkonfiguration sein?

Ich tippe auf einen verkonfigurierten Kernel, zu wenig Speicher und/oder nicht genügen vmalloc-Adressraum bei 32-Bit.

Gruß
e9hack

3PO · 31. März 2009

Schade dass das Plugin nicht mit der eHD funktioniert.

heifisch · 31. März 2009

Zitat

Original von e9hack
Der Absturz bei den beschriebenen speziellen Bedingung hat nichts mit Deinem Absturz zu tun. Die von Avards gelieferte OSD-Höhe ist negativ und das Skinsoppalusikka-Plugin berechnet vermutlich irgenwelche Offsets mit falschem Vorzeichen und greift im User-Mode auf nicht belegte Adressbereiche zu.

Ich tippe auf einen verkonfigurierten Kernel, zu wenig Speicher und/oder nicht genügen vmalloc-Adressraum bei 32-Bit.

Hmm... den VIDEOBUF_VMALLOC gibt es nur wenn man VIDEO_VIVI aktiviert. Und dann belegt es wohl /dev/video0...

Code

CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_COMMON=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_DVB_CORE=y
CONFIG_VIDEO_MEDIA=y
CONFIG_VIDEO_SAA7146=y
CONFIG_VIDEO_SAA7146_VV=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEOBUF_GEN=y
CONFIG_VIDEOBUF_DMA_SG=y
CONFIG_VIDEOBUF_VMALLOC=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_VIDEO_FIXED_MINOR_RANGES=y
CONFIG_VIDEO_VIVI=y
CONFIG_DVB_CAPTURE_DRIVERS=y
CONFIG_DVB_AV7110=y
CONFIG_DVB_AV7110_FIRMWARE=y
CONFIG_DVB_AV7110_FIRMWARE_FILE="/usr/src/firmware/dvb-ttpci-01.fw"
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_FE_CUSTOMISE=y
CONFIG_DVB_STV0299=y
CONFIG_DVB_TDA8083=y
CONFIG_DVB_VES1X93=y

Alles anzeigen

Den Absturz hab ich dann trotzdem.
Und die Abhängigkeiten bei der Kernel-Konfiguration werden ja eigentlich mit "make menuconfig" ganz gut gehandhabt. Sonst ist der Kernel auch absolut stabil.

Grüße
heifisch

SurfaceCleanerZ · 11. April 2009

Hi,
teste doch mal nen Standardkernel mit laktuellem liblianin.
Btw: Hat der 29 nich noch Riesenbugs? Hatte da was gelesen.... Evtl. mal 2.6.28.9 testen?

mfG

Frodo · 11. April 2009

Zitat

Original von heifisch

video4linux

V4L2 ist die 2. Generation

Infos gibt es hier:

http://linuxtv.org/v4lwiki/

Alles anzeigen

Und wo sollen die Infos sein? Überall bekomme ich die Meldung "The action you have requested is limited to users in the group user. ".

Ich würde mich freuen wenn ich verstehen könnte was nun an der Version2 anderst ist als bei der ersten.

FireFly · 11. April 2009

Zitat

Original von Frodo
Überall bekomme ich die Meldung "The action you have requested is limited to users in the group user. ".

So ein Schwachsinn, das sind doch keine geheimen Infos - die kann man doch öffentlich zugänglich machen!

V4L1 ist seit einem Jahr deprecated and scheduled for removal, allein das ist ein Grund auf V4L2 umzustellen, dessen erste Draft bereits im Dezember 2002 erschienen ist. Insbesondere das Streaming soll damit besser gehen (dropouts vermeiden), aber für Avards ist es eher ein Rückschritt, weil ja keine kompletter Stream abgegriffen wird sondern nur ab und zu ein einzelnes Bild. Mehr zum V4L2 API gibts z.B. bei LWN oder bei Dr. Google.

FireFly

[ANNOUNCE] Avards-Plugin 0.2.0

Jetzt mitmachen!

Teilen