I understand this, but there are significant downsides:
- It is harder to review patches if they are part of a fork, and there
have been very questionable patches in the past (like one patch that
tried to set the rank of *all* default GStreamer demuxers and decoders
to 63 so that only aiur etc. can be used). NXP can insert a whole lot of
dubious patches, and it is out of our reach. We've already seen this in
the kernel sometimes.
- It collides with GStreamer updates from OE-core. If for example
OE-core moves to 1.14, then these bbappends no longer apply, and
GStreamer suddenly behaves differently for users.
- New GStreamer versions will be available only when NXP decides to
update their fork. And as we've seen with the kernel, moving to newer
versions can take quite some time.
- if I want to use the upstream GStreamer instead of the fork, I have to
write a whole bunch of .bbappend files.
- It is a distro-wide change enforced by one BSP maker. This alone is
already a deal-breaker for me. A BSP layer should not do something this
severe, at least not by default.
- In a Yocto setup with multiple BSP layers (say, for building for NXP
machines and other machines as well), this can cause collisions, since
the other layers expect the upstream GStreamer. Right now, we can
identify the cause by checking patches and fix it by excluding them.
Also, if, as said, the NXP fork is behind - say, it is at 1.12, and 1.14
is current at that time - and the other BSP layers expect 1.14, then
they instead get a forked 1.12.
So, I definitely think this should be _opt-in_. Add to the documentation
that for using the NXP fork, you have to set this flag in local.conf etc.
Carlos
On 2017-12-29 03:30, Jun Zhu wrote:
Hi, Carlos,
The idea to use i.MX forks is to collect all of the i.MX specific
patches/enhancement to take the advantages for i.MX HW acceleration.
- Recently, we have many i.MX specific patches to added GStreamer formal
releases, for example, 30+ patches (i.MX + opensource) are needed for
gstreamer-plugins-bad.
- These patches may fail to apply if the GStreamer is upgraded to a new version
as the code base for patches are changed. This is reason why current GStreamer
build break on the master branch build.
For the GStreamer's i.MX forks:
- They are forked from the tags of the formal GStreamer releases and contains
all of the i.MX specific patches;
- It supports to apply the new patches in the bbappend.
I suggest that community can consider to using the GStreamer i.MX forks as
default, it is good for the i.MX users to take the advantages for i.MX HW
acceleration.
BR,
Jun Zhu
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Carlos Rafael
Giani
Sent: Tuesday, December 26, 2017 4:11 PM
To: [email protected]
Subject: Re: [meta-freescale] [PATCH 0/9] Upstream Multimedia patches for
L4.9.51_MX8MQ Beta release
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 configurable. If some distro-wide flag is set, the fork is
used.
On 2017-12-26 07:10, Yuqing Zhu wrote:
-Change default IMX_MIRROR to a new NXP one
-Upgrade imx-codec/imx-parser/imx-vpuwrap/imx-gst1.0-plugin to v4.3.2
-Add Gstreamer bbappend back, be compatible with current v1.12
Switch to use i.MX fork of GST.
All patches are put into this exteranl fork.
Yuqing Zhu (9):
layer.conf: Change default IMX_MIRROR to a new NXP one
imx-codec: Upgrade to v4.3.2
imx-parser: Upgrade to v4.3.2
imx-vpuwrap: Upgrade to v4.3.2
gstreamer1.0: Use i.MX fork of GST for customizations
gstreamer1.0-plugins-base: Use i.MX fork of GST for customizations
gstreamer1.0-plugins-good: Use i.MX fork of GST for customizations
gstreamer1.0-plugins-bad: Use i.MX fork of GST for customizations
imx-gst1.0-plugin: Upgrade to v4.3.2
conf/layer.conf | 2 +-
...-bad-Correct-PKG_COFING-directory-for-WAY.patch | 27 +++++++++++
.../gstreamer1.0-plugins-bad_1.12.%.bbappend | 53
++++++++++++++++++++++
.../gstreamer1.0-plugins-base_1.12.%.bbappend | 30 ++++++++++++
.../gstreamer1.0-plugins-good_1.12.%.bbappend | 15 ++++++
.../gstreamer/gstreamer1.0_1.12.%.bbappend | 16 +++++++
...-plugin_4.1.6.bb => imx-gst1.0-plugin_4.3.2.bb} | 12 ++---
recipes-multimedia/imx-codec/imx-codec.inc | 2 +-
recipes-multimedia/imx-codec/imx-codec_4.2.1.bb | 10 ----
recipes-multimedia/imx-codec/imx-codec_4.3.2.bb | 10 ++++
recipes-multimedia/imx-parser/imx-parser.inc | 2 +-
recipes-multimedia/imx-parser/imx-parser_4.2.1.bb | 10 ----
recipes-multimedia/imx-parser/imx-parser_4.3.2.bb | 10 ++++
...{imx-vpuwrap_1.0.68.bb => imx-vpuwrap_4.3.2.bb} | 6 +--
14 files changed, 173 insertions(+), 32 deletions(-)
create mode 100644
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-gst-plugins-bad-Correct-PKG_COFING-directory-for-WAY.patch
create mode 100644
recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.%.bbappend
create mode 100644
recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.%.bbappend
create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0_1.12.%.bbappend
rename recipes-multimedia/gstreamer/{imx-gst1.0-plugin_4.1.6.bb =>
imx-gst1.0-plugin_4.3.2.bb} (89%)
delete mode 100644 recipes-multimedia/imx-codec/imx-codec_4.2.1.bb
create mode 100644 recipes-multimedia/imx-codec/imx-codec_4.3.2.bb
delete mode 100644 recipes-multimedia/imx-parser/imx-parser_4.2.1.bb
create mode 100644 recipes-multimedia/imx-parser/imx-parser_4.3.2.bb
rename recipes-multimedia/imx-vpuwrap/{imx-vpuwrap_1.0.68.bb =>
imx-vpuwrap_4.3.2.bb} (76%)
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
