Re: [FFmpeg-devel] [PATCH v8 3/3] avdevice/decklink_dec: export timecode with s12m side data

[lance . lmwang]

On Sun, Jul 12, 2020 at 03:07:18AM +0200, Andreas Rheinhardt wrote:
> 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(&tcr, 
> > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > +uint32_t tc_data = 
> > av_timecode_get_smpte_from_framenum(&tcr, 0);
> > +int size = sizeof(uint32_t) * 4;
> > +uint8_t *sd = av_packet_new_side_data(&pkt, 
> > AV_PKT_DATA_S12M_TIMECODE, size);
> > +
> > +if (sd) {
> > +AV_WL32(sd, 1); // one TC ;
> 
> Nit: why is there a space after TC?

Will remove it, it's not intentional.

> 
> > +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.

good catch, at first, I think it's little endian order, and Nicolas comment
uint32_t is native, so I remove the commens for the byte order. I'll change
to use AV_WB32() for native write. 

> 
> 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.

I didn't get the SMPTE S314M:2005 specs for checking, it's not free. I think
use native format is fine for local system, but if the side data is packed into
or read from specific format like DV, AV_WB32() and AV_RB32() had to be used.
For the fate testing, I think we can't test the side data binary only, if 
needed,
we can test the format which use the sidedata like dv.

I have add fate timecode testing for h264/hevc and haven't submit yet. But if
the frame rate > 30, I got one unexpected result after map SMPTE ST 12-1:2014
side data to HEVC timecode, the frame is 6bit only(2bit for tens of frame), 
so to framerate > 30, it'll be divided by 2 with same timecode, but HEVC 
timecode
frame number can use 9bit and expect the frame > 30.

> 
> - 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.)

Yes, in my local system, I change the version related for conflict.

> ___
> 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] avfilter: add radial and circular blur video filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  46 
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   2 +
 libavfilter/vf_rblur.c   | 476 +++
 4 files changed, 526 insertions(+)
 create mode 100644 libavfilter/vf_rblur.c

diff --git a/doc/filters.texi b/doc/filters.texi
index ccc066a9ab..8c5006ce04 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7231,6 +7231,29 @@ Set planes to filter. Default value is to filter all
 planes except alpha plane.
 @end table
 
+@section cblur
+Apply Circular blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerx, centery
+Set central point position of circular blur. Default is @code{0.5}.
+
+@item angle
+Set angle of circular blur in degrees. Default is @code{5}.
+
+@item planes
+Set which planes to filter. By default all planes are filtered.
+@end table
+
+@subsection Commands
+This filter supports same @ref{commands} as options.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+
 @section chromahold
 Remove all color information for all colors except for certain one.
 
@@ -15768,6 +15791,29 @@ less than @code{0}, the filter will try to use a good 
random seed on a
 best effort basis.
 @end table
 
+@section rblur
+Apply Radial blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item centerx, centery
+Set central point position of radial blur. Default is @code{0.5}.
+
+@item angle
+Set angle of radial blur in degrees. Default is @code{5}.
+
+@item planes
+Set which planes to filter. By default all planes are filtered.
+@end table
+
+@subsection Commands
+This filter supports same @ref{commands} as options.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+
 @section readeia608
 
 Read closed captioning (EIA-608) information from the top lines of a video 
frame.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 33dcc69392..30f2abf9e2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -180,6 +180,7 @@ OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += 
vf_avgblur_opencl.o opencl.o \
 opencl/avgblur.o boxblur.o
 OBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o yadif_common.o
 OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
+OBJS-$(CONFIG_CBLUR_FILTER)  += vf_rblur.o
 OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER)   += vf_chromaber_vulkan.o vulkan.o
 OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
@@ -358,6 +359,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o 
framesync.o
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
 OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
 OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_RBLUR_FILTER)  += vf_rblur.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b896a76c9e..38279a44eb 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -171,6 +171,7 @@ extern AVFilter ff_vf_boxblur;
 extern AVFilter ff_vf_boxblur_opencl;
 extern AVFilter ff_vf_bwdif;
 extern AVFilter ff_vf_cas;
+extern AVFilter ff_vf_cblur;
 extern AVFilter ff_vf_chromahold;
 extern AVFilter ff_vf_chromakey;
 extern AVFilter ff_vf_chromanr;
@@ -341,6 +342,7 @@ extern AVFilter ff_vf_psnr;
 extern AVFilter ff_vf_pullup;
 extern AVFilter ff_vf_qp;
 extern AVFilter ff_vf_random;
+extern AVFilter ff_vf_rblur;
 extern AVFilter ff_vf_readeia608;
 extern AVFilter ff_vf_readvitc;
 extern AVFilter ff_vf_realtime;
diff --git a/libavfilter/vf_rblur.c b/libavfilter/vf_rblur.c
new file mode 100644
index 00..2524319b05
--- /dev/null
+++ b/libavfilter/vf_rblur.c
@@ -0,0 +1,476 @@
+/*
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * 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
+ */

Re: [FFmpeg-devel] [PATCH v8 3/3] avdevice/decklink_dec: export timecode with s12m side data

[Marton Balint]

