This is wonderful to have so quickly, and after some initial testing I see that the updated Demuxer has completely solved one part of the missing access problem. This Hotfix helped me see that there are really 4 separate issues going on, and they interact with each other, which made it hard to see the full picture.

1) Individual inaccessible frames. These frames are scattered throughout the test clips but are repeatably inaccessible. From an editing standpoint, this isn't a huge deal, but a large number of frames from almost all test clips were affected.

The Hotfix completely clears up accessing all of these frames in 4 of the most affected test files (see this comparison spreadsheet), and I expect that all of the previously individually inaccessible frames across all of the test clips will now be accessible. Well done, and thank you Cyberlink!

2) Out-of-order frames. I now see that this is a separate issue, and it only seems to happen in clips produced by PD17 using nVidia hardware encoding with driver version 411.70. The Hotfix does not solve this problem, but it changes where the out-of-order frames occur. In the original test using the PD17 GTX (411) clip, frames 4:00 and 4:02 each showed "3:54." Applying the Hotfix has moved the affected frames to 4:01 and 4:03, which were originally correct, but now show "3.54."

These out-of-order frames are a bigger issue. For example, if you accidentally use an out-of-order frame as a freeze frame to pause, there will be a noticeable jump in the produced video both before and after the pause. This is what lead me to dig deeper and try to understand what was going on.

3) Displaced frames. These are entire blocks of frames that are offset by 1 frame from their true positions. These occur at the end of the 4th second in almost every test clip that was produced by PD17. To me, their presence is a minor inconvenince because only a single frame is duplicated at the start of the block, and all other frames are actually accessible.

The Hotfix makes only the tiniest difference here by giving accces to one additional frame (4:58) in the block of displaced frames in PD14 QuickSync test clip, and that is probably from the fix that restored access to indivdual frames. As it currently stands, the root cause of the 1-frame displacement block is still completely unresolved.

4) Blocks of inaccessible frames. This is the biggest editing headache, since only the starting frame is displayed when previewing every frame in the affected block. This issue only appears in clips produced using nVidia hardware encoding, and it occurs in clips produce by both PD14 and PD17.

To my disappointment, the Hotfix shows absolutely no change in PD17's ability to access any of the frames in these blocks. This is a still a major issue.

So, the Hotfix is worth installing as it does clear up 1 of the 4 frame access issues, but it's a long way from being a true "fix" for the remaining issues.

I will do some more testing and create a revised spreadsheet highlighting the 4 distinct problems as soon as I have time. I very much appreciate the effort that Cyberlink has put into resolving this issue, and I hope that a more complete solution can be released soon.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Renamed the extension of the old one and installed the new .ax file. Result is not good as both timeline and media library delivered exactly the same result and it is the same as on my previous test posted earlier on the timeline only for PD17 h.264 m2ts test clip GTX411.m2ts.

Fc 14-25 c13, fc 40-51 c39, fc 53-1:04 c52, where fc = frame counter, and c = count displayed as discrepancies.

Used vlc and it has a limit of about 25 frames per session. It showed that every next frame is displayed with each keypress.

Quote Renamed the extension of the old one and installed the new .ax file. Result is not good as both timeline and media library delivered exactly the same result and it is the same as on my previous test posted earlier on the timeline only for PD17 h.264 m2ts test clip GTX411.m2ts.

Fc 14-25 c13, fc 40-51 c39, fc 53-1:04 c52, where fc = frame counter, and c = count displayed as discrepancies.

There's no change in the blocks of blocked frames in any of the test clips, but what about the individual missing frames that you noted in your test post: Fc 29 f27; Fc 31 f32; Fc 34 f35; and Fc 37 f38?

You don't mention them as missing here, but they were not accessible with the earlier version of the demuxer file and they are accessible on my system with the new version.

Can you also try the PD14 version of the GTX411 clip? I can now see all of the individual frames outside of the block from fc 40-51. 10 new frames are now accessible for a total of 48 in the 1st second of that clip when I test it.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote There's no change in the blocks of blocked frames in any of the test clips, but what about the individual missing frames that you noted in your test post: Fc 29 f27; Fc 31 f32; Fc 34 f35; and Fc 37 f38?

You don't mention them as missing here, but they were not accessible with the earlier version of the demuxer file and they are accessible on my system with the new version.

I did not list them as disreprencies because the frame counter at 29,31,32,37 displayed the correct count. Fc 1:06-1:17 c1:06 is a disreprency found now as unable to test the last time on March 22 when the snapshot capture screen popped up. It did not pop up this time so there are small improvements for timeline checking. The result is the same from the media library.

I did not check the same file from the media library the last time on March 22 as it was only suggested days later by Jeff.

Quote This is wonderful to have so quickly, and after some initial testing I see that the updated Demuxer has completely solved one part of the missing access problem. This Hotfix helped me see that there are really 4 separate issues going on, and they interact with each other, which made it hard to see the full picture.

1) Individual inaccessible frames. These frames are scattered throughout the test clips but are repeatably inaccessible. From an editing standpoint, this isn't a huge deal, but a large number of frames from almost all test clips were affected.

The Hotfix completely clears up accessing all of these frames in 4 of the most affected test files (see this comparison spreadsheet), and I expect that all of the previously individually inaccessible frames across all of the test clips will now be accessible. Well done, and thank you Cyberlink!

