ons are there.
Good luck!
Regards,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
disecq
handling code within VDR as part of the Unicable update. Klaus could
you point me in the direction of what might have changed such that
these plugins no longer work and I will do my best to implement a fix.
Thanks very much for your help,
Regards,
Morfsta
On Tue, Dec 20, 2011 at 9:23 AM, Klaus Schmidinger
wrote:
> On 20.12.2011 09:49, Morfsta wrote:
> I don't see what could have changed in version 1.7.21 that might
> have an impact on this.
> "Satellite Channel Routing" (SCR) and "Device Bonding" (unicable)
On Tue, Dec 20, 2011 at 9:20 AM, Ales Jurik wrote:
>
> I also had to implement changes into Seppo patch for gotoxx - so maybe
> you could take a look into the latest version of gotoxx patch for
> 1.7.22, it is working without problems, hope it helps.
>
> You could find the patch at
> http://www.li
ther ideas?
Kind Regards,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
d, for example by femon or other plugins that need
to communicate with the required physical adapter #?
Thanks,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I'll bite three.
There is no summer in England, so no excuses for all this quietness
On Mon, Aug 6, 2012 at 4:14 PM, Oliver Schinagl wrote:
> I'll bite too :)
>
> I'm still 'waiting' for comments on my patch that I posted on 23-07-12;
> 11:21
>
> [PATCH] Make RGYB buttons customizable (attemp
n one of these too and given the work done so far on VOMP
and XBMC how difficult it would be to create an output plugin?
Cheers,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
changed in VDR, or perhaps the driver that means this no
longer works the way that it used to? I've looked through the HISTORY and
can't spot anything that stands out.
Thank for any help you can provide.
Kind Regards,
Morfsta
___
vdr mailing lis
On Fri, Oct 12, 2012 at 3:31 PM, Klaus Schmidinger
wrote:
>
> I'm afraid I can't think of anything obvious.
> Could you try using versions 1.7.13 thru 1.7.27 in turn to see
> which version introduced the problem?
>
Thanks Klaus, I will dig into it.
I suspect it could be related to some changes i
might look at trying to hack up a plugin if I get some time.
Thanks,
Morfsta
[1] http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
le to give me would be much appreciated and
would hopefully move this plugin forward. I'm not a C++ developer,
more a code hacker so please be gentle! ;-)
Many Thanks,
Morfsta
On Mon, Oct 15, 2012 at 9:29 AM, Morfsta wrote:
> On Fri, Oct 12, 2012 at 3:31 PM, Klaus Schmidinger
> wrot
On Thu, Oct 25, 2012 at 3:32 PM, Klaus Schmidinger
wrote:
>
> What "ChannelMonitor"?
> There is no such thing in VDR.
>
Hi Klaus,
Thanks for getting back to me.
Sorry, I meant cStatusMonitor::ChannelSwitch.
> cDvbTuner is local to dvbdevice.c, and cDvbTuner::ExecuteDiseqc() is
> private.
> So
Hi,
The third version of my plugin rotorng has been released here: -
http://projects.vdr-developer.org/projects/plg-rotor-ng/files
This plugin allows you to steer a disecq 1.1 rotor, find satellites
with a signal meter and to store them at given positions. It also has
a rudimentary channel scann
On Thu, Oct 25, 2012 at 5:42 PM, Lars Hanisch wrote:
> You've forgotten the wrap the definition of ChannelSwitch into #if's:
>
> --- a/rotorng.c
> +++ b/rotorng.c
> @@ -333,7 +333,11 @@
>int last_position_shown;
>bool transfer;
> protected:
> +#if VDRVERSNUM >= 10726
>virtual void Ch
On Fri, Oct 26, 2012 at 7:59 AM, Lars Hanisch wrote:
>> There are two places: one in the class definition and one a few lines below
>> that. Just search for "ChannelSwitch"... :)
> Line 336 and line 347.
Oops. Thanks for the help, I'll update and release a fixed version.
Thanks
_
Okay, updated version (0.3.1) has been uploaded to the VDR Projects site.
I have also fixed all the compilation warnings (at last)!
Thanks
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Tue, Jan 1, 2013 at 8:52 PM, Lars Hanisch wrote:
> This is an invitation: Please create more posts in english at vdr-portal! If
> a critical mass is passed it will be
> easier for the ones coming past us. Sure there's only a small "international"
> part, but it is there. And of course there
> I use XVDR and miss in some ways the plain old Vanilla VDR "GUI".
> Maybe its possible with configuration, but I would like to "push"
> XBMC to the background and be able to use all remote keys in XVDR as if I
> was working natively with VDR, then maybe a single key press to get back to
> "normal
On Fri, Feb 8, 2013 at 11:38 AM, Torgeir Veimo wrote:
> The purpose for me would be to run a VDR client on a raspberry pi.
> XBMC already runs there and I've used it a bit with VNSI, but until I
> can get the native GUI running on XBMC, it's not WAF ready. I assume
> whenever libxine is finally ab
On Tue, Feb 19, 2013 at 5:03 PM, YUP wrote:
> Hey Morfsta,
> Vdr 2.0.0 is coming, it's time to update your plugin. BTW, take a look into
> this issue http://projects.vdr-developer.org/issues/740 . The same error I
> discovered when compiled against vdr-1.7.38.
> Regards,
>
On Thu, Nov 28, 2013 at 8:48 PM, Frank Schmirler wrote:
> Hi,
>
> it was about time to publish a streamdev release for VDR 2.0.
> Streamdev-0.6.1
> is now available from
> http://projects.vdr-developer.org/projects/plg-streamdev/files. The server
> plugin requires at least VDR 1.7.25. The client
gt; impact.
> The fact that streamdev uses TCP to transmit the stream might be an
> additional
> problem here as packet loss leads to retransmission.
>
> As Morfsta is able to view HD recordings while he seems to get problems
> even
> with SD live TV, bandwith alone sure
On Fri, Dec 6, 2013 at 8:55 AM, Frank Schmirler wrote:
>
> Can you try adding the sleep command as suggested in my first answer? Maybe
> try a short delay (e.g. 500 ms) and a long delay (e.g. 3000 ms). If it
> helps,
> I'll add a setup option.
>
>
Hi Frank,
Putting in a delay of 500ms definitely
kdvb process
entering the D state.
I worked around it for now by using dvbtune to tune the adapter to an
initial DVB-T frequency on boot up (init script which starts before VDR),
but they say they are fixing it in the next driver release.
Thanks,
Morfsta
On Thu, Jun 12, 2014 at 9:46 PM, Milos K
her day on BBC Three which was broadcast in 5.1 which exhibits the
problem.
Cheers,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Thu, Sep 17, 2015 at 8:58 PM, Karim wrote:
> Hi,
>
> I use TBS6280 (dual tuner, pci-e) from Turbosight in dvb-t mode (no dvb-t2
> signal here): good card, not expensive and great technical support. Newer
> model is TBS 6281 :
>
> http://www.linuxtv.org/wiki/index.php/TBS6281
>
> I hope it help
Hi Werner,
Were there problems?
Morfsta
On 2/23/07, Dr. Werner Fink <[EMAIL PROTECTED]> wrote:
On Thu, Feb 22, 2007 at 06:18:11PM +, Morfsta wrote:
> Hi Werner,
>
> Any idea when you will be able to release the new firmware for testing?
I'm just testing the stuf
between my budget
Nova-T and FF DVB-S. Could you let me know how you turned it off and if
possible post a patch to do it?
Kind Regards,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
and recordings.
I'll see if my sync problems in transfer mode improve with this new
implementation and report back. Georg / Reinhard if you would like me to do
any additional testing or debugging let me know.
Kind Regards,
Morfsta
___
vdr mailing li
On 3/28/07, Georg Acher <[EMAIL PROTECTED]> wrote:
Well, maybe there will be one later...
Sign me up to one of those... I would love something like that for VDR.
Its quite frustrating that there STILL isn't a FF DVB-S2 solution that
supports hardware decoding of MPEG2/4/AVC with HDMI output..
Hi,
xmltv2vdr version 1.0.7 has now been released on the VDR FTP site.
It can be found at: -
ftp://ftp.cadsoft.de/vdr/Tools/xmltv2vdr-1.0.7.tar.gz
Changes this version: -
* Code updates and speed improvements, with thanks to Sebastien Lucas
Please let me know any comments or problems,
Regar
the channel settings for the
other channels and they are all correct, so I can only guess that
there is a bug in VDR that prevents these channels from being
displayed.
The problem exists without any additional plugins in use.
Regards,
Morfsta
___
vdr
channels the VDR OSD looked terrible (very blockly
looking) and playing with the settings in the xine plugin did not make
it better. Any recommendations on improving this? When using MPEG4
(i.e. software accel) the OSD was fine.
Any thoughts on this anyone and/or Reinhard?
Cheers
Morfsta
On 10
%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Cpu1 : 66.2%us, 1.0%sy, 0.0%ni, 32.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2063240k total, 1537640k used, 525600k free, 593820k buffers
Swap: 1100412k total,0k used, 1100412k free, 494472k cached
PID USER PR NI VIRT RES
On 10/25/07, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Is there a special reason why you use -V xshm and not -V xv? The later
> would do colorspace transformation in hardware.
>
I was just changing settings - I did have xxmc on, but it didn't make
any difference.
> > HD recordings also show th
nge because clips
before and after this preview snippet were fine again so it must be
something to do with this particular HD recording as part of the
preview...
Here is a link to a short recording (26Mb) demonstrating the problem: -
http://www.megaupload.com/?d=72LCAI2P
Regards,
Morfsta
On Oct 31, 2007 11:51 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Please have a look at the patches referenced at
> http://www.vdr-portal.de/board/thread.php?postid=664938#post664938
>
> With theses patches, your recording looks much better.
Thanks for your help and assistance Reinhard - I rea
o the 5th in the setup I then don't get any
output via the mpeg2 decoder either, proving that the 5th device is
also not being picked up.
Is there a restriction of frontends in VDR and if so, how can I up it?
Regards,
Morfsta
___
vdr mailin
On Nov 9, 2007 2:06 PM, Lauri Tischler <[EMAIL PROTECTED]> wrote:
> Try to increase MAXDVBDEVICES in dvbdevice.h
>
That got it! Thanks Lauri! :-)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
rible!
Please implement these changes to VDR to ensure that those who would
like to see HD within VDR can remain with their favourite choice of
open source PVR software.
I hope this helps,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
he
problem might be.
Regards,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
e any mods or
dependencies that are required to get this working?
I have tested the AC3 output with mplayer and xine and it is working
properly with XVIDs with AC3 soundtrack. It also works with the
bitstreamout plugin but the sync is not good.
TIA,
Mo
, 0, 7, 0, 0x97d390
this results in a picture, but artifacting on motion and eventually in a crash.
I have a short clip recorded if you would like to work on it and need
an example?
Please let me know,
Kind Regards,
Morfsta
On Jan 1, 2008 10:15 PM, Reinhard Nissl <[EMAIL PROTECTED]>
dr -Pxine
Start xine with: -
xine -f -I -V xv -A alsa --verbose=2 --post vdr_video --post vdr_audio -Dtvtime:
method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 vdr://t
mp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log 2>&1
Enjoy HD channels!
HTH,
Morfsta
S2 is required for channel4 HD, not for BBC HD - they are running
MPEG4 DVB-S at the moment.
See http://www.lyngsat.com/hd/28east.html
On Jan 2, 2008 12:04 PM, Torgeir Veimo <[EMAIL PROTECTED]> wrote:
> Is S2 currently required to get BBC HD or CH4 HD? I've got a dvb-s card set
> up against Sky F
> Is there a way to use more than a card with it when only one is DVB-S2
> capable ?
I just dropped a mail to Reinhard asking the same question. My
"production" system runs 2 DVB-T cards that currently don't work with
vdr-1.5.12 / multiproto. I would love to start using it full time but
until I ca
> Over here, tests were done on STB0899, STV0299 and TDA10021 based
> all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
There is something wrong then as it does not tune in vdr-1.5.12. I
have the following DVB-T frontends: -
[ 9539.157598] DVB: registering frontend 1 (Conex
A diff of cx22702.c, cx22702.h and cx22702.mod.c between the normal hg
of v4l-dvb and the multiproto tree reveals no differences...
Almost the same for tda1004x (tda1004x.c makes reference to an include
for moduleparam.h) Is it these frontend modules that are the relevant
ones?
> If the driver wh
On Jan 3, 2008 5:40 PM, Magnus Hörlin <[EMAIL PROTECTED]> wrote:
> Hi. Big thanks to Reinhard, Manu, Claus and others who has made this
> possible. Using the old multiproto tree from 2007-10-25 I have SVT HD
> (swedish) working quite well with an S2-3200 on a 2.3GHz AMD BE-2400. My
> problem is tha
This problem keeps coming up over again, but for some reason Reinhard
and Manu don't seem to want to talk about it.
I do not understand why you can't use DVB-T with DVB-S2 using the
multiproto drivers and VDR, but I doubt it can be much of a problem.
I started modifying VDR to use the old API cal
Hi,
Thanks for speaking with Marco, Reinhard - its appreciated.
Unfortunately, the patch does not fix the problem. Still no picture on
DVB-T transmissions.
Regards
On Jan 11, 2008 7:21 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Reinhard Nissl schrieb:
>
> > So it seems to me that e
On Jan 12, 2008 3:37 PM, Stefan Lucke <[EMAIL PROTECTED]> wrote:
> Same here.
> Which DVB-T device do you use ? I'm using a cinergyT2.
>
> Ioctl's for this device are not passed
> via the common frontend interface. The new "API" has to get
> integrated into the cinergyT2 driver or client programs l
> I spent the whole evening with Manu looking through the emulation
> layer and cannot see any obvious errors in the DVB-T case.
>
Thank-you very much for your time.
> Then use VDR-1.4.x (limited to only one device) and tune to a
> certain DVB-T channel. Have a look what the driver reports (see
>
> Please report the relevant channel from VDR-1.4.x' channel.conf
> and from VDR-1.5.12's channel.conf too.
>
1.4.x: -
BBC ONE;BBC:73000:I0C34D34M16B8T2G32Y0:T:27500:600:601=eng,602=eng:0:0:4165:
9018:4101:0
1.5.12: -
BBC ONE;BBC:73000:A0I0C34D34M16B8T2G32Y0P0:T:27500:600:601=eng,602=en
Has anyone managed to get the signal strength, SNR and lock functions
working with multiproto and rotor 1.5.12? I took a look at menu.c and
compared it with szap2 but couldn't find much difference!
On Jan 11, 2008 10:21 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> lucian orasanu schrieb
ople are going to be very happy!
Cheers,
Morfsta
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Well, I think there has been a number of fixes (e.g. to the speedup
patches and the nit.c file) that probably warrants a new patch for
1.5.13 that incorporates them all. I'm sure Reinhard will do that when
he has a moment, he probably is taking a well deserved break after
looking into so many issue
sorry for the double post, but let's also not forget multiproto,
TT3200 and HVR4000 status! There is quite a lot to have to keep track
of.
PS Manu, are you considering implementing the HVR4000 patch directly
into the multiproto tree for direct support?
Thanks
On Jan 16, 2008 3:01 PM, Mo
Hi,
I see a lot of channels that are not supported in VDR because of
unsupported spatial direct mode in FFMPEG.
This has probably been covered before (mostly in German!) but Reinhard
could you explain what is spatial direct mode and why is it currently
not covered in FFMPEG. Is it quite complex t
Hi,
I was testing VDR with the H264 channels in Norway. It exhibits the
same kind of artifacting I reported earlier with BBC HD channels (not
spatial direct mode).
I have uploaded an example to: -
http://www.megaupload.com/?d=7N0J2G1L
HTH,
Morfsta
Hi,
Igor, would it be possible to do this? I heard CoreAVC is pretty good
with mythtv and HD, so if we could get it running with lib-xine that
would be fantastic!
Cheers,
Morfsta
On Jan 18, 2008 11:06 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Morfsta schrieb:
>
I'm having the same problem. I've put the .ax file in /usr/lib/win32,
registed the key in ~/.mplayer/registry32 and then done: -
# dshowserver -c CoreAVCDecoder.ax -s 1280x720 -g
09571a4b-f1fe-4c60-9760de6d310c7c31 -b 12 -f 0x34363248 -o 0x30323449
shm:/dshow_shm.(null)
sem1:/dshow_sem1.(null)
sem2
I have been using xine-1.2 from the Mercurial distribution, but it
still creates a plugin directory called 1.1.9 and sometimes 1.1.90.
I just can't get it to work!
Here's the steps I have taken: -
Running on Ubuntu 7.10 x86_64.
Downloaded xine-lib-1.2 from hg
Patched with xine.patch from google
See attached xine.log
On Jan 21, 2008 7:30 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Tried vdr-xine - this shows a black screen with audio but no video -
> > message says it can't find a plugin to handle the video.
>
> show verbose-log - xine --verbose=2
>
>
> ___
complete
solution - but so many channels use spatial direct then it looks like
the kludge using CoreAVC might still be the only way at the moment.
:-(
On Jan 20, 2008 11:16 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Morfsta schrieb:
>
>
> > I was testing VD
Same problem. I'm not sure that the w32 codec support is being built
in xine. If I look in src/libw32dll I see: -
:~/dshow/xine-lib-1.2/src/libw32dll# ls
common.cMakefile Makefile.in qtx wine
DirectShow Makefile.am nal_parser.c w32codec.c
dmo Makefile.am
but the
coreavc patch adds it..
Any ideas?
On Jan 21, 2008 2:42 PM, Darren Salt <[EMAIL PROTECTED]> wrote:
> I demand that Morfsta may or may not have written...
>
> > I have been using xine-1.2 from the Mercurial distribution, but it
> > still creates a plugin dire
y trashing my 64bit VDR box just to play around with
CoreAVC - it runs quite a few other bits and pieces.
On Jan 21, 2008 3:16 PM, Darren Salt <[EMAIL PROTECTED]> wrote:
> I demand that Morfsta may or may not have written...
>
> [snip]
> > However, I get this error message
It was in the tar file that Per posted earlier of his xine-lib!
On Jan 21, 2008 4:06 PM, Darren Salt <[EMAIL PROTECTED]> wrote:
> I demand that Morfsta may or may not have written...
>
> > Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
> > is
spatial direct mode.
Has anyone managed to get the xinelibout patch working so that VDR
doesn't coredump on startup?
On Jan 21, 2008 5:45 PM, VDR User <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008 7:01 AM, Morfsta <[EMAIL PROTECTED]> wrote:
> > However, I get this
Hey, it works ... Sort of. Anyone else having the "green bar" problem?
I get a large green bar across the bottom of the screen and four fuzzy
representations of the picture above it on: -
BBC HD
DigitalAlb HD-1
DigitalAlb HD-2
SVT HD
However, Channel 4 HD and a number of other HD channels work fi
hmmm, I've been looking into the demux_mpeg_pes function in xine,
isn't the height and width stored in the transport stream within the
pes? I tried to adapt the code that shows the resolution in femon to
work on the stream in demux_mpeg_pes but not had much success so far..
:-(
Do you have to pars
of
function for H264 (I looked in libavcodec and the code looks a bit
more complex!), or spot what I am doing wrong here?
TIA
On Jan 23, 2008 11:50 AM, Morfsta <[EMAIL PROTECTED]> wrote:
> hmmm, I've been looking into the demux_mpeg_pes function in xine,
> isn't the height and
have the
coding skills to be able to finish the job.. :-(
On Jan 24, 2008 7:31 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Morfsta schrieb:
>
>
> > OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
> >
> > static int32_t GetVideo
On Jan 24, 2008 9:54 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Typically, a SPS is found in the same memory block which starts
> with an AUD for an "I frame". From VDR's remux.c,
> cRemux::ScanVideoPacket():
>
> if (!p[-2] && !p[-1]) { // found 0x01
> if (h264
Hi Reinhard,
I have just tried the new DVB-S2 patches for VDR-1.5.13 and the
additional addon.
Now I cannot tune to a DVB-S2 channel and I get a "Channel Not
Available". H264 on DVB-S works fine.
I have a HVR4000 and a FF Technotrend. The response still appears when
I remove the use of the Tech
> have a look at the patch Gregoire provided starting at line 246.
> You may want to look for "DVBFE_DELSYS_DVBS2" which is what I think
> you'll need.
>
> What version of the HVR4000 patch/driver are you using if not the same
> as Gregoire? Is it more recent?
I think it is more recent. It was on
> Hi Morfsta,
>
> which addon patch are you using? The h264 autodetection posted on
> January 20th?
>
That's correct..
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Me too - it seems crazy that the development of DVB into Linux is
being held up my personal arguments. It would be nice for these to be
put aside for the greater good!
2008/1/25 Igor <[EMAIL PROTECTED]>:
> > I am really really really sad on how bad this card gets into linux :-(
>
> I'm too :(
>
>
I have tried your patch Gregoire and it doesn't work here (HVR4000
Lite). When tuning to a DVB-S or DVB-S2 I get a black screen. When
using the original patch everything works fine (on previous vdr-1.5.12
patches)
> If you use the patch from
> http://www.linuxtv.org/pipermail/linux-dvb/2008-Januar
No, when I apply your changes to the multiproto tree and install,
DVB-S / DVB-S2 doesn't work at all - all I get is a black screen on
DVB-S/2 delivered channels. Reverting back to the original patch works
fine.
What was the change you had to make to mark the HVR4000 as a DVB-S2
capable device? If
It's nothing to do with disecq, more that the card is not declared as
S2 capable and the patch you release does not show DVB-S or S2
channels with my HVR4000 lite (Nova-S2).
How do you declare a card DVB-S2 capable? This is the bit I need to
add to cx24116.c in the current multiproto to make it wo
> Have a look at Gregoire's initial discussion with Reinhard here:
> http://permalink.gmane.org/gmane.linux.vdr/34901
>
> Maybe the mentioned debug code helps to get this sorted.
> I don't have a HVR4000 here, with a TT3200 it's working out of the box...
Thanks for the info, I fixed Holger's origi
> I guess so, but I'm not going to ;-)
> This new driver appears to be stable enough now - at least I've
> been using it for a few days now without problems.
>
The new driver is fine, but what you might find is that new card and
features being released into the stock v4l mercurial tree aren't bein
I got the following error when compiling 1.5.14 with h264 patch
applied and your VDR diff from the tgz: -
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD
-DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE
-DVIDEODIR=\"/video\" -DCONFDIR=\"/video\"
-DPLUGI
On Jan 28, 2008 10:34 AM, Morfsta <[EMAIL PROTECTED]> wrote:
> I got the following error when compiling 1.5.14 with h264 patch
> applied and your VDR diff from the tgz: -
>
> g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD
> -DLIRC_DEVICE=\"/dev/li
n order so I can compare the difference between
the two cards soon.
Regards,
Morfsta
On Jan 28, 2008 1:46 AM, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Morfsta wrote:
> >> I guess so, but I'm not going to ;-)
> >> This new driver appears to be stable enough now -
On Jan 28, 2008 5:15 PM, Darren Salt
<[EMAIL PROTECTED]> pedantically wrote:
> c++filt says "cDevice::SwitchChannel(cChannel const*, cDevice*)". Maybe you
> need to recompile something...?
>
> [snip ; don't top post]
Nope, it's all compiled - just doublechecked with fresh source: -
vdr-1.5.14
vd
Here's an update on this for those interested in H264 and VDR.
I brought up the problems with Spatial Direct Mode and FFMPEG on their
mailing list and Loren has implemented it within the code. When tuning
to one of the affected channels I no longer get messages saying that
spatial direct is not im
No! Let's not lose momentum on VDR moving forward. I am intrigued as
to whether this move towards TS will improve performance for my H264
channels.
BTW, vompserver (CVS) / epgsearch etc all work with latest VDR and
multiproto. I use it here.
On Feb 3, 2008 1:25 PM, Klaus Schmidinger <[EMAIL PROTE
On Feb 6, 2008 10:12 AM, Travel Factory S.r.l. <[EMAIL PROTECTED]> wrote:
>
> 1.6 now
>
> I want to add that about every 12 months I rebuild my vdr pc and
> everytime I spend days trying to have it working !
Isn't that the fun part of it? I don't watch much TV, but I like
fiddling and tuning
On Feb 6, 2008 9:58 AM, Laz <[EMAIL PROTECTED]> wrote:
> I don't think MPEG4 decoding will be supported in this way for a very long
> time, unless Via have changed their attitudes. (Not really bothered
> looking into this because HD is years off in the UK where I am, unless
> you fork out lots to S
On Feb 7, 2008 4:27 PM, Jouni Karvo <[EMAIL PROTECTED]> wrote:
> The --stdctl option causes xine to crash if it is used when starting
> from the script...
>
I found the same problem without the --stdctl flag (is it default?)
and reported it to xine-devel. The Hg version of xine-lib cannot start
f
On Feb 8, 2008 10:44 AM, Arthur Konovalov <[EMAIL PROTECTED]> wrote:
>
> Hi!
> Do You solved this problem?
> I have same situation.
>
Nope, I had to roll back to an earlier version of rotor that I patched myself.
___
vdr mailing list
vdr@linuxtv.org
ht
On Feb 11, 2008 9:09 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> In case the decoder doesn't provide the image aspect ratio (and
> it looks like that as you had to provide the image size too),
> you'll have to extract it from the H.264 data yourself (as you
> did already for the image size).
>
On Feb 11, 2008 8:09 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Anyway, does the decoder tell you the aspect ratio anywhere?
>
> The aspect ratio must be passed to get_frame(). When the frame
> has the correct aspect ratio set, xine-lib will take care to
> setup the video scaler to stretch fo
On Feb 11, 2008 6:31 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Just a guess: maybe the above bih.biXPelsPerMeter and
> bih.biYPelsPerMeter can be used to set the pixel aspect ratio
> which will then in turn yield the frame aspect ratio when applied
> to the coded frame size. So pixel aspect
OK, I spent a bit of time looking at this today as there doesn't seem
to be much movement on FFMPEG and H264 at the moment.
I have managed to get xine to now detect the H264 video size prior to
starting up the CoreAVC decoder and set the size within the
initialisation function: -
memset(&bi
> Well, the spec tells you that aspect_ratio_idc 11 means a sample
> (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080
> pixels so the frame aspect ratio yields:
>
>far = 1.3636 * 1440 / 1080 = 1.8181
>
Could you give me a link to where you found that please?
Also, I just disc
1 - 100 of 186 matches
Mail list logo
