Ich hab mir überlegt, ob ich vielleicht auch mal den intel C++ Compiler ausprobiere.
Hab die Idee dann gleich wieder fallengelassen. Optimierten Code erzeugt der nur, wenn er selber auf einer intel-CPU läuft. Hab ich keine, zu teuer.
Dafür hängt sich Dark Shikari mal mit in die Diskussion um die XP-Kompatibilität. Immerhin kann x264 auch unter XP mit Condition-Variablen umgehen...
Dafür hängt sich Dark Shikari mal mit in die Diskussion um die XP-Kompatibilität. Immerhin kann x264 auch unter XP mit Condition-Variablen umgehen...
Wobei man ehrlicherweise zugeben muss, dass es auf lange Sicht natürlich immer weniger Sinn macht Windows XP noch zu unterstützen.
Allein schon wegen:
a. i.d.R. 32bit -> max. 2GB RAM pro Anwendung, was für alles über FullHD Probleme macht
b. Nutzerzahlen sollten in den nächsten Monaten (hoffentlich) deutlich zurück gehen, weil die meisten Leute doch der Ansicht sind, dass es nicht die cleverste Idee ist mit einem ungepatchten OS online zu gehen.
Es geht halt nur um die "eierlegende Wollmilchsau": dass es noch möglich (wenn auch nicht vernünftig) ist, modernste Formate auch auf veralteten Systemen zu erzeugen.
Aber schon die nötige Rechenleistung für HEVC und was noch käme (erinnert euch an schweinsz, der das ganz alleine viel besser könnte) macht einen PC, der zu alt für Windows 7+ ist, irgendwann ungeeignet.
Was die Sicherheit angeht, hilft vielleicht nur die Radikallösung: Da muss der Videorechner dann halt mal offline bleiben, wenn es zu riskant wird.
Es war einmal ein PDF namens "x265 Evaluator's Guide"; jetzt ist die Dokumentation online: x265 Documentation
Kann mal bitte jemand mit ausreichend Erfahrung damit eine Kurzanleitung erstellen, wie man geeignetes Video für die High-Bitdepth-Builds von x265 in AviSynth erzeugt und übermittelt?
Weiß nicht ob es hilft, aber ich weiß wie man mit ffmpeg 8bit content nach 10bit konvertiert und an x265 füttert, hier mal zwei Beispiele:
ffmpeg->x265:
ffmpeg -y -loglevel fatal -i "F:\TestClips&Co\test.avi" -an -sn -threads 8 -vsync 0 -r 25000/1000 -pix_fmt yuv420p10le -f rawvideo - | x265-16bit --input - --input-depth 10 --input-res 640x352 --fps 25 --frames 429 --colormatrix bt470bg --output "H:\Temp\test_22_14_53_5310_01.265"mencoder + avs -> ffmpeg -> x265: (den mencoder->ffmpeg Umweg nehme ich weil ich mencoder 32bit und ffmpeg 64bit verwendet und mencoder kein high-bit-depth raw-output unterstützt, soweit ich weiß)
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\Temp\encodingTempAvisynthSkript_22_16_14_8510.avs" | ffmpeg -loglevel fatal -threads 8 -an -sn -r 25 -pix_fmt yuv420p -s 640x352 -f rawvideo -i - -r 25 -pix_fmt yuv420p10le -f rawvideo - | x265-16bit --input - --input-depth 10 --input-res 640x352 --fps 25 --frames 429 --colormatrix bt470bg --output "H:\Temp\test_new_22_16_14_8510_03.265"Hab mich aber nicht weiter mich mit High-Bit-Depth-Avisynth beschäftigt, würde mich diesbezüglich also auch über Infos freuen.
Cu Selur
Ps.: bzgl mencoder hab ich auch mal nen feature request erstellt (https://trac.mplayerhq.hu/ticket/2179), aber der scheint keinen zu interessieren. 
Laut letzten Patches geht es schon halb in Richtung v0.9 (feature freeze).
__
P.S.:
"Neue" Funktionen (oder besser neu dokumentierte) sind das Dithern von Videos hoher Farbtiefe, falls sie für den Encoder ohne geeignete Unterstützung auf 8 bit pro Komponente heruntergerechnet werden, sowie die gewichtete Vorhersage auch für B-Frame-Slices (die ist standardmäßig für B-Frames deaktiviert, für P-Frames aktiviert – außer bei schnellsten Presets).
Es gab noch ein paar Korrekturen im Bereich "recon"... hat das was mit der Rekonstruktion (= Decodierung nach Encodierung) zu tun?
Kann mal bitte jemand mit ausreichend Erfahrung damit eine Kurzanleitung erstellen, wie man geeignetes Video für die High-Bitdepth-Builds von x265 in AviSynth erzeugt und übermittelt?
Wenn ich das richtig sehe, muß man gar nichts mehr machen. Die High-Bit-Depth-Builds wandeln 8 Bit automatisch auf 10 Bit. Alternativ wie bei x264 auch auf Interleaved-Ausgabe gehen und roh (d.h. ohne y4m-Header) pipen.
Hi, hab vor einiger Zeit mal ein paar tests gemacht.
8-Bit Material -> dither -> 10-Bit und dann das ganze via avs2pipe(mod) an den x265-16bpp encoder gepiped.
das war allerdings noch zu 0.6x Zeiten ... und da hatte sich gezeigt das bei gleichem CRF (25) die 8 Bit Variante eine weitaus bessere Qualität hatte als die 16 Bit ... und das bei gleichen settings ...
Auch bei 32 vs 64 bit app konnte ich keinen wirklichen Geschwindigkeits Unterschied feststellen ... Der Input war aber auch "nur" 720p 
das war allerdings noch zu 0.6x Zeiten ... und da hatte sich gezeigt das bei gleichem CRF (25) die 8 Bit Variante eine weitaus bessere Qualität hatte als die 16 Bit ... und das bei gleichen settings ...
Ein nutzloser Test, da die CRF-Skalen bei x265 für 8 Bit und 10 Bit vollkommen anders sind. Unterschied soll etwa 6 Einheiten pro Bit sein, d.h. 8 Bit CRF 25 würde etwa 10 Bit CRF 13 entsprechen. Wie bei x264 gilt: Vergleiche sollten bei identischer Bitrate durchgeführt werden, nicht bei identischem CRF.
Ein nutzloser Test, da die CRF-Skalen bei x265 für 8 Bit und 10 Bit vollkommen anders sind. Unterschied soll etwa 6 Einheiten pro Bit sein, d.h. 8 Bit CRF 25 würde etwa 10 Bit CRF 13 entsprechen...
Na da soll mal einer drauf kommen ...
Hallo,
auch wenn man schon eine Version 0.8 nutzen kann fehlt immer noch das Twopass Verfahren.
Ohne Twopass ist es ganz schön fummelig eine Dateigröße anzusteuern.
Grüße
Version 0.9 bereits.
x265 0.9 is a regularly scheduled bug fix release. Many bugs have
been fixed since the 0.8 tag, primarily in rate control and 10bit
encodes. A race hazard on POSIX systems was fixed, and several
non-determinism problems were resolved.
= API Changes =
* the stride of x265_picture is now in units of bytes, not pixels
* VUI configurables were moved into a param.vui sub-struct
* unimplemented VUI options removed
* bRepeatHeaders option added (inserts VPS+SPS+PPS each keyframe)
* fast-decode tune option added
* x265_encoder_headers() returns NAL byte count on success
= CLI Changes =
* --dither option to improve quality of pixel downshifts
* --cpuid replaced with x264 compatible --asm option
* --crf-max <float> added
* improved --help documentation, plus new online documentation
* **experimental** --interlaceMode <prog|tff|bff>
* **experimental** --weightb
= New Features =
* experimental support for interlaced content (field coding)
* experimental weightb support
We now have online documentation for this release
http://x265.readthedocs.org/en/0.9/
plus http://x265.readthedocs.org/en/default/ and
http://x265.readthedocs.org/en/stable for the two development
branches.
See the online manual for full documentation of CLI (and API) options
Our focus for the near future remains on visual quality and rate
control improvements.2-pass-Bitratensteuerung kommt sicher noch vor Version 1.0, nur Geduld.
Hallo,
da schließt sich gleich meine Frage an, woher man fertige Encoder herbekommt?
Ein paar Quellen werden im VideoHelp-Forum aufgelistet. Ich bin auch ab und zu dabei, beschränke mich aber in letzter Zeit öfter auf Versionen, bei denen der "stabile" Entwicklungszweig seinen Anteil hat (oder mal richtig wichtige Neuigkeiten implementiert wurden).
Auch die MeGUI lädt eine Version via Updater, wenn man das aktiviert. Und Hybrid sollte ebenso eine dabei haben.
Hallo,
sieht ja nach einer schönen Seite aus^^.
Leider bereitet mir die Anleitung "How to Compile" Probleme
(http://forum.videohelp.com/threads/357754…l=1#post2259093)
Ab Schritt 1 ist nicht mehr klar was zu tun ist, besonders das die dort runtergeladene Software eine andere Verzeichnisstruktur hat als in Anleitung. Vieleicht passt das ja jemand mal an oder macht eine deutsche Übersetzung für Windows
Du kannst auch die media-autobuild_suite verwenden; die compiliert allerdings so ziemlich alles, was im Audio/Video-Bereich momentan an quelloffenen Projekten wichtig ist.
Aber wenn du nicht täglich die neuesten und noch nicht bugfreien Testversionen brauchst, sondern ein paar Mal pro Woche reicht, dann hol dir einfach was von meinem MediaFire-Verzeichnis.
Danke für den Tip. Ich sehe den X265 im Moment ehr als eine Spielwiese an, von daher kann man sich auch mal beim selbst kompilieren versuchen
Was den RAM-Verbrauch angeht ... ich muss da wohl die Theorie entkräften, dass x265 eine ganze GOP lädt und deshalb ~250× den Platz eines Frames braucht, weil eine GOP mit Standardeinstellungen 250 Frames hat.
3840×2160 Pixel × 12 Bit (YUV 4:2:0) = 12150 KB pro Frame 4K UHD; bei 250 Frames käme man auf ~2,9 GB.
Aber wenn ich mit --keyint 100 oder --keyint 50 die GOP-Länge verkürze, braucht x265 immer noch über 2 GB RAM (entsprechend ist die Encodierung von UHD-Video auf 32-bit Windows unmöglich). Irgend etwas anderes braucht also noch deutlich mehr Speicher als bloß der Frame-Puffer.
eventuelle lookaheads&Co sind asicher auch interessant, auch nutzt x265 per Default doch openGOP, sprich da wäre es durchaus verwunderlich, wenn nur GOPsize an Frames gecached würden,...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!