Ruckler mit MKV Video aus Handbrake mit Apple TV 4 - H.265/HEVC

[denio]

@Wuchtbrumme - Die Auflösung liegt bei 1918x1080, weil das Quellmaterial so vorliegt, ist eine private Aufnahme eines Gemeindefestes welches mit einer AVCHD CAM aufgenommen worden ist.

@Martin Wendel - Die Angaben bzw. Bitraten von dem "kürzeren Video" sind nur deswegen "niedriger" weil in dem VideoSchnipsel große Teile in Slow-Motion sind. Aber auch bei dem "kurzen Video" kommen die Ruckler zustande, es ist im Grunde nur der Vorspann zu dem "großen Video" mit den selben Settings.

Hier mal die MPC-HC Daten von dem h.265 DemoVideo, welches auf dem ATV4 Problemlos abgespielt wird. Das Demo-Video hat in etwa die selbe overall-Bit-rate wie mein selbst kodiertes Video, zumindest lese ich das aus dem General-Abschnitt, aber in dem DemoVideo wird noch die Bit Rate mit 4939 kb/s angezeigt, was bei meinem selbst kodiertem Video nicht angezeigt wird? Sind das unterschiedliche Punkte?

General
Format : Matroska
Format version : Version 4 / Version 2
File size : 4.70 GiB
Duration : 2 h 00 min
Overall bit rate : 10.1 Mb/s
Encoded date : UTC 2017-11-21 09:20:34
Writing application : mkvmerge v8.6.1 ('Flying') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 00 min
Bit rate : 4 939 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.099
Stream size : 4.70 GiB (98%)
Writing library : x265 1.4+424-2b93cf2a5ac8:[Windows][MSVC 1500][32 bit]
Encoding settings : wpp / ctu=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=0 / subme=0 / merange=25 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / no-open-gop / interlace=0 / keyint=50 / min-keyint=25 / scenecut=0 / rc-lookahead=1 / bframes=0 / bframe-bias=0 / b-adapt=0 / ref=1 / no-weightp / no-weightb / aq-mode=0 / aq-strength=0.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=0.00 / psy-rdoq=0.00 / no-signhide / no-lft / no-sao / no-sao-non-deblock / no-b-pyramid / no-cutree / rc=abr / bitrate=5000 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40
Default : Yes
Forced : No

 

[double_d]

warum ist das Format eigentlich 1918x1080?

Wenn die originalen Breitbildinfos übernommen werden, kommen da schonmal solch krumme Werte raus. Der Effekt ist dann eigentlich ein schwarzer Balken oben und unten im Bild. Da wird i. d. R. dann auch eigentlich nichts skaliert. Allerdings bezieht sich das eher auf die Höhe des Bildes. 1920 x 800 wäre so eine klassische Größe im Verhältnis 2,4:1.

Wenn man sich die Formate von z. B. BluRay Produktionen anschaut, ist kaum ein Video im Format 1920 x 1080.

Hier ist es allerdings seltsam, dass 2 Pixel in der Breite fehlen. Möglicherweise liegt das aber an der Kamera bzw. der internen Bildverarbeitung dieser. Woher kommt das Video?
Aber dennoch solltest Du im Ergebnis die 1920 x 1080 bevorzugen und handbrake so einstellen, dass auch dieses Format rauskommt.

Die Bitrate von 11Mb/s ist zwar doppelt so hoch wie bei dem Demovideo, aber es sind ja auch zwei verschiedene Programme zum Einsatz gekommen, wenn ich das richtig sehe. mkvmerge und handbrake. Und 11Mb/s sind für das AppleTV noch kein Beinbruch. Da hat jeder iTunes Film eine höhere Bitrate, denke ich.
An Deiner Stelle würde ich aufgrund der Größe der Ursprungsdatei (woher kam das Video nochmal) eine möglichst konstante Framerate nutzen und dennoch auf h.265 verzichten. Ebenfalls mal das Originalvideo mit handbrake bearbeiten (von mir aus auch in h.265) und dann nochmal vergleichen, was da raus kommt und wie sich das AppleTV damit verträgt.

