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.
This message was edited 1 time. Last update was at Apr 03. 2019 16:46
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°