Posts by -lb-

    Hat sich erstmal erledigt - ich habe heute morgen die Ochsentour durchlaufen und mit meinem alten "produktiven" VDR einen Kernel nach dem anderen kompiliert.

    Der CT2-4400 stellt mit v4.18 seinen Dienst ein.

    Das dvbsky-Modul wurde von v4.17 -> v4.18 ziemlich umgebaut.

    Wer vor dem gleichen Problem steht: dvbsky.c aus v4.17 übernommen funktioniert direkt ohne Einschränkungen mit v4.19-rc7.

    Hallo,


    benutzt jemand den o.A. USB DVB-T2/C Stick (Version 2, USB-ID 0b48:3014) mit einem aktuellen Kernel? (v4.18 / v4.19-rc)?

    (oder irgendein anderes USB-Gerät welches mit dem "dvbsky" Treiber läuft?)


    Der CT2-4400 dürfte ggf. einigermaßen verbreitet sein, weil er seit Ewigkeiten out-of-the Box funktioniert.


    Ich betreibe einen VDR seit >1 Jahr stabil mit diesem Stick, allerdings unter einem Kernel v4.9.x / seit ein paar Monaten zusätzlich mit einem "August DVB-T230".

    (Letzterer / USB-ID 0572:c68a benötigt unter v4.9.x einen Patch, aus verschiedenen Quellen zurückportiert / Modul: dvb-usb-cxusb).



    Mein Problem ist jetzt: ich habe mich endlich dazu durchgerungen und neue Hardware zusammengestellt, und bin damit jetzt allerdings auf einen aktuellen Kernel angewiesen

    (AMD Ryzen 5 mit integrierter GPU / der VDR soll direkt h265-Sender wiedergeben können, und nicht mehr nur als "Headless" Gerät dienen).


    Der Zustand in den ich beide Sticks bekomme (den CT2-4400 wiederum ohne den Kernel überhaupt anzufassen):

    VDR (v2.4.0) / femon: der Tuner funktioniert, ich habe ein Lock auf allen DVB-T2 Kanälen, mir werden sogar Werte für Signalstärke und CNR angezeigt.

    Allerdings gibt der Stick keinen Transportstream aus (leider prima mit "usbtop" sichtbar).


    Generell funktioniert der VDR (der letzte Stick in meinem Zoo, ein PCTV 292e; Modul: em28xx) liefert brav einen Transportstream.

    Ich bin leider definitiv kein Programmierer und habe jetzt schon stundenlang vergeblich in den Sourcen nach dem Unterschied geforstet

    der dazu führt dass v4.9.x funktioniert, und v4.19 nicht - bislang ohne Ergebnis.

    Sämtliche Firmwareversionen für Tuner + Frontend die irgendwo zu finden sind habe ich auch schon durch.


    Falls das schon irgendjemand hinbekommen hat wäre ich für einen Tip dankbar.



    Danke,

    Lars

    Danke fürs testen.


    Das mit dem Schneiden ist definitiv nicht in Ordnung.
    Da sich hier an sich einiges geändert hat was ich noch nicht kannte ("adaptive skipping", ich komme damit noch nicht klar), habe ich mir jetzt erstmal einen VDR v2.0.x mit den ganzen hevc-Patches installiert.


    Damit funktioniert das Schneiden von h264-Material zumindest exakt so wie ich es gewohnt bin, bei hevc-Aufnahmen verschieben die Tasten 4+6 die Schnittmarken um ca +-1s, auch noch ok - allerdings praktisch komplett ohne Still Pictures, mal sehen ob ich dahintersteige was dort genau fehlt :)

    Hallo,


    ich habe meinen VDR seit ewigen Zeiten mit dem xineliboutput-plugin laufen. Nachdem die DVB-T2 - Kanäle mit kodi / vdr-plugin-vnsiserver oder
    über streamdev schon wunderbar funktionieren habe ich mich etwas mit der Materie beschäftigt, durch Teile der h.265-spec und ein paar Sourcen gequält.
    Das Resultat ist jetzt dass das plugin hier rudimentär mit den DVB-T2 - Kanälen funktioniert. Wenn ich rudimentär sage, dann meine ich das auch :)
    Der verwendete NAL SPS - Parser ist schlicht vom vnsiserver-plugin geklont, und mehr als nötig um ein Bild zu bekommen ist nicht implementiert..


    Was funktioniert?
    - Das Erste HD / ZDF HD des DVB-T2 Pilotmux laufen live einwandfrei, andere hevc-Quellen habe ich nicht getestet.
    - Nebenwirkungen für anderes was bisher schon funktionierte sind mir keine aufgefallen
    - Aufnahmen wiedergeben+schneiden: dachte erst das ist kaputt, scheint aber zu funktionieren (kenne nur VDR bis 2.0.x, da hat sich offenbar was verändert, verhält sich ohne Patch gleich)
    Ton beim Abspielen verliere ich manchmal, Zeit läuft nicht immer akurat mit, hier gibts definitiv noch was zu tun
    - Meine vorhandene Aufnahme der Münchner IRT-Testschleife zeigt Artefakte und führt zu Fehlermeldungen wie u.a.
    (direkt mit ffplay, vlc ect. abspielen funktioniert hingegen einwandfrei).
    ------------------------------------------------------
    [hevc @ 0x7f4d6c01a1c0] No start code is found.
    [hevc @ 0x7f4d6c01a1c0] Could not find ref with POC 34
    [hevc @ 0x7f4d6c01a1c0] No start code is found.
    [hevc @ 0x7f4d6c01a1c0] Could not find ref with POC 39
    [hevc @ 0x7f4d6c01a1c0] No start code is found.
    [hevc @ 0x7f4d6c01a1c0] No start code is found.
    [hevc @ 0x7f4d6c01a1c0] No start code is found.
    [hevc @ 0x7f4d6c01a1c0] Could not find ref with POC 47
    ------------------------------------------------------
    Live kann ich den IRT-Testkanal derzeit nicht ausprobieren, bin etwas weit weg davon - aktuell empfange ich hier den Pilotmux vom Großen Feldberg.


    Mein Test-VDR: headless Debian8 / VDR 2.2.0 (sourcen aus "testing", mit den Patches von reufer und jsffm für VDR und streamdev versehen), 1*DVB-T2, 1*Sat
    Client: Debian8 mit einigen Paketen aus Christian Marillats deb-multimedia, auf einem Laptop mit Haswell-CPU.


    Der Patch ist für xineliboutput / die aktuellen sourcen aus dem git repo. Insgesamt: RFC passt definitiv, vielleicht hat jemand Lust das mal auszuprobieren.



    Gruss, Lars