New submission from yoav y...@monfort.co.il:
ff_id3v1_read seeks to the end of the file in order to read the id3v1 tag. Once
done reading it seeks back to offset 0. This is a bug since in many cases we
were at a different offset (for example after reading an id3v2 header) before
calling
New submission from yoav y...@monfort.co.il:
This might be the case in many other parts of ffmpeg. But I'm specifically
suffering from getting -1 when calling av_open_input_file() (which in turn calls
the read_header() functions of the detected format). I'm interesting in knowing
if the open
yoav y...@monfort.co.il added the comment:
The fix in r23040 is incomplete:
1) The parsing of ff_asf_stream_header chunk already has the logic for skipping
unused data at the end of the chunk. So if there's generic code for that now
then the old code at the end of the ff_asf_stream_header
New submission from yoav y...@monfort.co.il:
When parsing ASF headers each header object contains an ID, Size, and object
fields. The ASF header parser asf_read_header in asfdec.c for most ID's ignores
the object size (gsize) and simply assumes that reading the fields of the object
will move
yoav y...@monfort.co.il added the comment:
Running over my sample data again I couldn't find any problematic files.
When I originally fixed issue1234 for myself I also added the the provided logic
(reading id3v2.3 extended header size as a non syncsafe length) so I though it
should probably
yoav y...@monfort.co.il added the comment:
The last fix in r19291 seems incomplete. It doesn't handle the id3v2.3 extended
headers length correctly and assumes they use a syncsafe length which is wrong
(only id3v2.4 use it).
Here's my patch