On Sun, 12 Jul 2020, Andreas Rheinhardt wrote:


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(&tcr, 
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+uint32_t tc_data = 
av_timecode_get_smpte_from_framenum(&tcr, 0);
+int size = sizeof(uint32_t) * 4;
+uint8_t *sd = av_packet_new_side_data(&pkt, 
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.


I think using possibly different endianness for the same type of frame 
side data and packet side data would be a very bad idea, a consistent API 
is a lot more important. Thanks for spotting this.


Regards,
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".

Re: [FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter

[Alexander Strasser]

Hi Paul!

Only doc comments. Feel free to apply the changes when the real
review has completed.

On 2020-07-12 13:01 +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  46 
>  libavfilter/Makefile |   2 +
>  libavfilter/allfilters.c |   2 +
>  libavfilter/vf_rblur.c   | 476 +++
>  4 files changed, 526 insertions(+)
>  create mode 100644 libavfilter/vf_rblur.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index ccc066a9ab..8c5006ce04 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7231,6 +7231,29 @@ Set planes to filter. Default value is to filter all
>  planes except alpha plane.
>  @end table
>
> +@section cblur

> +Apply Circular blur filter.

I suggest not upper casing circular and using the indefinite article:

Apply a circular blur filter.


> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item centerx, centery
> +Set central point position of circular blur. Default is @code{0.5}.
> +
> +@item angle
> +Set angle of circular blur in degrees. Default is @code{5}.
> +
> +@item planes
> +Set which planes to filter. By default all planes are filtered.
> +@end table
> +
> +@subsection Commands

> +This filter supports same @ref{commands} as options.

To me the sentence sounds a bit weird. I suggest:

All options are supported as @ref{commands}.

If you prefer, use that instead.

Now on the content itself. It bears the danger, that at some point
options and commands could diverge. So one needs to keep in mind
to update the documenation accordingly; should it ever happen.

I agree that not duplicating anything is preferable for now.


> +The command accepts the same syntax of the corresponding option.

Maybe:

   Each command accepts the syntax of the corresponding option.


> +
> +If the specified expression is not valid, it is kept at its current
> +value.
> +

All my remarks apply too the rblur filter too.


  Alexander

[...]
___
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] lavf/srt: fix build fail when used the libsrt 1.4.1

[Moritz Barsnick]

On Sun, Jul 12, 2020 at 14:03:03 +0800, Jun Zhao wrote:
> From: Jun Zhao 

(Which thread are you replying to?)

> libsrt 1.4.1 changed the:
> SRTO_SMOOTHER   -> SRTO_CONGESTION

AFAICT, this was changed in 1.3.3 (even though the commit doesn't
change the doc/API.md where it states 1.3.0):
https://github.com/Haivision/srt/commit/6f6b76b381ba8854fcd699908f74fae4cfce6783

> SRTO_STRICTENC  -> SRTO_ENFORCEDENCRYPTION

This was changed in 1.4.0. Does this codec compile with 1.4.0 after your
fix? Did it ever?
https://github.com/Haivision/srt/commit/a82e0c34b0aadcb309d9e2f322b26f8f59bf827a

> SRTO_TSBPDDELAY -> SRTO_LATENCY

You didn't change any code regarding these two, and anyway,
SRTO_LATENCY has existed as an alias since 1.2.0:
https://github.com/Haivision/srt/commit/508eeeb8dec6bcee123fa0d1d7f7fe3b0060eb77

Considering that 1.4.0 was released 10 months ago, I wonder whether
anyone compiled against a recent libsrt since then?

Cheers,
Moritz
___
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

[Moritz Barsnick]

On Sat, Jul 11, 2020 at 20:31:40 +0530, C Hanish Menon wrote:
> > Also fix the changelog.
>
> Sorry I didn't understand this fully. Can I assume that you don't want to
> mention about the fbtile helpers as an entry in the changelog, because its
> not a public api?

I believe what Lynne meant is:

Changelog entries are added at the bottom, not at the top of the list.
You can how other commits did something, before making assumptions.

> Thanks for suggesting the same (as previously mentioned, I haven't worked
> on ffmpeg before so am not aware of all the ffmpeg helper routines,

Just have a look around the code and observe the mailing list. to learn
about the conventions.

Moritz
___
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] Ban Carl Eugen Hoyos from trac.ffmpeg.org

[Paul B Mahol]

Hi,

This is request to ban Carl Eugen Hoyos from trac.ffmpeg.org

Above mention entity abuse its powers all the time and closes
perfectly valid bug reports all the time with no or invalid explanation.

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".

[FFmpeg-devel] Elections of TC and CC - v2

[Jean-Baptiste Kempf]

Hello,

You should have received another email about the elections for the TC and the 
CC.
Please note that most candidates where nominated by other people than 
themselves.

TC candidates
Martin Storsjö
Michael Niedermayer
Marton Balint
James Almer
Nicolas George
Mark Thompson
Anton Khirnov
Kieran Kunhya
Derek Buitenhuis
Timo Rothenpieler
Hendrik Leppkes
Paul B Mahol
Baptiste Coudurier
Lynne 

CC candidates
Josh de Koch
Jean-Baptiste Kempf
Carl Eugen Hoyos
James Almer
Thilo Borgman
Reynaldo H. Verdejo Pinochet 
Lydia Pintscher
Steven Liu
Dave Rice
Baptiste Coudurier 

Election closes on Sat 18 at 23:59 UTC time.

Best,

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] lavf/srt: fix build fail when used the libsrt 1.4.1

[Christopher Degawa]

> Considering that 1.4.0 was released 10 months ago, I wonder whether
> anyone compiled against a recent libsrt since then?

I can confirm that this fixes compilation errors with the latest
master branch of srt
https://github.com/Haivision/srt/commit/0e2201aff6b379979cec43fee5e8f162717f6346
and FFmpeg 
https://github.com/FFmpeg/FFmpeg/commit/3205ed31a7756ae563301e2f5a5dd2c853b20349

> ___
> 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 v08 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear

[C Hanish Menon]

Hi Mortiz,

On Sun, 12 Jul, 2020, 18:31 Moritz Barsnick,  wrote:

> On Sat, Jul 11, 2020 at 20:31:40 +0530, C Hanish Menon wrote:
> > > Also fix the changelog.
> >
> > Sorry I didn't understand this fully. Can I assume that you don't want to
> > mention about the fbtile helpers as an entry in the changelog, because
> its
> > not a public api?
>
> I believe what Lynne meant is:
>
> Changelog entries are added at the bottom, not at the top of the list.
> You can how other commits did something, before making assumptions.
>

Thanks for the input.


> > Thanks for suggesting the same (as previously mentioned, I haven't worked
> > on ffmpeg before so am not aware of all the ffmpeg helper routines,
>
> Just have a look around the code and observe the mailing list. to learn
> about the conventions.
>

Sure agree and I have tried to explore some of the related code to get
things going.

Wrt the specific suggestion that Lynne had given wrt av_frame_ref, for
which I was responding there, like what I had mentioned in my previous
email, I am not sure that is the right thing in that situation for two
reasons

A) to do with hardware mmaped memory being one of the buffers in question,
like what I had mentioned

And also because

B) the logic is mainly called where previously av_frame_copy would have got
called so also the fall back should be av_frame_copy rather than
av_frame_ref.


> Moritz
> ___
> 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

[myp...@gmail.com]

On Sun, Jul 12, 2020 at 1:38 AM Nicolas George  wrote:
>
> Marton Balint (12020-07-11):
> > LGTM, thanks.
>
> Whoever pushes, fix the typo in the commit message please.
>
fixed the typo and 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 v2 1/2] lavfi/setpts: fix setpts/asetpts option dump error

[myp...@gmail.com]

On Sat, Jul 11, 2020 at 7:58 PM Paul B Mahol  wrote:
>
> ok
Thx, pushed
>
> 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".

Re: [FFmpeg-devel] [PATCH v4] avdevice/xcbgrab: check return values of xcb query functions

[Andriy Gelman]

On Fri, 10. Jul 21:13, Moritz Barsnick wrote:
> Since xcbgrab is getting some attention recently...
> 
> Fixes a segfault, as reported in #7312.
> 
> To reproduce:
> Terminal 1:
> $ Xvfb :1 -nolisten tcp -screen 0 800x600x24
> Terminal 2:
> $ ffmpeg -f x11grab -i :1 -f null -
> or rather
> $ gdb -ex r --args ffmpeg_g -f x11grab -i :1 -f null -
> Then terminate Xvfb while ffmpeg is running.
> 
> Cheers,
> Moritz

> From 3bbf40dd08bb67e993cca97880aec032644fd02b Mon Sep 17 00:00:00 2001
> From: Moritz Barsnick 
> Date: Fri, 10 Jul 2020 13:26:55 +0200
> Subject: [PATCH] avdevice/xcbgrab: check return values of xcb query functions
> 
> Fixes #7312, segmentation fault on close of X11 server
> 
> xcb_query_pointer_reply() and xcb_get_geometry_reply() can return NULL
> if e.g. the X server closes or the connection is lost. This needs to
> be checked in order to cleanly exit, because the returned pointers are
> dereferenced later.
> 
> Furthermore, their return values need to be free()d, also in error
> code paths.
> 
> Signed-off-by: Moritz Barsnick 
> ---
>  libavdevice/xcbgrab.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index 6f6b2dbf15..be4e0d14f9 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -346,8 +346,10 @@ static void xcbgrab_draw_mouse(AVFormatContext *s, 
> AVPacket *pkt,
>  return;
> 
>  cursor = xcb_xfixes_get_cursor_image_cursor_image(ci);
> -if (!cursor)
> +if (!cursor) {
> +free(ci);
>  return;
> +}
> 
>  cx = ci->x - ci->xhot;
>  cy = ci->y - ci->yhot;
> @@ -425,7 +427,16 @@ static int xcbgrab_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  pc  = xcb_query_pointer(c->conn, c->screen->root);
>  gc  = xcb_get_geometry(c->conn, c->screen->root);
>  p   = xcb_query_pointer_reply(c->conn, pc, NULL);
> +if (!p) {
> +av_log(c, AV_LOG_ERROR, "Failed to query xcb pointer\n");
> +return AVERROR_EXTERNAL;
> +}
>  geo = xcb_get_geometry_reply(c->conn, gc, NULL);
> +if (!geo) {

> +av_log(c, AV_LOG_ERROR, "Failed to get xcb geometry\n");

The rest of the av_log calls use AVFormatContext*.
You may want to update to be consistent.

> +free(p);
> +return AVERROR_EXTERNAL;
> +}
>  }

Thanks,
-- 
Andriy
___
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] lavf/srt: fix build fail when used the libsrt 1.4.1

[myp...@gmail.com]

On Sun, Jul 12, 2020 at 8:39 PM Moritz Barsnick  wrote:
>
> On Sun, Jul 12, 2020 at 14:03:03 +0800, Jun Zhao wrote:
> > From: Jun Zhao 
>
> (Which thread are you replying to?)
>
> > libsrt 1.4.1 changed the:
> > SRTO_SMOOTHER   -> SRTO_CONGESTION
>
> AFAICT, this was changed in 1.3.3 (even though the commit doesn't
> change the doc/API.md where it states 1.3.0):
> https://github.com/Haivision/srt/commit/6f6b76b381ba8854fcd699908f74fae4cfce6783
>
> > SRTO_STRICTENC  -> SRTO_ENFORCEDENCRYPTION
>
> This was changed in 1.4.0. Does this codec compile with 1.4.0 after your
> fix? Did it ever?
> https://github.com/Haivision/srt/commit/a82e0c34b0aadcb309d9e2f322b26f8f59bf827a
>
> > SRTO_TSBPDDELAY -> SRTO_LATENCY
>
> You didn't change any code regarding these two, and anyway,
> SRTO_LATENCY has existed as an alias since 1.2.0:
> https://github.com/Haivision/srt/commit/508eeeb8dec6bcee123fa0d1d7f7fe3b0060eb77
>
> Considering that 1.4.0 was released 10 months ago, I wonder whether
> anyone compiled against a recent libsrt since then?
>
> Cheers,
> Moritz
Maybe I give an inaccurate description in the commit message, in fact,
libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
lead to FFmpeg build fail when using libsrt  version >= 1.4.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] avformat/mov: fix missing line break in messages

[Gyan Doshi]

On 10-07-2020 04:40 pm, Gyan Doshi wrote:



On 10-07-2020 04:36 pm, Moritz Barsnick wrote:

On Thu, Jun 25, 2020 at 18:59:58 +0800, myp...@gmail.com wrote:
On Thu, Jun 25, 2020 at 6:46 PM Moritz Barsnick  
wrote:
One of them can be triggered by 
https://samples.ffmpeg.org/F4V/H263_NM_f.mp4.


Signed-off-by: Moritz Barsnick 
---
  libavformat/mov.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index adc52de947..40fff5dd7d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -894,7 +894,7 @@ static int mov_read_ddts(MOVContext *c, 
AVIOContext *pb, MOVAtom atom)

  (frame_duration_code == 3) ? 4096 : 0;

  if (channel_layout_code > 0xff) {
-    av_log(c->fc, AV_LOG_WARNING, "Unsupported DTS audio 
channel layout");
+    av_log(c->fc, AV_LOG_WARNING, "Unsupported DTS audio 
channel layout\n");

  }
  st->codecpar->channel_layout =
  ((channel_layout_code & 0x1) ? AV_CH_FRONT_CENTER : 0) |
@@ -5219,7 +5219,7 @@ static int mov_read_elst(MOVContext *c, 
AVIOContext *pb, MOVAtom atom)

  } else {
  edit_count = atom.size / elst_entry_size;
  if (edit_count * elst_entry_size != atom.size) {
-    av_log(c->fc, AV_LOG_WARNING, "ELST atom of 
%"PRId64" bytes, bigger than %d entries.", atom.size, edit_count);
+    av_log(c->fc, AV_LOG_WARNING, "ELST atom of 
%"PRId64" bytes, bigger than %d entries.\n", atom.size, edit_count);

  }
  }
  }

LGTM

Ping for push.


Within a day.


Pushed as 2dabee7c0faef202ed04e20856e9f58cb4415810

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

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

Re: [FFmpeg-devel] [PATCH v8 3/3] avdevice/decklink_dec: export timecode with s12m side data

[Andreas Rheinhardt]

lance.lmw...@gmail.com:
> On Sun, Jul 12, 2020 at 03:07:18AM +0200, Andreas Rheinhardt wrote:
>> 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(&tcr, 
>>> ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
>>> +uint32_t tc_data = 
>>> av_timecode_get_smpte_from_framenum(&tcr, 0);
>>> +int size = sizeof(uint32_t) * 4;
>>> +uint8_t *sd = av_packet_new_side_data(&pkt, 
>>> AV_PKT_DATA_S12M_TIMECODE, size);
>>> +
>>> +if (sd) {
>>> +AV_WL32(sd, 1); // one TC ;
>>
>> Nit: why is there a space after TC?
> 
> Will remove it, it's not intentional.
> 
>>
>>> +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.
> 
> good catch, at first, I think it's little endian order, and Nicolas comment
> uint32_t is native, so I remove the commens for the byte order. I'll change
> to use AV_WB32() for native write. 
> 

AV_WB uses big-endian. Instead you could simply use an uint32_t* to
write the numbers.

>>
>> 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.
> 
> I didn't get the SMPTE S314M:2005 specs for checking, it's not free. I think
> use native format is fine for local system, but if the side data is packed 
> into
> or read from specific format like DV, AV_WB32() and AV_RB32() had to be used.
> For the fate testing, I think we can't test the side data binary only, if 
> needed,
> we can test the format which use the sidedata like dv.

The framecrc muxer calculates a checksum of every side data. There is
already a special way of calculating the side-data for palettes in
big-endian and it seems that we can simply reuse this (as both are based
on uint32_t in native format). So it seems it won't be much of a problem.

- 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".

Re: [FFmpeg-devel] Bug in FFMPEG video filter TINTERLACE needs fixing

[Paul B Mahol]

On 7/12/20, Ben Hutchinson  wrote:
> 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).

I sent patch to fix this.

>
> 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".
___
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] mailmap: add entry for RuilingSong

[Zhong Li]

Signed-off-by: Zhong Li 
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index f14770d800..3bd1a85c3c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -21,3 +21,4 @@
 rcombs  
  
  
+ 
-- 
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 v08.01 1/3] KMSGrab: getfb2 format_modifier if user doesnt specify

[hanishkvc]

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..20ba03ae8b 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
 - AudioToolbox output device
 - MacCaption demuxer
 - PGX decoder
+- kmsgrab GetFB2 format_modifier, if user doesnt specify
 
 
 version 4.3:
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.01 3/3] VF fbtiler (tile/detile) and hwdownload (detile)

[hanishkvc]

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

NOTE: This is a optional patch, provided for reference, if one wants
to experiment using the fbtiler video filter in this. This depends
on the fbtile patch being applied.
---
 Changelog   |   2 +
 doc/filters.texi| 103 +++
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_fbtiler.c| 245 
 libavfilter/vf_hwdownload.c |  60 -
 6 files changed, 410 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_fbtiler.c

diff --git a/Changelog b/Changelog
index 0b48858da7..affc852641 100644
--- a/Changelog
+++ b/Changelog
@@ -8,6 +8,8 @@ version :
 - kmsgrab GetFB2 format_modifier, if user doesnt specify
 - fbtile cpu based framebuffer tile/detile helpers (Intel TileX|Y|Yf)
 - hwcontext_drm detiles non linear layouts, if possible
+- hwdownload framebuffer layout detiling, if requested
+- fbtiler cpu based framebuffer layout tile/detile video filter
 
 
 version 4.3:
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 - -vf

[FFmpeg-devel] [PATCH v08.01 2/3] fbtile tile/detile, hwcontext_drm detile NonLinear

[hanishkvc]

** 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 internally 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.

Its basic functionality is exposed as a simple ff_fbtile_frame_copy
function along with few related funcs. This is inturn used by
hwcontext_drm.

** 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.

** NOTE This depends on the related KMSGrab GetFB2 patch, for enhanced
functionality, where detiling is automatically applied where possible.
---
 Changelog |   2 +
 libavutil/Makefile|   2 +
 libavutil/fbtile.c| 482 ++
 libavutil/fbtile.h| 134 +++
 libavutil/hwcontext_drm.c |  38 ++-
 5 files changed, 657 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/fbtile.c
 create mode 100644 libavutil/fbtile.h

diff --git a/Changelog b/Changelog
index 20ba03ae8b..0b48858da7 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,8 @@ version :
 - MacCaption demuxer
 - PGX decoder
 - kmsgrab GetFB2 format_modifier, if user doesnt specify
+- fbtile cpu based framebuffer tile/detile helpers (Intel TileX|Y|Yf)
+- hwcontext_drm detiles non linear layouts, if possible
 
 
 version 4.3:
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..f741e1aeca
--- /dev/null
+++ b/libavutil/fbtile.c
@@ -0,0 +1,482 @@
+/*
+ * 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
+
+
+/**
+ * Ok return value
+ */
+#define FBT_OK 0
+
+
+enum FFFBTileLayout ff_fbtile_getlayoutid(enum FFFBTileFamily family, uint64_t 
familyTileType)
+{
+enum FFFBTileLayout layout = FF_FBTILE_UNKNOWN;
+
+switch(family) {
+case FF_FBTILE_FAMILY_DRM:
+#if CONFIG_LIBDRM
+switch(familyTileType) {
+case DRM_FORMAT_MOD_LINEAR:
+layout = FF_FBTILE_NONE;
+   

[FFmpeg-devel] [PATCH v08.01 0/3] kmsgrab, fbtile+hwcontext_drm, VFs

[hanishkvc]

This is a full patch set. This includes the following

P1) KMSGrab, this is same has in v08 patch set.

P2) fbtile + hwcontext_drm, this is updated wrt v08

Have removed some of the ifdefs and made the logic bit more
simpler|clearer as suggested. While retaining few which make
logical sense. Have also tried to match some of the conventions.

The generic tile/detile logic is not directly exposed outside
fbtile now. Instead the higher level ff_fbtile_frame_copy is
the main one exposed along with two related functions.

This depends on KMSGrab GetFB2 P1, for enhanced functionality.

P3) video filters fbtiler and hwdownload

Have been updated to use the new fbtile. This is provided
for reference, in case someone is interested.


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| 245 ++
 libavfilter/vf_hwdownload.c |  60 -
 libavutil/Makefile  |   2 +
 libavutil/fbtile.c  | 482 
 libavutil/fbtile.h  | 134 ++
 libavutil/hwcontext_drm.c   |  38 ++-
 12 files changed, 1103 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 v2 2/3] doc/developer.texi: Restructured "Submitting patches" section.

[Manolis Stamatogiannakis]

- Main text split to two sections.
- Detailed checklist for new codecs or formats demoted to section.
- Detailed checklist for patch submission demoted to section.

Signed-off-by: Manolis Stamatogiannakis 
---
 doc/developer.texi | 64 +++---
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 585c37d241..c47d23e349 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -457,31 +457,49 @@ Finally, keep in mind the immortal words of Bill and Ted,
 @anchor{Submitting patches}
 @chapter Submitting patches
 
-First, read the @ref{Coding Rules} above if you did not yet, in particular
+@anchor{patch guidelines}
+@section Guidelines for preparing a patch
+
+The @strong{absolute minimum} you have to do before submitting a patch are the
+following:
+
+@enumerate
+@item Carefully read the @ref{Coding Rules} above if you did not yet, in 
particular
 the rules regarding patch submission.
 
-When you submit your patch, please use @code{git format-patch} or
-@code{git send-email}. We cannot read other diffs :-).
+@item Make sure your commit messages accurately describe the changes made
+(e.g. 'replaces lrint by lrintf') and why these changes are made (e.g.
+'*BSD isn't C99 compliant and has no lrint()').
 
-Also please do not submit a patch which contains several unrelated changes.
-Split it into separate, self-contained pieces. This does not mean splitting
-file by file. Instead, make the patch as small as possible while still
-keeping it as a logical unit that contains an individual change, even
-if it spans multiple files. This makes reviewing your patches much easier
-for us and greatly increases your chances of getting your patch applied.
+@item Make sure you use @code{git format-patch} or @code{git send-email} to 
prepare
+your patch. We cannot read other diffs :-).
+
+@item Run the @ref{Regression tests, regression tests} before submitting a 
patch
+in order to verify it does not cause unexpected problems.
 
-Use the patcheck tool of FFmpeg to check your patch.
-The tool is located in the tools directory.
+@item If you send your patches with an external email client
+(i.e. not @code{git send-email}), make sure to send each patch as a separate
+email. Do not attach several patches to the same email!
 
-Run the @ref{Regression tests} before submitting a patch in order to verify
-it does not cause unexpected problems.
+@item Do not submit a patch which contains several unrelated changes.
+@end enumerate
+
+Additionally, it is also important that each patch is logically
+self-contained. I.e. each patch should be as small as possible,
+while still containing a meaningful individual change.
+Patches spanning multiple files are perfectly fine, as long as they can
+be seen as a single logical unit.
 
-It also helps quite a bit if you tell us what the patch does (for example
-'replaces lrint by lrintf'), and why (for example '*BSD isn't C99 compliant
-and has no lrint()')
+Following these guidelines makes reviewing your patches much easier
+for us and greatly increases your chances of getting your patch applied.
+To further reduce the chance that you will need to revise your patch,
+it is also recommended to go through the detailed
+@ref{patch submission checklist, patch} and
+@ref{new codec format checklist, new codec or format}
+checklists.
 
-Also please if you send several patches, send each patch as a separate mail,
-do not attach several unrelated patches to the same mail.
+@anchor{patch submission process}
+@section Patch submission and revision process
 
 Patches should be posted to the
 @uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
@@ -517,7 +535,8 @@ its @emph{roll-counter}. This is achieved by adding a 
@code{-v } argument
 to @code{git format-patch}/@code{git send-email} commands. While this is not
 a strict requirement, it is a commonly followed good practice.
 
-@chapter New codecs or formats checklist
+@anchor{new codec format checklist}
+@section New codecs or formats checklist
 
 @enumerate
 @item
@@ -569,7 +588,8 @@ Did you make sure it compiles standalone, i.e. with
 @end enumerate
 
 
-@chapter Patch submission checklist
+@anchor{patch submission checklist}
+@section Patch submission checklist
 
 @enumerate
 @item
@@ -594,6 +614,10 @@ of @dfn{sign-off}.
 @item
 Did you provide a clear git commit log message?
 
+@item
+Did you use the @code{patcheck} tool of FFmpeg to check your patch
+for common issues? E.g. @code{tools/patcheck *.patch}.
+
 @item
 Is the patch against latest FFmpeg git master branch?
 
-- 
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] Bug in FFMPEG video filter TINTERLACE needs fixing

[Ben Hutchinson]

Problem is it's not as simple as just patching it to start at field 1
instead of field 2. It really depends on your signal source. If your signal
source recorded all lines that contain at least some image signal (even if
only half the line contains image signal), then the top line of the image
is the first line of field 2 (the even field). However, if your signal
source only recorded lines where the entire line contains image signal then
the top line of the image is the first line of field 1 (the odd field).
When using the TINTERLACE video filter (at least in MERGEX2 mode), one
actually needs to be able to select which field comes first (odd field
first, or even field first). This unfortunately is a much more in-depth
patch to the software than just hardcoding a different starting field. You
will need to add commandline option for the TINTERLACE filter in FFMPEG in
order to allow for user-selection of OFF or EFF.

On Sun, Jul 12, 2020 at 9:10 AM Paul B Mahol  wrote:

> On 7/12/20, Ben Hutchinson  wrote:
> > 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).
>
> I sent patch to fix this.
>
> >
> > 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".
> ___
> 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

[FFmpeg-devel] [PATCH v2 3/3] doc/developer.texi: Swapped patch checklist and new codec/format checklist.

[Manolis Stamatogiannakis]

Adding a new codec/format should be more rare, so it makes sense
to come after the detailed patch submission checklist.

Signed-off-by: Manolis Stamatogiannakis 
---
 doc/developer.texi | 105 ++---
 1 file changed, 52 insertions(+), 53 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index c47d23e349..c482c5e09d 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -535,59 +535,6 @@ its @emph{roll-counter}. This is achieved by adding a 
@code{-v } argument
 to @code{git format-patch}/@code{git send-email} commands. While this is not
 a strict requirement, it is a commonly followed good practice.
 
-@anchor{new codec format checklist}
-@section New codecs or formats checklist
-
-@enumerate
-@item
-Did you use av_cold for codec initialization and close functions?
-
-@item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
-@item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
-@item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
-@item
-Did you add the AVCodecID to @file{avcodec.h}?
-When adding new codec IDs, also add an entry to the codec descriptor
-list in @file{libavcodec/codec_desc.c}.
-
-@item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
-@item
-Did you add a rule to compile the appropriate files in the Makefile?
-Remember to do this even if you're just adding a format to a file that is
-already being compiled by some other rule, like a raw demuxer.
-
-@item
-Did you add an entry to the table of supported formats or codecs in
-@file{doc/general.texi}?
-
-@item
-Did you add an entry in the Changelog?
-
-@item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
-@item
-Did you @code{git add} the appropriate files before committing?
-
-@item
-Did you make sure it compiles standalone, i.e. with
-@code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
-@end enumerate
-
-
 @anchor{patch submission checklist}
 @section Patch submission checklist
 
@@ -710,6 +657,58 @@ Test your code with valgrind and or Address Sanitizer to 
ensure it's free
 of leaks, out of array accesses, etc.
 @end enumerate
 
+@anchor{new codec format checklist}
+@section New codecs or formats checklist
+
+@enumerate
+@item
+Did you use av_cold for codec initialization and close functions?
+
+@item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+@item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+@item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+@item
+Did you add the AVCodecID to @file{avcodec.h}?
+When adding new codec IDs, also add an entry to the codec descriptor
+list in @file{libavcodec/codec_desc.c}.
+
+@item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+@item
+Did you add a rule to compile the appropriate files in the Makefile?
+Remember to do this even if you're just adding a format to a file that is
+already being compiled by some other rule, like a raw demuxer.
+
+@item
+Did you add an entry to the table of supported formats or codecs in
+@file{doc/general.texi}?
+
+@item
+Did you add an entry in the Changelog?
+
+@item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+@item
+Did you @code{git add} the appropriate files before committing?
+
+@item
+Did you make sure it compiles standalone, i.e. with
+@code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+@end enumerate
+
 @chapter Patch review process
 
 All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-- 
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/3] doc/developer.texi: Improvements in "Submitting patches" section.

[Manolis Stamatogiannakis]

 - Documentation for adding a roll-counter.
 - Mention the possibility to manualy supersede/withdraw patches on
   patchwork.

Signed-off-by: Manolis Stamatogiannakis 
---
 doc/developer.texi | 41 +
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index b33cab0fc7..585c37d241 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -491,18 +491,31 @@ as base64-encoded attachments, so your patch is not 
trashed during
 transmission. Also ensure the correct mime type is used
 (text/x-diff or text/x-patch or at least text/plain) and that only one
 patch is inline or attached per mail.
-You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show 
up, its mime type
-likely was wrong.
-
-Your patch will be reviewed on the mailing list. You will likely be asked
+You can check the most recently received patches on
+@url{https://patchwork.ffmpeg.org, patchwork}.
+If your patch does not show up, its mime type likely was wrong.
+
+If you need to manually manage your patch (e.g. urgently mark it as as
+"Superseded", or "Withdrawn") you can do so by
+@uref{https://patchwork.ffmpeg.org/register/, registering for a patchwork 
account}.
+Note that this is not generally required, as patch management on patchwork
+is largely automated. But there are case where manual patch management is
+desired. For example, if you have started working on extensive changes
+on your patch, and you don't want people to spend more time reviewing the
+old version.
+
+Your patch will be reviewed on the mailing list. Give us a few days to react.
+But if some time passes without reaction, send a reminder by email.
+Your patch should eventually be dealt with. However, you will likely be asked
 to make some changes and are expected to send in an improved version that
 incorporates the requests from the review. This process may go through
 several iterations. Once your patch is deemed good enough, some developer
 will pick it up and commit it to the official FFmpeg tree.
 
-Give us a few days to react. But if some time passes without reaction,
-send a reminder by email. Your patch should eventually be dealt with.
-
+When preparing an updated version of you patch, you should increment
+its @emph{roll-counter}. This is achieved by adding a @code{-v } argument
+to @code{git format-patch}/@code{git send-email} commands. While this is not
+a strict requirement, it is a commonly followed good practice.
 
 @chapter New codecs or formats checklist
 
@@ -563,7 +576,15 @@ Did you make sure it compiles standalone, i.e. with
 Does @code{make fate} pass with the patch applied?
 
 @item
-Was the patch generated with git format-patch or send-email?
+Was the patch generated with @code{git format-patch} or @code{git send-email}?
+
+@item
+If you are submitting a revised patch, did you increment the roll-counter
+with @code{-v }?
+
+@item
+Are you subscribed to ffmpeg-devel?
+(the list is subscribers only due to spam)
 
 @item
 Did you sign-off your patch? (@code{git commit -s})
@@ -576,10 +597,6 @@ Did you provide a clear git commit log message?
 @item
 Is the patch against latest FFmpeg git master branch?
 
-@item
-Are you subscribed to ffmpeg-devel?
-(the list is subscribers only due to spam)
-
 @item
 Have you checked that the changes are minimal, so that the same cannot be
 achieved with a smaller patch and/or simpler final code?
-- 
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 v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.

[Manolis Stamatogiannakis]

On Thu, 9 Jul 2020 at 22:39, Michael Niedermayer 
wrote:

>
> > @Michael Niedermayer, since you seem to be the most involved with
> patchwork
> > in the thread, what would be better for this? Keep the wording as a
> > recommendation, or to move it outside the list as purely informational
> text?
>
> I think there are 2 aspects here
> First is a "mostly automatic patchwork with only people who want to play
> with
> it obtaining accounts and doing something with them" vs one where its
> recommanded to get accounts
> These are 2 different philosophies ;)
>
> Second is, time vs time
> Is the gain from manually working with patchwork saving us more time
> elsewhere while
> we achieve the same quality of code?
>
> and Third
> Can we not automate whatever we would do manually ?
>
> And describing the actual cases with examples what is wrong and needs
> manual
> update would be interresting.
>
> Are these caseses that are clear to human but unclear to a computer ?
> or we are just missing a line or 2 in the script ?
> or are they maybe unclear to humans too ? which could then lead
> a discussion on how to make that clear to humans first ...
>
> I think its needed to understand where automation fails to really discuss
> this all
>
> thx
>
>
Thanks for the input Michael.

If you find those benefits are not clear-cut, I agree we should refrain
from recommending to everyone to create a patchwork account.

I'm not intimate enough with patchwork automation, so my intuition on the
benefits of recommending manual patch management may be off.

I've updated the patch to v2, presenting the registration of a patchwork
account as an optional step that may come handy in some cases, but not
generally required.

If anyone can make a more informed proposal on that matter, I can
incorporate it in the patch, while we're looking at it.

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] avcodec/v4l2_m2m_dec: Remove redundant packet and fix double free

[Andriy Gelman]

On Wed, 24. Jun 09:26, Andriy Gelman wrote:
> On Mon, 25. May 14:59, Andriy Gelman wrote:
> > On Sat, 16. May 11:53, Andriy Gelman wrote:
> > > On Sat, 09. May 13:35, Andriy Gelman wrote:
> > > > From: Andriy Gelman 
> > > > 
> > > > v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
> > > > cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
> > > > the next call. Currently the ownership transfer between the two packets
> > > > is not properly handled. A double free occurs if
> > > > ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
> > > > returns EINVAL.
> > > > 
> > > > In fact, having two AVPackets is not needed and everything can be
> > > > handled by s->buf_pkt.
> > > > 
> > > > This commit removes the local avpkt from v4l2_receive_frame(), meaning
> > > > that the ownership transfer doesn't need to be handled and the double
> > > > free is fixed.
> > > > 
> > > > Signed-off-by: Andriy Gelman 
> > > > ---
> > > > 
> > > > Sorry, forgot to squash the commit from v1 so v2 didn't apply. This is 
> > > > correct version.
> > > > 
> > > > Supersedes:
> > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505055454.28683-1-andriy.gel...@gmail.com/
> > > > 
> > > > 
> > > >  libavcodec/v4l2_m2m_dec.c | 37 +++--
> > > >  1 file changed, 15 insertions(+), 22 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> > > > index 3e17e0fcac..b038efed9c 100644
> > > > --- a/libavcodec/v4l2_m2m_dec.c
> > > > +++ b/libavcodec/v4l2_m2m_dec.c
> > > > @@ -138,14 +138,10 @@ static int v4l2_receive_frame(AVCodecContext 
> > > > *avctx, AVFrame *frame)
> > > >  V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
> > > >  V4L2Context *const capture = &s->capture;
> > > >  V4L2Context *const output = &s->output;
> > > > -AVPacket avpkt = {0};
> > > >  int ret;
> > > >  
> > > > -if (s->buf_pkt.size) {
> > > > -avpkt = s->buf_pkt;
> > > > -memset(&s->buf_pkt, 0, sizeof(AVPacket));
> > > > -} else {
> > > > -ret = ff_decode_get_packet(avctx, &avpkt);
> > > > +if (!s->buf_pkt.size) {
> > > > +ret = ff_decode_get_packet(avctx, &s->buf_pkt);
> > > >  if (ret < 0 && ret != AVERROR_EOF)
> > > >  return ret;
> > > >  }
> > > > @@ -153,32 +149,29 @@ static int v4l2_receive_frame(AVCodecContext 
> > > > *avctx, AVFrame *frame)
> > > >  if (s->draining)
> > > >  goto dequeue;
> > > >  
> > > > -ret = ff_v4l2_context_enqueue_packet(output, &avpkt);
> > > > -if (ret < 0) {
> > > > -if (ret != AVERROR(EAGAIN))
> > > > -   return ret;
> > > > +ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt);
> > > > +if (ret < 0 && ret != AVERROR(EAGAIN))
> > > > +goto fail;
> > > >  
> > > > -s->buf_pkt = avpkt;
> > > > -/* no input buffers available, continue dequeing */
> > > > -}
> > > > +/* if EAGAIN don't unref packet and try to enqueue in the next 
> > > > iteration */
> > > > +if (ret != AVERROR(EAGAIN))
> > > > +av_packet_unref(&s->buf_pkt);
> > > >  
> > > > -if (avpkt.size) {
> > > > +if (!s->draining) {
> > > >  ret = v4l2_try_start(avctx);
> > > >  if (ret) {
> > > > -av_packet_unref(&avpkt);
> > > > -
> > > >  /* cant recover */
> > > > -if (ret == AVERROR(ENOMEM))
> > > > -return ret;
> > > > -
> > > > -return 0;
> > > > +if (ret != AVERROR(ENOMEM))
> > > > +ret = 0;
> > > > +goto fail;
> > > >  }
> > > >  }
> > > >  
> > > >  dequeue:
> > > > -if (!s->buf_pkt.size)
> > > > -av_packet_unref(&avpkt);
> > > >  return ff_v4l2_context_dequeue_frame(capture, frame, -1);
> > > > +fail:
> > > > +av_packet_unref(&s->buf_pkt);
> > > > +return ret;
> > > >  }
> > > >  
> > > >  static av_cold int v4l2_decode_init(AVCodecContext *avctx)
> > > > -- 
> > > > 2.25.1
> > > > 
> > > 
> > > ping
> > > 
> > 
> > ping
> > 
> 
> ping
> 

The patch has been on the ml for a long time so I'd like to apply it soon.
It gets rid of a seg fault in:
https://trac.ffmpeg.org/ticket/8774 

Any objections?

-- 
Andriy

PS:
Note the patch doesn't solve #8774 but at least makes sure that the code exits
gracefully. I have an idea how to solve the issue itself and will post a
separate 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] x86/yuv2rgb: fix crashes when storing data on unaligned buffers

[James Almer]

Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
CPUs.

Fixes ticket #8747

Signed-off-by: James Almer 
---
 libswscale/x86/yuv_2_rgb.asm | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index 575a84d921..003dff1f25 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -268,9 +268,9 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 porm2, m7
 porm1, m6  ; g5  b5  r6  g6  b6  r7  g7  b7  r8  g8  b8  r9  
g9  b9  r10 g10
 porm2, m3  ; b10 r11 g11 b11 r12 g12 b12 r13 g13 b13 r14 g14 
b14 r15 g15 b15
-mova [imageq], m0
-mova [imageq + 16], m1
-mova [imageq + 32], m2
+movu [imageq], m0
+movu [imageq + 16], m1
+movu [imageq + 32], m2
 %endif ; mmsize = 16
 %else ; PACK RGB15/16/32
 packuswb m0, m1
@@ -300,10 +300,10 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 punpckhwd m_green, m_red
 punpcklwd m5, m6
 punpckhwd m_alpha, m6
-mova [imageq + 0], m_blue
-mova [imageq + 8  * time_num], m_green
-mova [imageq + 16 * time_num], m5
-mova [imageq + 24 * time_num], m_alpha
+movu [imageq + 0], m_blue
+movu [imageq + 8  * time_num], m_green
+movu [imageq + 16 * time_num], m5
+movu [imageq + 24 * time_num], m_alpha
 %else ; PACK RGB15/16
 %define depth 2
 %if cpuflag(ssse3)
@@ -342,8 +342,8 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 mova m2, m0
 punpcklbw m0, m1
 punpckhbw m2, m1
-mova [imageq], m0
-mova [imageq + 8 * time_num], m2
+movu [imageq], m0
+movu [imageq + 8 * time_num], m2
 %endif ; PACK RGB15/16
 %endif ; PACK RGB15/16/32
 
-- 
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 v8 3/3] avdevice/decklink_dec: export timecode with s12m side data

[lance . lmwang]

On Sun, Jul 12, 2020 at 06:03:04PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > On Sun, Jul 12, 2020 at 03:07:18AM +0200, Andreas Rheinhardt wrote:
> >> 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(&tcr, 
> >>> ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> >>> +uint32_t tc_data = 
> >>> av_timecode_get_smpte_from_framenum(&tcr, 0);
> >>> +int size = sizeof(uint32_t) * 4;
> >>> +uint8_t *sd = av_packet_new_side_data(&pkt, 
> >>> AV_PKT_DATA_S12M_TIMECODE, size);
> >>> +
> >>> +if (sd) {
> >>> +AV_WL32(sd, 1); // one TC ;
> >>
> >> Nit: why is there a space after TC?
> > 
> > Will remove it, it's not intentional.
> > 
> >>
> >>> +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.
> > 
> > good catch, at first, I think it's little endian order, and Nicolas comment
> > uint32_t is native, so I remove the commens for the byte order. I'll change
> > to use AV_WB32() for native write. 
> > 
> 
> AV_WB uses big-endian. Instead you could simply use an uint32_t* to
> write the numbers.

OK, I'll change it.

> 
> >>
> >> 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.
> > 
> > I didn't get the SMPTE S314M:2005 specs for checking, it's not free. I think
> > use native format is fine for local system, but if the side data is packed 
> > into
> > or read from specific format like DV, AV_WB32() and AV_RB32() had to be 
> > used.
> > For the fate testing, I think we can't test the side data binary only, if 
> > needed,
> > we can test the format which use the sidedata like dv.
> 
> The framecrc muxer calculates a checksum of every side data. There is
> already a special way of calculating the side-data for palettes in
> big-endian and it seems that we can simply reuse this (as both are based
> on uint32_t in native format). So it seems it won't be much of a problem.
> 
> - 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".

-- 
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 v9 3/3] avdevice/decklink_dec: export timecode with s12m side data

[lance . lmwang]

From: Limin Wang 

Reviewed-by: Marton Balint 
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..dde68ff 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(&tcr, 
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+uint32_t tc_data = 
av_timecode_get_smpte_from_framenum(&tcr, 0);
+int size = sizeof(uint32_t) * 4;
+uint32_t *sd = (uint32_t 
*)av_packet_new_side_data(&pkt, AV_PKT_DATA_S12M_TIMECODE, size);
+
+if (sd) {
+*sd   = 1;   // one TC
+*(sd + 1) = tc_data; // TC
+}
+}
+
 if (av_dict_set(&metadata_dict, "timecode", tc, 
AV_DICT_DONT_STRDUP_VAL) >= 0) {
 packed_metadata = 
av_packet_pack_dictionary(metadata_dict, &metadata_len);
 av_dict_free(&metadata_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".