Threadanzahl für x264

hallo,
Habe kurz eine Frage zu der Anzahl der max. sinnvoll möglichen Treads bei x.264 in Verbindung mit einem X6.
Die schnellste Encodingzeit mit dem X6 erreiche ich mit 15Treads, wobei ich aber mehrfach nun schon feststellen mußte das dies jenach Quali-Settings teils zu weglassen von Frames u./o. fehlerhaften Teilsequenzen führen kann und letzlich jenach Setting geh ich dann "sicherheitshalber" doch wieder nur auf 6Treads.
Auftreten tut der Effekt auch irgendwie nur, wenn ich 1080p H.264 Material nach x.264 (re)encode.
Von xvid, MPEG2 oder sonstwas nach x.264 = dabei tritt das "Frameweglassen bei hohen Treadanzahlen" hingegen nicht auf.
Es ist jetzt auch nicht so als ob das dramatisch wäre, weil die Zeiteinsparung zwischen 6 und 15 Treads auch nur bei max. 5% liegt - trotzdem würde mich mal interessieren wieso das setzen hoher Treadanzahlen -jenach Eingangsmaterial+Settings- zu Framedrop Problemen führen kann?

Hi,
es betrifft vdub, früher hatte ich mkv über das FCC Handler mkv Plugin geladen, das dauert aber teils lange da das mkv vorher erst komplett gescannt wird. Seit geraumer Zeit nutzt ich daher einen Directshow Filter zum import wo das mkv vorher nicht extra eingelesen wird (läuft dann über den Haali Splitter) und es scheint an dieser ImportFilter Kombi auch zu liegen. Bei Material wo ich diesen DS Filter mit dem Haali nicht nutze besteht das Problem wie ich gerade sehe, anscheinend auch nicht.
Na ja ok, ist dann halt so und man kann halt nicht alles haben.
Danke für die Hilfe, Problem hat sich geklärt.

Über das alte vdub kann man immer noch fast alles machen und hatte bislang auch (fast) nie etwas, was sich darin nicht bearbeiten ließ.
Eine Zeitlang hatte ich auch andere Tools (FFMPEg usw. jedoch über Guis) benutzt, doch seitdem der x.264vfw Support kontinuierlich erstaunlich up-to-date ist (das macht ein anderer als früher) nutze ich primär wieder nur vdub. Lediglich schneiden ist da halt bekanntlich mies (obgleich es da so en Cutassistant gibt) und auch das einfügen von Tonspuren funktioniert nicht immer zuverlässig, so daß man teils doch noch ergänzende Tools braucht - aber ansonsten ist das olle Tool immer noch ne gute + flinke Sache.
1080p habe ich nur sehr selten und mir war der Zusammenhang, daher auch nicht direkt aufgefallen das es an dem DS Filter auch liegen könnte.
Na ja, manchmal sieht man den Wald vor lauter Bäume halt nicht. :ani_lol:

Na sieh mal einer an, "der langsame Steinmetz" .. oho.. eine Metapher und zu welch lyrischen Höhenflügen unser werter LigH doch fähig ist ... und die Moral von der Geschicht? So, wenn er nicht gestorben ist, so trollt er auch noch heutzutage fröhlich unter uns bisweilen umher, um Korrekturen an schändlich gesetzten Satzzeichen vorzunehmen. Seinen gleichfalls besonders lobenswerten Einsatz zur Wiedereingliederung mißhandelter Buchstaben, wollen wir selbstverständlich nicht schmälern :lol: .. wo ihm unlängst das Wunder gelang ein Großes H mit seinem kleinen x, vor dem sicheren Untergang in den digitalen Fluten zu retten .....
So sprechen wir nun gemeinsam, das *Halleluja LigH, .... Halleluja*

Nun ja - also ich finde, du solltest hier umgehend eine Sekte gründen:
Weil mich hast du immerhin schon soweit überzeugt, das ich in wahre Lobeshymnen euphorisch ausbreche, um Kunde über deine Wunder zu tuen - denn wer braucht schon für die Praxis verwertbar sachbezogene Antworten in einem Fachforum?

