Gab es mal eine VDR-Version, die (beim Schneiden?) .vdr (PES) in .ts umwandeln konnte?
Nein. Da der VDR auch PES abspielen kann bestand auch nie die Notwendigkeit. Ansonsten wie oben schon geschrieben wurde mit Project X oder ffmpeg umwandeln, das geht bei beiden mit den richtigen Einstellungen ohne Neukodierung.
von https://www.heise.de/newsticke…sselt-in-UHD-4111534.html
ZitatAm Sonntag strahlt ProSiebenSat.1 eine Folge Galileo Spezial in UHD-Auflösung aus. Die Sendung ist unverschlüsselt über Satellit empfangbar.
Am Sonntag, den 22.07.18, zeigt ProSiebenSat.1 eine Folge Galileo Spezial in UHD. Zusätzlich zur höheren Auflösung wird der Inhalt unter Einsatz des HDR-Verfahrens Hybrid Log-Gamma (HLG) ausgestrahlt, das bessere Farben verspricht. Laut Pressemitteilung der Sendergruppe ist "Galileo Spezial: Pauschal gegen Freestyle - der beste Urlaub auf den letzten Drücker" über Astra-Satellit auf dem Sender UHD1 by HD+ unverschlüsselt empfangbar.
Über die digitalen Kanäle von ProSiebenSat.1 kann man die UHD-Folge von Galileo ab Montag "für kurze Zeit" auch auf Abruf in hoher Auflösung ansehen. Parallel zur UHD-Ausstrahlung wird die Folge wie gewohnt in SD und HD auf den entsprechenden Sendern gezeigt. .....
xcb_connect .... ist das der Connect zum X-Server? Läuft der X-Server?
Wäre es vielleicht möglich, dass Du die Treiber bereits compiliert bereitstellst für Leap 15.0?
Dann müsste ich bei neuen Kernelversionen immer neue Pakete erzeugen und wäre ständig am hinterherlaufen. Und wenn ich mal keine Zeit habe könnte keiner den Kernel upgraden (oder schlimmer: man macht einen Upgrade und es gibt keinen Treiber - was dann?). Deshalb denke ich Hilfe zur Selbsthilfe als source RPM ist da besser. Um den suse build service zu nutzen habe ich momentan weder Zeit noch Muße....
Ich habe die Tage schon mal mit der Beta experimentiert und mein Treiber-RPM angepasst. Es kompiliert und die Treiber werden geladen, der Testrechner hat aber keine S2-6400.
Download des Source-RPM hier, dann das Source-RPM installieren und mit rpmbuild -bb <spec-file> die RPM Pakete für Treiber und Firmware erstellen und anschließend installieren
aus gegebenen Anlass (zypper will Updates einspielen):
als Repo habe ich unter 42.3 eingebunden:
und er will folgendes updaten:
ich habe bei mir folgende Buildrequires drin (compiliert unter 42.3 und 15.0 Beta):
wobei die libav* alle von Packman kommen. Damit compiliert es erfolgreich. Ob es auch läuft kann ich mangels geeigneter CPU noch nicht testen.
wenn ich bei Suse hihttps://software.opensuse.org/search?p=1&baseproject=openSUSE:Leap:42.3&q=vaapier suche, gibts da vaapi-intel-driver mit 1.7.3 und intel-vaapi-driver mit 2.0.0 - fiese Falle!
Bei Leap 15.0, dass in einigen Wochen erscheinen soll, müsste die 2.0.0 lt. dem zweiten Repo dann dabei sein.
Ok, danke.
Alternativ könnte ich mir auch ein cEvent::HasActiveTimer() vorstellen, das die tf-Flags des Timers zurückliefert
Mehr brauchen die Skin-Plugins ja nicht.
Viele Skin-Plugins (die nicht beim VDR mitgeliefert werden ) fragen ja in DisplayChannel::SetEvents() ab, ob es Timer gibt um das REC-Symbol entsprechend beim Title des Present Event dazustellen. Da ab VDR 2.3.x ja die Funktion mit vorherigem LOCK_CHANNELS_READ aufruft, kann man kein Read-Lock mehr für die Timer in SetEvents() setzen (weil dann ein Deadlock drohen könnte) und VDR meldet eine invalid lock sequence im syslog.
Wie von Klaus empfohlen habe ich die Timer-Abfrage in skinElchi testweise in DisplayChannel::Flush() ausgelagert, war aber verwundert, dass direkt beim Start wieder eine invliad lock sequence gemeldet wird:
Wenn ich den VDR Quellcode richtig verstehe wird das Flush an beiden Stellen mit vorherigem LOCK_CHANNELS_READ aufgerufen.
Im LCARS Skin wird im Flush nur der Present-Event benutzt, keine Timer, auch wenn das hier im Forum schon zu lesen war.
Ich dachte man könnte Event->HasTimer() als Alternative benutzen (mit kleinen Einschränkungen bei der Funktionalität), aber da habe ich die Tage festgestellt, dass sich in VDR 2.4 das Verhalten von HasTImer() geändert hat: in VDR 2.2 wurde nur bei aktivem Timer true zurückgegeben, in VDR 2.4 wird bei aktiven und inaktiven Timern true zurück geliefert, so dass damit keine REC-Anzeige realisierbar ist.
Sorry Klaus, dass mir das nicht früher aufgefallen ist, aber ich habe aus zeitlichen Gründen die VDR Entwicklung nicht aktiv verfolgt und wollte jetzt "nur" mein Skin-Plugin anpassen....
Übrigens hat sich die Funktion cEvent::HasTimer() geändert: Früher war sie nur bei aktivem Timer true, jetzt ist sie auch true wenn ein inaktiver Timer existiert. Damit stimmt die Rec-Anzeige des Following Event nicht mehr wenn der Timer inaktiv ist (siehe Listing oben in Post #2 Zeile 24), Aber das ist vermutlich bei so ziemlich allen Skin-Plugins so, die nicht beim VDR mitgeliefert werden, da alle fast den gleichen Code benutzen
Ich dachte nämlich man könnte das für den Present-Event genauso machen wie für den Following-Event, aber statt einem Workaround gibt's jetzt zwei Probleme ...
Entweder Du machst ein Redesign so dass die Timer-Abfrage im Flush() passiert oder Du kommentierst die Zeilen 15-20 in dem oben zitierten Code aus. Dann hast Du zwar keine Recording-Anzeige mehr so wie ich den Code verstehe, aber auch die Fehlermeldung ist weg.
Was habt ihr immer alle mit Docker ??!?!? Bei Docker sind keine Dateien persistent, d.h. man muss beim Shutdown alle Dateien irgendwie nach extern sichern oder immer zusätzliche Filesysteme da rein mounten, damit z.B. die VDR Config erhalten bleibt.
Nehmt doch lieber gleich LXC (Linux Container)! Da hat man ein eigenes Filesystem für jeden Container und alle Vorteile von Docker, da beide auf die cgroups des (Host-)Kernels aufbauen. Wir betreiben etliche LXC in der Firma und nur gute Erfahrungen damit gemacht.
Das schaut aus wie bei Empfangsproblemen,d.h. info Datei wird angelegt, aber es kommt kein (verwertbarer) DVB-Stream.
Kann es sein, dass der streamdev Server in den Default-Einstellungen nur ein Stream liefern kann und der wird schon für die Anzeige benutzt?
Evtl. kommst Du da mit netstat und tcpdump weiter (Habe aber weder streamdev im Einsatz noch kenne ich mich damit aus)
Aber HEVC/h. 265 kann es trotzdem nicht, oder?
Mangels Beispielen habe ich nur mpeg4 (sd) und h.264 (hd) getestet, aber da er sich den passenden Decoder selbst sucht möchte ich nicht ausschließen dass es auch mit H.265 geht
Da Libs für ffmpeg2 immer weniger zur Verfügung stehen, habe ich den bislang letzten noad 0.8.6 für ffmpeg 3.4 angepasst.
Der Patch beinhaltet folgendes:
- unterstützt ffmpeg 3 (libavcodec57), getestet mit ffmpeg 3.4
- ignoriert Aufrufe mit dem Parameter started oder editing (gab bisher Fehlermeldungen im Log)
- Default SVDRP Port an aktuellen VDR angepasst
- Frame Nummerierung an aktuellen VDR angepasst (off-by-one)
- einige Compiler-Warnungen beseitigt
FireFly
Jetzt noch eine Frage: Ich hatte bisher die komplette vdr-Installation immer nach der Anleitung von Hubertus Sandmann gemacht. Soll ich eurer Meinung nach dabei bleiben. oder kann ich es auch (wie ich es auf meinem Laptop mit DVB-t2 USB-Stick gemacht habe) mit eingebundenen Repositorie von openSUSE_Leap machen???
dieses Repo hatte ich für mein Laptop genommen:
Wieso teilt diese bescheuerte Forensoftware das Zitat so auf ????? 
Wenn Du mit dem Repo zufrieden bist (d.h. alle gewünschten Plugins vorhanden sind) kannst Du auch das Repo nehmen. Für ein produktives System würde ich aber kein unstable-Repo nehmen solange man nicht spezielle neue Features braucht.
Baue mal im spec-File hinter die Zeile
BuildRequires: unzip
mal das ein:
BuildRequires: kernel-source
Du kannst auch gleich ein "zypper install kernel-source" ausführen
Zu dem Font-face Error kann ich nichts konkretes sagen. Ist der zusätzliche Stromstecker an die Karte angeschlossen? Wird die FW geladen? z.B. mit dmesg|grep -i saa oder so ähnlich kontrollieren, da müssen die Versionen der drei Firmwarefiles ausgegeben werden
