Posts by MartenR

    Hallo,

    ich hatte mit dem patch hier noch das Problem, dass der vdr ab und zu segfaulted.

    Das ganze liegt an der Variable following in displaychannel.h, die durch den Patch eingeführt word, diese wird allerdings nie initialisiert, das führt bei mir zu einem sporadischen segfault beim starten.


    Wenn ich following = NULL; im constructor von cNopacityView einfüge ist das Problem behoben. Vielleicht hilft das noch jemand.


    Marten

    Hallo Tobi,

    vielen Dank für das Bereitstellen der Pakete.

    Ich habe im Moment Probleme mit softhddevice, das OSD hat Probleme beim Zeichnen z.B. mit skinnopacity (habe ich per Hand gebaut).

    Es funktioniert aber wenn das Paket aus http://ppa.launchpad.net/yavdr…n-softhddevice-openglosd/ nehme und mit dpkg-buildpackage für Debian baue. Ich denke es könnte ein Problem mit verändertem pixmap handling sein in vdr 2.4.0, daher glaube ich das pixmap_outsie_fix_v1.patch in dem yavdr Paket den Unterschied macht. (Das Problem sieht man natürlich nur bei den komplizierteren Skin, skindesigner sah bei mir auch merkwürdig aus).


    Wäre toll, wenn du das ändern könntest, bei mir funktioniert es zwar aber vielleicht profitieren ja auch Andere.


    Marten

    Quote

    Naja... Wenn in meinem Desktop Browser oder im FireTV oder auf einem anderen Gerät mit einer Webview ein HTML Player läuft muss ich den doch irgendwie Steuern können. Da ich nicht mit dem Telefon dem Plugin sagen will was es zum Fernseher streamen soll sondern dem Player direkt Befehle erteilen will bieten sich Websockets zur Kommunikation doch an.


    Quote

    Wenn der Player im Browser oder einer Webview läuft und ich ihn fernbedienen will und das ohne websockets muss er pollen. Das ist irgendwie so 2010.


    Über die Implememtation die jetzt bereits läuft kann ich an einen Client mit beliebiger ID eine beliebige Nachricht senden. Die Nachricht kommt ohne Verzögerung beim Client an.


    Das heißt du willst etwas im Fernsehbrowser mit einer App fernsteuern,ok, dafür ipasst websockets. Mir würde die Fernbedienung des FireTV, AndroidTV ausreichen.
    Warum nimmst du denn nicht die API von google cast (früher Chrome Cast), wenn du es fernsteuern möchtest?


    Marten

    Quote

    Ich bau gerade Websockets in Restfulapi ein, damit man darüber einen HTML Player fernsteuern kann.


    Wobei ich vermutlich keine Websockets verwenden werde und es wird ein separates Plugin das nur das streamen macht, so dass praktisch alle denkbaren Clients das verwenden können, ich möchte auch am Ende HLS unterstützen und das ist dann ein simples HTTP get für eine entsprechende URL. (Das Steuern würde ich dann kryptografisch absichern.)
    Aber erkläre mal genauer wozu inwiefern das über Websockets gesteuert werden soll....


    Marten

    So ich habe jetzt auch alle notwendigen Bibliotheken installiert, jetzt kann das Schreiben des Plugins beginnen...!
    Nur als Tipp mit -hwaccell vdpau gibt es noch einen Performanceschub....
    EDIT: Nur mag das der vdr mit vdpau softdevice gar nicht und man bekommt sowas:

    Quote

    vdr BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:15 61]


    EDIT2: Passiert nur wenn man die DISPLAY Variable in einer ssh Shell umbiegt....


    Marten

    Quote

    Einen extra Dienst fände ich nicht so gut. Ich habe da bedenken wegen der Umschaltzeiten und was macht der Dienst während des umschaltens wenn keine Daten mehr geliefert werden. Naja... da kenn ich mich nicht aus. Wenn es funktioniert... aber irgendwie hört sich für mich Plugin "richtiger" an. Auch weil man direkten Zugriff hat und IMO alles einfacher Steuern könnte.


    Da stimme ich voll zu. Nur so gibt es Zugriff auf die Informationen des VDRs ohne große Verzögerung.
    Der VDR hat einige Informationen über die laufende Aufnahmen, die Keyframes und nur hier bekomme ich die Möglichkeit direkt das LiveTV abzugreifen, das erst durch ein anderes PlugIn laufen zu lassen kostet nur Performance. Sicher muss man besser aufpassen das es nicht abstürzt, aber das ist auch schon alles...
    Und natürlich werde ich massiv verschiedene Threads einsetzen, um den VDR nicht zu stören.


    Quote


    Wenn Live TV noch einfacher ist, warum dann nicht für Aufnahmen ein Recording Device nutzen? Müsste das nicht ähnlich handlebar sein? Bei Streamdev kann man ja bereits einen Timestamp mitgeben. So habe ich in meinem Player das Spulen umgesetzt.


    Stop, so meinte ich das nicht. LiveTV ist einfacher vom Segmentieren, vom Zugriff auf VDR Resourcen sind Aufnahmen natürlich einfacher. Aber egal, das kenne ich alles vom vompserver plugin, da habe ich schon einige Sachen verändert...


    Marten

    Quote

    Wie man die Parameter übergibt kann man ja relativ einfach anpassen. Ich habe jedenfalls gerade festgestellt, das Apache als Proxy zicken macht wenn man kodierte slashes im URL übergeben will (404). Vielleicht sind GET Parameter doch besser geeignet.


    Naja, ich stelle wir eher so etwas vor, dass man mit einem GET auf http://vdr/open/recordings?PARAMETER einen JSON mit einem Art Handle bekommt und dann mit http://vdr/recordings/HANDLE/init.mp4 das initialization segment für MediaSourceExtensions bekommt und mit http://vdr/recordings/HANDLE/SEGMENTNUMBER.mp4?PARAMETER, wobei das die aktuelle Bitrate (transcodiert wird nur wenn Kodierung anders oder Bitrate überschritten) und Auflösung ist. So kann man bei schlechter WLAN oder anderer Verbindung die Bitrate adaptiv anpassen.
    Die GET für die Segmente sollten dann gleich noch Informationen über die tatsächliche Formate im Header haben. Der Header sollte auch sagen wie lang das Transcoding gedauert hat. Analog dazu Live-TV. Zusätzlich sollte eine Art Loadbalancing zwischen nvenv quicksync durchgeführt werden.


    Das mit dem Handle erlaubt dann Decoder und Encoder schnell wieder zu verwenden, das kann Wert volle Zeit und CPU Last sparen, außerdem vereinfacht das die Verteilung der Sample auf die Segmente. Wenn man immer weis welcher Client in welcher Reihenfolge auf die Segmente zugreift, kann man ein bisschen Schlampen bei der Zuordnung der Audiopakete zu den Paketen. Ein größeres Problem ist nämlich das die Segmente immer an Keyframe-Grenzen beginnen und dann die Audiopakete entsprechend aufgeteilt werden müssen. Wenn die Aufzeichung noch läuft, kennt man diese Information nicht unbedingt bei der Erstellung der Segmentgrenzen.


    Quote

    Meinst du Live TV lässt sich auch so umsetzen? Das zu segmentieren stell ich mir irgendwie schwierig vor


    Ja klar, das ist sogar einfacher, da die Daten in einer definierten Reihenfolge kommen. Wahlfreier Zugriff ist viel schwieriger....


    Quote

    Das segmentieren macht komplett ffmpeg bzw libav. Die Segmente werden dann über einen Webserver ausgeliefert (Apache, ngix, libpoco)
    Segmentiert wäre dann wohl Hls (m3u8) oder MPEG dash. Moderne Browser oder auch Geräte (Chromecast, Smarttv) spielen auch MKV als stream ab.
    Mit libpoco sind das nicht mehr als ein paar Zeilen Code, Beispiel siehe plex Plugin.


    Vorsicht, ich habe die Muxer gestern abend genau im git angeschaut (wobei ffmpeg da viel weiter als libav ist), ganz so einfach ist das nicht.
    Denn ffmpeg ist darauf ausgelegt, die ganze Datei einmal durch zu kodieren. (Nur bei live TV sollte das direkt funktionieren)
    Wenn man bei Aufnahmen wahlfreien Zugriff haben will, ohne dass die ganze Aufnahme einmal durch die Maschine läuft, muss das noch irgendwie durch das plugin gesteuert werden (am besten über die VDR index Datei).
    Das sollte also alles on the fly passieren und nicht statisch durch den Webserver ausgeliefert werden.
    Ich würde auch als erstes mp4 als Container verwenden, der Rest kann dann später dazu kommen.


    Marten

    Quote

    Also wenn das mit den Segmentierten Dateien irgendwie hinzubekommen ist... den JavaScript Part übernehme ich gerne. Mein Player kann ja schon die Hälfte. Aktuell arbeite ich mit den Streams von Streamdev aber das kann man auch umbauen.
    Für den HTTP Teil könnte man cxxtools nehmen.


    Ich habe mir gerade libavformat genauer angeschaut, scheint sich insbesondere 2015 viel getan zu haben (was vermutlich bedeutet das jessie nicht die richtigen libs hat).
    Scheint vieles da zu sein, alle wichtigen Container usw. auch als segmentierte Version.


    Die Frage ist, wie soll die API aussehen, die aktuellen Bitraten, Codecs und Container sowie Audiospur alle in die URL encoden für die Files?
    Dann noch eine JSON API die Informationen über die Aufnahme wie Länge und Audiospuren mitteilt (muss ja nicht alles transkodiert werden).
    Und das Ganze immer im Zusammenspiel mit dem Restfulapi plugin bauen.


    Frage ist cxxtools noch sinnvoll, die Webseite kann ich nicht aufrufen..., libpoco kann ich mir wenigstens anschauen...


    Ich schau mir das mal nächstes Wochenende noch genauer an... und dann entscheide ich ob ich einen Prototyp baue...., sieht aber einfacher aus als ich dachte..


    Marten

    Quote

    Das halte ich für ein Gerücht.
    ffmpeg kann doch Fertige HLS TS Streams ausgeben? Das macht der Plexmediaserver sowie Emby doch mit ffmpeg am laufendem Band...


    Ich meine aber etwas anderes, nicht das ein fixer HLS TS Stream ausgegeben wird, sondern das durch Kontrolle des Clienten die Bitrate dynamisch geändert werden kann, die das Plugin zum encoden nutzt.
    Ob da der muxer noch eingesetzt werden kann glaube ich weniger, da er ja eine feste HLS Datei ausgibt, außerdem ist HLS auch schon Schnee von gestern, die neue Standards nutzen alle MediaSourceExtensions und das ist ein anderer Container, leider kein TS mehr (auch wenn es Teil der Spezifikation ist). Grundsätzlich meine auch nur das der muxer wahrscheinlich im Plugin implementiert werden muss (ich vermute plex und emby machen das ähnlich aber die scheinen nicht open source zu sein(jedenfalls habe ich keinen source gefunden) , da kann ich nicht reinschauen, was die machen).


    Marten

    Quote

    Ich hab da keinen Unterschied festgestellt.


    Und softhddevice hat über vdpau h264 dargestellt. Lief beim transcodieren die dekodierung von h264 auch über vdpau?


    Quote

    Ich hab da ja so eine Webapp Programmiert, mit der man über Streamdev auch TV oder Aufnahmen ansehen kann. Was mich dabei stört, ist das ich IOS nicht bedienen kann, da hier die angesprochene Segmentierung verlangt wird und die langsamen Umschaltzeiten. Das Codec Wirrwarr ist gar nicht so schlimm. Eigentlich benötigt man nur x264 und Webm. Damit bedient man schon mal alles außer IOS (IE mit Webm Plugin von Google, Edge hab ich (noch) nicht). Chrome nimmt übrigens auch MKV


    Ich wünsche mir so ein Plugin, damit VDR eine eigene Lösung für Mobiles Fernsehen anbieten kann. Das funktioniert mit meiner App sehr gut (ich nutze sie täglich z.B. zum Nachrichten schauen beim Zähneputzen), ist aber wie gesagt verbesserungswürdig. Jetzt mit NVENC kann man schon mal schwachbrüstigere Server dafür nutzen. TV Geräte interessieren mich hier weniger. Da kann man auch einen RPI oder ähnliches als Client anschließen oder meine App mit Chromecast nutzen (ist eher nur zum Aufnahmen schauen gut TV geht auch, man kann ja aber nicht umschalten).


    Vielleicht kann man ja auch Streamdev beibringen bei Nutzung von Externremux auf Befehl umzuschalten. Aktuell muss ich immer den Stream anhalten und einen neuen starten, was auch schon Probleme macht und ca. 30 Sekunden dauert.


    Naja, wir haben hier jetzt überall smarttvs, und ich habe mir viele Apps von Streamingdiensten angeschaut.
    Die verwenden alle HTML5 als Basis für die UI und je nach Device wird das video Tag über HTML5 MediaSourceExtensions (https://www.w3.org/TR/media-source/) gefüttert oder die Dekodierung wird nativ über z.B. Android durchgeführt.
    Ich schau mir schon seit einigen Wochen Ideen an um vomp durch etwas zu ersetzen, was für die meisten Plattformen über HTML5 läuft und daher die entsprechenden segmentierten Files braucht. (Also sowohl AndroidTV, SmartTV Android für mobiles TV, und Versorgung über Webbrowser am PC).
    Mein aktueller Stand ist das die meisten Browser nur Mp4 Container über MediaSourceExtensions verarbeiten können und meist nicht TS (das nur über die älteren HLS und HAS Standards und dann Mp3 mit h264 und AAC oder mp3 der kleinste gemeinsame Nenner ist.
    Aber mir ist noch nicht klar wie der Weg genau aussehen wird. Das Schreiben eines Plugins das so etwas macht ist weniger das Problem, ich habe genug an muxer, demuxern und ffmpeg für die raspberry pi und windows ports für vomp gearbeitet (inklusive experimentellen Streamings mit Transcoding für bluray, das aber von der SchreibPerformance der temporär Dateien auf bluray Seite schrecklich war.
    Vielmehr eine Architektur zu finden die möglichst viele Geräte ansprechen kann, also welche Container und Codecs bedient werden müssen. Außerdem habe ich nicht so richtig Lust auf die javascript Seite und ich brauche noch eine lib die sich um die http routen kümmert.
    Also ich schwanke noch ob ich damit anfangen soll....


    Marten

    Quote

    Das einzige was noch besser wäre wär ein richtiges Ausgabeplugin das on the Fly transkodiert und mit dem man auch via HTTP Request umschalten kann ohne das er den Transkodier Prozess neu starten muss.


    Vielleicht liest ja hier einer von den Ausgabe Plugin Profis mit und baut das mal eben kurz ;) Ich beteilige mich dann auch mit einer hübschen Mediengalerie für den Browser.


    Naja, interessant ist das schon (wobei das schon viel Zeit brauchen wird), aber ich würde das eher nicht als Ausgabeplugin machen, sondern eher so eine Art Plugin, dass die Aufnahmen und die aktuellen Sender, als segmentierte TS oder MP4 transcodiert. (Also so eine Art vompserver plugin, nur http basiert und mit Transcoding und Segmentierung mit Clients entweder nativ oder Javascript).
    Das Problem sind hier eher die vielen Standards Samsung TV wollen noch die alten HAS oder HLS Standards, moderne Browser und Android TV (z.B. Sony) kann man über die MediaSourceExtensions von HTML5 bedienen oder nativ über MediaCodecs, aber das sind dann entweder MP4 oder TS Container. (Bei Segmentierung kann man leider ffmpeg nicht zum muxen nehmen, da es das nicht unterstützt). Zusätzlich gibt es noch ein großes Codec Wirrwar was die einzelnen Devices unterstützen.....


    Aber viel brennender Interessiert mich, habt ihr mal geschaut ob das parallel zu einem über VDPAU laufenden SoftHDDevice in vernüftiger Performance läuft???


    Marten

    Ich habe auch einen kleinen Vorschlag für die Peering Funktion. Sollten irgendwann irgendwelche TS Daten ausgetauscht werden. Fände ich eine Plugin-Schnittstelle hilfreich, die sich bei den eingehenden oder ausgehenden Daten befindet. So könnte z.B. ein Transcoder (z.B. falls der client kein mpeg2 oder das audio format kann, oder bei geringer Bandbreite WLAN) oder NaluStripper zwischen geschaltet werden.


    Marten

    Hallo,
    Das sieht ja interessant aus.
    Bevor ich mich jetzt an eine Anpassung von vompserver mache, frage ich mich wo die Reise hingeht.
    Ist es auch geplant, dass vdr im peer to peer modus Aufnahmen und Live-TV stream?
    Wenn ja, würde vomp ja sowieso obsolete werden, dann würde ich es nicht anpassen.


    Marten

    Es gab mal einen patch Kollektion für vomp, bei der einfach beim starten von vomp, Tastendrücke der Fernbedienung simuliert wurden. (Weis aber nicht mehr von wem und wo es die gab).
    Aber das war nicht wirklich schön.


    Marten

    Quote


    im Quelltext muss jedoch in der Datei select-platform die Abfrage um BCM2709 erweitert werden.


    Habe es in das git vom scraper support branch gepackt.


    Das Feature request mit dem beim Einschalten wieder den letzte Kanal sehen? Die Frage kam schon sehr häufig, die Antwort ist eigentlich immer die gleiche um das ordentlich zu machen, sind die Änderungen in vomp zu umfangreich.


    Marten

    Quote

    Da mache ich mir wenig Hoffnung, ich glaube nicht, dass ich vom Video-Decoder eine zweite Instanz starten kann…


    Bist du dir da sicher? Wenn der Chip für Bluray Anwendungen ausgelegt ist (was ich nicht definitiv weis), sollte er eine zweite Decodiereinheit unterstützen..... (Einige Blurays haben Pip)


    Marten