Jamie,
You are right, the RTP timestamps in sender reports are
wrong. I
thought client does RTCP time sync only for live streams and
not for
on-demand clips. Let me check that.
I did not get what you are inferring with wrong RTP
timestamps in sender
reports. Is that the cause for current problem or is that an
another
problem with this server ?
Please let me know if you need the complete ipdump.
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Jamie Gordon [mailto:jgordon real.com]
>Sent: Wednesday, March 12, 2008 1:52 PM
>To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas)
>Cc: ehychereal.com; nokia-private-devhelixcommunity.org;
>protocol-devhelixcommunity.org
>Subject: Re: [Protocol-dev] RE: [Nokia-private-dev]
Client
>handling for wrong Range field on Seekresponse
>
>If you look at the RTP/RTCP traffic instead of just the
RTSP,
>that server is severely screwing up the RTP time in the
sender reports.
>
>rajesh.rathinasamynokia.com wrote:
>> Hi Eric,
>> That was my initial guess, but it does not look
like that.
>> Whereever you seek to, server sends data from
previous play position
>> when it was paused.
>>
>> I seeked back to zero while playing 25 sec and the
play response
>> starts from 29. So it is not the key frame issue.
Seems more like
>> server does not respect the play message with a new
range field and
>> uses its time measurement to resume playback.
>>
>> Attaching the ip dump from microcore client.
>>
>> Thanks,
>> Rajesh.
>>
>>
>>> -----Original Message-----
>>> From: ext Eric Hyche [mailto:ehychereal.com]
>>> Sent: Wednesday, March 12, 2008 10:46 AM
>>> To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas);
>>> nokia-private-devhelixcommunity.org;
>protocol-devhelixcommunity.org
>>> Subject: RE: [Nokia-private-dev] Client
handling for wrong Range
>>> field on Seekresponse
>>>
>>>
>>> I believe what is happening is that when you
tell the
>server to seek
>>> to a certain point in the video (say 45
seconds), then the
>fileformat
>>> will look for the first keyframe prior to 45
seconds,
>because it HAS
>>> to start sending packets from there.
>>>
>>> I'm guessing that if you looked at the file,
you'd find that the
>>> first keyframe prior to 45 seconds is at 16
seconds. If that's the
>>> case, then the PLAY response is correct.
>>>
>>> Eric
>>>
>>> =============================================
>>> Eric Hyche (ehychereal.com)
>>> Technical Lead
>>> RealNetworks, Inc.
>>>
>>>> -----Original Message-----
>>>> From: nokia-private-dev-bounceshelixcommunity.org
>>>> [mailto:nokia-private-dev-bounceshelixcommunity.org] On Behalf Of
>>>> rajesh.rathinasamynokia.com
>>>> Sent: Tuesday, March 11, 2008 12:35 PM
>>>> To: nokia-private-devhelixcommunity.org;
>>>> protocol-devhelixcommunity.org
>>>> Subject: [Nokia-private-dev] Client
handling for wrong Range
>>> field on
>>>> Seekresponse
>>>>
>>>> Hi,
>>>> When we try to seek from a particular
server
>>>>
(rtsp://207.154.19.148:554/CL0010508556_6284d5ee0.3gp),
>the servers
>>>> play (Seek) response comes back with a
range field which
>is not the
>>>> one requested for in the play request. The
range field seems to be
>>>> same as where the stream was paused rather
than the seeked
>>> position.
>>>> Currently client stays in reloading until
the data for the
>(client)
>>>> seeked position shows up and plays from
where it was seeked to.
>>>>
>>>> For example,
>>>> * Stream paused at 15 sec
>>>> * Seeked to 45 sec (Sent play)
>>>> * Play response has wrong Range field (
Range: 16-100)
>>>> * Helix client stays in reloading until
data for 45 secs reaches
>>>> client and starts to play from there.
>>>>
>>>> Backward seek results in video being frozen
and no audio
>for a while
>>>> and later plays the received data.
>>>>
>>>> We would like to know what should be the
correct behaviour ?
>>>> Should Helix client/ Player adjust the
start time and play
>>>from where
>>>> server directed it to play ignoring user
command or the current
>>>> behaviour of staying in reloading for a
while is the correct
>>> behaviour
>>>> ?
>>>>
>>>> Branch info: 221CayS & SymbianMMF_rel
>>>>
>>>> Tried Head build splay which also shows the
same behaviour
>>> as 221CayS.
>>>> Thanks,
>>>> Rajesh.
>>>>
>>>>
>>>
>>>
>>>
>--------------------------------------------------------
-------------
>>> ---
>>>
>>>
_______________________________________________
>>> 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
|
