Does anybody latest version of gst-ffmpeg for mipsel (gst-ffmpeg-0.10.13)?
Or could you advice me how to compile it for mipsel ?
Thanks a lot
Does anybody latest version of gst-ffmpeg for mipsel (gst-ffmpeg-0.10.13)?
Or could you advice me how to compile it for mipsel ?
Thanks a lot
try this one, maybe --nodeps required during install ...
thanks a lot
i have tried it via command:
gst-inspect-0.10 /usr/lib/gstreamer-0.10/libgstffmpeg.so
vith result:
- liborc-0.4.so.0: cannot open shared object file
- libbz2.so.1: cannot open shared object file
Than I have downloaded some packages for mipsel from debian mipsel distribution and unpacked them and inserted into usr/lib and result after same command: gst-inspect ... :
- libgstffmpeg.so: undefined symbol: g_malloc_n
and for libraries libgstpostproc.so and libgstffmpegscale.so with command: gst-inspect ...:
- libgstpostproc.so: undefined symbol: gst_element_class_add_static_pad_template
Do you know where is the mistake? That I have used liborc and libbz2 from debian distribution?
Thanks
first the two missing libs,
2nd, i'm using the latest git-builds of gstreamer, which can cause incompatibilities.
but give it a try .. else u must wait for one, who is using the "main-stream"-build ...
//edit
btw. g_malloc_n was introduced in glib 2.24 ... afaik ist dmm still using 2.22 ...
Thanks!!! You are first man who are able to help!
I have tried it but there were missing libglib as you said.
I have again downloaded that library and than was missing libpcre.so.3. Again downloaded from debain and than I have tried my test and result was frozen without any info.
I thing it was based on incompatibilities
Do you have any ideas what I could try it?
the best option u have is to setup your own build-environment ...
the next best is to wait for dmm, because newer gstreamer builds require the new glib 2.24
the worst one, is to wait for someone
btw. exchange "base" libaries, like glib is almost a bad idea, cause it is used in many other apps.
different minor build versions shouldn't be a (api-)problem ( like 2.22 -> 2.24 ), but i wouldn't recommenced without rebuild all others.
and it isn't allways a good idea, to exchange debian packages ( mostly libs ) with the oe build system from dmm.
applications maybe no problem or not widely used libaries ...
but only 1 changed api-call can result in an unusable box ( without reflashing ) ...