Beiträge von Sagaras

Zitat von RealLiVe

Mit 32 Bit x264 ging's auch ohne Pipe. Versteh mich nicht falsch, die Info ist wichtig, aber sie stimmt nicht zu 100% - wie gesagt, MT ist funktionsfähig - und sie passt eigentlich auch nicht in ein Thema, in dem es nicht um MeGUI geht.

Machst du das mit Absicht dieses muntere "Ich lese nicht seinen Beitrag, sondern suche mir nur das passende raus und gebe ihn eine Antwort die nicht mehr zu seinem anderen geschriebenen passt" - Spielchen?

1. Ich habe geschrieben das es sein kann das MT nicht funktioniert, da der neue x264 bei MeGUI selbst AVISynth supporten tut. <- Das hast du schon mal komplett ignoriert.
2. Den Satz den du da zitiert hast mit "Selbst wenn das FFmpeg als Pipe missbraucht wird und ein y4m RAW File pipen tut an x264." war für die Texte davor bestimmt. Und da habe ich drauf hingewiesen das es um den nicht Verfügbaren Support von relativen Pfaden in AVS Skripten geht.

Zitat von RealLiVe

MT ist verglichen mit den Plug-Ins eine andere Geschichte - die SET-Version mit MT wird ja installiert, indem man die installierte avisynth.dll mit einer ersetzt, welche die Funktionalität und die nötigen Befehle mitbringt. Sofern die korrekte avisynth.dll geladen wird, steht das zur Verfügung. Und das tut sie bei mir.

Jein, das muss nicht immer so sein. Es kann auch mal sein das AVISynth als Programm integriert wird. Dann ist die DLL von AVISynth halt ein Teil davon. Wenn die die Bibliothek in einen Encoder mit kompilieren, kann es auch mal sein das bestimmte Funktionen nicht mehr möglich sind.

Vergiss nicht das "KANN" zu überlesen. Danke.

Zitat von RealLiVe

EDIT: Hatte den x86 Build von x264 drauf. Habe das Update nochmal angestoßen und das Paket jetzt auf x64 aktualisiert. Dort kracht es zwar ohne die Pipe von FFmpeg, mit klappt es aber weiterhin.

Kann sein das alle internen Plugins die MeGUI nutzt funktionieren.

Aber Individuelle Scripte die irgendwo auf der Platte sind und relative Pfade enthalten für Plugins oder Module funktionieren nicht mit dem neuen x264 von MeGUI. MeGUI ladet es zwars mit dem internen installierten AVISynth und zeigt es auch alles brav an, aber encodieren geht nicht mehr.

Das gleiche mit MT.

Sind MT Befehle vom modifizierten AVISynth von SET im Spiel gibt es auch ne Fehlermeldung.

Solange alles Brav in MeGUI ist, Plugins usw. läuft das Teil vermutlich. Sind Plugins außerhalb oder in Modulen mit relativen Pfaden angegeben ist schicht im Schacht.

Das hab ich schon mit einigen anderen Entwicklern schon ausdiskutiert und die haben das auch bemerkt dann das da was nicht stimmt.
Ist wie gesagt ein Hinweis und das hab ich Zathor auch schon geschrieben.

Hier mal der Auszug wie der Fehler dann aussieht:

---[Information] [06.08.2018 18:45:09] [avisynth @ 0554da00] [error] LoadPlugin: unable to load "ffms2.dll", Module not found.  Install missing library?

Das passiert wenn als Plugin Pfad das hier verwendet wird:

LoadPlugin("ffms2.dll")

Und die ffms2.dll befindet sich dabei genau im selben Pfad wie das AVS Skript.

Ist der absolute Pfad enthalten gibt es keinen Fehler seitens MeGUI.

Selbst wenn das FFmpeg als Pipe missbraucht wird und ein y4m RAW File pipen tut an x264. FFmpeg kann nix damit anfangen. Entweder die Pipe hat ein Problem damit oder x264. Was auch immer.

Problem besteht bei MeGUI Version 2872 Development Update Server mit der x264 Version 2901 und der FFmpeg Version 4.0.2

Hat man die neue MeGUI Version hat man auch den neuen x264 Encoder der AVISynth supportet. Es wird kein avs4x264mod mehr benötigt. Der neue x264 Encoder unterstützt nur noch 64Bit und kann auch die 32Bit AVISynth Scripte verarbeiten.

Soweit so gut.
Problem an der Sache ist, und das habe ich auch schon Zathor geschrieben, das der neue x264 Encoder der nun AVISynth supportet keine relativen Pfade mehr deuten kann. Sobald in einen Skript relative Pfade sind für Plugins z.B. wird MeGUI das Skript abbrechen und nicht verarbeiten können.

Im Skript müssen zur Zeit komplette Pfade angegeben werden.

Das ist momentan eine Rückentwicklung zwecks Benutzerfreundlichkeit bei MeGUI, aber ich hoffe er kann da was machen und wenn er den Entwickler oder was weiß ich anschreibt der die x264 da zusammen kompiliert hat

PS: MT wird auch nicht funktionieren, da das integrierte AVISynth in dem neuen x264 Encoder ein Original AVISynth+ Support nur hat.

Das heißt das einige Plugins nicht funktionieren können.

Und MT schon gar nicht, da der MT Befehl den der SSM enthält nicht auf AVISynth+ aufbaut, sondern auf das reguläre AVISynth.

Zitat von SvenPower

Normalerweise pfeifen die Plastik Brotkästen doch schon bei den eigentlichen Spielen aus dem letzten Loch und haben Frameeinbrüche jenseits von Gut und Böse. Dann noch ein paralleler x264 Stream auf Very Fast, der meinen zweiten, separat für OBS, hingestellten PC auf allen 12 Threads auslastet, halte ich schon für sehr unwahrscheinlich. Lasse mich da aber gerne eines besseren belehren

Die PS4 nutzt für Videoaufnahmen einen eigenen dafür vorgesehenen Speicher. Musste dir so vorstellen wie bei den NVIDIA Karten mit NVenc. Das ist völlig abgekapselt die Videoaufnahmen bei der PS4. Die Spiele nutzen ihren Speicher, die Videoaufnahmen ihren.
Mit anderen Worten: Im Spiel wird man das nicht merken das die PS4 aufnimmt. FPS, als auch Gameplay bleiben so als wenn man nicht aufnimmt.

Zitat von Rayxin

eine PS4 bewegt sich auf dem x264 Niveau von ultrafst maximal superfast. Richtig grottig ist das. Die PS4 Pro schafft von der Quali her veryfast.

Sony nutzt ein AMD H264 Model eines Encoders. Und zwars einen GPU Encoder. Den AMD VCE. Jedenfalls wird dieser Bitratengesteuert betrieben. Daher kann man der PS4 ja von der Qualität auch nur sagen: schlecht, mittel, gut. 3 oder 4 Optionen waren das auf jedenfall. Und danach wird eine feste Bitrate genommen + VBR (Variable Bitrate). Das heißt das die fest vorgelegte Bitrate eingestellt wird als Maximal Wert.

Das bedeutet:
Nimmt ihr ein Video auf das vom Bildaufbau recht unkomplex ist, wie z.B. ein recht ruhiges Bild, oder sehr viele einheitlich farbige Flächen, so wird die Bitrate unter der gesetzten Bitrate bleiben und das Bild im Video sieht top aus.
Wird der Bildaufbau aber komplex, wie z.B. viele Details im Bild wie Vegetation von Bäumen und Gräser, schnelle Bewegungen etc. pp, wird die benötigte Bitrate enorm sein und der gesetzten Bitrate von der Aufnahme übersteigen. Und wenn die Bitrate nicht ausreicht wird das Bild im Video auch schlechter. Das zeigt sich dann entweder in Pixelbrei oder Unschärfe.

Zudem sind eh nur Aufnahmen in 720p möglich bei der PS4, wobei Streams mit 1080p möglich sein sollten (Bin mir da grad nicht sicher, müsst ich noch mal nachschauen). Wie das bei der Pro ist, weiß ich leider nicht.

Da die PS4 max. ein H264 Video mit einen High Level 4.2 abspielen kann, wird auch die maximale Bitrate die 62,5 Mbit/s nicht übersteigen können. Bei Live-Streaming hat sie aber deutlich mehr Potenzial. Genauso wie bei Videoübertragungen via Share Play.

Die internen Aufnahmen die auf der PS4 gespeichert werden und in 720p erfolgen werden in etwa mit 5 bis 10 Mbit/s aufgenommen.
Das ist übelst wenig.

Daher ist es egal ob ultrafast, veryfast oder was weiß ich. Weil man kann auch mit diesen Presets hochwertige Videos produzieren ohne das da Fragmente oder Schlieren oder Unschärfe als Fehler im Video auftauchen. Das hat mit den Fehlern nix zu tun dann. Vielmehr der Bitraten-Cap der das Video dann in ein Brei verwandelt bei komplexeren Bild Szenen. ;D

Ein guter Rat:
Für Live-Streaming kann die PS4 wunderbar eingesetzt werden, sofern die Internetleitung eine recht hohe Bandbreite zulässt. Min. eine 16000 Leitung sollte da schon drin sein.
Die Qualität der Live-Streamings von der PS4 aus, sind qualitativ besser als wenn man intern aufnimmt. Hängt wie gesagt von der Bandbreite ab.
Ist die Bandbreite für Live-Streamings zu niedrig, wird die PS4 das kompensieren indem sie die Bitrate drosseln tut. Folge sind dann Fragmente im Bild.
Ist die Bandbreite zu sehr ausgelastet mit Upload, kann auch ein Stau enstehen. Das heißt: Ist die Bitrate zu viel beim Upload oder der Upload schwankt zu sehr, kann ein Upload Stau entstehen. Der Stream wird sich dann durch schlechtes Bild und dann durch ein eingefrorenes Bild äußern. Auch zu erkennen wenn der Delay zu groß wird.
Ist das der Fall, sollte man eine niedrige Auflösung für den Upload nutzen. Weil dann reicht die Bandbreite nicht aus.

Von einer internen Aufnahme von der PS4 würde ich abraten. Das kann man für Private Zwecke vllt. noch machen oder für Guides. Aber für komplette Let's Plays ungeeignet.

Empfehlen würde ich die Aufnahme einer PS4 über ein externes Gerät. z.B. einer Aufnahmekarte wie z.B. einer Elgato oder was weiß ich was grad so angesagt ist. Bei der PS4 ist das übelst leicht, da man bei dieser Konsole den HDCP abschalten kann in den Optionen. Damit ist der HDMI Ausgang der PS4 nicht verschlüsselt und kann somit auch aufgenommen werden über eine Aufnahmekarte am PC.
Qualitativ die Beste Wahl, da das Bild somit 1:1 wie am Fernseher ankommt, dank HDMI und zum zweiten man individuell das Video selbst am PC encodieren kann. z.B. mit x264.
Und noch ein Plus Punkt ist das das HDMI Signal auch 1080p oder gar 4K senden kann. Somit ist man vom internen PS4 Encoder weg.

Hau doch mal ein Titel raus die bei dir nicht gehen, die aber mit dem Editor erstellt worden sind. Dann könnten andere das ja probieren und berichten, bzw. sogar eine Lösung vorschlagen.

Zitat von Game8

Es bietet mir 23,976, 24, 25, 29,970, 50 und 59,94 FPS an.

Jo, alles analoge Werte für NTSC, PAL und sonstige Länderstandard Geräte. Weil deine Schnittsoftware für Kameras und andere Geräte eigentlich gedacht ist vorwiegend. Darum sind das auch feste Werte die dann angeboten werden. Also an sich kein Fehler von der Software.
De-M-oN würde jetzt vermutlich sagen das die Entwickler keine Ahnung haben und blöd sind. Aber die denken sich dabei schon was.

Zitat von De-M-oN

Du kannst konstanten QP Modus einstellen, aber den QP Wert nicht, sondern weiterhin nur bitraten?

In der Regel müsste die Bitratenangabe ignoriert werden. Vllt. richtet das sich nach dem Preset. Das wenn man schnelle Presets verwendet, ein deutlich qualitativer QP Wert verwendet wird und bei langsamen Presets ein etwas gering qualitativer QP Wert. Halt um das Geschehen im Bild auszugleichen.

Oder es richtet sich tatsächlich nach den Bitraten. Würde ja für QP auch gehen. Weil bei CQP kannst du eine max. Bitrate angeben die er nicht überschreiten darf. Fungiert halt als Limiter. Und die Durchschnittbitrate ist nur ein Grober Wert aus dem dann der Faktor für QP bestimmt wird. Weil du kannst ja das Video analysieren, damit man die Werte hat und dann kodieren lassen. Vegas kann das ja auch. In dem Sinne werden die 100Mbit angesteuert, aber mit dem Faktor den die Durschnittbitrate ergibt passend zum Video.

