[FFmpeg-devel] [PATCH] avfilter/lavfutils: use image2pipe demuxer on ff_load_image
allow protocols other than file to be used
for example, use data protocol to embed a file in script
Signed-off-by: Muhammad Faiz
---
libavfilter/lavfutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/lavfutils.c b/libavfilter/lavfutils.c
index 706badf..35878b3 100644
--- a/libavfilter/lavfutils.c
+++ b/libavfilter/lavfutils.c
@@ -38,7 +38,7 @@ int ff_load_image(uint8_t *data[4], int linesize[4],
av_register_all();
-iformat = av_find_input_format("image2");
+iformat = av_find_input_format("image2pipe");
if ((ret = avformat_open_input(&format_ctx, filename, iformat, NULL)) < 0)
{
av_log(log_ctx, AV_LOG_ERROR,
"Failed to open input file '%s'\n", filename);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Fix libopus detection
2017-04-13 1:08 GMT+02:00 Carl Eugen Hoyos :
> 2017-03-30 1:52 GMT+02:00 James Almer :
>> On 3/29/2017 7:47 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch fixes a compilation error here.
>>>
>>> Please test for success, Carl Eugen
>>>
>>>
>>> 0001-configure-Fix-libopus-detection.patch
>>>
>>>
>>> From 600b568651c60f8de609f211c814b5cd0640e584 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos
>>> Date: Thu, 30 Mar 2017 00:45:06 +0200
>>> Subject: [PATCH] configure: Fix libopus detection.
>>>
>>> Avoids a compilation error for old libopus.
>>> Regression since 37941878
>>> ---
>>> configure |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index a84b126..76a287e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5797,7 +5797,7 @@ enabled libopenjpeg && { { check_lib
>>> openjpeg-2.1/openjpeg.h opj_version -
>>> { check_lib openjpeg.h opj_version
>>> -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
>>> die "ERROR: libopenjpeg not found"; }
>>> enabled libopenmpt&& require_pkg_config "libopenmpt >= 0.2.6557"
>>> libopenmpt/libopenmpt.h openmpt_module_create
>>> -enabled libopus && require_pkg_config opus opus_multistream.h
>>> opus_multistream_decoder_create
>>> +enabled libopus && require_pkg_config opus opus_multistream.h
>>> opus_multistream_surround_encoder_create
>>
>> Should be ok,
>
>> but strictly speaking, this function is needed by the
>> encoder and not the decoder. Something like
>>
>> enabled libopus && {
>> enabled libopus_decoder && {
>> require_pkg_config opus opus_multistream.h
>> opus_multistream_decoder_create
>> }
>> enabled libopus_encoder && {
>> use_pkg_config "opus >= 1.1" opus_multistream.h
>> opus_multistream_surround_encoder_create ||
>> disable libopus_encoder;
>> }
>> }
>
> Please commit this if you prefer it.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining
On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote: > On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote: >> This is needed to get compatibility with the behavior before the >> recent decode.c restructuring merge, and fixes fate failures with >> this: >> >> make fate-h264-attachment-631 THREADS=32 >> >> For every 4 threads, a frame is dropped at the point at which >> draining is initialized. The problem starts at THREADS=4. >> >> This patch "fixes" it by ignoring errors during draining (if there >> is a frame to be returned), but there is probably a deeper cause >> and/or a better fix for this. I haven't looked closer at this, but >> was asked to send this patch for discussion. >> --- >> libavcodec/pthread_frame.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >> index 13d682842d..e7fa503adf 100644 >> --- a/libavcodec/pthread_frame.c >> +++ b/libavcodec/pthread_frame.c >> @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx, >> fctx->next_finished = finished; >> >> /* return the size of the consumed packet if no error occurred */ >> -if (err >= 0) >> +if (err >= 0 || (!avpkt->size && *got_picture_ptr)) > > Probably (*got_picture_ptr && p->result >= 0) > So error is not ignored. > Isnt the entire point of this to ignore errors during draining? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
On Mon, Apr 24, 2017 at 11:59 PM, James Almer wrote: > On 4/24/2017 6:48 PM, KongQun Yang wrote: >> -- KongQun Yang (KQ) >> >> On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes >> wrote: >> >>> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes >>> wrote: This brings our generation of the vpcC box up to date to version 1.0 of the VP Codec ISO Media File Format Binding. Specifically, color/transfer properties are now written with values based on ISO/IEC 23001-8, which is the same reference specification the AVColor* enumerations are based on. --- libavformat/movenc.c | 3 ++- libavformat/vpcc.c | 55 +- >>> -- 2 files changed, 7 insertions(+), 51 deletions(-) >>> >>> Actually I should probably update the main commit message to mention >>> that its v1.0 and not a draft any longer? >>> >> >> SGTM. Should we remove the experimental check as well: >> https://github.com/FFmpeg/FFmpeg/blob/b905ba5bc18c89c7fccd862179575562ef19/libavformat/movenc.c#L5989 >> ? > > IMO yes, assuming the vpcc boxes generated after this patch are 100% > v1.0 compliant. The vpcC bos is compliant, but I have no idea if anything else in the muxer is required to create fully compliant files. I randomy stumbled upon the vpcC generation and figured I would update it, I'm not that well versed in movenc otherwise. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Ignore expired cookies
On Sat, Apr 08, 2017 at 09:05:46PM -0400, Micah Galizia wrote:
> Signed-off-by: Micah Galizia
> ---
> libavformat/http.c | 211
> ++---
> 1 file changed, 154 insertions(+), 57 deletions(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 293a8a7204..425711aab5 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -29,6 +29,7 @@
> #include "libavutil/avstring.h"
> #include "libavutil/opt.h"
> #include "libavutil/time.h"
> +#include "libavutil/parseutils.h"
>
> #include "avformat.h"
> #include "http.h"
> @@ -48,6 +49,8 @@
> #define MAX_REDIRECTS 8
> #define HTTP_SINGLE 1
> #define HTTP_MUTLI2
> +#define MAX_EXPIRY19
> +#define WHITESPACES " \n\t\r"
> typedef enum {
> LOWER_PROTO,
> READ_HEADERS,
> @@ -680,10 +683,109 @@ static int parse_icy(HTTPContext *s, const char *tag,
> const char *p)
> return 0;
> }
>
> +static int parse_set_cookie_expiry_time(const char *exp_str, struct tm *buf)
> +{
> +char exp_buf[MAX_EXPIRY];
> +int i, j, exp_buf_len = MAX_EXPIRY-1;
> +char *expiry;
> +
> +// strip off any punctuation or whitespace
> +for (i = 0, j = 0; exp_str[i] != '\0' && j < exp_buf_len; i++) {
> +if ((exp_str[i] >= '0' && exp_str[i] <= '9') ||
> +(exp_str[i] >= 'A' && exp_str[i] <= 'Z') ||
> +(exp_str[i] >= 'a' && exp_str[i] <= 'z')) {
> +exp_buf[j] = exp_str[i];
> +j++;
> +}
> +}
> +exp_buf[j] = '\0';
> +expiry = exp_buf;
> +
> +// move the string beyond the day of week
> +while ((*expiry < '0' || *expiry > '9') && *expiry != '\0')
> +expiry++;
> +
> +return av_small_strptime(expiry, "%d%b%Y%H%M%S", buf) ? 0 :
> AVERROR(EINVAL);
> +}
> +
> +static int parse_set_cookie(const char *set_cookie, AVDictionary **dict)
> +{
> +char *param, *next_param, *cstr, *back;
> +
> +if (!(cstr = av_strdup(set_cookie)))
> +return AVERROR(EINVAL);
> +
> +// strip any trailing whitespace
> +back = &cstr[strlen(cstr)-1];
> +while (strchr(WHITESPACES, *back)) {
> +*back='\0';
> +back--;
> +}
> +
> +next_param = cstr;
> +while ((param = av_strtok(next_param, ";", &next_param))) {
> +char *name, *value;
> +param += strspn(param, WHITESPACES);
> +if ((name = av_strtok(param, "=", &value))) {
> +av_dict_set(dict, name, value, 0);
missing failure check
also if you get no reviewes of patches and are interrested in
the code, try to suggest to help with maintaining it, if noone objects
send a patch that adds you to MAINTAINERs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining
On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote: > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote: >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote: >>> This is needed to get compatibility with the behavior before the >>> recent decode.c restructuring merge, and fixes fate failures with >>> this: >>> >>> make fate-h264-attachment-631 THREADS=32 >>> >>> For every 4 threads, a frame is dropped at the point at which >>> draining is initialized. The problem starts at THREADS=4. >>> >>> This patch "fixes" it by ignoring errors during draining (if there >>> is a frame to be returned), but there is probably a deeper cause >>> and/or a better fix for this. I haven't looked closer at this, but >>> was asked to send this patch for discussion. >>> --- >>> libavcodec/pthread_frame.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >>> index 13d682842d..e7fa503adf 100644 >>> --- a/libavcodec/pthread_frame.c >>> +++ b/libavcodec/pthread_frame.c >>> @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx, >>> fctx->next_finished = finished; >>> >>> /* return the size of the consumed packet if no error occurred */ >>> -if (err >= 0) >>> +if (err >= 0 || (!avpkt->size && *got_picture_ptr)) >> >> Probably (*got_picture_ptr && p->result >= 0) >> So error is not ignored. >> > > Isnt the entire point of this to ignore errors during draining? wm4 stated that probably there is a better fix, and not ignoring error is a better fix. My point is that when a frame is retuned, propagate error from the thread that return it, not from another thread. More clearly if (*got_picture_ptr) err = p->result ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/exr : fix pix_fmt for pxr24 half/uint32
On Sat, Apr 22, 2017 at 06:43:54PM +0200, Martin Vignali wrote: > > > > How does it fix it ? > > if it doesnt contain alpha but tests alpha thats a bit odd and may > > test things that otherwise wouldnt be tested. > > But "fix" sounds like theres something wrong, not just odd > > Can you clarify/elaborate ? > > > > thx > > > > > Hello, > > I made a copy and paste of a previous line when i create this fate test > The original sample, doesn't have alpha, so testing an rgba output doesn't > seems right, for a decoder fate test. > > If i build ffmpeg with a configure line made to just enable exr > decoding/framecrc (in other word, just to check exr fate test), this test > fail. > So seems to be more clean, to use the right pixel format here. > > If you think it's necessary to test rgb48 to rgba64 conversion, IMHO > another fate test need to be created just for that, with different > dependancy patch applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : fix float to uint16 conversion for negative value
On Sun, Apr 23, 2017 at 06:00:06PM +0200, Martin Vignali wrote:
> Hello,
>
> In attach a patch who fix this sample :
> https://we.tl/HWgF0SFEll
>
> This sample contain negative value in the red channel.
>
> Before this patch, negative red float are converted to max red
> instead of zero.
>
> The previous hack doesn't seems to work for float to uint
> so i add an explicit sign check
>
> but i'm not familiar with float binary manipulation,
> so maybe there is a better way to fix the problem
>
> Comments welcome
>
> Martin
> Jokyo Images
> exr.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 99febb919a36ca28f2fd2500cd820f5ec75ebeb0
> 0002-libavcodec-exr-fix-float-to-uint16-conversion-for-ne.patch
> From 5385ed8d8d258e68474e3ff24b601fd9ae595677 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sun, 23 Apr 2017 17:57:53 +0200
> Subject: [PATCH 2/2] libavcodec/exr : fix float to uint16 conversion for
> negative value
>
> the previous hack doesn't seems to work
> so add an explicit sign check
> ---
> libavcodec/exr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 7194640..0e69a8d 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -223,9 +223,9 @@ static union av_intfloat32 exr_half2float(uint16_t hf)
> static inline uint16_t exr_flt2uint(uint32_t v)
> {
> unsigned int exp = v >> 23;
> -// "HACK": negative values result in exp< 0, so clipping them to 0
> -// is also handled by this condition, avoids explicit check for sign bit.
> -if (exp <= 127 + 7 - 24) // we would shift out all bits anyway
> +if (v >> 31 == 1)/* clamp negative value to 0*/
> +return 0;
> +if (exp <= 127 + 7 - 24)
> return 0;
did you try to make exp int32_t to avoid the 2nd check ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : fix piz uncompress on big endian
On Sun, Apr 23, 2017 at 03:41:43PM +0200, Martin Vignali wrote: > > > > There is bswap dsp function that runs on array of bytes. > > > > Thanks for your answer > > New patch in attach, using bswapdsp. > I only enable bswapdsp on big endian, no need for it on little endian. > > Martin > exr.c | 28 +++- > 1 file changed, 23 insertions(+), 5 deletions(-) > a85383d363521149bd11b70603b4520480e76d05 > 0001-libavcodec-exr-fix-piz-uncompress-on-big-endian.patch > From e4837a8e57e01958d04f41d8ecb668b90db4fb38 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sun, 23 Apr 2017 15:38:14 +0200 > Subject: [PATCH] libavcodec/exr : fix piz uncompress on big endian Tested-by: michael on qemu mips [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] NVENC Surface Allocation Reduction
> From f3917a452c3e0636c27876e84a4e3b57bb78dae5 Mon Sep 17 00:00:00 2001
> From: Ben Chang
> Date: Wed, 19 Apr 2017 13:07:31 -0700
> Subject: [PATCH] NVENC surface allocation reduction
>
> This patch aims to reduce the number of input/output surfaces
> NVENC allocates per session. Previous default sets allocated surfaces to 32
> (unless there is user specified param or lookahead involved). Having large
> number of surfaces consumes extra video memory (esp for higher resolution
> encoding). The patch changes the surfaces calculation for default, B-frames,
> lookahead scenario respectively.
>
> The other change involves surface selection. Previously, if a session
> allocates x surfaces, only x-1 surfaces are used (due to combination
> of output delay and lock toggle logic). To prevent unused surfaces,
> changing surface rotation to using predefined fifo.
> ---
> libavcodec/nvenc.c | 56
> ++---
> libavcodec/nvenc.h | 1 +
> libavcodec/nvenc_h264.c | 4 ++--
> libavcodec/nvenc_hevc.c | 4 ++--
> 4 files changed, 44 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index cf05455..0a1b290 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -644,16 +644,34 @@ static void nvenc_override_rate_control(AVCodecContext
> *avctx)
> static av_cold int nvenc_recalc_surfaces(AVCodecContext *avctx)
> {
> NvencContext *ctx = avctx->priv_data;
> -int nb_surfaces = 0;
> +// default minimum of 4 surfaces
Did you test if and how much it affects performance to reduce the default delay
from 32 to 4?
This was originally done because nvenc is extremely slow if you try to download
the frames without some delay headroom.
> +// *2 for number of NVENCs, *2 for avoid blocking next PBB group
What do you mean by "*2 for number of NVENCs"?
> +int nb_surfaces = FFMAX(4, ctx->encode_config.frameIntervalP * 2 * 2);
>
> +// lookahead enabled
> if (ctx->rc_lookahead > 0) {
> -nb_surfaces = ctx->rc_lookahead +
> ((ctx->encode_config.frameIntervalP > 0) ? ctx->encode_config.frameIntervalP
> : 0) + 1 + 4;
> -if (ctx->nb_surfaces < nb_surfaces) {
> +// +1 is to account for lkd_bound calculation later
> +// +4 is to allow sufficient pipelining with lookahead
> +nb_surfaces = FFMAX(1, FFMAX(nb_surfaces, ctx->rc_lookahead +
> ctx->encode_config.frameIntervalP + 1 + 4));
> +if ((nb_surfaces > ctx->nb_surfaces) && (ctx->nb_surfaces > 0))
Pointless braces
> +{
> av_log(avctx, AV_LOG_WARNING,
> "Defined rc_lookahead requires more surfaces, "
> "increasing used surfaces %d -> %d\n", ctx->nb_surfaces,
> nb_surfaces);
> -ctx->nb_surfaces = nb_surfaces;
> }
> +ctx->nb_surfaces = FFMAX(nb_surfaces, ctx->nb_surfaces);
> +}
> +else {
Should be on one line.
> +if ((ctx->encode_config.frameIntervalP > 1) && (ctx->nb_surfaces <
> nb_surfaces) && (ctx->nb_surfaces > 0))
Pointless braces
> +{
> +av_log(avctx, AV_LOG_WARNING,
> + "Defined b-frame requires more surfaces, "
> + "increasing used surfaces %d -> %d\n", ctx->nb_surfaces,
> nb_surfaces);
> +ctx->nb_surfaces = FFMAX(ctx->nb_surfaces, nb_surfaces);
> +}
> +else if (!(ctx->nb_surfaces > 0))
Why not just <= 0?
> +ctx->nb_surfaces = nb_surfaces;
> +// otherwise use user specified value
> }
>
> ctx->nb_surfaces = FFMAX(1, FFMIN(MAX_REGISTERED_FRAMES,
> ctx->nb_surfaces));
> @@ -1121,8 +1139,6 @@ static av_cold int nvenc_alloc_surface(AVCodecContext
> *avctx, int idx)
> ctx->surfaces[idx].height = allocSurf.height;
> }
>
> -ctx->surfaces[idx].lockCount = 0;
> -
> /* 1MB is large enough to hold most output frames.
> * NVENC increases this automaticaly if it is not enough. */
> allocOut.size = 1024 * 1024;
> @@ -1141,6 +1157,9 @@ static av_cold int nvenc_alloc_surface(AVCodecContext
> *avctx, int idx)
> ctx->surfaces[idx].output_surface = allocOut.bitstreamBuffer;
> ctx->surfaces[idx].size = allocOut.size;
>
> +NvencSurface* tmp = &ctx->surfaces[idx];
Mixed code and declaration.
Also, I'd prefer a less generic name, like tmp_surface.
> +av_fifo_generic_write(ctx->IO_surface_queue, &tmp,
> sizeof(NvencSurface*), NULL);
For safety and consistency, I'd prefer to have just sizeof(tmp).
> +
> return 0;
> }
>
> @@ -1156,6 +1175,11 @@ static av_cold int nvenc_setup_surfaces(AVCodecContext
> *avctx)
> ctx->timestamp_list = av_fifo_alloc(ctx->nb_surfaces * sizeof(int64_t));
> if (!ctx->timestamp_list)
> return AVERROR(ENOMEM);
> +
> +ctx->IO_surface_queue = av_fifo_alloc(ctx->nb_surfaces *
> sizeof(NvencSurface*));
> +if (!ctx->IO_surface_queue)
> +return AVERROR(ENOMEM);
> +
>
Re: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining
On Tue, 25 Apr 2017 17:29:10 +0700 Muhammad Faiz wrote: > On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote: > > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote: > >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote: > >>> This is needed to get compatibility with the behavior before the > >>> recent decode.c restructuring merge, and fixes fate failures with > >>> this: > >>> > >>> make fate-h264-attachment-631 THREADS=32 > >>> > >>> For every 4 threads, a frame is dropped at the point at which > >>> draining is initialized. The problem starts at THREADS=4. > >>> > >>> This patch "fixes" it by ignoring errors during draining (if there > >>> is a frame to be returned), but there is probably a deeper cause > >>> and/or a better fix for this. I haven't looked closer at this, but > >>> was asked to send this patch for discussion. > >>> --- > >>> libavcodec/pthread_frame.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c > >>> index 13d682842d..e7fa503adf 100644 > >>> --- a/libavcodec/pthread_frame.c > >>> +++ b/libavcodec/pthread_frame.c > >>> @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx, > >>> fctx->next_finished = finished; > >>> > >>> /* return the size of the consumed packet if no error occurred */ > >>> -if (err >= 0) > >>> +if (err >= 0 || (!avpkt->size && *got_picture_ptr)) > >> > >> Probably (*got_picture_ptr && p->result >= 0) > >> So error is not ignored. > >> > > > > Isnt the entire point of this to ignore errors during draining? > > wm4 stated that probably there is a better fix, and not ignoring error > is a better fix. > My point is that when a frame is retuned, propagate error from the > thread that return it, > not from another thread. More clearly > if (*got_picture_ptr) err = p->result Can you send a patch for this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
On 4/25/2017 6:11 AM, Hendrik Leppkes wrote: > On Mon, Apr 24, 2017 at 11:59 PM, James Almer wrote: >> On 4/24/2017 6:48 PM, KongQun Yang wrote: >>> -- KongQun Yang (KQ) >>> >>> On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes >>> wrote: >>> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes wrote: > This brings our generation of the vpcC box up to date to version 1.0 > of the VP Codec ISO Media File Format Binding. > > Specifically, color/transfer properties are now written with values > based on ISO/IEC 23001-8, which is the same reference specification the > AVColor* enumerations are based on. > --- > libavformat/movenc.c | 3 ++- > libavformat/vpcc.c | 55 +- -- > 2 files changed, 7 insertions(+), 51 deletions(-) > Actually I should probably update the main commit message to mention that its v1.0 and not a draft any longer? >>> >>> SGTM. Should we remove the experimental check as well: >>> https://github.com/FFmpeg/FFmpeg/blob/b905ba5bc18c89c7fccd862179575562ef19/libavformat/movenc.c#L5989 >>> ? >> >> IMO yes, assuming the vpcc boxes generated after this patch are 100% >> v1.0 compliant. > > The vpcC bos is compliant, but I have no idea if anything else in the > muxer is required to create fully compliant files. I randomy stumbled > upon the vpcC generation and figured I would update it, I'm not that > well versed in movenc otherwise. Don't think so. Should be good as is. You could set "VPC Coding" as compressor name in find_compressor(), but it's optional. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Reviewing merges
On 4/24/2017 3:27 PM, Michael Niedermayer wrote: > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote: >> On 4/23/2017 11:07 PM, Michael Niedermayer wrote: >>> Hi all >>> >>> Should changes ported from libav (what we call merges) be reviewed >>> before being pushed? >> >> The lot of merges are simple things like "Fix this bug that was already >> fixed in ffmpeg months ago", "K&R", etc. Lately we are even no-oping a >> good amount of them as they don't even apply. > >> Only a small set of merges are big API changes, and those are always >> handled by more than one developer, either by reviewing the changes, >> testing them or by helping getting the thing working. And of course, any >> bug that was not caught before pushing is fixed afterwards. >> In fact, it should be noted that if they are initially skipped for >> requiring more thought and for blocking unrelated merges, when we get >> them working at a latter point we always send them to the ML instead of >> simply pushing them. > > yes > > could you send more changes to the ML instead of just ones > initially skiped ? (and of course i dont mean trivial / clearly correct > stuff) If I'm the one merging some change that has considerable chances of introducing regressions, then sure. > > More eyes may catch more issues also i belive its important that we > all see the changes being done, we all have to maintain the code > which interacts with these changes. > > > [...] > >> We have recently been able to go through six hundred or so commits in a >> month or two this way after being stuck for the longest time by a few of >> those big API changes. If we start requiring every commit to go through >> a review process on the ML then we will never catch up with the backlog. >> In short, things as they are right now are smooth. Changing it will only >> make this slower. > > Maybe, but is merging more faster also better for FFmpeg ? Not being one thousand commits behind is. If someone wants to submit something to both projects and find code or a framework they depend on isn't in one, then they will not submit it to that project. > I did not analyze the bugs on our bug tracker but subjectivly the > number of regressions seems much larger than a year or 2 ago. > and i just yesterday found 2 issues in a merge (which you fixed) > > >> >> That aside, may i ask what prompted this question? Did someone complain >> to you privately? No merge recently seems to have broken anything that >> hasn't been already fixed, beyond one threading bug that's being >> investigated right now, so i wonder why ask this now. > > It was on my mind since a long time. I guess the recent surge of merges > and the uneasiness of doing the 3.3 release in the middle kind of was > bringing it up into relevance again. > Before that with the merges falling behind, multiple libav developers > did sent patches to ffmpeg-devel which passed through review on our > codebase before application. The merges restarting stoped this it > seems. > I strongly belive that libav developers sending patches to ffmpeg > and thus the author of a change testing it on top of ffmpeg results > in better code than if its merged by a 3rd party. Of course, and said developers should ideally be encouraged to keep doing it instead of saying "oh, they'll merge it". If they wanted to contribute when merges were almost at a standstill, they can still contribute and make the job of the people handling the merges easier. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: make ff_framequeue_skip_samples() more useful.
Hi, On Sun, Jan 29, 2017 at 11:54 AM, Nicolas George wrote: > > Le decadi 10 pluviôse, an CCXXV, Muhammad Faiz a écrit : > > LGTM > > Thanks, pushed. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Forwarding here so it doesn't get lost in trac. It appears that this patch caused a bug: https://trac.ffmpeg.org/ticket/6349#comment:3 Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] pthread_frame: set err from the thread that return frame
when frame is received, not from other threads. Should fix fate failure with THREADS>=4: make fate-h264-attachment-631 THREADS=4 Signed-off-by: Muhammad Faiz --- libavcodec/pthread_frame.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index 13d6828..c452ed7 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -547,6 +547,10 @@ int ff_thread_decode_frame(AVCodecContext *avctx, fctx->next_finished = finished; +/* if frame is returned, properly set err from the thread that return frame */ +if (*got_picture_ptr) +err = p->result; + /* return the size of the consumed packet if no error occurred */ if (err >= 0) err = avpkt->size; -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining
On Tue, Apr 25, 2017 at 6:58 PM, wm4 wrote: > On Tue, 25 Apr 2017 17:29:10 +0700 > Muhammad Faiz wrote: > >> On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote: >> > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote: >> >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote: >> >>> This is needed to get compatibility with the behavior before the >> >>> recent decode.c restructuring merge, and fixes fate failures with >> >>> this: >> >>> >> >>> make fate-h264-attachment-631 THREADS=32 >> >>> >> >>> For every 4 threads, a frame is dropped at the point at which >> >>> draining is initialized. The problem starts at THREADS=4. >> >>> >> >>> This patch "fixes" it by ignoring errors during draining (if there >> >>> is a frame to be returned), but there is probably a deeper cause >> >>> and/or a better fix for this. I haven't looked closer at this, but >> >>> was asked to send this patch for discussion. >> >>> --- >> >>> libavcodec/pthread_frame.c | 2 +- >> >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >>> >> >>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >> >>> index 13d682842d..e7fa503adf 100644 >> >>> --- a/libavcodec/pthread_frame.c >> >>> +++ b/libavcodec/pthread_frame.c >> >>> @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx, >> >>> fctx->next_finished = finished; >> >>> >> >>> /* return the size of the consumed packet if no error occurred */ >> >>> -if (err >= 0) >> >>> +if (err >= 0 || (!avpkt->size && *got_picture_ptr)) >> >> >> >> Probably (*got_picture_ptr && p->result >= 0) >> >> So error is not ignored. >> >> >> > >> > Isnt the entire point of this to ignore errors during draining? >> >> wm4 stated that probably there is a better fix, and not ignoring error >> is a better fix. >> My point is that when a frame is retuned, propagate error from the >> thread that return it, >> not from another thread. More clearly >> if (*got_picture_ptr) err = p->result > > Can you send a patch for this? posted thx ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add float_dsp tests
On 4/11/2017 6:11 PM, James Almer wrote: > This is a port of libavutil/tests/float_dsp.c > > Signed-off-by: James Almer > --- > tests/checkasm/Makefile| 1 + > tests/checkasm/checkasm.c | 20 +++ > tests/checkasm/checkasm.h | 4 + > tests/checkasm/float_dsp.c | 302 > + > tests/fate/checkasm.mak| 1 + > 5 files changed, 328 insertions(+) > create mode 100644 tests/checkasm/float_dsp.c Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskadec: export Content Light Level metadata
Based on a patch by Hendrik Leppkes
Signed-off-by: James Almer
---
libavformat/matroskadec.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 47873cccd8..fa786a8457 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1869,6 +1869,21 @@ static int mkv_parse_video_color(AVStream *st, const
MatroskaTrack *track) {
avcodec_chroma_pos_to_enum((color->chroma_siting_horz - 1) << 7,
(color->chroma_siting_vert - 1) << 7);
}
+if (color->max_cll && color->max_fall) {
+size_t size = 0;
+int ret;
+AVContentLightMetadata *metadata =
av_content_light_metadata_alloc(&size);
+if (!metadata)
+return AVERROR(ENOMEM);
+ret = av_stream_add_side_data(st, AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
(uint8_t *)metadata,
+ size);
+if (ret < 0) {
+av_freep(&metadata);
+return ret;
+}
+metadata->MaxCLL = color->max_cll;
+metadata->MaxFALL = color->max_fall;
+}
if (has_mastering_primaries || has_mastering_luminance) {
// Use similar rationals as other standards.
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for writing Content Light Level elements
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 9c7a213db9..f14936e3d2 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -844,8 +844,7 @@ static int mkv_write_video_color(AVIOContext *pb,
AVCodecParameters *par, AVStre
uint8_t *colorinfo_ptr;
int side_data_size = 0;
int ret, colorinfo_size;
-const uint8_t *side_data = av_stream_get_side_data(
-st, AV_PKT_DATA_MASTERING_DISPLAY_METADATA, &side_data_size);
+const uint8_t *side_data;
ret = avio_open_dyn_buf(&dyn_cp);
if (ret < 0)
@@ -876,6 +875,18 @@ static int mkv_write_video_color(AVIOContext *pb,
AVCodecParameters *par, AVStre
put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ, (xpos >>
7) + 1);
put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT, (ypos >>
7) + 1);
}
+
+side_data = av_stream_get_side_data(st, AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
+&side_data_size);
+if (side_data_size) {
+const AVContentLightMetadata *metadata =
+(const AVContentLightMetadata*)side_data;
+put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOCOLORMAXCLL, metadata->MaxCLL);
+put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOCOLORMAXFALL,
metadata->MaxFALL);
+}
+
+side_data = av_stream_get_side_data(st,
AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
+&side_data_size);
if (side_data_size == sizeof(AVMasteringDisplayMetadata)) {
ebml_master meta_element = start_ebml_master(
dyn_cp, MATROSKA_ID_VIDEOCOLORMASTERINGMETA, 0);
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: set err from the thread that return frame
On Tue, 25 Apr 2017 23:52:04 +0700 Muhammad Faiz wrote: > when frame is received, not from other threads. > > Should fix fate failure with THREADS>=4: > make fate-h264-attachment-631 THREADS=4 > > Signed-off-by: Muhammad Faiz > --- > libavcodec/pthread_frame.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c > index 13d6828..c452ed7 100644 > --- a/libavcodec/pthread_frame.c > +++ b/libavcodec/pthread_frame.c > @@ -547,6 +547,10 @@ int ff_thread_decode_frame(AVCodecContext *avctx, > > fctx->next_finished = finished; > > +/* if frame is returned, properly set err from the thread that return > frame */ > +if (*got_picture_ptr) > +err = p->result; > + > /* return the size of the consumed packet if no error occurred */ > if (err >= 0) > err = avpkt->size; Well, the logic confuses me. Does this override an earlier set err value? Could err be set to the correct value in the first place (inside of the loop)? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : fix float to uint16 conversion for negative value
> > did you try to make exp int32_t to avoid the 2nd check ? > > [...] > New patch in attach, with exp (and v) in int32_t Also fix the sample for me Martin 0001-libavcodec-exr-fix-float-to-uint16-conversion-for-ne.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] NVENC Surface Allocation Reduction
Hi Timo,
Thanks for the review. Attaching patch updated with your suggestions and
answering some queries from previous email.
>Did you test if and how much it affects performance to reduce the default
>delay from 32 to 4?
>This was originally done because nvenc is extremely slow if you try to
>download the frames without some delay headroom.
I have not seen drop in perf on windows in various scenarios (encode only, cpu
-> nvenc transcode, nvdec -> nvenc transcode) on several gpu arch (Kepler,
Maxwell, and Pascal). In fact, in some cases, the perf increases (by 1-2 fps).
I am using the fps # reported by ffmpeg in most cases. Reducing number of
surfaces effectively reduces the output delay (async_depth) which I believe is
why there is a decrease in encode/transcode time.
> What do you mean by "*2 for number of NVENCs"?
This is a hardcoded value for the number of NVENCs present on a GPU. Commercial
gpu can have up to two (most of the time). There is no support yet to inquire
number of NVENCs present on gpu with api. I have changed the comment to
"multiply by 2 for number of NVENCs on gpu (hardcode to 2)" for more clear
wording.
>> --- a/libavcodec/nvenc_h264.c
>> +++ b/libavcodec/nvenc_h264.c
>> @@ -79,8 +79,8 @@ static const AVOption options[] = {
>> 0,
>> AV_OPT_TYPE_CONST, { .i64 = NV_ENC_PARAMS_RC_2_PASS_FRAMESIZE_CAP },
>> 0, 0, VE, "rc" },
>> { "vbr_2pass","Multi-pass variable bitrate mode", 0,
>> AV_OPT_TYPE_CONST, { .i64 = NV_ENC_PARAMS_RC_2_PASS_VBR },
>> 0, 0, VE, "rc" },
>> { "rc-lookahead", "Number of frames to look ahead for rate-control",
>> -
>> OFFSET(rc_lookahead), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, VE },
>> -{ "surfaces", "Number of concurrent surfaces",
>> OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 32 }, 0,
>> MAX_REGISTERED_FRAMES, VE },
>> +
>> OFFSET(rc_lookahead), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
>Why the change of default here? Kinda gives up the possibility to
>differentiate between unset and user-set to 0.
I just thought it would make more sense to have these value be 0 or greater
since they may be/are used in positive integer calculation. Currently, there
are condition checks to prevent unspecified value (-1) from being used; but I
feel user unspecified and user set to 0 are essentially the same thing in
rc_looahead and nb_surfaces scenario.
Other things addressed as you suggested:
-remove lockCount from NvencSurface struct as it is no longer referenced
-rename temporary surface variable to tmp_surf to avoid camel casing
-rename IO_surface_queue to unused_surface_queue
-remove pointless braces
-change statement: !(ctx->nb_surfaces > 0) to ctx->nb_surfaces <= 0
-fix mixed code and declaration
Thanks!
Ben
---
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.
---
NVENC_surface_allocation_reduction_v2.patch
Description: NVENC_surface_allocation_reduction_v2.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP][PATCH] avfilter: add video oscilloscope filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_datascope.c | 299 +
3 files changed, 301 insertions(+)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e40c6fe..66c36e4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -236,6 +236,7 @@ OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCR_FILTER)+= vf_ocr.o
OBJS-$(CONFIG_OCV_FILTER)+= vf_libopencv.o
OBJS-$(CONFIG_OPENCL)+= deshake_opencl.o
unsharp_opencl.o
+OBJS-$(CONFIG_OSCILLOSCOPE_FILTER) += vf_datascope.o
OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o dualinput.o
framesync.o
OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0852b54..8fb87eb 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ static void register_all(void)
REGISTER_FILTER(NULL, null, vf);
REGISTER_FILTER(OCR,ocr,vf);
REGISTER_FILTER(OCV,ocv,vf);
+REGISTER_FILTER(OSCILLOSCOPE, oscilloscope, vf);
REGISTER_FILTER(OVERLAY,overlay,vf);
REGISTER_FILTER(OWDENOISE, owdenoise, vf);
REGISTER_FILTER(PAD,pad,vf);
diff --git a/libavfilter/vf_datascope.c b/libavfilter/vf_datascope.c
index 5ad4bb8..080a97d 100644
--- a/libavfilter/vf_datascope.c
+++ b/libavfilter/vf_datascope.c
@@ -630,3 +630,302 @@ AVFilter ff_vf_pixscope = {
.inputs= pixscope_inputs,
.outputs = pixscope_outputs,
};
+
+typedef struct PixelValues {
+uint16_t p[4];
+} PixelValues;
+
+typedef struct OscilloscopeContext {
+const AVClass *class;
+
+float xpos, ypos;
+float ty;
+float size;
+float tilt;
+float tsize;
+float o;
+int components;
+int grid;
+
+int x1, y1, x2, y2;
+int ox, oy;
+int width;
+
+int nb_planes;
+int nb_comps;
+int is_rgb;
+uint8_t rgba_map[4];
+FFDrawContext draw;
+FFDrawColor dark;
+FFDrawColor black;
+FFDrawColor white;
+FFDrawColor green;
+FFDrawColor blue;
+FFDrawColor red;
+FFDrawColor gray;
+FFDrawColor *colors[4];
+
+int nb_values;
+PixelValues *values;
+
+void (*pick_color)(FFDrawContext *draw, FFDrawColor *color, AVFrame *in,
int x, int y, int *value);
+} OscilloscopeContext;
+
+#define OOFFSET(x) offsetof(OscilloscopeContext, x)
+
+static const AVOption oscilloscope_options[] = {
+{ "x","set scope x position", OOFFSET(xpos),AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, 0, 1, FLAGS },
+{ "y","set scope y position", OOFFSET(ypos),AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, 0, 1, FLAGS },
+{ "s","set scope size", OOFFSET(size),AV_OPT_TYPE_FLOAT,
{.dbl=0.8}, 0, 1, FLAGS },
+{ "t","set scope tilt", OOFFSET(tilt),AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, 0, 1, FLAGS },
+{ "o","set opacity", OOFFSET(o), AV_OPT_TYPE_FLOAT,
{.dbl=0.8}, 0, 1, FLAGS },
+{ "ty", "set trace y position", OOFFSET(ty), AV_OPT_TYPE_FLOAT,
{.dbl=0.9}, 0, 1, FLAGS },
+{ "ts", "set trace size", OOFFSET(tsize), AV_OPT_TYPE_FLOAT,
{.dbl=0.8},.1, 1, FLAGS },
+{ "c","set components to trace", OOFFSET(components), AV_OPT_TYPE_INT,
{.i64=7}, 0, 15, FLAGS },
+{ "g","draw trace grid", OOFFSET(grid),AV_OPT_TYPE_BOOL,
{.i64=0}, 0, 1, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(oscilloscope);
+
+static void oscilloscope_uninit(AVFilterContext *ctx)
+{
+OscilloscopeContext *s = ctx->priv;
+
+av_freep(&s->values);
+}
+
+static int oscilloscope_config_input(AVFilterLink *inlink)
+{
+OscilloscopeContext *s = inlink->dst->priv;
+int cx, cy, size;
+float tilt;
+
+s->nb_planes = av_pix_fmt_count_planes(inlink->format);
+ff_draw_init(&s->draw, inlink->format, 0);
+ff_draw_color(&s->draw, &s->dark, (uint8_t[]){ 0, 0, 0, s->o * 255} );
+ff_draw_color(&s->draw, &s->black, (uint8_t[]){ 0, 0, 0, 255} );
+ff_draw_color(&s->draw, &s->white, (uint8_t[]){ 255, 255, 255, 255} );
+ff_draw_color(&s->draw, &s->green, (uint8_t[]){ 0, 255, 0, 255} );
+ff_draw_color(&s->draw, &s->blue, (uint8_t[]){ 0, 0, 255, 255} );
+ff_draw_color(&s->draw, &s->red, (uint8_t[]){ 255, 0, 0, 255} );
+ff_draw_color(&s->draw, &s->gray, (uint8_t[]){ 128, 128, 128, 255} );
+s->nb_comps = s->draw.desc->nb_components;
+s->is_rgb = s->draw.desc->flags & AV_PIX_FMT_FLAG_RGB;
+
+if (s->is_rgb) {
+s->colors[0] = &s->red;
+s->colors[1] = &s->green;
+s->colors[2] = &s->blue;
+s->colors[3] = &s->white;
+ff_fill_rgba_map(s->rgb
[FFmpeg-devel] [PATCH] avformat/hlsenc: hold old key info when append list
fix ticket id: #6353
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 27c8e3355d..3ec0f330fb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -810,6 +810,7 @@ static int parse_playlist(AVFormatContext *s, const char
*url)
int64_t new_start_pos;
char line[1024];
const char *ptr;
+const char *end;
if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
&s->interrupt_callback, NULL,
@@ -842,6 +843,29 @@ static int parse_playlist(AVFormatContext *s, const char
*url)
} else if (av_strstart(line, "#EXTINF:", &ptr)) {
is_segment = 1;
hls->duration = atof(ptr);
+} else if (av_stristart(line, "#EXT-X-KEY:", &ptr)) {
+ptr = av_stristr(line, "URI=\"");
+if (ptr) {
+ptr += strlen("URI=\"");
+end = av_stristr(ptr, ",");
+if (end) {
+av_strlcpy(hls->key_uri, ptr, end - ptr);
+} else {
+av_strlcpy(hls->key_uri, ptr, sizeof(hls->key_uri));
+}
+}
+
+ptr = av_stristr(line, "IV=0x");
+if (ptr) {
+ptr += strlen("IV=0x");
+end = av_stristr(ptr, ",");
+if (end) {
+av_strlcpy(hls->iv_string, ptr, end - ptr);
+} else {
+av_strlcpy(hls->iv_string, ptr, sizeof(hls->iv_string));
+}
+}
+
} else if (av_strstart(line, "#", NULL)) {
continue;
} else if (line[0]) {
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix CID 1405135
CID: 1405135
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3ec0f330fb..b7aafb73da 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -394,11 +394,11 @@ static int do_encrypt(AVFormatContext *s)
av_strlcat(hls->key_basename, ".key", len);
if (hls->key_url) {
-strncpy(hls->key_file, hls->key_url, sizeof(hls->key_file));
-strncpy(hls->key_uri, hls->key_url, sizeof(hls->key_uri));
+av_strlcpy(hls->key_file, hls->key_url, strlen(hls->key_url));
+av_strlcpy(hls->key_uri, hls->key_url, strlen(hls->key_url));
} else {
-strncpy(hls->key_file, hls->key_basename, sizeof(hls->key_file));
-strncpy(hls->key_uri, hls->key_basename, sizeof(hls->key_uri));
+av_strlcpy(hls->key_file, hls->key_basename,
strlen(hls->key_basename));
+av_strlcpy(hls->key_uri, hls->key_basename, strlen(hls->key_basename));
}
if (!*hls->iv_string) {
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Reviewing merges
On Tue, Apr 25, 2017 at 11:33:29AM -0300, James Almer wrote: > On 4/24/2017 3:27 PM, Michael Niedermayer wrote: > > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote: > >> On 4/23/2017 11:07 PM, Michael Niedermayer wrote: > >>> Hi all > >>> > >>> Should changes ported from libav (what we call merges) be reviewed > >>> before being pushed? > >> > >> The lot of merges are simple things like "Fix this bug that was already > >> fixed in ffmpeg months ago", "K&R", etc. Lately we are even no-oping a > >> good amount of them as they don't even apply. > > > >> Only a small set of merges are big API changes, and those are always > >> handled by more than one developer, either by reviewing the changes, > >> testing them or by helping getting the thing working. And of course, any > >> bug that was not caught before pushing is fixed afterwards. > >> In fact, it should be noted that if they are initially skipped for > >> requiring more thought and for blocking unrelated merges, when we get > >> them working at a latter point we always send them to the ML instead of > >> simply pushing them. > > > > yes > > > > could you send more changes to the ML instead of just ones > > initially skiped ? (and of course i dont mean trivial / clearly correct > > stuff) > > If I'm the one merging some change that has considerable chances of > introducing regressions, then sure. Thanks ! [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Is ffmpeg 2.8.11 vulnerable to clusterfuzz 4999324687663104?
Hi, I'm having trouble decoding this clusterfuzz report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=713 Was trying to figure out if 2.8.11 is vulnerable. It's not clear which commit was the fix, but it looks like none of the commits in the regression range made it to the 2.8 branch. Was that because 2.8 was never vulnerable to it? Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] avfilter: add video oscilloscope filter
> On Apr 25, 2017, at 6:15 PM, Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_datascope.c | 299 +
> 3 files changed, 301 insertions(+)
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e40c6fe..66c36e4 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -236,6 +236,7 @@ OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
> OBJS-$(CONFIG_OCR_FILTER)+= vf_ocr.o
> OBJS-$(CONFIG_OCV_FILTER)+= vf_libopencv.o
> OBJS-$(CONFIG_OPENCL)+= deshake_opencl.o
> unsharp_opencl.o
> +OBJS-$(CONFIG_OSCILLOSCOPE_FILTER) += vf_datascope.o
> OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o dualinput.o
> framesync.o
> OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
> OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 0852b54..8fb87eb 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -246,6 +246,7 @@ static void register_all(void)
> REGISTER_FILTER(NULL, null, vf);
> REGISTER_FILTER(OCR,ocr,vf);
> REGISTER_FILTER(OCV,ocv,vf);
> +REGISTER_FILTER(OSCILLOSCOPE, oscilloscope, vf);
> REGISTER_FILTER(OVERLAY,overlay,vf);
> REGISTER_FILTER(OWDENOISE, owdenoise, vf);
> REGISTER_FILTER(PAD,pad,vf);
> diff --git a/libavfilter/vf_datascope.c b/libavfilter/vf_datascope.c
> index 5ad4bb8..080a97d 100644
> --- a/libavfilter/vf_datascope.c
> +++ b/libavfilter/vf_datascope.c
> @@ -630,3 +630,302 @@ AVFilter ff_vf_pixscope = {
> .inputs= pixscope_inputs,
> .outputs = pixscope_outputs,
> };
> +
> +typedef struct PixelValues {
> +uint16_t p[4];
> +} PixelValues;
> +
> +typedef struct OscilloscopeContext {
> +const AVClass *class;
> +
> +float xpos, ypos;
> +float ty;
> +float size;
> +float tilt;
> +float tsize;
> +float o;
> +int components;
> +int grid;
> +
> +int x1, y1, x2, y2;
> +int ox, oy;
> +int width;
> +
> +int nb_planes;
> +int nb_comps;
> +int is_rgb;
> +uint8_t rgba_map[4];
> +FFDrawContext draw;
> +FFDrawColor dark;
> +FFDrawColor black;
> +FFDrawColor white;
> +FFDrawColor green;
> +FFDrawColor blue;
> +FFDrawColor red;
> +FFDrawColor gray;
> +FFDrawColor *colors[4];
> +
> +int nb_values;
> +PixelValues *values;
> +
> +void (*pick_color)(FFDrawContext *draw, FFDrawColor *color, AVFrame *in,
> int x, int y, int *value);
> +} OscilloscopeContext;
> +
> +#define OOFFSET(x) offsetof(OscilloscopeContext, x)
> +
> +static const AVOption oscilloscope_options[] = {
> +{ "x","set scope x position", OOFFSET(xpos),AV_OPT_TYPE_FLOAT,
> {.dbl=0.5}, 0, 1, FLAGS },
> +{ "y","set scope y position", OOFFSET(ypos),AV_OPT_TYPE_FLOAT,
> {.dbl=0.5}, 0, 1, FLAGS },
I’m curious why floats are used for x,y coordinates within a frame rather than
integers.
> +{ "s","set scope size", OOFFSET(size),AV_OPT_TYPE_FLOAT,
> {.dbl=0.8}, 0, 1, FLAGS },
> +{ "t","set scope tilt", OOFFSET(tilt),AV_OPT_TYPE_FLOAT,
> {.dbl=0.5}, 0, 1, FLAGS },
> +{ "o","set opacity", OOFFSET(o), AV_OPT_TYPE_FLOAT,
> {.dbl=0.8}, 0, 1, FLAGS },
> +{ "ty", "set trace y position", OOFFSET(ty), AV_OPT_TYPE_FLOAT,
> {.dbl=0.9}, 0, 1, FLAGS },
> +{ "ts", "set trace size", OOFFSET(tsize), AV_OPT_TYPE_FLOAT,
> {.dbl=0.8},.1, 1, FLAGS },
> +{ "c","set components to trace", OOFFSET(components),
> AV_OPT_TYPE_INT, {.i64=7}, 0, 15, FLAGS },
> +{ "g","draw trace grid", OOFFSET(grid),AV_OPT_TYPE_BOOL,
> {.i64=0}, 0, 1, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(oscilloscope);
> +
> +static void oscilloscope_uninit(AVFilterContext *ctx)
> +{
> +OscilloscopeContext *s = ctx->priv;
> +
> +av_freep(&s->values);
> +}
> +
> +static int oscilloscope_config_input(AVFilterLink *inlink)
> +{
> +OscilloscopeContext *s = inlink->dst->priv;
> +int cx, cy, size;
> +float tilt;
> +
> +s->nb_planes = av_pix_fmt_count_planes(inlink->format);
> +ff_draw_init(&s->draw, inlink->format, 0);
> +ff_draw_color(&s->draw, &s->dark, (uint8_t[]){ 0, 0, 0, s->o * 255} );
> +ff_draw_color(&s->draw, &s->black, (uint8_t[]){ 0, 0, 0, 255} );
> +ff_draw_color(&s->draw, &s->white, (uint8_t[]){ 255, 255, 255, 255} );
> +ff_draw_color(&s->draw, &s->green, (uint8_t[]){ 0, 255, 0, 255} );
> +ff_draw_color(&s->draw, &s->blue, (uint8_t[]){ 0, 0, 255, 255} );
> +ff_draw_color(&s->draw, &s->red, (uint8_t[]){ 255, 0, 0
Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter
> On Apr 24, 2017, at 5:03 PM, Paul B Mahol wrote: > > On 4/24/17, Dave Rice wrote: >> >>> On Apr 24, 2017, at 4:47 PM, Paul B Mahol wrote: >>> >>> On 4/24/17, Dave Rice wrote: I tested this filter and find it very useful, but could it be adjusted to handle full range video. Currently when I test with a sample such as: ./ffplay -f lavfi -i color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope The outputs list Y=235, U=240, V=16. >>> >>> Hmm, I cannot reproduce this with my old ffplay build or latest mpv or >>> latest ffmpeg. >>> >>> So it must be ffplay issue. >> >> Can you recreate it with: >> >> ./ffmpeg -f lavfi -i >> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope -f >> nut - | mpv - > > No. > > Neither with: > > ./ffmpeg -f lavfi -i > color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope > -f nut -c:v rawvideo - | mpv - > > or: > > mpv > avdevice://lavfi:color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope > > I hard reset my copy of the repo, re-applied the patch, and now it works as expected. Thanks. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread_frame: set err from the thread that return frame
On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote: > On Tue, 25 Apr 2017 23:52:04 +0700 > Muhammad Faiz wrote: > >> when frame is received, not from other threads. >> >> Should fix fate failure with THREADS>=4: >> make fate-h264-attachment-631 THREADS=4 >> >> Signed-off-by: Muhammad Faiz >> --- >> libavcodec/pthread_frame.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >> index 13d6828..c452ed7 100644 >> --- a/libavcodec/pthread_frame.c >> +++ b/libavcodec/pthread_frame.c >> @@ -547,6 +547,10 @@ int ff_thread_decode_frame(AVCodecContext *avctx, >> >> fctx->next_finished = finished; >> >> +/* if frame is returned, properly set err from the thread that return >> frame */ >> +if (*got_picture_ptr) >> +err = p->result; >> + >> /* return the size of the consumed packet if no error occurred */ >> if (err >= 0) >> err = avpkt->size; > > Well, the logic confuses me. Does this override an earlier set err > value? Yes, because an earlier set err value may be from a different thread. >Could err be set to the correct value in the first place (inside > of the loop)? No, it was intended on 32a5b631267 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/options: do a more thorough clean up in avcodec_copy_context()
On 4/24/2017 3:47 PM, James Almer wrote:
Free coded_frame, coded_side_data and unref hw_device_ctx to prevent
potential leaks.
Signed-off-by: James Almer
---
libavcodec/options.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index b98da9378a..82e12179a6 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -190,14 +190,26 @@ void avcodec_free_context(AVCodecContext **pavctx)
#if FF_API_COPY_CONTEXT
static void copy_context_reset(AVCodecContext *avctx)
{
+int i;
+
av_opt_free(avctx);
+#if FF_API_CODED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+av_frame_free(&avctx->coded_frame);
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
av_freep(&avctx->rc_override);
av_freep(&avctx->intra_matrix);
av_freep(&avctx->inter_matrix);
av_freep(&avctx->extradata);
av_freep(&avctx->subtitle_header);
av_buffer_unref(&avctx->hw_frames_ctx);
+av_buffer_unref(&avctx->hw_device_ctx);
+for (i = 0; i < avctx->nb_coded_side_data; i++)
+av_freep(&avctx->coded_side_data[i].data);
+av_freep(&avctx->coded_side_data);
avctx->subtitle_header_size = 0;
+avctx->nb_coded_side_data = 0;
avctx->extradata_size = 0;
}
@@ -238,11 +250,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
/* reallocate values that should be allocated separately */
dest->extradata = NULL;
+dest->coded_side_data = NULL;
dest->intra_matrix= NULL;
dest->inter_matrix= NULL;
dest->rc_override = NULL;
dest->subtitle_header = NULL;
dest->hw_frames_ctx = NULL;
+dest->hw_device_ctx = NULL;
+dest->nb_coded_side_data = 0;
#define alloc_and_copy_or_fail(obj, size, pad) \
if (src->obj && size > 0) { \
I'm not sure if this patch is intended to be a replacement for your last
"2/2" patch, but this version is missing the the coded_side_data
population code that was in the first version of your "2/2" patch.
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CID 1405135
On 4/25/2017 4:47 PM, Steven Liu wrote:
CID: 1405135
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3ec0f330fb..b7aafb73da 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -394,11 +394,11 @@ static int do_encrypt(AVFormatContext *s)
av_strlcat(hls->key_basename, ".key", len);
if (hls->key_url) {
-strncpy(hls->key_file, hls->key_url, sizeof(hls->key_file));
-strncpy(hls->key_uri, hls->key_url, sizeof(hls->key_uri));
+av_strlcpy(hls->key_file, hls->key_url, strlen(hls->key_url));
+av_strlcpy(hls->key_uri, hls->key_url, strlen(hls->key_url));
} else {
-strncpy(hls->key_file, hls->key_basename, sizeof(hls->key_file));
-strncpy(hls->key_uri, hls->key_basename, sizeof(hls->key_uri));
+av_strlcpy(hls->key_file, hls->key_basename,
strlen(hls->key_basename));
+av_strlcpy(hls->key_uri, hls->key_basename, strlen(hls->key_basename));
If either hls->key_url or hls->key_basename, depending on which path the
code takes, is longer in length than key_file or key_uri (both of size
LINE_BUFFER_SIZE + 1), then the calls to av_strlcpy() will write past
the end of the buffers. As key_url corresponds to a user-passed option,
and I think the same may be true for key_basename based on the way it is
formed, this in theory could be a problem, although it is unlikely in
practice since LINE_BUFFER_SIZE is 1024. While ideally there would be a
sanity check somewhere in the code to make sure those URLs aren't too
long, an alternative is to copy up to max LINE_BUFFER_SIZE characters
and make sure the string is null-terminated in that case.
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CID 1405135
> On Apr 25, 2017, at 18:47, Steven Liu wrote:
>
> CID: 1405135
I have no idea what this message is supposed to mean.
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 3ec0f330fb..b7aafb73da 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -394,11 +394,11 @@ static int do_encrypt(AVFormatContext *s)
> av_strlcat(hls->key_basename, ".key", len);
>
> if (hls->key_url) {
> -strncpy(hls->key_file, hls->key_url, sizeof(hls->key_file));
> -strncpy(hls->key_uri, hls->key_url, sizeof(hls->key_uri));
> +av_strlcpy(hls->key_file, hls->key_url, strlen(hls->key_url));
> +av_strlcpy(hls->key_uri, hls->key_url, strlen(hls->key_url));
Changing this to av_strlcpy makes sense, but using strlen() here replaces a DoS
vulnerability with a memory-corruption one. Use sizeof() like the original code
in all 4 cases.
> } else {
> -strncpy(hls->key_file, hls->key_basename, sizeof(hls->key_file));
> -strncpy(hls->key_uri, hls->key_basename, sizeof(hls->key_uri));
> +av_strlcpy(hls->key_file, hls->key_basename,
> strlen(hls->key_basename));
> +av_strlcpy(hls->key_uri, hls->key_basename,
> strlen(hls->key_basename));
> }
>
> if (!*hls->iv_string) {
> --
> 2.11.0 (Apple Git-81)
>
>
>
> ___
> 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] [WIP][PATCH] avfilter: add video oscilloscope filter
On 4/26/17, Dave Rice wrote: > > > I'm curious why floats are used for x,y coordinates within a frame rather > than integers. So it the position be set relatively. And for similar results for different resolutions. > > > It appears that the plotted scope is padded to 300, though the trace usually > is 256 (2^8) lines tall. Are the other 44 lines intended to store something? > Yes, some statistics numbers. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Suppress the "above array bounds" warning.
From f3678e0ceb691b6df5957a2c3d26d4f0d91d4ff5 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Wed, 26 Apr 2017 14:00:56 +0800
Subject: [PATCH] lavc/vaapi_encode_h265: Suppress the "above array bounds"
warning.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
setting the layer_id_included_flag lead to a potential array out of bounds,
build warning message as follow:
libavcodec/vaapi_encode_h265.c: In function
‘vaapi_encode_h265_write_sequence_header’:
libavcodec/vaapi_encode_h265.c:305:49: warning: array subscript is above
array bounds [-Warray-bounds]
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 6e008b7b9c..1b2a49806b 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -66,7 +66,7 @@ typedef struct VAAPIEncodeH265MiscSequenceParams {
unsigned int vps_num_layer_sets_minus1;
unsigned int sps_max_sub_layers_minus1;
char sps_temporal_id_nesting_flag;
-char layer_id_included_flag[MAX_LAYERS][64];
+char layer_id_included_flag[MAX_LAYERS+1][64];
// Profile/tier/level parameters.
char general_profile_compatibility_flag[32];
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
