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

List:       helix-datatype-dev
Subject:    RE: [datatype-dev] CR: mp4 fileformat fix for http streaming
From:       "Eric Hyche" <ehyche () real ! com>
Date:       2009-08-27 15:50:39
Message-ID: 00b401ca272e$212f3040$638d90c0$ () com
[Download RAW message or body]

+    , m_ulFileSize(0)

Perhaps m_ulFileSize should be initialized to ATOMIZE_ALL since
if StatDone() returns a failure then m_ulFileSize will still
be 0 when passed into the Atomize() call.

Eric

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


>-----Original Message-----
>From: Qiang Luo [mailto:qluo@real.com]
>Sent: Thursday, August 27, 2009 11:39 AM
>To: ehyche@real.com
>Cc: datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR: mp4 fileformat fix for http streaming
>
>Thanks for the review Eric.  I have made the file stat optional.  Please review attached new diff.
>
>Qiang
>
>On 8/27/2009 7:43 AM, Eric Hyche wrote:
>> It looks like from this diff that if the IHXFileObject does not
>> support IHXFileStat, that IHXFileFormatObject::Init() will always
>> fail. I don't think this should be a requirement. If the IHXFileObject does support IHXFileStat, we
>can use that information as you do in the diff. However, if the IHXFileObject does not support
>IHXFileStat, we should do exactly what we currently do.
>>
>> Rest looks good.
>>
>> 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: Thursday, August 27, 2009 12:48 AM
>>> To: datatype-dev@helixcommunity.org
>>> Subject: [datatype-dev] CR: mp4 fileformat fix for http streaming
>>>
>>> Synopsis:
>>> mp4 fileformat fix for http streaming.
>>>
>>> Summary:
>>> The mp4 header parsing code, the CAtomizer, walks through all atoms
>>> until certain conditions are met: the offset for the next atom is out
>>> of  range or the next atom read returns an error.  In the current
>>> implementation, we do not set the atom offset range limit.  In
>>> attempt to get to the next atom, we end up seeking over the last
>>> atom(usually the "mdat" atom) to the end of file.  While this may not
>>> be an issue for local playback(where we can do random seek without
>>> penalty), however for http streaming, it  will force an byte-range
>>> seek with network re-connect, disrupting normal downloading data
>>> flow.  The fix is to call stat on the http fileobject and set the
>>> atomizer offset range limit to the file size.
>>>
>>> Branches:
>>> head, hxclient_3_1_0_atla
>>>
>>> Files modified:
>>> datatype/mp4/fileformat/qtffplin.cpp
>>> datatype/mp4/fileformat/pub/qtffplin.h
>>>
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>


_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
[prev in list] [next in list] [prev in thread] [next in thread]