Zitat

Zum Problem könnte mir nur einfallen, dass eine hohe Anzahl Threads vielleicht sehr viele Slices erzwingt, und eventuell manche Decoder nur ein gewisses Maximum an Slices pro Frame korrekt verarbeiten können. Aber das ist nur geraten.

Also ich hab das zwischenzeitlich hin/herprobiert und es scheint doch nicht alleine vom DS Filter abhängig.
Mit einem reingesteckten X4 konnt ich das nämlich teils auch so nicht reproduzieren. Interessant ist, das die Kerne des X6 ->jenach Eingangsmaterial<- offensichtlich nicht produktiv genutzt werden.
Besonders auffällig ist das bei den OTR HD-Aufnahmen, die als avi mit AVC/H264@50FPS vorliegen.
Ein X4@3Ghz konvertiert das nämlich genauso schnell wie ein X6@3Ghz, was normallerweise so nicht sein dürfte.

Es gab ja auchschonmal diesen MMX Bug mit dem X6/div. Encodern, ich halte es mittlerweile daher auch nicht für ausgeschlossen, das dies ev. ebenfalls irgendein X6 betreffender Bug ist. Div. Microsoft DirectX Sachen wie z.b. VMR9 funktionieren mit dem X6 unter XP schließlich ebenfalls nicht so ordnungsgermäß wie sie sollten.

Zitat

Aber den x264vfw werde ich bestimmt nicht benutzen. H.264 kommt bei mir nicht in eine AVI.

Es geht ja nicht darum ein solches video zu archivieren - sondern, es war ja nur einfach eine Frage woran das liegt. Auch damals mit dem Audiodelay, sowas gibts absolut nicht mit einem X4 oder Intel CPUs:
http://forum.doom9.org/showthread.php…highlight=crash
Das war ja auch definitiv irgendein Bug in der x264core der ausschließlich nur in Verbindung mit Thuban CPUs auftritt und wurde nach meinem Tread dort (zumindest) in der vfw Version behoben. Nur sind solche Thuban Bugs eigentlich auch in den "nicht vfw" Versionen behoben und gibt es ev. noch andere "X6 spezifische Tread-Bugs" ?
Das Audiodelay hing ja auch irgendwie mit der Treadverteilung wohl zusammen. (das lief vorher nur im sliced mode)
Und so manches fällt ja auch nur auf, wenn man imselben PC die CPUs mal hin/hersteckt.

Zitat

Nebenbei: Gibt es eigentlich ne Begründung warum OTR nicht mkv oder mp4 nutzt?

In der Community gabs dsbzgl. schon Umfragen, und die Mehrheit möchte wohl das avi Format (behalten), da es für viele nunmal einfach zu schneiden ist. User erstellen dort ja teils auch Schnittlisten, die kann man runterladen um die TV-Werbung "ohne Eigenaufwand" loszuwerden. Bei MKV, MP4 und ähnlichen Containern gibts aber eher wenig Cut-Freeware und wie das dann mit Schnittlisten aussieht, ist eine andere Sache. So gesehen verständlich, das avis dort größtenteils von den Usern positiv angenommen werden.

Bin zwar nicht ganz sicher (hab bislang nur ein testvideo gemacht), aber hab die Ursache glaube ich gefunden.
Liegt anscheinend an den video filter und post ahead Treading Settings, bin nämlich mal zurück auf eine ältere vdub Version (wo es diese Treading Settings noch nicht gab) und hab damit (zumindest bislang) keine Drop Frames mehr bei hohen Treads im encoder beobachten können.

Zitat

Da ich nun auch über einen Phenom-II X6 verfüge

Kurz eine andere Frage, laufen eigentlich die Koepi xvid Builds mit deinem X6 stabil, v.a. wenn du die neue VHQ metric und Quartel Pixel nutzt?

joa, war von mir und du bist der sneaker_ger, oder?