from:"ayaka"

Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support

2017-07-11 Thread ayaka




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

2017-07-07 Thread ayaka




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

2017-07-07 Thread ayaka




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

2017-06-12 Thread ayaka


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

2017-06-08 Thread ayaka




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 Osciak  wrote:

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

2017-04-21 Thread ayaka




On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote:

Em Sun,  5 Mar 2017 18:00:32 +0800
Randy Li  escreveu:


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

2017-03-27 Thread Ayaka



從我的 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

2017-03-26 Thread Ayaka



從我的 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

2017-03-06 Thread Ayaka



從我的 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

2017-03-06 Thread Ayaka



從我的 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

2017-02-08 Thread Ayaka



從我的 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

2017-01-17 Thread ayaka




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

2017-01-05 Thread ayaka




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 

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?


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

2017-01-04 Thread Ayaka



從我的 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

2017-01-04 Thread ayaka




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

2017-01-02 Thread ayaka




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

2017-01-02 Thread ayaka




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 

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?


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-19 Thread ayaka




在 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

2016-05-06 Thread ayaka

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

2016-05-06 Thread ayaka

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

2016-05-06 Thread ayaka

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

2016-05-06 Thread ayaka

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

2016-05-06 Thread ayaka

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

2014-10-22 Thread ayaka

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

2014-10-22 Thread ayaka

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

2014-10-22 Thread ayaka

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

2014-10-22 Thread ayaka

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

2014-09-22 Thread ayaka

-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

2014-09-18 Thread ayaka

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

2014-09-18 Thread ayaka

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

2014-09-04 Thread ayaka

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

2014-07-23 Thread ayaka

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

2014-07-23 Thread ayaka

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

2014-07-03 Thread ayaka

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

2014-07-03 Thread ayaka


-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

2014-06-26 Thread ayaka

[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)

2014-03-29 Thread ayaka

-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

37 matches

Mail list logo