can you give specific examples of the issues you want fixed?
I didn't collect them specifically, but I've come across a lot of AVC/MP4 being handled ridiculously by "so4compundplug.dll", like no audio track, no video track, one piece of audio missing, one piece of video missing, noisy audio, video Garbled characters appear... Once switched to "compundplug.dll" they went back to normal.
It's not just me, I've seen many people have similar issues.
So I beg please keep the old goodness in the process of development.
Which version of VEGAS are you using? As so4 has been upgraded numerous times over the various updates. It is far more stable now, and I rarely find myself having to switch away from it these days.
For general camera records, many are working acceptable, and I feel it is getting better by the time it is being developed. Example on what I felt is DJI Osmo Pocket MP4 - previously it is troublesome reading this, but now more stable.
For these cases you are mentioned - it's better to know the original of those AVC MP4 media, how they are encoded / made (if it is screen record), if camera device, best to know the model type of it. Above of these, sample record uploaded to online drive (such as google drive) and shared here is extremely helpful for further analyze by the development team.
uploaded to online drive (such as google drive) and shared here is extremely helpful for further analyze by the development team.
Such a development process is too slow. I hope you can "copy" the source code of "compundplug.dll" and integrate them into "so4compundplug.dll", so that all the advantages can be preserved.
Such a development process is too slow. I hope you can "copy" the source code of "compundplug.dll" and integrate them into "so4compundplug.dll", so that all the advantages can be preserved.
In 8-bit AVC decoding, "so4compundplug.dll" is far much worse than "compundplug.dll".
In a Development area of the forum, some validation of your impressions would be especially welcome. Are you aware that each decoder addresses a different subset of encoders? What's the need to combine two libraries with different engines?
It "could" be, that the hardware encoders load more virtual memory than their legacy software counterparts. Which puts us into the sketchy world of GPU acceleration.
VP16 is the second year of this decoder. While it worked okay with some types of AVC I had many issues with GPU decoding in 15 and 16. Each version has gotten faster and more reliable so do the trial of 20 and see for yourself.