Ich werde künftig Änderungen auch auf GitHub veröffentlichen: https://github.com/reufer/rpihddevice
Gruss
Thomas
Ich werde künftig Änderungen auch auf GitHub veröffentlichen: https://github.com/reufer/rpihddevice
Gruss
Thomas
Danke für den Hinweis - der Fehler ist mir nicht aufgefallen, da ich den "wie Video"-Mode aus den bereits erwähnten Gründen selber nicht nutze.
Ich habe mir den Code und den Lösungsvorschlag angeschaut. Besser wäre es, den Null-Check innerhalb oder vor dem Aufruf von GetModeFormat() zu machen, denn die Methode
ist dazu da, auch das Pixelseitenverhältnis korrekt zu setzen. Ansonsten wird die Umschaltung zwischen 16:9 und 4:3 bei SD-Material nicht funktionieren.
Gruss
Thomas
Wenn ffmpeg eingangsseitig wirklich neutral wäre, dann bräuchte es genau ein Ausgabe-Plugin. Eines das den Datenstrom eingangsseitig in ffmpeg reinkippt.
Das Decodieren an sich ist ja nur die halbe Wahrheit - problematisch, weil plattformabhängig, ist auch die synchronisierte Ausgabe der decodierten (ob nun mit oder ohne Hardwareunterstützung) Audio- und Videoframes. V4L scheint da ein vielversprechender Weg zu sein, aber wann das für die neue Himbeere kommt ist fraglich.
Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.
OpenMAX wäre sehr wohl ein plattformübergreifender Standard, im Gegensatz zu ffmpeg. V4L wiederum auch, aber das scheint noch kein Thema zu sein.
Hallo Uwe
Ich befürchte, die Änderungen werden umfangreich sein... scheint ein Projekt für den Winter zu werden.
Gruss
Thomas
Wirst Du auch den neuen Raspberry Pi 4B mit hevc unterstützen?
So der Plan... ich kann aber den Aufwand noch nicht abschätzen. Mal schauen, was sich an der Softwarefront so tut und welche Schnittstellen der neue Videocore unterstützt.
Gruss
Thomas
ist nun gefixt - vielen Dank an Klaus für die Mithilfe!
2019-06-16: Version 1.0.5
-------------------------
- fixed:
- fixed drawing of empty strings on high level OSD (thanks to Klaus Schmidinger)
- fixed compilation for Raspbian Stretch (thanks to Klaus Schmidinger)
- fixed compilation for ffmpeg-4 (thanks to Stefan Schallenberg)
BTW: Hat sich bei projects.vdr-developer.org irgendwas geändert? Ich kann nicht mehr pushen, und mein SSH key hat nicht geändert...
Gruss
Thomas
I have the same issues with latest VDR/streamdev version as client, however I've already installed the patch you mentioned on the server. Due to limited time, I wasn't able yet to further investigate...
Thomas
Ehrlich gemeinte Frage aber nutzt Gentoo denn überhaupt noch jemand?
*meld*
Und ich habe eigentlich auch nicht vor, das zu ändern... würde mich sehr freuen, wenn es weiter geht!
Gruss
Thomas
Ich weiss nicht, ob ich dich richtig verstehe. Ist es nicht so, dass es immer eine Grenze gibt? Ob die nun bei 2k oder mehr liegt, spielt ja keine Rolle. Ein Skin muss einfach damit umgehen können, wenn die verwendete OSD-Implementation die angeforderte Pixmap nicht liefern kann. Wenn es ums Scrollen von EPG-Informationen geht (das war damals bei der Einfürung der Grenze der konkrete Anlass), hat Klaus ja im osddemo-Plugin vorgemacht, wie sich das mit minimalem Überhang realisieren lässt.
Gruss
Thomas
Ich sehe hier nicht die Himbeere als Spezialfall, eher die SW-Implementation des VDR. Hat nicht auch OpenGL eine maximale Grösse für Pixmaps? Spätestens bei Embedded-Systemen (z.B. Odroid) dürften die Grenzen real werden.
So oder so sollten sich Skin-Entwickler darum kümmern. Ob die Grenze nun bei 2k oder mehr liegt, spielt dabei ja keine Rolle - je höher der Default-Wert, desto eher wird das Problem verdrängt und lässt die Nutzer von Früchtekuchen potentiell aussen vor.
Gruss
Thomas
Hallo Martin
Die 2048x2048px gelten ja "nur" für die default-Implementation des un-beschleunigten OSDs und sind, streng genommen, vom Arbeitsspeicher des VDR abhängig. Ob das jetzt mehr oder weniger sein soll lässt sich sicher diskutieren, aber unendlich fände ich auch komisch...
Gruss
Thomas
Da sich auf der Seite eh schon länger nichts mehr getan hat und die vorhandenen Einträge vielleicht schon veraltet sind, tendiere ich dazu, sie ganz zu löschen.
Mal abgesehen vom eigentlichen Thema finde ich die Seite - pardon - abschreckend. Weshalb nicht (per Aufruf hier im Portal?) ein paar neue Bilder/Beispiele sammeln und dann selektiv auf deiner Seite veröffentlichen? Ich möchte niemandem zu nahe treten, aber wäre ich auf der Suche nach einem digitalen Videorekorder, wäre für mich VDR beim Anblick dieser Seite gestorben...
Gruss
Thomas
Kann man davon ausgehen das das rpihddevice damit wieder problemlos funktioniert?
Selbstverständlich. Ich werde meinen Produktiv-VDR auch updaten, sobald die Boards angekommen sind.
Momentan liegt das Projekt bei mir auf Eis, mangels Eigenbedarf und überschüssiger Zeit...
Gruss
Thomas
Hallo Dirk
Mehr als mit "-scodec=dvbsub" den Subtitle-Codec zu spezifizieren kann es nicht gewesen sein, ansonsten könnte ich mich daran erinnern.
Viele Grüsse
Thomas
Das geht grundsätzlich, ich habe das jedenfalls mit ffmpeg hingekriegt - meine DVD-Rips von Little Britain haben jedenfalls die originalen Untertitel. Ich bin mir nicht mehr sicher, ob ich nach DVB- oder PGS- (BluRay) Untertitel konvertiert habe. Beides unterstützt VDR nativ und ohne Plugins.
Edit: Ich habe nach DVB-Untertitel konvertiert:
Input #0, mpegts, from '00001.ts':
Duration: 00:28:30.24, start: 1.440000, bitrate: 4885 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:2[0x102](ger): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:3[0x103](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:4[0x104](ger): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Display More
Interessant wäre natürlich der "böse" EPG-Text, der die Ausgabe verhindert.
Hmm... könnte es evtl. am Inhalt der EPG-Daten liegen? Die eigentlich Ausgabe scheint kein Problem zu sein, sonst gäbe es ja Einträge im Log. Aber vielleicht stolpert die Pfad-Generierung für den Text über irgendwelche Sonderzeichen...
Hmm... im Log kann ich nichts aussergewöhnliches feststellen. Falls eine Bitmap zu gross sein sollte, oder sonst eine Ressource nicht ausreicht, gäbe es da eine Fehlermeldung. Kann das Problem sonst noch jemand nachvollziehen?