RE: RFC: Problem of using v4l2 spec with codec function
Hello, From: Jonghun Han [mailto:jonghun@samsung.com] Sent: 06 December 2010 07:57 Hi, If MFC(encoder/decoder) has a single node, how to know application's object before VIDIOC_S_FMT calling ? You're right. No way to know that before. VIDIOC_S_CTRL can be called before VIDIOC_S_FMT. For example user wants to use MFC as an *encoder*, but user calls VIDIOC_S_CTRL with *decoder* command by mistake. In that case driver cannot return fail because it cannot know the purpose before VIDIOC_S_FMT calling. When VIDIOC_S_FMT is called to use MFC as an *encoder* after VIDIOC_S_CTRL, driver will be confused how to handle it. But in two nodes solution decoder command via VIDIOC_S_CTRL will be failed on encoder device node. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Sunday, December 05, 2010 7:55 AM Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... We've had a discussion here with Sylwester Nawrocki and Marek Szyprowski. I suppose the application has to detect which video node is MFC anyway, for example by looking through /sys/class/video4linux or adding rules to udev. Same way it can choose which of the two node to use, so I don't think it going to be such a problem. In case of FIMC functionality - camera capture and m2m transformations are divided between two video nodes. In case of differentiating by format, I agree that it is feasible, but in my opinion it will overcomplicate the driver. When two nodes are used, there are going to be separate videobuf2 ops. Those functions that can be reused, would be reused, otherwise there would be two versions - one for encoding and one for decoding. Without that most functions would have to check what the context is doing and act appropriately. This means more complex code. What API changes have you had in mind that would be required when using two video nodes? Best regards -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, Kamil Hello, From: Jonghun Han [mailto:jonghun@samsung.com] Sent: 06 December 2010 07:57 Hi, If MFC(encoder/decoder) has a single node, how to know application's object before VIDIOC_S_FMT calling ? You're right. No way to know that before. VIDIOC_S_CTRL can be called before VIDIOC_S_FMT. For example user wants to use MFC as an *encoder*, but user calls VIDIOC_S_CTRL with *decoder* command by mistake. In that case driver cannot return fail because it cannot know the purpose before VIDIOC_S_FMT calling. When VIDIOC_S_FMT is called to use MFC as an *encoder* after VIDIOC_S_CTRL, driver will be confused how to handle it. But in two nodes solution decoder command via VIDIOC_S_CTRL will be failed on encoder device node. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Sunday, December 05, 2010 7:55 AM Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... We've had a discussion here with Sylwester Nawrocki and Marek Szyprowski. I suppose the application has to detect which video node is MFC anyway, for example by looking through /sys/class/video4linux or adding rules to udev. Same way it can choose which of the two node to use, so I don't think it going to be such a problem. In case of FIMC functionality - camera capture and m2m transformations are divided between two video nodes. In case of differentiating by format, I agree that it is feasible, but in my opinion it will overcomplicate the driver. When two nodes are used, there are going to be separate videobuf2 ops. Those functions that can be reused, would be reused, otherwise there would be two versions - one for encoding and one for decoding. Without that most functions would have to check what the context is doing and act appropriately. This means more complex code. It will have similar camera capture and m2m style. But we are considering that functions are reused enough b/w encoder decoder. -- peter Oh, Senior Engineer SW Solution Development Team, System LSI Division, Samsung Electronics, Co., Ltd. Email: jaeryul...@samsung.com --- What API changes have you had in mind that would be required when using two video nodes? Best regards -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, If MFC(encoder/decoder) has a single node, how to know application's object before VIDIOC_S_FMT calling ? VIDIOC_S_CTRL can be called before VIDIOC_S_FMT. For example user wants to use MFC as an *encoder*, but user calls VIDIOC_S_CTRL with *decoder* command by mistake. In that case driver cannot return fail because it cannot know the purpose before VIDIOC_S_FMT calling. When VIDIOC_S_FMT is called to use MFC as an *encoder* after VIDIOC_S_CTRL, driver will be confused how to handle it. But in two nodes solution decoder command via VIDIOC_S_CTRL will be failed on encoder device node. -- Best regards, Jonghun Han -- -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Sunday, December 05, 2010 7:55 AM To: Kamil Debski Cc: Hans Verkuil; Jonghun Han; Laurent Pinchart; jaeryul...@samsung.com; linux- me...@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, Hans Verkuil [hverk...@xs4all.nl] wrote: In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. The current V4L API is not good enough to determine what each video node can do. The upcoming media controller API should help in that. For the time being you should just assume that applications know what they are doing. Anyway, I think having two device nodes is a perfectly valid solution. Particularly for more complex scenarios. I agree that having two video nodes is a good solution. This kind of separation would simplify the driver. Detecting what should be done by checking format is possible, but I think having separate nodes seems better. Best regards, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
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. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip 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. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Monday, November 29, 2010 8:49 PM To: 'Laurent Pinchart'; 'Hans Verkuil' Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip 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. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. The current V4L API is not good enough to determine what each video node can do. The upcoming media controller API should help in that. For the time being you should just assume that applications know what they are doing. Anyway, I think having two device nodes is a perfectly valid solution. Particularly for more complex scenarios. Regards, Hans BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Monday, November 29, 2010 8:49 PM To: 'Laurent Pinchart'; 'Hans Verkuil' Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip 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. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
Hi Hans, On Monday 29 November 2010 11:36:03 Hans Verkuil wrote: On Monday 29 November 2010 08:34:06 Hans Verkuil wrote: [snip] 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. For colorspace conversion we can rely on formats as well. For video effects controls will probably be needed. That said, in this particular case your suggestion would work. If we think about the general case of a completely programmable system (think DSP), we will need a way to load the right firmware depending on the task at hand. The DSP would then become special purpose hardware, and V4L2 applications won't need to care much about how to select the desired operating mode. Whether the firmware selection/loading mechanism should be part of V4L2 or not is something to be discussed. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, Thanks for comment. I hope we would submit two nodes driver for encoder, decoder within 2010. BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Monday, November 29, 2010 9:17 PM To: Jonghun Han Cc: 'Laurent Pinchart'; jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. The current V4L API is not good enough to determine what each video node can do. The upcoming media controller API should help in that. For the time being you should just assume that applications know what they are doing. Anyway, I think having two device nodes is a perfectly valid solution. Particularly for more complex scenarios. Regards, Hans BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Monday, November 29, 2010 8:49 PM To: 'Laurent Pinchart'; 'Hans Verkuil' Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip 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. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Problem of using v4l2 spec with codec function
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 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 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 ? Thanks all -- peter Oh, Senior Engineer SW Solution Development Team, System LSI Division, Samsung Electronics, Co., Ltd. Phone: +82-31-32-52287 Mobile:+82-10-3369-1989 Email: jaeryul...@samsung.com --- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
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. Regards, Hans Thanks all -- peter Oh, Senior Engineer SW Solution Development Team, System LSI Division, Samsung Electronics, Co., Ltd. Phone: +82-31-32-52287 Mobile:+82-10-3369-1989 Email: jaeryul...@samsung.com --- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
