From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 86C074CD2D for <ffmpegdev@gitmailbox.com>; Mon, 14 Apr 2025 04:23:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 88E1B687CEF; Mon, 14 Apr 2025 07:23:54 +0300 (EEST) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 763F1680141 for <ffmpeg-devel@ffmpeg.org>; Mon, 14 Apr 2025 07:23:47 +0300 (EEST) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4ZbZ0x0SjGz9tsN for <ffmpeg-devel@ffmpeg.org>; Mon, 14 Apr 2025 06:23:45 +0200 (CEST) Message-ID: <60e25c6d-22ac-45d1-8946-0178f5f84071@gyani.pro> Date: Mon, 14 Apr 2025 09:53:42 +0530 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: <20250413111545.4619-1-ffmpeg@gyani.pro> <DM8P223MB03651EDCA0D837A06C6B7C62BAB02@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> Content-Language: en-US From: Gyan Doshi <ffmpeg@gyani.pro> In-Reply-To: <DM8P223MB03651EDCA0D837A06C6B7C62BAB02@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> X-Rspamd-Queue-Id: 4ZbZ0x0SjGz9tsN X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/60e25c6d-22ac-45d1-8946-0178f5f84071@gyani.pro/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> On 2025-04-13 09:39 pm, softworkz . wrote: > >> -----Original Message----- >> From: ffmpeg-devel<ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Gyan >> Doshi >> Sent: Sonntag, 13. April 2025 13:16 >> To:ffmpeg-devel@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 The first is not a method. It indicates whether the input is streamed. > 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 Will do. > 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 At the moment, there are 21 unused bits so there's no need as such. > >> +#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? Only a handful of demuxers have this flag, and all have TS. This is a job for reviewers when adding the flag. > >> + // 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? As alluded above, there's only a handful of attributes being indicated. I'd rather not spawn a new type when an inbuilt simple storage type will do. Regards, Gyan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".