Page 1 of 4

dropped frames

Posted: Mon Aug 12, 2013 8:55 am
by ripping
I have two camera boards, both hooked up to 512Mb 'B' pi's. (Fully updated, upgraded).
I'm having issues with dropped or skipped frames on 95% of my recordings.
usually every 10 or 15 sec in the recordings perhaps half a sec is missing from the recording, creating a noticeable skip. If I do 2 minute test recordings, they sometimes are only 1:48 in length (I assume this is the time lost or skipped that is reducing the output length - although I've read the timing is not 'perfect').
My workflow is record to the pi, convert to MP4 with MP4Box, then transfer to PC with WinSCP.
This is a typical command:

Code: Select all

raspivid -t 120000 -w 640 -h 360 -fps 25 -sh 70 -vf -hf -o twomin360.h264
.
(Writing to a USB thumb drive that holds the filesystem)

I suppose its possible the MP4Box conversion is dropping the frames.. but unlikely right?
Doing some testing tonight shows that every resolution above 640x360 is dropping frames on recording.
Originally I had the SD card holding the FS. Now I have a USB thumb drive holding the FS, but the results seem similar.
I overclocked to 950MHz earlier this evening, with no apparent improvement.
I've boosted the swap file size to 512Mb, and still no improvement. (Although the first video after doing that looked OK... seems it was a red herring!)
So.... is this what is to be expected? Am I expecting too much from the setup?
Have others had similar difficulties?
I mean its not a HUGE deal... but as I've not seen anyone discuss it before, I have just assumed skipping frames was non-existent.
Thoughts ?

Re: dropped frames

Posted: Mon Aug 12, 2013 9:17 am
by PiGraham
Are there dropped frames if you play the .h264 file on the Pi?
That should indicate if the issue is with raspivid or MP4Box.
Have you benchmarked the write speed of your SD / USB memory?
I'm not sure of the best way to do that but you can try:

Code: Select all

dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
See more at: http://systembash.com/content/simple-di ... nur51.dpuf

Re: dropped frames

Posted: Mon Aug 12, 2013 9:26 am
by jamesh
Check the original H264 file - does that show dropped frames? My guess would be you are exceeding the capabilities of the CPU to process the amount of data being generated when doing the conversion to mp4.

If you just use raspivid to record to h264 without any other processing do you still drop frames?

Re: dropped frames

Posted: Mon Aug 12, 2013 10:50 am
by ripping
OK. I did a quick test 720p / 2min recording.
Viewed the file on the pi using OMXplayer, and indeed I see dropped frames. Essentially the same pattern as what I am seeing on a PC with the converted MP4 files.
Safe to say that the MP4 conversion is not at fault.
I have a number of USB thumbdrives laying around, so I undertook a quick group test to measure their performance.

Image


The USB drive I have in the pi is the same as 'A' - which just happens to be the most sluggish writer that I have :roll:

Looking at this chart, I'm gunning for 'C', the 8Gb Cruzer Titanium.

I don't know how these results compare to 'official' testing, but at least they should be comparable among themselves.
The 'G' Kingston drive was almost the winner, with 3 out of 4 writes at 18MB/s, but the other write was very very slow, dragging the average down.
What sort of speeds are considered acceptable for the pi ??

Tested using SpeedOut 0.5.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:00 am
by jamesh
Odd. Not had reports of glitches like those described. I am fine recording 1080p30 at 25Mbits/s, no glitches, which is much faster than wht you are doing. But I am writing to SD card. If you write to SD do you get the same problem?

Re: dropped frames

Posted: Mon Aug 12, 2013 11:05 am
by ripping
Yes, I had the issues with just the SD card holding the filesystem. That's in fact why I went the USB Drive route, to eliminate the skipped frames I was experiencing. Alas, it was not to work !

Re: dropped frames

Posted: Mon Aug 12, 2013 11:07 am
by jamesh
Curiouser and curiouser. I do wonder if there is something wrong with the camera, as I cannot think of any other reason why (as long as all the software is up to date), you would get the symptoms described.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:16 am
by PiGraham
What happens if you write the output file to ram disk on /run/shm ?

That will be super fast. If you still get dropped frames it won't be because of storage speed.

I assumed you had tried this to SD card. Definitely check that in case it's a USB issue.

Test USB speed on the Pi.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:17 am
by ripping
Aha... but I have two cameras. And I'm 'sure' the same was happening with the other one too.
I think I will have to do some testing on the other, to be sure, to be sure....

ednl - I think the Class system of SD cards has little do with their actual performance anymore. Take the SD card being sold by the Foundation for 5 quid with NOOBs on it. Its a Class 4.. but it out-performs many Class 10's apparently.... but.. I dunno nothing about UHS-I .. ??

Re: dropped frames

Posted: Mon Aug 12, 2013 11:23 am
by PiGraham
Is your Pi doing anything else? What is the CPU load?
Have you tried with a clean Raspbian image?

Re: dropped frames

Posted: Mon Aug 12, 2013 11:28 am
by ripping
PiGraham wrote:What happens if you write the output file to ram disk on /run/shm ?

That will be super fast. If you still get dropped frames it won't be because of storage speed.

I assumed you had tried this to SD card. Definitely check that in case it's a USB issue.

Test USB speed on the Pi.
I did this:

Code: Select all

raspivid -t 120000 -w 1280 -h 720 -fps 25 -sh 70 -vf -hf -o /run/shm/twominit.h264
was that right.?
After about 30sec it aborted though.

Code: Select all

mmal: Failed to write buffer data - aborting
But as it was recording, there was no stuttering on the preview, which I WAS getting previously.
This pausing / stuttering seemed to coincide with the location of the dropped frames too (which make sense - obviously !)

The pi isn't doing anything else. Its just a camera pi. I installed a new image about a week ago when I got the camera, and only installed camera-relevant software... and apache.. I think thats about it...

I just checked CPU load while recording. Its barely working at 5.9% max.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:43 am
by PiGraham
ripping wrote:
PiGraham wrote:What happens if you write the output file to ram disk on /run/shm ?
I did this:

Code: Select all

raspivid -t 120000 -w 1280 -h 720 -fps 25 -sh 70 -vf -hf -o /run/shm/twominit.h264
was that right.?
After about 30sec it aborted though.

Code: Select all

mmal: Failed to write buffer data - aborting
But as it was recording, there was no stuttering on the preview, which I WAS getting previously.
This pausing / stuttering seemed to coincide with the location of the dropped frames too (which make sense - obviously !)
That is probably the limit of the ram disk. df reports 76MB on my 512MB model B.
At 25MBit/s that's about 24 seconds.

It does seem to suggest media write speed is the issue.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:45 am
by PiGraham
Another thing to try without wroting to file.
is demo mode (-d) doesn't write the output to file but still does the compression, I think.
Or pipe to /dev/null ?
Do those give you glitch free previews?

Re: dropped frames

Posted: Mon Aug 12, 2013 11:49 am
by RaTTuS
just try
raspivid -t 120000 -o test.h264
no other options
then try on a new raspbian image - install nothing else

Re: dropped frames

Posted: Mon Aug 12, 2013 11:50 am
by ripping
ednl wrote:To see which processes are busy, run 'top'.
Yes, that is what I did.
raspivid has top use at 5.9%
'top' is the next process at under 1%

Perhaps I just have the bad luck of having a slow SD card in conjunction with an equally slow USB drive. ?
I think I will try the fast USB drive I have, to see if that makes a difference.
Will refresh myself on how to copy my duty USB to the 'fast' drive then report back.

I've not had any issues that I remember while just running a preview...

edit. All my SD cards are Class 4's - but I did find a Class 6 in the pile, so I will load a fresh copy of the good word (Raspbian) on that.

Re: dropped frames

Posted: Mon Aug 12, 2013 11:57 am
by jamesh
Don't specify an output file - that way you just get the preview. See if that has problems. Although that doesn't use the encoder.

If you are happy to compile the code, you could modify it so that in the function encoder_buffer_format in RaspiVid.c, you simply don't do the fwrite. That way everything except the actual save is done. If you get glitches in the preview, that's very odd indeed.

EDIT: Maybe sending the output to /dev/null might have the same effect?

raspivid - - > /dev/null

Re: dropped frames

Posted: Mon Aug 12, 2013 12:06 pm
by ripping
Compile?? Code?? Y is u talk gibberish ??

Seriously tho.. I'm just a 'little league' player. But I look upon you Major League players with awe and reverence. Compiling code is something that will perhaps come in the distant future for me. Baby steps an'all that :)
But.. as I think I mentioned... previews (from what I remember) have not displayed the same glitches that a written file has.. so hopefully a change of media will be the cure all. I will be back !!

Re: dropped frames

Posted: Mon Aug 12, 2013 1:00 pm
by Aikidokajeff
I got this when adding video recording to the camera UI.
(http://youtu.be/orELpVD-6Dk) - about 6 seconds in.
(Very boring video!)

I had been ignoring it in case I was causing it with my code but it is interesting to see others having the same problems. (Also as I'm using the image from Texy using the TFT screen)
I had several skips in a 20 seconds video as well as in a 30 minute 2Gb video file.
Both recording to a class 10 16GB SD card.

I've yet to change memory allocations for CPU/GPU.

Very interested to see what comes out of this.

Jeff

Re: dropped frames

Posted: Mon Aug 12, 2013 3:42 pm
by alexeames
At 1080p30, I regularly got dropped frames on both camera modules I bought, model A, model B - no different. It shows both on preview and in the recording.

The problem mostly went away when I reduced the frame rate from 1080p30 to 1080p25. It's a better fit for my video editing software too - as my main camera does 25fps. But it's still not perfect.

So, no. You are NOT alone. :)

Re: dropped frames

Posted: Mon Aug 12, 2013 4:08 pm
by jamesh
To all those seeing drops, if you pipe to NULL does the preview glitch go away? Can you reduce bitrate to see if it helps? That would have a better effect than dropping the framerate if the media is too slow.

Re: dropped frames

Posted: Mon Aug 12, 2013 4:13 pm
by Aikidokajeff
I always use the "-n" option when taking videos like the one seen above. (because the small TFT doesn't support live preview very well, no point in trying)

Re: dropped frames

Posted: Mon Aug 12, 2013 4:18 pm
by PiGraham
I wonder if the condition of the flash memory device could be an issue. A new card should have large contiguous blocks available for writing but a well used card may have fragmented. That may affect the number of IO transactions and impact speed.
I know SSDs suffer serious speed degradation once they get nearly full, even if a lot of the space is taken by erased files. SSDs can be sorted out with a TRIM but I'm not sure about SD cards. Are you using well used flash memory devices? Can you test with a new device? Can you try Official SD formatter erase?

Re: dropped frames

Posted: Mon Aug 12, 2013 4:19 pm
by PiGraham
Aikidokajeff wrote:I always use the "-n" option when taking videos like the one seen above. (because the small TFT doesn't support live preview very well, no point in trying)
I get very nice preview on the 2.8" TFT from TEXY with tftfb and fbcopy.

What problems do you see?

Re: dropped frames

Posted: Mon Aug 12, 2013 4:22 pm
by Aikidokajeff
Useful info.
The card I have is 16GB, and only 30% used.

I have maybe used about 40% of it in total before deletes.
What you suggest is possible, but I don't have any fresh cards to test with at the moment. (and I can't take the time wiping this one etc.)

Thank you though, if I get a chance I will!

Re: dropped frames

Posted: Mon Aug 12, 2013 4:24 pm
by Aikidokajeff
PiGraham wrote:
Aikidokajeff wrote:I always use the "-n" option when taking videos like the one seen above. (because the small TFT doesn't support live preview very well, no point in trying)
I get very nice preview on the 2.8" TFT from TEXY with tftfb and fbcopy.

What problems do you see?
No real problems now, I think I tried the first version.
But either way, I am happy not using it in favour of using the TFT for the simple UI.
I'm not using the FBcopy software anymore, back to using the TFT directly with python.