openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: gstreamer status for 4.2.0-dev?
Date Tue, 29 May 2018 18:30:07 GMT
I think the hope is to continue using CentOS5 for our official AOO community builds. If not,
then this becomes much easier, but it is, IMO, a major policy decision to do that. recall
that gstreamer-1.x is incompatible w/ CentOS5.

I have no idea how to do #2 but #1 looks like simple brute force. Certainly not elegant but
if that's what it takes to get past this holding pattern, then that's what we have to do.

> On May 28, 2018, at 3:12 AM, Damjan Jovanovic <> wrote:
> 3. Build on a newer CentOS or other distro.
> 4. Link to 1.0.0 using run-time dynamic linking, using that patch I made,
> and only require the gstreamer-1.0.0 tarball at compile time to find the
> headers.
> Damjan
> On Mon, May 28, 2018 at 9:06 AM Peter kovacs <> wrote:
>> Imho the gstreamer libs are still the method of choice for doing
>> multimedia.
>> The current state is that trunk can utilize the gstreamer API 1.0.0
>> We have the issue not resolved the issue to provide gstreamer for
>> different Distributions. (Main issue: centos6 is to old to support the new
>> gstreamer 1.0.0 API)
>> We have 2 suggestions to solve the issue:
>> 1) implement 0.1.0 and 1.0.0 API.
>> 2) move the implementation into an optional extention.
>> Both solutions have currently not followed up.
>> All the best
>> Peter
>> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk <>:
>>> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
>>>> Subj line sez it all... where are we? There was a proposal to make it
>>> a run-time dependency but afaict there hasn't been any effort yet it
>>> doing that.
>>>> I know we have a handful of other things TODO re: 4.2.0 but this
>>> seems to be an inflection point for the Linux builds and so I really
>>> think we need to resolve this if we have any intent in getting a 4.2.0
>>> beta out in a reasonable time frame.
>>> What would happen if we simply stopped including the --with-gstreamer
>>> option in the build? Mac and Windows builds don't use it, and it only
>>> applies to Linux.
>>> I haven't investigated the code much to see how the gstreamer libraries
>>> are used. The Linux distros now mostly use Freedesktop lower level
>>> interfaces except I don't know what Unity uses. Is building with
>>> gstreamer still needed/compliant with this? In short, how are video
>>> applications determined in Linux now? Do we need a different approach
>>> for integration of video objects in Linux?
>>> If anyone knows the history of this, it would be very helpful to this
>>> discussion.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message