2) Out-of-order frames. I now see that this is a separate issue, and it only seems to happen in clips produced by PD17 using nVidia hardware encoding with driver version 411.70. The Hotfix does not solve this problem, but it changes where the out-of-order frames occur. In the original test using the PD17 GTX (411) clip, frames 4:00 and 4:02 each showed "3:54." Applying the Hotfix has moved the affected frames to 4:01 and 4:03, which were originally correct, but now show "3.54."

These out-of-order frames are a bigger issue. For example, if you accidentally use an out-of-order frame as a freeze frame to pause, there will be a noticeable jump in the produced video both before and after the pause. This is what lead me to dig deeper and try to understand what was going on.

3) Displaced frames. These are entire blocks of frames that are offset by 1 frame from their true positions. These occur at the end of the 4th second in almost every test clip that was produced by PD17. To me, their presence is a minor inconvenince because only a single frame is duplicated at the start of the block, and all other frames are actually accessible.

The Hotfix makes only the tiniest difference here by giving accces to one additional frame (4:58) in the block of displaced frames in PD14 QuickSync test clip, and that is probably from the fix that restored access to indivdual frames. As it currently stands, the root cause of the 1-frame displacement block is still completely unresolved.

4) Blocks of inaccessible frames. This is the biggest editing headache, since only the starting frame is displayed when previewing every frame in the affected block. This issue only appears in clips produced using nVidia hardware encoding, and it occurs in clips produce by both PD14 and PD17.

To my disappointment, the Hotfix shows absolutely no change in PD17's ability to access any of the frames in these blocks. This is a still a major issue.

So, the Hotfix is worth installing as it does clear up 1 of the 4 frame access issues, but it's a long way from being a true "fix" for the remaining issues.

I will do some more testing and create a revised spreadsheet highlighting the 4 distinct problems as soon as I have time. I very much appreciate the effort that Cyberlink has put into resolving this issue, and I hope that a more complete solution can be released soon.

Optodata,
Thanks for the testing and feedback. We will pass it on. Just please note that it is a 4 day long weekend in Taiwan this weekend, so RD won't look at it until next week.
Cheers
PowerDirector Moderator

For customer support related issues, please contact:
- Customer service: https://membership.cyberlink.com/support/customer-services.do
- Technical support: https://membership.cyberlink.com/support/service/technical-support.do

I actually think all the issues are totally related. Knowing how to alleviate the issue, which I demonstrated with a clip that I had temporarily posted in the other thread, leads me to believe all the issues related. In fact, this issue has been present since at least PD9 when several of us demonstrated then, just failed to get a resolved version. Greatly improved at the end of life of PD9, only to resurface bad in initial PD10. Since then I've seen the issue go from tolerable, to very poor, to tolerable, release to release and even patch to patch. Yes, different encoders affect differently but hard to blame Nvidia when NVENC does not have the issue in other free and purchased products that I've experienced.

1 out of 4 resolved, very poor issue isolation I'd say, I think I'll put my bet on getting a winning lottery ticket prior to this issue being fully resolved for a few releases.

Anyhow, glad to see PDM get the issue in front of RD yet again.

Jeff

I've done an exhaustive analysis of every single frame in 5 key test clips, and compared the results from before and after the Hotfix was applied. I also color coded the 4 separate frame access problems to expand on the amount of data the table contains.

The spreadsheet is here, and a somewhat surprising takeaway is that the clips encoded using Intel QuickSync in PD14 and PD17 are now 99% usable.

Prior to the Hotfix, the PD17 QS clips had 54 frames that could not be accessed (18% of the total). and they were scattered across all 5 seconds. Now, only the 2 final frames (4:58 and 4:59) are inaccessible, and a single frame @ 4:42 is duplicated. From an editing perspective, these are very minor issues and I don't imagine I'd have any problems working with H.264 M2TS QS clips now.

When everyone gets back from their long weekend, I hope they will put my hours of effort to good use and work on clearing up the large blocks of inaccessable frames next.

There's also a quick and easy way to tell when the problems are gone without painstakingly stepping through all 300 frames: If you randomly place the scrubber over and over on a clip with all frames accessible, the preview screen will always have an image. If PD cannot access large contiguous blocks in a specific clip, it will sometimes have a blank preview.

If the frame access code is still causing displaced blocks or out-of-order frames, the preview screen will sometimes not match the clip/timeline frame counter. If both of those issues are resolved, the preview image from every random frame will always match the counter, no matter where you place the scrubber.

I just tried this quick test on one of the PD17 CPU-produced clips, and it shows perfect results except for the block of displaced frames at the very end, so this Hotfix allows normal editing with both QuickSync CPU-produced H.264 M2TS clips.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

For anyone who wants to install this hotpatch, I've attached a zip archive with two batch files that will install and remove the CLEdtDemuxer file automatically.

All you need to do is download the zip file and extract the contents to the same folder where you extracted the CLEdtDemuxer.ax file from Cyberlink's zip file. To run the installer or uninstaller, right click on it and choose Run as administrator. Please make sure that PD is not running.

Each batch file checks for the presence of the renamed CLEdtDemuxer-old.ax file before proceeding, and neither one will do anything if the expected situation isn't present. For example, you can't uninstall the hotfix if it hasn't yet been applied

It's always a good idea to use a text editor like Notepad to inspect every batch file you download from the internet file in Notepad to confirm that there isn't anything nefarious going on, so please do that with these before using them for your own peace of mind.

Note that if you have installed PD17 to anywhere but the default location, you'll need to edit the folder location in each batch file for them to work.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°