date:20171022

On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch silences the many warnings shown when decoding streams
> with DolbyVision content.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch
> 
> 
> From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 22 Oct 2017 02:17:27 +0200
> Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.
> 
> ---
>  libavcodec/hevcdec.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 2e4add2..d5ed9f5 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  break;
>  case HEVC_NAL_AUD:
>  case HEVC_NAL_FD_NUT:
> +case 62: // unspecified, used by DolbyVision
> +case 63: // unspecified, used by DolbyVision

No, the log message should be set to verbose level instead, like
inff_hevc_decode_extradata(). It's something of little value for the
info level and effectively just spams stderr when trying to decode files
with unofficial or currently unsupported NAL units.

>  break;
>  default:
>  av_log(s->avctx, AV_LOG_INFO,
> -- 1.7.10.4
> 
> 
> 
> ___
> 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] avutil/crc: always use precalculated CRC tables for known polynomials

On Sun, Oct 22, 2017 at 10:03:55AM -0300, James Almer wrote:
> This prevents data races in av_crc_get_table()

the modules which use a specific crc can init it during their
initialization.
the initialization should be thread safe as it never writes a different
value in the same spot
This would avoid the need to alwas hardcode the tables

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

On Sat, Oct 21, 2017 at 08:13:15AM +, Dixit, Vishwanath wrote:
> Hi,
[...]

> @@ -1324,17 +1345,183 @@ static const char * 
> get_default_pattern_localtime_fmt(AVFormatContext *s)
>  return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || 
> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
>  }
>  
> +static int format_name(char *name, int name_buf_len, int i)
> +{
> +char *p;
> +char extension[10] = {'\0'};
> +
> +p = strrchr(name, '.');
> +if (p) {
> +strcpy(extension, p);
> +*p = '\0';
> +}
> +

> +sprintf(name + strlen(name), POSTFIX_PATTERN, i);

please always use snprintf() it is safer

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [RFC] v4l2_m2m: Fix races around freeing data on close

2017-10-22 Thread Mark Thompson

On 19/10/17 18:55, Jorge Ramirez wrote:
> On 10/19/2017 11:49 AM, Mark Thompson wrote:
>> On 19/10/17 08:28, Jorge Ramirez wrote:
>>> On 10/19/2017 02:10 AM, Mark Thompson wrote:
 Refcount all of the context information.
 ---
 As discussed in the other thread, something like this.  We move most of 
 the context into a refcounted buffer and AVCodecContext.priv_data is left 
 as a stub holding a reference to it.
>>> um, ok ... please could you send a patch so I can apply it? I see several 
>>> problems in v4l2_free_buffer.
>> What goes wrong?  It applies fine for me on current head 
>> (f4090940bd3024e69d236257d327f11d1e496229).
> 
> yes my bad.
> 
>>
>>> To sum up the RFC, instead of using private_data to place the codec's 
>>> context, it uses private data to place a _pointer_ to an allocated codec 
>>> context "just" so it wont be deallocated after the codec is closed (codec 
>>> close frees the private_data)
>>>
>>> Personally I think adding AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE and use 
>>> private_data to hold the codec context is a cleaner/simpler approach.
>>>
>>> - the codec requests private_data with a size (sizeof(type))
>>> - the code explicitly informs the API whether all memory will be released 
>>> on close or it will preserve it.
>> - All APIs in ffmpeg with this sort of private data field use them in the 
>> same way - they are allocated at create/alloc time (with the given size, for 
>> AVOptions), and freed at close/destroy time.
>> - Using the well-tested reference-counted buffer implementation is IMO 
>> strongly preferable to making ad-hoc synchronisation with atomics and 
>> semaphores.
>> - All other decoders use the reference-counted buffer approach (e.g. look at 
>> rkmpp for a direct implementation, the hwaccels all do it via hwcontext).
> 
> ok so I guess there is no point to discuss further what I tried to put 
> forward (I could provide my implementation to compare against this RFC - it 
> is just a handful of lines of code - but I guess there is no point given that 
> everyone is comfortable with the current way of doing things.).
> 
> so let's make this work then and fix the SIGSEGV present in master asap (btw 
> this RFC also seg-fault when the above is applied)

Where does that version segfault?  (It doesn't for me.)

> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 831fd81..1dd8cf0 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -176,8 +176,8 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
>   * by the v4l2 driver; this event will trigger a full pipeline reconfig 
> and
>   * the proper values will be retrieved from the kernel driver.
>   */
> -    output->height = capture->height = avctx->coded_height;
> -    output->width = capture->width = avctx->coded_width;
> +    output->height = capture->height = 0; //avctx->coded_height;
> +    output->width = capture->width = 0; //avctx->coded_width;
> 
>  output->av_codec_id = avctx->codec_id;
>  output->av_pix_fmt  = AV_PIX_FMT_NONE;

Sure, that coded_width/height information is meaningless anyway.

> also looking at your code I think we also need:
> 
> [jramirez@igloo libavcodec (patches/m6 *$)]$ git diff v4l2_buffers.c
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index 9831bdb..8dec56d 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -207,15 +207,19 @@ static void v4l2_free_buffer(void *opaque, uint8_t 
> *unused)
>  V4L2Buffer* avbuf = opaque;
>  V4L2m2mContext *s = buf_to_m2mctx(avbuf);
> 
> -    atomic_fetch_sub_explicit(>refcount, 1, memory_order_acq_rel);
> -    if (s->reinit) {
> -    if (!atomic_load(>refcount))
> -    sem_post(>refsync);
> -    } else if (avbuf->context->streamon) {
> -    ff_v4l2_buffer_enqueue(avbuf);
> -    }
> +    av_log(logger(avbuf), AV_LOG_DEBUG, "free capture %d\n", 
> avbuf->buf.index);
> 
>  if (atomic_fetch_sub(>context_refcount, 1) == 1) {
> +    atomic_fetch_sub_explicit(>refcount, 1, memory_order_acq_rel);
> +
> +    if (s->reinit) {
> +    if (!atomic_load(>refcount))
> +    sem_post(>refsync);
> +    } else if (avbuf->context->streamon) {
> +    av_log(logger(avbuf), AV_LOG_DEBUG, "queue capture %d\n", 
> avbuf->buf.index);
> +    ff_v4l2_buffer_enqueue(avbuf);
> +    }
> +
>  av_buffer_unref(>context_ref);
>  }
>  }

I don't think moving it inside the only-run-once-for-each-buffer check like 
this works, because the refcount here is incremented once-per-plane rather than 
once-per-buffer.

The context_refcount check there is really just a hack around the 
once-per-plane behaviour - I think it would probably be better to fix that 
first (including the redundant submission), because then this would be easier 
to reason about.

> 
> I tested the encoder and it seems to work properly (havent checked with 
> valgrind but all

[FFmpeg-devel] [PATCH] avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo()

This prevents potential ABI issues with GetBitContext.

Signed-off-by: James Almer 
---
 libavcodec/tak.c | 17 +++--
 libavcodec/tak.h |  8 ++--
 libavformat/takdec.c |  7 +--
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/libavcodec/tak.c b/libavcodec/tak.c
index d2670e00ff..8aa956b661 100644
--- a/libavcodec/tak.c
+++ b/libavcodec/tak.c
@@ -90,7 +90,7 @@ int ff_tak_check_crc(const uint8_t *buf, unsigned int 
buf_size)
 return 0;
 }
 
-void avpriv_tak_parse_streaminfo(GetBitContext *gb, TAKStreamInfo *s)
+void ff_tak_parse_streaminfo(TAKStreamInfo *s, GetBitContext *gb)
 {
 uint64_t channel_mask = 0;
 int frame_type, i;
@@ -125,6 +125,19 @@ void avpriv_tak_parse_streaminfo(GetBitContext *gb, 
TAKStreamInfo *s)
 s->frame_samples = tak_get_nb_samples(s->sample_rate, frame_type);
 }
 
+int avpriv_tak_parse_streaminfo(TAKStreamInfo *s, const uint8_t *buf, int size)
+{
+GetBitContext gb;
+int ret = init_get_bits8(, buf, size);
+
+if (ret < 0)
+return AVERROR_INVALIDDATA;
+
+ff_tak_parse_streaminfo(s, );
+
+return 0;
+}
+
 int ff_tak_decode_frame_header(AVCodecContext *avctx, GetBitContext *gb,
TAKStreamInfo *ti, int log_level_offset)
 {
@@ -144,7 +157,7 @@ int ff_tak_decode_frame_header(AVCodecContext *avctx, 
GetBitContext *gb,
 }
 
 if (ti->flags & TAK_FRAME_FLAG_HAS_INFO) {
-avpriv_tak_parse_streaminfo(gb, ti);
+ff_tak_parse_streaminfo(ti, gb);
 
 if (get_bits(gb, 6))
 skip_bits(gb, 25);
diff --git a/libavcodec/tak.h b/libavcodec/tak.h
index 4fa1239093..dc45a8c070 100644
--- a/libavcodec/tak.h
+++ b/libavcodec/tak.h
@@ -143,10 +143,14 @@ int ff_tak_check_crc(const uint8_t *buf, unsigned int 
buf_size);
 
 /**
  * Parse the Streaminfo metadata block.
- * @param[in]  gb pointer to GetBitContext
  * @param[out] s  storage for parsed information
+ * @param[in]  buf   input buffer
+ * @param[in]  size  size of input buffer in bytes
+ * @return non-zero on error, 0 if OK
  */
-void avpriv_tak_parse_streaminfo(GetBitContext *gb, TAKStreamInfo *s);
+int avpriv_tak_parse_streaminfo(TAKStreamInfo *s, const uint8_t *buf, int 
size);
+
+void ff_tak_parse_streaminfo(TAKStreamInfo *s, GetBitContext *gb);
 
 /**
  * Validate and decode a frame header.
diff --git a/libavformat/takdec.c b/libavformat/takdec.c
index 1535bec64f..6fda35c1be 100644
--- a/libavformat/takdec.c
+++ b/libavformat/takdec.c
@@ -103,7 +103,6 @@ static int tak_read_header(AVFormatContext *s)
 }
 }
 
-init_get_bits8(, buffer, size - 3);
 break;
 case TAK_METADATA_MD5: {
 uint8_t md5[16];
@@ -145,7 +144,9 @@ static int tak_read_header(AVFormatContext *s)
 if (type == TAK_METADATA_STREAMINFO) {
 TAKStreamInfo ti;
 
-avpriv_tak_parse_streaminfo(, );
+ret = avpriv_tak_parse_streaminfo(, buffer, size -3);
+if (ret < 0)
+return AVERROR_INVALIDDATA;
 if (ti.samples > 0)
 st->duration = ti.samples;
 st->codecpar->bits_per_coded_sample = ti.bps;
@@ -161,11 +162,13 @@ static int tak_read_header(AVFormatContext *s)
 } else if (type == TAK_METADATA_LAST_FRAME) {
 if (size != 11)
 return AVERROR_INVALIDDATA;
+init_get_bits8(, buffer, size - 3);
 tc->mlast_frame = 1;
 tc->data_end= get_bits64(, TAK_LAST_FRAME_POS_BITS) +
   get_bits(, TAK_LAST_FRAME_SIZE_BITS);
 av_freep();
 } else if (type == TAK_METADATA_ENCODER) {
+init_get_bits8(, buffer, size - 3);
 av_log(s, AV_LOG_VERBOSE, "encoder version: %0X\n",
get_bits_long(, TAK_ENCODER_VERSION_BITS));
 av_freep();
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-22 15:03 GMT+02:00 James Almer :
> This prevents data races in av_crc_get_table()

Doesn't this mix two changes - moving the tables into a
dedicated file and making them static - that are not
necessarily related?

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

Re: [FFmpeg-devel] [PATCH]lavc/bitstream_filter: Make a cast explicit

2017-10-22 23:22 GMT+02:00 Michael Niedermayer :
> On Wed, Mar 01, 2017 at 11:36:58PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences one of three warnings when compiling
>> bitstream_filter.o, I suspect this cast is necessary.
>>
>> Please comment, Carl Eugen
>
> probably ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH]lavc/avcodec: Constify the return value of av_bitstream_filter_next().

2017-10-21 21:17 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes a warning when compiling with sufficiently new gcc.

Working patch attached.

Carl Eugen
From 19077d0125e1e1eca81dc0311440c1a7da16e080 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 22 Oct 2017 23:38:31 +0200
Subject: [PATCH] lavc/avcodec: Constify the return value of
 av_bitstream_filter_next().

Fixes the following gcc warning:
libavcodec/bitstream_filter.c:39:12: warning: return discards 'const' qualifier from pointer target type
---
 libavcodec/avcodec.h  |2 +-
 libavcodec/bitstream_filter.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 40c8fab..dc4659f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5951,7 +5951,7 @@ void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
  * filters.
  */
 attribute_deprecated
-AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
+const AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
 #endif
 
 /**
diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
index 8599b90..b7d9adc 100644
--- a/libavcodec/bitstream_filter.c
+++ b/libavcodec/bitstream_filter.c
@@ -28,7 +28,7 @@
 #if FF_API_OLD_BSF
 FF_DISABLE_DEPRECATION_WARNINGS
 
-AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f)
+const AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f)
 {
 const AVBitStreamFilter *filter = NULL;
 void *opaque = NULL;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/bitstream_filter: Make a cast explicit

On Wed, Mar 01, 2017 at 11:36:58PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch silences one of three warnings when compiling 
> bitstream_filter.o, I suspect this cast is necessary.
> 
> Please comment, Carl Eugen

probably ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.

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

Re: [FFmpeg-devel] fate/hap : add test for HAPQA decoding

On Sat, Oct 21, 2017 at 07:37:31PM +0200, Martin Vignali wrote:
> Hello,
> 
> Sample can be found here
> https://we.tl/1XuI6QJ7Ra

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] order T-shirts

2017-10-22 Thread Thilo Borgmann

Am 22.10.17 um 18:18 schrieb Ronald S. Bultje:
> Hi,
> 
> On Sun, Oct 22, 2017 at 7:23 AM, Thilo Borgmann 
> wrote:
> 
>> Am 22.10.17 um 09:55 schrieb Liu Steven:
>>>
 在 2017年10月22日，上午2:42，Lou Logan  写道：

 I was thinking of black shirt, green logo, white "FFmpeg" lettering.
>>> I like this thinking too :D
>>
>> I must say that the black/white style comes closer to what our website has
>> color-wise...
>>
>> So what do others think about colors? Shall I make a 3-color-sample first?
>> We might do more than one version.
>> They open again Tuesday...
>>
> 
> I personally don't think it's a big deal either way, but green logo would
> be nice, I believe the original logo (and current favicon) was green.

Okay then I'll try to have the logo in green and white printing. I'd order all
green printings for the case that green/white printings would be too much extra
cost (>15/shirt I'd say).

Fine?

-Thilo

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

[FFmpeg-devel] libavcodec/bswapdsp : add AVX2 for bswap_buf

2017-10-22 Thread Martin Vignali

Hello,

In attach patch in order to add an AVX2 version for bswap_buf
(swap uint32 in a buffer)

Checkasm result (Kaby Lake 10.12)
bswap_buf_c: 122.8
bswap_buf_sse2: 67.8
bswap_buf_ssse3: 34.3
bswap_buf_avx2: 21.0


Pass checkasm and fate test for me


Martin
Jokyo Images


0001-libavcodec-bswapdsp-add-AVX2-func-for-bswap_buf.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

Hi,

On Sun, Oct 22, 2017 at 7:23 AM, Thilo Borgmann 
wrote:

> Am 22.10.17 um 09:55 schrieb Liu Steven:
> >
> >> 在 2017年10月22日，上午2:42，Lou Logan  写道：
> >>
> >> I was thinking of black shirt, green logo, white "FFmpeg" lettering.
> > I like this thinking too :D
>
> I must say that the black/white style comes closer to what our website has
> color-wise...
>
> So what do others think about colors? Shall I make a 3-color-sample first?
> We might do more than one version.
> They open again Tuesday...
>

I personally don't think it's a big deal either way, but green logo would
be nice, I believe the original logo (and current favicon) was green.

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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

Hi,

On Sun, Oct 22, 2017 at 9:43 AM, James Almer  wrote:

> On 10/22/2017 8:26 AM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer
>  >> wrote:
> >
> >> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
> >>   wrote:
> >>>
>  This is different from FF_API_VISMV which is supported through
> >> codecview.
> 
>  Signed-off-by: Michael Niedermayer 
>  ---
>   libavcodec/version.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/libavcodec/version.h b/libavcodec/version.h
>  index 8584bb7006..25696690d7 100644
>  --- a/libavcodec/version.h
>  +++ b/libavcodec/version.h
>  @@ -79,7 +79,7 @@
>   #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
>   #endif
>   #ifndef FF_API_DEBUG_MV
>  -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
>  +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
>   #endif
> 
> >>>
> >>> Can you give an explanation for why this should be delayed? (It's
> missing
> >>> in the commit message, and this is hard to evaluate without a
> >>> justification/explanation.)
> >>
> >> It was not agreed on ffmpeg-devel to remove this feature.
> >>
> >> Its used for example by me occasionally to analyze videos in bug
> >> reports for debuging them.
> >>
> >> There is no replacement or alternative iam aware of
> >>
> >
> > The replacement will never be written if:
> > a) nobody cares; AND
> > b) we keep delaying the removal
> >
> > I'm considering veto'ing this patch.
>
> Personally I'm with Clement in this. The deprecation was poorly handled,
> and the feature currently has no replacement. Michael uses it for
> debugging, so removing it does not seem productive.
>
> But, also agreeing with Clement, this should absolutely be ported to the
> codecview filter before the next bump, or it will be removed.
>

But this is the whole problem. We're stuck in a stalemate between nothing
and nobody. As with ffserver, we'll keep postponing this forever more until
the stalemate is broken.

What incentive is there for anyone to write a replacement for this feature?
And stack that incentive against the pool of available developers that have
time and interest in this feature, and what are you left with?

Nothing.

==

We need to move away from this stalemate-driven development. "ffserver"
shows how that can work. What we could propose is to accept this patch,
based on the understanding that we also - at the same time - agree on
timeline for final, conclusive, non-veto'able removal of this feature
within half a year, either replaced with an improved version that went
through real review and is for once not a total hack, or just not replaced
with anything at all.

==

If debugging using this feature really only happens once in a blue moon,
why not debug on a release branch? I'm thinking of Kieran complaining about
how hard it is to work on mpegvideo (10-bits anyone?) and all of this is
just not helping at all...

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

[FFmpeg-devel] [PATCH 1/2] ffserver: Fix off by 1 error in path

Signed-off-by: Michael Niedermayer 
---
 fftools/ffserver.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fftools/ffserver.c b/fftools/ffserver.c
index d4885dfa0e..51f31bc704 100644
--- a/fftools/ffserver.c
+++ b/fftools/ffserver.c
@@ -499,9 +499,9 @@ static void start_children(FFServerStream *feed)
 if (!slash) {
 pathname = av_mallocz(sizeof("ffmpeg"));
 } else {
-pathname = av_mallocz(slash - my_program_name + sizeof("ffmpeg"));
+pathname = av_mallocz(slash - my_program_name + 1 + sizeof("ffmpeg"));
 if (pathname != NULL) {
-memcpy(pathname, my_program_name, slash - my_program_name);
+memcpy(pathname, my_program_name, slash - my_program_name + 1);
 }
 }
 if (!pathname) {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] tests/ffserver.regression.ref: update checksums to what ffserver currently produces

Signed-off-by: Michael Niedermayer 
---
 tests/ffserver.regression.ref | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/ffserver.regression.ref b/tests/ffserver.regression.ref
index 398c285156..fd8536c853 100644
--- a/tests/ffserver.regression.ref
+++ b/tests/ffserver.regression.ref
@@ -1,11 +1,11 @@
 0c9639f09decbc54c9f091dcf1ca0e8f *ff-test_h.avi
 e28ba75853caf975e06d92955c9f7f73 *ff-test_l.avi
 a767dbdf5d1bded3450279f812f97b37 *ff-test.swf
-dc16f607e13328a832e73801cd21ec98 *ff-test_h.asf
-69337d6c8cd7ac7e626338decdbf41d3 *ff-test_l.asf
+ca209a0c67afbd3bc3bcde0840f313fc *ff-test_h.asf
+f97a91609bfc8a1857455f17c5ec101c *ff-test_l.asf
 06f5a6a4c5d1c6735f4d0068e825c91f *ff-test_h.rm
 1f57580f02f0317407b3b82a3d5e093f *ff-test_l.rm
-4c887dfc1dd0f6ea1a3a2be6dd32e495 *ff-test.jpg
-1d04b73b04aad27793cc762d5afabac1 *ff-test_small.jpg
-bc36c40ee34ebee6ffe50f3094aab733 *ff-test.mjpg
+e04e6ebf9584654df131f5eec881ac38 *ff-test.jpg
+f15d43e9d3630601b61a024023249bb8 *ff-test_small.jpg
+4735c72cde67000f12e9d1dbfbd975a7 *ff-test.mjpg
 fd038af80560e15271ce42651093ee43 *ff-stat
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] mov: fix decode of fragments that overlap in time

2017-10-22 Thread John Stebbins

On 10/12/2017 10:59 AM, John Stebbins wrote:
> When keyframe intervals of dash segments are not perfectly aligned,
> fragments in the stream can overlap in time. The previous sorting by
> timestamp causes packets to be read out of decode order and results
> in decode errors.
>
> Insert new "trun" index entries into index_entries in the order that
> the trun are referenced by the sidx.
> ---
>  libavformat/isom.h |  26 +-
>  libavformat/mov.c  | 684 
> -
>  2 files changed, 485 insertions(+), 225 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index b9380e9dcc..395d20d25c 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -93,7 +93,6 @@ typedef struct MOVFragment {
>  unsigned duration;
>  unsigned size;
>  unsigned flags;
> -int64_t time;
>  } MOVFragment;
>  
>  typedef struct MOVTrackExt {
> @@ -109,17 +108,28 @@ typedef struct MOVSbgp {
>  unsigned int index;
>  } MOVSbgp;
>  
> +typedef struct MOVFragmentStreamInfo {
> +int id;
> +int64_t sidx_pts;
> +int64_t first_tfra_pts;
> +int64_t tfdt_dts;
> +int index_entry;
> +} MOVFragmentStreamInfo;
> +
>  typedef struct MOVFragmentIndexItem {
>  int64_t moof_offset;
> -int64_t time;
>  int headers_read;
> +int current;
> +int nb_stream_info;
> +MOVFragmentStreamInfo * stream_info;
>  } MOVFragmentIndexItem;
>  
>  typedef struct MOVFragmentIndex {
> -unsigned track_id;
> -unsigned item_count;
> -unsigned current_item;
> -MOVFragmentIndexItem *items;
> +int allocated_size;
> +int complete;
> +int current;
> +int nb_items;
> +MOVFragmentIndexItem * item;
>  } MOVFragmentIndex;
>  
>  typedef struct MOVIndexRange {
> @@ -250,9 +260,7 @@ typedef struct MOVContext {
>  int moov_retry;
>  int use_mfra_for;
>  int has_looked_for_mfra;
> -MOVFragmentIndex** fragment_index_data;
> -unsigned fragment_index_count;
> -int fragment_index_complete;
> +MOVFragmentIndex frag_index;
>  int atom_depth;
>  unsigned int aax_mode;  ///< 'aax' file has been detected
>  uint8_t file_key[20];
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 899690d920..d6d2c813a8 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1168,6 +1168,211 @@ static int mov_read_moov(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0; /* now go for mdat */
>  }
>  
> +static MOVFragmentStreamInfo * get_frag_stream_info(
> +MOVFragmentIndex *frag_index,
> +int index,
> +int id)
> +{
> +int i;
> +MOVFragmentIndexItem * item;
> +
> +if (index < 0 || index >= frag_index->nb_items)
> +return NULL;
> +item = _index->item[index];
> +for (i = 0; i < item->nb_stream_info; i++)
> +if (item->stream_info[i].id == id)
> +return >stream_info[i];
> +
> +// This shouldn't happen
> +return NULL;
> +}
> +
> +static void set_frag_stream(MOVFragmentIndex *frag_index, int id)
> +{
> +int i;
> +MOVFragmentIndexItem * item;
> +
> +if (frag_index->current < 0 ||
> +frag_index->current >= frag_index->nb_items)
> +return;
> +
> +item = _index->item[frag_index->current];
> +for (i = 0; i < item->nb_stream_info; i++)
> +if (item->stream_info[i].id == id) {
> +item->current = i;
> +return;
> +}
> +
> +// id not found.  This shouldn't happen.
> +item->current = -1;
> +}
> +
> +static MOVFragmentStreamInfo * get_current_frag_stream_info(
> +MOVFragmentIndex *frag_index)
> +{
> +MOVFragmentIndexItem * item = _index->item[frag_index->current];
> +if (item->current >= 0 && item->current < item->nb_stream_info)
> +return >stream_info[item->current];
> +
> +// This shouldn't happen
> +return NULL;
> +}
> +
> +static int search_frag_moof_offset(MOVFragmentIndex *frag_index, int64_t 
> offset)
> +{
> +int a, b, m;
> +int64_t moof_offset;
> +
> +// Optimize for appending new entries
> +if (!frag_index->nb_items ||
> +frag_index->item[frag_index->nb_items - 1].moof_offset < offset)
> +return frag_index->nb_items;
> +
> +a = -1;
> +b = frag_index->nb_items;
> +
> +while (b - a > 1) {
> +m = (a + b) >> 1;
> +moof_offset = frag_index->item[m].moof_offset;
> +if (moof_offset >= offset)
> +b = m;
> +if (moof_offset <= offset)
> +a = m;
> +}
> +return b;
> +}
> +
> +static int64_t get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
> +{
> +
> +if (frag_stream_info) {
> +if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
> +return frag_stream_info->sidx_pts;
> +if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
> +return frag_stream_info->first_tfra_pts;
> +if (frag_stream_info->tfdt_dts != AV_NOPTS_VALUE)
> +return

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

On Sun, Oct 22, 2017 at 10:43:35AM -0300, James Almer wrote:
[...]
> Personally I'm with Clement in this. The deprecation was poorly handled,
> and the feature currently has no replacement. Michael uses it for
> debugging, so removing it does not seem productive.

Not just Michael, it's generally a good study case for understanding
codecs.

See https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors

Apparently, some people were caring about it enough to document it.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264dec: Fix potential array overread

2017-10-22 Thread Paul B Mahol

On 10/22/17, Michael Niedermayer  wrote:
> On Sun, Oct 22, 2017 at 07:28:31AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Oct 21, 2017 at 7:41 PM, Michael Niedermayer
>> > > wrote:
>>
>> > add padding before scantable arrays
>> >
>> > See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/h264dec.h | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
>> > index 2106ba077e..de8b7c38b9 100644
>> > --- a/libavcodec/h264dec.h
>> > +++ b/libavcodec/h264dec.h
>> > @@ -416,6 +416,7 @@ typedef struct H264Context {
>> >  uint8_t (*mvd_table[2])[2];
>> >  uint8_t *direct_table;
>> >
>> > +uint8_t scan_padding[16];
>> >  uint8_t zigzag_scan[16];
>> >  uint8_t zigzag_scan8x8[64];
>> >  uint8_t zigzag_scan8x8_cavlc[64];
>> > --
>> > 2.14.2
>>
>>
>> This is 16 bytes; isn't the space before it (the pointers) already
>> providing that space? Or do you want it to be zero'ed so resulting
>> indices
>> can be used for writing into the coef array?
>
> I wanted to ensure that the pointer cannot leak into the output.
> Possibly giving an attacker information about the memory layout

Can we expect more of such patches in future?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

On 10/22/2017 8:26 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer > wrote:
> 
>> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
>> >>
 This is different from FF_API_VISMV which is supported through
>> codecview.

 Signed-off-by: Michael Niedermayer 
 ---
  libavcodec/version.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavcodec/version.h b/libavcodec/version.h
 index 8584bb7006..25696690d7 100644
 --- a/libavcodec/version.h
 +++ b/libavcodec/version.h
 @@ -79,7 +79,7 @@
  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
  #endif
  #ifndef FF_API_DEBUG_MV
 -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
 +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
  #endif

>>>
>>> Can you give an explanation for why this should be delayed? (It's missing
>>> in the commit message, and this is hard to evaluate without a
>>> justification/explanation.)
>>
>> It was not agreed on ffmpeg-devel to remove this feature.
>>
>> Its used for example by me occasionally to analyze videos in bug
>> reports for debuging them.
>>
>> There is no replacement or alternative iam aware of
>>
> 
> The replacement will never be written if:
> a) nobody cares; AND
> b) we keep delaying the removal
> 
> I'm considering veto'ing this patch.

Personally I'm with Clement in this. The deprecation was poorly handled,
and the feature currently has no replacement. Michael uses it for
debugging, so removing it does not seem productive.

But, also agreeing with Clement, this should absolutely be ported to the
codecview filter before the next bump, or it will be removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-22 Thread Derek Buitenhuis

On 10/22/2017 2:11 PM, James Almer wrote:
> It was suggested, but nobody gave it a try (Or they did but found it
> wasn't as simple as first thought?).

[...]

> Thread sanitizer complains about this in every other run, and the tables
> are at most 1k each, so this is not a bad solution and can be replaced
> by ff_thread_once in the future.

And say that N times and you end up with Nk of tables ;).

That said, I'm not NAKing the patch, just suggesting an alternative.

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

On 10/22/2017 10:08 AM, Derek Buitenhuis wrote:
> On 10/22/2017 2:03 PM, James Almer wrote:
>> This prevents data races in av_crc_get_table()
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/Makefile |1 +
>>  libavutil/crc.c|  295 +-
>>  libavutil/crc_tables.c | 1030 
>> 
>>  libavutil/crc_tables.h |   33 ++
>>  4 files changed, 1066 insertions(+), 293 deletions(-)
>>  create mode 100644 libavutil/crc_tables.c
>>  create mode 100644 libavutil/crc_tables.h
> 
> Can this be generated at init, or lazily, using ff_thread_once instead of
> hardcoding huge tables?
> 
> - Derek

It was suggested, but nobody gave it a try (Or they did but found it
wasn't as simple as first thought?).

Thread sanitizer complains about this in every other run, and the tables
are at most 1k each, so this is not a bad solution and can be replaced
by ff_thread_once in the future.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-22 Thread Derek Buitenhuis

On 10/22/2017 2:03 PM, James Almer wrote:
> This prevents data races in av_crc_get_table()
> 
> Signed-off-by: James Almer 
> ---
>  libavutil/Makefile |1 +
>  libavutil/crc.c|  295 +-
>  libavutil/crc_tables.c | 1030 
> 
>  libavutil/crc_tables.h |   33 ++
>  4 files changed, 1066 insertions(+), 293 deletions(-)
>  create mode 100644 libavutil/crc_tables.c
>  create mode 100644 libavutil/crc_tables.h

Can this be generated at init, or lazily, using ff_thread_once instead of
hardcoding huge tables?

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

[FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

This prevents data races in av_crc_get_table()

Signed-off-by: James Almer 
---
 libavutil/Makefile |1 +
 libavutil/crc.c|  295 +-
 libavutil/crc_tables.c | 1030 
 libavutil/crc_tables.h |   33 ++
 4 files changed, 1066 insertions(+), 293 deletions(-)
 create mode 100644 libavutil/crc_tables.c
 create mode 100644 libavutil/crc_tables.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 4fe81fdd07..88a5c725c1 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -102,6 +102,7 @@ OBJS = adler32.o
\
color_utils.o\
cpu.o\
crc.o\
+   crc_tables.o \
des.o\
dict.o   \
display.o\
diff --git a/libavutil/crc.c b/libavutil/crc.c
index 495732b163..ed94368f68 100644
--- a/libavutil/crc.c
+++ b/libavutil/crc.c
@@ -23,289 +23,7 @@
 #include "bswap.h"
 #include "common.h"
 #include "crc.h"
-
-#if CONFIG_HARDCODED_TABLES
-static const AVCRC av_crc_table[AV_CRC_MAX][257] = {
-[AV_CRC_8_ATM] = {
-0x00, 0x07, 0x0E, 0x09, 0x1C, 0x1B, 0x12, 0x15, 0x38, 0x3F, 0x36, 0x31,
-0x24, 0x23, 0x2A, 0x2D, 0x70, 0x77, 0x7E, 0x79, 0x6C, 0x6B, 0x62, 0x65,
-0x48, 0x4F, 0x46, 0x41, 0x54, 0x53, 0x5A, 0x5D, 0xE0, 0xE7, 0xEE, 0xE9,
-0xFC, 0xFB, 0xF2, 0xF5, 0xD8, 0xDF, 0xD6, 0xD1, 0xC4, 0xC3, 0xCA, 0xCD,
-0x90, 0x97, 0x9E, 0x99, 0x8C, 0x8B, 0x82, 0x85, 0xA8, 0xAF, 0xA6, 0xA1,
-0xB4, 0xB3, 0xBA, 0xBD, 0xC7, 0xC0, 0xC9, 0xCE, 0xDB, 0xDC, 0xD5, 0xD2,
-0xFF, 0xF8, 0xF1, 0xF6, 0xE3, 0xE4, 0xED, 0xEA, 0xB7, 0xB0, 0xB9, 0xBE,
-0xAB, 0xAC, 0xA5, 0xA2, 0x8F, 0x88, 0x81, 0x86, 0x93, 0x94, 0x9D, 0x9A,
-0x27, 0x20, 0x29, 0x2E, 0x3B, 0x3C, 0x35, 0x32, 0x1F, 0x18, 0x11, 0x16,
-0x03, 0x04, 0x0D, 0x0A, 0x57, 0x50, 0x59, 0x5E, 0x4B, 0x4C, 0x45, 0x42,
-0x6F, 0x68, 0x61, 0x66, 0x73, 0x74, 0x7D, 0x7A, 0x89, 0x8E, 0x87, 0x80,
-0x95, 0x92, 0x9B, 0x9C, 0xB1, 0xB6, 0xBF, 0xB8, 0xAD, 0xAA, 0xA3, 0xA4,
-0xF9, 0xFE, 0xF7, 0xF0, 0xE5, 0xE2, 0xEB, 0xEC, 0xC1, 0xC6, 0xCF, 0xC8,
-0xDD, 0xDA, 0xD3, 0xD4, 0x69, 0x6E, 0x67, 0x60, 0x75, 0x72, 0x7B, 0x7C,
-0x51, 0x56, 0x5F, 0x58, 0x4D, 0x4A, 0x43, 0x44, 0x19, 0x1E, 0x17, 0x10,
-0x05, 0x02, 0x0B, 0x0C, 0x21, 0x26, 0x2F, 0x28, 0x3D, 0x3A, 0x33, 0x34,
-0x4E, 0x49, 0x40, 0x47, 0x52, 0x55, 0x5C, 0x5B, 0x76, 0x71, 0x78, 0x7F,
-0x6A, 0x6D, 0x64, 0x63, 0x3E, 0x39, 0x30, 0x37, 0x22, 0x25, 0x2C, 0x2B,
-0x06, 0x01, 0x08, 0x0F, 0x1A, 0x1D, 0x14, 0x13, 0xAE, 0xA9, 0xA0, 0xA7,
-0xB2, 0xB5, 0xBC, 0xBB, 0x96, 0x91, 0x98, 0x9F, 0x8A, 0x8D, 0x84, 0x83,
-0xDE, 0xD9, 0xD0, 0xD7, 0xC2, 0xC5, 0xCC, 0xCB, 0xE6, 0xE1, 0xE8, 0xEF,
-0xFA, 0xFD, 0xF4, 0xF3, 0x01
-},
-[AV_CRC_16_ANSI] = {
-0x, 0x0580, 0x0F80, 0x0A00, 0x1B80, 0x1E00, 0x1400, 0x1180,
-0x3380, 0x3600, 0x3C00, 0x3980, 0x2800, 0x2D80, 0x2780, 0x2200,
-0x6380, 0x6600, 0x6C00, 0x6980, 0x7800, 0x7D80, 0x7780, 0x7200,
-0x5000, 0x5580, 0x5F80, 0x5A00, 0x4B80, 0x4E00, 0x4400, 0x4180,
-0xC380, 0xC600, 0xCC00, 0xC980, 0xD800, 0xDD80, 0xD780, 0xD200,
-0xF000, 0xF580, 0xFF80, 0xFA00, 0xEB80, 0xEE00, 0xE400, 0xE180,
-0xA000, 0xA580, 0xAF80, 0xAA00, 0xBB80, 0xBE00, 0xB400, 0xB180,
-0x9380, 0x9600, 0x9C00, 0x9980, 0x8800, 0x8D80, 0x8780, 0x8200,
-0x8381, 0x8601, 0x8C01, 0x8981, 0x9801, 0x9D81, 0x9781, 0x9201,
-0xB001, 0xB581, 0xBF81, 0xBA01, 0xAB81, 0xAE01, 0xA401, 0xA181,
-0xE001, 0xE581, 0xEF81, 0xEA01, 0xFB81, 0xFE01, 0xF401, 0xF181,
-0xD381, 0xD601, 0xDC01, 0xD981, 0xC801, 0xCD81, 0xC781, 0xC201,
-0x4001, 0x4581, 0x4F81, 0x4A01, 0x5B81, 0x5E01, 0x5401, 0x5181,
-0x7381, 0x7601, 0x7C01, 0x7981, 0x6801, 0x6D81, 0x6781, 0x6201,
-0x2381, 0x2601, 0x2C01, 0x2981, 0x3801, 0x3D81, 0x3781, 0x3201,
-0x1001, 0x1581, 0x1F81, 0x1A01, 0x0B81, 0x0E01, 0x0401, 0x0181,
-0x0383, 0x0603, 0x0C03, 0x0983, 0x1803, 0x1D83, 0x1783, 0x1203,
-0x3003, 0x3583, 0x3F83, 0x3A03, 0x2B83, 0x2E03, 0x2403, 0x2183,
-0x6003, 0x6583, 0x6F83, 0x6A03, 0x7B83, 0x7E03, 0x7403, 0x7183,
-0x5383, 0x5603, 0x5C03, 0x5983, 0x4803, 0x4D83, 0x4783, 0x4203,
-0xC003, 0xC583, 0xCF83, 0xCA03, 0xDB83, 0xDE03, 0xD403, 0xD183,
-0xF383, 0xF603, 0xFC03, 0xF983, 0xE803, 0xED83, 0xE783, 0xE203,
-0xA383, 0xA603, 0xAC03, 0xA983, 0xB803, 0xBD83, 0xB783, 0xB203,
-0x9003, 0x9583, 0x9F83,

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

On 10/22/2017 7:15 AM, Paul B Mahol wrote:
> On 10/22/17, Michael Niedermayer  wrote:
>> On Sun, Oct 22, 2017 at 10:37:28AM +0200, Clement Boesch wrote:
>>> On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
 On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
>> This patchset removes the long-deprecated ffserver program and all
>> its privately exposed things from libavformat.
>>
>> Rostislav Pehlivanov (6):
>>   Remove the ffserver program
>>   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>>   libavformat: unexpose the ff_inet_aton function
>>   libavformat: remove the ff_rtp_get_local_rtcp_port function
>>   libavformat: unexpose private ff_ functions needed by ffserver
>>   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary
>> tag
>
> This set will be applied a month or so from now, when the unstable
> ABI
> period is over.
>
> If you can do in a month what was not done in a year plus, anyone is
> welcome to fix all ffserver issues or preferably replace it
> altogether
> with a new tool with a more user friendly syntax/interface.

 Can you list the technical problems that require dropping ffserver,
 so that someone interrested in fixing them can do so ?
>>>
>>> It's probably too late, one month is not enough. We already had that
>>> discussion:
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
>>>
>>
>>> The goal was ZERO internal API usage + at least partial FATE coverage. We
>>> gave it a year and nothing changed because no one cared.
>>
>> For reference, the votes text was: (uncut)
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203561.html
>> I propose, and put to the discussion, that the decision to drop
>> ffserver
>> is revoked, conditioned to the fixing of the technical issues that lead
>> to it.
>>
>> In other words, if the technical problems that require dropping
>> ffserver
>> are resolved at the time it is about to be dropped, then it must not be
>> and the patch is not applied.
>>
>> I support the decision. Pros:
>>
>> ffserver has users, if there are no reason to drop it, doing so is a
>> gratuitous annoyance to them.
>>
>> Apparently James Almer opposes the decision. Cons, if I understand
>> correctly:
>>
>> A decision was made, a project should stick to it stubbornly.
> 
> You and Carl should step out as leaders, or we will FORK!

Paul, please keep your "funny" remarks on IRC. Develop a sense of time
and place for jokes and sarcasm already.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264dec: Fix potential array overread

On Sun, Oct 22, 2017 at 07:28:31AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 21, 2017 at 7:41 PM, Michael Niedermayer  > wrote:
> 
> > add padding before scantable arrays
> >
> > See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264dec.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> > index 2106ba077e..de8b7c38b9 100644
> > --- a/libavcodec/h264dec.h
> > +++ b/libavcodec/h264dec.h
> > @@ -416,6 +416,7 @@ typedef struct H264Context {
> >  uint8_t (*mvd_table[2])[2];
> >  uint8_t *direct_table;
> >
> > +uint8_t scan_padding[16];
> >  uint8_t zigzag_scan[16];
> >  uint8_t zigzag_scan8x8[64];
> >  uint8_t zigzag_scan8x8_cavlc[64];
> > --
> > 2.14.2
> 
> 
> This is 16 bytes; isn't the space before it (the pointers) already
> providing that space? Or do you want it to be zero'ed so resulting indices
> can be used for writing into the coef array?

I wanted to ensure that the pointer cannot leak into the output.
Possibly giving an attacker information about the memory layout

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

[FFmpeg-devel] libavcodec/utvideodsp : add avx2 version

2017-10-22 Thread Martin Vignali

Hello,

In attach patch to add AVX2 version for the utvideodsp

Checkasm result (Kaby Lake, os 10.12)
restore_rgb_planes_c: 8371.0
restore_rgb_planes_sse2: 6583.7
restore_rgb_planes_avx2: 3596.5

restore_rgb_planes10_c: 16735.7
restore_rgb_planes10_sse2: 11478.5
restore_rgb_planes10_avx2: 7193.7


Pass fate test for me


0001-checkasm-add-utvideodsp-test :
I'm not entirely sure of mine, for this checkasm,

0002-libavcodec-x86-utvideodsp-make-macro-for-func
Code reorganization

0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp
AVX2 version

0004-libavcodec-x86-utvideodsp.asm-cosmetic
Cosmetic

Martin
Jokyo Images


0001-checkasm-add-utvideodsp-test.patch
Description: Binary data


0002-libavcodec-x86-utvideodsp-make-macro-for-func.patch
Description: Binary data


0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp.patch
Description: Binary data


0004-libavcodec-x86-utvideodsp.asm-cosmetic.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264dec: Fix potential array overread

Hi,

On Sat, Oct 21, 2017 at 7:41 PM, Michael Niedermayer  wrote:

> add padding before scantable arrays
>
> See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264dec.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index 2106ba077e..de8b7c38b9 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -416,6 +416,7 @@ typedef struct H264Context {
>  uint8_t (*mvd_table[2])[2];
>  uint8_t *direct_table;
>
> +uint8_t scan_padding[16];
>  uint8_t zigzag_scan[16];
>  uint8_t zigzag_scan8x8[64];
>  uint8_t zigzag_scan8x8_cavlc[64];
> --
> 2.14.2


This is 16 bytes; isn't the space before it (the pointers) already
providing that space? Or do you want it to be zero'ed so resulting indices
can be used for writing into the coef array?

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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

Hi,

On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer  wrote:

> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
>  > > wrote:
> >
> > > This is different from FF_API_VISMV which is supported through
> codecview.
> > >
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/version.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > > index 8584bb7006..25696690d7 100644
> > > --- a/libavcodec/version.h
> > > +++ b/libavcodec/version.h
> > > @@ -79,7 +79,7 @@
> > >  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
> > >  #endif
> > >  #ifndef FF_API_DEBUG_MV
> > > -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
> > > +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
> > >  #endif
> > >
> >
> > Can you give an explanation for why this should be delayed? (It's missing
> > in the commit message, and this is hard to evaluate without a
> > justification/explanation.)
>
> It was not agreed on ffmpeg-devel to remove this feature.
>
> Its used for example by me occasionally to analyze videos in bug
> reports for debuging them.
>
> There is no replacement or alternative iam aware of
>

The replacement will never be written if:
a) nobody cares; AND
b) we keep delaying the removal

I'm considering veto'ing this patch.

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

Re: [FFmpeg-devel] order T-shirts

2017-10-22 Thread Thilo Borgmann

Am 22.10.17 um 09:55 schrieb Liu Steven:
> 
>> 在 2017年10月22日，上午2:42，Lou Logan  写道：
>>
>> I was thinking of black shirt, green logo, white "FFmpeg" lettering.
> I like this thinking too :D

I must say that the black/white style comes closer to what our website has 
color-wise...

So what do others think about colors? Shall I make a 3-color-sample first? We 
might do more than one version.
They open again Tuesday...

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

On Sun, Oct 22, 2017 at 12:15:25PM +0200, Paul B Mahol wrote:
> On 10/22/17, Michael Niedermayer  wrote:
> > On Sun, Oct 22, 2017 at 10:37:28AM +0200, Clement Boesch wrote:
> >> On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
> >> > On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> >> > > On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> >> > > > This patchset removes the long-deprecated ffserver program and all
> >> > > > its privately exposed things from libavformat.
> >> > > >
> >> > > > Rostislav Pehlivanov (6):
> >> > > >   Remove the ffserver program
> >> > > >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
> >> > > >   libavformat: unexpose the ff_inet_aton function
> >> > > >   libavformat: remove the ff_rtp_get_local_rtcp_port function
> >> > > >   libavformat: unexpose private ff_ functions needed by ffserver
> >> > > >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary
> >> > > > tag
> >> > >
> >> > > This set will be applied a month or so from now, when the unstable
> >> > > ABI
> >> > > period is over.
> >> > >
> >> > > If you can do in a month what was not done in a year plus, anyone is
> >> > > welcome to fix all ffserver issues or preferably replace it
> >> > > altogether
> >> > > with a new tool with a more user friendly syntax/interface.
> >> >
> >> > Can you list the technical problems that require dropping ffserver,
> >> > so that someone interrested in fixing them can do so ?
> >>
> >> It's probably too late, one month is not enough. We already had that
> >> discussion:
> >> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
> >>
> >
> >> The goal was ZERO internal API usage + at least partial FATE coverage. We
> >> gave it a year and nothing changed because no one cared.
> >
> > For reference, the votes text was: (uncut)
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203561.html
> > I propose, and put to the discussion, that the decision to drop
> > ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> >
> > In other words, if the technical problems that require dropping
> > ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
> >
> > I support the decision. Pros:
> >
> > ffserver has users, if there are no reason to drop it, doing so is a
> > gratuitous annoyance to them.
> >
> > Apparently James Almer opposes the decision. Cons, if I understand
> > correctly:
> >
> > A decision was made, a project should stick to it stubbornly.
> 
> You and Carl should step out as leaders, or we will FORK!

calm down please, the only thing ive said in the whole thread was
asking for a list of "technical problems that require dropping ffserver"
and for reference posting the uncut text from the last years vote.
Which used exactly that phrase.
Which was not written by either me nor carl.

I had not intended to offend anyone by posting this.

I will also post a patch that hopefully fixes partial fate tests for
ffserver as that was one of several things suggested.
Beyond that i have no plans ATM about ffserver.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] GSoC 2017 mentor summit review

2017-10-22 Thread Thilo Borgmann

Hi,

Carl Eugen and me went to the mentor summit this year. We've met a lot of known
and some yet unknown users and had a lot of interesting talks with them, as well
as a lot conversations with representatives of other projects about OSS
development in general and GSoC matters in particular.

We had an audio & video developer meetup session with people from VideoLan,
Kodi,
Mixxx, MuseScore (IIRC). It was not very technical, mostly a general discussion
about
how development and cooperation could work.

There was also a very interesting session about different licenses used in OSS
given by a Google open-source lawyer that really added to what I had known
about this topic.
I still try to get a copy of these slides, however a very good resource was
referenced [1].

Two guys of the Apertus project [2] presented a prototype of their open-source
cinematic camera, completely build by open hardware - well except for some
still closed optional modules like a flash drive.
Their camera looks quite impressive and they looking into integrating FFmpeg in
their camera.
We are still missing handling of their 48bit Bayer patterns, though. Any
volunteers?

Kostya Serebryany talked about Google's OSS-Fuzz project we already benefit a
lot from. For everyone not aware, FFmpeg is leading the charts of having
revealed more than 2000 issues during their 24/7 fuzzing. A little
live demo of their fuzzer was about identifying the well-known heartbleed
vulnerability within seconds in an older SSH implementation. This has actually
become
part of their fuzzer's regression tests.
He took time to explain why timeouts and OOM are important,
not only because they may hide other issues and make the
fuzzer's work more difficult.
He additionally commented on why fixing undefined behaviour
is important (can trigger compiler non-bugs and leads to different
behaviour on different hardware) and mentioned current sparc
hardware that allows fast address sanitation (may be too
expensive for a project like FFmpeg...)

Next to that I had a chat with Stephanie Taylor and gave some feedback about the
issues we had this year during student selection (like I promised to do in a
mail from this point in time). Good news that should have a positive effect for
us being able to better judge a student's actual interest in the project they
are applying at, is that Google will have the number of applications a student
can submit way more limited than before - the maximum number of applications
will be set to three. (Google already states this in their FAQ today).

Although I could not attend that particular session in person, there have been
taken
detailed notes during it about how to keep GSoC students sticking with their
project after the program ends [3]. I find some things in it quite interesting.

So let's prepare for GSoC 2018! :)

-Thilo

p.s. I don't know if the guys caring about our social media representations
already wrote something. I'd appreciate if you would also write some lines
about that. Thanks!

[1] https://opensource.org/licenses/

[2] https://www.apertus.org/

[3]
https://docs.google.com/document/d/191ItHQfO92MxoS-IQ2dmlEQ3TcPqXGkFgzdyFXEFy_c/edit#heading=h.srrvw9px1v5x
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

2017-10-22 12:40 GMT+02:00 Clément Bœsch :

> Removal was announced, people were aware, we got discussions,
> but no one cared enough to do something about it.

Wasn't the (only) question what should be done?

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

On Sun, Oct 22, 2017 at 10:51:38AM +0200, Marton Balint wrote:
> 
> On Sun, 22 Oct 2017, Clément Bœsch wrote:
> 
> > On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
> > > On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> > > > On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> > > > > This patchset removes the long-deprecated ffserver program and all
> > > > > its privately exposed things from libavformat.
> > > > > 
> > > > > Rostislav Pehlivanov (6):
> > > > >   Remove the ffserver program
> > > > >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
> > > > >   libavformat: unexpose the ff_inet_aton function
> > > > >   libavformat: remove the ff_rtp_get_local_rtcp_port function
> > > > >   libavformat: unexpose private ff_ functions needed by ffserver
> > > > >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary 
> > > > > tag
> > > > 
> > > > This set will be applied a month or so from now, when the unstable ABI
> > > > period is over.
> > > > 
> > > > If you can do in a month what was not done in a year plus, anyone is
> > > > welcome to fix all ffserver issues or preferably replace it altogether
> > > > with a new tool with a more user friendly syntax/interface.
> > > 
> > > Can you list the technical problems that require dropping ffserver,
> > > so that someone interrested in fixing them can do so ?
> > 
> > It's probably too late, one month is not enough. We already had that
> > discussion:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
> > 
> > The goal was ZERO internal API usage + at least partial FATE coverage. We
> > gave it a year and nothing changed because no one cared.
> 
> It is natural that people only care if it gets removed otherwise.
> 

July 10th, 2016, ffserver program being dropped

After thorough deliberation, we're announcing that we're about to drop
the ffserver program from the project starting with the next release.
ffserver has been a problematic program to maintain due to its use of
internal APIs, which complicated the recent cleanups to the
libavformat library, and block further cleanups and improvements which
are desired by API users and will be easier to maintain. Furthermore
the program has been hard for users to deploy and run due to
reliability issues, lack of knowledgable people to help and confusing
configuration file syntax. Current users and members of the community
are invited to write a replacement program to fill the same niche that
ffserver did using the new APIs and to contact us so we may point
users to test and contribute to its development. 

source: ffmpeg.org

Removal was announced, people were aware, we got discussions, but no one
cared enough to do something about it.

-- 
Clément B.

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

2017-10-22 Thread Paul B Mahol

On 10/22/17, Michael Niedermayer  wrote:
> On Sun, Oct 22, 2017 at 10:37:28AM +0200, Clement Boesch wrote:
>> On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
>> > On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
>> > > On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
>> > > > This patchset removes the long-deprecated ffserver program and all
>> > > > its privately exposed things from libavformat.
>> > > >
>> > > > Rostislav Pehlivanov (6):
>> > > >   Remove the ffserver program
>> > > >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>> > > >   libavformat: unexpose the ff_inet_aton function
>> > > >   libavformat: remove the ff_rtp_get_local_rtcp_port function
>> > > >   libavformat: unexpose private ff_ functions needed by ffserver
>> > > >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary
>> > > > tag
>> > >
>> > > This set will be applied a month or so from now, when the unstable
>> > > ABI
>> > > period is over.
>> > >
>> > > If you can do in a month what was not done in a year plus, anyone is
>> > > welcome to fix all ffserver issues or preferably replace it
>> > > altogether
>> > > with a new tool with a more user friendly syntax/interface.
>> >
>> > Can you list the technical problems that require dropping ffserver,
>> > so that someone interrested in fixing them can do so ?
>>
>> It's probably too late, one month is not enough. We already had that
>> discussion:
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
>>
>
>> The goal was ZERO internal API usage + at least partial FATE coverage. We
>> gave it a year and nothing changed because no one cared.
>
> For reference, the votes text was: (uncut)
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203561.html
> I propose, and put to the discussion, that the decision to drop
> ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
>
> In other words, if the technical problems that require dropping
> ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
>
> I support the decision. Pros:
>
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
>
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
>
> A decision was made, a project should stick to it stubbornly.

You and Carl should step out as leaders, or we will FORK!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

On Sun, Oct 22, 2017 at 10:37:28AM +0200, Clément Bœsch wrote:
> On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
> > On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> > > On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> > > > This patchset removes the long-deprecated ffserver program and all
> > > > its privately exposed things from libavformat.
> > > > 
> > > > Rostislav Pehlivanov (6):
> > > >   Remove the ffserver program
> > > >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
> > > >   libavformat: unexpose the ff_inet_aton function
> > > >   libavformat: remove the ff_rtp_get_local_rtcp_port function
> > > >   libavformat: unexpose private ff_ functions needed by ffserver
> > > >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
> > > 
> > > This set will be applied a month or so from now, when the unstable ABI
> > > period is over.
> > > 
> > > If you can do in a month what was not done in a year plus, anyone is
> > > welcome to fix all ffserver issues or preferably replace it altogether
> > > with a new tool with a more user friendly syntax/interface.
> > 
> > Can you list the technical problems that require dropping ffserver,
> > so that someone interrested in fixing them can do so ?
> 
> It's probably too late, one month is not enough. We already had that
> discussion:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
> 

> The goal was ZERO internal API usage + at least partial FATE coverage. We
> gave it a year and nothing changed because no one cared.

For reference, the votes text was: (uncut)
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203561.html
I propose, and put to the discussion, that the decision to drop ffserver
is revoked, conditioned to the fixing of the technical issues that lead
to it.

In other words, if the technical problems that require dropping ffserver
are resolved at the time it is about to be dropped, then it must not be
and the patch is not applied.

I support the decision. Pros:

ffserver has users, if there are no reason to drop it, doing so is a
gratuitous annoyance to them.

Apparently James Almer opposes the decision. Cons, if I understand
correctly:

A decision was made, a project should stick to it stubbornly.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] swscale: Reduce verbosity of misalignment reporting

2017-10-22 Thread Henrik Gramner

It's a bit overzealous to complain about misalignment with AV_LOG_WARNING,
especially since memory bandwidth is much more likely to be the bottleneck
compared to data alignment which the user may not even have control over.
---
 libswscale/swscale.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 7f3e22355f..4eca79edc2 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -307,26 +307,14 @@ static int swscale(SwsContext *c, const uint8_t *src[],
 DEBUG_BUFFERS("vLumFilterSize: %d vChrFilterSize: %d\n",
   vLumFilterSize, vChrFilterSize);
 
-if (dstStride[0]&15 || dstStride[1]&15 ||
-dstStride[2]&15 || dstStride[3]&15) {
-static int warnedAlready = 0; // FIXME maybe move this into the context
-if (flags & SWS_PRINT_INFO && !warnedAlready) {
-av_log(c, AV_LOG_WARNING,
-   "Warning: dstStride is not aligned!\n"
-   " ->cannot do aligned memory accesses anymore\n");
-warnedAlready = 1;
-}
-}
-
 if (   (uintptr_t)dst[0]&15 || (uintptr_t)dst[1]&15 || (uintptr_t)dst[2]&15
 || (uintptr_t)src[0]&15 || (uintptr_t)src[1]&15 || (uintptr_t)src[2]&15
 || dstStride[0]&15 || dstStride[1]&15 || dstStride[2]&15 || 
dstStride[3]&15
 || srcStride[0]&15 || srcStride[1]&15 || srcStride[2]&15 || 
srcStride[3]&15
 ) {
-static int warnedAlready=0;
-int cpu_flags = av_get_cpu_flags();
-if (HAVE_MMXEXT && (cpu_flags & AV_CPU_FLAG_SSE2) && !warnedAlready){
-av_log(c, AV_LOG_WARNING, "Warning: data is not aligned! This can 
lead to a speed loss\n");
+static int warnedAlready=0; // FIXME maybe move this into the context
+if (flags & SWS_PRINT_INFO && !warnedAlready) {
+av_log(c, AV_LOG_VERBOSE, "Data is misaligned, this may reduce 
performance.\n");
 warnedAlready=1;
 }
 }
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

2017-10-22 Thread Marton Balint



On Sun, 22 Oct 2017, Clément Bœsch wrote:


On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:

On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:

On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:

This patchset removes the long-deprecated ffserver program and all
its privately exposed things from libavformat.

Rostislav Pehlivanov (6):
  Remove the ffserver program
  libavformat: remove the ffmenc and ffmdec muxer and demuxers
  libavformat: unexpose the ff_inet_aton function
  libavformat: remove the ff_rtp_get_local_rtcp_port function
  libavformat: unexpose private ff_ functions needed by ffserver
  libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag


This set will be applied a month or so from now, when the unstable ABI
period is over.

If you can do in a month what was not done in a year plus, anyone is
welcome to fix all ffserver issues or preferably replace it altogether
with a new tool with a more user friendly syntax/interface.


Can you list the technical problems that require dropping ffserver,
so that someone interrested in fixing them can do so ?


It's probably too late, one month is not enough. We already had that
discussion:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html

The goal was ZERO internal API usage + at least partial FATE coverage. We
gave it a year and nothing changed because no one cared.


It is natural that people only care if it gets removed otherwise.

A list is important so anybody interested can estimate the amount of work 
needed.


What abouth the ffmenc/ffmdec? That needs to go as well? Or if internal 
api usage is fixed, and some fate coverate is added, ffmenc and ffmdec can 
stay?


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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> > On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> > > This patchset removes the long-deprecated ffserver program and all
> > > its privately exposed things from libavformat.
> > > 
> > > Rostislav Pehlivanov (6):
> > >   Remove the ffserver program
> > >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
> > >   libavformat: unexpose the ff_inet_aton function
> > >   libavformat: remove the ff_rtp_get_local_rtcp_port function
> > >   libavformat: unexpose private ff_ functions needed by ffserver
> > >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
> > 
> > This set will be applied a month or so from now, when the unstable ABI
> > period is over.
> > 
> > If you can do in a month what was not done in a year plus, anyone is
> > welcome to fix all ffserver issues or preferably replace it altogether
> > with a new tool with a more user friendly syntax/interface.
> 
> Can you list the technical problems that require dropping ffserver,
> so that someone interrested in fixing them can do so ?

It's probably too late, one month is not enough. We already had that
discussion:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html

The goal was ZERO internal API usage + at least partial FATE coverage. We
gave it a year and nothing changed because no one cared.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV