Quote Eigentlich wollte ich heute einen Artikel über den Effekt von hardware-basierten Videoencodern in PowerDirector 15 schreiben, doch als ich nach Stunden die Qualität vergleichen wollte, stellte ich fest, dass die Dateigrößen zwischen CPU-basierter Ausgabe und QuickSync sich um etwa Faktor 2 unterscheiden. Beim Abspielen merkte ich dann auch schon mit bloßem Auge, dass die angegebene Bildrate von 25 FPS nicht stimmte. Es sind statt dessen 12,5 FPS. Damit war die Arbeit von einem Abend hin, da alle Zahlen und Resultate falsch sind. Frustrierend. Ich habe bloß das Häkchen bei "Technologie für schnelles Videorendern" weggenommen.

Ich fühle mich an den VW Abgasskandal erinnert. Alle Welt staunt, wie der PowerDirector 15 so schnell rendern kann, bis jemand feststellt, dass er im Testmodus heimlich die Bildrate halbiert. Ich hoffe es gibt eine andere plausible Erklärung dafür als Verbrauchertäuschung?

Habs gerade nachzustellen versucht mit meinem 6700K, einmal mit QuickSync, einmal ohne und kann den geschilderten
Effekt nicht reproduzieren. Die Framerate beträgt stets 25fps.
Da war der Abgasskandal doch etwas total Anderes! Mit solchen Behauptungen, quasi Betrug bzw. Täuschung zu unterstellen lehnst du dich weit aus dem Fenster.

Quote Habs gerade nachzustellen versucht mit meinem 6700K, einmal mit QuickSync, einmal ohne und kann den geschilderten
Effekt nicht reproduzieren. Die Framerate beträgt stets 25fps.
Da war der Abgasskandal doch etwas total Anderes! Mit solchen Behauptungen, quasi Betrug bzw. Täuschung zu unterstellen lehnst du dich weit aus dem Fenster.

Danke, ich hätte da zwei Fragen an dich:

Du hast nur die Trial-Version von PD 15 und nie die Vollversion aktiviert? Sonst würde das gerade meine Vermutung bestätigen, dass es sich im Testmodus (wie ein VW) anders verhält als im Produktiveinsatz. In der Vollversion wäre so ein Problem sicher schnell aufgefallen.

Die angegebene Framerate beträgt stets 25 FPS. Bei modernen Codecs kann sich die Bildrate aber jederzeit ändern. Hast du auch nachgezählt, dass eine Sekunde aus 25 Bildern besteht? Ist die Dateigröße in beiden Fällen identisch oder unterscheidet sie sich um den Faktor 2? Im MPC-HC z.B. kannst du mit der Nach-Rechts-Taste einzelne Frames weiter gehen und so genau zählen wie viele Einzelbilder z.B. zwischen Sekunde 00:01 und Sekunde 00:02 liegen. (00:00 bis 00:01 geht nicht, weil der MPC-HC rundet und bereits nach 0,5s die 00:01 anzeigt.) Oder du fügst etwas von 1 Sekunde Länge ein und zählst dort die Frames.

Obwohl, warte noch mal damit. Ich glaube es gibt eine andere Ursache.

Anfangs fragte ich nach einer anderen plasiblen Erklärung und ich habe sie glaube ich gefunden. Vorweg möchte ich mich dafür entschuldigen, dass ich unterstellt habe die Framerate würde bei reinem CPU Rendering seitens PD 15 halbiert. Das ist nicht der Fall.

Mein jetziger Erkenntnisstand deutet vielmehr auf einen Fehler in PDs H.264 Encoder hin, durch den Frames zu falschen Zeiten angezeigt werden, so dass für den Betrachter und den Video-Player nur etwa die halbe Bildrate sichtbar ist. Zusammen mit der halben Dateigröße entstand für mich der Eindruck es würde die Hälfte fehlen. Beide Videos liegen unter der nominalen Bitrate von 16 Mbit/s, die ich im Preset angegeben hatte und der Software Codec war möglicherweise bereits bei niedrigerer Bitrate an seinem Qualitäts-Maximum mit der einfachen Diashow.

Nun zu den Frame-Timings. Im Preset ist als GOP-Muster IBBPBBPBBPBBP voreingestellt und "dynamische GOP" abgewählt. Von älteren MPEG-Varianten erinnere ich mich, dass die B-Frames nach den von ihnen referenzierten P-Frames geschrieben werden, also in der Reihenfolge, wie sie der Dekoder benötigt: IPBBPBBPBBPBB. Im Programm "Transport Stream Packet Editor" gibt es unten-rechts einen Reiter mit dem Titel "PES Line". Darunter verbirgt sich die Liste der Frame-Typen. "Sort?" sortiert dabei die Frames in Anzeigereihenfolge (nach Presentation Time Stamp).

Merkmale des QuickSync Videos	Merkmale der software-kodierten Videos
GOP-Folge ist IBBPBBPBBPBBP (zeitl. sortiert), IPBBPBBPBBPBB (unsortiert).	GOP-Folge ist IPBPBPBPBPBPBPBPBPBPBPBPB (weicht vom Preset ab und B-Frames sortieren sich bei Anzeige nicht vor P-Frames).
Neue Frames werden nahtlos alle 0,04 Sekunden (25 FPS) angezeigt.	Nach dem ersten Frame gibt es eine Lücke von 1 Frame (0,04 Sekunden).
I-Frames geben Framerate mit 25 an.	I-Frames geben Framerate mit 0 an.
B-Frames haben keinen DTS (Dekodierzeitpunkt).	B-Frames haben einen korrekten DTS, der PTS liegt jedoch nach dem letzen P-Frame. In der Regel wird es davor angezeit.
Das letzte Frame startet bei Sekunde 59,96.	Das letzte Frame startet bei Sekunde 60,00. Es ist also bei einem Video von exakt 60 Sekunden nicht zu sehen.

Die voreingestellte GOP wurde also überhaupt nicht angewendet und die B-Frames werden erst nach den P-Frames zur Anzeige gebracht, was die halbiert erscheinende Bildrate hinreichend erklärt.

Verwendet habe ich für das Video die PowerDirector 15 Trial in Version 15.0.2309.0. Mein Preset basiert auf dem Standard für M2TS, AVC 1920 x 1080/50p mit folgenden Änderungen im Tab "Video":

• Bildrate: 25


• Durchschnittliche Bitrate: 16000 K bps

Das gepackte Projekt befindet sich im Anhang.

Da es vier Downloads des Testfalls gab (plus einer von mir) wollte ich mal fragen: Hat es schon jemand ausprobiert? Vor allem ein Test mit dem letzten Update der Vollversion wäre hilfreich, damit ich den Support über das Problem informieren kann.

Hallo,

Quote Da es vier Downloads des Testfalls gab (plus einer von mir) wollte ich mal fragen: Hat es schon jemand ausprobiert? Vor allem ein Test mit dem letzten Update der Vollversion wäre hilfreich, damit ich den Support über das Problem informieren kann.

ich habe den Testfall nicht heruntergeladen, aber das Problem hört sich (vom Ergebnis) ein wenig so an, wie meines mit der Testfassung von PD. Da ich in Bezug auf Videos noch ein blutiger Anfänger bin, kann ich nicht beurteilen, ob mein Problem die Reihenfolge der Frames ist, aber auch meine Videos, die ich mit dem Hauptprofil und nicht dem Baseline-Profil codiere, sehen so aus, als würden sie mit der halben Framrate abgespielt werden.

Viele Grüße,
Markus

Quote Hallo,

Quote Da es vier Downloads des Testfalls gab (plus einer von mir) wollte ich mal fragen: Hat es schon jemand ausprobiert? Vor allem ein Test mit dem letzten Update der Vollversion wäre hilfreich, damit ich den Support über das Problem informieren kann.

ich habe den Testfall nicht heruntergeladen, aber das Problem hört sich (vom Ergebnis) ein wenig so an, wie meines mit der Testfassung von PD. Da ich in Bezug auf Videos noch ein blutiger Anfänger bin, kann ich nicht beurteilen, ob mein Problem die Reihenfolge der Frames ist, aber auch meine Videos, die ich mit dem Hauptprofil und nicht dem Baseline-Profil codiere, sehen so aus, als würden sie mit der halben Framrate abgespielt werden.

Viele Grüße,
Markus

Hallo,

ich weis jetzt nicht, wie ihr anhand einer Diashow, die halbe Abspielgeschwindigkeit oder was auch immer festmacht.

Es gibt ja die Ausgabeformate in den verschiedenen Geschwindigkeiteten 24,25 oder 50B/s in Pal.

In NTSC liegt dann die Reihe bei24,30 und 60 B/s

Ich habe noch nie ein Video gehabt, was in der falschen Geschwindigkeit wiedergegeben wurde, es sei denn ich habe es so gewollt.

Quote

Quote Hallo,

Quote Da es vier Downloads des Testfalls gab (plus einer von mir) wollte ich mal fragen: Hat es schon jemand ausprobiert? Vor allem ein Test mit dem letzten Update der Vollversion wäre hilfreich, damit ich den Support über das Problem informieren kann.

ich habe den Testfall nicht heruntergeladen, aber das Problem hört sich (vom Ergebnis) ein wenig so an, wie meines mit der Testfassung von PD. Da ich in Bezug auf Videos noch ein blutiger Anfänger bin, kann ich nicht beurteilen, ob mein Problem die Reihenfolge der Frames ist, aber auch meine Videos, die ich mit dem Hauptprofil und nicht dem Baseline-Profil codiere, sehen so aus, als würden sie mit der halben Framrate abgespielt werden.

Viele Grüße,
Markus

Hallo,

ich weis jetzt nicht, wie ihr anhand einer Diashow, die halbe Abspielgeschwindigkeit oder was auch immer festmacht.

Es gibt ja die Ausgabeformate in den verschiedenen Geschwindigkeiteten 24,25 oder 50B/s in Pal.

In NTSC liegt dann die Reihe bei24,30 und 60 B/s

Ich habe noch nie ein Video gehabt, was in der falschen Geschwindigkeit wiedergegeben wurde, es sei denn ich habe es so gewollt.

Ich denke nicht, dass es in der falschen Geschwindigkeit wiedergegeben wird. Wenn ich Video mit dem Baseline-Profil encodiere ist es (fast) genauso groß, als wenn ich das Hauptprofil verwende. Hätte das mit dem Hauptprofil codierte Video nur die Hälfte der Frames, würde ich vermuten, dass es deutlich kleiner wäre. Es sieht eben nur so aus, als würde es mit deutlich weniger Bilder pro Sekunde wiedergegeben (es ruckelt deutlich, wie eine sehr schnelle Serienbildfolge).

Quote

Quote

Quote Hallo,

Quote Da es vier Downloads des Testfalls gab (plus einer von mir) wollte ich mal fragen: Hat es schon jemand ausprobiert? Vor allem ein Test mit dem letzten Update der Vollversion wäre hilfreich, damit ich den Support über das Problem informieren kann.

ich habe den Testfall nicht heruntergeladen, aber das Problem hört sich (vom Ergebnis) ein wenig so an, wie meines mit der Testfassung von PD. Da ich in Bezug auf Videos noch ein blutiger Anfänger bin, kann ich nicht beurteilen, ob mein Problem die Reihenfolge der Frames ist, aber auch meine Videos, die ich mit dem Hauptprofil und nicht dem Baseline-Profil codiere, sehen so aus, als würden sie mit der halben Framrate abgespielt werden.

Viele Grüße,
Markus

Hallo,

ich weis jetzt nicht, wie ihr anhand einer Diashow, die halbe Abspielgeschwindigkeit oder was auch immer festmacht.

Es gibt ja die Ausgabeformate in den verschiedenen Geschwindigkeiteten 24,25 oder 50B/s in Pal.

