This allows setting/overriding e.g. the bitrate parameter, which
is required for the smoothstreaming muxer. Normally, the bitrate
is set by the demuxer in these cases, but not all demuxers can
provide it. This allows stream copy of data to the smoothstreaming
muxer from such inputs.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some systems require sys/time.h being explicitly included before
sys/resource.h. The configure check already does this.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Error out on init if a codec with CODEC_CAP_EXPERIMENTAL is requested
and strict_std_compliance is not FF_COMPLIANCE_EXPERIMENTAL.
Move the check from avconv to avcodec_open2() and return
AVERROR_EXPERIMENTAL accordingly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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.
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.
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.
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
Because of a mistake during merging the code for simple and complex
filtergraphs, -async inserts an asyncts filter both on input and output.
Remove the output hunk.
When there are multiple input files, run demuxing for each input file in
a separate thread, so reading packets does not block.
This is useful for achieving low latency when reading from multiple
(possibly slow) input streams.
Invented timestamps for the h264 tests return to something resembling
sanity.
In the idroq-video-encode test when converting 25 fps -> 30 fps the
fifth frame gets duplicated instead of the sixth.
It's the same as av_vsrc_buffer_add_frame(), except it doesn't take pts
or pixel_aspect parameters. Those are read from AVFrame.
Deprecate av_vsrc_buffer_add_frame().
Converting the double to float for lrintf() loses precision when
the value is not exactly representable as a single-precision float.
Apart from being inaccurate, this causes discrepancies in some
configurations due to differences in rounding.
Note that the changed timestamp in the vc1-ism test is a bogus,
made-up value.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This allows masking CPU features with the -cpuflags avconv option
which is useful for testing different optimisations without rebuilding.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The decoder can change the layout and channel count during decoding,
but currently we only validate that the two are compatible when opening
the codec. This checks for incompatibilities after each decoded frame.
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.
This is required for letting applications to create and destroy
AVFilterInOut structs in a convenient way.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If either input or output layout is known and the channel counts match,
use the known layout for both. Otherwise choose the default layout based on
av_get_default_channel_layout().
Changed some FATE references due to some WAVE files now having a non-zero
channel mask.
This will allow a workaround for cases where input timestamps are invalid or
when decoder delay of 1 packet or more confuses avconv into using the wrong
timestamps as a sync reference.
Since the mandatory memcpy in vsrc_buffer has been eliminated, there
shouldn't be any significant reason to build without lavfi anymore.
This will make upcoming support for complex filtergraphs easier to do.
r_frame_rate should in theory have something to do with input framerate,
but in practice it is often made up from thin air by lavf. So unless we
are targeting a constant output framerate, it's better to just use input
stream timebase.
Brings back dropped frames in nuv and cscd tests introduced in
cd1ad18a65
Update FATE reference to account for now non-existent palette packet.
This also fixes the FATE test if frame data is not initialized in
get_buffer(), so update comment in avconv accordingly.
This is required when stream copying VC1 in ismv - there's one
global header in the moov atom, but keyframes have a separate
sequence header prepended.
Signed-off-by: Martin Storsjö <martin@martin.st>
Set output files duration to recording_time option, if given.
Rationale: to save duration into metadata for file that is written to
non-seekable output, for formats like FLV (with metadata at beginning).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
next_dts is used for estimating the dts of the next packet if it's
missing. Therefore, it makes no sense to set it from the pts of the last
decoded frame. Also it should be estimated from the current packet
duration/ticks_per_frame always, not only when a frame was successfully
decoded.
It currently has different meanings at different times (dts of the last
read packet/pts of the last decoded frame). Reduce obfuscation by
storing pts of the decoded frame in the frame itself.
Current code compares the desired recording time with InputStream.pts,
which has a very unclear meaning. Change the code to use actual
timestamps of the frames passed to the encoder.
In several tests, one less frame is encoded, which is more correct.
In the idroq test one more frame is encoded, which is again more
correct.
Behavior with stream copy should be unchanged.
The actual number (1/1000) will probably require some
discussion/tweaking in the future, but should be good enough for now,
since the timestamps in AVSubtitle are in this timebase by definition.
