The way you are using it, you are not encoding the captured data at all, and the buffers will be saved complete so you won’t lose any information from them.
The video convert is necessary in order to link the v4l2src element with the xvimagesink element, it will provide the conversion between the data types. You can check which data types support both of the elements by using
If you only want to save the raw frames as the pipeline above, you see you don’t need it.
You can use the “format=GREY8” in the pipeline to make it work I believe, you can check the inspection of the formats using the inspect of the element as well.
Additional note: Indeed, saving raw video will preserve all information, but be aware that this results in huge disk usage very fast. I’d advise to save raw video on an external disk so that you won’t fill your linux rootfs.
Also note that for playing it back you will need to know resolution and format, so better fix format in caps after v4l2src and rename output file with resolution/framerate/format details.
Alright, so far so good. I’ve saved a video file. Size jumps up to 1-2GB with only a few seconds of recording, so that seems correct.
Do I need to record in a different format if I want a colleague to be able to view it on a Windows machine? VLC throws the dreaded codec error…
Maybe I misunderstood you, but if I remove the videoconvert in the above example, I get:
“Internal data stream error”
Something weird happening with output resolution:
Something I noticed while playing around with the different pipelines - the camera output changed from 2064x1544 to 2048x1544. This goes back to 2064x1544 when I powercycle. Not super important at the moment but maybe you have some clues to what could cause this.
If you remove the videoconvert and it fails that’s because xvimagesink can’t handle GRAY8, so you need to convert it to something it can handle. filesink will support almost anything you throw at in, because it just stores the data. If you do a gst-inspect-1.0 avimux, you can see this: