Wenn man die AR-Flags korrekt setzt, dann sollte je Player, egal ob Software oder Hardware, AR-Informationen berücksichtigen...
Echt echt?
Tja, wenn dem wirklich so sein sollte, dann werd ich mich wohl am Wochende mit dem richtigen Setzen von AR-Flags mal konkreter beschäftigen ...
Besten DANK jedenfalls für die Infos!
Bei der zweiten Möglichkeit gehen zwangsläufig Details verloren, was sich vor allem im Vollbildmodus (und noch stärker auf einem "großen" Bildschirm) sehr wohl sichtbar auswirken kann!
... wenn du es anamorph belässt und das Resizen ganz sein lässt. Aber das willst du ja offensichtlich nicht tun...
Nur gut, dass du kurz das Thema mit den "großen Bildschirmen" angeschnitten hast:
Finde leider das Posting nimmer, jedenfalls hat mal jemand berichtet, dass er sich einen Beamer zugelegt hatte, und dann seine nach der "klassischen Methode" gekodeten Filme auf der Leinwand angucken wollte. Tja, was meint man wohl, wie begeistert er war?
Eben nicht wirklich: Er meinte noch, er legte dann die Original-DVD ein, und da sah die Welt auf der Leinwand wieder ganz anders aus, als mit den klassischen Backup.
Ich würde demnach schätzen, dass bis etwa 40" Bildschirme (mit angemessener Seh-Entfernung) die klassische Methode noch "o.k" sein dürfte, denn auf meinem 32" TV, ist sie jedenfalls noch definitiv, selbst wenn ich mit 50 - 70cm Abstand das Video angucken würde. Allerdings die Sache mit Beamer & Leinwand - wird klassisch nicht wirklich was taugen ...
Man könnte also sagen, wenn man anamorph kodiert, müsste es sogar mit Beamer & Leinwand klappen - theoretisch.
Wie sieht derzeit eigentlich die AR-Flag-Unterstützung bei den Player-Software oder gar Stand-alone-playern aus?
Wenn sich künftig allgemein breite Unterstützung für AR-Flags am Horizont abzeichnen sollte (falls es dies nicht schon tut?) - tja, spricht dann nicht mal für mich noch was dagegen, künftig anamorph zu kodieren ... ;D
Leute, dann danke ich mal für eure Antworten.
Gut, dann fasse ich nochmals kurz zusammen:
In diesem Thread geht es - zur nochmaligen Erwähnung - ausschließlich um das Thema "klassisches Encoding" - und nicht "anamorphes Encoding.
Und für klassisches Encoding heißt das nun also konkret:
1) Einfach OHNE Rücksicht auf Mod16 exakt zu den Bildrändern croppen;
2) Resize mit geeigneter (neuer + entzerrter + Mod16) Auflösung machen; - Fertig!
Warum ich das alles überhaupt gefragt habe - um kurz (selbst) abzuschweifen:
Mir persönlich ist das klassische Encoding vom Bauchgefühl her irgendwie lieber, als wenn ich bei "anamorphen Encoding" manchmal - fast - gezwungen wäre, zu weit ins Bild croppen zu müssen, oder dabei diverse sonstige Tricks anwenden zu müssen. Beim k. E. muss ich also (nunmehr Gewissheit) nur exakt zu den Bildrändern hincroppen, darüber hinaus jetzt auch die Gewissheit, eine etwaige Unsymetrie (oben od. unten 1-2 Pixel mehr od. weniger) unberücksichtigt lassen zu können, und somit bleibt zumindest mal das vollständige Videobild erhalten.
Das ein Resize zwar gewisse Nachteile (Detail-Verlust?!) mitbringen soll, insbesondere bei vertikaler "Schrumpfung", ist mir zwar bewusst/bekannt, allerdings ob DAS in der Tat solche "gravierenden" (sichtbaren) Auswirkungen hat, bezweifle ich allerdings:
Hat jemand mal Tests gemacht (klassisch vs. anamorph Enc.) und dabei einen "Detail-Verlust" beim klassischen Encoding feststellen können?
Na das möchte ich mal gesehen haben, ob man das echt merkt. Also ich glaubs jedenfalls nicht. Denn entscheidender ist dabei vielmehr - denke ich zumindest - der richtige Einsatz von Resize-Filtern und vor allem das A und O - die optimalen Codec-Konfigurationen - und das wär's auch schon.
Eine Frage ist mir gerade noch eingefallen - die Reihenfolge:
Ich bilde mir ein schon mehrmals wo gelesen zu haben, dass manche meinen, dass man zuerst das Resize machen soll (??) und dann croppen. Das denke ich aber weniger ...
Ich würde meinen, immer zuerst croppen, und DANN das Resize inkl. Entzerrung machen - oder?
Somit wäre wohl die richtige Reihenfolge bei Einsatz von Filtern:
1) Croppen
2) Resize
3) Event. Sharpen
4) Event. Glätten (smooth)
5) etc
Und in Hinblick auf das 2-pass Encoding, das alles noch VOR dem 1.pass ...
Richtig?
... Falls du aber nur in einer Dimension resizen wirst, dann solltest du in der Dimension, in der du nicht resizen willst, schon beim Croppen auf Mod16 achten. ...
Zunächst danke!
Ehm, bist du ganz sicher?
Diese Ausführung ist mir jedenfalls jetzt ganz neu - ehrlich gestanden.
Ich zumindest weiß ja nicht, ob und wie für ein "klassisches Encoding" das Cropping mit dem Resize im Zusammenhang steht. Denn ich würde - als Laie - glatt meinen, dass es völlig egal ist für welche Dimension die Mod16 beachtet werden muss - also weder für eine, noch für beide Dimensionen beachtet werden muss beim Crop mit anschl. Resize. Oder anders ausgedrückt:
Das eine ergibt ja ohnehin das andere. Denn wenn nach dem Cropping sämtlicher Balken (o/u/li/re) bsw. noch 714x430 über bleiben (also weder B noch H Mod16), so würde in dem Fall (z.B. 2.35er Film) ein Resize auf 720x304 od. 704x304 in Frage kommen - also mit Mod16-Berücksichtigung beim Resize.
Heißt also, irgendeine Horizontale (z.B. 714 od. 710 etc) nach dem Crop vollständig zu erhalten wollen (außer z.B. 720 od. 704), spielt sich ohnehin nicht.
Oder noch einfacher ausgedrückt:
1) Einfach OHNE Rücksicht auf Mod16 exakt zu den Bildrändern croppen;
2) Resize mit geeigneter (neuer + entzerrter + Mod16) Auflösung machen; - Fertig!
Sehe ich das richtig?
Dann wäre da noch etwas:
Manchmal kommt es ja vor, dass z.B. unten oder oben im Bild einige (2-3) Pixel-Reihen oft mehr weggecroppt werden müssten, damit man schön "gleichmäßig" oben/untern oder links/rechts bleibt.
Wo steht geschrieben, dass es "gleichmäßig" sein sollte, wenn danach ohnehin ein Resize geplant ist? Muss es überhaupt "ausgeglichen" sein?
Gibt es in dem Sinne Bezugspunkte bzw. muss nach Crop alles irgendwie "zentriert" bleiben? Tja, ich weiß das alles leider nicht ...
Hallo!
Habe nach der Antwort zur Titel-Frage schon gesucht, nur sicher bin ich mir noch immer nicht ... 
Klassisches Encoding (nicht-anamorphe Methode):
Wenn man ohnehin die "klassische Methode" für's Encoding wählt, also die Auflösung via Resize geändert werden soll, muss dann dennoch schon beim Cropping die Mod16-Regel beachtet werden oder nicht?
Ich denke halt, wenn man ohnehin ein Resize macht, dann wird man ja wohl nicht umsonst wertvolle Pixel-Reihen wegschneiden (müssen) - oder?
Ich vermute mal, es sollten zumindest gleich viele Pixel-Reihen oben/unten und ggf. links/rechts weggenommen werden müssen - aber sicher doch nicht mehr, als nötig ist, wenn man ohnehin ein Resize macht.
Oder muss dennoch z.B. zumindest Mod4 etc. beim Cropping beachtet werden?
Wäre dankbar für eine Antwort/Info.
Grüße!
nightwalker
P.S: Z.B. StaxRip zeigt demnach (Mod16 beim Crop nicht berücksichtigt) eigentlich immer einen falschen (höheren) AR-Fehler an (!?) ...
Aha - sehr gut. Muss mich erstmal am Wochende etwas eingehender mit StaxRip beschäftigen - bin schon neugierig wie's mit dem Zeug konkret läuft. Danke jedenfalls.
Genau genommen muss er sich eigtl. gar nicht damit beschäftigen. Die Frontends erkennen das AR bei Standardmaterial recht zuverlässig und rechnen standardmäßig in quadratisch um. Das passt i.d.R. sehr gut zu dem, was der Anfänger haben möchte.
Deine Frage ganz oben war, ob die AR-Optionen in den Encoder-Dialogen zu einem Resizing führen. Deine nächste Frage war nach der Funktionsweise des Resizing-Dialogs in VDub. Ein ziemlich eindeutiger Themenwechsel, findest du nicht …
Danke Brother John! Mit ersten Absatz hast du mir eine wichtige Frage beantwortet. O.k. mit 2. Absatz (abweichen) habt sowohl du und Selur recht. Aber nach dem Posting-Wirr-Warr wollte ich lediglich ein konkretes Beispiel zu einem Fall etwas näher beschreiben. Wie auch immer:
Das wollte ich nämlich schon immer wissen, ob denn mittlerweile nicht Frontends "fähig" sind schon beim Parsen zu erkennen, um welches Material es sich handelt, und demnach dem Anfänger (automatisiert) Vorschläge macht. Die Frage, die sich mir dabei noch stellt, ob das Teil auch dementsprechend auf bestimmte Werte oder die ganze analog/digital-Problematik "getrimmt" ist, und somit die Vorschläge auch ganz gut und brauchbar sind, als wenn man das "zu Fuß" (also manuell anhand Tabellen etc) machen würde.
Also ich hab zwar schon mal StaxRip installiert, muss mich aber erst mal mithilfe deiner Anleitung damit etwas vertrauter machen. Wäre also z.B. StaxRip für mich als Frontend gefragter, damit ich künftig nicht länger jemanden am Nerv gehe muss und mir somit selber einen Gefallen mache?
Dank im Voraus!
hm, also wundern tut es mich nicht, dass die meisten Leute lieber auf Drag&Drop-Methoden via DivX zurückgreifen. Hat ja schließlich nicht jeder vor wegen ein paar Video-Files zu kompressen gleich ein Informatik-Studium zu betreiben oder die Sache zu einer Lebensaufgabe zu machen .
Eine Sache (Auflösungen/Seitenverhältnisse), die IMHO mehr aufgebauscht wird, als unterm Stich eigentlich notwendig ist. Ein Anfänger will schließlich nur eine paar grundlegende Dinge zu dem Thema wissen wie "welche Seitenverhältnis gibt es (Standard etc), und welche sollten es letzlich sein bzw. worauf gilt es in welchem Fall zu achten." - Mehr will ja Otto-Normalverbraucher nicht wissen. Denn der ganze Rest ist dann meist ohnehin (mehr od. weniger) immer Routine.
Und nein, wüsste nicht irgendwo auch nur 1mm von Haupt-Thema (Cropping/Resize) abgewichen zu sein, denn diese Dinge stehen halt immer im Zusammenhang mit AR/FAR/DAR/PAR. Und somit lassen wir es halt gut sein.
Alles semantisch genug für dich? :ani_lol:
Puh, hm, mal versuchen das Pferd von hinten aufzuzäumen …
Selur, @didee, Brother John – mir ist schon schon klar, dass ihr kein Anfänger seid, und ich bin schon froh, wenn ich so inetwa 10 – 15 Jahren mal so einigermaßen mit euch mithalten kann. Hilft aber nix, die Postings hier sind nur mehr reinstes Wirr Warr für einen Anfänger …
Stichwort Anfänger vs. Profi:
Euch ist doch sicher der Name Avery Lee bekannt, also der Ur-Entwickler von VirtualDub.
Soweit mir bekannt ist, ist VirtualDub schon knapp 10 Jahre „am Markt“. Avery Lee scheint aber auch nach wie vor die „Ur-Version“ von VirtualDub zu hegen und zu pflegen, und er ist auch nach wie vor im „Inoffiziellen VirtualDub-Forum“ recht aktiv. Er selbst hat auch mir schon persönlich dort bei kniffligen Dingen geholfen.
Wie auch immer:
Am Anfang stellte ich mir z.B. die Frage, WIE eigentlich der interne Filter RESIZE von VirtualDub funktioniert. Denn irgendwas „schien da nicht zu stimmen“ - meiner Meinung nach.
Ich hatte also anfangs bei Aspect ratio nämlich immer einfach entweder 16:9 oder 4:3 eingegeben – was so aber nicht wirklich funktioniert …
Ich war dann auf der Suche nach Antworten, und zwar,
WIE der interne VirtualDub-Filter >Resize< eigentlich funktioniert:
[Blockierte Grafik: http://img21.imageshack.us/img21/4540/filterresizegr2.jpg]
Tja, und WER könnte das wohl besser beantworten, als sein Schöpfer selbst – nämlich Avery Lee, denn der interne VirtualDub-Filter, IST ja schließlich sein „Kind“.
Ich wurde also fündig nach der Antwort zu meiner Frage, und fand HIER Folgendes:
Bei den letzten User-Kommentaren ganz unten, hatte letztes Jahr jemand (u.a.) diesbezüglich angefragt (das war nicht ich!) und hat da irgendwas von „PARs“ gefaselt …
Tja, und die Original-Antwort darauf von Avery Lee (Phaeron - 05 12 08 - 04:15) könnt ihr ja dort selbst lesen. Ich hol dazu mal einfach hier sein Posting rein, und werde es einfach mal etwas für’s bessere Verständnis – inkl. in [xxx]-Klammern kleine Ergänzungen von mir - „entzerren“:
Er...
First of all, the dialog only accepts frame aspect ratio [FAR], not pixel aspect ratio [PAR]. You can use the resize filter to adjust for changes in PAR as well as it's the same resampling operation either way, but the dialog won't really help you do that as it works in frame aspect [FAR].
The way the current resize filter works is
- that it resamples the image to the size specified in the top half and
- then converts it to the frame size in the bottom half, if they differ.If you choose 4:3 in the size portion, then you'll get the image stretched to 768x576 with the resampling filter you specify. If you choose 4:3 in the framing options, then you'll get the 720x576 image just copied over with black bars on the side. You can also mix the two to get a blend of both resampling and letterboxing or cropping.
As for the resampling itself, it's the same bog-standard point sampling, bilinear, or bicubic filter kernels you'd find anywhere else. The continuous filter kernel is offset by the desired source offset, sampled according to the positions of the source pixels it overlaps, and then the source pixels are weighted and blended according to the kernel. Phaeron - 05 12 08 - 04:15
Achtet u.a. genau darauf, WIE Avery Lee (und der ist nicht wirklich ein Anfänger!) die Sache mit dem FAR und PAR dabei verklickert!
Jedenfalls, aus diesem Posting wurde ich bisher am meisten schlau, denn GENAU SO läuft das auch! Was ich allerdings damals aber nach wie vor NICHT wusste war, und zwar, was ich nun aber KONKRET beim Feld „Aspect ratio“ eingeben sollte …
Nach Hirn-Einschalten fand ich es schließlich raus:
Dort ist bei verzerrtem MPEG-2-Material (z.B. DVD) schlicht und einfach das richtige DAR der Quelle anzugeben! Und das ist eben NICHT das grundlegende Anzeigen-Verhältnis 16:9 oder 4:3, sondern entweder:
1.33:1 / 1.78:1 / 1,85 / 2.35:1 / 2.40:1 – jedenfalls, das exakte DAR des Originals OHNE etwaige schwarze Balken links/rechts!
Wenn man das Original-DAR des Videos nicht weiß:
DANK Brother John weiß ich es, wie ich es (näherungsweise) ermitteln kann. Denn ich muss ja dazu nur die zur Wiedergabe korrekte horizontale Auflösung berechnen (also als nach PAR nach MPEG-4-Tabelle), und komme so zumindest NÄHERUNGSWEISE an den Wert des Originals. Zumindest weiß ich so, was es ganz KONKRET nur sein kann. Tja, dieses konkrete Original-Video-DAR (z.B. 2,35:1) gebe ich dann wie am Bild oben dargestellt bei Aspect ratio ein – alle Standard-Einstellungen in Xvid blieben (square), und was glaubt man wohl, was als ERGEBNIS rauskommt?
So wie es aussieht (4 versch. Beispiele bis jetzt), ein offenbar EXAKT entzerrtes Video!
Woher ich das wissen will?
Na ganz einfach: Ich verwende den ZoomPlayer, und bei dem z,B. via die [R]-Taste auf der Tastatur, kann ich ja beim ZP verschiedene DARs einstellen. Mein Monitor vor der Nase hat eine Anzeigen-Auflösung von 1024x768. Der Monitor selbst (19Zoll) ist 4:3. Am PC hängt aber noch (via DVI) der 32Zoll LCD-TV dran, welcher wiederum ein 16:9 Verhältnis hat. Meine Grafikkarte muss in dem Fall zwar quasi eine Luftakrobatik machen (Klone-Modus) – ABER: Wenn ich dem ZoomPlayer sage, es soll das DAR der Quelle zeigen („Quelle“), tja, bei beiden Anzeigen-Geräten (4:3 / 16:9) ein völlig entzerrtes u. ganz offenbar korrektes Video-DAR – und das auf Anhieb!
Ergo, es wurde also ein Video produziert, welches „quadratische“ Pixel hat ("changes in PAR as well as it's the same resampling operation either way"), und somit in einer Umgebung mit quadratischen Pixeln auch entzerrt und korrekt dargestellt wird.
Ich hätte z.b. bei obigem Beispiel KEINE Resize-Filter genommen (also anamorph belassen, und OHNE Flag), und hätte dem ZoomPlayer halt dann auf 2,35:1 gestellt – Ergebnis: Na ja, einigermaßen „2,35:1“ – aber nicht wirklich eines.
FAZIT:
Auf oben beschriebene Weise, kommt man offenbar auf das recht „exakte“ DAR wie es sein sollte. Alles andere interessiert somit eigentlich nicht …
Die Frage ist halt noch, WIE läuft das bei anderen Frontends bzw. Resize-Fillter, z.b. StaxRip? Hm, muss ich erstmal testen …
Mag schon sein, dass ich hier vielleicht dem einen oder anderen sicher nix Neues erzähle – für andere vielleicht aber doch.
P.S: ich werde bei Gelegenheit versuchen das Start-Posting hier zu einer kleinen „FAQ“ umzubauen. Also nix weiter wie die Fragen belassen (vielleicht mehr präzisieren) + die „richtigen“ Antworten dazu. Und IHR checkt das halt dann ...
Was für ein wirr
quadratische Pixel dann wird die Auflösung natürlich umgerechnet.
Und das war's, was ich eigentlich wissen wollte.
Heißt also, sobald z.B. dem Xvid gesagt wird, er soll es Standard (square) machen, dann wird IMMER umgerechnet - egal welche Auflösung ich neu wähle oder sie belassen würde - sofern hier natürlich die ganze Zeit von DVD-Quell-Material (MPEG-2-Streams) die Rede ist, und von meiner Seite auch ist.
Selur:
ehm, du hast das mit Encoder u. Filter wohl so bei mir verstanden, dass diese beiden für mich dasselbe sind. Dass das 2 Paar Schuhe sind, das weiß ich. Was ich aber nicht genau weiß, und wie sollte ich auch, ist dessen konkrete (zumind. grobe) vorgehensweise, und eben welchen Einfluss es dann auf dieses oder jenes hat. Eben z.b., wenn alles umgerechnet werden muss, interpoliert werden muss, wird halt nicht immer zum besten Ergebnis or gar zu Fehlern führen - so in die Richtung meine ich das.
" Indexierungsinformationen nicht verfügbar "
Ich habe keine Ahnung was das ist, und wie ich diese Indexierungsinfo in die Xvids reinbekomme.
Versuchs mal mit DIESEM Zeug. Ist voll einfach und macht genau das was du brauchst - und das ratzfatz. Hatte auch schon mal das Problemchen ...
Danke selur!
O.k. dann war ich soweit auf der richtigen Fährte.
Ob nun DivX oder Xvid (arbeite mit Xvid) - FRAGE:
Egal welchen MPEG4-Codec ich zum Encoden verwende, und ich belasse die Standard-Einstellung (Square), und ob ich nun den Resize-Filter verwende oder nicht, und wenn ich beim Input-Material "RECHTECKIGE" Pixel habe, das Bild also verzerrt ist, so macht der Codec daraus schlicht und ergreifend "QUADRATISCHE" Pixel beim Output-Video. Gut. O.k.
Und wenn er das tut, und ob dann nun bicubic oder Lanczos etc als Filter für die interpol., der Codec bzw. Filter lässt dann keinen "Stein" (Bild-Pixel) auf dem anderen. Damit meine ich, JEDES einzelne Bild-Pixel ("Bitmap") des Video-Bildes (in welcher Form er das konkret codiert interessiert mich gar nicht) wird jedenfalls vom Codec "bearbeitet". Und zwar JEDES, auch das Mitten im Zentrum des Video-Bildes, es bleibt also nichts am Fleck wie es beim Input-Video mal war - besonders dann (aber eigentlich egal), wenn ich die ursprüngliche Bildauflösung (egal welche) z.b. stark verkleinere.
Ich würde mich schon über ein klares JA! oder NEIN! freuen ...
========
Danke MegaDeath.
1) Falsch. Die Abspielsoftware führt die Größenänderung gemäß des DAR/PAR durch, NICHT der Encoder.
Hi - und danke!
Aus deiner Antwort, die eigentlich nur richtig sein kann, kann ich also schlussfolgern, dass NUR beim Einsatz eines Resize-Filters "kein Stein auf dem anderen bleibt". Richtig?
Heißt also, Cropping alleine bewirkt KEIN gesamtes "Resize", bei welchem ALLE Bild-Pixel dann (quadratisch) umgeformt werden - richtig?
Und dass dabei (resize), sobald dieser mal eingesetzt wird, in der Tat kein einziges Bild-Pixel mehr am anderen bleibt (also ALLE Bildpixel neu angeordnet/interpoliert/skaliert wird), ist doch richtig - oder?
Das wäre noch gut zu wissen, wie das konkret läuft, denn dann wäre soweit alles klar.
-------------
Nachtrag:
Ooops, das kann aber doch nicht stimmen was du sagst - zumindest, kommt darauf an:
Hab grad geguckt: Der Xvid-Codec ist IMMER voreingestellt für quadratische Pixel (shape of a pixel). Heißt also, selbst wenn ich NUR croppe, macht er alles QUADRATISCHE Pixel bei meinem Ausgabe-Video. Der Software-Player (z.B. Zoom Player), würde im Fall 1) lediglich für die Entzerrung des auf quadratischen Pixeln bestehenden Videos sorgen. Er würde also nur das FAR richtig stellen, nicht aber das PAR (das kann der so gesehen gar nicht) - falls ich nicht irre...
Tag zusammen!
Da ist mir jetzt eben so ein verwegener Gedanke gekommen, wobei ich allerdings denke, dass der gar nicht mal so verwegen ist.
Fragen an die Codec-Experten ...
... dabei spielt es im Prinzip keine Rolle, von welchem Codec (DivX, XviD etc) die Rede ist:
Beispiel:
Das Quell-Video hat eine Bild-Pixel-Auflösung von 720x576 – „klassisch“ (PAL) also.
Egal ob ich nun die Mod16-Regel beim Cropping der schwarzen Balken nicht einhalte oder vielleicht doch „codec-friendly! die Mod16-Regel beim Cropping beachte, so komme ich z.B. NUR durch das Cropping auf eine neue Bild-Pixel-Auflösung von 720x336.
Dass NUR durch das Cropping die Sache ZUFÄLLIG „codec-friendly“ ist, spielt für mich zunächst keine Rolle, jedenfalls wollte ich ja von vorne herein keinen RESIZE-Filter verwenden. Zudem setzte ich knallhart nicht mal ein AR-Flag – z.B. ganz nach dem Motto „der Zoom Player bügelt mir schon das >richtige< AR hin.
Nun die geistreichen (Anfänger-)Fragen:
1) Allein durch den Umstand, dass sich durch das Cropping nicht nur das DAR des Video-Bildes geändert hat (von 1,25:1 zu 2,14:1), sondern auch das FAR von 720x576 zu nunmehr 720x336 - findet dann bei der Kompression INTERN dennoch ein „Resize“ samt allem Drum und Dran statt, obwohl ich direkt keinen Resize-Filter beauftrage?
Richtig oder falsch?
2.) Falls 1) richtig, dann findet INTERN ebenso auch eine Neu-Skalierung + Interpolation der Bild-Pixel statt, was grob heißt, es bleibt beim Encoden so oder so nie ein Mosaik-Steinchen auf dem anderen, denn das Video-(Raster-)Bild wir ja ohnehin komplett in seine Einzelteile zerlegt, und in einem (neuen) Bitmap-Raster (Bild-Pixel-Raster) intern neu zusammengewürfelt, bzw. neu „aufgelöst“.
Richtig oder falsch?
3.) Falls 2) u. 3) richtig, dann hätte ich unter Umständen so oder so IMMER Bildrauschen im Video-Clip, und mit einem RESIZE-Filter gebe ich dem Codec ledglich manuell bekannt - nachdem er ohnehin vor hat „die Karten neu zu mischen“, er solle dabei z.b. meinen Wunsch berücksichtigen, dass unterm Strich eine Bild-Auflösung von z.B. 720x304 rauskommen soll.
Richtig oder falsch?
4.) Ich ignoriere auch noch z.B. das „harte Kanten“-Problem, und sage dem Codec, dass die Auflösung gleich wie das Quell-Video sein soll. Falls 1) u. 2) u. 3) richtig sind, werden vom Codec auch in diesem Fall die Karten SO ODER SO „neu gemischt“ – nur dass er hierbei vielleicht mehr zu tun bekommt, da ja mehr Pixel zu bearbeiten sind, und auch die „harte Kante“ - wenn schon - dann sauber erhalten bleiben soll. Jedenfalls, der Codec macht in diesem Falls aus 720x576 rechteckigen Pixel lediglich 720x576 quadratisch Pixel. Schrumpft somit ohnehin ganz konkret die Video-Auflösung etwas.
Richtig oder falsch?
Im Klartext:
Egal was und wie ich was mache, beim Encoden bleibt ohnehin NIE ein Stein auf dem anderen, und dabei spielt es auch keine Rolle mehr, ob ich z.B. eine Resize-Filter verwende oder nicht – heißt, Gefahr zum „Bildrauschen“ laufe ich so oder so. Also würd's keine Rolle spielen, ob ich gleich nen Resize-Filter nehme oder keinen verwende.
Richtig oder falsch?
Da ich nicht in einen Codec reingucken kann, auch seine Vorgehensweise bzw. sein Arbeitsweise NICHT genau kenne, sind obige Fragen doch irgendwie berechtigt – oder?
Es sei denn, ich hab das irgendwo bei "Häufig gestellte Fragen" übersehen - dann sorry ...
Jedenfalls,
besten Dank im Voraus für Aufklärung + vielleicht kurze Hinweise!
Doppelten DANK Selur,
denn habe mir dein Xvid-Fachwissen natürlich auch eingezogen.
Zu deinen Anmerkungen:
Jep – so hab ich mir das vorgestellt. Und gleich vorweg: Du hast gut mit jedem Punkt recht.
Möchte jetzt aber gar nicht einzeln auf diese Punkte eingehen, denn hab’s mir in der Zwischenzeit etwas anders überlegt. Damit meine ich, es wäre sicher besser, doch ganz einfach die Katze aus dem Sack zu lassen, anstatt um den Brei reden. Nur weiß ich jetzt gar nicht so recht, WO oder WIE ich am besten anfangen sollte - hmm …
===============================
Na ja, am besten irgendwo schnurstracks rein in den Gemüsegarten und gleich zu den Fakten:
DIESER gute Mann hier,
war einer von den ganz wenigen – eigentlich der Einzige – der ihn VOLL geschnallt hat – nämlich den FETTEN Wurm in einem echt üblen Süppchen!
... mir bei wiederholtem Lesen der Anleitung von Brother John doch eine Ungereimtheit in dem Kapitel zum anamorphen Encoding aufgefallen, die zumindest mir anfangs viel Kopfzerbrechen bereitet hat. ...
... Das ist in dieser allgemeinen Form IMHO schlichtweg falsch, denn es gilt nur bei digitaler Ausgabe. Auf analogen Fernsehern ist das PAR außer bei 768x576 und 720x540 NIE 1:1, wenn ich dieser Quelle glauben darf: ...
Was der Anleitung an dieser Stelle fehlt, ist der deutliche Hinweis darauf, dass man sich zuerst entscheiden muss, ob man primär für digitale oder analoge Ausgabe encodiert ...
... Auch würde ich statt des Akronyms DAR lieber FAR (Frame Aspect Ratio) benutzen, denn das DAR ist ja immer 4:3 bzw. 16:9.
Tja, lieber duebel13,
da hast du dich auch nirgends auch nur 1 Millimeter geirrt! Und vertrauen kannst du dieser QUELLE geradezu Wort für Wort!
Im Übrigen handelt es sich dabei um einen (Ex-)Studenten (von 2002 bis 2007/08) von der Universität Vaasa in Finnland. Und deine Quelle ist auch nach wie vor dort gehostet und wird auch nach wie vor vom Autor gepflegt.
Warum „Wort für Wort“?
Hab jetzt echt ganz genau null Bock HIER näher darauf einzugehen …
Jedenfalls bald darauf Brother John als ANTWORT:
Hi, duebel13.
....
Deswegen sind solche Seiten wie der von dir erwähnte "Quick Guide" zwar hochinteressant (wenn mir von so Zeug auch regelmäßig der Kopf raucht), für den praktischen Gebrauch aber irrelevant und höchstens dafür gut, Verwirrung zu stiften.
....
Ich bin deswegen ganz klar dagegen, den Analog/Digital-Unterschied weiter herauszustellen...
Brother John:
Von „so Zeug“ hatte dir damals regelmäßig der Kopf geraucht?
Na was meinst du wohl wie mir, und GEWISS vielen anderen der Kopf bei DEINEM Zeug geraucht hat. Eh?
Und ja, GANZ GENAU so ist es aber: nämlich anstatt in deinem Tut so oft das Wort „anamorph“ zu gebrauchen, solltest du lieber ÜBERALL das Wort „anamorph“ besser durch „analog“ ersetzen – bevor noch ganz andere (harmlose) Leute wie ich „schreiend die Beine in die Hand nehmen“!
Wie auch immer – irgendwie ist ja wohl zu erkennen (auch für Blinde), dass dieser Link zum „Quick Guide“ B.J. damals nicht wirklich geschmeckt haben muss (aus mehrerlei Gründen), aber andererseits doch irgendwie/irgendwas etwas passiert sein muss, und zwar 1 Monat später dann …
Update! Und was für eins.
…
Außerdem neu
Anamorph-Kapitel komplett umgebaut…
Puh, da möchte ich gar nicht wissen, WIE wohl vorher das Anamorph-Kapitel erklärt wurde. Jedenfalls, von 10 Leuten, sagen mindestens 10 Leute, dass ab HIER (Anamorph-Kapitel) geradezu jeder Satz die reinste Satz-Luftakrobatik ist! Und von den Rechteck- und Quadrat-Pixel-Erklärungen, fang ich lieber gar nicht zu erwähnen an. Interessanter Weise allerdings im Gegensatz zum Rest des Tuts so rundherum, denn das ist soweit so gut alles tadellos – größtenteils sogar sehr gut und useful.
Kurzum:
Also ich würde KEINEM Anfänger Brother Johns Encodingwissen empfehlen, bestenfalls unter der Bedingung, dass diese Leute im Kapitel „Anamorph & Co“ es aber ja nicht wagen sollten auch nur 1 einzigen Satz dort zu lesen!
Denn das kostet für nix und wieder nix echt nur eine Menge VERLORENE ZEIT, und ebenso für nix und wieder nix einfach nur NERVEN – zumindest wer genau dort wie ich zwangläufig in den vollen Bulls… -Fettnapf tappt. Ein Fettnapf, den es ANDERE innerhalb nur weniger Zeilen schaffen (eigentlich nur mit 2 Begriffen), völlig plausibel und vor allem RICHTIG zu verklickern, damit ein Anfänger den (sehr wohl wichtigen) Part dann auch gleich mal als gelesen und verstanden abhaken kann.
Und soll bloß nie mehr einer sagen, dass man einem geschenken Gaul nicht genauer ins Maul gucken soll - denn die Tierarztkosen können im Verhältnis wieder teuer kommen - in dem Fall in Form viel verblasener Zeit für nix ...
Brother John,
bitte nicht übel nehmen, aber vielleicht checkst für dich zunächst mal selbst die Sache, und glättest ja mal bei Zeiten dunkle Wolken in deinem Tut, weil wär ja sonst glatt schade im Verhältnis zum Rest des Tuts.
Doppelten DANK Selur,
denn habe mir dein Xvid-Fachwissen natürlich auch eingezogen.
Zu deinen Anmerkungen:
Jep – so hab ich mir das vorgestellt. Und gleich vorweg: Du hast gut mit jedem Punkt recht.
Möchte jetzt aber gar nicht einzeln auf diese Punkte eingehen, denn hab’s mir in der Zwischenzeit etwas anders überlegt. Damit meine ich, es wäre sicher besser, doch ganz einfach die Katze aus dem Sack zu lassen, anstatt um den Brei reden. Nur weiß ich jetzt gar nicht so recht, WO oder WIE ich am besten anfangen sollte - hmm …
===============================
Na ja, am besten irgendwo schnurstracks rein in den Gemüsegarten und gleich zu den Fakten:
DIESER gute Mann hier,
war einer von den ganz wenigen – eigentlich der Einzige – der ihn VOLL geschnallt hat – nämlich den FETTEN Wurm in einem echt üblen Süppchen!
... mir bei wiederholtem Lesen der Anleitung von Brother John doch eine Ungereimtheit in dem Kapitel zum anamorphen Encoding aufgefallen, die zumindest mir anfangs viel Kopfzerbrechen bereitet hat. ...
... Das ist in dieser allgemeinen Form IMHO schlichtweg falsch, denn es gilt nur bei digitaler Ausgabe. Auf analogen Fernsehern ist das PAR außer bei 768x576 und 720x540 NIE 1:1, wenn ich dieser Quelle glauben darf: ...
Was der Anleitung an dieser Stelle fehlt, ist der deutliche Hinweis darauf, dass man sich zuerst entscheiden muss, ob man primär für digitale oder analoge Ausgabe encodiert ...
... Auch würde ich statt des Akronyms DAR lieber FAR (Frame Aspect Ratio) benutzen, denn das DAR ist ja immer 4:3 bzw. 16:9.
Tja, lieber duebel13,
da hast du dich auch nirgends auch nur 1 Millimeter geirrt! Und vertrauen kannst du dieser QUELLE geradezu Wort für Wort!
Im Übrigen handelt es sich dabei um einen (Ex-)Studenten (von 2002 bis 2007/08) von der Universität Vaasa in Finnland. Und deine Quelle ist auch nach wie vor dort gehostet und wird auch nach wie vor vom Autor gepflegt.
Warum „Wort für Wort“?
Hab jetzt echt ganz genau null Bock HIER näher darauf einzugehen …
Jedenfalls bald darauf Brother John als ANTWORT:
Hi, duebel13.
....
Deswegen sind solche Seiten wie der von dir erwähnte "Quick Guide" zwar hochinteressant (wenn mir von so Zeug auch regelmäßig der Kopf raucht), für den praktischen Gebrauch aber irrelevant und höchstens dafür gut, Verwirrung zu stiften.
....
Ich bin deswegen ganz klar dagegen, den Analog/Digital-Unterschied weiter herauszustellen...
Brother John:
Von „so Zeug“ hatte dir damals regelmäßig der Kopf geraucht?
Na was meinst du wohl wie mir, und GEWISS vielen anderen der Kopf bei DEINEM Zeug geraucht hat. Eh?
Und ja, GANZ GENAU so ist es aber: nämlich anstatt in deinem Tut so oft das Wort „anamorph“ zu gebrauchen, solltest du lieber ÜBERALL das Wort „anamorph“ besser durch „analog“ ersetzen – bevor noch ganz andere (harmlose) Leute wie ich „schreiend die Beine in die Hand nehmen“!
Wie auch immer – irgendwie ist ja wohl zu erkennen (auch für Blinde), dass dieser Link zum „Quick Guide“ B.J. damals nicht wirklich geschmeckt haben muss (aus mehrerlei Gründen), aber andererseits doch irgendwie/irgendwas etwas passiert sein muss, und zwar 1 Monat später dann …
Update! Und was für eins.
…
Außerdem neu
Anamorph-Kapitel komplett umgebaut…
Puh, da möchte ich gar nicht wissen, WIE wohl vorher das Anamorph-Kapitel erklärt wurde. Jedenfalls, von 10 Leuten, sagen mindestens 10 Leute, dass ab HIER (Anamorph-Kapitel) geradezu jeder Satz die reinste Satz-Luftakrobatik ist! Und von den Rechteck- und Quadrat-Pixel-Erklärungen, fang ich lieber gar nicht zu erwähnen an. Interessanter Weise allerdings im Gegensatz zum Rest des Tuts so rundherum, denn das ist soweit so gut alles tadellos – größtenteils sogar sehr gut und useful.
Kurzum:
Also ich würde KEINEM Anfänger Brother Johns Encodingwissen empfehlen, bestenfalls unter der Bedingung, dass diese Leute im Kapitel „Anamorph & Co“ es aber ja nicht wagen sollten auch nur 1 einzigen Satz dort zu lesen!
Denn das kostet für nix und wieder nix echt nur eine Menge VERLORENE ZEIT, und ebenso für nix und wieder nix einfach nur NERVEN – zumindest wer genau dort wie ich zwangläufig in den vollen Bulls… -Fettnapf tappt. Ein Fettnapf, den es ANDERE innerhalb nur weniger Zeilen schaffen (eigentlich nur mit 2 Begriffen), völlig plausibel und vor allem RICHTIG zu verklickern, damit ein Anfänger den (sehr wohl wichtigen) Part dann auch gleich mal als gelesen und verstanden abhaken kann.
Und soll bloß nie mehr einer sagen, dass man einem geschenken Gaul nicht genauer ins Maul gucken soll - denn die Tierarztkosen können im Verhältnis wieder teuer kommen - in dem Fall in Form viel verblasener Zeit für nix ...
Brother John,
bitte nicht übel nehmen, aber vielleicht checkst für dich zunächst mal selbst die Sache, und glättest ja mal bei Zeiten dunkle Wolken in deinem Tut, weil wär ja sonst glatt schade im Verhältnis zum Rest des Tuts.
-----
/Edit
Mod-Info von Brother John: Ich habe der Übersichtlichkeit halber für die Knowledgebase die entspr. Postings aus dem Encodingwissen-Thread hierher kopiert. Damit’s übersichtlich bleibt, Thema Knowledgebase bitte hier, Thema EW-Feedback im EW-Thread. Danke!
-----
Tag zusammen!
Tja, nachdem ich es geradezu versprochen habe und noch in der Zeit liege …
... Hoffe bis spätestens kommenden Sonntag gegen Abend ...
Um mich so kurz wie möglich zu halten, gleich die Fakten bzw. zuvor aber schnell noch zur Story „DIE fabelhafte Encoding-Welt des nightwalker …“
Es hat also jemand vor geraumer Zeit – konkret ein Encoding-Newbie – „verzweifelt?“ nach Infos für das RICHTIGE Encoding gesucht, und stieß schließlich eines Tages über versurfte Umwege auf Brother John’s (i.F. „B.J.“ abk.) „Encodingwissen“ (EW).
Dieser jemand war schließlich auch gleich recht schnell entzückt (Gestaltung, Lesbarkeit, Schreibstil, Info etc), alleine schon von all den echt guten, motivierenden und einleitenden Erklärungen – zumindest bis zu DIESER Stelle.
Wie man also auf DIESEM gescannten und völlig „unzensierten“ Bild sehen kann, da hat also jemand zunächst vielleicht gedacht, …
"Wofür braucht man PDF und Papier?"
weil es auch Leute gibt die gerne offline Guides lesen
Cu Selur
… genau so ist es!
Denn hier wird es langsam „haarig“ – obwohl vom Autor vorgewarnt. Denn speziell bei diesem Kapitel musste sich der Leser wohl gedacht haben „Es lässt es sich in Offline-Form wohl wesentlich bequemer auf ner Couch LÄNGER grübeln und brüten!“ Allerdings dürfte da jemand wohl mehr als nur gerübelt und „gebrütet“ haben, wie man so ganz allgemein am BILD erkennen kann – und dazu muss man auch kein sog. „Profiler“ sein. Jedenfalls, und das alles schon bei diesem einleitenden Kapitel-Abschnitt. Was am BILD u.a. noch besonders auffällt, ist, dass der Leser z.B. immer das Wort „Auflösung“ mit Leuchtstift markiert (7x) hat. Dieses Wörtchen muss es ihm aus irgendeinem Grund offenbar ganz besonders angetan haben – das Warum, bleibt zunächst offen.
Unterm Strich erkennt man am BILD ebenso eindeutig, dass es jedenfalls ganz danach aussieht, als ob da jemand nicht nur mit irgendetwas, sondern gleich mit mehreren Begriffen, Dingen und Sachverhalten ganz offenbar fürchterlich zu kämpfen hatte.
Der Leser, dessen Gehirn mittlerweile schon recht aufgeweicht war, dachte sich offenbar, „Na ja, dann halt schnell mal ein paar >>Wissensdefizite<< ausbügeln, indem man halt ganz einfach über’s Web…“ - seiner Meinung nach - … „die besten Definitionen von z.B. von >>Auflösung<< einfach mal sucht!“
Der Leser machte dann offenbar eine GEGENÜBERSTELLUNG der gefunden Definitionen, und zwar offenbar in der Hoffnung, gewisse „Wissensdefizite“ auf diese Weise schneller oder besser in den Griff zu kriegen. Allerdings wurde dem Leser beim Lesen und dem Versuch zu verstehen der gefundenen Definitionen, das Gehirn noch weicher (als es ohnehin schon war), und muss sich beim Lesen DIESER DEFINITIONEN von „Auflösung“ wohl schon langsam gedacht haben „Ja, spinn’ ich jetzt komplett?“ – und „löste“ sich lieber wieder voll und ganz in B.J’s-Encodingswissen „auf“.
Was allerdings auch keine so besonders gute Idee war:
B.J’s-Beispiel „Die fabelhafte Welt der Amelie“ schien geradezu zu einer „NOT-GEBURT“ (in übertragenem Sinn) auszuarten an (mögliche Varianten am PC visualisieren), denn der Leser, Grübler und Studierer, versuchte ganz offenbar das im EW vorgeführte Beispiel insofern für „bare Münze“ zu nehmen, denn schließlich las er im EW recht häufig Begriffe und Phrasen, wie etwa „Auflösung schrumpfen“ oder „das beschneidet das Bild“, „verwirft keine Informationen“ oder „enthalten diese 45% zusätzliches Bild genau 0% zusätzliche Details“. Bei Letzterem muss sich der Leser wohl ebenso gedacht haben, dass er selbst ziemlich übel mit „0% zusätzlichen Details“ (näheren Erklärungen) abgespeist wird. Jedenfalls hat besagter Leser auch in diesem ganzen Kontext nach Infos gesucht, und zwar, was wohl andere Leser so z.B. über „zwar viele zusätzliche Pixel, aber 0% zusätzlichen Details“ meinten, und bekam indirekt als Antworten bei Postings zu lesen, wie z.B. „für dazu-erfundene Pixel mit Null neuer Information verschwendet wird“. Mitterweile dachte besagter Encoding-Newbie „Nur gut, dass man wenigstens die unscheinbaren Wörtchen wie „zusätzlichen“ bzw. „neuen“ in diesen Sätzen eingepflanzt hatte – denn der Encoding-Newbie dachte zuvor schon langsam, dass das „Schrumpfen“ und/oder „Verwerfen“ etc wohl alles aus dem „Encoding-Fachjargon“ stammen muss, und das Schrumpfen von Pixeln scheinbar selbe Wirkung hat, wie das Cropping von schwarzen Balken – wie man u.a. auf DIESEM Bild in grüner Leuchtstift-Markierung erkennen kann – was genau zu diesem Zeitpunkt dann diesem Encoding-Newbie schließlich endgültig das Gehirn wie Butter in einer erhitzten Bratpfanne schmelzen lies; und das alles mit den abschließenden Gedanken „Das kann doch alles gar nicht möglich sein – SO kann’s nicht weitergehen!“ – und damit abermals …
-----------------------------------------------------------------
… Tag zusammen!
Gut, muss wohl nicht lange und breit erwähnen, dass bei diesem „Leser“ und „Encoding-Newbie“ bei obiger („tragischer“) Story natürlich von MIR, dem ollen nightwalker, die Rede ist.
Jedenfalls, selbst wenn es so den Anschein vielleicht hat, so ist alles halb so wild und nobody is schließlich von Anbeginn an perfect.
Aber liebe brothers & sisters, sowie liebe hoffentlich nach wie vor gut amüsierte Leser,
ihr könnt euch vielleicht gar nicht vorstellen, was gerade so rundum’s „RE-coden“ von Video-Files so alles für Gehirn-Fürze in Web zu finden sind, was Brother Johns Encodingswissen geradezu zu einem kleinen Goldstück rund um dieses Thema macht – und das meine ich toterst.
Aber um nicht allzu lange noch weiter zu verschwafeln:
Aufgefallen ist mir u.a. schon lange, also als ich schon seit einigen Jahren mich immer wieder versucht hatte mich mal halbweg passabel in die Encoding-Welt reinzuhängen, dass die meisten im Web befindlichen Tuts zwar oft schön bebildert und alles sind (ungeachtet dessen, dass sie meist veraltet sind), und fast jedes Mal zu beobachten war, dass wenn es „haarig“ wurde bei gewissen Punkten, die Autoren es echt gut verstanden haben, die Angelegenheit (nämlich ihr Selbst-Nicht-Wissen), geradezu elegant zu umsegeln.
Beispiel:
Bei den meisten Tuts fängt alles schön noch plausibel an, und da kommt dann z.B. genau „haariges“ Dialog-Fenster, wo ja nicht mal viel einzugeben ist, und der Autor schreibt da lediglich lässig „Und hier geben sie >einfach< die gewünschte Auflösung ein, und damit gleich weiter zum nächsten Dialog, wo Sie …“
Ich denke, ihr wisst schon was ich meine. Richtig, z.B. genau bei so einem Dialog-Fenster, wo zwar in der Tat ja nur zwei 3- bis max. 4-stellige Werte einzugeben sind, sich aber hinter diesen Werten – wenn man es genau betrachtet -, u.U. recht enormes Hintergrundwissen (Möglichkeiten/Varianten etc) steht. Denn was bitte soll denn „Ihre gewünschte Auflösung“ sein für ein Newbie??
Für Newbies jedenfalls komplett für’n Ar…. solche Tuts.Was mir noch so alles (u.v.a.) aufgefallen ist, dass bei vielen Begriffen oder technischen Sachverhalten, man leider zu oft merkt, dass die Autoren solcher Texte, aber so gut wie „0%“ selber keine Ahnung haben von der Sache, und damit meine ich gewiss NICHT B.J., sondern z.B. solche Autoren:
BILD-INTERPOLATION – nur als kleines Beispiel.
Man merkt hier einfach, dass da nur mal schnell was hingeklatscht wurde, sodass, wenn man dort beim Artikel auf „Diskussion“ geht, dass da schon mal jemand stutzig wurde. Der 2. Poster dort bei Diskussion bin übrigens ich, um quasi mal zumindest eine Info dem 1. Anfrager oder für weitere zu hinterlassen. Wesentlich besser trifft es da schon das ENGLISCHE Gegenstück (Resampling) zu diesem Thema/Artikel.
Aber um nun mal endlich zum PUNKT zu kommen:
Ich habe damals, und muss dabei abermals zugeben bzw. die Hosen runterlassen, dass ich am Anfang echt plötzlich im Wesentlichen mit Begriffen und Definition zu kämpfen hatte, sodass ich damals laaangsam anfing, SELBST die korrekten und auch lesbaren Definitionen rund ums Encodingwissen zu erstellen; zunächst nur für mich persönlich zusammen-geschustert – was schließlich mal zu einer – vorerst - SEHR kleinen „Encoding-Knowledgebase“ führen kann.
Ist alles wie ihr dann sehen könnt noch in den kleinsten Kinderschuhen, aber falls jemand Lust hat irgendwie mitzuwirken oder Ideen dazu hat, sei es auch nur in Form von konstrukiver Kritik, dann BITTE nur zu. Stichwort „konstruktive Kritik“: Diese kleine Encoding-Knowledgebase, und wie man ja sehen kann, besteht ja ausschließlich NUR aus Definitionen, maximal kurzen aber prägnanten Erklärungen, über welche ich zumindest in der Anfangszeit schon heil-froh darüber gewesen wäre. Kurz gesagt, sollte eventuell mal lediglich ein kleines Pedant zu B.J. Encodingwissen werden, damit Newbies nicht wie ich gleich von Anfang an dasselbe Problem haben – so irgendwie in diese Richtung.
Alle – irgendwann mal von wachsamen Augen nachgeprüften - Aussagen in dieser Encoding-Knowledgebase, sind im Übrigen völlig „unique“ (kann ruhig geprüft werden!), was aber lange nicht heißt, dass sie gut sind oder es sein müssen. Liegt also ganz am Leser selbst, oder Profi dies zu beurteilen. Zudem kann JEDER damit machen was er will – inkl. selbst etwas dazu beitragen. Lediglich für Schul- oder Studien-/Seminararbeiten 1:1 zu verwenden, würde ich natürlich nicht wirklich (Plagiat) empfehlen – falls jemand etwa der Meinung sein sollen, diese sind „gut geeignet“. Nun denn, im Datei-Anhang ist mal der KLEINE Entwurf der Encoding-Knowledbase zu finden …
… und stellt – wie erwähnt - schließlich nur mal einen bescheidenen Anfang dar, welcher auch nicht unbedingt riesengroß werden muss, aber zumindest die Wesentlichsten (haarigen) Begriffe/Definitionen beinhalten soll, welche von Anfang an (auch als Art Glossar etc) jegliche Missverständnisse von vornherein ausschließen soll – und hoffentlich auch wird.
Bis demnächst!
P.S: Bin übrigens neugierig über jede Art von Vorschlägen, Gedanken, Ideen, Kritiken, Züchtigungen etc.
Übrigens: Beim Lesen der kleinen KB am besten ganz von vorne diese (möglichst aufmerksam) zu lesen beginnen, selbst wenn man sich fragen sollte, wozu für’s Encoding Infos z.B. über „Vektor-Grafiken“ gut sein sollen - hat schon alles seinen Sinn – mehr dazu später mal. So, jetzt aber ab mit mir ins Körbchen …
Tag zusammen!
Tja, nachdem ich es geradezu versprochen habe und noch in der Zeit liege …
... Hoffe bis spätestens kommenden Sonntag gegen Abend ...
Um mich so kurz wie möglich zu halten, gleich die Fakten bzw. zuvor aber schnell noch zur Story „DIE fabelhafte Encoding-Welt des nightwalker …“
Es hat also jemand vor geraumer Zeit – konkret ein Encoding-Newbie – „verzweifelt?“ nach Infos für das RICHTIGE Encoding gesucht, und stieß schließlich eines Tages über versurfte Umwege auf Brother John’s (i.F. „B.J.“ abk.) „Encodingwissen“ (EW).
Dieser jemand war schließlich auch gleich recht schnell entzückt (Gestaltung, Lesbarkeit, Schreibstil, Info etc), alleine schon von all den echt guten, motivierenden und einleitenden Erklärungen – zumindest bis zu DIESER Stelle.
Wie man also auf DIESEM gescannten und völlig „unzensierten“ Bild sehen kann, da hat also jemand zunächst vielleicht gedacht, …
"Wofür braucht man PDF und Papier?"
weil es auch Leute gibt die gerne offline Guides lesen
Cu Selur
… genau so ist es!
Denn hier wird es langsam „haarig“ – obwohl vom Autor vorgewarnt. Denn speziell bei diesem Kapitel musste sich der Leser wohl gedacht haben „Es lässt es sich in Offline-Form wohl wesentlich bequemer auf ner Couch LÄNGER grübeln und brüten!“ Allerdings dürfte da jemand wohl mehr als nur gerübelt und „gebrütet“ haben, wie man so ganz allgemein am BILD erkennen kann – und dazu muss man auch kein sog. „Profiler“ sein. Jedenfalls, und das alles schon bei diesem einleitenden Kapitel-Abschnitt. Was am BILD u.a. noch besonders auffällt, ist, dass der Leser z.B. immer das Wort „Auflösung“ mit Leuchtstift markiert (7x) hat. Dieses Wörtchen muss es ihm aus irgendeinem Grund offenbar ganz besonders angetan haben – das Warum, bleibt zunächst offen.
Unterm Strich erkennt man am BILD ebenso eindeutig, dass es jedenfalls ganz danach aussieht, als ob da jemand nicht nur mit irgendetwas, sondern gleich mit mehreren Begriffen, Dingen und Sachverhalten ganz offenbar fürchterlich zu kämpfen hatte.
Der Leser, dessen Gehirn mittlerweile schon recht aufgeweicht war, dachte sich offenbar, „Na ja, dann halt schnell mal ein paar >>Wissensdefizite<< ausbügeln, indem man halt ganz einfach über’s Web…“ - seiner Meinung nach - … „die besten Definitionen von z.B. von >>Auflösung<< einfach mal sucht!“
Der Leser machte dann offenbar eine GEGENÜBERSTELLUNG der gefunden Definitionen, und zwar offenbar in der Hoffnung, gewisse „Wissensdefizite“ auf diese Weise schneller oder besser in den Griff zu kriegen. Allerdings wurde dem Leser beim Lesen und dem Versuch zu verstehen der gefundenen Definitionen, das Gehirn noch weicher (als es ohnehin schon war), und muss sich beim Lesen DIESER DEFINITIONEN von „Auflösung“ wohl schon langsam gedacht haben „Ja, spinn’ ich jetzt komplett?“ – und „löste“ sich lieber wieder voll und ganz in B.J’s-Encodingswissen „auf“.
Was allerdings auch keine so besonders gute Idee war:
B.J’s-Beispiel „Die fabelhafte Welt der Amelie“ schien geradezu zu einer „NOT-GEBURT“ (in übertragenem Sinn) auszuarten an (mögliche Varianten am PC visualisieren), denn der Leser, Grübler und Studierer, versuchte ganz offenbar das im EW vorgeführte Beispiel insofern für „bare Münze“ zu nehmen, denn schließlich las er im EW recht häufig Begriffe und Phrasen, wie etwa „Auflösung schrumpfen“ oder „das beschneidet das Bild“, „verwirft keine Informationen“ oder „enthalten diese 45% zusätzliches Bild genau 0% zusätzliche Details“. Bei Letzterem muss sich der Leser wohl ebenso gedacht haben, dass er selbst ziemlich übel mit „0% zusätzlichen Details“ (näheren Erklärungen) abgespeist wird. Jedenfalls hat besagter Leser auch in diesem ganzen Kontext nach Infos gesucht, und zwar, was wohl andere Leser so z.B. über „zwar viele zusätzliche Pixel, aber 0% zusätzlichen Details“ meinten, und bekam indirekt als Antworten bei Postings zu lesen, wie z.B. „für dazu-erfundene Pixel mit Null neuer Information verschwendet wird“. Mitterweile dachte besagter Encoding-Newbie „Nur gut, dass man wenigstens die unscheinbaren Wörtchen wie „zusätzlichen“ bzw. „neuen“ in diesen Sätzen eingepflanzt hatte – denn der Encoding-Newbie dachte zuvor schon langsam, dass das „Schrumpfen“ und/oder „Verwerfen“ etc wohl alles aus dem „Encoding-Fachjargon“ stammen muss, und das Schrumpfen von Pixeln scheinbar selbe Wirkung hat, wie das Cropping von schwarzen Balken – wie man u.a. auf DIESEM Bild in grüner Leuchtstift-Markierung erkennen kann – was genau zu diesem Zeitpunkt dann diesem Encoding-Newbie schließlich endgültig das Gehirn wie Butter in einer erhitzten Bratpfanne schmelzen lies; und das alles mit den abschließenden Gedanken „Das kann doch alles gar nicht möglich sein – SO kann’s nicht weitergehen!“ – und damit abermals …
-----------------------------------------------------------------
… Tag zusammen!
Gut, muss wohl nicht lange und breit erwähnen, dass bei diesem „Leser“ und „Encoding-Newbie“ bei obiger („tragischer“) Story natürlich von MIR, dem ollen nightwalker, die Rede ist.
Jedenfalls, selbst wenn es so den Anschein vielleicht hat, so ist alles halb so wild und nobody is schließlich von Anbeginn an perfect.
Aber liebe brothers & sisters, sowie liebe hoffentlich nach wie vor gut amüsierte Leser,
ihr könnt euch vielleicht gar nicht vorstellen, was gerade so rundum’s „RE-coden“ von Video-Files so alles für Gehirn-Fürze in Web zu finden sind, was Brother Johns Encodingswissen geradezu zu einem kleinen Goldstück rund um dieses Thema macht – und das meine ich toterst.
Aber um nicht allzu lange noch weiter zu verschwafeln:
Aufgefallen ist mir u.a. schon lange, also als ich schon seit einigen Jahren mich immer wieder versucht hatte mich mal halbweg passabel in die Encoding-Welt reinzuhängen, dass die meisten im Web befindlichen Tuts zwar oft schön bebildert und alles sind (ungeachtet dessen, dass sie meist veraltet sind), und fast jedes Mal zu beobachten war, dass wenn es „haarig“ wurde bei gewissen Punkten, die Autoren es echt gut verstanden haben, die Angelegenheit (nämlich ihr Selbst-Nicht-Wissen), geradezu elegant zu umsegeln.
Beispiel:
Bei den meisten Tuts fängt alles schön noch plausibel an, und da kommt dann z.B. genau „haariges“ Dialog-Fenster, wo ja nicht mal viel einzugeben ist, und der Autor schreibt da lediglich lässig „Und hier geben sie >einfach< die gewünschte Auflösung ein, und damit gleich weiter zum nächsten Dialog, wo Sie …“
Ich denke, ihr wisst schon was ich meine. Richtig, z.B. genau bei so einem Dialog-Fenster, wo zwar in der Tat ja nur zwei 3- bis max. 4-stellige Werte einzugeben sind, sich aber hinter diesen Werten – wenn man es genau betrachtet -, u.U. recht enormes Hintergrundwissen (Möglichkeiten/Varianten etc) steht. Denn was bitte soll denn „Ihre gewünschte Auflösung“ sein für ein Newbie??
Für Newbies jedenfalls komplett für’n Ar…. solche Tuts.Was mir noch so alles (u.v.a.) aufgefallen ist, dass bei vielen Begriffen oder technischen Sachverhalten, man leider zu oft merkt, dass die Autoren solcher Texte, aber so gut wie „0%“ selber keine Ahnung haben von der Sache, und damit meine ich gewiss NICHT B.J., sondern z.B. solche Autoren:
BILD-INTERPOLATION – nur als kleines Beispiel.
Man merkt hier einfach, dass da nur mal schnell was hingeklatscht wurde, sodass, wenn man dort beim Artikel auf „Diskussion“ geht, dass da schon mal jemand stutzig wurde. Der 2. Poster dort bei Diskussion bin übrigens ich, um quasi mal zumindest eine Info dem 1. Anfrager oder für weitere zu hinterlassen. Wesentlich besser trifft es da schon das ENGLISCHE Gegenstück (Resampling) zu diesem Thema/Artikel.
Aber um nun mal endlich zum PUNKT zu kommen:
Ich habe damals, und muss dabei abermals zugeben bzw. die Hosen runterlassen, dass ich am Anfang echt plötzlich im Wesentlichen mit Begriffen und Definition zu kämpfen hatte, sodass ich damals laaangsam anfing, SELBST die korrekten und auch lesbaren Definitionen rund ums Encodingwissen zu erstellen; zunächst nur für mich persönlich zusammen-geschustert – was schließlich mal zu einer – vorerst - SEHR kleinen „Encoding-Knowledgebase“ führen kann.
Ist alles wie ihr dann sehen könnt noch in den kleinsten Kinderschuhen, aber falls jemand Lust hat irgendwie mitzuwirken oder Ideen dazu hat, sei es auch nur in Form von konstrukiver Kritik, dann BITTE nur zu. Stichwort „konstruktive Kritik“: Diese kleine Encoding-Knowledgebase, und wie man ja sehen kann, besteht ja ausschließlich NUR aus Definitionen, maximal kurzen aber prägnanten Erklärungen, über welche ich zumindest in der Anfangszeit schon heil-froh darüber gewesen wäre. Kurz gesagt, sollte eventuell mal lediglich ein kleines Pedant zu B.J. Encodingwissen werden, damit Newbies nicht wie ich gleich von Anfang an dasselbe Problem haben – so irgendwie in diese Richtung.
Alle – irgendwann mal von wachsamen Augen nachgeprüften - Aussagen in dieser Encoding-Knowledgebase, sind im Übrigen völlig „unique“ (kann ruhig geprüft werden!), was aber lange nicht heißt, dass sie gut sind oder es sein müssen. Liegt also ganz am Leser selbst, oder Profi dies zu beurteilen. Zudem kann JEDER damit machen was er will – inkl. selbst etwas dazu beitragen. Lediglich für Schul- oder Studien-/Seminararbeiten 1:1 zu verwenden, würde ich natürlich nicht wirklich (Plagiat) empfehlen – falls jemand etwa der Meinung sein sollen, diese sind „gut geeignet“. Nun denn, im Datei-Anhang ist mal der KLEINE Entwurf der Encoding-Knowledbase zu finden …
… und stellt – wie erwähnt - schließlich nur mal einen bescheidenen Anfang dar, welcher auch nicht unbedingt riesengroß werden muss, aber zumindest die Wesentlichsten (haarigen) Begriffe/Definitionen beinhalten soll, welche von Anfang an (auch als Art Glossar etc) jegliche Missverständnisse von vornherein ausschließen soll – und hoffentlich auch wird.
Bis demnächst!
P.S: Bin übrigens neugierig über jede Art von Vorschlägen, Gedanken, Ideen, Kritiken, Züchtigungen etc.
Übrigens: Beim Lesen der kleinen KB am besten ganz von vorne diese (möglichst aufmerksam) zu lesen beginnen, selbst wenn man sich fragen sollte, wozu für’s Encoding Infos z.B. über „Vektor-Grafiken“ gut sein sollen - hat schon alles seinen Sinn – mehr dazu später mal. So, jetzt aber ab mit mir ins Körbchen …
... damit du dir nicht evtl. unnötig Mühe im x264-Abschnitt machst. Dass dort bei den Kommandozeilen ...
Hi!
Na wenn es nur DAS wäre - DAS macht mir alles KEINE Kopfzerbrechen. Was mir aber in der Tat seit geraumer Zeit Kopfzerbrechen machte, also seit ich dein Encodingwissen sorgfältig "studiere" - da müsste dir geradezu der Atem stillstehen ...
Also kann mich jedenfalls echt nicht erinnern, wann mich solche eine - wie schon im 1. Posting erwähnt - kleine, aber äußerst feine Angelegenheit, mich aber sowas auf die Palme bringen konnte ...
Vorweg - und damit's nicht gleich ein Missverständis gibt:
Dein Encodingwissen ist geradezu ein Hammer :daumen: - is ja nur eine kleine, aber äußerst pikante Angelegenheit dabei, die sich wie ein roter Faden ...
Mehr am Wochenende ...
P.S: Stichwort "konstruktive Kritik" - das meine ich auch so. Will heißen, ich "interpoliere" quasi gerade ein bisschen einige BEDEUTSAME Erklärungen zu bestimmten Punkten im Encodingwissen, sodass anstatt blöder "Kritik" besser gleich mögliche Lösungen auf den Tisch kommen - und dann schaun mer mal ...
Na klar. Jederzeit gern!
Ui - freut mich - sehr gut.
Freuen tut mich dies alleine schon deshalb, weil gerade du als "Encodingwissen-Vater" dich gleich als erstes zu meiner (mal vorsichtigen) Anfrage meldest.
Die Angelegenheit ist aber eigentlich weniger "geheimnisvoll" als es vielleicht und und mittlerweile den Anschein hat ...
Ich wollte dich ohnehin schon länger mal per Mail kontaktieren und dir ein paar Infos zukommen lassen, aber dann erschien es mir doch klüger, einfach DEINEN Worten zu folgen ...
Nichtsdestotrotz bin ich der Meinung, dass mein Tut zu umfangreich geworden ist und zu viel Arbeit drinsteckt, um es einfach so auf der Platte vergammeln zu lassen.
Also raus ins Netz damit ...
Jo, so sehe ich das auch.
Wie schon im 1. Posting erwähnt, muss ich zuvor noch einige Dinge auf die Reihe kriegen und fertigstellen - heißt, das "Hauptposting" kommt noch. Hoffe bis spätestens kommenden Sonntag gegen Abend. Außerdem muss ich mich noch nach einem Host umsehen, wo man schnell mal ein paar verschiedene File-Formate (PDF, eventl. ZIP) unbürokratisch hochladen kann, damit diese auch etwas längerfristig downloadbar dort bleiben ...
Also - bis zum Wochenende!
