Re: [FFmpeg-devel] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder]

2023-12-27 Thread Paul B Mahol 
On Wed, Dec 27, 2023 at 12:53 AM James Almer  wrote:

>
> On 12/26/2023 7:40 PM, Paul B Mahol wrote:
> > On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje 
> > wrote:
> >
> >> Paul,
> >>
> >> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol  wrote:
> >>
> >>> Say what serious feature you contributed ? - Nothing.
> >>>
> >>
> >> the CC requests that you please refrain from attacking fellow FFmpeg
> >> contributors ("what serious feature [have] you contributed? - Nothing")
> on
> >> the mailinglist.
> >>
> >
> > I object here to your dictatorship trolling.
> >
> > Your are selectively picking what to comment and censor.
>
> What did the phrase Ronald quoted add to the conversation? Do you
> consider that being civil? Because pretty much no one does.
> Why can't people discuss and exchange opinions without talking shit to
> each other?
>
> This ML has a very bad reputation because things like that are rampant,
> so it has to stop. How will anyone want to contribute if the threat of
> being shit talked for no reason is always looming?
>

Talk with Thardin, cowboy coding subtle calling and triggering begin with
that entity mails.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi: add quirc filter

2023-12-27 Thread Stefano Sabatini 
On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:
> On 12/26/2023 10:25 PM, Stefano Sabatini wrote:
> > On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini wrote:
> > > ---
> > >   Changelog|   1 +
> > >   configure|   4 +
> > >   doc/filters.texi |  35 
> > >   libavfilter/Makefile |   1 +
> > >   libavfilter/allfilters.c |   1 +
> > >   libavfilter/vf_quirc.c   | 183 +++
> > >   6 files changed, 225 insertions(+)
> > >   create mode 100644 libavfilter/vf_quirc.c
> > 
> > V2 with a few fixes and all corners put in the metadata (e.g. in case
> > the QR code is rotated).
> 

> Looking at the library, the license is very permissive and the code hasn't
> been touched in many years. It is also pretty small, so why not just add it
> as a native filter instead of requiring an external dependency for what
> seems to be a relatively simple process?

I see pros and cons, in total that would be about 3K lines of pretty
clean code and data, and this would simplify integration for end-users
(since they would not need to build the library, which seems not
packaged by many distributions), and having the code would help to
solve similar problems and probably could be generalized and optimized
(e.g. to support other pixel formats).

OTOH it would add to the maintenance burden since we would be owners
of the code, which also means we would not benefit from fixes to the
upstream project, in case they happen (last commit is from March
2023, so not very old):
https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca
___
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/proresenc: make transparency honored in mov/QT

2023-12-27 Thread Stefano Sabatini 
On date Tuesday 2023-12-26 23:25:15 +0100, Clément Bœsch wrote:
> In the mov muxer (in mov_write_video_tag()), bits_per_coded_sample will
> be written under certain conditions and is required to be 32 for the
> transparency to be honored in QuickTime.
> 
> prores_kostya already has this setting but prores_anatoliy and
> prores_videotoolbox didn't.
> ---
>  libavcodec/proresenc_anatoliy.c | 3 +++
>  libavcodec/videotoolboxenc.c| 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index a1cb46aa59..16741afd68 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -930,6 +930,9 @@ static av_cold int prores_encode_init(AVCodecContext 
> *avctx)
>  }
>  }
>  
> +if (ctx->need_alpha)
> +avctx->bits_per_coded_sample = 32;
> +
>  ff_fdctdsp_init(&ctx->fdsp, avctx);
>  
>  avctx->codec_tag = AV_RL32((const 
> uint8_t*)profiles[avctx->profile].name);
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 15e0e1fe29..644fd60b00 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -521,6 +521,8 @@ static CMVideoCodecType get_cm_codec_type(AVCodecContext 
> *avctx,
>  }
>  return kCMVideoCodecType_HEVC;
>  case AV_CODEC_ID_PRORES:
> +if (desc && (desc->flags & AV_PIX_FMT_FLAG_ALPHA))
> +avctx->bits_per_coded_sample = 32;
>  switch (profile) {
>  case AV_PROFILE_PRORES_PROXY:
>  return MKBETAG('a','p','c','o'); // 
> kCMVideoCodecType_AppleProRes422Proxy

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 2/2] avcodec/proresenc: fix alpha plane encoding bitstream

2023-12-27 Thread Stefano Sabatini 
On date Tuesday 2023-12-26 23:25:16 +0100, Clément Bœsch wrote:
> These functions encode a slice of alpha (1 to 8 macroblocks) which are
> expected to be encoded as a repeated sequence of "[diff][run-1]", where
> diff is the running difference of the alpha value and run is how many
> times that value is expected to be duplicated (within the limit of a
> grand total of 2048 unpacked samples, corresponding to a slice of 8 MB).
> 
> Even when run==0 (the run variable semantic is actually "run minus 1"),
> there is always a diff previously encoded that needs a counter of at
> least 1. This means we need to call put_alpha_run() unconditionally at
> the end of the bitstream to account for the last running diff.
> 
> This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware
> (but not M1 for some mysterious reason) with files generated with
> commands such as:
> 
>   ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_aw 
> -profile:v 4-y aw.mov
>   ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_ks 
> -profile:v  -y ks.mov
> 
> The glitch expresses itself deterministically as blinking black
> rectangles on random frames (for example on frame 21, 54, 71, 79, ...).
> 
> Even with the proresdec from FFmpeg, overreads actually happens while
> reading the run-minus-1 value (around val = get_bits(gb, 4) in
> unpack_alpha()). This doesn't seem to cause any particular issue because
> it simply overreads into the next slice, and because the decoder is
> resilient, but it's still a problem.
> 
> Fixes ticket #10255.
> ---
>  libavcodec/proresenc_anatoliy.c | 3 +--
>  libavcodec/proresenc_kostya.c   | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 16741afd68..9b9ffa03be 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -486,8 +486,7 @@ static av_always_inline int 
> encode_alpha_slice_data(AVCodecContext *avctx, int8_
>  run++;
>  }
>  } while (idx < num_coeffs);
> -if (run)
> -put_alpha_run(&pb, run);
> +put_alpha_run(&pb, run);
>  flush_put_bits(&pb);
>  *a_data_size = put_bytes_output(&pb);
>  
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index e904632f8e..8d45e42d1a 100644
> --- a/libavcodec/proresenc_kostya.c
> +++ b/libavcodec/proresenc_kostya.c
> @@ -562,8 +562,7 @@ static void encode_alpha_plane(ProresContext *ctx, 
> PutBitContext *pb,
>  run++;
>  }
>  } while (idx < num_coeffs);
> -if (run)
> -put_alpha_run(pb, run);
> +put_alpha_run(pb, run);
>  }

LGTM, thanks.
___
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] lavfi/overlay: factorize definition of planar and package blending functions

2023-12-27 Thread Stefano Sabatini 
On date Sunday 2023-12-24 20:54:39 +0300, Dennis Mungai wrote:
> On Sun, 24 Dec 2023, 20:41 Stefano Sabatini,  wrote:
> 
> > On date Saturday 2023-12-16 15:24:36 +0100, Stefano Sabatini wrote:
> > > ---
> > >  libavfilter/vf_overlay.c | 260 ---
> > >  1 file changed, 53 insertions(+), 207 deletions(-)
> >
> > Will apply in a few days.
> >
> 
> 
> Hello,
> 
> Is a similar change required in the other overlay filter applications, such
> as overlay_cuda, overlay_vulkan, etc?

Checked the code, this is the only one benefitting from this kind of
refactoring.
___
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/d3d12va_decode: don't change the resource state if the referenced frame is the same as the current frame

2023-12-27 Thread Wu Jianhua 
> From: ffmpeg-devel  On Behalf Of Wu, Tong1 
> 
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/d3d12va_decode: don't change the 
> resource state if the referenced frame is > the same as the current frame
>
>>From: ffmpeg-devel  On Behalf Of Wu
>>Jianhua
>>Sent: Tuesday, December 26, 2023 9:21 PM
>>To: FFmpeg development discussions and patches >de...@ffmpeg.org>
>>Subject: [FFmpeg-devel] [PATCH] avcodec/d3d12va_decode: don't change the
>>resource state if the referenced frame is the same as the current frame
>>
>>avcodec/d3d12va_decode: don't change the resource state if the referenced
>>frame is the same as the current frame
>>
>> This commit removes the follow warning and error:
>>
>>D3D12 WARNING: ID3D12CommandList::ResourceBarrier: Called on the
>>same subresource(s) of
>>Resource(0x02236E0E00D0:'Unnamed ID3D12Resource Object') in
>>separate Barrier Descs
>>which is inefficient and likely unintentional. Desc[0] and Desc[1] on
>>(subresource :
>>4294967295). [RESOURCE_MANIPULATION WARNING #1008:
>>RESOURCE_BARRIER_DUPLICATE_SUBRESOURCE_TRANSITIONS]
>>
>>D3D12 ERROR: ID3D12CommandList::ResourceBarrier: Before state (0x0:
>>D3D12_RESOURCE_STATE_[COMMON|PRESENT])
>>of resource (0x02236E0E00D0:'Unnamed ID3D12Resource Object')
>>(subresource: 0) specified
>>by transition barrier does not match with the state (0x2:
>>D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE)
>>specified in the previous call to ResourceBarrier [RESOURCE_MANIPULATION
>>ERROR #527:
>>RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]
>>
>>Patch attached
>
> Could you please split the function declaration(header) into 2 lines since 
> it's a little bit long?
>
> Thx,
> Tong

Sure. Will do in the v2.

Thanks,
Jianhua
___
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 v2] avcodec/d3d12va_decode: don't change the resource state if the referenced frame is the same as the current frame

2023-12-27 Thread Wu Jianhua 
This commit removes the follow warning and error:

D3D12 WARNING: ID3D12CommandList::ResourceBarrier: Called on the same 
subresource(s) of
Resource(0x02236E0E00D0:'Unnamed ID3D12Resource Object') in separate 
Barrier Descs
which is inefficient and likely unintentional. Desc[0] and Desc[1] on 
(subresource :
4294967295). [RESOURCE_MANIPULATION WARNING #1008: 
RESOURCE_BARRIER_DUPLICATE_SUBRESOURCE_TRANSITIONS]

D3D12 ERROR: ID3D12CommandList::ResourceBarrier: Before state (0x0: 
D3D12_RESOURCE_STATE_[COMMON|PRESENT])
of resource (0x02236E0E00D0:'Unnamed ID3D12Resource Object') 
(subresource: 0) specified
by transition barrier does not match with the state (0x2: 
D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE)
specified in the previous call to ResourceBarrier [RESOURCE_MANIPULATION 
ERROR #527:
RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]

Patch attached


0001-avcodec-d3d12va_decode-don-t-change-the-resource-sta.patch
Description: 0001-avcodec-d3d12va_decode-don-t-change-the-resource-sta.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/rtsp: Fix server compatibility issues with rtspclientsink GStreamer plugin

2023-12-27 Thread Paul Orlyk 
mode field in Transport header can be sent in upper case so make string 
comparison case insensitive.
Also, GStreamer expects to see mode=record instead of mode=receive in 
Transport header in response.


Signed-off-by: Paul Orlyk 
---
 libavformat/rtsp.c| 4 ++--
 libavformat/rtspdec.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 583f5338e8..61e24a5c7a 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1012,8 +1012,8 @@ static void rtsp_parse_transport(AVFormatContext *s,
 if (*p == '=') {
 p++;
 get_word_sep(buf, sizeof(buf), ";, ", &p);
-if (!strcmp(buf, "record") ||
-!strcmp(buf, "receive"))
+if (!av_strcasecmp(buf, "record") ||
+!av_strcasecmp(buf, "receive"))
 th->mode_record = 1;
 }
 }
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 39fd92fb66..d6a223cbc6 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -303,7 +303,7 @@ static int rtsp_read_setup(AVFormatContext *s, char* 
host, char *controlurl)

 rtsp_st->interleaved_min = request.transports[0].interleaved_min;
 rtsp_st->interleaved_max = request.transports[0].interleaved_max;
 snprintf(responseheaders, sizeof(responseheaders), "Transport: "
- "RTP/AVP/TCP;unicast;mode=receive;interleaved=%d-%d"
+ "RTP/AVP/TCP;unicast;mode=record;interleaved=%d-%d"
  "\r\n", request.transports[0].interleaved_min,
  request.transports[0].interleaved_max);
 } else {
@@ -333,7 +333,7 @@ static int rtsp_read_setup(AVFormatContext *s, char* 
host, char *controlurl)

  localport = ff_rtp_get_local_rtp_port(rtsp_st->rtp_handle);
 snprintf(responseheaders, sizeof(responseheaders), "Transport: "
- "RTP/AVP/UDP;unicast;mode=receive;source=%s;"
+ "RTP/AVP/UDP;unicast;mode=record;source=%s;"
  "client_port=%d-%d;server_port=%d-%d\r\n",
  host, request.transports[0].client_port_min,
  request.transports[0].client_port_max, localport,
--
2.39.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] [PATCH] all: Don't set AVClass.item_name to its default value

2023-12-27 Thread Kacper Michajlow 
On Mon, 25 Dec 2023 at 11:48, Zhao Zhili  wrote:
>
>
>
> > On Dec 25, 2023, at 18:21, Anton Khirnov  wrote:
> >
> > Quoting Zhao Zhili (2023-12-25 10:27:59)
> >>
> >>
> >>> On Dec 25, 2023, at 16:38, Anton Khirnov  wrote:
> >>>
> >>> Quoting Kacper Michajlow (2023-12-24 11:41:52)
>  On Fri, 22 Dec 2023 at 14:57, Anton Khirnov  wrote:
> >
> > Quoting Andreas Rheinhardt (2023-12-22 14:48:45)
> >> Avoids relocations.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >
> > Maybe mention that it's not needed after
> > acf63d5350adeae551d412db699f8ca03f7e76b9.
> 
>  This is not the only user of this API, no?
> 
>  I have a question for my own curiosity. This is ABI (and API) breaking
>  change,
> >>>
> >>> It is not. This item was not guaranteed to be set, which was actually
> >>> the reason I wrote the patch that this one refers to.

It has never been marked as optional and while one can argue that it
was not marked as required either this ambiguity would be interpreted
that item_name is available by most. Moreover this is further
solidified by the first-party tools that made this assumption for more
than a decade.

I don't want to argue about technicalities and semantics, or whether
it is (was) required field. My point is that it is breaking change
that affects 3rd-party code and 1st-party code too.

You fixed log.c, but the exact same issue can be found in ffprobe.c
today. See 
https://github.com/FFmpeg/FFmpeg/blob/4fee63b241e0dd254436bf38df8b0635b2b666d8/fftools/ffprobe.c#L371
(and L385)

And by code search on github I could find more projects that are
affected. Some have directly copied previous version of the callback
from log.c.

> >> There is no problem to relax a restriction inside libavutil. However, 
> >> since there is
> >> no explicit documentation on whether item_name can be null or not, user 
> >> may make
> >> incorrect assumptions and depend on item_name not being null. I don’t 
> >> think break
> >> user’s code suddenly is a good idea, although we can say it’s break since 
> >> the beginning.
> >
> > My point is that the restriction never existed.
>
> I’m not argue against this.
>
> > There were always
> > AVClass instances that did not set that pointer. There were fewer of
> > them, but they did exist.
>
> acf63d5350adeae551d412db699f8ca03f7e76b9 just shows that even libavutil can 
> make
> that incorrect assumption, we cannot expect more from users. If user’s code 
> don’t trigger
> those instances with null pointer, it works from user’s viewpoint. It’s hard 
> to believe that
> the bug found in MPV doesn’t exist in other  projects. We need another method 
> to make
> such change smoothly.

Thanks, I couldn't summarize this better.

> >
> > --
> > Anton Khirnov
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org 
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org  
> > with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] lavfi: add quirc filter

2023-12-27 Thread Tomas Härdin 
ons 2023-12-27 klockan 12:37 +0100 skrev Stefano Sabatini:
> On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:
> > On 12/26/2023 10:25 PM, Stefano Sabatini wrote:
> > > On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini
> > > wrote:
> > > > ---
> > > >   Changelog    |   1 +
> > > >   configure    |   4 +
> > > >   doc/filters.texi |  35 
> > > >   libavfilter/Makefile |   1 +
> > > >   libavfilter/allfilters.c |   1 +
> > > >   libavfilter/vf_quirc.c   | 183
> > > > +++
> > > >   6 files changed, 225 insertions(+)
> > > >   create mode 100644 libavfilter/vf_quirc.c
> > > 
> > > V2 with a few fixes and all corners put in the metadata (e.g. in
> > > case
> > > the QR code is rotated).
> > 
> 
> > Looking at the library, the license is very permissive and the code
> > hasn't
> > been touched in many years. It is also pretty small, so why not
> > just add it
> > as a native filter instead of requiring an external dependency for
> > what
> > seems to be a relatively simple process?
> 
> I see pros and cons, in total that would be about 3K lines of pretty
> clean code and data, and this would simplify integration for end-
> users
> (since they would not need to build the library, which seems not
> packaged by many distributions), and having the code would help to
> solve similar problems and probably could be generalized and
> optimized
> (e.g. to support other pixel formats).
> 
> OTOH it would add to the maintenance burden since we would be owners
> of the code, which also means we would not benefit from fixes to the
> upstream project, in case they happen (last commit is from March
> 2023, so not very old):
> https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca

We could use git-subtree to keep in sync with upstream and to
contribute patches back. This is something I've done with other
projects. It has the following benefits:

1) Not having to deal with git-submodule
2) Having a copy of the code in case upstream goes down
3) Possibility of applying FFmpeg-only changes, say to the build
system, without having to have scripts that apply patches on top of the
submodule
4) Development can be concentrated on one implementation rather than
many. This is a point I've made with MXF but it applies here too

However, a bit of work is necessary to make packagers happy with such
an arrangeent, since I expect they would want libquirc to be a separate
package.

On the other hand we can just force users to build and install
libquirc. This is less work for us.

/Tomas
___
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] Pipewiregrab patch

2023-12-27 Thread Abhishek Ojha 
I wanted to express my sincere gratitude to the entire FFMPEG community for
promptly reviewing the [1] patch I submitted.

Leo,
Your insightful comments and suggestions have been invaluable in improving the
quality of the code. I appreciate your time and effort to thoroughly assessing
the patch.I wanted to inform you that I have diligently incorporated all the
review comments provided for the recent patch submission. Your feedback has
been immensely helpful in refining the code and enhancing its overall quality.

Paul B Mahol,
Thanks for the review comments. Changes are incorporated and requesting you to
please review the updated patch.

llyyr,
Thank you for testing the patch and sharing your review comments. Two patches
were submitted simultaneously, and the [2] second patch addresses the issue you
mentioned in your comments. However, I am still in need of review comments
specifically for the second patch, I'm uncertain if this approach is the
optimal solution for resolving the issue and would greatly appreciate your
feedback on it.

As a newcomer to the community, I realized that my receive email settings were
not enabled, which unfortunately prevented me from replying in the original
mail chain. Hence starting new mail chain.


[1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-September/314633.html
[2] https://ffmpeg.org//pipermail/ffmpeg-devel/2023-September/314632.html

Refrences:
1. https://pipewire.org/
2. https://github.com/flatpak/xdg-desktop-portal/
3. https://docs.pipewire.org/video-src-reneg_8c-example.html
4. 
https://webrtc.googlesource.com/src/+/8d9d575920a906bbf2a7b4c5b10f0ccf046f1cb8/modules/desktop_capture/linux/base_capturer_pipewire.cc

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] configure: disable locale use in spa plugin

2023-12-27 Thread Abhishek Ojha 
This commit requires to resolve the compilation error of pipewiregrab
because Pipewire's spa plugin is requesting locale_t extension to
compile.
Which was added in POSIX 2008 but ffmpeg is using POSIX 2001 due to
which spa plugin complains. __LOCALE_C_ONLY flag is set to disable
the locale usage in spa plugin. Adding it in configure file fix both
the library test and source compilation issue.
Not sure if this is the right approach to fix the issue.
Feedback/Suggestions will be highly appreciated.

Signed-off-by: Abhishek Ojha 
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 375327d5fa..442d004258 100755
--- a/configure
+++ b/configure
@@ -7106,6 +7106,8 @@ if enabled libxcb; then
 enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
 fi
 
+# _POSIX_C_SOURCE=200112 doesn't support locale
+add_cppflags -D__LOCALE_C_ONLY
 enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 
0.3.40" pipewire/pipewire.h pw_init
 if enabled libpipewire; then
 enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
-- 
2.34.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/2] libavdevice/pipewiregrab: add pipewire based grab

2023-12-27 Thread Abhishek Ojha 
This is an proof of concept for pipewire grab to enable screen capture
on wayland. Add a new Linux capture based on [1] PipeWire and the
[2] Desktop portal.
This new capture starts by asking the Desktop portal for a screencapture
session.There are quite a few D-Bus calls involved in this, but the key
points are:

1. A connection to org.freedesktop.portal.ScreenCast is estabilished,
   and the available cursor modes are updated. Currently only embedded
   and hidden currsor mode enabled.

2. Call CreateSession via dbus call. This is the first step of the
   communication. Response callback return the status of created
   session.

3. Call SelectSources . This is when a system dialog pops up asking
   the user to either select a monitor (desktop capture).Only monitor
   capture is enabled in current implementation.

4. Call Start . This signals the compositor that it can setup a PipeWire
   stream, and start sending buffers.

Above flow is implemented as per the [2] xdg-desktop-portal. Once flow
is completed, pipewire fd is received and using this pipewire stream is
created and receive buffer from the created stream.

For cursor implementation, embedded cursor mode is enabled that means
cursor metadata is not handled in current implementation and has no
control over the cursor bitmap.

gdbus/pipewire logic, this is based on obs-xdg, gstpipewire and
pipewire examples, and initial pipewire grab logic, this is based on
libavdevice/xcbgrab and libavdevice/v4l2

This implementation shows the skeleton implementation and enables basic
functionality. I'd like to hear opinions and suggestions to improve and
properly use this.

[1] https://pipewire.org/
[2] https://github.com/flatpak/xdg-desktop-portal/

Below are the arguments for pipewiregrab.
ffplay -f pipewiregrab -draw_mouse 1 -i :0.0

Signed-off-by: Abhishek Ojha 
---
 configure  |9 +
 libavdevice/Makefile   |1 +
 libavdevice/alldevices.c   |1 +
 libavdevice/pipewiregrab.c | 1815 
 4 files changed, 1826 insertions(+)
 create mode 100644 libavdevice/pipewiregrab.c

