Wäre es evtl. sinnvoller, zuerst nach FullHD 60Hz zu schauen und dann erst nach HDready 50Hz?
Ich würde eine 50Hz Mode vorziehen weil bei 60Hz 10 Bilder pro Sekunde doppelt angezeigt werden müssen. Das gibt kleine Ruckler im Bild. Andere Meinungen sind willkommen.
Beim Wechsel auf 60Hz sollte man hdr wieder auf 0 setzen, sonst bekommt man bei 60Hz nie FullHD:
Ja, hab ich nicht bedacht.
Machst Du einen PR?
HEVC klappt super, mpeg2 mit Deinterlacer auch 
Vielen Dank zillerbaer, das ist echt ein Meilenstein!!
h264 funktioniert ca. 10 Sekunden, dann kommt leider reproduzierbar folgende Fehler. Danach hilft nur ein Reboot.
Tipps?
1) Der linke und rechte Rand ist ein Pixel breit grün.
Das liegt am Pixelformat das Raspi nutzt. Auf Rockchip und Allwinner ist das nicht der Fall. Ich würde erst mal abwarten ob das noch angepasst wird. Am TV kann das weg geschnitten werden.
2) 4:3 wird auf 16:9 skaliert. Lässt sich das abschalten?
Der Aufwand wäre recht groß und es betrifft nur alte Mpeg Formate. Vielleicht später mal wenn Zeit ist.
3) Audio Passthrough geht laut README nicht. Ich habe es noch nicht getestet (Raspi4 steht noch beim PC, nicht im Wohnzimmer beim Yamaha AV-Receiver). Kann/soll ich was testen, wenn ich den Raspi4 am AV-Receiver anstecke?
Die HDMI Treiber können momentan noch kein Passtrough nur PCM. Das ist bei AW und Rockchip auch noch nicht weiter.
h264 funktioniert ca. 10 Sekunden, dann kommt leider reproduzierbar folgende Fehler. Danach hilft nur ein Reboot.
Tipps?
Das kann ich hier nicht nachvollziehen. Vielleicht fehlt da noch was in der config.txt. Vergleich mal mit den Einstellungen.
Firmware auf aktuellem Stand?
Yup, ich habe gerade auf den aktuellen git-stand aktualisiert (geht in Arch mit: pikaur -S rpi-eeprom-git). Problem bleibt.
jemand eine Idee?
Taste Dich doch mal langsam ran mit -a hw:0,0 dann hw:1,0 ...
-a hw:0,0
root@rpi4b:/etc/vdr/conf.avail# tail -f /var/log/syslog
Jan 2 13:34:49 rpi4b vdr: [2826] SVDRP server handler thread started (pid=2815, tid=2826, prio=low)
Jan 2 13:34:49 rpi4b systemd[1]: Started Video Disk Recorder.
Jan 2 13:34:49 rpi4b vdr: [2826] SVDRP rpi4b opening port 6419/tcp
Jan 2 13:34:49 rpi4b vdr: [2826] SVDRP rpi4b listening on port 6419/tcp
Jan 2 13:34:49 rpi4b vdr: [2827] device 2 TS buffer thread started (pid=2815, tid=2827, prio=high)
Jan 2 13:34:49 rpi4b vdr: [2815] [softhddev]SetPlayMode: 1
Jan 2 13:34:49 rpi4b vdr: [2815] OSD size changed to 1920x1080 @ 1,77778
Jan 2 13:34:50 rpi4b vdr: audio/alsa: set params error: Das Argument ist ungültig
Jan 2 13:34:50 rpi4b vdr[2815]: AlsaSetup: set params error: Das Argument ist ungültig
Jan 2 13:34:50 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:53 rpi4b vdr: message repeated 17477 times: [ audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler]
Jan 2 13:34:53 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:53 rpi4b vdr[2815]: message repeated 74 times: [ AudioGetClock: no hw delay]
Jan 2 13:34:53 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:53 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:53 rpi4b vdr[2815]: message repeated 74 times: [ AudioGetClock: no hw delay]
Jan 2 13:34:53 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:53 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:53 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:54 rpi4b vdr: message repeated 3454 times: [ audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler]
Jan 2 13:34:54 rpi4b vdr: [2825] [softhddev]Clear:
Jan 2 13:34:54 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:54 rpi4b vdr: message repeated 443 times: [ audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler]
Jan 2 13:34:54 rpi4b vdr: [2825] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Jan 2 13:34:54 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:57 rpi4b vdr: message repeated 27497 times: [ audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler]
Jan 2 13:34:57 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:57 rpi4b vdr[2815]: message repeated 74 times: [ AudioGetClock: no hw delay]
Jan 2 13:34:57 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:57 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:57 rpi4b vdr[2815]: message repeated 74 times: [ AudioGetClock: no hw delay]
Jan 2 13:34:57 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehler
Jan 2 13:34:57 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:57 rpi4b vdr[2815]: AudioGetClock: no hw delay
Jan 2 13:34:57 rpi4b vdr: audio/alsa: snd_pcm_avail_update(): Eingabe-/Ausgabefehlerbei 99% CPU auf dem rsyslog
-a hw:1,0 cored sofort
Jan 2 13:33:34 rpi4b vdr: audio/alsa: playback open 'hw:1,0' error: Kein passendes Gerät gefunden
Jan 2 13:33:34 rpi4b kernel: [ 4598.034846] vc4_hdmi fef05700.hdmi: ASoC: can't open interface fef05700.hdmi: -19das einzige womit der vdr vernünftig läuft ist "-a hw:CARD=Headphones", hab aber nicht probiert ob damit Ton kommt. - aber CPU und Verhalten ist soweit ok
hier mal was: https://www.raspberrypi.org/fo…pic.php?t=269769#p1636828
Das kann ich hier nicht nachvollziehen. Vielleicht fehlt da noch was in der config.txt. Vergleich mal mit den Einstellungen.
Bei mir funktioniert es jetzt wieder nachdem ich diese Änderungen wieder zurückgeschraubt habe.
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-kms-v3d-pi4,cma-384
dtoverlay=rpivid-v4l2
max_framebuffers=2
disable_overscan=1
disable_fw_kms_setup=1damit hab ich jetzt auch hdmi Ton unter "-a hw:CARD=b1"
ÖR und ORF in HD laufen super bei CPU 10-15%, HD+ ruckelt sehr bei identischer CPU Last, dachte H264 wird in SW gemacht und ist da bei entsprechender CPU Last ganz OK?
Ja is klar, aber ich dachte der macht das so lange in Software wie es in Hardware nicht geht?
Decoding wurde erst in SW gemacht. Deinterlacing nicht. Das schafft die CPU nur bei SD Material. Zumal nur SW decodiertes Material in SW Deinterlaced werden kann wegen des nicht passenden Pixelformats. Für HD+ muss auf ein HW Deinterlacer gewartet werden.
hier mal was: https://www.raspberrypi.org/fo…pic.php?t=269769#p1636828
Mit den Hinweisen hab den Treiber zum Laufen bekommen, ob er besser ist, weiss ich noch nicht.
Zu 1080i, wenn ich das Aufrufe geht h264 sehr nachhaltig nicht mehr, es genügt nicht zu rebooten, der Pi muss aus- und wieder eingeschaltet werden.
Klingt super, wenn du das rausgefunden hast magst du dann einmal das komplette set posten, also config.txt, vc4-hdmi.conf und das plugin Startargument?
Da die in Libreelec ja auch "dtoverlay=vc4-kms-v3d-pi4,cma-384" nutzen, vllt haben die ja auch eine passende vc4-hdmi.conf?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!