[furii]

i did get sound, just no video.

this is what codecinfo shows:

note, since there was no video playing i had to manually go into now playing and pull that up.

i'm not sure why it's showing that file doesn't exist:

Code:

xbmc@simone:/usr/local/lib/xbmc/system/players/dvdplayer$ ll
total 48084
drwxr-xr-x 2 root root     4096 Mar 10 16:32 ./
drwxr-xr-x 4 root root     4096 Mar 10 16:32 ../
-rwxr-xr-x 1 root root 33749220 Mar 10 16:32 avcodec-53-i486-linux.so*
-rwxr-xr-x 1 root root  3119685 Mar 10 16:32 avfilter-2-i486-linux.so*
-rwxr-xr-x 1 root root  8636915 Mar 10 16:32 avformat-53-i486-linux.so*
-rwxr-xr-x 1 root root   640022 Mar 10 16:32 avutil-51-i486-linux.so*
-rwxr-xr-x 1 root root   144538 Mar 10 16:32 libdvdcss-i486-linux.so*
-rwxr-xr-x 1 root root   888574 Mar 10 16:32 libdvdnav-i486-linux.so*
-rwxr-xr-x 1 root root   583843 Mar 10 16:32 postproc-52-i486-linux.so*
-rwxr-xr-x 1 root root   245075 Mar 10 16:32 swresample-0-i486-linux.so*
-rwxr-xr-x 1 root root  1205818 Mar 10 16:32 swscale-2-i486-linux.so*

new log just in case: http://xbmclogs.com/show.php?id=3709

[flyingrat]

Thanks for the update! But as I explained, I'm not able to do anything about it myself for the moment. Someone with a decent linux environment has to help out in this case...

[vicbitter]

i did get sound, just no video.

this is what codecinfo shows:

note, since there was no video playing i had to manually go into now playing and pull that up.

i'm not sure why it's showing that file doesn't exist:

Code:

xbmc@simone:/usr/local/lib/xbmc/system/players/dvdplayer$ ll
total 48084
drwxr-xr-x 2 root root     4096 Mar 10 16:32 ./
drwxr-xr-x 4 root root     4096 Mar 10 16:32 ../
-rwxr-xr-x 1 root root 33749220 Mar 10 16:32 avcodec-53-i486-linux.so*
-rwxr-xr-x 1 root root  3119685 Mar 10 16:32 avfilter-2-i486-linux.so*
-rwxr-xr-x 1 root root  8636915 Mar 10 16:32 avformat-53-i486-linux.so*
-rwxr-xr-x 1 root root   640022 Mar 10 16:32 avutil-51-i486-linux.so*
-rwxr-xr-x 1 root root   144538 Mar 10 16:32 libdvdcss-i486-linux.so*
-rwxr-xr-x 1 root root   888574 Mar 10 16:32 libdvdnav-i486-linux.so*
-rwxr-xr-x 1 root root   583843 Mar 10 16:32 postproc-52-i486-linux.so*
-rwxr-xr-x 1 root root   245075 Mar 10 16:32 swresample-0-i486-linux.so*
-rwxr-xr-x 1 root root  1205818 Mar 10 16:32 swscale-2-i486-linux.so*

new log just in case: http://xbmclogs.com/show.php?id=3709

This looks like a path problem. Just as a test try copying postproc-52-i486-linux.so into /lib and see if that works.

[flyingrat]

It worked for me by manually add a shared library search path thus the problem may originate from an install script problem:

Code:

# export LD_LIBRARY_PATH=/usr/local/lib/xbmc/system/players/dvdplayer
# xbmc

I have similar problems with win32 since the build and install scripts (for ffmpeg) are version dependent but after some manual tricks I even got win32 to work as well. Besides the install script issues we now have osx, linux and win32 working with ffmpeg n1.1.3. Vicbitter, how is the RPi doing?

Btw, I can now confirm it works like a charm to run xbmc on vmware fusion!

[flyingrat]

I forgot to mention that I'll probably do some refactoring on the fork when I get home and add a separate branch for each platform...

[vicbitter]

It worked for me by manually add a shared library search path thus the problem may originate from an install script problem:

Code:

# export LD_LIBRARY_PATH=/usr/local/lib/xbmc/system/players/dvdplayer
# xbmc

I have similar problems with win32 since the build and install scripts (for ffmpeg) are version dependent but after some manual tricks I even got win32 to work as well. Besides the install script issues we now have osx, linux and win32 working with ffmpeg n1.1.3. Vicbitter, how is the RPi doing?

