Hi, All!

It is possible to flip vertically video encoded with the v4l2 (/dev/video11) encoder? I know about property, but it looks like it is not supported by the encoder.
With legacy drivers and MMAL it was just a flag set...

Thanks...

Last edited by oleg11 on Thu Feb 13, 2025 5:41 am, edited 1 time in total.

I don't believe the encoder has ever supported VFLIP.
Yes the legacy camera stack supported H & V flips (implemented on the sensor), but so does libcamera.

If you want to encode that the encoded stream should be played back in an alternate orientation, the normal approach these days is to add a composition matrix to the container. See the example in the Android code - https://android.googlesource.com/platfo ... r.cpp#1159

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9 wrote:I don't believe the encoder has ever supported VFLIP.
Yes the legacy camera stack supported H & V flips (implemented on the sensor), but so does libcamera.

The legacy MMAL M2M encoding also supported video flipping, at least for the following scenario. I used it to capture screen video, the screen image was generated by the OpenGL ES and was passed directly to MMAL with the help of the MMAL_ENCODING_EGL_IMAGE encoding. The OpenGL output was vertical flipped and setting nFlipped field in the MMAL_BRCMVEGLIMAGETYPE structure solved the problem. That worked like a charm!
Now I am moving that project to new KMS drivers. I was able to pass to v4l2 DRM framebuffers with the help of DMABUF, and it worked. The only problem left is vertically flipped image.

6by9 wrote:the normal approach these days is to add a composition matrix to the container

Thanks for a possible solution! The MKV container I use should allow to do it.

6by9 wrote:the normal approach these days is to add a composition matrix to the container

It was a good plan, thanks! I added the needed elements to the MKV container header, but ... it appeared that none of the players (at least VLC, Windows Media Player and MPC-BE) support that feature for MKV container :? .

I had to do some changes to shaders and drawing code, so the framebuffer was drawn flipped (not a great solution, but it works and does not compromise performance).

That's annoying that it's not used from an MKV container. It certainly is supported for MP4 as almost all mobile phones use it, hence me quoting the Android source.
I wonder if it is trying to only VFLIP that it is complaining about.

The old EGL path was odd in that EGL does inherently render vertically flipped. It also required passing in the image handle and some metadata as the buffer, and the processing path munges it.
When passing image data as the input buffer, you can't add metadata in there, and it would need to be a control. We're normally using the ISP to convert the image data into an internal format, and It is possible to get the ISP to do flips as it processes the image. Actually the trickier part is adding the hflip to the software slow route (there's no point only adding VFLIP and not HFLIP).

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9 wrote: ↑

Tue Feb 11, 2025 4:43 pm

I wonder if it is trying to only VFLIP that it is complaining about.

MPC-BE can rotate video, but not flip. VLC/WMP did not rotate or flip MKV videos.

there's no point only adding VFLIP and not HFLIP

That is not a problem, the real problem is GPU hangs (with "[drm] Resetting GPU" dmesg messages). With the legacy drivers it was stable as rock.

oleg11 wrote: ↑

Wed Feb 12, 2025 5:44 pm

6by9 wrote: ↑

Tue Feb 11, 2025 4:43 pm

I wonder if it is trying to only VFLIP that it is complaining about.

MPC-BE can rotate video, but not flip. VLC/WMP did not rotate or flip MKV videos.

I'm slightly surprised as iPhones always record their front camera with an hflip, but that's possibly done in the image sensor instead of encoding anywhere. I would have hoped that it could have been overcome without re-encoding.
(Android always does an HFLIP when rendering the preview of the front camera, so you see a mirror-image as you expect, but the recording is correct).

oleg11 wrote:

there's no point only adding VFLIP and not HFLIP

That is not a problem, the real problem is GPU hangs (with "[drm] Resetting GPU" dmesg messages). With the legacy drivers it was stable as rock.

Who? What? Why? How?
Where did that come from when you were asking about vertical flip on the video encoder?

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9 wrote: ↑

Wed Feb 12, 2025 6:23 pm

I'm slightly surprised as iPhones always record their front camera with an hflip, but that's possibly done in the image sensor instead of encoding anywhere. I would have hoped that it could have been overcome without re-encoding.

I told about MKV container only. iPhone probably writes video into MP4 container. As far as I know at least VLC correctly rotates video saved in the MP4 containers.

Where did that come from when you were asking about vertical flip on the video encoder?

Sorry, it was a bit of offtopic. That problem just worry me a lot.