[FFmpeg-devel] [PATCH] avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header()

[James Almer]

This prevents ABI issues with GetBitContext.

Signed-off-by: James Almer 
---
 libavcodec/dca.c| 15 ++-
 libavcodec/dca.h|  7 +--
 libavcodec/dca_core.c   |  2 +-
 libavcodec/dca_parser.c |  4 +---
 libavformat/dtsdec.c|  4 +---
 5 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/libavcodec/dca.c b/libavcodec/dca.c
index 39f8f3d81c..3f2ed67013 100644
--- a/libavcodec/dca.c
+++ b/libavcodec/dca.c
@@ -88,7 +88,7 @@ int avpriv_dca_convert_bitstream(const uint8_t *src, int 
src_size, uint8_t *dst,
 }
 }
 
-int avpriv_dca_parse_core_frame_header(GetBitContext *gb, DCACoreFrameHeader 
*h)
+int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, GetBitContext *gb)
 {
 if (get_bits_long(gb, 32) != DCA_SYNCWORD_CORE_BE)
 return DCA_PARSE_ERROR_SYNC_WORD;
@@ -145,3 +145,16 @@ int avpriv_dca_parse_core_frame_header(GetBitContext *gb, 
DCACoreFrameHeader *h)
 h->dn_code = get_bits(gb, 4);
 return 0;
 }
+
+int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, uint8_t *buf, 
int size)
+{
+GetBitContext gb;
+
+if (size < DCA_CORE_FRAME_HEADER_SIZE)
+return DCA_PARSE_ERROR_INVALIDDATA;
+
+if (init_get_bits8(, buf, size) < 0)
+return DCA_PARSE_ERROR_INVALIDDATA;
+
+return ff_dca_parse_core_frame_header(h, );
+}
diff --git a/libavcodec/dca.h b/libavcodec/dca.h
index cf6204e554..172c965b3b 100644
--- a/libavcodec/dca.h
+++ b/libavcodec/dca.h
@@ -45,7 +45,8 @@ enum DCAParseError {
 DCA_PARSE_ERROR_SAMPLE_RATE = -6,
 DCA_PARSE_ERROR_RESERVED_BIT= -7,
 DCA_PARSE_ERROR_LFE_FLAG= -8,
-DCA_PARSE_ERROR_PCM_RES = -9
+DCA_PARSE_ERROR_PCM_RES = -9,
+DCA_PARSE_ERROR_INVALIDDATA = -10,
 };
 
 typedef struct DCACoreFrameHeader {
@@ -212,6 +213,8 @@ int avpriv_dca_convert_bitstream(const uint8_t *src, int 
src_size, uint8_t *dst,
  * Parse and validate core frame header
  * @return 0 on success, negative DCA_PARSE_ERROR_ code on failure
  */
-int avpriv_dca_parse_core_frame_header(GetBitContext *gb, DCACoreFrameHeader 
*h);
+int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, uint8_t *buf, 
int size);
+
+int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, GetBitContext *gb);
 
 #endif /* AVCODEC_DCA_H */
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 3add9f812b..6cb1f30a3c 100644
--- a/libavcodec/dca_core.c
+++ b/libavcodec/dca_core.c
@@ -82,7 +82,7 @@ static void get_array(GetBitContext *s, int32_t *array, int 
size, int n)
 static int parse_frame_header(DCACoreDecoder *s)
 {
 DCACoreFrameHeader h = { 0 };
-int err = avpriv_dca_parse_core_frame_header(>gb, );
+int err = ff_dca_parse_core_frame_header(, >gb);
 
 if (err < 0) {
 switch (err) {
diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
index 7e99b16bf0..11ddb8f188 100644
--- a/libavcodec/dca_parser.c
+++ b/libavcodec/dca_parser.c
@@ -263,9 +263,7 @@ static int dca_parse_params(DCAParseContext *pc1, const 
uint8_t *buf,
 if ((ret = avpriv_dca_convert_bitstream(buf, DCA_CORE_FRAME_HEADER_SIZE,
 hdr, DCA_CORE_FRAME_HEADER_SIZE)) 
< 0)
 return ret;
-if ((ret = init_get_bits8(, hdr, ret)) < 0)
-return ret;
-if (avpriv_dca_parse_core_frame_header(, ) < 0)
+if (avpriv_dca_parse_core_frame_header(, hdr, ret) < 0)
 return AVERROR_INVALIDDATA;
 
 *duration = h.npcmblocks * DCA_PCMBLOCK_SAMPLES;
diff --git a/libavformat/dtsdec.c b/libavformat/dtsdec.c
index 6e0048f9bc..a3e52cd596 100644
--- a/libavformat/dtsdec.c
+++ b/libavformat/dtsdec.c
@@ -101,9 +101,7 @@ static int dts_probe(AVProbeData *p)
 if ((ret = avpriv_dca_convert_bitstream(buf - 2, 
DCA_CORE_FRAME_HEADER_SIZE,
 hdr, 
DCA_CORE_FRAME_HEADER_SIZE)) < 0)
 continue;
-if (init_get_bits8(, hdr, ret) < 0)
-continue;
-if (avpriv_dca_parse_core_frame_header(, ) < 0)
+if (avpriv_dca_parse_core_frame_header(, hdr, ret) < 0)
 continue;
 
 marker += 4 * h.sr_code;
-- 
2.13.3

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

[FFmpeg-devel] tsan warning about a data race in libavcodec/h264_direct.c

[Wan-Teh Chang]

Hi,

I'd like to report a tsan warning about a data race in libavcodec/h264_direct.c.

1. Steps to reproduce:

./configure --samples=~/fate-suite/ --toolchain=clang-tsan --disable-stripping

make fate-h264 THREADS=4

2. Here is an excerpt of the tsan warning in
tests/data/fate/h264-conformance-frext-hpcafl_bcrm_c.err:

WARNING: ThreadSanitizer: data race (pid=116081)
  Read of size 4 at 0x7b720118 by thread T3 (mutexes: write M2239):
#0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
(ffmpeg+0x1159c60)
#1 ff_h264_pred_direct_motion ffmpeg/libavcodec/h264_direct.c:727
(ffmpeg+0x1159c60)
#2 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2118:17
(ffmpeg+0x1471f03)
#3 decode_slice ffmpeg/libavcodec/h264_slice.c:2569:19 (ffmpeg+0x11930ba)
#4 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#5 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#6 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#7 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)

  Previous write of size 4 at 0x7b720118 by thread T1 (mutexes:
write M2234):
#0 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2386:31
(ffmpeg+0x1475e0a)
#1 decode_slice ffmpeg/libavcodec/h264_slice.c:2569:19 (ffmpeg+0x11930ba)
#2 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#3 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#4 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#5 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)

3. The relevant source code is:

libavcodec/h264_direct.c:

487 static void pred_temp_direct_motion(const H264Context *const h,
H264SliceContext *sl,
488 int *mb_type)
489 {
490 int b8_stride = 2;
491 int b4_stride = h->b_stride;
492 int mb_xy = sl->mb_xy, mb_y = sl->mb_y;
...
502 await_reference_mb_row(h, >ref_list[1][0],
503sl->mb_y + !!IS_INTERLACED(*mb_type));
504
505 if (IS_INTERLACED(sl->ref_list[1][0].parent->mb_type[mb_xy]))
{ // AFL/AFR/FR/FL -> AFL/FL

Note: tsan warns about the read of mb_type[mb_xy], not the read of
sl->ref_list[1][0].parent.

libavcodec/h264_slice.c:

1914 int ff_h264_decode_mb_cabac(const H264Context *h, H264SliceContext *sl)
1915 {
...
2386 h->cur_pic.mb_type[mb_xy] = mb_type;

4. I've investigated this tsan warning for several hours in my spare
time, but I can't figure out how to fix it. I hope someone familiar
with the h264 decoder will see what's wrong or suggest fixes for me to
try.

Here are two facts that may be helpful.

- This tsan warning does not occur when I run "make fate-h264" with
THREADS=2. It starts to occur with THREADS=3.

- If I annotate libavcodec/h264_direct.c so that tsan ignores the read
of sl->ref_list[1][0].parent->mb_type[mb_xy] at line 505, then "make
fate-h264 THREADS=4" runs to completion with no tsan warning (assuming
the fix in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213777.html
is applied). So this seems to be the last tsan warning in fate-h264.

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: don't sync default_ref[] between threads.

[Wan-Teh Chang]

I researched the history of the line in h264_slice.c that this patch deleted.

That line was implicitly added in commit
4da2ac5c7a491b20be62ad19d77526e62aa57c69:

http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=patch;h=4da2ac5c7a491b20be62ad19d77526e62aa57c69

Although commit 4da2ac5c7a491b20be62ad19d77526e62aa57c69 didn't modify
h264_slice.c, the copy_fields macro call in
ff_h264_update_thread_context() would copy the new default_ref[] field
of H264Context. The copying of default_ref[] was made explicit in
commit 98456d4d69e0fdcc328bb9e684ae776f5bc824e1, which replaced the
copy_fields macro with field-by-field copies.

http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=98456d4d69e0fdcc328bb9e684ae776f5bc824e1

Commit 4da2ac5c7a491b20be62ad19d77526e62aa57c69 makes it clear that
the default_ref[] field of H264Context is supposed to be initialized
(to values from the associated H264SliceContext) in
h264_initialise_ref_list(), so it should not be propagated from one
decoding thread to the next.

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

Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example

[Jun Zhao]

On 2017/7/19 7:30, Mark Thompson wrote:
> On 17/07/17 03:51, Jun Zhao wrote> On 2017/7/11 15:58, wm4 wrote:
>>> On Tue, 11 Jul 2017 12:06:10 +0800
>>> Jun Zhao  wrote:
>>>
 From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
 From: Jun Zhao 
 Date: Tue, 21 Mar 2017 11:04:41 +0800
 Subject: [V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example.

 Add a VA-API hwaccel decoding example.

 Signed-off-by: Liu, Kaixuan 
 Signed-off-by: Jun Zhao 
 ---
  doc/examples/vaapi_dec.c | 266 
 +++
  1 file changed, 266 insertions(+)
  create mode 100644 doc/examples/vaapi_dec.c

 diff --git a/doc/examples/vaapi_dec.c b/doc/examples/vaapi_dec.c
 new file mode 100644
 index 00..01320a3b71
 --- /dev/null
 +++ b/doc/examples/vaapi_dec.c
 @@ -0,0 +1,266 @@
 +/*
 + * Video Acceleration API (video decoding) decode sample
 + *
 + * This file is part of FFmpeg.
 + *
 + * FFmpeg is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU Lesser General Public
 + * License as published by the Free Software Foundation; either
 + * version 2.1 of the License, or (at your option) any later version.
 + *
 + * FFmpeg is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * Lesser General Public License for more details.
 + *
 + * You should have received a copy of the GNU Lesser General Public
 + * License along with FFmpeg; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
 02110-1301 USA
 + */
 +
 +/**
 + * @file
 + * Intel VAAPI-accelerated decoding example.
 + *
 + * @example vaapi_dec.c
 + * This example shows how to do VAAPI-accelerated decoding with output
 + * frames from the VAAPI video surfaces.
 + */
 +
 +#include 
 +#include 
 +#include 
> 
> This file is deprecated, and contains nothing useful anyway.
> 
Will remove.
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
> 
> Shouldn't need any of the API-specific hwcontext includes, just the generic 
> one.
> 
Same as above.
 +#include 
 +
 +static AVBufferRef *hw_device_ctx = NULL;
 +FILE *output_file = NULL;
 +
 +int decoder_init_vaapi(AVCodecContext *ctx)
 +{
 +int err = 0;
 +const char *dev_name = "/dev/dri/renderD128";
 +
 +if ((err = av_hwdevice_ctx_create(_device_ctx, 
 AV_HWDEVICE_TYPE_VAAPI,
 +  dev_name, NULL, 0)) < 0) {
>>>
>>> The implementation already uses your dev_name as default, so you should
>>> be able to drop that, and pass NULL to it.
>>>
>>
>> Yes, will remove the dev_name.
>>
 +fprintf(stderr, "Failed to create a VAAPI device.\n");
 +return err;
 +}
 +ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
 +
 +return err;
 +}
 +
 +static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
 +   const enum AVPixelFormat 
 *pix_fmts)
 +{
 +const enum AVPixelFormat *p;
 +
 +for (p = pix_fmts; *p != -1; p++) {
 +if (*p == AV_PIX_FMT_VAAPI)
 +return *p;
 +}
 +
 +return AV_PIX_FMT_NONE;
 +}
 +
 +int retrieve_data(AVFrame *input)
 +{
 +AVFrame *output = NULL;
 +int err;
 +av_assert0(input->format == AV_PIX_FMT_VAAPI);
 +
 +if (!(output = av_frame_alloc()))
 +return AVERROR(ENOMEM);
 +/* default output nv12 */
 +output->format = AV_PIX_FMT_NV12;
>>>
>>> You could use av_hwframe_transfer_get_formats() instead of hardcoding
>>> it. Might be better if the input is 10 bit, not sure. (Just a
>>> suggestion, up to you.)
>> Ok, it's will show the HW surface/ SW pixel format mapping if we 
>> use av_hwframe_transfer_get_formats() instead of hardcoding.
>>
>>>
 +if ((err = av_hwframe_transfer_data(output, input, 0)) < 0) {
 +fprintf(stderr, "Failed to transfer data to output frame: %d.\n", 
 err);
 +goto fail;
 +}
 +
 +if ((err = av_frame_copy_props(output, input)) < 0) {
 +av_frame_unref(output);
 +goto fail;
 +}
 +
 +av_frame_unref(input);
 +av_frame_move_ref(input, output);
 +av_frame_free();
 +return 0;
 +
 +fail:
 +av_frame_free();
 +return err;
 +}
 +
 +int write_frame(AVFrame *frame)
 +{
 +int idx, size;
 +

[FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Check dimensions which are closer to what is allocated in alloc_sequence_buffers()

[Michael Niedermayer]

Fixes OOM
Fixes: 2674/clusterfuzz-testcase-minimized-4999700518273024

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index c031b40b5e..71d0ff41b2 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -2090,7 +2090,10 @@ static int dirac_decode_data_unit(AVCodecContext *avctx, 
const uint8_t *buf, int
 return ret;
 }
 
-ret = ff_set_dimensions(avctx, dsh->width, dsh->height);
+if (CALC_PADDING((int64_t)dsh->width, MAX_DWT_LEVELS) * 
CALC_PADDING((int64_t)dsh->height, MAX_DWT_LEVELS) > avctx->max_pixels)
+ret = AVERROR(ERANGE);
+if (ret >= 0)
+ret = ff_set_dimensions(avctx, dsh->width, dsh->height);
 if (ret < 0) {
 av_freep();
 return ret;
-- 
2.13.0

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

[FFmpeg-devel] [PATCH 2/2] avcodec/dirac_vlc: Fix undefined shift

[Michael Niedermayer]

Fixes: runtime error: shift exponent 64 is too large for 64-bit type 'residual' 
(aka 'unsigned long')
Fixes: 2674/clusterfuzz-testcase-minimized-4999700518273024

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

diff --git a/libavcodec/dirac_vlc.c b/libavcodec/dirac_vlc.c
index 336d22a182..773f720858 100644
--- a/libavcodec/dirac_vlc.c
+++ b/libavcodec/dirac_vlc.c
@@ -216,9 +216,14 @@ static void generate_offset_lut(DiracGolombLUT *lut, int 
off)
 INIT_RESIDUE(res);
 SET_RESIDUE(res, idx, LUT_BITS);
 
-l->preamble  = CONVERT_TO_RESIDUE(res >> (RSIZE_BITS - off), off);
 l->preamble_bits = off;
-l->sign = ((l->preamble >> (RSIZE_BITS - l->preamble_bits)) & 1) ? -1 
: +1;
+if (off) {
+l->preamble  = CONVERT_TO_RESIDUE(res >> (RSIZE_BITS - off), off);
+l->sign  = ((l->preamble >> (RSIZE_BITS - l->preamble_bits)) & 
1) ? -1 : +1;
+} else {
+l->preamble  = 0;
+l->sign = 1;
+}
 
 search_for_golomb(l, res << off, LUT_BITS - off);
 }
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: move some enumeration typedefs into headers

[James Almer]

On 7/10/2017 11:11 AM, foo86 wrote:
> These values will be used by the parser. Prefix them with DCA_
> appropriately.
> ---
>  libavcodec/dca_core.c | 68 
> +++
>  libavcodec/dca_core.h | 28 +
>  libavcodec/dca_lbr.c  |  9 ++-
>  libavcodec/dca_lbr.h  |  5 
>  4 files changed, 55 insertions(+), 55 deletions(-)

Patchset pushed.

PS: You should add yourself to the MAINTAINERS file and send your public
ssh key to Michael Nyedermayer so you can push your patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] tsan warning about data race in h264 decoder

[Wan-Teh Chang]

Hi Ronald,

On Tue, Jul 18, 2017 at 11:41 AM, Ronald S. Bultje  wrote:
>
> Reminds me a little of
> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e72690b18da064f6c0f04f09ccde72b6636e3159.
> From a quick look, it appears that default_ref[] is unconditionally
> initialized in initialise_ref_list() (called from ff_h264_build_ref_list(),
> called from h264_slice_init()), so I think your suggested patch is correct.

Thanks a lot for taking a look and pointing me at the relevant code. I
reviewed those functions, and I think you are right.

I am curious: why do we need to sync short_ref[], long_ref[],
short_ref_count, and long_ref_count between threads?

> Can you send it as a git-formatted patch?

Done. Please see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213777.html.

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

[FFmpeg-devel] [PATCH] avcodec/h264_slice: don't sync default_ref[] between threads.

[Wan-Teh Chang]

default_ref[] is unconditionally initialized in h264_initialise_ref_list()
(called from ff_h264_build_ref_list(), called from h264_slice_init()).

This fixes the following tsan warning when running fate-h264:

WARNING: ThreadSanitizer: data race (pid=31070)
  Write of size 8 at 0x7bbc82a8 by thread T1 (mutexes: write M1628):
#0 memcpy 
/work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 h264_initialise_ref_list ffmpeg/libavcodec/h264_refs.c:214:29 
(ffmpeg+0x1186b3f)
#2 ff_h264_build_ref_list ffmpeg/libavcodec/h264_refs.c:306 
(ffmpeg+0x1186b3f)
#3 h264_slice_init ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
[..]
  Previous read of size 8 at 0x7bbc82a8 by main thread (mutexes:
write M1630):
#0 memcpy 
/work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5 
(ffmpeg+0x118b7dc)

Signed-off-by: Wan-Teh Chang 
---
 libavcodec/h264_slice.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6deb08fe6d..2fb89b189d 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -408,7 +408,6 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
 
 memcpy(>poc,>poc,sizeof(h->poc));
 
-memcpy(h->default_ref, h1->default_ref, sizeof(h->default_ref));
 memcpy(h->short_ref,   h1->short_ref,   sizeof(h->short_ref));
 memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
 memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));
-- 
2.13.2.932.g7449e964c-goog

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

Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example

[Mark Thompson]

On 17/07/17 03:51, Jun Zhao wrote> On 2017/7/11 15:58, wm4 wrote:
>> On Tue, 11 Jul 2017 12:06:10 +0800
>> Jun Zhao  wrote:
>>
>>> From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Tue, 21 Mar 2017 11:04:41 +0800
>>> Subject: [V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example.
>>>
>>> Add a VA-API hwaccel decoding example.
>>>
>>> Signed-off-by: Liu, Kaixuan 
>>> Signed-off-by: Jun Zhao 
>>> ---
>>>  doc/examples/vaapi_dec.c | 266 
>>> +++
>>>  1 file changed, 266 insertions(+)
>>>  create mode 100644 doc/examples/vaapi_dec.c
>>>
>>> diff --git a/doc/examples/vaapi_dec.c b/doc/examples/vaapi_dec.c
>>> new file mode 100644
>>> index 00..01320a3b71
>>> --- /dev/null
>>> +++ b/doc/examples/vaapi_dec.c
>>> @@ -0,0 +1,266 @@
>>> +/*
>>> + * Video Acceleration API (video decoding) decode sample
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>>> 02110-1301 USA
>>> + */
>>> +
>>> +/**
>>> + * @file
>>> + * Intel VAAPI-accelerated decoding example.
>>> + *
>>> + * @example vaapi_dec.c
>>> + * This example shows how to do VAAPI-accelerated decoding with output
>>> + * frames from the VAAPI video surfaces.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 

This file is deprecated, and contains nothing useful anyway.

>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 

Shouldn't need any of the API-specific hwcontext includes, just the generic one.

>>> +#include 
>>> +
>>> +static AVBufferRef *hw_device_ctx = NULL;
>>> +FILE *output_file = NULL;
>>> +
>>> +int decoder_init_vaapi(AVCodecContext *ctx)
>>> +{
>>> +int err = 0;
>>> +const char *dev_name = "/dev/dri/renderD128";
>>> +
>>> +if ((err = av_hwdevice_ctx_create(_device_ctx, 
>>> AV_HWDEVICE_TYPE_VAAPI,
>>> +  dev_name, NULL, 0)) < 0) {
>>
>> The implementation already uses your dev_name as default, so you should
>> be able to drop that, and pass NULL to it.
>>
> 
> Yes, will remove the dev_name.
> 
>>> +fprintf(stderr, "Failed to create a VAAPI device.\n");
>>> +return err;
>>> +}
>>> +ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
>>> +
>>> +return err;
>>> +}
>>> +
>>> +static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
>>> +   const enum AVPixelFormat 
>>> *pix_fmts)
>>> +{
>>> +const enum AVPixelFormat *p;
>>> +
>>> +for (p = pix_fmts; *p != -1; p++) {
>>> +if (*p == AV_PIX_FMT_VAAPI)
>>> +return *p;
>>> +}
>>> +
>>> +return AV_PIX_FMT_NONE;
>>> +}
>>> +
>>> +int retrieve_data(AVFrame *input)
>>> +{
>>> +AVFrame *output = NULL;
>>> +int err;
>>> +av_assert0(input->format == AV_PIX_FMT_VAAPI);
>>> +
>>> +if (!(output = av_frame_alloc()))
>>> +return AVERROR(ENOMEM);
>>> +/* default output nv12 */
>>> +output->format = AV_PIX_FMT_NV12;
>>
>> You could use av_hwframe_transfer_get_formats() instead of hardcoding
>> it. Might be better if the input is 10 bit, not sure. (Just a
>> suggestion, up to you.)
> Ok, it's will show the HW surface/ SW pixel format mapping if we 
> use av_hwframe_transfer_get_formats() instead of hardcoding.
> 
>>
>>> +if ((err = av_hwframe_transfer_data(output, input, 0)) < 0) {
>>> +fprintf(stderr, "Failed to transfer data to output frame: %d.\n", 
>>> err);
>>> +goto fail;
>>> +}
>>> +
>>> +if ((err = av_frame_copy_props(output, input)) < 0) {
>>> +av_frame_unref(output);
>>> +goto fail;
>>> +}
>>> +
>>> +av_frame_unref(input);
>>> +av_frame_move_ref(input, output);
>>> +av_frame_free();
>>> +return 0;
>>> +
>>> +fail:
>>> +av_frame_free();
>>> +return err;
>>> +}
>>> +
>>> +int write_frame(AVFrame *frame)
>>> +{
>>> +int idx, size;
>>> +int width = frame->width;
>>> +int height = frame->height;
>>> +
>>> +av_assert0(frame && frame->data[0] && output_file);
>>> +
>>> +for (idx = 0; idx < height; idx++) {
>>> +if ((size = fwrite(frame->data[0] + 

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Remove duplicate slice_segment_address.

[Mark Thompson]

On 18/07/17 05:08, Jun Zhao wrote:
> From ee094ddd0fedecc81ee0107df58fc0ec80369c13 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 18 Jul 2017 00:01:09 -0400
> Subject: [PATCH] lavc/vaapi_encode_h265: Remove duplicate
>  slice_segment_address.
> 
> the VAEncSliceParameterBufferHEVC in libva have support this field,
> so remove the duplicate field in VAAPIEncodeH265MiscSliceParams.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode_h265.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 1d648a6d87..cf6b9388d1 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -149,7 +149,6 @@ typedef struct VAAPIEncodeH265MiscSequenceParams {
>  typedef struct VAAPIEncodeH265MiscSliceParams {
>  // Slice segments.
>  char first_slice_segment_in_pic_flag;
> -unsigned int slice_segment_address;
>  
>  // Short-term reference picture sets.
>  char short_term_ref_pic_set_sps_flag;
> @@ -586,7 +585,7 @@ static void 
> vaapi_encode_h265_write_slice_header2(PutBitContext *pbc,
>  if (vpic->pic_fields.bits.dependent_slice_segments_enabled_flag)
>  u(1, vslice_field(dependent_slice_segment_flag));
>  u(av_log2((priv->ctu_width * priv->ctu_height) - 1) + 1,
> -  mslice_var(slice_segment_address));
> +  vslice_var(slice_segment_address));
>  }
>  if (!vslice->slice_fields.bits.dependent_slice_segment_flag) {
>  for (i = 0; i < mseq->num_extra_slice_header_bits; i++)
> -- 
> 2.11.0
> 

LGTM, applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] Add tonemap filter

[Jan Ekstrom]

On Tue, Jul 18, 2017 at 10:33 PM, Vittorio Giovara
 wrote:
> Based off mpv automatic tonemapping capabilities.

Cool stuff, will have to test this soon. Thanks for putting an example
in the docs.

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Rostislav Pehlivanov]

On 18 July 2017 at 19:42, Nicolas George  wrote:

> Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> > To not cause drama on git repo I kindly ask Michael to remove your git
> > push access.
>
> I will leave the people who have that kind of power judge who must be
> banished :
>
> The one who made useful reviews to the patches, with constructive
> comments, and insists on high-quality code.
>
> Or the one who makes ad-hominem attacks, threatens to fork when he
> cannot have his way and never addresses the actual technical question.
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Chill, both of you.

Its a crappy format, no reason to blame anyone else but the format.
We have plenty of crappy formats which have no clear separation between
packets so demuxers have to give not-entirely-demuxed packets to the
decoder which also has to skip past junk. Its both wrong and its not,
because it isn't defined anywhere and the packets packed in the file were
never meant to go anywhere but the format they were packed in.

I think the image2 demuxer shouldn't handle this type of junk/useless data
filtering and would rather see a separate demuxer like the current patch
which deals with crap. Its not elegant but blame the format and the fact
that back when it was designed there weren't even any universal containers
for audio/video.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

[Michael Niedermayer]

On Sun, Jul 09, 2017 at 02:28:28PM +0200, Clément Bœsch wrote:
> On Sat, Jul 08, 2017 at 11:07:48PM +0200, Michael Niedermayer wrote:
> [...]
> > 5 days passed with no comments and no suggestions on how to implement
> > this better.
> > does anyone object to the fix as in the patch to be applied ?
> 
> misc patterns I found you may want to give a try (note that these are
> completely broken garbage you may want to ignore):
> 
> 82
> 00:04:50,430 --> 00:05:01,030
> < pisode 4
> saison 1>
> www.SeriesSub.com>
> 
> 
> 57
> 00:03:38,318 --> 00:03:42,778
> <>
> <>
> 
> 
> 2
> 00:01:10,000 --> 00:01:14,500
> >>> RebelSubTeam <<<
> 
> 
> 306
> 00:20:31,849 --> 00:20:56,839
> 
> <<<>>>
> 
> 
> 37
> 00:02:37,750 --> 00:02:43,700
> ~ASUKO MARCH!~
> >>:<<
> translation by: cangii
> Retiming by: furransu
> 
> 
> 1214
> 02:11:00,738 --> 02:11:05,538
> <<< ÓÍÀÊÑ ÒÈÉÌ < 2015 > UNACS TEAM >>>
> 
> 
> 1
> 00:00:01,000 --> 00:00:02,308
> << Antes <<
> Ela é hum...
> 
> 
> 544
> 00:53:43,780 --> 00:53:45,941
> <> - he calmed himself.
> 
> 
> 545
> 00:53:46,216 --> 00:53:49,083
> < the hotel is within easy reach.
> 
> 
> 894
> 00:37:59,693 --> 00:38:01,591
> mint asztalt foglaltatni
> a <<>Le Cirque-ben.
> 
> 
> I really have a LOT of matches, so these are very common patterns.
> 
> Feel free to apply your patch if it generally doesn't make these cases
> worse.

the patch doesnt change the fate test,
applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later

[Michael Niedermayer]

On Sun, Jul 16, 2017 at 01:06:55AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: shift exponent 47 is too large for 32-bit type 'int'
> Fixes: 2581/clusterfuzz-testcase-minimized-4681474395602944
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacdec_template.c | 8 
>  1 file changed, 8 insertions(+)

applied

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

[FFmpeg-devel] [PATCH] Add tonemap filter

[Vittorio Giovara]

Based off mpv automatic tonemapping capabilities.

Signed-off-by: Vittorio Giovara 
---
Updated following an off-list review.
Vittorio

 doc/filters.texi | 104 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_tonemap.c | 309 +++
 4 files changed, 415 insertions(+)
 create mode 100644 libavfilter/vf_tonemap.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 930ca4cfab..ca57b28e34 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14295,6 +14295,110 @@ Vertical low-pass filtering can only be enabled for 
@option{mode}
 
 @end table
 
+@section tonemap
+Tone map colors from different dynamic ranges.
+
+This filter expects data in single precision floating point, as it needs to
+operate on (and can output) out-of-range values. Another filter, such as
+@ref{zscale}, is needed to convert the resulting frame to a usable format.
+
+The tonemapping algorithms implemented only work on linear light, so input
+data should be linearized beforehand (and possibly correctly tagged).
+
+@example
+ffmpeg -i INPUT -vf 
zscale=transfer=linear,tonemap=clip,zscale=transfer=bt709,format=yuv420p OUTPUT
+@end example
+
+@subsection Options
+The filter accepts the following options.
+
+@table @option
+@item tonemap
+Set the tone map algorithm to use.
+
+Possible values are:
+@table @var
+@item none
+Do not apply any tone map, only desaturate overbright pixels.
+
+@item clip
+Hard-clip any out-of-range values. Use it for perfect color accuracy for
+in-range values, while distorting out-of-range values.
+
+@item linear
+Stretch the entire reference gamut to a linear multiple of the display.
+
+@item gamma
+Fit a logarithmic transfer between the tone curves.
+
+@item reinhard
+Preserve overall image brightness with a simple curve, using nonlinear
+contrast, which results in flattening details and degrading color accuracy.
+
+@item hable
+Peserve both dark and bright details better than @ref{reinhard}, at the cost
+of slightly darkening everything. Use it when detail preservation is more
+important than color and brightness accuracy.
+
+@item mobius
+Smoothly map out-of-range values, while retaining contrast and colors for
+in-range material as much as possible. Use it when color accuracy is more
+important than detail preservation.
+@end table
+
+Default is none.
+
+@item param
+Tune the tone mapping algorithm.
+
+This affects the following algorithms:
+@table @var
+@item none
+Ignored.
+
+@item linear
+Specifies the scale factor to use while stretching.
+Default to 1.0.
+
+@item gamma
+Specifies the exponent of the function.
+Default to 1.8.
+
+@item clip
+Specify an extra linear coefficient to multiply into the signal before 
clipping.
+Default to 1.0.
+
+@item reinhard
+Specify the local contrast coefficient at the display peak.
+Default to 0.5, which means that in-gamut values will be about half as bright
+as when clipping.
+
+@item hable
+Ignored.
+
+@item mobius
+Specify the transition point from linear to mobius transform. Every value
+below this point is guaranteed to be mapped 1:1. The higher the value, the
+more accurate the result will be, at the cost of losing bright details.
+Default to 0.3, which due to the steep initial slope still preserves in-range
+colors fairly accurately.
+@end table
+
+@item desat
+Apply desaturation for highlights that exceed this level of brightness. The
+higher the parameter, the more color information will be preserved. This
+setting helps prevent unnaturally blown-out colors for super-highlights, by
+(smoothly) turning into white instead. This makes images feel more natural,
+at the cost of reducing information about out-of-range colors.
+
+The default of 2.0 is somewhat conservative and will mostly just apply to
+skies or directly sunlit surfaces. A setting of 0.0 disables this option.
+
+@item peak
+Override signal/nominal/reference peak with this value. Useful when the
+embedded peak information in display metadata is not reliable or when tone
+mapping from a lower range to a higher range.
+
 @section transpose
 
 Transpose rows with columns in the input video and optionally flip it.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f023a0d5d6..0ada5d77b5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -310,6 +310,7 @@ OBJS-$(CONFIG_THRESHOLD_FILTER)  += 
vf_threshold.o
 OBJS-$(CONFIG_THUMBNAIL_FILTER)  += vf_thumbnail.o
 OBJS-$(CONFIG_TILE_FILTER)   += vf_tile.o
 OBJS-$(CONFIG_TINTERLACE_FILTER) += vf_tinterlace.o
+OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
 OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
 OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
 OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c1c52330ef..fa31e8d52a 100644
--- 

[FFmpeg-devel] [PATCH] avformat/utils: fix freeing packet queue in avformat_free_context

[Steven Siloti]

The packet queue is referenced in internal so it needs to be flushed
before the internal structure is freed.

Signed-off-by: Steven Siloti 
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 38d247c6cd..58283616dc 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4333,8 +4333,8 @@ void avformat_free_context(AVFormatContext *s)
 av_dict_free(>metadata);
 av_dict_free(>internal->id3v2_meta);
 av_freep(>streams);
-av_freep(>internal);
 flush_packet_queue(s);
+av_freep(>internal);
 av_free(s);
 }
 
-- 
2.13.0.windows.1

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

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

Updated patch that fixes other ctts modification code to use the new
ctts_allocated_size value; I've verified this passes fate.

- dale

On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis 
wrote:

> Resending as it's own message per contribution rules. I've also attached
> the patch in case the formatting gets trashed.
>
> When sidx box support is enabled, the code will skip reading all
> trun boxes (each containing ctts entries for samples inthat box).
>
> If seeks are attempted before all ctts values are known, the old
> code would dump ctts entries into the wrong location. These are
> then used to compute pts values which leads to out of order and
> incorrectly timestamped packets.
>
> This patch fixes ctts processing by always using the index returned
> by av_add_index_entry() as the ctts_data index. When the index gains
> new entries old values are reshuffled as appropriate.
>
> This approach makes sense since the mov demuxer is already relying
> on the mapping of AVIndex entries to samples for correct demuxing.
>
> Notes for future improvement:
> Probably there are other boxes (stts, stsc, etc) that are impacted
> by this issue... this patch only attempts to fix ctts since it
> completely breaks packet timestamping.
>
> This patch continues using an array for the ctts data, which is not
> the most ideal given the rearrangement that needs to happen (via
> memmove as new entries are read in). Ideally AVIndex and the ctts
> data would be set-type structures so addition is always worst case
> O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
> noticeable during seeks.
>
> Additionally since ctts samples from trun boxes always have a count
> of 1, there's probably an opportunity to avoid the post-seek fixup
> that iterates O(n) over all samples with an O(1) when no non-1 count
> samples are present.
>
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/isom.h |  1 +
>  libavformat/mov.c  | 46 +++---
>  2 files changed, 32 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index ff009b0896..fdd98c28f5 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
>  unsigned int stts_count;
>  MOVStts *stts_data;
>  unsigned int ctts_count;
> +unsigned int ctts_allocated_size;
>  MOVStts *ctts_data;
>  unsigned int stsc_count;
>  MOVStsc *stsc_data;
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63f84be782..412290b435 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4297,11 +4297,6 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>  }
>  if ((uint64_t)entries+sc->ctts_count >=
> UINT_MAX/sizeof(*sc->ctts_data))
>  return AVERROR_INVALIDDATA;
> -if ((err = av_reallocp_array(>ctts_data, entries +
> sc->ctts_count,
> - sizeof(*sc->ctts_data))) < 0) {
> -sc->ctts_count = 0;
> -return err;
> -}
>  if (flags & MOV_TRUN_DATA_OFFSET)data_offset=
> avio_rb32(pb);
>  if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) first_sample_flags =
> avio_rb32(pb);
>  dts= sc->track_end - sc->time_offset;
> @@ -4312,26 +4307,28 @@ static int mov_read_trun(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  unsigned sample_size = frag->size;
>  int sample_flags = i ? frag->flags : first_sample_flags;
>  unsigned sample_duration = frag->duration;
> +unsigned ctts_duration = 0;
>  int keyframe = 0;
> +int ctts_index = 0;
> +int old_nb_index_entries = st->nb_index_entries;
>
>  if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration =
> avio_rb32(pb);
>  if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size =
> avio_rb32(pb);
>  if (flags & MOV_TRUN_SAMPLE_FLAGS)sample_flags=
> avio_rb32(pb);
> -sc->ctts_data[sc->ctts_count].count = 1;
> -sc->ctts_data[sc->ctts_count].duration = (flags &
> MOV_TRUN_SAMPLE_CTS) ?
> -  avio_rb32(pb) : 0;
> -mov_update_dts_shift(sc, sc->ctts_data[sc->ctts_count].duration);
> +if (flags & MOV_TRUN_SAMPLE_CTS)  ctts_duration   =
> avio_rb32(pb);
> +
> +mov_update_dts_shift(sc, ctts_duration);
>  if (frag->time != AV_NOPTS_VALUE) {
>  if (c->use_mfra_for == FF_MOV_FLAG_MFRA_PTS) {
>  int64_t pts = frag->time;
>  av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
>  " sc->dts_shift %d ctts.duration %d"
>  " sc->time_offset %"PRId64" flags &
> MOV_TRUN_SAMPLE_CTS %d\n", pts,
> -sc->dts_shift, sc->ctts_data[sc->ctts_count].
> duration,
> +sc->dts_shift, ctts_duration,
>  sc->time_offset, flags & 

Re: [FFmpeg-devel] tsan warning about data race in h264 decoder

[Ronald S. Bultje]

Hi Wah-Teng,

On Tue, Jul 18, 2017 at 12:59 PM, Wan-Teh Chang <
wtc-at-google@ffmpeg.org> wrote:

> Hi,
>
> I'd like to report a tsan warning about a data race in the h264 decoder.
>
> 1. Steps to reproduce:
>
> ./configure --samples=~/fate-suite/ --toolchain=clang-tsan
> --disable-stripping
>
> make fate-h264 THREADS=4
>
> 2. Here is an excerpt of the tsan warning in
> tests/data/fate/h264-conformance-ba1_ft_c.err:
>
> WARNING: ThreadSanitizer: data race (pid=31070)
>   Write of size 8 at 0x7bbc82a8 by thread T1 (mutexes: write M1628):
> #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/
> tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
> (ffmpeg+0x10de9d)
> #1 h264_initialise_ref_list
> home/wtc/tmp/ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
> #2 ff_h264_build_ref_list
> home/wtc/tmp/ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
> #3 h264_slice_init
> home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
> #4 ff_h264_queue_decode_slice
> home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:2129 (ffmpeg+0x1191149)
> #5 decode_nal_units
> home/wtc/tmp/ffmpeg/libavcodec/h264dec.c:675:24 (ffmpeg+0x7924ec)
> #6 h264_decode_frame home/wtc/tmp/ffmpeg/libavcodec/h264dec.c:1006
> (ffmpeg+0x7924ec)
> #7 frame_worker_thread
> home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:201:21
> (ffmpeg+0xae56dc)
>
>   Previous read of size 8 at 0x7bbc82a8 by main thread (mutexes:
> write M1630):
> #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/
> tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
> (ffmpeg+0x10de9d)
> #1 ff_h264_update_thread_context
> home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)
> #2 update_context_from_thread
> home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:315:19
> (ffmpeg+0xae4302)
> #3 submit_packet
> home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:418:15
> (ffmpeg+0xae3783)
> #4 ff_thread_decode_frame
> home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:495 (ffmpeg+0xae3783)
> #5 decode_simple_internal
> home/wtc/tmp/ffmpeg/libavcodec/decode.c:415:15 (ffmpeg+0x665ae4)
> #6 decode_simple_receive_frame
> home/wtc/tmp/ffmpeg/libavcodec/decode.c:620 (ffmpeg+0x665ae4)
> #7 decode_receive_frame_internal
> home/wtc/tmp/ffmpeg/libavcodec/decode.c:638 (ffmpeg+0x665ae4)
> #8 avcodec_send_packet
> home/wtc/tmp/ffmpeg/libavcodec/decode.c:678:15 (ffmpeg+0x665017)
> #9 decode home/wtc/tmp/ffmpeg/ffmpeg.c:2265:15 (ffmpeg+0x1a748e)
> #10 decode_video home/wtc/tmp/ffmpeg/ffmpeg.c:2409 (ffmpeg+0x1a748e)
> #11 process_input_packet home/wtc/tmp/ffmpeg/ffmpeg.c:2644
> (ffmpeg+0x1a748e)#12 process_input
> home/wtc/tmp/ffmpeg/ffmpeg.c:4432:5 (ffmpeg+0x1a2e69)
> #13 transcode_step home/wtc/tmp/ffmpeg/ffmpeg.c:4543 (ffmpeg+0x1a2e69)
> #14 transcode home/wtc/tmp/ffmpeg/ffmpeg.c:4597 (ffmpeg+0x1a2e69)
> #15 main home/wtc/tmp/ffmpeg/ffmpeg.c:4803:9 (ffmpeg+0x19daef)
>
> 3. The relevant source code is:
>
> libavcodec/h264_refs.c:
>
> 135 static void h264_initialise_ref_list(H264Context *h, H264SliceContext
> *sl)
> 136 {
> ...
> 213 for (i = 0; i < sl->list_count; i++)
> 214 h->default_ref[i] = sl->ref_list[i][0];
> 215 }
>
> libavcodec/h264_slice.c:
>
> 288 int ff_h264_update_thread_context(AVCodecContext *dst,
> 289   const AVCodecContext *src)
> 290 {
> ...
> 409 memcpy(>poc,>poc,sizeof(h->poc));
> 410
> 411 memcpy(h->default_ref, h1->default_ref, sizeof(h->default_ref));
> 412 memcpy(h->short_ref,   h1->short_ref,   sizeof(h->short_ref));
> 413 memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
> 414 memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));
> 415 memcpy(h->last_pocs,   h1->last_pocs,   sizeof(h->last_pocs));
>
> 4. I can eliminate the tsan warning by deleting line 411 in
> libavcodec/h264_slice.c, but I don't know if that is the correct fix.
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 6deb08fe6d..2fb89b189d 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -408,7 +408,6 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
>
>  memcpy(>poc,>poc,sizeof(h->poc));
>
> -memcpy(h->default_ref, h1->default_ref, sizeof(h->default_ref));
>  memcpy(h->short_ref,   h1->short_ref,   sizeof(h->short_ref));
>  memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
>  memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));


Reminds me a little of
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e72690b18da064f6c0f04f09ccde72b6636e3159.
From a quick look, it appears that default_ref[] is unconditionally
initialized in initialise_ref_list() (called from ff_h264_build_ref_list(),
called from h264_slice_init()), so I think your suggested patch is correct.
Can you send it as a git-formatted patch?

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> To not cause drama on git repo I kindly ask Michael to remove your git
> push access.

I will leave the people who have that kind of power judge who must be
banished :

The one who made useful reviews to the patches, with constructive
comments, and insists on high-quality code.

Or the one who makes ad-hominem attacks, threatens to fork when he
cannot have his way and never addresses the actual technical question.

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/18/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> Design is just fine. You need to be more constructive, otherwise I will
>> just assume you want to be evil and ignore your comments.
>
> This is not true, anybody who reads the mailing-list can see it (I can
> provide links if necessary).
>
> Please stop your ad-hominem attacks. Immediately.
>
> If the patches gets pushed with this issue unresolved, I will revert.

To not cause drama on git repo I kindly ask Michael to remove your git
push access.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> Design is just fine. You need to be more constructive, otherwise I will
> just assume you want to be evil and ignore your comments.

This is not true, anybody who reads the mailing-list can see it (I can
provide links if necessary).

Please stop your ad-hominem attacks. Immediately.

If the patches gets pushed with this issue unresolved, I will revert.

Regards,

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/18/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> You are unable to work with as a team.
>
> You may notice that my message did not contain anything ad-hominem.
> This, on the other hand, is pure ad-hoinem.
>
>> I see nothing wrong with either demuxer or decoder code and no
>> duplicated lines of code.
>
> The codde is not duplicated, but the logic is, one reading from a
> buffer, one reading from avio. Proof that this is duplicated : if a typo
> is found in the name of one of the fields, it needs fixing in both lavc
> and lavf. This is not good design. And as such, it cannot be accepted in
> FFmpeg.

Design is just fine. You need to be more constructive, otherwise I will
just assume you want to be evil and ignore your comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

[Marton Balint]

On Sat, 8 Jul 2017, Marton Balint wrote:


This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.

v2:
- only try teletext decoding for 576i PAL mode
- some comments as requested by Aaron Levinson

Signed-off-by: Marton Balint 


Applied the series, thanks for all the comments.

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

[FFmpeg-devel] tsan warning about data race in h264 decoder

[Wan-Teh Chang]

Hi,

I'd like to report a tsan warning about a data race in the h264 decoder.

1. Steps to reproduce:

./configure --samples=~/fate-suite/ --toolchain=clang-tsan --disable-stripping

make fate-h264 THREADS=4

2. Here is an excerpt of the tsan warning in
tests/data/fate/h264-conformance-ba1_ft_c.err:

WARNING: ThreadSanitizer: data race (pid=31070)
  Write of size 8 at 0x7bbc82a8 by thread T1 (mutexes: write M1628):
#0 memcpy 
/work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 h264_initialise_ref_list
home/wtc/tmp/ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
#2 ff_h264_build_ref_list
home/wtc/tmp/ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
#3 h264_slice_init
home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
#4 ff_h264_queue_decode_slice
home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:2129 (ffmpeg+0x1191149)
#5 decode_nal_units
home/wtc/tmp/ffmpeg/libavcodec/h264dec.c:675:24 (ffmpeg+0x7924ec)
#6 h264_decode_frame home/wtc/tmp/ffmpeg/libavcodec/h264dec.c:1006
(ffmpeg+0x7924ec)
#7 frame_worker_thread
home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56dc)

  Previous read of size 8 at 0x7bbc82a8 by main thread (mutexes:
write M1630):
#0 memcpy 
/work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 ff_h264_update_thread_context
home/wtc/tmp/ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)
#2 update_context_from_thread
home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:315:19
(ffmpeg+0xae4302)
#3 submit_packet
home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:418:15
(ffmpeg+0xae3783)
#4 ff_thread_decode_frame
home/wtc/tmp/ffmpeg/libavcodec/pthread_frame.c:495 (ffmpeg+0xae3783)
#5 decode_simple_internal
home/wtc/tmp/ffmpeg/libavcodec/decode.c:415:15 (ffmpeg+0x665ae4)
#6 decode_simple_receive_frame
home/wtc/tmp/ffmpeg/libavcodec/decode.c:620 (ffmpeg+0x665ae4)
#7 decode_receive_frame_internal
home/wtc/tmp/ffmpeg/libavcodec/decode.c:638 (ffmpeg+0x665ae4)
#8 avcodec_send_packet
home/wtc/tmp/ffmpeg/libavcodec/decode.c:678:15 (ffmpeg+0x665017)
#9 decode home/wtc/tmp/ffmpeg/ffmpeg.c:2265:15 (ffmpeg+0x1a748e)
#10 decode_video home/wtc/tmp/ffmpeg/ffmpeg.c:2409 (ffmpeg+0x1a748e)
#11 process_input_packet home/wtc/tmp/ffmpeg/ffmpeg.c:2644
(ffmpeg+0x1a748e)#12 process_input
home/wtc/tmp/ffmpeg/ffmpeg.c:4432:5 (ffmpeg+0x1a2e69)
#13 transcode_step home/wtc/tmp/ffmpeg/ffmpeg.c:4543 (ffmpeg+0x1a2e69)
#14 transcode home/wtc/tmp/ffmpeg/ffmpeg.c:4597 (ffmpeg+0x1a2e69)
#15 main home/wtc/tmp/ffmpeg/ffmpeg.c:4803:9 (ffmpeg+0x19daef)

3. The relevant source code is:

libavcodec/h264_refs.c:

135 static void h264_initialise_ref_list(H264Context *h, H264SliceContext *sl)
136 {
...
213 for (i = 0; i < sl->list_count; i++)
214 h->default_ref[i] = sl->ref_list[i][0];
215 }

libavcodec/h264_slice.c:

288 int ff_h264_update_thread_context(AVCodecContext *dst,
289   const AVCodecContext *src)
290 {
...
409 memcpy(>poc,>poc,sizeof(h->poc));
410
411 memcpy(h->default_ref, h1->default_ref, sizeof(h->default_ref));
412 memcpy(h->short_ref,   h1->short_ref,   sizeof(h->short_ref));
413 memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
414 memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));
415 memcpy(h->last_pocs,   h1->last_pocs,   sizeof(h->last_pocs));

4. I can eliminate the tsan warning by deleting line 411 in
libavcodec/h264_slice.c, but I don't know if that is the correct fix.

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6deb08fe6d..2fb89b189d 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -408,7 +408,6 @@ int ff_h264_update_thread_context(AVCodecContext *dst,

 memcpy(>poc,>poc,sizeof(h->poc));

-memcpy(h->default_ref, h1->default_ref, sizeof(h->default_ref));
 memcpy(h->short_ref,   h1->short_ref,   sizeof(h->short_ref));
 memcpy(h->long_ref,h1->long_ref,sizeof(h->long_ref));
 memcpy(h->delayed_pic, h1->delayed_pic, sizeof(h->delayed_pic));

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

[FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

Resending as it's own message per contribution rules. I've also attached
the patch in case the formatting gets trashed.

When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).

If seeks are attempted before all ctts values are known, the old
code would dump ctts entries into the wrong location. These are
then used to compute pts values which leads to out of order and
incorrectly timestamped packets.

This patch fixes ctts processing by always using the index returned
by av_add_index_entry() as the ctts_data index. When the index gains
new entries old values are reshuffled as appropriate.

This approach makes sense since the mov demuxer is already relying
on the mapping of AVIndex entries to samples for correct demuxing.

Notes for future improvement:
Probably there are other boxes (stts, stsc, etc) that are impacted
by this issue... this patch only attempts to fix ctts since it
completely breaks packet timestamping.

This patch continues using an array for the ctts data, which is not
the most ideal given the rearrangement that needs to happen (via
memmove as new entries are read in). Ideally AVIndex and the ctts
data would be set-type structures so addition is always worst case
O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
noticeable during seeks.

Additionally since ctts samples from trun boxes always have a count
of 1, there's probably an opportunity to avoid the post-seek fixup
that iterates O(n) over all samples with an O(1) when no non-1 count
samples are present.

Signed-off-by: Dale Curtis 
---
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 46 +++---
 2 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index ff009b0896..fdd98c28f5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
 unsigned int stts_count;
 MOVStts *stts_data;
 unsigned int ctts_count;
+unsigned int ctts_allocated_size;
 MOVStts *ctts_data;
 unsigned int stsc_count;
 MOVStsc *stsc_data;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63f84be782..412290b435 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4297,11 +4297,6 @@ static int mov_read_trun(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
 }
 if ((uint64_t)entries+sc->ctts_count >= UINT_MAX/sizeof(*sc->ctts_
data))
 return AVERROR_INVALIDDATA;
-if ((err = av_reallocp_array(>ctts_data, entries + sc->ctts_count,
- sizeof(*sc->ctts_data))) < 0) {
-sc->ctts_count = 0;
-return err;
-}
 if (flags & MOV_TRUN_DATA_OFFSET)data_offset=
avio_rb32(pb);
 if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) first_sample_flags =
avio_rb32(pb);
 dts= sc->track_end - sc->time_offset;
@@ -4312,26 +4307,28 @@ static int mov_read_trun(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
 unsigned sample_size = frag->size;
 int sample_flags = i ? frag->flags : first_sample_flags;
 unsigned sample_duration = frag->duration;
+unsigned ctts_duration = 0;
 int keyframe = 0;
+int ctts_index = 0;
+int old_nb_index_entries = st->nb_index_entries;

 if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration =
avio_rb32(pb);
 if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size =
avio_rb32(pb);
 if (flags & MOV_TRUN_SAMPLE_FLAGS)sample_flags=
avio_rb32(pb);
-sc->ctts_data[sc->ctts_count].count = 1;
-sc->ctts_data[sc->ctts_count].duration = (flags &
MOV_TRUN_SAMPLE_CTS) ?
-  avio_rb32(pb) : 0;
-mov_update_dts_shift(sc, sc->ctts_data[sc->ctts_count].duration);
+if (flags & MOV_TRUN_SAMPLE_CTS)  ctts_duration   =
avio_rb32(pb);
+
+mov_update_dts_shift(sc, ctts_duration);
 if (frag->time != AV_NOPTS_VALUE) {
 if (c->use_mfra_for == FF_MOV_FLAG_MFRA_PTS) {
 int64_t pts = frag->time;
 av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
 " sc->dts_shift %d ctts.duration %d"
 " sc->time_offset %"PRId64" flags &
MOV_TRUN_SAMPLE_CTS %d\n", pts,
-sc->dts_shift, sc->ctts_data[sc->ctts_count].
duration,
+sc->dts_shift, ctts_duration,
 sc->time_offset, flags & MOV_TRUN_SAMPLE_CTS);
 dts = pts - sc->dts_shift;
 if (flags & MOV_TRUN_SAMPLE_CTS) {
-dts -= sc->ctts_data[sc->ctts_count].duration;
+dts -= ctts_duration;
 } else {
 dts -= sc->time_offset;
 }
@@ -4343,7 +4340,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
 }

[FFmpeg-devel] [PATCH] pthread_frame: revert 2e664b9c1e73c80aab91070c1eb7676f04bdd12d.

[Wan-Teh Chang]

The patch does not fix the tsan warning it was intended to fix.
Reverting the patch moves the av_log() back to the outside of the lock.

Signed-off-by: Wan-Teh Chang 
---
 libavcodec/pthread_frame.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 2cea232a36..08e182c3d1 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -570,11 +570,12 @@ void ff_thread_report_progress(ThreadFrame *f, int n, int 
field)
 
 p = f->owner[field]->internal->thread_ctx;
 
-pthread_mutex_lock(>progress_mutex);
 if (atomic_load_explicit(>debug_threads, memory_order_relaxed))
 av_log(f->owner[field], AV_LOG_DEBUG,
"%p finished %d field %d\n", progress, n, field);
 
+pthread_mutex_lock(>progress_mutex);
+
 atomic_store_explicit([field], n, memory_order_release);
 
 pthread_cond_broadcast(>progress_cond);
@@ -592,10 +593,11 @@ void ff_thread_await_progress(ThreadFrame *f, int n, int 
field)
 
 p = f->owner[field]->internal->thread_ctx;
 
-pthread_mutex_lock(>progress_mutex);
 if (atomic_load_explicit(>debug_threads, memory_order_relaxed))
 av_log(f->owner[field], AV_LOG_DEBUG,
"thread awaiting %d field %d from %p\n", n, field, progress);
+
+pthread_mutex_lock(>progress_mutex);
 while (atomic_load_explicit([field], memory_order_relaxed) < n)
 pthread_cond_wait(>progress_cond, >progress_mutex);
 pthread_mutex_unlock(>progress_mutex);
-- 
2.13.2.932.g7449e964c-goog

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

[FFmpeg-devel] [PATCH] fate: add vf_overlay test for main source with alpha channel

[Peter Große]

Signed-off-by: Peter Große 
---
 tests/fate/filter-video.mak  |  5 +
 tests/ref/fate/filter-overlay-main-alpha | 15 +++
 2 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/filter-overlay-main-alpha

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 9186593c10..cbfee449b6 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -341,6 +341,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MATROSKA_DEMUXER 
OVERLAY_FILTER H264_DECODER
 fate-filter-overlay-dvdsub-2397: tests/data/filtergraphs/overlay-dvdsub-2397
 fate-filter-overlay-dvdsub-2397: CMD = framecrc -flags bitexact -i 
$(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/overlay-dvdsub-2397 -c:a copy
 
+FATE_FILTER_SAMPLES-$(call ALLYES, MXF_DEMUXER OVERLAY_FILTER DNXHD_DECODER 
PNG_DECODER) += fate-filter-overlay-main-alpha
+fate-filter-overlay-main-alpha: SRC = $(TARGET_SAMPLES)/mxf/track_01_v02.mxf
+fate-filter-overlay-main-alpha: OVERLAY = $(TARGET_SAMPLES)/png1/lena-rgba.png
+fate-filter-overlay-main-alpha: CMD = framecrc -flags bitexact -i $(SRC) 
-filter_complex "movie='$(OVERLAY)'[logo];[v:0][logo]overlay" -an
+
 FATE_FILTER_HQX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER HQX_FILTER) = 
fate-filter-hq2x fate-filter-hq3x fate-filter-hq4x
 FATE_FILTER_SAMPLES-yes += $(FATE_FILTER_HQX-yes)
 fate-filter-hq2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf hqx=2 -pix_fmt bgra
diff --git a/tests/ref/fate/filter-overlay-main-alpha 
b/tests/ref/fate/filter-overlay-main-alpha
new file mode 100644
index 00..5e5cdfd0d2
--- /dev/null
+++ b/tests/ref/fate/filter-overlay-main-alpha
@@ -0,0 +1,15 @@
+#tb 0: 1001/24000
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1280x720
+#sar 0: 1/1
+0,  0,  0,1,  2304000, 0x72b48234
+0,  1,  1,1,  2304000, 0x72b48234
+0,  2,  2,1,  2304000, 0x72b48234
+0,  3,  3,1,  2304000, 0x72b48234
+0,  4,  4,1,  2304000, 0x72b48234
+0,  5,  5,1,  2304000, 0x72b48234
+0,  6,  6,1,  2304000, 0x72b48234
+0,  7,  7,1,  2304000, 0x72b48234
+0,  8,  8,1,  2304000, 0x72b48234
+0,  9,  9,1,  2304000, 0x72b48234
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Derek Buitenhuis]

On 7/18/2017 3:48 PM, Nicolas George wrote:
> The reasons are exactly the same as the commit that it restores. I will
> include that and the other comments you request once I can access my
> work tree comfortably.

OK.

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

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Derek Buitenhuis a écrit :
> Doesn't say /why/ it's being reverted. Please update
> the commit message to do so.

The reasons are exactly the same as the commit that it restores. I will
include that and the other comments you request once I can access my
work tree comfortably.

Regards,

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> You are unable to work with as a team.

You may notice that my message did not contain anything ad-hominem.
This, on the other hand, is pure ad-hoinem.

> I see nothing wrong with either demuxer or decoder code and no
> duplicated lines of code.

The codde is not duplicated, but the logic is, one reading from a
buffer, one reading from avio. Proof that this is duplicated : if a typo
is found in the name of one of the fields, it needs fixing in both lavc
and lavf. This is not good design. And as such, it cannot be accepted in
FFmpeg.

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

Re: [FFmpeg-devel] [PATCH 6/7] lavfi/framesync2: implement activate design.

[Derek Buitenhuis]

On 7/18/2017 3:30 PM, Paul B Mahol wrote:
> I actually like this 'design', as its more like VS one.

I wasn't commenting on the code/design itself, but the commit message,
or rather, lack thereof.

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

Re: [FFmpeg-devel] [PATCH 6/7] lavfi/framesync2: implement activate design.

[Paul B Mahol]

On 7/18/17, Derek Buitenhuis  wrote:
> On 7/17/2017 3:19 PM, Nicolas George wrote:
>> Signed-off-by: Nicolas George 
>> ---
>>  libavfilter/framesync2.c | 166
>> +++
>>  libavfilter/framesync2.h |  77 --
>>  2 files changed, 82 insertions(+), 161 deletions(-)
>
> So what does this patch set *do*? The commit message has literally no
> information on what this actually does. One can say "well go read the
> entirety of the mailing list backlog", but that sure isn't a very good
> way to help e.g. people who git blame in the future. There is no
> substitute for a commit message.
>
> Also 'activate design' is gibberish in English, which doesn't help
> letting one know what it does.

I actually like this 'design', as its more like VS one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/7] lavfi/framesync2: implement activate design.

[Derek Buitenhuis]

On 7/17/2017 3:19 PM, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/framesync2.c | 166 
> +++
>  libavfilter/framesync2.h |  77 --
>  2 files changed, 82 insertions(+), 161 deletions(-)

So what does this patch set *do*? The commit message has literally no
information on what this actually does. One can say "well go read the
entirety of the mailing list backlog", but that sure isn't a very good
way to help e.g. people who git blame in the future. There is no
substitute for a commit message.

Also 'activate design' is gibberish in English, which doesn't help
letting one know what it does.

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

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Derek Buitenhuis]

On 7/17/2017 3:19 PM, Nicolas George wrote:
> This reverts commit 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8.
> 
> The fate-ffm change is caused by field_order now being set
> on the output format because the first frame arrives earlier.
> The fate-mxf change is assumed to be the same.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/buffersrc.c | 25 +
>  tests/ref/lavf/ffm  |  2 +-
>  tests/ref/lavf/mxf  |  6 +++---
>  3 files changed, 29 insertions(+), 4 deletions(-)

Doesn't say /why/ it's being reverted. Please update
the commit message to do so.

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/18/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>>I will fork FFmpeg.
>
> It is the third time you make that threat. Out of principle, I want to
> reply to anybody making it : please go ahead and good riddance.
>
> Seriously, only somebody unable to working in a team and respecting the
> diverse wishes and sensibilities of their colleagues make that kind of
> threat.

You are unable to work with as a team.

I see nothing wrong with either demuxer or decoder code and no
duplicated lines of code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I will fork FFmpeg.

It is the third time you make that threat. Out of principle, I want to
reply to anybody making it : please go ahead and good riddance.

Seriously, only somebody unable to working in a team and respecting the
diverse wishes and sensibilities of their colleagues make that kind of
threat.

Regards,

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/18/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I'm not going to listen your non-useful comments.
>
> My comments have been constructive. Pushing with outstanding objections
> like that is against the project policy. If you do it on purpose, your
> Git right should be revoked.

No it will not. I will fork FFmpeg. And leave you alone with CE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I'm not going to listen your non-useful comments.

My comments have been constructive. Pushing with outstanding objections
like that is against the project policy. If you do it on purpose, your
Git right should be revoked.

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/18/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I believe your approach is fine.
>
> The huge duplication between decoder and demuxer is definitely not fine.
> You need to find a solution before pushing anything.

I'm not going to listen your non-useful comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] zscale: Factor out format initialization

[Paul B Mahol]

On 7/18/17, Vittorio Giovara  wrote:
> ---
>  libavfilter/vf_zscale.c | 46 +-
>  1 file changed, 21 insertions(+), 25 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH 3/5] zscale: Factor out graph building

[Paul B Mahol]

On 7/18/17, Vittorio Giovara  wrote:
> ---
>  libavfilter/vf_zscale.c | 52
> +
>  1 file changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
> index a128db6267..466689dbc5 100644
> --- a/libavfilter/vf_zscale.c
> +++ b/libavfilter/vf_zscale.c
> @@ -438,6 +438,34 @@ static void format_init(zimg_image_format *format,
> AVFrame *frame, const AVPixFm
>  format->chroma_location = location == -1 ?
> convert_chroma_location(frame->chroma_location) : location;
>  }
>
> +static int graph_build(zimg_filter_graph **graph, zimg_graph_builder_params
> *params,
> +   zimg_image_format *src_format, zimg_image_format
> *dst_format,
> +   void **tmp, size_t *tmp_size)
> +{
> +int ret;
> +size_t size;
> +
> +zimg_filter_graph_free(*graph);
> +*graph = zimg_filter_graph_build(src_format, dst_format, params);
> +if (!*graph)
> +return print_zimg_error(NULL);
> +
> +ret = zimg_filter_graph_get_tmp_size(*graph, );
> +if (ret)
> +return print_zimg_error(NULL);
> +
> +if (size > *tmp_size) {
> +av_freep(tmp);
> +*tmp = av_malloc(size);
> +if (!*tmp)
> +return AVERROR(ENOMEM);
> +
> +*tmp_size = size;
> +}
> +
> +return 0;
> +}
> +
>  static int filter_frame(AVFilterLink *link, AVFrame *in)
>  {
>  ZScaleContext *s = link->dst->priv;
> @@ -447,7 +475,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
>  zimg_image_buffer_const src_buf = { ZIMG_API_VERSION };
>  zimg_image_buffer dst_buf = { ZIMG_API_VERSION };
>  char buf[32];
> -size_t tmp_size;
>  int ret = 0, plane;
>  AVFrame *out;
>
> @@ -520,27 +547,10 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
>  if (s->chromal != -1)
>  out->chroma_location = (int)s->dst_format.chroma_location - 1;
>
> -zimg_filter_graph_free(s->graph);
> -s->graph = zimg_filter_graph_build(>src_format, >dst_format,
> >params);
> -if (!s->graph) {
> -ret = print_zimg_error(link->dst);
> -goto fail;
> -}
> -
> -if ((ret = zimg_filter_graph_get_tmp_size(s->graph, _size))) {
> -ret = print_zimg_error(link->dst);
> +ret = graph_build(>graph, >params, >src_format,
> >dst_format,
> +  >tmp, >tmp_size);
> +if (ret < 0)
>  goto fail;
> -}
> -
> -if (tmp_size > s->tmp_size) {
> -av_freep(>tmp);
> -s->tmp = av_malloc(tmp_size);
> -if (!s->tmp) {
> -ret = AVERROR(ENOMEM);
> -goto fail;
> -}
> -s->tmp_size = tmp_size;
> -}
>
>  s->in_colorspace  = in->colorspace;
>  s->in_trc = in->color_trc;
> --
> 2.13.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH 3/5] zscale: Factor out graph building

[Vittorio Giovara]

---
 libavfilter/vf_zscale.c | 52 +
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index a128db6267..466689dbc5 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -438,6 +438,34 @@ static void format_init(zimg_image_format *format, AVFrame 
*frame, const AVPixFm
 format->chroma_location = location == -1 ? 
convert_chroma_location(frame->chroma_location) : location;
 }
 
+static int graph_build(zimg_filter_graph **graph, zimg_graph_builder_params 
*params,
+   zimg_image_format *src_format, zimg_image_format 
*dst_format,
+   void **tmp, size_t *tmp_size)
+{
+int ret;
+size_t size;
+
+zimg_filter_graph_free(*graph);
+*graph = zimg_filter_graph_build(src_format, dst_format, params);
+if (!*graph)
+return print_zimg_error(NULL);
+
+ret = zimg_filter_graph_get_tmp_size(*graph, );
+if (ret)
+return print_zimg_error(NULL);
+
+if (size > *tmp_size) {
+av_freep(tmp);
+*tmp = av_malloc(size);
+if (!*tmp)
+return AVERROR(ENOMEM);
+
+*tmp_size = size;
+}
+
+return 0;
+}
+
 static int filter_frame(AVFilterLink *link, AVFrame *in)
 {
 ZScaleContext *s = link->dst->priv;
@@ -447,7 +475,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 zimg_image_buffer_const src_buf = { ZIMG_API_VERSION };
 zimg_image_buffer dst_buf = { ZIMG_API_VERSION };
 char buf[32];
-size_t tmp_size;
 int ret = 0, plane;
 AVFrame *out;
 
@@ -520,27 +547,10 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 if (s->chromal != -1)
 out->chroma_location = (int)s->dst_format.chroma_location - 1;
 
-zimg_filter_graph_free(s->graph);
-s->graph = zimg_filter_graph_build(>src_format, >dst_format, 
>params);
-if (!s->graph) {
-ret = print_zimg_error(link->dst);
-goto fail;
-}
-
-if ((ret = zimg_filter_graph_get_tmp_size(s->graph, _size))) {
-ret = print_zimg_error(link->dst);
+ret = graph_build(>graph, >params, >src_format, 
>dst_format,
+  >tmp, >tmp_size);
+if (ret < 0)
 goto fail;
-}
-
-if (tmp_size > s->tmp_size) {
-av_freep(>tmp);
-s->tmp = av_malloc(tmp_size);
-if (!s->tmp) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-s->tmp_size = tmp_size;
-}
 
 s->in_colorspace  = in->colorspace;
 s->in_trc = in->color_trc;
-- 
2.13.2

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

[FFmpeg-devel] [PATCH 1/5] Add YUV444 32bit floating point pixel format

[Vittorio Giovara]

With and without alpha.
---
TODO: version bump

I am aware support for bpp > 2 is not present but the scope
of these formats is limited to a specific usecase, and contained
in libavfilter only.
Suggestions for reflecting this in documentation are welcome.

Cheers,
Vittorio

 libavutil/pixdesc.c | 51 +++
 libavutil/pixdesc.h |  5 +
 libavutil/pixfmt.h  |  7 +++
 libswscale/utils.c  |  4 
 4 files changed, 67 insertions(+)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 46a7eff06d..a61ce3c5ac 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2162,6 +2162,57 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 .name = "d3d11",
 .flags = AV_PIX_FMT_FLAG_HWACCEL,
 },
+[AV_PIX_FMT_YUV444F32LE] = {
+.name = "yuv444f32le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* Y */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* U */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV444F32BE] = {
+.name = "yuv444f32be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* Y */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* U */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR | 
AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUVA444F32LE] = {
+.name = "yuva444f32le",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* Y */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* U */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* V */
+{ 3, 4, 0, 0, 32, 3, 31, 1 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_FLOAT | 
AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_YUVA444F32BE] = {
+.name = "yuva444f32be",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* Y */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* U */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* V */
+{ 3, 4, 0, 0, 32, 3, 31, 1 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
+ AV_PIX_FMT_FLAG_FLOAT | AV_PIX_FMT_FLAG_ALPHA,
+},
 };
 #if FF_API_PLUS1_MINUS1
 FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index c3a6f27f49..294555260a 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -178,6 +178,11 @@ typedef struct AVPixFmtDescriptor {
 #define AV_PIX_FMT_FLAG_BAYER(1 << 8)
 
 /**
+ * The pixel format contains IEEE-754 single precision floating point values.
+ */
+#define AV_PIX_FMT_FLAG_FLOAT(1 << 10)
+
+/**
  * Return the number of bits per pixel used by the pixel format
  * described by pixdesc. Note that this is not the same as the number
  * of bits per sample.
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index e1e4074bee..d6a874da15 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -326,6 +326,11 @@ enum AVPixelFormat {
  */
 AV_PIX_FMT_D3D11,
 
+AV_PIX_FMT_YUV444F32LE,  ///< IEEE-754 single precision planar YUV 4:4:4,  
96bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian
+AV_PIX_FMT_YUV444F32BE,  ///< IEEE-754 single precision planar YUV 4:4:4,  
96bpp, (1 Cr & Cb sample per 1x1 Y samples), big-endian
+AV_PIX_FMT_YUVA444F32LE, ///< IEEE-754 single precision planar YUV 4:4:4, 
128bpp, (1 Cr & Cb sample per 1x1 Y & A sample), little-endian
+AV_PIX_FMT_YUVA444F32BE, ///< IEEE-754 single precision planar YUV 4:4:4, 
128bpp, (1 Cr & Cb sample per 1x1 Y & A sample), big-endian
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
@@ -389,6 +394,8 @@ enum AVPixelFormat {
 #define AV_PIX_FMT_BAYER_GBRG16 AV_PIX_FMT_NE(BAYER_GBRG16BE,
BAYER_GBRG16LE)
 #define AV_PIX_FMT_BAYER_GRBG16 AV_PIX_FMT_NE(BAYER_GRBG16BE,
BAYER_GRBG16LE)
 
+#define AV_PIX_FMT_YUV444F32  AV_PIX_FMT_NE(YUV444F32BE,  YUV444F32LE)
+#define AV_PIX_FMT_YUVA444F32 AV_PIX_FMT_NE(YUVA444F32BE, YUVA444F32LE)
 
 #define AV_PIX_FMT_YUVA420P9  AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
 #define AV_PIX_FMT_YUVA422P9  AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 17c996734a..892b219049 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -254,6 +254,10 @@ 

[FFmpeg-devel] [PATCH 5/5] Add tonemap filter

[Vittorio Giovara]

Based off mpv automatic tonemapping capabilities.

Signed-off-by: Vittorio Giovara 
---
TODO: version bump, changelog entry.

Thanks to Niklas Haas for mentoring me during the development
of this filter.
Vittorio

 doc/filters.texi | 101 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_tonemap.c | 307 +++
 4 files changed, 410 insertions(+)
 create mode 100644 libavfilter/vf_tonemap.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 930ca4cfab..b297730288 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14295,6 +14295,107 @@ Vertical low-pass filtering can only be enabled for 
@option{mode}
 
 @end table
 
+@section tonemap
+Tone map colors from different dynamic ranges.
+
+This filter expects data in single precision floating point, as it needs to
+operate on (and can output) out-of-range values. Another filter, such as
+@ref{zscale}, is needed to convert the resulting frame to a usable format.
+
+The tonemapping algorithms implemented only work on linear light, so input
+data should be linearized beforehand (and possibly correctly tagged).
+
+@example
+ffmpeg -i INPUT -vf 
zscale=transfer=linear,tonemap=clip,zscale=transfer=bt709,format=yuv420p OUTPUT
+@end example
+
+@subsection Options
+The filter accepts the following options.
+
+@table @option
+@item tonemap
+Set the tone map algorithm to use.
+
+Possible values are:
+@table @var
+@item none
+Do not apply any tone map.
+
+@item clip
+Hard-clip any out-of-range values. Use it for perfect color accuracy for
+in-range values, while distorting out-of-range values.
+
+@item linear
+Stretch the entire reference gamut to a linear multiple of the display.
+
+@item gamma
+Fit a logarithmic transfer between the tone curves.
+
+@item reinhard
+Preserve overall image brightness with a simple curve, using nonlinear
+contrast, which results in flattening details and degrading color accuracy.
+
+@item hable
+Peserve both dark and bright details better than @ref{reinhard}, at the cost
+of slightly darkening everything. Use it when detail preservation is more
+important than color and brightness accuracy.
+
+@item mobius
+Smoothly map out-of-range values, while retaining contrast and colors for
+in-range material as much as possible. Use it when color accuracy is more
+important than detail preservation.
+@end table
+
+Default is none.
+
+@item param
+Tune the tone mapping algorithm.
+
+This affects the following algorithms:
+@table @var
+@item linear
+Specifies the scale factor to use while stretching.
+Default to 1.0.
+
+@item gamma
+Specifies the exponent of the function.
+Default to 1.8.
+
+@item clip
+Specify an extra linear coefficient to multiply into the signal before 
clipping.
+Default to 1.0.
+
+@item reinhard
+Specify the local contrast coefficient at the display peak.
+Default to 0.5, which means that in-gamut values will be about half as bright
+as when clipping.
+
+@item hable
+Ignored.
+
+@item mobius
+Specify the transition point from linear to mobius transform. Every value
+below this point is guaranteed to be mapped 1:1. The higher the value, the
+more accurate the result will be, at the cost of losing bright details.
+Default to 0.3, which due to the steep initial slope still preserves in-range
+colors fairly accurately.
+@end table
+
+@item strength
+Apply desaturation for highlights that exceed this level of brightness. The
+higher the parameter, the more color information will be preserved. This
+setting helps prevent unnaturally blown-out colors for super-highlights, by
+(smoothly) turning into white instead. This makes images feel more natural,
+at the cost of reducing information about out-of-range colors.
+
+The default of 2.0 is somewhat conservative and will mostly just apply to
+skies or directly sunlit surfaces. A setting of 0.0 disables this option.
+
+@item peak
+Override signal/nominal/reference peak with this value. Useful when the
+embedded peak information in display metadata is not reliable or when tone
+mapping from a lower range to a higher range.
+
 @section transpose
 
 Transpose rows with columns in the input video and optionally flip it.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f023a0d5d6..0ada5d77b5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -310,6 +310,7 @@ OBJS-$(CONFIG_THRESHOLD_FILTER)  += 
vf_threshold.o
 OBJS-$(CONFIG_THUMBNAIL_FILTER)  += vf_thumbnail.o
 OBJS-$(CONFIG_TILE_FILTER)   += vf_tile.o
 OBJS-$(CONFIG_TINTERLACE_FILTER) += vf_tinterlace.o
+OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
 OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
 OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
 OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 

[FFmpeg-devel] [PATCH 4/5] zscale: Enable single precision input/ouput filtering

[Vittorio Giovara]

---
 libavfilter/vf_zscale.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 466689dbc5..d96edb3ade 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -179,6 +179,7 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
 AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
 AV_PIX_FMT_GBRAP, AV_PIX_FMT_GBRAP16,
+AV_PIX_FMT_YUV444F32, AV_PIX_FMT_YUVA444F32,
 AV_PIX_FMT_NONE
 };
 int ret;
@@ -429,7 +430,7 @@ static void format_init(zimg_image_format *format, AVFrame 
*frame, const AVPixFm
 format->subsample_w = desc->log2_chroma_w;
 format->subsample_h = desc->log2_chroma_h;
 format->depth = desc->comp[0].depth;
-format->pixel_type = desc->comp[0].depth > 8 ? ZIMG_PIXEL_WORD : 
ZIMG_PIXEL_BYTE;
+format->pixel_type = (desc->flags & AV_PIX_FMT_FLAG_FLOAT) ? 
ZIMG_PIXEL_FLOAT : desc->comp[0].depth > 8 ? ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
 format->color_family = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_COLOR_RGB : ZIMG_COLOR_YUV;
 format->matrix_coefficients = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_MATRIX_RGB : colorspace == -1 ? convert_matrix(frame->colorspace) : 
colorspace;
 format->color_primaries = primaries == -1 ? 
convert_primaries(frame->color_primaries) : primaries;
@@ -573,13 +574,13 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 s->alpha_src_format.width = in->width;
 s->alpha_src_format.height = in->height;
 s->alpha_src_format.depth = desc->comp[0].depth;
-s->alpha_src_format.pixel_type = desc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
+s->alpha_src_format.pixel_type = (desc->flags & 
AV_PIX_FMT_FLAG_FLOAT) ? ZIMG_PIXEL_FLOAT : desc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
 s->alpha_src_format.color_family = ZIMG_COLOR_GREY;
 
 s->alpha_dst_format.width = out->width;
 s->alpha_dst_format.height = out->height;
 s->alpha_dst_format.depth = odesc->comp[0].depth;
-s->alpha_dst_format.pixel_type = odesc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
+s->alpha_dst_format.pixel_type = (desc->flags & 
AV_PIX_FMT_FLAG_FLOAT) ? ZIMG_PIXEL_FLOAT : odesc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
 s->alpha_dst_format.color_family = ZIMG_COLOR_GREY;
 
 zimg_filter_graph_free(s->alpha_graph);
-- 
2.13.2

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

[FFmpeg-devel] [PATCH 2/5] zscale: Factor out format initialization

[Vittorio Giovara]

---
 libavfilter/vf_zscale.c | 46 +-
 1 file changed, 21 insertions(+), 25 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index d7b1612f3c..a128db6267 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -421,6 +421,23 @@ static int convert_range(enum AVColorRange color_range)
 return ZIMG_RANGE_LIMITED;
 }
 
+static void format_init(zimg_image_format *format, AVFrame *frame, const 
AVPixFmtDescriptor *desc,
+int colorspace, int primaries, int transfer, int 
range, int location)
+{
+format->width = frame->width;
+format->height = frame->height;
+format->subsample_w = desc->log2_chroma_w;
+format->subsample_h = desc->log2_chroma_h;
+format->depth = desc->comp[0].depth;
+format->pixel_type = desc->comp[0].depth > 8 ? ZIMG_PIXEL_WORD : 
ZIMG_PIXEL_BYTE;
+format->color_family = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_COLOR_RGB : ZIMG_COLOR_YUV;
+format->matrix_coefficients = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_MATRIX_RGB : colorspace == -1 ? convert_matrix(frame->colorspace) : 
colorspace;
+format->color_primaries = primaries == -1 ? 
convert_primaries(frame->color_primaries) : primaries;
+format->transfer_characteristics = transfer == - 1 ? 
convert_trc(frame->color_trc) : transfer;
+format->pixel_range = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_RANGE_FULL : range == -1 ? convert_range(frame->color_range) : range;
+format->chroma_location = location == -1 ? 
convert_chroma_location(frame->chroma_location) : location;
+}
+
 static int filter_frame(AVFilterLink *link, AVFrame *in)
 {
 ZScaleContext *s = link->dst->priv;
@@ -483,31 +500,10 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 s->params.nominal_peak_luminance = s->nominal_peak_luminance;
 s->params.allow_approximate_gamma = s->approximate_gamma;
 
-s->src_format.width = in->width;
-s->src_format.height = in->height;
-s->src_format.subsample_w = desc->log2_chroma_w;
-s->src_format.subsample_h = desc->log2_chroma_h;
-s->src_format.depth = desc->comp[0].depth;
-s->src_format.pixel_type = desc->comp[0].depth > 8 ? ZIMG_PIXEL_WORD : 
ZIMG_PIXEL_BYTE;
-s->src_format.color_family = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_COLOR_RGB : ZIMG_COLOR_YUV;
-s->src_format.matrix_coefficients = (desc->flags & 
AV_PIX_FMT_FLAG_RGB) ? ZIMG_MATRIX_RGB : s->colorspace_in == -1 ? 
convert_matrix(in->colorspace) : s->colorspace_in;
-s->src_format.transfer_characteristics = s->trc_in == - 1 ? 
convert_trc(in->color_trc) : s->trc_in;
-s->src_format.color_primaries = s->primaries_in == -1 ? 
convert_primaries(in->color_primaries) : s->primaries_in;
-s->src_format.pixel_range = (desc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_RANGE_FULL : s->range_in == -1 ? convert_range(in->color_range) : 
s->range_in;
-s->src_format.chroma_location = s->chromal_in == -1 ? 
convert_chroma_location(in->chroma_location) : s->chromal_in;
-
-s->dst_format.width = out->width;
-s->dst_format.height = out->height;
-s->dst_format.subsample_w = odesc->log2_chroma_w;
-s->dst_format.subsample_h = odesc->log2_chroma_h;
-s->dst_format.depth = odesc->comp[0].depth;
-s->dst_format.pixel_type = odesc->comp[0].depth > 8 ? ZIMG_PIXEL_WORD 
: ZIMG_PIXEL_BYTE;
-s->dst_format.color_family = (odesc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_COLOR_RGB : ZIMG_COLOR_YUV;
-s->dst_format.matrix_coefficients = (odesc->flags & 
AV_PIX_FMT_FLAG_RGB) ? ZIMG_MATRIX_RGB : s->colorspace == -1 ? 
convert_matrix(out->colorspace) : s->colorspace;
-s->dst_format.transfer_characteristics = s->trc == -1 ? 
convert_trc(out->color_trc) : s->trc;
-s->dst_format.color_primaries = s->primaries == -1 ? 
convert_primaries(out->color_primaries) : s->primaries;
-s->dst_format.pixel_range = (odesc->flags & AV_PIX_FMT_FLAG_RGB) ? 
ZIMG_RANGE_FULL : s->range == -1 ? convert_range(out->color_range) : s->range;
-s->dst_format.chroma_location = s->chromal == -1 ? 
convert_chroma_location(out->chroma_location) : s->chromal;
+format_init(>src_format, in, desc, s->colorspace_in,
+s->primaries_in, s->trc_in, s->range_in, s->chromal_in);
+format_init(>dst_format, out, odesc, s->colorspace,
+s->primaries, s->trc, s->range, s->chromal);
 
 if (s->colorspace != -1)
 out->colorspace = (int)s->dst_format.matrix_coefficients;
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I believe your approach is fine.

The huge duplication between decoder and demuxer is definitely not fine.
You need to find a solution before pushing anything.

Regards,

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/16/17, Paras Chadha  wrote:
> On Sun, Jul 16, 2017 at 10:06 PM, Paul B Mahol  wrote:
>
>> Can you give link to file which holds more than one FITS image?
>>
>
> Yes, here is the file: https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.
> fits
>

I believe your approach is fine. There could not be parser as format
does not allow that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] nvenc : Add P016 support

[Timo Rothenpieler]

Am 18.07.2017 um 13:24 schrieb Yogender Gupta:

Add P016 support to NVENC.

Thanks,
Yogender


All three patches look fine to me in general.
I vaguely remember there being some reason for P016 being missing so 
far, but it might be long fixed.


I'm not at home and can't really push patches from here.
If someone(philipl?) remembers if there was any particular issue, or if 
it's fine by now, it's a LGTM from me!

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: fix alpha blending when main source has an alpha channel

[Michael Niedermayer]

On Sun, Jul 16, 2017 at 08:26:57PM +0200, Peter Große wrote:
> On Sun, 16 Jul 2017 18:33:33 +0200
> Paul B Mahol  wrote:
> 
> > 
> > how can one reproduce this bug?
> 
> ffmpeg -i fate-suite/mfx/track_01_v02.mxf -filter_complex \
> "movie=fate-suite/png1/lena-rgba.png[logo];[v:0][logo]overlay" -an -vframes 1 
> out.png
> 
> In this example files from the fate suite are used.
> 
> The source mxf file actually doesn't have an alpha channel, but the 
> autoscaler adds one on adapting pixel formats:
> 
> [auto_scaler_0 @ 0x2118440] w:1280 h:720 fmt:yuv422p sar:1/1 -> w:1280 h:720 
> fmt:yuva420p sar:1/1 flags:0x2
> 
> As seen here [1] the png file has a almost zero alpha value on the left side, 
> but the output is way too bright without the patch.
> 
> I hope this helps.
> 
> Regards
> Peter
> 
> [1] http://imgur.com/a/74ZF4

please also add a fate test for this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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

[FFmpeg-devel] [Patch] nvenc : Add P016 support

[Yogender Gupta]

Add P016 support to NVENC.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0003-nvenc-Add-P016-support.patch
Description: 0003-nvenc-Add-P016-support.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] hwcontext_cuda : Support YUV444P16 format

[Yogender Gupta]

Added yuv444p16 to hwcontext_cuda.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0002-hwcontext_cuda-Support-YUV444P16-format.patch
Description: 0002-hwcontext_cuda-Support-YUV444P16-format.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hwupload_cuda : Add 10/16 bit format support

[Yogender Gupta]

Added 10/16bit formats to hwupload_cuda.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-hwupload_cuda-Add-10-16-bit-format-support.patch
Description: 0001-hwupload_cuda-Add-10-16-bit-format-support.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Read resolution box from jp2 files

[Carl Eugen Hoyos]

2017-05-02 16:29 GMT+02:00 Carl Eugen Hoyos :

> New, fixed patch attached.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: add -(no)find_stream_info expert option

[Clément Bœsch]

On Wed, Jul 12, 2017 at 05:30:04PM +0200, Clément Bœsch wrote:
> On Wed, Jul 12, 2017 at 05:14:14PM +0200, Nicolas George wrote:
> > Le quartidi 24 messidor, an CCXXV, Clement Boesch a écrit :
> > > ---
> > >  ffmpeg_opt.c | 22 +-
> > >  1 file changed, 13 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> > > index 9b7e8c74b9..10ca260648 100644
> > > --- a/ffmpeg_opt.c
> > > +++ b/ffmpeg_opt.c
> > > @@ -145,6 +145,7 @@ static int override_ffserver  = 0;
> > >  static int input_stream_potentially_available = 0;
> > >  static int ignore_unknown_streams = 0;
> > >  static int copy_unknown_streams = 0;
> > > +static int find_stream_info = 1;
> > 
> > > +{ "find_stream_info", OPT_BOOL | OPT_INPUT | OPT_EXPERT, { 
> > > _stream_info },
> > > +"read and decode the streams to fill missing information with 
> > > heuristics" },
> > >  
> > >  /* video options */
> > >  { "vframes",  OPT_VIDEO | HAS_ARG  | OPT_PERFILE | OPT_OUTPUT,   
> > > { .func_arg = opt_video_frames },
> > 
> > Should it not be implemented for OPT_PERFILE?
> > 
> 
> Yeah, I guess so. Fixed locally. Also changed in ffplay and ffprobe, even
> thought it doesn't make much sense "yet".
> 

Actually only done for ffmpeg to be safe.

Patchset applied, thanks

-- 
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 v2] avutil: merge slice threading implementation from avcodec and avfilter

[Muhammad Faiz]

On Wed, Jul 12, 2017 at 8:44 PM, Muhammad Faiz  wrote:
> Rework it to improve performance. Now mutex is not shared by workers,
> instead each worker has its own mutex and condition variable. This
> reduces lock contention between workers. Also use atomic variable for
> counter.
>
> The interface also allows execute to run special function on main
> thread, requested by Ronald.
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavutil/Makefile  |   1 +
>  libavutil/slicethread.c | 259 
> 
>  libavutil/slicethread.h |  52 ++
>  3 files changed, 312 insertions(+)
>  create mode 100644 libavutil/slicethread.c
>  create mode 100644 libavutil/slicethread.h
>

I'm going to push the patchset tomorrow.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Remove duplicate slice_segment_address.

[Steven Liu]

2017-07-18 12:08 GMT+08:00 Jun Zhao :
>

From ee094ddd0fedecc81ee0107df58fc0ec80369c13 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 18 Jul 2017 00:01:09 -0400
Subject: [PATCH] lavc/vaapi_encode_h265: Remove duplicate
 slice_segment_address.

the VAEncSliceParameterBufferHEVC in libva have support this field,
so remove the duplicate field in VAAPIEncodeH265MiscSliceParams.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h265.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 1d648a6d87..cf6b9388d1 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -149,7 +149,6 @@ typedef struct VAAPIEncodeH265MiscSequenceParams {
 typedef struct VAAPIEncodeH265MiscSliceParams {
 // Slice segments.
 char first_slice_segment_in_pic_flag;
-unsigned int slice_segment_address;

 // Short-term reference picture sets.
 char short_term_ref_pic_set_sps_flag;
@@ -586,7 +585,7 @@ static void
vaapi_encode_h265_write_slice_header2(PutBitContext *pbc,
 if (vpic->pic_fields.bits.dependent_slice_segments_enabled_flag)
 u(1, vslice_field(dependent_slice_segment_flag));
 u(av_log2((priv->ctu_width * priv->ctu_height) - 1) + 1,
-  mslice_var(slice_segment_address));
+  vslice_var(slice_segment_address));
 }
 if (!vslice->slice_fields.bits.dependent_slice_segment_flag) {
 for (i = 0; i < mseq->num_extra_slice_header_bits; i++)
-- 
2.11.0

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



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