[FFmpeg-devel] [PATCHv2 5/5] lavfi/select: add support for concatdec_select option

Marton Balint cus at passwd.hu
Wed Nov 25 01:08:39 CET 2015


On Fri, 20 Nov 2015, Stefano Sabatini wrote:

> On date Friday 2015-11-20 13:54:26 +0100, Marton Balint encoded:
>> This option can be used to select useful frames from an ffconcat file which is
>> using inpoints and outpoints but where the source files are not intra frame
>> only.
>> 
>> Signed-off-by: Marton Balint <cus at passwd.hu>
>> ---
>>  doc/filters.texi       | 20 ++++++++++++++++++++
>>  libavfilter/f_select.c | 27 +++++++++++++++++++++++++++
>>  2 files changed, 47 insertions(+)
>> 
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 471ec3f..c886976 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -13196,6 +13196,19 @@ value between 0 and 1 to indicate a new scene; a low value reflects a low
>>  probability for the current frame to introduce a new scene, while a higher
>>  value means the current frame is more likely to be one (see the example below)
>> 
>> + at item concatdec_select
>> +The concat demuxer can set the @var{lavf.concat.start_time} and the
>> + at var{lavf.concat.duration} packet metadata values which are also present in the
>> +decoded frames.
>
> Maybe here you could elaborate. Something like:
>
> The concat demuxer can select only part of a concat input file by
> setting an inpoint and an outpoint, but the output packets may not be
> entirely contained in the selected interval. By using this variable,
> it is possible to skip frames generated by the concat demuxer which
> are not exactly contained in the selected interval.
>
>> +
>> +The @var{concatdec_select} variable is -1 if the frame pts is at least
>> +start_time and either the duration metadata is missing or the frame pts is less
>> +than start_time + duration, 0 otherwise, and NaN if the start_time metadata is
>> +missing.
>> +
>> +That basically means that an input frame is selected if its pts is within the
>> +interval set by the concat demuxer.
> [...]
>
> Looks good otherwise.

Thanks, applied with the proposed changes.

Regards,
Marton


More information about the ffmpeg-devel mailing list