6by9 wrote:The sensor is being driven from a 25MHz crystal when it should be a 24.8MHz one, hence it is a couple of percent fast.
What EXACTLY is the command line you are running?
Are you requesting a low bitrate? The rate control algo can then sometimes decide to not encode frames as it is over bit budget.
Have you tried redirecting the video data to /dev/null whilst recording the PTS values (see earlier in this thread) to see what the timestamps come out as?
First of all, thanks for replying to a lot of these Camera Board related threads, you helped me solve some issues in these last weeks.
I'm not running it directly from the commandline, the video is recorded with the picamera library in a python program. I figure that doesn't make much of a difference in the actual recording though.
I don't set the bitrate to anything, so it should be whatever the default is, with a resolution of 1296 x 730 @ 20 fps.
I haven't tried those methods you mentioned yet because I'm not sure how to get a custom raspivid to run with picamera and include everything together (Audio and video recording at the same time while sending both to an encryption script), which is necessary since the problem probably doesn't exist if data isn't written to two files at the same time on the same usb port.
I'll try to do that once I've really exhausted my options.
But either way - Let's assume such a test would show that the USB device can't handle the writes while formatted as EXT4 (it certainly does handle them on XFS, but new requirements made that not an option). What would I even do in that case? Play around with the bitrate and hope for the best? Buy a ton of USB drives and pray that one is more reliable with the Raspberry's USB ports?
Sadly testing any of this is very time consuming, as differences are only obvious after ~1-2 hours of recording per video and I basically need a day of (daylight) recording for every setting I try to be statistically sure that it works fine.