Was möchtest Du uns damit sagen? Das die Emby Entwickler ganz doll böse sind zusätzliche Vorteile für zahlende Kunden einzubauen?
Ich sag gar nichts. FFmpeg hat nicht ohne Grund eine Rechtsabteilung und die werden sich schon drum kümmern, wenn hier etwas widerrechtlich läuft.
Mich interessiert nur, ob es da schon eine Klage gab oder ob ffmpeg das so durch gewunken hat.
Emby ist praktisch nur ein Wrapper um ffmpeg. Und HW Beschleunigung ist ein kostenloses Feature von ffmpeg und nur ein Parameter bei ffmpeg, wie er aufgerufen wird.
Und die HW Unterstützung in Emby wird nur ein paar Zeilen Code sein, welche die richtigen ffmpeg Parameter rausfindet.
Während der Code, der die HW Beschleunigung ermöglicht, komplett in ffmpeg liegt und 99,9999% dieses kostenpflichtigen Emby Features ausmacht.
Das ist nicht unbedingt ein Feature, das man kostenpflichtig einer Software macht, wenn der Eigenanteil an der Arbeit unter 0,0001 % liegt.
Eine Lizenz benötigt man nur für das Hardwaretranscoding (welches im LAN aber keinen Sinn macht)
Ist das rechtlich geprüft worden?
Die visual examples (unten im Artikel) sehen natürlich überzeugend aus: https://netflixtechblog.com/optimized-shot…ng-47b516b10bbb Wobei ich daraus nicht erkennen kann, ob da h264 mit (jetzt) h265 vergleichen wird. Die 4k Inhalte müssten aber generell schon vorher h265 gewesen sein, also möglicherweise haben die tatsächlich einfach ziemlich gute Optimierungen entwickelt.
Es ist keine Änderung des Codecs.
Was sie da machen, kann man vielleicht am "1pass feste Bitrate vs. CRF Modus " erklären.
Bei "1pass feste Bitrate" wird der Film einfach mit einer festgelegten Bitrate kodiert. Ob der Film bei der jeweiligen Szene mit dieser Bitrate gut oder scheiße aussieht, ist dabei völlig egal. Die "feste" Bitrate irgendwie einzuhalten, ist Gesetz.
Beim CRF Modus wird der Film etwas analysiert und dem Codec versucht anhand der Motion einzelnen Szenen mehr oder weniger Bitrate zuzuteilen, um dem Näherzukommen, was das menschliche Auge sehen kann. Dadurch spart man in Szenen, die das Auge sowieso schlecht sieht, um dann dann in anderen Szenen mehr Bitrate zugeben zu können. So erhält man insgesamt eine bessere Qualität des Film fürs Auge, auch wenn die Bitrate insgesamt niedriger sein kann.
Und was Netflix da macht, ist praktisch CRF extrem ausgebaut. Einzelne "Shot" - also praktisch Szenen - werden da mehrfach kodiert und extrem aufwendiger als noch bei crf analysiert. Und am Ende sucht ein Algo aus den Varianten der einzelnen Shots den "perfekten" Stream raus. Und dadurch können sie Bitrate sparen, obwohl es dem Auge nicht auffällt bzw. einzelne Szenen sogar besser aussehen, weil der Algo bei einzelnen Szene festgestellt hat, dass es sich lohnt, dort mehr Bitrate zu investieren.
Zeig erstmal, was
df -hanzeigt.
Mit all_squash mappst du alle NFS-User auf die lokale ID -2 (oder vorzeichenlos 65534) und der User nobody wird nicht die Rechte haben, die Dateien zu lesen.
Und Dateien, auf die ein NFS-User keine Rechte hat, werden nicht angezeigt.
Du solltest noch anonuid und anongid in /etc/exports auf eine User-ID bzw. Group-ID setzen, die es auf deinem Linux Server gibt und der auf deine Dateien zugreifen darf.
Oder die Rechte aller Dateien auf den User nobody umändern.
Und dann den FireTV neu starten. (Kodi unter Android cached die NFS Seiten sehr gut)
Wie sieht denn die Verkabelung bei dir aus?
Du hast Transport Fehler, die kommen z.B. vor, wenn durch die Verkabelung das Signal zu schwach ist.
Das wird ja auch eigentlich nur von den Chips zurück gemeldet und dann sicher(!!!!) verarbeitet.
Das Problem ist das das Abspielen von Original Scheiben mit HDR nur läuft wenn die ganze Sicherungskette verifizierbar läuft. Und da tun sich halt die Hersteller schwer eine offene Plattform so allumfassend zu unterstützen..
Ja, funktioniert mit den angepassten Versionen. Sowohl mit meiner 2080Super und mit der AMD APU 2200G
https://forum.kodi.tv/showthread.php?tid=349861
Funktioniert das denn auch im Fenster Modus?
Daran hängt es ja unter Linux.
Ich habe die Frage auch noch mal im LibreElec Forum gestellt.
Scheint nicht groß anders zu sein als vor zwei Jahren. So lange man eine Intel GPU hat, alles top. NVidia, vor allem auf lange sicht, ein ziemlicher flop.Mal gucken was man da zu AMD sagt.
Ich möchte eigentlich nur ein Dual Boot System haben, LE für Kodi, Windows fürs Gaming. Die Hardware ist schon vorhanden, aber ganz ehrlich bis auf die GPU ist ja egal was ich einsetze.
Ehrlich gesagt finde ich wenig über AMD HW Decoding. Zumindest auch, dass sich keiner beschwert, dass es nicht funktioniert. Was ein gutes Zeichen sein könnte.
Was hast du denn so vor?
Und welche Hardware hast du denn im Auge?
Bei AMD weiss ich es nicht, da beobachte ich das auch eher aus der Ferne. Da sind ja beim Gaming einige aktiv (z.B. https://www.youtube.com/watch?v=6RfJoH1N6IQ - stark gepatchte Arch Linux Version, nix fertiges, dass man einfach runterladen kann), aber bei Hardware Video Decoding weiss ich gar nix.
Bei Nvidia geht ja alles über Cuda, dass will aber Kodi nicht unterstützen. Im letzten NVIDIA 450 Linux Beta Driver haben sie aber nochmal VDPAU aktualisiert.
- HEVC 10/12-bit "decode only" support has been added to the VDPAU driver.
Wenn Kodi VDPAU noch nicht rausgeworfen hat, gibt dürfte das irgendwann gehen.
Alternativ wäre VAAPI bei Nvidia:
Chrome unterstützt ja jetzt VAAPI Decoding im Browser, aus diesem Grund wurde der NVIDIA VDPAU-VAAPI wrapper (https://github.com/xtknight/vdpau-va-driver-vp9) wiederbelebt.
Bei mir spielt Brave (Chrome Browser Variante) brav die 4K Videos von Youtube und Twitch über VAAPI-VDPAU Wrapper per Hardware ab.
Danke dir. Kannst du das noch genauer erläutern bzw, eine Referenz nenne?
Wenn es nur darum geht, dass es schwerer ist, Streams aneinander zu hängen: das passiert ja auch, wenn man an I-Frames einen Werbeblock rausschneidet. Und das scheinen ja avidemux und ts-doctor gut zu beherrschen, ohne Artefakte.
Beispiel: ein HD Stream mit H264 kodiert
Wenn du nur an I-Frames schneidest, nimmst du einfach ganze GoPs raus. Dann die übrig gebliebenen GoPs wieder aneinanderzufügen, ist dann einfach, weil ja alle GoPs vom gleichen Encoder und mit den gleichen Kodiereinstellungen erzeugt wurden. Und die kannst du relativ einfach aneinander hängen.
Beim Smart Rendern erzeugst du aber neue GoPs. Und die müssen in der Kodierung identisch zu den alten GoPs sein. Und dafür musst du den Encoder und die Kodiereinstellungen der alten GoPs kennen. Diese sind dir aber bei einem fremdem Stream unbekannt. Wenn die Kodierungen der alten und neuen GoPs nicht zusammenpassen, gibt es Probleme an der Schnittstelle (bis hin zum Crash des Decoders)
z.B. meine alte WDTV hatte einen H264 Hardware Decoder
wenn ich ihr einen H264 Stream mit ref=3 ( Referenzframes) gegeben habe, weiss der Decoder, dass er bis zu 3 Frames der schon decodieren Bilder im Decoding Buffer halten muss, um die folgenden Frames decodieren zu können. Und wenn ref über den gesamten Stream gleich war, klappte das auch hervorragend.
Ein Stream aber mit den ersten 250 Frames mit ref=3, und die nächsten 250 Frames mit anderen Kodiereinstellungen (z.B. ref=8), hat den Decoder crashen lassen. Nur Steckerziehen hat ihn dann wiederbelebt. Das auf einmal Frames im Bitstream sind, die bis zu 8 vorherige Frames referenzieren und die er auch nicht im Decoding Buffer aufgehoben hat, hat ihn böse straucheln lassen.
Und bei h264/h265 gibt es viele Parameter, die über den ganzen Stream gleich sein müssen, sonst kommen die Decoder damit nicht klar.
Bei Mpeg-2 war das alles noch einfacher gestrickt.
Findest du die Information noch mal? Würde mich interessieren.
Vielleicht verstehe ich auch Smartrendering nicht. Auf Anhieb will es mir noch nicht in den Kopf, dass es nicht mit Reencoding vom ersten Schnittpunkt bis zum ersten I-Frame und vom letzten I-Frame bis zum Schnittpunkt am Ende gehen sollte. (Dass man nicht einfach abschneiden kann am Ende - was man leicht meinen könnte - ist schon klar, wegen der B-Frames, die auf die Zukunft referenzieren können).
Vom Prinzip funktioniert Smart Rendering bei H264/H265 fast genau so, wie es bei MPEG-2 noch war.
Was sich geändert hat, ist, dass neuere Encoder/Codecs viel mehr Optionen und Optimierungen enthalten, die es umöglich machen, Streams einfach aneinander zu hängen.
Damit das "gesmart gerenderte" Video abspielbar ist, müssen die kopierten GoPs (group of pictures = I Frame mit allen folgenden Bildern, die von diesen I Frame abhängen) kompatibel zu den neu kodierten GoPs sein.
Wenn nicht, gibt es Bildfehler am Schnittpunkt der neuen und alten GoPs.
mal gucken, ob ich irgendwie einen ffmpeg lauf basteln kann, wo bloss psnr von dekodierten bild verglichen wird, einemal mit, einmal ohne mcdeint.
zusatzfrage: Weisst Du, ob bei den multi-channel audio encodern die bits nach bedarf verteilt werden und differentiell codiert wird ? Hoere da naemlich nie irgendwas wesentliches/effektmaessiges von hinten. Der ton ist maximal sterio, aber meistens hoert es sich eher nach Mono an. Da also viele bits fuer 5 Kanaele zu spendieren ist irgendwie sinnlos. Ich selbst hoere da also keinen unterschied wenn ich das auf 5 kanaelen lasse aber mit e.g.: ac3 brutal auf 128 kbps runterbringe. hab da mal auf die schnelle versucht zu vergleichen ob beim codieren auf ac3 128kbps stereo vs. 128 kbps 5+1 hoehere frequenzen weggebuegelt werden, aber mit dem spektrometer von vlc konnte ich da nix sehen. Allerdings weiss ich nicht, ob ich dem trauen kann und ob das sich nicht einfach dynamisch auf das vorhandene spektrum einstellt oder so
Zum Testen allein der Filter kannst du ffplay oder mpv verwenden. z.B. den Film 2x starten (einmal mit, einmal ohne Filter) und dann optisch Standbilder vergleichen.
(der drawbox Filter setze ich nur, damit ich sehe, welches per Filter geändert wurde)
mpv -hwdec=no -v -vf=lavfi=[mcdeint=0,drawbox=10:20:200:60:red@0.5] input.mkv
mpv -hwdec=no -v input.mkv
Audio ist schwierig. Entweder genauso lassen, wie er ist. Wenn du umkodieren willst, vielleicht interessiert dich Dolby Pro Logic 2. ( aresample=matrix_encoding=dplii )
Müsstest aber bißchen googlen, ob es für dich Sinn macht bzw. ffmpeg das vernünftig macht.
Also eigentlich bloss einen de-interlacer finden, weil wenn man das nicht rausnimmt, dann codiert x265 halt interlaced und das kostet dann immer unnötig platz. Hatte erst yadif probiert, aber bin dann bei mcdeint=0 gelandet, aber auch bloss weil er sich irgendwie in den Verkaufsprospekten besser angehört hat und glaube ich im vergleich ein paar % weniger bitrate am Ende brachte.
also wenn das Bild wirklich nicht interlaced ist, dann sollte es bei ffmpeg auch nicht nötig sein, ein interlacer filter drüber laufen zu lassen. Einfach ohne Filter laufen lassen. Da kommt dann auch progressiv raus, weil der Encoder darauf per Default eingestellt ist.
Bitrateänderungen können auch davon kommen, dass ein Deinterlace Filter über ein progressives Bild läuft und dort "optischen Schaden" anrichten und Details zerstört. Das spiegelt sich dann in niedrigerer Bitrate wieder. Ich würde einmal mit und einmal ohne deinterlace Filter laufen lassen und optisch vergleichen, ob ein Filter notwendig ist. Nicht das du dir durch den mcdeint das Bild zerstörst.
Kommt drauf an, was du mit der Karte sonst so machen willst.
Ne Turing Karte (1650 Super und aufwärts) sollte H265 10bit können. Nicht die alten Karten nehmen (da gehört auch die 1650 - ohne Super - dazu)
Prima 
Übrigends einige Erfas vom CCC machen das auch. z.B. der Entropia in Karlsruhe
Also einfach mal beim lokalen Erfa nachfragen, ob sie das auch machen, dann muss man es nicht schicken, sondern kann es so vorbei bringen.
Wie sieht es eigendlich mit 2-pass encoding aus? Das habe ich noch nicht ausprobiert. Hat das großen Einfluss auf die Dateigröße?
Beim 2-pass gibt man ja eine Bitrate an, weil man eine ganz genaue Dateigröße möchte ( um es auf DVD zu brennen z.B.)
2-pass ist bei x264 und x265 nur der CRF Modus, aber in 2 Durchgängen:
CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.
Der erste Pass berechnet nur den crf Wert, der genau zu der gewünschten Bitrate passt.
Zitat von TempeltonPeck
Und noch eine Frage in die Runde: Hat hier jemand schon Erfahrung mit AV1 gesammelt?
Ich hab schon häufiger mit AV1 probiert. Aber der ist mir einfach zu langsam, um das sinnvoll einzusetzen. Vielleicht wenn die ersten Hardware Encoder für AV1 kommen.
Verwende ffmpeg fuer x265 codierug. Glaube das ist effektiv dasselbe wie Handbrake bezueglich dem x265 encoder, hat halt noch mehr andere Parameter/filter mit denen man rumbasteln kann. Deinterlacing z.b. Wenn jemand was weiss, wo HandBrake besser ist als ffmpeg wuerde mich das interessieren. Gilt natuerlich nur fuer linux/CLI, wer gui oder windows will ist wahrscheinlich mit Handbrake einfacher dran.
Ich hatte vor kurzem angefangen zu versuchen x265 codierung von meinen DVD rips zu machen. das ist leider schwieriger als von gutem, neuen material weil da alles arten von problemen im material sind. NTSC->PAL konvertierung, interlaced 24fps->25fps speedup usw usf...
Ich denke, den einzigen Filter den Handbrake mehr hat, ist der decomb Filter. Aber wenn dich Filter interessieren, hast du dir schon http://www.vapoursynth.com/ angesehen?
Gibt da ja etliche Filter die unter Linux funktionieren. https://aur.archlinux.org/packages/?O=0&…00&do_Search=Go
Bei manchen Filmen sind mir später in großen dunklen Szenen Kompressionsartefakte aufgefallen. Dann habe ich den Film nochmal gerendert mit CFR 18 auf Preset Medium. Das hat die Artefakte eliminiert bei fast gleicher Dateigröße. 100-300MB mehr sind da zu verkraften. Auch Neuzugänge habe ich mit den Settings gerendert.
Wegen der Artefakte in dunklen Bereichen. Hast du mal mit H265 aber 10 Bit probiert?
Die AQ der Codecs sorgt dafür, dass helle und für das Auge besser sichtbare Bereiche immer deutlich mehr Bitrate bekommt. Dann reichts aber in dunklen Bereichen nicht aus.
Und man kann dann entweder den ganzen Film mit Bitrate tot schmeissen (und/oder an AQ rumdoktorn), was du mit dem niedrigeren crf Modus machst. Die bessere Option ist aber 10bit,
Im 10bit Modus reicht ihm die wenige Bitrate, um auch dunkle Bereich vernünftig darzustellen.
Man findet oft im Internet Empfehlungen von über CFR20. Das finde ich zu wenig. Mindestens CFR20 und je langsamer der Preset desto besser. Allerdings nicht langsamer als Slow, denn ab slower scheinen die Files wieder größer zu werden.
Das die Dateien größer werden, liegt am CRF Modus. Durch ein langsameres Preset wird Bitrate gespart und der CRF Modus investiert diese Bitrate, wenn er es für sinnvoll hält. Deshalb kann eine Datei bei verschiedenen Presets beim CRF Modus unterschiedlich groß werden.
Die Presets medium/slow/slower wirklich nur dazu verwenden, um die Geschwindigkeit des Codecs zu steuern. Und den Rate Faktor (crf) um die Qualität zu steuern.
Die Dateigröße, die am Ende beim CRF Modus rauskommt, hängt von sehr vielen Faktoren ab, die sich gegenseitig beeinflußen. Deshalb am besten ignorieren.
Bei Serien nehme ich CRF20, bei Filmen aus dem TV oder BR-Rips darf es CRF18 sein. TV-Aufnahmen mit einer Größe unter 6GB recodiere ich überhaupt nicht - lohnt den Aufwand nicht.
Bei mir variiert der CRF Wert immer etwas, kommt drauf an, wieviele feine Details ich aus dem Original übernehmen will.
Je mehr feine Details ich übernehmen will, desto niedriger setze ich den CRF Wert.
z.B.:
ne normale DVD mit Mpeg2 Stream hat ein recht sauberes Bild, aber halt nur mittlere SD Auflösung. Also nicht sehr viele feine Details, die ich "retten" möchte. -> CRF 20
ne Blueray mit HD Auflösung und guter Qualit -> viele Details -> niedriger crf Wert -> z.B. crf 17-18
ne SD TV Aufnahme ist schwieriger -> Bild völlig zermatscht und kaum Details vom eigentlichen Film mehr enthalten, aber Bild gleichzeitig durch schlechte Komprimierung verrauscht -> Rauschen sind feine Details
Entweder Rauschen loswerden -> Noise Filter und crf 23, um das Rauschen (und die letzten Details des Films) loszuwerden.
Oder crf 17-18 um auch das Rauschen mit zu übernehmen.
mfg,
monarc
@monarc99das mit Intel QS versteh ich noch nicht ganz, hast du dazu mehr Infos? Mein Wissensstand war, Encoding über GPU ist schnell aber qualitativ schlecht, CPU ist top und Intel kann es dank QuickSync schneller und genauso gut?
Mister XY hat es ja schon gesagt. Viele Intel CPU haben eine onboard Grafikkarte und darauf kann man dann Intel QuickSync laufen lassen. Also ganz normales Encoding über eine GPU.
Wobei die Hardware Encoder aber inzwischen - in der neuesten Hardware Generation, also den neuesten Grafikkarten - schon gut bei der Quali mithalten können.
z.B. Nvidia Turing ( z.B. GeForce RTX 1660 2060 2070 2080 )
hier ein reiner Qualitäts-Vergleich zwischen CPU/GPU Encoder vor ca. 1 Jahr: Codec Vergleich
(Geschwindigkeit wird nicht beachtet, aber die GPU Codecs sind grundlegend schneller)
Was man in dem Diagramm sieht:
Nvidia Turing (GPU) schneidet bei hevc (h.265) und avc (h.264) sehr gut ab. Hat aber das Manko, keinen CRF Modus zu besitzen.
x265 ähnlich gut wie Turing, aber deutlich langsamer. Und hat den CRF Modus, den man gerne bei Umwandlungen möchte.
QSV (GPU) ist bei avc (h.264) gut, bei hevc (h.265) aber mies.
Die restlichen Codecs kann man sich selbst aus dem Bild entnehmen. Der Name unten beschreibt, was getestet wurde: Codec _ Bitrate (1 Pass - Twitch Streaming) _ Codec Parameter
Je höher der Balken, desto besser die Qualität des Codecs. Also AV1 und VP9 in dem Diagramm.
![[dy]](https://www.kodinerds.net/wcf/images/smilies/smiley140.gif "dy"){kind=small}
