Re: [vdr] [Patch] Make RGYB buttons customizeable
On Fri, 1 Apr 2011, VDR User wrote: Ignoring remotes that don't follow the RGYB scheme doesn't make them any less 'tv oriented' or go away. I can't imagine it's much of a leap to make the colored button position customizable and is probably something that's better to have then not. What good argument against allowing the user to customize the layout according to their actual remote button layout could there be? None that I can think of. I'd guess Klaus will consider any patches submitted to him which don't cause problems. Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core. The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB standard that documents the teletext too. IMO, you really should switch the OSD button colors in skin plugins instead of patching the core VDR. There will be some glitches with learning the remotes, but these can be fixed with some extra documentation (Press 'Red/leftmost color' button). These remotes with "wrong" color button orders are really a small minority here mainly targeted to some odd mediacenters or PS3 - at least here in the northern Europe. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On 02.04.2011 11:33, Rolf Ahrenberg wrote: On Fri, 1 Apr 2011, VDR User wrote: Ignoring remotes that don't follow the RGYB scheme doesn't make them any less 'tv oriented' or go away. I can't imagine it's much of a leap to make the colored button position customizable and is probably something that's better to have then not. What good argument against allowing the user to customize the layout according to their actual remote button layout could there be? None that I can think of. I'd guess Klaus will consider any patches submitted to him which don't cause problems. Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core. The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB standard that documents the teletext too. IMO, you really should switch the OSD button colors in skin plugins instead of patching the core VDR. There will be some glitches with learning the remotes, but these can be fixed with some extra documentation (Press 'Red/leftmost color' button). These remotes with "wrong" color button orders are really a small minority here mainly targeted to some odd mediacenters or PS3 - at least here in the northern Europe. I could imagine accepting a patch that centralizes handling the sequence in which the color buttons are displayed, and offers a standard interface to skin plugins that allows them to arrange the color buttons accordingly. What I don't want to change is the actual functionality of the color buttons, meaning, for instance, the red button will always have the same functionality, no matter what sequence the remote control uses. I haven't looked into the original patch yet, so I can't say whether it only handles the display sequence or also messes with the functionality. At any rate, a patch that changes the functionality is unacceptable for me. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
> Regardless, users always have the option to patch the feature in if it > doesn't become a part of VDR's core. Here we go! Provide a patch, users can use or not w/o assuming to change vdr-core. Like the majority of users, I do use remotes following kls's VDR standard defined a century ago. I don't want to bothered w/ configurable colored keys, it can be just another cause for malfunctions, mere you guys are not willing to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high expectation, because you also buy DVB devices which are compatible w/ VDR ... If remotes would be some very expensive devices, I may follow your arguments, but you guys do often buy the cheapest you can get and expect that core VDR will changed to be usable with these sometimes pulpy devices, wereas also compatible devices are available for the same price ... Regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
Am 02.04.2011 12:23, schrieb Klaus Schmidinger:
> I could imagine accepting a patch that centralizes handling
> the sequence in which the color buttons are displayed, and
> offers a standard interface to skin plugins that allows
> them to arrange the color buttons accordingly.
>
> What I don't want to change is the actual functionality
> of the color buttons, meaning, for instance, the red button
> will always have the same functionality, no matter what sequence the
> remote control uses.
There is no simple solution to this. The problem is, that in some cases
the meaning of the button is linked to their color ('red' means
recording), and in some cases the meaning is linked to the placement
(button 2 for backwards, 3 for forward).
Making the color <-> placement relation configurable will automatically
break one or the other. The only 'clean' solution would be to decide by
situation whether key assignment should be by-placement or by-color. So
for example, in replay the assignment is BUTTON_1=jump, BUTTON_2=skip
back, BUTTON_3=skip fwd, BUTTON_4=stop, while in EPG view, the
assignment is BUTTON_RED=record, BUTTON_GREEN=now, BUTTON_YELLOW=next,
BUTTON_BLUE=switch.
Generally, the goal is to match the color order in the OSD with the
order on the remote, so the skins need to know the ordering. VDR
internally, the keys are called kRed, kGreen, kYellow, kBlue, their
meaning is obviously color related. So as long as the red button stays
the red button, it doesn't matter whether the skin displays the red
color button label on the left or right.
The most difficult question is, how to handle buttons by placement. A
eKeys key cannot be kRed and kButton1 at the same time. Any query
interface would break all the nice switch(Key) statements. (case
getColorOfButton1(): ... is not a constant.)
My suggestion would be to add pseudo keys kButton1..kButton4, that are
only transformed on demand:
switch (Key) {
case kRed:
switch (MAP_COLOR_KEYS_TO_PLACEMENT(key)) {
case kButton1: ...
Also, there should be a wrapper for SetHelp() to set the button labels
by placement, so you either call SetHelp("Red", "Green", "Yellow",
"Blue"), or SetHelpByPlacement("Left", "Mid-Left", "Mid-Right", "Right").
Finally, some documentation will need rewrites, from green/yellow to
mid-left, mid-right color button to skip fwd/bwd.
All in all a lot of changes to do it properly...
Cheers,
Udo
PS: My remote has the color order red, green, yellow, blue, purple. ;)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, 2 Apr 2011 12:33:58 +0300 (EEST) Rolf Ahrenberg wrote: > The RGYB color enumeration is defined in the video teletext standard and > every TV/STB set implementing the teletext feature DOES use the > mentioned color button order. I guess the teletext is used mainly in > Europe, so there might be different conventions elsewhere, but the VDR > is a STB for DVB standard that documents the teletext too. > > IMO, you really should switch the OSD button colors in skin plugins > instead of patching the core VDR. There will be some glitches with > learning the remotes, but these can be fixed with some extra > documentation (Press 'Red/leftmost color' button). These remotes with > "wrong" color button orders are really a small minority here mainly > targeted to some odd mediacenters or PS3 - at least here in the northern > Europe. It isn't true that only very obscure and trashy remotes have the buttons in the wrong order. I've got a Sony TV where the colours are arranged in a sort of cross layout with green above blue and red and yellow at the sides. It's a good quality remote that I think was used with a number of different models of Sony TV set and it was definitely designed to support teletext. I've got another remote with the wrong order which came with a KWorld DVB card bought from Maplins, a major high street electronics chain. That remote isn't really usable with VDR anyway though, because the colours are also play, pause, stop and record. I suppose they didn't think that people would use teletext or MHEG while watching a recording, and there is no standard for the way that VDR uses the colours. I can't use the remote that came with my other card (Hauppauge) because the current kernel/DVB drivers aren't compatible with it (for at least the 2nd time in hstory). So I'm making do with a wireless keyboard until that's fixed. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, Apr 2, 2011 at 4:40 AM, fnu wrote: >> Regardless, users always have the option to patch the feature in if it >> doesn't become a part of VDR's core. > > Here we go! Provide a patch, users can use or not w/o assuming to change > vdr-core. > > Like the majority of users, I do use remotes following kls's VDR standard > defined a century ago. I don't want to bothered w/ configurable colored keys, > it can be just another cause for malfunctions, mere you guys are not willing > to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to > high expectation, because you also buy DVB devices which are compatible w/ > VDR ... > > If remotes would be some very expensive devices, I may follow your arguments, > but you guys do often buy the cheapest you can get and expect that core VDR > will changed to be usable with these sometimes pulpy devices, wereas also > compatible devices are available for the same price ... You aren't doing yourself any favors by making all these silly assumptions. I mean this in the nicest way possible -- everything quoted above is complete nonsense. Nobody is ever giong to take you seriously if you keep posting such rubbish. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, Apr 2, 2011 at 2:33 AM, Rolf Ahrenberg wrote: > The RGYB color enumeration is defined in the video teletext standard and > every TV/STB set implementing the teletext feature DOES use the mentioned > color button order. I guess the teletext is used mainly in Europe, so there > might be different conventions elsewhere, but the VDR is a STB for DVB > standard that documents the teletext too. I have two top end tv's, one Panasonic, one Sony. Both support teletext, neither have the color button scheme as RGYB. I would guess it's as you mentioned, maybe that scheme is commonly used in Europe but it's simply not true that RGYB is some standard used across the globe with only cheap obscure remotes not conforming to it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings
On 02.04.2011 02:38, Joerg Riechardt wrote:
Problem solved with this patch:
--- dvbplayer.c.orig 2010-03-07 15:24:26.0 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
@@ -320,7 +320,7 @@
if (nonBlockingFileReader)
nonBlockingFileReader->Clear();
if (!firstPacket) // don't set the readIndex twice if Empty() is called more
than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will first
increment it!
+ readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped frames in
xine vdpau h264
delete readFrame; // might not have been stored in the buffer in Action()
readFrame = NULL;
playFrame = NULL;
@@ -388,6 +388,8 @@
int pc = 0;
readIndex = Resume();
+ int resume = readIndex;
+ bool firsttime = true;
if (readIndex >= 0)
isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex,
true, framesPerSecond));
@@ -452,6 +454,12 @@
else if (index) {
uint16_t FileNumber;
off_t FileOffset;
+ if (firsttime) {
+ if (readIndex == (resume + 32)) {
+ Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264
+ firsttime = false;
+ }
+ }
if (index->Get(readIndex + 1, &FileNumber, &FileOffset, &readIndependent, &Length)
&& NextFile(FileNumber, FileOffset))
readIndex++;
else
@@ -760,7 +768,7 @@
if (Index > 0)
Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true);
if (Index >= 0)
- readIndex = Index - 1; // Action() will first increment it!
+ readIndex = Index; // prevents dropped frames in xine vdpau h264
}
Play();
}
I can't help the feeling that this is a problem that should
be addressed in xine, rather than working around it in VDR.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings
Am 02.04.2011 23:18, schrieb Klaus Schmidinger:
On 02.04.2011 02:38, Joerg Riechardt wrote:
Problem solved with this patch:
--- dvbplayer.c.orig 2010-03-07 15:24:26.0 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
@@ -320,7 +320,7 @@
if (nonBlockingFileReader)
nonBlockingFileReader->Clear();
if (!firstPacket) // don't set the readIndex twice if Empty() is
called more than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will
first increment it!
+ readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped
frames in xine vdpau h264
delete readFrame; // might not have been stored in the buffer in Action()
readFrame = NULL;
playFrame = NULL;
@@ -388,6 +388,8 @@
int pc = 0;
readIndex = Resume();
+ int resume = readIndex;
+ bool firsttime = true;
if (readIndex >= 0)
isyslog("resuming replay at index %d (%s)", readIndex,
*IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@
else if (index) {
uint16_t FileNumber;
off_t FileOffset;
+ if (firsttime) {
+ if (readIndex == (resume + 32)) {
+ Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264
+ firsttime = false;
+ }
+ }
if (index->Get(readIndex + 1, &FileNumber, &FileOffset,
&readIndependent, &Length) && NextFile(FileNumber, FileOffset))
readIndex++;
else
@@ -760,7 +768,7 @@
if (Index > 0)
Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true);
if (Index >= 0)
- readIndex = Index - 1; // Action() will first increment it!
+ readIndex = Index; // prevents dropped frames in xine vdpau h264
}
Play();
}
I can't help the feeling that this is a problem that should
be addressed in xine, rather than working around it in VDR.
Klaus
I agree. I just thought, until that happens, it is nice for those
concerned to have that patch.
And maybe this patch gives an idea for a fix in xine.
Joerg
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] bitstreamout plugin and VDR 1.7.17
Hi! Does the bitstreamout plugin still make sense for VDR 1.7.17? Upstream has been dead for about 3 years now and I'm considering to remove this plugin from the Debian archive. bye, Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