Unterschied der Videos ist noch die Framerate. 23,9 und 25. Da muss Du Dich natürlich ans Quellmaterial halten, weil Du sonst Dein Video u. U. langsamer oder schneller codierst.
Aber wie ist das AppleTV eingestellt? Möglicherweise auf 60Hz? Das kann bei der Wiedergabe hier auch ein wenig hinderlich sein, sollte sich allerdings nicht in Abbrüchen äußern, sondern nur in unschönen Rucklern.

 

[Wuchtbrumme]

Nochmal eine Rückfrage: Was ist denn, wenn Du die Datei in h.264 encodierst? Klar, sie ist dann deutlich grösser und auch die Bitrate wird grösser sein, aber wenn das läuft...

 

[denio]

Die Auflösung/ konstante Framrate/Aspekte Ratio/etc. wurden unverändert übernommen, es handelt sich um eine private Aufnahme eines Gemeindefestes, welches mit einer AVCHD CAM aufgenommen worden ist. Ich habe lediglich den Kodierer auf h.265 gestellt und RF 17 ausgewählt, alles andere blieb auf "Auto" bzw. auf den Standard-Einstellungen.

Hab Handbrake genommen, weil es sehr sehr einfach zu nutzen ist, ohne ein halbes Informatik-Studium der Einstellmöglichkeiten hinter sich bringen zu müssen ich wusste nicht das mkvmerge auch zum kodieren genutzt wird? dachte immer nur, dass es ein Teil des MKVToolnix Paketes ist, welches nur zum Muxen und Demuxen genutzt wird? also ich habe es bisher immer nur dafür genutzt könnt ihr mir eine gute Info-Seite empfehlen, wo man sich ein bisschen einlesen kann, wie ich die Kodierung in mkvmerge durchführen kann?

Zur ATV kann ich erst wenn ich wieder zu Hause bin, genauere Angaben machen

Naja hab das Video als h.264 kodiert und sie läuft butterweich, aber das Video ist halt echt nahezu 50% größer, was noch ein Grund ist, warum ich nicht glaube, dass es an der Bandbreite/Anbindung der ATV im Netzwerk liegt, weil das selbe Video in h.264 mit doppelter Größe wird wie gesagt problemlos abgespielt.

 

[Wuchtbrumme]

Ok, das sieht in der Tat so aus. Dann beschleunigt wohl infuse/VLC nicht h.265 in Hardware bzw. ist nicht optimiert. Magst Du meinen Vorschlag mit dem Target h.265 für iTunes nicht mal ausprobieren? Und hast Du überhaupt die Vorlagen von Handbrake benutzt oder da selbst noch Hand angelegt?

 

[denio]

@Wuchtbrumme Hab die Vorlagen von Handbrake genutzt und einfach nur die Bildwiederholfrequenz auf die selbe wie in der Quelle eingestellt, diese ist bei konstanten 25 FPS, hab daher auch die Frequenz auf konstant statt Variable gesetzt. Hab den RF von 22 auf 17 gestellt und den PCM Datenstrom auf AAC umgestellt und MKV ausgewählt. Sonst blieb alles andere unverändert.

Finde kein direktes "iTunes" in den Vorgaben, lediglich "Apple xxxx", hab in meinem Linux-PC (der hat deutlich mehr Dampf als mein Mac Mini 2012) daher Matroska mit "H.265 MKV 1080p30 gewählt, hab jetzt mal geschaut, rein oberflächlich unterscheiden sich die Vorgaben nicht so sehr voneinander, aber wer weiß schon was für Parameter im Hintergrund in den "Encoding settings" gewählt wird. Hab übrigens beim Videokodierer "H.265 (x265)" gewählt und "H.265 10/12-bit (x265)" nicht gewählt, da das Quell Material garantiert nicht in 10/12- bit vorliegt. Kann mal versuchen eines der Apple Vorlagen zu nutzen falls du das mit "iTunes" meinst?

 

[double_d]

Naja hab das Video als h.264 kodiert und sie läuft butterweich, aber das Video ist halt echt nahezu 50% größer, was noch ein Grund ist, warum ich nicht glaube, dass es an der Bandbreite/Anbindung der ATV im Netzwerk liegt, weil das selbe Video in h.264 mit doppelter Größe wird wie gesagt problemlos abgespielt.

