Angepinnt Der Let's Play Guide

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • das ist mal ein sehr umfangreicher Thread. Kleine Anmerkung

      sam schrieb:


      YouTube macht die Qualität der Videos von der Auflösung und der FPS abhängig. Dennoch sollte nicht mehr als 1800p@60FPS hochgeladen werden, da der Effekt sonst verpufft.

      Du meinst wahrscheinlich 1080p ;)
      Vielleicht kannst du mittlerweile (der guide ist von 2015) auf 4K und was youtube so kann eingehen und wie sinnvoll oder eher unsinnig es ist in 4K aufzunehmen und vor allem diese daten hochzuladen und wer sich das überhaupt anschaut und wie es in 10 Jahren aussieht usw
    • Anzeige

      FVG schrieb:

      Ich finde übrigens im ganzen netz nichts über die Bildbreite bei 1800p, wird aber rein rechnerisch bei 16:9 bei ~3200 bildpunkten liegen, also keine kompletten 4K...
      Ja gut, kennt halt nich jeder die Tricks wie man aus Youtube mehr Bildqualität quetscht.
      1920x1080 sollte man auf youtube grundsätzlich meiden, kommt nur Pampe bei rum. Zwar nicht so krass wie bei vidme ( :D ) aber dennoch Pampe.
      2048x1152 würde youtube dir bereits 3-fache Bitrate geben, da die 1152 Pixel reichen um das 1440p Encoding Preset von denen auszulösen.
      Und bei 3200x1800 bekommst du eben die 4k Bitrate.
      @sem

      sam schrieb:

      Es wird vermutet, dass durch die Google+ Integration bald das Daumensystem durch das +1 System ersetzt wird.
      Glaub das kannste streichen. Zumal g+ mittlerweile eh wieder von youtube getrennt ist.





      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von De-M-oN ()

    • Ahoi,

      Seit einer Weile stellt YouTube für kleinere Kanäle (Grenze unbekannt) nur noch 360p und 720p zur Verfügung, auch wenn man selbst (und teilweise andere) noch die anderen Stufen sehen. Damit diese für alle verfügbar werden, muss das Video im YouTube-Editor neu gespeichert werden (eine Änderung am Video ist nicht notwendig). Anleitung mit Bildern: Besseren Codec (VP9) von YouTube erhalten

      Der Part mit 360p & 720p stimmt nicht (mehr?). Mein Kanal ist sehr klein und neu, ich kann aber ohne Probleme 1080P erzielen - auch für die Anzeige bei meinen "Fans" ... ;)

      VP9 vs. AVC ist nach wie vor der Fall, aber der Trick über das "Video Verbessern" von YouTube funktioniert nicht mehr - es bleibt bei AVC.


      Salute
      Larcath
      Schaut doch mal in meinem Lets Play - YouTube Channel vorbei!

      Aktuelle Projekte
      - VAMPYR
    • Der Guide erscheint mir erheblich verbesserungswürdig. Es handelt sich eher um eine unstrukturierte Ansammlung von Tipps als um einen Guide. Wenn er mir nicht mehrfach von Julian empfohlen worden wäre hätte ich nach dem ersten Absatz sofort mit dem Lesen aufgehört.

      Bei einem an gepinnten Post wie diesem sollte wenigstens alle 3 Monate, ganz oben und ganz deutlich erkennbar gemacht werden dass alles noch/wieder aktualisiert ist.

      Dem Guide fehlt es an Struktur. Ein Guide (Führer) soll jemanden führen, das heißt vom Anfang bis zum Ende. Hier wurde thematisch leider ständig hin und her gesprungen und viele zum Verständnis notwendige Informationen fehlen.

      Nach der Erläuterung dazu was ein Lets Play ist vermisse ich eine allgemeine Benennung der Hard- und Software (allgemein, nicht spezielle Produkte) die Voraussetzung für ein Lets Play sind sowie optionale Hard- und Software.

      Z.B.:
      Allgemeine Voraussetzung Hardware:
      Leistungsstarker PC

      Optionale Voraussetzung Hardware:
      Gaming-Konsole
      Capture Card
      Webcam
      Mikrofon

      Allgemeine Voraussetzung Software:
      Videobearbeitungsprogramm
      ...
      usw.


      Kein sorgfältiges Arbeiten: bei "Rechtliches" findet man in der linken und rechten Spalte jeweils den selben Text, der eigentlich nur in die rechte Spalte gehört.


      Der Teil Aufnahme:
      Er beginnt mit einer Erläuterung zu Codecs. Das ist äußerst irritierend denn wie man in dem selben Abschnitt erfährt erfolgt die Codierung idealer Weise nach der Aufnahme: "Dieser Prozess soll aber erst nach der Aufnahme beim Encodieren+Rendern geschehen".
      Es macht überhaupt keinen Sinn das Thema Codieren zu Beginn des Punktes Aufnahme im Guide zu behandeln sondern erst anschließend.
      Der Guide ist sehr chaotisch und unvollständig und daher eigentlich für Anfänger völlig unbrauchbar.

      Die Aufnahmeprogramme werden aufgelistet ohne dass sie als Aufnahmeprogramme bezeichnet werden. Der Leser muss also raten oder sich mühsam mit Google bemühen um herauszufinden worum es eigentlich geht.


      Angefangen wird im Guide schließlich mit dem Punkt Youtube wo man eine Browsererweiterung empfohlen bekommt, die den Bildschirmhintergrund von schwarz auf weiß ändern kann. - Das ist wirklich das allerletzte was mich interessiert wenn ich lernen möchte wie man Lets Plays macht.

      YouPloader wird empfohlen. Aber ist es nicht so dass YouTube selber eine Funktion anbietet Videos hoch zu laden? Wenn ja sollte das mindestens erwähnt werden.

      Erläuterungen der Begriffe (z.B. Rendern) fehlen.

      Auf Kritikpunkte von Samaras wurde weder eingegangen noch wurden sie ausgebessert.

      Ganz ehrlich: es gibt noch eine riesige Menge an Kritikpuktendie ich aber nicht alle beschreiben will weil es einfach zu aufwendig ist.

      Bis jetzt verstehe ich nicht wie Codecs, Encodierung, Rendering und Aufnahmeprogramme zusammenhängen.
      Muss ich wenn ich ein Aufnahmeprogramm habe (Pinnacle oder Adobe Premiere) noch eine Codec-Software z.B. MagicYUV dazu kaufen und einen Encoder z.B. 264x?

      Um alle diese Schwachpunkte zu beseitigen würde ich den Autor Sem bitten sich in die Rolle eines Anfängers zu versetzen und aus dieser Perspektive heraus den Guide komplett neu aufzusetzen und ganz systematisch vorzugehen. Ein Guide für Lets Plays muss den Anfänger von Anfang bis Ende systematisch durch das Thema führen.
    • @banda
      Das Problem ist das solche Sachen eigentlich so gut wie Wöchentlich jedes mal aktuell gehalten werden müssten. Und dafür ist ein Forum recht ungeeignet, wenn der entsprechende Threadverlauf oder der Threadersteller sein Startpost nicht aktuell hält.

      banda schrieb:

      Er beginnt mit einer Erläuterung zu Codecs. Das ist äußerst irritierend denn wie man in dem selben Abschnitt erfährt erfolgt die Codierung idealer Weise nach der Aufnahme: "Dieser Prozess soll aber erst nach der Aufnahme beim Encodieren+Rendern geschehen".
      Es macht überhaupt keinen Sinn das Thema Codieren zu Beginn des Punktes Aufnahme im Guide zu behandeln sondern erst anschließend.
      Der Guide ist sehr chaotisch und unvollständig und daher eigentlich für Anfänger völlig unbrauchbar.
      Der Teil ist einfach zu verstehen.

      Ein Codec ist z.B. XVID, H264, DIVX, BMP, PNG, PCM, usw.

      Codecs lassen sich aufteilen in De- und Encoder. Also Entschlüsseln und Verschlüsseln. Damit wird die gespeicherte Dateninformation gemeint.

      Ein Encoder wird zum Verschlüsseln genommen.
      Ein Decoder zum Entschlüsseln der Informationen in ein RAW Format.

      Codecs können auch komprimieren. Eine Kompression dient im Endeffekt nicht nur zum verkleinern einer Datei, sondern hat als Nebeneffekt auch eine Verschlüsslung zur Folge.
      Als Verständliches Beispiel für sowas kann man sich auf Wikipedia über Lauflängenkodierung auseinandersetzen (RLE Kompression), was man bei Bildformaten wie Bitmap finden kann.
      RLE ist aber nur eine Form solch einer Kompression. Da gibt es noch dutzend andere Sachen. ^^

      Encoder gibt es auch als einzelne Anwendung. z.B. x264
      x264 ist ein erweiterter H264 Encoder der mitunter auch eine Constant Rate Factor Encodierung zulässt. Was überaus Qualitätsfördernd ist. Gerade bei Spieleviedeos sehr zu empfehlen.

      Als Dateicontainer dienen dann z.B. AVI, MP4, MKV, WAV, MP3, BMP, PNG, usw.

      Der Dateicontainer kann, muss aber nicht unbedingt die gleiche Dateiendung haben die der Codec auch nutzt. Da sollte man vorsichtig sein. Eine Dateiendung muss nicht unbedingt auf den verwendeten Codec hindeuten den die Datei beinhaltet.

      Der Dateicontainer dient zur Verkapselung der Dateninformationen. Simple aufgeteilt in Header und Daten.
      Im Header stehen dann alle Informationen zu den gespeicherten Daten drin. z.B. Auflösung, ob es komprimiert ist, welche Farbtiefe, und und und. Meist ist der Header nur wenige KiloByte klein. Danach erfolgt der Datenstrom. z.B. bei einem simplen 24Bit Bitmap Bild erfolgt die Speicherungssequenz so das jeder Pixel beschrieben wird. 3Byte beschreiben dann einen Pixel. 3Byte für je 1Byte Rot, 1Byte Grün und 1Byte Blau. Und die sind dann hintereinander gekettet, weshalb man von einen Datenfluss redet.

      Hat man ein 8Bit Bild, würde im Header eine Palette angegeben werden mit min 3 * 256 Byte. Der Datenstrom erfolgt dann mit 1Byte pro Pixel.
      Der 1 Byte wird dann als Index für die Farbtabelle genutzt, der dann halt aus 3 Byte besteht.


      Bei einem Bitmap Bild würde der Encoder z.B. daraus bestehen:
      RLE Kompression oder nicht?
      Farbinformationsreihenfolge. Das heißt wie ist die Anordnung der Farbinformationen. RGB, GBR, BGR?
      Welche Farbtiefe ist vorhanden? Danach richtet sich dann auch die Vorgehensweise der Decompression bei der Decodierung.
      ...

      Das sind nur ein paar verständliche Sachen die beachtet werden müssen. Da gehört aber bei komplexeren Codecs ne ganze Kante mehr dazu.
      Die Decodierung ist dann dafür zuständig von den gespeicherten Informationen das Klarbild wieder zu bekommen. Sozusagen das umgekehrte Verfahren zur Encodierung.


      Das was in Programmen als 'Rendern' bezeichnet wird ist nicht da das gleiche wie das eben beschriebene. Als Rendern wird das Neuberechnen eines Bildes bezeichnet bevor es zur Encodierung kommt.

      z.B. Ein Video Schnitt Programm wie das von Adobe berechnet die Bilder neu. Darunter zählt auch die Bildsynthese. Sprich das hinzufügen von Effekten oder manipulieren von Auflösung, FPS, usw. Danach muss jeder Frame (Bild) neu berechnet werden, bevor es mit einem Codec in ein Dateicontainer encodiert werden kann.

      Dieser Prozess wird wie gesagt.als 'Rendern' bezeichnet.

      Ist etwas Fail von Schnittsoftware Entwickler den Punkt als 'Rendern' zu bezeichnen, wenn einem nach dem Klick auf diese Schaltfläche man zu den Encoder Einstellungen gelangt wie das Video encodiert werden soll.

      Deswegen hat sich das bei vielen Leuten komplett falsch eingebürgert das 'Rendern'.


      Beim Aufnehmen stellst du auch den Encoder ein und stellst vllt. auch den Dateicontainer ein.
      Danach erfolgt das Abgreifen des Bildes. Je nach Aufnahmesoftware durch Hooking in bestimmte Abschnitte der Anwendung. z.B. DirectX oder OpenGL, etc. pp. oder halt das rohe Bild.
      Diese rohe Abgreifung des Bildes wird dann encodiert und in eine Datei gespeichert.

      Somit hast du die Aufnahmedatei.

      Im Schnittprogramm lädst du die Aufnahmedatei rein, womit das Video decodiert wird, damit es dir im Schnittprogramm richtig dargestellt werden kann. Damit dir das Bearbeiten auch überhaupt gegeben ist.
      Wenn du das Ganze dann speichern bzw. 'Rendern' willst, musst du neue Encoder Parameter einstellen. Das Bild wird anschließend erst neu berechnet und zum zweiten neu encodiert.

      In einem Media Player wie z.B. VLC wird kannst du dann dieses Video dann nur Dekodieren. Damit es dir korrekt angezeigt wird auf dem Desktop.


      Sich mit Codecs auseinander zu setzen ist extrem wichtig, weil gerade die Encoder mit die Qualität beeinflussen. Schließlich will man ja kein Murks abliefern.

      banda schrieb:

      YouPloader wird empfohlen. Aber ist es nicht so dass YouTube selber eine Funktion anbietet Videos hoch zu laden? Wenn ja sollte das mindestens erwähnt werden.
      Ich denke der Vorteil an einen solchen Uploader aus Software Seite ist die, das man beim Upload, sofern es unterbrochen wird, wieder am selben Punkt fortsetzen kann. z.B. wenn der Browser oder die Youtube Seite selbst etwas spinnen sollte, ist man davor schon etwas gefeit.
      Hinzu kommt das man mit solchen Uploadern bequem Beschriftung, Titel, Veröffentlichung, etc. einstellen kann.

      Ist meiner Meinung nach eher dann Sinnvoll, wenn man wirklich Massenproduktion macht. ^^

      banda schrieb:

      Bis jetzt verstehe ich nicht wie Codecs, Encodierung, Rendering und Aufnahmeprogramme zusammenhängen.
      Muss ich wenn ich ein Aufnahmeprogramm habe (Pinnacle oder Adobe Premiere) noch eine Codec-Software z.B. MagicYUV dazu kaufen und einen Encoder z.B. 264x?
      Ich sage dazu einfach mal... ja, du solltest ungefähr verstehen wie ein Auto funktioniert, wenn du es fährst. Man muss ja nicht unbedingt wissen wie das Innenleben miteinander arbeitet. Man sollte aber wissen das man erst nach dem Anlassen des Motors das Fahrzeug bewegen kann. ^^

      Mit anderen Worten... Die Reihenfolge sollte dir klar sein und auch sollte dir klar sein wie man ein Encoder einstellt. Immerhin muss man beim Autofahren ja auch wissen wie die Verkehrsregeln sind, bevor man in der Öffentlichkeit los gelassen wird. Je sicherer du fährst, desto besser sind deine Fahrerskills. ^^

      Nix anderes bei Codec Einstellungen. Je besser sie sind, desto qualitativere bessere Videos bekommst du hin.

      Für bestimmte Videoschnittsoftware kann man sich weitere Codecs kaufen. Bei einigen wird man dazu auch regelrecht gezwungen.
      Vor nicht all zu langer Zeit war das bei Adobe Premiere auch der Fall. Der Codec x264pro gab es von Adobe für schlappe 299$.
      Was halt extrem teuer ist für einen Codec der sonst frei ist und bei Adobe noch nicht mal alle Funktionen zum Codec zur Verfügung gestellt werden.

      Seit diesem Jahr ist aber der Voukoder eine super kostenlose alternative dafür.

      Andere Alternativen sind aber unter anderem x264vfw, DebugFrameServer, Advanced Frame Server, AVISynth, x264 by Komisar


      An sich muss man nur eins im Hinterkopf haben...
      Je besser die Quelle, desto besser das Endergebnis.

      Soll heißen. Je besser und qualitativ die Aufnahme, desto besser wird das Endergebnis nach der Videobearbeitung werden.

      Daher ist die qualitativ beste Vorgehensweise wie folgt:
      Verlustfrei aufnehmen wie z.B. mit MagicYUV, UTvideo, Lagarith, etc. pp.
      Und dann qualitativ hochwertig mit x264 in h264 encodieren lassen. z.B. mit einem CRF von höstens 18.
      Das Video kann man dann hochladen und wird dann von Youtube erneut encodiert.

      Wie Youtube encodiert hängt von der Auflösung des hochgeladenen Video ab. Die gehen bei sowas halt anders vor. ^^
      Aber je besser das Video hochgeladen wird, desto weniger Murks kann Youtube daraus machen.

      Sollte Sinn ergeben, denk ich. ^^

    • Codecs lassen sich aufteilen in De- und Encoder. Also Entschlüsseln und Verschlüsseln. Damit wird die gespeicherte Dateninformation gemeint.


      Ein Encoder wird zum Verschlüsseln genommen.
      Ein Decoder zum Entschlüsseln der Informationen in ein RAW Format.
      Kurze Anmerkung: En- oder Decodieren hat nichts mit verschlüsseln zu tun. Würde zum erklären eher Wandeln nehmen als Begriff damit man dies nicht missversteht.
      ⋙⋙⋙ Meine Spielecke ⋘⋘⋘
      AstroLamb auf Youtube
      AstroLamb auf Twitch
      ⋙⋙⋙ Aktuelle Videoreihen ⋘⋘⋘
      Kerbal Space Program
      Surviving Mars


    • AstroLamb schrieb:

      Kurze Anmerkung: En- oder Decodieren hat nichts mit verschlüsseln zu tun. Würde zum erklären eher Wandeln nehmen als Begriff damit man dies nicht missversteht.
      Doch Encodiereun und Decodieren sind genau das was ich geschildert habe. Es sind Verschlüsslungen. Bei einer RGB Verschlüssung ist das total simple abgespeichert und man kann es halt auch so lesen. Wenn ich dir aber ein Bild ohne Header gebe und dir nicht sage das es in BGR gespeichert ist und dir nicht sage das es RLE komprimiert ist, wirst du erst mal Dumm dastehen und das Klarbild nicht erzeugen können. Dir fehlen halt Informationen, weil der Datenstrom verschlüsselt ist. Und ohne Informationen zur Farbraumanordnung und der entsprechenden RLE Algorithmus, kannste da ewig sitzen ohne das du jemals das Klarbild bekommen wirst. Sprich du bist dann unfähig das Bild jemals zu decodieren, weil dir die Schlüsselinformationen fehlen.

      Übrigens kommen die Begriffe Encodieren und Decodieren aus der Nachrichtentechnik.

      Die Begriffe Transkodierung und Rekodierung sollte man vllt. auch mal gehört haben.

      z.B. eine Rekodierung wäre es wenn ich aus einem RLE gespeicherten Bild die RLE Kompression entferne, das Bild aber immer noch identisch bleibt zwecks Datenstrom.

      Eine Transkodierung wäre es z.B. wenn ich ein RGB Signal in ein YUV Signal umwandeln würde. Oder die FPS ändern würde. Oder die Auflösung. Oder oder oder.

      Das was ihr am meisten macht ist eine Transkodierung. Ich unterstreiche das Wort mal. ^^

      Ansonsten wäre hier ne Quelle wo man sich durchlesen kann: de.wikipedia.org/wiki/Kodierer
    • RealLiVe schrieb:

      Encoding != Encryption, der Einwand ist korrekt. Den Header als Schlüssel zu bewerten ist aus meiner Sicht weit hergeholt.
      Was machste denn wenn dir kein Header gegeben ist? Du wirst mit der Datei nix anfangen können.

      Was ist wenn ich dir eine Nachricht gebe wo nur ich weiß wie es gespeichert ist? Du wirst erst mal nix damit anfangen können.

      Was ist denn bei einer ROM von SNES z.B. der Fall? Der Text ist kodiert. Wenn du nicht wüsstest das der Buchstabe A die 0 ist usw. kannst du es auch nicht dekodieren.

      Ohne die passende Information ist der Datenstrom nur wirrer Murks ohne das du damit was anfangen könntest.

      Du brauchst erst mehr Infos damit du damit was anfangen kannst. Sozusagen Schlüsselinformationen. Man muss doch schließlich irgendwie wissen z.B. um was für eine RLE Kompression man zu tun hat. Oder man sollte die Auflösung wissen. Man müsste wissen wie die Farbanordnung ist, man muss wissen wie viele Byte pro Pixel usw. Ohne diese Infos ist das Bild an sich nix weiter als ein wirrer Text mit dem man 0 anfangen kann.

      Ohne den Header würde eine kodierte Information für euch nur irgendein Quark sein. Bei nem Video würdet ihr sagen das das Teil Defekt ist. Obwohl der Datenstrom völlig in Takt ist. Kann halt nur nicht dekodiert werden, wenn die Informationen im Header fehlen.

      Was haben wir denn dann? Richtig... dann nennt man es cryptisch. lol


      Edit:
      Wenn ich ein Codec bauen würde und ihn Enigma nennen würde und er den Datenstrom auch entsprechend so speichert, dann habe ich den Informationsfluss encodiert. Der Text würde von mir einen Header bekommen, wo dann halt die Walzeninformation enthalten sind. Pos, usw.
      Öffnet man den Text mit nem simplen Notepad, würde man nur Quark rauslesen, weil ein Notepad damit nix anfangen kann.
      Lasse ich es aber mit dem entsprechenden Decoder dekodieren, ist der Klartext wieder da.
      Vllt. habe ich auch neben der Verschlüsslung auch das Bild mit einer RLE versehen. Der Text nach der Encodierung ist also mehr als Unverständlich.
      Und ohne Header. Sprich den Schlüssel kannst du mit der Datei absolut 0 was anfangen.

      Wenn ich Header und Datenstrom trenne, habe ich nix weiter als ein Schlüssel und eine cryptische Datei.

      Kannst mir aber gern den Gegenbeweis liefern.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()

    • Sagaras schrieb:

      Was machste denn wenn dir kein Header gegeben ist? Du wirst mit der Datei nix anfangen können. Was ist wenn ich dir eine Nachricht gebe wo nur ich weiß wie es gespeichert ist? Du wirst erst mal nix damit anfangen können.
      Wenn ich mit einem Franzosen rede und kein Wort verstehe, dann verschlüsselt er seine Nachricht nicht. Gut, blödes Beispiel, kein geistig normaler Mensch würde mit Franzosen reden, aber das ändert nichts am Vergleich.

      Dass der Inhalt nicht ohne weiteres lesbar ist rechtfertigt nicht das Wort verschlüsseln. Verschlüsseln hat Ziele aus dem Bereich der IT-Sicherheit, beispielsweise die Vertraulichkeit von Inhalten sicherzustellen. Du hast Schlüssel zum Ver- und zum Entschlüsseln, die du nicht unbedingt mit jedem teilen willst.

      Enkodieren ist da der allgemeinere Begriff, der für sich alleine nicht zwingend ein Ziel aus dem Bereich Sicherheit hat. Das Schema ist in unserem Kontext öffentlich verfügbar und der andere kann es, sofern die Datei intakt ist, dekodieren. Es ist kein Schlüssel im Sinne der IT-Sicherheit involviert. Wenn die Datei nicht intakt ist, dann ist entweder was schief gelaufen oder mein Gesprächspartner ist ein Idiot, weil der Spaßvogel den Header der Datei entfernt hat.

      Kurz: Du benutzt den Begriff falsch und noch dazu in einer Art, die mehr verwirrt als sie nutzt. Zu deinem Enigma-Beispiel findest du den Gegenbeweis in der Beschreibung des entsprechenden Wikipedia-Artikels.

      MfG,
      RealLive.
      Java is to JavaScript what Fun is to Funeral

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von RealLiVe ()

    • Sagaras schrieb:

      Der Text nach der Encodierung ist also mehr als Unverständlich.
      Aber jeder, der weiß, was du getan hast, kann es ohne Probleme wieder dekodieren.

      Ich sehe den Unterschied eher in der Zielsetzung - Kodierung an sich bedeutet lediglich erstmal, Information irgendwie in einen Code zu übersetzen. Verschlüsselung zielt eher darauf ab, dass der Code zusätzlich nur von wenigen Leuten mit einem entsprechenden Schlüssel verstanden werden kann, also gewissermaßen eine Erweiterung, die aber hier eher nicht zählt. Ein kodiertes Video ist idR nicht dazu gedacht, dass es sich nur wenige anschauen, es ist lediglich so gespeichert, weil man ein Video halt irgendwie speichern muss. Ich sehe da nicht den Anreiz, das Video nur für eine Minderheit lesbar zu machen.
      You like music? I like pissing.
      ~Corey Taylor

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von strohi ()

    • @banda
      Mit den Kritikpunkten hast du nicht ganz unrecht, es gibt aber hier zwei Probleme, die ich nicht unerwähnt lassen möchte:
      1. Ich halte es für schwierig, die Inhalte so präzise zu beschreiben, dass es wirklich was bringt, aber dabei Anfänger nicht zu erschlagen. @sem hat sich hier offensichtlich für eine grobe Übersicht über die Tipps entschieden, die generell im Forum so benannt werden. Es ist wie du schon sagtest mehr eine Tippsammlung als ein Guide. Aber auch als solche hat sie ein paar Schwächen, weil manches halt etwas verloren im Beitrag steht.
      2. Was man empfehlen kann hängt davon ab, was derjenige vorhat, was er ggf. schon an Hardware oder Software besitzt und so weiter und so weiter und sofort. Es gibt ja nicht nur ein Weg zum Ende, weshalb da ein Begleiten vom Anfang bis zum Ende schwierig ist. Ich halte es da derzeit noch für das Beste,wenn man ein neues Thema im Audio-/Video - Forum eröffnet und einfach fragt, wenn was unklar ist.

      banda schrieb:

      YouPloader wird empfohlen. Aber ist es nicht so dass YouTube selber eine Funktion anbietet Videos hoch zu laden? Wenn ja sollte das mindestens erwähnt werden.
      Die Empfehlung würde ich nicht mal mehr unterschreiben, auch der YouPloader steht derzeit still.

      banda schrieb:

      Er beginnt mit einer Erläuterung zu Codecs. Das ist äußerst irritierend denn wie man in dem selben Abschnitt erfährt erfolgt die Codierung idealer Weise nach der Aufnahme: "Dieser Prozess soll aber erst nach der Aufnahme beim Encodieren+Rendern geschehen".
      Doch, aber man müsste etwas mehr dazu schreiben. Das Kodieren - also das Speichern in einem Format, oftmals inklusive Kompression - macht man ja auch bei der Aufnahme. Im Wesentlichen kann man bei der Wahl des Verfahrens folgende Faktoren abwägen:
      • Die Qualität
      • Die Geschwindigkeit
      • Die Kompression - also möglichst kleine Dateien.
      Alles kriegt man nicht zeitgleich unter den Hut. Wenn du möglichst gute Qualität bei kleinen Dateien willst, dann sind die Verfahren dafür tendenziell aufwändig, um mal ein Beispiel zu nennen. Kommen wir mal zur Aufnahme zurück. Wenn da ein Spiel läuft, dann sollte das ja nicht durch die Kodierung beeinträchtigt werden. Und die Kodierung muss auch hinterherkommen. Man sollte also schauen, dass man die Geschwindigkeit und evtl. die Qualität höher priorisiert. Die Qualität, weil durch die Schritte Verluste entstehen, die man minimal halten oder gar ganz vermeiden will. Encoder, die diesen Kompromiss gehen wären halt unter anderem MagicYUV oder ein entsprechend eingestelltes NVenc - das wäre ein Encoder von Nvidia, der deren Grafikkarten benutzt.

      Der Kompromiss bedeutet aber fette Dateien, die man nicht unbedingt über die Leitung schieben will. Deshalb komprimiert / kodiert man das Video dann im Nachhinein oftmals mit dem erwähnten aufwändigeren Verfahren. Es kann auch sein, dass der Schritt nicht optional ist - wenn man schneidet und nach bearbeitet, dann kodiert das Schnittprogramm beim Rendern immer neu, wie Sagaras bereits erwähnt hat. In der Phase sind die Anforderungen anders. Es entsteht ein Video, was über die Leitung muss. Da sollte es also nicht unbedingt ein paar 100 GB groß sein. Und da in der Zeit kein Spiel Leistung verlangt darf die Kodierung ruhig ordentlich zulangen.

      Das wären ungefähr die Zusammenhänge von Codecs beim beim Aufnehmen von PC-Spielen und anschließendem Verarbeiten. Welche man genau nimmt ist so ne Sache, die ich generell nicht beantworten möchte. Hängt davon ab, was man machen will, was die Kiste und das Internet so hergibt und manchmal ist man auch durch Hard- oder Software eingeschränkt.

      Kleines Beispiel: Würde ich was aufnehmen, ich würde als Aufnahmeprogramm den MSI Afterburner bevorzugen - nicht weil es das beste Aufnahmeprogramm ist, sondern weil das Overlay affengeil ist. Ich hab also da schon mal ein Limit, das ich mir nicht ausreden lassen wollen würde. Der kann auf installierte Encoder zurückgreifen und hat ein paar GPU-Encoder integriert, die ich aber nicht nutzen kann. Fällt also wieder einiges weg. Ich würde also auf MagicYUV zurückgreifen. Die Dateien sind ein paar 100 GB groß und ich würde gerne in Vegas schneiden. Man kann in Vegas Encoder nachrüsten, also nehme ich x264 und stelle ihn so ein wie ich es brauche. Vegas hat zwar Encoder dabei, die arbeiten aber weniger effizient.

      Anderes Beispiel für einen komplett anderen Ansatz: Es kann für so manchen auch eine Option sein, die Bearbeitung gleich durch OBS Studio beim Aufnehmen zu machen, weil man sich den Aufwand später sparen will. Dort wären die Empfehlungen anders als bei jemanden, der immer auf ein Schnittprogramm zurückgreift, nur um ein Beispiel zu nennen.

      Was ich damit sagen will: Im Zweifelsfall und insbesondere bevor man (unsinnig) Geld ausgibt, hilft immer ein eigenes Thema im Forum mit möglichst vielen Informationen. Ein Guide kann halt nie alles abdecken.
      Java is to JavaScript what Fun is to Funeral

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von RealLiVe ()

    • Sagaras schrieb:

      Wenn ich dir aber ein Bild ohne Header gebe und dir nicht sage das es in BGR gespeichert ist und dir nicht sage das es RLE komprimiert ist, wirst du erst mal Dumm dastehen und das Klarbild nicht erzeugen können. Dir fehlen halt Informationen, weil der Datenstrom verschlüsselt ist.
      Okay, wenn ich dir also eine Rechnung schicke, aber nicht drauf schreibe von wem sondern nur die Positionen der Artikel mit samt Preis, dann ist das für die verschlüsseln? Dir fehlen ja auch entsprechende Informationen um mit der Rechnung etwas sinnvolles anzufangen.. Für mich nicht.


      Sagaras schrieb:

      Ansonsten wäre hier ne Quelle wo man sich durchlesen kann: de.wikipedia.org/wiki/Kodierer
      Danke, ist mir auch durchaus bekannt. Und auch hier findet sich direkt ein Hinweis darauf das du ein Video beim Rendern nicht Verschlüsselst.

      Ein Kodierer arbeitet nach einer fest vorgegebenen Kodiervorschrift, damit der Dekodierer auf der Empfängerseite das Signal wieder in das ursprüngliche Format zurückkonvertieren kan
      "nach einer fest vorgegebenen Kodiervorschrift" , das ist der elemtare Punkt der diese beiden Begriffe für mich unterscheidet. Kennst du das Verfahren, kannst du den Inhalt verstehen. Beim Verschlüsseln musst du das Verfahren kennen und den Schlüssel. Kennst du nur eines von beiden kannst du mit dem Inhalt nichts anfangen.

      Gehen wir mal weg von Videos und schauen uns diesen Text an:
      V2VyIGRhcyBsaWVzdCBpc3QgZG9vZiA6UA==

      Der Text ist kodiert, sage ich dir nicht mit welchen Algorithmus, kannst du nur raten. Aber sobald du das herausgefunden hast kannst du ihn ohne Probleme lesen, da du keinen Schlüssel brauchst um ihn zu entschlüsseln.

      Sagaras schrieb:

      Wenn ich ein Codec bauen würde und ihn Enigma nennen würde und er den Datenstrom auch entsprechend so speichert, dann habe ich den Informationsfluss encodiert. Der Text würde von mir einen Header bekommen, wo dann halt die Walzeninformation enthalten sind. Pos, usw.
      Öffnet man den Text mit nem simplen Notepad, würde man nur Quark rauslesen, weil ein Notepad damit nix anfangen kann.
      Lasse ich es aber mit dem entsprechenden Decoder dekodieren, ist der Klartext wieder da.
      Das ist eine Verschlüsselung. Nehmen wir an dass das was bei dir raus kommt das ist:

      Quellcode

      1. XYOWN LJPQH SVDWC LYXZQ FXHIU VWDJO BJNZX RCWEO TVNJC IONTF
      2. QNSXW ISXKH JDAGD JVAKU KVMJA JHSZQ QJHZO IAVZO WMSCK ASRDN
      3. XKKSR FHCXC MPJGX YIJCC KISYY SHETX VVOVD QLZYT NJXNU WKZRX
      4. UJFXM BDIBR VMJKR HTCUJ QPTEE IYNYN JBEAQ JCLMU ODFWM ARQCF
      5. OBWN
      Gut, wir beide wissen das der Text mit hilfe einer Enigma erstellt wurde, aber wie wir ihn lesen können wissen wir nicht. Erst wenn uns der Schlüssel bekannt ist, wissen wir was dahinter steht.





      Ja, die Begriffe sind durchaus miteinander verwandt. Wir sollten sie aber, vor allen hier im Kontext des Guides, nicht miteinander vertauschen. Ansonsten fragt irgendwann hier jemand ganz berechtigt "Wo gebe ich bei Youtube meinen geheimen Schlüssel an damit die das Video anzeigen können?"
      ⋙⋙⋙ Meine Spielecke ⋘⋘⋘
      AstroLamb auf Youtube
      AstroLamb auf Twitch
      ⋙⋙⋙ Aktuelle Videoreihen ⋘⋘⋘
      Kerbal Space Program
      Surviving Mars


    • AstroLamb schrieb:

      "nach einer fest vorgegebenen Kodiervorschrift" , das ist der elemtare Punkt der diese beiden Begriffe für mich unterscheidet. Kennst du das Verfahren, kannst du den Inhalt verstehen. Beim Verschlüsseln musst du das Verfahren kennen und den Schlüssel. Kennst du nur eines von beiden kannst du mit dem Inhalt nichts anfangen.

      Gehen wir mal weg von Videos und schauen uns diesen Text an:
      V2VyIGRhcyBsaWVzdCBpc3QgZG9vZiA6UA==

      Der Text ist kodiert, sage ich dir nicht mit welchen Algorithmus, kannst du nur raten. Aber sobald du das herausgefunden hast kannst du ihn ohne Probleme lesen, da du keinen Schlüssel brauchst um ihn zu entschlüsseln.
      Was unterscheidet das denn nun? Du erklärst genau das was ich geschildert habe.

      Beim Kodierer hast du eine Kodiervorschrift um den Inhalt unkenntlich zu machen. Kennst du die Vorschrift nicht bzw. den Algorithmus nicht, ist der Inhalt reiner wirrer Mist mit dem keiner was anfangen kann.

      Jetzt erklärst du es aber genau das gleiche mit dem Wort Verschlüsseln. ^^
      Nur das du hier mir de Schlüssel vorenthälst, was du beim Kodierer aber mitbekommst.

      Gebe ich dir den Header mit all den Informationen wie der Text kodiert ist, kennst du die Kodiervorschrift. Sozusagen den Schlüssel um den Scheiß wieder lesbar zu machen.

      Beim Verschlüsseln erklärst du mir aber nun das es genau das gleiche ist, nur das du mir nun kein Schlüssel gibst, sprich keinen Header und ich damit halt doof dastehe. ^^ Sehr gut. xD

      Aber wie beim Kodierer kann ich dein verschlüsselten Text anhand von reinem Raten auch rausbekommen.

      Als einfaches Beispiel... sollte jeder Mathematiker kennen:
      XOR Kodierung. Der Text kann damit verschlüsselt werden. Kennst die nicht die Zahl mit der der Text verschlüsselt wurde, kannst du ihn nicht lesen.

      Nehmen wir die Ceasar Verschlüsslung. Wo man jeden Buchstaben um x nach rechts oder links verschiebt. Weißt du x nicht, kannst du den Text auch nicht entschlüsseln.

      Die XOR Kodierung ist ein reiner Mathematischer Algorithmus, die Ceasar Verschlüsslung leider auch.

      Und jetzt erklär mir was die beiden denn von einander Unterscheidet als Kodierer und Verschlüsslung? ^^


      Ganz einfach. Gar keiner. ^^
      Weil wenn man mal lesen kann, und das fällt in diesem Forum vielen sehr schwer, dann würde man auf de.wikipedia.org/wiki/Verschl%C3%BCsselung unter Grundlagen und unter Verschlüsseln das finden.

      Ich zitiere mal die Passage:

      Wikipedia schrieb:

      Eine besondere und relativ einfache Art der Verschlüsselung ist die Codierung (auch: Kodierung). Hierbei werden in der Regel nicht einzelne Klartextzeichen oder kurze Zeichenkombinationen verschlüsselt, sondern ganze Worte, Satzteile oder ganze Sätze.

      Aber ihr könnt das natürlich so sehen wie ihr gern möchtet. ^^
    • Ich schätze mal, einem Anfänger ist es ziemlich egal, ob Encodieren nun Verschlüsselung beinhaltet oder nicht.
      Zum Erklären der einzelnen Begriffe hatten wir mal das Lexikon, was hoffentlich irgendwann wieder kommt. Möchte den Guide damit ungern aufblähen, da es viele, an die sich der Guide richtet, sicher gar nicht interessiert. Wer es doch tut, liest uU. auch mehr als den Startpost und wird eure Ausführungen dazu sehen.

      Wäre aber schön, wenn ihr eure Energie (vielleicht gemeinsam) in einen eigenen Guide stecken würdet. Den würde ich bestimmt auch anpinnen. ;)
    • Sagaras schrieb:

      Weil wenn man mal lesen kann, und das fällt in diesem Forum vielen sehr schwer, dann würde man auf de.wikipedia.org/wiki/Verschl%C3%BCsselung unter Grundlagen und unter Verschlüsseln das finden.
      Wenn man lesen kann und Recherche ernst nimmt, dann findet man unweigerlich auch Definitionen außerhalb von Wikipedia, wie beispielsweise im RFC 4949 - das ist der Internet Security Glossary in der Version 2, der beschreibt, in welchem Kontext Begriffe in technischen Dokumenten benutzt werden sollten: tools.ietf.org/html/rfc4949

      Dort findest du bei encode zwar auch die Definition "Synonym for encrypt", allerdings direkt dahinter die nicht zu überlesende Anmerkung Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for "encrypt"; encoding is not always meant to conceal meaning. Die gültige Definition - und so wird sie auch meines Wissens nach in der Literatur benutzt - sieht folgendermaßen aus:

      RFC schrieb:

      Use a system of symbols to represent information, which might originally have some other representation. Example: Morse code.
      Also das, was wir dir hier mehrfach erfolglos versuchten mitzuteilen. Die Benutzung des Begriffs Verschlüsselung in dem von dir beschriebenen Zusammenhang bleibt falsch.
      Java is to JavaScript what Fun is to Funeral

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von RealLiVe ()