Well I've done some more testing, and the Handbrake clip crashes PD each time I click on Produce just like you're seeing

The only main diffeence I can see between the two clips is the encoder profile, which is Main 10@L5.1@High on the source MOV and the Handbrake clip, but it's Main 10@L4@Main on the VD2 clip. I changed Handbrake's settings to use Main 10@L4 with the max bitrate, but it didn't help.

The other difference is that Handbrake is using the isom codec while VD2 uses mp42.

In the meantime, I've uploaded the MOV-to-MP4.vproject file to the OneDrive folder. Simply import it into VD2 (File | Load Project) and then use Save Video... (F7) and tell it where to send the converted clip.

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°

I now have good news on the Handbrake front!

I changed to the QuickSync 10-bit HEVC codec, and not only does it convert very quickly but PD seems to work as well with it as it does with the VD2 clip. Interestingly, it also uses the mp42 codec rather than the isom, so maybe that's a clue to what's happening in PD.

Try loading the MOV-to-QS-MP4.json preset from the OneDrive folder into Handbrake and see if PD will accept that clip.

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°

I'm not sure what's up with Handbrake and/or PD, the version, 1.3.3 appears to have issue with H.265 and PD being able to read correctly. I use Handbrake 1.2.2 and it has no issue like that. My H.265 files work fine in PD. I downloaded 1.3.3 and see similar issues as was noted about PD compatibility.

Jeff

1.2.2, https://handbrake.fr/rotation.php?file=HandBrake-1.2.2-x86_64-Win_GUI.exe&old=true

Thanks for that discovery. V1.2.2 uses the mp42 codec with my MOV-to-MP4.json settings where 1.3.3 used isom; but PD still crashes when trying to open the Produce page.

Event details (ID 1000) show that the issue is always caused by the ntdll.dll library:

Faulting application name: PDR.exe, version: 18.6.3120.0, time stamp: 0x5f159c9a
Faulting module name: ntdll.dll, version: 10.0.19041.207, time stamp: 0xcad89ab4
Exception code: 0xc0000374
Fault offset: 0x00000000000fdec9
Faulting process id: 0x5324
Faulting application start time: 0x01d6687d84da5894
Faulting application path: C:\Program Files\CyberLink\PowerDirector18\PDR.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: c1032120-c82c-4727-8f47-1e675b42ed35
Faulting package full name:
Faulting package-relative application ID:

Quote Thanks for that discovery. V1.2.2 uses the mp42 codec with my MOV-to-MP4.json settings where 1.3.3 used isom; but PD still crashes when trying to open the Produce page.

Event details (ID 1000) show that the issue is always caused by the ntdll.dll library:

Faulting application name: PDR.exe, version: 18.6.3120.0, time stamp: 0x5f159c9a
Faulting module name: ntdll.dll, version: 10.0.19041.207, time stamp: 0xcad89ab4
Exception code: 0xc0000374
Fault offset: 0x00000000000fdec9
Faulting process id: 0x5324
Faulting application start time: 0x01d6687d84da5894
Faulting application path: C:\Program Files\CyberLink\PowerDirector18\PDR.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: c1032120-c82c-4727-8f47-1e675b42ed35
Faulting package full name:
Faulting package-relative application ID:

Mine appears ok, no crashes and produces just fine in PD18 as screen capture of produce in action and file specifics pasted for details.

Jeff

Weird. Can you share that clip in case it's something in the Handbrake settings I used? My clip is in the OneDrive folder if you want to test it on your system.

Quote Weird. Can you share that clip in case it's something in the Handbrake settings I used? My clip is in the OneDrive folder if you want to test it on your system.

Must be the CA weather, your file simply appears to be encoded with HB 1.3.3, not 1.2.2 as suggested, even though your file title implies 1.2.2, pic attached. You can also see your writing library is much newer too for the new HB.

I do see a few recent issues with H.265 and PowerDVD playback of H.265 from HB 1.3 so that may be part of the issue as I posted prior.

Jeff

Wow, another anomaly in this thread but I don't think this one is weather-related.

I installed 1.2.2 and was prompted to uninstall 1.3.3 first, which I OKed and let the installer proceed. However, things apparently did not go smoothly as WIndows shows that the installed version is 1.2.2 but Handbrake says it's 1.3.3:



The writing library is clearly 1.3.3 but the codec used is mp42 rather than isom, which is what the true 1.3.3 uses. Maybe this mismatch can help CL track down the issue.

I just used Revo Uninstaller to remove all traces of Handbrake and have installed 1.2.2 and converted and uploaded Dscf0100 HB-1-2-2 recode #2.mp4. It shows the correct writing library this time!

I can also access the Produce screen with the new clip so it does seem like 1.2.2 is the best version to use for this conversion.

Brilliant, and I really do admire your perseverance.
Just downloaded the latest clip and:
(1) with video enoder checked, just an audio tape.....however
(2) with video encoder unchecked, this does everything perfectly. Great result.

I have no way of knowing down this end if this is a 10 file.
Can you confirm for me that it is a 10 bit file (I'm sure it is)

where did you download handbrake 1.2.2 from?

and finally, what settings are you using

Thanks

Quote Brilliant, and I really do admire your perseverance.
Just downloaded the latest clip and:
(1) with video enoder checked, just an audio tape.....however
(2) with video encoder unchecked, this does everything perfectly. Great result.

I have no way of knowing down this end if this is a 10 file.
Can you confirm for me that it is a 10 bit file (I'm sure it is)

where did you download handbrake 1.2.2 from?

and finally, what settings are you using

Thanks

I posted the link to HandBrake 1.2.2 a few threads back.

Yes, the file is now reasonable, 25fps, 10bit, reasonable quality. You can use MediaInfo to get specifics of a video file.

The pic with settings for HandBrake I posted a few threads back will work fine.

Jeff

Thanks for that, should have read more carefully.

downloaded and installed handbrake 1.2.2
used revo uninstaller to remove the old one

just run that 8 sec clip through and it looks good
here are my settings in handbrake:

Summary: ensure mp4;
Dimensions: left as 1920x1080
Video: codec: h265 10 bit (x265); framerate - 25; quality slider all the way to the right
Subtitles: pressed 'clear'
Chapters: unchecked box

Late over here now (UK), so I may have made some obvious mistakes, let me know if you spot anything please.

I'll have another check tomorrow sometime.

Thanks for all your help, invaluable.
I'd have given up days ago.

Quote

That means preventing PD from using the hardware encoder in your nVidia card. Uncheck the Fast video rendering technology box at the bottom of the Produce page. It will take longer to produce than with the hardware encoder, but in this case you may get a usable output

Probably NVENC has isssues with that format. Especially since is using the ancient 25Hz rate. WHO has a TV that doesn't use a native 60Hz panel today? Or a phone that is not having a screen with at least 60Hz (to watch YT)?

CL has confirmed the issue with this specific clip and has forwarded it on to engineering. Hopefully that will result in a patch for both PD365 and PD18 at some point, but using Handbrake 1.2.2 is probably the best workflow until then.

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°

Yes, thanks for all your efforts, yourself and CL, without which I certainly would not have found a solution.
I've completely integrated your suggestions into my workflow.

This issue is still present in the latest PD365 19.1.2321.0 update, so the Handbrake workaround is still the preferred way to work with these clips.