Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems

2009-08-22 Thread Klaus Schmidinger
On 22.08.2009 23:03, Simon Baxter wrote:
>> On 22.08.2009 00:51, Simon Baxter wrote:
>>> Hi
>>>
>>> I use xmltv2vdr to process .xml EPG listings and populate VDR.
>>>
>>> VDR seems to be processing the EPG (via SVDRP) into and across two
>>> channels. There's no error in the xmltv2vdr - seems to be a VDR problem.
>>>
>>> Example:
>>> here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c
>>> test.channels.vibe -s >>output"
>>>
>>> C C-182-5-504 Vibe;T
>>> E 8270 1250904000 3000 0
>>> T Smallville
>>> D Clark is amazed when a pesticide magnate somehow convinces Jonathan to
>>> sell the family farm to make way for a new plant.
>>> e
>>> E 8320 1250907000 2700 0
>>> T Smallville
>>> D When Clark rescues his classmate from harm during an electrical storm,
>>> they are both struck by lightning - resulting in all of Clark's
>>> superpowers being transferred. Lex confronts Clark about his powers.
>>> e
>>> c
>>> C C-182-2-212 Prime TV;T
>>> E 8300 1250905800 1800 0
>>> T Chequered Flag
>>> D Czech Moto GP Highlights - Moto GP returns after its summer break with
>>> the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals
>>> Jorge Lorenzo and Casey Stoner.
>>> e
>>>
>>>
>>> but when I do a "LSTE at 1250905800"
>>>
>>> The "Chequered Flag" program is appearing in Prime and Vibe:
>>>
>>> 215-C C-182-5-504 Vibe
>>> 215-E 8300 1250905800 1800 0 FF
>>> 215-T Chequered Flag
>>> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break
>>> with the Czech GP at Brno and Valentino Rossi holding a slim lead over
>>> rivals Jorge Lorenzo and Casey Stoner.
>>> 215-e
>>>
>>>
>>> 215-C C-182-10-1004 Prime TV
>>> 215-E 8300 1250905800 1800 0 FF
>>> 215-T Chequered Flag
>>> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break
>>> with the Czech GP at Brno and Valentino Rossi holding a slim lead over
>>> rivals Jorge Lorenzo and Casey Stoner.
>>> 215-e
>>> 215-c
>>
>> The channel you entered EPG data for was
>>
>> C-182-2-212 Prime TV;T
>>
>> while the one listed later is
>>
>> C-182-10-1004 Prime TV
>>
>>
>> Are you sure that this entry has not been in there for "C-182-5-504
>> Vibe;T"
>> before you ran xmltv2vdr.pl?
>>
>> Klaus
> 
> I think I've now fixed this...
> 
> I did have these multiple entries in the xmltv2vdr.channels.conf file :
> Prime
> TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz
> 
> Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz
> Prime
> TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz
> 
> Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz
> Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz
> Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz
> 
> 
> ...because my cable provider is currently transmitting prime on multiple
> transponders.
> (PS the Prime TV_A entry is received via a PVR-500 card)
> 
> question - the last Prime entry and the Vibe entry have the same service
> ID "504".  Should my provider be using this overlap?  This is probably
> where my mistake was - I've now excluded the last Prime TV entry in my
> xmltv2vdr processing.

Using the same Sid for two different channels on the same transponder
is certainly not a good idea ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems

2009-08-22 Thread Simon Baxter

On 22.08.2009 00:51, Simon Baxter wrote:

Hi

I use xmltv2vdr to process .xml EPG listings and populate VDR.

VDR seems to be processing the EPG (via SVDRP) into and across two
channels. There's no error in the xmltv2vdr - seems to be a VDR problem.

Example:
here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c
test.channels.vibe -s >>output"

C C-182-5-504 Vibe;T
E 8270 1250904000 3000 0
T Smallville
D Clark is amazed when a pesticide magnate somehow convinces Jonathan to
sell the family farm to make way for a new plant.
e
E 8320 1250907000 2700 0
T Smallville
D When Clark rescues his classmate from harm during an electrical storm,
they are both struck by lightning - resulting in all of Clark's
superpowers being transferred. Lex confronts Clark about his powers.
e
c
C C-182-2-212 Prime TV;T
E 8300 1250905800 1800 0
T Chequered Flag
D Czech Moto GP Highlights - Moto GP returns after its summer break with
the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals
Jorge Lorenzo and Casey Stoner.
e


but when I do a "LSTE at 1250905800"

The "Chequered Flag" program is appearing in Prime and Vibe:

215-C C-182-5-504 Vibe
215-E 8300 1250905800 1800 0 FF
215-T Chequered Flag
215-D Czech Moto GP Highlights - Moto GP returns after its summer break
with the Czech GP at Brno and Valentino Rossi holding a slim lead over
rivals Jorge Lorenzo and Casey Stoner.
215-e


215-C C-182-10-1004 Prime TV
215-E 8300 1250905800 1800 0 FF
215-T Chequered Flag
215-D Czech Moto GP Highlights - Moto GP returns after its summer break
with the Czech GP at Brno and Valentino Rossi holding a slim lead over
rivals Jorge Lorenzo and Casey Stoner.
215-e
215-c


The channel you entered EPG data for was

C-182-2-212 Prime TV;T

while the one listed later is

C-182-10-1004 Prime TV


Are you sure that this entry has not been in there for "C-182-5-504 
Vibe;T"

before you ran xmltv2vdr.pl?

Klaus


I think I've now fixed this...

I did have these multiple entries in the xmltv2vdr.channels.conf file :
Prime 
TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz

Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz
Prime 
TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz

Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz
Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz
Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz

...because my cable provider is currently transmitting prime on multiple 
transponders.

(PS the Prime TV_A entry is received via a PVR-500 card)

question - the last Prime entry and the Vibe entry have the same service ID 
"504".  Should my provider be using this overlap?  This is probably where my 
mistake was - I've now excluded the last Prime TV entry in my xmltv2vdr 
processing.




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] xbmc-pvr (was - HD clients for vdr)

2009-08-22 Thread Seppo Ingalsuo
On Sat, 2009-08-22 at 14:31 +0300, Seppo Ingalsuo wrote:

> recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’
> cannot be overloaded
> recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent()
> const’
> make: *** [channels.o] Error 1

The duplicate due to patching had to be removed from recording.h. Also
there was need to include status.h to videodir.c.

Now xbmc connects to vdr server and gets first radio channels, then tv
channels and then nothing happens. I wonder how long it needs to be
waited. Perhaps wrong/non working patches?

Xmbc without vdr seems to be fine. 

BR,
Seppo



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Goga777
> > honestly - I don't know because the dish is on the roof of my home - I 
> > don't have access to it currently 
> 
> OK, that makes debugging more complicated.

I connected the ampermeter for measure the current in dish cable and found out 
that no any problem with software - when I
are moving between satellite the current is arising from 120 ma to 200-300 ma. 
But I don't have lock. I suppose that my
dish installed not so correctly - that's why I should play with altitude and 
latitude. I will do. 

> > have you ideas about how can I see in the log the disecs commands from vdr 
> > to dish ?
> 
> I don't know of logging but it should be with your diseqc.conf as simple
> as:
> 
> tone on/off
> voltage 13/18
> E0
> 10
> 38
> xx
> wait 150 ms
> G becomes
>voltage 18
>tone off
>wait 20ms
>EO
>31
>6E
>yy
>zz
>if repeated
>  wait 20 ms
>  E1
>  31
>  6E
>  yy
>  zz
>   wait dish turn for 100 ms ... 100s (e.g.)
> tone on/off
> voltage 13/18
> 
> Did you have this working with some other vdr setup or set to box?

no, I have only these logs 

Aug 22 20:21:19 arvdr vdr: [3218] DiSEqC GotoX -192 (35008) -> -360 (35176), 
wait time  1.7s
Aug 22 20:21:22 arvdr vdr: [3218] DiSEqC GotoX done.
Aug 22 20:21:27 arvdr vdr: [3195] warning: Moving dish to 19.2E - 1s
Aug 22 20:21:29 arvdr vdr: [3195] warning: Moving dish to 36.0E - 1s
Aug 22 20:21:31 arvdr vdr: [3218] frontend 0 timed out while tuning to channel 
13, tp 112303
Aug 22 20:21:36 arvdr vdr: [3195] switching to channel 14


Goga

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Turn off/relocate ts error logging

2009-08-22 Thread VDR User
On Sat, Aug 22, 2009 at 10:12 AM, Timothy D. Lenz wrote:
> My log files get so big it,s very hard to check them because of the ts error 
> messages that get flooded to it. I've had logs near 2gb
> in size. I have a problem with xine crashing when there is a weak signal and 
> the ts loging bloating the log files is creating a lot
> of problems. Need a way to turn off ts error loging or relocate to another 
> file.

You can use logrotate to limit the size of the log file.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Turn off/relocate ts error logging

2009-08-22 Thread Timothy D. Lenz
My log files get so big it,s very hard to check them because of the ts error 
messages that get flooded to it. I've had logs near 2gb
in size. I have a problem with xine crashing when there is a weak signal and 
the ts loging bloating the log files is creating a lot
of problems. Need a way to turn off ts error loging or relocate to another file.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Ales Jurik
On Saturday 22 of August 2009, Goga777 wrote:
>
> have you ideas about how can I see in the log the disecs commands from vdr
> to dish ?
>
You can add dsyslog command to each point in dvbdevice.c where this ioctl with 
FE_DISEQC_SEND_MASTER_CMD is called (3 times) and print out the cmd buffer. 

Better is to place syslog into frontend source of your card.

BR,

Ales

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Seppo Ingalsuo
On Sat, 2009-08-22 at 17:45 +0400, Goga777 wrote:

> 
> honestly - I don't know because the dish is on the roof of my home - I don't 
> have access to it currently 

OK, that makes debugging more complicated.

> have you ideas about how can I see in the log the disecs commands from vdr to 
> dish ?

I don't know of logging but it should be with your diseqc.conf as simple
as:

tone on/off
voltage 13/18
E0
10
38
xx
wait 150 ms
G becomes
   voltage 18
   tone off
   wait 20ms
   EO
   31
   6E
   yy
   zz
   if repeated
 wait 20 ms
 E1
 31
 6E
 yy
 zz
  wait dish turn for 100 ms ... 100s (e.g.)
tone on/off
voltage 13/18

Did you have this working with some other vdr setup or set to box?

BR,
Seppo



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Goga777
> > I have this scheme  vdr with hvr4000 card  ---> rotor  >> 4x1 diseqc 
> > switch ---> LNB Ku band Linear + LNB Ku
> > band Circular + LNB С band Circular 
> > 
> > my diseqc.conf (for Ku circular) is 
> > 
> > S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t
> > S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t
> > S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t
> > S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t
> 
> Does the dish turn? 

honestly - I don't know because the dish is on the roof of my home - I don't 
have access to it currently 

>I wonder if the order of G and [E0 10 38 xx] switch
> command matters?
 
> Have you enabled diseqc.conf usage from vdr lnb setup menu?

yes

> You could set it to no as well to eliminate diseqc.conf for a while to just 
> see if
> the dish is moving. I suppose it should because it's not behind the
> switch in your setup.

have you ideas about how can I see in the log the disecs commands from vdr to 
dish ?

Goga


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems

2009-08-22 Thread Klaus Schmidinger
On 22.08.2009 00:51, Simon Baxter wrote:
> Hi
> 
> I use xmltv2vdr to process .xml EPG listings and populate VDR.
> 
> VDR seems to be processing the EPG (via SVDRP) into and across two
> channels. There's no error in the xmltv2vdr - seems to be a VDR problem.
> 
> Example:
> here's a snippet from "./xmltv2vdr.pl -x listings-sky.xml -c
> test.channels.vibe -s >>output"
> 
> C C-182-5-504 Vibe;T
> E 8270 1250904000 3000 0
> T Smallville
> D Clark is amazed when a pesticide magnate somehow convinces Jonathan to
> sell the family farm to make way for a new plant.
> e
> E 8320 1250907000 2700 0
> T Smallville
> D When Clark rescues his classmate from harm during an electrical storm,
> they are both struck by lightning - resulting in all of Clark's
> superpowers being transferred. Lex confronts Clark about his powers.
> e
> c
> C C-182-2-212 Prime TV;T
> E 8300 1250905800 1800 0
> T Chequered Flag
> D Czech Moto GP Highlights - Moto GP returns after its summer break with
> the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals
> Jorge Lorenzo and Casey Stoner.
> e
> 
> 
> but when I do a "LSTE at 1250905800"
> 
> The "Chequered Flag" program is appearing in Prime and Vibe:
> 
> 215-C C-182-5-504 Vibe
> 215-E 8300 1250905800 1800 0 FF
> 215-T Chequered Flag
> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break
> with the Czech GP at Brno and Valentino Rossi holding a slim lead over
> rivals Jorge Lorenzo and Casey Stoner.
> 215-e
> 
> 
> 215-C C-182-10-1004 Prime TV
> 215-E 8300 1250905800 1800 0 FF
> 215-T Chequered Flag
> 215-D Czech Moto GP Highlights - Moto GP returns after its summer break
> with the Czech GP at Brno and Valentino Rossi holding a slim lead over
> rivals Jorge Lorenzo and Casey Stoner.
> 215-e
> 215-c

The channel you entered EPG data for was

C-182-2-212 Prime TV;T

while the one listed later is

C-182-10-1004 Prime TV


Are you sure that this entry has not been in there for "C-182-5-504 Vibe;T"
before you ran xmltv2vdr.pl?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] xbmc-pvr (was - HD clients for vdr)

2009-08-22 Thread Seppo Ingalsuo
Hi,

Are there cleaner or later patches somewhere for vdr (1.7.8) for xmbc?
The patch vdr-1.7.4-ext68-streamdev.patch from ticket
http://xbmc.org/trac/ticket/5595

could be applied but there could be some extra that I don't need from
some VDR extensions patch.

I'm also wondering if streamdev cvs is good as such. The HISTORY file
mentions "added XBMC support by extending VTP capabilities (thanks to
Alwin Esch)".

Anyway this is what I got when compiling

g++ -march=pentium4 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c
-DUSE_STREAMDEVEXTENSION -DREMOTE_KBD -DVDR_USER=\"vdr\" -DLIRC_DEVICE=
\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\"
-DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/freetype2
-I/usr/src/v4l-dvb/linux/include channels.c
In file included from skins.h:17,
 from osdbase.h:15,
 from player.h:14,
 from status.h:15,
 from channels.c:17:
recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’
cannot be overloaded
recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent()
const’
make: *** [channels.o] Error 1

BR,
Seppo



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Seppo Ingalsuo
On Sat, 2009-08-22 at 13:54 +0400, Goga777 wrote:

> I have this scheme  vdr with hvr4000 card  ---> rotor  >> 4x1 diseqc 
> switch ---> LNB Ku band Linear + LNB Ku
> band Circular + LNB С band Circular 
> 
> my diseqc.conf (for Ku circular) is 
> 
> S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t
> S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t
> S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t
> S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t

Does the dish turn? I wonder if the order of G and [E0 10 38 xx] switch
command matters?

Have you enabled diseqc.conf usage from vdr lnb setup menu? You could
set it to no as well to eliminate diseqc.conf for a while to just see if
the dish is moving. I suppose it should because it's not behind the
switch in your setup.

BR,
Seppo



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] HD clients for vdr

2009-08-22 Thread Torgeir Veimo
2009/8/22 Thomas Hilber :
> On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote:
>> In my experience, you just have to do deinterlacing in vdpau with
>> interlaced content, even when displaying on an interlaced display. If
>> you try to output interlaced material directly, you get ghosting since
>> the weaved frames are copied to the progressive surface, and the
>> output resolution might be different than the weave pattern.
>
> the main reason why nvidia chooses to deinterlace always even if you use an
> interlaced video timing is not the scaling problem you mention. This could
> be eventually solved (albeit not perfectly) by scaling both fields
> independently.
>
> The main reason is: even with VDPAU there still exists no synchronization
> between stream and video timing.

I accept that they prefer "always" deinterlacing because they didn't
implement proper field parity in their architecture / api /
implementation. But I still think they screwed up. The matrox mga
450/550 cards do field parity pretty well, with a simple api, and in
98% of cases with predictable results and with manageable clock drift
workarounds. Too bad they offer no mpeg2 or h.264 acceleration.

