latest version of gst-ffmpeg for mipsel

  • 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 :frowning_face:


    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 :winking_face:


    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 ) ...