Wie wäre es damit...lautloser VDR-Streaming-Client+DVB-Receiver für 39 Euro (+60 Euro PremiereStart)

    Hallo allerseits, :)


    Zitat

    Original von Maniac
    ffnetdev funktioniert solange einwandfrei wie man nur Audio oder nur Video durchschickt, schickt man beides gleichzeitig kommen die Fehler.


    Es könnte jetzt daran liegen wie VDR die Daten liefert über die beiden Funtkionen die benutzt werden. Ich vermute das vor jedem Video und jedem Audio Packet ein Extra PES Header sitzt und dadurch zuviele Daten im fertigen TS landen. Das müsste man nur nochmal überprüfen weil es wie gesagt nur eine Vermutung ist.


    VDR garantiert beim jedem Aufruf der Funktionen PlayVideo bzw. PlayAudio, dass ein komplettes PES Packet zur Verfügung steht. Im PES2TS Remuxer wird das auch noch kurz gecheckt. Ein PES Packet wird in mehrere kleine Teile zerhäckt und dann auf die Payload der TS Pakete verteilt. Der PES Header wird dabei (natürlich) nicht entfernt.


    Inzwischen habe ich aber auch die Vermutung, dass an dem generierten Stream etwas faul ist. Nehtm doch mal ein Tool wie TSreader und jagt den TS da durch. Bei mir steht immer alles auf "grün", also keine Fehler im Stream. Der Elecard MPEG2 Codec kann den TS trotzdem nicht richtig dekodieren. Daher kann es sein, dass die TS Pakete an sich i.O sind, jedoch der enthaltene PES irgendwie beschädigt wird. Den analysiert IMHO TSreader wohl nicht.

    Habe meine Dreambox 5620 übrigens inzwischen verkauft. Zu wenig Zeit für den Spass. :(


    Da ich aber auch noch einen Windows Client hier am Start habe, den ich gerne mit ffnetdev als VDR Fernbedienung für meinen Budget-Karten-Server nutzten möchte, werde ich mich mit ffnetdev noch weiterhin beschäftigen.....wenn ich denn Zeit finde....

    Hallo Nano,


    ich hab gerade mal kurz deine neue Version 0.0.4 mit meiner dbox (mit VDRViewer-v0.2) getestet (habs gestern erst bei mir richtig zum laufen gebracht :).
    Leider stockt der Stream immer noch.


    Folgendes steht im syslog:

    Zitat

    ERROR: invalid Count in cRingBufferLinear:: Del: 1347 (limited to 0)
    ERROR: invalid Count in cRingBufferLinear:: Del: 311 (limited to 0)
    ERROR: invalid Count in cRingBufferLinear:: Del: 1679 (limited to 1311)


    JuNuVDR
    wie siehts bei dir aus?


    Zitat

    Gut, dann schaue ich mir sobald ich Zeit habe an, was ProjektX macht


    Vor längerer Zeit hab ich mal versucht mir ProjectX näher anzuschauen aber mir (und Eclipse) ist der Code einfach zu (nennen wir es) kompliziert. Aber evtl. könnte der Autor ja auch konkrete Fragen beantworten? Leider fällt mir momentan nicht ein in welchem Forum er aktiv ist :(
    Ich habe auch schon mal gelesen, dass der Movieplayer (oder die dbox selbst?) relativ anfällig ist wenn Fehler im TS vorhanden sind. Wenn ProjectX über den Stream gelaufen ist, dann ist allerdings alles okay. Ich hatte auch schon mal pes2ts ausprobiert, damit kam meine dbox nicht zurecht.


    Habe auch gerade mal einen Stream mit netcat abgefangen und auf Platte gespeichert. Diesen Stream habe ich nun durch ProjectX gejagt und mit der dbox abgespielt. Leider mag die dbox weder das Original noch den modifizierten Stream :(.
    Der mplayer (3.2.3 für Windows (ist glaub ich schon eine ältere Version)) mag den Stream übrigens auch nicht, wenn er auch mehr darstellt als die dbox.


    Wenn man aber die original VDR-Dateien durch PrjX bearbeiten läßt, dann kommt ein "perfekter" TS raus. Wie könnte man weiter vor gehen?

    VDR - Celeron 1000 mit BudgetCard - dbox als Client ;D

    2 Mal editiert, zuletzt von DonMarti ()



    Hi,


    Mist.... also der PES2TS Remuxer müsste jetzt wirklich in Ordnung sein. Die Fehler, die Du da jetzt hast, sind auf die Thread Synchronisation zurückzuführen, vermute ich. Was für einen Rechner benutzt Du denn?


    Habe hier einen Athlon XP1800 und diese Fehler nicht.


    Gruss, Nano

    Nano,
    bin jetzt auch schon am testen gewesen ....
    Hier ruckelt es nur noch vor sich hin ... würde es beschreiben als immer wieder stockende Zeitlupe. Würde aber behaupten, da fehlt jetzt wenigstens nichts mehr im Stream!... keine Artifakte mehr.


    Aber ... bei mir wird jetzt auch noch parallell (ein anderer Sender) auf der FF mit ausgegeben ... ist das Absicht? ... Find ich super!


    Ich habe einen 500MHz Epia ... und arbeite auf VDR 1.3.27 aus Tobi-experimental
    Hier die Ausgabe ... vielleicht blockiert jetzt der mutex immer wieder?


    Weiss noch nichts mit der Ausgabe anzufangen ... werde noch weiter testen. und den stream auf platte schreiben und asynchron testen. Vielleicht scheitert es jetzt nur noch am Syncronen verarbeiten im DBOX2 Plugin, da dieser keinen internen Ringbuffer verwendet ,,,,
    wir werden sehen, sobald ich den TS auf platte habe und die DBox diesen von dort lesen lassen habe (mache ich zum ersten mal!)


    Edit: Habe den Test mit auf Platte schreiben nun hinter mir:
    1,5 Minuten ergaben nur noch 8MB.
    MPlayer unter Windows zeigt, dass der Film Störungsfrei in 3 Sekunden-Happen mit immer wieder Sprüngen läuft.

    Nano
    übrigens sagt mein VDR CPU-Last 20 % !


    Alles in allem funktioniert es hier auf jeden Fall schlechter als vorher. Ruckler an Ruckler und eben ständig, die oben gemeldeten Ausgaben ....


    Vielleicht versuche ich jetzt dann mal auf vdr 1.3.30 umzustellen? Wo testet Ihr?



    Ich denke für heute Nacht gebe ich es erstmal auf ...


    DonMarti
    ... habe leider noch nicht damit begonnen ProjektX zu debuggen.
    Das Thema scheint mir für einen Einsteiger doch noch zu kompliziert/umfangreich.


    Werde mich erst mal auf kleinere Eingriffe konzentrieren ...
    OSD-Ausfaden, oder Zentrales Konfig-File im VDR-Viewer, oder Ring-Buffer in selbigem. Aber erstmal sollte der Stream einigermassen abspielbar sein, sonst ist alle Mühe umsonst!

    OK, bei dem Support bleibe ich noch ne runde dran ... gehe gerade ans auskommentieren und compilieren.


    Edit:
    OK, habe jetzt alle Mutex-zugriffe rausgenommen. Ergebnis ist das Selbe.
    Ruckeln ohne Ende und gleiche Ausgaben.


    Ein wenig komme ich mir jetzt so vor wie vor VDRAdim-Fernseher, ... aber mit Ton :rolleyes:


    Was ich noch beinahe vergessen habe, inzwischen ist die Ausgabe auf der FF-Karte verschwunden!? Habe den VDR noch mehrfach neu gestartet.,


    Kann mich erst morgen abend wieder anhängen wenn im Augenblick nichts mehr kommt... ist auch schon ziemlich spät.
    Wünsche noch gute Nachtruhe.

    Zitat

    OK, habe jetzt alle Mutex-zugriffe rausgenommen. Ergebnis ist das Selbe.


    dito


    ich habe immer noch
    ERROR: invalid Count in cRingBufferLinear:: Del:...


    (nur nicht aufgeben ;) irgendwie werden wir den TS noch zähmen)

    VDR - Celeron 1000 mit BudgetCard - dbox als Client ;D

    Einmal editiert, zuletzt von DonMarti ()

    Nano,


    Hallo, gibt es schon neue Erkenntnisse oder einen Verdacht?
    Könnte es sein, dass wenn dein Plugin jetzt einmal aus dem tritt mit der PES-Strukltur ist, sich nicht mehr aufsynchronisieren kann ? Könnte meine Ausgabe vielleicht DARAUF hindeuten?


    Ausserdem habe ich in deiner Readme gelesen, dass du VDR 1.3.29 verwendest, während ich noch auf der 27 stehe. Meinst du, daran könnte es liegen?

    DonMarti


    Wie sieht es inzwischen bei Dir aus?
    Habe mal die Quellcodes nach Deiner Fehlermeldung durchsucht ...



    So wie es aussieht versucht da das Plugin eine größere Anzahl Bytes aus dem ringbuffer zu löschen, als es bisher je reingestopft bekommen hat! Sieht mir definitiv nach einem Fehler/Lücke im ffnetdev-Plugin aus!


    Nano
    Kannst du mal bitte einen prüfenden Blick darauf werfen? Früher oder Später dürfte dieses Problem (wenn es eines ist) auch in Deinem Windows-Client stören!
    Habe Deinen Code mal analysiert und eine prinzipielle Lücke diesbezüglich gefunden ...
    uchar *data = m_InputBuffer->Get(count);
    Liest die Daten aus, die du vom Input-Buffer bekommst.
    Die zu analysierende Länge liest du aber aus dem Paket selbst aus!
    packetlen = ((data[4]<<8) | data[5]) + 6 ;


    So wie es mir aussieht, steht hier jetzt aber eine grössere Länge drin, als du überhaupt beim Get() ausgelesen hast. Du analysierst also am Ende vermutlich undefinierte Datenteile! Ggf. ist das ein Fehler im VDR selbst, da er ja immer komplette PES-Pakete senden sollte. Dein Code scheint hier aber eine Lücke zu haben, die ... werde also ggf. auch mal auf deine VDR-Variante 1.3.29 wechseln (wenn mir möglich).



    Schade dass diese Meldung nur im Syslog und nicht in der Debug-Ausgabe bei mir auftaucht. Werde also demnächst auch mal mein Syslog mit prüfen.


    DonMarti


    Wie sieht denn Deine Debug-Ausgabe aus? Kommen bei Dir die selben Fehler-/Debugmeldungen wie bei mir?


    pacemaker
    wie sieht es eigentlich bei Dir inzwischen aus?
    Gleiche Probleme wie wir haben?

    Hallo,


    Zitat

    Wie sieht es inzwischen bei Dir aus?
    Wie sieht denn Deine Debug-Ausgabe aus? Kommen bei Dir die selben Fehler-/Debugmeldungen wie bei mir?


    Bin nicht sehr viel weiter gekommen.
    Ich habe inzwischen mal VDR 1.3.30 + 1.3.31 ausprobiert, aber leider ohne großen Erfolg. Ich meine zwar, dass es deutlich weniger Fehlermeldungen gab, aber sie sind immer noch da, genau wie die Aussetzer.
    Mal schaun, wann ich dazu komme wieder etwas zu testen, bzw. mir mal den Code anzuschauen. Allerdings sind mir die TS/PES Umkodierungen noch zu wild. Wie kann man sich am besten in das Thema "einlesen"? Gibt es ne verständliche Doku, wie die verschiedenen Stream aufgebaut sind?


    bis hoffentlich bald
    DonMarti



    P.S.
    Ich habe mir jetzt auch mal einen TS vom streamdev-server geben lassen und diesen mit der dbox abgespielt. Diesen TS kann der movieplayer ohne Probleme abspielen. Da die TSs, die vom ffnetdev kamen und mit netcat gespeichert wurden nicht (vernünftig) mit dem movieplayer abspielbar waren, vermute ich, dass es doch eher am ffnetdev/vdr liegt als am dbox-VDR-plugin.
    Momentan könnten es zwei stellen sein, die Probleme machen:
    1. das ffnetdev hat Probleme beim umwandeln der PES in TS
    2. der VDR wandelt den TS nicht 100%ig in PES um, was allerdings erst beim zurückwandeln auffällt?


    Ich sehe momentan Punkt 1 als unseren 1. Ansatzpunkt.
    Was meint ihr?

    VDR - Celeron 1000 mit BudgetCard - dbox als Client ;D

    Einmal editiert, zuletzt von DonMarti ()

    Hi, Leutz.


    Sorry, daß ich mich erst jetzt wieder melde. Hatte eine Woche Urlaub und wenig Zeit.
    Getestet habe ich auch noch nicht, werde ich jetzt aber nachholen.


    @DonMartin:


    Ich tippe auch eher auf Punkt 1.
    Denke, daß der Algo zum rückwandeln einen Fehler ausweist. Das sehe ich schon allein darin bestätigt, daß man eine PES-Datei, die man mit ProjectX in einen TS umwandelt, problemlos auf der DBox abspielen kann.


    Vielleicht sollte man mal schauen, was ProjectX bei der Umwandlung anders macht.


    Auf jeden Fall werde ich so bald wie möglich mal testen und mich wieder melden.


    Ciao,


    pacemaker

    pacemaker und DonMarti


    Hallo zusammen,
    hier nochmal den Link, den ich gefunden habe und der TS und PES relativ gut erklärt.
    http://www.vdr-portal.de/board/thread.php?threadid=31628&sid=&threadview=0&hilight=&hilightuser=0&page=2


    Hoffe ich kann mir mal den Inhalt zu Gemüte führen. Leider habe ich auch gerade wenig Zeit gahabt ... wird aber in den folgenden tagen wieder besser. Nano hat sich leider nicht gemeldet, obwohl meiner Meinung ein Diskreter Fehler in seinem Plugin zu bestehen scheint. Siehe vorige Postings, ...
    was meint Ihr zu meiner Interpretation? Möglicherweise liegt auch dort das Problem? Er liest die Paket-Länge aus dem PES Tag aus und schickt genau diese Menge an die Clients, da aber die Länge eben auch falsch zu sein scheint, wundert es mich nicht, dass der movieplayer spuckt! Kommt Ihr zum selben Schluß ?


    Ich weiss, - ich muss das ganze erst noch genauer austesten, - mache ich auch noch sobald ich dazukomme. Hoffe immer noch auf Stellungsnahme von Experten/Euch.


    ;D


    Hier noch mehr Details zu TS, die ich gefunden habe
    http://www.theoinf.tu-ilmenau.…/Data/SA_Schaepe_Sven.pdf



    Und noch besser, weil noch Umfangreicher
    http://www.cdaniel.de/download/is138181.pdf



    Bis bald.

    DonMarti und pacemaker




    Habe mich inzwischen über das von DonMarti berichtete Problem hergemacht und den wesentlichen Fehler im ffnetdev Plugin hoffentlich beseitigt, der aus DonMartis Logs hervorging..


    Bei mir scheint nun zumindest der MPlayer unter Windows die NetCatteten Streams halbwegs brauchbar abzuspielen! Auch auf der DBOX ist es jetzt etwas brauchbarer, wenngleich noch immer mit Ruckler.


    Kann es mal jemand von Euch testen und berichten, ob wir auf dem rechten Weg sind ? :]


    Hier die geänderte Datei:

    @alle
    Kann es denn bitte jemand mal testen, ob es besser geworden ist?
    Ausserdem hätte ich die Bitte, dass jemand mal mit Netcat den Stream aufzeichnet und dann in die DBOX2 via NFS-Share einspielt. Wie ist dann das Ergebnis? ... mein Sportster-Image hat wohl probleme überhaupt ein Verzeichnis zu mounten, weshalb ich den Test nicht so schnell machen kann.


    Besten Dank für Rückmeldung,
    ... meine Fehlermeldungen sind übrigens mit meinen Änderungen auf jedenfall verschwunden ... Streamen ist wieder in Sync, wenn gleich wie bisher üblich, nicht immer gleich ein Connect zustande kommt. Öfters probieren ... muss wohl auch noch geprüft werden.
    Solltet Ihr Verbesserungen erkennen, werde ich Nano bitten die Änderungen zentral aufzunehmen und gg.f eine 0.0.5 daraus zu machen ;o)


    Sollte der aufgezeichnete Stream via NFS-Mount mit der Dbox fehlerfrei (oder nahezu fehlerfrei) funktionieren, - was ich durchaus für denkbar halte, könnte ich erst mal im DBOX-Plugin einen Ringbuffer, eine zentrale Config-Datei und das OSD-Fading einbauen.
    Wie sieht es aus? Heut ist das Wetter doch eh miess!

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden