Posts by rell

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Quote from neumann2k

    Oh, was mir noch aufgefallen ist: Um überhaupt eine 4K-Auflösung verwenden zu können, muss ich in der config.txt folgendes setzen:

    hdmi_enable_4kp60=1

    Nach meinem Verständnis betrifft dieser Eintrag jedoch nur die Aktivierung von 60Hertz bei 4K, also 50Hertz sollte auch ohne diesen Eintrag gehen. Allerdings verwendet das Plugin ohne den oben genannten Eintrag nur 1080p.

    Hast Du dafür eine Erklärung?

    Ja und Nein. Der Ablauf wie ausgewählt wird steht oben. Wäre interessant, was als höchste 50Hz Auflösung angeboten wird. Wenn du "modetest" drauf hast, kannst du mit "modetest -c" nachsehen, was es alles gibt.

    Wenn da eine 4K@50Hz drin ist und die Auflösung nicht manuell gesetzt wird, stimmt evtl. was mit dem Code nicht, wobei ich auf die Schnelle auch keinen Fehler sehe.

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Ok, verstanden. Da bei mir jeder VDR seinen eigenen Fernseher hat, stellt sich die Frage hier nicht. Unterstützen kannst du indem du testest und Bugs meldest oder selbst Code schreibst.

    Und ja, ich habe eine Amazon-Wunschliste - aber die ist nicht dafür gedacht, dass mir jemand Wünsche davon erfüllt - falls du darauf hinauswolltest. Ich beschäftige mich mit VDR weil es mir Spaß macht. Ich werde auch nicht mehr Zeit investieren, wenn es dafür externe Anreize gibt... Ich denke, so ist es bei allen anderen hier auch. Im Grunde verfolge ich damit lediglich einen egoistischen Selbstzweck. Ich baue mir das so, wie ich es haben will - sofern es mir mit meinen Kenntnissen möglich ist. Und das mache ich dann, wenn ich Zeit und Lust dazu habe. Aber natürlich erfülle ich auch gerne Wünsche anderer, weil ich froh bin, wenn auch andere davon einen Nutzen haben. Die Prioritäten dafür setze ich aber selbst ;)

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Die Auswahl der Auflösung/Frequenz läuft folgendermaßen:

    Zuerst wird nach der Auflösung gesucht, die man dem Plugin als Option beim Start mitgibt: "-d display resolution (e.g. 1920x1080@50)"
    Dann wird geprüft, ob es Auflösungen mit 50Hz gibt. Falls ja, wird die mit der größten Breite gewählt. Falls nein, wird nochmal mit 60Hz getestet. Und wenn es nichts mit 50 oder 60Hz gibt, nimmt er die breiteste mit der erstmöglichen Frequenz - wobei man da über Sinnhaftigkeit sprechen kann.

    Ich verstehe den Anwendungsfall noch nicht ganz, warum man per Menu die Auflösung ändern wollte? Eine Änderung in einer Konfigurationsdatei sollte hier doch ausreichen - auf welchem Weg auch immer man da ran kommt. Bei einer Änderung per menu muss in jedem Fall der renderer neu initialisiert werden. Wie trivial das ist, weiß ich noch nicht, aber es würde sich anbieten, das im Zuge von detach/attach mit einzubauen...

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Ich teste das nächste Woche mal bei mir mit dem rpi4 und VDRSternELEC. Mir fällt grad nichts ein, warum ein geöffnetes OSD in softhddevice das Video beeinflussen kann. Es wird mit der gpu zeichnet und dann beim pageflip einfach auf einem anderen plane mitangezeigt.

    Ist das mpeg2 576i bei dir? Wie ist deine Auflösung und Wiederholrate? Der RPI4 decodiert mpeg2 in software und deinterlacer ist dann bwdif. Wenn da ein generelles Problem mit dem Softwarepfad wäre, sollte das auch ohne OSD sichtbar sein. Systemauslastung oder bandwidth dürfte auch kein Problem sein. Hm, muss ich nachdenken und selbst testen. Kommt man bei mld an die Logs? Oder kannst du das Plugin selbst übersetzen?

  • Passthrough mit softhddevice*

    Hallo zusammen,

    bin grad dabei, passthrough in softhddevice-drm-gles zu integrieren.

    Bei Codelesen sind mir ein paar unklare Sachen aufgefallen, daher meine Fragen an euch Entwickler jojo61  lnj  jrie  zillerbaer usw. und alle, die sich mit alsa auskennen:

    1) https://github.com/jojo61/vdr-plu…er/codec.c#L967 CodecAudioPassthroughHelper() z.B. baut einen spdif-Header vor das avpkt und damit wird es dann an AudioEnqueue() übergeben. Wenn ich den Code richtig lese, wird zwar mit avcodec_receive_frame() das avpkt in ein frame decodiert, die decodierten Daten im frame werden aber später in passthrough nicht mehr verwendet. Im resample Zweig (- Ich gehe davon aus, dass es den Resample Context gibt, da ansonsten gar nichts in AudioEnqueue landet?! -) wird dann frame->extended_data weiterverarbeitet. Brauchts für passthrough überhaupt das avcodec_send_packet/avcodec_receive_frame?

    2) Braucht es CodecAudioPassthroughHelper() für passthrough immer oder können die Rohdaten von avpkt auch einfach so weitergeleitet werden? In softhddevice-drm-* wird (ohne passthrough) das frame mit einem avfilter bei Bedarf umgewandelt, d.h. den software resampling context gibt es hier nicht. Könnte das frame mit avfilter in das richtige passthrough-Format gebracht werden, oder ist das mit dem frame schon zu spät und man muss schon das avpkt für passthrough weiterverarbeiten?

    3) Auf meinem rockchip gibt es 2 Audiodevices: Analog und HDMI. Wo stelle ich fest, was HDMI kann bzw. ob HDMI passthrough annehmen kann oder kann ich einfach davon ausgehen? Der rockchip hängt am TV, der über HDMI(ARC) das Signal an meinen AV-Receiver durchschleift. Mit der XBox funktioniert 5.1.
    https://github.com/rellla/vdr-plu…s/audio.c#L1064 Mit snd_pcm_hw_params_set_channels_near() werden 6 HwChannels angefragt, es liefert aber 2 zurück, d.h. es geht in den Downmix. Wahrscheinlich stehe ich auf dem Schlauch, aber sollten hier nicht 6 HwChannels zurückkommen? Oder sind es bei HDMI generell nur 2? https://github.com/jojo61/vdr-plu…er/codec.c#L927 setzt bei passthrough ja auch zwei. Wahrscheinlich habe ich hier einen Denkfehler.

    Ich vermute, dass ich es so machen muss:

    - dem avpkt mit CodecAudioPassthroughHelper() einen spdif Header verpassen
    - irgendwie die PTS in den Griff kriegen
    - die neuen Daten ohne ein resampling an AudioEnqueue übergeben

    Fragen reichen vorerst. Ich wäre euch dankbar, wenn ihr hier etwas Licht für mich reinbringen könnt. Der Audio-Teil ist noch recht neu für mich.

    Gruß
    Andreas

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Quote from neumann2k

    Mir ist noch folgendes aufgefallen: Bei geöffnetem OSD flackert das Bild in der oberen Häfte. Sobald ich das OSD schließe, verschwindet das Problem wieder. Das passiert bei jedem Skin. Ist Dir das Verhalten schon bekannt?

    Nein, noch nicht. Evtl. ist das was RPI spezifisches. Da habe ich keinen produktiv im Einsatz und teste nur ab und an. Werde ich bei Gelegenheit testen. Auf meinen rockchip wäre mir das nicht aufgefallen.

    Wie kann ich mir das Flackern vorstellen? Flackert das Video oder "flackert" die allererste Bildschirmzeile? Das habe ich auch manchmal bei tvguide, wenn ich mich richtig erinnere.

    PS: Vielleicht schiebe ich tatsächlich Passthrough nach vorne auf meiner Liste ;) Ich möchte nur irgendwann den Umstieg auf konsequente Benutzung von Klassen/Objekten fertigstellen - was sich noch ziehen wird - und bei jedem Fix oder Feature, das zwischenrein grätscht muss ich bei einem rebase aufpassen, dass hier nichts verloren geht... Das ist das Problem mit mehreren gleichzeitigen Baustellen...

  • [softhddevice-drm-gles] Raspberry 4 und 5

    Danke, passt alles. RPI4 und 5 habe ich. Auch Odroid N2+ und ein paar Rockchip. Unterstützen kannst du aktuell nur, wenn du mir Zeit schenkst ;) oder selbst Code beisteuerst... Oder dann testest. Probleme und Featurewünsche sind erkannt, ich weiß grundsätzlich auch die Lösungsansätze, nur umsetzen brauchts halt :)

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Zabrimus

    In der toolchain hat sich etwas geändert und dafür habe ich keine einfache oder überhaupt eine Lösung gefunden, außer einem kompletten Rebuild :(

    Die einfache gibts auch nicht ->

    LibreELEC WIKI: "As a general rule you can keep rebuilding (respinning) unless there are changes to the "toolchain" packages. If these are changed, you will need to clean or remove the build folders and make a "clean build" again."

  • TrickSpeed - Verständnisfrage

    Danke, teste ich.

    Quote

    // while 0 is a valid PTS, DeviceGetSTC() might return 0 if, after a jump, the device hasn't displayed a frame, yet

    Nur zur Vollständigkeit:

    Wäre es sinnvoll, https://git.tvdr.de/?p=vdr.git;a=b…95;hb=HEAD#l718 so zu ergänzen, dass das Device (PTS & 0xFFFFFFFF) == 0 zurückliefern soll, wenn es keinen letzten pts gibt? Wenn ich es richtig sehe, liefern ffmpeg basierte softhddevice in diesem Fall AV_NOPTS_VALUE (https://ffmpeg.org/doxygen/7.0/gr…a6f2d08afa01be1) mit GetSTC() zurück, was bei Verwendung der ersten 32bit eh schon passt.

  • Neue VDR Umgebung aufbauen

    Wohl war, aber die braucht man ja nicht, wenn man mit SD-Karte zufrieden ist. An meinen beiden clients läuft alles von SD...

    Trotzdem, Stromversorgung, SD-Karte und evtl. Gehäuse und IR-Empfänger kommt natürlich noch dazu.

  • TrickSpeed - Verständnisfrage

    kls Probier ich nochmal. Sollte sein:

    Erstmal Play(), dann kDown für Pause, dann kRight für Zeitlupe vorwärts.

    Da sollte ein Sprung sein.

    Play sendet Daten, die in softhddevice gepuffert werden. Pause löscht das jetzt alles mit dem Empty() und das Forward setzt da fort, wo VDR die letzten Daten geschickt hat und nicht da, wo das Ausgabeplugin die letzten dargestellt hat. Die gepufferten fehlen durch das Empty.

    Ich hoffe, ich habs richtig zusammengefasst.

  • ruft vdr GetVideoSize nur bei Live-TV auf??

    Wenn ich es richtig im Kopf habe, prüft softhddevice-drm(-gles) vor jedem DRM Commit die width/height/aspect_ratio des AVFrames und stellt das frame im richtigen Seitenverhältnis maximal groß dar - entweder fullscreen oder in einem rect, das durch ScaleVideo() vorgegeben wird.

    Ich weiß nicht, wie gut der decoder mit einem solchen Wechsel im Laufenden Betrieb zurecht kommt, aber bisher ist mir nie was negtives aufgefallen. Evtl. bin ich aber auch noch über keinen solchen Fall gestolpert...