User avatar
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

v2 camera raspivid average captured framerate (640x480, mode 7)

Fri Jan 18, 2019 3:21 pm

In thread "v2 camera raspivid now captures up to 200fps ..."
https://www.raspberrypi.org/forums/view ... 3&t=206047

I did verify that indeed v2 camera can capture up to 200fps with raspivid.
I used tool ptsanalyze for that:
https://github.com/Hermann-SW/userland/ ... ptsanalyze

The tool does frame delta distribution analysis, determines framerate based on most often found frame delta and reports number of frame skips as well as lists those.

What the tool did not do was to determine the avarage framerate of the recorded video (from file generated by "--save-pts" and "-o" options).
The 1st line of the generated file is a comment, and the 1st timestamp in 2nd line seems to be always 0.000.
New tool "afps" does it safely and determines average framerate by dividing difference of last and first timestamp by lines of file minus 2:

Code: Select all

$ cat afps
#!/bin/bash
if [ "$1" = "" ]; then echo "$0 file.pts"; exit; fi

i=$((`wc --lines $1 | cut -f1 -d\ ` - 2))
f=`head -2 $1 | tail -1`
l=`tail -1 $1`
echo "1000/(($l-$f)/$i)" | bc -ql | sed "s/\([0-9]*\.[0-9][0-9]\).*/\1/"
$

I did a quick loop and recorded with each framerate for 10 seconds.
For all framerates from 60fps to 139 fps you get slightly more than you requested, 0.16 at minimum.

Next I did similar loop for all framerates in range 140fps up to 200fps.

Code: Select all

$ for((f=140; f<=200; ++f)); do raspivid -md 7 -w 640 -h 480 -pts tst.pts -p 100,80,640,480 -t 10000 -fps $f -o tst.h264; echo $f,`./afps tst.pts`; done
140,140.58
141,141.46
142,142.53
143,143.23
144,144.24
145,145.26
146,146.41
147,147.15
148,148.00
149,149.20
150,149.78
151,150.46
152,151.26
153,152.21
154,152.95
155,153.79
156,154.83
157,155.29
158,155.66
159,155.83
160,154.92
161,155.62
162,154.93
163,155.76
164,155.49
165,155.55
166,156.01
167,157.21
168,158.01
169,158.67
170,158.28
171,158.91
172,158.95
173,159.55
174,159.54
175,160.31
176,159.64
177,159.60
178,159.45
179,159.78
180,160.60
181,161.36
182,160.75
183,160.02
184,160.28
185,159.61
186,158.90
187,158.73
188,159.59
189,158.59
190,157.29
191,157.73
192,158.65
193,158.36
194,158.65
195,158.71
196,158.87
197,159.08
198,158.21
199,158.43
200,157.27
$

The first framerate where you get slightly less than requested is 150fps (you get 149.78fps).
Here is chart generated from above data:
Image


The maximal average framerate is 161.36fps for requested framerate 181fps.
The measurements were done on a Pi 3B+ with 15cm flat ribbon cable to connect v2 camera.
I did repeated evaluations around this framerate and they reported stable results, this time with maximum for 180fps requested:

Code: Select all

[email protected]:~ $ for((f=179; f<=182; ++f)); do raspivid -md 7 -w 640 -h 480 -pts tst.pts -p 100,80,640,480 -t 10000 -fps $f -o tst.h264; echo $f,`./afps tst.pts`; done
179,159.21
180,161.15
181,160.69
182,161.17
[email protected]:~ $ for((f=179; f<=182; ++f)); do raspivid -md 7 -w 640 -h 480 -pts tst.pts -p 100,80,640,480 -t 10000 -fps $f -o tst.h264; echo $f,`./afps tst.pts`; done
179,159.82
180,161.02
181,160.35
182,161.62
[email protected]:~ $ for((f=179; f<=182; ++f)); do raspivid -md 7 -w 640 -h 480 -pts tst.pts -p 100,80,640,480 -t 10000 -fps $f -o tst.h264; echo $f,`./afps tst.pts`; done
179,160.13
180,161.06
181,160.89
182,160.71
[email protected]:~ $ 

In the past most times I used framerate 180fps with v2 camera raspivid, seems I was lucky.

For high framerate raspiraw capturing (up to 1007fps with v2 camera) I typically select regions of the recorded frames without any frame skips (with raw2ogg2anim tool), which means the captured average framerate for those regions is slightly above the requested.


P.S:
I did one 10s capture with 180fps requested, and did ptsanalyze the data.
191 frameskips (10%), with 1587 frames captured mostly at 180fps, 161.37fps on average:

Code: Select all

