Beiträge von Der_Lurchi

Hallo Sneaker,
herzlichen Dank für die super Info,
Hab die "unset" Psy Werte wie du gesagt hast nun aus der Preset übernommen und jetzt sieht das Film Tune auch so aus wie es sollte und hab nun ein schönes alternatives Tune für div. anderes Ausgangsmaterial.
Für mehr Grain werde ich dahingehend tendentiell eher bei meinem Setting bleiben, das -Tune Grain habe ich ausprobiert, doch die niedrigen deadzone Werte schießen mir die Dateigröße doch was zu hoch.

Dein Posting hat mir wirklich sehr weitergeholfen, :ja:
die Frage bzgl. vbv hat sich indirekt auch erledigt. Das --sync-lookahead habe ich jedoch gesetzt, denn es scheint mir etwas Zeitersparnis beim CRF Encoding zu geben. Heut ist auch ein neues Build x264vfw2146K rausgekommen und habs gleich mal runtergeladen, das ist schon eine tolle Sache das x264 immer wieder überarbeitet und verbessert wird.

Hi,
nachdem was Zeit vergangen ist und ich im Nachhinein ja doch einsehen mußte, das meine Settings vorher schlecht waren, habe ich mich über die letzten Wochen daher versucht mehr ins encoding einzuarbeiten - wohl auch zwangsläufig gewzungen aufgrund der Festplattenpreise und das größenmäßig unoptimierte Files archivieren derzeit teuer kommen. :ani_lol:

Den B-Frames habe ich mich so angenommen:
bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1

Sowie desweiteren habe ich gesehen, das es wohl auch Sachen wie -MBTree, -Tune usw gibt die in der Gui fehlen und was ich daher über die Extra Options folgendermaßen Kommandozeile hinzugefügt habe:
--mbtree 1 --rc-lookahead 60 --sync-lookahead 10
Beim Rest steige ich aber nicht ganz durch: --vbv-maxrate, -vbv-bufsize, -keyint
In welchem Zusammenhang steht dies zum Mbtree, setzt man hier nix?

Mein momentanes Profil sieht so aus:
cabac=1 ref=3 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=9 psy=1 fade_compensate=0.00 psy_rd=0.56:1.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-1 threads=9 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=20.0000 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=2:1.00

Filmkörnung bleibt so teils erhalten (mag keine zu glattgebügelten/plastischen Bilder), aber gewiß geht das alles (jenach Ausgangsmaterial) besser und nun würde mich daher natürlich auch noch in dem Zusammenhang interessieren wie es mit den originalen x264 Tune Werten aussieht und hab dafür Google bedient; bin aber nicht sicher ob das auch alles so richtig meinerseits ergoogelt wurde:

tune grain:
-aq-strength 0.5 --no-dct-decimate
-deadzone-inter 6 --deadzone-intra 6
-deblock -2:-2 --ipratio 1.1
-pbratio 1.1
--psy-rd 1
-psy trel 0.25
-qcomp 0.8

tune animation:
--bframes {+2} --deblock 1:1
-psy-rd 0.4
- psy trel unset?
--aq-strength 0.6
--ref {Double if >1 else 1}

tune stillimage:
--aq-strength 1.2
--deblock -3:-3
--psy-rd 2.0
-- psy Trell :0.7

tune film:
--deblock -1:-1
-psy-rd unset?
-psy Trellis 0.15
-psy VAQ unset?

Wird bei Tune Film wirklich gar kein PSy RD und VAQ gesetzt?

Zitat

Vielleicht hilft es für diese unnötig beschränkten Programme, sich in der msconfig eine Kopie des BCD-Starteintrags zu erstellen, in welcher die Anzahl der "Prozessoren" (bzw. Kerne) auf 4 begrenzt wird - siehe Windows7Tipps; Kopieren vielleicht mit EasyBCD.

Auf dem PC wo ich encode nutze ich (zwar) noch XP, aber man kann Programmen ansonsten Kerne auch einfach per Easytools fest/dauerhaft zuweisen. Betroffen waren bei mir primär die alte Terratec (DVB-T) Software sowie der KMPlayer (allerdings nur in Verbindung mit MadVR).
Alles andere was ich an Software hab läuft mit dem X6 incl. aller Kerne ansonsten stabil. (von dem eigenartigen vdub Verhalten sowie dem Koepi xvid abgesehen, wobei ich da aber eher denke das es nur an dem Build liegt)

AMD Turbo ist deaktiviert. (der ist ohnehin total nutzlos und nicht vergleichbar mit der von Intels)
Bei DirectX9 Problemen liegt es einfach daran das manche Microsoft dll´s teils nicht mit mehr als 4Kernen in verbindung mit 3dnow umgehen können: http://www.progdigy.com/forums/viewtop…aa248a8b1c8074c
Seitens MS gabs für XP usw. zwar einen Hotfix, nur gibts den aber auf der Microsoft Seite nicht als öffentlichen Einzeldownload.

