OBS redux

oxez

New Member
Hello.

I am impressed by the work you have done on the multi-platform rewrite so far, keep it up! I might be able to contribute some code in the near future, depends on my other projects.

Jim, you have stated earlier in the thread that you are running Debian. I am also running Debian. The issue right now is that they do NOT include ffmpeg in their repos, but they include libav (this could change for Debian 8, see this RFP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203). libav is NOT compatible with ffmpeg, but the opposite is true (ffmpeg is compatible with libav)

Assuming they stick with libav, will you consider adding support for it? Remember that Ubuntu also went the libav way, that's a huge chunk of linux users there. Of course we can use deb-multimedia.org, but myself I try to not use 3rd party repos unless I 'really' need to..

Hopefully the Debian Multimedia team will go ahead and go back to ffmpeg (it's superior to libav in everyway, as in it merges libav code and add new features themselves), but gotta prepare for the worst !

Thanks !
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
As I said the previous time this came up, if it's not very difficult to use both, then I don't mind. However, if it becomes too much of a pain to maintain both, then no, I will not support both, you will have to download whichever one I choose for whichever distro you are using.

Just so you know. you -can- download ffmpeg for debian-based distros and livav for ffmpegs distros. It's not -that- hard to set up. In fact, it's very easy to set up.
 

oxez

New Member
Thanks for the quick reply, I'll see if there are simple ways to support both libraries (surely the popular applications do like VLC)

While I know it is easy to setup ffmpeg on debian, I prefer not using third party repositories (example: deb-multimedia offer ffmpeg packages along with other packages depending on it)
 

JPL

Member
Hello! This project seems to be progressing at a commendable rate, so I thought I'd try to build it and see how usable it is. I'm running Ubuntu 13.10 64-bit with the built-in Nvidia binary drivers, so my setup is fairly standard.

Right now I can't seem to get the project to build. Is autoconf still the preferred option for this, or is cmake support now functional? I get different errors at different stages of compilation with each.

When I run autogen.sh in the base directory, it generates a configure file, and when I run that I get this error:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking for gawk... gawk
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU Objective C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking dependency style of g++... gcc3
checking for a sed that does not truncate output... (cached) /bin/sed
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for X11... yes
checking for XINERAMA... yes
checking for GTK... yes
checking libavcodec/avcodec.h usability... yes
checking libavcodec/avcodec.h presence... yes
checking for libavcodec/avcodec.h... yes
checking libavformat/avformat.h usability... yes
checking libavformat/avformat.h presence... yes
checking for libavformat/avformat.h... yes
checking libavutil/avutil.h usability... yes
checking libavutil/avutil.h presence... yes
checking for libavutil/avutil.h... yes
checking libavutil/channel_layout.h usability... yes
checking libavutil/channel_layout.h presence... yes
checking for libavutil/channel_layout.h... yes
checking libswscale/swscale.h usability... yes
checking libswscale/swscale.h presence... yes
checking for libswscale/swscale.h... yes
checking libswresample/swresample.h usability... yes
checking libswresample/swresample.h presence... yes
checking for libswresample/swresample.h... yes
checking for avcodec_find_encoder_by_name in -lavcodec... yes
checking for av_guess_format in -lavformat... yes
checking for av_samples_alloc in -lavutil... yes
checking for sws_scale in -lswscale... yes
checking for swr_convert in -lswresample... no
configure: error: libswresample not found

I seem to have the libswresample library installed, though via the libmyth-dev package:
$ apt-file find libswresample
libmyth-dev: /usr/include/mythtv/libswresample/swresample.h
libmyth-dev: /usr/include/mythtv/libswresample/version.h

When I try to build via Cmake, it generates makefiles, but I get these errors when I try to make:
[ 1%] Building C object libobs/CMakeFiles/libobs.dir/obs.c.o
/home/jpl/src/obs-studio/libobs/obs.c: In function ‘obs_init_data’:
/home/jpl/src/obs-studio/libobs/obs.c:235:2: warning: implicit declaration of function ‘pthread_mutexattr_settype’ [-Wimplicit-function-declaration]
if (pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE) != 0)
^
/home/jpl/src/obs-studio/libobs/obs.c:235:39: error: ‘PTHREAD_MUTEX_RECURSIVE’ undeclared (first use in this function)
if (pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE) != 0)
^
/home/jpl/src/obs-studio/libobs/obs.c:235:39: note: each undeclared identifier is reported only once for each function it appears in
/home/jpl/src/obs-studio/libobs/obs.c: In function ‘obs_set_output_source’:
/home/jpl/src/obs-studio/libobs/obs.c:481:2: warning: passing argument 3 of ‘calldata_getptr’ from incompatible pointer type [enabled by default]
calldata_getptr(&params, "source", &source);
^
In file included from /home/jpl/src/obs-studio/libobs/obs.c:18:0:
/home/jpl/src/obs-studio/libobs/callback/calldata.h:188:20: note: expected ‘void **’ but argument is of type ‘struct obs_source **’
static inline bool calldata_getptr (calldata_t data, const char *name,
^
/home/jpl/src/obs-studio/libobs/obs.c: At top level:
/home/jpl/src/obs-studio/libobs/callback/calldata.h:355:13: warning: ‘calldata_setchar’ defined but not used [-Wunused-function]
static void calldata_setchar (calldata_t data, const char *name, char val)
^
make[2]: *** [libobs/CMakeFiles/libobs.dir/obs.c.o] Error 1
make[1]: *** [libobs/CMakeFiles/libobs.dir/all] Error 2
make: *** [all] Error 2

For what it's worth, I built (successfully, and installed) ffmpeg from source after seeing the instructions recommend that.

If these errors are due to the project's incompleteness, I understand completely and can wait a while before trying again. If not, maybe this is helpful as the experience of a non-contributor.

Please continue the awesome work!
 

Weegee

New Member
JPL said:
I seem to have the libswresample library installed, though via the libmyth-dev package:
It's a problem related to the libav/ffmpeg split in Debian and Ubuntu. libav is a fork from ffmpeg which is not compatible with ffmpeg, so there are library issues if some project depends on stuff from ffmpeg which doesn't exist in libav. I think this only affects Debian and Ubuntu though as every other distribution uses ffmpeg instead of libav (correct me if I'm wrong).

So yeah, the only way to compile OBS on Debian/Ubuntu right now is by compiling ffmpeg from source first.

JPL said:
If these errors are due to the project's incompleteness, I understand completely and can wait a while before trying again. If not, maybe this is helpful as the experience of a non-contributor.
Linux support is reeeally rudimentary right now. Even though I can compile OBS (Arch Linux x64 here), it immediately crashes and outputs the following:
Code:
Attempted path: /usr/local/share/obs-studio/locale/en.txt
Attempted path: /usr/share/obs-studio/locale/en.txt

(obs:12085): Gdk-WARNING **: gdkdrawable-x11.c:952 drawable is not a pixmap or window
X and Y: 741 385
Backbuffers: 2
Color Format: 3
ZStencil Format: 0
Adapter: 0

GLX error: BadMatch (invalid parameter attributes)

Failed to make context current.
device_create (GL) failed
Number of memory leaks: 0
Also, the main focus is on Windows (and OSX if you look at the GitHub commit messages?) at the moment I guess, although there has been some Linux work. I think Jim needed more Linux developers some time ago, but I don't know what the current situation looks like.

JPL said:
Please continue the awesome work!
Yeah Jim, do that :)
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
We still don't have linux working as nicely as I'd like right now. There are a number of issues with it at the moment. One especially is getting hardware acceleration working properly with non-proprietary graphics drivers, because they don't have some of the features we're currently using. However, it is being worked on.
 

computerquip

New Member
Well, I'm still working on it. :/

The crash above has been temporarily fixed on my branch. It's just a matter of one function call that fixes it but I'm not sure if that "fix" is permanent. I don't like putting in temporary fixes that might create other issues eventually.

EDIT: For instance, SFML actually uses this fix in one of its tutorials. Look below or search for "__WXGTK__" on this page: http://sfml-dev.org/tutorials/1.6/graph ... idgets.php

While other implementations simply don't need that. The tutorial is a bit old however so I'm trying to make sure nothing has change since this was created and that the quirk is still required.
 

computerquip

New Member
Also, concerning Cmake:

CMake is currently MacOSX only. I have a branch that allows it to work on Linux but there are quirks with it on MacOSX. I do not have a Mac at all so I can't test it to get it to work. For right now, priority for Linux is autotools. CMake is for MacOSX.

If the cheapest retail Mac wasn't just above $600, I might have considered buying a Mac for development....
 

JPL

Member
Thanks for the reply, folks.

I followed the instructions for compiling ffmpeg from source on this page:

https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide

and now I have a compiled version of ffmpeg with all the fixins in a folder in my home directory called ~/ffmpeg_build. How would I point this project's configure script towards that? The params I've used for other projects don't seem to work here.
 

computerquip

New Member
You could probably just use the install ability of the make script in FFmpeg. It will install into /usr/local by default which is good since it separates those libraries from what your package manager manages.

The libraries need to be present even after you configure obs-studio.
 

Joseei

New Member
Hey Jim, any estimate till we can use this? I'd love to stream with OBS but my Hauppuge HD PVR 2 just gets a red screen.
 

dodgepong

Administrator
Forum Admin
The estimate still hasn't changed. An initial alpha is still expected to come early this year, so sometime within the next couple months.
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
We're going to be attempting to switch to QT soon. Have a preliminary FFmpeg output for testing but I need to go over the UI stuff first again before I can use it.
 

Tak0r

Member
Are you going to have it done with the QT VS plugin or directly with QT Creator?

Anyways very good move dropping the crap idea of using wxWidgets :)
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
wxWidgets wasn't particularly what I'd consider a crap idea. It's a good library for native widgets. The reason I did it was in consideration of plugin developers so it would have a lower bar of entry, and so they would have access to a form dialog editor and such.

I'm using the visual studio plugin.
 

Weegee

New Member
Cool, Qt5 is a nice toolkit to work with :)

Now I just need to update my build scripts, though I'll better wait with that until there's a new INSTALL file with the updated dependencies. Nice to see this switch though!
 
Top