[email protected]:~ $ raspivid -md 7 -w 640 -h 480 -pts tst.pts -p 100,80,640,480 -t 10000 -fps 180 -o tst.h264
[email protected]:~ $ ./afps tst.pts161.37
[email protected]:~ $ ptsanalyze tst.pts 0
creating tstamps.csv
1587 frames were captured at 180fps
frame delta time[us] distribution
      1 5515
      1 5516
      1 5517
      1 5518
      4 5519
      4 5522
      1 5523
      1 5524
      4 5525
     12 5526
     34 5527
     82 5528
    140 5529
    334 5530
    393 5531
    197 5532
    104 5533
     34 5534
     20 5535
      8 5536
      1 5537
      3 5538
      1 5539
      2 5540
      1 5541
      1 5542
      5 5544
      2 5545
      1 5548
      1 11042
      1 11054
      1 11055
      2 11056
      1 11057
      8 11058
     18 11059
     38 11060
     60 11061
     33 11062
     23 11063
      3 11064
      1 11065
      1 11066
after skip frame indices (middle column)
> 11060,116144
> 11060,154857
> 11062,210166
> 11061,232286
> 11060,304184
> 11065,342902
> 11063,392677
> 11060,453511
> 11058,486696
> 11061,564124
> 11060,580716
> 11062,674737
> 11061,730043
> 11062,763227
> 11063,790881
> 11061,862778
> 11060,901492
> 11061,956799
> 11061,1012105
> 11061,1050819
> 11061,1106126
> 11061,1144840
> 11060,1189085
> 11062,1227800
> 11061,1321820
> 11062,1360535
> 11062,1399249
> 11061,1454554
> 11061,1487738
> 11062,1504331
> 11058,1565167
> 11063,1603883
> 11062,1675780
> 11063,1780863
> 11063,1869355
> 11058,1924658
> 11064,1957843
> 11062,2002088
> 11059,2057393
> 11061,2112699
> 11059,2151414
> 11061,2223311
> 11060,2239904
> 11063,2333925
> 11058,2422414
> 11062,2444537
> 11062,2516436
> 11059,2555149
> 11058,2604925
> 11061,2665761
> 11060,2698946
> 11061,2743191
> 11062,2781905
> 11062,2853804
> 11062,2892518
> 11060,2947825
> 11062,2981008
> 11059,3025253
> 11063,3080560
> 11061,3119273
> 11061,3174581
> 11057,3229885
> 11060,3268600
> 11059,3340497
> 11061,3357090
> 11060,3451112
> 11060,3473232
> 11058,3539601
> 11061,3567253
> 11062,3639153
> 11060,3677866
> 11061,3733173
> 11042,3788478
> 11060,3827193
> 11061,3882500
> 11063,3915684
> 11060,4004173
> 11061,4048419
> 11060,4098194
> 11061,4142439
> 11061,4192215
> 11061,4236459
> 11061,4286235
> 11059,4347071
> 11063,4385789
> 11060,4457684
> 11063,4474278
> 11061,4551705
> 11059,4573827
> 11059,4662318
> 11056,4717623
> 11059,4750808
> 11060,4795052
> 11059,4844829
> 11060,4905665
> 11059,4938850
> 11060,5016278
> 11061,5032870
> 11059,5126889
> 11062,5215380
> 11062,5237504
> 11061,5309401
> 11061,5348115
> 11060,5397891
> 11061,5458728
> 11061,5497443
> 11058,5563809
> 11061,5585932
> 11063,5646771
> 11062,5679953
> 11062,5773975
> 11062,5796096
> 11061,5862464
> 11062,5906709
> 11061,5956486
> 11056,6017320
> 11061,6050507
> 11063,6127934
> 11060,6144526
> 11060,6238549
> 11060,6277261
> 11060,6332566
> 11061,6421059
> 11060,6459771
> 11061,6515077
> 11060,6553793
> 11060,6609098
> 11061,6664404
> 11061,6697588
> 11061,6758425
> 11063,6791609
> 11061,6852447
> 11061,6885629
> 11061,6913282
> 11061,6968588
> 11063,6985181
> 11061,7029425
> 11061,7068140
> 11059,7140038
> 11063,7173224
> 11061,7234059
> 11060,7272773
> 11062,7344672
> 11058,7361263
> 11059,7455284
> 11062,7477406
> 11063,7549306
> 11059,7588019
> 11061,7637795
> 11060,7698631
> 11061,7731815
> 11060,7803713
> 11061,7825836
> 11062,7886675
> 11062,7919856
> 11064,8013880
> 11062,8036000
> 11063,8107899
> 11061,8146611
> 11066,8201922
> 11059,8251693
> 11063,8290411
> 11061,8367837
> 11064,8384431
> 11063,8472922
> 11063,8517167
> 11059,8572470
> 11063,8594594
> 11059,8660961
> 11060,8705205
> 11060,8760512
> 11062,8815818
> 11055,8854532
> 11060,8926431
> 11062,8943023
> 11061,9003858
> 11062,9042574
> 11061,9131064
> 11062,9169779
> 11062,9219554
> 11060,9263799
> 11061,9319105
> 11061,9374411
> 11060,9407596
> 11060,9485023
> 11061,9501616
> 11063,9595639
> 11061,9667535
> 11054,9706249
> 11063,9778149
> 11062,9816862
191 frame skips (10%)
[email protected]:~ $

P.P.S:
I did several runs with 150fps, all resulting in >=149.57fps average framerate.
For the last few runs I did run pts analyze, 1473 frames were recorded at 150fps requested framerate, 9 frameskips.
I had to go down to 140fps requested framerate to get runs with 0 frameskips.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: v2 camera raspivid average captured framerate (640x480, mode 7)

Sat Jan 19, 2019 8:55 pm

I wanted to get higher average framerates with raspivid and studied the available options:
https://www.raspberrypi.org/documentati ... /camera.md


For very high framerate raspiraw capturing the rule of thumb is:
half the vertical resolution and get double the framerate

So I first did try to make use of "-roi" option (region of interest).
That did not result in any (average) framerate increase.

Then I stumbled over v2 camera mode table remark 1 for mode 7:
1For frame rates over 120fps, it is necessary to turn off automatic exposure and gain control using -ex off. Doing so should achieve the higher frame rates, but exposure time and gains will need to be set to fixed values supplied by the user.
This is the diagram generated by for loop as above with "-ex off" added to raspivid command (see axis labels in previous diagram):
Image

That gave much better results!
The first framerate that did get slightly less average framerate than requested is 170fps (instead of 150fps before).
I had to go down to 162fps for runs with 0 frameskips (140fps before).
Maximal average framerates are slightly more than 185fps (160fps before).


If I could reduce the number of rows captured/processed as with raspiraw there would be no problem at all to reach 200fps framerate without frameskips ...
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: v2 camera raspivid average captured framerate (640x480, mode 7)

Mon Jan 21, 2019 9:10 am

HermannSW wrote:
Sat Jan 19, 2019 8:55 pm
If I could reduce the number of rows captured/processed as with raspiraw there would be no problem at all to reach 200fps framerate without frameskips ...
Last night I found a solution to easily prototype in that direction.

The black parts of this diagram are the standard mode of raspivid operation (rectangular parts are HW, ellipses are commands). raspivid sends commands to GPU, GPU sends I2C commands against camera, camera sends raw video stream over CSI-2 interface back to GPU, and finally processed video gets displayed on HDMI monitor:
Image

Last year I did fork 6by9's userland branch and added the red component. I made raspivid send i2C comands to camera after camera was already streaming video to the GPU. I did this to prove that mode=7 (640x480) maximal framerate of 120fps at that time was too low by showing that v2 camera easily could process mode=7 video at 180fps. In current raspivid the limit is increased to 200fps because of that :
https://github.com/Hermann-SW/userland

I did add other options to my fork, first a "shutter" mode that allowed every other frame of a video being captured with a different shutter value:
https://www.raspberrypi.org/forums/view ... 4#p1313054
Image

And lately an experimental "single camera stereoscopic" option, where the view captured toggles for every other frame:
https://www.raspberrypi.org/forums/view ... 3&t=230312
Image


6by9 said that sending I2C commands while recording is in process is not a good idea, because of possible I2C bus clashes and because the GPU has no idea of what I2C commands have been sent to camera bypassing GPU. I never have seen clashes, and all three cases I described above did work fine for me though.


The new solution I have developed just now is shown in this diagram (1057 byte long Graphviz "Share" URL allowing to see+edit the diagram in your browser):
Share link
Image


This solution allows to work with current raspivid without any modifications. While raspivid command is started in background, new command "lft" is executed while raspivid is running and sends I2C command to camera. As first example I just took the register changes uses in experimental single camera stereoscopic option for changing the horizontal view.

This is the command execution:

Code: Select all

[email protected]:~ $ gcc -Wall -pedantic lft.c -o lft
[email protected]:~ $ 
[email protected]:~ $ raspivid -md 7 -w 640 -h 480 -pts tst.pts -t 3000 -fps 100 -o tst.h264 &
[1] 2722
[email protected]:~ $ ./lft /dev/i2c-0 800
[email protected]:~ $ 
This is the video uploaded to youtube, because it is recorded at 100fps and played at 25fps, the video is 4 times as long there than real. After 6s in the video the horizontal view changes:
https://www.youtube.com/watch?v=8CWs2PW ... e=youtu.be

And this is the simple "lft.c" code, I am still surprised how easy it is (only 36 lines of code):

Code: Select all

#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>

#define I2C_SLAVE_FORCE 0x0706
#define WRITE_I2C(fd, arr)  (write(fd, arr, sizeof(arr)) != sizeof(arr))

int main(int argc, char *argv[])
{
    int  i2c_fd = 0;
    char *i2c_device_name;

    assert(argc==3);
    i2c_device_name = argv[1];

    i2c_fd = open(i2c_device_name, O_RDWR);
    assert(i2c_fd);
    assert(ioctl(i2c_fd, I2C_SLAVE_FORCE, 0x10) >= 0);

        unsigned lft, nwidth, end;

        lft = atoi(argv[2]);
        nwidth = 640*2;
        end = lft + nwidth - 1;

        unsigned char msg[] = {0x01, 0x64, lft>>8, lft&0xFF, end>>8, end&0xFF};

        assert( WRITE_I2C(i2c_fd, msg)==0 );

    if (i2c_fd) 
        close(i2c_fd);

    return 0;
}

For other options the initial code and final code will be identical, the middle part is what does affect the camera.
Compute new left and right border in 0..3279 range and send the I2C command for requesting that new view:

Code: Select all

        unsigned lft, nwidth, end;

        lft = atoi(argv[2]);
        nwidth = 640*2;
        end = lft + nwidth - 1;

        unsigned char msg[] = {0x01, 0x64, lft>>8, lft&0xFF, end>>8, end&0xFF};

        assert( WRITE_I2C(i2c_fd, msg)==0 );

Next steps: try to reduce recorded view number of lines from 480 to 400 or 360 in order to go for 200fps raspivid recording without a single frame skip!

P.S:
For working with v2 camera Sony IMX219 datasheet is helpful:
https://github.com/rellimmot/Sony-IMX21 ... Pi-V2-CMOS
Last edited by HermannSW on Mon Jan 21, 2019 11:34 am, edited 1 time in total.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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: v2 camera raspivid average captured framerate (640x480, mode 7)

Mon Jan 21, 2019 11:06 am

The problem isn't that you are accessing i2c-0 from raspivid, it is accessing i2c-0 at all!

You have one hardware block (Broadcom Serial Controller 0, or BSC0), and two processors (the ARM and GPU).

Code: Select all

GPU    -> +------+
  ^       |      |
  +-int<- | BSC0 | -> I2C to sensor
  v       |      |
ARM    -> +------+
If both processsors have opened the device simultaneously, then both have registered their interrupt handlers.
When an interrupt occurs, the interrupt line is wired to both of them. Whichever responds first will service it. If that processor had no outstanding transaction then it'll reset the interrupt and wonder what happened to trigger it. The other processor will then try servicing the interrupt and find nothing to do. Should it be the interrupt on having sent the first byte of a command that gets lost, then the other bytes won't get sent (or possibly only on timeout).
The other alternative is that one processor has sent 1 byte of N, at which point the other processor decides it needs to send something. It believes the peripheral to be idle as it isn't sending anything with it, so stuffs bytes into the FIFO. You now have two intermixed commands.

I'm happy that appears to be working for you, but it can not be recommended in anything other than very tightly controlled conditions.
There have also been requests from upstream that the VPU will never use BSC0 if it finds it configured in device tree. I'm not convinced by that one as there are a number of times where it is useful (eg alternating raspivid and raspiraw), but it may happen in the future. We already do a similar thing around other blocks for switching to Eric's driver, or the Unicam driver.
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
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: v2 camera raspivid average captured framerate (640x480, mode 7)

Mon Jan 21, 2019 6:00 pm

6by9 wrote:
Mon Jan 21, 2019 11:06 am
The other alternative is that one processor has sent 1 byte of N, at which point the other processor decides it needs to send something. It believes the peripheral to be idle as it isn't sending anything with it, so stuffs bytes into the FIFO. You now have two intermixed commands.
This is no problem for lft.c since the asserts make sure that always the full number of bytes are sent over I2C. If execution was successful we know all is fine.
I'm happy that appears to be working for you, but it can not be recommended in anything other than very tightly controlled conditions.
I will use this method only to change few registers for a specific purpose once.
Should be much less risky than what I described above for shutter and stereographic options.
There every frame did change register settings over I2C bus.
And I have never ever seen any problem you describe.

In order to investigate the size of timeframe where lft.c accesses I2C at all I added timestamp taking and reporting of delta time:

Code: Select all

$ diff lft.c lftT.c 
5a6,7
> #include <stdio.h>
> #include <time.h>
13a16
>     struct timespec t0, t1;
17a21,22
>     assert( 0 == clock_gettime(CLOCK_REALTIME, &t0) );
> 
33a39,42
> 
>     assert( 0 == clock_gettime(CLOCK_REALTIME, &t1) );
> 
>     printf("%ldns\n", 1000000000*(t1.tv_sec - t0.tv_sec) + t1.tv_nsec - t0.tv_nsec);
$

As you can see the timeframe is really minimal, only 1.2ms!

Code: Select all

[email protected]:~ $ gcc -Wall -pedantic lftT.c -o lftT
[email protected]:~ $ raspivid -md 7 -w 640 -h 480 -pts tst.pts -t 10000 -fps 100 -o tsta.h264 &
[1] 1186
[email protected]:~ $ ./lftT /dev/i2c-0 800
1204303ns
[email protected]:~ $ 
Attachments
lftT.zip
contains lftT.c
(653 Bytes) Downloaded 20 times
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: v2 camera raspivid average captured framerate (640x480, mode 7)

Thu Jan 24, 2019 11:18 am

Above I did show how to modify horizontal view of a running raspivid video capturing (lft.c).

Now I wanted to modify vertical view as next step, but wanted to use a simpler method for prototyping. First I thought on using i2cget and i2cset, but that seemed to be too complicated. I was interested in some kind of register dump and a method to overwrite many registers in a single go. Therefore I created i2cread.c and i2cwrite.c (attached, short code based on lft.c, 44/40 lines only). This is the modified operational diagram:
Share link
Image


And this is example usage for reading 12 registers containing horizontal start/end, vertical start/end and horizontal #rows, vertical #rows from v2 camera from running v2 raspivid capturing, then moving view down by 512 pixels and finally 256 up again using i2cwrite, followed by i2cread for verifying that i2cwrite did work:

Code: Select all

$ raspivid -md 7 -w 640 -h 480 -pts tstv.pts -t 10000 -fps 100 -o tstv.h264 &
[1] 2775
$ ./i2cread /dev/i2c-0 0164 0c
03 e8 08 e7 02 f0 06 af 02 80 01 e0 
$ ./i2cwrite /dev/i2c-0 0168 04 f0 08 af
$ ./i2cwrite /dev/i2c-0 0168 03 f0 07 af
$ ./i2cread /dev/i2c-0 0164 0c
03 e8 08 e7 03 f0 07 af 02 80 01 e0 
$ 

Horizontal view start and end are 1280-1 pixels apart (640 columns with 2x2 binning):

Code: Select all

$ echo -e "ibase=16\n03E8\n08E7" | bc -q
1000
2279
$ 

Vertical view start and end are 960-1 pixels apart (480 rows with 2x2 binning):

Code: Select all

$ echo -e "ibase=16\n02F0\n06AF" | bc -q
752
1711
$  

Horizontal and vertical #rows:

Code: Select all

$ echo -e "ibase=16\n0280\n01E0" | bc -q
640
480
$ 

The captured 10s 100fps video plays at 25fps on youtube, 4 times slower than real.
The vertical change by 1st i2cwrite command happens after 16s, the 2nd vertical change after 25s.
Pausing youtube video and single frame stepping fore/back with "."/"," keys shows that the frame before as well after a vertical view change are perfectly normal:
https://www.youtube.com/watch?v=zdbIeEo ... e=youtu.be

P.S:
Changing horizontal and vertical view while raspivid captures video is nothing special, picamera can do so as well during recording:
https://www.raspberrypi.org/forums/view ... 4#p1417454
Attachments
i2creadwrite.zip
contains i2cread.c and i2cwrite.c
(1.21 KiB) Downloaded 21 times
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1307
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: v2 camera raspivid average captured framerate (640x480, mode 7)

Thu Jan 24, 2019 11:03 pm

HermannSW wrote:
Thu Jan 24, 2019 11:18 am
P.S:
Changing horizontal and vertical view while raspivid captures video is nothing special, picamera can do so as well during recording:
https://www.raspberrypi.org/forums/view ... 4#p1417454
Thinking on this again, it is not the same.
raspivid as well as picamera allow to zoom to any part, but because all parameters have to be between 0 and 1, both can only show parts of the mode 7 area (1000,752)...(2279,1751). But the vertical replacement shown in previous posting leaves that area, any 2*640x2*480 area in (0,0)..(3279,2463) can be recorded from.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

Return to “Camera board”