[vdr] Re: DXR3 support patch for vdr-1.1.5

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Andreas Schultz wrote:
> 
> ...
> > I've started with the players/receivers and just haven't done the
> > devices yet. What upset me about your initial posting was the way
> > you brought this up. To me it sounded like "Well, look what Klaus did:
> > it's still unusable!". Making devices plugin-aware simply wasn't what
> > I intended to do in this step. Until recently the main problem was with
> > players, so I decided to make _those_ plugin aware first. You yourself have
> > been focused on the DVD player, so I thought making player plugins first
> > would support your work.
> 
> it does, but i can already see the points where things will almost certainly
> have to be changed in my code once you make the devices modular. The current
> plugin API still exposes to much of vdr internals to plugins and it
> shouldn't.

A absolutely agree that the current implementation of cDevice is not yet
abtract enough. I know that and will change that later.

However, I don't really see how a more abstract cDevice would cause existing
player implementations to be changed (at least not radically). Can you give
just one example where this would happen? Maybe I'm missing something important
here.

> > I can't help it, but it's my way of doing things to do one step after the
> > other, and to make one thing work before starting a new one. As you may
> > have noticed, version 1.1.5 still lacks Dolby Digital support. This will
> > also be made plugin aware, and I want to incorporate support for live Dolby
> > Digital audio as well. Once these steps are completed, I will release this
> > as version 1.2.0 - which is then basicly the status of version 1.0.0, with
> > several features made "plugin aware".
> 
> Are you sure, wouldn't it be better to start with the devices and the
> concentrate on DD?
> With DD you will most certainly want to support external decoders again and
> hopefully include internal direct support of OSS/ALSA sound devices. Support
> for both can IMHO best be implemented within the device classes, provided
> that the framework is powerfull and flexible enough.

Just as you have already used the cPlayr class to implement your own player,
you will be able to derive from a (yet to be implemented) cAudio class to
implement your own Dolby Digital audio output. Live DD will, of course, be
done by the cDevice, but it will use the very same cAudio derived objects
as normal replay.

> > After that I will make the devices plugin aware. This isn't something you
> 
> I'm not talking about plugin aware devices. That will certanly be the ultimate
> goal, but in the meantime, i would settle for a radical restruturing of the
> device layer.

With devices it will be just like it has been with players: the current cDevice
will later become an abstract base class, and the existing implementation will
be moved into a cDvbDevice. Then a plugin can derive from cDevice and implement
the necessary functions to access the particular hardware.

> > just throw in with a few lines of code. You have to allow devices that can
> > record but not replay (and vice versa), and you have to completely separate
> > the OSD from the actual device, because a particular device might not be
> > able to display an OSD, or may need a completely different implementation.
> > Part of this has already been prepared in the current developer version.
> 
> As you said, one step at a time. I would be more than willing to start on the
> cDevice issues when i could be sure that at least parts of it will be
> accepted ....

Well, I don't know how you would do these things, so I'm afraid I can't give
you a guarantee that I will adopt it that way. I do have certain ideas about
how I plan to do this, but as I said, this will not happen until the current
work is finished.

> I could also throw together a "janitor" list of small things that should/could
> be changed thoughout vdr.

Fell free to do so.

> > BTW: I've tested your latest DVD player plugin with "X-Men" and
> > "Raumpatrouille". In one case I had a complete program crash, and on
> > several occasions the menu didn't work as expected. Are you interested in
> > fixing this? I can lend these DVDs to you if it helps.
> 
> I definetly am.

Will you be present at the meeting in Ismaning on August 17?
If so, I could bring them there.

> > Oh, one more thing: I'd really appreciate if the DVD player would react on
> > the default "up/down/left/right" keys when in menu mode. I never really
> > understood why you had to use the number keys for this...
> 
> Because the number keys are more convenient on my remote control and because
> of:
> 
>     case kUp:      Play(); break;
>     case kDown:    Pause(); break;
>     case kLeft:    Backward(); break;
>     case kRight:   Forward(); break;
> 
> Menus on most DVD's are also just video/audio sequences played over and over
> again. To be able to have a double meaning of those keys, i would have to use
> the "User Operation Flags" which then would not allow you anymore to skip
> over those stupid intro copyright messages.

So basicly what you're saying is that the DVD player doesn't "know" whether
it is in menu mode or play mode? That's too bad...

Anyway, although I haven't done too much DVD playing yet, so far I never
needed the play/pause/forward/back function of these keys. I rather mainly
navigated through the menus, and there I found it very complicated to use
the number keys. Wouldn't it have been better to use the up/down/left/right
keys for navigating, and assign the play/pause/forward/back functions to the
number keys? I know, using the number keys is only a temporary workaround
until VDR knows more key definitions. But the first thing a user is confronted
with when playing a DVD is typically the DVD menu - and IMHO one would expect
the usual keys to navigate through this.

Just a thought: couldn't the DVD player detect the fact that it has the OSD open
in order to switch between menu navigating mode and play mode?

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________