hdlr and new tagging API

[Jeremy Noring]

If you create a file with 1.9.1 and use any of the new tagging APIs
(e.g. MP4TagsAlloc, MP4TagsSet..., etc.), that file cannot be read
back by 1.9.1 or any subsequent release of the library. The reason is
it inserts a malformed hdlr atom (there is no handlerType specified,
so the atom ends up being 4 bytes too short). Then, durning MP4Read
(), the library either tosses an exception (1.9.1, which parses off
EOF) or crashes outright (355, which subtracts 24 from 21 and attempts
to malloc ~4 GB of memory). Other players, such as WMP and QT are
happy ignoring the hdlr block and still seem to playback the file; the
real issue is mp4v2 cannot read files that were legitimately created
by 1.9.1.

I don't believe 355 creates the malformed hdlr atom (I still need to
verify), but I think it is very important for the project to update to
a more recent version that does not create this malformed hdlr atom
and stop distributing 1.9.0/1.9.1.

[Jeremy Noring]

Sorry, let me summarize what I'm proposing: can we have an "official"
release some time soon (i.e. 1.9.2, 2.0, whatever you decide to name
it, etc.)?

[Jeremy Noring]

On Dec 8, 9:14 am, Jeremy Noring <kid...@gmail.com> wrote:

> I don't believe 355 creates the malformed hdlr atom (I still need to
> verify), but I think it is very important for the project to update to
> a more recent version that does not create this malformed hdlr atom
> and stop distributing 1.9.0/1.9.1.

I updated our project to r355. The files created by r355 don't have
this issue. I'd still like to have an "official" update, and it'd
still be a very good idea to no longer distribute 1.9.1.