Selbstverständlich kann der Pi3 (Modell B, das neue B+ hat ja noch 200 MHz mehr) 1080p/24fps in h.265 wiedergeben!
Per Software Decoder ff-hevc-mmal (SW). Allerdings keine zu hohen Bitraten. Bei etwas über 5000 kbps (nur Video, ohne Audio) zeigt top bei mir in der Konsole eine CPU Last von bis zu 250-300 % ( 100 % pro Kern, also maximal 400 %). Die Temperatur geht dabei aber gegen die 80 Grad. So zwischen 75 und 79 Grad.
Bei 2700 kbps CPU Last ca. 150-170 % und Temp ca. 72 Grad.
Wird die Bitrate zu hoch kommt der Pi ins Throttle und dann reicht die Rechenleistung natürlich nicht mehr.
Am besten selbst einen großen CPU Kühler basteln, bzw. passend sägen. Aus dem, was man so an alten Kühlern rumliegen hat und mit Sekundenkleber festkleben. Aber Achtung: Mit Sekundenkleber gilt einmal drauf, nie wieder runter!
Kühler so groß wie es geht und ein möglichst offenes Gehäuse verwenden oder gar keines. Ich habe das Standard Raspberry Gehäuse und den Kühler so groß gemacht, daß er ihn die Aussparung paßt. Stattdessen hätte ich lieber mit dem Seitenschneider die innere Kunststoffabdeckung weg knipsen sollen und den Kühler so groß wie möglich dimensionieren sollen. Geht aber auch so; ich lasse halt den Deckel offen.
Da 1080p/h.265 aber gerade dazu benutzt wird um Platz und damit Bandbreite zu sparen, sollten 5000 kps schon an der Obergrenze liegen. Ansonsten würde der Einsatz von HEVC bei 1080p den Sinn verlieren.
Etwas OT: Generell kann man sowieso über den Sinn von HEVC bei 1080p nachdenken. So sehr viel Einsparung bringt das nicht.
http://compression.ru/video/codec_comparison/hevc_2017/
Je nach Material 10-15 % und manchmal nicht mal das. Mit Preset slow oder slower und ref=5 ist x.264 schon sehr gut und bringt sehr gute Kompressionsraten. Viele Coder nutzen das Potential von x.264 nicht wirklich aus. Aus Zeitgründen oder Unwissen.
Der h.265 spielt seine Stärken bei hohen Kompressionsraten aus. 1080p/h.265 sieht bei 2000 kbps und auch deutlich darunter immer noch passabel aus. Bei Bitraten über 4000-5000 kps lohnt h.265 bei 1080p imho nicht wirklich.
Bei niedrigen Bitraten bis 3000-4000 kbps kann sogar der Pi2 h.265.
Per Software Decoder ff-hevc-mmal (SW). Allerdings keine zu hohen Bitraten. Bei etwas über 5000 kbps (nur Video, ohne Audio) zeigt top bei mir in der Konsole eine CPU Last von bis zu 250-300 % ( 100 % pro Kern, also maximal 400 %). Die Temperatur geht dabei aber gegen die 80 Grad. So zwischen 75 und 79 Grad.
Bei 2700 kbps CPU Last ca. 150-170 % und Temp ca. 72 Grad.
Wird die Bitrate zu hoch kommt der Pi ins Throttle und dann reicht die Rechenleistung natürlich nicht mehr.
Am besten selbst einen großen CPU Kühler basteln, bzw. passend sägen. Aus dem, was man so an alten Kühlern rumliegen hat und mit Sekundenkleber festkleben. Aber Achtung: Mit Sekundenkleber gilt einmal drauf, nie wieder runter!
Kühler so groß wie es geht und ein möglichst offenes Gehäuse verwenden oder gar keines. Ich habe das Standard Raspberry Gehäuse und den Kühler so groß gemacht, daß er ihn die Aussparung paßt. Stattdessen hätte ich lieber mit dem Seitenschneider die innere Kunststoffabdeckung weg knipsen sollen und den Kühler so groß wie möglich dimensionieren sollen. Geht aber auch so; ich lasse halt den Deckel offen.
Da 1080p/h.265 aber gerade dazu benutzt wird um Platz und damit Bandbreite zu sparen, sollten 5000 kps schon an der Obergrenze liegen. Ansonsten würde der Einsatz von HEVC bei 1080p den Sinn verlieren.
Etwas OT: Generell kann man sowieso über den Sinn von HEVC bei 1080p nachdenken. So sehr viel Einsparung bringt das nicht.
http://compression.ru/video/codec_comparison/hevc_2017/
Je nach Material 10-15 % und manchmal nicht mal das. Mit Preset slow oder slower und ref=5 ist x.264 schon sehr gut und bringt sehr gute Kompressionsraten. Viele Coder nutzen das Potential von x.264 nicht wirklich aus. Aus Zeitgründen oder Unwissen.
Der h.265 spielt seine Stärken bei hohen Kompressionsraten aus. 1080p/h.265 sieht bei 2000 kbps und auch deutlich darunter immer noch passabel aus. Bei Bitraten über 4000-5000 kps lohnt h.265 bei 1080p imho nicht wirklich.
Bei niedrigen Bitraten bis 3000-4000 kbps kann sogar der Pi2 h.265.
T
tek9
Gast
Er wollte sicherlich nur darauf hinweisen das sich seine Zahlen lediglich auf die Video Bitrate beziehen. Wobei ich auch keine Probleme damit sehe das zu den genannten 5mbits für das x265 Video nochmal 1,5 mbit für DTS Core dazu kommen.
Der Ton wird per Passthrogh durchgereicht, während das Video vom PI decodiert wird.
Der Ton wird per Passthrogh durchgereicht, während das Video vom PI decodiert wird.
tek9 schrieb:
Exakt.
Ich habe ca. 80 Videos in HEVC. Die höchsten Video-Bitraten liegen bei etwas über 5000 kbps und crf 20, was bei x265 mehr als ausreichend sein sollte. Audio kommt natürlich nochmal dazu; auch DTS original übernommen kein Problem. Bandbreite insgesamt gut 7000 kbps.
Das Problem ist die Kühlung. Zuvor ohne Kühler ging es nicht, bzw nur mit niedrigeren Bitraten.
Bis auf ein paar laufen die Videos auch auf dem Pi2 ohne Ruckler, bei ca. 15 Grad niedrigerer Temperatur und identischer Kühlergröße. Temperatur scheint beim Pi3 ein generelles Problem zu sein oder ich habe einfach nur ein schlechtes Exemplar erwischt.
Mit den Bitraten ist das natürlich so eine Sache, da sie variabel sind. Aber in den Videos ruckeln auch die problematischen Szenen nicht, wie Vollschwenks mit vielen feinen bewegten Strukturen.
Bei den Jellyfish Test-Videos entspräche das dem Anfang des Videos mit den vielen kleinen Krebstierchen oder was immer das ist. Da sieht es etwas anders aus. 3 mbps läuft komplett ohne Ruckeln und 5 mbps ruckelt zu Beginn 2-3 mal. In der Praxis macht sich das (bei mir) aber nicht bemerkbar und persönlich halte ich crf 20 bis 22 gegenüber 2 pass mit bitrate=5000 überlegen.
Grundsätzlich stellt sich aber die Frage nach dem Sinn von HEVC bei 1080p. Nach diversen Versuchen stimmen meine eigenen Ergebnisse ziemlich gut mit denen von den weiter oben verlinkten Russen, die regelmäßig die gängigen Codecs testen, überein.
Bei 1080p lohnt der Einsatz von HEVC nicht wirklich. Da bringt x265 nur unwesentlich bessere Kompressionsraten als x264.
Lediglich bei sehr niedrigen Bitraten sticht x265 hervor, weil es immer noch mehr als akzeptabel aussieht.
Wenn man noch keinen Pi hat, dann halt Odroid C2 für knapp 60 € bei Pollin. Noch interessanter erscheint mir das neue Asus Tinker Board S, das nächsten Monat in den Handel kommen soll. Das erste ohne S hatte eine nicht funktionierende CEC Implementation. Das neue mit S hat dann auch 16 GB eMMC und ansonsten noch so nette Sachen wie einen vernünftigen Audio Codec, eine Option für externe WLAN Antenne, GbE ...
Aber dafür gibt es bisher noch kein offizielles LibreELEC.
Zuletzt bearbeitet:
T
tek9
Gast
Ich bin gespannt wie es mit x265 und FullHD weitergeht. Releases in SD und x264 gab es erst recht spät und so richtig angekommen ist der Codec bei dieser Auflösung nimmer.
@Sparkraft: Mit welchem Player etc spielst du die x265 Videos auf dem PI ab?
@Sparkraft: Mit welchem Player etc spielst du die x265 Videos auf dem PI ab?
Software ist LibreELEC, aktuelle Version.
Ich weiß nicht genau wie frei ich hier schreiben kann. Sagen wir mal so, ich habe eigene Versuche/Videos und welche von Freunden. Was mich selbst überrascht hat, bis auf einige, die wirklich dann nicht anschaubar wäre, laufen sie auch auf dem Pi2 unter LibreELEC.
Wer aber noch keinen Pi hat, dem würde ich die kleine Mehrausgabe zu der genannten Alternative empfehlen. Teurer, aber dafür nochmal eine ganze Ecke potenter ist der kleinste Intel NUC mit Apollo Lake für etwas über 100 €, bzw. der Nachfolger. Bei den NUCs muß aber bei Bedarf aus England das CEC Modul nachgekauft werden.
Zu 1080p/x265 ist die Frage ob da noch viel raus zu holen ist. Bei den Russen auf der Seite gibt es ein PDF mit detaillierten Vergleichen der codecs bei unterschiedlichen Presets/Bitraten. Das habe ich mir durchgelesen und mit eigenen Versuchen verglichen. Allerdings anders als die Russen ohne PSNR/SSMI berechnen zu lassen, reine Sichtprüfung auf einem 46" TV.
x264 ist über die Jahre einfach immer besser geworden. crf 19 bis 20 bei Preset slow oder slower und Tune film, ref auf 4 oder 5 runter wegen Zeit und mehr bringt auch kaum noch Platzersparnis; das bringt schon so gute Ergebnisse, daß ich kaum einen Unterschied zum Original ausmachen kann.
Ich code nur crf. 2 pass macht imho nur Sinn, wenn man eine Zielgröße anstrebt, ansonsten ist es m.E. kontraproduktiv. Bei x264 entspricht crf 20 dem Standard und bei x265 23, ohne explizite Optionen wählt x264 automatisch 23 und x265 28, wenn ich mich richtig erinnere.
Ich habe schon 1080p mit x264 und x265 beide bei crf 20 kodiert und konnte aus 1,5 m Entfernung keinen Unterschied mehr feststellen und das bei fast gleicher Dateigröße.
x265 zeigt seine Stärken ~ 1500 kbps und darunter. Da sind sehr hohe Kompressionsraten möglich, so daß eine original DTS Core größer ist, als die Videospur.
Das sieht immer noch gut aus, aber in sehr dunklen Szenen kann es zu Blockbildung kommen. Geht man dann wieder mit der Bitrate rauf, kommt man schon wieder in den Bereich bei dem man sich fragen muß ob x265 zu x264 einen wirklichen Vorteil bringt.
Ich weiß nicht genau wie frei ich hier schreiben kann. Sagen wir mal so, ich habe eigene Versuche/Videos und welche von Freunden. Was mich selbst überrascht hat, bis auf einige, die wirklich dann nicht anschaubar wäre, laufen sie auch auf dem Pi2 unter LibreELEC.
Wer aber noch keinen Pi hat, dem würde ich die kleine Mehrausgabe zu der genannten Alternative empfehlen. Teurer, aber dafür nochmal eine ganze Ecke potenter ist der kleinste Intel NUC mit Apollo Lake für etwas über 100 €, bzw. der Nachfolger. Bei den NUCs muß aber bei Bedarf aus England das CEC Modul nachgekauft werden.
Zu 1080p/x265 ist die Frage ob da noch viel raus zu holen ist. Bei den Russen auf der Seite gibt es ein PDF mit detaillierten Vergleichen der codecs bei unterschiedlichen Presets/Bitraten. Das habe ich mir durchgelesen und mit eigenen Versuchen verglichen. Allerdings anders als die Russen ohne PSNR/SSMI berechnen zu lassen, reine Sichtprüfung auf einem 46" TV.
x264 ist über die Jahre einfach immer besser geworden. crf 19 bis 20 bei Preset slow oder slower und Tune film, ref auf 4 oder 5 runter wegen Zeit und mehr bringt auch kaum noch Platzersparnis; das bringt schon so gute Ergebnisse, daß ich kaum einen Unterschied zum Original ausmachen kann.
Ich code nur crf. 2 pass macht imho nur Sinn, wenn man eine Zielgröße anstrebt, ansonsten ist es m.E. kontraproduktiv. Bei x264 entspricht crf 20 dem Standard und bei x265 23, ohne explizite Optionen wählt x264 automatisch 23 und x265 28, wenn ich mich richtig erinnere.
Ich habe schon 1080p mit x264 und x265 beide bei crf 20 kodiert und konnte aus 1,5 m Entfernung keinen Unterschied mehr feststellen und das bei fast gleicher Dateigröße.
x265 zeigt seine Stärken ~ 1500 kbps und darunter. Da sind sehr hohe Kompressionsraten möglich, so daß eine original DTS Core größer ist, als die Videospur.
Das sieht immer noch gut aus, aber in sehr dunklen Szenen kann es zu Blockbildung kommen. Geht man dann wieder mit der Bitrate rauf, kommt man schon wieder in den Bereich bei dem man sich fragen muß ob x265 zu x264 einen wirklichen Vorteil bringt.
Zuletzt bearbeitet:
Ähnliche Themen