Die Größe des Videos ist vollkommen unabhängig. BluRays mit 50GB Datengröße laufen auf einem BluRay Player, der hardwaretechnisch an das Innenleben eines alten Festnetztelefons erinnert.
Theoretisch kann Dein Video 100TB groß sein und es würde problemlos übers Netzwerk laufen, da es sich hier ja um eine Echtzeit-Wiedergabe handelt. Bis auf die Sequenzen und die Größe, die in den Puffer geladen wird, wird das Netzwerk ja auch nicht weiter belastet. Selbst die Bitrate stellt nicht unbedingt die Netzwerkgeschwindigkeit dar, sondern eher die Geschwindigkeit und Datenmenge vom ATV zum Fernseher.
Für Bitraten von 10-20MB/s reicht also eigentlich auch ein 100MBit Netzwerk und Du hast 1GB/s, wenn ich das richtig verstanden habe.

daher Matroska mit "H.265 MKV 1080p30 gewählt, hab jetzt mal geschaut, rein oberflächlich unterscheiden sich die Vorgaben nicht so sehr voneinander, aber wer weiß schon was für Parameter im Hintergrund in den "Encoding settings" gewählt wird.

Das ATV mag eigentlich keine mkv und spielt die imho auch nicht nativ ab. Deine Abspielsoftware regelt das und hat natürlich auch dann entsprechend Rechenarbeit zu leisten, wozu schlicht die Performance des ATV nicht ausreichen wird.
Ich würde auch mal versuchen, ganz flott und schlicht einen Plex-Server auf dem Celeron einzurichten und das besagte "Problemvideo"
darüber am ATV abzuspeieln mit dem Plex Client aus dem AppStore. Könnte wetten, dass damit auch das Video ohne weitere Bearbeitung abgespielt wird.
So wie ich das verstehe, holst Du aktuell nur das Video ohne transcodieren ab. Damit wird die gesamte Performance der NAS oder des Rechners ignoriert und erst die Leistung des AppleTV genutzt um das Video abspielbar zu machen.

 

[Wuchtbrumme]

[
Finde kein direktes "iTunes" in den Vorgaben, lediglich "Apple xxxx", [...]
Kann mal versuchen eines der Apple Vorlagen zu nutzen falls du das mit "iTunes" meinst?

ja, das wäre gut. Endergebnis wäre ein MP4, das Du direkt über iTunes und die Freigabe abspielen könntest. Es wäre interessant zu wissen, ob das problemfrei funktioniert, wenngleich es nur hieße, dass die Apple-Abspielsoft- und Hardware weniger Probleme hätte...

 

[Wuchtbrumme]

Die Größe des Videos ist vollkommen unabhängig. BluRays mit 50GB Datengröße laufen auf einem BluRay Player, der hardwaretechnisch an das Innenleben eines alten Festnetztelefons erinnert.

boah, wie arrogant! Jeder DVD-DivX-Player schämt sich gerade!

 

[Wuchtbrumme]

Für Bitraten von 10-20MB/s reicht also eigentlich auch ein 100MBit Netzwerk und Du hast 1GB/s, wenn ich das richtig verstanden habe.

Das ATV4 kann nur 100MBit/s.

 

[Wuchtbrumme]

Das ATV mag eigentlich keine mkv und spielt die imho auch nicht nativ ab. Deine Abspielsoftware regelt das und hat natürlich auch dann entsprechend Rechenarbeit zu leisten, wozu schlicht die Performance des ATV nicht ausreichen wird.
Ich würde auch mal versuchen, ganz flott und schlicht einen Plex-Server auf dem Celeron einzurichten und das besagte "Problemvideo"
darüber am ATV abzuspeieln mit dem Plex Client aus dem AppStore. Könnte wetten, dass damit auch das Video ohne weitere Bearbeitung abgespielt wird.
So wie ich das verstehe, holst Du aktuell nur das Video ohne transcodieren ab. Damit wird die gesamte Performance der NAS oder des Rechners ignoriert und erst die Leistung des AppleTV genutzt um das Video abspielbar zu machen.

gute Idee, aber natürlich Mehraufwand

 

[Martin Wendel]

@denio: Du kannst das MKV-Video ohne Neucodierung mit MP4tools (du solltest mit der Gratis-Version auslangen finden) in ein MP4-Format „umwandeln“. Das ist in kürzester Zeit erledigt und sollte dein Problem beseitigen. Die Dateigröße bleibt praktisch ident.

 

[Wuchtbrumme]

oben hast Du noch geschrieben, dass in den genannten Formaten Hardwaredecoding nicht unterstützt werde und ich schreibe schon seit gestern abend, er soll nach Apple-Spezifikation enkodieren. Manchmaö fragt man sich echt, ob man gegen eine Wand redet.

 

[denio]

Bzgl. des Netzwerks gehe ich auch nicht davon aus, dass das der Flaschenhals ist, ist eine konstante/stabile GB Leitung.

Ja die Kodierung erfolgt ja quasi vorher und die ATV spielt es "normalerweise" ab, was mich halt lediglich wundert, ist dass das DemoVideo läuft, mein "Video" allerdings nicht, beides sind h265 Exemplare. Jetzt ist halt die Frage, mit welchen Einstellungen diese kodiert sind, den offensichtlich kann die ATV das DemoVideo abpielen, also sollte die "Performance" der ATV "reichen", aber wohl nur wenn die "Settings" so gewählt werden, das es "passt".

Was macht den der PlexServer/Client anders als das NAS/Samba/Windows-Freigabe in Kombination mit dem Infuse/VLC? Die reinen "Rohdaten" des Videos bzw. die Anforderungen an die ATV ändern sich doch dadurch nicht, oder irre ich mich?

OK teste es mit dem MP4, im Grunde müsste es doch reichen einen kurzen Abschnitt des Video mit diesen Settings zu kodieren, oder müsste ich das ganze Video kodieren? Weil es dauert selbst auf dem Linux-PC eine Ewigkeit gelinde gesagt

 

[denio]

ok checke auch mal MP4tools aus.

 

[Martin Wendel]

oben hast Du noch geschrieben, dass in den genannten Formaten Hardwaredecoding nicht unterstützt werde

Ja, mit MKV/H265 ist kein Hardwaredecoding möglich.

 

[double_d]

Das ATV4 kann nur 100MBit/s.

Echt? Das wusste ich gar nicht. Hätte drauf gewettet, es wäre mit GBit LAN ausgestattet. Aber ich glaube, dass ist eh irrelevant, weil der TE ja schrieb, dass er das AppleTV ins 5GHz WLAN eingebunden hat. Ich meine etwas von 45MB/s gelesen zu haben, was ja dann real irgendwas um 300MBit/s bedeuten könnte. Also vollkommen ausreichend meiner Meinung nach, auch wenn es sich um WLAN handelt.

Was macht den der PlexServer/Client anders als das NAS/Samba/Windows-Freigabe in Kombination mit dem Infuse/VLC? Die reinen "Rohdaten" des Videos bzw. die Anforderungen an die ATV ändern sich doch dadurch nicht, oder irre ich mich?

Das sind unterschiedlich Dinge. Eine Freigabe ermöglicht es dem Client lediglich das Video so abzuholen, wie es vorliegt und die eventuell anfallende Rechenarbeit erfolgt auf dem Clientgerät. Wenn da die Leistung nicht ausreicht, spielt der Player es halt nicht ab.
Bestes Beispiel ist ein Smart TV mit USB-Anschluss. Sind da AVI oder MOV oder was auch immer für Container oder Formate (Audio/ Video) drauf, die nativ von dem Player auf dem TV nicht abgespielt werden, müsste die Hardware des TVs diese Formate transcodieren, was sie per se nicht schaffen würde und deshalb so etwas auch gar nicht unterstützt wird.

Infuse oder VLC auf dem Apple TV holen bei Dir aber genauso die Inhalte über das AppleTV von der NAS (Freigabe) ab und nutzen die Hardware des AppleTV, um z. B. die Formate, welche das AppleTV nativ nicht abspielen kann, um zu transcodieren. Und genau für diesen Vorgang wird die Hardware (CPU, Grafikeinheit, Speicher) des AppleTV zu schwach sein, weil eben bei dem A8, der im AppleTV ist, kein HEVC Hardwareencoding unterstützt wird. Die Rechenleistung wird also voll und ganz für das softwareseitige Encoding genutzt und lässt dann kaum mehr Ressourcen über und die Wiedergabe stockt oder bricht ab.

Der Plex Server nutzt indes die Hardware des Serverrechners, also z. B. eine NAS, einen MacMini, eine Linuxmaschine etc. um die Formate, die der Client auf dem AppleTV nicht nativ, also ohne Transcoding abspielen kann. Dass AppleTV hat dann also nur noch die Aufgabe den bereits transcodierten Stream in Empfang zu nehmen, ohne dass seine Hardware großartig belastet wird.

Bezogen auf Dein Setup, welches eben kein Transcoding auf Serverseite möglich macht, bietet es sich demnach an, so wie @Wuchtbrumme es nun mehrfach vorgeschlagen hat, das Material in ein Format zu encodieren, welches das AppleTV von Haus aus wiedergeben kann. h.265 bei 1920x1080 max. 30fps, in einem mp4-Container. Das würde bei allen noch existierenden "potenziellen" Problemen, zunächst mal die Hardware des AppleTV entlasten und man könnte hier bestimmte Ursachen weiter einschränken.

kurzen Abschnitt des Video mit diesen Settings zu kodieren, oder müsste ich das ganze Video kodieren? Weil es dauert selbst auf dem Linux-PC eine Ewigkeit gelinde gesagt

Du brauchst nicht die ganzen 6 Stunden zu bearbeiten, aber ich würde da schon ne Stunde bis 2 nutzen. So ein 6 Minuten-Clip hat auch andere Hardwarevoraussetzungen, was das Transcodieren angeht. Ginge es lediglich um einen Test, ob das Format grundsätzlich läuft, reichten ein paar Minuten, ob aber das ATV auch über einen längeren Zeitraum die Leistung halten kann, wenn transcodiert werden muss, sieht man glaube ich nicht so deutlich bei so kurzen Clips.

 

[Martin Wendel]

ok checke auch mal MP4tools aus.

Du musst einfach nur oben Audio- und Videospur anwählen, auswählen dass diese unverändert übernommen werden sollen, und dann auf Convert klicken. Er codiert dann die Videospuren nicht neu sondern packt einfach alles in MP4 um.

 

[denio]

@double_d Jup geht übers WLAN mit den etwa oben genannten Zahlen.

Hmm gut zu wissen das NAS sollte auch als Plex-Server dienen können, würde aber vorher die Kodierung nach den "Apple" Vorgaben im MP4 Container durchführen und schauen wie es sich damit Verhält.

@Martin Wendel werde auch das mal direkt vor Ort testen und berichten. Das Umpacken ging schon mal sauber durch. Werde es nachher an der ATV testen.

Danke an alle für die Hilfe

 

[double_d]

würde aber vorher die Kodierung nach den "Apple" Vorgaben im MP4 Container durchführen und schauen wie es sich damit Verhält.

Das wäre eigentlich auch immer die erste Wahl, weil damit eben keine zusätzlichen Ressourcen bereitgestellt werden müssen.
Wenn es sich irgendwann mal um eine Videodatenbank aus den Heimvideos handelt, tut man gut daran, sich auf ein Format festzulegen, welches den Bedürfnissen der Hardware gerecht wird. HEVCm bzw. h.265 ist da natürlich nun ein lockendes Angebot aufgrund der später geringen Dateigröße und der Möglichkeit bis zu 2160p wiedergeben zu können.

Oftmals ist es aber auch nicht verkehrt an hergebrachten und nun "alten" Standards noch etwas länger festzuhalten.
Die Rechenleistung für die reine Wiedergabe von h.264 FullHD mit x-beliebiger Tonspur ist lachhaft gering, wenn die Clienthardware damit auch von Haus aus umgehen kann. Ich habe meinen SmartTV per DLNA auf einen Server in meinem Netzwerk abgestimmt und die Inhalte werden dort auch nur abgeholt, also nicht transcodiert. Das sind teilweise Dateigrößen im 3stelligen Gbyte-Bereich. ich habe damit keine Probleme. Sowohl Server, als auch Client sind nicht mal ansatzweise ausgelastet und dümpeln bei der Wiedergabe bei wenigen Prozenten im ganz unteren einstelligen Prozentbereich rum. Daher schafft wahrscheinlich auch Dein Celeron die Wiedergabe spielend und das ATV nicht.