Wenn das der Fall ist, gibt es eigentlich keine Lösung dafür, weil dieser Faktor Wert komplett für jedes andere Video Variable wäre.

Und ja, wäre dann ineffizient, weil das ja dann darauf beruht die Bitrate via Wahrsagerglaskugel raten zu müssen, damit man den passenden QP Wert hat. xD

Müsste jemand aber ausprobieren von was das ganze abhängig ist. Ihr macht ja da eh mehr Videos in der Hinsicht.

Zitat von Game8

Dann frage ich mich, wieso das überall als Standard hinterlegt ist. Werdens halt 30

Die 29,97 oder 59,94 oder 23,976 usw. sind alles solche NTSC Frequenzen die noch aus dem analogen Bereich stammen. Um genau zu sein von Röhren Monitoren.
Das hat noch was mit Wechsel- und Gleichspannung zu tun mit den einige Länder die Trägerfrequenz zu ihren Geräten angepasst haben.

Das ist noch Standard und wird es auch weiterhin bleiben. Nur einige junge Leute (darunter auch viele User im LPF und Entwickler wie die von OBS) meinen das es ein Standard sein muss, weil USA is the best. ;D Nein, ohne Scheiß, es ist in der USA ein Standard der sich eingebürgert hat und auch heute noch Geräte so funktionieren. Von Kameras, etc. mal ganz zu schweigen. Und es kommt ohnehin jeder Scheiß entweder aus China, Japan oder USA. Und die haben alle diese 29,97 NTSC Standard.
Aber das ist ein analoger Wert und für den digitalen Bereich irrelevant.

Die AMI PS4 oder PS3 über Component oder SCART und ihr könnt trotzdem 30 oder 60 FPS nutzen. Weil ein Spannungswandler schon drin ist. Genauso wie wir in Deutschland auch AMI Kram nutzen können ohne das es flöten geht.

Für Youtube, PC, Smartphones, etc. pp. sind diese Krummen Dinge völlig uninteressant. Kann man nutzen, muss man aber nicht. Und sollte man auch lieber nicht, da gerade Anfänger bei sowas sehr leicht Mist bauen können und ihre Videos asynchron raus kodieren, weil sie vllt. von 29,97 FPS auf 30 FPS kodieren. Die Audiopart aber unberührt bleibt davon.
Häufige Fehler passieren aber bei Schnittsoftwares, wenn man z.B. ein 30 FPS Video aus versehen als 29,97 FPS Video raus haut.

Fazit: Es ist ein Fehlergrund, den man gleich am Anfang vermeiden könnte.

Zitat von Zastava

Hoffe mir kann jemand sagen, ob es was bringt bei Sony Vegas unter Projekteinstellungen das Pixelformat von 8Bit auf 32Bit zu stellen

8Bit was? Palette? 8Bit sind 256 Kombinationen, weshalb man dort eher von einer Farbpalette spricht.

8Bit pro Kanal ist was anderes. Das sind dann 24Bit.

Und nein, es bringt keinen Vorteil von 24Bit auf 32Bit zu wechseln, wenn es nicht zwingend nötig ist.

Man kann auch 24Bit nach 32Bit und umgekehrt konvertieren lassen ohne Verlust, da ihr im Begriff seid das Endvideo zu produzieren.

Man kann auch Videos mit Alphakanal erzeugen und als Schablone verwenden. z.B. ein sich drehender Stern der von Außen Video A hat und im Stern Video B abspielt. Das ist dann für Effekte sehr etc. gut.

Im Endeffekt ist es aber so bis auf einige Ausnahmen wie z.B. Premiere: Ein Video in einer Schnittsoftware wird immer mit RGB32 neu berechnet und dann an den Encoder / Frameserver gesenden. Was dann der Encoder bzw. Frameserver damit macht, obliegt dem User wie er den Codec einstellt.

Warum konvertiert eine Schnittsoftware Videos in das bevorzugte RGB32?
Um sie A) auf einen gleichen Nenner bringen zu können zu anderen Videos in der Schnittsoftware, B) um jeden Differenz-Frame in Schlüsselbilder zu wandeln, damit man sie auch an dieser Stelle anspulen und schneiden kann und C) da viele Effekt Filter von Schnittsoftware auf RGB32 ausgelegt sind und diese erst damit arbeiten können.

Spiele laufen ja auch in RGB32. Dort sind es wie gesagt Filter etc. die dafür sorgen das Effekte funktionieren. z.B. bei Bumpmapping.

Zitat von Zastava

Ich mach das ganze über den Frameserver (RGB24), megui und x264 (Misc: --output-csp i444 // AvS: ConvertToYV24())

Kann man so machen, muss man aber nicht. Der Mehraufwand für den minimalen Unterschied zwischen i420 // YV12 und i444 // YV24 ist so gering, das er sich kaum lohnt. Lieber dann in i420 // YV12 kodieren lassen und sich über mehr Speed freuen.

Zitat von De-M-oN

Und 8bit pro Farbkanal ist nunmal 24bit+Alpha = RGB32.

8Bit pro Farbkanal sind nach Adams Riese 24Bit Der Alphakanal ist da total uninteressant.

Ein RGB 24Bit Bild als auch ein RGB 32Bit Bild kann man mit 8Bit pro Kanal bezeichnen. Die gehören beide dazu.

Er hat aber nur geschrieben was von 8Bit und 32Bit. Jetzt kannste dir aussuchen was er meint.
Meint er mit 8Bit ein Video mit einer Farbpalette? Oder ein reguläres 8Bit pro Farbkanal? Oder 8Bit Tiefe? Gibt ja auch 10Bit ;D Nutze deine Glaskugel.

Zitat von RealLiVe

Konkret frage ich mich, wo denn genau der Unterschied ist zwischen dem Einbinden von Bildern, was ja wegen Bedenken zur DSGVO unterbunden wurde, und dem Einbinden vom YouTube-Player?

Eigentlich gibs kein Unterschied. Deine Daten werden mit übertragen. So wie eigentlich jeder scheiß Link das tut. Theoretisch müsste jeder Link und jedes eingebundene Objekt wie Bilder oder Videos vom User bestätigt werden das dieser damit einverstanden ist persönliche Daten zu senden. Weil die IP schickt man halt bei jedem Link ja nun mal mit.

An sich müsste dieses Forum, wenn es sehr behaarlich auf die DSGVO hören sollte, keine externen Links mehr erlauben und auch externe Bilder und Videos verbieten einzubinden. So hab ich das jetzt verstanden irgendwie. Könnt mich aber gerne verbessern.

Zitat von Julien

Wenn es vorgefertigte Presets sind, dann ist das höchstwahrscheinlich noch eins aus der Zeit des analogen Fernsehens – da waren NTSC und 29.97 FPS nämlich noch wichtig, mittlerweile ist das alles überholt.

Ja und Nein.
Ja, wenn man Videos nur auf PC oder Konsole oder Handy betrachtet. Weil dem OS das an sich total egal ist was da mit wie viel FPS abläuft.

Nein, weil auch für Fernseher heutigen Standards das gar nicht so unwichtig ist. Die Frage die sich einen dabei stellen sollte ist: Warum werden BluRays und DVDs die International sind mit 23,976 FPS oder 29,97 FPS kodiert? Das hat seinen Grund warum das heute immer noch so gemacht wird.

Das hat den Zweck das du solche Filme und Videos auch in Amerika oder sonstwo schauen kannst an solchen Fernseher die die dort teilweise noch haben. Die hätten vermutlich auch gerne 30 FPS oder 24 FPS genommen, aber um Farbfehler vorzubeugen wegen ihren Wechselstrom der bei 60Hz liegt, ergeben sich halt diese krummen FPS Werte. Dadurch werden Tonhöhenschwankungen bei der Übertragung vermieden.

Da eure Video Schnitt Software nicht aus Deutschland stammt, und diese dann auch noch für Kamera, Film etc. pp. ausgelegt ist, ist es auch Standard das meist 29,97 oder eben 23,976 FPS genutzt werden. Ist halt ein Stück amerikanische Software. Oder Japanische. Die haben genauso so ein Kram.

Und das alles ist recht wichtig wegen der Übertragung auf analogem Wege. Bei SCART oder Component RGB hat man das auch nicht. Aber bei Composite, FBAS, S-Video und RCA spielt das eine wichtige Rolle.

Wenn man sich eine PS4 z.B. holt, wird da gewiss ein Composite Kabel / FBAS mit bei sein. Grundausstattung halt.
Um dir dann zu gewährleisten das die BluRay korrekt angezeigt wird auf einem Ami Ferneseher, waren die Ersteller für BluRay und Co so geistet Gegenwertig und haben für dich Gott Sei Dank die Framerate entsprechend ihrer Wechselstrom Frequenz Übertragung angepasst, sodass du keine Farbfehler siehst.

Da 25 FPS drunter liegt können auch Problemlos PAL Videos dort geschaut werden ohne Farbstörungen.

Also Fazit: Das hat heutzutage immer noch seine Berechtigung. Kann sein das es irgendwann mal abgeschafft wird. Aber solange es Fernseher mit Analoger Übertragung gibt, werden sich BluRays, DVDs etc. auch nicht ändern.

Es ist halt ein Standard. Genauso als wenn ihr sagt das 16:9 ein Standard ist. Ist halt so.

Videostream hat ne Größe von 1,94 Gibibyte -> 1986,56 Mebibyte
Audiostram ne Größe von 52 Mebibyte

Macht nach Adam Riese 2038,56 Mebibyte -> 1,99078125 Gibibyte, also 2,137585091 Gigabyte

Anschein ist das Video samt Audio komplett vorhanden und müsste auch von einen lokalen Mediaplayer ala VLC oder MPC-HC abgespielt werden können.

Das einzige was nicht hinhaut ist der Gesamtkopf des MP4 Containers.

Daher würde ich Juliens Vorschlag annehmen und dieses Video einfach neu Muxen lassen. Sollte ausreichen, sofern das Video in der Datei vollkommen vorhanden ist.

https://www.amazon.de/Codierun…itr%C3%A4ge/dp/3528153997

Also ist das Buch schon mal mist. Stimmt ja mit deiner Definition nicht überein.

Oder Codierung mit Matrizen.
https://www.lernhelfer.de/schu…el/codierung-mit-matrizen

Scheiße... darf man auch nicht nutzen. Da wird mit dem Wort Verschlüsseln hantiert.

Und sind deiner Meinung nach sehr kluge Leute im Netz die das Codieren mit dem Wort Verschlüsseln und Entschlüsseln erklären einfach nur dumm, weil sie nicht deiner Meinung sind?

Sehr gut.

Wenn ich dem Enigma Code einen Header gebe wo Walzenanzahl, Position etc. eingetragen ist, ist es keine Verschlüsslung mehr, sondern ein Kodierung. Weil ich kann es ja dann frei dekodieren, weil mir der Schlüssel bekannt ist.

Wenn ich die Informationen nicht habe, dann ist es deiner Meinung nach eine Verschlüsslung, weil kann ja kein anderer lesen.

Ist das soweit korrekt?

Zitat von RealLiVe

Kannst du das lesen? Ich nicht. Wir konnten es aber, sobald wir das Verfahren heraus hatten. Es war nicht verschlüsselt - es war problemlos lesbar, sobald das Verfahren selbst bekannt war.

Du weißt schon was du schreibst, oder?

Wenn du es nicht lesen kannst, weil dir das Verfahren unbekannt ist, ist es verschlüsselt, bzw. encodiert oder halt mit euren Worten gewandelt. Ohne das entsprechende Verfahren zu kennen kann kein anderer was damit anfangen. Hast du selbst jetzt gesagt.

Natürlich ist das Verfahren/Algorithmus selbst schon ein Schlüssel um Textnachrichten zu wandeln.

Wenn du Klartext hast und es durch die Enigma jagst, wandelst du den Text doch auch um. Der kann doch auch nur mit dem gleichen Verfahren in Klartext umgewandelt werden.

Und ihr habt selbst gesagt das Kodierung = Wandeln bedeutet.

Gebe ich dir ein Bitmap Bild ohne zu sagen wie es kodiert ist. Sprich ich enthalte dir die Information der Speicherung vor, bist du nicht in der Lage es zu dekodieren. Du müsstest dir die Informationen erst mal erraten. Und erst wenn dir das gelinkt kannst du das Bild darstellen.

Selbst wenn du den Algorithmus wüsstest, fehlen dir halt Informationen ohne den Header. Sprich das Bild wäre erst mal sicher, solange du keine genaueren Angaben hast wie der Datenstrom gespeichert wurde. Und das ist nix anderes dann als eine Verschlüsslung. Und trotzdem nennt man das Ding was dafür sorgt das es wieder Klar wird einen Decoder. Ja, warum wohl?

Ich würde sagen ihr verrennt euch selbst langsam.

Zitat von RealLiVe

In dem Fall ist das Mapping Bestandteil des Verfahrens, vollständig öffentlich und hat nicht das Ziel, den Inhalt vor unbefugten Augen zu verbergen. Deine Einwürfe ändern an den Begrifflichkeiten nichts. Auch dass die Verfahren verwandt sind ändert daran nichts.

Soll das jetzt bedeutet, alles was öffentlich ist ist ein Codec und alles was nicht bekannt ist ist Crypting oder was?

Zitat von AstroLamb

Ich schlie0e das Thema für mich hier ab. Am Ende haben beide Verfahren einen anderen Hintergrund, entsprechend sollte man auch Sprachlich versuchen das ganze abzugrenzen. Beim Verschlüsseln versuche ich den Inhalt geheim zu halten, nur diejenigen mit dem Schlüssel sind in der Lage die Nachricht zu lesen.[2]
Beim Kodieren wandel ich den Inhalt X zu Format Y und kann ihn später ohne Einsatz eines Schlüssels von Format Y zurück kodieren um Ihn zu lesen. Hier habe ich nicht das Ziel das jemand anderes den Inhalt nicht lesen kann sondern das ich Bandbreite spare durch kompression oder um Fehlertoleranz einzubauen oder ähnliches. [3]

Das bedeutet also... wenn ich dir ein Text gebe ohne Infos wie es kodiert ist, wärst du in der vollen Lage den Klartext raus zu bekommen.
Ich könnte das so einfach machen und du würdest davor sitzen und den Text niemals raus bekommen.

Zitat von AstroLamb

Beim Kodieren wandel ich den Inhalt X zu Format Y und kann ihn später ohne Einsatz eines Schlüssels von Format Y zurück kodieren um Ihn zu lesen.

Eben nicht. Kennst du die Werte die für das Verfahren benötigt werden nicht, kannst du den Inhalt nicht rekonstruieren. Und die stehen im Header.

Würdest du einer Enigma-Verschlüsslung einen Header angeben wo Walzenposition etc. gespeichert sind, wärst auch du in der Lage den Text in Klartext wandeln zu können. Und trotzdem würde die Datei encodiert sein und zugleich nicht lesbar. Das kann nur ein Tool das auch was mit den Headerinformationen anfangen kann. Der Datenstrom ist aber ohne Header komplett verschlüsselt.

Ohne den Header sitzt du auch nur doof da. Daher ist der Header mehr oder weniger der Schlüssel für das Verfahren. Du brauchst halt Informationen um das Verfahren anwenden zu können. Sonst sind Dinge wie Bilder, Videos, etc. nur wirres Datenwirrwar das du im Falle von z.B. H264, XVID, JPG, etc. nicht entschlüsseln bzw. dekodieren kannst.

Zitat von AstroLamb

Text A + Verfahren A + Schlüssel A = Verschlüsselung, nur mithilfe des Schlüssels A kannst du Text A lesen.
(XOR, Enigma, AES, Ceasar....)
Text A + Verfahren A = Kodierung, jeder der das Verfahren kennt ist in der Lage den Text zu lesen.
(Base64)

Wo ist denn nun der Unterschied?

Bei Base64 sind die Werte (sozusagen der Schlüssel) fest vorgeschrieben. Steht sogar auf der Wiki.
Aber der Knackpunkt ist doch... würdest du es dekodieren können wenn du nicht wüsstest das es Base64 verschlüsselt ist. Nein, der Text wäre nur ein Kauderwelsch.

Was unterscheidet es denn von der XOR Kodierung?
XOR Kodierung kann man schnell erraten. Sind ja nur 256 Möglichkeiten möglich. Aber würdest du nicht wissen das es XOR kodiert ist, würdest du auch nur ein Kauderwelsch haben, mit dem du 0 was anfangen kannst.

Mit anderen Worten. Eine Wandlung oder Entschlüsslung in den jeweiligen Klartext ist nicht möglich, sofern dir das Verfahren unbekannt ist.

Gebe ich dem XOR kodierten Text eine Header Information noch mit wo der Wert drin steht mit was es XOR genommen wurde, ist es genau das gleiche nun wie das was du bei Base64 erklärt hast.

Du wärst in der Lage, sofern du das Verfahren kennst den Klartext wieder zu bekommen.

Naja Sem, ich würde schon gern wissen was nun der Unterschied sein soll. Weil alle Quellen die ich finden kann beschreiben beide Worte so ziemlich exakt gleich. Und ich arbeite als Digitaltechniker und Entwickler schon ziemlich lange mit diesen Begriffen und deren Anwendung. Aber das es jetzt komplett neu sein soll die Begriffe, würde ich halt gern mal wissen was das geändert wurde.

Das Beispiel von @RealLiVe mit dem Franzosen. Ihm würde ich vllt. mal das Kommunikationsmodell zu rate ziehen und sich damit beschäftigen. Aber er sollte sich nicht so weit dort reinlesen, weil sonst trifft er auf Worte wie Encodierung und Decodierung zwischen Sender und Empfänger. xD
Bzw. findet er deutsche Kommunikationsmodelle wo es mit den Worten Verschlüsseln und Entschlüsseln erklärt wird.
Und trotzdem sind beide Modelle völlig korrekt.

http://www.fb10.uni-bremen.de/…/grundkurs1/kapitel3.aspx
http://thenaturalcurriculum.co…ikationsmodell-heupel.gif
http://docplayer.org/docs-images/52/30674109/images/13-0.png

Als Beispiel: Nur weil ich ein Delphin nicht verstehe, redet er dennoch unter seines gleichen Klartext. Für mich ist es aber verschlüsselt, weil ich A) seine Syntax nicht verstehe und B) seine Wortlaute keinen mir bekannten Wort zuordnen kann. Mit anderen Worten ich kann es nicht übersetzen.

Treffe ich ein Franzosen ist es das gleiche. Bin ich der Sprache nicht mächtig, kann ich mit der Information des Franzosen nix anfangen. Es liegt eine Kommunikationsstörung vor. Einfach weil ich seine Nachricht nicht dekodieren bzw. entschlüsseln kann. Oder das Übertragungsmedium nicht geeignet ist. Sprich das keine Wellen übertragen kann.

Aber ich denke der Link mit dem Beispiel wo es anhand des Morse Codes demonstriert wird ist recht verständlich denk ich. Aber ist halt doof das das Kommunikationsmodell wieder mit Kodierung und Dekodierung beschrieben werden. xD

Gleiches mit Verkehrsschildern.
Kennt man deren Bedeutung nicht, kann man mit dem Verkehrsschild nix anfangen. Kennt man es fängt das Gehirn an das Schild zu dekodieren bzw. zu entschlüsseln und einem den Informationsgehalt zu geben. Aber um dies zu können muss man erst mal die Informationen den den Schildern zugeordnet ist erst mal wissen. Vorher kann man es nicht verstehen. Man kann aber auch raten was sie bedeuten.

Zitat von AstroLamb

"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 https://de.wikipedia.org/wiki/Verschl%C3%BCsselung unter Grundlagen und unter Verschlüsseln das finden.

Ich zitiere mal die Passage:

Zitat von Wikipedia

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.

Zitat von RealLiVe

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.

Zitat von AstroLamb

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: https://de.wikipedia.org/wiki/Kodierer

@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.

Zitat von banda

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.

Zitat von banda

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.

Zitat von banda

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.

Zitat von Julien

Bilder einbetten ist nämlich laut DSGVO ab dem 25. Mai nicht mehr ganz so unproblematisch, weswegen der Admin das kurzerhand deaktiviert hat.

Warum sind dann die Avatare noch drin? Sind das denn keine Bilder?

Zitat von 1000kcirtap

Man möchte halt jene schützen die sich nicht schützen können oder aber zu doof dafür sind. Letztere sind jene die jedes Detail ihres Lebens teilen und sich hinterher darüber aufregen wenn sie Dubiose Anrufe bekommen oder ihre Daten verkauft wurden.

Hmm... also wenn man wirklich so einen DAU vor sich hat, meinste nicht das er allein schon wenn er ein reales Foto von sich oder wo er mit Freundin/Freund zu sehen ist ein Stück von sein Leben mit anderen teilt? Wie z.B. ein Avatar?

Also wenn das LPF das schon durchzieht, dann bitte richtig. xD