I use a vendor provided encoder.
When I link it with the acpy3 debug library instead of the release library, the following runtime error
happens :
Assertion failed : file=acpy3_configure.c line=44.
What is the meaning of this message ?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I use a vendor provided encoder.
When I link it with the acpy3 debug library instead of the release library, the following runtime error
happens :
Assertion failed : file=acpy3_configure.c line=44.
What is the meaning of this message ?
Who is the vendor?
I will try to find some answers for you, but FYI, codec issues such as this one should be handled by the ASP (Authorized Software Provider) that provided you this encode algorithm. We are very selective on which companies are selected as part of our ASP network and they can work with us to resolve any customer issues. However, they know their deliverables best, so they should be the first line of support, and they can always get us involved in need be.
Which version of Framework Components are you using?
Chris
I believe this is an extention of a prior post here? Assuming this is an extention than the FC version should be the FC that comes with DVSDK 1.10.00.14. We can combine the threads maybe, though there is little in the prior thread of value.
As to the problem at hand, an assertion means that something in the code believes it was violated (probably some value was too large or too small, or some allocation failed), so if you could find the file acpy3_configure.c (I took a quick look and could not find this in my older installs unfortunately) and look at line 44 that should give you an idea of what is actually failing. Chances are this is being caused by some incorrect versioning, such as if your codec was meant for another version of framework components, or it is trying to take on more resources than are available.
OK. DVSDK 1.10.00.14 used FC 1.20.03.
Line 44 of acpy3_configure.c from the sources of FC 1.20.03 is an assertion check that there is no transferPending for the given handle being configured.
That is, the IDMA3_Handle provided as the first arg to ACPY3_configure() incorrectly(!) has its .transferPending flag set to TRUE. I think the alg needs to ensure that all configured transfers have been waited on before configuring a new one.
Chris
Thanks, that is the kind of information I was looking for.
I will check tomoroww to see if it leads me toward a working codec, and go back to the vendor with this info if not.
The release version does not do this check ?
Glad this helped.
bandini said:The release version does not do this check ?
Nope. ACPY3 is optimized for performance, so these "are you using my APIs right?" checks are compiled out in release builds.
Chris