Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable
> On Apr 13, 2025, at 19:15, Gyan Doshi wrote:
>
> 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 - xx - 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);
>
> +#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_DEMUXER0x04 ///< demuxer has a seek function
> +#define AVSEEKABLE_PKTSCAN0x08 ///< seek is performed by consuming 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
> +#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
> +
> +/**
> + * Report if and how a seek can be performed in a given input.
> + *
> + * @param smedia file handle
> + *
> + * @return 0 if no seek can be performed on input,
> + * -1 if the fmt ctx is NULL or is not an input
> + * else return AVSEEKABLE_ bitflags indicating seekability features.
> + */
> +int avformat_query_seekable(AVFormatContext *s);
> +
> /**
> * Discard all internally buffered data. This can be useful when dealing with
> * discontinuities in the byte stream. Generally works only with formats that
> diff --git a/libavformat/seek.c b/libavformat/seek.c
> index c0d94371e6..776a09744a 100644
> --- a/libavformat/seek.c
> +++ b/libavformat/seek.c
> @@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int
> stream_index, int64_t min_ts,
> return ret;
> }
>
> +int avformat_query_seekable(AVFormatContext *s)
> +{
> +int ret = 0;
> +
> +if (!s || !s->iformat)
> +return -1;
> +
> +if (!(s->pb && s->pb->seekable) || s->ctx_flags & AVFMTCTX_UNSEEKABLE)
> +return 0;
I think RTSP doesn’t follow this rule, it’s seekable.
> +
> +if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
> +ret |= AVSEEKABLE_NORMAL;
> +
> +if (s->pb->seekable & AVIO_SEEKABLE_TIME)
> +ret |= AVSEEKABLE_PROTOCOL;
> +
> +if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
> +ret |= AVSEEKABLE_DEMUXER;
> +
> +if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags &
> AVFMT_NOBINSEARCH))
> +ret |= AVSEEKABLE_PKTSCAN;
> +
> +if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
> +ret |= AVSEEKABLE_TIME;
> +
> +// TODO: incomplete, a few demuxers don't set flag but error out on byte
> seek
> +if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
> +ret |= AVSEEKABLE_BYTE;
> +
> +// 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;
> +
> +// TODO: flag exists but not added to the demuxers which support it
> +if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
> +ret |= AVSEEKABLE_FAST;
> +
> +if (!(ret & AVSEEKABLE_DEMUXER) && ret & AVSEEKABLE_PKTSCAN)
> +ret |= AVSEEKABLE_FWDONLY;
> +
> +if ( !(ret & AVSEEKABLE_DEMUXER) &&
> + !(ret & AVSEEKABLE_PKTSCAN) &&
> + !(ret & AVSEEKABLE_BYTE) &&
> + !(ret & AVSEEKABLE_PROTOCOL) &&
> + (s->iformat->flags & AVFMT_NOGENSEARCH) )
> +ret = 0;
> +
> +return ret;
> +}
> +
> /** Flush the frame reader. */
> void ff_read_frame_flush(AVFormatContext *s)
> {
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 752aac16f7..a7c80dc564 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@
Re: [FFmpeg-devel] [PATCH v2] w32pthreads: add support for setting thread name
On Mon, 31 Mar 2025 at 02:50, softworkz .
wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Jan
> > Ekström
> > Sent: Montag, 31. März 2025 00:05
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v2] w32pthreads: add support for
> > setting thread name
> >
> > On Tue, Mar 4, 2025 at 5:14 PM Kacper Michajłow
> > wrote:
> > >
> > > Signed-off-by: Kacper Michajłow
> > > ---
> > > compat/w32pthreads.h | 30 ++
> > > libavutil/thread.h | 2 ++
> > > 2 files changed, 32 insertions(+)
> > >
> > > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > > index fd6428e29f..8d5b4729fa 100644
> > > --- a/compat/w32pthreads.h
> > > +++ b/compat/w32pthreads.h
> > > @@ -44,6 +44,7 @@
> > > #include "libavutil/internal.h"
> > > #include "libavutil/mem.h"
> > > #include "libavutil/time.h"
> > > +#include "libavutil/wchar_filename.h"
> > >
> > > typedef struct pthread_t {
> > > void *handle;
> > > @@ -209,4 +210,33 @@ static inline int pthread_setcancelstate(int
> > state, int *oldstate)
> > > return 0;
> > > }
> > >
> > > +static inline int win32_thread_setname(const char *name)
> > > +{
> > > +typedef HRESULT (WINAPI *SetThreadDescriptionFn)(HANDLE, PCWSTR);
> > > +SetThreadDescriptionFn pSetThreadDescription;
> > > +HRESULT hr;
> > > +wchar_t *wname;
> > > +
> > > +#if !HAVE_UWP
> > > +HMODULE kernel32 = GetModuleHandleW(L"kernel32.dll");
> > > +if (!kernel32)
> > > +return AVERROR(ENOSYS);
> > > +pSetThreadDescription = (SetThreadDescriptionFn)
> > > +GetProcAddress(kernel32, "SetThreadDescription");
> > > +if (!pSetThreadDescription)
> > > +return AVERROR(ENOSYS);
> > > +#else
> > > +WINBASEAPI HRESULT WINAPI
> > > +SetThreadDescription(HANDLE hThread, PCWSTR lpThreadDescription);
> > > +pSetThreadDescription = &SetThreadDescription;
> > > +#endif
> > > +
> > > +if (utf8towchar(name, &wname) < 0)
> > > +return AVERROR(ENOMEM);
> > > +
> > > +hr = pSetThreadDescription(GetCurrentThread(), wname);
> > > +av_free(wname);
> > > +return SUCCEEDED(hr) ? 0 : AVERROR(EINVAL);
> > > +}
> > > +
> >
> > I can only comment on the non-UWP side of things, but in general the
> > code seems fine. I guess this function definition has not been in
> > mingw-w64 etc for long enough to hope it would always be there and
> > thus we need to define it (similar to pf_DXGIGetDebugInterface)?
> >
> > The only question mark that is left is whether this functionality is
> > actually in kernel32 or kernelbase. When I first saw
> > https://stackoverflow.com/questions/62243162/how-to-access-
> > setthreaddescription-in-windows-2016-server-version-1607
> > I more or less thought of it as a possibly fluke or so, but then
> > apparently mingw-w64 went for kernelbase as well in winpthreads?
> > https://sourceforge.net/p/mingw-w64/mailman/message/58829419/
> >
> > What it seems like is that kernel32 works for (at the very least) 20+
> > versions of win10+, and older stuff such as the still-supported server
> > 2016 requires direct usage of kernelbase?
> >
> > Jan
> > ___
>
> Hi Jan,
>
> the actual implementation is (and has always been) in kernelbase.dll.
>
> It was introduced there with Windows SDK 10.0.14393 (Windows OS 1607).
> At some point between SDKs 14393 and 18362 (don't have the in-betweens
> installed), a forwarding export had been added to kernel32.dll (try: dumpbin
> /exports c:\windows\system32\kernel32.dll | findstr SetThreadDescription).
>
> So, using kernelbase.dll will cover more Windows versions than with
> kernel32.dll.
I don't think the few unsupported versions that would be covered by
this are worth the added complexity in the code. Maybe it will never
be moved out of kernelbase.dll, but our entry point is kernel32.dll as
documentation states. I don't see the need to check both and actually
we would need to check the api set too. Which is actually the first
forwarded target from kernel32.dll
> dumpbin /exports c:\windows\system32\kernel32.dll | findstr
> SetThreadDescription
1431 596 SetThreadDescription (forwarded to
api-ms-win-core-processthreads-l1-1-3.SetThreadDescription)
Chromium uses kernel32.dll
https://chromium.googlesource.com/chromium/src/+/1a4233541ca76ad2cfda2630d44744b5d29dd73a/base/threading/platform_thread_win.cc#222
mpv uses kernel32.dll
https://github.com/mpv-player/mpv/blob/52a95d91bd46bded9c5440db6bdd4dcada65/osdep/threads-win32.h#L166
winpthreads uses kernelbase.dll
https://github.com/mingw-w64/mingw-w64/blob/90da6c6535c503159e952dc8b44f8778bed6f622/mingw-w64-libraries/winpthreads/src/misc.c#L51
vlc uses both api-ms-win-core-processthreads-l1-1-3.dll and
kernelbase.dll
https://code.videolan.org/videolan/vlc/-/blob/7616581625670b94381f78e6cf3021b5625551df/src/win32/thread.c#L726-728
I think using kernel32.dll on win32 target is fine. Though t
[FFmpeg-devel] [PATCH] ffmpeg/repo: Add dot-folders in the repository root to .gitignore
From: softworkz Those are often used by IDEs and FFmpeg doesn't have any such folders in the repo. Signed-off-by: softworkz --- ffmpeg/repo: Add dot-folders in the repository root to .gitignore Those are often used by IDEs and FFmpeg doesn't have any such folders in the repo. Signed-off-by: softworkz softwo...@hotmail.com Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-65%2Fsoftworkz%2Fsubmit_ignore_dotfolders-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-65/softworkz/submit_ignore_dotfolders-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/65 .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 430abaf91b..59c89da5e0 100644 --- a/.gitignore +++ b/.gitignore @@ -44,3 +44,4 @@ /tools/python/__pycache__/ /libavcodec/vulkan/*.c /libavfilter/vulkan/*.c +/.*/ base-commit: bf327ac6762dfbf17ce7c766bbcd3f86942769f6 -- ffmpeg-codebot ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable
On 2025-04-13 10:12 pm, Zhao Zhili wrote:
On Apr 13, 2025, at 19:15, Gyan Doshi wrote:
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 - xx - 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);
+#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_DEMUXER0x04 ///< demuxer has a seek function
+#define AVSEEKABLE_PKTSCAN0x08 ///< seek is performed by consuming 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
+#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
+
+/**
+ * Report if and how a seek can be performed in a given input.
+ *
+ * @param smedia file handle
+ *
+ * @return 0 if no seek can be performed on input,
+ * -1 if the fmt ctx is NULL or is not an input
+ * else return AVSEEKABLE_ bitflags indicating seekability features.
+ */
+int avformat_query_seekable(AVFormatContext *s);
+
/**
* Discard all internally buffered data. This can be useful when dealing with
* discontinuities in the byte stream. Generally works only with formats that
diff --git a/libavformat/seek.c b/libavformat/seek.c
index c0d94371e6..776a09744a 100644
--- a/libavformat/seek.c
+++ b/libavformat/seek.c
@@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int
stream_index, int64_t min_ts,
return ret;
}
+int avformat_query_seekable(AVFormatContext *s)
+{
+int ret = 0;
+
+if (!s || !s->iformat)
+return -1;
+
+if (!(s->pb && s->pb->seekable) || s->ctx_flags & AVFMTCTX_UNSEEKABLE)
+return 0;
I think RTSP doesn’t follow this rule, it’s seekable.
Ah, yes, the protocol implemented as a demuxer. Will add an exception.
Regards,
Gyan
+
+if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
+ret |= AVSEEKABLE_NORMAL;
+
+if (s->pb->seekable & AVIO_SEEKABLE_TIME)
+ret |= AVSEEKABLE_PROTOCOL;
+
+if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
+ret |= AVSEEKABLE_DEMUXER;
+
+if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags &
AVFMT_NOBINSEARCH))
+ret |= AVSEEKABLE_PKTSCAN;
+
+if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
+ret |= AVSEEKABLE_TIME;
+
+// TODO: incomplete, a few demuxers don't set flag but error out on byte
seek
+if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
+ret |= AVSEEKABLE_BYTE;
+
+// 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;
+
+// TODO: flag exists but not added to the demuxers which support it
+if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
+ret |= AVSEEKABLE_FAST;
+
+if (!(ret & AVSEEKABLE_DEMUXER) && ret & AVSEEKABLE_PKTSCAN)
+ret |= AVSEEKABLE_FWDONLY;
+
+if ( !(ret & AVSEEKABLE_DEMUXER) &&
+ !(ret & AVSEEKABLE_PKTSCAN) &&
+ !(ret & AVSEEKABLE_BYTE) &&
+ !(ret & AVSEEKABLE_PROTOCOL) &&
+ (s->iformat->flags & AVFMT_NOGENSEARCH) )
+ret = 0;
+
+return ret;
+}
+
/** Flush the frame reader. */
void ff_read_frame_flush(AVFormatContext *s)
{
diff --git a/libavformat/version.h b/libavformat/version.h
index 752aac16f7..a7c80dc564 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
#include "version_major.h"
-#define LIBAVFORMAT_VERSION_MINOR 0
+#define LIBAVFORMAT_VERSION_MINOR 1
#define LIB
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable
On 2025-04-13 09:39 pm, softworkz . wrote: -Original Message- From: ffmpeg-devel 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 - xx - 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_DEMUXER0x04 ///< demuxer has a seek function +#define AVSEEKABLE_PKTSCAN0x08 ///< 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_DEMUXER0x04 ///< demuxer has a seek function +#define AVSEEKABLE_PKTSCAN0x08 ///< 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 13/18] ffv1/vulkan: redo context count tracking and quant_table_idx management
Le 12/04/2025 à 09:22, Lynne a écrit : Also, this commit fully fixes decoding of context=1 encoded files. I confirm that it passes all my tests with this patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable
> -Original Message- > From: ffmpeg-devel On Behalf Of Gyan > Doshi > Sent: Montag, 14. April 2025 06:24 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat: add > avformat_query_seekable > > > > On 2025-04-13 09:39 pm, softworkz . wrote: > > > >> -Original Message- > >> From: ffmpeg-devel 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. [..] > > 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_DEMUXER0x04 ///< demuxer has a seek function > >> +#define AVSEEKABLE_PKTSCAN0x08 ///< 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. Sorry, what I meant is like: AVSEEKABLE_PKTSCAN0x08 AVSEEKABLE_TIME 0x100 i.e. first block - first byte, second block - second byte, etc. (just for aesthetics obviously) sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section
On 2025-04-13 09:48 pm, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Gyan
Doshi
Sent: Sonntag, 13. April 2025 13:16
To:ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in
format section
---
fftools/ffprobe.c| 49 +++-
tests/ref/fate/cavs-demux| 2 +-
tests/ref/fate/ffprobe_compact | 2 +-
tests/ref/fate/ffprobe_csv | 2 +-
tests/ref/fate/ffprobe_default | 1 +
tests/ref/fate/ffprobe_flat | 1 +
tests/ref/fate/ffprobe_ini | 1 +
tests/ref/fate/ffprobe_json | 1 +
tests/ref/fate/ffprobe_xml | 2 +-
tests/ref/fate/ffprobe_xsd | 2 +-
tests/ref/fate/flv-demux | 2 +-
tests/ref/fate/gapless-mp3-side-data | 2 +-
tests/ref/fate/oggopus-demux | 2 +-
tests/ref/fate/ts-demux | 2 +-
tests/ref/fate/ts-opus-demux | 2 +-
tests/ref/fate/ts-small-demux| 2 +-
tests/ref/fate/ts-timed-id3-demux| 2 +-
17 files changed, 64 insertions(+), 13 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e0a7322523..8b09afb8c1 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext *tfc,
InputFile *ifile)
{
AVFormatContext *fmt_ctx = ifile->fmt_ctx;
int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
-int ret = 0;
+int seekable, ret = 0;
avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
print_str_validate("filename", fmt_ctx->url);
@@ -2279,6 +2279,53 @@ static int show_format(AVTextFormatContext *tfc,
InputFile *ifile)
if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx-
bit_rate, unit_bit_per_second_str);
else print_str_opt("bit_rate", "N/A");
print_int("probe_score", fmt_ctx->probe_score);
+
+seekable = avformat_query_seekable(fmt_ctx);
+if (seekable > 0) {
+int gen = 1, ante = 0;
+AVBPrint seek_str;
+av_bprint_init(&seek_str, 0, AV_BPRINT_SIZE_AUTOMATIC);
+
+av_bprintf(&seek_str, "yes, by");
+if (seekable & AVSEEKABLE_TIME) {
+av_bprintf(&seek_str, " time");
+if (seekable & AVSEEKABLE_PTS)
+av_bprintf(&seek_str, "(pts)");
+else
+av_bprintf(&seek_str, "(dts)");
+ante = 1;
+}
+if (seekable & AVSEEKABLE_BYTE) {
+av_bprintf(&seek_str, "%cbyte-offset", ante ? ',':' ');
+ante = 1;
+}
+if (seekable & AVSEEKABLE_FRAME) {
+av_bprintf(&seek_str, "%cframe-index", ante ? ',':' ');
+}
+
+ante = 0;
+av_bprintf(&seek_str, " via");
+if (seekable & AVSEEKABLE_DEMUXER) {
+av_bprintf(&seek_str, " demuxer");
+gen = 0;
+ante = 1;
+}
+if (seekable & AVSEEKABLE_PKTSCAN) {
+av_bprintf(&seek_str, "%cpacket-scan", ante ? ',':' ');
+gen = 0;
+ante = 0;
+}
+if (gen)
+av_bprintf(&seek_str, " generic seek");
+
+if (seekable & AVSEEKABLE_FWDONLY)
+av_bprintf(&seek_str, " (forward only)");
+
+print_str("seekable", seek_str.str);
+}
+else
+print_str("seekable", "no");
+
if (do_show_format_tags)
ret = show_tags(tfc, fmt_ctx->metadata,
SECTION_ID_FORMAT_TAGS);
Hi Gyan,
the problem that I see here is that it's not machine-readable and would require
non-trivial parsing to translate back to the actual information behind it.
I think that either a separate sub-section or at least three separate values
would be better.
I can add a delimiter like |
e.g.
yes|time(pts),frame-index|demuxer,packet-scan|fast
All of the phrases for an attribute are unique, and for that, they just
need to grep, not parse the string.
Most CLI users will only care about two things: yes/no and forward-only.
Another note: When you skim through the ffprobe code, you can see that ffprobe rarely
does its own "numbers-to-string" translations (only for cases of absence, like
'none', 'unknown', etc.). Normally, those translations are included in the libs where
they are defined.
The information is stored as bitflags in an int. How would the lib do it?
Oh, and I believe you also need to add new output fields to the xml schema file
(ffprobe.xsd).
Will do.
Regards,
Gyan
Still like it! 😊
Thanks,
sw
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section
> -Original Message-
> From: ffmpeg-devel On Behalf Of Gyan
> Doshi
> Sent: Montag, 14. April 2025 06:40
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability
> details in format section
>
>
>
> On 2025-04-13 09:48 pm, softworkz . wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> Gyan
> >> Doshi
> >> Sent: Sonntag, 13. April 2025 13:16
> >> To:ffmpeg-devel@ffmpeg.org
> >> Subject: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details
> in
> >> format section
> >>
> >> ---
> >> fftools/ffprobe.c| 49
> +++-
> >> tests/ref/fate/cavs-demux| 2 +-
> >> tests/ref/fate/ffprobe_compact | 2 +-
> >> tests/ref/fate/ffprobe_csv | 2 +-
> >> tests/ref/fate/ffprobe_default | 1 +
> >> tests/ref/fate/ffprobe_flat | 1 +
> >> tests/ref/fate/ffprobe_ini | 1 +
> >> tests/ref/fate/ffprobe_json | 1 +
> >> tests/ref/fate/ffprobe_xml | 2 +-
> >> tests/ref/fate/ffprobe_xsd | 2 +-
> >> tests/ref/fate/flv-demux | 2 +-
> >> tests/ref/fate/gapless-mp3-side-data | 2 +-
> >> tests/ref/fate/oggopus-demux | 2 +-
> >> tests/ref/fate/ts-demux | 2 +-
> >> tests/ref/fate/ts-opus-demux | 2 +-
> >> tests/ref/fate/ts-small-demux| 2 +-
> >> tests/ref/fate/ts-timed-id3-demux| 2 +-
> >> 17 files changed, 64 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> >> index e0a7322523..8b09afb8c1 100644
> >> --- a/fftools/ffprobe.c
> >> +++ b/fftools/ffprobe.c
> >> @@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext
> *tfc,
> >> InputFile *ifile)
> >> {
> >> AVFormatContext *fmt_ctx = ifile->fmt_ctx;
> >> int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
> >> -int ret = 0;
> >> +int seekable, ret = 0;
> >>
> >> avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
> >> print_str_validate("filename", fmt_ctx->url);
> >> @@ -2279,6 +2279,53 @@ static int show_format(AVTextFormatContext
> *tfc,
> >> InputFile *ifile)
> >> if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx-
> >>> bit_rate, unit_bit_per_second_str);
> >> else print_str_opt("bit_rate", "N/A");
> >> print_int("probe_score", fmt_ctx->probe_score);
> >> +
> >> +seekable = avformat_query_seekable(fmt_ctx);
> >> +if (seekable > 0) {
> >> +int gen = 1, ante = 0;
> >> +AVBPrint seek_str;
> >> +av_bprint_init(&seek_str, 0, AV_BPRINT_SIZE_AUTOMATIC);
> >> +
> >> +av_bprintf(&seek_str, "yes, by");
> >> +if (seekable & AVSEEKABLE_TIME) {
> >> +av_bprintf(&seek_str, " time");
> >> +if (seekable & AVSEEKABLE_PTS)
> >> +av_bprintf(&seek_str, "(pts)");
> >> +else
> >> +av_bprintf(&seek_str, "(dts)");
> >> +ante = 1;
> >> +}
> >> +if (seekable & AVSEEKABLE_BYTE) {
> >> +av_bprintf(&seek_str, "%cbyte-offset", ante ? ',':' ');
> >> +ante = 1;
> >> +}
> >> +if (seekable & AVSEEKABLE_FRAME) {
> >> +av_bprintf(&seek_str, "%cframe-index", ante ? ',':' ');
> >> +}
> >> +
> >> +ante = 0;
> >> +av_bprintf(&seek_str, " via");
> >> +if (seekable & AVSEEKABLE_DEMUXER) {
> >> +av_bprintf(&seek_str, " demuxer");
> >> +gen = 0;
> >> +ante = 1;
> >> +}
> >> +if (seekable & AVSEEKABLE_PKTSCAN) {
> >> +av_bprintf(&seek_str, "%cpacket-scan", ante ? ',':' ');
> >> +gen = 0;
> >> +ante = 0;
> >> +}
> >> +if (gen)
> >> +av_bprintf(&seek_str, " generic seek");
> >> +
> >> +if (seekable & AVSEEKABLE_FWDONLY)
> >> +av_bprintf(&seek_str, " (forward only)");
> >> +
> >> +print_str("seekable", seek_str.str);
> >> +}
> >> +else
> >> +print_str("seekable", "no");
> >> +
> >> if (do_show_format_tags)
> >> ret = show_tags(tfc, fmt_ctx->metadata,
> >> SECTION_ID_FORMAT_TAGS);
> >
> > Hi Gyan,
> >
> > the problem that I see here is that it's not machine-readable and
> would require non-trivial parsing to translate back to the actual
> information behind it.
> > I think that either a separate sub-section or at least three separate
> values would be better.
>
> I can add a delimiter like |
>
> e.g.
>
> yes|time(pts),frame-index|demuxer,packet-scan|fast
>
> All of the phrases for an attribute are unique, and for that, they just
> need to grep, not parse the string.
> Most CLI users will only care about two things: yes/no and forward-only.
When processing data using formats like XML or JSON by software, there is no
"grep".
Machine-readable means (not only but inclu
Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Montag, 14. April 2025 06:52
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability
> details in format section
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Gyan
> > Doshi
> > Sent: Montag, 14. April 2025 06:40
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability
> > details in format section
> >
> >
> >
> > On 2025-04-13 09:48 pm, softworkz . wrote:
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel On Behalf Of
> > Gyan
> > >> Doshi
> > >> Sent: Sonntag, 13. April 2025 13:16
> > >> To:ffmpeg-devel@ffmpeg.org
> > >> Subject: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability
> details
> > in
> > >> format section
> > >>
> > >> ---
> > >> fftools/ffprobe.c| 49
> > +++-
> > >> tests/ref/fate/cavs-demux| 2 +-
> > >> tests/ref/fate/ffprobe_compact | 2 +-
> > >> tests/ref/fate/ffprobe_csv | 2 +-
> > >> tests/ref/fate/ffprobe_default | 1 +
> > >> tests/ref/fate/ffprobe_flat | 1 +
> > >> tests/ref/fate/ffprobe_ini | 1 +
> > >> tests/ref/fate/ffprobe_json | 1 +
> > >> tests/ref/fate/ffprobe_xml | 2 +-
> > >> tests/ref/fate/ffprobe_xsd | 2 +-
> > >> tests/ref/fate/flv-demux | 2 +-
> > >> tests/ref/fate/gapless-mp3-side-data | 2 +-
> > >> tests/ref/fate/oggopus-demux | 2 +-
> > >> tests/ref/fate/ts-demux | 2 +-
> > >> tests/ref/fate/ts-opus-demux | 2 +-
> > >> tests/ref/fate/ts-small-demux| 2 +-
> > >> tests/ref/fate/ts-timed-id3-demux| 2 +-
> > >> 17 files changed, 64 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> > >> index e0a7322523..8b09afb8c1 100644
> > >> --- a/fftools/ffprobe.c
> > >> +++ b/fftools/ffprobe.c
> > >> @@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext
> > *tfc,
> > >> InputFile *ifile)
> > >> {
> > >> AVFormatContext *fmt_ctx = ifile->fmt_ctx;
> > >> int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
> > >> -int ret = 0;
> > >> +int seekable, ret = 0;
> > >>
> > >> avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
> > >> print_str_validate("filename", fmt_ctx->url);
> > >> @@ -2279,6 +2279,53 @@ static int show_format(AVTextFormatContext
> > *tfc,
> > >> InputFile *ifile)
> > >> if (fmt_ctx->bit_rate > 0) print_val("bit_rate",
> fmt_ctx-
> > >>> bit_rate, unit_bit_per_second_str);
> > >> else print_str_opt("bit_rate",
> "N/A");
> > >> print_int("probe_score", fmt_ctx->probe_score);
> > >> +
> > >> +seekable = avformat_query_seekable(fmt_ctx);
> > >> +if (seekable > 0) {
> > >> +int gen = 1, ante = 0;
> > >> +AVBPrint seek_str;
> > >> +av_bprint_init(&seek_str, 0, AV_BPRINT_SIZE_AUTOMATIC);
> > >> +
> > >> +av_bprintf(&seek_str, "yes, by");
> > >> +if (seekable & AVSEEKABLE_TIME) {
> > >> +av_bprintf(&seek_str, " time");
> > >> +if (seekable & AVSEEKABLE_PTS)
> > >> +av_bprintf(&seek_str, "(pts)");
> > >> +else
> > >> +av_bprintf(&seek_str, "(dts)");
> > >> +ante = 1;
> > >> +}
> > >> +if (seekable & AVSEEKABLE_BYTE) {
> > >> +av_bprintf(&seek_str, "%cbyte-offset", ante ? ',':'
> ');
> > >> +ante = 1;
> > >> +}
> > >> +if (seekable & AVSEEKABLE_FRAME) {
> > >> +av_bprintf(&seek_str, "%cframe-index", ante ? ',':'
> ');
> > >> +}
> > >> +
> > >> +ante = 0;
> > >> +av_bprintf(&seek_str, " via");
> > >> +if (seekable & AVSEEKABLE_DEMUXER) {
> > >> +av_bprintf(&seek_str, " demuxer");
> > >> +gen = 0;
> > >> +ante = 1;
> > >> +}
> > >> +if (seekable & AVSEEKABLE_PKTSCAN) {
> > >> +av_bprintf(&seek_str, "%cpacket-scan", ante ? ',':'
> ');
> > >> +gen = 0;
> > >> +ante = 0;
> > >> +}
> > >> +if (gen)
> > >> +av_bprintf(&seek_str, " generic seek");
> > >> +
> > >> +if (seekable & AVSEEKABLE_FWDONLY)
> > >> +av_bprintf(&seek_str, " (forward only)");
> > >> +
> > >> +print_str("seekable", seek_str.str);
> > >> +}
> > >> +else
> > >> +print_str("seekable", "no");
> > >> +
> > >> if (do_show_format_tags)
> > >> ret = show_tags(tfc, fmt_ctx->metadata,
> > >> SECTION_ID_FORMAT_TAGS);
> > >
> > > Hi Gyan,
> > >
> > > the problem that I see here is that it's not machine-readable and
> > would require non-trivial parsing to translate back to the actual
> > i
[FFmpeg-devel] Libtheora encoder/cingg <->ffmpeg interop?
I was testing our libtheora encoder/muxer after updating to libtheora 1.2.0 and noticed that ffmpeg complains about "(non)keyframe not correctly marked" ~/cinelerra/cinelerra-5.1 $ ffmpeg -i ~/svt_t.ogg -f null /dev/null ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers built with Android (12470979, +pgo, +bolt, +lto, +mlgo, based on r522817c) clang version 18.0.3 ( https://android.googlesource.com/toolchain/llvm-project d8003a456d14a3deb8054cdaa529ffbf02d9b262)configuration: --arch=aarch64 --as=aarch64-linux-android-clang --cc=aarch64-linux-android-clang --cxx=aarch64-linux-android-clang++ --nm=llvm-nm --ar=llvm-ar --ranlib=llvm-ranlib --pkg-config=/home/builder/.termux-build/_cache/android-r27c-api-24-v1/bin/pkg-config --strip=llvm-strip --cross-prefix=aarch64-linux-android- --disable-indevs --disable-outdevs --enable-indev=lavfi --disable-static --disable-symver --enable-cross-compile --enable-gnutls --enable-gpl --enable-version3 --enable-jni --enable-lcms2 --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libharfbuzz --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenmpt --enable-libopus --enable-librav1e --enable-librubberband --enable-libsoxr --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-mediacodec --enable-opencl --enable-shared --prefix=/data/data/com.termux/files/usr --target-os=android --extra-libs=-landroid-glob --disable-vulkan --enable-neon --disable-libfdk-aaclibavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.101 / 61. 19.101 libavformat61. 7.100 / 61. 7.100 libavdevice61. 3.100 / 61. 3.100 libavfilter10. 4.100 / 10. 4.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc58. 3.100 / 58. 3.100 [ogg @ 0xb4710c40f4d0] Broken file, keyframe not correctly marked. Input #0, ogg, from '/data/data/com.termux/files/home/svt_t.ogg': Duration: 00:00:13.44, start: 0.00, bitrate: 658 kb/s Stream #0:0: Video: theora, yuv420p(bt470bg/bt470bg/bt709), 1440x1080 [SAR 133:100 DAR 94:53], 25 tbr, 25 tbn Metadata: ENCODER : Cinelerra Infinity Stream mapping: Stream #0:0 -> #0:0 (theora (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to '/dev/null': Metadata: encoder : Lavf61.7.100 Stream #0:0: Video: wrapped_avframe, yuv420p(bt470bg/bt470bg/bt709, progressive), 1440x1080 [SAR 133:100 DAR 94:53], q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc61.19.101 wrapped_avframe [ogg @ 0xb4710c40f4d0] Broken file, keyframe not correctly marked. [ogg @ 0xb4710c40f4d0] Broken file, keyframe not correctly marked.=8.24x Last message repeated 1 times [ogg @ 0xb4710c40f4d0] Broken file, non-keyframe not correctly marked. Last message repeated 36 times [ogg @ 0xb4710c40f4d0] Broken file, non-keyframe not correctly marked.9x Last message repeated 58 times [out#0/null @ 0xb470bc40f7f0] video:144KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame= 336 fps=264 q=-0.0 Lsize=N/A time=00:00:13.44 bitrate=N/A speed=10.6x I found this recent bug on libtheora gitlab, not sure if last comment is true or misses something when it comes to ffmpeg? https://gitlab.xiph.org/xiph/theora/-/issues/2311 some other search hits: https://progress.opensuse.org/issues/42047 https://github.com/Enselic/recordmydesktop/issues/23 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Libtheora encoder/cingg <->ffmpeg interop?
On 4/13/2025 8:52 PM, Andrew Randrianasulu wrote: I was testing our libtheora encoder/muxer after updating to libtheora 1.2.0 and noticed that ffmpeg complains about "(non)keyframe not correctly marked" Backporting commit 22aa71d4da37a4ad2b0d28deeace64b57aa2ef50 to the 7.1 branch should fix it. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section
---
fftools/ffprobe.c| 49 +++-
tests/ref/fate/cavs-demux| 2 +-
tests/ref/fate/ffprobe_compact | 2 +-
tests/ref/fate/ffprobe_csv | 2 +-
tests/ref/fate/ffprobe_default | 1 +
tests/ref/fate/ffprobe_flat | 1 +
tests/ref/fate/ffprobe_ini | 1 +
tests/ref/fate/ffprobe_json | 1 +
tests/ref/fate/ffprobe_xml | 2 +-
tests/ref/fate/ffprobe_xsd | 2 +-
tests/ref/fate/flv-demux | 2 +-
tests/ref/fate/gapless-mp3-side-data | 2 +-
tests/ref/fate/oggopus-demux | 2 +-
tests/ref/fate/ts-demux | 2 +-
tests/ref/fate/ts-opus-demux | 2 +-
tests/ref/fate/ts-small-demux| 2 +-
tests/ref/fate/ts-timed-id3-demux| 2 +-
17 files changed, 64 insertions(+), 13 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e0a7322523..8b09afb8c1 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext *tfc,
InputFile *ifile)
{
AVFormatContext *fmt_ctx = ifile->fmt_ctx;
int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
-int ret = 0;
+int seekable, ret = 0;
avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
print_str_validate("filename", fmt_ctx->url);
@@ -2279,6 +2279,53 @@ static int show_format(AVTextFormatContext *tfc,
InputFile *ifile)
if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx->bit_rate,
unit_bit_per_second_str);
else print_str_opt("bit_rate", "N/A");
print_int("probe_score", fmt_ctx->probe_score);
+
+seekable = avformat_query_seekable(fmt_ctx);
+if (seekable > 0) {
+int gen = 1, ante = 0;
+AVBPrint seek_str;
+av_bprint_init(&seek_str, 0, AV_BPRINT_SIZE_AUTOMATIC);
+
+av_bprintf(&seek_str, "yes, by");
+if (seekable & AVSEEKABLE_TIME) {
+av_bprintf(&seek_str, " time");
+if (seekable & AVSEEKABLE_PTS)
+av_bprintf(&seek_str, "(pts)");
+else
+av_bprintf(&seek_str, "(dts)");
+ante = 1;
+}
+if (seekable & AVSEEKABLE_BYTE) {
+av_bprintf(&seek_str, "%cbyte-offset", ante ? ',':' ');
+ante = 1;
+}
+if (seekable & AVSEEKABLE_FRAME) {
+av_bprintf(&seek_str, "%cframe-index", ante ? ',':' ');
+}
+
+ante = 0;
+av_bprintf(&seek_str, " via");
+if (seekable & AVSEEKABLE_DEMUXER) {
+av_bprintf(&seek_str, " demuxer");
+gen = 0;
+ante = 1;
+}
+if (seekable & AVSEEKABLE_PKTSCAN) {
+av_bprintf(&seek_str, "%cpacket-scan", ante ? ',':' ');
+gen = 0;
+ante = 0;
+}
+if (gen)
+av_bprintf(&seek_str, " generic seek");
+
+if (seekable & AVSEEKABLE_FWDONLY)
+av_bprintf(&seek_str, " (forward only)");
+
+print_str("seekable", seek_str.str);
+}
+else
+print_str("seekable", "no");
+
if (do_show_format_tags)
ret = show_tags(tfc, fmt_ctx->metadata, SECTION_ID_FORMAT_TAGS);
diff --git a/tests/ref/fate/cavs-demux b/tests/ref/fate/cavs-demux
index b1e2c2fd25..ad3a7a0d4b 100644
--- a/tests/ref/fate/cavs-demux
+++ b/tests/ref/fate/cavs-demux
@@ -59,4 +59,4 @@
packet|codec_type=video|stream_index=0|pts=232|pts_time=1.93|dts=232
packet|codec_type=video|stream_index=0|pts=236|pts_time=1.97|dts=236|dts_time=1.97|duration=4|duration_time=0.03|size=83|pos=172252|flags=K__|data_hash=CRC32:a941bdf0
packet|codec_type=video|stream_index=0|pts=240|pts_time=2.00|dts=240|dts_time=2.00|duration=4|duration_time=0.03|size=5417|pos=172335|flags=K__|data_hash=CRC32:9d0d503b
stream|index=0|codec_name=cavs|profile=unknown|codec_type=video|codec_tag_string=[0][0][0][0]|codec_tag=0x|width=1280|height=720|coded_width=1280|coded_height=720|has_b_frames=0|sample_aspect_ratio=N/A|display_aspect_ratio=N/A|pix_fmt=yuv420p|level=-99|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=unspecified|field_order=unknown|refs=1|id=N/A|r_frame_rate=30/1|avg_frame_rate=25/1|time_base=1/120|start_pts=N/A|start_time=N/A|duration_ts=N/A|duration=N/A|bit_rate=N/A|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=60|extradata_size=18|extradata_hash=CRC32:1255d52e|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|disposition:non_diegetic=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:depend
[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 - xx - 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);
+#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_DEMUXER0x04 ///< demuxer has a seek function
+#define AVSEEKABLE_PKTSCAN0x08 ///< seek is performed by consuming 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
+#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
+
+/**
+ * Report if and how a seek can be performed in a given input.
+ *
+ * @param smedia file handle
+ *
+ * @return 0 if no seek can be performed on input,
+ * -1 if the fmt ctx is NULL or is not an input
+ * else return AVSEEKABLE_ bitflags indicating seekability features.
+ */
+int avformat_query_seekable(AVFormatContext *s);
+
/**
* Discard all internally buffered data. This can be useful when dealing with
* discontinuities in the byte stream. Generally works only with formats that
diff --git a/libavformat/seek.c b/libavformat/seek.c
index c0d94371e6..776a09744a 100644
--- a/libavformat/seek.c
+++ b/libavformat/seek.c
@@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int
stream_index, int64_t min_ts,
return ret;
}
+int avformat_query_seekable(AVFormatContext *s)
+{
+int ret = 0;
+
+if (!s || !s->iformat)
+return -1;
+
+if (!(s->pb && s->pb->seekable) || s->ctx_flags & AVFMTCTX_UNSEEKABLE)
+return 0;
+
+if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
+ret |= AVSEEKABLE_NORMAL;
+
+if (s->pb->seekable & AVIO_SEEKABLE_TIME)
+ret |= AVSEEKABLE_PROTOCOL;
+
+if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
+ret |= AVSEEKABLE_DEMUXER;
+
+if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags &
AVFMT_NOBINSEARCH))
+ret |= AVSEEKABLE_PKTSCAN;
+
+if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
+ret |= AVSEEKABLE_TIME;
+
+// TODO: incomplete, a few demuxers don't set flag but error out on byte
seek
+if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
+ret |= AVSEEKABLE_BYTE;
+
+// 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;
+
+// TODO: flag exists but not added to the demuxers which support it
+if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
+ret |= AVSEEKABLE_FAST;
+
+if (!(ret & AVSEEKABLE_DEMUXER) && ret & AVSEEKABLE_PKTSCAN)
+ret |= AVSEEKABLE_FWDONLY;
+
+if ( !(ret & AVSEEKABLE_DEMUXER) &&
+ !(ret & AVSEEKABLE_PKTSCAN) &&
+ !(ret & AVSEEKABLE_BYTE) &&
+ !(ret & AVSEEKABLE_PROTOCOL) &&
+ (s->iformat->flags & AVFMT_NOGENSEARCH) )
+ret = 0;
+
+return ret;
+}
+
/** Flush the frame reader. */
void ff_read_frame_flush(AVFormatContext *s)
{
diff --git a/libavformat/version.h b/libavformat/version.h
index 752aac16f7..a7c80dc564 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
#include "version_major.h"
-#define LIBAVFORMAT_VERSION_MINOR 0
+#define LIBAVFORMAT_VERSION_MINOR 1
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.49.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
Re: [FFmpeg-devel] [PATCH] avcodec/hevc: Enable d3d11va for yuv422p and yuv422p10
> On Apr 12, 2025, at 20:51, Zhao Zhili > wrote: > > From: Zhao Zhili > > --- > I don't have hardware which support 4:2:2. Please help test this feature. Please ignore this patch. There is a more complete patch on the mailing list https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241113032625.1243-1-aicomman...@gmail.com/ > > libavcodec/hevc/hevcdec.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c > index da8fdc5935..e5e63f57fe 100644 > --- a/libavcodec/hevc/hevcdec.c > +++ b/libavcodec/hevc/hevcdec.c > @@ -681,6 +681,10 @@ static enum AVPixelFormat get_format(HEVCContext *s, > const HEVCSPS *sps) > break; > case AV_PIX_FMT_YUV422P: > case AV_PIX_FMT_YUV422P10LE: > +#if CONFIG_HEVC_D3D11VA_HWACCEL > +*fmt++ = AV_PIX_FMT_D3D11VA_VLD; > +*fmt++ = AV_PIX_FMT_D3D11; > +#endif > #if CONFIG_HEVC_VAAPI_HWACCEL >*fmt++ = AV_PIX_FMT_VAAPI; > #endif > -- > 2.42.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/libjxlenc: prevent color encoding from being set twice
We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 115 +
1 file changed, 59 insertions(+), 56 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 81d466e6cc..54ba745672 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -258,7 +258,6 @@ static int libjxl_preprocess_stream(AVCodecContext *avctx,
const AVFrame *frame,
AVFrameSideData *sd;
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(frame->format);
JxlBasicInfo info;
-JxlColorEncoding jxl_color;
JxlPixelFormat *jxl_fmt = &ctx->jxl_fmt;
int bits_per_sample;
#if JPEGXL_NUMERIC_VERSION >= JPEGXL_COMPUTE_NUMERIC_VERSION(0, 8, 0)
@@ -320,66 +319,70 @@ static int libjxl_preprocess_stream(AVCodecContext
*avctx, const AVFrame *frame,
return AVERROR_EXTERNAL;
}
-/* rendering intent doesn't matter here
- * but libjxl will whine if we don't set it */
-jxl_color.rendering_intent = JXL_RENDERING_INTENT_RELATIVE;
-
-switch (frame->color_trc && frame->color_trc != AVCOL_TRC_UNSPECIFIED
-? frame->color_trc : avctx->color_trc) {
-case AVCOL_TRC_BT709:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_709;
-break;
-case AVCOL_TRC_LINEAR:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_LINEAR;
-break;
-case AVCOL_TRC_IEC61966_2_1:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_SRGB;
-break;
-case AVCOL_TRC_SMPTE428:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_DCI;
-break;
-case AVCOL_TRC_SMPTE2084:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_PQ;
-break;
-case AVCOL_TRC_ARIB_STD_B67:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_HLG;
-break;
-case AVCOL_TRC_GAMMA22:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_GAMMA;
-jxl_color.gamma = 1/2.2f;
-break;
-case AVCOL_TRC_GAMMA28:
-jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_GAMMA;
-jxl_color.gamma = 1/2.8f;
-break;
-default:
-if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
-av_log(avctx, AV_LOG_WARNING, "Unknown transfer function, assuming
Linear Light. Colors may be wrong.\n");
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE);
+if (sd && sd->size && JxlEncoderSetICCProfile(ctx->encoder, sd->data,
sd->size) != JXL_ENC_SUCCESS) {
+av_log(avctx, AV_LOG_WARNING, "Could not set ICC Profile\n");
+sd = NULL;
+}
+
+if ((!sd || !sd->size)) {
+/* no ICC Profile means enum-style color options */
+JxlColorEncoding jxl_color;
+
+switch (frame->color_trc && frame->color_trc != AVCOL_TRC_UNSPECIFIED
+? frame->color_trc : avctx->color_trc) {
+case AVCOL_TRC_BT709:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_709;
+break;
+case AVCOL_TRC_LINEAR:
jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_LINEAR;
-} else {
-av_log(avctx, AV_LOG_WARNING, "Unknown transfer function, assuming
IEC61966-2-1/sRGB. Colors may be wrong.\n");
+break;
+case AVCOL_TRC_IEC61966_2_1:
jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_SRGB;
+break;
+case AVCOL_TRC_SMPTE428:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_DCI;
+break;
+case AVCOL_TRC_SMPTE2084:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_PQ;
+break;
+case AVCOL_TRC_ARIB_STD_B67:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_HLG;
+break;
+case AVCOL_TRC_GAMMA22:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_GAMMA;
+jxl_color.gamma = 1/2.2f;
+break;
+case AVCOL_TRC_GAMMA28:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_GAMMA;
+jxl_color.gamma = 1/2.8f;
+break;
+default:
+if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
+av_log(avctx, AV_LOG_WARNING,
+ "Unknown transfer function, assuming Linear Light.
Colors may be wrong.\n");
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_LINEAR;
+} else {
+av_log(avctx, AV_LOG_WARNING,
+ "Unknown transfer function, assuming IEC61966-2-1/sRGB.
Colors may be wrong.\n");
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_SRGB;
+
Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
Hi Nicolas On Fri, Apr 11, 2025 at 07:09:09PM +0200, Nicolas George wrote: > Michael Niedermayer (HE12025-03-29): > > can you repost the AVWriter patches ? > > Sure, but I need to find the latest branch, and it is proving a cause of > procrastination for me. In the meantime, let me explain anew the > principles behind it, after a few years I might be able to express them > better. > > (I hope it means you are considering re-asserting your authority to > approve it on principle pending review of the code. I will not invest > more coding into it unless I know nobody has the authority to put it to > waste with “it does not belong”.) FFmpeg belongs to the People, to the Community. Its our project not just my project. This doesnt mean anyone should be able to block anything, this worked when the Community was smaller. In this specific case, I think the people who previously objected are no longer active in FFmpeg. So simply reposting the patchset seemed like a good idea to me. Maybe noone has objections, maybe someone has valid and good suggestions maybe someone has valid objections, that require technical changes. Maybe we will have an objection by one person but a clear consensus that most people are in favor of this being added to FFmpeg. OTOH, if there are objections from multiple active developers who would be affected by the patchset, then this is something we need to accept and then the patchset would not be able to be applied as long as these objections are standing. And even if there is just one active developer objecting, we need to very carefully listen and understand what he is saying before concluding that theres a consensus with one objection. Because maybe we can learn from the objection and improve the code for example > > > 1. Why we need it > > We use a lot of text for small things. As a command-line tool, we use > text to communicate with users. Even as a library, when GUIs do not have > the proper widget they will use text, and we need to provide the > necessary support functions. > > We should have a rule that for every type we add, we must have a > corresponding to-text API function. Furthermore, these functions should > all have the same type (up to the type of the opaque pointer), so that > we can store them in a structure that describes the type along with > other information (from string, ref/unref, etc.). > > We also need text for inter-process communication, like exporting > statistics from filters. > > Some of these to-text conversions happen once per frame. That means they > should happen without dynamic allocation. Quite complex code is > warranted to prevent dynamic allocations once per frame: see the frame > and buffer pools too. But some of these to-text conversion have an > unbounded output. That means the API needs to be able to handle long > output. > > BPrint meets the criteria: BPrint is as fast as a buffer on the stack > but can handle strings of arbitrary length. > > Unfortunately, BPrint is ugly. The name is ugly, and more importantly, > it is inflexible, it works only with flat buffers in memory. > > > 2. How AVWriter does it > > AVWriter is an attempt — successful, in my opinion — at keeping what is > good in BPrint and fixing what is ugly, in particular by giving it > features similar to AVIO. > > The design principle is the same as AVIO: a structure with callbacks > that perform the low-level operations. > > The difference with AVIO is that effort were made to keep the structures > small and allocatable by the caller. > > Also, the back-end is allowed to provide only a few methods: printf-like > or write-like or get_buffer-like, and the framework will make sure to > use one that is available. That means quite a bit of code to handle > doing a printf() on a back-end that only has get_buffer, but it is code > isolated within a single file and with ample FATE coverage. > > One of the tricks I used to avoid dynamic allocations is to store the > structure of methods and the structure with an instance as a structure > with two pointer elements passed by value. > > Another trick I used to avoid dynamic allocations is to store the size > of a structure in it. That way, if a caller is compiled with an old > version of the library, it stores a smaller size than the current one, > and the new version of the library can test and avoid accessing the new > fields. That lets the caller allocate the structure while keeping the > ability to add fields to the structure. > > Apart from that, is is rather straightforward. The default AVWriter is a > simple wrapper around BPrint, but there are also quite a few other > built-in ones: wrapper around stdio and av_log (without storing the > whole string), wrapper around a fixed-size buffer. AVwriter can also act > as a filter: get an AVWriter, you can create a new one that will encode > to base64 or HTML entities on the fly. > > > 3. Where it will go > > The trick passing a struct of methods and the object as a
Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
On 4/13/2025 12:13 PM, Michael Niedermayer wrote: FFmpeg belongs to the People, to the Community. Its our project not just my project. In this specific case, I think the people who previously objected are no longer active in FFmpeg. These two statements clash with each other, for reasons you're well aware of. If you were serious about the first, the second would not be true. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libpostproc: deprecate the AMD 3DNow! define
Hi, On Fri, Apr 11, 2025, 09:52 Sean McGovern wrote: > It was left unreferenced in 1f0948272a0fcd0e4947f629b600983f3338c02f. > --- > libpostproc/postprocess.h | 2 ++ > libpostproc/version.h | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/libpostproc/postprocess.h b/libpostproc/postprocess.h > index 5decb7e8a9..7010c2b51b 100644 > --- a/libpostproc/postprocess.h > +++ b/libpostproc/postprocess.h > @@ -87,7 +87,9 @@ void pp_free_context(pp_context *ppContext); > > #define PP_CPU_CAPS_MMX 0x8000 > #define PP_CPU_CAPS_MMX2 0x2000 > +#if PP_AMD_3DNOW > #define PP_CPU_CAPS_3DNOW 0x4000 > +#endif > #define PP_CPU_CAPS_ALTIVEC 0x1000 > #define PP_CPU_CAPS_AUTO 0x0008 > > diff --git a/libpostproc/version.h b/libpostproc/version.h > index bcbdd210c4..5a272630bf 100644 > --- a/libpostproc/version.h > +++ b/libpostproc/version.h > @@ -43,4 +43,6 @@ > > #define LIBPOSTPROC_IDENT "postproc" > AV_STRINGIFY(LIBPOSTPROC_VERSION) > > +#define PP_AMD_3DNOW (LIBPOSTPROC_VERSION_MAJOR < 60) > + > #endif /* POSTPROC_VERSION_H */ > -- > 2.39.5 > Did I do this correctly this time? Also it seems a bit much to wait a year or more for this to be actually removed. Can it instead be keyed to the next minor bump, or is this against some guarantee we give our downstreams? -- Sean McGovern > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/rtpdec_av1: Fix fragment continuation check when OBU_HAS_SIZE_FIELD is set
When OBU_HAS_SIZE_FIELD is set in the OBU header, frag_obu_size remains 0.
The code used !frag_obu_size to check for unexpected fragment continuation,
which resulted in incorrect drops. Introduce expect_frag_cont to explicitly
track continuation expectation.
Signed-off-by: Parallelc
---
libavformat/rtpdec_av1.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec_av1.c b/libavformat/rtpdec_av1.c
index 7cfc83b03c..87f8cd2b0b 100644
--- a/libavformat/rtpdec_av1.c
+++ b/libavformat/rtpdec_av1.c
@@ -53,6 +53,7 @@ struct PayloadContext {
unsigned int frag_pkt_leb_pos; ///< offset in buffer where OBU LEB starts
unsigned int frag_lebs_res; ///< number of bytes reserved for LEB
unsigned int frag_header_size; ///< size of OBU header (1 or 2)
+int expect_frag_cont; ///< expect fragment continuation in packet
int needs_td; ///< indicates that a TD should be output
int drop_fragment; ///< drop all fragments until next frame
int keyframe_seen; ///< keyframe was seen
@@ -165,7 +166,7 @@ static int av1_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
seq, expected_seq);
goto drop_fragment;
}
-if (!pkt->size || !data->frag_obu_size) {
+if (!pkt->size || !data->expect_frag_cont) {
av_log(ctx, AV_LOG_WARNING, "Unexpected fragment continuation in
AV1 RTP packet\n");
goto drop_fragment; // avoid repeated output for the same fragment
}
@@ -187,9 +188,11 @@ static int av1_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
av_log(ctx, AV_LOG_TRACE, "Timestamp changed to %u (or first pkt
%d), forcing TD\n", *timestamp, is_first_pkt);
data->needs_td = 1;
data->frag_obu_size = 0; // new temporal unit might have been
caused by dropped packets
+data->expect_frag_cont = 0;
}
-if (data->frag_obu_size) {
+if (data->expect_frag_cont) {
data->frag_obu_size = 0; // make sure we recover
+data->expect_frag_cont = 0;
av_log(ctx, AV_LOG_ERROR, "Missing fragment continuation in AV1
RTP packet\n");
return AVERROR_INVALIDDATA;
}
@@ -362,6 +365,7 @@ static int av1_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
write_leb(lebptr, final_obu_size);
data->frag_obu_size = 0; // signal end of fragment
+data->expect_frag_cont = 0;
} else if (is_last_fragmented && !rem_pkt_size) {
// add to total OBU size, so we can fix that in OBU header
// (but only if the OBU size was missing!)
@@ -370,6 +374,7 @@ static int av1_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
}
// fragment not yet finished!
result = -1;
+data->expect_frag_cont = 1;
}
is_frag_cont = 0;
@@ -391,6 +396,7 @@ static int av1_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
if (!is_last_fragmented) {
data->frag_obu_size = 0;
data->frag_pkt_leb_pos = 0;
+data->expect_frag_cont = 0;
}
#ifdef RTPDEC_AV1_VERBOSE_TRACE
@@ -409,6 +415,7 @@ drop_fragment:
data->keyframe_seen = 0;
data->drop_fragment = 1;
data->frag_obu_size = 0;
+data->expect_frag_cont = 0;
data->needs_td = 1;
if (pkt->size) {
av_log(ctx, AV_LOG_TRACE, "Dumping current AV1 frame packet\n");
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add avformat_query_seekable
> -Original Message- > From: ffmpeg-devel 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 - xx - 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_DEMUXER0x04 ///< demuxer has a seek function > +#define AVSEEKABLE_PKTSCAN0x08 ///< 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_DEMUXER0x04 ///< demuxer has a seek function > +#define AVSEEKABLE_PKTSCAN0x08 ///< 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section
> -Original Message-
> From: ffmpeg-devel On Behalf Of Gyan
> Doshi
> Sent: Sonntag, 13. April 2025 13:16
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in
> format section
>
> ---
> fftools/ffprobe.c| 49 +++-
> tests/ref/fate/cavs-demux| 2 +-
> tests/ref/fate/ffprobe_compact | 2 +-
> tests/ref/fate/ffprobe_csv | 2 +-
> tests/ref/fate/ffprobe_default | 1 +
> tests/ref/fate/ffprobe_flat | 1 +
> tests/ref/fate/ffprobe_ini | 1 +
> tests/ref/fate/ffprobe_json | 1 +
> tests/ref/fate/ffprobe_xml | 2 +-
> tests/ref/fate/ffprobe_xsd | 2 +-
> tests/ref/fate/flv-demux | 2 +-
> tests/ref/fate/gapless-mp3-side-data | 2 +-
> tests/ref/fate/oggopus-demux | 2 +-
> tests/ref/fate/ts-demux | 2 +-
> tests/ref/fate/ts-opus-demux | 2 +-
> tests/ref/fate/ts-small-demux| 2 +-
> tests/ref/fate/ts-timed-id3-demux| 2 +-
> 17 files changed, 64 insertions(+), 13 deletions(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index e0a7322523..8b09afb8c1 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext *tfc,
> InputFile *ifile)
> {
> AVFormatContext *fmt_ctx = ifile->fmt_ctx;
> int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
> -int ret = 0;
> +int seekable, ret = 0;
>
> avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
> print_str_validate("filename", fmt_ctx->url);
> @@ -2279,6 +2279,53 @@ static int show_format(AVTextFormatContext *tfc,
> InputFile *ifile)
> if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx-
> >bit_rate, unit_bit_per_second_str);
> else print_str_opt("bit_rate", "N/A");
> print_int("probe_score", fmt_ctx->probe_score);
> +
> +seekable = avformat_query_seekable(fmt_ctx);
> +if (seekable > 0) {
> +int gen = 1, ante = 0;
> +AVBPrint seek_str;
> +av_bprint_init(&seek_str, 0, AV_BPRINT_SIZE_AUTOMATIC);
> +
> +av_bprintf(&seek_str, "yes, by");
> +if (seekable & AVSEEKABLE_TIME) {
> +av_bprintf(&seek_str, " time");
> +if (seekable & AVSEEKABLE_PTS)
> +av_bprintf(&seek_str, "(pts)");
> +else
> +av_bprintf(&seek_str, "(dts)");
> +ante = 1;
> +}
> +if (seekable & AVSEEKABLE_BYTE) {
> +av_bprintf(&seek_str, "%cbyte-offset", ante ? ',':' ');
> +ante = 1;
> +}
> +if (seekable & AVSEEKABLE_FRAME) {
> +av_bprintf(&seek_str, "%cframe-index", ante ? ',':' ');
> +}
> +
> +ante = 0;
> +av_bprintf(&seek_str, " via");
> +if (seekable & AVSEEKABLE_DEMUXER) {
> +av_bprintf(&seek_str, " demuxer");
> +gen = 0;
> +ante = 1;
> +}
> +if (seekable & AVSEEKABLE_PKTSCAN) {
> +av_bprintf(&seek_str, "%cpacket-scan", ante ? ',':' ');
> +gen = 0;
> +ante = 0;
> +}
> +if (gen)
> +av_bprintf(&seek_str, " generic seek");
> +
> +if (seekable & AVSEEKABLE_FWDONLY)
> +av_bprintf(&seek_str, " (forward only)");
> +
> +print_str("seekable", seek_str.str);
> +}
> +else
> +print_str("seekable", "no");
> +
> if (do_show_format_tags)
> ret = show_tags(tfc, fmt_ctx->metadata,
> SECTION_ID_FORMAT_TAGS);
Hi Gyan,
the problem that I see here is that it's not machine-readable and would require
non-trivial parsing to translate back to the actual information behind it.
I think that either a separate sub-section or at least three separate values
would be better.
Another note: When you skim through the ffprobe code, you can see that ffprobe
rarely does its own "numbers-to-string" translations (only for cases of
absence, like 'none', 'unknown', etc.). Normally, those translations are
included in the libs where they are defined.
Oh, and I believe you also need to add new output fields to the xml schema file
(ffprobe.xsd).
Still like it! 😊
Thanks,
sw
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/18] hwcontext_vulkan: disable descriptor buffer extension on Intel
I tested the patches as a whole, for the moment with a focus on the performance. Tested with a RTX 4070 Ti on Linux & a RTX 3050 on Windows, globally no regression in speed on both test platforms, and I find a +25% (up to +35% in some cases, especially high resolutions) in average with 10-bit or 16-bit content for most cases (it is weird sometimes, no speed improvement, I'll check). Easy to decode complex 4K 10-bit in real time with the RTX 4070 Ti now, which is good performance for lossless compressed content. Additionally, the cards can handle higher resolutions e.g. 12k9k16bit succeeds now even on the low end RTX 3050 (at 0.5 fps :) ). Le 12/04/2025 à 09:22, Lynne a écrit : Temporary workaround. Will be replaced with a version check once a fix is in the works and a known next version for Mesa with a fix is known. --- libavutil/hwcontext_vulkan.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index 319b71ed04..d11c0274d2 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -773,6 +773,11 @@ static int check_extensions(AVHWDeviceContext *ctx, int dev, AVDictionary *opts, tstr = optional_exts[i].name; found = 0; +/* Intel has had a bad descriptor buffer implementation for a while */ +if (p->vkctx.driver_props.driverID == VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA && +!strcmp(tstr, VK_EXT_DESCRIPTOR_BUFFER_EXTENSION_NAME)) +continue; + if (dev && ((debug_mode == FF_VULKAN_DEBUG_VALIDATE) || (debug_mode == FF_VULKAN_DEBUG_PRINTF) || ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
