Posts by jsffm

Ich habe Zeit

Würde mich auch interessieren.

Hast Du mal vaapi versucht? Weil Du von x265 sprichst.

Natürlich, ich sag Bescheid, wenn´s bereit liegt.

Die kommen so nicht direkt vom Sender, manchmal findet man sowas in Mediatheken oder man erzeugt sowas selbst mit ffmpeg oder komfortabler mit meinem Script vdr-transcode.

Wenn Du schon dran bist, mir ist aufgefallen, das mit libx265 erstellte TS-Files extrem viele Fehler erzeugen, obwohl der Stream völlig ok ist.

Hi,

Jetzt habe ich wohl ein etwas problematisches Board erwischt und damit zum Ersten Mal eine Problem mit dem ACPI Wakeup.

Es ist diese hier:

https://www.asrock.com/mb/Intel/B860M-H2/index.asp

Die üblichen Verdächtigen wie HPET und RTC Wakeup an/aus habe ich schon durchgespielt. Ich hoffe, hier hat jemad noch eine Idee.

vdr3-3 ~ # ./acpi_test
rtc_time        : 15:02:46
rtc_date        : 2025-11-18
alrm_time       : 15:49:45
alrm_date       : 2025-11-18
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
nextboot 1763478346 2025-11-18 16:05:46
./acpi_test: Zeile 17: echo: Schreibfehler: Das Gerät oder die Ressource ist belegt
Aktuelle Zeit:         2025-11-18 16:02:46
Starte Rechner neu um: 1763478346
Fahre Rechner nun runter.
rtc_time        : 15:02:46
rtc_date        : 2025-11-18
alrm_time       : 15:05:46
alrm_date       : 2025-11-18
alarm_IRQ       : yes
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay

Der Schreibfehler tritt beim ersten Versuch auf, der zweite ist dann erfolgreich.

Quote from gggggg

jsffm du meinst ev. sie sollen es remote auf einem PC schauen ? Das wollen wir vermeiden.

Nein, alleine das Vorhandensein des plugins erzeugt ein DVB-Device.

Das Problem hatte ich auch schon, spätestens, wenn das wieder passiert, werde ich das Testen.

streamdev-client sollte helfen

Ich bin ein Fan von Geräten mit Arm-Prozessor, mir ist aber keines bekannt, dass von ffmpeg gut unterstützt wird, leider. Transcoding geht am Besten mit Nvidia oder Intel.

Das sind leider schlechte Voraussetzungen.

Das war wohl eher ein Vertipper von mir, sorry. Was hast Du denn für eine CPU? Hevcencoding ist schon aufwendig. Zeigst Du mal das Protokoll von dem abgebrochenen Versuch?

Du kannst mal alternativ -h264 h264 Testen.

Ein anderer Versuch wäre kvazaar zu Installieren, das ist etwas flotter als x265.

-h264 hevc oder besser -h264HD hevc in /etc/vdr-transcode.conf

ich fürchte, die GT 520 ist zu alt, das schneller zu erledigen.

in Beiden

Den Parameter -g würde ich weglassen oder größer machen, z.B. 250

wenn Du z.B. mal verraten würdest, was Du für eine Grafikkarte hast, könnte man evtl. die zum Transkodieren nehmen, was viel sinnvoller wäre.

Es wäre hilfreich, wenn Du mal genauer Deine Konfiguration und was Du willst beschreibst.

Quote from nobanzai

Ich möchte ein Ergebnis, das am besten für 1920x1200 optimiert ist und auch über langsamere Verbindungen ruckelfrei abgespielt wird.

Diese Angaben sind sehr allgemein, die Auflösung schon größer als die Sender senden (max. 1920x1080). Du kannst z.B. auf 1080x720 reduzieren. wenn der der Sender größer sendet. Du kannst mpeg2 nach h264 konvertieren, Du kannst grundsätzlich die Bitrate reduzieren, was die Qualität reduziert, aber in Maßen angewendet, nicht sichtbar. Es ist sinnvoll, dafür die Grafikkarte heranzuziehen, damit ist auch Konvertierung nach hevc möglich. Du kannst zur Hilfe meinen Script heranziehen, mit dem Parameter --sim werden nur die ffmpeg Parameter angezeigt.

genau so ist es:

https://www.ffmpeg.org/ffmpeg-all.html