On 4/12/19 12:12 AM, Nicolas Dufresne wrote:
Le jeudi 11 avril 2019 à 09:29 +0800, Randy Li a écrit :
We agreed with Maxime and Ezequiel that there will be two distinct
format, V4L2_PIX_FMT_H264_SLICE_RAW and V4L2_PIX_FMT_H264_SLICE_ANNEXB.
And user-pace will take care of providing the right i
Sent from my iPad
> On Apr 11, 2019, at 12:01 AM, Nicolas Dufresne wrote:
>
>> Le mercredi 10 avril 2019 à 20:42 +0800, ayaka a écrit :
>> From: Randy 'ayaka' Li
>>
>> Although I really hate the bitstream construction in kernel and I think
>>
Sent from my iPad
> On Apr 11, 2019, at 12:01 AM, Nicolas Dufresne wrote:
>
>> Le mercredi 10 avril 2019 à 20:42 +0800, ayaka a écrit :
>> From: Randy 'ayaka' Li
>>
>> Although I really hate the bitstream construction in kernel and I think
>>
From: Randy Li
Having problem with vepu2
The sclk_vdec_core for RKVDEC is in gpll at vendor kernel.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 32 ++
.../arm64/boot/dts/rockchip/rk3328-rock64.dts | 32 ++
arch/arm64/boot/dts/rockchip/rk3328.dtsi
From: Randy Li
Or VOP won't work well.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 84f14b132e8f..55a72abed
From: Randy Li
I want the memory region !!!
It can save more time if those data are prepared in userspace.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/mpp_dev_common.c | 3 +--
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 ---
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c |
From: Randy Li
I don't care, I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 +++
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 5 -
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 13 -
I really don't want to do this.
Signed-off-by: Randy Li
Signed-off-by: ayaka
---
drivers/staging/rockchip-mpp/Makefile | 2 +-
drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 8 +-
.../staging/rockchip-mpp/rkvdec/avc-data.c| 239 ++
.../staging/rockchi
I found the offset for cpu access is not equal to the DMA
opeartion.
Signed-off-by: ayaka
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 +++
drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 3 +++
drivers/staging/rockchip-mpp/rkvdec/avc.c | 14 +++---
3 files changed, 13
From: Randy Li
Not done yet, not enough data.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/Makefile | 4 +-
.../staging/rockchip-mpp/rkvdec/hevc-data.c | 208 ++
.../staging/rockchip-mpp/rkvdec/hevc-data.h | 27 +++
drivers/staging/rockchip-mpp/rkvdec
From: Randy Li
It is a bit writer.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/rkvdec/rbsp.c | 96 ++
drivers/staging/rockchip-mpp/rkvdec/rbsp.h | 30 +++
2 files changed, 126 insertions(+)
create mode 100644 drivers/staging/rockchip-mpp/rkvdec/rbsp.c
cre
From: Randy 'ayaka' Li
Although I really hate the bitstream construction in kernel and I think
many people realise its problems, I still take the advise from ndufresne to
release this version. This should be released in a early week but
I was sick that time.
After reviewed the docu
On 3/12/19 4:22 PM, Tomasz Figa wrote:
On Thu, Feb 28, 2019 at 12:13 AM Ayaka wrote:
Hello all
I am writing the v4l2 decoder driver for rockchip. Although I hear the suggest
from the Hans before, it is ok for decoder to use single plane buffer format,
but I still decide to the multi
Sent from my iPad
> On Mar 1, 2019, at 12:21 AM, Nicolas Dufresne wrote:
>
> Le jeudi 28 février 2019 à 09:12 +0800, Ayaka a écrit :
>>> On Feb 28, 2019, at 5:07 AM, Nicolas Dufresne wrote:
>>>
>>> Hi Ayaka,
>>>
>>>> Le mercredi
> On Feb 28, 2019, at 5:07 AM, Nicolas Dufresne wrote:
>
> Hi Ayaka,
>
>> Le mercredi 27 février 2019 à 23:13 +0800, Ayaka a écrit :
>> Last time in FOSDEM, kwiboo and I talk some problems of the request
>> API and stateless decoder, I say the a method to
Hello all
I am writing the v4l2 decoder driver for rockchip. Although I hear the suggest
from the Hans before, it is ok for decoder to use single plane buffer format,
but I still decide to the multi planes format.
There is not a register for vdpau1 and vdpau2 setting the chroma starting
addres
Sent from my iPad
> On Jan 31, 2019, at 10:03 PM, Ezequiel Garcia wrote:
>
> Hey Ayaka!
>
>> On Thu, 2019-01-31 at 11:13 +0800, ayaka wrote:
>> From: Randy 'ayaka' Li
>>
>> Hello
>> Those patches are based on the previous vendor d
Yes, the buffer won't be freed.
I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
Signed-off-by: ayaka
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 ++
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 3 ++
drivers/staging/rockchip
From: Randy Li
Signed-off-by: Randy Li
---
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e4f608815c05..81634dd0a283 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/stagin
From: Randy 'ayaka' Li
Hello
Those patches are based on the previous vendor driver I post before,
but it can apply without the previous one.
I really want to make it work before FOSDEM and I didn't. And upcoming
the lunar new year holiday would last two week.
I have verifie
From: Randy 'ayaka' Li
It doesn't work yet, I am suffering unknow power or
clock problem, but the vendor driver I post to ML
would work.
I want to put the implementation of those v4l2 ioctl
which related to device in echo device's files, but
the current inheritance looks u
From: Randy 'ayaka' Li
The current version is designed for multi-planes
buffers.
TODO:
improve the interface and work flow of v4l2
finish a task before it would be dequeued
Signed-off-by: Randy Li
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/Kconfig | 54
Sent from my iPad
> On Jan 30, 2019, at 3:17 PM, Tomasz Figa wrote:
>
>> On Wed, Jan 30, 2019 at 3:28 PM Ayaka wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>> On Jan 30, 2019, at 11:35 AM, Tomasz Figa wrote:
>>>
>&
Sent from my iPad
> On Jan 30, 2019, at 5:41 AM, Nicolas Dufresne wrote:
>
>> Le mardi 29 janvier 2019 à 16:44 +0900, Alexandre Courbot a écrit :
>> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
>> wrote:
>>> Hi,
>>>
>>>> On Thu,
r 2019 à 16:44 +0900, Alexandre Courbot a écrit :
>>>> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
>>>>>> Sent from my i
Sent from my iPad
> On Jan 24, 2019, at 10:23 PM, Maxime Ripard wrote:
>
> Hi!
>
> On Sun, Jan 20, 2019 at 08:48:32PM +0800, ayaka wrote:
>>>>> +struct v4l2_ctrl_h264_scaling_matrix {
>>>>> +__u8 scaling_list_4x4[6][16];
>>>>>
Sent from my iPad
> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>> I forget a important thing, for the rkvdec and rk hevc decoder, it would
>> requests cabac table, scaling list, pi
Sent from my iPad
> On Jan 24, 2019, at 6:36 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Tue, 2019-01-08 at 18:00 +0800, Ayaka wrote:
>>
>> Sent from my iPad
>>
>>> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
>>> wrote:
I am sorry I am a little busy for the lunar new year recently and the
H.264 syntax rules are little complex, I will try explain my ideas more
clear here.
On 1/17/19 7:01 PM, Maxime Ripard wrote:
Hi,
On Tue, Jan 08, 2019 at 05:52:28PM +0800, Randy 'ayaka' Li wrote
and rps, it is possible to reuse the slice header, just let
the decoder know the offset from the bitstream bufer, I would suggest to
add three properties(with sps) for them. But I think we need a method to
mark a OUTPUT side buffer for those aux data.
On 1/9/19 1:01 AM, ayaka wrote:
On 1/8/19 5
and rps, it is possible to reuse the slice header, just let
the decoder know the offset from the bitstream bufer, I would suggest to
add three properties(with sps) for them. But I think we need a method to
mark a OUTPUT side buffer for those aux data.
On 1/8/19 6:00 PM, Ayaka wrote:
Sent from
n't
>>> copy what's written from external docs, you could take a look at the
>>> Internet for the P010 descriptions, and use the pixfmt-yuy420m.rst file
>>> as the basis for a new pixfmt-p010.rst file.
>>
>> There is some work done on this but it&#x
On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:
On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:
From: Pawel Osciak
Stateless video codecs will require both the H264 metadata and slices in
order to be able to decode frames.
This introduces the definitions for a new pi
Sent from my iPad
> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>>
>> Sent from my iPad
>>
>>> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski
>>> wrote:
On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:
> From: Pawel Osciak
>
> Stateless video codecs will require both the H264 metadata and slices in
> order to be able to decode frames.
>
> This introduces the definitions for a new pixel format for H264 slices that
> have been parsed
Sent from my iPad
> On Jan 8, 2019, at 2:33 PM, Tomasz Figa wrote:
>
>> On Mon, Jan 7, 2019 at 2:30 AM Ayaka wrote:
>>
>> Hello Ezequiel
>>
>> Sent from my iPad
>>
>>>> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia
>>>
8slice_act_cb_qp_offset;
>>>>> +__s8slice_act_cr_qp_offset;
>>>>> +__u8slice_deblocking_filter_disabled_flag;
>>>>> +__s8slice_beta_offset_div2;
>>>>> +__s8slice_tc_offset_div2;
>>>>&g
Hello Ezequiel
Sent from my iPad
> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia
> wrote:
>
>> On Sun, 6 Jan 2019 at 13:16, Ayaka wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia wrote:
&
Sent from my iPad
> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia wrote:
>
> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote:
>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia wrote:
>>>
>>> Hi Randy,
>>>
>>> Thanks a lot for this patch
> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia wrote:
>
> Hi Randy,
>
> Thanks a lot for this patches. They are really useful
> to provide more insight into the VPU hardware.
>
> This change will make the vpu encoder and vpu decoder
> completely independent, can they really work in parallel?
> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia wrote:
>
> Hi Randy,
>
> Thanks a lot for this patches. They are really useful
> to provide more insight into the VPU hardware.
>
> This change will make the vpu encoder and vpu decoder
> completely independent, can they really work in parallel?
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
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
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 s
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, statele
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
or
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 forma
從我的 iPad 傳送
> Clint Taylor 於 2017年3月28日 上午6:49 寫道：
>
>> On 03/26/2017 09:05 PM, Ayaka wrote:
>>
>>
>> 從我的 iPad 傳送
>>
>>>> Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
>>>>
>>>> On Tue, 2017-03-07 at 04:27
從我的 iPad 傳送
> Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
>
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>>
>> 從我的 iPad 傳送
>>
>>>> Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
>>>>
>>>> On Tue, Mar 07, 2
從我的 iPad 傳送
> Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
>
>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>>
>>
>> 從我的 iPad 傳送
>>
>>>> Ville Syrjälä 於 2017年3月6日 下午9:06 寫道：
>>>>
>>>> On Sun, Mar 05, 2017 a
從我的 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 vi
從我的 iPad 傳送
> Mauro Carvalho Chehab 於 2017年2月3日 下午10:04 寫道：
>
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus escreveu:
>
>> Hi Randy,
>>
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>>
>>>
>>&g
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
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, non
從我的 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
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:
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
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
h
在 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=
We don't need to request the sizeimage or num_planes
in try_fmt.
Signed-off-by: ayaka
---
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
It is a cosmetic commit.
Signed-off-by: ayaka
---
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
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: r
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
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 3 +++
1 file changed, 3 insertions(+)
diff
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
User-
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
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file chang
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
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
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file chang
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
-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
lanar.
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
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
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 24 +++-
drivers/
lanar.
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
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
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 24 +++-
drivers/
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(
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
于 2014年07月04日 12:13, Pawel Osciak 写道:
> Hi,
>
> On Fri, Jul 4, 2014 at 12:39 PM, ayaka mailto:ay...@soulik.info>> wrote:
>
> Add handling of buffer freeing reqbufs request to the encoder of
> s5p-mfc.
>
>
Add handling of buffer freeing reqbufs request to the encoder of
s5p-mfc.
Signed-off-by: ayaka
---
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
[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 |
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+AuiF0c
79 matches
Mail list logo
