axiscommunications / acap-native-sdk Goto Github PK

Hey,

I'm wondering why you remove OpenSSL from the docker file ? Is it not possible to keep it so we can use it ?

Thanks a lot for your answer !

Best Regards,

The AxParameter example is missing. Are ACAP 3 examples compatible with acap-native-sdk?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hi support team,

I'm trying to build a small application (see test_vdostream.zip) with SDK 4.2 for artpec-8. This application calls some functions from the vdostream library. The procedure how I try to build the application is described in the document 'Building an ACAP application with SDK 4_2'. As you can see there is a linking problem with glib-2.0 (version 2.66.7) and glibc 2.33. Do you have any idea what is causing this error? I also noted the container environment settings in the document. Maybe this can help.

I have the same issue with SDK 3.5. However, building the application with SDK 3.1 on a non-containerized Linux platform (glib-2.0 version 2.60.7 and glibc 2.30) works fine and runs on an artpec-8 camera.

Thanks in advance
Bart Dewancker
Araani

test_vdostream.zip

Building ACAP application with SDK 4_2.docx

Dockerfile.docx

Describe the feature

This feature(OpticsSDK) would give low-level access to controlling/listening to PTZ(Pan, Tilt, Zoom) and Focus of Cameras. We actively use 4 Axis Q6215-LE to look at objects in the sky and the embedded contrast-based autofocus doesn't do a very good job at focusing on such objects due to low contrast/noise. Thus, we would like to implement our own enhanced auto-focus plugin using the Native SDK. We have attempted to do this but the Native SDK doesn't expose mechanisms to change the focus or listen to the focus. Thus, we opted to use the VAPIX API to do an HTTP call to set the focus and poll the focus. However, we found that setting the focus and polling until the focus changed to the desired focus is too slow to implement a contrast enhanced auto-focus plugin.

When it comes to dependencies we've had great success with using Renovate to automatically create new pull requests when new versions of dependencies are released.

Would automatically upgrading the base images found in the Dockerfiles be of benefit, or do you already have a well functioning process where the Dockerfiles are updated when new versions of the base images are released?

(This issue is valid for acap-native-sdk-examples, acap-computer-vision-sdk and acap-computer-vision-sdk-examples as well)

Hi,
we are creating an application that should read the audio input from the camera, use a neural network model to classify specific events from the sound and react to them somehow. I noticed that there used to be an AXaudio library for it, there is even a documentation for it, however the example provided in the documentation doesn't work anymore since (I assume from my research) the library was removed from the SDK some time ago. Is there any replacement for it I am missing, or some other way to get the audio feed and feed it into Larod? And if not, are there any plans to create one?
Thank you in advance for your answer.

Hi,
We've been asked by a customer to integrate our solution on a M2035-LE with chipset Ambarella CV25.
However in your description of SDK4.x, I don't see SDK4.x supports CV25.

https://axiscommunications.github.io/acap-documentation/docs/api/native-api.html

What are the tools we need to integrate our ACAP on CV25 chipset?
Can you provide us the information we need to do this?

Thanks,
Maggy

Describe the bug

Hi,

I have been testing the Cairo overlay APIs in ACAP3 and 4 and came across an issue when using axoverlay_set_overlay_size causing a crash.

I am testing on a Q1615 MKIII and the issue started from fw 10.8.1 (before that release all was working fine) and higher. I managed to narrow it down to this specific function: "axoverlay_set_overlay_size" which allows to resize a box. I have also created a couple of videos showing what happens.

Here is a demo video showing the test application not using the "axoverlay_set_overlay_size" -->
https://www.youtube.com/watch?v=8KUGwci_u5w

And here is the test application using "axoverlay_set_overlay_size" -->
https://www.youtube.com/watch?v=6KoEoPeFKe8

When running the same sample test code on fw 10.7.3 I have no issues.

To reproduce

Use "axoverlay_set_overlay_size"

Steps to reproduce the behavior:

Run the "axoverlay_set_overlay_size" on fw 10.8.1 and higher through ssh terminal. Logs will show this message:

(process:6939): GLib-CRITICAL **: 10:59:18.712: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed
overlaytest: src/overlay.c:749: overlay_free_overlay_context: Assertion `ovl_table != NULL' failed.
Aborted (core dumped)

Environment

• Axis device model: Q1615 Mk III

• Axis device firmware version: starting 10.8.1 including the latest version 10.12.73

• Stack trace or logs:

• 2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ ERR ] kernel: [ 133.331897][ T6939] overlaytest: overlaytest: potentially unexpected fatal signal 6.
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332060][ T6939] CPU: 1 PID: 6939 Comm: overlaytest Kdump: loaded Tainted: G O 4.19.217-axis8 #1
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332181][ T6939] Hardware name: Axis ARTPEC-7 Platform
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332249][ T6939] PC is at 0x76b65996
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332365][ T6939] LR is at 0x76ba2497
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332430][ T6939] pc : [<76b65996>] lr : [<76ba2497>] psr: 200e0030
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332546][ T6939] sp : 7edca690 ip : 0000010c fp : 00000000
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332613][ T6939] r10: 74c48018 r9 : 76f77ad8 r8 : 76f77594
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332727][ T6939] r7 : 0000010c r6 : 76c3633c r5 : 00000006 r4 : 00001b1b
  2022-08-19T10:59:18.723-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332793][ T6939] r3 : 76fae770 r2 : 00000006 r1 : 00001b1b r0 : 00000000
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.332915][ T6939] Flags: nzCv IRQs on FIQs on Mode USER_32 ISA Thumb Segment user
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333038][ T6939] Control: 50c5387d Table: 6db7004a DAC: 00000055
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333106][ T6939] CPU: 1 PID: 6939 Comm: overlaytest Kdump: loaded Tainted: G O 4.19.217-axis8 #1
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333220][ T6939] Hardware name: Axis ARTPEC-7 Platform
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333350][ T6939] [<8010bd99>] (unwind_backtrace) from [<8010898f>] (show_stack+0xb/0xc)
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333423][ T6939] [<8010898f>] (show_stack) from [<804a2a41>] (dump_stack+0x69/0x78)
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333546][ T6939] [<804a2a41>] (dump_stack) from [<801202e3>] (get_signal+0x2d3/0x530)
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333669][ T6939] [<801202e3>] (get_signal) from [<80108355>] (do_signal+0x81/0x3a4)
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333735][ T6939] [<80108355>] (do_signal) from [<801087b1>] (do_work_pending+0x75/0x84)
  2022-08-19T10:59:18.724-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333851][ T6939] [<801087b1>] (do_work_pending) from [<80101079>] (slow_work_pending+0x9/0x18)
  2022-08-19T10:59:18.730-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.333968][ T6939] Exception stack(0xea025fb0 to 0xea025ff8)
  2022-08-19T10:59:18.730-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.334035][ T6939] 5fa0: 00000000 00001b1b 00000006 76fae770
  2022-08-19T10:59:18.730-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.334154][ T6939] 5fc0: 00001b1b 00000006 76c3633c 0000010c 76f77594 76f77ad8 74c48018 00000000
  2022-08-19T10:59:18.730-04:00 axis-b8a44f050c2b [ WARNING ] kernel: [ 133.334271][ T6939] 5fe0: 0000010c 7edca690 76ba2497 76b65996 200e0030 00001b1b
  2022-08-19T10:59:18.752-04:00 axis-b8a44f050c2b [ INFO ] overlayd: ./overlaytest vanished, removing its overlays
  2022-08-19T10:59:18.755-04:00 axis-b8a44f050c2b [ INFO ] overlayd: :1.405 vanished, tearing down command channel

• Version: ACAP3.5 and ACAP4 (axisecp/acap-native-sdk:1.1-armv7hf-ubuntu20.04)

Additional context

Willing to share test code to AXIS internally if needed.

Thanks!
Marco
Axis Communications

What is the benefit of having ARCH and REPO as Dockerfile arguments?

When it comes to ARCH, haven't we already decided on the architecture by selecting the correct Dockerfile among the alternatives Dockerfile.aarch64 and Dockerfile.armv7hf?

When it comes to REPO, is a common scenario to choose another repository than the default to pull the images from?

The reason I'm asking is because having these arguments makes me believe that there's something missing to the puzzle, something I doesn't understand, that I will invest time into figuring out.

(This issue is valid for acap-native-sdk-examples, acap-computer-vision-sdk and acap-computer-vision-sdk-examples as well)