I am trying to create a gstreamer application, starting from the very basic Hello world gstreamer tutorial.
The application compiles without problems, both locally and remotely but when I try to execute that application I get the following error:
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingFATAL: cannot locate cpu MHz in /proc/cpuinfo
For remote compilation I made a remote cuda project. Then I tried to execute the file locally.
Has anybody come across this problem before, or maybe knows whats wrong with it? Thanks in advance.
I don’t remember where, but I believe the cpu MHz is not only an old and common issue (not a Jetson issue, but related because it isn’t an issue on many other platforms), but also was solved and marked for some future release. I just don’t remember where I saw that there is a solution which will be available (just not yet in Jetson’s version). Some web research might find a patch you could use temporarily.
The cpu Mhz is in an old issue. Its typical in the arm architecture. Most reports I found indicate that this is a jackd issue and the current jackd tree has a fix which has not propagated yet to the ubuntu tree. I tried to recompile jackd with a patch but this did not fix the issue. I even uninstalled jackd and this made no difference (I expected some form of dependancy but there was none). This is why I asked in case someone has come across the file which tries to parse /proc/cpuinfo and fails. The video I tried had sound. When I tried a video without sound everything worked as expected.
What is amazing is that even the most basic gstreamer tutorial fails. Maybe the problem is only with gstreamer0.10, but I need to write a plugin that uses opencv and for some reason if I try to install streamer-1.0-plugins opencv gets uninstalled!!!
And yes I did spend a couple of hours before I posted this question. I will resolve the issue but I thought I could save sometime. But as with all the other questions I posted in this forum I ended up solving the problem myself. What amazes me is how unstable this distribution is and how fast it deteriorates (it was more stable a month ago). It seems nvidia is using this chip just to create hype (the 64 bit version is another story). For instance, the documentation does not contain even one example how to interface a csi 2 camera, let alone more complex stuff. Probably because it does not work. And yes I could use a usb camera but that has a huge speed penalty and latency.
So its a good toy but thats about it. I am not going to waste any more of my time on it.
The fatal error is probably coming from the JACK audio server. The packaged jack2 that comes with L4T/Ubuntu has a problem on newer ARM processors. Any application that is “jack aware” can hit this. I ran into this with a number of audio applications I wanted to install and use on my Jetson.
To get around this you will need to build jack2 from the latest source code and install it.
I opted to overwrite the original files (the --prefix and --libdir args) because installing them in /usr/local still resulted in the old ones being picked up. I think there is a search order problem when looking for .so files.