[FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF
From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 28 Jan 2019 12:20:02 +0530
Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
missing CRLF
---
libavformat/http.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 240304f6e6..2f2ce856bc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char *uri, int
flags,
int len = strlen(s->headers);
if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
av_log(h, AV_LOG_WARNING,
- "No trailing CRLF found in HTTP header.\n");
+ "No trailing CRLF found in HTTP header. Adding it.\n");
ret = av_reallocp(&s->headers, len + 3);
-if (ret < 0)
+if (ret < 0) {
+av_log(h, AV_LOG_ERROR,
+ "Failed to add trailing CRLF.\n");
return ret;
+}
s->headers[len] = '\r';
s->headers[len + 1] = '\n';
s->headers[len + 2] = '\0';
--
2.19.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Skip writing trailer for MP4 output when in streaming mode
On 1/24/19 11:31 AM, Karthick J wrote:
> In streaming mode mp4 trailer is not required for playout.
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 9c90cf17e5..6299e179c2 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1210,7 +1210,7 @@ static int dash_init(AVFormatContext *s)
>
> if (os->segment_type == SEGMENT_TYPE_MP4) {
> if (c->streaming)
> -av_dict_set(&opts, "movflags",
> "frag_every_frame+dash+delay_moov+skip_sidx", 0);
> +av_dict_set(&opts, "movflags",
> "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer", 0);
> else
> av_dict_set(&opts, "movflags",
> "frag_custom+dash+delay_moov", 0);
> } else {
Pushed.
Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
> Thompson
> Sent: Sunday, January 27, 2019 3:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
>
> Allow setting the mode explicitly, and try to make a sensible choice
> given the available parameters if not.
> ---
> doc/encoders.texi | 24 +++
> libavcodec/vaapi_encode.c | 370 +++---
> libavcodec/vaapi_encode.h | 65 +++
> 3 files changed, 351 insertions(+), 108 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..29625ba07c 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2824,6 +2824,30 @@ Set the B-frame reference depth. When set to one (the
> default), all B-frames
> will refer only to P- or I-frames. When set to greater values multiple
> layers
> of B-frames will be present, frames in each layer only referring to frames in
> higher layers.
> +
> +@item rc_mode
> +Set the rate control mode to use. A given driver may only support a subset
> of
> +modes.
> +
> +Possible modes:
> +@table @option
> +@item auto
> +Choose the mode automatically based on driver support and the other options.
> +This is the default.
> +@item CQP
> +Constant-quality.
> +@item CBR
> +Constant-bitrate.
> +@item VBR
> +Variable-bitrate.
> +@item ICQ
> +Intelligent constant-quality.
> +@item QVBR
> +Quality-defined variable-bitrate.
> +@item AVBR
> +Average variable bitrate.
> +@end table
> +
> @end table
>
> Each encoder also has its own specific options:
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b4e9fadaee..d0e101b118 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1283,17 +1283,42 @@ fail:
> return err;
> }
>
> +static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
> +// Bitrate Quality
> +// | Maxrate | HRD/VBV
> +{ 0 }, // ||||
> +{ RC_MODE_CQP, "CQP", 1, VA_RC_CQP, 0, 0, 1, 0 },
> +{ RC_MODE_CBR, "CBR", 1, VA_RC_CBR, 1, 0, 0, 1 },
> +{ RC_MODE_VBR, "VBR", 1, VA_RC_VBR, 1, 1, 0, 1 },
> +#if VA_CHECK_VERSION(1, 1, 0)
> +{ RC_MODE_ICQ, "ICQ", 1, VA_RC_ICQ, 0, 0, 1, 0 },
> +#else
> +{ RC_MODE_ICQ, "ICQ", 0 },
> +#endif
> +#if VA_CHECK_VERSION(1, 3, 0)
> +{ RC_MODE_QVBR, "QVBR", 1, VA_RC_QVBR, 1, 1, 1, 1 },
> +{ RC_MODE_AVBR, "AVBR", 0, VA_RC_AVBR, 1, 0, 0, 0 },
> +#else
> +{ RC_MODE_QVBR, "QVBR", 0 },
> +{ RC_MODE_AVBR, "AVBR", 0 },
> +#endif
> +};
> +
> static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> +uint32_t supported_va_rc_modes;
> +const VAAPIEncodeRCMode *rc_mode;
> int64_t rc_bits_per_second;
> int rc_target_percentage;
> int rc_window_size;
> +int rc_quality;
> int64_t hrd_buffer_size;
> int64_t hrd_initial_buffer_fullness;
> int fr_num, fr_den;
> VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> VAStatus vas;
> +char supported_rc_modes_string[64];
>
> vas = vaGetConfigAttributes(ctx->hwctx->display,
> ctx->va_profile, ctx->va_entrypoint,
> @@ -1303,119 +1328,215 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
> "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> return AVERROR_EXTERNAL;
> }
> -
> if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> - "supported rate control modes: assuming constant-quality.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -return 0;
> -}
> -if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
> -avctx->flags & AV_CODEC_FLAG_QSCALE ||
> -avctx->bit_rate <= 0) {
> -if (rc_attr.value & VA_RC_CQP) {
> -av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
> -av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
> - "ignored in constant-quality mode.\n");
> + "supported rate control modes: assuming CQP only.\n");
> +supported_va_rc_modes = VA_RC_CQP;
> +strcpy(supported_rc_modes_string, "unknown");
> +} else {
> +char *str = supported_rc_modes_string;
> +size_t len = sizeof(supported_rc_modes_string);
> +int i, first = 1, res;
> +
> +supported_va_rc_modes = rc_attr.value;
> +
> +first = 1;
> +for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
> +rc_mode = &vaapi_
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On 1/27/2019 3:43 PM, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 27 January 2019 at 19:29, Carl Eugen Hoyos wrote: >> 2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski >> : >>> Hello, >>> >>> On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: ffmpeg | branch: master | ManojGuptaBonda | Mon Oct 29 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | committer: Philip Langdale avcodec/vdpau: Enable HEVC support for working Nvidia driver versions The driver bugs that caused decoded HEVC content to have an incorrect memory layout have been fully fixed in the 410.xx driver release so we can start exposing support. > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f >>> >>> I have a user requesting a backport of this and >>> 4a976200d7853588336005a394dd31d905f5caf6 >>> to 4.0 branch which we use in Fedora/RPM Fusion 29: >>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 >> >> Wouldn't a user who uses an outdated version of FFmpeg >> typically also use an outdated Nvidia driver? > > No. Why would you say that? First, 4.0.x is not outdated from where I'm > sitting and second, we've updated the packaged nVidia drivers in RPM > Fusion for F29 to 415 already. > > If you're trying to say we can upgrade 4.0.x to 4.1.x without > recompiling any dependent packages and you guarantee everything will > work just like with 4.0.x, then I would be willing to entertain that > option ffmpeg 4.1 is meant to be ABI compatible with 4.0, so you should be able to replace the 4.0 libraries and anything linking to them should still work without the need to be recompiled. Now, "work just like with 4.0.x" is impossible to guarantee because there were like five months of development between the two releases, and some modules may behave slightly differently. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec: add ARBC decoder
> ffmpeg | branch: master | Paul B Mahol | Sun Jan
> 20 11:18:38 2019 +0100| [795af110f70bbd12b45ae2d3b08e7f45db5224a0] |
> committer: Paul B Mahol
>
> avcodec: add ARBC decoder
>
> Thanks Kostya for great help in reversing binary.
>
> >
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=795af110f70bbd12b45ae2d3b08e7f45db5224a0
> ---
>
> Changelog | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/arbc.c | 204
>
> libavcodec/avcodec.h | 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/version.h | 2 +-
> libavformat/riff.c | 1 +
> 8 files changed, 217 insertions(+), 1 deletion(-)
[...]
>
> +
> +static av_cold int decode_init(AVCodecContext *avctx)
> +{
> + ARBCContext *s = avctx->priv_data;
> +
> + avctx->pix_fmt = AV_PIX_FMT_RGB24;
> +
> + s->prev_frame = av_frame_alloc();
> + if (!s->prev_frame)
> + return AVERROR(ENOMEM);
> +
> + return 0;
> +}
> +
> +static av_cold int decode_close(AVCodecContext *avctx)
> +{
> + ARBCContext *s = avctx->priv_data;
> +
> + av_frame_free(&s->prev_frame);
> +
> + return 0;
> +}
> +
> +AVCodec ff_arbc_decoder = {
> + .name = "arbc",
> + .long_name = NULL_IF_CONFIG_SMALL("Gryphon's Anim Compressor"),
> + .type = AVMEDIA_TYPE_VIDEO,
> + .id = AV_CODEC_ID_ARBC,
> + .priv_data_size = sizeof(ARBCContext),
> + .init = decode_init,
> + .decode = decode_frame,
> + .close = decode_close,
> + .capabilities = AV_CODEC_CAP_DR1,
> + .caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
Why did you remove the init thread safe flag?
And this is missing an AVCodec.flush() callback to unref s->prev_frame,
for that matter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, January 28, 2019 07:47
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC
> modes
>
> Allow setting the mode explicitly, and try to make a sensible choice
> given the available parameters if not.
> ---
> doc/encoders.texi | 24 +++
> libavcodec/vaapi_encode.c | 370 +++-
> --
> libavcodec/vaapi_encode.h | 65 +++
> 3 files changed, 351 insertions(+), 108 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..29625ba07c 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2824,6 +2824,30 @@ Set the B-frame reference depth. When set to
> one (the default), all B-frames
> will refer only to P- or I-frames. When set to greater values multiple
> layers
> of B-frames will be present, frames in each layer only referring to frames in
> higher layers.
> +
> +@item rc_mode
> +Set the rate control mode to use. A given driver may only support a subset
> of
> +modes.
> +
> +Possible modes:
> +@table @option
> +@item auto
> +Choose the mode automatically based on driver support and the other
> options.
> +This is the default.
> +@item CQP
> +Constant-quality.
> +@item CBR
> +Constant-bitrate.
> +@item VBR
> +Variable-bitrate.
> +@item ICQ
> +Intelligent constant-quality.
> +@item QVBR
> +Quality-defined variable-bitrate.
> +@item AVBR
> +Average variable bitrate.
> +@end table
> +
> @end table
>
> Each encoder also has its own specific options:
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b4e9fadaee..d0e101b118 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1283,17 +1283,42 @@ fail:
> return err;
> }
>
> +static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
> +// Bitrate Quality
> +// | Maxrate | HRD/VBV
> +{ 0 }, // ||||
> +{ RC_MODE_CQP, "CQP", 1, VA_RC_CQP, 0, 0, 1, 0 },
> +{ RC_MODE_CBR, "CBR", 1, VA_RC_CBR, 1, 0, 0, 1 },
> +{ RC_MODE_VBR, "VBR", 1, VA_RC_VBR, 1, 1, 0, 1 },
> +#if VA_CHECK_VERSION(1, 1, 0)
> +{ RC_MODE_ICQ, "ICQ", 1, VA_RC_ICQ, 0, 0, 1, 0 },
> +#else
> +{ RC_MODE_ICQ, "ICQ", 0 },
> +#endif
> +#if VA_CHECK_VERSION(1, 3, 0)
> +{ RC_MODE_QVBR, "QVBR", 1, VA_RC_QVBR, 1, 1, 1, 1 },
> +{ RC_MODE_AVBR, "AVBR", 0, VA_RC_AVBR, 1, 0, 0, 0 },
> +#else
> +{ RC_MODE_QVBR, "QVBR", 0 },
> +{ RC_MODE_AVBR, "AVBR", 0 },
> +#endif
> +};
> +
> static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> +uint32_t supported_va_rc_modes;
> +const VAAPIEncodeRCMode *rc_mode;
> int64_t rc_bits_per_second;
> int rc_target_percentage;
> int rc_window_size;
> +int rc_quality;
> int64_t hrd_buffer_size;
> int64_t hrd_initial_buffer_fullness;
> int fr_num, fr_den;
> VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> VAStatus vas;
> +char supported_rc_modes_string[64];
>
> vas = vaGetConfigAttributes(ctx->hwctx->display,
> ctx->va_profile, ctx->va_entrypoint,
> @@ -1303,119 +1328,215 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
> "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> return AVERROR_EXTERNAL;
> }
> -
> if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> - "supported rate control modes: assuming constant-quality.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -return 0;
> -}
> -if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
> -avctx->flags & AV_CODEC_FLAG_QSCALE ||
> -avctx->bit_rate <= 0) {
> -if (rc_attr.value & VA_RC_CQP) {
> -av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
> -av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
> - "ignored in constant-quality mode.\n");
> + "supported rate control modes: assuming CQP only.\n");
> +supported_va_rc_modes = VA_RC_CQP;
> +strcpy(supported_rc_modes_string, "unknown");
> +} else {
> +char *str = supported_rc_modes_string;
> +size_t len = sizeof(supported_rc_modes_string);
> +int i, first = 1, res;
> +
> +supported_va_rc_modes = rc_attr.value;
> +
> +first = 1;
Redundant “first” here I think.
> +for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++)
[FFmpeg-devel] [PATCHv2] configure: request explicitly enabled components
If we enable a component but a dependant library is disabled, then the enabled
component get silently disabled. Requesting all explicitly enabled components
allows configure to fail and show the missing dependencies instead of ignoring
our request.
For example if libdav1d is not availble ./configure --enable-decoder=libdav1d
succeeds but the libdav1d decoder will not be enabled. After the patch the
configure line will fail with the following message:
ERROR: libdav1d_decoder requested, but not all dependencies are satisfied:
libdav1d
Signed-off-by: Marton Balint
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e1412352fa..afe64bf98a 100755
--- a/configure
+++ b/configure
@@ -3880,6 +3880,7 @@ for opt do
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match anything"
+test $action = enable && request $list
$action $list
;;
--enable-yasm|--disable-yasm)
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: request explicitly enabled components
If we enable a component but a dependant library is disabled, then the enabled
component get silently disabled. Requesting all explicitly enabled components
allows configure to fail and show the missing dependencies instead of ignoring
our request.
For example if libdav1d is not availble ./configure --enable-decoder=libdav1d
succeeds but the libdav1d decoder will not be enabled. After the patch the
configure line will fail with the following message:
ERROR: libdav1d_decoder requested, but not all dependencies are satisfied:
libdav1d
Signed-off-by: Marton Balint
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e1412352fa..1f6c6a7311 100755
--- a/configure
+++ b/configure
@@ -3881,6 +3881,7 @@ for opt do
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match anything"
$action $list
+test $action = enable && request $list
;;
--enable-yasm|--disable-yasm)
warn "The ${opt} option is only provided for compatibility and
will be\n"\
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
On Mon, 2019-01-28 at 00:04 +0100, Henrik Gramner wrote: > On Mon, Jan 21, 2019 at 9:54 PM James Almer wrote: > > There's also no good way to deprecate a define and replace it with > > another while informing the library user, so for something purely > > cosmetic like this i don't think it's worth the trouble. > > Would it be possible to create a deprecated inlined function that does > nothing, and add a call to that function inside the old macro? Kind of > ugly though. I already posted that suggestion last Tuesday. It does work trigger a deprecation warning, but an inline function has the drawback that it's not a constant expression. If you want to keep backward compatibility even for uses like initializing global tables or other variables, you can use a deprecated variable in ways other than a call though. For example this should be a constant expression that shows a deprecation message: // This variable does not need to really exist extern int __attribute__ ((deprecated)) RSHIFT_is_deprecated; #define RSHIFT(a, b) (0*(int)sizeof(RSHIFT_is_deprecated) + AV_ROUNDED_SHIFT(a, b)) sizeof counts as a "use" that shows the deprecation warning, while not creating any actual reference to the variable and being a constant expression. The (int) cast is there to make 100% sure that the addition doesn't change anything by changing the type of the expression. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Mon, Jan 28, 2019 at 05:29:41AM +0700, Muhammad Faiz wrote:
> On Mon, Jan 28, 2019 at 3:07 AM Michael Niedermayer
> wrote:
> >
> > On Sun, Jan 27, 2019 at 11:24:46PM +0700, Muhammad Faiz wrote:
> > > On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > > > > regardless of the actual supported formats.
> > > > > This allows filters to support only native-endian formats,
> > > > > and also allows consistency checks between little-endian
> > > > > and big-endian implementation.
> > > > >
> > > > > This also reveals bugs on gbrap10, p010, p016 format, and
> > > > > super2xsai filter (mismatched checksums between little-endian
> > > > > and big-endian).
> > > > >
> > > > > Suggested-by: Hendrik Leppkes
> > > > > Signed-off-by: Muhammad Faiz
> > > > > ---
> > > > > Old thread is here:
> > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> > > > >
> > > > > tests/fate-run.sh| 6 +-
> > > > > tests/ref/fate/filter-pixfmts-copy | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-crop | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-field | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-fieldorder | 88 +-
> > > > > tests/ref/fate/filter-pixfmts-hflip | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-il | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-null | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-scale | 112
> > > > > +++
> > > > > tests/ref/fate/filter-pixfmts-super2xsai | 8 +-
> > > > > tests/ref/fate/filter-pixfmts-swapuv | 56 ++--
> > > > > tests/ref/fate/filter-pixfmts-transpose | 90 +-
> > > > > tests/ref/fate/filter-pixfmts-vflip | 112
> > > > > +++
> > > > > 13 files changed, 573 insertions(+), 571 deletions(-)
> > > > >
> > > > > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > > > > index aece90a01d..faa4285e71 100755
> > > > > --- a/tests/fate-run.sh
> > > > > +++ b/tests/fate-run.sh
> > > > > @@ -297,8 +297,10 @@ pixfmts(){
> > > > >
> > > > > outertest=$test
> > > > > for pix_fmt in $pix_fmts; do
> > > > > -test=$pix_fmt
> > > > > -video_filter
> > > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > > > $pix_fmt -frames:v $nframes
> > > > > +# force little endian format on result
> > > > > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > > > > +test=$pix_fmt_le
> > > > > +video_filter
> > > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > > > $pix_fmt_le -frames:v $nframes
> > > > > done
> > > >
> > > > if the input to a filter is a big endian format and the output is little
> > > > endian. Then there really isnt a gurantee that the filter will work with
> > > > big endian data. The libavfilter core could convert before or after the
> > > > filter
> > > > as it preferrs. At least thats how i remember it from the last time i
> > > > looked
> > > > at the code.
> > > > This also makes sense, as there are very good reasons to convert before,
> > > > for example when doing so results in better quality or higher speed
> > > > or fewer converts overall in multi input or multi output filters...
> > >
> > > Of course, this can be easily fixed by adding format=$pix_fmt after
> > > $filter=$filter_args.
> > >
> >
> > > >
> > > > So if the output is always forced to LE then this may unintentionally
> > > > remove testing a range of cases.
> > > > also this removes testing the codepath for big endian formats after the
> > > > convert. Or do we have remaining cases that test these ?
> > >
> > > Do you suggest to duplicate test to output BE and LE simultaneously?
> >
> > I dont really have a specific suggestion, just dont want to have some
> > codepathes be lost from testing
> > a solution that doesnt duplicate all the tests would be better i guess
> > as it would be quicker
>
> Do you feel that because BE disappears in the output, it means that BE
> is untested?
no, rather that it implies that the code path after the final convert to LE
dont see BE anymore in the affected tests. I did not check if other cases
remain that test BE there
the disappearance might confuse people though,
for example a developer who runs the tests after a code change and sees
a checksum change. Its important that he understands what the change means
so he can quickly fix his code.
Seeing a LE test fail causes one to probably not think about a BE specific bug.
The case of developers seeing their or someone elses code cause a fate failure
is possibly the main area where understanding the meaning matters.
I dont know how muc
[FFmpeg-devel] [PATCH v2 08/11] vaapi_encode_mjpeg: Warn if input is not full range
---
libavcodec/vaapi_encode_mjpeg.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index 350800697f..e52f8b9820 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpeg.c
@@ -460,6 +460,11 @@ static av_cold int
vaapi_encode_mjpeg_configure(AVCodecContext *avctx)
if (err < 0)
return err;
+if (avctx->color_range == AVCOL_RANGE_MPEG) {
+av_log(avctx, AV_LOG_WARNING, "Input video does not appear "
+ "to use full-range: output colours may be incorrect.\n");
+}
+
return 0;
}
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect()
Fixes: Infinite loop
Found-by: Michael Hanselmann
Reviewed-by: Michael Hanselmann
Signed-off-by: Michael Niedermayer
---
libavformat/rtsp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ceb770a3a4..82c6c12af5 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1663,7 +1663,7 @@ int ff_rtsp_connect(AVFormatContext *s)
char tcpname[1024], cmd[2048], auth[128];
const char *lower_rtsp_proto = "tcp";
int port, err, tcp_fd;
-RTSPMessageHeader reply1 = {0}, *reply = &reply1;
+RTSPMessageHeader reply1, *reply = &reply1;
int lower_transport_mask = 0;
int default_port = RTSP_DEFAULT_PORT;
char real_challenge[64] = "";
@@ -1692,6 +1692,7 @@ int ff_rtsp_connect(AVFormatContext *s)
rt->lower_transport_mask &= (1 << RTSP_LOWER_TRANSPORT_NB) - 1;
redirect:
+memset(&reply1, 0, sizeof(reply1));
/* extract hostname and port */
av_url_split(proto, sizeof(proto), auth, sizeof(auth),
host, sizeof(host), &port, path, sizeof(path), s->url);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/rtsp: Check number of streams in sdp_parse_line()
Fixes: OOM
Found-by: Michael Hanselmann
Reviewed-by: Michael Hanselmann
Signed-off-by: Michael Niedermayer
---
libavformat/rtsp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 82c6c12af5..975637cf54 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -454,7 +454,10 @@ static void sdp_parse_line(AVFormatContext *s,
SDPParseState *s1,
} else if (!strcmp(st_type, "text")) {
codec_type = AVMEDIA_TYPE_SUBTITLE;
}
-if (codec_type == AVMEDIA_TYPE_UNKNOWN || !(rt->media_type_mask & (1
<< codec_type))) {
+if (codec_type == AVMEDIA_TYPE_UNKNOWN ||
+!(rt->media_type_mask & (1 << codec_type)) ||
+rt->nb_rtsp_streams >= s->max_streams
+) {
s1->skip_media = 1;
return;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 09/11] vaapi_encode: Add support for VFR mode
Use the frame-skip feature to maintain a specified framerate from the
point of view of the driver.
---
doc/encoders.texi | 7 +++
libavcodec/vaapi_encode.c | 116 +++---
libavcodec/vaapi_encode.h | 18 +-
3 files changed, 132 insertions(+), 9 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 29625ba07c..b8322c4e95 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2848,6 +2848,13 @@ Quality-defined variable-bitrate.
Average variable bitrate.
@end table
+@item max_fps
+Enable VFR encoding with this maximum framerate. This is implemented by
+indicating to the driver that frames have been skipped at some locations in
+the stream, and requires driver support. The minimum interval between frames
+must not be smaller than this, and there may be problems if the maximum
+interval is more than a small multiple of it.
+
@end table
Each encoder also has its own specific options:
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index d0e101b118..e5491fcd03 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -412,6 +412,29 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
}
}
+#if VA_CHECK_VERSION(0, 40, 0)
+if (ctx->vfr_mode && pic->frame_skips > 0) {
+struct {
+VAEncMiscParameterBuffer misc;
+VAEncMiscParameterSkipFrame skip;
+} param = {
+.misc = {
+.type = VAEncMiscParameterTypeSkipFrame,
+},
+.skip = {
+.skip_frame_flag = 1,
+.num_skip_frames = pic->frame_skips,
+},
+};
+
+err = vaapi_encode_make_param_buffer(avctx, pic,
+ VAEncMiscParameterBufferType,
+ (char*)¶m, sizeof(param));
+if (err < 0)
+goto fail;
+}
+#endif
+
vas = vaBeginPicture(ctx->hwctx->display, ctx->va_context,
pic->input_surface);
if (vas != VA_STATUS_SUCCESS) {
@@ -942,6 +965,36 @@ int ff_vaapi_encode_send_frame(AVCodecContext *avctx,
const AVFrame *frame)
pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->pts = frame->pts;
+if (ctx->vfr_mode && ctx->input_order > 0) {
+if (frame->pts < ctx->prev_pts) {
+av_log(avctx, AV_LOG_WARNING, "Timestamp discontinuity "
+ "(backward step: %"PRId64" -> %"PRId64"): "
+ "VFR mode reset.\n", ctx->prev_pts, frame->pts);
+ctx->ticks_outstanding = av_make_q(0, 1);
+} else {
+AVRational step_ticks, ticks;
+int ticks_int;
+step_ticks = av_div_q(av_make_q(frame->pts - ctx->prev_pts, 1),
+ ctx->ticks_per_frame);
+ticks = av_add_q(ctx->ticks_outstanding, step_ticks);
+ticks_int = ticks.num / ticks.den;
+if (ticks_int < 1) {
+av_log(avctx, AV_LOG_WARNING, "Max FPS exceeded!\n");
+} else if (ticks_int > 256) {
+av_log(avctx, AV_LOG_WARNING, "Timestamp discontinuity "
+ "(forward step: %"PRId64" -> %"PRId64"): "
+ "VFR mode reset.\n", ctx->prev_pts, frame->pts);
+} else {
+av_log(avctx, AV_LOG_DEBUG, "Inserting %d frame skips
before "
+ "frame %"PRId64".\n", ticks_int - 1, frame->pts);
+pic->frame_skips = ticks_int - 1;
+}
+ctx->ticks_outstanding =
+av_sub_q(ticks, av_make_q(ticks_int, 1));
+}
+}
+ctx->prev_pts = frame->pts;
+
if (ctx->input_order == 0)
ctx->first_pts = pic->pts;
if (ctx->input_order == ctx->decode_delay)
@@ -1315,7 +1368,6 @@ static av_cold int
vaapi_encode_init_rate_control(AVCodecContext *avctx)
int rc_quality;
int64_t hrd_buffer_size;
int64_t hrd_initial_buffer_fullness;
-int fr_num, fr_den;
VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
VAStatus vas;
char supported_rc_modes_string[64];
@@ -1607,22 +1659,66 @@ rc_mode_found:
sizeof(ctx->hrd_params));
}
-if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
-av_reduce(&fr_num, &fr_den,
- avctx->framerate.num, avctx->framerate.den, 65535);
-else
+return 0;
+}
+
+static av_cold int vaapi_encode_init_framerate(AVCodecContext *avctx)
+{
+VAAPIEncodeContext *ctx = avctx->priv_data;
+
+#if VA_CHECK_VERSION(0, 40, 0)
+int fr_num, fr_den;
+
+ctx->vfr_mode = ctx->vfr_max_fps.num > 0 && ctx->vfr_max_fps.den > 0;
+if (ctx->vfr_mode) {
+VAConfigAttrib attr = { VAConfigAttribEncSkipFrame };
+
[FFmpeg-devel] [PATCH v2 04/11] vaapi_encode_mpeg2: Enable support for more RC modes
---
libavcodec/vaapi_encode_mpeg2.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
index 9d42c3e644..174611ff24 100644
--- a/libavcodec/vaapi_encode_mpeg2.c
+++ b/libavcodec/vaapi_encode_mpeg2.c
@@ -521,19 +521,17 @@ static av_cold int
vaapi_encode_mpeg2_configure(AVCodecContext *avctx)
return err;
if (ctx->va_rc_mode == VA_RC_CQP) {
-priv->quant_p = av_clip(avctx->global_quality, 1, 31);
+priv->quant_p = av_clip(ctx->rc_quality, 1, 31);
if (avctx->i_quant_factor > 0.0)
-priv->quant_i = av_clip((avctx->global_quality *
- avctx->i_quant_factor +
- avctx->i_quant_offset) + 0.5,
-1, 31);
+priv->quant_i =
+av_clip((avctx->i_quant_factor * priv->quant_p +
+ avctx->i_quant_offset) + 0.5, 1, 31);
else
priv->quant_i = priv->quant_p;
if (avctx->b_quant_factor > 0.0)
-priv->quant_b = av_clip((avctx->global_quality *
- avctx->b_quant_factor +
- avctx->b_quant_offset) + 0.5,
-1, 31);
+priv->quant_b =
+av_clip((avctx->b_quant_factor * priv->quant_p +
+ avctx->b_quant_offset) + 0.5, 1, 31);
else
priv->quant_b = priv->quant_p;
@@ -542,7 +540,9 @@ static av_cold int
vaapi_encode_mpeg2_configure(AVCodecContext *avctx)
priv->quant_i, priv->quant_p, priv->quant_b);
} else {
-av_assert0(0 && "Invalid RC mode.");
+priv->quant_i = 16;
+priv->quant_p = 16;
+priv->quant_b = 16;
}
ctx->slice_block_rows = FFALIGN(avctx->height, 16) / 16;
@@ -567,6 +567,8 @@ static const VAAPIEncodeType vaapi_encode_type_mpeg2 = {
.configure = &vaapi_encode_mpeg2_configure,
+.default_quality = 10,
+
.sequence_params_size = sizeof(VAEncSequenceParameterBufferMPEG2),
.init_sequence_params = &vaapi_encode_mpeg2_init_sequence_params,
@@ -637,6 +639,7 @@ static av_cold int vaapi_encode_mpeg2_close(AVCodecContext
*avctx)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM)
static const AVOption vaapi_encode_mpeg2_options[] = {
VAAPI_ENCODE_COMMON_OPTIONS,
+VAAPI_ENCODE_RC_OPTIONS,
{ "profile", "Set profile (in profile_and_level_indication)",
OFFSET(profile), AV_OPT_TYPE_INT,
@@ -671,7 +674,6 @@ static const AVCodecDefault vaapi_encode_mpeg2_defaults[] =
{
{ "i_qoffset", "0" },
{ "b_qfactor", "6/5" },
{ "b_qoffset", "0" },
-{ "global_quality", "10" },
{ "qmin", "-1" },
{ "qmax", "-1" },
{ NULL },
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 07/11] vaapi_encode_mjpeg: Use common quality option
Doesn't change anything, but makes the behaviour better match that of the
other codecs (the CONSTANT_QUALITY_ONLY flag already ensures that CQP is
the only RC mode selectable for MJPEG).
---
libavcodec/vaapi_encode_mjpeg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index f0ea292098..350800697f 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpeg.c
@@ -438,7 +438,7 @@ static av_cold int
vaapi_encode_mjpeg_configure(AVCodecContext *avctx)
VAAPIEncodeMJPEGContext *priv = avctx->priv_data;
int err;
-priv->quality = avctx->global_quality;
+priv->quality = ctx->rc_quality;
if (priv->quality < 1 || priv->quality > 100) {
av_log(avctx, AV_LOG_ERROR, "Invalid quality value %d "
"(must be 1-100).\n", priv->quality);
@@ -483,6 +483,8 @@ static const VAAPIEncodeType vaapi_encode_type_mjpeg = {
.configure = &vaapi_encode_mjpeg_configure,
+.default_quality = 80,
+
.picture_params_size = sizeof(VAEncPictureParameterBufferJPEG),
.init_picture_params = &vaapi_encode_mjpeg_init_picture_params,
@@ -536,7 +538,6 @@ static const AVOption vaapi_encode_mjpeg_options[] = {
};
static const AVCodecDefault vaapi_encode_mjpeg_defaults[] = {
-{ "global_quality", "80" },
{ "b", "0" },
{ NULL },
};
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 10/11] vaapi_encode_h264: Don't include AUD with slice header
Always write it as a RawData block, even if there is no SEI as well.
---
libavcodec/vaapi_encode_h264.c | 40 +++---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index fb55eb7779..b65ee4bec0 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -187,13 +187,6 @@ static int
vaapi_encode_h264_write_slice_header(AVCodecContext *avctx,
CodedBitstreamFragment *au = &priv->current_access_unit;
int err;
-if (priv->aud_needed) {
-err = vaapi_encode_h264_add_nal(avctx, au, &priv->raw_aud);
-if (err < 0)
-goto fail;
-priv->aud_needed = 0;
-}
-
err = vaapi_encode_h264_add_nal(avctx, au, &priv->raw_slice);
if (err < 0)
goto fail;
@@ -213,16 +206,16 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
CodedBitstreamFragment *au = &priv->current_access_unit;
int err, i;
+if (priv->aud_needed) {
+err = vaapi_encode_h264_add_nal(avctx, au, &priv->raw_aud);
+if (err < 0)
+goto fail;
+priv->aud_needed = 0;
+}
+
if (priv->sei_needed) {
H264RawSEI *sei = &priv->raw_sei;
-if (priv->aud_needed) {
-err = vaapi_encode_h264_add_nal(avctx, au, &priv->raw_aud);
-if (err < 0)
-goto fail;
-priv->aud_needed = 0;
-}
-
*sei = (H264RawSEI) {
.nal_unit_header = {
.nal_unit_type = H264_NAL_SEI,
@@ -260,15 +253,6 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
goto fail;
priv->sei_needed = 0;
-err = vaapi_encode_h264_write_access_unit(avctx, data, data_len, au);
-if (err < 0)
-goto fail;
-
-ff_cbs_fragment_uninit(priv->cbc, au);
-
-*type = VAEncPackedHeaderRawData;
-return 0;
-
#if !CONFIG_VAAPI_1
} else if (priv->sei_cbr_workaround_needed) {
// Insert a zero-length header using the old SEI type. This is
@@ -285,6 +269,16 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
return AVERROR_EOF;
}
+
+err = vaapi_encode_h264_write_access_unit(avctx, data, data_len, au);
+if (err < 0)
+goto fail;
+
+ff_cbs_fragment_uninit(priv->cbc, au);
+
+*type = VAEncPackedHeaderRawData;
+return 0;
+
fail:
ff_cbs_fragment_uninit(priv->cbc, au);
return err;
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 11/11] vaapi_encode: Support limiting slice size
---
doc/encoders.texi | 4 +++
libavcodec/vaapi_encode.c | 57 ---
libavcodec/vaapi_encode.h | 9 ++-
3 files changed, 65 insertions(+), 5 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index b8322c4e95..07d9b46b2a 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2855,6 +2855,10 @@ the stream, and requires driver support. The minimum
interval between frames
must not be smaller than this, and there may be problems if the maximum
interval is more than a small multiple of it.
+@item max_slice_bytes
+Set the maximum number of bytes allowed in a single slice. Requires driver
+support. Not limited by default.
+
@end table
Each encoder also has its own specific options:
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e5491fcd03..5326245003 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -316,14 +316,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
if (pic->nb_slices == 0)
pic->nb_slices = ctx->nb_slices;
if (pic->nb_slices > 0) {
-int rounding;
-
pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
if (!pic->slices) {
err = AVERROR(ENOMEM);
goto fail;
}
-
+}
+if (pic->nb_slices > 0 && ctx->max_slice_bytes == 0) {
+int rounding;
for (i = 0; i < pic->nb_slices; i++)
pic->slices[i].row_size = ctx->slice_size;
@@ -435,6 +435,31 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
}
#endif
+#if VA_CHECK_VERSION(1, 0, 0)
+if (ctx->max_slice_bytes > 0) {
+struct {
+VAEncMiscParameterBuffer misc;
+VAEncMiscParameterMaxSliceSize slice;
+} param = {
+.misc = {
+.type = VAEncMiscParameterTypeMaxSliceSize,
+},
+.slice = {
+// VAAPI wants this value in bits.
+.max_slice_size = 8 * ctx->max_slice_bytes,
+},
+};
+
+err = vaapi_encode_make_param_buffer(avctx, pic,
+ VAEncMiscParameterBufferType,
+ (char*)¶m, sizeof(param));
+if (err < 0)
+goto fail;
+}
+#else
+av_assert0(ctx->max_slice_bytes == 0);
+#endif
+
vas = vaBeginPicture(ctx->hwctx->display, ctx->va_context,
pic->input_surface);
if (vas != VA_STATUS_SUCCESS) {
@@ -1810,7 +1835,7 @@ static av_cold int
vaapi_encode_init_slice_structure(AVCodecContext *avctx)
ctx->slice_block_cols = (avctx->width + ctx->slice_block_width - 1) /
ctx->slice_block_width;
-if (avctx->slices <= 1) {
+if (avctx->slices <= 1 && ctx->max_slice_bytes == 0) {
ctx->nb_slices = 1;
ctx->slice_size = ctx->slice_block_rows;
return 0;
@@ -1834,6 +1859,30 @@ static av_cold int
vaapi_encode_init_slice_structure(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
+if (ctx->max_slice_bytes > 0) {
+#if VA_CHECK_VERSION(1, 0, 0)
+if (slice_structure & VA_ENC_SLICE_STRUCTURE_MAX_SLICE_SIZE) {
+av_log(avctx, AV_LOG_VERBOSE, "Encoding pictures using "
+ "at most %d bytes per slice.\n",
+ ctx->max_slice_bytes);
+// In this mode we supply only a single slice structure and
+// no packed headers - the driver generates the headers for
+// each slice itself.
+ctx->nb_slices = 1;
+ctx->desired_packed_headers &= ~VA_ENC_PACKED_HEADER_SLICE;
+return 0;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Driver does not support "
+ "encoding pictures with a slice size limit.\n");
+return AVERROR(EINVAL);
+}
+#else
+av_log(avctx, AV_LOG_ERROR, "Slice size limiting is "
+ "not supported with this VAAPI version.\n");
+return AVERROR(EINVAL);
+#endif
+}
+
// For fixed-size slices currently we only support whole rows, making
// rectangular slices. This could be extended to arbitrary runs of
// blocks, but since slices tend to be a conformance requirement and
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 054cdaafbb..15a9284eaf 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -191,6 +191,9 @@ typedef struct VAAPIEncodeContext {
// framerate.
AVRational vfr_max_fps;
+// Requested maximum slice size in bytes. Ignored if zero.
+unsigned intmax_slice_bytes;
+
// Desired packed headers.
unsigned intdesired_packed_headers;
@@ -441,7 +444,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "b_depth", \
"Maximum B-frame reference depth", \
OFFSET(common.desired_b_depth), AV_OPT_TYPE_INT, \
- { .i64 = 1 },
[FFmpeg-devel] [PATCH v2 05/11] vaapi_encode_vp8: Enable support for more RC modes
---
libavcodec/vaapi_encode_vp8.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index 166636cd84..ddbe4c9075 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@ -161,14 +161,15 @@ static int
vaapi_encode_vp8_write_quant_table(AVCodecContext *avctx,
static av_cold int vaapi_encode_vp8_configure(AVCodecContext *avctx)
{
+VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodeVP8Context *priv = avctx->priv_data;
-priv->q_index_p = av_clip(avctx->global_quality, 0, VP8_MAX_QUANT);
+priv->q_index_p = av_clip(ctx->rc_quality, 0, VP8_MAX_QUANT);
if (avctx->i_quant_factor > 0.0)
-priv->q_index_i = av_clip((avctx->global_quality *
- avctx->i_quant_factor +
- avctx->i_quant_offset) + 0.5,
- 0, VP8_MAX_QUANT);
+priv->q_index_i =
+av_clip((avctx->i_quant_factor * priv->q_index_p +
+ avctx->i_quant_offset) + 0.5,
+0, VP8_MAX_QUANT);
else
priv->q_index_i = priv->q_index_p;
@@ -185,6 +186,8 @@ static const VAAPIEncodeType vaapi_encode_type_vp8 = {
.configure = &vaapi_encode_vp8_configure,
+.default_quality = 40,
+
.sequence_params_size = sizeof(VAEncSequenceParameterBufferVP8),
.init_sequence_params = &vaapi_encode_vp8_init_sequence_params,
@@ -215,6 +218,8 @@ static av_cold int vaapi_encode_vp8_init(AVCodecContext
*avctx)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM)
static const AVOption vaapi_encode_vp8_options[] = {
VAAPI_ENCODE_COMMON_OPTIONS,
+VAAPI_ENCODE_RC_OPTIONS,
+
{ "loop_filter_level", "Loop filter level",
OFFSET(loop_filter_level), AV_OPT_TYPE_INT, { .i64 = 16 }, 0, 63, FLAGS
},
{ "loop_filter_sharpness", "Loop filter sharpness",
@@ -226,7 +231,6 @@ static const AVCodecDefault vaapi_encode_vp8_defaults[] = {
{ "b", "0" },
{ "bf", "0" },
{ "g", "120" },
-{ "global_quality", "40" },
{ "qmin", "-1" },
{ "qmax", "-1" },
{ NULL },
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 06/11] vaapi_encode_vp9: Enable support for more RC modes
---
libavcodec/vaapi_encode_vp9.c | 41 +--
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index 97142dcc49..f89fd0d07a 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++ b/libavcodec/vaapi_encode_vp9.c
@@ -178,23 +178,29 @@ static int
vaapi_encode_vp9_init_picture_params(AVCodecContext *avctx,
static av_cold int vaapi_encode_vp9_configure(AVCodecContext *avctx)
{
+VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodeVP9Context *priv = avctx->priv_data;
-priv->q_idx_p = av_clip(avctx->global_quality, 0, VP9_MAX_QUANT);
-if (avctx->i_quant_factor > 0.0)
-priv->q_idx_idr = av_clip((avctx->global_quality *
- avctx->i_quant_factor +
- avctx->i_quant_offset) + 0.5,
- 0, VP9_MAX_QUANT);
-else
-priv->q_idx_idr = priv->q_idx_p;
-if (avctx->b_quant_factor > 0.0)
-priv->q_idx_b = av_clip((avctx->global_quality *
- avctx->b_quant_factor +
- avctx->b_quant_offset) + 0.5,
-0, VP9_MAX_QUANT);
-else
-priv->q_idx_b = priv->q_idx_p;
+if (ctx->rc_mode->quality) {
+priv->q_idx_p = av_clip(ctx->rc_quality, 0, VP9_MAX_QUANT);
+if (avctx->i_quant_factor > 0.0)
+priv->q_idx_idr =
+av_clip((avctx->i_quant_factor * priv->q_idx_p +
+ avctx->i_quant_offset) + 0.5,
+0, VP9_MAX_QUANT);
+else
+priv->q_idx_idr = priv->q_idx_p;
+if (avctx->b_quant_factor > 0.0)
+priv->q_idx_b =
+av_clip((avctx->b_quant_factor * priv->q_idx_p +
+ avctx->b_quant_offset) + 0.5,
+0, VP9_MAX_QUANT);
+else
+priv->q_idx_b = priv->q_idx_p;
+} else {
+// Arbitrary value.
+priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 100;
+}
return 0;
}
@@ -211,6 +217,8 @@ static const VAAPIEncodeType vaapi_encode_type_vp9 = {
.flags = FLAG_B_PICTURES |
FLAG_B_PICTURE_REFERENCES,
+.default_quality = 100,
+
.picture_priv_data_size = sizeof(VAAPIEncodeVP9Picture),
.configure = &vaapi_encode_vp9_configure,
@@ -244,6 +252,8 @@ static av_cold int vaapi_encode_vp9_init(AVCodecContext
*avctx)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM)
static const AVOption vaapi_encode_vp9_options[] = {
VAAPI_ENCODE_COMMON_OPTIONS,
+VAAPI_ENCODE_RC_OPTIONS,
+
{ "loop_filter_level", "Loop filter level",
OFFSET(loop_filter_level), AV_OPT_TYPE_INT, { .i64 = 16 }, 0, 63, FLAGS
},
{ "loop_filter_sharpness", "Loop filter sharpness",
@@ -255,7 +265,6 @@ static const AVCodecDefault vaapi_encode_vp9_defaults[] = {
{ "b", "0" },
{ "bf", "0" },
{ "g", "250" },
-{ "global_quality", "100" },
{ "qmin", "-1" },
{ "qmax", "-1" },
{ NULL },
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 03/11] vaapi_encode_h265: Enable support for more RC modes
Also fixes QP going out of range when modified by the quant factor/offset
values, and clarifies the QP behaviour for >8-bit modes.
---
libavcodec/vaapi_encode_h265.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 19e7104e9e..286f6a22c7 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1076,15 +1076,21 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
return err;
if (ctx->va_rc_mode == VA_RC_CQP) {
-priv->fixed_qp_p = priv->qp;
+// Note that VAAPI only supports positive QP values - the range is
+// therefore always bounded below by 1, even in 10-bit mode where
+// it should go down to -12.
+
+priv->fixed_qp_p = av_clip(ctx->rc_quality, 1, 51);
if (avctx->i_quant_factor > 0.0)
-priv->fixed_qp_idr = (int)((priv->fixed_qp_p *
avctx->i_quant_factor +
-avctx->i_quant_offset) + 0.5);
+priv->fixed_qp_idr =
+av_clip((avctx->i_quant_factor * priv->fixed_qp_p +
+ avctx->i_quant_offset) + 0.5, 1, 51);
else
priv->fixed_qp_idr = priv->fixed_qp_p;
if (avctx->b_quant_factor > 0.0)
-priv->fixed_qp_b = (int)((priv->fixed_qp_p * avctx->b_quant_factor
+
- avctx->b_quant_offset) + 0.5);
+priv->fixed_qp_b =
+av_clip((avctx->b_quant_factor * priv->fixed_qp_p +
+ avctx->b_quant_offset) + 0.5, 1, 51);
else
priv->fixed_qp_b = priv->fixed_qp_p;
@@ -1092,15 +1098,11 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
"%d / %d / %d for IDR- / P- / B-frames.\n",
priv->fixed_qp_idr, priv->fixed_qp_p, priv->fixed_qp_b);
-} else if (ctx->va_rc_mode == VA_RC_CBR ||
- ctx->va_rc_mode == VA_RC_VBR) {
-// These still need to be set for pic_init_qp/slice_qp_delta.
+} else {
+// These still need to be set for pic_init_qp/slice_qp_delta.
priv->fixed_qp_idr = 30;
priv->fixed_qp_p = 30;
priv->fixed_qp_b = 30;
-
-} else {
-av_assert0(0 && "Invalid RC mode.");
}
return 0;
@@ -1124,6 +1126,8 @@ static const VAAPIEncodeType vaapi_encode_type_h265 = {
FLAG_B_PICTURE_REFERENCES |
FLAG_NON_IDR_KEY_PICTURES,
+.default_quality = 25,
+
.configure = &vaapi_encode_h265_configure,
.picture_priv_data_size = sizeof(VAAPIEncodeH265Picture),
@@ -1175,6 +1179,9 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext
*avctx)
// CTU size is currently hard-coded to 32.
ctx->slice_block_width = ctx->slice_block_height = 32;
+if (priv->qp > 0)
+ctx->explicit_qp = priv->qp;
+
return ff_vaapi_encode_init(avctx);
}
@@ -1191,9 +1198,10 @@ static av_cold int
vaapi_encode_h265_close(AVCodecContext *avctx)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM)
static const AVOption vaapi_encode_h265_options[] = {
VAAPI_ENCODE_COMMON_OPTIONS,
+VAAPI_ENCODE_RC_OPTIONS,
{ "qp", "Constant QP (for P-frames; scaled by qfactor/qoffset for I/B)",
- OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, 52, FLAGS },
+ OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 52, FLAGS },
{ "aud", "Include AUD",
OFFSET(aud), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 02/11] vaapi_encode_h264: Enable support for more RC modes
Also fixes QP going out of range when modified by the quant factor/offset
values.
---
libavcodec/vaapi_encode_h264.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 4ea62d96f3..fb55eb7779 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -1071,33 +1071,34 @@ static av_cold int
vaapi_encode_h264_configure(AVCodecContext *avctx)
priv->mb_height = FFALIGN(avctx->height, 16) / 16;
if (ctx->va_rc_mode == VA_RC_CQP) {
-priv->fixed_qp_p = priv->qp;
+priv->fixed_qp_p = av_clip(ctx->rc_quality, 1, 51);
if (avctx->i_quant_factor > 0.0)
-priv->fixed_qp_idr = (int)((priv->fixed_qp_p *
avctx->i_quant_factor +
-avctx->i_quant_offset) + 0.5);
+priv->fixed_qp_idr =
+av_clip((avctx->i_quant_factor * priv->fixed_qp_p +
+ avctx->i_quant_offset) + 0.5, 1, 51);
else
priv->fixed_qp_idr = priv->fixed_qp_p;
if (avctx->b_quant_factor > 0.0)
-priv->fixed_qp_b = (int)((priv->fixed_qp_p * avctx->b_quant_factor
+
- avctx->b_quant_offset) + 0.5);
+priv->fixed_qp_b =
+av_clip((avctx->b_quant_factor * priv->fixed_qp_p +
+ avctx->b_quant_offset) + 0.5, 1, 51);
else
priv->fixed_qp_b = priv->fixed_qp_p;
-priv->sei &= ~SEI_TIMING;
-
av_log(avctx, AV_LOG_DEBUG, "Using fixed QP = "
"%d / %d / %d for IDR- / P- / B-frames.\n",
priv->fixed_qp_idr, priv->fixed_qp_p, priv->fixed_qp_b);
-} else if (ctx->va_rc_mode == VA_RC_CBR ||
- ctx->va_rc_mode == VA_RC_VBR) {
+} else {
// These still need to be set for pic_init_qp/slice_qp_delta.
priv->fixed_qp_idr = 26;
priv->fixed_qp_p = 26;
priv->fixed_qp_b = 26;
+}
-} else {
-av_assert0(0 && "Invalid RC mode.");
+if (!ctx->rc_mode->hrd) {
+// Timing SEI requires a mode respecting HRD parameters.
+priv->sei &= ~SEI_TIMING;
}
if (priv->sei & SEI_IDENTIFIER) {
@@ -1147,6 +1148,8 @@ static const VAAPIEncodeType vaapi_encode_type_h264 = {
FLAG_B_PICTURE_REFERENCES |
FLAG_NON_IDR_KEY_PICTURES,
+.default_quality = 20,
+
.configure = &vaapi_encode_h264_configure,
.picture_priv_data_size = sizeof(VAAPIEncodeH264Picture),
@@ -1226,6 +1229,9 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext
*avctx)
ctx->slice_block_height = ctx->slice_block_width = 16;
+if (priv->qp > 0)
+ctx->explicit_qp = priv->qp;
+
return ff_vaapi_encode_init(avctx);
}
@@ -1243,9 +1249,10 @@ static av_cold int
vaapi_encode_h264_close(AVCodecContext *avctx)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM)
static const AVOption vaapi_encode_h264_options[] = {
VAAPI_ENCODE_COMMON_OPTIONS,
+VAAPI_ENCODE_RC_OPTIONS,
{ "qp", "Constant QP (for P-frames; scaled by qfactor/qoffset for I/B)",
- OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 20 }, 0, 52, FLAGS },
+ OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 52, FLAGS },
{ "quality", "Set encode quality (trades off against speed, higher is
faster)",
OFFSET(quality), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, FLAGS },
{ "coder", "Entropy coder type",
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
Allow setting the mode explicitly, and try to make a sensible choice
given the available parameters if not.
---
doc/encoders.texi | 24 +++
libavcodec/vaapi_encode.c | 370 +++---
libavcodec/vaapi_encode.h | 65 +++
3 files changed, 351 insertions(+), 108 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..29625ba07c 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2824,6 +2824,30 @@ Set the B-frame reference depth. When set to one (the
default), all B-frames
will refer only to P- or I-frames. When set to greater values multiple layers
of B-frames will be present, frames in each layer only referring to frames in
higher layers.
+
+@item rc_mode
+Set the rate control mode to use. A given driver may only support a subset of
+modes.
+
+Possible modes:
+@table @option
+@item auto
+Choose the mode automatically based on driver support and the other options.
+This is the default.
+@item CQP
+Constant-quality.
+@item CBR
+Constant-bitrate.
+@item VBR
+Variable-bitrate.
+@item ICQ
+Intelligent constant-quality.
+@item QVBR
+Quality-defined variable-bitrate.
+@item AVBR
+Average variable bitrate.
+@end table
+
@end table
Each encoder also has its own specific options:
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index b4e9fadaee..d0e101b118 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1283,17 +1283,42 @@ fail:
return err;
}
+static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
+// Bitrate Quality
+// | Maxrate | HRD/VBV
+{ 0 }, // ||||
+{ RC_MODE_CQP, "CQP", 1, VA_RC_CQP, 0, 0, 1, 0 },
+{ RC_MODE_CBR, "CBR", 1, VA_RC_CBR, 1, 0, 0, 1 },
+{ RC_MODE_VBR, "VBR", 1, VA_RC_VBR, 1, 1, 0, 1 },
+#if VA_CHECK_VERSION(1, 1, 0)
+{ RC_MODE_ICQ, "ICQ", 1, VA_RC_ICQ, 0, 0, 1, 0 },
+#else
+{ RC_MODE_ICQ, "ICQ", 0 },
+#endif
+#if VA_CHECK_VERSION(1, 3, 0)
+{ RC_MODE_QVBR, "QVBR", 1, VA_RC_QVBR, 1, 1, 1, 1 },
+{ RC_MODE_AVBR, "AVBR", 0, VA_RC_AVBR, 1, 0, 0, 0 },
+#else
+{ RC_MODE_QVBR, "QVBR", 0 },
+{ RC_MODE_AVBR, "AVBR", 0 },
+#endif
+};
+
static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
+uint32_t supported_va_rc_modes;
+const VAAPIEncodeRCMode *rc_mode;
int64_t rc_bits_per_second;
int rc_target_percentage;
int rc_window_size;
+int rc_quality;
int64_t hrd_buffer_size;
int64_t hrd_initial_buffer_fullness;
int fr_num, fr_den;
VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
VAStatus vas;
+char supported_rc_modes_string[64];
vas = vaGetConfigAttributes(ctx->hwctx->display,
ctx->va_profile, ctx->va_entrypoint,
@@ -1303,119 +1328,215 @@ static av_cold int
vaapi_encode_init_rate_control(AVCodecContext *avctx)
"config attribute: %d (%s).\n", vas, vaErrorStr(vas));
return AVERROR_EXTERNAL;
}
-
if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
- "supported rate control modes: assuming constant-quality.\n");
-ctx->va_rc_mode = VA_RC_CQP;
-return 0;
-}
-if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
-avctx->flags & AV_CODEC_FLAG_QSCALE ||
-avctx->bit_rate <= 0) {
-if (rc_attr.value & VA_RC_CQP) {
-av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
-ctx->va_rc_mode = VA_RC_CQP;
-if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
-av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
- "ignored in constant-quality mode.\n");
+ "supported rate control modes: assuming CQP only.\n");
+supported_va_rc_modes = VA_RC_CQP;
+strcpy(supported_rc_modes_string, "unknown");
+} else {
+char *str = supported_rc_modes_string;
+size_t len = sizeof(supported_rc_modes_string);
+int i, first = 1, res;
+
+supported_va_rc_modes = rc_attr.value;
+
+first = 1;
+for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
+rc_mode = &vaapi_encode_rc_modes[i];
+if (supported_va_rc_modes & rc_mode->va_mode) {
+res = snprintf(str, len, "%s%s",
+ first ? "" : ", ", rc_mode->name);
+first = 0;
+if (res < 0) {
+*str = 0;
+break;
+}
+len -= res;
+str += res;
+if (len == 0)
+break;
}
-return 0;
-} else {
-av_lo
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
On Mon, Jan 21, 2019 at 9:54 PM James Almer wrote: > There's also no good way to deprecate a define and replace it with > another while informing the library user, so for something purely > cosmetic like this i don't think it's worth the trouble. Would it be possible to create a deprecated inlined function that does nothing, and add a call to that function inside the old macro? Kind of ugly though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi_encode_h265: Ensure that ref pics are always in the RPS
On 25/01/2019 20:40, Eoff, Ullysses A wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of >> Mark Thompson >> Sent: Friday, January 25, 2019 12:05 PM >> To: FFmpeg development discussions and patches >> Subject: [FFmpeg-devel] [PATCH] vaapi_encode_h265: Ensure that ref pics are >> always in the RPS >> >> When making a new P-frame when B-frames are present the previous P-frame >> is normally in the DPB because it will be referred to by subsequent >> B-frames. However, this is not true if there are no B-frames, or in edge >> cases where a GOP ends with two P-frames. Fix this by adding the direct >> ref pics to the RPS explicitly. >> >> Fixes #7699. > > This patch fixes #7699 for me. Thanks! :) Applied. Thank you for the report, and for testing! - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale
On Mon, Jan 28, 2019 at 2:52 AM Michael Niedermayer wrote: > > On Sun, Jan 27, 2019 at 04:36:16PM +0700, Muhammad Faiz wrote: > > Fix inconsistent checksums between gbrap10be > > and gbrap10le on fate-filter-pixfmts. > > > > Signed-off-by: Muhammad Faiz > > --- > > libswscale/swscale_unscaled.c| 3 +++ > > tests/ref/fate/filter-pixfmts-copy | 2 +- > > tests/ref/fate/filter-pixfmts-crop | 2 +- > > tests/ref/fate/filter-pixfmts-field | 2 +- > > tests/ref/fate/filter-pixfmts-fieldorder | 2 +- > > tests/ref/fate/filter-pixfmts-hflip | 2 +- > > tests/ref/fate/filter-pixfmts-il | 2 +- > > tests/ref/fate/filter-pixfmts-null | 2 +- > > tests/ref/fate/filter-pixfmts-transpose | 2 +- > > tests/ref/fate/filter-pixfmts-vflip | 2 +- > > 10 files changed, 12 insertions(+), 9 deletions(-) > > > > diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c > > index 058f2b94db..9abfae5c04 100644 > > --- a/libswscale/swscale_unscaled.c > > +++ b/libswscale/swscale_unscaled.c > > @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c) > > dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == > > AV_PIX_FMT_GBRP12BE || > > dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == > > AV_PIX_FMT_GBRP14BE || > > dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == > > AV_PIX_FMT_GBRP16BE || > > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == > > AV_PIX_FMT_GBRAP10LE || > > dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == > > AV_PIX_FMT_GBRAP12BE || > > dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == > > AV_PIX_FMT_GBRAP16BE )) > > c->swscale = Rgb16ToPlanarRgb16Wrapper; > > > @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c) > > srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == > > AV_PIX_FMT_GBRP10BE || > > srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == > > AV_PIX_FMT_GBRP12BE || > > srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == > > AV_PIX_FMT_GBRP14BE || > > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == > > AV_PIX_FMT_GBRAP10LE || > > srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == > > AV_PIX_FMT_GBRAP12BE || > > srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == > > AV_PIX_FMT_GBRAP16BE) && > > this looks a bit strange, the added line adds a dstFormat check into a list of > srcFormat checks, also the check is added twice My bad. Will fix it. Thx. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Mon, Jan 28, 2019 at 3:07 AM Michael Niedermayer
wrote:
>
> On Sun, Jan 27, 2019 at 11:24:46PM +0700, Muhammad Faiz wrote:
> > On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
> > wrote:
> > >
> > > On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > > > regardless of the actual supported formats.
> > > > This allows filters to support only native-endian formats,
> > > > and also allows consistency checks between little-endian
> > > > and big-endian implementation.
> > > >
> > > > This also reveals bugs on gbrap10, p010, p016 format, and
> > > > super2xsai filter (mismatched checksums between little-endian
> > > > and big-endian).
> > > >
> > > > Suggested-by: Hendrik Leppkes
> > > > Signed-off-by: Muhammad Faiz
> > > > ---
> > > > Old thread is here:
> > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> > > >
> > > > tests/fate-run.sh| 6 +-
> > > > tests/ref/fate/filter-pixfmts-copy | 112 +++
> > > > tests/ref/fate/filter-pixfmts-crop | 112 +++
> > > > tests/ref/fate/filter-pixfmts-field | 112 +++
> > > > tests/ref/fate/filter-pixfmts-fieldorder | 88 +-
> > > > tests/ref/fate/filter-pixfmts-hflip | 112 +++
> > > > tests/ref/fate/filter-pixfmts-il | 112 +++
> > > > tests/ref/fate/filter-pixfmts-null | 112 +++
> > > > tests/ref/fate/filter-pixfmts-scale | 112 +++
> > > > tests/ref/fate/filter-pixfmts-super2xsai | 8 +-
> > > > tests/ref/fate/filter-pixfmts-swapuv | 56 ++--
> > > > tests/ref/fate/filter-pixfmts-transpose | 90 +-
> > > > tests/ref/fate/filter-pixfmts-vflip | 112 +++
> > > > 13 files changed, 573 insertions(+), 571 deletions(-)
> > > >
> > > > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > > > index aece90a01d..faa4285e71 100755
> > > > --- a/tests/fate-run.sh
> > > > +++ b/tests/fate-run.sh
> > > > @@ -297,8 +297,10 @@ pixfmts(){
> > > >
> > > > outertest=$test
> > > > for pix_fmt in $pix_fmts; do
> > > > -test=$pix_fmt
> > > > -video_filter
> > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > > $pix_fmt -frames:v $nframes
> > > > +# force little endian format on result
> > > > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > > > +test=$pix_fmt_le
> > > > +video_filter
> > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > > $pix_fmt_le -frames:v $nframes
> > > > done
> > >
> > > if the input to a filter is a big endian format and the output is little
> > > endian. Then there really isnt a gurantee that the filter will work with
> > > big endian data. The libavfilter core could convert before or after the
> > > filter
> > > as it preferrs. At least thats how i remember it from the last time i
> > > looked
> > > at the code.
> > > This also makes sense, as there are very good reasons to convert before,
> > > for example when doing so results in better quality or higher speed
> > > or fewer converts overall in multi input or multi output filters...
> >
> > Of course, this can be easily fixed by adding format=$pix_fmt after
> > $filter=$filter_args.
> >
>
> > >
> > > So if the output is always forced to LE then this may unintentionally
> > > remove testing a range of cases.
> > > also this removes testing the codepath for big endian formats after the
> > > convert. Or do we have remaining cases that test these ?
> >
> > Do you suggest to duplicate test to output BE and LE simultaneously?
>
> I dont really have a specific suggestion, just dont want to have some
> codepathes be lost from testing
> a solution that doesnt duplicate all the tests would be better i guess
> as it would be quicker
Do you feel that because BE disappears in the output, it means that BE
is untested?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add discard_sample_percentage
On Sat, Jan 19, 2019 at 12:00:48AM +0100, Michael Niedermayer wrote: > Suggested-by: BBB > Signed-off-by: Michael Niedermayer > --- > doc/APIchanges | 3 +++ > libavcodec/avcodec.h | 8 > libavcodec/options_table.h | 1 + > tests/ref/fate/api-mjpeg-codec-param | 2 ++ > tests/ref/fate/api-png-codec-param | 2 ++ > 5 files changed, 16 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them
On Fri, Jan 18, 2019 at 11:41:35PM +, Matthew Fearnley wrote:
>
> > On 18 Jan 2019, at 23:00, Michael Niedermayer
> > wrote:
> >
> > Fixes: Timeout
> > Fixes:
> > 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> >
> > Before:
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> > in 15423 ms
> > After:
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> > in 190 ms
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/rscc.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> > index 7921f149ed..3868c1cb1b 100644
> > --- a/libavcodec/rscc.c
> > +++ b/libavcodec/rscc.c
> > @@ -64,6 +64,7 @@ typedef struct RsccContext {
> > /* zlib interaction */
> > uint8_t *inflated_buf;
> > uLongf inflated_size;
> > +int valid_pixels
> > } RsccContext;
> >
> > static av_cold int rscc_init(AVCodecContext *avctx)
> > @@ -348,7 +349,11 @@ static int rscc_decode_frame(AVCodecContext *avctx,
> > void *data,
> > memcpy (frame->data[1], ctx->palette, AVPALETTE_SIZE);
> > }
> >
> > -*got_frame = 1;
> > +// We only return a picture when too little is undameged, this avoids
> > copying nearly broken frames around
> Hi,
> FWIW, I think “too little is undameged” should say: “enough of it is
> undamaged”
> (i.e. invert the logic, fix the typo).
will apply with the better wording
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tools/target_dec_fate.list: add entries upto 1214
On Sat, Jan 19, 2019 at 02:09:56AM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fate.list | 63 ++ > 1 file changed, 63 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/huffyuvdec: Check slice_offset/size
On Mon, Jan 21, 2019 at 01:08:41AM +0100, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 12447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5201623956062208 > Fixes: > 12458/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5705567736168448 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/huffyuvdec.c | 5 + > 1 file changed, 5 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ilbcdec: Fix integer overflow in construct_vector()
On Tue, Jan 15, 2019 at 12:29:42AM +0100, Michael Niedermayer wrote: > webrtc contains explicit code to ignore the undefined behavior > (RTC_NO_SANITIZE / OverflowingAddS32S32ToS32()) > > Probably fixes: Integer overflow (unreproducable here) > Probably fixes: > 12215/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5767142427852800 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/ilbcdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add AVS2 section
On Sat, Jul 28, 2018 at 11:20:48AM +0800, hwren wrote: > Signed-off-by: hwren > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
Hi!
Attached patch was requested in ticket #7220 iiuc.
Please review, Carl Eugen
From a713b58767e8d77b641d1b87e68de11c176fd454 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 27 Jan 2019 22:35:51 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.
---
libavformat/avformat.h |8
libavformat/format.c |4 ++--
libavformat/hls.c |2 +-
libavformat/utils.c|4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..9cfdbe8 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1346,7 +1346,7 @@ typedef struct AVFormatContext {
*
* Demuxing only, set by avformat_open_input().
*/
-struct AVInputFormat *iformat;
+const struct AVInputFormat *iformat;
/**
* The output container format.
@@ -2272,14 +2272,14 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score
* the maximal score is AVPROBE_SCORE_MAX
* AVERROR code otherwise
*/
-int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat **fmt,
+int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat const **fmt,
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
/**
* Like av_probe_input_buffer2() but returns 0 on success
*/
-int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
+int av_probe_input_buffer(AVIOContext *pb, const AVInputFormat **fmt,
const char *url, void *logctx,
unsigned int offset, unsigned int max_probe_size);
@@ -2302,7 +2302,7 @@ int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
*
* @note If you want to use custom IO, preallocate the format context and set its pb field.
*/
-int avformat_open_input(AVFormatContext **ps, const char *url, AVInputFormat *fmt, AVDictionary **options);
+int avformat_open_input(AVFormatContext **ps, const char *url, const AVInputFormat *fmt, AVDictionary **options);
attribute_deprecated
int av_demuxer_open(AVFormatContext *ic);
diff --git a/libavformat/format.c b/libavformat/format.c
index 2c4c895..157e09a 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -219,7 +219,7 @@ AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened)
return av_probe_input_format2(pd, is_opened, &score);
}
-int av_probe_input_buffer2(AVIOContext *pb, AVInputFormat **fmt,
+int av_probe_input_buffer2(AVIOContext *pb, const AVInputFormat **fmt,
const char *filename, void *logctx,
unsigned int offset, unsigned int max_probe_size)
{
@@ -309,7 +309,7 @@ fail:
return ret < 0 ? ret : score;
}
-int av_probe_input_buffer(AVIOContext *pb, AVInputFormat **fmt,
+int av_probe_input_buffer(AVIOContext *pb, const AVInputFormat **fmt,
const char *filename, void *logctx,
unsigned int offset, unsigned int max_probe_size)
{
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 8975a87..4c2265a 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1868,7 +1868,7 @@ static int hls_read_header(AVFormatContext *s)
/* Open the demuxer for each playlist */
for (i = 0; i < c->n_playlists; i++) {
struct playlist *pls = c->playlists[i];
-AVInputFormat *in_fmt = NULL;
+const AVInputFormat *in_fmt = NULL;
if (!(pls->ctx = avformat_alloc_context())) {
ret = AVERROR(ENOMEM);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7afef54..98e8849 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -535,7 +535,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
int avformat_open_input(AVFormatContext **ps, const char *filename,
-AVInputFormat *fmt, AVDictionary **options)
+const AVInputFormat *fmt, AVDictionary **options)
{
AVFormatContext *s = *ps;
int i, ret = 0;
@@ -2163,7 +2163,7 @@ static int64_t ff_read_timestamp(AVFormatContext *s, int stream_index, int64_t *
int ff_seek_frame_binary(AVFormatContext *s, int stream_index,
int64_t target_ts, int flags)
{
-AVInputFormat *avif = s->iformat;
+const AVInputFormat *avif = s->iformat;
int64_t av_uninit(pos_min), av_uninit(pos_max), pos, pos_limit;
int64_t ts_min, ts_max, ts;
int index;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libass cannot be detected in centos 7
On Sun, Jan 27, 2019 at 23:48:51 +0300, Dennis Mungai wrote:
> I'm building ffmpeg on centos 7 and one issue keeps cropping up:
This mailing list (ffmpeg-devel) covers topics around the development
of ffmpeg. Your question belongs on ffmpeg-user.
> libass. Yes, its' installed. But ffmpeg's ./configure stage won't detect it.
[...]
> BEGIN /tmp/ffconf.Du3r0RrN/test.c
> 1 #include
> 2 #include
> 3 long check_ass_library_init(void) { return (long) ass_library_init; }
> 4 int main(void) { int ret = 0;
> 5ret |= ((intptr_t)check_ass_library_init) & 0x;
> 6 return ret; }
> END /tmp/ffconf.Du3r0RrN/test.c
> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/opt/ffmpeg/include
> -I/usr/local/cuda/include/ -I/usr/include/
> +-std=c11 -fomit-frame-pointer -I/opt/ffmpeg/include -pthread
> -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2
> -I/usr/include/glib-2.0
> +-I/usr/lib64/glib-2.0/include -I/usr/include/uuid -I/usr/include/libpng15
> -pthread -c -o /tmp/ffconf.Du3r0RrN/test.o /tmp/ffconf.Du3r0RrN/test.c
>
> gcc -L/opt/ffmpeg/lib -L/usr/local/cuda/lib64/ -L/usr/lib64/ -Wl,--as-needed
> -Wl,-z,noexecstack -I/usr/include/harfbuzz -I/usr/include/fribidi
> -I/usr/include/freetype2
> +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/uuid
> -I/usr/include/libpng15 -pthread -o /tmp/ffconf.Du3r0RrN/test
> /tmp/ffconf.Du3r0RrN/test.o -lass
> +-lharfbuzz -lfontconfig -lfribidi -lglib-2.0 -lgraphite2 -lpcre -luuid
> -lexpat -lfreetype -lbz2 -lpng15 -lz -lm -lpthread -lm
>
> /usr/bin/ld: cannot find -lbz2
> collect2: error: ld returned 1 exit status
> ERROR: libass not found using pkg-config
The essential error is "cannot find -lbz2". One of your dependencies
seems to require libbz2 - you need to install libbz2-devel.
(This isn't a direct ffmpeg dependency. ffmpeg previously already
checks for libbz2 - for matroska's sake - and figures out it's not
there.)
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/1] libavdevice/v4l2enc: support additional v4l2 output formats
From: James Hilliard
The purpose of this patch is to fix a bug where ffmpeg would only
output rawvideo to a v4l2loopback device even though v4l2loopback
accepts other formats such as mjpeg.
Signed-off-by: James Hilliard
---
libavdevice/v4l2enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index faf6e07..f778208 100644
--- a/libavdevice/v4l2enc.c
+++ b/libavdevice/v4l2enc.c
@@ -47,8 +47,7 @@ static av_cold int write_header(AVFormatContext *s1)
}
if (s1->nb_streams != 1 ||
-s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
-s1->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
+s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
av_log(s1, AV_LOG_ERROR,
"V4L2 output device supports only a single raw video stream\n");
return AVERROR(EINVAL);
@@ -56,7 +55,7 @@ static av_cold int write_header(AVFormatContext *s1)
par = s1->streams[0]->codecpar;
-v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE,
s1->streams[0]->codecpar->codec_id);
if (!v4l2_pixfmt) { // XXX: try to force them one by one?
av_log(s1, AV_LOG_ERROR, "Unknown V4L2 pixel format equivalent for
%s\n",
av_get_pix_fmt_name(par->format));
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 11:24:46PM +0700, Muhammad Faiz wrote:
> On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
> wrote:
> >
> > On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > > regardless of the actual supported formats.
> > > This allows filters to support only native-endian formats,
> > > and also allows consistency checks between little-endian
> > > and big-endian implementation.
> > >
> > > This also reveals bugs on gbrap10, p010, p016 format, and
> > > super2xsai filter (mismatched checksums between little-endian
> > > and big-endian).
> > >
> > > Suggested-by: Hendrik Leppkes
> > > Signed-off-by: Muhammad Faiz
> > > ---
> > > Old thread is here:
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> > >
> > > tests/fate-run.sh| 6 +-
> > > tests/ref/fate/filter-pixfmts-copy | 112 +++
> > > tests/ref/fate/filter-pixfmts-crop | 112 +++
> > > tests/ref/fate/filter-pixfmts-field | 112 +++
> > > tests/ref/fate/filter-pixfmts-fieldorder | 88 +-
> > > tests/ref/fate/filter-pixfmts-hflip | 112 +++
> > > tests/ref/fate/filter-pixfmts-il | 112 +++
> > > tests/ref/fate/filter-pixfmts-null | 112 +++
> > > tests/ref/fate/filter-pixfmts-scale | 112 +++
> > > tests/ref/fate/filter-pixfmts-super2xsai | 8 +-
> > > tests/ref/fate/filter-pixfmts-swapuv | 56 ++--
> > > tests/ref/fate/filter-pixfmts-transpose | 90 +-
> > > tests/ref/fate/filter-pixfmts-vflip | 112 +++
> > > 13 files changed, 573 insertions(+), 571 deletions(-)
> > >
> > > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > > index aece90a01d..faa4285e71 100755
> > > --- a/tests/fate-run.sh
> > > +++ b/tests/fate-run.sh
> > > @@ -297,8 +297,10 @@ pixfmts(){
> > >
> > > outertest=$test
> > > for pix_fmt in $pix_fmts; do
> > > -test=$pix_fmt
> > > -video_filter
> > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > $pix_fmt -frames:v $nframes
> > > +# force little endian format on result
> > > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > > +test=$pix_fmt_le
> > > +video_filter
> > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > > $pix_fmt_le -frames:v $nframes
> > > done
> >
> > if the input to a filter is a big endian format and the output is little
> > endian. Then there really isnt a gurantee that the filter will work with
> > big endian data. The libavfilter core could convert before or after the
> > filter
> > as it preferrs. At least thats how i remember it from the last time i looked
> > at the code.
> > This also makes sense, as there are very good reasons to convert before,
> > for example when doing so results in better quality or higher speed
> > or fewer converts overall in multi input or multi output filters...
>
> Of course, this can be easily fixed by adding format=$pix_fmt after
> $filter=$filter_args.
>
> >
> > So if the output is always forced to LE then this may unintentionally
> > remove testing a range of cases.
> > also this removes testing the codepath for big endian formats after the
> > convert. Or do we have remaining cases that test these ?
>
> Do you suggest to duplicate test to output BE and LE simultaneously?
I dont really have a specific suggestion, just dont want to have some
codepathes be lost from testing
a solution that doesnt duplicate all the tests would be better i guess
as it would be quicker
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale
On Sun, Jan 27, 2019 at 04:36:16PM +0700, Muhammad Faiz wrote: > Fix inconsistent checksums between gbrap10be > and gbrap10le on fate-filter-pixfmts. > > Signed-off-by: Muhammad Faiz > --- > libswscale/swscale_unscaled.c| 3 +++ > tests/ref/fate/filter-pixfmts-copy | 2 +- > tests/ref/fate/filter-pixfmts-crop | 2 +- > tests/ref/fate/filter-pixfmts-field | 2 +- > tests/ref/fate/filter-pixfmts-fieldorder | 2 +- > tests/ref/fate/filter-pixfmts-hflip | 2 +- > tests/ref/fate/filter-pixfmts-il | 2 +- > tests/ref/fate/filter-pixfmts-null | 2 +- > tests/ref/fate/filter-pixfmts-transpose | 2 +- > tests/ref/fate/filter-pixfmts-vflip | 2 +- > 10 files changed, 12 insertions(+), 9 deletions(-) > > diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c > index 058f2b94db..9abfae5c04 100644 > --- a/libswscale/swscale_unscaled.c > +++ b/libswscale/swscale_unscaled.c > @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c) > dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == > AV_PIX_FMT_GBRP12BE || > dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == > AV_PIX_FMT_GBRP14BE || > dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == > AV_PIX_FMT_GBRP16BE || > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == > AV_PIX_FMT_GBRAP10LE || > dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == > AV_PIX_FMT_GBRAP12BE || > dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == > AV_PIX_FMT_GBRAP16BE )) > c->swscale = Rgb16ToPlanarRgb16Wrapper; > @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c) > srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == > AV_PIX_FMT_GBRP10BE || > srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == > AV_PIX_FMT_GBRP12BE || > srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == > AV_PIX_FMT_GBRP14BE || > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == > AV_PIX_FMT_GBRAP10LE || > srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == > AV_PIX_FMT_GBRAP12BE || > srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == > AV_PIX_FMT_GBRAP16BE) && this looks a bit strange, the added line adds a dstFormat check into a list of srcFormat checks, also the check is added twice [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gdigrab: fix HIDPI support for mouse positioning
New version, which uses integer arithmetics
--
With the best regards,
Dilshod
>From 586d4b3ed3406b66e3d0bd69806bc33beaddc026 Mon Sep 17 00:00:00 2001
From: Dilshod Mukhtarov
Date: Sun, 27 Jan 2019 23:10:37 +0400
Subject: [PATCH 2/2] libavdevice/gdigrab: fix HIDPI support for mouse
positioning
Mouse position was not calculated properly in area or window mode
Signed-off-by: Dilshod Mukhtarov
---
libavdevice/gdigrab.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 0e6ae2bd5d..b226bd0831 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -479,25 +479,26 @@ static void paint_mouse_pointer(AVFormatContext *s1, struct gdigrab *gdigrab)
goto icon_error;
}
-pos.x = ci.ptScreenPos.x - clip_rect.left - info.xHotspot;
-pos.y = ci.ptScreenPos.y - clip_rect.top - info.yHotspot;
-
if (hwnd) {
RECT rect;
if (GetWindowRect(hwnd, &rect)) {
-pos.x -= rect.left;
-pos.y -= rect.top;
+pos.x = ci.ptScreenPos.x - clip_rect.left - info.xHotspot - rect.left;
+pos.y = ci.ptScreenPos.y - clip_rect.top - info.yHotspot - rect.top;
+
+//that would keep the correct location of mouse with hidpi screens
+pos.x = pos.x * desktophorzres / horzres;
+pos.y = pos.y * desktopvertres / vertres;
} else {
CURSOR_ERROR("Couldn't get window rectangle");
goto icon_error;
}
+} else {
+//that would keep the correct location of mouse with hidpi screens
+pos.x = ci.ptScreenPos.x * desktophorzres / horzres - clip_rect.left - info.xHotspot;
+pos.y = ci.ptScreenPos.y * desktopvertres / vertres - clip_rect.top - info.yHotspot;
}
-//that would keep the correct location of mouse with hidpi screens
-pos.x = pos.x * desktophorzres / horzres;
-pos.y = pos.y * desktopvertres / vertres;
-
av_log(s1, AV_LOG_DEBUG, "Cursor pos (%li,%li) -> (%li,%li)\n",
ci.ptScreenPos.x, ci.ptScreenPos.y, pos.x, pos.y);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gdigrab: fix HIDPI support
On 27.01.2019 22:51, Carl Eugen Hoyos wrote:
2019-01-27 1:45 GMT+01:00, Carl Eugen Hoyos :
2019-01-26 18:53 GMT+01:00, Dilshod Mukhtarov :
HI, this is the patch that fixes HIDPI support in gdigrab
+double h_dpr; // Horizontal device pixel ratio
+double v_dpr; // Vertical device pixel ratio
I would expect these to be AVRational, if this is not
possible, it should be explained why.
Sorry if this was not an ideal comment, it should have been:
All aspect ratio calculations (and all calculations related to
aspect ratio) do not need double (or floats) but should be
done as integer calculations. AVRational structs are often
used, theoretically they may not be needed.
I attached new version of the patch, which uses integer arithmetics
--
With the best regards,
Dilshod
>From 1db3c6d3bc8320330cd2908ef50c27e55dcfdf43 Mon Sep 17 00:00:00 2001
From: Dilshod Mukhtarov
Date: Sun, 27 Jan 2019 23:09:53 +0400
Subject: [PATCH 1/2] libavdevice/gdigrab: fix HIDPI support for window capture
In Windows if using scaling other than 100% then the grabbed window was not captured fully (cropped)
Signed-off-by: Dilshod Mukhtarov
---
libavdevice/gdigrab.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index ab08c11788..0e6ae2bd5d 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -277,14 +277,20 @@ gdigrab_read_header(AVFormatContext *s1)
}
bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
+horzres = GetDeviceCaps(source_hdc, HORZRES);
+vertres = GetDeviceCaps(source_hdc, VERTRES);
+desktophorzres = GetDeviceCaps(source_hdc, DESKTOPHORZRES);
+desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
+
if (hwnd) {
GetClientRect(hwnd, &virtual_rect);
+/* window -- get the right height and width for scaling DPI */
+virtual_rect.left = virtual_rect.left * desktophorzres / horzres;
+virtual_rect.right = virtual_rect.right * desktophorzres / horzres;
+virtual_rect.top= virtual_rect.top* desktopvertres / vertres;
+virtual_rect.bottom = virtual_rect.bottom * desktopvertres / vertres;
} else {
/* desktop -- get the right height and width for scaling DPI */
-horzres = GetDeviceCaps(source_hdc, HORZRES);
-vertres = GetDeviceCaps(source_hdc, VERTRES);
-desktophorzres = GetDeviceCaps(source_hdc, DESKTOPHORZRES);
-desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
virtual_rect.right = (virtual_rect.left + GetSystemMetrics(SM_CXVIRTUALSCREEN)) * desktophorzres / horzres;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Sun, Jan 27, 2019 at 7:43 PM Dominik 'Rathann' Mierzejewski wrote: > > If you're trying to say we can upgrade 4.0.x to 4.1.x without > recompiling any dependent packages and you guarantee everything will > work just like with 4.0.x, then I would be willing to entertain that > option, though we try to avoid upgrading base system components in the > middle of a release cycle. > Whats more base system then a driver? :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/async: fix assertion condition when draining buffer
Fixes some random assertion failures with
ffprobe -show_packets
async:samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts >
/dev/null
Signed-off-by: Marton Balint
---
libavformat/async.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index 54dbd2312a..4e295b5e10 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -142,7 +142,7 @@ static int ring_size_of_read_back(RingBuffer *ring)
static int ring_drain(RingBuffer *ring, int offset)
{
av_assert2(offset >= -ring_size_of_read_back(ring));
-av_assert2(offset <= -ring_size(ring));
+av_assert2(offset <= ring_size(ring));
ring->read_pos += offset;
return 0;
}
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gdigrab: fix HIDPI support
2019-01-27 1:45 GMT+01:00, Carl Eugen Hoyos : > 2019-01-26 18:53 GMT+01:00, Dilshod Mukhtarov : >> HI, this is the patch that fixes HIDPI support in gdigrab > >> +double h_dpr; // Horizontal device pixel ratio >> +double v_dpr; // Vertical device pixel ratio > > I would expect these to be AVRational, if this is not > possible, it should be explained why. Sorry if this was not an ideal comment, it should have been: All aspect ratio calculations (and all calculations related to aspect ratio) do not need double (or floats) but should be done as integer calculations. AVRational structs are often used, theoretically they may not be needed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the PPC section
Signed-off-by: Lauri Kasanen --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) Ref http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/239357.html Requesting commit access so I don't have to constantly bug Michael. diff --git a/MAINTAINERS b/MAINTAINERS index bc2ae13..e3a80e9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -526,6 +526,7 @@ Alpha Falk Hueffner MIPSManojkumar Bhosale, Shiyou Yin Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier Amiga / PowerPC Colin Ward +Linux / PowerPC Lauri Kasanen Windows MinGW Alex Beregszaszi, Ramiro Polla Windows Cygwin Victor Paesa Windows MSVCMatthew Oliver, Hendrik Leppkes -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] gdigrab: fix HIDPI support for mouse positioning
--
With the best regards,
Dilshod
>From 0d8ee5aca28655baf0e6954063ad61a422443d38 Mon Sep 17 00:00:00 2001
From: Dilshod Mukhtarov
Date: Sun, 27 Jan 2019 22:30:01 +0400
Subject: [PATCH 2/2] libavdevice/gdigrab: fix HIDPI support for mouse
positioning
Mouse position was not calculated properly in area or window mode
Signed-off-by: Dilshod Mukhtarov
---
libavdevice/gdigrab.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index f2c3077523..22c7477d36 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -452,10 +452,10 @@ static void paint_mouse_pointer(AVFormatContext *s1, struct gdigrab *gdigrab)
POINT pos;
RECT clip_rect = gdigrab->clip_rect;
HWND hwnd = gdigrab->hwnd;
-int horzres = GetDeviceCaps(gdigrab->source_hdc, HORZRES);
-int vertres = GetDeviceCaps(gdigrab->source_hdc, VERTRES);
-int desktophorzres = GetDeviceCaps(gdigrab->source_hdc, DESKTOPHORZRES);
-int desktopvertres = GetDeviceCaps(gdigrab->source_hdc, DESKTOPVERTRES);
+AVRational h_dpr = { GetDeviceCaps(gdigrab->source_hdc, DESKTOPHORZRES),
+ GetDeviceCaps(gdigrab->source_hdc, HORZRES) }; // Horizontal device pixel ratio
+AVRational v_dpr = { GetDeviceCaps(gdigrab->source_hdc, DESKTOPVERTRES),
+ GetDeviceCaps(gdigrab->source_hdc, VERTRES) }; // Vertical device pixel ratio
info.hbmMask = NULL;
info.hbmColor = NULL;
@@ -474,25 +474,26 @@ static void paint_mouse_pointer(AVFormatContext *s1, struct gdigrab *gdigrab)
goto icon_error;
}
-pos.x = ci.ptScreenPos.x - clip_rect.left - info.xHotspot;
-pos.y = ci.ptScreenPos.y - clip_rect.top - info.yHotspot;
-
if (hwnd) {
RECT rect;
if (GetWindowRect(hwnd, &rect)) {
-pos.x -= rect.left;
-pos.y -= rect.top;
+pos.x = ci.ptScreenPos.x - clip_rect.left - info.xHotspot - rect.left;
+pos.y = ci.ptScreenPos.y - clip_rect.top - info.yHotspot - rect.top;
+
+//that would keep the correct location of mouse with hidpi screens
+pos.x *= av_q2d(h_dpr);
+pos.y *= av_q2d(v_dpr);
} else {
CURSOR_ERROR("Couldn't get window rectangle");
goto icon_error;
}
+} else {
+//that would keep the correct location of mouse with hidpi screens
+pos.x = ci.ptScreenPos.x * av_q2d(h_dpr) - clip_rect.left - info.xHotspot;
+pos.y = ci.ptScreenPos.y * av_q2d(v_dpr) - clip_rect.top - info.yHotspot;
}
-//that would keep the correct location of mouse with hidpi screens
-pos.x = pos.x * desktophorzres / horzres;
-pos.y = pos.y * desktopvertres / vertres;
-
av_log(s1, AV_LOG_DEBUG, "Cursor pos (%li,%li) -> (%li,%li)\n",
ci.ptScreenPos.x, ci.ptScreenPos.y, pos.x, pos.y);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
2019-01-27 19:43 GMT+01:00, Dominik 'Rathann' Mierzejewski : > On Sunday, 27 January 2019 at 19:29, Carl Eugen Hoyos wrote: >> 2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski >> : >> > Hello, >> > >> > On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: >> >> ffmpeg | branch: master | ManojGuptaBonda | Mon Oct >> >> 29 >> >> 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | >> >> committer: Philip Langdale >> >> >> >> avcodec/vdpau: Enable HEVC support for working Nvidia driver versions >> >> >> >> The driver bugs that caused decoded HEVC content to have an incorrect >> >> memory layout have been fully fixed in the 410.xx driver release so >> >> we can start exposing support. >> >> >> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f >> > >> > I have a user requesting a backport of this and >> > 4a976200d7853588336005a394dd31d905f5caf6 >> > to 4.0 branch which we use in Fedora/RPM Fusion 29: >> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 >> >> Wouldn't a user who uses an outdated version of FFmpeg >> typically also use an outdated Nvidia driver? > > No. Why would you say that? First, 4.0.x is not outdated from > where I'm sitting and second, we've updated the packaged > nVidia drivers in RPM Fusion for F29 to 415 already. Thank you for explaining, I misunderstood. Why are you updating Nvidia drivers but not FFmpeg? Do you expect that (current) 4.0 has less bugs than the last 4.1 release? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gdigrab: fix HIDPI support
2019-01-27 19:40 GMT+01:00, Dilshod Mukhtarov : > Thanks for advices. I split the patch to two distinct parts. The > first part is here and the next one in a new message. I am quite sure that this has to be implemented without av_q2d(). Please avoid top-posting here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Sunday, 27 January 2019 at 19:29, Carl Eugen Hoyos wrote: > 2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski > : > > Hello, > > > > On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: > >> ffmpeg | branch: master | ManojGuptaBonda | Mon Oct 29 > >> 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | > >> committer: Philip Langdale > >> > >> avcodec/vdpau: Enable HEVC support for working Nvidia driver versions > >> > >> The driver bugs that caused decoded HEVC content to have an incorrect > >> memory layout have been fully fixed in the 410.xx driver release so > >> we can start exposing support. > >> > >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f > > > > I have a user requesting a backport of this and > > 4a976200d7853588336005a394dd31d905f5caf6 > > to 4.0 branch which we use in Fedora/RPM Fusion 29: > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 > > Wouldn't a user who uses an outdated version of FFmpeg > typically also use an outdated Nvidia driver? No. Why would you say that? First, 4.0.x is not outdated from where I'm sitting and second, we've updated the packaged nVidia drivers in RPM Fusion for F29 to 415 already. If you're trying to say we can upgrade 4.0.x to 4.1.x without recompiling any dependent packages and you guarantee everything will work just like with 4.0.x, then I would be willing to entertain that option, though we try to avoid upgrading base system components in the middle of a release cycle. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gdigrab: fix HIDPI support
Hi Carl,
Thanks for advices. I split the patch to two distinct parts. The first
part is here and the next one in a new message.
On 27.01.2019 4:45, Carl Eugen Hoyos wrote:
2019-01-26 18:53 GMT+01:00, Dilshod Mukhtarov :
HI, this is the patch that fixes HIDPI support in gdigrab
+double h_dpr; // Horizontal device pixel ratio
+double v_dpr; // Vertical device pixel ratio
I would expect these to be AVRational, if this is not
possible, it should be explained why.
Please put "else" on the same line as "}", no linebreak
between "}" and "else".
1) Mouse position was not calculated properly in area or window mode
2) In window mode the size of window was not calculated properly (cropped)
This may not apply here, but typically, if a patch says "fixes A and B",
it should be split in two patches to ease review and future debugging.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
With the best regards,
Dilshod
>From 618c77964c6d15f5482d7298c0639b3c3452203b Mon Sep 17 00:00:00 2001
From: Dilshod Mukhtarov
Date: Sun, 27 Jan 2019 22:27:35 +0400
Subject: [PATCH 1/2] libavdevice/gdigrab: fix HIDPI support for window capture
In Windows if using scaling other than 100% then the grabbed window was not captured fully (cropped)
Signed-off-by: Dilshod Mukhtarov
---
libavdevice/gdigrab.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index ab08c11788..f2c3077523 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -235,14 +235,12 @@ gdigrab_read_header(AVFormatContext *s1)
AVStream *st = NULL;
int bpp;
-int horzres;
-int vertres;
-int desktophorzres;
-int desktopvertres;
RECT virtual_rect;
RECT clip_rect;
BITMAP bmp;
int ret;
+AVRational h_dpr; // Horizontal device pixel ratio
+AVRational v_dpr; // Vertical device pixel ratio
if (!strncmp(filename, "title=", 6)) {
name = filename + 6;
@@ -277,18 +275,21 @@ gdigrab_read_header(AVFormatContext *s1)
}
bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
+h_dpr = av_make_q(GetDeviceCaps(source_hdc, DESKTOPHORZRES), GetDeviceCaps(source_hdc, HORZRES));
+v_dpr = av_make_q(GetDeviceCaps(source_hdc, DESKTOPVERTRES), GetDeviceCaps(source_hdc, VERTRES));
+
if (hwnd) {
GetClientRect(hwnd, &virtual_rect);
+virtual_rect.left *= av_q2d(h_dpr);
+virtual_rect.right *= av_q2d(h_dpr);
+virtual_rect.top*= av_q2d(v_dpr);
+virtual_rect.bottom *= av_q2d(v_dpr);
} else {
/* desktop -- get the right height and width for scaling DPI */
-horzres = GetDeviceCaps(source_hdc, HORZRES);
-vertres = GetDeviceCaps(source_hdc, VERTRES);
-desktophorzres = GetDeviceCaps(source_hdc, DESKTOPHORZRES);
-desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
-virtual_rect.right = (virtual_rect.left + GetSystemMetrics(SM_CXVIRTUALSCREEN)) * desktophorzres / horzres;
-virtual_rect.bottom = (virtual_rect.top + GetSystemMetrics(SM_CYVIRTUALSCREEN)) * desktopvertres / vertres;
+virtual_rect.right = (virtual_rect.left + GetSystemMetrics(SM_CXVIRTUALSCREEN)) * av_q2d(h_dpr);
+virtual_rect.bottom = (virtual_rect.top + GetSystemMetrics(SM_CYVIRTUALSCREEN)) * av_q2d(v_dpr);
}
/* If no width or height set, use full screen/window area */
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski : > Hello, > > On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: >> ffmpeg | branch: master | ManojGuptaBonda | Mon Oct 29 >> 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | >> committer: Philip Langdale >> >> avcodec/vdpau: Enable HEVC support for working Nvidia driver versions >> >> The driver bugs that caused decoded HEVC content to have an incorrect >> memory layout have been fully fixed in the 410.xx driver release so >> we can start exposing support. >> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f > > I have a user requesting a backport of this and > 4a976200d7853588336005a394dd31d905f5caf6 > to 4.0 branch which we use in Fedora/RPM Fusion 29: > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 Wouldn't a user who uses an outdated version of FFmpeg typically also use an outdated Nvidia driver? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
Hello, On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: > ffmpeg | branch: master | ManojGuptaBonda | Mon Oct 29 > 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | committer: > Philip Langdale > > avcodec/vdpau: Enable HEVC support for working Nvidia driver versions > > The driver bugs that caused decoded HEVC content to have an incorrect > memory layout have been fully fixed in the 410.xx driver release so > we can start exposing support. > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f I have a user requesting a backport of this and 4a976200d7853588336005a394dd31d905f5caf6 to 4.0 branch which we use in Fedora/RPM Fusion 29: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 Would it be possible? Regards, Dominik (FFmpeg Fedora package maintainer in RPM Fusion) -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
2019-01-27 17:38 GMT+01:00, Muhammad Faiz :
> On Sun, Jan 27, 2019 at 11:02 PM Carl Eugen Hoyos
> wrote:
>>
>> 2019-01-27 16:18 GMT+01:00, Muhammad Faiz :
>> > On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
>> >>
>> >> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>> >> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
>> >> > +{
>> >> > +int len = strlen(desc->name);
>> >> > +
>> >> > +if (!strcmp(desc->name + len - 2, "be"))
>> >> > +return HAVE_BIGENDIAN;
>> >> > +if (!strcmp(desc->name + len - 2, "le"))
>> >> > +return !HAVE_BIGENDIAN;
>> >> > +return 1;
>> >> > +}
>> >> > +
>> >>
>> >> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE
>> >> instead of string compare?
>> >
>> > I don't really understand your code.
>>
>> Something like "return shift + depth <=8 ||
>> desc->flags | FMT_FLAG_BE ^ !HAVE_BIGENDIAN"
>
> OK, I will try.
Please use Marton's suggestion, the "|" will not be the only
thing completely wrong.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
On Sun, Jan 27, 2019 at 11:21 PM Marton Balint wrote:
>
>
>
> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>
> > On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
> >>
> >>
> >>
> >> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
> >>
> >> > Signed-off-by: Muhammad Faiz
> >> > ---
> >> > Old thread is here:
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> >> > Need someone test it on big-endian machine.
> >> >
> >> > libavfilter/drawutils.c | 48 +
> >> > libavfilter/vf_rotate.c | 26 ++--
> >> > libavfilter/vf_tinterlace.c | 30 +++
> >> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >> >
> >> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> >> > index 5f4cb548f0..12bdfcb900 100644
> >> > --- a/libavfilter/drawutils.c
> >> > +++ b/libavfilter/drawutils.c
> >> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
> >> > dst_linesize[4],
> >> > }
> >> > }
> >> >
> >> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> >> > +{
> >> > +int len = strlen(desc->name);
> >> > +
> >> > +if (!strcmp(desc->name + len - 2, "be"))
> >> > +return HAVE_BIGENDIAN;
> >> > +if (!strcmp(desc->name + len - 2, "le"))
> >> > +return !HAVE_BIGENDIAN;
> >> > +return 1;
> >> > +}
> >> > +
> >>
> >> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
> >> compare?
> >
> > I don't really understand your code. Currently I can't test on
> > big-endian platform. Adding something that I don't understand and
> > can't test is not a good idea.
>
> Using strcmp to determine format endianness is ugly. Use other means, like
> checking component bit depth, or component step:
>
> static int is_native_endian(const AVPixFmtDescriptor *desc)
> {
> return desc->comp[0].step <= 1 ||
> (HAVE_BIGENDIAN == !!(desc->comp[0].flags & AV_PIX_FMT_FLAG_BE));
> }
>
comp[0] doesn't have flags.
Anyway, I will try.
Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
2019-01-27 17:27 GMT+01:00, Muhammad Faiz : > Can you give me an example how the output should be? I have no suggestion, I simply wanted to point out that with your change it would be very difficult to understand how future differences are caused. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
On Sun, Jan 27, 2019 at 11:02 PM Carl Eugen Hoyos wrote:
>
> 2019-01-27 16:18 GMT+01:00, Muhammad Faiz :
> > On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
> >>
> >>
> >>
> >> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
> >>
> >> > Signed-off-by: Muhammad Faiz
> >> > ---
> >> > Old thread is here:
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> >> > Need someone test it on big-endian machine.
> >> >
> >> > libavfilter/drawutils.c | 48 +
> >> > libavfilter/vf_rotate.c | 26 ++--
> >> > libavfilter/vf_tinterlace.c | 30 +++
> >> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >> >
> >> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> >> > index 5f4cb548f0..12bdfcb900 100644
> >> > --- a/libavfilter/drawutils.c
> >> > +++ b/libavfilter/drawutils.c
> >> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
> >> > dst_linesize[4],
> >> > }
> >> > }
> >> >
> >> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> >> > +{
> >> > +int len = strlen(desc->name);
> >> > +
> >> > +if (!strcmp(desc->name + len - 2, "be"))
> >> > +return HAVE_BIGENDIAN;
> >> > +if (!strcmp(desc->name + len - 2, "le"))
> >> > +return !HAVE_BIGENDIAN;
> >> > +return 1;
> >> > +}
> >> > +
> >>
> >> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE
> >> instead of string compare?
> >
> > I don't really understand your code.
>
> Something like "return shift + depth <=8 ||
> desc->flags | FMT_FLAG_BE ^ !HAVE_BIGENDIAN"
OK, I will try.
>
> And since the new function is only used once, it may
> be more readable not to add a new function.
OK.
>
> > Currently I can't test on big-endian platform. Adding
> > something that I don't understand and
> > can't test is not a good idea.
>
> But your patchset does change big-endian code and only
> improves big-endian, no?
Yes. I write it blindly. I really depends on Michael's report on
big-endian platform.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 10:54 PM Carl Eugen Hoyos wrote: > > 2019-01-27 16:07 GMT+01:00, Muhammad Faiz : > > On Sun, Jan 27, 2019 at 9:15 PM Carl Eugen Hoyos wrote: > >> > >> 2019-01-27 15:05 GMT+01:00, Muhammad Faiz : > >> > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos > >> > wrote: > >> >> > >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > >> >> > >> >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 > >> >> > +bgra64leb71d75a928aac14cb768403e6f6a9910 > >> >> > bgra64leb71d75a928aac14cb768403e6f6a9910 > >> >> > >> >> I believe the output should be changed to make it less > >> >> confusing. > >> > > >> > Any attempt to differentiate these two lines makes [4/5] > >> > and [5/5] don't work. > >> > >> I wonder if this just indicates that your approach is wrong, > >> and that the tests for the filters in question have to be > >> (completely) different. > > > > How can this approach be wrong if it revealed bug? > > As I tried to explain I am happy that you found this issue, > but I believe an approach should be searched that produces > a little more useful output. Can you give me an example how the output should be? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
wrote:
>
> On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > regardless of the actual supported formats.
> > This allows filters to support only native-endian formats,
> > and also allows consistency checks between little-endian
> > and big-endian implementation.
> >
> > This also reveals bugs on gbrap10, p010, p016 format, and
> > super2xsai filter (mismatched checksums between little-endian
> > and big-endian).
> >
> > Suggested-by: Hendrik Leppkes
> > Signed-off-by: Muhammad Faiz
> > ---
> > Old thread is here:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> >
> > tests/fate-run.sh| 6 +-
> > tests/ref/fate/filter-pixfmts-copy | 112 +++
> > tests/ref/fate/filter-pixfmts-crop | 112 +++
> > tests/ref/fate/filter-pixfmts-field | 112 +++
> > tests/ref/fate/filter-pixfmts-fieldorder | 88 +-
> > tests/ref/fate/filter-pixfmts-hflip | 112 +++
> > tests/ref/fate/filter-pixfmts-il | 112 +++
> > tests/ref/fate/filter-pixfmts-null | 112 +++
> > tests/ref/fate/filter-pixfmts-scale | 112 +++
> > tests/ref/fate/filter-pixfmts-super2xsai | 8 +-
> > tests/ref/fate/filter-pixfmts-swapuv | 56 ++--
> > tests/ref/fate/filter-pixfmts-transpose | 90 +-
> > tests/ref/fate/filter-pixfmts-vflip | 112 +++
> > 13 files changed, 573 insertions(+), 571 deletions(-)
> >
> > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > index aece90a01d..faa4285e71 100755
> > --- a/tests/fate-run.sh
> > +++ b/tests/fate-run.sh
> > @@ -297,8 +297,10 @@ pixfmts(){
> >
> > outertest=$test
> > for pix_fmt in $pix_fmts; do
> > -test=$pix_fmt
> > -video_filter
> > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt
> > -frames:v $nframes
> > +# force little endian format on result
> > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > +test=$pix_fmt_le
> > +video_filter
> > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt
> > $pix_fmt_le -frames:v $nframes
> > done
>
> if the input to a filter is a big endian format and the output is little
> endian. Then there really isnt a gurantee that the filter will work with
> big endian data. The libavfilter core could convert before or after the filter
> as it preferrs. At least thats how i remember it from the last time i looked
> at the code.
> This also makes sense, as there are very good reasons to convert before,
> for example when doing so results in better quality or higher speed
> or fewer converts overall in multi input or multi output filters...
Of course, this can be easily fixed by adding format=$pix_fmt after
$filter=$filter_args.
>
> So if the output is always forced to LE then this may unintentionally
> remove testing a range of cases.
> also this removes testing the codepath for big endian formats after the
> convert. Or do we have remaining cases that test these ?
Do you suggest to duplicate test to output BE and LE simultaneously?
>
> I am in favor of adding more and better tests but please make sure
> no codepathes drop out of all tests. (and not just by chance of the
> format negotiation randomly picking the intended choice, which it
> very well might)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
On Sun, 27 Jan 2019, Muhammad Faiz wrote:
On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
On Sun, 27 Jan 2019, Muhammad Faiz wrote:
> Signed-off-by: Muhammad Faiz
> ---
> Old thread is here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> Need someone test it on big-endian machine.
>
> libavfilter/drawutils.c | 48 +
> libavfilter/vf_rotate.c | 26 ++--
> libavfilter/vf_tinterlace.c | 30 +++
> 3 files changed, 54 insertions(+), 50 deletions(-)
>
> diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> index 5f4cb548f0..12bdfcb900 100644
> --- a/libavfilter/drawutils.c
> +++ b/libavfilter/drawutils.c
> @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
dst_linesize[4],
> }
> }
>
> +static int is_native_endian(const AVPixFmtDescriptor *desc)
> +{
> +int len = strlen(desc->name);
> +
> +if (!strcmp(desc->name + len - 2, "be"))
> +return HAVE_BIGENDIAN;
> +if (!strcmp(desc->name + len - 2, "le"))
> +return !HAVE_BIGENDIAN;
> +return 1;
> +}
> +
Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
compare?
I don't really understand your code. Currently I can't test on
big-endian platform. Adding something that I don't understand and
can't test is not a good idea.
Using strcmp to determine format endianness is ugly. Use other means, like
checking component bit depth, or component step:
static int is_native_endian(const AVPixFmtDescriptor *desc)
{
return desc->comp[0].step <= 1 ||
(HAVE_BIGENDIAN == !!(desc->comp[0].flags & AV_PIX_FMT_FLAG_BE));
}
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
2019-01-27 16:18 GMT+01:00, Muhammad Faiz :
> On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
>>
>>
>>
>> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>>
>> > Signed-off-by: Muhammad Faiz
>> > ---
>> > Old thread is here:
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
>> > Need someone test it on big-endian machine.
>> >
>> > libavfilter/drawutils.c | 48 +
>> > libavfilter/vf_rotate.c | 26 ++--
>> > libavfilter/vf_tinterlace.c | 30 +++
>> > 3 files changed, 54 insertions(+), 50 deletions(-)
>> >
>> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
>> > index 5f4cb548f0..12bdfcb900 100644
>> > --- a/libavfilter/drawutils.c
>> > +++ b/libavfilter/drawutils.c
>> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
>> > dst_linesize[4],
>> > }
>> > }
>> >
>> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
>> > +{
>> > +int len = strlen(desc->name);
>> > +
>> > +if (!strcmp(desc->name + len - 2, "be"))
>> > +return HAVE_BIGENDIAN;
>> > +if (!strcmp(desc->name + len - 2, "le"))
>> > +return !HAVE_BIGENDIAN;
>> > +return 1;
>> > +}
>> > +
>>
>> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE
>> instead of string compare?
>
> I don't really understand your code.
Something like "return shift + depth <=8 ||
desc->flags | FMT_FLAG_BE ^ !HAVE_BIGENDIAN"
And since the new function is only used once, it may
be more readable not to add a new function.
> Currently I can't test on big-endian platform. Adding
> something that I don't understand and
> can't test is not a good idea.
But your patchset does change big-endian code and only
improves big-endian, no?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
2019-01-27 16:12 GMT+01:00, Muhammad Faiz : > On Sun, Jan 27, 2019 at 9:17 PM Carl Eugen Hoyos wrote: >> >> 2019-01-27 15:07 GMT+01:00, Muhammad Faiz : >> > On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos >> > wrote: >> >> >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : >> >> > Fix mismatched checksum on fate-filter-pixfmts-super2xsai. >> >> >> >> I believe this patch and 2/5 are unrelated and should be >> >> committed independently of the patchset. >> > >> > No. [2/5] and [3/5] depend on [1/5]. >> >> No (at least afaiu). >> The fate tests for these changes depend on the first patch. >> But if the tests are currently broken, they cannot be used >> as reasoning for anything. >> Instead, the code should be fixed and the tests disabled. >> (imo) > > Don't forget that 2/5 and 3/5 bugs (and p010/p016 bugs) are > revealed by 1/5. I know, I understood this. > It means that 1/5 is important. I neither said that it is important nor that it is unimportant. I seems to me that this bug fix (for a bug that was thankfully found by a patch written by you) is not related to the fate system. If fixing this bug means that fate breaks, it indicates that fate is wrong and that maybe the fate test should be disabled / replaced. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
2019-01-27 16:07 GMT+01:00, Muhammad Faiz : > On Sun, Jan 27, 2019 at 9:15 PM Carl Eugen Hoyos wrote: >> >> 2019-01-27 15:05 GMT+01:00, Muhammad Faiz : >> > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos >> > wrote: >> >> >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : >> >> >> >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 >> >> > +bgra64leb71d75a928aac14cb768403e6f6a9910 >> >> > bgra64leb71d75a928aac14cb768403e6f6a9910 >> >> >> >> I believe the output should be changed to make it less >> >> confusing. >> > >> > Any attempt to differentiate these two lines makes [4/5] >> > and [5/5] don't work. >> >> I wonder if this just indicates that your approach is wrong, >> and that the tests for the filters in question have to be >> (completely) different. > > How can this approach be wrong if it revealed bug? As I tried to explain I am happy that you found this issue, but I believe an approach should be searched that produces a little more useful output. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> regardless of the actual supported formats.
> This allows filters to support only native-endian formats,
> and also allows consistency checks between little-endian
> and big-endian implementation.
>
> This also reveals bugs on gbrap10, p010, p016 format, and
> super2xsai filter (mismatched checksums between little-endian
> and big-endian).
>
> Suggested-by: Hendrik Leppkes
> Signed-off-by: Muhammad Faiz
> ---
> Old thread is here:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
>
> tests/fate-run.sh| 6 +-
> tests/ref/fate/filter-pixfmts-copy | 112 +++
> tests/ref/fate/filter-pixfmts-crop | 112 +++
> tests/ref/fate/filter-pixfmts-field | 112 +++
> tests/ref/fate/filter-pixfmts-fieldorder | 88 +-
> tests/ref/fate/filter-pixfmts-hflip | 112 +++
> tests/ref/fate/filter-pixfmts-il | 112 +++
> tests/ref/fate/filter-pixfmts-null | 112 +++
> tests/ref/fate/filter-pixfmts-scale | 112 +++
> tests/ref/fate/filter-pixfmts-super2xsai | 8 +-
> tests/ref/fate/filter-pixfmts-swapuv | 56 ++--
> tests/ref/fate/filter-pixfmts-transpose | 90 +-
> tests/ref/fate/filter-pixfmts-vflip | 112 +++
> 13 files changed, 573 insertions(+), 571 deletions(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index aece90a01d..faa4285e71 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -297,8 +297,10 @@ pixfmts(){
>
> outertest=$test
> for pix_fmt in $pix_fmts; do
> -test=$pix_fmt
> -video_filter
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt
> -frames:v $nframes
> +# force little endian format on result
> +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> +test=$pix_fmt_le
> +video_filter
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt_le
> -frames:v $nframes
> done
if the input to a filter is a big endian format and the output is little
endian. Then there really isnt a gurantee that the filter will work with
big endian data. The libavfilter core could convert before or after the filter
as it preferrs. At least thats how i remember it from the last time i looked
at the code.
This also makes sense, as there are very good reasons to convert before,
for example when doing so results in better quality or higher speed
or fewer converts overall in multi input or multi output filters...
So if the output is always forced to LE then this may unintentionally
remove testing a range of cases.
also this removes testing the codepath for big endian formats after the
convert. Or do we have remaining cases that test these ?
I am in favor of adding more and better tests but please make sure
no codepathes drop out of all tests. (and not just by chance of the
format negotiation randomly picking the intended choice, which it
very well might)
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
On Sun, Jan 27, 2019 at 5:25 PM Marton Balint wrote:
>
>
>
> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>
> > Signed-off-by: Muhammad Faiz
> > ---
> > Old thread is here:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> > Need someone test it on big-endian machine.
> >
> > libavfilter/drawutils.c | 48 +
> > libavfilter/vf_rotate.c | 26 ++--
> > libavfilter/vf_tinterlace.c | 30 +++
> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >
> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> > index 5f4cb548f0..12bdfcb900 100644
> > --- a/libavfilter/drawutils.c
> > +++ b/libavfilter/drawutils.c
> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
> > dst_linesize[4],
> > }
> > }
> >
> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> > +{
> > +int len = strlen(desc->name);
> > +
> > +if (!strcmp(desc->name + len - 2, "be"))
> > +return HAVE_BIGENDIAN;
> > +if (!strcmp(desc->name + len - 2, "le"))
> > +return !HAVE_BIGENDIAN;
> > +return 1;
> > +}
> > +
>
> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
> compare?
I don't really understand your code. Currently I can't test on
big-endian platform. Adding something that I don't understand and
can't test is not a good idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
On Sun, Jan 27, 2019 at 9:17 PM Carl Eugen Hoyos wrote: > > 2019-01-27 15:07 GMT+01:00, Muhammad Faiz : > > On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos wrote: > >> > >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > >> > Fix mismatched checksum on fate-filter-pixfmts-super2xsai. > >> > >> I believe this patch and 2/5 are unrelated and should be > >> committed independently of the patchset. > > > > No. [2/5] and [3/5] depend on [1/5]. > > No (at least afaiu). > The fate tests for these changes depend on the first patch. > But if the tests are currently broken, they cannot be used > as reasoning for anything. > Instead, the code should be fixed and the tests disabled. > (imo) Don't forget that 2/5 and 3/5 bugs (and p010/p016 bugs) are revealed by 1/5. It means that 1/5 is important. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 9:15 PM Carl Eugen Hoyos wrote: > > 2019-01-27 15:05 GMT+01:00, Muhammad Faiz : > > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos wrote: > >> > >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > >> > >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 > >> > +bgra64leb71d75a928aac14cb768403e6f6a9910 > >> > bgra64leb71d75a928aac14cb768403e6f6a9910 > >> > >> I believe the output should be changed to make it less > >> confusing. > > > > Any attempt to differentiate these two lines makes [4/5] > > and [5/5] don't work. > > I wonder if this just indicates that your approach is wrong, > and that the tests for the filters in question have to be > (completely) different. How can this approach be wrong if it revealed bug? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/arbc: Use AV_WB24() where applicable
Hi!
Minimal simplification attached.
Please comment, Carl Eugen
From e767b19ed1f87758ab777b70b6bb08ad44a6cf33 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 27 Jan 2019 15:10:04 +0100
Subject: [PATCH] lavc/arbc: Use AV_WB24() where applicable.
---
libavcodec/arbc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
index 01a146f..d2d109e 100644
--- a/libavcodec/arbc.c
+++ b/libavcodec/arbc.c
@@ -38,7 +38,7 @@ typedef struct ARBCContext {
AVFrame *prev_frame;
} ARBCContext;
-static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
+static void fill_tile4(AVCodecContext *avctx, int color, AVFrame *frame)
{
ARBCContext *s = avctx->priv_data;
GetByteContext *gb = &s->gb;
@@ -59,9 +59,7 @@ static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
mask = mask << 1;
continue;
}
-frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 0] = color[0];
-frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 1] = color[1];
-frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 2] = color[2];
+AV_WB24(&frame->data[0][frame->linesize[0] * (h - j) + 3 * k], color);
}
mask = mask << 1;
}
@@ -70,7 +68,7 @@ static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
}
static void fill_tileX(AVCodecContext *avctx, int tile_width, int tile_height,
- uint8_t *color, AVFrame *frame)
+ int color, AVFrame *frame)
{
ARBCContext *s = avctx->priv_data;
GetByteContext *gb = &s->gb;
@@ -93,9 +91,7 @@ static void fill_tileX(AVCodecContext *avctx, int tile_width, int tile_height,
for (int n = 0; n < step_w; n++) {
if (j + m >= avctx->height || k + n >= avctx->width)
continue;
-frame->data[0][frame->linesize[0] * (h - (j + m)) + 3 * (k + n) + 0] = color[0];
-frame->data[0][frame->linesize[0] * (h - (j + m)) + 3 * (k + n) + 1] = color[1];
-frame->data[0][frame->linesize[0] * (h - (j + m)) + 3 * (k + n) + 2] = color[2];
+AV_WB24(&frame->data[0][frame->linesize[0] * (h - (j + m)) + 3 * (k + n)], color);
}
}
}
@@ -132,16 +128,16 @@ static int decode_frame(AVCodecContext *avctx, void *data,
for (int i = 0; i < nb_segments; i++) {
int resolution_flag;
-uint8_t fill[3];
+int fill;
if (bytestream2_get_bytes_left(&s->gb) <= 0)
return AVERROR_INVALIDDATA;
-fill[0] = bytestream2_get_byte(&s->gb);
+fill = bytestream2_get_byte(&s->gb) << 16;
bytestream2_skip(&s->gb, 1);
-fill[1] = bytestream2_get_byte(&s->gb);
+fill |= bytestream2_get_byte(&s->gb) << 8;
bytestream2_skip(&s->gb, 1);
-fill[2] = bytestream2_get_byte(&s->gb);
+fill |= bytestream2_get_byte(&s->gb) << 0;
bytestream2_skip(&s->gb, 1);
resolution_flag = bytestream2_get_byte(&s->gb);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
2019-01-27 15:07 GMT+01:00, Muhammad Faiz : > On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos wrote: >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : >> > Fix mismatched checksum on fate-filter-pixfmts-super2xsai. >> >> I believe this patch and 2/5 are unrelated and should be >> committed independently of the patchset. > > No. [2/5] and [3/5] depend on [1/5]. No (at least afaiu). The fate tests for these changes depend on the first patch. But if the tests are currently broken, they cannot be used as reasoning for anything. Instead, the code should be fixed and the tests disabled. (imo) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
2019-01-27 15:05 GMT+01:00, Muhammad Faiz : > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos wrote: >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : >> >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 >> > +bgra64leb71d75a928aac14cb768403e6f6a9910 >> > bgra64leb71d75a928aac14cb768403e6f6a9910 >> >> I believe the output should be changed to make it less >> confusing. > > Any attempt to differentiate these two lines makes [4/5] > and [5/5] don't work. I wonder if this just indicates that your approach is wrong, and that the tests for the filters in question have to be (completely) different. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec: add ARBC decoder
On 1/27/2019 10:06 AM, Paul B Mahol wrote: > On 1/27/19, Carl Eugen Hoyos wrote: >> 2019-01-27 13:55 GMT+01:00, Paul B Mahol : >> >>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >>> 0] = color[0]; >>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >>> 1] = color[1]; >>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >>> 2] = color[2]; >> >> Isn't this AV_Wx24()? >> >> Carl Eugen >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > I do not do micro optimizations. Don't be ridiculous. intreadwrite macros not only make sure the most optimized way to read and write bytes is used, but also make the code much more readable. And you know it, because you've have used them plenty of times. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos wrote: > > 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > > > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 > > +bgra64leb71d75a928aac14cb768403e6f6a9910 > > bgra64leb71d75a928aac14cb768403e6f6a9910 > > I believe the output should be changed to make it less > confusing. Any attempt to differentiate these two lines makes [4/5] and [5/5] don't work. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos wrote: > > 2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > > Fix mismatched checksum on fate-filter-pixfmts-super2xsai. > > I believe this patch and 2/5 are unrelated and should be > committed independently of the patchset. No. [2/5] and [3/5] depend on [1/5]. [4/5] and [5/5] depend on [1/5] and [2/5]. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail for unknown atoms with negative size.
2019-01-26 15:38 GMT+01:00, Paul B Mahol : > On 1/26/19, Carl Eugen Hoyos wrote: >> 2019-01-25 17:49 GMT+01:00, Paul B Mahol : >>> On 1/23/19, Carl Eugen Hoyos wrote: Hi! Attached patch allows to read a user's file that plays fine with QT. The patch duplicates the behaviour of QT. Please comment, Carl Eugen >>> >>> lgtm >> >> Sorry, I had attached the wrong patch. >> >> New patch attached, Carl Eugen >> > > lgtm Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: print relevant info when skipping filter reinit
On 27-01-2019 09:57 AM, Gyan wrote: On 26-01-2019 08:23 PM, Carl Eugen Hoyos wrote: 2019-01-26 15:42 GMT+01:00, Gyan : On 26-01-2019 07:49 PM, Carl Eugen Hoyos wrote: 2019-01-26 15:10 GMT+01:00, Gyan : Try feeding a few images of different sizes to the crop filter with reinit disabled Sorry, not sure if I understand: The warning you want to add is only shown if the filter reinit was disabled by the user? Yes, reinit filter is enabled by default so if frame props change, ffmpeg reconfigures the graph. If successful, no warning is shown. Thank you for the explanation, no more comments from me. Thanks. Plan to push tonight. Pushed as b5b6f6ad59ef9bd7af7c5ff3cf94ca3d6abd29ae Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec: add ARBC decoder
On 1/27/19, Carl Eugen Hoyos wrote: > 2019-01-27 13:55 GMT+01:00, Paul B Mahol : > >> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >> 0] = color[0]; >> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >> 1] = color[1]; >> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + >> 2] = color[2]; > > Isn't this AV_Wx24()? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I do not do micro optimizations. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec: add ARBC decoder
2019-01-27 13:55 GMT+01:00, Paul B Mahol : > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + > 0] = color[0]; > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + > 1] = color[1]; > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + > 2] = color[2]; Isn't this AV_Wx24()? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2enc: support additional v4l2 output formats
2019-01-27 7:52 GMT+01:00, James Hilliard : > The purpose of this patch is to fix a bug where ffmpeg would only > output rawvideo to a v4l2loopback device even though v4l2loopback > accepts other formats such as mjpeg. I believe this (or a short variant) should be part of the commit message. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection
2019-01-27 9:32 GMT+01:00, Lauri Kasanen : > Given the low interest in power patches, should I be applying for > commit rights? Definitely! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > Fix mismatched checksum on fate-filter-pixfmts-super2xsai. I believe this patch and 2/5 are unrelated and should be committed independently of the patchset. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts
2019-01-27 10:36 GMT+01:00, Muhammad Faiz : > -bgra64bec8d3217bf58d34f080ac88c0b0012c77 > +bgra64leb71d75a928aac14cb768403e6f6a9910 > bgra64leb71d75a928aac14cb768403e6f6a9910 I believe the output should be changed to make it less confusing. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
On Sun, 27 Jan 2019, Muhammad Faiz wrote:
Signed-off-by: Muhammad Faiz
---
Old thread is here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
Need someone test it on big-endian machine.
libavfilter/drawutils.c | 48 +
libavfilter/vf_rotate.c | 26 ++--
libavfilter/vf_tinterlace.c | 30 +++
3 files changed, 54 insertions(+), 50 deletions(-)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 5f4cb548f0..12bdfcb900 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
dst_linesize[4],
}
}
+static int is_native_endian(const AVPixFmtDescriptor *desc)
+{
+int len = strlen(desc->name);
+
+if (!strcmp(desc->name + len - 2, "be"))
+return HAVE_BIGENDIAN;
+if (!strcmp(desc->name + len - 2, "le"))
+return !HAVE_BIGENDIAN;
+return 1;
+}
+
Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
compare?
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] avfilter/vf_lut: support native-endian instead of little-endian
Signed-off-by: Muhammad Faiz
---
Old thread is here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
Need someone test it on big-endian machine.
libavfilter/vf_lut.c | 95
1 file changed, 42 insertions(+), 53 deletions(-)
diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc194..29bb3172d7 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -116,28 +116,28 @@ static av_cold void uninit(AVFilterContext *ctx)
AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P, \
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P, \
AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE,
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE,
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV420P9, \
+AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10,
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14, \
+AV_PIX_FMT_YUV444P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV420P16, \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
#define RGB_FORMATS \
AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE, AV_PIX_FMT_RGBA64LE, \
+AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64, \
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,\
-AV_PIX_FMT_GBRP9LE, AV_PIX_FMT_GBRP10LE, \
-AV_PIX_FMT_GBRAP10LE, \
-AV_PIX_FMT_GBRP12LE, AV_PIX_FMT_GBRP14LE, \
-AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRAP12LE,\
-AV_PIX_FMT_GBRAP16LE
+AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10, \
+AV_PIX_FMT_GBRAP10, \
+AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, \
+AV_PIX_FMT_GBRP16, AV_PIX_FMT_GBRAP12,\
+AV_PIX_FMT_GBRAP16
#define GRAY_FORMATS\
-AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9LE, AV_PIX_FMT_GRAY10LE, \
-AV_PIX_FMT_GRAY12LE, AV_PIX_FMT_GRAY14LE, AV_PIX_FMT_GRAY16LE
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9, AV_PIX_FMT_GRAY10, \
+AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16
static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS,
AV_PIX_FMT_NONE };
static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS,
AV_PIX_FMT_NONE };
@@ -237,32 +237,32 @@ static int config_props(AVFilterLink *inlink)
case AV_PIX_FMT_YUVA420P:
case AV_PIX_FMT_YUVA422P:
case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case AV_PIX_FMT_YUV422P14LE:
-case AV_PIX_FMT_YUV444P14LE:
-case AV_PIX_FMT_YUV420P16LE:
-case AV_PIX_FMT_YUV422P16LE:
-case AV_PIX_FMT_YUV444P16LE:
-case AV_PIX_FMT_YUVA420P16LE:
-case AV_PIX_FMT_YUVA422P16LE:
-case AV_PIX_FMT_YUVA444P16LE:
+case AV_PIX_FMT_YUV420P9:
+case AV_PIX_FMT_YUV422P9:
+case AV_PIX_FMT_YUV444P9:
+case AV_PIX_FMT_YUVA420P9:
+case AV_PIX_FMT_YUVA422P9:
+case AV_PIX_FMT_YUVA444P9:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV440P10:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUVA420P10:
+case AV_PIX_FMT_YUVA422P10:
+case AV_PIX_FMT_YUVA444P10:
+case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV422P12:
+case AV_PIX_FMT_YUV440P12:
+case AV_PIX_FMT_YUV444P12:
+case AV_PIX_FMT_YUV420P14:
+case AV_PIX_FMT_YUV422P14:
+case AV_PIX_FMT_YUV444P14:
+case AV_PIX_FMT_YUV420P16:
+case AV_PIX_FMT_YUV422P16:
+case AV_PIX_FMT_YUV444P16:
+case AV_PIX_FMT_YUVA420P16:
+case AV_PIX_FMT_YUVA422P16:
+case AV_PIX_FMT_YUVA444P16:
min[Y] = 16 * (1 <<
[FFmpeg-devel] [PATCH 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale
Fix inconsistent checksums between gbrap10be and gbrap10le on fate-filter-pixfmts. Signed-off-by: Muhammad Faiz --- libswscale/swscale_unscaled.c| 3 +++ tests/ref/fate/filter-pixfmts-copy | 2 +- tests/ref/fate/filter-pixfmts-crop | 2 +- tests/ref/fate/filter-pixfmts-field | 2 +- tests/ref/fate/filter-pixfmts-fieldorder | 2 +- tests/ref/fate/filter-pixfmts-hflip | 2 +- tests/ref/fate/filter-pixfmts-il | 2 +- tests/ref/fate/filter-pixfmts-null | 2 +- tests/ref/fate/filter-pixfmts-transpose | 2 +- tests/ref/fate/filter-pixfmts-vflip | 2 +- 10 files changed, 12 insertions(+), 9 deletions(-) diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c index 058f2b94db..9abfae5c04 100644 --- a/libswscale/swscale_unscaled.c +++ b/libswscale/swscale_unscaled.c @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c) dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == AV_PIX_FMT_GBRP12BE || dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == AV_PIX_FMT_GBRP14BE || dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == AV_PIX_FMT_GBRP16BE || + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == AV_PIX_FMT_GBRAP12BE || dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == AV_PIX_FMT_GBRAP16BE )) c->swscale = Rgb16ToPlanarRgb16Wrapper; @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c) srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == AV_PIX_FMT_GBRP10BE || srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == AV_PIX_FMT_GBRP12BE || srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == AV_PIX_FMT_GBRP14BE || + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == AV_PIX_FMT_GBRAP12BE || srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == AV_PIX_FMT_GBRAP16BE) && (dstFormat == AV_PIX_FMT_RGB48LE || dstFormat == AV_PIX_FMT_RGB48BE || @@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c) IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) || IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) || IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) || +IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) || IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) || IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) || IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) || diff --git a/tests/ref/fate/filter-pixfmts-copy b/tests/ref/fate/filter-pixfmts-copy index bf0977a96a..4694fb7676 100644 --- a/tests/ref/fate/filter-pixfmts-copy +++ b/tests/ref/fate/filter-pixfmts-copy @@ -19,7 +19,7 @@ bgra3934fb81a602dfa7d29420b1a66f0fd8 bgra64leb71d75a928aac14cb768403e6f6a9910 bgra64leb71d75a928aac14cb768403e6f6a9910 gbrap 98d30987407c51e5620921e11d40a4ff -gbrap10le 3a046be0d38289dda5d8fdbd0f34aaf5 +gbrap10le 2a7392e14b21b1f9457526a071236a6d gbrap10le 2a7392e14b21b1f9457526a071236a6d gbrap12le 5f1d8c663d4c28863e687192433b34a4 gbrap12le 5f1d8c663d4c28863e687192433b34a4 diff --git a/tests/ref/fate/filter-pixfmts-crop b/tests/ref/fate/filter-pixfmts-crop index 09b7ca9a27..9dd6f097b5 100644 --- a/tests/ref/fate/filter-pixfmts-crop +++ b/tests/ref/fate/filter-pixfmts-crop @@ -19,7 +19,7 @@ bgrae66a5f68ba463cbc89fce23a61bb5203 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831 gbrap 188cd467fe7ae7d85ae9ca8bdfa07739 -gbrap10le c8505df07f9eeb413f943b5f4d686c0b +gbrap10le c2b6e35f8b7ca363a7ec021ccdf31d1f gbrap10le c2b6e35f8b7ca363a7ec021ccdf31d1f gbrap12le 3f80453c1ac6c5d1b2febf3ef141b476 gbrap12le 3f80453c1ac6c5d1b2febf3ef141b476 diff --git a/tests/ref/fate/filter-pixfmts-field b/tests/ref/fate/filter-pixfmts-field index 5779469d41..7dfa0c3299 100644 --- a/tests/ref/fate/filter-pixfmts-field +++ b/tests/ref/fate/filter-pixfmts-field @@ -19,7 +19,7 @@ bgra66d6e0846990fff0f09a07c43c3add71 bgra64le9e2def541e51bc6e77fbffbff7fa146a bgra64le9e2def541e51bc6e77fbffbff7fa146a gbrap 08a28b79dbd19246d1a94e3466af3624 -gbrap10le a5cfc53fbd96fcdf83b8b655fe25bf67 +gbrap10le 4017c5d8c124438eb9aefa107db58d3b gbrap10le 4017c5d8c124438eb9aefa107db58d3b gbrap12le 886207e5aa379a0312485b94e5fd5edd gbrap12le 886207e5aa379a0312485b94e5fd5edd diff --git a/tests/ref/fate/filter-pixfmts-fieldorder b/tests/ref/fate/filter-pixfmts-fieldorder index 216ca3e769..e62768ab3d 100644 --- a/tests/ref/fate/
[FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian
Signed-off-by: Muhammad Faiz
---
Old thread is here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
Need someone test it on big-endian machine.
libavfilter/drawutils.c | 48 +
libavfilter/vf_rotate.c | 26 ++--
libavfilter/vf_tinterlace.c | 30 +++
3 files changed, 54 insertions(+), 50 deletions(-)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 5f4cb548f0..12bdfcb900 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
dst_linesize[4],
}
}
+static int is_native_endian(const AVPixFmtDescriptor *desc)
+{
+int len = strlen(desc->name);
+
+if (!strcmp(desc->name + len - 2, "be"))
+return HAVE_BIGENDIAN;
+if (!strcmp(desc->name + len - 2, "le"))
+return !HAVE_BIGENDIAN;
+return 1;
+}
+
int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned
flags)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
@@ -185,20 +196,20 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat
format, unsigned flags)
if (!desc || !desc->name)
return AVERROR(EINVAL);
-if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB |
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
+if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB |
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BE))
return AVERROR(ENOSYS);
if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE || format
== AV_PIX_FMT_P016LE || format == AV_PIX_FMT_P016BE)
return AVERROR(ENOSYS);
if (format == AV_PIX_FMT_YUVJ420P || format == AV_PIX_FMT_YUVJ422P ||
format == AV_PIX_FMT_YUVJ444P ||
format == AV_PIX_FMT_YUVJ411P || format == AV_PIX_FMT_YUVJ440P)
full_range = 1;
+if (!is_native_endian(desc))
+return AVERROR(ENOSYS);
for (i = 0; i < desc->nb_components; i++) {
c = &desc->comp[i];
/* for now, only 8-16 bits formats */
if (c->depth < 8 || c->depth > 16)
return AVERROR(ENOSYS);
-if (desc->flags & AV_PIX_FMT_FLAG_BE)
-return AVERROR(ENOSYS);
if (c->plane >= MAX_PLANES)
return AVERROR(ENOSYS);
/* strange interleaving */
@@ -268,11 +279,11 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor
*color, const uint8_t rgba[4
EXPAND(1);
EXPAND(0);
} else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format ==
AV_PIX_FMT_GRAY8A ||
- draw->format == AV_PIX_FMT_GRAY16LE || draw->format ==
AV_PIX_FMT_YA16LE ||
- draw->format == AV_PIX_FMT_GRAY9LE ||
- draw->format == AV_PIX_FMT_GRAY10LE ||
- draw->format == AV_PIX_FMT_GRAY12LE ||
- draw->format == AV_PIX_FMT_GRAY14LE) {
+ draw->format == AV_PIX_FMT_GRAY16 || draw->format ==
AV_PIX_FMT_YA16 ||
+ draw->format == AV_PIX_FMT_GRAY9 ||
+ draw->format == AV_PIX_FMT_GRAY10 ||
+ draw->format == AV_PIX_FMT_GRAY12 ||
+ draw->format == AV_PIX_FMT_GRAY14) {
const AVPixFmtDescriptor *desc = draw->desc;
color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
EXPAND(0);
@@ -331,11 +342,6 @@ void ff_fill_rectangle(FFDrawContext *draw, FFDrawColor
*color,
return;
p = p0;
-if (HAVE_BIGENDIAN && draw->desc->comp[0].depth > 8) {
-for (x = 0; 2*x < draw->pixelstep[plane]; x++)
-color_tmp.comp[plane].u16[x] =
av_bswap16(color_tmp.comp[plane].u16[x]);
-}
-
/* copy first line from color */
for (x = 0; x < wp; x++) {
memcpy(p, color_tmp.comp[plane].u8, draw->pixelstep[plane]);
@@ -426,19 +432,19 @@ static void blend_line16(uint8_t *dst, unsigned src,
unsigned alpha,
if (left) {
unsigned suba = (left * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
dst += dx;
}
for (x = 0; x < w; x++) {
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * tau + asrc) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * tau + asrc) >> 16);
dst += dx;
}
if (right) {
unsigned suba = (right * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
}
}
@@ -531,7 +537,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src,
unsigned alpha,
unsigned xmmod = 7 >> l2depth;
unsigned mbits = (1 << (1 << l2depth))
[FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing
Fix mismatched checksum on fate-filter-pixfmts-super2xsai.
Signed-off-by: Muhammad Faiz
---
libavfilter/vf_super2xsai.c | 4 ++--
tests/ref/fate/filter-pixfmts-super2xsai | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_super2xsai.c b/libavfilter/vf_super2xsai.c
index 87eec04da8..4901e03e23 100644
--- a/libavfilter/vf_super2xsai.c
+++ b/libavfilter/vf_super2xsai.c
@@ -180,8 +180,8 @@ static void super2xsai(AVFilterContext *ctx,
break;
default: // bpp = 2
if (s->is_be) {
-AV_WB32(dst_line[0] + x * 4, product1a | (product1b <<
16));
-AV_WB32(dst_line[1] + x * 4, product2a | (product2b <<
16));
+AV_WB32(dst_line[0] + x * 4, (product1a << 16) |
product1b);
+AV_WB32(dst_line[1] + x * 4, (product2a << 16) |
product2b);
} else {
AV_WL32(dst_line[0] + x * 4, product1a | (product1b <<
16));
AV_WL32(dst_line[1] + x * 4, product2a | (product2b <<
16));
diff --git a/tests/ref/fate/filter-pixfmts-super2xsai
b/tests/ref/fate/filter-pixfmts-super2xsai
index d42601dab1..c76d469880 100644
--- a/tests/ref/fate/filter-pixfmts-super2xsai
+++ b/tests/ref/fate/filter-pixfmts-super2xsai
@@ -1,14 +1,14 @@
abgre21be14b5fe9d7a29740a418c325b17e
argb563489534663cb2b32beed2b41370c37
bgr24 a933eac9bb53c3ce3c33950b229996b5
-bgr555led69e39a24027afcb28feaabb46f0948d
bgr555le70b819425f79f823356229b90b41cc84
-bgr565le78f3b43ddcc1f8558444c97d249a6123
+bgr555le70b819425f79f823356229b90b41cc84
+bgr565le6fb9dc50a81b853800ba65d5ec6b8417
bgr565le6fb9dc50a81b853800ba65d5ec6b8417
bgrae9cc6644e2f35103c241094ab4bb8fec
rgb24 3fd7653f414f350ddb0c0a236ce0c809
-rgb555lef2f9f30e8be582729f12a03331e3c635
rgb555le53325a20c913826566880eb25d1d2946
-rgb565le340ffed3645809f68346280764ca3de6
+rgb555le53325a20c913826566880eb25d1d2946
+rgb565le14fe550f449a7539d9f1e99e85cf40f1
rgb565le14fe550f449a7539d9f1e99e85cf40f1
rgba7041184d35c316e73e849504b64bc4f6
--
2.17.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection
On Thu, 17 Jan 2019 09:40:09 +0200 Lauri Kasanen wrote: > On Tue, 8 Jan 2019 11:08:04 +0200 > Lauri Kasanen wrote: > > > The existing code was in no released kernel that I can see. The corrected > > code > > was added in 3.9. > > > > Signed-off-by: Lauri Kasanen > > --- > > libavutil/ppc/cpu.c | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > Ping. Ping. Carl Eugen, you were the only one who looked at it - could you apply it? Given the low interest in power patches, should I be applying for commit rights? - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
On Mon, 14 Jan 2019 16:13:52 +0100 Michael Niedermayer wrote: > On Sun, Jan 13, 2019 at 10:26:20AM +0200, Lauri Kasanen wrote: > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt > > yuv420p16be \ > > -s 1920x1728 -f null -vframes 100 -v error -nostats - > > > > 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x. > > Fate passes, each format tested with an image to video conversion. > > > > Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out > > of the 16-bit function. This includes the vec_mulo/mule functions too, > > not just vmuluwm. ... > > v6: No patch changes, updated bench numbers without skips. > > fate does not get worse from this patch on qemu ppc32be and ppc64le Ping - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
