List Info

Thread: First seek (backwards) Issue
First seek (backwards) Issue
user name
 2006-12-22 11:18:23 

  


  

    



Hi All,


 


I am working on the bug in which when the 
user seeks for the first time backwards, it results in audio disappears from the 
*seek to* position till *seek from* position.


 


I added logs in the following places:


 


1. Vidrend.cpp


a) CVideoRenderer::OnPreSeek() printing ulOldTime 
and ulNewTime.


b) CVideoRenderer::OnPacket() taking the packet 
time


c) CVideoRenderer::OnPostSeek() printing ulOldTime 
and ulNewTime


 


2. Audrend.cpp


in same functions as in Vidrend.cpp


 


3. transbuf.cpp


a) RTSPTransportBuffer::Add() printing the 
Stream Number, Sequence Number and TimeStamp


b) RTSPTransportBuffer::Insert() printing the 
Stream Number, Sequence Number and TimeStamp


 


4. rtspclnt.cpp


RTSPClientProtocol::handlePlayResponse() printing 
RTPErr, Stream ID, Sequence Number and RTPTime


 


Test Content is 3GP 
streamed over RDT/RTP.


 


After taking these logs and analysing, I found 
2 bugs in this


 


1. For the 1st bug, please refer to the logs 
below: seek to the beginning (timestamp 0) is performed around 20 
seconds into the presentation 


--


Seeking the first player to 0


CVideoRenderer::OnPreSeek ulOldTime[20573],ulNewTime[0] 

CAudioRenderer::OnPreSeek ulOldTime[20573] ulNewTime[0] 

CAudioRenderer::OnPacket Stream Number[1] pts[21717] 

CVideoRenderer::OnPacket() pts=21700 rule=1 
flags=0x01  


RTSPClientProtocol::handlePlayResponse 
RTPErr[3] streamID[65335] seqNum[667] 
ulRTPTime[0]
RTSPClientProtocol::handlePlayResponse RTPErr[3] streamID[65435] 
seqNum[1538] ulRTPTime[0]
RTSPTransportBuffer::Add 
, uStreamNum[0]  uSeqNum[666] ulTime[0] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[0]  uSequenceNumber[666] 
uTimestamp[0] uPacketIndex[441]
RTSPTransportBuffer::Add , 
uStreamNum[1]  uSeqNum[1537] ulTime[0] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[1]  uSequenceNumber[1537] 
uTimestamp[0] uPacketIndex[1027]


RTSPTransportBuffer::Add , uStreamNum[1]  
uSeqNum[1538] ulTime[43] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[1]  uSequenceNumber[1538] 
uTimestamp[43] uPacketIndex[1028]


RTSPTransportBuffer::Add , uStreamNum[0]  
uSeqNum[667] ulTime[100] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[0]  uSequenceNumber[667] uTimestamp[100] uPacketIndex[442]


 


Normally the sequence number we 
get in handlePlayResponse (), (in this example 1538 (audio) and 667 (video)) 
symbolizes that the packets  starting 
this sequence number (1538,667) is of the  new  generation  (post-seek packets) so Transport 
Add() and Insert() should have the timestamp as 0 against these sequence 
numbers mentioned in HandlePlayResponse().  But the 
server seem to send packets with timestamp 0 with sequence number 1 less than 
that sent in 
handlePlayResponse.  ;


 


We should have got logs like 


RTSPTransportBuffer::Add , uStreamNum[0]  
uSeqNum[667] ulTime[0] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[0]  uSequenceNumber[667] 
uTimestamp[0] uPacketIndex[441]


and


RTSPTransportBuffer::Add , uStreamNum[1]  
uSeqNum[1538] ulTime[0] 
m_bWaitingForLiveSeekFlush[0]
RTSPTransportBuffer::Insert , 
uStreamNum[1]  uSequenceNumber[1538] 
uTimestamp[0] uPacketIndex[1027]


 


as we got 667 and 1538 as sequence numbers in the 
RTSPClientProtocol::handlePlayResponse()


 


2. The CAudioRenderer::OnPostSeek() call is getting 
called before all the pre-seek packets 
have ;been delivered to the renderer..


 


CAudioRenderer::OnPostSeek ulOldTime[20573] ulNewTime[0] 

CAudioRenderer::OnPacket Stream Number[1] pts[21760] 

CHXAudioStream::AddData 
pAudioData[0xbfffdb20]
CAudioRenderer::OnPacket Stream Number[1] 
pts[21803]


 


 This results in renderer using the pre-seek 
packets that it should have discarded.


 


Both these bugs  happen only with an older cayenne 
branch (from Feb 2005) ;and cannot be reproed with latest cayenne or 
HEAD.However, #1 seems 
to be a server bug and the behavior of the server *should* be the same 
regardless of the client  version for the seek operation. Is it 
possible I am not logging at the right place? 



 


I have also attached the packet logs I took. 



 


1. audiologs.zip having the logs 
where we can hear the audio ; 


2. noaudiologs.zip having the logs 
where we can hear the audio


 


Please find the zip files attached with the 
mail.


 


Thanks & Regards,


Lovish

  

  
  
   
     
    






 [1]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )