Re: RFC: Problem of using v4l2 spec with codec function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux