gregeric
Posts: 1509
Joined: Mon Nov 28, 2011 10:08 am

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 4:16 pm

@ethanol100 I have -ex sports - w 640 -h 480 -fps 120, writing just one line of 640 pixels to (overclocked) SD card per frame.

I had tested the MMAL_PARAMETER_ZERO_COPY tweak (inserted before the buffer pool is created), with results not improved, but that was before I tweaked the number of buffers. Will try again on that one.

@jbeale I'm using raspividyuv, there is no compression, other than the fixed 480:1 compression I attain by throwing away 479 of the lines...

With some more (longer) recordings I can see the framerate bouncing up & down. There don't appear to bed dropped frames, the pts suggest the framerate is slowly changing (to my non-expert eye).

ethanol100
Posts: 586
Joined: Wed Oct 02, 2013 12:28 pm

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 5:09 pm

Which duration do you want to record, I just tested a minute and got full 120fps for that.

My code used was a modified version of raspividyuv:

Code: Select all

diff --git a/host_applications/linux/apps/raspicam/RaspiVidYUV.c b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
index a8bc4c7..7d5061d 100644
--- a/host_applications/linux/apps/raspicam/RaspiVidYUV.c
+++ b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
@@ -119,6 +119,7 @@ typedef struct
    FILE *file_handle;                   /// File handle to write buffer data to.
    RASPIVIDYUV_STATE *pstate;           /// pointer to our state in case required in callback
    int abort;                           /// Set to 1 in callback if an error occurs to attempt to abort the capture
+   FILE *pts_file_handle;               /// File timestamps
 } PORT_USERDATA;
 
 /** Structure containing all state information for the current run
@@ -153,6 +154,13 @@ struct RASPIVIDYUV_STATE_S
    int cameraNum;                       /// Camera number
    int settings;                        /// Request settings from the camera
    int sensor_mode;                     /// Sensor mode. 0=auto. Check docs/forum for modes selected by other values.
+   int frame;
+   char *pts_file;
+   int save_pts;
+   int64_t starttime;
+   int64_t lasttime;
+   int zero_copy;
+   int line_mode;
 };
 
 static XREF_T  initial_map[] =
@@ -182,6 +190,10 @@ static void display_valid_parameters(char *app_name);
 #define CommandCamSelect    12
 #define CommandSettings     13
 #define CommandSensorMode   14
+#define CommandSavePTS      15
+#define CommandZeroCopy      16
+#define CommandLineMode     17
+
 
 static COMMAND_LIST cmdline_commands[] =
 {
@@ -200,6 +212,9 @@ static COMMAND_LIST cmdline_commands[] =
    { CommandCamSelect,     "-camselect",  "cs", "Select camera <number>. Default 0", 1 },
    { CommandSettings,      "-settings",   "set","Retrieve camera settings and write to stdout", 0},
    { CommandSensorMode,    "-mode",       "md", "Force sensor mode. 0=auto. See docs for other modes available", 1},
+   { CommandSavePTS,       "-save-pts",   "pts","Save Timestamps to file for mkvmerge", 1 },
+   { CommandZeroCopy,      "-zero-copy",   "zc","Enable zero copy mode", 0},
+   { CommandLineMode,    "-line-mode",       "lmo", "just output one line", 1},
 };
 
 static int cmdline_commands_size = sizeof(cmdline_commands) / sizeof(cmdline_commands[0]);
@@ -255,6 +270,12 @@ static void default_status(RASPIVIDYUV_STATE *state)
    state->settings = 0;
    state->sensor_mode = 0;
 
+   state->frame = 0;
+   state->save_pts = 0;
+
+   state->line_mode = 0;
+
+   state->zero_copy = 0;
    // Setup preview window defaults
    raspipreview_set_defaults(&state->preview_parameters);
 
@@ -507,6 +528,38 @@ static int parse_cmdline(int argc, const char **argv, RASPIVIDYUV_STATE *state)
          break;
       }
 
+      case CommandSavePTS:  // output filename
+      {
+         state->save_pts = 1;
+         int len = strlen(argv[i + 1]);
+         if (len)
+         {
+            state->pts_file = malloc(len + 1);
+            vcos_assert(state->pts_file);
+            if (state->pts_file)
+               strncpy(state->pts_file, argv[i + 1], len+1);
+            i++;
+         }
+         else
+            valid = 0;
+         break;
+      }
+
+      case CommandZeroCopy:
+         state->zero_copy = 1;
+         break;
+
+      case CommandLineMode:
+      {
+         if (sscanf(argv[i + 1], "%u", &state->line_mode) == 1)
+         {
+            i++;
+         }
+         else
+            valid = 0;
+         break;
+      }
+
       default:
       {
          // Try parsing for any image specific parameters
@@ -623,6 +676,32 @@ static void camera_control_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buf
    mmal_buffer_header_release(buffer);
 }
 
+static FILE *open_pts_filename(RASPIVIDYUV_STATE *pState)
+{
+   FILE *new_handle = NULL;
+   char *filename = NULL;
+
+   filename = pState->pts_file;
+
+   if (filename)
+      new_handle = fopen(filename, "wb");
+
+   if (pState->verbose)
+   {
+      if (new_handle)
+         fprintf(stderr, "Opening pts output file \"%s\"\n", filename);
+      else
+         fprintf(stderr, "Failed to open new pts file \"%s\"\n", filename);
+   }
+
+   if (new_handle)
+   {
+      //save header for mkvmerge
+      fprintf(new_handle,"# timecode format v2\n");
+   }
+
+   return new_handle;
+}
 
 /**
  * Open a file based on the settings in state
@@ -684,8 +763,38 @@ static void camera_buffer_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buff
       if (buffer->length)
       {
          mmal_buffer_header_mem_lock(buffer);
-         bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);
+         if(pData->pstate->line_mode)
+         {
+            if(pData->pstate->line_mode >= pData->pstate->height)
+               pData->pstate->line_mode=(pData->pstate->height >> 1);
+            int w = VCOS_ALIGN_UP(pData->pstate->width, 32);
+            int h = VCOS_ALIGN_UP(pData->pstate->height, 16);
+            bytes_written = fwrite(buffer->data+w*pData->pstate->line_mode, 1, pData->pstate->width, pData->file_handle);
+            if(bytes_written==pData->pstate->width)
+               bytes_written=buffer->length;
+         }
+         else
+            bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);
+            
          mmal_buffer_header_mem_unlock(buffer);
+         fflush(pData->file_handle);
+         
+         if(pData->pstate->save_pts &&
+            (buffer->flags & MMAL_BUFFER_HEADER_FLAG_FRAME_END ||
+             buffer->flags == 0 ||
+             buffer->flags & MMAL_BUFFER_HEADER_FLAG_KEYFRAME) &&
+            !(buffer->flags & MMAL_BUFFER_HEADER_FLAG_CONFIG))
+         {
+            if(buffer->pts != MMAL_TIME_UNKNOWN && buffer->pts != pData->pstate->lasttime)
+            {
+              int64_t pts;
+              if(pData->pstate->frame==0)pData->pstate->starttime=buffer->pts;
+              pData->pstate->lasttime=buffer->pts;
+              pts = buffer->pts - pData->pstate->starttime;
+              fprintf(pData->pts_file_handle,"%d.%03d\n", pts/1000, pts%1000);
+              pData->pstate->frame++;
+            }
+         }
 
          if (bytes_written != buffer->length)
          {
@@ -806,7 +915,7 @@ static MMAL_STATUS_T create_camera_component(RASPIVIDYUV_STATE *state)
          .one_shot_stills = 0,
          .max_preview_video_w = state->width,
          .max_preview_video_h = state->height,
-         .num_preview_video_frames = 3,
+         .num_preview_video_frames = 10,
          .stills_capture_circular_buffer_height = 0,
          .fast_preview_resume = 0,
          .use_stc_timestamp = MMAL_PARAM_TIMESTAMP_MODE_RESET_STC
@@ -896,6 +1005,16 @@ static MMAL_STATUS_T create_camera_component(RASPIVIDYUV_STATE *state)
    format->es->video.frame_rate.num = state->framerate;
    format->es->video.frame_rate.den = VIDEO_FRAME_RATE_DEN;
 
+   if(state->zero_copy)
+   {
+      status = mmal_port_parameter_set_boolean(video_port,
+             MMAL_PARAMETER_ZERO_COPY, MMAL_TRUE);
+      if(status != MMAL_SUCCESS)
+      {
+         printf(stderr,"Error setting zero copy...\n");
+      }
+   }
+   
    status = mmal_port_format_commit(video_port);
 
    if (status != MMAL_SUCCESS)
@@ -1289,6 +1408,27 @@ int main(int argc, const char **argv)
             }
          }
 
+         state.callback_data.pts_file_handle = NULL;
+
+         if (state.pts_file)
+         {
+            if (state.pts_file[0] == '-')
+            {
+               state.callback_data.pts_file_handle = stdout;
+            }
+            else
+            {
+               state.callback_data.pts_file_handle = open_pts_filename(&state);
+            }
+
+            if (!state.callback_data.pts_file_handle)
+            {
+               // Notify user, carry on but discarding encoded output buffers
+               fprintf(stderr, "Error opening output file: %s\nNo output file will be generated\n",state.pts_file);
+               state.save_pts=0;
+            }
+         }
+
          // Set up our userdata - this is passed though to the callback where we need the information.
          state.callback_data.pstate = &state;
          state.callback_data.abort = 0;
@@ -1413,6 +1553,8 @@ error:
       // problems if we have already closed the file!
       if (state.callback_data.file_handle && state.callback_data.file_handle != stdout)
          fclose(state.callback_data.file_handle);
+      if (state.callback_data.pts_file_handle && state.callback_data.pts_file_handle != stdout)
+         fclose(state.callback_data.pts_file_handle);
 
       raspipreview_destroy(&state.preview_parameters);
       destroy_camera_component(&state);
I have run it with

Code: Select all

./raspividyuv -ex sport -o sd3.dat -lmo 240 -pts sd3.pts -w 640 -h 480 -fps 120 -v -zc -t 60000
enabling zero copy, taking only row 240.
And then have reconstructed the image using:

Code: Select all

echo -e "P5\n640 $(wc sd3.pts | awk '{print $1-1}')\n255\n" > sd3.pgm
cat sd3.dat >> sd3.pgm
I checked the timestamps in sd3.pts(which are in ms).

I have tried to attach my compiled binary here:
raspividyuv.zip
Zip of my compiled binary
(23.75 KiB) Downloaded 195 times

gregeric
Posts: 1509
Joined: Mon Nov 28, 2011 10:08 am

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 5:21 pm

Wow, ethanol100, thanks for that. I'll test with your implementation.

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

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 6:43 pm

To give some background as to what is happening in video mode.
- The sensor is going at the requested frame rate. No if's, not buts.
- There are normally 3 buffers allocated to handle those incoming Bayer frames - one being filled, one being fed into the ISP, and one spare. The control software deals with buffer swapping.
- The ISP can run at about 120-150MPix/s depending on how the frame is broken up.
- It writes to a buffer from a pool of buffers. This is the pool that has been increased in size. If there isn't a buffer available, then the ISP can't start the frame. If the camera starts producing a new frame before the last has been passed into the ISP, then the old one is dropped.
- When the ISP completes a frame, if there hasn't been a request for the buffer from the layer above (the IL/MMAL component) then again the frame is dropped.
- The MMAL/IL layer will request a frame when the previous one has been passed on to whatever is downstream.

- If it is the video encoder that is downstream, it can queue a number of jobs up. In other words it will soak up all those extra buffers if it is running behind, and only then will it start causing the camera component to start dropping. This is mainly of benefit during startup as opening the codec can take around 60ms, so absorbs the buffers and normally has capacity to catch up again once going.

Raspividyuv is obviously pulling frames back to the ARM, therefore another place for stalls is if it isn't delivering buffers back to the GPU fast enough to keep the system running. Adding in extra buffers (increase VIDEO_OUTPUT_BUFFERS_NUM by the looks of it) means that there should always be extras available on the GPU and it shouldn't stall.

There are subtleties involved on the GPU side. Format conversions and some other image processing is done using the Vector Register File (VRF) which is the heart of the SIMD side of the GPU. There are 2 of them, but the RTOS doesn't dynamically shift processes between cores. The main things that will use that are the format conversion on the output of the component (particularly if you ask for RGB), tuner algorithms (AGC, AWB, etc), and the denoise algorithm. You can disable the denoise algorithm using MMAL_PARAMETER_VIDEO_DENOISE if you think that is what is causing your issue, but there's no debug available to tell you what the loading/contention is on the VRF - suck it and see.
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.

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

Re: New 8MP Camera - Q&A thread

Mon Jun 20, 2016 10:19 am

ethanol100 wrote:Which duration do you want to record, I just tested a minute and got full 120fps for that.

My code used was a modified version of raspividyuv:

Code: Select all

diff --git a/host_applications/linux/apps/raspicam/RaspiVidYUV.c b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
index a8bc4c7..7d5061d 100644
--- a/host_applications/linux/apps/raspicam/RaspiVidYUV.c
+++ b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
@@ -119,6 +119,7 @@ typedef struct
    FILE *file_handle;                   /// File handle to write buffer data to.
    RASPIVIDYUV_STATE *pstate;           /// pointer to our state in case required in callback
    int abort;                           /// Set to 1 in callback if an error occurs to attempt to abort the capture
+   FILE *pts_file_handle;               /// File timestamps
 } PORT_USERDATA;
 
 /** Structure containing all state information for the current run
@@ -153,6 +154,13 @@ struct RASPIVIDYUV_STATE_S
    int cameraNum;                       /// Camera number
    int settings;                        /// Request settings from the camera
    int sensor_mode;                     /// Sensor mode. 0=auto. Check docs/forum for modes selected by other values.
+   int frame;
+   char *pts_file;
+   int save_pts;
+   int64_t starttime;
+   int64_t lasttime;
+   int zero_copy;
+   int line_mode;
 };
 
 static XREF_T  initial_map[] =
@@ -182,6 +190,10 @@ static void display_valid_parameters(char *app_name);
 #define CommandCamSelect    12
 #define CommandSettings     13
 #define CommandSensorMode   14
+#define CommandSavePTS      15
+#define CommandZeroCopy      16
+#define CommandLineMode     17
+
 
 static COMMAND_LIST cmdline_commands[] =
 {
@@ -200,6 +212,9 @@ static COMMAND_LIST cmdline_commands[] =
    { CommandCamSelect,     "-camselect",  "cs", "Select camera <number>. Default 0", 1 },
    { CommandSettings,      "-settings",   "set","Retrieve camera settings and write to stdout", 0},
    { CommandSensorMode,    "-mode",       "md", "Force sensor mode. 0=auto. See docs for other modes available", 1},
+   { CommandSavePTS,       "-save-pts",   "pts","Save Timestamps to file for mkvmerge", 1 },
+   { CommandZeroCopy,      "-zero-copy",   "zc","Enable zero copy mode", 0},
+   { CommandLineMode,    "-line-mode",       "lmo", "just output one line", 1},
 };
 
 static int cmdline_commands_size = sizeof(cmdline_commands) / sizeof(cmdline_commands[0]);
@@ -255,6 +270,12 @@ static void default_status(RASPIVIDYUV_STATE *state)
    state->settings = 0;
    state->sensor_mode = 0;
 
+   state->frame = 0;
+   state->save_pts = 0;
+
+   state->line_mode = 0;
+
+   state->zero_copy = 0;
    // Setup preview window defaults
    raspipreview_set_defaults(&state->preview_parameters);
 
@@ -507,6 +528,38 @@ static int parse_cmdline(int argc, const char **argv, RASPIVIDYUV_STATE *state)
          break;
       }
 
+      case CommandSavePTS:  // output filename
+      {
+         state->save_pts = 1;
+         int len = strlen(argv[i + 1]);
+         if (len)
+         {
+            state->pts_file = malloc(len + 1);
+            vcos_assert(state->pts_file);
+            if (state->pts_file)
+               strncpy(state->pts_file, argv[i + 1], len+1);
+            i++;
+         }
+         else
+            valid = 0;
+         break;
+      }
+
+      case CommandZeroCopy:
+         state->zero_copy = 1;
+         break;
+
+      case CommandLineMode:
+      {
+         if (sscanf(argv[i + 1], "%u", &state->line_mode) == 1)
+         {
+            i++;
+         }
+         else
+            valid = 0;
+         break;
+      }
+
       default:
       {
          // Try parsing for any image specific parameters
@@ -623,6 +676,32 @@ static void camera_control_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buf
    mmal_buffer_header_release(buffer);
 }
 
+static FILE *open_pts_filename(RASPIVIDYUV_STATE *pState)
+{
+   FILE *new_handle = NULL;
+   char *filename = NULL;
+
+   filename = pState->pts_file;
+
+   if (filename)
+      new_handle = fopen(filename, "wb");
+
+   if (pState->verbose)
+   {
+      if (new_handle)
+         fprintf(stderr, "Opening pts output file \"%s\"\n", filename);
+      else
+         fprintf(stderr, "Failed to open new pts file \"%s\"\n", filename);
+   }
+
+   if (new_handle)
+   {
+      //save header for mkvmerge
+      fprintf(new_handle,"# timecode format v2\n");
+   }
+
+   return new_handle;
+}
 
 /**
  * Open a file based on the settings in state
@@ -684,8 +763,38 @@ static void camera_buffer_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buff
       if (buffer->length)
       {
          mmal_buffer_header_mem_lock(buffer);
-         bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);
+         if(pData->pstate->line_mode)
+         {
+            if(pData->pstate->line_mode >= pData->pstate->height)
+               pData->pstate->line_mode=(pData->pstate->height >> 1);
+            int w = VCOS_ALIGN_UP(pData->pstate->width, 32);
+            int h = VCOS_ALIGN_UP(pData->pstate->height, 16);
+            bytes_written = fwrite(buffer->data+w*pData->pstate->line_mode, 1, pData->pstate->width, pData->file_handle);
+            if(bytes_written==pData->pstate->width)
+               bytes_written=buffer->length;
+         }
+         else
+            bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);
+            
          mmal_buffer_header_mem_unlock(buffer);
+         fflush(pData->file_handle);
+         
+         if(pData->pstate->save_pts &&
+            (buffer->flags & MMAL_BUFFER_HEADER_FLAG_FRAME_END ||
+             buffer->flags == 0 ||
+             buffer->flags & MMAL_BUFFER_HEADER_FLAG_KEYFRAME) &&
+            !(buffer->flags & MMAL_BUFFER_HEADER_FLAG_CONFIG))
+         {
+            if(buffer->pts != MMAL_TIME_UNKNOWN && buffer->pts != pData->pstate->lasttime)
+            {
+              int64_t pts;
+              if(pData->pstate->frame==0)pData->pstate->starttime=buffer->pts;
+              pData->pstate->lasttime=buffer->pts;
+              pts = buffer->pts - pData->pstate->starttime;
+              fprintf(pData->pts_file_handle,"%d.%03d\n", pts/1000, pts%1000);
+              pData->pstate->frame++;
+            }
+         }
 
          if (bytes_written != buffer->length)
          {
@@ -806,7 +915,7 @@ static MMAL_STATUS_T create_camera_component(RASPIVIDYUV_STATE *state)
          .one_shot_stills = 0,
          .max_preview_video_w = state->width,
          .max_preview_video_h = state->height,
-         .num_preview_video_frames = 3,
+         .num_preview_video_frames = 10,
          .stills_capture_circular_buffer_height = 0,
          .fast_preview_resume = 0,
          .use_stc_timestamp = MMAL_PARAM_TIMESTAMP_MODE_RESET_STC
@@ -896,6 +1005,16 @@ static MMAL_STATUS_T create_camera_component(RASPIVIDYUV_STATE *state)
    format->es->video.frame_rate.num = state->framerate;
    format->es->video.frame_rate.den = VIDEO_FRAME_RATE_DEN;
 
+   if(state->zero_copy)
+   {
+      status = mmal_port_parameter_set_boolean(video_port,
+             MMAL_PARAMETER_ZERO_COPY, MMAL_TRUE);
+      if(status != MMAL_SUCCESS)
+      {
+         printf(stderr,"Error setting zero copy...\n");
+      }
+   }
+   
    status = mmal_port_format_commit(video_port);
 
    if (status != MMAL_SUCCESS)
@@ -1289,6 +1408,27 @@ int main(int argc, const char **argv)
             }
          }
 
+         state.callback_data.pts_file_handle = NULL;
+
+         if (state.pts_file)
+         {
+            if (state.pts_file[0] == '-')
+            {
+               state.callback_data.pts_file_handle = stdout;
+            }
+            else
+            {
+               state.callback_data.pts_file_handle = open_pts_filename(&state);
+            }
+
+            if (!state.callback_data.pts_file_handle)
+            {
+               // Notify user, carry on but discarding encoded output buffers
+               fprintf(stderr, "Error opening output file: %s\nNo output file will be generated\n",state.pts_file);
+               state.save_pts=0;
+            }
+         }
+
          // Set up our userdata - this is passed though to the callback where we need the information.
          state.callback_data.pstate = &state;
          state.callback_data.abort = 0;
@@ -1413,6 +1553,8 @@ error:
       // problems if we have already closed the file!
       if (state.callback_data.file_handle && state.callback_data.file_handle != stdout)
          fclose(state.callback_data.file_handle);
+      if (state.callback_data.pts_file_handle && state.callback_data.pts_file_handle != stdout)
+         fclose(state.callback_data.pts_file_handle);
 
       raspipreview_destroy(&state.preview_parameters);
       destroy_camera_component(&state);
Pull request? ;)
Ideally it would be three patches, but I'm not that much of a stickler.
As stated above, zero copy does need to be used with caution at the moment - there is a definite deadlock condition in the kernel if it is used.
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.

gregeric
Posts: 1509
Joined: Mon Nov 28, 2011 10:08 am

Re: New 8MP Camera - Q&A thread

Mon Jun 20, 2016 1:50 pm

With ethanol100's modifications, my Zero plus v2 cam gives a solid 120.5fps - thanks! :D

When reconstructing the image, I removed the trailing linefeed, as the echo appends one anyway, resulting in a spurious 0x0a prepending the image data:

Code: Select all

echo -e "P5\n640 $(wc sd3.pts | awk '{print $1-1}')\n255" > sd3.pgm
cat sd3.dat >> sd3.pgm
Repeating at 720p (-w 1280 -h 720 -lmo 360) I can see ~10% dropped frames.

Sokolum
Posts: 7
Joined: Wed May 25, 2016 4:17 pm

Re: New 8MP Camera - Q&A thread

Sun Jun 26, 2016 12:12 pm

6by9 wrote:To give some background as to what is happening in video mode.
- There are normally 3 buffers allocated to handle those incoming Bayer frames - one being filled, one being fed into the ISP, and one spare. The control software deals with buffer swapping.
With this said and what I am understanding all of this:
Captures from the camera is always 3 frames behind before the GPU will do something about it.
When you output directly to the HDMI, it takes again 3 frames + latency monitor (don't have a source, I recall that I have read the HDMI also buffers 3 frames before it displays).

You will never reach a better latency then 6 frames, when recording at 60hz/16.67ms per frame, It will takes at least 100.02ms before the recorded frame is displayed on your monitor.

Increasing CPU/GPU clock will not give you better results. The optimization has to come from the hardware camera buffers and GPU buffers.

Iteration
Posts: 1
Joined: Tue Jun 28, 2016 3:23 am

Re: New 8MP Camera - Q&A thread

Tue Jun 28, 2016 3:33 am

Hi Folks

So I have been playing around with a few Raspberry Pi's and some camera modules.

I had initially been very unimpressed with the performance of my V2 camera, but after reading about the focus issues in this forum, I manually adjusted the focus and things have worked really well.

The thing is that I had wondered whether this focus issue was due to my camera being from an early batch, with newer ones at/near infinity. I just (today) got a second camera module from Element14 to test and noticed that the focus issue seems to remain.

I put them next to each other and took two side by side images that clearly show the focus issue.
http://imgur.com/a/HsytO

I was just wondering whether there is an issue with Australian stock or whether the factory focus they come with now is as "resolved" as this is likely to get. (I have ordered one of the adjusters off thingiverse so I can adjust this one without the risk of trashing it)

4x4
Posts: 2
Joined: Thu Jun 30, 2016 11:44 am

Re: New 8MP Camera - Q&A thread

Thu Jun 30, 2016 12:22 pm

poing wrote:The original Pi camera had a 'problem' when using it with another lens. I experimented a lot with Nikon lenses but always got a magenta circle in the frame. This was apparently caused by either the lens shading algorithm (without a vignetting lens this caused corners to be colored) and / or micro prisms optimized for the short lens to sensor distance. Any hope this will be better with the V2 camera board?

See the right side of this image:
000020A.jpg
Hi Poing,

You should need some IR-CUT (infrared) filter to recover the right colours. This one is a low cost one that I've tried, but doesn't have the original one's filtering performance :
http://www.ebay.fr/itm/9-5mm-Optical-UV ... SwQJhUcrRP

The original IR-UV filter is attached on the original lens, so you should have removed it.

Also you should not try to add your lens to the original lens. This makes an equivalent lens with a shorter focal length than the original one, and thus lose your long focal.

For astrophotography, it is preferable not adding the filter to catch more IR light !

Hope this can help, even after so much time .. :)

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Jun 30, 2016 2:05 pm

4x4 wrote:The original IR-UV filter is attached on the original lens, so you should have removed it.
I'd like to point out that the IR filter in the official RPi camera is attached directly over the sensor, and not on the lens (as is done with some M12 type camera assemblies for example). It is a delicate and difficult operation to remove the IR filter from a "normal" RPi camera even after you have unscrewed the lens; that's one reason why they decided to make the Pi-NoIR model.

The color-vignetting issue when using different lenses is due to the lens shading algorithm and is made much better, if not fixed entirely by enabling the statistics pass in raspistill using the -st option.

4x4
Posts: 2
Joined: Thu Jun 30, 2016 11:44 am

Re: New 8MP Camera - Q&A thread

Thu Jun 30, 2016 2:36 pm

Thank you jbeale, I will try the -st option !

ianj
Posts: 21
Joined: Mon May 12, 2014 2:24 am

Re: New 8MP Camera - Q&A thread

Sat Jul 16, 2016 6:50 pm

Wish I could get a refund or a credit for a free replacement camera. Considering it was unfocused and practically garbage from the beginning - of course tried to fix it and destroyed the lens with one slip in the process, making it literal garbage.

Of course that part is my fault, but it doesn't make up for the failure to provide a quality product from the beginning. Sure it's only $30 USD down the drain, but it's infuriating to just throw money away because of poor QC. :evil:

User avatar
Mettauk
Posts: 238
Joined: Mon Dec 10, 2012 12:40 pm
Location: Zarg

Re: New 8MP Camera - Q&A thread

Sat Jul 16, 2016 7:15 pm

ianj wrote:Wish I could get a refund or a credit for a free replacement camera. Considering it was unfocused and practically garbage from the beginning - of course tried to fix it and destroyed the lens with one slip in the process, making it literal garbage.

Of course that part is my fault, but it doesn't make up for the failure to provide a quality product from the beginning. Sure it's only $30 USD down the drain, but it's infuriating to just throw money away because of poor QC. :evil:
Tottaly agree, many fans on this forum make the point about how cheep Pi stuff is and seem to miss the point about defective cameras, touch screens, connectors not working despite claims of cross model compatability etc etc.

Postage is sometimes more than the item ordered. So failure goes in the bin.

The weird thing is an ordenary android phone costs considerbly less than a working Pi and as Pi's are sold in the millions some are making a mint.

BUT, for all the waste and overall expense, it is a great "product" which without the Community forum would fail as other attempts have.

So before anyone jumps on me for being negative I want to congratulate and thank all the people, especially the regular volunteers that give so much to make Pi Trading and the RPi foundation such a wonderful sucsess.

I have about 20 Pi's most doing something useful, most are used teaching me things I never thought I would be able to do!
As humans we have been the same for a very very long time, technology changes how we do... not who we are as people.

sblaszak
Posts: 13
Joined: Mon Feb 20, 2012 6:52 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Fri Jul 22, 2016 6:49 pm

Hi,

I noticed, on Wikipedia, that H264 level 4.2 supposedly supports up to 1920×1080@64 and 2048×1080@60. Given that you guys have managed to demonstrate 720p120 with a suitably overclocked Pi, do you think it's within the realm of possibility to hit 1080p60 or, at least, something like 1080p45?

Thanks,

-Shawn Blaszak

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

Re: New 8MP Camera - Q&A thread

Fri Jul 22, 2016 9:16 pm

sblaszak wrote:I noticed, on Wikipedia, that H264 level 4.2 supposedly supports up to 1920×1080@64 and 2048×1080@60. Given that you guys have managed to demonstrate 720p120 with a suitably overclocked Pi, do you think it's within the realm of possibility to hit 1080p60 or, at least, something like 1080p45?
1080P60 is highly unlikely.

Firstly the best that I believe has been achieved for H264 is 720P96 based on viewtopic.php?f=43&t=145815&start=325#p992276. It's only VGA that has hit 120fps.
1080P is 2.25 times the number of pixels of 720P, so if it were a simple scaling then that would be 1080P42.6. The block without overclocking was rated at 1080P33.

Secondly the sensor modes only set up 1080P30 (cropped FOV), 1640x922@40 (binned but full FOV), or 720P supposedly up to 120 (binned and cropped FOV). So there isn't a readout mode that will achieve >30fps with enough source pixels to make a 1080P encode worthwhile.
There may be scope to increase the max frame rate from the 1080P mode - basic numbers based on the line length say that a higher frame may be possible, but these sensors don't always work in a linear manner. Sorry, but it'll be a way down my priority list.
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.

sblaszak
Posts: 13
Joined: Mon Feb 20, 2012 6:52 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Jul 28, 2016 9:13 pm

Hi 6by9,

Thanks for the reply. I can definitely appreciate that this wouldn't be a priority for you but thanks for keeping the door open a crack.

On an unrelated note (and on the other end of the spectrum) what are the chances of future low resolution modes with ultra-high frame-rates (ex. 320x240@240hz)?

Thanks,

Shawn Blaszak

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

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 7:38 am

Mettauk wrote:
ianj wrote:Wish I could get a refund or a credit for a free replacement camera. Considering it was unfocused and practically garbage from the beginning - of course tried to fix it and destroyed the lens with one slip in the process, making it literal garbage.

Of course that part is my fault, but it doesn't make up for the failure to provide a quality product from the beginning. Sure it's only $30 USD down the drain, but it's infuriating to just throw money away because of poor QC. :evil:
Tottaly agree, many fans on this forum make the point about how cheep Pi stuff is and seem to miss the point about defective cameras, touch screens, connectors not working despite claims of cross model compatability etc etc.

Postage is sometimes more than the item ordered. So failure goes in the bin.

The weird thing is an ordenary android phone costs considerbly less than a working Pi and as Pi's are sold in the millions some are making a mint.

BUT, for all the waste and overall expense, it is a great "product" which without the Community forum would fail as other attempts have.

So before anyone jumps on me for being negative I want to congratulate and thank all the people, especially the regular volunteers that give so much to make Pi Trading and the RPi foundation such a wonderful sucsess.

I have about 20 Pi's most doing something useful, most are used teaching me things I never thought I would be able to do!
An Android phone costs less than a working Pi? Where?

Also, would be interested to know what you mean when talking about connectors and cross model compatibility. AFAIK, there are no differences on the connectors over all the 40 pin models, and the 26 pin version is forward compatible to 40.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

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

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 8:27 am

sblaszak wrote:Thanks for the reply. I can definitely appreciate that this wouldn't be a priority for you but thanks for keeping the door open a crack.

On an unrelated note (and on the other end of the spectrum) what are the chances of future low resolution modes with ultra-high frame-rates (ex. 320x240@240hz)?
New modes are just a faff to get running - from comments made by Naush (did most of the low level driver work for IMX219) it is an easier sensor to work with, but that still doesn't make it totally trivial.
There's also an issue of scheduling and control loops, and for each increase in framerate you're capturing less light so noise goes up. 240fps is ~4ms per frame, so that's also the max exposure time. Purely shifting buffers around at that rate is feasible, but IIRC the control loops were running at around 9ms to analyse the stats. We already back off the control loop to 1 frame in N when above 60fps.
There may be other options in the pipeline, but I'm not going to say more now.
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
Mettauk
Posts: 238
Joined: Mon Dec 10, 2012 12:40 pm
Location: Zarg

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 3:21 pm

Does the Official touch screen work properly with the pre 40 pin models? I am under the impression (perhaps wronly that it does not.

As for a fully functioning touch screen phone (Android) they can be had, new, fully working, no contract from around£35, see screen grab below. Or see BBC news article where an Indian Co is releasing a no contract £5 Android phone!
My point was that Pi stuff is impressive, but for a fully functioning computer far more than £5 - £35 is required! Plus low cost is no excuse for poor/defective product! Focus/slipping screens being my main gripe, perhaps coupled with RPF saying a few years ago that the pi will be ruining Android. Then seeming to walk away , perhaps because of closed hardware issues.
jamesh wrote:
Mettauk wrote:
ianj wrote:Wish I could get a refund or a credit for a free replacement camera. Considering it was unfocused and practically garbage from the beginning - of course tried to fix it and destroyed the lens with one slip in the process, making it literal garbage.

Of course that part is my fault, but it doesn't make up for the failure to provide a quality product from the beginning. Sure it's only $30 USD down the drain, but it's infuriating to just throw money away because of poor QC. :evil:
Tottaly agree, many fans on this forum make the point about how cheep Pi stuff is and seem to miss the point about defective cameras, touch screens, connectors not working despite claims of cross model compatability etc etc.

Postage is sometimes more than the item ordered. So failure goes in the bin.

The weird thing is an ordenary android phone costs considerbly less than a working Pi and as Pi's are sold in the millions some are making a mint.

BUT, for all the waste and overall expense, it is a great "product" which without the Community forum would fail as other attempts have.

So before anyone jumps on me for being negative I want to congratulate and thank all the people, especially the regular volunteers that give so much to make Pi Trading and the RPi foundation such a wonderful sucsess.

I have about 20 Pi's most doing something useful, most are used teaching me things I never thought I would be able to do!
An Android phone costs less than a working Pi? Where?

Also, would be interested to know what you mean when talking about connectors and cross model compatibility. AFAIK, there are no differences on the connectors over all the 40 pin models, and the 26 pin version is forward compatible to 40.
As humans we have been the same for a very very long time, technology changes how we do... not who we are as people.

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

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 3:32 pm

Going very off-topic here. I'd like to keep this thread clean if possible!
Mettauk wrote:Does the Official touch screen work properly with the pre 40 pin models? I am under the impression (perhaps wronly that it does not.
Wrongly.
Instructions on the official docs page for connecting to a model A or B. It has to use i2c-1 as i2c-0 wasn't wired through to the DSI connector.
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
Mettauk
Posts: 238
Joined: Mon Dec 10, 2012 12:40 pm
Location: Zarg

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 3:45 pm

6by9 wrote:Going very off-topic here. I'd like to keep this thread clean if possible!
Mettauk wrote:Does the Official touch screen work properly with the pre 40 pin models? I am under the impression (perhaps wronly that it does not.
Wrongly.
Instructions on the official docs page for connecting to a model A or B. It has to use i2c-1 as i2c-0 wasn't wired through to the DSI connector.
OK thank you and my apologies for that slight error. To close this as it is a bit OT. Here are two offerings of contract free touch screen computers with, storage, charger, battery, phone, wifi, BT etc. Only missing GPIO for substantially less than multi million plus selling pi's! Chalk and cheese I know, but irritated at ongoing claims of Pi being so cheep, it's not cheep to get it working. Especially those starting from scratch and the camera is well over £20 delivered, Pi0 £5, Camera £22, Memory £8, WiFi £8, plus screen, power, keyboard, mouse etc etc.
voda.jpg
Contract free phone
voda.jpg (17.13 KiB) Viewed 4418 times
O2.jpg
O2 contract free phone
O2.jpg (14.05 KiB) Viewed 4418 times
As humans we have been the same for a very very long time, technology changes how we do... not who we are as people.

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

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 4:39 pm

I have no idea how they make them for that price. Presumably in 10 of millions, certainly in much larger quantities than the Pi (note, the Pi is a LOW volume device when compared to phones).

Although not been able to find that £35 deal on the Vodafone site. They only seem to do bundles. EDIT: Found it, you have to add another £10 minimum/month for a bundle price. So £45 minimum. Still ludicrously cheap - I expect it's a loss leader, getting people on to their PAYG system, which is where they make the money back.


Be that as it may, if you think you can do what you need to do on an Android phone, use it. It's a no brainer. However, if you want to do the sort of projects that the Pi can do, then you are going to need to bite the bullet and spend a whole $35+tax+P&P on a Pi.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
Mettauk
Posts: 238
Joined: Mon Dec 10, 2012 12:40 pm
Location: Zarg

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 5:26 pm

jamesh wrote:However, if you want to do the sort of projects that the Pi can do, then you are going to need to bite the bullet and spend a whole $35+tax+P&P on a Pi.
Please stop the $35 speak. it's £35 plus postage plus memory as an absolute minimum, a zero needs WiFi, keyboard adaptors etc etc. All without even a screen, keyboard, mouse let alone a camera, and if a zero a £4 ribbon cable to boot!
As humans we have been the same for a very very long time, technology changes how we do... not who we are as people.

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

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 7:37 pm

Mettauk wrote:
jamesh wrote:However, if you want to do the sort of projects that the Pi can do, then you are going to need to bite the bullet and spend a whole $35+tax+P&P on a Pi.
Please stop the $35 speak. it's £35 plus postage plus memory as an absolute minimum, a zero needs WiFi, keyboard adaptors etc etc. All without even a screen, keyboard, mouse let alone a camera, and if a zero a £4 ribbon cable to boot!
Er, a post full of fail!

1. The first search I did, Pimoroni, £32 + delivery (that includes tax).

2. A Zero is £4, yes you do have to add a few connectors, but with case and adapters it's £12 + delivery. That's three pints of beer. Three pints, for something that cost 10's of millions to develop ( inc dev costs of the chips on board).

You can then add whatever accessories you want. WHich you will have to pay for. Because, you know, you don't get anything for free.

So, before spouting cobblers, do some research. Even better, just use the device that suits you best, stop comparing oranges with apples, and stop complaining about nothing. 5 years ago, you could not buy a full featured computer for less than £200. Now look. This stuff have changed the whole market.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

thanasispap
Posts: 14
Joined: Thu Jul 28, 2016 2:59 pm

Re: New 8MP Camera - Q&A thread

Fri Jul 29, 2016 7:42 pm

I've read all the previous posts and I can't find out how to take full res. from the camera in a python script.

Sorry for this "silly" question but even when I try to set resolution further from 5MP (1920, 1080) I 've always an error.

p.s. I found the CameraPi lib in python3 folder and as 6by9 said there is a "MAX_RESOLUTION" where I can change to my value, but I don't think its the write thing to do. I've last update on raspi firmware and picamera libs.

p.s. 2. Is there a need to set GPU mem to 256?

Thanks in advance!

Return to “Camera board”