[vdr] Re: xine-plugin AND Configurable LNB-Sharing ?

[Reinhard Nissl <rnissl@gmx.de>]

Hi,

I've just tuned to

SSR-La 1ere;Radio Suisse 
Romande:12398:hC34:S13.0E:27500:0:217:0:0:927:318:8500:0

and I get the same FIXME's with and without the LNB sharing patch 
applied. On my vdr-xine-0.6.1pre2 it looks like that:

todo: 1900, (6 + len): 2048     FIXME: xineDevice.c:855
FIXME: xineDevice.c:728
FIXME: xineDevice.c:861
FIXME: xineDevice.c:895
FIXME: xineDevice.c:721

The actual reason is that VDR doesn't give me a complete PES packet 
(it's to short at line 855 and the remainder then doesn't start like a 
PES packet in line 861) although PlayVideo()/PlayAudio() is said to give 
one or more "complete" packets.

I'll have a look at this issue the next days.

@Klaus:
Did I get you right some weeks ago that a VDR with new buffer handling 
(e. g. 1.3.16) feeds "one or more complete" PES packets to 
PlayVideo()/PlayAudio()?

At least as long PlayVideo() returns the size of complete packets, the 
next call to PlayVideo() should get at data block which starts with 0x00 
0x00 0x01. So a possible fix within vdr-xine would be to return the size 
of the complete packets.

But this doesn't work for PlayAudio() as there is no return value. A 
possible fix would there be to buffer the remainder internally and to 
assemble the complete packet on the next call to PlayAudio().

But I don't like the idea of buffering and reassembling the PES packets 
over and over again as this was already the job of VDR's remuxer. It has 
a bad impact on CPU load especially on less powerful machines.

If you agree to "complete" packets I could have a look into this issue 
and provide a patch (for the case that I can find a solution).

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de