Mediaserver 32bit

[joshi]

Servus Kollegen,

ich habe hier ein D945GSEJT, das ich gerne wiederbeleben möchte. Da ich trotz Prime und Youtube doch noch eine handvoll Videos habe und bekomme (hauptsächlich Downloads aus Mediatheken), wär ein Mediaserver ein netter Verwendungszweck. Ich habe zwei Chromecasts und zwei Prime Sticks im Einsatz, dorthin sollen die Filme dann flutschen. Sound hab ich auch noch ein wenig, das kann ich aber auch anders machen. Prio hat für mich die Videostreamingfunktion. Der limitirende Faktor hier sind v.a. die CPU (ein Atom N270):

Anzahl der Kerne: 1
Anzahl der Threads: 2
Grundtaktfrequenz des Prozessors: 1,60 GHz
Cache: 512 KB L2 Cache
Bus-Taktfrequenz: 533 MHz
Intel® 64: Nein
Befehlssatz: 32-bit
Befehlssatzerweiterungen: Intel SSE, Intel SSE2, Intel SSE3, Intel SSSE3

Ich habe 2GB RAM verbaut, und noch einen 2GB ATA-DOM, den ich gern als Bootdevice verwenden würde. Einfach, weil ich ihn halt noch habe, und sonst nicht wüsste, was tun damit. Muss aber nicht. Für die Daten hab ich eine 500GB SATA Platte, die ich dann einfach einmal am Tag auf eine externe Platte rsynce. Das genügt mir soweit.

Jetzt stellt sich mir die Frage, welche Debianversion und welcher Mediaserver (32bit nat.) am schlauesten sind? 10.3 muss ja nicht wirklich sein, vielleicht etwas älteres, schlänkeres? Securitytechnisch muss ich hier nicht wirklich aufpassen, die Kiste steht mit dem WLAN für TV und Handy in einer eigenen DMZ, ausgehend wird alles gesperrt, Medientransfer per SCP von meinem PC aus dem anderen Netz. Auch die Frage, ob die Medien nur ausgeliefert oder auch transkodiert werden müssen, kann ich nicht genau beantworten. Ich wüsste auch gar nicht, ob die CPU das in Realtime schaffen könnte? Material liegt max in FHD vor. Vielleicht hat ja von euch wer Erfahrung damit? Gern caste ich die Videos auch per App, muss nicht alles via Fernbedienung am TV passieren....

Danke schonmal für euren Input.

LG
Joshi

[MSfree]

Solange die Kiste nur Filmdateien unverändert über das Netzwerk an das Abspielgerät (TV) senden muß, wird sich die CPU nur langweilen. Transkodieren in ein anderes Medienformat kannst du jedoch komplett vergessen, das schafft die CPU nicht.

Das 2GB DOM ist zu klein. OK, wenn du das Teil headless betreibst und keine graphische Benutzerumgebung installierst und alles auf der Kommandozeile administrieren und konfigurieren kannst, dann könnten 2GB gerade so ausreichen, aber mit 2GB Installationsumfang mußt du heutzutage ohne GUI rechnen, mit GUI sind es eher 4-6GB.

Hat das Teil zwei SATA-Anschlüsse? Dann würde ich nämlich eine 120GB SSD als Root-Device dranhängen. Vor der Coronakrise gab es diese 120GB-Dinger schon für 18€ auf dem Grabbelktisch, im Moment liegen sie wohl eher bei 27€.

Und warum sollte es dann nicht auch gleich Buster sein? solange die Kiste nicht swapt, und das ist bei 2GB RAM unwahrscheinlich, kannst du ruhig auch Buster nehmen.

[wanne]

Ich würde eher nen Bananapi M1 nehmen. Der Kaufpreis hat sich am kleineren Stromverbrauch schnell amortisiert. Was die Kiste schafft, schafft der PI auch. Als reines NAS ist der gut genug. Wenn du reencodieren willst ist da natürlich genau so Schluss wie beim Atom.

[MSfree]

Wenn du reencodieren willst ist da natürlich genau so Schluss wie beim Atom.

Der Raspberry Pi hat spezielle Video-Hardware, die einem das Transcodieren abnehmen kann, zumindest bis FullHD. Was die Banane biete, weiß ich nicht.

[joshi]

OK, es scheint, als würde das Intel-Board hier nicht viel helfen. Ich hab noch einen Pi2 rumliegen, der lt. Inet bis 1080p transkodieren kann. Dann wirds wohl der werden.
Ging ja recht schnell hier, danke für eure Hinweise

LG
Joshi

[MSfree]

Ich hab noch einen Pi2 rumliegen, der lt. Inet bis 1080p transkodieren kann.

Der hat leider nur 100MBit-Ethernet. Das reicht als Medienserver zwar völlig aus, ist aber etwas lahm, wenn es darum geht, große Datenmengen hochzuladen oder ein Backup zu machen.

FireTV oder ähnliche können natürlich nur mit der Gescvhwindigkeit Filme runterladen, die dein Internetanschluß hergibt. Da sollten die 100MBit des Raspi-Ethernets also ausreichen.

[joshi]

Das stimmt, aber so oft kommt da nix neues drauf. D.h. die paar mal, wo ich da neuen Content hochschiebe, kanns gern ein paar Minuten länger dauern. Es wird nie mehr als zwei Concurrent User geben, eher nur einen. Mich Backups liegen dann ja eig. lokal auf der USB-Platte, da ists egal, ob der mit 5, 15, oder 50MB/Sek schreibt

[debianoli]

Ich würde das mit dem Intel-Board trotzdem machen. Du kannst ja alles bis auf /usr auf deine 2GB klatschen und dann noch eine 6 GB Partition für /usr auf der 500gb Platte. Müsste eigentlich auch ein openmediavault drauf laufen. Ob der Stromverbrauch bei dem Gerät groß ins Gewicht fällt, wenn man die HD bei Ruhe zum schlafen schickt, wage ich zu bezweifeln.
Ich nutzeHardware so lange es geht. Das ist das Schöne an Linux und Debian, damit kann man Hardware viel länger nutzen als mit Win oder OSX

[MSfree]

Du kannst ja alles bis auf /usr auf deine 2GB klatschen und dann noch eine 6 GB Partition für /usr auf der 500gb Platte.

Ich kann mich vage daran erinnern, daß es da in neueren Debianversionen (war es ab Stretch?) zu Problemen kommt. Das ist also vermutlich keine so gute Idee.

Müsste eigentlich auch ein openmediavault drauf laufen.

Aktuelle OMV-Images sind 64-bitig. Man kann wohl auch ein 32Bit Buster installieren, das OMV-Repo in die sources.list eintragen und dann OMV installieren. Da OMV aus PHP-Skripten besteht, müßte das also auch auf 32Bit laufen, ist aber mehr Installationsaufwand.

Ob der Stromverbrauch bei dem Gerät groß ins Gewicht fällt, wenn man die HD bei Ruhe zum schlafen schickt, wage ich zu bezweifeln.

Ich hatte selbst mal so ein Atombrett mit einem Atom 330 (OK, das was ein Dual-Core), das Ding hat im Leerlauf bei abgeschalteter Platte um die 15W gezogen. Irgendwann war die Netzwerkschnittstelle hin, die Platte zu klein und Board und Platte wurde durch ein Board mit einem i5-3450 ersetzt, der genauso viel Strom im Leerlauf zieht.

So ein Raspi zieht im Vergleich dazu 1-2W, mit laufender 3.5"-Festplatte können es auch 10W werden. Und wenn beides vorhanden ist, würde ich wohl auch dem Raspi den Vorzug geben, vor allem, wenn das Ding 24/7 laufen soll.

Ich nutze Hardware so lange es geht.

Ich nicht. Ich nutze Hardware, solange es sinnvoll ist. Mein 12 Jahre alter Core2-Quad schlürft halt deutlich intensiver an der Steckdose als mein i3-7100, dabei ist der i3 auch noch doppelt so schnell. Den Blick auf die jährliche Stromabrechnung sollte man schon gelegendlich wagen.

[wanne]

OK, es scheint, als würde das Intel-Board hier nicht viel helfen. Ich hab noch einen Pi2 rumliegen, der lt. Inet bis 1080p transkodieren kann. Dann wirds wohl der werden.

Auch wenn er laut Spec 1080p30 Full HD HP H.264 kann. Das mag für Videokonferenzen wo sich eh nix bewegt und die Qualität zweitrangig ist eventuell funktionieren. Wenn du wirklich echtes Multimedia live reencodiren willst, willst du dafür nen richtigen modernen Rechner haben. Also GeForce GTX 10XX oder neuer und einen ordentlichen Multicore-Prozessor >= 4 Kerne. Verstehe aber nicht, warum du das wollen würdest. Der Chromecast frisst doch praktisch jedes Format. – Und gleich 10 mal jedes für das der PI Hardwaresupport hat. Und der dürfte selbst beim decoden nicht in SW hinter her kommen.

Da OMV aus PHP-Skripten besteht, müßte das also auch auf 32Bit laufen, ist aber mehr Installationsaufwand.

Bitte beachten, dass offizielles PHP in 32Bit keine Dateien über 4GiB handeln kann. (Es gibt irgend wo patches.)

Ob der Stromverbrauch bei dem Gerät groß ins Gewicht fällt, wenn man die HD bei Ruhe zum schlafen schickt, wage ich zu bezweifeln.

Wie hier schon mehrfach angemerkt. Der Prozessor alleine zieht vermutlich im Idle 3W. Dazu kommt der unsägliche DDR2-RAM der mindestens 10W ziehen dürfte. Unter 15W betreibst du so nen Rechner nicht. Und dann bist du halt gleich mal ~40€/Jahr an Strom los. 3€/Monat sind nicht viel aber es läppert sich. Davon bekommt man halt einen Pi.

Der hat leider nur 100MBit-Ethernet.

Und vor allem kein SATA. USB hält deine CPU beim Lesen halt nen PI1 defakto unter Vollast. Luft für was anderes ist dann oft nicht mehr so viel. Der PI 2 hat ne deutlich stärkere CPU, da dürfte das nicht mehr so Schlimm ins Gewicht fallen Probieren geht da wohl über studieren...

[MSfree]

Bitte beachten, dass offizielles PHP in 32Bit keine Dateien über 4GiB handeln kann. (Es gibt irgend wo patches.)

Das ist für OMV glaube ich nicht relevant. OMV stellt über PHP ja "nur" eine Verwaltungsoberfläche dar, mit der man

• Storage (RAIDS) einrichten kann
• ein paar Plugins installieren kann
• die Software aktualisieren kann (apt...)
• Benutzer einrichten kann
• Filesharingdienste NFS und SMB konfigurieren kann

Dazu wird kein Zugriff auf Dateien benötigt, die größer als 4GB sind.

Und vor allem kein SATA. USB hält deine CPU beim Lesen halt nen PI1 defakto unter Vollast... Der PI 2 hat ne deutlich stärkere CPU, da dürfte das nicht mehr so Schlimm ins Gewicht fallen Probieren geht da wohl über studieren...

Ich habe hier einen Pi2 mit Kodi am TV. Dateien liegen allerdings auf meine Server, der an den Pi mit NFS angebunden ist. Abspielen von Filmen funktioniert damit völlig problemlos. Die Datenraten über NFS sind normalerweise im Bereich von einem Megabyte pro Sekunde und die CPU ist beim Abspielen auch kaum ausgelasetet, die Videobeschleunigung im Pi2 scheint also ganz gut zu funktionieren. Ich glaube nicht, daß eine USB-Festplatte mehr CPU-Last erzeugen würde als die aufgelötete USB-NIC, und bei für Video typischen Datenraten von 1-3MByte/s ist das sowieso irrelevant.

[wanne]

und die CPU ist beim Abspielen auch kaum ausgelasetet, die Videobeschleunigung im Pi2 scheint also ganz gut zu funktionieren

Das Abspieln kein Problem ist, ist, ist klar. Aber decoden üblicherweise über den Faktor 10 weniger aufwändig ist wie encoden! In Hardware gißen lässt es sich dank weniger branches auch deutlich besser. Daneben ist der direkte Output auf DP üblicherweise deutlich weniger anspruchsvoll als die Daten über den RAM nochmal aufs Netzwerk zu hauen.
Das Szenatiro hat um Größenordnungen nichts mit nem Reencoder zu tun.
Hier mal der Vergleich zwischen de- und encoden:

Code: Alles auswählen

$ time ffmpeg -y -t 5 -i /media/data/Film/bbb_libx265.mp4 -f mpegts -c:v mpeg2video /dev/null
> user    0m8.945s
> sys     0m0.255s
$  ffmpeg -y -t 5 -i /media/data/Film/bbb_mpeg2.mpeg -f mpegts -c:v hevc  /tmp/output
> user    1m23.257s
> sys     0m1.003s

Deswegen kann ich beim Zocken nebenher 3 Videos laufen lassen brauche fürs Streamen aber ne zusätzliche dedizirte 2. Grafikkarte.

Die Datenraten über NFS sind normalerweise im Bereich von einem Megabyte pro Sekunde und die CPU ist beim Abspielen auch kaum ausgelasetet

Abspielen tust du ja nur sehr langsam lesen. Kein vergleich zu du pumpst mit GBit/s einen Film auf die Platte. Aber wie schon angemerkt: Limitierender Faktor ist da zuerst mal eh das 100MBit/s-Ethernet.

[MSfree]

Das Abspieln kein Problem ist, ist, ist klar.

Auch das Encoding ist beim Raspberry Pi in Hardware gegossen. Zumindest kann man mit einem angeschlossenen Kameramodul FullHD eindampfen, ohne daß der ARM groß zu tun bekommt.

[wanne]

Auch das Encoding ist beim Raspberry Pi in Hardware gegossen. Zumindest kann man mit einem angeschlossenen Kameramodul FullHD eindampfen, ohne daß der ARM groß zu tun bekommt.

Und dann hast du ein Video, gegen das jedes VHS-Band tolle Qualität ist.
Oder wie ich geschrieben habe:

Das mag für Videokonferenzen wo sich eh nix bewegt und die Qualität zweitrangig ist eventuell funktionieren.

Aber halt garantiert nicht für Filme die man genießen will.