Re: 24/96 playback via http://

Thanks. Will try some of your suggestions.

John


Qiang Luo wrote:
> 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 via http://
>>>>
>>>> Hi Eric,
>>>>
>>>> Tried that (and a few other http feature combinations) but doesn't really improve things.
>>>>
>>>> Does 35% CPU for file:// playback compared to 55% for http:// 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 via http://
>>>>
>>>> 		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 for http:// 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