> Hi, > > On Monday 29 November 2010 08:34:06 Hans Verkuil wrote: >> On Monday, November 29, 2010 00:52:15 Jaeryul Oh wrote: >> > Hello, everyone. >> > >> > When it comes to using v4l2 standard spec, I have a question about >> that. >> > >> > A month ago, Kamil Debski posted second version for the driver of a hw >> > video codec. To be exact, it is decoding function of hw video codec >> > which is called MFC(Multi Format Codec). >> > >> > For members not accustomed to this, refer to link as below. >> > >> > : http://www.spinics.net/lists/linux-media/msg24682.html >> > >> > I'm preparing for patch of encoding function of MFC. But simply I >> could >> > say, According to the current version of v4l2 standard, User cannot >> call >> > encoder or decoder differentially. I mean, Kamil designed MFC decoder >> > driver using m2m style(not using by m2m framework, but >> > V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VIDEO_CAPTURE) >> > And it would be almost same to implement encoder in terms of using >> same >> > m2m style. But user should be able to call decoder for decoding, Due >> to >> > the same reason, user should be able to call encoder. Of course, some >> > different functions b/w encoder & decoder are called. (Driver should >> > know what function(enc or dec) is called) >> > >> > What do you think is the best way to let driver know what function >> user >> > wants to execute ? >> > >> > 1. VIDIOC_QUERYCAP is mandatory, but it doesn't define about any >> encoder, >> > decoder in the v4l2_capability >> > >> > : we need new capability for codec such as >> V4L2_BUF_TYPE_VIDEO_ENCODER, >> > : V4L2_BUF_TYPE_VIDEO_DECODER >> >> The upcoming media controller might be used to signal the capability. >> I'd >> be opposed to use a new buftype for this. Actually, I'm not sure if you >> really need this. >> >> > 2. What about using VIDIOC_S_CTRL, but it requires new defined decoder >> or >> > encoder as a ctrl.id. >> > >> > Another problem is VIDIOC_S_CTRL is optional >> >> Wouldn't you have separate video device nodes for the decoder and for >> the >> encoder? Or are they mutually exclusive? I.e., only one or the other can >> be running at a time? >> >> > 3. What about VIDIOC_S_FMT ? it is also optional, which means default >> > format will be used if not VIDIOC_S_FMT >> > >> > called. >> > >> > Let me know best way such as one among appropriate way that I >> mentioned >> > as above, or any other idea ? >> >> I have to admit it's not entirely clear to me what your problem is >> exactly. >> >> I *think* that what you are saying is that your hardware can have just a >> single 'm2m' video instance and so you want to allow the user to switch >> between the possible m2m functions (video encoder or decoder) >> dynamically. >> Is that right? >> >> If so, then I think creating a so-called 'private' control for your >> hardware would be the best way to go. As an example of private controls >> search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > > I would rely on formats. If the input format is YUV and the output format > is > MPEG, it's pretty obvious that the hardware should be encoding. If the > formats > are the other way around, then the hardware should be decoding. That doesn't work in the general case. Instead of video encoding/decoding you may also have video effects, colorspace conversion or other fancy transformations. That said, in this particular case your suggestion would work. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
