Beiträge von Drexel

Mal wieder ein Update, leider ohne fellpower s Feddback.

Die ersten beiden Punkte helfen mir vor allem bessere Übersicht beim Handling von mehreren Projekten zu halten.

• Gibt jetzt ein Setting, dass der letzte Upload pro Template bim löschen behalten wird.
• Ebenso kann man im Kebap Menü eines Templates jetzt eine Liste der erfolgreichen Uploads einsehen.
• Die Farbe des Warnicons wird jetzt nur gelb, wenn der Upload erfolgreich beendet wurde, aber zwischendurch was passiert ist.
• Network Package Size ist jetzt einstellbar. Je kleiner, desto besser throttlebar, je größer, desto weniger CPU Last und Overhead, weil die Loops verringert werden. Default Wert ist 32, kleiner gehts auch nicht. Bei gutem Upload Speed kann man auch mal höher gehen. Bin bei 64, .Net Default ist 128.
• Generell den Throttling Code etwas überarbeitet.

https://1drv.ms/u/s!AlNGd4g1Vh9rmHAvaCyZ5nvtOkDF?e=5vhucP

Moin!

Ich habe mich seit ich einen neuen Rechner mit Intel Core i7 13700 habe gefragt, warum meine Renderperformance so schwankt und habe glaube ich gerade rausgefunden warum und wollte es mal mit allen teilen. Evtl. hilft es ja wem oder ich bin der einzige Depp dem es nicht so klar war.

Intel nutzt auf seinen aktuellen CPUs Performance Cores und Efficiency Cores (P-Cores und E-Cores), die E-Cores sind da um Energie zu sparen, wenn keine Leistung benötigt wird (oder auch um Hintergrund Tasks abzuarbeiten wie ich jetzt weiß), diese haben nicht so hohe Taktraten und Rechenperformance und brauchen deswegen nicht so viel Strom, wenn der PC im Office Betrieb z.B. zu 99% rumidlet. Alles was Performance braucht sollte eigentlich auf den stärkeren, aber auch energiehungrigeren P-Cores laufen.

Und meine Performance schwankt so, weil sobald man Apps minimiert, werden sie auf die E-Cores geschoben, holt man sie wieder in den Vordergrund, werden sie wieder auf die P-Cores geschoben. Und je nachdem ob beim Rendern über Nacht das das Batch Encode Tool zum Rendern oder mein Uploader im Vordergrund war, war die Renderperformance mal schneller, mal langsamer.

Ich habe das mal manuell ausprobiert jetzt und man sieht es im Taskmanager:

Erst war das Batch Encode Tool minimiert, dann war die Last auf den letzten 8 Cores, das sind die E-Cores. Da wo die roten Pfeile sind, hole ich das Encode Tool in den Vordergrund als aktive Anwendung und die Last geht auf die P-Cores.

Hier sind Artikel und Videos die das auch zeigen/bestätigen:

https://www.xmg.gg/en/news-tip…tricks-rendering-e-cores/

Ist im Prinzip ein gewolltes Verhalten, aber evtl. gibt es in Windows 11 Updates, womit man das genauer steuern kann.

Wenn man eine App als Administrator ausführt, scheint sie auf den P-Cores zu bleiben, das hat zumindest ein kurzer Test gerade bestätigt, muss das mal über Nacht weiter beobachten. Bei mir bedeutet das Verschieben auf die E-Cores eine Verdopplung der Renderzeit...

Zitat von fellpower

Alles jut. Nimm dir die Zeit, die du brauchst

Puh hat doch etwas länger gedauert als gedacht. Ich habe Dir eine Testversion gebaut: https://onedrive.live.com/?authkey=%21AC9oLJnme%2D06QMU&id=6B1F563588774653%213526&cid=6B1F563588774653

Einfach entzippen und die exe starten.

Einerseits hab ich das RAM Caching des Uploads deaktiviert, falls das eine Bottleneck ist, Vidup lädt sonst immer 50MB Blöcke des Uploads in den RAM um nicht die ganze Zeit auf der Platte mit Minimalzugriffen rumzulesen. Kannst einfach erstmal einen Upload starten und schauen, ob das einen Unterschied macht, ich denke aber nicht. Der RAM Verbrauch sollte dadurch nur deutlich sinken.

Und man kann jetzt die Network Package Size unter Settings einstellen, die stand bisher fix auf 32768 Bytes (32KBytes). Die kannst Du mal verdoppeln oder vervierfachen und schauen ob das einen Unterschied macht. Der HttpClient von .NET unterstützt btw nur fixe Paketgrößen irgendwelcher 2er Potenzen, das kann ich aber erst am Ende des Uploads feststellen, dann wird die Network Package Size auch in den Settings auf die wirklich genutzte Paketgröße gestellt. Sprich, wenn Du 50000 eingibst, fordert der Client autom. 65536 Bytes an, nach Ende des Uploads steht der Wert auch in den Settings. Nach Änderung des Werts VidUp neustarten.

