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>

Without these, the expansion contains things like --1 with
some compilers resulting in build errors.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Fixes crashes when using biweight on win64.

Prevents it from referring to the rest of the list.

Prevents extensive buffering when overlaying a single picture.

This is the first step towards supporting complex filtergraphs with more
than one input and/or output.

It more properly belongs to output, not input.

Always take it from lavfi. This way we don't need a clearly defined
corresponding input stream.

This is a more proper place for them, since they store parameters of the
input, not output, stream.

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.

They are globals, no point in pretending they are not.

Switch from changing global values to defining a separate C style
and add appropriate settings for indenting assignments that span
more than one line.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Call mov_read_close when mov_read_header fails.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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>

If coefficient A is 12-bits xixed-point number "X", then the other
coefficient is (1 << 12) - X, not (1 << 12) - X - 1.

The user submitted variable in this function is frame, not buf.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

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 probably a leftover from WMA Pro.

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.

Fixes bug 270.

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>

Signed-off-by: Martin Storsjö <martin@martin.st>

Stss atom without entries doesn't mean every sample is a sync sample.

Signed-off-by: Martin Storsjö <martin@martin.st>

Some container formats report a global duration, but not a per stream
one.

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.

Also adjust some comments including wording and typo fixes.