media-build-dkms

Zitat von jasminj

Hinter der Aussage stehe ich immer noch.

Also: Du kennst den Ausgabe-Teil des DVB-API (audio/video/osd) nicht, Du benutzt es nicht, Du hast nie etwas dazu beigetragen, Du kennst die ganze Entwicklungshistorie nicht. Du hast anscheinend mit niemandem darueber gesprochen, auf den irgendwas davon zutrifft.

Trotzdem glaubst Du, oeffentlich ein Urteil ueber die Entwickler dieses API, der zugehoerigen Treiber, des VDR, seiner Plugins faellen zu muessen: Sie sind unfaehig und machen ihre Hausaufgaben nicht!? Und bist auch noch stolz drauf? Da bleibt mir ja wirklich die Luft weg.

In der Tat war dieses API vor Mauro da, es bildet die Grundlage fuer die gesamte VDR-Entwicklung, es gibt funktionierende Treiber, funktionierende Hardware, VDR-Anwender, die alles das nutzen und damit voll zufrieden sind. Und es gibt einen sogenannten Maintainer von linux-media, der dieses API nicht versteht, nicht verstehen will, es fuer deprecated erklaert (kenn ich nich, kann weg), ohne auch auf mehrfache Nachfrage einen technischen Grund dafuer angeben zu koennen, oder gar einen Migrationsplan zu haben, welches andere man denn wie anstelle dieses "veralteten" API benutzen soll. Und genau das ist eben der Unterschied zu einem sinnvollen Vorgehen, mit einem richtigen Maintainer, auch in Deinem deshalb hier gerade nicht zutreffenden Beispiel.

Entschuldigung, dass diese Diskussion nicht perfekt in diesen Thread passt, Du hast aber dieses Thema aufgebracht, und ich konnte das nicht so stehen lassen.

Ich glaube ihr redet aneinander vorbei und habt beide Recht.

Deprecated ist Ziffer 6 der API, und hier insbesondere die Decoder-ioctls in Ziffer 6.2 und 6.3. Dieses API wurde zunächst ausschließlich von vdr (zunächst im core, später im dvbsddevice-Plugin) genutzt. Zu der Zeit war die alte SD-FF-Karte (Treiber dvb-ttpci) der einzige Hardwaredecoder, der vom Linux-Kernel unterstützt wurde. Vor über 10 Jahren kam dann der ivtv-Treiber dazu und benutzte für den Hardwaredecoder der PVR350 ebenfalls dieses API, was wegen weiterer Besonderheiten der Karte aufgebohrt wurde. Das von mir damals mitentwickelte pvr350-Plugin war dann lange Zeit neben dem dvbsddevice-Plugin das einzige Userspace-Programm (sieht man mal von Testfunktionen in v4l2-ctl ab), das dieses API nutzte.

Von mir völlig unbemerkt (wer nutzt heute schon noch reine MPEG2-Decoder und SDTV?) und vermutlich auch von der Mehrheit der vdr-Nutzer (das dvbsddevice-Plugin ist mittlerweile nicht mehr Bestandteil der vdr-Sourcen) wurde das API in Teil 6 dann für obsolet erklärt (sicher keine einsame Einzelentscheidung von Mauro) und durch neue ioctls in Ziffer 7 ersetzt. Vorausgegangen war eine intensive Diskussion in der community , wie dieses Posting zeigt. Der ivtv-Treiber wurde entsprechend angepasst - die alten ioctls aus dvb/video.h und dvb/audio.h sind dort zwar noch enthalten, aber als deprecated gekennzeichnet. Der Treiber unterstützt also schon das neue API. Analog hätte jetzt eigentlich auch der dvb-ttpic-Treiber (und in der Folge ggf. das dvbsddevice-Plugin, sofern es noch jemand benutzt) angepasst werden müssen, aber nachdem UFO schon vor Jahren entnervt das Handtuch geworfen hatte, hat der Treiber ja keinen Maintainer mehr.

