Question about OE4T vs L4T GStreamer versions

[vinotion]

Hi,

We've observed that OE4T/meta tegra ships GStreamer-1.14.4, while L4T R32.6.1 ships with GStreamer-1.14.5 (and has been for a long time). Is there a particular reason for this?

We are currently migrating from L4T to OE4T and we are running into build discrepancies between our application builds and the libraries shipped with OE4T.

Thanks in advance!

[madisongh]

The gstreamer recipes we include in the meta-tegra/contrib layer were imported from the last OE-Core release that supported gstreamer 1.14 (from the warrior branch), which was based on 1.14.4. OE-Core moved on to gstreamer 1.16 and 1.18 in later branches, so the import was provided for folks that needed some compatibility for running NVIDIA-provided containers that contain gstreamer applications and plugins that were built against 1.14. (The NVIDIA container support for Jetson mixes container-provided binaries with libraries passthrough-mounted from the underlying OS.)

There's also a chance that one of the binary-only gstreamer plugins that NVIDIA provides with L4T won't interoperate with later versions of gstreamer, but there haven't been any such issues reported, at least recently.

So it's up to you to decide which version of gstreamer you want to ship for your builds - in many cases, just using the version provided in OE-Core will work.

Are these discrepancies you mention just differences, or are they causing issues of some kind?

[vinotion]

Hi Matt,

Thanks for the quick response! I see.

Well, we noticed the version on our application build-side (v1.14.5) and the OE4T version (v1.14.4) and wondered about why there was this difference to L4T. But now we know.

We don't think there will be any issues regarding ABI-changes, at least, let's hope not. The differences came up due to Yocto reverse-looking up the dynamic library dependencies of our application.