[vlc-devel] Accessing the demux Control at the interface level ? (re: RTSP trickplay)
slaine at slaine.org
Fri Dec 7 10:32:44 CET 2007
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
>>>> 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.
>> Jean-Paul Saman.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
Glen Gray (slaine at slaine.org)
More information about the vlc-devel