Beiträge von incredible

    Didée, Scharfi
    Wieviel phys. RAM ist denn zu empfehlen, wenn ich mal mein System aufrüsten will (Neben Core2Duo, neuen DDR2s, neuem Mobo, etc)?

    hörte sich so an, als ob man 2GB einkalkulieren sollte wenns zu kniffeligen Scriptereien kommt.

    SilberWärmeleitpste ist zu 90% Perlen vor die Säue.

    Regel: Wenn der Kühlerboden aus Kupfer und vollkommen plan ist, dann eine normale Silikonpatse hauchdünn auftragen. Die Silberpasten gleichen schlechtere Unebenheiten jener schlecht verarbeiteten Kühler mit non-Kupferboden aus.
    Am besten den Kupferboden nochmal mit 1600er und Polierpaste bearbeiten, Silikonpaste drauf fertig.

    Ich glaube da hat jemand (war es Didée?) ein DenoiserScript vorgestellt, welches zwei Streams vergleicht und via zwei captures das wahre Rauschen besser von wahren Details unterscheiden kann.
    Musst mal auf doom9 suchen. Bei TV machts ja keinen Sinn, denn was einmal via der Buchse reinkommt wird lediglich auf einen 2ten Stream gespiegelt ;).

    400Watt allein sagen GAR nichts aus, ist genauso wie bei Verstärkern und Boxen.

    Bei allen Netzteilkäufen neben der Wattzahl ebenso die Amperes checken, welche auf den versch. Leitungen anliegen. Daher gibts im Ebay auch die seriöseren Verkäufer, die dies direkt mit anbieten.
    Ich gebe dir einen Tipp: Kaufe ein Gutes Netzteil, welches ein gutes Feedback (wie z.B. hier) erfahren hat. Denn sowas sollte eine vernünftige Investition sein, ansonsten hast du nur Ärger und weisst nicht woher er kommt. Selbst wenn die aktuellen CPUs mit ihrer Verlustleistung eher runter gehen, knallen dafür z.B. Top-Grakas lecker rein was Bedarf angeht. Von SLI und Crossfire ganz zu schweigen, aber das ist bei dir bestimmt kein Thema ;) Und für mich ebensowenig.

    Zitat

    Das Problem scheint mir da weniger die Programmiersprache als die Community zu sein. Ich finde kaum Leute, welche mir bei meinen Problemen helfen können

    Genau das war auch für mich ein Entscheidungsgrund. Wenn du in einer Community bist, in der dir gerne und bzgl. der Frage kompetent geholfen werden kann, ist das die halbe Miete zum Erfolg.

    Zitat

    In Delphi findet man dazu fast gar nichts und die Standards enthalten C/C++-Beispiele.

    Wie gesagt, wenn du lediglich C/C++ code hast, diesen als Lib incl. der msvcrt.lib linken und wenn keine weiteren "Symbols" fehlen, läufts wunderbar. Und wenn welchen fehlen, dann würdest du diese für C/C++ Kompilate ebenso finden müssen ;)

    Eins sei gesagt! Wenn du externe C/C++ libs linkst, dann kompiliere diese libs mit VC6 und nicht mit VSExpress2005C++! Da gibts sodann Cruntime/Manifest Probleme, welche selbst durch ein linken der VS2005 eigenen msvcrt.lib und dem vorhanden sein der MSVCR80.dll im System nicht zu bändigen sind. Mit VC6 oder dem freien alten MSVC++Toolkit2003 gehts wunderbar.

    Zitat

    Mir fehl immer noch ein Muxer /Converter für Audio Video Delays , wo ich a Was sehe und B schnell mal was anhören kann und C das dann auch so augegeben wird wie ich es gehört habe.
    ...
    Und da das laut INcredible ja so einfach geht indem man auf existieren de Libraries zurückgreift.......

    In deinem Falle würde ich dann doch auf C/C++ zurückgreifen, denn da gibts für genau dein spezielles Anliegen genug Sources auf GPL Basis, aus denen du das Beste für dich (theoretisch) zusammentragen und zu einer Applikation umstricken/kompilieren kannst. Und selbst hier wirst du noch die Nächte am PC verbringen, selbst wenn du gut C/C++ beherrschst. ;)
    Das ist etwas sehr spezifiches und ein Muxer/Demuxer verlangt explizite Kenntnis darüber, wie der zu behandelnde Datenstream interleaved in seinen Packets aufgebaut ist. Fr_An ist doch sowas mal für mpeg1 angegangen? Zumindest was die Logic deines Vorhabens angeht.

    Was es für PB z.B. gibt ist eine von mir verfasste, - die AVIfil32 API direkt unterstützende-, Library und ein Directshow-Include, wo man seinen eigenen Player zusammenbauen kann, also so ähnlich wie das Dshow Pack für Delphi, lediglich kleiner. Ach ja, und eine Library, mit der man die Avisynth dll direkt ansprechen und via dieser die Video/Audiodaten auslesen kann.

    - Bladerunner -> Wegen der Videotelefonie und Nudeln aus dem Becher.
    - Full Metal Jacket -> Weil man da aufgeklärt wird, was passiert, wenn man heimlich zuviel Krapfen ist.
    - Starwars 4-6 -> Weil auch ich mal klein war und mit Püppchen gespielt habe ( die konnten aber schießen :sly: )
    - León der Profi -> Bringt leute um, und doch findet jeder, er habe einen guten Charakter. Und er besitzt eine Pflanze, "die keine Fragen stellt".
    - Der einzige Zeuge -> Dort gibts KEINE KLINGELTÖNE! (und wirds wohl auch nie geben *neid*)


    EDIT: Und wenn jetzt jemand meint, dann zieh doch zu den Amish hin: Ich will nicht als einzgen Song für den Rest meines Lebens von Sam Cook - "Wonderful World" in der Scheune nebenan hören müssen, und das auch nur mit Glück, wenn jemand das Vogelhaus umfährt. ;)

    Das liegt dann an den Einstellungen vom anderen Monitor.

    Mit ein Grund, warum ich auf eine ATI gewechselt bin, heisst aber nicht das Nvidea da mist baut, sondern weil ich mir eh eine neue Graka kaufen wollte und die Nvidea nun wunderbar via s-video out im HTPC ihren Dienst verrichtet und da kommt alles bene rüber (ebenfalls via Overlay).

    Vor allem macht es so richtig Sinn einen Guide in Angriff zu nehmen, wo als erstes in deinem Post fett Warez zu erkennen sind.
    Demnach eher im falschen Forum als in der falschen Sektion gepostet.
    Lese die Forenregeln. Und das der Kram illegal ist, weiss auch ohne Forenregeln jedes Kind.

    Zitat von Fr_An

    Dann wirst Du auf Incredible warten müssen. Ich wollte mir Pure Basic eigentlich schon vor einiger Zeit zulegen, aber irgendwie scheue ich mich davor, meine Projekte umzuschreiben.


    Du kannst dir ja einen kleinen Konverter schreiben ;) Sodass zumindest schon mal Variablen und Strukturen declarationen/Definitionen umgesetzt werden.

    Ich habe mir mal sowas für den Dshow.pas header gefummelt. Total trivial (also gerade das Nötigste), aber hatte für Strukturen und GUIDs gereicht ;)

    Ich würde viell. die alten Projekte in Delphi lassen und neues in PB angehen.
    Bzw. wenn du in Delphi lib's ausgeben kannst, dann mit PB linken und die Befehle/Symbole des Delphi kompilats wie normale Befehle aufrufen.

    Zitat

    Ist PureBasic wirklich so schnell und Plattformübergreifend

    Ja.
    Es gibt PureBasic für Win, Linux und OSx. Wenn du einmal eine Lizenz erworben hast, kannst du alle OS spezifischen Versionen nutzen. Zudem kommen bei zukünftigen Upgrades keine weiteren Kosten auf dich zu. Kurzum: Einmal die Lizenz zahlen, keine zukünftigen weiteren Kosten.

    Das Projekt PureBasic wird von dem franz. Entwickler Frederic Laboruer hauptberuflich immer weiterentwickelt. Er bietet englische., deutsche und französische Foren an und steht permanent in Kontakt mit der Community. Somit werden Verbesserungen oder Bugs sehr schnell umgesetzt bzw. behoben.

    Der Purebasic Compiler ist nichts anderes als ein Preprozessor/Interpreter, der den PureBasic Code in asm übersetzt und via Fasm.exe in Maschinencode compiliert, der als resultierende obj. Datei sodann via Polink zur .exe oder .dll wird.
    Der resultierende asm code ist laut asm versierten Mitgliedern recht gut umgesetzt, was eben für die Geschwindigkeit des resultierenden Kompilates spricht. Natürlich handelt es sich hierbei nicht um einen hochoptimierten Compiler, wie z.B. den Intel Compiler für C++, aber was Performance angeht, da kenne ich keine Klagen.

    OOP bzw. Klassenbasiertes Programmieren ist via ein par zus. Zeilen ebenso möglich.

    Beinahe die gesamte API wird 'nativ' unterstützt, somit musst du keine Systemheader oder Dlls direkt laden, sondern lediglich den API Befehl mit einem angehangenen Underscore versehen. Z.B. GetDC() in C/C++ wäre in PB GetDC_(), fertig.

    Was die Community angeht, da sind sehr versierte Programmierer aus der C/C++ Ecke unterwegs, die mittlerweile ebenso in PureBasic programmieren. Die geben sodann klasse Tips bei komplexen Dingen wie API, DirectX, pointer arithmetic etc etc etc.

    Was Video-Programme Programmierung angeht, da ist schon einiges an Includes und Libraries zusammen gekommen (nebenher auch via meiner Wenigkeit ;) ) was man ohne Probleme in eigenen Anwendungen übernehmen/nutzen kann.

    Zudem gibt es noch einen Vorteil: Du kannst externe lib oder obj Files direkt in PureBasic Applikationen statisch linken. D.h. wenn es in der C/C++ Welt eine tolle rasend schnellen Routine gibt, compilierst du den Code als lib oder obj. und linkst wie o.g. in PureBasic. Die Routinen sind sodann wie 'native' Purebasic Befehle nutzbar. Das erleichtert z.B. die Zusammenarbeit mit reinen C/C++'lern.

    Es ist so, dass immer die aktuellste Version zuerst für Windows, dann für Liniux und dann für OSx rauskommt. Daher gibt es jetzt PB für Win als v4, jedoch für OSx noch als v3.94. Die Zeitspanne liegt hierbei ca. 6 Monate bis die beiden anderen Platformen mit ihrer eigenen IDE unterstützt sind. Aber v3.94 reicht für OSx oder Linux noch ohne Probleme aus.

    PB unterstützt seit v4 nativ Unicode, vorher konnte man dies aber via Routinen oder externen Libraries lösen.

    Was die IDE angeht, da gibt es zwar eben den originalen PureBasic Editor, jedoch würde ich als IDE direkt 'jaPBe' nehmen, denn dieser Editor ist ein Genuß was Extras und Komfort angeht. Er besitzt Vorzüge, wie man sie nur von marktführenden Entwicklungsumgebungen her kennt.

    Die Community ist klasse, sehr nette Leute (wenn man sich nicht gerade daneben benimmt oder andere alles für einen machen lassen will ;) )
    http://www.purebasic.fr/german/
    http://www.purebasic-lounge.de/index.php
    http://www.purebasic.fr/english/


    Zitat

    mit .Net kann ich überhaupt nichts anfangen

    Nun ja, viell. weil du dich damit noch nicht auseinandergesetzt hast.
    Ich kann mich dazu nicht wirklich äussern, da ich zu faul bin, mich in .net einzuarbeiten, bzw. ich es nicht brauche.
    Jedenfalls haben alle Umgebungen ihre Stärken und Schwächen. Meist entscheiden sich Nutzer via ihrem 'ersten' Eindruck und da dieser meist nicht alle Hintergründe mit einbezieht ist dieser Entschluss oft nicht der beste für einen selbst. Da gehst du hin, arbeitest dich in eine Umgebung ein, bekommst Ahnung und dann stehst du vor einem Punkt, wo die für dich spezifischen Nachteile ersichtlich werden. Wenn diese Nachteile nix ausmachen, dann alles bene. Andersherum musst du sodann umstellen.
    Soweit ich .net verstanden habe, ist es eine Ansammlung von mächtigen Anwenderklassen und ist komplett OOP basiert. Das sollte aber nicht zurückschrecken, denn die meisten schrecken vor OOP bzw. Klassen zurück, weil sie negative Berichte von Usern im www gelesen haben. Man sollte sich das erstmal selber ansehen, bevor man sich da negativ beeinflusen lässt.

    Du kannst .net neben C# sowohl in M$ VS C++ 2005 und anderen .net unterstützenden Umgebungen anwenden.

    Mein Tipp: Bevor du Geld ausgibst, schaue dir Demos (z.B. Purebasic) und freie Umgebungen wie z.b. VisualStudio Express C++ und C# mal genau an und probiere ein wenig an mitgelieferten Beispielen herum. Und ich meine hierbei nicht ein "Hello World" Konsolenprogramm, sondern eine kleine Windows applikation. ;)

    Hmmmm ... also ich rufe den Frame dekromprimiert in der Desktop-Farbtiefe ab. Es kann natürlich sein, dass ich in der SetDIBits() Routine immer RGB24/32 wandeln lasse. Muss mal nachsehen.
    Danke für die Info.

    Genau, VLC nutzt Std.mäßig DirectX und da ist der Hase im Pfeffer begraben.
    Mit meiner Nvidea Karte hatte ich genau ebenso solche Probleme, das hängt mit der Hardwarebeschl. der Karte zusammen, wie hier bereits erwähnt. Denn da wird der Farbraum zudem auch falsch gewandelt. Wenn du im VLC die Hardware Farbraumwandlung deaktivierst, wirds wieder stimmen, ist aber nicht im Sinne von DirectX.

    Probiere diverse Treiber für deine Graka aus, bzw. suche mal im www nach Berichten, wo bestimmte Treiber mit bestimmten Directx Versionen Probleme verursachen.

    Da hast du vollkommen recht.
    Mit mpeg4 meinte ich auch PAR 1:1 (jetzt fange ich auch schon so an).

    Generell würde ich eh bei guten Backups empfehlen entweder nix an der Bildproportion zu ändern und somit wenns geht MOD16 croppen, oder eben, wenn die Dateien kleiner werden sollen genau das Prinzip von SVCD und Co. zu nutzen, also warum sollte man nicht z.B. ein Capture auf 544x576 bringen und am ende lediglich GripBorders() weglassen und sodann via z.B. x264 mit der entspr. PAR codieren :) Denn sodann wirds auch via llen Software Playern richtig unterstützt.

    Generell sollte bei mpeg4 targets somit GripBorders weggelassen weden.
    Demnach hier die richtigen PAR/SARs bei folgenden Zielformaten via GripFit:

    PAL non-Anamorph (AKA ca. 4:3):

    Output___ PAR/SAR ___Anzeige Bilschirm / Beamer
    -------------------------------------------------
    720x576 = 128/117 ___(788xXXX)
    704x576 = 128/117 ___(770xXXX)
    544x576 = 397/272 ___(794xXXX)
    528x576 = 397/264 ___(794xXXX)
    480x576 = 128/78 ____(788xXXX)
    352x576 = 256/117 ___(770xXXX)
    352x288 = 128/117 ___(385xXXX)


    PAL Anamorph (AKA ca. 16:9)

    Output___ PAR/SAR ___Anzeige Bilschirm / Beamer
    -------------------------------------------------
    720x576 = 512/351___(1050xXXX)
    704x576 = 512/351 ___(1027xXXX)

    Alles weitere würde zu unscharf enden.

    Somit bei mpeg4 mit Einbehalten des anamorphen Bildes der DVD Source:

    GripCrop(720x576, source_anamorphic=true, dest_anamorphic=true)
    GripSize("LanczosResize") # oder welchen auch immer

    SAR/PAR wäre hier eben bei 720 anamorph : 512/351


    Wenn man einen anamorphen DVD stream auf non-anamorph encodieren will, dann:

    GripCrop(720x576, source_anamorphic=true, dest_anamorphic=false)
    GripSize("LanczosResize") # oder welchen auch immer

    SAR/PAR wäre hier eben bei 720 non-anamorph : 128/117


    Ein Beispiel für ein analog Capture (welche btw. nie anamorph daherkommen):

    GripCrop(544x576, source_anamorphic=false, dest_anamorphic=false)
    GripSize("LanczosResize") # oder welchen auch immer

    SAR/PAR wäre hier eben bei 544 : 397/272
    Voraussetzung bei einem richtigen Resizen von analog Captures ist hierbei, dass bei 704x576 oder 720x576 die Karte proportional richtig aufnimmt (siehe Doom9 capture Faq). Ich habe bewusst 544 genommen, da captures im original nie die Güte von 720 o. 704 px ausschöpfen.


    Nochmal zusammengefasst:

    Ich habe eine DVD mit 720x576 anamorph und will sie bestmöglich als backup in x264 oder xvid encodieren und am ende auch anamorph mit voller vertikalen Auflösung sehen können (am PC oder Beamer via HTPC).

    Das Original mit 720x576

    [Blockierte Grafik: http://img163.imageshack.us/img163/699/720x576un9.jpg]


    1. Das Script:

    dgdecode_MPEG2Source("X:\MyMovie.d2v")
    gripcrop(704,576)
    Gripsize("LanczosResize")
    Colormatrix(...)

    wie man sieht ist kein GripBorders() angehangen! Ich habe bewusst 704 genutzt, da sodann auf 1027xXXX am ende am PC oder z.B. Beamer via HTPC angezeigt wird. Alles größere wie bei 720 würde eh im *off* verschwinden, da die meisten besseren Beamer max. eh nur 1024xXXX wiedergeben können.

    dabei kommt das hier raus:

    [Blockierte Grafik: http://img46.imageshack.us/img46/8711/704x432ho9.jpg]

    mit korrekten MOD16.

    ... und ab in den Encoder und in diesem Beispiel wie o.g. SAR/PAR = 512/351 einstellen.

    Am PC, bzw. Beamer via HTPC kommts am Ende so richtig rüber wenn die PlaybackSoftware richtig die PAR/SAR des Encodings auslesen kann:

    [Blockierte Grafik: http://img65.imageshack.us/img65/7947/1027x432rp9.jpg]


    Was für Vorteile habe ich noch bei der o.g. PAR/SAR Methode:
    Nehmen wir an, ich hätte ein interlaced capture, welches ich ohne deinterlacing via XVID oder x264 encodieren möchte.
    Da wirds problematisch, aaaber ich kann hingehen, GripCrop() und GripSize() nutzen, sowie einen MotionCompensating Bobber nutzen um auf volle Bildgröße bei fpsx2 zu kommen = flüssige Bewegung und keine Interlacing artefakte.
    D.h. der Encoder müsste die doppelte Framerate beim encodieren unterstützen.
    Da dies aber in eine irre große Datei enden würde, gehen wir hin und nutzen

    Avisource(...)
    xMotionCompBobber()
    GripCrop(352,576)
    GripSize("LanczosResize")

    und beim encodieren eine PAR/SAR von 256/117.
    Damit habe ich zwar ein etwas unschärferes Bild, kann aber die "flüssige" Wiedergabe beibehalten und die Dateigröße klein halten.

    Gemach, gemach ... ;)

    Ich hatte sowieso vor irgendwann eine PARanoia.dll für Avsiynth zu erstellen, da wird dann auch klarerweise mpeg4 als target mit individuallen PARs unterstützt.

    Ich habe mal in den code von GripFit reingesehen und ein paar kleine Änderungen vorgenommen.
    Es wurde ab und zu berichtet, dass die alte Version von GripFit unter (wenn auch sehr seltenen) Umständen in komplexen Scripten abstürzt. Ich vermute, dass es daran liegt, dass die alte Version mit einem der allerersten avisynth_25.h Header kompiliert wurde. Diese Version wurde mit dem neueren avisynth.h Header kompiliert.

    Der original Code stammt von SansGrip.

    Änderungen:
    - Neuer Avisynth.h Header beim kompilieren genutzt.
    - Kleine Verbesserungen bei der internen PAR Berechnung. Neben anderen Kleinigkeiten werden jetzt auch 544xYYY Zielgrößen richtig auf dem SAP wiedergegeben.
    - Wenn eine 720er Source auf 704er Breite gebracht wird und die Source anamorph ist, so bleibt per default der anamorphe Zustand erhalten. Bisher war das nur bei 720er Sourcen der Fall, wenn nicht manuell die Parameter entspr. gesetzt wurden.

    Download: GripFit2006
    (Beta, --> keine Gewähr)

    Die Nutzung ist wie gehabt:

    Zitat

    GripCrop(int width, int height, bool source_anamorphic, bool dest_anamorphic, int overscan, int crop_round_width, int crop_round_height, int resize_round_width, int resize_round_height, int luma_threshold, int samples)

    GripSize(string resizer)

    GripBorders()

    Bei einer 720 source z.B.:

    GripCrop(704,576)
    GripSize("Lanczos4Resize")
    GripBorders()

    Wenn die Source in 720px und anamorph daherkommt wird anamorphic beibehalten und zu 704 konvertiert. Hierbei wird intern richtigerweise zu 704 hin lediglich gecroppt.


    GripCrop(352,576, source_anamorphic=false, resize_round_width=2, resize_round_height=2)
    GripSize("Lanczos4Resize")
    GripBorders()

    Skaliert einen nicht anamorphen Source Stream hin zu 352x576 und nutzt MOD2 anstatt von MOD16 beim Resizing (nicht empfohlen).
    Die gleiche Logic kommt auch bei "crop_round_width" und "crop_round_height" zum Zuge. Hier wird der cropping MOD verändert (2,4,8,16,32).

    "luma_threshold" und "samples" beziehen sich auf die Border Detection, also den Schwellenwert (threshold) und die genutze anzahl der Referenz-Frames (samples) über den gesamten Stream hinweg.


    Bei XVID/x264 oder generell mpeg4 Ziel-Encodings bitte so wie hier beschrieben vorgehen:
    http://forum.gleitz.info/showpost.php?p=294861&postcount=6