Only "F_Null_Packets" with Pluto Firmware 0303

    Hallo Robert,


    danke für Deine ausführlichen Informationen.


    Mein Pluto bekommt von der H.265-EncoderBox via UDP den Transportstream. Dieser ist immer völlig gleich da keine Parameter geändert werden.


    Lediglich abhängig von der Pluto-Firmwareversion gibt es einmal "F_Null_Packets" und einmal nicht. Und genau das ist es was ich nicht verstehe.


    Auch mit Ändern von Parametern (sowohl in der H.265 EncoderBox als auch im Pluto) bekomme ich die "F_Null_Packets" bei den neuen Firmware-Versionen nicht weg.


    Ältere Firmware-Versionen kommen mit meinem UDP-Transportstream (geliefert von der H.265 EncoderBox) prima klar, die neueren nicht.

    Quote from DD4YR

    Unterschiedliche Ergebnisse zwischen den Firmwareversionen bei gleichem UDP Stream und Parametern im PLUTO sind nicht möglich.

    Genau das passiert bei mir aber. Der UDP-Stream ist unverändert und auch die Parameter im Pluto sind identisch. Keine Ahnung warum es dann unterschiedliche Ergebnisse gibt.


    Die "Null_Packets" die meine EncoderBox erzeugt scheinen von den neuen Firmware-Versionen einfach ignoriert zu werden. Und dann fügt der Pluto natürlich "F_Null_Packets" ein.


    Eine Decodierung im MiniTiouner erfolgt aber immer! Einmal halt mit F_Null_Packets und einmal mit echten "Null_Packets".

    Ja, wie schon geschrieben, der Pluto kann nur fehlende Pakete zur TS-Rate available auffüllen und als Fakenull packets kennzeichnen.

    Die Zusammensetzung des Videostreams ist primär Aufgabe der vorangestellten Video H265 encoding Soft / Hardware.

    Leider ist der Transporstream über DVB-S2 nicht dynamisch sondern an eine fixe Datenrate gebunden.

    Was jetzt der Evariste da in seinem speziellen H265 encoder box Teil der Pluto Firmware versucht hat zu korrigieren weiß ich nicht.

    Schließlich wurde dieser Part aufgrund seines geringen Erfolges auch nicht weiter verfolgt.


    73 de Robert

    Quote from DD4YR

    Was jetzt der Evariste da in seinem speziellen H265 encoder box Teil der Pluto Firmware versucht hat zu korrigieren weiß ich nicht.

    Schließlich wurde dieser Part aufgrund seines geringen Erfolges auch nicht weiter verfolgt.

    Hmm, in den neuen Versionen gibt es aber doch u.a. die "H264/H265 box control (option)" noch. Und das funktioniert auch. Man kann schön sehen wie der Pluto die Parameter in der EncoderBox abhängig von den gewählten Einstellungen anpasst.


    Mein zentrale Frage wäre nun: Benutzt jemand die H.265-EncoderBox zusammen mit einer neueren Pluto-Firmware ohne "F_Null_Packets" zu erzeugen? Und wenn ja, warum funktioniert das dort und bei mir nicht? ;)

    Oder etwas anders gefragt: Warum werden bei den neuen Pluto-Firmwareversionen die "Null_Packets" bei jeweils identischem Transportstream der H.265 EncoderBox scheinbar ignoriert und stattdessen "F_Null_Packets" eingefügt?


    Im Moment denke ich ja noch das ich irgendetwas falsch mache. Aber was? ;)

    Das ist einfach zu beantworten.

    Die seperate Ausweisung / Kennzeichnung von Fakenull packets wurde erst in den jüngeren Firmwareversionen eingeführt.

    Bei den älteren Firmwareversionen geht das einfach im overhaed unter.


    (Hab das gerade nochmal bei der 2908 ausprobiert. Ist so, dass keine Fakenullpackets trotz zu niedriger Datenrate angezeigt werden. )

    Ja, sowas hatte ich auch schon vermutet. Die älteren Versionen zeigen allerdings in der Transportstream-Analyse des Pluto echte „Null_Packets“ des UDP-Streams an!


    Erst bei den neuen Versionen fehlen diese dann in der Analyse komplett. Als würden sie ignoriert bzw. nicht erkannt.


    Es kann aber durchaus sein das die Darstellung/Bezeichnung in der älteren Pluto-Firmware etwas unglücklich war. Und mein Transportstream vielleicht wirklich keine echten Null-Pakete hat. Und ich dieser Anzeige auf den Leim gegangen bin, hi.


    Vermutlich kann die EncoderBox gar keine Null-Pakete erzeugen. Wie auch, denn die Box kennt ja die Sendeparameter gar nicht. Der Pluto füllt den Rest dann einfach mit Fake-Paketen auf.


    Vielleicht sollte ich besser doch auf die Software-Lösung umschwenken ;)

    Hallo Frank,

    hast du beobachtet um wieviel mehr Rechenleistung du jetzt brauchst? Bei mir steht ein Neukauf an. Ich möchte mit der DATV Anlage Mobil bleiben und brauche eine Abschätzung der Rechenleistung die für eine Softwarelösung notwendig ist. Der Rechner sollte natürlich möglichst klein sein (zB.: NUC) als "stand alone" Gerät der ausschließlich für ADTV dient. Und wie verwendest du die FreeStreamCoder Software genau.

    73 Peter

    Hallo zusammen,

    vielleicht ein kleiner Tipp:

    Die MiniTioune Software krallt sich immer einen kompletten Kern aus den CPU Kernels. Will man jetzt mehrere Anwendungen gleichzeitig laufen lassen, dann macht es Sinn eine CPU mit möglichst vielen Kernen zu verwenden. Geschwindigkeit ist sekundär.

    In meinem Fall läuft Minitioune im Kern 11. In Summe ist dadurch die CPU wenig ausgelastet, und ich bin somit in der Lage mit 12 Kernels OBS, ffmpeg, usw. bis hin zur SDR-Console alles gleichzeitig laufen zu lassen und hab nur 60% CPU Auslastung in Summe.

    Schaut euch mal die aktuelle Auslastung eurer Kernels an, mit und ohne MiniTioune ....

    Übrigens, es läuft auch MiniTioune noch problemlos mit 0,9 GHz Taktfrequenz .....

    73 de Robert


    Starting with a full DFU, I installed 303 and the 303 hardware patch. Sending H.264 over RTMP works as expected. Sending HEVC/H.265 over UDP transmits ok, but the provider/service names are missing and the analysis page is obviously wrong with no info displaying in the buffer analysis. Is this behaviour normal?


    If not, what could have gone wrong during the 303 installation?


    I’m still quite new to DATV, so all help be be warmly received.


    EA7KIR Michael