WebcamCompressInMemory

Introduction

Every time someone is using a browser to see a webcam motion writes to disk each frame captured from a device (v4l or network). Instead of using a tmpfile() function i changed the code to use memory for jpeg compressing to speed up.

Description of Patch

This patch tries to reduce the potencial I/O bottleneck replacing the compress process, for jpeg images, from disk ( tmpfile() ) to memory.

Installation of Patch

tar xfvz motion-3.2.1.tar.gz
cd motion-3.2.1
gzip -cd ../WebcamCompressInMemory.diff.gz | patch -p1

Change History of Patch

• 3.2.1-post1
• 3.2.2-snap4-post2 2 Jul 2005

Discussion and Comments

---

You seem to be doing a whole lot more than just replacing tmpfile.

You add a lot of code and there is not a single comment saying what the code is doing. The old Motion code is with little comments but I am adding comments to the files one by one and most of the regular developers are doing the same so we help each other getting an overview.

The snap2 I released meant code changes everywhere to eliminate gcc 4 warnings. So your patch will have to be re-merged into 3.2.2_snap3 (released very soon). I tried to run the patch. I get 3 small reject files and the rejected code looked easy to merge. It is a 10 minute job.

But before you do too much work. Please explain what all that code is doing. Just use this topic.

I am sure it is a great patch and that it will be added.

-- KennethLavrsen - 23 Jun 2005

Usally for the events EVENT_IMAGE and EVENT_IMAGE_DETECTED webcam_put from webcam.c with a picture is called.

If there are any clients connected and no picture sending is in progress a new tempfile with a picture converted to jpeg is created.

The picture is converted in put_picture_fd from picture.c.

This function converts a ppm picture to bgr24 (if configured) or the v4l picturetype VIDEO_PALETTE_YUV420P / VIDEO_PALETTE_GREY to a jpeg.

Now each client using this tempfile does reference counting on them an decreases this count after trying to send.

My patch does two things:

1. Instead of tempfile i use allocated memory for each picture but keep reference counting.

2. Instead put_picture_fd i had to write put_picture_mem.

put_picture_fd -> put_picture_mem

To support all 3 conversion methods i added functions based on the existing one:

put_jpeg_yuv420p -> put_jpeg_yuv420p_mem
put_jpeg_grey -> put_jpeg_grey_mem
put_ppm_bgr24 -> put_ppm_bgr24_mem

and instead of accessing a filepointer i access memory.

Additionally to support jpeg compression in memory i had to add functions for the jpeg library at the beginning of picture.c

-- PeterHolik - 23 Jun 2005

---

Need to look a little more at the code before I add it - but I believe it will be added once I have tested it and stepped through the code.

-- KennethLavrsen - 27 Jun 2005

---

I spent half a Sunday on this patch.

It worked right out of the box with a few compiler warnings in gcc4.

I decided to walk through the code in detail and decided to do some extra work.

• The webcam is a stream in mjpeg format. When the user chooses to store images in ppm format the old code tried to stream ppm pictures which does not work. The new webcam code repeated this behavour. By actually simplifying the code and throwing away put_ppm_bgr24_mem() Motion now actually can stream mjpeg even when the user saves ppm files. So this is a nice new feature.
• I added a lot of comments in both your new code and the old. I add comments in Motion each time I make a major walkthrogh. I encourage you and others to follow the good example. Some of the regular developers have also started commenting. The important comments are the ones explaining what a function does. And then add a few comments inside the function when using tricks and non-obvious code constructions.
• I renamed the functions in webcam.c and picture.c so that the names explains better what they do. I also renamed variables. Good function and variable names is as important as comments.
• I fixed a few indentation errors.
• I fixed the compiler warnings (signed / unsigned).
• I renamed all variables and functions called tmpfile. Since it is no longer a tmpfile the name becomes confusing when reading the code. I also made sure that the name of a function and the name of a struct was no longer the same. It was confusing when reading the code.

The end result seems to work fine. I have not seen any leaks the 6 hours I tested but I did not use any memory leak tools.

The modified patch is in 3.2.2_snap5. Even though I did modify the code so it is hard to recognize the major bulk of the job was the work done in the original patch and half of my cleaning was in the existing code. So great job Peter. Thanks

---

This patch has introduced a major issue. The mjpeg stream is somehow destroyed but not always.

-- KennethLavrsen - 15 Jul 2005

---

There are thousands and thousands of various automation tools on the market and if used smartly they come out very helpful for routine SEO tasks, small generic epizods and such. It doesn't look like any bots are used in creation of testimonials at Payforessay on https://topwritingreviews.com/services/payforessay. Do you think so?

-- NickiAllen - 12 Dec 2017

---