Re: CR: fix for Bug 220782: using the ?start=xx URL parameter causes playback to never start

Thanks for the review Milko. I have made the suggested alternative
fix and checked in the code to both head and 310 branch.

Qiang

At 08:46 PM 6/25/2008, Milko Boic wrote:

This fix is not quite
correct. There are two problems:

1.) The applied offset is not correct. It should be
ulMaxRendererDispatchTime += m_ulStartTime -
m_ulDelay;

2.) Second issue is more involved and stems from a flaw in RecordControl
and RecordSource APIs.

m_ulStartTime - m_ulDelay offset is already communicated to
the record control as packet associated time-stamp offset:

m_pRecordControl->OnPacket(pPacket, m_ulStartTime - m_ulDelay);

However, record control does not provide for the return of the passed in
offset:

STDMETHODIMP

HXRecordControl::PacketReady(HX_RESULT status, IHXPacket* pPacket)

HX_RESULT

HXRecordControl::GetPacket(UINT16 usStreamNumber, IHXPacket*&
pPacket)

Conceptually, the time-stamp offset is custom for each packet to allow
for stream splicing by adjusting the time-stamp in datatype agnostic
manner. Treating it globally limits the usefulness of packet offset
and thus engine capabilities. It is true enough that this concept
is broken in other places - HXRecordControl for example. However,
we should try to limit the flaw so it is easier to fix later when
needed. Ultimately, the time-stamp offset needs to be passed and
preserved through all the components packet travels.

What to do now:

Limit the flaw to RecordControl and have
RecordControl::GetLatestTimestampWritten() and GetLatestTimestampRead()
return offset time-stamps so they can be directly to the
timeline:

HX_RESULT HXRecordControl::SendPacket(IHXPacket* pPacket, INT32
lTimeOffset)

{

...

if (m_pRecordSource)

{

- UINT32 ulTime =
pPacket->GetTime();

+ UINT32 ulTime =
pPacket->GetTime() - lTimeOffset;

HX_RESULT

HXRecordControl::OnPacket(IHXPacket* pPacket, INT32 nTimeOffset)

{

...

+ m_lTimeOffset = nTimeOffset;

#if
defined
(HELIX_FEATURE_RECORDCONTROL_MERGESORT)

if
(m_bDisableRSMergeSort)

{

nResult = WritePacket(pPacket,
nTimeOffset);

}

else
if (m_pMergeSorter)

{

// Save the time offset

-
m_lTimeOffset = nTimeOffset;

HX_RESULT

HXRecordControl::GetPacket(UINT16 usStreamNumber, IHXPacket*&
pPacket)

{

...

if (pPacket)

{

- UINT32 ulTime =
pPacket->GetTime();

+ UINT32 ulTime = pPacket->GetTime() -
m_lTimeOffset; // This is not quite right but best we can do given
that offset is not being passed through the record source. It works
as long as the packet offsets are not changing within the source.
Currently, there are no such cases.

if
(m_bFirstTimestampRead)

In addition, above fix corrects network source record control
reading as well network source super-buffer overrun protection:

// If
we are playing from record control and we are

// forward accelerated, then it's
possible for accelerated

// playback to overtake the write
point. Here we detect

// if we are about to overtake the
write point. If we are,

// then go back to normal
velocity.

if
(m_bPlayFromRecordControl && m_pRecordControl
&&

m_pPlayer->GetVelocity()
> HX_PLAYBACK_VELOCITY_NORMAL &&

!m_pRecordControl->IsFinishedWriting() &&

!m_bDisableRecordSourceOverrunProtection)

{

UINT32 ulPlayTime =
m_pPlayer->GetCurrentPlayTime();

UINT32 ulWriteTime =
m_pRecordControl->GetLatestTimestampWritten();

if (ulWriteTime
> m_ulRecordSourceOverrunProtectionTime &&

ulPlayTime > (ulWriteTime -
m_ulRecordSourceOverrunProtectionTime))

{

HXLOGL2(HXLOG_TRIK, "Playback time (%lu) getting close to record
"

"control write time (%lu), resetting velocity",

ulPlayTime, ulWriteTime);

// We are getting close to overrun,
so reset velocity

m_pPlayer->SetVelocity(100, FALSE, FALSE);

}

}

Milko

At 07:36 PM 6/25/2008, Qiang Luo wrote:

Synopsis:

Fix for Bug 220782: using the ?start=xx URL parameter causes playback to
never start

Overview:

For http file-source, the renders get packets from the supper
buffer. Before reading racket from the recorded file and inserting
it into event queue, the core computes ulMaxRendererDispatchTime and
checks it against the recorder's last read time-stamp. When we have
?start=xx in the http url parameter, the check would fail. The
player will be in a loop where HXFileSource::GetEvent() will return
HXR_WOULD_BLOCK. The fix is to account for the non-zero start time
when we compute the ulMaxRendererDispatchTime value.

File modified:

client/core/hxflsrc.cpp

The diff:

Index: hxflsrc.cpp

===================================================================

RCS file: /cvsroot/client/core/hxflsrc.cpp,v

retrieving revision 1.126.2.2

diff -u -w -1 -0 -r1.126.2.2 hxflsrc.cpp

--- hxflsrc.cpp 23 Oct 2007 20:57:33
-0000 1.126.2.2

+++ hxflsrc.cpp 26 Jun 2008 02:28:47 -0000

@@ -1763,20 +1763,23 @@

}

#if defined(HELIX_FEATURE_RECORDCONTROL)

if (m_bPlayFromRecordControl &&
m_pRecordControl)

{

UINT32
ulMaxRendererDispatchTime = m_pPlayer->ComputeFillEndTime(

m_pPlayer->GetInternalCurrentPlayTime(),

m_pPlayer->GetGranularity(),

m_ulMaxPreRoll +
MAX_INTERSTREAM_TIMESTAMP_JITTER);

+ // account for
the start time.

+
ulMaxRendererDispatchTime += m_ulStartTime;

+

theErr =
HXR_WOULD_BLOCK;

// We
supply packets from the record control only when needed

// since
sparse streams may result in excessive buffering of packets due to

//
interleaving with non-sparse packets.

if
((!m_pRecordControl->IsRead()) ||

(((LONG32) (ulMaxRendererDispatchTime -
m_pRecordControl->GetLatestTimestampRead())) >= 0))

{

IHXPacket* pPacket = NULL;

Thanks,

Qiang

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev