Rotate image/Video only when saving or streaming

[gemminiss]

0. Reviewed guide and contributing documents? (Yes/No): No
1. version [x.y.z, hash, other]: 4.3.2
2. installed as a package or compiled from sources [deb, rpm, git, other]: git
3. standalone or part of third party [motion, MotionEyeOS, other]: motion
4. video stream source [V4L (card or USB), net cam (mjpeg, rtsp, other), mmal]: rtsp
5. hardware [x86, ARM, other]: ARM
6. operating system [16.04, Stretch, etc, FreeBSD, other]: Buster

Hello, I have a proposal for enhancement:

Rotate image/Video only when saving or streaming. To save CPU/Power consumption.

Description:

For my Set-up.

• 3 Rtsp cameras dual channel (high-low resolution)
• the 3 are rotated 90 degrees (to cover more Area)
• Motion detection done with low resolution and Movie Passthrough (high quality) ON.
• Motion Running on Raspberry Pi 3B.
• videos and Images sent via Telegram.

With this configuration, I can keep my raspberry at 25% CPU usage, Raspberry stays 'cool', and I'm able to add more Cameras.
But I have to turn my head 90° to watch the videos on PC (or turn the phone and lock the orientation)

And If I set 'Rotate 90' to all cameras

• CPU goes to 60% and more.
  -And the Passthrough videos are still saved not rotated.

I think that for the few times Motion is detecting or we watch the streaming, we do not need to rotate permanently and we could save CPU. --> from my personal experience.

-> I do not know if the streaming rotation can be managed by the webserver in a kind of 'stream_preview_rotate 90' (even better if rotation done in the frontend)
-> And do something similar like 'movie_output_rotate 90'

[davidmorabito]

+1

[bertofurth]

Is this something people are still interested in?

This issue caught my attention because I'm trying to reduce CPU usage as much as possible on my underpowered motion host.

I implemented a proposed method of only doing rotation when images are being viewed, however it is a little bit more involved than I originally thought. In addition I didn't see massive CPU savings. Only around 20%.

Would you be willing to try out my motion fork at

https://github.com/bertofurth/motion

and see what results you get?

Thanks!

[gemminiss]

Hello bertofurth.

I will test with pleasure your fork. I'm very interested in!

The only problem on my side is then 'when'. Between family, Work and some works at home I do not have much time in this moment. :(

I've read quickly the README of your fork, and I have some comments/questions (I'm à noob in coding and I have no idea about how Motion is hard coded, Sorry if I ask stupid questions ! )

My understanding of your work is that you are rotating the image in the host, and then creating à rotated stream when viewing/saving.

Which stream_preview_method are you using when you say only saves 20% CPU?

My Idea was that the 'rotate' job to be transferred to the client CPU.

• motion has the WebControl page, where we can watch 'live' stream (normally on port 8080).
• This web has to be coded in Html, CSS or any web Language.
• If there is any html/CSS command 'rotate', then the rotate job will be done by Client CPU.
  --> Right?

Thanks for your great Job!!

[bertofurth]

Hi gemminiss,

There's no hurry or compulsion at all! It's all voluntary. Your family comes first and my motion fork comes 58724th!!

It didn't matter what stream_preview_method was being used. The idea was that if "rotate 90" was configured then original motion was internally rotating images and burning CPU regardless of whether anyone was watching the stream or using the motion webpage or not.

Thanks for explaining your idea to have the rotation happen on the client. I'm afraid I don't know anything about html or CSS so I don't know if there's a way to rotate images on the client either.

The only minor problem with with rotating on the client would be that the embedded text would be rotated as well....although I'll bet most people could put up with that if it saved CPU load on the motion host.

Anyway, if you get a chance to test then please let me know how you go. If not, then no problems.

All the best!!

[Mr-Dave]

I would note that this is unlikely to be feasible to bring into the main code. The pre-capture functionality effectively means it always needs to be rotated. Trying to do the transformations on the pre-capture buffer just when the motion is detected and starting the recordings would bottleneck and stall the image capture at the precise moment when you want Motion to be recording.

[bertofurth]

Would there be any way to delay the pre capture buffer being rotated till after the recording was finished? So do the rotation and capture for all the live frames and then post event, rotate the pre-captured frames and prepend them? I guess doing that would make things pretty complicated. Never mind. I think the inescapable conclusion is that if you want to save CPU load then don't use 90 degree rotation.

…

On Thu, 14 Oct 2021, at 10:54, Mr-Dave wrote: I would note that this is unlikely to be feasible to bring into the main code. The pre-capture functionality effectively means it always needs to be rotated. Trying to do the transformations on the pre-capture buffer just when the motion is detected and starting the recordings would bottleneck and stall the image capture at the precise moment when you want Motion to be recording. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3N3NB4R7UBJZIF4DCTTB3UGYLZVANCNFSM4YOVF3TA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[tosiara]

Isn't 90, 180 and 270 degree rotation quite well optimized by SIMD during compile?

[gemminiss]

Hello.

As I'm à noob in coding, and my English level is not very good: sorry guys...I tried best but I'm not fully understanding you :(

Hereby my 'thinking path' from I've got the idea of post rotating Videos.

1. Motion is saving the video captures to à folder.
2. When Motion finishes the save of the capture/Video, I can use another different software to edit/rotate it, and delete the original
3. This Software could be just an scritpt (python, bash, other)
4. This scritpt, could be called directly from Motion Main Code. (if a configuration variable is turned ON)
5. The action would be something like 'Script...take the last Video (or video name) and rotate 90'
6. If the Variable is turned ON, Motion pushes the file (mail,Telegram) result of that script
7. If variable Tuned OFF, Motion do like is doing now.
8. Motion, Instead of writting/saving the video directly to a device, could write first to RAM, and depending of The variable ON/OFF, either write to to Device or send to this 'Rotate Script'.

Would this after Proces/Job, bottleneck the CPU?....disturb the MAin motion capture from Cameras?....

Probably I'm missing many things and I'm sure that I have a very simplistic understanding about what Motion does.

I just wanted to propose an enhencement with very low Impact on main Code. You are the Wise 'Motion' guys..., if you say that it is too complicate forget-it....

PS. Where can I buy à coffee for the developpers of Motion?....they really deserve-it :)

[bertofurth]

It doesn't seem to be very optimized on ARM. Maybe on x86 it's better?

…

On Thu, 14 Oct 2021, at 18:59, tosiara wrote: Isn't 90, 180 and 270 degree rotation quite well optimized by SIMD during compile? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3N3NAMGTFVEXUK4FHQ5M3UG2EUPANCNFSM4YOVF3TA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bertofurth]

Hi gemminiss, That sounds very clear and clever to me. Motion has a mechanism where you can call a script once a movie has been saved (on_movie_end). We could come up with a script that invoked "ffmpeg" to take the latest movie name as an argument and then rotated it. There's a stackoverflow question about it at https://stackoverflow.com/questions/3937387/rotating-videos-with-ffmpeg The syntax to rotate a motion movie 90 degrees clockwise is ffmpeg -i NAS-USB-20211014-212755-01.mkv -vf "transpose=1" NAS-USB-20211014-212755-01-90.mkv The only problem of course is that any embedded text is also rotated, but I somehow doubt that this is of much concern to most people. I'd also like to know where to send a coffee to the developers of motion! Berto.

…

On Thu, 14 Oct 2021, at 20:43, gemminiss wrote: Hello. As I'm à noob in coding, and my English level is not very good: sorry guys...I tried best but I'm not fully understanding you :( Hereby my 'thinking path' from I've got the idea of post rotating Videos. 1. Motion is saving the video captures to à folder. 2. When Motion finishes the save of the capture/Video, I can use another different software to edit/rotate it, and delete the original 3. This Software could be just an scritpt (python, bash, other) 4. This scritpt, could be called directly from Motion Main Code. (if a configuration variable is turned ON) 5. The action would be something like 'Script...take the last Video (or video name) and rotate 90' 6. If the Variable is turned ON, Motion pushes the file (mail,Telegram) result of that script 7. If variable Tuned OFF, Motion do like is doing now. 8. Motion, Instead of writting/saving the video directly to a device, could write first to RAM, and depending of The variable ON/OFF, either write to to Device or send to this 'Rotate Script'. Would this after Proces/Job, bottleneck the CPU?....disturb the MAin motion capture from Cameras?.... Probably I'm missing many things and I'm sure that I have a very simplistic understanding about what Motion does. I just wanted to propose an enhencement with very low Impact on main Code. You are the Wise 'Motion' guys..., if you say that it is too complicate forget-it.... PS. Where can I buy à coffee for the developpers of Motion?....they really deserve-it :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3N3NDMSQXEE35A3NSEX2DUG2Q4BANCNFSM4YOVF3TA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[tosiara]

You can try this test app: rotate.txt
This is a slightly modified motion code for rotation.

My results on x86_64 are:

$ gcc -O0 -march=native rotate.c 
$ time ./a.out 

real	0m18,047s
user	0m18,045s
sys	0m0,000s

$ gcc -O3 -march=native rotate.c 
$ time ./a.out 

real	0m0,002s
user	0m0,000s
sys	0m0,002s

on ARM results are a bit different, as there -O0 gives better results, than -O3

$ gcc -O0 rotate.c 
$ time ./a.out 

real	0m0.300s
user	0m0.268s
sys	0m0.028s

With O3 ARM test is going forever

[gemminiss]

@tosiara: sorry but I do not know how to test your rotate.txt

@bertofurth: I think your idea of using (on_movie_end) I think is the good one.

• I have installed ffmepg on my Raspberry.
• I have used yours: ffmpeg -i filename.mpeg -vf "transpose=1" filenamRotated.mpeg
• It took around 4 mins to rotate à 3.5Mb .mpeg Video

But I think that can be done faster because the file was on a NAS (it was a monted network folder, not stored in the SD Card of the raspberry).

I think it looks promissing. :)

