BUG: Long transcodes from DV to ProRes results in large chunks of skipped video
I'm seeing a tremendous number of problems on long transcodes with camera cuts in the dailies. I'm working on a doc feature including a lot of Hi8 and MiniDV tapes. The source tapes are captured in long chunks, often over an hour. Within this are camera cuts, crash recorded blank tape spots, etc - the usual amateur issues. The source clips are all perfect on import. However, most of the transcodes (to ProRes 1080 @23.98) have serious problems as follows:
- clips can be truncated, i.e. can be 30 mins or more shorter than source clip.
- clips have internal problems. The audio continues correctly, but 20 mins of video will disappear. The means from this point in the transcoded clip on, the clip is completely out of sync, and the picture is permanently missing. Resulting clip is shorter than source.
Most of these problems seem to occur on the above mentioned recording errors, but not always. Often in the middle of a continuously recorded conversation, 20 mins will have just disappeared.
The result is a nightmare as I have to go back and create new, shorter Quicktime sources from the master source clip, then transcode these until I can get a clip that works.
Antoine (Autokroma.com) commented
Weird.. What happens if you change the export codec ?
This is all in AME v 13.1 btw
The more I work on this, the more it's looking like the truncated transcodes are exactly half the duration of the source material. But I'm now seeing this on even short source clips that are 5mins long - resulting transcodes arc off after 2.30.
Clips longer than half an hour are definitely problematic. Cutting them in two or three results in much more successful transcodes.
I should further add that I'm seeing the same problems whether I use the Metal encoder acceleration or OpenCL. In some cases, but not all, the OpenCL encoder makes it successfully past points that the Metal encoder doesn't seem to want to, but in other cases, the break points of the truncated clips are at precisely the same point. However, I see no camera cut or errors at that point.