Re: [FFmpeg-devel] [PATCH 1/1] avformat/tcp: support timeout for getaddrinfo For fixing stucking when resolving addrinfo

[XinZheng Zhang]

On Tue, Jun 7, 2016 at 5:42 AM, Michael Niedermayer
 wrote:
> On Wed, Jun 01, 2016 at 12:03:32PM +0800, XinZheng Zhang wrote:
>> On Tue, May 31, 2016 at 9:33 PM, Hendrik Leppkes  wrote:
>> >
>> > On Tue, May 31, 2016 at 2:58 PM, Xinzheng Zhang  
>> > wrote:
>> > > ---
>> > >  libavformat/tcp.c | 215 
>> > > ++
>> > >  1 file changed, 215 insertions(+)
>> > >
>> >
>> > This whole patch looks extremely complicated and long for something
>> > hidden behind a tiny option not saying much.
>> > Maybe you should start by elaborating in detail what you are trying to
>> > fix, how you are fixing it, and why you choose this approach and not
>> > any others that may appear simpler.
>> >
>>
>> For some ugly network conditions(Eg.Mobile device in a WiFi network,
>> but offline from internet), getaddrinfo() could block tcp_open() for a
>> long time,
>> neither timeout nor interrupt callback can save us.
>>
>> There are serveral way to fix this issue
>> AFAIK. We can use `getaddrinfo_a` on some linux platform
>> http://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html
>> But, it doesn't work on other platforms.
>
> would the getaddrinfo_a() based code be simple ?
> if so i think thats the way to go
>
> If one really wants one could implement getaddrinfo_a() emulation
> with a thread on other platforms. That should still be cleaner then
> stuffing this code into tcp.c
>
> above is just a suggestion
>
> [...]

I thought that create and destory a thread everty time
for reolving addrinfo is such a waste thing, but as said that
there are no global thread pool or other background facility in ffmpeg,
and on most platform there has not getaddrinfo_a().

Wrap there code to a function like getaddrinfo_a(),
will make these horrible thing to be invisible.
Considering that so I choose to stuff these code into tcp.c

I know that I should implement sth maybe called ff_getaddrinfo_a().
But I do not know how...(Specially in iOS and Android platform).
Any suggestion will be helpful, thanks a lot.

Sorry for the late reply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskaenc.c: use metadata key/value to set mastering metadata

[Neil Birkbeck]

The most recent patch should still apply cleanly (unless we have a
better way to set these elements). Thanks

On Tue, Apr 19, 2016 at 8:12 AM, Neil Birkbeck  wrote:
> Updated patch attached.
>
> On Sat, Apr 16, 2016 at 7:08 PM, Michael Niedermayer
>  wrote:
>> On Sun, Apr 03, 2016 at 03:38:33PM -0700, Neil Birkbeck wrote:
>>> Use "master_display" key/value pair to specify mastering metadata in a
>>> similar formatting as accepted by libx265 (unless there is some other
>>> generic way to add side data to a stream from command line).
>>> Currently, the packet side data propagates from an input file to
>>> output file if it is transmuxed (mkv -> mkv). Perhaps we want to also
>>> use this same metadata key in matroskadec to also allow for the
>>> metadata to propagate during transcoding.
>>
>>>  matroskaenc.c |   51 +++
>>>  1 file changed, 47 insertions(+), 4 deletions(-)
>>> d92564f3ec6cf08430a79b64f4d1ec304637afe1  
>>> 0001-lavf-matroskaenc.c-use-metadata-key-value-to-set-mas.patch
>>> From b30d80f6ba4b09811039f64af3e7f709d86df5fe Mon Sep 17 00:00:00 2001
>>> From: Neil Birkbeck 
>>> Date: Fri, 1 Apr 2016 17:02:42 -0700
>>> Subject: [PATCH] lavf/matroskaenc.c: use metadata key/value to set mastering
>>>  metadata
>>>
>>> Add key/value metadata interface to allow command line setting of 
>>> AVMasteringDisplayMetadata. The formatting is the same as the option in 
>>> libx265.
>>>
>>> Signed-off-by: Neil Birkbeck 
>>
>> this does not apply cleanly anymore after codecpar
>>
>> Applying: lavf/matroskaenc.c: use metadata key/value to set mastering 
>> metadata
>> Using index info to reconstruct a base tree...
>> Falling back to patching base and 3-way merge...
>> Auto-merging libavformat/matroskaenc.c
>> CONFLICT (content): Merge conflict in libavformat/matroskaenc.c
>> Failed to merge in the changes.
>> Patch failed at 0001 lavf/matroskaenc.c: use metadata key/value to set 
>> mastering metadata
>> When you have resolved this problem run "git am --resolved".
>> If you would prefer to skip this patch, instead run "git am --skip".
>> To restore the original branch and stop patching run "git am --abort".
>>
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Democracy is the form of government in which you can choose your dictator
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/alsdec: relax opt_order limit

[Michael Niedermayer]

Fixes: Ticket5297

Needs review by maintainer / author to check that this is ok and sufficient
---
 libavcodec/alsdec.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index a7e58a2..9410f52 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -694,7 +694,7 @@ static int read_var_block_data(ALSDecContext *ctx, 
ALSBlockData *bd)
 } else {
 *bd->opt_order = sconf->max_order;
 }
-if (*bd->opt_order > bd->block_length) {
+if (*bd->opt_order > bd->block_length + sconf->max_order) {
 *bd->opt_order = bd->block_length;
 av_log(avctx, AV_LOG_ERROR, "Predictor order too large.\n");
 return AVERROR_INVALIDDATA;
@@ -1252,7 +1252,7 @@ static int revert_channel_correlation(ALSDecContext *ctx, 
ALSBlockData *bd,
 ALSChannelData *ch = cd[c];
 unsigned int   dep = 0;
 unsigned int channels = ctx->avctx->channels;
-unsigned int channel_size = ctx->sconf.frame_length + ctx->sconf.max_order;
+unsigned int channel_size = ctx->sconf.frame_length + 
2*ctx->sconf.max_order;
 
 if (reverted[c])
 return 0;
@@ -1311,7 +1311,7 @@ static int revert_channel_correlation(ALSDecContext *ctx, 
ALSBlockData *bd,
 }
 
 if (FFMIN(begin - 1, begin - 1 + t) < ctx->raw_buffer - master ||
-FFMAX(end   + 1,   end + 1 + t) > ctx->raw_buffer + channels * 
channel_size - master) {
+FFMAX(end   + 1,   end + 1 + t) > ctx->raw_buffer + channels * 
channel_size - master - ctx->sconf.max_order) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"sample pointer range [%p, %p] not contained in 
raw_buffer [%p, %p].\n",
master + FFMIN(begin - 1, begin - 1 + t), master + 
FFMAX(end + 1,   end + 1 + t),
@@ -1333,7 +1333,7 @@ static int revert_channel_correlation(ALSDecContext *ctx, 
ALSBlockData *bd,
 } else {
 
 if (begin - 1 < ctx->raw_buffer - master ||
-end   + 1 > ctx->raw_buffer + channels * channel_size - 
master) {
+end   + 1 > ctx->raw_buffer + channels * channel_size - master 
- ctx->sconf.max_order) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"sample pointer range [%p, %p] not contained in 
raw_buffer [%p, %p].\n",
master + begin - 1, master + end + 1,
@@ -1797,7 +1797,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 ctx->reverted_channels = NULL;
 }
 
-channel_size  = sconf->frame_length + sconf->max_order;
+channel_size  = sconf->frame_length + 2*sconf->max_order;
 
 ctx->prev_raw_samples = av_malloc_array(sconf->max_order, 
sizeof(*ctx->prev_raw_samples));
 ctx->raw_buffer   = av_mallocz_array(avctx->channels * channel_size, 
sizeof(*ctx->raw_buffer));
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] swscale/swscale-test: Code to test scaler with slices

[Pedro Arthur]

Hi, I took the time to investigate it and I find a few bugs which I'm
attaching a patch for them.
Yet I'm not convinced that it is a definitive fix, since the output of
swscale-test differs in some cases when scaling the whole frame or in
slices.
Also there is a few fixes needed in this patch which took me a while to
figure out because I blindly trusted the patch was correct.

2016-06-05 9:27 GMT-03:00 Michael Niedermayer :

> +src_tmp[0] += srcStride[0] * i * STEP;
>
here it should be:
src_tmp[0] += srcStride[0] * i;

+if (src_tmp[2]) {
> +int step = STEP >> desc_src->log2_chroma_h;
>
+src_tmp[1] += srcStride[1] * i * step;
> +src_tmp[2] += srcStride[2] * i * step;
> +}
> +if (src_tmp[3])
> +src_tmp[3] += srcStride[3] * i * STEP;
>
The same applies for the above code.

Regards,
Pedro.
From d0b51102b77e9a883b7b821ecd691ed36cb175ba Mon Sep 17 00:00:00 2001
From: Pedro Arthur 
Date: Wed, 8 Jun 2016 21:36:16 -0300
Subject: [PATCH 1/2] swscale: fix crash with swscale-test when using slices

---
 libswscale/swscale_unscaled.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 4d6cfd1..b231abe 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -575,7 +575,7 @@ static int Rgb16ToPlanarRgb16Wrapper(SwsContext *c, const uint8_t *src[],
 case AV_PIX_FMT_RGB48BE:
 case AV_PIX_FMT_RGBA64LE:
 case AV_PIX_FMT_RGBA64BE:
-packed16togbra16(src[0] + srcSliceY * srcStride[0], srcStride[0],
+packed16togbra16(src[0], srcStride[0],
  dst2013, stride2013, srcSliceH, alpha, swap,
  16 - bpc, c->srcW);
 break;
@@ -583,7 +583,7 @@ static int Rgb16ToPlanarRgb16Wrapper(SwsContext *c, const uint8_t *src[],
 case AV_PIX_FMT_BGR48BE:
 case AV_PIX_FMT_BGRA64LE:
 case AV_PIX_FMT_BGRA64BE:
-packed16togbra16(src[0] + srcSliceY * srcStride[0], srcStride[0],
+packed16togbra16(src[0], srcStride[0],
  dst1023, stride1023, srcSliceH, alpha, swap,
  16 - bpc, c->srcW);
 break;
-- 
1.9.1

From c45a3d6dca86fbf2b622dbbb9f0562de43abab5a Mon Sep 17 00:00:00 2001
From: Pedro Arthur 
Date: Wed, 8 Jun 2016 21:38:49 -0300
Subject: [PATCH 2/2] swscale: fix ring buffer size when scaling slices of a
 frame

The ring buffer size should be able to store input lines
when there is not enough lines to output a single line.
---
 libswscale/slice.c   | 47 +--
 libswscale/swscale.c | 10 ++
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/libswscale/slice.c b/libswscale/slice.c
index 0159a73..3da4136 100644
--- a/libswscale/slice.c
+++ b/libswscale/slice.c
@@ -210,6 +210,42 @@ static void fill_ones(SwsSlice *s, int n, int is16bit)
 }
 }
 
+/*
+ Calculates the minimum ring buffer size, it should be able to store vFilterSize
+ more n lines where n is the max difference between each adjacent slice which 
+ outputs a line.
+ The n lines are needed only when there is not enough src lines to output a single
+ dst line, then we should buffer these lines to process them on the next call to scale.
+*/
+static void get_min_buffer_size(SwsContext *c, int *out_lum_size, int *out_chr_size)
+{
+int lumY;
+int dstH = c->dstH;
+int chrDstH = c->chrDstH;
+int *lumFilterPos = c->vLumFilterPos;
+int *chrFilterPos = c->vChrFilterPos;
+int lumFilterSize = c->vLumFilterSize;
+int chrFilterSize = c->vChrFilterSize;
+int chrSubSample = c->chrSrcVSubSample;
+
+*out_lum_size = lumFilterSize;
+*out_chr_size = chrFilterSize;
+
+for (lumY = 0; lumY < dstH; lumY++) {
+int chrY  = (int64_t)lumY * chrDstH / dstH;
+int nextSlice = FFMAX(lumFilterPos[lumY] + lumFilterSize - 1,
+  ((chrFilterPos[chrY] + chrFilterSize - 1)
+   << chrSubSample));
+
+nextSlice >>= chrSubSample;
+nextSlice <<= chrSubSample;
+(*out_lum_size) = FFMAX((*out_lum_size), nextSlice - lumFilterPos[lumY]);
+(*out_chr_size) = FFMAX((*out_chr_size), (nextSlice >> chrSubSample) - chrFilterPos[chrY]);
+}
+}
+
+
+
 int ff_init_filters(SwsContext * c)
 {
 int i;
@@ -226,6 +262,13 @@ int ff_init_filters(SwsContext * c)
 uint32_t * pal = usePal(c->srcFormat) ? c->pal_yuv : (uint32_t*)c->input_rgb2yuv_table;
 int res = 0;
 
+int lumBufSize;
+int chrBufSize;
+
+get_min_buffer_size(c, , );
+lumBufSize = FFMAX(lumBufSize, c->vLumFilterSize + MAX_LINES_AHEAD);
+chrBufSize = FFMAX(chrBufSize, c->vChrFilterSize + MAX_LINES_AHEAD);
+
 if (c->dstBpc == 16)
 dst_stride <<= 1;
 
@@ -248,13 +291,13 @@ int ff_init_filters(SwsContext * c)
 res = 

Re: [FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Will Kelleher]

On 06/08, Will Kelleher wrote:
> 
> That works for me.  I can update the patch with that warning.  Thanks!
>
Updated patch attached.

>From 3229edf9e52dfd61580209630f20ddef3e39e78e Mon Sep 17 00:00:00 2001
From: Will Kelleher 
Date: Tue, 7 Jun 2016 20:49:48 -0500
Subject: [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

otherwise they leak, contrary to what the documentation seems to say.
---
 libavcodec/vaapi_encode.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 329b33c..01b8c70 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -370,6 +370,29 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 goto fail_at_end;
 }
 
+// We free all of the parameter buffers here.
+// This is not consistent with what VAAPI states is required; under
+// vaDestroyBuffer, it says: "Only call this if the buffer is not
+// going to be passed to vaRenderBuffer" [sic; vaRenderPicture].
+// Doing this here is a pragmatic decision to preferentially support
+// the Intel i965 back-end driver, which does not and has never
+// freed the buffers as required by the specification - if we don't
+// free here, memory will leak for every frame submitted when using
+// that driver.
+// If other drivers are supported in future, this decision may need
+// to be revisted - if the driver really has already freed the
+// buffer, doing so here is disaster for thread-safety because we
+// may free buffers which have been allocated in other threads.
+for(i = 0; i < pic->nb_param_buffers; i++) {
+if (pic->param_buffers[i] != VA_INVALID_ID) {
+vas = vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
+if (vas != 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to destroy param buffer 
%d\n",i);
+}
+pic->param_buffers[i] = VA_INVALID_ID;
+}
+}
+
 pic->encode_issued = 1;
 
 if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
-- 
2.8.0

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

Re: [FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Will Kelleher]

On 06/08, Mark Thompson wrote:
> On 08/06/16 21:02, Will Kelleher wrote:
> > On 06/08, Mark Thompson wrote:
> >> On 08/06/16 18:23, Will Kelleher wrote:
> >>> Hi all -
> >>>
> >>> I'm experiencing some significant heap growth when encoding with VAAPI on
> >>> my Ivy Bridge hardware.  Based on what I'm seeing from Massif, it seems 
> >>> like
> >>> the parameter buffers allocated in vaapi_encode_make_param_buffer are 
> >>> leaking.
> >>>
> >>> I came across this thread [1] that indicates that vaEndPicture might not 
> >>> be
> >>> freeing the param buffers like the libva documentation says it should.
> >>>
> >>> I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on 
> >>> the
> >>> param buffers after vaEndPicture.
> >>>
> >>> When I try that, the leak is gone.
> >>
> >> Yes, I wrote essentially the same code on observing the same issue.
> >>
> >> Unfortunately, you need a lot more machinery to do this safely - the 
> >> change makes all buffer operations thread-unsafe (another thread could 
> >> allocate a buffer with the ID you are about to try to destroy).  That 
> >> results in needing VADisplay-global locks around pretty much everything to 
> >> do with buffers (including any time the user makes use of them).
> >>
> >> I don't much like the idea of writing all the code to have locking 
> >> everywhere (including in all user code talking to libavcodec), so I took 
> >> the cowardly approach of doing nothing and hiding behind the documentation 
> >> :/
> >>
> >> Therefore, dunno.  Maybe we should talk to the libva people about it?
> >>
> >> - Mark
> >>
> > Hmm, good point.
> > 
> > I wonder if this is why libmfx seems to open separate va displays for each 
> > encode/decode session.
> 
> libmfx on Linux isn't really a wrapper over VAAPI, it has an entirely 
> separate proprietary driver underneath which does who knows what.
> 

That's not quite true.  It certainly has some special sauce inside, but it 
seems to use libva for some of it (although it is a special? fork).

When you run a libmfx encode you should see the libva init prints, like this:

libva info: VA-API version 0.35.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0

And I see one of those for each ffmpeg encoding that I start, unlike the vaapi 
encoder, which only opens libva once.

> > Unfortunately unless we can solve this, the encoder is pretty useless for 
> > any long-running encodes.
> > 
> > Talking to the libva people might help, but any fix that requires 
> > modifications to libva/libdrm is
> > less than ideal because it would require people to likely build those 
> > components from source to get
> > a recent enough version for this to work.
> 
> Yeah.  Maybe pragmatic concerns with what we have now should win here - the 
> answer is that we obviously should do this if only the i965 driver is 
> supported (which is mostly true already, though I've tried to not to embed it 
> by making large assumptions like this one).
> 
> > That said... how sure are you about these thread safety concerns?  Did you 
> > witness any instability
> > when you tested your vaDestroyBuffer change?  I've been running an encode 
> > of 12 streams with this
> > patch for 17+ hours now without any issues.  I would have crashed due to 
> > OOM by now without this.
> 
> I didn't, but I never did particularly serious testing with the change (I do 
> not currently have a use case for leaving it encoding something indefinitely).
> 
> The concern is more that any other driver someone tries to use will fall over 
> due to this, not that the i965 one will (given the current setup, I think we 
> believe it won't).
> 
> 
> Ok, I think I'm convinced.  We need a long comment next to it describing all 
> of this problem, though.
> 
> Something like:
> 
> // We free all of the parameter buffers here.
> // This is not consistent with what VAAPI states is required; under
> // vaDestroyBuffer, it says: "Only call this if the buffer is not
> // going to be passed to vaRenderBuffer" [sic; vaRenderPicture].
> // Doing this here is a pragmatic decision to preferentially support
> // the Intel i965 back-end driver, which does not and has never
> // freed the buffers as required by the specification - if we don't
> // free here, memory will leak for every frame submitted when using
> // that driver.
> // If other drivers are supported in future, this decision may need
> // to be revisted - if the driver really has already freed the
> // buffer, doing so here is disaster for thread-safety because we
> // may free buffers which have been allocated in other threads.
> 
> ?

That works for me.  I can update the patch with that warning.  Thanks!

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort

[Lukasz Marek]

On 09.06.2016 00:25, Michael Niedermayer wrote:
> On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote:
>> When writing files to FTP, if the data connection is closed before the
>> control connection, the server may handle it as an aborted file transfer
>> and create and leave the file empty.
> 
> which ftp server, or is that in the RFC, if so please refer to it

RFC is good for reference, unfortunately even popular linux
implementations don't follow it strictly (sometimes it is hard to say
they follow at all some aspects). Regarding aborting and stuff it is
really implementation dependent. I can't remember now which
implementation and what version, but one was totally unresponsive on
control connection while active transfer on data connection, so the only
way to abort it was to close data connection.

Reverting order of closing should be OK, but I'm not really sure
expecting all implementation to send 225/226 code is correct. I would
suggest to at least check state if it is UPLOADING and apply that change
only for this case. Perfectly this behaviour could be enabled by an
option and autodetected in ftp_connect_control_connection when server
send its name (note 220 code's message may be overwritten so an option
to enforce is needed)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort

[Michael Niedermayer]

On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote:
> When writing files to FTP, if the data connection is closed before the
> control connection, the server may handle it as an aborted file transfer
> and create and leave the file empty.

which ftp server, or is that in the RFC, if so please refer to it


> 
> ---
>  libavformat/ftp.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
> index 0663b47..00747bb 100644
> --- a/libavformat/ftp.c
> +++ b/libavformat/ftp.c
> @@ -220,15 +220,21 @@ static int ftp_send_command(FTPContext *s, const char
> *command,
> 
>  static void ftp_close_data_connection(FTPContext *s)
>  {
> -ffurl_closep(>conn_data);
> +static const int close_codes[] = {225, 226, 0};

indention inconsistent

> +
> +if (s->conn_data) {
> +ffurl_closep(>conn_data);
> +// Need to wait for status, or file transfer might be aborted on
> server side
> +ftp_status(s, NULL, close_codes);

patch corrupted by a newline

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [RFC] BSF list API

[Gonzalo Garramuño]

On 08/06/2016 06:34 p.m., Marton Balint wrote:

Hi All,

Please comment, thanks,

Be careful that : in Windows do not currently parse well if you need to 
use them in a path, like F:/filter/ or Z:/movie.  They are parsed as F 
and /filter/ and Z and /movie/ respectively.


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

[FFmpeg-devel] [RFC] BSF list API

[Marton Balint]

Hi All,

My GSOC student Jan is working on improving the tee muxer, and as a side 
project he is also working on converting the tee muxer to the new BSF API.


I have checked his WIP patches, and it seems to me that developing some 
API which we can use for BSF chains would be really useful not only for 
the tee muxer, but for a lot of other places (e.g. ffmpeg.c) as well.


Instead of adding a totally new API, I suggest to use a "container" 
bitstream filter called 'list', which will instantiate the 
"child" bitstream filters and pump the packets through them.


Thanks to the N:M nature of the new BSF api, this should be achievable, 
and we can completely hide for the API user if we are using a single 
bitstream filter, or a chain (list) of several bitstream filters.


The mentioned 'list' bitstream filter could have an AVOption string 
parameter called list which it can parse on init to create the bitstream 
filter chain. The list string would follow the ffmpeg bsf list syntax:

filter1[=opt1=str1/opt2=str2][,filter2]

The list bitstream filter with and empty list can also work as the null 
bitstream filter already discussed on this mailing list.


Please comment, thanks,

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

[FFmpeg-devel] [PATCH] lavc/mediacodec: refactor ff_AMediaCodecList_getCodecByType

[Matthieu Bouron]

From: Matthieu Bouron 

Allows to select a codec (encoder or decoder) only if it supports a
specific profile.

Adds ff_AMediaCodecProfile_getProfileFromAVCodecContext to convert an
AVCodecContext profile to a MediaCodec profile. It only supports H264
for now.

The codepath using MediaCodecList.findDecoderForFormat() (Android >= 5.0)
has been dropped as this method does not allow to select a decoder
compatible with a specific profile.
---
 libavcodec/mediacodec_wrapper.c | 277 ++--
 libavcodec/mediacodec_wrapper.h |   4 +-
 libavcodec/mediacodecdec.c  |   8 +-
 3 files changed, 216 insertions(+), 73 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index c05b6fd..b87e62a 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -26,6 +26,7 @@
 #include "libavutil/mem.h"
 #include "libavutil/avstring.h"
 
+#include "avcodec.h"
 #include "ffjni.h"
 #include "version.h"
 #include "mediacodec_wrapper.h"
@@ -41,9 +42,26 @@ struct JNIAMediaCodecListFields {
 
 jclass mediacodec_info_class;
 jmethodID get_name_id;
+jmethodID get_codec_capabilities_id;
 jmethodID get_supported_types_id;
 jmethodID is_encoder_id;
 
+jclass codec_capabilities_class;
+jfieldID color_formats_id;
+jfieldID profile_levels_id;
+
+jclass codec_profile_level_class;
+jfieldID profile_id;
+jfieldID level_id;
+
+jfieldID avc_profile_baseline_id;
+jfieldID avc_profile_main_id;
+jfieldID avc_profile_extended_id;
+jfieldID avc_profile_high_id;
+jfieldID avc_profile_high10_id;
+jfieldID avc_profile_high422_id;
+jfieldID avc_profile_high444_id;
+
 } JNIAMediaCodecListFields;
 
 static const struct FFJniField jni_amediacodeclist_mapping[] = {
@@ -56,9 +74,26 @@ static const struct FFJniField jni_amediacodeclist_mapping[] 
= {
 
 { "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_info_class), 1 },
 { "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, get_name_id), 1 },
+{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_capabilities_id), 1 },
 { "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_supported_types_id), 1 },
 { "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
 
+{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_capabilities_class), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, 
color_formats_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
offsetof(struct JNIAMediaCodecListFields, profile_levels_id), 1 },
+
+{ "android/media/MediaCodecInfo$CodecProfileLevel", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_profile_level_class), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", "profile", "I", 
FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, profile_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", "level", "I", 
FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, level_id), 1 },
+
+{ "android/media/MediaCodecInfo$CodecProfileLevel", 
"AVCProfileBaseline", "I", FF_JNI_STATIC_FIELD, offsetof(struct 
JNIAMediaCodecListFields, avc_profile_baseline_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", "AVCProfileMain", 
"I", FF_JNI_STATIC_FIELD, offsetof(struct JNIAMediaCodecListFields, 
avc_profile_main_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", 
"AVCProfileExtended", "I", FF_JNI_STATIC_FIELD, offsetof(struct 
JNIAMediaCodecListFields, avc_profile_extended_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", "AVCProfileHigh", 
"I", FF_JNI_STATIC_FIELD, offsetof(struct JNIAMediaCodecListFields, 
avc_profile_high_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", 
"AVCProfileHigh10", "I", FF_JNI_STATIC_FIELD, offsetof(struct 
JNIAMediaCodecListFields, avc_profile_high10_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", 
"AVCProfileHigh422", "I", FF_JNI_STATIC_FIELD, offsetof(struct 
JNIAMediaCodecListFields, avc_profile_high422_id), 1 },
+{ "android/media/MediaCodecInfo$CodecProfileLevel", 
"AVCProfileHigh444", "I", FF_JNI_STATIC_FIELD, offsetof(struct 

Re: [FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Mark Thompson]

On 08/06/16 21:02, Will Kelleher wrote:
> On 06/08, Mark Thompson wrote:
>> On 08/06/16 18:23, Will Kelleher wrote:
>>> Hi all -
>>>
>>> I'm experiencing some significant heap growth when encoding with VAAPI on
>>> my Ivy Bridge hardware.  Based on what I'm seeing from Massif, it seems like
>>> the parameter buffers allocated in vaapi_encode_make_param_buffer are 
>>> leaking.
>>>
>>> I came across this thread [1] that indicates that vaEndPicture might not be
>>> freeing the param buffers like the libva documentation says it should.
>>>
>>> I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on the
>>> param buffers after vaEndPicture.
>>>
>>> When I try that, the leak is gone.
>>
>> Yes, I wrote essentially the same code on observing the same issue.
>>
>> Unfortunately, you need a lot more machinery to do this safely - the change 
>> makes all buffer operations thread-unsafe (another thread could allocate a 
>> buffer with the ID you are about to try to destroy).  That results in 
>> needing VADisplay-global locks around pretty much everything to do with 
>> buffers (including any time the user makes use of them).
>>
>> I don't much like the idea of writing all the code to have locking 
>> everywhere (including in all user code talking to libavcodec), so I took the 
>> cowardly approach of doing nothing and hiding behind the documentation :/
>>
>> Therefore, dunno.  Maybe we should talk to the libva people about it?
>>
>> - Mark
>>
> Hmm, good point.
> 
> I wonder if this is why libmfx seems to open separate va displays for each 
> encode/decode session.

libmfx on Linux isn't really a wrapper over VAAPI, it has an entirely separate 
proprietary driver underneath which does who knows what.

> Unfortunately unless we can solve this, the encoder is pretty useless for any 
> long-running encodes.
> 
> Talking to the libva people might help, but any fix that requires 
> modifications to libva/libdrm is
> less than ideal because it would require people to likely build those 
> components from source to get
> a recent enough version for this to work.

Yeah.  Maybe pragmatic concerns with what we have now should win here - the 
answer is that we obviously should do this if only the i965 driver is supported 
(which is mostly true already, though I've tried to not to embed it by making 
large assumptions like this one).

> That said... how sure are you about these thread safety concerns?  Did you 
> witness any instability
> when you tested your vaDestroyBuffer change?  I've been running an encode of 
> 12 streams with this
> patch for 17+ hours now without any issues.  I would have crashed due to OOM 
> by now without this.

I didn't, but I never did particularly serious testing with the change (I do 
not currently have a use case for leaving it encoding something indefinitely).

The concern is more that any other driver someone tries to use will fall over 
due to this, not that the i965 one will (given the current setup, I think we 
believe it won't).


Ok, I think I'm convinced.  We need a long comment next to it describing all of 
this problem, though.

Something like:

// We free all of the parameter buffers here.
// This is not consistent with what VAAPI states is required; under
// vaDestroyBuffer, it says: "Only call this if the buffer is not
// going to be passed to vaRenderBuffer" [sic; vaRenderPicture].
// Doing this here is a pragmatic decision to preferentially support
// the Intel i965 back-end driver, which does not and has never
// freed the buffers as required by the specification - if we don't
// free here, memory will leak for every frame submitted when using
// that driver.
// If other drivers are supported in future, this decision may need
// to be revisted - if the driver really has already freed the
// buffer, doing so here is disaster for thread-safety because we
// may free buffers which have been allocated in other threads.

?

- Mark

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

Re: [FFmpeg-devel] [PATCH] aacsbr: reduce element type mismatch warning severity

[Rostislav Pehlivanov]

On 4 June 2016 at 20:37, Rostislav Pehlivanov  wrote:

> All HE-AAC samples with an LFE channel make this warning get spammed on
> every frame. Turning off SBR for LFE channels makes sense (since it has
> much less coefficients than normal channels do), so this error print is
> of no value in this case.
> It makes sense to keep the error in other cases, hence why it's still
> around, degraded to warning severity since the decoder will still
> attempt to decode without SBR.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aacsbr_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
> index 733e619..5110542 100644
> --- a/libavcodec/aacsbr_template.c
> +++ b/libavcodec/aacsbr_template.c
> @@ -1473,7 +1473,7 @@ void AAC_RENAME(ff_sbr_apply)(AACContext *ac,
> SpectralBandReplication *sbr, int
>  int err;
>
>  if (id_aac != sbr->id_aac) {
> -av_log(ac->avctx, AV_LOG_ERROR,
> +av_log(ac->avctx, id_aac == TYPE_LFE ? AV_LOG_VERBOSE :
> AV_LOG_WARNING,
>  "element type mismatch %d != %d\n", id_aac, sbr->id_aac);
>  sbr_turnoff(sbr);
>  }
> --
> 2.8.1.369.geae769a
>
>
Pushed
More and more users were getting fooled into thinking they have invalid
files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Will Kelleher]

On 06/08, Mark Thompson wrote:
> On 08/06/16 18:23, Will Kelleher wrote:
> > Hi all -
> > 
> > I'm experiencing some significant heap growth when encoding with VAAPI on
> > my Ivy Bridge hardware.  Based on what I'm seeing from Massif, it seems like
> > the parameter buffers allocated in vaapi_encode_make_param_buffer are 
> > leaking.
> > 
> > I came across this thread [1] that indicates that vaEndPicture might not be
> > freeing the param buffers like the libva documentation says it should.
> > 
> > I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on the
> > param buffers after vaEndPicture.
> > 
> > When I try that, the leak is gone.
> 
> Yes, I wrote essentially the same code on observing the same issue.
> 
> Unfortunately, you need a lot more machinery to do this safely - the change 
> makes all buffer operations thread-unsafe (another thread could allocate a 
> buffer with the ID you are about to try to destroy).  That results in needing 
> VADisplay-global locks around pretty much everything to do with buffers 
> (including any time the user makes use of them).
> 
> I don't much like the idea of writing all the code to have locking everywhere 
> (including in all user code talking to libavcodec), so I took the cowardly 
> approach of doing nothing and hiding behind the documentation :/
> 
> Therefore, dunno.  Maybe we should talk to the libva people about it?
> 
> - Mark
>
Hmm, good point.

I wonder if this is why libmfx seems to open separate va displays for each 
encode/decode session.

Unfortunately unless we can solve this, the encoder is pretty useless for any 
long-running encodes.

Talking to the libva people might help, but any fix that requires modifications 
to libva/libdrm is
less than ideal because it would require people to likely build those 
components from source to get
a recent enough version for this to work.

That said... how sure are you about these thread safety concerns?  Did you 
witness any instability
when you tested your vaDestroyBuffer change?  I've been running an encode of 12 
streams with this
patch for 17+ hours now without any issues.  I would have crashed due to OOM by 
now without this.

will

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fffmpeg.org%2fmailman%2flistinfo%2fffmpeg-devel=01%7c01%7cwkelleher%40gogoair.com%7c74085da316e24558151d08d38fccdd3a%7c2e6508518649457ea18abc0264c3b7d0%7c1=67%2btJgwLlFuEtAvLgP%2f6FP0Y8WBmzpxyV0lBLXCsCOQ%3d
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/src_movie: call open_stream after guess_channel_layout

[Muhammad Faiz]

On Thu, Jun 2, 2016 at 3:01 PM, Muhammad Faiz  wrote:
> fix error 'Channel layout change is not supported' when
> opening wav file
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/src_movie.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

applied

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

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[James Almer]

On 6/8/2016 1:49 PM, Michael Niedermayer wrote:
> On Wed, Jun 08, 2016 at 12:04:44AM -0300, James Almer wrote:
>> On 5/31/2016 4:23 PM, Michael Niedermayer wrote:
>>> adding demuxer and other logs should be easy
>>> This forces single threaded decoding for simplicity
>>> It also requires pthreads, this could be avoided either with
>>> some lockless tricks or simply by assuming av_log would never be called from
>>> another thread.
>>>
>>> doc/ffprobe.xsd update missing (TODO & help welcome)
>>>
>>> Fixes Ticket5521
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  ffprobe.c |  154 
>>> -
>>>  1 file changed, 153 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/ffprobe.c b/ffprobe.c
>>> index a7e329c..07b61ec 100644
>>> --- a/ffprobe.c
>>> +++ b/ffprobe.c
>>> @@ -49,6 +49,19 @@
>>>  #include "libpostproc/postprocess.h"
>>>  #include "cmdutils.h"
>>>  
>>> +#if HAVE_PTHREADS
>>> +#  include 
>>> +#else
>>> +#  ifdef pthread_mutex_lock
>>> +#undef pthread_mutex_lock
>>> +#  endif
>>> +#  define pthread_mutex_lock(a)
>>> +#  ifdef pthread_mutex_unlock
>>> +#undef pthread_mutex_unlock
>>> +#  endif
>>> +#  define pthread_mutex_unlock(a)
>>> +#endif
>>
>> Why are you not using the compat wrappers here? These are simple
>> mutex locks that don't even use static init, so i don't see why
>> they wouldn't work with w32threads or os2threads.
> 
> i just used the same as ffmpeg.c does

That one should also be checked. Seems to be only pthread_join,
pthread_create, both supported by the wrappers, and lavu's threaded
message API, which also uses the wrappers.

> 
> but locally changed as:
> no idea if it works on os2 or w32

Compiles and seems to work after a quick test with mingw-w64.

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

Re: [FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Mark Thompson]

On 08/06/16 18:23, Will Kelleher wrote:
> Hi all -
> 
> I'm experiencing some significant heap growth when encoding with VAAPI on
> my Ivy Bridge hardware.  Based on what I'm seeing from Massif, it seems like
> the parameter buffers allocated in vaapi_encode_make_param_buffer are leaking.
> 
> I came across this thread [1] that indicates that vaEndPicture might not be
> freeing the param buffers like the libva documentation says it should.
> 
> I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on the
> param buffers after vaEndPicture.
> 
> When I try that, the leak is gone.

Yes, I wrote essentially the same code on observing the same issue.

Unfortunately, you need a lot more machinery to do this safely - the change 
makes all buffer operations thread-unsafe (another thread could allocate a 
buffer with the ID you are about to try to destroy).  That results in needing 
VADisplay-global locks around pretty much everything to do with buffers 
(including any time the user makes use of them).

I don't much like the idea of writing all the code to have locking everywhere 
(including in all user code talking to libavcodec), so I took the cowardly 
approach of doing nothing and hiding behind the documentation :/

Therefore, dunno.  Maybe we should talk to the libva people about it?

- Mark

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: set range on fps/rate/r option

[Muhammad Faiz]

On Wed, Jun 8, 2016 at 9:59 PM, Michael Niedermayer
 wrote:
> On Wed, Jun 08, 2016 at 07:46:07AM +0700, Muhammad Faiz wrote:
>> see Ticket #5618
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavfilter/avf_showcqt.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> probably (1) ok
>
> (1) (unless a different meaning for max/min is intended)
>
Applied
But this doesn't mean for fixing Ticket #5618.
Also some other filters that have AV_OPT_TYPE_VIDEO_RATE option
probably need to be fixed.

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: cqt_calc optimization on x86

[Muhammad Faiz]

On Wed, Jun 8, 2016 at 11:34 PM, James Almer  wrote:
> On 6/7/2016 6:18 AM, Muhammad Faiz wrote:
 +sub lend, 2
 >> +lea dstq, [dstq + 16]
>>> >
>>> > Use add
>>> >
 >> +lea coeffsq, [coeffsq + 2*Coeffs.sizeof]
>>> >
>>> > Same, assuming sizeof is an immediate.
>>> >
>> This is optimization to separate sub and jnz with lea.
>
> Does it make a noticeable difference? We don't really bother
> keeping the instruction that sets the flag and the one that
> checks it separated anywhere else, so i wonder.
>
I don't know.

>> Using add will clobber flag register.
>
> You could keep the coeffsq lea but change the dstq into an add
> and move it above the sub instruction. No need for two slow leas
> for the above purpose.
>
OK, probably add is faster.
But AMD64 optimization guide said that lea instr have a latency 1
when there are two source operand (so it is as fast as add)
Anyway, this code is not the critical path, so measuring faster one
is difficult.

>> Also lea does not need rex prefix
>
> add dstq, 16 seems to be four bytes, same as lea dstq [dstq+16],
> at least on win64.
I'm sorry, I'm wrong. It uses rex prefix

>
 +SELECT_CQT_CALC(sse,  SSE,  4, 0);
 >> +SELECT_CQT_CALC(sse3, SSE3, 4, 0);
 >> +SELECT_CQT_CALC(avx,  AVX,  8, 01452367);
>>> >
>>> > Use AVX_FAST, so this function will not be used on CPUs that set the
>>> > AV_CPU_FLAG_AVXSLOW flag.
>>> >
 >> +SELECT_CQT_CALC(fma3, FMA3, 8, 01452367);
>>> >
>>> > Same, use FMA3_FAST. The result will then be the FMA3 version used by
>>> > Intel CPUs and hopefully AMD Zen, and the FMA4 one by Bulldozer based
>>> > CPUs.
>>> >
 >> +SELECT_CQT_CALC(fma4, FMA4, 8, 01452367);
 >> +}
 >>
>>> >
>> OK, also reorder (FMA4 before AVX because AVX/ymm without FMA4 is faster than
>> FMA4/xmm)
>
> Not in any machine supporting FMA4. And they will not use the
> AVX or FMA3 functions here because they set the avxslow flag,
> which the EXTERNAL_*_FAST macros check for.
>
> You could have kept the FMA4 init at the end and it would be
> functionally the same, but in any case it's purely cosmetic.
>
If there is machine that support AVX (and fast ymm), FMA3 and FMA4,
without reorder the selected code is FMA4.

Anyway, I have applied the patch.

Thank's for the review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[Dave Rice]

> On Jun 8, 2016, at 12:30 PM, Michael Niedermayer  
> wrote:
> 
> On Tue, Jun 07, 2016 at 08:06:35PM -0400, Dave Rice wrote:
>> 
>>> On May 31, 2016, at 3:23 PM, Michael Niedermayer  
>>> wrote:
>>> 
>>> adding demuxer and other logs should be easy
>>> This forces single threaded decoding for simplicity
>>> It also requires pthreads, this could be avoided either with
>>> some lockless tricks or simply by assuming av_log would never be called from
>>> another thread.
>> 
>> I’ve been testing this patch, but currently the logging does not appear 
>> within the log node. For instance with a fuzzed mpeg2video in QuickTime when 
>> I run:
>> 
>> ./ffprobe -i /Users/davidrice/fuzzed_mpeg2video.mov -show_log 1 -show_frames 
>> -of xml
> [...]
>> 
>> When the mpeg2video decoding log appears in sdterr, then the  node is 
>> written but empty. During a frame when there is no logged message, there is 
>> no  node.
>> 
>> Also I’m uncertain what the value to use with -show_log means. I’m using 
>> -show_log 1 for now. Is this for verbosity?
> 
> you need to set the log level in -show_log high enough so the messages
> that you are interrested in are included

OK, the value just needs to be higher than I expected.

I created a test file with:
ffmpeg -f lavfi -i testsrc -bsf noise -t 1 -c:v mpeg2video fuzzed_mpeg2video.mov

I don't actually get log info until the -show_log value is up to 16. Then this 
works:
ffprobe fuzzed_mpeg2video.mov -show_log 16 -show_frames -of xml

But it outputs invalid xml:


<(null) key="context" value="mpeg2video"/>
 level="16" category="6"<(null) key="message" 
value="[mpeg2video @ 0x7fa4a380] skipped MB in I frame at 3 0
"/>
<(null) key="context" value="mpeg2video"/>
 level="16" category="6"<(null) key="message" 
value="[mpeg2video @ 0x7fa4a380] ac-tex damaged at 16 9
"/>
<(null) key="context" value="mpeg2video"/>
 level="16" category="6"<(null) key="message" 
value="[mpeg2video @ 0x7fa4a380] ac-tex damaged at 11 11
"/>
<(null) key="context" value="mpeg2video"/>
 level="16" category="6"<(null) key="message" 
value="[mpeg2video @ 0x7fa4a380] invalid mb type in I Frame at 9 13
"/>
<(null) key="context" value="mpeg2video"/>
 level="16" category="6"<(null) key="message" 
value="[mpeg2video @ 0x7fa4a380] Warning MVs not available
"/>


The 'log' node is called '(null)' and the level and category attributes are 
outside of a node.

> all messages are still printed to stderr too, maybe that is confusing
> but feels consistent behavior

I agree.

[...]

Dave Rice


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters

[Jon Toohill]

Michael et al., is this good to merge as-is? I just tested and a round trip
with ffmpeg from wav -> mp3 -> wav retains the correct number of samples.


Jon Toohill |  Google Play Music |  jtooh...@google.com |  (650) 215-0770

On Wed, Jun 1, 2016 at 5:58 PM, Jon Toohill  wrote:

> Based on my understanding of [1], these values in the Info tag specify
> only the encoder delay/padding, which matches the documentation for these
> fields. It looks like other formats are using the fields that way as well.
>
> I think the extra 528 + 1 samples are the decoder delay [2]. It looks like
> libmp3lame adds the 528 + 1 only to have mp3dec subtract it, so I'm not
> sure why that's done. IIUC start_skip_samples is the mechanism that
> actually accounts for the extra delay when decoding.
>
> [1]: http://gabriel.mp3-tech.org/mp3infotag.html#delays
> [2]: http://lame.sourceforge.net/tech-FAQ.txt
>
>
>
> Jon Toohill |  Google Play Music |  jtooh...@google.com |  (650) 215-0770
>
> On Thu, May 26, 2016 at 7:51 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Wed, May 25, 2016 at 09:56:59AM -0700, Jon Toohill wrote:
>> > ---
>> >  libavformat/mp3dec.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
>> > index 3725d67..192f5ef 100644
>> > --- a/libavformat/mp3dec.c
>> > +++ b/libavformat/mp3dec.c
>> > @@ -234,6 +234,8 @@ static void mp3_parse_info_tag(AVFormatContext *s,
>> AVStream *st,
>> >
>> >  mp3->start_pad = v>>12;
>> >  mp3->  end_pad = v&4095;
>> > +st->codecpar->initial_padding = mp3->start_pad;
>> > +st->codecpar->trailing_padding = mp3->end_pad;
>> >  st->start_skip_samples = mp3->start_pad + 528 + 1;
>> >  if (mp3->frames) {
>> >  st->first_discard_sample = -mp3->end_pad + 528 + 1 +
>> mp3->frames * (int64_t)spf;
>>
>> is the 528 + 1 difference intended to
>> start_skip_samples/first_discard_sample
>> ?
>> mp3enc stores par->initial_padding - 528 - 1
>>
>> [...]
>>
>> --
>> 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.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vaapi_encode: explicitly free buffers after vaEndPicture

[Will Kelleher]

Hi all -

I'm experiencing some significant heap growth when encoding with VAAPI on
my Ivy Bridge hardware.  Based on what I'm seeing from Massif, it seems like
the parameter buffers allocated in vaapi_encode_make_param_buffer are leaking.

I came across this thread [1] that indicates that vaEndPicture might not be
freeing the param buffers like the libva documentation says it should.

I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on the
param buffers after vaEndPicture.

When I try that, the leak is gone.

Thoughts?

Thanks,

will

1: https://lists.freedesktop.org/archives/libva/2012-July/000952.html
2: https://github.com/BtbN/vlc-vaapi-enc/blob/master/vlc-h264-vaapi-enc.c

---
 libavcodec/vaapi_encode.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 329b33c..6fca815 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -370,6 +370,19 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 goto fail_at_end;
 }
 
+// Although the documentation says that vaEndPicture will free these 
buffers,
+// in practice that appears not to be the case. We need to explicitly free
+// them to avoid a massive leak.
+for(i = 0; i < pic->nb_param_buffers; i++) {
+if (pic->param_buffers[i] != VA_INVALID_ID) {
+vas = vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
+if (vas != 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to destroy param buffer 
%d\n",i);
+}
+pic->param_buffers[i] = VA_INVALID_ID;
+}
+}
+
 pic->encode_issued = 1;
 
 if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
-- 
2.8.0

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

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[Michael Niedermayer]

On Wed, Jun 08, 2016 at 12:04:44AM -0300, James Almer wrote:
> On 5/31/2016 4:23 PM, Michael Niedermayer wrote:
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided either with
> > some lockless tricks or simply by assuming av_log would never be called from
> > another thread.
> > 
> > doc/ffprobe.xsd update missing (TODO & help welcome)
> > 
> > Fixes Ticket5521
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  ffprobe.c |  154 
> > -
> >  1 file changed, 153 insertions(+), 1 deletion(-)
> > 
> > diff --git a/ffprobe.c b/ffprobe.c
> > index a7e329c..07b61ec 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -49,6 +49,19 @@
> >  #include "libpostproc/postprocess.h"
> >  #include "cmdutils.h"
> >  
> > +#if HAVE_PTHREADS
> > +#  include 
> > +#else
> > +#  ifdef pthread_mutex_lock
> > +#undef pthread_mutex_lock
> > +#  endif
> > +#  define pthread_mutex_lock(a)
> > +#  ifdef pthread_mutex_unlock
> > +#undef pthread_mutex_unlock
> > +#  endif
> > +#  define pthread_mutex_unlock(a)
> > +#endif
> 
> Why are you not using the compat wrappers here? These are simple
> mutex locks that don't even use static init, so i don't see why
> they wouldn't work with w32threads or os2threads.

i just used the same as ffmpeg.c does

but locally changed as:
no idea if it works on os2 or w32

diff --git a/ffprobe.c b/ffprobe.c
index 07b61ec..ef6d4db 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -49,9 +49,9 @@
 #include "libpostproc/postprocess.h"
 #include "cmdutils.h"

-#if HAVE_PTHREADS
-#  include 
-#else
+#include "libavutil/thread.h"
+
+#if !HAVE_THREADS
 #  ifdef pthread_mutex_lock
 #undef pthread_mutex_lock
 #  endif
@@ -274,7 +274,7 @@ static uint64_t *nb_streams_packets;
 static uint64_t *nb_streams_frames;
 static int *selected_streams;

-#if HAVE_PTHREADS
+#if HAVE_THREADS
 pthread_mutex_t log_mutex;
 #endif
 typedef struct LogBuffer {
@@ -302,7 +302,7 @@ static void log_callback(void *ptr, int level, const char 
*fmt, va_list vl)
 av_log_format_line(ptr, level, fmt, vl2, line, sizeof(line), 
_prefix);
 va_end(vl2);

-#if HAVE_PTHREADS
+#if HAVE_THREADS
 pthread_mutex_lock(_mutex);

 new_log_buffer = av_realloc_array(log_buffer, log_buffer_size + 1, 
sizeof(*log_buffer));
@@ -338,7 +338,7 @@ static void ffprobe_cleanup(int ret)
 for (i = 0; i < FF_ARRAY_ELEMS(sections); i++)
 av_dict_free(&(sections[i].entries_to_show));

-#if HAVE_PTHREADS
+#if HAVE_THREADS
 pthread_mutex_destroy(_mutex);
 #endif
 }
@@ -3332,7 +3332,7 @@ static const OptionDef real_options[] = {
   "show a particular entry from the format/container info", "entry" },
 { "show_entries", HAS_ARG, {.func_arg = opt_show_entries},
   "show a set of specified entries", "entry_list" },
-#if HAVE_PTHREADS
+#if HAVE_THREADS
 { "show_log", OPT_INT|HAS_ARG, {(void*)_show_log}, "show log" },
 #endif
 { "show_packets", 0, {(void*)_show_packets}, "show packets info" },
@@ -3379,7 +3379,7 @@ int main(int argc, char **argv)
 char *w_name = NULL, *w_args = NULL;
 int ret, i;

-#if HAVE_PTHREADS
+#if HAVE_THREADS
 ret = pthread_mutex_init(_mutex, NULL);
 if (ret != 0) {
 goto end;

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

It is what and why we do it that matters, not just one of them.


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/avf_showcqt: cqt_calc optimization on x86

[James Almer]

On 6/7/2016 6:18 AM, Muhammad Faiz wrote:
>>> +sub lend, 2
>>> >> +lea dstq, [dstq + 16]
>> >
>> > Use add
>> >
>>> >> +lea coeffsq, [coeffsq + 2*Coeffs.sizeof]
>> >
>> > Same, assuming sizeof is an immediate.
>> >
> This is optimization to separate sub and jnz with lea.

Does it make a noticeable difference? We don't really bother
keeping the instruction that sets the flag and the one that
checks it separated anywhere else, so i wonder.

> Using add will clobber flag register.

You could keep the coeffsq lea but change the dstq into an add
and move it above the sub instruction. No need for two slow leas
for the above purpose.

> Also lea does not need rex prefix

add dstq, 16 seems to be four bytes, same as lea dstq [dstq+16],
at least on win64.

>>> +SELECT_CQT_CALC(sse,  SSE,  4, 0);
>>> >> +SELECT_CQT_CALC(sse3, SSE3, 4, 0);
>>> >> +SELECT_CQT_CALC(avx,  AVX,  8, 01452367);
>> >
>> > Use AVX_FAST, so this function will not be used on CPUs that set the
>> > AV_CPU_FLAG_AVXSLOW flag.
>> >
>>> >> +SELECT_CQT_CALC(fma3, FMA3, 8, 01452367);
>> >
>> > Same, use FMA3_FAST. The result will then be the FMA3 version used by
>> > Intel CPUs and hopefully AMD Zen, and the FMA4 one by Bulldozer based
>> > CPUs.
>> >
>>> >> +SELECT_CQT_CALC(fma4, FMA4, 8, 01452367);
>>> >> +}
>>> >>
>> >
> OK, also reorder (FMA4 before AVX because AVX/ymm without FMA4 is faster than
> FMA4/xmm)

Not in any machine supporting FMA4. And they will not use the
AVX or FMA3 functions here because they set the avxslow flag,
which the EXTERNAL_*_FAST macros check for.

You could have kept the FMA4 init at the end and it would be
functionally the same, but in any case it's purely cosmetic.

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

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[Michael Niedermayer]

On Tue, Jun 07, 2016 at 08:06:35PM -0400, Dave Rice wrote:
> 
> > On May 31, 2016, at 3:23 PM, Michael Niedermayer  
> > wrote:
> > 
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided either with
> > some lockless tricks or simply by assuming av_log would never be called from
> > another thread.
> 
> I’ve been testing this patch, but currently the logging does not appear 
> within the log node. For instance with a fuzzed mpeg2video in QuickTime when 
> I run:
> 
> ./ffprobe -i /Users/davidrice/fuzzed_mpeg2video.mov -show_log 1 -show_frames 
> -of xml
[...]
>
> When the mpeg2video decoding log appears in sdterr, then the  node is 
> written but empty. During a frame when there is no logged message, there is 
> no  node.
> 
> Also I’m uncertain what the value to use with -show_log means. I’m using 
> -show_log 1 for now. Is this for verbosity?

you need to set the log level in -show_log high enough so the messages
that you are interrested in are included

all messages are still printed to stderr too, maybe that is confusing
but feels consistent behavior

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] Changelog : add OpenExr improvements

[Martin Vignali]

Hello,

Yes it's planned. (with YCbCr, and display window).

Martin
Jokyo images

2016-06-08 17:26 GMT+02:00 Piotr Bandurski :

> Hi,
>
> > In attach, patch to add entry to the changelog, for recently add OpenExr
> > features
>
> Could you add support for grayscale images as well?
>
> https://trac.ffmpeg.org/ticket/5621
>
> Regards
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[Michael Niedermayer]

On Sun, Jun 05, 2016 at 12:56:08PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2016-05-31 21:23:27 +0200, Michael Niedermayer encoded:
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided either with
> > some lockless tricks or simply by assuming av_log would never be called from
> > another thread.
> > 
> > doc/ffprobe.xsd update missing (TODO & help welcome)
> > 
> > Fixes Ticket5521
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  ffprobe.c |  154 
> > -
> >  1 file changed, 153 insertions(+), 1 deletion(-)
> > 
> > diff --git a/ffprobe.c b/ffprobe.c
> > index a7e329c..07b61ec 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -49,6 +49,19 @@
> >  #include "libpostproc/postprocess.h"
> >  #include "cmdutils.h"
> >  
> 
> > +#if HAVE_PTHREADS
> > +#  include 
> > +#else
> > +#  ifdef pthread_mutex_lock
> > +#undef pthread_mutex_lock
> > +#  endif
> > +#  define pthread_mutex_lock(a)
> > +#  ifdef pthread_mutex_unlock
> > +#undef pthread_mutex_unlock
> > +#  endif
> > +#  define pthread_mutex_unlock(a)
> > +#endif
> > +
> 
> any chance to move this ifdeffery to lavu?

iam not sure what you suggest exactly ?


> 
> >  typedef struct InputStream {
> >  AVStream *st;
> >  
> > @@ -84,6 +97,7 @@ static int do_show_library_versions = 0;
> >  static int do_show_pixel_formats = 0;
> >  static int do_show_pixel_format_flags = 0;
> >  static int do_show_pixel_format_components = 0;
> > +static int do_show_log = 0;
> >  
> >  static int do_show_chapter_tags = 0;
> >  static int do_show_format_tags = 0;
> > @@ -92,6 +106,7 @@ static int do_show_program_tags = 0;
> >  static int do_show_stream_tags = 0;
> >  static int do_show_packet_tags = 0;
> >  
> > +
> >  static int show_value_unit  = 0;
> >  static int use_value_prefix = 0;
> >  static int use_byte_value_binary_prefix = 0;
> > @@ -146,6 +161,8 @@ typedef enum {
> >  SECTION_ID_FRAME_TAGS,
> >  SECTION_ID_FRAME_SIDE_DATA_LIST,
> >  SECTION_ID_FRAME_SIDE_DATA,
> > +SECTION_ID_FRAME_LOG,
> > +SECTION_ID_FRAME_LOGS,
> >  SECTION_ID_LIBRARY_VERSION,
> >  SECTION_ID_LIBRARY_VERSIONS,
> >  SECTION_ID_PACKET,
> > @@ -185,10 +202,12 @@ static struct section sections[] = {
> >  [SECTION_ID_FORMAT] = { SECTION_ID_FORMAT, "format", 0, { 
> > SECTION_ID_FORMAT_TAGS, -1 } },
> >  [SECTION_ID_FORMAT_TAGS] ={ SECTION_ID_FORMAT_TAGS, "tags", 
> > SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", 
> > .unique_name = "format_tags" },
> >  [SECTION_ID_FRAMES] = { SECTION_ID_FRAMES, "frames", 
> > SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME, SECTION_ID_SUBTITLE, -1 } },
> > -[SECTION_ID_FRAME] =  { SECTION_ID_FRAME, "frame", 0, { 
> > SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, -1 } },
> > +[SECTION_ID_FRAME] =  { SECTION_ID_FRAME, "frame", 0, { 
> > SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, 
> > SECTION_ID_FRAME_LOGS, -1 } },
> >  [SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS, "tags", 
> > SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", 
> > .unique_name = "frame_tags" },
> >  [SECTION_ID_FRAME_SIDE_DATA_LIST] ={ SECTION_ID_FRAME_SIDE_DATA_LIST, 
> > "side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 } 
> > },
> >  [SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA, 
> > "side_data", 0, { -1 } },
> > +[SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs", 
> > SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
> > +[SECTION_ID_FRAME_LOG] =  { SECTION_ID_FRAME_LOG, "log", 
> > SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 } },
> >  [SECTION_ID_LIBRARY_VERSIONS] =   { SECTION_ID_LIBRARY_VERSIONS, 
> > "library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 
> > } },
> >  [SECTION_ID_LIBRARY_VERSION] ={ SECTION_ID_LIBRARY_VERSION, 
> > "library_version", 0, { -1 } },
> >  [SECTION_ID_PACKETS] ={ SECTION_ID_PACKETS, "packets", 
> > SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} },
> > @@ -255,11 +274,73 @@ static uint64_t *nb_streams_packets;
> >  static uint64_t *nb_streams_frames;
> >  static int *selected_streams;
> >  
> > +#if HAVE_PTHREADS
> > +pthread_mutex_t log_mutex;
> > +#endif
> > +typedef struct LogBuffer {
> > +char *context_name;
> > +int log_level;
> > +char *log_message;
> > +AVClassCategory category;
> > +char *parent_name;
> > +AVClassCategory parent_category;
> > +}LogBuffer;
> > +
> > +static LogBuffer *log_buffer;
> > +static int log_buffer_size;
> > +
> > +static void log_callback(void *ptr, int level, const char *fmt, va_list vl)
> > +{
> > +AVClass* avc = ptr ? *(AVClass **) ptr : NULL;
> > +

[FFmpeg-devel] dxva2 patch

[Денис Кулаков]

In dxva2 code there is bug with context_mutex usage -
if ID3D11VideoContext_DecoderBeginFrame return E_PENDING -
WaitForSingleObjectEx(context_mutex) will be called again, but each call to
it must have corresponding ReleaseMutex, otherwise it will not be released
- so after E_PENDING context mutex will never be released.
--- dxva2.c
+++ dxva2fix.c
@@ -142,11 +142,16 @@
 HRESULT hr;
 unsigned type;
 
-do {
 #if CONFIG_D3D11VA
-if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
+   if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
 if (D3D11VA_CONTEXT(ctx)->context_mutex != INVALID_HANDLE_VALUE)
 WaitForSingleObjectEx(D3D11VA_CONTEXT(ctx)->context_mutex, 
INFINITE, FALSE);
+   }
+#endif
+   
+do {
+#if CONFIG_D3D11VA
+if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
 hr = 
ID3D11VideoContext_DecoderBeginFrame(D3D11VA_CONTEXT(ctx)->video_context, 
D3D11VA_CONTEXT(ctx)->decoder,
   
ff_dxva2_get_surface(frame),
   0, NULL);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] IRC meeting

[Ganesh Ajjanagadde]

On Jun 4, 2016 09:45, "Michael Niedermayer"  wrote:
>
> CCing lukasz and ganesh ...
> so they can correct what we misremember if they want, also dont want
> to speak about people behind their back ...
>
> On Sat, Jun 04, 2016 at 12:26:22PM -0300, James Almer wrote:
> > On 6/4/2016 7:33 AM, Michael Niedermayer wrote:
> > > On Sat, Jun 04, 2016 at 10:30:32AM +0200, Piotr Bandurski wrote:
> > >> Hi,
> > >>
> > >> The problem with this project is that it has not enough active
developers. It looks like most of the devs swiched into "stand-by" mode or
something
> > >> and sadly no new people are joining in to push development forward ;)
> > >
> > > There where new developers but i have the feeling many of them where
> > > treated rather hostile by the community until they decreased activity
> > > or disappeared examples are lukasz
> >
> > I don't know enough about his case aside from i think there being
> > differences with other devs regarding his GSoC 2015 mentored project
> > for me to comment.
>
> I think there where more cases than GSoC itself
> rather a general opposition to some network / ffm / ffserver related
> work. Leaving several areas unmaintained now as a result.
>
> IMO no matter how much one disagrees with someone elses work
> if one doesnt intend to do a better job oneself, one should be humble
> and polite with critique or at least not "shit at one" until he leaves
>
>
> >
> > ganesh
> >
> > There was no hostility towards him. He basically left after a handful
> > of patches he sent were rejected for technical reasons.

The timeline statement is correct. As for hostility, this is incorrect,
even when restricted to public activity on ffmpeg-devel.

But this was not the reason for leaving. The reason for leaving, which I
previously conveyed to Michael privately, is that I lack time for this work
these days.

Put in other words, even if FFmpeg was "perfect" as a community, whatever
that means, I still would have left roughly around this time. Exact timing
was a result of a combination of multiple things that are really irrelevant.

>
> IMHO
> our failure as a community was IIUC that we failed to make him part
> of our team / be more welcoming instead we argued publically if he
> should have a git write account. And we failed to "mentor"/"help"
> him to work on something he liked and we needed. What happened
> was he did good work that was rejected because we kind of didnt
> need/want it.

This mentoring/elaboration of project needs would have been very helpful. I
basically did whatever I wanted to, with limited suggestions from the
community until a few months back, at which time it was too late for me.
IMHO a file with to-do points at least at a high level that most devs agree
upon as being worthy would be useful.

At the moment, even gsoc projects have strong disagreements among the
developers as to their utility.

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: improved cbr mode pcr accuracy

[Michael Niedermayer]

On Tue, Jun 07, 2016 at 02:49:38PM +0300, ale...@netup.ru wrote:
> From: Alex Shumsky 
> 
> ---
>  libavformat/mpegtsenc.c | 64 
> -
>  1 file changed, 37 insertions(+), 27 deletions(-)

did you test this ?
if so please provide information & test results from it

also has this been tested with multiple programs ?

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] Changelog : add OpenExr improvements

[Piotr Bandurski]

Hi,

> In attach, patch to add entry to the changelog, for recently add OpenExr
> features

Could you add support for grayscale images as well?

https://trac.ffmpeg.org/ticket/5621

Regards

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: set range on fps/rate/r option

[Michael Niedermayer]

On Wed, Jun 08, 2016 at 07:46:07AM +0700, Muhammad Faiz wrote:
> see Ticket #5618
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/avf_showcqt.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

probably (1) ok

(1) (unless a different meaning for max/min is intended)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

[Carl Eugen Hoyos]

Mark Thompson  jkqxz.net> writes:

> The point here is that the driver has declared its 
> capabilities, and the given stream is not within those 
> capabilities so the hwaccel should not be used because 
> it will not work

Can you explain how it "will not work"?
On my nvidia hardware, any level can be decoded, 
other restrictions - not level-related - like 
resolution or specific codec features exist.

If the check would actually indicate that decoding "will 
not work" the patch would be useless imo.

Carl Eugen

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

Re: [FFmpeg-devel] MetaData in Sun AU format

[miniupnp]

Le 08/06/2016 15:37, Michael Niedermayer a écrit :
> On Wed, Jun 08, 2016 at 12:03:10AM +0200, miniupnp wrote:
 On 6/1/16, miniupnp  wrote:
> Hello,
>
> I'm using the .AU audio file format and noticed that FFmpeg always put 8
> zero's in the annotation field.
> SOX does use the annotation field to put metadata
> (Title/Author/Album/Genre/Track)
>
> I don't think there is any precise specification for this AU annotation
> field as long as it is a null terminated character string, but what SOX
> does looks good.
>
> Attached are my patches to write metadata to AU files.
 look fine to me.
>>> applied
>>> thx
>> And now is the patch to READ theses metadata in AU files.
>>
>> Regards,
>>
>> Thomas Bernard
>>
>>
>>  au.c |   69 
>> +--
>>  1 file changed, 67 insertions(+), 2 deletions(-)
>> 501f81b2747e0758344d189918af2863d76c774d  
>> 0001-Read-MetaData-from-AU-Sun-audio-file-header.patch
>> From 10ca03e6a944b6a5385a92d72f633e98a0c1b57f Mon Sep 17 00:00:00 2001
>> From: Thomas Bernard 
>> Date: Tue, 7 Jun 2016 00:25:38 +0200
>> Subject: [PATCH] Read MetaData from AU Sun audio file header
>>
>> recognize title= album= artist= genre= track=
>> ---
>>  libavformat/au.c |   69 
>> --
>>  1 file changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/au.c b/libavformat/au.c
>> index 4a0400b..dba2a83 100644
>> --- a/libavformat/au.c
>> +++ b/libavformat/au.c
>> @@ -66,6 +66,71 @@ static int au_probe(AVProbeData *p)
>>  return 0;
>>  }
>>  
>> +static int au_read_annotation(AVFormatContext *s, int size)
>> +{
>> +static const char * keys[] = {
>> +"title",
>> +"artist",
>> +"album",
>> +"track",
>> +"genre",
>> +NULL };
>> +AVIOContext *pb = s->pb;
>> +enum { PARSE_KEY, PARSE_VALUE, PARSE_FINISHED } state = PARSE_KEY;
>> +char c;
>> +AVBPrint bprint;
>> +char * key = NULL;
>> +char * value = NULL;
>> +int i;
>> +
>> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
>> +
>> +while (size-- > 0) {
>> +c = avio_r8(pb);
>> +switch(state) {
>> +case PARSE_KEY:
>> +if (c == '\0') {
>> +state = PARSE_FINISHED;
>> +} else if (c == '=') {
>> +av_bprint_finalize(, );
>> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
>> +state = PARSE_VALUE;
>> +} else {
>> +av_bprint_chars(, c, 1);
>> +}
>> +break;
>> +case PARSE_VALUE:
>> +if (c == '\0' || c == '\n') {
>> +if (av_bprint_finalize(, ) != 0) {
>> +av_log(s, AV_LOG_ERROR, "Memory error while parsing AU 
>> metadata.\n");
>> +} else {
>> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
>> +for (i = 0; keys[i] != NULL && key != NULL; i++) {
>> +if (av_strcasecmp(keys[i], key) == 0) {
>> +av_dict_set(&(s->metadata), keys[i], value, 
>> AV_DICT_DONT_STRDUP_VAL);
>> +av_freep();
>> +value = NULL;
>> +}
>> +}
>> +}
>> +if (key != NULL) av_freep();
>> +if (value != NULL) av_freep();
> redundant if()

I was not sure of what av_freep() does when key==NULL.

here is the patch, plus a potential memory leak fix.
From 10ca03e6a944b6a5385a92d72f633e98a0c1b57f Mon Sep 17 00:00:00 2001
From: Thomas Bernard 
Date: Tue, 7 Jun 2016 00:25:38 +0200
Subject: [PATCH 1/2] Read MetaData from AU Sun audio file header

recognize title= album= artist= genre= track=
---
 libavformat/au.c |   69 --
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/libavformat/au.c b/libavformat/au.c
index 4a0400b..dba2a83 100644
--- a/libavformat/au.c
+++ b/libavformat/au.c
@@ -66,6 +66,71 @@ static int au_probe(AVProbeData *p)
 return 0;
 }
 
+static int au_read_annotation(AVFormatContext *s, int size)
+{
+static const char * keys[] = {
+"title",
+"artist",
+"album",
+"track",
+"genre",
+NULL };
+AVIOContext *pb = s->pb;
+enum { PARSE_KEY, PARSE_VALUE, PARSE_FINISHED } state = PARSE_KEY;
+char c;
+AVBPrint bprint;
+char * key = NULL;
+char * value = NULL;
+int i;
+
+av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
+
+while (size-- > 0) {
+c = avio_r8(pb);
+switch(state) {
+case PARSE_KEY:
+if (c == '\0') {
+state = PARSE_FINISHED;
+} else if (c == '=') {
+av_bprint_finalize(, );
+  

Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

[Mark Thompson]

On 08/06/16 13:59, Carl Eugen Hoyos wrote:
> Mark Thompson  jkqxz.net> writes:
> 
>> Uses the global -hwaccel_lax_profile_check option (may be 
>> misnamed for this purpose, but it has the right spirit).
> 
> Iirc, all old x264 files have a very high profile set (5.0?).
> Is there a usecase for the default not being to accept any 
> profile?

(You mean level rather than profile there, right?)

The point here is that the driver has declared its capabilities, and the given
stream is not within those capabilities so the hwaccel should not be used
because it will not work (the software decoder should be used instead, which
will supports a wider set of streams).  However, in reality we have known cases
where the driver is broken and incorrectly reports this information, and can in
fact decode some streams which it has stated it is unable to.

Now, obviously fixing the driver to correctly report capabilities would be the
way to actually fix the problem, but we don't control that.  This option allows
the user to ignore the declared capabilities of the driver and attempt decode
anyway - it may then fail, but the user did explicitly request it so if it
doesn't work then it is their problem.  Setting it by default would result in
some streams which previously worked now unexpectedly failing, which would be
worse than the current situation.

I hope that was clearer.

Thanks,

- Mark

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

Re: [FFmpeg-devel] MetaData in Sun AU format

[Michael Niedermayer]

On Wed, Jun 08, 2016 at 12:03:10AM +0200, miniupnp wrote:
> 
> >> On 6/1/16, miniupnp  wrote:
> >>> Hello,
> >>>
> >>> I'm using the .AU audio file format and noticed that FFmpeg always put 8
> >>> zero's in the annotation field.
> >>> SOX does use the annotation field to put metadata
> >>> (Title/Author/Album/Genre/Track)
> >>>
> >>> I don't think there is any precise specification for this AU annotation
> >>> field as long as it is a null terminated character string, but what SOX
> >>> does looks good.
> >>>
> >>> Attached are my patches to write metadata to AU files.
> >> look fine to me.
> > applied
> > thx
> And now is the patch to READ theses metadata in AU files.
> 
> Regards,
> 
> Thomas Bernard
> 
> 

>  au.c |   69 
> +--
>  1 file changed, 67 insertions(+), 2 deletions(-)
> 501f81b2747e0758344d189918af2863d76c774d  
> 0001-Read-MetaData-from-AU-Sun-audio-file-header.patch
> From 10ca03e6a944b6a5385a92d72f633e98a0c1b57f Mon Sep 17 00:00:00 2001
> From: Thomas Bernard 
> Date: Tue, 7 Jun 2016 00:25:38 +0200
> Subject: [PATCH] Read MetaData from AU Sun audio file header
> 
> recognize title= album= artist= genre= track=
> ---
>  libavformat/au.c |   69 
> --
>  1 file changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/au.c b/libavformat/au.c
> index 4a0400b..dba2a83 100644
> --- a/libavformat/au.c
> +++ b/libavformat/au.c
> @@ -66,6 +66,71 @@ static int au_probe(AVProbeData *p)
>  return 0;
>  }
>  
> +static int au_read_annotation(AVFormatContext *s, int size)
> +{
> +static const char * keys[] = {
> +"title",
> +"artist",
> +"album",
> +"track",
> +"genre",
> +NULL };
> +AVIOContext *pb = s->pb;
> +enum { PARSE_KEY, PARSE_VALUE, PARSE_FINISHED } state = PARSE_KEY;
> +char c;
> +AVBPrint bprint;
> +char * key = NULL;
> +char * value = NULL;
> +int i;
> +
> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
> +
> +while (size-- > 0) {
> +c = avio_r8(pb);
> +switch(state) {
> +case PARSE_KEY:
> +if (c == '\0') {
> +state = PARSE_FINISHED;
> +} else if (c == '=') {
> +av_bprint_finalize(, );
> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
> +state = PARSE_VALUE;
> +} else {
> +av_bprint_chars(, c, 1);
> +}
> +break;
> +case PARSE_VALUE:
> +if (c == '\0' || c == '\n') {
> +if (av_bprint_finalize(, ) != 0) {
> +av_log(s, AV_LOG_ERROR, "Memory error while parsing AU 
> metadata.\n");
> +} else {
> +av_bprint_init(, 64, AV_BPRINT_SIZE_UNLIMITED);
> +for (i = 0; keys[i] != NULL && key != NULL; i++) {
> +if (av_strcasecmp(keys[i], key) == 0) {
> +av_dict_set(&(s->metadata), keys[i], value, 
> AV_DICT_DONT_STRDUP_VAL);
> +av_freep();
> +value = NULL;
> +}
> +}
> +}

> +if (key != NULL) av_freep();
> +if (value != NULL) av_freep();

redundant if()


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- 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 1/2] MAINTAINERS: Add myself as maintainer for VAAPI encoders

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 10:10:03PM +0100, Mark Thompson wrote:
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

applied

thanks

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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/avf_showcqt: cqt_calc optimization on x86

[Muhammad Faiz]

On Tue, Jun 7, 2016 at 4:18 PM, Muhammad Faiz  wrote:
> On Tue, Jun 7, 2016 at 10:36 AM, James Almer  wrote:
>> On 6/4/2016 4:36 AM, Muhammad Faiz wrote:
>>> benchmark on x86_64
>>> cqt_time:
>>> plain = 3.292 s
>>> SSE   = 1.640 s
>>> SSE3  = 1.631 s
>>> AVX   = 1.395 s
>>> FMA3  = 1.271 s
>>> FMA4  = not available
>>
>> Try using the START_TIMER and STOP_TIMER macros to wrap the s->cqt_calc
>> call in libavfilter/avf_showcqt.c
>> It will potentially give more accurate results than the current
>> UPDATE_TIME(s->cqt_time) check.
>>
> OK, but probably I will check it privately (not sending patch)
>
>>>
>>> untested on x86_32
>>
>> Do you have a sample command to test this? As Michael said FATE doesn't
>> cover showcqt.
>>
>
> I check it using psnr filter (avg psnr above 90dB means OK)
>
> #!/bin/bash
> # example usage: ./psnr-check audio.mp3 yuv420p "-cpuflags 
> -fma3-fma4-avx-sse3"
>
> mkfifo in0.y4m
> mkfifo in1.y4m
>
> # this is new ffmpeg
> build_path=$HOME/Documents/sources/ffmpeg/ffmpeg-build
> LD_LIBRARY_PATH=$build_path/libavcodec:$build_path/libavdevice:$build_path/libavfilter
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$build_path/libavformat:$build_path/libavutil
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$build_path/libpostproc:$build_path/libswresample
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$build_path/libswscale
>
> export LD_LIBRARY_PATH
>
> $build_path/ffmpeg $3 -i "$1" -filter_complex "showcqt, format=$2,
> format=yuv444p|yuv422p|yuv420p" -f yuv4mpegpipe -y in0.y4m >/dev/null
> 2>&1 
> # this is old ffmpeg
> unset LD_LIBRARY_PATH
> ffmpeg $3 -i "$1" -filter_complex "showcqt, format=$2,
> format=yuv444p|yuv422p|yuv420p" -f yuv4mpegpipe -y in1.y4m >/dev/null
> 2>&1 
> ffmpeg -i $dir/in0.y4m -i $dir/in1.y4m -filter_complex "psnr=f=-" -f
> null -y /dev/null
>
>
>>>
>>> Signed-off-by: Muhammad Faiz 
>>> ---
>>>  libavfilter/avf_showcqt.c  |   7 ++
>>>  libavfilter/avf_showcqt.h  |   3 +
>>>  libavfilter/x86/Makefile   |   2 +
>>>  libavfilter/x86/avf_showcqt.asm| 206 
>>> +
>>>  libavfilter/x86/avf_showcqt_init.c |  63 
>>>  5 files changed, 281 insertions(+)
>>>  create mode 100644 libavfilter/x86/avf_showcqt.asm
>>>  create mode 100644 libavfilter/x86/avf_showcqt_init.c
>>>
>>> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
>>> index b88c83c..62d5b09 100644
>>> --- a/libavfilter/avf_showcqt.c
>>> +++ b/libavfilter/avf_showcqt.c
>>> @@ -320,6 +320,9 @@ static int init_cqt(ShowCQTContext *s)
>>>  w *= sign * (1.0 / s->fft_len);
>>>  s->coeffs[m].val[x - s->coeffs[m].start] = w;
>>>  }
>>> +
>>> +if (s->permute_coeffs)
>>> +s->permute_coeffs(s->coeffs[m].val, s->coeffs[m].len);
>>>  }
>>>
>>>  av_expr_free(expr);
>>> @@ -1230,6 +1233,7 @@ static int config_output(AVFilterLink *outlink)
>>>
>>>  s->cqt_align = 1;
>>>  s->cqt_calc = cqt_calc;
>>> +s->permute_coeffs = NULL;
>>>  s->draw_sono = draw_sono;
>>>  if (s->format == AV_PIX_FMT_RGB24) {
>>>  s->draw_bar = draw_bar_rgb;
>>> @@ -1241,6 +1245,9 @@ static int config_output(AVFilterLink *outlink)
>>>  s->update_sono = update_sono_yuv;
>>>  }
>>>
>>> +if (ARCH_X86)
>>> +ff_showcqt_init_x86(s);
>>> +
>>>  if ((ret = init_cqt(s)) < 0)
>>>  return ret;
>>>
>>> diff --git a/libavfilter/avf_showcqt.h b/libavfilter/avf_showcqt.h
>>> index b945f49..588830f 100644
>>> --- a/libavfilter/avf_showcqt.h
>>> +++ b/libavfilter/avf_showcqt.h
>>> @@ -74,6 +74,7 @@ typedef struct {
>>>  /* callback */
>>>  void(*cqt_calc)(FFTComplex *dst, const FFTComplex 
>>> *src, const Coeffs *coeffs,
>>>  int len, int fft_len);
>>> +void(*permute_coeffs)(float *v, int len);
>>>  void(*draw_bar)(AVFrame *out, const float *h, const 
>>> float *rcp_h,
>>>  const ColorFloat *c, int bar_h);
>>>  void(*draw_axis)(AVFrame *out, AVFrame *axis, const 
>>> ColorFloat *c, int off);
>>> @@ -112,4 +113,6 @@ typedef struct {
>>>  int axis;
>>>  } ShowCQTContext;
>>>
>>> +void ff_showcqt_init_x86(ShowCQTContext *s);
>>> +
>>>  #endif
>>> diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
>>> index 4486b79..b6195f8 100644
>>> --- a/libavfilter/x86/Makefile
>>> +++ b/libavfilter/x86/Makefile
>>> @@ -13,6 +13,7 @@ OBJS-$(CONFIG_PP7_FILTER)+= 
>>> x86/vf_pp7_init.o
>>>  OBJS-$(CONFIG_PSNR_FILTER)   += x86/vf_psnr_init.o
>>>  OBJS-$(CONFIG_PULLUP_FILTER) += x86/vf_pullup_init.o
>>>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= x86/vf_removegrain_init.o
>>> +OBJS-$(CONFIG_SHOWCQT_FILTER)+= x86/avf_showcqt_init.o
>>>  OBJS-$(CONFIG_SPP_FILTER)+= x86/vf_spp.o
>>>  

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: cqt_calc optimization on x86

[Muhammad Faiz]

On Tue, Jun 7, 2016 at 2:51 PM, Muhammad Faiz  wrote:
> On Tue, Jun 7, 2016 at 9:49 AM, Michael Niedermayer
>  wrote:
>> On Tue, Jun 07, 2016 at 08:07:45AM +0700, Muhammad Faiz wrote:
>>> On Sat, Jun 4, 2016 at 2:36 PM, Muhammad Faiz  wrote:
>>> > benchmark on x86_64
>>> > cqt_time:
>>> > plain = 3.292 s
>>> > SSE   = 1.640 s
>>> > SSE3  = 1.631 s
>>> > AVX   = 1.395 s
>>> > FMA3  = 1.271 s
>>> > FMA4  = not available
>>> >
>>> > untested on x86_32
>>> >
>>> > Signed-off-by: Muhammad Faiz 
>>> > ---
>>> >  libavfilter/avf_showcqt.c  |   7 ++
>>> >  libavfilter/avf_showcqt.h  |   3 +
>>> >  libavfilter/x86/Makefile   |   2 +
>>> >  libavfilter/x86/avf_showcqt.asm| 206 
>>> > +
>>> >  libavfilter/x86/avf_showcqt_init.c |  63 
>>> >  5 files changed, 281 insertions(+)
>>> >  create mode 100644 libavfilter/x86/avf_showcqt.asm
>>> >  create mode 100644 libavfilter/x86/avf_showcqt_init.c
>>> >
>>>
>>> I want to apply this patch but I'm not sure if it works on
>>> x86_32 or not (I didn't test it on x86_32)
>>
>> i had tested fate with it applied on x86_32 earlier today but i think
>> this filter isnt tested with fate ...
>>
>> testing x86_32 is easy:
>> --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32  
>> --enable-cross-compile
>>
> unfortunately, my linux is pure 64-bit (Fedora 23, it has no 32-bit 
> libraries),
> so it cannot be done
>
> thanks

I update my linux to support 32-bit (at least libc),
and now testingx86_32 works

thank's for the suggestion
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] FFPlay on a HLS stream skips audio from time to time.

[Adrian Cruceru]

On Tue Jun 7 Marton Balint wrote:

On Wed, 1 Jun 2016, Adrian Cruceru wrote:

>/Hi, />//>/Patch is attached, />//>/Quick notes: />/- Playing HLS streams - FFPlay stalls a 
bit before each segment download />/- Stalls accumulate and FFPlay falls behind />/- We get log warning 
and segment skip. />//>/Fix: />/- Just make sure HLS is marked as a real time stream. /
I guess using -infbuf fixes your usecase as well, right? Without -infbuf
ffplay buffers 25 frames, so for 25 fps video content, if playing stops,
this means that it is unable to acquire the first few packets of a
new segment within 1 second. Is this really the case?

Do you have a public test stream where this can be tested?

Thanks,
Marton


Hi Marton,

You are correct in both items:
1) "-infBuf" fixes the issue - the patch just adds code to avoid 
manually setting flag.


2) "unable to acquire first few packets" - yes, that's the case:
- if download takes longer then the 25 frames then we skip a bit at each 
download.

- the skips accumulate over time
- the streaming server will eventually age out old frames and cause a 
full segment skip (as detailed in initial email).


You can find some public streams here: 
http://www.addictradio.net/en/labs/ but takes a while to reproduce


Let me know if I can help with any logs / if you want me to test out 
other patches or look into a different area for a fix


Thanks,
Adrian


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: fix H.264 hwaccel init issue

[Hendrik Leppkes]

On Wed, Jun 8, 2016 at 3:02 AM, Richard Kern  wrote:
>
>> On Jun 6, 2016, at 9:00 AM, Richard Kern  wrote:
>>
>> Ping. This fixes #5595.
>>
>>> On Jun 1, 2016, at 10:06 PM, Rick Kern  wrote:
>>>
>>> Fixes VTDecompressionSessionCreate() error.
>>>
>>> Signed-off-by: Rick Kern 
>>> ---
>>> libavcodec/videotoolbox.c | 59 
>>> ---
>>> 1 file changed, 45 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>>> index 2f4d531..cadfb23 100644
>>> --- a/libavcodec/videotoolbox.c
>>> +++ b/libavcodec/videotoolbox.c
>>> @@ -487,23 +487,53 @@ static CFDictionaryRef 
>>> videotoolbox_buffer_attributes_create(int width,
>>>return buffer_attributes;
>>> }
>>>
>>> -static CMVideoFormatDescriptionRef 
>>> videotoolbox_format_desc_create(CMVideoCodecType codec_type,
>>> +static CMVideoFormatDescriptionRef 
>>> videotoolbox_format_desc_create(AVCodecContext *avctx,
>>> +   
>>> CMVideoCodecType codec_type,
>>>   
>>> CFDictionaryRef decoder_spec,
>>>   int width,
>>>   int 
>>> height)
>>> {
>>> -CMFormatDescriptionRef cm_fmt_desc;
>>> -OSStatus status;
>>> -
>>> -status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
>>> -codec_type,
>>> -width,
>>> -height,
>>> -decoder_spec, // Dictionary of 
>>> extension
>>> -_fmt_desc);
>>> -
>>> -if (status)
>>> -return NULL;
>>> +CMFormatDescriptionRef cm_fmt_desc = NULL;
>>> +int status;
>>> +H264Context *h = codec_type == kCMVideoCodecType_H264 ? 
>>> avctx->priv_data : NULL;
>>> +
>>> +if (h && h->sps.data_size && h->pps.data_size) {
>>> +int ps_count = 2;
>>> +const uint8_t **ps_data = av_malloc(sizeof(uint8_t*) * ps_count);
>>> +size_t *ps_sizes = av_malloc(sizeof(size_t)  * ps_count);
>>> +
>>> +ps_data[0]  = h->sps.data;
>>> +ps_sizes[0] = h->sps.data_size;
>>> +
>>> +ps_data[1]  = h->pps.data;
>>> +ps_sizes[1] = h->pps.data_size;
>>> +
>>> +status = CMVideoFormatDescriptionCreateFromH264ParameterSets(NULL,
>>> + 
>>> ps_count,
>>> + 
>>> ps_data,
>>> + 
>>> ps_sizes,
>>> + 4,
>>> + 
>>> _fmt_desc);
>>> +av_freep(_sizes);
>>> +av_freep(_data);
>>> +
>>> +if (status) {
>>> +av_log(avctx, AV_LOG_ERROR, "Error creating H.264 format 
>>> description: %d\n", status);
>>> +return NULL;
>>> +}
>>> +} else {
>>> +status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
>>> +codec_type,
>>> +width,
>>> +height,
>>> +decoder_spec, // 
>>> Dictionary of extension
>>> +_fmt_desc);
>>> +
>>> +if (status) {
>>> +av_log(avctx, AV_LOG_ERROR, "Error creating format 
>>> description: %d\n", status);
>>> +return NULL;
>>> +}
>>> +}
>>>
>>>return cm_fmt_desc;
>>> }
>>> @@ -543,7 +573,8 @@ static int videotoolbox_default_init(AVCodecContext 
>>> *avctx)
>>>
>>>decoder_spec = 
>>> videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
>>>
>>> -videotoolbox->cm_fmt_desc = 
>>> videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
>>> +videotoolbox->cm_fmt_desc = videotoolbox_format_desc_create(avctx,
>>> +
>>> videotoolbox->cm_codec_type,
>>>decoder_spec,
>>>avctx->width,
>>>
>>> avctx->height);
>>> --
>>> 2.7.4
>>>
>
> No one’s reviewed, but pon pon confirmed the fix. What’s the policy? Can I 
> push, or should I contact the maintainer directly?
>

Code with an active maintainer requires his signoff for changes, so I
would suggest to contact him directly.

- Hendrik