Re: 24/96 playback via http://

John,

I recently looked into the network streaming issues on android 
platform.  Some of the findings might be relevant in your case.

1) MIN_HEAP
The areas affected by HELIX_FEATURE_MIN_HEAP are listed bellow.  The 
value on the first column is for MIN_HEAP and the second column is for 
regular heap.
-----------------------------------------------------------
base audio render:
MAXIMUM_AUDIO_PREROLL
1.5s 7.5s
for MIN_HEAP, the render skips DoAudio() call in 
CAudioRenderer::OnTimeSync()

-----------------------------------------------------------
base video render:
MAX_BUFFERED_DECODED_FRAMES
2 frames 12 frames
FORMAT_DEFAULT_PREROLL
2s 5s
FORMAT_MAXIMUM_PREROLL
3s 15s

-----------------------------------------------------------
m4p fileformat:
ATMZR_PAGING_THRESHOLD
1k 64k
MEMPAGER_DFLT_MIN_PAGE_SIZE
1k 64k

m4p video render:
MAX_BUFFERED_DECODED_MP4_FRAMES
4 frames 14 frames
MP4V_DEFAULT_PREROLL
2s 3.5s

-----------------------------------------------------------
rm video render:
MAX_BUFFERED_DECODED_RV_FRAMES
11 frames 29 frames
MAX_DECODED_RV_FRAMES_IN_STEP
10 frames 15 frames
DECODE_CALLBACK_RNGBUF_SIZE
10 ring buffers 25 ring buffers
RVXV_DEFAULT_PREROLL
2s 3.5s

rm fileformat:
RMFF_INDEX_MIN_ENTRIES
4 32
RMFF_INDEX_MAX_ENTRIES
512 2048
RMFF_INDEX_MIN_TIME_GRANULE
0.5s 0.05s
RMFF_INDEX_MAX_TIME_GRANULE
6s 1.5s

-----------------------------------------------------------
wm video render
HX_WMV_MAX_BUFFERED_DECODED_FRAMES
4 frames 40 frames
HX_WMV_DECODE_CALLBACK_RNGBUF_SIZE
10 ring buffers 30 ring buffers
HX_WMV_DEFAULT_PREROLL
2s 3.5s

-----------------------------------------------------------
netio:
TCP_BUF_SIZE:
2K 32k

-----------------------------------------------------------
http filesystem:
DFLT_MEM_CACHE_SIZE
0.5MB 4MB
MIN_MEM_CACHE_SIZE
64k 256k

fileio chunkres:
DEF_CHUNKYRES_MEM_THRESHOLD
256k 4MB
DEF_CHUNKYRES_CHUNK_SIZE
32k 64k

-----------------------------------------------------------
protocol/rtsp
DEFAULT_TRANSPORT_BYTE_LIMIT
1MB 100MB

datatype/rtsp/fileformat:
RTSPFF_FULL_QUEUE_BYTES_HARDSTOP
1.9MB 38MB
RTSPFF_FULL_QUEUE_BYTES
1.43MB 28.6MB
RTSPFF_FULL_TO_NORMAL_QUEUE_BYTES
0.95MB 19MB

-----------------------------------------------------------
client/core buffer manager will also be affected when using MIN_HEAP:
disables PerfectPlay/BufferedPlay
disables buffering-size-increment when re-buffering

On android platform, when using MIN_HEAP, the TCP_BUF_SIZE of 2k is too 
small to stream http/rtsp content smoothly.  If you have to use 
MIN_HEAP, at least bump up netio's TCP_BUF_SIZE.  The preroll is short 
under MIN_HEAP.  This may cause re-buffering under certain network 
conditions.

2) http byte-range seeking
Some of the fileformat's read pattens at the start up can trigger 
frequent byte-range seeking in the httpfilesys, creating gaps in the 
cache and degrading performance.  If those gaps in the chunkyres cache 
need to be filled during playback, it will disrupt normal data 
downloading.  Put some logging code in function 
CHTTPFileObject::_HandleByteRangeSeek().  If you see frequent byte-range 
seek within a narrow data range, you then might consider bumping up the 
BYTE_RANGE_SEEK_THRESHHOLD value.  For the head and hxclient_3_1_0_atlas 
branch, we have increased it from 4k to 256k under normal heap.

3) CPU usage
Make sure that you use release build for performance test.  If you are 
using helix logging,  turn it off or lowever the logging level.  If you 
are able to stream your content smoothly but are concerned with the http 
cpu usage, you can experiment with the ProcessIdle() callback frequency 
by giving a larger value for m_pCallback->ScheduleRelative(m_pScheduler, 
50) call.

Qiang

On 9/3/2009 7:14 AM, John Stirling wrote:
> We have our own 'fasthttp' plugin that we normally use for local upnp 
> streaming (we wrote that plugin because were getting periodic out of 
> memory crashes when running overnight tests with the standard http 
> filesys which were pretty difficult to track down the cause).
>
> If we plug that in in place of the standard http:// filesys then CPU 
> goes back down to just over 35% for the same content. Unfortunately 
> that has throughput issues when we go to 24/96 data rates.
>
> I'll try your null renderer experiment as well.
>
> It sounds like our best plan might be to make our fasthttp plugin 
> faster. Those 10k lines of httpfsys code are scaring me off a bit...
>
> John
>
> Eric Hyche wrote:
>> It might be useful to stick in the NULL renderer (datatype/null/renderer) so that there is no CPU usage from decoding and see what
>> the CPU usage is for http playback. That should tell you how much of the CPU is being used for network versus how much for
>> decoding/rendering.
>>
>> Eric
>>
>> =======================================
>> Eric Hyche ([email protected])
>> Principal Engineer
>> RealNetworks, Inc.
>>
>>      
>>> -----Original Message-----
>>> From: John Stirling [mailto:[email protected]]
>>> Sent: Thursday, September 03, 2009 4:29 AM
>>> To:[email protected]
>>> Cc: 'Helix client dev'
>>> Subject: Re: [Helix-client-dev] 24/96 playback viahttp://
>>>
>>> Hi Eric,
>>>
>>> Tried that (and a few other http feature combinations) but doesn't really improve things.
>>>
>>> Does 35% CPU forfile://  playback compared to 55% forhttp://  sound about right to you ?
>>>
>>> If there are any other global HELIX_FEATURES you think might help let me know.
>>>
>>> Eric Hyche wrote:
>>>
>>> 	John,
>>>
>>> 	You might try without MIN_HEAP. I believe MIN_HEAP reduces the limiting size of some buffers
>>> which would probably affect http
>>> 	throughput. Of course, removing MIN_HEAP means that your memory usage will go up.
>>>
>>> 	Eric
>>>
>>> 	=======================================
>>> 	Eric Hyche ([email protected])
>>> 	Principal Engineer
>>> 	RealNetworks, Inc.
>>>
>>> 		-----Original Message-----
>>> 		From:[email protected]  [mailto:helix-client-dev-
>>> [email protected]]
>>> 		On Behalf Of John Stirling
>>> 		Sent: Wednesday, September 02, 2009 6:12 AM
>>> 		To: Helix client dev
>>> 		Subject: [Helix-client-dev] 24/96 playback viahttp://
>>>
>>> 		We're having a few issues getting 24/96 .wav to play smoothly via
>>> 		http://  (from a local upnp server)
>>>
>>> 		We're using an atlas http fsys with the following HELIX_FEATURES -
>>>
>>> 		# The basic audio only profile
>>> 		exec_profile_file("helix-client-audio-all.pf")
>>>
>>> 		# Enable function level linking - reduces code size by approx 30%
>>> 		project.AddDefines('HELIX_CONFIG_USE_RLINK')
>>>
>>> 		# Remove video related stuff
>>> 		project.RemoveDefines('HELIX_FEATURE_VIDEO')
>>> 		project.RemoveDefines("USE_XWINDOWS")
>>> 		project.AddDefines("HELIX_CONFIG_NO_XWINDOWS")
>>>
>>> 		# Hopefully fixes MP3 Locker playback
>>> 		project.RemoveDefines('HELIX_FEATURE_HTTP_GZIP')
>>> 		project.AddDefines("HELIX_FEATURE_HTTP_MEMCACHE")
>>> 		project.AddDefines("HELIX_FEATURE_MIN_HEAP")
>>>
>>> 		Our CPU load forhttp://  playback is approx 55%. Playing the same
>>> 		content via local thumbdrive (file://) cpu load is approx 35%. So don't
>>> 		think cpu is getting overloaded.
>>>
>>> 		Our raw network throughput is approx 620 kB/s with 24/96 .wav content
>>> 		needing 576kB/s (measure using curl<url>  >  /dev/null). Fairly close to
>>> 		the edge but would have though that should be ok.
>>>
>>> 		Is there anything obviously wrong with our feature set or are there any
>>> 		HELIX_FEATURES or parameters that would be worth trying or adjusting ?
>>>
>>> 		Also, can someone explain what these features are for -
>>>
>>> 		HELIX_FEATURE_HTTP_MEMCACHE
>>> 		HELIX_FEATURE_MIN_HEAP
>>> 		HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT
>>>
>>> 		John
>>> 		_______________________________________________
>>> 		Helix-client-dev mailing list
>>> 		[email protected]
>>> 		http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>        
> ------------------------------------------------------------------------
> _______________________________________________
> Helix-client-dev mailing list
> [email protected]
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev