In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
On 05/01/2009, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
Yes
http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC
On 05/01/2009, Theunis Potgieter theunis.potgieter@gmail.com wrote:
On 05/01/2009, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
Yes
http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC
http://en.wikipedia.org/wiki/Sampling_frequency
Please do not always _assume_ that it is actually PAL or NTSC, since PAL or NTSC defines colour encoding, but the most of the time the usual frame rates are associated with the colour encoding. However like I've stated before nvidia on their newer drivers output PAL on 60Hz (on the tv-out of the card), not even 59.94006Hz, or 50Hz like PAL is supposed to be for interlaced. The older CRT TVs (interlaced monitors) expect PAL to run 50Hz. You can confirm this with xvidtune.
On 05.01.2009 11:57, Theunis Potgieter wrote:
On 05/01/2009, Theunis Potgieter theunis.potgieter@gmail.com wrote:
On 05/01/2009, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
Yes
http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC
http://en.wikipedia.org/wiki/Sampling_frequency
Please do not always _assume_ that it is actually PAL or NTSC, since PAL or NTSC defines colour encoding, but the most of the time the usual frame rates are associated with the colour encoding. However like I've stated before nvidia on their newer drivers output PAL on 60Hz (on the tv-out of the card), not even 59.94006Hz, or 50Hz like PAL is supposed to be for interlaced. The older CRT TVs (interlaced monitors) expect PAL to run 50Hz. You can confirm this with xvidtune.
Detecting the frame rate is done by looking at the PTS values, so it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
-------------------------------------------------------- #include <math.h> #include <stdio.h>
int main(void) { double FramesPerSecond = double(90000) / 3003; //FramesPerSecond = 25; for (int Index = 0; Index < 10000; Index++) { double Seconds; int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; int s = int(Seconds); int m = s / 60 % 60; int h = s / 3600; s %= 60; printf("%3d ", Index); printf("%15.9f ", Index / FramesPerSecond); printf("%d:%02d:%02d.%02d", h, m, s, f); if (f > 30) printf(" *"); printf("\n"); } } --------------------------------------------------------
... sometimes results in a 31st frame:
9978 332.932600000 0:05:32.29 9979 332.965966667 0:05:32.30 9980 332.999333333 0:05:32.31 * 9981 333.032700000 0:05:33.02 9982 333.066066667 0:05:33.03
Any ideas how to fix this?
Klaus
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include <math.h> #include <stdio.h>
int main(void) { double FramesPerSecond = double(90000) / 3003; //FramesPerSecond = 25; for (int Index = 0; Index < 10000; Index++) { double Seconds; int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; int s = int(Seconds); int m = s / 60 % 60; int h = s / 3600; s %= 60; printf("%3d ", Index); printf("%15.9f ", Index / FramesPerSecond); printf("%d:%02d:%02d.%02d", h, m, s, f); if (f > 30) printf(" *"); printf("\n"); } }
... sometimes results in a 31st frame:
9978 332.932600000 0:05:32.29 9979 332.965966667 0:05:32.30 9980 332.999333333 0:05:32.31 * 9981 333.032700000 0:05:33.02 9982 333.066066667 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; + int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond + 0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the original and 1019 in the fixed version)
artur
On 05.01.2009 13:31, Artur Skawina wrote:
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include <math.h> #include <stdio.h>
int main(void) { double FramesPerSecond = double(90000) / 3003; //FramesPerSecond = 25; for (int Index = 0; Index < 10000; Index++) { double Seconds; int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; int s = int(Seconds); int m = s / 60 % 60; int h = s / 3600; s %= 60; printf("%3d ", Index); printf("%15.9f ", Index / FramesPerSecond); printf("%d:%02d:%02d.%02d", h, m, s, f); if (f > 30) printf(" *"); printf("\n"); } }
... sometimes results in a 31st frame:
9978 332.932600000 0:05:32.29 9979 332.965966667 0:05:32.30 9980 332.999333333 0:05:32.31 * 9981 333.032700000 0:05:33.02 9982 333.066066667 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1;
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond + 0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the original and 1019 in the fixed version)
I'm afraid this isn't feasible. The '+1' is done to make the first frame (at Index 0) have number '1'. With your change it would be numbered '0'.
Klaus
Klaus Schmidinger wrote:
On 05.01.2009 13:31, Artur Skawina wrote:
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include <math.h> #include <stdio.h>
int main(void) { double FramesPerSecond = double(90000) / 3003; //FramesPerSecond = 25; for (int Index = 0; Index < 10000; Index++) { double Seconds; int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; int s = int(Seconds); int m = s / 60 % 60; int h = s / 3600; s %= 60; printf("%3d ", Index); printf("%15.9f ", Index / FramesPerSecond); printf("%d:%02d:%02d.%02d", h, m, s, f); if (f > 30) printf(" *"); printf("\n"); } }
... sometimes results in a 31st frame:
9978 332.932600000 0:05:32.29 9979 332.965966667 0:05:32.30 9980 332.999333333 0:05:32.31 * 9981 333.032700000 0:05:33.02 9982 333.066066667 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1;
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond + 0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the original and 1019 in the fixed version)
I'm afraid this isn't feasible. The '+1' is done to make the first frame (at Index 0) have number '1'. With your change it would be numbered '0'.
Klaus
no, try it :)
and you can also drop the round call:
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; + int f = modf((Index + 0.5) / FramesPerSecond, &Seconds) * FramesPerSecond + 1;
which will move the 'missing' frames to the same locations as in the original.
artur
On 05.01.2009 13:49, Artur Skawina wrote:
Klaus Schmidinger wrote:
On 05.01.2009 13:31, Artur Skawina wrote:
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include <math.h> #include <stdio.h>
int main(void) { double FramesPerSecond = double(90000) / 3003; //FramesPerSecond = 25; for (int Index = 0; Index < 10000; Index++) { double Seconds; int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1; int s = int(Seconds); int m = s / 60 % 60; int h = s / 3600; s %= 60; printf("%3d ", Index); printf("%15.9f ", Index / FramesPerSecond); printf("%d:%02d:%02d.%02d", h, m, s, f); if (f > 30) printf(" *"); printf("\n"); } }
... sometimes results in a 31st frame:
9978 332.932600000 0:05:32.29 9979 332.965966667 0:05:32.30 9980 332.999333333 0:05:32.31 * 9981 333.032700000 0:05:33.02 9982 333.066066667 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1;
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond + 0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the original and 1019 in the fixed version)
I'm afraid this isn't feasible. The '+1' is done to make the first frame (at Index 0) have number '1'. With your change it would be numbered '0'.
Klaus
no, try it :)
I did - but I just replaced 1 with 0.5 and totally missed that you have also changed the bracketing - sorry.
and you can also drop the round call:
- int f = round(modf(Index / FramesPerSecond, &Seconds) * FramesPerSecond) + 1;
- int f = modf((Index + 0.5) / FramesPerSecond, &Seconds) * FramesPerSecond + 1;
which will move the 'missing' frames to the same locations as in the original.
This looks good!
Thanks. Klaus
On Mon, 5 Jan 2009 12:57:41 +0200 "Theunis Potgieter" theunis.potgieter@gmail.com wrote:
Please do not always _assume_ that it is actually PAL or NTSC, since PAL or NTSC defines colour encoding, but the most of the time the usual frame rates are associated with the colour encoding. However like I've stated before nvidia on their newer drivers output PAL on 60Hz (on the tv-out of the card), not even 59.94006Hz, or 50Hz like PAL is supposed to be for interlaced. The older CRT TVs (interlaced monitors) expect PAL to run 50Hz. You can confirm this with xvidtune.
I expect you've already checked this, but have you set the "TVStandard" option in xorg.conf?
Also, it may not be treating the TV as the primary display but locking the frequency to whatever it thinks is the primary display, and if it's an LCD, by default the Nvidia driver always outputs the maximum resolution, scaling the configure resolution to fill it, unless you add:
Option "FlatPanelProperties" "Scaling = Native"
And xrandr will report refresh rates incorrectly unless you add:
Option "DynamicTwinView" "false"
Partly question and partly proposal. Maybe this is not VDR related but e.g. xineliboutput etc. related.
I'm not an expert on satellite systems but I'd assume that there are different frame rates in satellite systems available (shall be compared to cable and terresterial as well). Instead of doing pull-down/pull-up "conversions" it would be nice to playback according to the framerate of the material. This should be an option as it is fully dependant on the output and display devices whether they support this feature or not.
The same applies also to mplayer-plugin.
Would this be possible to implement?
Br, Pasi
On Mon, 05 Jan 2009 20:48:57 +0200 Pasi Juppo Pasi@Juppo.fi wrote:
Partly question and partly proposal. Maybe this is not VDR related but e.g. xineliboutput etc. related.
I'm not an expert on satellite systems but I'd assume that there are different frame rates in satellite systems available (shall be compared to cable and terresterial as well). Instead of doing pull-down/pull-up "conversions" it would be nice to playback according to the framerate of the material. This should be an option as it is fully dependant on the output and display devices whether they support this feature or not.
The same applies also to mplayer-plugin.
Would this be possible to implement?
Yes, boxstar does this, but it's a bit limited by its current reliance on external players. DirectFB players can set the screen mode, while in X boxstar sets it first with xrandr. Boxstar has to be able to use mplayer -identify on the stream first to determine the frame rate and it can't change it midstream. Boxstar can't tell the frame rate of what vdr-sxfe or whatever is using, so it has to use an option. Luckily most people receive transmissions all in the same frame rate even if they watch foreign DVDs or downloaded videos, so boxstar can cope with this.
Tony Houghton wrote:
On Mon, 05 Jan 2009 20:48:57 +0200 Pasi Juppo Pasi@Juppo.fi wrote:
Partly question and partly proposal. Maybe this is not VDR related but e.g. xineliboutput etc. related.
I'm not an expert on satellite systems but I'd assume that there are different frame rates in satellite systems available (shall be compared to cable and terresterial as well). Instead of doing pull-down/pull-up "conversions" it would be nice to playback according to the framerate of the material. This should be an option as it is fully dependant on the output and display devices whether they support this feature or not.
The same applies also to mplayer-plugin.
Would this be possible to implement?
Yes, boxstar does this, but it's a bit limited by its current reliance on external players. DirectFB players can set the screen mode, while in X boxstar sets it first with xrandr. Boxstar has to be able to use mplayer -identify on the stream first to determine the frame rate and it can't change it midstream. Boxstar can't tell the frame rate of what vdr-sxfe or whatever is using, so it has to use an option. Luckily most people receive transmissions all in the same frame rate even if they watch foreign DVDs or downloaded videos, so boxstar can cope with this.
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Br, Pasi
On Tue, 06 Jan 2009 09:12:04 +0200 Pasi Juppo Pasi@Juppo.fi wrote:
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day.
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day.
At least for now it seems to use vdr as a backend. Has anybody tested it.
Mika
On Tue, 6 Jan 2009 16:47:35 +0200 (EET) Mika Laitio lamikr@pilppa.org wrote:
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day.
At least for now it seems to use vdr as a backend. Has anybody tested it.
I should let on that I'm the developer and I've been using it a lot. I started writing it back before VDR had a media player, so some sort of frontend was really needed; even now I think boxstar has a lot of advantages over VDR's media player, but VDR, especially with the xineliboutput plugin, did improve a lot so I wasn't motivated to develop boxstar's own DVB support.
Now I've got a DVB-S card and a DVB-T card together, VDR's channels management just isn't good enough, so because of all sorts of other niggles and because I don't like C++ enough to make big changes to VDR I want to press ahead again with boxstar's DVB support.
Tony Houghton wrote:
On Tue, 6 Jan 2009 16:47:35 +0200 (EET) Mika Laitio lamikr@pilppa.org wrote:
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day.
At least for now it seems to use vdr as a backend. Has anybody tested it.
I should let on that I'm the developer and I've been using it a lot. I started writing it back before VDR had a media player, so some sort of frontend was really needed; even now I think boxstar has a lot of advantages over VDR's media player, but VDR, especially with the xineliboutput plugin, did improve a lot so I wasn't motivated to develop boxstar's own DVB support.
Now I've got a DVB-S card and a DVB-T card together, VDR's channels management just isn't good enough, so because of all sorts of other niggles and because I don't like C++ enough to make big changes to VDR I want to press ahead again with boxstar's DVB support.
Few comments/suggestions to boxstar: -roadmap: boxtar itself does not seem to show EPG unless it is incorporated into manage timers and recordings. Anyhow, I really hope you implement TVOnScreen type of EPG viewer and similar EPG search -plugin for automated timers. -OSD: not much is said about that but I hope it will scale according to the resolution and be full-coloured. -I assume that boxstar is developed to be full client-server solution which allows multiple fully independent clients. What would be nice addition because of the today's motherboards is that bostar-daemon could be run on multiple PCs for single system. This would allow to use cheap mATX boards that have one or two PCI slots to build a massive (?) system of e.g. 6 DVB cards. Some kind of master server might be needed for centralized recordings, timers etc.
Br, Pasi
On Tue, 06 Jan 2009 20:47:14 +0200 Pasi Juppo Pasi@Juppo.fi wrote:
Few comments/suggestions to boxstar: -roadmap: boxtar itself does not seem to show EPG unless it is incorporated into manage timers and recordings. Anyhow, I really hope you implement TVOnScreen type of EPG viewer and similar EPG search
Yes, I want to be able to present the EPG in at least two ways, both in boxstar's frontend and in a web frontend. One way is like many TVs and STBs and vdr-admin's "Timeline" with the channels vertically on the left and the programmes in horizontal strips, the other is a vertical list of programmes for a single channel like VDR's "Schedule" and vdr-admin's "Channels" view. I do want to provide EPG searching too although I've never got round to enabling that plugin in VDR.
-plugin for automated timers.
Do you mean automatically record programmes with the same title? That's a feature I'd like to have too, and features I'd like have a good chance of making it in :).
I'm not really thinking in terms of "plugins" though, one of the things I dislike about VDR is having to find and compile plugins separately apart from a few core ones available in Debian. If and when it gets popular enough for people to want to add their own features I'll probably have to provide a mechanism to extend boxstar without the core code having to be altered to accommodate each extension, but it'll be easier in python than C++, and I'll encourage them to be hosted on the main boxstar site or at least have a CMS where people can add links etc.
-OSD: not much is said about that but I hope it will scale according to the resolution and be full-coloured.
Yes, once "hvid" is fully developed. In the meantime video playing will stay mainly based around mplayer so the OSD will be limited to things like showing the channel number when the user changes it.
-I assume that boxstar is developed to be full client-server solution which allows multiple fully independent clients.
Yes.
What would be nice addition because of the today's motherboards is that bostar-daemon could be run on multiple PCs for single system. This would allow to use cheap mATX boards that have one or two PCI slots to build a massive (?) system of e.g. 6 DVB cards. Some kind of master server might be needed for centralized recordings, timers etc.
I hadn't really thought about going that far. The basic principle isn't too difficult, but it makes configuration more difficult, especially as one of the problems I want to solve is being able to configure boxstar to know the relationships between channels such as "BBC ONE" on DVB-T being equivalent to "BBC 1 South" (in my case) on DVB-S so that if I want to set overlapping timers I can just choose "BBC 1" and boxstar will automatically choose whichever card isn't already committed to another timer - like VDR can already do if both cards are the same type. Obviously it will be possible to assign priorities to cards. Managing these equivalencies and priorities across more than one PC could get very complicated.
Hopefully Linux will support PCI-E cards with multiple tuners soon, and with PCI being phased out and assuming you can plug a PCI-E x1 card into a x16 slot while using onboard graphics, it should eventually be possible to have 4 such cards in one PC. But then you'd probably need an array of 10k rpm SAS HDs to keep up with recording from them all!
Tony Houghton wrote:
On Tue, 06 Jan 2009 09:12:04 +0200 Pasi Juppo Pasi@Juppo.fi wrote:
I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it.
Do you mean ambitious? Yes, it is going to be a big challenge, but hopefully it'll get there one day.
Yes, that's what I meant but wrote something else :-)
I sure wish the best for the developer(s) - it surely is not a small task.
Br, Pasi
On Mon, 5 Jan 2009, Pasi Juppo wrote:
Would this be possible to implement?
There's already a modeswitching patch using xrandr for vdr-sxfe available on VDR-Portal. However, it lacks support for interpreting frame rate of source video, but it could be added...
BR, -- rofa
Rolf Ahrenberg wrote:
On Mon, 5 Jan 2009, Pasi Juppo wrote:
Would this be possible to implement?
There's already a modeswitching patch using xrandr for vdr-sxfe available on VDR-Portal. However, it lacks support for interpreting frame rate of source video, but it could be added...
Half way there already! Hopefully someone can add the support to interprete the frame rate of the source. This would be quite unique feature to my understanding.
Br, Pasi
On 05/01/2009, Rolf Ahrenberg rahrenbe@cc.hut.fi wrote:
On Mon, 5 Jan 2009, Pasi Juppo wrote:
Would this be possible to implement?
There's already a modeswitching patch using xrandr for vdr-sxfe available on VDR-Portal. However, it lacks support for interpreting frame rate of source video, but it could be added...
BR,
-- rofa
Could you please provide a url to that information? I'm assuming it is in German.
Klaus Schmidinger wrote:
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
The last paragraph under "Color Encoding" explains the "odd" number for the NTSC frame rate: http://en.wikipedia.org/wiki/NTSC#Color_encoding
While taking care of the correct display of time for NTSC and PAL, please also adjust the OSD for PAL and NTSC. Right now it takes a plugin called videosystem, which does not seem to be maintained anymore to alter the size of the OSD when playing back NTSC video. Without this plugin parts of the OSD will be "out of bounds".
André
Maybe these links will help:
http://cnyack.homestead.com/files/modulation/ntsc_sig.htm http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC http://www.afterdawn.com/glossary/terms/ntsc.cfm http://www.fixya.com/support/t174610-ntsc_frame_rate_29_97_hz
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Monday, January 05, 2009 3:31 AM Subject: [vdr] Frames per second PAL vs. NTSC
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 "ticks" of 1/90000s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that "odd"? I thought it would be an even 30 fps.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
André Weidemann -
Artur Skawina -
Artur Skawina -
Jukka Tastula -
Klaus Schmidinger -
Mika Laitio -
Pasi Juppo -
Rolf Ahrenberg -
Theunis Potgieter -
Timothy D. Lenz -
Tony Houghton