Hi Eric,
   We have a similar problem with mdf video renderer & XPS. Video only
stream is played through XPS which uses FileSource for playback. 

Snippet from your mail...
>We should not automatically go into buffering if packets are 
>being delivered late. We already have a very flexible 
>mechanism for knowing when to drop frames if they are too late 
>to display. I think a more reasonable criteria for going into 
>buffering for would be if we have dropped X percent of frames 
>over the last Y milliseconds, and X and Y should be arrived at 
>by experimentation.

The above mentioned logic would work if the frames are coming in and
delayed. But there are cases where video packets are not even getting
into the system (may be network congestion). In case of video only
session, the system time keeps moving and the renderer does not inform
of the dry case, resulting in video freeze without proper notification
to the user. 

I'm inclined towards what Lovish proposed earlier. Ie.. Checking for a
specified offset between the last packet and the ontimesync value. 

On OnTimeSync function...
#define REBUFFER_TOLERANCE_IN_MSEC    1000
if( (onTimesyncvalue - m_ulLastPktTime) > REBUFFER_TOLERANCE_IN_MSEC)
{
   Rebuffer()
}

Could you please advise on this ?

I have few more questions related to this ....
* Do we need to report buffer status on all cases or this is really
required only in case of vid only stream ?
* What is the purpose of lTimeOffset on IHXRenderer::OnPacket api ?

Thanks,
Rajesh.


>-----Original Message-----
>From: datatype-dev-bounces at helixcommunity.org 
>[mailto:datatype-dev-bounces at helixcommunity.org] On Behalf Of 
>ext Eric Hyche
>Sent: Friday, November 03, 2006 10:27 AM
>To: 'Lovish Dhawan'
>Cc: datatype-dev at helixcommunity.org
>Subject: RE: [datatype-dev] CR: Rebuffering of Video only 
>presenation whenvideostream is running behind
>
>
>Lovish,
>
>Comments below...
>
>> -----Original Message-----
>> From: Lovish Dhawan [mailto:ldhawan at real.com]
>> Sent: Wednesday, November 01, 2006 9:27 AM
>> To: ehyche at real.com
>> Cc: datatype-dev at helixcommunity.org
>> Subject: Re: [datatype-dev] CR: Rebuffering of Video only 
>presenation 
>> when videostream is running behind
>> 
>> Hi Eric,
>> 
>> Please find the attached vidrend.zip having the diff files.
>> 
>> 1. What is the purpose of this check?
>> 
>> (ulTime > (m_ulLastFrameTime - m_lTimeOffset))
>> 
>> m_ulLastFrameTime is poorly named. It should really be 
>> m_ulLastPacketTime since it represents the timestamp of the last 
>> received packet. The purpose of this logic is to trigger rebuffering 
>> if timestamp
>received 
>> in OnTimeSync is already past the last packet time. Since 
>the renderer 
>> is usually expected to receive packets "preroll" ms in advance, this 
>> logic already has built-in threshhold of preroll. i.e. instead of 
>> triggering
>rebuffer 
>> when curent time lastPacketTime-preroll, it is triggered only when
>timeline 
>> time is already past the last packet time. Please let me know if
>additional 
>> threshhold needs to be added.
>> 
>
>We should not automatically go into buffering if packets are 
>being delivered late. We already have a very flexible 
>mechanism for knowing when to drop frames if they are too late 
>to display. I think a more reasonable criteria for going into 
>buffering for would be if we have dropped X percent of frames 
>over the last Y milliseconds, and X and Y should be arrived at 
>by experimentation.
>
>
>Eric
>
>=============================================
>Eric Hyche (ehyche at real.com)
>Technical Lead
>RealNetworks, Inc. 
>
>> 32-bit wrap around is now handled. (copy of existing code 
>> from baserend.cpp)
>> 
>> 2. This rebuffer logic is based on packets being received 
>> late and do not relate to frame time...so not using any last frame
>blt/drop time.
>> 
>> Thanks & Regards
>> 
>> Lovish
>> 
>> 
>> ----- Original Message ----- 
>> From: "Eric Hyche" <ehyche at real.com>
>> To: "'Lovish Dhawan'" <ldhawan at real.com>; 
>> <datatype-dev at helixcommunity.org>
>> Sent: Tuesday, October 31, 2006 6:10 PM
>> Subject: RE: [datatype-dev] CR: Rebuffering of Video only 
>> presenation when 
>> videostream is running behind
>> 
>> 
>> >
>> > What is the purpose of this check?
>> >
>> > (ulTime > (m_ulLastFrameTime - m_lTimeOffset))
>> >
>> > Seems like there are a couple of problems with this.
>> > First, if you want to cause buffering if the video stream
>> > falls far enough behind, then it seems like you need to
>> > check against some sort of threshold (i.e. - if the
>> > difference between the current frame to be blitted
>> > and the current time is great enough, then rebuffer.
>> > But I don't see a comparison against any sort of
>> > threshold here.
>> >
>> > The second problem is that this calculation won't
>> > handle a 32-bit wraparound in times.
>> >
>> > Also note that there is logic in the base video renderer
>> > to drop frames when the frames are too far behind (either
>> > pre-decode or post-decode, depending on whether a certain
>> > preprocessor define is enabled). So you'll need to make
>> > sure that m_ulLastFrameTime is done at the proper point -
>> > if frames are being dropped, then m_ulLastFrameTime
>> > may not get updated for several frames. (I haven't looked
>> > at the code - this is my recollection.)
>> >
>> > Eric
>> >
>> > =============================================
>> > Eric Hyche (ehyche at real.com)
>> > Technical Lead
>> > RealNetworks, Inc.
>> >
>> >> -----Original Message-----
>> >> From: datatype-dev-bounces at helixcommunity.org
>> >> [mailto:datatype-dev-bounces at helixcommunity.org] On Behalf Of
>> >> Lovish Dhawan
>> >> Sent: Tuesday, October 31, 2006 6:22 AM
>> >> To: datatype-dev at helixcommunity.org
>> >> Subject: [datatype-dev] CR: Rebuffering of Video only
>> >> presenation when videostream is running behind
>> >>
>> >> Synopsis:
>> >> This change is to fix REBUFFER_ON_VIDEO support. Needed by CE
>> >> manufactures who want to use this feature to pause the
>> >> timeline when video is running behind (to avoid video freeze).
>> >>
>> >>
>> >> Overview:
>> >> This change fixes for  Rebuffering of Video only presentation
>> >> when video stream is running behind.
>> >>
>> >> Files Added:
>> >>
>> >>
>> >> Files Modified:
>> >> datatype/common/vidrend/vidrend.cpp -
>> >> datatype/common/vidrend/vidrend.h -
>> >>
>> >> Image Size and Heap Use impact (Client -Only):
>> >> None.
>> >>
>> >> Platforms and Profiles Affected:
>> >> None. (This feature is to be explicitly enabled)
>> >>
>> >>
>> >> Distribution Libraries Affected:
>> >> None
>> >>
>> >> Distribution library impact and planned action:
>> >> None
>> >>
>> >> Platforms and Profiles Build Verified:
>> >>
>> >> BIF branch  -> hxclient_1_5_0_cayenne_restricted
>> >> Target(s) ->splay
>> >> Profile ->helix-client-mobile-ezx
>> >> SYSTEM_ID=linux-2.2-libc6-gcc32-i586
>> >>
>> >> Branch:
>> >> HEAD, hxclient_1_5_0_cayenne
>> >>
>> >> Files Attached:
>> >> Vidrend.zip containing the 2 diff files Vidrend.cpp.diff and
>> >> vidrend.h.diff
>> >>
>> >> Regards,
>> >> Lovish
>> >>
>> > 
>> 
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev at helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>