[FFmpeg-devel] [PATCH] avutil/hwcontext_d3d11va: fix type arguments passed to IDXGIAdapter2_GetDesc()
libavutil/hwcontext_d3d11va.c: In function 'd3d11va_device_create':
libavutil/hwcontext_d3d11va.c:554:46: warning: passing argument 2 of
'pAdapter->lpVtbl->GetDesc' from incompatible pointer type
[-Wincompatible-pointer-types]
hr = IDXGIAdapter2_GetDesc(pAdapter, );
^
libavutil/hwcontext_d3d11va.c:554:46: note: expected 'DXGI_ADAPTER_DESC * {aka
struct DXGI_ADAPTER_DESC *}' but argument is of type 'DXGI_ADAPTER_DESC2 * {aka
struct DXGI_ADAPTER_DESC2 *}'
Signed-off-by: James Almer
---
libavutil/hwcontext_d3d11va.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index b68d262804..41330f0ae6 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -550,7 +550,7 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx,
const char *device,
}
if (pAdapter) {
-DXGI_ADAPTER_DESC2 desc;
+DXGI_ADAPTER_DESC desc;
hr = IDXGIAdapter2_GetDesc(pAdapter, );
if (!FAILED(hr)) {
av_log(ctx, AV_LOG_INFO, "Using device %04x:%04x (%ls).\n",
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why not integrate libyuv as a scale filter
On Mon, Jul 23, 2018 at 07:16:43PM +0200, Nicolas George wrote: > Jeff (2018-07-23): > > It seems like libyuv has better performace on scaling than libswscale. > > So I'm wondering is there anyone has tried integrating libyuv as a > > scale filter before. I mean link it as a 3rd party lib, and then call > > it's API through a wrap filter. Just like how libavcodec use libx264. > > If not, why? Is there any licensee issue? Effort worth pay on it? > > Finding out why it has better performance (figures?) and integrating the > same optimizations would be more in line with the project policy, I > think. same oppinion here, if its better in some case, please integrate whatever it does better Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] download: remove dead link for Mac binaries
On Mon, Jul 23, 2018 at 07:38:16PM +0530, Gyan Doshi wrote: > download |3 --- > 1 file changed, 3 deletions(-) > 79d69cdda36ee65da6f7348f8397ccbb8fc9854d > 0001-download-remove-dead-link-for-Mac-binaries.patch > From f57cec086a22300dbc12f6e998b2cf53d7a8e103 Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Mon, 23 Jul 2018 19:33:57 +0530 > Subject: [PATCH] download: remove dead link for Mac binaries > > ffmpegmac.net now leads to a parked page. > --- > src/download | 3 --- > 1 file changed, 3 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Parse encryption init info from streams.
On Thu, Jul 12, 2018 at 5:05 PM Jacob Trimble wrote:
>
> Signed-off-by: Jacob Trimble
> ---
> libavformat/matroskadec.c | 43 +--
> 1 file changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 1ded431b80..bfef329e59 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -2080,7 +2080,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
> int extradata_offset = 0;
> uint32_t fourcc = 0;
> AVIOContext b;
> -char* key_id_base64 = NULL;
> +char* key_id = NULL;
> +int key_id_size = 0;
> int bit_depth = -1;
>
> /* Apply some sanity checks. */
> @@ -2133,14 +2134,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
> if (encodings[0].encryption.key_id.size > 0) {
> /* Save the encryption key id to be stored later as a
> metadata tag. */
> -const int b64_size =
> AV_BASE64_SIZE(encodings[0].encryption.key_id.size);
> -key_id_base64 = av_malloc(b64_size);
> -if (key_id_base64 == NULL)
> -return AVERROR(ENOMEM);
> -
> -av_base64_encode(key_id_base64, b64_size,
> - encodings[0].encryption.key_id.data,
> - encodings[0].encryption.key_id.size);
> +key_id = encodings[0].encryption.key_id.data;
> +key_id_size = encodings[0].encryption.key_id.size;
> } else {
> encodings[0].scope = 0;
> av_log(matroska->ctx, AV_LOG_ERROR,
> @@ -2198,14 +2193,40 @@ static int matroska_parse_tracks(AVFormatContext *s)
>
> st = track->stream = avformat_new_stream(s, NULL);
> if (!st) {
> -av_free(key_id_base64);
> return AVERROR(ENOMEM);
> }
>
> -if (key_id_base64) {
> +if (key_id) {
> +AVEncryptionInitInfo *init_info;
> +uint8_t *side_data;
> +size_t side_data_size;
> +const int b64_size = AV_BASE64_SIZE(key_id_size);
> +char *key_id_base64 = av_malloc(b64_size);
> +if (!key_id_base64)
> +return AVERROR(ENOMEM);
> +av_base64_encode(key_id_base64, b64_size, key_id, key_id_size);
> +
> /* export encryption key id as base64 metadata tag */
> av_dict_set(>metadata, "enc_key_id", key_id_base64, 0);
> av_freep(_id_base64);
> +
> +
> +/* Convert the key ID to a generic encryption init info */
> +init_info = av_encryption_init_info_alloc(/* system_id_size */
> 0, /* num_key_ids */ 1,
> + /* key_id_size */
> key_id_size, /* data_size */ 0);
> +if (!init_info)
> +return AVERROR(ENOMEM);
> +memcpy(init_info->key_ids[0], key_id, key_id_size);
> +side_data = av_encryption_init_info_add_side_data(init_info,
> _data_size);
> +av_encryption_init_info_free(init_info);
> +if (!side_data)
> +return AVERROR(ENOMEM);
> +ret = av_stream_add_side_data(st,
> AV_PKT_DATA_ENCRYPTION_INIT_INFO,
> + side_data, side_data_size);
> +if (ret < 0) {
> +av_free(side_data);
> +return ret;
> +}
> }
>
> if (!strcmp(track->codec_id, "V_MS/VFW/FOURCC") &&
> --
> 2.18.0.203.gfac676dfb9-goog
>
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroska: Parse generic encryption info from packets.
On Thu, Jul 12, 2018 at 4:45 PM Jacob Trimble wrote: > > The attached patch adds parsing for WebM encryption info into the > AVEncryptionInfo side-data. The AVEncryptionInitInfo will be handled > in another patch. > > Spec: https://www.webmproject.org/docs/webm-encryption/ > > I am currently seeing a problem with this when using Opus audio. In > read_frame_internal, it will try to parse the resulting packet. For > video, which uses subsample encryption, it is able to parse the > headers; but for Opus, which uses full-sample encryption, it fails to > parse the headers. This causes the read_frame_internal to drop the > packet. > > I have traced a workaround to opus_parse in opus_parser.c: instead of > setting poutbuf to NULL, set it to the buffer and just pass the packet > to the app to handle it. The frame will be decrypted before passing > to the decoder. I can't just disable parsing in the demuxer because I > want to parse the packets for clear content and when using subsample > encryption. > > Does anyone have any other ideas to work around this? Is there a way > to allow parsing but ignore errors? Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy
Am 19.07.18 um 08:26 schrieb Thilo Borgmann: > > >> Am 16.07.2018 um 13:41 schrieb Mina : >> >> Hi, >> >> This patch introduces Grey-Edge algorithm as part of the Color Constancy >> Filter project in GSOC. >> >> V4 changes: >> - Fixed error in filter.texi that resulted in breaking "make >> doc/ffprobe-all.html" > > If there are no more comments coming in I‘ll push this in a couple of days. Applied. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why not integrate libyuv as a scale filter
> On Jul 23, 2018, at 1:16 PM, Nicolas George wrote: > > Jeff (2018-07-23): >> It seems like libyuv has better performace on scaling than libswscale. >> So I'm wondering is there anyone has tried integrating libyuv as a >> scale filter before. I mean link it as a 3rd party lib, and then call >> it's API through a wrap filter. Just like how libavcodec use libx264. >> If not, why? Is there any licensee issue? Effort worth pay on it? > > Finding out why it has better performance (figures?) and integrating the > same optimizations would be more in line with the project policy, I > think. > > Regards, > > -- > Nicolas George Hello, I’ve used libyuv in a couple of projects in the past. Nice little library and easy to bolt into an existing application when you need a quick scaling, colorspace conversion, or rotation in the most common YUV colorspaces found in decoders and graphics chipsets (e.g. stuff like NV12). It also has pretty good optimized assembly for ARM for common use cases, making it perform well on such platforms. Because it’s got a relatively simple API and build setup, it’s my “go to” library when my requirements are simple and I want to cross-compile for some embedded target. That said, it takes a pretty simplistic approach to operations such as scaling and CSC, generally only providing a single scheme for each. You can probably get comparable performance from libswscale if you adjust the tuning parameters to match whatever scaling algorithm libyuv internally implements. As Nicolas suggested, if you have some specific use case you can describe where libyuv significant outperforms libswscale, it would be great to see some numbers and discuss. It’s possible it has some optimized assembly worth looking closer at, but my gut reaction is that it’s likely just that libswscale’s defaults to a higher quality scaler (at the associated cost), and you can achieve comparable numbers as found in libyuv by tweaking the configuration. Devin --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why not integrate libyuv as a scale filter
Jeff (2018-07-23): > It seems like libyuv has better performace on scaling than libswscale. > So I'm wondering is there anyone has tried integrating libyuv as a > scale filter before. I mean link it as a 3rd party lib, and then call > it's API through a wrap filter. Just like how libavcodec use libx264. > If not, why? Is there any licensee issue? Effort worth pay on it? Finding out why it has better performance (figures?) and integrating the same optimizations would be more in line with the project policy, I think. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Why not integrate libyuv as a scale filter
Hi there, It seems like libyuv has better performace on scaling than libswscale. So I'm wondering is there anyone has tried integrating libyuv as a scale filter before. I mean link it as a 3rd party lib, and then call it's API through a wrap filter. Just like how libavcodec use libx264. If not, why? Is there any licensee issue? Effort worth pay on it? Thanks, Jogh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Use channel count in rematrix initialization
On Sat, Jul 21, 2018 at 07:31:12PM +0100, Marcin Gorzel wrote:
> Rematrixing supports up to 64 channels. However, there is only a limited
> number of channel layouts defined. Since the in/out channel count is
> currently obtained from the channel layout, for undefined layouts (e.g. for
> 9, 10, 11 channels etc.) the rematrixing fails.
>
> This patch changes rematrix init methods to use in/out channel count directly
> instead of computing it from channel layout.
> ---
> libswresample/rematrix.c | 4 ++--
> libswresample/x86/rematrix_init.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> index 8227730056..ec1909dc0c 100644
> --- a/libswresample/rematrix.c
> +++ b/libswresample/rematrix.c
> @@ -384,8 +384,8 @@ av_cold static int auto_matrix(SwrContext *s)
>
> av_cold int swri_rematrix_init(SwrContext *s){
> int i, j;
> -int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> +int nb_in = s->in.ch_count;
> +int nb_out = s->out.ch_count;
>
> s->mix_any_f = NULL;
This is much better than the previous patch
still, why is this not using used_ch_count ?
Lets look at the code in swresample.c, as i dont remember 100% ...
First stage is in_convert, its initialized with:
s->in_convert = swri_audio_convert_alloc(s->int_sample_fmt,
s-> in_sample_fmt,
s->used_ch_count, s->channel_map, 0);
You can see here that used_ch_count is its output
and next stages are resample and rematrix (in either order)
how can they have s->in.ch_count as input ?
and yes, it seems there is no testcase that catches this, which is
unfortunate.
a much more minor issue is, please vertically align the "=" as it was
before the patch.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] download: remove dead link for Mac binaries
From f57cec086a22300dbc12f6e998b2cf53d7a8e103 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Mon, 23 Jul 2018 19:33:57 +0530 Subject: [PATCH] download: remove dead link for Mac binaries ffmpegmac.net now leads to a parked page. --- src/download | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/download b/src/download index 183ca95..0bda5a0 100644 --- a/src/download +++ b/src/download @@ -97,9 +97,6 @@ https://evermeet.cx/ffmpeg/;> Static builds for OS X Intel 64-bit - http://ffmpegmac.net/;> -Builds 32-bit and 64-bit for OS X 10.5 and above - https://ffmpeg.zeranoe.com/builds/;> Static and shared builds for macOS 64-bit -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresenc_aw improvements
> > > > > Do you think it's better to only authorize few colorspace ? > > depends on what happens if "others" are stored. > if the official decoders fail with a blank screen then its probably > not a good idea to use such a value. If OTOH they ignore values they > do not support then it may be ok. > Seems like not all prores decoder use these values. Will check, with offical decoder. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] docs/filters: add documentation to all existing OpenCL filters
On 20-07-2018 10:01 PM, Danil Iashchenko wrote:
+@section avgblur_opencl
+
+Apply average blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item sizeX
+Set horizontal radius size. By default value is @code{1}.
State range as well for all options, e.g.
Range is @code{[1, 1024]} and default value is @code{1}.
+Insert a JPG logo in the bottom left corner of the input
Shouldn't this be top-left?
+@example
+-i INPUT -i LOGO -filter_complex
"[0:v]hwupload[a],[1:v]hwupload[b],[a][b]overlay_opencl[out],[out]hwdownload"
OUTPUT
Prefer this in recommended syntax:
"[0:v]hwupload[a];[1:v]hwupload[b];[a][b]overlay_opencl,hwdownload"
+@section tonemap_opencl
+Tone map colors from different dynamic ranges.
+
+Supported output formats: NV12/P010.
+
+@subsection Options
+The filter accepts the following options.
+
+@table @option
+@item tonemap
+Set the tone map algorithm to use.
+
+Possible values are:
+@table @var
+@item none
+Do not apply any tone map, only desaturate overbright pixels.
+
+@item linear
+Stretch the entire reference gamut to a linear multiple of the display.
+
+@end table
+
+Default is none.
+
+@item param
+Tune the tone mapping algorithm.
+
+This affects the following algorithms:
+@table @var
+@item none
+Ignored.
+
+@item linear
+Specifies the scale factor to use while stretching.
+Default to 1.0.
The filer source has many more options defined.
In addition, there are many missing values for the tonemap algo; it
appears not all are effected. If that's the case, remove or note that in
the AVOptions table.
Please document all effective options and their values.
+This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping with vaapi
codecs.
+@example
+-init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device opencl=ocl@@va
-hwaccel vaapi -hwaccel_device va -hwaccel_output_format vaapi -i INPUT
-filter_hw_device ocl -filter_complex
'[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]
[x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT
hwmap doc says reverse is a "dangerous" option and should be used with
care. Can you convert this example to one which doesn't use it?
---
There are 4 whitespace errors reported when applying the mbox. Doesn't
matter much in docs/* but do remove them during revision.
Please remember to state range/default for all options. If an option has
an alias, mention it, like in unsharp_opencl.
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Use channel count in rematrix initialization
On 21.07.2018 20:31, Marcin Gorzel wrote:
Rematrixing supports up to 64 channels. However, there is only a limited number
of channel layouts defined. Since the in/out channel count is currently
obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
channels etc.) the rematrixing fails.
This patch changes rematrix init methods to use in/out channel count directly
instead of computing it from channel layout.
---
libswresample/rematrix.c | 4 ++--
libswresample/x86/rematrix_init.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..ec1909dc0c 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -384,8 +384,8 @@ av_cold static int auto_matrix(SwrContext *s)
av_cold int swri_rematrix_init(SwrContext *s){
int i, j;
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in.ch_count;
+int nb_out = s->out.ch_count;
s->mix_any_f = NULL;
diff --git a/libswresample/x86/rematrix_init.c b/libswresample/x86/rematrix_init.c
index d71b41a73e..1cdf97803f 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,8 @@ D(int16, sse2)
av_cold int swri_rematrix_init_x86(struct SwrContext *s){
#if HAVE_X86ASM
int mm_flags = av_get_cpu_flags();
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in.ch_count;
+int nb_out = s->out.ch_count;
int num= nb_in * nb_out;
int i,j;
Patch looks good to me. Will leave it to Michael to comment/apply the patch.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
