[FFmpeg-devel] [PATCH,v3] lavc/qsvenc: add VDENC support for H264
Add VDENC(lowpower mode) support for QSV H264.
It's an experimental function(like lowpower in vaapi) with
some limitations:
- CBR/VBR require HuC which should be explicitly loaded via i915
module parameter(i915.enable_guc=2 for linux kernel version >= 4.16)
use option "-low_power 1" to enable VDENC.
Signed-off-by: Linjie Fu
---
[v2]: modified the commit message and option comments, use AV_OPT_TYPE_BOOL
to replace AV_OPT_TYPE_INT.
[v3]: enable H264 VDENC separately.
libavcodec/qsvenc.c | 3 +++
libavcodec/qsvenc.h | 2 ++
libavcodec/qsvenc_h264.c | 3 +++
3 files changed, 8 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 948751daf4..7a031297fe 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -464,6 +464,9 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
}
}
+#if QSV_HAVE_VDENC
+q->param.mfx.LowPower = q->low_power ?
MFX_CODINGOPTION_ON:MFX_CODINGOPTION_OFF;
+#endif
q->param.mfx.CodecProfile = q->profile;
q->param.mfx.TargetUsage= avctx->compression_level;
q->param.mfx.GopPicSize = FFMAX(0, avctx->gop_size);
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 50cc4267e7..a396aa7d3f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -44,6 +44,7 @@
#define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
#define QSV_HAVE_LA_DS QSV_VERSION_ATLEAST(1, 8)
#define QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
+#define QSV_HAVE_VDENC QSV_VERSION_ATLEAST(1, 15)
#if defined(_WIN32) || defined(__CYGWIN__)
#define QSV_HAVE_AVBR QSV_VERSION_ATLEAST(1, 3)
@@ -162,6 +163,7 @@ typedef struct QSVEncContext {
int recovery_point_sei;
int a53_cc;
+int low_power;
#if QSV_HAVE_MF
int mfmode;
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 07c9d64e6b..8857959d39 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -153,6 +153,9 @@ static const AVOption options[] = {
{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_DISABLED },
INT_MIN, INT_MAX, VE, "mfmode" },
{ "auto" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_AUTO },
INT_MIN, INT_MAX, VE, "mfmode" },
#endif
+#if QSV_HAVE_VDENC
+{ "low_power", "enable low power mode (experimental, many limitations by
mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64
= 0 }, 0, 1, VE},
+#endif
{ NULL },
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/dashenc: Fix AVDictionary leaks in case of various init errors.
On 11/26/18 4:31 PM, Andrey Semashev wrote: > On Wed, Nov 21, 2018 at 3:45 PM Jeyapal, Karthick wrote: > > On 11/20/18 6:01 PM, Andrey Semashev wrote: > > > On 11/18/18 1:55 PM, Jeyapal, Karthick wrote: > > > > Thanks for sending these excellent patches. The entire patchset looks > > > > good to me. > > > > Also, many thanks for your patience and taking the earlier review > > > > comments in the right spirit. > > > > > > Ping for merging it then? > > Thanks for the ping. Pushed all the dashenc patches. > > Left out the dashdec patch, as its maintainer has not commented yet. Maybe > > we can wait for few more days before pushing the dashdec patch. > > Looks like noone will comment on the dashdec patch. Could you merge it, > please? Sure. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Fix integer overflows in left shift in init_image()
On Mon, Nov 26, 2018 at 12:08:27PM +0100, Tomas Härdin wrote:
> mån 2018-11-26 klockan 02:57 +0100 skrev Michael Niedermayer:
> > Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
> > Fixes:
> > 11377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5694319101476864
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/tiff.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index 6271c937c3..751f23ef33 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -706,7 +706,7 @@ static int init_image(TiffContext *s, ThreadFrame
> > *frame)
> > s->avctx->pix_fmt = s->palette_is_set ? AV_PIX_FMT_PAL8 :
> > AV_PIX_FMT_GRAY8;
> > break;
> > case 10081:
> > -switch (s->pattern[0] | (s->pattern[1] << 8) | (s->pattern[2] <<
> > 16) | (s->pattern[3] << 24)) {
> > +switch (AV_RL32(s->pattern)) {
> > case 0x02010100:
> > s->avctx->pix_fmt = AV_PIX_FMT_BAYER_RGGB8;
> > break;
> > @@ -721,12 +721,12 @@ static int init_image(TiffContext *s, ThreadFrame
> > *frame)
> > break;
> > default:
> > av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> > 0x%X\n",
> > - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] <<
> > 16 | s->pattern[3] << 24);
> > + AV_RL32(s->pattern));
> > return AVERROR_PATCHWELCOME;
> > }
> > break;
> > case 10121:
> > -switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
> > s->pattern[3] << 24) {
> > +switch (AV_RL32(s->pattern)) {
> > case 0x02010100:
> > s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
> > AV_PIX_FMT_BAYER_RGGB16BE;
> > break;
> > @@ -741,12 +741,12 @@ static int init_image(TiffContext *s, ThreadFrame
> > *frame)
> > break;
> > default:
> > av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> > 0x%X\n",
> > - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] <<
> > 16 | s->pattern[3] << 24);
> > + AV_RL32(s->pattern));
> > return AVERROR_PATCHWELCOME;
> > }
> > break;
> > case 10161:
> > -switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
> > s->pattern[3] << 24) {
> > +switch (AV_RL32(s->pattern)) {
> > case 0x02010100:
> > s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
> > AV_PIX_FMT_BAYER_RGGB16BE;
> > break;
> > @@ -761,7 +761,7 @@ static int init_image(TiffContext *s, ThreadFrame
> > *frame)
> > break;
> > default:
> > av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> > 0x%X\n",
> > - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] <<
> > 16 | s->pattern[3] << 24);
> > + AV_RL32(s->pattern));
>
> This is much nicer :)
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8
2018-11-21 18:19 GMT+01:00, Lauri Kasanen : > First I ran with THREADS=3, baseline blew up in > fate-h264-conformance-frext-hpcafl_bcrm_c I opened ticket #7570, thank you for the report! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
On Mon, Nov 26, 2018 at 04:19:20PM +0100, Martin Vignali wrote:
> > > +
> > > +switch (pict->colorspace) {
> > > +case AVCOL_SPC_BT709:
> > > +case AVCOL_SPC_UNSPECIFIED:
> > > +case AVCOL_SPC_SMPTE170M:
> > > +case AVCOL_SPC_BT2020_NCL:
> > > +colorspace = pict->colorspace;
> > > +break;
> > > +default:
> > > +av_log(avctx, AV_LOG_DEBUG,
> > > +"Frame colorspace %d are not supported in prores frame.
> > Set prores frame value to unspecified\n", pict->colorspace);
> > > +break;
> > > +}
> > > +*buf++ = color_primaries;
> > > +*buf++ = color_trc;
> > > +*buf++ = colorspace;
> >
> > we maybe should write a generic function that takes a list of supported
> > types
> > and the undefined one and then does the check, debug print and all that
> > that could be used in other encoders too.
> > just an idea, that can be done later
> >
> > the patch
> > LGTM
> >
> >
> Don't know for others codecs, but this check can also probably be add when
> setting AvFrame color properties in prores dec.
>
> As a generic function, do you mean something like this :
> (If yes, where do you think it's better to declare this func)
> (untested, and not sure, what is the right log level for this (debug or
> warning ?))
>
> int ff_check_value(AVCodecContext *avctx, const char * val_name, int val,
ff_int_is_in_list() or something similar would be more descriptive and specific
this one doesnt suggest though that the return is teh value or default so its
still maybe not the best identifer
> int * array_valid_values, int nb_values, int
> default_value) {
nb_values could be replaced by a -1 or so terminated array, making the
API slightly more robust
AVCodecContext* should be void *
but yes this is what i had in mind
If it has uses in multiple libs then it has to be in a lib that all
depend on. This would dictate in which lib to put it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
2018-11-26 23:35 GMT+01:00, Michael Niedermayer : > On Mon, Nov 26, 2018 at 12:45:26AM +0100, Carl Eugen Hoyos wrote: >> 2018-11-25 16:17 GMT+01:00, Lauri Kasanen : >> > Hi, >> > >> > The lone power8 fate failing test seems like an aliasing issue. >> > I've isolated it into the attached standalone test case. Compiling it >> > with >> > gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize >> > -o test test.c >> > >> > reproduces on gcc 8.2.0, dropping the optimization level fixes it. This >> > was one of the "adding a printf made it work" things too. >> > >> > -Wstrict-aliasing=1 complains about the "register int *idataptr = >> > (int*)dataptr;" cast. If I put "typedef int __attribute__((may_alias)) >> > int_alias;" at the top and change the cast and type to int_alias, the >> > results become correct. >> >> Thank you for the analysis! >> >> Patch attached, Carl Eugen > >> jrevdct.c | 17 + >> 1 file changed, 9 insertions(+), 8 deletions(-) >> fef3d295836588ff8e619d4aa42247b4d2f25e93 >> 0001-lavc-jrevdct-Avoid-an-aliasing-violation.patch >> From e5403b832f2bcd360128d9986b602484e576c931 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Mon, 26 Nov 2018 00:43:46 +0100 >> Subject: [PATCH] lavc/jrevdct: Avoid an aliasing violation. >> >> Fixes fate on different PowerPC systems with some compilers. >> >> Analyzed-by: Lauri Kasanen >> --- >> libavcodec/jrevdct.c | 17 + >> 1 file changed, 9 insertions(+), 8 deletions(-) >> >> diff --git a/libavcodec/jrevdct.c b/libavcodec/jrevdct.c >> index 3b15a52..c749468 100644 >> --- a/libavcodec/jrevdct.c >> +++ b/libavcodec/jrevdct.c >> @@ -63,6 +63,7 @@ >> */ >> >> #include "libavutil/common.h" >> +#include "libavutil/intreadwrite.h" >> >> #include "dct.h" >> #include "idctdsp.h" >> @@ -234,7 +235,7 @@ void ff_j_rev_dct(DCTBLOCK data) >> * row DCT calculations can be simplified this way. >> */ >> >> -register int *idataptr = (int*)dataptr; >> +register uint8_t *idataptr = (uint8_t*)dataptr; >> >> /* WARNING: we do the same permutation as MMX idct to simplify the >> video core */ >> @@ -254,10 +255,10 @@ void ff_j_rev_dct(DCTBLOCK data) >>int16_t dcval = (int16_t) (d0 * (1 << PASS1_BITS)); >>register int v = (dcval & 0x) | ((dcval * (1 << 16)) & >> 0x); >> >> - idataptr[0] = v; >> - idataptr[1] = v; >> - idataptr[2] = v; >> - idataptr[3] = v; >> + AV_WN32(&idataptr[ 0], v); >> + AV_WN32(&idataptr[ 4], v); >> + AV_WN32(&idataptr[ 8], v); >> + AV_WN32(&idataptr[12], v); > > this probably should be AV_WN32A() Tested and applied with AV_WN32A(). Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8
2018-11-27 0:17 GMT+01:00, Carl Eugen Hoyos :
> 2018-11-17 9:12 GMT+01:00, Lauri Kasanen :
>> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
>> yuv420p \
>> -f null -vframes 100 -v error -nostats -
>>
>> 1158 UNITS in planar1, 65528 runs, 8 skips
>>
>> -cpuflags 0
>>
>> 19082 UNITS in planar1, 65533 runs, 3 skips
>>
>> 16.48 speedup ratio. On x86, SSE2 is ~7. Curiously, the Power C version
>> takes as many cycles as the x86 SSE2 version, yikes it's fast.
>>
>> Note that this function uses VSX instructions, but is not marked so.
>> This is because several existing functions also make that mistake.
>> I'll submit a patch moving them once this is reviewed.
>>
>> v2: Remove !BE check
>> Signed-off-by: Lauri Kasanen
>> ---
>> libswscale/ppc/swscale_altivec.c | 53
>>
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/libswscale/ppc/swscale_altivec.c
>> b/libswscale/ppc/swscale_altivec.c
>> index 2fb2337..8c6056d 100644
>> --- a/libswscale/ppc/swscale_altivec.c
>> +++ b/libswscale/ppc/swscale_altivec.c
>> @@ -324,6 +324,53 @@ static void hScale_altivec_real(SwsContext *c,
>> int16_t
>> *dst, int dstW,
>> }
>> }
>> }
>> +
>> +static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
>> + const uint8_t *dither, int offset, int start)
>> +{
>> +int i;
>> +for (i = start; i < dstW; i++) {
>> +int val = (src[i] + dither[(i + offset) & 7]) >> 7;
>> +dest[i] = av_clip_uint8(val);
>> +}
>> +}
>> +
>> +static void yuv2plane1_8_altivec(const int16_t *src, uint8_t *dest, int
>> dstW,
>> + const uint8_t *dither, int offset)
>> +{
>> +const int dst_u = -(uintptr_t)dest & 15;
>> +int i, j;
>> +LOCAL_ALIGNED(16, int16_t, val, [16]);
>
>> +const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7,
>> 7,
>> 7};
>
> The patch breaks compilation with xlc, sorry for not testing earlier:
> libswscale/ppc/swscale_altivec.c:344:11: error: unknown type name 'vector'
> const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7, 7, 7};
In case this error does not make much sense to you, don't worry too
much, the following change was necessary to make xlc pass rv20-1239:
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 6518d50..fb749c5 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -744,6 +744,7 @@ static int configure_input_video_filter
InputFile *f = input_files[ist->file_index];
AVRational tb = ist->framerate.num ? av_inv_q(ist->framerate) :
ist->st->time_base;
+if(!ist->framerate.num)tb = ist->st->time_base;
AVRational fr = ist->framerate;
AVRational sar;
AVBPrint args;
;-)
(As expected, other tests also fail.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvmaf: update docs
Hi,
On 10/22/18, Kyle Swanson wrote:
> From: Kyle Swanson
>
> For context: https://github.com/Netflix/vmaf/issues/237
>
> Signed-off-by: Kyle Swanson
> ---
>
> I'll push this sometime in the next 24hrs unless someone has an issue.
Almost forgot about this. Pushed an updated version. Thanks.
>
> doc/filters.texi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index a2ef327688..5ab8ffbccb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -11243,7 +11243,9 @@ Set the file path to be used to store logs.
> Set the format of the log file (xml or json).
>
> @item enable_transform
> -Enables transform for computing vmaf.
> +This option can enable/disable the @code{score_transform} applied to the
> final predicted VMAF score,
> +if you have specified score_transform option in the input parameter file
> passed to @code{run_vmaf_training.py}
> +Default value: @code{false}
>
> @item phone_model
> Invokes the phone model which will generate VMAF scores higher than in the
> --
> 2.18.0
>
>
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8
2018-11-17 9:12 GMT+01:00, Lauri Kasanen :
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p \
> -f null -vframes 100 -v error -nostats -
>
> 1158 UNITS in planar1, 65528 runs, 8 skips
>
> -cpuflags 0
>
> 19082 UNITS in planar1, 65533 runs, 3 skips
>
> 16.48 speedup ratio. On x86, SSE2 is ~7. Curiously, the Power C version
> takes as many cycles as the x86 SSE2 version, yikes it's fast.
>
> Note that this function uses VSX instructions, but is not marked so.
> This is because several existing functions also make that mistake.
> I'll submit a patch moving them once this is reviewed.
>
> v2: Remove !BE check
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/ppc/swscale_altivec.c | 53
>
> 1 file changed, 53 insertions(+)
>
> diff --git a/libswscale/ppc/swscale_altivec.c
> b/libswscale/ppc/swscale_altivec.c
> index 2fb2337..8c6056d 100644
> --- a/libswscale/ppc/swscale_altivec.c
> +++ b/libswscale/ppc/swscale_altivec.c
> @@ -324,6 +324,53 @@ static void hScale_altivec_real(SwsContext *c, int16_t
> *dst, int dstW,
> }
> }
> }
> +
> +static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
> + const uint8_t *dither, int offset, int start)
> +{
> +int i;
> +for (i = start; i < dstW; i++) {
> +int val = (src[i] + dither[(i + offset) & 7]) >> 7;
> +dest[i] = av_clip_uint8(val);
> +}
> +}
> +
> +static void yuv2plane1_8_altivec(const int16_t *src, uint8_t *dest, int
> dstW,
> + const uint8_t *dither, int offset)
> +{
> +const int dst_u = -(uintptr_t)dest & 15;
> +int i, j;
> +LOCAL_ALIGNED(16, int16_t, val, [16]);
> +const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7, 7,
> 7};
The patch breaks compilation with xlc, sorry for not testing earlier:
libswscale/ppc/swscale_altivec.c:344:11: error: unknown type name 'vector'
const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7, 7, 7};
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mem: Fix invalid use of av_alloc_size
On Sun, Nov 25, 2018 at 05:55:37PM -0800, Mark Harris wrote: > On 2018-11-25 17:29, James Almer wrote: > > On 11/25/2018 10:01 PM, Michael Niedermayer wrote: > >> On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote: > >>> The alloc_size attribute is valid only on functions that return a > >>> pointer. GCC 9 (not yet released) warns about invalid usage: > >>> > >>> ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a > >>> function returning int' [-Wattributes] > >>> 342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t > >>> nmemb, size_t size); > >>> | ^ > >> > >> Is the attribute also useless on all other compilers ? > > > > The attribute is only used when __GNUC__ is defined, so it should for > > any such compiler (GCC and Clang). > > > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html > > > > The Clang documentation does note a minor difference from GCC, but both > GCC and Clang agree that it applies to functions that return a pointer. > The size is the number of bytes allocated at that pointer. It doesn't > support an indirect reference to the allocated memory; if it did it > would likely need an additional parameter to indicate which argument was > the indirect reference. ok, will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/vivo: Don't log null value
On Sun, Nov 25, 2018 at 09:52:04AM +0100, Paul B Mahol wrote:
> On 11/25/18, Mark Harris wrote:
> > ---
> > libavformat/vivo.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/vivo.c b/libavformat/vivo.c
> > index c9e9c37f37..9b9189f307 100644
> > --- a/libavformat/vivo.c
> > +++ b/libavformat/vivo.c
> > @@ -166,7 +166,7 @@ static int vivo_read_header(AVFormatContext *s)
> > value = strchr(key, ':');
> > if (!value) {
> > av_log(s, AV_LOG_WARNING, "missing colon in key:value pair
> > '%s'\n",
> > - value);
> > + key);
> > continue;
> > }
> >
> > --
> > 2.19.2
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromashift: Fix mixed declaration and code
On Sun, Nov 25, 2018 at 09:52:58AM +0100, Paul B Mahol wrote: > On 11/25/18, Mark Harris wrote: > > --- > > libavfilter/vf_chromashift.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavfilter/vf_chromashift.c b/libavfilter/vf_chromashift.c > > index 068c3c1b68..d073256b99 100644 > > --- a/libavfilter/vf_chromashift.c > > +++ b/libavfilter/vf_chromashift.c > > @@ -76,13 +76,14 @@ static int query_formats(AVFilterContext *ctx) > > AV_PIX_FMT_NONE > > }; > > const enum AVPixelFormat *pix_fmts; > > +AVFilterFormats *fmts_list; > > > > if (!strcmp(ctx->filter->name, "rgbashift")) > > pix_fmts = rgb_pix_fmts; > > else > > pix_fmts = yuv_pix_fmts; > > > > -AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts); > > +fmts_list = ff_make_format_list(pix_fmts); > > if (!fmts_list) > > return AVERROR(ENOMEM); > > return ff_set_common_formats(ctx, fmts_list); > > -- > > 2.19.2 > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
On Mon, Nov 26, 2018 at 12:45:26AM +0100, Carl Eugen Hoyos wrote: > 2018-11-25 16:17 GMT+01:00, Lauri Kasanen : > > Hi, > > > > The lone power8 fate failing test seems like an aliasing issue. > > I've isolated it into the attached standalone test case. Compiling it > > with > > gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize > > -o test test.c > > > > reproduces on gcc 8.2.0, dropping the optimization level fixes it. This > > was one of the "adding a printf made it work" things too. > > > > -Wstrict-aliasing=1 complains about the "register int *idataptr = > > (int*)dataptr;" cast. If I put "typedef int __attribute__((may_alias)) > > int_alias;" at the top and change the cast and type to int_alias, the > > results become correct. > > Thank you for the analysis! > > Patch attached, Carl Eugen > jrevdct.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > fef3d295836588ff8e619d4aa42247b4d2f25e93 > 0001-lavc-jrevdct-Avoid-an-aliasing-violation.patch > From e5403b832f2bcd360128d9986b602484e576c931 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Mon, 26 Nov 2018 00:43:46 +0100 > Subject: [PATCH] lavc/jrevdct: Avoid an aliasing violation. > > Fixes fate on different PowerPC systems with some compilers. > > Analyzed-by: Lauri Kasanen > --- > libavcodec/jrevdct.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/libavcodec/jrevdct.c b/libavcodec/jrevdct.c > index 3b15a52..c749468 100644 > --- a/libavcodec/jrevdct.c > +++ b/libavcodec/jrevdct.c > @@ -63,6 +63,7 @@ > */ > > #include "libavutil/common.h" > +#include "libavutil/intreadwrite.h" > > #include "dct.h" > #include "idctdsp.h" > @@ -234,7 +235,7 @@ void ff_j_rev_dct(DCTBLOCK data) > * row DCT calculations can be simplified this way. > */ > > -register int *idataptr = (int*)dataptr; > +register uint8_t *idataptr = (uint8_t*)dataptr; > > /* WARNING: we do the same permutation as MMX idct to simplify the > video core */ > @@ -254,10 +255,10 @@ void ff_j_rev_dct(DCTBLOCK data) >int16_t dcval = (int16_t) (d0 * (1 << PASS1_BITS)); >register int v = (dcval & 0x) | ((dcval * (1 << 16)) & > 0x); > > - idataptr[0] = v; > - idataptr[1] = v; > - idataptr[2] = v; > - idataptr[3] = v; > + AV_WN32(&idataptr[ 0], v); > + AV_WN32(&idataptr[ 4], v); > + AV_WN32(&idataptr[ 8], v); > + AV_WN32(&idataptr[12], v); this probably should be AV_WN32A() [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: always skip junk bytes before sync bytes
On Sun, Nov 25, 2018 at 12:18:15PM +0100, Paul B Mahol wrote: > Fixes #7278. > > Signed-off-by: Paul B Mahol > --- > libavcodec/ac3dec.c | 19 --- > libavformat/ac3dec.c | 2 +- > 2 files changed, 17 insertions(+), 4 deletions(-) this seems to break TESTeac3-5 stddev: 1071.76 PSNR: 35.73 MAXDIFF:11122 bytes: 3858432/ 2893824 MAXDIFF: |11122 - 0| >= 1 size: |3858432 - 2893824| >= 0 Test eac3-5 failed. Look at tests/data/fate/eac3-5.err for details. make: *** [fate-eac3-5] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add PCM-DVD encoder
2018-11-26 20:48 GMT+01:00, Paul B Mahol : > TODO: add >16 bit support, needs to muxer update. Please mention ticket #6784. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add PCM-DVD encoder
TODO: add >16 bit support, needs to muxer update.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/pcm-dvdenc.c | 159
3 files changed, 161 insertions(+)
create mode 100644 libavcodec/pcm-dvdenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 2840a8069f..5feadac729 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -737,6 +737,7 @@ OBJS-$(CONFIG_PCM_ALAW_DECODER) += pcm.o
OBJS-$(CONFIG_PCM_ALAW_ENCODER) += pcm.o
OBJS-$(CONFIG_PCM_BLURAY_DECODER) += pcm-bluray.o
OBJS-$(CONFIG_PCM_DVD_DECODER)+= pcm-dvd.o
+OBJS-$(CONFIG_PCM_DVD_ENCODER)+= pcm-dvdenc.o
OBJS-$(CONFIG_PCM_F16LE_DECODER) += pcm.o
OBJS-$(CONFIG_PCM_F24LE_DECODER) += pcm.o
OBJS-$(CONFIG_PCM_F32BE_DECODER) += pcm.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2c17db5a70..d70646e91a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -494,6 +494,7 @@ extern AVCodec ff_xma2_decoder;
extern AVCodec ff_pcm_alaw_encoder;
extern AVCodec ff_pcm_alaw_decoder;
extern AVCodec ff_pcm_bluray_decoder;
+extern AVCodec ff_pcm_dvd_encoder;
extern AVCodec ff_pcm_dvd_decoder;
extern AVCodec ff_pcm_f16le_decoder;
extern AVCodec ff_pcm_f24le_decoder;
diff --git a/libavcodec/pcm-dvdenc.c b/libavcodec/pcm-dvdenc.c
new file mode 100644
index 00..536b27dce6
--- /dev/null
+++ b/libavcodec/pcm-dvdenc.c
@@ -0,0 +1,159 @@
+/*
+ * LPCM codecs for PCM formats found in Video DVD streams
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct PCMDVDContext {
+uint8_t header[3]; // Header added to every frame
+int block_size; // Size of a block of samples in bytes
+int samples_per_block; // Number of samples per channel per block
+int groups_per_block;// Number of 20/24-bit sample groups per block
+uint8_t *extra_samples; // Pointer to leftover samples from a frame
+int extra_sample_count; // Number of leftover samples in the buffer
+} PCMDVDContext;
+
+static av_cold int pcm_dvd_encode_init(AVCodecContext *avctx)
+{
+PCMDVDContext *s = avctx->priv_data;
+int quant, freq;
+
+switch (avctx->sample_rate) {
+case 48000:
+freq = 0;
+break;
+case 96000:
+freq = 1;
+break;
+}
+
+switch (avctx->sample_fmt) {
+case AV_SAMPLE_FMT_S16:
+avctx->bits_per_coded_sample = 16;
+quant = 0;
+break;
+case AV_SAMPLE_FMT_S32:
+avctx->bits_per_coded_sample = 24;
+quant = 2;
+break;
+}
+
+avctx->bits_per_coded_sample = 16 + quant * 4;
+avctx->block_align = avctx->channels *
avctx->bits_per_coded_sample / 8;
+avctx->bit_rate = avctx->block_align * 8LL *
avctx->sample_rate;
+
+if (avctx->sample_fmt == AV_SAMPLE_FMT_S16) {
+s->samples_per_block = 1;
+s->block_size= avctx->channels * 2;
+} else {
+switch (avctx->channels) {
+case 1:
+case 2:
+case 4:
+/* one group has all the samples needed */
+s->block_size= 4 * avctx->bits_per_coded_sample / 8;
+s->samples_per_block = 4 / avctx->channels;
+s->groups_per_block = 1;
+break;
+case 8:
+/* two groups have all the samples needed */
+s->block_size= 8 * avctx->bits_per_coded_sample / 8;
+s->samples_per_block = 1;
+s->groups_per_block = 2;
+break;
+default:
+/* need avctx->channels groups */
+s->block_size= 4 * avctx->channels *
+ avctx->bits_per_coded_sample / 8;
+s->samples_per_block = 4;
+s->groups_per_block = avctx->channels;
+break;
+}
+}
+
+s->header[0] = 0x0c;
+s->header[1] = (quant << 6) | (freq << 4) | (avctx->channels - 1);
+s->header[2] = 0x80;
+
+avctx->frame_size = 2008 / s->block_size;
+
+return 0;
+}
+
+st
Re: [FFmpeg-devel] [PATCH] libavfilter: scale_cuda filter adds dynamic command values
‐‐‐ Original Message ‐‐‐
On Monday, 26 de November de 2018 20:10, Timo Rothenpieler
wrote:
> On 26.11.2018 19:09, msanders wrote:
>
> > Hi,
> > This patch adds command support for dynamic change the size in the
> > “scale_cuda” resize filter. In fact, it’s the first GPU filter accepting
> > realtime commands. Using similar changes it’s possible to port it to other
> > hwaccelerators. The only limitation is that the values cannot exceed the
> > initial values. It is therefore necessary to set up the graph with the
> > higher values you may need.
> > One example: { -filter_complex
> > "scale_cuda=720:576,hwdownload,format=nv12,zmq" }
> > And then you can use the or ZMQ messages to change the width and/or
> > height.
> > Warning: This patch requires, to have sense, to apply too this other patch
> > that fixes the hwdownload filter.
> > https://patchwork.ffmpeg.org/patch/11165/
>
> I'm not sure if this is such a good idea. There's a lot of places all
> over the codebase that have a hardcoded assumption about how hardware
> frames in general, and CUDA frames in particular work.
>
I think it's a good idea because: I implemented it and I'm using it. In
addition, it works!
For sure you can't change the HW frames, only the "size" of images in the HW
frames. That's all.
> A lot of code checks the width/height from the hwframes ctx instead of
> the frame itself, because it needs the real size(1088 for 1080p for
> example) of the underlying buffer at all times.
> So those consumers would straight up ignore any scaling done to the
> frames, reading messed up data instead.
>
For all checks that I have done, all works as expected.
Only the "hwdownload" has some troubles. But I also provided the patch that
solves it.
> On top of that, in the specific case of CUDA, the CUDA pix_fmt is
> defined with the assumption that the entire frame is in a single
> continuous buffer with all planes right after one another. This would
> most prominently affect nvenc, as its API only takes one lone CUdevptr
> as input, and then has a fixed idea about how the data behind it looks.
>
I take account of this in the code. See the part where I always use the
original (context) boundaries for secondary planes.
> So it would produce output with random data to the right and bottom of
> the scaled frame, still with the outer dimensions before the
> re-configuration.
>
No. The output is always close to the top (begining). No other alignement is
allowed. Nothing random at all.
> The only way this could possibly work is if a new hw_frames_ctx is
> created on reconfiguration.
No. This isn't viable. If you recreate the hw_context then the next HW filters
fails.
Please, belive me. I've already tried it and it doesn't work.
> With nvenc this would actually work without any changes, as it re-reads
> the width/height out of it on every frame already, and initially only
> gets the CUDA-Context and sw_pix_fmt out of it, so those would need to
> stay the same, which isn't an issue.
Why you like to "resize" before the "encoder"? This will produce a bitstream
with size changes. Not a good idea.
Think on what does the current "vf_scale"... that already supports live size
changes: It's useful when you're doing some filtering/processing. In such
situation it's good that the "scale_cuda" does equal to "scale" (aka dynamic
commands). Then you can do more work inside the GPU before downloading frames
to RAM (remember that with my patch for "hwdonwload" it works). Only think in
the wasted CPU consumed for a simple "scale" instead of "scale_cuda" when you
need "live size changes".
> But for a bunch of other hardware filters more work is needed. Specially
> as some parts overlap with other APIs.
I don't see the problem. Please explain it better.
Regards.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: scale_cuda filter adds dynamic command values
On 26.11.2018 19:09, msanders wrote:
Hi,
This patch adds command support for dynamic change the size in the “scale_cuda”
resize filter. In fact, it’s the first GPU filter accepting realtime commands.
Using similar changes it’s possible to port it to other hwaccelerators. The
only limitation is that the values cannot exceed the initial values. It is
therefore necessary to set up the graph with the higher values you may need.
One example: { -filter_complex "scale_cuda=720:576,hwdownload,format=nv12,zmq" }
And then you can use the or ZMQ messages to change the width and/or height.
Warning: This patch requires, to have sense, to apply too this other patch that
fixes the hwdownload filter.
https://patchwork.ffmpeg.org/patch/11165/
I'm not sure if this is such a good idea. There's a lot of places all
over the codebase that have a hardcoded assumption about how hardware
frames in general, and CUDA frames in particular work.
A lot of code checks the width/height from the hwframes ctx instead of
the frame itself, because it needs the real size(1088 for 1080p for
example) of the underlying buffer at all times.
So those consumers would straight up ignore any scaling done to the
frames, reading messed up data instead.
On top of that, in the specific case of CUDA, the CUDA pix_fmt is
defined with the assumption that the entire frame is in a single
continuous buffer with all planes right after one another. This would
most prominently affect nvenc, as its API only takes one lone CUdevptr
as input, and then has a fixed idea about how the data behind it looks.
So it would produce output with random data to the right and bottom of
the scaled frame, still with the outer dimensions before the
re-configuration.
The only way this could possibly work is if a new hw_frames_ctx is
created on reconfiguration.
With nvenc this would actually work without any changes, as it re-reads
the width/height out of it on every frame already, and initially only
gets the CUDA-Context and sw_pix_fmt out of it, so those would need to
stay the same, which isn't an issue.
But for a bunch of other hardware filters more work is needed. Specially
as some parts overlap with other APIs.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter: scale_cuda filter adds dynamic command values
Hi,
This patch adds command support for dynamic change the size in the “scale_cuda”
resize filter. In fact, it’s the first GPU filter accepting realtime commands.
Using similar changes it’s possible to port it to other hwaccelerators. The
only limitation is that the values cannot exceed the initial values. It is
therefore necessary to set up the graph with the higher values you may need.
One example: { -filter_complex "scale_cuda=720:576,hwdownload,format=nv12,zmq" }
And then you can use the or ZMQ messages to change the width and/or height.
Warning: This patch requires, to have sense, to apply too this other patch that
fixes the hwdownload filter.
https://patchwork.ffmpeg.org/patch/11165/From 46c58c1da02ba40c1fab0ec93febc995db90caca Mon Sep 17 00:00:00 2001
From: M. Sanders
Date: Mon, 26 Nov 2018 17:52:52 +
Subject: [PATCH 2/2] libavfilter: scale_cuda dynamic command values
---
libavfilter/vf_scale_cuda.c | 72 +--
1 file changed, 62 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index 53b7aa9..ac8f8cc 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -78,6 +78,8 @@ typedef struct CUDAScaleContext {
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
+int target_width;
+int target_height;
CUcontext cu_ctx;
CUevent cu_event;
@@ -314,9 +316,22 @@ static av_cold int cudascale_config_props(AVFilterLink
*outlink)
outlink->w = w;
outlink->h = h;
-ret = init_processing_chain(ctx, inlink->w, inlink->h, w, h);
-if (ret < 0)
-return ret;
+if (!s->frames_ctx) {
+ret = init_processing_chain(ctx, inlink->w, inlink->h, w, h);
+if (ret < 0)
+return ret;
+} else {
+// We are reconfiguring, so reuse the current hw_context
+av_log(s, AV_LOG_DEBUG, "Reusing the current hw_context.\n");
+if (s->planes_out && outlink->w > s->planes_out[0].width) {
+outlink->w = s->planes_out[0].width;
+av_log(s, AV_LOG_ERROR, "Impossible to resize above the Context
width.\n");
+}
+if (s->planes_out && outlink->h > s->planes_out[0].height) {
+outlink->h = s->planes_out[0].height;
+av_log(s, AV_LOG_ERROR, "Impossible to resize above the Context
height.\n");
+}
+}
av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d -> w:%d h:%d\n",
inlink->w, inlink->h, outlink->w, outlink->h);
@@ -329,6 +344,9 @@ static av_cold int cudascale_config_props(AVFilterLink
*outlink)
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
}
+s->target_width = outlink->w;
+s->target_height = outlink->h;
+
return 0;
fail:
@@ -375,11 +393,11 @@ static int scalecuda_resize(AVFilterContext *ctx,
1);
call_resize_kernel(s, s->cu_func_uchar, s->cu_tex_uchar, 1,
in->data[0]+in->linesize[0]*in->height,
in->width/2, in->height/2, in->linesize[0]/2,
- out->data[0]+out->linesize[0]*out->height,
out->width/2, out->height/2, out->linesize[0]/2,
+
out->data[0]+out->linesize[0]*s->planes_out[0].height, out->width/2,
out->height/2, out->linesize[0]/2,
1);
call_resize_kernel(s, s->cu_func_uchar, s->cu_tex_uchar, 1,
in->data[0]+
ALIGN_UP((in->linesize[0]*in->height*5)/4, s->tex_alignment), in->width/2,
in->height/2, in->linesize[0]/2,
- out->data[0]+(out->linesize[0]*out->height*5)/4,
out->width/2, out->height/2, out->linesize[0]/2,
+
out->data[0]+(out->linesize[0]*s->planes_out[0].height*5)/4, out->width/2,
out->height/2, out->linesize[0]/2,
1);
break;
case AV_PIX_FMT_YUV444P:
@@ -389,11 +407,11 @@ static int scalecuda_resize(AVFilterContext *ctx,
1);
call_resize_kernel(s, s->cu_func_uchar, s->cu_tex_uchar, 1,
in->data[0]+in->linesize[0]*in->height, in->width,
in->height, in->linesize[0],
- out->data[0]+out->linesize[0]*out->height,
out->width, out->height, out->linesize[0],
+
out->data[0]+out->linesize[0]*s->planes_out[0].height, out->width, out->height,
out->linesize[0],
1);
call_resize_kernel(s, s->cu_func_uchar, s->cu_tex_uchar, 1,
in->data[0]+in->linesize[0]*in->height*2,
in->width, in->height, in->linesize[0],
- out->data[0]+out->linesize[0]*out->height*2,
out->width, out->height, out->linesize[0],
+
out->data[0]+out->linesize[0]*s->planes_out[0].height*2, out->width,
out->height, out->linesize[0],
Re: [FFmpeg-devel] avdevice/v4l2-common: add Z16 pixel format
2018-11-26 16:35 GMT+01:00, Pablo Rubio Fernández : > Simple patch to work with Z16 pixel format as gray16le. Doesn't this break gray16 recordings with your v4l2 device? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
> > (alpha 12b encoding is probably > > easy to add) > > Are you sure alpha is 12 bit? As long as I remember, it is 16 bit. > > Alpha is stored in 16b, but like the input pix fmt is 10b or (later) 12b alpha, the alpha val is shift during encoding to obtain a 16b val. The right way will be to add yuv444p12_with16bAlpha, but probably not an easy task to integrate this inside swscale. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes
You assume that device ID returned from regular enumeration is the same as
device ID returned from clGetDeviceIDsFromD3D11KHR. It is not guaranteed and I
didn't try this. Also I would add tracing to ensure that
CL_CONTEXT_D3D11_DEVICE_KHR is actually set and clGetDeviceIDsFromD3D11KHR is
called. In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true. Also I
would trace other parameters to clCreateFromD3D11Texture2DKHR: memory flags and
texture descriptor.
BTW: does the interop work for NV or Intel?
Thanks,
Mikhail
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: November 25, 2018 5:22 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
>
> On 25/11/2018 21:28, Mironov, Mikhail wrote:
> > It seem that the failure is not in the new extension but before, in the
> interop from D3D11 to OCL. It can happen in two cases: OCL device/context
> are created without D3D11 device or format of the texture is not supported.
> NV12 is supported. I went through the latest ffmpeg snapshot and found that
> function opencl_enumerate_d3d11_devices() looks correct, pointer to the
> function is set to OpenCLDeviceSelector::enumerate_devices member but I
> cannot find a call to selector->enumerate_devices(). Instead
> opencl_enumerate_devices() is called directly. So my guess is that created
> OCL device is not created from D3D11.
>
> Hmm, right - patch just sent to fix the selection call.
>
> It doesn't actually make any difference to this case, though, since the filter
> made it choose the right device anyway and
> CL_CONTEXT_D3D11_DEVICE_KHR was always set when deriving from
> D3D11. (It could only have made a difference if there were other conflicting
> D3D11 devices it could have picked incorrectly.)
>
> > Just in case OCL device creation sample:
> > https://github.com/GPUOpen-
> LibrariesAndSDKs/AMF/blob/master/amf/public
> > /samples/CPPSamples/common/DeviceOpenCL.cpp
> >
> > Regarding the new split extension: here is a working snippet:
> > cl_mem clImage2D = 0;
> > cl_mem clImages[AMF_SURFACE_MAX_PLANES]; // index can be not 0 if
> > texture is allocated as an array.
> > clImage2D = clCreateFromD3D11Texture2DKHR(m_clContext, memflags,
> > pTexture, index, &clStatus);
>
> Where is the comment about index being nonzero coming from there?
> Other callers to this definitely start from a zero index. (I tried adding
> one to
> my index values but it didn't change the result.)
>
> >
> > for(int i = 0; i < planesNumber; i++)
> > {
> > clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D,
> > (cl_uint)i, &clStatus);
> >
> > }
> > // don’t forget to release clImages[i] and clImage2D
>
> Otherwise, that agrees with how I read the extension document.
>
> 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
[FFmpeg-devel] [PATCH] avdevice/v4l2-common: add Z16 pixel format
Simple patch to work with Z16 pixel format as gray16le.
From 39e24c9cbbdacc594e47112dabcaed777028d6b6 Mon Sep 17 00:00:00 2001
From: prubio
Date: Mon, 26 Nov 2018 10:04:07 +0100
Subject: [PATCH] avdevice/v4l2-common: add Z16 pixel format
Added Z16 pixel format. Works as gray16le.
---
libavdevice/v4l2-common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index 2d6bfac..7154548 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -43,6 +43,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32 },
{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32 },
{ AV_PIX_FMT_GRAY8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+#ifdef V4L2_PIX_FMT_Z16
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Z16},
+#endif
#ifdef V4L2_PIX_FMT_Y16
{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
#endif
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avdevice/v4l2-common: add Z16 pixel format
Simple patch to work with Z16 pixel format as gray16le.
From 39e24c9cbbdacc594e47112dabcaed777028d6b6 Mon Sep 17 00:00:00 2001
From: prubio
Date: Mon, 26 Nov 2018 10:04:07 +0100
Subject: [PATCH] avdevice/v4l2-common: add Z16 pixel format
Added Z16 pixel format. Works as gray16le.
---
libavdevice/v4l2-common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index 2d6bfac..7154548 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -43,6 +43,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32 },
{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32 },
{ AV_PIX_FMT_GRAY8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+#ifdef V4L2_PIX_FMT_Z16
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Z16},
+#endif
#ifdef V4L2_PIX_FMT_Y16
{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
#endif
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
> On 26 Nov 2018, at 15:28, Martin Vignali wrote: > > (alpha 12b encoding is probably > easy to add) Are you sure alpha is 12 bit? As long as I remember, it is 16 bit. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
> > So I applied these patches and it appears that ffmpeg will encode XQ as > 10-bit, but it will decode as 12-bit. Is this intentional? I worry that I > might have applied the patches incorrectly. And is it possible to add > 12-bit encoding? > > Hello, Seems like you applied patch "add 12b decoding in prores dec", and "add Proresxq in prores_aw". With these patchs, decoding of prores , and XQ, are in 12b But the encoding bitdepth is not modify (stay in 10b). The "Add Xq encoding patch", only define quantif matrix, and target size. Will be interesting to add later support to 12b input in prores_aw, but doesn't know where to start to add 12b DCT (alpha 12b encoding is probably easy to add) Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
> > +
> > +switch (pict->colorspace) {
> > +case AVCOL_SPC_BT709:
> > +case AVCOL_SPC_UNSPECIFIED:
> > +case AVCOL_SPC_SMPTE170M:
> > +case AVCOL_SPC_BT2020_NCL:
> > +colorspace = pict->colorspace;
> > +break;
> > +default:
> > +av_log(avctx, AV_LOG_DEBUG,
> > +"Frame colorspace %d are not supported in prores frame.
> Set prores frame value to unspecified\n", pict->colorspace);
> > +break;
> > +}
> > +*buf++ = color_primaries;
> > +*buf++ = color_trc;
> > +*buf++ = colorspace;
>
> we maybe should write a generic function that takes a list of supported
> types
> and the undefined one and then does the check, debug print and all that
> that could be used in other encoders too.
> just an idea, that can be done later
>
> the patch
> LGTM
>
>
Don't know for others codecs, but this check can also probably be add when
setting AvFrame color properties in prores dec.
As a generic function, do you mean something like this :
(If yes, where do you think it's better to declare this func)
(untested, and not sure, what is the right log level for this (debug or
warning ?))
int ff_check_value(AVCodecContext *avctx, const char * val_name, int val,
int * array_valid_values, int nb_values, int
default_value) {
int i;
for (i = 0 ; i < nb_values ; i ++) {
if (val == array_valid_values[i]){
return val;
}
}
/* val is not a valid value */
av_log(avctx, AV_LOG_DEBUG,
"%s %d are not supported. Set to default value : %d\n",
val_name, val, default_value);
return default_value;
}
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresdec : add 12b decoding support
> > +/* align height to 16, to avoid segfault */ > > +tframe.f->height = FFALIGN(avctx->height, 16); > > +tframe.f->width = FFALIGN(avctx->width, 16); > > +tframe.f->crop_bottom = tframe.f->height - avctx->height; > > + > > if ((ret = ff_thread_get_buffer(avctx, &tframe, 0)) < 0) > > return ret; > > Why is this now needed but was not before ? > Is avcodec_align_dimensions2() correct ? > > Hello, This is the part, where i'm not really sure about. Like it's only segfault when there is alpha, but segfault on luma decoding part and alpha decoding part. Seems like, i need to add YUVA4xxP12 in avcodec_align_dimensions2, to have the correct "height padding". Will test this, and send new patch. Thanks Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 23/11/2018 02:16, Michael Niedermayer wrote: > do we have some sample flv files that require this patchset / that have > discontinuites. I have many. I've mailed you one privately, while I work on getting a public one. > another thing i just realize now, why is this discontinuity issues coming up > now? flv support is very old. This should be a long standing issue Probably not many codebases check the DISCONT flag. I only just added proper discontinuity handling to some codebases this year, and that's why *I* noticed. Chances are most people use the ffmpeg cli which seems to handle stuff differently, and doesn't necessarily care about the flag. In my case, I only try to 'fix' discontinuities if they appear to be in a format that allows them, during indexing. I could add a workaround specific to FLV, or some threshold stuff, but I'd prefer that demuxers which may output discontinuous timestamps say they do. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] cbs: Add function to make content of a unit writable
This will enable us to change e.g. the parameter sets of H.2645 in ways
that would change the parsing process of future units. An example of
this is the h264_redundant_pps bsf.
The actual implementation of the underlying codec-dependent
make_writable functions is not contained in this commit.
Signed-off-by: Andreas Rheinhardt
---
Here is an updated patchset. Sorry for the unnecessary noise.
libavcodec/cbs.c | 21 +
libavcodec/cbs.h | 9 +
libavcodec/cbs_internal.h | 4
3 files changed, 34 insertions(+)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ecbf57c293..cb2ee3a769 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -665,3 +665,24 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
return 0;
}
+
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
+ void** content)
+{
+if (unit->content && (!unit->content_ref ||
+ !av_buffer_is_writable(unit->content_ref))) {
+int err;
+if (!ctx->codec->make_writable)
+return AVERROR_PATCHWELCOME;
+
+err = ctx->codec->make_writable(ctx, unit);
+if (err < 0)
+return err;
+
+if (content)
+*content = unit->content;
+}
+
+return 0;
+}
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 53ac360bb1..9bdc6aa5fd 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -352,5 +352,14 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
int position);
+/**
+ * Make the content of a unit writable.
+ *
+ * If content is supplied, *content will point to the unit's content on
success.
+ */
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
+ void **content);
+
#endif /* AVCODEC_CBS_H */
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 53f2e5d187..62a836af90 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -44,6 +44,10 @@ typedef struct CodedBitstreamType {
int (*read_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
+// Make a unit's content writable.
+int (*make_writable)(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit);
+
// Write the unit->data bitstream from unit->content.
int (*write_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] h264_redundant_pps: Make it reference-compatible
Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were parsed. This patch makes h264_redundant_pps
compatible with the reality of reference-counted parameter sets.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_redundant_pps_bsf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_redundant_pps_bsf.c
b/libavcodec/h264_redundant_pps_bsf.c
index 0b7888c97e..c484357942 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -40,8 +40,17 @@ typedef struct H264RedundantPPSContext {
static int h264_redundant_pps_fixup_pps(H264RedundantPPSContext *ctx,
-H264RawPPS *pps)
+CodedBitstreamUnit *unit)
{
+H264RawPPS *pps;
+int err;
+// The changes we are about to perform affect the parsing process,
+// so we must make sure that the PPS is writable, otherwise the
+// parsing of future slices will be incorrect and even raise errors.
+if ((err = ff_cbs_make_unit_writable(ctx->input, unit, NULL)) < 0)
+return err;
+pps = unit->content;
+
// Record the current value of pic_init_qp in order to fix up
// following slices, then overwrite with the global value.
ctx->current_pic_init_qp = pps->pic_init_qp_minus26 + 26;
@@ -89,7 +98,7 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
AVPacket *out)
if (nal->type == H264_NAL_SPS)
au_has_sps = 1;
if (nal->type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, nal->content);
+err = h264_redundant_pps_fixup_pps(ctx, nal);
if (err < 0)
goto fail;
if (!au_has_sps) {
@@ -151,7 +160,7 @@ static int h264_redundant_pps_init(AVBSFContext *bsf)
for (i = 0; i < au->nb_units; i++) {
if (au->units[i].type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, au->units[i].content);
+err = h264_redundant_pps_fixup_pps(ctx, &au->units[i]);
if (err < 0)
goto fail;
}
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] cbs_h2645: Implement copy-functions for parameter sets
and use them to replace the context's parameter sets.
This fixes a dangling pointers problem with the parameter sets
held in the CodedBitstreamH26xContext that occurs when the parameter
sets were not reference-counted initially.
The functions to free the parameter sets that have a special free
callback are now also created via the same macro as the copy functions.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 47 --
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 666970ed03..559290bd91 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -413,14 +413,25 @@ static int cbs_h2645_read_more_rbsp_data(GetBitContext
*gbc)
#undef byte_alignment
#undef allocate
-
-static void cbs_h264_free_pps(void *unit, uint8_t *content)
+static AVBufferRef *cbs_h264_copy_sps(const H264RawSPS *source)
{
-H264RawPPS *pps = (H264RawPPS*)content;
-av_buffer_unref(&pps->slice_group_id_ref);
-av_freep(&content);
+AVBufferRef *ref = av_buffer_alloc(sizeof(H264RawSPS));
+if (!ref)
+return NULL;
+memcpy(ref->data, source, sizeof(H264RawSPS));
+return ref;
}
+cbs_copy_free(h264, H264RawPPS, pps, slice_group_id,
+ pic_size_in_map_units_minus1, BYTES, 1)
+
+cbs_copy_free(h265, H265RawVPS, vps, extension_data.data,
+ extension_data.bit_length, BITS, 0)
+cbs_copy_free(h265, H265RawSPS, sps, extension_data.data,
+ extension_data.bit_length, BITS, 0)
+cbs_copy_free(h265, H265RawPPS, pps, extension_data.data,
+ extension_data.bit_length, BITS, 0)
+
static void cbs_h264_free_sei_payload(H264RawSEIPayload *payload)
{
switch (payload->payload_type) {
@@ -459,27 +470,6 @@ static void cbs_h264_free_slice(void *unit, uint8_t
*content)
av_freep(&content);
}
-static void cbs_h265_free_vps(void *unit, uint8_t *content)
-{
-H265RawVPS *vps = (H265RawVPS*)content;
-av_buffer_unref(&vps->extension_data.data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_sps(void *unit, uint8_t *content)
-{
-H265RawSPS *sps = (H265RawSPS*)content;
-av_buffer_unref(&sps->extension_data.data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_pps(void *unit, uint8_t *content)
-{
-H265RawPPS *pps = (H265RawPPS*)content;
-av_buffer_unref(&pps->extension_data.data_ref);
-av_freep(&content);
-}
-
static void cbs_h265_free_slice(void *unit, uint8_t *content)
{
H265RawSlice *slice = (H265RawSlice*)content;
@@ -721,6 +711,7 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext
*ctx,
return 0;
}
+
#define cbs_h2645_replace_ps(h26n, ps_name, ps_var, id_element) \
static int cbs_h26 ## h26n ## _replace_ ## ps_var(CodedBitstreamContext *ctx, \
CodedBitstreamUnit *unit) \
@@ -739,12 +730,10 @@ static int cbs_h26 ## h26n ## _replace_ ##
ps_var(CodedBitstreamContext *ctx, \
if (unit->content_ref) \
priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
else \
-priv->ps_var ## _ref[id] = av_buffer_alloc(sizeof(*ps_var)); \
+priv->ps_var ## _ref[id] = cbs_h26 ## h26n ## _copy_ ##
ps_var(ps_var); \
if (!priv->ps_var ## _ref[id]) \
return AVERROR(ENOMEM); \
priv->ps_var[id] = (H26 ## h26n ## Raw ## ps_name *)priv->ps_var ##
_ref[id]->data; \
-if (!unit->content_ref) \
-memcpy(priv->ps_var[id], ps_var, sizeof(*ps_var)); \
return 0; \
}
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] cbs: Add a macro to create functions for deep copying
Some structs in cbs (most importantly some of the parameter sets of
H.264/HEVC) can contain external buffers so that shallow copies are not
enough for them; furthermore, they need a special free-callback
function. The macro provided in this commit can be used to easily create
functions both for copying as well as freeing such structures.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_internal.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 62a836af90..dd45748c61 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -98,4 +98,57 @@ extern const CodedBitstreamType ff_cbs_type_mpeg2;
extern const CodedBitstreamType ff_cbs_type_vp9;
+enum {
+BITS,
+BYTES
+};
+
+// The following macro automatically creates both (deep) copy and
+// free functions for structs with exactly one internal buffer.
+
+#define cbs_copy_free(codec, type, var, buffer, size_element, size_offset,
size_unit) \
+static void cbs_ ## codec ## _free_ ## var(void *unit, uint8_t *content) \
+{ \
+type *var = (type *)content; \
+ \
+av_buffer_unref(&var->buffer ## _ref); \
+av_freep(&var); \
+} \
+ \
+static AVBufferRef *cbs_ ## codec ## _copy_ ## var(const type *source) \
+{ \
+AVBufferRef *copy_ref; \
+type *copy; \
+ \
+copy = av_malloc(sizeof(type)); \
+if (!copy) \
+return NULL; \
+memcpy(copy, source, sizeof(type)); \
+ \
+copy_ref = av_buffer_create((uint8_t*)copy, sizeof(type), \
+&cbs_ ## codec ## _free_ ## var, \
+NULL, 0); \
+if (!copy_ref) { \
+av_free(copy); \
+return NULL; \
+} \
+ \
+if (source->buffer) { \
+size_t size = (size_t)source->size_element + size_offset; \
+if (size_unit == BITS) \
+size = (size + 7) / 8; \
+ \
+copy->buffer ## _ref = av_buffer_alloc(size +
AV_INPUT_BUFFER_PADDING_SIZE); \
+if (!copy->buffer ## _ref) {\
+av_buffer_unref(©_ref); \
+return NULL; \
+} \
+copy->buffer = copy->buffer ## _ref->data; \
+memcpy(copy->buffer, source->buffer, size); \
+memset(copy->buffer + size, 0, AV_INPUT_BUFFER_PADDING_SIZE); \
+} \
+ \
+return copy_ref; \
+}
+
#endif /* AVCODEC_CBS_INTERNAL_H */
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] cbs_h2645: Implement functions to make a unit's content writable
These functions (which are only implemented for parameter sets) make it
possible to change the contents of the parameter sets as one pleases
without changing/breaking the parsing process of future access units.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 65 ++
1 file changed, 65 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 559290bd91..931c7fb2af 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1062,6 +1062,69 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext
*ctx,
return 0;
}
+static int cbs_h264_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit)
+{
+AVBufferRef *ref;
+
+switch (unit->type) {
+case H264_NAL_SPS:
+{
+ref = cbs_h264_copy_sps(unit->content);
+break;
+}
+case H264_NAL_PPS:
+{
+ref = cbs_h264_copy_pps(unit->content);
+break;
+}
+default:
+return AVERROR_PATCHWELCOME;
+}
+if (!ref)
+return AVERROR(ENOMEM);
+
+av_buffer_unref(&unit->content_ref);
+unit->content = ref->data;
+unit->content_ref = ref;
+
+return 0;
+}
+
+static int cbs_h265_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit)
+{
+AVBufferRef *ref;
+
+switch (unit->type) {
+case HEVC_NAL_VPS:
+{
+ref = cbs_h265_copy_vps(unit->content);
+break;
+}
+case HEVC_NAL_SPS:
+{
+ref = cbs_h265_copy_sps(unit->content);
+break;
+}
+case HEVC_NAL_PPS:
+{
+ref = cbs_h265_copy_pps(unit->content);
+break;
+}
+default:
+return AVERROR_PATCHWELCOME;
+}
+if (!ref)
+return AVERROR(ENOMEM);
+
+av_buffer_unref(&unit->content_ref);
+unit->content = ref->data;
+unit->content_ref = ref;
+
+return 0;
+}
+
static int cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
PutBitContext *pbc, const uint8_t *data,
size_t data_size, int data_bit_start)
@@ -1534,6 +1597,7 @@ const CodedBitstreamType ff_cbs_type_h264 = {
.split_fragment= &cbs_h2645_split_fragment,
.read_unit = &cbs_h264_read_nal_unit,
+.make_writable = &cbs_h264_make_unit_writable,
.write_unit= &cbs_h2645_write_nal_unit,
.assemble_fragment = &cbs_h2645_assemble_fragment,
@@ -1547,6 +1611,7 @@ const CodedBitstreamType ff_cbs_type_h265 = {
.split_fragment= &cbs_h2645_split_fragment,
.read_unit = &cbs_h265_read_nal_unit,
+.make_writable = &cbs_h265_make_unit_writable,
.write_unit= &cbs_h2645_write_nal_unit,
.assemble_fragment = &cbs_h2645_assemble_fragment,
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] lavc/qsvenc: add forced_idr option
This option can be used to repect original input I/IDR frame type.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 7 +++
libavcodec/qsvenc.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 948751d..3946c1d 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1192,6 +1192,13 @@ static int encode_frame(AVCodecContext *avctx,
QSVEncContext *q,
if (qsv_frame) {
surf = &qsv_frame->surface;
enc_ctrl = &qsv_frame->enc_ctrl;
+memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
+
+if (frame->pict_type == AV_PICTURE_TYPE_I) {
+enc_ctrl->FrameType = MFX_FRAMETYPE_I | MFX_FRAMETYPE_REF;
+if (q->forced_idr)
+enc_ctrl->FrameType |= MFX_FRAMETYPE_IDR;
+}
}
ret = av_new_packet(&new_pkt, q->packet_size);
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 055b4a6..fbdc199 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -87,6 +87,7 @@
{ "adaptive_i", "Adaptive I-frame placement",
OFFSET(qsv.adaptive_i), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE
}, \
{ "adaptive_b", "Adaptive B-frame placement",
OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE
}, \
{ "b_strategy", "Strategy to choose between I/P/B-frames",
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE
}, \
+{ "forced_idr", "Forcing I frames as IDR frames",
OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE
}, \
typedef int SetEncodeCtrlCB (AVCodecContext *avctx,
const AVFrame *frame, mfxEncodeCtrl* enc_ctrl);
@@ -168,6 +169,7 @@ typedef struct QSVEncContext {
#endif
char *load_plugins;
SetEncodeCtrlCB *set_encode_ctrl_cb;
+int forced_idr;
} QSVEncContext;
int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext *q);
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hwcontext_opencl: Only release command queue if it exists
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, November 26, 2018 3:16 AM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] hwcontext_opencl: Only release command
> queue if it exists
>
> If the frames context creation fails then the command queue reference
> need not exist when uninit is called.
> ---
> libavutil/hwcontext_opencl.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> index c745b91775..e6cef74269 100644
> --- a/libavutil/hwcontext_opencl.c
> +++ b/libavutil/hwcontext_opencl.c
> @@ -1750,10 +1750,13 @@ static void
> opencl_frames_uninit(AVHWFramesContext *hwfc)
> av_freep(&priv->mapped_frames);
> #endif
>
> -cle = clReleaseCommandQueue(priv->command_queue);
> -if (cle != CL_SUCCESS) {
> -av_log(hwfc, AV_LOG_ERROR, "Failed to release frame "
> - "command queue: %d.\n", cle);
> +if (priv->command_queue) {
> +cle = clReleaseCommandQueue(priv->command_queue);
> +if (cle != CL_SUCCESS) {
> +av_log(hwfc, AV_LOG_ERROR, "Failed to release frame "
> + "command queue: %d.\n", cle);
> +}
> +priv->command_queue = NULL;
Seems ok.
Ruiling
> }
> }
>
> --
> 2.19.1
> ___
> 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] [PATCH] swscale/ppc: Move VSX-using code to its own file
Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation" applied).
Can anyone test BE?
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/Makefile | 1 +
libswscale/ppc/swscale_altivec.c | 291 ++
libswscale/ppc/swscale_ppc_template.c | 217 +
libswscale/ppc/swscale_vsx.c | 164 +++
libswscale/swscale_internal.h | 1 +
5 files changed, 393 insertions(+), 281 deletions(-)
create mode 100644 libswscale/ppc/swscale_ppc_template.c
create mode 100644 libswscale/ppc/swscale_vsx.c
diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
index d1b596e..0a31a30 100644
--- a/libswscale/ppc/Makefile
+++ b/libswscale/ppc/Makefile
@@ -1,3 +1,4 @@
OBJS += ppc/swscale_altivec.o \
ppc/yuv2rgb_altivec.o \
ppc/yuv2yuv_altivec.o \
+ppc/swscale_vsx.o
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index 8c6056d..1d2b2fa 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b/libswscale/ppc/swscale_altivec.c
@@ -31,21 +31,14 @@
#include "yuv2rgb_altivec.h"
#include "libavutil/ppc/util_altivec.h"
-#if HAVE_ALTIVEC
+#if HAVE_ALTIVEC && HAVE_BIGENDIAN
#define vzero vec_splat_s32(0)
-#if HAVE_BIGENDIAN
#define GET_LS(a,b,c,s) {\
vector signed short l2 = vec_ld(((b) << 1) + 16, s);\
ls = vec_perm(a, l2, c);\
a = l2;\
}
-#else
-#define GET_LS(a,b,c,s) {\
-ls = a;\
-a = vec_vsx_ld(((b) << 1) + 16, s);\
-}
-#endif
#define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do {\
vector signed short ls;\
@@ -59,7 +52,6 @@
d2 = vec_add(d2, vf2);\
} while (0)
-#if HAVE_BIGENDIAN
#define LOAD_FILTER(vf,f) {\
vector unsigned char perm0 = vec_lvsl(joffset, f);\
vf = vec_ld(joffset, f);\
@@ -69,89 +61,7 @@
p = vec_lvsl(xoffset, s);\
ll1 = vec_ld(xoffset, s);\
}
-#else
-#define LOAD_FILTER(vf,f) {\
-vf = vec_vsx_ld(joffset, f);\
-}
-#define LOAD_L1(ll1,s,p){\
-ll1 = vec_vsx_ld(xoffset, s);\
-}
-#endif
-
-static void yuv2planeX_16_altivec(const int16_t *filter, int filterSize,
- const int16_t **src, uint8_t *dest,
- const uint8_t *dither, int offset, int x)
-{
-register int i, j;
-LOCAL_ALIGNED(16, int, val, [16]);
-vector signed int vo1, vo2, vo3, vo4;
-vector unsigned short vs1, vs2;
-vector unsigned char vf;
-vector unsigned int altivec_vectorShiftInt19 =
-vec_add(vec_splat_u32(10), vec_splat_u32(9));
-
-for (i = 0; i < 16; i++)
-val[i] = dither[(x + i + offset) & 7] << 12;
-
-vo1 = vec_ld(0, val);
-vo2 = vec_ld(16, val);
-vo3 = vec_ld(32, val);
-vo4 = vec_ld(48, val);
-
-for (j = 0; j < filterSize; j++) {
-unsigned int joffset=j<<1;
-unsigned int xoffset=x<<1;
-vector unsigned char perm;
-vector signed short l1,vLumFilter;
-LOAD_FILTER(vLumFilter,filter);
-vLumFilter = vec_splat(vLumFilter, 0);
-LOAD_L1(l1,src[j],perm);
-yuv2planeX_8(vo1, vo2, l1, src[j], x, perm, vLumFilter);
-yuv2planeX_8(vo3, vo4, l1, src[j], x + 8, perm, vLumFilter);
-}
-
-vo1 = vec_sra(vo1, altivec_vectorShiftInt19);
-vo2 = vec_sra(vo2, altivec_vectorShiftInt19);
-vo3 = vec_sra(vo3, altivec_vectorShiftInt19);
-vo4 = vec_sra(vo4, altivec_vectorShiftInt19);
-vs1 = vec_packsu(vo1, vo2);
-vs2 = vec_packsu(vo3, vo4);
-vf = vec_packsu(vs1, vs2);
-VEC_ST(vf, 0, dest);
-}
-
-
-static inline void yuv2planeX_u(const int16_t *filter, int filterSize,
-const int16_t **src, uint8_t *dest, int dstW,
-const uint8_t *dither, int offset, int x)
-{
-int i, j;
-
-for (i = x; i < dstW; i++) {
-int t = dither[(i + offset) & 7] << 12;
-for (j = 0; j < filterSize; j++)
-t += src[j][i] * filter[j];
-dest[i] = av_clip_uint8(t >> 19);
-}
-}
-
-static void yuv2planeX_altivec(const int16_t *filter, int filterSize,
- const int16_t **src, uint8_t *dest, int dstW,
- const uint8_t *dither, int offset)
-{
-int dst_u = -(uintptr_t)dest & 15;
-int i;
-
-yuv2planeX_u(filter, filterSize, src, dest, dst_u, dither, offset, 0);
-
-for (i = dst_u; i < dstW - 15; i += 16)
-yuv2planeX_16_altivec(filter, filterSize, src, dest + i, dither,
- offset, i);
-
-yuv2planeX_u(filter, filterSize, src, dest, dstW, dither, offset, i);
-}
-#if HAVE_BIGENDIAN
// The 3 above is 2 (filterSize == 4) + 1 (sizeof(short) == 2).
// The neat trick: We only care for half the elements,
@@ -187,191 +97,12 @@ stati
[FFmpeg-devel] [PATCH] libavfilter: fix hwdownload dynamic resizing
This patch resolves dynamic resizing changes in the hwdownload filter. See more info at: https://trac.ffmpeg.org/ticket/7564 Regards. M. SandersFrom 2efeb454400db117af276cdfd6a98a00b80ca114 Mon Sep 17 00:00:00 2001 From: M. Sanders Date: Mon, 26 Nov 2018 11:56:14 + Subject: [PATCH] libavfilter: fix hwdownload dynamic resizing --- libavfilter/vf_hwdownload.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c index 33af30c..dbc44b1 100644 --- a/libavfilter/vf_hwdownload.c +++ b/libavfilter/vf_hwdownload.c @@ -155,8 +155,8 @@ static int hwdownload_filter_frame(AVFilterLink *link, AVFrame *input) goto fail; } -output->width = outlink->w; -output->height = outlink->h; +output->width = input->width; +output->height = input->height; err = av_frame_copy_props(output, input); if (err < 0) -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
On Mon, 26 Nov 2018 00:45:26 +0100 Carl Eugen Hoyos wrote: > 2018-11-25 16:17 GMT+01:00, Lauri Kasanen : > > Hi, > > > > The lone power8 fate failing test seems like an aliasing issue. > > I've isolated it into the attached standalone test case. Compiling it > > with > > gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize > > -o test test.c > > > > reproduces on gcc 8.2.0, dropping the optimization level fixes it. This > > was one of the "adding a printf made it work" things too. > > > > -Wstrict-aliasing=1 complains about the "register int *idataptr = > > (int*)dataptr;" cast. If I put "typedef int __attribute__((may_alias)) > > int_alias;" at the top and change the cast and type to int_alias, the > > results become correct. > > Thank you for the analysis! > > Patch attached, Carl Eugen Tested, fixes the fate test for me. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Fix integer overflows in left shift in init_image()
mån 2018-11-26 klockan 02:57 +0100 skrev Michael Niedermayer:
> Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
> Fixes:
> 11377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5694319101476864
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> ---
> libavcodec/tiff.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 6271c937c3..751f23ef33 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -706,7 +706,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
> s->avctx->pix_fmt = s->palette_is_set ? AV_PIX_FMT_PAL8 :
> AV_PIX_FMT_GRAY8;
> break;
> case 10081:
> -switch (s->pattern[0] | (s->pattern[1] << 8) | (s->pattern[2] << 16)
> | (s->pattern[3] << 24)) {
> +switch (AV_RL32(s->pattern)) {
> case 0x02010100:
> s->avctx->pix_fmt = AV_PIX_FMT_BAYER_RGGB8;
> break;
> @@ -721,12 +721,12 @@ static int init_image(TiffContext *s, ThreadFrame
> *frame)
> break;
> default:
> av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> 0x%X\n",
> - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16
> | s->pattern[3] << 24);
> + AV_RL32(s->pattern));
> return AVERROR_PATCHWELCOME;
> }
> break;
> case 10121:
> -switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
> s->pattern[3] << 24) {
> +switch (AV_RL32(s->pattern)) {
> case 0x02010100:
> s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
> AV_PIX_FMT_BAYER_RGGB16BE;
> break;
> @@ -741,12 +741,12 @@ static int init_image(TiffContext *s, ThreadFrame
> *frame)
> break;
> default:
> av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> 0x%X\n",
> - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16
> | s->pattern[3] << 24);
> + AV_RL32(s->pattern));
> return AVERROR_PATCHWELCOME;
> }
> break;
> case 10161:
> -switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
> s->pattern[3] << 24) {
> +switch (AV_RL32(s->pattern)) {
> case 0x02010100:
> s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
> AV_PIX_FMT_BAYER_RGGB16BE;
> break;
> @@ -761,7 +761,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
> break;
> default:
> av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern:
> 0x%X\n",
> - s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16
> | s->pattern[3] << 24);
> + AV_RL32(s->pattern));
This is much nicer :)
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/dashenc: Fix AVDictionary leaks in case of various init errors.
On Wed, Nov 21, 2018 at 3:45 PM Jeyapal, Karthick wrote: > On 11/20/18 6:01 PM, Andrey Semashev wrote: > > On 11/18/18 1:55 PM, Jeyapal, Karthick wrote: > > > Thanks for sending these excellent patches. The entire patchset looks > > > good to me. > > > Also, many thanks for your patience and taking the earlier review > > > comments in the right spirit. > > > > Ping for merging it then? > Thanks for the ping. Pushed all the dashenc patches. > Left out the dashdec patch, as its maintainer has not commented yet. Maybe we > can wait for few more days before pushing the dashdec patch. Looks like noone will comment on the dashdec patch. Could you merge it, please? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
On Mon, Nov 26, 2018 at 8:06 AM Kieran O Leary wrote: > > > On Sat, 24 Nov 2018, 22:11 Martin Vignali >> Hello, >> >> Patch in attach add some improvments to prores aw encoder >> >> 012 : Add vendor option (code come from prores_ks encoder) >> 013 : Only write color properties, if defined in rdd36 (other values are >> "converted" to unspecified) >> 014 : Add XQ encoding support >> > > I hope to test these patches out today with 12-bit RGB DPX/FFV1 as input. > Is the XQ encoder intended to be 10 or 12-bit? > So I applied these patches and it appears that ffmpeg will encode XQ as 10-bit, but it will decode as 12-bit. Is this intentional? I worry that I might have applied the patches incorrectly. And is it possible to add 12-bit encoding? $ ./ffmpeg -f lavfi -i testsrc -c:v prores -profile:v 5 xq.mov ffmpeg version N-92541-g598755603c Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 9.0.0 (clang-900.0.39.2) configuration: libavutil 56. 24.101 / 56. 24.101 libavcodec 58. 40.100 / 58. 40.100 libavformat58. 23.100 / 58. 23.100 libavdevice58. 6.100 / 58. 6.100 libavfilter 7. 46.100 / 7. 46.100 libswscale 5. 4.100 / 5. 4.100 libswresample 3. 4.100 / 3. 4.100 Input #0, lavfi, from 'testsrc': Duration: N/A, start: 0.00, bitrate: N/A Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc File 'xq.mov' already exists. Overwrite ? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> prores (native)) Press [q] to stop, [?] for help Output #0, mov, to 'xq.mov': Metadata: encoder : Lavf58.23.100 Stream #0:0: Video: prores (XQ) (ap4x / 0x78347061), yuv444p10le, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc Metadata: encoder : Lavc58.40.100 prores frame=14747 fps=2015 q=-0.0 Lsize= 469689kB time=00:09:49.84 bitrate=6523.3kbits/s speed=80.6x video:469627kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.013138% Exiting normally, received signal 2. telecine:ffmpeg administrator$ ./ffmpeg -i xq.mov ffmpeg version N-92541-g598755603c Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 9.0.0 (clang-900.0.39.2) configuration: libavutil 56. 24.101 / 56. 24.101 libavcodec 58. 40.100 / 58. 40.100 libavformat58. 23.100 / 58. 23.100 libavdevice58. 6.100 / 58. 6.100 libavfilter 7. 46.100 / 7. 46.100 libswscale 5. 4.100 / 5. 4.100 libswresample 3. 4.100 / 3. 4.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'xq.mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf58.23.100 Duration: 00:09:49.88, start: 0.00, bitrate: 6522 kb/s Stream #0:0(eng): Video: prores (XQ) (ap4x / 0x78347061), yuv444p12le(tv, progressive), 320x240, 6521 kb/s, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default) Metadata: handler_name: VideoHandler encoder : Lavc58.40.100 prores Best, Kieran. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Added an option to ignore io errors
When dashenc has to run for long duration(say 24x7 live stream), one can enable
this option to ignore the io failure of few segment's upload due to an
intermittent network issues.
When the network connection recovers dashenc will continue with the upload of
the current segments, leading to the recovery of the stream.
---
doc/muxers.texi | 3 +++
libavformat/dashenc.c | 26 --
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a02ac01b55..f1cc6f5fee 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -300,6 +300,9 @@ If this flag is set, the dash segment files will be in in
ISOBMFF format.
@item webm
If this flag is set, the dash segment files will be in in WebM format.
+@item -ignore_io_errors @var{ignore_io_errors}
+Ignore IO errors during open and write. Useful for long-duration runs with
network output.
+
@end table
@anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 2f403257c0..92b09417df 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -138,6 +138,7 @@ typedef struct DASHContext {
int index_correction;
char *format_options_str;
SegmentType segment_type_option; /* segment type as specified in options
*/
+int ignore_io_errors;
} DASHContext;
static struct codec_string {
@@ -846,7 +847,10 @@ static int write_manifest(AVFormatContext *s, int final)
av_dict_free(&opts);
if (ret < 0) {
av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
temp_filename);
-return ret;
+if (c->ignore_io_errors)
+return 0;
+else
+return ret;
}
out = c->mpd_out;
avio_printf(out, "\n");
@@ -937,7 +941,10 @@ static int write_manifest(AVFormatContext *s, int final)
av_dict_free(&opts);
if (ret < 0) {
av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
temp_filename);
-return ret;
+if (c->ignore_io_errors)
+return 0;
+else
+return ret;
}
ff_hls_write_playlist_version(c->m3u8_out, 7);
@@ -1565,8 +1572,12 @@ static int dash_write_packet(AVFormatContext *s,
AVPacket *pkt)
set_http_options(&opts, c);
ret = dashenc_io_open(s, &os->out, os->temp_path, &opts);
av_dict_free(&opts);
-if (ret < 0)
-return ret;
+if (ret < 0) {
+if (c->ignore_io_errors)
+return 0;
+else
+return ret;
+}
}
//write out the data immediately in streaming mode
@@ -1577,9 +1588,11 @@ static int dash_write_packet(AVFormatContext *s,
AVPacket *pkt)
write_styp(os->ctx->pb);
avio_flush(os->ctx->pb);
len = avio_get_dyn_buf (os->ctx->pb, &buf);
-avio_write(os->out, buf + os->written_len, len - os->written_len);
+if (os->out) {
+avio_write(os->out, buf + os->written_len, len - os->written_len);
+avio_flush(os->out);
+}
os->written_len = len;
-avio_flush(os->out);
}
return ret;
@@ -1670,6 +1683,7 @@ static const AVOption options[] = {
{ "auto", "select segment file format based on codec", 0,
AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_AUTO }, 0, UINT_MAX, E,
"segment_type"},
{ "mp4", "make segment file in ISOBMFF format", 0, AV_OPT_TYPE_CONST,
{.i64 = SEGMENT_TYPE_MP4 }, 0, UINT_MAX, E, "segment_type"},
{ "webm", "make segment file in WebM format", 0, AV_OPT_TYPE_CONST, {.i64
= SEGMENT_TYPE_WEBM }, 0, UINT_MAX, E, "segment_type"},
+{ "ignore_io_errors", "Ignore IO errors during open and write. Useful for
long-duration runs with network output", OFFSET(ignore_io_errors),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ NULL },
};
--
2.17.1 (Apple Git-112)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Handled the error from dashenc_io_open()
---
libavformat/dashenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 6ce70e0076..2f403257c0 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -527,8 +527,12 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ?
"%s.tmp" : "%s", filename_hls);
set_http_options(&http_opts, c);
-dashenc_io_open(s, &c->m3u8_out, temp_filename_hls, &http_opts);
+ret = dashenc_io_open(s, &c->m3u8_out, temp_filename_hls, &http_opts);
av_dict_free(&http_opts);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
temp_filename_hls);
+return;
+}
for (i = start_index; i < os->nb_segments; i++) {
Segment *seg = os->segments[i];
double duration = (double) seg->duration / timescale;
--
2.17.1 (Apple Git-112)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.
On 25/11/2018 15:05, Mark Thompson wrote: I see what you're trying to do here, but I'm not sure that overloading this option is the best way to achieve it. This option has a specific meaning in terms of the consumer of the frames, and is intended to be negotiated (any consumers of hardware frames should declare how many they will hold onto at most in a given configuration), but since that is very much configuration-dependent it hasn't yet been done. Setting it to, for example, -3 ends up saying "I want the frame pool to be large enough for the consumer to be able to hold onto at most -2 frames at any given time", which is nonsensical in the meaning of the particular option. Presumably the case you're actually imagining wanting this option is to reduce memory use when a stream doesn't actually use the maximum number of reference frames - given that this is generally signalled in the stream, can you instead propagate the real number of reference frames into the allocation so that it uses the correct number rather than the maximum? Alternatively, if you have some particular program in mind then it could just use hw_frames_ctx rather than hw_device_ctx and do this allocation itself. The case I'm targeting is that for example the CUDA yadif filter needs to hold onto a buffer of up to 2 frames, which it in turn steals from the nvdec decoders buffer. But if you don't use yadif, that's 2 unused frames, which is potentially quite a bit of VRAM. nvdec already uses some logic based on the stream, but that logic is sometimes wrong in both directions. So the idea here is to give the user an option to optimize a given commandline for memory use. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hwcontext_opencl: Use correct function to enumerate devices
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Mark Thompson > Sent: Monday, November 26, 2018 6:08 AM > To: FFmpeg development discussions and patches > Subject: [FFmpeg-devel] [PATCH] hwcontext_opencl: Use correct function to > enumerate devices > > --- > libavutil/hwcontext_opencl.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c > index e6cef74269..6a26354c87 100644 > --- a/libavutil/hwcontext_opencl.c > +++ b/libavutil/hwcontext_opencl.c > @@ -542,9 +542,9 @@ static int > opencl_device_create_internal(AVHWDeviceContext *hwdev, > continue; > } > > -err = opencl_enumerate_devices(hwdev, platforms[p], platform_name, > - &nb_devices, &devices, > - selector->context); > +err = selector->enumerate_devices(hwdev, platforms[p], platform_name, > + &nb_devices, &devices, > + selector->context); I think it is better to check enumerate_devices against null pointer before calling it, although it should works well currently. Ruiling > if (err < 0) > continue; > > -- > 2.19.1 > > ___ > 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] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
On Sat, 24 Nov 2018, 22:11 Martin Vignali Hello, > > Patch in attach add some improvments to prores aw encoder > > 012 : Add vendor option (code come from prores_ks encoder) > 013 : Only write color properties, if defined in rdd36 (other values are > "converted" to unspecified) > 014 : Add XQ encoding support > I hope to test these patches out today with 12-bit RGB DPX/FFV1 as input. Is the XQ encoder intended to be 10 or 12-bit? Kieran. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey
On 24.11.2018 16:32, Tomas Härdin wrote: [...] While I'm in here I have a small suggestion: talking is better than writing when it comes to interpersonal conflicts. Using Mumble or Jingle or whatever and getting the relevant people to talk can be a good way to avoid more drastic measures. Unless of course someone's just being an ass to be an ass, but I haven't noticed that yet on here. Seems like a good idea. And the talking could be moderated by a person neutral to the conflict. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8
On Mon, 26 Nov 2018 11:03:55 +0300 Michael Kostylev wrote: > > http://fate.xffm.org/?sort=arch > /ppc Yeah, mentioned in the commit message. Follow-up patch coming today. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