-- 
-Tor

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] HD clients for vdr

2009-08-22 Thread Goga777
Приветствую, Vladimir
> Is it AMD (ATI) have the same problem?

yes.
but for ati and intel there's solution from Thomas - see 

http://www.forum.free-x.de/wbb/index.php?page=Thread&postID=2576#post2576
http://lowbyte.de/vga-sync-fields/vga-sync-fields/


Goga

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] gotoX patch & vdr 1.7.8

2009-08-22 Thread Goga777
hi

I tried to use the gotox patch (thanks to Seppo Ingalsuo and Ales Jurik) for 
vdr 178
http://www.linuxtv.org/pipermail/vdr/2009-June/020800.html

I have this scheme  vdr with hvr4000 card  ---> rotor  >> 4x1 diseqc switch 
---> LNB Ku band Linear + LNB Ku
band Circular + LNB С band Circular 

my diseqc.conf (for Ku circular) is 

S36.0E 0 V 10750 t v [E0 10 38 F4] W150 G v t
S36.0E 9 V 10750 t v [E0 10 38 F5] W150 G v t
S36.0E 0 H 10750 t V [E0 10 38 F6] W150 G V t
S36.0E 9 H 10750 t V [E0 10 38 F7] W150 G V t


but it seems something is wrong - I don't see anything

questions - how to log the diseqc command for more investigations ?

Goga







___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] HD clients for vdr

2009-08-22 Thread Thomas Hilber
On Sat, Aug 22, 2009 at 01:12:43PM +0400, Goga777 wrote:
> is it possible to solve radically this problem with vdpau ? did you discuss 
> with nvidia  developpers about this
> issue ?

I don't know if nvidia hardware is capable of such things at all. 
This issue (among others) once has been discussed somewhere here [1]. 

- Thomas

[1] http://www.nvnews.net/vbulletin/showthread.php?t=123895


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] HD clients for vdr

2009-08-22 Thread Vladimir Kangin
Is it AMD (ATI) have the same problem?

Vladimir

On Sat, 2009-08-22 at 13:12 +0400, Goga777 wrote:
> > the main reason why nvidia chooses to deinterlace always even if you
> > use an interlaced video timing is not the scaling problem you 
> > mention. This could be eventually solved (albeit not perfectly) by
> > scaling both fields independently.
> > 
> > The main reason is: even with VDPAU there still exists no
> > synchronization between stream and video timing.
> 
> is it possible to solve radically this problem with vdpau ? did you
> discuss with nvidia developpers about this issue ?
> 
> Goga


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] HD clients for vdr

2009-08-22 Thread Goga777
> the main reason why nvidia chooses to deinterlace always even if you use an
> interlaced video timing is not the scaling problem you mention. This could
> be eventually solved (albeit not perfectly) by scaling both fields 
> independently.
> 
> The main reason is: even with VDPAU there still exists no synchronization 
> between stream and video timing.

is it possible to solve radically this problem with vdpau ? did you discuss 
with nvidia  developpers about this
issue ?


Goga

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] HD clients for vdr

2009-08-22 Thread Thomas Hilber
On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote:
> In my experience, you just have to do deinterlacing in vdpau with
> interlaced content, even when displaying on an interlaced display. If
> you try to output interlaced material directly, you get ghosting since
> the weaved frames are copied to the progressive surface, and the
> output resolution might be different than the weave pattern.

the main reason why nvidia chooses to deinterlace always even if you use an
interlaced video timing is not the scaling problem you mention. This could
be eventually solved (albeit not perfectly) by scaling both fields 
independently.

The main reason is: even with VDPAU there still exists no synchronization 
between stream and video timing.

That means there will be an arbitrary amount of lost/doubled fields with
current VDPAU implementation.

Nvidias workaround now is to deinterlace all content in any case. As a 
result these field losses are (mostly) not directly visible to the human eye.

Ceasing from deinterlacing here would reveal field sequence problems 
(caused by missing stream-synchronization) immediately.

Cheers
  Thomas

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr