Die meisten Publisher dulden doch LPs und Monetarisierung mittlerweile...
Beiträge von Drexel
-
-
Also darf ich nie rot verwenden ohne an Coca Cola zu blechen? xD das gilt doch wohl nur auch mit dem Schriftzug zusammen oder?
-
Hey und herzlich willkommen!

-
Hab die Tage einen kleinen Bug entdeckt:
Wenn der Upload gedrosselt wird, wird der Drosselwert beim Uploadstart jeder weiteren Datei auf den Wert gesetzt, der beim Start des ersten Uploads gesetzt war....
-
Am besten in MKV aufzeichnen und von OBS automatisch in mp4 nach der Aufnahme umwandeln lassen. "Automatically remix to mp4" in den Advanced Einstellungen ist das.
Der Grund dafür: Wenn die Aufnahme aus irgendeinem Grund abbrechen sollte und du mit MP4 direkt aufzeichnest ist die Datei futsch, bei MKV passiert dir das nicht. Wird dann ja eh in MP4 umgewandelt.
Ich mach keinen Remix nach MP4 mehr, alle meine Programme und YouTube können mit mkv umgehen.
-
Den einfachsten Aufnahmemodus für Anfänger finde ich immer noch CQP, also Rate Control Mode CQP, Preset maximal Quality, Profile High und dann mit CQ Level rumspielen, alles unter 20 ist schon ganz gut, hatte mich glaub ich bei 14 eingefunden, weniger ist besser aber ergibt größere Dateien.
Tonspuren kannst Du auch mit OBS getrennt aufnehmen, Dein Mikro und Deine Stimme, AAC 320 kBit ist maximum, ist aber sehr nah an verlustfrei, da lohnt es eigentlich kaum sich den Stress mit ner externen Aufnahme zu machen.
Kenn mich mit dem AMD Encodern nicht aus, da ich ne NVIDIA Karte habe. Prinzipiell ist h264 älter, braucht weniger Rechenpower, erzeugt aber größere Dateien als h265. Aber aufgrund der weniger benötigten Rechenressourcen nehmen die meisten mit h264 auf, der finale Encode vorm Upload kann h265 günstiger sein, weil kleinere Dateien, aber dafür längerer Encode.
-
Also mehr als 1 MegaByte/Sek geht auf jeden Fall, ich lade so mit 3,5 im Schnitt. Mehr gibt meine Leitung nicht her.
-
Nein keine Begrenzung und kann bei mir auch nix derartiges feststellen... Was heißt langsamer konkret?
-
Ja das macht OBS natürlich, Du kannst auch einstellen mit welchem Codec und wie stark komprimiert werden soll unter File->Settings->Output und dann Recording oder Streaming je nachdem. Unkomprimierte Videos werden sehr groß, soll aber auch Leute geben, die die Rohaufnahme gerne unkomprimiert haben. =)
Generell sollte die Rohaufnahme zur Weiterverarbeitung eine möglichst gute Qualität haben. Wenn Du nicht weiter verarbeitest, kannst Du natürlich direkt auf die Zielqualität gehen.
-
Was verstehst Du unter rendern? Allein das ist ja schon ein Begriff, der wenig definiert ist, rendern, exportieren, encoden, irgendwie alles das gleiche. OBS nimmt erstmal nur ein Video aus mehreren Quellen auf, wenn Du mehrere Quellen hast übereinander oder nebeneinander, ganz wie Du es einstellst. Dann wird entweder direkt ins Netz gestreamt (Twitch) oder der Videostream/die Videodatei auf Deine Festplatte geschrieben.
Im OBS Log liest man bei Problemen immer mal von Rendering Lag oder Encoding Lag, Rendering ist nach meinem Verständnis das Preprocessing, das die Bilder der Quellen zusammensetzt, Effekte anwendet etc. und Encoding das komprimieren den Videostream nach h264 z.B. Ist Deine Hardware ausgelastet, kommt es auf jeden Fall zu diesen Lags und es wird zu diesen Problemen führen und einzelne Frames gedroppt werden.
Also nein Du willst das Renering von OBS nicht ausschalten, kann man auch nicht, weil Du sonst keinen Videostream erhalten würdest. =)
-
-
OBS zum Aufnehmen und Streamen ist schon der Standard würde ich sagen.
Zum Schneiden gibt es dann diverse von kostenfrei bist kostenpflichtig, Shotcut, DaVinci Resole, TMPGEnc VMW, Adobe Premiere um mal einige zu nennen.
Videobearbeitung ist ein weites und komplexes Feld, deswegen auch viele Meinunge und Empfehlungen mit "Gefährlichem" Halbwisssen. Und was dem einem an Qualität genügt, tut es evtl. beim anderen dann noch lange nicht.
Also nein, es gibt nicht den Standard und die All in One Lösung.
-
So ich hab mich ein wenig auf stackoverflow mit jemandem ausgetauscht und auch nochmal selbst ein wenig nachgedacht und analyisiert wie man die API Crdentials besser schützen kann. Idee war die Authentifizierung auf einem (Web-)Server vorzunehmen und die Authentifizierungsinformation für weitere Requests, also das refreshToken an die App weiter zu geben, erstmal per manuellem Copy&Paste, später evtl. auch automatisch.
In der Analyse habe ich aber festgestellt, dass das auch nicht so wirklich geht, zumindest ist der Aufwand deutlich höher, als in der ersten Idee gedacht.
Die API Credentials werden bei der initialen Authentifizierung genutzt, darüber erhält man das refreshToken. Mit dem refreshToken kann man accessTokens abrufen, die die eigentlichen Requests authentifizieren. Aber auch die Erzeugung der accessTokens benötigt die API Credentials, das hatte ich nicht mehr auf dem Schirm. Ich habs zwar hinbekommen, mir das refreshToken über ein PHP Skript auf einem Webserver zu erzeugen und in der App weiter zu nutzen. Aber um die API Credentials sicher nur auf dem Server zu halten, müsste die App halt auch jedes accessToken vom Server abfragen... Und die AccessTokens ändern sich jede Stunde. Das macht es dann doch deutlich komplizierter, man müsste sich auch das refreshToken oder den YouTube Account oder irgendwas um den Connect zur App hinzubekommen auf dem Server merken oder ein Account System nutzen, mit dem man sich auf der Webseite und in der App anmeldet und die Kommunikation sicher gestalten.... Das ist alles kacke und aufwendig...
-
Das wäre btw der ffmpeg Befehl:
ffmpeg.exe -i "PfadZurDatei.mkv" -map a:0 -c copy "PfadZurAusgabe1.m4a" -map a:1 -c copy "PfadZurAusgabe2.m4a"
-
Im Zweifel mit ffmpeg extrahieren, Befehl kann ich Dir später geben...
-
Oof, das ist blöd...
Mal ganz blöd gefragt: Kannst du absolut sicher sagen, dass jemand die Credentials misbraucht?Danke für Deine Hinweise Strohi, ich habe das gedanklich auch alles schon durchgespielt

Ja ich bin sicher, dass abuset wird, ich sehe in der Google Cloud Console folgende Requests in den letzten 24 Stunden:
VideoRatingService.Insert, also Bewertungen abgeben, ist definitiv nichts was mein Tool tut. Manchmal sind auch Subscriptions dabei.
Was, wenn irgendjemand das Tool nutzt, um wie gestört Videos hochzuladen? Kannst du das sicher ausschließen, z. B. indem du in die nächste Version ein Rate-Limiting von 20 Videos pro Tag pro Benutzer einbaust?
Das würde dann erklären, wieso die ganzen Verschleierungsmaßnahmen nicht helfen..Ja es könnte jemand wie gestört Videos hochladen, kenn da auch mind. einen Nutzer der das genutzt hat um ziemlich viele Shorts zu spammen. Ist zwar auch nicht doll, aber im Rahmen der Nutzungsmöglichkeiten, müsste ich akzeptieren. Habe schon probiert, das über die Google Cloud Conole zu limitieren, da kann man ein tolles Setting einstellen, Quota pro User pro Minute, das muss ich auf 1600 stellen, damit überhaupt ein Upload funktioniert, wären immer noch 1440 Uploads pro Tag pro user und noch mehr sonstige Requests... Quota pro Tag wäre einfach zu viel verlangt...
Ich könnte ein User Limit einbauen, dass irgendwo lokal gespeichert wird, im Zweifel löscht man das und es geht wieder von vorn los.
Andere Frage:
Könnte es sein, dass der Angreifer sich erst später als Man in the Middle einhängt und den Webtraffic deines Programms via Fiddler oder ähnlicher Tools abgreift und so an die Credentials kommt?
Weiß nicht, ob es geht, aber auch das könnte erklären, wieso er trotz allem leichtes Spiel hat.. Weil wenn er sich in die Requests reinhängt, hilft keinerlei Obfuscation im Code...
Klar, die Obfuscation war auch nur ein Test, wie schlau der Hijacker wirklich ist, ob er nur den ILSpy anwerfen kann oder ob er noch weitreichendere Kenntnisse hat. Hat er offensichtlich.
Wenn es letzteres ist, stellt sich mir die Frage, ob es überhaupt irgendwie möglich sein könnte, das Abfangen zu verhindern.
Eigentlich nur eine Serverlösung, bei der User ihre Videos hochladen und du die vom Server aus an Youtube schickst. Darüber könntest du Rate-Limiting einbinden, hättest dann aber ne Shitload an DSGVO und hohe Serverkosten an Bord...
Ja keine Alternative. =)
Aber ganz ehrlich: Was soll die Doppelauthentifizierung? Alle Requests sind OAuth Authentifiziert, sie wissen wer da was macht, sollen sie doch diese Accounts einfach sperren. Und die Quota Limiterung an den Account hängen. Da könnten sie doch einfach sagen, jeder Account darf max 20 Videos am Tag hochladen und gut ist.
Wenn ich ungehindert spammen will muss ich auch nicht über die API gehen sondern bau mir einen Robot/BrowserPlugin/whatever der über den Browser geht...
Man kann lokale Apps einfach nicht absichern, das weiss selbst Google, es steht ja in ihren FAQs. Was soll das dann überhaupt?
-
Die Spammer gehen mir echt auf den Sack. Scheint alles nix gebracht haben. Ich überlege, ob ich es komplett öffentlich nur ohne Api Zugang veröffentlichen soll und mit Api Zugang nur auf Anfrage/an bekannte Leute...
Oder Google einfach weiter mit Quota Requests nerven soll, bis sie mal ihr Api Zugangs System überdenken...
-
Gibt's Tapatalk noch? Die App hatte ich früher auf dem Handy genutzt, um Foren auch mobil anzusurfen. Aber ich kann das nachvollziehen, Push-Benachrichtigungen bei neuen Antworten zu einem Thema wären schon ganz praktisch.
Ja das fänd ich bei einigen Foren auch ganz nice, aber für jedes Forum eine eigene App no way. Und bei einer 3rd Party App für alle Foren hätte ich Sorgen, dass die zu viel vom nativen Funktionsumfang schluckt. Also surf ich sie lieber im Browser an.
-
Hm sich für jedes Forum eine App installieren? Ich find die mobile Ansicht vollkommen in Ordnung und gut benutzbar...
-
Willkommen!
