Mehrere Livestreams auf Raspberry Pi

Hallo,

das Enconding das in der Kamera eingestellt ist ist h265.
Mit (Netzwerk)kameras begebe ich mich auf Neuland, kann der Raspberry 
damit umgehen?

Die Netzwerkbandbreite liegt bei ca 80Mbit/s, da alle Komponenten 
1GBit/s unterstützen wird das wohl nicht der Flaschenhals sein.

Die CPU Auslastung des Raspberry ist jedoch bei allen 4 Kernen bei 100%, 
daraus schließe ich das er mit dem Encoding nicht fertig wird.

Da man in den Kameras nichts anderes als h265 einstellen kann wird wohl 
nichts anderes bleiben als auf eine andere Hardware zu wechseln.
Oder liege ich mit meiner Einschätzung daneben?

rpi schrieb:

> Die CPU Auslastung des Raspberry ist jedoch bei allen 4 Kernen bei 100%,
> daraus schließe ich das er mit dem Encoding nicht fertig wird.

Du meinst: Decoding. Aber ja, genau das schafft er offensichtlich nicht. 
Mit etwas älteren Kameras mit H.246 hätte es eventuell klappen können, 
die kann der Pi nämlich in Hardware decodieren.

> Da man in den Kameras nichts anderes als h265 einstellen kann wird wohl
> nichts anderes bleiben als auf eine andere Hardware zu wechseln.
> Oder liege ich mit meiner Einschätzung daneben?

Nö, würde ich auch so sehen. Wobei die Frage zu stellen wäre: Welche 
Hardware soll getauscht werden. Die guten aktuellen Kameras gegen was 
altes oder der offensichtlich untermotorisierte RasPi gegen einen 
richtigen Rechner?

Nach einigen Tagen des einlesens und ausprobierens bin ich ein Stück 
weiter gekommen:

Der Raspberry Pi 4 unterstützt das Hardwaredecoding von h265, leider ist 
die bisher einzige Software (die ich gefunden habe)die das auch benutzt 
Kodi. Hier bekomme ich aber ein flüssiges Bild bei nur 10% CPU 
Auslastung.

Wenn ich es richtig verstanden habe benutzt Kodi, ebenso wie Motioneye 
unter der Haube ffmpeg.

ffmpeg sollte man aber auch mit h265 Unterstützung kompilieren können, 
dann sollte Motioneye, das mir deutlich besser gefällt, doch auch auf 
einem Raspberry Pi 4 h265 decodieren können.

Die Formulierung ist etwas holprig, da ja nicht Motioneye decodiert 
sondern ffmpeg, aber ich glaube es ist klar was ich meine.

Kann diese Theorie jemand bestätigen bevor ich mich jetzt einarbeite wie 
man ffmpeg auf dem Pi kompiliert?

Danke und Gruß
Daniel

Ich denke, Du hast die falsche Hardware. Ein NVIdia Jetson Nano oder 
besser ein Xavier NX wäre eher geeignet, denn da ist neben den den 
ARM-Kernen noch eine halbwegs dicke GPU dabei, die Du haben willst. Und 
die wird von NVidia auch gut unterstützt. Auf dieser Plattform solltest 
Du dich dann mit GStreamer beschäftigen, das die Hardwarebeschleunigung 
gut unterstützt.

fchk

fchk schrieb:
> Ich denke, Du hast die falsche Hardware. Ein NVIdia Jetson Nano oder
> besser ein Xavier NX wäre eher geeignet, denn da ist neben den den
> ARM-Kernen noch eine halbwegs dicke GPU dabei, die Du haben willst. Und
> die wird von NVidia auch gut unterstützt. Auf dieser Plattform solltest
> Du dich dann mit GStreamer beschäftigen, das die Hardwarebeschleunigung
> gut unterstützt.

Tatsächlich haben auch die RasPis eine leistungsfähige GPU.

rpi schrieb:
> Der Raspberry Pi 4 unterstützt das Hardwaredecoding von h265, leider ist
> die bisher einzige Software (die ich gefunden habe)die das auch benutzt
> Kodi. Hier bekomme ich aber ein flüssiges Bild bei nur 10% CPU
> Auslastung.

Und? Was nützt Dir das? Du willst ja gleich sechs h265 Streams parallel 
dekodieren, und das in Hardware, weil in Software packt das der Pi 
sowieso nicht. Schon mal erkundigt, wie viele Streams in Hardware 
parallel dekodiert werden können? In der Spec zum Pi steht nix davon, 
daß mehr als ein Stream (4k) möglich ist. Das sieht mir stark nach dem 
falschen Werkzeug für die Aufgabe aus.pi h265 hardware

Nur_ein_Typ schrieb:
> Tatsächlich haben auch die RasPis eine leistungsfähige GPU.

Du weißt mehr? Dann her mit einem Link.

Also, eigentlich ist das mal wieder so ein typischer Thread, wie leider 
so viele hier im Forum. Statt das der TE fragt, wie eine Aufgabe zu 
lösen ist,
also "6 FHD Streams (natürlich skaliert) gleichzeitig auf einem 
Bildschirm darzustellen", kommt er zuerst mit dem Werkzeug.
Das liest sich immer so, als wenn jemand mit Schraubendreher und Nägeln 
daher kommt und will damit nun ein Regal an der Wand anbringen und dann 
muß gefrickelt und gewurschtelt werden, weil man ja schon mal einen 
kleinen Nagel mit der Schraubendreherkopf in Holz eingeschlagen hat und 
"so schwer kann ja ne Lösung nicht sein" usw. usf...

M.M.M schrieb:
> Nur_ein_Typ schrieb:
>> Tatsächlich haben auch die RasPis eine leistungsfähige GPU.
>
> Du weißt mehr? Dann her mit einem Link.

Offenbar weiß ich mehr, und natürlich google ich das gerne für Dich: 
[1].

> Also, eigentlich ist das mal wieder so ein typischer Thread, wie leider
> so viele hier im Forum. Statt das der TE fragt, wie eine Aufgabe zu
> lösen ist,
> also "6 FHD Streams (natürlich skaliert) gleichzeitig auf einem
> Bildschirm darzustellen", kommt er zuerst mit dem Werkzeug.

Stimmt, das ist ein sehr typischer Tread, denn Du erklärst sein Werkzeug 
gleich für ungeeignet -- ohne es näher zu kennen, wohlgemerkt, sonst 
hättest Du mich ja nicht um einen Link "bitten" müssen -- und empfiehlst 
deswegen stattdessen gleich einfach mal andere Werkzeuge. Das kennen wir 
hier sehr gut, egal um was es geht; insbesondere dann, wenn jemand 
Jeho^WRaspberry Pi sagt, kann man die Uhr danach stellen, wann der Erste 
nach einer zünftigen Steinigung ruft.

Dabei hat "Sheeva P." die ideale Lösung doch schon genannt: gar nicht 
auf dem Webserver de- oder enkodieren, sondern die Videos einfach 
durchreichen -- sie also gar nicht serverseitig zu de- und wieder 
enkodieren, sondern das Dekodieren ganz alleine den Clients überlassen. 
Die Clients brauchen ohnehin ausreichende Leistungsfähigkeit, um die 
Streams zu dekodieren und darzustellen. Solange nun auf dem Server keine 
Verarbeitung stattfinden muß, ist das auch dann die beste Lösung, wenn 
der Server eine richtig fette Maschine mit mehreren Nvidia- oder 
ATI-Grafikkarten ist. Denn die teure, aber völlig überflüssige Rechnerei 
kostet nur unnötig Energie: blöd für den Geldbeutel, blöd für die 
Umwelt.


[1] https://de.wikipedia.org/wiki/Raspberry_Pi#Grafik

Nur_ein_Typ schrieb:
> Dabei hat "Sheeva P." die ideale Lösung doch schon genannt: gar nicht
> auf dem Webserver de- oder enkodieren, sondern die Videos einfach
> durchreichen -- sie also gar nicht serverseitig zu de- und wieder
> enkodieren, sondern das Dekodieren ganz alleine den Clients überlassen.

Nein. Lesen der Frage hilft:

rpi schrieb:
> Am Raspberry Pi ist ein 15 Zoll Touchscreen angeschlossen
> (1920x1080), wird nun auf einen der Kamerastreams getippt soll dieser im
> Vollbild angezeigt werden(1920x1080)

Es gibt keinen weiteren Client...

Thomas schrieb:
> Nein. Lesen der Frage hilft:
>
> rpi schrieb:
>> Am Raspberry Pi ist ein 15 Zoll Touchscreen angeschlossen
>> (1920x1080), wird nun auf einen der Kamerastreams getippt soll dieser im
>> Vollbild angezeigt werden(1920x1080)
>
> Es gibt keinen weiteren Client...

Oh, stimmt. Also auch insofern ein typischer Thread... :-)

Hallo zusammen,

ich habe mir eure Tipps zu Herzen genommen, ein Jetson Nano bestellt und 
mich in gstreamer eingearbeitet.

Mit dieser Pipeline bekomme ich einen beinahe verzögerungsfreien Stream.

1

 gst-launch-1.0 rtspsrc location=rtsp://192.168....... latency=0 ! rtph265depay ! h265parse ! nvv4l2decoder ! nvoverlaysink

Um das nun in eine GUI zu packen habe ich mich dann mit GTK befasst und 
folgendes Programm geschrieben.

1

2

#include <stdlib.h>

3

#include <gtk/gtk.h>

4

#include <gst/gst.h>

5

#include <inttypes.h>

6

#include <stdbool.h>

7

8

//TODO: use cameraURL instead of dummys

9

const uint8_t cams[] =

10

{

11

    1,

12

    2,

13

    3,

14

    4

15

};

16

17

18

GstElement *pipeline[(sizeof(cams)/sizeof(cams[0]))];

19

20

GtkWidget* newCamera(uint8_t pipeNum)

21

{

22

    GtkWidget *video_window;

23

    GstElement *source, *depay, *parse, *decoder, *converter, *sink;

24

25

    pipeline[pipeNum] = gst_pipeline_new("pipe");

26

27

    source = gst_element_factory_make("rtspsrc", NULL);

28

    g_object_set(source, "location", "rtsp://192.168.178.211:554/user=admin_password=_channel=1_stream=0", NULL);

29

30

    depay = gst_element_factory_make("rtph265depay", NULL);

31

    parse = gst_element_factory_make("h265parse", NULL);

32

    decoder = gst_element_factory_make("nvv4l2decoder", NULL);

33

    converter = gst_element_factory_make("nvvidconv", NULL);

34

    sink = gst_element_factory_make("gtksink", NULL);

35

36

    if(!source || !depay || !parse || !decoder || !converter|| !sink)

37

    {

38

        printf("ERROR: not all elements could be created\n\r");

39

    }

40

41

    gst_bin_add_many(GST_BIN(pipeline[pipeNum]), source, depay, parse, decoder, converter, sink, NULL);

42

43

    if(!gst_element_link(source, depay))

44

    {

45

        printf("ERROR: linking source-depay\n\r");

46

    }

47

48

    if(!gst_element_link(depay, parse))

49

    {

50

        printf("ERROR: linking depay-parse\n\r");

51

    }

52

53

    if(!gst_element_link(parse, decoder))

54

    {

55

        printf("ERROR: linking parse-decode\n\r");

56

    }

57

58

    if(!gst_element_link(decoder, converter))

59

    {

60

        printf("ERROR: linking decode-convert\n\r");

61

    }

62

63

    if(!gst_element_link(converter, sink))

64

    {

65

       printf("ERROR: linking convert-sink\n\r");

66

    }

67

68

/*

69

    source = gst_element_factory_make("videotestsrc", NULL);

70

    sink = gst_element_factory_make("gtksink", NULL);

71

    gst_bin_add_many(GST_BIN(pipeline[pipeNum]), source, sink, NULL);

72

    gst_element_link(source, sink);

73

74

*/

75

    g_object_get(sink, "widget", &video_window, NULL);

76

    return video_window;

77

}

78

79

int main (int argc, char *argv[])

80

{

81

    GtkWidget *window;

82

    GtkWidget *vbox1;

83

    GtkWidget *vbox2;

84

    GtkWidget *hbox;

85

86

    gtk_init(&argc, &argv);

87

    gst_init(&argc, &argv);

88

89

    //generate Layout

90

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);

91

    vbox1 = gtk_box_new(GTK_ORIENTATION_VERTICAL, 0);

92

    vbox2 = gtk_box_new(GTK_ORIENTATION_VERTICAL, 0);

93

    hbox = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 0);

94

95

    //add Cameras to row1

96

    gtk_box_pack_start(GTK_BOX(vbox1), newCamera(0), FALSE, FALSE, 0);

97

    gtk_box_pack_end(GTK_BOX(vbox1), newCamera(1), FALSE, FALSE, 0);

98

99

    //add Cameras to row2

100

    gtk_box_pack_start(GTK_BOX(vbox2), newCamera(2), FALSE, FALSE, 0);

101

    gtk_box_pack_end(GTK_BOX(vbox2), newCamera(3), FALSE, FALSE, 0);

102

103

    //add rows to columns

104

    gtk_box_pack_start(GTK_BOX(hbox), vbox1, FALSE, FALSE, 0);

105

    gtk_box_pack_end(GTK_BOX(hbox), vbox2, FALSE, FALSE, 0);

106

107

    gtk_container_add(GTK_CONTAINER(window), hbox);

108

109

    for(uint8_t i = 0; i < (sizeof(cams)/sizeof(cams[0])); i = i + 1)

110

    {

111

        gst_element_set_state(pipeline[i], GST_STATE_PLAYING);

112

    }

113

114

    gtk_window_fullscreen(GTK_WINDOW(window));

115

    gtk_widget_show_all(window);

116

    gtk_main();

117

118

    return 0;

119

}

Das Problem ist das das Linken zwischen rtspsrc und rtph265depay nicht 
funktioniert.
In der Konsole funktioniert die Pipeline.
könnte mir jemand erklären wo das Problem liegt?

Danke und Gruß
Daniel