[vlc-devel] Status of GUI support for RTSP seeking/fast-forward/reverse-play?

[Laurent Aimar]

On Tue, Nov 11, 2008, Glen Gray wrote:
> Hi,
> 
> On 11 Nov 2008, at 13:28, Laurent Aimar wrote:
> >> Well, the patchset basically got the Rate code in src/input/input.c
> >> iirc to query the demuxer to see if it supported scaled trickplay
> >>
> >> +            int i_rate, i_ret;
> >> +            vlc_bool_t b_scale_trickplay = VLC_FALSE;
> >> +
> >> +            /* Check to see if the Demux allows us to use Scale
> >> trickplay */
> >> +            i_ret = demux2_Control( p_input->input.p_demux,
> >> +                                    DEMUX_HAS_SCALE_TRICKPLAY,
> >> +                                    &b_scale_trickplay );
> >> +            if( i_ret == VLC_SUCCESS && b_scale_trickplay ==  
> >> VLC_TRUE )
> >> +            {
> >> +                double scale = val.f_float;
> >> +
> >> +                msg_Dbg( p_input, "Setting RTSP Scale to %0.2f",
> >> scale);
> >> +                demux2_Control( p_input->input.p_demux,
> >> DEMUX_SET_SCALE,
> >> +                                scale );
> >> +                msg_Dbg( p_input, "Checking Scale....");
> >> +                /* Now, readback the value actually used by the
> >> server */
> >> +                demux2_Control( p_input->input.p_demux,
> >> DEMUX_GET_SCALE,
> >> +                                &scale);
> >> +                msg_Dbg( p_input, "Scale set to %0.2f", scale);
> >>              }
> >>
> >> That's from my original patch, I know fenrir made some adjustments to
> >> the patches based on conversations that where held on IRC at the  
> >> time,
> >> I can't recall exactly what.
> > I have merged DEMUX_HAS_SCALE_TRICKPLAY into DEMUX_CAN_CONTROL_RATE  
> > and
> > then the rate is set using the standard DEMUX_SET_RATE at the demux  
> > level.
> > So except rewind, everything is there to support rtsp ff.
> 
> 
> The reason I used a different set of control calls here  
> (DEMUX_SET_SCALE...) was that the mechanisms for setting the value of  
> the RATE and passing up those RATE versions where specifically not  
> going to allow negative float values and hence couldn't be used for  
> rewind trickplay. The issues are more to do with the input layer and  
> getting those values into the demux rather than with whether tricplay  
> works or not. It works perfectly well.
 Yes but I was not enjoyed by the idea of supporting 2 ways of controlling exactly
the same concept (rate), and so having duplicated input/gui code.
 Extending the current rate path for negative rate should not be difficult 
*when* DEMUX_CAN_CONTROL_RATE set pb_ts_rescale to false.

 Anyway, FF should at least be able to work, but I see it is commented out
in live555.cpp. My commit log was:

"Added DEMUX_CAN_CONTROL_RATE and DEMUX_SET_RATE implementation based
 on Glen Gray patch.
 (The code is commented until it is confirmed to compil/work.)"

As no one has confirmed it working, it is still commented out...

-- 
fenrir