Emil wrote:
> I mean between red and ground, green and ground, blue and ground.
I haven't tried wiring up this RGB lead myself but I've done a fair bit
of work with ananogue transmission line theory which explains why this
termination is required to get a good signal.
I believe the answer is a s
I've found some info at
http://www.vdrportal.de/board/portal_vdrinfo.php?
site=7&infonr=4&infoln=en&sid=2e010195ed29a33af8a7f3d506ae42c0 but
cannot decipher it.
If I'm absolutely anal about picture quality and protecting my DVB-S
card and also interested in the SPDIF out what would my item
Hi,
I've started a new thread because I wanted to change the topic of my
previous thread and get as broad a viewing as possible. In my previous
thread I was told how to fix my wiring so that I would get a picture
and this worked but the output is much too grainy with light colours on
white bei
On Wed, 24 Dec 2003 07:58:55 +1000, Michal Dobrzynski
<[EMAIL PROTECTED]> wrote:
> a 75Ohm resistor on the ground? Are you sure you don't mean on the
> composite video/luminance signal? I am electrically ignorant so it
> doesn't make much sense to me to put it on ground.
I mean between red and
Malcolm Caldwell wrote:
> Here is my apps/scan/dvb-t/au-Darwin file for Darwin Australia.
Comitted to CVS.
> Out of curiosity: In Australia channels can be 125Khz off centre. When
> I scan the scan picks up from the information on air that there are
> channels I have specified in my file but wi
Holger Waechtler wrote:
>
> the nom/denom notation is in opposite to the frames/msec notation always
> correct and can display all usual framerates without rounding - so I'd
> vote for this one.
It's frames / (1000 seconds).
And I think it's accurate enough. AFAIK this value is not used
in the
Andreas Oberritter wrote:
> On Tue, 2003-12-23 at 14:12, Holger Waechtler wrote:
> > the nom/denom notation is in opposite to the frames/msec notation always
> > correct and can display all usual framerates without rounding - so I'd
> > vote for this one.
>
> Do you know any mpeg decoder which o
a 75Ohm resistor on the ground? Are you sure you don't mean on the
composite video/luminance signal? I am electrically ignorant so it
doesn't make much sense to me to put it on ground.
Regards,
Michal
On 24/12/2003, at 12:22 AM, Emil Naepflein wrote:
On Wed, 24 Dec 2003 00:18:12 +1000, Michal D
Hello,
I assume this may be a bit off-topic for this list, however my hopes are to
find someone who can deliver this info back to it's author.
In my quest to make v4l2 and related tools 64bit compatible, I came up with
SoftCam plugin. I've found some issues so far that I would like to share:
In
From: "Andreas Oberritter" <[EMAIL PROTECTED]>
> seems like auto inversion fails. please try ves1820.c from dvb-kernel
> or try increasing the mdelays until it works reliably. current cvs
> version uses 50ms delay while the patches you used have 30ms.
Might still not be enough. I've measured the s
Instead of modifying the sources, you could simply have edited the
channels.conf file and change the "INVERSION_AUTO" setting to either
"INVERSION_ON" or "INVERSION_OFF".
The automatic spectral inversion detection code (which is just a few lines
below the part you edited) appears not to work relia
On Tue, 2003-12-23 at 14:02, Andreas 'powARman' Regel wrote:
> I tracked this down to function ves1820_setup_reg0 in ves1820.c. Value
> of reg0 at the beginning of this function changes from value 0x48 to
> 0x68 or from 0x68 to 0x48 with every call. If reg0 is 0x48 tuning will
> work, if reg0 is 0x
On Tue, 2003-12-23 at 14:12, Holger Waechtler wrote:
> the nom/denom notation is in opposite to the frames/msec notation always
> correct and can display all usual framerates without rounding - so I'd
> vote for this one.
Do you know any mpeg decoder which offers these values instead of the
few
On Wed, 24 Dec 2003 00:18:12 +1000, Michal Dobrzynski
<[EMAIL PROTECTED]> wrote:
> I couldn't help myself and I just tried it. It works :) Thanks.
>
> But I'm a bit concerned. Something doesn't seem quite right about the
> output. It's grainier than I think it should be and this is even
> visib
I couldn't help myself and I just tried it. It works :) Thanks.
But I'm a bit concerned. Something doesn't seem quite right about the
output. It's grainier than I think it should be and this is even
visible in areas of black. I'm sure the SVideo output of the DXR3
didn't exhibit this. Also thin
> What kind of card might that be? Is there any chance to get it to run with
> the linux dvb drivers?
I have a Hauppauge DVB-s Rev. 1.3 with a sticker "DVBS 564 012912" from the
same year.
It's no problem to use with dvb-drivers, it is supported well.
This card is full featured.
Greetings from Er
Johannes Stezenbach wrote:
Felix Domke wrote:
Johannes Stezenbach wrote:
The V4 API has:
unsigned int frame_rate; /* in frames per 1000sec */
I'm against this.
The reason is that arbitrary framerates are not allowed in MPEG-2
(correct me if i'm wrong, i'm currently too lazy to read 13818-2
Hi, me again :-)
> I did some further investigations using czap. I discovered that tuning
> works exactly every second try, the next try always doesn't work
I tracked this down to function ves1820_setup_reg0 in ves1820.c. Value
of reg0 at the beginning of this function changes from value 0x48 to
Hello again,
> I was offered a 2nd hand card which is called "WinTV DVB-s"
> (produced 1999) and has a sticker on the back saying "DVBS
> 564 014915".
>
> What kind of card might that be? Is there any chance to get
> it to run with the linux dvb drivers?
After some more inquiry, the card
Hi Michal,
I confess it now makes perfect sense to me.. All the frustration had
caused me to completely misinterpret what you wrote and twist it into
something crazy which you didn't say at all. For some reason I had
misunderstood that ALL pins had to be reversed (whatever I imagined
that to m
Hi,
I did some further investigations using czap. I discovered that tuning
works exactly every second try, the next try always doesn't work:
outputs of czap tuning on channel ZDF (also tested other channels):
/usr/local/src/DVB/apps/szap # ./czap -c channels.conf -n 1
using '/dev/dvb/adapter0/fr
I confess it now makes perfect sense to me.. All the frustration had
caused me to completely misinterpret what you wrote and twist it into
something crazy which you didn't say at all. For some reason I had
misunderstood that ALL pins had to be reversed (whatever I imagined
that to mean).
Sorry
Hello,
I was offered a 2nd hand card which is called "WinTV DVB-s" (produced 1999)
and has a sticker on the back saying "DVBS 564 014915".
What kind of card might that be? Is there any chance to get it to run with
the linux dvb drivers?
Lars
--
Info:
To unsubscribe send a mail to [EMAIL PROT
On 23/12/2003, at 9:43 PM, Helmut Auer wrote:
Hi Michal,
That doesn't quite make sense to me as pin 1 on the male connector
corresponds to pin 1 on the female connector and so forth through all
the pins. When I compared it to the male connector I wired up for the
Matrox G550 the red, green, bl
Hi Michal,
That doesn't quite make sense to me as pin 1 on the male connector
corresponds to pin 1 on the female connector and so forth through all
the pins. When I compared it to the male connector I wired up for the
Matrox G550 the red, green, blue, etc pins went into the red, green,
blue et
On Tue, Dec 23, 2003 at 12:23:41PM +0100, Nico wrote:
>
> did you run
> mplayer -cache 4096 dvb://
>
> as I previously suggested? Does it help?
yes, I did, it does not make any difference
(except for slower startup until it caches the data)
> >
> >
> 12% from the file?
from /dev/dvb/adapter0/
That doesn't quite make sense to me as pin 1 on the male connector
corresponds to pin 1 on the female connector and so forth through all
the pins. When I compared it to the male connector I wired up for the
Matrox G550 the red, green, blue, etc pins went into the red, green,
blue etc sockets.
did you run
mplayer -cache 4096 dvb://
as I previously suggested? Does it help?
Radovan Garabik wrote:
Following up to my previous mail about mplayer's slow decoding,
here are some additional tests:
first, speed of audio decoding (mp2 stream, taken from
dvb broadcast and saved to hdd as an eleme
Michal Dobrzynski wrote:
On 23/12/2003, at 8:19 PM, Helmut Auer wrote:
Hello,
The main Problem can be the cable you are using, and the length of it.
I would suggest to connect the J2 to a female SCART connector with a
short ( and if possible shielded ) cable connection ( ~ 30 cm ).
You have to b
Following up to my previous mail about mplayer's slow decoding,
here are some additional tests:
first, speed of audio decoding (mp2 stream, taken from
dvb broadcast and saved to hdd as an elementary stream),
number is CPU usage:
mpg1235%
mpg321 13%
madplay 9.5%
second, CPU usage of mplay
On 23/12/2003, at 8:19 PM, Helmut Auer wrote:
Hello,
The main Problem can be the cable you are using, and the length of it.
I would suggest to connect the J2 to a female SCART connector with a
short ( and if possible shielded ) cable connection ( ~ 30 cm ).
You have to be aware that in this cse t
Furthermore, some info I have forgotten to add is that the card is
detected as a rev1.3 as follows when the dvb-ttpci and stv0299 modules
are loaded:
saa7146: register extension 'dvb'.
saa7146_core: found saa7146 @ mem e0907e00 (revision 1, irq 17)
(0x13c2,0x).
DVB: registering new adapter
Michal Dobrzynski wrote:
Si it looks like I may have made a very expensive mistake ordering a
card from overseas. I've followed the diagram at
http://www2.arnes.si/%7Emthale1/rgb.html to create a cable to connect
the card via J2 to my TV and the best I have been able to get is a
garbled, scrol
your dmesg doesn't report any frontend, that's why you can't access
frontend0
ABBAS AL-MUTAWA wrote:
hi
You have to create the /dev/dvbX/... entries...
There is a script in the "DVB" package at
linuxtv.org
i have used makedev to create the /dev/dvb/adapter..
this is the result
[EMAIL PR
Si it looks like I may have made a very expensive mistake ordering a
card from overseas. I've followed the diagram at
http://www2.arnes.si/%7Emthale1/rgb.html to create a cable to connect
the card via J2 to my TV and the best I have been able to get is a
garbled, scrolling mass of junk (only ba
hi
> You have to create the /dev/dvbX/... entries...
> There is a script in the "DVB" package at
> linuxtv.org
i have used makedev to create the /dev/dvb/adapter..
this is the result
[EMAIL PROTECTED] driver]# sh makedev.napi
Creating DVB devices in /dev/dvb/adapter0
chown: `root.video': invali
Hello,
Following Michael's hints in the other thread, I have 2.6.0 now running with
a statically built in dvb-kernel (CVS as of yesterday evening). I'm using a
Nexus-s 2.1, "frontend" is VDR 1.2.6.
However, stability seems to be worse than with 2.6.0-t11 and dvb-kernel from
CVS about 2 weeks ago
Hi,
I recently tried the new kernel 2.6.0 with dvb-kernel from CVS but
have tuning problems. I am using a Technotrend DVB-C Rev. 2.1. I have
checked out dvb-kernel module from CVS and applied the 12 patches.
Loading the driver and the firmware through sysfs works very well but
when starting vdr I
On Monday 22 December 2003 21:43, ABBAS AL-MUTAWA wrote:
> Hi
>
> after insmod the following modules successfully
>
> modprobe dvb_core dvb_shutdown_timeout=0
> modprobe video-buf
> modprobe bttv i2c_hw=1 card=0x68
> modprobe bt878
> modprobe dst dst_type_flags=4
> modprobe dvb-bt8xx
>
> i tr
39 matches
Mail list logo
