[FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
Pass through mode (input resolution = output resolution) mode is broken in scale_npp. This patch fixes the same. Thanks, Yogender --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-scale_npp-Fix-pass-through-mode.patch Description: 0001-scale_npp-Fix-pass-through-mode.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
On 14/08/17 12:20, Yogender Gupta wrote:
> Pass through mode (input resolution = output resolution) mode is broken in
> scale_npp. This patch fixes the same.
>
> Thanks,
> Yogender
>
> From 6ab2dee97b0eef4c06e9ba8a24a9be01a8c3e33d Mon Sep 17 00:00:00 2001
> From: Yogender Gupta
> Date: Mon, 14 Aug 2017 16:11:32 +0530
> Subject: [PATCH] scale_npp : Fix pass through mode
>
> ---
> libavfilter/vf_scale_npp.c | 4
> 1 file changed, 4 insertions(+)
Right, this was broken by the addition of the the HWFRAME_AWARE flag to the
filter, because it was previously relying on the automatic propagation of the
input hw_frames_ctx to the output link for the passthrough case.
LGTM with changes below.
Thanks,
- Mark
> diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
> index c36772e..f64ab95 100644
> --- a/libavfilter/vf_scale_npp.c
> +++ b/libavfilter/vf_scale_npp.c
> @@ -320,7 +320,11 @@ static int init_processing_chain(AVFilterContext *ctx,
> int in_width, int in_heig
> }
>
> if (last_stage < 0)
> +{
Please use the same brace style as everywhere else in ffmpeg.
> +ctx->outputs[0]->hw_frames_ctx =
> av_buffer_ref(ctx->inputs[0]->hw_frames_ctx);
This needs to check that the allocation succeeds (as in the following lines).
> return 0;
> +}
> +
> ctx->outputs[0]->hw_frames_ctx =
> av_buffer_ref(s->stages[last_stage].frames_ctx);
> if (!ctx->outputs[0]->hw_frames_ctx)
> return AVERROR(ENOMEM);
> --
> 2.10.1.windows.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add single precision planar RGB pixel formats
2017-08-11 16:11 GMT+02:00 Vittorio Giovara : > [...] Can't you use the functions from FFmpeg's exr implementation to provide basic libswscale support? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
Applied with a slightly changed logic to achieve the same with fewer lines. (Which I forgot to commit before pushing, so there's two patches now) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: Add support for QSV screen capture plugin
On 11/08/17 10:10, Alexander Bilyak wrote: > Intel QSV SDK provide screen capture plugin starting from API ver 1.17 > as runtime loadable plugin for QSV decoder. > > * add API version selection while initialization of QSV context > (default is still 1.1 for usual encoding/decoding) > --- > configure | 2 + > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/qsv.c | 6 +- > libavcodec/qsv_internal.h | 2 +- > libavcodec/qsvdec.c| 12 ++- > libavcodec/qsvdec.h| 5 + > libavcodec/qsvdec_screen.c | 250 > + > libavcodec/qsvenc.c| 3 +- > 9 files changed, 272 insertions(+), 10 deletions(-) > create mode 100644 libavcodec/qsvdec_screen.c I'm not convinced that adding this as a hacked-up pseudo-decoder is really the best approach. It would, I think, be straightforward to put this in lavd completely standalone. The common code you are actually using there is: * Session initialisation - this should be trivial, since you have no device or external frames anyway. * The actual decode function - this contains a lot of additional trickiness (packets, asynchronicity, queueing) which you don't want. A simpler form which just fetches one frame would feel better. This should also be able to avoid the second copy to the output packet. Some other thoughts: * If this is only available in a higher API version then you will need a configure test for those headers. * Does this only support NV12 capture? In many cases RGB is more useful (or at least some YUV 4:4:4 which doesn't do nasty things to thin coloured lines). * Is having an externally-provided device (hw_device_ctx) ever useful? The lavd implementation doesn't have any way to pass a device in (since lavf can't). * Do you happen to know how it actually works? (Presumably it's reading surfaces used for scanout on the GPU side somehow; who does the copy and colour conversion?) Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: Add support for QSV screen capture plugin
Hi, Mark, I am not satisfied with this approach neither. But I thought it would be better this way since we have already well-written code for encoder/decoder, surface management, etc. Sharing this functions between lavc and lavd will be a big mess up and produce a lot of avpriv_ functions (I've tried). And I don't know if copying the same code twice (at least for surface management and initialization) would be better than adding pseudo-decoder. So I sent this patch just to show the idea, of course it is not final version. I was curious if pseudo-decoder will be acceptable or not. Also your remarks 1 and 2 are true. But as I said: this is just concept version. I don't have idea if there could be any need to pass external device in. If you want a screen capture device - what could you wish to do with it's hardware context? Settings like mouse capture (that is not working at all in QSV lol) or specifying desired window/area could be set via usual text options. If someone REALLY want to provide external device context (or get it out from created context) - we could add some callback parameter with pointer to context memory (I've seen something like this in VLC long time ago). This is bad, BAD approach, but as you mentioned - lavf won't let us do anything else. As far as I understood this "decoder" from Intel makes copy of backbuffer to system memory. As it consumes a lot less CPU than GDI (like half) and Intel Media Performance shows me some small load on MFX - I THINK that GPU is responsible for copying and converting. But this are just my thoughts, that's all as no info is provided in documentation. Many thanks for reviewing the code, - Alex 2017-08-14 14:26 GMT+02:00 Mark Thompson : > On 11/08/17 10:10, Alexander Bilyak wrote: > > Intel QSV SDK provide screen capture plugin starting from API ver 1.17 > > as runtime loadable plugin for QSV decoder. > > > > * add API version selection while initialization of QSV context > > (default is still 1.1 for usual encoding/decoding) > > --- > > configure | 2 + > > libavcodec/Makefile| 1 + > > libavcodec/allcodecs.c | 1 + > > libavcodec/qsv.c | 6 +- > > libavcodec/qsv_internal.h | 2 +- > > libavcodec/qsvdec.c| 12 ++- > > libavcodec/qsvdec.h| 5 + > > libavcodec/qsvdec_screen.c | 250 ++ > +++ > > libavcodec/qsvenc.c| 3 +- > > 9 files changed, 272 insertions(+), 10 deletions(-) > > create mode 100644 libavcodec/qsvdec_screen.c > > I'm not convinced that adding this as a hacked-up pseudo-decoder is really > the best approach. > > It would, I think, be straightforward to put this in lavd completely > standalone. The common code you are actually using there is: > * Session initialisation - this should be trivial, since you have no > device or external frames anyway. > * The actual decode function - this contains a lot of additional > trickiness (packets, asynchronicity, queueing) which you don't want. A > simpler form which just fetches one frame would feel better. This should > also be able to avoid the second copy to the output packet. > > Some other thoughts: > * If this is only available in a higher API version then you will need a > configure test for those headers. > * Does this only support NV12 capture? In many cases RGB is more useful > (or at least some YUV 4:4:4 which doesn't do nasty things to thin coloured > lines). > * Is having an externally-provided device (hw_device_ctx) ever useful? > The lavd implementation doesn't have any way to pass a device in (since > lavf can't). > * Do you happen to know how it actually works? (Presumably it's reading > surfaces used for scanout on the GPU side somehow; who does the copy and > colour conversion?) > > Thanks, > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
>> Applied with a slightly changed logic to achieve the same with fewer lines. I just tested, the modified logic doesn't work as none of the stages are initialized. Thanks, Yogender -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Timo Rothenpieler Sent: Monday, August 14, 2017 5:49 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode Applied with a slightly changed logic to achieve the same with fewer lines. (Which I forgot to commit before pushing, so there's two patches now) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
Am 14.08.2017 um 15:42 schrieb Yogender Gupta: >>> Applied with a slightly changed logic to achieve the same with fewer lines. > > I just tested, the modified logic doesn't work as none of the stages are > initialized. > True, I mis-read the array name as being identical. -ctx->outputs[0]->hw_frames_ctx = av_buffer_ref(s->stages[last_stage > 0 ? last_stage : 0].frames_ctx); +if (last_stage < 0) +ctx->outputs[0]->hw_frames_ctx = av_buffer_ref(ctx->inputs[0]->hw_frames_ctx); +else +ctx->outputs[0]->hw_frames_ctx = av_buffer_ref(s->stages[last_stage].frames_ctx); + This should be good? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode
The better simplification may be : ctx->outputs[0]->hw_frames_ctx = s->stages[last_stage > 0] ? s->stages[last_stage].frames_ctx : ctx->inputs[0]->hw_frames_ctx; -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Timo Rothenpieler Sent: Monday, August 14, 2017 5:49 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [Patch] scale_npp : Fix pass through mode Applied with a slightly changed logic to achieve the same with fewer lines. (Which I forgot to commit before pushing, so there's two patches now) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tonemap filter
Hi,
On 8/11/17, Vittorio Giovara wrote:
[...]
> +/* do the tone map */
> +for (y = 0; y < in->height; y++)
> +for (x = 0; x < in->width; x++)
> +tonemap(s, out, in, desc, x, y, peak);
> +
> +/* copy/generate alpha if needed */
> +if (desc->flags & AV_PIX_FMT_FLAG_ALPHA && odesc->flags &
> AV_PIX_FMT_FLAG_ALPHA) {
> +av_image_copy_plane(out->data[3], out->linesize[3],
> +in->data[3], in->linesize[3],
> +out->linesize[3], outlink->h);
> +} else if (odesc->flags & AV_PIX_FMT_FLAG_ALPHA) {
> +for (y = 0; y < outlink->h; y++)
> +memset(out->data[3] + y * out->linesize[3], 0xff, outlink->w);
This looks strange.
Rest looks fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] zscale: Enable single precision input/ouput filtering
Hi, On 8/11/17, Vittorio Giovara wrote: > --- > libavfilter/vf_zscale.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add single precision planar RGB pixel formats
On 8/11/17, Vittorio Giovara wrote: > Signed-off-by: Vittorio Giovara > --- > libavutil/pixdesc.c | 54 > > libavutil/pixdesc.h | 5 > libavutil/pixfmt.h | 7 ++ > tests/ref/fate/sws-pixdesc-query | 20 +++ > 4 files changed, 86 insertions(+) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tonemap filter
>Hi,
>
>On 8/11/17, Vittorio Giovara wrote:
>[...]
>> +/* do the tone map */
>> +for (y = 0; y < in->height; y++)
>> +for (x = 0; x < in->width; x++)
>> +tonemap(s, out, in, desc, x, y, peak);
>> +
>> +/* copy/generate alpha if needed */
>> +if (desc->flags & AV_PIX_FMT_FLAG_ALPHA && odesc->flags &
>> AV_PIX_FMT_FLAG_ALPHA) {
>> +av_image_copy_plane(out->data[3], out->linesize[3],
>> +in->data[3], in->linesize[3],
>> +out->linesize[3], outlink->h);
>> +} else if (odesc->flags & AV_PIX_FMT_FLAG_ALPHA) {
>> +for (y = 0; y < outlink->h; y++)
>> +memset(out->data[3] + y * out->linesize[3], 0xff, outlink->w);
>
>This looks strange.
>
>Rest looks fine.
Ah right, thanks for spotting, replaced with
for (y = 0; y < out->height; y++) {
for (x = 0; x < out->width; x++) {
AV_WN32(out->data[3] + x * odesc->comp[3].step + y *
out->linesize[3],
av_float2int(1.0f));
}
}
pushing later today unless further objections
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/decklink: configurablity to set max queue size
On Mon, 14 Aug 2017, Patagar, Ravindra wrote:
Configurablity to set max queue size so that worst case latency can be
controlled.
Signed-off-by: Ravindra Patagar
---
libavdevice/decklink_common.h | 2 ++
libavdevice/decklink_common_c.h | 2 ++
libavdevice/decklink_dec.cpp| 7 +--
libavdevice/decklink_dec_c.c| 2 ++
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index c12cf18..64cc722 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -1,6 +1,7 @@
/*
* Blackmagic DeckLink common code
* Copyright (c) 2013-2014 Ramiro Polla, Luca Barbato, Deti Fliegl
+ * Copyright (c) 2017 Akamai Technologies, Inc.
*
* This file is part of FFmpeg.
*
@@ -38,6 +39,7 @@ typedef struct AVPacketQueue {
pthread_mutex_t mutex;
pthread_cond_t cond;
AVFormatContext *avctx;
+int max_q_size;
} AVPacketQueue;
struct decklink_ctx {
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 72c5f9a..0ddd32a 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -1,6 +1,7 @@
/*
* Blackmagic DeckLink common code
* Copyright (c) 2013-2014 Ramiro Polla
+ * Copyright (c) 2017 Akamai Technologies, Inc.
*
* This file is part of FFmpeg.
*
@@ -48,6 +49,7 @@ struct decklink_cctx {
int video_input;
int draw_bars;
char *format_code;
+int queue_size;
};
#endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 72449a8..8e85c65 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1,6 +1,7 @@
/*
* Blackmagic DeckLink input
* Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
+ * Copyright (c) 2017 Akamai Technologies, Inc.
*
* This file is part of FFmpeg.
*
@@ -187,10 +188,12 @@ static uint8_t* teletext_data_unit_from_vanc_data(uint8_t
*src, uint8_t *tgt, in
static void avpacket_queue_init(AVFormatContext *avctx, AVPacketQueue *q)
{
+struct decklink_cctx * ctx = (struct decklink_cctx *)avctx->priv_data;
memset(q, 0, sizeof(AVPacketQueue));
pthread_mutex_init(&q->mutex, NULL);
pthread_cond_init(&q->cond, NULL);
q->avctx = avctx;
+q->max_q_size = ctx->queue_size;
}
static void avpacket_queue_flush(AVPacketQueue *q)
@@ -230,8 +233,8 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket
*pkt)
{
AVPacketList *pkt1;
-// Drop Packet if queue size is > 1GB
-if (avpacket_queue_size(q) > 1024 * 1024 * 1024 ) {
+// Drop Packet if queue size is > maximum queue size
+if (avpacket_queue_size(q) > q->max_q_size ) {
av_log(q->avctx, AV_LOG_WARNING, "Decklink input buffer overrun!\n");
return -1;
}
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 5b26d12..ea828be 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -1,6 +1,7 @@
/*
* Blackmagic DeckLink input
* Copyright (c) 2014 Deti Fliegl
+ * Copyright (c) 2017 Akamai Technologies, Inc.
*
* This file is part of FFmpeg.
*
@@ -64,6 +65,7 @@ static const AVOption options[] = {
{ "reference", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_REFERENCE}, 0, 0, DEC, "pts_source"},
{ "wallclock", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_WALLCLOCK}, 0, 0, DEC, "pts_source"},
{ "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
AV_OPT_TYPE_BOOL, { .i64 = 1}, 0, 1, DEC },
+{ "qbufsize", "Input queue buffer size", OFFSET(queue_size),
AV_OPT_TYPE_INT, { .i64 = (1024 * 1024 * 1024)}, 0, INT_MAX, DEC, "bytes"},
I'd rather call the option "queue_size", shortened names should be fine
for variables, but for option names we tend to use normal text.
Also please add documentation for it and increase libavdevice micro
version.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_ambisonic.c Added File for Ambisonic Filter
On Mon, Mar 20, 2017 at 2:16 PM, Carl Eugen Hoyos
wrote:
> 2017-03-13 10:15 GMT+01:00 Sanchit Sinha :
> > Sir, I cannot find any tabs in the code.
>
> For the future:
> There is a script in tools/patcheck that helps you with some basic
> issues.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Sanchit Sinha
B.Tech- CSE
IIIT-Delhi
Roll-2015083
https://sinhaaftersanchit.com/
From f01fb13355643d331df4a6bf8ce622a2cdb8568a Mon Sep 17 00:00:00 2001
From: Sanchit Sinha
Date: Tue, 15 Aug 2017 01:36:23 +0530
Subject: [PATCH] PATCH1
Signed-off-by: Sanchit Sinha
---
Changelog | 1 +
libavfilter/Makefile | 1 +
libavfilter/af_ambisonic.c | 732 +
libavfilter/allfilters.c | 1 +
4 files changed, 735 insertions(+)
create mode 100644 libavfilter/af_ambisonic.c
diff --git a/Changelog b/Changelog
index c797d68..e09c48b 100644
--- a/Changelog
+++ b/Changelog
@@ -32,6 +32,7 @@ version :
- unpremultiply video filter
- tlut2 video filter
- floodfill video filter
+- Ambisonic Decoder
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 06b915f..c1ca5ea 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -45,6 +45,7 @@ OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
OBJS-$(CONFIG_ALIMITER_FILTER) += af_alimiter.o
OBJS-$(CONFIG_ALLPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_ALOOP_FILTER) += f_loop.o
+OBJS-$(CONFIG_AMBISONIC_FILTER) += af_ambisonic.o
OBJS-$(CONFIG_AMERGE_FILTER) += af_amerge.o
OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
diff --git a/libavfilter/af_ambisonic.c b/libavfilter/af_ambisonic.c
new file mode 100644
index 000..fa6782d
--- /dev/null
+++ b/libavfilter/af_ambisonic.c
@@ -0,0 +1,732 @@
+/*
+ * Copyright (c) 2017 Sanchit Sinha
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include
+#include
+
+enum FilterType {
+shelf,
+nearfield
+};
+
+enum InputFormat {
+ N3D,
+ SN3D ,
+ FURMUL
+};
+
+enum Rotate {
+TILT ,
+TUMBLE,
+YAW
+};
+
+enum Layouts {
+MONO,
+STEREO ,
+TRIANGLE,
+SQUARE ,
+PENTAGON,
+HEXAGON ,
+HEPTAGON,
+OCTAGON ,
+TETRAHEDRON ,
+OCTAHEDRON ,
+CUBE,
+DODECAHEDRON,
+ICOSAHEDRON
+};
+
+typedef struct Cache {
+double i1, i2;
+double o1, o2;
+} Cache;
+
+/*Decoding matrix for 1st order files. Similar can be done for 2nd, 3rd etc*/
+static const struct {
+ int speakers;
+float matrix[22][15];
+} ambisonic_matrix[]= {
+[MONO]={
+ .speakers=1,
+.matrix={
+{0.22156, 0, 0, 0},
+},
+},
+[TRIANGLE]={
+ .speakers=3,
+.matrix={
+{0.17836, 0.32555, 0.18795, 0},
+{0.17836, 0 ,-0.37591, 0},
+{0.17836,-0.32555, 0.18795, 0},
+},
+},
+[SQUARE]={
+ .speakers=4,
+.matrix={
+{0.39388, 0.18690, 0.18690, 0},
+{0.39388,-0.18690, 0.18690, 0},
+{0.39388,-0.18690,-0.18690, 0},
+{0.39388, 0.18690,-0.18690, 0},
+},
+},
+[PENTAGON]={
+ .speakers=5,
+.matrix={
+{0.20195, 0 , 0.33420, 0},
+{0.11356, 0.2901 , 0.04186, 0},
+{0.19654,-0.07993,-0.34782, 0},
+{0.19654, 0.07993,-0.34782, 0},
+{0.19654,-0.2901 , 0.04186, 0},
+},
+},
+[HEXAGON]={
+ .speakers=6,
+.matrix={
+{0.26259, 0 , 0.31326, 0},
+{0.26259, 0.27129, 0.15663, 0},
+{0.26259, 0.27129, -0.15663, 0},
+{0.26259, 0 , -0.31326, 0},
+{0.26259,-0.27129, -0.15663, 0},
+{0.26259,-0.27129
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/rangecoder: Do not increase the pointer beyond the buffer
On Sun, Aug 13, 2017 at 07:18:11PM -0300, James Almer wrote:
> On 8/13/2017 7:15 PM, Michael Niedermayer wrote:
> > Fixes: undefined behavior
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/rangecoder.c | 1 +
> > libavcodec/rangecoder.h | 8 ++--
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/rangecoder.c b/libavcodec/rangecoder.c
> > index 0bb79c880e..0d53bef076 100644
> > --- a/libavcodec/rangecoder.c
> > +++ b/libavcodec/rangecoder.c
> > @@ -58,6 +58,7 @@ av_cold void ff_init_range_decoder(RangeCoder *c, const
> > uint8_t *buf,
> >
> > c->low = AV_RB16(c->bytestream);
> > c->bytestream += 2;
> > +c->overread= 0;
> > if (c->low >= 0xFF00) {
> > c->low = 0xFF00;
> > c->bytestream_end = c->bytestream;
> > diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
> > index c3e81d0dcb..44af88b8f5 100644
> > --- a/libavcodec/rangecoder.h
> > +++ b/libavcodec/rangecoder.h
> > @@ -42,6 +42,8 @@ typedef struct RangeCoder {
> > uint8_t *bytestream_start;
> > uint8_t *bytestream;
> > uint8_t *bytestream_end;
> > +int overread;
> > +#define MAX_OVERREAD 2
> > } RangeCoder;
> >
> > void ff_init_range_encoder(RangeCoder *c, uint8_t *buf, int buf_size);
> > @@ -106,9 +108,11 @@ static inline void refill(RangeCoder *c)
> > if (c->range < 0x100) {
> > c->range <<= 8;
> > c->low <<= 8;
> > -if (c->bytestream < c->bytestream_end)
> > +if (c->bytestream < c->bytestream_end) {
> > c->low += c->bytestream[0];
> > -c->bytestream++;
> > +c->bytestream++;
> > +} else
> > +c->overread ++;
> > }
> > }
>
> Wouldn't it be better to port this to the bytestream2 reading api?
this is speed relevant code, i am not sure bytestream2 wouldnt add
overhead. In fact i wasnt entirely sure keeping track of the overread
bytes is a great idea. But i didnt see an easy way to avoid that.
[...]
--
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cavsdec: Check I frame mb decode for errors
On Sun, Aug 13, 2017 at 08:38:38PM +0200, Michael Niedermayer wrote: > Fixes: timeout > Fixes: 2943/clusterfuzz-testcase-5430257156882432 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/cavsdec.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
ping? On 2017/8/9 9:39, Jun Zhao wrote: > V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code review. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Check perspective_exp and zrs_exp.
Fixes: undefined shift
Fixes: runtime error: shift exponent 264 is too large for 32-bit type 'int'
Fixes: 2860/clusterfuzz-testcase-minimized-4672811689836544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/diracdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index f2837aca69..be8b282314 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -1161,6 +1161,11 @@ static int
dirac_unpack_prediction_parameters(DiracContext *s)
s->globalmc[ref].perspective[0] = dirac_get_se_golomb(gb);
s->globalmc[ref].perspective[1] = dirac_get_se_golomb(gb);
}
+if (s->globalmc[ref].perspective_exp +
(uint64_t)s->globalmc[ref].zrs_exp > 30) {
+av_log(s->avctx, AV_LOG_ERROR, "exp %d %d too large\n",
s->globalmc[ref].perspective_exp, s->globalmc[ref].zrs_exp);
+return AVERROR_INVALIDDATA;
+}
+
}
}
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/diracdec: Fixes integer overflow
Fixes: runtime error: signed integer overflow: 340018243 * 27 cannot be
represented in type 'int'
Fixes: 2861/clusterfuzz-testcase-minimized-5361070510178304
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/diracdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index be8b282314..82c5c158b5 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -442,7 +442,7 @@ static av_cold int dirac_decode_end(AVCodecContext *avctx)
static inline int coeff_unpack_golomb(GetBitContext *gb, int qfactor, int
qoffset)
{
int coeff = dirac_get_se_golomb(gb);
-const int sign = FFSIGN(coeff);
+const unsigned sign = FFSIGN(coeff);
if (coeff)
coeff = sign*((sign * coeff * qfactor + qoffset) >> 2);
return coeff;
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/rangecoder: Do not increase the pointer beyond the buffer
On 8/14/2017 8:07 PM, Michael Niedermayer wrote:
> On Sun, Aug 13, 2017 at 07:18:11PM -0300, James Almer wrote:
>> On 8/13/2017 7:15 PM, Michael Niedermayer wrote:
>>> Fixes: undefined behavior
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/rangecoder.c | 1 +
>>> libavcodec/rangecoder.h | 8 ++--
>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/rangecoder.c b/libavcodec/rangecoder.c
>>> index 0bb79c880e..0d53bef076 100644
>>> --- a/libavcodec/rangecoder.c
>>> +++ b/libavcodec/rangecoder.c
>>> @@ -58,6 +58,7 @@ av_cold void ff_init_range_decoder(RangeCoder *c, const
>>> uint8_t *buf,
>>>
>>> c->low = AV_RB16(c->bytestream);
>>> c->bytestream += 2;
>>> +c->overread= 0;
>>> if (c->low >= 0xFF00) {
>>> c->low = 0xFF00;
>>> c->bytestream_end = c->bytestream;
>>> diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
>>> index c3e81d0dcb..44af88b8f5 100644
>>> --- a/libavcodec/rangecoder.h
>>> +++ b/libavcodec/rangecoder.h
>>> @@ -42,6 +42,8 @@ typedef struct RangeCoder {
>>> uint8_t *bytestream_start;
>>> uint8_t *bytestream;
>>> uint8_t *bytestream_end;
>>> +int overread;
>>> +#define MAX_OVERREAD 2
>>> } RangeCoder;
>>>
>>> void ff_init_range_encoder(RangeCoder *c, uint8_t *buf, int buf_size);
>>> @@ -106,9 +108,11 @@ static inline void refill(RangeCoder *c)
>>> if (c->range < 0x100) {
>>> c->range <<= 8;
>>> c->low <<= 8;
>>> -if (c->bytestream < c->bytestream_end)
>>> +if (c->bytestream < c->bytestream_end) {
>>> c->low += c->bytestream[0];
>>> -c->bytestream++;
>>> +c->bytestream++;
>>> +} else
>>> +c->overread ++;
>>> }
>>> }
>>
>> Wouldn't it be better to port this to the bytestream2 reading api?
>
> this is speed relevant code, i am not sure bytestream2 wouldnt add
> overhead. In fact i wasnt entirely sure keeping track of the overread
> bytes is a great idea. But i didnt see an easy way to avoid that.
Probably no overhead, since renorm_encoder() can use the unchecked
reader much like it's doing it now.
In any case, the buffer may be both read and written to, which means
you'd have to split things in two to use both the put and get
bytestream2 APIs, so it may not be worth doing (and probably the reason
why it's not already been done in the first place).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
2017-08-15 8:48 GMT+08:00 Jun Zhao : > ping? No Documentation for the coder options? > > On 2017/8/9 9:39, Jun Zhao wrote: >> V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code review. >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/7] avutil/opencl: convert to stdatomic
2017-03-23 7:34 GMT+08:00 James Almer :
> Signed-off-by: James Almer
> ---
> libavutil/opencl.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/opencl.c b/libavutil/opencl.c
> index af35770e06..9b6c8d10d8 100644
> --- a/libavutil/opencl.c
> +++ b/libavutil/opencl.c
> @@ -29,7 +29,7 @@
>
> #if HAVE_THREADS
> #include "thread.h"
> -#include "atomic.h"
> +#include
>
> static pthread_mutex_t * volatile atomic_opencl_lock = NULL;
> #define LOCK_OPENCL pthread_mutex_lock(atomic_opencl_lock)
> @@ -351,13 +351,14 @@ static inline int init_opencl_mtx(void)
> if (!atomic_opencl_lock) {
> int err;
> pthread_mutex_t *tmp = av_malloc(sizeof(pthread_mutex_t));
> +const pthread_mutex_t *cmp = NULL;
> if (!tmp)
> return AVERROR(ENOMEM);
> if ((err = pthread_mutex_init(tmp, NULL))) {
> av_free(tmp);
> return AVERROR(err);
> }
> -if (avpriv_atomic_ptr_cas((void * volatile *)&atomic_opencl_lock,
> NULL, tmp)) {
> +if (!atomic_compare_exchange_strong(&atomic_opencl_lock, &cmp,
> tmp)) {
> pthread_mutex_destroy(tmp);
> av_free(tmp);
> }
> --
> 2.12.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi
Looks good to me, thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
On 2017/8/15 10:41, Steven Liu wrote: > 2017-08-15 8:48 GMT+08:00 Jun Zhao : >> ping? > No Documentation for the coder options? Do you means man page or the other docs ? >> >> On 2017/8/9 9:39, Jun Zhao wrote: >>> V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code >>> review. >>> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
2017-08-15 11:23 GMT+08:00 Jun Zhao : > > > On 2017/8/15 10:41, Steven Liu wrote: >> 2017-08-15 8:48 GMT+08:00 Jun Zhao : >>> ping? >> No Documentation for the coder options? > > Do you means man page or the other docs ? doc/encoders.texi This one. > >>> >>> On 2017/8/9 9:39, Jun Zhao wrote: V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code review. >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
2017-08-15 11:33 GMT+08:00 Steven Liu :
> 2017-08-15 11:23 GMT+08:00 Jun Zhao :
>>
>>
>> On 2017/8/15 10:41, Steven Liu wrote:
>>> 2017-08-15 8:48 GMT+08:00 Jun Zhao :
ping?
>>> No Documentation for the coder options?
>>
>> Do you means man page or the other docs ?
> doc/encoders.texi
> This one.
>>
On 2017/8/9 9:39, Jun Zhao wrote:
> V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code
> review.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
From 28e4dc3533be2b7c7493a08de7143c042c9923c1 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 8 Aug 2017 03:33:53 -0400
Subject: [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support
Follow libx264 style to support coder option, default is
enabled cabac.
Signed-off-by: Yi A Wang
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h264.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f9fcd805a4..4e1df182a0 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -168,6 +168,8 @@ typedef struct VAAPIEncodeH264Options {
int qp;
int quality;
int low_power;
+// Entropy encoder type
+int coder;
} VAAPIEncodeH264Options;
@@ -783,6 +785,8 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
VAEncPictureParameterBufferH264 *vpic = ctx->codec_picture_params;
VAAPIEncodeH264Context*priv = ctx->priv_data;
VAAPIEncodeH264MiscSequenceParams *mseq = &priv->misc_sequence_params;
+VAAPIEncodeH264Options *opt =
+(VAAPIEncodeH264Options*)ctx->codec_options_data;
int i;
{
@@ -927,8 +931,12 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
vpic->num_ref_idx_l0_active_minus1 = 0;
vpic->num_ref_idx_l1_active_minus1 = 0;
-vpic->pic_fields.bits.entropy_coding_mode_flag =
-((avctx->profile & 0xff) != 66);
+if (opt->coder) {
+vpic->pic_fields.bits.entropy_coding_mode_flag =
+((avctx->profile & 0xff) != 66);
+} else {
+vpic->pic_fields.bits.entropy_coding_mode_flag = 0;
+}
What about write like this?
vpic->pic_fields.bits.entropy_coding_mode_flag = opt->coder ?
(avctx->profile & 0xff) != 66 : 0;
vpic->pic_fields.bits.weighted_pred_flag = 0;
vpic->pic_fields.bits.weighted_bipred_idc = 0;
vpic->pic_fields.bits.transform_8x8_mode_flag =
@@ -1283,6 +1291,12 @@ static const AVOption vaapi_encode_h264_options[] = {
{ "low_power", "Use low-power encoding mode (experimental: only supported "
"on some platforms, does not support all features)",
OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
+{ "coder", "Entropy coder type",
+ OFFSET(coder), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS, "coder" },
+{ "cavlc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN,
INT_MAX, FLAGS, "coder" },
+{ "cabac", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN,
INT_MAX, FLAGS, "coder" },
+{ "vlc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN,
INT_MAX, FLAGS, "coder" },
+{ "ac",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN,
INT_MAX, FLAGS, "coder" },
{ NULL },
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
