> -----Original Message-----
> From: gang.1.shen at nokia.com [mailto:gang.1.shen at nokia.com] 
> Sent: Thursday, June 07, 2007 2:36 PM
> To: ehyche at real.com; helix-client-dev at helixcommunity.org
> Subject: RE: Trickplay 
> 
> 
> Thanks a lot. That answers my question. 
> 
> It looks like there is a need for renderer to selectively push frames
> (non-key frames) to decoders based on magnitude of velocity, for
> all-frames mode. That would save decoder from decoding frames that are
> supposed to be skipped. Is that what Helix has in its video renderer?
> Btw, my concern is on our MDF renderer; we'd like to see how Helix
> renderer works. 
> 

In the base video renderer (from which the RealVideo renderer and
MP4 video renderer and WMV renderer derive), we have decided to
try and render as much as we can in all-frames mode before switching
to keyframe mode. Of course, the TLC can override this decision
by simply setting keyframe mode to TRUE when it calls SetVelocity().
If you *know* on your platform, for instance, that all-frames mode
is not feasible beyond 1x or 2x then you can always have the TLC
enforce that when it calls SetVelocity.

Eric

> -GS
> 
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche at real.com] 
> Sent: Thursday, June 07, 2007 12:00 PM
> To: Shen Gang.1 (Nokia-TP-MSW/Dallas);
> helix-client-dev at helixcommunity.org
> Subject: RE: Trickplay 
> 
> 
> The renderer makes the decision about when frames are dropped. If the
> user specified that it should autoswitch from all-frames mode to
> keyframe-mode, then the renderer will try to play all the 
> frames it can.
> When it realizes that it is dropping frames about a certain rate, then
> it will tell the client core that it wants to go to keyframe-mode. At
> that point, the client core tells the file format plugin that it is
> going to keyframe mode.
> 
> The file format may or may not at that point start providing just
> keyframes. But the fileformat proxy in the client core will from that
> point on filter out everything but keyframe packets.
> 
> Does that answer your question?
> 
> Eric
> 
> =============================================
> Eric Hyche (ehyche at real.com)
> Technical Lead
> RealNetworks, Inc.  
> 
> > -----Original Message-----
> > From: gang.1.shen at nokia.com [mailto:gang.1.shen at nokia.com]
> > Sent: Thursday, June 07, 2007 12:42 PM
> > To: ehyche at real.com; helix-client-dev at helixcommunity.org
> > Subject: Trickplay
> > 
> > Hi, Eric,
> > 
> > I have a question regarding "trickplay" design in 
> > https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP
> > -SOD-001-TrickPlay.html
> > <https://helix-client.helixcommunity.org/nonav/2005/devdocs/TK
> > P-SOD-001-TrickPlay.html> .
> > 
> > How does Helix avoid a overflow during fast forward? If fileformat 
> > (optionally) deliver packets differently based on the 
> magnitude of the
> 
> > playback velocity, there would be more packets delivered to video 
> > renderer than needed in a fast forward playback. Which 
> component will 
> > drop these extra frames?
> > 
> > Thanks,
> > 
> > Gang Shen
> > 
> > 
>