3. Simples standardisiertes Streamingprotokoll

Simples standardisiertes Streamingprotokoll

  • T

    Hallöle,
    gibt es ein simples standardisiertes Streamingprotokoll für unkomprimierte Audiodaten? Irgendwie sowas wie RTP Light ohne RTCP?
    Irgendwie bin ich zu doof, da was zu finden. Ich will im Prinzip einfach Daten über UDP an eine IP:Port schicken, wobei der Header für jedes Paket im einem halbwegs dokumentiereten Standard entspricht.

    0

  • Wie wärs mit FTP?^^

    0
  • T

    dot schrieb:

    Wie wärs mit FTP?^^

    Wie streamt man denn damit?

    0

  • Na die Daten kommen doch als Stream an, man muss sie eben nur noch abspielen...

    War auch nicht ganz ernst gemeint. Ich bin gewiss kein Experte was das angeht, aber imo sollte doch TCP allein schon genügen wenn du einfach nur unkomprimierte Daten streamen willst?

    0

  • Ich vermute dass Tachyon die Abspielgeschwindigkeit beim Sender steuern können möchte.
    Dann würden quasi alle Lösungen wegfallen, die dafür gemacht sind vorgefertigten Content zu streamen.

    Sollte ich mich irren, und es reicht dass der Empfänger die Abspielgeschwindigkeit kontrolliert, dann einfach HTTP.

    0
  • M

    rtp ist doch schon dein freund. welchen codec, oder nicht-codec, du benutzt ist dabei ja egal.

    hustbaer schrieb:

    Ich vermute dass Tachyon die Abspielgeschwindigkeit beim Sender steuern können möchte.
    Dann würden quasi alle Lösungen wegfallen, die dafür gemacht sind vorgefertigten Content zu streamen.

    was meinst du damit? ich gehe mal davon aus, dass er mit einfacher geschwindigkeit wiedergeben will. :xmas1:
    falls ich dich richtig verstehe, dann kann das z.b. vlc.

    hustbaer schrieb:

    Sollte ich mich irren, und es reicht dass der Empfänger die Abspielgeschwindigkeit kontrolliert, dann einfach HTTP.

    tcp kannst du fuer progressive downloads verwenden. fuer streaming ist das nichts.

    0

  • @mezzo mix
    Wenn die Clocks von Client und Server driften, der Server aber "live" aufnimmt, dann kann man TCP vergessen.
    Wenn der Server dagegen einfach aus einem File liest (z.B. Video on Demand), dann kann TCP/IP wunderbar funktionieren.

    mezzo mix schrieb:

    hustbaer schrieb:

    Sollte ich mich irren, und es reicht dass der Empfänger die Abspielgeschwindigkeit kontrolliert, dann einfach HTTP.

    tcp kannst du fuer progressive downloads verwenden. fuer streaming ist das nichts.

    Immer diese sinnvollen Belehrungen 🙄
    Weil es für Streaming "nichts ist" verwenden es wohl so viele, oder wie?

    0
  • T

    mezzo mix schrieb:

    rtp ist doch schon dein freund. welchen codec, oder nicht-codec, du benutzt ist dabei ja egal.

    RTP hat aber den Nachteil, dass es ohne RTCP nur bedingt zu gebrauchen ist, da solche Sachen wie die Telegramgröße darüber ausgehandelt werden (auch ausgehandelt werden sollen).
    Sowas brauche ich aber nicht. Die Telegramgröße ist fest und muss nicht ausgehandelt werden.
    Ich brauche etwas, mit dem ich einen kontinuierlichen Bytestrom empfangen kann und mit minimalem Buffering aus dem Stream ein hörbares Audiosignal erzeugen kann.
    Zeugs zur Zeitsynchronisation zwischen unterschiedlichen Clocks etc. ist bereits fertig. Ich brauche nur ein, am besten halbwegs gut dokumentiertes, Protokoll für das Streamingformat.
    Der Grund warum ich es nicht selbst definieren will ist, dass ich dem, der den Sender macht, am liebsten was bewährtes und gut dokumentiertes an die Hand geben will anstatt einfach was selbst zu basteln.

    PS: TCP macht es einem recht schwer, bei einem Übertragungsfehler (führt zu einem Neusenden des Paketes und bringt einem das Zeitgefüge durcheinander) gegenzusteuern. Bei UDP kann ich erkennen, dass ein Paket fehlt, und kann dann den Fehler im Audiosignal recht einfach kaschieren. Die Eigenschaft von TCP, dass es sich um eine "sichere" Verbindung handelt, ist hier eher störend.

    0
  • M

    hustbaer schrieb:

    @mezzo mix
    Wenn die Clocks von Client und Server driften, der Server aber "live" aufnimmt, dann kann man TCP vergessen.
    Wenn der Server dagegen einfach aus einem File liest (z.B. Video on Demand), dann kann TCP/IP wunderbar funktionieren.

    mezzo mix schrieb:

    hustbaer schrieb:

    Sollte ich mich irren, und es reicht dass der Empfänger die Abspielgeschwindigkeit kontrolliert, dann einfach HTTP.

    tcp kannst du fuer progressive downloads verwenden. fuer streaming ist das nichts.

    Immer diese sinnvollen Belehrungen 🙄
    Weil es für Streaming "nichts ist" verwenden es wohl so viele, oder wie?

    du hast dir die frage doch selber schon beantwortet. wenn der server aus einem file liest, z.b. video on demand bei youtube, dann nennt sich das progressive download. streaming wird z.b. bei iptv-anschluessen wie t-home vision benutzt. ich habe mir den unterschied nicht ausgedacht.

    @Tachion, ich kenne mich mit dem application layer nicht genug aus um dir im detail helfen zu koennen. ich vermute aber nicht, dass du rtcp brauchst um rtp sinnvoll zu benutzen. die settopboxen an einem iptv anschluss machen nicht mehr als einer multicast-gruppe beizutreten und den dan kommenden stream zu 'fressen'. da findet keine signalisierung zum server statt. das ist die vereinfachte sicht auf die basisfunktionalitaet.

    0

  • @mezzo mix
    Die Unterscheidung war mir nicht klar. Man liest "Streaming" so oft im Zusammenhang mit Dingen, wo es darum geht Videos zu übertragen, die irgendein Server auf der Platte liegen hat.

    Progressive Download hab' ich in dem Zusammenhang noch nie gelesen (oder so selten dass es nicht hängengeblieben ist). Auch kommt mir die Bezeichnung "Progressive Download" etwas unpassend vor, wenn man z.B. clientseitig seeken kann (was mit HTTP ja durchaus akzeptabel geht).

    Davon abgesehen wird HTTP auch für Live-Streaming verwendet. Ob das nun Sinn macht ist wieder ne andere Frage.

    EDIT: ich merke gerade, meine eigene Aussage war auch "zu absolut". Auch bei Live-Streams kann man TCP verwenden. Nur ist es nicht wirklich optimal. /EDIT

    0
Anmelden zum Antworten