Beiträge von Bumsfalara

    Nein, dazu gibt es keine anwendbare Formel. Für ein Gemisch wie Ethanol-Wasser wird es allerdings wahrscheinlich eine empirische Formel geben, müsste man mal bei webofscience oder ähnlichen nachlesen.
    Man kann sich nämlich aus dem oben dargestellten Kurvenverlauf nicht einfach in Excel ein Polynom erstellen lassen, weil dieser Kurvenverlauf eben nur für genau diese Temperatur gilt.

    Es ist gut möglich, dass sich Ethanol-Wasser in bezug auf die Dichte bei eine anderen Temperatur nahezu ideal verhält.

    Edit: Hier bereits ein Paper für den Temperaturbereich von 283,15K bis 298,15K. Allerdings musst du in diesem Fall noch Formel 1 etwas umstellen, ist also leider nicht so pralle.
    http://pubs.acs.org/doi/abs/10.1021/je060335h

    Verhält sich das Gemisch überhaupt ideal? Wenn nein kannst du die Dichte des Gemischs nicht aus den Dichten der reinen Komponenten errechnen.


    Edit: Das Gemisch verhält sich nicht ideal, von daher kannst du die Dichte ohne weiteres auch nicht berechnen. Siehe das angehängte Diagramm. Bei einem idealem Gemisch verhält sich die Dichte des Gemischs proportional zum Massenanteil der Komponenten.


    Tja, und uneigentlich ... ?
    Ich gehe mal davon aus das selbst bei standardkonformen Decoder noch spiel bei der ein oder anderen Option ist und deshalb das Bild variiert ...

    Nein, da ist kein Spiel mehr vorhanden, die Decoder für h.264 liefern alle den gleichen Output, sofern nicht weitere Postprocessingfilter hinzukommen. Ausnahmslos.

    Wenn du das Gegenteil beweisen willst, macht doch einfach mal ein paar Screenshots, natürlich mit sonst gleichen Randbedingungen.


    Und klar, der CoreAVC ist als DirectShow Treiber erst mal auf Speed getrimmt. Trotzdem stufe ich ihn als einen der Besten ein - und um's cutten geht's hier ja nicht ...

    Wie bewertet man einen Decoder? Nach Geschwindigkeit, Preis, Fehleranfälligkeit? Oder bewertet man Decoderpakete wie CoreAVC als ganzes Paket (CoreAVC beherrscht doch Sachen wie Outputrangeumwandlung?)

    Coreavc hatte früher mal Probleme mit Makroblöcken, ist das heute immer noch so?
    Hast du mal Decoder wie "DiAVC" getestet? ffdshow und ffdshow-mt?

    Yup :)


    Hm, ich hab mich jetzt mal ein bissl in das Thema "threaded lookahead" eingelesen.
    Anscheinend wurde das Priorität des threads von lookahead innerhalb der x264-Prozess hochgesetzt, lookahead selbst ist allerdings noch nicht multithreaded.

    Was ist jetzt mit mbtree? Das arbeitet soviel ich weiß viel mit lookahead, (rc-lookahead), ist das quasi das gleiche und somit auch nicht multithreaded?

    ... der im Moment *eigentlich* auch aktuell sein müsste. Aber wie Selur schon sagt: brandaktuell für die jeweilige Version siehst du die Vorlagendetails mit x264.exe --fulhelp.


    Sorry, wollte deine Seite hier auch nicht irgendwie diffamieren oder kritiseren ;)

    Hab jetzt in die fullhelp reingeschaut, da steht ja doch alles beschrieben. Das --fullhelp Kommando kannte ich vorher noch nicht, habs immer mit der --longhelp versucht und da den entscheidenden Hinweis auf die --fullhelp übersehen :redface:

    Danke für die Hilfe

    Bumsfalara: Was erwartest/suchst Du den als Erklärung zu den Presets&Tune Einstellungen?
    mit x264 --fullhelp sieht man welche es gibt und was für Parameter sie ändern und die Namen der Settings weißen doch recht eindeutig darauf hin wofür sie gedacht sind,...

    Nein, sonst vermutlich auch die Anmerkung '(slow with high --bframes)' nicht mehr hinter der Option in der fullhelp stehen. ;) (damit b-frames 2 flotter wird muß der lookahead multithread fähig sein, was er akutell nicht ist)

    Cu Selur


    Welche Abweichnungen von den Standardeinstellungen sie vornehmen. Ich benutze das Tuning-System gerne, weil es Kommandozeilentipperei vereinfacht und ich es generell sinnvoll finde auch Hinweise oder Vorschläge der Entwickler einzugehen.
    Aber mittlerweile bin ich auch so lange im Geschäft, dass ich mir ungern blind alles vorgeben lasse. --no-fast-pskip steht bei mir beispielsweise immer in der Kommandozeile, auch wenn mir noch so oft gesagt wird es sei unsinnig: Meine Augen sehn den Unterschied :P

    Aber man sieht hier gar nicht den Unterschied zwischen slow und slower, was wird wirklich vorgenommen. Wie hoch sind dann die reference-Frames, wie hoch die b-frames etc. Klar, ich kann in der x264.c mir das alles rausfrimeln, aber das bei jeder neuen Version zu machen ist mühselig.

    Was macht denn --tune film mittlerweile? Immer noch deblock -2:-1 und psyrd 1:0,15
    -> Sowas stört mich, die Dokumentation dafür ist sehr einfach, aber dennoch anscheinend nicht vorhanden.

    Brother-Johns Encodingwissen wurde zuletzt am 4.2 aktualisiert, das ist bei der rasanten Entwicklung von x264 ne recht lange Zeit. Aber immerhin mal ein Anhaltspunkt.


    Die Bilder sind nicht ganz gleich weil ich die von Hand mitm VLC geschossen hab (oder ist das ein klares no-go?).

    Von Hand heißt mit Digitalkamera? :ohoh:
    -> Kann ich mir jetzt nicht vorstellen.

    Gute Vergleichsbilder kann man Beispielsweise im MPC-HC erstellen. Über strg+g kann man Framegenau im Video springen ;)



    Einen Weg automatisch zu croppen hab ich nicht realisieren können, also belass ich es bei der Quellauflösung - was erstmal der einfachere Weg ist.

    Es gibt diverse Programme, die automatisch croppen können. Evtl. mal deren Code anschauen und in deine Batch einbauen?


    Aber ok etwas mehr deblocking könnte ich mal testen und auch ein anderen Renderer werde ich vorher auch ausprobieren.
    Mit Mediaportal oder dem DVBviewer sollte ich das vorgeben können - beim DVBviewer gehts in jedem Fall.

    So wie ich das sehe ist x264 schon auf Deblock 0;0 eingestellt, das würde ich erstmal nicht weiter hochschrauben.
    Als erstes solltest du definitiv am Renderer war schrauben. Im VLC kann man den eigentlich auswählen, oder du probierst mal wie gesagt den MPC-HC aus, mit dem kann man sämtliche Moderne Renderer ansprechen.


    Ein intelligenteres Upscaling schon im avi-synth Script macht wenig Sinn weil dass den Speicherbedarf überflüssiger Weise erhöht, hm?

    Meiner Meinung nach macht das keinen Sinn, zur Not kann man das (je nach CPU-Power) auch anschließend immer noch den Decoder übernehmen lassen.
    Aber prinzipiell ist dafür der Renderer da. Haalis Renderer (muss separat installiert werden) oder auch der EVR-Custom (Ist seit Vista fester Bestandteil des Betriebssystems) beherrschen Bicubic-Upsampling, was bereits sehr sehr gute Ergebnisse liefert.

    Was ist daran veraltet? Der Thread is nicht mal 2 Monate alt.

    --preset name optimiert in Richtung encodingspeed
    --tune name optimiert in Richtung der Art des Materials

    x264 --help (bzw --longhelp) hilft auch weiter ;)

    Ich bin ja nicht total bescheuert...
    Die --longhelp hilft 0 weiter, da stehen lediglich die Namen der Presets.

    Was die Presets machen ist klar, aber die genaue Aufschlüsselung was sie an den Parametern ändern ist nicht gescheit dokumentiert.

    --preset faster fehlt zum Beispiel in dem Thread, MBtree ist dazugekommen was mittlerweile glaub ich standardmäßig aktiviert ist etcetc


    Selur
    Ich werd das mal durchgehen, kann ein wenig c++.
    Ist aber dennoch nervig dass die das nirgends hinschreiben.


    Hab jetzt hier was gefunden, damit kann man arbeiten.
    http://mewiki.project357.com/wiki/X264_Settings


    Edit: Irgendwas passt da nicht zwischen Medium und Slow: Die Geschwindigkeit halbiert sich im First-pass bei nutzung von zum Beispiel multithreaded ffmpegsource.

    Edit2: Kanns sein, dass --b-adapt 2 nicht Multithreaded ist?

    Hallo !

    Es belibt bei ~ meinen Formeln.
    Um ein paar Prozent(punkte) streite ich mich nicht.
    Natürlich ist ein PIV 1000 nicht 4 Mal schneller, als ein PI 250 (wenn es sowas je gab).

    Aber zwei (drei) aufeinanderfolgenden Prozessorgeneratioen stimmt das ungefär.
    Und da es im Moment KEINEN technologischen Durchbruch gibt, bleibt es bei den reinen MärchenHertz.

    Klingt komisch,
    ist aber so.


    Naja, ich schmeiß einfach mal den Corei7 in die Runde. Der zieht bei h264 Benchmarks, insbesondere bei x264 mit 4x2,67GHZ einen Yorkfield mit 4x3,8GHZ ab.

    Megaherz sind nur unter der gleichen Prozessorgeneration miteinander vergleichbar, über Generationen oder Hersteller hinweg macht das in meinen Augen keinen Sinn.

    Ansonsten auch mal hier drüber stöbern, ist auch ganz interessant ;)
    http://www.forum-3dcenter.org/vbulletin/showthread.php?t=446675

    Die jobHistory, JobList sollte im HomeDir des Users liegen, oder auf welche Tempfiles beziehst Du Dich?
    Bei meinen Tests wurden die Dateien in den Ordner gespeichert der bei Misc als Tempordner angegeben ist -> bräuchte ein paar erweiterte Informationen. ;)
    @Pittiplatsch: hast ne PM


    Zum Beispiel die .stats Datei: Die liegt im Temp Ordner von Windows.

    Im Ordner, den ich spezifisch angegeben hab liegt gar nichts.