2 Hinweise noch: Das Abschließen des Uploads kann in der Testversion mal zu Fehlern führen, das habe ich noch nicht zu Ende betrachtet, da gabs auf jeden Fall ohne das RAM Caching 1-2 Probleme. Und das Throttling kann je nach Package Size problematisch werden, am besten mit dieser Version nicht nutzen.

Endlich hab ichs verstanden. Vielen Dank Dir und viel Erfolg!

Das Klauen war primär auf Deine ersten beiden Videos bezogen. Aber indem man jemand anderen kopiert, kommt man nicht weit, das Original wird immer mehr Views haben als die Kopie weil er schon die Leute hat, die sich für Typen wie ihn interessieren.

Aber auch Dein Banner willst Du wie er haben anstatt Dir was eigenes auszudenken. Ja wow Du willst mehr Pokemons drauf, aber vom Style wie seiner. Ultra kreativ, mega Eigenleistung.

Gleiche Diskussionen wie beim letzten Mal, Du hast nichts gelernt.

Du hörst auch nie auf zu klauen oder? Wie Deine ersten Videos exakt den gleichen Titel und Thumbnail wie die von OGDNZ haben.

Und Deine Anforderungen soll jemand für lau umsetzen, richtig? Da steckt locker Arbeit im Wert von ein paar Hundert drin, das wird Dir hoffentlich niemand machen.

Interessant wäre evtl was die Windows Ereignisanzeige unter Applikation und System evtl zum Absturz sagt.

Ja auf Quellcode Ansicht schalten, Quellcode kopieren und in Quellcode Ansicht wieder einfügen.

Immerhin kann ich mit 1,5k Abos Geld verdienen im Gegensatz zu Dir mit 5k. 😇

Ne hab ich schon von gelesen, aber noch nie aufgefallen. Zugegebenermaßen schaue ich in alte Playlists auch nicht so oft rein...

Wenn Du das jetzt bei jeder Ungereimtheit mit irgendwelchen Stats machst hast Du viel zu tun. Ich glaube auch ehrlich gesagt nicht, dass Deine Mail da viel zu getan hat, es dauert halt eine Weile bis die Werte final sind.

In Liebe direkt, Du gehst steil. Willkommen!

Hab das vor allem bei Shorts beobachtet. Kann viele Ursachen haben. Man weiss ja nicht wie die Systeme von YT laufen, es gibt auch in den Analytics immer eine leichte Diskrepanz zwischen Live Werten und finalen Werten. Evtl. werten sie erstmal nur Zugänge und keine Abgänge für Livedaten aus oder persistieren sie nicht und nehmen Ungenauigkeiten bei der Live Zusammenrechnung in Kauf (rechnen nur die Likes eines Cluster hoch oder was auch immer). Oder es sind nachträglich gebannte Accounts die Likes gespamt haben oder was auch immer. YT wird schon wissen, was sie da machen (oder auch nicht ;)), Einfluss hast Du ja eh keinen drauf.

* Seit Ende August 2018.

Keine große Überraschung dabei, es dümpelt so vor sich hin.

Zitat von dIsSidIuS

Das wird nicht gut aussehen dieses Jahr.. Aber immerhin habe ich jetzt endlich mein Abi! 2023 wird alles anders! Jaja!

Gz zum Abi

CRF an sich ist auch x26x Feature, es ist ein Encoder Feature. Gibt schon ein Parameter Set in NVENC was man als CRF bezeichnen kann, im VBR Mode: OBS NVENC 4k Aufnahme mit ffmpeg in h.265/HEVC und h.264/AVC

Wo willst Du sie denn kleiner haben? Die werden doch an 1000 Stellen angezeigt. Glaub bei YT hast Du wenig Einfluss, höchstens beim Einbetten.

Nach meinem Verständnis nein, wenn Du ein Oberlimit brauchst musst Du mit variabler Bitrate arbeiten.

Ja diese Schwankungen hab ich auch, denke das kommt durch das Framework, dass die Daten parallel zum Upload in den RAM nach lädt. Irgendwann werden die Daten wieder aus dem RAM geschmissen, denke das Aufräumen verursacht dann auch ein wenig CPU lässt. Aber die Stelle könnte auch noch ein Bottleneck sein fällt mir gerade ein. Oder die YT Api gibt einfach nicht mehr Upload Speed her...

Ich bekomm jetzt eine Restdauer für den 4K Encode angezeigt. Ob der stimmt?