Why is the MAX_READ_SIZE of local FS plugin changed? A summary of the
new/modified change please.

fxd

Joe Li wrote:
> Hi, Sheldon
> 	Diff updated; please help to review it.
> Thanks.
> Joe
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Sheldon Fu=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1=D4=C225=C8=D5=D0=C7=C6=DA=B6=FE 2=
2:04
> =CA=D5=BC=FE=C8=CB: Joe Li
> =B3=AD=CB=CD: Gurpreet Ahluwalia; Helen Hua; Qiang Luo; Kinson Liu; Cai=
jun Song; Frank Lan
> =D6=F7=CC=E2: Re: =B4=F0=B8=B4: =B4=F0=B8=B4: =B4=F0=B8=B4: =B4=F0=B8=B4=
: RESEND: CR: mkv support seeking without cues
>
> Would it be better then to limit the duration (and seek range) to what
> is available? The best time we can do this is at the init time to get
> the correct duration so that the UI won't even give user a change to
> seek out of range.
>
> If this is not possible (e.g. we don't know if the linked mkv
> presentation has a next segment or not), at least we could do this at
> the seek time -- instead of quiting, we should gracefully let the seek
> fail and keep the playback going from the current position, or the
> furthest point we can go.
>
> Not letting user know where he can seek to or not and then fail the
> playback if he does seek out of range probably will annoy the user.
>
> fxd
>
> Joe Li wrote:
>  =20
>> SEEKING_IN_MKV error code is for some media downloads from website, it=
 is just a part of whole mkv movie.
>> If you seek to out of the actually length of media, we can't read any =
packets, so quit the player and report the error codes.
>> Thanks
>> Joe
>>
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Sheldon Fu=20
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1=D4=C225=C8=D5=D0=C7=C6=DA=B6=FE =
21:10
>> =CA=D5=BC=FE=C8=CB: Joe Li
>> =B3=AD=CB=CD: Gurpreet Ahluwalia; Helen Hua; Qiang Luo; Kinson Liu; Ca=
ijun Song; Frank Lan
>> =D6=F7=CC=E2: Re: =B4=F0=B8=B4: =B4=F0=B8=B4: =B4=F0=B8=B4: RESEND: CR=
: mkv support seeking without cues
>>
>> Overall logic looks good to me but somebody familiar with mkv lib shou=
ld
>> have a look since this is quite some changes. (Not sure who though.
>> Unfortunately it might be some Nokia developers who are most qualified
>> for the review)
>>
>> Why do we still report error of SEEKING_IN_MKV? Should we be able to d=
o
>> seek for any mkv file now?
>>
>> fxd
>>
>> Joe Li wrote:
>>  =20
>>    =20
>>> Diff updates.
>>> Fixed one seeking 2 blank cluster issue=20
>>> Removed some codes for normal mkv files.
>>> Thanks
>>> Joe
>>>
>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>> =B7=A2=BC=FE=C8=CB: Gurpreet Ahluwalia=20
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1=D4=C224=C8=D5=D0=C7=C6=DA=D2=BB=
 13:42
>>> =CA=D5=BC=FE=C8=CB: Joe Li
>>> =B3=AD=CB=CD: Sheldon Fu; Helen Hua; Qiang Luo; Kinson Liu; Caijun So=
ng; Frank Lan
>>> =D6=F7=CC=E2: Re: =B4=F0=B8=B4: =B4=F0=B8=B4: RESEND: CR: mkv support=
 seeking without cues
>>>
>>> As this is needed quite urgently we should go ahead and check it in.
>>> We can further experiment to optimize it later on.
>>>
>>> Best Regards,
>>> Gurpreet
>>>
>>> On 1/24/2011 8:53 AM, Joe Li wrote:
>>>  =20
>>>    =20
>>>      =20
>>>> Thanks Sheldon, Please help to review the codes change.
>>>> The feature final Release date is 2011/1/26. So it's urgent.
>>>>
>>>> Hi, all
>>>> Is there any advice for those codes changing?
>>>> Any comments welcomed.
>>>> Thanks all
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>> =B7=A2=BC=FE=C8=CB: Sheldon Fu=20
>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1=D4=C221=C8=D5=D0=C7=C6=DA=CE=E5=
 19:54
>>>> =CA=D5=BC=FE=C8=CB: Gurpreet Ahluwalia
>>>> =B3=AD=CB=CD: Joe Li; Helen Hua; Qiang Luo; Kinson Liu; Caijun Song;=
 Frank Lan
>>>> =D6=F7=CC=E2: Re: =B4=F0=B8=B4: RESEND: CR: mkv support seeking with=
out cues
>>>>
>>>> It may not be possible if the mkv lib is not re-entrantable. Besides=
,
>>>> seeking is a rare event, building a full index up front and will not=
 be
>>>> used in most cases may not exactly be a good idea.
>>>>
>>>> A constant seek time is also important for Android suspend/resume
>>>> operation (you are supposed to seek to the last played position. MKV=
s
>>>> normally are movies in large size.
>>>>
>>>> We are not saving offsets of all frames, we are saving offsets of
>>>> clusters, which contains multiple frames. Parsing just up to cluster
>>>> level and let the rest of the search happen on demand is a compromis=
e
>>>> for startup speed and seek performance.
>>>>
>>>> fxd
>>>>
>>>> Gurpreet Ahluwalia wrote:
>>>>  =20
>>>>    =20
>>>>      =20
>>>>        =20
>>>>> yes, I think it will still be good idea to do that.
>>>>> Also we are creating index at when preparing file header. It does
>>>>> increase the start up time.
>>>>> Would it be possible to generate index as we play like we do in wm
>>>>> file format.
>>>>>
>>>>> And if we get a seek point thats further then what we indexed upto,=
 we
>>>>> can keep skipping the frame and updating the index till we reach se=
ek
>>>>> point.
>>>>>
>>>>> Best Regards,
>>>>> Gurpreet
>>>>>
>>>>>
>>>>> On 1/21/2011 4:22 PM, Joe Li wrote:
>>>>>    =20
>>>>>      =20
>>>>>        =20
>>>>>          =20
>>>>>> Hi, Gurpreet
>>>>>>
>>>>>> I don=A1=AFt think so.
>>>>>>
>>>>>> If we check if it is keyframe or not? We need to deep into cluster=
s,
>>>>>> and check blocks in blockgroup, it will takes more time.
>>>>>>
>>>>>> Structure looks like:
>>>>>>
>>>>>> cluster
>>>>>>
>>>>>> blockgroup
>>>>>>
>>>>>> block
>>>>>>
>>>>>> frame
>>>>>>
>>>>>> =A1=AD
>>>>>>
>>>>>> Frame
>>>>>>
>>>>>> =A1=AD
>>>>>>
>>>>>> Blockgroup
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> ------------------------------------------------------------------=
------
>>>>>>
>>>>>> *=B7=A2=BC=FE=C8=CB:* Gurpreet Ahluwalia
>>>>>> *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA1=D4=C221=C8=D5=D0=C7=C6=DA=CE=
=E5 18:34
>>>>>> *=CA=D5=BC=FE=C8=CB:* Joe Li
>>>>>> *=B3=AD=CB=CD:* Helen Hua; Sheldon Fu; Qiang Luo; Kinson Liu; Caij=
un Song;
>>>>>> Frank Lan; android-port-dev at helixcommunity.org;
>>>>>> datatype-dev at helixcommunity.org
>>>>>> *=D6=F7=CC=E2:* Re: RESEND: CR: mkv support seeking without cues
>>>>>>
>>>>>> Hi Joe,
>>>>>> It looks like when preparing index we are saving offset of all fra=
mes.
>>>>>> It would be better if we save only keyframe offsets.That would mak=
e
>>>>>> seeking much faster.
>>>>>> In function ParseOtherClusters, we should add a check for that.
>>>>>>
>>>>>> Best Regards,
>>>>>> Gurpreet
>>>>>>
>>>>>>
>>>>>> On 1/21/2011 2:15 PM, Joe Li wrote:
>>>>>>
>>>>>> Update diffs.
>>>>>>
>>>>>> Removed some work-around codes.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> ------------------------------------------------------------------=
------
>>>>>>
>>>>>> *=B7=A2=BC=FE=C8=CB:* Helen Hua
>>>>>> *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA1=D4=C220=C8=D5=D0=C7=C6=DA=CB=
=C4 21:22
>>>>>> *=CA=D5=BC=FE=C8=CB:* Sheldon Fu; Gurpreet Ahluwalia; Qiang Luo; K=
inson Liu;
>>>>>> Caijun Song
>>>>>> *=B3=AD=CB=CD:* Frank Lan; Joe Li; Helen Hua
>>>>>> *=D6=F7=CC=E2:* =D7=AA=B7=A2: CR: mkv support seeking without cues
>>>>>> *=D6=D8=D2=AA=D0=D4:* =B8=DF
>>>>>>
>>>>>> HI, experts,
>>>>>>
>>>>>> Please review the mkv seek without cues code change from Joe, than=
ks.
>>>>>> this is must have feature for U1 shipment.
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Helen
>>>>>>
>>>>>> *=B7=A2=BC=FE=C8=CB:* android-port-dev-bounces at lists.helixcommunit=
y.org
>>>>>> <mailto:android-port-dev-bounces at lists.helixcommunity.org>
>>>>>> [mailto:android-port-dev-bounces at lists.helixcommunity.org] *=B4=FA=
=B1=ED *Joe Li
>>>>>> *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA1=D4=C220=C8=D5 21:15
>>>>>> *=CA=D5=BC=FE=C8=CB:* android-port-dev at helixcommunity.org
>>>>>> <mailto:android-port-dev at helixcommunity.org>;
>>>>>> datatype-dev at helixcommunity.org <mailto:datatype-dev at helixcommunit=
y.org>
>>>>>> *=D6=F7=CC=E2:* [Android-port-dev] CR: mkv support seeking without=
 cues
>>>>>>
>>>>>> Modified by: joeli at real.com <mailto:joeli at real.com>
>>>>>>
>>>>>> Date: 2011-01-20
>>>>>>
>>>>>> Project: RealPlayer for Android Smartphones
>>>>>>
>>>>>> Overview:
>>>>>>
>>>>>> Current mkv component can=A1=AFt seek some contents without seekin=
g cues.
>>>>>>
>>>>>> And now we modified the fileformat to use clusters in mkv files fo=
r
>>>>>> seeking.
>>>>>>
>>>>>> * *
>>>>>>
>>>>>> Files Added:
>>>>>>
>>>>>> NA
>>>>>>
>>>>>> Files Modified:
>>>>>>
>>>>>> client/core/hxflsrc.cpp
>>>>>>
>>>>>> common/include/hxresult.h
>>>>>>
>>>>>> datatype/mkv/fileformat/mkv_file_format.cpp
>>>>>>
>>>>>> datatype/mkv/fileformat/pub/mkv_file_format.h
>>>>>>
>>>>>> datatype/mkv/libmatroska/Matroska.cpp
>>>>>>
>>>>>> datatype/mkv/libmatroska/Matroska.h
>>>>>>
>>>>>> Image Size and Heap Use impact (Client-Only):
>>>>>>
>>>>>> None
>>>>>>
>>>>>> Platforms and Profiles Affected:
>>>>>>
>>>>>> Platform: hxclient_3_6_2_atlas
>>>>>>
>>>>>> Profile: helix-client-android and helix-client-all-defines
>>>>>>
>>>>>> Distribution Libraries Affected:
>>>>>>
>>>>>> NA
>>>>>>
>>>>>> Distribution library impact and planned action:
>>>>>>
>>>>>> NA
>>>>>>
>>>>>> Platforms and Profiles Build Verified:
>>>>>>
>>>>>> Platform: hxclient_3_6_2_atlas
>>>>>>
>>>>>> Profile: helix-client-android and helix-client-all-defines
>>>>>>
>>>>>> Platforms and Profiles Functionality verified:
>>>>>>
>>>>>> Platform: hxclient_3_6_2_atlas
>>>>>>
>>>>>> Profile: helix-client-android and helix-client-all-defines
>>>>>>
>>>>>> Branch: hxclient_3_6_2_atlas
>>>>>>
>>>>>> Copyright assignment: I am a RealNetworks employee
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>>      =20
>>>>>>        =20
>>>>>>          =20
>>>>>>            =20
>>>>>    =20
>>>>>      =20
>>>>>        =20
>>>>>          =20
>>>>  =20
>>>>    =20
>>>>      =20
>>>>        =20
>>>  =20
>>>    =20
>>>      =20
>>  =20
>>    =20
>
>  =20