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

List:       helix-filesystem-dev
Subject:    [Filesystem-dev] RE: [datatype-dev] CR: mp4 fileformat and http
From:       "Eric Hyche" <ehyche () real ! com>
Date:       2009-08-31 13:12:04
Message-ID: 005501ca2a3c$a3733040$ea5990c0$ () com
[Download RAW message or body]

Changes look good. Just one word of caution: MIN_HEAP has a lot of impact in a lot of \
places, mainly in audio and video renderer. In video renderer, it greatly reduces the \
size of the decoded frame queue. So without MIN_HEAP, the number of decoded frames in \
the base video renderer will probably be about 15. Just make sure that the devices \
you are running on have enough memory to handle having 15 decompressed frames in \
memory.

Of course, now that I think about it, you are probably using hardware decode for most \
codecs, so your memory management is totally different, and this may not be an issue. \
You might try playback of some codec that does not have hardware decode (like RV) and \
see if it still works without MIN_HEAP.

Eric

=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.


> -----Original Message-----
> From: datatype-dev-bounces@helixcommunity.org \
> [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Qiang Luo
> Sent: Sunday, August 30, 2009 12:27 AM
> To: datatype-dev@helixcommunity.org; filesystem-dev@helixcommunity.org; \
> android-port- dev@lists.helixcommunity.org
> Subject: [datatype-dev] CR: mp4 fileformat and http filesystem fixes for mp4 http \
> streaming 
> Synopsis:
> mp4 fileformat and http filesystem fixes for mp4 http streaming.
> 
> Summary:
> We are having some issues streaming mp4 contents over http.  The playback often \
> fails to start or gets stuck/dead-locked in the middle.
> It is particularly problematic when streaming mp4 tracks of long durations.  This \
> bug seems to repro on all platform/players that I have
> tested: windows RealPlayer SP,  RealPlayer for Netbook, helix splay on linux, and \
> HelixPlayer for android.  The main issue is related to the
> mp4 fileformat where it treats and drives httpfilesystem as if it supports \
> synchronized file access. 
> There are 3 changes in this CR:
> 1) fix in httpfsys/mp4ff to avoid synchronized file access mode, taking care of  \
> the none- staring/dead-locking issue.
> 2) bumping up BYTE_RANGE_SEEK_THRESHHOLD from 4k to 256k to avoid creating too many \
> gaps in the chunkyres cache.  This improves playback performance by avoiding \
> frequent byte-range seeks in order to access the
> mp4 sample table in the header.
> 3) take out the HELIX_FEATURE_MIN_HEAP from android build profile.  On android, the \
> MIN_HEAP preroll seems to be too small to streaming YouTube contents smoothly.
> 
> Branches:
> head, hxclient_3_1_0_atlas, other branches on request
> 
> Platforms tested:
> windoes(RealPlayer SP), linux desktop(splay), android(HelixPlayer)
> 
> Files modified:
> filesystem/http/httpfsys.cpp
> datatype/mp4/fileformat/atomizer.cpp
> datatype/mp4/fileformat/mempager.cpp
> ribosome/build/umakepf/helix-client-android.pf
> 
> Please review attached diff.
> 
> Qiang


_______________________________________________
Filesystem-dev mailing list
Filesystem-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev


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