MCEBuddy und FFMPEG-AMD: Beschädigte Datei, riesige Logs

General Support / Questions Hardware-Kodierung
1

Ihr habt früher erwähnt, dass ihr kein AMD-Hardware zum Testen habt, also teste ich auf eigene Faust. Ich habe ffmpeg/ffprobe durch Versionen von Zeranoes Nightly ersetzt/umbenannt und eine Kopie des MKV-Normal-Profils erstellt, das statt x264 den Video-Codec h264_vce verwendet.

Meine Quelle sind 30-minütige TV-Sendungen von HDHomeRun Prime, die in Software einwandfrei konvertieren. Ich habe am MKV-Normal-Profil außer der Angabe eines anderen Encoders für ffmpeg nichts geändert. Alle anderen Einstellungen bleiben gleich.

Das erste und offensichtlichste Ergebnis: Die Videodatei lässt sich nicht abspielen:
Die Datei wird von MediaInfo korrekt erkannt (VCE-Codec, Laufzeit usw.), ist in meinen Playern aber beschädigt/defekt. VLC verweigert die Wiedergabe mit der Warnung „Cannot get block EOF?“. Plex bricht die Wiedergabe oft sofort ab, spielt die Datei später aber ohne Resume-Funktion. Scheinbar hängt es mit einem Timestamp zusammen, der dem Player die Laufzeit mitteilt, obwohl MediaInfo damit kein Problem hat.

Die zweite große Änderung: Die Log-Datei ist riesig:
Das Log ist 22 MB groß, verglichen mit den üblichen <2 MB bei Software-Encodes. Ich habe eine Kopie des Logs hier hochgeladen. Es scheint hauptsächlich aus vielen Crop-Operationen zu bestehen, die in Software nicht auftreten.

Ich mache, was ich kann, aber ich bin ratlos. Wie bekomme ich das mit VLC/Plex kompatibel und kann die riesigen Logs verkleinern?

2

Die Logs sehen in Ordnung aus, sogar das finale Ausgabevideo sieht gut aus:

2018-05-26T13:04:38 MCEBuddy.AppWrapper.Base → Stream #0:0: Video: h264 (Main), yuv420p(tv, progressive), 1920x1072 [SAR 1:1 DAR 120:67], 29.97 fps, 29.97 tbr, 1k tbn, 60 tbc (default)

Ich würde vorschlagen, es auf einem anderen Computer mit einem einfachen Player wie dem Windows Media Player abzuspielen, um Probleme mit deinen Wiedergabe-Codecs auszuschließen.

Wenn das nicht funktioniert, handelt es sich um ein ffmpeg-Problem; du solltest es dort melden, damit die Entwickler es analysieren können.

Außerdem würde ich empfehlen, im Profil und in MCEBuddy einfachere Optionen zu verwenden und dann zu schauen, wo es bricht, bevor du es an ffmpeg meldest.

Versuch ein Profil wie dieses:

[AMD Test]
Description=AMD Test
order=ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec h264_amf -b 1000k -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=false
SkipCropping=true
ffmpeg-UsingHardwareEncoding=true

Dies schaltet im Grunde alle erweiterten Optionen inklusive Cropping aus und sagt MCEBuddy, keine Videoeinstellungen zu ändern, da sie für Hardware-Encoding optimiert sind.

Wenn das funktioniert, kannst du die Optionen nach und nach wieder hinzufügen, um zu sehen, welche Probleme verursacht (z. B. Cropping aktivieren, dann die Hardware-Encoding-Option entfernen, dann x264opts wieder hinzufügen usw.).

3

Der Code, den du mir gegeben hast, funktionierte – erzeugte sehr schnell eine Datei, die sich sogar in VLC problemlos abspielen ließ, und erzeugte ein kurzes (700 K) Protokoll.

Daraufhin änderte ich den Containertyp zu VLC. Erhielt eine Datei, die im Windows Media Player abspielbar war, aber nicht in VLC. Ich werde in den nächsten Tagen noch etwas herumprobieren und testen, doch zunächst scheint diese Methode zu funktionieren, ist aber am besten mit MP4-Dateien kompatibel und nicht mit MKV.

4

Okay, versuchen wir, das Problem zu isolieren. Probier diese beiden jetzt aus:

  1. Probieren Sie dieses Profil aus

[AMD Test MKV]
Description=AMD Test MKV
order=ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec h264_amf -b 1000k -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=false
SkipCropping=true
ffmpeg-UsingHardwareEncoding=true

  1. Dann probieren Sie dieses:

