I've already asked about that earlier in this thread……ethanol100 wrote:... I think raspivid with a start/stop event would then behave more like a usual camcorder (or more like a still camera with video a feature...
Actually, the it makes the stream more resilient to errors, but does increase size. There's always a tradeoff!ethanol100 wrote:I think increasing the number of intra frames only increases file size. I have quickly tested to request i-frames after each "pause" of the video stream, and it is working, giving me additional I-Frames(and starting to count from there on i.e. 60,63,123...), but I have not tested, if there are at the right frame. Now I need to initial a split after pause, will quickly give it another try.
Looks OK. You should really push this as a git change to the raspi userland. It will be code reviewed by me and Dom, then pushed to the main tree if OK. Just make sure to keep to the coding standards (3 space tabs, allman braces) and it should get through quickly. I would say that the change as it stands would need to have some scheme for turning it on or off on the command line, so as not to affect current the current default functionality.ethanol100 wrote:I can now use i.e.: "raspivid -v -i 'pause' -t 0 -k -o vid%02d.h264"
Then I get for each "start-stop cycle" a h264 file. Thank you for the "inline header" and "segment" features. With these it was really easy to modify the source to reach my goal.
My modifications can be found here:
http://www2.geo.uni-bonn.de/members/kro ... VidSplit.c
I think something similar could be useful in raspivid.
tvjon wrote:There's no framerate info' with h264 files,
omxplayer -v says "invalid option -v" - it seems that there is no version info easily available. However, the stock omxplayer in the current raspbian certainly works well with h264, at least with those recorded by raspivid.tvjon wrote:However, I see a couple of posters reporting they are playing these files with omxplayer. Can you please say which version of omxplayer? Recent versions IME do not play h264 files.
H264 streams don't have time stamp or frame rate information - that's the job of the container. It's not strange. A bitstream of information can be played back at any rate - it has no inherent value except for width and height.caerandir wrote:tvjon wrote:There's no framerate info' with h264 files,
Accoring to http://www.ietf.org/rfc/rfc3984.txt I understand that there may be framerate info included (honestly, everything else I'd find strange...). I assume that it is not in raspivid-videos. Perhaps that can be improved?
ffmpeg (avconv) can take a stream and wrap a container around it. It been posted on around here somewhere.caerandir wrote:Ah, I see. So I'd need to wrap the container around. Is there any easy way to do this?
Code: Select all
sudo apt-get update sudo apt-get install -y gpac MP4Box -fps 30 -add myvid.h264 myvid.mp4
The buffer is of fixed size (or more precisely is size limited) and thus can contain bits of big I-frames (or I suppose P-frames). Whether a single callback can deal with multiple P-frames I'm not sure - I suspect in the case that the P-frames were smaller than the buffer size, the callback would be called once for each frame, but this is merely an untested hunch. As far as I know, B-frames aren't used by the camera's encoder (not entirely surprising - I get the impression they're only used when transcoding a pre-existing source, not when recording "live").caerandir wrote:Hi jamesh,
I started to have a look into the raspivid source code because I think if I want to have the motion detection working reliably I need to directly look into the motion vectors. As far as I was able to follow the code, there is the encoder_buffer_callback function that handles output from the codec. What I could not find out: Is the buffer always of fixed size and may thus contain anything from half an I-Frame up to several P- or B-frames, or is one buffer always one frame?