diff --git a/configure b/configure
index cd66e42850..375327d5fa 100755
--- a/configure
+++ b/configure
@@ -297,6 +297,7 @@ External library support:
   --enable-libxcb-shm  enable X11 grabbing shm communication [autodetect]
   --enable-libxcb-xfixes   enable X11 grabbing mouse rendering [autodetect]
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
+  --enable-libpipewire enable screen grabbing using pipewire [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
   --enable-libxml2 enable XML parsing using the C library libxml2, 
needed
@@ -1788,6 +1789,8 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
 libxcb_shm
 libxcb_shape
 libxcb_xfixes
+libpipewire
+libgio_unix
 lzma
 mediafoundation
 metal
@@ -3639,6 +3642,7 @@ v4l2_outdev_suggest="libv4l2"
 vfwcap_indev_deps="vfw32 vfwcap_defines"
 xcbgrab_indev_deps="libxcb"
 xcbgrab_indev_suggest="libxcb_shm libxcb_shape libxcb_xfixes"
+pipewiregrab_indev_deps="libpipewire libgio_unix pthreads"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
@@ -7102,6 +7106,11 @@ if enabled libxcb; then
 enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
 fi
 
+enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 
0.3.40" pipewire/pipewire.h pw_init
+if enabled libpipewire; then
+enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
+fi
+
 check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
 
 # check if building for desktop or uwp
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index c30449201d..f02960782d 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -49,6 +49,7 @@ OBJS-$(CONFIG_V4L2_INDEV)+= v4l2.o 
v4l2-common.o timefilter.o
 OBJS-$(CONFIG_V4L2_OUTDEV)   += v4l2enc.o v4l2-common.o
 OBJS-$(CONFIG_VFWCAP_INDEV)  += vfwcap.o
 OBJS-$(CONFIG_XCBGRAB_INDEV) += xcbgrab.o
+OBJS-$(CONFIG_PIPEWIREGRAB_INDEV)+= pipewiregrab.o
 OBJS-$(CONFIG_XV_OUTDEV) += xv.o
 
 # external libraries
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 8a90fcb5d7..1fa8563df4 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -53,6 +53,7 @@ extern const AVInputFormat  ff_v4l2_demuxer;
 extern const FFOutputFormat ff_v4l2_muxer;
 extern const AVInputFormat  ff_vfwcap_demuxer;
 extern const AVInputFormat  ff_xcbgrab_demuxer;
+extern const AVInputFormat  ff_pipewiregrab_demuxer;
 extern const FFOutputFormat ff_xv_muxer;
 
 /* external libraries */
diff --git a/libavdevice/pipewiregrab.c b/libavdevice/pipewiregrab.c
new file mode 100644
index 00..67b8a1d97c
--- /dev/null
+++ b/libavd

Re: [FFmpeg-devel] [PATCH] lavfi: add quirc filter

2023-12-27 Thread James Almer 

On 12/27/2023 8:37 AM, Stefano Sabatini wrote:

On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:

On 12/26/2023 10:25 PM, Stefano Sabatini wrote:

On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini wrote:

---
   Changelog|   1 +
   configure|   4 +
   doc/filters.texi |  35 
   libavfilter/Makefile |   1 +
   libavfilter/allfilters.c |   1 +
   libavfilter/vf_quirc.c   | 183 +++
   6 files changed, 225 insertions(+)
   create mode 100644 libavfilter/vf_quirc.c


V2 with a few fixes and all corners put in the metadata (e.g. in case
the QR code is rotated).





Looking at the library, the license is very permissive and the code hasn't
been touched in many years. It is also pretty small, so why not just add it
as a native filter instead of requiring an external dependency for what
seems to be a relatively simple process?


I see pros and cons, in total that would be about 3K lines of pretty
clean code and data, and this would simplify integration for end-users
(since they would not need to build the library, which seems not
packaged by many distributions), and having the code would help to
solve similar problems and probably could be generalized and optimized
(e.g. to support other pixel formats).

OTOH it would add to the maintenance burden since we would be owners
of the code, which also means we would not benefit from fixes to the
upstream project, in case they happen (last commit is from March
2023, so not very old):
https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca


That's a build system change, so not really relevant. Last real change 
was 
https://github.com/dlbeer/quirc/commit/cc673124335785d220dbb9057b21c51e4a87e0b2, 
also from March 2023, but the one before it is from August 2021.


I really think this should be ported as a native filter. It's not big 
and complex like a scaler (sws, zscale) which should not live within 
libavfilter. Any change can be contributed back to libquirc (A library 
that's not going to be abandoned like it happened with libdcadec after 
it was merged into lavc, because its license is more permissive than our 
LGPL, which has its merits).


Lets try to keep external dependencies as limited as possible.
___
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] lavfi: add quirc filter

2023-12-27 Thread Stefano Sabatini 
On date Wednesday 2023-12-27 14:16:24 -0300, James Almer wrote:
> On 12/27/2023 8:37 AM, Stefano Sabatini wrote:
> > On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:
> > > On 12/26/2023 10:25 PM, Stefano Sabatini wrote:
> > > > On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini wrote:
> > > > > ---
> > > > >Changelog|   1 +
> > > > >configure|   4 +
> > > > >doc/filters.texi |  35 
> > > > >libavfilter/Makefile |   1 +
> > > > >libavfilter/allfilters.c |   1 +
> > > > >libavfilter/vf_quirc.c   | 183 
> > > > > +++
> > > > >6 files changed, 225 insertions(+)
> > > > >create mode 100644 libavfilter/vf_quirc.c
> > > > 
> > > > V2 with a few fixes and all corners put in the metadata (e.g. in case
> > > > the QR code is rotated).
> > > 
> > 
> > > Looking at the library, the license is very permissive and the code hasn't
> > > been touched in many years. It is also pretty small, so why not just add 
> > > it
> > > as a native filter instead of requiring an external dependency for what
> > > seems to be a relatively simple process?
> > 
> > I see pros and cons, in total that would be about 3K lines of pretty
> > clean code and data, and this would simplify integration for end-users
> > (since they would not need to build the library, which seems not
> > packaged by many distributions), and having the code would help to
> > solve similar problems and probably could be generalized and optimized
> > (e.g. to support other pixel formats).
> > 
> > OTOH it would add to the maintenance burden since we would be owners
> > of the code, which also means we would not benefit from fixes to the
> > upstream project, in case they happen (last commit is from March
> > 2023, so not very old):
> > https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca
> 
> That's a build system change, so not really relevant. Last real change was 
> https://github.com/dlbeer/quirc/commit/cc673124335785d220dbb9057b21c51e4a87e0b2,
> also from March 2023, but the one before it is from August 2021.
> 

> I really think this should be ported as a native filter. It's not big and
> complex like a scaler (sws, zscale) which should not live within
> libavfilter.

> Any change can be contributed back to libquirc

This is not realistic, given that a reimplementation would be possibly
completely refactored to fit into FFmpeg.

> (A library
> that's not going to be abandoned like it happened with libdcadec after it
> was merged into lavc,

OTOH, this library is quite outside the scope of the FFmpeg, so it
makes sense to keep it as external dependency. This is a quite
different use case than a decoder, a QR-decoder library can make sense
outside of a multimedia library, for a decoder you would need a
complete multimedia library anyway.

I was checking the code, and porting would be a serious effort and
comprise several thousands lines of code (against the moderate effort
of wrapping it - which is already done), also some of the logic would
not really fit into FFmpeg because it is quite specific to this
application domain (QR code decoding), so it makes sense for it to
live within an external library. Not to mention that this would be
a duplication of effort.

*Unless* someone is willing to port/reimplement the code, but this
should not be a blocker for the wrapper and can be done as a separate
step.
___
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/2] lavfi/setpts: use macro to access variables array

2023-12-27 Thread Stefano Sabatini 
---
 libavfilter/setpts.c | 94 +---
 1 file changed, 45 insertions(+), 49 deletions(-)

diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index d057fc91c4..88a8d6af86 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -103,6 +103,9 @@ typedef struct SetPTSContext {
 enum AVMediaType type;
 } SetPTSContext;
 
+#define V(name_) \
+setpts->var_values[VAR_##name_]
+
 static av_cold int init(AVFilterContext *ctx)
 {
 SetPTSContext *setpts = ctx->priv;
@@ -114,15 +117,15 @@ static av_cold int init(AVFilterContext *ctx)
 return ret;
 }
 
-setpts->var_values[VAR_N]   = 0.0;
-setpts->var_values[VAR_S]   = 0.0;
-setpts->var_values[VAR_PREV_INPTS]  = NAN;
-setpts->var_values[VAR_PREV_INT]= NAN;
-setpts->var_values[VAR_PREV_OUTPTS] = NAN;
-setpts->var_values[VAR_PREV_OUTT]   = NAN;
-setpts->var_values[VAR_STARTPTS]= NAN;
-setpts->var_values[VAR_STARTT]  = NAN;
-setpts->var_values[VAR_T_CHANGE]= NAN;
+V(N)   = 0.0;
+V(S)   = 0.0;
+V(PREV_INPTS)  = NAN;
+V(PREV_INT)= NAN;
+V(PREV_OUTPTS) = NAN;
+V(PREV_OUTT)   = NAN;
+V(STARTPTS)= NAN;
+V(STARTT)  = NAN;
+V(T_CHANGE)= NAN;
 return 0;
 }
 
@@ -132,22 +135,18 @@ static int config_input(AVFilterLink *inlink)
 SetPTSContext *setpts = ctx->priv;
 
 setpts->type = inlink->type;
-setpts->var_values[VAR_TB] = av_q2d(inlink->time_base);
-setpts->var_values[VAR_RTCSTART] = av_gettime();
+V(TB) = av_q2d(inlink->time_base);
+V(RTCSTART) = av_gettime();
 
-setpts->var_values[VAR_SR] =
-setpts->var_values[VAR_SAMPLE_RATE] =
+V(SR) = V(SAMPLE_RATE) =
 setpts->type == AVMEDIA_TYPE_AUDIO ? inlink->sample_rate : NAN;
 
-setpts->var_values[VAR_FRAME_RATE] =
-setpts->var_values[VAR_FR] = inlink->frame_rate.num &&
- inlink->frame_rate.den ?
-av_q2d(inlink->frame_rate) : NAN;
+V(FRAME_RATE) = V(FR) =
+inlink->frame_rate.num && inlink->frame_rate.den ?
+av_q2d(inlink->frame_rate) : NAN;
 
 av_log(inlink->src, AV_LOG_VERBOSE, "TB:%f FRAME_RATE:%f SAMPLE_RATE:%f\n",
-   setpts->var_values[VAR_TB],
-   setpts->var_values[VAR_FRAME_RATE],
-   setpts->var_values[VAR_SAMPLE_RATE]);
+   V(TB), V(FRAME_RATE), V(SAMPLE_RATE));
 return 0;
 }
 
@@ -162,28 +161,28 @@ static inline char *double2int64str(char *buf, double v)
 
 static double eval_pts(SetPTSContext *setpts, AVFilterLink *inlink, AVFrame 
*frame, int64_t pts)
 {
-if (isnan(setpts->var_values[VAR_STARTPTS])) {
-setpts->var_values[VAR_STARTPTS] = TS2D(pts);
-setpts->var_values[VAR_STARTT  ] = TS2T(pts, inlink->time_base);
+if (isnan(V(STARTPTS))) {
+V(STARTPTS) = TS2D(pts);
+V(STARTT  ) = TS2T(pts, inlink->time_base);
 }
-if (isnan(setpts->var_values[VAR_T_CHANGE])) {
-setpts->var_values[VAR_T_CHANGE] = TS2T(pts, inlink->time_base);
+if (isnan(V(T_CHANGE))) {
+V(T_CHANGE) = TS2T(pts, inlink->time_base);
 }
-setpts->var_values[VAR_PTS   ] = TS2D(pts);
-setpts->var_values[VAR_T ] = TS2T(pts, inlink->time_base);
+V(PTS   ) = TS2D(pts);
+V(T ) = TS2T(pts, inlink->time_base);
 #if FF_API_FRAME_PKT
 FF_DISABLE_DEPRECATION_WARNINGS
-setpts->var_values[VAR_POS   ] = !frame || frame->pkt_pos == -1 ? NAN 
: frame->pkt_pos;
+V(POS   ) = !frame || frame->pkt_pos == -1 ? NAN : frame->pkt_pos;
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
-setpts->var_values[VAR_RTCTIME   ] = av_gettime();
+V(RTCTIME   ) = av_gettime();
 
 if (frame) {
 if (inlink->type == AVMEDIA_TYPE_VIDEO) {
-setpts->var_values[VAR_INTERLACED] = !!(frame->flags & 
AV_FRAME_FLAG_INTERLACED);
+V(INTERLACED) = !!(frame->flags & AV_FRAME_FLAG_INTERLACED);
 } else if (inlink->type == AVMEDIA_TYPE_AUDIO) {
-setpts->var_values[VAR_S] = frame->nb_samples;
-setpts->var_values[VAR_NB_SAMPLES] = frame->nb_samples;
+V(S) = frame->nb_samples;
+V(NB_SAMPLES) = frame->nb_samples;
 }
 }
 
@@ -202,34 +201,32 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 
 av_log(inlink->dst, AV_LOG_TRACE,
 "N:%"PRId64" PTS:%s T:%f",
-(int64_t)setpts->var_values[VAR_N],
-d2istr(setpts->var_values[VAR_PTS]),
-setpts->var_values[VAR_T]);
+   (int64_t)V(N), d2istr(V(PTS)), V(T));
 switch (inlink->type) {
 case AVMEDIA_TYPE_VIDEO:
 av_log(inlink->dst, AV_LOG_TRACE, " INTERLACED:%"PRId64,
-(int64_t)setpts->var_values[VAR_INTERLACED]);
+(int64_t)V(INTERLACED));
 break;
 case AVMEDIA_TYPE_AUDIO:
 av_log(inlink->dst, AV_LOG_TRACE, " N

[FFmpeg-devel] [PATCH 2/2] lavfi/setpts: introduce rand() function in expression

2023-12-27 Thread Stefano Sabatini 
This is useful to simulate random jitter.
---
 Changelog|  1 +
 doc/filters.texi | 10 +-
 libavfilter/setpts.c | 39 +--
 3 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/Changelog b/Changelog
index 424bfc11af..ed01c53264 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
 - tiltandshift filter
 - qrencode filter and qrencodesrc source
 - quirc filter
+- lavfi/setpts: introduce rand() function in expression
 
 version 6.1:
 - libaribcaption decoder
diff --git a/doc/filters.texi b/doc/filters.texi
index d1f95b9781..1d9a5d6c7d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -30946,7 +30946,7 @@ The expression which is evaluated for each frame to 
construct its timestamp.
 @end table
 
 The expression is evaluated through the eval API and can contain the following
-constants:
+constants and functions:
 
 @table @option
 @item FRAME_RATE, FR
@@ -31010,6 +31010,8 @@ The timebase of the input timestamps.
 @item T_CHANGE
 Time of the first frame after command was applied or time of the first frame 
if no commands.
 
+@item rand(min, max)
+a random number included between min and max
 @end table
 
 @subsection Examples
@@ -31021,6 +31023,12 @@ Start counting PTS from zero
 setpts=PTS-STARTPTS
 @end example
 
+@item
+Apply a random jitter effect of +/-100 TB units:
+@example
+setpts=PTS+100rand(-100\,100)
+@end example
+
 @item
 Apply fast motion effect:
 @example
diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index 88a8d6af86..0f24a900b3 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -32,6 +32,8 @@
 #include "libavutil/internal.h"
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
+#include "libavutil/lfg.h"
+#include "libavutil/random_seed.h"
 #include "libavutil/time.h"
 #include "audio.h"
 #include "avfilter.h"
@@ -101,18 +103,39 @@ typedef struct SetPTSContext {
 AVExpr *expr;
 double var_values[VAR_VARS_NB];
 enum AVMediaType type;
+AVLFG lfg;
 } SetPTSContext;
 
 #define V(name_) \
 setpts->var_values[VAR_##name_]
 
+static double drand(void *ctx, double min, double max)
+{
+SetPTSContext *setpts = ((AVFilterContext *)ctx)->priv;
+
+return min + (max-min) / UINT_MAX * av_lfg_get(&setpts->lfg);
+}
+
+typedef double (*eval_func2)(void *, double a, double b);
+
+static const eval_func2 fun2[] = {
+drand,
+NULL
+};
+
+static const char *const fun2_names[] = {
+"rand"
+};
+
 static av_cold int init(AVFilterContext *ctx)
 {
 SetPTSContext *setpts = ctx->priv;
 int ret;
 
+av_lfg_init(&setpts->lfg, av_get_random_seed());
+
 if ((ret = av_expr_parse(&setpts->expr, setpts->expr_str,
- var_names, NULL, NULL, NULL, NULL, 0, ctx)) < 0) {
+ var_names, NULL, NULL, fun2_names, fun2, 0, ctx)) 
< 0) {
 av_log(ctx, AV_LOG_ERROR, "Error while parsing expression '%s'\n", 
setpts->expr_str);
 return ret;
 }
@@ -126,6 +149,7 @@ static av_cold int init(AVFilterContext *ctx)
 V(STARTPTS)= NAN;
 V(STARTT)  = NAN;
 V(T_CHANGE)= NAN;
+
 return 0;
 }
 
@@ -159,8 +183,10 @@ static inline char *double2int64str(char *buf, double v)
 return buf;
 }
 
-static double eval_pts(SetPTSContext *setpts, AVFilterLink *inlink, AVFrame 
*frame, int64_t pts)
+static double eval_pts(AVFilterContext *ctx, AVFilterLink *inlink, AVFrame 
*frame, int64_t pts)
 {
+SetPTSContext *setpts = ctx->priv;
+
 if (isnan(V(STARTPTS))) {
 V(STARTPTS) = TS2D(pts);
 V(STARTT  ) = TS2T(pts, inlink->time_base);
@@ -186,17 +212,18 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
-return av_expr_eval(setpts->expr, setpts->var_values, NULL);
+return av_expr_eval(setpts->expr, setpts->var_values, ctx);
 }
 #define d2istr(v) double2int64str((char[BUF_SIZE]){0}, v)
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 {
-SetPTSContext *setpts = inlink->dst->priv;
+AVFilterContext *ctx = inlink->dst;
+SetPTSContext *setpts = ctx->priv;
 int64_t in_pts = frame->pts;
 double d;
 
-d = eval_pts(setpts, inlink, frame, frame->pts);
+d = eval_pts(ctx, inlink, frame, frame->pts);
 frame->pts = D2TS(d);
 
 av_log(inlink->dst, AV_LOG_TRACE,
@@ -250,7 +277,7 @@ static int activate(AVFilterContext *ctx)
 return filter_frame(inlink, in);
 
 if (ff_inlink_acknowledge_status(inlink, &status, &pts)) {
-double d = eval_pts(setpts, inlink, NULL, pts);
+double d = eval_pts(ctx, inlink, NULL, pts);
 
 av_log(ctx, AV_LOG_TRACE, "N:EOF PTS:%s T:%f -> PTS:%s T:%f\n",
d2istr(V(PTS)), V(T), d2istr(d), TS2T(d, inlink->time_base));
-- 
2.34.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 subje

Re: [FFmpeg-devel] [PATCH v2 0/3] Fix some active sequences in subtitles

2023-12-27 Thread Oneric 
On Sun, Dec 10, 2023 at 17:37:12 +0100, Oneric wrote:
> Changes from v1:
>  - ff_ass_bprint_text_event now only inserts a word-joiner
>if there isn’t already one anyway
>  - added a third commit improving the handling of
>curly brackets for standard ASS renderers
> 
> Heads up:
> [...]

ping

(applying from the received mails works fine,
 but do not use Patchwork’s mbox/diff/series as Patchwork mangled them)
___
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] lavfi: add quirc filter

2023-12-27 Thread James Almer 

On 12/27/2023 8:20 PM, Stefano Sabatini wrote:

On date Wednesday 2023-12-27 14:16:24 -0300, James Almer wrote:

On 12/27/2023 8:37 AM, Stefano Sabatini wrote:

On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:

On 12/26/2023 10:25 PM, Stefano Sabatini wrote:

On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini wrote:

---
Changelog|   1 +
configure|   4 +
doc/filters.texi |  35 
libavfilter/Makefile |   1 +
libavfilter/allfilters.c |   1 +
libavfilter/vf_quirc.c   | 183 +++
6 files changed, 225 insertions(+)
create mode 100644 libavfilter/vf_quirc.c


V2 with a few fixes and all corners put in the metadata (e.g. in case
the QR code is rotated).





Looking at the library, the license is very permissive and the code hasn't
been touched in many years. It is also pretty small, so why not just add it
as a native filter instead of requiring an external dependency for what
seems to be a relatively simple process?


I see pros and cons, in total that would be about 3K lines of pretty
clean code and data, and this would simplify integration for end-users
(since they would not need to build the library, which seems not
packaged by many distributions), and having the code would help to
solve similar problems and probably could be generalized and optimized
(e.g. to support other pixel formats).

OTOH it would add to the maintenance burden since we would be owners
of the code, which also means we would not benefit from fixes to the
upstream project, in case they happen (last commit is from March
2023, so not very old):
https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca


That's a build system change, so not really relevant. Last real change was 
https://github.com/dlbeer/quirc/commit/cc673124335785d220dbb9057b21c51e4a87e0b2,
also from March 2023, but the one before it is from August 2021.




I really think this should be ported as a native filter. It's not big and
complex like a scaler (sws, zscale) which should not live within
libavfilter.



Any change can be contributed back to libquirc


This is not realistic, given that a reimplementation would be possibly
completely refactored to fit into FFmpeg.


(A library
that's not going to be abandoned like it happened with libdcadec after it
was merged into lavc,


OTOH, this library is quite outside the scope of the FFmpeg, so it
makes sense to keep it as external dependency. This is a quite
different use case than a decoder, a QR-decoder library can make sense
outside of a multimedia library, for a decoder you would need a
complete multimedia library anyway.

I was checking the code, and porting would be a serious effort and
comprise several thousands lines of code (against the moderate effort
of wrapping it - which is already done), also some of the logic would
not really fit into FFmpeg because it is quite specific to this
application domain (QR code decoding), so it makes sense for it to
live within an external library. Not to mention that this would be
a duplication of effort.


Image analysis is within FFmpeg's scope, which QR code identification 
and decoding would be about.




*Unless* someone is willing to port/reimplement the code, but this
should not be a blocker for the wrapper and can be done as a separate
step.


No, i'm not blocking anything. Just stating that ideally this would be a 
native module.

___
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 v2 1/2] avcodec/av1dec: Move message of OBU info back to the beginning

2023-12-27 Thread fei . w . wang-at-intel . com 
From: Fei Wang 

So that can show OBU info even it doesn't have decomposed content. And
add OBU content status into the message.

Signed-off-by: Fei Wang 
---
 libavcodec/av1dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index da05a0f039..198fe75aa0 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -1200,11 +1200,12 @@ static int av1_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 AV1RawOBU *obu = unit->content;
 const AV1RawOBUHeader *header;
 
+av_log(avctx, AV_LOG_DEBUG, "OBU idx:%d, type:%d, content 
available:%d.\n", i, unit->type, !!obu);
+
 if (!obu)
 continue;
 
 header = &obu->header;
-av_log(avctx, AV_LOG_DEBUG, "Obu idx:%d, obu type:%d.\n", i, 
unit->type);
 
 switch (unit->type) {
 case AV1_OBU_SEQUENCE_HEADER:
-- 
2.25.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 v2 2/2] avcodec/av1dec: Return error for unsupported tile list OBU

2023-12-27 Thread fei . w . wang-at-intel . com 
From: Fei Wang 

Otherwise decoding maybe successful but output result is incorrect.

Signed-off-by: Fei Wang 
---
 libavcodec/av1dec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 198fe75aa0..41746b1f11 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -1202,6 +1202,12 @@ static int av1_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 
 av_log(avctx, AV_LOG_DEBUG, "OBU idx:%d, type:%d, content 
available:%d.\n", i, unit->type, !!obu);
 
+if (unit->type == AV1_OBU_TILE_LIST) {
+av_log(avctx, AV_LOG_ERROR, "Large scale tile decoding is 
unsupported.\n");
+ret = AVERROR_PATCHWELCOME;
+goto end;
+}
+
 if (!obu)
 continue;
 
-- 
2.25.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 v1 1/2] avcodec/av1dec: Move message of OBU info back to the beginning

2023-12-27 Thread Wang, Fei W 
On Wed, 2023-12-27 at 05:35 +, Xiang, Haihao wrote:
> On Di, 2023-12-26 at 11:31 +0800, fei.w.wang-at-intel@ffmpeg.org
> wrote:
> > From: Fei Wang 
> > 
> > So that can show OBU info even it doesn't have decomposed content.
> > 
> > Signed-off-by: Fei Wang 
> > ---
> >  libavcodec/av1dec.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index da05a0f039..e8041c1f58 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -1200,11 +1200,12 @@ static int
> > av1_receive_frame_internal(AVCodecContext
> > *avctx, AVFrame *frame)
> >  AV1RawOBU *obu = unit->content;
> >  const AV1RawOBUHeader *header;
> >  
> > +av_log(avctx, AV_LOG_DEBUG, "Obu idx:%d, obu type:%d.\n",
> > i, unit-
> > > type);
> 
> Could you add message to indicate the content of this unit is
> available or not ?

Added in V2.

Thanks
Fei

> 
> Thanks
> Haihao
> 
> > +
> >  if (!obu)
> >  continue;
> >  
> >  header = &obu->header;
> > -av_log(avctx, AV_LOG_DEBUG, "Obu idx:%d, obu type:%d.\n",
> > i, unit-
> > > type);
> >  
> >  switch (unit->type) {
> >  case AV1_OBU_SEQUENCE_HEADER:
___
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/7] avcodec/hevc: Add pel_uni_w_pixels4/6/8/12/16/24/32/48/64 asm opt

2023-12-27 Thread yinshiyou-hf 
> -原始邮件-
> 发件人: jinbo 
> 发送时间:2023-12-27 12:50:15 (星期三)
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: jinbo 
> 主题: [FFmpeg-devel] [PATCH v2 3/7] avcodec/hevc: Add 
> pel_uni_w_pixels4/6/8/12/16/24/32/48/64 asm opt
> 

> +
> +.macro HEVC_PEL_UNI_W_PIXELS8_LSX src0, dst0, w
> +vldrepl.d  vr0,\src0,   0
> +vsllwil.hu.bu  vr0,vr0, 0
> +vexth.wu.huvr5,vr0
> +vsllwil.wu.hu  vr0,vr0, 0
> +vslli.wvr0,vr0, 6
> +vslli.wvr5,vr5, 6
> +vmul.w vr0,vr0, vr1
> +vmul.w vr5,vr5, vr1
> +vadd.w vr0,vr0, vr2
> +vadd.w vr5,vr5, vr2
You can use 'vmadd.w' here.
> +vsra.w vr0,vr0, vr3
> +vsra.w vr5,vr5, vr3
> +vadd.w vr0,vr0, vr4
> +vadd.w vr5,vr5, vr4
> +vssrani.h.wvr5,vr0, 0
> +vssrani.bu.h   vr5,vr5, 0
> +.if \w == 6
> +fst.s  f5, \dst0,   0
> +vstelm.h   vr5,\dst0,   4, 2
> +.else
> +fst.d  f5, \dst0,   0
> +.endif
> +.endm
> +
> +.macro HEVC_PEL_UNI_W_PIXELS8x2_LASX src0, dst0, w
> +vldrepl.d  vr0,\src0,   0
> +add.d  t2, \src0,   a3
> +vldrepl.d  vr5,t2,  0
> +xvpermi.q  xr0,xr5, 0x02
> +xvsllwil.hu.bu xr0,xr0, 0
> +xvexth.wu.hu   xr5,xr0
> +xvsllwil.wu.hu xr0,xr0, 0
> +xvslli.w   xr0,xr0, 6
> +xvslli.w   xr5,xr5, 6
> +xvmul.wxr0,xr0, xr1
> +xvmul.wxr5,xr5, xr1
> +xvadd.wxr0,xr0, xr2
> +xvadd.wxr5,xr5, xr2

Use 'vmadd.w' will be better.

> +xvsra.wxr0,xr0, xr3
> +xvsra.wxr5,xr5, xr3
> +xvadd.wxr0,xr0, xr4
> +xvadd.wxr5,xr5, xr4
> +xvssrani.h.w   xr5,xr0, 0
> +xvpermi.q  xr0,xr5, 0x01
> +xvssrani.bu.h  xr0,xr5, 0
> +add.d  t3, \dst0,   a1
> +.if \w == 6
> +vstelm.w   vr0,\dst0,   0, 0
> +vstelm.h   vr0,\dst0,   4, 2
> +vstelm.w   vr0,t3,  0, 2
> +vstelm.h   vr0,t3,  4, 6
> +.else
> +vstelm.d   vr0,\dst0,   0, 0
> +vstelm.d   vr0,t3,  0, 1
> +.endif
> +.endm
> +
> +.macro HEVC_PEL_UNI_W_PIXELS16_LSX src0, dst0
> +vldvr0,\src0,   0
> +vexth.hu.buvr7,vr0
> +vexth.wu.huvr8,vr7
> +vsllwil.wu.hu  vr7,vr7, 0
> +vsllwil.hu.bu  vr5,vr0, 0
> +vexth.wu.huvr6,vr5
> +vsllwil.wu.hu  vr5,vr5, 0
> +vslli.wvr5,vr5, 6
> +vslli.wvr6,vr6, 6
> +vslli.wvr7,vr7, 6
> +vslli.wvr8,vr8, 6
> +vmul.w vr5,vr5, vr1
> +vmul.w vr6,vr6, vr1
> +vmul.w vr7,vr7, vr1
> +vmul.w vr8,vr8, vr1
> +vadd.w vr5,vr5, vr2
> +vadd.w vr6,vr6, vr2
> +vadd.w vr7,vr7, vr2
> +vadd.w vr8,vr8, vr2

Use 'vmadd.w', please check it in your left code.


本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
 
This email and its attachments contain confidential information from Loongson 
Technology , which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction or 
dissemination) by persons other than the intended recipient(s) is prohibited. 
If you receive this email in error, please notify the sender by phone or email 
immediately and delete it. 
___
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/d3d12va_decode: don't change the resource state if the referenced frame is the same as the current frame

2023-12-27 Thread Wu, Tong1 
>From: ffmpeg-devel  On Behalf Of Wu
>Jianhua
>Sent: Wednesday, December 27, 2023 9:44 PM
>To: FFmpeg development discussions and patches de...@ffmpeg.org>
>Subject: [FFmpeg-devel] [PATCH v2] avcodec/d3d12va_decode: don't change
>the resource state if the referenced frame is the same as the current frame
>
>This commit removes the follow warning and error:
>
>D3D12 WARNING: ID3D12CommandList::ResourceBarrier: Called on the
>same subresource(s) of
>Resource(0x02236E0E00D0:'Unnamed ID3D12Resource Object') in
>separate Barrier Descs
>which is inefficient and likely unintentional. Desc[0] and Desc[1] on
>(subresource :
>4294967295). [RESOURCE_MANIPULATION WARNING #1008:
>RESOURCE_BARRIER_DUPLICATE_SUBRESOURCE_TRANSITIONS]
>
>D3D12 ERROR: ID3D12CommandList::ResourceBarrier: Before state (0x0:
>D3D12_RESOURCE_STATE_[COMMON|PRESENT])
>of resource (0x02236E0E00D0:'Unnamed ID3D12Resource Object')
>(subresource: 0) specified
>by transition barrier does not match with the state (0x2:
>D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE)
>specified in the previous call to ResourceBarrier [RESOURCE_MANIPULATION
>ERROR #527:
>RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]
>
>Patch attached

Tested. It worked for me. Thx.
___
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 v2 2/5] avcodec/d3d12va_decode: delete an empty line and fix a fuction alignment

2023-12-27 Thread Tong Wu 
Signed-off-by: Tong Wu 
---
 libavcodec/d3d12va_decode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
index e0b67bf964..50d5b8d601 100644
--- a/libavcodec/d3d12va_decode.c
+++ b/libavcodec/d3d12va_decode.c
@@ -324,11 +324,10 @@ int ff_d3d12va_decode_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 
 ctx->objects_queue = av_fifo_alloc2(D3D12VA_VIDEO_DEC_ASYNC_DEPTH,
-  sizeof(HelperObjects), 
AV_FIFO_FLAG_AUTO_GROW);
+sizeof(HelperObjects), 
AV_FIFO_FLAG_AUTO_GROW);
 if (!ctx->objects_queue)
 return AVERROR(ENOMEM);
 
-
 DX_CHECK(ID3D12Device_CreateFence(ctx->device_ctx->device, 0, 
D3D12_FENCE_FLAG_NONE,
   &IID_ID3D12Fence, (void 
**)&ctx->sync_ctx.fence));
 
-- 
2.41.0.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 v2 3/5] avcodec/d3d12va_h264: replace assert with av_assert0

2023-12-27 Thread Tong Wu 
Signed-off-by: Tong Wu 
---
 libavcodec/d3d12va_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/d3d12va_h264.c b/libavcodec/d3d12va_h264.c
index 5a6d6852c8..24e1c523fa 100644
--- a/libavcodec/d3d12va_h264.c
+++ b/libavcodec/d3d12va_h264.c
@@ -60,7 +60,7 @@ static int d3d12va_h264_start_frame(AVCodecContext *avctx,
 if (!ctx)
 return -1;
 
-assert(ctx_pic);
+av_assert0(ctx_pic);
 
 ctx->used_mask = 0;
 
-- 
2.41.0.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 v2 1/5] avcodec/d3d12va_vp9: fix vp9 max_num_refs value

2023-12-27 Thread Tong Wu 
Previous max_num_refs was based on pp.frame_refs plus 1 and it could possibly
reaches the size limit. Actually it should be the size of pp.ref_frame_map
plus 1.

Signed-off-by: Tong Wu 
---
 libavcodec/d3d12va_vp9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/d3d12va_vp9.c b/libavcodec/d3d12va_vp9.c
index bb94e18781..d6dfc905d9 100644
--- a/libavcodec/d3d12va_vp9.c
+++ b/libavcodec/d3d12va_vp9.c
@@ -148,7 +148,7 @@ static int d3d12va_vp9_decode_init(AVCodecContext *avctx)
 break;
 };
 
-ctx->max_num_ref = FF_ARRAY_ELEMS(pp.frame_refs) + 1;
+ctx->max_num_ref = FF_ARRAY_ELEMS(pp.ref_frame_map) + 1;
 
 return ff_d3d12va_decode_init(avctx);
 }
-- 
2.41.0.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 v2 5/5] avcodec/dxva2(h264|mpeg2|vc1): use av_assert0 instead of assert

2023-12-27 Thread Tong Wu 
Signed-off-by: Tong Wu 
---
 libavcodec/dxva2.c   |  4 ++--
 libavcodec/dxva2_h264.c  | 16 
 libavcodec/dxva2_mpeg2.c |  2 +-
 libavcodec/dxva2_vc1.c   |  2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index a6ad5e4dc7..ec0d9e7d1c 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -20,10 +20,10 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include 
 #include 
 #include 
 
+#include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "libavutil/log.h"
 #include "libavutil/time.h"
@@ -1012,7 +1012,7 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx, 
AVFrame *frame,
 
 /* TODO Film Grain when possible */
 
-assert(buffer_count == 1 + (qm_size > 0) + 2);
+av_assert0(buffer_count == 1 + (qm_size > 0) + 2);
 
 #if CONFIG_D3D11VA
 if (ff_dxva2_is_d3d11(avctx))
diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
index e0ec4878a7..0fe4152625 100644
--- a/libavcodec/dxva2_h264.c
+++ b/libavcodec/dxva2_h264.c
@@ -44,7 +44,7 @@ struct dxva2_picture_context {
 static void fill_picture_entry(DXVA_PicEntry_H264 *pic,
unsigned index, unsigned flag)
 {
-assert((index&0x7f) == index && (flag&0x01) == flag);
+av_assert0((index&0x7f) == index && (flag&0x01) == flag);
 pic->bPicEntry = index | (flag << 7);
 }
 
@@ -194,8 +194,8 @@ void ff_dxva2_h264_fill_scaling_lists(const AVCodecContext 
*avctx, AVDXVAContext
 
 static int is_slice_short(const AVCodecContext *avctx, AVDXVAContext *ctx)
 {
-assert(DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) == 1 ||
-   DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) == 2);
+av_assert0(DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) == 1 ||
+   DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) == 2);
 return DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) == 2;
 }
 
@@ -348,10 +348,10 @@ static int 
commit_bitstream_and_slice_buffer(AVCodecContext *avctx,
 static const unsigned start_code_size = sizeof(start_code);
 unsigned position, size;
 
-assert(offsetof(DXVA_Slice_H264_Short, BSNALunitDataLocation) ==
-   offsetof(DXVA_Slice_H264_Long,  BSNALunitDataLocation));
-assert(offsetof(DXVA_Slice_H264_Short, SliceBytesInBuffer) ==
-   offsetof(DXVA_Slice_H264_Long,  SliceBytesInBuffer));
+av_assert0(offsetof(DXVA_Slice_H264_Short, BSNALunitDataLocation) ==
+   offsetof(DXVA_Slice_H264_Long,  BSNALunitDataLocation));
+av_assert0(offsetof(DXVA_Slice_H264_Short, SliceBytesInBuffer) ==
+   offsetof(DXVA_Slice_H264_Long,  SliceBytesInBuffer));
 
 if (is_slice_short(avctx, ctx))
 slice = &ctx_pic->slice_short[i];
@@ -453,7 +453,7 @@ static int dxva2_h264_start_frame(AVCodecContext *avctx,
 
 if (!DXVA_CONTEXT_VALID(avctx, ctx))
 return -1;
-assert(ctx_pic);
+av_assert0(ctx_pic);
 
 /* Fill up DXVA_PicParams_H264 */
 ff_dxva2_h264_fill_picture_parameters(avctx, ctx, &ctx_pic->pp);
diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
index 4c9ed1d761..d31a8bb872 100644
--- a/libavcodec/dxva2_mpeg2.c
+++ b/libavcodec/dxva2_mpeg2.c
@@ -264,7 +264,7 @@ static int dxva2_mpeg2_start_frame(AVCodecContext *avctx,
 
 if (!DXVA_CONTEXT_VALID(avctx, ctx))
 return -1;
-assert(ctx_pic);
+av_assert0(ctx_pic);
 
 ff_dxva2_mpeg2_fill_picture_parameters(avctx, ctx, &ctx_pic->pp);
 ff_dxva2_mpeg2_fill_quantization_matrices(avctx, ctx, &ctx_pic->qm);
diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
index 2b1b3f97ea..f7513b2b15 100644
--- a/libavcodec/dxva2_vc1.c
+++ b/libavcodec/dxva2_vc1.c
@@ -321,7 +321,7 @@ static int dxva2_vc1_start_frame(AVCodecContext *avctx,
 
 if (!DXVA_CONTEXT_VALID(avctx, ctx))
 return -1;
-assert(ctx_pic);
+av_assert0(ctx_pic);
 
 ff_dxva2_vc1_fill_picture_parameters(avctx, ctx, &ctx_pic->pp);
 
-- 
2.41.0.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 v2 4/5] avcodec/d3d12va_decode|dxva2: add a warning to replace assertion

2023-12-27 Thread Tong Wu 
Previous assertion was not useful. Now a warning is added to replace it.
For get_surface_index, we should return a zero index in case the index is not 
found.
But a warning is necessary to notify.

Signed-off-by: Tong Wu 
---
 libavcodec/d3d12va_decode.c | 3 +--
 libavcodec/dxva2.c  | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
index 50d5b8d601..babb2aaa0f 100644
--- a/libavcodec/d3d12va_decode.c
+++ b/libavcodec/d3d12va_decode.c
@@ -20,7 +20,6 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include 
 #include 
 #include 
 
@@ -80,7 +79,7 @@ unsigned ff_d3d12va_get_surface_index(const AVCodecContext 
*avctx,
 }
 
 fail:
-assert(0);
+av_log(avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 
instead.\n");
 return 0;
 }
 
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 7160a0008b..a6ad5e4dc7 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -795,7 +795,7 @@ unsigned ff_dxva2_get_surface_index(const AVCodecContext 
*avctx,
 }
 #endif
 
-assert(0);
+av_log(avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 
instead.\n");
 return 0;
 }
 
-- 
2.41.0.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] avfilter/vf_showinfo: add udu_sei_as_ascii option

2023-12-27 Thread Zhao Zhili 

> On Dec 21, 2023, at 11:05, Zhao Zhili  wrote:
> 
> 
>> On Dec 13, 2023, at 11:46, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> Some encoders (e.g., libx264) dump encoder configuration as user
>> data unregistered SEI message. This option try to print it as
>> ascii character when possible.
>> ---
>> doc/filters.texi  |  4 
>> libavfilter/version.h |  2 +-
>> libavfilter/vf_showinfo.c | 14 --
>> 3 files changed, 17 insertions(+), 3 deletions(-)
>> 
> 
> Ping. Any comments on this idea and implementation?

Applied. Hope it doesn’t make trouble during Christmas.

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".