Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support
On 07/09/2017 08:32 AM, Nicolas Dufresne wrote: Le samedi 08 juillet 2017 à 13:16 +0800, ayaka a écrit : On 07/08/2017 02:33 AM, Nicolas Dufresne wrote: Le samedi 08 juillet 2017 à 01:29 +0800, ayaka a écrit : On 07/04/2017 05:29 PM, Hugues FRUCHET wrote: Hi Randy, Thanks for review, and sorry for late reply, answers inline. BR, Hugues. On 06/11/2017 01:41 PM, ayaka wrote: On 04/28/2017 09:25 PM, Hugues Fruchet wrote: Add "parsed MPEG-2" pixel format & related controls needed by stateless video decoders. In order to decode the video bitstream chunk provided by user on output queue, stateless decoders require also some extra data resulting from this video bitstream chunk parsing. Those parsed extra data have to be set by user through control framework using the dedicated mpeg video extended controls introduced in this patchset. I have compared those v4l2 controls with the registers of the rockchip video IP. Most of them are met, but only lacks of sw_init_qp. In case of MPEG-1/2, this register seems forced to 1, please double check the on2 headers parsing library related to MPEG2. Nevertheless, I see this hardware register used with VP8/H264. Yes, it is forced to be 1. We can skip this field for MPEG1/2 Hence, no need to put this field on MPEG-2 interface, but should come with VP8/H264. Here is the full translation table of the registers of the rockchip video IP. q_scale_type sw_qscale_type concealment_motion_vectorssw_con_mv_e intra_dc_precision sw_intra_dc_prec intra_vlc_format sw_intra_vlc_tab frame_pred_frame_dct sw_frame_pred_dct alternate_scan sw_alt_scan_flag_e f_code sw_fcode_bwd_ver sw_fcode_bwd_hor sw_fcode_fwd_ver sw_fcode_fwd_hor full_pel_forward_vector sw_mv_accuracy_fwd full_pel_backward_vector sw_mv_accuracy_bwd I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would not recommand to do that. We need to differentiate MPEG-1/MPEG-2, not all the fields are applicable depending on version. Usually the MPEG-2 decoder could support MPEG-1, as I know, the syntax of byte stream of them are the same. That is what google does, because for a few video format and some hardware, they just request a offsets from the original video byte stream. I don't understand your comment, perhaps have you some as a basis of discussion ? I mean V4L2-PIX-FMT-MPEG2-PARSED V4L2-PIX-FMT-MPEG1-PARSED I wonder whether you want use the new format to inform the userspace that this device is for stateless video decoder, as google defined something like V4L2_PIX_FMT_H264_SLICE. I think the driver registers some controls is enough for the userspace to detect whether it is a stateless device. Or it will increase the work of the userspace(I mean Gstreamer). Just a note that SLICE has nothing to do with PARSED here. You could have an H264 decoder that is stateless and support handling slices rather then full frames (e.g. V4L2_PIX_FMT_H264_SLICE_PARSED could be valid). Actually, they have the same meanings, the H264_SLICE is not a slice, it is an access unit in the rockchip vpu driver for Google. Let's make sure this never get into mainline unmodified. H264_SLICE should indicate that encoded buffer need to contains at least one slice. We already have a format that indicates that a complete AU must be passed. I do have active project going on where we really want to pass slice for low latency cases and I would really appreciate if that name can be used. I think the hardware could support multiple slices in an AU, one slice in an AU or slice itself. Well, but the in chrome os, it just means an parsed H264 stream. I would not worry to much about Gst, as we will likely use this device through the libv4l2 here, hence will only notice the "emulated" V4L2_PIX_FMT_MPEG2 and ignore the _PARSED variant. And without libv4l2, we'd just ignore this driver completely. I doubt we will implement per- device parsing inside Gst itself if it's already done in an external library for us. libv4l2 might need some fixing, but hopefully it's not beyond repair. As Gstreamer has merged the VA-API before, I would like to merge it into Gstreamer directly. Also for performance reason and my experience, the buffer management would be a big problem, we need to increase the another layer to v4l2 plugins then. When the parser is split from its caller, it would be hard to add a path for error handing or something else. I totally fail to understand your point here. Existing driver have a separate core that do hide all the parsing and error handling, yet it works relatively well this way. GStreamer is pretty h
Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support
On 07/08/2017 02:33 AM, Nicolas Dufresne wrote: Le samedi 08 juillet 2017 à 01:29 +0800, ayaka a écrit : On 07/04/2017 05:29 PM, Hugues FRUCHET wrote: Hi Randy, Thanks for review, and sorry for late reply, answers inline. BR, Hugues. On 06/11/2017 01:41 PM, ayaka wrote: On 04/28/2017 09:25 PM, Hugues Fruchet wrote: Add "parsed MPEG-2" pixel format & related controls needed by stateless video decoders. In order to decode the video bitstream chunk provided by user on output queue, stateless decoders require also some extra data resulting from this video bitstream chunk parsing. Those parsed extra data have to be set by user through control framework using the dedicated mpeg video extended controls introduced in this patchset. I have compared those v4l2 controls with the registers of the rockchip video IP. Most of them are met, but only lacks of sw_init_qp. In case of MPEG-1/2, this register seems forced to 1, please double check the on2 headers parsing library related to MPEG2. Nevertheless, I see this hardware register used with VP8/H264. Yes, it is forced to be 1. We can skip this field for MPEG1/2 Hence, no need to put this field on MPEG-2 interface, but should come with VP8/H264. Here is the full translation table of the registers of the rockchip video IP. q_scale_type sw_qscale_type concealment_motion_vectorssw_con_mv_e intra_dc_precision sw_intra_dc_prec intra_vlc_format sw_intra_vlc_tab frame_pred_frame_dct sw_frame_pred_dct alternate_scan sw_alt_scan_flag_e f_code sw_fcode_bwd_ver sw_fcode_bwd_hor sw_fcode_fwd_ver sw_fcode_fwd_hor full_pel_forward_vector sw_mv_accuracy_fwd full_pel_backward_vector sw_mv_accuracy_bwd I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would not recommand to do that. We need to differentiate MPEG-1/MPEG-2, not all the fields are applicable depending on version. Usually the MPEG-2 decoder could support MPEG-1, as I know, the syntax of byte stream of them are the same. That is what google does, because for a few video format and some hardware, they just request a offsets from the original video byte stream. I don't understand your comment, perhaps have you some as a basis of discussion ? I mean V4L2-PIX-FMT-MPEG2-PARSED V4L2-PIX-FMT-MPEG1-PARSED I wonder whether you want use the new format to inform the userspace that this device is for stateless video decoder, as google defined something like V4L2_PIX_FMT_H264_SLICE. I think the driver registers some controls is enough for the userspace to detect whether it is a stateless device. Or it will increase the work of the userspace(I mean Gstreamer). Just a note that SLICE has nothing to do with PARSED here. You could have an H264 decoder that is stateless and support handling slices rather then full frames (e.g. V4L2_PIX_FMT_H264_SLICE_PARSED could be valid). Actually, they have the same meanings, the H264_SLICE is not a slice, it is an access unit in the rockchip vpu driver for Google. I would not worry to much about Gst, as we will likely use this device through the libv4l2 here, hence will only notice the "emulated" V4L2_PIX_FMT_MPEG2 and ignore the _PARSED variant. And without libv4l2, we'd just ignore this driver completely. I doubt we will implement per- device parsing inside Gst itself if it's already done in an external library for us. libv4l2 might need some fixing, but hopefully it's not beyond repair. As Gstreamer has merged the VA-API before, I would like to merge it into Gstreamer directly. Also for performance reason and my experience, the buffer management would be a big problem, we need to increase the another layer to v4l2 plugins then. When the parser is split from its caller, it would be hard to add a path for error handing or something else. P.S I have dropped my original plan about writing a new v4l2 driver for rockchip, but reuse the v4l2 logic from google and rewrite the hal part and rewrite what I need to save the time. It would comes soon Offset from the beginning of original video bitstream is supported within proposed interface, see v4l2_mpeg_video_mpeg2_pic_hd->offset field. Signed-off-by: Hugues Fruchet<hugues.fruc...@st.com> --- Documentation/media/uapi/v4l/extended-controls.rst | 363 + Documentation/media/uapi/v4l/pixfmt-013.rst| 10 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 38 ++- Documentation/media/videodev2.h.rst.exceptions | 6 + drivers/media/v4l2-core/v4l2-ctrls.c | 53 +++ drivers/media/v4l2-core/v4l2-ioctl.c |
Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support
On 07/04/2017 05:29 PM, Hugues FRUCHET wrote: Hi Randy, Thanks for review, and sorry for late reply, answers inline. BR, Hugues. On 06/11/2017 01:41 PM, ayaka wrote: On 04/28/2017 09:25 PM, Hugues Fruchet wrote: Add "parsed MPEG-2" pixel format & related controls needed by stateless video decoders. In order to decode the video bitstream chunk provided by user on output queue, stateless decoders require also some extra data resulting from this video bitstream chunk parsing. Those parsed extra data have to be set by user through control framework using the dedicated mpeg video extended controls introduced in this patchset. I have compared those v4l2 controls with the registers of the rockchip video IP. Most of them are met, but only lacks of sw_init_qp. In case of MPEG-1/2, this register seems forced to 1, please double check the on2 headers parsing library related to MPEG2. Nevertheless, I see this hardware register used with VP8/H264. Yes, it is forced to be 1. We can skip this field for MPEG1/2 Hence, no need to put this field on MPEG-2 interface, but should come with VP8/H264. Here is the full translation table of the registers of the rockchip video IP. q_scale_type sw_qscale_type concealment_motion_vectorssw_con_mv_e intra_dc_precision sw_intra_dc_prec intra_vlc_format sw_intra_vlc_tab frame_pred_frame_dct sw_frame_pred_dct alternate_scan sw_alt_scan_flag_e f_code sw_fcode_bwd_ver sw_fcode_bwd_hor sw_fcode_fwd_ver sw_fcode_fwd_hor full_pel_forward_vector sw_mv_accuracy_fwd full_pel_backward_vector sw_mv_accuracy_bwd I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would not recommand to do that. We need to differentiate MPEG-1/MPEG-2, not all the fields are applicable depending on version. Usually the MPEG-2 decoder could support MPEG-1, as I know, the syntax of byte stream of them are the same. That is what google does, because for a few video format and some hardware, they just request a offsets from the original video byte stream. I don't understand your comment, perhaps have you some as a basis of discussion ? I mean V4L2-PIX-FMT-MPEG2-PARSED V4L2-PIX-FMT-MPEG1-PARSED I wonder whether you want use the new format to inform the userspace that this device is for stateless video decoder, as google defined something like V4L2_PIX_FMT_H264_SLICE. I think the driver registers some controls is enough for the userspace to detect whether it is a stateless device. Or it will increase the work of the userspace(I mean Gstreamer). Offset from the beginning of original video bitstream is supported within proposed interface, see v4l2_mpeg_video_mpeg2_pic_hd->offset field. Signed-off-by: Hugues Fruchet<hugues.fruc...@st.com> --- Documentation/media/uapi/v4l/extended-controls.rst | 363 + Documentation/media/uapi/v4l/pixfmt-013.rst| 10 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 38 ++- Documentation/media/videodev2.h.rst.exceptions | 6 + drivers/media/v4l2-core/v4l2-ctrls.c | 53 +++ drivers/media/v4l2-core/v4l2-ioctl.c | 2 + include/uapi/linux/v4l2-controls.h | 94 ++ include/uapi/linux/videodev2.h | 8 + 8 files changed, 572 insertions(+), 2 deletions(-) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index abb1057..b48eac9 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type - not insert, 1 = insert packets. +MPEG-2 Parsed Control Reference +- + +The MPEG-2 parsed decoding controls are needed by stateless video decoders. +Those decoders expose :ref:`Compressed formats ` :ref:`V4L2_PIX_FMT_MPEG1_PARSED` or :ref:`V4L2_PIX_FMT_MPEG2_PARSED`. +In order to decode the video bitstream chunk provided by user on output queue, +stateless decoders require also some extra data resulting from this video +bitstream chunk parsing. Those parsed extra data have to be set by user +through control framework using the mpeg video extended controls defined +in this section. Those controls have been defined based on MPEG-2 standard +ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax +including how it is coded inside bitstream (enumeration values for ex.). + +MPEG-2 Parsed Control IDs +^^^ + +.. _mpeg2-parsed-c
Fwd: Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support
I don't know why it was sent in html format, I am sorry to re-send it again. On 04/28/2017 09:25 PM, Hugues Fruchet wrote: Add "parsed MPEG-2" pixel format & related controls needed by stateless video decoders. In order to decode the video bitstream chunk provided by user on output queue, stateless decoders require also some extra data resulting from this video bitstream chunk parsing. Those parsed extra data have to be set by user through control framework using the dedicated mpeg video extended controls introduced in this patchset. I have compared those v4l2 controls with the registers of the rockchip video IP. Most of them are met, but only lacks of sw_init_qp. Here is the full translation table of the registers of the rockchip video IP. q_scale_type sw_qscale_type concealment_motion_vectorssw_con_mv_e intra_dc_precision sw_intra_dc_prec intra_vlc_format sw_intra_vlc_tab frame_pred_frame_dct sw_frame_pred_dct alternate_scan sw_alt_scan_flag_e f_code sw_fcode_bwd_ver sw_fcode_bwd_hor sw_fcode_fwd_ver sw_fcode_fwd_hor full_pel_forward_vector sw_mv_accuracy_fwd full_pel_backward_vector sw_mv_accuracy_bwd I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would not recommand to do that. That is what google does, because for a few video format and some hardware, they just request a offsets from the original video byte stream. Signed-off-by: Hugues Fruchet--- Documentation/media/uapi/v4l/extended-controls.rst | 363 + Documentation/media/uapi/v4l/pixfmt-013.rst| 10 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 38 ++- Documentation/media/videodev2.h.rst.exceptions | 6 + drivers/media/v4l2-core/v4l2-ctrls.c | 53 +++ drivers/media/v4l2-core/v4l2-ioctl.c | 2 + include/uapi/linux/v4l2-controls.h | 94 ++ include/uapi/linux/videodev2.h | 8 + 8 files changed, 572 insertions(+), 2 deletions(-) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index abb1057..b48eac9 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type - not insert, 1 = insert packets. +MPEG-2 Parsed Control Reference +- + +The MPEG-2 parsed decoding controls are needed by stateless video decoders. +Those decoders expose :ref:`Compressed formats ` :ref:`V4L2_PIX_FMT_MPEG1_PARSED` or :ref:`V4L2_PIX_FMT_MPEG2_PARSED`. +In order to decode the video bitstream chunk provided by user on output queue, +stateless decoders require also some extra data resulting from this video +bitstream chunk parsing. Those parsed extra data have to be set by user +through control framework using the mpeg video extended controls defined +in this section. Those controls have been defined based on MPEG-2 standard +ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax +including how it is coded inside bitstream (enumeration values for ex.). + +MPEG-2 Parsed Control IDs +^^^ + +.. _mpeg2-parsed-control-id: + +.. c:type:: V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR +(enum) + +.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}| + +.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u16 + - ``width`` + - Video width in pixels. +* - __u16 + - ``height`` + - Video height in pixels. +* - __u8 + - ``aspect_ratio_info`` + - Aspect ratio code as in the bitstream (1: 1:1 square pixels, +2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display) +* - __u8 + - ``framerate code`` + - Framerate code as in the bitstream +(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0, +4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0, +8: 60.0) +* - __u16 + - ``vbv_buffer_size`` + - Video Buffering Verifier size, expressed in 16KBytes unit. +* - __u32 + - ``bitrate_value`` + - Bitrate value as in the bitstream, expressed in 400bps unit +* - __u16 + - ``constrained_parameters_flag`` + - Set to 1 if this bitstream uses constrained parameters. +* - __u8 + - ``load_intra_quantiser_matrix`` + - If set to 1, ``intra_quantiser_matrix`` table is to be used for +decoding. +* - __u8 + - ``load_non_intra_quantiser_matrix`` + - If set to 1, ``non_intra_quantiser_matrix`` table is to be used for +decoding. +* - __u8 + - ``intra_quantiser_matrix[64]`` + - Intra quantization table, in zig-zag scan order. +* - __u8 + - ``non_intra_quantiser_matrix[64]`` + - Non-intra
Re: [RFC] V4L2 unified low-level decoder API
On 06/08/2017 06:56 PM, Hans Verkuil wrote: Hi Alexandre, On 08/06/17 11:59, Alexandre Courbot wrote: On Thu, Jun 8, 2017 at 5:56 PM, Pawel Osciakwrote: Hi, On Fri, May 19, 2017 at 1:08 AM, Hugues FRUCHET wrote: Before merging this work Hans would like to have feedback from peers, in order to be sure that this is inline with other SoC vendors drivers expectations. Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip driver ? The drivers for Rockchip codecs are submitted to the public Chromium OS kernel and working on our RK-based platforms. We have also since added a VP9 API as That driver still lacks a number of feature comparing to the rockchip android driver, since google never requests them. Also the performance is not as good as the android one. That is why I start to write a new driver myself. Also the rockchip platform is very complex, that driver won't be work on all the SoCs without a large of modification(now only two chips are supported) well, which is also working on devices that support it. This gives us a set of H.264, VP8 and VP9 APIs on both kernel and userspace side (in the open source Chromium browser) that are working currently and can be used for further testing. We are interested in merging the API patches as well as these drivers upstream (they were posted on this list two years ago), however we've been blocked by the progress of request API, which is required for this. Alexandre Courbot is currently Well the request API looks fine for me, I just can't understand why it is not merged except those are a few functions have a reference problem stopping build v4l2 as a module. looking into creating a minimal version of the request API that would provide enough functionality for stateless codecs, and also plans to further work on re-submitting the particular codec API patches, once the request API is finalized. Hi everyone, It is a bit scary to start hacking on V4L with something as disruptive as the request API, so please bear with me as I will inevitably post code that will go from cutely clueless to downright offensive. Yeah, you went straight into the deep end of the pool :-) I am very, very pleased to see Google picking up this work. We need more core V4L2 developers, so welcome! Thankfully Pawel is not too far from my desk, and we (Pawel, Tomasz and myself) had a very fruitful in-person brainstorming session last week with Laurent, so this should limit the damage. In any case, I think that everybody agrees that this needs to be pushed forward. Chromium OS in particular has a big interest to see this feature landing upstream, so I will dedicate some cycles to this. Absolutely! From reading the meetings reports (e.g. https://www.spinics.net/lists/linux-media/msg106699.html) I understand that we want to support several use-cases with this and we already have several proposals with code. Chromium in a first time is interested in stateless codecs support, and this use-case also seems to be the simplest to implement, so we would like to start pushing in that direction first. This should give us a reasonably sized code base to rely upon and implement the other use-cases as we see clearer through this. I still need to study a bit the existing proposals and to clearly lay out the conclusions of our meeting with Laurent, but the general idea has not changed too much, except maybe that we thought it may be nice to make state management less explicit to userspace by default. I would be interested in knowing whether there are updated versions of the implementations mentioned in the meeting report above, and/or a merge of these work? Also, if someone is actively working on this at the moment, we will definitely want to sync on IRC or anywhere else. Laurent has been the last one working on this, but his code doesn't have the control handling :-( My latest (well, December 2015) tree with the control request code is here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests2 It's AFAIK a slightly newer version from what ChromeOS uses. Excited to work with you all! :) Looking forward to your code! Regards, Hans
Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats
On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote: Em Sun, 5 Mar 2017 18:00:32 +0800 Randy Liescreveu: The formats added by this patch are: V4L2_PIX_FMT_P010 V4L2_PIX_FMT_P010M V4L2_PIX_FMT_P016 V4L2_PIX_FMT_P016M Currently, none of driver uses those format. Also a variant of V4L2_PIX_FMT_P010M pixel format is added. The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010, Some developers from Gstreamer think it should be renamed as CM10 for the P010CM, I don't have much idea about that. which uses the unused 6 bits to store the next pixel. And with the alignment requirement of the hardware, it usually would be some extra space left at the end of a stride. You should check your patches with checkpatch... I'm getting this: WARNING: 'simliar' may be misspelled - perhaps 'similar'? #61: FILE: Documentation/media/uapi/v4l/pixfmt-p010.rst:13: +chroma samples as simliar to ``V4L2_PIX_FMT_NV12`` I am sorry about that WARNING: 'simliar' may be misspelled - perhaps 'similar'? #334: FILE: Documentation/media/uapi/v4l/pixfmt-p016.rst:13: +chroma samples as simliar to ``V4L2_PIX_FMT_NV12`` Signed-off-by: Randy Li --- Documentation/media/uapi/v4l/pixfmt-p010.rst | 126 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 125 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 + Documentation/media/uapi/v4l/yuv-formats.rst | 4 + include/uapi/linux/videodev2.h| 5 + 6 files changed, 529 insertions(+) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst b/Documentation/media/uapi/v4l/pixfmt-p010.rst new file mode 100644 index 000..59ed118 --- /dev/null +++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst @@ -0,0 +1,126 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _V4L2-PIX-FMT-P010: + +** +V4L2_PIX_FMT_P010 ('P010') +** + + +V4L2_PIX_FMT_P010 +Formats with ½ horizontal and vertical chroma resolution. One luminance and +one chrominance plane with alternating +chroma samples as simliar to ``V4L2_PIX_FMT_NV12`` It is probably ok to use the UTF symbol for 1/2, but you should check if both PDF and HTML outputs will be ok. I see, I would upload a new version later + + +Description +=== + +It is a two-plane versions of the YUV 4:2:0 format. The three +components are separated into two sub-images or planes. The Y plane is +first. The Y plane has 16 bits per pixel, but only 10 bits are used with the +rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane +immediately follows the Y plane in memory. The CbCr +plane is the same width, in bytes, as the Y plane (and of the image), +but is half as tall in pixels. Each CbCr pair belongs to four pixels. +For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`, +Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`. +If the Y plane has pad bytes after each row, then the CbCr plane has as +many pad bytes after its rows. + +**Byte Order.** +Each cell is two bytes. + + +.. flat-table:: +:header-rows: 0 +:stub-columns: 0 + +* - start + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` +* - start + 4: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` +* - start + 8: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` +* - start + 12: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` +* - start + 16: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` +* - start + 20: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + + +**Color Sample Location..** + +.. flat-table:: +:header-rows: 0 +:stub-columns: 0 + +* - + - 0 + - + - 1 + - 2 + - + - 3 +* - 0 + - Y + - + - Y + - Y + - + - Y +* - + - + - C + - + - + - C + - +* - 1 + - Y + - + - Y + - Y + - + - Y +* - +* - 2 + - Y + - + - Y + - Y + - + - Y +* - + - + - C + - + - + - C + - +* - 3 + - Y + - + - Y + - Y + - + - Y diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst b/Documentation/media/uapi/v4l/pixfmt-p010m.rst new file mode
Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
從我的 iPad 傳送 > Clint Taylor <clinton.a.tay...@intel.com> 於 2017年3月28日 上午6:49 寫道: > >> On 03/26/2017 09:05 PM, Ayaka wrote: >> >> >> 從我的 iPad 傳送 >> >>>> Ander Conselvan De Oliveira <conselv...@gmail.com> 於 2017年3月14日 下午9:53 寫道: >>>> >>>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote: >>>> >>>> 從我的 iPad 傳送 >>>> >>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道: >>>>>> >>>>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote: >>>>>> >>>>>> >>>>>> 從我的 iPad 傳送 >>>>>> >>>>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道: >>>>>>>> >>>>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote: >>>>>>>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits >>>>>>>> per channel video format. >>>>>>>> >>>>>>>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits >>>>>>>> per channel video format. >>>>>>>> >>>>>>>> V3: Added P012 and fixed cpp for P010 >>>>>>>> V4: format definition refined per review >>>>>>>> V5: Format comment block for each new pixel format >>>>>>>> V6: reversed Cb/Cr order in comments >>>>>>>> v7: reversed Cb/Cr order in comments of header files, remove >>>>>>>> the wrong part of commit message. >>>>>>> >>>>>>> What? Why? You just undid what Clint did in v6. >>>>>> >>>>>> He missed a file also keeping the wrong description of rockchip. >>>>> >>>>> I don't follow. Who missed what exactly? >>>> >>>> What he sent is v5, I increase the order number twice in the message, it >>>> confuse me as well. >>>> I think Clint forgot the include/uapi/drm/drm_fourcc.h . >>> >>> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h": >>> >>> https://patchwork.freedesktop.org/patch/141342/ >> Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr >> since I think the V is after the U. > > From the MSDN fourcc website: > "If the combined U-V array is addressed as an array of DWORDs, the least > significant word (LSW) contains the U value and the most significant word > (MSW) contains the V value. The stride of the combined U-V plane is equal to > the stride of the Y plane. The U-V plane has half as many lines as the Y > plane." > > The LSW contains U and the MSW contains V, hence the Cr:Cb in the comments of > the V6 patch. > > -Clint ok it is correct. I think I mistake it that is why my converter for gstreamer doesn't work > >>> >>> >>> Ander >>> >>>>> >>>>> >>>>>>> >>>>>>>> >>>>>>>> Cc: Daniel Stone <dan...@fooishbar.org> >>>>>>>> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> >>>>>>>> >>>>>>>> Signed-off-by: Randy Li <ay...@soulik.info> >>>>>>>> Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com> >>>>>>>> --- >>>>>>>> drivers/gpu/drm/drm_fourcc.c | 3 +++ >>>>>>>> include/uapi/drm/drm_fourcc.h | 21 + >>>>>>>> 2 files changed, 24 insertions(+) >>>>>>>> >>>>>>>> diff --git a/drivers/gpu/drm/drm_fourcc.c >>>>>>>> b/drivers/gpu/drm/drm_fourcc.c >>>>>>>> index 90d2cc8..3e0fd58 100644 >>>>>>>> --- a/drivers/gpu/drm/drm_fourcc.c >>>>>>>> +++ b/drivers/gpu/drm/drm_fourcc.c >>>>>>>> @@ -165,6 +165,9 @@ const struct drm_format_info >>>>>>>> *__drm_format_info(u32 format) >>>>>>>> { .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes = 1, >>>>>>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>>>>>> { .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes = 1, >>>>>>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>&g
Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
從我的 iPad 傳送 > Ander Conselvan De Oliveira <conselv...@gmail.com> 於 2017年3月14日 下午9:53 寫道: > >> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote: >> >> 從我的 iPad 傳送 >> >>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道: >>>> >>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote: >>>> >>>> >>>> 從我的 iPad 傳送 >>>> >>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道: >>>>>> >>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote: >>>>>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits >>>>>> per channel video format. >>>>>> >>>>>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits >>>>>> per channel video format. >>>>>> >>>>>> V3: Added P012 and fixed cpp for P010 >>>>>> V4: format definition refined per review >>>>>> V5: Format comment block for each new pixel format >>>>>> V6: reversed Cb/Cr order in comments >>>>>> v7: reversed Cb/Cr order in comments of header files, remove >>>>>> the wrong part of commit message. >>>>> >>>>> What? Why? You just undid what Clint did in v6. >>>> >>>> He missed a file also keeping the wrong description of rockchip. >>> >>> I don't follow. Who missed what exactly? >> >> What he sent is v5, I increase the order number twice in the message, it >> confuse me as well. >> I think Clint forgot the include/uapi/drm/drm_fourcc.h . > > Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h": > > https://patchwork.freedesktop.org/patch/141342/ Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr since I think the V is after the U. > > > Ander > >>> >>> >>>>> >>>>>> >>>>>> Cc: Daniel Stone <dan...@fooishbar.org> >>>>>> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> >>>>>> >>>>>> Signed-off-by: Randy Li <ay...@soulik.info> >>>>>> Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com> >>>>>> --- >>>>>> drivers/gpu/drm/drm_fourcc.c | 3 +++ >>>>>> include/uapi/drm/drm_fourcc.h | 21 + >>>>>> 2 files changed, 24 insertions(+) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c >>>>>> index 90d2cc8..3e0fd58 100644 >>>>>> --- a/drivers/gpu/drm/drm_fourcc.c >>>>>> +++ b/drivers/gpu/drm/drm_fourcc.c >>>>>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 >>>>>> format) >>>>>> { .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes = 1, >>>>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>>>> { .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes = 1, >>>>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>>>> { .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes = 1, >>>>>> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, >>>>>> +{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes = >>>>>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>>>> +{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes = >>>>>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>>>> +{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes = >>>>>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>>>> }; >>>>>> >>>>>> unsigned int i; >>>>>> diff --git a/include/uapi/drm/drm_fourcc.h >>>>>> b/include/uapi/drm/drm_fourcc.h >>>>>> index ef20abb..306f979 100644 >>>>>> --- a/include/uapi/drm/drm_fourcc.h >>>>>> +++ b/include/uapi/drm/drm_fourcc.h >>>>>> @@ -128,6 +128,27 @@ extern "C" { >>>>>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* >>>>>> non-subsampled Cb:Cr plane */ >>>>>> >>>>>> /* >>>>>> + * 2 plane YCbCr MSB aligned >>>>>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian >>>>>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian >>>>>> + */ >>>>>> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 >>>>>> subsampled Cb:Cr plane 10 bits per channel */ >>>>>> + >>>>>> +/* >>>>>> + * 2 plane YCbCr MSB aligned >>>>>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian >>>>>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian >>>>>> + */ >>>>>> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 >>>>>> subsampled Cb:Cr plane 12 bits per channel */ >>>>>> + >>>>>> +/* >>>>>> + * 2 plane YCbCr MSB aligned >>>>>> + * index 0 = Y plane, [15:0] Y little endian >>>>>> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian >>>>>> + */ >>>>>> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 >>>>>> subsampled Cb:Cr plane 16 bits per channel */ >>>>>> + >>>>>> +/* >>>>>> * 3 plane YCbCr >>>>>> * index 0: Y plane, [7:0] Y >>>>>> * index 1: Cb plane, [7:0] Cb >>>>>> -- >>>>>> 2.7.4 >>>>> >>>>> -- >>>>> Ville Syrjälä >>>>> Intel OTC >>> >>> -- >>> Ville Syrjälä >>> Intel OTC >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
從我的 iPad 傳送 > Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道: > >> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote: >> >> >> 從我的 iPad 傳送 >> >>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道: >>>> >>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote: >>>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits >>>> per channel video format. >>>> >>>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits >>>> per channel video format. >>>> >>>> V3: Added P012 and fixed cpp for P010 >>>> V4: format definition refined per review >>>> V5: Format comment block for each new pixel format >>>> V6: reversed Cb/Cr order in comments >>>> v7: reversed Cb/Cr order in comments of header files, remove >>>> the wrong part of commit message. >>> >>> What? Why? You just undid what Clint did in v6. >> He missed a file also keeping the wrong description of rockchip. > > I don't follow. Who missed what exactly? What he sent is v5, I increase the order number twice in the message, it confuse me as well. I think Clint forgot the include/uapi/drm/drm_fourcc.h . > > >>> >>>> >>>> Cc: Daniel Stone <dan...@fooishbar.org> >>>> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> >>>> >>>> Signed-off-by: Randy Li <ay...@soulik.info> >>>> Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com> >>>> --- >>>> drivers/gpu/drm/drm_fourcc.c | 3 +++ >>>> include/uapi/drm/drm_fourcc.h | 21 + >>>> 2 files changed, 24 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c >>>> index 90d2cc8..3e0fd58 100644 >>>> --- a/drivers/gpu/drm/drm_fourcc.c >>>> +++ b/drivers/gpu/drm/drm_fourcc.c >>>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 >>>> format) >>>> { .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes = 1, >>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>> { .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes = 1, >>>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>>> { .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes = 1, >>>> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, >>>> +{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes = 2, >>>> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>> +{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes = 2, >>>> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>> +{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes = 2, >>>> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>>> }; >>>> >>>> unsigned int i; >>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >>>> index ef20abb..306f979 100644 >>>> --- a/include/uapi/drm/drm_fourcc.h >>>> +++ b/include/uapi/drm/drm_fourcc.h >>>> @@ -128,6 +128,27 @@ extern "C" { >>>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* >>>> non-subsampled Cb:Cr plane */ >>>> >>>> /* >>>> + * 2 plane YCbCr MSB aligned >>>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian >>>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian >>>> + */ >>>> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 >>>> subsampled Cb:Cr plane 10 bits per channel */ >>>> + >>>> +/* >>>> + * 2 plane YCbCr MSB aligned >>>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian >>>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian >>>> + */ >>>> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 >>>> subsampled Cb:Cr plane 12 bits per channel */ >>>> + >>>> +/* >>>> + * 2 plane YCbCr MSB aligned >>>> + * index 0 = Y plane, [15:0] Y little endian >>>> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian >>>> + */ >>>> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 >>>> subsampled Cb:Cr plane 16 bits per channel */ >>>> + >>>> +/* >>>> * 3 plane YCbCr >>>> * index 0: Y plane, [7:0] Y >>>> * index 1: Cb plane, [7:0] Cb >>>> -- >>>> 2.7.4 >>> >>> -- >>> Ville Syrjälä >>> Intel OTC > > -- > Ville Syrjälä > Intel OTC
Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
從我的 iPad 傳送 > Ville Syrjälä於 2017年3月6日 下午9:06 寫道: > >> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote: >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits >> per channel video format. >> >> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits >> per channel video format. >> >> V3: Added P012 and fixed cpp for P010 >> V4: format definition refined per review >> V5: Format comment block for each new pixel format >> V6: reversed Cb/Cr order in comments >> v7: reversed Cb/Cr order in comments of header files, remove >> the wrong part of commit message. > > What? Why? You just undid what Clint did in v6. He missed a file also keeping the wrong description of rockchip. > >> >> Cc: Daniel Stone >> Cc: Ville Syrjälä >> >> Signed-off-by: Randy Li >> Signed-off-by: Clint Taylor >> --- >> drivers/gpu/drm/drm_fourcc.c | 3 +++ >> include/uapi/drm/drm_fourcc.h | 21 + >> 2 files changed, 24 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c >> index 90d2cc8..3e0fd58 100644 >> --- a/drivers/gpu/drm/drm_fourcc.c >> +++ b/drivers/gpu/drm/drm_fourcc.c >> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 >> format) >>{ .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes = 1, >> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>{ .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes = 1, >> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>{ .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes = 1, >> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, >> +{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes = 2, >> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >> +{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes = 2, >> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >> +{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes = 2, >> .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 }, >>}; >> >>unsigned int i; >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >> index ef20abb..306f979 100644 >> --- a/include/uapi/drm/drm_fourcc.h >> +++ b/include/uapi/drm/drm_fourcc.h >> @@ -128,6 +128,27 @@ extern "C" { >> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* >> non-subsampled Cb:Cr plane */ >> >> /* >> + * 2 plane YCbCr MSB aligned >> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian >> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian >> + */ >> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 >> subsampled Cb:Cr plane 10 bits per channel */ >> + >> +/* >> + * 2 plane YCbCr MSB aligned >> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian >> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian >> + */ >> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 >> subsampled Cb:Cr plane 12 bits per channel */ >> + >> +/* >> + * 2 plane YCbCr MSB aligned >> + * index 0 = Y plane, [15:0] Y little endian >> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian >> + */ >> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 >> subsampled Cb:Cr plane 16 bits per channel */ >> + >> +/* >> * 3 plane YCbCr >> * index 0: Y plane, [7:0] Y >> * index 1: Cb plane, [7:0] Cb >> -- >> 2.7.4 > > -- > Ville Syrjälä > Intel OTC
Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats
從我的 iPad 傳送 > Mauro Carvalho Chehab <mche...@s-opensource.com> 於 2017年2月3日 下午10:04 寫道: > > Em Thu, 5 Jan 2017 20:27:17 +0200 > Sakari Ailus <sakari.ai...@iki.fi> escreveu: > >> Hi Randy, >> >>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote: >>> >>> >>>> On 01/05/2017 06:30 PM, Sakari Ailus wrote: >>>> Hi Randy, >>>> >>>> Thanks for the update. >>>> >>>>> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote: >>>>> The formats added by this patch are: >>>>>V4L2_PIX_FMT_P010 >>>>>V4L2_PIX_FMT_P010M >>>>>V4L2_PIX_FMT_P016 >>>>>V4L2_PIX_FMT_P016M >>>>> Currently, none of driver uses those format, but some video device >>>>> has been confirmed with could as those format for video output. >>>>> The Rockchip's new decoder has supported those 10 bits format for >>>>> profile_10 HEVC/AVC video. >>>>> >>>>> Signed-off-by: Randy Li <ay...@soulik.info> >>>>> >>>>> v4l2 >>>>> --- >>>>> Documentation/media/uapi/v4l/pixfmt-p010.rst | 86 >>>>> Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++ >>>>> Documentation/media/uapi/v4l/pixfmt-p016.rst | 126 >>>>> >>>>> Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 >>>>> ++ >>>> You need to include the formats in pixfmt.rst in order to compile the >>>> documentation. >>>> >>>> $ make htmldocs >>>> >>>> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html . >>>> >>>> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme >>>> . >>> OK, I would fix them in new version. >>> The view of byte order for P010 serial is left empty, it is a little hard >>> for me to use flat-table to draw them. Is there possible to use something >>> like latex to do this job? >> >> Hmm. Not as far as I know. We recently switched from DocBook mostly due to >> ReST being more simple to use AFAIU. I think LaTeX output could be produced >> ReST, that might not be very helpful here though. > > No, you can't use LaTeX, as it won't be properly displayed on all output > formats. There are a few options to define tables in ReST, but we prefer > using flat-table because the other formats are harder to maintain at the > V4L2 uAPI documentation. > > Just one note about this series: it won't be merged upstream until > someone adds a driver needing those pixel formats. > I made a mistake, the pixel format I want is not P010, I would post a new patch for that. > Regards, > Mauro > > > Thanks, > Mauro -- 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: Request API: stateless VPU: the buffer mechanism and DPB management
On 01/17/2017 10:59 PM, Nicolas Dufresne wrote: Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a écrit : If we move parser or part of DPB management mechanism into kernel we will face a issue as follows: One customer requires dpb management do a flush when stream occurs in order to keep output frame clean. While another one requires output frame with error to keep output frame smooth. And when only one field has a error one customer wants to do a simple field copy to recover. The driver should send all frames and simply mark the corrupted frames using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their own decision. It is also important to keep track and cleanup the buffers meta's (which are application specific). If the driver silently drops frame, it makes that management much harder. About flushing and draining operation, they are respectively signalled to the driver using STREAMOFF and CMD_STOP. These are some operation related to strategy rather then mechanism. I think it is not a good idea to bring such kind of flexible process to kernel driver. So here is the ultimate challenge that how to reasonably move the parser and flexible process which is encapsuled in firmware to a userspace - kernel stateless driver model. Moving the parsers in the kernel (on the main CPU) is not acceptable. No, what is not what I said. What I want to do is "The whole plan in userspace is just injecting a parsing operation and set those v4l2 control in kernel before enqueue a buffer into OUTPUT, which would keep the most compatible with those stateful video IP(those with a firmware). " This is too much of a security threat. Userspace should parse the data into structures, doing any validation required before end. My main question and that should have an impact decision, is if those structures can be made generic. PDB handling is not that trivial (my reference is VAAPI here, maybe they are doing it wrong) and with driver specific structures, we would have this code copy-pasted over and over. So with driver specific structures, it's probably better to keep all the parsing and reordering logic outside (hence together). The result to keep DPB and re-order inside the kernel is want to be compatible with the original buffer operation. Anyway the DPB structure could be common. That remains, that some driver will deal with reordering on the firmware side (even the if they don't parse), hence we need to take this into consideration. No sure what do you mean, I think all those driver with firmware would do that. regards, Nicolas Hello all: I have recently finish the learning of the H.264 codec and ready to write the driver. Although I have not get deep in syntax of H.264 but I think I just need to reuse and extended the VA-API H264 Parser from gstreamer. The whole plan in userspace is just injecting a parsing operation and set those v4l2 control in kernel before enqueue a buffer into OUTPUT, which would keep the most compatible with those stateful video IP(those with a firmware). But in order to do that, I can't avoid the management of DPB. I decided to moving the DPB management job from userspace in kernel. Also the video IP(On2 on rk3288 and the transition video IP on those future SoC than rk3288, rkv don't have this problem) would a special way to manage the DPB, which requests the same reference frame is storing in the same reference index in the runtime(actually it is its Motion Vector data appended in decoded YUV data would not be moved). I would suggest to keep those job in kernel, the userspace just to need update the list0 and list1 of DPB. DPB is self managed in kernel the userspace don't need to even dequeue the buffer from CAPTURE until the re-order is done. The kernel driver would also re-order the CAPTURE buffer into display order, and blocking the operation on CAPTURE until a buffer is ready to place in the very display order. If I don't do that, I have to get the buffer once it is decoded, and marking its result with the poc, I could only begin the processing of the next frame only after those thing are done. Which would effect the performance badly. That is what chromebook did(I hear that from the other staff, I didn't get invoke in chromium project yet). So I would suggest that doing the re-order job in kernel, and inform the the userspace the buffers are ready when the new I frame(key frame) is pushed into the video IP. Although moving those job into kernel would increase the loading, but I think it is worth to do that, but I don't know whether all those thought are correct and high performance(It is more important than API compatible especially for those 4K video). And I want to know more ideas about this topic. I would begin the writing the new driver after the coming culture new year vacation(I would go to the Europe), I wish we can decide the final mechanism before I begin this job. -- To unsubscribe from this
Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats
On 01/05/2017 06:30 PM, Sakari Ailus wrote: Hi Randy, Thanks for the update. On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote: The formats added by this patch are: V4L2_PIX_FMT_P010 V4L2_PIX_FMT_P010M V4L2_PIX_FMT_P016 V4L2_PIX_FMT_P016M Currently, none of driver uses those format, but some video device has been confirmed with could as those format for video output. The Rockchip's new decoder has supported those 10 bits format for profile_10 HEVC/AVC video. Signed-off-by: Randy Liv4l2 --- Documentation/media/uapi/v4l/pixfmt-p010.rst | 86 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 126 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++ You need to include the formats in pixfmt.rst in order to compile the documentation. $ make htmldocs And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html . In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme . OK, I would fix them in new version. The view of byte order for P010 serial is left empty, it is a little hard for me to use flat-table to draw them. Is there possible to use something like latex to do this job? Regarding P010 and the rest --- I'm fine with that, considering also that NV12 was never a great name for a format... -- 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: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
從我的 iPad 傳送 > Daniel Stone於 2017年1月5日 上午1:02 寫道: > > Hi Randy, > >> On 4 January 2017 at 16:29, Randy Li wrote: >> index 90d2cc8..23c8e99 100644 >> --- a/drivers/gpu/drm/drm_fourcc.c >> +++ b/drivers/gpu/drm/drm_fourcc.c >> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 >> format) >>{ .format = DRM_FORMAT_UYVY,.depth = 0, >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>{ .format = DRM_FORMAT_VYUY,.depth = 0, >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 }, >>{ .format = DRM_FORMAT_AYUV,.depth = 0, >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, >> + /* FIXME a pixel in Y for P010 is 10 bits */ >> + { .format = DRM_FORMAT_P010,.depth = 0, >> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 }, > > It seems like P010 stores each Y component in a 16-bit value, with the > bottom 6 bits ignored. So I think cpp here should be 2. No, the rest bits are used to store the next pixel. The P010 is just a 10 bits color depth pixel format. > > Cheers, > Daniel -- 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: [PATCH 1/2] drm_fourcc: Add new P010 video format
On 01/04/2017 11:56 PM, Ville Syrjälä wrote: On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote: P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only) as the input video format. Signed-off-by: Randy Li--- include/uapi/drm/drm_fourcc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 9e1bb7f..d2721da 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -119,6 +119,7 @@ extern "C" { #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */ #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */ #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */ +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */ We could use a better description of the format here. IIRC there is 10bits of actual data contained in each 16bits. So there should be a proper comment explaning in which way the bits are stored. It is a little hard to describe P010, which leaves a problem cpp information in the new patches. Also I have no idea how to draw the byte-order table the rst document for v4l2. /* * 3 plane YCbCr -- 2.7.4 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
On 01/02/2017 07:07 PM, Sakari Ailus wrote: Hi, On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote: On 01/02/2017 05:10 PM, Sakari Ailus wrote: Hi Randy, Thanks for the patch. On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote: The formats added by this patch are: V4L2_PIX_FMT_P010 V4L2_PIX_FMT_P010M Currently, none of driver uses those format, but some video device has been confirmed with could as those format for video output. The Rockchip's new decoder has supported those format for profile_10 HEVC/AVC video. Signed-off-by: Randy Li <ay...@soulik.info> If the format resembles the existing formats but on a different bit depth, it should be named in similar fashion. Do you mean it would be better if it is called as NV12_10? If it otherwise resembles NV12 but just has 10 bits per pixel, I think NV12_10 is a good name for it. The main reason I don't like it is that there is a various of software having used the P010 for this kind of pixel format. It would leadi a conflict between them(and I never saw it is used as NV12_10), as the P010 is more common to be used. I left a problem unsolved for P010 in v4l2, P010 have two variant, little endian and big endian. Which could be easy identified in drm driver(there is a flag for all the big endian pixel format). Could you also add ReST documentation for the format, please? I will. The common requirement for merging patches that change interfaces has been that there's a user for that change. It'll still help you to get this The kernel used in rockchip has supported that format in drm driver, but just we don't have a agreement about the pixel format. As the Gstreamer and some others would call it with a P010_ prefix, but Mark(rockchip's drm author) prefer the something like NV12_10, that is why I sent out those patches, I want the upstream decided its final name. Ack. I think we haven't really tried to unify the format naming in the past between the two subsystems. If existing conventions exist on both regarding this format, then it's probably better to follow those. Cc Laurent as well. reviewed now so the interface that the future hopefully-in-mainline driver provides will not change. --- include/uapi/linux/videodev2.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 46e8a2e3..9e03f20 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -551,6 +551,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */ #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */ #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb 4:4:4 */ +#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr 4:2:0, 10 bits per channel */ /* two non contiguous planes - one Y, one Cr + Cb interleaved */ #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */ @@ -559,6 +560,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb 4:2:2 */ #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */ #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 macroblocks */ +#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr 4:2:0, 10 bits per channel */ /* three planes - Y Cb, Cr */ #define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0 */ -- 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: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
On 01/02/2017 05:10 PM, Sakari Ailus wrote: Hi Randy, Thanks for the patch. On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote: The formats added by this patch are: V4L2_PIX_FMT_P010 V4L2_PIX_FMT_P010M Currently, none of driver uses those format, but some video device has been confirmed with could as those format for video output. The Rockchip's new decoder has supported those format for profile_10 HEVC/AVC video. Signed-off-by: Randy LiIf the format resembles the existing formats but on a different bit depth, it should be named in similar fashion. Do you mean it would be better if it is called as NV12_10? Could you also add ReST documentation for the format, please? I will. The common requirement for merging patches that change interfaces has been that there's a user for that change. It'll still help you to get this The kernel used in rockchip has supported that format in drm driver, but just we don't have a agreement about the pixel format. As the Gstreamer and some others would call it with a P010_ prefix, but Mark(rockchip's drm author) prefer the something like NV12_10, that is why I sent out those patches, I want the upstream decided its final name. reviewed now so the interface that the future hopefully-in-mainline driver provides will not change. --- include/uapi/linux/videodev2.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 46e8a2e3..9e03f20 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -551,6 +551,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */ #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */ #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb 4:4:4 */ +#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr 4:2:0, 10 bits per channel */ /* two non contiguous planes - one Y, one Cr + Cb interleaved */ #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */ @@ -559,6 +560,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb 4:2:2 */ #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */ #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 macroblocks */ +#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr 4:2:0, 10 bits per channel */ /* three planes - Y Cb, Cr */ #define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0 */ -- 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: gstreamer: v4l2videodec plugin
在 2016年05月15日 15:41, Nicolas Dufresne 写道: Le vendredi 13 mai 2016 à 11:45 +0300, Stanimir Varbanov a écrit : One thing which bothers me is how the extra-controls property working, i.e. I failed to change the h264 profile for example with below construct: extra-controls="controls,h264_profile=4;" Yes, and profile should be negotiated with downstream in GStreamer. For common controls, like bitrate, it should be exposed as separate properties instead. Please try the new patches in https://github.com/hizukiayaka/gst-plugins-good And look at this commit https://github.com/hizukiayaka/gst-plugins-good/commit/92b99ba9322cf8a1039b877315b12bc9813e95cf NOTE: even you could set those extra controls and driver accepted. It doesn't mean it would work. I looked at the s5p-mfc driver, it just set it then leave it alone. I may fix this bug in the few weeks. Nicolas -- 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
[PATCH 2/3] [media] s5p-mfc: remove unnecessary check in try_fmt
We don't need to request the sizeimage or num_planes in try_fmt. Signed-off-by: ayaka <ay...@soulik.info> --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index a66a9f9..2f76aba 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1043,10 +1043,6 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f) mfc_err("failed to try output format\n"); return -EINVAL; } - if (pix_fmt_mp->plane_fmt[0].sizeimage == 0) { - mfc_err("must be set encoding output size\n"); - return -EINVAL; - } if ((dev->variant->version_bit & fmt->versions) == 0) { mfc_err("Unsupported format by this MFC version.\n"); return -EINVAL; @@ -1060,11 +1056,6 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f) mfc_err("failed to try output format\n"); return -EINVAL; } - - if (fmt->num_planes != pix_fmt_mp->num_planes) { - mfc_err("failed to try output format\n"); - return -EINVAL; - } if ((dev->variant->version_bit & fmt->versions) == 0) { mfc_err("Unsupported format by this MFC version.\n"); return -EINVAL; -- 2.5.5 -- 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
[PATCH 3/3] [media] s5p-mfc: fix a typo in s5p_mfc_dec
It is a cosmetic commit. Signed-off-by: ayaka <ay...@soulik.info> --- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c index f2d6376..391ed9c 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c @@ -573,7 +573,7 @@ static int vidioc_reqbufs(struct file *file, void *priv, struct s5p_mfc_ctx *ctx = fh_to_ctx(priv); if (reqbufs->memory != V4L2_MEMORY_MMAP) { - mfc_err("Only V4L2_MEMORY_MAP is supported\n"); + mfc_err("Only V4L2_MEMORY_MMAP is supported\n"); return -EINVAL; } -- 2.5.5 -- 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
[RESEND PATCH] [PATCH 0/3] A few patches make s5p-mfc work with Gstreamer
A user-space application will follow the V4l2 document, but I meet a problem when I test it with Gstreamer. I look at the V4l2 document, the driver check the external setting which the document not cover, so that is what the second patch do. The first patch comes from chromium project, but I didn't find it is merged, so I sent it again with new kernel API. But I have not test it with 4.6-rc6, as I meet sysmmu problem there. But all those patches have been confirmed at Linux 4.1.16. ayaka (3): [media] s5p-mfc: Add handling of buffer freeing reqbufs request [media] s5p-mfc: remove unnecessary check in try_fmt [media] s5p-mfc: fix a typo in s5p_mfc_dec drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 12 +++- 2 files changed, 4 insertions(+), 10 deletions(-) -- 2.5.5 -- 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
[PATCH 1/3] [media] s5p-mfc: Add handling of buffer freeing reqbufs request
The encoder forget the work to call hardware to release its buffers. This patch came from chromium project. I just change its code style and make the API match with new kernel. Signed-off-by: ayaka <ay...@soulik.info> --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index 034b5c1..a66a9f9 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1144,7 +1144,10 @@ static int vidioc_reqbufs(struct file *file, void *priv, return -EINVAL; if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) { if (reqbufs->count == 0) { + mfc_debug(2, "Freeing buffers\n"); ret = vb2_reqbufs(>vq_dst, reqbufs); + s5p_mfc_hw_call(dev->mfc_ops, release_codec_buffers, + ctx); ctx->capture_state = QUEUE_FREE; return ret; } -- 2.5.5 -- 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: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
Please also notice those patches (A few patches make s5p-mfc work with Gstreamer) I resent to mail recently. Without them, the encoder won't work with Gstreamer either. I hope it will be merged as soon as possible. 在 2016年05月07日 06:11, Javier Martinez Canillas 写道: From: ayaka <ay...@soulik.info> User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a memory mapped, user pointer or DMABUF based I/O is supported by the driver. So a set of VIDIOC_REQBUFS ioctl calls will be made with count 0 and then the real VIDIOC_REQBUFS call with count == n. But for count 0, the driver not only frees the buffer but also closes the MFC instance and s5p_mfc_ctx state is set to MFCINST_FREE. The VIDIOC_REQBUFS handler for the output device checks if the s5p_mfc_ctx state is set to MFCINST_INIT (which happens on an VIDIOC_S_FMT) and fails otherwise. So after a VIDIOC_REQBUFS(n), future VIDIOC_REQBUFS(n) calls will fails unless a VIDIOC_S_FMT ioctl calls happens before the reqbufs. But applications may first set the format and then attempt to determine the I/O methods supported by the driver (for example Gstramer does it) so the state won't be set to MFCINST_INIT again and VIDIOC_REQBUFS will fail. To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't close the MFC instance to allow future VIDIOC_REQBUFS(n) calls to succeed. Signed-off-by: ayaka <ay...@soulik.info> [javier: Rewrote changelog to explain the problem more detailed] Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> --- Hello, This is a resend of a patch posted by Ayaka some time ago [0]. Without $SUBJECT, trying to decode a video using Gstramer fails on an Exynos5422 Odroid XU4 board with following error message: $ gst-launch-1.0 filesrc location=test.mov ! qtdemux ! h264parse ! v4l2video0dec ! videoconvert ! autovideosink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... [ 3947.114756] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported [ 3947.114771] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported [ 3947.114903] reqbufs_output:484: Reqbufs called in an invalid state [ 3947.114913] reqbufs_output:510: Failed allocating buffers for OUTPUT queue ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: Failed to allocate required memory. Additional debug info: gstv4l2videodec.c(575): gst_v4l2_video_dec_handle_frame (): /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: Buffer pool activation failed ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... [0]: https://patchwork.linuxtv.org/patch/32794/ Best regards, Javier drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c index f2d6376ce618..8b9467de2d6a 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c @@ -474,7 +474,6 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx, ret = vb2_reqbufs(>vq_src, reqbufs); if (ret) goto out; - s5p_mfc_close_mfc_inst(dev, ctx); ctx->src_bufs_cnt = 0; ctx->output_state = QUEUE_FREE; } else if (ctx->output_state == QUEUE_FREE) { -- 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: [PATCH] s5p-mfc: correct the formats info for encoder
I am very sorry to forget the Sign-off again and thank you for reviewing. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- 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
[PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better to use it as default OUTPUT format. MFC v5 doesn't support NV21, I have tested it, for the SEC doc it is not supported either. Signed-off-by: ayaka ay...@soulik.info --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..4ea3796 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -32,7 +32,7 @@ #include s5p_mfc_intr.h #include s5p_mfc_opr.h -#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT +#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M #define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264 static struct s5p_mfc_fmt formats[] = { @@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = { .codec_mode = S5P_MFC_CODEC_NONE, .type = MFC_FMT_RAW, .num_planes = 2, - .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | - MFC_V8_BIT, + .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT, }, { .name = H264 Encoded Stream, -- 1.9.3 -- 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
[PATCH] s5p-mfc: correct the formats info for encoder
I am very sorry to forget the Sign-off again and thank you for reviewing. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- 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
[PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better to use it as default OUTPUT format. MFC v5 doesn't support NV21, I have tested it, for the SEC doc it is not supported either. Signed-off-by: ayaka ay...@soulik.info --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..4ea3796 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -32,7 +32,7 @@ #include s5p_mfc_intr.h #include s5p_mfc_opr.h -#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT +#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M #define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264 static struct s5p_mfc_fmt formats[] = { @@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = { .codec_mode = S5P_MFC_CODEC_NONE, .type = MFC_FMT_RAW, .num_planes = 2, - .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | - MFC_V8_BIT, + .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT, }, { .name = H264 Encoded Stream, -- 1.9.3 -- 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: [PATCH] s5p-mfc: correct the formats info for encoder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2014/09/23 00:28, Kamil Debski wrote: Hi Ayaka, Sorry for such a late reply - I just noticed this patch. The NV12M is supported by all the version of MFC, so it is better to use it as default OUTPUT format. MFC v5 doesn't support NV21, I have tested it, for the SEC doc it is not supported either. A proper Sign-off is missing here. Sorry to miss it again. According to the documentation of MFC v5 I have non-tiled format is supported. Which documentation were you looking at? But the V4L2_PIX_FMT_NV12MT is only supported by MFC_V5_BIT from your code, V4L2_PIX_FMT_NV12M is supported by all the version. From my documentation: ++ ENC_MAP_FOR_CUR0xC51C Memory structure setting register of the current frame.R/W 0x Bits NameDescription Reset Value [31:2] RESERVED Reserved0 [1:0] ENC_MAP_FOR_CUR Memory structure of the current frame 0 : Linear mode 3 : 64x32 tiled mode 0 ++ In the page 2277. The same result. I think the V4L2_PIX_FMT_NV12MT is 64x32 Tiles mode, but what I remove for MFC v5 is V4L2_PIX_FMT_NV21M. Best wishes, - -- ayaka -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUIFNLAAoJEPsGh4kgR4i5HcIP/2qwn7uIFq66qpSajXmtcLx3 3/wt8n26u6GhTMUnIJKZS07FGtv7qizUVqeY3WmfWQw3jLaUjZeVviVH08y3DrE8 +7Vjq2rxz57ou4bBtc4qIgTWB7z2yuVSpBOYUB94laItQ7KDap4EgLf89m4KaKTt 5nULR0byxXh+RuUOw80v0eP/TBz7SRfYZnulASV9QlGS6T3Xp6v4U6W8LbSbieR5 63PwPxYP7aDVb5R6qzaLIVXNuI53vn5VhrQ6JJUfKee5YSbkV/Ff6XK+7/P162Pn 5cVt06X+RUeZXHGqCroMNb9cdm+7JHOZL458NPn4NmTJnFcPNu6JzW9iLymHeHC8 iFmNhpDuHJBulKsW44lqKe1fHT22a5C/oJAI1ZS9c3yrH+TqHkfEkUJjglSRByzj ptTFFZVTCdiL5VwnDlfowR4ZzrkZuoWzHIn5cGeHogvbLbxCbtV67+IFpWlXfyJu rKnCI+DKYb5cjEiHm7kzGbAO04AfNMT79sNwrD+sPuvnaFyRiy2rjKv3ubnPFRVp 3agNRzAcCgmsW3K10P3ism4ceJUqeZtFvieCQrjiQdxj8EB7QAcgOhgn3K//zrQ1 mQP7xuVQcwpaRIOx/3jSlVWYFrkFs2+tmgS9oEn+v40gXOQXk8rML21gHvpDuCnf qJXx0UVYQRV7Bhgv8EFW =SNTL -END PGP SIGNATURE- -- 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
[PATCH] media: fix enum_fmt for s5p-mfc
As the s5p-mfc is a driver which use multiplanar api, so the vidioc_enum_fmt_vid serial of ioctl should only for multiplanar, non-multiplanar shouldn't be implemented at all. Signed-off-by: ayaka ay...@soulik.info --- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 24 +++- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++- 2 files changed, 6 insertions(+), 42 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c index 4d93835..6611a7a 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c @@ -283,17 +283,13 @@ static int vidioc_querycap(struct file *file, void *priv, /* Enumerate format */ static int vidioc_enum_fmt(struct file *file, struct v4l2_fmtdesc *f, - bool mplane, bool out) + bool out) { struct s5p_mfc_dev *dev = video_drvdata(file); struct s5p_mfc_fmt *fmt; int i, j = 0; for (i = 0; i ARRAY_SIZE(formats); ++i) { - if (mplane formats[i].num_planes == 1) - continue; - else if (!mplane formats[i].num_planes 1) - continue; if (out formats[i].type != MFC_FMT_DEC) continue; else if (!out formats[i].type != MFC_FMT_RAW) @@ -313,28 +309,16 @@ static int vidioc_enum_fmt(struct file *file, struct v4l2_fmtdesc *f, return 0; } -static int vidioc_enum_fmt_vid_cap(struct file *file, void *pirv, - struct v4l2_fmtdesc *f) -{ - return vidioc_enum_fmt(file, f, false, false); -} - static int vidioc_enum_fmt_vid_cap_mplane(struct file *file, void *pirv, struct v4l2_fmtdesc *f) { - return vidioc_enum_fmt(file, f, true, false); -} - -static int vidioc_enum_fmt_vid_out(struct file *file, void *priv, - struct v4l2_fmtdesc *f) -{ - return vidioc_enum_fmt(file, f, false, true); + return vidioc_enum_fmt(file, f, false); } static int vidioc_enum_fmt_vid_out_mplane(struct file *file, void *priv, struct v4l2_fmtdesc *f) { - return vidioc_enum_fmt(file, f, true, true); + return vidioc_enum_fmt(file, f, true); } /* Get format */ @@ -878,9 +862,7 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh, /* v4l2_ioctl_ops */ static const struct v4l2_ioctl_ops s5p_mfc_dec_ioctl_ops = { .vidioc_querycap = vidioc_querycap, - .vidioc_enum_fmt_vid_cap = vidioc_enum_fmt_vid_cap, .vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane, - .vidioc_enum_fmt_vid_out = vidioc_enum_fmt_vid_out, .vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane, .vidioc_g_fmt_vid_cap_mplane = vidioc_g_fmt, .vidioc_g_fmt_vid_out_mplane = vidioc_g_fmt, diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index 3abe468..4725a6f 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -953,17 +953,13 @@ static int vidioc_querycap(struct file *file, void *priv, } static int vidioc_enum_fmt(struct file *file, struct v4l2_fmtdesc *f, - bool mplane, bool out) + bool out) { struct s5p_mfc_dev *dev = video_drvdata(file); struct s5p_mfc_fmt *fmt; int i, j = 0; for (i = 0; i ARRAY_SIZE(formats); ++i) { - if (mplane formats[i].num_planes == 1) - continue; - else if (!mplane formats[i].num_planes 1) - continue; if (out formats[i].type != MFC_FMT_RAW) continue; else if (!out formats[i].type != MFC_FMT_ENC) @@ -983,28 +979,16 @@ static int vidioc_enum_fmt(struct file *file, struct v4l2_fmtdesc *f, return -EINVAL; } -static int vidioc_enum_fmt_vid_cap(struct file *file, void *pirv, - struct v4l2_fmtdesc *f) -{ - return vidioc_enum_fmt(file, f, false, false); -} - static int vidioc_enum_fmt_vid_cap_mplane(struct file *file, void *pirv, struct v4l2_fmtdesc *f) { - return vidioc_enum_fmt(file, f, true, false); -} - -static int vidioc_enum_fmt_vid_out(struct file *file, void *prov, - struct v4l2_fmtdesc *f) -{ - return vidioc_enum_fmt(file, f, false, true); + return vidioc_enum_fmt(file, f, false); } static int vidioc_enum_fmt_vid_out_mplane(struct file *file
[PATCH] fix enum_fmt for s5p-mfc
The patch remove the non-multiplanar api for enum_fmt in s5p-mfc. Now enum_fmt in the driver will only work with multiplanar. I think it is a bug, hverkuil think it is too. so I made this patch. Actually gstreamer doesn't care about it, it will merge the result from non-multiplanar and multiplanar. ayaka (1): media: fix enum_fmt for s5p-mfc drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 24 +++- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++- 2 files changed, 6 insertions(+), 42 deletions(-) -- 1.9.3 -- 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
[PATCH] fix enum_fmt for s5p-mfc
The patch remove the non-multiplanar api for enum_fmt in s5p-mfc. Now enum_fmt in the driver will only work with multiplanar. I think it is a bug, hverkuil think it is too. so I made this patch. Actually gstreamer doesn't care about it, it will merge the result from non-multiplanar and multiplanar. ayaka (1): media: fix enum_fmt for s5p-mfc drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 24 +++- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++- 2 files changed, 6 insertions(+), 42 deletions(-) -- 1.9.3 -- 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
[PATCH] correct formats info in s5p-mfc encoder
I have tested it in exynos 4412. I enable MFC and with 64MB buffer in echo bank. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- 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
[PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better to use it as default OUTPUT format. MFC v5 doesn't support NV21, I have tested it, for the SEC doc it is not supported either. --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..4ea3796 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -32,7 +32,7 @@ #include s5p_mfc_intr.h #include s5p_mfc_opr.h -#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT +#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M #define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264 static struct s5p_mfc_fmt formats[] = { @@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = { .codec_mode = S5P_MFC_CODEC_NONE, .type = MFC_FMT_RAW, .num_planes = 2, - .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | - MFC_V8_BIT, + .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT, }, { .name = H264 Encoded Stream, -- 1.9.3 -- 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
[PATCH] s5p-mfc: encoder handles buffers freeing
Add handling of buffer freeing reqbufs request to the encoder of s5p-mfc. Signed-off-by: ayaka ay...@soulik.info --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..74fb80b 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1166,6 +1166,11 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(D)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + ctx-capture_state = QUEUE_FREE; + return ret; + } ctx-capture_state = QUEUE_BUFS_REQUESTED; ret = s5p_mfc_hw_call(ctx-dev-mfc_ops, @@ -1200,6 +1205,11 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(S)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + ctx-output_state = QUEUE_FREE; + return ret; + } ctx-output_state = QUEUE_BUFS_REQUESTED; } else { mfc_err(invalid buf type\n); -- 1.9.3 -- 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: [PATCH] s5p-mfc: encoder handles buffers freeing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 于 2014年07月04日 12:13, Pawel Osciak 写道: Hi, On Fri, Jul 4, 2014 at 12:39 PM, ayaka ay...@soulik.info mailto:ay...@soulik.info wrote: Add handling of buffer freeing reqbufs request to the encoder of s5p-mfc. Signed-off-by: ayaka ay...@soulik.info mailto:ay...@soulik.info We've had a verified and tested fix for this in ChromeOS tree for some time now, but haven't gotten to upstreaming it yet. It's a combination of the below two diffs: https://chromium-review.googlesource.com/#/c/65926/2/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c https://chromium-review.googlesource.com/#/c/66624/2/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c Have you tested and verified your patch? Unless I'm looking at a different base, it will not work, because: Yes I have do a little test, but the patch was for gstreamer project, it mainly used it on buffer allocation detecting, so I forget it again even I have been told. - the call to reqbufs it too late and will not execute, because the check for state != QUEUE_FREE above it will be true and you'll hit the early return; - it will also leak private buffer memory, as you can see in the above patches, you also need to release_codec_buffers on the OUTPUT queue. Please ignore my patch, I am so careless and making so much mistake and I didn't know a project have done that. Thank you for telling me that. Thanks, Pawel --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..74fb80b 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1166,6 +1166,11 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(D)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + ctx-capture_state = QUEUE_FREE; + return ret; + } ctx-capture_state = QUEUE_BUFS_REQUESTED; ret = s5p_mfc_hw_call(ctx-dev-mfc_ops, @@ -1200,6 +1205,11 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(S)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + ctx-output_state = QUEUE_FREE; + return ret; + } ctx-output_state = QUEUE_BUFS_REQUESTED; } else { mfc_err(invalid buf type\n); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTti7PAAoJEPsGh4kgR4i5peYQAIZYX8rWsiPnG4SDo4DryffI g8CnfNr6ndmgxbKiW4OLceSmFmWwmrJj+JQT5fMtO7psAhRL3VmsTZOAn5eMxkpc z4+/etqF+vKCR/UJf6MeUN/Q4P4RitFulWNGgSfBP0DWoQcxTVdFFSfWBMAEKClI +11IbN/5IEvRNcGfc9S4sZxwuTOyxrPCMT+X8LayO8zDBC/qMpoOjlFMH2buPCu7 SsvEMjk6AZtIl7oTSF7saPO+Y6C13vuJZHcjCLI7rZlJb5+JajorERNMTqnYZb9j Qa9jeeTqjtsA42L3y+JUNh6TPjXlF0dZYFfMBQvvaKBNyvKbB+jXkujUJpLZY09F 6baVb/JQlkCehLhi7GUlhKtghgDxXBRBGmw0U7FMA6C4pDr8Z67O4ePdfM1MmPbV FwBjDALWJuioWiSwZFzhU/lzAhypN5EFKNMKa+pS8SJuU9S1PwURP3VQaV8y7urR NTsiHyC53JL5wYzfn52jQMcYOC06W+ABjlB2i4L2kmSxfNrexdWZbIH0VLTaHKqt e1Wl1ZDLXYjE8UXfxbmIOLaSYOPRc5iAkXfB1PpTlETdIvc0znC/dV7xPY2Im6p3 Yc6FnDus6oSP4Lxo+NrIGs4TcqF2cTvHu7QPikFTRIr1bCD1NFTp3L8w1Jlk999q 72b9+Bg5FebefLBseNi1 =3KV/ -END PGP SIGNATURE- -- 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
[PATCH] s5p-mfc: encoder could free buffers
[PATCH] s5p-mfc: encoder could free buffers The patch is necessary or the buffers could be freeed but it would break the state of encoder in s5p-mfc. It is also need by some application which would detect the buffer allocation way, like gstreamer. --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index d26b248..1a7518f 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1166,6 +1166,10 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(D)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + return ret; + } ctx-capture_state = QUEUE_BUFS_REQUESTED; ret = s5p_mfc_hw_call(ctx-dev-mfc_ops, @@ -1200,6 +1204,10 @@ static int vidioc_reqbufs(struct file *file, void *priv, mfc_err(error in vb2_reqbufs() for E(S)\n); return ret; } + if (reqbufs-count == 0) { + mfc_debug(2, Freeing buffers\n); + return ret; + } ctx-output_state = QUEUE_BUFS_REQUESTED; } else { mfc_err(invalid buf type\n); -- 1.9.1 -- 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
mfc: fixed the request buffer but failed in enqueue a dequeued OUTPUT(input)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My kernel is 3.13.7, as I have reported before, mfc encoder can't request buffer, I increase the mfc size in dts file from 0x80 to 0x400, then it can request buffer now, but it can't enqueue the input(OUTPUT in v4l2 side) buffer which is just dequeued after stream has start. Here is the log of samsung demo, I don't get any information in dmesg root@kagami:~# ./mfc-encode -m /dev/video1 -c h264 mfc codec encoding example application Andrzej Hajda a.ha...@samsung.com Copyright 2012 Samsung Electronics Co., Ltd. 50.370398146:args.c:parse_args:187: codec: H264 50.386230729:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3 50.402226771:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16 buffers for device 3:0 50.402356979:func_dev.c:func_req_bufs:42: Succesfully requested 16 buffers for device -1:1 50.402523896:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1 50.402677896:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1 50.402819771:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1 50.403051729:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1 50.403199646:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1 50.403604562:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1 50.403880187:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1 50.404194396:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1 50.404580146:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1 50.404951021:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1 50.405400896:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1 50.405554729:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1 50.405721271:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1 50.405791896:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1 50.405933604:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1 50.406003646:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1 50.473507729:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 4 buffers for device 3:1 50.473621146:func_dev.c:func_req_bufs:42: Succesfully requested 4 buffers for device 4:0 50.473815312:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 0/4 to 3:1 50.474005771:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 1/4 to 3:1 50.474252854:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 2/4 to 3:1 50.474754854:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 3/4 to 3:1 State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/250] [Off 0 0/0|Off 4 0/0] [Off 0 0/0|Off 0 0/0] State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/250] [Off 0 0/0|Off 4 0/0] [Off 0 0/0|Off 0 0/0] 50.476985521:func_dev.c:func_deq_buf:79: Dequeued buffer 0/16 from - -1:1 ret=25344 v4l_dev.c:v4l_enq_buf:207: error: Error 22 enq buffer 0/16 to 3:0 50.477464521:io_dev.c:process_chain:165: pair 0:1 ret=-1 I have tried [Linaro-mm-sig] [PATCH][RFC] mm: Don't put CMA pages on per-cpu lists but it doesn't have any effect and if I don't modify the size in dts it will failed in request buffer either. In the program wroten by myself(I have tested work in manufacturer's 3.5 kernel), it can't dequeue the OUPUT at all neither the second frame in CAPTURE(with V4L2_CID_MPEG_VIDEO_HEADER_MODE in 0), of course, there is not any frame in OUTPUT, it is impossible to get the the second frame in CAPTURE. Thank you ayaka -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJTNrvoAAoJEPb4VsMIzTziUtwH/RBoyPSLUieV+fJ0+/KkvBxN WlkFATzPJD+AuiF0co2ggWrx0DnA1M8qFGHecNJW6mf+oL9+kz+2ASFBT+g224Pa q5m1ykAGGnfo1sVtcMOf+HcDxq2dYMG9AD8Cjo39oPZXxgeJLRl2Wd/uePIBIj/H IBGHX7I94XCAgU9OzMq8TviqwE9pyXVMNCa9DX0XBGYKuJDkeKVgXZXt/loGa1BZ IV74aS0jKN8iO7npWSgpTvWG4nSDtw7arDfPTR1N6CsqgJvY+z9K0sr3LFIzu/UW gPUW+eK08qyeemZr5W39akf56x/B+pua8npB+H3NKSxVysTgVvBZ5YieupEfXrE= =gquq -END PGP SIGNATURE- -- 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