[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-clientapps-dev
Subject: [Clientapps-dev] RE: [Client-dev] RESEND: Helix Seeking [while
From: <Yury.Ramanovich () nokia ! com>
Date: 2008-08-20 19:55:08
Message-ID: 654E856A5136DF4382BE4B57B5E93A41083055B8 () daebe101 ! NOE ! Nokia ! com
[Download RAW message or body]
Anuj
Well this is how it works currently even without my change; we can take
action point for the future to make onpreseek and onpostseek have
different times passed to renderers.
Thanks
Yury
>-----Original Message-----
>From: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
>Sent: Tuesday, August 19, 2008 2:47 PM
>To: Ramanovich Yury (Nokia-D-MSW/Dallas); ehyche@real.com;
>clientapps-dev@helixcommunity.org;
>client-dev@helixcommunity.org;
>protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
>Subject: RE: [Client-dev] RESEND: Helix Seeking [while
>streaming]Behavior Modification (aka ApproxSeek)
>
>Hi Yury,
>
>Regarding HXPlay::HandleApproxSeekResponse() internally
>calling SrcInfo->Seek(), I have my doubts as to would it be
>correct thing to do as logically PreSeek and PostSeek signify
>two separate events before and after Seek respectively.
>Forcing PreSeek() AFTER actual seek defeats the whole purpose
>of having two different events in first place. I understand it
>would be more work as we need to take care of handling
>PostSeek events in Renderers which are thus far assuming
>PreSeek and PostSeek times to be same but I still believe it
>should be worth it to maintain the logical separation between
>PreSeek and PostSeek by reflecting different time in two
>events if so is the case and not force PreSeek time to match
>PostSeek time for sake of code reuse.
>
>thnx & regds
>AD
>
>
>-----Original Message-----
>From: client-dev-bounces@helixcommunity.org
>[mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>ext Yury.Ramanovich@nokia.com
>Sent: Tuesday, August 19, 2008 11:04 AM
>To: ehyche@real.com; clientapps-dev@helixcommunity.org;
>client-dev@helixcommunity.org;
>protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
>Subject: RE: [Client-dev] RESEND: Helix Seeking [while
>streaming]Behavior Modification (aka ApproxSeek)
>
>Hi Eric
>
>I can answer a couple of comments so far.
>
>3] we would like to have UseApproxSeek disabled by default
>because we didn't want to introduce regression into current
>helix streaming behavior.
>On microplayer we also seek using new time from PLAY response
>and we've had problems with certain server(s) where they
>send some packets that don't correspond to whatever was in
>rtp-info line.
>
>4] HXPlay::HandleApproxSeekResponse() internally calls
>SrcInfo->Seek() Which sends OnPreSeek() to renderers again
>with new seek time; later on
>OnPostSeek()
>Called with the same new seek time. So it should not cause
>problems with renderers Since (onPreseek() -- onPostseek() )
>behaviour remains the same as before...
>
>Thanks
>Yury
>>-----Original Message-----
>>From: ext Eric Hyche [mailto:ehyche@real.com]
>>Sent: Tuesday, August 19, 2008 7:45 AM
>>To: Ramanovich Yury (Nokia-D-MSW/Dallas);
>>clientapps-dev@helixcommunity.org;
>>client-dev@helixcommunity.org;
>>protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
>>Cc: 'Milko Boic'
>>Subject: RE: [Client-dev] RESEND: Helix Seeking [while streaming]
>>Behavior Modification (aka ApproxSeek)
>>
>>Yury,
>>
>>I have some general comments, and then depending on the outcome of my
>>question to Milko, I'll have some comments on the code changes itself.
>>
>>Milko, can you comment on my points #1 and #2 below?
>>I know you originally suggested putting this behavior behind a new
>>ApproxSeek API. But I think this new behavior would benefit
>QuickSeek()
>>as well.
>>
>>1) Adjusting the seek time based upon the returned
>> time in the PLAY response is a really useful change.
>> But I don't really want to have both QuickSeek
>> and ApproxSeek.
>>
>> QuickSeek() is a seek that a player
>> can do if it knows it will be doing lots of quick
>> seeks rapidly without playing back in between these
>> quick seeks. Adjusting the seek time based on
>> the PLAY response time is a great optimization
>> for QuickSeek as well, because in QuickSeek()
>> you know you just want to just display the keyframe
>> prior to the seek time, and that you expect to
>> be called with QuickSeek() again, as the user
>> drags the seek bar. So I think this optimization
>> of adjusting the seek time should be used on
>> QuickSeek() when we are playing from a NetSource.
>>
>> I think all your underlying code can still be
>> used, but I would like this to be activated
>> by the existing QuickSeek() call rather than
>> a new ApproxSeek.
>>
>>2) The same actually applies when playing from a
>> FileSource. In this case, the timestamp of the
>> first video packet returned after the fileformat
>> is seeked corresponds exactly to the starting
>> time of the PLAY response when a NetSource is
>> seeked. So we can actually do the same thing
>> for FileSource that you have done with NetSource -
>> when we do a QuickSeek(), then adjust the seek
>> time based upon the timestamp of the first
>> video packet returned after the seek. So I think
>> we should implement this same optimization
>> for FileSource's as well as NetSource's.
>>
>>3) I like the idea of having this behavior controlled by
>> a pref. But I think the default of the pref should
>> be enabled rather than disabled.
>>
>>4) So it sounds like that when the renderer gets called
>> OnPreSeek(), the *original* seek time is used, but
>> when it gets called with OnPostSeek(), the *updated*
>> seek time is used. If that's correct, then this might
>> cause a problem in some renderers, since most renderers
>> assume that the seek-to time will be the same in
>> OnPreSeek() and OnPostSeek(). In some cases, renderers
>> just pretty much ignore the seek-to time in OnPostSeek().
>>
>> However, this new behavior of looking for a potentially
>> updated seek time in OnPostSeek() is going to be most
>> beneficial in video renderers, because we won't have
>> to decode all the frames between the keyframe and the
>> seek time before we can start displaying frames. If
>> our seek time gets adjusted to the same as the time
>> of the keyframe, then we will wind up bltting the
>> first frame we decode. And this will wind up
>> giving us faster QuickSeek() times.
>>
>> So really, the most important place we need to
>> make sure we look at the seek-to time in OnPostSeek()
>> is in the base video renderer
>(datatype/common/vidrend/vidrend.cpp).
>> Making the change in the base video renderer will
>> benefit almost all of the video renderers, since almost
>> all of them derive from the base video renderer.
>>
>>
>>=======================================
>>Eric Hyche (ehyche@real.com)
>>Senior Technical Lead
>>RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: client-dev-bounces@helixcommunity.org
>>>[mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>>>Yury.Ramanovich@nokia.com
>>>Sent: Monday, August 18, 2008 5:59 PM
>>>To: clientapps-dev@helixcommunity.org;
>client-dev@helixcommunity.org;
>>>protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
>>>Subject: [Client-dev] RESEND: Helix Seeking [while streaming]
>>Behavior
>>>Modification (aka ApproxSeek)
>>>
>>>
>>>
>>> ______________________________________________
>>> From: Ramanovich Yury (Nokia-D-MSW/Dallas)
>>> Sent: Friday, August 15, 2008 10:46 AM
>>> To: clientapps-dev@helixcommunity.org;
>>'client-dev@helixcommunity.org'; protocol-
>>>dev@helixcommunity.org
>>> Cc: nokia-private-dev@helixcommunity.org
>>> Subject: Helix Seeking [while streaming]
>>Behavior Modification (aka ApproxSeek)
>>>
>>> Modified by: yury.ramanovich@nokia.com
>>>
>>> Reviewed by:
>>>
>>> Date: 08/15/2008
>>>
>>> Project: SymbianMmf_rel
>>>
>>> ErrorId: CR 417-10500
>>>
>>> Synopsis: Helix Seeking [while streaming] Behavior
>>Modification aka ApproxSeek.
>>>
>>> Overview: Current Helix seek implementation uses the
>>client requested
>>>start time in the RTSP PLAY request as the seek time. This change
>>>modifies Helix's seeking behaviour during streaming to use
>>the starting
>>>time returned by the streaming server in Range header of RTSP PLAY
>>>response. The new seeking behaviour will be known as
>>"Approximate Seek"
>>>(ApproxSeek)
>>>
>>> Solution: when seeking during streaming, helix will
>>initially issue
>>>Seek() with client seek time, but will replace this seek time
>>with the
>>>time returned by server in Range header of RTSP PLAY response. That
>>>will be the time at which playback will resume. The new
>functionality
>>>is added as part of IHXApproxSeek interface to HXPlayer. This
>>interface
>>>is similar to QuickSeek which is on HEAD branch. It will include
>>>ApproxSeek() method. The use of new API is determined during runtime
>>>based on two factors: if this is a streaming url ( to
>minimize impact
>>>on non-streaming use cases) , and whether UseApproxSeek
>>config flag is set to 1. By default, UseApproxSeek is set to
>0, meaning
>>ApproxSeek is disabled. If UseApproxSeek is absent from
>config file, or
>>either of two factors mentioned above is not true, the regular Helix
>>Seek behavior will be used.
>>>
>>> ApproxSeek() method internally calls HXPlayer::Seek()
>>method and also
>>>sets HXPlayer internal boolean m_bInApproxSeek indicating
>>that HXPlayer
>>>is in ApproxSeek; the value of this flag can be queried by Netsource
>>>via InApproxSeek(). When RTSP PLAY response is received from server,
>>>Range header time values are saved by RTSPClientProtocol during
>>>HandlePlayResponse(). Then RTSPProtocol will query
>>HXNetSource to find
>>>out if player is in ApproxSeek mode via InApproxSeek(). If
>>this is the
>>>case then new seektime is obtained from RTSPClientProtocol
>and passed
>>>to HXNetSource::HandleApproxSeekResponse
>>>() method. This method internally calls
>>>HXPlayer::HandleApproxSeekResponse() where new seek time is
>>propagated
>>>to CAudioPlayer, SourceInfo which updates renderers
>>information, and HXNetSource which updates CBufferManager.
>>Renderers will obtain new seektime via OnPostSeek().
>>>
>>> HXPlayer::ApproxSeek() is called by
>>HXMMFPlayCtrl::Seek() only if both
>>>of the following conditions are satisfied: UseApproxSeek
>>config flag is
>>>equal to 1 in helix configuration file and it has been
>>determined that
>>>it is a streaming case. The url passed to helix via
>>>HXMMFPlayCtrl::OpenUrl or HXMMFPlayCtrl::OpenRequest is saved
>>in HXMMFPlayCtrl, then CHXURL::IsNetworkProtocol() API is used to
>>determine whether this is a streaming case or not.
>>>
>>> Otherwise, HXPlayer::Seek() is called and regular
>>seeking behavior is in use.
>>>
>>> Changed logging level from 3 to 2 in
>>CMdfVideoRenderer::OnPreSeek()
>>>and CMdfVideoRenderer::OnPostSeek().
>>>
>>>
>>>
>>> Files modified:
>>> /client/core/hxbsrc.h
>>> /client/core/hxntsrc.cpp
>>> /client/core/hxntsrc.h
>>> /client/core/hxplay.cpp
>>> /client/core/rtspprotocol.cpp
>>> /client/core/pub/hxplay.h
>>> /clientapps/symbianMmf/hxmmfplayctrl.cpp
>>> /clientapps/symbianMmf/hxmmfplayctrl.h
>>> /clientapps/symbiancommon/config/R1_Mobile_4_0_Factory.cfg
>>> /common/include/hxcore.h
>>> /common/include/hxiids.h
>>> /datatype/mdf/video/renderer/mdfvidrend.cpp
>>> /protocol/rtsp/rtspclnt.cpp
>>> /protocol/rtsp/pub/rtspclnt.h
>>>
>>> Files added:
>>> None
>>>
>>> Here's email thread that refers to ApproxSeek API.
>>> <<RE: [Protocol-dev] RE: [Nokia-private-dev] Client handling
>>>forwrongRange field on
>>>Seekresponse>>
>>> Cvs diff :
>>>
>>> <<approxseek_diff_2_a.txt>>
>>>
>>>
>>> Image Size and Heap Use impact: minor.
>>>
>>> Module Release testing (STIF) : N/A
>>>
>>> Test case(s) Added : No
>>>
>>> Memory leak check performed : Yes. No new memory leaks
>>introduced.
>>>
>>> Platforms and Profiles Build Verified:
>>helix-client-s60-50-mmf-mdf-arm
>>>
>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>
>>> Branch: 210Cays, 221Cays, HEAD?
>>
>>
>>
>
>_______________________________________________
>Client-dev mailing list
>Client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/client-dev
>
_______________________________________________
Clientapps-dev mailing list
Clientapps-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/clientapps-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic