Posts by Zabrimus

    Edit: Ich habe doch noch einen Fehler gefunden, der nervig ist. ich werde versuchen, den schnell zu fixen und eine neue Version zu erstellen. Das Problem ist, daß man im Video nicht mehr Vor- und zurückspringen kann. Aber WDR-Videos mit TCP scheinen bei mir viel besser zu laufen.



    Version 0.0.5 wurde getaggt. Das ppa baut gerade. Das Hauptaugenmerk liegt hierbei bei verschiedenen Möglichkeiten, den Videostream an das Plugin zu übertragen.


    Changelog vdr-plugin-hbbtv:


    Changelog vdr-osr-browser:


    Videostreams können nun statt nur per UDP nun auch per TCP oder Unix domain sockets an den VDR übertragen werden. Ich hoffe damit, ein paar Probleme mit reinem UDP umgehen zu können.

    Das VDR-Plugin und der Browser haben dazu neue Parameter erhalten. Sollte der Browser intern gestartet werden, ist eine weitere Konfiguration des Browsers nicht notwendig, das erledigt das Plugin automatisch.


    Falls -v nicht angegeben wird, ist standardmäßig UDP voreingestellt.

    Um das 188-Byte Problem zu umgehen habe ich zusätzlich den Patch von TomJoad genommen und die Änderungen in das Plugin verschoben.


    Weitere Bemerkungen:

    Ich hatte gehofft, die Navigation in der Tageschau und Anixe auch noch lösen zu können, war aber nicht erfolgreich. Statt Javascript aufzurufen und den KeyCode zu übermitteln, habe ich versucht direkt im Browser nativ die KeyCodes zu verwenden. Allerdings brachte das nicht den gewünschten Erfolg. Was ist an den Seiten so besonders? Auf anderen Seiten funktioniert doch alles. Jetzt muss ich erstmal auf eine Erleuchtung hoffen :( Zumal es mit Firefox/Firehbbtv ja auch funktioniert, aber eben nicht unter Chrome/HybridTvViewer.


    Als Nächstes werde ich versuchen, das mpeg-dash und livestream-ts Problem anzugehen und eine Lösung zu finden. Sofern keine weiteren Bugs auftauchen, die eine schnelle Lösung erfordern, oder ich wieder einen Flash bekomme und untersuche, warum die oben erwähnten Sites nicht funktionieren.


    wird der download der Media Dateien vom Browser gemacht oder nutzt Du dafür ffmpeg?

    Den Download erledigt ffmpeg selbst und auch transcoding (falls notwendig) und das Bereitstellen per Netz.

    Deshalb meine ich ja, das man die Klasse aus dem Browser nehmen müsste, anpassen und in ein Plugin giessen.

    Das Transcoding wird nur gemacht, falls es notwendig ist, ansonsten werden die Audio- und Video-Streams nur kopiert und als mpegts ausgegeben. Das erzeugt fast keine Last. Die Codecs werden ermittelt und die optimale ffmpeg Kommandozeile zusammengebaut.

    Auch webm wären kein Problem, zumal das auch das Standardformat ist, das momentan fast immer (bis auf Ausnahmen) im hbbtv Plugin gelesen werden.

    Brainstorming:

    Im HbbTV Plugin mache ich etwas ähnliches. Im Prinzip nutze ich ffmpeg (mit einer evt. Transcodierung nach h264/aac) um Videodaten direkt aus dem Netz zu lesen und an den VDR zu senden: z.B. per UDP. Der Receiver/Player im VDR-Plugin ist dazu recht übersichtlich.

    Das Problem düfte die Steuerung sein: Pause, Play, Stop, Vorwärts, Rückwärts. Im HbbTV-Plugin gibt die HTML-Seite die entsprechenden Kommandos an die Implementierung, welche dann wiederum ffmpeg entsprechend neu startet/stoppt.

    Wenn man jetzt noch die ffmpeg-Klasse aus dem Browser mit dem Player aus dem Plugin verbindet und ein OSD bastelt, wäre eine Umsetzung denkbar.


    Aber das ist nur die VDR-Seite, auf der Android-Seite muss ich passen.


    -I/opt/cef? Okay. Dann hast du CEF selbst installiert? Das habe ich schon lange nicht mehr probiert. Sollte aber trotzdem klappen.

    Der eigentliche Fehler scheint zu sein, daß ein Link fehlt. Das müsste funktionieren:

    Code
    1. /opt/cef/include && ln -s ../include cef


    Aber grundsätzlich empfehle ich eher die lokale Installation von CEF, weil die besser kontrolliert werden kann und - wichtiger - ein Release Order erstellt wird, in dem alles enthalten ist (CEF und sonstige Dateien). Dieser Order kann dann überall hin kopiert oder auch rückstandsfrei gelöscht werden, falls kein Interesse mehr da ist.


    Dazu muss einmalig (sofern man die Sourcen behält und nicht immer alles löscht) folgendes aufgerufen werden. Es wird CEF heruntergeladen, die Libs compiliert und auch der obige Link gesetzt.

    Code
    1. make prepare_release


    Dann reicht es, bei jedem Update (git pull) nur folgendes aufzurufen:

    Code
    1. make release


    Der Release-Order ist dann komplett mit allem, was notwendig ist.

    yes ffmpeg 4.3 did the trick for tagesschau24

    the other missing thing is dash, but you already kow

    Great. The mpeg-dash thing is on my priority list. But at first i want to fix all obvious bugs and corner cases.

    what does that mean?


    You mean the CHANNEL command? These are all necessary information for the browser to be functional. Some sites needs the current channel information.

    VDR has no trace log level, or? Because some log output is too noisy. But sometimes i need them.


    Wenn ich über DVB-T WDR über Internet aufrufe bekomme ich folgende UR

    Ich habe dein Problem nachstellen können und verstehe jetzt, worauf du hinaus willst. (Dank der Channel Informationen ;) )

    In der Seite soll ein Video bzw. ein Livestream angezeigt werden: http://cdn.hbbtvlive.de/wdr/fs.ts

    Ich muss mal schauen, warum bei .ts nicht das normale Videohandling unterstützt wird.


    Wobei....


    Ich fürchte, das liegt daran, daß ich nicht an die Laufzeit des Videos komme. Was auch irgendwie klar ist, bei einem Livestream.

    Hmm... hmm... Vielleicht muss da eine Ausnahme-Behandlung für .ts her. Oder sogar für Videos, bei denen die Laufzeit nicht bestimmt werden kann.


    onAnixe the browser is also crashing Chrome

    Is this problem still valid? Because i'm not able to reproduce the crash. But navigation is still not possible. Could be the same problem as for Tagesschau.

    Wenn ich über DVB-T WDR über Internet aufrufe bekomme ich folgende URLs

    Erzeugt das die Ausgabe aus #164 Screenshot???

    Die URL selbst kommt mir bekannt vor, die SID, ONID, TSID stimmen nicht mit meinen Werten überein. Die Channel-Informationen, die an den Browser übergeben werden, werden gerade besonders bei der ARD ausgewertet und abhängig davon, ändert sich die Seite leicht (Das Erste, die Dritten, viele weitere aus dem Senderverbund und die Spezialangebote).


    Ich versuche mal mit den Daten einen Aufruf zu simulieren.


    Mein WDR Köln HD hat diese Daten:

    Code
    1. onid":9999,"tsid":111,"sid":11155,


    is there any valid ffmpeg 4.3 ppa for Ubuntu 20.04 focal?

    Hopefully another one can help, i don't know.

    Bei ServusTV bekomme ich den gleichen Fehler

    Das Problem ist gefixed und committed. Wenn oben nur etwas von Parse Error steht, dann ist mit hoher Wahrscheinlichkeit mein Versuch mißlungen, die Seite etwas umzuschreiben.


    Aber ich weiß nicht, was normalerweise so bei ServusTV zu sehen sein soll, aber so richtig beeindruckt bin ich da jetzt nicht unbedingt. Oder sendet mein Provider eine andere URL?


    Edit: Ich musste noch einen Fix nachschieben. Ich bin mir fast sicher, daß in ein paar Seiten Änderungen auftauchten, die vorher nicht da waren.

    udp ist einfach unzuverlässig. Ich habe den Continuationcounter der ts-Pakete mitlaufen lassen und bei den Störungen fehlen komplette Pakete. Mit einem wesentlich grösserem Puffer scheint es zumindest seltener zu sein

    Ich bin mir nicht sicher, ob es vorher nicht besser war. Ich dachte UDP mit loopback und dann auch noch ffmpeg direkt senden lassen, wäre eine gute Idee. Aber so ganz überzeugt bin ich gerade nicht.


    Gibt es Meinungen dazu? War es vorher besser? Oder doch bei UDP bleiben? Oder ist das egal?

    Ich denke, es sollte kein großes Problem sein, das Transportprotokol auf die vorherige Version zu ändern.

    Sind die ständigen Meldungen [hbbtv] Send command 'APPURL 03:http://tv.ardmediathek.de/index.html' normal?

    Die kommen vielleicht etwas zu oft und auch permanent. Ich werde die mal ausblenden.


    äre es nicht 'idiotensicherer', wenn hier nicht die packet_size als Multiples von 188,

    Ich habe die Logik etwas verändert. Werte < 188 werden mit 188 multipliziert und Werte >= 188 werden genau so genommen. Zusätzlich wird geprüft, ob ein Vielfaches von 188 angegeben wurde.

    hmm, http://hbbtv01p.anixe.net/pub/anixesd/ticker/index.php und FireFox + HybridTvViewer geht.

    Ich habe unter Chrome beide Extensions versucht und beide gehen nicht. Ich muss doch mal für Firefox die Extension besorgen. Eigentlich sollte der Source-Code gleich sein. Die Initialisierung könnte sich unterscheiden. Aber daß die Browser noch so eigene Spezialitäten haben, wie früher, will ich einfach nicht glauben.


    Scheint zu Laufen:

    Okay. Plugin erweitern und das Display konfigurierbar machen...

    vdr lief parallel, damit auch X


    Okay. Ich konnte deine Ausgabe genau nachstellen, wenn ich ein nicht-existentes Display angegeben habe:


    Kannst Du mal versuchen, mit dem echten Display zu starten? DISPLAY=XXXX ./vdrosrbrowser --trace
    Ich muss dann das Display im Plugin konfigurierbar machen.

    9000H

    Are these the Anixe URLs?

    http://hbbtv01p.anixe.net/pub/anixesd/ticker/index.php

    http://hbbtv01p.anixe.net/pub/anixehd/ticker/index.html

    Both aren't working in the Chrome extension. There is something really strange. I will try to examine these, because a crash shall never happen.

    Es sieht wie das alte Problem aus, wo es noch einen Rest (nicht durch 188 teilbar) gibt.

    Hmm. Laut ffmpeg Doku wird garantiert, daß nur 188 Bytes und vielfaches gesendet werden. Zumindest hatte ich das in einem 7 Jahre alten Ticket gefunden. Ansonsten muss die damalige (hört sich älter an, als es in Wirklichkeit ist) Lösung statt im Browser in das Plugin eingebaut werden. Achja. Die alte Ausgabe gibt es ja auch nicht mehr, weil der Code ja komplett ersetzt wurde.


    Das lief dort noch nie, hat also nicht unbedingt was mit Änderungen zu tun

    Dann bin ich beruhigt. Ich denke schon kreuz und quer, was ich kaputt gemacht haben könnte.

    [0706/172247.681500:ERROR:browser_main_loop.cc(1485)] Unable to open X display.

    Hmm. Läuft kein X oder kommt der Browser nicht dran? Berechtigung und dergleichen.

    Ich hatte xvfb noch nicht im echten Einsatz. Weiß also nicht, ob das überhaupt brauchbar ist, weil man dann auch die GPU Unterstützung ausschalten muss. Parameter müsste ich raussuchen, die kenne ich nicht auswendig.


    [0706/172247.764755:FATAL:cef_ref_counted.h(325)] Assert failed: ptr_ != __null.

    Ich bin mir nicht sicher, ob das eine Folgefehler von oben ist oder etwas ganz anders.

    Ich bin nochmal die Änderungen im Plugin durchgegangen. Die greifen erst (Video per UDP), wenn tatsächlich ein Video angeschaut wird. Das neue Kommando kann max. Auswirkungen im Browser haben.

    Die Änderungen im Browser hingegen, waren schon etwas durchgreifender.


    Also systematisch:

    - Wenn VDR und Browser nicht laufen, dann sollte auf den Ports 5560 und 5561 nichts mehr zu finden sein.

    - Startet der Browser denn alleine ohne VDR? Am besten mit ./vdrosrbrowser --trace. Die Konsole sollte dann ein paar Ausgaben bringen, die vielleicht helfen können.

    - Hast du mal versucht ein make clean im Browser und dann neukompilieren?


    Die nächste Variante wäre dann, im Plugin den automatischen Start auszuschalten (Parameter -s auskommentieren oder entfernen) und den Browser und VDR getrennt zu starten, um zu prüfen ob der Browser vielleicht - aus welchen Gründen auch immer, abschmiert?


    Welches war denn die letzte funktionierende Version / Commit?

    Unable to send command...

    Hmm... Das ist allerdings seltsam. Die Sockets werden vorher erstellt und der Browser hat auch schon Lebenszeichen gesendet, oder? Läuft denn der Browser tatsächlich? Das kann eigentlich nur schief gehen, wenn die Gegenseite nicht da ist. Das Kommando ist dabei relativ egal.

    Oder werden die Kommandos zu früh gesendet? Während der Browser noch startet.


    Funktioniert denn irgendwas oder geht gar nix?



    onAnixe the browser is also crashing Chrome

    Anixe? I will take a look. But there exists a problem. I don't have Anixe in my channels.conf, nowhere. Could you please provide me the URL and possibly the channels.conf entry?




    Beim abspielen von Videos habe ich wieder Bildfehler.

    Die UDP Paketgröße ist/war suboptimal. Ich habe im Browser die Paketgröße und die interne ffmpe-Buffergröße konfigurierbar gemacht.


    In der Datei vdr-osr-ffmpeg.config gibt es die beiden neuen Konfigurationseinträge, mit denen man spielen kann:

    Code
    1. # UDP packet size, must be a multiple of 188 (default, if not configured is 1316)
    2. # udp_packet_size = 1316
    3. # UDP buffer stze (default is 31960 = 170 * 188)
    4. # udp_buffer_size = 31960

    Ich hoffe, damit wird es besser.

    Tagesschau: Wie komme ich zum nächsten Video? Mit rechts, unten oder skip geht es nicht.

    Die Tagesschau... :/Ich muss zugeben, daß ich bisher genau da noch keinen Hinweis auf ein Problem gefunden habe, noch habe ich eine Idee, was genau auf der Seite nicht so funktioniert, wie es soll. Genau diese Page ist noch eine (Vanta)Blackbox.



    Mit WDR-Videos habe ich ziemliche Probleme, Seit der neuen Version sind sie erheblich weniger geworden, aber die Meldungen


    Korrellieren mit Bildaussetzern. Ich weiß noch nicht, woran es liegt und wie ich es ändern kann. Ausgabedevice? Konfiguration? Das ist etwas ärgerlich.

    Version 0.0.4 wurde getaggt und das ppa baut gerade für den Browser.

    Wichtig ist, daß sowohl der Browser und das Plugin beide aktualisiert werden müssen (auf aktuell Version 0.0.4). Ansonsten sind Probleme zu erwarten.


    Changelog Plugin:


    Changelog Browser:


    Die Änderungen in Prosa:

    • Der Video-Transfer vom Browser zum Plugin wurde vollständig auf UDP umgestellt. Dabei werden die nativen Fähigkeiten von ffmpeg verwendet. Die Latenz sollte drastisch sinken.
    • Das Plugin sendet die URLs und die Applikation-Ids an den Browser
    • Der Browser verwendet die Applikation-Ids um die Navigation z.B. auf den ARD Seiten zu ermöglichen
    • Die in einem anderen Beitrag erwähnten problematischen XMLHTTPRequests (SID decimal oder hex) werden jetzt intern korrigiert.
    • kleiner Fixes