[vdr] [ANNOUNCE] vdr-rotorng-0.1.0

[Morfsta]

Hi,

The first version of my plugin rotorng has been released here: -

http://projects.vdr-developer.org/projects/plg-rotor-ng

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 scanner which works with both DVB-S and S2. Much
of this code has been merged together from the existing actuator and
rotor plugins, so thanks to the developers of those for their work.

This is an alpha version, though it has been stable on my own system
for a few months. I haven't been able to make as much additional
progress on it as I'd like since my previous email due to work and
holidays so I'm releasing it as is for the moment.

Please see the README file, there are a number of functions within the
user interface that aren't fully implemented or working but the main
functions are there.

Good luck!

Regards,

Morfsta

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

[vdr] Rotor / Rotor-NG not working with latest VDR

[Morfsta]

Hi,

I have just upgraded my VDR system to yavdr 0.4.0 which uses VDR
1.7.21 and I notice that the Rotor plugin and my own Rotor-ng plugin
no longer drive the rotor using any of the functions in the menu.

Is anyone else seeing this too?

I think that this could be because of recent changes to 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

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

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[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)
> were implemented in later versions.

I think the yavdr VDR distribution has the Unicable patch applied to
1.7.21, there is an option "log LNB usage" in the LNB menu and there
is a # Unicable set of entries in the disecq.conf file.

The rotor and rotorng plugin use: -

  if (ActuatorDevice->SendDiseqcCmd(switch_cmds[KNr]))

to send the disecq sequence to move the rotor where KNr is the device
number with the rotor atached.

Has this means to send the disecqc command now changed as part of
unicable support both in core VDR 1.7.21 and as part of the patch?

Kind Regards,

Morfsta

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

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Morfsta]

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.linuxtv.org/pipermail/vdr/2011-December/025511.html

I don't know the previous patch, what did you have to change?

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

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Morfsta]

>  Please install the latest updates with:
> $ sudo apt-get update
> $ sudo apt-get dist-upgrade
>
>  There was an error in the vdr-plugin dynamite's Makefile.

Hi there,

Thanks for your help, but the rotor / rotorng plugins still don't work
after the update.

Any other ideas?

Kind Regards,

Morfsta

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

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Morfsta]

On Sun, Dec 25, 2011 at 12:32 PM, ilia mane  wrote:
> Thank you Lars Hanisch it work for me.I just disable the dynamite plugin in
> /etc/vdr/plugins/order.conf and the rotorng plugin work now.

Just returned from the Christmas period, merry Christmas all!

Then it looks like dynamite is the problem. Rotorng has a setup option
for the satellite adapter that is connected to the rotor and normally
it is set to 1,2,3 etc depending on the allocated adapter # at boot
up. I guess this might now change with this virtual proxy for the
adapter that is setup by dynamite?

How is this handled, 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

Re: [vdr] Quiet times...

[Morfsta]

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 (attempt 2)
>
>
> On 06-08-12 09:04, Klaus Schmidinger wrote:
>
>> It's been rather quiet on the VDR mailing list lately, but I guess
>> everybody (like myself) is enjoying the summer and engaged in outdoor
>> activities...
>>
>> Klaus
>>
>> __**_
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr
>>
>
>
> __**_
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] VDR on Raspberry Pi

[Morfsta]

Hi,

Now that Raspberry Pis are quite common, cheap (~£25) and
easily acquired (I received my order within 2 days from Farnell) has anyone
considered whether it might be feasible to put together an output plugin
for VDR for it? It is now possible to play MPEG-2 (with a codec license
costing £2.40) as well as 1080p H.264 with hardware acceleration.

There is work on VOMP (previously on Hauppauge MediaMVP) to work as a VDR
client on the Pi and as far as I can see quite a lot of progress has been
made. I'm wondering whether it would be possible to run VDR with HDMI video
/ audio output on 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

[vdr] rotorng broken with 1.7.27 - any changes to vdr core / kernel?

[Morfsta]

Hi Klaus,

As part of a recent upgrade from vdr-1.7.22 to 1.7.27 within yavdr I've
seen that my rotorng plugin doesn't work anymore and this is shown in the
syslog when I try to send a disecq command: -

 vdr: [8287] ERROR: frontend 1/0: Invalid argument

The plugin includes a patch to the vdr src which adds another method to
cDvbTuner: -

+bool cDvbTuner::SendDiseqcCmd(dvb_diseqc_master_cmd cmd)
+{
+  cMutexLock MutexLock(&mutex);
+  if ((frontendType!=SYS_DVBS2 && frontendType!=SYS_DVBS) || SendDiseqc)
+return false;
+  diseqc_cmd=cmd;
+  SendDiseqc=true;
+  newSet.Broadcast();
+  return true;
+}
and modifies cDvbTuner::GetFrontendStatus with: -

  cMutexLock MutexLock(&mutex);
+if (SendDiseqc) {
+   CHECK(ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD,
&diseqc_cmd));
+   SendDiseqc=false;
+   }
Has anything 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 list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] rotorng broken with 1.7.27 - any changes to vdr core / kernel?

[Morfsta]

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 in YAVDR but I will
build a vanilla VDR(s) at some stage and test it with that too.

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

[vdr] HDMI CEC support in VDR with Pulse Eight Adapter

[Morfsta]

Hi,

Has anyone had any experience of working with the Pulse Eight USB to
HDMI CEC adapter [1] with controlling VDR when using a graphics card
or other non-CEC device as an output?

It seems that support for this has been implemented within Myth TV and
XBMC, but I haven't seen anything on VDR.

It would be very useful to be able to control VDR from your TV handset
and also be able to power on / off VDR with all other HDMI CEC
devices.

I wondered if anyone has started work on a CEC VDR PLUGIN or whether
it should be implemented within the core itself, alongside LIRC and
KBD?

If not, 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

Re: [vdr] rotorng broken with 1.7.27 - any changes to vdr core / kernel?

[Morfsta]

Hi Klaus,

I fixed the problem I had with rotorng, it was a problem with a YAVDR
patch and also your changes to ChannelMonitor.

I'm trying to get my head around the VDR function
cDVBTuner::ExecuteDiseqc to try and remove the requirement for a patch
for VDR core in future.

If I would like to send a FE_DISEQC_SEND_MASTER_CMD from a plugin, how
would I write the code to do this from inside the plugin? Is this
possible?

I am trying to setup a cDiseqc object but don't know how to build it
just to be able to send a raw command of type dvb_diseqc_master_cmd.

Any help you would be able 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
>  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 in YAVDR but I will
> build a vanilla VDR(s) at some stage and test it with that too.

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

Re: [vdr] rotorng broken with 1.7.27 - any changes to vdr core / kernel?

[Morfsta]

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 I'm afraid you can't do this without a patch.

Would it be possibe to update this in a later version of VDR please
Klaus? Given that there is currently no multiple satellite support in
code VDR (there should be really - many people would appreciate this),
then it would make sense to at least permit a plugin to be able to
move the dish with diseqc commands.

Kind Regards

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

[vdr] [ANNOUNCE] vdr-rotorng-0.3

[Morfsta]

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 scanner which works with both DVB-S and S2. Much
of this code has been merged together from the existing actuator and
rotor plugins, so thanks to the developers of those for their work.

Please see the README file, there are a number of functions within the
user interface that aren't fully implemented or working but the main
functions are there.

Changes since previous version: -

2012-10-11: Version 0.2

- updated sat card store value in config, always resetting
- fixed issue with change implemented in 1.7.23 (thanks to Ihanisch)

2012-10-21: Version 0.3

- Added patch for vdr-1.7.27 onwards, old patch for VDR still exists also.
- Fixed problem with cStatusMonitor::ChannelSwitch call introduced in
VDR 1.7.26 so dish moves on channel change

Good luck!

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

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Morfsta]

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 ChannelSwitch(const cDevice *Device, int ChannelNumber, bool 
> LiveView);
> +#else
> +  virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber);
> +#endif
>  public:
>cStatusMonitor();
>  };
>

Are you sure? Its definitely in my copy and seems to be in the one on
the projects site.

Thanks

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

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Morfsta]

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

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

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Morfsta]

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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Morfsta]

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
> will be "idiots", you got them everywhere, even at this mailing list. :)
>  I promise if I have something valuable to say to an question asked in 
> english I will give my best and will answer it.
>

I can second Lars here, following my English post on vdr-portal we
worked together to fix rotorng with later versions of VDR in yavdr
0.5.0.

Perhaps a sticky at the top of the forum discussing and encouraging
the use of English for non-German speaking users would help and giving
some guidance on the best way to approach it, so as to avoid flames.

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

Re: [vdr] Does anyone see this or is the VDR mailing list broken?

[Morfsta]

> 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" XBMC functionality. Its a WAF thing.

Look at yavdr, it provides that but the other way around and for me
that is preferable as we watch TV / recordings much more than using
XBMC to listen to music or watch videos.

You use vanilla VDR as the base, then when you need XBMC you call it
either via the desktop/mouse or via the VDR menu
(Applications/Media/XBMC). When you exit XBMC it seamlessly goes back
into VDR.

I found that remote control and sound (including AC3 and DTS) work
seamlessly out of the box now with the latest version.

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

Re: [vdr] Does anyone see this or is the VDR mailing list broken?

[Morfsta]

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 able to make use of the hw accelerated
> decoding, xinelibplugin will supply what's needed.

Yes, I have a few Pis too, I posted awhile ago as to whether anyone
had had any joy with getting a VDR client running on it but didn't get
a response.

I would much prefer to use a Pi as a client, rather than run it
through XBMC which seems very laggy as a PVR on a Pi.

Is anyone working on xine acceleration for the Pi do you know?

Thanks

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

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Morfsta]

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,
> Yarema

That issue was fixed in version 0.3.1. Are there any further changes
that are required for VDR 2.0.0?

Regards,

Morfsta

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

Re: [vdr] [Announce] streamdev-0.6.1

[Morfsta]

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 plugin should even work
> with
> VDR 1.6. On VDR version up to 1.7.33 the Makefiles have to be replaced by
> the
> old versions which are shipped along with the source.
>

Hi Frank,

Thanks for all your hard work with streamdev.

I have been using the VDR Samsung SmartTV VDR plugin which relies on
streamdev for transfer of live channels over the network and it uses its
own proprietary implementation for the transfer of recordings. I have tried
using it over wifi as well as powerline. The recordings (SD and HD) play
flawlessly over the network, however the streaming of live channels using
streamdev results in regular buffering (SD and HD) and eventually the TV
just gives up playing them. Is there any buffer options or other
configurable settings within streamdev that might alleviate this problem? I
can't seem to find much that would help.

Look forward to hearing from you and TIA.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [Announce] streamdev-0.6.1

[Morfsta]

On Mon, Dec 2, 2013 at 11:39 AM, Frank Schmirler  wrote:

> Hi,
>
> On Sat, 30 Nov 2013 16:36:14 -0800, VDR User wrote
> > If his recordings stream fine and the problem is only with live tv,
> > how could that possibly be network congestion?
>
> I should have written "temporary network congestion".
>
> When streaming a recording, the client can pre-buffer data to prevent
> buffer
> underruns. With live TV this is not possible as data becomes available
> just in
> time. So fluctuations in the available network bandwidth could have an
> 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 surely isn't the problem. But temporary
> congestion or high packet loss due to e.g. interference sound reasonable
> to me.
>
> Regards,
> Frank
>
>
Difficult to trace these problems isn't it? I get a sustained transfer rate
when copying files over of around 15MB/sec - so I would have thought this
would be ample for SD and HD streaming?

I was just surprised to find very few options to play with in streamdev
with regard to buffer sizes etc. I presume this is by design and the way in
which it works?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [Announce] streamdev-0.6.1

[Morfsta]

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 improves things - its been streaming
awhile without any buffering / drop outs.

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

Re: [vdr] TBS6285 slow onscreen menu

[Morfsta]

Hi,

I can confirm this issue and also reported this to TBS last week (hadn't
seen this thread) with regard to my dual DVB-T2 card (TBS6281) and worked
with them on the problem.  The issue is the second adapter provided by the
card being untuned on bootup and VDR start and the associated 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 Kapoun  wrote:

> Hi all,
>  I am solving it with TBS support. High CPU load is caused by untuned
> (unused) adapters.
>
> After each:
>
> Jun 12 21:39:23 streamer vdr: [3860] frontend 2/0 timed out while tuning
> to channel 0, tp 76
>
> CPUload += 1; :-}
>
> When all adapters are tuned everything is OK and load is low, for example
> 0.3.
>
> Milos
>
> Dne 2014-06-12 16:31, Milos Kapoun napsal:
>
>  Thank you for your replay. It is good to see that card is working.
>> Could you send driver version?
>>
>> Milos
>>
>>
>> Dne 2014-06-12 16:01, Pasi Juppo napsal:
>>
>>> I have TBS6285 card and been using it for few months without
>>> problems. There was an issue with remote control but with lirc
>>> parameter change (delay changes to get rid of repetition) it got
>>> fixed. The card and drivers have been working pretty much flawlessly
>>> in my case (yavdr distro).
>>>
>>> Pasi
>>>
>>
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] VDR / Softhddevice Freeview HD Multichannel HE-AAC Audio Handling

[Morfsta]

Hi,

I'm using vdr 2.0.6 (2.0.6-6yavdr1) and softhddevice 0.6.1rc1 and I'm
noticing that for multichannel audio output on UK Freeview HD
channels (which I believe use HE-AAC) that there is no centre channel being
output through my amplifier (connected via HDMI) which is receiving only
PCM 2.0 - only left and right stereo audio is heard.

If I watch the same channel directly via my TV's Freeview HD tuner
(connected using ARC HDMI to the same amp) then I think some transcoding
occurs and Dolby Digital is shown on the amplifier and I get all channels
correctly.

Multichannel audio is working fine via VDR on Freesat HD channels which
just uses standard Dolby Digital so I'm guessing its something to do with
the handling of HE-AAC multi channel sound, either in VDR or Softhddevice.

Is anyone else seeing the same problem? I recorded "Blades of Glory" the
other 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

Re: [vdr] DVB-T2 device in France

[Morfsta]

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 helps.
> Regards.


I have the TBS6281 and have found that the drivers from TBS are a pain to
get co-existing at the same time with other kernel DVB drivers (e.g. my
Prof USB DVB-S2 device) and need re-installing after every kernel update.
Also, I think that the open source drivers do not support DVB-T2.

However, on the positive side once the driver is installed, the card is
stable.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] FF card AV sync problems, possible fix to VDR (fwd)

[Morfsta]

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 stuff in real live on my productions system ;)
Knock on wood that this stays stable ...

 Werner

--
"Having a smoking section in a restaurant is like having
 a peeing section in a swimming pool." -- Edward Burr

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

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

Re: [vdr] softdevice audio problem. audio repacker issue?

[Morfsta]

On 3/18/07, Martin Wache <[EMAIL PROTECTED]> wrote:



I switched the repacking of in my vdr... I don't think that it is
necessary.

Bye,
Martin




Hi,

I would like to disable the repacker in my VDR implementation as I think it
might be responsible for sync problems in transfer mode 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

[vdr] softdevice audio problem. audio repacker issue?

[Morfsta]

On 3/18/07, Georg Acher <[EMAIL PROTECTED]> wrote:


That's a bit difficult, since "our" vdr has no exact mainline equivalent.
It may contain parts from different vdr versions. But as I've heard, it
should work also on a full featured card without any modifications. Maybe
you need to tweak the makefile... The remuxer itself should be API
compatible, so exchanging the file and using tools.c/h from the svn should
also work.



I can confirm that this repacker code does integrate seamlessly into the
latest 1.4 version of VDR, I replaced remux.c and remux.h as well as tools.cand
tools.h from Georg's SVN tree and recompiled.

I've done some quick tests on radio channels in transfer mode and all seems
to work okay. My AC3 channels are provided directly from my FF card so might
not be subjected to the repacker but they also work fine in both live mode
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 list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] reelbox HD kit - vendor?

[Morfsta]

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.. Whoever
comes first to market with that will surely make a fortune... Anyone
know of any imminent release by a company?

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

[vdr] [ANNOUNCE] xmltv2vdr-1.0.7

[Morfsta]

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,

Regards

Morph

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

[vdr] VDR BUG: Cannot display named channels on a transponder with other unnamed channels present

[Morfsta]

Hi,

I am running VDR 1.4.6-1 and I think there is a bug in its tuning of
certain channels. On the Astra 28.2E package at 11604V there are two
unnamed channels which are Sky Anytime A and Sky Anytime B
(http://www.lyngsat.com/packages/skyuk.html). Using dvbscan these show
up as channels [0f36] and [0f37] respectively and have VPIDS 518 and
519. It is poosible to display these channels, but  it is now not
possible to receive the other channels on this transponder (VPIDS 512
to 517).

I had no problems receiving these channels before the appearance of
these additional channels. I have checked 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 mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] DVB-S2 + H.264 support for VDR-1.5.10

[Morfsta]

Hi,

I tried the patch yesterday on my desktop computer: -

2.13Ghz Intel Core 2 CPU
2Gb RAM
Nvidia 6200LE PCI-E graphics card
400Gb IDE (not SATA) hard disk
Skystar 2 DVB-S
Latest Ubuntu with xorg
Latest NVIDIA Drivers
Hooked up DVI -> HDMI on a Pioneer 43" plasma TV at 720p (native
resolution of the panel = 1024x768) and using 32bpp on the desktop.
vdr-1.5.9 with the earlier h264 patch (I didn't see the seperated
patch for 1.5.10 yesterday)
xine-lib-cvs

The only test channel I could try it on at the moment is the BBC HD
service on Astra 2 which is FTA, DVB-S and mpeg4 (MBAFF).  Used tvtime
Greedy2Frame deinterlacer in xine.

The picture was very good, but there was dropped frames that xine
reported and the stuttered on occassion and then ran very quickly to
catch up. Playing around with the settings in xine (setting threads to
2 etc) didn't really make much difference. However, for the first time
I've spent playing with this I was impressed with the picture quality
out of VDR. Top reported that the CPU was ~40% idle so I don't know
why I saw dropped frames...

One other thing I noticed though was when using XVMC (-V xxmc) to view
normal MPEG2 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/21/07, Igor Nikanov <[EMAIL PROTECTED]> wrote:
> Hello Reinhard
>
> it's interesting - is there some opinion from VDR's users about this path ? 
> Which h.264 dvb-s2 channels is
> it possible to watch really ? What about CPU's load during this ? which 
> hardware (dvb-s2 card, cpu,
> graphic card) use ?
>
> regards
> Igor
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

[vdr] DVB-S2 + H.264 support for VDR-1.5.10

[Morfsta]

eo_out: throwing away image with pts 947540 because it's too old
(diff : 23198).
video_out: throwing away image with pts 952887 because it's too old
(diff : 26131).
video_out: throwing away image with pts 955430 because it's too old
(diff : 28988).
video_out: throwing away image with pts 960968 because it's too old
(diff : 27770).
video_out: throwing away image with pts 963601 because it's too old
(diff : 30538).
input_vdr: execution of rpc command 15 () failed, exiting ...
input_vdr: rpc thread done.
video_out: throwing away image with pts 969311 because it's too old
(diff : 30588).
video_out: throwing away image with pts 972026 because it's too old
(diff : 33273).
video_out: throwing away image with pts 975131 because it's too old
(diff : 32329).
video_out: throwing away image with pts 977892 because it's too old
(diff : 34968).
video_out: throwing away image with pts 980681 because it's too old
(diff : 33618).
[h264 @ 0x2ce75800]concealing 5040 DC, 5040 AC, 5040 MV errors
video_out: throwing away image with pts 983857 because it's too old
(diff : 36202).
video_out: throwing away image with pts 986687 because it's too old
(diff : 34094).
ffmpeg_video_dec: error decompressing frame
ffmpeg_video_dec: error decompressing frame
ffmpeg_video_dec: error decompressing frame
ffmpeg_video_dec: error decompressing frame

I don't get video jumping on MPEG 2 pictures, but I do get the
video_out "too old" messages.

When the video jumps, the whole of VDR seems to lock up, i.e. you
can't move the menu selection on the OSD until the video restarts.

Any ideas - or am I hitting some kind of hardware bottleneck here
(dual core 2.13Ghz, 2Gb RAM, IDE disk, NVIDIA 6200LE PCIe graphics @
720p)? Both cores are idle @ around 40%: -

top - 12:17:39 up  1:10,  4 users,  load average: 3.07, 3.31, 3.03
Tasks: 138 total,   2 running, 136 sleeping,   0 stopped,   0 zombie
Cpu0  : 29.3%us,  1.7%sy,  0.0%ni, 67.3%id,  0.0%wa,  1.0%hi,  0.7%si,  0.0%st
Cpu1  : 46.7%us,  0.3%sy,  0.0%ni, 53.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2063240k total,  1537516k used,   525724k free,   593748k buffers
Swap:  1100412k total,0k used,  1100412k free,   494464k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 8565 root  15   0  517m 120m  53m S   69  6.0  32:45.80 xine
 8081 root  15   0  155m  82m  55m R8  4.1   3:18.08 Xorg
 7607 root  15   0  215m  30m 3856 S2  1.5   0:36.89 vdr

top - 12:18:29 up  1:11,  4 users,  load average: 3.04, 3.28, 3.03
Tasks: 138 total,   3 running, 135 sleeping,   0 stopped,   0 zombie
Cpu0  : 80.3%us,  1.0%sy,  0.0%ni, 17.7%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  SHR S %CPU %MEMTIME+  COMMAND
 8565 root  15   0  517m 120m  53m R  140  6.0  33:50.91 xine
 8081 root  15   0  155m  82m  55m S8  4.1   3:21.94 Xorg
 7607 root  15   0  215m  30m 3856 S1  1.5   0:37.70 vdr

HD recordings also show the same symptoms. If you are interested I am
currently uploading a minute of BBC HD recording (140Mb)

Regards,

Morfsta




On 10/24/07, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Morfsta schrieb:
>
> > The picture was very good, but there was dropped frames that xine
> > reported and the stuttered on occassion and then ran very quickly to
> > catch up. Playing around with the settings in xine (setting threads to
> > 2 etc) didn't really make much difference. However, for the first time
> > I've spent playing with this I was impressed with the picture quality
> > out of VDR. Top reported that the CPU was ~40% idle so I don't know
> > why I saw dropped frames...
>
> Frame duration wasn't set at all in xine-lib for this case. xine-lib-1.2
> contains now a fix for this issue. The fix is part of vdr-xine-0.8.0's
> xine-lib.patch for xine-lib-1.1.8, too.
>
> > One other thing I noticed though was when using XVMC (-V xxmc) to view
> > normal MPEG2 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.
>
> xxmc's OSD support allows only 16 colors. I assume, you've enabled font
> antialiasing in VDR, which requires much more than 16 colors. This is
> the case for hardware accelerated MPEG2 decoding. For H.264, xxmc falls
> back to xv where there is no such limitation.
>
> You may also want to try to choose unscaled OSD in vdr-xine's setup
> menu, which renders the OSD on top of the video image, using libX11. It
> is therefore not limited to 16 colors but doesn't support OSD
> transparency at all.
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

[vdr] DVB-S2 + H.264 support for VDR-1.5.10

[Morfsta]

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 the same symptoms. If you are interested I am
> > currently uploading a minute of BBC HD recording (140Mb)
>
> Please provide a link to this recording.
>

Try here: -

http://www.megaupload.com/?d=55JZHZ4A

Thanks.

> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] DVB-S2 + H.264 support for VDR-1.5.10

[Morfsta]

On 10/25/07, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Please give the patch on the below mentioned site a try. Your recording
> (which uses only interlaced frames) plays properly here when I play it
> at 50 % of normal speed (my PC simply isn't fast enough for realtime
> decoding).
>
> http://www.vdr-portal.de/board/thread.php?postid=662944#post662944
>

That has fixed it - BBC HD and HD2/5 (Astra 3) are now playing
smoothly! It is so much better!

Now I have noticed another problem - there is a strange "fuzz" effect
(like tearing, but not exactly the same) on some broadcasts and not on
others. At first I thought it was the graphics setup on fast panning,
but this is not the case - it affects static images also. I saw this
on BBC HD and HD2/5. I managed to capture a snippet of the BBC HD
preview that demonstrates this - it's very strange 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

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

[vdr] DVB-S2 + H.264 support for VDR-1.5.10

[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 read the thread on
gmane.comp.video.ffmpeg.devel with interest.

I patched ffmpeg and did a make && make install and the recording is
still the same on my system. Do I have to re-compile xine-lib?

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

[vdr] Max 4 DVB Devices on VDR?

[Morfsta]

 Hi,

I have just added a Nova-T 500 device to my VDR stable setup (1.4.7)
and now have 5 frontends: -

[   29.735000] DVB: registering frontend 0 (ST STV0299 DVB-S)...
[   29.955000] DVB: registering frontend 1 (ST STV0299 DVB-S)...
[   29.976000] DVB: registering frontend 2 (Conexant CX22702 DVB-T)...
[   30.129000] DVB: registering frontend 3 (DiBcom 3000MC/P)...
[   30.634000] DVB: registering frontend 4 (DiBcom 3000MC/P)...

The problem I have is that the fifth frontend doesn't work in VDR
(i.e. I can only tune to 2 DVB-T stations simultaneously). If I move
my DVB-TTPCI device to 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 mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Max 4 DVB Devices on VDR?

[Morfsta]

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

[vdr] next features?

[Morfsta]

> > H.264 will only become interesting (to me) once there are hardware
> > devices that can replay it (aka "Full Featured DVB cards").
> > I am not interested in software players that might not even run
> > on my 450 MHz VDR.
> >
> > Until then, normal MPEG2/DVB-S does just fine for me.

I can understand Klaus has only a limited amount of time available and
therefore can only focus on what he thinks are important for his
system, but the problem with this is that there is more than 1 user of
VDR out there. H264 is a video standard and as such it should have
support within VDR. More and more channels will start using it (not
necessarily HD channels either, H264 increases the bandwidth of the
satellite platform) and there is already plenty of fine content out
there. E.g. the Premiere HD channels, Sky UK HD channels and the
bouquet of HD channels on Thor (Canal Digital). The Polish HD channels
are already improving and there will be HD channels as part of
Digitalb in December. It has now gone behind demonstration loops and
if you check out Kingofsat's website you will see there is now an
abundance of channels from different providers.

If Klaus is too busy or unconcerned to implement this standard in VDR,
why aren't key patches by trustworthy sources such as Reinhard
included? If Klaus does not start taking onboard assistance from key
developers to assist then VDR will always be behind the curve. With
something as important as H264 and DVB-S2 support, this needs to be
included in the developer version as soon as possible (H264 NOW and
DVB-S2 when the multiproto stuff is finished) otherwise it will be a
real problem to patch and update the source and plugins to keep in
line with new developer versions. Klaus may argue that he would like
to keep control of stability of VDR etc, however isn't this why we
have "developer" versions? Personally, I have still be using
vdr-1.4.7, but I also have vdr-1.5.10 setup alongside it for looking
at the dev version and applying patches etc (usually when the wife is
out).

Reinhard has released some much needed patches that AFAIK have still
not been implemented within VDR developer: -

* H264 (this can slot in very easily with negligible impact to MPEG2 users)
* Sync Early
* NTSC recording time
* Radio recording time fix (this has been a problem with VDR for as
long as I have used it)

Essentially, what I believe is that if Klaus is unwilling to implement
changes within VDR due to time constraints he should do what most
other open source projects do and enlist help and set-up a CVS/SVN/HG.
Klaus can then spend a little bit of time reviewing the code and
ensuring it is OK, but I'm sure from people like Reinhard et al this
will not take a lot of time.

I must admit that unless this happens soon then I might be another
long term user and supporter of VDR that moves over to MythTV purely
because it seems to be better supported by developers. I have recently
been playing with xine and a nvidia card (for both VDR and MythTV) and
there is now very little difference between the output of xine and
Technotrend FF card due to the improvements in de-interlacing. This
was one of my first reasons for using VDR - output via a graphics card
looked terrible!

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

[vdr] Multiproto / VDR with S2 Patch and DVB-T

[Morfsta]

Hi,

I have been trying VDR with the multiproto DVB kernel source and the
DVB-S2/H264 patch.

Has anyone managed to get any DVB-T cards working with this? It
doesn't show any output with my NOVA-T 500 and NOVA-T cards.

I think it will be something quite simple, but can't find where the
problem might be.

Regards,

Morfsta

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

[vdr] Technotrend FF DVB-S AC3 Passthrough

[Morfsta]

Hi,

Apologies if this has been covered before but I have been searching
for info on this, can anyone explain how this works with the TT FF AC3
Passthrough firmware?

I can't seem to get any AC3 out of my motherboard soundcard when
playing an AC3 channel with the firmware alone - are there 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,

Morfsta

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

[vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

Reinhard,

Wow! I am running vdr-1.5.12 with the new xine-lib CVS (with your loop
filter and speed over accuracy changes enabled) alongside FFMPEG built
for 64bit linux on a k8 (AMD dual core BE-2350 processor overclocked
at 2.7Ghz) and the results are nothing short of amazing! Firstly I
would like to say thank-you very much for all your hard work on H264 -
what you have achieved is fantastic.

I can view channels such as BBC HD, Channel 4 HD and others perfectly.

I think this might have been covered before, but the only problem I
now see is with interlaced and spatial direct mode (particularly on
the French and Polish HD channels): -

[h264 @ 0x2d0b0700]Interlaced pictures + spatial direct mode is
not implemented
[h264 @ 0x2d0b0700]Interlaced pictures + spatial direct mode is
not implemented
buffer usage: 492,  0,  6,  0, 0x97d390
buffer usage: 492,  0,  7,  0, 0x97d390
buffer usage: 444,  0,  7,  0, 0x97d390
buffer usage: 444,  0,  7,  0, 0x97d390
[h264 @ 0x2d0b0700]Interlaced pictures + spatial direct mode is
not implemented
[h264 @ 0x2d0b0700]Interlaced pictures + spatial direct mode is
not implemented
buffer usage: 411,  0,  7,  0, 0x97d390
buffer usage: 411,  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]> wrote:
> Hi,
>
> Reinhard Nissl schrieb:
>
> > attached you'll find updated patches for VDR-1.5.12, which replace all
> > formerly patches regarding this subject.
> >
> > The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR
> > (thanks to Marco Schlüßler) and requires to use the DVB drivers from the
> > multi-proto tree (see URL below for further details).
> >
> > The other patch is without DVB-S2 support and therefore most suitable
> > for DVB-C users.
> >
> > The patches have been extended to also include the recently released
> > audioindexer patch. Furthermore, the field detection code for H.264 has
> > been adopted to MPEG2, where the same issue (VDR's index.vdr addresses
> > frame pictures, so an index entry must not be generated for the second
> > field of a field picture pair) exists, though hardly used compared to H.264.
>
> The patches now include my recently released speedup patches as
> well as an unreleased speedup patch for cAudioRepacker and
> cVideoRepacker, because at least the latter one would have been
> hard to extract separately.
>
>
> > Have a look at this page for more instructions on this concern:
> >
> > http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Installationsanleitung_%28Achtung_Beta%29
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

2344:HC34M2S1Z0:S28.2E:29500:0:0:0:0:3896:2:2005:0
NVOD:12344:HC34M2S1Z0:S28.2E:29500:10513+8190:641=NAR;661=eng:2312:960,961:3897:
2:2033:0
Nat Geo HD;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10513+8190:641=NAR;661=eng:0:960
,961:3831:2:2034:0
SBO HD1;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10514+8190:642=NAR;662=eng:2305:960
,961:3879:2:2034:0
History HD;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10512+8190:640=NAR;660=eng:0:960
,961:3886:2:2034:0
CANAL+ FILM HD;Harmonic:11470:vS0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:1
00:15423:318:1400:0
National Geographic HD;Globecast UK:7:vS0Z0:S13.0E:27500:12301+2301:0;2311=p
ol:0:100:14623:318:13000:0

Start X and xine to create a .config file then stop xine and edit your
~/.xine/config file. I have a dual core processor so here are the
settings I used in there: -

video.processing.ffmpeg_skip_loop_filter:all
video.processing.ffmpeg_thread_count:2
video.processing.ffmpeg_pp_quality:3
video.processing.ffmpeg_choose_speed_over_accuracy:1

Run vdr -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

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[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 FTA, but no S2 card atm.
>

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

> 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 can get support for DVB-T then it won't be possible.

There's two ways you can do this I believe, port the dvb-t driver
properly to the new multiproto tree or modify VDR to fall back to the
old interface to tune the driver if the new one fails.

I know that it is possible to use the old interface because when I use
vdr-1.4.7 with the multiproto tree it works fine for DVB-T, however I
am not sure where to start coding this into either VDR and I'm not
sure my skills are that hot at the driver level!

If someone could provide some pointers here, that would be great (Manu
or Reinhard?)

Thanks,

Phil

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

> 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 (Conexant CX22702 DVB-T)...
[ 9539.197883] DVB: registering frontend 3 (Philips TDA10045H DVB-T)...

Should the TDA10045H work? If so, perhaps the problem is that VDR is
tuning frontend 1 first which is not supported yet.

How can I go about porting the Conexant to the new interface? Is it
straightforward (i.e. can I compare the code for the TDA10021 based
frontend in v4l-dvb and multiproto and make the changes for the
cx22702 frontend?)

Thanks

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

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 what you have in the multiproto tree, if you see it as old,
> ie: changes have gone into those drivers in between. The easiest thing to
> get going is:
>
> Get the latest tree or whichever for which that demodulator/card is working
> with. Just overwrite the relevant older files for your driver/card in the
> multiproto tree (your local copy) That way, the devices which have been
> newly updated also will work.

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

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 that with that multiproto tree, VDR won't tune to any dvb-t
> channels on my nova-t 500. And with the latest multiproto tree dvb-t
> works but only unless I load the S2-3200 modules. If I do that VDR just
> hangs at startup saying nothing and doesn't answer on svdrp. Is there a
> way to debug this and see what's happening? Does anybody have any ideas
> about what's going on? If I remove the channels.conf vdr complains about
> that, so I know it's coming that far at least. There's no difference if
> I load any plugins or not.
>
> Again, I have followed all steps on the wiki and h.264+dvb-s2 works with
> the old multiproto, both using vdr-1.5.10 with your "old" patch and on
> vdr-1.5.12 with the new one. I'm running this on the 2.6.22-14-generic
> kernel that ships with Ubuntu 7.10.

Sounds like you are having the same problem I am - when you say "new"
multiproto, what do you mean?

I am using the mercurial tree at http://jusst.de/hg/multiproto which
hasn't been updated now in 4 weeks.

I can't get the DVB-T devices working with it, even though Manu said
it should work. The devices I use haven't had their source code
modified from the v4l-dvb tree, so according to Manu the compatibility
layer should mean they work OK, but when I tune to a DVB-T channel in
VDR I just get a black screen.

As it seems there are quite a few people desperately hoping for some
kind of DVB-T support alongisde their beloved DVB-S2 are there any
other suggestions from Manu or Reinhard on this?

Cheers

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

[vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]

[Morfsta]

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 calls for DVB-T whilst
using the new calls for DVB-S and S2 and I managed to get VDR to tune
to the current DVB-T frequency and show the picture, but it would not
tune to new frequencies. :-(

I too was considering using 2 VDRs on a single system using the -D
options but it's very messy.

It would be great if someone could look into this for us!

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

Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]

[Morfsta]

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 either the emulation layer has a bug for
> > DVB-T or the patched VDR passes incorrect data to the new API.
>
> Looks like the latter is true: Marco Schlüßler informed me that
> the mapping of TransmissionModes in nit.c for DVB-T is wrong.
>
> I've created the attached patch according to his' instructions.
>
> Please give the patch a try and report success or failure.
>
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>

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

Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]

[Morfsta]

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 like vdr etc.
> have to recognize the driver supported API ;-) .
>

I am using two Hauppauge Nova-T (tda1004x and cx2388x).

Manu said in an earlier thread that there should be compatibility with
the old API so he doesn't think that should be a problem. The driver
in the multiproto tree for my devices have not been changed so should
work through the compatibility layer.

The odd thing is that when I use an older pre-compiled VDR 1.4.x with
the new multiproto drivers everything works fine but when I compile
1.5.12 with multiproto includes it doesn't work.

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

[vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto

[Morfsta]

> 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
> dmesg or /var/log/messages or anything else which suits your
> system) at least for the set_frontend() function.
>
> Next use VDR-1.5.12-dvbs2-... (limited to only one device) and
> tune to the same DVB-T channel. Check what the driver reports
> this time. Additionally to the set_frontend() output there must a
> similar output before it which shows the parameters which VDR
> passed to the emulation layer.
>
> Please report the debug output here for further investigation.
>

Attached are two files - tuning to the same DVB-T channel using either
system and the Philips frontend... vdr-1.4.x shows the channel fine,
1.5.12 does not.

Hope this helps and thanks again for your assistance.

Regards


vdr-1.4.x_dvbt_BBCONE.log.bz2
Description: BZip2 compressed data


vdr-1.5.12_dvbs2_dvbt_BBCONE.log.bz2
Description: BZip2 compressed data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto

[Morfsta]

> 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=eng:0:0:4
165:9018:4101:0

Regards

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

Re: [vdr] Rotor patch for 1.5.12

[Morfsta]

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:
>
> > Hy again! thanks for the patch and cmd line, but
> > afther patching vdr with that patch i get the
> > following error when compiling vdr:
> > dvbdevice.c:946: error: no 'bool
> > cDvbDevice::SendDiseqcCmd(dvb_diseqc_master_cmd)'
> > member function declared in class 'cDvbDevice'
>
> Hmm, the patched VDR compiled flawlessly. And the last chunk of
> the patch adds the function declaration to dvbdevice.h. So I
> don't see how you can get this error.
>
> Are there any other reports?
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto

[Morfsta]

> While copying the code here to ask for help in searching the bug,
> it seems that I found the bug -- a missing break in the DVB-T
> case ;-)
>
> Please try the attached patch.

Reinhard you've done it!!! All working! :-)

Thanks a lot for your work, I'm sure a lot of people are going to be very happy!

Cheers,

Morfsta

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

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 issues and fixes for us over the last few weeks!

In the meantime, just look over Reinhard's postings since the first
ANNOUNCE for vdr dvb-s2 and h264 for vdr-1.5.12 and download and apply
all of the relevant patches.

With all of the required patches, fixes and tweaks for VDR / FFMPEG /
XINE-LIB / VDR-XINE I'm wondering if it would be nice to set-up a web
site that tracks all of the latest patches for VDR / S2 / h264. Would
anyone be interested in this? I know there is the vdrportal.de site
that discusses a lot of this stuff, but as its in German I find it
quite hard to follow.

On Jan 16, 2008 12:34 PM, serge pecher <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Sorry, but is this the last version of the patch ?
>
> I believe there was an additional one, but can't find it anymore.
>
>
>
> http://www.linuxtv.org/pipermail/vdr//2008-January/014956.html
>
>
>
> thanks,
>
>
>
> sp
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>

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

Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12

[Morfsta]

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, Morfsta <[EMAIL PROTECTED]> wrote:
> 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 issues and fixes for us over the last few weeks!
>
> In the meantime, just look over Reinhard's postings since the first
> ANNOUNCE for vdr dvb-s2 and h264 for vdr-1.5.12 and download and apply
> all of the relevant patches.
>
> With all of the required patches, fixes and tweaks for VDR / FFMPEG /
> XINE-LIB / VDR-XINE I'm wondering if it would be nice to set-up a web
> site that tracks all of the latest patches for VDR / S2 / h264. Would
> anyone be interested in this? I know there is the vdrportal.de site
> that discusses a lot of this stuff, but as its in German I find it
> quite hard to follow.
>
>
> On Jan 16, 2008 12:34 PM, serge pecher <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > Sorry, but is this the last version of the patch ?
> >
> > I believe there was an additional one, but can't find it anymore.
> >
> >
> >
> > http://www.linuxtv.org/pipermail/vdr//2008-January/014956.html
> >
> >
> >
> > thanks,
> >
> >
> >
> > sp
> > ___
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
> >
>

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

[vdr] What is H264 Spatial Direct Mode?

[Morfsta]

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 to code up? Do you know if
there are any plans to support it?

Thanks

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

[vdr] H264 Issue with C+ Nordic Channels

[Morfsta]

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

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

Re: [vdr] What is H264 Spatial Direct Mode?

[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 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 to code up? Do you know if
> > there are any plans to support it?
>
> I'm sorry, haven't read in the spec for this issue yet. But it
> looks like there is currently no one willing to implement it on
> ffmpeg-devel mailing list.
>
> Maybe Igor may post some links which enable xine-lib to use
> coreavc. Igor mentioned, that coreavc supports spatial direct mode.
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] CoreAVC + xineliboutput

[Morfsta]

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:/dshow_sem2.(null)
Opening device
Called unk_IsDebuggerPresent
len: 948
ProductVersion: 1.3.0.0
Decoder supports the following YUV formats: YUY2 IYUV YV12 I420
Decoder is capable of YUV output (flags 0x27)
Setting fmt
Starting
Initialization is complete
shm_open failed: No such file or directory

Is dshowserver supposed to run in the background - using strace it
says it's detached but I can't see it?

I looked through the diff and can't find any options to enable CoreAVC
in xine-lib... Must be missing something?

Igor, can you point us to or translate a HOWTO?

Thanks


On Jan 19, 2008 4:38 PM, Per Mellander <[EMAIL PROTECTED]> wrote:
> I have done all the patching to xine-lib, ( patch from
> coreavc-for-linux-read-only + additional from happysat ). Then I've put
> CoreAVCDecoder.ax in /usr/lib/win32.
>
> I'm running VDR with xineliboutput.
>
> -P "xineliboutput --fullscreen --local=sxfe --audio=alsa --remote=none"
>
> What more do I have to do, ( extra arguments etc. ) to use CoreAVC? When
> I start VDR now I can't see any difference from using ffmpeg.
>
> 
> load_plugins: plugin
> /usr/local/lib/xine/plugins/1.1.9/xineplug_dmx_nsv.so found
> load_plugins: plugin
> /usr/local/lib/xine/plugins/1.1.9/xineplug_decode_a52.so found
> video_out_xv: using Xv port 275 from adaptor NV17 Video Texture for
> hardware colour space conversion and scaling.
> video_out_xv: this adaptor supports the yuy2 format.
> video_out_xv: this adaptor supports the yv12 format.
> audio_alsa_out : supported modes are 8bit 16bit 24bit 32bit mono stereo
> (4-channel not enabled in xine config) (4.1-channel
>  not enabled in xine config) (5-channel not enabled in xine config)
> (5.1-channel not enabled in xine config) (a/52 and DTS pass-through not
> enabled in xine config)
> xine: found input plugin  : VDR (Video Disk Recorder) input plugin
> input cache plugin disabled
> xine: found demuxer plugin: DVD/VOB demux plugin
> video_out_xv: VO_PROP_INTERLACED(1)
> av_offset=0 pts
> video_out_xv: VO_PROP_ZOOM_X = 100
> prebuffer=14400 pts
> prebuffer=14400 pts
> prebuffer=14400 pts
> prebuffer=14400 pts
> prebuffer=14400 pts
> video: synced early
> prebuffer=14400 pts
> prebuffer=14400 pts
> video: synced early
> prebuffer=14400 pts
> prebuffer=14400 pts
> video: synced early
> [h264 @ 0x11c43f0]non existing PPS referenced
> [h264 @ 0x11c43f0]decode_slice_header error
> [h264 @ 0x11c43f0]non existing PPS referenced
> [h264 @ 0x11c43f0]decode_slice_header error
> 
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 code site
Fixed the Makefile.am problem
Patched with additional patch posted from Per in this mailing list
Patched with all additional patches that are in the Genpix thread on DVBN
Ran configure (./configure --disable-dxr3) && make && make install
Downloaded the CoreAVC unpacked file from rapidshare
(coreavcdecoder_unpacked.ax)
Put it in /usr/lib/win32 as (CoreAVCDecoder.ax)
Remove /usr/local/lib/plugins/1.1.9/xineplug_decode_ff.so [THERE IS NO
/usr/local/lib//1.1.9/xineplug_decode_qt.so]
Remove /usr/local/lib/plugins/1.1.90/xineplug_decode_ff.so [THERE IS
NO /usr/local/lib//1.1.90/xineplug_decode_qt.so]
Patched xinelibout (this doesn't work and causes a segfault on VDR startup)
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.

So it seems that it just doesn't load the DLL. Am I missing any other
dependencies, do you need wine or anything else?

Thanks for your help and hopefully the above can lead to a howto, and
perhaps someone can upload somewhere a patched and working xine-lib as
well as a patched and working xinelibout?

Thanks in advance for all your help.


2008/1/21 Igor <[EMAIL PROTECTED]>:
> > I'll try 1.2,
>
>
> may be it's the best case :)
>
> @Reinhard
>
> is there any difference between xine-lib 1.2 branch and 1.1 branch for our 
> case ?
>
> Igor
>
>
>
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>


xine.log
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] H264 Issue with C+ Nordic Channels

[Morfsta]

OK, well thanks for looking at it Reinhard.

It seems like there is a lot of work required with xine and ffmpeg,
which is a shame because using them is obviously the more desireable
solution at the moment. If spatial direct mode was properly
implemented as well as these issues it would almost a 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 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
>
> Looks like the broadcaster has set the progressive frame flag and
> as such, no deinterlacing is applied when running the
> deinterlacer like that:
>
> -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1
>
> To force deinterlacing even for progressive frames use this one:
>
> -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=0
>
> But it then looks like top and bottom field are shown in the
> incorrect order. Don't know whether this can be fixed. When the
> broadcaster sets the progressive frame flag, then there is
> usually no way to decide, which field must be displayed first.
> And it seems that tvtime's decision is the wrong one :-(
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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.orig  nal_parser.h  w32codec.c.orig
libwin32.h  Makefile.am.rej   qt_decoder.c  w32codec.h

there doesn't seem to be any .lo or .o files - do you have them?

Also, if I do a make clean && make in that directory it doesn't do anything: -

# make
make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll'

Could this be the problem?

Thanks


On Jan 21, 2008 11:05 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote:
>
> > See attached xine.log
> >
>
> >load_plugins: plugin mpeg2 will be used for video streamtype 00.
>
> try delete /usr/local/lib libxine* and /usr/local/lib/xine dir and make
> install xine again
>
> Walery
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

OK, you are right. I am building it in a 32bit chroot environment and
now it tried to build in lib32dll!

However, I get this error message: -

w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)

I can't find anywhere in the code where this is declared 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 directory called 1.1.9 and sometimes 1.1.90.
>
> Wrong. 1.1.90 only. Any 1.1.9 which you see is from xine-lib 1.1.9.
>
> [snip]
> > Running on Ubuntu 7.10 x86_64.
>
> libw32dll is built only in i386; I see nothing in the patch which causes it
> to be built on amd64.
>
> [snip]
> --
> | Darren Salt| linux or ds at  | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> |   Kill all extremists!
>
> b Wrong file type, 0:1
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
is defined in xine-engine.h. I added it to an include and its
compiling-ish I'm actually cross compiling 32bit in my 64 bit
environment which is fun with having to provide so many 32-bit libs.
Still I don't fancy 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: -
>
> > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this 
> > function)
>
> > I can't find anywhere in the code where this is declared but the
> > coreavc patch adds it..
>
> > Any ideas?
>
> Incomplete patch?
>
> Anyway, I'm guessing that it's for the same codec as BUF_VIDEO_VC1, which I
> added for 1.1.9 (since it's one which ffmpeg implements).
>
> [snip]
> --
> | Darren Salt| linux or ds at  | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.
>
> Don't use a big word where a diminutive one will suffice.
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 defined in xine-engine.h.
>
> I don't know where your xine-engine.h came from, but it's not xine-lib.
>
> [snip; don't top-post]
> --
> | Darren Salt| linux or ds at  | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
>
> Avoid run-on sentences they are hard to read.
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

That got it!

I've got it working now in the 32-bit chroot environment, I can see it
loading the CoreAVC codec when switching to BBC HD.

Sadly, I'm doing this remotely so can't see how the results actually
look on the TV until tomorrow! I'm keen on seeing a channel that uses
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 error message: -
> >
> > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this 
> > function)
>
> Try:
>
> --- xine-lib/src/xine-engine/buffer.h.orig  2007-11-05 18:33:03.0 
> -0500
> +++ xine-lib/src/xine-engine/buffer.h   2007-11-05 18:33:38.0 -0500
> @@ -192,6 +192,8 @@
>  #define BUF_VIDEO_CAVS 0x0262
>  #define BUF_VIDEO_VP6F 0x0263
>  #define BUF_VIDEO_THEORA_RAW   0x0264
> +#define BUF_VIDEO_VC1  0x0265
> +#define BUF_VIDEO_WVC1 0x0265
>
>  /* audio buffer types:  (please keep in sync with buffer_types.c) */
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 fine.
Anyone else managed to see BBC HD okay? I know it is supported with
the CoreAVC codec...

It's swings and roundabouts - some spatial mode channels now are fine!

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 parse through the payload itself?

On Jan 23, 2008 3:10 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote:
> Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly
> up, and for BBS HD it is necessary 1440?1080
>
> > 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
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

OK, I have added the following code into src/demuxers/demux_mpeg_pes.c

static int32_t GetVideoSize(const uint8_t *buf, int length, int
*width, int *height)
{
  int i = 0; // the minimum length of the video packet header
  //i += buf[i] + 1;   // possible additional header bytes
  for (; i < length-6; i++) {
if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
  if(buf[i + 3] == 0xb3) {
int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
*width = (d >> 12);
*height = (d & 0xfff);
return 1;
  }
}
  }
  return 0;
}

and then put the following code in parse_video_stream: -

  int Width, Height;
  if (GetVideoSize(p, payload_size, &Width, &Height)) {
   printf("Detected video size %dx%d\n", Width, Height);
  }
  else {
   printf("Failed to detect video size\n");
  }

before:   /* H.264 broadcasts via DVB-S use standard video PES packets,

This detects the video size for MPEG2 broadcasts (Detected video size 704x576
), but not for H264, I'm guessing the payload is in a different
format. Can anyone point me in the direction of a GetVideoSize type 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 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 parse through the payload itself?
>
>
> On Jan 23, 2008 3:10 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote:
> > Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly
> > up, and for BBS HD it is necessary 1440?1080
> >
> > > 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
> >
> >
> >
> > ___
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

Yes, I started looking at that. I also downloaded some H264 reference
utilities that someone at Dolby put together.

 It seems that you must start scanning the mpeg stream for a Sequence
Parameter Set with a NAL Access Code of 7. At first glance this
doesn't appear too bad, as the code is already in
src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit
Delimiter), which it uses to detect the presence of H264 stream.

I thought it would be quite straightforward to find the NAL code of 7
and then parse the SPS and in turn find the height and width
parameters. However, trying to get this to work in sequence is not
that easy as the parse_video_stream seems to want to identify MPEG1/2
or H264 and then just init the decoders. This is where the
initialisation of CoreAVCDecoder.ax is made, currently with the
hardcoded video size of 1920x1080.  What I want it to do is identify
the H264 stream and then keep scanning for an SPS to identify the size
prior to initting the decoder.

It seems that once it's found the AUD it doesn't really want to keep
looking for a SPS. I tried modifying the code to look for a SPS to
init the H264 sequence, however haven't had much success with that
either.

It might be the case that the whole initialisation of the CoreAVC
decoder would be better suited somewhere else in the code :-\

Still, I knew nothing about MPEG2 and MPEG4 formats this morning and
now I know a tiny bit! Unfortunately, I'm not sure if I 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 GetVideoSize(const uint8_t *buf, int length, int
> > *width, int *height)
> > {
> >   int i = 0; // the minimum length of the video packet header
> >   //i += buf[i] + 1;   // possible additional header bytes
> >   for (; i < length-6; i++) {
> > if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
> >   if(buf[i + 3] == 0xb3) {
> > int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
> > *width = (d >> 12);
> > *height = (d & 0xfff);
> > return 1;
> >   }
> > }
> >   }
> >   return 0;
> > }
> >
> > and then put the following code in parse_video_stream: -
> >
> >   int Width, Height;
> >   if (GetVideoSize(p, payload_size, &Width, &Height)) {
> >printf("Detected video size %dx%d\n", Width, Height);
> >   }
> >   else {
> >printf("Failed to detect video size\n");
> >   }
> >
> > before:   /* H.264 broadcasts via DVB-S use standard video PES packets,
> >
> > This detects the video size for MPEG2 broadcasts (Detected video size 
> > 704x576
> > ), but not for H264, I'm guessing the payload is in a different
> > format. Can anyone point me in the direction of a GetVideoSize type of
> > function for H264 (I looked in libavcodec and the code looks a bit
> > more complex!), or spot what I am doing wrong here?
>
> In H.264, this information in coded far more complex. Have a look
> into VDR's h264parser.c. Look for pic_width_in_mbs_minus1,
> pic_height_in_map_units_minus1 and frame_crop_*_offset.
>
> You can get the standard from here for free:
> http://www.itu.int/rec/T-REC-H.264-200503-I/en
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
>
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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) {
>int nal_unit_type = p[1] & 0x1F;
>switch (nal_unit_type) {
>  case 9: { // access unit delimiter
>   int primary_pic_type = p[2] >> 5;
>   switch (primary_pic_type) {
> case 0: // I
> case 3: // SI
> case 5: // I, SI
>  PictureType = I_FRAME;
>  break;
>
> > It might be the case that the whole initialisation of the CoreAVC
> > decoder would be better suited somewhere else in the code :-\
>
> Doesn't the decoder support a callback function where it tells
> you, the detected frame size? It'll really be a mess to do H.264
> "decoding" in the demuxer.
>

I'm not sure about that. So, if the function identifies an AUD at the
start of the payload then it could go on and scan the rest of the
payload for an SPS? In other words we must scan after the AUD for

Data[0] = 0x00
Data[1] = 0x00
Data[2] = 0x01
Data[3] & 0x1F = 0x07

and start parsing from Data[4]?

How can we be sure that combination of bytes doesn't exist by chance
in the picture payload anyway?

Cheers

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

[vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

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 Technotrend through the use of the -D options
to VDR.

Regards

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

> 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 the linux-dvb mailing list and
can be downloaded here: -

http://www.linuxtv.org/pipermail/linux-dvb/attachments/20071215/13bb7cb3/attachment-0001.bin

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

> 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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel NotAvailable on DVBS2 Channels

[Morfsta]

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 :(
>
> Igor
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

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-January/022762.html it
> should work, the previous one didn't declare the card as DVB-S2 capable.

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

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 you could isolate that bit then perhaps I could
just add that to the original multiproto + original hvr4000 patch?

> But now your VDR recognize the card as a DVB-S2 one (who said black
> screen is a problem ?).
>

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

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 work with the
new VDR.

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

Re: [vdr] VDR-1.5.13 DVBS2 Autodetect Addon: Channel Not Available on DVBS2 Channels

[Morfsta]

> 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 original HVR4000 patch to work
with VDR-1.5.13 and Reinhard's recent patches. The patch is attached,
apply the patch after applying Holger's to the multiproto tree.
--- multiproto/linux/drivers/media/dvb/frontends/cx24116.c  2008-01-26 
18:49:56.0 +
+++ multiproto.worked/linux/drivers/media/dvb/frontends/cx24116.c   
2008-01-26 17:23:21.0 +
@@ -1490,6 +1490,16 @@ static int cx24116_get_frontend(struct d
return ret;
 }
 
+static int cx24116_get_delsys(struct dvb_frontend *fe,
+enum dvbfe_delsys *fe_delsys)
+{
+dprintk("%s()\n",__FUNCTION__);
+*fe_delsys = DVBFE_DELSYS_DVBS | DVBFE_DELSYS_DVBS2;
+
+return 0;
+}
+
+
 /*
  * Initialise or wake up device
  *
@@ -1579,6 +1589,7 @@ static struct dvb_frontend_ops cx24116_o
.set_voltage = cx24116_set_voltage,
.diseqc_send_master_cmd = cx24116_send_diseqc_msg,
.diseqc_send_burst = cx24116_diseqc_send_burst,
+   .get_delsys = cx24116_get_delsys,
 };
 
 module_param(debug, int, 0644);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14

[Morfsta]

> 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 being
backported into multiproto - its been fairly static for awhile.

Hopefully your move toward multiproto might kickstart a move towards
widespread adoption (i.e. integration with the development tree) and
then eventually into the kernel itself.

Still, I'm pleased that VDR now supports S2 "out of the box", shame it
doesn't support h264 by default yet though! ;-)

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

[vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14

[Morfsta]

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\"
-DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"
-I/usr/include/freetype2 -I/root/multiproto/linux/include device.c
device.c:793: error: prototype for âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â does not match any in
class âcDeviceâ
device.h:255: error: candidate is: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c: In member function âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â:
device.c:813: error: call of overloaded âSetChannel(const cChannel*&,
bool)â is ambiguous
device.h:255: note: candidates are: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c:793: note: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool)
make: *** [device.o] Error 1

The following patch fixes it: -

--- device.c2008-01-28 10:33:00.0 +
+++ device.c.new2008-01-28 10:32:47.0 +
@@ -790,7 +790,7 @@ bool cDevice::SwitchChannel(int Directio
   return result;
 }

-eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool LiveView)
+eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool
LiveView, cDevice *SpecificSourceDevice)
 {
   if (LiveView) {
  StopReplay();

I'll test the functionality of the new rotor + patches shortly. I had
a brief look through the output, should it now be able to scan DVB-S2
transponders?

Thanks



On Jan 27, 2008 11:05 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> the attached patch is based on these files:
>
>vdr-rotor-0.1.4-vdr1.5.tgz
>rotor-0.1.4-vdr-15.12.diff
>
> For simplicity a patched version is attached too.
>
> NOTES:
> - I couldn't test with a real rotor device
> - I couldn't test with a FF card
>
> Have fun!
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>

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

Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14

[Morfsta]

Seems that I spoke too soon - I get a problem running rotor on my
system after compilation: -

vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol:
_ZN7cDevice13SwitchChannelEPK8cChannelPS_

Whatever I try I can't seem to fix it. Reverting back to my old
version of rotor works fine.



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/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE
> -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\"
> -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"
> -I/usr/include/freetype2 -I/root/multiproto/linux/include device.c
> device.c:793: error: prototype for âeSetChannelResult
> cDevice::SetChannel(const cChannel*, bool)â does not match any in
> class âcDeviceâ
> device.h:255: error: candidate is: eSetChannelResult
> cDevice::SetChannel(const cChannel*, bool, cDevice*)
> device.c: In member function âeSetChannelResult
> cDevice::SetChannel(const cChannel*, bool)â:
> device.c:813: error: call of overloaded âSetChannel(const cChannel*&,
> bool)â is ambiguous
> device.h:255: note: candidates are: eSetChannelResult
> cDevice::SetChannel(const cChannel*, bool, cDevice*)
> device.c:793: note: eSetChannelResult
> cDevice::SetChannel(const cChannel*, bool)
> make: *** [device.o] Error 1
>
> The following patch fixes it: -
>
> --- device.c2008-01-28 10:33:00.0 +
> +++ device.c.new2008-01-28 10:32:47.0 +
> @@ -790,7 +790,7 @@ bool cDevice::SwitchChannel(int Directio
>   return result;
>  }
>
> -eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool LiveView)
> +eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool
> LiveView, cDevice *SpecificSourceDevice)
>  {
>   if (LiveView) {
>  StopReplay();
>
> I'll test the functionality of the new rotor + patches shortly. I had
> a brief look through the output, should it now be able to scan DVB-S2
> transponders?
>
> Thanks
>
>
>
>
> On Jan 27, 2008 11:05 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > the attached patch is based on these files:
> >
> >vdr-rotor-0.1.4-vdr1.5.tgz
> >rotor-0.1.4-vdr-15.12.diff
> >
> > For simplicity a patched version is attached too.
> >
> > NOTES:
> > - I couldn't test with a real rotor device
> > - I couldn't test with a FF card
> >
> > Have fun!
> >
> > Bye.
> > --
> > Dipl.-Inform. (FH) Reinhard Nissl
> > mailto:[EMAIL PROTECTED]
> >
> > ___
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
> >
>

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

Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.5.14

[Morfsta]

Manu,

Firstly, thanks for all your work - it's appreciated.

Is the interface working properly for reading the signal strength, BER
and status?

The rotor plugin doesnt return anything and I can't get anything out
of VDR-Femon.

Is it working OK with the TT 3200?

BTW I have a TT3200 on 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 - 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 being
> > backported into multiproto - its been fairly static for awhile.
>
>
> I have pushed out a tree which is now a merged version of v4l-dvb and the
> multiproto trees and is available at http://jusst.de/hg/multiproto
> (As of now, insufficient tests, after the merge, please test)
>
> A point to note is that, in the build (for me 2.6.21) the stk-webcam in the
> v4l-dvb tree was broken and hence is broken in the updated multiproto
> tree as well.
>
> You will need to disable the stk-webcam build in that tree, in case you are
> using an older kernel.
>
> Regards,
> Manu
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14

[Morfsta]

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
vdr-rotor-0.1.4-vdr-1.5.14.tgz
vdr-1.5.14-h264-other-rotor.diff
vdr-1.5.14-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff

./vdr -Protor
vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol:
_ZN7cDevice13SwitchChannelEPK8cChannelPS_

Could be the mismatch between device.c and device.h  in
eSetChannelResult SetChannel. I don't know.

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

Re: [vdr] What is H264 Spatial Direct Mode?

[Morfsta]

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 implemented, but I still get extreme
artifacting, dropped frames and problems with xine: -

video_out: throwing away image with pts 1124374 because it's too old
(diff : 31864).
buffer usage: 1689,  0,  0,  0, 0x9639a0
buffer usage: 1689,  0,  1,  0, 0x9639a0
ffmpeg_video_dec: error decompressing frame
ffmpeg_video_dec: error decompressing frame
buffer usage: 1669,  0,  1,  0, 0x9639a0
ffmpeg_video_dec: error decompressing frame
buffer usage: 1662,  0,  1,  0, 0x9639a0
ffmpeg_video_dec: error decompressing frame
buffer usage: 1647,  0,  1,  0, 0x9639a0
video_out: throwing away image with pts 1126698 because it's too old
(diff : 33319).
buffer usage: 1714,  0,  0,  0, 0x9639a0
buffer usage: 1675,  0,  0,  0, 0x9639a0
buffer usage: 1675,  0,  1,  0, 0x9639a0
video_out: throwing away image with pts 1138960 because it's too old
(diff : 25556).

Hopefully, we can continue the interest and get these issues fixed.
Reinhard, do you have any idea why this might be occuring? I can
upload some samples somewhere if required.

Thanks

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

Re: [vdr] Straw poll: stable version 1.6.0 now?

[Morfsta]

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 PROTECTED]> wrote:
> On 02/03/08 13:36, Ales Jurik wrote:
> > On Sunday 03 February 2008, Klaus Schmidinger wrote:
> >> So, here's the straw poll:
> >>
> >>Should there be a stable version 1.6.0 now, based on what's in
> >>version 1.5.14, but without DVB-S2 or even H.264 support?
> >>
> >> Yes or No?
> >>
> >> Klaus
> >>
> >
> > Hi Klaus,
> > I vote for DVB-S2/H.264 (HDTV) support. But if it is a problem with some
> > distros could it be there time-compile switch to choose which drivers to 
> > use?
>
> The developer version will only support one driver API officially,
> and that's the "multiproto" API.
>
> > I thing it would be disadvantage to leave at whole such a well prepared part
> > of vdr.
>
> It wouldn't be left out of the developer version (which would then be
> numbered 1.7.x).
>
> The question was whether there is enough demand for a stable version
> *now*, based on what is in version 1.5.14, but without the switch
> to DVB-S2 (and thus the "multiproto" driver).
>
>
> So far there have been 19 votes here on the list, 11 No and 8 Yes.
>
> I have asked the same question over on vdrportal.de, and there the
> situation looks a lot different: 90 votes, 70 Yes, 20 No.
>
> For the final result all votes given here on the ML and on vdrportal.de
> will be added up.
>
> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] Straw poll: stable version 1.6.0 now?

[Morfsta]

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 the VDR!

I think the vote's closed - there will be a 1.6 now.

So let's let Klaus get on with it so that we can get it out of the way
and concentrate on the good (fun) stuff! ;-)

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

[vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card

[Morfsta]

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 Sky!)

Apologies for going slightly off topic, but errrm, no it isn't. Three
of the four main broadcasters in the UK will be offering HD services
this spring, for free, on the FreeSat platform. Currently you can get
an excellent service from BBC HD for free and Channel 4 HD you can
watch for the one off cost (£15) of a viewing card. C4 HD will also be
going FTA in a month or two. I can currently watch and record both
channels on my VDR box which is fantastic (check out Paul Mcartney at
the Electric Proms in HD and DD5.1!)

Apparently ITV HD will start FTA in March / April. Additionally, Luxe
HD is also FTA on Astra 2.

So, currently 4 HD channels that you can receive in the UK without
forking out lots to Sky.

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

Re: [vdr] xine problems with vdr

[Morfsta]

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
from /etc/inittab or rc.local type scripts without segfaulting.

Someone advised me of a workaround, you can use the startup script
with a sudo xine, or a su - xine and it will not segfault. I guess
using su or sudo setup some different environment variables (or
something) that xine is happy with.

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

Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14

[Morfsta]

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
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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).
>

OK - thanks for your help and patience Reinhard.

We are on the right track here. If I hardcode the this->ratio to be
1.8181 all looks good for my channels. However it is a hack and I have
come this far, so I might as well get the rest correct!

I used xinelibout for my H264 parser but Petri Hintukainen skips
parsing of the VUI! I am looking in your h264parser.c in VDR and you
also seem to comment this stuff out!

So, here is my code: -

   if (br_get_bit(&br)) { /* VUI parameters */
  if (br_get_bit(&br)) { /* Aspect Info */
 uint32_t aspect_ratio_idc = br_get_u8(&br);
 printf("H.264 SPS: -> Aspect Ratio IDC %d\n", aspect_ratio_idc);
 const uint32_t Extended_SAR = 255;
 if (aspect_ratio_idc == Extended_SAR) {
  uint32_t sar_width = br_get_u16(&br);
  uint32_t sar_height = br_get_u16(&br);
  printf("H.264 SPS: -> SAR_Size = %dx%d\n",
sar_width, sar_height);
 }
  }
   }

I am getting an Aspect Ratio IDC of 11 so the sar width and height
calcs are not called. What do I need to do here to get the aspect
(~1.818181)?

Thanks again!




>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 for example the image to 136 %
> horizontally.

The coreavc patch for xine has this code in it: -

+if(!img) {
+img = this->stream->video_out->get_frame (this->stream->video_out,
+  this->bih->biWidth,
+  this->bih->biHeight,
+  this->ratio,
+  IMGFMT_YUY2,
+  field);
+}

with  this->ratio = (double)this->bih->biWidth/(double)this->bih->biHeight;

This is all within xine's src/libw32dll/w32codec.c which is a
different area to which I was modifying before
(src/demuxers/demux_mpeg_pes.c) where the codec is initialised.

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

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 for the above sample
> should yield:
>
>pa = 1.81818 * 1080 / 1440 = 1.363635
>
> and most likely:
>
>bih.biXPelsPerMeter=13636
>

I tried that, what would the bih.biYPelsPerMeter be in this instance?
1?  Even then it doesn't seem to make any difference.

There is a reference to that structure here: -

http://www.herdsoft.com/ti/davincie/davp3xo2.htm

I think I'm quite close to getting this sorted but just can't seem to
get this final output right.. :-(

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

[vdr] VDR - xine - CoreAVC

[Morfsta]

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(&bih, 0x00, sizeof(bih));
  bih.biWidth = sps.width;
  bih.biHeight = sps.height;
  bih.biPlanes = 1;
  bih.biBitCount = 24;
  bih.biCompression = 0x34363248; //31435641; //AVC1
  bih.biSizeImage = 0;
  bih.biXPelsPerMeter=1;
  bih.biYPelsPerMeter=1;
  bih.biClrUsed=0;
  bih.biClrImportant=0;
  bih.biSize = sizeof(bih);
  buf->content = malloc(sizeof(bih));

It detects BBC HD as the right video size, i.e. 1440 x 1080 - however
this now results in a squased image on the display with black bars
down the left and right sides. Any idea how you tell CoreAVC what the
video size is and to scale it to the size that xine is using? It
detects other video sizes such as 1920x1088 and displays them all
correctly on the screen so I know that we are now very close!

Once I get this bit right, I'll release a patch to xine's
demux_mpeg_pes.c that will properly detect the source video size prior
to starting CoreAVC.

Thanks for any help.

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

Re: [vdr] VDR - xine - CoreAVC

[Morfsta]

> 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 discovered another problem with this method. I was
wondering why the performance on HD was so poor and it turns out that
the picture was being de-interlaced twice, once by CoreAVC for the
h264 picture and then by xine post plugin (tvtime). When I remove the
post deinterlacing plugin the performance is much better and now seems
to decode all the h264 channels I have access to pretty well with ~40%
idle. However, when I go back to a MPEG2 channel of course the
deinterlacing is now disabled and it looks terrible!

Do you know if its possible to enable de-interlacing for only a
certain picture type(s), or am I looking at this the wrong way?

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