Erst mal ein Check von Software, wie Yuzu und auch Unreal 5.2.1, die immer 100% GPU nimmt, selbst im Low Profile. Man kann dann aber mit arbeiten.
Meta zeigte Benchmarks von Llama 2. Mit 13B Parametern, was lokal gerade noch so nutzbar ist, sind das super Werte und online fix testbar.. Das neue KoboldCPP checkte ich mal, weil sich llama.cpp zu durcheinander entwickelt. Falcon40b ging in Kobold nicht. Das sind ohnehin derzeit kaum nutzbare Modelle mit 0.9T/s. Noch lohnen sich die $20/Monat für GPT4. Zur Zeit eher weniger Interesse den lokalen Sachen zu folgen, weil eben gigantische Performance-Sprünge mangels GPU ausbleiben.
Per GPT4 bekam ich ein Python Script hin, was die Resolve API Doku fast problemlos in ein CSV umwandelt. Viele Edge cases wurden gut behandelt. Das CSV könnte als Start für Websocket Funktionen dienen. Wenn ich die Abfragen und Payloads direkt aus dem Browser an Resolve hinbekomme, brauche ich nur einen Hack, der Bool aus einigen Funktionen löscht. Als Interface wäre vuepress wohl gut aber ich denke, dass für die Workflow Sachen in Resolve Svelte wohl noch mehr Sinn macht. Irgendwann…
Als erstes aber musste Producer/Consumer Pattern in WS funktionieren. Stattdessen ließ ich erst das Bootstrap Design ändern, falls ich das routevideo mit eingebunden bekomme. oder vielleicht doch rchtig Google Maps? Das Wichtigste ist nun aber echt die Websocket, damit ich Marker per Clicks betexte. Die Verbesserungen im Code und Interface müssen dann kommen, wenn sich alles stabilisiert. Herumcoden ist nur viel interessanter, als arbeiten. An Tools kann man sich viel aufhalten – ohne sie zu nutzen.
Für GPT Hilfen muss ich auch die Wikipedia GET https://{country}.wikipedia.org/api/rest_v1/page/summary/{sight} Funktion nutzen. Mal sehen, ob ich das über Alpine auch hinbekome oder am besten ein Panda DF dedupliziert in ein CSV scrapen. GPT4 muss man auf die Sprünge helfen, wenn ich nicht alles „rich history“ und „vibrant atmosphere“ sein soll.
Joggen ging gerade noch so, Chili con carne zum Abendessen. Etwas gießen.
Ich setzte mich dann an die alten Websockets. Per GUI und einem Haufen async Code, den ich nicht verstehe, gab’s viele Crashes beim Shutdown. GPT wollte helfen, konnte aber am Ende doch nicht. Man müsste von ganz vorne anfangen, wozu ich keine Zeit und Prompts habe. Somit ließ ich es bei einer Version die weniger heftig crasht und nicht gleich die Shell mit nimmt. Ich kann nun also den Timecode an den Browser schicken und zurück auch ein JSON an DaVinci, was dann den Marker setzt. Das alles nur, um kopieren und einfügen über zwei Fenster zu vermeiden. Bei 30-80 Markern pro Video ist das eben eine Menge Klickerei, die mir hoffentlich erspart bleibt. Morgen muss ich das in die echte Website einbauen und dann werde ich sehen.
Die JSON Formate analog zu streamer.bot. FrameId muss int sein, sonst fail. Man könnte eben alle noch hübscher machen aber der Fokus liegt jetzt erst mal auf dem Nutzen für den Viewer und das sind die Subtitles, die ich einfacher generieren will. Tastenkürzel müssen auch noch her. Prompt Basteln muss dann auch automatisiert werden. Es ist viel Arbeit alleine aber es muss sich lohnen.
DaVinci Resolve zu Web App:
{
"requestType": "SetCurrentTimecode",
"requestData": {
"timecode": {timecode}
}
}
Web App zu DaVinci Resolve:
{
"requestType": "AddMarker",
"requestData": {
"frameId": {frameId},
"color": {color},
"name": {name},
"note": {note},
"duration": 1,
"customData": null
}
}
0 Responses to “Llama 2, Socket hin und her”