Btw, I can now confirm it works like a charm to run xbmc on vmware fusion!

RPi is working too!

[flyingrat]

Regarding win32, there's another thing that needs to be dealt with. To properly build ffmpeg and avoid the "library.mak: *** missing separator" issue with GNU Make 3.81 on win32, git needs to (in contrast to xbmc Git_Usage) be configured with:

Code:

git config --global core.autocrlf false

FFmpeg ref: https://ffmpeg.org/trac/ffmpeg/ticket/1209

---

RPi is working too!

Vicbitter, you are the man!

[flyingrat]

Win32 is working quite ok now! I'm just gonna test if I can do the ffmpeg integration "version agnostic" before I upload the changes...

[flyingrat]

I'm just gonna test if I can do the ffmpeg integration "version agnostic" before I upload the changes...

It seems that the ffmpeg make script for MinGW32 is flawed as it tries to symlink a version specific dll to a version independent name i.e. "ln -sf avcodec-54.dll avcodec.dll" on win32 but the result is instead two separate but identical files: avcodec-54.dll and avcodec.dll. Although they are identical, all link references are pointing to avcodec-54.dll which makes the version neutral file name avcodec.dll useless to include in xbmc.

This is a snippet from the build script for libavcodec:

Code:

gcc -shared -Wl,--output-def,libavcodec/avcodec-54.orig.def -Wl,--out-implib,libavcodec/libavcodec.dll.a -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base -Wl,-Bsymbolic -Wl,--version-script,libavcodec/libavcodec.ver ...
sed -e "s/ @[^ ]*//" libavcodec/avcodec-54.orig.def > libavcodec/avcodec-54.def; lib.exe /machine:i386 /def:libavcodec/avcodec-54.def /out:libavcodec/avcodec.lib
cd ./libavcodec/ && [b]ln -sf avcodec-54.dll avcodec.dll[/b]
lib.exe /machine:i386 /def:libavcodec/avcodec-54.def /out:libavcodec/avcodec.lib

I'll fix a workaround in build_xbmc_win32.sh that slurps the version number and creates a "DllPaths_win32_ffmpeg.h" and copies only the necessary files to xmbc/system/players/dvdplayer

Question for the windows guru: What's the best practice to create a version neutral path name for a dll that still may interact with a version dependent and numbered dll corresponding to symlinks used by linux/unix/osx world to manage libraries?? (I've googled it but couldn't find any decent info on the subject...)

[flyingrat]

This is the new win32/ffmpeg version independent build script "ffmpeg/build_xbmc_win32.sh" for review. It's tested and works as expected. Comments and suggestions are welcome!

Code:

#!/bin/bash

MAKEFLAGS=""

# add --enable-debug (remove --disable-debug ofc) to get ffmpeg log messages in xbmc.log
# the resulting debug dll's are twice to fourth time the size of the release binaries

OPTIONS="
--enable-shared \
--enable-memalign-hack \
--enable-gpl \
--enable-w32threads \
--enable-postproc \
--enable-zlib \
--disable-static \
--disable-altivec \
--disable-muxers \
--disable-encoders \
--disable-debug \
--disable-ffplay \
--disable-ffserver \
--disable-ffmpeg \
--disable-ffprobe \
--disable-devices \
--disable-crystalhd \
--enable-muxer=spdif \
--enable-muxer=adts \
--enable-encoder=ac3 \
--enable-encoder=aac \
--enable-runtime-cpudetect \
--enable-avfilter \
--disable-doc"

#
# Flag when ffmpeg is configured
#

WIN32CONF=.win32configured
DLLPATHS_INCLUDE=/xbmc/xbmc/DllPaths_win32_ffmpeg.h


#
# Set parallel build mode
#

if [ $NUMBER_OF_PROCESSORS > 1 ]
then
  MAKEFLAGS=-j$NUMBER_OF_PROCESSORS
fi


#
# Clean object files and libraries
#

if [ "$1" == "clean" ]
then
  make distclean
  rm -f $WIN32CONF $DLLPATHS_INCLUDE
fi


#
# Only run configure when neccesary and break if configure fails.
#

if [ ! -f $WIN32CONF ]; then

  echo "$0: Running ffmpeg configure..."

  if ./configure --extra-cflags="-fno-common -Iinclude-xbmc-win32/dxva2 -DNDEBUG" \
                --extra-ldflags="-L/xbmc/system/players/dvdplayer" ${OPTIONS}; then
    touch $WIN32CONF
  else
    echo "$0: configure failed."
    exit 1
  fi
fi


#
# @FFMPEG113 - version agnostic build, copy and generate DLL-paths include file.
#

# enable break on error:
set -e

make $MAKEFLAGS

DLL_PATH_LIBAVCODEC=$(set -- libavcodec/avcodec-[0-9]*.dll; echo $1)
DLL_PATH_LIBAVFORMAT=$(set -- libavformat/avformat-[0-9]*.dll; echo $1)
DLL_PATH_LIBAVUTIL=$(set -- libavutil/avutil-[0-9]*.dll; echo $1)
DLL_PATH_LIBAVFILTER=$(set -- libavfilter/avfilter-[0-9]*.dll; echo $1)
DLL_PATH_LIBPOSTPROC=$(set -- libpostproc/postproc-[0-9]*.dll; echo $1)
DLL_PATH_LIBSWSCALE=$(set -- libswscale/swscale-[0-9]*.dll; echo $1)
DLL_PATH_LIBSWRESAMPLE=$(set -- libswresample/swresample-[0-9]*.dll; echo $1)

#
# @FFMPEG113 - Generate dll path defintion file $DLLPATHS_INCLUDE
#

for DLL in    DLL_PATH_LIBAVCODEC DLL_PATH_LIBAVFORMAT DLL_PATH_LIBAVUTIL \
        DLL_PATH_LIBAVFILTER DLL_PATH_LIBPOSTPROC DLL_PATH_LIBSWSCALE \
        DLL_PATH_LIBSWRESAMPLE
do
    echo "#define $DLL        \"special://xbmcbin/system/players/dvdplayer/$(basename ${!DLL})\""
done > $DLLPATHS_INCLUDE

#
# @FFMPEG113 - Copy dll's to system player folder
#

cp $DLL_PATH_LIBAVCODEC        /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBAVFORMAT    /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBAVUTIL        /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBAVFILTER    /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBPOSTPROC    /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBSWSCALE        /xbmc/system/players/dvdplayer/
cp $DLL_PATH_LIBSWRESAMPLE    /xbmc/system/players/dvdplayer/

[WiSo]

IMHO we change ffmpeg libs not very often so I wouldn't spend any time to get the buildscript version independent. Once a year I have no problem to change those by hand
The make file produced two identical files since I can remember but just take the versioned libs and you're done.

[Martijn]

IMHO we change ffmpeg libs not very often so I wouldn't spend any time to get the buildscript version independent. Once a year I have no problem to change those by hand
The make file produced two identical files since I can remember but just take the versioned libs and you're done.

Wasn't the plan to bump version more often to follow releases? If we get patches upstream it should become easier

[WiSo]

even then I would't spend time on it. the only change needed is updating the buildscript and the dllpaths (ca. 1 minute work).
But thats just my opinion and I wouldn't reject an automatic solution.

[WiSo]

And don't forget that you need to alter the buildprocess if you generate the dllpath header. Currently the vs project is build first and afterwards the mingw libs. This won't work anymore and needs to be changed and reviewed as it could have side effects.

[flyingrat]

IMHO we change ffmpeg libs not very often so I wouldn't spend any time to get the buildscript version independent. Once a year I have no problem to change those by hand
The make file produced two identical files since I can remember but just take the versioned libs and you're done.

Well, this will certainly not make it worse (I hope!). The objective is to be able to lift ffmpeg to any new version without to much trouble with manual "reconfigurations".

If you are a believer in "Continuous Delivery" (as I am) then anything that can, should be automated to avoid that Mr Murphy shows up when you prepare for new changes.

I have already met Murphy way too many times!

---

And don't forget that you need to alter the buildprocess if you generate the dllpath header. Currently the vs project is build first and afterwards the mingw libs. This won't work anymore and needs to be changed and reviewed as it could have side effects.

Thanks for the info! I've adjusted "buildmingwlibs.sh" but you are correct about the build process that needs to be reviewed. I'll look in to it! /Cheers, Lars.

---

Fork is now refreshed (rebased) and I added a new branch "ffmpeg-n1.1.3" that should build cleanly on linux/ubuntu, osx, win32 and rpi although I cant guarantee the main stream is clean (saw something about osx yesterday). I'll plan to start working on ios tomorrow...