From ldhawan at real.com Mon Apr 2 22:11:39 2007
From: ldhawan at real.com (Lovish Dhawan)
Date: Mon Apr 2 22:37:33 2007
Subject: [Protocol-dev] Re: [Client-dev] 3GPP Rate Adaptation implementation
issues
References:
Message-ID: <00e501c775ae$91f9e060$7d01a8c0@user>
3GPP Rate Adaptation implementation issuesHi Junhong,
Sorry for the late reply.
I have seen this issue and worked on this. For reproducing the issue, following steps are performed
1. created a 3gp content with bandwidth as Video 60kbps (56322) and Audio 20Kbps (20176)
2. Edited the preferences in Registry to set the TransportByteLimit to 300K (300000)
3. Looked and verified at the size in the setup message. It is 307040 and 302522 in this case.
4. Found out the how the size is set to 307040 and 302522 in Setup.
Theory behind finding the size:
For Video :
In the function HXRAIStreamInfo::Init(), we read the preference
...
// Add TransportByteLimit (or default)
ReadPrefUINT32(pPrefs, "TransportByteLimit", m_ulBufferSize);
A value of 0 means no limit. But here we set it to 300000 (in registry).
Then we add buffersize with HXMulDiv(ulMaxBitRate, ulPreroll, BITS_PER_BYTE * 1000);
This means ( 56322 * 1000 ) / 8000 = 7040.25 is added to 300000 so the Buffer size becomes 307040.
m_ulBufferSize += HXMulDiv(ulMaxBitRate, ulPreroll, BITS_PER_BYTE * 1000);
So the value is set to 307040 bytes.
Same goes with audio (Stream Number 1)
Again HXRAIStreamInfo::Init() is called.
The m_ulBufferSize is 302522 as this time the ulMaxBitRate is 20176 (audio)
5. Found how this size is sent to SETUP message.
RTSPClientProtocol::SendSetupRequest() have calls and so finally it calls the function CHXRateAdaptationInfo::Create3gpAdaptHdrs() we call HXRAIStreamInfo::Get3gpBufferSize() . This returns m_ulBufferSize and then this size is used.
res = pValues->SetPropertyULONG32("size",ulBufferSize); --------> This is also in CHXRateAdaptationInfo::Create3gpAdaptHdrs()
So My audio buffer is 305522 and video is 307040. The preroll is 1000 in this case. So as per the mail this is also verified that the max buffer size is around 300K for both audio and video.
Transport Buffer limit for video comes out to be 20876 bytes
For Audio it is 79123 and so verified that these limits are smaller than the max buffer sizes of audio and video.
Now when we stream this file, it starts dropping the packets because of the RTSPTransportBuffer::OverByteLimit() .
I just want to make sure did I missed any step ?
If we see your mail, it is saying
I think we need revisit the fundamental assumption on the current 3GPP Rel6 RA. The main purpose of TS26.234 Rel6 RA is to deal with handover, which could cause packet transmit temporarily discontinue for some period. So first of all, we need configure the client side target_buffer_time to tolerance the handover time. After the targe_buffer_time is set, then we can decide the max_buffer_size for each stream by adding a protect factor, such as 2. So the formula could be max_buffer_size = 2 * target_buffer_time * clip_bit_rate. Since the audio and video are pacing based on time, the balance between audio and video stream should be in seconds too. The current implementation is setting the max_buffer_size for audio and video stream to the almost same, that is not proper. The third thing is to make sure the transportbuffer byte limite is bigger than the max_buffer_size, or just don't set this limit by using the max_buffer_size to guarding the whole clinet's memory allocation. Any advices to solve this problem is welcome.
What exactly you want to suggest that now needs to be done ?
Thanks & Regards,
Lovish
----- Original Message -----
From: Junhong.Liu@nokia.com
To: client-dev@helixcommunity.org ; protocol-dev@helixcommunity.org
Sent: Thursday, March 08, 2007 4:09 AM
Subject: [Client-dev] 3GPP Rate Adaptation implementation issues
Hi,
We are experiencing streaming problems with helix 11 server when 3GPP rata adaptation feature is turned on.
Here is the situation.
There is a clip on helix 11 server, the video bit rate is 60 kpbs, and the audio bit rate is 20 kpb. The clip duration is 90 seconds and preroll is 1 second.
The data flow in helix client for streaming case is: server ->TransportBuffer.m_pPacketDeque ->HXPlayer.m_EventList -> renderer
The steps of 3GPP Rel6 RA are:
1. Read "TransportByteLimit" from the .cfg file and set audio and video's TransportBuffer byte limit, proportional to their bit rates. For example, audio's TransportBuffer byte is 100k, and video is 200k in this case.
2. Calculate the 3GPP RA's max_buffer_size (used by SETUP message) as TransportByteLimit (300k) + proroll * bit rate / 8. The results are around 300k for both video and audio streams since the preroll is very small.
3. Send RTCP APP (PSS0) feedback including the free buffer size (FBS) periodically.
The calculation of FBS is
FBS = max_buffer_size - sizeof ( TransportBuffer.m_pPacketDeque + HXPlayer.m_EventList + renderer ).
However, when the TransportBuffer reaches its byte limit, it starts to drop the packet before moving to HXPlayer.m_EventList.
For audio stream, the result of FBS is :
FBS = 300k - ( 100k + HXPlayer.m_EventList + renderer ) = 200k - (HXPlayer.m_EventList + renderer)
If the data in ( HXPlayer.m_EventList + renderer ) is smaller than 200k, the client will keep notifying the server that it has available buffer. So the server will not slowdown it's sending, resulting in more packets dropped in TransportBuffer. We have seen after playing for a while, the video/audio quality was downgraded significantly.
The root cause of this problem is the byte limit of TransportBuffer is smaller than the max_buffer_size. In fact, the problem also happens on Helix adaptation which also uses the free buffer size as it's RDT feedback.
To solve this problem, I think we need revisit the fundamental assumption on the current 3GPP Rel6 RA.
The main purpose of TS26.234 Rel6 RA is to deal with handover, which could cause packet transmit temporarily discontinue for some period. So first of all, we need configure the client side target_buffer_time to tolerance the handover time. After the targe_buffer_time is set, then we can decide the max_buffer_size for each stream by adding a protect factor, such as 2. So the formula could be max_buffer_size = 2 * target_buffer_time * clip_bit_rate. Since the audio and video are pacing based on time, the balance between audio and video stream should be in seconds too. The current implementation is setting the max_buffer_size for audio and video stream to the almost same, that is not proper. The third thing is to make sure the transportbuffer byte limite is bigger than the max_buffer_size, or just don't set this limit by using the max_buffer_size to guarding the whole clinet's memory allocation.
Any advices to solve this problem is welcome.
Thanks
Junhong
------------------------------------------------------------------------------
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070403/264ee14f/attachment-0001.html
From E7978C at motorola.com Wed Apr 4 20:16:40 2007
From: E7978C at motorola.com (Lu Mingjun-E7978C)
Date: Wed Apr 4 20:46:36 2007
Subject: [Protocol-dev] CR-Client: protocol project
In-Reply-To: <1FF774FA67C1EA44A3244E735C9F90AE01C378FC@ZMY16EXM65.ds.mot.com>
Message-ID:
Modified by: e12714@motorola.com
Date: 04:04:2007
Project: mediaplayer on motorola phone
Bug Number:
Bug URL:
Synopsis: live streaming pause/replay will lead to coredump issue
Overview:
Description:
1. Connect to live streaming RTSP server (Huawei's server).
CMCC live streaming
1.Go to CMCC streaming video test server:
211.136.165.53:8001/test.jsp password:54shlmt.
2.Select live streaming test site
2. Click live streaming case.
3. press pause, after success, then press play!
4. helix will segfault at protocol/transport/common/system/transbuf.cpp!
Analysis:
1. For Huawei's server, after pasue command, the seq number of RTP
packet will reset to start from 1, but fro real's server, seq number
will increase forever!
Such case will lead to the buffer disorder!
2. Pause/replay will not flush pervious buffer immediately, in currect
code, we need to wait for a long time to get old buffer be flushed! That
means the replay delay is very very long!
Temp fix solution is:
When work in live streaming mode, just flush all remain data in to
buffer if pause occurred!
Files Added:
[File 1] -
[File 2] -
Files Modified:
[File 1] - protocol/transport/common/system/transbuf.cpp
Image Size and Heap Use impact (Client -Only):
Platforms and Profiles Affected:
Distribution Libraries Affected:
Distribution library impact and planned action:
Platforms and Profiles Build Verified:
build for arm11 version
Platforms and Profiles Functionality verified:
Branch:
Copyright assignment: <3. >
1. 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.
2. I have signed and delivered a Joint Copyright Assignment
to RealNetworks, and received acknowledgment that the
agreement was received.
3. My company (Motorola) submits this code under the terms
of a commercial contribution agreement with RealNetworks,
and I am authorized to contribute this code under said
agreement.
4. I am a RealNetworks employee or contractor
QA Instructions:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070405/af0ea71e/attachment.html
From E7978C at motorola.com Wed Apr 4 20:19:49 2007
From: E7978C at motorola.com (Lu Mingjun-E7978C)
Date: Wed Apr 4 20:49:39 2007
Subject: [Protocol-dev] RE: CR-Client: protocol project
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: protocol.diff
Type: application/octet-stream
Size: 7753 bytes
Desc: protocol.diff
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070405/ed8acd50/protocol-0001.obj
From ehyche at real.com Mon Apr 9 05:48:38 2007
From: ehyche at real.com (Eric Hyche)
Date: Mon Apr 9 06:27:17 2007
Subject: [Protocol-dev] RE: CR-Client: protocol project
In-Reply-To:
References:
Message-ID: <002e01c77aa5$665f42a0$db68a8c0@EHYCHED620>
For future reference, a lot of my questions may be able to
be answered if you could add more description in the CR
email itself.
- if (IsQueueEmpty())
+ if (m_bQueueIsEmpty)
Why are all the calls to IsQueueEmpty() being replaced
by m_bQueueIsEmpty?
@@ -1103,19 +1111,10 @@
{
if (!m_bFirstPacketGet)
{
- if(!pPacket->IsLostPacket()) {
m_bFirstPacketGet = TRUE;
HXLOGL1(HXLOG_TRAN,
"RTSPTransportBuffer[%p]: First Packet Retrieved %i",
this, m_uStreamNumber);
- } else {
- //Return HXR_NO_DATA, if the first packet is a lost
packet.
- //This is to avoid the situation of the base time being
set to 0,
- //which could be far from real time-range of the packets
and cause the player
- //to "freeze"
- HX_RELEASE(pPacket);
- rc = HXR_NO_DATA;
- }
}
}
Why is the first-packet-lost code being removed here?
-RTSPTransportBuffer::GetCurrentBuffering(UINT32& ulLowestTimestamp,
- UINT32& ulHighestTimestamp,
+RTSPTransportBuffer::GetCurrentBuffering(INT64& llLowestTimestamp,
+ INT64& llHighestTimestamp,
Why are these being changed to 64-bit?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
> Lu Mingjun-E7978C
> Sent: Wednesday, April 04, 2007 11:20 PM
> To: protocol-dev@helixcommunity.org
> Cc: Wang JinJian-E12714; Qu Yongzhi-W20664; Zhao Liang-E3423C
> Subject: [Protocol-dev] RE: CR-Client: protocol project
>
> Sorry for missing diff file.
>
> ________________________________
>
> From: Lu Mingjun-E7978C
> Sent: Thursday, April 05, 2007 11:17 AM
> To: 'protocol-dev@helixcommunity.org'
> Cc: Wang JinJian-E12714; Zhao Liang-E3423C; Rishi Mathew; Qu
> Yongzhi-W20664
> Subject: CR-Client: protocol project
>
>
> Modified by: e12714@motorola.com
>
> Date: 04:04:2007
>
> Project: mediaplayer on motorola phone
> Bug Number:
> Bug URL:
>
> Synopsis: live streaming pause/replay will lead to coredump issue
> Overview:
> Description:
> 1. Connect to live streaming RTSP server (Huawei's server).
>
> CMCC live streaming
> 1.Go to CMCC streaming video test server:
> 211.136.165.53:8001/test.jsp password:54shlmt.
> 2.Select live streaming test site
>
> 2. Click live streaming case.
>
> 3. press pause, after success, then press play!
>
> 4. helix will segfault at
> protocol/transport/common/system/transbuf.cpp!
>
> Analysis:
>
> 1. For Huawei's server, after pasue command, the seq number
> of RTP packet will reset to start from 1, but fro real's
> server, seq number will increase forever!
> Such case will lead to the buffer disorder!
>
> 2. Pause/replay will not flush pervious buffer immediately,
> in currect code, we need to wait for a long time to get old
> buffer be flushed! That means the replay delay is very very long!
>
> Temp fix solution is:
> When work in live streaming mode, just flush all remain data
> in to buffer if pause occurred!
>
>
> Files Added:
> [File 1] -
> [File 2] -
>
>
> Files Modified:
> [File 1] - protocol/transport/common/system/transbuf.cpp
> Image Size and Heap Use impact (Client -Only):
>
>
> Platforms and Profiles Affected:
> affected if they are different>
>
> Distribution Libraries Affected:
>
> Distribution library impact and planned action:
>
>
> Platforms and Profiles Build Verified:
> build for arm11 version
>
> Platforms and Profiles Functionality verified:
> verified>
>
> Branch:
>
> Copyright assignment: <3. >
>
> 1. 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.
>
> 2. I have signed and delivered a Joint Copyright Assignment
> to RealNetworks, and received acknowledgment that the
> agreement was received.
>
> 3. My company (Motorola) submits this code under the terms
> of a commercial contribution agreement with RealNetworks,
> and I am authorized to contribute this code under
> said agreement.
>
> 4. I am a RealNetworks employee or contractor
>
> QA Instructions:
> areas>
>
>
>
>
>
>
>
>
From Junhong.Liu at nokia.com Mon Apr 9 20:49:41 2007
From: Junhong.Liu at nokia.com (Junhong.Liu@nokia.com)
Date: Mon Apr 9 21:18:27 2007
Subject: [Protocol-dev] Re : [Client-dev] 3GPP Rate Adaptation
implementation issues
Message-ID:
Hi, Lovish:
Sorry for my late reply too.
What you did is correct. Just as you found, the problem is that the
packets were dropped by transport buffer because of overlimit even if
the whole client side buffer is not full.
Back to the current implementation of 3GPP RA in helix. I was involved
in the 3GPP Rate adaptation implementation for micro-core. Here, I would
like to share its design.
Since the 3GPP RA is mainly to deal with the discontinuous data
transmission during the handover, micro-core first retrieves the
handover time configured by the operator. Then according to this
handover time, the preroll time, which is also used as the target_time
inside 3GPP RA SETUP message, is deduced as:
preroll = handover_time * clip_bit_rate / network_bandwidth.
The reasoning here is when clip_bit rate equals to network_bandwidth,
preroll will be the handover time, which can tolerance the data
interrupt during the handover. And when the clip_bit_rate is smaller
than network_bandwidth, preroll will be smaller than the handover time
since the network can fill in the client side buffer in a shorter time.
Based on preroll, the max_buffer_size will be 2 * preroll *
clip_bit_rate, in which 2 is the safe protection factor. Please note
that the max_buffer_size is for each stream.
There are a couple of problems for the current helix 3GPP RA
implementation. I list the helix steps on 3GPP RA and problems I think
as below
1. Read "TransportByteLimit" from the .cfg file and set audio and
video's TransportBuffer byte limit, proportional to their bit rates. For
example, audio's TransportBuffer byte is 100k, and video is 200k in
this case.
[problem] We should use preroll to calculate the max_buffer_size, then
take TransportByteLimit into account.
2. Calculate the 3GPP RA's max_buffer_size (used by SETUP message) as
TransportByteLimit (300k) + preroll * bit rate / 8. The results are
around 300k for both video and audio streams since the preroll is very
small.
[problem] The max_buffer_size calculation doesn't make sense to me.
First, the result of max_buffer_size is almost same for audio and video
stream since the preroll is very small, which is not proper in this
case. Second, TransportByteLimit is still using 300k, however, the
actual limit should be 100k for audio and 200k for video as the result
of step 1.
3. Send RTCP APP (PSS0) feedback including the free buffer size (FBS)
periodically.
4 The calculation of FBS is
FBS = max_buffer_size - sizeof ( TransportBuffer.m_pPacketDeque +
HXPlayer.m_EventList + renderer ).
However, when the TransportBuffer reaches its byte limit, it
starts to drop the packet before moving to HXPlayer.m_EventList.
For audio stream, the result of FBS is :
FBS = 300k - ( 100k + HXPlayer.m_EventList + renderer ) = 200k -
(HXPlayer.m_EventList + renderer)
If the data in ( HXPlayer.m_EventList + renderer ) is smaller than
200k, the client will keep notifying the server that it has available
buffer. So the server will not slowdown it's sending, resulting in more
packets dropped in TransportBuffer. We have seen after playing for a
while, the video/audio quality was downgraded significantly.
The root cause of this problem is the byte limit of TransportBuffer
is smaller than the max_buffer_size. In fact, the problem also happens
on Helix adaptation which also uses the free buffer size as it's RDT
feedback.
[problem] This is the reason of overflow. The TransportBuffer is
overflow before the whole buffer has reached its limit.
So I think the helix 3GPP RA needs to overhaul to solve the current
problems.
Thanks,
Junhong
________________________________
From: ext Lovish Dhawan [mailto:ldhawan@real.com]
Sent: Tuesday, April 03, 2007 12:12 AM
To: Liu Junhong (Nokia-TP-MSW/Dallas);
client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
Subject: Re: [Client-dev] 3GPP Rate Adaptation
implementation issues
Hi Junhong,
Sorry for the late reply.
I have seen this issue and worked on
this. For reproducing the issue, following steps are performed
1. created a 3gp content with bandwidth as Video 60kbps
(56322) and Audio 20Kbps (20176)
2. Edited the preferences in Registry to set the
TransportByteLimit to 300K (300000)
3. Looked and verified at the size in the setup message.
It is 307040 and 302522 in this case.
4. Found out the how the size is set to 307040 and
302522 in Setup.
Theory behind finding the size:
For Video :
In the function HXRAIStreamInfo::Init(), we read the
preference
...
// Add TransportByteLimit (or default)
ReadPrefUINT32(pPrefs, "TransportByteLimit",
m_ulBufferSize);
A value of 0 means no limit. But here we set it to
300000 (in registry).
Then we add buffersize with HXMulDiv(ulMaxBitRate,
ulPreroll, BITS_PER_BYTE * 1000);
This means ( 56322 * 1000 ) / 8000 = 7040.25 is added to
300000 so the Buffer size becomes 307040.
m_ulBufferSize += HXMulDiv(ulMaxBitRate, ulPreroll,
BITS_PER_BYTE * 1000);
So the value is set to 307040 bytes.
Same goes with audio (Stream Number 1)
Again HXRAIStreamInfo::Init() is called.
The m_ulBufferSize is 302522 as this time the
ulMaxBitRate is 20176 (audio)
5. Found how this size is sent to SETUP
message.
RTSPClientProtocol::SendSetupRequest() have calls and so
finally it calls the function
CHXRateAdaptationInfo::Create3gpAdaptHdrs() we call
HXRAIStreamInfo::Get3gpBufferSize() . This returns m_ulBufferSize and
then this size is used.
res =
pValues->SetPropertyULONG32("size",ulBufferSize); --------> This is also
in CHXRateAdaptationInfo::Create3gpAdaptHdrs()
So My audio buffer is 305522 and video is 307040. The
preroll is 1000 in this case. So as per the mail this is also verified
that the max buffer size is around 300K for both audio and video.
Transport Buffer limit for video comes out to be 20876
bytes
For Audio it is 79123 and so verified that these limits
are smaller than the max buffer sizes of audio and video.
Now when we stream this file, it starts persist
I just want to make sure did I missed any step ?
If we see your mail, it is saying
I think we need revisit the fundamental assumption on
the current 3GPP Rel6 RA. The main purpose of TS26.234 Rel6 RA is to
deal with handover, which could cause packet transmit temporarily
discontinue for some period. So first of all, we need configure the
client side target_buffer_time to tolerance the handover time. After the
targe_buffer_time is set, then we can decide the max_buffer_size for
each stream by adding a protect factor, such as 2. So the formula could
be max_buffer_size = 2 * target_buffer_time * clip_bit_rate. Since the
audio and video are pacing based on time, the balance between audio and
video stream should be in seconds too. The current implementation is
setting the max_buffer_size for audio and video stream to the almost
same, that is not proper. The third thing is to make sure the
transportbuffer byte limite is bigger than the max_buffer_size, or just
don't set this limit by using the max_buffer_size to guarding the whole
clinet's memory allocation. Any advices to solve this problem is
welcome.
What exactly you want to suggest that now needs to be
done ?
Thanks & Regards,
Lovish
----- Original Message -----
From: Junhong.Liu@nokia.com
To: client-dev@helixcommunity.org ;
protocol-dev@helixcommunity.org
Sent: Thursday, March 08, 2007 4:09 AM
Subject: [Client-dev] 3GPP Rate Adaptation
implementation issues
Hi,
We are experiencing streaming problems
with helix 11 server when 3GPP rata adaptation feature is turned on.
Here is the situation.
There is a clip on helix 11 server, the
video bit rate is 60 kpbs, and the audio bit rate is 20 kpb. The clip
duration is 90 seconds and preroll is 1 second.
The data flow in helix client for
streaming case is: server ->TransportBuffer.m_pPacketDeque
->HXPlayer.m_EventList -> renderer
The steps of 3GPP Rel6 RA are:
1. Read "TransportByteLimit" from the
.cfg file and set audio and video's TransportBuffer byte limit,
proportional to their bit rates. For example, audio's TransportBuffer
byte is 100k, and video is 200k in this case.
2. Calculate the 3GPP RA's
max_buffer_size (used by SETUP message) as TransportByteLimit (300k) +
proroll * bit rate / 8. The results are around 300k for both video and
audio streams since the preroll is very small.
3. Send RTCP APP (PSS0) feedback
including the free buffer size (FBS) periodically.
The calculation of FBS is
FBS = max_buffer_size - sizeof (
TransportBuffer.m_pPacketDeque + HXPlayer.m_EventList + renderer ).
However, when the TransportBuffer
reaches its byte limit, it starts to drop the packet before moving to
HXPlayer.m_EventList.
For audio stream, the result of FBS is
:
FBS = 300k - ( 100k +
HXPlayer.m_EventList + renderer ) = 200k - (HXPlayer.m_EventList +
renderer)
If the data in ( HXPlayer.m_EventList +
renderer ) is smaller than 200k, the client will keep notifying the
server that it has available buffer. So the server will not slowdown
it's sending, resulting in more packets dropped in TransportBuffer. We
have seen after playing for a while, the video/audio quality was
downgraded significantly.
The root cause of this problem is the
byte limit of TransportBuffer is smaller than the max_buffer_size. In
fact, the problem also happens on Helix adaptation which also uses the
free buffer size as it's RDT feedback.
To solve this problem, I think we need
revisit the fundamental assumption on the current 3GPP Rel6 RA.
The main purpose of TS26.234 Rel6 RA is
to deal with handover, which could cause packet transmit temporarily
discontinue for some period. So first of all, we need configure the
client side target_buffer_time to tolerance the handover time. After the
targe_buffer_time is set, then we can decide the max_buffer_size for
each stream by adding a protect factor, such as 2. So the formula could
be max_buffer_size = 2 * target_buffer_time * clip_bit_rate. Since the
audio and video are pacing based on time, the balance between audio and
video stream should be in seconds too. The current implementation is
setting the max_buffer_size for audio and video stream to the almost
same, that is not proper. The third thing is to make sure the
transportbuffer byte limite is bigger than the max_buffer_size, or just
don't set this limit by using the max_buffer_size to guarding the whole
clinet's memory allocation.
Any advices to solve this problem is
welcome.
Thanks
Junhong
________________________________
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070409/41937904/attachment-0001.html
From gbajaj at real.com Tue Apr 10 23:18:39 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Tue Apr 10 23:46:40 2007
Subject: [Protocol-dev] CR:[Bug 187976] BLOCKED: REOPEN: Legacy Embedded
Player: Player reports
a time out while playing realmedia contents on embedded player.
Message-ID: <461C7DBF.2000904@real.com>
Synopsis:
This changes fixes the problem of player timing out not only on embedded
player but also while playing the clip using Cayenne150 splay build
after receiving
"connection re-set" error.
Overview:
This bug was occurring only when player starts streaming from the server
with current transport set to UDPMode.
Earlier player was not handling the "connection reset" error coming from
server over UDPSocket. After this change
player handles this error and attempts to change the transport and then
reconnect to the server.
.
Files Added:
None
Files Modified:
/protocol/rtsp/rtspclnt.cpp,
/client/core/hxntsrc.cpp, /client/core/hxntsrc.h
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
Not a platform specific change
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Platforms and Profiles Build Verified:
BIF branch -> Cayenne1_5_0
Target(s) ->splay
Profile ->helix-client-all-defines
SYSTEM_ID=win32-i386-vc7
Branch:
Cayenne150
Files Attached:
diff.txt
Thanks and Regards
Gaurav Bajaj
-------------- next part --------------
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.148.2.50
diff -u -w -r1.148.2.50 rtspclnt.cpp
--- rtspclnt.cpp 6 Feb 2007 18:28:20 -0000 1.148.2.50
+++ rtspclnt.cpp 6 Apr 2007 06:23:36 -0000
@@ -11469,7 +11469,8 @@
case HX_SOCK_EVENT_CLOSE:
// normally only the client initiates close
// Connection errors are handled via the TCP socket.
- if (status == HXR_OUTOFMEMORY)
+ if (status == HXR_OUTOFMEMORY ||
+ status == HXR_SOCK_CONNRESET)
{
m_pOwner->OnProtocolError(status);
}
Index: hxntsrc.cpp
===================================================================
RCS file: /cvsroot/client/core/hxntsrc.cpp,v
retrieving revision 1.118.2.15
diff -u -w -r1.118.2.15 hxntsrc.cpp
--- hxntsrc.cpp 12 Jan 2007 04:27:40 -0000 1.118.2.15
+++ hxntsrc.cpp 6 Apr 2007 06:24:04 -0000
@@ -2715,6 +2715,15 @@
theErr = AttemptReconnect();
mLastError = theErr;
}
+ else if (theErr == HXR_SOCK_CONNRESET)
+ {
+ theErr = switch_to_next_transport(theErr, FALSE);
+ if (SUCCEEDED(theErr))
+ {
+ theErr = AttemptReconnect();
+ mLastError = theErr
+ }
+ }
// handle HXR_REDIRECTION explicitly
if (theErr == HXR_REDIRECTION)
@@ -5185,7 +5194,7 @@
}
HX_RESULT
-HXNetSource::switch_to_next_transport(HX_RESULT incomingError)
+HXNetSource::switch_to_next_transport(HX_RESULT incomingError, BOOL bAttemptReconnect/* TRUE*/)
{
HXLOGL3(HXLOG_NSRC, "HXNetSource::switch_to_next_transport(): error = %08x", incomingError);
HX_RESULT theErr = HXR_OK;
@@ -5219,6 +5228,8 @@
goto exit;
}
+ if (bAttemptReconnect)
+ {
// reset transport state to PTS_CREATE so the PreferredTransport object
// will be notified on the success/failure of this transport switch
m_prefTransportState = PTS_CREATE;
@@ -5234,6 +5245,7 @@
theErr = handleTransportSwitch();
mLastError = theErr;
}
+ }
exit:
Index: hxntsrc.h
===================================================================
RCS file: /cvsroot/client/core/hxntsrc.h,v
retrieving revision 1.38.2.4
diff -u -w -r1.38.2.4 hxntsrc.h
--- hxntsrc.h 14 Jul 2006 18:45:43 -0000 1.38.2.4
+++ hxntsrc.h 6 Apr 2007 06:24:04 -0000
@@ -528,7 +528,7 @@
void ReportError (HX_RESULT theErr);
void ActualReportError(HX_RESULT theErr);
- HX_RESULT switch_to_next_transport(HX_RESULT incomingError);
+ HX_RESULT switch_to_next_transport(HX_RESULT incomingError, BOOL bAttemptReconnect = TRUE);
void set_transport(TransportMode mode);
void WritePerfectPlayToRegistry();
From ehyche at real.com Wed Apr 11 05:30:20 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Apr 11 05:58:27 2007
Subject: [Protocol-dev] CR:[Bug 187976] BLOCKED: REOPEN: Legacy Embedded
Player: Player reports a time out while playing realmedia
contents on embedded player.
In-Reply-To: <461C7DBF.2000904@real.com>
References: <461C7DBF.2000904@real.com>
Message-ID: <000301c77c35$2c8ff010$db68a8c0@EHYCHED620>
Looks good.
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
> Gaurav Bajaj
> Sent: Wednesday, April 11, 2007 2:19 AM
> To: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
> Subject: [Protocol-dev] CR:[Bug 187976] BLOCKED: REOPEN:
> Legacy Embedded Player: Player reports a time out while
> playing realmedia contents on embedded player.
>
>
> Synopsis:
> This changes fixes the problem of player timing out not only
> on embedded
> player but also while playing the clip using Cayenne150 splay build
> after receiving
> "connection re-set" error.
>
> Overview:
> This bug was occurring only when player starts streaming from
> the server
> with current transport set to UDPMode.
> Earlier player was not handling the "connection reset" error
> coming from
> server over UDPSocket. After this change
> player handles this error and attempts to change the
> transport and then
> reconnect to the server.
>
> .
> Files Added:
> None
>
> Files Modified:
> /protocol/rtsp/rtspclnt.cpp,
> /client/core/hxntsrc.cpp, /client/core/hxntsrc.h
>
> Image Size and Heap Use impact (Client -Only):
> None.
>
> Platforms and Profiles Affected:
> Not a platform specific change
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
> Platforms and Profiles Build Verified:
>
> BIF branch -> Cayenne1_5_0
> Target(s) ->splay
> Profile ->helix-client-all-defines
> SYSTEM_ID=win32-i386-vc7
>
>
> Branch:
> Cayenne150
>
> Files Attached:
> diff.txt
>
>
> Thanks and Regards
> Gaurav Bajaj
>
From gbajaj at real.com Wed Apr 11 07:04:04 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Wed Apr 11 07:31:58 2007
Subject: [Protocol-dev] CN:[Bug 187976] BLOCKED: REOPEN: Legacy Embedded
Player: Player reports
a time out while playing realmedia contents on embedded player.
In-Reply-To: <000301c77c35$2c8ff010$db68a8c0@EHYCHED620>
References: <461C7DBF.2000904@real.com>
<000301c77c35$2c8ff010$db68a8c0@EHYCHED620>
Message-ID: <461CEAD4.4020502@real.com>
Thanks Eric
This has been checked into Cayenne150 and HEAD.
Does it need to be checked into any other branch...?
Thanks & regards
Gaurav Bajaj
Eric Hyche wrote:
> Looks good.
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
>
>> -----Original Message-----
>> From: protocol-dev-bounces@helixcommunity.org
>> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
>> Gaurav Bajaj
>> Sent: Wednesday, April 11, 2007 2:19 AM
>> To: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>> Subject: [Protocol-dev] CR:[Bug 187976] BLOCKED: REOPEN:
>> Legacy Embedded Player: Player reports a time out while
>> playing realmedia contents on embedded player.
>>
>>
>> Synopsis:
>> This changes fixes the problem of player timing out not only
>> on embedded
>> player but also while playing the clip using Cayenne150 splay build
>> after receiving
>> "connection re-set" error.
>>
>> Overview:
>> This bug was occurring only when player starts streaming from
>> the server
>> with current transport set to UDPMode.
>> Earlier player was not handling the "connection reset" error
>> coming from
>> server over UDPSocket. After this change
>> player handles this error and attempts to change the
>> transport and then
>> reconnect to the server.
>>
>> .
>> Files Added:
>> None
>>
>> Files Modified:
>> /protocol/rtsp/rtspclnt.cpp,
>> /client/core/hxntsrc.cpp, /client/core/hxntsrc.h
>>
>> Image Size and Heap Use impact (Client -Only):
>> None.
>>
>> Platforms and Profiles Affected:
>> Not a platform specific change
>>
>> Distribution Libraries Affected:
>> None
>>
>> Distribution library impact and planned action:
>> None
>>
>> Platforms and Profiles Build Verified:
>>
>> BIF branch -> Cayenne1_5_0
>> Target(s) ->splay
>> Profile ->helix-client-all-defines
>> SYSTEM_ID=win32-i386-vc7
>>
>>
>> Branch:
>> Cayenne150
>>
>> Files Attached:
>> diff.txt
>>
>>
>> Thanks and Regards
>> Gaurav Bajaj
>>
>>
>
>
>
From rajesh.rathinasamy at nokia.com Mon Apr 16 12:08:16 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Apr 16 12:35:42 2007
Subject: [Protocol-dev] IHXRTPPacket vs IHXPacket usage
Message-ID:
Hello All,
* How is the IHXRTPPacket different from IHXPacket apart from the
RTPTime ?
* What is the advantage of using IHXRTPPacket over IHXPacket ? What if I
create IHXPacket and set the helix time created from rtp time ?
* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first
packet TS offset ? (Meaning should RTP time always start with zero when
IHXRTPPacket is used ?)
In XPS fileformat (which is similar to RTSP file format), when RTP
packets are received, it sets the same RTP time & Helix time (calculated
using TSConverter)in the packet and sends it to depacketizer.
Depacketizer is again calculating the Helix time with its own
TSConverter. And the time calculated from TSConverter seem to start with
some offset instead of zero and audio playback does not happen untill
that time. The playback time keeps moving and audio starts playing after
the time offset. If the RTP packet ts is adjusted (meaning subtracted to
first packet's TS) while setting on IHXRTPPacket, then playout seems to
be ok.
Can someone please clarify the above mentioned questions on
IHXRTPPacket, so that I can change XPS File format appropriately ?
Thanks,
Rajesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070416/2f5865fc/attachment.html
From john.wei at nokia.com Mon Apr 16 12:34:42 2007
From: john.wei at nokia.com (john.wei@nokia.com)
Date: Mon Apr 16 13:02:13 2007
Subject: [Protocol-dev] CR: handle mesg 301 ("Moved Permanently") from
streaming server
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB03BC087D@daebe102.NOE.Nokia.com>
Nokia submits this code under the terms of a commercial contribution
agreement with RealNetworks, and I am authorized to contribute this code
under said agreement."
Modified by: john.wei@nokia.com
Reviewed by:
Date: 04-April-2007
Project: SymbianMmf_Rel
TSW: EHHZ-6ZRFWU
Synopsis: handle mesg 301 ("Moved Permanently") from streaming server
When streaming server replys with mesg 301 ("Moved Permanently"), Helix
does not handle this message resulting "system error". This CR adds
support for mesg 301.
Files Modified:
/cvsroot/protocol/rtsp/rtspclnt.cpp
? rtsp.diff
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.20
diff -u -w -b -r1.182.2.20 rtspclnt.cpp
--- rtspclnt.cpp 9 Feb 2007 19:31:40 -0000 1.182.2.20
+++ rtspclnt.cpp 16 Apr 2007 15:59:16 -0000
@@ -6590,8 +6590,7 @@
}
// check for URL redirect
- /// @todo Shouldn't we check for 301 here too?
- else if (uErrorCode == 302 || uErrorCode == 303)
+ else if (uErrorCode == 301 || uErrorCode == 302 ||
uErrorCode == 303)
{
rc = HandleRedirectResponse((RTSPResponseMessage*)pMsg);
goto exit;
Files Added: None
Image Size and Heap Use impact: minor
Module Release testing (STIF) : MRT test cases run and passed.
Root Cause: Implementation.
Test case(s) Added : No
Memory leak check performed : Yes. No new leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Head & 210CayS
From gwright at real.com Mon Apr 16 18:29:20 2007
From: gwright at real.com (Greg Wright)
Date: Mon Apr 16 18:56:06 2007
Subject: [Protocol-dev] CR: handle mesg 301 ("Moved Permanently") from
streaming server
In-Reply-To: <1F7C330B210B764DBBE8B2D749F9A5DB03BC087D@daebe102.NOE.Nokia.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03BC087D@daebe102.NOE.Nokia.com>
Message-ID: <462422F0.8010802@real.com>
Looks good.
--greg.
john.wei@nokia.com wrote:
> Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement."
>
> Modified by: john.wei@nokia.com
>
> Reviewed by:
>
> Date: 04-April-2007
>
> Project: SymbianMmf_Rel
>
> TSW: EHHZ-6ZRFWU
>
> Synopsis: handle mesg 301 ("Moved Permanently") from streaming server
>
> When streaming server replys with mesg 301 ("Moved Permanently"), Helix
> does not handle this message resulting "system error". This CR adds
> support for mesg 301.
> Files Modified:
>
> /cvsroot/protocol/rtsp/rtspclnt.cpp
>
> ? rtsp.diff
> Index: rtspclnt.cpp
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
> retrieving revision 1.182.2.20
> diff -u -w -b -r1.182.2.20 rtspclnt.cpp
> --- rtspclnt.cpp 9 Feb 2007 19:31:40 -0000 1.182.2.20
> +++ rtspclnt.cpp 16 Apr 2007 15:59:16 -0000
> @@ -6590,8 +6590,7 @@
> }
>
> // check for URL redirect
> - /// @todo Shouldn't we check for 301 here too?
> - else if (uErrorCode == 302 || uErrorCode == 303)
> + else if (uErrorCode == 301 || uErrorCode == 302 ||
> uErrorCode == 303)
> {
> rc = HandleRedirectResponse((RTSPResponseMessage*)pMsg);
> goto exit;
> Files Added: None
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : MRT test cases run and passed.
>
> Root Cause: Implementation.
>
> Test case(s) Added : No
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Head & 210CayS
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
From john.wei at nokia.com Tue Apr 17 08:12:00 2007
From: john.wei at nokia.com (john.wei@nokia.com)
Date: Tue Apr 17 08:39:21 2007
Subject: [Protocol-dev] CR: handle mesg 301 ("Moved Permanently") from
streaming server
In-Reply-To: <462422F0.8010802@real.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03BC087D@daebe102.NOE.Nokia.com>
<462422F0.8010802@real.com>
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB03BC0DC2@daebe102.NOE.Nokia.com>
Thanks. Changes have been checked into both head and cayes210.
-----Original Message-----
From: ext Greg Wright [mailto:gwright@real.com]
Sent: Monday, April 16, 2007 8:29 PM
To: Wei John (Nokia-TP-MSW/Dallas)
Cc: protocol-dev@helixcommunity.org
Subject: Re: [Protocol-dev] CR: handle mesg 301 ("Moved Permanently")
from streaming server
Looks good.
--greg.
john.wei@nokia.com wrote:
> Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: john.wei@nokia.com
>
> Reviewed by:
>
> Date: 04-April-2007
>
> Project: SymbianMmf_Rel
>
> TSW: EHHZ-6ZRFWU
>
> Synopsis: handle mesg 301 ("Moved Permanently") from streaming server
>
> When streaming server replys with mesg 301 ("Moved Permanently"),
> Helix does not handle this message resulting "system error". This CR
> adds support for mesg 301.
> Files Modified:
>
> /cvsroot/protocol/rtsp/rtspclnt.cpp
>
> ? rtsp.diff
> Index: rtspclnt.cpp
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
> retrieving revision 1.182.2.20
> diff -u -w -b -r1.182.2.20 rtspclnt.cpp
> --- rtspclnt.cpp 9 Feb 2007 19:31:40 -0000 1.182.2.20
> +++ rtspclnt.cpp 16 Apr 2007 15:59:16 -0000
> @@ -6590,8 +6590,7 @@
> }
>
> // check for URL redirect
> - /// @todo Shouldn't we check for 301 here too?
> - else if (uErrorCode == 302 || uErrorCode == 303)
> + else if (uErrorCode == 301 || uErrorCode == 302 ||
> uErrorCode == 303)
> {
> rc =
HandleRedirectResponse((RTSPResponseMessage*)pMsg);
> goto exit;
> Files Added: None
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : MRT test cases run and passed.
>
> Root Cause: Implementation.
>
> Test case(s) Added : No
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Head & 210CayS
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
From rajesh.rathinasamy at nokia.com Wed Apr 18 14:16:47 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Apr 18 14:43:35 2007
Subject: [Protocol-dev] RE: [Client-dev] IHXRTPPacket vs IHXPacket usage
In-Reply-To:
References:
Message-ID:
________________________________
From: client-dev-bounces@helixcommunity.org
[mailto:client-dev-bounces@helixcommunity.org]
Sent: Monday, April 16, 2007 2:08 PM
To: client-dev@helixcommunity.org;
protocol-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Client-dev] IHXRTPPacket vs IHXPacket usage
Hello All,
* How is the IHXRTPPacket different from IHXPacket apart from
the RTPTime ?
* What is the advantage of using IHXRTPPacket over IHXPacket ?
What if I create IHXPacket and set the helix time created from rtp time
?
* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the
first packet TS offset ? (Meaning should RTP time always start with zero
when IHXRTPPacket is used ?)
In XPS fileformat (which is similar to RTSP file format), when
RTP packets are received, it sets the same RTP time & Helix time
(calculated using TSConverter)in the packet and sends it to
depacketizer. Depacketizer is again calculating the Helix time with its
own TSConverter. And the time calculated from TSConverter seem to start
with some offset instead of zero and audio playback does not happen
untill that time. The playback time keeps moving and audio starts
playing after the time offset. If the RTP packet ts is adjusted (meaning
subtracted to first packet's TS) while setting on IHXRTPPacket, then
playout seems to be ok.
Can someone please clarify the above mentioned questions on
IHXRTPPacket, so that I can change XPS File format appropriately ?
Thanks,
Rajesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070418/f3c57712/attachment.html
From milko at real.com Wed Apr 18 15:12:39 2007
From: milko at real.com (Milko Boic)
Date: Wed Apr 18 15:39:05 2007
Subject: [Protocol-dev] IHXRTPPacket vs IHXPacket usage
In-Reply-To:
References:
Message-ID: <6.2.1.2.2.20070418145549.04236630@mailone.real.com>
At 12:08 PM 4/16/2007, rajesh.rathinasamy@nokia.com wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01C7805A.96BBEF09"
>
>
>Hello All,
>
>* How is the IHXRTPPacket different from IHXPacket apart from the RTPTime ?
It is not different beyond that.
>* What is the advantage of using IHXRTPPacket over IHXPacket ?
It can differentiate presentation and dispatch time of a packet and retain
packet presentation time in sample time base which provides for more accuracy.
Presentation time is given by RTPTime, which is packet's presentation time
in units of samples. Samples relation to seconds is expressed in
"SamplesPerSecond" property in the associated stream header. If the header
is absent, the units of RTPTime are to be assumed in milliseconds.
When IHXPacket is used, presentation and dispatch time are assumed to be
the same and always expressed in milliseconds.
>What if I create IHXPacket and set the helix time created from rtp time ?
No problem as long as helix time is in milliseconds.
>* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first
>packet TS offset ? (Meaning should RTP time always start with zero when
>IHXRTPPacket is used ?)
No. However, the following should always be true: 0 in RTP time == 0 in
helix time.
Given the RTPTime is presentation time, it is directly related to playback
time.
Note that in the network RTP stream this is not so. Network RTP time needs
to be normalized to presentation time using NPT, NTP and RTP time-stamps.
>In XPS fileformat (which is similar to RTSP file format), when RTP packets
>are received, it sets the same RTP time & Helix time (calculated using
>TSConverter)in the packet and sends it to depacketizer. Depacketizer is
>again calculating the Helix time with its own TSConverter. And the time
>calculated from TSConverter seem to start with some offset instead of zero
>and audio playback does not happen untill that time. The playback time
>keeps moving and audio starts playing after the time offset. If the RTP
>packet ts is adjusted (meaning subtracted to first packet's TS) while
>setting on IHXRTPPacket, then playout seems to be ok.
Sound like you have not normalized the RTP time-stamp (converted it to
presentation time in NPT coordinate system).
Milko
>Can someone please clarify the above mentioned questions on IHXRTPPacket,
>so that I can change XPS File format appropriately ?
>
>Thanks,
>Rajesh.
>_______________________________________________
>Protocol-dev mailing list
>Protocol-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070418/a138dbda/attachment.html
From E3423C at motorola.com Thu Apr 19 02:18:29 2007
From: E3423C at motorola.com (Zhao Liang-E3423C)
Date: Thu Apr 19 02:44:54 2007
Subject: [Protocol-dev] CR-Client: live streaming pause/replay will lead to
coredump issue (ezx)
Message-ID:
Best Regards
Zhao Liang
Tel:86-10-65646158
-----Original Message-----
From: Lu Mingjun-E7978C
Sent: Thursday, April 19, 2007 4:59 PM
To: ehyche@real.com
Cc: Qu Yongzhi-W20664; Zhao Liang-E3423C; Wang JinJian-E12714
Subject: RE: [Protocol-dev] CR-Client: live streaming pause/replay will
lead to coredump issue (ezx)
Hi Eric
How about this issue? We need your further information about this issue
before checking related code in.
Thanks
Lu Mingjun
-----Original Message-----
From: Lu Mingjun-E7978C
Sent: Tuesday, April 10, 2007 11:44 AM
To: Wang JinJian-E12714
Cc: Qu Yongzhi-W20664; Zhao Liang-E3423C
Subject: [Protocol-dev] CR-Client: live streaming pause/replay will lead
to coredump issue (ezx)
Hi Eric
I think the description about the CR is enough. What actually made you
puzzled is that this diff result is not based on the latest code. I
regenerate the result as in the attached file.
Best regards
Lu Mingjun
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Monday, April 09, 2007 8:49 PM
To: Lu Mingjun-E7978C; protocol-dev@helixcommunity.org
Cc: Wang JinJian-E12714; Qu Yongzhi-W20664; Zhao Liang-E3423C
Subject: RE: [Protocol-dev] RE: CR-Client: protocol project
For future reference, a lot of my questions may be able to be answered
if you could add more description in the CR email itself.
- if (IsQueueEmpty())
+ if (m_bQueueIsEmpty)
Why are all the calls to IsQueueEmpty() being replaced by
m_bQueueIsEmpty?
@@ -1103,19 +1111,10 @@
{
if (!m_bFirstPacketGet)
{
- if(!pPacket->IsLostPacket()) {
m_bFirstPacketGet = TRUE;
HXLOGL1(HXLOG_TRAN,
"RTSPTransportBuffer[%p]: First Packet Retrieved
%i",
this, m_uStreamNumber);
- } else {
- //Return HXR_NO_DATA, if the first packet is a lost
packet.
- //This is to avoid the situation of the base time
being
set to 0,
- //which could be far from real time-range of the
packets
and cause the player
- //to "freeze"
- HX_RELEASE(pPacket);
- rc = HXR_NO_DATA;
- }
}
}
Why is the first-packet-lost code being removed here?
-RTSPTransportBuffer::GetCurrentBuffering(UINT32& ulLowestTimestamp,
- UINT32& ulHighestTimestamp,
+RTSPTransportBuffer::GetCurrentBuffering(INT64& llLowestTimestamp,
+ INT64& llHighestTimestamp,
Why are these being changed to 64-bit?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of Lu
> Mingjun-E7978C
> Sent: Wednesday, April 04, 2007 11:20 PM
> To: protocol-dev@helixcommunity.org
> Cc: Wang JinJian-E12714; Qu Yongzhi-W20664; Zhao Liang-E3423C
> Subject: [Protocol-dev] RE: CR-Client: protocol project
>
> Sorry for missing diff file.
>
> ________________________________
>
> From: Lu Mingjun-E7978C
> Sent: Thursday, April 05, 2007 11:17 AM
> To: 'protocol-dev@helixcommunity.org'
> Cc: Wang JinJian-E12714; Zhao Liang-E3423C; Rishi Mathew; Qu
> Yongzhi-W20664
> Subject: CR-Client: protocol project
>
>
> Modified by: e12714@motorola.com
>
> Date: 04:04:2007
>
> Project: mediaplayer on motorola phone Bug Number:
> Bug URL:
>
> Synopsis: live streaming pause/replay will lead to coredump issue
> Overview:
> Description:
> 1. Connect to live streaming RTSP server (Huawei's server).
>
> CMCC live streaming
> 1.Go to CMCC streaming video test server:
> 211.136.165.53:8001/test.jsp password:54shlmt.
> 2.Select live streaming test site
>
> 2. Click live streaming case.
>
> 3. press pause, after success, then press play!
>
> 4. helix will segfault at
> protocol/transport/common/system/transbuf.cpp!
>
> Analysis:
>
> 1. For Huawei's server, after pasue command, the seq number of RTP
> packet will reset to start from 1, but fro real's server, seq number
> will increase forever!
> Such case will lead to the buffer disorder!
>
> 2. Pause/replay will not flush pervious buffer immediately, in currect
> code, we need to wait for a long time to get old buffer be flushed!
> That means the replay delay is very very long!
>
> Temp fix solution is:
> When work in live streaming mode, just flush all remain data in to
> buffer if pause occurred!
>
>
> Files Added:
> [File 1] -
> [File 2] -
>
>
> Files Modified:
> [File 1] - protocol/transport/common/system/transbuf.cpp
> Image Size and Heap Use impact (Client -Only):
>
>
> Platforms and Profiles Affected:
> affected if they are different>
>
> Distribution Libraries Affected:
>
> Distribution library impact and planned action:
>
>
> Platforms and Profiles Build Verified:
> build for arm11 version
>
> Platforms and Profiles Functionality verified:
> verified>
>
> Branch:
>
> Copyright assignment: <3. >
>
> 1. 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.
>
> 2. I have signed and delivered a Joint Copyright Assignment
> to RealNetworks, and received acknowledgment that the
> agreement was received.
>
> 3. My company (Motorola) submits this code under the terms
> of a commercial contribution agreement with RealNetworks,
> and I am authorized to contribute this code under said
> agreement.
>
> 4. I am a RealNetworks employee or contractor
>
> QA Instructions:
> areas>
>
>
>
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtsp.diff
Type: application/octet-stream
Size: 627 bytes
Desc: rtsp.diff
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070419/d64e7a54/rtsp.obj
From rajesh.rathinasamy at nokia.com Thu Apr 19 08:34:38 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Thu Apr 19 09:01:30 2007
Subject: [Protocol-dev] IHXRTPPacket vs IHXPacket usage
In-Reply-To: <6.2.1.2.2.20070418145549.04236630@mailone.real.com>
References:
<6.2.1.2.2.20070418145549.04236630@mailone.real.com>
Message-ID:
Milko,
Thank you very much for the information.
Thanks,
Rajesh.
________________________________
From: ext Milko Boic [mailto:milko@real.com]
Sent: Wednesday, April 18, 2007 5:13 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
client-dev@helixcommunity.org; protocol-dev@helixcommunity.org;
datatype-dev@helixcommunity.org
Subject: Re: [Protocol-dev] IHXRTPPacket vs IHXPacket usage
At 12:08 PM 4/16/2007, rajesh.rathinasamy@nokia.com wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C7805A.96BBEF09"
Hello All,
* How is the IHXRTPPacket different from IHXPacket apart
from the RTPTime ?
It is not different beyond that.
* What is the advantage of using IHXRTPPacket over
IHXPacket ?
It can differentiate presentation and dispatch time of a packet
and retain packet presentation time in sample time base which provides
for more accuracy.
Presentation time is given by RTPTime, which is packet's
presentation time in units of samples. Samples relation to seconds is
expressed in "SamplesPerSecond" property in the associated stream
header. If the header is absent, the units of RTPTime are to be assumed
in milliseconds.
When IHXPacket is used, presentation and dispatch time are
assumed to be the same and always expressed in milliseconds.
What if I create IHXPacket and set the helix time
created from rtp time ?
No problem as long as helix time is in milliseconds.
* In IHXRTPPacket::SetRTP, should the RTPTime be
adjusted to the first packet TS offset ? (Meaning should RTP time always
start with zero when IHXRTPPacket is used ?)
No. However, the following should always be true: 0 in RTP
time == 0 in helix time.
Given the RTPTime is presentation time, it is directly related
to playback time.
Note that in the network RTP stream this is not so. Network RTP
time needs to be normalized to presentation time using NPT, NTP and RTP
time-stamps.
In XPS fileformat (which is similar to RTSP file
format), when RTP packets are received, it sets the same RTP time &
Helix time (calculated using TSConverter)in the packet and sends it to
depacketizer. Depacketizer is again calculating the Helix time with its
own TSConverter. And the time calculated from TSConverter seem to start
with some offset instead of zero and audio playback does not happen
untill that time. The playback time keeps moving and audio starts
playing after the time offset. If the RTP packet ts is adjusted (meaning
subtracted to first packet's TS) while setting on IHXRTPPacket, then
playout seems to be ok.
Sound like you have not normalized the RTP time-stamp (converted
it to presentation time in NPT coordinate system).
Milko
Can someone please clarify the above mentioned questions
on IHXRTPPacket, so that I can change XPS File format appropriately ?
Thanks,
Rajesh.
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070419/4ec77629/attachment-0001.html
From E3423C at motorola.com Mon Apr 23 19:11:19 2007
From: E3423C at motorola.com (Zhao Liang-E3423C)
Date: Mon Apr 23 19:37:01 2007
Subject: [Protocol-dev] CR-Client: live streaming pause/replay will lead
to coredump issue (ezx)
In-Reply-To: <006c01c7827f$c39f6850$db68a8c0@EHYCHED620>
References:
<006c01c7827f$c39f6850$db68a8c0@EHYCHED620>
Message-ID:
Eric,
Yes, only this change!
Best Regards
Zhao Liang
Tel:86-10-65646158
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Thursday, April 19, 2007 8:39 PM
To: Lu Mingjun-E7978C
Cc: Qu Yongzhi-W20664; Zhao Liang-E3423C; Wang JinJian-E12714
Subject: RE: [Protocol-dev] CR-Client: live streaming pause/replay will
lead to coredump issue (ezx)
@@ -535,7 +535,11 @@
{
result = Insert(pPacket);
}
-
+ else
+ {
+ //live streaming seek/pause case, just flush buffer
+ m_bFlushHolding = TRUE; //set this flag to force flush in live
streaming mode
+ }
if (HXR_OK != result)
{
return result;
Is this the only change? If so, then this looks fine.
If not, and the changes below that I asked questions about are still
supposed to be included in this change, then please address my questions
about them.
Thanks,
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: Lu Mingjun-E7978C [mailto:E7978C@motorola.com]
> Sent: Thursday, April 19, 2007 4:59 AM
> To: ehyche@real.com
> Cc: Qu Yongzhi-W20664; Zhao Liang-E3423C; Wang JinJian-E12714
> Subject: RE: [Protocol-dev] CR-Client: live streaming pause/replay
> will lead to coredump issue (ezx)
>
> Hi Eric
>
> How about this issue? We need your further information about this
> issue before checking related code in.
>
> Thanks
> Lu Mingjun
>
> -----Original Message-----
> From: Lu Mingjun-E7978C
> Sent: Tuesday, April 10, 2007 11:44 AM
> To: Wang JinJian-E12714
> Cc: Qu Yongzhi-W20664; Zhao Liang-E3423C
> Subject: [Protocol-dev] CR-Client: live streaming pause/replay will
> lead to coredump issue (ezx)
>
>
> Hi Eric
>
> I think the description about the CR is enough. What actually made you
> puzzled is that this diff result is not based on the latest code. I
> regenerate the result as in the attached file.
>
> Best regards
> Lu Mingjun
>
>
> -----Original Message-----
> From: Eric Hyche [mailto:ehyche@real.com]
> Sent: Monday, April 09, 2007 8:49 PM
> To: Lu Mingjun-E7978C; protocol-dev@helixcommunity.org
> Cc: Wang JinJian-E12714; Qu Yongzhi-W20664; Zhao Liang-E3423C
> Subject: RE: [Protocol-dev] RE: CR-Client: protocol project
>
>
> For future reference, a lot of my questions may be able to be answered
> if you could add more description in the CR email itself.
>
> - if (IsQueueEmpty())
> + if (m_bQueueIsEmpty)
>
> Why are all the calls to IsQueueEmpty() being replaced by
> m_bQueueIsEmpty?
>
> @@ -1103,19 +1111,10 @@
> {
> if (!m_bFirstPacketGet)
> {
> - if(!pPacket->IsLostPacket()) {
> m_bFirstPacketGet = TRUE;
> HXLOGL1(HXLOG_TRAN,
> "RTSPTransportBuffer[%p]: First Packet Retrieved
> %i",
> this, m_uStreamNumber);
> - } else {
> - //Return HXR_NO_DATA, if the first packet is a lost
> packet.
> - //This is to avoid the situation of the base time
> being
> set to 0,
> - //which could be far from real time-range of the
> packets
> and cause the player
> - //to "freeze"
> - HX_RELEASE(pPacket);
> - rc = HXR_NO_DATA;
> - }
> }
> }
>
>
> Why is the first-packet-lost code being removed here?
>
> -RTSPTransportBuffer::GetCurrentBuffering(UINT32& ulLowestTimestamp,
> - UINT32& ulHighestTimestamp,
> +RTSPTransportBuffer::GetCurrentBuffering(INT64& llLowestTimestamp,
> + INT64& llHighestTimestamp,
>
> Why are these being changed to 64-bit?
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: protocol-dev-bounces@helixcommunity.org
> > [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of Lu
> > Mingjun-E7978C
> > Sent: Wednesday, April 04, 2007 11:20 PM
> > To: protocol-dev@helixcommunity.org
> > Cc: Wang JinJian-E12714; Qu Yongzhi-W20664; Zhao Liang-E3423C
> > Subject: [Protocol-dev] RE: CR-Client: protocol project
> >
> > Sorry for missing diff file.
> >
> > ________________________________
> >
> > From: Lu Mingjun-E7978C
> > Sent: Thursday, April 05, 2007 11:17 AM
> > To: 'protocol-dev@helixcommunity.org'
> > Cc: Wang JinJian-E12714; Zhao Liang-E3423C; Rishi Mathew; Qu
> > Yongzhi-W20664
> > Subject: CR-Client: protocol project
> >
> >
> > Modified by: e12714@motorola.com
> >
> > Date: 04:04:2007
> >
> > Project: mediaplayer on motorola phone Bug Number:
> > Bug URL:
> >
> > Synopsis: live streaming pause/replay will lead to coredump issue
> > Overview:
> > Description:
> > 1. Connect to live streaming RTSP server (Huawei's server).
> >
> > CMCC live streaming
> > 1.Go to CMCC streaming video test server:
> > 211.136.165.53:8001/test.jsp password:54shlmt.
> > 2.Select live streaming test site
> >
> > 2. Click live streaming case.
> >
> > 3. press pause, after success, then press play!
> >
> > 4. helix will segfault at
> > protocol/transport/common/system/transbuf.cpp!
> >
> > Analysis:
> >
> > 1. For Huawei's server, after pasue command, the seq number of RTP
> > packet will reset to start from 1, but fro real's server,
> seq number
> > will increase forever!
> > Such case will lead to the buffer disorder!
> >
> > 2. Pause/replay will not flush pervious buffer immediately,
> in currect
>
> > code, we need to wait for a long time to get old buffer be flushed!
> > That means the replay delay is very very long!
> >
> > Temp fix solution is:
> > When work in live streaming mode, just flush all remain data in to
> > buffer if pause occurred!
> >
> >
> > Files Added:
> > [File 1] -
> > [File 2] -
> >
> >
> > Files Modified:
> > [File 1] - protocol/transport/common/system/transbuf.cpp
> > Image Size and Heap Use impact (Client -Only):
> >
> >
> > Platforms and Profiles Affected:
> > they are
> > affected if they are different>
> >
> > Distribution Libraries Affected:
> >
> > Distribution library impact and planned action:
> >
> >
> > Platforms and Profiles Build Verified:
> > build for arm11 version
> >
> > Platforms and Profiles Functionality verified:
> > > verified>
> >
> > Branch:
> >
> > Copyright assignment: <3. >
> >
> > 1. 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.
> >
> > 2. I have signed and delivered a Joint Copyright Assignment
> > to RealNetworks, and received acknowledgment that the
> > agreement was received.
> >
> > 3. My company (Motorola) submits this code under the terms
> > of a commercial contribution agreement with RealNetworks,
> > and I am authorized to contribute this code under said
> > agreement.
> >
> > 4. I am a RealNetworks employee or contractor
> >
> > QA Instructions:
> > verification
> > areas>
> >
> >
> >
> >
> >
> >
> >
> >
>
>
From E3423C at motorola.com Wed Apr 4 20:48:15 2007
From: E3423C at motorola.com (Zhao Liang-E3423C)
Date: Tue Apr 24 16:44:04 2007
Subject: [Protocol-dev] RE: CR-Client: protocol project
In-Reply-To:
References: <1FF774FA67C1EA44A3244E735C9F90AE01C378FC@ZMY16EXM65.ds.mot.com>
Message-ID:
Mingjun,
thanks, but maybe you miss diff file
Best Regards
Zhao Liang
Tel:86-10-65646158
________________________________
From: Lu Mingjun-E7978C
Sent: Thursday, April 05, 2007 11:17 AM
To: protocol-dev@helixcommunity.org
Cc: Wang JinJian-E12714; Zhao Liang-E3423C; Rishi Mathew; Qu
Yongzhi-W20664
Subject: CR-Client: protocol project
Modified by: e12714@motorola.com
Date: 04:04:2007
Project: mediaplayer on motorola phone
Bug Number:
Bug URL:
Synopsis: live streaming pause/replay will lead to coredump issue
Overview:
Description:
1. Connect to live streaming RTSP server (Huawei's server).
CMCC live streaming
1.Go to CMCC streaming video test server:
211.136.165.53:8001/test.jsp password:54shlmt.
2.Select live streaming test site
2. Click live streaming case.
3. press pause, after success, then press play!
4. helix will segfault at protocol/transport/common/system/transbuf.cpp!
Analysis:
1. For Huawei's server, after pasue command, the seq number of RTP
packet will reset to start from 1, but fro real's server, seq number
will increase forever!
Such case will lead to the buffer disorder!
2. Pause/replay will not flush pervious buffer immediately, in currect
code, we need to wait for a long time to get old buffer be flushed! That
means the replay delay is very very long!
Temp fix solution is:
When work in live streaming mode, just flush all remain data in to
buffer if pause occurred!
Files Added:
[File 1] -
[File 2] -
Files Modified:
[File 1] - protocol/transport/common/system/transbuf.cpp
Image Size and Heap Use impact (Client -Only):
Platforms and Profiles Affected:
Distribution Libraries Affected:
Distribution library impact and planned action:
Platforms and Profiles Build Verified:
build for arm11 version
Platforms and Profiles Functionality verified:
Branch:
Copyright assignment: <3. >
1. 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.
2. I have signed and delivered a Joint Copyright Assignment
to RealNetworks, and received acknowledgment that the
agreement was received.
3. My company (Motorola) submits this code under the terms
of a commercial contribution agreement with RealNetworks,
and I am authorized to contribute this code under said
agreement.
4. I am a RealNetworks employee or contractor
QA Instructions:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070405/15c7f7e9/attachment.html
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.