|
|
|
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.
|
|
|
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
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.
|
|
|
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.
|
|
|
I did not copy over the nvcuvenc.dll file(s) and still got "hardware encoder" in my PD12. OS is Windows 10, drivers are 375.95. It is an Optimus Laptop as well. NVIDIA Inspector shows VPU usage as seen in the attachment and it clearly rises, when the complexity of the timeline is low (i.e. CPU has less work to do). How can that be? Feels like magic. 
Note that NVIDIA Inspector also shows 0% Encoder Usage, but that might be related to that new technology mentioned in the first post.
EDIT: The last two posts already cleared it up. Keppler based cards like my GT 740M (GK208) work normally with latest drivers and Windows 10. Optimus was what gave me a headache for a while. Almost all PowerDirector versions are locked and the option to select the gfx card to run on is grayed out. Unfortunately it turned out if NVIDIA did not apply any Optimus special casing for PowerDirector it would work just fine for me.
The tool NVIDIA Profile Inspector can override the hard wired application profiles until reboot and make PD work on Optimus systems. From the "Profiles" I selected "Cyberlink Power Director". Then scroll down in the list to "Other". Change the following settings:
"Enable application for Optimus" from "SHIM_RENDERING_MODE_USER_EDITABLE" to "SHIM_RENDERING_MODE_ENABLE"
"Shim Rendering Mode Options per application for Optimus" from "(Arcsoft Media Impression, Roxio Video Converter, Cyberlink MediaShow Espresso, Cyberlink Power Director, Nero Move It, CyberLink MediaShow, Movavi Video Converter, CyberLink MediaStory, CyberLink MediaEspresso)" to "SHIM_RENDERING_OPTIONS_DISABLE_ASYNC_PRESENT"
Then click on "Apply changes" in the top right and start PowerDirector. It should be using the NVIDIA card now.
|
|
|
Quote
I can not be bothered getting into a slanging match with you or anyone else But I have been editing video for som 25yrs
and I know what I'm talking about
I'll come back to that.
Quote
as I said the harddrive is causing a bottle neck one harddrive on an edit system is just asking for trouble
And 20 years ago I would have trusted you on that, when everyone was using mechanical drives that had to accellerate and decelerate read/write heads as they worked on several files that were spread out over the disk area, which caused horrible random access performance. SSD solved that for good and with M.2 and the new NVM cards parallel access to several files is once more optimized.
Quote
now go watch some tutorials and come back when you learn something
True, I've never watched any of those. So let's look at the first three that Google spits out:
https://www.youtube.com/watch?v=D-xCVQ6HuQ8 - They edit higher resolution content (4K/1080p) and use one SSD that's connected via SATA together with a regular HDD (for the big files I assume). In case of PowerDirector we would be working with shadow files on the SSD.) They claim that the CPU is the most important part of any video editing computer, which supports what I said above. The graphics card can be anything in the mid-range. They also use 16 GiB of DDR4 RAM and consider it a "decent amount for 4K resolution". As for RAM upgrades they projected the following numbers...
Rendering 4K video with different amounts of RAM, with 16 GiB being the base:
32 GiB: +15% to +20%
64 GiB: +30%
They go on and claim that for video editing the difference of SSD vs. HDD isn't really that important. I see how that is likely true for the rendering tasks, but jumping in the timeline and actually working in the editor should be more snappy with an SSD.
https://www.youtube.com/watch?v=XxI-LvwtkHM - "Memory is also very important for video editing machines. Definitely if you're working with 4K footage. We're suggesting a minimum of 16 GB, but if you can please think about going to 32GB or even 64GB if you wich to stay away from the limits." - That again would suggest that for Jeremy's 720p 16 GiB is plenty.
"Some people will tell you it's the graphics card, but in reality you want to spend most of your budget on the CPU. Having multiple cores will increase your rendering power as well. The graphics card is less important […]" - Between the lines you may read that multi-core CPUs will improve rendering, but for the editing itself it depends on the quality of the software if it can make good use of many cores. Otherwise a high clock speed is more important.
"[…] for storing your video files, even a normal hard drive would be enough." - Again the same claim as above.
https://www.youtube.com/watch?v=xaNZRz0E8XY&list=PL0EHp46PT0fGKdc4kjIOAXYMwvH1sKgR5 - Uses 32 GiB of RAM and two SSDs. The build is "centered around" the 8 core AMD CPU. One SSD is used as the C: drive, the other larger one as the scratch drive. The introduction assumed some prior knowledge on photo/video editing PCs, so did not explain why the components were chosen. It also wasn't clear what kind of video his client would work with.
The bottom line is, none of the tutorials supported the idea that multiple SSDs are necessary for video editing for performance reasons. The CPU was always considered the weak link or most important part by far.
Quote
I answered the post to try and help I'm not wanting a slanging match with someone whom thinks one harddrive is sufficent
And I would have answered the question the exact opposite way: Forget about extra RAM and disks, focus on the CPU frequency. If you really want to help poeple, be open to new information even if it contradicts your experience. We all are prone to confirmation bias. In other words, if the experience is 20 years old, maybe it is time to start from a clean slate.
Quote
simply you don't have a clue with statements like that
end of story
have a nice day
Tom G
I wish you a nice day, too. Sorry for the wall of text.
|
|
|
Quote
PD 15 is not useless but it may be your computer that has the problem
and Carl 312 was pointing you in the right direction so listen to the advice??
one harddrive just won't cut it with video editing and your 16GB memory is borderline
get an othe ssd drive at least 500Gig for the scratch disk and update your memory
nothing wrong with the speed of PD so sort out your computer its not as fast as you think
its to slow for PD 15 and your harddrive is causing a bottleneck trying to read and write back and forth on the same drive as your
operating system JUST WON'T WORK thats the main problem.
I would also suggest you look at some up to date tutorials on how to setup a video edit system
have a nice day Tom G
Tom G
I hope you are not offended when I say that I get the impression that you try to justify having spent so much money on the latest hardware. If the question was, whether jeremy's rig is adequate for editing the given source material (720p), I would say "Yes, by a large margin". An expensive large SSD or more RAM is not going to make the user interface more responsive under that workload, simply because that material has been edited swiftly with shadow files (aka proxies) on far weaker systems back in the days. Other consumer oriented video editing software (there are two or three comparable to PD) could also be tested with a similar workload to see if editing must be that slow or if they use an obvious trick to be faster.
The only hardware items that should have an effect on editing speed are the CPU frequency & generation and RAM speed. (GPU effects aside.) The CPU frequency is awesome and the RAM - I presume - is fast, too. Any hardware bottlenecks are ruled out in my opinion. That leaves us with the software side. Do you have any codec packs installed? I could imagine in theory, that if an external codec was used, that is slow to use for still frame extrction the way it happens when editing in PD, it could slow down the whole application. Are the shadow files ready and the preview quality set to "normal" or lower, so they get used? Did you try disabling the "continuous thumbnails for easy scene recognition"? You'll only see the first video frame for each clip, but it is faster. The same goes for "audio waveforms". Most importantly though: How big is your project? In PD 12 I once had a 4 hour long 1920x1080@50p project with lots of clips and well over a thousand animated still images, that would become slow to edit on the now six year old office notebook I was using back then. Also the occasional longer pauses in the interface were caused by the autosave feature, which would work for a minute or so without a visual feedback.
Don't worry about the free disk space on that SSD unless PD stops writing shadow files. (It tries to keep a certain percentage of disk space free). Performance-wise, a good small M.2 SSD beats an SATA SSD hands down by a factor of 3 to 5, because SATA is limited to ~650 MB/s. More RAM will not give you as much of an advantage since your SSD is already "only" about 10x slower than RAM, while with a mechanical HDD the factor is 1000x and more. Figure this: In the time PD hangs - let's assume 1 second - your SSD can sequentially read more than half an hour of 720p material (assuming an overall bitrate of 10,5 Mbit/s and a Samsung SSD 950 Pro M.2).
|
|
|
|
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.
|
|
|
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.
|
|
|
|
Obwohl, warte noch mal damit. Ich glaube es gibt eine andere Ursache.
|
|
|
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.
|
|
|
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?
|
|
|
Das kann ich verstehen. Ich hatte mein erstes PD 12 Projekt vorwiegend mit 5 Sekunden langen mit MagicMotion animierten Dias und übergängen gefüllt plus einiger kürzerer und längegerer Video Clips, bis es auf etwa 4 Stunden Spielzeit angewachsen war, um dann nach und nach eher langweilige Passagen herauszuschneiden oder zu kürzen. Dabei fiel mir auch auf, dass das Speichern und praktisch jede Interaktion mit Elementen der Zeitleiste mit langen Verzögerungen einher ging, ob sie nun viele der Videoelemente beeinflusste oder nicht. Auch das Laden und Speichern dauerte gefühlte 10 Minuten und beim Auto-Speichern konnte ich mir einen Kaffee kochen. Das konnte ich aber nicht deaktivieren auf Grund sporadischer Abstürze, wobei diese durchaus auch von Fehlern in Codecs, Plugins und Grafiktreibern außerhalb des Einflussbereichs von CyberLink stammen können. Dazu gesellten sich dann noch ein paar andere Bugs in PD.
Mir geht es jetzt ähnlich wie dir. Gerade MagicMotion - wenn auch nicht perfekt - ist eine schnelle Möglichkeit ein Panoramafoto wie einen Filmschwenk inklusive Zoom aussehen zu lassen. Ich sehe zwar auch die neuen Funktionen, aber vor einem Upgrade stelle ich die Frage, ob denn die bekannten Probleme in PD 12 die mich so frustriert haben jetzt behoben sind. Corel Video Studio hatte ich von Anfang an nicht erwogen, weil ich Filmmaterial mit unterschiedlicher Bildrate (50p, 25p, 23,97p) aus einem Urlaub vorliegen hatte und Corels Programm erhebliches Stottern im gerenderten Video aufwies. Man muss bei jedem Programm mit unerwarteten Problemen rechnen, die bei der Konkurenz nicht auftreten.
|
|
|
|
Today I found that my PD12 doesn't open .ogg any more after uninstalling some "cruft" on my system. I found the more or less official DirectShow filter from xiph.org to work in Windows Media Player but not in PD. Wikipedia mentioned another project named RadLight Ogg Media that has been discontinued from 2005 on but can still be downloaded from free-codecs.com and works great with PowerDirector (32-bit at least)!
|
|
|
Guys, the irony is that since H.264 it is purely optional to use a certain frame rate. The display time stamps (which were present in older codecs as well, but with a fixed delta) dictate how long a frame shows on the display device. That means you can mix and match any FPS without conversion and jumpy playback.
Now in practice the Blu-Ray still demands constant frame rates and video editors are also slow to adapt. It is likely that the upper price segment already offers solutions there, but not PD12.
I think there is still a working solution if you are fine with playing the video from a laptop connected to the TV instead of a Blu-Ray player...
Render each section that contains clips in a different frame rate separately. This way you can chose or create a matching profile for 25/30/60 FPS and possibly even utilize SVRT on each as a bonus. These parts can then be concatenated (lossless) with a variety of command-line and GUI tools, many of which are free (ffmpeg, AviDemux, VirtualDub, ...).
For fixed frame rates though, you can just stick with what PD offers. It was working a lot better for me (23.97 FPS material in 50 FPS timeline) than the demo version of VideoStudio, which targets a similar price segment.
(Hint: Since I haven't tried this, I don't know how PD handles any overhang resulting from selections on the timeline being 25 FPS and then rendering them in 30/60 FPS. So better make sure the 30/60 FPS segments' durations can be expressed in 30/60 FPS without rounding. That's easy if you measure them in whole seconds. In cases where that's not possible, select a multiple of 5 frames (resulting in 6 or 12 frames for 30 and 60 FPS respectively). You can verify the duration below the preview on the production tab: If it ends in a 5 or a 0 you are good to go!)
|
|
|
|
Hallo Michael. Wenn du Symptom sagst, meinst du wahrscheinlich die Sache mit der DVD? Den Thread findest du hier: DVD u. intelligente Einpassung
|
|
|
Also gleich zwei Probleme:
1. PowerDirector hätte zunächst Prüfen sollen, wie viel % des Videos per SVRT direkt 1:1 kopiert werden können. Dabei wäre dann herausgekommen, dass das komplette Video bereits DVD-konform ist und von der Bitrate her auf die DVD passt.
2. Die errechnete Bitrate liegt mit 4718 Kbit/s ein gutes Stück weit zu hoch.
Punkt 1) finde ich in diesem speziellen Fall eigentlich am wichtigsten. Wenn die Quelle bereits eine niedrigere Bitrate hat, als PowerDirectors Vorgabe, dann gibt jedes bisschen Smart Rendering Platz auf der DVD frei für den Rest und die Bitrate kann angehoben werden.
Statt dessen scheint PD nur auf die Laufzeit zu gucken und die mit der Standard-Bitrate für DVDs zu multiplizieren, was natürlich zu einer zu großen Datei führt und die Intelligente Anpassung muss einspringen.
Die MPEG2 Datei die du da hast ist bereits 100% DVD-konform, oder? Also maximal 15 Frames pro GOP etc. Zumindest MAGIX scheint das ja anzunehmen.
Zu Punkt 2) hatte ich erst überlegt, ob sie die Tonspur bei der Bitratenberechnung vergessen haben. Aber bei 192 Kbit/s würde sie trotzdem nur 230 MiB draufschlagen und deine DVD ist ja locker 800 MiB zu groß. Und 670 Kbit/s hat die Tonspur ja sicher nicht.
|
|
|
Dein Post von http://forum.cyberlink.com/forum/posts/list/10482.page#46606:
Quote:
[...] Antwort vom Supprt: man könne die schlechte Qualität sehr wohl nachvollziehen. Ich solle doch mal testhalber meinen Virenschutz und alle im Hintergrund laufenden Aktivitäten abschalten!!!! [...]
![]() Das haben sie mir auch mal empfohlen.
Die intelligente Anpassung habe ich noch nicht verwendet. Hast du herausgefunden, was die Ursache ist? Hat die Intelligente Anpassung die Datenrate zu weit reduziert? Also war die DVD am Ende nur halb voll? Produziert man da interlaced oder progressiv? Ich habe beim H.264 Encoder bemerkt, dass wenn ich die Bitrate höher setze als gewöhnlich und interlaced kodiere, das Produkt ein einziger Haufen Blöcke und Pixelfehler wird. Das ist also nicht das übliche Resultat von zu wenig Bitrate sondern ein Bug im Encoder. Und da müsste man schon Profi im schreiben von Videocodecs sein UND den richtigen Quellcode haben, um den Fehler zu finden.
Immerhin hast du ja einen Ausweg über MAGIX zum Brennen gefunden. Das ist ja zumindest eine praktikable Lösung. Wenn du beim Rendern keine Qualität verlieren willst, könntest du noch ein eigenes MPEG2 Profil anlegen und in der Datei %APPDATA%\CyberLink\PowerDirector\12.0\Profile.ini mit der Bitrate und der GOP Sequenz spielen.
|
|
|
Danke, ich bin selbst Programmierer. Was du sagst, ist zwar im Allgemeinen richtig, trifft aber auf die 3 Fehlenden Funktionen nicht zu. Dateien von >4GiB zu rendern ist z.B. kein Problem für PowerDirector. Deshalb tendiere ich eher zur These mit den bösen Onkelz vom Marketing. ![]()
Der Support versteht mich weiterhin beharrlich falsch. Aus "ich würde gerne mit jemandem sprechen, der Einblick in den Quellcode hat" wird "ich würde gerne Einblick in den Quellcode haben" und die Antwort, das das nicht ginge folgt natürlich prompt. Im Ernst: Hätten sie von Anfang an richtig gelesen, hätten sich die 3 Support-Mitarbeiter und ich viel Zeit erspart. Eine Farce ist das...
Wie dem auch sei, ich habe PowerDirector jetzt entgegen der Nutzungslizenz Disassembliert (zu Deutsch: mir die einzelnen Programminstruktionen vergegenwärtigt) und drei Instruktionen stillgelegt, die für die Reduktion der Photoauflösung verantwortlich sind. Und oh Wunder, es läuft und mein 32-bit System bricht nicht plötzlich zusammen. ![]() Ich habe jetzt eine bessere Bildqualität als selbst 64-bit User zu träumen wagen. Aber warum muss ich erst zu solch illegalen Methoden greifen? Eventuell gebe ich in einem neuen Thread noch genaue Instruktionen und Tipps, welche Bytes man dafür patchen muss und wie man die optimale Fotoqualität in PD 12 zu erreicht. (Stichwort: beim Zuschnitt auf gerade Auflösungen achten.) Netter Nebeneffekt: Meine ebenfalls über Registry Tricksereien aktivierte Full HD Preview zeigt nun auch bei starkem Zoom die volle Fotoauflösung an, was bei starkem Zoom mit MagicMotion hilft zu wissen, wo man stoppen muss. Soweit ich mich erinnere streikt da selbst die 64-bit Version.
|
|
|
Da hast du absolut Recht, das ist etwas für die Entwicklungsabteilung, doch der 1st Level Support weicht geflissentlich meiner Frage aus. Plötzlich ist es viel interessanter, dass ich über die Registry in der 32-bit Version die HD Vorschau ans Laufen bekommen habe: "setting any value in the registry is not considered as normal use of our programs". Oder man verfällt in Marketing-Phrasen darüber was TrueVelocity 64-bit kann. Fast könnte man meinen die wollen mich nicht verstehen. ![]()
Offiziell verheimlicht man unter "Systemanforderungen" komplett (seht selbst) evtl. Einschränkungen der 32-bit Version und der Support verweist auf die FAQ, die man scheinbar vor dem Kauf auf potentiell relevante Inhalte durchsuchen muss. (Im Ernst?!) Dort steht dann plötzlich 4k Video und HD Vorschau seinen Extrafunktionen der 64-bit Version. Die sind aber sonst überall als Standardumfang gelistet. Das mit den Fotos sieht man nicht mal in der FAQ erwähnt. Alles in allem ziemlich Grauzone, was das Marketing angeht.
Erwarte ich von einer günstigen Schitt-Software zu viel? Nö, eigentlich gar nichts. Ich will nur die Funktionen nutzen die allen anderen auch zur Verfügung stehen. Bloß weil mein Windows 32-bit ist muss ich für die HD Vorschau auf Registry-Änderungen zurückgreifen und bekomme dann noch zu hören, dass sei keine normale Nutzung der Software. Ganz normal in Fotos hineinzoomen zu können ist auch kein High-End-Feature, dass ihr alle nutzen könnt. Wogegen ich mich sträube ist die sinnfreie Beschränkung der 32-bit Version. 32-bit bedeutet nur, dass ich irgendwo mit dem Speicher begrenzt bin, was freilich davon abhängt wie viel ich lade, also wie umfangreich mein Projekt ist. Ein einzelnes Foto in 50MP sorgt während des Renderns lediglich für Spitzen. Es nur in 2MP zu verarbeiten vermeidet die Spitze, kann aber nicht verhindern, dass das Programm nach längerer Benutzung mit umfangreichen Projekten mangels Arbeitsspeichers abstürzt.
Ich hätte vor einiger Zeit auch so einen Thread aufmachen können weil Additives Blending (sowas wie doppelte Belichtung) in PD fehlt, habe ich aber nicht, weil es nun mal nicht zum Funktionsumfang von PowerDirector 12 gehört, anders als Diashows.
Zum Testen/Zurückgeben: Zu Anfang wusste ich noch nicht, dass ich auch Dias ins Video einfügen würde. Das kam dann so nach und nach als mir von einigen Orten Videos fehlten, und man kann sich vorstellen, dass man so etwas grundlegendes wie Fotos nicht extra testet. Selbst wenn man mit einem Größenlimit gerechnet hätte, dann doch wohl irgendwo über gängigen Kameraauflösungen. Tatsächlich habe ich getestet: Mit einer 64-bit Demoversion im Wohnort meiner Eltern auf dem Laptop meines Vaters mit Videoclips von 3 verschiedenen Kameras. Urteil: PowerDirector schlägt VideoStudio beim Mix unterschiedlicher Bildraten!
|
|
|
