Synology Photos ffmpeg-thumb braucht Stunden bzw. Tage

[oicfar]

Zufälligerweise habe ich auch so konvertiert.

https://kb.synology.com/de-de/DSM/t..._videos_to_be_compatible_with_Synology_Photos

 

[Benares]

Was vielleicht für dich interessant sein könnte/dürfte:

Bei mir sind die Indizierungseinstellungen des Medienservers so eingestellt:



Damit auch die (Handy-)Videos unter /photos mit indiziert werden. Unter /video liegen auch etliche Aufnahmen (Filme) meines VU+-Receivers als .ts-Dateien. Wenn ich dort in die @eaDir-Verzeichnisse schaue, geht es wesentlich schlanker zu. Da gibt es außer einer kleinen Datei mit Medieninfos gar nichts. Die Video-Indizierung unter /photos arbeitet also anders und ist wesentlich umfangreicher. Vielleicht ist sie ja nur für kleinere Videos gedacht und nicht für ganz Filme. Dafür ist ja eher /video vorgesehen.

 

[oicfar]

Du musst aber den Hinweis beachten:


Bei mir ist nur /music drin.

Ansonsten werden Bilder und Videos, die sich im /home/Photos befinden, für die Thumbs-Erstellung gescannt.

 

[oicfar]

Gibt es vielleicht irgendwo ein Skript/Tool, mit dem man über die gesamte Struktur auf dem NAS den Plattenplatz für alle @eaDir sich anzeigen lassen kann?

Ansonsten müsste ich so was mal machen. Damit ich ein Überblick bekomme, wo was "verloren" geht.

 

[Benares]

Den Hinweis kenne ich. Trotzdem macht es einen großen unterschied, ob Videos unter /home/Photos (Persönlicher Speicherplatz) bzw. /photo (Freigegebener Bereich) oder unter /video liegen (s.o.). Aus welchem Grund hast du deine Filme im Bereich von Synology Photos liegen?

Edit: Über google habe ich folgenden Befehl gefunden, der die Größe aller @eaDirs ausrechnen sollte

find /volume1/photo -print0 -name '@eaDir' | du -ch --files0-from=-

Edit2: Nö, passt nicht.

Edit3: so passt's:

 find /volume1/photo -name '@eaDir' -print0 | du -sch --files0-from=-

 

[oicfar]

Den Hinweis kenne ich. Trotzdem macht es einen großen unterschied, ob Videos unter /home/Photos (Persönlicher Speicherplatz) bzw. /photo (Freigegebener Bereich) oder unter /video liegen (s.o.). Aus welchem Grund hast du deine Filme im Bereich von Synology Photos liegen?

Weil es mein erstes NAS und erste Synology ist. Irgendwo sah ich, dass man die Bilder/Videos für die Photos App unter /home/Photos ablegen sollte.

Und wer liest schon die Anleitung.

Aber danke für den Tipp. Ich werde das bei mir umstellen.

Edit: Über google habe ich folgenden Befehl gefunden, der die Größe aller @eaDirs ausrechnen sollte

find /volume1/photo -print0 -name '@eaDir' | du -ch --files0-from=-

Edit2: Nö, passt nicht.

Ja, habe es auch gestern mit find gemacht. Muss aber noch schauen, ob es hier was "besseres" gibt. Ansonsten was eigenes schreiben.

 

[oicfar]

Ich habe die letzten Tage meine Videos analysiert und mir ein bash Skript gebastelt, wo ich anhängig von den ausgelesenen Parametern die Videos entsprechend konvertiere. Dadurch habe ich es erreicht, dass nur der eine Softlink bleibt und keine FILM_M Qualität mehr berechnet wird.

Schon spanendes Thema um Platz auf dem NAS zu sparen. Wenn man im Vorfeld nicht weiß, was da gemacht wird, kann man eine falsche Entscheidung treffen, wenn man die HDDs kauft. Zum Glück bin ich hier mit 3x12 TB gestartet und hab' reichlich Platz.

 

[Thonav]

Vielleicht willst Du ja noch ein wenig detaillierter beschreiben was genau Dein Skript macht und wieviel man dadurch spart.

 

[oicfar]

Wie viel gespart wird, kann ich nicht sagen. Aber im Vergleich zu der Ursprungssituation, die zu dem Post hier geführt hat, wird schon was sein.

Ich rechte die Videos auf 720p herunter. Da ich hie ca. 3000 (vor allem ältere Videos haben). Die neuen konvertiere ich in 1080p. Außerdem stellte ich fest, dass da noch Videos dabei sind, wo die Rotation nicht richtig vermerkt ist und das versuche ich zu erkennen und zu berücksichtigen. Klappt noch nicht so optimal. Da muss ich bei Gelegenheit noch ein wenig dran basteln.

Ich lese erst die Infos aus

$(ffprobe -v quiet -print_format json -show_format -show_streams $input_file > $output_file_json)

Dann werde ich diese aus und entscheide, was ich mache.

        if [[ "$width" == "640" && "$height" == "480" ]] || [[ "$width" == "480" && "$height" == "640" ]]
        then
            # only copy the original
            echo "  -> copy the original"
            echo "    -> src $input_file"
            echo "    -> desc $output_file"
            cp $input_file $output_file
            continue
        else
            echo "  -> convert the original"
            if [[ "$rotation" == "-90" || "$rotation" == "90"  ]] || [[ "$width" == "720" && "$height" == "1280" ]]
            then
                echo "    -> process wih rotation"
                ffmpeg ...
            else
                echo "    -> process wihout rotation"
                ffmpeg ...
            fi
        fi

Grüße
Rafal

 

[oicfar]

So

sieht dann die CPU Auslastung, wenn ~700 konvertierte Videos auf den NAS kopiert wurden. Schnell abgearbeitet und nicht so belastet.

 

[Benares]

Wäre toll, wenn du deine Erfahrungen abschließend noch mal zusammenfassen könntest. Dann hätten alle was davon und müssten nicht erst den ganzen Thread lesen.

 

[oicfar]

@Benares wollte ich noch machen. Wohl aber im Laufe der kommenden Woche.

 

[oicfar]

Hier eine kurze Analyse, wie Synolgy Photos die Videos konvertiert.

Um die Synology zu entlasten sollte man die Videos so

https://kb.synology.com/de-de/DSM/t..._videos_to_be_compatible_with_Synology_Photos

konvertieren.

Was bedeutet das im Detail?

Wen man sich an die Vorgabe von Synology hält, dann sieht das so

Spoiler: Video in 720p mit H.264 Codec

user@syn:/volume1/photo/videos/2023$ ls -al VID_20230907_181453894.mp4 \@eaDir/VID_20230907_181453894.mp4
-rwxrwxrwx+ 1 rafcio users 250340026 Sep 10 14:32 VID_20230907_181453894.mp4

@eaDir/VID_20230907_181453894.mp4:
total 144
drwxrwxrwx+ 1 root root     276 Sep 10 14:36 .
drwxrwxrwx+ 1 root users  47624 Sep 10 15:36 ..
drwxrwxrwx+ 1 root root      46 Sep 10 14:35 @eaDir
-rwxrwxrwx+ 1 root root     477 Sep 10 14:35 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root      79 Sep 10 14:35 SYNOINDEX_VIDEO_METADATA
lrwxrwxrwx+ 1 root root      32 Sep 10 14:35 SYNOPHOTO_FILM_H264.mp4 -> ../../VID_20230907_181453894.mp4
-rw-r--r--  1 root root   14965 Sep 10 14:36 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root    9903 Sep 10 14:36 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root  104227 Sep 10 14:36 SYNOPHOTO_THUMB_XL.jpg

im Datei System aus. Man sieht, dass Synology hier die im richtigen Format vorliegende Datei nicht neu rendert. Es wird einfach ein Softlink (SYNOPHOTO_FILM_H264.mp4 -> ../../VID_20230907_181453894.mp4) gesetzt. Sieht wohl so aus, dass Synology die Dateinamen im @eaDir Verzeichnis nutzt um es einheitlich zu halten. An sich ein sehr guter Ansatz.

Ist die Hochgeladene Datei im 1080p Forman, so wird noch von der Synology 720p berechnet.

Spoiler: Video in 1080p mit H.264 Codec

user@syn:/volume1/photo/videos$ ls -al \@eaDir/C0116_1080p30.mp4
total 39940
drwxrwxrwx+ 1 root root      316 Sep  7 05:13 .
drwxrwxrwx+ 1 root root     8072 Sep  6 23:47 ..
drwxrwxrwx+ 1 root root       86 Sep  7 05:13 @eaDir
-rwxrwxrwx+ 1 root root      469 Sep  6 17:12 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root       78 Sep  6 18:56 SYNOINDEX_VIDEO_METADATA
lrwxrwxrwx+ 1 root root       23 Sep  6 17:12 SYNOPHOTO_FILM_H264.mp4 -> ../../C0116_1080p30.mp4
-rw-r--r--  1 root root 40723633 Sep  7 05:13 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root    16866 Sep  7 05:13 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root    11322 Sep  7 05:13 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root   123470 Sep  7 05:13 SYNOPHOTO_THUMB_XL.jpg

Wenn man sich nicht an die Vorgaben hält, dann werden bis zu zwei Qualitätsstufen generiert. Das belastet die Synology (vor allem, wenn man sehr viele Videos kopiert) und der Platzverbrauch steigt. Was das in 5 bedeutet, habe ich nicht ausgerechnet. hängt am Ende auch von den Videos ab.

Und so sieht das auf dem Dateinsystem aus

Spoiler: Videos ohne H.264 Codec

-rwxrwxrwx+ 1 user users 6329705553 Aug 17 18:22 C0114_1080p_original.MP4

@eaDir/C0114_1080p_original.MP4:
total 610440
drwxrwxrwx+ 1 root root       310 Sep 10 16:43 .
drwxrwxrwx+ 1 root root       680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root        40 Sep 10 16:43 @eaDir
-rwxrwxrwx+ 1 root root       471 Sep 10 16:28 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root        79 Sep 10 16:28 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 312450446 Sep 10 16:43 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 312450439 Sep 10 16:43 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root     18559 Sep 10 16:28 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root     12394 Sep 10 16:28 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root    139358 Sep 10 16:28 SYNOPHOTO_THUMB_XL.jpg


-rwxrwxrwx+ 1 user users  312186565 Sep 10 16:36 C0114_1080p_ffmpeg.mp4

@eaDir/C0114_1080p_ffmpeg.mp4:
total 610432
drwxrwxrwx+ 1 root root       310 Sep 10 16:46 .
drwxrwxrwx+ 1 root root       680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root        40 Sep 10 16:46 @eaDir
-rwxrwxrwx+ 1 root root       459 Sep 10 16:41 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root        79 Sep 10 16:41 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 312455452 Sep 10 16:46 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 312455445 Sep 10 16:46 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root     18085 Sep 10 16:43 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root     12188 Sep 10 16:43 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root    120451 Sep 10 16:43 SYNOPHOTO_THUMB_XL.jpg


-rwxrwxrwx+ 1 user users  312509681 Sep 10 16:33 C0114_720p_ffmpeg.mp4

@eaDir/C0114_720p_ffmpeg.mp4:
total 610612
drwxrwxrwx+ 1 root root       310 Sep 10 16:49 .
drwxrwxrwx+ 1 root root       680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root        40 Sep 10 16:49 @eaDir
-rwxrwxrwx+ 1 root root       456 Sep 10 16:41 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root        79 Sep 10 16:41 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 312550925 Sep 10 16:49 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 312550918 Sep 10 16:49 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root     17891 Sep 10 16:46 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root     12097 Sep 10 16:46 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root    118344 Sep 10 16:46 SYNOPHOTO_THUMB_XL.jpg




-rwxrwxrwx+ 1 user users 1451284184 Sep 10 16:08 C0118_4k_original.mp4

@eaDir/C0118_4k_original.mp4:
total 125312
drwxrwxrwx+ 1 root root      310 Sep 10 16:54 .
drwxrwxrwx+ 1 root root      680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root       40 Sep 10 16:54 @eaDir
-rwxrwxrwx+ 1 root root      468 Sep 10 16:42 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root       79 Sep 10 16:42 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 64048694 Sep 10 16:54 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 64048687 Sep 10 16:54 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root    19485 Sep 10 16:49 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root    13039 Sep 10 16:49 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root   173550 Sep 10 16:49 SYNOPHOTO_THUMB_XL.jpg


-rwxrwxrwx+ 1 user users   64467406 Sep 10 16:38 C0118_1080p_ffmpeg.mp4

@eaDir/C0118_1080p_ffmpeg.mp4:
total 124960
drwxrwxrwx+ 1 root root      310 Sep 10 16:49 .
drwxrwxrwx+ 1 root root      680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root       40 Sep 10 16:49 @eaDir
-rwxrwxrwx+ 1 root root      458 Sep 10 16:41 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root       79 Sep 10 16:41 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 63872599 Sep 10 16:49 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 63872592 Sep 10 16:49 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root    23421 Sep 10 16:49 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root    15417 Sep 10 16:49 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root   163563 Sep 10 16:49 SYNOPHOTO_THUMB_XL.jpg


-rwxrwxrwx+ 1 user users   64135439 Sep 10 16:39 C0118_720p_ffmpeg.mp4

@eaDir/C0118_720p_ffmpeg.mp4:
total 125252
drwxrwxrwx+ 1 root root      310 Sep 10 16:54 .
drwxrwxrwx+ 1 root root      680 Sep 10 16:42 ..
drwxrwxrwx+ 1 root root       40 Sep 10 16:54 @eaDir
-rwxrwxrwx+ 1 root root      455 Sep 10 16:42 SYNOINDEX_MEDIA_INFO
-rwxrwxrwx+ 1 root root       79 Sep 10 16:42 SYNOINDEX_VIDEO_METADATA
-rw-r--r--  1 root root 64023620 Sep 10 16:54 SYNOPHOTO_FILM_M.mov
-rw-r--r--  1 root root 64023613 Sep 10 16:54 SYNOPHOTO_FILM_M.mp4
-rw-r--r--  1 root root    22812 Sep 10 16:54 SYNOPHOTO_THUMB_M.jpg
-rw-r--r--  1 root root    15121 Sep 10 16:54 SYNOPHOTO_THUMB_SM.jpg
-rw-r--r--  1 root root   159411 Sep 10 16:54 SYNOPHOTO_THUMB_XL.jpg

Wie man sieht, wurden hier keine Softlinks erstellt und es wurde 2x die SYNOPHOTO_FILM_M Qualität angelegt.

Ich habe mich dazu entschlossen, dass ich die Original-Dateien auf einer anderen Partition auf dem NAS ablege. 4K Videos habe ich sehr wenige und da ich kein 4K Bildschirm/Fernseher habe, generiere ich die kleinere Auflösung. Aktuell ist in meinem Fall 720p ausreichend. Und wenn doch jemand aus meinem Haushalt 1080p haben möchte, dann kann ich es einfach an die richtige Stelle kopieren.

Fragen? Bemerkungen?

 

[worie]

Bin jetzt nach dem Upgrade auf DSM7 auf das gleiche Problem gestoßen, dass die Erzeugung der Thumbnails der Fotos (ca. 80000) und Videos (ca. 7000) ewig lange dauert ... Leider habe ich "nur" ein DS213J mit 512MB DDR3 zu bieten :-(
Was ist aber nicht verstehe: wozu ist das alles überhaupt notwendig? Ich habe diese Daten schon lange Zeit (z.T. seit Jahren) unter DSM6 genutzt, sowohl vom Smartphone als auch vom Samsung TV aus, und auch schon da wurden mir Thumbnails angezeigt. Sind die alle verloren?

 

[oicfar]

Naja, Online-Dienste machen es auch so. Es werden kleinere Auflösungen vor generiert um dann zu entscheiden, was ausgeliefert wird. Und nicht alles, was man selbst hochgeladen hat, kann gestreamt werden. Deswegen macht Synology das.

Ich habe es bei mir getrennt. Die Original Dateien liegen woanders und bei Synology Photos habe ich vor generierte Qualität (nur bei den Videos) hochgeladen. So spate ich den Platz. Wie viel genau, habe ich nicht ausgerechnet.