njsss
Posts: 35
Joined: Fri May 20, 2016 9:36 pm

Python or C++ for fast recording?

Mon Dec 05, 2016 10:25 pm

Hello all,

I plan to use raspberry pi and the camera module (NoIR v2) to record a short video on-demand, and I want to be able to integrate it to an opencv application. I need highest fps possible, so I was a little confused as how to achieve it.

The Picamera (python api v1.12) states the camera can get 40-90 fps with a resolution 640x480; yet the unofficial C++ api (RaspiCam) can only reach 29.29 fps under 640x480. Isn't c++ supposed to be faster? Or the picamera may not actually achieve more than 40 fps?

python or c++?

thanks

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23060
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python or C++ for fast recording?

Tue Dec 06, 2016 2:06 pm

C++ will be faster.

I suspect you are comparing different camera modes in your python vs C++ test. They are the ultimate fps limitation, whatever the language speed.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

njsss
Posts: 35
Joined: Fri May 20, 2016 9:36 pm

Re: Python or C++ for fast recording?

Tue Dec 06, 2016 10:53 pm

Hi jamesh,

I actually haven't tested either, try to decide which way to go. Just by comparing the documents from python api (picamera) and c++ api (RaspiCam), makes me a little bit confused. What I have is a version 2 NoIR camera, as stated in picamera/hardware part, with a vga resolution (640x480), partial fov, and 2x2 binning, the camera can achieve 40-90 fps! Yet after google it, even c++ can't reach that (https://github.com/cedricve/raspicam).

so basically
1) both python and c++ api can reach the ultimate fps.
2) c++ api runs faster than python.

right?

thank you

ghans
Posts: 7867
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Python or C++ for fast recording?

Wed Dec 07, 2016 6:52 am

I guess the Python wrappers are simply better than the C++ ones ... picamera is actively maintained ,
sensibly designed , excellently documented and very feature-rich.
AFAIK it will auto-switch modes if you select higher FPS rates.
Doesn't your C++ wrapper offer similiar functionailty ?

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23060
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python or C++ for fast recording?

Wed Dec 07, 2016 1:53 pm

ghans wrote:I guess the Python wrappers are simply better than the C++ ones ... picamera is actively maintained ,
sensibly designed , excellently documented and very feature-rich.
AFAIK it will auto-switch modes if you select higher FPS rates.
Doesn't your C++ wrapper offer similiar functionailty ?

ghans
There are no C++ wrappers in the demo examples. Raspistill etc talk pretty much directly (shortest path) to the ISP code on the VC4. Raspistill etc will always be faster than the Python code because of that. Note, Raspistill etc are actively maintained, the ISP code is actively maintained.

The third party C++ wrapper quoted may well add some nasty overheads. I should really get round to writing my own and get some official support, maybe next year!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

MarkR
Posts: 154
Joined: Fri Jan 25, 2013 1:55 pm

Re: Python or C++ for fast recording?

Wed Dec 07, 2016 2:11 pm

Getting the pictures from the camera is unlikely to be the performance bottleneck.

If you are doing any analysis in opencv - even very rudimentary - of every frame from the camera, then you won't be able to keep up with the camera at 640x480 (or any higher resolution, I suspect).

If on the other hand, you want to discard most of the frames and just pick a few for analysis, that might work.

builder93939
Posts: 11
Joined: Sat Dec 03, 2016 3:02 pm

Re: Python or C++ for fast recording?

Wed Dec 07, 2016 2:52 pm

I'm quite new to cameras, but been solving a lot of problems with them the past few days. Some things you may find useful...

- raspicam_cv.h , not sure what it does, but theres a bcm command that I can't recall, but surely you can search it, which will make the cam appear as /dev/video0, from there you can load it into cvCapturefromCAM(0) & it's the same as any other webcam as far as opencv is concerned. However, at least on the pi, for me it's significantly faster than USB based cameras. I guess due to it's connector. (Again, I'm new to cameras, but perhaps someone can explain to me the point of raspicam_cv.h and that whole opencv c++ API when it's 10x easier to do this?) If you do follow those instructions (https://github.com/cedricve/raspicam), one thing they don't mention is that raspicam_cv.h must use opencv 2.4.x api, it won't work w/3+. Don't be like me & waste 5 hr compile times to learn this!

- For me, FPS that the pi can display (on my 7" official screen) depends on whether it's a live stream or not. From a live stream, regardless of the resolution, using OpenCV to measure FPS I never got above 30. I'm using a v2 no ir camera. I'm not sure what settings must be enabled to get advertised speeds.

- As mentioned, the pi (I'm using a rpi3) is way too slow to do any image processing. It can do very basic stuff like convert color images to gray or flip images while consuming around 10% CPU, but anything that involves ROI, or even drawing on the live stream will be extremely laggy at best. The pi is useful for taking the live stream from the camera, and offloading it to another host to perform image processing. In short, pi is not capable of image analysis.

- I'm using opencv2 C api. Never used the c++/py api. I think anything important is going to happen in the kernel. In theory, c will be faster than c++ which will be faster than python, in practice it's going to be a minimal speed/resource consumption difference between the 3 for basic live cam streaming. For intense stuff like w/image analysis, you could be looking at 20%+ CPU consumption differences between the languages. To give an idea, I have a very powerful server that does intense image analysis and it consumes 90%+ of that cpu...

Hope that helps.

ghans
Posts: 7867
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Python or C++ for fast recording?

Wed Dec 07, 2016 8:18 pm

Indeed , the V4L2 driver (sudo modprobe bcm2835-v4l2)
might be another option. It supports lots of tuning options via v2l2-ctl .

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 10:01 am

Just to add a little to this topic: when it comes to simply recording data from the camera the choice of language will make little/no difference to the speed you can reach. All the serious processing happens on the GPU, which then sends packets of output to whatever you've got in userspace. So whether it's Python, C, C++, JavaScript or whatever, all it's got to do is accept the bytes and write it to a file. That's sufficiently trivial that language choice is effectively irrelevant.

If you want to do some actual *work* on those bytes then language choice *might* be relevant, but it's still not as cut and dried as "C++ is faster than Python". Remember that a lot of serious Python libraries, or libraries with Python bindings (including numpy, scipy, opencv, etc.) are written in C so your code might well be in Python, but the bulk of the work would still be performed in fast, compiled code.

Ultimately I'd say trying to decide on a language up front is a case of premature optimization. I usually find algorithm choice has a *much* greater influence on the eventual speed of any code than language choice so you're better off spending your time studying that. Start work in whatever language you're familiar with, or if you're learning from scratch start work in a high level language to minimize the learning curve.

If you reach a point where things aren't fast enough, profile and optimize the pieces that are the real bottlenecks (which is never a case of "the whole language").

Getting back to the camera and what work gets done where, I've been expanding the hardware chapter of the docs for the next release with an explanation and some (crude) diagrams. I'd welcome any feedback on it as it probably needs simplification and a bit more expansion before it's released!


Dave.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23060
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 1:23 pm

waveform80 wrote:Just to add a little to this topic: when it comes to simply recording data from the camera the choice of language will make little/no difference to the speed you can reach. All the serious processing happens on the GPU, which then sends packets of output to whatever you've got in userspace. So whether it's Python, C, C++, JavaScript or whatever, all it's got to do is accept the bytes and write it to a file. That's sufficiently trivial that language choice is effectively irrelevant.

If you want to do some actual *work* on those bytes then language choice *might* be relevant, but it's still not as cut and dried as "C++ is faster than Python". Remember that a lot of serious Python libraries, or libraries with Python bindings (including numpy, scipy, opencv, etc.) are written in C so your code might well be in Python, but the bulk of the work would still be performed in fast, compiled code.

Ultimately I'd say trying to decide on a language up front is a case of premature optimization. I usually find algorithm choice has a *much* greater influence on the eventual speed of any code than language choice so you're better off spending your time studying that. Start work in whatever language you're familiar with, or if you're learning from scratch start work in a high level language to minimize the learning curve.

If you reach a point where things aren't fast enough, profile and optimize the pieces that are the real bottlenecks (which is never a case of "the whole language").

Getting back to the camera and what work gets done where, I've been expanding the hardware chapter of the docs for the next release with an explanation and some (crude) diagrams. I'd welcome any feedback on it as it probably needs simplification and a bit more expansion before it's released!


Dave.
Hi Dave,

not given docs a thorough read (but what I did read was pretty damn good), but one thing did jump out. The OS running on the VC4 is threadx IIRC, not VCOS. VCOS is an abstraction layer for the OS calls which means that the code can be compiled for different OS simply by adding a new VCOS abstraction layer for that OS. So the VC4 code can compile and run over threadx, Linux (via pthreads etc) and I think there was even a Windows version at some point - deprecated now!

Also, might be worth mentioning that MMAL is a abstraction layer over OpenMAX to make it easier to use (which isn't difficult...).

Finally, with regard to language choice, that is usually dictated by what is already being used! You are in a lucky place indeed if you have a clean sheet design and can pick the language to use.

James
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 2:32 pm

jamesh wrote:Hi Dave,

not given docs a thorough read (but what I did read was pretty damn good), but one thing did jump out. The OS running on the VC4 is threadx IIRC, not VCOS. VCOS is an abstraction layer for the OS calls which means that the code can be compiled for different OS simply by adding a new VCOS abstraction layer for that OS. So the VC4 code can compile and run over threadx, Linux (via pthreads etc) and I think there was even a Windows version at some point - deprecated now!

Also, might be worth mentioning that MMAL is a abstraction layer over OpenMAX to make it easier to use (which isn't difficult...).

Finally, with regard to language choice, that is usually dictated by what is already being used! You are in a lucky place indeed if you have a clean sheet design and can pick the language to use.

James
I've already given Dave a docs review by email :D
Also MMAL is NOT an abstraction over OpenMaxIL. It reuses the Reduced IL API for the components on the VideoCore side, but none of the IL core (because that is where all the nastiness lies). So it has similarities but is not an abstraction. I really don't want people taking your comment out of context, as IL is a pain to get right.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

RpiName
Posts: 711
Joined: Sat Jul 06, 2013 3:14 am

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 6:39 pm

njsss wrote:I plan to use raspberry pi and the camera module (NoIR v2) to record a short video on-demand, and I want to be able to integrate it to an opencv application. I need highest fps possible, so I was a little confused as how to achieve it.
The fastest is UV4L. Ok, I should say "would be" because, while this functionality is already implemented, it's not documented yet: UV4L can provide an "hook" that easily allows to integrate any opencv or third-party processing on all the uncompressed frames passing through *any* supported pipeline, starting from the bottom driver up to the integrated streaming server. An example of the performance is the built-in face detection or tracking, another example is text/image-overlay. You can already enable it at driver level and see real-time face detection in action on any browser via WebRTC in H264 HD full 30-fps with just ~25-30% of CPU usage on a Rpi3. (It's actually two mouse clicks to test this from the web interface). No other software can achieve this on the Rpi AFAIK. Also, as you have asked about recording, it's possible to record & playback the processed video from within the browser and even on the server side (although I'll leave out the details in this case).

If there's enough interest, I can ask the powers to export or document this functionality for the public.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 10:04 pm

RpiName wrote:
njsss wrote:I plan to use raspberry pi and the camera module (NoIR v2) to record a short video on-demand, and I want to be able to integrate it to an opencv application. I need highest fps possible, so I was a little confused as how to achieve it.
The fastest is UV4L. Ok, I should say "would be" because, while this functionality is already implemented, it's not documented yet: UV4L can provide an "hook" that easily allows to integrate any opencv or third-party processing on all the uncompressed frames passing through *any* supported pipeline, starting from the bottom driver up to the integrated streaming server. An example of the performance is the built-in face detection or tracking, another example is text/image-overlay. You can already enable it at driver level and see real-time face detection in action on any browser via WebRTC in H264 HD full 30-fps with just ~25-30% of CPU usage on a Rpi3. (It's actually two mouse clicks to test this from the web interface). No other software can achieve this on the Rpi AFAIK. Also, as you have asked about recording, it's possible to record & playback the processed video from within the browser and even on the server side (although I'll leave out the details in this case).

If there's enough interest, I can ask the powers to export or document this functionality for the public.
And UV4L is written in ... ? C at a guess.
It's going through exactly the same IPC to the GPU as raspistill, raspivid, bcm2835-v4l2, and PiCamera. Other than mangling the buffers to fit with the appropriate framework, and possibly a few different kernel/userspace transactions, they are all identical.
waveform80 is right that the amount of CPU time required for almost any of the different mechanisms will be small compared to the amount required for any significant OpenCV processing, just as long as there aren't any daft casts going on.

(The craziest OpenCV code I've seen was to simply divide all pixel values by 8. Take the uint16 array of pixel values, convert to floats(!), floating point divide by 8, and then convert back to uint16. For some crazy reason it didn't perform very well. Reimplement as a simple integer shift right 3 and it went quite a bit faster. Amazing. No amount of framework tweaking is going to get around that sort of silliness.)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

RpiName
Posts: 711
Joined: Sat Jul 06, 2013 3:14 am

Re: Python or C++ for fast recording?

Wed Jan 04, 2017 11:50 pm

6by9 wrote:It's going through exactly the same IPC to the GPU as raspistill, raspivid, bcm2835-v4l2, and PiCamera. Other than mangling the buffers to fit with the appropriate framework, and possibly a few different kernel/userspace transactions, they are all identical.
waveform80 is right that the amount of CPU time required for almost any of the different mechanisms will be small compared to the amount required for any significant OpenCV processing, just as long as there aren't any daft casts going on.
waveform80's comment was more about languages, not mechanisms in general. Anyway, while what are you saying is true for very very simple and limited programs like the ones you mentioned, try to extend one of them in order to present a video frame in less than ~200ms to the user browser, if you know what this means (which was my suggestion to the OP for a possibly useful record-while-streaming service with some custom image processing). You will then notice how much languages, mechanisms and any sort of (apparently) micro-optimizations count on constrained architecture like the Rpi.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23060
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 8:34 am

RpiName wrote:
6by9 wrote:It's going through exactly the same IPC to the GPU as raspistill, raspivid, bcm2835-v4l2, and PiCamera. Other than mangling the buffers to fit with the appropriate framework, and possibly a few different kernel/userspace transactions, they are all identical.
waveform80 is right that the amount of CPU time required for almost any of the different mechanisms will be small compared to the amount required for any significant OpenCV processing, just as long as there aren't any daft casts going on.
waveform80's comment was more about languages, not mechanisms in general. Anyway, while what are you saying is true for very very simple and limited programs like the ones you mentioned, try to extend one of them in order to present a video frame in less than ~200ms to the user browser, if you know what this means (which was my suggestion to the OP for a possibly useful record-while-streaming service with some custom image processing). You will then notice how much languages, mechanisms and any sort of (apparently) micro-optimizations count on constrained architecture like the Rpi.
I'd suggest 6x9 knows exactly what he's doing, since he is the world's leading expert on the Vc4 camera code, owing to the fact he wrote a large proportion of it.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

builder93939
Posts: 11
Joined: Sat Dec 03, 2016 3:02 pm

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 2:17 pm

njsss wrote: see real-time face detection in action on any browser via WebRTC in H264 HD full 30-fps with just ~25-30% of CPU usage on a Rpi3. (It's actually two mouse clicks to test this from the web interface). No other software can achieve this on the Rpi AFAIK

If there's enough interest, I can ask the powers to export or document this functionality for the public.
There is def. interest. You're saying the pi is even capable of facial recognition, much less at 30% cpu? I would def. need to see the code to believe that : )
The fastest is UV4L. Ok, I should say "would be" because, while this functionality is already implemented, it's not documented yet: UV4L can provide an "hook" that easily allows to integrate any opencv or third-party processing on all the uncompressed frames passing through *any* supported pipeline, starting from the bottom driver up to the integrated streaming server.

I can confirm w/my own tests what 6by9 has said - I don't think "the fastest is UV4L", although it is my personal choice due to cross platform linux-distro compatibility and a convenient /dev/video0 interface, in my tests MMAL gave me no faster or slower performance. If you compile opencv correctly, which admittedly is probably more difficult than writing opencv code, it can work very well with the bcm/uv4l driver. But the opencv you'll find in the repos won't.

Although earlier in this thread I was confused, the raspicv_cv.h does exactly this, by using the MMAL api to grab raw frames and add the Mat headers to use natively in opencv. [/quote]

Just to add a little to this topic: when it comes to simply recording data from the camera the choice of language will make little/no difference to the speed you can reach. All the serious processing happens on the GPU, which then sends packets of output to whatever you've got in userspace. So whether it's Python, C, C++, JavaScript or whatever, all it's got to do is accept the bytes and write it to a file. That's sufficiently trivial that language choice is effectively irrelevant.

If you want to do some actual *work* on those bytes then language choice *might* be relevant, but it's still not as cut and dried as "C++ is faster than Python". Remember that a lot of serious Python libraries, or libraries with Python bindings (including numpy, scipy, opencv, etc.) are written in C so your code might well be in Python, but the bulk of the work would still be performed in fast, compiled code.
Well, I think it's more about what you're doing. If you're just taking a picture, or recording a video, the difference between python vs. C will be trivial.

When you compile python, even to call a function is going to have, at a minimum, dozens more of ARM instructions executed than doing the equivalent in ARM/cc/g++/etc, and to a lesser extent C. Let's say you're streaming 30 fps over the network, and you have a routine running 30 times p/second, python out of the box will charge you thousands of extra, useless, instructions executed p/second, resulting in significant lag times, increased CPU/battery usage, etc.

A coworker on my team was able to achieve the fastest frame rate display, while consuming virtually nor esources, on a client side video streamer (where the Pi was streaming to pretty much every device imaginable) by hand coding x86 asm in masm windows and feeding frames directly to a GDI buffer (hes doing the same thing on desktop linux now by giving frames to /dev/fb). You're not going to get anything close to that with anything else, even with gcc -O3. So when you're writing programs that will be run all day, everyday, for stuff like cameras, a few lines of code could mean a 20 or 30 dollar difference in a monthly electricity bill, and it's hard to say whether language X is better than language Y, but there's def. a list of languages you can't use, python, javascript, and even in many cases C++ being included.

I was just listening to the radio in my car, and heard the latest hit sweeping the charts globally, it's called "write in C" - https://www.youtube.com/watch?v=1S1fISh-pag : ) OK, jk :)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 2:36 pm

builder93939 wrote:
njsss wrote: see real-time face detection in action on any browser via WebRTC in H264 HD full 30-fps with just ~25-30% of CPU usage on a Rpi3. (It's actually two mouse clicks to test this from the web interface). No other software can achieve this on the Rpi AFAIK

If there's enough interest, I can ask the powers to export or document this functionality for the public.
There is def. interest. You're saying the pi is even capable of facial recognition, much less at 30% cpu? I would def. need to see the code to believe that : )
Face detection (ie there is a face at x,y of size w,h), not face recognition (oh, it's Fred).
We had a third party (read licence fees payable) face detection algo running on the VideoCore side. IIRC It took about 5ms per frame on the VPU (250MHz), and only had minimal vectorisation (if any).
Face detection isn't as big a deal as it may at first seem, and generally you only need to run it every few frames as people don't move that fast when they're facing a camera.
builder93939 wrote:I was just listening to the radio in my car, and heard the latest hit sweeping the charts globally, it's called "write in C" - https://www.youtube.com/watch?v=1S1fISh-pag : ) OK, jk :)
:-)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

RpiName
Posts: 711
Joined: Sat Jul 06, 2013 3:14 am

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 4:08 pm

builder93939 wrote:There is def. interest. You're saying the pi is even capable of facial recognition, much less at 30% cpu? I would def. need to see the code to believe that : )
I said facial detection and/or tracking, not facial recognition. Anyway, you do not need the source code to check :P
builder93939 wrote:Let's say you're streaming 30 fps over the network, and you have a routine running 30 times p/second, python out of the box will charge you thousands of extra, useless, instructions executed p/second, resulting in significant lag times, increased CPU/battery usage, etc.
which is the point of my previous answer.
builder93939 wrote: I was just listening to the radio in my car, and heard the latest hit sweeping the charts globally, it's called "write in C" - https://www.youtube.com/watch?v=1S1fISh-pag : ) OK, jk :)
C is good to nothing nowadays. It's a well-known fact that idiomatic C++ gives the compiler a better chance to produce faster object code (apart from all the other benefits). But sometimes you do not have a C++ implementation and must still go with C.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 4:24 pm

RpiName wrote:C is good to nothing nowadays. It's a well-known fact that idiomatic C++ gives the compiler a better chance to produce faster object code (apart from all the other benefits). But sometimes you do not have a C++ implementation and must still go with C.
So that leaves the unanswered question as to what UV4L is written in. UV4L is not a language.
The original question was which is faster, python or C++. You've now written off C, so I can only assume it's using Pascal, Cobol, or pure assembler. It obviously can't be C++ as then you'd have answered the OP with C++.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 4:53 pm

builder93939 wrote:...when you're writing programs that will be run all day, everyday, for stuff like cameras, a few lines of code could mean a 20 or 30 dollar difference in a monthly electricity bill, and it's hard to say whether language X is better than language Y
A few lines of code means 20 or 30 dollars a _month_?! Are you powering your Pi with ground unicorn dust or something? I ... don't really understand how that might work, but I'm powering mine off a rather more mundane 2A phone charger so the monthly cost of running it is unlikely to be much more than ... hmm, actually I'm not sure (brief pause while Dave googles some electricity tariffs) ...

2A * 5V = 10W
10W * 24h * 30days/month = 7.2kWh/month
12.36p/kWh * 7.2kWh/month = 89p/month

Phew! For a minute I was worried my myriad Pi's were costing me a fortune ;)

Let's be really generous and assume we can save *half* the power by switching languages (!). I'll just about be able to save a fiver in the entire year. On the other hand, I'm fairly confident I can save a fiver's worth of my time in a year by using higher level languages here and there.
builder93939 wrote:... and you have a routine running 30 times p/second, python out of the box will charge you thousands of extra, useless, instructions executed p/second ...
Absolutely true - it's terribly inefficient compared to good ol' C (or even bare knuckle assembler). Fifteen years ago when I was hacking away at x86 assembler I'd have really cared about those thousands of wasted instructions. But nowadays I've more processing power in my pocket than my huge space-heating tower had back then. Nowadays I usually have more processor cycles than I need (yes, even on a Pi; not always, but often). So I don't mind sacrificing a few (yes, even a few thousand per second) if it gets me something in return (i.e. my time).

I'll certainly grant there's cases where it's not going to cut the mustard. There's still plenty of use for good ol' C (and even bare knuckle assembler) but it's no longer my starting point. Incidentally, I know that feeling of your brain yelling "but it's soooo wasteful! Think of all those processor cycles you could be *using* instead of sacrificing them to some high level runtime". Been there, got over it :)

Dave.

builder93939
Posts: 11
Joined: Sat Dec 03, 2016 3:02 pm

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 5:45 pm

waveform80 wrote:
builder93939 wrote:...when you're writing programs that will be run all day, everyday, for stuff like cameras, a few lines of code could mean a 20 or 30 dollar difference in a monthly electricity bill, and it's hard to say whether language X is better than language Y
A few lines of code means 20 or 30 dollars a _month_?! Are you powering your Pi with ground unicorn dust or something? I ... don't really understand how that might work, but I'm powering mine off a rather more mundane 2A phone charger so the monthly cost of running it is unlikely to be much more than ... hmm, actually I'm not sure (brief pause while Dave googles some electricity tariffs) ...

2A * 5V = 10W
10W * 24h * 30days/month = 7.2kWh/month
12.36p/kWh * 7.2kWh/month = 89p/month

Phew! For a minute I was worried my myriad Pi's were costing me a fortune ;)

Let's be really generous and assume we can save *half* the power by switching languages (!). I'll just about be able to save a fiver in the entire year. On the other hand, I'm fairly confident I can save a fiver's worth of my time in a year by using higher level languages here and there.
builder93939 wrote:... and you have a routine running 30 times p/second, python out of the box will charge you thousands of extra, useless, instructions executed p/second ...
Absolutely true - it's terribly inefficient compared to good ol' C (or even bare knuckle assembler). Fifteen years ago when I was hacking away at x86 assembler I'd have really cared about those thousands of wasted instructions. But nowadays I've more processing power in my pocket than my huge space-heating tower had back then. Nowadays I usually have more processor cycles than I need (yes, even on a Pi; not always, but often). So I don't mind sacrificing a few (yes, even a few thousand per second) if it gets me something in return (i.e. my time).

I'll certainly grant there's cases where it's not going to cut the mustard. There's still plenty of use for good ol' C (and even bare knuckle assembler) but it's no longer my starting point. Incidentally, I know that feeling of your brain yelling "but it's soooo wasteful! Think of all those processor cycles you could be *using* instead of sacrificing them to some high level runtime". Been there, got over it :)

Dave.
It's actually being powered with meteorite dust : ) Seriously though, not sure where you live but keep in mind price of electricity can vary, a lot. And I was referring to having the same code run on many Pi's, so if you have 100 Pi's running opencv python on a generator, or some island where they charge 1 usd p/kwh, (properly written) C is going to save you a lot of money.

I agree with your general view though. You do what works for you. I have my preferences, but I avoid talking religion/politics as to "the best language", and I def. will not be offended by any comments on a particular language.
I said facial detection and/or tracking, not facial recognition. Anyway, you do not need the source code to check :P
Excuse me, I misread that. No I don't want the source, we can't use stuff like WebRTC where javascript has access to native code for security anyways, I was just curious to see. Using a browser is tempting but opencv lets you have players on basically every device without the overhead of a browser. But we've gotten the same (and better) speeds and I'd imagine a lot of others have too.

RpiName
Posts: 711
Joined: Sat Jul 06, 2013 3:14 am

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 6:58 pm

builder93939 wrote:we can't use stuff like WebRTC where javascript has access to native code for security anyways, Using a browser is tempting
non sense. Face detection and face tracking are built in UV4L at V4L2 driver level, e.g. load the driver with detection enabled, put your face in front of the camera and take a frame with the old good dd if=/dev/video0 unix command.

got it?

I'll keep WebRTC out from this answer as you clearly do not know what you are talking about.
builder93939 wrote:but opencv lets you have players on basically every device without the overhead of a browser. But we've gotten the same (and better) speeds and I'd imagine a lot of others have too.
Yeah, load a V4L2 driver (either the kernel one or, again, UV4L) and use opencv for your face detection implementation on the captured frames, say in MJPEG or H264. It will unlikely be as fast and accurate as the built-in UV4L face detection.

RpiName
Posts: 711
Joined: Sat Jul 06, 2013 3:14 am

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 7:03 pm

6by9 wrote:
RpiName wrote:C is good to nothing nowadays. It's a well-known fact that idiomatic C++ gives the compiler a better chance to produce faster object code (apart from all the other benefits). But sometimes you do not have a C++ implementation and must still go with C.
So that leaves the unanswered question as to what UV4L is written in. UV4L is not a language.
The original question was which is faster, python or C++. You've now written off C, so I can only assume it's using Pascal, Cobol, or pure assembler. It obviously can't be C++ as then you'd have answered the OP with C++.
I do not follow your logic, but to answer your question, UV4L is ~99% modern C++ and, with regard to ARMv7 architectures like some the RPi models, there are critical paths implemented with Neon instructions.

builder93939
Posts: 11
Joined: Sat Dec 03, 2016 3:02 pm

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 9:28 pm

RpiName wrote:
builder93939 wrote:we can't use stuff like WebRTC where javascript has access to native code for security anyways, Using a browser is tempting
non sense. Face detection and face tracking are built in UV4L at V4L2 driver level, e.g. load the driver with detection enabled, put your face in front of the camera and take a frame with the old good dd if=/dev/video0 unix command.

got it?

I'll keep WebRTC out from this answer as you clearly do not know what you are talking about.
builder93939 wrote:but opencv lets you have players on basically every device without the overhead of a browser. But we've gotten the same (and better) speeds and I'd imagine a lot of others have too.
Yeah, load a V4L2 driver (either the kernel one or, again, UV4L) and use opencv for your face detection implementation on the captured frames, say in MJPEG or H264. It will unlikely be as fast and accurate as the built-in UV4L face detection.
Or let a server/client w/more resources than a Pi handle image processing so frames arrive to a client display faster...

You sound like a nice person and all, but many people/companies go through the trouble of building their own cameras, specifically to avoid those cheap & reliable off the shelf IP cameras that are very insecure. So using stuff like webrtc, which is known to have many remotely exploitable vulnerabilities (despite having a tiny userbase even has cves...), is not an option.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Python or C++ for fast recording?

Thu Jan 05, 2017 10:20 pm

RpiName wrote:I do not follow your logic, but to answer your question, UV4L is ~99% modern C++ and, with regard to ARMv7 architectures like some the RPi models, there are critical paths implemented with Neon instructions.
OP:
python or c++?
With your answer of "UV4L" you are really saying C++ (and some NEON) but with an alternative framework to the OPs raspicam C++ API.
The fastest way will be to remove all unnecessary framework stuff, so a version of raspivid.
RpiName wrote:Yeah, load a V4L2 driver (either the kernel one or, again, UV4L) and use opencv for your face detection implementation on the captured frames, say in MJPEG or H264. It will unlikely be as fast and accurate as the built-in UV4L face detection.
Why face detect on MJPEG or H264? The camera is producing YUV, and that can be sent to both OpenCV and encoder simultaneously. Sending YUV to the app at the same time as encoding was added to raspivid in November. No need to decode the bitstream (which would also add latency).

Speed depends on the complexity of the algorithm chosen and optimisations applied. NEON is great on BCM2836 and BCM2837 (as long as you handle cache sensibly), but not an option on BCM2835.
One would hope that those involved in the open source OpenCV project would have optimised their algorithms and had those optimisations reviewed. It looks like some of them are only for OpenCL rather than native NEON implementations, but as it's all open there is nothing stopping any programmer optimising as they need.

As waveform80 has said, analyse the specific use case and see if it meets your needs - these days there is normally CPU to spare. If not, profile it and see where the lowest hanging fruit is. In most cases it won't be the framework, and reworking the actual processing code will be the answer.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”