[libav-devel] [PATCH] Adding / Changing some NVENC options Naming

[Ben Chang]

Change profile option high_444 to high444p. And add auto option in level. This 
is to keep consistent naming between libav and ffmpeg and avoid confusion for 
users.

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.
---


libav_nvenc_option.patch
Description: libav_nvenc_option.patch
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/10] lavc: Add a new function to probe hardware support

[wm4]

On Tue, 28 Mar 2017 13:27:49 +0100
Mark Thompson  wrote:

> On 28/03/17 11:18, wm4 wrote:
> > On Mon, 27 Mar 2017 21:38:12 +0100
> > Mark Thompson  wrote:
> [...]
> >> +int avcodec_probe_hw(AVCodecContext *avctx, AVBufferRef *hw_frames_ref);  
> > 
> > This API still makes me a bit uneasy. Regular get_format hwaccel init
> > relies on the fact that the decoder has set some fields from parsing
> > the bit stream, like the current sw_pixfmt or frame size. These aren't
> > necessarily available on a "fresh" AVCodecContext (not even if
> > extradata is available).
> > 
> > So normally, the only time this will work properly is in the get_format
> > callback. Which is ok, but which I think isn't the entire intention? I
> > think I'd be fine with allowing this call only during get_format or so.  
> 
> It's certainly the intent that this is usable outside get format.  In the 
> most general case, probing with a codec, a profile, and maybe some dimensions 
> can test the hardware support without any stream at all.

The profile isn't necessarily set at this point, though. (Actually
nothing needs to be set for h264 decoding if the input is Annex B
format.)

> > Or maybe it's supposed to return "approximate" results outside of
> > get_format in the first place.
> > 
> > (For encoding on the other hand it's probably fine - though I'm not
> > sure if this is supposed to be called before or after opening the
> > context.)  
> 
> Before.  I didn't provide a VAAPI implementation for encode because with the 
> current design it requires some nontrivial rearrangement of code to work 
> (stuff done by the current per-codec init functions needs to move to a 
> callback so that it's usable at other times - I'll do this if once we have 
> some agreement on the API).
> 
> > As a minor nit, this can't distinguish between required initial pool
> > size and upper bound on pool size. Users who want to preallocate frames
> > with e.g. vdpau would want to know the latter. (Well, I don't want
> > that, and see no reason why anyone would want it, so I officially don't
> > care about this argument.)  
> 
> My intent is that for now the decoder would always allocate the returned 
> initial_pool_size + extra_hw_frames, so a user would do the same.  (They 
> control extra_hw_frames so how many more they have is completely up to them, 
> but it works the same whether they are doing the allocation or lavc is.)

Yeah, this comment of mine was just a distraction anyway, sorry about
that.

> > I'll make full use of my permission to bikeshed, so here is a different
> > API that impractically changes everything:
> > 
> > Proposal 1:
> > 
> > Add new init_hw_device and init_hw_frames callbacks:
> > 
> >   /*
> >* Create a hw device and set ctx->hw_device_ctx. This might be used
> >* for hardware decoding. If ENOSYS is returned, the next hwaccel
> >* method is tried, and if all fail, software decoding is used.
> >*
> >* If hw_device_ctx is already set, this callback is not used, and
> >* does not need to be set.
> >*
> >* If internal reinit is done (like on flush or if the codec
> >* parameters change), hw_device_ctx is cleared, and this callback
> >* can be called again.
> >*/
> >   int (*init_hw_device)(AVCodecContext *ctx, AVHWDeviceType type);
> > 
> >   /*
> >* When this is called, ctx->hw_frames_ctx is already setup in a basic
> >* way (such as frame dimensions and surface format). This callback
> >* can be used to refine the frame parameters further.
> >*/
> >   int (*init_hw_frames)(AVCodecContext *ctx);  
> 
> Hmm, that only covers the inline decode case, but it does do it rather well.

init_hw_device, sure.

init_hw_frames could be used by "full" hw decoders if applicable.

Yeah, this doesn't care about encoding, if you mean that. (Haven't
thought about that.)

> > Proposal 2:
> > 
> > Add a mechanism to let the caller setup parameters in advance, and
> > letting the hwaccel code use these parameters without needing callbacks
> > back to user code.
> > 
> > Proposal 2a:
> > 
> > Add these fields to AVCodecContext:
> > 
> >   AVDictionary *hw_frames_params;
> >   void *hw_frames_opaque_params; // AVDictionary can't have pointers
> >   AVHWDeviceType hw_frames_opaque_params_type;
> > 
> > Proposal 2b:
> > 
> > Add this field to AVCodecContext:
> > 
> >   /*
> >* When allocating a new hw_frames_ctx, use the parameters found in
> >* this context as defaults (if the device type matches). The pixel
> >* format and size will be changed, and the number of initial pool
> >* frames can be extended.
> >*/
> >   AHWFramesContext *hw_frames_template;  
> 
> I think this proposal is horrible.

I think 2b is actually not that terrible, but point taken. It's
probably also not upwards compatible enough for whatever future things
we might want to do.

> > Proposal 3:
> > 
> > Use your API, and restrict when/where it's allowed to be called.  
> 
> 

Re: [libav-devel] [PATCH 03/10] lavc: Add a new function to probe hardware support

[Mark Thompson]

On 28/03/17 11:18, wm4 wrote:
> On Mon, 27 Mar 2017 21:38:12 +0100
> Mark Thompson  wrote:
> 
>> This also adds a new field to AVHWAccel to set supported hardware device
>> types, so that we can query the right hwaccel.
>> ---
>> Not entirely sure that the AVCodecContext should be the first argument of 
>> probe_hw() - AVCodecParameters might be nicer, but we are likely to end up 
>> needing an AVCodecContext anyway.  (More generally, please bikeshed freely 
>> over naming and structures used.)
>>
>> The probe_hw() function on the D*VA hwaccel would be where the extra 
>> alignment gets set (when AVCodecContext.hw_device_ctx is not used).
>>
>>
>>  doc/APIchanges|  3 +++
>>  libavcodec/avcodec.h  | 51 +
>>  libavcodec/decode.c   | 53 
>> ---
>>  libavcodec/encode.c   | 13 +
>>  libavcodec/internal.h | 10 ++
>>  libavcodec/utils.c| 15 +++
>>  6 files changed, 138 insertions(+), 7 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 5da821c90..649d35a08 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>>  
>>  API changes, most recent first:
>>  
>> +2017-04-xx - xxx - lavc 58.x+1.0 - avcodec.h
>> +  Add AVHWAccel.device_type and avcodec_probe_hw().
>> +
>>  2017-04-xx - xxx - lavc 58.x.y+1 - avcodec.h
>>Add AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH.
>>  
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 2aa70ca4f..8f7293d02 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -35,6 +35,7 @@
>>  #include "libavutil/cpu.h"
>>  #include "libavutil/dict.h"
>>  #include "libavutil/frame.h"
>> +#include "libavutil/hwcontext.h"
>>  #include "libavutil/log.h"
>>  #include "libavutil/pixfmt.h"
>>  #include "libavutil/rational.h"
>> @@ -2857,6 +2858,15 @@ typedef struct AVCodec {
>>   * packets before decoding.
>>   */
>>  const char *bsfs;
>> +
>> +/**
>> + * Test support for the given encode/decode parameters, and if possible
>> + * set the fields in the frames context to a set of usable values.
>> + *
>> + * If a hwaccel is used with a decoder and it also has a probe_hw()
>> + * function, that will be called instead of this.
>> + */
>> +int (*probe_hw)(AVCodecContext *avctx, AVHWFramesContext *hw_frames);
>>  } AVCodec;
>>  
>>  /**
>> @@ -2898,6 +2908,11 @@ typedef struct AVHWAccel {
>>   */
>>  int capabilities;
>>  
>> +/**
>> + * Hardware device type which this hwaccel can use.
>> + */
>> +enum AVHWDeviceType device_type;
>> +
>>  /*
>>   * No fields below this line are part of the public API. They
>>   * may not be used outside of libavcodec and can be changed and
>> @@ -2988,6 +3003,11 @@ typedef struct AVHWAccel {
>>   * Internal hwaccel capabilities.
>>   */
>>  int caps_internal;
>> +
>> +/**
>> + * Probe hardware for support and parameters.
>> + */
>> +int (*probe_hw)(AVCodecContext *avctx, AVHWFramesContext *hw_frames);
>>  } AVHWAccel;
>>  
>>  /**
>> @@ -4927,6 +4947,37 @@ const AVCodecDescriptor 
>> *avcodec_descriptor_get_by_name(const char *name);
>>  AVCPBProperties *av_cpb_properties_alloc(size_t *size);
>>  
>>  /**
>> + * Probe hardware support for the given codec parameters.
>> + *
>> + * For decoders, it tests whether a stream with the given parameters can be
>> + * decoded on the given device.  For encoders, it tests whether encoding 
>> with
>> + * the given parameters is possible on the device.
>> + *
>> + * On successful return, the fields of hw_frames_ref are set such that, once
>> + * initialised, it will be usable as AVCodecContext.hw_frames_ctx.  If the
>> + * user has additional requirements to apply to the frames context (for
>> + * example, for a larger pool size or for frames created with some system-
>> + * specific attribute) then they should be applied after this call but 
>> before
>> + * calling av_hwframe_ctx_init().
>> + *
>> + * The device to use is provided as the allocating context of hw_frames_ref.
>> + * (Even if set, the hw_frames_ctx and hw_device_ctx fields of avctx are
>> + * ignored.)
>> + *
>> + * @param avctx Codec context with relevant fields set.  It need not have 
>> been
>> + *  opened.
>> + * @param hw_frames_ref A reference to a newly-allocated AVHWFramesContext,
>> + *  which will be used to return the result.
>> + * @return 0 on success, otherwise negative error code:
>> + * AVERROR(ENOSYS): This function is not implemented (hardware support
>> + *  may or may not be available).
>> + * AVERROR(ENODEV): The device is not usable.
>> + * AVERROR(EINVAL): The codec parameters are not supported.
>> + * Other errors:Probing failed for some other 

Re: [libav-devel] [PATCH 09/10] lavfi/qsv: Use extra_hw_frames setting when allocating output frames

[Luca Barbato]

On 27/03/2017 22:38, Mark Thompson wrote:
> The deinterlacer does not change, because it does not allocate any new
> frames (for output it uses the same pool as the input).
> ---
>  libavfilter/vf_scale_qsv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> index 8ef77835d..aed74aa8b 100644
> --- a/libavfilter/vf_scale_qsv.c
> +++ b/libavfilter/vf_scale_qsv.c
> @@ -193,7 +193,7 @@ static int init_out_pool(AVFilterContext *ctx,
>  out_frames_ctx->width = FFALIGN(out_width,  32);
>  out_frames_ctx->height= FFALIGN(out_height, 32);
>  out_frames_ctx->sw_format = out_format;
> -out_frames_ctx->initial_pool_size = 32;
> +out_frames_ctx->initial_pool_size = FFMAX(32, 4 + ctx->extra_hw_frames);
>  
>  out_frames_hwctx->frame_type = in_frames_hwctx->frame_type;
>  
> 

Probably ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] Changing AV_PIX_FMT_NONE from -1 to 0

[Luca Barbato]

On 28/03/2017 12:43, wm4 wrote:
> I propose that AV_PIX_FMT_NONE is changed from -1 to 0. The reason is
> that default-initializing an AVPixelFormat should set an invalid or
> neutral value, instead of a "random" valid value.
> 
> Currently, 0 means AV_PIX_FMT_YUV420P, which is confusing and can lead
> to errors, especially since almost all video is yuv420p anyway.
> 
> The only problem I see with this is that some code does "<0" to check
> for an "unset" format. Some code even uses "-1" instead of the enum
> constants, like avcodec_parameters_alloc(). This code would have to be
> changed. (You could consider it "buggy" because it didn't use the enum
> constant and hardcoded the exact integer values, even though that was
> not documented as allowed.)
> 
> The same applies to AV_SAMPLE_FMT_NONE (which currently is -1).

Probably it should not hurt. I'd like to progress with the
AVPixelFormaton stuff sooner or later, you might be interested =)

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 2/2] Use LOCAL_ALIGNED_32 instead of LOCAL_ALIGNED(32

[Martin Storsjö]

This allows using compiler attributes for aligning the local variables,
in the cases where the compiler supports such alignment for stack variables.

libavutil/internal.h needs to include mem.h, since it uses
the DECLARE_ALIGNED macro.
---
 libavcodec/dcadec.c   |  4 ++--
 libavcodec/lpc.c  |  2 +-
 libavcodec/ra288.c|  6 +++---
 libavutil/internal.h  |  1 +
 libavutil/tests/float_dsp.c   | 46 +--
 libavutil/tests/lls.c |  2 +-
 tests/checkasm/audiodsp.c | 16 +++
 tests/checkasm/fmtconvert.c   |  6 +++---
 tests/checkasm/hevc_add_res.c |  8 
 tests/checkasm/hevc_idct.c|  8 
 tests/checkasm/synth_filter.c | 20 +--
 tests/checkasm/vp9dsp.c   | 12 +--
 12 files changed, 66 insertions(+), 65 deletions(-)

diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index fa2a240..c3c88c1 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -937,7 +937,7 @@ static int dca_filter_channels(DCAContext *s, int 
block_index, int upsample)
 int k;
 
 if (upsample) {
-LOCAL_ALIGNED(32, float, samples, [DCA_SUBBANDS_X96K], 
[SAMPLES_PER_SUBBAND]);
+LOCAL_ALIGNED_32(float, samples, [DCA_SUBBANDS_X96K], 
[SAMPLES_PER_SUBBAND]);
 
 if (!s->qmf64_table) {
 s->qmf64_table = qmf64_precompute();
@@ -962,7 +962,7 @@ static int dca_filter_channels(DCAContext *s, int 
block_index, int upsample)
 }
 } else {
 /* 32 subbands QMF */
-LOCAL_ALIGNED(32, float, samples, [DCA_SUBBANDS], 
[SAMPLES_PER_SUBBAND]);
+LOCAL_ALIGNED_32(float, samples, [DCA_SUBBANDS], 
[SAMPLES_PER_SUBBAND]);
 
 for (k = 0; k < s->audio_header.prim_channels; k++) {
 int channel = s->channel_order_tab[k];
diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
index 1482e57..7305de6 100644
--- a/libavcodec/lpc.c
+++ b/libavcodec/lpc.c
@@ -204,7 +204,7 @@ int ff_lpc_calc_coefs(LPCContext *s,
 
 if (lpc_type == FF_LPC_TYPE_CHOLESKY) {
 LLSModel m[2];
-LOCAL_ALIGNED(32, double, var, [FFALIGN(MAX_LPC_ORDER+1,4)]);
+LOCAL_ALIGNED_32(double, var, [FFALIGN(MAX_LPC_ORDER+1,4)]);
 double av_uninit(weight);
 memset(var, 0, FFALIGN(MAX_LPC_ORDER+1,4)*sizeof(*var));
 
diff --git a/libavcodec/ra288.c b/libavcodec/ra288.c
index c457d0c..d43c39c 100644
--- a/libavcodec/ra288.c
+++ b/libavcodec/ra288.c
@@ -136,9 +136,9 @@ static void do_hybrid_window(RA288Context *ractx,
 int i;
 float buffer1[MAX_BACKWARD_FILTER_ORDER + 1];
 float buffer2[MAX_BACKWARD_FILTER_ORDER + 1];
-LOCAL_ALIGNED(32, float, work, [FFALIGN(MAX_BACKWARD_FILTER_ORDER +
-MAX_BACKWARD_FILTER_LEN   +
-MAX_BACKWARD_FILTER_NONREC, 16)]);
+LOCAL_ALIGNED_32(float, work, [FFALIGN(MAX_BACKWARD_FILTER_ORDER +
+   MAX_BACKWARD_FILTER_LEN   +
+   MAX_BACKWARD_FILTER_NONREC, 16)]);
 
 ractx->fdsp.vector_fmul(work, window, hist, FFALIGN(order + n + non_rec, 
16));
 
diff --git a/libavutil/internal.h b/libavutil/internal.h
index d96762c..fcec798 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -38,6 +38,7 @@
 #include "attributes.h"
 #include "dict.h"
 #include "macros.h"
+#include "mem.h"
 #include "pixfmt.h"
 
 #if ARCH_X86
diff --git a/libavutil/tests/float_dsp.c b/libavutil/tests/float_dsp.c
index ab6bf6a..17728e0 100644
--- a/libavutil/tests/float_dsp.c
+++ b/libavutil/tests/float_dsp.c
@@ -85,8 +85,8 @@ static int compare_doubles(const double *a, const double *b, 
int len,
 static int test_vector_fmul(AVFloatDSPContext *fdsp, AVFloatDSPContext *cdsp,
 const float *v1, const float *v2)
 {
-LOCAL_ALIGNED(32, float, cdst, [LEN]);
-LOCAL_ALIGNED(32, float, odst, [LEN]);
+LOCAL_ALIGNED_32(float, cdst, [LEN]);
+LOCAL_ALIGNED_32(float, odst, [LEN]);
 int ret;
 
 cdsp->vector_fmul(cdst, v1, v2, LEN);
@@ -102,8 +102,8 @@ static int test_vector_fmul(AVFloatDSPContext *fdsp, 
AVFloatDSPContext *cdsp,
 static int test_vector_fmac_scalar(AVFloatDSPContext *fdsp, AVFloatDSPContext 
*cdsp,
const float *v1, const float *src0, float 
scale)
 {
-LOCAL_ALIGNED(32, float, cdst, [LEN]);
-LOCAL_ALIGNED(32, float, odst, [LEN]);
+LOCAL_ALIGNED_32(float, cdst, [LEN]);
+LOCAL_ALIGNED_32(float, odst, [LEN]);
 int ret;
 
 memcpy(cdst, v1, LEN * sizeof(*v1));
@@ -121,8 +121,8 @@ static int test_vector_fmac_scalar(AVFloatDSPContext *fdsp, 
AVFloatDSPContext *c
 static int test_vector_fmul_scalar(AVFloatDSPContext *fdsp, AVFloatDSPContext 
*cdsp,
const float *v1, float scale)
 {
-LOCAL_ALIGNED(32, float, cdst, [LEN]);
-LOCAL_ALIGNED(32, float, odst, [LEN]);
+LOCAL_ALIGNED_32(float, cdst, [LEN]);
+   

[libav-devel] [PATCH 1/2] atrac3plusdsp: Use LOCAL_ALIGNED for stack variables

[Martin Storsjö]

This fixes warnings like these with ARMCC:
alignment for an auto object may not be larger than 8
---
 libavcodec/atrac3plusdsp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/atrac3plusdsp.c b/libavcodec/atrac3plusdsp.c
index 468f098..c1a54ae 100644
--- a/libavcodec/atrac3plusdsp.c
+++ b/libavcodec/atrac3plusdsp.c
@@ -177,12 +177,14 @@ static void waves_synth(Atrac3pWaveSynthParams 
*synth_param,
 void ff_atrac3p_generate_tones(Atrac3pChanUnitCtx *ch_unit, AVFloatDSPContext 
*fdsp,
int ch_num, int sb, float *out)
 {
-DECLARE_ALIGNED(32, float, wavreg1)[128] = { 0 };
-DECLARE_ALIGNED(32, float, wavreg2)[128] = { 0 };
+LOCAL_ALIGNED_32(float, wavreg1, [128]);
+LOCAL_ALIGNED_32(float, wavreg2, [128]);
 int i, reg1_env_nonzero, reg2_env_nonzero;
 Atrac3pWavesData *tones_now  = 
_unit->channels[ch_num].tones_info_prev[sb];
 Atrac3pWavesData *tones_next = _unit->channels[ch_num].tones_info[sb];
 
+memset(wavreg1, 0, sizeof(float) * 128);
+memset(wavreg2, 0, sizeof(float) * 128);
 /* reconstruct full envelopes for both overlapping regions
  * from truncated bitstream data */
 if (tones_next->pend_env.has_start_point &&
@@ -599,8 +601,8 @@ void ff_atrac3p_ipqf(FFTContext *dct_ctx, 
Atrac3pIPQFChannelCtx *hist,
  const float *in, float *out)
 {
 int i, s, sb, t, pos_now, pos_next;
-DECLARE_ALIGNED(32, float, idct_in)[ATRAC3P_SUBBANDS];
-DECLARE_ALIGNED(32, float, idct_out)[ATRAC3P_SUBBANDS];
+LOCAL_ALIGNED_32(float, idct_in,  [ATRAC3P_SUBBANDS]);
+LOCAL_ALIGNED_32(float, idct_out, [ATRAC3P_SUBBANDS]);
 
 memset(out, 0, ATRAC3P_FRAME_SAMPLES * sizeof(*out));
 
-- 
2.7.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] hevcdec: Use LOCAL_ALIGNED_* for declaring local variables with alignment

[Diego Biurrun]

On Tue, Mar 28, 2017 at 12:58:06PM +0300, Martin Storsjö wrote:
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -917,8 +917,8 @@ static void hls_residual_coding(HEVCContext *s, int x0, 
> int y0,
> -DECLARE_ALIGNED(32, int16_t, coeffs[MAX_TB_SIZE * MAX_TB_SIZE]) = { 0 };
> -DECLARE_ALIGNED(8, uint8_t, significant_coeff_group_flag[8][8]) = { { 0 
> } };
> +LOCAL_ALIGNED_32(int16_t, coeffs, [MAX_TB_SIZE * MAX_TB_SIZE]);
> +LOCAL_ALIGNED_8(uint8_t, significant_coeff_group_flag, [8], [8]);
> @@ -926,6 +926,8 @@ static void hls_residual_coding(HEVCContext *s, int x0, 
> int y0,
> +memset(coeffs, 0, sizeof(int16_t) * MAX_TB_SIZE * MAX_TB_SIZE);
> +memset(significant_coeff_group_flag, 0, sizeof(uint8_t) * 8 * 8);

LOCAL_ALIGNED does not allow zero initialization? Maybe we should fix
that at some point.

OK

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] Changing AV_PIX_FMT_NONE from -1 to 0

[Vittorio Giovara]

On Tue, Mar 28, 2017 at 12:43 PM, wm4  wrote:
> I propose that AV_PIX_FMT_NONE is changed from -1 to 0. The reason is
> that default-initializing an AVPixelFormat should set an invalid or
> neutral value, instead of a "random" valid value.
>
> Currently, 0 means AV_PIX_FMT_YUV420P, which is confusing and can lead
> to errors, especially since almost all video is yuv420p anyway.

I wouldn't be against this idea, I actually think it makes sense.

> The only problem I see with this is that some code does "<0" to check
> for an "unset" format. Some code even uses "-1" instead of the enum
> constants, like avcodec_parameters_alloc(). This code would have to be
> changed. (You could consider it "buggy" because it didn't use the enum
> constant and hardcoded the exact integer values, even though that was
> not documented as allowed.)

I believe some initialization functions would need changes too, but I
don't know which ones off hand.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [RFC] Changing AV_PIX_FMT_NONE from -1 to 0

[wm4]

I propose that AV_PIX_FMT_NONE is changed from -1 to 0. The reason is
that default-initializing an AVPixelFormat should set an invalid or
neutral value, instead of a "random" valid value.

Currently, 0 means AV_PIX_FMT_YUV420P, which is confusing and can lead
to errors, especially since almost all video is yuv420p anyway.

The only problem I see with this is that some code does "<0" to check
for an "unset" format. Some code even uses "-1" instead of the enum
constants, like avcodec_parameters_alloc(). This code would have to be
changed. (You could consider it "buggy" because it didn't use the enum
constant and hardcoded the exact integer values, even though that was
not documented as allowed.)

The same applies to AV_SAMPLE_FMT_NONE (which currently is -1).
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 10/10] avconv: Test avcodec_probe_hw()

[wm4]

On Mon, 27 Mar 2017 21:38:19 +0100
Mark Thompson  wrote:

> Test only, not to commit in this form.
> ---
>  avtools/avconv_hw.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/avtools/avconv_hw.c b/avtools/avconv_hw.c
> index fd1618389..71a3c2772 100644
> --- a/avtools/avconv_hw.c
> +++ b/avtools/avconv_hw.c
> @@ -376,8 +376,35 @@ fail:
>  int hwaccel_decode_init(AVCodecContext *avctx)
>  {
>  InputStream *ist = avctx->opaque;
> +AVBufferRef *hw_frames_ref;
> +AVHWFramesContext *hw_frames;
> +int err;
> +
> +if (!avctx->hw_device_ctx)
> +return AVERROR(ENOSYS);
> +
> +hw_frames_ref = av_hwframe_ctx_alloc(avctx->hw_device_ctx);
> +if (!hw_frames_ref)
> +return AVERROR(ENOMEM);
> +hw_frames = (AVHWFramesContext*)hw_frames_ref->data;
> +
> +err = avcodec_probe_hw(avctx, hw_frames_ref);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Decode with %s not supported: %d.\n",
> +   av_hwdevice_get_type_name(hw_frames->device_ctx->type), err);
> +goto fail;
> +}
> +
> +av_log(avctx, AV_LOG_ERROR, "Decode with %s supported; %d frames "
> +   "of type %d/%d and size %dx%d are required.\n",
> +   av_hwdevice_get_type_name(hw_frames->device_ctx->type),
> +   hw_frames->initial_pool_size, hw_frames->format, 
> hw_frames->sw_format,
> +   hw_frames->width, hw_frames->height);
>  
>  ist->hwaccel_retrieve_data = _retrieve_data;
>  
> -return 0;
> +err = 0;
> +fail:
> +av_buffer_unref(_frames_ref);
> +return err;
>  }

LGTM, under the condition of whatever happening to patch 3/10.

All the other patches I didn't comment on LGTM as well.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 07/10] lavfi: Add a way to control how many hardware frames are allocated for filtering

[wm4]

On Mon, 27 Mar 2017 21:38:16 +0100
Mark Thompson  wrote:

> This functions identically to the same field in AVCodecContext.
> ---
>  doc/APIchanges |  3 +++
>  libavfilter/avfilter.c |  2 ++
>  libavfilter/avfilter.h | 13 +
>  3 files changed, 18 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 677f5f7f1..8f06614fb 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>  
>  API changes, most recent first:
>  
> +2017-04-xx - xxx - lavfi 7.x+1.0 - avfilter.h
> +  Add AVFilterContext.extra_hw_frames.
> +
>  2017-04-xx - xxx - lavc 58.x+1.0 - avcodec.h
>Add AVCodecContext.extra_hw_frames.
>  
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 83c1a7c20..834eca8b3 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -368,6 +368,8 @@ static const AVOption avfilter_options[] = {
>  { "thread_type", "Allowed thread types", OFFSET(thread_type), 
> AV_OPT_TYPE_FLAGS,
>  { .i64 = AVFILTER_THREAD_SLICE }, 0, INT_MAX, FLAGS, "thread_type" },
>  { "slice", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AVFILTER_THREAD_SLICE }, .unit = "thread_type" },
> +{ "extra_hw_frames", "Number of extra hardware frames to allocate for 
> the user",
> +OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, 
> FLAGS },
>  { NULL },
>  };
>  
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 6df69dbbb..c8f861076 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -311,6 +311,19 @@ struct AVFilterContext {
>   * hardware context information.
>   */
>  AVBufferRef *hw_device_ctx;
> +
> +/**
> + * Sets the number of extra hardware frames which the filter will
> + * allocate on its output links for use in following filters or by
> + * the caller.
> + *
> + * Some hardware filters require all frames that they will use for
> + * output to be defined in advance before filtering starts.  For such
> + * filters, any hardware frame pools used for output must therefore be
> + * of fixed size.  The extra frames set here are on top of any number
> + * that the filter needs internally in order to operate normally.
> + */
> +int extra_hw_frames;
>  };
>  
>  /**

(Same comment as on the AVCodecContext patch, otherwise LGTM.)

(Also we need something to make this work for the whole graph, but
that's one difficulty level and patch set later.)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 05/10] lavc: Add a way to control how many hardware frames are allocated for decode

[wm4]

On Mon, 27 Mar 2017 21:38:14 +0100
Mark Thompson  wrote:

> ---
>  doc/APIchanges |  3 +++
>  libavcodec/avcodec.h   | 14 ++
>  libavcodec/options_table.h |  1 +
>  3 files changed, 18 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 649d35a08..677f5f7f1 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2017-03-23
>  API changes, most recent first:
>  
>  2017-04-xx - xxx - lavc 58.x+1.0 - avcodec.h
> +  Add AVCodecContext.extra_hw_frames.
> +
> +2017-04-xx - xxx - lavc 58.x+1.0 - avcodec.h
>Add AVHWAccel.device_type and avcodec_probe_hw().
>  
>  2017-04-xx - xxx - lavc 58.x.y+1 - avcodec.h
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 8f7293d02..0a50cd876 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2724,6 +2724,20 @@ typedef struct AVCodecContext {
>   * AVCodecContext.get_format callback)
>   */
>  int hwaccel_flags;
> +
> +/**
> + * Video decoding only.  Sets the number of extra hardware frames which
> + * the decoder will allocate for use by the caller.  This is only used
> + * if hw_device_ctx is set.
> + *
> + * Some hardware decoders require all frames that they will use for
> + * output to be defined in advance before decoding starts.  For such
> + * decoders, the hardware frame pool must therefore be of a fixed size.
> + * The extra frames set here are on top of any number that the decoder
> + * needs internally in order to operate normally (for example, frames
> + * used as reference pictures).
> + */
> +int extra_hw_frames;
>  } AVCodecContext;
>  
>  /**
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 925ef376f..ce871dccd 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -419,6 +419,7 @@ static const AVOption avcodec_options[] = {
>  {"side_data_only_packets", NULL, OFFSET(side_data_only_packets), 
> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, A|V|E },
>  #endif
>  {"apply_cropping", NULL, OFFSET(apply_cropping), AV_OPT_TYPE_INT, { .i64 = 1 
> }, 0, 1, V | D },
> +{"extra_hw_frames", "Number of extra hardware frames to allocate for the 
> user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, 
> V|D },
>  {NULL},
>  };
>  

What will it do for decoders which do not require pre-allocation? A
small note of this would be good. Otherwise LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/10] lavc: Add a new function to probe hardware support

[wm4]

On Mon, 27 Mar 2017 21:38:12 +0100
Mark Thompson  wrote:

> This also adds a new field to AVHWAccel to set supported hardware device
> types, so that we can query the right hwaccel.
> ---
> Not entirely sure that the AVCodecContext should be the first argument of 
> probe_hw() - AVCodecParameters might be nicer, but we are likely to end up 
> needing an AVCodecContext anyway.  (More generally, please bikeshed freely 
> over naming and structures used.)
> 
> The probe_hw() function on the D*VA hwaccel would be where the extra 
> alignment gets set (when AVCodecContext.hw_device_ctx is not used).
> 
> 
>  doc/APIchanges|  3 +++
>  libavcodec/avcodec.h  | 51 +
>  libavcodec/decode.c   | 53 
> ---
>  libavcodec/encode.c   | 13 +
>  libavcodec/internal.h | 10 ++
>  libavcodec/utils.c| 15 +++
>  6 files changed, 138 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 5da821c90..649d35a08 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>  
>  API changes, most recent first:
>  
> +2017-04-xx - xxx - lavc 58.x+1.0 - avcodec.h
> +  Add AVHWAccel.device_type and avcodec_probe_hw().
> +
>  2017-04-xx - xxx - lavc 58.x.y+1 - avcodec.h
>Add AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH.
>  
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 2aa70ca4f..8f7293d02 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -35,6 +35,7 @@
>  #include "libavutil/cpu.h"
>  #include "libavutil/dict.h"
>  #include "libavutil/frame.h"
> +#include "libavutil/hwcontext.h"
>  #include "libavutil/log.h"
>  #include "libavutil/pixfmt.h"
>  #include "libavutil/rational.h"
> @@ -2857,6 +2858,15 @@ typedef struct AVCodec {
>   * packets before decoding.
>   */
>  const char *bsfs;
> +
> +/**
> + * Test support for the given encode/decode parameters, and if possible
> + * set the fields in the frames context to a set of usable values.
> + *
> + * If a hwaccel is used with a decoder and it also has a probe_hw()
> + * function, that will be called instead of this.
> + */
> +int (*probe_hw)(AVCodecContext *avctx, AVHWFramesContext *hw_frames);
>  } AVCodec;
>  
>  /**
> @@ -2898,6 +2908,11 @@ typedef struct AVHWAccel {
>   */
>  int capabilities;
>  
> +/**
> + * Hardware device type which this hwaccel can use.
> + */
> +enum AVHWDeviceType device_type;
> +
>  /*
>   * No fields below this line are part of the public API. They
>   * may not be used outside of libavcodec and can be changed and
> @@ -2988,6 +3003,11 @@ typedef struct AVHWAccel {
>   * Internal hwaccel capabilities.
>   */
>  int caps_internal;
> +
> +/**
> + * Probe hardware for support and parameters.
> + */
> +int (*probe_hw)(AVCodecContext *avctx, AVHWFramesContext *hw_frames);
>  } AVHWAccel;
>  
>  /**
> @@ -4927,6 +4947,37 @@ const AVCodecDescriptor 
> *avcodec_descriptor_get_by_name(const char *name);
>  AVCPBProperties *av_cpb_properties_alloc(size_t *size);
>  
>  /**
> + * Probe hardware support for the given codec parameters.
> + *
> + * For decoders, it tests whether a stream with the given parameters can be
> + * decoded on the given device.  For encoders, it tests whether encoding with
> + * the given parameters is possible on the device.
> + *
> + * On successful return, the fields of hw_frames_ref are set such that, once
> + * initialised, it will be usable as AVCodecContext.hw_frames_ctx.  If the
> + * user has additional requirements to apply to the frames context (for
> + * example, for a larger pool size or for frames created with some system-
> + * specific attribute) then they should be applied after this call but before
> + * calling av_hwframe_ctx_init().
> + *
> + * The device to use is provided as the allocating context of hw_frames_ref.
> + * (Even if set, the hw_frames_ctx and hw_device_ctx fields of avctx are
> + * ignored.)
> + *
> + * @param avctx Codec context with relevant fields set.  It need not have 
> been
> + *  opened.
> + * @param hw_frames_ref A reference to a newly-allocated AVHWFramesContext,
> + *  which will be used to return the result.
> + * @return 0 on success, otherwise negative error code:
> + * AVERROR(ENOSYS): This function is not implemented (hardware support
> + *  may or may not be available).
> + * AVERROR(ENODEV): The device is not usable.
> + * AVERROR(EINVAL): The codec parameters are not supported.
> + * Other errors:Probing failed for some other reason.
> + */
> +int avcodec_probe_hw(AVCodecContext *avctx, AVBufferRef *hw_frames_ref);

This API still makes me a bit uneasy. Regular get_format hwaccel init

[libav-devel] [PATCH] hevcdec: Use LOCAL_ALIGNED_* for declaring local variables with alignment

[Martin Storsjö]

Not all compilers can do alignment larger than the normal stack alignment
for variables on the stack. In these cases, the LOCAL_ALIGNED_* macros
produce the workaround alignment wrapper consisting of a padded array
and a pointer variable.

This fixes the hevc fate tests on RVCT/ARMCC after adding IDCT assembly
that actually assumes/relies on this alignment.
---
 libavcodec/hevcdec.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index e24ce1e..6a04858 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -917,8 +917,8 @@ static void hls_residual_coding(HEVCContext *s, int x0, int 
y0,
 int vshift   = s->ps.sps->vshift[c_idx];
 uint8_t *dst = >frame->data[c_idx][(y0 >> vshift) * stride +
   ((x0 >> hshift) << 
s->ps.sps->pixel_shift)];
-DECLARE_ALIGNED(32, int16_t, coeffs[MAX_TB_SIZE * MAX_TB_SIZE]) = { 0 };
-DECLARE_ALIGNED(8, uint8_t, significant_coeff_group_flag[8][8]) = { { 0 } 
};
+LOCAL_ALIGNED_32(int16_t, coeffs, [MAX_TB_SIZE * MAX_TB_SIZE]);
+LOCAL_ALIGNED_8(uint8_t, significant_coeff_group_flag, [8], [8]);
 
 int trafo_size = 1 << log2_trafo_size;
 int i, qp, shift, add, scale, scale_m;
@@ -926,6 +926,8 @@ static void hls_residual_coding(HEVCContext *s, int x0, int 
y0,
 const uint8_t *scale_matrix;
 uint8_t dc_scale;
 
+memset(coeffs, 0, sizeof(int16_t) * MAX_TB_SIZE * MAX_TB_SIZE);
+memset(significant_coeff_group_flag, 0, sizeof(uint8_t) * 8 * 8);
 // Derive QP for dequant
 if (!lc->cu.cu_transquant_bypass_flag) {
 static const int qp_c[] = {
@@ -1755,8 +1757,8 @@ static void hls_prediction_unit(HEVCContext *s, int x0, 
int y0,
 }
 
 if (current_mv.pred_flag[0] && !current_mv.pred_flag[1]) {
-DECLARE_ALIGNED(16, int16_t,  tmp[MAX_PB_SIZE * MAX_PB_SIZE]);
-DECLARE_ALIGNED(16, int16_t, tmp2[MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t,  tmp, [MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp2, [MAX_PB_SIZE * MAX_PB_SIZE]);
 
 luma_mc(s, tmp, tmpstride, ref0->frame,
 _mv.mv[0], x0, y0, nPbW, nPbH, pred_idx);
@@ -1789,8 +1791,8 @@ static void hls_prediction_unit(HEVCContext *s, int x0, 
int y0,
 s->hevcdsp.put_unweighted_pred_chroma[pred_idx](dst2, 
s->frame->linesize[2], tmp2, tmpstride, nPbH / 2);
 }
 } else if (!current_mv.pred_flag[0] && current_mv.pred_flag[1]) {
-DECLARE_ALIGNED(16, int16_t, tmp [MAX_PB_SIZE * MAX_PB_SIZE]);
-DECLARE_ALIGNED(16, int16_t, tmp2[MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp,  [MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp2, [MAX_PB_SIZE * MAX_PB_SIZE]);
 
 luma_mc(s, tmp, tmpstride, ref1->frame,
 _mv.mv[1], x0, y0, nPbW, nPbH, pred_idx);
@@ -1822,10 +1824,10 @@ static void hls_prediction_unit(HEVCContext *s, int x0, 
int y0,
 s->hevcdsp.put_unweighted_pred_chroma[pred_idx](dst2, 
s->frame->linesize[2], tmp2, tmpstride, nPbH / 2);
 }
 } else if (current_mv.pred_flag[0] && current_mv.pred_flag[1]) {
-DECLARE_ALIGNED(16, int16_t, tmp [MAX_PB_SIZE * MAX_PB_SIZE]);
-DECLARE_ALIGNED(16, int16_t, tmp2[MAX_PB_SIZE * MAX_PB_SIZE]);
-DECLARE_ALIGNED(16, int16_t, tmp3[MAX_PB_SIZE * MAX_PB_SIZE]);
-DECLARE_ALIGNED(16, int16_t, tmp4[MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp,  [MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp2, [MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp3, [MAX_PB_SIZE * MAX_PB_SIZE]);
+LOCAL_ALIGNED_16(int16_t, tmp4, [MAX_PB_SIZE * MAX_PB_SIZE]);
 
 luma_mc(s, tmp, tmpstride, ref0->frame,
 _mv.mv[0], x0, y0, nPbW, nPbH, pred_idx);
-- 
2.7.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 05/10] lavc: Add a way to control how many hardware frames are allocated for decode

[Luca Barbato]

On 27/03/2017 22:38, Mark Thompson wrote:
> ---
>  doc/APIchanges |  3 +++
>  libavcodec/avcodec.h   | 14 ++
>  libavcodec/options_table.h |  1 +
>  3 files changed, 18 insertions(+)

Seems fine.

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 06/10] vaapi: Use extra_hw_frames setting when allocating frames

[Luca Barbato]

On 27/03/2017 22:38, Mark Thompson wrote:
> ---
>  libavcodec/vaapi_decode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 82e919858..6910ecab6 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -570,7 +570,8 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
>  ctx->frames->height = avctx->coded_height;
>  
>  ctx->frames->sw_format = ctx->surface_format;
> -ctx->frames->initial_pool_size = ctx->surface_count;
> +ctx->frames->initial_pool_size = ctx->surface_count +
> + avctx->extra_hw_frames;
>  
>  err = av_hwframe_ctx_init(avctx->hw_frames_ctx);
>  if (err < 0) {
> 

Sounds fine.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/10] lavc: Add flag to allow profile mismatch with hardware decoding

[Mark Thompson]

On 28/03/17 10:06, wm4 wrote:
> On Mon, 27 Mar 2017 21:38:10 +0100
> Mark Thompson  wrote:
> 
>> ---
>> For naughty people only - this won't be set by default anywhere.
>>
>>
>>  doc/APIchanges   |  3 +++
>>  libavcodec/avcodec.h | 14 ++
>>  2 files changed, 17 insertions(+)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index a0ca3b7ac..5da821c90 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>>  
>>  API changes, most recent first:
>>  
>> +2017-04-xx - xxx - lavc 58.x.y+1 - avcodec.h
>> +  Add AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH.
>> +
>>  2017-03-xx - xxx - lavc 57.37.0 - avcodec.h
>>Add AVCodecContext.hwaccel_flags field. This will control some hwaccels at
>>a later point.
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 1c58fe2d6..2aa70ca4f 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3004,6 +3004,20 @@ typedef struct AVHWAccel {
>>  #define AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH (1 << 1)
>>  
>>  /**
>> + * Hardware acceleration should still be attempted for decoding when the
>> + * codec profile does not match the reported capabilities of the hardware.
>> + *
>> + * For example, this can be used to try to decode baseline profile H.264
>> + * streams in hardware - it will often succeed, because many streams marked
>> + * as baseline profile actually conform to constrained baseline profile.
>> + *
>> + * @warning If the stream is actually not supported then the behaviour is
>> + *  undefined, and may include returning entirely incorrect output
>> + *  while indicating success.
>> + */
>> +#define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>> +
>> +/**
>>   * @}
>>   */
>>  
> 
> What are the exact semantics of this? I assume it's something like
> picking the highest profile if the exact profile is not available.

Yes.  But, I was really going for "deliberately unclear" - it's doing something 
dubious and may be undefined behaviour, but also could happen to do the thing 
you want in some cases.

(I wouldn't mind the semantics being even more nebulous - 
"AV_HWACCEL_FLAG_TRY_INCOMPATIBLE_STREAMS_ANYWAY".)

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/10] lavc: Add flag to allow profile mismatch with hardware decoding

[wm4]

On Mon, 27 Mar 2017 21:38:10 +0100
Mark Thompson  wrote:

> ---
> For naughty people only - this won't be set by default anywhere.
> 
> 
>  doc/APIchanges   |  3 +++
>  libavcodec/avcodec.h | 14 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index a0ca3b7ac..5da821c90 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>  
>  API changes, most recent first:
>  
> +2017-04-xx - xxx - lavc 58.x.y+1 - avcodec.h
> +  Add AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH.
> +
>  2017-03-xx - xxx - lavc 57.37.0 - avcodec.h
>Add AVCodecContext.hwaccel_flags field. This will control some hwaccels at
>a later point.
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 1c58fe2d6..2aa70ca4f 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3004,6 +3004,20 @@ typedef struct AVHWAccel {
>  #define AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH (1 << 1)
>  
>  /**
> + * Hardware acceleration should still be attempted for decoding when the
> + * codec profile does not match the reported capabilities of the hardware.
> + *
> + * For example, this can be used to try to decode baseline profile H.264
> + * streams in hardware - it will often succeed, because many streams marked
> + * as baseline profile actually conform to constrained baseline profile.
> + *
> + * @warning If the stream is actually not supported then the behaviour is
> + *  undefined, and may include returning entirely incorrect output
> + *  while indicating success.
> + */
> +#define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
> +
> +/**
>   * @}
>   */
>  

What are the exact semantics of this? I assume it's something like
picking the highest profile if the exact profile is not available.

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] arm: Always build the hevcdsp_init_arm.c file

[Diego Biurrun]

On Tue, Mar 28, 2017 at 11:09:45AM +0300, Martin Storsjö wrote:
> The main hevcdsp.c file calls this init function if HAVE_ARM is set,
> regardless of whether neon support is available or not.
> 
> This fixes builds where neon isn't supported by the build tools at all.
> ---
>  libavcodec/arm/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

OK

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] arm: Always build the hevcdsp_init_arm.c file

[Martin Storsjö]

The main hevcdsp.c file calls this init function if HAVE_ARM is set,
regardless of whether neon support is available or not.

This fixes builds where neon isn't supported by the build tools at all.
---
 libavcodec/arm/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 555de160e4..b48745ad40 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -41,6 +41,7 @@ OBJS-$(CONFIG_AAC_DECODER) += 
arm/aacpsdsp_init_arm.o   \
   arm/sbrdsp_init_arm.o
 OBJS-$(CONFIG_APE_DECODER) += arm/apedsp_init_arm.o
 OBJS-$(CONFIG_DCA_DECODER) += arm/dcadsp_init_arm.o
+OBJS-$(CONFIG_HEVC_DECODER)+= arm/hevcdsp_init_arm.o
 OBJS-$(CONFIG_MLP_DECODER) += arm/mlpdsp_init_arm.o
 OBJS-$(CONFIG_RV40_DECODER)+= arm/rv40dsp_init_arm.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += arm/vorbisdsp_init_arm.o
@@ -134,8 +135,7 @@ NEON-OBJS-$(CONFIG_AAC_DECODER)+= 
arm/aacpsdsp_neon.o   \
 NEON-OBJS-$(CONFIG_APE_DECODER)+= arm/apedsp_neon.o
 NEON-OBJS-$(CONFIG_DCA_DECODER)+= arm/dcadsp_neon.o \
   arm/synth_filter_neon.o
-NEON-OBJS-$(CONFIG_HEVC_DECODER)   += arm/hevc_idct.o   \
-  arm/hevcdsp_init_arm.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)   += arm/hevc_idct.o
 NEON-OBJS-$(CONFIG_RV30_DECODER)   += arm/rv34dsp_neon.o
 NEON-OBJS-$(CONFIG_RV40_DECODER)   += arm/rv34dsp_neon.o\
   arm/rv40dsp_neon.o
-- 
2.11.0 (Apple Git-81)

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] Add FM Screen Capture Codec decoder

[Diego Biurrun]

On Fri, Mar 24, 2017 at 04:47:55PM +0100, Vittorio Giovara wrote:
> On Fri, Mar 24, 2017 at 4:10 PM, Diego Biurrun  wrote:
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -12,6 +12,7 @@ version :
> >  - The x86 assembler default switched from yasm to nasm, pass
> >--x86asmexe=yasm to configure to restore the old behavior.
> >  - Cineform HD decoder
> > +- FM Screen Capture Codec decoder
> 
> FM is a tad short, would you mind using the full name Fox Magic in the
> commit too?

On second thought, FM is part of the official name:

http://www.fox-magic.com/fmvc.php

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/3] Add av_calloc() helper

[Diego Biurrun]

On Fri, Mar 24, 2017 at 04:20:40PM +0100, Luca Barbato wrote:
> On 24/03/2017 16:10, Diego Biurrun wrote:
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -193,6 +193,13 @@ void *av_mallocz(size_t size)
> > +void *av_calloc(size_t nmemb, size_t size)
> > +{
> > +if (size <= 0 || nmemb >= INT_MAX / size)
> > +return NULL;
> > +return av_mallocz(nmemb * size);
> > +}
> 
> av_mallocz_array exists already.

Patch dropped.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] Add FM Screen Capture Codec decoder

[Diego Biurrun]

On Mon, Mar 27, 2017 at 12:59:13PM +0200, Vittorio Giovara wrote:
> On Mon, Mar 27, 2017 at 12:17 PM, Diego Biurrun  wrote:
> > On Fri, Mar 24, 2017 at 04:47:55PM +0100, Vittorio Giovara wrote:
> >> On Fri, Mar 24, 2017 at 4:10 PM, Diego Biurrun  wrote:
> >> > +bytestream2_init(gb, avpkt->data, avpkt->size);
> >> > +bytestream2_skip(gb, 2);
> >> > +
> >> > +frame->key_frame = !!bytestream2_get_le16(gb);
> >> > +frame->pict_type = frame->key_frame ? AV_PICTURE_TYPE_I : 
> >> > AV_PICTURE_TYPE_P;
> >>
> >> these are usually initialized only if got_frame = 1
> >
> > Not sure what you want me to change here. frame->key_frame is changed
> > just below ..
> 
> This was a minor suggestion, I was just thinking that you could store
> !!bytestream2_get_le16(gb) in a separate variable and initialize
> frame->key_frame only after *got_frame = 1.

Sometimes we do that, sometimes we don't. I'd keep it as-is to minimize
changes for now.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel