V4L API 1 deprecation Dezember 2008

Zitat

Leider betrifft das den Großteil unserer VDR-Geräte, denn die meisten werden wohl eine TT-Karte drin haben, für die es nur API1-module gibt.

Die Module der FF-TT-Karte benutzen intern v4l2. Es gibt nur noch eine v4l1 Funktion, die sich nicht per Wrapper übersetzen läßt.

Zitat

Wie sieht's da eigentlich mit dem VDR selbst aus? Basiert der auf VfL1?

Der Vdr hat nicht viel mit v4l zu schaffen. Das v4l-API darf man nicht mit dem DVB-API verwechseln. GrabImage() benutzt v4l1-Funktionen. Das sollte sich aber relativ einfach umstellen lassen.

Gruß
e9hack

Zitat

Original von e9hack
GrabImage() benutzt v4l1-Funktionen. Das sollte sich aber relativ einfach umstellen lassen.

ist das eine Freiwilligen-Meldung?
ich wüsste nicht, wer das sonst könnte. Ob UFO dazu noch Lust hat, nachdem er die Maintainer-Funktion abgegeben hat ...

Zitat

Original von Dr. Seltsam

ist das eine Freiwilligen-Meldung?
ich wüsste nicht, wer das sonst könnte. Ob UFO dazu noch Lust hat, nachdem er die Maintainer-Funktion abgegeben hat ...

Die Änderung betrifft doch nur vdr, nicht den Treiber. Und die grab-Funktion war noch nie meine Baustelle.

CU
Oliver

d.h. der Treiber ist inzwischen vollständig auf v4l2 angepasst?

Zitat

Original von Dr. Seltsam
d.h. der Treiber ist inzwischen vollständig auf v4l2 angepasst?

Wird sich zeigen. xawtv-3.95 bringt jedenfalls auch bei deaktivierter v4l1-Unterstützung ein Bild.

CU
Oliver

P.S.:
Für derartige Aktionen habe ich keinerlei Verständnis. Imho dürften innerhalb eines Stable-Kernel-Zyklus (wie 2.6.x) existierende Schnittstellen nicht entfernt werden. So etwas ist für Anwendungsentwickler einfach nur ärgerlich.

Zitat

Originally posted by UFO
Für derartige Aktionen habe ich keinerlei Verständnis. Imho dürften innerhalb eines Stable-Kernel-Zyklus (wie 2.6.x) existierende Schnittstellen nicht entfernt werden. So etwas ist für Anwendungsentwickler einfach nur ärgerlich.

Das ist das neue Entwicklungskonzept. Die alte stable/development-Trennung gibts nicht mehr und wirds nach Linus auch nicht mehr geben, wenn sich nicht sehr gewichtige Gründe dafür finden sollten.

Stable ist alles, was kein rc hat, Development ist zwischen stable und rc1, danach wird der nächste stable vorbereitet. Was rausfliegt, wird einige Versionen vorher deprecated, irgendwann ist es halt soweit.

Zitat

Original von linuxservice

Das ist das neue Entwicklungskonzept. Die alte stable/development-Trennung gibts nicht mehr und wirds nach Linus auch nicht mehr geben, wenn sich nicht sehr gewichtige Gründe dafür finden sollten.

Ist bekannt. Nur ist das vom Standpunkt der Qualitätssicherung kein Konzept, sondern das reine Chaos. Kein verantwortungsbewußter Mensch kann 2.6er Kernels in sicherheitskritischen Anwendungen einsetzen.

Zitat

Stable ist alles, was kein rc hat, Development ist zwischen stable und rc1, danach wird der nächste stable vorbereitet. Was rausfliegt, wird einige Versionen vorher deprecated, irgendwann ist es halt soweit.

Meiner Meinung ist nun alles einfach unstable, da ungenügend getestet. Man braucht ja nur die Changelogs zu lesen...

CU
Oliver

Zitat

Original von shh
Hi, ich bin gerade drüber gestolpert, dass die Video4Linux API1, die schon länger "überholt" ist, im Dezember aus dem Kernel geschmissen wird:

Au weh! Ich hatte mich da schon mal an Avards und V4L2 versucht, habe das aber wegen des enormen Aufwands abgebrochen:
Unter V4L1 kann man einfach dem API sagen: "Gibt mir mal ein Bild!".
Bei V4L2 muss man mehr oder weniger einen Stream initialisieren, grabbing starten und kann dann kontinuierlich Bilder abfragen. Für Streaming wesentlich einfacher (weil so kein Bild mehr so leicht verloren geht), für Snapshots (wie es grabimage, Avards und einige andere Plugins benötigen) eine Katastrophe...

Vielleicht wäre eine VDR-Anpassung/Erweiterung, die Snapshots zur Verfügung stellt eine Lösung?

Zitat

Original von FireFly

Au weh! Ich hatte mich da schon mal an Avards und V4L2 versucht, habe das aber wegen des enormen Aufwands abgebrochen:
Unter V4L1 kann man einfach dem API sagen: "Gibt mir mal ein Bild!".
Bei V4L2 muss man mehr oder weniger einen Stream initialisieren, grabbing starten und kann dann kontinuierlich Bilder abfragen. Für Streaming wesentlich einfacher (weil so kein Bild mehr so leicht verloren geht), für Snapshots (wie es grabimage, Avards und einige andere Plugins benötigen) eine Katastrophe...

Vielleicht wäre eine VDR-Anpassung/Erweiterung, die Snapshots zur Verfügung stellt eine Lösung?

Im hg-Repository gibt es unter ./v4l2-apps/test eine Capture-Demo, die alle 3 Buffer Varianten zum capturen verwendet. So kompliziert sieht das nicht aus.

Ein Stream darf auch aus nur einem Bild bestehen.

Gruß
e9hack

Zitat

Original von e9hack
Im hg-Repository gibt es unter ./v4l2-apps/test eine Capture-Demo, die alle 3 Buffer Varianten zum capturen verwendet. So kompliziert sieht das nicht aus.

Das dachte ich auch, aber irgendwann habe ich es dann abgebrochen. Ich glaube ein weiterer Grund war das Umrechnen der Bilder in Graustufen, das V4L2 nicht mehr selbst macht.

Zitat

Original von e9hack
Ein Stream darf auch aus nur einem Bild bestehen.

Ja, schon klar. Trotzdem ziemlich viel Overhead wenn man den ständig starten, synchronisieren, abholen und stoppen muss (wenn ich das noch richtig in Erinnerung habe)
Die beste Lösung wäre IMHO eine VDR-Erweiterung, die das allen zur Verfügung stellt. Evtl. ist für VDR 1.7.x ja auch sowas geplant, aber da hat wohl S2API momentan wesentlich höhere Priorität.

Gruß
FireFly

Zitat

Original von FireFly
Die beste Lösung wäre IMHO eine VDR-Erweiterung, die das allen zur Verfügung stellt.

Die Lösung hat der vdr bereits eingebaut und heißt GrabImage().

Gruß
e9hack

Zitat

Original von e9hack
Die Lösung hat der vdr bereits eingebaut und heißt GrabImage().

Hmm, so hab ich das noch nie gesehen ...