In NTSC liegt dann die Reihe bei24,30 und 60 B/s

Ich habe noch nie ein Video gehabt, was in der falschen Geschwindigkeit wiedergegeben wurde, es sei denn ich habe es so gewollt.

Ich denke nicht, dass es in der falschen Geschwindigkeit wiedergegeben wird. Wenn ich Video mit dem Baseline-Profil encodiere ist es (fast) genauso groß, als wenn ich das Hauptprofil verwende. Hätte das mit dem Hauptprofil codierte Video nur die Hälfte der Frames, würde ich vermuten, dass es deutlich kleiner wäre. Es sieht eben nur so aus, als würde es mit deutlich weniger Bilder pro Sekunde wiedergegeben (es ruckelt deutlich, wie eine sehr schnelle Serienbildfolge).

Bei mir ruckelt nichts.Player PDVD16

Danke euch beiden für die Hilfe.

Quote Bei mir ruckelt nichts.Player PDVD16

Deine Datei ruckelt bei mir auch nicht. Da sie aber auch doppelt so groß ist wie unsere (96 MiB zu 49 MiB) frage ich lieber noch mal ob du hast das Häkchen für das Hardware-Encoding beim Produzieren wirklich deaktiviert und eine 16000 K bps Bitrate eingestellt hast? Dateigrößen von über 90 MiB bekomme ich nämlich nur beim Hardware-Encoding (Intel oder NVIDIA ist egal) und die damit erstellten Videos sind auch immer "sauber" was die Frame-Timings und Bitraten betrifft.

Quote Danke euch beiden für die Hilfe.

Quote Bei mir ruckelt nichts.Player PDVD16

Deine Datei ruckelt bei mir auch nicht. Da sie aber auch doppelt so groß ist wie unsere (96 MiB zu 49 MiB) frage ich lieber noch mal ob du hast das Häkchen für das Hardware-Encoding beim Produzieren wirklich deaktiviert und eine 16000 K bps Bitrate eingestellt hast? Dateigrößen von über 90 MiB bekomme ich nämlich nur beim Hardware-Encoding (Intel oder NVIDIA ist egal) und die damit erstellten Videos sind auch immer "sauber" was die Frame-Timings und Bitraten betrifft.

Hier ohne Hardwarecodierung.

Quote Hier ohne Hardwarecodierung.

Ok, wir kommen der Sache näher. Eine weiter Analyse mit dem Video PID Analyse durch Transport Stream Packet Editor Professional Ver. 0.815 (ja, 0815 ) gibt folgendes Bild:

PD 15 Lizensiert

PD 15 Trial

PID: 0x1011 Continuity Counter: 0 PTS: 00:00:00:11 (22) 00.440s (Frame: 0) DTS: 00:00:00:10 (20) 00.400s Attributes: H.264 1920x1088 (1920x1080) @ 0.000 fps Payload Unit Start Indicator: True Transport Scrambling Control: 0: (no scrambling of TS packet payload) Adaptation Field Control: 1 H.264 Header: NAL Ref IDC: 3 NAL Type: 5: Coded Slice of an IDR Picture Sequence Parameter Set: Summary: H.264 High Profile Level: 4 (HP@L4) Encoded Picture Width: 1920 Height: 1088 Aspect Ratio: 1:1 Display size: 1920 x 1080

PID: 0x1011 Continuity Counter: 0 PTS: 00:00:00:11 (22) 00.440s (Frame: 0) DTS: 00:00:00:09 (18) 00.360s Attributes: H.264 1920x1088 (1920x1080) @ 0.000 fps Payload Unit Start Indicator: True Transport Scrambling Control: 0: (no scrambling of TS packet payload) Adaptation Field Control: 1 H.264 Header: NAL Ref IDC: 3 NAL Type: 5: Coded Slice of an IDR Picture Sequence Parameter Set: Summary: H.264 Main Profile Level: 4 (MP@L4) Encoded Picture Width: 1920 Height: 1088 Aspect Ratio: 1:1 Display size: 1920 x 1080

Offenbar ist das standardmäßige "Hohe Profil" (aus Lizenzgründen?) in der Trialversion nicht verfügbar und statt dessen wird im einfacheren "Hauptrofil" kodiert. Auf dem Screenshot der Qualitätseinstellungen wäre das dann auch der einzige Unterschied den ich ausmachen kann. Damit hat sich das mit dem Artikel über die Performance von Software- und Hardwarekodierung in der Trialversion erübrigt, denn das Hauptprofil ist simpler und schneller zu kodieren.

Kannst du noch ein letztes Mal deine Einstellungen auf "Hauptprofil" umstellen und ein Software-Encoding starten? Das wäre dann die letzte Bestätigung, dass da ein Bug - auch in der Vollversion - vorhanden ist.

Gruß Bernd
Technical support:
DE:
https://de.cyberlink.com/support/index.html

Nachdem ich jetzt die Ultimate Version von PowerDirector 15 lizensiert habe (mit Coupons und Weihnachtsangebot war das jetzt verkraftbar), kann ich zunächst einmal sagen, dass Ruckeln dort - egal mit welchem Profil ich codiere (Baseline, Main oder High) - nicht auftritt. Es scheint sich tatsächlich um ein Problem zu handeln, das nur beim Software-Rendern in der Demo-/Trial-Version auftritt.

Mein Problem, dass ich trotz angeblich unterstützter NVIDIA GTX 560 Ti keine Hardware-Unterstützung aktivieren kann, bleibt allerdings bestehen

Quote Nachdem ich jetzt die Ultimate Version von PowerDirector 15 lizensiert habe (mit Coupons und Weihnachtsangebot war das jetzt verkraftbar), kann ich zunächst einmal sagen, dass Ruckeln dort - egal mit welchem Profil ich codiere (Baseline, Main oder High) - nicht auftritt. Es scheint sich tatsächlich um ein Problem zu handeln, das nur beim Software-Rendern in der Demo-/Trial-Version auftritt.

Jupp, sehe ich auch so. Hab die Produce_2.m2ts von Bernd auch noch mal durch die Analyse gejagt, aber es war subjektiv schon erkennbar, dass die Datei in Ordnung ist. Danke noch mal für die Unterstützung. Ich hatte mit einem anderen Ergebnis gerechnet und war jetzt am Überlegen, ob es überhaupt Sinn macht das Problem zu berichten, da ja niemand Schaden nimmt, außer dem Ruf der Firma vielleicht. Nachdem wir jetzt so viel Zeit investiert haben, weiße ich den Support zumindest mal auf den Thread und das Problem hin. Im Anhang noch die "kaputte" Datei, wie sie von der Trial-Version produziert wird.

@Twindaddy: NVIDIAs neuere Hardware-Enkoder-Schnittstelle NVENCODE, benötigt mindestens die Keppler-Generation (z.B. 600er-Serie). Dein Fermi-Chip ist genau die Generation davor. Möglicherweise hat es damit zu tun.

Quote @Twindaddy: NVIDIAs neuere Hardware-Enkoder-Schnittstelle NVENCODE, benötigt mindestens die Keppler-Generation (z.B. 600er-Serie). Dein Fermi-Chip ist genau die Generation davor. Möglicherweise hat es damit zu tun.

Möglicherweise. Nachdem die 560 ohnehin schon etwas in die Jahre gekommen ist, habe ich ohnehin beschlossen, sie baldigst durch eine 1060 6GB zu ersetzen. Mal sehen, was dann unter PowerDirector passiert.

Neue Info: Intel's QuickSync Dekoder ist in der Lage, die fehlerhafte P- und B-Frame-Reihung zu erkennen, zu korrigieren und eine flüssige Wiedergabe zu ermöglichen. Wer libav (z.B. über den Player "MPC-HC") als Codec verwendet, kann in dessen Konfigurations-App "LAV Video" Intel QuickSync als Hardware-Dekoder festlegen um das hier beschriebene Problem weitgehend zu umschiffen.