Dass das dvbhddevice-Plugin und der Treiber für die TT6400 einige ioctls des alten API (Teil 6) benutzten, war mir bislang neu. Dass Mauro schon in der Phase, wo die alten ioctls nur als deprecated markiert, aber noch vorhanden sind, das ioctl AUDIO_GET_PTS einfach rausschmeisst, nur weil es nicht in der API dokumentiert ist, war sicher schwach. Man hätte sich ja auch stattdessen fragen können, ob vielleicht nur die Dokumentation unvollständig ist. Auch hätte er merken müssen, dass zumindest ein im Kernel enthaltener Treiber (dvb-ttpci) es noch unterstützt hat. Wie auch immer, das ist ja nun wieder drin. Es löst aber das Problem nicht, dass irgendwann die deprecated ioctls rausfliegen werden. In einer idealen Welt hätten Treiber-Maintainer und Userspace-Entwickler jetzt geprüft, ob das gewünschte Ziel mit einem der neuen ioctls aus Teil 7 darstellbar ist bzw. ob man überhaupt ein ioctl dafür braucht - und wenn das nicht möglich ist, einen entsprechenden Vorschlag zur Erweiterung des neuen API gemacht.

Ein ganz wesentliches Problem bleibt aber offen: Auch das neue API orientiert sich am Bedarf von MPEG2-Dekoderkarten. Ich gehe mal davon aus, dass ein h264-Dekoder ganz andere Anforderungen stellt und andere, zusätzliche ioctl braucht. In der Situation dann nur auf das v4l2-API (Teil 7) zu verweisen und den Entwickler alleine damit zu lassen, notwendige Erweiterungen vorzuschlagen und durchzusetzen, ist etwas mager für einen linuxtv-Maintainer.

Abschließend sei allerdings die Frage erlaubt, ob es wirklich sinnvoll ist, für einen einzigen existierenden h264-Hardwaredekoder, der zudem keine große Verbreitung hat und schon lange nicht mehr als Neuware erhältlich ist, viel Zeit in die Erweiterung eines API zu investieren. Die TT6400 kann nichtmal FullHD ausgeben, und schon in wenigen Jahren wird sie genauso vergessen sein wie die SD-FF-Karte oder die PVR350. Von daher könnte es vielleicht zielführender sein, den Treiber außerhalb des Kernels zu lassen. Denn eins ist klar: Wenn er es in den Kernel schafft, dann nur mit neuen ioctls. Es müsste in der Folge also auch noch jemand gefunden werden, der das dvbhddevice-Plugin entsprechend anpasst.

Zitat von Dr. Seltsam

Die TT6400 kann nichtmal FullHD ausgeben

hartnäckig halten sich weiterhin solche Fake-News --> TechnoTrend Premium S2-6400 dual HD Technik / Features /Ankündigungen

[Work in Progess] mplayer für TT6400

(ändert aber am derzeiten Nutzen nichts)

Zitat von Dr. Seltsam

Denn eins ist klar: Wenn er es in den Kernel schafft, dann nur mit neuen ioctls

Vielen Dank fuer die ausfuehrliche Erklaerung, die leider im Wesentlichen die voellig unpassenden Ansichten von linux-media wiederholt. Genau das alles trifft eben gerade nicht auf das audio/video DVB-API zu, wie es von ttpci und saa716x verwendet wird. Es ist kein API speziell fuer einen Dekoder, auch wenn es dafuer entwickelt wurde, und damit etwas voellig anderes, als ein v4l2 decoder API mit gigantisch groesserer Komplexitaet.

saa716x nutzt dieses audio/video-DVB-API, um einen DVB-TS-Strom per device-write an die Karte zu schicken. Dazu gibt es noch drei ioctls: Buffer fuer diesen Stream resetten, den PTS des TS-Pakets am Ende das Buffers lesen, die Quelle dieses TS-Stream vom genannten device-write auf ein DVB-Frontend auf der Karte umschalten.

Es ist also einzig ein API, um einen TS auszugeben. Dass der nun gerade in diesem Fall an einen Dekoder geht, und nicht z.B. auf eine Leitung oder einen DVB-C-Transmitter, oder was-auch-immer, hat exakt nichts mit dem API zu tun. Somit ist auch voellig egal, ob in dem Strom MPEG-2, H.264, H.265 oder etwas anderes steckt. Und ja, es gibt quasi als Debug-Mode bei saa716x die Moeglichkeit, ein einzelnes dekodiertes Bild alle mehrere 100ms von dem video-Device zu lesen. Dafuer aber alles auf v4l2 umzustellen ergibt gar keinen Sinn (wer will sich denn so eine Dia-Show in kaffeine ansehen?), dann lieber diesen Mode entfernen. Waere halt bloed fuer VDR-Skin-Entwickler, ist aber keine Kernfunktionalitaet.

Diese drei genannten ioctls sind so einfach, dass sie nun wirklich keinerlei nennenswerten Maintainance-Aufwand bedeuten, zumal sie ja auf die beiden FF-Treiber beschraenkt sind und keinerlei Interaktion irgendwo anders erfordern. Auch gibt es die Dokumentation dafuer schon, man braucht gar nichts zusaetzlich. Es muss ueberhaupt keine Zeit in irgendwelche Anpassungen des API investiert werden, da ja alles fuer ttpci schon da ist (oder sich fuer AUDIO_GET_PTS wieder herstellen laesst). Ich habe auch bereits angeboten, die Verwaltung dieses API fuer beide Treiber zu uebernehmen, wenn gewuenscht.

Eventuell noetige Anpassungen am dvbhddevice-Plugin sind eine Sache einer halben Stunde, solange dieses super-einfache DVB-API weiter genutzt werden kann und nicht alles auf v4l2 umgestellt werden muss. Fuer so eine Umstellung gibt es keinen technischen Grund. Es wird nur gefordert, weil offenbar alle glauben, dieses API waere nur eine alte Version eines v4l2-Dekoder-APIs, was es aber definitiv nicht ist. Es ist ein viel einfacheres API, das eben nicht die ganze Komplexitaet hat, die man zwar fuer eine Dekoder-Steuerung durch den Treiber braucht, hier jedoch nicht, weil das alles in der Kartenfirmware steckt und der Linux-Treiber nichts damit zu tun hat.

Anzumerken ist noch, dass die Steuerung der Karte ueber das OSD-Device erfolgt. Hier hatte Mauro aber signalisiert, dass er die API-Anpassungen dafuer uebernimmt (ob er sich daran noch erinnert, ist wie vieles andere in seiner Kommunikation unklar).

Gruss,

S:oren

Zitat von jasminj

Vielleicht schafft es der Treiber ja doch nach Staging.

Eher nicht. Mauro wollte ihn explizit nicht in staging. Deshalb habe ich bereits alles aufgeraeumt, was ich (und checkpatch.pl) fuer noetig hielt.

Gruss,

S:oren

jasminj

Hi , ich nutze dein dkmsbuild und wollte mal kurz feedback geben

Erstmal vielen dank dafür...

Es läuft spitze unter ubuntu 18.04, aber ja, teilweise dauern die updates ewig, insbesondere wenn ich mal wieder nach mehreren kernel updates die alten raus werfe

Ich habe im startpost etwas von einem speedpatch gelesen, wo kann ich denn was modifizieren ?

LG

Zitat von DeBaschdi

Ich habe im startpost etwas von einem speedpatch gelesen, wo kann ich denn was modifizieren ?

jasminj hatte dort im Startpost einen Link angegeben:

Zitat von jasminj

Und das De-Installieren braucht ohne dem DKMS Speed Patch extrem lange!

DKMS Speed Patch

dort ganz unten, als Anhang