[FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Gyan
> Doshi
> Sent: Sonntag, 13. April 2025 13:16
> To: ffmpeg-devel at ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/2] avformat: add
> avformat_query_seekable
> 
> Utility function to report seekability features for a given input.
> 
> Useful for ffprobe and to extend seek possibilities in fftools.
> ---
>  doc/APIchanges         |  3 +++
>  libavformat/avformat.h | 22 ++++++++++++++++++
>  libavformat/seek.c     | 53 ++++++++++++++++++++++++++++++++++++++++++
>  libavformat/version.h  |  2 +-
>  4 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 65bf5a9419..879f56b572 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on
> 2025-03-28
> 
>  API changes, most recent first:
> 
> +2025-04-xx - xxxxxxxxxx - lavf 62.1.100 - avformat.h
> +  Add avformat_query_seekable().
> +
>  2025-04-07 - 19e9a203b7 - lavu 60.01.100 - dict.h
>    Add AV_DICT_DEDUP.
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 498c3020a5..e00f1ed0d9 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -2338,6 +2338,28 @@ int av_seek_frame(AVFormatContext *s, int
> stream_index, int64_t timestamp,
>   */
>  int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t
> min_ts, int64_t ts, int64_t max_ts, int flags);

Hi Gyan,

I like the idea of showing seekability in FFprobe output!

As far as I understand, these flags are expressing three different things:


1. Seek method

> +#define AVSEEKABLE_NORMAL     0x01 ///< I/O is seekable like a local
> file
> +#define AVSEEKABLE_PROTOCOL   0x02 ///< I/O seek is through protocol
> request via avio_seek_time
> +#define AVSEEKABLE_DEMUXER    0x04 ///< demuxer has a seek function
> +#define AVSEEKABLE_PKTSCAN    0x08 ///< seek is performed by consuming

2. Seek parameter type

> and scanning packet timestamps
> +#define AVSEEKABLE_TIME       0x10 ///< seek target can be a timestamp
> +#define AVSEEKABLE_BYTE       0x20 ///< seek target can be in bytes
> +#define AVSEEKABLE_FRAME      0x40 ///< seek target can be a frame
> index

3. Additional seek behavior

> +#define AVSEEKABLE_PTS       0x100 ///< seek target timestamp is
> expected to be PTS
> +#define AVSEEKABLE_FAST      0x200 ///< demuxer allows fast but
> inaccurate seeking
> +#define AVSEEKABLE_FWDONLY   0x400 ///< set seek will be equal or
> forward of specified seek point


Wouldn't it be better for clarity when this differentiation would be 
reflected in the naming?

Maybe something like this:

AVSEEKABLE_VIA_DEMUXER

AVSEEKABLE_BY_TIME

AVSEEKABLE_BEHAVIOR_FAST


Another note:

> +#define AVSEEKABLE_NORMAL     0x01 ///< I/O is seekable like a local
> +#define AVSEEKABLE_PROTOCOL   0x02 ///< I/O seek is through protocol
> +#define AVSEEKABLE_DEMUXER    0x04 ///< demuxer has a seek function
> +#define AVSEEKABLE_PKTSCAN    0x08 ///< seek is performed by consuming

There's no (numeric) room for extending the first block

> +#define AVSEEKABLE_TIME       0x10 ///< seek target can be a timestamp
> +#define AVSEEKABLE_BYTE       0x20 ///< seek target can be in bytes
> +#define AVSEEKABLE_FRAME      0x40 ///< seek target can be a frame


> +    // TODO: no flag for frame seeking. Add flag and update this check
> +    if (s->iformat->flags & 0)
> +        ret |= AVSEEKABLE_FRAME;
> +
> +    if (s->iformat->flags & AVFMT_SEEK_TO_PTS)
> +        ret |= AVSEEKABLE_PTS;

Maybe add a check for AVSEEKABLE_TIME - for sanity?

> +    // TODO: flag exists but not added to the demuxers which support it
> +    if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
> +        ret |= AVSEEKABLE_FAST;



Another idea would be to return a struct (like AVSeekability) with a clear
separation of those three types of information, maybe that would provide
better clarity?


Best,
sw