User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

RESOLVED: Macro-block buffering

Tue Sep 06, 2016 7:31 am

I'm using picamera to stream macro-blocks to another process for motion processing.

The video is running at 10 fps, but the other end of the stream is receiving 40 frames of macro-blocks every 4 seconds followed by 4s of silence, rather then a bolck every 0.1s.

Anyone experience why? Anyone with suggestions how I can get rid of this buffering?

Sample code to see what I mean is here: http://blog.pistuffing.co.uk/camera-mot ... king-code/

This is with the new camera and latest jessie lite.

TIA
Last edited by Hove on Tue Sep 06, 2016 7:19 pm, edited 1 time in total.
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

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

Re: Macro-block buffering

Tue Sep 06, 2016 9:36 am

I'd guess that it's file system buffering on the FIFO. Until the application closes a file handle or calls flush, the OS is not obliged to write it.1680 bytes/frame * 40 frames = 67200. 65536 is a nice power of 2 that will often be used for buffers.

My other thought is have you changed the resolution that the camera is capturing at? That code is fixed for 320x320, and the

Code: Select all

           frame = py_fifo.read(1680)
            if len(frame) != 1680:
                print "ERROR: incomplete frame received"
                break
code needs to be amended if you change the resolution.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 10:57 am

Hhmm - I hadn't spotted the 65536 - as you say, a good buffer size!

Resolution is permanently fixed at 320 x 320 as the minimum video frame size supported (at least for V1 of the camera). I had suspected buffering, but as the source is in the GPU effectively, there's no way I can change the code to flush. I need these samples at the 10Hz frame rate so that each can also use the current height to convert the macro-block vectors to lateral movement in meters. During a 4s delay, the height can change quite radically, making all the readings junk - each reading is an increment on the previous one, so effectively they are being integrated.

I don't suppose Gordon's got any ideas, has he, as the magician behind the camera?

Thanks
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 11:15 am

Just one additional thought - I believe it's possible to stream video live without this buffering on the senders side, so I presume there's a difference here between how the GPU outputs the video and macro-block data stream?
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

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

Re: Macro-block buffering

Tue Sep 06, 2016 11:21 am

Hove wrote:Resolution is permanently fixed at 320 x 320 as the minimum video frame size supported (at least for V1 of the camera).
Minimum frame size is 32x32 (increased recently from 16x16 due to issues), though a total of 4 macroblocks is unlikely to give you much useful information.
Hove wrote:I had suspected buffering, but as the source is in the GPU effectively, there's no way I can change the code to flush.
You're using PiCamera (ARM side). The data is presented to that, which in turn writes to the Linux FIFO (again ARM side). Neither are GPU side - that will be delivering frames as they are available as long as there are output buffers available.
Source for PiCamera available at https://github.com/waveform80/picamera with docs at http://picamera.readthedocs.io/en/release-1.12/ including instructions on how to rebuild.

You may be able to do a similar thing using raspivid, and there was a change to that to optionally add flushes - https://github.com/raspberrypi/userland ... 3afd5f0911.
Totally untested, but potentially

Code: Select all

raspivid -w 320 -h 320 -fps 10 -fl -t 0 -o /dev/null -x /dev/shm/motion_stream
Hove wrote: I need these samples at the 10Hz frame rate so that each can also use the current height to convert the macro-block vectors to lateral movement in meters. During a 4s delay, the height can change quite radically, making all the readings junk - each reading is an increment on the previous one, so effectively they are being integrated.

I don't suppose Gordon's got any ideas, has he, as the magician behind the camera?
Gordon normally juggles instead of performing magic ;)
Whilst he added the original motion vectors code, he hasn't touched it since. Camera and video encode support typically comes from me.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: Macro-block buffering

Tue Sep 06, 2016 11:24 am

http://man7.org/linux/man-pages/man7/pipe.7.html
In Linux versions before 2.6.11, the capacity of a pipe was the same
as the system page size (e.g., 4096 bytes on i386). Since Linux
2.6.11, the pipe capacity is 65536 bytes. Since Linux 2.6.35, the
default pipe capacity is 65536 bytes, but the capacity can be queried
and set using the fcntl(2) F_GETPIPE_SZ and F_SETPIPE_SZ operations.
See fcntl(2) for more information.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 11:30 am

Thanks for both responses, and apologies for crediting Gordon with your work!

I guess first step is to try to set the FIFO buffering to 0 or 1680 and see whether that solves the problem; failing that, it's a dig into the picamera code.

Thanks for the pointers.

Hove
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

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

Re: Macro-block buffering

Tue Sep 06, 2016 11:42 am

Do give the raspivid line a quick try - at least that is easy to do compared to rebuilding PiCamera.

http://unix.stackexchange.com/questions ... 5376#25376 implies the pipe will always wait until full before forwarding.
http://stackoverflow.com/questions/8287 ... -buffering likewise
Line buffered mode won't help as you're sending binary data, so there is no carriage return between writes.

You may want to raise an issue on https://github.com/waveform80/picamera/issues just to query with waveform80 the best place to add an optional flush. He's generally pretty responsive on there, and you could create a pull request with your fix if he thinks it will be useful to others.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 12:15 pm

6by9 wrote:Do give the raspivid line a quick try - at least that is easy to do compared to rebuilding PiCamera.
Will do and I'll report back later - it should be a trivial change to my motion.py code.
6by9 wrote: http://unix.stackexchange.com/questions ... 5376#25376 implies the pipe will always wait until full before forwarding.
http://stackoverflow.com/questions/8287 ... -buffering likewise
Line buffered mode won't help as you're sending binary data, so there is no carriage return between writes.
Thx
6by9 wrote: You may want to raise an issue on https://github.com/waveform80/picamera/issues just to query with waveform80 the best place to add an optional flush. He's generally pretty responsive on there, and you could create a pull request with your fix if he thinks it will be useful to others.
I actually e-mailed him earlier, but I'll follow the more formal way via gibhub as you suggest.

I owe you a beer for all your help - come along to the Cotswold Jam on 24th September to collect ;)
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 12:40 pm

6by9 wrote:Do give the raspivid line a quick try - at least that is easy to do compared to rebuilding PiCamera.
I can confirm raspivid is working perfectly as the source for the macro-blocks - the 1680 byte macro-blocks per frame are delivered at 10 fps intervals as required. So this is a viable solution, thanks.

I will follow up on the picamera solution too though, as one of my targets for this quadcopter project is "pure python is possible".

P.S. Yes, I'm the guy to set the lecture hall on fire at the birthday party!
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: Macro-block buffering

Tue Sep 06, 2016 7:18 pm

waveform80 got in touch via e-mail and there's an existing solution:
So, in your case instead of this:

camera.start_recording(
'/dev/null', format='h264',
motion_output="/dev/shm/motion_stream", quality=23)

You want something like this (this assumes Python 3's variant of open; if you're on Python 2, use the "io" library's open() function instead):

output = open('/dev/shm/motion_stream', 'wb', buffering=0)
try:
camera.start_recording(
'/dev/null', format='h264', motion_output=output,
quality=23)
# wait_recording, etc.
finally:
camera.stop_recording()
output.close()

Basically, when people give picamera a filename (as opposed to a file-like object), I have to make a judgement call and open the file in a way that fits the majority use case. The majority use case is "I don't want to bash every minor write onto the SD card and drastically reduce its performance and lifespan", so the default has to include a fairly substantial amount of buffering. That's the logic behind the default.

However, there's plenty of perfectly good use cases (like yours) in which buffering is a problem - hence why you can pass any file-like object to picamera and it'll happily write to it like any other output.
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Thu Jun 29, 2017 1:18 pm

Hello everyone (first post). :D

And thanks for writing about your work - it has been helpful to read. :D I first read Gordon's post with the juggling GIF, then later found Hove's blog about drones and finally stumbled here.

I've got a somewhat different (yet similar) situation, which I've solved (well, half-solved) differently too.

The background: I'm preparing for Robotex (a robotics contest by the Tallinn Technical University, in Tallinn, Estonia), and the task is to fly (as fast as possible) above a number 8 pattern while avoiding plastic poles. My "drone" is not an actual drone but a wingless plane with massive independently movable tail surfaces and two (ducted, vertically stacked) coaxial propellers (run by brushless outrunner motors via a common controller for perfect synchronization, so yaw is changed not via RPM but with tail surfaces)...

...anyway, I'm using "raspivid" and writing in Java instead of C or Python. I'm using a tiny frame size at the moment (200 x 112 pixels) and my program is consuming both video frames and the motion vectors.

Video frames go into a fairly complicated "gstreamer" pipeline which splits the stream, decompresses raw GRAY8 images for local consumption, wraps H264 data in RTP packets over UDP and dispatches those to a desktop "flight control" program, which in turn receives data using "gstreamer", decompresses H264 into RGB24 color images and displays them in an AWT user interface with telemetry (received via another UDP socket) drawn on top.

Code: Select all

Sending side pipeline:
raspivid -n -t 0 -w 200 -h 112 -b 500000 -fps 30 -ex auto -pf baseline \
-o - -x ! | \
gst-launch-1.0 -v fdsrc fd=0 ! h264parse ! tee name=splitter ! \
queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=$1 port=9000 \
splitter. ! queue ! avdec_h264 ! decodebin ! \
videoconvert ! video/x-raw,format=GRAY8 ! fdsink fd=1

Code: Select all

Receiving side pipeline:
gst-launch-1.0 -v udpsrc port=9000 \
caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! \
rtph264depay ! avdec_h264 ! decodebin ! videoconvert ! video/x-raw,format=RGB ! fdsink fd=1
What I stumbled on: since frames and vectors cannot be both output via "stdout", I tried for a while to output vectors via UDP and video via "stdout"... and alas, the UDP stream lagged behind everything else catastrophically.

My solution was to alter "raspivid" sources and do as follows:

Code: Select all

if (state.imv_filename)
{
    if (state.imv_filename[0] == '-')
    {
        state.callback_data.imv_file_handle = stdout;
    }
+++ else if (state.imv_filename[0] == '!')
+++ {
+++ state.callback_data.imv_file_handle = stderr;
+++ }
    else
    {
        state.callback_data.imv_file_handle = open_filename(&state, state.imv_filename);
    }
So basically, I gave "raspivid" the ability to send vectors to "stderr" and my code then reads both "stdout" and "stderr" to get fast (and usually synchronous) access to video frames and motion vectors. :D

I haven't done any fancy flying yet, but thought I'd share this bit anyway.

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

Re: RESOLVED: Macro-block buffering

Thu Jun 29, 2017 2:01 pm

cpunk wrote:So basically, I gave "raspivid" the ability to send vectors to "stderr" and my code then reads both "stdout" and "stderr" to get fast (and usually synchronous) access to video frames and motion vectors. :D

I haven't done any fancy flying yet, but thought I'd share this bit anyway.
Writing to stderr is likely to have issues, as any error or status messages go there.

The typical reason behind network traffic lagging is that Linux sees it as a file, and inherently buffers all file writes as big blocks are generally good, however they add latency. That's what most of this thread with Hove has been about.
There is already the -f / --flush option in raspivid that should flush the file descriptor after every write, which should trigger any buffered data to be sent. That should improve the latency on the main pipe to stdout too, although the typical 64kB buffer gets filled fairly quickly with compressed video so you may not have noticed it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Hove
Posts: 1204
Joined: Sun Oct 21, 2012 6:55 pm
Location: Cotswolds, UK
Contact: Website

Re: RESOLVED: Macro-block buffering

Thu Jun 29, 2017 2:35 pm

You can get around buffering on Python 2 by using io, so instead of using file = open(filename), you import io and do file = io.open(filename, buffering = 0) - has worked perfectly for me.
www.pistuffing.co.uk - Raspberry Pi and other stuffing!

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Thu Jun 29, 2017 2:37 pm

Thanks for reminding, I will definitely try the -f option for comparison! :)

Until now, I have lacked a framework for measuring latency properly, but I just rediscovered the old trick of filming my laptop's screen while it's displaying a running stopwatch. That should help figure out how much effect -f has for me. :)

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Wed Jul 05, 2017 9:17 pm

So I realized that I cannot measure the speed improvement gained from the -f option without other onboard sensors - I'd be measuring my own network latency. Unfortunately, other onboard sensors are not ready yet (well, there is a Scanse Sweep here too, and a mirror system for conical scanning is being built, but it won't help the slightest bit to sync events up).

However, 256 x 256 pixel video frames are now obtained at 30 fps, analyzed onboard pretty fast, and telemetry (slightly filtered motion vectors) gets drawn onto them on the ground station in an almost tolerable manner (it flickers a bit, but telemetry arrives in sync with frames, both delayed by network latency by the same amount of time) and with a bit of handwaving, it might pass as a working prototype. :D

(I apologize, my Java code is currently a mess, it is not fit for sharing since I barely know how I got it this far. :P I'll be improving it well until autumn.)
screenshot.png
handwaving :)
screenshot.png (60.74 KiB) Viewed 1916 times
)

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sat Jul 08, 2017 9:09 pm

A side note about 50Hz (especially LED, since LEDs respond fast) lamps and featureless single-color surfaces... that's a recipe for confusion. This is likely due to the cyclic nature of ceiling lights. They brighten and dim with AC current in the electrical grid, and the brightening and dimming cycles most likely get interpreted by the GPU as motion. This behaviour seems specific to featureless surfaces. As soon as a surface has significant features (e.g. furniture) the effect disappears.

To deal with this, I'm currently filtering vectors by length and angle, discarding all multiples of right angles, all vectors insignificantly short or outrageously long. I have the feeling that I should be doing it smarter, but since I'm not the best or brightest coder, I go for low-hanging solutions first. :P

I will also take another look into SAD values, perhaps the right-angled pseudo-motion has easily recognizable sums of difference. I would have difficulty doing any filtering in the time (as opposed to space) domain, but eventually I guess I should.
Attachments
50_hz_led_lights_unfiltered_and_filtered.png
unfiltered and filtered, without real motion
50_hz_led_lights_unfiltered_and_filtered.png (50.19 KiB) Viewed 1875 times
Last edited by cpunk on Sat Jul 08, 2017 9:24 pm, edited 5 times in total.

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sat Jul 08, 2017 9:12 pm

P.S. And here's a frame with real motion - first unfiltered and then filtered.
Attachments
50_hz_led_lights_and_hand_filtered_unfiltered.png
unfiltered and filtered, with real motion present in frame
50_hz_led_lights_and_hand_filtered_unfiltered.png (61.27 KiB) Viewed 1874 times

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sat Jul 08, 2017 9:44 pm

Update: unfortunately, the SAD values of vectors passing through my filter and getting dropped by the filter, are too close to each other. Their ranges overlap and I would be unable to separate them manually, so I can't find an efficient algorithm to do that.

I guess the next stop for me is consolidating vectors into areas or polygons, and then time-domain filtering ("things which flicker in and out of existence can't be real").

I will probably go for some algorithm which assigns scores to features basing on how long they have "continuously" existed, continuity being defined by another score based on overlapping rectangles or something. It will get messy, but I need it anyway for landmark-based navigation.

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

Re: RESOLVED: Macro-block buffering

Sun Jul 09, 2017 6:26 am

There is a mmal parameter that enables the flicker avoidance within the ae algorithm. Simplistic approach is that it always uses an exposure time that is a multiple of the mains half cycle period.
IIRC picamera has it available as a simple parameter.

Worth a quick try anyway.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sun Jul 09, 2017 2:03 pm

Thank you for yet another useful tip! :)

I now have code to contribute (besides the ! argument for dumping vectors to "stderr" -- which is indeed bad style, yet incredibly useful to me personally... I understand if nobody wants it into distribution code, though I can offer to add protective code to totally disable status messages in case a user has chosen to use "stderr" for data).

The code I wrote today alters "RaspiCamControl.h, RaspiCamControl.c, RaspiVid.c". Essentially, it gives the user a command line option to control if the MMAL parameter you mentioned gets passed, and what value gets passed (out of "off", "auto", "50hz", "60hz" and "max").

Against my personal ceiling lights, only the "auto" (it seems to learn after flicker first occurrs) and "50hz" options have any effect (confirmed visually, for testing how it affects motion vectors, I will have to wait until evening). What the "max" option does, I don't even know, but to me, it doesn't seem to do anything. :)

The diff is here:

https://pastebin.com/fNjnEGrd

Also, maybe I should ask... is there a standard or preferred way of contributing patches to "raspicam" and assorted tools?

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

Re: RESOLVED: Macro-block buffering

Sun Jul 09, 2017 2:25 pm

cpunk wrote:I now have code to contribute (besides the ! argument for dumping vectors to "stderr" -- which is indeed bad style, yet incredibly useful to me personally... I understand if nobody wants it into distribution code, though I can offer to add protective code to totally disable status messages in case a user has chosen to use "stderr" for data).

The code I wrote today alters "RaspiCamControl.h, RaspiCamControl.c, RaspiVid.c". Essentially, it gives the user a command line option to control if the MMAL parameter you mentioned gets passed, and what value gets passed (out of "off", "auto", "50hz", "60hz" and "max").
MMAL_PARAM_FLICKERAVOID_MAX = 0x7FFFFFFF
"max" is there to make sure the compiler treats the enum as a 32bit value. Without it compilers can differ in the variable size used for the enum, and that is not a good thing when writing an interprocessor comms API.
cpunk wrote:Against my personal ceiling lights, only the "auto" (it seems to learn after flicker first occurrs) and "50hz" options have any effect (confirmed visually, for testing how it affects motion vectors, I will have to wait until evening). What the "max" option does, I don't even know, but to me, it doesn't seem to do anything. :)
I'd have to check on auto as to whether the decent learning algorithm reached the Pi branch. "max" - see above.
cpunk wrote:The diff is here:

https://pastebin.com/fNjnEGrd
Looks good, although you shouldn't need to add command line parsing for your new parameter to both RaspiCamControl and RaspiVid. The former should be used by all the raspicam apps, just be careful to find a command line name and shortcut that is unique across all apps.
The "max" option also needs to be dropped.
cpunk wrote:Also, maybe I should ask... is there a standard or preferred way of contributing patches to "raspicam" and assorted tools?
Make your own fork of https://github.com/raspberrypi/userland, push your alterations to it, and then create a pull request. It'll then get reviewed, potentially changes requested, and merged.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sun Jul 09, 2017 2:36 pm

Thanks, will do. :) As for the duplication of command line parsing, I'll see how other apps are doing it. For some reason, on first attempt, I couldn't understand it properly.

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sun Jul 09, 2017 4:37 pm

Took some time (new tools) but pull request created. :) I found a seemingly better place for the structure I had duplicated before, but whether it was the right place, no idea. :)

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: RESOLVED: Macro-block buffering

Sat Jul 15, 2017 2:59 pm

Out of curiosity, what are you using for the "-ex" option, Hove?

I only today found out that "-ex auto" causes (again via changes in brightness) motion vectors to be generated which do not represent real motion (just like lamp flicker does). After setting it to "off" instead of "auto" (and establishing fixed values for brightness and contrast), I'm getting almost-nice results at 320 x 320 @30 fps.

P.S. The attachment depicts tracking a rotor with colorful sponge paddles, which I can do pretty reliably by this point.
Attachments
nice.png
nice.png (58.81 KiB) Viewed 1648 times

Return to “Camera board”

Who is online

Users browsing this forum: No registered users and 15 guests