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.
