2007/1/29, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:

Martin Wache wrote:

...

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.

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.

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.

Tero Siironen schrieb:

On 29.1.2007 19:23, "Martin Wache" M.Wache@gmx.net wrote:

...

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

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.

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)

...

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.

I tried the softdevice plugin but it failed on shmget. I have larger shm values in /etc/rc than in the ReadMe,

Yes, that should be fine...

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

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

Tero Siironen schrieb:

On 30.1.2007 00:58, "Martin Wache" M.Wache@gmx.net wrote:

...

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

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

Hmm, no clue what's wrong...

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?

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

Tero Siironen schrieb:

On 30.1.2007 21:39, "Martin Wache" M.Wache@gmx.net wrote:

...

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

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.

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

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