Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Was ist denn am Ende der Kette dein Abspielgerät für den RTP-Stream? Der müsste doch eigentlich selbst etwas puffern, schon um Netzwerkschwankungen auszugleichen. Den Puffer im Transcoder (ffmpeg) will man eigentlich so klein wie möglich halten um die Latenz nicht zu erhöhen. Kannst du andere Quellen testen um zu sehen ob die ruckeln? Ruckelt es wenn du den RTP-Stream mit einem Software-Player abspielst?
-b:v ist die Bitrate für den Videostream und hier Käse da der Videostream ja nicht neu enkodiert werden soll (-vcodec copy).
Jo eben, ist doch der einzige Vorteil von dem Kram, dass der selbst in HD Kopierschutzfrei ist. Und dank Internet-Streams auch mit stinknormalen Videoplayern abspielbar. Rechtfertigt u.a. auch die Zwangsabgabe trotz dessen dass man kein Fernsehgerät hat.
Ein Ruckeln wegen zu hoher Prozessorlast, Netzwerk etc. ist ausgeschlossen? Ja
Bin direkt mit einen Netzwerkkabel Gigabit verbunden.
Direkt kann ich den ARD Stream auch rückfrei sehen.
Die CPU i7 th11 ist nicht mal zu 10% ausgelastet, ich codiere den H.264 auch nicht neu.
Alternativ könntest du den Stream auch in einer Datei speichern und (ggf. Zeitversetzt) in einem anderen Prozess senden.
Da fehlen mir aktuell die Befehle für.
Wenn ich diesen dann "abspiele" ist es auch ruckelfrei.
ffmpeg -stream_loop -1 -re -i out.ts -c copy -f rtp_mpegts rtp://224.2.2.2:2234?pkt_size=1316
Aber ich benötige einen Live Betrieb, 5 sek. Verzögerung stören mich aber nicht.
Ich habe etwas gelesen von thread_queue_size, aber ich verstehe es nicht. Was ist ein normaler Wert dafür?
Ergänzung ()
Marco01_809 schrieb:
Was ist denn am Ende der Kette dein Abspielgerät für den RTP-Stream? Der müsste doch eigentlich selbst etwas puffern, schon um Netzwerkschwankungen auszugleichen. Den Puffer im Transcoder (ffmpeg) will man eigentlich so klein wie möglich halten um die Latenz nicht zu erhöhen. Kannst du andere Quellen testen um zu sehen ob die ruckeln? Ruckelt es wenn du den RTP-Stream mit einem Software-Player abspielst?
-b:v ist die Bitrate für den Videostream und hier Käse da der Videostream ja nicht neu enkodiert werden soll (-vcodec copy).
Jo eben, ist doch der einzige Vorteil von dem Kram, dass der selbst in HD Kopierschutzfrei ist. Und dank Internet-Streams auch mit stinknormalen Videoplayern abspielbar. Rechtfertigt u.a. auch die Zwangsabgabe trotz dessen dass man kein Fernsehgerät hat.
Ich habe mir überlegt, das es besser ist den RTP Stream über eine seperate Netzwerkkarte zu streamen. Leider schaffe ich es nicht den ffmpeg Befehl anzupassen.
eth0 ist mit dem Internet-Router verbunden
eth1 soll für den RTP Ausgangsstream genutzt werden
Ist es nötig eth1 eine feste IP zu geben, da dort kein DHCP läuft? Oder ist es egal, das es ein Multicast Stream ist?
