Beiträge von mighty-p

    Also den Effekt, dass sich VDR mit vaapidevice beendet, wenn es kein Profil "VAProfileNone" mit EntryPoint "VAEntrypointVideoProc" gibt, kann man verhindern, indem man in der video.c vom vaapidevice-Plugin die Zeile 2654 von

    Code
    1. Fatal("video/vaapi: can't create config '%s'", vaErrorStr(status));

    ändert in

    Code
    1. Error("video/vaapi: can't create config '%s'", vaErrorStr(status));

    Dann müsste es jedenfalls ein Bild geben. In wieweit das Bild (vor allem bei interlaced und fehlendem De-Interlacer) qualitativ akzeptabel ist, muss man dann sehen.


    Die andere Frage ist: Warum fehlt hier überhaupt der VAEntrypointVideoProc? Der Haswell müsste das doch eigentlich haben, oder doch nicht?

    Also es wird dran liegen, dass es bei dir das "VAProfileNone" nicht gibt, warum auch immer das so ist. Ich habe bei mir nämlich die video.c so gepatched, dass er immer den Pfad läuft, als wäre dieses Profil nicht da, und dann kommt es zu genau dem von dir beschriebenen Verhalten, dass sich vdr beendet. Ich denke, das ist ein Bug und schaue mir das gerade etwas genauer an.

    M-Reimer schrieb:

    Ein zentrales, großes, modulares Projekt allgemein für "Ausgabe über Grafikkarte" wäre sinnvoll gewesen. Schon weil z.B. die Tonausgabe ja über alle möglichen Optionen immer gleich ist. Wenn man Audio auch "modular" hätte, könnte man da auch mal direkte pulseaudio-Ausgabe reinbauen...


    [...]

    Kodi bekommt mit Version 18 sogar Amazon Prime und Netflix (natürlich inklusive DRM). Wenn man einen reinen Receiver will, dann ist VDR nach wie vor gut.


    Ich frage mich auch immer mehr, ob das ganze Gewurschtel mit verschiedenen Forks von softhddevice, die zwar alle mehr oder weniger funktionieren, aber bei denen man nicht mehr durchsteigt und die alle das Problem haben von nur sehr wenigen (oft nur einem?) Entwickler abhängig zu sein, noch Sinn macht.


    Vielleicht ist es an der Zeit, vdr einfach als Server zu sehen (vielleicht ihn in Zukuft sogar irgendwann dazu "zurückzubauen") und auf Kodi als Frontend zu setzen. Ich schrecke davor immer noch ein bisschen zurück, da ich Kodi als überladen empfinde. Andererseits muss man sagen, dass Kodi konstant weiterentwickelt wird und alle Grafikkarten und zugehörigen APIs wirklich optimal (im Sinne von: so optimal wie es hard- und softwaremäßig unter Linux geht) unterstützt.

    Mir ist noch etwas eingefallen, was du testen könntest. Interessant wäre zu wissen, ob den vaapi noch mit anderen Programmen funktioniert. Gut zum Test eignet sich der Video Player "mpv", da er vaapi exzellent unterstützt. Daher wäre es interessant, ob (bei installiertem mpv) folgendes Kommando ein Video korrekt abspielt:

    Code
    1. mpv --hwdec=vaapi --vo=opengl /path/to/my/video.mpg

    Also ich wundere mich in der Ausgabe von vainfo über das fehlende VAProfileNone. Das braucht man nämlich für das VAAPI-Postprocessing. Ich gehe mal davon aus, dass daher auch diese Meldung "can't query entrypoints: the requested VAProfile is not supported" her rührt.


    Du könntest mal versuchen, ob du ein Bild kriegst, wenn du in den Plugin-Einstellungen alle Postprocessing-Filter ausschaltest (Color Balance aus, Skin Tone Enhancement 0 [oder 50, bin nicht sicher], für alle Auflösungen Deinterlace aus, Denoise und Schärfen 0 [oder 50, bin nicht sicher]). Evtl. fordert vaapi dann das VAProfileNone nicht an. Aber ich bin mir da nicht sicher (muss gleich mal im Source-Code gucken) und außerdem wäre das Bild sicher deutlich schlechter als gewohnt.


    Die eigentliche Frage ist halt: Warum fehlt das VAProfileNone hier? Kann die Karte eventuell wirklich kein Postprocessing weil sie zu alt ist?


    [Edit]: Kurz mal in den Source-Code vom vaapidevice geschaut (video.c): Eigentlich sollte bei nicht vorhandenem Postprocessing auf der Hardware einfach das Postprocessing ausgeschaltet und das Bild halt unprocessed angezeigt werden. Ich habe bei mir mal einfach in der video.c die Variable VaapiVideoProcessing hart auf 0 gesetzt und kriege immer noch ein Bild.

    Andere Frage: Um welche Empfangsart geht es und ist es SD oder HD? Davon hängt nämlich auch der Codec ab.

    localhosthack0r Danke für's Log. Das -F erhöht eigentlich nur den Timeout beim Auslesen der Kanalinfos. Es kann natürlich sein, dass ohne -F der Default Timeout hier wirklich zu kurz ist, daher nicht alles gelesen ist (es sind ja recht viele Programme da auf einem Kanal) und daher die Programme nicht in der Kanalliste landen. Kann VDR denn die connect Kanäle bei dir abspielen?
    Was mich auch noch wundert ist, dass auf 498000 auch Programme gefunden werden (Pro Sieben HD usw). Die sollten eigentlich nicht auf PLP 1 liegen.

    Ich habe gerade mal eine Änderung ins GIT übernommen, um mit dem Parameter "-p" die PLP ID für DVB-T2 setzen zu können. Damit kann man jetzt z. B. auch die "connect"-Kanäle bei DVB-T2 finden (PLP 1 auf dem ZDF-Kanal) sowie ein zusätzlichen Standbild/Info-Kanal (PLP 1 im dritten freenet-Mux).


    t2scan -t2 -p1 -F


    Das "-F" braucht man eigentlich nicht, aber meine DVB-T2-Karte scheint Probleme zu haben, auf der zweiten PLP im ZDF-Kanal (wo die "connect"-Sender zu finden sind) sauber zu tunen.


    Mich würde interessieren, ob bei euch mit dem o.g. Befehl die "connect"-Kanäle gefunden werden und ob "-F" bei euch auch nötig ist. Bei mir braucht es manchmal auch trotz des "-F" mehrere Versuche (falls das passiert, kann man mit "-l<kanalnummer>" ja auf den ZDF-Kanal einschränken, damit nicht alle Kanäle immer durchgelaufen werden müssen).


    Außerdem würde ich mich interessieren, ob VDR die "connect"-Kanäle überhaupt abspielen kann!? Bei mir scheint es nicht zu klappen, evtl. liegt das aber man Tuning-Problem meiner Karte. Der zusätzliche Standbild-Kanal dagegen wird bei mir abgespielt, wenn auch manchmal mit Unterbrechungen (auch da geht wohl der Lock verloren...).

    Hast du mal irgendwelche DVB-Treiber manuell installiert (also z.B. den media_build oder irgendwelche proprietäre Treiber direkt vom Kartenhersteller) und dann wieder ein Kernel-Paket der Distribution installiert? Ich kann mir nämlich eigentlich nicht vorstellen, dass eine Distribution mit einem so kaputten Kernel daher kommt. wirbel hat Recht, dass man das aufräumen sollte/muss. Order du kannst mal versuchen, besagten media_build einfach drüber zu installieren (ist evtl. Pfusch, aber vielleicht klappt es auch).

    Neue Version 0.3 ist soeben released worden. Enthält die Markierung von doppelten Multiplexen und Services (Parameter "-d"), automatisches Entfernen solcher Duplikate (Expertenoption "-D"), sowie den Fix für das Problem dass im VDR>=2.1-Format bei manchem Services die Audio-PID fehlte (das war ein "alter" Bug noch aus w_scan).

    Da mir keine wirklichen Probleme mit den letzten Git-Ständen berichtet wurden, habe ich nun t2scan 0.2 released (https://github.com/mighty-p/t2scan/releases). Vielen Dank an alle, die getestet und mir im Thread oder per Direktnachricht Rückmeldung gegeben haben!


    Ein Problem von t2scan derzeit ist, dass bei mehrfachem Empfang eines Programmes dieses dann auch doppelt (oder ggfs. noch öfters) in der ausgegebenen channels.conf steht. Der optionale Schalter "-d" kann zwar helfen, aber hier will ich in Zukunft etwas Besseres bauen und idealerweise das ioctl der DVB API nutzen, um das Programm nur vom am besten zu empfangenden Kanal zu nehmen. Entsprechende Änderungen werdet ihr bald im GIT sehen. Kann durchaus sein, dass v.a. der Schalter "-d" dann bei euch gar nicht geht oder instabil läuft. Das nur zur Info :)

    So, neue Änderungen wurden gerade ins GIT hochgeladen.


    Ich habe mal etwas bei den ganzen Optionen sortiert. DIe waren ja bis jetzt alle von w_scan übernommen. U.a. hab ich die ganzen Schalter für die Ausgabeformate durch einen einzigen "-o", der halt nen Parameter kriegt, ersetzt. Das finde ich einfacher. Dabei habe ich gerade auch das Default-Ausgabeformat von vdr 2.0 auf vdr 2.1.x geändert. Falls das keine gute Idee ist, sagt Bescheid, dann mach ich's rückgängig. An der eigentlichen Scan-Logik hat sich nichts geändert.


    "t2scan -h" zeigt jetzt wirklich nur noch die paar Optionen an, die für den normalen User Sinn machen. Alles andere ist in der Expertenhilfe "-H". Die man-Page ist auch entsprechend überarbeitet.


    Wenn es mit diesem Stand keine Probleme gibt, werde ich wohl am Sonntag oder Montag ein neues Release v0.2 erzeugen.


    jsffm - Danke für's Testen. Weitere Testberichte von anderen Usern sind gerne willkommen.

    :thumbup:


    Ich werde dann im GIT nachher die drei Dateien "proforma" hinzufügen. Bin eh gerade an t2scan am arbeiten. Bin die Optionen weiter am vereinfachen.


    Für die, die sich gerade an "-k" und "-K" (niedrigster, höchster Kanal zum Scannen) gewöhnen: Gewöhnt euch noch nicht zu viel dran, die beiden werden auf "-c"/"-C" (für "Channel") umbenannt :)


    P.S. jsffm Darf ich fragen, bei welcher Distri du benutzt?