2.4.8 Beta sieht so aus, als würde FFMPEG streiken – Video stoppt, Audio läuft weiter, unsicher bei h.264 WMC

General Support / Questions Hardware-Kodierung
1

Ich benutze Windows Media Center mit einem Ceton-USB-Tuner unter Windows 7 mit einem Intel i5 2500k

und musste kürlich wegen eines Festplattencrashs eine Neuinstallation durchführen. Ich bin jetzt auf einer neuen Festplatte und bin mir nicht sicher, ob es sich um jede Datei handelt, die ich seitdem aufgenommen habe, aber zumindest um die von gestern, die Video-Probleme haben.

Die Original-WTV-Datei hat das Video durchgehend und läuft sowohl im MediaCenter als auch in VLC.

Die konvertierte Datei hängt sich bei einem zufälligen Zeitpunkt im Video auf.

Ich habe KEINE Werbung-Entfernung aktiviert… habe es beim Neuinstallieren tatsächlich vergessen… dumm…

Die Konvertierung läuft zu Ende und die resultierende Datei endet an einem zufälligen Punkt. Es könnte nach 15 Minuten oder 20 Minuten sein, aber der Ton läuft weiter.

Ich habe die Log-Datei eines Videos geöffnet und es scheint eine große Zahl von Fehlern zu geben.

Die Log-Datei ist lang und sich wiederholend, daher ziehe ich einige Beispiele heraus, die anders erscheinen und einen Hinweis auf das Problem geben.

Ich habe sie als .zip hochgeladen, da es sich um eine 11 MB große Textdatei handelt und

SAMPLE 1

2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] SPS unavailable in decode_picture_timing
2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] non-existing PPS 0 referenced
2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] SPS unavailable in decode_picture_timing
2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] non-existing PPS 0 referenced
2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] decode_slice_header error
2017-10-29T04:38:46 MCEBuddy.AppWrapper.Base → [h264 @ 0000000000577d40] no frame!

SAMPLE 2

2017-10-29T04:39:12 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000000009a24b40] Non-monotonous DTS in output stream 0:2; previous: 71136, current: 69634; changing to 71137. This may result in incorrect timestamps in the output file.

SAMPLE 3

2017-10-29T04:43:10 MCEBuddy.AppWrapper.FFmpegMediaInfo → Past duration 0.955376 too large

SAMPLE 4

2017-10-29T04:43:12 MCEBuddy.AppWrapper.FFmpegMediaInfo → frame= 1170 fps=585 q=-0.0 size= 1579500kB time=00:00:19.51 bitrate=662889.1kbits/s dup=20 drop=0 speed=9.76x

SAMPLE 5

2017-10-29T04:44:34 MCEBuddy.AppWrapper.Handbrake → [04:44:34] qsv_enc_init: using ‘hardware (1)’ implementation, API: 1.4
2017-10-29T04:44:35 MCEBuddy.AppWrapper.Handbrake → [NULL @ 000000000874af20] missing picture in access unit

2017-10-29T04:44:37 MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 0.48 %[NULL @ 000000000874af20] missing picture in access unit

2017-10-29T04:44:39 MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 2.04 % (403.72 fps, avg 391.22 fps, ETA 00h04m18s)[NULL @ 000000000874af20] missing picture in access unit
2017-10-29T04:44:39 MCEBuddy.AppWrapper.Handbrake → [NULL @ 000000000874af20] missing picture in access unit

2017-10-29T04:47:51 MCEBuddy.AppWrapper.Handbrake → [NULL @ 000000000874af20] missing picture in access unit
2017-10-29T04:47:51 MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 77.39 % (412.55 fps, avg 404.15 fps, ETA 00h00m58s)[NULL @ 000000000874af20] missing picture in access unit
2017-10-29T04:47:51 MCEBuddy.AppWrapper.Handbrake → [h264_qsv @ 00000000025a4c20] Error during QSV decoding.: incompatible video parameters (-14)

2017-10-29T04:47:59 MCEBuddy.AppWrapper.Handbrake → [h264_qsv @ 00000000025a4c20] Error during QSV decoding.: incompatible video parameters (-14)
2017-10-29T04:47:59 MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 77.41 % (412.55 fps, avg 404.15 fps, ETA 00h00m58s)[h264_qsv @ 00000000025a4c20] Error during QSV decoding.: incompatible video parameters (-14)
2017-10-29T04:47:59 MCEBuddy.AppWrapper.Handbrake → [h264_qsv @ 00000000025a4c20] Error during QSV decoding.: incompatible video parameters (-14)

How It’s Made Convert to MP4-2017-10-29T04-38-46.0299417-04-00.zip (312.3 KB)

2

Also gestern Nacht habe ich mit Windows Handbrake eine .wtv-Datei in eine mp4 konvertiert, und das lief problemlos ab. Danach habe ich dieselbe Datei mit MCEBuddy konvertiert, und dabei trat wieder das Problem auf, dass das Video bei 21:54 endet, während die Audiospur weiterspielt.

Verwendete Version: MCEBuddy 2.4.8 64bit – 20171006

Ich werde eine Neuinstallation versuchen.

Ich habe einige Dateien, die vor dem Auftreten dieses Problems konvertiert wurden, noch einmal überprüft: Vier von fünf Filmen laufen einwandfrei. Der fünfte zeigt denselben Fehler – das Video endet, die Audiospur läuft weiter. Ich vermute, dass auch einige der TV-Sendungen betroffen sind; das wird jedoch schwieriger aufzuspüren sein, da sie bereits mit den älteren Sendungen zusammengeführt wurden.

Ich werde eine Neuinstallation versuchen. Mir sind keine Änderungen an meinem Computer oder an MCEBuddy bekannt – abgesehen davon, dass ich versucht habe, MCEBuddy dazu zu bringen, die Episodennummern aus dem Internet zu beziehen. Die Videoeinstellungen blieben unverändert, und ich verwende zwar momentan keinen Werbeentferner, normalerweise tue ich das aber schon.

3

Versuch es mit VLC. Wenn das funktioniert, liegt es an einem Decoder-Problem und du müsstest ffdshow, LAV Filters oder Ähnliches installieren.

edit: Der Sandy-Bridge-QuickSync-Encoder unterstützt kein AVC. Versuche auch, die Hardware-Kodierung zu deaktivieren

5

Ich benutze VLC, um sowohl die Original-WTV-Datei als auch die fertige MP4-Datei anzusehen.

Nach einigen Tests bin ich noch verwirrter … heute Nacht hat WMC fünf Sendungen aufgenommen, und die vom Discovery Channel sind diejenigen, die sich aufhängen. Ich habe auch einen Film und eine Folge von „Survivor“ aufgenommen, und diese Dateien laufen nach der Konvertierung in VLC, aber die beiden Sendungen vom Discovery Channel bleiben nach etwa 20 Minuten hängen.

Zusätzlich getestet: Mein Kabelanbieter hat drei Discovery-Kanäle – einen SD-, einen HD- und einen weiteren HD-Kanal mit einer viel höheren Kanalnummer. Bisher habe ich von beiden HD-Kanälen aufgenommen, und die Dateien bleiben nach etwa 20 Minuten hängen, aber nicht an derselben Stelle – innerhalb von 5–10 Minuten. Bei anderen Dateien ist das Stocken jedoch zufälliger und kann am Ende des Films oder der Folge auftreten; glaube ich, waren das Aufnahmen vom History-Kanal.

Normalerweise habe ich keine Probleme mit Aufnahmen vom Discovery Channel, und ich habe buchstäblich Hunderte, wenn nicht Tausende von Folgen.

Es handelt sich also wahrscheinlich nicht um eine „Copy-Once“-Geschichte, keine Ahnung.

Ich werde versuchen, vom SD-Kanal des Discovery Channel aufzunehmen und schauen, was rauskommt.

Wiederhole: Nicht jede Aufnahme hängt sich in VLC auf, und wenn ich sage „hängt sich auf“, meine ich, dass das Video stehen bleibt und der Ton weiterspielt. Es scheinen momentan nur ein paar Kanäle betroffen zu sein.

Ich wette, Discovery SD vs. HD wird sich genauso verhalten, aber wer weiß – ich probiere es einfach mal.

6

Versuchen Sie, die Signalstärke/-qualität für diese Sender zu überprüfen. Stellen Sie außerdem sicher, dass Sie die neuesten Treiber/Firmware für Ihren Tuner verwenden. Nach dem Aktualisieren Ihrer Treiber/Firmware führen Sie einen Sendersuchlauf durch. Es ist möglicherweise Zeit für eine neue CableCARD.

7

Irgendwelche Ergebnisse? Ich habe das gleiche Problem wie du. CableCard und HDHomeRun Prime. Aufgenommenes TV, das mit HandBrake konvertiert wurde: Das Bild bleibt nach 15 oder 20 Minuten stehen, während der Ton weiterspielt. Etwa jede fünfte bis zehnte Aufnahme ist betroffen. Ich habe versucht, dieselbe Folge vom selben Sender zu einem späteren Termin erneut aufzunehmen – beim zweiten Mal trat das Problem nicht auf. Ich nutze Plex DVR für die Aufzeichnungen; die erzeugte .TS-Datei läuft in Plex oder VLC komplett durch. Interessanterweise zeigt VLC beim direkten Abspielen der .TS-Datei zu Beginn die Zeit korrekt an; sobald die Stelle vorbei ist, an der HandBrake scheitert, bleibt die Zeit im Counter dauerhaft auf 00:00 stehen. Die Wiedergabe läuft bis zum Ende ohne Bild- oder Tonstörungen weiter – ein Hinweis darauf, dass die .TS-Quelle beschädigt ist, was VLC/Plex als MPEG2-Transportstrom verkraften, eine Konvertierung nach H.264 aber nicht bewältigen kann.

8

Nein, ich hatte keine guten Ergebnisse. Ich bin bei Comcast, verwende einen Ceton-4-Tuner-USB-Tuner mit MediaCenter unter Win7 und hatte dieses spezielle Problem zuvor noch nie. Allerdings ist mir ein anderes Problem aufgefallen.

Wenn ich mit MCEBuddy in h.264 konvertiere und dann versuche, mit Windows-HandBrake erneut in h.265 zu konvertieren, lässt die Datei Windows-HandBrake straucheln, und HandBrake macht in der Warteschlange keinen weiteren Schritt zum nächsten Video … Das ist wirklich schmerzhaft, weil ich an einem anderen Computer sitze: der Win7-Rechner schafft die h.264-Konvertierung, ist aber nicht leistungsfähig genug, um in einem Schritt mit MCEBuddy auf h.265 zu gehen. Daher verschiebe ich die Dateien auf ein Netzwerklaufwerk und führe dort die Konvertierung mit diesem Computer durch.

Vielleicht sollte ich in etwas anderes als h.264 konvertieren oder einfach nur die Werbung herausschneiden … keine Ahnung.

Ich glaube nicht, dass es ein Problem mit der CableCard oder dem Tuner ist, und – wie du sagst, Matt – betrifft es nicht alle Videos, sondern nur ein paar aus der Menge.

Momentan lösche ich einfach Sendungen, die streiken, aber das will ich eigentlich nicht, weil es sich um Serien handelt und man dann den Faden verliert.

Die von MCEBuddy erzeugte Datei wird definitiv mit einem Fehler geschrieben.