Ganz so einfach war’s dann doch nicht, die AV1 HDR Videos auf YouTube zu bekommen. Das Riga Video blieb SDR mit ganz flachen Farben. Ich löschte es schließlich und startete einen neuen normalen H.265 Encoding Job auf dem Dell.
Aus irgendeinem Grund schien heute DaVinci schneller. Ich bekam im normalen Teil ohne Overlays 13-14fps. Damit könnte ich leben. GPU Activity zeigte mal 90+%. Warum es vorher nicht ging? Dafür zog der Dell 100W mit allem – 35W CPU, 34W für die GPU und die restlichen 30W Für SSDs, Netzwerk und Netzteil Leistungsverlust bei 80% Adapter Effizienz wohl. Vor allem bleibt er relativ leise mit um 70°C für GPU/CPU. Heute war ich doch mit dem Teil zufrieden. Warum nur die Arc GPU vor Tagen so erratische Performance hatte?
Die HDR10 Embed und Metadaten klickt ich aus, was im Wesley Knapp Blog so gesagt wurde, in YouTube Tutorials einst anders. Eigentlich klappte es immer mit den HDR10 Embeds aber mal gucken. Ich will dann schon weiter AV1 testen, denn ich will die Bitrate zum Upload nicht verdoppeln, da 60Mbit+ für 4K60 vorgeschlagen werden. Das Riga Video sollte schnell zurück auf YouTube.
Das Dell Ding lief dann erst mal. Enttäuschend wieder, dass der Video Workflow weiterhin nicht komplett gelöst ist. Daran wollte ich also doch weiter arbeiten.
WSL2 bekam ein Update, was vielleicht den Bridge Modus in’s LAN meiner Docker löst. Mit dem ganzen Gefummel könnte man das eigentlich auch alles auf einer VPS lösen. Eine neue Docker Desktop Version kam auch noch auf den HP. Komischerweise klappte Copy/Paste per Keyboard Shortcut zwischen Local und Network Project DB in DaVinci Resolve. Somit geht’s am Ende vielleicht doch mit Netzwerk Database, wie das auch professioneller sein sollte – und einem Macro?
Einfach war das Bridging nicht. Bei vorigen Versuchen übersah ich einiges. Einer machte sogar einen virtuellen Switch.
Zuerst eine Firewall Rule:
New-NetFirewallHyperVRule -Name "DaVinciResolveProjectServer" -DisplayName "DaVinci Resolve Project Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 5432
Name : DaVinciResolveProjectServer
DisplayName : DaVinci Resolve Project Server
Direction : Inbound
VMCreatorId : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Protocol : TCP
LocalAddresses : Any
LocalPorts : 5432
RemoteAddresses : Any
RemotePorts : Any
Action : Allow
Enabled : True
EnforcementStatus : OK
PolicyStoreSourceType : Local
Profiles : Any
PortStatuses : {
SwitchName: 790E58B4-7939-4434-9358-89AE7DDBE87E
PortName: 583FB733-E47B-4FBF-A9F3-41F13C7567F1
Profile: Public
NetworkType: NAT
InterfaceGuid: {00000000-0000-0000-0000-000000000000}
PartitionGuid: {A5CE9333-4888-4ABB-82E6-F895D7E91C2E}
VMCreatorId: {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
EnforcementStatus: NATInboundRuleNotApplicable
}
Ich bekam dank Network Mirror lokal Zugriff auf den PostgreSQL Port:
Test-NetConnection 192.168.1.1 -Port 5432
ComputerName : 192.168.1.1
RemoteAddress : 192.168.1.1
RemotePort : 5432
InterfaceAlias : Ethernet
SourceAddress : 192.168.1.1
TcpTestSucceeded : True
Über den Dell allerdings ging’s erst nicht, womit ich dann nochmal den Port 5432 auf dem HP in der Firewall frei gab und es dann endlich funktionierte. Die Sache war damit scheinbar gelöst:
1. WSL im Network Mirror Modus und Docker Netz auf 192.168.0.1/24 damit ich WSL/Docker auf 192.168.1.1 sehe
2. HyperV Firewall Freigabe auf Port 5432
3. Windows Firewall Freigabe(n) auf Port 5432
Jetzt müsste man noch absichern, dass der Port in Public Netzen nicht frei wäre, doch LAN wird als Public angezeigt. Ich beließ es auf einer Beschränkung auf die 192.168.1.2 IP in der HP Firewall für den Dell. Docker mit dem Server in einem Public Netz wäre sonst für jeden verfügbar. Unwahrscheinlich, dass jemand im gleichen Subnet die Standard Resolve user/pass nutzt. So oft läuft der Docker Container ja nicht. Vielleicht kann ich doch noch die Firewall auf ein Netzwerk Interface beschränken. Wie hier beschrieben
Get-NetAdapter -IncludeHidden | Format-Table -AutoSize
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow. In der Windows Firewall konnte man das doch auf das LAN beschränken.
Nach diesem dritten Versuch, Resolve Projekte per Docker im LAN zur Verfügung zu stellen, der dieses Mal wohl erfolgreich endet, ging ich erst mal joggen.
Einige Feuerwerke heute in der Gegend. Auf dem Rückweg auf der Schafstreibe startete die Jugend auch eins.
Gyros zum späten Abendessen. Dann schaute ich mir einen alten Enterprise Film im ZDF nebenbei an. Ich glaube zu dem war ich damals sogar im Kino.
Eigentlich wollte ich Videos schneiden aber machte dann doch im Netzwerk weiter. Es gab ein gemountetes Laufwerk,w as aber in’s Nichts führte. Das konnte man nicht löschen und GPT kam auch nicht dahinter. Ein RSuche in der Registry brachte fast den PC zum Absturz. Alles wackelte, der Explorer startete ab und zu neu. Sehr komisch alles.
Da meine 3 PCs am Switch als „Unidentified Network“ keine option zum „Private“ schalten bekam und ich Public nicht für generell File Sharing und Discovery freimachen wollte, schlug GPT vor:
Get-NetConnectionProfile -InterfaceAlias "Ethernet" | Set-NetConnectionProfile -NetworkCategory Private
Und siehe da, endlich was mein LAN auf Private. Es gab keinen Button dafür!
Alle sonstigen Laufwerke mappte ich auf dem Dell – auch ohne Script. Das komische falsch gemappte Laufwerk verschwand dann.
MouseWithoutBorders hörte aber dann auch mal auf zu funktionieren. Das Programm ist wichtig für 2-3 PCs, denn man wird ja irre, ständig Mouse und Tastatur umzuschalten. Am Ende half nur, die Dir: „%localappdata%\Microsoft\PowerToys\MouseWithoutBorders“ zu löschen. Das Problem war ein offener Filehandler wohl: „Microsoft\PowerToys\MouseWithoutBorders\settings.json‘ because it is being used by another process.“ – gleich 10MB Log files… So kann man sich auch den Samstag Abend um die Ohren schlagen. Es ging viel gut heute aber am Ende auch wieder viel Zeit für Quatsch drauf.
Am Ende ging sogar nicht mal mehr der 192.168.1.1 als Verbindung. In den hosts sah ich, dass wohl per mirror das WLAN Subnet genommen wurde:
# Added by Docker Desktop
192.168.178.101 host.docker.internal
192.168.178.101 gateway.docker.internal
Ich will aber 192.168.1.1 des LANs! Ich hatte die mirror config mit einem Fehler (kein [wsl2] am Start) und sie wurde damit nicht geladen sondern die Docker Desktop Einstellungen genutzt. Da wurde das interne Docker Net von 192.168.1.0/24 wieder auf WLAN Subnet umgeleitet. Ein Docker restart brachte nichts, erst wsl –shutdown, um den mirror Modus rauszunehmen, brachte es wieder zum Laufen.
Das Dumme am Resolve Project container ist, dass nach jedem Neustart alte DBs noch drin sind. Der backup Dienst macht hier wohl ’ne eigene Wiederherstellung. Mannomann.
Am Ende ist’s wohl besser, gleich PostgreSQL lokal laufen zu lassen. Das ganze Docker hin und her geht mir schnell auf den Keks, wenn dann solche Netzwerk Bridging Probleme WSL2->Docker->Host->LAN die Zeit stehlen.
0 Responses to “HDR Humbug”