[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-datatype-cvs
Subject:    [Datatype-cvs]
From:       xiaochengli () helixcommunity ! org
Date:       2011-12-23 11:45:22
[Download RAW message or body]

Update of /cvsroot/datatype/mp4/payload/pub
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv16585/pub

Modified Files:
      Tag: SERVER_14_3
	mp4apyld.h mp4gpyld.h 
Log Message:

Synopsis:
=========
This fix is for PR269464: iphone segments stop streaming after 24hrs or more uptime \
on Solaris

Branch: HEAD, SERVER_14_3_RN
Suggested Reviewers: Chytanya, Anyone
Reviewed by: Chytanya

Description:
=========
This description reports that rtp live feed can't work for HLS client after 24hr, \
actually if we add RTP time from RTPBCStreamsObject::PacketReady to make it repro \
easier, on both windows and solaris we can't see correct picture/audio on iPad.  \
There're another PR262104, which has a similar roll-over for h264. The original \
check-in description is: 

" In the h264 depacketizer, we use rtp2hxa to calculate the media time.  This assumes \
that the packets starting from (rtp = 0, media time = 0), and is okay for on-demand \
content.  But for live packets, the rtp time rolls over in a few hours and everything \
falls apart. The bug shows up in the flash live playback where the delta between \
composition(presentation, media, whatever:-) time and decode(delivery) time is huge \
because the incorrect rtp time conversion. Since live packets are only from the \
server, the fix is to query the IHXServerPacketExt and get the media time, instead of \
doing the conversion. "


This fix includes: 
Porting the same code from h264pyld to mp4apyld and mp4gpyld as PR262104, to use \
milliseconds from packet directly if available. 

Files affected:
=========
datatype/mp4/payload/mp4apyld.cpp
datatype/mp4/payload/pub/mp4apyld.h
datatype/mp4/payload/mp4gpyld.cpp
datatype/mp4/payload/pub/mp4gpyld.h
datatype_rn/mpeg2/ts/muxer/tsmux.cpp

Testing Performed:
=========
Unit Tests: N/A
Integration Tests: 
Test on windows/solaris, after changing RTPTime in RTPBCStreamsObject::PacketReady, \
it can work well for packets/feeds with big RTP time.  I'm running a long time \
testing and check if it can insist more than 24 hrs. 

Leak Tests: None
Performance Tests: N/A

Platforms Tested: win-x86_64-vc10, Solaris 64 Builds Verified: win-x86_64-vc10, \
Solaris 64

QA Hints
========
Need to test live feeds from RBS/rtpencoder/rtmp to HLS for a long time(e.p, 13hr, \
24hr, 27hr). 



Index: mp4gpyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4gpyld.h,v
retrieving revision 1.6
retrieving revision 1.6.4.1
diff -u -d -r1.6 -r1.6.4.1
--- mp4gpyld.h	29 Jan 2011 01:30:52 -0000	1.6
+++ mp4gpyld.h	23 Dec 2011 11:45:19 -0000	1.6.4.1
@@ -257,6 +257,7 @@
     HXBOOL			m_bFlushed;
     HXBOOL			m_bUsesRTPPackets;
     HXBOOL			m_bRTPPacketTested;
+    HXBOOL			m_bUsesServerPacketExt;
     HXBOOL			m_bPacketize;
     HXBOOL			m_bPriorLoss;
 

Index: mp4apyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4apyld.h,v
retrieving revision 1.17
retrieving revision 1.17.4.1
diff -u -d -r1.17 -r1.17.4.1
--- mp4apyld.h	29 Sep 2011 01:24:25 -0000	1.17
+++ mp4apyld.h	23 Dec 2011 11:45:19 -0000	1.17.4.1
@@ -165,6 +165,7 @@
     HXBOOL                      m_bFlushed;
     HXBOOL                      m_bUsesRTPPackets;
     HXBOOL                      m_bRTPPacketTested;
+    HXBOOL                      m_bUsesServerPacketExt;
     HXBOOL                      m_bPacketize;
     HXBOOL                      m_bPriorLoss;
 


_______________________________________________
Datatype-cvs mailing list
Datatype-cvs@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-cvs


[prev in list] [next in list] [prev in thread] [next in thread]