5MPixSlow 1fps with ISP producing 1920x1080) - 1003.59123ms with line length 0.183789ms (Needs checking as we should be able to do better, but may already have no padding lines).New values taken by (timestamp of frame FPS+1) / FPS (ie averaged over a second): How can I compensate with raspivid or ffmpeg commands?Ĭode: Select all build/bin/raspivid -w W -h H -fps FPS -pts timecodes.txt -o video.h264 -md X Thanks for replying, this information was useful. In the meantime you should be able to compensate with either the raspivid or ffmpeg commands.Ħby9 wrote:(This is where I start hating the manufacturers of the camera board) I'll add looking at the PLL setup to my list of jobs, but it may take a while. Not quite sure why you get 14hr 11mins - maybe the tolerance on your oscillator is a little on the wide side and is running faster still, but I thought they were meant to be fairly good. ffmpeg doesn't know this so is just stamping it with 40ms between frames.ġ4hr + 0.8% = 14.11hours, or 14hrs 6min 46secs. Therefore your requested 25fps is actually delivering 25.2frames/s.
So now we have cameras running 0.8% fast (25/24.8). The manufacturers got hold of it and found that 24.8MHz oscillators were more expensive than 25MHz oscillators, so substituted one for the other. When the module went for EMC testing, that configuration failed, so they redesigned the board to have an on-board oscillator.
The sensor is programmed on the basis that it is fed with a 24.8MHz clock as that was the original design, with that coming direct from the Pi down the ribbon cable. (This is where I start hating the manufacturers of the camera board)
0 kommentar(er)
