*offizielles deutsches flaskmpeg & dvdtoogm board* | *codecs*

*offizielles deutsches flaskmpeg & dvdtoogm board* » *codecs* » => man x264 <= (Hilfe zum x264 CLI)

» Hallo Gast [Anmelden|Registrieren]

Letzter Beitrag | Erster ungelesener Beitrag

Druckvorschau | An Freund senden | Thema zu Favoriten hinzufügen

=> man x264 <= (Hilfe zum x264 CLI)

Autor

Beitrag

« Vorheriges Thema | Nächstes Thema »

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

=> man x264 <= (Hilfe zum x264 CLI)

Zitatantwort auf diesen Beitrag erstellen

Da ich schon von einigen Leuten gefragt wurde ob ich nicht etwas wie ein Wissenswertes rund um x264 auch für das CommandLineInterface von x264 schreiben könnte habe ich mich mal drangesetzt und einiges niedergeschrieben.

Feedback, insbesondere Fragen, Anregungen und Verbesserungen sind gerne gesehen.

Aktuell ist Version: 0.0.9

ToDo:

- Scenecut-Beschreibung anpassen, siehe http://forum.gleitz.info/showthread.php?p=317141#post317141

- deadzone Beschreibung anpassen, kleinere Werte haben bessere Grainerhaltung zur Folge nicht umgekehrt. Augenzwinkern

Cu Selur

Dateianhang:

man x264 by Selur - 0.0.9.zip (99 KB, 28.145 mal heruntergeladen)

__________________
Hybrid

10.12.2005 20:51

Nehmen Sie Selur in Ihre Freundesliste auf

JoeB
Mitglied

Dabei seit: 11.05.2005
Beiträge: 37
Herkunft: Köln

RE: => man x264 <= (Hilfe zum x264 CLI)

Sehr schön - vor allem Deine Empfehlungen sind klasse und sehr gut argumentiert. Bringt ein feature wenig - stellst Du diesem die Verlangsamung des Encodens gegenüber -> so kann jeder selbst entscheiden.

Gut gefällt mir auch, dass Du jedes feature erstmal technisch erklärst und erst dann die Vor- und Nachteile erläuterst und schliesslich bereits oben erwähnte Empfehlung aussprichst.

Bilder würde ich auch weiterhin weglassen - man könnte ja MeGUI einblenden, aber weis schon was kommt großes Grinsen

__________________
cu

Joe
-----------------------------------------------------
freedom is just another word for nothing left to loose

11.12.2005 09:23

Nehmen Sie JoeB in Ihre Freundesliste auf

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Bilder werden wohl wenn nur zur Erklärung von Features kommen, ansonsten nicht. Bilder bei einem Kommandozeilentool erscheinen mir irgendwie affig. Augenzwinkern

Cu Selur

__________________
Hybrid

11.12.2005 12:13

akapuma
Routinier

Dabei seit: 01.01.2004
Beiträge: 297
Herkunft: Oberbergisches Land

RE: => man x264 <= (Hilfe zum x264 CLI)

Hallo Selur,

ich habe noch 2 Fragen:

zu -r bzw. -ref, "sollte normalerweise - 6 sein":
Warum schreibst Du hier 6 anstatt 5?

zu -b bzw. -bframes:
Sehe ich es richtig, daß deren Anzahl, entgegen früherer Empfehlungen im VfW-Wissenswertes, von 2-3 auf 3-5 hochgesetzt wurde?

Gruß

akapuma

18.12.2005 11:27

Nehmen Sie akapuma in Ihre Freundesliste auf

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

zu b-frames: Nein, hat sich eigentlich nicht groß geändert, für normale Encodes (wie ich im Wissenswertes anmerkte) würde ich immer noch 3 empfehlen, nur für Animes und niedrige Auflösungen würde ich bis 5 hochgehen. smile

zu ref frames: 5 oder 6 tut sich i.d.R. nichts, kannst ruhig auf 6 bleiben, bei sehr niedrigen Auflösungen (z.B für Handy) bringt sogar 16 noch was. Augenzwinkern

Hab wahrscheinlich 6 genommen, da ich in letzter Zeit öfter für niedrige Auflösungen mal etwa encoded hatte. smile

Cu Selur

__________________
Hybrid

18.12.2005 12:55

akapuma
Routinier

Dabei seit: 01.01.2004
Beiträge: 297
Herkunft: Oberbergisches Land

Hallo,

Aktuell ist Version: 0.0.4
Ziele für die nächste Version:
1. etweilige Fehler&Co beheben Augenzwinkern

Änderungen zu Version 0.0.3:
- etwas zur --bime Option geschrieben

ich poste mal hier, damit dieser Thread für Abonenten als ungelesen markiert wird. Daß es hier was neues gibt, hab ich nämlich erst im engl. doom9-Forum erfahen.

Danke Selur, weiter so. Ohne Dein Manual hätte ich nie von --bime erfahren.

Gruß

akapuma

30.12.2005 23:49

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

--bime gibt's erst seit heute, also kein Wunder das Du es nicht kanntest Augenzwinkern

siehe: http://mirror01.x264.nl/x264/changelog.txt

