This seems like a hack to mask a problem elsewhere. While
that has it's
place, I always like to understand when that's what we're
doing. Is there
a server bug that isn't actually sending reliable packets
reliably? Why is
this an issue for live and not on-demand streams?
JEff
At 11:58 AM 10/4/2006, Anderson Luiz Brunozi wrote:
>Hi, Henry,
>
>I've followed your sugestion, and disbled the reliable
packet check
>enforcement for live streams. Now, it seems to work
perfectly!
>
>However, I've noticed that the m_bIsLive variable was
not set. So tried
>setting it, on the function
RTSPTransport::addStreamInfo(), in the file
>protocol/transport/common/system/rtsptran.cpp. It works,
but I'm not sure
>this is the right place for it. You might want to check
that.
>The new diff file is attached.
>
>
>Att,
>
> Anderson Luiz Brunozi
>
>
>
>-----Mensagem original-----
>De: Henry Ping [mailto:ping real.com]
>Enviada em: segunda-feira, 2 de outubro de 2006 16:01
>Para: Anderson Luiz Brunozi; protocol-devhelixcommunity.org
>Assunto: RE: [Protocol-dev] CR-client: Fix bug 5332:
Client stops
>processingevents after an event packet is lost.
>
>
> > -----Original Message-----
> > From: Anderson Luiz Brunozi [mailto:abrunozicpqd.com.br]
> > Sent: Monday, October 02, 2006 11:44 AM Ping
> > To: Henry Ping; protocol-devhelixcommunity.org
> > Subject: RES: [Protocol-dev] CR-client: Fix bug
5332: Client
> > stops processingevents after an event packet is
lost.
> >
> > Hi, Henry,
> >
> > Sorry. I've not got your reply to my previous
message.
> > In fact, it's because I've not receveid any
replies since
> > I've sent the solution proposal to the list, that
I thought
> > it was ok, and tried sending it as CR.
>
>No problem, the email server can act up sometimes.
>
> > I've just read your message now, from the online
archives.
> > Just to make sure I've understood it, did you mean
something
> > like this?
> >
> >
> > if ((!m_bFastStart || bPlaying)
&&
> > (!m_bIsEnded
&&
> > m_pPacketDeque->size() <
MAX_QUEUED_PACKETS &&
> > frontPacket->IsLostPacket()
&&
> > ulTimeInQueue < ulMinimumToBuffer
&&
> > TimeInBuffer <
> > Timeval((float)ulMinimumToBuffer / 1000.0)) ||
> > (!m_bIsLive &&
> > frontPacket->GetReliableSeqNo()
!=
> > (UINT16)(m_uReliableSeqNo +
> > frontPacket->IsReliable())))
> > {
> > pPacket = 0;
> >
> > m_status = TRANSBUF_FILLING;
> > return HXR_BUFFERING;
> > }
> >
>
>Yes. If this fixes it, I'd add some comment to explain
why we don't check
>ReliableSeqNo for live.
>
>-->Henry
>
> > I'll now try it this way, and report back soon.
> >
> > Or should I still use the m_bSparseStream to
disable the time
> > enforcement, as Eric sugestted?
> >
> >
> > Thanks,
> >
> > Anderson Luiz Brunozi
> >
> >
> >
> > -----Mensagem original-----
> > De: Henry Ping [mailto:pingreal.com]
> > Enviada em: segunda-feira, 2 de outubro de 2006
14:55
> > Para: Anderson Luiz Brunozi; protocol-devhelixcommunity.org
> > Assunto: RE: [Protocol-dev] CR-client: Fix bug
5332: Client
> > stops processingevents after an event packet is
lost.
> >
> >
> > Hi, Anderson
> >
> > I responsed to your previous inquiry on this
problem as archived here:
> > http://lists.helixcommunity.org/pipermail/player-d
ev/2006-Sept
> > ember/002506.h
> > tml
> >
> > Have you seen it & tried my proposed solution
which is
> > different from yours?
> >
> > -->Henry
> >
> > > -----Original Message-----
> > > From: protocol-dev-bounceshelixcommunity.org
> > > [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf
> > Of Anderson
> > > Luiz Brunozi
> > > Sent: Monday, October 02, 2006 10:08 AM Ping
> > > To: protocol-devhelixcommunity.org
> > > Subject: [Protocol-dev] CR-client: Fix bug
5332: Client stops
> > > processingevents after an event packet is
lost.
> > >
> > > Modified by: abrunozicpqd.com.br
> > > Date: 09:28:06
> > > Project: protocol
> > > Bug Number: 5332
> > > Bug URL:
https://bugs.helixcommunity.org/show_bug.cgi?id=5332
> > >
> > >
> > > Synopsis:
> > > ---------
> > > On transbuf.cpp, when receving packets for an
sparse
> > stream, like an
> > > event stream, after a packet is lost it
enters an state of
> > indefinite
> > > buffering, as packets arrive and keep getting
into the
> > queue, but no
> > > packet get out of it while the front packet
is a lost packet.
> > >
> > >
> > > Overview:
> > > ---------
> > >
> > > The problem has been detected in this code in
transbuf.cpp:
> > >
> > > if ((!m_bFastStart || bPlaying)
&&
> > > (!m_bIsEnded
&&
> > > m_pPacketDeque->size() <
MAX_QUEUED_PACKETS &&
> > > frontPacket->IsLostPacket()
&&
> > > ulTimeInQueue < ulMinimumToBuffer
&&
> > > TimeInBuffer <
Timeval((float)ulMinimumToBuffer /
> > > 1000.0)) ||
> > > (frontPacket->GetReliableSeqNo()
!=
> > > (UINT16)(m_uReliableSeqNo
+
> > > frontPacket->IsReliable())))
> > > {
> > > pPacket = 0;
> > >
> > > m_status = TRANSBUF_FILLING;
> > > return HXR_BUFFERING;
> > > }
> > >
> > >
> > > Because of last OR operator in this if()
clause, after an
> > > event packet, the last condition is always
true, as front
> > > packet in queue in one that has been filled
with a
> > > placeholder packet marked as lost, and thus
> > > frontPacket->IsReliable() == 0.
> > > This was causing it to always return
HXR_BUFFERING, for a
> > > sparse stream.
> > >
> > > The solution was to initialize the
m_bSparseStream in the
> > > Init() function, and use it in function
GetPacketFromQueue()
> > > for choosing the condition that decides
whether to return
> > > HXR_BUFFERING.
> > >
> > > For non-sparse streams the condition has been
kept unchanged,
> > > as it seems to be working. (Even I don't
undestand exactly how).
> > >
> > > A new condition has been created for sparse
streams, which
> > > use a small value for packet queue max limit,
and does not
> > > have the time enforcement. Also the last OR
operator has been
> > > change to an AND operator.
> > >
> > > if ((!m_bFastStart || bPlaying)
&&
> > > (!m_bIsEnded
&&
> > > m_pPacketDeque->size() <
MAX_QUEUED_SPARSE_PACKETS &&
> > > frontPacket->IsLostPacket()
&&
> > > (frontPacket->GetReliableSeqNo() !=
> > > (UINT16)(m_uReliableSeqNo +
> > > frontPacket->IsReliable())))) {
> > > pPacket = 0;
> > >
> > > m_status = TRANSBUF_FILLING;
> > > return HXR_BUFFERING;
> > > }
> > >
> > >
> > >
> > > Files Modified:
> > > ---------------
> > > [RCS file:
> >
/cvsroot/protocol/transport/common/system/transbuf.cpp,v]:
> > > - created a new constant
MAX_QUEUED_SPARSE_PACKETS for use
> > > with sparse streams;
> > > - m_bSparseStream is initialized in the
Init() function;
> > > - added special condition in the function
> > > GetPacketFromQueue() for deciding whether to
return
> > > HXR_BUFFERING (The condition for non-sparse
streams seems to
> > > be working, and has not been change).
> > >
> > >
> > >
> > > Image Size and Heap Use impact (Client
-Only):
> > >
----------------------------------------------
> > > <Description of image size and heaps size
impact. >
> > >
> > >
> > > Platforms and Profiles Build Verified:
> > > --------------------------------------
> > > Windows is the only platform used for
testing, but I believe
> > > it applies to all platforms.
> > >
> > >
> > > Platforms and Profiles Functionality
verified:
> > >
----------------------------------------------
> > > Windows is the only platform used for
testing, but I believe
> > > it applies to all platforms.
> > >
> > >
> > > Branch:
> > > -------
> > > hxclient_1_5_0_cayenne
> > >
> > >
> > > Copyright assignment:
> > > ---------------------
> > >
> > > In consideration for RealNetworks'
hosting and
> > maintenance
> > > of my modification, I agree to
assign to
> > RealNetworks full
> > > copyright ownership of the code
included in the attached
> > > patch, and agree that RealNetworks
has no duty of
> > > accounting
> > > to me for it. I warrant that this
code is
> > entirely original
> > > to and owned by me, that I can
legally grant the
> > copyright
> > > assignment, and that my
contribution does not
> > > violate any other
> > > person's rights, and laws or
breach any contract.
> > > I understand
> > > that RealNetworks may license this
code under
> > RPSL, RCSL,
> > > and/or any other license at
RealNetworks'
> > > discretion, and use
> > > the code in any way.
> > >
> > >
> > >
> > >
> > >
> > > Att,
> > >
> > > Anderson Luiz Brunozi
> > >
> > >
> > >
> > >
> > >
> > >
> > > <<protocol.diff>>
> > >
> >
>
>
>
>_______________________________________________
>Protocol-dev mailing list
>Protocol-devhelixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
|