Der x265-Encoder entwickelt sich...

Soweit ich das verstanden habe, ist das ne andere Gruppe, die eigene Lizenzen neben MPEG-LA erhebt.
Die Lizenzen muss man also drauf rechnen.

Zitat

Die Lizenzen muss man also drauf rechnen.

Was die Sache nur unschöner macht.

Zitat von Selur

So wie ich das momentan sehe müsste theoretisch jeder der einen Software HEVC Decoder oder Encoder zur Verfügung stellt 1.1€ pro Download zahlen.
Falls die (hoffentlich) ist es die schlechte Presse nicht Wert und man wird kleinen Hobby-Toolentwicklern und Leuten die z.B. x265 zum Download anbieten da nicht aufs Dach steigen.
(ansonsten wird der HEVC Support in freien Tools wohl stark einbrechen)

Es hat sich bisher niemand bei den freien Tools um Patente geschert, das wird sich dadurch nicht ändern. Oder hast Du für Hybrid Lizenzen für auch nur ein einziges Format eingeholt?

Nein, hab ich nicht musste ich aber auch nicht weil ich damit unter die 100k/units pro Jahr gefallen bin.

Was ist mit den Patenten von Xvid, MP3, AC3, DTS, AAC, MP4, BluRay...?

Hab ich mir auch durchgelesen und als unproblematisch in meinen Fall angesehen.

Mit anderen Worten: Du hast für Hybrid nicht eine einzige Lizenz eingeholt.

Zitat von sneaker2

Es hat sich bisher niemand bei den freien Tools um Patente geschert, das wird sich dadurch nicht ändern.

Die andere Frage ist eher, wie es bei Hardware Decoder/Encoder und Streams aussieht. Also die Verbreitung des Codecs allgemein.

Divx hatte ja auch einige Patente verkauft, daraufhin wurden die ganzen DVD Player Hersteller genötigt, hohe Lizenzen für Divx zu zahlen. Die Folge war, dass per Firmware die Divx Unterstützung (FOURCC Kennung) an den Geräten unterbunden wurde.
Sowas in der Richtung kann ja auch h265 passieren.

Ja, das bleibt abzuwarten. HEVC wird ja schon kommerziell eingesetzt, z.B. von Netflix für UltraHD und für die BluRay ab Ende dieses Jahres. In Deutschland ab nächstem Jahr auch für DVB-T2 (und für ein paar UHD Sat-Sender). Eigentlich nimmt HEVC gerade richtig Fahrt auf und die wollen anscheinend auch von den Inhalteanbietern nicht unerheblich Geld, was richtig böse enden könnte:
http://blog.streamingmedia.com/2015/07/new-pa…ent-owners.html

Neue Builds mit MinGW-w64-Patch für die stats-Datei-Ausgabe bei Multi-Threading:

x265 1.7+382-7c83f7755422 (GCC 4.9.2)
x265 1.7+382-7c83f7755422 (GCC 5.2.0)

Heute darüber gestolpert warum ich letztens dachte, dass das 12bit decoding (in libav) oder das Encoding in x265 nicht klappt.
Mein Test-Call hat lossless encoding versucht.
Normales 12bit encodes können mit dem aktuellen MPC-HC ohne Probleme abgespielt werden, lossless encodes zeigen aber (immer noch) Decodierprobleme.

Cu Selur

Ps.: sehe auch gerade https://bitbucket.org/multicoreware/…t-exact-and-the -> würde generell erst mal empfehlen sich nicht auf x265 'lossless' zu verlassen. Komisch scheint, dass lossless nur bei manchen Files nicht klappt,...

Zitat

x265 version 1.8 has been released. This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.

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

=================================== API Changes ========================================================

• Experimental support for Main12 is now enabled. Partial assembly support exists.
• Main12 and Intra/Still picture profiles are now supported. Still picture profile is detected based on x265_param::totalFrames.
• Three classes of encoding statistics are now available through the API.
  
  
  • x265_stats - contains encoding statistics, available through x265_encoder_get_stats()
  • x265_frame_stats and x265_cu_stats - contains frame encoding statistics, available through recon x265_picture
• --csv
  
  
  • x265_encoder_log() is now deprecated
  • x265_param::csvfn is also deprecated
• --log-level now controls only console logging, frame level console logging has been removed.
• Support added for new color transfer characteristic ARIB STD-B67

================================== New Features ========================================================

• limit-refs
  
  
  • This feature limits the references analysed for individual CUS.
  • Provides a nice tradeoff between efficiency and performance.
• aq-mode 3
  
  
  • A new aq-mode that provides additional biasing for low-light conditions.
• An improved scene cut detection logic that allows ratecontrol to manage visual quality at fade-ins and fade-outs better.

=============================== Preset and Tune Options ===================================================

• tune grain
  
  
  • Increases psyRdoq strength to 10.0, and rdoq-level to 2.
• qg-size
  
  
  • Default value changed to 32.

Alles anzeigen

Und ein aktuelles "merge with stable"-Release, nachdem die adaptive Szenenerkennung korrigiert wurde:

x265 1.8+2-55a4a9b920ff (GCC 4.9.2)
x265 1.8+2-55a4a9b920ff (GCC 5.2.0)

Vor kurzem wurde ein Patch eingepflegt, der in Intra-CU die Analyse für 64×64-Blöcke deaktiviert; deren unvorteilhafte bisherige Implementierung war wohl einer der Hauptgründe für deutliche Detailverluste (laut Analyse von mandarinka und nandaku2 im doom9-Forum). Bis zur Implementierung einer besseren Methode gilt also für Intra-Blöcke eine Größenbeschränkung auf maximal 32×32 Samples.

intra prediction: disable 64x64 analysis


In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.

x265 1.8+106-e8f9a60d4cd9 (GCC 4.9.2)
x265 1.8+106-e8f9a60d4cd9 (GCC 5.2.0)

Gerade wurde auch ein Patch vorgeschlagen, der 2-pass CRF mit Bitratenbeschränkung via VBV als Bitrate-Control-Modus ermöglichen soll. Der wird dann eventuell demnächst in einem kommenden Build verfügbar. Für welche Zwecke der sich wohl am besten eignet? HQ-Filme, deren Bitraten an die Auslese-Geschwindigkeit nicht allzu schneller Flash-Sticks oder von WLANs mit geringerer Empfangsqualität und reduzierter Datenrate heranreichen?

Hat zwar auch mit x265 zu tun aber keine Ahnung ob es hier rein passt. Aber weshalb lassen sich mit x265 encodete Filme so viel schlechter "spulen/ springen" als x264 encodete? Also im Film Vorspulen oder springen... das ist es was mich aktuell von x265 abhält...

Weil Dein PC HEVC nicht so schnell dekodieren kann wie H.264?

Wenn du zufällig (oder weil du deinen Player so eingestellt hast) nur zu GOP-Anfängen (bei AVC und HEVC jeweils meist IDR-Frames) springst, kann der Player von dort aus direkt decodieren.

Springst du sonstwo hin, muss der Player erst mal vom letzten vorherigen GOP-Anfang bis zu deinem Sprungziel alles unsichtbar decodieren, bis er ab deinem Sprungziel dann weiter normal abspielen kann. Das dauert bei HEVC deutlich länger als bei AVC.

Den MPC-HC kann man konfigurieren, ob du damit lieber schnell (aber ungenau, nur zu GOPs) oder lieber exakt (dafür aber u.U. mit Decodierpause) springen möchtest.

hmm, meine Player basieren auf ffmpeg... VLC/ Plex/ Kodi ich wüsste nicht wo die hinspringen, ich vermute wahllos. Muss ich mal schauen ob es Möglich ist das einzustellen wo der hinhüpft...

Ja, das Problem kommt mir bekannt vor

Bei x265 ist "open GOP" Standard.
Ich empfehle daher: "--no-open-gop" in der cmd zu benutzen.

Ja, das war sogar aktiv...

Und warum sollte Open-GOP nennenswerten Einfluß auf die Seekgeschwindigkeit haben?