Und noch eins:
r430: VfW: support trellis, brdo, nr, bime. patch by Dan Nelson (dnelson at allantgroup dot com).
Und noch eins:
r430: VfW: support trellis, brdo, nr, bime. patch by Dan Nelson (dnelson at allantgroup dot com).
gleich mal nuckeln,... eventuell mach ich dann morgen abend ein Update des Wissenswertes
yup, ist wirklich im vfw Interface:
More->Noise Reduction
More->Trellis
B-Frames->Bidirectional ME
Partition decision->7 (RDO on B-Frames)
=> werd mal gucken, dass ich morgen abend Zeit finde das Wissenswertes rund um x264 upzudaten.
Cu Selur
Weiss jemand ob es für den Athlon-XP optimierte Builds gibt, bzw wie man selber noch über cflags mehr Leistung rausholen könnte?
Ich baue mir momentan x264 immer selber aus dem svn-repository und habe -march=athlon hinzugefügt (athlon-xp gab ne Fehlermeldung beim Kompilieren). Gibt es noch irgendwelche anderen Möglichkeiten der Optimierung?
Und was bedeutet das DHAVE_SSE2? Das ist per default dabei und klingt für mich als sollte es dann auf nicht-sse2 CPUs gar nicht laufen, tuts aber.
"VfW: cosmetics"
gut das ich mich heute abend erst daran setze sonst könnte ich etweilige Screenshots direkt in die Tonne treten.
Cu Selur
ich denke heute abend werd ich erstmal gucken ob es nicht schon wieder einige Updates gibt
Zitat von burWeiss jemand ob es für den Athlon-XP optimierte Builds gibt, bzw wie man selber noch über cflags mehr Leistung rausholen könnte?
Ich baue mir momentan x264 immer selber aus dem svn-repository und habe -march=athlon hinzugefügt (athlon-xp gab ne Fehlermeldung beim Kompilieren). Gibt es noch irgendwelche anderen Möglichkeiten der Optimierung?
Und was bedeutet das DHAVE_SSE2? Das ist per default dabei und klingt für mich als sollte es dann auf nicht-sse2 CPUs gar nicht laufen, tuts aber.
Speziell auf einzelne Prozessortypen optimierte Builds gibts nicht.
Zu Compileroptionen: Sharktooth verwendet imho profiling, und gcc 4. Seine genauen Flags stehen hier irgendwo drin:
r435: cosmetics
r436: -q0 --b-rdo wasn't lossless
r437: ratecontrol didn't always account for header bits, causing an undersize in multipass with --ratetol inf.
r439: * encoder/ratecontrol.c: OS X support for exp2f and sqrtf.
440: trellis=2 slightly affected intra analysis even without subme=6
kann es sein das Sharktooth z.Z. keine neueren Builds herrausbringt?
bei mir ist immernoch die version 408...
Ja. Er ist gesundheitlich angeschlagen.
Jede Menge updates heute morgen:
r441: lowres intra used wrong neighboring pixels
r442: h->mc.copy()
r443: copy current macroblock to a smaller buffer, to improve cache coherency and reduce stride computations.
part 1: memory arrangement.
r444: part 2: intra prediction
r445: part 3: asm
{ Bitte immer die letzten Revisionen aus der "changelog" sammeln, dafür gibt's - statt löschen und antworten - den [Blockierte Grafik: http://forum.gleitz.info/images/buttons/edit.gif] | LigH }
r446: 10l in r443 (p4x4 chroma)
r447: common/i386/i386inc.asm: tell the ELF linker about our stack properties so that it does not assume the stack has to be executable.
r448: configure common/i386/i386inc.asm: got rid of -DFORMAT_* nasm flags and use built-in preprocessor tests instead.
r449: common/i386: factored the .rodata section declaration into i386inc.asm.
Gibt es eigentlich schon Pläne von den Revisionsnummern abzusehen und dann auf Versionsnummer, Alpha, Beta zu gehen?
Schließlich wird schon lange daran gewerkelt. Welche Ziele werden denn noch angestrebt?
@ Deinorius:
"Revisionen" sind für SVN (die "bessere Konkurrenz" zu CVS als Quelltext-Versionsverwaltung) typisch, das wird wohl (erst mal) so bleiben.
Weitere Spekulationen passen nicht in einen News-Beitrag...
Laut Sirber kompiliert auch ChronoCross x264 Builds, mit einigen, wenn sogar den meisten Patches, die auch Sharktooth angewendet hat.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!