Hi Carlos, No matter if we switch to use GST fork or not, the current bbappends shouldn't be applied after OE-core does upgrade. We couldn't guarantee the current patch is compatible with the new version. That's why we add version filter into bbappend, eg: gstreamer1.0_1.12.%.bbappend.
And we add 'imx' filter when switching to use NXP GST fork, so the change is for i.MX platform only. In current release, all the patches are in the external NXP GST fork, no standalone patch integration in bbappend. I am not very clear about the "opt-in" suggestion, could you give more clarification? Thanks ~ B.R. Carol -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carlos Rafael Giani Sent: Friday, December 29, 2017 5:02 PM To: Jun Zhu <[email protected]> Cc: [email protected] Subject: Re: [meta-freescale] [PATCH 0/9] Upstream Multimedia patches for L4.9.51_MX8MQ Beta release 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fmeta-freescale&data=02%7C01%7Ccarol.zhu%40nxp.com%7Cb1755d067e584ece4aac08d54e9ae0b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636501349476547933&sdata=igv34qyoOcQOKX%2FKyXQQ1bNTaxHwQPsX1gmSS2KZjXg%3D&reserved=0 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
