Re: [FFmpeg-devel] [PATCH V2 2/3] lavfi/procamp_vaapi: fix the green video issue if without arguments.

2018-01-24 Thread Carl Eugen Hoyos 
2018-01-24 4:04 GMT+01:00 Jun Zhao :

> -procamp_params[i].type   = VAProcFilterColorBalance;
> -procamp_params[i].attrib = VAProcColorBalanceBrightness;
> -procamp_params[i].value  = map(ctx->bright, BRIGHTNESS_MIN, 
> BRIGHTNESS_MAX,
> -   
> procamp_caps[VAProcColorBalanceBrightness-1].range.min_value,
> -   
> procamp_caps[VAProcColorBalanceBrightness-1].range.max_value);
> -i++;

> -procamp_params[i].type   = VAProcFilterColorBalance;
> -procamp_params[i].attrib = VAProcColorBalanceContrast;
> -procamp_params[i].value  = map(ctx->contrast, CONTRAST_MIN, 
> CONTRAST_MAX,
> -   
> procamp_caps[VAProcColorBalanceContrast-1].range.min_value,
> -   
> procamp_caps[VAProcColorBalanceContrast-1].range.max_value);
> -i++;

> -procamp_params[i].type   = VAProcFilterColorBalance;
> -procamp_params[i].attrib = VAProcColorBalanceHue;
> -procamp_params[i].value  = map(ctx->hue, HUE_MIN, HUE_MAX,
> -   
> procamp_caps[VAProcColorBalanceHue-1].range.min_value,
> -   
> procamp_caps[VAProcColorBalanceHue-1].range.max_value);
> -i++;

> -procamp_params[i].type   = VAProcFilterColorBalance;
> -procamp_params[i].attrib = VAProcColorBalanceSaturation;
> -procamp_params[i].value  = map(ctx->saturation, SATURATION_MIN, 
> SATURATION_MAX,
> -   
> procamp_caps[VAProcColorBalanceSaturation-1].range.min_value,
> -   
> procamp_caps[VAProcColorBalanceSaturation-1].range.max_value);
> -i++;

Please do not reindent these lines in the same patch that removes the
conditions, this has two advantages: It makes reviewing your changes
easier now, and allows somebody who looks at your change in the
future to understand it more quickly.
Send an independent patch for the re-indentation.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use ff_hevc_decode_extradata() to parse extradata

2018-01-24 Thread James Almer 
On 1/20/2018 3:00 PM, James Almer wrote:
> On 1/20/2018 1:12 AM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/hevc_parser.c | 21 +
>>  1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
>> index ff7e8a49d6..a3a9098c7c 100644
>> --- a/libavcodec/hevc_parser.c
>> +++ b/libavcodec/hevc_parser.c
>> @@ -24,6 +24,7 @@
>>  
>>  #include "golomb.h"
>>  #include "hevc.h"
>> +#include "hevc_parse.h"
>>  #include "hevc_ps.h"
>>  #include "hevc_sei.h"
>>  #include "h2645_parse.h"
>> @@ -43,6 +44,8 @@ typedef struct HEVCParserContext {
>>  HEVCSEI sei;
>>  SliceHeader sh;
>>  
>> +int is_avc;
>> +int nal_length_size;
>>  int parsed_extradata;
>>  
>>  int poc;
>> @@ -181,7 +184,6 @@ static int parse_nal_units(AVCodecParserContext *s, 
>> const uint8_t *buf,
>>  HEVCParserContext *ctx = s->priv_data;
>>  HEVCParamSets *ps = &ctx->ps;
>>  HEVCSEI *sei = &ctx->sei;
>> -int is_global = buf == avctx->extradata;
>>  int ret, i;
>>  
>>  /* set some sane default values */
>> @@ -191,8 +193,8 @@ static int parse_nal_units(AVCodecParserContext *s, 
>> const uint8_t *buf,
>>  
>>  ff_hevc_reset_sei(sei);
>>  
>> -ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, 0, 0,
>> -AV_CODEC_ID_HEVC, 1);
>> +ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, 
>> ctx->is_avc,
>> +ctx->nal_length_size, AV_CODEC_ID_HEVC, 1);
>>  if (ret < 0)
>>  return ret;
>>  
>> @@ -230,12 +232,6 @@ static int parse_nal_units(AVCodecParserContext *s, 
>> const uint8_t *buf,
>>  case HEVC_NAL_RADL_R:
>>  case HEVC_NAL_RASL_N:
>>  case HEVC_NAL_RASL_R:
>> -
>> -if (is_global) {
>> -av_log(avctx, AV_LOG_ERROR, "Invalid NAL unit: %d\n", 
>> nal->type);
>> -return AVERROR_INVALIDDATA;
>> -}
>> -
>>  ret = hevc_parse_slice_header(s, nal, avctx);
>>  if (ret)
>>  return ret;
>> @@ -243,8 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, 
>> const uint8_t *buf,
>>  }
>>  }
>>  /* didn't find a picture! */
>> -if (!is_global)
>> -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
>> +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
>>  return -1;
>>  }
>>  
>> @@ -301,7 +296,9 @@ static int hevc_parse(AVCodecParserContext *s, 
>> AVCodecContext *avctx,
>>  ParseContext *pc = &ctx->pc;
>>  
>>  if (avctx->extradata && !ctx->parsed_extradata) {
>> -parse_nal_units(s, avctx->extradata, avctx->extradata_size, avctx);
>> +ff_hevc_decode_extradata(buf, buf_size, &ctx->ps, &ctx->sei, 
>> &ctx->is_avc,
> 
> Changed buf and buf_size locally to avctx->extradata and
> avctx->extradata_size.
> 
>> + &ctx->nal_length_size, 
>> avctx->err_recognition,
>> + 1, avctx);
>>  ctx->parsed_extradata = 1;
>>  }
>>  

Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add id3v2 tests

2018-01-24 Thread Richard Shaffer 
On Tue, Jan 23, 2018 at 6:15 PM, James Almer  wrote:
>
>
> ffprobe -show_format is probably best for an id3v2 tag. Add a new
> probeformat() function to fate-run.sh like
>
> probeformat(){
> run ffprobe${PROGSUF} -show_format -v 0 "$@"
> }
>
> Then call it with the sample in question a argument. See how exif.mak
> uses probeframes().
>

Thanks, James. That's helpful. I'll take a look today.

-Richard

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

2018-01-24 Thread Jacob Trimble 
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer
 wrote
> [...]
>> This removes support for saio/saiz atoms, but it was incorrect before.
>> A follow-up change will add correct support for those.
>
> This removal should be done by a seperate patch if it is done.
> diff has matched up the removed function with a added one making this
> hard to read as is
>

The problem is that the old code used the saiz atoms to parse the senc
atom.  I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content.  But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

>
>>
>> Signed-off-by: Jacob Trimble 
>> ---
>>  libavformat/isom.h |  20 +-
>>  libavformat/mov.c  | 432 
>> ++---
>>  tests/fate/mov.mak |   8 +
>>  tests/ref/fate/mov-frag-encrypted  |  57 +
>>  tests/ref/fate/mov-tenc-only-encrypted |  57 +
>>  5 files changed, 422 insertions(+), 152 deletions(-)
>>  create mode 100644 tests/ref/fate/mov-frag-encrypted
>>  create mode 100644 tests/ref/fate/mov-tenc-only-encrypted
>
> This depends on other patches you posted, this should be mentioned or
> all patches should be in the same patchset in order
>

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr.  Should I add
something to the commit message or is that enough?

>
>>
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 65676fb0f5..3794b1f0fd 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -27,6 +27,7 @@
>>  #include 
>>  #include 
>>
>> +#include "libavutil/encryption_info.h"
>>  #include "libavutil/mastering_display_metadata.h"
>>  #include "libavutil/spherical.h"
>>  #include "libavutil/stereo3d.h"
>> @@ -108,12 +109,20 @@ typedef struct MOVSbgp {
>>  unsigned int index;
>>  } MOVSbgp;
>>
>> +typedef struct MOVEncryptionIndex {
>> +// Individual encrypted samples.  If there are no elements, then the 
>> default
>> +// settings will be used.
>> +unsigned int nb_encrypted_samples;
>> +AVEncryptionInfo **encrypted_samples;
>> +} MOVEncryptionIndex;
>> +
>>  typedef struct MOVFragmentStreamInfo {
>>  int id;
>>  int64_t sidx_pts;
>>  int64_t first_tfra_pts;
>>  int64_t tfdt_dts;
>>  int index_entry;
>> +MOVEncryptionIndex *encryption_index;
>>  } MOVFragmentStreamInfo;
>>
>>  typedef struct MOVFragmentIndexItem {
>> @@ -214,15 +223,10 @@ typedef struct MOVStreamContext {
>>
>>  int has_sidx;  // If there is an sidx entry for this stream.
>>  struct {
>> -int use_subsamples;
>> -uint8_t* auxiliary_info;
>> -uint8_t* auxiliary_info_end;
>> -uint8_t* auxiliary_info_pos;
>> -uint8_t auxiliary_info_default_size;
>> -uint8_t* auxiliary_info_sizes;
>> -size_t auxiliary_info_sizes_count;
>> -int64_t auxiliary_info_index;
>>  struct AVAESCTR* aes_ctr;
>> +unsigned int per_sample_iv_size;  // Either 0, 8, or 16.
>> +AVEncryptionInfo *default_encrypted_sample;
>> +MOVEncryptionIndex *encryption_index;
>>  } cenc;
>>  } MOVStreamContext;
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 22faecfc17..37320af2f6 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -1324,6 +1324,7 @@ static int update_frag_index(MOVContext *c, int64_t 
>> offset)
>>  frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
>>  frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
>>  frag_stream_info[i].index_entry = -1;
>> +frag_stream_info[i].encryption_index = NULL;
>>  }
>>
>>  if (index < c->frag_index.nb_items)
>> @@ -5710,117 +5711,252 @@ static int mov_read_frma(MOVContext *c, 
>> AVIOContext *pb, MOVAtom atom)
>>  return 0;
>>  }
>>
>> -static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> +/**
>> + * Gets the current encryption info and associated current stream context.  
>> If
>> + * we are parsing a track fragment, this will return the specific encryption
>> + * info for this fragment; otherwise this will return the global encryption
>> + * info for the current stream.
>> + */
>
>> +static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex 
>> **encryption_index, MOVStreamContext **sc)
>>  {
>> +MOVFragmentStreamInfo *frag_stream_info;
>>  AVStream *st;
>> -MOVStreamContext *sc;
>> -size_t auxiliary_info_size;
>> +int i;
>>
>> -if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
>> -return 0;
>> +frag_stream_info = get_current_frag_stream_info(&c->frag_index);
>> +if (frag_stream_info) {
>> +for (i = 0; i < c->fc->nb_streams; i++) {
>> +if (c->fc->streams[i]->id == frag_stream_info->id) {
>> +  st = c->fc->streams

Re: [FFmpeg-devel] [PATCH V2 1/3] lavfi/vf_xxx_vaapi: fix typo.

2018-01-24 Thread Carl Eugen Hoyos 
2018-01-24 4:04 GMT+01:00 Jun Zhao :
> V2: split the patches as carl's comments

Pushed.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_transpose: Fix used plane count.

2018-01-24 Thread Michael Niedermayer 
Fixes out of array access
Fixes: poc.mp4

Found-by: GwanYeong Kim 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_transpose.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
index 982fb0c8ca..1e1a5c4b89 100644
--- a/libavfilter/vf_transpose.c
+++ b/libavfilter/vf_transpose.c
@@ -27,6 +27,7 @@
 
 #include 
 
+#include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
@@ -54,6 +55,7 @@ enum TransposeDir {
 typedef struct TransContext {
 const AVClass *class;
 int hsub, vsub;
+int planes;
 int pixsteps[4];
 
 int passthrough;///< PassthroughType, landscape passthrough mode 
enabled
@@ -215,6 +217,10 @@ static int config_props_output(AVFilterLink *outlink)
 
 s->hsub = desc_in->log2_chroma_w;
 s->vsub = desc_in->log2_chroma_h;
+s->planes = desc_in->nb_components;
+
+av_assert0(desc_in->nb_components == desc_out->nb_components);
+
 
 av_image_fill_max_pixsteps(s->pixsteps, NULL, desc_out);
 
@@ -272,7 +278,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr,
 AVFrame *in = td->in;
 int plane;
 
-for (plane = 0; out->data[plane]; plane++) {
+for (plane = 0; plane < s->planes; plane++) {
 int hsub= plane == 1 || plane == 2 ? s->hsub : 0;
 int vsub= plane == 1 || plane == 2 ? s->vsub : 0;
 int pixstep = s->pixsteps[plane];
-- 
2.15.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

2018-01-24 Thread Ben Chang 
Hi,

Please help review this patch to reduce stack frame size per GPU thread. The 
default allocation size per thread (1024 bytes) is excessive and can be reduced 
to 128 bytes based on nvidia cuda kernel compilation statistics. This should 
help with reducing video memory usage per cuda context.

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


0001-Reduce-cuda-context-s-stack-frame-size-limit-through.patch
Description: 0001-Reduce-cuda-context-s-stack-frame-size-limit-through.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

2018-01-24 Thread Carl Eugen Hoyos 
2018-01-25 0:44 GMT+01:00 Ben Chang :

> Please help review this patch to reduce stack frame size per GPU
> thread. The default allocation size per thread (1024 bytes) is
> excessive and can be reduced to 128 bytes based on nvidia cuda
> kernel compilation statistics. This should help with reducing video
> memory usage per cuda context.

> Subject: [PATCH] Reduce cuda context's stack frame size limit through
> cuCtxSetLimit. The default stack limit is 1024 byte per GPU thread. This
> reduces limit to 128 byte as verified against current cuda kernel compilation
> statistic. This will reduce local memory allocated per cuda context.

This looks as if your commit message spans several lines, should
be one line followed by an empty line and as many more lines as
you need.

Is there a reason why the error messages are different?

> This email message is for the sole use of the intended recipient(s)
> and may contain confidential information.

Please remove this or use another email address.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

2018-01-24 Thread Michael Niedermayer 
On Wed, Jan 24, 2018 at 11:43:26AM -0800, Jacob Trimble wrote:
> On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer
>  wrote
> > [...]
> >> This removes support for saio/saiz atoms, but it was incorrect before.
> >> A follow-up change will add correct support for those.
> >
> > This removal should be done by a seperate patch if it is done.
> > diff has matched up the removed function with a added one making this
> > hard to read as is
> >
> 
> The problem is that the old code used the saiz atoms to parse the senc
> atom.  I split the patch up for readability, but the two patches need
> to be applied at the same time (or squashed) since the first breaks
> encrypted content.  But I can squash them again if it is preferable to
> not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a 
subsequent patch to prevent diff from messing the line matching up totally


> 
> >
> >>
> >> Signed-off-by: Jacob Trimble 
> >> ---
> >>  libavformat/isom.h |  20 +-
> >>  libavformat/mov.c  | 432 
> >> ++---
> >>  tests/fate/mov.mak |   8 +
> >>  tests/ref/fate/mov-frag-encrypted  |  57 +
> >>  tests/ref/fate/mov-tenc-only-encrypted |  57 +
> >>  5 files changed, 422 insertions(+), 152 deletions(-)
> >>  create mode 100644 tests/ref/fate/mov-frag-encrypted
> >>  create mode 100644 tests/ref/fate/mov-tenc-only-encrypted
> >
> > This depends on other patches you posted, this should be mentioned or
> > all patches should be in the same patchset in order
> >
> 
> This depends on
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
> the recently pushed change to libavutil/aes_ctr.  Should I add
> something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset


[...]
> >> +static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex 
> >> **encryption_index, MOVStreamContext **sc)
> >>  {
> >> +MOVFragmentStreamInfo *frag_stream_info;
> >>  AVStream *st;
> >> -MOVStreamContext *sc;
> >> -size_t auxiliary_info_size;
> >> +int i;
> >>
> >> -if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
> >> -return 0;
> >> +frag_stream_info = get_current_frag_stream_info(&c->frag_index);
> >> +if (frag_stream_info) {
> >> +for (i = 0; i < c->fc->nb_streams; i++) {
> >> +if (c->fc->streams[i]->id == frag_stream_info->id) {
> >> +  st = c->fc->streams[i];
> >> +  break;
> >> +}
> >> +}
> >
> > the indention is inconsistent here
> >
> 
> No it's not, it looks like it because the diff looks odd.  If you
> apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch

personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC

2018-01-24 Thread Ray Tiley 
On Tue, Jan 23, 2018 at 9:07 AM Devin Heitmueller <
dheitmuel...@ltnglobal.com> wrote:

> Hi Ray,
>
> > On Jan 22, 2018, at 11:20 PM, Ray Tiley  wrote:
> >
> > I'm reading 334-1:2017 Sec 4
> > "When the ANC packets defined in this standard are carried in a high
> > definition signal, they shall be carried in the Y stream."
> >
> > I couldn't find anywhere in the document where it calls out standard
> > definition
>
> Right, so my understanding was that allowing the ability to use both luma
> and chroma was a result of having less space in the VANC to hold data,
> compared to HD resolutions where that is much less likely to be an issue.
> That said, I’ve never seen an implementation that actually puts it in the
> chroma.
>
> >
> > Conversation is here:
> > https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574 <
> https://video-dev.slack.com/archives/C0XKDDH5Y/p151614155574> with
> > kier...@obe.tv  who I believe is in the
> ffmpeg-devel IRC.
> >
>
> Ah, ok.  That’s Kieran.  He’s really knowledgable in this area, although I
> cannot see the conversation you’ve linked to as it seems that room is only
> accessible by people with email accounts from certain domains.
>
> Devin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Please find updated patch attatched. I reverted the vanc lines changes and
found that all my tests worked as expected, so not sure what was wrong w/
my original test. The need to extract vanc from the entire line vs just the
luma in NTSC is still required.

-ray


0001-avdevice-decklink_dec-Extract-NTSC-VANC.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

2018-01-24 Thread Michael Niedermayer 
On Wed, Jan 24, 2018 at 12:47:18AM -0300, James Almer wrote:
> On 1/24/2018 12:34 AM, Michael Niedermayer wrote:
> > Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> > Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevc_ps.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 4787312cfa..746c96b17e 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
> > AVCodecContext *avctx,
> >  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
> >  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
> >  
> > +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth
> > - 10, 0)
> > +|| pps->log2_sao_offset_scale_chroma > FFMAX(sps->bit_depth_chroma 
> > - 10, 0)
> > +) {
> > +av_log(avctx, AV_LOG_ERROR,
> > +"log2 sao offset scales (%d %d) are invalid\n",
> > +   pps->log2_sao_offset_scale_luma,
> > +   pps->log2_sao_offset_scale_chroma
> > +  );
> > +return AVERROR_INVALIDDATA;
> 
> Wouldn't it be better to just port the h264 and hevc decoder to use the
> cbs API at this point? It correctly does a range check for every
> sps/vps/pps/slice value already.
> 
> Otherwise you'll be adding a lot of range checks as oss-fuzz finds an
> ubsan testcase for them.

cbs is not available in the releases
we need to fix issues in the releases

so i dont think cbs can help here

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

2018-01-24 Thread Michael Niedermayer 
On Wed, Jan 24, 2018 at 04:42:38AM +0100, wm4 wrote:
> On Wed, 24 Jan 2018 04:34:49 +0100
> Michael Niedermayer  wrote:
> 
> > Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> > Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevc_ps.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 4787312cfa..746c96b17e 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
> > AVCodecContext *avctx,
> >  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
> >  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
> >  
> > +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth
> > - 10, 0)
> > +|| pps->log2_sao_offset_scale_chroma > FFMAX(sps->bit_depth_chroma 
> > - 10, 0)
> > +) {
> > +av_log(avctx, AV_LOG_ERROR,
> > +"log2 sao offset scales (%d %d) are invalid\n",
> > +   pps->log2_sao_offset_scale_luma,
> > +   pps->log2_sao_offset_scale_chroma
> > +  );
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> >  return(0);
> >  }
> >  
> 
> Unnecessary logging.

i would prefer to keep the logging. But if people want it removed ill remove it.
Of course without error logging i will not be available to maintain or help
maintain hevc in the future. 

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

2018-01-24 Thread wm4 
On Thu, 25 Jan 2018 03:26:51 +0100
Michael Niedermayer  wrote:

> On Wed, Jan 24, 2018 at 04:42:38AM +0100, wm4 wrote:
> > On Wed, 24 Jan 2018 04:34:49 +0100
> > Michael Niedermayer  wrote:
> >   
> > > Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> > > Fixes: runtime error: shift exponent 126 is too large for 32-bit type 
> > > 'int'
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/hevc_ps.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > > index 4787312cfa..746c96b17e 100644
> > > --- a/libavcodec/hevc_ps.c
> > > +++ b/libavcodec/hevc_ps.c
> > > @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
> > > AVCodecContext *avctx,
> > >  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
> > >  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
> > >  
> > > +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth  
> > >   - 10, 0)
> > > +|| pps->log2_sao_offset_scale_chroma > 
> > > FFMAX(sps->bit_depth_chroma - 10, 0)
> > > +) {
> > > +av_log(avctx, AV_LOG_ERROR,
> > > +"log2 sao offset scales (%d %d) are invalid\n",
> > > +   pps->log2_sao_offset_scale_luma,
> > > +   pps->log2_sao_offset_scale_chroma
> > > +  );
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > > +
> > >  return(0);
> > >  }
> > >
> > 
> > Unnecessary logging.  
> 
> i would prefer to keep the logging. But if people want it removed ill remove 
> it.
> Of course without error logging i will not be available to maintain or help
> maintain hevc in the future. 

Farewell, then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

2018-01-24 Thread Ben Chang 
Thanks for the review Carl.

> This looks as if your commit message spans several lines, should be one line 
> followed by an empty line and as many more lines as you need.
Fixed. Reattaching.

> Is there a reason why the error messages are different?
I am following the current convention of cuda error messages based on each file 
(hwcontext_cudda.c & nvenc.c).

> Please remove this or use another email address.
Is this absolutely necessary? I am unable to disable the disclaimer through 
outlook. Seems to be tied to nvidia's IT infra.

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


0001-Reduce-cuda-context-s-stack-frame-size-limit-through.patch
Description: 0001-Reduce-cuda-context-s-stack-frame-size-limit-through.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

2018-01-24 Thread nablet developer 

On 16-Jan-18 09:43, Michael Niedermayer wrote:

if you will maintain this code then you may want to include a
change to the MAINTAINERs file

also does anyone have any more comments on this patch ?
it seems to have not gotten much attention recently. There where
reviews/comments a few months ago but the recent versions received little
attention.
Once/If everyone is done with reviewing/commenting (i assume all requests for
changes have been made?) then it should be applied, thus if i see no more
comments from anyone and spot no obvious issue myself then i will apply
seems like no comments so far. is anything else preventing patch to be 
applied now?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

2018-01-24 Thread James Almer 
On 1/24/2018 11:03 PM, Michael Niedermayer wrote:
> On Wed, Jan 24, 2018 at 12:47:18AM -0300, James Almer wrote:
>> On 1/24/2018 12:34 AM, Michael Niedermayer wrote:
>>> Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
>>> Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
>>>
>>> Found-by: continuous fuzzing process 
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/hevc_ps.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 4787312cfa..746c96b17e 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
>>> AVCodecContext *avctx,
>>>  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
>>>  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
>>>  
>>> +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth
>>> - 10, 0)
>>> +|| pps->log2_sao_offset_scale_chroma > FFMAX(sps->bit_depth_chroma 
>>> - 10, 0)
>>> +) {
>>> +av_log(avctx, AV_LOG_ERROR,
>>> +"log2 sao offset scales (%d %d) are invalid\n",
>>> +   pps->log2_sao_offset_scale_luma,
>>> +   pps->log2_sao_offset_scale_chroma
>>> +  );
>>> +return AVERROR_INVALIDDATA;
>>
>> Wouldn't it be better to just port the h264 and hevc decoder to use the
>> cbs API at this point? It correctly does a range check for every
>> sps/vps/pps/slice value already.
>>
>> Otherwise you'll be adding a lot of range checks as oss-fuzz finds an
>> ubsan testcase for them.
> 
> cbs is not available in the releases
> we need to fix issues in the releases
> 
> so i dont think cbs can help here

For release branches yes, no way around it, patches like this are
needed. But for future releases it will prevent this kind of fix to be
added as fuzzers find issues. Eventually, every supported release will
be one using cbs where range checks are already implemented, so the
quickest it's done the better.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

2018-01-24 Thread wm4 
On Wed, 24 Jan 2018 23:42:44 -0300
James Almer  wrote:

> On 1/24/2018 11:03 PM, Michael Niedermayer wrote:
> > On Wed, Jan 24, 2018 at 12:47:18AM -0300, James Almer wrote:  
> >> On 1/24/2018 12:34 AM, Michael Niedermayer wrote:  
> >>> Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> >>> Fixes: runtime error: shift exponent 126 is too large for 32-bit type 
> >>> 'int'
> >>>
> >>> Found-by: continuous fuzzing process 
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/hevc_ps.c | 11 +++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index 4787312cfa..746c96b17e 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
> >>> AVCodecContext *avctx,
> >>>  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
> >>>  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
> >>>  
> >>> +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth  
> >>>   - 10, 0)
> >>> +|| pps->log2_sao_offset_scale_chroma > 
> >>> FFMAX(sps->bit_depth_chroma - 10, 0)
> >>> +) {
> >>> +av_log(avctx, AV_LOG_ERROR,
> >>> +"log2 sao offset scales (%d %d) are invalid\n",
> >>> +   pps->log2_sao_offset_scale_luma,
> >>> +   pps->log2_sao_offset_scale_chroma
> >>> +  );
> >>> +return AVERROR_INVALIDDATA;  
> >>
> >> Wouldn't it be better to just port the h264 and hevc decoder to use the
> >> cbs API at this point? It correctly does a range check for every
> >> sps/vps/pps/slice value already.
> >>
> >> Otherwise you'll be adding a lot of range checks as oss-fuzz finds an
> >> ubsan testcase for them.  
> > 
> > cbs is not available in the releases
> > we need to fix issues in the releases
> > 
> > so i dont think cbs can help here  
> 
> For release branches yes, no way around it, patches like this are
> needed. But for future releases it will prevent this kind of fix to be
> added as fuzzers find issues. Eventually, every supported release will
> be one using cbs where range checks are already implemented, so the
> quickest it's done the better.

Is there even any indication that this is an important fix that
requires it to be backported?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] docs/codecs: remove dead codec debug options

2018-01-24 Thread Gyan Doshi 

Ping. x2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffprobe: Initialize coded_width/height

2018-01-24 Thread Li, Zhong 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Hendrik Leppkes
> > Sent: Friday, January 19, 2018 6:10 PM
> > To: FFmpeg development discussions and patches
> > 
> > Subject: Re: [FFmpeg-devel] [PATCH] ffprobe: Initialize
> > coded_width/height
> >
> > On Fri, Jan 19, 2018 at 6:05 AM, Zhong Li  wrote:
> > > coded_width/height are unnitialized and will be overwritten by
> > > dec_ctx->width/height in avcodec_open2()
> > >
> > > This fixes tiket #6958.
> > >
> > > Signed-off-by: Zhong Li 
> > > ---
> > >  fftools/ffprobe.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index
> > > 0e7a771..233760d 100644
> > > --- a/fftools/ffprobe.c
> > > +++ b/fftools/ffprobe.c
> > > @@ -2512,10 +2512,12 @@ static int show_stream(WriterContext *w,
> > AVFormatContext *fmt_ctx, int stream_id
> > >  case AVMEDIA_TYPE_VIDEO:
> > >  print_int("width",par->width);
> > >  print_int("height",   par->height);
> > > +#if FF_API_LAVF_AVCTX
> > >  if (dec_ctx) {
> > >  print_int("coded_width",  dec_ctx->coded_width);
> > >  print_int("coded_height", dec_ctx->coded_height);
> > >  }
> > > +#endif
> > >  print_int("has_b_frames", par->video_delay);
> > >  sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
> > >  if (sar.den) {
> > > @@ -2912,6 +2914,10 @@ static int open_input_file(InputFile *ifile,
> > > const char *filename)
> > >
> > >  ist->dec_ctx->pkt_timebase = stream->time_base;
> > >  ist->dec_ctx->framerate = stream->avg_frame_rate;
> > > +#if FF_API_LAVF_AVCTX
> > > +ist->dec_ctx->coded_width =
> > stream->codec->coded_width;
> > > +ist->dec_ctx->coded_height =
> > stream->codec->coded_height;
> > > +#endif
> > >
> > >  if (avcodec_open2(ist->dec_ctx, codec, &opts) < 0) {
> > >  av_log(NULL, AV_LOG_WARNING, "Could not open
> > codec
> > > for input stream %d\n",
> >
> > Lets not write new code based on deprecated API.
> >
> > - Hendrik
> 
> Refer the discussion on https://patchwork.ffmpeg.org/patch/7342/

Ping? 
I am also ok just remove these two line to print coded_w/h (If this is the best 
way, I can update this patch), then we can close this ticket.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel