Re: [FFmpeg-devel] [PATCH 4/5] lavu/intmath.h: Fix UB in ff_ctz_c() and ff_ctzll_c()
On Thu, May 30, 2024 at 11:50 AM Tomas Härdin wrote: > > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont: > > Can't we just use the compiler built-ins here? AFAIK, they (GCC, > > LLVM) use the same algorithm if the CPU doesn't support native CTZ. > > And they will pick the right instruction if CPU does have CTZ. > > > > I get it that maybe it wasn't working so well 20 years ago, but we've > > increased compiler version requirements since then. > > I think we still support MSVC, but maybe we shouldn't? It's possible to > cross-compile for Windows either way. > This is not going to happen. - Hendrik ___ 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] lavc/vp9: reset segmentation fields when segmentation isn't enabled
On Thu, May 23, 2024 at 10:38 AM wrote:
>
> From: llyyr
>
> Fields under the segmentation switch are never reset on a new frame, and
> retain the value from the previous frame. This bugs out a bunch of
> hwaccel drivers when segmentation is disabled but update_map isn't
> reset because they don't ignore values behind switches. This commit also
> resets the temporal field, though it may not be required.
>
> We also do this for vp8 [1] so this commit is just mirroring the vp8
> logic.
>
> This fixes an issue with certain samples [2] that causes blocky
> artifacts with vaapi, d3d11va and cuda (and possibly others).
> Mesa worked around [3] this by ignoring these fields if
> segmentation.enabled is 0, but d3d11va still displays blocky artifacts.
>
> [1] https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> [2] https://github.com/mpv-player/mpv/issues/13533
> [3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
>
> Signed-off-by: llyyr
> ---
> libavcodec/vp9.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 6e2d18bf9595..8ede2e2eb358 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -709,6 +709,12 @@ static int decode_frame_header(AVCodecContext *avctx,
> s->s.h.segmentation.feat[i].skip_enabled = get_bits1(>gb);
> }
> }
> +} else {
> +// Reset fields under segmentation switch if segmentation is
> disabled.
> +// This is necessary because some hwaccels don't ignore these fields
> +// if segmentation is disabled.
> +s->s.h.segmentation.temporal = 0;
> +s->s.h.segmentation.update_map = 0;
> }
>
> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas
> --
> 2.45.1
Last call for comments. Otherwise will apply on the weekend with the
updated Git URL.
- Hendrik
___
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] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
On Wed, May 22, 2024 at 7:16 PM Lynne via ffmpeg-devel
wrote:
>
> On 22/05/2024 18:17, Philip Langdale via ffmpeg-devel wrote:
> > On Wed, 22 May 2024 11:10:31 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> >> wrote:
> >>
> >>> On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> >>>>
> >>>> segmentation.update_map is never reset to 0 on a new frame, and
> >>>> retains the value from the previous frame. This bugs out a bunch
> >>>> of hwaccel drivers when segmentation.enabled is 0 but update_map
> >>>> isn't because they don't ignore values behind switches. We also
> >>>> do this for vp8* so this commit is just mirroring the vp8 logic.
> >>>>
> >>>> This fixes an issue with certain samples** that causes blocky
> >>>> artifacts with vaapi and d3d11va (as far as known hwaccel drivers
> >>>> go). Mesa worked around*** this by ignoring this field if
> >>>> segmentation.enabled is 0, but d3d11va still doesn't work.
> >>>>
> >>>> *
> >>> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> >>>
> >>>> ** https://github.com/mpv-player/mpv/issues/13533
> >>>> ***
> >>>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
> >>>>
> >>>> Signed-off-by: llyyr
> >>>> ---
> >>>> libavcodec/vp9.c | 2 ++
> >>>> 1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> >>>> index 855936cdc1c7..4a628625131e 100644
> >>>> --- a/libavcodec/vp9.c
> >>>> +++ b/libavcodec/vp9.c
> >>>> @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext
> >>>> *avctx, s->s.h.segmentation.feat[i].skip_enabled =
> >>> get_bits1(>gb);
> >>>> }
> >>>> }
> >>>> +} else {
> >>>> +s->s.h.segmentation.update_map = 0;
> >>>> }
> >>>>
> >>>> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx
> >>>> deltas
> >>>>
> >>>> base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> >>>> --
> >>>
> >>> Change LGTM.
> >>> I was debugging the same issue today, and found the same problem
> >>> with some hwaccels not properly ignoring update_map when
> >>> segmentation is disabled.
> >>>
> >>> Will apply soon if there are no further comments.
> >>>
> >>
> >> Is fine, please apply.
> >>
> >
> > Another LGTM. We've been seeing this reported on the mpv side as well.
> >
> > --phil
> > ___
> > 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".
>
> Can't this get fixed by hwaccel code rather than globally?
> I'd hate to apply fixes with no information in shared code. This can get
> removed with no information about what relies on it.
Changing 5 different hwaccel modules to avoid one line here seems
rather silly, doesn't it?
We can add a comment, if that helps.
- Hendrik
___
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] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
>
> segmentation.update_map is never reset to 0 on a new frame, and retains
> the value from the previous frame. This bugs out a bunch of hwaccel
> drivers when segmentation.enabled is 0 but update_map isn't because
> they don't ignore values behind switches. We also do this for vp8* so
> this commit is just mirroring the vp8 logic.
>
> This fixes an issue with certain samples** that causes blocky
> artifacts with vaapi and d3d11va (as far as known hwaccel drivers go).
> Mesa worked around*** this by ignoring this field if
> segmentation.enabled is 0, but d3d11va still doesn't work.
>
> * https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> ** https://github.com/mpv-player/mpv/issues/13533
> *** https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
>
> Signed-off-by: llyyr
> ---
> libavcodec/vp9.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 855936cdc1c7..4a628625131e 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext *avctx,
> s->s.h.segmentation.feat[i].skip_enabled = get_bits1(>gb);
> }
> }
> +} else {
> +s->s.h.segmentation.update_map = 0;
> }
>
> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas
>
> base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> --
Change LGTM.
I was debugging the same issue today, and found the same problem with
some hwaccels not properly ignoring update_map when segmentation is
disabled.
Will apply soon if there are no further comments.
- Hendrik
___
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 8/8] aacdec: add a decoder for AAC USAC (xHE-AAC)
On Tue, May 21, 2024 at 9:52 PM Lynne via ffmpeg-devel wrote: > > > It should be the case here, we shouldn't need reordering as NATIVE just > lets you specify what order the elements appear in the bitstream. NATIVE means "the FFmpeg native ordering", not "bitstream order". CUSTOM lets you specify an arbitrary order but requires metadata to that effect, but it makes it particularly hard to map to any standard when playing or transcoding, so some efforts to try to unify it into a NATIVE format is always appreciated if possible. - Hendrik ___ 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] avcodec/av1dec: Always set ret before goto end
On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
wrote:
>
> Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
> and update_reference_list() could fail and therefore needed to
> be checked, which incidentally set ret. This is no longer happening,
> leading to a potential use of an uninitialized value which is
> also the subject of Coverity ticket #1596605.
>
> Fix this by always setting ret before goto end; do not return
> some random ancient value.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/av1dec.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index 79a30a114d..c3f255a29a 100644
> --- a/libavcodec/av1dec.c
> +++ b/libavcodec/av1dec.c
> @@ -1335,6 +1335,12 @@ static int av1_receive_frame_internal(AVCodecContext
> *avctx, AVFrame *frame)
> ret = set_output_frame(avctx, frame);
> if (ret < 0)
> av_log(avctx, AV_LOG_ERROR, "Set output frame
> error.\n");
> +} else {
> +// CBS checks for us that the frame to be shown actually
> existed
> +// in the bitstream; if it doesn't it could be e.g. due
> to
> +// skip_frame setting. Return EAGAIN to indicate that we
> are
> +// currently unable to produce output.
> +ret = AVERROR(EAGAIN);
> }
>
In the vein of this comment, set_output_frame will also return 0
without returning a frame in some cases - eg. with multiple layers.
Should this equally return EAGAIN rather than claiming success without
a frame?
- Hendrik
___
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] [RFC] 5 year plan & Inovation
On Tue, Apr 30, 2024 at 8:49 PM Ondřej Fiala wrote: > > On Tue Apr 30, 2024 at 2:11 AM CEST, Hendrik Leppkes wrote: > > On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote: > > > > > > I would really suggest you look at SourceHut. > > > > While SourceHut might be a slight improvement over the current > > situation (and only slight), it being fundamentally still based on > > email makes it inherit a lot of limitations and problems, and the > > functionality of the web interface is severely lacking, as key > > functions like commenting on patches are relegated back to your email > > client. > I think that's sort of the point, that you don't need a modern web > browser to do code review. The web interface is meant to supplement > email in the process, not replace it. I will take the replacement instead, thanks. Email is archaic. The entire point is to get away from email, not dress it up. SourceHut usage would likely make me even less interested then today. - Hendrik ___ 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] [RFC] 5 year plan & Inovation
On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote: > > I would really suggest you look at SourceHut. While SourceHut might be a slight improvement over the current situation (and only slight), it being fundamentally still based on email makes it inherit a lot of limitations and problems, and the functionality of the web interface is severely lacking, as key functions like commenting on patches are relegated back to your email client. Patch display functionality isn't any better then a mail client with a bit of syntax highlighting, nevermind bespoke review tools that are entirely absent, as it just sends you to your email client to respond. At least thats what I see when checking the SourceHut instance of SourceHut itself. As far as solutions go, this isn't one that I would imagine, I'm afraid. It's essentially a mailing list with patchwork. We have that now. - Hendrik ___ 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] avcodec/libx264: bump minimum required version to 160
On Wed, Apr 10, 2024 at 3:19 PM Michael Niedermayer wrote: > > On Tue, Apr 09, 2024 at 02:53:28PM +0200, Niklas Haas wrote: > > On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer > > wrote: > > > On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote: > > > > From: Niklas Haas > > > > > > > > This version is four years old, and present in Debian oldstable, Ubuntu > > > > 22.04 and Leap 15.1. > > > > > > Ubuntu 20.04 has general support till 2025-05-29 > > > Ubuntu 18.04 has security support (ESM) till 2028-04 > > > > I'll relax it from 160 back down to version 155 then. That covers Ubuntu > > 20.04 and Debian oldoldstable. > > 18.04 has 152 > > libx264-dev/bionic,now 2:0.152.2854+gite9a5903-2 amd64 [installed] > > Ubuntu 18.04 still has security support in ESM and ubuntu pro IIUC till > 2028-04 > Then they can use security updates from old release branches. The assumption that people will run Git ffmpeg but distribution provided x264 seems flawed. They can update dependencies that are important for them. The distribution itself is certainly never going to update. - Hendrik ___ 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] fix typo(1),style(1),nit(4) issue
On Wed, Apr 3, 2024 at 10:50 AM 정지우 | Eugene wrote:
>
> - typo(1) : Line 242 : RFIC7616 ->RFC7616
> - style(1) : make_digest_auth() , make_digest_auth_sha() : A1hash-> a1_hash
> and A2hash -> a2_hash
> - nit(3) : httpauth.c: Line 245,265,389:
> - nit(1) : httpauth.h: Line 85
>
> Signed-off-by: Eugene-bitsensing
>
> @@ -386,7 +386,7 @@ char *ff_http_auth_create_response(HTTPAuthState *state,
> const char *auth,
> if ((password = strchr(username, ':'))) {
> *password++ = 0;
> /* add digest algorithm SHA-256 */
> -if (!strcmp(state->digest_params.algorithm, "SHA-256")) {
> +if (!strcmp(state->digest_params.algorithm, "SHA256")) {
This is not a "nit", "SHA-256" with a dash is how RFC 7616 specifies
the algorithm token to be spelled.
> authstr = make_digest_auth_sha(state, username, password,
> path, method,"SHA256");
> } else {
> authstr = make_digest_auth(state, username, password, path,
> method);
- Hendrik
___
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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On Thu, Mar 28, 2024 at 10:12 AM wrote: > > From: Tong Wu > > HEVCHdrParams* receives a pointer which points to a dynamically > allocated memory block. It causes the memcmp always returning 1. > Add a function to do the comparision. A condition is also added to > avoid malloc(0). > > Signed-off-by: Tong Wu I've been looking into some playback glitches after 456c8ebe7c7dcd766d36cd0296815d89fd1166b5 and I can confirm that this patch fixes those as well. Using the fixed position of the *hdr member and its offset seems a bit icky though, and _at least_ could use a comment so future changes keep it last. - Hendrik ___ 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] Remove struct named initializer from aac profile option.
On Tue, Mar 26, 2024 at 9:42 AM Muiz Yusuff wrote: > > From: Muiz > > All fields of the stuct use unnamed struct initialization. > Also omit the field name for `AVOption::unit` to maintain consistency. "unit" intentionally uses designated initializers, so that adding new fields before it is more robust and less prone to errors. See 1e7d2007c3aca1cc1cd3b1ca409f4ded6c885f86 - Hendrik ___ 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] Add support d3d11va Intel Hevc Rext decoder.
On Sun, Feb 25, 2024 at 11:36 AM Mark Thompson wrote: > > On 25/02/2024 02:22, Водянников А.В. via ffmpeg-devel wrote: > > From ed8fda62bbdbc62f7565891c935966c931d001ca Mon Sep 17 00:00:00 2001 > > From: Aleksoid > > Date: Thu, 22 Feb 2024 19:15:48 +1000 > > Subject: [PATCH 1/2] Add support d3d11va Intel Hevc Rext decoder. > > > > Signed-off-by: Aleksoid > > --- > > libavcodec/d3d12va_hevc.c | 2 +- > > libavcodec/dxva2.c| 68 +-- > > libavcodec/dxva2_hevc.c | 41 ++--- > > libavcodec/dxva2_internal.h | 38 +++- > > libavcodec/hevcdec.c | 16 + > > libavutil/hwcontext_d3d11va.c | 26 +++--- > > 6 files changed, 178 insertions(+), 13 deletions(-) > > What elements are Intel-specific about this? > > Presumably there will be an official rext mode for D3D in future; are there > any possible problems with having this vendor extension in that case? > The next Windows SDK is presumably supposed to contain RExt support, but so far only partial information is present in the pre-release SDKs. It might be wise to wait for that. - Hendrik ___ 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] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
On Mon, Feb 19, 2024 at 12:44 AM Marton Balint wrote: > > > > On Fri, 16 Feb 2024, Anton Khirnov wrote: > > > Quoting Tomas Härdin (2024-02-03 20:58:20) > >> I think people with knowledge how interlacing is handled in other > >> formats and codecs might want to chime in. > > > > For MPEG codecs our decoders always output (properly signalled) > > interlaced content as two interleaved fields in a single AVFrame flagged > > with AV_FRAME_FLAG_INTERLACED. Its height is the height of the whole > > frame, so double the number of lines in each field. > > > > So IIUC this patch is taking the correct approach. > > I believe interlaced HEVC has the same issue, the decoder generates field > pictures and not frames. Would changing the HEVC decoder be acceptable to > generate frames with interleaved fields? > Absolutely. There have been WIP patches in the past that tried to do this, but resorting to memcpy instead of updating the decoder to write to every second line, and that should of course be avoided. HEVC also has HWAccel, which should work as well in the same manner, if possible. - Hendrik ___ 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] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer wrote: > > * A disagreement implies that there are 2 parties > * And we assume here that what one party wants is better for FFmpeg than what > the other wants. > * The TC needs to find out which partys choice is better or suggest a 3rd > choice. > * If one but not the other party is a member of the TC then this decission > becomes biased if that member votes > > Your interpretation suggests that the TC members are "above" everyone and > should > prevail in arguments they have with others. > Noone is above the rules, but just because someone has an opinion and shared it shouldn't disqualify them, because they were specifically voted into the TC for their opinions on technical matters. Would their opinion, and therefore their vote, change if someone else was seen as the person "blocking"? What if multiple people had expressed disagreement with a patch, and most of the TC was involved in the public discussion already? Do the remaining "uninvolved" people on the TC get all the decision power? Or do we consider most of the TC already opposing it publicly as perhaps an indicator that the patch might not be the way to go? Thats what the TC was voted in for, to give their opinion on technical matters and decide if needed, so why deprive them of their opinion, just because they already stated it publicly? That makes no sense to me. - Hendrik ___ 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] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n
On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö wrote: > > > > diff --git a/.gitattributes b/.gitattributes > > index 5a19b963b6..a900528e47 100644 > > --- a/.gitattributes > > +++ b/.gitattributes > > @@ -1,2 +1 @@ > > *.pnm -diff -text > > -tests/ref/fate/sub-scc eol=crlf > > This change seems to have had a tricky effect on the > tests/ref/fate/sub-scc file. Previously, when checked out, users got the > file with CRLF newlines. When updating to this git commit, or past it, > that file remains untouched, with CRLF still present, and the > fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git > checkout tests/ref/fate/sub-scc", then the file does get restored with LR > newlines, and the test passes. > > It's easy to do this change manually in the source checkout of a fate > runner, but I'm not sure how easily we get all fate instances fixed that > way - currently this test is failing in most of them. > Can this be fixed by restoring the .gitattribute entry but with eol=lf? Not sure if Git would reset the file then. - Hendrik ___ 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 v9 13/13] vvcdec: add vvc decoder
On Mon, Jan 1, 2024 at 3:54 PM Lynne wrote: > > Jan 1, 2024, 15:16 by nuomi2...@gmail.com: > > > vvc decoder plug-in to avcodec. > > split frames into slices/tiles and send them to vvc_thread for further > > decoding > > reorder and wait for the frame decoding to be done and output the frame > > > > Features: > > + Support I, P, B frames > > + Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension > > + Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, > > LMCS, ALF > > + 295 conformace clips passed > > - Not support RPR, IBC, PALETTE, and other minor features yet > > > > IBC == Intra-block copy? > Palette == palette (screen content) coding? Yes; Both IBC and PALETTE modes are alternate block coding modes, with these two primarily optimized for screen content. - Hendrik ___ 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 v3] avcodec/decode: guard against NULL hw_frames_ctx
On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
wrote:
>
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> v2: check for free_frame_priv (Hendrik)
> v3: return EINVAL (Christoph Reiter)
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
The latest change itself looks fine to me, I would however prefer if
the commit message would contain a bit more text and a bit less gdb
dump.
Maybe something like this (quick suggestion, for title and body):
avcodec: validate hw_frames_ctx is available when
AVHWAccel.free_frame_priv is used
Validate that a hw_frames_ctx is available before using it for the
AVHWAccel.free_frame_priv callback, and don't require it to be present when
the callback is not in use by the HWAccel.
---
Feel free to augment and reword, but I don't think the gdb dump offers
much info that couldn't be conveyed more clearly in a few words that
mention the absence of hw_frame_ctx.
- Hendrik
___
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] avcodec/decode: guard against NULL hw_frames_ctx
On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
wrote:
>
> Gurd against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
> libavcodec/decode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index ad39021..3caaeec 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1845,9 +1845,9 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx,
> void **hwaccel_picture_pr
>
> av_assert0(!*hwaccel_picture_private);
>
> -frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> +frames_ctx = (AVHWFramesContext *) avctx->hw_frames_ctx ?
> avctx->hw_frames_ctx->data : NULL;
> *hwaccel_picture_private =
> ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
> - frames_ctx->device_ctx,
> + frames_ctx ?
> frames_ctx->device_ctx : NULL,
>
> hwaccel->free_frame_priv);
The free_frame_priv callback is not usable when no context is
available. The code should be updated to check if the hwaccel has a
free_frame_priv callback and then require a frames_ctx to be set and
otherwise error out (instead of crashing), and if free_frame_priv is
not set, then it can allocate a buffer without these requirements.
- Hendrik
___
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 4/6] avcodec/h264: keep track of which frames used gray references
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4
> 4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index 691c61eea23..3234141dbd6 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst,
> const H264Picture *src)
> dst->field_picture = src->field_picture;
> dst->reference = src->reference;
> dst->recovered = src->recovered;
> +dst->gray = src->gray;
> dst->invalid_gap = src->invalid_gap;
> dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> dst->mb_width = src->mb_width;
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 4861a2cabba..2c4ab89dae1 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> h->poc.prev_frame_num= h->poc.frame_num;
>
> h->recovery_frame= h1->recovery_frame;
> +h->non_gray = h1->non_gray;
>
> return err;
> }
> @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
> H264SliceContext *sl,
> if (ret < 0)
> return ret;
> h->short_ref[0]->poc = prev->poc + 2U;
> +h->short_ref[0]->gray = prev->gray;
> ff_thread_report_progress(>short_ref[0]->tf, INT_MAX, 0);
> if (h->short_ref[0]->field_picture)
> ff_thread_report_progress(>short_ref[0]->tf, INT_MAX,
> 1);
> -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> color_frame(h->short_ref[0]->f, c);
> +h->short_ref[0]->gray = 1;
> +}
While we can't color invalid frames for hwaccels easily, the flag
should perhaps still be applied, as they are equally invalid.
Thinking about this, maybe the name should be less the color we
happened to use for it, and more like "placeholder" or "invalid" or
anything like that?
> h->short_ref[0]->frame_num = h->poc.prev_frame_num;
> }
> }
> @@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h,
> H264SliceContext *sl,
> (sl->ref_list[j][i].reference & 3);
> }
>
> +if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
> +h->cur_pic_ptr->gray = 0;
> +h->non_gray = 1;
> +} else {
> +int gray = 0;
> +for (j = 0; j < sl->list_count; j++) {
> +for (i = 0; i < sl->ref_count[j]; i++) {
> +gray |= sl->ref_list[j][i].parent->gray;
> +}
> +}
> +h->cur_pic_ptr->gray = gray;
> +}
> +
> if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
> av_log(h->avctx, AV_LOG_DEBUG,
> "slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d
> loop:%d:%d:%d weight:%d%s %s\n",
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ef9e60bbf33..7ea55db75dd 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
> ff_h264_unref_picture(>cur_pic);
>
> h->mb_y = 0;
> +h->non_gray = 0;
>
> ff_h264_free_tables(h);
> h->context_initialized = 0;
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index ede51951727..366626c056c 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -154,6 +154,8 @@ typedef struct H264Picture {
>
> /// RefStruct reference; its pointee is shared between decoding threads.
> atomic_int *decode_error_flags;
> +
> +int gray;
> } H264Picture;
>
> typedef struct H264Ref {
> @@ -567,6 +569,8 @@ typedef struct H264Context {
> struct FFRefStructPool *ref_index_pool;
> struct FFRefStructPool *decode_error_flags_pool;
> int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number
> lists, used in the loop filter, the first 2 are for -2,-1
> +
> +int non_gray; ///< Did we encounter a intra frame
> after a gray gap frame
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
> --
> 2.17.1
>
> ___
> 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
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 1:24 PM James Almer wrote: > > On 11/9/2023 9:21 AM, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-11-09 12:55:25) > >> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote: > >>> As nobody expressed a preference, the vote will start next Monday > >>> (2023-11-13). It should run for a week, and will be followed by TC/CC > >>> elections. > >>> > >>> The only extra GA candidate I see proposed so far is Ronald. If anyone > >>> wants to suggest further people, please do so in this thread ASAP. > >> > >> IMHO the question of the relation of the list of people who could vote > >> in the last GA vote and the people who where in the general assembly > >> in 2020 should be awnsered before further votes. > >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > > > As far as I can tell, the voter list in the last vote should be the same > > as the GA from 2020, except for the extra members whose voting rights > > expire after 2 years. > > > > Do you dispute that? > > > >> If the current GA stays as it is, then i propose the following people > >> (this list was quickly made and certainly has omisions and possibly errors, > >> check anything thats important to you!) > >> > >> The presumed 2020 General assembly as well as people who have subtantial > >> contributions over the lifetime of the project where the source of this > >> list > > > >> Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > > > > He actually is in the GA, but his Intel mailbox bounces. > > > >> Fabrice Bellard(Founder of the project over 600 commits in FFmpeg) > >> Aman Karmani (17 authored commits in 2020-2023, recently active in > >> 2023-June and work all over the codebase) > >> Baptiste Coudurier (Pays for our fate server since forever, maintains 15 > >> things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > >> in FFmpeg) > >> Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > >> Lauri Kasanen (Linux / PowerPC maintainer) > >> Dale Curtis(14 commits in 2020 was in the 2020-GA) > >> Alexander Strasser (Root admin, just recently reported that he could not > >> vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > >> foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > >> Huiwen Ren (8 matches in the codebase of his name, avs2* and > >> related things maintainer) > >> Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > >> hostility) > >> Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > >> 2020-GA but not on jbs list) > >> Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > >> entries in MAINTAINERs, 25 in copyrights) > >> Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > >> various bits of code, last active in git in 2020) > >> John Stebbins (over 100 commits in FFmpeg, last active in git in > >> 2020, 1 copyright match) > >> Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > >> commits in FFmpeg) > >> Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > >> in the source, last commit May 2023) > >> Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > >> commit in Oct 2023, 49 matches for his name in the codebase) > >> Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > >> MAINTAINERs, 70 copyright line matches) > >> Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > >> 4 copyrights, last commit in Jul 2023) > >> Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > >> Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > >> Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > >> 22 copyright matches) > >> Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > >> Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > >> Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > Sending voting emails to people who have not had any contact with the > > project for years, can be regarded as spamming. I think there should be > > some confirmation that these peop
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote: > > Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit : > > that said, i checked ML subscribers and found > > 16 of the people above to be currently subscribed with email addresses > > that i found by greping their name. (not posting the list due to privacy > > concerns) > > Thing is, if they are subscribed and still don't ask to be added to the GA, I > don't think they should be "volunteered" by someone else. They are of course > welcome to apply. > I don't see the big difference here for people that meet an arbitrary commit threshold, they get automatically added and not asked, but if you are slightly under you don't. By that logic, everyone should step forward and not be "volunteered" by a script of all things. - Hendrik ___ 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] [RFC] financial sustainability Plan A (SPI)
On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer wrote: > > On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: > > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : > > > > That's not a credible solution for a library. All reverse dependency > > > > developers would disable that before they ship affected FFmpeg versions, > > > > or worse, just stop updating their vendored FFmpeg. > > > > > > If its announced and we point to the commit, maybe half the minor users > > > will remove it, maybe most of the bigger ones. If its not announced > > > noone would remove it. companies do not audit the FFmpeg commits. > > > They would remove it after seeing it but at that point it did what it > > > intended to to, inform users again, like i said thats hypothetical and > > > controversal. But basically doing the same as companies which put > > > advertisements in without asking either creator nor viewer. > > > > How do you show ads without a GUI? Hijack the video signal from the decoder? > > In this very very hypothetical idea ... > it would not be a add, but a simple information box shown briefly that says > something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with > ffmpeg.org, donate if you enjoy" > If as a professional user of a decoder library, it starts putting in an ad or a watermark or whatever you want to call it, even if briefly, i'm looking for a new decoder library, or will venture to remove the message instantly. And if that wasn't enough to completely destroy the projects reputation, if you then try to hide it by randomizing or whatever, so that testing before deployment doesn't see it, that definitely will. This is not acceptable behavior for a decoder. And no "exposure" due to bad press will actually yield you a benefit. Companies won't pay you, because that doesn't get rid of the message. They'll pay an engineer to disable it. - Hendrik ___ 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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:57 AM James Almer wrote:
>
> On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
> >>
> >> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >>>
> >>> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> >>> "Channel
> >>> Configuration 14", and it being the first layout with top layer channels,
> >>> it's
> >>> best to use a different scheme to properly convey the presence and amount
> >>> of said
> >>> channels.
> >>> The new name will also be a better fit for the additions in the following
> >>> commits.
> >>>
> >>> Signed-off-by: James Almer
> >>> ---
> >>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> >>> index ac2ddfa022..8c40c81b44 100644
> >>> --- a/libavutil/channel_layout.h
> >>> +++ b/libavutil/channel_layout.h
> >>> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> >>> #define AV_CH_LAYOUT_7POINT1
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>> +#define AV_CH_LAYOUT_5POINT1POINT2
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>
> >> Looking at the specs and the naming of the thing, I don't think it
> >> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> >> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> >> that, and not swap the base layer speakers.
> >> Looking at the specifications, they don't map properly to our speaker
> >> definitions, as they assign it a generic "surround" title (at 100-120
> >> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> >> and a side speaker at 90 (as is the standard for 7.1 setups).
> >>
> >> Yes, this doesn't match the one you are renaming, but I think
> >> consistency within our own defined formats is important here. 5.1 ->
> >> 5.1.2 should just add two.
> >>
> >> The renamed one could be 5.1.2(back) or whatever we want to name those.
> >>
> >> Or we do it properly and actually include a proper "surround" speaker
> >> definition and get rid of the confusion between side and back. But
> >> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> >> definitions are mostly sourced from, so might not be worth it.
> >
> > Actually I got confused by our terrible naming. The define
> > AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
> > AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
> > Regardless, rather see consistency within those as well, so while the
> > name of the format is fine, rename the define to include the _BACK
> > maybe?
>
> Yes, it's a mess.
>
> Do i use "5.1.2" alongside AV_CH_LAYOUT_5POINT1POINT2_BACK, then?
That works for me.
- Hendrik
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
>
> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >
> > This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> > "Channel
> > Configuration 14", and it being the first layout with top layer channels,
> > it's
> > best to use a different scheme to properly convey the presence and amount
> > of said
> > channels.
> > The new name will also be a better fit for the additions in the following
> > commits.
> >
> > Signed-off-by: James Almer
> > ---
> > diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> > index ac2ddfa022..8c40c81b44 100644
> > --- a/libavutil/channel_layout.h
> > +++ b/libavutil/channel_layout.h
> > @@ -232,13 +232,15 @@ enum AVChannelOrder {
> > #define AV_CH_LAYOUT_7POINT1
> > (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> > #define AV_CH_LAYOUT_7POINT1_WIDE
> > (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> > +#define AV_CH_LAYOUT_5POINT1POINT2
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
>
> Looking at the specs and the naming of the thing, I don't think it
> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> that, and not swap the base layer speakers.
> Looking at the specifications, they don't map properly to our speaker
> definitions, as they assign it a generic "surround" title (at 100-120
> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> and a side speaker at 90 (as is the standard for 7.1 setups).
>
> Yes, this doesn't match the one you are renaming, but I think
> consistency within our own defined formats is important here. 5.1 ->
> 5.1.2 should just add two.
>
> The renamed one could be 5.1.2(back) or whatever we want to name those.
>
> Or we do it properly and actually include a proper "surround" speaker
> definition and get rid of the confusion between side and back. But
> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> definitions are mostly sourced from, so might not be worth it.
Actually I got confused by our terrible naming. The define
AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
Regardless, rather see consistency within those as well, so while the
name of the format is fine, rename the define to include the _BACK
maybe?
- Hendrik
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
>
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount of
> said
> channels.
> The new name will also be a better fit for the additions in the following
> commits.
>
> Signed-off-by: James Almer
> ---
> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> index ac2ddfa022..8c40c81b44 100644
> --- a/libavutil/channel_layout.h
> +++ b/libavutil/channel_layout.h
> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> #define AV_CH_LAYOUT_7POINT1
> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> #define AV_CH_LAYOUT_7POINT1_WIDE
> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> +#define AV_CH_LAYOUT_5POINT1POINT2
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
Looking at the specs and the naming of the thing, I don't think it
should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
that, and not swap the base layer speakers.
Looking at the specifications, they don't map properly to our speaker
definitions, as they assign it a generic "surround" title (at 100-120
degrees azimuth), while a rear/back speaker should be at 135 degrees,
and a side speaker at 90 (as is the standard for 7.1 setups).
Yes, this doesn't match the one you are renaming, but I think
consistency within our own defined formats is important here. 5.1 ->
5.1.2 should just add two.
The renamed one could be 5.1.2(back) or whatever we want to name those.
Or we do it properly and actually include a proper "surround" speaker
definition and get rid of the confusion between side and back. But
that breaks compat with WAVEFORMATEXTENSIBLE that our channel
definitions are mostly sourced from, so might not be worth it.
- Hendrik
- Hendrik
___
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] libavcodec/dxva2.c: fix dxva2 does not support H264 baseline profile
On Sat, Oct 14, 2023 at 6:02 AM xyz1001 wrote:
>
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
> ---
> libavcodec/dxva2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index d7bc587562..e6b83f89cc 100644
> --- a/libavcodec/dxva2.c
> +++ b/libavcodec/dxva2.c
> @@ -61,7 +61,8 @@ typedef struct dxva_mode {
> static const int prof_mpeg2_main[] = {AV_PROFILE_MPEG2_SIMPLE,
> AV_PROFILE_MPEG2_MAIN,
> AV_PROFILE_UNKNOWN};
> -static const int prof_h264_high[]= {AV_PROFILE_H264_CONSTRAINED_BASELINE,
> +static const int prof_h264_high[]= {AV_PROFILE_H264_BASELINE,
> +AV_PROFILE_H264_CONSTRAINED_BASELINE,
> AV_PROFILE_H264_MAIN,
> AV_PROFILE_H264_HIGH,
> AV_PROFILE_UNKNOWN};
Baseline is not compatible with main/high profile accelerators.
There is only one profile defined by DXVA2 that supports Baseline
completely, and I have never seen a GPU expose it - and we don't
support it.
- Hendrik
___
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] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler wrote: > I'm quite confused why this specific instance suddenly causes so much upset. Because its bad form to break compilation of master, if all it took to avoid that is change the order of pushing a tag to one repo and a patch to another. - Hendrik ___ 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] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler wrote: > > On 06/10/2023 14:29, Hendrik Leppkes wrote: > > On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler > > wrote: > >> > >> On 01.10.2023 04:06, James Almer wrote: > >>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > >> > >> It's expected behaviour to break compilation with random inter-release > >> versions of ffnvcodec. > >> It's only reliable exactly on release versions. > >> > > > > But isn't the point that there is no release version of ffnvcodec that > > I can use to build this? > > And that it has no check to limit building it, and will always fail > > with release versions? > > I don't understand what you mean. > Right now, it only works with nv-codec-headers master. > I will make a new release there very soon. You say that its expected to break with inter-release versions of ffnvcodec, but this is the opposite, it breaks with the release version and works with git versions. So I'm not sure I understand what you are saying. Requiring a non-released version of a dependency was obviously a gigantic oversight with the original patch, and as a result master is currently broken for any reasonable setup avoiding those "inter-release versions". - Hendrik ___ 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] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler wrote: > > On 01.10.2023 04:06, James Almer wrote: > > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > > It's expected behaviour to break compilation with random inter-release > versions of ffnvcodec. > It's only reliable exactly on release versions. > But isn't the point that there is no release version of ffnvcodec that I can use to build this? And that it has no check to limit building it, and will always fail with release versions? - Hendrik ___ 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] configure: disable vulkan if min version insufficient
On Fri, Sep 29, 2023 at 3:55 PM Tristan Matthews wrote: > > Fixes: https://trac.ffmpeg.org/ticket/10596 > --- > configure | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > index 20db1801ed..50ba6f772f 100755 > --- a/configure > +++ b/configure > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h > libcrystalhd/libcrystalhd_if. > > if enabled vulkan; then > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" > "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > -check_cpp_condition vulkan "vulkan/vulkan.h" > "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= > 255)" > +check_cpp_condition vulkan "vulkan/vulkan.h" > "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= > 255)" || > +warn "Disabling vulkan" && disable vulkan > fi > This change doesn't seem right. If a feature is explicitly requested, we generally fail the build and don't just disable the feature (afterall the user wanted it to be on). If the feature is not explicitly requested, then it should not print a message. - Hendrik ___ 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] TRAC Spam
On Fri, Sep 22, 2023 at 11:14 AM Michael Koch wrote: > > Is it ok if I remove the dead link to Python syntax, and replace it by > this link to Wikipedia? > https://en.wikipedia.org/wiki/Regular_expression > A more accurate page would probably to just point to the correct python regex docs, eg: https://docs.python.org/2.7/library/re.html ___ 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] configure: don't force specific C++ standard library linking
On Wed, Sep 6, 2023 at 12:14 AM Kacper Michajłow wrote:
>
> Other C++ standard libraries exist. Also, this is not a proper way to
> link the standard library anyway. Instead when a C++ dependency is
> detected, switch to the C++ compiler driver to properly link everything.
>
> Signed-off-by: Kacper Michajłow
> ---
> configure | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/configure b/configure
> index bd7f7697c8..90ee6e4f7d 100755
> --- a/configure
> +++ b/configure
> @@ -3584,11 +3584,9 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h
> machine_ioctl_bt848_h dev_video_bktr
> caca_outdev_deps="libcaca"
> decklink_deps_any="libdl LoadLibrary"
> decklink_indev_deps="decklink threads"
> -decklink_indev_extralibs="-lstdc++"
> decklink_indev_suggest="libzvbi"
> decklink_outdev_deps="decklink threads"
> decklink_outdev_suggest="libklvanc"
> -decklink_outdev_extralibs="-lstdc++"
> dshow_indev_deps="IBaseFilter"
> dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
> -lshlwapi"
> fbdev_indev_deps="linux_fb_h"
> @@ -4684,7 +4682,6 @@ msvc_common_flags(){
> -march=*) ;;
> -lz) echo zlib.lib ;;
> -lx264) echo libx264.lib ;;
> --lstdc++) ;;
> -l*) echo ${flag#-l}.lib ;;
> -LARGEADDRESSAWARE) echo $flag ;;
> -L*) echo -libpath:${flag#-L} ;;
Should probably keep this one, it may come from a pkg-config file or
some other source, and you don't want it forwarded to cl.exe
- Hendrik
___
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/3] avfilter/avfilter: Make functions only used here static
On Tue, Aug 1, 2023 at 5:05 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 44 +++---
> libavfilter/internal.h | 8
> 2 files changed, 24 insertions(+), 28 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index b8e1523bdb..df6f1ab3de 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -201,6 +201,17 @@ void avfilter_link_free(AVFilterLink **link)
> av_freep(link);
> }
>
> +static void update_link_current_pts(AVFilterLink *link, int64_t pts)
> +{
> +if (pts == AV_NOPTS_VALUE)
> +return;
> +link->current_pts = pts;
> +link->current_pts_us = av_rescale_q(pts, link->time_base,
> AV_TIME_BASE_Q);
> +/* TODO use duration */
> +if (link->graph && link->age_index >= 0)
> +ff_avfilter_graph_update_heap(link->graph, link);
> +}
> +
> void ff_filter_set_ready(AVFilterContext *filter, unsigned priority)
> {
> filter->ready = FFMAX(filter->ready, priority);
> @@ -232,13 +243,17 @@ void ff_avfilter_link_set_in_status(AVFilterLink *link,
> int status, int64_t pts)
> ff_filter_set_ready(link->dst, 200);
> }
>
> -void ff_avfilter_link_set_out_status(AVFilterLink *link, int status, int64_t
> pts)
> +/**
> + * Set the status field of a link from the destination filter.
> + * The pts should probably be left unset (AV_NOPTS_VALUE).
> + */
> +static void avfilter_link_set_out_status(AVFilterLink *link, int status,
> int64_t pts)
Having the function named avfilter_* seems slightly confusing, as
thats the public namespace of exported avfilter functions.
Its of course not going to show up in other files, being static and
all, but in the functions below that use it, a reader might get the
wrong idea about a function call.
Maybe just remove the avfilter prefix? It seems unnecessary here.
> {
> av_assert0(!link->frame_wanted_out);
> av_assert0(!link->status_out);
> link->status_out = status;
> if (pts != AV_NOPTS_VALUE)
> -ff_update_link_current_pts(link, pts);
> +update_link_current_pts(link, pts);
> filter_unblock(link->dst);
> ff_filter_set_ready(link->src, 200);
> }
> @@ -428,7 +443,7 @@ int ff_request_frame(AVFilterLink *link)
> /* Acknowledge status change. Filters using ff_request_frame()
> will
> handle the change automatically. Filters can also check the
> status directly but none do yet. */
> -ff_avfilter_link_set_out_status(link, link->status_in,
> link->status_in_pts);
> +avfilter_link_set_out_status(link, link->status_in,
> link->status_in_pts);
> return link->status_out;
> }
> }
> @@ -537,17 +552,6 @@ static int set_enable_expr(AVFilterContext *ctx, const
> char *expr)
> return 0;
> }
>
> -void ff_update_link_current_pts(AVFilterLink *link, int64_t pts)
> -{
> -if (pts == AV_NOPTS_VALUE)
> -return;
> -link->current_pts = pts;
> -link->current_pts_us = av_rescale_q(pts, link->time_base,
> AV_TIME_BASE_Q);
> -/* TODO use duration */
> -if (link->graph && link->age_index >= 0)
> -ff_avfilter_graph_update_heap(link->graph, link);
> -}
> -
> int avfilter_process_command(AVFilterContext *filter, const char *cmd, const
> char *arg, char *res, int res_len, int flags)
> {
> if(!strcmp(cmd, "ping")){
> @@ -1117,7 +1121,7 @@ static int ff_filter_frame_to_filter(AVFilterLink *link)
> link->frame_count_out--;
> ret = ff_filter_frame_framed(link, frame);
> if (ret < 0 && ret != link->status_out) {
> -ff_avfilter_link_set_out_status(link, ret, AV_NOPTS_VALUE);
> +avfilter_link_set_out_status(link, ret, AV_NOPTS_VALUE);
> } else {
> /* Run once again, to see if several frames were available, or if
> the input status has also changed, or any other reason. */
> @@ -1147,7 +1151,7 @@ static int forward_status_change(AVFilterContext
> *filter, AVFilterLink *in)
> if (!progress) {
> /* Every output already closed: input no longer interesting
> (example: overlay in shortest mode, other input closed).
> */
> -ff_avfilter_link_set_out_status(in, in->status_in,
> in->status_in_pts);
> +avfilter_link_set_out_status(in, in->status_in,
> in->status_in_pts);
> return 0;
> }
> progress = 0;
> @@ -1249,7 +1253,7 @@ static int ff_filter_activate_default(AVFilterContext
> *filter)
> change is considered having already happened.
>
> It is set by the destination filter using
> - ff_avfilter_link_set_out_status().
> + avfilter_link_set_out_status().
>
> Filters are activated according to the ready field, set using the
> ff_filter_set_ready(). Eventually, a priority queue will be used.
> @@ -1339,7 +1343,7 @@ int
Re: [FFmpeg-devel] [PATCH v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 11:54 AM Hendrik Leppkes wrote: > > On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote: > > > > > > > > On Sat, 29 Jul 2023, Hendrik Leppkes wrote: > > > > > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > > >> > > >> read fourcc for video codec after VideoTagHeader read. > > >> passed as parameter to flv_same_video_codec. > > >> > > > > > > Add the same parameter to flv_set_video_codec, and then you can remove > > > the entire backwards seek and just read it and adjust the size like > > > all other parameters. > > > > As far as I see flv_set_video_codec should not read a binary fourcc in the > > first place when it is called from amf_parse_object. > > Yeah probably not, so moving it to a parameter would fix that as well, > and make the entire parsing flow less opaque. > In fact the actual value will carry the FourCC then, which is not handled at all. Definitely very broken here. - Hendrik ___ 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 v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote: > > > > On Sat, 29 Jul 2023, Hendrik Leppkes wrote: > > > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > >> > >> read fourcc for video codec after VideoTagHeader read. > >> passed as parameter to flv_same_video_codec. > >> > > > > Add the same parameter to flv_set_video_codec, and then you can remove > > the entire backwards seek and just read it and adjust the size like > > all other parameters. > > As far as I see flv_set_video_codec should not read a binary fourcc in the > first place when it is called from amf_parse_object. Yeah probably not, so moving it to a parameter would fix that as well, and make the entire parsing flow less opaque. - Hendrik ___ 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 v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > > read fourcc for video codec after VideoTagHeader read. > passed as parameter to flv_same_video_codec. > Add the same parameter to flv_set_video_codec, and then you can remove the entire backwards seek and just read it and adjust the size like all other parameters. - Hendrik ___ 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] avformat/flvdec: use avio operation instead of pb->buf_ptr use
On Thu, Jul 27, 2023 at 4:38 AM Steven Liu wrote:
>
> fix segfaults:
> READ of size 1 at 0x610003b7 thread T0
> #0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
> #1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
> #2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
> #3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
> #4 0x71d158 in avformat_find_stream_info
> ffmpeg/libavformat/demux.c:2634:15
> #5 0x4c821b in LLVMFuzzerTestOneInput
> ffmpeg/tools/target_dem_fuzzer.c:206:11
>
> Signed-off-by: Steven Liu
> ---
> libavformat/flvdec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 3fe21622f7..003e4d7691 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -313,8 +313,9 @@ static int flv_same_video_codec(AVFormatContext *s,
> AVCodecParameters *vpar, int
> return 1;
>
> if (flv->exheader) {
> -uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
> -uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
> codec_id_str[1] << 16 | codec_id_str[0] << 24;
> +int64_t pos = avio_tell(s->pb);
> +uint32_t codec_id = avio_rb32(s->pb);
> +avio_seek(s->pb, pos, SEEK_SET);
> switch(codec_id) {
> case MKBETAG('h', 'v', 'c', '1'):
> return vpar->codec_id == AV_CODEC_ID_HEVC;
You don't need to store the position, just do a relative seek
backwards by 4 bytes.
I would also recommend to include a call to ffio_ensure_seekback so it
works with streams.
eg. something like this:
ffio_ensure_seekback(s->pb, 4);
avio_rb32(s->pb);
avio_seek(s->pb, -4, SEEK_CUR);
Add appropriate error checking, in particular for ffio_ensure_seekback, etc.
- Hendrik
___
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] flvdec: fix size desync when reading timestamp offsets
The size offset was previously being accounted for in flv_set_video_codec for h264 and mpeg4, instead of being directly accounted for in the spot where its read, which desynced on HEVC streams. For clarity, move the size offset directly to the parsing, similar to how its done for all other header fields. --- libavformat/flvdec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c index a6a94a4021..3fe21622f7 100644 --- a/libavformat/flvdec.c +++ b/libavformat/flvdec.c @@ -407,11 +407,9 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream, case FLV_CODECID_H264: par->codec_id = AV_CODEC_ID_H264; vstreami->need_parsing = AVSTREAM_PARSE_HEADERS; -ret = 3; // not 4, reading packet type will consume one byte break; case FLV_CODECID_MPEG4: par->codec_id = AV_CODEC_ID_MPEG4; -ret = 3; break; default: avpriv_request_sample(s, "Video codec (%x)", flv_codecid); @@ -1321,6 +1319,7 @@ retry_duration: "invalid timestamps %"PRId64" %"PRId64"\n", dts, pts); dts = pts = AV_NOPTS_VALUE; } +size -= 3; } if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC || st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_HEVC || -- 2.40.1.windows.1 ___ 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 1/2] avutil/random_seed: add av_random()
On Tue, Jul 4, 2023 at 10:41 PM James Almer wrote:
>
> Uses the existing code for av_get_random_seed() to return a buffer with
> cryptographically secure random data, or an error if none could be generated.
>
> Signed-off-by: James Almer
> ---
> libavutil/random_seed.c | 54 -
> libavutil/random_seed.h | 12 +
> 2 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
> index 66dd504ef0..0ed8f89cc6 100644
> --- a/libavutil/random_seed.c
> +++ b/libavutil/random_seed.c
> @@ -46,20 +46,22 @@
> #define TEST 0
> #endif
>
> -static int read_random(uint32_t *dst, const char *file)
> -{
> #if HAVE_UNISTD_H
> +static int read_random(uint8_t *dst, size_t len, const char *file)
> +{
> int fd = avpriv_open(file, O_RDONLY);
> -int err = -1;
> +ssize_t err = -1;
>
> +if (len > SSIZE_MAX)
> +return -1;
> if (fd == -1)
> return -1;
> -err = read(fd, dst, sizeof(*dst));
> +err = read(fd, dst, len);
> close(fd);
> +if (err == -1)
> +return AVERROR(errno);
>
> -return err;
> -#else
> -return -1;
> +return err == len;
> #endif
> }
>
> @@ -118,29 +120,47 @@ static uint32_t get_generic_seed(void)
> return AV_RB32(digest) + AV_RB32(digest + 16);
> }
>
> -uint32_t av_get_random_seed(void)
> +int av_random(uint8_t* buf, size_t len)
> {
> -uint32_t seed;
> +int err = AVERROR_UNKNOWN;
>
> #if HAVE_BCRYPT
> BCRYPT_ALG_HANDLE algo_handle;
> NTSTATUS ret = BCryptOpenAlgorithmProvider(_handle,
> BCRYPT_RNG_ALGORITHM,
> MS_PRIMITIVE_PROVIDER, 0);
> if (BCRYPT_SUCCESS(ret)) {
> -NTSTATUS ret = BCryptGenRandom(algo_handle, (UCHAR*),
> sizeof(seed), 0);
> +NTSTATUS ret = BCryptGenRandom(algo_handle, (PUCHAR)buf, len, 0);
> BCryptCloseAlgorithmProvider(algo_handle, 0);
> if (BCRYPT_SUCCESS(ret))
> -return seed;
> +return 0;
> }
> #endif
>
> #if HAVE_ARC4RANDOM
> -return arc4random();
> +arc4random_buf(buf, len);
> +return 0;
> +#endif
> +
> +#if HAVE_UNISTD_H
> +err = read_random(buf, len, "/dev/urandom");
> +if (err == 1)
> +return 0;
> +err = read_random(buf, len, "/dev/random");
> +if (err == 1)
> +return 0;
> +if (err == 0)
> + err = AVERROR_UNKNOWN;
> #endif
>
> -if (read_random(, "/dev/urandom") == sizeof(seed))
> -return seed;
> -if (read_random(, "/dev/random") == sizeof(seed))
> -return seed;
> -return get_generic_seed();
> +return err;
> +}
> +
> +uint32_t av_get_random_seed(void)
> +{
> +uint32_t seed;
> +
> +if (av_random((uint8_t *), sizeof(seed)) < 0)
> +return get_generic_seed();
> +
> +return seed;
> }
> diff --git a/libavutil/random_seed.h b/libavutil/random_seed.h
> index 0462a048e0..ce982bb82f 100644
> --- a/libavutil/random_seed.h
> +++ b/libavutil/random_seed.h
> @@ -36,6 +36,18 @@
> */
> uint32_t av_get_random_seed(void);
>
> +/**
> + * Generate cryptographically secure random data, i.e. suitable for use as
> + * encryption keys and similar.
> + *
> + * @param buf buffer into which the random data will be written
> + * @param len size of buf in bytes
> + *
> + * @retval 0 success, and len bytes of random data was written into buf, or
> + * a negative AVERROR code if random data could not be generated.
> + */
> +int av_random(uint8_t* buf, size_t len);
av_random seems like a pretty generic name for something thats
requiring to be cryptographically secure and otherwise fail. I would
expect a more specific name for that purpose. There is plenty other
uses of randomness in multimedia, noise, dithering, etc, which don't
need crypto security. The function doesn't have to handle those, but
maybe it should be specific in what it does handle?
- Hendrik
___
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 5/5] avformat: add sdr support
On Sun, Jun 18, 2023 at 2:59 PM Lynne wrote: > > Jun 17, 2023, 20:37 by mich...@niedermayer.cc: > > > On Sat, Jun 17, 2023 at 08:08:11PM +0200, Paul B Mahol wrote: > > [...] > > > >> Which library handles compressed stuff? > >> > > > > For digital stuff like DAB/DVB/... > > > > sdrdemux in libavformat will demodulate, do error correction then return > > AVPacket > > with H.264 / Mpeg2 video or AAC or wahetever > > That then will get passed to libavcodec, same as with any other demuxer. > > > > This code is not written yet. There is just analog AM demodulation. I posted > > this patch as soon as the first usecase worked > > > > usecase was "listen to random AM radio stations in ffplay" :) > > and it can also grab all AM stations in a 10Mhz window and demodulate all > > (that 10mhz is what my hw and usb bandwidth can do max) > > > > I intend to add FM demodulation, because it seems a fun thing to try to do. > > > > someone will need to add DAB/DVB support, I would be happy if someone else > > comes forth to do that. If noone does ill think about if i want to do it > > or not once FM is done and once this is in git. > > > > The initial reaction from some was a bit spicy, so i need to think > > how much fun this is in FFmpeg. > > But one thing i can say for sure, is, if i cannot use this in ffplay > > then it makes no sense for me to put more time into it > > > > We could implement seeking to next/previous stations differently but > > it seems a bit like creating extra work for everyone. > > I mean a new API in sdrdemux then ffplay needs to support that and then > > other players would need to support it and so on. While really the > > seeking on a realtime input has no other use > > > > I like the new functionality, but I too think that libavformat > should just source the data from a device, and that libavfilter > should demodulate. And how do you deal with the prospect of future digital audio, outputting a compressed bitstream? - Hendrik ___ 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] avcodec: Align AVFrame memory to page size for access via Apple Metal
On Thu, Jun 15, 2023 at 4:16 AM Iskandar Safarov wrote:
>
> ---
> libavcodec/get_buffer.c | 52 -
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/get_buffer.c b/libavcodec/get_buffer.c
> index a04fd878de..b18af3be4a 100644
> --- a/libavcodec/get_buffer.c
> +++ b/libavcodec/get_buffer.c
> @@ -33,6 +33,11 @@
> #include "avcodec.h"
> #include "internal.h"
>
> +#if __APPLE__
> +#import
> +#import
> +#endif
> +
> typedef struct FramePool {
> /**
> * Pools for each data plane. For audio all the planes have the same
> size,
> @@ -81,6 +86,51 @@ static AVBufferRef *frame_pool_alloc(void)
> return buf;
> }
>
> +#if __APPLE__
> +/*
> +When compiling for Apple platform the frame buffer data pointers need to
> be
> +page-aligned for cases when in-place GPU processing may be required
> +
> https://developer.apple.com/documentation/metal/mtldevice/1433382-newbufferwithbytesnocopy
> + */
> +#define POOL_BUFFER_ALLOCZ aapl_buffer_allocz
> +
> +static void aapl_buffer_free(void *opaque, uint8_t *data)
> +{
> +vm_deallocate((vm_map_t) mach_task_self(), (vm_address_t)data,
> (size_t)opaque);
> +}
> +
> +static AVBufferRef *aapl_buffer_alloc(size_t size)
> +{
> +AVBufferRef *ret = NULL;
> +uint8_t*data = NULL;
> +
> +kern_return_t err;
> +err = vm_allocate( (vm_map_t) mach_task_self(),
> +(vm_address_t*) , size, VM_FLAGS_ANYWHERE);
> +if (err != KERN_SUCCESS || !data)
> +return NULL;
> +
> +ret = av_buffer_create(data, size, aapl_buffer_free, (void*)size, 0);
> +if (!ret)
> +free(data);
> +
> +return ret;
> +}
> +
> +static AVBufferRef *aapl_buffer_allocz(size_t size)
> +{
> +AVBufferRef *ret = aapl_buffer_alloc(size);
> +if (!ret)
> +return NULL;
> +
> +memset(ret->data, 0, size);
> +return ret;
> +}
> +
> +#else
> +#define POOL_BUFFER_ALLOCZ av_buffer_allocz
> +#endif
> +
> static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
> {
> FramePool *pool = avctx->internal->pool ?
> @@ -155,7 +205,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> pool->pools[i] = av_buffer_pool_init(size[i] + 16 +
> STRIDE_ALIGN - 1,
> CONFIG_MEMORY_POISONING
> ?
> NULL :
> -av_buffer_allocz);
> +POOL_BUFFER_ALLOCZ);
> if (!pool->pools[i]) {
> ret = AVERROR(ENOMEM);
> goto fail;
> --
> 2.39.2 (Apple Git-143)
>
This is most definitely the wrong place to do this. Frames can be
allocated through various means and in various locations, and randomly
sprinkling new allocators all over is not how this should be
approached.
I don't believe FFmpeg itself shares this requirement, so maybe your
application should just use a custom get_buffer2 callback to fullfill
it?
If others agree that FFmpeg should create frames with this property by
default (which I can't answer without knowing if those special
allocation functions have any other downsides etc), it should be done
more centrally, rather then only in the avcodec pool.
- Hendrik
___
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/3] lavu/frame: add av_frame_get_buffer2
On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao wrote: > > From: Haihao Xiang > > Intel MediaSDK and oneVPL expect contiguous allocation for data[i], > however there are mandatory padding bytes between data[i] and data[i+1]. > when calling av_frame_get_buffer. So adding av_frame_get_buffer2 to > allow caller to specify the length of padding bytes. > get_video_buffer will also pad the height to a multiple of 32, won't that again cause issues? I don't think the API even necessarily guarantees that its going to be one contiguous buffer, it just happens to be the way its made right now. If a new API is introduced, maybe it should be very tailor designed to offer these guarantees, and named appropriate, not introducing any padding - padded height or extra padding, or otherwise. - Hendrik ___ 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] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
On Mon, May 15, 2023 at 1:30 PM Hendrik Leppkes wrote: > > Apparently mpeg4 and VDPAU have the same issue. I can test and fix > mpeg4, but do not have VDPAU setup, so .. untested commits incoming? > Tested and confirmed mpeg2 and mpeg4 are fixed for NVDEC, and elenril tested VDPAU with the same result. OK'ed by BtbN on IRC. Going to push later today. - Hendrik ___ 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 4/4] avcodec/vdpau_mpeg4: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/vdpau_mpeg4.c
index 6e082eefc6..1211b1df2c 100644
--- a/libavcodec/vdpau_mpeg4.c
+++ b/libavcodec/vdpau_mpeg4.c
@@ -74,8 +74,9 @@ static int vdpau_mpeg4_start_frame(AVCodecContext *avctx,
info->alternate_vertical_scan_flag = s->alternate_scan;
info->top_field_first = s->top_field_first;
for (i = 0; i < 64; ++i) {
-info->intra_quantizer_matrix[i] = s->intra_matrix[i];
-info->non_intra_quantizer_matrix[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+info->intra_quantizer_matrix[i] = s->intra_matrix[n];
+info->non_intra_quantizer_matrix[i] = s->inter_matrix[n];
}
ff_vdpau_common_start_frame(pic_ctx, buffer, size);
--
2.40.1.windows.1
___
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 3/4] avcodec/vdpau_mpeg12: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
index 354239cad5..79007aa1a8 100644
--- a/libavcodec/vdpau_mpeg12.c
+++ b/libavcodec/vdpau_mpeg12.c
@@ -75,8 +75,9 @@ static int vdpau_mpeg_start_frame(AVCodecContext *avctx,
info->f_code[1][0] = s->mpeg_f_code[1][0];
info->f_code[1][1] = s->mpeg_f_code[1][1];
for (i = 0; i < 64; ++i) {
-info->intra_quantizer_matrix[i] = s->intra_matrix[i];
-info->non_intra_quantizer_matrix[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+info->intra_quantizer_matrix[i] = s->intra_matrix[n];
+info->non_intra_quantizer_matrix[i] = s->inter_matrix[n];
}
return ff_vdpau_common_start_frame(pic_ctx, buffer, size);
--
2.40.1.windows.1
___
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/4] avcodec/nvdec_mpeg4: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
index eac138cc38..c193f6b6e4 100644
--- a/libavcodec/nvdec_mpeg4.c
+++ b/libavcodec/nvdec_mpeg4.c
@@ -88,8 +88,9 @@ static int nvdec_mpeg4_start_frame(AVCodecContext *avctx,
const uint8_t *buffer,
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
// We need to pass the full frame buffer and not just the slice
--
2.40.1.windows.1
___
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 1/4] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index e10735587d..3b9ff60734 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
const uint8_t *buffer
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
return 0;
--
2.40.1.windows.1
___
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] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
On Mon, May 15, 2023 at 12:51 PM Hendrik Leppkes wrote:
>
> mpeg2dec stores them permutated for the IDCT, nvdec expects them in
> plain raster order.
> ---
> libavcodec/nvdec_mpeg12.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
> index e10735587d..3b9ff60734 100644
> --- a/libavcodec/nvdec_mpeg12.c
> +++ b/libavcodec/nvdec_mpeg12.c
> @@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
> const uint8_t *buffer
> };
>
> for (i = 0; i < 64; ++i) {
> -ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
> -ppc->QuantMatrixInter[i] = s->inter_matrix[i];
> +int n = s->idsp.idct_permutation[i];
> +ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
> +ppc->QuantMatrixInter[i] = s->inter_matrix[n];
> }
>
> return 0;
> --
> 2.40.1.windows.1
>
Apparently mpeg4 and VDPAU have the same issue. I can test and fix
mpeg4, but do not have VDPAU setup, so .. untested commits incoming?
- Hendrik
___
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/nvdec_mpeg2: fix order of quant matrix coefficients
mpeg2dec stores them permutated for the IDCT, nvdec expects them in
plain raster order.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index e10735587d..3b9ff60734 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
const uint8_t *buffer
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
return 0;
--
2.40.1.windows.1
___
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] lavc/qsv: fallback to the default mfx implementation for internal session on Windows
On Mon, May 15, 2023 at 8:04 AM Xiang, Haihao wrote: > > From: Haihao Xiang > > The mfx implementation based on D3D11 is expected for an internal > session on Windows, however sometimes this implemntation is not > supported [1]. A fallback to the default mfx implementation is added in > this patch. > > [1] https://github.com/intel/cartwheel-ffmpeg/issues/246 > From the issue description, the user is trying to use it a as software library, not a hardware one? I don't think software fallback, especially an automatic one, is really quite appropriate. When someone requests a "qsv" encoder, they expect hardware. - Hendrik ___ 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] lavfi/vf_libplacebo: add vulkan device import fallback
On Thu, May 11, 2023 at 11:32 AM Lynne wrote: > > May 11, 2023, 10:39 by ffm...@haasn.xyz: > > > From: Niklas Haas > > > > Recent versions of libplacebo have required Vulkan versions incompatible > > with lavu Vulkan hwcontexts. While this is expected to change > > eventually, breaking vf_libplacebo every time there is such a transition > > period is obviously undesired behavior, as the following sea of bug > > reports shows. > > > > This commit adds a fallback path for pl_vulkan_import failures which > > simply creates an internal device instead. Also useful when no interop > > with lavu vulkan hwframes is needed or desired. > > > > Fixes: https://github.com/haasn/libplacebo/issues/170 > > Fixes: https://github.com/mpv-player/mpv/issues/9589#issuecomment-1535432185 > > Fixes: https://code.videolan.org/videolan/libplacebo/-/issues/270 > > > > NAK. The whole point of the hwcontext infrastructure is to be > explicit, and creating a new device behind the scenes is anything but that. > > This is not a native vulkan filter, it is an external library not married to our vulkan infrastructure - it merely has compatibility for it. Ensuring it works, as it might have separate requirements or a different development cycle, is hardly a bad thing. And it greatly simplifies the usability for users that only want a quick GPU processing. - Hendrik ___ 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] av_mallocz_array
On Thu, May 4, 2023 at 11:06 AM Christophe GARNIER
wrote:
>
> Hello,
>
> To build makemkv version 1.17.3 (makemkv-oss), I retreived he sources of
> ffmpeg from the git repository (git clone
> https://git.ffmpeg.org/ffmpeg.git ffmpeg).It appeared that the function
> av_mallocz_array is not present into libavutil/mem.c and libavutil/mem.h.
>
> I had the following code into libavutil/mem.c :
>
> void *av_mallocz_array(size_t nmemb, size_t size)
> {
> size_t result;
> if (size_mult(nmemb, size, ) < 0)
> return NULL;
> return av_mallocz(result);
> }
>
> and into libavutil/mem.h :
>
> /**
> * Allocate a memory block for an array with av_mallocz().
> *
> * The allocated memory will have size `size * nmemb` bytes.
> *
> * @param nmemb Number of elements
> * @param size Size of the single element
> * @return Pointer to the allocated block, or `NULL` if the block cannot
> * be allocated
> *
> * @see av_mallocz()
> * @see av_malloc_array()
> */
> av_alloc_size(1, 2) void *av_mallocz_array(size_t nmemb, size_t size);
>
> After these modifications, I have been able to generate makemkv-oss.
>
>
av_mallocz_array has been deprecated over 2 years ago and removed in
the latest version. The replacement is av_calloc.
The code you are trying to compile needs to be updated for the latest
version of FFmpeg, not the function returned.
- Hendrik
___
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] [RFC] avformat: Add basic same origin check
On Wed, May 3, 2023 at 12:49 PM Michael Niedermayer
wrote:
>
> On Wed, May 03, 2023 at 12:05:54PM +0200, Hendrik Leppkes wrote:
> > On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> > > >
> > > > added
> > > > +{"same_none" , "same origin check off" , 0 ,
> > > > AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX,
> > > > D|E, "same_origin"},
> > >
> > > "none" sounds more natural.
> > >
> > > >
> > > >
> > > >> And do we want check_path to be default? It's a change
> > > >> in behavior.
> > > >
> > > > is it usefull if its not enabled by default ?
> > >
> > > It is, since it can be enabled, like the whitelists and blacklists, but
> > > the question is if it's preferable to have it enabled. If you consider
> > > it so, then it's good and i wont oppose it.
> > >
> >
> > Is there any estimation how many legitimate streams would be broken by
> > these options?
> > If any major streams don't work with this, then its not a good option,
> > and eg. library users will likely just turn it off or to a lower
> > setting, as proper streams just have to work - and log output is
> > pretty much useless for API usage cases.
> >
> > A quick check for example shows that even something as simple as the
> > HLS BBC Radio streams will fail _all_ checks, since the playlists are
> > hosted on another host entirely as the media, thanks to akamai live
> > streaming.
> > Playlist here, as an example:
> > http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
>
> yes, thats why it says RFC in the subject, i had expected that a bit already
>
> still OTOH, blocking these by default is the safer option, i mean if a user
> does a
> ./ffplay http://trustedfoobar.org/cutevideo.avi
>
> would she expect that video to access http://127.0.0.1/ and later
> http://evilhost/localwebscan-success
> I think this should not be possible by default settings, its unexpected
>
Coming from the other side -- If the user needs to set the flag for
nearly all streams, then they are not going to check in the future and
just set it, defeating the purpose of them. At which point we might as
well not burden them.
- Hendrik
___
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] [RFC] avformat: Add basic same origin check
On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> >
> > added
> > +{"same_none" , "same origin check off" , 0 ,
> > AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX,
> > D|E, "same_origin"},
>
> "none" sounds more natural.
>
> >
> >
> >> And do we want check_path to be default? It's a change
> >> in behavior.
> >
> > is it usefull if its not enabled by default ?
>
> It is, since it can be enabled, like the whitelists and blacklists, but
> the question is if it's preferable to have it enabled. If you consider
> it so, then it's good and i wont oppose it.
>
Is there any estimation how many legitimate streams would be broken by
these options?
If any major streams don't work with this, then its not a good option,
and eg. library users will likely just turn it off or to a lower
setting, as proper streams just have to work - and log output is
pretty much useless for API usage cases.
A quick check for example shows that even something as simple as the
HLS BBC Radio streams will fail _all_ checks, since the playlists are
hosted on another host entirely as the media, thanks to akamai live
streaming.
Playlist here, as an example:
http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
- Hendrik
___
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] lavu/avassert: include config.h
On Wed, Apr 26, 2023 at 2:32 PM Nicolas George wrote: > > Fix setting the assert level. > > Signed-off-by: Nicolas George > --- > libavutil/avassert.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavutil/avassert.h b/libavutil/avassert.h > index 51e462bbae..8f3f72c80c 100644 > --- a/libavutil/avassert.h > +++ b/libavutil/avassert.h > @@ -28,6 +28,7 @@ > #define AVUTIL_AVASSERT_H > > #include > +#include "config.h" > #include "log.h" > #include "macros.h" > This is an installed header, it cannot depend on config.h - Hendrik ___ 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] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Fri, Mar 10, 2023 at 3:18 AM Marth64 wrote: > > Hi, > > If there is still interest I can refine this to match the latest ffmpeg > branch. Thank you! > > Your patches have already been merged to git master. - Hendrik ___ 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] PRIx64 and msvc
On Wed, Mar 8, 2023 at 5:34 PM wrote: > > Le 2023-03-08 09:10, Hendrik Leppkes a écrit : > > On Wed, Mar 8, 2023 at 4:02 PM wrote: > >> > >> I'm compiling with msvc and get some errors with PRIx64 and similars. > >> For example: > >> snprintf(name, sizeof(name), "0x%"PRIx64, ch_layout); > >> > >> won't compile, but this work (with the extra space): > >> snprintf(name, sizeof(name), "0x%" PRIx64, ch_layout); > >> > >> Can this be included in the sources without introducing problems for > >> other platforms? > > > > You'll have to provide more information. We have automated builds with > > MSVC which are running just fine right now. > > > > - Hendrik > > ___ > > 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". > > For example, in ffplay.c sample (ffmpeg version 5.0.2): > > if (is->audio_filter_src.channel_layout) > snprintf(asrc_args + ret, sizeof(asrc_args) - ret, > ":channel_layout=0x%"PRIx64, > is->audio_filter_src.channel_layout); > > gives the following error: > error C3688: invalid literal suffix 'PRIx64'; literal operator or > literal operator template 'operator ""PRIx64' not found > > The error is gone when adding a space before PRIx64. > > Note that I'm mixing C and C++ in my projet. Compiling in plain C seems > to work. This is C code, it has to be compiled as C. You can set this for every individual file in MSVC if you have to. We cannot support modifications or custom projects, of course. - Hendrik ___ 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] PRIx64 and msvc
On Wed, Mar 8, 2023 at 4:02 PM wrote: > > I'm compiling with msvc and get some errors with PRIx64 and similars. > For example: > snprintf(name, sizeof(name), "0x%"PRIx64, ch_layout); > > won't compile, but this work (with the extra space): > snprintf(name, sizeof(name), "0x%" PRIx64, ch_layout); > > Can this be included in the sources without introducing problems for > other platforms? You'll have to provide more information. We have automated builds with MSVC which are running just fine right now. - Hendrik ___ 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] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding
On Fri, Dec 23, 2022 at 7:01 PM Wu Jianhua wrote: > > [PATCH v2] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 > decoding > > Patches attached. > The naming scheme on this seems to be rather inconsistent. Both "d3d12dec" and "d3d12va" seem to be used in different places - please standardize it all on "d3d12va", it matches d3d11va and remains consistent with itself. Additionally, why are you not supporting all codecs that D3D11 supports? Are there any limitations on what it supports, for some reason? - Hendrik ___ 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 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 8:43 PM Marth64 wrote: > > Signed-off-by: Marth64 The entire set looks good to me now. If there are no further objections or comments, I'll apply it in a day or two. - Hendrik ___ 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] Fix broken build on Android due to broken asm-generic/termbits.h include
On Thu, Feb 23, 2023 at 3:37 PM copypaste wrote: > It gets included because this platform does indeed have Video4Linux so some > of the aarch64 stuff is relevant. Furthermore I think that the HEVC stuff > includes it. > If its relevant for V4L or other hardware integration is fine and all ... but the real question is, how does it end up in aaccoder.c and other files entirely unrelated to video or hardware? And can we just get it out of those? - Hendrik ___ 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] Chromium 110 and ffmpeg 5.1.2
On Wed, Feb 22, 2023 at 9:42 PM Drew Abbott wrote: > > Hello, > > I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of > the errors I get while building has to do with the API for accessing > first_dts. It looks like previously it was just a member of AVStream, > but now it can only be accessed with av_stream_get_first_dts: > https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd > I can see now first_dts is a member of FFStream, but I don't know how > to go from an AVStream to an FFStream without using internals of > libavformat, if that is even possible. How was first_dts accessed in > 5.1.2 from an AVStream? Chrome hacks their ffmpeg rather then fixing their code. You can't build it with anything but their canned version. - Hendrik ___ 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 00/72] Implement support for Vulkan multiplane images and video decoding
On Mon, Feb 20, 2023 at 12:50 AM Neal Gompa wrote: > > On Sun, Feb 19, 2023 at 5:00 PM Kieran Kunhya wrote: > > > > On Sun, 19 Feb 2023 at 18:46, Lynne wrote: > > > > > Feb 19, 2023, 18:43 by kier...@obe.tv: > > > > > > > On Sun, 19 Feb 2023 at 17:36, Kieran Kunhya wrote: > > > > > > > >> Obviously, if we merge it now, and big enough issues are found > > > >> > > > >>> which we couldn't fix immediately, I'd have no problem reverting > > > >>> the Vulkan patches from the 6.0 branch. > > > >>> > > > >> > > > >> > > > >> A major LTS release is not your development sandbox. > > > >> > > > >> Kieran > > > >> > > > > > > > > Correction, 6.0 is not an LTS. Nonetheless, it's not your sandbox. > > > > > > > > > > If new features don't go in, the project dies. > > > Everyone but seems to dislike new features. > > > > > > > Sure, then put your features in early in the dev cycle, not days before a > > major release. > > > > This is not a reasonable response, especially to someone who is > volunteering their time to develop features for a project. If it > misses 6.0, it sucks. > I think its quite reasonable to think of the stability and quality of the release. If a feature is rushed into a release and you get a buggy version of it in 6.0, that also sucks - in fact it may suck more for those people that were using those features this is going to replace. - Hendrik ___ 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 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 6:50 PM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> - Missed adding the profiles to actual codec descriptor in ac3dec_float
> - Formatting tidyness
>
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/ac3dec_float.c | 2 ++
> libavcodec/avcodec.h | 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/eac3dec.c | 11 ++-
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 8 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index 0b120e6140..b5f4b166d3 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1714,6 +1714,9 @@ skip:
> if (!err) {
> avctx->sample_rate = s->sample_rate;
> avctx->bit_rate= s->bit_rate + s->prev_bit_rate;
> +
> +if (s->eac3_extension_type_a == 1)
> +avctx->profile = s->eac3_extension_type_a == 1 ?
> FF_PROFILE_EAC3_DDP_ATMOS : FF_PROFILE_UNKNOWN;
> }
You have to leave out the if(..) for this to make sense. :)
___
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 2/4] avcodec/mlpdec: add detection of Atmos spatial extension profile in TrueHD
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/mlpdec.c | 11 +++
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 5 files changed, 20 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 0e85dd50a4..3feab75741 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1593,6 +1593,8 @@ typedef struct AVCodecContext {
>
> #define FF_PROFILE_EAC3_DDP_ATMOS 30
>
> +#define FF_PROFILE_TRUEHD_ATMOS 30
> +
> #define FF_PROFILE_MPEG2_4220
> #define FF_PROFILE_MPEG2_HIGH 1
> #define FF_PROFILE_MPEG2_SS 2
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 4098d4f5a5..e80ac07700 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2960,6 +2960,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .name = "truehd",
> .long_name = NULL_IF_CONFIG_SMALL("TrueHD"),
> .props = AV_CODEC_PROP_LOSSLESS,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_truehd_profiles),
> },
> {
> .id= AV_CODEC_ID_MP4ALS,
> diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
> index 0ee1f0982c..85d6207b9c 100644
> --- a/libavcodec/mlpdec.c
> +++ b/libavcodec/mlpdec.c
> @@ -42,6 +42,7 @@
> #include "mlpdsp.h"
> #include "mlp.h"
> #include "config.h"
> +#include "profiles.h"
>
> /** number of bits used for VLC lookup - longest Huffman code is 9 */
> #if ARCH_ARM
> @@ -392,6 +393,15 @@ static int read_major_sync(MLPDecodeContext *m,
> GetBitContext *gb)
> m->num_substreams= mh.num_substreams;
> m->substream_info= mh.substream_info;
>
> +/* If there is a 4th substream and the MSB of substream_info is set,
> + * there is a 16-channel spatial presentation (Atmos in TrueHD).
> + */
> +if (m->avctx->codec_id == AV_CODEC_ID_TRUEHD
> +&& m->num_substreams == 4
> +&& m->substream_info >> 7 == 1) {
> +m->avctx->profile = FF_PROFILE_TRUEHD_ATMOS;
> +}
> +
Nit: maybe put the if into two lines instead of three? The two
substream checks look like they should fit in one line quite well. But
this is just a style question, so feel free to ignore.
Otherwise LGTM
___
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 3/4] avcodec/dca_xll: add detection of DTS:X and DTS:X IMAX
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- > libavcodec/avcodec.h | 15 +-- > libavcodec/dca_syncwords.h | 3 +++ > libavcodec/dca_xll.c | 26 +- > libavcodec/dca_xll.h | 3 +++ > libavcodec/profiles.c | 14 -- > 5 files changed, 48 insertions(+), 13 deletions(-) > LGTM ___ 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 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- Another thing I noticed, you should add the profiles to the eac3 decoder AVCodec in ac3_float.c ___ 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 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/eac3dec.c| 11 ++-
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 7 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index 0b120e6140..8cede139b8 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1714,6 +1714,9 @@ skip:
> if (!err) {
> avctx->sample_rate = s->sample_rate;
> avctx->bit_rate= s->bit_rate + s->prev_bit_rate;
> +
> +if (s->eac3_extension_type_a == 1)
> +avctx->profile = FF_PROFILE_EAC3_DDP_ATMOS;
> }
This should probably be something like:
avctx->profile = s->eac3_extension_type_a == 1 ?
FF_PROFILE_EAC3_DDP_ATMOS : FF_PROFILE_UNKNOWN;
This way the profile is properly reset when there is no extension (anymore).
>
> if (!avctx->sample_rate) {
> diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
> index 138b462abb..0829f4b40d 100644
> --- a/libavcodec/ac3dec.h
> +++ b/libavcodec/ac3dec.h
> @@ -102,6 +102,7 @@ typedef struct AC3DecodeContext {
> int eac3; ///< indicates if current frame
> is E-AC-3
> int eac3_frame_dependent_found; ///< bitstream has E-AC-3
> dependent frame(s)
> int eac3_subsbtreamid_found;///< bitstream has E-AC-3
> additional substream(s)
> +int eac3_extension_type_a; ///< bitstream has E-AC-3
> extension type A enabled frame(s)
> int dolby_surround_mode;///< dolby surround mode
>(dsurmod)
> int dolby_surround_ex_mode; ///< dolby surround ex mode
>(dsurexmod)
> int dolby_headphone_mode; ///< dolby headphone mode
>(dheadphonmod)
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 39881a1d2b..0e85dd50a4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1591,6 +1591,8 @@ typedef struct AVCodecContext {
> #define FF_PROFILE_DTS_HD_MA 60
> #define FF_PROFILE_DTS_EXPRESS 70
>
> +#define FF_PROFILE_EAC3_DDP_ATMOS 30
> +
> #define FF_PROFILE_MPEG2_4220
> #define FF_PROFILE_MPEG2_HIGH 1
> #define FF_PROFILE_MPEG2_SS 2
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 199f62df15..4098d4f5a5 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2931,6 +2931,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .name = "eac3",
> .long_name = NULL_IF_CONFIG_SMALL("ATSC A/52B (AC-3, E-AC-3)"),
> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_eac3_profiles),
> },
> {
> .id= AV_CODEC_ID_SIPR,
> diff --git a/libavcodec/eac3dec.c b/libavcodec/eac3dec.c
> index deca51dd3d..5c71751a0c 100644
> --- a/libavcodec/eac3dec.c
> +++ b/libavcodec/eac3dec.c
> @@ -464,7 +464,16 @@ static int ff_eac3_parse_header(AC3DecodeContext *s)
> if (get_bits1(gbc)) {
> int addbsil = get_bits(gbc, 6);
> for (i = 0; i < addbsil + 1; i++) {
> -skip_bits(gbc, 8); // skip additional bit stream info
> +if (i == 0) {
> +/* In this 8 bit chunk, the LSB is equal to
> flag_ec3_extension_type_a
> + which can be used to detect Atmos presence */
> +skip_bits(gbc, 7);
> +if (get_bits1(gbc)) {
> +s->eac3_extension_type_a = 1;
> +}
> +} else {
> +skip_bits(gbc, 8); // skip additional bit stream info
> +}
> }
> }
>
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 7af7fbeb13..343b08f363 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -45,6 +45,11 @@ const AVProfile ff_dca_profiles[] = {
> { FF_PROFILE_UNKNOWN },
> };
>
> +const AVProfile ff_eac3_profiles[] = {
> + { FF_PROFILE_EAC3_DDP_ATMOS, "Dolby Digital Plus + Dolby Atmos"},
> + { FF_PROFILE_UNKNOWN },
> +};
> +
> const AVProfile ff_dnxhd_profiles[] = {
>{ FF_PROFILE_DNXHD, "DNXHD"},
>{ FF_PROFILE_DNXHR_LB, "DNXHR LB"},
> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> index 41a19aa9ad..6ebedbd03f 100644
> --- a/libavcodec/profiles.h
> +++ b/libavcodec/profiles.h
> @@ -58,6 +58,7 @@
>
> extern const AVProfile ff_aac_profiles[];
> extern const AVProfile ff_dca_profiles[];
> +extern const AVProfile ff_eac3_profiles[];
> extern const AVProfile ff_dnxhd_profiles[];
> extern const AVProfile ff_h264_profiles[];
> extern const AVProfile ff_hevc_profiles[];
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
>
Re: [FFmpeg-devel] [PATCH] lavc: deprecate avcodec_dct, av_fft, av_dct, av_rdft and av_mdct
On Fri, Feb 17, 2023 at 7:45 PM Lynne wrote: > > Feb 17, 2023, 18:08 by jamr...@gmail.com: > > > On 2/17/2023 1:54 PM, Lynne wrote: > > > >> This reverts commit 26cb36f35746fe6ef53688b119852bfa6d555f62. > >> > >> All filters and all codecs (except wmavoice) have been ported for the > >> lavu/tx API. > >> > >> The noise should be minimal. > >> > > > > It isn't. I'm getting more than two thousand lines of warnings after > > applying this patch from > > > > libavfilter/vf_spp.c > > libavfilter/x86/vf_spp.c > > libavcodec/asvenc.c > > libavcodec/avdct.c > > libavcodec/avfft.c > > libavcodec/dct.c > > libavcodec/fdctdsp.c > > libavcodec/fft_float.c > > libavcodec/fft_init_table.c > > libavcodec/idctdsp.c > > libavcodec/jfdctfst.c > > libavcodec/jfdctint.c > > libavcodec/jrevdct.c > > libavcodec/mpegaudiodsp.c > > libavcodec/mpegvideo_enc.c > > libavcodec/rdft.c > > libavcodec/wmavoice.c > > libavcodec/x86/dct_init.c > > libavcodec/x86/fft_init.c > > libavcodec/x86/mpegvideoenc.c > > > > It's not just wmavoice, there's also mpeg and jpeg stuff, and one filter. > > For the actual fft/dct/rdft/mdct source files, you should use the > > deprecation warning pragmas to silence them, but the other modules need to > > be ported. > > This patch is also missing the schedule FF_API deprecation wrapper. > > > > Is the noise acceptable if I just deprecate the functions? > It wasn't before, but it should be much less now. An API we still use internally doesn't seem very deprecated to me. Should get rid of it, then there won't be any warnings. - Hendrik ___ 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 00/72] Implement support for Vulkan multiplane images and video decoding
On Fri, Feb 17, 2023 at 10:09 AM Jean-Baptiste Kempf wrote: > > Hello, > > On Fri, 17 Feb 2023, at 04:43, Lynne wrote: > > This small patchset mostly rewrites Vulkan to enable using multiplane > > images, > > This is not small. We're talking about thousands of lines of code; > > And this changes numerous h264 and hevc headers, and adds callback to the > make AVHWAccel. > > And that is besides the full rewrite of some Vulkan files... > > This will take a long time to review. > I would agree, this set is too large to try to skirt it in just under the deadline of a new release, with the potential of needing to fix stuff later. Just have it land on master after the branch, and there is no time pressure to review it, or make numerous fixes on the release branch. PS: Can you please send it as a proper patchset? Reviewing 72 patches off of one mail is not really fitting the workflow at all. - Hendrik ___ 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] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Sun, Feb 12, 2023 at 1:53 AM Marth64 wrote:
> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> index 4d2cd5f56d..200702f89e 100644
> --- a/libavcodec/dca_syncwords.h
> +++ b/libavcodec/dca_syncwords.h
> @@ -33,4 +33,7 @@
> #defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U
> #defineDCA_SYNCWORD_REV1AUX 0x9A1105A0U
>
> +#defineDCA_SYNCWORD_XLL_X0x00020008U
> +#defineDCA_SYNCWORD_XLL_X_IMAX 0x00F14000U
> +
> #endif /* AVCODEC_DCA_SYNCWORDS_H */
> diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> index fe2c766d98..efbbae67f8 100644
> --- a/libavcodec/dca_xll.c
> +++ b/libavcodec/dca_xll.c
> @@ -19,6 +19,7 @@
> */
>
> #include "libavutil/channel_layout.h"
> +#include "avcodec.h"
> #include "dcadec.h"
> #include "dcadata.h"
> #include "dcamath.h"
> @@ -1043,6 +1044,7 @@ static int parse_band_data(DCAXllDecoder *s)
> static int parse_frame(DCAXllDecoder *s, const uint8_t *data, int size,
> DCAExssAsset *asset)
> {
> int ret;
> +int extradata_peek_pos;
>
> if ((ret = init_get_bits8(>gb, data, size)) < 0)
> return ret;
> @@ -1054,10 +1056,23 @@ static int parse_frame(DCAXllDecoder *s, const
> uint8_t *data, int size, DCAExssA
> return ret;
> if ((ret = parse_band_data(s)) < 0)
> return ret;
> +
> +extradata_peek_pos = (get_bits_count(>gb) + 31) & ~31;
> +if (s->frame_size * 8 > extradata_peek_pos) {
> +unsigned int extradata_syncword = show_bits_long(>gb, 32);
> +
> +if (extradata_syncword == DCA_SYNCWORD_XLL_X) {
> +s->x_syncword_present = 1;
> +} else if (extradata_syncword == DCA_SYNCWORD_XLL_X_IMAX) {
> +s->x_imax_syncword_present = 1;
> +}
> +}
> +
I was testing this, and the DTS detections were not very reliable for
me. This is what I came up with instead:
#defineDCA_SYNCWORD_XLL_X0x02000850U
#defineDCA_SYNCWORD_XLL_X_IMAX 0xF14000D0U
if (s->frame_size * 8 > FFALIGN(get_bits_count(>gb), 32)) {
unsigned int extradata_syncword;
// align to dword
skip_bits_long(>gb, -get_bits_count(>gb) & 31);
// get sync code
extradata_syncword = show_bits_long(>gb, 32);
if (extradata_syncword == DCA_SYNCWORD_XLL_X) {
s->x_syncword_present = 1;
} else if ((extradata_syncword >> 1) ==
(DCA_SYNCWORD_XLL_X_IMAX >> 1)) {
s->x_imax_syncword_present = 1;
}
}
I don't have many DTS:X discs, but this worked on them, the old code did not.
Aligning to DWORD for a new section is a typical DTS thing to do,
which then also resulted in the syncwords to shift a bit, and actually
include more digits.
The IMAX case is a bit weird, there seems to be an extra bit in there
thats not stable, so shifting it out improves the detection (or it
could be masked out, but same difference).
- Hendrik
___
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] mswindres: Use '-' instead of '/' for rc.exe options
On Thu, Feb 9, 2023 at 10:02 PM Ziemowit Laski wrote: > > > FWIW, this setup is definitely being used by lots of others already - so > > whenever there's such an issue, the main question to ask is why others > > haven't run into the issue before. But improvements are definitely > > welcome! > > You have to have PATH set up so that rc.exe is found inside the Windows SDK. > This is NOT the default behavior. Usually, you would have to invoke the > 'Developer Command Prompt' from the start menu to get the correct environment. > > But I have my system set up so that the Microsoft tools are ALWAYS found, > regardless of which shell you are running. That could explain the different > behavior that I'm seeing. > > > You should probably talk about the option '/nologo' here, there's no > > '/logo' option afaik. > > Yes, good catch, thanks. > > > These changes seem fine, but you're apparently not touching the case at > > the top, used for --version, where it is calling 'rc.exe /?'. For me, this > > That's an interesting point. I guess MinGW is "smart enough" not to rewrite > "/?" because it doesn't represent a valid path to begin with. I will change > it to "-?" as you suggest. > You would think so, but attempting to run rc.exe /? straight from a msys bash prompt over here does come up with an invalid file error, so definitely better to fix it. - Hendrik ___ 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] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Thu, Feb 9, 2023 at 5:42 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- > Adds detection of spatial/object-based audio extensions in E-AC-3, > TrueHD, and DCA XLL (DTS). This includes Atmos, DTS:X, and IMAX formats. > Please let me know what I could improve, I'm learning still. > Thank you. > The detection itself seems fine to me, however we should talk about how the presence is communicated back to the user. A new flag in AVCodecContext goes against a variety of designs we try to avoid - namely having codec-specific things in a global struct, as well as having only one value, rather then per-frame values. So options that present themself to me: (a) Use "profile". At least for DTS that would fit quite nicely, as it already has profiles, and it seems like a logical extension. TrueHD and eac3 do not have profiles, but it might still be sensible to put it there. The advantage here is that it also automatically is conveyed in AVCodecParameters after avformat opens a stream, so the information is available early and lets players decide how to handle the stream. (b) Use per-frame side data. The early-availability advantage is not present here, so its not my favorite. side-data could be used in the future to transport the actual object metadata, if needed. So from where I'm standing we should maybe define profiles to use for these. In the past profiles were at least suggested for TrueHD Atmos before, but there were some objections, so maybe a good time to revisit and see where we go from here. - Hendrik ___ 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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, Feb 8, 2023 at 2:08 PM Jean-Baptiste Kempf wrote: > > On Wed, 8 Feb 2023, at 10:47, Le Bao Tin Ha wrote: > > Hello, you can found the explanation here: > > > > https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html > > > > "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FMT_NV12M but stores > > pixels in 2D 8x128 tiles, and stores tiles linearly in memory. The > > image height must be aligned to a multiple of 128. The layouts of the > > luma and chroma planes are identical. > > > > V4L2_PIX_FMT_NV12_8L128 is similar to V4L2_PIX_FMT_NV12M_8L128 but > > stores two planes in one memory." > > Do we really need those PIX_FMT in FFmpeg public API? > Tiled formats also really don't fit into our format definitions, and would not work with any generic pixel format handling code, as far as I can tell. - Hendrik ___ 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] configure: add --disable-he-aac option
On Wed, Feb 1, 2023 at 3:33 PM Kristofer Björkström wrote: > > From 6828ea418f0209dface9fbb23ff4657f66988f5e Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Kristofer=20Bj=C3=B6rkstr=C3=B6m?= > Date: Wed, 1 Feb 2023 15:15:14 +0100 > Subject: [PATCH] configure: add --disable-he-aac option > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Make it possible to disable HE and HEv2 support for AAC. To avoid > patents in HE-AAC. > I don't feel like this adds a good precedence to our codebase. We generally ignore patents, because every codec is littered with them. Having options to cherry-pick which patents are enabled and which are not is not only very ugly, but also impossible to track or make any guarantees on, so I think we should not even start. - Hendrik ___ 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 00/26] Major library version bump
On Sat, Jan 21, 2023 at 10:30 PM Marvin Scholz wrote: > > Or do you mean that there should be a public devel branch where API/ABI > breaking patches can be proposed for that will eventually be merged into > master at a defined point in time together with major bump? > Yes, I'm talking about one centrally managed branch that contributors can merge their breaking changes to, and we can test it all in one piece, and then when the time comes, that one branch would get merged into master. - Hendrik ___ 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 00/26] Major library version bump
On Sat, Jan 21, 2023 at 8:33 PM Marvin Scholz wrote: > > > > Alternatively, we could just not have an instability period at all. > > > > Not having any instability period at all seems like a bad idea. > Actually that sounds like the best idea. You would just have to prepare the bump in a branch and all unstable changes ready to merge in an instant. Miss it? Tough. Having months long periods so people can get their stuff sorted is way too long. Ideally it should be prepared ahead of time and only a "soft instability" period of maybe two weeks reserved for bug fixes (don't want to sit on issues for ever), rather then big changes or new features. - Hendrik ___ 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] avcodec: Use preprocessors conditions
On Tue, Jan 17, 2023 at 3:36 PM wrote:
>
> From: Pawday
>
> Thank you Andreas Rheinhardt for review
>
> Here the fixes for runtime "else" conditions
>
> ---
> libavcodec/avcodec.c | 16 +++-
> libavcodec/decode.c | 11 ---
> libavcodec/encode.c | 13 -
> libavcodec/h264dec.c | 14 +++---
> 4 files changed, 34 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index a85d3c2309..0e792aead9 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -403,10 +403,13 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
> av_frame_unref(avci->buffer_frame);
> av_packet_unref(avci->buffer_pkt);
>
> -if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
> +#if HAVE_THREADS
> +if (avctx->active_thread_type & FF_THREAD_FRAME)
> ff_thread_flush(avctx);
> -else if (ffcodec(avctx->codec)->flush)
> +#else
> +if (ffcodec(avctx->codec)->flush)
> ffcodec(avctx->codec)->flush(avctx);
> +#endif
> }
>
The before and after behavior are not identical. Just because threads
are supported does not imply they are always used.
> void avsubtitle_free(AVSubtitle *sub)
> @@ -441,12 +444,15 @@ av_cold int avcodec_close(AVCodecContext *avctx)
> if (avcodec_is_open(avctx)) {
> AVCodecInternal *avci = avctx->internal;
>
> -if (CONFIG_FRAME_THREAD_ENCODER &&
> -avci->frame_thread_encoder && avctx->thread_count > 1) {
> +#if CONFIG_FRAME_THREAD_ENCODER
> +if (avci->frame_thread_encoder && avctx->thread_count > 1) {
> ff_frame_thread_encoder_free(avctx);
> }
> -if (HAVE_THREADS && avci->thread_ctx)
> +#endif
> +#if HAVE_THREADS
> +if (avci->thread_ctx)
> ff_thread_free(avctx);
> +#endif
> if (avci->needs_close && ffcodec(avctx->codec)->close)
> ffcodec(avctx->codec)->close(avctx);
> avci->byte_buffer_size = 0;
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6be2d3d6ed..54ffd0f203 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -300,10 +300,14 @@ static inline int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame,
> return AVERROR_EOF;
>
> got_frame = 0;
> -
> -if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
> +#if HAVE_THREADS
> +if (avctx->active_thread_type & FF_THREAD_FRAME) {
> ret = ff_thread_decode_frame(avctx, frame, _frame, pkt);
> -} else {
> +}
> +#endif
> +
> +#if !HAVE_THREADS
> +if (!(avctx->active_thread_type & FF_THREAD_FRAME)) {
Same issue here. Threads are not always active even if supported.
> ret = codec->cb.decode(avctx, frame, _frame, pkt);
>
> if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
> @@ -321,6 +325,7 @@ static inline int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame,
> }
> }
> }
> +#endif
> emms_c();
> actual_got_frame = got_frame;
>
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index fbe2c97cd6..b19599e67e 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -269,17 +269,20 @@ static int encode_simple_internal(AVCodecContext
> *avctx, AVPacket *avpkt)
> got_packet = 0;
>
> av_assert0(codec->cb_type == FF_CODEC_CB_TYPE_ENCODE);
> -
> -if (CONFIG_FRAME_THREAD_ENCODER && avci->frame_thread_encoder)
> +#if CONFIG_FRAME_THREAD_ENCODER
> +if (avci->frame_thread_encoder)
> /* This will unref frame. */
> ret = ff_thread_video_encode_frame(avctx, avpkt, frame, _packet);
> -else {
> +#endif
> +#if !CONFIG_FRAME_THREAD_ENCODER
> +if (!avci->frame_thread_encoder) {
> ret = ff_encode_encode_cb(avctx, avpkt, frame, _packet);
And here..
> #if FF_API_THREAD_SAFE_CALLBACKS
> if (frame)
> av_frame_unref(frame);
> #endif
> }
> +#endif // !CONFIG_FRAME_THREAD_ENCODER
>
> if (avci->draining && !got_packet)
> avci->draining_done = 1;
> @@ -670,11 +673,11 @@ int ff_encode_preinit(AVCodecContext *avctx)
> return AVERROR(ENOMEM);
> }
>
> -if (CONFIG_FRAME_THREAD_ENCODER) {
> +#if CONFIG_FRAME_THREAD_ENCODER
> ret = ff_frame_thread_encoder_init(avctx);
> if (ret < 0)
> return ret;
> -}
> +#endif
>
> return 0;
> }
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 6ede4e8c9f..4538974dab 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -933,13 +933,13 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
> H264Picture *out, int *g
>
> *got_frame = 1;
>
> -if (CONFIG_MPEGVIDEODEC) {
> -ff_print_debug_info2(h->avctx, dst, NULL,
> - out->mb_type,
> - out->qscale_table,
> - out->motion_val,
> -
Re: [FFmpeg-devel] [PATCH] get_cabac_inline_x86: Don't inline if 32-bit Windows
On Tue, Jan 3, 2023 at 12:01 AM Christopher Degawa wrote: > > previouslly, it only was an issue with 32-bit clang from msys2's > mingw32 repo, however, at some point with an update to gcc 12.2.0, > the same issue popped up. Tested with a clean clone of ffmpeg, and even > tested with n5.0, but the issue persists, so I presume it's a compiler > issue. > > Related: https://trac.ffmpeg.org/ticket/8903 > I regularly build with 12.2 on win32 and its fine. In fact, there is a fate station for that: https://fate.ffmpeg.org/report.cgi?slot=x86_32-mingw-w64-dll-windows-native=20230102232810 So if you are seeing this issue, more details that trigger it will be required, and maybe a more targeted fix. - Hendrik ___ 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] Would a crypto file be acceptable?
On Thu, Dec 22, 2022 at 4:53 PM Mark Gaiser wrote: > > On Thu, Dec 22, 2022 at 11:40 AM Nicolas George wrote: > > > Mark Gaiser (12022-12-21): > > > While this works just fine, it's limited in use because the cryptography > > > details have to be passed on the command line. Applications that might > > well > > > support much of ffmpeg functionality can't easily hook into the crypto > > > functionality. Take KODI for example, it allows playback of many of the > > > formats ffmpeg supports but anything with crypto just isn't possible. In > > > fact, anything that requires custom command line arguments isn't > > possible. > > > [2] > > > > > > My idea is to make a new file format that would be implemented and > > specced > > > within [1]. My proposed format would be: > > > > > > --- > > > CRYPTO-VERSION:1 > > > CRYPTO-KEY:URI:. > > > CRYPTO-IV:URI:. > > > encrypted_file > > > --- > > > > The concat demuxer can already contain options, and despite is name it > > can be used with a single file. > > > > Could you elaborate on how to use that:? > > The end result needs to be: > ffplay > > that needs to translate to: > ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv > $AES_IV > > I briefly looked at the concat demuxer but couldn't see how to get this > desired result. > If you know how, please let me know! > Create a file like this: https://pastebin.com/hFSeXsZt The first line is so ffmpeg can probe the format, then just have a "file" line followed by any number of "option" lines. Note that options are only allowed if safe-mode is disengaged, so the app in question would have to pass "-safe 0" to the execution in some manner. But this is something you would have to ask the app to do, as this protection exists for a reason. - Hendrik ___ 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]configure: Assume target-os=win32 for toolchain msvc
On Tue, Dec 13, 2022 at 8:02 PM Carl Eugen Hoyos wrote: > > Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos > : > > > > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes > > : > > > > > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos > > > wrote: > > > > > > > > Hi! > > > > > > > > Attached patch slightly simplifies building with MSVC. > > > > > > > > Please comment, Carl Eugen > > > > > > I don't think any toolchain value should make assumptions about the > > > host it is running on, because between WSL and Wine, you can certainly > > > do a bunch of specific things where this is not true. > > > > If this is true, then my patch is of course incorrect. > > But could you give an example? > > I was under the impression that cl.exe can only run > > in win32. > > Ping. > Could you give an example where host-os is not win32 when > compiling with msvc? > When using wine, your host is linux. - Hendrik ___ 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] Towards YUVJ removal
On Fri, Dec 9, 2022 at 12:49 PM Niklas Haas wrote: > > So, as was discussed at the last meeting, we should move towards > removing YUVJ. I want to gather feedback on what appears to be to the > major hurdle, and possible ways to solve it. > > The basic major issue is how to handle the case of combining limited > range input with an encoder for a format that only accepts full range > data. The common case, for example, would be converting a frame from a > typical video file to a JPEG: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > > Currently, this works because the JPEG encoder only advertises YUVJ > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert > from limited range to full range. But this depends on conflating color > range and pixel formats, which is exactly what has been marked > deprecated for an eternity. > > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: > > 1. Simply output an error, and rely on the user to insert a conversion >filter, e.g.: > >$ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg >error: inputs to jpeg encoder must be full range > >$ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg > output.jpg >... works > > 2. Have the JPEG encoder take care of range conversion internally, by >using sws to convert limited to full range. > > 3. Allow filters to start exposing color space metadata as part of >filter negotiation, and then auto-insert swscaler whenever colorspace >conversion needs to happen as a result of filters not accepting the >corresponding color metadata. This would also allow more than just >conversion between limited/full range. > > 4. Combine approach 1 with an encoder flag for "supports full range >only", and have ffmpeg.c auto-insert a scale filter as the last step >before the encoder if this flag is set (and input is limited range). > > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. > > 2 would be the least work, but violates abstraction boundaries. > > 3 would be the most work and is, IMO, of questionable gain. > > 4 would be both explicit and not break existing workflows. > Some sort of metadata has to be present to indicate this. It is not reasonable to assume users magically know what range a codec accepts, and then go out of their way to hardcode a list that might need full range. So 1 alone is entirely not reasonable, especially if you think eg. about an API user, who might create an app that may not show the immediate error message, or even have a button to insert a scaler. Instead the API should contain all the information for an application to make the right choices if necessary. Of course I already see people argue that JPEG accepts both depending on standards compliance etc, but the metadata should allow me to make the encoder work without needing to set standard compliance to some value. Or in other words, it should just work the most straight-forward way, without needing special knowledge about the encoder or even format. For mjpegenc this probably means it should only advertise full range. Or this information needs to somehow be context-sensitive and allow me to indicate the standards compliance value I care for. If the encoder indicates both limited and full, but errors out on limited, thats not useful. - Hendrik ___ 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 v3 0/5] Fix FFmpeg compilation without DCE
> > And does running configure output VS project files, so that > you can compile inside VS (I think this existed at some > earlier time at least, but I was under the impression that > it's broken)..? > This was never a feature, and likely never will be. We have our own build system and its the only supported one. The compiler is the same regardless, the msvc compiler. - Hendrik ___ 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]configure: Assume target-os=win32 for toolchain msvc
On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch slightly simplifies building with MSVC. > > Please comment, Carl Eugen I don't think any toolchain value should make assumptions about the host it is running on, because between WSL and Wine, you can certainly do a bunch of specific things where this is not true. - Hendrik ___ 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 v9 02/25] avutil/frame: Prepare AVFrame for subtitle handling
On Tue, Oct 25, 2022 at 11:14 AM softworkz wrote:
>
> @@ -712,6 +712,53 @@ typedef struct AVFrame {
> * Duration of the frame, in the same units as pts. 0 if unknown.
> */
> int64_t duration;
> +
> +/**
> + * Media type of the frame (audio, video, subtitles..)
> + *
> + * See AVMEDIA_TYPE_xxx
> + */
> +enum AVMediaType type;
> +
> +/**
> + * Number of items in the @ref subtitle_areas array.
> + */
> +unsigned num_subtitle_areas;
> +
> +/**
> + * Array of subtitle areas, may be empty.
> + */
> +AVSubtitleArea **subtitle_areas;
> +
> +/**
> + * Header containing style information for text subtitles.
> + */
> +AVBufferRef *subtitle_header;
> +
> +/**
> + * Indicates that a subtitle frame is a repeated frame for arbitrating
> flow
> + * in a filter graph.
> + * The field subtitle_timing.start_pts always indicates the original
> presentation
> + * time, while the frame's pts field may be different.
> + */
> +int repeat_sub;
> +
> +struct SubtitleTiming
> +{
> +/**
> + * The display start time, in AV_TIME_BASE.
> + *
> + * For subtitle frames, AVFrame.pts is populated from the packet pts
> value,
> + * which is not always the same as this value.
> + */
> +int64_t start_pts;
There is still no explanation here why they are not the same, why they
could not just be the same, and which field a user should look at.
The cover letter talks about clarity why this is needed is important,
but then provides none of that.
"Its required" is not an argument. So please enlighten us once again
why we absolutely need two timestamps for subtitles, instead of just
one. As far as I can see, subtitle frames only have one relevant time
- when its supposed to be shown on the screen. What would the other
time ever be good for to a user?
Similarly for the duration, of course. I can even see the
AVFrame.duration field in this patch snippet just above the additions
that would seem to fully replace this one.
- Hendrik
> +
> +/**
> + * Display duration, in AV_TIME_BASE.
> + */
> +int64_t duration;
> +
> +} subtitle_timing;
> } AVFrame;
>
>
> @@ -788,6 +835,8 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
> /**
> * Allocate new buffer(s) for audio or video data.
> *
> + * Note: For subtitle data, use av_frame_get_buffer2
> + *
> * The following fields must be set on frame before calling this function:
> * - format (pixel format for video, sample format for audio)
> * - width and height for video
> @@ -807,9 +856,39 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
> * recommended to pass 0 here unless you know what you are
> doing.
> *
> * @return 0 on success, a negative AVERROR on error.
> + *
> + * @deprecated Use @ref av_frame_get_buffer2 instead and set @ref
> AVFrame.type
> + * before calling.
> */
> +attribute_deprecated
> int av_frame_get_buffer(AVFrame *frame, int align);
>
> +/**
> + * Allocate new buffer(s) for audio, video or subtitle data.
> + *
> + * The following fields must be set on frame before calling this function:
> + * - format (pixel format for video, sample format for audio)
> + * - width and height for video
> + * - nb_samples and channel_layout for audio
> + * - type (AVMediaType)
> + *
> + * This function will fill AVFrame.data and AVFrame.buf arrays and, if
> + * necessary, allocate and fill AVFrame.extended_data and
> AVFrame.extended_buf.
> + * For planar formats, one buffer will be allocated for each plane.
> + *
> + * @warning: if frame already has been allocated, calling this function will
> + * leak memory. In addition, undefined behavior can occur in
> certain
> + * cases.
> + *
> + * @param frame frame in which to store the new buffers.
> + * @param align Required buffer size alignment. If equal to 0, alignment
> will be
> + * chosen automatically for the current CPU. It is highly
> + * recommended to pass 0 here unless you know what you are
> doing.
> + *
> + * @return 0 on success, a negative AVERROR on error.
> + */
> +int av_frame_get_buffer2(AVFrame *frame, int align);
> +
> /**
> * Check if the frame data is writable.
> *
> diff --git a/libavutil/subfmt.c b/libavutil/subfmt.c
> new file mode 100644
> index 00..c72ebe2a43
> --- /dev/null
> +++ b/libavutil/subfmt.c
> @@ -0,0 +1,45 @@
> +/*
> + * Copyright (c) 2021 softworkz
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>
Re: [FFmpeg-devel] [PATCH] avcodec: Vorbis decode: don't use a flag to determine if frames have been output
On Mon, Oct 17, 2022 at 10:18 AM Paul B Mahol wrote:
>
> On 10/17/22, Hendrik Leppkes wrote:
> > On Thu, Sep 8, 2022 at 10:26 AM wrote:
> >>
> >> From: Jyrki Vesterinen
> >>
> >> If a developer using FFmpeg libraries seeks into an earlier position and
> >> calls
> >> avcodec_flush_buffers() afterwards as recommended, the Vorbis decoder will
> >> drop
> >> the next frame, since buffer flushing clears the first_frame flag. As a
> >> result,
> >> the audio samples the calling code receives may be ahead of the requested
> >> seek
> >> position, which is unacceptable in some use cases such as playing a
> >> looping
> >> sound effect.
> >>
> >> This commit removes the first_frame flag entirely and instead uses the
> >> presentation timestamp to determine if it's the first frame.
> >> ---
> >> libavcodec/vorbisdec.c | 5 +
> >> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> >> index 4d03947c49..d4b030d7b9 100644
> >> --- a/libavcodec/vorbisdec.c
> >> +++ b/libavcodec/vorbisdec.c
> >> @@ -130,7 +130,6 @@ typedef struct vorbis_context_s {
> >> AVFloatDSPContext *fdsp;
> >>
> >> FFTContext mdct[2];
> >> -uint8_t first_frame;
> >> uint32_t version;
> >> uint8_t audio_channels;
> >> uint32_t audio_samplerate;
> >> @@ -1845,8 +1844,7 @@ static int vorbis_decode_frame(AVCodecContext
> >> *avctx, AVFrame *frame,
> >> if ((len = vorbis_parse_audio_packet(vc, channel_ptrs)) <= 0)
> >> return len;
> >>
> >> -if (!vc->first_frame) {
> >> -vc->first_frame = 1;
> >> +if (frame->pts < 0) {
> >> *got_frame_ptr = 0;
> >> av_frame_unref(frame);
> >> return buf_size;
> >> @@ -1881,7 +1879,6 @@ static av_cold void
> >> vorbis_decode_flush(AVCodecContext *avctx)
> >> sizeof(*vc->saved));
> >> }
> >> vc->previous_window = -1;
> >> -vc->first_frame = 0;
> >> }
> >>
> >> const FFCodec ff_vorbis_decoder = {
> >> --
> >> 2.37.2.windows.2
> >>
> >
> > This change seems to be rather fragile and faulty, causing vorbis
> > decoding to fail in various scenarios for a bunch of downstream
> > projects.
> >
> > - A user may not set pts at all, resulting in all frames being dropped
> > (pure audio files don't necessarily need timestamps)
> > - A seek could happen before any frame is ever decoded, resulting in
> > wrong drops, potentially in the middle of playback if the user seeks
> > backwards after opening in the middle.
> >
> > In general, using timestamps to control decoder behavior is often just
> > wrong, as timestamps are not reliable, and most importantly, not tied
> > to the bitstream at all.
> >
> > Can we revert this and re-think the approach?
>
> Are you saying that previous solution was better than current one?
>
> By your own words its ever worse that current state.
>
At least the old solution consistently just dropped one frame after a
flush, not in the middle of playback, or dropping every single frame
because the user did not specify timestamps, breaking playback
entirely.
We already have mechanisms to properly drop padding data from the
front of a stream in generic code, that should ideally be used, and
not a decoder-specific hack.
- Hendrik
___
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] avcodec: Vorbis decode: don't use a flag to determine if frames have been output
On Thu, Sep 8, 2022 at 10:26 AM wrote:
>
> From: Jyrki Vesterinen
>
> If a developer using FFmpeg libraries seeks into an earlier position and calls
> avcodec_flush_buffers() afterwards as recommended, the Vorbis decoder will
> drop
> the next frame, since buffer flushing clears the first_frame flag. As a
> result,
> the audio samples the calling code receives may be ahead of the requested seek
> position, which is unacceptable in some use cases such as playing a looping
> sound effect.
>
> This commit removes the first_frame flag entirely and instead uses the
> presentation timestamp to determine if it's the first frame.
> ---
> libavcodec/vorbisdec.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> index 4d03947c49..d4b030d7b9 100644
> --- a/libavcodec/vorbisdec.c
> +++ b/libavcodec/vorbisdec.c
> @@ -130,7 +130,6 @@ typedef struct vorbis_context_s {
> AVFloatDSPContext *fdsp;
>
> FFTContext mdct[2];
> -uint8_t first_frame;
> uint32_t version;
> uint8_t audio_channels;
> uint32_t audio_samplerate;
> @@ -1845,8 +1844,7 @@ static int vorbis_decode_frame(AVCodecContext *avctx,
> AVFrame *frame,
> if ((len = vorbis_parse_audio_packet(vc, channel_ptrs)) <= 0)
> return len;
>
> -if (!vc->first_frame) {
> -vc->first_frame = 1;
> +if (frame->pts < 0) {
> *got_frame_ptr = 0;
> av_frame_unref(frame);
> return buf_size;
> @@ -1881,7 +1879,6 @@ static av_cold void vorbis_decode_flush(AVCodecContext
> *avctx)
> sizeof(*vc->saved));
> }
> vc->previous_window = -1;
> -vc->first_frame = 0;
> }
>
> const FFCodec ff_vorbis_decoder = {
> --
> 2.37.2.windows.2
>
This change seems to be rather fragile and faulty, causing vorbis
decoding to fail in various scenarios for a bunch of downstream
projects.
- A user may not set pts at all, resulting in all frames being dropped
(pure audio files don't necessarily need timestamps)
- A seek could happen before any frame is ever decoded, resulting in
wrong drops, potentially in the middle of playback if the user seeks
backwards after opening in the middle.
In general, using timestamps to control decoder behavior is often just
wrong, as timestamps are not reliable, and most importantly, not tied
to the bitstream at all.
Can we revert this and re-think the approach?
- Hendrik
___
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] [crop support for matroska demuxer 2/3] libavcodec: Public code to support container crop
On Sat, Oct 1, 2022 at 8:14 AM OvchinnikovDmitrii
wrote:
>
> Support both simple and receive_frame api
> The container crop information is applied additional to frame crop information
> ---
> libavcodec/codec_par.c | 8
> libavcodec/decode.c| 20
> 2 files changed, 28 insertions(+)
>
> diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
> index abda649aa8..f74964a817 100644
> --- a/libavcodec/codec_par.c
> +++ b/libavcodec/codec_par.c
> @@ -118,6 +118,10 @@ int avcodec_parameters_from_context(AVCodecParameters
> *par,
> par->format = codec->pix_fmt;
> par->width = codec->width;
> par->height = codec->height;
> +par->crop_top = codec->crop_top;
> +par->crop_left = codec->crop_left;
> +par->crop_bottom= codec->crop_bottom;
> +par->crop_right = codec->crop_right;
> par->field_order = codec->field_order;
> par->color_range = codec->color_range;
> par->color_primaries = codec->color_primaries;
> @@ -199,6 +203,10 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
> codec->pix_fmt= par->format;
> codec->width = par->width;
> codec->height = par->height;
> +codec->crop_top = par->crop_top;
> +codec->crop_left = par->crop_left;
> +codec->crop_bottom= par->crop_bottom;
> +codec->crop_right = par->crop_right;
> codec->field_order= par->field_order;
> codec->color_range= par->color_range;
> codec->color_primaries= par->color_primaries;
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6be2d3d6ed..548225c904 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -324,6 +324,16 @@ static inline int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame,
> emms_c();
> actual_got_frame = got_frame;
>
> +/* crop for simple api mode. apply additional container crop info to
> frame */
> +if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> +if (avctx->crop_top != 0 || avctx->crop_left != 0 ||
> avctx->crop_right != 0 || avctx->crop_bottom != 0){
> +frame->crop_top+= avctx->crop_top;
> +frame->crop_left += avctx->crop_left;
> +frame->crop_right += avctx->crop_right;
> +frame->crop_bottom += avctx->crop_bottom;
> +}
> +}
> +
> if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> if (frame->flags & AV_FRAME_FLAG_DISCARD)
> got_frame = 0;
> @@ -707,6 +717,16 @@ int ff_decode_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
>
> if (avci->buffer_frame->buf[0]) {
> av_frame_move_ref(frame, avci->buffer_frame);
> +
> +/* crop for receive_frame api mode. apply additional container crop
> info to frame */
> +if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> +if (avctx->crop_top != 0 || avctx->crop_left != 0 ||
> avctx->crop_right != 0 || avctx->crop_bottom != 0){
> +frame->crop_top+= avctx->crop_top;
> +frame->crop_left += avctx->crop_left;
> +frame->crop_right += avctx->crop_right;
> +frame->crop_bottom += avctx->crop_bottom;
> +}
> +}
Somehow I don't feel like adding the two crops together is really
going to do what most users would expect to happen. It just feels
weird.
It also changes the decoder crop information, and an API user does not
get the pure information from the decoder, but rather an "interpreted"
form. As an API user, I do not get the ability here to extract the
pure decoder crop info, unless I manually null out the container info
beforehand, or subtract it again, both of which seems odd and
undesirable to me. Shouldn't I be provided with clean information, and
then I (the API user) can choose how to act?
- Hendrik
___
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] [crop support for matroska demuxer 1/3] libavcodec: Add crop related fields to structure AVCodecContext and AVCodecParameters.
On Sat, Oct 1, 2022 at 8:14 AM OvchinnikovDmitrii
wrote:
>
> ---
> libavcodec/avcodec.h | 8
> libavcodec/codec_par.h | 8
> 2 files changed, 16 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 7365eb5cc0..66df571afc 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -585,6 +585,14 @@ typedef struct AVCodecContext {
> */
> int coded_width, coded_height;
>
> +/**
> + * The dimensions of the crop, usually from container.
> + */
> +int crop_top;
> +int crop_left;
> +int crop_bottom;
> +int crop_right;
> +
> /**
> * the number of pictures in a group of pictures, or 0 for intra_only
> * - encoding: Set by user.
> diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
> index 7660791a12..c730a79957 100644
> --- a/libavcodec/codec_par.h
> +++ b/libavcodec/codec_par.h
> @@ -210,6 +210,14 @@ typedef struct AVCodecParameters {
> * Audio only. The channel layout and number of channels.
> */
> AVChannelLayout ch_layout;
> +
> +/**
> + * The dimensions of the crop, usually from container.
> + */
> +int crop_top;
> +int crop_left;
> +int crop_bottom;
> +int crop_right;
> } AVCodecParameters;
>
All of these should be size_t (and in AVCodecContext as well,
naturally), matching the type in AVFrame.
- Hendrik
___
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/6] opus: convert encoder and decoder to lavu/tx
On Sat, Sep 24, 2022 at 9:26 PM Hendrik Leppkes wrote: > > On Sat, Sep 24, 2022 at 8:43 PM Martin Storsjö wrote: > > > > On Sat, 24 Sep 2022, Lynne wrote: > > > > > This commit changes both the encoder and decoder to use the new lavu/tx > > > code, > > > which has faster C transforms and more assembly optimizations. > > > > What's the case of e.g. 32 bit arm - that does have a bunch of fft and > > mdct assembly, but is that something that ends up used by opus today, or > > does the mdct15 stuff use separate codepaths that aren't optimized there > > today yet? > > > > mdct15 only has some x86 assembly, nothing for ARM. > Only the normal (power of 2) fft/mdct has some ARM 32-bit assembly. > Actually, I missed that the mdct15 internally uses one of the normal fft functions for a part of the calculation, but how much impact that has on performance vs. the new code where the C alone is quite a bit faster would have to be confirmed by Lynne. - Hendrik ___ 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/6] opus: convert encoder and decoder to lavu/tx
On Sat, Sep 24, 2022 at 8:43 PM Martin Storsjö wrote: > > On Sat, 24 Sep 2022, Lynne wrote: > > > This commit changes both the encoder and decoder to use the new lavu/tx > > code, > > which has faster C transforms and more assembly optimizations. > > What's the case of e.g. 32 bit arm - that does have a bunch of fft and > mdct assembly, but is that something that ends up used by opus today, or > does the mdct15 stuff use separate codepaths that aren't optimized there > today yet? > mdct15 only has some x86 assembly, nothing for ARM. Only the normal (power of 2) fft/mdct has some ARM 32-bit assembly. - Hendrik ___ 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] lavc: add detection of forced subtitles
On Mon, Sep 19, 2022 at 10:53 PM Andreas Rheinhardt
wrote:
>
> Scott Theisen:
> > This is from the following MythTV commits:
> > libavcodec: add support for detecting forced subtitle segments.
> > https://github.com/MythTV/mythtv/commit/5099f1a5777966fba482b623e581c1eef5c8fc09
> > This adds forced subtitle segment detection to the PGS subtitle decoder and
> > copies the result to AVSubtitle.
> >
> > Subtitles: Flag forced DVD subtitles.
> > https://github.com/MythTV/mythtv/commit/78f71eecdbd53ba92af2ad639b32564c01f24563
> > ---
> > libavcodec/avcodec.h | 1 +
> > libavcodec/dvdsubdec.c | 4 +++-
> > libavcodec/pgssubdec.c | 4
> > 3 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 7db5d1b1c5..b9aa9efb2f 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -2331,6 +2331,7 @@ typedef struct AVSubtitle {
> > unsigned num_rects;
> > AVSubtitleRect **rects;
> > int64_t pts;///< Same as packet pts, in AV_TIME_BASE
> > +int forced;
>
> sizeof(AVSubtitle) is part of the public ABI, no additions to it are
> possible. I wanted to suggest using AVSubtitleRect.flags, but apparently
> AV_SUBTITLE_FLAG_FORCED already exists. And it seems that both the
> dvdsub as well as the pgssub decoders already set this.
>
Which is also more correct, since in PGS for example you can have both
active rects that are forced, and those that are not, at the same
time.
- Hendrik
___
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] Discrepancy between comments for AVX512 flags
On Sat, Aug 27, 2022 at 12:04 AM James Darnley wrote: > > Has there been a discussion about which features should go with which flag? I think the feature selection is fine as-is, if you want to clarify the comments go ahead. AVX512 wouldn't be useful with a subset even smaller then what the plain AVX512 is looking for (there is also no CPUs with any smaller set, afaik), and most would even agree that the ICL set is the minimum they would be developing for. - Hendrik ___ 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] configure: enable the av1_frame_split bsf for the av1 decoder
The BSF is required to make use of the AV1 decoder, thus configure should also ensure it is build. --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index fe94941a03..6a179190ac 100755 --- a/configure +++ b/configure @@ -2788,7 +2788,7 @@ atrac3al_decoder_select="mdct" atrac3p_decoder_select="mdct sinewin" atrac3pal_decoder_select="mdct sinewin" atrac9_decoder_select="mdct" -av1_decoder_select="cbs_av1" +av1_decoder_select="cbs_av1 av1_frame_split_bsf" bink_decoder_select="blockdsp hpeldsp" binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs" binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs" -- 2.33.0.windows.2 ___ 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] [FFmpeg-cvslog] doc/filters: clarify behaviour of weights in amix
On Tue, Aug 9, 2022 at 12:46 PM Gyan Doshi wrote: > > > > On 2022-08-09 04:00 pm, Ronald S. Bultje wrote: > > On Tue, Aug 9, 2022 at 5:36 PM Gyan Doshi wrote: > > > >> > >> On 2022-08-09 02:57 pm, Anton Khirnov wrote: > >>> Quoting Gyan Doshi (2022-08-09 11:22:39) > I am a docs maintainer so I push these directly. > >>> All patches should go through the mailing list, so other people get the > >>> opportunity to comment on them. > >> I do that for more extensive changes. > >> > >> As the guidelines say, > >> > >> "Send your changes as patches to the ffmpeg-devel mailing list > > > > and > > > > > > if > >> the code maintainers say OK, you may commit. This does not apply to > >> files you wrote and/or maintain." > > > > That should make the intent of the sentence quoted clear. > > 'This' refers to the entire preceding sentence. If it was otherwise, it > would be incompatible with the 2nd way mentioned at > http://www.ffmpeg.org/developer.html#Contributing > > I'm not wedded to the policy as stated in the current docs, but the > current docs are clear that maintainers can push directly. > If several people disagree on the interpretation, its clearly not as "clear" as you claim it to be. - Hendrik ___ 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] configure: Check for DXGI_OUTDUPL_FRAME_INFO for the ddagrab filter
On Mon, Aug 1, 2022 at 2:56 PM Martin Storsjö wrote: > > On Mon, 1 Aug 2022, Hendrik Leppkes wrote: > > > On Mon, Aug 1, 2022 at 2:36 PM Martin Storsjö wrote: > >> > >> The DXGI_OUTDUPL_FRAME_INFO type isn't available in Windows API > >> subsets other than "desktop", while the IDXGIOutput1 interface is > >> available for all API subsets. > >> > >> This fixes compilation for UWP/"Windows Store" configurations (and > >> older API subsets like Windows Phone). > > > > The entire desktop duplication API is not present on Phone targets > > (its called "desktop" duplication afterall). I think it would be > > better to check for a primary DDA function, instead of some auxiliary > > structure. > > FWIW, based on the MSVC error output > (http://fate.ffmpeg.org/log.cgi?log=compile=arm-msvc2019-phone=20220730152801), > the only hard errors it listed were the undefined types > (DXGI_OUTDUPL_POINTER_SHAPE_INFO and DXGI_OUTDUPL_FRAME_INFO) - but I > presume that IDXGIOutputDuplication_AcquireNextFrame and > IDXGIOutputDuplication_ReleaseFrame could be good candidates for checking > too - I don't see anything else in that error log that one could check > for? I guess it doesn't really matter what we check for, and checking for types seems easier then those macro'ed COM function wrappers. It just felt slightly odd. But since its in already, no need to worry. - Hendrik ___ 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] Enhancement layers in FFmpeg
On Mon, Aug 1, 2022 at 1:25 PM Niklas Haas wrote: > > Hey, > > We need to think about possible ways to implement reasonably-transparent > support for enhancement layers in FFmpeg. (SVC, Dolby Vision, ...). > There are more open questions than answers here. > > From what I can tell, these are basically separate bitstreams that carry > some amount of auxiliary information needed to reconstruct the > high-quality bitstream. That is, they are not independent, but need to > be merged with the original bitstream somehow. > > How do we architecturally fit this into FFmpeg? Do we define a new codec > ID for each (common/relevant) combination of base codec and enhancement > layer, e.g. HEVC+DoVi, H.264+SVC, ..., or do we transparently handle it > for the base codec ID and control it via a flag? Do the enhancement > layer packets already make their way to the codec, and if not, how do we > ensure that this is the case? EL on Blu-rays are a separate stream, so that would need to be handled in some fashion. Unless it wouldn't. See below. > > Can the decoder itself recursively initialize a sub-decoder for the > second bitstream? And if so, does the decoder apply the actual > transformation, or does it merely attach the EL data to the AVFrame > somehow in a way that can be used by further filters or end users? My main question is, how closely related are those streams? I know that Dolby EL can be decoded basically entirely separately from the main video stream. But EL might be the special case here. I have no experience with SVC. If the enhancement layer is entirely independent, like Dolby EL, should avcodec need to do anything? It _can_ decode the stream today, a user-application could write code that decodes both the main stream and the EL stream and links them together, without any changes in avcodec. Do we need to complicate this situation by forcing this into avcodec? Decoding them in entirely separate decoder instances has the advantage of being able to use Hardware for the main one, software for the EL, or both in hardware, or whatever one prefers. Of course this applies to the special situation of Dolby EL which is entirely independent, at least in its primary source - Blu-ray. I think MKV might mix both into one stream, which is an unfortunate design decision on their part. avfilter for example is already setup to synchronize two incoming streams (for eg. overlay), so the same mechanic could be used to pass it to a processing filter. > > (What about the case of Dolby Vision, which iirc requires handling the > DoVi RPU metadata before the EL can be applied? What about instances > where the user wants the DoVi/EL application to happen on GPU, e.g. via > libplacebo in mpv/vlc?) > Yes, processing should be left to dedicated filters. > How does this metadata need to be attached? A second AVFrame reference > inside the AVFrame? Raw data in a big side data struct? For Dolby EL, no attachment is necessary if we follow the above concept of just not having avcodec care. - Hendrik ___ 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] configure: Check for DXGI_OUTDUPL_FRAME_INFO for the ddagrab filter
On Mon, Aug 1, 2022 at 2:36 PM Martin Storsjö wrote: > > The DXGI_OUTDUPL_FRAME_INFO type isn't available in Windows API > subsets other than "desktop", while the IDXGIOutput1 interface is > available for all API subsets. > > This fixes compilation for UWP/"Windows Store" configurations (and > older API subsets like Windows Phone). The entire desktop duplication API is not present on Phone targets (its called "desktop" duplication afterall). I think it would be better to check for a primary DDA function, instead of some auxiliary structure. - Hendrik ___ 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] enable auto vectorization for gcc 7 and higher
On Wed, Jul 27, 2022 at 11:02 PM Martin Storsjö wrote: > > On Wed, 27 Jul 2022, Hendrik Leppkes wrote: > > > On Wed, Jul 27, 2022 at 7:39 PM James Almer wrote: > >> > >> On 7/27/2022 2:34 PM, Swinney, Jonathan wrote: > >>> I recognize that this patch is going to be somewhat controversial. I'm > >>> submitting it mostly to see what the opinions are and evaluate options. I > >>> am working on improving performance for aarch64. On that architecture, > >>> there are fewer hand written assembly implementations of hot functions > >>> than there are for x86_64 and allowing gcc to auto-vectorize yields > >>> noticeable improvements. > >>> > >>> Gcc vectorization has improved recently and it hasn't been evaluated on > >>> the mailing list for a few years. This is the latest discussion I found > >>> in my searches: > >>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/193977.html > >> > >> Every time this was done, it was inevitably reverted after complains and > >> crash reports started piling up because gcc can't really handle all the > >> inline code our codebase has, among other things. > >> > > > > No need to wait for issues, I just tested, and the same issues still > > persist that have existed for years with GCC now. They don't seem to > > care to make it compatible with inline asm, which might be fair > > enough, but it means it just can't work here. > > > > In file included from libavcodec/cabac_functions.h:49, > > from libavcodec/h264_cabac.c:36: > > libavcodec/h264_cabac.c: In function 'ff_h264_decode_mb_cabac': > > libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible > > constraints > > This particular bit of inline assembly has historically been very > problematic in many configurations (although primarily on i386 I think) - > see e.g. 8990c5869e27fcd43b53045f87ba251f42e7d293. Would something like > that be enough for that build configuration to succeed, or are there many > other cases that break? > I can test tomorrow, but if we start influencing optimizer decisions just to run another optimizer flag, such a change would need to be backed with (positive!) performance numbers, and _very_ thorough testing (as we all know, trying to prove that something is not an issue is practically impossible, as the combinations are infinite) - Hendrik ___ 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".
