HLG HDR aus Cinema Pro (Xperia 1) unter Linux weiterverwenden

Moderne Smartphones, wie das Xperia 1, unterstützen High Dynamic Range (kurz HDR) Videos. In diesem Artikel gehe ich darauf ein wie man diese Videodateien auch unter Linux anschauen und verarbeiten kann. 

Cinema Pro auf Xperia 1

Was ist HDR?

Der hohe Dynamikumfang (HDR) kennt man aus Fotos die einem erlauben tolle Fotos auch mit Gegenlicht aufzunehmen. Dafür werden unter- und überbelichtete Bilder zusammengerechnet um den Dynamikumfang zwischen ganz dunklen und ganz hellen Bereichen in einem Bild zu erhöhen. Moderne Smartphones können dies nun auch für Videoaufnahmen machen. Ganz aktuell z.B. das neue iPhone 12 mit der Möglichkeit sogar das sehr rechenintensive Dolby Vision HDR aufzunehmen. In meinem Beispiel konzentriere ich mich auf das vom Sony Xperia 1 unterstützte HLG HDR. Dieses ist nicht ganz so qualitativ hochwertig, aber eines der am besten unterstützten. 

HDR Videos unter Linux

Standardmäßig wird das HLG HDR Format unter Linux von gängigen Media Playern nicht immer unterstützt. So zeigt z.B. der VLC Media Player unter Debian in Version 3.0.11 ein ziemlich blasses und ausgewaschenes Bild. 

VLC vs MPV mit HDR HLG Video

Andere Mediaplayer wie z.B. mpv ebenfalls aus Debian in Version 0.29.1 können das HDR Format ohne Probleme darstellen. Das hilft natürlich zunächst bei der allgemeinen Darstellung, aber zu HDR gehören ja immer noch mehr Dinge. Damit HDR auch vollends genossen werden kann benötigt es auch Monitore, die das auch unterstützen. Die wenigstens Laptop- oder PC-Bildschirme bieten diese Unterstützung. Deshalb lohnt es sich das HDR Format, für die unproblematische Verteilung und Verarbeitung. in SDR (Standard Dynamic Range) umzuwandeln. 

Linux Videoschnittsoftware unterstützt meist kein HDR

Die gängigen Linux Videoschnittprogrammen wie z.B. Kdenlive unterstützen derzeit keine Verarbeitung von HDR. Löblich sind Ausnahmen wie Lightworks oder Davinci Resolve. Beides professionelle Programme, die aber nicht unter der sonst üblichen Open Source Lizenz stehen. Dank der Abwärtskompatibilität des HLG HDR Formats kann man aber auch unter Kdenlive das blasse Bild mittels Color Grading aufpeppeln. Nicht immer gelingt aber ein Look der dem entspricht, was mpv oder das Smartphone mit HDR Display selbst anzeigt. 

Mit ffmpeg von HDR zu SDR

In diesem Fall kann aber die Multimediabibliothek ffmpeg mit einigen Filtern und Optionen helfen. Die beste Einstellung die ich gefunden habe um das HLG HDR Video - aufgenommen mit Cinema Pro unter einem Xperia 1 - in SDR zu konvertieren, ist folgende: 

ffmpeg -i "Eingangsdatei.mp4" -vf zscale=t=linear:npl=250,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p -c:v libx265 -crf 10 -preset ultrafast "Ausgangsdatei.mp4"

Leider klappt diese Methode mit dem standardmäßig bei Ubuntu und Debian ausgelieferten ffmpeg Version nicht. Man müsste sich also selber eine ffmpeg Version kompilieren, dass die zscale Option unterstützt, oder man lädt sich eine bereits gebaute Version mit dieser Unterstützung herunter. 

Links: HDR zu SDR konvertiert Rechts: HDR Original

Nach der Konvertierung erhält man ein SDR Video, dass man mit KDEnlive problemlos weiterverabeiten kann. 

WLAN über LAN freigeben bei Linux (KDE Plasma)

Manchmal kann so ein Hotel / Motel WLAN mit Captive Portalen einen an seine Grenzen bringen. So auch bei mir. Eine einfache Grenze, die Grenze der Geräte die eingeloggt werden dürfen.

Session limit exceed ist eine Meldung die solche Captive Portale in solch einem Fall ausspucken. Da ich mich momentan in Neuseeland in einem kleinen Apartment befinde und es dort nur WLAN Zugang per Captive Portal gibt, habe ich bei meinen mehr als 8 Geräten die sich mit dem WLAN verbinden oft solche Meldungen gesehen.

Freedom Internet Captive Portal

Diese Captive Portale lassen sich zwar mit WIFI-Extendern weiterleiten, aber die Anmeldung per Username und Passwort über den WIFI-Extender gelingt meist nicht.
Klar man kann sich unter Linux schnell die Mac-Adresse des Extenders aneigenen und dann einloggen, aber auf Dauer ist das auch nichts, da die Portale einen regelmäßig zum relogin auffordern.

Nun ist mir eine andere Möglichkeit eingefallen die ebenfalls recht gut funktioniert und clever die Funktionen des Netzwerk Managers unter Linux ausnutzt und auch einen WIFI-Extender oder Router nutzbar macht.
Der Netzwerk Manager bietet unter Gnome oder Plasma nämlich die Möglichkeit das per WLAN empfangene Netz per LAN weiterzuleiten. Dies ermöglicht mir den WIFI-Extender im AP also Access Point Modus laufen zu lassen, wo es sich das Internet per Kabel holt und per WLAN freigibt.

Netzwerk Manager weiterleitung per LAN

Alles was man dazu tun muss ist nur die Option im Netzwerk Manager unter IPV4 "Für andere Rechner freigeben" auszuwählen, beide Geräte also Laptop und WIFI-Extender per LAN Kabel zu verbinden und man kann sich dann solange der Laptop im WLAN befindet mit anderen Geräten am WIFI-Extender anmelden und im Internet surfen. Für das Captive Portal scheint der Traffic komplett vom Laptop zu kommen.

Huawei ohne Google Services: Mehr Chancen als Scheitern

Nun ist es raus, Huawei wird ihre Mate 30 Serie wohl Mitte September ohne Google Dienste ausliefern.
Hier scheint man in der Medienwelt zumindest in Deutschland, dass Aus von Huawei in Europa zu prognostizieren.

Huawei P30 mit Huawei Hülle

Wirklich!?
Echt jetzt!?

Wo seit Jahren nach Alternativen zu iOS und Google gesucht werden und man Projekte wie Ubuntu Touch oder SailfishOS total ignoriert hat, kommt nun einer der größten Smartphone Hersteller und setzt nicht mehr (zugegebener maßen nicht ganz freiwillig) auf Google Dienste und nun geht das Untergangsgeschreie los.

Sind wir denn schon so Abhängig von Google, dass ein Smartphone ohne dessen Dienste "nutzlos" ist?
Wenn man den Artikel von Marco Dettweiler auf faz.net liest, dann ja.

Das macht mich fassunglos.
Anstatt die Chancen zu sehen und zu fördern zerreissen die Möchtegernexperten jeden kleinen Sproß von Hoffnung, dass mit einem der größten Hersteller von Smartphones in der Welt zusammen mit Software Entwicklern in Europa, wie Jolla, vornehmlich UbPorts und anderen, eine große Chance existiert ein eigenes Ökosystem aufzubauen unabhängig von den politischen Begebenheiten der USA.

Man muss doch kein technikaffiner Computergeek sein um zu wissen, dass monopolartige Strukturen zu vielen Abhängigkeiten und deswegen auch großen Nachteilen führt.

Ein Gerät egal wie gut es nun sein mag, aber ohne Google Dienste, zu verfluchen obwohl man im gleichen Text zeigt, dass es in einem Land wie in China doch funktionieren kann, wenn man ein eigenes Ökosystem aufgebaut hat, ist schon etwas schizophren.

Ich jedenfalls bin schon fast begeistert von der Ankündigung. Zusammen mit der Ankündigung dass Huawei auch in Europa ein eigenes Ökosystem aufbauen will und gleichzeitig in Russland mit dem auf SailfishOS basierenden AuroraOS herumexperimentiert, gibt es eine große Chance, dass das von mir geliebte SailfishOS evtl. auch später einmal auf Huawei Geräten zum laufen gebracht werden kann.

Huawei P30 mit SailfishOS Mockup

Noch besser wäre es wenn Huawei sich entscheidet, dass die Mate 30 Geräte ohne Bootloadersperre ausgeliefert werden, so dass man eigene Systeme auf das Gerät ohne großes zutun flashen kann.
Die Chancen, dass dies dann auch dazu führt, dass sich Community dafür interessiert und mit ein wenig Hilfe von Huawei dann auch brauchbare Portierungen hinbekommt, sind zumindestens inspirierend.

Huawei sollte die Zeichen der Zeit erkennen und das Risiko, auch als Chance begreifen. Zusammen mit anderen chinesischen und europäischen Firmen ein eigenes Smartphone Ökosystem für Europa auf die Beine zu stellen, ganz unabhängig von Google ist zumindest eine sehr verlockende Geschichte.

Stromsparen unter Linux mit Intel P-State

Stromsparen unter Linux ist ja meist eine Wissenschaft für sich. Viele Stromsparmechanismen und Tipps, sowie Tricks werden immer wieder gegeben, andere passen sich mit den Generationen der Geräte auch an. In diesem Fall will ich über eine relativ neue Stromspartechnik namens Intel P-State berichten, dass bei meinem neuen HP Spectre X360 und dem Kernel 4.20.7 standardmäßig zum Einsatz kommt.

Das Notebook ist für Entwickler und Technikaffine ein wichtiger begleiter. Auch Youtuber, Podcaster und Blogger nutzen das Notebook für ihre tägliche mobile Arbeit.
Die Freiheit immer und überall ohne Kabel leistungstarke Hardware für den Videoschnitt zu haben, oder mal schnell einen neuen Text zu schreiben mit einer ordentlichter Tastatur sind wichtige Kriterien dafür.
Aber natürlich muss auch die Akkulaufzeit stimmen. In der Vergangenheit hat sich Linux damit immer etwas schwer getan, da nicht immer alle neuen Stromsparmechanismen dort immer sofort verfügbar waren und weil die Hersteller meist auch mist in ihre Firmware/BIOS/EFI schrieben, die dazu führten dass ihre Stromspartechniken kaputt waren und nicht dem Standard entsprachen. Gefixt haben die Hersteller dies dann nur per Windows Treiber. Leider ist das heutzutage zum Großteil immer noch so.
Linux ist also hier darauf angewiesen diese Quirks zu erkennen und nachzuimplementieren.

Mittlerweile hat auch Intel erkannt, dass es für ihre neuen Ultrastromsparprozessoren Sinn macht evtl. die Steuerung raus aus der reinen Software rein in eine bessere Kooperation von Hardware und Software zu packen.
Aus diesem Grund gibt es auch den Intel P-State Skalierungstreiber für Linux. Dieser bietet im Gegensatz zum alten ACPI Skalierer, nur noch 2 Skalierungsstrategien, Performance & Powersave.

KSysguard zeigt den Takt der Prozessoren mit Performance Skalierungsmethode

Standardmäßig wird zumindest bei mir auf dem Neptune System (Neptune 6 Beta basierend auf Debian Buster) der Performance Skalierer verwendet. Der hat den Vorteil, dass er sehr viel Leistung aus dem Notebook herausholen kann, was man ja auch beim Videoschnitt benötigt.
Der Nachteil ist, dass er zumindest hier aber nicht ordentlich runtertaktet, sondern immer einen hohen Takt an der oberen Grenze. auch wenn nicht viel am Notebook gemacht wird. hält.

Der Trick ist es nun also den Powersave Modus zu benutzen, der auf vernünftigere Werte gesetzt wird und auch deutlich nach unten taktet, wenn nicht viel am Notebook gemacht wird.
Dies kann man mit modernen Tools wie cpupower auch manuell relativ schnell und einfach einstellen.
Dazu reicht der Befehl

sudo cpupower frequency-set -g powersave

Natürlich will man so etwas nicht immer manuell einstellen und hätte gerne diesen stromsparenden Modus standardmäßig im Akkubetrieb aktiv.
Steckt man dann das Stromkabel an, möchte man dann natürlich auch die volle Leistung des Rechners nutzen können und dann wäre es super, wenn der Rechner den Skalierungsmodus in performance ändert.

Gott sei dank sind wir hier bei Linux und so kann man das alles einfach und schnell mittels einiger Konfigurationsdateien auch schnell so einstellen.

Ich habe mich hier von diesem Arch Linux Foren Thread inspiren lassen, der dies für den acpi Skalierer durchführt.

Dazu habe ich mir zuerst dieses power.sh Scrtipt gebastelt, dass mittels upower überprüft ob der Akku gerade aufgeladen wird oder nicht. Je nachdem setzt er dann den entsprechenden Governor (die entsprechende Skalierungsmethode):

#!/usr/bin/bash

STATE=""

BAT="BAT0"

if [[ "$1" == "BAT" || "$1" == "AC" ]]; then

  STATE="$1"

fi

if [[ $STATE == "" ]]; then

  if [[ $(upower -i /org/freedesktop/UPower/devices/battery_$BAT | grep state | grep discharging) == "" ]]; then

    STATE="AC"

  else STATE="BAT"

  fi

fi

echo $STATE

if [[ $STATE == "BAT" ]]; then

  echo "Discharging, set governor to powersave"

  cpupower frequency-set -g powersave

elif [[ $STATE == "AC"  ]]; then

  echo "AC plugged in, set governor to performance"

  cpupower frequency-set -g performance

fi

Angepasst werden muss hier evtl. nur der Name von BAT, der bei meinem Akku BAT0 heißt.
Mittels dieses power.sh scriptes, dass zusätzlich noch mit dem Parametern AC und BAT manuell in einen Skalierungsmodus gezwungen werden kann, habe ich nun Udev und Systemd Service Dateien erstellt, dir mir beim Hochfahren oder dem Abstecken bzw. Anstecken des Stromkabels den entsprechenden Skalierungsmodus setzen.

Das Udev Script, was ich unter /etc/udev/rules.d/powersave.rules angelegt habe, sieht dann so aus:

SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/home/leszek/Downloads/power.sh AC"

SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/home/leszek/Downloads/power.sh BAT"

Der Pfad zum power.sh Script muss man natürlich ggf. anpassen.

Nun sorgt dieses Service File beim Hochfahren des Rechners dazu, dass der richtige Skalierungsmodus verwendet wird:

[Unit]

Description=Sets the CPU governor on boot according to AC mode

Requires=multi-user.target

After=multi-user.target

[Service]

Type=oneshot

RemainAfterExit=no

ExecStart=/home/leszek/Downloads/power.sh

[Install]

WantedBy=multi-user.target

Die Servicedatei habe ich unter /etc/systemd/system/power_management.service angelegt.

Nun kann es aber noch dazu kommen, dass ich das Gerät ja auch manchmal in den Standby bringe und kurz davor den Stromkabel angeschlossen habe, ich dann aber Stunden später den Kabel abstecke und dann das Gerät erst aufwecke. Damit dann die richtige Skalierungsmethode für die CPU Taktung gewählt wird braucht es einen weiteren Systemd Dienst. Dieser root-resume.service getaufte Dienst wird wiederum unter /etc/systemd/system/ angelegt.

[Unit]

Description=Local system resume actions

After=suspend.target

[Service]

Type=simple

ExecStart=/home/leszek/Downloads/power.sh

[Install]

WantedBy=suspend.target

Mit diesen Anpassungen läuft das Notebook nun doppelt so lange und somit genauso wie ich es erhofft habe und ich kann bis etwa 10 Stunden Akkulaufzeit herausholen.

Videos unter Linux schneller rendern mit GPU Beschleunigung

Videoschnitt ist ja eines meiner Hobbies, gerade als Podcaster, kommt man ja nicht immer drum herum. Nun betreibe ich ja nur ziemlich einfachen Videoschnitt via Kdenlive unter Linux und meist sind es auch nur im Falle des Techview VLogs nur Konvertierungen mit Ein- und Ausblendeffekten.

Im Falle der Techview Podcast Show wird das ganze etwas aufwendiger mit Überganagseffekten und eben etwas mehr B-Roll Schnitt der hineingemischt wird, oder auch Titel Einblendungen usw.
Etwas gestört hat mich dort bisher immer der etwas lange Atem den man haben musste, nachdem ein Video fertig geschnitten war, dieses auch herausrendern zu können. Hier ist es manchmal etwas lässtig, wenn man für ein 15 Minuten Video 30 Minuten braucht um es zu rendern.

