[vlc-devel] RTSP client 'trick play' support. When will it?ever work??

[Glen Gray]

On 9 Jul 2009, at 21:04, Laurent Aimar wrote:

> On Thu, Jul 09, 2009, Rémi Denis-Courmont wrote:
>> Le jeudi 9 juillet 2009 22:34:05 Laurent Aimar, vous avez écrit :
>>> Hi,
>>>
>>>> (Ideally, VLC would have some implement some kind of progress  
>>>> bar, even
>>>> when it does not know the length of a _seekable_ media.
>>>
>>> That's a bit difficult without knowing the length and/or the current
>>> position. How to you translate the user clicking somewhere into a  
>>> position
>>> ? Beside, with rtsp you never know when you can seek or not  
>>> (unless I
>>> missed something in that wonderfull RTSP RFC).
>>
>> There are two completely separate problems. The scale/UI design is  
>> one issue.
>> Of course, it will be clumsy and RTSP servers should really specify  
>> the media
>> length in the description.
>>
>> Handling the failure to seek is another one. But I think that we  
>> can already
>> cope with as the demux can do whatever it wants with the seek  
>> point, no?
>
> With "Playback->Jump to specific time", the request will go up to  
> the demuxer
> even if the length is zero. So the core and the gui already have a  
> way to seek
> without length.
>
> The problem is only a GUI problem. Without a way to convert from a  
> slider
> position to an absolute time (for RTSP) I don't see how we can seek.
> Beside, for a better interface usage, detecting when we can seek is  
> a plus,
> we actually use the fact that a length is returned to detect that  
> for rtsp.
>
> Now, I have commited something that should fix most of the problem:  
> VLC now
> ignores the end time in PLAY requests if it is 0 (and so we fall  
> back to the
> one retreive in SETUP).

That's great fenrir, thanks.

Any comments on my earlier question with regards to the set rate in  
the demux explicitly excluding kasenna servers ?

--
Glen Gray
<slaine at slaine.org>