zu mkv: Mosu ist drann und hat aktuell wohl geplant den HEVC support in Version 6.8.0 zu integrieren. siehe: https://forum.doom9.org/showthread.php?p=1661376#post1661376
Einzige Möglichkeit mkv files mit H.265 files zu erstellen ist aktuell die mkvtoolnix 6.2.0 version von Rovi, siehe: http://labs.divx.com/node/127905
zu mp4: alle aktuellen MP4Box Versionen sollten HEVC unterstützen (erstelle ich hier mit Hybrid schon ne Weile)
Wobei man von Rovi 1.0.4 die Finger lassen sollte, weil das, wenn ich mich recht erinnere, noch eine Vorabversion war, die nicht so muxt, wie das Matroska-Team (in Zusammenarbeit mit DivX) sich das inzwischen vorstellt.
Weil das Team von MulticoreWare Inc. die Marke x265 schützen will und deshalb die Bereitstellung der Autobuilds unter dem Nutzernamen und unter der Internet-Domain 'x265.cc' eingestellt wurde, fehlt nun eine regelmäßige Downloadquelle für aktuelle Binaries.
Kennt jemand Alternativen? Organisationen wie VideoLAN werden sich wegen der MPEG-LA sicherlich nur auf Quelltexte beschränken.
Dachte eigentlich, dass die Markenrechte&Co zumindest in Europa bei Videolan liegen,....
Wer im Moment wo der Inhaber ist, interessiert so im Detail eigentlich weniger. Entscheidend ist im Moment, dass zwar eine Unterstützung der Entwicklung von x265 erlaubt ist, die Verwendung des Markennamens aber nicht ohne weiteres (zumindest nicht in dem Maße, dass es den Anschein erwecken kann, man selbst hätte Rechte daran, ihn wie einen Titel in einem Benutzernamen oder einer Internetdomain zu führen).
Mein Problem ist hier nicht das Markenrecht.
Mein Problem ist, dass jemand, der es wohl mangels juristischer Vorbildung nicht von Anfang an verstanden hat, nun die falschen Schlussfolgerungen daraus gezogen hat: Niemand wollte, dass der Buildbot verschwindet, es ging nur darum, dass er nicht unter diesem Namen läuft.
Tja, nun ist er weg. Und wer übernimmt jetzt?
Im IRC meinte JEEB, dass das Anbieten von x265-Binaries nicht allzu riskant sei, wenn man nicht gerade eine Organisation oder Firma verkörpert; hinter Privatleuten ohne wahrscheinliche wirtschaftliche Interessen sei die MPEG-LA ja wohl nicht her.
Schaun wir mal, ob sich jemand findet, der sowohl Webspace als auch genug Erfahrung mit git und C-Compilern hat (mir würde da zumindest letzteres fehlen, insbesondere wenn's nicht auf Anhieb durchläuft).
Na gut, es lief problemlos durch und warf mir ein x265 0.7+95 aus.
Neu in Version 0.7 ist dann wohl u.a. die adaptive Szenenerkennung, so dass auch der Parameter für die maximale GOP-Länge statt -i jetzt -I heißt, und -i nun für die minimale zuständig ist (Standard: auto).
Und v0.7 crasht auch nicht mehr im Preset placebo.
__
Die neue Preset-Steuerung ist etwas merkwürdig. Es gibt einen deutlichen Qualitätsunterschied zwischen allen Presets 'faster' und schneller einerseits, sowie 'fast' und langsamer andererseits. Die langsameren sind optisch deutlich schlechter. Und es liegt nicht primär an der Verwendung des CUTree.
Hier ist noch 'ne build Seite ... die von Fllear -> http://machine-doll.ru/vc12/
32 vs 64 bit.
Nun x265 sollte doch "from scratch" entwickelt worden sein. Macht es da nicht mehr Sinn das Ganze mit 64bit Version als Schwerpunkt zu entwickeln/bauen ?
Ja, ich weiß auch das es noch genügend 32 Bitter gibt ... aber bei der Komplexität und Datenmenge (4k z.B.) macht es da nicht mehr Sinn eher bei 64 Bit zu bleiben ?
Sicherlich ist die hauptsächliche Unterstützung einer AMD64-Architektur sinnvoll. Unter anderem, weil solche Prozessoren effizienter nutzbare Direktregister haben, was manche Algorithmen ordentlich beschleunigen kann. Von x264 wurde ja schon +10% behauptet. Und auch bei der Datenmenge, die 4K- oder gar 8K-Video im RAM halten muss, ist eine 64-bit-Adressierung nützlich.
Leider ändert das erst mal noch nichts an dem Problem, dass ich selber keine Ahnung davon habe, wie ich die Quelltexte oder die Compileroptionen so ändern muss, dass eine Win64-EXE gebaut wird.
Übrigens ... weiß zufällig jemand, ob man MSYS auch mit einem spezifischen Benutzernamen aufrufen kann? Oder wird grundsätzlich immer der Name des aktiven Windows-Benutzerkontos auch als Shell-Nutzer verwendet? Ich würde nämlich gern auf zwei Rechnern mit unterschiedlichem Windows-Benutzernamen ein gleichnamiges home-Verzeichnis verwenden.
nebenbei: http://x265.ru/en erstellt wohl auch wieder builds,..
wegen mingw: vermute schon stark, dass der Benutzername zu einem bestimmten existierenden Benutzer gehören muss und nicht frei gewählt werden kann; hab bis dato noch keine portable MinGW Buildumgebung außerhalb einer VM gesehen.
Da müsste man dann wohl einen Windows-Benutzer mit entsprechendem Namen anlegen und MSYS.bat unter diesem Nutzer ausführen. Etwas umständlich, aber wenn's geht...
Übrigens, v0.7+98 beschreibt die GOP-Parameter etwas verständlicher, würde ich sagen. Und ein Win64-Build scheint möglich; aber die 16bpp-EXE will wohl ausschließlich nur 10-bit-Video haben, und wie man das herstellt, weiß ich noch nicht.
Tja, wenn man erst mal weiß, was man wo wie anzupassen hat, wird dann die erforderliche Änderung zum Erzeugen einer Win64-EXE relativ einfach.
... aber die 16bpp-EXE will wohl ausschließlich nur 10-bit-Video haben, und wie man das herstellt, weiß ich noch nicht.
Nun du kannst doch 8Bit nach (erst mal) 16 Bit Farbraum mit den dither tools "verwandeln"
Dither_convert_8_to_16()
Damit man trotzdem was erkennen kann is LBS und MSB ge-stacked.
Um's auf 10Bit runterzubrechen benutze man:
Dither_quantize(bitdepth=10, reducerange=true)
Dither_out()
... und der "output" ist dann 10Bit (meist 4:2:0)
Aber noch nimmt x265 keine AviSynth-Ausgabe an. Man müsste also das Ergebnis als 10-bit-Y4M/YUV speichern (da werden dann sicher viele Parameter notwendig, um das Eingabeformat genau zu definieren) oder mit avs4x265 pipen ... aber da lese ich immer Warnungen, dass AviSynth 2.60 erkannt und deshalb auf 8 bpp begrenzt wird. Womit geht denn dann mehr, mit AviSynth+?
Also bleibe ich erst mal bei 8 bpp. Ist ja eh noch nichts ernstes mit x265.
Na ja, sowohl ich als auch Sneaker haben schon einige 10 Bit x265 tests gemacht. Mit avs2pipemod.
Ich hatte damals einen Testausschnitt von 500 frames genommen ... es hatte sich gezeigt das bei gleichem --crf die Unterschiede enorm waren in punkto qualität.
Hier war das 8 Bit Material um längen besser. Das kann aber auch am Avisynth output liegen ...
Kurzer Hinweis für diejenigen, die wirklich alles ausprobieren müssen:
Ab sofort wird x265 auch Video-Formate mit feinerem Chroma-Subsampling unterstützen. Bisher gibt es dafür allerdings wesentliche Einschränkungen, da noch nicht alle Funktionen optimiert und ihre Zusammenarbeit mit anderen Code-Bereichen gesichert ist. Ich zitiere dazu mal die Email an die Entwickler-Mailingliste:
Hello,
I want to announce that support for 4:4:4 input frames (full sized chroma planes with no sub-sampling) is now on the default branch.
At this time, you are required to use --no-weightp and --cpuid 1 when using the 4:4:4 color space (to avoid output mistakes, and decoder hash mismatches) because there are problems with a few assembly routines and with weightp when used with 4:4:4 content. We hope to have both of those issues resolved very soon.
To test this feature you either need 4:4:4 Y4M content, or use 4:4:4 YUV content and add --input-csp 3 to your command line.
If you try this new feature and encounter problems, please let us know. Thanks.
--
Steve BorhoPS: Support for 4:2:2 color space is under development.
"--input-csp 3" krieg ich schon den Affen, wenn ich sehe, dass sie den Input-Colorspace über einzelne Zahlen spezifizieren. Strings wäre da doch wesentlich aussagekräftiger. (und auch nicht wirklich komplizierter zu implementieren)
Link zur von LigH zitierten Mail: https://mailman.videolan.org/pipermail/x265…ary/003516.html
Dafür ist noch Zeit. 
Im Moment sind wir wohl in einer etwas instabilen Phase. Ein paar Patches zuvor wurde noch eine SSE4-Optimierung bereits ab SSE2 verwendet, mit sofortigem Crash als Ergebnis. Version 0.7+207, die ich gerade nebenbei laufen lasse, mag langsamere Presets (ab 'slow') nicht und stürzt ab. Außerdem verrechnet sich die Bitratenkalkulation bei größeren Bildflächen, bei mir werden für FullHD fünffach so hohe Werte ausgegeben wie die Größe der Datei am Ende.
Aktuell (hier v0.7+254) gibt es einen ganzen Block mit neuen Parametern zu "Video Usability Information":
VUI options:
--vui Add Video Useability Information with all fields to the SPS. Default disabled
--sar Sample Aspect Ratio, the ratio of width to height of an individual pixel.
Choose from 0=Unspecified, 1=1:1("square"), 2=12:11, 3=10:11, 4=16:11,
5=40:33, 6=24:11, 7=20:11, 8=32:11, 9=80:33, 10=18:11, 11=15:11,
12=64:33, 13=160:99, 14=4:3, 15=3:2, 16=2:1. Default 0
--extended-sar Use a custom Sample Aspect Ratio,[WxH]
--overscan <string> Specify crop overscan setting from undef, show or crop. Default of undef
--videoformat <string> Specify video format from undef, component, pal, ntsc, secam, mac. Default of undef
--[no-]range Specify black level and range of luma and chroma signals. Default of disabled
--colorprim <string> Specify color primaries from undef, bt709, bt470m, bt470bg, smpte170m,
smpte240m, film, bt2020. Default of undef
--transfer <string> Specify transfer characteristics from undef, bt709, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316, iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12. Default of undef
--colormatrix <string> Specify color matrix setting from undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c
--chromaloc <integer> Specify chroma sample location (0 to 5). Default of 0
--[no-]fieldseq Specify that pictures are fields and an SEI timing message
will be added to every access unit. Default disabled
--[no-]framefieldinfo Specify that a pic-struct will be added to the SEI timing message. Default disabled
--crop-rect <string> Add 'left,top,right,bottom' to the bitstream-level cropping rectangle
--timinginfo Add timing information to the VUI. Defaut disabled
--nal-hrd Signal HRD information. Default disabled
--bitstreamrestriction Add bit stream restriction fields to the VUI. Default disabled
--subpichrd Add sub picture HRD parameters to the HRD. Default disabledDa wird noch viel zu dokumentieren sein...
Ich hoffe das Brother John die Parameter usw. auch bald in sein Encodingwissen mit aufnimmt 
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!