For the embeeded text, you are rigth, now it's rotated. But I Think it is easier reading rotated text than watching a rotated Video.

The next step would be now to create à scritpt which combines:

1. -Apply the ffmpeg transform to the last file of (on_movie_end)
2. Pipe the output of the ffmpeg direct to à curl command to push the video

This is what I have in my motion.conf for pushing the Video to my smartphone
curl -s -F 'document=@%f' "https://api.telegram.org/botxxxx/sendDocument?chatid=xxxxxx"

But This I do not know how to do this combination :(

I think if we pipe directly we avoid double writing of the videos on devices (normal + rotated)

[tosiara]

rename it to rotate.c, then execute:

gcc -O0 -march=native rotate.c 
time ./a.out 
gcc -O3 -march=native rotate.c 
time ./a.out 

[bertofurth]

Hi tosiara, Great idea to extract this little "chunk" of motion to focus on. I'm learning a lot from you! I got similar results to you on my RPI 4B when I compiled ran "rotate.txt", however these results looked far too fast compared to "real" motion. I suspect something weird is happening where gcc is being very clever and realizing that although we're doing all this rotation, we're not actually using the results...perhaps it's optimizing the whole rotation operation away? I modified your "rotate.txt" so that img_data is initially filled with random data and the results of the rotation are added up and printed out at the end of the program. This way the rotation operations can't be easily optimized away. I also reduced ITERATIONS to 1000 rather than the 1,000,000 you originally had. Here's what I now see. (FYI "-O3" on ARM didn't work for me either) [rotate-v2.c.txt](https://github.com/Motion-Project/motion/files/7384652/rotate-v2.c.txt) ***@***.*** ~/src$5:gcc -g -O0 rotate-v2.c -o rotate-random-O0 ***@***.*** ~/src$5:time ./rotate-random-O0 Iterations 1000 Dimensions 1920 x 1080 Rot 90 : 17753 msec image_total = 1642298768 Rot 180 : 17906 msec image_total = 2898896536 Rot 270 : 17701 msec image_total = 4155494304 real 0m53.613s user 0m53.579s sys 0m0.001s ***@***.*** ~/src$5:gcc -g -O2 rotate-v2.c -o rotate-random-O2 ***@***.*** ~/src$5:time ./rotate-random-O2 Iterations 1000 Dimensions 1920 x 1080 Rot 90 : 22494 msec image_total = 1438487768 Rot 180 : 6032 msec image_total = 2707363536 Rot 270 : 22538 msec image_total = 3976239304 real 0m51.313s user 0m51.253s sys 0m0.020s Notice how some parts of the "O2" version are slower than the "O0" version? Anyway, I guess the point is that on ARM rotation is in fact slowing things down. Given that keeping images internally within motion unrotated is not a viable option I think the moral is that if you need to save CPU resources, you shouldn't be doing 90 or 270 degree rotation. Thanks again Tosiara! Berto.

On Thu, 14 Oct 2021, at 21:35, tosiara wrote: You can try this test app: rotate.txt <https://github.com/Motion-Project/motion/files/7345199/rotate.txt> This is a slightly modified motion code for rotation. My results on x86_64 are: `$ gcc -O0 -march=native rotate.c $ time ./a.out real 0m18,047s user 0m18,045s sys 0m0,000s $ gcc -O3 -march=native rotate.c $ time ./a.out real 0m0,002s user 0m0,000s sys 0m0,002s

`

on ARM results are a bit different, as there -O0 gives better results, than -O3 `$ gcc -O0 rotate.c $ time ./a.out real 0m0.300s user 0m0.268s sys 0m0.028s

`

With O3 ARM test is going forever — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3N3NBC66UO6JJRRMJ54RLUG2W5LANCNFSM4YOVF3TA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

Edit to remove text of rotate-v2.c