__________________
Hybrid

31.12.2005 00:14

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Okay, ich hatte das Deblocking falsch verstanden:

Zitat:

Deblocking strength is controled by values called alpha & beta. These values are computed for each macroblock according to the quantizer of this macroblock, the quantizer of its neighbour, and the offset you set ( the famous value that range from -6 to +6 ).

Here are the tables for alpha & beta, indexed by 'quantizer + offset' :

code:

1:
2:
3:
4:
5:


alpha : 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 5, 6, 7, 8, 9, 10, 12, 13, 15, 17, 20, 22, 25, 28, 32, 36, 40, 45, 50, 56, 63, 71, 80, 90,101,113,127,144,162,182,203,226, 255, 255
beta : 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 6, 6, 7, 7, 8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 14, 15, 15, 16, 16, 17, 17, 18, 18

The higher these values, the stronger the deblocking. When one of these is null, there's no deblocking on the macroblock.

As you can see, when 'quantizer + offset <= 15', both alpha and beta are null, so no deblocking is applied.

Alpha is used to determine whether the frontier is blocky or if it's actually a detail. It works like a threshold. Beta also works as a threshold, but is used to insure that on both side of the frontier, the picture is homogenous enough ( once again, to separate detail from blockiness ).

Once you've decided whether or not to filter the frontier, alpha is used to decide the strength ( in fact, the maximal allowed modification to a pixel ). beta can slightly modify this strength, is the macroblock is flat enough.

So in the end, foxyshadis' description is a bit too simple. Both offsets decide which blocks, and the first one influences the bluriness the most.

Quelle: http://forum.doom9.org/showthread.php?p=765770#post765770

Mal schauen wie man das am Besten fürs Wissenswertes übersetzt. smile

(Vorschläge sind gerne gesehen.)

Cu Selur

__________________
Hybrid

11.01.2006 06:06

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Aktuell ist Version: 0.0.5

Änderungen zu Version 0.0.4
- Deblockingbeschreibung gekürzt
- adaptive quantizer Parameter hinzugefügt

Cu Selur

__________________
Hybrid

15.01.2006 11:29

akapuma
Routinier

Dabei seit: 01.01.2004
Beiträge: 297
Herkunft: Oberbergisches Land

Hallo,

Zitat x264-changelog:
r456: change default direct mode to spatial

Zitat "Wissenswertes":
"und temporal sieht meist, meiner Meinung nach, etwas besser aus"

Was ist davon zu halten? Läßt man den Parameter weg, wie im Wissenswertes empfohlen, hat man jetzt nicht mehr "temporal", sondern "spatial". Sollte man den Parameter jetzt weiterhin weglassen und "spatial" verwenden, oder sollte man --direct temporal verwenden?

Gruß

akapuma

Edit: vielleicht besser "--direct auto"

Gruß

akapuma

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von akapuma: 05.03.2006 11:59.

05.03.2006 11:57

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Persönlich fand ich temporal sah besser aus => würde also --direct temporal verwenden,...
Gibt's den irgendwo ne Begründugn warum gewechselt wurde?

Zitat:

--direct auto
selects direct mode per frame. works best in 2pass (enable in both passes).

COOL, endlich! smile

=> DAS sollte ab jetzt der Defaultwert für einen sein. smile

__________________
Hybrid

05.03.2006 11:59

akapuma
Routinier

Dabei seit: 01.01.2004
Beiträge: 297
Herkunft: Oberbergisches Land

Siehe mein "Edit" im Beitrag vorher.

05.03.2006 12:00

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

*gig*

Aktuell ist jetzt Version: 0.0.6

Änderungen zu Version 0.0.5
- automatisch Entscheidung ob Motionvektorendifferenzen der Makroblöcke eines B-Frames spartial oder temporal ermittelt werden ist nun möglich

Anmerkung:

Spatial sieht bei langsamen und temproal bei schnellen Szenen etwas besser aus als das andere. Augenzwinkern

__________________
Hybrid

05.03.2006 12:01

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Hab "man x264" auf Version 0.0.7 upgedatet.

Änderungen zu Version 0.0.6
- ein paar Typos
- einige Parameter hinzugefügt: sps-id, qpfile, no-dcr-decimate
- bei den Adaptive Quantizer Parametern angemerkt, dass sie nicht im Standard SVN enthalten sind (handelt sich um Patches von Usern)

Cu Selur

__________________
Hybrid

07.08.2006 11:04

Selur
spamming old Newbie

Dabei seit: 13.03.2002
Beiträge: 10.933

Themenstarter Thema begonnen von Selur

Aktuell ist Version: 0.0.8

Änderungen zur 0.0.7:
1. Neu Parameter: --version, --direct-8x8, --deadzone-inter, --deadzone-intra
2. Umbennenung von alten Parametern

Cu Selur

__________________
Hybrid

24.10.2006 15:04

Baumstruktur | Brettstruktur

*offizielles deutsches flaskmpeg & dvdtoogm board* » *codecs* » => man x264 <= (Hilfe zum x264 CLI)

WBB, entwickelt von WoltLab GmBH