Package Details: lib32-gst-libav 1.24.8-1

Git Clone URL: https://aur.archlinux.org/lib32-gst-bad-ugly.git (read-only, click to copy)
Package Base: lib32-gst-bad-ugly
Description: Multimedia graph framework (32-bit) - libav plugin
Upstream URL: https://gstreamer.freedesktop.org/
Licenses: LGPL
Provides: lib32-gst-ffmpeg
Replaces: lib32-gst-libav-latest
Submitter: ahmubashshir
Maintainer: ahmubashshir (MarsSeed)
Last Packager: ahmubashshir
Votes: 46
Popularity: 0.030306
First Submitted: 2023-01-07 17:47 (UTC)
Last Updated: 2024-10-28 05:13 (UTC)

Pinned Comments

ahmubashshir commented on 2023-11-18 14:43 (UTC) (edited on 2023-11-18 14:44 (UTC) by ahmubashshir)

If you have any improvements/suggestions for the pkgbuilds I maintain, please create an issue/pr on github.com/ahmubashshir/pkgbuilds or send the patches to ahmubashshir+pkgbuilds@gmail.com

p.s. sorry for being late, I was busy with my mid and part-time job last three months... it was truly chaotic...

Latest Comments

« First ‹ Previous 1 .. 10 11 12 13 14 15 16 17 18 19 20 21 Next › Last »

DarkShadow44 commented on 2019-01-14 12:48 (UTC)

@Umbralump See the last two comments. You can use my patch in the meantime.

umbralump commented on 2019-01-14 05:15 (UTC)

Doesn't build for me anymore

gstfdkaacenc.c:74:8: error: ‘MODE_2_1’ undeclared here (not in a function); did you mean ‘MODE_6_1’? 3, MODE_2_1, { ^~~~~~~~ MODE_6_1 make[3]: *** [Makefile:874: libgstfdkaac_la-gstfdkaacenc.lo] Error 1

maybe is the problem of lib32-libfdk-aac?

rodrigo21 commented on 2019-01-13 21:34 (UTC) (edited on 2019-01-13 21:35 (UTC) by rodrigo21)

@DarkShadow44 I already have a updated lib32-libfdk-aac package which fix this error. I'm just waiting for my orphan request to be accepted.

I can build it without lib32-liblrdf and lib32-directfb.

DarkShadow44 commented on 2019-01-13 20:10 (UTC)

Needs both lib32-liblrdf and lib32-directfb for me. Also needs a patch for aac: https://gist.github.com/DarkShadow44/53e0f8a7f3fa177d3ac834c6dcd27d23

Mind merging these changes?

Nocifer commented on 2018-11-24 06:07 (UTC) (edited on 2018-11-24 11:33 (UTC) by Nocifer)

EDIT: Nevermind, fixed with the just released opencv 4.0.0 update.

Hi. I'm hitting this error when building with opencv 3.4.4:

  ...
  ...
  CXX      libgstopencv_la-gstgrabcut.lo
In file included from /usr/include/opencv2/imgproc/imgproc_c.h:46,
                 from gstgrabcut.cpp:90:
/usr/include/opencv2/imgproc/types_c.h:445:21: error: conflicting declaration of C function ‘CvMoments cvMoments(const cv::Moments&)’
 CV_INLINE CvMoments cvMoments(const cv::Moments& m)
                     ^~~~~~~~~
/usr/include/opencv2/imgproc/types_c.h:436:21: note: previous declaration ‘CvMoments cvMoments()’
 CV_INLINE CvMoments cvMoments()
                     ^~~~~~~~~
In file included from gstgrabcut.cpp:90:
/usr/include/opencv2/imgproc/imgproc_c.h:360:13: error: conflicting declaration of C function ‘void cvMoments(const CvArr*, CvMoments*, int)’
 CVAPI(void) cvMoments( const CvArr* arr, CvMoments* moments, int binary CV_DEFAULT(0));
             ^~~~~~~~~
In file included from /usr/include/opencv2/imgproc/imgproc_c.h:46,
                 from gstgrabcut.cpp:90:
/usr/include/opencv2/imgproc/types_c.h:445:21: note: previous declaration ‘CvMoments cvMoments(const cv::Moments&)’
 CV_INLINE CvMoments cvMoments(const cv::Moments& m)
                     ^~~~~~~~~
In file included from gstgrabcut.cpp:90:
/usr/include/opencv2/imgproc/imgproc_c.h:360:13: error: conflicting declaration of C function ‘void cvMoments(const CvArr*, CvMoments*, int)’
 CVAPI(void) cvMoments( const CvArr* arr, CvMoments* moments, int binary CV_DEFAULT(0));
             ^~~~~~~~~
In file included from /usr/include/opencv2/imgproc/imgproc_c.h:46,
                 from gstgrabcut.cpp:90:
/usr/include/opencv2/imgproc/types_c.h:436:21: note: previous declaration ‘CvMoments cvMoments()’
 CV_INLINE CvMoments cvMoments()
                     ^~~~~~~~~

Package builds successfully with opencv 3.4.3.

Given that opencv itself also builds fine, I'm guessing the 3.4.4 release broke something on gst's side of the equation. Should it be reported directly to gst upstream, or...?

InspMustache commented on 2018-11-04 22:16 (UTC)

lib32-liblrdf is required as a build dependency. At least it wouldn't build for me without it.

adam900710 commented on 2018-09-20 02:25 (UTC)

@rodrigo21, please report this problem to lib32-gst-plugins-base-libs.

As mentioned, the dependency chain breaks at lib32-gst-plugins-base-libs, not this package, and all lib32-* packages should depend on original package for headers.

rodrigo21 commented on 2018-09-20 02:16 (UTC)

I'm still having the same problem.  I had to add gst-plugins-base-libs as makepedends because it's not a dependency of lib32-gst-plugins-base-libs and this package needs /usr/include/gst/audio/audio.h.

« First ‹ Previous 1 .. 10 11 12 13 14 15 16 17 18 19 20 21 Next › Last »