Beiträge von MartenR

Größtes Problem sehe ich beim fehlenden h264 support, die CPU soll stark genug sein, aber wie das mit der Hitze aussieht.... Ich vermute Lizenzen sollten gespart werden....

Ihr solltet aber erst klären ob ihr einen DirectShow hevc codec bekommt, die Technik war schon vor 10 Jahren kurz vor der Abkündigung, und wenn es den nicht gibt das Ganze auf den Nachfolger umschreiben, welcher das auch immer jetzt ist, könnte ein kompletter Rewrite werden.

Das git ist von Chris Tallon, aber ich habe die meisten Portierungen gemacht, bzw. habe/hatte Zugang. (Lange nicht genutzt)
Und ja besonders ordentlich war ich nicht...

Zitat

leider kann er kein DVB-T (hevc) und verwirrend ist, dass ich ihn auf 4:3 einstellen muss, um 16:9 korrekt zu sehn.

Das mit dem hevc ist klar, der WindowsClient wurde seit 10 Jahren nicht mehr angepackt...., und das mit dem 4:3 hat damit zu tun,. dass er sich wie eine mediamvp mit Scart Anschluss verhält, also 16:9 ist anamorph, wie man das früher bei Röhrenfernseher und deren Zoomfunktion hatte....

Hallo,

das sind definitiv die fehlenden MPEG2 Lizenzen. Vomp hat keine Softwareunterstützung für Mpeg2 auf Raspberry, da alles auf der ersten Raspberry entwickelt wurde. Erst die neueren haben genug Power für Mpeg2 bzw. auch optimierte Bibliotheken.
Ich entwickele nicht mehr an Vomp, VDR noch selten im Einsatz mehr Streaming...
Und Chris hat auch nicht so viel mehr gemacht:

git.vomp.tv Git - vompclient.git/summary

aber es ist nur das Forum down:

Loggytronic

aber aus dem git bekommt man noch den Quellcode.

Marten

Zitat

hattest du das Problem, wie hier geschildert mit dem Plugin epgsearch?

Nein, das war gleich beim Start des vdrs, das erste Channelinfo hatte keine gesetzten Informationen.....

Marten

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

Zitat

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.

Zitat

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

Zitat

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:

Zitat

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

Zitat

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.

Zitat

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

Zitat

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.

Zitat

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....

Zitat

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

Zitat

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

Zitat

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

Zitat

Ich hab da keinen Unterschied festgestellt.

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

Zitat

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

Zitat

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

Hallo,
ich wollte kurz auf eine Umfrage darüber ob vomp in Zukunft noch die mvp unterstützen soll hinweisen:

http://forum.loggytronic.com/index.php?topic=769.new#new

Marten

P.S: Diskussion darüber am besten in Englisch auf loggytronic damit Chris mitlesen kann...

Zitat

Ich denke nicht das jemand für die "sturm alten" MVP-Boxen die Software noch umschreiben wird.

Software umschreiben reicht da nicht, das kann die Hardware einfach nicht.
Raspberry pi wären die Lösung auch wenn der cinch Ausgang nicht so gut wie bei den alten mvps ist.
Im scraper_support branch gibt es im Zusammenspiel mit epgd und co auch Filmplakate im vomp.

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