Ich habe ein Problem mit der Konvertierung von Aufnahmen von HBO, wobei die meisten meiner Plex-Clients die Inhalte nicht abspielen. Ich habe mich durch Logs gewühlt und komme nicht wirklich weiter, aber vielleicht übersehe ich auch nur etwas. Normalerweise würde ich einfach MP4 Unprocessed verwenden, dachte aber, vielleicht würde eine Konvertierung helfen, also wechselte ich zu MP4 High Quality in der Hoffnung, dass die Transkodierung etwas bewirkt.
Ich sehe viele Fehler im Quellvideo, das könnte der Grund sein, warum Plex auch nach der Konvertierung Probleme mit der Datei hat. Wenn ich raten müsste, wirst du beim Abspielen Ruckler und Aussetzer feststellen.
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=25 35 at 0 68
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] Warning MVs not available
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in B frame
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [vist#0:2/mpeg2video @ 0000026c3801ca00] corrupt decoded frame
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=23 7C at 0 68
…
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in P frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=28 4 at 0 68
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] Warning MVs not available
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in I frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [vist#0:2/mpeg2video @ 0000026c3801ca00] corrupt decoded frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → Last message repeated 1 times
Dies wird normalerweise durch ein schlechtes OTA-Signal oder ein Problem mit den Treibern der Aufnahmekarte verursacht.
Ich habe bemerkt, dass du WTV verwendest. Wenn die Quell-WTV-Datei in WMC einwandfrei abgespielt wird, könntest du versuchen, diese Option zu verwenden. Füge diese dem Profil hinzu (in deiner profiles.conf-Datei), das du verwendest, und prüfe, ob es hilft. Dies wird die nativen WTV DirectShow-Filter verwenden, um die Datei zu decodieren, was helfen könnte, Fehler zu beheben, falls möglich:
ForceWTVStreamsRemuxing=true
Wenn das nicht hilft, könntest du eine alternative Option im Profil ausprobieren, um die WTV-Dateien zu decodieren, indem du verwendest:
Die Wiedergabe in Plex war … nicht besonders gut. Im besten Fall ruckelte es extrem (also 0,5 s laufen, 2 s Pause, dann von vorne). Komischerweise lief die Wiedergabe auf meinem iPhone einwandfrei – vermutlich macht Apple da clientseitig etwas Besonderes. Die Datei läuft direkt auf dem HTPC, auf dem sie aufgenommen wurde, auch sauber – das ist schon mal ein Pluspunkt.
Ich glaube nicht, dass es am Signal liegt; weder der Tuner noch andere Sender (HDHR Prime) zeigen Fehler an. Dennoch wäre es nicht das erste Mal, dass mein Kabelanbieter den HBO-Stream verkackt. Ich weiß nicht mehr, woran es damals lag, aber vor Jahren ist ein Media-Center-Extender wegen eines Framerate-Problems durchgedreht. Ich vermute eher Inkompetenz als Absicht – sie sind einfach schlecht in dem, was sie tun. An meiner Seite liegt es wohl auch nicht: alles läuft auf einem Win8.1-HTPC, der natürlich keine Updates mehr bekommt.
Jedenfalls habe ich in das No-Convert-Profil die Option ForceWTVStreamsRemuxing=true gesetzt. Zunächst lief die Wiedergabe, brach aber schnell wieder zusammen. Das Gleiche passierte mit UseWTVRemuxsupp=true.
ForceWTVStreamsRemuxing=true im Profil „MP4 High“ scheint zu funktionieren! Ich muss noch prüfen, was mein Smart-TV macht, aber damit scheint das Problem erst mal gelöst.
Während die Encodes liefen, habe ich gegoogelt und an dieses Schmuckstück aus der Vergangenheit erinnert:
Da der HTPC sowieso lief (Originalvideo getestet), habe ich das Debug-Tool gestartet – tatsächlich springt die Framerate zwischen zwei Werten hin und her (zu schnell zum Lesen). Es ist also eindeutig ein vermurkstes Signal vom Mutter-Schiff. Direkt am HTPC schaut man sich das problemlos an (wenn auch unbequem), und Streaming funktioniert auch. Ich frage mich, warum das nach Jahren plötzlich auftritt.
Wenn ich mir deine Logs ansehe, scheinst du die Hardware-Kodierung von Nvidia zu verwenden. Ich vermute, dass die Karte die Framerate/Zeitstempel-Probleme nicht bewältigen kann. Versuche, die Hardware-Beschleunigung zu deaktivieren, und schau, ob das hilft, alles zu glätten.
Ok, ich habe mir also eine der „erfolgreich“ konvertierten Sendungen nochmal angesehen und festgestellt, dass – obwohl das Video nicht durchgedreht ist – die Audio-Synchronisation danebenlag, als ForceWTVStreamsRemuxing=true gesetzt war … so etwa 5 s Versatz.
Ich habe UseWTVRemuxsupp=true mit GPU-Encoding ausprobiert; das schien zwar zu funktionieren, wurde aber recht schnell instabil. Nach dem Wechsel auf reines CPU-Encoding läuft die Datei einwandfrei – das scheint also der „Fix“ für das Problem zu sein.
GPU-Encoder sind im Allgemeinen sehr fehlerempfindlich bei Videos und können diese nicht gut kompensieren. Sie sind im Grunde darauf ausgelegt, eine Sache zu tun – und das schnell. Software-Encoder (CPU) sind deutlich flexibler und toleranter, allerdings auf Kosten der Geschwindigkeit.