[PATCH 0/5] s5p-fimc: Misc fixes

This patch series fixes several bugs found in the s5p-fimc driver. These bugs relate to bad parameters in the formats definition and short size of image buffers. Nicolas Dufresne (5): s5p-fimc: Reuse calculated sizes s5p-fimc: Iterate for each memory plane s5p-fimc: Align imagesize to row

[PATCH 1/5] s5p-fimc: Changed RGB32 to BGR32

Testing showed that HW produces BGR32 rather then RGB32 as exposed in the driver. The documentation seems to state the pixels are stored in little endian order. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 4 ++-- 1 file

[PATCH 2/5] s5p-fimc: Fix YUV422P depth

All YUV 422 has 16bit per pixels. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos4-is/fimc-core.c b/drivers/media/platform/exynos4

[PATCH 3/5] s5p-fimc: Align imagesize to row size for tiled formats

-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/exynos4-is/fimc-core.c b/drivers/media/platform/exynos4-is/fimc-core.c index 2e70fab

[PATCH 5/5] s5p-fimc: Reuse calculated sizes

This formula did not take into account the required tiled alignement for NV12MT format. As this was already computed an stored in payload array initially, reuse that value. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-m2m.c | 2 +- 1

[PATCH 1/5] s5p-fimc: Changed RGB32 to BGR32

Testing showed that HW produces BGR32 rather then RGB32 as exposed in the driver. The documentation seems to state the pixels are stored in little endian order. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 4 ++-- 1 file

[PATCH 4/5] s5p-fimc: Iterate for each memory plane

Depth and payload is defined per memory plane. It's better to iterate using number of memory planes. This was not causing much issue since the rest of the arrays involved where intialized to zero. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4

[PATCH 2/5] s5p-fimc: Fix YUV422P depth

All YUV 422 has 16bit per pixels. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos4-is/fimc-core.c b/drivers/media/platform/exynos4

Re: [PATCH 3/5] s5p-fimc: Align imagesize to row size for tiled formats

Le mardi 25 mars 2014 à 16:51 -0400, Nicolas Dufresne a écrit : For tiled format, we need to allocated a multiple of the row size. A good example is for 1280x720, wich get adjusted to 1280x736. In tiles, this mean Y plane is 20x23 and UV plane 20x12. Because of the rounding, the previous code

[PATCH 3/5] s5p-fimc: Roundup imagesize to row size for tiled formats

-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/exynos4-is/fimc-core.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/exynos4-is/fimc-core.c b/drivers/media/platform/exynos4-is/fimc-core.c index 2e70fab

Re: [PATCH 0/5] s5p-fimc: Misc fixes

Any comment/input ? Le mardi 25 mars 2014 à 16:45 -0400, Nicolas Dufresne a écrit : This patch series fixes several bugs found in the s5p-fimc driver. These bugs relate to bad parameters in the formats definition and short size of image buffers. Nicolas Dufresne (5): s5p-fimc: Reuse

Re: [PATCH 1/5] s5p-fimc: Changed RGB32 to BGR32

Le mardi 01 avril 2014 à 16:34 +0200, Sylwester Nawrocki a écrit : It should be BGRA, 32 bpp, I can fix it when applying, if you won't send next version of this patch until then. Good catch, I'll let you fix when applying. thanks, Nicolas signature.asc Description: This is a digitally

[PATCH] vb2: Update buffer state flags after __vb2_dqbuf

it. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/v4l2-core/videobuf2-core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index f9059bb..ac5026a 100644

Poll and empty queues

Hi everyone, Recently in GStreamer we notice that we where not handling the POLLERR flag at all. Though we found that what the code do, and what the doc says is slightly ambiguous. When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds,

Re: Poll and empty queues

Le mardi 03 juin 2014 à 08:38 +0200, Hans Verkuil a écrit : Hi Nicholas, On 06/02/2014 09:47 PM, Nicolas Dufresne wrote: Hi everyone, Recently in GStreamer we notice that we where not handling the POLLERR flag at all. Though we found that what the code do, and what the doc says

Re: Poll and empty queues

Le mardi 03 juin 2014 à 18:11 +0200, Laurent Pinchart a écrit : Hi Nicolas, On Tuesday 03 June 2014 10:37:50 Nicolas Dufresne wrote: Le mardi 03 juin 2014 à 08:38 +0200, Hans Verkuil a écrit : On 06/02/2014 09:47 PM, Nicolas Dufresne wrote: Hi everyone, Recently in GStreamer

Re: [PATCH v2 06/29] [media] coda: Add encoder/decoder support for CODA960

Le mardi 24 juin 2014 à 16:55 +0200, Philipp Zabel a écrit : This patch adds support for the CODA960 VPU in Freescale i.MX6 SoCs. It enables h.264 and MPEG4 encoding and decoding support. Besides the usual register shifting, the CODA960 gains frame memory control and GDI registers that are

Re: [PATCH 06/30] [media] coda: Add encoder/decoder support for CODA960

Le vendredi 13 juin 2014 à 18:08 +0200, Philipp Zabel a écrit : This patch adds support for the CODA960 VPU in Freescale i.MX6 SoCs. I might be confused, but is this driver sharing the same device node for the encoder and the decoder ? If so why ? I know the spec might not be preventing it, but

UVC driver produce decreasing timestamp

Hello, I've been trying to solve some timestamp issues with v4l2 in GStreamer and tracked down the problem to be the uvc driver giving back non-monotonic (sometimes decreasing) timestamp. Here's some traces I have captured. It shows the TS as computed by uvc_video_clock_update(). Notice that

Re: [RFC PATCH] Docbook/media: improve data_offset/bytesused documentation

Le lundi 21 juillet 2014 à 15:16 +0200, Hans Verkuil a écrit : + Note that data_offset is included in structfieldbytesused/structfield. + So the size of the image in the plane is + structfieldbytesused/structfield-structfielddata_offset/structfield at +

Re: [PATCH 04/10] [media] s5p-mfc: Don't allocate codec buffers on STREAMON.

Le lundi 19 mai 2014 à 18:03 +0530, Arun Kumar K a écrit : From: Pawel Osciak posc...@chromium.org Currently, we allocate private codec buffers on STREAMON, which may fail if we are out of memory. We don't check for failure though, which will make us crash with the codec accessing random

Re: [PATCH 2/3] [media] coda: fix coda_g_selection

Le Samedi 26 Juillet 2014 12:37 EDT, Philipp Zabel philipp.za...@gmail.com a écrit: I have tried the GStreamer v4l2videodec element with the coda driver and noticed that GStreamer calls VIDIOC_CROPCAP to obtain the pixel aspect ratio. This always fails with -EINVAL because of this issue.

Re: [PATCH 2/3] [media] coda: fix coda_g_selection

Le dimanche 27 juillet 2014 à 20:21 +0200, Hans Verkuil a écrit : If cropcap returns -EINVAL then that means that the current input or output does not support cropping (for input) or composing (for output). In that case the pixel aspect ratio is undefined and you have no way to get hold of

Bug: s5p-mfc should allow multiple call to REQBUFS before we start streaming

Hi Kamil, after a discussion on IRC, we concluded that s5p-mfc have this bug that disallow multiple reqbufs calls before streaming. This has the impact that it forces to call REQBUFS(0) before setting the new number of buffers during re-negotiation, and is against the spec too. As an

Re: s5p-mfc should allow multiple call to REQBUFS before we start streaming

Le 2014-09-01 05:43, Kamil Debski a écrit : Hi Nicolas, From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] Sent: Friday, August 29, 2014 3:47 PM Hi Kamil, after a discussion on IRC, we concluded that s5p-mfc have this bug that disallow multiple reqbufs calls before streaming

Re: s5p-mfc should allow multiple call to REQBUFS before we start streaming

Le 2014-09-02 05:02, Kamil Debski a écrit This limitation in MFC causes an important conflict between old videobuf and new videobuf2 drivers. Old videobuf driver (before Hans G. proposed patch) refuse REQBUFS(0). As MFC code has this bug that refuse REBBUFS(N) if buffers are already allocated,

Re: [PATCH/RFC v2 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns

Le 2014-09-15 08:49, Laurent Pinchart a écrit : Reverting the patch will also be a regression, as that would break applications that now rely on the new behaviour (I've developed this patch to fix a problem I've noticed with gstreamer). One way or another, we're screwed and we'll break

Re: [PATCH/RFC v2 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns

Le 2014-09-15 09:55, Mauro Carvalho Chehab a écrit : The DQBUF locking fixup was merged on libv4l2 for version 1.2. So, the potential breakage happens when libv4l2 is 1.2 and Gstreamer versions before 1.4. Do you have any procedure on gstreamer to fix a bug on stable releases? A backport is

Regression: in v4l2 converter does not set the buffer.length anymore

This was initially reported to GStreamer project: https://bugzilla.gnome.org/show_bug.cgi?id=737521 We track this down to be a regression introduced in v4l2-utils from version 1.4.0. In recent GStreamer we make sure the buffer.length field (retreived with QUERYBUF) is bigger or equal to the

Re: uvcvideo fails on 3.16 and 3.17 kernels

Le 2014-09-30 04:50, Paulo Assis a écrit : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362358 I've run some tests and after increasing verbosity for uvcvideo, I get: EOF on empty payload this seems consistent with the zero size frames returned by the driver. After VIDIOC_DQBUF |

Re: [PATCH 00/10] CODA7 JPEG support

Le 2014-09-30 10:34, Kamil Debski a écrit : I agree with you Hans. MFC has a single encoder node that supports multiple codecs and I think this design works well. JPEG should be separated into separate device. Having combined encoders and combines decoders works well from application /

Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

Le 2014-10-08 06:24, Kamil Debski a écrit : Hi, This patch seems complicated and I do not understand your motives. Could you explain what is the problem with the current aligning of the values? Is this a hardware problem? Which MFC version does it affect? Is it a software problem? If so,

Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

Le 2014-10-09 06:06, Kamil Debski a écrit : I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? A flag could be a good option, maybe we should take a minute and discuss this next

Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

Le 2014-10-21 07:34, Hans Verkuil a écrit : I think we should add flags here as well. NEAREST (the default), ROUND_DOWN and ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for all three of these, and I think the caller should just have to specify what is needed. Just

Re: Synching app to live tv

Please, when cross-posting, make sure to make it really evident, otherwise it's a bit of an abuse of people free time. cheers, Nicolas p.s. same message was posted on both GStreamer and linux-media mailing lists Le 2014-11-01 13:03, Evol Johnson a écrit : Hi I'm an app developer and no

Re: Using the coda driver with Gstreamer

Note, I'm only commenting about the GStreamer side... Le 2014-11-17 12:29, Fabio Estevam a écrit : Hi, I am running linux-next 20141117 on a mx6qsabresd board and trying to play a mp4 video via Gstreamer 1.4.1, but I am getting the following error: You should update to latest stable version,

Re: Using the coda driver with Gstreamer

Le 2014-11-18 13:08, Fabio Estevam a écrit : On Mon, Nov 17, 2014 at 5:58 PM, Fabio Estevam feste...@gmail.com wrote: Just a wild guess - we usually test here with dmabuf capable devices and without X. As you are using gstglimagesink, the code around ext/gl/gstglimagesink.c (453) looks

Re: V4l2 state transition

Le 2014-12-08 00:19, Bin Chen a écrit : Can anyone comment is following state transition diagram for V4l2 user space program make sense? Do you see any issues if we were to enforce this constraint? I think you should request some buffers before streamon. If in capture, you should also queue

Re: V4l2 state transition

Le 2014-12-08 09:29, Nicolas Dufresne a écrit : Le 2014-12-08 00:19, Bin Chen a écrit : Can anyone comment is following state transition diagram for V4l2 user space program make sense? Do you see any issues if we were to enforce this constraint? I think you should request some buffers before

LibV4L2 and CREATE_BUFS issues

Hi, we recently fixed our CREATE_BUFS support in GStreamer master. It works nicely with UVC drivers. The problem is that libv4l2 isn't aware of it, and endup taking terribly decision the least quickly lead to crash. I'm not sure what that right approach. It seems non-trivial to support it, at

Re: coda: not generating EOS event

Le jeudi 11 décembre 2014 à 11:00 -0200, Fabio Estevam a écrit : Hi, I am running Gstreamer 1.4.4 with on a imx6q-sabresd board and I am able to decode a video through the coda driver. The pipeline I use is: gst-launch-1.0 filesrc location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 !

Re: LibV4L2 and CREATE_BUFS issues

Le 2014-12-13 05:41, Hans de Goede a écrit : I think making CREATE_BUFS fail when doing conversion is probably best, note that gstreamer should be able to tell which formats will lead to doing conversion, and that it can try to avoid those. Those format indeed have a flag. The problem is

Re: LibV4L2 and CREATE_BUFS issues

Le 2014-12-14 04:49, Hans de Goede a écrit : Ah yes I see, so I assume that if libv4l where to return a failure for CREATE_BUFS when conversion is used, that gstreamer will then fallback to a regular REQUEST_BUFS call ? Then that indeed seems the best solution, can you submit patch for this ?

[PATCH 0/3] Various fixes for s5p-mfc driver

the control properties was preventing it. There was basically no way other then setting a large delay value to get the frames in display order. Nicolas Dufresne (3): s5p-mfc-v6+: Use display_delay_enable CID s5p-mfc-dec: Don't use encoder stop command media-doc: Fix MFC display delay control

[PATCH 2/3] s5p-mfc-dec: Don't use encoder stop command

The decoder should handle V4L2_DEC_CMD_STOP to trigger drain, but it currently expecting V4L2_ENC_CMD_STOP. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

[PATCH 1/3] s5p-mfc-v6+: Use display_delay_enable CID

a comment stating that DISPLAY_DELAY should be set to a negative value to disable it. This is not possible since the control range is from 0 to 65535. This feature was also supposed to be disabled by default in order to produce frames in display order. Signed-off-by: Nicolas Dufresne nicolas.dufre

[PATCH 3/3] media-doc: Fix MFC display delay control doc

The V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE control is a boolean but was documented as a integer. The documentation was also slightly miss-leading. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com --- Documentation/DocBook/media/v4l/controls.xml | 11

Re: coda: Unable to use encoder video_bitrate

Le 2014-12-22 10:24, Frédéric Sureau a écrit : Thanks for the patch! It works fine now after forcing framerate to 30fps (which seems to be hardcoded in the driver) Can you comment about this on gnome bug. Would make sense for the encoder element in GStreamer to relay the framerate to the

Re: coda: Unable to use encoder video_bitrate

Le 2014-12-22 11:02, Philipp Zabel a écrit : That is a good point, rate control can only work if the encoder has an idea about the framerate. I've sent a patch that allows to use VIDIOC_S_PARM to set it: [media] coda: Use S_PARM to set nominal framerate for h.264 encoder Thanks, I'll sort out

Re: [RFC PATCH] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder

Le 2015-01-15 11:23, Frédéric Sureau a écrit : Maybe a-parm.output.capability should be set to |V4L2_CAP_TIMEPERFRAME| here. I think it is required by GStreamer V4L2 plugin. Looking at this, I think output device is indeed the right place to set this, and the capability should indeed be

Re: Using the coda driver with Gstreamer

Le 2015-02-19 02:24, Zahari Doychev a écrit : So can you tell me if there are some drivers and plugins that can do this in efficient way. Is there some work going on in this directions. I suppose glimagesink maybe will be a good way to go. There is a lot of work happening, you should notice

Re: Using the coda driver with Gstreamer

Le 2015-02-18 03:42, Zahari Doychev a écrit : gst-launch-1.0 filesrc location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux ! h264parse ! v4l2video1dec ! videoconvert ! fbdevsink I am using this pipeline with gstreamer 1.4.5 and current media branch but I am getting very poor

Re: [PATCH 0/3] Various fixes for s5p-mfc driver

Le 2015-01-08 07:51, Kamil Debski a écrit : I usually don't ack patches that I plan to take into my tree, but it might be a good idea to let know the submitter that patches are good Thanks for letting me know, I may ask informally then next time. cheers, Nicolas -- To unsubscribe from this

Re: [PATCH 0/3] Various fixes for s5p-mfc driver

Just a friendly reminder that this patch is pending review ;-P cheers, Nicolas Le 2014-12-15 16:10, Nicolas Dufresne a écrit : This patchset fixes ability to drain the decoder due to use of wrong enumeration name and fixes implementation of display delay controls for MFC firmware v6 and higher

Re: [PATCH/RFC 0/2] Repurpose the v4l2_plane data_offset field

: Nicolas Dufresne nicolas.dufre...@collabora.com Date: Fri Apr 11 17:10:11 2014 -0400 v4l2: Add DMABUF and USERPTR importation (I've CC'ed Nicolas to this e-mail) I'm not too familiar with the latest gstreamer code, but after a first investigation it seems that gstreamer uses

Re: [RFC] V4L2 codecs in user space

Le lundi 08 juin 2015 à 13:42 +0900, Damian Hobson-Garcia a écrit : Also, if this method is not recommended, should there be a 1-2 line disclaimer on the V4L2_Userspace_Library wiki page that mentions this? I think you may have got that wrong. The V4L2 userspace library is not implementing

Re: imx53 IPU support on 4.0.4

Le mercredi 20 mai 2015 à 21:55 +0100, Russell King - ARM Linux a écrit : The way kernel development works is that patches are sent to mailing lists for review. Kernel developers review the patches and provide comments back. The comments are discussed and actioned, and a new set of patches

Re: [PATCH 4/4] v4l2-mem2mem: allow reqbufs(0) with "in use" MMAP buffers

Le mardi 08 avril 2014 à 12:51 +0200, Marek Szyprowski a écrit : > Hello, > > On 2014-04-07 16:41, Kamil Debski wrote: > > Pawel, Marek, > > > > Before taking this to my tree I wanted to get an ACK from one of > > the > > videobuf2 maintainers. Could you spare a moment to look through > > this >

Re: v4l2 api: supported resolution negotiation

Le dimanche 04 octobre 2015 à 21:49 +0300, Sakari Ailus a écrit : > I think the GStreamer > v4lsrc tries very small and very large values. The driver will clamp > them to > a supported values which are passed to the application from the > IOCTL. In GStreamer we try ENUM_FRAMESIZE, and when no

Re: v4l2 kernel module debugging methods

Le dimanche 06 décembre 2015 à 00:00 +0200, Ran Shalit a écrit : > Hello, > > I would like to ask a general question regarding methods to debug a > v4l2 device driver. > Since I assume that the kernel driver will probably won't work in > first try after coding everything inside the device

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit : > > # [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout > > # [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout > >  > > The video is stopped but I can see last frame on the screen although in  > > qt application it should

VIVID bug in BGRA and ARGB

Hi Hans, while testing over color formats VIVID produce, I found that BGRA and ARGB the alpha component is always 0, which leads to black frames when composed (when the background is black of course). Is that a bug, or intended ? cheers, Nicolas signature.asc Description: This is a digitally

Re: v4l2 kernel module debugging methods

Le jeudi 10 décembre 2015 à 23:46 +0200, Ran Shalit a écrit : > Thank you for the comment. > As someone expreinced with v4l2 device driver, do you recommened > using > debugging technique such as qemu (or kgdb) or do you rather use plain > printing ? I never used that, printing I used. You should

Re: Multiple open and read of vivi device

Le mardi 05 janvier 2016 à 23:18 +0200, Ran Shalit a écrit : > Does anyone knows why vivi is limited to one open ? > Is there some way to patch it for multiple opens and reading ? This is not fully exact. You can open vivid device multiple times. Though you can only have one instance streaming at

Re: [PATCH 00/38] i.MX5/6 Video Capture

Le jeudi 16 juin 2016 à 10:02 -0700, Steve Longerbeam a écrit : > I found the cause at least in my case. After enabling dynamic debug in > videobuf2-dma-contig.c, "v4l2-ctl -d/dev/video0 --stream-user=8" gives > me > > [  468.826046] user data must be aligned to 64 bytes > > > > But even

Re: [PATCH 00/38] i.MX5/6 Video Capture

Le jeudi 16 juin 2016 à 10:02 -0700, Steve Longerbeam a écrit : > I found the cause at least in my case. After enabling dynamic debug in > videobuf2-dma-contig.c, "v4l2-ctl -d/dev/video0 --stream-user=8" gives > me > > [  468.826046] user data must be aligned to 64 bytes > > > > But even

Re: gstreamer: v4l2videodec plugin

Le lundi 11 avril 2016 à 15:11 +0300, Stanimir Varbanov a écrit : > adding gstreamer-devel > > On 04/11/2016 03:03 PM, Stanimir Varbanov wrote: > > > > Hi, > > > > I'm working on QCOM v4l2 video decoder/encoder driver and in order > > to > > test its functionalities I'm using gstreamer

Re: gstreamer: v4l2videodec plugin

Le mardi 12 avril 2016 à 11:57 +0300, Stanimir Varbanov a écrit : > > I'm very happy to see this report. So far, we only had report that > this > > element works on Freescale IMX.6 (CODA) and Exynos 4/5. > > In this context, I would be very happy to see v4l2videoenc merged > soon :) That will

Re: [PATCH 1/7] [media]: v4l: add Mediatek MT21 video block format

Le mercredi 13 avril 2016 à 20:01 +0800, Tiffany Lin a écrit : > From: Daniel Kurtz > > Mediatek video format is YVU8_420_2PLANE_PACK8_PROGRESSIVE. > > Create V4L2_PIX_FMT_MT21 and DRM_FORMAT_MT21 to be consistent with > V4L2_PIX_FMT_NV12 notation. > > Signed-off-by:

Re: [PATCH] uvc: Fix bytesperline calculation for planar YUV

Le mercredi 13 avril 2016 à 17:36 +0300, Laurent Pinchart a écrit : > Hi Nicolas, > > Thank you for the patch. > > On Thursday 07 Jan 2016 15:43:48 Nicolas Dufresne wrote: > > > > The formula used to calculate bytesperline only works for packed > > format.

Re: gstreamer: v4l2videodec plugin

Le jeudi 19 mai 2016 à 15:25 +0200, Philipp Zabel a écrit : > Is there any reason not to update the MFC driver to use G_SELECTION? > The > g_crop implementation could be kept for backwards compatibility. Videobuf2 already provide this backward compatible implementation, so there is no reason not

Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers

; 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] > Signe

Re: [PATCH] Revert "[media] videobuf2-v4l2: Verify planes array in buffer dequeueing"

Le mercredi 11 mai 2016 à 13:27 -0300, Mauro Carvalho Chehab a écrit : > This patch causes a Kernel panic when called on a DVB driver. > > This reverts commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab. Seems rather tricky, since this commit fixed a possible (user induced) buffer overflow

Re: gstreamer: v4l2videodec plugin

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

Re: gstreamer: v4l2videodec plugin

Le vendredi 13 mai 2016 à 11:45 +0300, Stanimir Varbanov a écrit : > yes, of course :) > > Just FYI, I applied the WIP patches on my side and I'm very happy to > report that they just works. So If you need some testing on qcom > video > accelerator just ping me. > > One thing which bothers me is

Re: [RFC 08/22] videodev2.h: Add request field to v4l2_pix_format_mplane

Le vendredi 06 mai 2016 à 13:53 +0300, Sakari Ailus a écrit : > From: Laurent Pinchart > > Let userspace specify a request ID when getting or setting formats. > The > support is limited to the multi-planar API at the moment, extending > it > to the

Re: gstreamer: v4l2videodec plugin

Le jeudi 28 avril 2016 à 14:33 +0300, Stanimir Varbanov a écrit : > So I'm wondering is that intensional? > > Depending on the answer I should make the same in the Gallium dri2 in > dri2_from_dma_bufs(). It's DRI format that are confusing. In GStreamer DRI_FORMAT_GR88 would be named RG88 (if it

Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers

Thanks for re-submitting. See inline two typos to fix in teh comment. cheers, Nicolas Le vendredi 06 mai 2016 à 18:11 -0400, Javier Martinez Canillas a écrit : > From: ayaka > > User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a > memory mapped, user

Re: gstreamer: v4l2videodec plugin

Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit : > The issue is probably the YUV format, which we cannot really deal > with > properly in gallium..  it's a similar issue to multi-planer even if > it > is in a single buffer. > > The best way to handle this would be to import the same

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit : > > > We are plaining to remove m2m framework in th feature, although > we think > >  > > Remove it for just the decoder driver or both encoder and decoder? > >  > Remove it from decoder driver. Did you look at how CODA handle it

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

erspace with absolutely no way to handle the case of incompatible DMA-Buf. Regards, Nicolas p.s. I'll be away for the rest of the summer, see you in September. > > Regards, > > Hans > > > > > Suggested-by: Nicolas Dufresne <nicolas.dufre...@collabora.co

Re: [RFT PATCH v2] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

ort. So the reference count is incremented but > > not > > decremented for the endpoint and port nodes. > > > > Fix this by having separate pointers for each node looked up. > > > > Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> > > >

Re: [RFT PATCH v2] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

Le vendredi 15 juillet 2016 à 12:53 -0400, Nicolas Dufresne a écrit : > Le jeudi 21 avril 2016 à 09:21 -0400, Javier Martinez Canillas a > écrit : > > Hello Sylwester, > > > > On 03/23/2016 08:41 PM, Javier Martinez Canillas wrote: > > > The same struct dev

Re: [PATCH v2 2/3] [media] hva: multi-format video encoder V4L2 driver

Le lundi 11 juillet 2016 à 17:14 +0200, Jean-Christophe Trotin a écrit : > This patch adds V4L2 HVA (Hardware Video Accelerator) video encoder > driver for STMicroelectronics SoC. It uses the V4L2 mem2mem framework. > > This patch only contains the core parts of the driver: > - the V4L2 interface

Re: [PATCH v2 0/3] support of v4l2 encoder for STMicroelectronics SOC

Le lundi 11 juillet 2016 à 17:14 +0200, Jean-Christophe Trotin a écrit : > version 2: > - List of pixel formats supported by the encoder reduced to NV12 and > NV21 > - x86_64 compilation warnings corrected > - V4L2 compliance successfully passed with this version (see report > below) > - All

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > Decoder hardware produces MT21 (compressed). Image processor can > convert it to a format that can be input of display driver. Tiffany. > When do you plan to upstream image processor (mtk-mdp)? > > > > It can be as input format

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > Decoder hardware produces MT21 (compressed). Image processor can > > convert it to a format that can be input of display driver. > > Tif

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

Le mercredi 13 juillet 2016 à 10:00 +0800, tiffany lin a écrit : > Hi Nicolas, > > On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote: > > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > > Le mardi 12 juillet 2016 à 16:16 +0800, W

Re: [PATCH 2/2] [media] s5p-g2d: Replace old driver with DRM version

Le mardi 12 juillet 2016 à 20:02 -0300, Mauro Carvalho Chehab a écrit : > I suspect that you'll be applying this one via DRM tree, so: > > Em Tue, 24 May 2016 15:28:13 +0200 > Krzysztof Kozlowski escreveu: > > > Remove the old non-DRM driver because it is now entirely

Re: [RFC PATCH] media: s5p-mfc - remove vidioc_g_crop

Le dimanche 03 juillet 2016 à 11:43 +0200, Hans Verkuil a écrit : > Hi Nicolas, > > On 07/02/2016 10:29 PM, Nicolas Dufresne wrote: > > > > Le 30 juin 2016 5:35 PM, "Shuah Khan" <shua...@osg.samsung.com > > <mailto:shua...@osg.samsung.com>> a écr

Re: rtl2832_sdr and /dev/swradio0

Le mardi 31 janvier 2017 à 17:50 +, Russel Winder a écrit : > Hi, > > Is anyone actively working on the rtl2832_sdr driver? > > I am particularly interested in anyone who has code for turning the > byte stream from /dev/swradio0 into an ETI stream. Or failing that > getting enough data about

Re: [PATCH v5 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

Le mercredi 22 février 2017 à 10:10 -0300, Thibault Saunier a écrit : > Hello, > > On 02/22/2017 06:29 AM, Andrzej Hajda wrote: > > On 21.02.2017 20:20, Thibault Saunier wrote: > > > It is required by the standard that the field order is set by the > > > driver. > > > > > > Signed-off-by:

Re: [PATCH 00/15] Exynos MFC v6+ - remove the need for the reserved memory

Le mardi 14 février 2017 à 08:51 +0100, Marek Szyprowski a écrit : > Dear All, > > This patchset is a result of my work on enabling full support for MFC device > (multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought > that to let it working on ARM64 architecture with IOMMU,

Re: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

Le mercredi 22 février 2017 à 15:57 -0300, Thibault Saunier a écrit : > On 02/22/2017 03:06 PM, Hans Verkuil wrote: > > > > On 02/22/2017 05:05 AM, Thibault Saunier wrote: > > > Hello, > > > > > > > > > On 02/21/2017 11:19 PM, Hans Verkuil wrote: > > > > On 02/21/2017 11:20 AM, Thibault Saunier

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

Le jeudi 09 février 2017 à 18:07 +0100, Hugues Fruchet a écrit : > 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

Re: [PATCH] media: fix s5p_mfc_set_dec_frame_buffer_v6() to print buf size in hex

Le jeudi 09 février 2017 à 15:10 -0700, Shuah Khan a écrit : > Fix s5p_mfc_set_dec_frame_buffer_v6() to print buffer size in hex to > be > consistent with the rest of the messages in the routine. Short and long descriptions are miss-leading. This patch will print the buffer pointer as hex and

Re: Request API: stateless VPU: the buffer mechanism and DPB management

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

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

with the TODO, and even if I did, I'm not sure I agree > with this solution. Since queuing the buffer to the driver is not the same > as 'just before the DMA', since there may be many buffers queued up in the > driver and you don't know in vb2 when the buffer is at the 'just before the > DMA' > s

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

the mapping when buffers > > are queued in the driver since that's when the actual DMA operation are > > going to happen. > > > > Suggested-by: Nicolas Dufresne <nicolas.dufre...@collabora.com> > > Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.co

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

priate to do the mapping when buffers > > are queued in the driver since that's when the actual DMA operation are > > going to happen. > > > > Suggested-by: Nicolas Dufresne <nicolas.dufre...@collabora.com> > > Signed-off-by: Javier Martinez Canillas <jav..

  1   2   3   >