This way we don't require a clearly defined corresponding input stream.
The result for the xwd test changes because rgb24 is now chosen instead
of bgra.
Right now, they are arrays of structs, reallocated when new
streams/files are added. This makes storing pointers to those structs
harder than necessary.
Instead of allocating over the original, free first. MOVStreamContext
is zero initialized so no double free will occur. Same style as other
fixes for the same problem in this file.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
There is no point in storing the value in a variable, since it is not
used anywhere else in the decoder.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This is required for letting applications to create and destroy
AVFilterInOut structs in a convenient way.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Right now, e.g. scale,[in]overlay would connect scale to the first
overlay input and [in] to the second, which goes against the
documentation and is unintuitive.
The bug happens because of the ordering mess in curr_inputs variable:
1) the unlabeled links from the previous filter are added to it in
correct order
2) input labels are parsed and inserted to the beginning one by one
(i.e. in reverse order)
3) curr_inputs is matched against filter inputs in reverse order
Fix the problem by always using proper ordering without trying to be
clever.
Unlike avfilter_graph_parse(), it returns unlinked inputs and outputs
to the caller, which allows parsing of graphs where inputs/outputs are
not known in advance.
This reworks a loop to get rid of an ugly pointer cast,
fixing errors seen with the PathScale ENZO compiler.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Recent register allocation changes (x86inc.asm update) changed the
register order and thus opcodes for the inner loops. One of them became
>128bytes, which confuses other parts of this function where it jumps
to fixed-offset positions to extend the edge by fixed amounts. A simple
register change fixes this.
The fields in config.fate are colon-separated so any colons
within the fields should be escaped to prevent confusion.
Signed-off-by: Mans Rullgard <mans@mansr.com>
During error conditions matroska_parse_block may exit without
freeing the memory allocated for laces.
Found via valgrind: http://pastebin.com/E54k8QFU
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
