Do not pointlessly call ff_alloc_packet multiple times,
and fix an infinite loop by clamping the maximum
number of bits to target in the algorithm that does
not use lambda.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Save the old output configuration (if it has been used
successfully) when trying a new configuration. If the new configuration
fails to decode, restore the last successful configuration.
This option is the stream identifier to play or to publish.
Sometimes the URL parser cannot determine the correct
playpath automatically, so it must be given explicitly
using this option (ie. -rtmp_playpath).
Signed-off-by: Martin Storsjö <martin@martin.st>
This option is the name of application to connect on the RTMP server.
Sometimes the URL parser cannot determine the app name automatically,
so it must be given explicitly using this option (ie. -rtmp_app).
Signed-off-by: Martin Storsjö <martin@martin.st>
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.