Frame limiting is now handled using sync queues. This code prevents the
sync queue from triggering EOF, resulting in unnecessarily many frames
being decoded, filtered, and then discarded.
Found-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Specificaly, the of_add_attachments() call (which can add attachment
streams to the output) and the check whether the output file contains
any streams. They both logically belong in create_streams().
Some formats like FLV can dynamically add streams during packet reading.
FFprobe does check for this and reallocates the global stream info, but does
not reallocate InputFrame's streams and decoders when this happens, which,
as a result, could have caused flushing to occur on an out of bounds stream
index, since the flush loop iterates over fmt_ctx's nb_streams, and not
ifile's, despite using ifile's streams.
This fixes an out of bounds read and segfult.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The current adjustment of input start times just adjusts the tsoffset.
And it does so, by resetting the tsoffset to nullify the new start time.
This leads to breakage of -copyts, ignoring of input_ts_offset, breaking
of -isync as well as breaking wrap correction.
Fixed by taking cognizance of these parameters, and by correcting start times
just before sync offsets are applied.
The current code will override the *_disable fields (set by -vn/-an
options) when creating output streams for unlabeled complex filtergraph
outputs, in order to disable automatic mapping for the corresponding
media type.
However, this will apply not only to automatic mappings, but to manual
ones as well, which should not happen. Avoid this by adding local
variables that are used only for automatic mappings.
Specifically recording_time and stop_time - use local variables instead.
OptionsContext should be input-only to this code. Will allow making it
const in future commits.
This is similar to what was done before for output files and will allow
introducing demuxer-private state in future commits
Unlike for muxing, the code is moved to existing ffmpeg_demux.c rather
than to a new file. The reason is just file size - the demuxing code is
much smaller than muxing.
Now that we have proper options for defining display matrix
overrides, this should no longer be required.
fftools does not have its own versioning, so for now the define is
just set to 1 and disables the functionality if set to zero.
This enables overriding the rotation as well as horizontal/vertical
flip state of a specific video stream on the input side.
Additionally, switch the singular test that was utilizing the rotation
metadata to instead override the input display rotation, thus leading
to the same result.
This is now possible since OutputStream is a child of OutputFile and the
code allocating it can access MuxStream. Avoids the overhead and extra
complexity of allocating two objects instead of one.
Similar to what was previously done for OutputFile/Muxer.
Replace it with an array of streams in each OutputFile. This is a more
accurate reflection of the actual relationship between OutputStream and
OutputFile. This is easier to handle and will allow further
simplifications in future commits.
This is now possible since the code allocating OutputFile can see
sizeof(Muxer). Avoids the overhead and extra complexity of allocating
two objects instead of one.
Similar to what is done e.g. for AVStream/FFStream in lavf.
