Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: add premultiplied alpha mode

2017-12-02 Thread Marton Balint



On Sat, 2 Dec 2017, Paul B Mahol wrote:


On 12/2/17, Marton Balint  wrote:



On Fri, 1 Dec 2017, Paul B Mahol wrote:


Signed-off-by: Paul B Mahol 
---
doc/filters.texi |   4 ++
libavfilter/vf_overlay.c | 160
---
2 files changed, 140 insertions(+), 24 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index f7c371592f..0699728b7e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11328,6 +11328,10 @@ Default value is @samp{yuv420}.

@item repeatlast
See @ref{framesync}.
+
+@item alpha
+Set format of alpha, it can be @var{straight} or @var{premultiplied}.
+Default is @var{straight}.
@end table


Does this mean that not only overlay, but input and output is also
considered as premultiplied? Maybe better to clarify this in the docs.


I done it for overlay only alpha. For rest I'm little confused what needs doing.


Ok, then just write in the docs:

"Set format of alpha of the overlaid video."





Have you measured the slowdown caused by the extra condition in the pixel
blending code? If it is more than 1-2%, then some DEFINE magic (or
making the blend_image functions inline?) would be better IMHO.


It should already be inlined. Thats why there are so many functions.


Not all of them, blend_image_packed_rgb misses an av_always_inline.

Regards,
Marton




The @option{x}, and @option{y} expressions can contain the following
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 5bf3d66cf1..8206dae454 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -109,6 +109,7 @@ typedef struct OverlayContext {
uint8_t overlay_rgba_map[4];
uint8_t overlay_has_alpha;
int format; ///< OverlayFormat
+int alpha_format;
int eval_mode;  ///< EvalMode

FFFrameSync fs;
@@ -403,7 +404,8 @@ static int config_output(AVFilterLink *outlink)

static void blend_image_packed_rgb(AVFilterContext *ctx,
   AVFrame *dst, const AVFrame *src,
-   int main_has_alpha, int x, int y)
+   int main_has_alpha, int x, int y,
+   int is_straight)
{
OverlayContext *s = ctx->priv;
int i, imax, j, jmax;
@@ -454,9 +456,9 @@ static void blend_image_packed_rgb(AVFilterContext
*ctx,
default:
// main_value = main_value * (1 - alpha) + overlay_value *
alpha
// since alpha is in the range 0-255, the result must
divided by 255
-d[dr] = FAST_DIV255(d[dr] * (255 - alpha) + S[sr] *
alpha);
-d[dg] = FAST_DIV255(d[dg] * (255 - alpha) + S[sg] *
alpha);
-d[db] = FAST_DIV255(d[db] * (255 - alpha) + S[sb] *
alpha);
+d[dr] = is_straight ? FAST_DIV255(d[dr] * (255 - alpha) +
S[sr] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[dg] = is_straight ? FAST_DIV255(d[dg] * (255 - alpha) +
S[sg] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[db] = is_straight ? FAST_DIV255(d[db] * (255 - alpha) +
S[sb] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
}
if (main_has_alpha) {
switch (alpha) {
@@ -487,7 +489,9 @@ static av_always_inline void
blend_plane(AVFilterContext *ctx,
 int main_has_alpha,
 int dst_plane,
 int dst_offset,
- int dst_step)
+ int dst_step,
+ int straight,
+ int yuv)
{
int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
@@ -546,7 +550,14 @@ static av_always_inline void
blend_plane(AVFilterContext *ctx,
alpha_d = da[0];
alpha = UNPREMULTIPLY_ALPHA(alpha, alpha_d);
}
-*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+if (straight) {
+*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+} else {
+if (i && yuv)
+*d = av_clip(FAST_DIV255((*d - 128) * (255 - alpha))
+ *s - 128, -128, 128) + 128;
+else
+*d = FFMIN(FAST_DIV255(*d * (255 - alpha)) + *s,
255);
+}
s++;
d += dst_step;
da += 1 << hsub;
@@ -605,7 +616,8 @@ static av_always_inline void
blend_image_yuv(AVFilterContext *ctx,
 AVFrame *dst, const AVFrame
*src,
 int hsub, int vsub,
 int main_has_alpha,
- int x, int y)
+ int x, int y,
+   

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: add premultiplied alpha mode

2017-12-02 Thread Paul B Mahol
On 12/2/17, Marton Balint  wrote:
>
>
> On Sat, 2 Dec 2017, Paul B Mahol wrote:
>
>> On 12/2/17, Marton Balint  wrote:
>>>
>>>
>>> On Fri, 1 Dec 2017, Paul B Mahol wrote:
>>>
 Signed-off-by: Paul B Mahol 
 ---
 doc/filters.texi |   4 ++
 libavfilter/vf_overlay.c | 160
 ---
 2 files changed, 140 insertions(+), 24 deletions(-)

 diff --git a/doc/filters.texi b/doc/filters.texi
 index f7c371592f..0699728b7e 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -11328,6 +11328,10 @@ Default value is @samp{yuv420}.

 @item repeatlast
 See @ref{framesync}.
 +
 +@item alpha
 +Set format of alpha, it can be @var{straight} or @var{premultiplied}.
 +Default is @var{straight}.
 @end table
>>>
>>> Does this mean that not only overlay, but input and output is also
>>> considered as premultiplied? Maybe better to clarify this in the docs.
>>
>> I done it for overlay only alpha. For rest I'm little confused what needs
>> doing.
>
> Ok, then just write in the docs:
>
> "Set format of alpha of the overlaid video."

Fixed locally, thanks!

>
>>
>>>
>>> Have you measured the slowdown caused by the extra condition in the pixel
>>> blending code? If it is more than 1-2%, then some DEFINE magic (or
>>> making the blend_image functions inline?) would be better IMHO.
>>
>> It should already be inlined. Thats why there are so many functions.
>
> Not all of them, blend_image_packed_rgb misses an av_always_inline.
>

Fixed locally, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: add premultiplied alpha mode

2017-12-02 Thread Marton Balint



On Fri, 1 Dec 2017, Paul B Mahol wrote:


Signed-off-by: Paul B Mahol 
---
doc/filters.texi |   4 ++
libavfilter/vf_overlay.c | 160 ---
2 files changed, 140 insertions(+), 24 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index f7c371592f..0699728b7e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11328,6 +11328,10 @@ Default value is @samp{yuv420}.

@item repeatlast
See @ref{framesync}.
+
+@item alpha
+Set format of alpha, it can be @var{straight} or @var{premultiplied}.
+Default is @var{straight}.
@end table


Does this mean that not only overlay, but input and output is also 
considered as premultiplied? Maybe better to clarify this in the docs.


Have you measured the slowdown caused by the extra condition in the pixel 
blending code? If it is more than 1-2%, then some DEFINE magic (or 
making the blend_image functions inline?) would be better IMHO.


Regards,
Marton



The @option{x}, and @option{y} expressions can contain the following
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 5bf3d66cf1..8206dae454 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -109,6 +109,7 @@ typedef struct OverlayContext {
uint8_t overlay_rgba_map[4];
uint8_t overlay_has_alpha;
int format; ///< OverlayFormat
+int alpha_format;
int eval_mode;  ///< EvalMode

FFFrameSync fs;
@@ -403,7 +404,8 @@ static int config_output(AVFilterLink *outlink)

static void blend_image_packed_rgb(AVFilterContext *ctx,
   AVFrame *dst, const AVFrame *src,
-   int main_has_alpha, int x, int y)
+   int main_has_alpha, int x, int y,
+   int is_straight)
{
OverlayContext *s = ctx->priv;
int i, imax, j, jmax;
@@ -454,9 +456,9 @@ static void blend_image_packed_rgb(AVFilterContext *ctx,
default:
// main_value = main_value * (1 - alpha) + overlay_value * alpha
// since alpha is in the range 0-255, the result must divided 
by 255
-d[dr] = FAST_DIV255(d[dr] * (255 - alpha) + S[sr] * alpha);
-d[dg] = FAST_DIV255(d[dg] * (255 - alpha) + S[sg] * alpha);
-d[db] = FAST_DIV255(d[db] * (255 - alpha) + S[sb] * alpha);
+d[dr] = is_straight ? FAST_DIV255(d[dr] * (255 - alpha) + 
S[sr] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[dg] = is_straight ? FAST_DIV255(d[dg] * (255 - alpha) + 
S[sg] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[db] = is_straight ? FAST_DIV255(d[db] * (255 - alpha) + 
S[sb] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
}
if (main_has_alpha) {
switch (alpha) {
@@ -487,7 +489,9 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
 int main_has_alpha,
 int dst_plane,
 int dst_offset,
- int dst_step)
+ int dst_step,
+ int straight,
+ int yuv)
{
int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
@@ -546,7 +550,14 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
alpha_d = da[0];
alpha = UNPREMULTIPLY_ALPHA(alpha, alpha_d);
}
-*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+if (straight) {
+*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+} else {
+if (i && yuv)
+*d = av_clip(FAST_DIV255((*d - 128) * (255 - alpha)) + *s 
- 128, -128, 128) + 128;
+else
+*d = FFMIN(FAST_DIV255(*d * (255 - alpha)) + *s, 255);
+}
s++;
d += dst_step;
da += 1 << hsub;
@@ -605,7 +616,8 @@ static av_always_inline void 
blend_image_yuv(AVFilterContext *ctx,
 AVFrame *dst, const AVFrame *src,
 int hsub, int vsub,
 int main_has_alpha,
- int x, int y)
+ int x, int y,
+ int is_straight)
{
OverlayContext *s = ctx->priv;
const int src_w = src->width;
@@ -614,11 +626,11 @@ static av_always_inline void 
blend_image_yuv(AVFilterContext *ctx,
const int dst_h = dst->height;

blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,   0, x, y, 
main_has_alpha,
-

Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread Marton Balint



On Thu, 30 Nov 2017, John Stebbins wrote:


Used by movenc to fill sdtp box
---
libavcodec/libx265.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..c137fe4ae1 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -329,6 +329,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
FF_ENABLE_DEPRECATION_WARNINGS
#endif

+if (x265pic_out.sliceType == X265_TYPE_B)
+pkt->flags |= AV_PKT_FLAG_DISPOSABLE;


You can only set this for B pictures which are not referenced by other 
frames, no? Otherwise they can't be dropped independently from the others.


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


Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: add premultiplied alpha mode

2017-12-02 Thread Paul B Mahol
On 12/2/17, Marton Balint  wrote:
>
>
> On Fri, 1 Dec 2017, Paul B Mahol wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>> doc/filters.texi |   4 ++
>> libavfilter/vf_overlay.c | 160
>> ---
>> 2 files changed, 140 insertions(+), 24 deletions(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index f7c371592f..0699728b7e 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -11328,6 +11328,10 @@ Default value is @samp{yuv420}.
>>
>> @item repeatlast
>> See @ref{framesync}.
>> +
>> +@item alpha
>> +Set format of alpha, it can be @var{straight} or @var{premultiplied}.
>> +Default is @var{straight}.
>> @end table
>
> Does this mean that not only overlay, but input and output is also
> considered as premultiplied? Maybe better to clarify this in the docs.

I done it for overlay only alpha. For rest I'm little confused what needs doing.

>
> Have you measured the slowdown caused by the extra condition in the pixel
> blending code? If it is more than 1-2%, then some DEFINE magic (or
> making the blend_image functions inline?) would be better IMHO.

It should already be inlined. Thats why there are so many functions.

>
> Regards,
> Marton
>
>>
>> The @option{x}, and @option{y} expressions can contain the following
>> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
>> index 5bf3d66cf1..8206dae454 100644
>> --- a/libavfilter/vf_overlay.c
>> +++ b/libavfilter/vf_overlay.c
>> @@ -109,6 +109,7 @@ typedef struct OverlayContext {
>> uint8_t overlay_rgba_map[4];
>> uint8_t overlay_has_alpha;
>> int format; ///< OverlayFormat
>> +int alpha_format;
>> int eval_mode;  ///< EvalMode
>>
>> FFFrameSync fs;
>> @@ -403,7 +404,8 @@ static int config_output(AVFilterLink *outlink)
>>
>> static void blend_image_packed_rgb(AVFilterContext *ctx,
>>AVFrame *dst, const AVFrame *src,
>> -   int main_has_alpha, int x, int y)
>> +   int main_has_alpha, int x, int y,
>> +   int is_straight)
>> {
>> OverlayContext *s = ctx->priv;
>> int i, imax, j, jmax;
>> @@ -454,9 +456,9 @@ static void blend_image_packed_rgb(AVFilterContext
>> *ctx,
>> default:
>> // main_value = main_value * (1 - alpha) + overlay_value *
>> alpha
>> // since alpha is in the range 0-255, the result must
>> divided by 255
>> -d[dr] = FAST_DIV255(d[dr] * (255 - alpha) + S[sr] *
>> alpha);
>> -d[dg] = FAST_DIV255(d[dg] * (255 - alpha) + S[sg] *
>> alpha);
>> -d[db] = FAST_DIV255(d[db] * (255 - alpha) + S[sb] *
>> alpha);
>> +d[dr] = is_straight ? FAST_DIV255(d[dr] * (255 - alpha) +
>> S[sr] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
>> +d[dg] = is_straight ? FAST_DIV255(d[dg] * (255 - alpha) +
>> S[sg] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
>> +d[db] = is_straight ? FAST_DIV255(d[db] * (255 - alpha) +
>> S[sb] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
>> }
>> if (main_has_alpha) {
>> switch (alpha) {
>> @@ -487,7 +489,9 @@ static av_always_inline void
>> blend_plane(AVFilterContext *ctx,
>>  int main_has_alpha,
>>  int dst_plane,
>>  int dst_offset,
>> - int dst_step)
>> + int dst_step,
>> + int straight,
>> + int yuv)
>> {
>> int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
>> int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
>> @@ -546,7 +550,14 @@ static av_always_inline void
>> blend_plane(AVFilterContext *ctx,
>> alpha_d = da[0];
>> alpha = UNPREMULTIPLY_ALPHA(alpha, alpha_d);
>> }
>> -*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
>> +if (straight) {
>> +*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
>> +} else {
>> +if (i && yuv)
>> +*d = av_clip(FAST_DIV255((*d - 128) * (255 - alpha))
>> + *s - 128, -128, 128) + 128;
>> +else
>> +*d = FFMIN(FAST_DIV255(*d * (255 - alpha)) + *s,
>> 255);
>> +}
>> s++;
>> d += dst_step;
>> da += 1 << hsub;
>> @@ -605,7 +616,8 @@ static av_always_inline void
>> blend_image_yuv(AVFilterContext *ctx,
>>  AVFrame *dst, const AVFrame
>> *src,
>>  int hsub, int vsub,
>>  int main_has_alpha,

Re: [FFmpeg-devel] [PATCHv2] avformat/mxfdec: fix last packet timestamps

2017-12-02 Thread Marton Balint


On Fri, 24 Nov 2017, Marton Balint wrote:


The current edit unit cannot be reliably determined for the last packet of a
video stream, because we can't query the start offset of the next edit unit
from the index. This caused missing timestamps for the last video packet.

Therefore from now on, we allow setting the PTS even if we are not sure of the
current edit unit if mxf_set_current_edit_unit returned a specific failure, and
the assumed current edit unit is the last.

Fixes last packet timestamp of:
ffprobe -fflags nofillin -show_packets tests/data/lavf/lavf.mxf -select_streams 
v



Ping, will apply soon.

Regards,
Marton


Signed-off-by: Marton Balint 
---
libavformat/mxfdec.c|  4 ++--
tests/ref/seek/lavf-mxf_d10 | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 118e3e40b4..3b8d423906 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2976,7 +2976,7 @@ static int64_t mxf_set_current_edit_unit(MXFContext *mxf, 
int64_t current_offset
/* find mxf->current_edit_unit so that the next edit unit starts ahead of 
current_offset */
while (mxf->current_edit_unit >= 0) {
if (mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit + 1, NULL, 
_ofs, 0) < 0)
-return -1;
+return -2;

if (next_ofs <= last_ofs) {
/* large next_ofs didn't change or current_edit_unit wrapped
@@ -3065,7 +3065,7 @@ static int mxf_set_pts(MXFContext *mxf, AVStream *st, 
AVPacket *pkt, int64_t nex
AVCodecParameters *par = st->codecpar;
MXFTrack *track = st->priv_data;

-if (par->codec_type == AVMEDIA_TYPE_VIDEO && next_ofs >= 0) {
+if (par->codec_type == AVMEDIA_TYPE_VIDEO && (next_ofs >= 0 || next_ofs == -2 && 
st->duration == mxf->current_edit_unit + 1)) {
/* mxf->current_edit_unit good - see if we have an
 * index table to derive timestamps from */
MXFIndexTable *t = >index_tables[0];
diff --git a/tests/ref/seek/lavf-mxf_d10 b/tests/ref/seek/lavf-mxf_d10
index 17cca29c03..5a682f0927 100644
--- a/tests/ref/seek/lavf-mxf_d10
+++ b/tests/ref/seek/lavf-mxf_d10
@@ -8,9 +8,9 @@ ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 
pos:4265984 size:15
ret: 0 st: 0 flags:1  ts:-0.32
ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 size:15
ret: 0 st: 1 flags:0  ts: 2.576667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st: 1 flags:1  ts: 1.470833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st:-1 flags:0  ts: 0.365002
ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos:1923072 size:15
ret: 0 st:-1 flags:1  ts:-0.740831
@@ -22,7 +22,7 @@ ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 
pos:5117952 size:15
ret: 0 st: 1 flags:0  ts:-0.058333
ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 size:15
ret: 0 st: 1 flags:1  ts: 2.835833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st:-1 flags:0  ts: 1.730004
ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 size:15
ret: 0 st:-1 flags:1  ts: 0.624171
@@ -32,7 +32,7 @@ ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 
  6144 size:15
ret: 0 st: 0 flags:1  ts: 2.40
ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 size:15
ret: 0 st: 1 flags:0  ts: 1.306667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st: 1 flags:1  ts: 0.200833
ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos:1071104 size:15
ret: 0 st:-1 flags:0  ts:-0.904994
@@ -44,9 +44,9 @@ ret: 0 st: 0 flags:1 dts: 0.88 pts: 0.88 
pos:4691968 size:15
ret: 0 st: 0 flags:1  ts:-0.24
ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 size:15
ret: 0 st: 1 flags:0  ts: 2.671667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st: 1 flags:1  ts: 1.565833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
ret: 0 st:-1 flags:0  ts: 0.460008
ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos:2562048 size:15
ret: 0 st:-1 flags:1  

Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD

2017-12-02 Thread Paul B Mahol
On 12/2/17, James Almer  wrote:
> On 12/1/2017 3:41 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavfilter/threshold.h | 51 +++
>>  libavfilter/vf_threshold.c  | 28 ---
>>  libavfilter/x86/Makefile|  2 ++
>>  libavfilter/x86/vf_threshold.asm| 69
>> +
>>  libavfilter/x86/vf_threshold_init.c | 41 ++
>>  5 files changed, 169 insertions(+), 22 deletions(-)
>>  create mode 100644 libavfilter/threshold.h
>>  create mode 100644 libavfilter/x86/vf_threshold.asm
>>  create mode 100644 libavfilter/x86/vf_threshold_init.c
>
> [..]
>
>> diff --git a/libavfilter/x86/vf_threshold_init.c
>> b/libavfilter/x86/vf_threshold_init.c
>> new file mode 100644
>> index 00..e2bbae11d5
>> --- /dev/null
>> +++ b/libavfilter/x86/vf_threshold_init.c
>> @@ -0,0 +1,41 @@
>> +/*
>> + * Copyright (c) 2015 Paul B Mahol
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> + */
>> +
>> +#include "libavutil/attributes.h"
>> +#include "libavutil/cpu.h"
>> +#include "libavutil/x86/cpu.h"
>> +#include "libavfilter/threshold.h"
>> +
>> +void ff_threshold8_sse4(const uint8_t *in, const uint8_t *threshold,
>> +const uint8_t *min, const uint8_t *max,
>> +uint8_t *out,
>> +ptrdiff_t ilinesize, ptrdiff_t tlinesize,
>> +ptrdiff_t flinesize, ptrdiff_t slinesize,
>> +ptrdiff_t olinesize,
>> +int w, int h);
>> +
>> +av_cold void ff_threshold_init_x86(ThresholdContext *s)
>> +{
>> +int cpu_flags = av_get_cpu_flags();
>> +
>> +if (ARCH_X86_64 && EXTERNAL_SSE4(cpu_flags) && s->depth == 8) {
>> +s->threshold = ff_threshold8_sse4;
>> +}
>> +}
>>
>
> Can you add a checkasm test for this function, or at least a normal test
> for the filter that covers it?

Yes, i can add it later. Is it ready for push?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

2017-12-02 Thread James Darnley
On 2017-11-27 17:50, Henrik Gramner wrote:
> On Sun, Nov 26, 2017 at 11:51 PM, James Darnley  
> wrote:
>> -pd_0_int_min: times  2 dd 0, -2147483648
>> -pq_int_min:   times  2 dq -2147483648
>> -pq_int_max:   times  2 dq  2147483647
>> +pd_0_int_min: times  4 dd 0, -2147483648
>> +pq_int_min:   times  4 dq -2147483648
>> +pq_int_max:   times  4 dq  2147483647
> 
> Using 128-bit broadcasts is preferable over duplicating the constants
> to 256-bit unless there's a good reason for doing so since it wastes
> less cache and is faster on AMD CPU:s.

At first I  thought it sounded like a possible candidate for x86-64
optimisation; I have run out of registers on x86.  Although that is in
the inner loop and these constants used in the outer loop or just once
so I have some room.

Do you want to block the patch set while I change this or could it be
left for another time?

Thanks for the suggestion anyway.




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


Re: [FFmpeg-devel] [PATCH 3/3] avformat/dashenc: add avpriv_io_move return value check

2017-12-02 Thread Moritz Barsnick
On Sat, Dec 02, 2017 at 10:44:02 +0800, Steven Liu wrote:
> +av_log(os->ctx, AV_LOG_WARNING, "rename file from %s to %s 
> faild\n", temp_filename_hls, filename_hls);
^ renaming^ 
failed

Perhaps just "renaming file %s to %s failed\n".

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


Re: [FFmpeg-devel] [PATCH 1/2] vaapi_h264: Add named options for setting profile and level

2017-12-02 Thread Mark Thompson
On 01/12/17 05:24, Li, Zhong wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Moritz Barsnick
>> Sent: Thursday, November 30, 2017 10:33 PM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] vaapi_h264: Add named options for
>> setting profile and level
>>
>> On Thu, Nov 30, 2017 at 08:52:21 +, Li, Zhong wrote:
 +{ LEVEL("6",   60) },
 +{ LEVEL("6.1", 61) },
 +{ LEVEL("6.2", 62) },
>>>
>>> IIRC, level 5.2 is the maximum level of H264?
>>
>> Higher levels were introduced in 2016. Edition V12 of H.264 lists 6,
>> 6.1 and 6.2 in Annex A, Table A-1. It basically lists the same thing as
>> Wikipedia:
>> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
> 
> Exactly.
To clarify, are you happy with this patch and the matching one for H.265 now?

Thanks,

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


Re: [FFmpeg-devel] [PATCH] Fix for ticket 6796 (ffprobe show_frames ts dvbsubs infinate loop)

2017-12-02 Thread Michael Niedermayer
On Sat, Dec 02, 2017 at 12:42:22AM +, Colin NG wrote:
> ---
>  fftools/ffprobe.c  |  2 ++
>  libavcodec/dvbsubdec.c | 10 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)

This should be split in 2 patches
one for the lib and one for the application

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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/6] lavc/libx265: mark disposable frames

2017-12-02 Thread Carl Eugen Hoyos
2017-12-02 18:51 GMT+01:00 James Almer :
> On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
>> 2017-12-02 18:37 GMT+01:00 John Stebbins :
>>> That should be done, or I should add back support for earlier versions.
>>> Is there any desire by anyone to keep support for earlier versions?
>>
>> How old is 2.5, is 2.4 used by current versions of distributions?
>> (How ugly is the support for earlier versions?)
>
> It's four months old, and rolling release distros are using it and will
> move on to 2.6 soon.
>
> By the time non rolling release distros switch to ffmpeg > 3.4, they
> will also switch to whatever is newest for x265 at the time.

I was mostly thinking about users who build FFmpeg by themselves
on current distributions. (And about developers who like to test on
vanilla systems.)

Four months seem not a lot to me.

(I believe it is impossible that your criteria ever fails.)

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


Re: [FFmpeg-devel] avcodec/x86/lossless_videodsp : add_left_pred AVX2 v2

2017-12-02 Thread Martin Vignali
New patch in attach

001, 002 : unchanged

003 : use VBROADCASTI128 macro for constant loading en XMM/YMM instead of
256 bits constants.

Martin


0001-checkasm-llviddsp-test-return-of-add_left_pred-16.patch
Description: Binary data


0002-avcodec-x86-lossless_videodsp.asm-make-macro-for.patch
Description: Binary data


0003-avcodec-x86-lossless_videodsp-add-avx2-version-for.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD

2017-12-02 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/hflip.h |  38 
 libavfilter/vf_hflip.c  | 131 ++--
 libavfilter/x86/Makefile|   2 +
 libavfilter/x86/vf_hflip.asm|  92 
 libavfilter/x86/vf_hflip_init.c |  41 +
 5 files changed, 257 insertions(+), 47 deletions(-)
 create mode 100644 libavfilter/hflip.h
 create mode 100644 libavfilter/x86/vf_hflip.asm
 create mode 100644 libavfilter/x86/vf_hflip_init.c

diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
new file mode 100644
index 00..138380427c
--- /dev/null
+++ b/libavfilter/hflip.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2007 Benoit Fouet
+ * Copyright (c) 2010 Stefano Sabatini
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_HFLIP_H
+#define AVFILTER_HFLIP_H
+
+#include "avfilter.h"
+
+typedef struct FlipContext {
+const AVClass *class;
+int max_step[4];///< max pixel step for each plane, expressed as a 
number of bytes
+int planewidth[4];  ///< width of each plane
+int planeheight[4]; ///< height of each plane
+
+void (*flip_line[4])(const uint8_t *src, uint8_t *dst, int w);
+} FlipContext;
+
+void ff_hflip_init_x86(FlipContext *s, int step[4]);
+
+#endif /* AVFILTER_HFLIP_H */
diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
index cf20c193f7..303cc8af60 100644
--- a/libavfilter/vf_hflip.c
+++ b/libavfilter/vf_hflip.c
@@ -29,6 +29,7 @@
 #include "libavutil/opt.h"
 #include "avfilter.h"
 #include "formats.h"
+#include "hflip.h"
 #include "internal.h"
 #include "video.h"
 #include "libavutil/pixdesc.h"
@@ -36,13 +37,6 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
 
-typedef struct FlipContext {
-const AVClass *class;
-int max_step[4];///< max pixel step for each plane, expressed as a 
number of bytes
-int planewidth[4];  ///< width of each plane
-int planeheight[4]; ///< height of each plane
-} FlipContext;
-
 static const AVOption hflip_options[] = {
 { NULL }
 };
@@ -67,12 +61,77 @@ static int query_formats(AVFilterContext *ctx)
 return ff_set_common_formats(ctx, pix_fmts);
 }
 
+static void hflip_byte_c(const uint8_t *src, uint8_t *dst, int w)
+{
+int j;
+
+for (j = 0; j < w; j++)
+dst[j] = src[-j];
+}
+
+static void hflip_short_c(const uint8_t *ssrc, uint8_t *ddst, int w)
+{
+const uint16_t *src = (const uint16_t *)ssrc;
+uint16_t *dst = (uint16_t *)ddst;
+int j;
+
+for (j = 0; j < w; j++)
+dst[j] = src[-j];
+}
+
+static void hflip_dword_c(const uint8_t *ssrc, uint8_t *ddst, int w)
+{
+const uint32_t *src = (const uint32_t *)ssrc;
+uint32_t *dst = (uint32_t *)ddst;
+int j;
+
+for (j = 0; j < w; j++)
+dst[j] = src[-j];
+}
+
+static void hflip_b24_c(const uint8_t *src, uint8_t *dst, int w)
+{
+const uint8_t *in  = src;
+uint8_t *out = dst;
+int j;
+
+for (j = 0; j < w; j++, out += 3, in -= 3) {
+int32_t v = AV_RB24(in);
+
+AV_WB24(out, v);
+}
+}
+
+static void hflip_b48_c(const uint8_t *src, uint8_t *dst, int w)
+{
+const uint8_t *in  = src;
+uint8_t *out = dst;
+int j;
+
+for (j = 0; j < w; j++, out += 6, in -= 6) {
+int64_t v = AV_RB48(in);
+
+AV_WB48(out, v);
+}
+}
+
+static void hflip_qword_c(const uint8_t *ssrc, uint8_t *ddst, int w)
+{
+const uint64_t *src = (const uint64_t *)ssrc;
+uint64_t *dst = (uint64_t *)ddst;
+int j;
+
+for (j = 0; j < w; j++)
+dst[j] = src[-j];
+}
+
 static int config_props(AVFilterLink *inlink)
 {
 FlipContext *s = inlink->dst->priv;
 const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
 const int hsub = pix_desc->log2_chroma_w;
 const int vsub = pix_desc->log2_chroma_h;
+int i;
 
 av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
 s->planewidth[0]  = s->planewidth[3]  = inlink->w;
@@ -80,6 +139,22 @@ static int config_props(AVFilterLink *inlink)
 s->planeheight[0] = s->planeheight[3] = inlink->h;
 s->planeheight[1] = s->planeheight[2] = AV_CEIL_RSHIFT(inlink->h, vsub);
 
+for (i = 0; i < 4; i++) {
+switch 

[FFmpeg-devel] [PATCH 1/4] libavutil: Add saturating subtraction functions

2017-12-02 Thread Andrew D'Addesio
Add av_sat_sub32 and av_sat_dsub32 as the subtraction analogues to
av_sat_add32/av_sat_dadd32.

Also clarify the formulas for dadd32/dsub32.

Signed-off-by: Andrew D'Addesio 
---
 libavutil/arm/intmath.h | 16 
 libavutil/common.h  | 32 +++-
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/libavutil/arm/intmath.h b/libavutil/arm/intmath.h
index 65e42c5..5311a7d 100644
--- a/libavutil/arm/intmath.h
+++ b/libavutil/arm/intmath.h
@@ -94,6 +94,22 @@ static av_always_inline int av_sat_dadd32_arm(int a, int b)
 return r;
 }
 
+#define av_sat_sub32 av_sat_sub32_arm
+static av_always_inline int av_sat_sub32_arm(int a, int b)
+{
+int r;
+__asm__ ("qsub %0, %1, %2" : "=r"(r) : "r"(a), "r"(b));
+return r;
+}
+
+#define av_sat_dsub32 av_sat_dsub32_arm
+static av_always_inline int av_sat_dsub32_arm(int a, int b)
+{
+int r;
+__asm__ ("qdsub %0, %1, %2" : "=r"(r) : "r"(a), "r"(b));
+return r;
+}
+
 #endif /* HAVE_ARMV6_INLINE */
 
 #if HAVE_ASM_MOD_Q
diff --git a/libavutil/common.h b/libavutil/common.h
index 8142b31..5e03828 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -260,13 +260,37 @@ static av_always_inline int av_sat_add32_c(int a, int b)
  *
  * @param  a first value
  * @param  b value doubled and added to a
- * @return sum with signed saturation
+ * @return sum sat(a + sat(2*b)) with signed saturation
  */
 static av_always_inline int av_sat_dadd32_c(int a, int b)
 {
 return av_sat_add32(a, av_sat_add32(b, b));
 }
 
+/**
+ * Subtract two signed 32-bit values with saturation.
+ *
+ * @param  a one value
+ * @param  b another value
+ * @return difference with signed saturation
+ */
+static av_always_inline int av_sat_sub32_c(int a, int b)
+{
+return av_clipl_int32((int64_t)a - b);
+}
+
+/**
+ * Subtract a doubled value from another value with saturation at both stages.
+ *
+ * @param  a first value
+ * @param  b value doubled and subtracted from a
+ * @return difference sat(a - sat(2*b)) with signed saturation
+ */
+static av_always_inline int av_sat_dsub32_c(int a, int b)
+{
+return av_sat_sub32(a, av_sat_add32(b, b));
+}
+
 /**
  * Clip a float value into the amin-amax range.
  * @param a value to clip
@@ -513,6 +537,12 @@ static av_always_inline av_const int av_parity_c(uint32_t 
v)
 #ifndef av_sat_dadd32
 #   define av_sat_dadd32av_sat_dadd32_c
 #endif
+#ifndef av_sat_sub32
+#   define av_sat_sub32 av_sat_sub32_c
+#endif
+#ifndef av_sat_dsub32
+#   define av_sat_dsub32av_sat_dsub32_c
+#endif
 #ifndef av_clipf
 #   define av_clipf av_clipf_c
 #endif
-- 
2.15.1.windows.2

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


[FFmpeg-devel] [PATCH 2/4] opus: Fix arithmetic overflows (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
The relevant sections from the RFC are:

Sec.6. Integer Wrap-Around in Inverse Gain Computation
32-bit integer overflow in Levinson recursion. Affects
silk_is_lpc_stable().

Sec.8. Cap on Band Energy
NaN due to large log-energy value. Affects celt_denormalize().

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_celt.c |  3 ++-
 libavcodec/opus_silk.c | 11 +--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index 84d4847..ff56041 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -481,7 +481,8 @@ static void celt_denormalize(CeltFrame *f, CeltBlock 
*block, float *data)
 
 for (i = f->start_band; i < f->end_band; i++) {
 float *dst = data + (ff_celt_freq_bands[i] << f->size);
-float norm = exp2f(block->energy[i] + ff_celt_mean_energy[i]);
+float log_norm = block->energy[i] + ff_celt_mean_energy[i];
+float norm = exp2f(FFMIN(log_norm, 32.0f));
 
 for (j = 0; j < ff_celt_freq_range[i] << f->size; j++)
 dst[j] *= norm;
diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index 3c9c849..344333c 100644
--- a/libavcodec/opus_silk.c
+++ b/libavcodec/opus_silk.c
@@ -185,8 +185,15 @@ static inline int silk_is_lpc_stable(const int16_t 
lpc[16], int order)
 row = lpc32[k & 1];
 
 for (j = 0; j < k; j++) {
-int x = prevrow[j] - ROUND_MULL(prevrow[k - j - 1], rc, 31);
-row[j] = ROUND_MULL(x, gain, fbits);
+int x = av_sat_sub32(prevrow[j], ROUND_MULL(prevrow[k - j - 1], 
rc, 31));
+int64_t tmp = ROUND_MULL(x, gain, fbits);
+
+/* per RFC 8251 section 6, if this calculation overflows, the 
filter
+   is considered unstable. */
+if (tmp < INT32_MIN || tmp > INT32_MAX)
+return 0;
+
+row[j] = (int32_t)tmp;
 }
 }
 }
-- 
2.15.1.windows.2

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


[FFmpeg-devel] [PATCH 3/4] opus: Add Special Hybrid Folding (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
This decoder-side change, introduced in RFC 8251 (section 9), slightly
improves the decoded quality of 16kbps speech in Hybrid Mode.

Differences can be seen/heard in testvector05.bit, testvector06.bit,
and testvector12.bit in the RFC 6716/8251 testvectors found here:
https://people.xiph.org/~greg/opus_testvectors/

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_celt.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index ff56041..2bbb96b 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -712,10 +712,22 @@ static void celt_decode_bands(CeltFrame *f, 
OpusRangeCoder *rc)
 b = av_clip_uintp2(FFMIN(f->remaining2 + 1, f->pulses[i] + 
curr_balance), 14);
 }
 
-if (ff_celt_freq_bands[i] - ff_celt_freq_range[i] >= 
ff_celt_freq_bands[f->start_band] &&
-(update_lowband || lowband_offset == 0))
+if ((ff_celt_freq_bands[i] - ff_celt_freq_range[i] >= 
ff_celt_freq_bands[f->start_band] ||
+i == f->start_band + 1) && (update_lowband || lowband_offset == 0))
 lowband_offset = i;
 
+if (i == f->start_band + 1) {
+/* Special Hybrid Folding (RFC 8251 section 9). Copy the first 
band into
+the second to ensure the second band never has to use the LCG. */
+int offset = 8 * ff_celt_freq_bands[i];
+int count = 8 * (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]);
+
+memcpy([offset], [offset - count], count * 
sizeof(float));
+
+if (f->channels == 2)
+memcpy([offset], [offset - count], count * 
sizeof(float));
+}
+
 /* Get a conservative estimate of the collapse_mask's for the bands 
we're
going to be folding from. */
 if (lowband_offset != 0 && (f->spread != CELT_SPREAD_AGGRESSIVE ||
@@ -728,7 +740,7 @@ static void celt_decode_bands(CeltFrame *f, OpusRangeCoder 
*rc)
 foldstart = lowband_offset;
 while (ff_celt_freq_bands[--foldstart] > effective_lowband);
 foldend = lowband_offset - 1;
-while (ff_celt_freq_bands[++foldend] < effective_lowband + 
ff_celt_freq_range[i]);
+while (++foldend < i && ff_celt_freq_bands[foldend] < 
effective_lowband + ff_celt_freq_range[i]);
 
 cm[0] = cm[1] = 0;
 for (j = foldstart; j < foldend; j++) {
-- 
2.15.1.windows.2

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


[FFmpeg-devel] [PATCH 4/4] opus: Don't invert phase when downmixing to mono (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
When decoding to downmixed mono, don't put the channels out of phase,
as they will cancel out and create audible artifacts. (See
RFC 8251 sec. 10.)

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_pvq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2f7aa74..f18c010 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -643,7 +643,13 @@ static av_always_inline uint32_t 
quant_band_template(CeltPVQ *pvq, CeltFrame *f,
 }
 } else {
 inv = (b > 2 << 3 && f->remaining2 > 2 << 3) ? 
ff_opus_rc_dec_log(rc, 2) : 0;
+
+/* Don't put the channels out of phase if we are decoding to 
downmixed
+ * mono as this subjectively sounds bad (RFC 8251 section 10). 
*/
+if (f->channels == 1)
+inv = 0;
 }
+
 itheta = 0;
 }
 qalloc = opus_rc_tell_frac(rc) - tell;
-- 
2.15.1.windows.2

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


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread James Almer
On 12/2/2017 2:37 PM, John Stebbins wrote:
> On 12/02/2017 09:25 AM, James Almer wrote:
>> On 12/2/2017 1:52 PM, John Stebbins wrote:
>>> On 12/02/2017 01:40 AM, Marton Balint wrote:
 On Thu, 30 Nov 2017, John Stebbins wrote:

> Used by movenc to fill sdtp box
> ---
> libavcodec/libx265.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 4456e300f2..c137fe4ae1 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -329,6 +329,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
>
> +if (x265pic_out.sliceType == X265_TYPE_B)
> +pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
 You can only set this for B pictures which are not referenced by other 
 frames, no? Otherwise they can't be dropped independently from the others.


>>> Correct.  x265 version 2.5 and above returns X265_TYPE_BREF for frames that 
>>> are referenced.  There is a way to
>>> distinguish on version 2.4 and below as well using 
>>> x265pic_out.frameData.sliceType, and an earlier version of my patch
>>> used that.  But it's really not the "right" way going forward.  I can 
>>> restore it if supporting earlier versions of x265
>>> is important.  But my feeling with such fast moving projects as x265 is 
>>> it's best not to keep too much cruft in support
>>> of old versions.
>> You can bump the minimum required version. Just make the necessary
>> changes in configure.
>>
> 
> Ah, good point.  That should be done, or I should add back support for 
> earlier versions.  Is there any desire by anyone
> to keep support for earlier versions?

No, 2.5 is not even the most recent version, so it's fine as the minimum
supported version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.

2017-12-02 Thread Michael Niedermayer
On Fri, Dec 01, 2017 at 11:16:37AM -0800, Dale Curtis wrote:
> On Thu, Nov 30, 2017 at 5:49 PM, Michael Niedermayer  > wrote:
> 
> > I dont see anything really wrong with the file
> >
> 
> For kicks, I tried running it through oggz-validate, but it doesn't know
> how to handle ogm. Which TIL, is distinct from ogv.
> 
> 
> >
> > it seems what happens is that theres a data packet in one stream that
> > preceeds the headers on the other streams, technically that data packet
> > likely contains the video headers so its kind of a header too.
> >
> > The demuxer stops header parsing prematurly due to this.
> > from there on it gets confused reading the same header twice
> > while it determines the duration of the file which triggers the error
> >
> > There are a few differnt ways to fix this, iam not sure which is the
> > simplest but i dont think the demuxer should fail in this case
> >
> >
> Applying a workaround similar to what you did here works:
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c04c43b3e423d0426162828e7b180e4d0014a3f7
> 
> I.e. condition AVERROR_INVALIDATA based on priv->vp being incomplete here:
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/oggparsevorbis.c;h=65b1998a02d92d0fcaeb740d8f4523641502dbea;hb=HEAD#l319
> 
> WDYT? Here's a patch to do this and fail on AVERROR w/o the AV_EF_EXPLODE
> restriction.

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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


Re: [FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD

2017-12-02 Thread Paul B Mahol
On 12/2/17, Martin Vignali  wrote:
>> +
>> +%include "libavutil/x86/x86util.asm"
>> +
>> +SECTION_RODATA
>> +
>> +pb_flip_byte:  times 16 db 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0
>> +pb_flip_short: times 16 db 14,15,12,13,10,11,8,9,6,7,4,5,2,3,0,1
>> +
>>
>
> times 16 ?

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


Re: [FFmpeg-devel] [PATCH] rtsp: only break on parse_rtsp_message on error

2017-12-02 Thread Michael Niedermayer
On Fri, Dec 01, 2017 at 04:09:15PM -0500, Tristan Matthews wrote:
> Fix suggested by Luca Barbato.
> 
> This was causing spurious EOFs when using -rtsp_transport udp, as
> reported in https://bugzilla.libav.org/show_bug.cgi?id=1103
> ---
>  libavformat/rtsp.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

where is the code which interprets 0 as EOF ?
also nicolas may want to look at this, he was working on EOF vs 0 issues
(thus ccing nicolas)

thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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/6] lavc/libx265: mark disposable frames

2017-12-02 Thread John Stebbins
On 12/02/2017 09:25 AM, James Almer wrote:
> On 12/2/2017 1:52 PM, John Stebbins wrote:
>> On 12/02/2017 01:40 AM, Marton Balint wrote:
>>> On Thu, 30 Nov 2017, John Stebbins wrote:
>>>
 Used by movenc to fill sdtp box
 ---
 libavcodec/libx265.c | 3 +++
 1 file changed, 3 insertions(+)

 diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
 index 4456e300f2..c137fe4ae1 100644
 --- a/libavcodec/libx265.c
 +++ b/libavcodec/libx265.c
 @@ -329,6 +329,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif

 +if (x265pic_out.sliceType == X265_TYPE_B)
 +pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
>>> You can only set this for B pictures which are not referenced by other 
>>> frames, no? Otherwise they can't be dropped independently from the others.
>>>
>>>
>> Correct.  x265 version 2.5 and above returns X265_TYPE_BREF for frames that 
>> are referenced.  There is a way to
>> distinguish on version 2.4 and below as well using 
>> x265pic_out.frameData.sliceType, and an earlier version of my patch
>> used that.  But it's really not the "right" way going forward.  I can 
>> restore it if supporting earlier versions of x265
>> is important.  But my feeling with such fast moving projects as x265 is it's 
>> best not to keep too much cruft in support
>> of old versions.
> You can bump the minimum required version. Just make the necessary
> changes in configure.
>

Ah, good point.  That should be done, or I should add back support for earlier 
versions.  Is there any desire by anyone
to keep support for earlier versions?

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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


Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

2017-12-02 Thread Martin Vignali
2017-12-02 13:13 GMT+01:00 Henrik Gramner :

> On Fri, Dec 1, 2017 at 9:03 PM, Martin Vignali 
> wrote:
> > If no one have objections, i will push these patch tomorrow.
> >
> > Martin
>
> Follow James' suggestion to use >16 instead of ==32, otherwise OK.
>

Pushed, with mmsize > 16 in the macro patch

Thanks

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


[FFmpeg-devel] [PATCH 1/4] libavutil: Add saturating subtraction functions

2017-12-02 Thread Andrew D'Addesio
Add av_sat_sub32 and av_sat_dsub32 as the subtraction analogues to
av_sat_add32/av_sat_dadd32.

Also clarify the formulas for dadd32/dsub32.

Signed-off-by: Andrew D'Addesio 
---
 libavutil/arm/intmath.h | 16 
 libavutil/common.h  | 32 +++-
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/libavutil/arm/intmath.h b/libavutil/arm/intmath.h
index 65e42c5..5311a7d 100644
--- a/libavutil/arm/intmath.h
+++ b/libavutil/arm/intmath.h
@@ -94,6 +94,22 @@ static av_always_inline int av_sat_dadd32_arm(int a, int b)
 return r;
 }
 
+#define av_sat_sub32 av_sat_sub32_arm
+static av_always_inline int av_sat_sub32_arm(int a, int b)
+{
+int r;
+__asm__ ("qsub %0, %1, %2" : "=r"(r) : "r"(a), "r"(b));
+return r;
+}
+
+#define av_sat_dsub32 av_sat_dsub32_arm
+static av_always_inline int av_sat_dsub32_arm(int a, int b)
+{
+int r;
+__asm__ ("qdsub %0, %1, %2" : "=r"(r) : "r"(a), "r"(b));
+return r;
+}
+
 #endif /* HAVE_ARMV6_INLINE */
 
 #if HAVE_ASM_MOD_Q
diff --git a/libavutil/common.h b/libavutil/common.h
index 8142b31..5e03828 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -260,13 +260,37 @@ static av_always_inline int av_sat_add32_c(int a, int b)
  *
  * @param  a first value
  * @param  b value doubled and added to a
- * @return sum with signed saturation
+ * @return sum sat(a + sat(2*b)) with signed saturation
  */
 static av_always_inline int av_sat_dadd32_c(int a, int b)
 {
 return av_sat_add32(a, av_sat_add32(b, b));
 }
 
+/**
+ * Subtract two signed 32-bit values with saturation.
+ *
+ * @param  a one value
+ * @param  b another value
+ * @return difference with signed saturation
+ */
+static av_always_inline int av_sat_sub32_c(int a, int b)
+{
+return av_clipl_int32((int64_t)a - b);
+}
+
+/**
+ * Subtract a doubled value from another value with saturation at both stages.
+ *
+ * @param  a first value
+ * @param  b value doubled and subtracted from a
+ * @return difference sat(a - sat(2*b)) with signed saturation
+ */
+static av_always_inline int av_sat_dsub32_c(int a, int b)
+{
+return av_sat_sub32(a, av_sat_add32(b, b));
+}
+
 /**
  * Clip a float value into the amin-amax range.
  * @param a value to clip
@@ -513,6 +537,12 @@ static av_always_inline av_const int av_parity_c(uint32_t 
v)
 #ifndef av_sat_dadd32
 #   define av_sat_dadd32av_sat_dadd32_c
 #endif
+#ifndef av_sat_sub32
+#   define av_sat_sub32 av_sat_sub32_c
+#endif
+#ifndef av_sat_dsub32
+#   define av_sat_dsub32av_sat_dsub32_c
+#endif
 #ifndef av_clipf
 #   define av_clipf av_clipf_c
 #endif
-- 
2.15.1.windows.2

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


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread James Almer
On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
> 2017-12-02 18:37 GMT+01:00 John Stebbins :
>> That should be done, or I should add back support for earlier versions.
>> Is there any desire by anyone to keep support for earlier versions?
> 
> How old is 2.5, is 2.4 used by current versions of distributions?
> (How ugly is the support for earlier versions?)

It's four months old, and rolling release distros are using it and will
move on to 2.6 soon.

By the time non rolling release distros switch to ffmpeg > 3.4, they
will also switch to whatever is newest for x265 at the time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

2017-12-02 Thread Henrik Gramner
On Fri, Dec 1, 2017 at 9:03 PM, Martin Vignali  wrote:
> If no one have objections, i will push these patch tomorrow.
>
> Martin

Follow James' suggestion to use >16 instead of ==32, otherwise OK.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread James Almer
On 12/2/2017 3:00 PM, Carl Eugen Hoyos wrote:
> 2017-12-02 18:51 GMT+01:00 James Almer :
>> On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
>>> 2017-12-02 18:37 GMT+01:00 John Stebbins :
 That should be done, or I should add back support for earlier versions.
 Is there any desire by anyone to keep support for earlier versions?
>>>
>>> How old is 2.5, is 2.4 used by current versions of distributions?
>>> (How ugly is the support for earlier versions?)
>>
>> It's four months old, and rolling release distros are using it and will
>> move on to 2.6 soon.
>>
>> By the time non rolling release distros switch to ffmpeg > 3.4, they
>> will also switch to whatever is newest for x265 at the time.
> 
> I was mostly thinking about users who build FFmpeg by themselves
> on current distributions. (And about developers who like to test on
> vanilla systems.)

Those on rolling release ditros are covered, and those compiling ffmpeg
git head on non rolling release distros are most likely also compiling
any required libraries for it.
Hell, 2.5 is even in Debian testing right now.

I very much rather avoid ifdeffery to support old releases from projects
with a rapid update schedule like x265.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add DECLARE_ASM_ALIGNED macro for DJGPP architecture.

2017-12-02 Thread Michael Niedermayer
On Tue, Nov 14, 2017 at 06:26:49PM +, Thomas Köppe wrote:
> The macro was added in 43171a2a738f5114768d34a7278e56e5fde714bc, but I forgot 
> to add it to the DJGPP architecture in that change.
> ---
>  libavutil/mem.h | 1 +
>  1 file changed, 1 insertion(+)

will apply unless someone else is faster

thx

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

Those who are best at talking, realize last or never when they are wrong.


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


Re: [FFmpeg-devel] avcodec/huffyuvenc : try to call dsp with aligned data, and remove code duplication

2017-12-02 Thread Martin Vignali
>
> requiring FFMIN() to be evaluated per iteration could be slower
> if the compiler fails to factor it out
>
>
>
> New patchs in attach :

001 : unchanged
002 : add "int min_width = FFMIN(w, 32)" at the start of the func
003 : add "int min_width = FFMIN(w, 8)" at the start of the func


Pass fate test for me.

Martin


0001-avcodec-huffyuvenc-increase-scalar-loop-count.patch
Description: Binary data


0002-avcodec-huffyuvenc-remove-code-duplication-in.patch
Description: Binary data


0003-avcodec-huffyuvenc-sub_left_prediction_bgr32-call-ds.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD

2017-12-02 Thread James Almer
On 12/2/2017 6:27 AM, Paul B Mahol wrote:
> On 12/2/17, James Almer  wrote:
>> On 12/1/2017 3:41 PM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavfilter/threshold.h | 51 +++
>>>  libavfilter/vf_threshold.c  | 28 ---
>>>  libavfilter/x86/Makefile|  2 ++
>>>  libavfilter/x86/vf_threshold.asm| 69
>>> +
>>>  libavfilter/x86/vf_threshold_init.c | 41 ++
>>>  5 files changed, 169 insertions(+), 22 deletions(-)
>>>  create mode 100644 libavfilter/threshold.h
>>>  create mode 100644 libavfilter/x86/vf_threshold.asm
>>>  create mode 100644 libavfilter/x86/vf_threshold_init.c
>>
>> [..]
>>
>>> diff --git a/libavfilter/x86/vf_threshold_init.c
>>> b/libavfilter/x86/vf_threshold_init.c
>>> new file mode 100644
>>> index 00..e2bbae11d5
>>> --- /dev/null
>>> +++ b/libavfilter/x86/vf_threshold_init.c
>>> @@ -0,0 +1,41 @@
>>> +/*
>>> + * Copyright (c) 2015 Paul B Mahol
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> + */
>>> +
>>> +#include "libavutil/attributes.h"
>>> +#include "libavutil/cpu.h"
>>> +#include "libavutil/x86/cpu.h"
>>> +#include "libavfilter/threshold.h"
>>> +
>>> +void ff_threshold8_sse4(const uint8_t *in, const uint8_t *threshold,
>>> +const uint8_t *min, const uint8_t *max,
>>> +uint8_t *out,
>>> +ptrdiff_t ilinesize, ptrdiff_t tlinesize,
>>> +ptrdiff_t flinesize, ptrdiff_t slinesize,
>>> +ptrdiff_t olinesize,
>>> +int w, int h);
>>> +
>>> +av_cold void ff_threshold_init_x86(ThresholdContext *s)
>>> +{
>>> +int cpu_flags = av_get_cpu_flags();
>>> +
>>> +if (ARCH_X86_64 && EXTERNAL_SSE4(cpu_flags) && s->depth == 8) {
>>> +s->threshold = ff_threshold8_sse4;
>>> +}
>>> +}
>>>
>>
>> Can you add a checkasm test for this function, or at least a normal test
>> for the filter that covers it?
> 
> Yes, i can add it later. Is it ready for push?

I can't test it, but there's nothing obviously wrong with it, so if you
know if works then yes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD

2017-12-02 Thread Martin Vignali
> +
> +%include "libavutil/x86/x86util.asm"
> +
> +SECTION_RODATA
> +
> +pb_flip_byte:  times 16 db 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0
> +pb_flip_short: times 16 db 14,15,12,13,10,11,8,9,6,7,4,5,2,3,0,1
> +
>

times 16 ?

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


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread John Stebbins
On 12/02/2017 01:40 AM, Marton Balint wrote:
> On Thu, 30 Nov 2017, John Stebbins wrote:
>
>> Used by movenc to fill sdtp box
>> ---
>> libavcodec/libx265.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
>> index 4456e300f2..c137fe4ae1 100644
>> --- a/libavcodec/libx265.c
>> +++ b/libavcodec/libx265.c
>> @@ -329,6 +329,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> FF_ENABLE_DEPRECATION_WARNINGS
>> #endif
>>
>> +if (x265pic_out.sliceType == X265_TYPE_B)
>> +pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
> You can only set this for B pictures which are not referenced by other 
> frames, no? Otherwise they can't be dropped independently from the others.
>
>

Correct.  x265 version 2.5 and above returns X265_TYPE_BREF for frames that are 
referenced.  There is a way to
distinguish on version 2.4 and below as well using 
x265pic_out.frameData.sliceType, and an earlier version of my patch
used that.  But it's really not the "right" way going forward.  I can restore 
it if supporting earlier versions of x265
is important.  But my feeling with such fast moving projects as x265 is it's 
best not to keep too much cruft in support
of old versions.

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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


[FFmpeg-devel] [PATCH 2/4] opus: Fix arithmetic overflows (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
The relevant sections from the RFC are:

Sec.6. Integer Wrap-Around in Inverse Gain Computation
32-bit integer overflow in Levinson recursion. Affects
silk_is_lpc_stable().

Sec.8. Cap on Band Energy
NaN due to large log-energy value. Affects celt_denormalize().

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_celt.c |  3 ++-
 libavcodec/opus_silk.c | 11 +--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index 84d4847..ff56041 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -481,7 +481,8 @@ static void celt_denormalize(CeltFrame *f, CeltBlock 
*block, float *data)
 
 for (i = f->start_band; i < f->end_band; i++) {
 float *dst = data + (ff_celt_freq_bands[i] << f->size);
-float norm = exp2f(block->energy[i] + ff_celt_mean_energy[i]);
+float log_norm = block->energy[i] + ff_celt_mean_energy[i];
+float norm = exp2f(FFMIN(log_norm, 32.0f));
 
 for (j = 0; j < ff_celt_freq_range[i] << f->size; j++)
 dst[j] *= norm;
diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index 3c9c849..344333c 100644
--- a/libavcodec/opus_silk.c
+++ b/libavcodec/opus_silk.c
@@ -185,8 +185,15 @@ static inline int silk_is_lpc_stable(const int16_t 
lpc[16], int order)
 row = lpc32[k & 1];
 
 for (j = 0; j < k; j++) {
-int x = prevrow[j] - ROUND_MULL(prevrow[k - j - 1], rc, 31);
-row[j] = ROUND_MULL(x, gain, fbits);
+int x = av_sat_sub32(prevrow[j], ROUND_MULL(prevrow[k - j - 1], 
rc, 31));
+int64_t tmp = ROUND_MULL(x, gain, fbits);
+
+/* per RFC 8251 section 6, if this calculation overflows, the 
filter
+   is considered unstable. */
+if (tmp < INT32_MIN || tmp > INT32_MAX)
+return 0;
+
+row[j] = (int32_t)tmp;
 }
 }
 }
-- 
2.15.1.windows.2

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


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread Carl Eugen Hoyos
2017-12-02 18:37 GMT+01:00 John Stebbins :
> That should be done, or I should add back support for earlier versions.
> Is there any desire by anyone to keep support for earlier versions?

How old is 2.5, is 2.4 used by current versions of distributions?
(How ugly is the support for earlier versions?)

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


Re: [FFmpeg-devel] [PATCH 1/6] lavf/movenc: add sdtp (sample dependency) box

2017-12-02 Thread Michael Niedermayer
On Sun, Nov 19, 2017 at 12:46:30PM -0800, John Stebbins wrote:
> The sdtp is required by the AppleTV 4K in order to play 2160p60 video.
> ---
>  libavcodec/avcodec.h |  6 ++
>  libavformat/isom.h   |  5 +
>  libavformat/movenc.c | 30 ++
>  libavformat/movenc.h |  2 ++
>  4 files changed, 43 insertions(+)

will apply

thanks

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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


[FFmpeg-devel] avcodec/utvideodec : add SIMD (SSSE3 and AVX2) for gradient_pred (V2)

2017-12-02 Thread Martin Vignali
Hello,

New patchs in attach for adding gradient pred SIMD (SSSE3 and AVX2)
(use by utvideo dec now (more use will be add later))

Checkasm result (width = 1024)

add_gradient_pred_c: 2070.2
add_gradient_pred_ssse3: 602.4
add_gradient_pred_avx2: 385.7


Need to be apply after add_left_pred AVX2 patchs



Martin


0004-avcodec-utvideodec-add-SIMD-SSSE3-and-AVX2-for-gradi.patch
Description: Binary data


0005-checkasm-llviddsp-add-test-for-add_gradient_pred.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/2] avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97*

2017-12-02 Thread Michael Niedermayer
Fixes: 4478/clusterfuzz-testcase-minimized-4752113767809024
Fixes: runtime error: signed integer overflow: -2147483626 + -319489 cannot be 
represented in type 'int'

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dirac_dwt.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index eb5aebc878..50c8b1e394 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -117,16 +117,16 @@ void ff_spatial_idwt_slice2(DWTContext *d, int y);
 ((unsigned)b4 + ((int)(-2*(b0+(unsigned)b8) + 10*(b1+(unsigned)b7) - 
25*(b2+(unsigned)b6) +  81*(b3+(unsigned)b5) + 128) >> 8))
 
 #define COMPOSE_DAUB97iL1(b0, b1, b2)\
-(b1 - ((int)(1817*(b0 + (unsigned)b2) + 2048) >> 12))
+((unsigned)(b1) - ((int)(1817*(b0 + (unsigned)b2) + 2048) >> 12))
 
 #define COMPOSE_DAUB97iH1(b0, b1, b2)\
-(b1 - ((int)( 113*(b0 + (unsigned)b2) + 64) >> 7))
+((unsigned)(b1) - ((int)( 113*(b0 + (unsigned)b2) + 64) >> 7))
 
 #define COMPOSE_DAUB97iL0(b0, b1, b2)\
-(b1 + ((int)( 217*(b0 + (unsigned)b2) + 2048) >> 12))
+((unsigned)(b1) + ((int)( 217*(b0 + (unsigned)b2) + 2048) >> 12))
 
 #define COMPOSE_DAUB97iH0(b0, b1, b2)\
-(b1 + ((int)(6497*(b0 + (unsigned)b2) + 2048) >> 12))
+((unsigned)(b1) + ((int)(6497*(b0 + (unsigned)b2) + 2048) >> 12))
 
 
 #endif /* AVCODEC_DWT_H */
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 2/2] avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED()

2017-12-02 Thread Michael Niedermayer
Fixes: runtime error: signed integer overflow: 2147483646 + 2048 cannot be 
represented in type 'int'
Fixes: 4479/clusterfuzz-testcase-minimized-6529894147162112

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/diracdsp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
index 8bc79b788c..2dd56f83f3 100644
--- a/libavcodec/diracdsp.c
+++ b/libavcodec/diracdsp.c
@@ -159,10 +159,10 @@ static void put_signed_rect_clamped_ ## PX ## 
bit_c(uint8_t *_dst, int dst_strid
 int32_t *src = (int32_t *)_src;
 \
 for (y = 0; y < height; y++) { 
 \
 for (x = 0; x < width; x+=4) { 
 \
-dst[x  ] = av_clip_uintp2(src[x  ] + (1 << (PX - 1)), PX); 
 \
-dst[x+1] = av_clip_uintp2(src[x+1] + (1 << (PX - 1)), PX); 
 \
-dst[x+2] = av_clip_uintp2(src[x+2] + (1 << (PX - 1)), PX); 
 \
-dst[x+3] = av_clip_uintp2(src[x+3] + (1 << (PX - 1)), PX); 
 \
+dst[x  ] = av_clip_uintp2(src[x  ] + (1U << (PX - 1)), PX);
  \
+dst[x+1] = av_clip_uintp2(src[x+1] + (1U << (PX - 1)), PX);
  \
+dst[x+2] = av_clip_uintp2(src[x+2] + (1U << (PX - 1)), PX);
  \
+dst[x+3] = av_clip_uintp2(src[x+3] + (1U << (PX - 1)), PX);
  \
 }  
 \
 dst += dst_stride >> 1;
 \
 src += src_stride >> 2;
 \
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4()

2017-12-02 Thread Michael Niedermayer
On Sat, Nov 25, 2017 at 11:08:46PM +0100, Clément Bœsch wrote:
> On Sat, Nov 25, 2017 at 10:49:09PM +0100, Michael Niedermayer wrote:
> > Fixes: lorex.mp4
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_parse.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> > index a7c71d9bbb..9216d0bdbd 100644
> > --- a/libavcodec/h264_parse.c
> > +++ b/libavcodec/h264_parse.c
> > @@ -427,8 +427,6 @@ static int decode_extradata_ps_mp4(const uint8_t *buf, 
> > int buf_size, H264ParamSe
> >  
> >  ret = decode_extradata_ps(escaped_buf, escaped_buf_size, ps, 1, 
> > logctx);
> >  av_freep(_buf);
> > -if (ret < 0)
> > -return ret;
> 
> If you don't want the return code to be reintroduced differently 10x in
> the future (like, someone deciding to return ret in the function instead
> of 0), I'd suggest 2 things:
> 
> - use "(void)decode_extradata_ps(...)" to explicitly ignore the code
>   return; it's a hint for the compiler and the developer, typically used
>   in OpenBSD (I believe that's because they warn about unchecked return
>   code by default)
> - add a comment above about the why

will push with these changes

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread Michael Niedermayer
On Sat, Dec 02, 2017 at 03:26:34PM -0300, James Almer wrote:
> On 12/2/2017 3:00 PM, Carl Eugen Hoyos wrote:
> > 2017-12-02 18:51 GMT+01:00 James Almer :
> >> On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
> >>> 2017-12-02 18:37 GMT+01:00 John Stebbins :
>  That should be done, or I should add back support for earlier versions.
>  Is there any desire by anyone to keep support for earlier versions?
> >>>
> >>> How old is 2.5, is 2.4 used by current versions of distributions?
> >>> (How ugly is the support for earlier versions?)
> >>
> >> It's four months old, and rolling release distros are using it and will
> >> move on to 2.6 soon.
> >>
> >> By the time non rolling release distros switch to ffmpeg > 3.4, they
> >> will also switch to whatever is newest for x265 at the time.
> > 
> > I was mostly thinking about users who build FFmpeg by themselves
> > on current distributions. (And about developers who like to test on
> > vanilla systems.)
> 
> Those on rolling release ditros are covered, and those compiling ffmpeg
> git head on non rolling release distros are most likely also compiling
> any required libraries for it.
> Hell, 2.5 is even in Debian testing right now.
> 

> I very much rather avoid ifdeffery to support old releases from projects
> with a rapid update schedule like x265.

I understand why you prefer this but i think its nicer to our users
also the stricter version  deps are the more one runs into issues

for example the "recent" libvpx min version bump required me to
update my libvpx and it promptly broke many older FFmpeg versions
ive patched my release branches locally and that would be in the next
point releases of course but versions released previously require
a libvpx that master doesnt build with and what master builds with
they dont.

If we accumulate too many of these things bisect will become
increasingly painfull

short version, my "vote" is for keeping support for the older version
by #if or any other solution


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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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/4] opus: Add Special Hybrid Folding (per RFC8251)

2017-12-02 Thread Michael Niedermayer
On Sat, Dec 02, 2017 at 11:46:58AM -0600, Andrew D'Addesio wrote:
> This decoder-side change, introduced in RFC 8251 (section 9), slightly
> improves the decoded quality of 16kbps speech in Hybrid Mode.
> 
> Differences can be seen/heard in testvector05.bit, testvector06.bit,
> and testvector12.bit in the RFC 6716/8251 testvectors found here:
> https://people.xiph.org/~greg/opus_testvectors/
> 
> Signed-off-by: Andrew D'Addesio 
> ---
>  libavcodec/opus_celt.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)

this is missing fate updates:
TESTopus-testvector05
TESTopus-testvector06
stddev:  117.55 PSNR: 54.92 MAXDIFF: 3275 bytes:  4803840/  4803840
stddev: |117.55 - 106| >= 3
Test opus-testvector06 failed. Look at tests/data/fate/opus-testvector06.err 
for details.
make: *** [fate-opus-testvector06] Error 1
make: *** Waiting for unfinished jobs
stddev:  111.41 PSNR: 55.39 MAXDIFF: 2630 bytes:  5216640/  5216640
stddev: |111.41 - 108| >= 3
Test opus-testvector05 failed. Look at tests/data/fate/opus-testvector05.err 
for details.
make: *** [fate-opus-testvector05] Error 1

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


[FFmpeg-devel] [PATCH] fix MSVC compilation errors

2017-12-02 Thread Mateusz
After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
we have included windows.h in much more files and we should
avoid conflicts with defines/function declarations.

Signed-off-by: Mateusz Brzostek 
---
 libavcodec/jpegls.h  | 4 
 libavcodec/mss2.c| 6 +++---
 libavformat/mxfenc.c | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
index c8997c7861..69a57b9538 100644
--- a/libavcodec/jpegls.h
+++ b/libavcodec/jpegls.h
@@ -32,6 +32,10 @@
 #include "avcodec.h"
 #include "internal.h"
 
+#ifdef near
+#undef near
+#endif
+
 typedef struct JpeglsContext {
 AVCodecContext *avctx;
 } JpeglsContext;
diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
index 9e7cc466de..f850349a0a 100644
--- a/libavcodec/mss2.c
+++ b/libavcodec/mss2.c
@@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const uint8_t 
*buf, int buf_size,
 return 0;
 }
 
-typedef struct Rectangle {
+typedef struct ff_Rectangle {
 int coded, x, y, w, h;
-} Rectangle;
+} ff_Rectangle;
 
 #define MAX_WMV9_RECTANGLES 20
 #define ARITH2_PADDING 2
@@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 
 int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
 
-Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
+ff_Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
 int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
 
 if ((ret = init_get_bits8(, buf, buf_size)) < 0)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ed6ecbf541..407acdcaaa 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1444,7 +1444,7 @@ static int mxf_write_header_metadata_sets(AVFormatContext 
*s)
 AVStream *st = NULL;
 int i;
 
-MXFPackage packages[2] = {};
+MXFPackage packages[2] = {{NULL}};
 int package_count = 2;
 packages[0].type = MaterialPackage;
 packages[1].type = SourcePackage;
-- 
2.15.1.windows.2

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


[FFmpeg-devel] [PATCH 3/4] opus: Add Special Hybrid Folding (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
This decoder-side change, introduced in RFC 8251 (section 9), slightly
improves the decoded quality of 16kbps speech in Hybrid Mode.

Differences can be seen/heard in testvector05.bit, testvector06.bit,
and testvector12.bit in the RFC 6716/8251 testvectors found here:
https://people.xiph.org/~greg/opus_testvectors/

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_celt.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index ff56041..2bbb96b 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -712,10 +712,22 @@ static void celt_decode_bands(CeltFrame *f, 
OpusRangeCoder *rc)
 b = av_clip_uintp2(FFMIN(f->remaining2 + 1, f->pulses[i] + 
curr_balance), 14);
 }
 
-if (ff_celt_freq_bands[i] - ff_celt_freq_range[i] >= 
ff_celt_freq_bands[f->start_band] &&
-(update_lowband || lowband_offset == 0))
+if ((ff_celt_freq_bands[i] - ff_celt_freq_range[i] >= 
ff_celt_freq_bands[f->start_band] ||
+i == f->start_band + 1) && (update_lowband || lowband_offset == 0))
 lowband_offset = i;
 
+if (i == f->start_band + 1) {
+/* Special Hybrid Folding (RFC 8251 section 9). Copy the first 
band into
+the second to ensure the second band never has to use the LCG. */
+int offset = 8 * ff_celt_freq_bands[i];
+int count = 8 * (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]);
+
+memcpy([offset], [offset - count], count * 
sizeof(float));
+
+if (f->channels == 2)
+memcpy([offset], [offset - count], count * 
sizeof(float));
+}
+
 /* Get a conservative estimate of the collapse_mask's for the bands 
we're
going to be folding from. */
 if (lowband_offset != 0 && (f->spread != CELT_SPREAD_AGGRESSIVE ||
@@ -728,7 +740,7 @@ static void celt_decode_bands(CeltFrame *f, OpusRangeCoder 
*rc)
 foldstart = lowband_offset;
 while (ff_celt_freq_bands[--foldstart] > effective_lowband);
 foldend = lowband_offset - 1;
-while (ff_celt_freq_bands[++foldend] < effective_lowband + 
ff_celt_freq_range[i]);
+while (++foldend < i && ff_celt_freq_bands[foldend] < 
effective_lowband + ff_celt_freq_range[i]);
 
 cm[0] = cm[1] = 0;
 for (j = foldstart; j < foldend; j++) {
-- 
2.15.1.windows.2

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


Re: [FFmpeg-devel] [PATCH 1/2] v3 - SCTE extraction from mpegts

2017-12-02 Thread Sandeep Reddy
Hi,

I applied the SCTE patch on hlsenc. But I am unable to find a way to
intialize scte_interface of HLSContext .

Please let me know ,how to intialize it
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 4/4] opus: Don't invert phase when downmixing to mono (per RFC8251)

2017-12-02 Thread Andrew D'Addesio
When decoding to downmixed mono, don't put the channels out of phase,
as they will cancel out and create audible artifacts. (See
RFC 8251 sec. 10.)

Signed-off-by: Andrew D'Addesio 
---
 libavcodec/opus_pvq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2f7aa74..f18c010 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -643,7 +643,13 @@ static av_always_inline uint32_t 
quant_band_template(CeltPVQ *pvq, CeltFrame *f,
 }
 } else {
 inv = (b > 2 << 3 && f->remaining2 > 2 << 3) ? 
ff_opus_rc_dec_log(rc, 2) : 0;
+
+/* Don't put the channels out of phase if we are decoding to 
downmixed
+ * mono as this subjectively sounds bad (RFC 8251 section 10). 
*/
+if (f->channels == 1)
+inv = 0;
 }
+
 itheta = 0;
 }
 qalloc = opus_rc_tell_frac(rc) - tell;
-- 
2.15.1.windows.2

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


Re: [FFmpeg-devel] [PATCH] avformat: add NSP demuxer

2017-12-02 Thread Carl Eugen Hoyos
2017-12-01 17:26 GMT+01:00 Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/nspdec.c | 101 
> +++
>  3 files changed, 103 insertions(+)
>  create mode 100644 libavformat/nspdec.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 4bffdf2205..734b703862 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -331,6 +331,7 @@ OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o 
> mxf.o audiointerleave.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> +OBJS-$(CONFIG_NSP_DEMUXER)   += nspdec.o
>  OBJS-$(CONFIG_NSV_DEMUXER)   += nsvdec.o
>  OBJS-$(CONFIG_NULL_MUXER)+= nullenc.o
>  OBJS-$(CONFIG_NUT_DEMUXER)   += nutdec.o nut.o isom.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 9213af9301..6a9b9883c9 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -224,6 +224,7 @@ static void register_all(void)
>  REGISTER_DEMUXER (MXG,  mxg);
>  REGISTER_DEMUXER (NC,   nc);
>  REGISTER_DEMUXER (NISTSPHERE,   nistsphere);
> +REGISTER_DEMUXER (NSP,  nsp);
>  REGISTER_DEMUXER (NSV,  nsv);
>  REGISTER_MUXER   (NULL, null);
>  REGISTER_MUXDEMUX(NUT,  nut);
> diff --git a/libavformat/nspdec.c b/libavformat/nspdec.c
> new file mode 100644
> index 00..d2ff779732
> --- /dev/null
> +++ b/libavformat/nspdec.c
> @@ -0,0 +1,101 @@
> +/*
> + * NSP demuxer
> + * Copyright (c) 2017 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/avstring.h"
> +#include "libavutil/intreadwrite.h"
> +#include "avformat.h"
> +#include "internal.h"
> +#include "pcm.h"
> +
> +static int nsp_probe(AVProbeData *p)
> +{
> +if (AV_RB32(p->buf) == AV_RB32("FORM") &&
> +AV_RB32(p->buf + 4) == AV_RB32("DS16"))
> +return AVPROBE_SCORE_MAX;
> +return 0;
> +}
> +
> +static int nsp_read_header(AVFormatContext *s)
> +{
> +int rate = 0, channels = 0;
> +uint32_t chunk, size;
> +AVStream *st;
> +int64_t pos;
> +
> +avio_skip(s->pb, 12);
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +
> +while (!avio_feof(s->pb)) {
> +chunk = avio_rb32(s->pb);

Not codec_tag?

> +size  = avio_rl32(s->pb);
> +pos   = avio_tell(s->pb);
> +
> +if (chunk == MKBETAG('H', 'D', 'R', '8') ||
> +chunk == MKBETAG('H', 'E', 'D', 'R')) {

It's your code but I suspect a switch() makes this
more readable.

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


[FFmpeg-devel] [PATCH 1/2] libavutil/hwcontext: add AV_HWDEVICE_TYPE_MEDIACODEC

2017-12-02 Thread Aman Gupta
From: Aman Gupta 

---
 libavutil/Makefile   |  2 ++
 libavutil/hwcontext.c|  4 
 libavutil/hwcontext.h|  1 +
 libavutil/hwcontext_mediacodec.c | 50 
 libavutil/hwcontext_mediacodec.h | 34 +++
 5 files changed, 91 insertions(+)
 create mode 100644 libavutil/hwcontext_mediacodec.c
 create mode 100644 libavutil/hwcontext_mediacodec.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 721784086c..6b12acea68 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -166,6 +166,7 @@ OBJS-$(CONFIG_OPENCL)   += 
hwcontext_opencl.o
 OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
+OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
 
 OBJS += $(COMPAT_OBJS:%=../compat/%)
 
@@ -181,6 +182,7 @@ SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
+SKIPHEADERS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.h
 SKIPHEADERS-$(HAVE_ATOMICS_GCC)+= atomic_gcc.h
 SKIPHEADERS-$(HAVE_ATOMICS_SUNCC)  += atomic_suncc.h
 SKIPHEADERS-$(HAVE_ATOMICS_WIN32)  += atomic_win32.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index f47158f811..31ac12807b 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -56,6 +56,9 @@ static const HWContextType * const hw_table[] = {
 #if CONFIG_VIDEOTOOLBOX
 _hwcontext_type_videotoolbox,
 #endif
+#if CONFIG_MEDIACODEC
+_hwcontext_type_mediacodec,
+#endif
 NULL,
 };
 
@@ -69,6 +72,7 @@ static const char *const hw_type_names[] = {
 [AV_HWDEVICE_TYPE_VAAPI]  = "vaapi",
 [AV_HWDEVICE_TYPE_VDPAU]  = "vdpau",
 [AV_HWDEVICE_TYPE_VIDEOTOOLBOX] = "videotoolbox",
+[AV_HWDEVICE_TYPE_MEDIACODEC] = "mediacodec",
 };
 
 enum AVHWDeviceType av_hwdevice_find_type_by_name(const char *name)
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 8d27b987df..f5a4b62387 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -35,6 +35,7 @@ enum AVHWDeviceType {
 AV_HWDEVICE_TYPE_D3D11VA,
 AV_HWDEVICE_TYPE_DRM,
 AV_HWDEVICE_TYPE_OPENCL,
+AV_HWDEVICE_TYPE_MEDIACODEC,
 };
 
 typedef struct AVHWDeviceInternal AVHWDeviceInternal;
diff --git a/libavutil/hwcontext_mediacodec.c b/libavutil/hwcontext_mediacodec.c
new file mode 100644
index 00..b0d8993e15
--- /dev/null
+++ b/libavutil/hwcontext_mediacodec.c
@@ -0,0 +1,50 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "buffer.h"
+#include "common.h"
+#include "hwcontext.h"
+#include "hwcontext_internal.h"
+#include "hwcontext_mediacodec.h"
+
+static int mc_device_create(AVHWDeviceContext *ctx, const char *device,
+AVDictionary *opts, int flags)
+{
+if (device && device[0]) {
+av_log(ctx, AV_LOG_ERROR, "Device selection unsupported.\n");
+return AVERROR_UNKNOWN;
+}
+
+return 0;
+}
+
+const HWContextType ff_hwcontext_type_mediacodec = {
+.type = AV_HWDEVICE_TYPE_MEDIACODEC,
+.name = "mediacodec",
+
+.device_hwctx_size= sizeof(AVMediaCodecDeviceContext),
+
+.device_create= mc_device_create,
+
+.pix_fmts = (const enum AVPixelFormat[]){
+AV_PIX_FMT_MEDIACODEC,
+AV_PIX_FMT_NONE
+},
+};
diff --git a/libavutil/hwcontext_mediacodec.h b/libavutil/hwcontext_mediacodec.h
new file mode 100644
index 00..3d2c91d2f2
--- /dev/null
+++ b/libavutil/hwcontext_mediacodec.h
@@ -0,0 +1,34 @@
+/*
+ * 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 

Re: [FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

2017-12-02 Thread Carl Eugen Hoyos
2017-12-01 20:08 GMT+01:00 Neil Birkbeck :
> On Thu, Nov 30, 2017 at 9:52 AM, Michael Niedermayer wrote:

>> > For that sample, I feel like it may be incorrectly tagged as pc/full.
>>
>> is it stored in the file or taken from:
>> ff_generate_avci_extradata()
>> maybe theres a bug in the AVCIntra handling
>
> It seems avci100_1080i_extradata may be the one that is signalling full
> range for the AVCI100.mov sample. I tested changing the range flag:
> -0x3c, 0x60, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,
> +0x3c, 0x20, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,

If you believe it is safe (or a bug), please change it.

> There is an unused ACLR atom in the mov that also appears to
> signal full range (parsing of that atom is skipped for h264)

I believe the extra-data should not be overwritten.

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


Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

2017-12-02 Thread Anssi Hannula

Hi,

Sorry about the delay.

Rainer Hochecker kirjoitti 2017-11-28 00:23:

2017-11-27 22:53 GMT+01:00 Anssi Hannula :

Hi,

Rainer Hochecker kirjoitti 2017-11-26 12:46:


fixed mem leak poined out by Steven

---
 doc/demuxers.texi |   5 +
 libavformat/hls.c | 304
--
 2 files changed, 209 insertions(+), 100 deletions(-)


[...]


+
+@item load_all_variants
+If 0, only the first variant/playlist is loaded on open. All other
variants
+get disabled and can be enabled by setting discard option in 
program.

+Default value is 1.
 @end table



If playlist download+parsing is indeed taking long enough time that 
this is
warranted, I wonder if we should maybe just never read any variant 
playlists

in read_header(), and instead set AVFMTCTX_NOHEADER.
Then the user may discard AVPrograms right after open, before unneeded
playlists are loaded+parsed.

This would avoid having a separate option/mode for this.

Any thoughts?


I actually tried it like this but somwhow did not like it because this
is different
to all other demuxers/formats. In general you open an input, call
find_stream_info,
and select a program. I did not like selecting the program between open 
and

find_stream_info.


OK I guess. Though arguably hls is already quite different from mpegts 
which is the only other demuxer that creates multiple AVPrograms.


In the long run, I think I'd prefer the HLS demuxer to have a mode where 
only a single program/variant is given to the user at a time, with the 
demuxer handling the switching between the variants. But that would be a 
lot more work and I'm not even sure it would be feasible. So I guess 
your solution is OK, at least for now.



Is there a reason the first variant/playlist is still parsed, i.e. why 
not simply not parse any media playlists (i.e. only master pls) when the 
new mode is selected?
If the player is selecting the variant/program based on bitrate (like 
Kodi does), then the first playlist would likely have been 
downloaded+parsed unnecessarily.



Also, even with your current patch you will need to set 
AVFMTCTX_NOHEADER as you defer avformat_new_stream() calls to 
read_packet(). I think you can update update_noheader_flag() to set 
flag_needed=1 if any pls is !pls->is_parsed.






 @section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 786934af03..c42e0b0f95 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -112,6 +112,7 @@ struct playlist {
 int n_segments;
 struct segment **segments;
 int needed, cur_needed;
+int parsed;
 int cur_seq_no;
 int64_t cur_seg_offset;
 int64_t last_load_time;
@@ -206,6 +207,7 @@ typedef struct HLSContext {
 int strict_std_compliance;
 char *allowed_extensions;
 int max_reload;
+int load_all_variants;
 } HLSContext;


[...]


@@ -721,6 +726,7 @@ static int parse_playlist(HLSContext *c, const 
char

*url,
 free_segment_list(pls);
 pls->finished = 0;
 pls->type = PLS_TYPE_UNSPECIFIED;
+pls->parsed = 1;
 }



That "pls->parsed = 1" is in the "reinit old playlist for re-parse" 
block,

is that intentional?

I'd think it should rather be at the end of the function alongside 
setting

pls->last_load_time, so it is set to 1 whenever parsing has been done.



I put it at the beginning because I wanted to avoid that it gets tried 
again

on error.


OK. But now it is not set for master playlists, so maybe move 
pls->parsed = 1 below the "fail" label then?



 while (!avio_feof(in)) {
 read_chomp_line(in, line, sizeof(line));


[...]


@@ -1631,6 +1655,124 @@ static int hls_close(AVFormatContext *s)
 return 0;
 }

+static int init_playlist(HLSContext *c, struct playlist *pls)
+{



This init_playlist() seems to be mostly code moved from below, could 
you
split the patch so that the first patch moves the code around but does 
not
change behavior, and the second patch makes the actual changes (i.e. 
adds

the option)?

That would ease e.g. future bisecting.


Sure. At least I can try.



[...]


+return 0;
+}
+
 static int hls_read_header(AVFormatContext *s)
 {
 void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
@@ -1663,6 +1805,9 @@ static int hls_read_header(AVFormatContext *s)
 if ((ret = parse_playlist(c, s->filename, NULL, s->pb)) < 0)
 goto fail;

+/* first playlist was created, set it to parsed */
+c->variants[0]->playlists[0]->parsed = 1;
+



I think parse_playlist() should set this when it parses something.


That was pitfall for my v1. The first playlist gets parsed with no
playlist given as argument.
fate failed because non-master playlists were not set to parsed.


I don't think I follow. If parse_playlist() would set the playlist as 
parsed on every call (whether failed or not), then all playlists would 
be set to parsed and this line would be unnecessary.





 if ((ret = save_avio_options(s)) < 0)
 goto fail;


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread James Almer
On 12/2/2017 1:52 PM, John Stebbins wrote:
> On 12/02/2017 01:40 AM, Marton Balint wrote:
>> On Thu, 30 Nov 2017, John Stebbins wrote:
>>
>>> Used by movenc to fill sdtp box
>>> ---
>>> libavcodec/libx265.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
>>> index 4456e300f2..c137fe4ae1 100644
>>> --- a/libavcodec/libx265.c
>>> +++ b/libavcodec/libx265.c
>>> @@ -329,6 +329,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>> FF_ENABLE_DEPRECATION_WARNINGS
>>> #endif
>>>
>>> +if (x265pic_out.sliceType == X265_TYPE_B)
>>> +pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
>> You can only set this for B pictures which are not referenced by other 
>> frames, no? Otherwise they can't be dropped independently from the others.
>>
>>
> 
> Correct.  x265 version 2.5 and above returns X265_TYPE_BREF for frames that 
> are referenced.  There is a way to
> distinguish on version 2.4 and below as well using 
> x265pic_out.frameData.sliceType, and an earlier version of my patch
> used that.  But it's really not the "right" way going forward.  I can restore 
> it if supporting earlier versions of x265
> is important.  But my feeling with such fast moving projects as x265 is it's 
> best not to keep too much cruft in support
> of old versions.

You can bump the minimum required version. Just make the necessary
changes in configure.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

2017-12-02 Thread James Almer
On 12/2/2017 10:48 PM, Michael Niedermayer wrote:
> On Sat, Dec 02, 2017 at 03:26:34PM -0300, James Almer wrote:
>> On 12/2/2017 3:00 PM, Carl Eugen Hoyos wrote:
>>> 2017-12-02 18:51 GMT+01:00 James Almer :
 On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
> 2017-12-02 18:37 GMT+01:00 John Stebbins :
>> That should be done, or I should add back support for earlier versions.
>> Is there any desire by anyone to keep support for earlier versions?
>
> How old is 2.5, is 2.4 used by current versions of distributions?
> (How ugly is the support for earlier versions?)

 It's four months old, and rolling release distros are using it and will
 move on to 2.6 soon.

 By the time non rolling release distros switch to ffmpeg > 3.4, they
 will also switch to whatever is newest for x265 at the time.
>>>
>>> I was mostly thinking about users who build FFmpeg by themselves
>>> on current distributions. (And about developers who like to test on
>>> vanilla systems.)
>>
>> Those on rolling release ditros are covered, and those compiling ffmpeg
>> git head on non rolling release distros are most likely also compiling
>> any required libraries for it.
>> Hell, 2.5 is even in Debian testing right now.
>>
> 
>> I very much rather avoid ifdeffery to support old releases from projects
>> with a rapid update schedule like x265.
> 
> I understand why you prefer this but i think its nicer to our users
> also the stricter version  deps are the more one runs into issues
> 
> for example the "recent" libvpx min version bump required me to
> update my libvpx

How? 1.4.0 is two years and a half old. Even Debian ships 1.6.x in
stable by now.

> and it promptly broke many older FFmpeg versions
> ive patched my release branches locally and that would be in the next
> point releases of course but versions released previously require
> a libvpx that master doesnt build with and what master builds with
> they dont.
> 
> If we accumulate too many of these things bisect will become
> increasingly painfull

We can't keep external libraries hostage of bisect attempts for
unrelated modules... You don't need libvpx or libx265 compiled in when
hunting down a bug in mpeg2/h264/snow code. We'd never be able to update
anything that way.

I'm surprised for that matter that the libvpx wrappers in old FFMpeg
versions don't work with >= 1.4.0. I don't recall any kind of API break
that we had to work around in them.

> 
> short version, my "vote" is for keeping support for the older version
> by #if or any other solution

I'm fine keeping libx265 as is for now. Unlike libvpx 1.4.0, which is
two years and a half old, libx265 2.5 is admittedly somewhat recent.
But bisecting bugs in unrelated modules is definitely not a reason to
maintain ugly support for old and potentially buggy/unstable/insecure
versions of optional, non system external libraries.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

2017-12-02 Thread Timothy Gu
Hi all,

On Sun, Nov 26, 2017 at 12:32 AM Jim DeLaHunt 
wrote:
> 1. In doc/developer.texi, eliminate the single chapter,
> and promote each section underneath to chapter, and
> each subsection to section. Thus content and relative
> structure remains the same, but the overall structure is
> simpler.  Anchors within the page remain the same.

I have manually applied this part of the patch, which is noncontroversial
and a
strict improvement to what we have right now.

> 2. In doc/developer.texi, add a new section about
> ffmpeg-devel, based on existing text from ffmpeg-cvslog
> section regarding discussion of patches and of
> development issues.

The wording in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221199.html sounds
good
to me.

> 3. In doc/developer.texi, rewrite the ffmpeg-cvslog section
> to match the current usage of ffmpeg-cvslog. Some developers
> choose to follow this list, but it is not mandatory.

> +from all sources. Subscribing to this list is not mandatory, if
> +all you want to do is submit a patch here and there.

I would remove the "if" part, leaving only the "not mandatory" message.
Over my
tenure as FFmpeg developer I have never subscribed to -cvslog, since there
are
other ways of following FFmpeg development these days (subscribing to the
FFmpeg repo on GitHub, for example). I am glad to see this sentiment echoed
by
Ronald and Rostislav.

However, other than this technicality, I am in favor of the spirit of this
part
of the patch.



Carl,

On Mon, Nov 27, 2017 at 3:03 PM Carl Eugen Hoyos  wrote:
> If you believe that it is unclear that there is a difference between an
> occasional contributor (who most likely would not read -devel nor
> -cvslog) and a committer (who is supposed to read -cvslog), then
> maybe a patch is useful.
>
> I believe the difference could be considered common sense.

Thank you for expressing your opinion regarding this. However, I cannot say
I
agree with this evaluation. As I read this paragraph as it currently stands,
the tone makes it sound like subscription is mandatory ("we expect you"). I
believe the proposed modification is a significant improvement over the
existing text.

Additionally, from what I'm reading, it seems as if you believe subscribing
to
-cvslog is even more important than subscribing to -devel, which is false,
plain and simple.

Without further opinions from you, I will be applying this part of the
patch in
due time, by virtue of being the maintainer of Documentation.

Thanks to you all,

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


[FFmpeg-devel] [PATCH]lavfi/minterpolate: Split struct Pixel to allow higher resolutions

2017-12-02 Thread Carl Eugen Hoyos
Hi!

Attached patch should fix ticket #6795, only tested with one filter
chain (bitexact): testsrc2=r=5:d=10,minterpolate=10

Please comment, Carl Eugen
From 618c6b77dd94fcb99bfb87e6245517a829b1eff4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 3 Dec 2017 05:26:25 +0100
Subject: [PATCH] lavfi/minterpolate: Split struct Pixel to allow higher
 resolutions.

Fixes ticket #6795.
---
 libavfilter/vf_minterpolate.c |  120 +
 1 file changed, 75 insertions(+), 45 deletions(-)

diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
index 6c5c264..d534315 100644
--- a/libavfilter/vf_minterpolate.c
+++ b/libavfilter/vf_minterpolate.c
@@ -145,12 +145,18 @@ typedef struct Block {
 struct Block *subs;
 } Block;
 
-typedef struct Pixel {
+typedef struct PixelMVS {
 int16_t mvs[NB_PIXEL_MVS][2];
+} PixelMVS;
+
+typedef struct PixelWeights {
 uint32_t weights[NB_PIXEL_MVS];
+} PixelWeights;
+
+typedef struct PixelRefs {
 int8_t refs[NB_PIXEL_MVS];
 int nb;
-} Pixel;
+} PixelRefs;
 
 typedef struct Frame {
 AVFrame *avf;
@@ -172,7 +178,9 @@ typedef struct MIContext {
 Frame frames[NB_FRAMES];
 Cluster clusters[NB_CLUSTERS];
 Block *int_blocks;
-Pixel *pixels;
+PixelMVS *pixel_mvs;
+PixelWeights *pixel_weights;
+PixelRefs *pixel_refs;
 int (*mv_table[3])[2][2];
 int64_t out_pts;
 int b_width, b_height, b_count;
@@ -331,7 +339,7 @@ static int config_input(AVFilterLink *inlink)
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
 const int height = inlink->h;
 const int width  = inlink->w;
-int i;
+int i, ret = 0;
 
 mi_ctx->log2_chroma_h = desc->log2_chroma_h;
 mi_ctx->log2_chroma_w = desc->log2_chroma_w;
@@ -353,8 +361,13 @@ static int config_input(AVFilterLink *inlink)
 }
 
 if (mi_ctx->mi_mode == MI_MODE_MCI) {
-if (!(mi_ctx->pixels = av_mallocz_array(width * height, sizeof(Pixel
-return AVERROR(ENOMEM);
+mi_ctx->pixel_mvs = av_mallocz_array(width * height, sizeof(PixelMVS));
+mi_ctx->pixel_weights = av_mallocz_array(width * height, sizeof(PixelWeights));
+mi_ctx->pixel_refs = av_mallocz_array(width * height, sizeof(PixelRefs));
+if (!mi_ctx->pixel_mvs || !mi_ctx->pixel_weights || !mi_ctx->pixel_refs) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 
 if (mi_ctx->me_mode == ME_MODE_BILAT)
 if (!(mi_ctx->int_blocks = av_mallocz_array(mi_ctx->b_count, sizeof(Block
@@ -383,6 +396,13 @@ static int config_input(AVFilterLink *inlink)
 me_ctx->get_cost = _sbad_ob;
 
 return 0;
+fail:
+for (i = 0; i < NB_FRAMES; i++)
+av_freep(_ctx->frames[i].blocks);
+av_freep(_ctx->pixel_mvs);
+av_freep(_ctx->pixel_weights);
+av_freep(_ctx->pixel_refs);
+return ret;
 }
 
 static int config_output(AVFilterLink *outlink)
@@ -833,18 +853,18 @@ static int detect_scene_change(MIContext *mi_ctx)
 
 #define ADD_PIXELS(b_weight, mv_x, mv_y)\
 do {\
-if (!b_weight || pixel->nb + 1 >= NB_PIXEL_MVS)\
+if (!b_weight || pixel_refs->nb + 1 >= NB_PIXEL_MVS)\
 continue;\
-pixel->refs[pixel->nb] = 1;\
-pixel->weights[pixel->nb] = b_weight * (ALPHA_MAX - alpha);\
-pixel->mvs[pixel->nb][0] = av_clip((mv_x * alpha) / ALPHA_MAX, x_min, x_max);\
-pixel->mvs[pixel->nb][1] = av_clip((mv_y * alpha) / ALPHA_MAX, y_min, y_max);\
-pixel->nb++;\
-pixel->refs[pixel->nb] = 2;\
-pixel->weights[pixel->nb] = b_weight * alpha;\
-pixel->mvs[pixel->nb][0] = av_clip(-mv_x * (ALPHA_MAX - alpha) / ALPHA_MAX, x_min, x_max);\
-pixel->mvs[pixel->nb][1] = av_clip(-mv_y * (ALPHA_MAX - alpha) / ALPHA_MAX, y_min, y_max);\
-pixel->nb++;\
+pixel_refs->refs[pixel_refs->nb] = 1;\
+pixel_weights->weights[pixel_refs->nb] = b_weight * (ALPHA_MAX - alpha);\
+pixel_mvs->mvs[pixel_refs->nb][0] = av_clip((mv_x * alpha) / ALPHA_MAX, x_min, x_max);\
+pixel_mvs->mvs[pixel_refs->nb][1] = av_clip((mv_y * alpha) / ALPHA_MAX, y_min, y_max);\
+pixel_refs->nb++;\
+pixel_refs->refs[pixel_refs->nb] = 2;\
+pixel_weights->weights[pixel_refs->nb] = b_weight * alpha;\
+pixel_mvs->mvs[pixel_refs->nb][0] = av_clip(-mv_x * (ALPHA_MAX - alpha) / ALPHA_MAX, x_min, x_max);\
+pixel_mvs->mvs[pixel_refs->nb][1] = av_clip(-mv_y * (ALPHA_MAX - alpha) / ALPHA_MAX, y_min, y_max);\
+pixel_refs->nb++;\
 } while(0)
 
 static void bidirectional_obmc(MIContext *mi_ctx, int alpha)
@@ -856,7 +876,7 @@ static void bidirectional_obmc(MIContext *mi_ctx, int alpha)
 
 for (y = 0; y < height; y++)
 for (x = 0; x < width; x++)
-mi_ctx->pixels[x + y * width].nb = 0;
+mi_ctx->pixel_refs[x + y * width].nb = 0;
 
 for (dir = 0; dir < 2; dir++)
 for (mb_y 

[FFmpeg-devel] [PATCH] avfilter: port scaletempo filter from mpv

2017-12-02 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile|   1 +
 libavfilter/af_scaletempo.c | 529 
 libavfilter/allfilters.c|   1 +
 3 files changed, 531 insertions(+)
 create mode 100644 libavfilter/af_scaletempo.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1c0cc1da80..4c025c8d07 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -107,6 +107,7 @@ OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
 OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
 OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
 OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
+OBJS-$(CONFIG_SCALETEMPO_FILTER) += af_scaletempo.o
 OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += af_sidechaincompress.o
 OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
 OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
diff --git a/libavfilter/af_scaletempo.c b/libavfilter/af_scaletempo.c
new file mode 100644
index 00..1e673d3e34
--- /dev/null
+++ b/libavfilter/af_scaletempo.c
@@ -0,0 +1,529 @@
+/*
+ * scaletempo audio filter
+ *
+ * scale tempo while maintaining pitch
+ * (WSOLA technique with cross correlation)
+ * inspired by SoundTouch library by Olli Parviainen
+ *
+ * basic algorithm
+ *   - produce 'stride' output samples per loop
+ *   - consume stride*scale input samples per loop
+ *
+ * to produce smoother transitions between strides, blend next overlap
+ * samples from last stride with correlated samples of current input
+ *
+ * Copyright (c) 2007 Robert Juliano
+ *
+ * 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, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "libavutil/samplefmt.h"
+
+#include "avfilter.h"
+#include "audio.h"
+#include "internal.h"
+
+typedef struct ScaleTempoContext
+{
+AVClass *class;
+
+// stride
+float scale;
+float speed;
+int frames_stride;
+float frames_stride_scaled;
+float frames_stride_error;
+int bytes_per_frame;
+int bytes_stride;
+int bytes_queue;
+int bytes_queued;
+int bytes_to_slide;
+int8_t *buf_queue;
+// overlap
+int samples_overlap;
+int samples_standing;
+int bytes_overlap;
+int bytes_standing;
+void *buf_overlap;
+void *table_blend;
+void (*output_overlap)(struct ScaleTempoContext *s, void *out_buf,
+   int bytes_off);
+// best overlap
+int frames_search;
+int num_channels;
+void *buf_pre_corr;
+void *table_window;
+int (*best_overlap_offset)(struct ScaleTempoContext *s);
+// command line
+float scale_nominal;
+float ms_stride;
+float percent_overlap;
+float ms_search;
+#define SCALE_TEMPO 1
+#define SCALE_PITCH 2
+int speed_opt;
+
+int64_t pts;
+} ScaleTempoContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterChannelLayouts *layouts = NULL;
+AVFilterFormats*formats = NULL;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_S16,
+AV_SAMPLE_FMT_FLT,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts) {
+return AVERROR(ENOMEM);
+}
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats) {
+return AVERROR(ENOMEM);
+}
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+formats = ff_all_samplerates();
+if (!formats) {
+return AVERROR(ENOMEM);
+}
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static int fill_queue(AVFilterContext *ctx, AVFrame *in, int offset)
+{
+ScaleTempoContext *s = ctx->priv;
+int bytes_in = in->nb_samples * s->bytes_per_frame - offset;
+int offset_unchanged = offset;
+
+if (s->bytes_to_slide > 0) {
+if (s->bytes_to_slide < s->bytes_queued) {
+int bytes_move = s->bytes_queued - s->bytes_to_slide;
+
+memmove(s->buf_queue, s->buf_queue + s->bytes_to_slide, 
bytes_move);
+s->bytes_to_slide = 0;
+s->bytes_queued = 

[FFmpeg-devel] [PATCH 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext hw_device_ctx if set

2017-12-02 Thread Aman Gupta
From: Aman Gupta 

---
 libavcodec/mediacodecdec_common.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index cb2f6ae5e5..e524ffe0e4 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "libavutil/common.h"
+#include "libavutil/hwcontext_mediacodec.h"
 #include "libavutil/mem.h"
 #include "libavutil/log.h"
 #include "libavutil/pixfmt.h"
@@ -475,8 +476,12 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 pix_fmt = ff_get_format(avctx, pix_fmts);
 if (pix_fmt == AV_PIX_FMT_MEDIACODEC) {
 AVMediaCodecContext *user_ctx = avctx->hwaccel_context;
+AVMediaCodecDeviceContext *device_ctx = avctx->hw_device_ctx;
 
-if (user_ctx && user_ctx->surface) {
+if (device_ctx && device_ctx->surface) {
+s->surface = ff_mediacodec_surface_ref(device_ctx->surface, avctx);
+av_log(avctx, AV_LOG_INFO, "Using surface %p\n", s->surface);
+} else if (user_ctx && user_ctx->surface) {
 s->surface = ff_mediacodec_surface_ref(user_ctx->surface, avctx);
 av_log(avctx, AV_LOG_INFO, "Using surface %p\n", s->surface);
 }
-- 
2.13.6 (Apple Git-96)

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4()

2017-12-02 Thread Michael Niedermayer
On Sun, Nov 26, 2017 at 12:58:45AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-25 22:49 GMT+01:00 Michael Niedermayer :
> > Fixes: lorex.mp4
> 
> Please mention ticket #6762 if it is related.

yes, it seems a shorter variant of the same file that i worked with

will add ticket #6762
thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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