x264 Problematik seit ca. 6 Monaten... ? Oder auch nicht...

    Hallo, ich war schon lange nicht mehr hier... was wohl aussagt das mir hier damals sehr gut geholfen wurde ;)

    Folgende Problematik drückt mich aber...
    Nur beim FullHD codieren (z.B. 1920x1080/800 usw.) brechen Programme wie Mediacoder oder tx264 das codieren irgendwann mit einem Fehler in x264.exe ab. Das habe ich seit ca. (grob) Mitte 2012... bisher dachte ich immer es liegt an meinem übertakteten x1090, aber jetzt bin ich anderer Meinung.

    Es hat mich bisher nicht sonderlich gejuckt, weil mit Handbrake das ganze absolut stabil ablief, aber Handbrake nutzt eine recht "olle" Version von x264. Handbrake selber ist die V 09.8. vom 17.07.12.

    Wieso ich das denke, nun... zum einen habe ich den Rechner mal auf normal getaktet und zum zweiten: Ich kann folgendes GLEICHZEITIG machen:
    1. Über die Technotrend DVB_S2 USB Karte was in HD aufzeichnen/schauen
    2. Mit XMediaRecode Clips in AVI (XVID&MP§) zum schneiden codieren
    3. Mit VirtualDub 2. scheiden
    4. Mit Handbrake einen HD Film codieren
    5. Mit xxxxxxxxx eine blaue optische kopieren
    6. Mit dem Tiger II in WoT ins Gefecht ziehen oder FarCry3 zocken

    Das juckt meinen PC weitestgehend gar nicht! Egal ob der auf 6x3.2 oder 6x3.8Ghz läuft. Das Teil besteht auch nur aus quasi "Testsiegern"... Netzteil, Board, Marken-RAM usw. und die CPU geht auch nicht über 45°, d.h. das Kühlungskonzept war ein wichtiger Bestandteil beim Kauf der Komponenten.

    Weil das Teil normalerweise sehr stabil rennt, nur x264 seit ca. Mitte 2012 Probleme macht, vermute ich das es an x264 liegt. Ja, SD Material codiert die Kiste mit 6x100% CPU Auslastung auch mit Mediacoder problemlos... codiere gerade die ganzen Konzerte von 3sat...

    Weiß da einer was?

    Hier mal meine Einstellung die ich eigentlich in allen Programmen nutze:
    hb_x264.jpg

    Folgendes habe ich noch vor:
    1. Ich werde schauen ob ich in Handbrake die x264.exe mal PROBEHALBER durch die aktuelle ersetze.
    2. Mal Hybrid anschauen

    Bei HandBrake läßt sich nicht einfach die x264.exe austauschen, da dort libx264 direkt eingebunden wird. Könntest aber eine Nightly testen, wobei ich nicht weiß, auf welchem Versionsstand dort x264 im Moment ist.

    Was sagen denn Programme wie Memtest etc.?

    Hat sich wohl erledigt...
    Hab mir Hybrid installiert... hat heute Nacht ohne Probleme drei M2TS mit VC1 1920x800 mit Preset SLOW codiert. Auch heute keinerlei Probleme mit Hybrid... also wird das Problem höchstwahrscheinlich weder an meiner Hardware, noch an x264 liegen. Und die Kiste rennt anstatt 6x3.2 auf 6x3.75Ghz... dann kann ich ja mal wieder hochtakten... ;)

    Anmerkung, ich habe eine ganz vage Vermutung das es an der Einstellung vom Mediacoder liegt:
    x264.exe" --no-progress --tune film --weightp 2 --b-pyramid strict --bluray-compat --scenecut 40 --rc-lookahead 80 --b-adapt 1 --keyint 250 --min-keyint 25 --nondeterministic --aq-mode 1 --aq-strength 1.0 --subme 7 --ref 5 --me umh --merange 16 --bframes 3 --trellis 1 --weightb --direct auto --no-psy --crf 22 --sar 11:15--threads 9 --demuxer raw --input-res 1920x792 --fps 24000/10

    Fällt einem ein was da Unsinnig ist...? Bzw. was auf einem 6 Kerner dazu führt das x264 nur bei FullHD Material mit einem Fehler beendet wird?

    Ist aber auch nicht so wichtig... Handbrake und Hybrid werden wohl den MQ auf lang ersetzen.

    Win7 x64 mit 8GB RAM und 64bit x264... habe beim codieren eigentlich immer den Sysinternals Systemexplorer laufen... phys. RAM war noch nie ein Thema, meist immer um die 4GB noch frei.
    Das fehlende Freizeichen wird daherkommen da sich aus der DOS-Box kopiert habe und händisch alles in eine Zeile rückte...

    Aber nicht so wichtig... nehm ich halt Hybrid oder Handbrake... hauptsache ich weiß das es nicht an meiner Hardware liegt.

    Lösung (vermutlich):
    Das Problem scheint das hier gewesen zu sein: --nondeterministic
    Laut me.wiki sollte das default-off sein... hab ich mal gemacht... bei den anderen Programmen ist das auch aus... und siehe da... die Kiste lief die Nacht ohne Probs durch.

    Nur zur Info... Gruß Andre

    "... denn sie wissen nicht, was sie tun" — da steht was von "Slightly improve quality", der Rest ist unwichtig. ;)

    Der Qualitätsgewinn dieser Option dürfte bei ansonsten reichlicher Bitrate so dermaßen vernachlässigbar sein, dass diese Option hier wahrscheinlich noch nie jemand überhaupt ausprobiert hat. :ani_lol:

    Ich weiß gar nicht, ob ich die überhaupt genau verstehe. Wahrscheinlich wird da nur der Code der verlustlosen Komprimierung durch ein Durchprobieren mehrerer Ansätze optimiert. Vergleichbar vielleicht mit PNG-Optimierern. Das kostet hauptsächlich mehr Rechenaufwand, bringt auf die Gesamtgröße aber wohl kaum Promille an Unterschied.

    Den eigentlichen Einfluss auf ein gutes Qualitäts-Leistungs-Verhältnis haben die verlustbehafteten Funktionen, ohne die läge das Größenverhältnis zu unkomprimiertem Video nicht jenseits von 1:1000.
    __

    P.S.:

    Noch nicht einmal. Dabei werden nur die Encoding-Threads nicht ganz so streng synchronisiert, die Bewegungsschätzung kann dabei etwas schneller auf etwas größere Bereiche zugreifen. Es wird ein wenig seltener gewartet, bis etwas anderes fertig ist, also wird die CPU besser ausgelastet und dadurch ein wenig heißer.

    Übrigens ist in "--non-deterministic" noch ein Bindestrich drin. Also stimmt außerdem was mit deiner Optionsliste nicht.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden