Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecdec_h264: switch to new BSF API

[Matthieu Bouron]

On Wed, Jun 01, 2016 at 11:25:07AM +0200, Matthieu Bouron wrote:
> On Tue, May 31, 2016 at 10:13:40AM +0200, Matthieu Bouron wrote:
> > On Sun, May 29, 2016 at 10:15:44AM +0200, Matthieu Bouron wrote:
> > > On Fri, May 27, 2016 at 10:13:20AM +0200, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron 
> > > > 
> > > > ---
> > > >  libavcodec/mediacodecdec_h264.c | 61 
> > > > +
> > > >  1 file changed, 37 insertions(+), 24 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/mediacodecdec_h264.c 
> > > > b/libavcodec/mediacodecdec_h264.c
> > > > index 2d1d525..7f764e9 100644
> > > > --- a/libavcodec/mediacodecdec_h264.c
> > > > +++ b/libavcodec/mediacodecdec_h264.c
> > > > @@ -23,6 +23,7 @@
> > > >  #include 
> > > >  #include 
> > > >  
> > > > +#include "libavutil/avassert.h"
> > > >  #include "libavutil/common.h"
> > > >  #include "libavutil/fifo.h"
> > > >  #include "libavutil/opt.h"
> > > > @@ -41,13 +42,11 @@ typedef struct MediaCodecH264DecContext {
> > > >  
> > > >  MediaCodecDecContext ctx;
> > > >  
> > > > -AVBitStreamFilterContext *bsf;
> > > > +AVBSFContext *bsf;
> > > >  
> > > >  AVFifoBuffer *fifo;
> > > >  
> > > > -AVPacket input_ref;
> > > >  AVPacket filtered_pkt;
> > > > -uint8_t *filtered_data;
> > > >  
> > > >  } MediaCodecH264DecContext;
> > > >  
> > > > @@ -156,8 +155,9 @@ static av_cold int 
> > > > mediacodec_decode_close(AVCodecContext *avctx)
> > > >  ff_mediacodec_dec_close(avctx, &s->ctx);
> > > >  
> > > >  av_fifo_free(s->fifo);
> > > > +av_bsf_free(&s->bsf);
> > > >  
> > > > -av_bitstream_filter_close(s->bsf);
> > > > +av_packet_unref(&s->filtered_pkt);
> > > >  
> > > >  return 0;
> > > >  }
> > > > @@ -211,12 +211,23 @@ static av_cold int 
> > > > mediacodec_decode_init(AVCodecContext *avctx)
> > > >  goto done;
> > > >  }
> > > >  
> > > > -s->bsf = av_bitstream_filter_init("h264_mp4toannexb");
> > > > -if (!s->bsf) {
> > > > -ret = AVERROR(ENOMEM);
> > > > +const AVBitStreamFilter *bsf = 
> > > > av_bsf_get_by_name("h264_mp4toannexb");
> > > > +if(!bsf) {
> > > > +ret = AVERROR_BSF_NOT_FOUND;
> > > >  goto done;
> > > >  }
> > > >  
> > > > +if ((ret = av_bsf_alloc(bsf, &s->bsf))) {
> > > > +goto done;
> > > > +}
> > > > +
> > > > +if (((ret = avcodec_parameters_from_context(s->bsf->par_in, 
> > > > avctx)) < 0) ||
> > > > +((ret = av_bsf_init(s->bsf)) < 0)) {
> > > > +  goto done;
> > > > +}
> > > > +
> > > > +av_init_packet(&s->filtered_pkt);
> > > > +
> > > >  done:
> > > >  if (format) {
> > > >  ff_AMediaFormat_delete(format);
> > > > @@ -265,7 +276,9 @@ static int mediacodec_decode_frame(AVCodecContext 
> > > > *avctx, void *data,
> > > >  while (!*got_frame) {
> > > >  /* prepare the input data -- convert to Annex B if needed */
> > > >  if (s->filtered_pkt.size <= 0) {
> > > > -int size;
> > > > +AVPacket input_pkt = { 0 };
> > > > +
> > > > +av_packet_unref(&s->filtered_pkt);
> > > >  
> > > >  /* no more data */
> > > >  if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
> > > > @@ -273,22 +286,24 @@ static int mediacodec_decode_frame(AVCodecContext 
> > > > *avctx, void *data,
> > > >  ff_mediacodec_dec_decode(avctx, &s->ctx, frame, 
> > > > got_frame, avpkt);
> > > >  }
> > > >  
> > > > -if (s->filtered_data != s->input_ref.data)
> > > > -av_freep(&s->filtered_data);
> > > > -s->filtered_data = NULL;
> > > > -av_packet_unref(&s->input_ref);
> > > > +av_fifo_generic_read(s->fifo, &input_pkt, 
> > > > sizeof(input_pkt), NULL);
> > > > +
> > > > +ret = av_bsf_send_packet(s->bsf, &input_pkt);
> > > > +if (ret < 0) {
> > > > +return ret;
> > > > +}
> > > > +
> > > > +ret = av_bsf_receive_packet(s->bsf, &s->filtered_pkt);
> > > > +if (ret == AVERROR(EAGAIN)) {
> > > > +goto done;
> > > > +}
> > > > +
> > > > +/* h264_mp4toannexb is used here and does not require 
> > > > flushing */
> > > > +av_assert0(ret != AVERROR_EOF);
> > > >  
> > > > -av_fifo_generic_read(s->fifo, &s->input_ref, 
> > > > sizeof(s->input_ref), NULL);
> > > > -ret = av_bitstream_filter_filter(s->bsf, avctx, NULL,
> > > > - &s->filtered_data, &size,
> > > > - s->input_ref.data, 
> > > > s->input_ref.size, 0);
> > > >  if (ret < 0) {
> > > > -s->filtered_data = s->input_ref.data;
> > > > -size = s->input_ref.size;
> > > > +return ret;
> > > >  }
> > > > -s->filtered_pkt  = s->input_re

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encoder_{h264, h265}: fix bad format warning

[Matthieu Bouron]

On Thu, Jun 02, 2016 at 07:09:16PM +0100, Mark Thompson wrote:
> On 02/06/16 17:20, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > ---
> >  libavcodec/vaapi_encode_h264.c | 2 +-
> >  libavcodec/vaapi_encode_h265.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> > index 0a99bb1..dc7774b 100644
> > --- a/libavcodec/vaapi_encode_h264.c
> > +++ b/libavcodec/vaapi_encode_h264.c
> > @@ -769,7 +769,7 @@ static av_cold int 
> > vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
> >  priv->fixed_qp_p   = 26;
> >  priv->fixed_qp_b   = 26;
> >  
> > -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n",
> > +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" 
> > bps.\n",
> > avctx->bit_rate);
> >  return 0;
> >  }
> > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> > index 05d3aa4..17cd900 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -1196,7 +1196,7 @@ static av_cold int 
> > vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx
> >  priv->fixed_qp_p   = 30;
> >  priv->fixed_qp_b   = 30;
> >  
> > -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n",
> > +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" 
> > bps.\n",
> > avctx->bit_rate);
> >  return 0;
> >  }
> > 
> 
> LGTM to fix the warning.
> 
> I didn't realise that bit_rate has a different type in the two tines - I 
> think a bit more is needed here to just reject higher numbers because all of 
> the relevant fields in va.h structures are 32-bit anyway...

Pushed. Thanks.

Matthieu

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

Re: [FFmpeg-devel] [PATCH] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31

[Matthieu Bouron]

On Thu, Jun 02, 2016 at 10:36:21PM +0100, Mark Thompson wrote:
> On 02/06/16 22:00, Matthieu Bouron wrote:
> > On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
> >> ---
> >> ... something like this.
> >>
> >>  libavcodec/vaapi_encode_h264.c | 6 ++
> >>  libavcodec/vaapi_encode_h265.c | 6 ++
> >>  2 files changed, 12 insertions(+)
> >>
> >> diff --git a/libavcodec/vaapi_encode_h264.c 
> >> b/libavcodec/vaapi_encode_h264.c
> >> index 0a99bb1..019ed1f 100644
> >> --- a/libavcodec/vaapi_encode_h264.c
> >> +++ b/libavcodec/vaapi_encode_h264.c
> >> @@ -731,6 +731,12 @@ static av_cold int 
> >> vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
> >>  int hrd_buffer_size;
> >>  int hrd_initial_buffer_fullness;
> >>
> >> +if (avctx->bit_rate >= 1u << 31) {
> > 
> > Wouldn't INT32_MAX be more aproriate ?
> 
> Hmm.  No preference - I went for 1u << 31 to match the 2^31 in the error 
> message, but maybe INT32_MAX makes the code constraint slightly clearer.

IMHO, I think it's clearer to use INT32_MAX but as you are the maintainer
of those encoders, it's up to you to decide.

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

Re: [FFmpeg-devel] [PATCH] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31

[Mark Thompson]

On 03/06/16 09:32, Matthieu Bouron wrote:
> On Thu, Jun 02, 2016 at 10:36:21PM +0100, Mark Thompson wrote:
>> On 02/06/16 22:00, Matthieu Bouron wrote:
>>> On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
 ---
 ... something like this.

  libavcodec/vaapi_encode_h264.c | 6 ++
  libavcodec/vaapi_encode_h265.c | 6 ++
  2 files changed, 12 insertions(+)

 diff --git a/libavcodec/vaapi_encode_h264.c 
 b/libavcodec/vaapi_encode_h264.c
 index 0a99bb1..019ed1f 100644
 --- a/libavcodec/vaapi_encode_h264.c
 +++ b/libavcodec/vaapi_encode_h264.c
 @@ -731,6 +731,12 @@ static av_cold int 
 vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
  int hrd_buffer_size;
  int hrd_initial_buffer_fullness;

 +if (avctx->bit_rate >= 1u << 31) {
>>>
>>> Wouldn't INT32_MAX be more aproriate ?
>>
>> Hmm.  No preference - I went for 1u << 31 to match the 2^31 in the error 
>> message, but maybe INT32_MAX makes the code constraint slightly clearer.
> 
> IMHO, I think it's clearer to use INT32_MAX but as you are the maintainer
> of those encoders, it's up to you to decide.

While I may be the de facto maintainer (having written all of the code), I am
not the de jure maintainer and I do not have commit access.  Please do just
commit this patch, including your change ("> INT32_MAX").

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 Thu, Jun 02, 2016 at 06:07:22AM +0200, Paul B Mahol 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.
> >
> > Regards,
> >
> > Thomas Bernard
> >
> >
> 
> look fine to me.

applied
thx

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

[FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Nicolas George]

Since d607861, service can not be NULL, only "0".
An UDP address with neither local port nor address leaves both
service and node to their default value, and POSIX specifies
that they are not allowed to be both NULL; "0" is equivalent
to an unspecified port for all currently known protocols.

Fix CID 1341570.

Signed-off-by: Nicolas George 
---
 libavformat/udp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 0f35689..531e254 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -264,7 +264,7 @@ static struct addrinfo *udp_resolve_host(URLContext *h,
 res = NULL;
 av_log(h, AV_LOG_ERROR, "getaddrinfo(%s, %s): %s\n",
node ? node : "unknown",
-   service ? service : "unknown",
+   service,
gai_strerror(error));
 }
 
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 11:21:23AM +0200, Nicolas George wrote:
> Since d607861, service can not be NULL, only "0".
> An UDP address with neither local port nor address leaves both
> service and node to their default value, and POSIX specifies
> that they are not allowed to be both NULL; "0" is equivalent
> to an unspecified port for all currently known protocols.
> 
> Fix CID 1341570.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavformat/udp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

ok
thanks

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Nicolas George]

Le sextidi 16 prairial, an CCXXIV, Michael Niedermayer a écrit :
> ok
> thanks

Thanks. I pushed to g...@source.ffmpeg.org:ffmpeg, it appears on the
mailing-list but not on https://git.ffmpeg.org/ffmpeg.git, and I have no
permissions for g...@git.ffmpeg.org:ffmpeg. Am I doing something wrong?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 01:00:46PM +0200, Nicolas George wrote:
> Le sextidi 16 prairial, an CCXXIV, Michael Niedermayer a écrit :
> > ok
> > thanks
> 
> Thanks. I pushed to g...@source.ffmpeg.org:ffmpeg, it appears on the

yes, that is and always was the push url 


> mailing-list but not on https://git.ffmpeg.org/ffmpeg.git, and I have no
> permissions for g...@git.ffmpeg.org:ffmpeg. Am I doing something wrong?
> 
> Regards,
> 
> -- 
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

[FFmpeg-devel] [PATCH] avfilter/avf_showcqt: render default font at 960x16

[Muhammad Faiz]

and let ffmpeg scaler scale it
this impoves quality

Signed-off-by: Muhammad Faiz 
---
 libavfilter/avf_showcqt.c | 43 ---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index a09b992..b88c83c 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -434,14 +434,16 @@ static double b_func(void *p, double x)
 return lrint(x*255.0);
 }
 
-static int init_axis_color(ShowCQTContext *s, AVFrame *tmp)
+static int init_axis_color(ShowCQTContext *s, AVFrame *tmp, int half)
 {
 const char *var_names[] = { "timeclamp", "tc", "frequency", "freq", "f", 
NULL };
 const char *func_names[] = { "midi", "r", "g", "b", NULL };
 double (*funcs[])(void *, double) = { midi, r_func, g_func, b_func };
 AVExpr *expr = NULL;
 double *freq = NULL;
-int x, y, ret;
+int x, xs, y, ret;
+int width = half ? 1920/2 : 1920, height = half ? 16 : 32;
+int step = half ? 2 : 1;
 
 if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) {
 av_log(s->ctx, AV_LOG_WARNING, "font axis rendering is not implemented 
in non-default frequency range,"
@@ -460,17 +462,16 @@ static int init_axis_color(ShowCQTContext *s, AVFrame 
*tmp)
 return ret;
 }
 
-for (x = 0; x < 1920; x++) {
-double vars[] = { s->timeclamp, s->timeclamp, freq[x], freq[x], 
freq[x] };
+for (x = 0, xs = 0; x < width; x++, xs += step) {
+double vars[] = { s->timeclamp, s->timeclamp, freq[xs], freq[xs], 
freq[xs] };
 int color = (int) av_expr_eval(expr, vars, NULL);
 uint8_t r = (color >> 16) & 0xFF, g = (color >> 8) & 0xFF, b = color & 
0xFF;
 uint8_t *data = tmp->data[0];
 int linesize = tmp->linesize[0];
-for (y = 0; y < 32; y++) {
+for (y = 0; y < height; y++) {
 data[linesize * y + 4 * x] = r;
 data[linesize * y + 4 * x + 1] = g;
 data[linesize * y + 4 * x + 2] = b;
-data[linesize * y + 4 * x + 3] = 0;
 }
 }
 
@@ -570,19 +571,18 @@ static int render_default_font(AVFrame *tmp)
 int x, u, v, mask;
 uint8_t *data = tmp->data[0];
 int linesize = tmp->linesize[0];
+int width = 1920/2, height = 16;
 
-for (x = 0; x < 1920; x += 192) {
+for (x = 0; x < width; x += width/10) {
 uint8_t *startptr = data + 4 * x;
 for (u = 0; u < 12; u++) {
-for (v = 0; v < 16; v++) {
-uint8_t *p = startptr + 2 * v * linesize + 16 * 4 * u;
-for (mask = 0x80; mask; mask >>= 1, p += 8) {
-if (mask & avpriv_vga16_font[str[u] * 16 + v]) {
+for (v = 0; v < height; v++) {
+uint8_t *p = startptr + v * linesize + height/2 * 4 * u;
+for (mask = 0x80; mask; mask >>= 1, p += 4) {
+if (mask & avpriv_vga16_font[str[u] * 16 + v])
 p[3] = 255;
-p[7] = 255;
-p[linesize+3] = 255;
-p[linesize+7] = 255;
-}
+else
+p[3] = 0;
 }
 }
 }
@@ -595,22 +595,27 @@ static int init_axis_from_font(ShowCQTContext *s)
 {
 AVFrame *tmp = NULL;
 int ret = AVERROR(ENOMEM);
+int width = 1920, height = 32;
+int default_font = 0;
 
-if (!(tmp = alloc_frame_empty(AV_PIX_FMT_RGBA, 1920, 32)))
+if (!(tmp = alloc_frame_empty(AV_PIX_FMT_RGBA, width, height)))
 goto fail;
 
 if (!(s->axis_frame = av_frame_alloc()))
 goto fail;
 
-if ((ret = init_axis_color(s, tmp)) < 0)
+if (render_freetype(s, tmp) < 0 && (default_font = 1, ret = 
render_default_font(tmp)) < 0)
 goto fail;
 
-if (render_freetype(s, tmp) < 0 && (ret = render_default_font(tmp)) < 0)
+if (default_font)
+width /= 2, height /= 2;
+
+if ((ret = init_axis_color(s, tmp, default_font)) < 0)
 goto fail;
 
 if ((ret = ff_scale_image(s->axis_frame->data, s->axis_frame->linesize, 
s->width, s->axis_h,
   convert_axis_pixel_format(s->format), tmp->data, 
tmp->linesize,
-  1920, 32, AV_PIX_FMT_RGBA, s->ctx)) < 0)
+  width, height, AV_PIX_FMT_RGBA, s->ctx)) < 0)
 goto fail;
 
 av_frame_free(&tmp);
-- 
2.5.0

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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 01:05:06PM +0200, Michael Niedermayer wrote:
> On Fri, Jun 03, 2016 at 01:00:46PM +0200, Nicolas George wrote:
> > Le sextidi 16 prairial, an CCXXIV, Michael Niedermayer a écrit :
> > > ok
> > > thanks
> > 
> > Thanks. I pushed to g...@source.ffmpeg.org:ffmpeg, it appears on the
> 
> yes, that is and always was the push url 
> 
> 

> > mailing-list but not on https://git.ffmpeg.org/ffmpeg.git, and I have no

Do you know how to change the push URL for one repository in gitolite?
I know how to change it for all repositories but only ffmpeg uses the
videolan server for git push, all other repositories we have
use our own server.
It should be possible with gitweb.url but its syntax seems undocumented
and no example i could find uses push != fetch urls
my attempts to guess syntax led to either it being parsed as one url
or gitolite refusing the string with fatal error


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

[FFmpeg-devel] [PATCH] libavutil/fifo: Fix fifo grow step

[sebechlebskyjan]

From: Jan Sebechlebsky 

Fifo was reallocating always to twice of the requested size.
This fixes it to reallocate to requested size, or twice of the
original size - whichever is greater.

Signed-off-by: Jan Sebechlebsky 
---
 I believe the intended behaviour was as described in commit message
 and FFMAX(size,2*size) is a mistake.

 libavutil/fifo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 986729a..1060aed 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -113,7 +113,7 @@ int av_fifo_grow(AVFifoBuffer *f, unsigned int size)
 size += av_fifo_size(f);
 
 if (old_size < size)
-return av_fifo_realloc2(f, FFMAX(size, 2*size));
+return av_fifo_realloc2(f, FFMAX(size, 2*old_size));
 return 0;
 }
 
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 10:08:16AM +0100, Mark Thompson wrote:
> On 03/06/16 09:32, Matthieu Bouron wrote:
> > On Thu, Jun 02, 2016 at 10:36:21PM +0100, Mark Thompson wrote:
> >> On 02/06/16 22:00, Matthieu Bouron wrote:
> >>> On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
>  ---
>  ... something like this.
> 
>   libavcodec/vaapi_encode_h264.c | 6 ++
>   libavcodec/vaapi_encode_h265.c | 6 ++
>   2 files changed, 12 insertions(+)
> 
>  diff --git a/libavcodec/vaapi_encode_h264.c 
>  b/libavcodec/vaapi_encode_h264.c
>  index 0a99bb1..019ed1f 100644
>  --- a/libavcodec/vaapi_encode_h264.c
>  +++ b/libavcodec/vaapi_encode_h264.c
>  @@ -731,6 +731,12 @@ static av_cold int 
>  vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
>   int hrd_buffer_size;
>   int hrd_initial_buffer_fullness;
> 
>  +if (avctx->bit_rate >= 1u << 31) {
> >>>
> >>> Wouldn't INT32_MAX be more aproriate ?
> >>
> >> Hmm.  No preference - I went for 1u << 31 to match the 2^31 in the error 
> >> message, but maybe INT32_MAX makes the code constraint slightly clearer.
> > 
> > IMHO, I think it's clearer to use INT32_MAX but as you are the maintainer
> > of those encoders, it's up to you to decide.
> 
> While I may be the de facto maintainer (having written all of the code), I am
> not the de jure maintainer and I do not have commit access.  Please do just
> commit this patch, including your change ("> INT32_MAX").

if you want to maintain the code you are author of, please send a patch
for the MAINTAINERs file

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Nicolas George]

Le sextidi 16 prairial, an CCXXIV, Michael Niedermayer a écrit :
> Do you know how to change the push URL for one repository in gitolite?
> I know how to change it for all repositories but only ffmpeg uses the
> videolan server for git push, all other repositories we have
> use our own server.
> It should be possible with gitweb.url but its syntax seems undocumented
> and no example i could find uses push != fetch urls
> my attempts to guess syntax led to either it being parsed as one url
> or gitolite refusing the string with fatal error

Thanks, but I always use a different remote for pushing anyways. I was just
a bit confused: when did we acquire our own git server, and is there a file
summarizing what repository is authoritative?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] Tee improvement - discussion

[Nicolas George]

Sorry for forgetting to reply.

L'octidi 8 prairial, an CCXXIV, Marton Balint a écrit :
> What if we decouple the non-blocking queue and the retry on failure logic to
> a separate "buffer" or "fifo" muxer?
> 
> This seems like what you are trying to do, and by using the exisiting muxer
> interface, we don't have to design new API around it.
> 
> Although I don't yet see if using three levels of muxing (E.g. the tee muxer
> invokes the fifo muxer, which will invoke the underlying real muxer) can
> cause any unseen problems or not.

Implementing the non-blocking logic in a separate muxer would indeed avoid
most of my objections. It would still be very far from a real solution to
the non-blocking problem, but it can certainly do for now.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] Tee improvement - discussion

[Nicolas George]

Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :
> If I understand it correctly, I think this will be handled quite smoothy -
> you don't have to kill the blocked write, the application has to call
> write_trailer anyway before closing the muxer, so I guess this is the place
> where tee will wait for the muxer's pending write operation to finish. So
> application will know, that after call to write_trailer all operations are
> finished.

There is no "after call to write_trailer": the real muxer is blocked
writing, it will not terminate. By pushing it in a thread, you may have
achieved non-blocking writes for the application, but that just pushed the
issue a bit further.

To achieve real non-blocking operation, you need to have all the muxers and
protocols stack working in non-blocking mode, or you need asynchronous
killing of I/O operations. Asynchronous killing of I/O operations exists,
that is pthread_cancel(), but it is quite tricky to use and we had no end of
portability issues with it too.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/4] lavf/concat: switch to new BSF API.

[Nicolas George]

L'octidi 8 prairial, an CCXXIV, Nicolas George a écrit :
> It seems the memory management is not as negligible as I expected. The
> result is a ~2.3% slow-down for ~90k frames from AVI, which is approximately
> equal to the standard deviation on 10 runs. I suspect this is acceptable
> compared to the overhead of more complex containers.

No comments? I think this overhead is acceptable and this, if nobody objects
I will push soon the series.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH]Filter: Add snapshot filter. It is enable to save snapshot.

[Nicolas George]

Le quartidi 14 prairial, an CCXXIV, kl222 a écrit :
> I understand your usage scenario. But I am not specified snapshot file
> name on the command line. But it needs to be updated it is, another
> program specified file name. So, I think as a separate filter is better.

I think you will need to do a little better than that: you can not wave the
objections to your patch away, you need to explain why they are less
important than your wish of specifying the output file name on the command
stream.

IMHO, they are not: the calling code can as easily rename the output file to
its final name. I might add that having an output file name specified
through a command channel is at least a security concern: since it is a
rarely used feature, people will often forget it exists when auditing new
code.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] Matroska / FFV1 Symposium in Berlin

[Dave Rice]

Hi all,

I wanted to share news and an invite for a free symposium to be held in Berlin 
on July 18-20, 2016 hosted by Deutsche Kinemathek and Zuse Institute Berlin 
which has a specific focus on the development, standardization, and 
implementation of Matroska and FFV1. Developers, users, and onlookers are 
invited to attend. This conference should build upon the work of the IETF 
Cellar working group [1] which is tasked with standardizing these formats.

We are still arranging the schedule but if you would like to propose a 
presentation or event, or have any questions, please contact i...@mediaarea.net 
. More information and a link to the registration 
form are available at https://mediaarea.net/MediaConch/notimetowait.html 
.

Best Regards,
Dave Rice

[1] https://datatracker.ietf.org/wg/cellar/charter/ 

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

Re: [FFmpeg-devel] Tee improvement - discussion

[Jan Sebechlebsky]

On 06/03/2016 03:46 PM, Nicolas George wrote:

Sorry for forgetting to reply.

L'octidi 8 prairial, an CCXXIV, Marton Balint a écrit :

What if we decouple the non-blocking queue and the retry on failure logic to
a separate "buffer" or "fifo" muxer?

This seems like what you are trying to do, and by using the exisiting muxer
interface, we don't have to design new API around it.

Although I don't yet see if using three levels of muxing (E.g. the tee muxer
invokes the fifo muxer, which will invoke the underlying real muxer) can
cause any unseen problems or not.

Implementing the non-blocking logic in a separate muxer would indeed avoid
most of my objections. It would still be very far from a real solution to
the non-blocking problem, but it can certainly do for now.

Great! I guess I can do it that way then :)

Regards,



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

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

Re: [FFmpeg-devel] Tee improvement - discussion

[Jan Sebechlebsky]

On 06/03/2016 03:53 PM, Nicolas George wrote:

Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :

If I understand it correctly, I think this will be handled quite smoothy -
you don't have to kill the blocked write, the application has to call
write_trailer anyway before closing the muxer, so I guess this is the place
where tee will wait for the muxer's pending write operation to finish. So
application will know, that after call to write_trailer all operations are
finished.

There is no "after call to write_trailer": the real muxer is blocked
writing, it will not terminate. By pushing it in a thread, you may have
achieved non-blocking writes for the application, but that just pushed the
issue a bit further.

To achieve real non-blocking operation, you need to have all the muxers and
protocols stack working in non-blocking mode, or you need asynchronous
killing of I/O operations. Asynchronous killing of I/O operations exists,
that is pthread_cancel(), but it is quite tricky to use and we had no end of
portability issues with it too.

I guess then, that implementing it without killing blocked threads 
should not introduce any new problems - the process will hang as it does 
now in this kind of situation.
I can try to take a look if canceling the thread could be used. How 
do you imagine this (like that there will be a timeout enforced by 
killing the thread?). Do you know where are I/O operations which can 
block forever without timeouting used, so I can try to take a look at 
some particular case?


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

Re: [FFmpeg-devel] [PATCH] lavf/udp: fix dead code.

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 03:08:51PM +0200, Nicolas George wrote:
> Le sextidi 16 prairial, an CCXXIV, Michael Niedermayer a écrit :
> > Do you know how to change the push URL for one repository in gitolite?
> > I know how to change it for all repositories but only ffmpeg uses the
> > videolan server for git push, all other repositories we have
> > use our own server.
> > It should be possible with gitweb.url but its syntax seems undocumented
> > and no example i could find uses push != fetch urls
> > my attempts to guess syntax led to either it being parsed as one url
> > or gitolite refusing the string with fatal error
> 
> Thanks, but I always use a different remote for pushing anyways. I was just
> a bit confused: when did we acquire our own git server, and is there a file
> summarizing what repository is authoritative?

we have our own git server since april 2011
at the end of april 2011 the following repositories existed in it
most of these where from svn and some where inactive long before

repodvdnav
repomplayer-homepage
repolibc
repomga_vid
repomplayer
repomplayerosx
reportmpdump
reposkins
repouha
repouuterm
repovesautils
reponut
reposoc
repomichael
reportmpdump-web
repoffmpeg-web
repobow
repolibswscale  #old libswscale repo, do not push anything in 
this
repoffmpeg.svn  #old ffmpeg repo, do not push anything in this

its easy to add repositories and give admin access if anyone needs a
repo for FOSS purposes and is unhappy with offers from github and
others ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] libavutil/fifo: Fix fifo grow step

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 02:04:00PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Fifo was reallocating always to twice of the requested size.
> This fixes it to reallocate to requested size, or twice of the
> original size - whichever is greater.
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  I believe the intended behaviour was as described in commit message
>  and FFMAX(size,2*size) is a mistake.

the point behind teh FFMAX was to protect against a overflow of
2*size but your suggestion is probably better and would reduce memory
use, so applied

thanks

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Michael Niedermayer]

On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote:
> Hi
> 
> It was suggested in the IRC meeting today that i start a vote to
> resolve if AVClass & AVOption should be added to AVCodecParameters
> This question needs to be awnsered before the next release because
> the ABI would be broken if its added afterwards
> the lack of any decission blocks the release which is worse than
> either decission, otherwise a vote might be silly for such technical
> question but eve a bad decission is better than no decission here
> 
> 
> The disadvanatges are:
> 1 more field in the struct
> a high level API that some feel is unneeded for AVCodecParameters
> it could be confusing to some that there are 2 different ways to
> access the fields
> people might use it as av_log() context when they intended to use a
> different context for it
> There are probably more please help fill the list if you know more
> 
> The advanatges are:
> More consistent availability of AVOptions and AVClass in public
> structs
> Makes supporting multiple FFmpeg versions and distros easier and
> cleaner for applications. (reduces lists of #if version checks)
> Provides default/min/max values, allows basic validity checking within
> min/max
> Avoids mysterious crashes if an application uses avoption functions
> on AVCodecParameters
> Introspection
> Serialization support that may be usefull for ffserver or an application
> replacing ffserver
> 
> 
> An application that doesnt want to use AVOptions or AVClass can
> completey ignore them.
> 
> Please state clearly if you agree to add AVClass&AVOption to
> AVCodecParameters or if you disagree about adding it or if you dont
> care either way
> 
> The vote will end 1 week from now, simple 50% majority (Yes vs no)
> I dont really know who should be eligible for voting, so i suggest
> everyone from the vote comittee but iam happy with anything, just
> stating somethng ...

I agree to adding an AVClass* on top of AVCodecParameters.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] IRC meeting

[Christophe Gisquet]

Hi,

here's I think a list of things left to do. I remember saste doing it
on some occasions.

Please comment on whether you think I have pointed an actual action to
perform. Don't mind the details for now, it's just to get the train
going.

2016-05-30 10:49 GMT+02:00 Michael Niedermayer :


ONE)
> May 28 19:07:54https://wiki.videolan.org/Code_of_Conduct/
[...]
> May 28 19:29:06   so lets add that to current CoC and put it 
> for vote on ML?

Action: put to vote the addition of the "repercussions" from the linked page.

There was some discussion as how to modify it. Whether to accept as
is, or delay for additions can be included in the vote, IMO:
> May 28 19:29:40durandal_1707: send a draft first and get 
> comments to improve it



TWO)
> May 28 19:38:00  AVClass & AVOption should be added to all 
> public "Context" structs for API consistency and to make it easier for apps 
> to support multiple ffmpeg versios and distros

Action: put to vote (vote ongoing).



THREE)
> May 28 20:21:19liabvutil is currently the only non modular 
> library. literally everything is compiled and installed no matter your 
> configure options
[...]
> May 28 20:31:19Err what's the result on the previous topic? 
> Send patches and it'll get reviewed but the end goal is ok? (I don't mind)
> May 28 20:31:47kurosu_: sounds like it yes

Action: whoever is interested will submit patches, with the idea that
the end goal is worth reaching.


FOUR)
> May 28 20:32:54 that's the other issue; we don't really have 
> someone to handle the sysadmin stuff
> May 28 20:35:58 i feel like we really need someone to 
> officially handle the sysadmin stuff
> May 28 20:33:14 does anyone have a sysadmin in his 
> relationships that would be interested in that?
> May 28 20:34:09  we have a virtual box in bulgaria that ffbox0 
> could be moved to if teres a volunteer
> May 28 20:52:40VLC have offered to sysadmin for years
> May 28 20:55:01  i put it on the table, my offer to admin again
> May 28 21:22:30  iive: makes a good suggestion, GitHub would release 
> at least two services (git and trac). For trac to GitHub you could look at 
> something like: https://github.com/trustmaster/trac2github It also might make 
> the project more accessible to new contributors

Action: decide how and who performs admin tasks.
I think the above lists the possible options in a vote:
- Compn as admin
- Delegate admin tasks to VLC (seemed related to hosting too)
- Draft a request for admins to be circulated
- Move stuff to bulgaria
- Move stuff to github


FOUR.TWO)
> May 28 20:58:44  we probably should config postfix or 
> spamassasin to check DMARK/DKIM/SPF or part of that on incoming mai (not 
> really important but i thn it doest curretly)

Details on what needs to be done, I think this is not high-level
enough for a vote.
Action: michaelni to list some wishes?



FIVE)
> May 28 21:28:47   i want possibility to fund devs to work on 
> specific part of FFmpeg
> May 28 21:28:59   what happened with FFmtech?
> May 28 21:29:38  at the moment we have a total of ~15K USD in the SPI 
> and ffis.de funds
> May 28 21:30:58  saste, can we fund someone maybe to make 
> kierans fuzzing GSoC project a reality ? i mean if people agree to that
> May 28 21:31:59   so just need to pick some part of codebase 
> that need refactoring/cleaning up/improving?
> May 28 21:59:08Kierank mentioned btw he was willing to fund 
> some work on libavfilter API that would suit his needs, the details of which 
> he'll give to whomever is integrated

Action: list the sponsoring opportunities for work on ffmpeg: tasks
and origin of funds?
Subpoints:
- better lavfi API for some usecases
- find whether SPI/... can be used for that



SIX)
> May 28 19:32:58since cehoyos is here, we could maybe talk 
> about his behavior and why the CoC and repercussions for violating it was 
> introduced to begin with
> May 28 21:51:31is there anything concrete we’re going to do w.r.t. 
> derek and carl?
> May 28 21:59:52So Derek and carl?
> May 28 22:26:54 its too late now, and we need to handle the 
> situation at hand
> May 28 22:28:24nevcairiel, do you want a vote here and now, 
> to what effect?
> May 28 22:31:09I agree that a vote on the ML would be better to give 
> people that fell asleep here the chance to participate also
> May 28 22:34:59It's late here. I'm ok for a vote also, just 
> not sure what kind of offense it would be

And the big, flashy pink, elephant in the room:
Action: draft a vote on the repercussions to Carl Eugen Hoyos
behaviours (patch submission, general interaction with others)
Note, I don't have a strong idea on what it may contain (option of
temp/week/perma ban, warning, removal of some rights, etc).

If someone is interested in this, maybe listing all potential options
and use Condorcet etc.

I don't really care, the above just says: don't drag this on.

Best

Re: [FFmpeg-devel] IRC meeting

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 08:32:51PM +0200, Christophe Gisquet wrote:
[...]

> FOUR.TWO)
> > May 28 20:58:44  we probably should config postfix or 
> > spamassasin to check DMARK/DKIM/SPF or part of that on incoming mai (not 
> > really important but i thn it doest curretly)
> 
> Details on what needs to be done, I think this is not high-level
> enough for a vote.
> Action: michaelni to list some wishes?

i want some assistent to help with dayly server admin duties
most root admins we have help and contribute but are often busy
raz recently set up a full backup system for us, someone seems
helping with security updates as iam not always the first doing them
(i think its lou but didnt check) and all kinds of other things ...

what would be really nice would be someone who has some time and for
whom server admining is a fun thing to do,
someone who would do it "because it needs to be done" would be 2nd
choice IMHO


[...]
> SIX)
> > May 28 19:32:58since cehoyos is here, we could maybe talk 
> > about his behavior and why the CoC and repercussions for violating it was 
> > introduced to begin with
> > May 28 21:51:31is there anything concrete we’re going to do w.r.t. 
> > derek and carl?
> > May 28 21:59:52So Derek and carl?
> > May 28 22:26:54 its too late now, and we need to handle the 
> > situation at hand
> > May 28 22:28:24nevcairiel, do you want a vote here and 
> > now, to what effect?
> > May 28 22:31:09I agree that a vote on the ML would be better to 
> > give people that fell asleep here the chance to participate also
> > May 28 22:34:59It's late here. I'm ok for a vote also, 
> > just not sure what kind of offense it would be
> 
> And the big, flashy pink, elephant in the room:
> Action: draft a vote on the repercussions to Carl Eugen Hoyos
> behaviours (patch submission, general interaction with others)
> Note, I don't have a strong idea on what it may contain (option of
> temp/week/perma ban, warning, removal of some rights, etc).

iam not suggesting anything specific but there is one thing that i
think i have not seen talked about and that is moderation. Mailman
supports moderating individual subscribers.

It might be along the lines of
If one repeatly and conciously violates the CoC and no real solution
can be found, he can be given the choice by the mailman admins to
either promise to attempt not to repeat the violation
or to be moderated until an event occurs that changes the situation
or some timeout.
The insulted person should have the option to veto this at any time so
if one feels that it wasnt enough to justify the inconvenience the
"hurt" party should be able to stop this.
This would have to be combined with something effective for IRC and
possibly git, in case issues shift there too


[...]

-- 
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] IRC meeting

[Christophe Gisquet]

Hi,

sorry if I'm or was confusing, I'm best-effort here.

2016-06-03 21:13 GMT+02:00 Michael Niedermayer :
> > FOUR.TWO)
[...]
> i want some assistent to help with dayly server admin duties
> most root admins we have help and contribute but are often busy
> raz recently set up a full backup system for us, someone seems
> helping with security updates as iam not always the first doing them
> (i think its lou but didnt check) and all kinds of other things ...
>
> what would be really nice would be someone who has some time and for
> whom server admining is a fun thing to do,
> someone who would do it "because it needs to be done" would be 2nd
> choice IMHO

You are actually replying to FOUR)
This seems to be "ask someone to join in the rotation of tasks",
rather than a full-blown delegation of work. That's an option. I don't
pretend to have correctly worded the action of FOUR)

> iam not suggesting anything specific but there is one thing that i
> think i have not seen talked about and that is moderation. Mailman
> supports moderating individual subscribers.
>
> It might be along the lines of
> If one repeatly and conciously violates the CoC and no real solution
> can be found, he can be given the choice by the mailman admins to
> either promise to attempt not to repeat the violation
> or to be moderated until an event occurs that changes the situation
> or some timeout.
> The insulted person should have the option to veto this at any time so
> if one feels that it wasnt enough to justify the inconvenience the
> "hurt" party should be able to stop this.
> This would have to be combined with something effective for IRC and
> possibly git, in case issues shift there too

You are actually replying to point ONE, more precisely, "how to modify
it" (the CoC).
There are many opinions. I think an amount of time best described by
some aleph can be spent discussing the details, but I bet people are
ok with "use VLC's or whichever, then vote for improvement". You are
proposing an improvement.

The point here is, several people seem to want things to move here
irrespective of ONE, so a vote seems (to me) the natural step forward.
So, either someone acts towards the action, and it may happen, or
clearly, nothing will happen.

I'm resting my opinion that we are putting the cart before the horse,
but I recognize the need from people for action, so I'm ready to vote
on that point, irrespective of ONE. If it happens.

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

[FFmpeg-devel] [PATCH 2/2] avformat/rawdec: Fix avg_framerate for h264

[Michael Niedermayer]

The framerate is 25 which is a fixed default and is wrong undo the 1 line
change which caused this regression
Fixes Ticket 5444

Signed-off-by: Michael Niedermayer 
---
 libavformat/rawdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index 8c734db..2bcb672 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -84,8 +84,8 @@ int ff_raw_video_read_header(AVFormatContext *s)
 st->codecpar->codec_id = s->iformat->raw_codec_id;
 st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
 
-st->avg_frame_rate = s1->framerate;
 st->internal->avctx->framerate = s1->framerate;
+st->internal->avctx->time_base = av_inv_q(s1->framerate);
 avpriv_set_pts_info(st, 64, 1, 120);
 
 fail:
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] avformat/dump: Print tbc value

[Michael Niedermayer]

Fixes regression of av_dump_format()
Fixes part of Ticket 5444

Signed-off-by: Michael Niedermayer 
---
 libavformat/dump.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index 7ff5ef0..485e9fd 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -492,16 +492,19 @@ static void dump_stream_format(AVFormatContext *ic, int i,
 int fps = st->avg_frame_rate.den && st->avg_frame_rate.num;
 int tbr = st->r_frame_rate.den && st->r_frame_rate.num;
 int tbn = st->time_base.den && st->time_base.num;
+int tbc = st->codec->time_base.den && st->codec->time_base.num;
 
-if (fps || tbr || tbn)
+if (fps || tbr || tbn | tbc)
 av_log(NULL, AV_LOG_INFO, "%s", separator);
 
 if (fps)
-print_fps(av_q2d(st->avg_frame_rate), tbr || tbn ? "fps, " : 
"fps");
+print_fps(av_q2d(st->avg_frame_rate), tbr || tbn || tbc ? "fps, " 
: "fps");
 if (tbr)
-print_fps(av_q2d(st->r_frame_rate), tbn ? "tbr, " : "tbr");
+print_fps(av_q2d(st->r_frame_rate), tbn || tbc ? "tbr, " : "tbr");
 if (tbn)
-print_fps(1 / av_q2d(st->time_base), "tbn");
+print_fps(1 / av_q2d(st->time_base), tbc ? "tbn, " : "tbn");
+if (tbc)
+print_fps(1 / av_q2d(st->codec->time_base), "tbc");
 }
 
 if (st->disposition & AV_DISPOSITION_DEFAULT)
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/rawdec: Fix avg_framerate for h264

[Ronald S. Bultje]

Hi,

On Fri, Jun 3, 2016 at 6:12 PM, Michael Niedermayer 
wrote:

> The framerate is 25 which is a fixed default and is wrong undo the 1 line
> change which caused this regression
> Fixes Ticket 5444
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rawdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
> index 8c734db..2bcb672 100644
> --- a/libavformat/rawdec.c
> +++ b/libavformat/rawdec.c
> @@ -84,8 +84,8 @@ int ff_raw_video_read_header(AVFormatContext *s)
>  st->codecpar->codec_id = s->iformat->raw_codec_id;
>  st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
>
> -st->avg_frame_rate = s1->framerate;
>  st->internal->avctx->framerate = s1->framerate;
> +st->internal->avctx->time_base = av_inv_q(s1->framerate);
>  avpriv_set_pts_info(st, 64, 1, 120);


This seems odd, I thought that we should not touch internal in lavf. Also,
are both parts required (- as well as +), or is the + only enough?

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/rawdec: Fix avg_framerate for h264

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 07:39:08PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Jun 3, 2016 at 6:12 PM, Michael Niedermayer 
> wrote:
> 
> > The framerate is 25 which is a fixed default and is wrong undo the 1 line
> > change which caused this regression
> > Fixes Ticket 5444
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/rawdec.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
> > index 8c734db..2bcb672 100644
> > --- a/libavformat/rawdec.c
> > +++ b/libavformat/rawdec.c
> > @@ -84,8 +84,8 @@ int ff_raw_video_read_header(AVFormatContext *s)
> >  st->codecpar->codec_id = s->iformat->raw_codec_id;
> >  st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
> >
> > -st->avg_frame_rate = s1->framerate;
> >  st->internal->avctx->framerate = s1->framerate;
> > +st->internal->avctx->time_base = av_inv_q(s1->framerate);
> >  avpriv_set_pts_info(st, 64, 1, 120);
> 
> 
> This seems odd, I thought that we should not touch internal in lavf. Also,
> are both parts required (- as well as +), or is the + only enough?

the - part is what is needed
i added the 2nd part as that was how it was originally before the
regression


[...]
-- 
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 1/2] avformat/dump: Print tbc value

[James Almer]

On 6/3/2016 7:12 PM, Michael Niedermayer wrote:
> Fixes regression of av_dump_format()
> Fixes part of Ticket 5444
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/dump.c |   11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 7ff5ef0..485e9fd 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -492,16 +492,19 @@ static void dump_stream_format(AVFormatContext *ic, int 
> i,
>  int fps = st->avg_frame_rate.den && st->avg_frame_rate.num;
>  int tbr = st->r_frame_rate.den && st->r_frame_rate.num;
>  int tbn = st->time_base.den && st->time_base.num;
> +int tbc = st->codec->time_base.den && st->codec->time_base.num;
>  
> -if (fps || tbr || tbn)
> +if (fps || tbr || tbn | tbc)

Shouldn't this be ||?

>  av_log(NULL, AV_LOG_INFO, "%s", separator);
>  
>  if (fps)
> -print_fps(av_q2d(st->avg_frame_rate), tbr || tbn ? "fps, " : 
> "fps");
> +print_fps(av_q2d(st->avg_frame_rate), tbr || tbn || tbc ? "fps, 
> " : "fps");
>  if (tbr)
> -print_fps(av_q2d(st->r_frame_rate), tbn ? "tbr, " : "tbr");
> +print_fps(av_q2d(st->r_frame_rate), tbn || tbc ? "tbr, " : 
> "tbr");
>  if (tbn)
> -print_fps(1 / av_q2d(st->time_base), "tbn");
> +print_fps(1 / av_q2d(st->time_base), tbc ? "tbn, " : "tbn");
> +if (tbc)
> +print_fps(1 / av_q2d(st->codec->time_base), "tbc");
>  }
>  
>  if (st->disposition & AV_DISPOSITION_DEFAULT)
> 

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dump: Print tbc value

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 09:48:02PM -0300, James Almer wrote:
> On 6/3/2016 7:12 PM, Michael Niedermayer wrote:
> > Fixes regression of av_dump_format()
> > Fixes part of Ticket 5444
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/dump.c |   11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavformat/dump.c b/libavformat/dump.c
> > index 7ff5ef0..485e9fd 100644
> > --- a/libavformat/dump.c
> > +++ b/libavformat/dump.c
> > @@ -492,16 +492,19 @@ static void dump_stream_format(AVFormatContext *ic, 
> > int i,
> >  int fps = st->avg_frame_rate.den && st->avg_frame_rate.num;
> >  int tbr = st->r_frame_rate.den && st->r_frame_rate.num;
> >  int tbn = st->time_base.den && st->time_base.num;
> > +int tbc = st->codec->time_base.den && st->codec->time_base.num;
> >  
> > -if (fps || tbr || tbn)
> > +if (fps || tbr || tbn | tbc)
> 
> Shouldn't this be ||?

yea, typo, makes no difference but ill fix it

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] IRC meeting

[compn]

On Fri, 3 Jun 2016 20:32:51 +0200
Christophe Gisquet  wrote:


> SIX)
> > May 28 19:32:58since cehoyos is here, we could
> > maybe talk about his behavior and why the CoC and repercussions for
> > violating it was introduced to begin with May 28 21:51:31 
> > is there anything concrete we’re going to do w.r.t. derek and carl?
> > May 28 21:59:52So Derek and carl? May 28 22:26:54
> > its too late now, and we need to handle the
> > situation at hand May 28 22:28:24nevcairiel, do
> > you want a vote here and now, to what effect? May 28 22:31:09
> >I agree that a vote on the ML would be better to give
> > people that fell asleep here the chance to participate also May 28
> > 22:34:59It's late here. I'm ok for a vote also,
> > just not sure what kind of offense it would be
> 
> And the big, flashy pink, elephant in the room:
> Action: draft a vote on the repercussions to Carl Eugen Hoyos
> behaviours (patch submission, general interaction with others)
> Note, I don't have a strong idea on what it may contain (option of
> temp/week/perma ban, warning, removal of some rights, etc).

i am against voting on rules and then retroactively applying them to
anyone.

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

Re: [FFmpeg-devel] IRC meeting

[compn]

On Fri, 3 Jun 2016 21:13:09 +0200
Michael Niedermayer  wrote:

> On Fri, Jun 03, 2016 at 08:32:51PM +0200, Christophe Gisquet wrote:
> i want some assistent to help with dayly server admin duties
> most root admins we have help and contribute but are often busy
> raz recently set up a full backup system for us, someone seems
> helping with security updates as iam not always the first doing them
> (i think its lou but didnt check) and all kinds of other things ...
> 
> what would be really nice would be someone who has some time and for
> whom server admining is a fun thing to do,
> someone who would do it "because it needs to be done" would be 2nd
> choice IMHO
> 

i am against using github, but am for using vlc admins if we vote that
way.

i think i may take back my offer to admin. i was more offering to help
michael with $random admin tasks.

but i dont think i can dedicate much time to it, sorry :(


> 
> [...]
> > SIX)
> > > May 28 19:32:58since cehoyos is here, we could
> > > maybe talk about his behavior and why the CoC and repercussions
> > > for violating it was introduced to begin with May 28 21:51:31
> > >is there anything concrete we’re going to do w.r.t. derek
> > > and carl? May 28 21:59:52So Derek and carl? May
> > > 28 22:26:54 its too late now, and we need to
> > > handle the situation at hand May 28 22:28:24 
> > > nevcairiel, do you want a vote here and now, to what effect? May
> > > 28 22:31:09I agree that a vote on the ML would be better
> > > to give people that fell asleep here the chance to participate
> > > also May 28 22:34:59It's late here. I'm ok for a
> > > vote also, just not sure what kind of offense it would be
> > 
> > And the big, flashy pink, elephant in the room:
> > Action: draft a vote on the repercussions to Carl Eugen Hoyos
> > behaviours (patch submission, general interaction with others)
> > Note, I don't have a strong idea on what it may contain (option of
> > temp/week/perma ban, warning, removal of some rights, etc).
> 
> iam not suggesting anything specific but there is one thing that i
> think i have not seen talked about and that is moderation. Mailman
> supports moderating individual subscribers.
> 
> It might be along the lines of
> If one repeatly and conciously violates the CoC and no real solution
> can be found, he can be given the choice by the mailman admins to
> either promise to attempt not to repeat the violation
> or to be moderated until an event occurs that changes the situation
> or some timeout.
> The insulted person should have the option to veto this at any time so
> if one feels that it wasnt enough to justify the inconvenience the
> "hurt" party should be able to stop this.
> This would have to be combined with something effective for IRC and
> possibly git, in case issues shift there too


i like the idea of moderating certain members, when they start in with
insults. assuming we vote in the CoC...

i personally enjoy free speech to insult everyone but , democracy :P

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

[FFmpeg-devel] [PATCH] avcodec/utils: initialize delay in avcodec_parameters_to_context()

[Michael Niedermayer]

Fixes lost codec delayy
Should fix Ticket5509

Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 7b99526..4016583 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -4157,6 +4157,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 codec->sample_rate = par->sample_rate;
 codec->block_align = par->block_align;
 codec->frame_size  = par->frame_size;
+codec->delay   =
 codec->initial_padding = par->initial_padding;
 codec->seek_preroll= par->seek_preroll;
 break;
-- 
1.7.9.5

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

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

[XinZheng Zhang]

On Wed, Jun 1, 2016 at 12:03 PM, 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.
>
> Besides, we can put this task into a background thread,
> and detach from it when we want to cancel the task,
> or it is timed out. But unfortunately,
> there are no global thread pool or other background facility
> to host such detached tasks in ffmpeg


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