Und Thuban Probleme mit div. Games sind auch "OS-übergreifend":
http://community.codemasters.com/forum/f1-2010-…ading-race.html
Vor ein Jahr hatte ich F1 2010 gekauft (stürzte immer ab) und ein halbes Jahr später erst, gab es einen funktionierenden ThubanFix - nur, muß sowas eigentlich umgehend vom Hersteller kommen. Und bei irgendwelchen älteren Programmen, sind Hersteller auch nicht sonderlich bemüht noch Updates zu bringen und man kann in so Fällen, dann eigentlich nur die Kernanzahl begrenzen und darauf hoffen das dies alleine ausreicht.

hallo Selur
Wie gesagt scheint es imo mit dem Threadingoptionen des vdub zusammenzuhängen, allerdings tritt dieser Fehler nur sporadisch auf.
D.h. bei 20 encodings ist vielleicht 1 drunter was "falsch" ist. Mit der 1.9er scheint das eher nicht zu passieren, aber dort ist das Encoding natürlich auch wieder langsamer. Daher bin ich nun wieder zurück auf 1.10. und hab das Program mal nach jedem Encoding neugestartet, denn so wie es aussieht scheint das warum auch immer ebenfalls zu helfen.
Sehr eigenartige Sache.

MadVR läuft nun auch, nachdem ich dem KMPlayer nur 4Kerne zugewiesen habe und statt des internen KM Video Decoders einen externen nutze. Nur alles ziemlich viel gefrickel und hätt mir im nachhinein wohl besser einen Intel Quad gekauft (der ohnehin auch schneller ist), denn so manche Sachen scheinen ja nicht unbedingt sonderlich "AMD X6 optimiert" zu sein.

Ja das x264vfw X6 Treading Problem ist gelöst und nachdem ich nun weiß, das diese AMD CPU die Ursache auch für viele andere Probleme ist, geh ich eins nachdem anderen an.
Für das Overlay Problem in div. Playern habe ich mittlerweile auch eine Lösung gefunden. Man kann über ein zusätzlich erstelltes Dword für die Processor specific graphics pipeline (PSGP) das AMD 3DNow! in der Registry deaktivieren, so daß statt 3DNow! auf SSE2 zurückgreifen wird. Das erfährt man natürlich nicht auf der Microsoft Seite - aber sieh da SSE2 statt 3DNow und VMR9, EVR C/A, Haali Overlays usw. funktioniert nun alles plötzlich mit dem X6. :ani_lol:
(bis auf MADVR)

Probleme in div. Games (auch diese nvidia ntdll. crashes) lagen ebenfalls an der CPU.
Für manche Sachen wie z.b. die Codemasters Games gibts auch div. Thuban Hotfixes usw, nur funktionieren die allerdings teils nicht, ohne das man zusätzlich noch manuell div Registry Einträge vornimmt.
Sowas hatte ich mit noch keiner CPU und ist extremly uncool. :cool:

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

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?

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.

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.

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?

Ü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:

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.

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?

Joa, die Sachen sind otr seitig nochmals gut runtergepreßt - anscheined meist 1.3-2gb pro Film groß.
Das Bild wirkt leicht "weichgespült" (hatte den Effekt, aber auch schon bei einer 10GB DBV-S HD Aufnahme eines Kumpels u.U. ist das auch Senderseitig bzw. schlicht jenach Ausgangsmaterial schon so).
Hatte die Aufnahmen auchnochmals umkomprimiert um sie was schärfer abfiltern zu können, das dies zwar nochmals Verluste bedeutet ist klar - dennoch sind die OTr hd Aufnahmen einiges optisch besser als dasselbe was ich hier über DBV-T reinkrieg. Man hat im direkten Vergleich kaum groß Rauschen oder gar fiese Klötzchenbildung, vom Ton ganz zu schweigen.

Ja, hab das eben auch gesehen das die wohl ein eigenes Forum haben, iss mir vor lauter PopUps gar nicht anfangs aufgefallen. :lol:
Das mit Delay setzen ist mir soweit klar, allerdings nervig und fummelig. Hab jetzt nochmal ein HD aufgenommen und da hatte die AC3 Spur auf anhieb gepaßt - war dann wohl ein Aufzeichnungsfehler oder so. Soweit ich das da verstehe, werden aber nur die am meisten programmierten filme in HD aufgezeichnet.

Gibt es außer otr daher eigentlich noch eine andere Möglichkeit online in Hd was aufzunehmen?
(hab nur DVB-T, das ist echt lumpig vorallem wg. dem miesen Sound :nein: )

Hallo,
habe ein aufgezeichnetes video:
codec H.264
audio mp3
Container AVI
(bevor draufrumgeritten wird, der onlinevideorecorder nimmt H.264 in AVI auf)

Seperat kann man dann zu dem avi dort ja auch noch eine AC3 Spur downloaden, die ich einfach per vdub eingefügt hab. Beim abspielen stelle ich nun aber fest, das der Ton mit ac3 vor dem eigentlichen Film (wg. des EPG ist da ja was Vor/Nachlauf) zwar synchron ist - aber sobald der Film beginnt nicht mehr.
Beim Vergleich der Längen, zeigt das (ursprüngliche) avi 1.45.49
die optional zum download erhältliche AC3 Spur hingegen nur 1.45.48

Wieso ist die AC3 Spur kürzer und wieso entsteht die Unsynchronität ausgerechnet genau bei Beginn des HD-Film? Entsteht das durch Aufzeichnungsfehler seitens OTR wenn ev. der Sender von Format X auf Ac3 umswitcht oder wieso?

Das THG Tool kenne ich und das funktioniert auch damit, nur leider hat das Tool den Nachteil des es sich nicht minimieren läßt.
Es läßt sich zwar über Eigenschaften des Arbeitsplatz so einstellen (oder im autostart per Batch start /b /min TaskAssign.exe
) .... das es zwar "unsichtbar" mitstartet, nur landet in der Taskleiste.
Obs einen Command für den Tray gibt, weiß ich nicht.
(mit einem zusätzlichen Tool wie TrayIT ginge es natürlich)

Zitat

Wiederholfrequenz von 54.xyz Hz ist nicht besser als 60Hz. Es ist nur "anders schlimm".

Das bestreite ich nicht, denn es minimiert den Effekt nur und verursacht dabei eine Unschärfe bei Schwenks - das ist allerdings wenigstens angenehmer zu betrachten als das vorige "Bildgestottere". Und das ein neuer TFT auf Sicht hermuß, das ist klar - nur muß die Anschaffung momentan warten und d.h. erstmal das "verträglichste" aus der Situation machen.
ReClock hatte ich vorher schon probiert, das hatte allerdings rein subjektiv leider nicht geholfen.

Zitat

a) es MUSS Tearing auftreten (Vsync OFF), weil es gar nicht anders geht.

Und warum tritt das Tearing nur unter EVR und in allen anderen Modes bei 54Hz nicht auf?
Arbeiten die anderen Modes mit aktiviertem vysnc und EVR nicht?

hi,
Nun ja, wenn man selbst nix weiß, kann man sich dann natürlich auf rumgeunke beschränken. :zunge:
Nichtdestotrotz wird es dennoch gewiß ein Tool geben, was permanent einer Anwendung eine bestimmte Anzahl an Kerne zuweisen kann (womit sich das VRM9 Problem auch logischerweise fixen läßt).

Und was MadVR angeht,
du willst aber doch nicht ernsthaft womöglich gar behaupten , das ein "moderneres System" dessen Kompatililät erhöht? :ani_lol: :ani_lol: :ani_lol:
Man selbst einem Hoss leuchtet ein, solange man in div. Playern wie VLC, GOM solch externe Renderer nicht auswählen kann = solange wird es vollkommen unabhängig vom PC/OS auch nicht funktionieren: http://forum.videolan.org/viewtopic.php?f=7&t=79902
Steht doch da schwarz auf weiß, kein Playersupport = keine Funktion.
Es sei denn irgendjemand hat hier irgendeinen Trick parat, wodurch externe (!) Renderer erlaubt werden in o.g. Playern. (womit wir wieder bei der Eingangsfrage sind)

Hallo,
wollte die Ausgabequalität beim abspielen an meinem PC etwas optimieren, was leider ein "paar Stolpersteine" hat. Um Bildstuttering bei Kamreraschwenks zu beseitigen, hatte ich erstmal die wIindows 60Hz Default per Powerstrip auf 54HZ gesetzt (weiter runter geht der TFT nicht) Das hat aber schon was gebracht, nur leider führt das jedoch zu dem Problem, das unter EVR nun ein Tearing entsteht (wie in Games, wenn kein vsync an ist).
Dachte ich mir install mal MADVR, das läuft zwar nur leider nicht mit meinem bevorzugten GOM Player.

OK also VMR9, nur dummerweise crashed das mit der ntdll/D3D9 :ani_lol:
Hatte ja mal kurzzeitig ein Problem mit vfw codecs in Verbindung mit dem X6, was glücklicherweise mit einem Bugfix beseitigt wurde. Nun gut, kann bei solchen Sachen (die wenige Leute nutzen) ja vorkommen - nur ist VMR9 ja nix "exotisches oder seltenes" doch muß ich nun leider feststellen, das auch dieses VMR9 Video Renderer Problem ebenfalls mit dem Mehrkerner zusammenhängt:
http://www.progdigy.com/forums/viewtop…94c2421fcb165c7
Das bezieht sich zwar nicht gezielt auf Softwareplayer, doch es ist so wie es da steht.
Macht man einen Downcore auf 1,2,3 oder 4 Kerner, dann funktioniert tatsächlich VMR9.
Sind 5 oder 6 Kerne aktiviert, dann crashed es hingegen.

Welche Möglichkeiten gibts nun?
# Gibt es einen Weg MADVr im Gomplayer ans laufen zu kriegen?
# Falls nicht, wie kriegt man unter EVR das Tearing unter 60Hz weg.
# Falls es dafür auch keine Möglichekeit gibt, wie kriegt man VMR9 unter XP gezielt/permanent einer Anwendung weniger Kerne zugewiesen? (ohne per Taskmanager das "dauernd per Hand" zu tuen)