WMA seek problem

The problem you describe seems to be a limitation of the
on-the-fly seek table. It doesn't really have the
notion of how "good" its seek offset estimate is
-
it just knows whether it has one or not. 

The short-term fix might be to look at the logic
in the seek table and if the time gap between 
the chosen offset and the next one is too great,
then return failure. This will cause the ASF fileformat
to fall back to using the ASF file's index tables.

Let me describe this in more detail. Suppose we have
a WMV that's 10 minutes long with keyframes every 10
seconds. At the beginning of playback, then the first
few entries are made in the on-the-fly table:

Time(ms)     Offset(bytes)
----------------------------------
0            xxxx
10000        yyyy
20000        zzzz

and then after you seek to close to the end of
the file, entries get made close to the end:

Time(sec)   Offset(bytes)
----------------------------------
0            xxxx
10           yyyy
20           zzzz
580          aaaa
590          bbbb

and then if you seek to 572 seconds, then
the on-the-fly seek table will choose 20 seconds
and zzzz as the time and offset. Clearly this is
the correct but inefficient choice, since the ASF
fileformat
will scan from zzzz all the way until it finds
the real last keyframe before 572 seconds, which
would be at 570 seconds.

I think one fix for this would be to set some sort
of maximum keyframe delta, and then if the difference
between the returned time (20s) and the next time entry
in the table (580s) is too great, then return failure.

Ideally this maximum delta should be chosen by analyzing
the deltas in the current table. The deltas in
the table above would be 10,10,560,10. Practically,
you could just set a reasonably high maximum keyframe
delta,
such as perhaps 60s or so.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: datatype-dev-bounceshelixcommunity.org 
> [mailto:datatype-dev-bounceshelixcommunity.org] On
Behalf Of 
> Gang.Jianokia.com
> Sent: Wednesday, December 19, 2007 5:02 PM
> To: datatype-devhelixcommunity.org
> Subject: [datatype-dev] WMA seek problem
> 
> Hi 
> 
> I have a WMA seek problem related to the on-the-fly
seek 
> table. If you have a long WMA clip (>10min), start
to seek 
> forward just after it starts to play. Seek to close the
end 
> of the clip, stop seek forward and start to seek
backward a 
> little bit. After that the behavior is unpredictable. 
> Sometimes it starts to play after a long delay,
sometimes it 
> just hangs. 
> 
> The problem here is the way ASF index fill in the seek
table. 
> After the first seek, we jump a lot in the seek table
then it 
> tries to fill in the table using the last valid entry.

> However these entries could be off a lot. After the 2nd
seek 
> one of these filled in entry is read as the seek
position and 
> the file offset is from it. Since this value could be
off a 
> lot to the actual seek position it can cause very long

> buffering time and sometimes hang the player.
> 
> If I disable this fill in at
CHXASFIndex::SetIndexEntry(), it 
> will fix the problem I mentioned above. But this is in
the 
> common code and it must be some reason to have it
there.
> 
> Another thing is what is the WallclockDelay used for in

> BufferManager? I noticed in this case the
WallclockDelay is 
> getting larger than normal ( this is because the way it
get 
> calculated). 
> 
> If you need a clip to reproduce the problem I can send
it separately. 
> 
> Thanks, 
> Gang 
> 
> 


_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev

Thanks Eric. I will try this approach.

Gang 

>-----Original Message-----
>From: ext Eric Hyche [mailto:ehychereal.com]

>Sent: Wednesday, January 02, 2008 10:32 AM
>To: Jia Gang (Nokia-TP-MSW/Dallas); datatype-devhelixcommunity.org
>Subject: RE: [datatype-dev] WMA seek problem
>
>
>The problem you describe seems to be a limitation of the

>on-the-fly seek table. It doesn't really have the notion
of 
>how "good" its seek offset estimate is - it
just knows whether 
>it has one or not. 
>
>The short-term fix might be to look at the logic in the
seek 
>table and if the time gap between the chosen offset and
the 
>next one is too great, then return failure. This will
cause 
>the ASF fileformat to fall back to using the ASF file's
index tables.
>
>Let me describe this in more detail. Suppose we have a
WMV 
>that's 10 minutes long with keyframes every 10 seconds.
At the 
>beginning of playback, then the first few entries are
made in 
>the on-the-fly table:
>
>Time(ms)     Offset(bytes)
>----------------------------------
>0            xxxx
>10000        yyyy
>20000        zzzz
>
>and then after you seek to close to the end of the file,

>entries get made close to the end:
>
>Time(sec)   Offset(bytes)
>----------------------------------
>0            xxxx
>10           yyyy
>20           zzzz
>580          aaaa
>590          bbbb
>
>and then if you seek to 572 seconds, then the on-the-fly
seek 
>table will choose 20 seconds and zzzz as the time and
offset. 
>Clearly this is the correct but inefficient choice,
since the 
>ASF fileformat will scan from zzzz all the way until it
finds 
>the real last keyframe before 572 seconds, which would
be at 
>570 seconds.
>
>I think one fix for this would be to set some sort of
maximum 
>keyframe delta, and then if the difference between the 
>returned time (20s) and the next time entry in the table

>(580s) is too great, then return failure.
>
>Ideally this maximum delta should be chosen by analyzing
the 
>deltas in the current table. The deltas in the table
above 
>would be 10,10,560,10. Practically, you could just set a

>reasonably high maximum keyframe delta, such as perhaps
60s or so.
>
>Eric
>
>=============================================
>Eric Hyche (ehychereal.com)
>Technical Lead
>RealNetworks, Inc.  
>
>> -----Original Message-----
>> From: datatype-dev-bounceshelixcommunity.org
>> [mailto:datatype-dev-bounceshelixcommunity.org] On
Behalf Of 
>> Gang.Jianokia.com
>> Sent: Wednesday, December 19, 2007 5:02 PM
>> To: datatype-devhelixcommunity.org
>> Subject: [datatype-dev] WMA seek problem
>> 
>> Hi
>> 
>> I have a WMA seek problem related to the on-the-fly
seek 
>table. If you 
>> have a long WMA clip (>10min), start to seek
forward just after it 
>> starts to play. Seek to close the end of the clip,
stop seek forward 
>> and start to seek backward a little bit. After that
the behavior is 
>> unpredictable.
>> Sometimes it starts to play after a long delay,
sometimes it just 
>> hangs.
>> 
>> The problem here is the way ASF index fill in the
seek table. 
>> After the first seek, we jump a lot in the seek
table then 
>it tries to 
>> fill in the table using the last valid entry.
>> However these entries could be off a lot. After the
2nd seek one of 
>> these filled in entry is read as the seek position
and the 
>file offset 
>> is from it. Since this value could be off a lot to
the actual seek 
>> position it can cause very long buffering time and
sometimes 
>hang the 
>> player.
>> 
>> If I disable this fill in at
CHXASFIndex::SetIndexEntry(), 
>it will fix 
>> the problem I mentioned above. But this is in the
common code and it 
>> must be some reason to have it there.
>> 
>> Another thing is what is the WallclockDelay used
for in 
>BufferManager? 
>> I noticed in this case the WallclockDelay is
getting larger than 
>> normal ( this is because the way it get
calculated).
>> 
>> If you need a clip to reproduce the problem I can
send it 
>separately. 
>> 
>> Thanks,
>> Gang
>> 
>> 
>
>

_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev

Gang,

In thinking through this some more, I'm thinking the
fileformat should have behaved like this when seeked
to the end of the file:

1) Try the on-the-fly table and it should fail
   (since it only has the first few keyframe entries)
2) Try to read the ASF index table entries at
   the end of the file.

When it is reading the ASF index table entries,
it *should* be simultaneously adding all of the
ASF index table entries into the on-the-fly seek table,
so that the next time on-the-fly table is consulted,
it should be complete. Are the ASF index table
entries not being added to the on-the-fly table,
or does this particular content file simply not
*have* an ASF index table?

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Gang.Jianokia.com [mailto:Gang.Jianokia.com] 
> Sent: Wednesday, January 02, 2008 12:48 PM
> To: ehychereal.com; datatype-devhelixcommunity.org
> Subject: RE: [datatype-dev] WMA seek problem
> 
> Thanks Eric. I will try this approach.
> 
> Gang 
> 
> >-----Original Message-----
> >From: ext Eric Hyche [mailto:ehychereal.com]

> >Sent: Wednesday, January 02, 2008 10:32 AM
> >To: Jia Gang (Nokia-TP-MSW/Dallas);
datatype-devhelixcommunity.org
> >Subject: RE: [datatype-dev] WMA seek problem
> >
> >
> >The problem you describe seems to be a limitation
of the 
> >on-the-fly seek table. It doesn't really have the
notion of 
> >how "good" its seek offset estimate is -
it just knows whether 
> >it has one or not. 
> >
> >The short-term fix might be to look at the logic in
the seek 
> >table and if the time gap between the chosen offset
and the 
> >next one is too great, then return failure. This
will cause 
> >the ASF fileformat to fall back to using the ASF
file's index tables.
> >
> >Let me describe this in more detail. Suppose we
have a WMV 
> >that's 10 minutes long with keyframes every 10
seconds. At the 
> >beginning of playback, then the first few entries
are made in 
> >the on-the-fly table:
> >
> >Time(ms)     Offset(bytes)
> >----------------------------------
> >0            xxxx
> >10000        yyyy
> >20000        zzzz
> >
> >and then after you seek to close to the end of the
file, 
> >entries get made close to the end:
> >
> >Time(sec)   Offset(bytes)
> >----------------------------------
> >0            xxxx
> >10           yyyy
> >20           zzzz
> >580          aaaa
> >590          bbbb
> >
> >and then if you seek to 572 seconds, then the
on-the-fly seek 
> >table will choose 20 seconds and zzzz as the time
and offset. 
> >Clearly this is the correct but inefficient choice,
since the 
> >ASF fileformat will scan from zzzz all the way
until it finds 
> >the real last keyframe before 572 seconds, which
would be at 
> >570 seconds.
> >
> >I think one fix for this would be to set some sort
of maximum 
> >keyframe delta, and then if the difference between
the 
> >returned time (20s) and the next time entry in the
table 
> >(580s) is too great, then return failure.
> >
> >Ideally this maximum delta should be chosen by
analyzing the 
> >deltas in the current table. The deltas in the
table above 
> >would be 10,10,560,10. Practically, you could just
set a 
> >reasonably high maximum keyframe delta, such as
perhaps 60s or so.
> >
> >Eric
> >
> >=============================================
> >Eric Hyche (ehychereal.com)
> >Technical Lead
> >RealNetworks, Inc.  
> >
> >> -----Original Message-----
> >> From: datatype-dev-bounceshelixcommunity.org
> >> [mailto:datatype-dev-bounceshelixcommunity.org] On Behalf Of 
> >> Gang.Jianokia.com
> >> Sent: Wednesday, December 19, 2007 5:02 PM
> >> To: datatype-devhelixcommunity.org
> >> Subject: [datatype-dev] WMA seek problem
> >> 
> >> Hi
> >> 
> >> I have a WMA seek problem related to the
on-the-fly seek 
> >table. If you 
> >> have a long WMA clip (>10min), start to
seek forward just after it 
> >> starts to play. Seek to close the end of the
clip, stop 
> seek forward 
> >> and start to seek backward a little bit. After
that the 
> behavior is 
> >> unpredictable.
> >> Sometimes it starts to play after a long
delay, sometimes it just 
> >> hangs.
> >> 
> >> The problem here is the way ASF index fill in
the seek table. 
> >> After the first seek, we jump a lot in the
seek table then 
> >it tries to 
> >> fill in the table using the last valid entry.
> >> However these entries could be off a lot.
After the 2nd 
> seek one of 
> >> these filled in entry is read as the seek
position and the 
> >file offset 
> >> is from it. Since this value could be off a
lot to the actual seek 
> >> position it can cause very long buffering time
and sometimes 
> >hang the 
> >> player.
> >> 
> >> If I disable this fill in at
CHXASFIndex::SetIndexEntry(), 
> >it will fix 
> >> the problem I mentioned above. But this is in
the common 
> code and it 
> >> must be some reason to have it there.
> >> 
> >> Another thing is what is the WallclockDelay
used for in 
> >BufferManager? 
> >> I noticed in this case the WallclockDelay is
getting larger than 
> >> normal ( this is because the way it get
calculated).
> >> 
> >> If you need a clip to reproduce the problem I
can send it 
> >separately. 
> >> 
> >> Thanks,
> >> Gang
> >> 
> >> 
> >
> >
> 


_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev

In this case the file just doesn't have an index table.
Otherwise it
will be all fine after the first seek - the index object
will be copied
to the on-the-fly table.

Thanks,
Gang 

>-----Original Message-----
>From: ext Eric Hyche [mailto:ehychereal.com]

>Sent: Wednesday, January 02, 2008 11:59 AM
>To: Jia Gang (Nokia-TP-MSW/Dallas); datatype-devhelixcommunity.org
>Subject: RE: [datatype-dev] WMA seek problem
>
>
>Gang,
>
>In thinking through this some more, I'm thinking the 
>fileformat should have behaved like this when seeked to
the 
>end of the file:
>
>1) Try the on-the-fly table and it should fail
>   (since it only has the first few keyframe entries)
>2) Try to read the ASF index table entries at
>   the end of the file.
>
>When it is reading the ASF index table entries, it
*should* be 
>simultaneously adding all of the ASF index table entries
into 
>the on-the-fly seek table, so that the next time
on-the-fly 
>table is consulted, it should be complete. Are the ASF
index 
>table entries not being added to the on-the-fly table,
or does 
>this particular content file simply not
>*have* an ASF index table?
>
>Eric
>
>=============================================
>Eric Hyche (ehychereal.com)
>Technical Lead
>RealNetworks, Inc.  
>
>> -----Original Message-----
>> From: Gang.Jianokia.com [mailto:Gang.Jianokia.com]
>> Sent: Wednesday, January 02, 2008 12:48 PM
>> To: ehychereal.com; datatype-devhelixcommunity.org
>> Subject: RE: [datatype-dev] WMA seek problem
>> 
>> Thanks Eric. I will try this approach.
>> 
>> Gang
>> 
>> >-----Original Message-----
>> >From: ext Eric Hyche [mailto:ehychereal.com]
>> >Sent: Wednesday, January 02, 2008 10:32 AM
>> >To: Jia Gang (Nokia-TP-MSW/Dallas);
datatype-devhelixcommunity.org
>> >Subject: RE: [datatype-dev] WMA seek problem
>> >
>> >
>> >The problem you describe seems to be a
limitation of the on-the-fly 
>> >seek table. It doesn't really have the notion
of how "good" 
>its seek 
>> >offset estimate is - it just knows whether it
has one or not.
>> >
>> >The short-term fix might be to look at the
logic in the seek table 
>> >and if the time gap between the chosen offset
and the next 
>one is too 
>> >great, then return failure. This will cause the
ASF fileformat to 
>> >fall back to using the ASF file's index
tables.
>> >
>> >Let me describe this in more detail. Suppose we
have a WMV 
>that's 10 
>> >minutes long with keyframes every 10 seconds.
At the beginning of 
>> >playback, then the first few entries are made
in the on-the-fly 
>> >table:
>> >
>> >Time(ms)     Offset(bytes)
>> >----------------------------------
>> >0            xxxx
>> >10000        yyyy
>> >20000        zzzz
>> >
>> >and then after you seek to close to the end of
the file, 
>entries get 
>> >made close to the end:
>> >
>> >Time(sec)   Offset(bytes)
>> >----------------------------------
>> >0            xxxx
>> >10           yyyy
>> >20           zzzz
>> >580          aaaa
>> >590          bbbb
>> >
>> >and then if you seek to 572 seconds, then the
on-the-fly seek table 
>> >will choose 20 seconds and zzzz as the time and
offset.
>> >Clearly this is the correct but inefficient
choice, since the ASF 
>> >fileformat will scan from zzzz all the way
until it finds the real 
>> >last keyframe before 572 seconds, which would
be at 570 seconds.
>> >
>> >I think one fix for this would be to set some
sort of maximum 
>> >keyframe delta, and then if the difference
between the 
>returned time 
>> >(20s) and the next time entry in the table
>> >(580s) is too great, then return failure.
>> >
>> >Ideally this maximum delta should be chosen by
analyzing the deltas 
>> >in the current table. The deltas in the table
above would be 
>> >10,10,560,10. Practically, you could just set a
reasonably high 
>> >maximum keyframe delta, such as perhaps 60s or
so.
>> >
>> >Eric
>> >
>> >=============================================
>> >Eric Hyche (ehychereal.com)
>> >Technical Lead
>> >RealNetworks, Inc.  
>> >
>> >> -----Original Message-----
>> >> From: datatype-dev-bounceshelixcommunity.org
>> >> [mailto:datatype-dev-bounceshelixcommunity.org] On Behalf Of 
>> >> Gang.Jianokia.com
>> >> Sent: Wednesday, December 19, 2007 5:02
PM
>> >> To: datatype-devhelixcommunity.org
>> >> Subject: [datatype-dev] WMA seek problem
>> >> 
>> >> Hi
>> >> 
>> >> I have a WMA seek problem related to the
on-the-fly seek
>> >table. If you
>> >> have a long WMA clip (>10min), start to
seek forward just 
>after it 
>> >> starts to play. Seek to close the end of
the clip, stop
>> seek forward
>> >> and start to seek backward a little bit.
After that the
>> behavior is
>> >> unpredictable.
>> >> Sometimes it starts to play after a long
delay, sometimes it just 
>> >> hangs.
>> >> 
>> >> The problem here is the way ASF index fill
in the seek table. 
>> >> After the first seek, we jump a lot in the
seek table then
>> >it tries to
>> >> fill in the table using the last valid
entry.
>> >> However these entries could be off a lot.
After the 2nd
>> seek one of
>> >> these filled in entry is read as the seek
position and the
>> >file offset
>> >> is from it. Since this value could be off
a lot to the 
>actual seek 
>> >> position it can cause very long buffering
time and sometimes
>> >hang the
>> >> player.
>> >> 
>> >> If I disable this fill in at
CHXASFIndex::SetIndexEntry(),
>> >it will fix
>> >> the problem I mentioned above. But this is
in the common
>> code and it
>> >> must be some reason to have it there.
>> >> 
>> >> Another thing is what is the
WallclockDelay used for in
>> >BufferManager? 
>> >> I noticed in this case the WallclockDelay
is getting larger than 
>> >> normal ( this is because the way it get
calculated).
>> >> 
>> >> If you need a clip to reproduce the
problem I can send it
>> >separately. 
>> >> 
>> >> Thanks,
>> >> Gang
>> >> 
>> >> 
>> >
>> >
>> 
>
>

_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev

Ok, well in that case, the fix I mentioned 
earlier won't make any difference. If the on-the-fly
table fails out (as my fix suggested) and there
isn't any ASF index table, then the ASF fileformat
has no other choice but to scan from the beginning,
which is even worse than scanning from the point
that the on-the-fly table suggested.

So I think for ASF files with no ASF index, we're
simply doing the best we can. If there is no
ASF index, then the file hasn't been created
with random access in mind.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Gang.Jianokia.com [mailto:Gang.Jianokia.com] 
> Sent: Wednesday, January 02, 2008 1:09 PM
> To: ehychereal.com; datatype-devhelixcommunity.org
> Subject: RE: [datatype-dev] WMA seek problem
> 
> In this case the file just doesn't have an index table.
Otherwise it
> will be all fine after the first seek - the index
object will 
> be copied
> to the on-the-fly table.
> 
> Thanks,
> Gang 
> 
> >-----Original Message-----
> >From: ext Eric Hyche [mailto:ehychereal.com]

> >Sent: Wednesday, January 02, 2008 11:59 AM
> >To: Jia Gang (Nokia-TP-MSW/Dallas);
datatype-devhelixcommunity.org
> >Subject: RE: [datatype-dev] WMA seek problem
> >
> >
> >Gang,
> >
> >In thinking through this some more, I'm thinking
the 
> >fileformat should have behaved like this when
seeked to the 
> >end of the file:
> >
> >1) Try the on-the-fly table and it should fail
> >   (since it only has the first few keyframe
entries)
> >2) Try to read the ASF index table entries at
> >   the end of the file.
> >
> >When it is reading the ASF index table entries, it
*should* be 
> >simultaneously adding all of the ASF index table
entries into 
> >the on-the-fly seek table, so that the next time
on-the-fly 
> >table is consulted, it should be complete. Are the
ASF index 
> >table entries not being added to the on-the-fly
table, or does 
> >this particular content file simply not
> >*have* an ASF index table?
> >
> >Eric
> >
> >=============================================
> >Eric Hyche (ehychereal.com)
> >Technical Lead
> >RealNetworks, Inc.  
> >
> >> -----Original Message-----
> >> From: Gang.Jianokia.com
[mailto:Gang.Jianokia.com]
> >> Sent: Wednesday, January 02, 2008 12:48 PM
> >> To: ehychereal.com; datatype-devhelixcommunity.org
> >> Subject: RE: [datatype-dev] WMA seek problem
> >> 
> >> Thanks Eric. I will try this approach.
> >> 
> >> Gang
> >> 
> >> >-----Original Message-----
> >> >From: ext Eric Hyche [mailto:ehychereal.com]
> >> >Sent: Wednesday, January 02, 2008 10:32
AM
> >> >To: Jia Gang (Nokia-TP-MSW/Dallas); 
> datatype-devhelixcommunity.org
> >> >Subject: RE: [datatype-dev] WMA seek
problem
> >> >
> >> >
> >> >The problem you describe seems to be a
limitation of the 
> on-the-fly 
> >> >seek table. It doesn't really have the
notion of how "good" 
> >its seek 
> >> >offset estimate is - it just knows whether
it has one or not.
> >> >
> >> >The short-term fix might be to look at the
logic in the 
> seek table 
> >> >and if the time gap between the chosen
offset and the next 
> >one is too 
> >> >great, then return failure. This will
cause the ASF fileformat to 
> >> >fall back to using the ASF file's index
tables.
> >> >
> >> >Let me describe this in more detail.
Suppose we have a WMV 
> >that's 10 
> >> >minutes long with keyframes every 10
seconds. At the beginning of 
> >> >playback, then the first few entries are
made in the on-the-fly 
> >> >table:
> >> >
> >> >Time(ms)     Offset(bytes)
> >> >----------------------------------
> >> >0            xxxx
> >> >10000        yyyy
> >> >20000        zzzz
> >> >
> >> >and then after you seek to close to the
end of the file, 
> >entries get 
> >> >made close to the end:
> >> >
> >> >Time(sec)   Offset(bytes)
> >> >----------------------------------
> >> >0            xxxx
> >> >10           yyyy
> >> >20           zzzz
> >> >580          aaaa
> >> >590          bbbb
> >> >
> >> >and then if you seek to 572 seconds, then
the on-the-fly 
> seek table 
> >> >will choose 20 seconds and zzzz as the
time and offset.
> >> >Clearly this is the correct but
inefficient choice, since the ASF 
> >> >fileformat will scan from zzzz all the way
until it finds 
> the real 
> >> >last keyframe before 572 seconds, which
would be at 570 seconds.
> >> >
> >> >I think one fix for this would be to set
some sort of maximum 
> >> >keyframe delta, and then if the difference
between the 
> >returned time 
> >> >(20s) and the next time entry in the
table
> >> >(580s) is too great, then return failure.
> >> >
> >> >Ideally this maximum delta should be
chosen by analyzing 
> the deltas 
> >> >in the current table. The deltas in the
table above would be 
> >> >10,10,560,10. Practically, you could just
set a reasonably high 
> >> >maximum keyframe delta, such as perhaps
60s or so.
> >> >
> >> >Eric
> >> >
> >>
>=============================================
> >> >Eric Hyche (ehychereal.com)
> >> >Technical Lead
> >> >RealNetworks, Inc.  
> >> >
> >> >> -----Original Message-----
> >> >> From: datatype-dev-bounceshelixcommunity.org
> >> >> [mailto:datatype-dev-bounceshelixcommunity.org] On Behalf Of 
> >> >> Gang.Jianokia.com
> >> >> Sent: Wednesday, December 19, 2007
5:02 PM
> >> >> To: datatype-devhelixcommunity.org
> >> >> Subject: [datatype-dev] WMA seek
problem
> >> >> 
> >> >> Hi
> >> >> 
> >> >> I have a WMA seek problem related to
the on-the-fly seek
> >> >table. If you
> >> >> have a long WMA clip (>10min),
start to seek forward just 
> >after it 
> >> >> starts to play. Seek to close the end
of the clip, stop
> >> seek forward
> >> >> and start to seek backward a little
bit. After that the
> >> behavior is
> >> >> unpredictable.
> >> >> Sometimes it starts to play after a
long delay, 
> sometimes it just 
> >> >> hangs.
> >> >> 
> >> >> The problem here is the way ASF index
fill in the seek table. 
> >> >> After the first seek, we jump a lot
in the seek table then
> >> >it tries to
> >> >> fill in the table using the last
valid entry.
> >> >> However these entries could be off a
lot. After the 2nd
> >> seek one of
> >> >> these filled in entry is read as the
seek position and the
> >> >file offset
> >> >> is from it. Since this value could be
off a lot to the 
> >actual seek 
> >> >> position it can cause very long
buffering time and sometimes
> >> >hang the
> >> >> player.
> >> >> 
> >> >> If I disable this fill in at
CHXASFIndex::SetIndexEntry(),
> >> >it will fix
> >> >> the problem I mentioned above. But
this is in the common
> >> code and it
> >> >> must be some reason to have it
there.
> >> >> 
> >> >> Another thing is what is the
WallclockDelay used for in
> >> >BufferManager? 
> >> >> I noticed in this case the
WallclockDelay is getting 
> larger than 
> >> >> normal ( this is because the way it
get calculated).
> >> >> 
> >> >> If you need a clip to reproduce the
problem I can send it
> >> >separately. 
> >> >> 
> >> >> Thanks,
> >> >> Gang
> >> >> 
> >> >> 
> >> >
> >> >
> >> 
> >
> >
> 


_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev

Actually it is not that "bad" to fail the
on-the-fly table in this case.
Since it is an audio only clip it will be easy to find the
seek position
in the file based on the calculation. And I guess maybe the
reason for
missing index object is because it is an audio only clip.
So I think it is good to try to fail the on-the-fly index if
it is off
too much. Even I doubt why we need to fill it with the most
recent valid
entry.

Thanks
Gang 

>-----Original Message-----
>From: ext Eric Hyche [mailto:ehychereal.com]

>Sent: Wednesday, January 02, 2008 12:17 PM
>To: Jia Gang (Nokia-TP-MSW/Dallas); datatype-devhelixcommunity.org
>Subject: RE: [datatype-dev] WMA seek problem
>
>
>Ok, well in that case, the fix I mentioned earlier won't
make 
>any difference. If the on-the-fly table fails out (as my
fix 
>suggested) and there isn't any ASF index table, then the
ASF 
>fileformat has no other choice but to scan from the
beginning, 
>which is even worse than scanning from the point that
the 
>on-the-fly table suggested.
>
>So I think for ASF files with no ASF index, we're simply
doing 
>the best we can. If there is no ASF index, then the file

>hasn't been created with random access in mind.
>
>Eric
>
>=============================================
>Eric Hyche (ehychereal.com)
>Technical Lead
>RealNetworks, Inc.  
>
>> -----Original Message-----
>> From: Gang.Jianokia.com [mailto:Gang.Jianokia.com]
>> Sent: Wednesday, January 02, 2008 1:09 PM
>> To: ehychereal.com; datatype-devhelixcommunity.org
>> Subject: RE: [datatype-dev] WMA seek problem
>> 
>> In this case the file just doesn't have an index
table. Otherwise it 
>> will be all fine after the first seek - the index
object will be 
>> copied to the on-the-fly table.
>> 
>> Thanks,
>> Gang
>> 
>> >-----Original Message-----
>> >From: ext Eric Hyche [mailto:ehychereal.com]
>> >Sent: Wednesday, January 02, 2008 11:59 AM
>> >To: Jia Gang (Nokia-TP-MSW/Dallas);
datatype-devhelixcommunity.org
>> >Subject: RE: [datatype-dev] WMA seek problem
>> >
>> >
>> >Gang,
>> >
>> >In thinking through this some more, I'm
thinking the fileformat 
>> >should have behaved like this when seeked to
the end of the file:
>> >
>> >1) Try the on-the-fly table and it should fail
>> >   (since it only has the first few keyframe
entries)
>> >2) Try to read the ASF index table entries at
>> >   the end of the file.
>> >
>> >When it is reading the ASF index table entries,
it *should* be 
>> >simultaneously adding all of the ASF index
table entries into the 
>> >on-the-fly seek table, so that the next time
on-the-fly table is 
>> >consulted, it should be complete. Are the ASF
index table 
>entries not 
>> >being added to the on-the-fly table, or does
this 
>particular content 
>> >file simply not
>> >*have* an ASF index table?
>> >
>> >Eric
>> >
>> >=============================================
>> >Eric Hyche (ehychereal.com)
>> >Technical Lead
>> >RealNetworks, Inc.  
>> >
>> >> -----Original Message-----
>> >> From: Gang.Jianokia.com
[mailto:Gang.Jianokia.com]
>> >> Sent: Wednesday, January 02, 2008 12:48
PM
>> >> To: ehychereal.com; datatype-devhelixcommunity.org
>> >> Subject: RE: [datatype-dev] WMA seek
problem
>> >> 
>> >> Thanks Eric. I will try this approach.
>> >> 
>> >> Gang
>> >> 
>> >> >-----Original Message-----
>> >> >From: ext Eric Hyche
[mailto:ehychereal.com]
>> >> >Sent: Wednesday, January 02, 2008
10:32 AM
>> >> >To: Jia Gang (Nokia-TP-MSW/Dallas);
>> datatype-devhelixcommunity.org
>> >> >Subject: RE: [datatype-dev] WMA seek
problem
>> >> >
>> >> >
>> >> >The problem you describe seems to be a
limitation of the
>> on-the-fly
>> >> >seek table. It doesn't really have the
notion of how "good" 
>> >its seek
>> >> >offset estimate is - it just knows
whether it has one or not.
>> >> >
>> >> >The short-term fix might be to look at
the logic in the
>> seek table
>> >> >and if the time gap between the chosen
offset and the next
>> >one is too
>> >> >great, then return failure. This will
cause the ASF 
>fileformat to 
>> >> >fall back to using the ASF file's
index tables.
>> >> >
>> >> >Let me describe this in more detail.
Suppose we have a WMV
>> >that's 10
>> >> >minutes long with keyframes every 10
seconds. At the 
>beginning of 
>> >> >playback, then the first few entries
are made in the on-the-fly
>> >> >table:
>> >> >
>> >> >Time(ms)     Offset(bytes)
>> >> >----------------------------------
>> >> >0            xxxx
>> >> >10000        yyyy
>> >> >20000        zzzz
>> >> >
>> >> >and then after you seek to close to
the end of the file,
>> >entries get
>> >> >made close to the end:
>> >> >
>> >> >Time(sec)   Offset(bytes)
>> >> >----------------------------------
>> >> >0            xxxx
>> >> >10           yyyy
>> >> >20           zzzz
>> >> >580          aaaa
>> >> >590          bbbb
>> >> >
>> >> >and then if you seek to 572 seconds,
then the on-the-fly
>> seek table
>> >> >will choose 20 seconds and zzzz as the
time and offset.
>> >> >Clearly this is the correct but
inefficient choice, 
>since the ASF 
>> >> >fileformat will scan from zzzz all the
way until it finds
>> the real
>> >> >last keyframe before 572 seconds,
which would be at 570 seconds.
>> >> >
>> >> >I think one fix for this would be to
set some sort of maximum 
>> >> >keyframe delta, and then if the
difference between the
>> >returned time
>> >> >(20s) and the next time entry in the
table
>> >> >(580s) is too great, then return
failure.
>> >> >
>> >> >Ideally this maximum delta should be
chosen by analyzing
>> the deltas
>> >> >in the current table. The deltas in
the table above would be 
>> >> >10,10,560,10. Practically, you could
just set a reasonably high 
>> >> >maximum keyframe delta, such as
perhaps 60s or so.
>> >> >
>> >> >Eric
>> >> >
>> >>
>=============================================
>> >> >Eric Hyche (ehychereal.com)
>> >> >Technical Lead
>> >> >RealNetworks, Inc.  
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: datatype-dev-bounceshelixcommunity.org
>> >> >> [mailto:datatype-dev-bounceshelixcommunity.org] On Behalf Of 
>> >> >> Gang.Jianokia.com
>> >> >> Sent: Wednesday, December 19,
2007 5:02 PM
>> >> >> To: datatype-devhelixcommunity.org
>> >> >> Subject: [datatype-dev] WMA seek
problem
>> >> >> 
>> >> >> Hi
>> >> >> 
>> >> >> I have a WMA seek problem related
to the on-the-fly seek
>> >> >table. If you
>> >> >> have a long WMA clip (>10min),
start to seek forward just
>> >after it
>> >> >> starts to play. Seek to close the
end of the clip, stop
>> >> seek forward
>> >> >> and start to seek backward a
little bit. After that the
>> >> behavior is
>> >> >> unpredictable.
>> >> >> Sometimes it starts to play after
a long delay,
>> sometimes it just
>> >> >> hangs.
>> >> >> 
>> >> >> The problem here is the way ASF
index fill in the seek table. 
>> >> >> After the first seek, we jump a
lot in the seek table then
>> >> >it tries to
>> >> >> fill in the table using the last
valid entry.
>> >> >> However these entries could be
off a lot. After the 2nd
>> >> seek one of
>> >> >> these filled in entry is read as
the seek position and the
>> >> >file offset
>> >> >> is from it. Since this value
could be off a lot to the
>> >actual seek
>> >> >> position it can cause very long
buffering time and sometimes
>> >> >hang the
>> >> >> player.
>> >> >> 
>> >> >> If I disable this fill in at
CHXASFIndex::SetIndexEntry(),
>> >> >it will fix
>> >> >> the problem I mentioned above.
But this is in the common
>> >> code and it
>> >> >> must be some reason to have it
there.
>> >> >> 
>> >> >> Another thing is what is the
WallclockDelay used for in
>> >> >BufferManager? 
>> >> >> I noticed in this case the
WallclockDelay is getting
>> larger than
>> >> >> normal ( this is because the way
it get calculated).
>> >> >> 
>> >> >> If you need a clip to reproduce
the problem I can send it
>> >> >separately. 
>> >> >> 
>> >> >> Thanks,
>> >> >> Gang
>> >> >> 
>> >> >> 
>> >> >
>> >> >
>> >> 
>> >
>> >
>> 
>
>

_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev