Op Di, 25 november, 2008 03:59, schreef VDR User:
> On Mon, Nov 24, 2008 at 9:46 AM, Nicolas Huillard <nicolas(a)huillard.net>
> wrote:
>> It's still good news to know that open-source software allowing current
>> fanless integrated motherboards to decode HDTV at ~10% CPU is on its
>> way...
>>
>> Going from 87% of 2 cores, to ~10% of an entry level CPU is good,
>> specially when the load is taken care of by existing chips.
>
I agree on that …
[View More]point. I would rather have ~10% or ~20% then the regular
57% per core on my Core 2 Quad system when I view H264 channels of my
provider.
> Yes, I agree. Just pointing out that you certainly do not need a quad
> core, that's all. Also, the price of the cpu is the same whether
> you're using 87% or 10% of it. ;) The point is you can already have
> cheap HDTV without using the new Nvidia api.
>
Well, in my case I do. When I view BBCHD, ArteHD, AnixeHD or the AstraHD
channels I don't encounter many problems. Image is clear and no stutter.
But as soon as I watch the 1080i/H264 channels of my provider (Canal
Digitaal) on Astra 23.5e, I have major stuttering. BravaTV in HD doesn't
have much problems, but NGC HD and Discovery HD is an other matter. My
Core 2 Duo just couldn't handle it with FFMPeg and Xine-lib 1.2. But since
I've put in a Core 2 Quad, I'm able to watch those channels even with fast
moving images :)
>> I'd like to have full-HDTV on a single x86 mini-ITX board. I'm now
>> seeing this will happen soon enough, and I'll wait until then before I
>> spend money on new hardware.
>
> Yes it's nice! My goal is diskless, fanless, low power consumption
> dedicated HDTV box. Very small, very low cost!
>
I again agree :) I would like an additional HDTV box in my bedroom. It
needs to have the options you wrote. But I don't want a Popcorn or some
other kind of device. I want the option to enhance it myself (flexability)
so I'm waiting desperately for GPU based decoding of H264 and VC-1
transport streams :)
Niels Wagenaar
[View Less]
Hello dear VDR users and developers!
I've started a small survey about VDR and the VDR plug-ins and kindly ask
you to participate.
http://e-tobi.net/survey/
The main reason for this survey is, that there are currently more than 300
plug-ins available for VDR (according to the English and German VDR Wiki).
That's a lot!
As a member of the Debian VDR packaging project (we currently just have
about 120 plug-ins packaged), I would like to know, which are the plug-ins
that are really used and …
[View More]which are the ones that aren't used at all.
As a result of this survey, we would like to drop Debian packaging support
for some of the rarely and not used plug-ins that are not maintained by
their authors anymore and identify interesting plug-ins that might be good
candidates for an official release in Lenny +1 .
This survey is not just about the Debian VDR packages. It's main focus is
on VDR and VDR plug-ins in general and I hope, it will be useful for other
distribution maintainers and developers as well.
I will make the results and all the collected data available to the public
under the terms of the Creative Commons Licence (CC-BY-SA), after the
survey has been finished.
The survey is completely anonymous! You have to register with an email
address and a password, but they will only be stored as an SHA hash in the
database and will be randomized once more, before the data is made
available to the public. The survey will not send any emails or do other
nasty stuff!
If you have any problems with the survey or your are missing a plug-in,
just write me a small note to: vdr-plugin-survey-2008(a)e-tobi.net
Thanks for your participation!
Tobias Grimm (e-tobi.net)
[View Less]
Hi,
Please advice how to configure xineliboutput in the best way...
I have 1.7.1 + ext64 patches, xineliboutput 1.0.3, nVidia card with latest
drivers.
After many tests I have the following:
Using --hud gives best OSD I ever seen, but it shows only the OSD when the
output window is in focus and no playback. When I select another window
(loose focus), I see the playback, but this way I can't control it...
Using opengl video output gives me the best playback quality with lowest CPU
usage, but …
[View More]it doesn't show any OSD at all, nor software nor hardware.
Using xv video output with deinterlacing takes about 40-50% of CPU on my
E6600 system. OSD is shown ok (don't remember already, but I think only
software based OSD works well).
Using xxmc video output with deinterlacing takes less than 40% CPU, hardware
OSD works well, but with tvtime deinterlacing looks like frames are dropped.
Non tvtime deinterlacing doesn't look that good.
Using xvmc output doesn't work since there is a module that can't be found.
Please advice how can it be configured to have both low CPU, good
deinterlaced image and an OSD (preffered the --hud one).
Thank you.
[View Less]
Hi,
using vdr-1.7.1 patched for S2API with vdr-1.7.1-s2api-07102008-vanilla.patch
and DVB drivers from yesterday (via: hg clone http://linuxtv.org/hg/v4l-dvb).
I've the following issues (tuned to ZDF):
- playing with softdevice there is no video, but audio and subtile work.
- dumping the data I got via PlayVideo() to a file neither ffplay nor
mplayer can identify stream info from dumped data.
- additional implemented methods PlayTs*() won't get called.
class cSoftDevice : public cDevice {
…
[View More]private:
cMpeg2Decoder *decoder;
cVideoOut *videoOut;
cAudioOut *audioOut;
[snip]
public:
cSoftDevice(int method, int audioMethod, char *pluginPath);
~cSoftDevice();
[snip]
virtual int PlayVideo(const uchar *Data, int Length);
#if VDRVERSNUM >= 10701
virtual int PlayTSVideo(const uchar *Data, int Length);
virtual int PlayTSAudio(const uchar *Data, int Length);
virtual int PlayTS(const uchar *Data, int Length, bool VideoOnly = false);
#endif
--
Stefan Lucke
[View Less]
Where can I download the H.264 patch from? I can't find it on Google. My
card is only DVB-S, not DVB-S2; do I need the s2api patch as well?
--
TH * http://www.realh.co.uk
Hi,
I'm trying to configure xineliboutput 1.0.3 with VDR 1.7.1.
Compilation and installation seems to go ok, but playback doesn't work.
I can see OSD in opened window, but when it gets to the channel itself CPU
usage jumps to 100% and the log contains:
Nov 30 01:24:17 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(185008 bytes) !
Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES …
[View More]too long
(185008 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:17 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(192000 bytes) !
Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(192000 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:18 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(243888 bytes) !
Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(243888 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:18 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(260816 bytes) !
Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(260816 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:19 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(245728 bytes) !
Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(245728 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:19 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(242416 bytes) !
Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(242416 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:20 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(249776 bytes) !
Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(249776 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:20 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(257320 bytes) !
Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(257320 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:21 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(268176 bytes) !
Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(268176 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:21 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(268912 bytes) !
Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(268912 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:22 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(237632 bytes) !
Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(237632 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:22 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES
(215000 bytes) !
Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long
(215000 bytes, max size 8192 bytes), data ignored !
Nov 30 01:24:23 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny:
invalid data !
Any ideas?
Thanks.
[View Less]
This femon release should fix those reported hangups while zapping
through channels.
Femon:
======
2008-11-30: Version 1.6.4
- Added new helper functions.
- Updated Italian translation (Thanks to Diego Pierotto).
- Fixed a memory leak.
- Added a check for the minimum OSD height.
- Replaced "Use single area (8bpp)" option with VDR's
"Setup/OSD/Anti-alias".
- Removed the FEMON_NTSC option.
- Fixed a deadlock in cFemonReceiver (Thanks to Antti Seppälä
for reporting this one).
http://www.…
[View More]saunalahti.fi/~rahrenbe/vdr/femon/
Skinsoppalusikka:
=================
2008-11-30: Version 1.6.3
- Added automatic conversion of '/' characters in channel names
to '~' characters in filenames for logos.
- Replaced "Use single area (8bpp)" option with VDR's
"Setup/OSD/Anti-alias".
http://www.saunalahti.fi/~rahrenbe/vdr/soppalusikka/
BR,
--
rofa
[View Less]
Hi!
There is a new version of the 'Spider Arachnid' plug-in.
Download: http://toms-cafe.de/vdr/spider/vdr-spider-0.2.2.tgz
Changes since version 0.2.1:
- Updated Italian language texts (thanks to Diego Pierotto).
- Updated Spanish language texts (thanks to Bittor Corl).
'Spider Arachnid' is an implementation of the best patience game played
on the On Screen Display of the VDR. See the project's homepage for
details: http://www.toms-cafe.de/vdr/spider/
Tom
VDR isn't fetching EPG info for my DVB-S channels. At best it shows
what's on now and next but many channels seem to have no data at all.
My dish is a Sky minidish, so I presume I don't have diseqc. To "seed"
channels.conf I used the scan utility from linuxtv-dvb-apps, with the
initial tuning files for Astra-28.2E and Eurobird1-28.5E because I read
that's where Freesat is broadcast from. I noticed that the provider for
all the channels is listed as "BSkyB", so does this mean I'm getting
"…
[View More]Freesat from Sky" rather than the BBC/ITV consortium?
ISTR reading that Freesat's EPG is on Eurobird1. Perhaps I accidentally
masked it out because I tried to mask out encrypted channels and
non-TV/radio? But I would have thought VDR would add it back, because it
doesn't mask on its own scans.
Or perhaps scan's output isn't quite compatible with VDR, even with the
-o vdr option? I know this causes lots of trouble with the DVB-T
channels, because VDR adds copies of channels if they're not quite in
the format it likes best and then gets a bit weird with them, including
not providing EPG info for the channels from the external scan tool.
I've managed to resolve this for DVB-T, but there are so many satellite
channels (mostly not of interest to me) I can't really keep track of
which ones came from scan and which from VDR, and some VDR claims are
"unavailable" even though they should be FTA.
It would be good if the developers of scan and VDR could advise each
other so they're properly compatible with each other and if VDR could
have an option to run a separate program for building channels.conf so I
could do all sorts of tricks like filtering out encrypted channels and
sorting the ones I'm interested in.
--
TH * http://www.realh.co.uk
[View Less]
Hi
is it possible to implement in xineliboutput the on fly software scaling on fly (as it has been realize in vdr-xine) ?
I mean the option - Video - Software scaling - yes - Change video size
http://ag1455.nm.ru/VDR/IMG_1056.JPG
Need to restart vdr and after that new settings will apply. It's not comfortable.
Goga