Beiträge von Drexel
-
-
Normaler Alltag eines Programmierers:
Jemand kommt mit neuer Anforderung, wie z.B. gedrosselter Upload.
Gedanke: Hm das könnte so und so gehen, ist wahrscheinlich nicht so viel Aufwand, mach ich mal.
Tag 1: Den ganzen Tag mit dem externen Client rumgehampelt und versucht ihm eine Drosselung unterzuschieben um dann festzustellen, dass es nicht den Ansprüchen genügend geht. Neuer Entschluss: Eigenen Client programmieren. Erstmal in die schlecht dokumentierte und relativ komplexe Api einlesen und einarbeiten.
Tag 2: Api implementieren. Kleinere Probleme mit der Authentifizierung aus dem Weg geräumt. Aber der Upload funktioniert nicht. Ewig lange Fehlersuche. Nix behebt den Fehler. Der auch laut Dokumentation so gar nicht passieren sollte. Statt hochzuladen, landen alle Daten erstmal im RAM, was bei Dateigrößen mit mehreren GB unvorteilhaft ist. Verzweiflung macht sich breit, strohi wird konsultiert. Nix hilft. Letzter Gedanke, das Verhalten ist als .NET Core App anders als mit dem vollen .NET Framework. Testweise die App mal aufs .NET Framework umstellen, was auch nicht mal eben gemacht ist. Und siehe da auf einmal funktioniert es ohne eine Code Änderunge...
Also tschüss Core App...
-
Wie Ihr immer wieder versucht einen neuen Strohhalm zu finden. Irgendwann wird's weg sein, gewöhnt Euch an den Gedanken... Und ans neue Studio.
-
Also ich bin auch kurz davor mir den Upload Client selbst zu implementieren. Hab mir die Authentifizierung gerade mal angeschaut, alles reichlich kompliziert... Danke Foxhunter für die Anforderung der Drosselung.
Alles anzeigenAn dem Fehler bin ich seit Monaten dran, aber es ist schwer, ihn zu beheben, weil er absolut sporadisch auftritt.
Soweit ich das bisher verfolgen konnte, liegt es darin, dass das Token abläuft.
Also wenn du dich anmeldest, dann machst du das ja auf Googles offizieller Seite und gibst dort dein Passwort ein, sodass der Uploader das gar nicht mitschneiden könnte.
Der Uploader bekommt dann "nur" zwei Tokens: Eins, mit dem er sich bei Youtube anmelden kann, das gilt dann jeweils eine Stunde. Und dann gibts noch eins, mit dem er die zum Anmelden erhalten kann. Das gilt auf seeeeeeehr lange Zeit (Monate bis Jahre), aber man kann sich eben damit nicht direkt anmelden, sondern muss sich damit die anderen Tokens generieren.
Mein Programm ist so geschrieben, dass es automatisch schaut, wann die erstgenannten Tokens ablaufen und sich rechtzeitig ein neues generiert, aber manchmal scheint das nicht zu funktionieren. Ich weiß aber noch nicht so ganz, was da das Problem ist.
Dann erhälst du den 401er, der dir eben sagt, dass sich der Uploader Youtube gegenüber nicht authentisieren konnte.
Beim Neustart holt sich der Uploader immer ein neues Token, das dann wieder eine Stunde gilt, daher funktioniert das ab dann wieder.
Ich beobachte das immer wieder mal, aber bisher konnte ich das nicht beheben.
Hab mir gerade auch die ganze Authentifizierungs und Upload Api genauer angeschaut, weil ich auch überlege einen eigenen Client zu bauen, um die Drosselung besser hin zu bekommen (danke dafür Foxhunter :P). Gut zu wissen, dass es solche Probleme gibt. Ich glaub ich hätte mir aber eh für jeden Request ein neues Access Token besorgt um der Ablauf Problematik aus dem Weg zu gehen.
Spricht da aus Deiner Erfahrung was dagegen? -
Hab da mittlerweile doch noch einiges rumgeschraubt, auch wenn der schon gut war, fand ich es blöd, dass er immer ein Interval definiert in dem er den Read Speed monitort und nach dem interval alles wieder auf 0 resettet. Ich hab mittlerweile ne Version, die sich einfach nahtlos die letzten X Millisekunden anschaut. Dennoch hab ich einiges an komischen Verhalten, ich hab das Gefühl der Youtueb Client buffert intern auch nochmal, er liest erst mehrere Megabyte oder wieviel auch immer in 4KB Blöcken aus dem Stream und dann lädt er hoch, das bringt das Messen beim lesen ganz schön aus dem Tritt. Weil er kurz ganz schnell und viel liest und dann nix mehr. Deswegen mag ich solche indirekt Lösungen nicht, besser wäre es direkt im Netzwerk Client. Das sollte bei Dir natürlich wesentlich besser gehen, mit dem selbst geschriebenen Client... Kann Dir meinen angepassten Code zuschicken, wenn Du magst.
-
Falls Du mal einen streambasierten Throttle einbauen willst, ich habe jetzt den hier als Ausgangslage genommen und ganz leicht angepasst:
https://gist.github.com/passy/637319
Der ist sehr genau, weil er nicht nur das aktuelle Interval betrachtet, sondern auch eine History. Damit komm ich ziemlich nah ans eingestellte Uploadlimit, andere gethrottlete Streams die ich genutzt habe, z.b. aus dem ersten Stackoverflow Thread von google nehmen es da nicht so genau, da liegt man dann gerne mal 20% unter der Bandbreite....
-
-
-
OK und sollte ich ihn jemals wieder einblenden sind auch alle seine Posts wieder da?
-
Sagt mal was macht die Funktion "Nutzer auf Kanal ausblenden" genau? Blendet die den Nutzer für alle aus oder nur für mich? Kann er dann noch posten und man sieht es nur nicht?
Hab so nen nervigen Spammer bei mir, Todd, den dürfte wahrscheinlich auch noch der ein oder andere hier kennen, hab ihn auch auf vielen anderen Kanälen schon gesehen...
-
Ich muss sagen es sieht auch besser aus erwartet, also soweit gute Arbeit für ein Erstlingswerk. Ich hoffe aber nicht Du glaubst nicht wie der letzte (wer war es nochmal?) direkt Deinen Lebensunterhalt damit bestreiten zu können.
Hab aber auch kein Apple und zocke keine Handygames...
-
Danke auf jeden Fall fürs positive Feedback.
Hab gestern Days Gone beendet, in den nächsten Tagen werde ich denke ich anfangen an einer neuen Version zu basteln, die Drosselung ist dann defintitiv dabei. Darfst Du dann testen. Schätze irgendwann im Laufe der nächsten Woche wird das dann soweit sein.Ich glaube, dass der Zähler bei 0 anfängt steht im Tooltip und ist ja auch in der Informatik so üblich.
Aber vor dem Upload sieht man ja auch den Titel nochmal im Eingabefeld. Bzw im blauen Balken oben über dem Upload steht der Titel wie er definitiv auf YT ankommt. -
Alles anzeigen
Weil du VP9 erwähnst, hier gibts ja ein Thema wo es heißt, wenn man upscaling macht, dass man dann VP9 bekommt, ist das noch aktuell?
Aber auf OBS kann is ja nicht auf 3200x1800 upscalen, wenn mein Bildschirm nur 1920x1080 wiedergeben kann und in Vegas geht das schon oder? Nur dass das halt dann utopische Größen werden...
Naja wieviel ich dann bearbeiten muss, das weiß ich noch nicht, da ich mich bisher immer noch nur um die Videoqualität kümmere, erst wenn das stimmt, kommt die Soundqualität usw.
Aufnahmesettings von OBS kommen:
Ich hoffe, damit könnt ihr was anfangen.
Danke...
Die Setting sehen gut aus. Hab mit Qualitätsregulierung verlustfrei noch nie gearbeitet, wie groß werden die Dateien da? =) Benutze CQP mit CQ Level 14.
-
Die Aufnahmesettings in OBS wären auch interessant zu wissen, wenn das Quellmaterial schon bescheiden ist, wird VP9 und höhere Bitrate auch nix mehr retten.
Wenn Du am Video in Vegas nichts veränderst musst Du nicht rendern. Das Upscalen kann auch OBS übernehmen...
-
Alles anzeigen
Ich halte das sogar für eine ganz passable Lösung, da du so über den überschriebenen Stream an die aktuelle Geschwindigkeit rankommen und sie auch setzen könntest.
Gibt ja auch schon vorgefertigte Beispiele bei Deutschlands bestem Programmierer #1.
Wie gut die Lösung für dich passt, musst du halt mal schauen. Ansonsten ist das ja auch kein Hexenwerk, wenn dus doch selber machen musst.
Nö, aktuell noch nicht.
Da ich aber nicht den vorgefertigten Client nutze, sondern mir einen eigenen geschrieben habe, könnte ich das thoeretisch jederzeit direkt in die entsprechenden Methoden reinbasteln und den WebRequest direkt drosseln.
Wenn du willst, kannst du dir den Quellcode gerne anschauen. Müsstest dann halt schauen, ob du das an deine Bedürfnisse anpassen könntest. Der Code zum Upload ist hauptsächlich im YoutubeVideoUploader und im FileUploader gesetzt. Ich bin mit der Architektur dieser Teilbibliothek allerdings noch nicht ganz zufrieden - nur weiß ich aktuell noch nicht, wie ich das schöner designen könnte.
Äh, und auch wichtig: Du musst in den Branch "Standarduploader" wechseln - der ist 107 commits weiter, als der Master!
Achso Dein Uploader ist auch Open Source nice, das wusste ich noch gar nicht.
Deutschlands besten Programmierer mag ich auch, ich sag auch immer eigentlich kann ich gar nicht programmieren, ich kann nur googlen und Code Teile zusammensetzen.
Ne ist nicht schwierig, den Stream selbst zu implementieren, aber ich finde die Lösung nicht elegant, dass Lesen zu drosseln um die Netzwerkgeschwindigkeit zu drosseln...
Und ich bleib lieber bei dem API Client den Youtube bereitstellt, das ist eine Sache weniger, die ich selbst pflegen muss.
Wobei ich den Client auch bescheiden umgesetzt finde, der hat mich auch schon richtig aufgeregt... Wieso geben sie z.B. die Video ID des Uploads nur in einem Event zurück und nicht als Rückgabewert der Upload Funktion? -
Ich weiß nicht warum, aber das Problem hat sich erledigt. Habe alles so gemacht wie gestern, und jetzt funktioniert es. Vielleicht war das gestern ein kleiner Schluckauf, aktuell hat sich das Problem also erledigt
Danke auf jeden Fall schonmal fürs Feedback. Die Funktion hatte jetzt schon zum zweiten Mal einen kurzen Schluckauf, das wundert mich schon ein wenig, zumal da auch echt keine Magie passiert..
-
Hab mal geschaut bezüglich der Drosselung, der C# YouTube Client oder die API bieten da nix direkt an. Dem YouTube Client wird ein Stream des Videos übergeben, ich könnte nen eigenen Stream implementieren der gedrosselt liest, das wär aber mal wieder sowas von von Hinten durchs Knie durchs Auge, sowas geht mir ja immer dezent auf den Keks...
strohi hast Du eine Drosselung des Uploads bei Dir implementiert und das evtl. eleganter gelöst? Mal so von Entwickler zu Entwickler gefragt...
-
Klar, es gilt immer noch den Use Case zu beachten und sämtliche Hersteller Garantien entbinden Dich natürlich nicht von der Backup Pflicht. Garantie heißt ja nur, dass sie das Gerät austauschen, nicht, dass sie für den Datenverlust aufkommen.
Wollte damit auch nur sagen, dass ich mir keine Gedanken mehr mache, wieviel ich auf meine SSD schreibe, anfangs tat ich das noch...
-
Naja der Wert ist aber auch eher theoretischer Natur. Ich hab noch keine SSD gesehen, die wegen Zellverschleiß gestorben ist, eher wegen anderer Elektronik Fehler.
Hab gerade Mal geschaut, Samsung gibt für meine 1TB EVO eine TBW von 2400TB an, d.h. sie garantieren schonmal, dass man die Platte 2400 Mal komplett voll schreiben kann. Und danach geht's wahrscheinlich noch sehr lange weiter, kann mich noch an einen Heise Langezeittest erinnern, da ist glaub ich keine SSD direkt nach der garantierten Schreibrate ausgefallen.
Aber selbst wenn ich sie 2400 Mal komplett vollschreibe hieße das 6,5 Jahre Haltbarkeit, wenn ich das einmal pro Tag mache. Wenn ich im Schnitt ein Video Pro Tag veröffentlich mit 20GB und evtl. nochmal 20GB an Rohdaten haben, also sagen wir mal grob 50GB pro Video, dann wären wir bei 130 Jahren. Also ich denke nicht, dass ich meine SSD in 130 Jahren noch benutzen werde. =)
-
Huhu und herzlich willkommen. Die großen Legosets z.B. von Star Wars find ich auch cool, ich hab einen noch relativ überschaubaren R2D2 hier.
Ich glaubw as Doom etc. angeht ist De-M-oN Dein Freund.
