*offizielles deutsches flaskmpeg & dvdtoogm board* | Druckvorschau: => Wissenswertes rund um x264 <=

Geschrieben von Selur am 13.02.2005 um 20:46:

=> Wissenswertes rund um x264 <=

'Wissenswertes rund um x264' großes Grinsen

Update auf 0.1.6 und damit die vorerst letzte Version ist draußen!
Warum, vorerst die letzte Version?
Einfach, mit SVN Version 581 wurde offiziell die Entwicklung der VFW Schnittstelle auf Eis gelegt -> ehe sich ein neuer Entwickler findet der sich um die VFW Schnittstelle kümmert ist ein weiterführen des Wissenswertes rund um x264 unsinig.

Cu Selur

Geschrieben von scrat am 13.02.2005 um 21:41:

hey!

hättest du die version nicht ne stunde früher online stellen können? dann hätte ich mir das lesen des englischen doom9-guides erspart großes Grinsen

(hab mir für heute nämlich mal vorgenommen mir x264 anzuschauen)...

mfg
scrat

Geschrieben von Selur am 13.02.2005 um 22:03:

Dann hier schonmal ne Vorwarnung:
morgen abend bring ich ein Update raus, da ich ein paar Kleinigkeiten Missverstanden hab, die aber dank akupenguin under mplayer manpage gerade durch lesen geklärt werden. Augenzwinkern

Cu Selur

Ps.: 0.0.2 ist draußen

Geschrieben von Selur am 16.02.2005 um 10:59:

0.0.5 ist draußen

Geschrieben von Selur am 06.03.2005 um 14:30:

Zitat:

Changelog
0.0.5 nach 0.0.6
- Deblocking Filter Strength(A) und Strength(B) heißen nun auch Strength und Threshold
- B-Frame Pyramide

Cu Selur

Geschrieben von Dreamer 2002 am 06.03.2005 um 19:00:

Irgendwie verpenne ich das wichtigste von dir Selur! Aber nun hab ichs auch bemerkt das du fleißige Biene schon wieder ein super gutes Guide gemacht hast! BIG THX Selur smile

Dreamer 2002

Geschrieben von Selur am 08.03.2005 um 10:27:

Vielleicht mal ganz interessant, falls man wissen will wie die B-Frames gespeichert und in welcher Reihenfolge sie abgespielt werden.

Zitat:

Encoding delay is equal to the max consecutive B-frames. Decoding delay is 1 when traditional B-frames are used, and 2 when B-pyramid is used.

Note that only 1 delay is needed in order to ensure that each decoded frame is available in time for output:

code:I b b b P
1 2 3 4 5 ; input order

I P b b b
1 5 2 3 4 ; coded order
- 1 2 3 4 5 ; display order

With B-pyramid, you need 2 delay to make sure frame#2 is decoded in time:

code:I b B b P
1 2 3 4 5 ; input order

I P B b b ; coded order
1 5 3 2 4
- - 1 2 3 4 5 ; display order

Either way, decoding delay is independent of max B-frames:

code:I b b b B b b b P
1 2 3 4 5 6 7 8 9 ; input order

I P B b b b b b b ; coded order
1 9 5 2 3 4 6 7 8
- - 1 2 3 4 5 6 7 8 9 ; display order

But note that the current B-pyramid is not the only way to use B-refs. Not all strategies require extra reordering, and some require more than 2 decoding delay and/or extra encoding delay. The following (not used by x264) requires 3 delay:

code:I b B b B b B b P
1 2 3 4 5 6 7 8 9 ; input order

I P B B b b B b b ; coded order
1 9 5 3 2 4 7 6 8
- - - 1 2 3 4 5 6 7 8 9 ; display order

Of course, when I speak of delay, it only means delay between when you give a coded frame to the codec and when it returns the result. If the demuxer provides correct timestamps, the player can always decode enough frames in advance that the user won't see any delay.

Quelle: http://forum.doom9.org/showthread.php?s=&postid=621685

Geschrieben von Selur am 09.03.2005 um 09:02:

Zitat:

Changelog
0.0.6 nach 0.0.7
- GUI im Advanced Featurebereich wurde umgestaltet
- Weighted Prediction
- Deblocking Threshold wurde entfernt
- Meine Empfehlungen farblich in Grau eingefügt

Weiß jemand warum der Deblocking Threshold entfernt wurde ?
=> kein Platz in der GUI, sie suchen jemanden der sich um die GUI kümmern würde.

Cu Selur

Geschrieben von Selur am 03.06.2005 um 08:12:

Update:

Zitat:

Changelog:
0.0.7 nach 0.0.8
- max reference Frames max = 16 nicht mehr 15Referenzen
- Jarods Homepage als weiter x264 Quelle angegeben
- kurze Beschreibung zum Thread Support

Cu Selur

Geschrieben von Selur am 09.06.2005 um 10:10:

Update:

Zitat:

Changelog:
0.0.8 nach 0.0.9
- Pixel Aspect Ratio, 8x8 DCT und 8x8 Intra Search wurde in die GUI aufgenommen

Würde mich vorallem freuen, wenn ein paar Leute psoten würden ob 8x8 DCT und 8x8 Intra Search auch etwas bei nicht HDTV Auflösungen bringt.

Cu Selur

Geschrieben von Selur am 12.06.2005 um 19:40:

Update auf 0.1.0 ist draußen!

Zitat:

Changelog:
0.0.9 nach 0.1.0
- Typos, kleine Umformulierungen
- Link zu Doom9 letztem Codecvergleich eingefügt
- komplettes Redesign des Advanced Bereichs, mit einigen neuen Features

Würde mich wie immer über Feedback freuen! großes Grinsen

Cu Selur

Geschrieben von Balm am 12.06.2005 um 22:18:

Damit du nicht denkst, deine Arbeit wäre umsonst! Ich lese!

Cu Balm

Geschrieben von Selur am 15.06.2005 um 19:14:

Update auf 0.1.1 ist draußen!

Zitat:

Changelog:
0.1.0 nach 0.1.1
- Partition decision quality wurde um RDO erweitert.

Würde mich wie immer über Feedback freuen! großes Grinsen

Cu Selur

Geschrieben von scrat am 17.07.2005 um 18:06:

hey!

hab mal ne frage zu deinem guide: warum soll ich für x264 ne mp4-hülle verwenden?
ich hab mal nen test gemacht und muss sagen dass die qualität von x264 bei einer auflösung von 720x576 und einer bitrate von 500 (wollte nur wissen wie es bei einer sehr niedrigen bitrate mit hoher auflösung aussieht) doch besser ist als bei divx 6 und xvid. hab da x264 in ne avi gepackt und hatte keine probleme beim erstellen und abspielen - daher die frage was mir mp4 für vorteile bringt.
werd mir mal x264 in mkv anschauen und dann wenn ich meinen matroska-guide update entweder xvid oder x264 anstelle von divx 5.05 nehmen...

mfg
scrat

Geschrieben von Selur am 17.07.2005 um 18:57:

x264 sollte in ne mp4 Hülle, da:
1. das die vorgesehene Hülle für den Codec ist (Stichwort: Standard konform)
2. mp4 neben geringen Overhead auch noch einige andere gute Features bietet welche aber leider noch teilweise untertützt werden (warte auch noch darauf, dass die Decoder&Co unterstützen das man überall schneiden kann)
3. weil avi veraltet ist und man es noch künstlich mit dehnen des Standards aufrecht erhält,...
(nix gegen die Arbeit von AlexNoe smile

)

Zitat:

... doch besser ist als bei divx 6 und xvid.

hatte ich auch erwartet, Nero ist übrigends noch nen Tick besser Augenzwinkern

Zitat:

..entweder xvid oder x264 anstelle von divx 5.05 nehmen...

wie wäre es mit 'und' anstatt 'oder' ? Augenzwinkern

Cu Selur

Geschrieben von scrat am 17.07.2005 um 20:07:

hey!

Zitat:

Original von Selur
x264 sollte in ne mp4 Hülle, da:
1. das die vorgesehene Hülle für den Codec ist (Stichwort: Standard konform)

ok - ist ein grund.

Zitat:

2. mp4 neben geringen Overhead auch noch einige andere gute Features bietet welche aber leider noch teilweise untertützt werden (warte auch noch darauf, dass die Decoder&Co unterstützen das man überall schneiden kann)

weisst du zufällig ob der overhead von mp4 geringer ist wie der von mkv oder kann man das nicht allgemein sagen...

Zitat:

3. weil avi veraltet ist und man es noch künstlich mit dehnen des Standards aufrecht erhält,...
(nix gegen die Arbeit von AlexNoe smile

)

klar, würde ja auch nicht avi sondern mkv nehmen - hab nur nen schnellen test mit x264 in avi gemacht...

Zitat:

... doch besser ist als bei divx 6 und xvid.

hatte ich auch erwartet, Nero ist übrigends noch nen Tick besser Augenzwinkern

werd ich mir mal anschauen

Zitat:

..entweder xvid oder x264 anstelle von divx 5.05 nehmen...

wie wäre es mit 'und' anstatt 'oder' ? Augenzwinkern

naja, wenn ich jetzt und sage dann muss ich beim audio auch ac3, ogg und aac nehmen und bei den subtitles vobsub und usf nehmen und dann wird das ganze doch etwas lang genug...

mfg
scrat

Geschrieben von Selur am 18.07.2005 um 08:47:

Soweit ich weiß gibt es noch keine feste Formel für den Overhead für den OVerhead in mp4 files, meine mich zu entsinnen, dass

1. die Overheadberechnung analog zu mkv recht unintuitiv und könnte wenn wohl am ehesten über die Anzahl von Frames abgeschätzt werden ( gab im englischen Doom9Forum mal nen thread dazu , siehe: http://forum.doom9.org/showthread.php?t=85298, meine im 3ivx.com Forum gabs auch malw as dazu, finde es aber nicht mehr Augenzwinkern

)
2. mp4 ist normalerweise immer nen Tick kleiner als mkv (mov ist meist nochmal etwas kleiner) smile

Zitat:

würde ja auch nicht avi sondern mkv nehmen

Achte darauf, dass Du nicht einen Umweg über Avi einlegst, sondern möglichst direkt in ein mkv file schreibst oder über mp4 gehst, da sonst der Videostream in einem Avi stream im mkv file gecapselt wird. Augenzwinkern

Cu Selur