On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote:
> Ok, I have this hardware;
> http://www.silentpcreview.com/article311-page1.html an asus mainboard
> i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure
> with some tweaking, it should be possible to run pu
On 21 Jan 2009, at 16:17, Thomas Hilber wrote:
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote:
Does it work with 915 hardware as well?
Yup, a few days ago I successfully testet the patch on my
Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU
idles
at about
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote:
> Does it work with 915 hardware as well?
Yup, a few days ago I successfully testet the patch on my
Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles
at about 60%. Please see table at
http://www.vdr-portal.de/bo
On 21 Jan 2009, at 15:02, Thomas Hilber wrote:
>
> This way you now can build very cheap budget VDRs based on modern
> hardware
> like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output
> quality
> equaling a FF card but at fractional cost.
Does it work with 915 hardware as well?
On Tue, Jan 20, 2009 at 05:21:53PM +, Tony Houghton wrote:
> Varying the output frame rate to keep in sync with the input stream is
> very clever, but I don't understand how it solves the problem of
> distinguishing between top and bottom fields to sync to.
surely you can distinguish top and b
On 20.01.2009 22:18, Oliver Endriss wrote:
> Klaus Schmidinger wrote:
>> On 20.01.2009 16:01, Frank Schmirler wrote:
>>> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
I have attached a raw TS capture (~10M) containing the PMT pid 132
which is revealing the problem.
>>> Hum - PID 132 is
Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132
> >> which is revealing the problem.
> >
> > Hum - PID 132 is a french dolby track, not a PMT PID...
>
2009/1/20 Tony Houghton :
> On Tue, 20 Jan 2009 18:19:49 +0200
> "Ville Aakko" wrote:
>
>> 1) You need to enable sync on vblanck.
>
> [Snip]
>
>> The first is not possible on all drivers (i.e. fglrx).
>
> Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have
> APIs for waiting f
On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132
> >> which is revealing the problem.
> >
> > Hum - PID 132 i
On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> > I have attached a raw TS capture (~10M) containing the PMT pid 132
> > which is revealing the problem.
>
> Hum - PID 132 is a french dolby track, not a PMT PID...
>
> Cheers,
>
On Tue, 20 Jan 2009 18:23:21 +0200
Pasi Kärkkäinen wrote:
> Please check this thread:
> http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html
>
> Original patches: http://lowbyte.de/vga-sync-fields/
>
> New version: http://www.vdr-portal.de/board/thread.php?threadid=80567
>
> Those might
On Tue, 20 Jan 2009 18:19:49 +0200
"Ville Aakko" wrote:
> 1) You need to enable sync on vblanck.
[Snip]
> The first is not possible on all drivers (i.e. fglrx).
Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have
APIs for waiting for vblank and ISTR seeing a xine option fo
On Mon, Jan 19, 2009 at 09:54:18PM +, Scott Waye wrote:
> I want to replace my UK Sky digital box with VDR (I only want the free
> to air channels) for watching/recording TV over HDMI on my plasma. So
> far everything is working OK, I have vdr 1.7.3 and xine running on an
> ASUS M2N VM-HDMI
Hi Scott!
2009/1/19 Scott Waye :
> If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do
> any de interlacing in xine, why is this not the same as what my digibox
> does? I'm guessing it has something to do with xine outputting a
> complete frame when the broadcast sends each f
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537)
Thanks for having spotted that.
Cheers,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Dienstag, 20. Januar 2009, Klaus Schmidinger wrote:
>
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed m
On 20.01.2009 16:01, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
>> I have attached a raw TS capture (~10M) containing the PMT pid 132
>> which is revealing the problem.
>
> Hum - PID 132 is a french dolby track, not a PMT PID...
VDR uses the (fixed) "pseudo" PMT pid
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> I have attached a raw TS capture (~10M) containing the PMT pid 132
> which is revealing the problem.
Hum - PID 132 is a french dolby track, not a PMT PID...
Cheers,
Frank
___
vdr mailing list
vdr@linux
Hi,
Gerald Dachs schrieb:
>> I read something similar on the MythTV mailinglist.
>> >From http://www.gossamer-threads.com/lists/mythtv/users/366684:
>>> In the end I believe it was accidental code bugs when he was
>>> porting the automatic letterboxing patch over to work with VDPAU
>>> that caused
Hi Mika,
I have already applied the mentioned patch ;-) But unfortunately it does not
solve the issue.
Cheers,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> I did check the TS stream with dvbsnoop and it is not containing corrupted TS
> packets.
>
> Apparently VDR is able to parse the PMT the first time the data buffer is
> used. Then, it seems to loose the sync inside the payload.
>
> I have attached a raw TS capture (~10M) containing the PMT pid 13
Hi,
I did check the TS stream with dvbsnoop and it is not containing corrupted TS
packets.
Apparently VDR is able to parse the PMT the first time the data buffer is
used. Then, it seems to loose the sync inside the payload.
I have attached a raw TS capture (~10M) containing the PMT pid 132 wh
22 matches
Mail list logo
