Problem with LiveBuffer and vdr-xine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Thomas Bergwinkl wrote:

>>>>> So, this is a matter of LiveBuffer patch. But I don't understand why
>> it
>>>>> was working when switching channels.
>>>>>
>>>>> Anyway, to fix it properly, the following line in
>>>>> cXineDevice::SetPlayMode() most be adapted to LiveBuffer:
>>>>>
>>>>>        m_settings.SelectReplayPrebufferMode(!Transferring());
>>>>>
>>>>> For vanilla VDR, Transferring() reports the existence of a transfer
>>>>> thread which means, VDR sends Live TV to vdr-xine.
>>>>>
>>>>> So, how could I detect Live TV in the case of a VDR with LiveBuffer
>>>>> patch?
>>>>>
>>>>> Is there a way to automatically detect that the LiveBuffer patch was
>>>>> applied to VDR?
>>  >>
>>>> In config.h LIVEBUFFERVERSION is defined, when livebuffer has been
>> applied:
>>>> #define LIVEBUFFERVERSION 106
>>>>
>>>> When the livebuffer is active (replaying)
>>>> cTransferControl::ReceiverDevice() returns the receiving device. So you
>>>> could use this for detecting Live TV.
>>>>
>>>> But I think it would be better to adapt the livebuffer patch so that
>>>> cDevice::Transferring() returns also true when a livebuffer recording
>> is
>>>> played. (Or does something argue against it?)
>>> I try to force Live TV in vdr-xine for LiveBuffer to solve the problem.
>> View
>>> channels work ok. But when moving back or forward into the LiveBuffer
>> don't
>>> work very well.
 >>
>> Hhm, it seems that it is not that easy to find a proper solution. Maybe
>> cDevice::Transferring() could be patched to return true when
>> LiveBuffer's reader and writer are almost at the same position (delta ~
>> 8 frames) and to return false otherwise.
> 
> I don't know vdr-xine, so why is it neccessary to distinguish between LiveTV
> and a recording. And why does fast forward / backward doesn't work correctly
> when you in LiveTV mode?
> 
> Patching cDevice::Transferring() the way you suggested shouldn't be much of
> a problem. But this behaviour doesn't seem to me very logical. 

xine wants to read data on demand which is possible for sources like 
DVDs, files on disk and VDR recordings sent via vdr-xine.

But on demand access is not possible for LiveTV as the satellite 
broadcasts at a constant data rate. Seeking forward to catch up with 
replaying will most likely result in a buffer underflow.

That's why I distinguish between LiveTV and recording and establish a 
buffer in LiveTV mode, which allows little seeks and other on demand 
burst accesses. The average input / output rate should typically be equal.

The buffer is reestablished when VDR clears the device and that's why 
moving forward / backward gets quite sluggish. Buffering is not 
necessary in this case as VDR can honor all on demand requests.

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


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux