> why do that? I can understand to seek back to the old position if the
> index parsing gave errors, but in case of success why read the
> same data again?
Almost all comments processed new patch attached.
Following not process:
>> Index: libavformat/flvdec.c
>> ===================================================================
>> --- libavformat/flvdec.c ? ? ? ?(revision 26402)
>> +++ libavformat/flvdec.c ? ? ? ?(working copy)
>> +
>> + ? ? ? ?for (i = 0; i< ?arraylen&& ?url_ftell(ioc)< ?max_pos - 1; i++) {
>> nit: please give operators room the breathe and drop the double spaces
Actually my English is not good, so I do not understand what do you
mean, I did not find any two sequential spaces in this line, but
anyway I format this line to look the same as other lines in this .c
file (so this line fit at least to this file "codestyle" now).
>>> + ? ? ? ? ? ?amf_type = get_byte(ioc);
>> + ? ? ? ? ? ?if (amf_type != AMF_DATA_TYPE_NUMBER)
>> + ? ? ? ? ? ? ? ?return;
>> + ? ? ? ? ? ?num_val = av_int2dbl(get_be64(ioc));
>> + ? ? ? ? ? ?(*current_array)[i] = num_val;
>> + ? ? ? ?}
>> + ? ?}
>> + ? ?if (timeslen != fileposlen)
>> + ? ? ? ?// times->filepositions arrays have different size, will not use
>> such metadata for indexing
>> obvious, no?
Not obvious 'keyframes' metatag is not part of standart it is just
convention to use such kind of metatag information for indexing, but
nobody can prevent end user to create FLV file with keyframes metadata
with it's own structure, for own purposed, in that case I try just
ignore such data not coredump trying to access data which does not
present. I want prevent crushed on expected structure. I compare two
sizes because they packet in two different arrays in metadata,
that is why they can have different sizes in case of bug in tool which
insert metatags for example.
JFYI strructure is following, it allows to have it inconsistent:
keyframes:
times (array):
time0 (num)
time1 (num)
time2 (num)
filepositions (array)
position0 (num)
position1 (num)
>-------------- next part --------------
A non-text attachment was scrubbed...
Name: flvdec.c.diff
Type: text/x-patch
Size: 3680 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110128/15a174cc/attachment.bin>