for exchanging
DMA buffers in userspace, and can also use the same API and support mx6,
mx7, and mx8 machines, without requiring platform specific code changes.
Signed-off-by: Carlos Rafael Giani
---
.../libimxdmabuffer/libimxdmabuffer_1.0.0.bb | 41 +++
1 file changed, 41 ins
This follows the OE-Core upgrade.
Signed-off-by: Carlos Rafael Giani
---
..._1.14.%.bbappend => gstreamer1.0-plugins-base_1.16.%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.14.%.bbappend
=> gstrea
When I try to build an image, the rootfs generation fails, because both
firmware-qca9377 and firmware-qca6174 want to install
/etc/bluetooth/firmware.conf .
This happens with both core-image-base and core-image-weston.
The hack to circumvent this is to remove qca9377 or qca6174 from the
imx8m
This fixes the compiler error:
| unable to execute 'x86_64-linux-gnu-gcc': No such file or directory
| error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Signed-off-by: Carlos Rafael Giani
---
.../0001-tools-allow-to-override-python.patch | 46 ++
The imx-kernel has support for DMA-BUF backed memory through Android's
ION. This is already used by imx-gstplugin-1.0 . It makes it possible to
transport frames over DMA.
But what seems to be missing is support for DMA-BUF in the V4L2 CSI
devices on NXP machines. GStreamer's v4l2src delivers d
d VP8 frame that was input into the codec was an
invisible frame.
It is still unclear though if this affects VP9 playback as well.
On 13.12.18 14:48, Otavio Salvador wrote:
Hello Carlos,
On Sat, Dec 8, 2018 at 8:43 AM Carlos Rafael Giani wrote:
I recently noticed that VP8 playback does not
I recently noticed that VP8 playback does not work correctly with
imx-vpu-hantro . If a VP8 stream contains alternate reference (altref)
frames, then imx-vpu-hantro decodes them correctly, but does not inform
about the fact that they are altref frames. This is a problem, because
altref frames a
For the Hantro VPU, there's imx-vpu-hantro .
But does something like imx-vpu-malone or imx-vpu-amphion exist as well?
I cannot find any .bb file for it. Is a .bin package or tarball already
available on the NXP servers perhaps?
--
___
meta-freescale
Signed-off-by: Carlos Rafael Giani
---
.../gstreamer/gstreamer1.0-plugins-good_1.14.imx.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.imx.bb
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins
Without these, the Vivante EGL headers will try to include X11 headers,
causing the build to break.
Signed-off-by: Carlos Rafael Giani
---
recipes-graphics/libsdl2/libsdl2_%.bbappend | 5 +
1 file changed, 5 insertions(+)
diff --git a/recipes-graphics/libsdl2/libsdl2_%.bbappend
b/recipes
Yeah, but that won't happen until the API is changed to not allow for
physical addresses and to use FDs instead (like from ION or DMA-BUF).
But that will take a while I guess.
On 2018-10-03 20:50, Otavio Salvador wrote:
On Wed, Oct 3, 2018 at 3:47 PM Tom Hochstein wrote:
/usr/include/imx/li
Rafael Giani
wrote:
In addition to this, I think adding a "hantro_config.h" header would be
useful. That's because we can find this in the Makefile_codec file:
CFLAGS += -DSET_OUTPUT_CROP_RECT -DUSE_EXTERNAL_BUFFER
-DUSE_OUTPUT_RELEASE -DVSI_API -DIS_G1_DECODER -DE
In addition to this, I think adding a "hantro_config.h" header would be
useful. That's because we can find this in the Makefile_codec file:
CFLAGS += -DSET_OUTPUT_CROP_RECT -DUSE_EXTERNAL_BUFFER
-DUSE_OUTPUT_RELEASE -DVSI_API -DIS_G1_DECODER -DENABLE_CODEC_VP8
-DVP8_HWTIMEOUT_WORKAROUND -DEN
Recently I saw this in the imx-gpu-viv-6.inc file:
REQUIRED_DISTRO_FEATURES_mx8 = "wayland"
Since when is Wayland a requirement? What if I want to use X11? What if
I want to render directly to the framebuffer without Wayland or X11?
Or is this just a build time dependency, and the other two
Nevermind, should have google for these names :) Amphion is the
manufacturer, malone is the codec.
On 2018-08-02 10:35, Carlos Rafael Giani wrote:
Hmm okay, and is "malone" an engineering name an "Amphion" the
marketing name, or why has this codec two names?
On 20
Hmm okay, and is "malone" an engineering name an "Amphion" the marketing
name, or why has this codec two names?
On 2018-08-02 10:24, Gary Bisson wrote:
Hi Carlos,
On Thu, Aug 2, 2018 at 9:50 AM, Carlos Rafael Giani
mailto:d...@pseudoterminal.org>> wrote:
I
I saw in the imx-vpu-hantro and imx gst plugins packages that both
Hantro and Amphion were mentioned.
I remember that the imx8m only has a hantro decoder. But apparently
there is also a Hantro encoder. And there is also an "Amphion" codec?
Where are the Amphion codec and the Hantro encoder us
-
From: meta-freescale-boun...@yoctoproject.org [mailto:meta-freescale-
boun...@yoctoproject.org] On Behalf Of Carlos Rafael Giani
Sent: Friday, July 27, 2018 9:01 AM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] Fixing imx-vpu-hantro header installation
Currently, the headers from
Currently, the headers from imx-vpu-hantro are installed in the
${includedir} directory, which is /usr/include/ in Yocto.
This is bad, because there are multiple headers, and none of them have
names that are distinguishable enough. There are headers called codec.h,
version.h, util.h for exampl
It is better to report this in the gstreamer-imx github page please.
Also, this is not enough information. I do not know of any problems with
1.8.0. I do however recommend to try to update to the most recent stable
version, since looking for bugs with such an old version is very difficult.
On
It is located in gstreamer1.0-plugins-bad . In version 1.14, it will be
in -base. It is actually strange why it was in -base in 1.8.
On 2018-01-16 11:57, Diaz de Grenu, Jose wrote:
Seems like the missing header was provided in gstreamer1.0-plugins-base-1.8.3
However poky/rocko uses gstreamer1
With sufficiently new Qt5 and GStreamer versions, this should be
relatively easy. Qt5 has dedicated i.MX6 support. Try installing
gstreamer-imx to use the VPU for video decoding. This places the video
frames into DMA buffers, which the GPU can render directly from. This
way, the rescaling is do
meta-freescale-boun...@yoctoproject.org
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Carlos Rafael
Giani
Sent: Tuesday, December 26, 2017 4:11 PM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [PATCH 0/9] Upstream Multimedia patches for
L4.9.51_MX8MQ Beta re
I do not agree with using an entire GStreamer fork. At least, this
should be opt-in, and _not_ be the default. Otherwise, people would not
know that they are using a fork instead of the upstream GStreamer, and
they would have to modify the bbappends if they wanted upstream.
So, I'd make this c
I recommend posting this to the OE-core mailing list to highlight the
issue. Perhaps there's still room for this fix in rocko.
On 2017-12-14 08:40, Steffen Sledz wrote:
On 11.12.2017 15:05, Stefan Agner wrote:
This seems to be an issue which only happens on some host distros (e.g.
Fedora 26)
c caps as may be leaked
This gets rid of the false positive in the leak tracer
* misc:
* Update waf to 1.9.3 to fix compilation with Python 3.4+
Signed-off-by: Carlos Rafael Giani
---
...lugins-imx_0.12.2.bb => gstreamer1.0-plugins-imx_0.13.0.bb} | 10 ++
1 file changed,
internally and filling the U and V planes
with 0x80 bytes
- make sure JPEG quantization table is copied in standardized zig zag order
the VPU does not, so this has to be done explicitely
Signed-off-by: Carlos Rafael Giani
---
.../libimxvpuapi/{libimxvpuapi_0.10.2.bb => libimxvpuapi_0.10.
And what happens if you try other capture modes? (use the
imx-capture-mode property)
On 2016-11-03 13:31, Ari Sinisalo wrote:
I am using NXP Sabre i.MX7dual.
It should work fine with the ov5640. What board is this?
On 2016-11-03 13:14, Ari Sinisalo wrote:
I have tried to use imxv4l2vid
What hardware are you using? Not just the SoC, but also what board? And
what video capture chipset are you using? ov5640? adv7180?
On 2016-11-03 13:18, Ari Sinisalo wrote:
Is there possibility to use lower than 15fps framerate with
imxv4l2videosrc or imxv4l2src?
Br AriS
-
It should work fine with the ov5640. What board is this?
On 2016-11-03 13:14, Ari Sinisalo wrote:
I have tried to use imxv4l2videosrc but it fails constantly. Following
is what I get with fakesink.
GST_DEBUG=2,*imx*:9 gst-launch-1.0 imxv4l2videosrc device=/dev/video1
! fakesink
0:00:00.0
wrote:
On Mon, Oct 17, 2016 at 7:59 AM, Carlos Rafael Giani
wrote:
What version of gstreamer-imx, gstreamer, and yocto are you using? And what
hardware are you using?
Everything is from the current fsl-krogath branch.
gstreamer1.0_1.6.3
imx-gst1.0-plugin_4.0.9
kernel-module-imx-gpu-viv_5.0.11
What version of gstreamer-imx, gstreamer, and yocto are you using? And
what hardware are you using?
On 2016-10-16 16:46, Mark Farver wrote:
Having an intermittent issue, and I'm not really sure where to turn,
or what the solution might be.
We have a kiosk that plays a series of videos in a re
Moving add_chromium_imx_patches() is pointless I think. The patch
effectively makes chromium-imx.inc unusable with any future chromium-imx
patches.
Just leaving the CHROMIUM_IMX_COMMON_PATCHES , CHROMIUM_IMX_VPU_PATCHES
, CHROMIUM_IMX_WAYLAND_PATCHES variables unset or set to "" is enough,
si
Hi,
starting with commit 9cc449273252314fdc88cd62deb18a3e03d8abd5 "image:
Deploy images to IMGDEPLOYDIR" , the ext4 image is not immediately
deployed after it is built. This in turn breaks sdcard image generation,
since the dd call made by generate_imx_sdcard() and
generate_mxs_sdcard() insid
This fixes the following build error during the install task:
"cp: cannot stat '.../git/Module.symvers': No such file or directory"
Signed-off-by: Carlos Rafael Giani
---
.../kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p8.4+fslc.bb | 9 +
1 file changed, 9 inser
Well, the GNU_HASH issue is gone. But the driver and the exa module
still aren't being copied over when I build core-image-x11. I again had
to copy them over manually to get X to work.
This does appear like a bug to me.
On 2016-07-28 08:33, Carlos Rafael Giani wrote:
Hello,
I saw some
Nevermind. You are right. I made the mistake of assuming that the
nitrogen behaves like the Sabre board (= that it reads the u-boot from
the SD card). When I boot, it indeed is a U-Boot version from 2014. I'll
upgrade.
On 2016-08-27 07:19, Carlos Rafael Giani wrote:
Hm.
I let bi
/recipes-bsp/u-boot/u-boot-boundary_git.bb
On 2016-08-27 01:44, Eric Nelson wrote:
Hi Carlos,
On 08/26/2016 12:11 PM, Carlos Rafael Giani wrote:
Hello,
I just built an image for the nitrogen6x with poky, meta-openembedded,
meta-fsl-arm, meta-fsl-arm-extra, meta-fsl-demos all at the latest
Hello,
I just built an image for the nitrogen6x with poky, meta-openembedded,
meta-fsl-arm, meta-fsl-arm-extra, meta-fsl-demos all at the latest
master. boundary-kernel version is 4.1.15.
Looking at /dev/ shows that there is no /dev/fb0, fb1, or any fbX device
node!
I did not add any argum
cubox-i is not fully supported in meta-fsl-arm-extra anymore. You are
limited to the FSLC kernel with it. See
https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/cubox-i.conf#L17
.
For full support, you need to contact SolidRun.
On 2016-08-22 19:21, Otavio Salvador wrote
EGL flags etc. enabled.
On 2016-08-19 17:31, Carlos Rafael Giani wrote:
Such updates are never trivial because the Chrome devs constantly
change subtle things about the APIs. This will require an update of
chromium-imx to be fully functional. I will not be able to do this
until mid September.
Such updates are never trivial because the Chrome devs constantly change
subtle things about the APIs. This will require an update of
chromium-imx to be fully functional. I will not be able to do this until
mid September. So, either you stick to M48, or you remove the bbappend.
No other options
This one can also be applied to krogoth.
On 2016-07-28 08:54, Carlos Rafael Giani wrote:
Changes:
* imxv4l2videosrc:
* Stricter checks for video device capabilities
* Add support for more video formats like 8/16-bit grayscale
* pxp: Fix incorrect return code which broke blitter with
files are placed
* Explicitely add the libfslaudiocodec.pc libdir to the MP3 encoder
Fixes build errors in buildroot
* Minor logging fixes
* misc:
* Proper check for region copies in phys_mem_meta
* Add missing G_END_DECLS lines in headers
Signed-off-by: Carlos Rafael Giani
Were these patches tested with master-next ? I have a build with the
latest master, and got neither this error nor the G2D one.
Other than that, these patches look OK to me.
On 2016-07-25 21:56, Otavio Salvador wrote:
This fixes following ERROR:
,
| ERROR: QA Issue: gstreamer1.0-plugins-
Hello,
I saw something curious yesterday while trying to run an X11 image.
I built core-image-x11 with latest yocto master & meta-fsl-arm master. I
then saw that the X11 driver was not included in the image. Neither was
the EXA module.
When trying to run bitbake xf86-video-imxfb-vivante , I
This could be GCC 5 related. Try adding this line to local.conf and then
rebuild Chromium:
GCCVERSION = "4.9%"
On 2016-06-30 19:34, Luigi Scagnet wrote:
Hello all,
I've built a Weston image with command bitbake core-image-weston for
my custom board mounting an iMx6 quadcore. All seems to work
Signed-off-by: Carlos Rafael Giani
---
browser-layer/recipes-browser/chromium/chromium-imx.inc| 7 ++-
...hromium_40.0.2214.91.bbappend => chromium_48.0.2548.0.bbappend} | 4 ++--
2 files changed, 4 insertions(+), 7 deletions(-)
rename browser-layer/recipes-browser/chrom
I have a patch for it, but it isn't tested yet. I am fixing something
else in chromium and will then to a test build for this one.
On 2016-05-18 19:11, Otavio Salvador wrote:
On Tue, May 17, 2016 at 10:33 PM, Gary Thomas wrote:
ERROR: No recipes available for:
/local/poky-cutting-edge/meta-f
setting header data
useful for modifying headers, like VUI data in the SPS RBSP
- documentation updates
Signed-off-by: Carlos Rafael Giani
---
.../libimxvpuapi/{libimxvpuapi_0.10.1.bb => libimxvpuapi_0.10.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-multime
dec recipe renaming.
On 04/06/2016 04:10 PM, Carlos Rafael Giani wrote:
The recipe now uses PACKAGECONFIG to allow for enabling/disabling plugins.
Also, mx7 support has been added.
Changes:
* compositor: Rename ImxCompositor(Pad) to ImxVideoCompositor(Pad)
This prevents conflicts if both the
Signed-off-by: Carlos Rafael Giani
---
recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.12.1.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.12.1.bb
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins
* Documentation additions
Adds GPU memory leak notess to the FAQ
* vpu: encoder: Expose motion estimation range as property
* vpu: decoder: Drop output frame if its buffer cannot be allocated
Signed-off-by: Carlos Rafael Giani
---
12.0.bb => gstreamer1.0-plugins-imx_0.12.1.bb} |
On 04/06/2016 12:36 PM, Otavio Salvador wrote:
On Wed, Apr 6, 2016 at 6:21 AM, Carlos Rafael Giani
wrote:
gstreamer1.0-plugins-imx-imxvpu
Yes, you can do:
RDEPENDS_ += "foo"
It is harmless if it is not generated.
This is what is being done now. Then I'll leave as it i
On 2016-04-06 10:10, Gary Bisson wrote:
# add the audioparsers and the videoparsersbad plugins as RDEPENDS ;
audioparsers
# for the uniaudio decoder, videoparsersbad for the VPU video decoder
# the gstreamer1.0-plugins-imx RDEPENDS is necessary to ensure the -good
recipe is
Same for
On 2016-04-06 10:43, Gary Bisson wrote:
-# gstreamer1.0-plugins-bad is in DEPENDS because imxv4l2videosrc
requires
-# the GstPhotography headers and libraries
-DEPENDS = "gstreamer1.0 gstreamer1.0-plugins-base
gstreamer1.0-plugins-bad imx-gpu-viv \
- libfslcodec libimxvpuapi virtual/
-boun...@yoctoproject.org
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Carlos Rafael
Giani
Sent: Thursday, March 31, 2016 11:14 PM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm][PATCH 1/5] libfslcodec: Upgrade to
v4.0.9
I have a suggestion for this rec
On 2016-04-06 10:10, Gary Bisson wrote:
Carlos, All,
On Wed, Apr 6, 2016 at 9:36 AM, Carlos Rafael Giani
wrote:
The recipe now uses PACKAGECONFIG to allow for enabling/disabling plugins.
Also, mx7 support has been added, and the libfslcodec->imx_codec renaming
has been included.
Chan
are swapped
This fixes eglSwapBuffer swaps with damaged frames
* Documentation additions
Adds GPU memory leak notess to the FAQ
* vpu: encoder: Expose motion estimation range as property
* vpu: decoder: Drop output frame if its buffer cannot be allocated
Signed-off-by: Carlos Rafael Gi
On 04/04/2016 03:04 PM, Gary Bisson wrote:
Otavio, All,
On Mon, Apr 4, 2016 at 1:04 PM, Otavio Salvador
wrote:
On Sat, Apr 2, 2016 at 12:58 PM, Gary Bisson
wrote:
Modify the dependencies to match the platform features. By default
the build will generate the following plugins for all the mx6/
Actually, I have started to modify the build scripts to be able to
enable/disable individual components by using packageconfigs, so the
timing is nice :)
Also because some people might not need/want the uniaudio decoders for
example.
I'll see if this can be added quickly. If so, then I'll do a
I have a suggestion for this recipe.
The uniaudio codecs require knowledge about the SONAME of the plugin.
Without this SONAME, accessing these plugins is not possible. For this
reason, imx-gst1.0-plugin installs a file in /etc/ that contains a list
of these plugins.
(gstreamer-imx scans for p
Generally this patch seems OK. There are some places that need
clarification.
@@ -231,6 +233,18 @@ gst_gl_upload_element_prepare_output_buffer
(GstBaseTransform * bt,
return GST_FLOW_ERROR;
}
+ /* check if the output buffer's meta format equals to the caps format */
+ GstVideoMeta
This seems to be quite useful to me. But it is not i.MX specific - I
could for example even use this on the PC.
However, modifying the global vertices array is not good, for two reasons:
1. This will not work well in a multithreaded environment (with multiple
glimagesink instances)
2. The verte
This gets an Ack from me. It doesn't break anything, and is truly i.MX
specific. There may be i.MX devices with screens smaller than 1024x768,
though to me this seems to be the minority.
On 2016-02-02 15:01, Yuqing Zhu wrote:
In our release, the default display is full screen in LVDS.
The 1024
I do see the reason behind the patch. As you explained earlier, the
VPU's output buffers are re-used as references, so they should not be
modified.
Before I give this patch an Ack however, I need to know if the
suggestions from https://bugzilla.gnome.org/show_bug.cgi?id=747495
regarding the N
As said in the previous submission, I think this patch is acceptable,
and a good example of something truly i.MX specific.
Since 8/16-pixel alignments aren't exactly uncommon, I think this should
be turned into a solution that can be upstreamed and is applicable to
many other GStreamer plugins
I noticed a build error when building a rootfs for nitrogen6x.
I first ran: MACHINE=nitrogen6x nice bitbake virtual/kernel
Then, MACHINE=nitrogen6x nice bitbake kernel-module-imx-gpu-viv
and I got the compile error attached below.
Then I ran: MACHINE=nitrogen6x nice bitbake -c cleansstate
ke
I remember that. Very problematic issue.
One way to clean this up would be to add fonts to the RDEPENDS list. But
then, certain fonts will always be installed.
Probably a better way would be to somehow have something like RDEPENDS
for a class of packages. This way, bitbake complains unless you
Actually, it already uses the waf bbclass:
inherit waf pkgconfig
On 2016-02-19 11:32, eien sakebe wrote:
hello,
Thank you for your feedback.
Do you mean
http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/76501 ?
bcause it gives me annother issue | AttributeError: Values insta
GStreamer bugzilla.
If they accept it, I will push the patch to poky.
B.R.
Yuqing Zhu
-Original Message-
From: meta-freescale-boun...@yoctoproject.org
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Carlos Rafael
Giani
Sent: Wednesday, January 27, 2016 8:11 PM
To: meta
m.
B.R.
Yuqing Zhu
-Original Message-
From: meta-freescale-boun...@yoctoproject.org
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Carlos Rafael
Giani
Sent: Wednesday, January 27, 2016 8:24 PM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm]
ng Zhu
Cc: Carlos Rafael Giani ;
meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm][PATCH 2/9]
gstreamer1.0-plugins-bad: Fix for gl plugin not built in wayland backend
On Thu, Jan 28, 2016 at 5:29 AM, Yuqing Zhu wrote:
Hi Carlos,
We change it to 1.0 as the wayland-
Could you add an explanation to the commit message why you increase the
default resolution?
On 01/27/2016 10:41 AM, Yuqing Zhu wrote:
Change wayland backend default window resolution
from 320x240 to 1024x768.
Signed-off-by: Yuqing Zhu
---
...in-Change-wayland-default-res-to-1024x768.patch |
This seems like a patch for debug output (the number of frames shown so
far). This is OK, except that it should not be always enabled, and it
should not directly call g_print. Have a look at fpsdisplaysink. It uses
the last-message property, a "silent" property, and
g_object_notify_by_pspec() t
This commit is acceptable. I can also live with the "i.MX specific"
part, since this is a Vivante GPU problem.
I think this could be upstreamed, though, because having "sqrt(2)" in
the shader does not actually gain anybody anything. It would be
perfectly acceptable to replace it with 1.4142135
This is missing an explanation in the commit message for why you do
this. I guess this is done because the Vivante EGL implementation has
these version numbers, right?
On 01/27/2016 10:41 AM, Yuqing Zhu wrote:
Signed-off-by: Yuqing Zhu
---
...or-gl-plugin-not-built-in-wayland-backend.patch
This is not acceptable. It breaks every autoplugged pipeline which
relies on these elements. If your goal is to let GStreamer prefer the
FSL parsers from gst1.0-fsl-plugins, then increase their ranks instead.
On 01/27/2016 10:41 AM, Yuqing Zhu wrote:
. h263parse rank down to 63
. h264parse ran
On 01/20/2016 03:42 PM, Richard Röjfors wrote:
On Wed, Jan 20, 2016 at 3:34 PM, Schrempf Frieder
wrote:
Hi,
I can still experience this problem reported here in 2014
https://lists.yoctoproject.org/pipermail/meta-freescale/2014-October/010889.html
in my current setup with a recent jethro build
Of Carlos Rafael
Giani
Sent: Monday, January 18, 2016 10:16 PM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm][PATCH 1/3]
gstreamer1.0-plugins-base: Make memory copy when video buffer's memory is read
only
Why is this flagged as i.MX specific? Nothing in
Here my question too is: why is this flagged as i.MX specific? Nothing
in this patch refers to i.MX details such as IPU, VPU..
And you also need a link to a GStreamer bugzilla entry in the commit
message of this patch.
On 01/18/2016 10:34 AM, Yuqing Zhu wrote:
Set async to false lead to A/V
This *is* a good example of something truly i.MX specific. As a
workaround, the patch is acceptable.
I'd still submit this to GStreamer bugzilla so this can be turned into
something upstreamable. I am thinking of an additional set of element
properties, like "alignment-x" "alignment-y". This w
Why is this flagged as i.MX specific? Nothing in this patch refers to
i.MX details such as IPU, VPU etc.
Also, the patch commit message needs a reference to a GStreamer bugzilla
entry.
On 01/18/2016 10:34 AM, Yuqing Zhu wrote:
Since gst_buffer_make_writable just lookup the refcount to determ
/
? In other words, the entire work folder of that build.
On 2016-01-13 22:09, Otavio Salvador wrote:
On Wed, Jan 13, 2016 at 5:42 PM, Carlos Rafael Giani
wrote:
This makes no sense. The new version does _not_ look for libfslvpuwrap.
Checking the log.do_configure output of my local build
AM, Carlos Rafael Giani
wrote:
Changes:
* vpu:
- Completely rewritten plugin code; elements now based on libimxvpuapi
instead of libfslvpuwrap
- imxvpuenc_h264 inserts SPS/PPS data in front of I/IDR frames
- imxvpuenc_mjpeg's quality factor actually has an effect, a
This upgrade can be applied to jethro and master.
On 2016-01-08 09:43, Carlos Rafael Giani wrote:
Changes:
* vpu:
- Completely rewritten plugin code; elements now based on libimxvpuapi
instead of libfslvpuwrap
- imxvpuenc_h264 inserts SPS/PPS data in front of I/IDR frames
with frame sizes that aren't aligned
* wscript:
- improve Android support
- fix installation paths for the common, blitter, compositor libraries
Signed-off-by: Carlos Rafael Giani
---
...ns-imx_0.11.1.bb => gstreamer1.0-plugins-imx_0.12.0.bb} | 14 +-
1 file changed, 9
Writing this to the mailing list for sake of completeness: this turned
out to be a memory leak in the GPU driver, imx-gpu-viv 5.0.11.p4.4.
Upgrading to 5.0.11.p4.5 fixed the issue.
On 2015-12-22 13:17, Carlos Rafael Giani wrote:
This is strange. For me, it looped over 160 times before I
ached here the complete log with allocation failure after 53rd time
with master branch of plug-in and libimxvpuapi and CMA configs I
mentioned.
Regards,
Vikash
On Tue, Dec 22, 2015 at 4:11 PM, Carlos Rafael Giani
wrote:
You mean, "before the CMA reconfiguration, the loop-video test fa
MBYTES=256
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7
Regards,
Vikas
On Tue, Dec 22, 2015 at 3:18 PM, Carlos Rafael Giani
wrote:
This is a different error, however. I
it also be possible for you to give me a copy of this
B01_Baseline1.0_1280_720.MP4 file?
On 2015-12-22 10:39, Vikas Patil wrote:
Hi Carlos,
Still I could not play. Attached here the log.
Regards,
Vikas
On Tue, Dec 22, 2015 at 12:34 AM, Carlos Rafael Giani
wrote:
Can you try out the example
etween 6th to 9th loop)
gst-launch-1.0 filesrc
location=/home/root/B01_Baseline1.0_1280_720.MP4 ! qtdemux ! h264parse
! imxvpudec ! imxipuvideotransform ! imxg2dvideosink (gets memory
allocation failure on 62nd loop iteration)
Thanks & Regards,
Vikas
On Wed, Nov 18, 2015 at 10:28 PM, Carlo
Note: this can be applied to jethro and master.
On 2015-12-15 23:51, Carlos Rafael Giani wrote:
Changes:
- add debian packaging files
- update waf to version 1.8.16
- add workaround in wscript to prevent stale pkg-config .pc files
- fix memory leak by adding missing IOFreeVirtMem() call in
Changes:
- add debian packaging files
- update waf to version 1.8.16
- add workaround in wscript to prevent stale pkg-config .pc files
- fix memory leak by adding missing IOFreeVirtMem() call in vpulib backend
Signed-off-by: Carlos Rafael Giani
---
.../libimxvpuapi/{libimxvpuapi_0.10.0.bb
Signed-off-by: Carlos Rafael Giani
---
...CH-install-gstaggregator-and-gstvideoaggregator-h.patch | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-PATCH-install-gstaggregator-and-gstvideoaggregator
Actually, it isn't. The whole point of this patch is that the
gst1.0-fsl-plugin package needs headers from -bad which aren't public
(yet), so they aren't installed. The patch makes sure they are.
On 2015-11-18 23:40, Ann Thornton wrote:
The problem is the
0001-PATCH-install-gstaggregator-and
This actually looks more like a problem in imx-vpu or in the VPU
driver's DMA memory pool. DMA buffer allocation fails.
Perhaps this affects other allocators as well. Try these pipelines:
GST_DEBUG=2,*imx*:5 gst-launch-1.0 videotestsrc ! imxg2dvideosink
GST_DEBUG=2,*imx*:5 gst-launch-1.0 videote
ecipes to dizzy.
Do you mean I need to upgrade "imx-vpu-3.10.17-1.0.0" (i.e. dizzy) to
imx-vpu_5.4.28.bb (i.e. fido) or to "imx-vpu_5.4.31.bb" (i.e. jethro)
along with libimxvpuapi_0.10.0.bb?
Regards,
Vikash
On Tue, Nov 17, 2015 at 10:27 PM, Carlos Rafael Giani
wrote:
&quo
, 2015 at 8:25 PM, Carlos Rafael Giani
wrote:
Hi, first, please provide logs without word wrap, it is harder to read
otherwise.
Second, can you try the latest git master of gstreamer-imx? Read its readme,
since it has a new dependency.
Third, the interesting bit seems to be the memory allocation
rlos,
Attached here the log file. I will check with the master branch. Is
there any other component I need to upgrade as I have only upgraded
gstreamer from fido to dizzy branch.
Regards,
Vikash
On Tue, Nov 17, 2015 at 8:25 PM, Carlos Rafael Giani
wrote:
Hi, first, please provide logs without w
1 - 100 of 335 matches
Mail list logo
