Re: [FFmpeg-devel] [PATCH v08 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear
Hi Lynne, On Sat, 11 Jul, 2020, 20:31 C Hanish Menon, wrote: > Hi Lynne, > > On Sat, Jul 11, 2020 at 5:20 PM Lynne wrote: > >> Jul 11, 2020, 08:52 by hanish...@gmail.com: >> >> > ** fbtile cpu based framebuffer tile/detile helpers >> > >> > Add helper routines which can be used to tile/detile framebuffer >> > layouts between linear and specified tile layout, using the cpu. >> > >> > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and >> > Newer Intel Tile-Yf tiled layouts. >> > >> > Currently supported pixel format is 32bit RGB. >> > >> > It also contains fbtile_generic logic, which can be easily configured >> > to support different kinds of tiling layouts, at the expense of some >> > additional processing cycles, compared to developing custom (de)tiling >> > logic. One requires to provide the tile walking parameters for the >> > new tile layout to be supported. Once it is done, both tiling and >> > detiling of the new tile layout can be handled automatically. >> > >> > This is non-public by default. >> > >> >> I thought I made myself clear. No compile time public header options. >> That means no SCOPEIN, no HWCTXDRM_SYNCRELATED_FORMATMODIFIER, >> no DEBUG_FBTILE_FORMATMODIFIER_MAPPING, no FBTILE_SCOPE_PUBLIC, >> no FBTILER_OPTI_UNROLL (just always unroll), no FBTILER_GENERIC_OPTI, >> none of those please, at all. No, this is not up for discussion. >> > > Reason HWCTXDRM_SYNCRELATED_FORMATMODIFIER is provided is because > currently as the AVFrame doesn't have any generic tiling info related > member, so the related HW AVFrame is currently used to notify any other > users in future within hwcontext_drm that it has been detiled. But then > again has there is no single right or wrong way here at one level, so I put > it under a ifdef block and what I felt as a potentially sane default for > now was set for the same. > > The DEBUG defs (DEBUG_FBTILE and DEBUG_...MAPPING) are provided so that in > future, if someone wants to debug the flow for some reason like say a new > tile layout being added or some other reason, then they don't have to hunt > as to where to put debug prints to help understand the flow, instead they > could use the already available compile time option to enable the debug > logs and then get one level of understanding. And again currently a sane > default of keeping it disabled (undef'd) is used. > > The reason UNROLL is put within ifdef is because if for some reason a > tiling layout which involves less than 4x4 subtile block is required to be > supported in future, then the unrolling will need to be avoided in this > function or a new function without unrolling will have to be created. Again > to help a future developer who may face such a situation, the code is > properly identified and put into suitable ifdef blocks and suitably > commented in the code. Again a sane default which is fine for the current > situation is setup. > Rather to be more clear, once unrolled the logic can't be used for subtiles and walks involving non multiples of 4 (along vertical direction) in this case. Will modify code to use unrolled opti version where this condition is satisfied, which is the case for currently supported tile layouts. At same time if this condition is not met by a new layout in future, the non parallel simple version, which is also provided, can be used. The same is noted as a comment in the code. > Again the idea of FBTILE_SCOPE_PUBLIC, is so that a logically independent > code, can be embedded into a some other code in a structured way, while at > same time providing the flexibility to move it into a independent public > api if required in future, if another use case for the logic comes up. > Had a look at the ffmpeg coding convention, will use the ff_ prefixed convention for non static but internal to library helper functions. That will keep the code simple and clean, while allowing it to be used by others if required in future. > I do agree that these compile time options won't be changed in a normal > compile, but then again it is not for a normal compile situation, but for > future flow changes if required in future for a developer (or a user who > wants to experiment) who may have to touch the code. > > I am not sure your way of thinking of trying to structure everything to an > immediate specific need, is the right way of approaching things in general, > when the underlying logic is in reality independent and even when things > are potentially (I do accept different people may implement the things in > slightly different ways) structured in a sane way to provide future > flexibility. > > At the same time I appreciate and am thankful to the volunteering you and > other developers are doing here and will change the code to be more > specific if you still feel that is what you, as an active ffmpeg developer, > feel. > > I can't review this patch well at all with this. >> You can depend on CONFIG_LIBDRM always being available, as we're never >> ever >> going
Re: [FFmpeg-devel] [PATCH v8 3/3] avdevice/decklink_dec: export timecode with s12m side data
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavdevice/decklink_dec.cpp | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index a499972..146f56f 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -42,6 +42,7 @@ extern "C" {
> #include "libavutil/imgutils.h"
> #include "libavutil/intreadwrite.h"
> #include "libavutil/time.h"
> +#include "libavutil/timecode.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/reverse.h"
> #include "avdevice.h"
> @@ -882,6 +883,19 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
> AVDictionary* metadata_dict = NULL;
> int metadata_len;
> uint8_t* packed_metadata;
> +AVTimecode tcr;
> +
> +if (av_timecode_init_from_string(,
> ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> +uint32_t tc_data =
> av_timecode_get_smpte_from_framenum(, 0);
> +int size = sizeof(uint32_t) * 4;
> +uint8_t *sd = av_packet_new_side_data(,
> AV_PKT_DATA_S12M_TIMECODE, size);
> +
> +if (sd) {
> +AV_WL32(sd, 1); // one TC ;
Nit: why is there a space after TC?
> +AV_WL32(sd + 4, tc_data); // TC;
This contradicts the documentation of AV_PKT_DATA_S12M_TIMECODE, because
you are always using little endian here. But the documentation [1] does
not specify an endianness, it uses native endianness (in accordance with
what AV_FRAME_DATA_S12M_TIMECODE does). This very same patch also uses
native endianness in libavformat/dump.c.
I consider it a mistake to use native endianness for the frame side data
and an uint32_t in av_timecode_get_smpte (none of the fields cross a
byte boundary, so each entry could easily have been an uint8_t[4]), as
this will make it harder to test this side data via fate; but I also see
the advantage of using the same format and the same helper functions for
both. What do others think about this? After all, we can still change
the format for the packet side data.
- Andreas
[1]:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1593610798-21093-2-git-send-email-lance.lmw...@gmail.com/
(Is this even the latest version? I haven't paid close attention to this
patchset tbh.)
___
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] tools/coverity: override av_dict_set
On 11.07.2020 22:17, Andreas Rheinhardt wrote:
Timo Rothenpieler:
Coverity thinks av_dict_set frees the key and value parameter, because
it has the (rarely used) option to do so, and it's not smart enough to
figure out it depends on the flags parameter.
So lets provide a custom implementation that does not free them.
---
tools/coverity.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/coverity.c b/tools/coverity.c
index 19a132a976..5e4eb19f39 100644
--- a/tools/coverity.c
+++ b/tools/coverity.c
@@ -77,3 +77,12 @@ void *av_free(void *ptr) {
__coverity_mark_as_afm_freed__(ptr, "av_free");
}
+int av_dict_set(void **pm, const char *key, const char *value, int flags) {
+int has_memory;
+if (has_memory) {
+return 0;
+} else {
+return -1;
+}
+}
+
1. Won't this lead to a use-of-uninitialized-value warning?
No, since this is never actually compiled, but given to coverity
(manually) as hints file.
You just need to make branch points for it to analyze.
2. This is a trade-off, isn't it? Coverity will then think that all the
cases where the AV_DICT_DONT_STRDUP_* flags are used lead to leaks,
won't it? If so, this shoul be mentioned in the commit message.
Yeah, but those seem to be rarely used, while the case where it's 0 and
causes errors is happening a whole lot.
3. Furthermore, this model does not actually set anything: pm is
unchanged. Given that av_dict_set is the only function that actually
allocates an AVDictionary, Coverity might infer that lots of
AVDictionary * are in fact NULL; this might lead it to think that
certain code is dead although it isn't. Is there a way we can just use
the ordinary implementation of av_dict_set, but without the
AV_DICT_DONT_STRDUP_* flags?
Not easily, since one cannot include other files here, and only use very
basic features that coverity can understand.
Yeah, some more side effects will probably have to be built in, but
still, given that coverity never actually runs the code, and only runs
static analysis on it, a lot of normally nonsensical shortcuts can be made.
- Andreas
___
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] Bug in FFMPEG video filter TINTERLACE needs fixing
I was assuming it started from 1, because in the NTSC video standard (which is of course where the concept of interlaced video originated), the first field is called field 1. Field 1 contains the first full line of displayed video (though technically field 2 contains the first image data, one line above the first displayed line of field 1, although it's only the right half of that line). On Sat, Jul 11, 2020 at 4:07 AM Paul B Mahol wrote: > On 7/11/20, Ben Hutchinson wrote: > > I was reading it directly from the official FFMPEG website. > > https://ffmpeg.org/ffmpeg-filters.html > > All the info about the TINTERLACE filter I got from reading the info > there. > > > > OK, lets try again, where have you read that first frame is always an > odd frame, one with 1 number. > FFmpeg counts from 0. > > > On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol wrote: > > > >> On 7/8/20, Ben Hutchinson wrote: > >> > According to the documentation on the TINTERLACE video filter, the > >> > filter > >> > mode called MERGEX2 will "Move odd frames into the upper field, even > >> > into > >> > the lower field, generating a double height frame at same frame rate." > >> But > >> > it doesn't do this, at least in some cases (not sure about all cases). > >> The > >> > first frame in a sequence should be considered frame one (an odd > frame) > >> for > >> > >> Where is this written? > >> > >> > the purpose of this interlacing algorithm. However, that is not what's > >> > happening in my experience. At least with raw video (using "-f > >> > rawvideo") > >> > it's treating the first frame as frame zero (an even frame) and thus > my > >> > first frame (which contains top-field data) ends up getting put into > the > >> > bottom-field of the output video, and this is messing up the output. > >> Please > >> > fix this. > >> > ___ > >> > 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". > ___ > 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 v8 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Sun, 12 Jul 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index a499972..146f56f 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -42,6 +42,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/time.h"
+#include "libavutil/timecode.h"
#include "libavutil/mathematics.h"
#include "libavutil/reverse.h"
#include "avdevice.h"
@@ -882,6 +883,19 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
AVDictionary* metadata_dict = NULL;
int metadata_len;
uint8_t* packed_metadata;
+AVTimecode tcr;
+
+if (av_timecode_init_from_string(,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+uint32_t tc_data =
av_timecode_get_smpte_from_framenum(, 0);
+int size = sizeof(uint32_t) * 4;
+uint8_t *sd = av_packet_new_side_data(,
AV_PKT_DATA_S12M_TIMECODE, size);
+
+if (sd) {
+AV_WL32(sd, 1); // one TC ;
+AV_WL32(sd + 4, tc_data); // TC;
+}
+}
+
if (av_dict_set(_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
packed_metadata =
av_packet_pack_dictionary(metadata_dict, _len);
av_dict_free(_dict);
LGTM, thanks.
Marton
___
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] checkasm/vf_blend: use the correct depth parameters to initialize the blend modes
This effectively enables the tests that until now were just running the C version alone. Signed-off-by: James Almer --- tests/checkasm/vf_blend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blend.c index a7578fec39..bdd21d4986 100644 --- a/tests/checkasm/vf_blend.c +++ b/tests/checkasm/vf_blend.c @@ -99,7 +99,7 @@ void checkasm_check_blend(void) #define check_and_report(name, val, depth)\ param.mode = val; \ -ff_blend_init(, depth - 1); \ +ff_blend_init(, depth * 8); \ if (check_func(param.blend, #name)) \ check_blend_func(depth); -- 2.27.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Sat, Jul 11, 2020 at 07:13:31PM +0200, Marton Balint wrote:
>
>
> On Fri, 10 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavdevice/decklink_dec.cpp | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index a499972..8adc00b 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -42,6 +42,7 @@ extern "C" {
> > #include "libavutil/imgutils.h"
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/time.h"
> > +#include "libavutil/timecode.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/reverse.h"
> > #include "avdevice.h"
> > @@ -882,6 +883,21 @@ HRESULT
> > decklink_input_callback::VideoInputFrameArrived(
> > AVDictionary* metadata_dict = NULL;
> > int metadata_len;
> > uint8_t* packed_metadata;
> > +AVTimecode tcr;
> > +
> > +if (av_timecode_init_from_string(,
> > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > +uint32_t tc_data;
> > +uint8_t *sd;
> > +int size = sizeof(uint32_t) * 4;
> > +
> > +tc_data =
> > av_timecode_get_smpte_from_framenum(, 0);
> > +sd = av_packet_new_side_data(,
> > AV_PKT_DATA_S12M_TIMECODE, size);
>
> You can put these two into the same line as the declaration if you
> initialize size first.
Sure, have updated the patch, please check it, thanks.
>
> > +if (sd) {
> > +AV_WL32(sd, 1); // one TC ;
> > +AV_WL32(sd + 4, tc_data); // TC;
> > +}
> > +}
> > +
>
> Regards,
> Marton
>
> > if (av_dict_set(_dict, "timecode", tc,
> > AV_DICT_DONT_STRDUP_VAL) >= 0) {
> > packed_metadata =
> > av_packet_pack_dictionary(metadata_dict, _len);
> > av_dict_free(_dict);
> > --
> > 1.8.3.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 email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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 v8 3/3] avdevice/decklink_dec: export timecode with s12m side data
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index a499972..146f56f 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -42,6 +42,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/time.h"
+#include "libavutil/timecode.h"
#include "libavutil/mathematics.h"
#include "libavutil/reverse.h"
#include "avdevice.h"
@@ -882,6 +883,19 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
AVDictionary* metadata_dict = NULL;
int metadata_len;
uint8_t* packed_metadata;
+AVTimecode tcr;
+
+if (av_timecode_init_from_string(,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+uint32_t tc_data =
av_timecode_get_smpte_from_framenum(, 0);
+int size = sizeof(uint32_t) * 4;
+uint8_t *sd = av_packet_new_side_data(,
AV_PKT_DATA_S12M_TIMECODE, size);
+
+if (sd) {
+AV_WL32(sd, 1); // one TC ;
+AV_WL32(sd + 4, tc_data); // TC;
+}
+}
+
if (av_dict_set(_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
packed_metadata =
av_packet_pack_dictionary(metadata_dict, _len);
av_dict_free(_dict);
--
1.8.3.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/2] swscale/tests/swscale: Initialize res to a non random error code
Regression since: 3adffab073bc59af39035168ac72bc9ffde3
-1 is consistent what other error paths return
Signed-off-by: Michael Niedermayer
---
libswscale/tests/swscale.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index 58870fdb78..845ced61bb 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -423,8 +423,10 @@ bad_option:
for (x = 0; x < W * 4; x++)
rgb_data[ x + y * 4 * W] = av_lfg_get();
res = sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *)
src, stride);
-if (res < 0 || res != H)
+if (res < 0 || res != H) {
+res = -1;
goto error;
+}
sws_freeContext(sws);
av_free(rgb_data);
--
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] [PATCH 1/2] swscale/tests/swscale: Fix incorrect return code check
Regression since: 3adffab073bc59af39035168ac72bc9ffde3 Signed-off-by: Michael Niedermayer --- libswscale/tests/swscale.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c index 693f439bf5..58870fdb78 100644 --- a/libswscale/tests/swscale.c +++ b/libswscale/tests/swscale.c @@ -423,7 +423,7 @@ bad_option: for (x = 0; x < W * 4; x++) rgb_data[ x + y * 4 * W] = av_lfg_get(); res = sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) src, stride); -if (res < 0 || res != (H / 12)) +if (res < 0 || res != H) goto error; sws_freeContext(sws); av_free(rgb_data); -- 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".
Re: [FFmpeg-devel] [PATCH 1/1] MAINTAINERS: add myself and gpg fingerprint
On Tue, Jul 07, 2020 at 03:26:38PM +, Zane van Iperen wrote: > Signed-off-by: Zane van Iperen > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) will apply this soon unless i hear objections thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tools/coverity: override av_dict_set
Timo Rothenpieler:
> Coverity thinks av_dict_set frees the key and value parameter, because
> it has the (rarely used) option to do so, and it's not smart enough to
> figure out it depends on the flags parameter.
> So lets provide a custom implementation that does not free them.
> ---
> tools/coverity.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/tools/coverity.c b/tools/coverity.c
> index 19a132a976..5e4eb19f39 100644
> --- a/tools/coverity.c
> +++ b/tools/coverity.c
> @@ -77,3 +77,12 @@ void *av_free(void *ptr) {
> __coverity_mark_as_afm_freed__(ptr, "av_free");
> }
>
> +int av_dict_set(void **pm, const char *key, const char *value, int flags) {
> +int has_memory;
> +if (has_memory) {
> +return 0;
> +} else {
> +return -1;
> +}
> +}
> +
>
1. Won't this lead to a use-of-uninitialized-value warning?
2. This is a trade-off, isn't it? Coverity will then think that all the
cases where the AV_DICT_DONT_STRDUP_* flags are used lead to leaks,
won't it? If so, this shoul be mentioned in the commit message.
3. Furthermore, this model does not actually set anything: pm is
unchanged. Given that av_dict_set is the only function that actually
allocates an AVDictionary, Coverity might infer that lots of
AVDictionary * are in fact NULL; this might lead it to think that
certain code is dead although it isn't. Is there a way we can just use
the ordinary implementation of av_dict_set, but without the
AV_DICT_DONT_STRDUP_* flags?
- Andreas
___
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] tools/coverity: override av_dict_set
Coverity thinks av_dict_set frees the key and value parameter, because
it has the (rarely used) option to do so, and it's not smart enough to
figure out it depends on the flags parameter.
So lets provide a custom implementation that does not free them.
---
tools/coverity.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/coverity.c b/tools/coverity.c
index 19a132a976..5e4eb19f39 100644
--- a/tools/coverity.c
+++ b/tools/coverity.c
@@ -77,3 +77,12 @@ void *av_free(void *ptr) {
__coverity_mark_as_afm_freed__(ptr, "av_free");
}
+int av_dict_set(void **pm, const char *key, const char *value, int flags) {
+int has_memory;
+if (has_memory) {
+return 0;
+} else {
+return -1;
+}
+}
+
--
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 v2 2/2] lavf/udp: fix the commets for defalt UDP socket recvbuf size
Marton Balint (12020-07-11): > LGTM, thanks. Whoever pushes, fix the typo in the commit message please. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Fri, 10 Jul 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index a499972..8adc00b 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -42,6 +42,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/time.h"
+#include "libavutil/timecode.h"
#include "libavutil/mathematics.h"
#include "libavutil/reverse.h"
#include "avdevice.h"
@@ -882,6 +883,21 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
AVDictionary* metadata_dict = NULL;
int metadata_len;
uint8_t* packed_metadata;
+AVTimecode tcr;
+
+if (av_timecode_init_from_string(,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+uint32_t tc_data;
+uint8_t *sd;
+int size = sizeof(uint32_t) * 4;
+
+tc_data =
av_timecode_get_smpte_from_framenum(, 0);
+sd = av_packet_new_side_data(,
AV_PKT_DATA_S12M_TIMECODE, size);
You can put these two into the same line as the declaration if you
initialize size first.
+if (sd) {
+AV_WL32(sd, 1); // one TC ;
+AV_WL32(sd + 4, tc_data); // TC;
+}
+}
+
Regards,
Marton
if (av_dict_set(_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
packed_metadata =
av_packet_pack_dictionary(metadata_dict, _len);
av_dict_free(_dict);
--
1.8.3.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 email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavf/udp: fix the commets for defalt UDP socket recvbuf size
On Sat, 11 Jul 2020, Jun Zhao wrote:
From: Jun Zhao
15d160cc0b2 increased the UDP socket receiving buffer size
(64K ->384K), but missed to update this comments.
Signed-off-by: Jun Zhao
---
libavformat/udp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index ad6992c..30d8041 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -852,7 +852,7 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
goto fail;
}
} else {
-/* set udp recv buffer size to the requested value (default 64K) */
+/* set udp recv buffer size to the requested value (default
UDP_RX_BUF_SIZE) */
tmp = s->buffer_size;
if (setsockopt(udp_fd, SOL_SOCKET, SO_RCVBUF, , sizeof(tmp)) < 0) {
ff_log_net_error(h, AV_LOG_WARNING, "setsockopt(SO_RECVBUF)");
LGTM, thanks.
Marton
___
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/mov: fix atom type to string conversion
The conversion was endian-dependent, and it may contain non-printable
characters.
---
libavformat/mov.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index da438e4e2c..ba05223cd0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -297,7 +297,7 @@ static int mov_metadata_hmmt(MOVContext *c, AVIOContext
*pb, unsigned len)
static int mov_read_udta_string(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
-char tmp_key[5];
+char tmp_key[AV_FOURCC_MAX_STRING_SIZE] = {0};
char key2[32], language[4] = {0};
char *str = NULL;
const char *key = NULL;
@@ -444,8 +444,7 @@ retry:
str_size = atom.size;
if (c->export_all && !key) {
-snprintf(tmp_key, 5, "%.4s", (char*));
-key = tmp_key;
+key = av_fourcc_make_string(tmp_key, atom.type);
}
if (!key)
@@ -7024,8 +7023,8 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
avio_skip(pb, left);
else if (left < 0) {
av_log(c->fc, AV_LOG_WARNING,
- "overread end of atom '%.4s' by %"PRId64" bytes\n",
- (char*), -left);
+ "overread end of atom '%s' by %"PRId64" bytes\n",
+ av_fourcc2str(a.type), -left);
avio_seek(pb, left, SEEK_CUR);
}
}
--
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] libavfilter/glslang: Remove unused header
Jul 10, 2020, 16:53 by bclayton-at-google@ffmpeg.org: > The include was not used, and revision.h has > been removed from glslang master. > See: https://github.com/KhronosGroup/glslang/pull/2277 > Thanks, pushed. ___ 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 v08 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear
Jul 11, 2020, 08:52 by hanish...@gmail.com: > ** fbtile cpu based framebuffer tile/detile helpers > > Add helper routines which can be used to tile/detile framebuffer > layouts between linear and specified tile layout, using the cpu. > > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and > Newer Intel Tile-Yf tiled layouts. > > Currently supported pixel format is 32bit RGB. > > It also contains fbtile_generic logic, which can be easily configured > to support different kinds of tiling layouts, at the expense of some > additional processing cycles, compared to developing custom (de)tiling > logic. One requires to provide the tile walking parameters for the > new tile layout to be supported. Once it is done, both tiling and > detiling of the new tile layout can be handled automatically. > > This is non-public by default. > I thought I made myself clear. No compile time public header options. That means no SCOPEIN, no HWCTXDRM_SYNCRELATED_FORMATMODIFIER, no DEBUG_FBTILE_FORMATMODIFIER_MAPPING, no FBTILE_SCOPE_PUBLIC, no FBTILER_OPTI_UNROLL (just always unroll), no FBTILER_GENERIC_OPTI, none of those please, at all. No, this is not up for discussion. I can't review this patch well at all with this. You can depend on CONFIG_LIBDRM always being available, as we're never ever going to be using this code outside of hwcontext_drm.c. We align our switch cases with the switch indentation, so no extra indent. Its not a block. Use av_log instead of av_log_once. Also fix the changelog. And please stop submitting the fbdetile filter patch, even for informative reasons. Just dump it in a git repository somewhere. > +// Common return values> +#define FBT_OK 0> +#define FBT_ERR 1 Really? Use 0 for ok and AVERROR... for errors. > +/*> + * Copy one AVFrame into the other, tiling or detiling as required, if > possible.> + * NOTE: Either the Source or the Destination AVFrame (i.e one of > them) should be linear.> + * NOTE: If the tiling layout is not understood, it > will do a simple copy.> + */ If the contents aren't going to change you can avoid copying by just using av_frame_ref. Like I said, this is just a fraction of what I can review with all those ifdefs around the code. ___ 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 v06 2/5] fbtile helperRoutines cpu based framebuffer detiling
Hi Mark,
On Mon, Jul 6, 2020 at 4:18 AM Mark Thompson wrote:
> On 04/07/2020 14:17, hanishkvc wrote:
> > Add helper routines which can be used to detile tiled framebuffer
> > layouts into a linear layout, using the cpu.
> >
> > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
> > Newer Intel Tile-Yf tiled layouts.
> >
> > Currently supported pixel format is 32bit RGB.
> >
> > It also contains detile_generic logic, which can be easily configured
> > to support different kinds of tiling layouts, at the expense of some
> > processing speed, compared to developing a targeted detiling logic.
> > ---
> > libavutil/Makefile | 2 +
> > libavutil/fbtile.c | 441 +
> > libavutil/fbtile.h | 228 +++
> > 3 files changed, 671 insertions(+)
> > create mode 100644 libavutil/fbtile.c
> > create mode 100644 libavutil/fbtile.h
>
> I do think this is a reasonable thing to include in FFmpeg, but please
> think about what you actually want as a public API here.
>
> Ideally you want to minimise the public API surface while providing
> something clean and of general use.
>
> So:
> - It should probably operate on whole frames - copying pieces of frames or
> single planes doesn't have any obvious use.
> - The pixel format, width, height and pitches will all need to be
> specified, so AVFrames which already include that information are probably
> the right structure to use.
> - You want to specify a tiling mode for the source frame somehow.
> - For the untile case the destination is linear, but a plausible use-case
> is the opposite so we could include tiling mode for the destination as well.
> - The tiling modes will need to be some sort of enum, since they are all
> ad-hoc setups for particular hardware vendors.
> - We can't reuse existing values like those from libdrm because we'd like
> it to work everywhere it can and there is no intrinsic dependence on
> libdrm, so it needs to be a new enum.
> - Names for the tiling modes should be valid everywhere, so if they are
> platform-dependent (like Intel X/Y tiling) then the platform will need to
> be included in the name.
> - Linear should be in the tiling mode enum, so that you don't need special
> cases elsewhere.
> - All the dispatch between different implementations can happen
> internally, so it doesn't need to be exposed.
> - Not everything will actually be implemented, so it will need to be able
> to return an error indicating that a particular case is not available.
>
> Given that, I make the desired public API to be exactly one enum and one
> function. It would look something like:
>
> enum AVTilingMode {
>AV_TILING_MODE_LINEAR = 0,
>AV_TILING_MODE_INTEL_GEN7_X,
>AV_TILING_MODE_INTEL_GEN7_Y,
>AV_TILING_MODE_INTEL_GEN9_X,
>AV_TILING_MODE_INTEL_GEN9_Y,
>AV_TILING_MODE_INTEL_YF,
> };
>
> int av_frame_copy_with_tiling(const AVFrame *dst, enum AVTilingMode
> dst_tiling,
>const AVFrame *src, enum AVTilingMode
> src_tiling);
>
>
> Some other thoughts:
> - Functions should all be static unless you are intentionally exposing
> them as public API.
> - Libraries must not include mutable globals.
> - Note that av_log(NULL, ...) should never be called from a library unless
> you really are in a global context. I think you probably just don't want
> to include any user-facing logging at all.
> - Look at the coding style guide, especially around naming and operator
> spacing.
>
>
Thanks for the feedback. I thought your suggestion about
av_frame_copy_with_tiling was good. However as you and Lynne seem to have
discussed further and concluded not to expose a public api like
av_frame_copy_with_tiling, so the equivalent function which I had, which
has been further updated to support tiling also (in addition to detiling,
so that is a more fuller copy), I have named as fbtile_frame_copy (it is
limited to the 3 common Intel tile formats, the logic is extendable in a
easy way for new tile layouts) in my new patch.
In future if ffmpeg is implementing such an api, you may also want to add
an additional status argument, which will indicate as to whether the logic
did only a plain copy or a tile/detile based copy. As the user of the
function may want indication as to whether the tiling related operation was
done or not (may not be done, because the combination of
pixelformat+planes+tile layout involved may not be supported). At the same
time still retaining the simple 0 for success (a fall back plain copy can
still be a valid copy at one level) function return value.
Also you may require two additional public api
one) which maps from a hardware(and related) context specific tile layout
id to the tile layout id used by the ffmpeg avframe tile support logic.
two) which tells whether the combination of pixel format (+ planes) + tile
layout is supported or not.
Just for my understanding, if a library wants to log something, so that it
doesnt chain
Re: [FFmpeg-devel] [PATCH v08 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear
Hi Lynne, On Sat, Jul 11, 2020 at 5:20 PM Lynne wrote: > Jul 11, 2020, 08:52 by hanish...@gmail.com: > > > ** fbtile cpu based framebuffer tile/detile helpers > > > > Add helper routines which can be used to tile/detile framebuffer > > layouts between linear and specified tile layout, using the cpu. > > > > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and > > Newer Intel Tile-Yf tiled layouts. > > > > Currently supported pixel format is 32bit RGB. > > > > It also contains fbtile_generic logic, which can be easily configured > > to support different kinds of tiling layouts, at the expense of some > > additional processing cycles, compared to developing custom (de)tiling > > logic. One requires to provide the tile walking parameters for the > > new tile layout to be supported. Once it is done, both tiling and > > detiling of the new tile layout can be handled automatically. > > > > This is non-public by default. > > > > I thought I made myself clear. No compile time public header options. > That means no SCOPEIN, no HWCTXDRM_SYNCRELATED_FORMATMODIFIER, > no DEBUG_FBTILE_FORMATMODIFIER_MAPPING, no FBTILE_SCOPE_PUBLIC, > no FBTILER_OPTI_UNROLL (just always unroll), no FBTILER_GENERIC_OPTI, > none of those please, at all. No, this is not up for discussion. > Reason HWCTXDRM_SYNCRELATED_FORMATMODIFIER is provided is because currently as the AVFrame doesn't have any generic tiling info related member, so the related HW AVFrame is currently used to notify any other users in future within hwcontext_drm that it has been detiled. But then again has there is no single right or wrong way here at one level, so I put it under a ifdef block and what I felt as a potentially sane default for now was set for the same. The DEBUG defs (DEBUG_FBTILE and DEBUG_...MAPPING) are provided so that in future, if someone wants to debug the flow for some reason like say a new tile layout being added or some other reason, then they don't have to hunt as to where to put debug prints to help understand the flow, instead they could use the already available compile time option to enable the debug logs and then get one level of understanding. And again currently a sane default of keeping it disabled (undef'd) is used. The reason UNROLL is put within ifdef is because if for some reason a tiling layout which involves less than 4x4 subtile block is required to be supported in future, then the unrolling will need to be avoided in this function or a new function without unrolling will have to be created. Again to help a future developer who may face such a situation, the code is properly identified and put into suitable ifdef blocks and suitably commented in the code. Again a sane default which is fine for the current situation is setup. Again the idea of FBTILE_SCOPE_PUBLIC, is so that a logically independent code, can be embedded into a some other code in a structured way, while at same time providing the flexibility to move it into a independent public api if required in future, if another use case for the logic comes up. I do agree that these compile time options won't be changed in a normal compile, but then again it is not for a normal compile situation, but for future flow changes if required in future for a developer (or a user who wants to experiment) who may have to touch the code. I am not sure your way of thinking of trying to structure everything to an immediate specific need, is the right way of approaching things in general, when the underlying logic is in reality independent and even when things are potentially (I do accept different people may implement the things in slightly different ways) structured in a sane way to provide future flexibility. At the same time I appreciate and am thankful to the volunteering you and other developers are doing here and will change the code to be more specific if you still feel that is what you, as an active ffmpeg developer, feel. I can't review this patch well at all with this. > You can depend on CONFIG_LIBDRM always being available, as we're never ever > going to be using this code outside of hwcontext_drm.c. > As what I have mentioned above already, you seem to want to structure the code to be very specific to the current immediate use case, while I normally prefer structuring things to be flexible and adaptable for the unknown future, especially when the logic in question is in reality independent at one level. Also in this case I feel it is a sensible ifdef'd block for drm specific code (to map from format_modifier to the logic's id for the tiling layout) in an otherwise generic logic and we should retain it. > We align our switch cases with the switch indentation, so no extra indent. > Its not a block. > Understood the ffmpeg convention, will update. > Use av_log instead of av_log_once. > In a video flow, has the same unwanted setup can trigger more than once in a single run, like say an unknown tile layout, in such a situation I didnt want to flood
[FFmpeg-devel] [PATCH 3/3 v2] x86/vf_blend: fix warnings about trailing empty parameters
Signed-off-by: James Almer --- Now generating the same output as before. The checkasm test needs to be fixed. libavfilter/x86/vf_blend.asm | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm index 251bbb5a12..766e5b7bc1 100644 --- a/libavfilter/x86/vf_blend.asm +++ b/libavfilter/x86/vf_blend.asm @@ -38,11 +38,11 @@ pb_255: times 16 db 255 SECTION .text -%macro BLEND_INIT 2-3 +%macro BLEND_INIT 2-3 0 %if ARCH_X86_64 cglobal blend_%1, 6, 9, %2, top, top_linesize, bottom, bottom_linesize, dst, dst_linesize, width, end, x movwidthd, dword widthm -%if %0 == 3; is 16 bit +%if %3; is 16 bit addwidthq, widthq ; doesn't compile on x86_32 %endif %else @@ -66,7 +66,7 @@ cglobal blend_%1, 5, 7, %2, top, top_linesize, bottom, bottom_linesize, dst, end REP_RET %endmacro -%macro BLEND_SIMPLE 2-3 +%macro BLEND_SIMPLE 2-3 0 BLEND_INIT %1, 2, %3 .nextrow: movxq, widthq @@ -82,10 +82,10 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro GRAINEXTRACT 3-4 +%macro GRAINEXTRACT 3-4 0 BLEND_INIT %1, 6, %4 pxor m4, m4 -%if %0 == 4 ; 16 bit +%if %4 ; 16 bit VBROADCASTI128 m5, [pd_32768] %else VBROADCASTI128 m5, [pw_128] @@ -182,7 +182,7 @@ BLEND_END %endmacro ;%1 name, %2 (b or w), %3 (set if 16 bit) -%macro AVERAGE 2-3 +%macro AVERAGE 2-3 0 BLEND_INIT %1, 3, %3 pcmpeqbm2, m2 @@ -203,10 +203,10 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro GRAINMERGE 3-4 +%macro GRAINMERGE 3-4 0 BLEND_INIT %1, 6, %4 pxor m4, m4 -%if %0 == 4 ; 16 bit +%if %4 ; 16 bit VBROADCASTI128 m5, [pd_32768] %else VBROADCASTI128 m5, [pw_128] @@ -288,7 +288,7 @@ BLEND_INIT divide, 4 BLEND_END %endmacro -%macro PHOENIX 2-3 +%macro PHOENIX 2-3 0 ; %1 name, %2 b or w, %3 (opt) 1 if 16 bit BLEND_INIT %1, 4, %3 VBROADCASTI128 m3, [pb_255] @@ -311,7 +311,7 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro DIFFERENCE 3-4 +%macro DIFFERENCE 3-4 0 BLEND_INIT %1, 5, %4 pxor m2, m2 .nextrow: @@ -326,7 +326,7 @@ BLEND_INIT %1, 5, %4 punpckl%2%3 m1, m2 psub%3 m0, m1 psub%3 m3, m4 -%if %0 == 4; 16 bit +%if %4; 16 bit pabsd m0, m0 pabsd m3, m3 %else @@ -340,10 +340,10 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro EXTREMITY 3-4 +%macro EXTREMITY 3-4 0 BLEND_INIT %1, 8, %4 pxor m2, m2 -%if %0 == 4; 16 bit +%if %4; 16 bit VBROADCASTI128 m4, [pd_65535] %else VBROADCASTI128 m4, [pw_255] @@ -362,7 +362,7 @@ BLEND_INIT %1, 8, %4 psub%3 m7, m4, m5 psub%3 m3, m1 psub%3 m7, m6 -%if %0 == 4; 16 bit +%if %4; 16 bit pabsd m3, m3 pabsd m7, m7 %else @@ -375,10 +375,10 @@ BLEND_INIT %1, 8, %4 BLEND_END %endmacro -%macro NEGATION 3-4 +%macro NEGATION 3-4 0 BLEND_INIT %1, 8, %4 pxor m2, m2 -%if %0 == 4; 16 bit +%if %4; 16 bit VBROADCASTI128 m4, [pd_65535] %else VBROADCASTI128 m4, [pw_255] @@ -397,7 +397,7 @@ BLEND_INIT %1, 8, %4 psub%3 m7, m4, m5 psub%3 m3, m1 psub%3 m7, m6 -%if %0 == 4; 16 bit +%if %4; 16 bit pabsd m3, m3 pabsd m7, m7 %else -- 2.27.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] x86/vf_blend: fix warnings about trailing empty parameters
On 7/10/2020 6:54 PM, Henrik Gramner wrote: > On Thu, Jul 9, 2020 at 4:54 PM James Almer wrote: >> @@ -38,7 +38,7 @@ pb_255: times 16 db 255 >> >> SECTION .text >> >> -%macro BLEND_INIT 2-3 >> +%macro BLEND_INIT 2 >> %if ARCH_X86_64 >> cglobal blend_%1, 6, 9, %2, top, top_linesize, bottom, bottom_linesize, >> dst, dst_linesize, width, end, x >> movwidthd, dword widthm > > Wont this change the output? width was previously doubled a few lines > down when called with three args (%0 means "number of arguments"). > > The existing macro is written in a somewhat obfuscated way using the > number of arguments as an implicit boolean flag, instead of just using > a boolean flag directly. > > Maybe it'd be better to change this macro to have 3 fixed arguments > and use %3 instead of %0 == 3 in combination with adding a default 0 > value in the other macros with a variable number of arguments, e.g. > "%macro BLEND_SIMPLE 2-3 0" You're right, i had missed the %0 checks. I'm surprised the checkasm test didn't break after this, seeing it does seemingly test 16bit. Will send a new version that generates the same output. ___ 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] avfilter/vf_tinterlace: fix mergex2, first frame is always considered odd
Signed-off-by: Paul B Mahol --- libavfilter/vf_tinterlace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c index d145e35520..542b66898e 100644 --- a/libavfilter/vf_tinterlace.c +++ b/libavfilter/vf_tinterlace.c @@ -396,12 +396,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *picref) copy_picture_field(tinterlace, out->data, out->linesize, (const uint8_t **)cur->data, cur->linesize, inlink->format, inlink->w, inlink->h, - FIELD_UPPER_AND_LOWER, 1, tinterlace->mode == MODE_MERGEX2 ? inlink->frame_count_out & 1 ? FIELD_LOWER : FIELD_UPPER : FIELD_UPPER, tinterlace->flags); + FIELD_UPPER_AND_LOWER, 1, tinterlace->mode == MODE_MERGEX2 ? (1 + inlink->frame_count_out) & 1 ? FIELD_LOWER : FIELD_UPPER : FIELD_UPPER, tinterlace->flags); /* write even frame lines into the lower field of the new frame */ copy_picture_field(tinterlace, out->data, out->linesize, (const uint8_t **)next->data, next->linesize, inlink->format, inlink->w, inlink->h, - FIELD_UPPER_AND_LOWER, 1, tinterlace->mode == MODE_MERGEX2 ? inlink->frame_count_out & 1 ? FIELD_UPPER : FIELD_LOWER : FIELD_LOWER, tinterlace->flags); + FIELD_UPPER_AND_LOWER, 1, tinterlace->mode == MODE_MERGEX2 ? (1 + inlink->frame_count_out) & 1 ? FIELD_UPPER : FIELD_LOWER : FIELD_LOWER, tinterlace->flags); if (tinterlace->mode != MODE_MERGEX2) av_frame_free(>next); break; -- 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] lavfi/setpts: fix setpts/asetpts option dump error
ok
On 7/11/20, Jun Zhao wrote:
> From: Jun Zhao
>
> fix the command ffmpeg -h filter=setpts/asetpts both dump the expr
> option with "FVA" flags.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/setpts.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
> index 6506653..440a218 100644
> --- a/libavfilter/setpts.c
> +++ b/libavfilter/setpts.c
> @@ -262,14 +262,15 @@ static av_cold void uninit(AVFilterContext *ctx)
> }
>
> #define OFFSET(x) offsetof(SetPTSContext, x)
> -#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_AUDIO_PARAM |
> AV_OPT_FLAG_FILTERING_PARAM
> -static const AVOption options[] = {
> -{ "expr", "Expression determining the frame timestamp",
> OFFSET(expr_str), AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = FLAGS },
> -{ NULL }
> -};
> +#define V AV_OPT_FLAG_VIDEO_PARAM
> +#define A AV_OPT_FLAG_AUDIO_PARAM
> +#define F AV_OPT_FLAG_FILTERING_PARAM
>
> #if CONFIG_SETPTS_FILTER
> -#define setpts_options options
> +static const AVOption setpts_options[] = {
> +{ "expr", "Expression determining the frame timestamp",
> OFFSET(expr_str), AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = V|F },
> +{ NULL }
> +};
> AVFILTER_DEFINE_CLASS(setpts);
>
> static const AVFilterPad avfilter_vf_setpts_inputs[] = {
> @@ -306,7 +307,10 @@ AVFilter ff_vf_setpts = {
>
> #if CONFIG_ASETPTS_FILTER
>
> -#define asetpts_options options
> +static const AVOption asetpts_options[] = {
> +{ "expr", "Expression determining the frame timestamp",
> OFFSET(expr_str), AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = A|F },
> +{ NULL }
> +};
> AVFILTER_DEFINE_CLASS(asetpts);
>
> static const AVFilterPad asetpts_inputs[] = {
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] lavf/udp: fix the commets for defalt UDP socket recvbuf size
From: Jun Zhao
15d160cc0b2 increased the UDP socket receiving buffer size
(64K ->384K), but missed to update this comments.
Signed-off-by: Jun Zhao
---
libavformat/udp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index ad6992c..30d8041 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -852,7 +852,7 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
goto fail;
}
} else {
-/* set udp recv buffer size to the requested value (default 64K) */
+/* set udp recv buffer size to the requested value (default
UDP_RX_BUF_SIZE) */
tmp = s->buffer_size;
if (setsockopt(udp_fd, SOL_SOCKET, SO_RCVBUF, , sizeof(tmp)) < 0) {
ff_log_net_error(h, AV_LOG_WARNING, "setsockopt(SO_RECVBUF)");
--
2.7.4
___
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] avfilter/vf_tinterlace: use frame counter from lavfi
Remove internal counter.
Signed-off-by: Paul B Mahol
---
libavfilter/tinterlace.h| 1 -
libavfilter/vf_tinterlace.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
index 020887ff34..4059ebf81a 100644
--- a/libavfilter/tinterlace.h
+++ b/libavfilter/tinterlace.h
@@ -67,7 +67,6 @@ typedef struct TInterlaceContext {
AVRational preout_time_base;
int flags; ///< flags affecting interlacing algorithm
int lowpass;///< legacy interlace filter lowpass mode
-int frame; ///< number of the output frame
int vsub; ///< chroma vertical subsampling
AVFrame *cur;
AVFrame *next;
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index a77753775c..d145e35520 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -423,7 +423,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
out->height = outlink->h;
out->sample_aspect_ratio = av_mul_q(cur->sample_aspect_ratio,
av_make_q(2, 1));
-field = (1 + tinterlace->frame) & 1 ? FIELD_UPPER : FIELD_LOWER;
+field = (1 + outlink->frame_count_in) & 1 ? FIELD_UPPER : FIELD_LOWER;
/* copy upper and lower fields */
copy_picture_field(tinterlace, out->data, out->linesize,
(const uint8_t **)cur->data, cur->linesize,
@@ -517,7 +517,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
out->pts = av_rescale_q(out->pts, tinterlace->preout_time_base,
outlink->time_base);
ret = ff_filter_frame(outlink, out);
-tinterlace->frame++;
return ret;
}
--
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] [PATCH v2 1/2] lavfi/setpts: fix setpts/asetpts option dump error
From: Jun Zhao
fix the command ffmpeg -h filter=setpts/asetpts both dump the expr
option with "FVA" flags.
Signed-off-by: Jun Zhao
---
libavfilter/setpts.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index 6506653..440a218 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -262,14 +262,15 @@ static av_cold void uninit(AVFilterContext *ctx)
}
#define OFFSET(x) offsetof(SetPTSContext, x)
-#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_AUDIO_PARAM |
AV_OPT_FLAG_FILTERING_PARAM
-static const AVOption options[] = {
-{ "expr", "Expression determining the frame timestamp", OFFSET(expr_str),
AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = FLAGS },
-{ NULL }
-};
+#define V AV_OPT_FLAG_VIDEO_PARAM
+#define A AV_OPT_FLAG_AUDIO_PARAM
+#define F AV_OPT_FLAG_FILTERING_PARAM
#if CONFIG_SETPTS_FILTER
-#define setpts_options options
+static const AVOption setpts_options[] = {
+{ "expr", "Expression determining the frame timestamp", OFFSET(expr_str),
AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = V|F },
+{ NULL }
+};
AVFILTER_DEFINE_CLASS(setpts);
static const AVFilterPad avfilter_vf_setpts_inputs[] = {
@@ -306,7 +307,10 @@ AVFilter ff_vf_setpts = {
#if CONFIG_ASETPTS_FILTER
-#define asetpts_options options
+static const AVOption asetpts_options[] = {
+{ "expr", "Expression determining the frame timestamp", OFFSET(expr_str),
AV_OPT_TYPE_STRING, { .str = "PTS" }, .flags = A|F },
+{ NULL }
+};
AVFILTER_DEFINE_CLASS(asetpts);
static const AVFilterPad asetpts_inputs[] = {
--
2.7.4
___
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] Bug in FFMPEG video filter TINTERLACE needs fixing
On 7/11/20, Ben Hutchinson wrote: > I was reading it directly from the official FFMPEG website. > https://ffmpeg.org/ffmpeg-filters.html > All the info about the TINTERLACE filter I got from reading the info there. > OK, lets try again, where have you read that first frame is always an odd frame, one with 1 number. FFmpeg counts from 0. > On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol wrote: > >> On 7/8/20, Ben Hutchinson wrote: >> > According to the documentation on the TINTERLACE video filter, the >> > filter >> > mode called MERGEX2 will "Move odd frames into the upper field, even >> > into >> > the lower field, generating a double height frame at same frame rate." >> But >> > it doesn't do this, at least in some cases (not sure about all cases). >> The >> > first frame in a sequence should be considered frame one (an odd frame) >> for >> >> Where is this written? >> >> > the purpose of this interlacing algorithm. However, that is not what's >> > happening in my experience. At least with raw video (using "-f >> > rawvideo") >> > it's treating the first frame as frame zero (an even frame) and thus my >> > first frame (which contains top-field data) ends up getting put into the >> > bottom-field of the output video, and this is messing up the output. >> Please >> > fix this. >> > ___ >> > 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". ___ 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] Bug in FFMPEG video filter TINTERLACE needs fixing
I was reading it directly from the official FFMPEG website. https://ffmpeg.org/ffmpeg-filters.html All the info about the TINTERLACE filter I got from reading the info there. On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol wrote: > On 7/8/20, Ben Hutchinson wrote: > > According to the documentation on the TINTERLACE video filter, the filter > > mode called MERGEX2 will "Move odd frames into the upper field, even into > > the lower field, generating a double height frame at same frame rate." > But > > it doesn't do this, at least in some cases (not sure about all cases). > The > > first frame in a sequence should be considered frame one (an odd frame) > for > > Where is this written? > > > the purpose of this interlacing algorithm. However, that is not what's > > happening in my experience. At least with raw video (using "-f rawvideo") > > it's treating the first frame as frame zero (an even frame) and thus my > > first frame (which contains top-field data) ends up getting put into the > > bottom-field of the output video, and this is messing up the output. > Please > > fix this. > > ___ > > 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".
[FFmpeg-devel] [PATCH v6] avdevice/xcbgrab: Add select_region option
This patch adds a select_region option to the xcbgrab input device.
If set to 1, the user will be prompted to select the grabbing area
graphically by clicking and dragging. A rectangle will be drawn to
mark the grabbing area. A single click with no dragging will select
the whole screen. The option overwrites the video_size, grab_x, and
grab_y options if set by the user.
For testing, just set the select_region option as follows:
ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
The drawing happens directly on the root window using standard rubber
banding techniques, so it is very efficient and doesn't depend on any
X extensions or compositors.
Signed-off-by: Omar Emara
---
doc/indevs.texi | 8 +++
libavdevice/xcbgrab.c | 127 ++
2 files changed, 135 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf344..90ccc917aa 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1478,6 +1478,14 @@ ffmpeg -f x11grab -framerate 25 -video_size cif -i
:0.0+10,20 out.mpg
@subsection Options
@table @option
+@item select_region
+Specify whether to select the grabbing area graphically using the pointer.
+A value of @code{1} prompts the user to select the grabbing area graphically
+by clicking and dragging. A single click with no dragging will select the
+whole screen. A region with zero width or height will also select the whole
+screen. This option overwrites the @var{video_size}, @var{grab_x}, and
+@var{grab_y} options. Default value is @code{0}.
+
@item draw_mouse
Specify whether to draw the mouse pointer. A value of @code{0} specifies
not to draw the pointer. Default value is @code{1}.
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 6f6b2dbf15..bcd91e54af 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -22,6 +22,7 @@
#include "config.h"
#include
+#include
#include
#if CONFIG_LIBXCB_XFIXES
@@ -69,6 +70,7 @@ typedef struct XCBGrabContext {
int show_region;
int region_border;
int centered;
+int select_region;
const char *framerate;
@@ -92,6 +94,7 @@ static const AVOption options[] = {
{ "centered", "Keep the mouse pointer at the center of grabbing region
when following.", 0, AV_OPT_TYPE_CONST, { .i64 = -1 }, INT_MIN, INT_MAX, D,
"follow_mouse" },
{ "show_region", "Show the grabbing region.", OFFSET(show_region),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
{ "region_border", "Set the region border thickness.",
OFFSET(region_border), AV_OPT_TYPE_INT, { .i64 = 3 }, 1, 128, D },
+{ "select_region", "Select the grabbing region graphically using the
pointer.", OFFSET(select_region), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
{ NULL },
};
@@ -668,6 +671,122 @@ static void setup_window(AVFormatContext *s)
draw_rectangle(s);
}
+#define CROSSHAIR_CURSOR 34
+
+static xcb_rectangle_t rectangle_from_corners(xcb_point_t *corner_a,
+ xcb_point_t *corner_b)
+{
+xcb_rectangle_t rectangle;
+rectangle.x = FFMIN(corner_a->x, corner_b->x);
+rectangle.y = FFMIN(corner_a->y, corner_b->y);
+rectangle.width = FFABS(corner_a->x - corner_b->x);
+rectangle.height = FFABS(corner_a->y - corner_b->y);
+return rectangle;
+}
+
+static int select_region(AVFormatContext *s)
+{
+XCBGrabContext *c = s->priv_data;
+xcb_connection_t *conn = c->conn;
+xcb_screen_t *screen = c->screen;
+
+int ret = 0;
+int done = 0;
+int was_pressed = 0;
+xcb_cursor_t cursor;
+xcb_font_t cursor_font;
+xcb_point_t press_position;
+xcb_generic_event_t *event;
+xcb_rectangle_t rectangle = {0};
+xcb_grab_pointer_reply_t *reply;
+xcb_grab_pointer_cookie_t cookie;
+
+xcb_window_t root_window = screen->root;
+xcb_gcontext_t gc = xcb_generate_id(conn);
+uint32_t mask = XCB_GC_FUNCTION | XCB_GC_SUBWINDOW_MODE;
+uint32_t values[] = {XCB_GX_INVERT,
+ XCB_SUBWINDOW_MODE_INCLUDE_INFERIORS};
+xcb_create_gc(conn, gc, root_window, mask, values);
+
+cursor_font = xcb_generate_id(conn);
+xcb_open_font(conn, cursor_font, strlen("cursor"), "cursor");
+cursor = xcb_generate_id(conn);
+xcb_create_glyph_cursor(conn, cursor, cursor_font, cursor_font,
+CROSSHAIR_CURSOR, CROSSHAIR_CURSOR + 1, 0, 0, 0,
+0x, 0x, 0x);
+cookie = xcb_grab_pointer(conn, 0, root_window,
+ XCB_EVENT_MASK_BUTTON_PRESS |
+ XCB_EVENT_MASK_BUTTON_RELEASE |
+ XCB_EVENT_MASK_BUTTON_MOTION,
+ XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC,
+ root_window, cursor, XCB_CURRENT_TIME);
+reply = xcb_grab_pointer_reply(conn, cookie, NULL);
+if (!reply || reply->status != XCB_GRAB_STATUS_SUCCESS) {
+av_log(s, AV_LOG_ERROR,
+ "Failed
Re: [FFmpeg-devel] [PATCH] lavc/cfhd:3d transform decoding for both progressive and interlaced
On 7/4/20, Kieran Kunhya wrote: > On Sat, 4 Jul 2020 at 18:39, Paul B Mahol wrote: > >> NAK >> >> Removed frame threading. >> > > That is coming in another patch There is no point in splitting patches and disabling threading and enabling it again in different patch. It is probably best to merge that two patches into one. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v08 0/3] *** kmsgrab, fbtile hwdownload_drm, VFs ***
This consists of P1) kmsgrab updated to pickup format_modifier using drm getfb2, provided the user has not explicitly set a format_modifier and GetFB2 is part of xf86drmMode.h Apply this patch set. P2) hwcontext_drm updated to detile known tile layouts, when user tries to get data from it. This uses the fbtile helper routines. fbtile has been configured by default to be non-public and thus is included into hwcontext_drm.c fbtile now supports both tiling as well as detiling of supported tile layouts. It also supports av_frame_copy_with_tiling, its named as fbtile_frame_copy. If required in future, one can expose fbtile as a public api by defining FBTILE_SCOPE_PUBLIC, while compiling. Apply this patch set. P3) video filters vf_fbtiler and vf_hwdownload (with detile) This is provided just for reference, in case someone is interested. It supports fbtile compiled either as a public api or internal api. This is a optional patch set. hanishkvc (3): KMSGrab: getfb2 format_modifier if user doesnt specify fbtile tile/detile, hwcontext_drm detile NonLinear VF fbtiler (tile/detile) and hwdownload (detile) Changelog | 5 + configure | 5 + doc/filters.texi| 103 + libavdevice/kmsgrab.c | 31 ++- libavfilter/Makefile| 1 + libavfilter/allfilters.c| 1 + libavfilter/vf_fbtiler.c| 247 libavfilter/vf_hwdownload.c | 65 +- libavutil/Makefile | 2 + libavutil/fbtile.c | 434 libavutil/fbtile.h | 255 + libavutil/hwcontext_drm.c | 36 ++- 12 files changed, 1181 insertions(+), 4 deletions(-) create mode 100644 libavfilter/vf_fbtiler.c create mode 100644 libavutil/fbtile.c create mode 100644 libavutil/fbtile.h -- 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 v08 1/3] KMSGrab: getfb2 format_modifier if user doesnt specify
If user doesnt specify a format_modifier explicitly, then use GetFB2
to identify the format_modifier of the framebuffer being grabbed.
This is supported on newer linux builds, where xf86drmMode.h has
added support for GetFB2.
---
Changelog | 1 +
configure | 5 +
libavdevice/kmsgrab.c | 31 ++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 1bb9931c0d..ac3f1cf208 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- kmsgrab GetFB2 format_modifier, if user doesnt specify
- AudioToolbox output device
- MacCaption demuxer
- PGX decoder
diff --git a/configure b/configure
index bdfd731602..3bbc51053c 100755
--- a/configure
+++ b/configure
@@ -2325,6 +2325,7 @@ HAVE_LIST="
$TYPES_LIST
makeinfo
makeinfo_html
+drm_getfb2
opencl_d3d11
opencl_drm_arm
opencl_drm_beignet
@@ -6653,6 +6654,10 @@ if enabled vaapi; then
check_type "va/va.h va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
fi
+if enabled libdrm; then
+check_pkg_config drm_getfb2 libdrm "xf86drm.h xf86drmMode.h" drmModeGetFB2
+fi
+
if enabled_all opencl libdrm ; then
check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
enable opencl_drm_beignet
diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
index d0de774871..c7fa2343e3 100644
--- a/libavdevice/kmsgrab.c
+++ b/libavdevice/kmsgrab.c
@@ -239,6 +239,9 @@ static av_cold int kmsgrab_read_header(AVFormatContext
*avctx)
drmModePlaneRes *plane_res = NULL;
drmModePlane *plane = NULL;
drmModeFB *fb = NULL;
+#if HAVE_DRM_GETFB2
+drmModeFB2 *fb2 = NULL;
+#endif
AVStream *stream;
int err, i;
@@ -364,6 +367,28 @@ static av_cold int kmsgrab_read_header(AVFormatContext
*avctx)
goto fail;
}
+#if HAVE_DRM_GETFB2
+fb2 = drmModeGetFB2(ctx->hwctx->fd, plane->fb_id);
+if (!fb2) {
+err = errno;
+av_log(avctx, AV_LOG_ERROR, "Failed to get "
+ "framebuffer2 %"PRIu32": %s.\n",
+ plane->fb_id, strerror(err));
+err = AVERROR(err);
+goto fail;
+}
+
+av_log(avctx, AV_LOG_INFO, "Template framebuffer2 is %"PRIu32": "
+ "%"PRIu32"x%"PRIu32", pixel_format: 0x%"PRIx32", format_modifier:
0x%"PRIx64".\n",
+ fb2->fb_id, fb2->width, fb2->height, fb2->pixel_format,
fb2->modifier);
+
+if (ctx->drm_format_modifier == DRM_FORMAT_MOD_INVALID)
+ctx->drm_format_modifier = fb2->modifier;
+#else
+if (ctx->drm_format_modifier == DRM_FORMAT_MOD_INVALID)
+ctx->drm_format_modifier = DRM_FORMAT_MOD_NONE;
+#endif
+
stream = avformat_new_stream(avctx, NULL);
if (!stream) {
err = AVERROR(ENOMEM);
@@ -408,6 +433,10 @@ fail:
drmModeFreePlane(plane);
if (fb)
drmModeFreeFB(fb);
+#if HAVE_DRM_GETFB2
+if (fb2)
+drmModeFreeFB2(fb2);
+#endif
return err;
}
@@ -433,7 +462,7 @@ static const AVOption options[] = {
{ .i64 = AV_PIX_FMT_BGR0 }, 0, UINT32_MAX, FLAGS },
{ "format_modifier", "DRM format modifier for framebuffer",
OFFSET(drm_format_modifier), AV_OPT_TYPE_INT64,
- { .i64 = DRM_FORMAT_MOD_NONE }, 0, INT64_MAX, FLAGS },
+ { .i64 = DRM_FORMAT_MOD_INVALID}, 0, INT64_MAX, FLAGS },
{ "crtc_id", "CRTC ID to define capture source",
OFFSET(source_crtc), AV_OPT_TYPE_INT64,
{ .i64 = 0 }, 0, UINT32_MAX, FLAGS },
--
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 v08 1/3] KMSGrab: getfb2 format_modifier if user doesnt specify
If user doesnt specify a format_modifier explicitly, then use GetFB2
to identify the format_modifier of the framebuffer being grabbed.
This is supported on newer linux builds, where xf86drmMode.h has
added support for GetFB2.
---
Changelog | 1 +
configure | 5 +
libavdevice/kmsgrab.c | 31 ++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 1bb9931c0d..ac3f1cf208 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- kmsgrab GetFB2 format_modifier, if user doesnt specify
- AudioToolbox output device
- MacCaption demuxer
- PGX decoder
diff --git a/configure b/configure
index bdfd731602..3bbc51053c 100755
--- a/configure
+++ b/configure
@@ -2325,6 +2325,7 @@ HAVE_LIST="
$TYPES_LIST
makeinfo
makeinfo_html
+drm_getfb2
opencl_d3d11
opencl_drm_arm
opencl_drm_beignet
@@ -6653,6 +6654,10 @@ if enabled vaapi; then
check_type "va/va.h va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
fi
+if enabled libdrm; then
+check_pkg_config drm_getfb2 libdrm "xf86drm.h xf86drmMode.h" drmModeGetFB2
+fi
+
if enabled_all opencl libdrm ; then
check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
enable opencl_drm_beignet
diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
index d0de774871..c7fa2343e3 100644
--- a/libavdevice/kmsgrab.c
+++ b/libavdevice/kmsgrab.c
@@ -239,6 +239,9 @@ static av_cold int kmsgrab_read_header(AVFormatContext
*avctx)
drmModePlaneRes *plane_res = NULL;
drmModePlane *plane = NULL;
drmModeFB *fb = NULL;
+#if HAVE_DRM_GETFB2
+drmModeFB2 *fb2 = NULL;
+#endif
AVStream *stream;
int err, i;
@@ -364,6 +367,28 @@ static av_cold int kmsgrab_read_header(AVFormatContext
*avctx)
goto fail;
}
+#if HAVE_DRM_GETFB2
+fb2 = drmModeGetFB2(ctx->hwctx->fd, plane->fb_id);
+if (!fb2) {
+err = errno;
+av_log(avctx, AV_LOG_ERROR, "Failed to get "
+ "framebuffer2 %"PRIu32": %s.\n",
+ plane->fb_id, strerror(err));
+err = AVERROR(err);
+goto fail;
+}
+
+av_log(avctx, AV_LOG_INFO, "Template framebuffer2 is %"PRIu32": "
+ "%"PRIu32"x%"PRIu32", pixel_format: 0x%"PRIx32", format_modifier:
0x%"PRIx64".\n",
+ fb2->fb_id, fb2->width, fb2->height, fb2->pixel_format,
fb2->modifier);
+
+if (ctx->drm_format_modifier == DRM_FORMAT_MOD_INVALID)
+ctx->drm_format_modifier = fb2->modifier;
+#else
+if (ctx->drm_format_modifier == DRM_FORMAT_MOD_INVALID)
+ctx->drm_format_modifier = DRM_FORMAT_MOD_NONE;
+#endif
+
stream = avformat_new_stream(avctx, NULL);
if (!stream) {
err = AVERROR(ENOMEM);
@@ -408,6 +433,10 @@ fail:
drmModeFreePlane(plane);
if (fb)
drmModeFreeFB(fb);
+#if HAVE_DRM_GETFB2
+if (fb2)
+drmModeFreeFB2(fb2);
+#endif
return err;
}
@@ -433,7 +462,7 @@ static const AVOption options[] = {
{ .i64 = AV_PIX_FMT_BGR0 }, 0, UINT32_MAX, FLAGS },
{ "format_modifier", "DRM format modifier for framebuffer",
OFFSET(drm_format_modifier), AV_OPT_TYPE_INT64,
- { .i64 = DRM_FORMAT_MOD_NONE }, 0, INT64_MAX, FLAGS },
+ { .i64 = DRM_FORMAT_MOD_INVALID}, 0, INT64_MAX, FLAGS },
{ "crtc_id", "CRTC ID to define capture source",
OFFSET(source_crtc), AV_OPT_TYPE_INT64,
{ .i64 = 0 }, 0, UINT32_MAX, FLAGS },
--
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] avformat/crypto.c: remove unnecessary code
Because the newpos variable is set value before use it.
The newpos variable declared at the head partition of crypto_seek.
Signed-off-by: Steven Liu
---
libavformat/crypto.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/crypto.c b/libavformat/crypto.c
index 31f9ac0ab9..daa29ed501 100644
--- a/libavformat/crypto.c
+++ b/libavformat/crypto.c
@@ -252,21 +252,18 @@ static int64_t crypto_seek(URLContext *h, int64_t pos,
int whence)
case SEEK_CUR:
pos = pos + c->position;
break;
-case SEEK_END: {
-int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
+case SEEK_END:
+newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
if (newpos < 0) {
av_log(h, AV_LOG_ERROR,
"Crypto: seek_end - can't get file size (pos=%lld)\r\n", (long
long int)pos);
return newpos;
}
pos = newpos - pos;
-}
break;
-case AVSEEK_SIZE: {
-int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
+case AVSEEK_SIZE:
+newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
return newpos;
-}
-break;
default:
av_log(h, AV_LOG_ERROR,
"Crypto: no support for seek where 'whence' is %d\r\n", whence);
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v08 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear
** fbtile cpu based framebuffer tile/detile helpers
Add helper routines which can be used to tile/detile framebuffer
layouts between linear and specified tile layout, using the cpu.
Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
Newer Intel Tile-Yf tiled layouts.
Currently supported pixel format is 32bit RGB.
It also contains fbtile_generic logic, which can be easily configured
to support different kinds of tiling layouts, at the expense of some
additional processing cycles, compared to developing custom (de)tiling
logic. One requires to provide the tile walking parameters for the
new tile layout to be supported. Once it is done, both tiling and
detiling of the new tile layout can be handled automatically.
This is non-public by default.
** hwcontext_drm detile non linear layout, if possible
If the framebuffer is a tiled layout, use the fbtile helper routines
to try and detile it into linear layout, if supported by fbtile.
It uses the format_modifier associated with the framebuffer to decide
whether to apply detiling or not and inturn which specific detiling
to apply.
If user is using kmsgrab, they will have to use -format_modifer option
of kmsgrab to force a specific detile logic, in case they dont want to
use the original format_modifier related detiling. Or they could even
use -format_modifier 0 to make hwcontext_drm bypass this detiling.
---
Changelog | 2 +
libavutil/Makefile| 2 +
libavutil/fbtile.c| 434 ++
libavutil/fbtile.h| 255 ++
libavutil/hwcontext_drm.c | 36 +++-
5 files changed, 728 insertions(+), 1 deletion(-)
create mode 100644 libavutil/fbtile.c
create mode 100644 libavutil/fbtile.h
diff --git a/Changelog b/Changelog
index ac3f1cf208..c25a28a428 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,8 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- hwcontext_drm detiles non linear layouts, if possible
+- fbtile cpu based framebuffer tile/detile helpers
- kmsgrab GetFB2 format_modifier, if user doesnt specify
- AudioToolbox output device
- MacCaption demuxer
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9b08372eb2..9b58ac5980 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -84,6 +84,7 @@ HEADERS = adler32.h
\
xtea.h\
tea.h \
tx.h \
+ fbtile.h \
HEADERS-$(CONFIG_LZO) += lzo.h
@@ -169,6 +170,7 @@ OBJS = adler32.o
\
tx_float.o \
tx_double.o \
tx_int32.o \
+ fbtile.o \
video_enc_params.o \
diff --git a/libavutil/fbtile.c b/libavutil/fbtile.c
new file mode 100644
index 00..921e5de805
--- /dev/null
+++ b/libavutil/fbtile.c
@@ -0,0 +1,434 @@
+/*
+ * CPU based Framebuffer Generic Tile DeTile logic
+ * Copyright (c) 2020 C Hanish Menon
+ *
+ * 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
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+#include "avutil.h"
+#include "common.h"
+#include "fbtile.h"
+#if CONFIG_LIBDRM
+#include
+#endif
+
+
+SCOPEIN enum FBTileLayout fbtilelayoutid_from_drmformatmodifier(uint64_t
formatModifier)
+{
+enum FBTileLayout layout = FBTILE_UNKNOWN;
+
+#if CONFIG_LIBDRM
+switch(formatModifier) {
+case DRM_FORMAT_MOD_LINEAR:
+layout = FBTILE_NONE;
+break;
+case I915_FORMAT_MOD_X_TILED:
+layout = FBTILE_INTEL_XGEN9;
+break;
+case I915_FORMAT_MOD_Y_TILED:
+layout = FBTILE_INTEL_YGEN9;
+break;
+case I915_FORMAT_MOD_Yf_TILED:
+
[FFmpeg-devel] [PATCH v08 3/3] VF fbtiler (tile/detile) and hwdownload (detile)
NOTE: THis is provided for reference, in case someone needs it.
fbtiler videofilter cpu based framebuffer tiling/detiling
This adds a video filter called fbtiler, which allows the user
to tile/detile framebuffer layout between linear and tiled
layouts, if required.
It uses the fbtile helper routines to achieve its functionality.
This is useful, if
a) the user doesnt want to apply detiling when capturing some
content/framebuffer which is tiled. OR
b) the user already has tiled content with them. OR
c) a developer wants to experiment with tiled data. OR
d) user/developer wants to tile a linear layout.
hwdownload detile framebuffer, if requested by user
Added logic to support detiling of framebuffer.
By default this is disabled. Only if requested by the user, the
logic will be triggered.
It uses the fbtile helper routines to do the detiling. Currently
32bit RGB pixel format based framebuffers are supported.
If the underlying hardware context provides linear layouts, then
nothing is done. However if underlying hardware context generates
tiled layout, then user can use this to detile, where possible.
./ffmpeg -f kmsgrab -i - -vf hwdownload=1,format=bgr0 out.mp4
---
Changelog | 2 +
doc/filters.texi| 103 +++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_fbtiler.c| 247
libavfilter/vf_hwdownload.c | 65 +-
6 files changed, 417 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/vf_fbtiler.c
diff --git a/Changelog b/Changelog
index c25a28a428..0fde7e27a3 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,8 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- fbtiler cpu based framebuffer layout tile/detile video filter
+- hwdownload framebuffer layout detiling (Intel tile-x|y|yf layouts)
- hwcontext_drm detiles non linear layouts, if possible
- fbtile cpu based framebuffer tile/detile helpers
- kmsgrab GetFB2 format_modifier, if user doesnt specify
diff --git a/doc/filters.texi b/doc/filters.texi
index ad2448acb2..e242304e3d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12105,6 +12105,23 @@ Not all formats will be supported on the output - it
may be necessary to insert
an additional @option{format} filter immediately following in the graph to get
the output in a supported format.
+It supports the following optional parameters
+
+@table @option
+@item fbdetile
+Specify type of CPU based FrameBuffer layout detiling to apply. The supported
values are
+@table @var
+@item 0
+Dont do sw detiling (the default).
+@item 1
+intel tile-x to linear conversion.
+@item 2
+intel tile-y to linear conversion.
+@item 3
+intel tile-yf to linear conversion.
+@end table
+@end table
+
@section hwmap
Map hardware frames to system memory or to another device.
@@ -12218,6 +12235,92 @@ It accepts the following optional parameters:
The number of the CUDA device to use
@end table
+@anchor{fbtiler}
+@section fbtiler
+
+Tile/Detile the Framebuffer between tile layout and linear layout using CPU.
+
+Currently supports conversion to|from Intel legacy tile-x|tile-y as well as
+the newer Intel tile-yf layouts and the linear layout. This is useful if
+one is using kmsgrab and hwdownload to capture a screen which is using one
+of these non-linear layouts. It can also be used to generate a tiled layout.
+
+It provides a generic tiling|detiling logic, which can be easily configured
+to tile|detile many different tiling schemes if required, in future. One is
+only required to specify the tile walk parameters for the new tiling layout.
+
+Currently it expects the data to be a 32bit RGB based pixel format. However
+the logic doesnt do any pixel format conversion or so. Later will be enabling
+16bit RGB data also, as the logic is transparent to it at one level.
+
+One could either insert this into the filter chain while capturing itself,
+or else, if it is slowing things down or so, then one could instead insert
+it into the filter chain during playback or transcoding or so.
+
+It supports the following parameters
+
+@table @option
+@item op
+Specify whether to apply tiling or detiling. The supported values are
+@table @var
+@item 0
+Dont do any operation, just pass through.
+@item 1
+Apply tiling operation.
+@item 2
+Apply detiling operation.
+@end table
+@item layout
+Specify which frame buffer layout to work with for conversion. The supported
values are
+@table @var
+@item 0
+Dont do any tile/detiling.
+@item 1
+Between intel tile-x and linear conversion (the default).
+@item 2
+Between intel tile-y and linear conversion.
+@item 3
+Between intel tile-yf and linear conversion.
+@end table
+@end table
+
+If one wants to convert during capture itself, one could do
+@example
+ffmpeg -f kmsgrab -i -
