I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested)
Notice, VDR can only be run as client for another VDR system as there's no support for DVB devices. Server-VDR needs a streamdev-server or xineliboutput plugin which can stream the reception to the client.
Patches and short instrucions can be found from here:
http://kotisivu.suomi.net/izero/vdr-darwin/vdr-darwin.html
Tero Siironen wrote:
Sounds really good.
I will play tomorrow.
How easy would it be to package up a version of, say vdr-sxfe for mac with xine incorporated? In such a way that it runs, searches for a vdr server on the local net and auto connects?
2007/1/29, Rob Davis rob.davis@libero.it:
I don't know how hard it would be, but idea sounds very good. One problem currently is that Xine-lib doesn't compile clean on OS X yet. Some patches exists already but they don't solve all the compiling problems. Also accelerated video out is needed to get the performance, Xshm is too heavy for everyday use.
Another thing that I would like to someone dig in are the DVB-drivers for OS X by John Dalgliesh (http://www.defyne.org/dvb/driver.html) which are originally based on Linux v4l drivers. Maybe VDR could be adopted for those drivers or some kind of a wrapper could be made to get DVB device support on OS X.
Hi Tero,
Tero Siironen schrieb:
I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested)
Funny, a friend, Stefan Rieke and me are also working on getting VDR to run on Mac OS X. We have VDR 1.4.0 running on OS X 10.3.9 and 10.4.8, together with a few plugins. I think we are a bit more advanced than you, we have a special version of the softdevice which has native audio and video Mac OS X support (the video is displayed via OpenGL), and a very alpha version of an mminput-plugin, which makes it possible to use USB DVB devices on Mac OS X together with the VDR. However after a short look you patches to VDR seem to be cleaner than ours ;-)
We planned to publish our work some time ago, but up to now we delayed it again and again... Maybe we can join our efforts? If you are interested, you (or anyone else...) can find our special softdevice version at
http://butler.physik.uni-mainz.de/~wache/softdevice-macosx.tbz
We developed it using a PowerPCs, so there might be some endian problems on Intel Systems. The package also contains short instructions how to build the softdevice and ffmpeg.
Bye, Martin
Martin Wache wrote:
A few months ago I have received a patch that adapts VDR to the Mac from Andreas Thiede (a.thiede at berlin dot de), but haven't had time to really look into it yet (shame on me - I'm permanently out of time...). Don't know if he's working with any of you. Anyway, if this is supposed to go into the main VDR source one day, it might be best if you join forces and agree on common solution. I would appreciate if the impact on the VDR source could be kept to a minimum by putting everything as far as possible into a separate compat.[hc] and avoiding tons of "#ifdef __APPLE__" all over the place.
Klaus
2007/1/29, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
I agree. These patches I made on purpose that way that it has those conditional compilings, so everyone could see what has been changed as it makes the bug hunting easier. Non-standard C funtion replacements I placed in darwinutils.[hc].
I think that almost all of the modifications can be put in a own file. Exception would be isnumber function in tools and of course includes. Function with 'isnumber' name is already defined* in Darwin, so that name needs a change if Darwin compatibility without code changes is desired. Maybe this could be made in developer version at some point.
*) I should check what the definition for that really is. I got error that it wasn't compatible, so I just changed the name.
On 29.1.2007 19:23, "Martin Wache" M.Wache@gmx.net wrote:
Hi Martin,
Well this is good news as I was hopingd that someone could continue developing this as personally I don't have too much spare time. I started this just to test what is required to get VDR even compiled. Because it wasn't so much, I continued also with few plugins to get also video out and used Xineliboutput for it.
If there's any use of my patches please use them. I can provide at least test support for Mac-VDR.
I tried the softdevice plugin but it failed on shmget. I have larger shm values in /etc/rc than in the ReadMe, any ideas what could be the problem:
Vdr start output: [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3349248) cShmVideoOut: Got ctl_shmid 65536 shm ctl! [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] No alsa support compiled in. Using dummy-audio [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder
Client start output: cQuartVideoOut [vout-quartz] WindowEventHandler result 0 [vout-quartz] resized.. dsyslog:[VideoOut]: 720x536 [0,0 720x536] -> 360x288 [0,12 360x263] [vout-quartz] result 0 init video engine [vout-quartz] initgl Finished Quartz constructor ctl_shmid error in shmget! Check if the Vdr is running with the softdevice and the option "-vo shm:"! [vout-quartz] cQuartzVideoOut destructor [vout-quartz] RmShmMemory pic 655361 osd 655362 dsyslog:[VideoOut]: Good bye
Mac OS X 10.4.8 running on 15" MacBook Pro 2.33 GHz Core 2 Duo, 2GB RAM, 160GB HDD
Tero Siironen schrieb:
Unfortunately we also don't have lots of spare time, that is why the developing has stalled in the past time. On the other hand, we are almost there... We can watch live-tv, record, playback and also time-shifting works. But there are still things to be done, it is not as stable as it should be, and the build process is difficult and almost completely undocumented (especially for the mminput-plugin)
Yes, that should be fine...
Hmm, you can check with ipcs if the shared memory block has properly been created, has the correct Id (it should be the one in shm-common.h), and has the correct size. If you end the vdr, the block won't be deleted, so you may try to delete the shared memory block and let vdr create a new one. Did you make sure that you have a clean build (make clean doesn't delete all the files...)?
Bye, Martin
On 30.1.2007 00:58, "Martin Wache" M.Wache@gmx.net wrote:
Ok, there obviously was some files left when compiling because now when I'm trying to compile from clean environment I get:
Plugin softdevice: g++ -O2 -g -Wall -fPIC -Woverloaded-virtual -c -DHAVE_CONFIG -DPOWERPC -DNO_LINUX -DPLUGIN_NAME_I18N='"softdevice"' -D_GNU_SOURCE -DPLUGINLIBDIR='"./PLUGINS/lib"' -DMACOSAO_SUPPORT -DQUARTZ_SUPPORT -DSHM_SUPPORT -I../../../include -I../../../../DVB/include -I/sw/include -I/sw/include/ffmpeg softdevice.c /sw/include/ffmpeg/avformat.h:243: warning: 'AVFrac' is deprecated (declared at /sw/include/ffmpeg/avformat.h:94) /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.fram ework/Headers/MachineExceptions.h:245: error: declaration does not declare anything make[1]: *** [softdevice.o] Error 1
However, before I cleaned it I tried ipcs with some debug. Key was correct, but for some reason shmget returned always -1. I hardcoded the correct value to ctl_shmid (from softdevice's output while vdr was running) and got the window show up with green picture, but softdevice didn't react to that.
I then installed same setup to my iBook G4 and managed to get picture and sound but not able to control the window or vdr. Is this how it should be at the moment?
Tero Siironen schrieb:
Hmm, no clue what's wrong...
Did you start the client like it is described in the ReadMe? From inside of the McVdrClient.app folder? For some reason Quartz application needs the context of this folder to run correctly. I don't know if there is a workaround...
Bye,
Martin
On 30.1.2007 21:39, "Martin Wache" M.Wache@gmx.net wrote:
Argh, my mistake. It is working now. But the problem now lies on remote setup. Every keypress is detected as same key and therefore remote cannot be setup. The window with McVdrClient shows different keycodes, but vdr doesn't detect it. Same thing if keyboard is tried, so something is wrong, but I cannot find out what it is.
Tero Siironen schrieb:
This somehow sounds familiar... but I can't remember the circumstances. But it should be simple to add a few printfs to narrow the problem down. The key events are recieved by KeyEventHandler() in video-quartz.c (and there the printouts are written, note that only the first value is actually used). quartzRemote->PutKey() is the one in McVdrClient.c, it should write the keycode into the shared memory control block and signal the softdevice.
Forget it - I think I know now whats wrong, there is a patch missing in your vdr. See remote.c, if I remember correctly the format string is not correctly interpreted by the printf. Here is my cRemote::Put() method:
bool cRemote::Put(uint64 Code, bool Repeat, bool Release) { char buffer[32]; snprintf(buffer, sizeof(buffer), "%0llX", Code); //snprintf(buffer, sizeof(buffer), "%016LX", Code); return Put(buffer, Repeat, Release); }
Bye, Martin
On 30.1.2007 23:02, "Martin Wache" M.Wache@gmx.net wrote:
Thank you, that was it. Next thing I'll try to do is get it to run on MacBook Pro also.
Hi Tero,
Tero Siironen schrieb:
Thank you, that was it. Next thing I'll try to do is get it to run on MacBook Pro also.
Great! Keep us up to date on your progress ;-) I'm not sure if the configure script correctly detects the Intel Mac, so you may have to modify the configure to get MMX acceleration. Also, in audio-macos.c I've set the audio format to
inDesc.mFormatFlags |= kAudioFormatFlagIsBigEndian;
I would guess that you have to change that on Intel processors, but I can't try it. And there may be problems with the OSD colors, but you will see ;-)
Bye, Martin
-
Klaus Schmidinger -
Martin Wache -
Rob Davis -
Tero Siironen