Kdenlive

Diese Zeiten sind bedingt durch die standardmäßig in vielen Videoschnittprogrammen unter Linux verwendeten Renderprofile, die nur CPU Rendering beinhalten.
Nun gibt es aber mit VAAPI eine Schnittstelle und einen Enkodierer, sowie Dekodierer für ffmpeg, der so etwas auch auf die durchaus besser dafür geeignete GPU auslagern kann, bzw. diese mitbenutzen kann für das Rendern.

Das erfreuliche, dank sehr guter Arbeiten der Grafiktreiberentwickler für Linux ist diese Schnittstelle quasi zum Standard geworden und alle gängigen aktuellen Karten von AMD, Intel und sogar Nvidia (mittels Nouveau) unterstützen es.
Da auch aktuelle Distributionen in ihre ffmpeg Versionen die Unterstützung dafür hineinkompilieren, steht also dem Rendern eines Videoclips mittels dieser Technik nicht viel im Wege.

Auf meinen Neptune und Netrunner Systemen, basierend auf Debian Stable bzw. Testing, ist es dank der ebenfalls aktivierten vaapi Enkodierfähigkeit in der Bibliothek Melt auch in meinem Lieblingsvideoschnittprogramm Kdenlive möglich auf diese Fähigkeit zu setzen.

Renderprofile von Kdenlive

Leider liefert Kdenlive momentan noch (es ändert sich in der Zukunft, so hoffe ich) kein Standardprofil dafür aus. Deshalb habe ich etwas Hand angelegt und möchte euch hier zeigen, wie man sich sein eigenes Renderprofil unter Kdenlive erstellen kann, dass auf den VAAPI Codec für die H.264 Videokodierung setzt.
Dazu muss man einfach ein neues Renderprofil erzeugen. Ich habe eines auf Basis des vorhandenen MP4 Profils erstellt, da meine GPU nur in der Lage ist H264 ordentlich zu dekodieren und zu enkodieren. Infos darüber was eure GPU kann verrät der Befehl

vainfo

den man in ein Terminal eingeben kann. (Vorrausgesetzt das gleichnamige Paket ist installiert)

Mein "LLs Podcast Option" Profil mit VAAPI

Nun habe ich folgende Werte für mein neues LLs Podcast Option Profil eingetragen (siehe auch Foto oben):

vaapi_device=/dev/dri/renderD128 vf='format=nv12,hwupload' properties=x264-medium f=mp4 vcodec=h264_vaapi threads=4 real_time=-1 preset=faster acodec=aac g=120 crf=%quality ab=%audiobitrate+'k'

Mit diesen Einstellungen erziele ich einen deutlichen Performancegewinn, wenn es um das Rendern von Videos geht. Hier mal ein Vergleich zu einem Techview VLog den ich geschnitten habe einmal die Renderzeit mit dem MP4 Profil von Kdenlive:

Renderzeit mit Standard MP4 Profil von Kdenlive

 Und hier zum Vergleich das gleiche Renderprojekt mit meinem Profil und VAAPI Enkodierung:

Renderzeit mit VAAPI Enkodierer Profil

Wie man sehen kann ist der Unterschied schon gewaltig. Ich kann bei dem Video was etwas über 24 Minuten geht meine Renderzeit halbieren und komme so auf einen Renderwert der unter Echtzeit liegt, also mit etwa 20 Minuten kürzer ist als das Video selbst.

Das ganze jetzt auf einem noch nicht mehr so taufrischen Thinkpad E555 mit AMD A8-7100 und einer R5 Radeon Grafikeinheit in dieser APU.
Neben der schnelleren Renderzeit werden auch die CPU Kernel nicht die ganze Zeit sehr hoch belastet, so dass auch die Hitzeentwicklung nicht mehr so deutlich ansteigt bei diesem Notebook. Zumal auch bei einer kürzeren Renderzeit die Prozessoren evtl. auch gar nicht so weit wegen Hitze heruntertakten müssen.

Natürlich schneide ich nun meine Videos nicht nur auf diesem Laptop, sondern auch einem potenteren AMD Sechskern Desktop System (AMD FX-6100) das mit einer Nvidia Geforce 650 TI ausgestattet ist. Nun könnte ich hier auch auf VAAPI setzen. Aber auf diesem System ist tatsächlich der proprietäre Nvidia Treiber installiert, da ich darauf auch ab und zu Spiele spiele, die der Nouveau Treiber nicht schafft.

Der Nvidia Treiber bietet eine weitere clevere GPU Optimierung fürs Dekodieren, aber auch Enkodieren von Videos. NVENC nennt sich das ganze und ist ebenfalls in aktuellen Distros in ffmpeg und melt enthalten.
Wer also den proprietären Nvidia Treiber sein eigen nennt kann anstatt VAAPI auch NVENC zum enkodieren von Videos benutzen.

NVEnc Renderprofil

Mein Profil auf diesem Desktop Rechner sieht dann so aus:

properties=x264-medium f=mp4 vcodec=nvenc_h264 acodec=aac g=120 crf=%quality ab=%audiobitrate+'k' preset=fast

Mit diesem Profil erreiche ich auch gute Werte für das Videorendering.

Jedem sollte aber klar sein, je nachdem was man für Videos schneidet sind die Einsparoptionen  mittels der Nutzung von VAAPI oder NVEnc beim Rendern von Videos nicht immer so hoch wie in meinem Beispiel. Lohnen tut es sich aber allemal, gerade auch wenn man wie ich einen etwas älteren Rechner einsetzt und über eine potente Grafikeinheit verfügt.

Stromsparen mit Enlightenment 0.22

Der Desktop Enlightenment fasziniert mich ja schon seit Jahren. Einer der Gründe weswegen z.B. in meiner Linux Distribution Neptune auch immer wieder ein Enlightenment als Low Memory Desktop angeboten wird. Dieser wird zwar bei Neptune standardmäßig noch in der Urversion 0.16, oder DR16 genannt, ausgeliefert bietet dafür aber das notwendige um auch an einem PC mit wenig Arbeitsspeicher oder schwächerer Leistung ordentlich zu arbeiten.

E22 mit klassischer Desktop Konfiguration

Natürlich liefern wir bei Neptune aber auch die aktuelle Version 0.22 von Enlightenment aus. Diese Version kommt anders als die Version 0.16 mittlerweile in Sachen Features und Funktionen an eine komplette Desktopumgebung heran.
Die Konfigurierbarkeit ist ähnlich gut und detailreich wie bei meinem heißgeliebten Plasma Desktop, dafür bietet E22 aber einige Gimmicks die man so bei Plasma derzeit nicht findet, wie virtuelle Arbeitsflächen mit unterschiedlichen Hintergründen oder die Möglichkeit mit dem Everythinglauncher auch ohne Maus das komplette System steuern zu können.
Natürlich gibt es auch einige Einschränkungen, so muss fehlt mir eine ausführliche Einstellungsmöglichkeit für das Touchpad. Hier kann man aber auch auf die Plasma Systemeinstellungen zurückgreifen um das ganze zu konfigurieren.

Eine Sache die mich bisher immer zu Plasma zurückgetrieben hat war die Akkulaufzeit die irgendwie deutlich kürzer war auf dem E22 Desktop im Vergleich zu Plasma.
Eine kurze Recherche hat mich zu dem Schluss gebracht dass fast 5 Watt konstant mehr Strom verbraucht worden ist, im Vergleich zu Plasma.

CPUFreq Modul für Strom sparen

Der Grund dafür war bei mir das nicht eingebundene Cpufreq Modul. Dieses kann man unter Module System einbinden und allen Notebooknutzern kann ich das nur wärmstens ans Herz legen, da es dann die CPU auch in den Schlaf schicken kann und ihr sogar wenn ich besonders stromsparend unterwegs sein möchte einen Takt vorgeben kann.

Damit man schnell zwischen Profilen wechseln kann oder auch einfach sehen kann in welchem Takt die CPU gerade arbeitet lohnt es sich auf eurem Desktop oder Panel dieses Modul auch sichtbar zu machen.

Insgesamt eine ziemlich einfache Sache, auf die man aber auch erstmal kommen muss.

Frohes Neues Jahr

Ich wünsche allen ein frohes neues und erfolgreiches Jahr 2019.