Skip to content
This repository has been archived by the owner on Oct 23, 2023. It is now read-only.

V4L2 decoder does not correctly implement VIDIOC_G_FMT and VIDIOC_S_FMT #888

Open
EwanRoycroft opened this issue May 5, 2020 · 2 comments

Comments

@EwanRoycroft
Copy link

According to the V4L2 documentation, VIDIOC_G_FMT is exclusive to capture devices, and you can use this method with other drivers to get information about the output format; yet yami limits it to V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE.

The documentation also says of VIDIOC_S_FMT that:

"Drivers should not return an error code unless the type field is invalid,"

and that, after setting the format as requested:

"the VIDIOC_S_FMT ioctl returns the current format parameters as VIDIOC_G_FMT does."

I have found that this is not the case with yami. If certain fields are left empty, it will throw an error instead of filling them with the current values.

@xuguangxin
Copy link
Contributor

yes. we are not fully aligned with spec. the spec original designed for capture or output device. some items may not reasonable to decode or encoder.
Are you expect this VIDIOC_S_FMT/VIDIOC_G_FMT behavior in our application?
thanks

@EwanRoycroft
Copy link
Author

I have a program that uses the V4L2 driver on the Raspberry Pi to decode video. Assuming other drivers follow the spec, it should work cross-platform; but it fails on yami when making calls to VIDIOC_G_FMT / VIDIOC_S_FMT.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants