The string might or might not be set depending if there
are args and in case of error it must be freed nonetheless.
CC: libav-stable@libav.org
Bug-Id: CID 739878 / CID 739882
This atom typically is used for a track title. The handler name is stored
as a Pascal string in the QT specs (first byte is the length of the string),
so do not export it.
A second length check based on the first character is added to avoid
overwriting an already specified handler_name (it happens with YouTube
videos for instance, the handler_name get masked), or specifying an
empty string metadata.
The Pascal string fix and the second length check are written
by Clément Bœsch <clement.boesch@smartjog.com>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes builds with vc1_parser enabled without vc1_decoder. All
the vc1_decoder object files were included in the vc1_parser line
in libavcodec/Makefile before, but architecture specific object files
for vc1_decoder were not.
Signed-off-by: Martin Storsjö <martin@martin.st>
This uses explicit memory copying to read and write pointer to pointers
of arbitrary object types. This works provided that the architecture
uses the same representation for all pointer types (the previous code
made that assumption already anyway).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Trigger a refill if the seek action moves the pointer
at the end of the buffer.
Before this patch the read action following the seek would trigger
the refill, while write action would write outside the buffer.
In the Libav codebase few muxers seek forward outside of what
already has been written so it is quite unlikely to experience
the problem with the default buffer size.
CC: libav-stable@libav.org
It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.
Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.
Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.
