[vlc-devel] Accessing the demux Control at the interface level ? (re: RTSP trickplay)

[Glen Gray]

Just looking over the modules/demux/mkv.cpp file, perhaps it contains 
the answer. Have a event handler in the rtsp demuxer that can handle the 
key press events.


Glen Gray wrote:
> There seems to be some confusion of the reason for having the option.
>
> As Ross says, RTSP already handles returning the scale that the server 
> used, regardless of what you asked. This is not why the option is there.
>
> The reason is to do with VLC and how to trigger the call to 
> DEMUX_SET_SCALE. At the moment the interface for  Fastforward and Rewind 
> (this is my understanding based on the rc interface module at least) 
> triggers a short skip forward or backwards in the current play buffer by 
> simulating a key-press event, which is different to setting the scale of 
> play on an RTSP stream.
>
> The option is there at the moment, to specifically allow for other 
> methods of implementing FF/RW. My suggestion was to replace the user 
> supplied option with a query to the Demux to see if it supported setting 
> the scale, if so then enter that code path, if not then carry on with 
> the existing FF/RW implementations.
>
> There may well be a better implementation technique for this in VLC, 
> suggestions welcome.
>
>
> Jean-Paul Saman wrote:
>   
>> Ross Finlayson wrote:
>>   
>>     
>>>> Laurent Aimar wrote:
>>>>       
>>>>         
>>>>>   I will have a look at your patches this WE (or this week if I can find the
>>>>>  time)
>>>>>         
>>>>>           
>>>> The patch looks OK to me except for the option to turn scale on. That
>>>> renders the whole usage of scale unusable for a simple user. There most
>>>> by some way of either:
>>>> 1) letting live555 libs handle it
>>>>       
>>>>         
>>> The "live555 libs" (or, more precisely, the RTSP protocol) already 
>>> handles this.  Regardless of what scale you specify in the RTSP 
>>> "PLAY" request, the server will - in its RTSP "PLAY" response - tell 
>>> the client the *actual* scale that it supports.  (For example, if you 
>>> ask for a scale of 3.2, then the server might respond with a scale of 
>>> 3, or a scale of 1 (if it doesn't support fast-forward at all).)  As 
>>> I've noted already, after calling "playMediaSession()" (or 
>>> "playMediaSubsession()"), simply call "session.scale()" (or 
>>> "subsession.scale()") to get the actual scale factor that the server 
>>> chose to support.
>>>
>>> So, is there any reason not to *always* allow the user to (try to) 
>>> change the scale?
>>>     
>>>       
>> I think this is the *perfect* reason to do away with the proposed 
>> options on the comandline for scale. Just assume the server will support 
>> it and check the real value.
>>
>> Ross, Thanks for your clarification.
>>
>> Gtz,
>> Jean-Paul Saman.
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> http://mailman.videolan.org/listinfo/vlc-devel
>>   
>>     
>
>
>   


-- 
Glen Gray (slaine at slaine.org)