[streamdev] Streamen von Aufnahmen

  • Auch ich habe die neuen Aufnahme-Streaming-Fähigkeiten des streamdev plugin jetzt entdeckt.
    Ist ja nur im repository drin, in der letzten versionierten 0.6.0 noch nicht.
    Und soweit ich sehe sind die Fähigkeiten auch noch praktisch "undokumentiert" - weder auf der Homepage des Plugin selbst, im README des Pakets oder im VDR
    Wiki sind sie erwähnt. (Im Streaming-Artikel des Wiki steht sogar noch explizit "Da der Streamdev-server keine Aufnahmen streamen kann.." -
    habe da eben mal einen Hinweis auf den aktuellen Stand mit aufgenommen).
    Lediglich unter den Tickets der plugin-Homepage und bei einzelnen Threads hier habe ich Hinweise darauf gefunden.
    Auf diese Weise werden wohl viele Leute nichts davon mitbekommen.
    Oder habe ich irgendeine Doku übersehen?


    Anhand der recordings.html wie im Web-Interface verlinkt bekommt man Streaming-Links auf die Aufnahmen. Alternativ klappen offenbar die Indices dieser Liste mit Streaming-URL http://host:port/<index>.rec


    Mich interessiert das vor allem um auf ein Tablet zu streamen - und zwar so, dass man leicht zwischen Haupt-TV und dem Tablet hin- und herwechseln kann.


    Während bei Wiedergabe des Streams über den Desktop-VLC (Win) in der Aufnahme gesprungen werden kann, ist das leider beim Android-VLC nicht der Fall (ebensowenig beim MX Player). Der Android-VLC schafft es aber (anders als MX Player) auf einem neuen Nexus 7 nun endlich, mit aktiviertem HW-Decoding HD-Streams (live und eben nun auch Aufnahmen) flüssig wiederzugeben (jedenfalls stabil und ohne Artefakte, leichtes Ruckeln mag noch dabei sein - 720p wie 1080i - ausreichende Netzverbindung vorausgesetzt).


    Warum klappt das Navigieren in der Aufnahme bei Android nicht? Wie funktioniert das Springen denn Protokoll-technisch?


    Gibt es einen Parameter in der URL, mit dem man die Start-Position angeben kann? Wenn nicht, das wäre eine sehr interessante Erweiterung, finde ich..
    Bzw auf dem Tab würde es so erst brauchbar, wenn man jede Aufnahme immer nur ganz von vorne starten kann und nicht springen ist das nicht praxistauglich.


    Sehr hilfreich wäre auch die Möglichkeit, die Aufnahmen an der Stelle zu starten, an der sie eben auch im VDR grade "stehen" - wiederum per Parameter oder sonstwie kodiert in der URL, etwa /123.rec.current


    Schliesslich habe ich noch die App androvdr probiert: fürs Live-Streaming aus der Channel-Liste heraus ist das ja ganz gut brauchbar, um nicht umständlich die URLs selbst im MediaPlayer eingeben zu müssen. Aufnahmen unterstützt sie aber wohl noch nicht - bei Versionsdatum Juli 2012 auch schwer möglich, damals gabs die Funktion im streamdev ja noch gar nicht..
    Weiss jemand, ob daran evtl. nochmal weiterentwickelt wird? Gibt es den Source dazu?
    Oder existiert eine andere ähnliche App die noch gepflegt wird?


    Merci für die Aufmerksamkeit!

  • Warum klappt das Navigieren in der Aufnahme bei Android nicht? Wie funktioniert das Springen denn Protokoll-technisch?


    Technisch werden HTTP-Ranges genutzt (Header Range, Accept-Ranges und Content-Range). Möglicherweise unterstützt dies der Android VLC nicht? Vielleicht mal mit z.B. Wireshark die Kommunikation mitschneiden und die übermittelten Header vergleichen.


    Zitat

    Gibt es einen Parameter in der URL, mit dem man die Start-Position angeben kann? Wenn nicht, das wäre eine sehr interessante Erweiterung, finde ich..
    Bzw auf dem Tab würde es so erst brauchbar, wenn man jede Aufnahme immer nur ganz von vorne starten kann und nicht springen ist das nicht praxistauglich.


    Sehr hilfreich wäre auch die Möglichkeit, die Aufnahmen an der Stelle zu starten, an der sie eben auch im VDR grade "stehen" - wiederum per Parameter oder sonstwie kodiert in der URL, etwa /123.rec.current


    Da sehe ich nur zwei Lösungsmöglichkeiten: Anwendungsspezifisch (z.B. das VLC-Plugin scheint man mit Javascript entsprechend fernsteuern zu können) oder indem Streamdev den Anfang des Streams unterschlägt.


    Zuvor müssen aber erst noch das Remuxen von Aufnahmen und eine ordentliche Ordnerstruktur im Menü umgesetzt werden. Das wird noch dauern, da meine Zeit doch sehr begrenzt ist.

  • Danke für die Rückmeldung schmirl!


    Das scheint ja im Moment nicht gerade ein Trend-Thema zu sein..


    Zeit habe ich leider auch nicht wirklich viel (eigentlich keine..), trotzdem hatte ich mich jetzt zuletzt sogar ein bisschen mit dem Source auseinandergesetzt - und eben auch gesehen, dass da ganz normale HTTP Range Requests zum Einsatz kommen. Habe dann auch mal zum Probieren (nix sauberes was man "veröffentlichen" oder zum Patchen einreichen möchte) einen Parameter &offset=xy eingebaut, der als Prozent der Laufzeit interpretiert wird, wo gestartet wird (wenn range.from == 0). Das hat mit dem Desktop-VLC direkt funktioniert, er hat dann auch gleich die Fortschritts-Anzeige entsprechend gezeigt. Der Android-VLC dagegen kam damit nur klar, wenn man generell keine Range-response sendet, sondern eine normale 200er mit eben den Daten mit offset xy%.


    Auch das mit dem Sniffen hatte ich mir schon vorgenommen und nun mal eben gemacht. Leider ohne grosse Erkenntnis.


    Auch der Android-VLC sendet initial einen Range-Request 0-. In einer per Apache bereitgestellten .mp4 Datei konnte auch ohne weiteres navigiert werden:



    Ein Sprung führte zu:



    Nun das ganze gegen den VDR / streamdev-server (wieder zurückgerollt auf aktuellen Original-Stand!):



    Ich erkenne keinen wesentlichen Unterschied in der Response bzgl. ranges. Trotzdem reagiert der Android-VLC hier so, dass er einfach kein Spulen/Springen anbietet!
    (und wie oben gesagt, wenn man ihm einen range-Response von "mittendrin" gleich auf den 0- request untergeschoben hat, konnte er damit gar nichts anfangen - keine Wiedergabe)
    Auffällig ist beim Andro-VLC (probiert auf Nexus 7 sowie hier mit einem Galaxy S3) ausserdem, dass er nie sofort die Wiedergabe startet, sondern man immer erst nochmal den "play" Button drücken muss.


    Naja, ich weiss auch nicht wann ich nochmal Zeit habe, da weiterzuforschen. Aber vielleicht konnte ich Dich ja auf eine Idee bringen.


    Das mit dem Start ab aktuellem "resume" fände ich wie gesagt extrem hilfreich. Funktionieren täte das definitiv (s.oben), indem man eben wie Du sagst den Anfang "unterschlägt", genau. Beim Desktop-VLC (s.oben) auch indem man statt dem angeforderten initialen range den ab Start-Index zurückgibt. Ich habe aber leider keine Idee, wie ich aus dem Inhalt von "resume" (I wie I-Frame?) den Byte-Index in der Aufnahme mache..


    Aber auch das allgemeine Problem mit Andro-VLC und kein Springen (was er wie gesagt grundsätzlich offenbar schon beherrscht) zu beheben wäre natürlich sehr schön.


    Danke für die Arbeit am Plugin!


    Ein Nachtrag noch.. auch der Android MX-Player kann ohne Probleme im per Apache bereitgestellten Video springen - nicht aber bei streamdev. Irgendwas muss da noch anders sein. Strange.

    Einmal editiert, zuletzt von hivdr ()

  • Hi,


    Mein Android VLC hat auch Probleme beim Springen. Abspielen tut.


    Mit MX Player kann ich springen und abspielen. Allerdings nutze ich das smarttvweb plugin zum Streamen von Aufnahmen.


    Grüße,
    T.

    Server: Asrock J3455-ITX with Ubuntu 20.04, ubuntu vdr dist, streamdev-server, live, smarttvweb, vnsiserver, dynamite
    Clients: Samsung UE40ES5700 (VDR on Smart TV widget), Kodi

  • Ich habe noch etwas experimentiert mit den Headern. Weder das Hinzufügen des "fehlenden" Server-Headers, noch ein anderer content-type (mp4) oder Änderungen bei den Cache-Headern haben etwas bewirkt.
    Ich denke also an den Headern liegts nicht.


    Es muss am Inhalt liegen. Und tatsächlich: stelle ich eine VDR .ts Datei via Apache bereit, so kann der Andro-VLC auch darin nicht springen. Da ist wohl einfach die Android-Version noch nicht weit genug.


    Solange also der VLC-Port nicht entsprechend weiterentwickelt wurde, bleibt nur, die Daten serverseitig zu steuern.


    Anhand der Infos hier, http://www.vdr-wiki.de/wiki/index.php/Index (resume enthält offenbar eine frame-number) und der im recplayer schon enthaltenen Funktion positionFromFrameNumber() werde ich hoffentlich demnächst die Zeit finden, das mal testweise einzubauen, etwa via Parameter &resume=1.


    externremux hin zu einem besser verträglichen Format würde dann vermutlich auch helfen, was ja auf Deiner Agenda steht. Aber ich selbst habe nicht vor, nur deshalb mit hohem Rechenaufwand / Energiebedarf das Material generell durch den converter zu jagen..


    Nachtrag thlo: ich vermute das smarttvweb plugin macht dann eben auch irgendeine Konvertierung der Daten hin zu einem Format, mit dem zumindest der MX-Player dann besser umgehen kann. Ist ja interessant was es alles gibt. Samsung TV hätt ich auch, aber noch D-Serie. Und von dem proprietären Schmarrn will ich ja mit dieser Sache grade weg - Samsung smartview ist eigentlich eine nette Sache, aber nervt durch soviele indiskutable Schweinereien: nicht nur beschränkt auf Samsung-TV, auch die App läuft nur auf Samsung-Geräten, und selbst da oft genug nicht, spätestens nach dem nächsten Android-Update.. dazu nutzt es irgendwelches UPnP-Gedöns, das man nicht mal eben durch einen Router durchbekommt. Sauberes Streaming auf einem einzelnen Port, so muss das..

  • Moin!


    etwa via Parameter &resume=1


    Vorschlag meinerseits:
    Nur "&resume" nimmt die Position aus der Datei, "&resume=<Zahl>" nimmt die übergebene Zahl als Framenummer. Dann könnte man auch Links auf bestimmte Stellen in einer Aufnahme bauen.


    Lars.

  • hivdr: Danke für Dein Engagement!
    Die Idee, beim initialen Request die Range ab Resume-Position zurückzugegeben, ist genial. Standardkonform ist dies natürlich nicht, aber die meisten Player dürften darauf reinfallen. Ich würde dieses Verhalten in den Streamdev-Server Plugin-Einstellungen konfigurierbar machen mit default standardkonform (also Anfang der Aufnahme unterschlagen).


    Als Parameter würde ich pos={resume|resume.#|mark.#} vorschlagen. Neben der normalen resume-Datei kann es auch benutzerspezifische geben (siehe VDR Parameter "Wiedergabe-ID" und remotetimers Multiuser-Unterstützung). Das direkte anspringen von Markierungen ist sicherlich auch sinnvoll. Falls benötigt, ließe sich das auch um frame.# oder nur # (Byte-Position) erweitern. mini73: was hast Du bei den Links auf bestimmte Stellen im Sinn?


    Das Remuxen von Aufnahmen wird uns hier nicht weiter bringen. Ein Spulen wird in Aufnahmen via Remux nicht möglich sein: Weder die Gesamtlänge der umgewandelten Aufnahme ist bekannt noch ist es möglich aus der Position im umgewandelten Stream auf die Position im Original zu schließen.

  • mini73: was hast Du bei den Links auf bestimmte Stellen im Sinn?


    Man könnte seiner Holden (oder anderen Mitbewohnern) hausintern Links schicken, frei nach dem Motto "schau dir mal diese Stelle an".
    So, wie man das von YouTube-Videos her kennt.


    Lars.

  • Also ich habe dann tatsächlich mal etwas gebastelt..


    Der Parameter pos erlaubt: resume | mark.# | time.# (Sekunden) | frame.# | # (<100 -> Prozent, sonst Byte-Index)
    (offen bleibt also individuelles resume.#)


    Per default wird das File "abgeschnitten", innerhalb dieses Bereichs wird dann auch korrekt navigiert (wenns der Client denn beherrscht).
    Ausserdem kann man dem ganzen noch ein Präfix "full_" voranstellen (bessere Bezeichnung ist mir nicht eingefallen), bei dem dann doch mit der Gesamtlänge bzgl. range gearbeitet wird (wie man einen config-Schalter einbaut, weiss ich nicht, ausserdem erscheint es mir Stream-spezifisch in der URL flexibler). Hier freut mich zwar, wenn Du die Idee "genial" nennst, nur wie gut es funktioniert ist etwas zweifelhaft. Mal klappt es problemlos, dann gar nicht: der vlc zeigt nur "Müll".. und das obwohl ja die gleichen Daten geschickt werden, lediglich der gemeldete range-Bereich ist anders (umfassender). Es scheint mir auch vom Material abzuhängen, aber auch bei ein und derselben Aufnahme und den gleichen Stellen hat es mal geklappt und mal nicht (Restart vlc egal). Manchmal fordert der vlc dann auch die letzten 128 Byte an - und hängt (also kein Absturz, nur die Wiedergabe). Sehr seltsam.


    Den HEAD-Teil habe ich nicht berücksichtigt, mir ist nie ein HEAD-Request untergekommen.
    Die Berechnung des Frame aus der Zeit (wie in marks oder eben selbst angegebene Sekunden) geht einfach von 25fps aus.
    Theoretisch könnte man bei den Frames noch immer zum nächsten oder vorherigen I-Frame springen - aber ich hatte (ohne full_) keinerlei Probleme mit beliebigen Stellen, auch mitten-im-Frame (byte- oder Prozent-Index).


    Bei mir klappt es also soweit. Es ist aber natürlich weit weg davon, absolut gründlichst durchgetestet zu sein. Da ich es im Moment selbst noch gar nicht benutzen kann wie beabsichtigt (mein Haupt-VDR ist zu alt für das neue Plugin), kann es auch noch etwas dauern, bis es zu ggf. nötigem Feintuning kommt. Aber falls mir selbst noch ein grösseres Problem auffällt, werde ich es hier nachtragen.


    schmirl - würde mich freuen, wenn Du es übernimmst bzw. Dich inspirieren lässt.
    Etwas Qualitätskontrolle schadet definitiv nicht (hatte seit Ewigkeiten nichts mehr mit C/C++ am Hut, und von VDR-Programmierung verstehe ich schon gar nichts).


    Diff gegen das aktuelle Repository (bzw. vom 30.8. - wenn das noch aktuell ist..):
    (diff ist auch nicht so mein Metier, ich hoffe das ist so für "patch" brauchbar)



    Viel Spass, wenns wer brauchen kann freue mich über Rückmeldungen.

    Einmal editiert, zuletzt von hivdr ()

  • (diff ist auch nicht so mein Metier, ich hoffe das ist so für "patch" brauchbar)


    Versuch es mal mit

    Code
    diff -Nurp


    Dann sieht man besser was sich wie ändert :)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • (ah, der Bot-Post ist wieder weg, schön..)


    @seahawk ** diff -Nurp
    Danke, mit Kontext etwas leserlicher, aber nat. auch "aufgebläht". Beim nächsten mal..


    Mir ist grade aufgefallen (mit Original-Repository-Version gegengecheckt) dass die Links aus der Recording-Seite nicht funktionieren, weil hinten noch .ts mit dranhängt - laut Code wird dann das als file-extension betrachtet und ist dann also nicht ".rec"? (habe sonst meist die URL selbst eingegeben mit der Index-Kurzform)


    Nächster Schritt wäre dann auch, diese Seite mit entsprechenden Links oder Icons für "resume" auszustatten.


    Leider reagieren die Browser unter Android (probiert: FF und Chrome) auch nicht auf die Links, indem sie das Öffnen eines MediaPlayer anbieten. Gut, solange die Links das .ts enthalten, kommt wohl eh keine richtige Antwort mit passendem mimetype, aber auch wenn ich im Browser das .ts entferne startet er nur einen Download.
    Kann man unter Android irgendwo die Mimetype-App-Zuordnung editieren (kleine Recherche war erfolglos)?


    Auf dem Desktop (zB Ubuntu / FF) bietet er an es mit dem vlc zu öffnen, dann aber scheint er den kompletten Stream downloaden zu wollen, bevor er wirklich an vlc übergibt. Erst bei Abbruch des Streams (durch Stop des VDR oder Stop des Stream im plugin-Menu) startet der Player und zeigt den bis dahin geladenen Teil (dafür dann mit Zeit..)
    Sowas wie eine Übergabe der Stream-URL aus demBrowser an einen Player ist nicht möglich?

  • Hallo hivdr,


    erstmal Danke für den Patch. Sieht prima aus. Leider komme ich im Moment nicht dazu, den Patch auszuprobieren. Gib mir bitte noch ein paar Tage.
    Ein paar Dinge sind mir aufgefallen:


    Zitat

    Der Parameter pos erlaubt: resume | mark.# | time.# (Sekunden) | frame.# | # (<100 -> Prozent, sonst Byte-Index)


    Die Doppelverwendung als Prozentangabe oder Byte-Index gefällt mir nicht so, auch wenn es in der Praxis bei Werten bis 100 sicher keinen Konflikt mit dem Byte-Index gibt. Ich würde #% bevorzugen. Alles was nach dem Prozentzeichen kommt, würde ich einfach ignorieren. Wenn der Client das Prozentzeichen unkodiert sendet (damit nicht standardkonform) wird es dann genauso erkannt als hätte der Browser ein %25 daraus gemacht.


    Zitat

    Ausserdem kann man dem ganzen noch ein Präfix "full_" voranstellen (bessere Bezeichnung ist mir nicht eingefallen), bei dem dann doch mit der Gesamtlänge bzgl. range gearbeitet wird (wie man einen config-Schalter einbaut, weiss ich nicht, ausserdem erscheint es mir Stream-spezifisch in der URL flexibler). Hier freut mich zwar, wenn Du die Idee "genial" nennst, nur wie gut es funktioniert ist etwas zweifelhaft. Mal klappt es problemlos, dann gar nicht: der vlc zeigt nur "Müll".. und das obwohl ja die gleichen Daten geschickt werden, lediglich der gemeldete range-Bereich ist anders (umfassender). Es scheint mir auch vom Material abzuhängen, aber auch bei ein und derselben Aufnahme und den gleichen Stellen hat es mal geklappt und mal nicht (Restart vlc egal). Manchmal fordert der vlc dann auch die letzten 128 Byte an - und hängt (also kein Absturz, nur die Wiedergabe). Sehr seltsam.


    Schade - wenn das so schlecht funktioniert, würde ich es eher weglassen oder auskommentieren.


    Zitat

    Den HEAD-Teil habe ich nicht berücksichtigt, mir ist nie ein HEAD-Request untergekommen.


    Das lässt sich nachbessern, wenn der Rest steht.


    Zitat

    Die Berechnung des Frame aus der Zeit (wie in marks oder eben selbst angegebene Sekunden) geht einfach von 25fps aus.


    Kann ebenfalls später ergänzt werden.


    Zitat

    Mir ist grade aufgefallen (mit Original-Repository-Version gegengecheckt) dass die Links aus der Recording-Seite nicht funktionieren, weil hinten noch .ts mit dranhängt - laut Code wird dann das als file-extension betrachtet und ist dann also nicht ".rec"? (habe sonst meist die URL selbst eingegeben mit der Index-Kurzform)


    Der Fehler ist bekannt, hatte aber noch keine Zeit mich darum zu kümmern. Im Moment am besten den externremux-Pfad EXT benutzen, dann wird keine Extension angehängt (und remuxing als solches funktioniert für Aufnahmen ja noch nicht).


    Bezüglich der Browser: Kenne mich da nicht wirklich aus. Schlimmstenfalls wirst Du da über die Playlist gehen müssen, die natürlich erstmal entsprechende Links beinhalten muss. Bei FF dürfte das VLC-Plugin helfen.


    Nochmal zum Patch: Besser würde es mir gefallen, wenn alles was in cStreamdevRecStreamer::GetFromByPos() mit HTTP-Parametern zu tun hat in cConnectionHTTP stehen würde und die frameFrom...() Methoden von RecPlayer nach cStreamdevRecStreamer wandern würden. Kann ich aber auch anpassen, wenn ich den Patch integriere.

  • Hallo schmirl,


    schön dass Du den Patch berücksichtigen möchtest. Hat natürlich alles die Zeit die es braucht, nur keine Hektik, ich verspreche ja auch nichts.


    Grundsätzlich ist es Dein plugin, passe also alles so an wie Du möchtest.


    In der Sache würde ich aber folgendermassen argumentieren.


    Bei der Prozent-Sache hatte ich im Hinterkopf, dass es eben nicht funktioniert hatte, wenn ich nur ein "%" angehängt habe. Vielleicht habe ich auch was falsch gemacht (siehe eine auskommentierte Zeile im Patch). Wenn es funktioniert einverstanden, wenn man als Nutzer "%25" eingeben muss fände ich das nicht so dolle..


    Das mit full_ könnte man ja auch noch ein bisschen weiterverfolgen, etwa indem man grundsätzlich dann noch iframes nimmt (da ist ja auch eine Funktion in recplayer). Falls ich demnächst noch dazukomme es zu testen.. Auch habe ich noch keine anderen Player probiert.


    Ein Server-Header mit "Version x.y.z" ist übrigens auch noch im Patch, falls Du wüsstest wie man die VDR-Version und plugin-Version da noch reinbringt.. nicht nötig, aber wäre auch ganz schön.
    Die ein oder andere Debugging-Ausgabe wirst Du vermutl. auch aus- oder besser umbauen wollen.


    Das getFromByPos kann man nat. umziehen. Aber mich würde der eine übergebene Parameter, der da verarbeitet wird, weniger stören, als eben die ganzen Positions-Berechnungen in einer Klasse, die sich dem Namen nach nur um die reine HTTP-Verbindung kümmern soll. Ausserdem sind halt die recplayer-Aufrufe drin. Und diese Funktionen wiederum finde ich auch sehr wohl im "Player" richtig aufgehoben. Der Index etwa wird ja auch dort eingelesen, warum soll ich plötzlich resume und marks im recstreamer verarbeiten?
    Nur meine Meinung, wie oben gesagt.. Hauptsache es funktioniert.

  • So, nochmal was neues..


    Der aktuelle diff (vom gleichen Ausgangspunkt von Ende August) hängt an, diesmal im Nurp Format.


    Ich habe noch eingebaut, dass generell iFrames verwendet werden. Bei resume stehen glaub ich sowieso nur solche drin, aber bei marks (Zeitangaben) und bei direkter frame-Angabe wird rückwärts der letzte iFrame gesucht und verwendet - das schadet nie.


    Wirklich gebracht hat es aber nichts, generell kommt zumindest der vlc auch mit jedem anderen Frame klar, ausser im full_ Modus - da hat zufällig erst mal wieder alles geklappt nach der Änderung, kurz drauf war es wieder Essig. Letztlich konnte ich in einem Beispiel reproduzieren, dass bei mehreren hintereinander identisch abgerufenen Streams in den meisten Versuchen "Müll" dargestellt wurde, gelegentlich war es auch OK. Ich habe in wireshark verglichen was über die Leitung geht, und abgesehen vom Date-Header war es absolut identisch. Nur im Fehler-Fall hat vlc mittendrin angefangen die Verbindung abzubrechen (RST). An den empfangenen Daten kanns also nicht liegen, warum der vlc mal glücklich ist, und mal so gar nicht (gar nichts anzeigt oder nur Müll, versucht die letzten 200000 oder 128 Bytes abzurufen und damit aber auch nichts anfangen kann usw).
    Insofern: gebe auf, finde aber man könnte den Code (minimal, i.w. zwei if-Abfragen) ruhig drin lassen, undokumentiert..
    Wenn es initial gut geht, lässt sich danach einwandfrei in der (vollen) Aufnahme springen.


    Eingebaut habe ich ausserdem auch noch, dass der pos-Parameter auch bei initialen nicht-range-requests ausgewertet wird. Der mplayer macht das zB so, dass er nur einen normalen HTTP-Request ohne range Header schickt, und erst wenn man vor/zurück springen will sendet er die range requests. In diesem Fall geht full_ natürlich schon aus Prinzip nicht, da ja gar keine range response erwartet wird.


    Soweit der aktuelle Stand.
    Offen wären dann in erster Linie die Abspiel-Links auf der Aufnahmen-Seite. Der Android-FF bietet bei "Lang-Klick" an, die URL mit einer anderen Applikation zu öffnen - bietet aber nur den MX-Player an, nicht vlc - und wer weiss ob er das bei .rec ohne .ts auch noch täte.


    Ach ja, übergibt man neben pos noch weitere Parameter (die eigentlich ignoriert werden sollten), kommt es mehr oder weniger zu Abstürzen (hängende Verbindungen), und pos wird nicht erkannt. Das Parameter Parsing klappt also evtl. auch nicht so 100%, das habe ich mir aber nicht mehr näher angesehen.


    Aufgefallen ist mir, dass beim Live-Streaming nicht nur der Sendungs-Titel laut EPG übertragen wird, sondern auch die Dauer der Sendung, und dass die Zeit innerhalb dieses "Fensters" korrekt abläuft. Bei einem schnellen Sniffing neulich sind mir keine Header aufgefallen, das scheint im TS-Stream selbst drinzustecken? Und wird bei Aufnahmen ausgefiltert?
    Eigentlich möchte man sagen, wenn sowas sogar live geht, dann müsste es bei Aufnahmen ja erst recht möglich sein, beim Abspielen die Gesamtdauer und die aktuelle Position zu bekommen. Aber wie genau überträgt man diese Infos an den Player..?

    Dateien

  • Sind im Live-Stream nicht auch die EPG-Daten enthalten? Die sind in einer Aufnahme natürlich nicht drin, das könnte der entscheidene Unterschied sein.
    Und Videotext-Tafeln kann man beim Live-Stream ja auch anzeigen lassen.


    Eine Aufnahme hat außer PAT/PMT nur Video- und Audio-Pakete evtl. noch Untertitel, sonst nichts (wenn ich mich nicht irre).


    Lars.

  • Lars
    Das wirds wohl sein, ja - wobei das ja schon erstaunlich ist, wie der VLC das anstellt. Eigentlich kann er nur das EPG auswerten und dann anhand der aktuellen Uhrzeit die Anzeige von Fortschritt und Endzeit berechnen. Insofern wäre es im Fall von Aufnahmen wohl doch heftigste Trickserei: man müsste EPG-Daten "einbauen", die anhand der aktuellen Zeit und der Position eine virtuelle Sendung so erfindet, dass es grade passt..


    Trotzdem wär ja noch die Frage, ob es nicht auch andere Möglichkeiten gibt, einem Player die Gesamtdauer zu übermitteln, so dass er auch die Zeit laufen lassen kann.
    Der von vlc angezeigte Fortschrittsbalken dürfte wohl auf Basis der "rohen Bytes" gezeichnet werden, nicht anhand des tatsächlichen (Bitraten-abhängig schwankenden) Zeit-Fortschritts.


    Das ist übrigens eins der wenigen Dinge, die mich beim VDR immer schon gestört haben - der fehlende Videotext in Aufnahmen. War ich einst vom Topfield so gewohnt, war immer interessant zu sehen wie spät es bei Ausstrahlung grade war (ohne zu rechnen) oder die "aktuellen" Nachrichten von vor einem Jahr.. eine Option um in Aufnahmen auch solche Sachen mitzuspeichern fände ich interessant - natürlich müssten sie dann auch bei Wiedergabe entsprechend "als wäre es live DVB" verwendet werden.

  • Das Feature ist nun eingecheckt. Nochmals Danke an dieser Stelle.


    Wirklich gebracht hat es aber nichts, generell kommt zumindest der vlc auch mit jedem anderen Frame klar, ausser im full_ Modus - da hat zufällig erst mal wieder alles geklappt nach der Änderung, kurz drauf war es wieder Essig. Letztlich konnte ich in einem Beispiel reproduzieren, dass bei mehreren hintereinander identisch abgerufenen Streams in den meisten Versuchen "Müll" dargestellt wurde, gelegentlich war es auch OK. Ich habe in wireshark verglichen was über die Leitung geht, und abgesehen vom Date-Header war es absolut identisch. Nur im Fehler-Fall hat vlc mittendrin angefangen die Verbindung abzubrechen (RST). An den empfangenen Daten kanns also nicht liegen, warum der vlc mal glücklich ist, und mal so gar nicht (gar nichts anzeigt oder nur Müll, versucht die letzten 200000 oder 128 Bytes abzurufen und damit aber auch nichts anfangen kann usw).
    Insofern: gebe auf, finde aber man könnte den Code (minimal, i.w. zwei if-Abfragen) ruhig drin lassen, undokumentiert..
    Wenn es initial gut geht, lässt sich danach einwandfrei in der (vollen) Aufnahme springen.


    Vielleicht klappt es mit dem full_-Modus wenn die Daten nicht am nächsten I-Frame ausgerichtet werden sondern wenn die Übertragung mit PAT und PMT beginnt. Wäre zumindest einen Versuch wert.

  • Moin!


    PAT/PMT (mehr oder weniger) immer am Anfang zu übertragen ist sicherlich keine schlechte Idee.
    Wenn man sich die Debug-Meldungen in vlc ansieht, sieht man auch, dass er sie braucht. Sonst weiß er nicht, welche PIDs die verschiedenen Streams haben.


    Lars.

  • Ich danke ebenfalls, für die Aufnahme der Funktion ins Plugin (und die gründliche Überarbeitung meines Patch)!


    Was PMT/PAT angeht - abgesehen davon dass ich mich erst mal etwas schlau machen musste und trotzdem keine Idee habe, wie das konkret zu bewerkstelligen wäre - so spricht natürlich eine Sache gegen die Theorie, dass das helfen würde: alles was beim full_ Modus anders ist, sind die Range-Header, die eben eine Position "mittendrin" signalisieren, obwohl 0- angefordert wurde. Die Daten als solche sind ja völlig identisch, und da hat vlc keinerlei Probleme mit der Wiedergabe, ob nun an beliebigen Frames oder sogar an irgendwelchen Byte-Indices. So dringend wird er das also doch nicht brauchen, oder aber selbständig finden, egal ab welcher Position man die Daten schickt.
    Warum das nur im Fall der Übergabe eines Mittendrin-Range-Header dann anders ist, bleibt wohl bis auf weiteres ein Mysterium. Vielleicht gibt er sich bei einem Stream-Anfang mehr Mühe mit der Erkennung und verlässt sich dann bei Sprüngen auf diese "Initialisierung" - und denkt bei der full_response mittendrin es wäre ein Sprung gewesen. Nur das erklärt wiederum nicht, warum es in Einzelfällen auch mit full_ gutgeht.


    Auch könnte ich mir vorstellen, dass zumindest andere Player einen TS-Stream nicht so weitgehend unterstützen wie vlc, vielleicht sogar einfach nur Video-Daten erkennen, wiedergeben und alles andere ignorieren. Da in einer Aufnahme ja sowieso nur ein einzelnes Programm herausgefiltert wurde, gibts letztlich nicht wirklich die Notwendigkeit, irgendwelche PIDs zu unterscheiden, oder..

  • Ich meine, bei einer Aufnahme sind es die ersten TS-Blöcke, in denen die PAT und PMT drin stecken.
    Eine PAT hat immer PID 0, in der PAT steht dann, welche PID die PMT hat. Und in der PMT ist dann kodiert, welches Programm welche Video- und Audio-PIDs hat. Der vdr orientiert sich daran, wenn er ein bestimmtes Programm aufzeichnen soll, dann werden TS-Blöcke mit den passenden PIDs herausgefiltert.


    Hast du dir mal die Debug-Meldungen vom vlc angesehen? Es kann da sehr gesprächig sein. Ich hab da "früher" auch eine Weile gebraucht, bis ich bei pvrinput den Stream soweit richtig hatte, dass er da was mit anfangen konnte. PCR und SCR waren auch noch wichtig, die müssten in den Aufnahmen aber auch drin sein.


    Ich hab mit diesem Feature aber noch nicht wirklich viel herumgespielt, hatte bisher noch keine Zeit dafür. Ich steuere eher gedankliche Theorie bei... :)


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!