[AMD Test MKV1]
Description=AMD Test MKV1
order=ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec h264_amf -b 1000k -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
ffmpeg-ext=.mp4
ffmpeg-remuxto=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=false
SkipCropping=true
ffmpeg-UsingHardwareEncoding=true

5

Beide Profile erstellten Videos, die abspielbar sind, aber das zweite produzierte in VLC viele Warnungen über Audio-Timings und verlorene Millisekunden an Daten. Das zweite Video schien für den Betrachter überhaupt nicht asynchron zu sein (obwohl ich in der Timeline gesprungen bin und nicht komplett durchgeschaut habe), aber das erste Video lief mit deutlich weniger Drama in den Player-Logs durch und erscheint definitiv vorzuziehen.

Ich habe das erste Profil genommen, die Bitrate auf 1400 erhöht und AutoDeinterlace aktiviert (ich nehme TV für das Streaming auf Geräten ohne Hardware-Decoder auf), um es als Daily Driver für die nahe Zukunft zu nutzen. Wenn ihr jedoch weitere Tests wollt, lasst es mich wissen. Ich verwende hauptsächlich 15-minütige Episoden von Cartoon Network für Tests, und obwohl ich HEVC etc. nicht regelmäßig nutzen würde, hätte ich nichts dagegen, einige Tests für euch durchzuführen. Es wäre schön, wenn AMD in einem zukünftigen Beta-Release zur Hardware-Encoding-Checkbox hinzugefügt würde, anstatt ein benutzerdefiniertes Profil erstellen zu müssen.

6

Nun, das könnte es erklären. Kannst du das verwendete Profil posten?

7

Hallo, ich verwende gerade eine modifizierte Version von der, die du mir gegeben hast, daher sieht sie momentan so aus:

[AMD Test MKV]
Description=AMD Test MKV
order=ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec h264_amf -b 1400k -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=true
SkipCropping=true
ffmpeg-UsingHardwareEncoding=true

Als ich diesen Thread gestartet habe, verwendete ich ein Duplikat von „MKV Normal“ mit geändertem Codec. Das war es, was die beschädigten Dateien mit EOF-Fehlern erzeugt hat.

Ich glaube, ich hatte auch Dateien, die durch AMD-Hardware-Encoding in einem separaten Programm (A’s, StaxRip usw.) korrumpiert wurden und dann von MCEBuddy unverarbeitet zum Comskip/Umbenennen liefen. Das erzeugte ähnliche EOF-Fehler. Kurzzeitig hatte ich einen Workaround, bei dem MCEBuddy jede Datei zweimal laufen ließ: einmal, um eine unkomprimierte .ts zu erstellen und Comskip darauf laufen zu lassen, dann in einen von A’s überwachten Ordner zum Konvertieren, dann die konvertierte Datei verschieben/umbenennen; aber ich wollte das auf ein Programm vereinfachen und habe diesen komplexen Ansatz aufgegeben. Seit ffmpeg 4.0 finalisiert wurde, versuche ich, es mit MCEBuddy zum Laufen zu bringen.

Offenbar war mein Problem hier ein Profil-Problem? Aber ich bin kein ffmpeg-CLI-Poweruser und wusste nicht, wie ich ein funktionierendes Profil erstelle. Das bereitgestellte ffmpeg gegen 4.0 auszutauschen war einfach genug, aber ich kenne viele der x264-Optionen in der ffmpeg-video-Zeile nicht. Selbst das Entfernen des x264-Options-Arguments erzeugte keine stabilen Dateien. Dein Profil tut es.

8

Okay, wir sind kurz davor herauszufinden, welcher Parameter mit AMD nicht funktioniert, probiert dieses Profil:

[MP4 AC3 AMD]
Description=Main profile, gute Qualität 1-Pass MP4 (H.264/AC3) Konvertierung. Verwendet AMD AMF
order=ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec h264_amf -b 1400k -x264opts me=hex:trellis=1:subq=8:partitions=all:8x8dct=1:ref=3:rc-lookahead=50:keyint=25:min-keyint=20:bframes=1:weightb=1:level=4.0:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=0:threads=auto -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
AutoDeinterlace=true
SkipCropping=true
ffmpeg-UsingHardwareEncoding=true
9

Wenn Sie eine AMD-Karte haben, probieren Sie das heutige 2.5.1-BETA-Build aus. Es unterstützt nun die automatische Erkennung von NVidia (CUDA/NvEnc), Intel (QuickSync) und AMD (AMF/VCE) Hardware und aktiviert die Hardware-Beschleunigung automatisch.