Steffen Barszus wrote:
Is it? If they really used DirectFB as hardware abstraction layer there is no real reason why it should be. And if it is then it's a good reason to spend some time to change this;)Am Mittwoch, 19. November 2003 02:19 schrieben Sie:Steffen Barszus wrote:Am Dienstag, 18. November 2003 23:16 schrieben Sie:Hi Klaus, don't get me wrong, I appreciate your work. But I'm pretty angry about the situation that VDR is (I don't care whether willingly or not) endorsing these troublesome and expensive beasts since years. We have now at least since about two or three years cheap and good alternatives and there have been efforts to write DirectFB and Xine-backends for VDR but they never found their way into the mainstream source which means nothing else than that they are born dead.Why should they ? The plugin you speak about exists since some months (weeks). In the time i was on the vdr list the xine plugin is the first real approach on having a software display and i have never seen a patch for 1.0.x that tried that. Patches were really successfull even if they were not in main vdr (think of AIO, who is running vdr w/o it ? I guess 50% using it). Further the "solution" you think of has some problems.I was mainly thinking of df-gp, the first VDR patch I know that worked on the frambuffer (http://df-gp.sourceforge.net/). The first NEWS entry is now about 19 months old.
I have seen that too. But this project was limited and is still limited to Matrox cards.
I have tried to get a good supported matrox card to no avail (a matrox g400).Both Xine and MPlayer are somewhat oversized as pure decoders. They are more multimedia player centers than generic decoder libraries like libmpeg2, libmpeg3 and ffmpeg.
It may be a good solution, but it is not practicable in reality.
If it would work with an ati rage 128 or the like i guess it would had become a lot more popular. Now the
Xine-plugin is a lot more flexible than df-gp.