The failure in the Deploy step sounds very similar to some of the issues I encountered when trying to get QT creator working on Ubuntu 17.04, what I found was that newer versions of QT were getting some paths wrong and trying to find the free space of a directory that didn't exist on the target. Rather than trying to figure out why, I simply switched my development machine back to Ubuntu 16.04 LTS, which seemed to work just fine. Can you check which version of Ubuntu and QT creator you're using?
Chronos Cam App open source build discussion
- Thread starter tesla500
- Start date
host = Ubuntu 16.04LTS. QT creator ver = 3.5.1.
In the .pro project file there is a target.path = /home/root/qt. that path does not exists so I fixed that by adding the qt folder.
That unfortunately did not help.
Googling the problem I found a post suggesting QT will try to load to /root.
So I created a /root folder, that did not work either.
Change install folder permission to rw access for everybody. Did not help.
Running out of ideas to try but I will continue ...
In the .pro project file there is a target.path = /home/root/qt. that path does not exists so I fixed that by adding the qt folder.
That unfortunately did not help.
Googling the problem I found a post suggesting QT will try to load to /root.
So I created a /root folder, that did not work either.
Change install folder permission to rw access for everybody. Did not help.
Running out of ideas to try but I will continue ...
That was it.
Removed "check for free space" and changed path in .pro file to target.path = /opt/camera
Deploy/Debug works fine now.
Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.
Once it's working I will be happy to show what I have and share if anybody is interested.
Removed "check for free space" and changed path in .pro file to target.path = /opt/camera
Deploy/Debug works fine now.
Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.
Once it's working I will be happy to show what I have and share if anybody is interested.
tretee said:
We're also working on this, in fact pretty much all our effort now is devoted to getting Ethernet remote control and video download working. It's a very nontrivial task to just get the video into a RAM buffer, which is one of the reasons why it's taking so long.
The video system is built on a framework called OpenMax (OMX). Most of OMX is run internally by a separate M3 core in the CPU. This runs a binary blob provided by TI, the source is available from TI under an NDA, ask for the "DM8148 EZSDK Overlay Package". This handles pretty much everything related to video input, processing, and output to the display. There's another M3 running a different binary blob which operates the H264 encoder. We've modified the former M3 code somewhat to add features like the video save throttling.
In the camApp, OMX is used directly for live display, and saving is done using gstreamer. Internally, gstreamer uses OMX as OMX is the only way to do anything with the hardware accelerated video pipeline. There is currently a problem with the gstreamer component that allows you to get frames into a RAM buffer, foobar or Loial could comment further, but we believe that the component that provides RAM buffers doesn't properly handle shutting down the pipeline, which crashes the M3. This issue needs to be solved before we can get RAW saving over Etherent working.
gstreamer currently supports streaming compressed video via RTSP, if you just want live display that should be significantly easier than getting RAW.
Take a look at videoRecord.c to see how the gstreamer pipeline is set up. There's also a way to run gstreamer pipelines from the command line, Loial has some examples of doing this.
