Der x265-Encoder entwickelt sich...

Wenn ich mich recht erinnere, hat es etwas mit dem Unterschied zwischen Darstellungs- und Decodier-Reihenfolge zu tun, wo genau eine offene GOP beginnt.

Illustrierende Grafiken: AX-Comp / Apple

Bei einer geschlossenen GOP ist es relativ eindeutig: Aus der vorherigen GOP gibt es keine B-Frames, die Bezug auf das I-Frame der aktuell betrachteten GOP nehmen, mit dem die Decodierung dort beginnen kann; dazu wird die geschlossene GOP beispielsweise mit einem P-Frame abgeschlossen. GOP-Grenzen sind scharf definiert. Man kann den Videostream an GOP-Grenzen ohne Sorgen schneiden, sowohl Anfang als auch Ende sind sicher.

Eine offene GOP aber hat am Ende B-Frames, die zukünftigen Bezug auf das nächste I-Frame nehmen. Dazu muss also das I-Frame der nächsten GOP bereits decodiert worden sein, bevor noch die B-Frames der eigentlich letzten GOP dargestellt werden können. Die GOP-Grenzen werden hierbei also logisch etwas aufgeweicht. Zählen nun die B-Frames, die sich vorwärts auf das I-Frame beziehen, logisch zur aktuellen GOP, dann muss der Decoder hier schon um diese Anzahl B-Frames in den Strom hinein decodieren, wenn er "den Anfang dieser GOP" statt "das I-Frame" als Sprungziel ansieht.

Jo, dann hast Du vielleicht 3 B-Frames am Ende einer z.B. 120 Frame-GOP, die Daten aus dem nächsten (einem!) I-Frame benötigen. Die Chance genau dahin zu seeken ist also 3:117. Schlimmstenfalls mußt Du einen einzigen (I-)Frame zusätzlich dekodieren. Wobei zusätzlich auch nicht wirklich stimmt, da wäre sonst halt ein P-Frame. Wodurch soll da nun die Seekgeschwindigkeit merklich sinken?

In Chennai (Indien) ist "Land unter" wegen Monsun, deshalb wird die Entwicklung von x265 wohl eine Zeit lang etwas aufgehalten, da einige Mitarbeiter dort leben...

grummel hab momentan das Problem, dass wenn ich 2pass Encoding in Kombination mit '--pme' verwende es immer zu einem Crash kommt.

Zitat

Wodurch soll da nun die Seekgeschwindigkeit merklich sinken?

Kommt auf die Decoder an, zumindest als HEVC noch neuer war hatten einige Decoder Probleme damit, weshalb ich in Hybrid standardmäßig open gop deaktiviert habe.

Ok, Fehler mag ich nicht ausschließen. Insbesondere mp4box macht bekanntlich in einigen Playern Probleme (im Gegensatz zu L-Smash). Bei der Frage, was genau richtig ist, scheint man sich nicht einig zu sein. Die MP4-Spezifikation ist auch leider nur käuflich zu erwerben und Open-Gop in MP4 war schon immer ein Thema für sich. Zumindest LAV scheint keine Probleme zu haben, egal welche Variante man nimmt. Langsameres Seeken ergibt sich dann nur aus dem generell langsameren Decoder.

Ich hab mal mit den L-Smash-Entwicklern gesprochen. Die haben sich das nochmal angeschaut und sagen, daß es derzeit ein Problem mit der MP4-Spezifikation in Sachen HEVC und Open-GOP gibt, was dazu führt, daß man die nächste Revision der Spezifikation abwarten sollte. Die Empfehlung wäre also tatsächlich, vorerst --no-open-gop zu verwenden, solange mp4 das Ziel ist. Zumindest L-Smash muxt derzeit falsch (nach vermuteter zukünftiger Spez.), womit ironischerweise aber alle Player gut zurechtkommen. Ob mp4box geändert werden muß, weiß ich nicht - möglicherweise nicht, auch wenn Player Probleme haben.
Schon schräg, daß die das schon wieder verbockt haben. Bei AVC gab es damals auch Probleme.

Danke für die Recherche, das ist auf jeden Fall nützlich.

Ich erinnere mich an den Aufwand, Matroska zu spezifizieren, und das ist noch deutlich flexibler als MP4. Man kann einfach nicht von vorn herein an alles denken...

Frohe Weihnachten (oder ähnliche Feste) mit einem aktuellen Build mit neuen Preset-Standardwerten (z.B. limit-modes/refs; siehe Doku).

x265 1.8+187-da48f2690076 (GCC 4.9.2)
x265 1.8+187-da48f2690076 (GCC 5.2.0)

Habe jetzt auch mal ein paar Testversuche gemacht und bekam diese Warnung bei Staxrip:

log:
x265 [warning]: Specifying a decoder level with constant rate factor rate-control requires
x265 [warning]: enabling VBV with vbv-bufsize=20000kb vbv-maxrate=20000kbps. VBV outputs are non-deterministic!

woran kann das liegen?

Mit BDtoAVCHD bekam ich diese wiederum nicht.

Danke für eine eventuelle Info.

:welcome:

Entschuldige das späte Freischalten, bekomme darüber leider keine Nachricht; wieso hat hier unser Anti-Spam-Plugin überhaupt zugeschlagen? Weder Links noch Bilder zu sehen...

Wenn du was testest, dann brauchen wir möglichst die komplette generierte Kommandozeile mit allen Parametern. Anscheinend hat StaxRip hier sowohl Profile@Level als auch CRF eingebaut, aber nicht gleichzeitig die dazu passenden VBV-Parameter übergeben. Nun ja, das ist nur eine "Warnung". Am PC wird das Ergebnis schon abspielbar sein. Nur Consumer-Player könnten da empfindlicher reagieren.
__

^ davon unabhängig:

Sie haben es getan. Sie reiten tote Pferde. Und wundern sich, dass sie liegenbleiben.

Zitat

Sie haben es getan. Sie reiten tote Pferde. Und wundern sich, dass sie liegenbleiben

Hatte die Tage auch jemanden der 8k Material unter Windows XP 32bit nach x265 umwandeln wollte und dabei Probleme mit freien Arbeitsspeicher hatte,...

8K UHD? Das ging ja noch nicht mal mit 8 GB RAM unter 64-bit vernünftig, weil x265 da schon an die 12 GB brauchte (laut ProcessExplorer), entsprechend swappediswap.

^ P.S.: Version x265vfw_v100_x265b79_20160116 ist unvollständig, es fehlen MinGW/GCC-Runtimes und vielleicht noch andere SxS-DLLs. Statische Builds sind bei gemischten C/C++-Projekten wohl nicht so einfach.

Version 1.9 wurde als neuer Meilenstein veröffentlicht.

Zitat von Deepthi Nandakumar

x265 version 1.9 has now been released. This release supports many new features as well as additional assembly optimizations for Main12, intra prediction and SAO. Recently added features lookahead-slices, limit-refs and limit-modes have been enabled by default in the supported presets.

Full documentation is available at http://x265.readthedocs.org/en/stable/

========================================== New Features ==============================================
Quant offsets: This feature allows block level quantization offsets to be specified for every frame. An API-only feature.
--intra-refresh: Keyframes can be replaced by a moving column of intra blocks in non-keyframes.
--limit-modes: Intelligently restricts mode analysis.
--max-luma and --min-luma for luma clipping, optional for HDR use-cases
Emergency denoising is now enabled by default in very low bitrate, VBV encodes
=========================================== API Changes ==============================================
x265_frame_stats returns many additional fields: maxCLL, maxFALL, residual energy, scenecut and latency logging
--qpfile now supports frametype 'K"
x265 now allows CRF ratecontrol in pass N (N greater than or equal to 2)
Chroma subsampling format YUV 4:0:0 is now fully supported and tested
====================================== Presets and Performance ==========================================
Recently added features lookahead-slices, limit-modes, limit-refs have been enabled by default for applicable presets.
The default psy-rd strength has been increased to 2.0
Multi-socket machines now use a single pool of threads that can work cross-socket.

Thanks,
Deepthi Nandakumar
Engineering Manager, x265
Multicoreware, Inc

Alles anzeigen

x265 1.9+3-548a45bbf223
__

Mittlerweile berichtet auch Fefe über x265. :sly: Er findet, x265 ist mittlerweile schnell genug für praktische Nutzung.

Mal ne Frage wie muss ich unten stehendes ändern um eine bestimmte Version von x265 zu bauen?

# libx265
cd ${CMPL} 
hg clone https://bitbucket.org/multicoreware/x265
cd x265/source
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DENABLE_SHARED=NO .
make -j 4 && make install

Habe das nun unschön gemacht indem ich die source manuell ausgetauscht habe, das hat aber zu Folge das x65 ohne Versionsinfo gebaut wird..

Grüße
Massaguna

man 1 hg als HTML

Für den Befehl "clone" gibt es u.a. die Option -u (--updaterev), mit der man direkt eine Revision mit einem Tag (z.B. "1.8" und "1.9") oder einem Patch-Hash frisch herunterladen kann. Wenn du relativ zu einem bereits vorhandenen Stand die Quellen laden willst, dann verwende z.B. den Befehl "update" statt "clone".

Kann es sein das sich die "Qualitätsstufen" bei CRF mal wieder geändert haben (gegenüber ver. 1.8)
Ich habe die ganze Zeit mit CRF 22 gearbeitet was plötzlich weit größere Files produziert ...

Ja, kann sein. U.a. der Standardwert für --psy-rd wurde geändert.

Ja, die Standardwerte für Presets wurden geändert; du solltest auch "--limit-modes" beachten, das kann die Konvertierung deutlich beschleunigen mit nur unwesentlich geringerer Qualität.

Also ich bekomme das nicht hin eine bestimmte Version zu bauen...

Mac-Pro:compile Massaguana$ cd ${CMPL}
Mac-Pro:compile Massaguana$ hg update -r 1.8 https://bitbucket.org/multicoreware/x265
abort: no repository found in '/Volumes/Ramdisk/compile' (.hg not found)!
Mac-Pro:compile Massaguana$ hg clone -r 72005f2c0acda56913c0eae4562dc5ad https://bitbucket.org/multicoreware/x265
warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)
destination directory: x265
abort: unknown revision '72005f2c0acda56913c0eae4562dc5ad'!
Mac-Pro:compile Massaguana$