Re: [FFmpeg-devel] [RFC] lavf: add CoreMedia AVCodecTag mappings

[Josh de Kock]

On 20/11/2016 22:49, Carl Eugen Hoyos wrote:

2016-11-19 17:37 GMT+01:00 Josh de Kock :

I've mapped a fair amount of the CoreMedia FourCCs to their
respective AVCodecIDs. The ones I didn't know or thought didn't
exist in FFmpeg have been mapped to AV_CODEC_ID_NONE.


Could you explain the use-case for these mappings?

Carl Eugen


This was discussed in IRC, there was a bit of confusion about how FFmpeg 
supported certain types of data, so the muxed, metadata, and timecode 
mappings are no longer relevant.


As for usecase, it would make working with CoreMedia and FFmpeg tons 
easier because you can easily identify what the different types of 
stream are coming out of CoreMedia with minimal custom code (i.e. 
checking the mapping first, and then probe it with FFmpeg if one is not 
found). It also helps with getting an AVCodecID from a CMDescriptionRef 
with the least amount of pain.


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

Re: [FFmpeg-devel] [PATCH] lavfi/avfiltergraph: always reduce all_layouts to a single layout

[Carl Eugen Hoyos]

2016-11-21 2:09 GMT+01:00 Marton Balint :
> This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
>
> Further reference:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
>
> I can't reproduce ticket #2899

I just tested the following with FFmpeg 2.1:
$ ffmpeg -i test.wav -af "pan=0x4|c0=c4" out.wav
Output is silent ("empty").
Works fine with current FFmpeg and also with your patch applied.

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

Re: [FFmpeg-devel] [RFC] lavf: add CoreMedia AVCodecTag mappings

[Carl Eugen Hoyos]

2016-11-21 10:35 GMT+01:00 Josh de Kock :
> On 20/11/2016 22:49, Carl Eugen Hoyos wrote:
>>
>> 2016-11-19 17:37 GMT+01:00 Josh de Kock :
>>>
>>> I've mapped a fair amount of the CoreMedia FourCCs to their
>>> respective AVCodecIDs. The ones I didn't know or thought didn't
>>> exist in FFmpeg have been mapped to AV_CODEC_ID_NONE.
>>
>> Could you explain the use-case for these mappings?
>>
> This was discussed in IRC, there was a bit of confusion about how FFmpeg
> supported certain types of data, so the muxed, metadata, and timecode
> mappings are no longer relevant.
>
> As for usecase, it would make working with CoreMedia and FFmpeg tons easier
> because you can easily identify what the different types of stream are
> coming out of CoreMedia with minimal custom code (i.e. checking the mapping
> first, and then probe it with FFmpeg if one is not found). It also helps
> with getting an AVCodecID from a CMDescriptionRef with the least amount of
> pain.

Could it be that you are saying FFmpeg needs a CoreMedia demuxer?

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

Re: [FFmpeg-devel] [RFC] lavf: add CoreMedia AVCodecTag mappings

[Josh de Kock]

On 21/11/2016 09:51, Carl Eugen Hoyos wrote:

2016-11-21 10:35 GMT+01:00 Josh de Kock :

On 20/11/2016 22:49, Carl Eugen Hoyos wrote:


2016-11-19 17:37 GMT+01:00 Josh de Kock :


I've mapped a fair amount of the CoreMedia FourCCs to their
respective AVCodecIDs. The ones I didn't know or thought didn't
exist in FFmpeg have been mapped to AV_CODEC_ID_NONE.


Could you explain the use-case for these mappings?


This was discussed in IRC, there was a bit of confusion about how FFmpeg
supported certain types of data, so the muxed, metadata, and timecode
mappings are no longer relevant.

As for usecase, it would make working with CoreMedia and FFmpeg tons easier
because you can easily identify what the different types of stream are
coming out of CoreMedia with minimal custom code (i.e. checking the mapping
first, and then probe it with FFmpeg if one is not found). It also helps
with getting an AVCodecID from a CMDescriptionRef with the least amount of
pain.


Could it be that you are saying FFmpeg needs a CoreMedia demuxer?



Pretty much (it's also something I'm already working on).

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

[FFmpeg-devel] [PATCH] NVENC: Maximum usable surfaces is limited to maximum registered frames

[Miroslav Slugeň]

Maximum usable surfaces is limited to MAX_REGISTERED_FRAMES constant in 
nvenc.h


--
Miroslav Slugeň


>From 96b28516942d76b65e9dce033317909e4c0e019a Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Mon, 21 Nov 2016 11:04:45 +0100
Subject: [PATCH] NVENC: Maximum usable surfaces is limited to maximum
 registered frames

---
 libavcodec/nvenc_h264.c | 2 +-
 libavcodec/nvenc_hevc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
index 6914046b..71e27fd 100644
--- a/libavcodec/nvenc_h264.c
+++ b/libavcodec/nvenc_h264.c
@@ -80,7 +80,7 @@ static const AVOption options[] = {
 { "vbr_2pass","Multi-pass variable bitrate mode",   0,AV_OPT_TYPE_CONST, { .i64 = NV_ENC_PARAMS_RC_2_PASS_VBR },   0, 0, VE, "rc" },
 { "rc-lookahead", "Number of frames to look ahead for rate-control",
 OFFSET(rc_lookahead), AV_OPT_TYPE_INT,   { .i64 = -1 }, -1, INT_MAX, VE },
-{ "surfaces", "Number of concurrent surfaces",  OFFSET(nb_surfaces),  AV_OPT_TYPE_INT,   { .i64 = 32 },  0, INT_MAX, VE },
+{ "surfaces", "Number of concurrent surfaces",  OFFSET(nb_surfaces),  AV_OPT_TYPE_INT,   { .i64 = 32 },  0, MAX_REGISTERED_FRAMES, VE },
 { "cbr",  "Use cbr encoding mode",  OFFSET(cbr),  AV_OPT_TYPE_BOOL,  { .i64 = 0 },   0, 1, VE },
 { "2pass","Use 2pass encoding mode",OFFSET(twopass),  AV_OPT_TYPE_BOOL,  { .i64 = -1 }, -1, 1, VE },
 { "gpu",  "Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on.",
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index 0fec77a..ef739b6 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -79,7 +79,7 @@ static const AVOption options[] = {
 { "vbr_2pass","Multi-pass variable bitrate mode",   0,AV_OPT_TYPE_CONST, { .i64 = NV_ENC_PARAMS_RC_2_PASS_VBR },   0, 0, VE, "rc" },
 { "rc-lookahead", "Number of frames to look ahead for rate-control",
 OFFSET(rc_lookahead), AV_OPT_TYPE_INT,   { .i64 = -1 }, -1, INT_MAX, VE },
-{ "surfaces", "Number of concurrent surfaces",  OFFSET(nb_surfaces),  AV_OPT_TYPE_INT,   { .i64 = 32 },  0, INT_MAX, VE },
+{ "surfaces", "Number of concurrent surfaces",  OFFSET(nb_surfaces),  AV_OPT_TYPE_INT,   { .i64 = 32 },  0, MAX_REGISTERED_FRAMES, VE },
 { "cbr",  "Use cbr encoding mode",  OFFSET(cbr),  AV_OPT_TYPE_BOOL,  { .i64 = 0 },   0, 1, VE },
 { "2pass","Use 2pass encoding mode",OFFSET(twopass),  AV_OPT_TYPE_BOOL,  { .i64 = -1 }, -1, 1, VE },
 { "gpu",  "Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on.",
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] lavfi/avfiltergraph: always reduce all_layouts to a single layout

[Nicolas George]

Le primidi 1er frimaire, an CCXXV, Marton Balint a écrit :
> This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
> 
> Further reference:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
> 
> I can't reproduce ticket #2899 so I am not sure the original patch is still
> needed. Reverting it fixes unknown channel layout support for trivial
> resamples, such as:
> 
> ffmpeg -f lavfi -i "aevalsrc=0|0|0|0|0|0|0|0|0:d=1,asetnsamples" -f null none
> 
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/avfiltergraph.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index 3af698d..379bc1a 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -802,8 +802,7 @@ static int reduce_formats_on_filter(AVFilterContext 
> *filter)
>  if (inlink->type != outlink->type || fmts->nb_channel_layouts == 
> 1)
>  continue;
>  
> -if (fmts->all_layouts &&
> -(!FF_LAYOUT2COUNT(fmt) || fmts->all_counts)) {
> +if (fmts->all_layouts) {
>  /* Turn the infinite list into a singleton */
>  fmts->all_layouts = fmts->all_counts  = 0;
>  if (ff_add_channel_layout(&outlink->in_channel_layouts, fmt) 
> < 0)

This is not correct. It makes a difference if the condition you remove
is false, i.e. if !fmts->all_counts && FF_LAYOUT2COUNT(fmt): the filter
does not support unknown layouts, and you propose to give it one
nonetheless.

Regards,

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[wm4]

On Mon, 21 Nov 2016 07:36:44 +
Rostislav Pehlivanov  wrote:

> On 20 November 2016 at 17:05, Kieran Kunhya  wrote:
> 
> > I object to this patch for the reasons Rostislav outlined..
> >
> > Kieran
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> I actually don't mind the decoder anymore. The code looks simple and neat,
> and it would be nice to be able to view the few random psd files I have and
> which the decoder can open. No full decoding support is planned, which
> would require inhuman effort to complete even like 20% of anyway, so I
> doubt the decoder will grow into a huge mess. I mean viewing psd files is a
> big pain anyway, so eh, if the decoder can open a few of them and save
> people the effort of having gimp (which also doesn't support some psd
> features) without being a security disaster it's okay. When you think about
> it png is also a mess, its been extended to hell with nonstandard chunks,
> but we even have pretty good encoding support for the base of it. Not sure
> what the fuss is here, because there's no public standard?

Can we get support for .doc and .html too? I think these would be great
features.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead

[Miroslav Slugeň]

User selectable surfaces are not working correctly, if you set number of 
surfaces on cmdline, it will always use minimum 32 or 48 depends on 
selected resolution, but in nvenc it is not necessary to use so many 
surfaces.


So from now you can define as low as 1 surface and nvenc will still 
work, it will ofcourse lower GPU memory usage by 95% and async_delay to zero


That was the easy part, now littlebit more...

Next part of this patch is to always prefer rc_lookahead to be more 
important for number of surfaces, than user defined surfaces value. 
Maximum rc_lookahead from nvidia documentation is 32, but could increase 
in future generations so there is no limit for this yet. Value 
async_depth is still accepted and prefered over rc_lookahead.


There were also bug when you request more than rc_lookahead > 31, it 
will always set maximum 31, because surface numbers recalculation was 
after setting lookahead, which is now fixed.


Results:
If you set -rc_lookahead 32 and -bf 3 it will now use only 40 surfaces 
and lower GPU memory usage by 20%, also it will now increase PSNR by 0.012dB


Two more comments:

1. from my internal test, i don't understand addition of 4 more surfaces 
when lookahead is calculated, i didn't used this and everything works as 
with those 4 more extra surfaces, does anybody know what is going on 
there? I looks like it was used for B frames which are calculated 
separately, because B frames maximum is 4.


2. rc_lookahead is defined default to -1, but in test condition if 
(ctx->rc_lookahead) which sets lookahead it will be always true, i don't 
know if this is intended behavior, so in default behavior is lookahead 
always on!


This is default condition when rc_lokkahead is -1 (not defined on 
cmdline), whis is maybe something that is not intended:

ctx->encode_config.rcParams.enableLookahead = 1;
ctx->encode_config.rcParams.lookaheadDepth  = 0;
ctx->encode_config.rcParams.disableIadapt   = 0;
ctx->encode_config.rcParams.disableBadapt   = 0;

--
Miroslav Slugeň


>From ab98c06a19086ee3763722556295fa32ab8b8789 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Mon, 21 Nov 2016 11:30:27 +0100
Subject: [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead
 limit

---
 libavcodec/nvenc.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3a2ef5..fdf8e5d 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -674,6 +674,27 @@ static void nvenc_override_rate_control(AVCodecContext *avctx)
 rc->rateControlMode = ctx->rc;
 }
 
+static av_cold int nvenc_recalc_surfaces(AVCodecContext *avctx)
+{
+NvencContext *ctx = avctx->priv_data;
+int nb_surfaces = 0;
+
+if (ctx->rc_lookahead > 0) {
+nb_surfaces = ctx->rc_lookahead + ((ctx->encode_config.frameIntervalP > 0) ? ctx->encode_config.frameIntervalP : 0) + 1 + 4;
+if (ctx->nb_surfaces < nb_surfaces) {
+av_log(avctx, AV_LOG_WARNING,
+   "Defined rc_lookahead require more surfaces, "
+   "increasing used surfaces %d -> %d\n", ctx->nb_surfaces, nb_surfaces);
+ctx->nb_surfaces = nb_surfaces;
+}
+}
+
+ctx->nb_surfaces = FFMAX(1, FFMIN(MAX_REGISTERED_FRAMES, ctx->nb_surfaces));
+ctx->async_depth = FFMIN(ctx->async_depth, ctx->nb_surfaces - 1);
+
+return 0;
+}
+
 static av_cold void nvenc_setup_rate_control(AVCodecContext *avctx)
 {
 NvencContext *ctx = avctx->priv_data;
@@ -1030,6 +1051,8 @@ static av_cold int nvenc_setup_encoder(AVCodecContext *avctx)
 ctx->initial_pts[0] = AV_NOPTS_VALUE;
 ctx->initial_pts[1] = AV_NOPTS_VALUE;
 
+nvenc_recalc_surfaces(avctx);
+
 nvenc_setup_rate_control(avctx);
 
 if (avctx->flags & AV_CODEC_FLAG_INTERLACED_DCT) {
@@ -1156,11 +1179,6 @@ static av_cold int nvenc_setup_surfaces(AVCodecContext *avctx)
 {
 NvencContext *ctx = avctx->priv_data;
 int i, res;
-int num_mbs = ((avctx->width + 15) >> 4) * ((avctx->height + 15) >> 4);
-ctx->nb_surfaces = FFMAX((num_mbs >= 8160) ? 32 : 48,
- ctx->nb_surfaces);
-ctx->async_depth = FFMIN(ctx->async_depth, ctx->nb_surfaces - 1);
-
 
 ctx->surfaces = av_mallocz_array(ctx->nb_surfaces, sizeof(*ctx->surfaces));
 if (!ctx->surfaces)
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] WIP: subtitles in AVFrame

[wm4]

On Sun, 20 Nov 2016 14:24:00 +0100
Carl Eugen Hoyos  wrote:

> 2016-11-20 13:52 GMT+01:00 Clément Bœsch :
> 
> >> > +static const AVOption sbuffer_options[] = {
> >> > +{ "time_base",  NULL, OFFSET(time_base),  AV_OPT_TYPE_RATIONAL, 
> >> > { .dbl = 0 }, 0, INT_MAX, S },
> >> > +{ "format", NULL, OFFSET(sub_format), AV_OPT_TYPE_INT,  
> >> > { .i64 = -1 }, -1, 1, S, "format" },
> >> > +{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64=-1}, 
> >> > INT_MIN, INT_MAX, S, "format" },
> >> > +{ "bitmap",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=0},  
> >> > INT_MIN, INT_MAX, S, "format" },
> >> > +{ "text",NULL, 0, AV_OPT_TYPE_CONST, {.i64=1},  
> >> > INT_MIN, INT_MAX, S, "format" },  
> >>
> >> Implies no mixed subs. I'm fine with that, but might be restrictive.
> >>  
> >
> > Yeah, so far we don't have such things AFAIK. But we could replace this
> > with a mask later on. It was simpler for the initial format negotiation
> > that way.  
> 
> Will this work with our current external teletext decoder?
> (Will it work with a hypothetical future teletext decoder that provides both
> bitmap and text when decoding?)

That's a different case. I was talking about subtitles with need both
text and images for correct display. Different output formats can be
handled with get_format or a private option or so.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] WIP: subtitles in AVFrame

[Carl Eugen Hoyos]

2016-11-21 12:30 GMT+01:00 wm4 :
> On Sun, 20 Nov 2016 14:24:00 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2016-11-20 13:52 GMT+01:00 Clément Bœsch :
>>
>> >> > +static const AVOption sbuffer_options[] = {
>> >> > +{ "time_base",  NULL, OFFSET(time_base),  
>> >> > AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, INT_MAX, S },
>> >> > +{ "format", NULL, OFFSET(sub_format), AV_OPT_TYPE_INT, 
>> >> >  { .i64 = -1 }, -1, 1, S, "format" },
>> >> > +{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64=-1}, 
>> >> > INT_MIN, INT_MAX, S, "format" },
>> >> > +{ "bitmap",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=0},  
>> >> > INT_MIN, INT_MAX, S, "format" },
>> >> > +{ "text",NULL, 0, AV_OPT_TYPE_CONST, {.i64=1},  
>> >> > INT_MIN, INT_MAX, S, "format" },
>> >>
>> >> Implies no mixed subs. I'm fine with that, but might be restrictive.
>> >>
>> >
>> > Yeah, so far we don't have such things AFAIK. But we could replace this
>> > with a mask later on. It was simpler for the initial format negotiation
>> > that way.
>>
>> Will this work with our current external teletext decoder?
>> (Will it work with a hypothetical future teletext decoder that provides both
>> bitmap and text when decoding?)
>
> That's a different case. I was talking about subtitles with need both
> text and images for correct display. Different output formats can be
> handled with get_format or a private option or so.

So it does already work with our current external teletext decoder and
a hypothetical future teletext decoder that provides both bitmap and
text when decoding?

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

Re: [FFmpeg-devel] [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead

[Carl Eugen Hoyos]

2016-11-21 12:17 GMT+01:00 Miroslav Slugeň :

> That was the easy part, now littlebit more...
>
> Next part of this patch is to always prefer rc_lookahead

[...]

> There were also bug

Please split the patch into two (or three) patches to make
the review and possible regression tests easier.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Carl Eugen Hoyos]

2016-11-21 12:04 GMT+01:00 wm4 :
> On Mon, 21 Nov 2016 07:36:44 +

> Can we get support for .doc and .html too? I think these would be great
> features.

Maybe such comments are not against our policy (that you requested so
much), in any case they are not useful.

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

Re: [FFmpeg-devel] [PATCH] WIP: subtitles in AVFrame

[wm4]

On Sun, 20 Nov 2016 13:52:02 +0100
Clément Bœsch  wrote:

> On Fri, Nov 11, 2016 at 04:46:51PM +0100, wm4 wrote:
> [...]
> > > +
> > > +frame->sub_start_display = sub.start_display_time ? 
> > > av_rescale_q(sub.start_display_time, av_make_q(1, 1000), AV_TIME_BASE_Q)
> > > +  : 
> > > AV_NOPTS_VALUE;
> > > +frame->sub_end_display   = sub.end_display_time   ? 
> > > av_rescale_q(sub.end_display_time,   av_make_q(1, 1000), AV_TIME_BASE_Q)
> > > +  : 
> > > AV_NOPTS_VALUE;  
> > 
> > end_display_time can be UINT32_MAX for "infinite". I think we should
> > clean this up here, and differentiate between "0", "unknown", and
> > "until next event".
> >   
> 
> I don't even know what's the convention today, so this part is currently
> mostly ignored from this first prototype.

dvdsubdec.c leaves end_display_time simply at 0 in some cases (which
means show until next event), while pgssubdec.c always sets it to
UINT32_MAX (which apparently means the same). I don't know why it
was done this way (see 0c911c8fbc).

> What would be the difference between "infinite" and "until next
> (potentially clear) event"?

Probably none.

The important part for non-infinite end time values is whether the
subtitles get strictly replaced by other (later) subtitles, or whether
they overlap.

With the existing API, you have to guess by the codec ID.

> 
> [...]
> > > +static int get_subtitle_buffer(AVFrame *frame)
> > > +{
> > > +int i, ret;
> > > +
> > > +ret = get_data_buffer(frame, frame->sub_nb_rects, 
> > > sizeof(AVFrameSubtitleRectangle));
> > > +if (ret < 0)
> > > +return ret;
> > > +for (i = 0; i < frame->sub_nb_rects; i++)
> > > +memset(frame->extended_data[i], 0, 
> > > sizeof(AVFrameSubtitleRectangle));
> > > +return 0;  
> > 
> > I'm noticing it doesn't allocate the actual subtitle bitmap or text
> > data, which is a difference from audio/video.
> >   
> 
> Yes, exactly. This is tricky. It's really tricky because contrary to audio
> and video, we can not know the size required for every (not yet allocated)
> rectangle from the raw format information alone.
> 
> For video, we have the pixel format, and dimensions. For audio we have the
> sample format and number of samples. But for subtitles, we can at most
> have the number of rectangles.
> 
> To workaround this problem, I just made the get_buffer callback allocate
> the rectangles holder. The decoder will then allocate every rectangle data
> (of different sizes) manually, be it text or actual bitmap rectangle.
> 
> But indeed this means that every ref counting will mean a new allocation
> and copy of the rectangles. As subtitles are meant to be small and sparse,
> I'm assuming it's not exactly a problem.
> 
> Do you have a better suggestion?
> 
> Maybe we could have the user (decoders) allocate the rectangles holder and
> fill all the sizes instead, and then call the get buffer, but this might
> be annoying as it will require for most of them to do it in two-pass
> instead of one as of today.
> 

Seems to me that av_frame_get_buffer() would just have confusing
semantics here, and it'd be better to have dedicated allocation
functions.

But the important part is that the subtitle data is actually properly
refcounted/freed, and that things like copy-on-write actually work.

> > >  }
> > >  
> > >  int av_frame_get_buffer(AVFrame *frame, int align)
> > >  {
> > > +if (frame->sub_nb_rects)
> > > +return get_subtitle_buffer(frame);  
> > 
> > No format set is valid for subtitles?
> >   
> 
> Yes, no format set means text. If the format is set, it defines the format
> used by the rectangles.

Seems slightly questionable.

> [...]
> > > +/* image data for bitmap subtitles, in AVFrame.format 
> > > (AVPixelFormat) */
> > > +uint8_t *data[AV_NUM_DATA_POINTERS];
> > > +int linesize[AV_NUM_DATA_POINTERS];  
> > 
> > Does it define the format somewhere?
> >   
> 
> in AVFrame.format

Right. 

> > > +} AVFrameSubtitleRectangle;  
> > 
> > The struct should probably be extendable (so its size is not part of
> > the ABI).
> >   
> 
> In the current design, there is no need to ever allocate them: you set the
> number of rectangles in your AVFrame, then call av_frame_get_buffer()
> which will allocate them.

You still need to make this explicit. Also, allocation isn't the only
operation you can do on a struct.

> > > @@ -224,9 +242,12 @@ typedef struct AVFrame {
> > >   * For packed audio, there is just one data pointer, and linesize[0]
> > >   * contains the total size of the buffer for all channels.
> > >   *
> > > + * For subtitles, each pointer corresponds to an 
> > > AVFrameSubtitleRectangle.
> > > + *  
> > 
> > It should also mention how many data pointers there are.
> > 
> > Btw. I'm very not much of a fan to have to deal with extended_data. And
> > the duplicat

Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Add support for P010 as an output surface format

[wm4]

On Sat, 19 Nov 2016 17:18:08 -0800
Philip Langdale  wrote:

> The nvidia 375.xx driver introduces support for P016 output surfaces,
> for 10bit and 12bit HEVC content (it's also the first driver to support
> hardware decoding of 12bit content).
> 
> Technically, we don't support P016, but in practice I don't think we
> zero-out the extra bits in P010 so it can be used to carry the data.
> 
> This change introduces cuvid decoder support for P010 output for
> output to hardware and system memory surfaces. For simplicity, it
> does not maintain the previous ability to output NV12 for > 8 bit
> input video - the user will need to update their driver to decode
> such videos.
> 
> After this change, both cuvid and nvenc support P010, but the
> ffmpeg_cuvid transcoding logic will need more work to connect the
> two together. Similarly, the scale_npp filter still only works with
> 8bit surfaces.
> 
> Signed-off-by: Philip Langdale 
> ---
>  compat/cuda/dynlink_cuviddec.h |  3 ++-
>  libavcodec/cuvid.c | 58 
> +++---
>  libavutil/hwcontext_cuda.c | 11 +++-
>  3 files changed, 55 insertions(+), 17 deletions(-)
> 
> diff --git a/compat/cuda/dynlink_cuviddec.h b/compat/cuda/dynlink_cuviddec.h
> index 17207bc..9ff2741 100644
> --- a/compat/cuda/dynlink_cuviddec.h
> +++ b/compat/cuda/dynlink_cuviddec.h
> @@ -83,7 +83,8 @@ typedef enum cudaVideoCodec_enum {
>   * Video Surface Formats Enums
>   */
>  typedef enum cudaVideoSurfaceFormat_enum {
> -cudaVideoSurfaceFormat_NV12=0   /**< NV12 (currently the only 
> supported output format)  */
> +cudaVideoSurfaceFormat_NV12=0,  /**< NV12  */
> +cudaVideoSurfaceFormat_P016=1   /**< P016  */
>  } cudaVideoSurfaceFormat;
>  
>  /*!
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> index c3e831a..34b0734 100644
> --- a/libavcodec/cuvid.c
> +++ b/libavcodec/cuvid.c
> @@ -28,6 +28,7 @@
>  #include "libavutil/fifo.h"
>  #include "libavutil/log.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  
>  #include "avcodec.h"
>  #include "internal.h"
> @@ -103,11 +104,35 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
> *opaque, CUVIDEOFORMAT* form
>  CuvidContext *ctx = avctx->priv_data;
>  AVHWFramesContext *hwframe_ctx = (AVHWFramesContext*)ctx->hwframe->data;
>  CUVIDDECODECREATEINFO cuinfo;
> +int surface_fmt;
> +
> +enum AVPixelFormat pix_fmts_nv12[3] = { AV_PIX_FMT_CUDA,
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_NONE };
> +
> +enum AVPixelFormat pix_fmts_p010[3] = { AV_PIX_FMT_CUDA,
> +AV_PIX_FMT_P010,
> +AV_PIX_FMT_NONE };
>  
>  av_log(avctx, AV_LOG_TRACE, "pfnSequenceCallback, 
> progressive_sequence=%d\n", format->progressive_sequence);
>  
>  ctx->internal_error = 0;
>  
> +surface_fmt = ff_get_format(avctx, format->bit_depth_luma_minus8 > 0 ?
> +pix_fmts_p010 : pix_fmts_nv12);
> +if (surface_fmt < 0) {
> +av_log(avctx, AV_LOG_ERROR, "ff_get_format failed: %d\n", 
> surface_fmt);
> +ctx->internal_error = AVERROR(EINVAL);
> +return 0;
> +}
> +
> +av_log(avctx, AV_LOG_VERBOSE, "Formats: Original: %s | HW: %s | SW: 
> %s\n",
> +   av_get_pix_fmt_name(avctx->pix_fmt),
> +   av_get_pix_fmt_name(surface_fmt),
> +   av_get_pix_fmt_name(avctx->sw_pix_fmt));
> +
> +avctx->pix_fmt = surface_fmt;
> +
>  avctx->width = format->display_area.right;
>  avctx->height = format->display_area.bottom;
>  
> @@ -156,7 +181,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
> *opaque, CUVIDEOFORMAT* form
>  hwframe_ctx->width < avctx->width ||
>  hwframe_ctx->height < avctx->height ||
>  hwframe_ctx->format != AV_PIX_FMT_CUDA ||
> -hwframe_ctx->sw_format != AV_PIX_FMT_NV12)) {
> +hwframe_ctx->sw_format != avctx->sw_pix_fmt)) {
>  av_log(avctx, AV_LOG_ERROR, "AVHWFramesContext is already 
> initialized with incompatible parameters\n");
>  ctx->internal_error = AVERROR(EINVAL);
>  return 0;
> @@ -177,7 +202,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
> *opaque, CUVIDEOFORMAT* form
>  
>  cuinfo.CodecType = ctx->codec_type = format->codec;
>  cuinfo.ChromaFormat = format->chroma_format;
> -cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
> +
> +switch (avctx->sw_pix_fmt) {
> +case AV_PIX_FMT_NV12:
> +cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
> +break;
> +case AV_PIX_FMT_P010:
> +cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016;
> +break;
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12 or P010 
> are not supported\n");
> +ctx->internal_error = AVERROR(EINVAL);
> +ret

Re: [FFmpeg-devel] [PATCH] NVENC: Maximum usable surfaces is limited to maximum registered frames

[Timo Rothenpieler]

Patch LGTM, applied locally, will push most likely tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead

[Timo Rothenpieler]

> Please split the patch into two (or three) patches to make
> the review and possible regression tests easier.

The bug was implicitly fixed by the new code, it doesn't seem necessary
to me to fix it independently, specially as so far nobody seems to have
run into it.

Patch LGTM, applied locally, will push most likely tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead

[Miroslav Slugeň]

Thx, i has same opinion :)

Miroslav Slugeň
+420 724 825 885

Dne 21.11.2016 v 12:57 Timo Rothenpieler napsal(a):

Please split the patch into two (or three) patches to make
the review and possible regression tests easier.

The bug was implicitly fixed by the new code, it doesn't seem necessary
to me to fix it independently, specially as so far nobody seems to have
run into it.

Patch LGTM, applied locally, will push most likely tomorrow.
___
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] libavcodec : add psd image file decoder

[wm4]

On Mon, 21 Nov 2016 12:48:31 +0100
Carl Eugen Hoyos  wrote:

> 2016-11-21 12:04 GMT+01:00 wm4 :
> > On Mon, 21 Nov 2016 07:36:44 +  
> 
> > Can we get support for .doc and .html too? I think these would be great
> > features.  
> 
> Maybe such comments are not against our policy (that you requested so
> much), in any case they are not useful.

I do not understand this. Please explain why requesting features is
against policy or not useful.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Carl Eugen Hoyos]

2016-11-21 13:06 GMT+01:00 wm4 :
> On Mon, 21 Nov 2016 12:48:31 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2016-11-21 12:04 GMT+01:00 wm4 :
>> > On Mon, 21 Nov 2016 07:36:44 +
>>
>> > Can we get support for .doc and .html too? I think these would be great
>> > features.
>>
>> Maybe such comments are not against our policy (that you requested so
>> much), in any case they are not useful.
>
> I do not understand this. Please explain why requesting features is
> against policy or not useful.

The development mailing list is not the right place for a feature request
(so your email is in fact a policy violation).

Apart from the fact that doc support does not seem realistic to me:
What would FFmpeg do with the files once it contains a decoder?

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

[FFmpeg-devel] [PATCH] CUVID: Allow to set number of used surfaces for decoding (resend)

[Miroslav Slugeň]

We are using more decoding threads at once, so it is sometime useful to 
lower number of surfaces used for decoding, it could lower GPU memory usage.


--
Miroslav Slugeň


>From 30ddf173c87a9da16ba4725f8beea67d8fa6f537 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Mon, 21 Nov 2016 10:51:25 +0100
Subject: [PATCH] CUVID: Allow to set number of used surfaces for decoding

---
 libavcodec/cuvid.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index eafce0a..fbe32fb 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -32,8 +32,6 @@
 
 #include "compat/cuda/nvcuvid.h"
 
-#define MAX_FRAME_COUNT 25
-
 typedef struct CuvidContext
 {
 AVClass *avclass;
@@ -42,6 +40,7 @@ typedef struct CuvidContext
 CUvideoparser cuparser;
 
 char *cu_gpu;
+int nb_surfaces;
 
 AVBufferRef *hwdevice;
 AVBufferRef *hwframe;
@@ -185,7 +184,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = format->bit_depth_luma_minus8;
@@ -268,7 +267,7 @@ static int cuvid_decode_packet(AVCodecContext *avctx, const AVPacket *avpkt)
 if (is_flush && avpkt && avpkt->size)
 return AVERROR_EOF;
 
-if (av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame) > MAX_FRAME_COUNT - 2 && avpkt && avpkt->size)
+if ((av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame)) + 2 > ctx->nb_surfaces && avpkt && avpkt->size)
 return AVERROR(EAGAIN);
 
 if (ctx->bsf && avpkt && avpkt->size) {
@@ -576,7 +575,7 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS *cu
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = 0;
@@ -616,7 +615,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
 return ret;
 }
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 ret = AVERROR(ENOMEM);
 goto error;
@@ -743,7 +742,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
FFMIN(sizeof(ctx->cuparse_ext.raw_seqhdr_data), avctx->extradata_size));
 }
 
-ctx->cuparseinfo.ulMaxNumDecodeSurfaces = MAX_FRAME_COUNT;
+ctx->cuparseinfo.ulMaxNumDecodeSurfaces = ctx->nb_surfaces;
 ctx->cuparseinfo.ulMaxDisplayDelay = 4;
 ctx->cuparseinfo.pUserData = avctx;
 ctx->cuparseinfo.pfnSequenceCallback = cuvid_handle_video_sequence;
@@ -802,7 +801,7 @@ static void cuvid_flush(AVCodecContext *avctx)
 
 av_fifo_freep(&ctx->frame_queue);
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 av_log(avctx, AV_LOG_ERROR, "Failed to recreate frame queue on flush\n");
 return;
@@ -851,6 +850,7 @@ static const AVOption options[] = {
 { "bob",  "Bob deinterlacing",   0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Bob  }, 0, 0, VD, "deint" },
 { "adaptive", "Adaptive deinterlacing",  0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
 { "gpu",  "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
+{ "surfaces", "Maximum surfaces to be used for decoding", OFFSET(surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
 { NULL }
 };
 
-- 
2.1.4


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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[wm4]

On Mon, 21 Nov 2016 13:08:37 +0100
Carl Eugen Hoyos  wrote:

> 2016-11-21 13:06 GMT+01:00 wm4 :
> > On Mon, 21 Nov 2016 12:48:31 +0100
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2016-11-21 12:04 GMT+01:00 wm4 :  
> >> > On Mon, 21 Nov 2016 07:36:44 +  
> >>  
> >> > Can we get support for .doc and .html too? I think these would be great
> >> > features.  
> >>
> >> Maybe such comments are not against our policy (that you requested so
> >> much), in any case they are not useful.  
> >
> > I do not understand this. Please explain why requesting features is
> > against policy or not useful.  
> 
> The development mailing list is not the right place for a feature request
> (so your email is in fact a policy violation).
> 
> Apart from the fact that doc support does not seem realistic to me:
> What would FFmpeg do with the files once it contains a decoder?

The same as our teletype decoder does.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] CUVID: Allow to set number of used surfaces for decoding (resend)

[Timo Rothenpieler]

Does not compile:

libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
 #define OFFSET(x) offsetof(CuvidContext, x)


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

[FFmpeg-devel] [PATCH] avformat/flvenc: add no_metadata to flvflags

[Steven Liu]

some flv have no metadata,
ffmpeg will same with the source flv stream.

Signed-off-by: Steven Liu 
---
 doc/muxers.texi  |3 +++
 libavformat/flvenc.c |8 +++-
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 806182a..8689341 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -148,6 +148,9 @@ Place AAC sequence header based on audio stream data.
 @item no_sequence_end
 Disable sequence end tag.
 
+@item no_metadata
+Disable metadata tag.
+
 @item add_keyframe_index
 Used to facilitate seeking; particularly for HTTP pseudo streaming.
 @end table
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 4ca6aea..177052a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -67,6 +67,7 @@ typedef enum {
 FLV_AAC_SEQ_HEADER_DETECT = (1 << 0),
 FLV_NO_SEQUENCE_END = (1 << 1),
 FLV_ADD_KEYFRAME_INDEX = (1 << 2),
+FLV_NO_METADATA = (1 << 3),
 } FLVFlags;
 
 typedef struct FLVFileposition {
@@ -744,7 +745,11 @@ static int flv_write_header(AVFormatContext *s)
 flv->reserved = 5;
 }
 
-write_metadata(s, 0);
+if (flv->flags & FLV_NO_METADATA) {
+pb->seekable = 0;
+} else {
+write_metadata(s, 0);
+}
 
 for (i = 0; i < s->nb_streams; i++) {
 flv_write_codec_header(s, s->streams[i]->codecpar);
@@ -1055,6 +1060,7 @@ static const AVOption options[] = {
 { "flvflags", "FLV muxer flags", offsetof(FLVContext, flags), 
AV_OPT_TYPE_FLAGS, {.i64 = 0}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"flvflags" },
 { "aac_seq_header_detect", "Put AAC sequence header based on stream data", 
0, AV_OPT_TYPE_CONST, {.i64 = FLV_AAC_SEQ_HEADER_DETECT}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
 { "no_sequence_end", "disable sequence end for FLV", 0, AV_OPT_TYPE_CONST, 
{.i64 = FLV_NO_SEQUENCE_END}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"flvflags" },
+{ "no_metadata", "disable metadata for FLV", 0, AV_OPT_TYPE_CONST, {.i64 = 
FLV_NO_METADATA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
 { "add_keyframe_index", "Add keyframe index metadata", 0, 
AV_OPT_TYPE_CONST, {.i64 = FLV_ADD_KEYFRAME_INDEX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
 { NULL },
 };
-- 
1.7.1



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

Re: [FFmpeg-devel] [PATCH] CUVID: Allow to set number of used surfaces for decoding (resend)

[Miroslav Slugeň]

Thanks, sending corrected version.

just changed OFFSET(surfaces) to OFFSET(nb_surfaces)

Miroslav Slugeň
+420 724 825 885

Dne 21.11.2016 v 13:29 Timo Rothenpieler napsal(a):

Does not compile:

libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
  #define OFFSET(x) offsetof(CuvidContext, x)


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


>From 30ddf173c87a9da16ba4725f8beea67d8fa6f537 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Mon, 21 Nov 2016 10:51:25 +0100
Subject: [PATCH] CUVID: Allow to set number of used surfaces for decoding

---
 libavcodec/cuvid.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index eafce0a..fbe32fb 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -32,8 +32,6 @@
 
 #include "compat/cuda/nvcuvid.h"
 
-#define MAX_FRAME_COUNT 25
-
 typedef struct CuvidContext
 {
 AVClass *avclass;
@@ -42,6 +40,7 @@ typedef struct CuvidContext
 CUvideoparser cuparser;
 
 char *cu_gpu;
+int nb_surfaces;
 
 AVBufferRef *hwdevice;
 AVBufferRef *hwframe;
@@ -185,7 +184,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = format->bit_depth_luma_minus8;
@@ -268,7 +267,7 @@ static int cuvid_decode_packet(AVCodecContext *avctx, const AVPacket *avpkt)
 if (is_flush && avpkt && avpkt->size)
 return AVERROR_EOF;
 
-if (av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame) > MAX_FRAME_COUNT - 2 && avpkt && avpkt->size)
+if ((av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame)) + 2 > ctx->nb_surfaces && avpkt && avpkt->size)
 return AVERROR(EAGAIN);
 
 if (ctx->bsf && avpkt && avpkt->size) {
@@ -576,7 +575,7 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS *cu
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = 0;
@@ -616,7 +615,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
 return ret;
 }
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 ret = AVERROR(ENOMEM);
 goto error;
@@ -743,7 +742,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
FFMIN(sizeof(ctx->cuparse_ext.raw_seqhdr_data), avctx->extradata_size));
 }
 
-ctx->cuparseinfo.ulMaxNumDecodeSurfaces = MAX_FRAME_COUNT;
+ctx->cuparseinfo.ulMaxNumDecodeSurfaces = ctx->nb_surfaces;
 ctx->cuparseinfo.ulMaxDisplayDelay = 4;
 ctx->cuparseinfo.pUserData = avctx;
 ctx->cuparseinfo.pfnSequenceCallback = cuvid_handle_video_sequence;
@@ -802,7 +801,7 @@ static void cuvid_flush(AVCodecContext *avctx)
 
 av_fifo_freep(&ctx->frame_queue);
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 av_log(avctx, AV_LOG_ERROR, "Failed to recreate frame queue on flush\n");
 return;
@@ -851,6 +850,7 @@ static const AVOption options[] = {
 { "bob",  "Bob deinterlacing",   0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Bob  }, 0, 0, VD, "deint" },
 { "adaptive", "Adaptive deinterlacing",  0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
 { "gpu",  "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
+{ "surfaces", "Maximum surfaces to be used for decoding", OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
 { NULL }
 };
 
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[James Almer]

On 11/21/2016 4:21 AM, Rostislav Pehlivanov wrote:
> On 17 November 2016 at 00:08, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> All the fields can be set via options read from the ffm file and thus
>> have to be sanitized.
>>
>> A negative extradata size for example gets passed to memcpy in
>> avcodec_parameters_from_context causing a segmentation fault.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>
>>
> The ffm demuxer and ffserver will be removed before the next release (no
> getting out of this, Reynaldo),
> so it'll be pointless but whatever.

ffm de/muxers can't be removed until there's a major bump. So while
ffserver will be removed in the next version, ffm will depend on what 
happens with the libraries.

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

[FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Gregory J. Wolfe]

(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both gcc and Windows run
time functions are available to get this information.  However, when Windows
threading has been selected, the Windows function should be used, not the
gcc function.  This avoids creating an unnecessary dependency on the gcc
thread library.

(2) When ALL threading support is disabled, the build should not create a
dependency on ANY thread library.

Signed-off-by: Gregory J. Wolfe 
---
 libavutil/cpu.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index f5785fc..3843778 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -258,10 +258,15 @@ int av_cpu_count(void)
 static volatile int printed;
 
 int nb_cpus = 1;
+#if HAVE_THREADS
 #if HAVE_WINRT
 SYSTEM_INFO sysinfo;
 #endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK, we will use
+// Windows GetProcessAffinityMask() instead of gcc library function
+// sched_getaffinity().  This avoids creating a dependency on the gcc
+// thread library that we don't need/want.
+#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) && !(HAVE_W32THREADS && 
HAVE_GETPROCESSAFFINITYMASK)
 cpu_set_t cpuset;
 
 CPU_ZERO(&cpuset);
@@ -286,6 +291,7 @@ int av_cpu_count(void)
 GetNativeSystemInfo(&sysinfo);
 nb_cpus = sysinfo.dwNumberOfProcessors;
 #endif
+#endif
 
 if (!printed) {
 av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
-- 
2.5.1.windows.1

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

[FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage

[Michael Niedermayer]

With this it is possible to prevent OOM with untrusted media

As this fundamentally requires keeping track of allocated memory sizes
and the memalign hack code does nearly exactly that already, this feature
depends on it being enabled.

Signed-off-by: Michael Niedermayer 
---
 libavutil/mem.c | 45 -
 libavutil/mem.h | 17 +
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 6273d89..6ee07b7 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -37,6 +37,7 @@
 #endif
 
 #include "avassert.h"
+#include "atomic.h"
 #include "avutil.h"
 #include "common.h"
 #include "dynarray.h"
@@ -69,11 +70,39 @@ void  free(void *ptr);
  * Note that this will cost performance. */
 
 static size_t max_alloc_size= INT_MAX;
+static int64_t max_heap_size= 0;
+static volatile int64_t heap_size = 0;
 
 void av_max_alloc(size_t max){
 max_alloc_size = max;
 }
 
+int av_max_heap(uint64_t max)
+{
+#if CONFIG_MEMALIGN_HACK
+max_heap_size = max;
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
+
+static int heap_change(int64_t size, int force)
+{
+int64_t oldval, newval;
+if (!max_heap_size)
+return 0;
+
+do {
+oldval = heap_size;
+if (!force && max_heap_size - oldval < size)
+return AVERROR(ENOMEM);
+newval = oldval + size;
+} while (oldval != avpriv_atomic_int64_cas(&heap_size, oldval, newval));
+
+return 0;
+}
+
 void *av_malloc(size_t size)
 {
 void *ptr = NULL;
@@ -86,9 +115,15 @@ void *av_malloc(size_t size)
 return NULL;
 
 #if CONFIG_MEMALIGN_HACK
+
+if (heap_change(size + ALIGN + 8, 0) < 0)
+return NULL;
+
 ptr = malloc(size + ALIGN + 8);
-if (!ptr)
+if (!ptr) {
+heap_change(-((int64_t)size + ALIGN + 8), 1);
 return ptr;
+}
 
 diff = uintptr_t)ptr) + 9 + ALIGN - 1) & ~(ALIGN - 1)) - 
(uintptr_t)ptr;
 av_assert0(diff>0 && diff<=ALIGN + 8);
@@ -164,9 +199,15 @@ void *av_realloc(void *ptr, size_t size)
 
 // Quick path for apparently and likly aligned realloc()
 if (diff == ALIGN) {
+int64_t size_delta = size - ((int64_t *)ptr)[-1];
+if (heap_change(size_delta, 0) < 0)
+return NULL;
+
 ptr = realloc((char *)ptr - diff, size + diff);
 if (ptr)
 ptr = (char *)ptr + diff;
+else
+heap_change(-size_delta, 1);
 if (!(((uintptr_t)ptr) & (ALIGN - 1))) {
 if (ptr)
 ((int64_t *)ptr)[-1] = size;
@@ -250,8 +291,10 @@ void av_free(void *ptr)
 #if CONFIG_MEMALIGN_HACK
 if (ptr) {
 int v= ((char *)ptr)[-9];
+int64_t size = ((int64_t *)ptr)[-1];
 av_assert0(v>0 && v<=ALIGN + 8);
 free((char *)ptr - v);
+heap_change(-size, 1);
 }
 #elif HAVE_ALIGNED_MALLOC
 _aligned_free(ptr);
diff --git a/libavutil/mem.h b/libavutil/mem.h
index f9d8884..9cce433 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -689,6 +689,23 @@ static inline int av_size_mult(size_t a, size_t b, size_t 
*r)
 void av_max_alloc(size_t max);
 
 /**
+ * Set the maximum heap size that may be allocated.
+ *
+ * The value specified with this function is effective for all libavutil's @ref
+ * lavu_mem_funcs "heap management functions."
+ *
+ * By default, there is no limit.
+ * If this is set lower than the currently allocated space then behavior is
+ * undefined.
+ * Allocations prior to this being set are potentially not kept track of.
+ *
+ * @param max Value to be set as the new maximum size
+ *
+ * @return >= 0 or a negative error code in case of failure
+ */
+int av_max_heap(uint64_t max);
+
+/**
  * @}
  * @}
  */
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] avutil/atomic: Add avpriv_atomic_int64_cas()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/atomic.c | 20 
 libavutil/atomic.h | 10 ++
 libavutil/atomic_gcc.h | 12 
 3 files changed, 42 insertions(+)

diff --git a/libavutil/atomic.c b/libavutil/atomic.c
index 64cff25..27561ad 100644
--- a/libavutil/atomic.c
+++ b/libavutil/atomic.c
@@ -70,6 +70,17 @@ void *avpriv_atomic_ptr_cas(void * volatile *ptr, void 
*oldval, void *newval)
 return ret;
 }
 
+int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, int64_t 
newval)
+{
+int64_t ret;
+pthread_mutex_lock(&atomic_lock);
+ret = *ptr;
+if (ret == oldval)
+*ptr = newval;
+pthread_mutex_unlock(&atomic_lock);
+return ret;
+}
+
 #elif !HAVE_THREADS
 
 int avpriv_atomic_int_get(volatile int *ptr)
@@ -97,6 +108,15 @@ void *avpriv_atomic_ptr_cas(void * volatile *ptr, void 
*oldval, void *newval)
 return *ptr;
 }
 
+int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, int64_t 
newval)
+{
+if (*ptr == oldval) {
+*ptr = newval;
+return oldval;
+}
+return *ptr;
+}
+
 #else /* HAVE_THREADS */
 
 /* This should never trigger, unless a new threading implementation
diff --git a/libavutil/atomic.h b/libavutil/atomic.h
index 15906d2..cabc4f0 100644
--- a/libavutil/atomic.h
+++ b/libavutil/atomic.h
@@ -74,6 +74,16 @@ int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int 
inc);
  */
 void *avpriv_atomic_ptr_cas(void * volatile *ptr, void *oldval, void *newval);
 
+/**
+ * Atomic int64_t compare and swap.
+ *
+ * @param ptr pointer to the int64_t to operate on
+ * @param oldval do the swap if the current value of *ptr equals to oldval
+ * @param newval value to replace *ptr with
+ * @return the value of *ptr before comparison
+ */
+int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, int64_t 
newval);
+
 #endif /* HAVE_ATOMICS_NATIVE */
 
 #endif /* AVUTIL_ATOMIC_H */
diff --git a/libavutil/atomic_gcc.h b/libavutil/atomic_gcc.h
index 5f9fc49..c7e0dba 100644
--- a/libavutil/atomic_gcc.h
+++ b/libavutil/atomic_gcc.h
@@ -75,4 +75,16 @@ static inline void *atomic_ptr_cas_gcc(void * volatile *ptr,
 #endif
 }
 
+#define avpriv_atomic_int64_cas atomic_int64_cas_gcc
+static inline int64_t atomic_int64_cas_gcc(int64_t volatile *ptr,
+   int64_t oldval, int64_t newval)
+{
+#if HAVE_SYNC_VAL_COMPARE_AND_SWAP
+return __sync_val_compare_and_swap(ptr, oldval, newval);
+#else
+__atomic_compare_exchange_n(ptr, &oldval, newval, 0, __ATOMIC_SEQ_CST, 
__ATOMIC_SEQ_CST);
+return oldval;
+#endif
+}
+
 #endif /* AVUTIL_ATOMIC_GCC_H */
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/3] avutil/mem: Fix *realloc() alignment with memalign hack

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/mem.c | 44 
 1 file changed, 32 insertions(+), 12 deletions(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 1a8fc21..6273d89 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -86,12 +86,15 @@ void *av_malloc(size_t size)
 return NULL;
 
 #if CONFIG_MEMALIGN_HACK
-ptr = malloc(size + ALIGN);
+ptr = malloc(size + ALIGN + 8);
 if (!ptr)
 return ptr;
-diff  = ((~(long)ptr)&(ALIGN - 1)) + 1;
+
+diff = uintptr_t)ptr) + 9 + ALIGN - 1) & ~(ALIGN - 1)) - 
(uintptr_t)ptr;
+av_assert0(diff>0 && diff<=ALIGN + 8);
 ptr   = (char *)ptr + diff;
-((char *)ptr)[-1] = diff;
+((char *)ptr)[-9] = diff;
+((int64_t *)ptr)[-1] = size;
 #elif HAVE_POSIX_MEMALIGN
 if (size) //OS X on SDK 10.6 has a broken posix_memalign implementation
 if (posix_memalign(&ptr, ALIGN, size))
@@ -146,6 +149,7 @@ void *av_realloc(void *ptr, size_t size)
 {
 #if CONFIG_MEMALIGN_HACK
 int diff;
+void *ptr2;
 #endif
 
 /* let's disallow possibly ambiguous cases */
@@ -153,15 +157,31 @@ void *av_realloc(void *ptr, size_t size)
 return NULL;
 
 #if CONFIG_MEMALIGN_HACK
-//FIXME this isn't aligned correctly, though it probably isn't needed
 if (!ptr)
 return av_malloc(size);
-diff = ((char *)ptr)[-1];
-av_assert0(diff>0 && diff<=ALIGN);
-ptr = realloc((char *)ptr - diff, size + diff);
-if (ptr)
-ptr = (char *)ptr + diff;
-return ptr;
+diff = ((char *)ptr)[-9];
+av_assert0(diff>0 && diff<=ALIGN + 8);
+
+// Quick path for apparently and likly aligned realloc()
+if (diff == ALIGN) {
+ptr = realloc((char *)ptr - diff, size + diff);
+if (ptr)
+ptr = (char *)ptr + diff;
+if (!(((uintptr_t)ptr) & (ALIGN - 1))) {
+if (ptr)
+((int64_t *)ptr)[-1] = size;
+return ptr;
+}
+}
+
+ptr2 = av_malloc(size);
+if (!ptr2)
+return NULL;
+
+memcpy(ptr2, ptr, FFMIN(((int64_t *)ptr)[-1], size));
+((int64_t *)ptr2)[-1] = size;
+av_free(ptr);
+return ptr2;
 #elif HAVE_ALIGNED_MALLOC
 return _aligned_realloc(ptr, size + !size, ALIGN);
 #else
@@ -229,8 +249,8 @@ void av_free(void *ptr)
 {
 #if CONFIG_MEMALIGN_HACK
 if (ptr) {
-int v= ((char *)ptr)[-1];
-av_assert0(v>0 && v<=ALIGN);
+int v= ((char *)ptr)[-9];
+av_assert0(v>0 && v<=ALIGN + 8);
 free((char *)ptr - v);
 }
 #elif HAVE_ALIGNED_MALLOC
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: Add support for P016 as an output surface format

[Philip Langdale]

The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).

This change introduces cuvid decoder support for P016 output for
output to hardware and system memory surfaces. For simplicity, it
does not maintain the previous ability to output NV12 for > 8 bit
input video - the user will need to update their driver to decode
such videos.

Signed-off-by: Philip Langdale 
---
 compat/cuda/dynlink_cuviddec.h |  3 ++-
 libavcodec/cuvid.c | 59 ++
 libavutil/hwcontext_cuda.c | 11 +++-
 3 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/compat/cuda/dynlink_cuviddec.h b/compat/cuda/dynlink_cuviddec.h
index 17207bc..9ff2741 100644
--- a/compat/cuda/dynlink_cuviddec.h
+++ b/compat/cuda/dynlink_cuviddec.h
@@ -83,7 +83,8 @@ typedef enum cudaVideoCodec_enum {
  * Video Surface Formats Enums
  */
 typedef enum cudaVideoSurfaceFormat_enum {
-cudaVideoSurfaceFormat_NV12=0   /**< NV12 (currently the only 
supported output format)  */
+cudaVideoSurfaceFormat_NV12=0,  /**< NV12  */
+cudaVideoSurfaceFormat_P016=1   /**< P016  */
 } cudaVideoSurfaceFormat;
 
 /*!
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index c3e831a..6798bac 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -28,6 +28,7 @@
 #include "libavutil/fifo.h"
 #include "libavutil/log.h"
 #include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
 
 #include "avcodec.h"
 #include "internal.h"
@@ -103,11 +104,35 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 CuvidContext *ctx = avctx->priv_data;
 AVHWFramesContext *hwframe_ctx = (AVHWFramesContext*)ctx->hwframe->data;
 CUVIDDECODECREATEINFO cuinfo;
+int surface_fmt;
+
+enum AVPixelFormat pix_fmts_nv12[3] = { AV_PIX_FMT_CUDA,
+AV_PIX_FMT_NV12,
+AV_PIX_FMT_NONE };
+
+enum AVPixelFormat pix_fmts_p016[3] = { AV_PIX_FMT_CUDA,
+AV_PIX_FMT_P016,
+AV_PIX_FMT_NONE };
 
 av_log(avctx, AV_LOG_TRACE, "pfnSequenceCallback, 
progressive_sequence=%d\n", format->progressive_sequence);
 
 ctx->internal_error = 0;
 
+surface_fmt = ff_get_format(avctx, format->bit_depth_luma_minus8 > 0 ?
+pix_fmts_p016 : pix_fmts_nv12);
+if (surface_fmt < 0) {
+av_log(avctx, AV_LOG_ERROR, "ff_get_format failed: %d\n", surface_fmt);
+ctx->internal_error = AVERROR(EINVAL);
+return 0;
+}
+
+av_log(avctx, AV_LOG_VERBOSE, "Formats: Original: %s | HW: %s | SW: %s\n",
+   av_get_pix_fmt_name(avctx->pix_fmt),
+   av_get_pix_fmt_name(surface_fmt),
+   av_get_pix_fmt_name(avctx->sw_pix_fmt));
+
+avctx->pix_fmt = surface_fmt;
+
 avctx->width = format->display_area.right;
 avctx->height = format->display_area.bottom;
 
@@ -156,7 +181,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 hwframe_ctx->width < avctx->width ||
 hwframe_ctx->height < avctx->height ||
 hwframe_ctx->format != AV_PIX_FMT_CUDA ||
-hwframe_ctx->sw_format != AV_PIX_FMT_NV12)) {
+hwframe_ctx->sw_format != avctx->sw_pix_fmt)) {
 av_log(avctx, AV_LOG_ERROR, "AVHWFramesContext is already initialized 
with incompatible parameters\n");
 ctx->internal_error = AVERROR(EINVAL);
 return 0;
@@ -177,7 +202,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 
 cuinfo.CodecType = ctx->codec_type = format->codec;
 cuinfo.ChromaFormat = format->chroma_format;
-cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
+
+switch (avctx->sw_pix_fmt) {
+case AV_PIX_FMT_NV12:
+cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
+break;
+case AV_PIX_FMT_P016:
+cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12 or P016 
are not supported\n");
+ctx->internal_error = AVERROR(EINVAL);
+return 0;
+}
 
 cuinfo.ulWidth = avctx->coded_width;
 cuinfo.ulHeight = avctx->coded_height;
@@ -209,7 +246,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 
 if (!hwframe_ctx->pool) {
 hwframe_ctx->format = AV_PIX_FMT_CUDA;
-hwframe_ctx->sw_format = AV_PIX_FMT_NV12;
+hwframe_ctx->sw_format = avctx->sw_pix_fmt;
 hwframe_ctx->width = avctx->width;
 hwframe_ctx->height = avctx->height;
 
@@ -417,7 +454,8 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 offset += avctx->coded_height;
 }
-} else if (avct

[FFmpeg-devel] [PATCH 0/2] CUVID & NVENC support for P016 content

[Philip Langdale]

These changes allow cuvid to output P016 for 10/12bit content
and nvenc to accept it (treating it as P010). Additional work
will be required for transcoding, however.

Philip Langdale (2):
  avcodec/cuvid: Add support for P016 as an output surface format
  avcodec/nvenc: Accept P016 content

 compat/cuda/dynlink_cuviddec.h |  3 ++-
 libavcodec/cuvid.c | 59 ++
 libavcodec/nvenc.c |  3 +++
 libavutil/hwcontext_cuda.c | 11 +++-
 4 files changed, 58 insertions(+), 18 deletions(-)

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

[FFmpeg-devel] [PATCH 2/2] avcodec/nvenc: Accept P016 content

[Philip Langdale]

nvenc doesn't officially support P016 input, but at the same time,
cuvid only outputs P016, technically (it uses the same format for
both 10 and 12 bit output). As it's safe to pass P016 when P010 is
expected, let's just allow it; it's wasteful to force content through
swscale.

After this change, both cuvid and nvenc support P016, but the
ffmpeg_cuvid transcoding logic will need more work to connect the
two together. Similarly, the scale_npp filter still only works with
8bit surfaces.

Signed-off-by: Philip Langdale 
---
 libavcodec/nvenc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index d71a445..ba8fdfd 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -39,6 +39,7 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_P010,
+AV_PIX_FMT_P016,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUV444P16,
 AV_PIX_FMT_0RGB32,
@@ -48,6 +49,7 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 };
 
 #define IS_10BIT(pix_fmt) (pix_fmt == AV_PIX_FMT_P010 ||\
+   pix_fmt == AV_PIX_FMT_P016 ||\
pix_fmt == AV_PIX_FMT_YUV444P16)
 
 #define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P || \
@@ -1018,6 +1020,7 @@ static av_cold int nvenc_alloc_surface(AVCodecContext 
*avctx, int idx)
 break;
 
 case AV_PIX_FMT_P010:
+case AV_PIX_FMT_P016:
 ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV420_10BIT;
 break;
 
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avutil/mem: Fix *realloc() alignment with memalign hack

[wm4]

On Mon, 21 Nov 2016 16:18:56 +0100
Michael Niedermayer  wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/mem.c | 44 
>  1 file changed, 32 insertions(+), 12 deletions(-)
> 

"Fix" is not a good description. Was it broken? What was broken?

Also, I thought the memalign hack was generally not needed anymore.
Which platforms still need it?

> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 1a8fc21..6273d89 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -86,12 +86,15 @@ void *av_malloc(size_t size)
>  return NULL;
>  
>  #if CONFIG_MEMALIGN_HACK
> -ptr = malloc(size + ALIGN);
> +ptr = malloc(size + ALIGN + 8);
>  if (!ptr)
>  return ptr;
> -diff  = ((~(long)ptr)&(ALIGN - 1)) + 1;
> +
> +diff = uintptr_t)ptr) + 9 + ALIGN - 1) & ~(ALIGN - 1)) - 
> (uintptr_t)ptr;
> +av_assert0(diff>0 && diff<=ALIGN + 8);

Why 9?

>  ptr   = (char *)ptr + diff;
> -((char *)ptr)[-1] = diff;
> +((char *)ptr)[-9] = diff;
> +((int64_t *)ptr)[-1] = size;
>  #elif HAVE_POSIX_MEMALIGN
>  if (size) //OS X on SDK 10.6 has a broken posix_memalign implementation
>  if (posix_memalign(&ptr, ALIGN, size))
> @@ -146,6 +149,7 @@ void *av_realloc(void *ptr, size_t size)
>  {
>  #if CONFIG_MEMALIGN_HACK
>  int diff;
> +void *ptr2;
>  #endif
>  
>  /* let's disallow possibly ambiguous cases */
> @@ -153,15 +157,31 @@ void *av_realloc(void *ptr, size_t size)
>  return NULL;
>  
>  #if CONFIG_MEMALIGN_HACK
> -//FIXME this isn't aligned correctly, though it probably isn't needed
>  if (!ptr)
>  return av_malloc(size);
> -diff = ((char *)ptr)[-1];
> -av_assert0(diff>0 && diff<=ALIGN);  
> -ptr = realloc((char *)ptr - diff, size + diff);
> -if (ptr)
> -ptr = (char *)ptr + diff;
> -return ptr;
> +diff = ((char *)ptr)[-9];
> +av_assert0(diff>0 && diff<=ALIGN + 8);
> +
> +// Quick path for apparently and likly aligned realloc()
> +if (diff == ALIGN) {
> +ptr = realloc((char *)ptr - diff, size + diff);
> +if (ptr)
> +ptr = (char *)ptr + diff;
> +if (!(((uintptr_t)ptr) & (ALIGN - 1))) {
> +if (ptr)
> +((int64_t *)ptr)[-1] = size;
> +return ptr;
> +}
> +}
> +
> +ptr2 = av_malloc(size);
> +if (!ptr2)
> +return NULL;
> +
> +memcpy(ptr2, ptr, FFMIN(((int64_t *)ptr)[-1], size));
> +((int64_t *)ptr2)[-1] = size;
> +av_free(ptr);
> +return ptr2;

I thought av_realloc() never keeps alignment. It only needs to be sure
to not choke on the alignment hack, since calling av_realloc() on a
av_malloc() allocated block is still ok, even if it can lose the
alignment.

>  #elif HAVE_ALIGNED_MALLOC
>  return _aligned_realloc(ptr, size + !size, ALIGN);
>  #else
> @@ -229,8 +249,8 @@ void av_free(void *ptr)
>  {
>  #if CONFIG_MEMALIGN_HACK
>  if (ptr) {
> -int v= ((char *)ptr)[-1];
> -av_assert0(v>0 && v<=ALIGN);  
> +int v= ((char *)ptr)[-9];
> +av_assert0(v>0 && v<=ALIGN + 8);
>  free((char *)ptr - v);
>  }
>  #elif HAVE_ALIGNED_MALLOC

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil: add P016 pixel format

[wm4]

On Sun, 20 Nov 2016 14:35:51 -0800
Philip Langdale  wrote:

> P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
> two bytes per component.
> 
> It may, and in fact is most likely to, be used in situations where
> there are less than 16 bits of data. It is the responsibility of
> the writer to zero out any unused LSBs.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavutil/pixdesc.c | 24 
>  libavutil/pixfmt.h  |  4 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index f8092ef..3b9c45d 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2078,6 +2078,30 @@ static const AVPixFmtDescriptor 
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
>  },
>  .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
>  },
> +[AV_PIX_FMT_P016LE] = {
> +.name = "p016le",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 1,
> +.comp = {
> +{ 0, 2, 0, 0, 16, 1, 15, 1 },   /* Y */
> +{ 1, 4, 0, 0, 16, 3, 15, 1 },   /* U */
> +{ 1, 4, 2, 0, 16, 3, 15, 3 },   /* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_PLANAR,
> +},
> +[AV_PIX_FMT_P016BE] = {
> +.name = "p016be",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 1,
> +.comp = {
> +{ 0, 2, 0, 0, 16, 1, 15, 1 },   /* Y */
> +{ 1, 4, 0, 0, 16, 3, 15, 1 },   /* U */
> +{ 1, 4, 2, 0, 16, 3, 15, 3 },   /* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
> +},
>  [AV_PIX_FMT_GBRAP12LE] = {
>  .name = "gbrap12le",
>  .nb_components = 4,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 96860ce..dfb1b11 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -311,6 +311,9 @@ enum AVPixelFormat {
>  AV_PIX_FMT_GRAY10BE,   ///  AV_PIX_FMT_GRAY10LE,   ///  
> +AV_PIX_FMT_P016LE, ///< like NV12, with 16bpp per component, 
> little-endian
> +AV_PIX_FMT_P016BE, ///< like NV12, with 16bpp per component, big-endian
> +
>  AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if 
> you want to link with shared libav* because the number of formats might 
> differ between versions
>  };
>  
> @@ -389,6 +392,7 @@ enum AVPixelFormat {
>  #define AV_PIX_FMT_NV20   AV_PIX_FMT_NE(NV20BE,  NV20LE)
>  #define AV_PIX_FMT_AYUV64 AV_PIX_FMT_NE(AYUV64BE, AYUV64LE)
>  #define AV_PIX_FMT_P010   AV_PIX_FMT_NE(P010BE,  P010LE)
> +#define AV_PIX_FMT_P016   AV_PIX_FMT_NE(P016BE,  P016LE)
>  
>  /**
>* Chromaticity coordinates of the source primaries.

Probably fine, though these pixdesc fields are all kinds of tricky. You
changed shift from 6 to 0 and depth from 10 to 16, which looks right.

Probably lacks a libavutil minor bump or so.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage

[wm4]

On Mon, 21 Nov 2016 16:18:58 +0100
Michael Niedermayer  wrote:

> With this it is possible to prevent OOM with untrusted media
> 
> As this fundamentally requires keeping track of allocated memory sizes
> and the memalign hack code does nearly exactly that already, this feature
> depends on it being enabled.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/mem.c | 45 -
>  libavutil/mem.h | 17 +
>  2 files changed, 61 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 6273d89..6ee07b7 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -37,6 +37,7 @@
>  #endif
>  
>  #include "avassert.h"
> +#include "atomic.h"
>  #include "avutil.h"
>  #include "common.h"
>  #include "dynarray.h"
> @@ -69,11 +70,39 @@ void  free(void *ptr);
>   * Note that this will cost performance. */
>  
>  static size_t max_alloc_size= INT_MAX;
> +static int64_t max_heap_size= 0;
> +static volatile int64_t heap_size = 0;
>  
>  void av_max_alloc(size_t max){
>  max_alloc_size = max;
>  }
>  
> +int av_max_heap(uint64_t max)
> +{
> +#if CONFIG_MEMALIGN_HACK
> +max_heap_size = max;
> +return 0;
> +#else
> +return AVERROR(ENOSYS);
> +#endif
> +}
> +
> +static int heap_change(int64_t size, int force)
> +{
> +int64_t oldval, newval;
> +if (!max_heap_size)
> +return 0;
> +
> +do {
> +oldval = heap_size;
> +if (!force && max_heap_size - oldval < size)
> +return AVERROR(ENOMEM);
> +newval = oldval + size;
> +} while (oldval != avpriv_atomic_int64_cas(&heap_size, oldval, newval));
> +
> +return 0;
> +}
> +
>  void *av_malloc(size_t size)
>  {
>  void *ptr = NULL;
> @@ -86,9 +115,15 @@ void *av_malloc(size_t size)
>  return NULL;
>  
>  #if CONFIG_MEMALIGN_HACK
> +
> +if (heap_change(size + ALIGN + 8, 0) < 0)
> +return NULL;
> +
>  ptr = malloc(size + ALIGN + 8);
> -if (!ptr)
> +if (!ptr) {
> +heap_change(-((int64_t)size + ALIGN + 8), 1);
>  return ptr;
> +}
>  
>  diff = uintptr_t)ptr) + 9 + ALIGN - 1) & ~(ALIGN - 1)) - 
> (uintptr_t)ptr;
>  av_assert0(diff>0 && diff<=ALIGN + 8);  
> @@ -164,9 +199,15 @@ void *av_realloc(void *ptr, size_t size)
>  
>  // Quick path for apparently and likly aligned realloc()
>  if (diff == ALIGN) {
> +int64_t size_delta = size - ((int64_t *)ptr)[-1];
> +if (heap_change(size_delta, 0) < 0)
> +return NULL;
> +
>  ptr = realloc((char *)ptr - diff, size + diff);
>  if (ptr)
>  ptr = (char *)ptr + diff;
> +else
> +heap_change(-size_delta, 1);
>  if (!(((uintptr_t)ptr) & (ALIGN - 1))) {
>  if (ptr)
>  ((int64_t *)ptr)[-1] = size;
> @@ -250,8 +291,10 @@ void av_free(void *ptr)
>  #if CONFIG_MEMALIGN_HACK
>  if (ptr) {
>  int v= ((char *)ptr)[-9];
> +int64_t size = ((int64_t *)ptr)[-1];
>  av_assert0(v>0 && v<=ALIGN + 8);  
>  free((char *)ptr - v);
> +heap_change(-size, 1);
>  }
>  #elif HAVE_ALIGNED_MALLOC
>  _aligned_free(ptr);
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index f9d8884..9cce433 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
> @@ -689,6 +689,23 @@ static inline int av_size_mult(size_t a, size_t b, 
> size_t *r)
>  void av_max_alloc(size_t max);
>  
>  /**
> + * Set the maximum heap size that may be allocated.
> + *
> + * The value specified with this function is effective for all libavutil's 
> @ref
> + * lavu_mem_funcs "heap management functions."
> + *
> + * By default, there is no limit.
> + * If this is set lower than the currently allocated space then behavior is
> + * undefined.
> + * Allocations prior to this being set are potentially not kept track of.
> + *
> + * @param max Value to be set as the new maximum size
> + *
> + * @return >= 0 or a negative error code in case of failure
> + */
> +int av_max_heap(uint64_t max);
> +
> +/**
>   * @}
>   * @}
>   */

"No."

Not another questionable global state thing please.

This isn't any better than ulimit anyway.

Besides, using this in practice would only trigger tons of malloc
failure handling bugs, so practical uses would probably involve
tearing down the whole process.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avutil/atomic: Add avpriv_atomic_int64_cas()

[James Almer]

On 11/21/2016 12:18 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/atomic.c | 20 
>  libavutil/atomic.h | 10 ++
>  libavutil/atomic_gcc.h | 12 
>  3 files changed, 42 insertions(+)
> 
> diff --git a/libavutil/atomic.c b/libavutil/atomic.c
> index 64cff25..27561ad 100644
> --- a/libavutil/atomic.c
> +++ b/libavutil/atomic.c
> @@ -70,6 +70,17 @@ void *avpriv_atomic_ptr_cas(void * volatile *ptr, void 
> *oldval, void *newval)
>  return ret;
>  }
>  
> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, 
> int64_t newval)

There's a bunch of libav commits in queue to replace the entire custom atomic
API and use instead the standard C11 API.
The C11 functions are generic and are defined for all atomic types regardless
of size, so this commit and its new private-but-exported symbol can be avoided.

Since said commits are a bit far away in the queue, we could cherry pick them
now and noop them later.
They are 13f5d2b (C11 stdatomics.h configure check), 4e928ef, c275586, bb81ed4,
f9a6a80, eb34d40 (fallback implementations for non-C11 compilers), followed by
a bunch of commits replacing the current usage of the custom API with the C11
one.
A last commit removes the current API altogether, but i don't think we can do
that until a major bump takes place.


> +{
> +int64_t ret;
> +pthread_mutex_lock(&atomic_lock);
> +ret = *ptr;
> +if (ret == oldval)
> +*ptr = newval;
> +pthread_mutex_unlock(&atomic_lock);
> +return ret;
> +}
> +
>  #elif !HAVE_THREADS
>  
>  int avpriv_atomic_int_get(volatile int *ptr)
> @@ -97,6 +108,15 @@ void *avpriv_atomic_ptr_cas(void * volatile *ptr, void 
> *oldval, void *newval)
>  return *ptr;
>  }
>  
> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, 
> int64_t newval)
> +{
> +if (*ptr == oldval) {
> +*ptr = newval;
> +return oldval;
> +}
> +return *ptr;
> +}
> +
>  #else /* HAVE_THREADS */
>  
>  /* This should never trigger, unless a new threading implementation
> diff --git a/libavutil/atomic.h b/libavutil/atomic.h
> index 15906d2..cabc4f0 100644
> --- a/libavutil/atomic.h
> +++ b/libavutil/atomic.h
> @@ -74,6 +74,16 @@ int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int 
> inc);
>   */
>  void *avpriv_atomic_ptr_cas(void * volatile *ptr, void *oldval, void 
> *newval);
>  
> +/**
> + * Atomic int64_t compare and swap.
> + *
> + * @param ptr pointer to the int64_t to operate on
> + * @param oldval do the swap if the current value of *ptr equals to oldval
> + * @param newval value to replace *ptr with
> + * @return the value of *ptr before comparison
> + */
> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, 
> int64_t newval);
> +
>  #endif /* HAVE_ATOMICS_NATIVE */
>  
>  #endif /* AVUTIL_ATOMIC_H */
> diff --git a/libavutil/atomic_gcc.h b/libavutil/atomic_gcc.h
> index 5f9fc49..c7e0dba 100644
> --- a/libavutil/atomic_gcc.h
> +++ b/libavutil/atomic_gcc.h
> @@ -75,4 +75,16 @@ static inline void *atomic_ptr_cas_gcc(void * volatile 
> *ptr,
>  #endif
>  }
>  
> +#define avpriv_atomic_int64_cas atomic_int64_cas_gcc
> +static inline int64_t atomic_int64_cas_gcc(int64_t volatile *ptr,
> +   int64_t oldval, int64_t newval)
> +{
> +#if HAVE_SYNC_VAL_COMPARE_AND_SWAP
> +return __sync_val_compare_and_swap(ptr, oldval, newval);
> +#else
> +__atomic_compare_exchange_n(ptr, &oldval, newval, 0, __ATOMIC_SEQ_CST, 
> __ATOMIC_SEQ_CST);
> +return oldval;
> +#endif
> +}
> +
>  #endif /* AVUTIL_ATOMIC_GCC_H */
> 

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Nicolas George]

Le primidi 1er frimaire, an CCXXV, wm4 a écrit :
> I do not understand this. Please explain why requesting features is
> against policy or not useful.

Please stop your passive-aggressive flame bait.


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

Re: [FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage

[Nicolas George]

Le primidi 1er frimaire, an CCXXV, Michael Niedermayer a écrit :
> With this it is possible to prevent OOM with untrusted media
> 
> As this fundamentally requires keeping track of allocated memory sizes
> and the memalign hack code does nearly exactly that already, this feature
> depends on it being enabled.
> 
> Signed-off-by: Michael Niedermayer 

Please no.

It feels completely broken. It will not track memory allocated by
external libraries, it adds global state, it makes all allocations more
complex, it does not take the overhead of allocations into account, etc.

Linux has setrlimit(), I am quite sure other OSes have similar features.
Let applications use them.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[wm4]

On Mon, 21 Nov 2016 09:58:33 -0500
"Gregory J. Wolfe"  wrote:

> (1) Multi-threading support requires knowing the number of CPUs available.
> When building with MinGW on a Windows system, both gcc and Windows run
> time functions are available to get this information.  However, when Windows
> threading has been selected, the Windows function should be used, not the
> gcc function.  This avoids creating an unnecessary dependency on the gcc
> thread library.
> 
> (2) When ALL threading support is disabled, the build should not create a
> dependency on ANY thread library.
> 
> Signed-off-by: Gregory J. Wolfe 
> ---
>  libavutil/cpu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index f5785fc..3843778 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
> @@ -258,10 +258,15 @@ int av_cpu_count(void)
>  static volatile int printed;
>  
>  int nb_cpus = 1;
> +#if HAVE_THREADS
>  #if HAVE_WINRT
>  SYSTEM_INFO sysinfo;
>  #endif
> -#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
> +// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK, we will use
> +// Windows GetProcessAffinityMask() instead of gcc library function
> +// sched_getaffinity().  This avoids creating a dependency on the gcc
> +// thread library that we don't need/want.
> +#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) && !(HAVE_W32THREADS && 
> HAVE_GETPROCESSAFFINITYMASK)
>  cpu_set_t cpuset;
>  
>  CPU_ZERO(&cpuset);
> @@ -286,6 +291,7 @@ int av_cpu_count(void)
>  GetNativeSystemInfo(&sysinfo);
>  nb_cpus = sysinfo.dwNumberOfProcessors;
>  #endif
> +#endif
>  
>  if (!printed) {
>  av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);

Wouldn't it be better to move the HAVE_GETPROCESSAFFINITYMASK case
above HAVE_SCHED_GETAFFINITY, and avoid making the ifdeffery mess
worse? GetProcessAffinityMask is available on every supported Windows
and could as well be replaced by "ifdef _WIN32" instead.

Also, technically you might have to stop the configure script to stop
linking to libpthread. I'm not sure what exactly stops it from doing
that in your case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Gregory J Wolfe]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of wm4
> Sent: Monday, November 21, 2016 10:05 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
> dependencies on thread libraries.
> 
> On Mon, 21 Nov 2016 09:58:33 -0500
> "Gregory J. Wolfe"  wrote:
> 
> > (1) Multi-threading support requires knowing the number of CPUs
> available.
> > When building with MinGW on a Windows system, both gcc and
> Windows run
> > time functions are available to get this information.  However, when
> Windows
> > threading has been selected, the Windows function should be used,
> not the
> > gcc function.  This avoids creating an unnecessary dependency on
> the gcc
> > thread library.
> >
> > (2) When ALL threading support is disabled, the build should not
> create a
> > dependency on ANY thread library.
> >
> > Signed-off-by: Gregory J. Wolfe 
> > ---
> >  libavutil/cpu.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> > index f5785fc..3843778 100644
> > --- a/libavutil/cpu.c
> > +++ b/libavutil/cpu.c
> > @@ -258,10 +258,15 @@ int av_cpu_count(void)
> >  static volatile int printed;
> >
> >  int nb_cpus = 1;
> > +#if HAVE_THREADS
> >  #if HAVE_WINRT
> >  SYSTEM_INFO sysinfo;
> >  #endif
> > -#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
> > +// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK,
> we will use
> > +// Windows GetProcessAffinityMask() instead of gcc library
> function
> > +// sched_getaffinity().  This avoids creating a dependency on the
> gcc
> > +// thread library that we don't need/want.
> > +#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) &&
> !(HAVE_W32THREADS && HAVE_GETPROCESSAFFINITYMASK)
> >  cpu_set_t cpuset;
> >
> >  CPU_ZERO(&cpuset);
> > @@ -286,6 +291,7 @@ int av_cpu_count(void)
> >  GetNativeSystemInfo(&sysinfo);
> >  nb_cpus = sysinfo.dwNumberOfProcessors;
> >  #endif
> > +#endif
> >
> >  if (!printed) {
> >  av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n",
> nb_cpus);
> 
> Wouldn't it be better to move the HAVE_GETPROCESSAFFINITYMASK
> case
> above HAVE_SCHED_GETAFFINITY, and avoid making the ifdeffery
> mess
> worse? GetProcessAffinityMask is available on every supported
> Windows
> and could as well be replaced by "ifdef _WIN32" instead.
> 

Yeah, I had the same thought.  For the first go around I opted for the
solution that moved around the least code, not knowing for sure if
I might cause some undesirable side effects by reordering the existing
code.  I can easily redo the patch if we're in agreement on this point.

> Also, technically you might have to stop the configure script to stop
> linking to libpthread. I'm not sure what exactly stops it from doing
> that in your case.
 
The result I observed was that the resulting avutil.dll did NOT have
a dependency on the gcc run time.  My interpretation of this is that
if you link against a library, but don't reference any symbols in it, then
it's as if you never linked against it in the first place.

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

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[wm4]

On Mon, 21 Nov 2016 16:23:03 +
Gregory J Wolfe  wrote:

> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf Of wm4
> > Sent: Monday, November 21, 2016 10:05 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
> > dependencies on thread libraries.
> > 
> > On Mon, 21 Nov 2016 09:58:33 -0500
> > "Gregory J. Wolfe"  wrote:
> >   
> > > (1) Multi-threading support requires knowing the number of CPUs  
> > available.  
> > > When building with MinGW on a Windows system, both gcc and  
> > Windows run  
> > > time functions are available to get this information.  However, when  
> > Windows  
> > > threading has been selected, the Windows function should be used,  
> > not the  
> > > gcc function.  This avoids creating an unnecessary dependency on  
> > the gcc  
> > > thread library.
> > >
> > > (2) When ALL threading support is disabled, the build should not  
> > create a  
> > > dependency on ANY thread library.
> > >
> > > Signed-off-by: Gregory J. Wolfe 
> > > ---
> > >  libavutil/cpu.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> > > index f5785fc..3843778 100644
> > > --- a/libavutil/cpu.c
> > > +++ b/libavutil/cpu.c
> > > @@ -258,10 +258,15 @@ int av_cpu_count(void)
> > >  static volatile int printed;
> > >
> > >  int nb_cpus = 1;
> > > +#if HAVE_THREADS
> > >  #if HAVE_WINRT
> > >  SYSTEM_INFO sysinfo;
> > >  #endif
> > > -#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
> > > +// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK,  
> > we will use  
> > > +// Windows GetProcessAffinityMask() instead of gcc library  
> > function  
> > > +// sched_getaffinity().  This avoids creating a dependency on the  
> > gcc  
> > > +// thread library that we don't need/want.
> > > +#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) &&  
> > !(HAVE_W32THREADS && HAVE_GETPROCESSAFFINITYMASK)  
> > >  cpu_set_t cpuset;
> > >
> > >  CPU_ZERO(&cpuset);
> > > @@ -286,6 +291,7 @@ int av_cpu_count(void)
> > >  GetNativeSystemInfo(&sysinfo);
> > >  nb_cpus = sysinfo.dwNumberOfProcessors;
> > >  #endif
> > > +#endif
> > >
> > >  if (!printed) {
> > >  av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n",  
> > nb_cpus);
> > 
> > Wouldn't it be better to move the HAVE_GETPROCESSAFFINITYMASK
> > case
> > above HAVE_SCHED_GETAFFINITY, and avoid making the ifdeffery
> > mess
> > worse? GetProcessAffinityMask is available on every supported
> > Windows
> > and could as well be replaced by "ifdef _WIN32" instead.
> >   
> 
> Yeah, I had the same thought.  For the first go around I opted for the
> solution that moved around the least code, not knowing for sure if
> I might cause some undesirable side effects by reordering the existing
> code.  I can easily redo the patch if we're in agreement on this point.

Depends if there are any cargo cult people who are against it.

> > Also, technically you might have to stop the configure script to stop
> > linking to libpthread. I'm not sure what exactly stops it from doing
> > that in your case.  
>  
> The result I observed was that the resulting avutil.dll did NOT have
> a dependency on the gcc run time.  My interpretation of this is that
> if you link against a library, but don't reference any symbols in it, then
> it's as if you never linked against it in the first place.

This could still be caused by certain link flag (forgot which one). In
general, linking against a dynamic library without using any of its
functions, could still have side effects, such as registering plugins
in the DLL init functions and such.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Hendrik Leppkes]

On Mon, Nov 21, 2016 at 5:23 PM, Gregory J Wolfe
 wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf Of wm4
>> Sent: Monday, November 21, 2016 10:05 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
>> dependencies on thread libraries.
>>
>> On Mon, 21 Nov 2016 09:58:33 -0500
>> "Gregory J. Wolfe"  wrote:
>>
>> > (1) Multi-threading support requires knowing the number of CPUs
>> available.
>> > When building with MinGW on a Windows system, both gcc and
>> Windows run
>> > time functions are available to get this information.  However, when
>> Windows
>> > threading has been selected, the Windows function should be used,
>> not the
>> > gcc function.  This avoids creating an unnecessary dependency on
>> the gcc
>> > thread library.
>> >
>> > (2) When ALL threading support is disabled, the build should not
>> create a
>> > dependency on ANY thread library.
>> >
>> > Signed-off-by: Gregory J. Wolfe 
>> > ---
>> >  libavutil/cpu.c | 8 +++-
>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> > index f5785fc..3843778 100644
>> > --- a/libavutil/cpu.c
>> > +++ b/libavutil/cpu.c
>> > @@ -258,10 +258,15 @@ int av_cpu_count(void)
>> >  static volatile int printed;
>> >
>> >  int nb_cpus = 1;
>> > +#if HAVE_THREADS
>> >  #if HAVE_WINRT
>> >  SYSTEM_INFO sysinfo;
>> >  #endif
>> > -#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
>> > +// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK,
>> we will use
>> > +// Windows GetProcessAffinityMask() instead of gcc library
>> function
>> > +// sched_getaffinity().  This avoids creating a dependency on the
>> gcc
>> > +// thread library that we don't need/want.
>> > +#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) &&
>> !(HAVE_W32THREADS && HAVE_GETPROCESSAFFINITYMASK)
>> >  cpu_set_t cpuset;
>> >
>> >  CPU_ZERO(&cpuset);
>> > @@ -286,6 +291,7 @@ int av_cpu_count(void)
>> >  GetNativeSystemInfo(&sysinfo);
>> >  nb_cpus = sysinfo.dwNumberOfProcessors;
>> >  #endif
>> > +#endif
>> >
>> >  if (!printed) {
>> >  av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n",
>> nb_cpus);
>>
>> Wouldn't it be better to move the HAVE_GETPROCESSAFFINITYMASK
>> case
>> above HAVE_SCHED_GETAFFINITY, and avoid making the ifdeffery
>> mess
>> worse? GetProcessAffinityMask is available on every supported
>> Windows
>> and could as well be replaced by "ifdef _WIN32" instead.
>>
>
> Yeah, I had the same thought.  For the first go around I opted for the
> solution that moved around the least code, not knowing for sure if
> I might cause some undesirable side effects by reordering the existing
> code.  I can easily redo the patch if we're in agreement on this point.
>

Moving the code to prefer the win32 functions if available is
definitely preferable to further complicating the ifdefs to not only
check for features but also doing negative checks on other features.
The preferred option should just be on top - which in this case is the
OS-native function over the pthread functions, which are always some
sort of emulation layer ontop of the win32 functions anyway.

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself as an API tests maintainer

[Michael Niedermayer]

On Mon, Aug 24, 2015 at 03:37:42AM +0300, Ludmila Glinskih wrote:
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

patch applied

this seems to have been forgotten

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

[FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed

[Michael Niedermayer]

I omitted developers who do not use their account and i felt would prefer not
to be listed.
I think everyone using their account should be listed if we list anyone

Signed-off-by: Michael Niedermayer 
---
 MAINTAINERS | 25 +
 1 file changed, 25 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ffed64f..e80cd23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -525,6 +525,31 @@ Sparc   Roman Shaposhnik
 OS/2KO Myung-Hun
 
 
+Developers with git write access who are currently not maintaining any 
specific part
+
+Alex Converse
+Andreas Cadhalpun
+Anuradha Suraparaju
+Ben Littler
+Benjamin Larsson
+Bobby Bingham
+Daniel Verkamp
+Derek Buitenhuis
+Ganesh Ajjanagadde
+Henrik Gramner
+Ivan Uskov
+James Darnley
+Joakim Plate
+Kieran Kunhya
+Kirill Gavrilov
+Martin Storsjö
+Panagiotis Issaris
+Pedro Arthur
+Sebastien Zwickert
+wm4
+(this list is incomplete)
+
+
 Releases
 
 
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil/mem: Fix *realloc() alignment with memalign hack

[Michael Niedermayer]

On Mon, Nov 21, 2016 at 04:34:54PM +0100, wm4 wrote:
> On Mon, 21 Nov 2016 16:18:56 +0100
> Michael Niedermayer  wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/mem.c | 44 
> >  1 file changed, 32 insertions(+), 12 deletions(-)
> > 
> 
> "Fix" is not a good description. Was it broken? What was broken?
> 

well
there was a "FIXME" in there about the realloc alignment
and as the heap limit i wanted to implement needed very similar changes
i fixed that. I did remember that at some point in the past we wanted to
have this codepath align correctly.

Maybe the comment mislead me
still, this code could come in handy for debuging and tracing things
as it allows debug code to access the allocated size of heap
allocations easily
also as its already written, someone might want to check if it has any
speed effect to have misaligned output from realloc()


> Also, I thought the memalign hack was generally not needed anymore.
> Which platforms still need it?

i dont know, iam not a user of an affected platform

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] CUVID: Allow to set number of used surfaces for decoding (resend)

[Miroslav Slugeň]

Thanks, sending corrected version.

just changed OFFSET(surfaces) to OFFSET(nb_surfaces)

Miroslav Slugeň

Dne 21.11.2016 v 13:29 Timo Rothenpieler napsal(a):

Does not compile:

libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
  #define OFFSET(x) offsetof(CuvidContext, x)


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



>From 30ddf173c87a9da16ba4725f8beea67d8fa6f537 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Mon, 21 Nov 2016 10:51:25 +0100
Subject: [PATCH] CUVID: Allow to set number of used surfaces for decoding

---
 libavcodec/cuvid.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index eafce0a..fbe32fb 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -32,8 +32,6 @@
 
 #include "compat/cuda/nvcuvid.h"
 
-#define MAX_FRAME_COUNT 25
-
 typedef struct CuvidContext
 {
 AVClass *avclass;
@@ -42,6 +40,7 @@ typedef struct CuvidContext
 CUvideoparser cuparser;
 
 char *cu_gpu;
+int nb_surfaces;
 
 AVBufferRef *hwdevice;
 AVBufferRef *hwframe;
@@ -185,7 +184,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = format->bit_depth_luma_minus8;
@@ -268,7 +267,7 @@ static int cuvid_decode_packet(AVCodecContext *avctx, const AVPacket *avpkt)
 if (is_flush && avpkt && avpkt->size)
 return AVERROR_EOF;
 
-if (av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame) > MAX_FRAME_COUNT - 2 && avpkt && avpkt->size)
+if ((av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame)) + 2 > ctx->nb_surfaces && avpkt && avpkt->size)
 return AVERROR(EAGAIN);
 
 if (ctx->bsf && avpkt && avpkt->size) {
@@ -576,7 +575,7 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS *cu
 cuinfo.target_rect.right = cuinfo.ulWidth;
 cuinfo.target_rect.bottom = cuinfo.ulHeight;
 
-cuinfo.ulNumDecodeSurfaces = MAX_FRAME_COUNT;
+cuinfo.ulNumDecodeSurfaces = ctx->nb_surfaces;
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = 0;
@@ -616,7 +615,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
 return ret;
 }
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 ret = AVERROR(ENOMEM);
 goto error;
@@ -743,7 +742,7 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
FFMIN(sizeof(ctx->cuparse_ext.raw_seqhdr_data), avctx->extradata_size));
 }
 
-ctx->cuparseinfo.ulMaxNumDecodeSurfaces = MAX_FRAME_COUNT;
+ctx->cuparseinfo.ulMaxNumDecodeSurfaces = ctx->nb_surfaces;
 ctx->cuparseinfo.ulMaxDisplayDelay = 4;
 ctx->cuparseinfo.pUserData = avctx;
 ctx->cuparseinfo.pfnSequenceCallback = cuvid_handle_video_sequence;
@@ -802,7 +801,7 @@ static void cuvid_flush(AVCodecContext *avctx)
 
 av_fifo_freep(&ctx->frame_queue);
 
-ctx->frame_queue = av_fifo_alloc(MAX_FRAME_COUNT * sizeof(CuvidParsedFrame));
+ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
 if (!ctx->frame_queue) {
 av_log(avctx, AV_LOG_ERROR, "Failed to recreate frame queue on flush\n");
 return;
@@ -851,6 +850,7 @@ static const AVOption options[] = {
 { "bob",  "Bob deinterlacing",   0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Bob  }, 0, 0, VD, "deint" },
 { "adaptive", "Adaptive deinterlacing",  0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
 { "gpu",  "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
+{ "surfaces", "Maximum surfaces to be used for decoding", OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
 { NULL }
 };
 
-- 
2.1.4


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

[FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Gregory J. Wolfe]

(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both Windows and gcc run
time functions are available to get this information.  If available,
the Windows function should be used, not the gcc function.  This avoids
creating an unnecessary dependency on the gcc thread library.

(2) When ALL threading support is disabled, the build should not create a
dependency on ANY thread library.

Signed-off-by: Gregory J. Wolfe 
---
 libavutil/cpu.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index f5785fc..a55921a 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -258,20 +258,25 @@ int av_cpu_count(void)
 static volatile int printed;
 
 int nb_cpus = 1;
+#if HAVE_THREADS
 #if HAVE_WINRT
 SYSTEM_INFO sysinfo;
 #endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_GETPROCESSAFFINITYMASK, we will use Windows
+// GetProcessAffinityMask() over gcc library function
+// sched_getaffinity().  This avoids creating a dependency
+// on the gcc thread library that we don't need/want.
+#if HAVE_GETPROCESSAFFINITYMASK
+DWORD_PTR proc_aff, sys_aff;
+if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
+nb_cpus = av_popcount64(proc_aff);
+#elif HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
 cpu_set_t cpuset;
 
 CPU_ZERO(&cpuset);
 
 if (!sched_getaffinity(0, sizeof(cpuset), &cpuset))
 nb_cpus = CPU_COUNT(&cpuset);
-#elif HAVE_GETPROCESSAFFINITYMASK
-DWORD_PTR proc_aff, sys_aff;
-if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
-nb_cpus = av_popcount64(proc_aff);
 #elif HAVE_SYSCTL && defined(HW_NCPU)
 int mib[2] = { CTL_HW, HW_NCPU };
 size_t len = sizeof(nb_cpus);
@@ -286,6 +291,7 @@ int av_cpu_count(void)
 GetNativeSystemInfo(&sysinfo);
 nb_cpus = sysinfo.dwNumberOfProcessors;
 #endif
+#endif
 
 if (!printed) {
 av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
-- 
2.5.1.windows.1

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

Re: [FFmpeg-devel] [PATCH 1/2] Add experimental muxing support for FLAC in ISO BMFF (MP4).

[James Almer]

On 11/18/2016 12:25 AM, Matthew Gregan wrote:
> At 2016-11-17T22:57:49-0300, James Almer wrote:
>>> > > @@ -345,6 +346,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
>>> > > +{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /* 
>>> > > nonstandard */
>> > 
>> > This is enables muxing into mov, which bypasses the experimental check 
>> > below
>> > since mov isn't MODE_MP4.
> Thanks.  Updated the check to reject non-MP4 as invalid before checking the
> experimental flag.  I based the original check on the VP9/MP4 muxing, which
> has the same bug, should I send a patch to restrict that to MP4 too?
> 
> Updated patch attached.
> 
> 
> 0001-Add-experimental-muxing-support-for-FLAC-in-ISO-BMFF.patch
> 
> 
> From 6309c0c60835a843a846915c7534a61786291ad3 Mon Sep 17 00:00:00 2001
> From: Matthew Gregan 
> Date: Thu, 20 Oct 2016 17:28:11 +1300
> Subject: Add experimental muxing support for FLAC in ISO BMFF (MP4).
> 
> Based on the draft spec at 
> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
> 
> '-strict -2' is required to create files in this format.

Seeing the maintainer hasn't replied, i have pushed it. Seems to adhere to
the (draft) spec correctly, and is under an experimental strict check.

I tried creating some FLAC only files and they play fine on Firefox 51 b1,
which is the first version with FLAC support. However an h264+flac file
gave me audio only and no video. Do you know if it's a bug that should be
reported to Mozilla, or just expected behavior as they only mention support
for h264+aac and no other specific AV combination?

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

Re: [FFmpeg-devel] [PATCH 2/2] Add experimental demuxing support for FLAC in ISO BMFF (MP4).

[James Almer]

On 11/1/2016 8:23 PM, Matthew Gregan wrote:
> At 2016-11-01T18:07:07-0300, James Almer wrote:
>> > Just include libavcodec/flac.h which already defines it.
>> > 
>> > With the above header you'll also be able to use the inline function
>> > flac_parse_block_header() for this. See flac and matroska demuxers.
>> > 
>> > INVALIDDATA errors would ideally also throw an error message.
>> > 
>> > Use ff_get_extradata(), which combines these two into a single function.
> Thanks for the feedback.  Updated patch attached with these addressed.
> 
> 
> 0002-Add-experimental-demuxing-support-for-FLAC-in-ISO-BM.patch
> 
> 
> From 7f08d03c7c73105098e3c398f10e5127b17eb368 Mon Sep 17 00:00:00 2001
> From: Matthew Gregan 
> Date: Fri, 21 Oct 2016 16:10:43 +1300
> Subject: [PATCH 2/2] Add experimental demuxing support for FLAC in ISO BMFF
>  (MP4).
> 
> Based on the draft spec at 
> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
> 
> Signed-off-by: Matthew Gregan 
> ---
>  libavformat/mov.c | 39 +++
>  1 file changed, 39 insertions(+)

Pushed, thanks!

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

Re: [FFmpeg-devel] [PATCH] Restrict experimental VP9 support to MODE_MP4.

[James Almer]

On 11/18/2016 12:35 AM, Matthew Gregan wrote:
> Without this, it's possible to mux VP9 into MOV without passing -strict -2.
> This tightens the check to restrict VP9 to MODE_MP4 only.
> 
> Based on the discussion with James Almer on the experimental FLAC in MP4
> muxing patch.
> 
> 
> 0001-Restrict-experimental-VP9-support-to-MODE_MP4.patch
> 
> 
> From 47f74ca9269d2bddccd9d273d6739798f9bfd0b7 Mon Sep 17 00:00:00 2001
> From: Matthew Gregan 
> Date: Fri, 18 Nov 2016 16:29:42 +1300
> Subject: [PATCH] Restrict experimental VP9 support to MODE_MP4.
> 
> Signed-off-by: Matthew Gregan 
> ---
>  libavformat/movenc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 

Pushed, thanks.

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Martin Vignali]

Hello,

New patchs in attach.
Correction have been made followings comments from Andreas and Carl.

@Rotislav : thanks for your answer.

Martin
From d923d4e8031fae4fa87cab39b431d055d2744ffe Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 21 Nov 2016 21:39:07 +0100
Subject: [PATCH 1/2] libavcodec : add decoder for Photoshop PSD image files

Decode the Image Data Section (which contains merged pictures).
Support RGB/A and Grayscale/A in 8bits and 16 bits per channel.
Support uncompress and rle decompression in Image Data Section.
---
 Changelog   |   1 +
 doc/general.texi|   2 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/psd.c| 429 
 libavcodec/version.h|   4 +-
 8 files changed, 444 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/psd.c

diff --git a/Changelog b/Changelog
index 8456022..bdad732 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
 - CrystalHD decoder moved to new decode API
 - add internal ebur128 library, remove external libebur128 dependency
 - Pro-MPEG CoP #3-R2 FEC protocol
+- PSD Decoder
 
 version 3.2:
 - libopenmpt demuxer
diff --git a/doc/general.texi b/doc/general.texi
index 56b9e4d..9ea3ba3 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -584,6 +584,8 @@ following image formats are supported:
 @item PNG  @tab X @tab X
 @item PPM  @tab X @tab X
 @tab Portable PixelMap image
+@item PSD  @tab   @tab X
+@tab Photoshop
 @item PTX  @tab   @tab X
 @tab V.Flash PTX format
 @item SGI  @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 82f7fa2..343329e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -462,6 +462,7 @@ OBJS-$(CONFIG_PRORES_LGPL_DECODER) += proresdec_lgpl.o proresdsp.o proresdat
 OBJS-$(CONFIG_PRORES_ENCODER)  += proresenc_anatoliy.o
 OBJS-$(CONFIG_PRORES_AW_ENCODER)   += proresenc_anatoliy.o
 OBJS-$(CONFIG_PRORES_KS_ENCODER)   += proresenc_kostya.o proresdata.o
+OBJS-$(CONFIG_PSD_DECODER) += psd.o
 OBJS-$(CONFIG_PTX_DECODER) += ptx.o
 OBJS-$(CONFIG_QCELP_DECODER)   += qcelpdec.o \
   celp_filters.o acelp_vectors.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ada9481..bbcecce 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -287,6 +287,7 @@ void avcodec_register_all(void)
 REGISTER_ENCODER(PRORES_AW, prores_aw);
 REGISTER_ENCODER(PRORES_KS, prores_ks);
 REGISTER_DECODER(PRORES_LGPL,   prores_lgpl);
+REGISTER_DECODER(PSD,   psd);
 REGISTER_DECODER(PTX,   ptx);
 REGISTER_DECODER(QDRAW, qdraw);
 REGISTER_DECODER(QPEG,  qpeg);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e5e7f42..538e701 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -411,6 +411,7 @@ enum AVCodecID {
 AV_CODEC_ID_MAGICYUV,
 AV_CODEC_ID_SHEERVIDEO,
 AV_CODEC_ID_YLC,
+AV_CODEC_ID_PSD,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9dbe2dc..29ffcb9 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1461,6 +1461,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 },
 {
+.id= AV_CODEC_ID_PSD,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "psd",
+.long_name = NULL_IF_CONFIG_SMALL("Photoshop PSD file"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
 .id= AV_CODEC_ID_PTX,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "ptx",
diff --git a/libavcodec/psd.c b/libavcodec/psd.c
new file mode 100644
index 000..e026845
--- /dev/null
+++ b/libavcodec/psd.c
@@ -0,0 +1,429 @@
+/*
+ * Photoshop (PSD) image decoder
+ * Copyright (c) 2016 Jokyo Images
+ *
+ * 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., 

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Rostislav Pehlivanov]

On 21 November 2016 at 20:44, Martin Vignali 
wrote:

> Hello,
>
> New patchs in attach.
> Correction have been made followings comments from Andreas and Carl.
>
> @Rotislav : thanks for your answer.
>
> Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I don't think you need the checks, it was pointed out that
ff_set_dimensions already does that.
Also IIRC lavc doesn't support widths or heights over 16384 anyway.

>unsigned int pixel_size
Please use uint32_t instead of unsigned ints throughout the patches.. I'm
paranoid about unspecified sizes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Ronald S. Bultje]

Hi,

On Mon, Nov 21, 2016 at 4:40 PM, Rostislav Pehlivanov 
wrote:

> On 21 November 2016 at 20:44, Martin Vignali 
> wrote:
>
> > Hello,
> >
> > New patchs in attach.
> > Correction have been made followings comments from Andreas and Carl.
> >
> > @Rotislav : thanks for your answer.
> >
> > Martin
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> I don't think you need the checks, it was pointed out that
> ff_set_dimensions already does that.
> Also IIRC lavc doesn't support widths or heights over 16384 anyway.
>
> >unsigned int pixel_size
> Please use uint32_t instead of unsigned ints throughout the patches.. I'm
> paranoid about unspecified sizes.


I don't think we typically encourage that, except for things that are
arrays...

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

Re: [FFmpeg-devel] [PATCH] NVENC: Better surface allocation alghoritm, fix rc_lookahead

[Moritz Barsnick]

On Mon, Nov 21, 2016 at 12:17:43 +0100, Miroslav Slugeň wrote:
> +   "Defined rc_lookahead require more surfaces, "
Nit:^ requires

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Rostislav Pehlivanov]

On 21 November 2016 at 21:47, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Nov 21, 2016 at 4:40 PM, Rostislav Pehlivanov  >
> wrote:
>
> > On 21 November 2016 at 20:44, Martin Vignali 
> > wrote:
> >
> > > Hello,
> > >
> > > New patchs in attach.
> > > Correction have been made followings comments from Andreas and Carl.
> > >
> > > @Rotislav : thanks for your answer.
> > >
> > > Martin
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> > I don't think you need the checks, it was pointed out that
> > ff_set_dimensions already does that.
> > Also IIRC lavc doesn't support widths or heights over 16384 anyway.
> >
> > >unsigned int pixel_size
> > Please use uint32_t instead of unsigned ints throughout the patches.. I'm
> > paranoid about unspecified sizes.
>
>
> I don't think we typically encourage that, except for things that are
> arrays...
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Didn't know that, ignore it.

Still though, I don't think there's a need to check the dimensions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Moritz Barsnick]

On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> +avpriv_request_sample(s->avctx, "ZIP without predictor compression");
> +return AVERROR_PATCHWELCOME;
> +break;
> +case 3:
> +avpriv_request_sample(s->avctx, "ZIP with predictor compression");
> +return AVERROR_PATCHWELCOME;
> +break;

Are these the only two (detectable) unsupported features? I.e. all
other error messages are true errors, not "unsupported"?

Just wondering,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output shaking issue.

[Mark Thompson]

On 14/11/16 00:19, Jun Zhao wrote:
> 
> 
> On 2016/11/12 22:00, Mark Thompson wrote:
>> On 11/11/16 02:24, Jun Zhao wrote:
>>> From 5db0b2cd0930ed88d853114f13b69a80a44d9c4c Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Fri, 11 Nov 2016 10:04:53 +0800
>>> Subject: [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output
>>>  shaking issue.
>>>
>>> the max_num_reorder_pics/max_dec_pic_buffering_minus in vps/sps are 
>>> incorrect.
>>>
>>> merge libav commit 314b421dd8910ebed7a8d419a0dbea239a00044e
>>> vaapi_encode: Decide on GOP setup before initialising sequence 
>>> parameters
>>>
>>> merge libav commit b8cac1e83066aa87e8402c146c81b77a11b5eec3
>>> vaapi_h265: Fix buffering parameters
>>>
>>> Merged-by: Wang, Yi A 
>>> Merged-by: Jun Zhao 
>>> ---
>>>  libavcodec/vaapi_encode.c  | 13 ++---
>>>  libavcodec/vaapi_encode_h265.c |  8 
>>>  2 files changed, 10 insertions(+), 11 deletions(-)
>>
>> As with the other patch, this is already in the merge queue and I would 
>> prefer to use it from there.
>>
>> Thanks,
>>
>> - Mark
>>
> 
> Please go on the merge :). Hope we can get the mergee patch as quick, maybe I 
> can try the early dorp if you like :)
> 
> Thanks
> 

Hi,

Apologies for the delay in coming back to this.  I have now cherry-picked the 
following commits:

3a9662af6c741f8354b1ca97642f78f5c02e2e8f vaapi_h264: Fix HRD bit_rate/cpb_size 
scaling
80a5d05108cb218e8cd2e25c6621a3bfef0a832e vaapi_encode: Refactor initialisation
892bbbcdc171ff0d08d69636a240ffb95f54243c vaapi_encode: Check packed header 
capabilities
086e4b58b59ea3993107aa24d92bb962ec69667c vaapi_encode: Sync to input surface 
rather than output
956a54129db522998a5abae869568dae2c9774cb vaapi_h264: Set max_num_ref_frames to 
1 when not using B frames
314b421dd8910ebed7a8d419a0dbea239a00044e vaapi_encode: Decide on GOP setup 
before initialising sequence parameters
17a0f9481cf07af0feb3838ca315b970117e8000 vaapi_h264: Fix CFR mode with 
frame_rate set in AVCodecContext
ec17ab381ede4f31c4bdd2767d8f62d24aaf430a vaapi_h264: Write bitstream 
restriction fields
fc30a90898e419cee7c7cb496976da6337d0bf3e vaapi_h265: Fix slice header writing
b8cac1e83066aa87e8402c146c81b77a11b5eec3 vaapi_h265: Fix buffering parameters

This should fix the issues you highlighted above while staying in sync with 
libav.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[Andreas Cadhalpun]

On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun 
> :
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>> There are a few possibilities:
>> a) error out for negative values and also for zero
> 
> Only if -fstrict strict was set.
> 
>> b) error out for negative values, silently accept zero
> 
> Only if -fstrict strict was set.

So you have no preference between accepting zero or not?

I tend to silently accept zero, because I'd like a
consistent solution and in some cases rejecting zero
causes FATE failures.
If a zero causes SIGFPE crashes, it obviously needs to
be rejected with an error.

I also like the idea to only error out if strict is set
and otherwise only warn.

>> c) warn for negative values and also for zero
>> d) warn for negative values, silently accept zero
> 
> I obviously cannot stop you if you feel this should
> be done, but note that users will report regressions
> "warnings are shown for playable files".

Isn't that a good thing?

Because either our demuxer has a bug and should be fixed,
or some other tool created broken files, and if ffmpeg
informs it's users about that, they can try to get that
tool fixed.

>> e) something else
> 
> Broken files exist and FFmpeg should play them if
> reasonable.

I agree in principle.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame.

[Mark Thompson]

On 14/11/16 07:11, Jun Zhao wrote:
> V2 : - Change the last_idr_frame filed location based on Mark code review.
>  - Modify the commit message to actually explain the problem.
> 
> From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 11 Nov 2016 14:53:49 +0800
> Subject: [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after
>  meeting idr frame.
>
> when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
> this issue based on h264 spec. Some decoder don't care this case, but this
> fix will enhance the encoder action. Before this fix, poc number is
> negative in some case.
>
> Reviewed-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 

Applied as 
.

Thanks,

- Mark

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Martin Vignali]

Hello,

2016-11-21 23:16 GMT+01:00 Moritz Barsnick :

> On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> > +avpriv_request_sample(s->avctx, "ZIP without predictor
> compression");
> > +return AVERROR_PATCHWELCOME;
> > +break;
> > +case 3:
> > +avpriv_request_sample(s->avctx, "ZIP with predictor
> compression");
> > +return AVERROR_PATCHWELCOME;
> > +break;
>
> Are these the only two (detectable) unsupported features? I.e. all
> other error messages are true errors, not "unsupported"?
> 
>

I think,  i use AVERROR_PATCHWELCOME, for each documented features, that
the decoder does not support.
Do you have a specific place where you think i return the wrong message ?

I mainly use this link, for the psd specification :
https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/


@Rostislav :
> I don't think you need the checks, it was pointed out that
> ff_set_dimensions already does that.
> Also IIRC lavc doesn't support widths or heights over 16384 anyway.

Andreas ask why i choose 30 000 for check widths/heights
And the choice come from the Adobe documentation : "Supported range is 1 to
30,000."

But i doesn't know about the 16384 limit, in lavc. I wrongly suppose, it
was int max

So if this is the real limit value is under 30 000, you're right, the check
is not need.

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

Re: [FFmpeg-devel] [PATCH] configure: reserve a register for gcc before 5 on x86_32 with PIE

[Andreas Cadhalpun]

On 20.11.2016 21:27, Carl Eugen Hoyos wrote:
> 2016-11-20 19:48 GMT+01:00 Andreas Cadhalpun 
> :
>> On 20.11.2016 13:38, Carl Eugen Hoyos wrote:
>>> --enable-sdl2
>>
>> I'd rather not remove this. The thing is that sdl2 is autodetected, like sdl
>> used to be, but ffplay depends on it.
> 
> How is that different from before?

Not at all.

>> When 3.2 switched to sdl2 the build silently worked, but didn't
>> produce ffplay, which I found annoying.
> 
> But --enable-sdl2 made no difference at all, or do I misunderstand?

Indeed, I just thought it would. Isn't that a bug?
Anyway, thanks for pointing this out.
Is there any way to make sure that configure does not disable ffplay?

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avutil/opt: Add AV_OPT_TYPE_UINT64

[Andreas Cadhalpun]

On 20.11.2016 21:52, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:55:44PM +0100, Andreas Cadhalpun wrote:
>> On 20.11.2016 12:57, Michael Niedermayer wrote:
>>> +if (intnum == 1 && d == (double)UINT64_MAX) {
>>> +*(int64_t *)dst = UINT64_MAX;
>>
>> Is there a reason why this uses int64_t, 
>>
>>> +} else if (o->max > INT64_MAX + 1ULL && d > INT64_MAX + 1ULL) {
>>> +*(uint64_t *)dst = (llrint(d - (INT64_MAX + 1ULL)) + 
>>> (INT64_MAX + 1ULL))*intnum;
>>
>> but this uint64_t,
>>
>>> +} else {
>>> +*(int64_t *)dst = llrint(d) * intnum;
>>
>> and this again int64_t?
> 
> these are left over from the year old patch this is based on
> fixed locally

OK. Now I've another question. Why does the check involve o->max?
Is the out-of-range check at the beginning of write_number not
sufficient?

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/avfiltergraph: always reduce all_layouts to a single layout

[Marton Balint]

On Mon, 21 Nov 2016, Nicolas George wrote:


Le primidi 1er frimaire, an CCXXV, Marton Balint a écrit :

This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.

Further reference:
https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html

I can't reproduce ticket #2899 so I am not sure the original patch is still
needed. Reverting it fixes unknown channel layout support for trivial
resamples, such as:

ffmpeg -f lavfi -i "aevalsrc=0|0|0|0|0|0|0|0|0:d=1,asetnsamples" -f null none

Signed-off-by: Marton Balint 
---
 libavfilter/avfiltergraph.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 3af698d..379bc1a 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -802,8 +802,7 @@ static int reduce_formats_on_filter(AVFilterContext *filter)
 if (inlink->type != outlink->type || fmts->nb_channel_layouts == 1)
 continue;

-if (fmts->all_layouts &&
-(!FF_LAYOUT2COUNT(fmt) || fmts->all_counts)) {
+if (fmts->all_layouts) {
 /* Turn the infinite list into a singleton */
 fmts->all_layouts = fmts->all_counts  = 0;
 if (ff_add_channel_layout(&outlink->in_channel_layouts, fmt) < 
0)


This is not correct. It makes a difference if the condition you remove
is false, i.e. if !fmts->all_counts && FF_LAYOUT2COUNT(fmt): the filter
does not support unknown layouts, and you propose to give it one
nonetheless.


Okay, so the proper fix would be to make asetnsamples support unknown 
channel layouts? I thought it does, but as far as I see, the default, 
if no query_formats callback is specified is to only allow known layouts.


Wouldn't it make sense to change the default to allow unknown channel 
layouts as well, if no query_formats is specified?


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

[FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().

[Wan-Teh Chang]

Hi,

This patch makes the one-time initialization in av_get_cpu_flags()
thread-safe. The data race was reported by ThreadSanitizer.

Wan-Teh Chang (1):
  avutil: fix data race in av_get_cpu_flags().

 libavutil/atomic.c   | 40 
 libavutil/atomic.h   | 34 --
 libavutil/atomic_gcc.h   | 33 +
 libavutil/atomic_suncc.h | 19 +++
 libavutil/atomic_win32.h | 21 +
 libavutil/cpu.c  | 41 ++---
 libavutil/tests/atomic.c | 13 +
 7 files changed, 180 insertions(+), 21 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().

[Wan-Teh Chang]

Make the one-time initialization in av_get_cpu_flags() thread-safe.
The fix assumes -1 is an invalid value for cpu flags.

The fix requires new atomic functions to get, set, and compare-and-swap
an integer without a memory barrier.

The data race fix is written by Dmitry Vyukov of Google.

Signed-off-by: Wan-Teh Chang 
---
 libavutil/atomic.c   | 40 
 libavutil/atomic.h   | 34 --
 libavutil/atomic_gcc.h   | 33 +
 libavutil/atomic_suncc.h | 19 +++
 libavutil/atomic_win32.h | 21 +
 libavutil/cpu.c  | 41 ++---
 libavutil/tests/atomic.c | 13 +
 7 files changed, 180 insertions(+), 21 deletions(-)

diff --git a/libavutil/atomic.c b/libavutil/atomic.c
index 64cff25..7bce013 100644
--- a/libavutil/atomic.c
+++ b/libavutil/atomic.c
@@ -40,6 +40,11 @@ int avpriv_atomic_int_get(volatile int *ptr)
 return res;
 }
 
+int avpriv_atomic_int_get_relaxed(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
 void avpriv_atomic_int_set(volatile int *ptr, int val)
 {
 pthread_mutex_lock(&atomic_lock);
@@ -47,6 +52,11 @@ void avpriv_atomic_int_set(volatile int *ptr, int val)
 pthread_mutex_unlock(&atomic_lock);
 }
 
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
 int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int inc)
 {
 int res;
@@ -59,6 +69,17 @@ int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int 
inc)
 return res;
 }
 
+int avpriv_atomic_int_cas_relaxed(volatile int *ptr, int oldval, int newval)
+{
+int ret;
+pthread_mutex_lock(&atomic_lock);
+ret = *ptr;
+if (ret == oldval)
+*ptr = newval;
+pthread_mutex_unlock(&atomic_lock);
+return ret;
+}
+
 void *avpriv_atomic_ptr_cas(void * volatile *ptr, void *oldval, void *newval)
 {
 void *ret;
@@ -77,17 +98,36 @@ int avpriv_atomic_int_get(volatile int *ptr)
 return *ptr;
 }
 
+int avpriv_atomic_int_get_relaxed(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
 void avpriv_atomic_int_set(volatile int *ptr, int val)
 {
 *ptr = val;
 }
 
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
 int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int inc)
 {
 *ptr += inc;
 return *ptr;
 }
 
+int avpriv_atomic_int_cas_relaxed(volatile int *ptr, int oldval, int newval)
+{
+if (*ptr == oldval) {
+*ptr = newval;
+return oldval;
+}
+return *ptr;
+}
+
 void *avpriv_atomic_ptr_cas(void * volatile *ptr, void *oldval, void *newval)
 {
 if (*ptr == oldval) {
diff --git a/libavutil/atomic.h b/libavutil/atomic.h
index 15906d2..c5aa1a4 100644
--- a/libavutil/atomic.h
+++ b/libavutil/atomic.h
@@ -40,20 +40,38 @@
  *
  * @param ptr atomic integer
  * @return the current value of the atomic integer
- * @note This acts as a memory barrier.
+ * @note This acts as a memory barrier with sequentially-consistent ordering.
  */
 int avpriv_atomic_int_get(volatile int *ptr);
 
 /**
+ * Load the current value stored in an atomic integer.
+ *
+ * @param ptr atomic integer
+ * @return the current value of the atomic integer
+ * @note This does NOT act as a memory barrier.
+ */
+int avpriv_atomic_int_get_relaxed(volatile int *ptr);
+
+/**
  * Store a new value in an atomic integer.
  *
  * @param ptr atomic integer
  * @param val the value to store in the atomic integer
- * @note This acts as a memory barrier.
+ * @note This acts as a memory barrier with sequentially-consistent ordering.
  */
 void avpriv_atomic_int_set(volatile int *ptr, int val);
 
 /**
+ * Store a new value in an atomic integer.
+ *
+ * @param ptr atomic integer
+ * @param val the value to store in the atomic integer
+ * @note This does NOT act as a memory barrier.
+ */
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val);
+
+/**
  * Add a value to an atomic integer.
  *
  * @param ptr atomic integer
@@ -65,12 +83,24 @@ void avpriv_atomic_int_set(volatile int *ptr, int val);
 int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int inc);
 
 /**
+ * Atomic integer compare and swap.
+ *
+ * @param ptr pointer to the integer to operate on
+ * @param oldval do the swap if the current value of *ptr equals to oldval
+ * @param newval value to replace *ptr with
+ * @return the value of *ptr before comparison
+ * @note This does NOT act as a memory barrier.
+ */
+int avpriv_atomic_int_cas_relaxed(volatile int *ptr, int oldval, int newval);
+
+/**
  * Atomic pointer compare and swap.
  *
  * @param ptr pointer to the pointer to operate on
  * @param oldval do the swap if the current value of *ptr equals to oldval
  * @param newval value to replace *ptr with
  * @return the value of *ptr before comparison
+ * @note This acts as a memory barrier with sequentially-consistent 

Re: [FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[Andreas Cadhalpun]

On 21.11.2016 03:13, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>> There are a few possibilities:
>> a) error out for negative values and also for zero
>> b) error out for negative values, silently accept zero
>> c) warn for negative values and also for zero
>> d) warn for negative values, silently accept zero
>> e) something else
>>
>> Is there a consensus on which way is best?
> 
> I think this depends on the format and what exists in real world files
> 
> If X is allowed by the spec, clearly no error or warning should be
> produced for it
> 
> If X is not allowed by the spec but occurs in some file then no error
> should occur by default but likely a warning. More strict compliance
> options can change this.
> 
> If X does not work (demuxer failing in some form) then it should error
> out
> 
> 
> Theres quite a bit between these and theres the problem of not knowing
> spec and file existence easily

In general that sounds reasonable, but what does it mean in practice?

For example what should be done about overflows, e.g. when calculating
the bit rate? Does this count as demuxer failing?

And what should be done if the spec says a field is unsigned, but
our framework only supports the signed variant?

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Andreas Cadhalpun]

On 20.11.2016 17:57, Martin Vignali wrote:
>>> Support uncompress and rle compression in Image Data Section.
>>   ^
>> decompression
>>
> 
> Not sure i understand, do you mean :
> Support uncompress and rle decompression in Image Data Section.
> ?
> Because currently, the psd reader, can manage uncompress or rle.

Never mind, I just didn't parse this sentence correctly.

>>
>> Also a fate test would be nice.
>>
> Il would add a fate test, with the samples (in the previous link, when the
> path will be apply (to not mix, path and fate test).

OK. Alternatively you could already send a separate patch adding the fate test.

>>> diff --git a/libavcodec/psd.c b/libavcodec/psd.c
>>> new file mode 100644
>>> index 000..90ee337
>>> --- /dev/null
>>> +++ b/libavcodec/psd.c
>>> @@ -0,0 +1,428 @@
>> [...]
>>> +s->height = bytestream2_get_be32(&s->gb);
>>> +
>>> +if ((s->height < 1) || (s->height > 3)) {
>>
>> Why 3?
>> ff_set_dimensions already checks for sane dimensions.
>>
> 
> Following adobe specs :
> http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577409_pgfId-1055726
> in a psd file, the width or height, can't be > to 30 000 pixels.

I see. In that case it makes sense to explicitly check this, as
the check in ff_set_dimensions is more general and might change
in the future.

On 20.11.2016 18:32, Martin Vignali wrote:
>> However, all the rle samples seem to not decode entirely correct, instead
>> > containing blue/white rectangular areas.
>> >
>> >
>> > Sorry, forget to answer to that.
> The white/blue rect have been add by me to the sample file, in order to
> "enable" the rle compression of photoshop.
> So i think, the conversion is correct for RLE compression

Thanks for explaining that.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage

[Michael Niedermayer]

On Mon, Nov 21, 2016 at 04:37:12PM +0100, wm4 wrote:
[...]
> Besides, using this in practice would only trigger tons of malloc
> failure handling bugs, so practical uses would probably involve
> tearing down the whole process.

If such bugs exist (no doubt some do) they need to be fixed with or
without this patchset

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

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


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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Carl Eugen Hoyos]

2016-11-22 0:57 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 17:57, Martin Vignali wrote:

 +s->height = bytestream2_get_be32(&s->gb);
 +
 +if ((s->height < 1) || (s->height > 3)) {
>>>
>>> Why 3?
>>> ff_set_dimensions already checks for sane dimensions.
>>>
>>
>> Following adobe specs :
>> http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577409_pgfId-1055726
>> in a psd file, the width or height, can't be > to 30 000 pixels.
>
> I see. In that case it makes sense to explicitly check this, as
> the check in ff_set_dimensions is more general and might
> change in the future.

If an application writes psd files with width or height > 3 (or,
horribile dictu, Adobe changes the limits), we want to decode
such images (unless strict strict was set).

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

Re: [FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[Carl Eugen Hoyos]

2016-11-22 0:40 GMT+01:00 Andreas Cadhalpun :

> For example what should be done about overflows, e.g. when
> calculating the bit rate? Does this count as demuxer failing?

I don't understand this question:
There are formats for which we don't know the specification (or
it may not exist): Of course we always want to fix all undefined
behaviour, all crashes and similar - this is not related to the
specifications in question.

FFmpeg should never by default refuse to decode media files
that can be decoded and it should never stop reading such files.

> And what should be done if the spec says a field is unsigned,
> but our framework only supports the signed variant?

Is there a sample for which this makes a difference? If yes, we
should try to fix it.

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

Re: [FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().

[Michael Niedermayer]

On Mon, Nov 21, 2016 at 03:37:49PM -0800, Wan-Teh Chang wrote:
> Make the one-time initialization in av_get_cpu_flags() thread-safe.
> The fix assumes -1 is an invalid value for cpu flags.

please explain the bug / race that occurs and how it is fixed


> 
> The fix requires new atomic functions to get, set, and compare-and-swap
> an integer without a memory barrier.

why ?


> 
> The data race fix is written by Dmitry Vyukov of Google.

Then the author for the git patch should be set accordingly


[...]

> @@ -44,7 +45,20 @@
>  #include 
>  #endif
>  
> -static int flags, checked;
> +static int cpu_flags = -1;
> +
> +static int get_cpu_flags(void)
> +{
> +if (ARCH_AARCH64)
> +return ff_get_cpu_flags_aarch64();
> +if (ARCH_ARM)
> +return ff_get_cpu_flags_arm();
> +if (ARCH_PPC)
> +return ff_get_cpu_flags_ppc();
> +if (ARCH_X86)
> +return ff_get_cpu_flags_x86();
> +/* Not reached. */

src/libavutil/cpu.c: In function ‘get_cpu_flags’:
src/libavutil/cpu.c:61: error: control reaches end of non-void function

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[Carl Eugen Hoyos]

2016-11-22 0:06 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
>> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun 
>> :
>>> Currently many demuxers silently accept wrong (i.e. negative) values
>>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>>> so the question is now, how?
>>>
>>> There are a few possibilities:
>>> a) error out for negative values and also for zero
>>
>> Only if -fstrict strict was set.
>>
>>> b) error out for negative values, silently accept zero
>>
>> Only if -fstrict strict was set.
>
> So you have no preference between accepting zero or not?

Sorry:
By default, FFmpeg should not error out because of an
invalid value in some field, neither if it is zero although
it should be positive nor when it is negative.

> I tend to silently accept zero, because I'd like a
> consistent solution and in some cases rejecting zero
> causes FATE failures.

If there were a bug, you should of course fix fate, fate
alone is generally no argument in favour or against a patch.

> If a zero causes SIGFPE crashes, it obviously needs to
> be rejected with an error.

The crash has to be fixed.

If a simple fix is possible that allows to decode such samples,
it should be preferred over a fix that doesn't allow it.

> I also like the idea to only error out if strict is set
> and otherwise only warn.
>
>>> c) warn for negative values and also for zero
>>> d) warn for negative values, silently accept zero
>>
>> I obviously cannot stop you if you feel this should
>> be done, but note that users will report regressions
>> "warnings are shown for playable files".
>
> Isn't that a good thing?

I tried to explain above why it is not necessarily a good thing.

> Because either our demuxer has a bug and should be fixed,
> or some other tool created broken files, and if ffmpeg
> informs it's users about that, they can try to get that
> tool fixed.

(Träum weiter)
Seriously: We have an uncountable amount of files that
do not respect some "specification", many of them apparently
by intention, many written by applications that do not exist
since a long time, and some written by applications that have
fixed the issue meanwhile: Of course it can be a (very) good
thing to print warnings but in general, we should try to fix a
few of the thousands of known bugs in FFmpeg and not
spend infinite time on possible issues in other applications.

Sorry if I just misunderstand you.

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

Re: [FFmpeg-devel] [PATCH] avformat/utils: check for overflow before reallocating side data

[Neil Birkbeck]

On Sat, Nov 19, 2016 at 3:28 PM, James Almer  wrote:

> On 11/19/2016 7:19 PM, Michael Niedermayer wrote:
> > On Sat, Nov 19, 2016 at 03:09:15PM -0300, James Almer wrote:
> >> This makes av_stream_add_side_data() consistent with
> av_packet_add_side_data().
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavformat/utils.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > LGTM
> >
> > thx
>
> Pushed, Thanks.


Isn't the realloc missing brackets around the num elements:
   tmp = av_realloc(st->side_data, (st->nb_side_data + 1) * sizeof(*tmp));
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: reserve a register for gcc before 5 on x86_32 with PIE

[Carl Eugen Hoyos]

2016-11-22 0:20 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 21:27, Carl Eugen Hoyos wrote:

>> But --enable-sdl2 made no difference at all, or do I misunderstand?
>
> Indeed, I just thought it would. Isn't that a bug?

It is neither a bug nor not a bug, it is just how FFmpeg's configure
works for approximately a decade.

Please remove --enable-sdl2 because it makes people think it
works the way you expected it to work.

> Anyway, thanks for pointing this out.

> Is there any way to make sure that configure does not disable ffplay?

I would expect something like (untested):
Requires: sdl-devel >= 2.0.1

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Lou Logan]

On Tue, 22 Nov 2016 01:21:08 +0100, Carl Eugen Hoyos wrote:

> If an application writes psd files with width or height > 3 (or,
> horribile dictu, Adobe changes the limits), we want to decode
> such images (unless strict strict was set).

We shouldn't be encouraging theoretical random broken crapware that
ignores specs. Anything over 3 should be using PSB anyway.

Instead of blindly decoding a garbage example it should require
"-strict experimental" to "allow non standardized experimental things".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/formats: allow unknown channel layouts by default

[Marton Balint]

Adds unknown channel layout support for filters where query_formats is not
specified. List of the affected filters:

abench
afifo
ainterleave
aloop
ametadata
anull
anullsink
apad
aperms
arealtime
aselect
asendcmd
asetnsamples
asetpts
asettb
ashowinfo
asidedata
asplit
asyncts
atrim
azmq

Also remove query_formats from filters which already allowed all layouts.

Signed-off-by: Marton Balint 
---
 libavfilter/af_anull.c   |  1 -
 libavfilter/f_loop.c |  1 -
 libavfilter/f_metadata.c |  1 -
 libavfilter/f_sidedata.c |  1 -
 libavfilter/formats.c|  5 -
 libavfilter/formats.h| 10 --
 libavfilter/split.c  |  1 -
 libavfilter/trim.c   |  1 -
 8 files changed, 21 deletions(-)

diff --git a/libavfilter/af_anull.c b/libavfilter/af_anull.c
index fff456e..1d0af45 100644
--- a/libavfilter/af_anull.c
+++ b/libavfilter/af_anull.c
@@ -46,7 +46,6 @@ static const AVFilterPad avfilter_af_anull_outputs[] = {
 AVFilter ff_af_anull = {
 .name  = "anull",
 .description   = NULL_IF_CONFIG_SMALL("Pass the source unchanged to the 
output."),
-.query_formats = ff_query_formats_all,
 .inputs= avfilter_af_anull_inputs,
 .outputs   = avfilter_af_anull_outputs,
 };
diff --git a/libavfilter/f_loop.c b/libavfilter/f_loop.c
index 69bfb10..5a32807 100644
--- a/libavfilter/f_loop.c
+++ b/libavfilter/f_loop.c
@@ -233,7 +233,6 @@ AVFilter ff_af_aloop = {
 .priv_size = sizeof(LoopContext),
 .priv_class= &aloop_class,
 .uninit= auninit,
-.query_formats = ff_query_formats_all,
 .inputs= ainputs,
 .outputs   = aoutputs,
 };
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 24deccf..1f613ec 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -373,7 +373,6 @@ AVFilter ff_af_ametadata = {
 .priv_class= &ametadata_class,
 .init  = init,
 .uninit= uninit,
-.query_formats = ff_query_formats_all,
 .inputs= ainputs,
 .outputs   = aoutputs,
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
index 4863cc9..45d246b 100644
--- a/libavfilter/f_sidedata.c
+++ b/libavfilter/f_sidedata.c
@@ -139,7 +139,6 @@ AVFilter ff_af_asidedata = {
 .priv_size = sizeof(SideDataContext),
 .priv_class= &asidedata_class,
 .init  = init,
-.query_formats = ff_query_formats_all,
 .inputs= ainputs,
 .outputs   = aoutputs,
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 20f45e3..0661618 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -596,11 +596,6 @@ static int default_query_formats_common(AVFilterContext 
*ctx,
 
 int ff_default_query_formats(AVFilterContext *ctx)
 {
-return default_query_formats_common(ctx, ff_all_channel_layouts);
-}
-
-int ff_query_formats_all(AVFilterContext *ctx)
-{
 return default_query_formats_common(ctx, ff_all_channel_counts);
 }
 
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index 77981f5..7e05ece 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -187,16 +187,6 @@ av_warn_unused_result
 int ff_default_query_formats(AVFilterContext *ctx);
 
 /**
- * Set the formats list to all existing formats.
- * This function behaves like ff_default_query_formats(), except it also
- * accepts channel layouts with unknown disposition. It should only be used
- * with audio filters.
- */
-av_warn_unused_result
-int ff_query_formats_all(AVFilterContext *ctx);
-
-
-/**
  * Create a list of supported formats. This is intended for use in
  * AVFilter->query_formats().
  *
diff --git a/libavfilter/split.c b/libavfilter/split.c
index 6cf4ab1..6630087 100644
--- a/libavfilter/split.c
+++ b/libavfilter/split.c
@@ -144,7 +144,6 @@ AVFilter ff_af_asplit = {
 .priv_class  = &asplit_class,
 .init= split_init,
 .uninit  = split_uninit,
-.query_formats = ff_query_formats_all,
 .inputs  = avfilter_af_asplit_inputs,
 .outputs = NULL,
 .flags   = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
diff --git a/libavfilter/trim.c b/libavfilter/trim.c
index 9daaeaf..1dbbabb 100644
--- a/libavfilter/trim.c
+++ b/libavfilter/trim.c
@@ -365,7 +365,6 @@ AVFilter ff_af_atrim = {
 .name= "atrim",
 .description = NULL_IF_CONFIG_SMALL("Pick one continuous section from the 
input, drop the rest."),
 .init= init,
-.query_formats = ff_query_formats_all,
 .priv_size   = sizeof(TrimContext),
 .priv_class  = &atrim_class,
 .inputs  = atrim_inputs,
-- 
2.10.0

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

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Carl Eugen Hoyos]

2016-11-21 19:52 GMT+01:00 Gregory J. Wolfe :

> (2) When ALL threading support is disabled, the build should not create a
> dependency on ANY thread library.

If this done through "#if HAVE_THREADS", it would be preferable to
split the patches imo.

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

Re: [FFmpeg-devel] [PATCH 2/3] avutil/atomic: Add avpriv_atomic_int64_cas()

[Carl Eugen Hoyos]

2016-11-21 16:49 GMT+01:00 James Almer :

>> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, 
>> int64_t newval)
>
> There's a bunch of libav commits in queue to replace the entire custom atomic
> API and use instead the standard C11 API.

What does that mean for pre-C11 compilers?

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Michael Niedermayer]

On Tue, Nov 22, 2016 at 12:15:16AM +0100, Martin Vignali wrote:
> Hello,
> 
> 2016-11-21 23:16 GMT+01:00 Moritz Barsnick :
> 
> > On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> > > +avpriv_request_sample(s->avctx, "ZIP without predictor
> > compression");
> > > +return AVERROR_PATCHWELCOME;
> > > +break;
> > > +case 3:
> > > +avpriv_request_sample(s->avctx, "ZIP with predictor
> > compression");
> > > +return AVERROR_PATCHWELCOME;
> > > +break;
> >
> > Are these the only two (detectable) unsupported features? I.e. all
> > other error messages are true errors, not "unsupported"?
> > 
> >
> 
> I think,  i use AVERROR_PATCHWELCOME, for each documented features, that
> the decoder does not support.
> Do you have a specific place where you think i return the wrong message ?
> 
> I mainly use this link, for the psd specification :
> https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/
> 
> 
> @Rostislav :
> > I don't think you need the checks, it was pointed out that
> > ff_set_dimensions already does that.
> > Also IIRC lavc doesn't support widths or heights over 16384 anyway.
> 
> Andreas ask why i choose 30 000 for check widths/heights
> And the choice come from the Adobe documentation : "Supported range is 1 to
> 30,000."
> 
> But i doesn't know about the 16384 limit, in lavc. I wrongly suppose, it
> was int max

./ffmpeg -i matrixbench_mpeg2.mpg -vf scale=6:16 -vcodec ffv1 test.nut
works fine

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avutil/atomic: Add avpriv_atomic_int64_cas()

[James Almer]

On 11/21/2016 10:20 PM, Carl Eugen Hoyos wrote:
> 2016-11-21 16:49 GMT+01:00 James Almer :
> 
>>> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval, 
>>> int64_t newval)
>>
>> There's a bunch of libav commits in queue to replace the entire custom atomic
>> API and use instead the standard C11 API.
> 
> What does that mean for pre-C11 compilers?
> 
> Carl Eugen

As i said in a following paragraph, the set includes fallback compat
implementations for non C11 compilers. The result is similar to how
threading is handled on non-pthreads targets.

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

Re: [FFmpeg-devel] [PATCH] avformat/utils: check for overflow before reallocating side data

[James Almer]

On 11/21/2016 9:37 PM, Neil Birkbeck wrote:
> On Sat, Nov 19, 2016 at 3:28 PM, James Almer  wrote:
> 
>> On 11/19/2016 7:19 PM, Michael Niedermayer wrote:
>>> On Sat, Nov 19, 2016 at 03:09:15PM -0300, James Almer wrote:
 This makes av_stream_add_side_data() consistent with
>> av_packet_add_side_data().

 Signed-off-by: James Almer 
 ---
  libavformat/utils.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> LGTM
>>>
>>> thx
>>
>> Pushed, Thanks.
> 
> 
> Isn't the realloc missing brackets around the num elements:
>tmp = av_realloc(st->side_data, (st->nb_side_data + 1) * sizeof(*tmp));

Yikes, yes, thanks a lot for noticing. Pushed that fix.

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

[FFmpeg-devel] [PATCH] avcodec/aac_adtstoasc: recover original extradata if the stream is already ASC

[James Almer]

Fixes ticket #5973

Signed-off-by: James Almer 
---
Maybe init() should propagate the extradata down the filter chain instead
of this, since if an aac stream has extradata then it means that it's an
ASC stream. Neither ADTS or LATM use extradata.

What's preferred?

 libavcodec/aac_adtstoasc_bsf.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
index 48889fc..76cf32e 100644
--- a/libavcodec/aac_adtstoasc_bsf.c
+++ b/libavcodec/aac_adtstoasc_bsf.c
@@ -54,8 +54,19 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket 
*out)
 
 init_get_bits(&gb, in->data, AAC_ADTS_HEADER_SIZE * 8);
 
-if (bsfc->par_in->extradata && show_bits(&gb, 12) != 0xfff)
+if (bsfc->par_in->extradata && show_bits(&gb, 12) != 0xfff) {
+if (!bsfc->par_out->extradata) {
+/* Stream is already AudioSpecificConfig. Restore its original 
extradata */
+bsfc->par_out->extradata = av_mallocz(bsfc->par_in->extradata_size 
+ AV_INPUT_BUFFER_PADDING_SIZE);
+if (!bsfc->par_out->extradata) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+bsfc->par_out->extradata_size = bsfc->par_in->extradata_size;
+memcpy(bsfc->par_out->extradata, bsfc->par_in->extradata, 
bsfc->par_in->extradata_size);
+}
 goto finish;
+}
 
 if (avpriv_aac_parse_header(&gb, &hdr) < 0) {
 av_log(bsfc, AV_LOG_ERROR, "Error parsing ADTS frame header!\n");
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] avformat/flvenc: add no_metadata to flvflags

[Steven Liu]

2016-11-21 20:29 GMT+08:00 Steven Liu :

> some flv have no metadata,
> ffmpeg will same with the source flv stream.
>
> Signed-off-by: Steven Liu 
> ---
>  doc/muxers.texi  |3 +++
>  libavformat/flvenc.c |8 +++-
>  2 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 806182a..8689341 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -148,6 +148,9 @@ Place AAC sequence header based on audio stream data.
>  @item no_sequence_end
>  Disable sequence end tag.
>
> +@item no_metadata
> +Disable metadata tag.
> +
>  @item add_keyframe_index
>  Used to facilitate seeking; particularly for HTTP pseudo streaming.
>  @end table
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 4ca6aea..177052a 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -67,6 +67,7 @@ typedef enum {
>  FLV_AAC_SEQ_HEADER_DETECT = (1 << 0),
>  FLV_NO_SEQUENCE_END = (1 << 1),
>  FLV_ADD_KEYFRAME_INDEX = (1 << 2),
> +FLV_NO_METADATA = (1 << 3),
>  } FLVFlags;
>
>  typedef struct FLVFileposition {
> @@ -744,7 +745,11 @@ static int flv_write_header(AVFormatContext *s)
>  flv->reserved = 5;
>  }
>
> -write_metadata(s, 0);
> +if (flv->flags & FLV_NO_METADATA) {
> +pb->seekable = 0;
> +} else {
> +write_metadata(s, 0);
> +}
>
>  for (i = 0; i < s->nb_streams; i++) {
>  flv_write_codec_header(s, s->streams[i]->codecpar);
> @@ -1055,6 +1060,7 @@ static const AVOption options[] = {
>  { "flvflags", "FLV muxer flags", offsetof(FLVContext, flags),
> AV_OPT_TYPE_FLAGS, {.i64 = 0}, INT_MIN, INT_MAX,
> AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
>  { "aac_seq_header_detect", "Put AAC sequence header based on stream
> data", 0, AV_OPT_TYPE_CONST, {.i64 = FLV_AAC_SEQ_HEADER_DETECT}, INT_MIN,
> INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
>  { "no_sequence_end", "disable sequence end for FLV", 0,
> AV_OPT_TYPE_CONST, {.i64 = FLV_NO_SEQUENCE_END}, INT_MIN, INT_MAX,
> AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
> +{ "no_metadata", "disable metadata for FLV", 0, AV_OPT_TYPE_CONST,
> {.i64 = FLV_NO_METADATA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
> "flvflags" },
>  { "add_keyframe_index", "Add keyframe index metadata", 0,
> AV_OPT_TYPE_CONST, {.i64 = FLV_ADD_KEYFRAME_INDEX}, INT_MIN, INT_MAX,
> AV_OPT_FLAG_ENCODING_PARAM, "flvflags" },
>  { NULL },
>  };
> --
> 1.7.1
>
>
pushed, Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Add experimental muxing support for FLAC in ISO BMFF (MP4).

[Matthew Gregan]

At 2016-11-21T15:56:23-0300, James Almer wrote:
> Seeing the maintainer hasn't replied, i have pushed it. Seems to adhere to
> the (draft) spec correctly, and is under an experimental strict check.

Thanks for your assistance getting this reviewed and landed, much
appreciated.

> I tried creating some FLAC only files and they play fine on Firefox 51 b1,
> which is the first version with FLAC support. However an h264+flac file
> gave me audio only and no video. Do you know if it's a bug that should be
> reported to Mozilla, or just expected behavior as they only mention support
> for h264+aac and no other specific AV combination?

That's a bug caused by missing functionality in the new Rust demuxer (which
is only used for VP9, FLAC, and Opus in MP4 for now, but the presence of any
of those track types triggers the new demuxer for the entire stream).  It'll
be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1317609.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avutil: add P016 pixel format

[Philip Langdale]

P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.

It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.

Signed-off-by: Philip Langdale 
---
 libavutil/pixdesc.c | 24 
 libavutil/pixfmt.h  |  4 
 libavutil/version.h |  2 +-
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index f8092ef..3b9c45d 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2078,6 +2078,30 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
 },
+[AV_PIX_FMT_P016LE] = {
+.name = "p016le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 2, 0, 0, 16, 1, 15, 1 },   /* Y */
+{ 1, 4, 0, 0, 16, 3, 15, 1 },   /* U */
+{ 1, 4, 2, 0, 16, 3, 15, 3 },   /* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_P016BE] = {
+.name = "p016be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 2, 0, 0, 16, 1, 15, 1 },   /* Y */
+{ 1, 4, 0, 0, 16, 3, 15, 1 },   /* U */
+{ 1, 4, 2, 0, 16, 3, 15, 3 },   /* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
+},
 [AV_PIX_FMT_GBRAP12LE] = {
 .name = "gbrap12le",
 .nb_components = 4,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 96860ce..dfb1b11 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -311,6 +311,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_GRAY10BE,   ///

[FFmpeg-devel] [PATCH 0/2] P016 Pixel Format v2

[Philip Langdale]

It's pretty much P010 with the low 6 bits explicitly allowed to contain
data. I did not attempt to implement any fast path conversion for P010.
Someone could obviously add that if desired.

Updated to bump minor version

Philip Langdale (2):
  avutil: add P016 pixel format
  swscale: add P016 input support

 libavutil/pixdesc.c | 24 
 libavutil/pixfmt.h  |  4 
 libavutil/version.h |  2 +-
 libswscale/input.c  | 32 
 libswscale/utils.c  |  2 ++
 5 files changed, 63 insertions(+), 1 deletion(-)

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

[FFmpeg-devel] [PATCH 2/2] swscale: add P016 input support

[Philip Langdale]

Signed-off-by: Philip Langdale 
---
 libswscale/input.c | 32 
 libswscale/utils.c |  2 ++
 2 files changed, 34 insertions(+)

diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -719,6 +719,28 @@ static void p010BEToUV_c(uint8_t *dstU, uint8_t *dstV,
 }
 }
 
+static void p016LEToUV_c(uint8_t *dstU, uint8_t *dstV,
+   const uint8_t *unused0, const uint8_t *src1, const 
uint8_t *src2,
+   int width, uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RL16(src1 + i * 4 + 0));
+AV_WN16(dstV + i * 2, AV_RL16(src1 + i * 4 + 2));
+}
+}
+
+static void p016BEToUV_c(uint8_t *dstU, uint8_t *dstV,
+   const uint8_t *unused0, const uint8_t *src1, const 
uint8_t *src2,
+   int width, uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RB16(src1 + i * 4 + 0));
+AV_WN16(dstV + i * 2, AV_RB16(src1 + i * 4 + 2));
+}
+}
+
 #define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
 
 static void bgr24ToY_c(uint8_t *_dst, const uint8_t *src, const uint8_t 
*unused1, const uint8_t *unused2,
@@ -1085,6 +1107,12 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_P010BE:
 c->chrToYV12 = p010BEToUV_c;
 break;
+case AV_PIX_FMT_P016LE:
+c->chrToYV12 = p016LEToUV_c;
+break;
+case AV_PIX_FMT_P016BE:
+c->chrToYV12 = p016BEToUV_c;
+break;
 }
 if (c->chrSrcHSubSample) {
 switch (srcFormat) {
@@ -1326,6 +1354,8 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_GRAY10LE:
 case AV_PIX_FMT_GRAY12LE:
 case AV_PIX_FMT_GRAY16LE:
+
+case AV_PIX_FMT_P016LE:
 c->lumToYV12 = bswap16Y_c;
 break;
 case AV_PIX_FMT_YUVA444P9LE:
@@ -1362,6 +1392,8 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_GRAY10BE:
 case AV_PIX_FMT_GRAY12BE:
 case AV_PIX_FMT_GRAY16BE:
+
+case AV_PIX_FMT_P016BE:
 c->lumToYV12 = bswap16Y_c;
 break;
 case AV_PIX_FMT_YUVA444P9BE:
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 15cc56d..88a22bd 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -252,6 +252,8 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
 [AV_PIX_FMT_AYUV64LE]= { 1, 1},
 [AV_PIX_FMT_P010LE]  = { 1, 1 },
 [AV_PIX_FMT_P010BE]  = { 1, 1 },
+[AV_PIX_FMT_P016LE]  = { 1, 0 },
+[AV_PIX_FMT_P016BE]  = { 1, 0 },
 };
 
 int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel