The state of mainline hardware decoding

[CounterPillow]

If someone have and idea to avoid the encoding part, please let me know (because I am kind new to the world of decoding/encoding and all related video processing stuff).

You can avoid both the encoding and decoding part if you stream-copy, though whether the MJPEG stream coming from the webcam is suitable for this is an entirely different question.

Here's an example:

Code:

ffmpeg -input_format mjpeg -framerate 30 -video_size 1280x720 -i /dev/video0 -c:v copy -f rtsp rtsp://localhost:8554/live

the -input_format mjpeg -framerate 30 -video_size 1280x720 before the -i /dev/video0 set up some options for our input, namely that we ask video4linux2 for the mjpeg stream of the camera, at a framerate of 30 frames per second, with a video size of 1280x720. -i /dev/video0 sets our input device; in this case /dev/video0 (replace with 1 or 2 if there are other cameras on the system).

-c:v copy tells ffmpeg to stream-copy the video stream, meaning it will not decode or encode it. -f rtsp sets the output format to rtsp, and what follows is the URL for this.

In this case, you won't be needing any hardware decoding or encoding, and your CPU won't be stressing too much as it's essentially doing not much at all.

Back to the topic at hand though: there currently is no mainline driver implementation of the hardware encoder for this particular SoC, as far as I'm aware. But that shouldn't be too big of an issue for mjpeg encoding if you end up having to reencode, as it should be very fast either way.