GitLab

It has not worked for anything other than fringe codecs (asv1/2, mdec,
mjpeg[b]) since about 2003 and nobody ever noticed or complained. This
sufficiently proves that there are no users of this option who have a
clue of what they are doing, so it is completely useless.

This takes into account planar vs. packed when comparing to find the closest
sample format match.

This prevents lost frames after a resolution change.

func2_arg is the same as func_arg, except it has one additional
parameter. Change all func_arg callbacks to take that parameter (and
ignore it).

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

It is now possible to use lavfi sources.

The new name is shorter and more accurate, since this variable is no
longer used only for checking recording time constraint.

Operate with a pointer to InputFile instead of its index in input_files.

Replace for (;foo == 0;) with while (!foo)
This is prettier.

This simplifies splitting code for reading from input out of
transcode().

Before this commit, poll_filters() reads all frames available on each
lavfi output. This does not work for lavfi sources that produce
an unlimited number of frames, e.g. color and similar.

With this commit, poll_filters() reads from output with the lowest
timestamp and returns to wait for more input if no frames are available
on it.

This allows simplifying a few expressions.
Signed-off-by: Mans Rullgard <mans@mansr.com>

According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.

Replace it with the average framerate where it makes sense.

FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.

In some other tests lavf starts making up frame durations from different
frame.

Also exit in such a case if -xerror is used.

Fixes bug 329.

start time is already substracted from the frame timestamp, so it needs
to be checked against 0, not start time.

Currently it always exits with an error when more than
one position is specified.

CC: libav-stable@libav.org

If the output frame size is smaller than the input sample rate,
and the input stream time base corresponds exactly to the input
frame size (getting input packet timestamps like 0, 1, 2, 3, 4 etc),
the output timestamps from the filter will be like
0, 1, 2, 3, 4, 4, 5 ..., leadning to non-monotone timestamps later.

A concrete example is input mp3 data having frame sizes of 1152
samples, transcoded to aac with 1024 sample frames.

By setting the audio filter time base to the sample rate, we will
get sensible timestamps for all output packets, regardless of
the ratio between the input and output frame sizes.
Signed-off-by: Martin Storsjö <martin@martin.st>

This allows passing the right options to encoders when there's more
than one encoder for a certain codec id.
Signed-off-by: Martin Storsjö <martin@martin.st>

The warning silenced was:
avconv.c: In function ‘opt_output_file’:
avconv.c:3380:21: warning: ‘meta_out’ may be used uninitialized in this function [-Wuninitialized]
avconv.c:3315:20: note: ‘meta_out’ was declared here

The warning silenced was:
avconv.c: In function ‘configure_filtergraph’:
avconv.c:603:8: warning: ‘ist’ may be used uninitialized in this function [-Wuninitialized]
avconv.c:549:18: note: ‘ist’ was declared here

parse_forced_keyframes() relies in encoder timebase being set, so call
it from transcode_init() after it is known.