This is done in order to clarify the non-video-specific nature of the
buffersink code, as the result of the video/audio API unification of
the previous commit, and for improving overall consistency.
The new API is more generic (no distinction between audio/video for
pulling frames), and avoids code duplication.
A backward compatibility layer is kept for avoiding tools ABI breaks
(only for the video binary interface, audio interface was never used
in the tools).
AVFormatParameters are converted into corresponding private options in
av_open_input_file/stream() compat wrappers, so accessing them from
demuxers is redundant.
In lavfi_read_header(), use the pad index designated in the inout for
linking an output to a sink, rather than always 0. Fix link creation
for filters with more than one output (e.g. the split filter).
This fixes the two following warnings:
libavdevice/alsa-audio-dec.c:62:26: warning: unused variable ‘sw_params’ [-Wunused-variable]
libavdevice/alsa-audio-dec.c:109:15: warning: unused variable ‘st’ [-Wunused-variable]
-follow_mouse centered|PIXELS
move grabbing region to where mouse pointer at the center; or
only move when pointer reaches within PIXELS to the edge.
Signed-off-by: Yu-Jie Lin <livibetter@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
In testing, the file output plugin gave a max buffer size of about 20 million
frames, which is way more than what is really needed and causes a memory
allocation error on my system.
The PTS for captured audio was measured using snd_pcm_htimestamp.
snd_pcm_htimestamp hangs when the input is a dsnoop plugin.
Furthermore, at some point, snd_pcm_htimestamp started returning monotonic
timestamps rather than wall clock timestamps, in most but not all
situations.
Monotonic timestamps are fine, but ffmpeg uses wall clock timestamps
everywhere else, and we have no API to inform the user which kind of
timestamps it is.
A separate snd_pcm_htimestamp is only slightly less accurate than
snd_pcm_htimestamp: the standard deviation for the difference between two
consecutive timestamps is (on my hardware):
- ~13 µs with snd_pcm_htimestamp;
- ~35 µs with av_gettime;
- ~5 µs with av_gettime and a timefilter.
Show the invalid string in the error message.
While at it also prefer "Could not" over "Couldn't", plain forms are
preferred over contractions (simplify readability, especially for non
English-savvy people).
Signed-off-by: Anton Khirnov <anton@khirnov.net>