Re: [FFmpeg-devel] [PATCH] libvmaf: exit gracefully if the library fails.

[Gyan Doshi]

On 12/9/2017 7:05 AM, Ronald S. Bultje wrote:

Fixes trac issue #6884 and Netflix/vmaf issue #124.



  static void *call_vmaf(void *ctx)
  {

>   ...

  pthread_exit(NULL);
  }


Fails to build unless I add  'return NULL;'  in call_vmaf. Pre-existing 
issue. Open ticket is #6878.


Is it possible to have distinctive error messages? I get the same 
message whether the model is not found or found but not successfully 
parsed. Pasted below. Earlier, the console would have the exception 
reporting if "No newline at end o string". The error for missing file 
was generic, like now.



t C:\avutils\ffmpeg-libs\compiled\share\model\nflxtrain_vmfv3a.pkl 
cannot be read successfully.
Caught VmafException: Error loading model (.pkl): Trouble reading the 
file:C:\avutils\ffmpeg-libs\compiled\share\model\nflxtrain_vmfv3a.pkl
[Parsed_libvmaf_0 @ 0050b4a0] libvmaf encountered an error, 
check log for details

Error while filtering: Invalid argument
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #1:0
Conversion failed!


But no more "This application has requested the Runtime to terminate it 
in an unusual way.". Thanks.


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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: add flag to discard timestamps on corrupted frames

[Rodger Combs]

> On Dec 8, 2017, at 11:06, Michael Niedermayer  wrote:
> 
> On Thu, Dec 07, 2017 at 10:23:15PM -0600, Rodger Combs wrote:
>> ---
>> libavformat/avformat.h  | 1 +
>> libavformat/options_table.h | 1 +
>> libavformat/utils.c | 8 
>> 3 files changed, 10 insertions(+)
>> 
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index 4f2798a871..d10d583dff 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
>> #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate 
>> seeks for some formats
>> #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
>> stream stops.
>> #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as 
>> requested by the muxer
>> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
>> frames marked corrupt
>> 
>> /**
>>  * Maximum size of the data read from input for determining
>> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
>> index b8fa47c6fd..515574d3e0 100644
>> --- a/libavformat/options_table.h
>> +++ b/libavformat/options_table.h
>> @@ -58,6 +58,7 @@ static const AVOption avformat_options[] = {
>> {"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { 
>> .i64 = AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
>> {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, { 
>> .i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
>> {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 = 
>> AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
>> +{"discardcorruptts", "discard timestamps on corrupted frames", 0, 
>> AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E, 
>> "fflags" },
>> {"analyzeduration", "specify how many microseconds are analyzed to probe the 
>> input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, 
>> INT64_MAX, D},
>> {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0}, 
>> 0, 0, D},
>> {"indexmem", "max memory used for timestamp index (per stream)", 
>> OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 84e49208b8..98af941e9f 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
> 
>> @@ -873,6 +873,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>> st->cur_dts = wrap_timestamp(st, st->cur_dts);
>> }
>> 
>> +if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS) &&
>> +(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
>> +pkt->pts = pkt->dts = AV_NOPTS_VALUE;
>> +av_log(s, AV_LOG_WARNING,
>> +   "Discarded timestamp on corrupted packet (stream = 
>> %d)\n",
>> +   pkt->stream_index);
>> +}
> 
> how many of the cases that set AV_PKT_FLAG_CORRUPT can even be due to
> the timestamp ?

Pretty much just the new TEI check, or potentially other CRC checks. I don't 
_think_ the continuity-counter check failing could indicate an incorrect 
timestamp. I suppose we could add a second flag just for corruption that could 
affect timestamps?

> 
> We set this for truncated / EOF cases and all kinds of stuff that
> are known to be unrelated to the timestamps
> 
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] lavf/matroskadec: resync if cluster parsing fails while seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 496499b553..b51f67af00 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3528,9 +3528,13 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
   SEEK_SET);
 matroska->current_id = 0;
 while ((index = av_index_search_timestamp(st, timestamp, flags)) < 0 
|| index == st->nb_index_entries - 1) {
+int ret;
+int64_t pos = avio_tell(matroska->ctx->pb);
 matroska_clear_queue(matroska);
-if (matroska_parse_cluster(matroska) < 0)
-break;
+if ((ret = matroska_parse_cluster(matroska)) < 0) {
+if ((ret == AVERROR_EOF) || matroska_resync(matroska, pos) < 0)
+break;
+}
 }
 }
 
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 2/3] lavf/matroskadec: fallback to generic seeking if resyncing fails while seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b51f67af00..944ed795d5 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3532,8 +3532,12 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 int64_t pos = avio_tell(matroska->ctx->pb);
 matroska_clear_queue(matroska);
 if ((ret = matroska_parse_cluster(matroska)) < 0) {
-if ((ret == AVERROR_EOF) || matroska_resync(matroska, pos) < 0)
+if (ret == AVERROR_EOF) {
 break;
+} else if(matroska_resync(matroska, pos) < 0) {
+index = -1;
+break;
+}
 }
 }
 }
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 3/3] lavf/matroskadec: log when falling back to generic seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 944ed795d5..fb1a27f4a8 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3570,6 +3570,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 ff_update_cur_dts(s, st, st->index_entries[index].timestamp);
 return 0;
 err:
+av_log(s, AV_LOG_VERBOSE, "Failed to seek using index; falling back to 
generic seek");
 // slightly hackish but allows proper fallback to
 // the generic seeking code.
 matroska_clear_queue(matroska);
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: steps to ditch YUVJ formats

[Rostislav Pehlivanov]

On 8 December 2017 at 20:48, Michael Niedermayer 
wrote:

> On Fri, Dec 08, 2017 at 12:12:57PM +0100, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  fftools/ffmpeg.c |  1 +
> >  fftools/ffmpeg.h |  2 ++
> >  fftools/ffmpeg_filter.c  | 18 +++---
> >  libavcodec/avcodec.h |  1 +
> >  libavcodec/utils.c   |  2 ++
> >  libavfilter/avfilter.c   |  2 ++
> >  libavfilter/avfilter.h   |  2 ++
> >  libavfilter/buffersink.c |  1 +
> >  libavfilter/buffersink.h |  1 +
> >  libavfilter/buffersrc.c  | 13 +
> >  libavfilter/buffersrc.h  |  5 +
> >  libavfilter/vf_scale.c   |  9 +
> >  libavfilter/video.c  |  8 +++-
> >  13 files changed, 61 insertions(+), 4 deletions(-)
>
> as a more general comment,
> If doing all this across all libs is too hard, doing one lib at a
> time could be easier.
>
> That is fully support color_range without yuvj in a lib while
> providing support for deprecated yuvj formats.
>
>
There's no point in keeping them. We're still in the middle of the bump and
if we have to we'll delay the bump until the YUVJ stuff is gone.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libvmaf: exit gracefully if the library fails.

[Ronald S. Bultje]

Fixes trac issue #6884 and Netflix/vmaf issue #124.
---
 libavfilter/vf_libvmaf.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
index 7670c51..d628b95 100644
--- a/libavfilter/vf_libvmaf.c
+++ b/libavfilter/vf_libvmaf.c
@@ -61,6 +61,7 @@ typedef struct LIBVMAFContext {
 int ssim;
 int ms_ssim;
 char *pool;
+int error;
 } LIBVMAFContext;
 
 #define OFFSET(x) offsetof(LIBVMAFContext, x)
@@ -158,17 +159,24 @@ static void compute_vmaf_score(LIBVMAFContext *s)
 
 format = (char *) s->desc->name;
 
-s->vmaf_score = compute_vmaf(format, s->width, s->height, read_frame, s,
- s->model_path, s->log_path, s->log_fmt, 0, 0,
- s->enable_transform, s->phone_model, s->psnr,
- s->ssim, s->ms_ssim, s->pool);
+s->error = compute_vmaf(>vmaf_score, format, s->width, s->height,
+read_frame, s, s->model_path, s->log_path,
+s->log_fmt, 0, 0, s->enable_transform,
+s->phone_model, s->psnr, s->ssim,
+s->ms_ssim, s->pool);
 }
 
 static void *call_vmaf(void *ctx)
 {
 LIBVMAFContext *s = (LIBVMAFContext *) ctx;
 compute_vmaf_score(s);
-av_log(ctx, AV_LOG_INFO, "VMAF score: %f\n",s->vmaf_score);
+if (!s->error) {
+av_log(ctx, AV_LOG_INFO, "VMAF score: %f\n",s->vmaf_score);
+} else {
+pthread_mutex_lock(>lock);
+pthread_cond_signal(>cond);
+pthread_mutex_unlock(>lock);
+}
 pthread_exit(NULL);
 }
 
@@ -187,10 +195,17 @@ static int do_vmaf(FFFrameSync *fs)
 
 pthread_mutex_lock(>lock);
 
-while (s->frame_set != 0) {
+while (s->frame_set && !s->error) {
 pthread_cond_wait(>cond, >lock);
 }
 
+if (s->error) {
+av_log(ctx, AV_LOG_ERROR,
+   "libvmaf encountered an error, check log for details\n");
+pthread_mutex_unlock(>lock);
+return AVERROR(EINVAL);
+}
+
 av_frame_ref(s->gref, ref);
 av_frame_ref(s->gmain, main);
 
@@ -208,6 +223,7 @@ static av_cold int init(AVFilterContext *ctx)
 
 s->gref = av_frame_alloc();
 s->gmain = av_frame_alloc();
+s->error = 0;
 
 pthread_mutex_init(>lock, NULL);
 pthread_cond_init (>cond, NULL);
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/matroskadec: fallback to generic seeking if resyncing fails while seeking

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 06:45:35AM -0600, Rodger Combs wrote:
> ---
>  libavformat/matroskadec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

breaks fate-seek-mkv-codec-delay


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

[FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android

[James Almer]

Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
messages is "Offset out of range". The reason of the error is assembler LDR
directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage
in range <1k, but no such storage provided.

Based on a patch by Ihor Bobalo 

Suggested-by: wbs
Signed-off-by: James Almer 
---
This solution prevents increasing the diff of functions shared with
libav and thus makes future merges easier.

Untested.

 libavcodec/arm/hevcdsp_idct_neon.S | 119 +++--
 1 file changed, 60 insertions(+), 59 deletions(-)

diff --git a/libavcodec/arm/hevcdsp_idct_neon.S 
b/libavcodec/arm/hevcdsp_idct_neon.S
index 139029a256..75795e6a6a 100644
--- a/libavcodec/arm/hevcdsp_idct_neon.S
+++ b/libavcodec/arm/hevcdsp_idct_neon.S
@@ -229,65 +229,6 @@ function ff_hevc_add_residual_32x32_10_neon, export=1
 bx  lr
 endfunc
 
-/* uses registers q2 - q9 for temp values */
-/* TODO: reorder */
-.macro tr4_luma_shift r0, r1, r2, r3, shift
-vaddl.s16   q5, \r0, \r2// c0 = src0 + src2
-vaddl.s16   q2, \r2, \r3// c1 = src2 + src3
-vsubl.s16   q4, \r0, \r3// c2 = src0 - src3
-vmull.s16   q6, \r1, d0[0]  // c3 = 74 * src1
-
-vaddl.s16   q7, \r0, \r3// src0 + src3
-vsubw.s16   q7, q7, \r2 // src0 - src2 + src3
-vmul.s32q7, q7, d0[0]   // dst2 = 74 * (src0 - src2 + src3)
-
-vmul.s32q8, q5, d0[1]   // 29 * c0
-vmul.s32q9, q2, d1[0]   // 55 * c1
-vadd.s32q8, q9  // 29 * c0 + 55 * c1
-vadd.s32q8, q6  // dst0 = 29 * c0 + 55 * c1 + c3
-
-vmul.s32q2, q2, d0[1]   // 29 * c1
-vmul.s32q9, q4, d1[0]   // 55 * c2
-vsub.s32q9, q2  // 55 * c2 - 29 * c1
-vadd.s32q9, q6  // dst1 = 55 * c2 - 29 * c1 + c3
-
-vmul.s32q5, q5, d1[0]   // 55 * c0
-vmul.s32q4, q4, d0[1]   // 29 * c2
-vadd.s32q5, q4  // 55 * c0 + 29 * c2
-vsub.s32q5, q6  // dst3 = 55 * c0 + 29 * c2 - c3
-
-vqrshrn.s32   \r0, q8, \shift
-vqrshrn.s32   \r1, q9, \shift
-vqrshrn.s32   \r2, q7, \shift
-vqrshrn.s32   \r3, q5, \shift
-.endm
-
-function ff_hevc_transform_luma_4x4_neon_8, export=1
-vpush   {d8-d15}
-vld1.16 {q14, q15}, [r0]  // coeffs
-ldr r3, =0x4a  // 74
-vmov.32 d0[0], r3
-ldr r3, =0x1d  // 29
-vmov.32 d0[1], r3
-ldr r3, =0x37  // 55
-vmov.32 d1[0], r3
-
-tr4_luma_shift d28, d29, d30, d31, #7
-
-vtrn.16 d28, d29
-vtrn.16 d30, d31
-vtrn.32 q14, q15
-
-tr4_luma_shift d28, d29, d30, d31, #12
-
-vtrn.16 d28, d29
-vtrn.16 d30, d31
-vtrn.32 q14, q15
-vst1.16 {q14, q15}, [r0]
-vpop{d8-d15}
-bx lr
-endfunc
-
 .macro idct_4x4_dc bitdepth
 function ff_hevc_idct_4x4_dc_\bitdepth\()_neon, export=1
 ldrsh   r1, [r0]
@@ -1040,3 +981,63 @@ idct_32x32 8
 idct_32x32_dc 8
 idct_32x32 10
 idct_32x32_dc 10
+
+/* uses registers q2 - q9 for temp values */
+/* TODO: reorder */
+.macro tr4_luma_shift r0, r1, r2, r3, shift
+vaddl.s16   q5, \r0, \r2// c0 = src0 + src2
+vaddl.s16   q2, \r2, \r3// c1 = src2 + src3
+vsubl.s16   q4, \r0, \r3// c2 = src0 - src3
+vmull.s16   q6, \r1, d0[0]  // c3 = 74 * src1
+
+vaddl.s16   q7, \r0, \r3// src0 + src3
+vsubw.s16   q7, q7, \r2 // src0 - src2 + src3
+vmul.s32q7, q7, d0[0]   // dst2 = 74 * (src0 - src2 + src3)
+
+vmul.s32q8, q5, d0[1]   // 29 * c0
+vmul.s32q9, q2, d1[0]   // 55 * c1
+vadd.s32q8, q9  // 29 * c0 + 55 * c1
+vadd.s32q8, q6  // dst0 = 29 * c0 + 55 * c1 + c3
+
+vmul.s32q2, q2, d0[1]   // 29 * c1
+vmul.s32q9, q4, d1[0]   // 55 * c2
+vsub.s32q9, q2  // 55 * c2 - 29 * c1
+vadd.s32q9, q6  // dst1 = 55 * c2 - 29 * c1 + c3
+
+vmul.s32q5, q5, d1[0]   // 55 * c0
+vmul.s32q4, q4, d0[1]   // 29 * c2
+vadd.s32q5, q4  // 55 * c0 + 29 * c2
+vsub.s32q5, q6  // dst3 = 55 * c0 + 29 * c2 - c3
+
+vqrshrn.s32   \r0, q8, \shift
+vqrshrn.s32   \r1, q9, \shift
+vqrshrn.s32   \r2, q7, \shift
+vqrshrn.s32   \r3, q5, \shift
+.endm
+
+.ltorg
+function ff_hevc_transform_luma_4x4_neon_8, export=1
+vpush   {d8-d15}
+vld1.16 {q14, q15}, [r0]  // coeffs
+ldr r3, =0x4a  // 74
+vmov.32 d0[0], r3
+ldr r3, =0x1d  // 29
+vmov.32 d0[1], r3
+ldr   

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: steps to ditch YUVJ formats

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 12:12:57PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  fftools/ffmpeg.c |  1 +
>  fftools/ffmpeg.h |  2 ++
>  fftools/ffmpeg_filter.c  | 18 +++---
>  libavcodec/avcodec.h |  1 +
>  libavcodec/utils.c   |  2 ++
>  libavfilter/avfilter.c   |  2 ++
>  libavfilter/avfilter.h   |  2 ++
>  libavfilter/buffersink.c |  1 +
>  libavfilter/buffersink.h |  1 +
>  libavfilter/buffersrc.c  | 13 +
>  libavfilter/buffersrc.h  |  5 +
>  libavfilter/vf_scale.c   |  9 +
>  libavfilter/video.c  |  8 +++-
>  13 files changed, 61 insertions(+), 4 deletions(-)

as a more general comment,
If doing all this across all libs is too hard, doing one lib at a
time could be easier.

That is fully support color_range without yuvj in a lib while
providing support for deprecated yuvj formats.

that lib could be tested by some hack that intercepts yuvj and translates
it to color_range, such hack would of course not be commited

then do the next lib

just a random idea, if it simplifies something that would be great,
if not just ignore this mail

thx

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: steps to ditch YUVJ formats

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 12:12:57PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  fftools/ffmpeg.c |  1 +
>  fftools/ffmpeg.h |  2 ++
>  fftools/ffmpeg_filter.c  | 18 +++---
>  libavcodec/avcodec.h |  1 +
>  libavcodec/utils.c   |  2 ++
>  libavfilter/avfilter.c   |  2 ++
>  libavfilter/avfilter.h   |  2 ++
>  libavfilter/buffersink.c |  1 +
>  libavfilter/buffersink.h |  1 +
>  libavfilter/buffersrc.c  | 13 +
>  libavfilter/buffersrc.h  |  5 +
>  libavfilter/vf_scale.c   |  9 +
>  libavfilter/video.c  |  8 +++-
>  13 files changed, 61 insertions(+), 4 deletions(-)
[...]

> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..4ff5fe8aa1 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>  uint8_t max_lowres; ///< maximum value for lowres 
> supported by the decoder
>  const AVClass *priv_class;  ///< AVClass for the private 
> context
>  const AVProfile *profiles;  ///< array of recognized 
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +const int color_range;  ///< value of color range 
> encoder supports, 0 if all is supported
>  
>  /*
>   * No fields below this line are part of the public API. They

Looking just at libavcodec (i didnt look indepth at the rest)

the API looks ok i think

an alternative may be a list similar to others that lists supported
ranges and we would have differen values for 8bit and 10bit full and
subset ranges. That way codecs could list support for one without the
other. But that may be overkill 


> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..aa81c21ef3 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
>  avctx->color_range = AVCOL_RANGE_JPEG;
>  }
> +if (avctx->codec->color_range)
> +avctx->color_range = avctx->codec->color_range;
>  if (avctx->codec->supported_samplerates) {
>  for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
>  if (avctx->sample_rate == 
> avctx->codec->supported_samplerates[i])

If the user did set a avctx->color_range for an encoder then this
should warn and or fail if its unsupported instead of overriding
at least at higher strict_std_compliance

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 12:12:58PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/mjpegdec.c| 18 +-
>  libavcodec/mjpegenc.c|  6 --
>  libavcodec/mjpegenc_common.c |  5 +
>  tests/fate/vcodec.mak| 21 ++---
>  4 files changed, 28 insertions(+), 22 deletions(-)

This breaks a bunch of fate tests

make: *** [fate-vsynth1-ljpeg] Error 1
make: *** [fate-vsynth3-ljpeg] Error 1
make: *** [fate-vsynth_lena-ljpeg] Error 1
make: *** [fate-tdsc] Error 1
make: *** [fate-filter-owdenoise-sample] Error 1
make: *** [fate-vsynth2-ljpeg] Error 1
make: *** [fate-api-mjpeg-codec-param] Error 1
make: *** [fate-exif-image-jpg] Error 1
make: *** [fate-exif-image-embedded] Error 1

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 01:25:16PM +0100, Marton Balint wrote:
> 
> 
> On Fri, 8 Dec 2017, wm4 wrote:
> 
> >On Fri, 8 Dec 2017 06:52:20 +0100
> >Michael Niedermayer  wrote:
> >
> >>On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> >>> On 12/8/2017 12:26 AM, wm4 wrote: > > On Thu, 7 Dec 2017
> >>23:23:51 +0100
> >>> > Michael Niedermayer  wrote:
> >>> > > >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael
> >>Niedermayer wrote: > >>> On Sat, Nov 18, 2017 at 09:11:17PM
> >>+0100, Michael Niedermayer wrote: >  On Sat, Nov 18, 2017 at
> >>09:50:33AM +0100, Hendrik Leppkes wrote: > > On Sat, Nov 18,
> >>2017 at 3:05 AM, Michael Niedermayer
> >>> >  wrote: > >> On Fri, Nov 17,
> >>2017 at 09:55:47AM +0100, Hendrik Leppkes wrote: > >>> On
> >>Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>> >>>  wrote: >  On Thu, Nov
> >>16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote: >
> >>> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer
> >>: > >> On Thu, Nov 16, 2017 at
> >>01:04:27AM +0100, Carl Eugen Hoyos wrote: > >>>
> >>2017-11-15 13:34 GMT+01:00 Michael Niedermayer
> >>: >  Hi all
> >>> 
> >>>  I intend to make 3.4.1 very soon > >>>
> >>> >>> Shouldn't we first decide on how to proceed with
> >>#6775? > >>
> >>> >> This would be ideal.
> >>> >>
> >>> >> IIUC this is a regression from
> >>bddb2343b6e594e312dadb5d21b408702929ae04 > >
> >>> > This was confirmed by more than one developer, yes.
> >>> > > >> I see a patch that is said to improve
> >>6775, can that be applied and
> >>> >> would that resolve this ? > >
> >>> > Iiuc, it would not completely resolve the issue, see:
> >>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >>> > > >> If so why was it not applied yet ? >
> >>>
> >>> > The patch did not get support here, see:
> >>> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> >>> > after EOF
> >>> > in compat_decode > 
> >>> 
> >>>  Is someone working on fixing this better than with the available 
> >>>  patch ?
> >>>  > >>>
> >>> >>> I don't even agree this needs fixing. Those projects
> >>use the API wrong. > >>
> >>> >> Had we documented the correct/wrong use precissely in the past when
> >>> >> these wrong uses where written ?
> >>> >>
> >>> >> Because if it was documented then few should have made the mistake.
> >>> >> But it seems this affects multiple projects, so i wonder if our API
> >>> >> really excluded the use
> >>> >> > >
> >>> > Apparently not well enough, but I also don't even understand why you
> >>> > would *want* to drain in the middle of decoding.
> >>> >
> >>> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> >>> > new API was introduced) do include the "at the end", however.
> >>> >
> >>> > From CODEC_CAP_DELAY:
> >>> >  * Decoders:
> >>> >  * The decoder has a non-zero delay and needs to be fed with 
> >>> > avpkt->data=NULL,
> >>> >  * avpkt->size=0 at the end to get the delayed data until the 
> >>> > decoder no longer
> >>> >  * returns frames.
> >>> >
> >>> > From avcodec_decode_video2
> >>> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set 
> >>> > have a delay
> >>> > * between input and output, these need to be fed with 
> >>> > avpkt->data=NULL,
> >>> > * avpkt->size=0 at the end to return the remaining frames.
> >>> >
> >>> > There is a few more mentions of the same concept, but as far as I 
> >>> > can
> >>> > see all include the key words "at the end".
> >>> > >  > > For the suggested patch, draining and
> >>flushing in the middle of a
> >>> > bitstream is still going to result in problems, though, since it
> >>> > removes all reference frames, for example.
> >>> > The original behavior cannot really be stored, which was to just 
> >>> > keep
> >>> > feeding frames into the decoder after a drain without a flush.
> >>> > However, some decoders actually crashed when you did this, so this 
> >>> > was
> >>> > a rather unsafe action to begin with (not an issue any longer, since
> >>> > this pattern is now blocked). > 
> >>>  Did the previous code really work if the frame after a flush was not 
> >>>  a
> >>>  new keyframe or there was some use of previous references
> >>? > >>>
> >>> >>> ping
> >>> >>>
> >>> >>> so what is the status of this?
> >>> >>>
> >>> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> >>> it closed as 

Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link

[Paul B Mahol]

On 12/7/17, Paul B Mahol  wrote:
> On 12/7/17, Nicolas George  wrote:
>> Paul B Mahol (2017-12-07):
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavfilter/video.c | 9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> Please explain (in the commit message) why you think this patch is
>> needed.
>
> It should not be needed for each filter that sets sample aspect ratio
> to set it explicitly also for each and every frame, instead that is
> automatically done in get_buffer call.
>

Is this message ok? If yes then I will push this patch shortly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eofcause play fail

[Michael Niedermayer]

On Sat, Dec 09, 2017 at 12:06:47AM +0800, Tiejun.Peng wrote:
> yes,  i have checked this case and i have done a lot of tests  with .mp4 file 
> and fate

Please correct me if iam wrong
there are many different atoms/boxes and many functions parsing
them
If any of these return EOF, it has previously been consideered an
error now it can be handled as not an error.

Noone has reviewed most of this code to be safe after the change.
It doesnt crash in fate or with some valid mp4 files

When a parsing function hits EOF it may return EOF.
This can occur in the middle of the function, initializing some but
not all of what it does normally.
Previously this would stop the demuxer and trigger cleanup, after
the change the code continues and may behave badly when it uses half
initialized structures



> 
> -- Original --
> From:  "Michael Niedermayer";;
> Send time: Friday, Dec 8, 2017 4:42 AM
> To: "FFmpeg development discussions and patches"; 
> Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return 
> eofcause play fail
> 
> On Thu, Dec 07, 2017 at 05:47:46PM +0800, tiejun.peng wrote: > fix eof lead 
> to play fail. >  > Signed-off-by: tiejun.peng  > 
> --- >  libavformat/mov.c | 47 --- 
> >  1 file changed, 36 insertions(+), 11 deletions(-)  please split the 
> addition of warning messages from the change to EOF behavior did you check 
> that every EOF return case is safe to continue as if no error occured ? That 
> change has quite wide effects possibly unless i misunderstand. [...] --  
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/Makefile: Fix opus parser dependency.

[Jacob Trimble]

On Fri, Dec 8, 2017 at 10:39 AM, Michael Niedermayer
 wrote:
> On Thu, Dec 07, 2017 at 11:30:13AM -0800, Jacob Trimble wrote:
>> The opus.c file uses variables that are defined in opustab.c.  The
>> opus parser needs to include that file to avoid linker errors when
>> not including the opus encoder/decoder.
>
> please list the symbols needed or the error message in the commmit
> message, so the reader knows about which symbols this is
>
> thx

Done
From 8519e5192bc3dbbc5aa49204321419b6e5a8bf4b Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Thu, 7 Dec 2017 11:05:46 -0800
Subject: [PATCH] avcodec/Makefile: Fix opus parser dependency.

The opus.c file uses ff_celt_freq_range and ff_celt_freq_bands which are
defined in opustab.c.  The opus parser needs to include that file to
avoid linker errors when not including the opus encoder/decoder.

Signed-off-by: Jacob Trimble 
---
 libavcodec/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ab7893f560..ca72138c02 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1005,7 +1005,7 @@ OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_MPEGAUDIO_PARSER)+= mpegaudio_parser.o
 OBJS-$(CONFIG_MPEGVIDEO_PARSER)+= mpegvideo_parser.o\
   mpeg12.o mpeg12data.o
-OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o vorbis_data.o
+OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o opustab.o vorbis_data.o
 OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
 OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
-- 
2.15.1.424.g9478a66081-goog

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

[FFmpeg-devel] [PATCH] amf: fix wrong profile level after auto-correction in H264 and HEVC

[Mironov, Mikhail]

Moved bitrate parameters set before Init() call because bitrate is used in 
profile level correction code inside Init().

Signed-off-by: Mikhail Mironov 
---
 libavcodec/amfenc_h264.c | 10 +-
 libavcodec/amfenc_hevc.c |  8 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index 3cacf32..96e4e95 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -213,7 +213,6 @@ static av_cold int amf_encode_init_h264(AVCodecContext 
*avctx)
 }
 }
 
-
 if (ctx->rate_control_mode == 
AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP) {
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_RATE_CONTROL_PREANALYSIS_ENABLE, 
AMF_VIDEO_ENCODER_PREENCODE_DISABLED);
 if (ctx->preanalysis)
@@ -224,10 +223,6 @@ static av_cold int amf_encode_init_h264(AVCodecContext 
*avctx)
 
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_QUALITY_PRESET, ctx->quality);
 
-// Initialize Encoder
-res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format, avctx->width, 
avctx->height);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG, "encoder->Init() 
failed with error %d\n", res);
-
 // Dynamic parmaters
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD, ctx->rate_control_mode);
 
@@ -279,6 +274,11 @@ static av_cold int amf_encode_init_h264(AVCodecContext 
*avctx)
 } else if (ctx->rate_control_mode == 
AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VBR) {
 av_log(ctx, AV_LOG_WARNING, "rate control mode is PEAK_CONSTRAINED_VBR 
but rc_max_rate is not set\n");
 }
+
+// Initialize Encoder
+res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format, avctx->width, 
avctx->height);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG, "encoder->Init() 
failed with error %d\n", res);
+
 // Enforce HRD, Filler Data, VBAQ, Frame Skipping, Deblocking Filter
 AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder, AMF_VIDEO_ENCODER_ENFORCE_HRD, 
!!ctx->enforce_hrd);
 AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder, 
AMF_VIDEO_ENCODER_FILLER_DATA_ENABLE, !!ctx->filler_data);
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index ced57b1..3956b2d 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -204,10 +204,6 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
*avctx)
 AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder, 
AMF_VIDEO_ENCODER_HEVC_MOTION_HALF_PIXEL, ctx->me_half_pel);
 AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder, 
AMF_VIDEO_ENCODER_HEVC_MOTION_QUARTERPIXEL, ctx->me_quarter_pel);
 
-// init encoder
-res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format, avctx->width, 
avctx->height);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG, "encoder->Init() 
failed with error %d\n", res);
-
 // init dynamic rate control params
 if (ctx->max_au_size)
 ctx->enforce_hrd = 1;
@@ -225,6 +221,10 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
*avctx)
 av_log(ctx, AV_LOG_WARNING, "rate control mode is PEAK_CONSTRAINED_VBR 
but rc_max_rate is not set\n");
 }
 
+// init encoder
+res = ctx->encoder->pVtbl->Init(ctx->encoder, ctx->format, avctx->width, 
avctx->height);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_BUG, "encoder->Init() 
failed with error %d\n", res);
+
 // init dynamic picture control params
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_HEVC_MAX_AU_SIZE, ctx->max_au_size);
 
-- 
2.8.3.windows.1



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

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 02:32:33PM -0300, James Almer wrote:
> On 12/7/2017 8:57 AM, Ihor Bobalo wrote:
> > 
> > 
> 
> There's (what i assume is) an alternative fix here
> https://git.videolan.org/?p=vlc.git;a=commitdiff;h=d14c813b19b9f40e3c1de93f2d750ced41f0e7f1

that may be better, yes

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 06:05:27PM +0100, Martin Vignali wrote:
> >
> > issue still happens with both reverted
> >
> > checkasm: using random seed 1616253308
> > SSSE3:
> >hflip_byte_ssse3 (vf_hflip.c:63)
> >  - vf_hflip.hflip_byte  [FAILED]
> >hflip_short_ssse3 (vf_hflip.c:63)
> >  - vf_hflip.hflip_short [FAILED]
> > checkasm: 2 of 2 tests have failed
> >
> > Thanks for testing,
> rereading the patch, i found one mistake (for the bench_new part (i use
> WIDTH instead of w for the short version)
> But the fail is before.

> Do you test on X86_32 or x86_64 ?

failure occurs on both


> Nasm or Yasm ?

NASM version 2.10.09 compiled on Dec 29 2013

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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



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

Re: [FFmpeg-devel] [PATCH v3 1/2] libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case into function

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 07:56:11PM +, Stefan _ wrote:
> On 07.12.2017 at 17:41 Michael Niedermayer wrote:
> > The move and the functional change should be in seperate patches
> > that keeps changes easy to read and understand
> >
> > [...]
> 
> 

>  hevc_filter.c |   20 +++-
>  hevcdec.h |   20 
>  2 files changed, 23 insertions(+), 17 deletions(-)
> 04e3531811a72a5c76a832b9db910f249430c95e  
> 0001-libavcodec-hevc_filter-move-AVDISCARD_NONREF-switch-.patch
> >From b5d6c40c6516b90abeeffb7cf8ecd1ca1c3f7cb2 Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Thu, 7 Dec 2017 20:37:48 +0100
> Subject: [PATCH 1/2] libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case
>  into function

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 12:19:21AM +0100, Tomas Härdin wrote:
> On Thu, 2017-12-07 at 14:45 -0800, Mark Reid wrote:
> > On Dec 7, 2017 7:45 AM, "Tomas Härdin"  wrote:
> > 
> > On 2017-12-05 05:46, Mark Reid wrote:
> > 
> > > ---
> > >   libavformat/mxf.h|  1 +
> > >   libavformat/mxfenc.c | 42 +++--
> > > -
> > >   2 files changed, 36 insertions(+), 7 deletions(-)
> > > 
> > > 
> > > @@ -1476,6 +1495,15 @@ static int
> > > mxf_write_header_metadata_sets(AVFormatContext
> > > *s)
> > >   }
> > >   }
> > >   +entry = av_dict_get(s->metadata, "reel_name", NULL, 0);
> > > +if (entry) {
> > > +packages[2].name = entry->value;
> > > +packages[2].type = SourcePackage;
> > > +packages[2].instance = 2;
> > > +packages[1].ref = [2];
> > > +package_count = 3;
> > > +}
> > > 
> > 
> > I guess we can have it check track metadata later if we feel like it.
> > Did a
> > patch moving reel_name into AVFormatContext make it into mxfdec yet?
> > mxfenc's output surviving a roundtrip through mxfdec + mxfenc might
> > be
> > desirable:
> > 
> > ffmpeg -i somefile_with_reel_name.mkv output.mxf
> > ffmpeg -i output.mxf -vcodec copy -acodec copy remuxed.mxf
> > 
> > Ideally remuxed.mxf is identical to output.mxf
> > 
> > /Tomas
> > 
> > 
> > Yes I agree that such behaviour is desirable.
> > I haven't taken a look at mxfdec yet. Looking in steams for reel_name
> > might
> > be necessary, as I believe that's where mov,MP4 store it. But I was
> > trying
> > to keep it simple at first and addressed this specific issue a future
> > patch.
> 
> Fair enough. I guess we can commit this patch series then. Michael?

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

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

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 08:46:52AM +0100, Mateusz wrote:
> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
> we have included windows.h in much more files and we should
> avoid conflicts with defines/function declarations.
> 
> Signed-off-by: Mateusz Brzostek 
> ---
>  libavcodec/jpegls.h   | 2 ++
>  libavcodec/mjpegdec.h | 2 ++
>  libavcodec/mss2.c | 6 +++---
>  libavformat/mxfenc.c  | 2 +-
>  4 files changed, 8 insertions(+), 4 deletions(-)

tested on x86-32/64/arm/mips linux & x86-32/64 mingw

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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/Makefile: Fix opus parser dependency.

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 11:30:13AM -0800, Jacob Trimble wrote:
> The opus.c file uses variables that are defined in opustab.c.  The
> opus parser needs to include that file to avoid linker errors when
> not including the opus encoder/decoder.

please list the symbols needed or the error message in the commmit
message, so the reader knows about which symbols this is

thx

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

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


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

Re: [FFmpeg-devel] avfilter/x86/vf_threshold : add SSE4 and AVX2 for threshold 16

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 10:08:56PM +0100, Martin Vignali wrote:
> >
> > You should also change the cglobal line for x86_32, right below this else
> >
> >
> new patch in attach

tested, works on arm/mips/x86-32/64 linux & x86-32/64 mingw

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Jacob Trimble]

On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
 wrote:
> On 12/6/2017 12:36 AM, Jacob Trimble wrote:
>> Would a 0-length array work?  Otherwise I would need to have it be a
>> 1-length array and have to account for that when calculating the size
>> to allocate; it would also require a comment to ignore the size of the
>> array.
>
> Aren't 0-length arrays a GNU extensions? If so, I would gather that it
> probably is not OK in a public header, either.

Yeah.

> I'm not entirely sure what way we prefer nowadays, but you can see
> we've had side data with variable length members before with e.g.
> AV_PKT_DATA_QUALITY_STATS, but that doesn't have a struct associated
> with it. I'm hoping someone more up to date with the side data stuff
> can chime in with a suggestion on what our current best practices
> are for it.

I would prefer to avoid requiring the app to "parse" the side data, using a
plain struct would be better.  I've updated the patch to include my other plan
of allocating a larger bock and having the struct followed by the subsample
array.

I have also renamed the file, I think the mailing list rejected my attachment
before since gmail sent the MIME type as text/x-patch.  Hopefully with the
.txt extension gmail will send the correct MIME type.
From 740c0ccf3ed90b3d417ea25ec26cfefb93974461 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.

This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.  To allow for a
variable number of subsamples, the buffer for the side-data will be
allocated to hold both the structure and the array of subsamples.  So
the |subsamples| member will point to right after the struct.

Signed-off-by: Jacob Trimble 
---
 libavcodec/avcodec.h | 60 
 1 file changed, 60 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..6f5c387556 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1112,6 +1112,53 @@ typedef struct AVCPBProperties {
 uint64_t vbv_delay;
 } AVCPBProperties;
 
+/**
+ * This describes encryption info for a packet.  This contains frame-specific
+ * info for how to decrypt the packet before passing it to the decoder.  If 
this
+ * side-data is present, then the packet is encrypted.
+ */
+typedef struct AVPacketEncryptionInfo {
+/** The fourcc encryption scheme. */
+int scheme;
+
+/** The ID of the key used to encrypt the packet. */
+uint8_t key_id[16];
+
+/** The initialization vector. */
+uint8_t iv[16];
+
+/**
+ * Only used for pattern encryption.  This is the number of 16-byte blocks
+ * that are encrypted.
+ */
+unsigned int crypt_byte_block;
+
+/**
+ * Only used for pattern encryption.  This is the number of 16-byte blocks
+ * that are clear.
+ */
+unsigned int skip_byte_block;
+
+/**
+ * The number of sub-samples in this packet.  If 0, then the whole sample
+ * is encrypted.
+ */
+unsigned int subsample_count;
+
+struct {
+  /** The number of bytes that are clear. */
+  unsigned int bytes_of_clear_data;
+
+  /**
+   * The number of bytes that are protected.  If using pattern encryption,
+   * the pattern applies to only the protected bytes; if not using pattern
+   * encryption, all these bytes are encrypted.
+   */
+  unsigned int bytes_of_protected_data;
+} *subsamples;
+} AVPacketEncryptionInfo;
+#define FF_PACKET_ENCRYPTION_INFO_SIZE(a) (sizeof(AVPacketEncryptionInfo) + 
sizeof(unsigned int) * a * 2)
+
 /**
  * The decoder will keep a reference to the frame and may reuse it later.
  */
@@ -1327,6 +1374,19 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_A53_CC,
 
+/**
+ * This side data is encryption "initialization data".
+ * For MP4 this is the entire 'pssh' box.
+ * For WebM this is the key ID.
+ */
+AV_PKT_DATA_ENCRYPTION_INIT_DATA,
+
+/**
+ * This side data is an AVPacketEncryptionInfo structure and contains info
+ * about how the packet is encrypted.
+ */
+AV_PKT_DATA_PACKET_ENCRYPTION_INFO,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
-- 
2.15.1.424.g9478a66081-goog

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

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Carl Eugen Hoyos]

2017-12-08 18:45 GMT+01:00 Tiejun.Peng :
> i agree with you. too much  experience value in condition of Judgement  like 
> this:
> "else if(max_frames>=4 && max_frames >= p->buf_size/1)".
>  why  it is the value ? it is hard to known.
> maybe  the work of cleaned up  need a few days, so i just  repair of the 
> probe.

Please be careful:
As you already know, this probe function is the result of many
user reports, many tests and turning many knobs. You cannot
"repair" it (easily).

If you know of any false positives of the current probe function,
please report them!

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

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Tiejun.Peng]

i agree with you. too much  experience value in condition of Judgement  like 
this:
"else if(max_frames>=4 && max_frames >= p->buf_size/1)".
 why  it is the value ? it is hard to known. 
maybe  the work of cleaned up  need a few days, so i just  repair of the probe.


-- Original --
From:  "wm4";;
Send time: Thursday, Dec 7, 2017 9:16 PM
To: "ffmpeg-devel"; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



On Wed,  6 Dec 2017 17:27:43 +0800
"tiejun.peng"  wrote:

> fix #6895: https://trac.ffmpeg.org/ticket/6895
> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3
> 
> Signed-off-by: tiejun.peng 
> ---
>  libavformat/mp3dec.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index a76fe32..286eb68 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,6 +73,7 @@ static int mp3_read_probe(AVProbeData *p)
>  int frames, ret;
>  uint32_t header;
>  const uint8_t *buf, *buf0, *buf2, *end;
> +int match_size = 0;
>  
>  buf0 = p->buf;
>  end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -92,6 +93,7 @@ static int mp3_read_probe(AVProbeData *p)
>  if (ret != 0)
>  break;
>  buf2 += h.frame_size;
> +match_size += h.frame_size;
>  }
>  max_frames = FFMAX(max_frames, frames);
>  if(buf == buf0) {
> @@ -104,6 +106,8 @@ static int mp3_read_probe(AVProbeData *p)
>  // issues with MPEG-files!
>  if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
>  else if(max_frames>200)return AVPROBE_SCORE_EXTENSION;
> +// over 50% of probe size is valid
> +else if (p->buf_size > 1 && match_size > (p->buf_size/2)) return 
> AVPROBE_SCORE_EXTENSION;
>  else if(max_frames>=4 && max_frames >= p->buf_size/1) return 
> AVPROBE_SCORE_EXTENSION / 2;
>  else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 
> 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
> return p->buf_size < PROBE_BUF_MAX ? 
> AVPROBE_SCORE_EXTENSION / 4 : AVPROBE_SCORE_EXTENSION - 2;

That doesn't necessarily affect whether this patch should be applied,
but: I think this mp4 probe should really be cleaned up. It's one of
the most complex probe functions, and it doesn't even work correctly.
It still detects some ELF files as mp3 (or mp1/2), for example.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[James Almer]

On 12/7/2017 8:57 AM, Ihor Bobalo wrote:
> 
> 

There's (what i assume is) an alternative fix here
https://git.videolan.org/?p=vlc.git;a=commitdiff;h=d14c813b19b9f40e3c1de93f2d750ced41f0e7f1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[Jan Ekström]

On Fri, Dec 8, 2017 at 7:18 PM, Michael Niedermayer
 wrote:
> please provide the uncut error message and compiler/assembler version
> affected in the commit message as reference otherwise its hard to
> understand what/where exactly the issue was

Hi,

I noticed this breakage with clang on ARMv7, and jamrial seemed to
mention that aarch64 with GCC seemed to be broken as well?
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html


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

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Tiejun.Peng]

sorry , i can't  produce the output file of  pcm with vlc .
below link  is the vlc record file, maybe it is useful for you. i try to play 
it with ffmpeg is ok.

https://trac.ffmpeg.org/attachment/ticket/6895/vlc-record-2017-12-09-01h02m32s-music_mp3-.mp3




-- Original --
From:  "Carl Eugen Hoyos";;
Send time: Saturday, Dec 9, 2017 0:21 AM
To: "FFmpeg development discussions and patches"; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-08 17:13 GMT+01:00 Tiejun.Peng :
> can this commit  be merged into master?

Given that it would introduce a regression, I guess not.

More important though: I cannot reproduce successful
playback with vlc - can you provide the output file that
vlc produces for you?

Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 11:57:51AM +, Ihor Bobalo wrote:
> 
> 
> 
> 
> This e-mail may contain privileged and confidential information. If you are 
> not the intended recipient, be aware that any use, disclosure, copying or 
> distribution of this e-mail or any attachments is prohibited. If you have 
> received this e-mail in error, please notify us immediately by returning it 
> to the sender and delete this copy from your system. Thank you.

>  hevcdsp_idct_neon.S |2 ++
>  1 file changed, 2 insertions(+)
> 2a708aa4ad4e5be9109be5c547b6f47addf56bce  
> 0001-libavcodec-hevcdsp-compilation-error-fixed-for-ARM.patch
> From a649745642e5fb3812c01750e69476d356a42e95 Mon Sep 17 00:00:00 2001
> From: Ihor Bobalo 
> Date: Thu, 7 Dec 2017 13:27:44 +0200
> Subject: [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM
> 
> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed 
> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error 
> messages is "Offset out of range". The reason of the error is assembler LDR 
> directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage 
> in range <1k, but no such storage provided. Fixed by added "ltorg" directive 
> after the function end, allowing compiler to allocate the local storage just 
> after the function code if neccessary.

please provide the uncut error message and compiler/assembler version
affected in the commit message as reference otherwise its hard to
understand what/where exactly the issue was

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v2] libavcodec/mpegvideo_parser: improve detection of progressive mpeg2

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 04:05:15PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Previously many progressive mpeg2video samples were detected as interlaced
> by ffmpeg/ffprobe. For example, https://tmm1.s3.amazonaws.com/720p.ts
> 
> Before:
> 
> Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
>   Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
>   Program 2
>   Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv, bottom 
> first), 1280x720 ...
> 
> After:
> 
> Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
>   Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
>   Program 2
>   Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv, 
> progressive), 1280x720 ...

commit message sounds ok
no more comments from me, please wait a bit with applying so others
can comment too

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: add flag to discard timestamps on corrupted frames

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 10:23:15PM -0600, Rodger Combs wrote:
> ---
>  libavformat/avformat.h  | 1 +
>  libavformat/options_table.h | 1 +
>  libavformat/utils.c | 8 
>  3 files changed, 10 insertions(+)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 4f2798a871..d10d583dff 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
>  #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate 
> seeks for some formats
>  #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
> stream stops.
>  #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as 
> requested by the muxer
> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
> frames marked corrupt
>  
>  /**
>   * Maximum size of the data read from input for determining
> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
> index b8fa47c6fd..515574d3e0 100644
> --- a/libavformat/options_table.h
> +++ b/libavformat/options_table.h
> @@ -58,6 +58,7 @@ static const AVOption avformat_options[] = {
>  {"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { 
> .i64 = AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
>  {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, { 
> .i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
>  {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 = 
> AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
> +{"discardcorruptts", "discard timestamps on corrupted frames", 0, 
> AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E, 
> "fflags" },
>  {"analyzeduration", "specify how many microseconds are analyzed to probe the 
> input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, 
> INT64_MAX, D},
>  {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0}, 
> 0, 0, D},
>  {"indexmem", "max memory used for timestamp index (per stream)", 
> OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 84e49208b8..98af941e9f 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c

> @@ -873,6 +873,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>  st->cur_dts = wrap_timestamp(st, st->cur_dts);
>  }
>  
> +if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS) &&
> +(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
> +pkt->pts = pkt->dts = AV_NOPTS_VALUE;
> +av_log(s, AV_LOG_WARNING,
> +   "Discarded timestamp on corrupted packet (stream = %d)\n",
> +   pkt->stream_index);
> +}

how many of the cases that set AV_PKT_FLAG_CORRUPT can even be due to
the timestamp ?

We set this for truncated / EOF cases and all kinds of stuff that
are known to be unrelated to the timestamps


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Martin Vignali]

>
> issue still happens with both reverted
>
> checkasm: using random seed 1616253308
> SSSE3:
>hflip_byte_ssse3 (vf_hflip.c:63)
>  - vf_hflip.hflip_byte  [FAILED]
>hflip_short_ssse3 (vf_hflip.c:63)
>  - vf_hflip.hflip_short [FAILED]
> checkasm: 2 of 2 tests have failed
>
> Thanks for testing,
rereading the patch, i found one mistake (for the bench_new part (i use
WIDTH instead of w for the short version)
But the fail is before.
Do you test on X86_32 or x86_64 ?
Nasm or Yasm ?

I will try to reproduce.

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

[FFmpeg-devel] [PATCH V2] lavf/mov: atom box parsing return eof cause play fail

[tiejun.peng]

fix eof lead to play fail.

Signed-off-by: tiejun.peng 
---
 libavformat/mov.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 180b6f4..870fdd6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6632,7 +6632,9 @@ static int mov_read_header(AVFormatContext *s)
 do {
 if (mov->moov_retry)
 avio_seek(pb, 0, SEEK_SET);
-if ((err = mov_read_default(mov, pb, atom)) < 0) {
+/* EOF don't mean the file to play fail*/
+err = mov_read_default(mov, pb, atom);
+if (err < 0 && err != AVERROR_EOF) {
 av_log(s, AV_LOG_ERROR, "error reading header\n");
 mov_read_close(s);
 return err;
-- 
2.7.4



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

[FFmpeg-devel] [PATCH] lavf/mov: modify code indentation

[tiejun.peng]

Signed-off-by: tiejun.peng 
---
 libavformat/mov.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9982204..180b6f4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6630,13 +6630,13 @@ static int mov_read_header(AVFormatContext *s)
 
 /* check MOV header */
 do {
-if (mov->moov_retry)
-avio_seek(pb, 0, SEEK_SET);
-if ((err = mov_read_default(mov, pb, atom)) < 0) {
-av_log(s, AV_LOG_ERROR, "error reading header\n");
-mov_read_close(s);
-return err;
-}
+if (mov->moov_retry)
+avio_seek(pb, 0, SEEK_SET);
+if ((err = mov_read_default(mov, pb, atom)) < 0) {
+av_log(s, AV_LOG_ERROR, "error reading header\n");
+mov_read_close(s);
+return err;
+}
 } while ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mov->found_moov && 
!mov->moov_retry++);
 if (!mov->found_moov) {
 av_log(s, AV_LOG_ERROR, "moov atom not found\n");
-- 
2.7.4



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

[FFmpeg-devel] [PATCH] lavf/mov: add some useful warning log of eof

[tiejun.peng]

Signed-off-by: tiejun.peng 
---
 libavformat/mov.c | 43 +--
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index c901859..9982204 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1991,8 +1991,10 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->chunk_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STCO atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2522,8 +2524,10 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext 
*pb, int entries)
 sc->stsd_count++;
 }
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSD atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2624,8 +2628,10 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->stsc_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSC atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2676,8 +2682,10 @@ static int mov_read_stps(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->stps_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STPS atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2723,8 +2731,10 @@ static int mov_read_stss(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->keyframe_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSS atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2808,8 +2818,10 @@ static int mov_read_stsz(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 av_free(buf);
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSZ atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2870,8 +2882,10 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 sc->duration_for_fps  += duration;
 sc->nb_frames_for_fps += total_sample_count;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STTS atom\n");
 return AVERROR_EOF;
+}
 
 st->nb_frames= total_sample_count;
 if (duration)
@@ -2948,8 +2962,10 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->ctts_count = ctts_count;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted CTTS atom\n");
 return AVERROR_EOF;
+}
 
 av_log(c->fc, AV_LOG_TRACE, "dts shift %d\n", sc->dts_shift);
 
@@ -2995,7 +3011,12 @@ static int mov_read_sbgp(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->rap_group_count = i;
 
-return pb->eof_reached ? AVERROR_EOF : 0;
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted SBGP atom\n");
+return AVERROR_EOF;
+}
+
+return 0;
 }
 
 /**
@@ -4720,8 +4741,10 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 fix_frag_index_entries(>frag_index, next_frag_index,
frag->track_id, entries);
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted TRUN atom\n");
 return AVERROR_EOF;
+}
 
 frag->implicit_offset = offset;
 
-- 
2.7.4



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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-12-08 5:42 GMT+01:00 James Almer :
> On 12/8/2017 1:33 AM, Carl Eugen Hoyos wrote:
>> 2017-12-08 5:09 GMT+01:00 James Almer :
>>
>>> When the old decode API was turned into a wrapper for the
>>> new, some applications using said API this way started to
>>> experience issues/crashes that did not happen before.
>>
>> Where was a crash reported?

> I said issues/crashes because i wasn't sure which kind was reported.
> Looking at the ticket, i guess it was the former.

Thank you!

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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/matroskadec: log when falling back to generic seeking

[Carl Eugen Hoyos]

2017-12-08 13:45 GMT+01:00 Rodger Combs :
> ---
>  libavformat/matroskadec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 2d23f2ee84..f023e94e70 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3567,6 +3567,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
> stream_index,
>  ff_update_cur_dts(s, st, st->index_entries[index].timestamp);
>  return 0;
>  err:
> +av_log(s, AV_LOG_VERBOSE, "Failed to seek using index; falling back to 
> generic seek");

Sounds like a warning to me, no?

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

[FFmpeg-devel] [PATCH] lavc: Make hardware config method support more explicit for hwaccels

[Mark Thompson]

From: Thomas Guillem 

This fixes the use of old ad-hoc methods which are still supported by some
hwaccels which also support newer methods (DXVA2, VAAPI, VDPAU,
videotoolbox) - without the method being visible here, ff_get_format()
would refuse to use it.

Signed-off-by: Mark Thompson 
---
On 07/12/17 12:25, Thomas Guillem wrote:
> Add a boolean to specify if an API can work with
> AV_CODEC_HW_CONFIG_METHOD_AD_HOC.
> ---
>  libavcodec/hwaccel.h | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> index ae55527c2f..16ee822920 100644
> --- a/libavcodec/hwaccel.h
> +++ b/libavcodec/hwaccel.h
> @@ -42,12 +42,13 @@ typedef struct AVCodecHWConfigInternal {
>  
>  // These macros are used to simplify AVCodecHWConfigInternal definitions.
>  
> -#define HW_CONFIG_HWACCEL(format, device, name) \
> +#define HW_CONFIG_HWACCEL(format, ad_hoc, device, name) \
>  &(const AVCodecHWConfigInternal) { \
>  .public  = { \
>  .pix_fmt = AV_PIX_FMT_ ## format, \
>  .methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
> -   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
> +   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX | \
> +   ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC : 0, \
>  .device_type = AV_HWDEVICE_TYPE_ ## device, \
>  }, \
>  .hwaccel = , \

Once we're having extra arguments in the macros like that I think I would 
prefer all the methods to be specified explicitly (which conveniently also lets 
us delete the second macro).

How about this?

Thanks,

- Mark


 libavcodec/hwaccel.h | 36 +---
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index ae55527c2f..3aaa92571c 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -42,13 +42,14 @@ typedef struct AVCodecHWConfigInternal {
 
 // These macros are used to simplify AVCodecHWConfigInternal definitions.
 
-#define HW_CONFIG_HWACCEL(format, device, name) \
+#define HW_CONFIG_HWACCEL(device, frames, ad_hoc, format, device_type_, name) \
 &(const AVCodecHWConfigInternal) { \
 .public  = { \
 .pix_fmt = AV_PIX_FMT_ ## format, \
-.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
-   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
-.device_type = AV_HWDEVICE_TYPE_ ## device, \
+.methods = (device ? AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX : 
0) | \
+   (frames ? AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX : 
0) | \
+   (ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC: 
0),  \
+.device_type = AV_HWDEVICE_TYPE_ ## device_type_, \
 }, \
 .hwaccel = , \
 }
@@ -63,32 +64,21 @@ typedef struct AVCodecHWConfigInternal {
 .hwaccel = NULL, \
 }
 
-#define HW_CONFIG_AD_HOC_HWACCEL(format, name) \
-&(const AVCodecHWConfigInternal) { \
-.public =  { \
-.pix_fmt = AV_PIX_FMT_ ## format, \
-.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC, \
-.device_type = AV_HWDEVICE_TYPE_NONE, \
-}, \
-.hwaccel = , \
-}
-
 #define HWACCEL_DXVA2(codec) \
-HW_CONFIG_HWACCEL(DXVA2_VLD, DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
+HW_CONFIG_HWACCEL(1, 1, 1, DXVA2_VLD,DXVA2,ff_ ## codec ## 
_dxva2_hwaccel)
 #define HWACCEL_D3D11VA2(codec) \
-HW_CONFIG_HWACCEL(D3D11, D3D11VA, ff_ ## codec ## _d3d11va2_hwaccel)
+HW_CONFIG_HWACCEL(1, 1, 0, D3D11,D3D11VA,  ff_ ## codec ## 
_d3d11va2_hwaccel)
 #define HWACCEL_NVDEC(codec) \
-HW_CONFIG_HWACCEL(CUDA,  CUDA,ff_ ## codec ## _nvdec_hwaccel)
+HW_CONFIG_HWACCEL(1, 1, 0, CUDA, CUDA, ff_ ## codec ## 
_nvdec_hwaccel)
 #define HWACCEL_VAAPI(codec) \
-HW_CONFIG_HWACCEL(VAAPI, VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
+HW_CONFIG_HWACCEL(1, 1, 1, VAAPI,VAAPI,ff_ ## codec ## 
_vaapi_hwaccel)
 #define HWACCEL_VDPAU(codec) \
-HW_CONFIG_HWACCEL(VDPAU, VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
+HW_CONFIG_HWACCEL(1, 1, 1, VDPAU,VDPAU,ff_ ## codec ## 
_vdpau_hwaccel)
 #define HWACCEL_VIDEOTOOLBOX(codec) \
-HW_CONFIG_HWACCEL(VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
-
+HW_CONFIG_HWACCEL(1, 1, 1, VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
 #define HWACCEL_D3D11VA(codec) \
-HW_CONFIG_AD_HOC_HWACCEL(D3D11VA_VLD, ff_ ## codec ## _d3d11va_hwaccel)
+HW_CONFIG_HWACCEL(0, 0, 1, D3D11VA_VLD,  NONE, ff_ ## codec ## 
_d3d11va_hwaccel)
 #define HWACCEL_XVMC(codec) \
-HW_CONFIG_AD_HOC_HWACCEL(XVMC,ff_ ## codec ## _xvmc_hwaccel)
+

Re: [FFmpeg-devel] [PATCH] lavc: Make hardware config method support more explicit for hwaccels

[Thomas Guillem]

On Fri, Dec 8, 2017, at 17:15, Mark Thompson wrote:
> From: Thomas Guillem 
> 
> This fixes the use of old ad-hoc methods which are still supported by
> some
> hwaccels which also support newer methods (DXVA2, VAAPI, VDPAU,
> videotoolbox) - without the method being visible here, ff_get_format()
> would refuse to use it.
> 
> Signed-off-by: Mark Thompson 
> ---
> On 07/12/17 12:25, Thomas Guillem wrote:
> > Add a boolean to specify if an API can work with
> > AV_CODEC_HW_CONFIG_METHOD_AD_HOC.
> > ---
> >  libavcodec/hwaccel.h | 17 +
> >  1 file changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> > index ae55527c2f..16ee822920 100644
> > --- a/libavcodec/hwaccel.h
> > +++ b/libavcodec/hwaccel.h
> > @@ -42,12 +42,13 @@ typedef struct AVCodecHWConfigInternal {
> >  
> >  // These macros are used to simplify AVCodecHWConfigInternal definitions.
> >  
> > -#define HW_CONFIG_HWACCEL(format, device, name) \
> > +#define HW_CONFIG_HWACCEL(format, ad_hoc, device, name) \
> >  &(const AVCodecHWConfigInternal) { \
> >  .public  = { \
> >  .pix_fmt = AV_PIX_FMT_ ## format, \
> >  .methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
> > -   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
> > +   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX | \
> > +   ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC : 0, \
> >  .device_type = AV_HWDEVICE_TYPE_ ## device, \
> >  }, \
> >  .hwaccel = , \
> 
> Once we're having extra arguments in the macros like that I think I would
> prefer all the methods to be specified explicitly (which conveniently
> also lets us delete the second macro).
> 
> How about this?

Fine with me.

> 
> Thanks,
> 
> - Mark
> 
> 
>  libavcodec/hwaccel.h | 36 +---
>  1 file changed, 13 insertions(+), 23 deletions(-)
> 
> diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> index ae55527c2f..3aaa92571c 100644
> --- a/libavcodec/hwaccel.h
> +++ b/libavcodec/hwaccel.h
> @@ -42,13 +42,14 @@ typedef struct AVCodecHWConfigInternal {
>  
>  // These macros are used to simplify AVCodecHWConfigInternal
>  definitions.
>  
> -#define HW_CONFIG_HWACCEL(format, device, name) \
> +#define HW_CONFIG_HWACCEL(device, frames, ad_hoc, format, device_type_,
> name) \
>  &(const AVCodecHWConfigInternal) { \
>  .public  = { \
>  .pix_fmt = AV_PIX_FMT_ ## format, \
> -.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
> -   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
> -.device_type = AV_HWDEVICE_TYPE_ ## device, \
> +.methods = (device ?
> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX : 0) | \
> +   (frames ?
> AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX : 0) | \
> +   (ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC   
> : 0),  \
> +.device_type = AV_HWDEVICE_TYPE_ ## device_type_, \
>  }, \
>  .hwaccel = , \
>  }
> @@ -63,32 +64,21 @@ typedef struct AVCodecHWConfigInternal {
>  .hwaccel = NULL, \
>  }
>  
> -#define HW_CONFIG_AD_HOC_HWACCEL(format, name) \
> -&(const AVCodecHWConfigInternal) { \
> -.public =  { \
> -.pix_fmt = AV_PIX_FMT_ ## format, \
> -.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC, \
> -.device_type = AV_HWDEVICE_TYPE_NONE, \
> -}, \
> -.hwaccel = , \
> -}
> -
>  #define HWACCEL_DXVA2(codec) \
> -HW_CONFIG_HWACCEL(DXVA2_VLD, DXVA2,   ff_ ## codec ##
> _dxva2_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 1, DXVA2_VLD,DXVA2,ff_ ## codec
> ## _dxva2_hwaccel)
>  #define HWACCEL_D3D11VA2(codec) \
> -HW_CONFIG_HWACCEL(D3D11, D3D11VA, ff_ ## codec ##
> _d3d11va2_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 0, D3D11,D3D11VA,  ff_ ## codec
> ## _d3d11va2_hwaccel)
>  #define HWACCEL_NVDEC(codec) \
> -HW_CONFIG_HWACCEL(CUDA,  CUDA,ff_ ## codec ##
> _nvdec_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 0, CUDA, CUDA, ff_ ## codec
> ## _nvdec_hwaccel)
>  #define HWACCEL_VAAPI(codec) \
> -HW_CONFIG_HWACCEL(VAAPI, VAAPI,   ff_ ## codec ##
> _vaapi_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 1, VAAPI,VAAPI,ff_ ## codec
> ## _vaapi_hwaccel)
>  #define HWACCEL_VDPAU(codec) \
> -HW_CONFIG_HWACCEL(VDPAU, VDPAU,   ff_ ## codec ##
> _vdpau_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 1, VDPAU,VDPAU,ff_ ## codec
> ## _vdpau_hwaccel)
>  #define HWACCEL_VIDEOTOOLBOX(codec) \
> -HW_CONFIG_HWACCEL(VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec ##
> _videotoolbox_hwaccel)
> -
> +HW_CONFIG_HWACCEL(1, 1, 1, VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec
> ## _videotoolbox_hwaccel)
>  #define 

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Carl Eugen Hoyos]

2017-12-08 17:13 GMT+01:00 Tiejun.Peng :
> can this commit  be merged into master?

Given that it would introduce a regression, I guess not.

More important though: I cannot reproduce successful
playback with vlc - can you provide the output file that
vlc produces for you?

Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Tiejun.Peng]

can this commit  be merged into master?
-- Original --
From:  "Tiejun.Peng";;
Send time: Thursday, Dec 7, 2017 5:32 PM
To: "FFmpeg development discussions and patches"; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



Playback of the mp3 file sounds very good with VLC media player 2.2.2 
Weatherwax (revision 2.2.2-0-g6259d80)


Tiejun Peng

-- Original --
From:  "Carl Eugen Hoyos";;
Send time: Thursday, Dec 7, 2017 0:00 AM
To: "FFmpeg development discussions and patches"; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-06 10:27 GMT+01:00 tiejun.peng :
> fix #6895: https://trac.ffmpeg.org/ticket/6895

The patch breaks issue3327-libc-2.17.so

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3

Which player does something useful with this file?

I am not saying there can't be an issue, but not detecting
severely broken files does not sound necessarily wrong
to me.

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

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 12:34:07PM +0100, Martin Vignali wrote:
> >
> > maybe iam missing something
> > but my box doesnt like your test:
> >
> >
> > Is there a link to these recent commit :
> https://github.com/FFmpeg/FFmpeg/commit/dc33fe1d0080e932faa9fe3c7fb4850dfde161a8
> https://github.com/FFmpeg/FFmpeg/commit/f2aa0ce5a059cf02ee4cbd68111dd2ad622edc85
> ?

issue still happens with both reverted

checkasm: using random seed 1616253308
SSSE3:
   hflip_byte_ssse3 (vf_hflip.c:63)
 - vf_hflip.hflip_byte  [FAILED]
   hflip_short_ssse3 (vf_hflip.c:63)
 - vf_hflip.hflip_short [FAILED]
checkasm: 2 of 2 tests have failed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eofcause play fail

[Tiejun.Peng]

yes,  i have checked this case and i have done a lot of tests  with .mp4 file 
and fate

-- Original --
From:  "Michael Niedermayer";;
Send time: Friday, Dec 8, 2017 4:42 AM
To: "FFmpeg development discussions and patches"; 
Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eofcause 
play fail

On Thu, Dec 07, 2017 at 05:47:46PM +0800, tiejun.peng wrote: > fix eof lead to 
play fail. >  > Signed-off-by: tiejun.peng  > --- > 
 libavformat/mov.c | 47 --- >  1 
file changed, 36 insertions(+), 11 deletions(-)  please split the addition of 
warning messages from the change to EOF behavior did you check that every EOF 
return case is safe to continue as if no error occured ? That change has quite 
wide effects possibly unless i misunderstand. [...] --  Michael GnuPG 
fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Paul B Mahol]

On 12/8/17, Paul B Mahol  wrote:
> On 12/8/17, Vittorio Giovara  wrote:
>>> On 12/8/17, Paul B Mahole *>> >* wrote:
>>>*> This will basically break everyone encoding mjpeg right now, since it
>> *>*> suddenly only accepts different formats without any common-ground
>> *>*> before/after.
>> *>*> Furthermore, there is no replacement for the indication that this
>> *>*> encoder wants full-range data, which the old pixfmts indicated.
>> *>
>>> So I will add .color_range to AVCodec
>>> 0 means encoder supports both.
>>>
>>> Is that ok?
>>
>> I tried in the past and it is indeed possible, however it doesn't really
>> work: going that route you'll end up adding all the color properties,
>> including chroma location.
>> As much as I despise the J formats, it's a hacky solution at best leading
>> to a very confusing API, making the negotiation and conversion
>> unnecessary
>> complex.
>
> There is nothing complex here, simply color_range is auto set for mjpeg
> encoder (even thought it can support both with minimal changes)
>
> Also now filter links are aware of color_range and can be freely changed,
> similar to sample aspect ratio.
>
>> If we were to break this feature, I'd suggest going the full route of
>> adding a PixelFormaton and work on a sws alternative (one is allowed to
>> dream no?).
>
> This is step to right direction, why would adding yet another API be better
> solution?
>
> J formats are hack - misfeature - most obvious reason why nobody added
> 10bit J formats, or one of alpha. Calling it otherwise, points to severe
> lack of understanding of problem.
>

Also asking to make additional changes and then asking to drop the thing all
together is not good for project health.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Paul B Mahol]

On 12/8/17, Vittorio Giovara  wrote:
>> On 12/8/17, Paul B Mahole *> >* wrote:
>>*> This will basically break everyone encoding mjpeg right now, since it
> *>*> suddenly only accepts different formats without any common-ground
> *>*> before/after.
> *>*> Furthermore, there is no replacement for the indication that this
> *>*> encoder wants full-range data, which the old pixfmts indicated.
> *>
>> So I will add .color_range to AVCodec
>> 0 means encoder supports both.
>>
>> Is that ok?
>
> I tried in the past and it is indeed possible, however it doesn't really
> work: going that route you'll end up adding all the color properties,
> including chroma location.
> As much as I despise the J formats, it's a hacky solution at best leading
> to a very confusing API, making the negotiation and conversion unnecessary
> complex.

There is nothing complex here, simply color_range is auto set for mjpeg
encoder (even thought it can support both with minimal changes)

Also now filter links are aware of color_range and can be freely changed,
similar to sample aspect ratio.

> If we were to break this feature, I'd suggest going the full route of
> adding a PixelFormaton and work on a sws alternative (one is allowed to
> dream no?).

This is step to right direction, why would adding yet another API be better
solution?

J formats are hack - misfeature - most obvious reason why nobody added
10bit J formats, or one of alpha. Calling it otherwise, points to severe
lack of understanding of problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Vittorio Giovara]

> On 12/8/17, Paul B Mahole * >* wrote:
>*> This will basically break everyone encoding mjpeg right now, since it
*>*> suddenly only accepts different formats without any common-ground
*>*> before/after.
*>*> Furthermore, there is no replacement for the indication that this
*>*> encoder wants full-range data, which the old pixfmts indicated.
*>
> So I will add .color_range to AVCodec
> 0 means encoder supports both.
>
> Is that ok?

I tried in the past and it is indeed possible, however it doesn't really
work: going that route you'll end up adding all the color properties,
including chroma location.
As much as I despise the J formats, it's a hacky solution at best leading
to a very confusing API, making the negotiation and conversion unnecessary
complex.
If we were to break this feature, I'd suggest going the full route of
adding a PixelFormaton and work on a sws alternative (one is allowed to
dream no?).
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Allow users to disable all hwaccel libraries

[Gyan Doshi]

On 12/8/2017 4:56 PM, Tobias Rapp wrote:

includes autodetected hwaccels, but that's just my personal opinion. I 
leave it to the maintainer of the file to decide what to push.


Speaking of which, who is the maintainer of configure? Neither the file 
nor MAINTAINERS has a name.


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

[FFmpeg-devel] [PATCH 3/3] lavf/matroskadec: log when falling back to generic seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2d23f2ee84..f023e94e70 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3567,6 +3567,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 ff_update_cur_dts(s, st, st->index_entries[index].timestamp);
 return 0;
 err:
+av_log(s, AV_LOG_VERBOSE, "Failed to seek using index; falling back to 
generic seek");
 // slightly hackish but allows proper fallback to
 // the generic seeking code.
 matroska_clear_queue(matroska);
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 2/3] lavf/matroskadec: fallback to generic seeking if resyncing fails while seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 93a3ec4a07..2d23f2ee84 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3531,8 +3531,10 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 int64_t pos = avio_tell(matroska->ctx->pb);
 matroska_clear_queue(matroska);
 if (matroska_parse_cluster(matroska) < 0) {
-if (matroska_resync(matroska, pos) < 0)
+if (matroska_resync(matroska, pos) < 0) {
+index = -1;
 break;
+}
 }
 }
 }
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 1/3] lavf/matroskadec: resync if cluster parsing fails while seeking

[Rodger Combs]

---
 libavformat/matroskadec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 496499b553..93a3ec4a07 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3528,9 +3528,12 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
   SEEK_SET);
 matroska->current_id = 0;
 while ((index = av_index_search_timestamp(st, timestamp, flags)) < 0 
|| index == st->nb_index_entries - 1) {
+int64_t pos = avio_tell(matroska->ctx->pb);
 matroska_clear_queue(matroska);
-if (matroska_parse_cluster(matroska) < 0)
-break;
+if (matroska_parse_cluster(matroska) < 0) {
+if (matroska_resync(matroska, pos) < 0)
+break;
+}
 }
 }
 
-- 
2.15.1

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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Marton Balint]

On Fri, 8 Dec 2017, wm4 wrote:


On Fri, 8 Dec 2017 06:52:20 +0100
Michael Niedermayer  wrote:


On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> On 12/8/2017 12:26 AM, wm4 wrote: 
> > On Thu, 7 Dec 2017 23:23:51 +0100

> > Michael Niedermayer  wrote:
> > 
> >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote: 
> >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote: 
>  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote: 
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote: 
> >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote: 
> >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>>  wrote: 
>  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote: 
> > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer : 
> >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote: 
> >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer : 
>  Hi all

> 
>  I intend to make 3.4.1 very soon 
> >>>
> >>> Shouldn't we first decide on how to proceed with #6775? 
> >>

> >> This would be ideal.
> >>
> >> IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04 
> >

> > This was confirmed by more than one developer, yes.
> > 
> >> I see a patch that is said to improve 6775, can that be applied and
> >> would that resolve this ? 
> >

> > Iiuc, it would not completely resolve the issue, see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > 
> >> If so why was it not applied yet ? 
> >

> > The patch did not get support here, see:
> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
EOF
> > in compat_decode 
> 

> 
>  Is someone working on fixing this better than with the available 
patch ?
>  
> >>>
> >>> I don't even agree this needs fixing. Those projects use the API wrong. 
> >>

> >> Had we documented the correct/wrong use precissely in the past when
> >> these wrong uses where written ?
> >>
> >> Because if it was documented then few should have made the mistake.
> >> But it seems this affects multiple projects, so i wonder if our API
> >> really excluded the use
> >> 
> >

> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> >
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> >
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder 
no longer
> >  * returns frames.
> >
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> >
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> > 
>  
> > For the suggested patch, draining and flushing in the middle of a

> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked). 
> 

>  Did the previous code really work if the frame after a flush was not a
>  new keyframe or there was some use of previous references ? 
> >>>

> >>> ping
> >>>
> >>> so what is the status of this?
> >>>
> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> it closed as invalid. Only one workaround was proposed which was
> >>> claimed to be worse than the code before.
> >>> It seems the discussion died down.
> >>> If theres no activity on this in the next days then i intend to make
> >>> the release with whats in release/3.4 at the time. I dont think
> >>> blind waiting will do any good, id rather release early and often ...
> >>>
> >>> Also if someone wants to write some release notes about this issue,
> >>> that is IMO a good idea ... 
> >>

> >> So this code is completely 

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Martin Vignali]

>
> maybe iam missing something
> but my box doesnt like your test:
>
>
> Is there a link to these recent commit :
https://github.com/FFmpeg/FFmpeg/commit/dc33fe1d0080e932faa9fe3c7fb4850dfde161a8
https://github.com/FFmpeg/FFmpeg/commit/f2aa0ce5a059cf02ee4cbd68111dd2ad622edc85
?

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

Re: [FFmpeg-devel] [PATCH] configure: Allow users to disable all hwaccel libraries

[Tobias Rapp]

On 07.12.2017 10:31, Gyan Doshi wrote:

On 12/7/2017 12:59 PM, Tobias Rapp wrote:


Why not add the HWACCEL_AUTODETECT_LIBRARY_LIST to --disable-hwaccels?


That is a better choice but there wasn't a bespoke case for 
'--disable-hwaccels', so originally ignored that possibility. Added it 
in attached (new) patch.


Either one - this or original patch - works for me.


This one makes more sense to me as "disable all hwaccels" implicitly 
includes autodetected hwaccels, but that's just my personal opinion. I 
leave it to the maintainer of the file to decide what to push.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH 1/2] avfilter: steps to ditch YUVJ formats

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 fftools/ffmpeg.c |  1 +
 fftools/ffmpeg.h |  2 ++
 fftools/ffmpeg_filter.c  | 18 +++---
 libavcodec/avcodec.h |  1 +
 libavcodec/utils.c   |  2 ++
 libavfilter/avfilter.c   |  2 ++
 libavfilter/avfilter.h   |  2 ++
 libavfilter/buffersink.c |  1 +
 libavfilter/buffersink.h |  1 +
 libavfilter/buffersrc.c  | 13 +
 libavfilter/buffersrc.h  |  5 +
 libavfilter/vf_scale.c   |  9 +
 libavfilter/video.c  |  8 +++-
 13 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6aff3366c5..4edf3ee52f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1864,6 +1864,7 @@ static void flush_encoders(void)
 ifilter->width  = par->width;
 ifilter->height = par->height;
 ifilter->sample_aspect_ratio= 
par->sample_aspect_ratio;
+ifilter->color_range= par->color_range;
 }
 }
 
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 4e73d59082..1ad0b1eff1 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -248,6 +248,7 @@ typedef struct InputFilter {
 int format;
 
 int width, height;
+int color_range;
 AVRational sample_aspect_ratio;
 
 int sample_rate;
@@ -271,6 +272,7 @@ typedef struct OutputFilter {
 
 /* desired output stream properties */
 int width, height;
+int color_range;
 AVRational frame_rate;
 int format;
 int sample_rate;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 877fd670e6..3a279106a2 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -449,6 +449,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 OutputStream *ost = ofilter->ost;
 OutputFile*of = output_files[ost->file_index];
 AVFilterContext *last_filter = out->filter_ctx;
+AVDictionaryEntry *cre = NULL;
 int pad_idx = out->pad_idx;
 int ret;
 char name[255];
@@ -461,7 +462,9 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 if (ret < 0)
 return ret;
 
-if (ofilter->width || ofilter->height) {
+cre = av_dict_get(ost->encoder_opts, "color_range", NULL, 0);
+
+if (ofilter->width || ofilter->height || (cre && cre->value) || 
ost->enc->color_range) {
 char args[255];
 AVFilterContext *filter;
 AVDictionaryEntry *e = NULL;
@@ -474,6 +477,12 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 av_strlcatf(args, sizeof(args), ":%s=%s", e->key, e->value);
 }
 
+if (cre && cre->value) {
+av_strlcatf(args, sizeof(args), ":out_range=%s", cre->value);
+} else if (ost->enc->color_range) {
+av_strlcatf(args, sizeof(args), ":out_range=%s", 
av_color_range_name(ost->enc->color_range));
+}
+
 snprintf(name, sizeof(name), "scaler_out_%d_%d",
  ost->file_index, ost->index);
 if ((ret = avfilter_graph_create_filter(, 
avfilter_get_by_name("scale"),
@@ -777,10 +786,11 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 av_bprint_init(, 0, 1);
 av_bprintf(,
  "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d:sws_param=flags=%d",
+ "pixel_aspect=%d/%d:sws_param=flags=%d:color_range=%s",
  ifilter->width, ifilter->height, ifilter->format,
  tb.num, tb.den, sar.num, sar.den,
- SWS_BILINEAR + ((ist->dec_ctx->flags_CODEC_FLAG_BITEXACT) ? 
SWS_BITEXACT:0));
+ SWS_BILINEAR + ((ist->dec_ctx->flags_CODEC_FLAG_BITEXACT) ? 
SWS_BITEXACT:0),
+ av_color_range_name(ist->dec_ctx->color_range));
 if (fr.num && fr.den)
 av_bprintf(, ":frame_rate=%d/%d", fr.num, fr.den);
 snprintf(name, sizeof(name), "graph %d input from stream %d:%d", fg->index,
@@ -1110,6 +1120,7 @@ int configure_filtergraph(FilterGraph *fg)
 
 ofilter->width  = av_buffersink_get_w(sink);
 ofilter->height = av_buffersink_get_h(sink);
+ofilter->color_range = av_buffersink_get_color_range(sink);
 
 ofilter->sample_rate= av_buffersink_get_sample_rate(sink);
 ofilter->channel_layout = av_buffersink_get_channel_layout(sink);
@@ -1182,6 +1193,7 @@ int ifilter_parameters_from_frame(InputFilter *ifilter, 
const AVFrame *frame)
 ifilter->width   = frame->width;
 ifilter->height  = frame->height;
 ifilter->sample_aspect_ratio = frame->sample_aspect_ratio;
+ifilter->color_range = frame->color_range;
 
 ifilter->sample_rate = frame->sample_rate;
 ifilter->channels= frame->channels;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h

[FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/mjpegdec.c| 18 +-
 libavcodec/mjpegenc.c|  6 --
 libavcodec/mjpegenc_common.c |  5 +
 tests/fate/vcodec.mak| 21 ++---
 4 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index e005dd0cd3..55676d8576 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -467,7 +467,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && 
s->component_id[2] == 'A') {
 s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP : 
AV_PIX_FMT_GBRP16;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -509,7 +509,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x22122100:
 case 0x21211100:
 case 0x22211200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -517,7 +517,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x1100:
 case 0x22112200:
 case 0x1100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -549,7 +549,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 } else {
 if (pix_fmt_id == 0x1400)
 s->upscale_v[1] = s->upscale_v[2] = 1;
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV440P : AV_PIX_FMT_YUVJ440P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV440P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -562,7 +562,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 goto unk_pixfmt;
 s->upscale_h[0] = s->upscale_h[1] = 1;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV422P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -570,13 +570,13 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x3100:
 if (s->bits > 8)
 goto unk_pixfmt;
-s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV444P : 
AV_PIX_FMT_YUVJ444P;
+s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 s->upscale_h[1] = s->upscale_h[2] = 2;
 break;
 case 0x22121100:
 case 0x22111200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -584,7 +584,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x2200:
 case 0x4200:
 case 0x2400:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUVJ420P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV420P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 if (pix_fmt_id == 0x4200) {
@@ -598,7 +598,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 }
 break;
 case 0x4100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV411P : AV_PIX_FMT_YUVJ411P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV411P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index d2fcb8e191..9602a6fe64 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -415,8 +415,9 @@ AVCodec ff_mjpeg_encoder = {
 .close  = ff_mpv_encode_end,
 .capabilities   = AV_CODEC_CAP_SLICE_THREADS | 

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 09:40:41PM +0100, Martin Vignali wrote:
> Hello,
> 
> Patch in attach add a checkasm test for vf_hflip (byte and short)
> 
> Martin

>  hflip.h|1 +
>  vf_hflip.c |   14 ++
>  2 files changed, 11 insertions(+), 4 deletions(-)
> cac8c66112fd43e63d2fc734a66a156ad37e3d0d  
> 0001-avfilter-vf_hflip-move-context-func-init-in.patch
> From 16dde326c4ffd8ddf22dbf891c5fc3c093ad8a28 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Thu, 7 Dec 2017 21:35:42 +0100
> Subject: [PATCH 1/2] avfilter/vf_hflip : move context func init in 
>  ff_hflip_init
> 
> ---
>  libavfilter/hflip.h|  1 +
>  libavfilter/vf_hflip.c | 14 ++
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
> index cbe1fb3d8c..204090dbb4 100644
> --- a/libavfilter/hflip.h
> +++ b/libavfilter/hflip.h
> @@ -33,6 +33,7 @@ typedef struct FlipContext {
>  void (*flip_line[4])(const uint8_t *src, uint8_t *dst, int w);
>  } FlipContext;
>  
> +int ff_hflip_init(FlipContext *s, int step[4], int nb_planes);
>  void ff_hflip_init_x86(FlipContext *s, int step[4], int nb_planes);
>  
>  #endif /* AVFILTER_HFLIP_H */
> diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
> index 957ddd9900..b77afc77fc 100644
> --- a/libavfilter/vf_hflip.c
> +++ b/libavfilter/vf_hflip.c
> @@ -131,7 +131,7 @@ static int config_props(AVFilterLink *inlink)
>  const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
>  const int hsub = pix_desc->log2_chroma_w;
>  const int vsub = pix_desc->log2_chroma_h;
> -int nb_planes, i;
> +int nb_planes;
>  
>  av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
>  s->planewidth[0]  = s->planewidth[3]  = inlink->w;
> @@ -141,8 +141,15 @@ static int config_props(AVFilterLink *inlink)
>  
>  nb_planes = av_pix_fmt_count_planes(inlink->format);
>  
> +return ff_hflip_init(s, s->max_step, nb_planes);
> +}
> +
> +int ff_hflip_init(FlipContext *s, int step[4], int nb_planes)
> +{
> +int i;
> +
>  for (i = 0; i < nb_planes; i++) {
> -switch (s->max_step[i]) {
> +switch (step[i]) {
>  case 1: s->flip_line[i] = hflip_byte_c;  break;
>  case 2: s->flip_line[i] = hflip_short_c; break;
>  case 3: s->flip_line[i] = hflip_b24_c;   break;
> @@ -153,9 +160,8 @@ static int config_props(AVFilterLink *inlink)
>  return AVERROR_BUG;
>  }
>  }
> -
>  if (ARCH_X86)
> -ff_hflip_init_x86(s, s->max_step, nb_planes);
> +ff_hflip_init_x86(s, step, nb_planes);
>  
>  return 0;
>  }
> -- 
> 2.11.0 (Apple Git-81)
> 

>  checkasm/Makefile   |1 
>  checkasm/checkasm.c |3 ++
>  checkasm/checkasm.h |1 
>  checkasm/vf_hflip.c |   74 
> 
>  fate/checkasm.mak   |1 
>  5 files changed, 80 insertions(+)
> 8e11138c838a238905257fd6d1ed47be49ee1d37  
> 0002-checkasm-vf_hflip-add-test-for-vf_hflip-byte-and-sho.patch
> From 1012af32158bc1d387afdc9fc5cacd83894b77d0 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Thu, 7 Dec 2017 21:38:20 +0100
> Subject: [PATCH 2/2] checkasm/vf_hflip : add test for vf_hflip byte and short 
>  simd

maybe iam missing something
but my box doesnt like your test:

TESTcheckasm-vf_hflip
Test checkasm-vf_hflip failed. Look at tests/data/fate/checkasm-vf_hflip.err 
for details.
make: *** [fate-checkasm-vf_hflip] Error 1
michael@sandybox:~/ffmpeg-git/ffmpeg$ cat tests/data/fate/checkasm-vf_hflip.err
checkasm: using random seed 358531722
SSSE3:
   hflip_byte_ssse3 (vf_hflip.c:63)
 - vf_hflip.hflip_byte  [FAILED]
   hflip_short_ssse3 (vf_hflip.c:63)
 - vf_hflip.hflip_short [FAILED]
checkasm: 2 of 2 tests have failed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:
> On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
>  wrote:
> > Its already done by lockmgr.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/utils.c | 6 --
> >  1 file changed, 6 deletions(-)
> >
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index baf09119fe..796d24dcbb 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp 
> > op) = NULL;
> >  #endif
> >
> >
> > -static atomic_bool ff_avcodec_locked;
> >  static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
> >  static void *codec_mutex;
> >  static void *avformat_mutex;
> > @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
> > AVLockOp op))
> >
> >  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> >  {
> > -_Bool exp = 0;
> >  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || 
> > !codec->init)
> >  return 0;
> >
> > @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const 
> > AVCodec *codec)
> > atomic_load(_thread_counter));
> >  if (!lockmgr_cb)
> >  av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set, please 
> > see av_lockmgr_register()\n");
> > -atomic_store(_avcodec_locked, 1);
> >  ff_unlock_avcodec(codec);
> >  return AVERROR(EINVAL);
> >  }
> > -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 
> > 1));
> >  return 0;
> >  }
> >
> >  int ff_unlock_avcodec(const AVCodec *codec)
> >  {
> > -_Bool exp = 1;
> >  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || 
> > !codec->init)
> >  return 0;
> >
> > -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 
> > 0));
> >  atomic_fetch_add(_thread_counter, -1);
> >  if (lockmgr_cb) {
> >  if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
> > --
> > 2.15.1.424.g9478a66081
> >
> 
> These variables never performed any locking, they only existed as a
> sanity check that lock/unlock is always called in pairs. If that is
> really required is up for discussion.

They shuld be usefull to detect some bugs related to locking

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Paul B Mahol]

On 12/8/17, Hendrik Leppkes  wrote:
> On Fri, Dec 8, 2017 at 10:46 AM, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/mjpegdec.c| 18 +-
>>  libavcodec/mjpegenc.c|  4 ++--
>>  libavcodec/mjpegenc_common.c |  5 +
>>  tests/fate/vcodec.mak| 21 ++---
>>  4 files changed, 26 insertions(+), 22 deletions(-)
>>
>> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
>> index d2fcb8e191..5f7b685e56 100644
>> --- a/libavcodec/mjpegenc.c
>> +++ b/libavcodec/mjpegenc.c
>> @@ -415,7 +415,7 @@ AVCodec ff_mjpeg_encoder = {
>>  .close  = ff_mpv_encode_end,
>>  .capabilities   = AV_CODEC_CAP_SLICE_THREADS |
>> AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
>>  .pix_fmts   = (const enum AVPixelFormat[]) {
>> -AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>> AV_PIX_FMT_NONE
>> +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
>> AV_PIX_FMT_NONE
>>  },
>
> This will basically break everyone encoding mjpeg right now, since it
> suddenly only accepts different formats without any common-ground
> before/after.
> Furthermore, there is no replacement for the indication that this
> encoder wants full-range data, which the old pixfmts indicated.

So I will add .color_range to AVCodec
0 means encoder supports both.

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

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Hendrik Leppkes]

On Fri, Dec 8, 2017 at 10:46 AM, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/mjpegdec.c| 18 +-
>  libavcodec/mjpegenc.c|  4 ++--
>  libavcodec/mjpegenc_common.c |  5 +
>  tests/fate/vcodec.mak| 21 ++---
>  4 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index d2fcb8e191..5f7b685e56 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -415,7 +415,7 @@ AVCodec ff_mjpeg_encoder = {
>  .close  = ff_mpv_encode_end,
>  .capabilities   = AV_CODEC_CAP_SLICE_THREADS | 
> AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
>  .pix_fmts   = (const enum AVPixelFormat[]) {
> -AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, 
> AV_PIX_FMT_NONE
> +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, 
> AV_PIX_FMT_NONE
>  },

This will basically break everyone encoding mjpeg right now, since it
suddenly only accepts different formats without any common-ground
before/after.
Furthermore, there is no replacement for the indication that this
encoder wants full-range data, which the old pixfmts indicated.

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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Am 30.11.2017 17:40, schrieb Michael Niedermayer:

yes, if you dont set it, it will be computet but it would give some
latency on startup as it needs a few frames first to base the 
computation

on. This latency may or may not be a bigger problem than slightly
incorrect values. I dont know, its up to you i think what you feel
is more important


I tested it, it works way better when setting it manually so I will 
leave it like it is.


I've done some further fixes and adjustments to the patch, I attached 
the newest version.


It now works on Android 7 and 8 (tested on Nexus 9 and Pixel 2).From 80182b2ec0c2fc76584c71a7138c58b4716d5d5f Mon Sep 17 00:00:00 2001
From: Felix Matouschek 
Date: Fri, 8 Dec 2017 10:43:51 +0100
Subject: [PATCH] avdevice: add android_camera indev
To: ffmpeg-devel@ffmpeg.org

This commit adds an indev for Android devices on API level 24+ which
uses the Android NDK Camera2 API to capture video from builtin cameras

Signed-off-by: Felix Matouschek 
---
 Changelog|   1 +
 MAINTAINERS  |   1 +
 configure|   6 +
 doc/indevs.texi  |  40 ++
 libavdevice/Makefile |   1 +
 libavdevice/alldevices.c |   1 +
 libavdevice/android_camera.c | 866 +++
 libavdevice/version.h|   2 +-
 8 files changed, 917 insertions(+), 1 deletion(-)
 create mode 100644 libavdevice/android_camera.c

diff --git a/Changelog b/Changelog
index 6592d868da..f58cd810e0 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
   requires 2.1 (or later) and pkg-config.
 - VDA dropped (use VideoToolbox instead)
+- Add android_camera indev
 
 
 version 3.4:
diff --git a/MAINTAINERS b/MAINTAINERS
index 1d2ff78b0e..d6cb135964 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -281,6 +281,7 @@ libavdevice
 
 
   avfoundation.mThilo Borgmann
+  android_camera.c  Felix Matouschek
   decklink* Marton Balint
   dshow.c   Roger Pack (CC rogerdp...@gmail.com)
   fbdev_enc.c   Lukasz Marek
diff --git a/configure b/configure
index 7a53bc76c7..d52b18fab3 100755
--- a/configure
+++ b/configure
@@ -3068,6 +3068,8 @@ xmv_demuxer_select="riffdec"
 xwma_demuxer_select="riffdec"
 
 # indevs / outdevs
+android_camera_indev_deps="android camera2ndk mediandk pthreads"
+android_camera_indev_extralibs="-landroid -lcamera2ndk -lmediandk"
 alsa_indev_deps="alsa"
 alsa_outdev_deps="alsa"
 avfoundation_indev_deps="avfoundation corevideo coremedia pthreads"
@@ -5836,6 +5838,10 @@ check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
+check_lib android android/native_window.h ANativeWindow_acquire -landroid
+check_lib mediandk "stdint.h media/NdkImage.h" AImage_delete -lmediandk
+check_lib camera2ndk "stdbool.h stdint.h camera/NdkCameraManager.h" ACameraManager_create -lcamera2ndk
+
 enabled appkit   && check_apple_framework AppKit
 enabled audiotoolbox && check_apple_framework AudioToolbox
 enabled avfoundation && check_apple_framework AVFoundation
diff --git a/doc/indevs.texi b/doc/indevs.texi
index d308bbf7de..07056d762e 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -63,6 +63,46 @@ Set the number of channels. Default is 2.
 
 @end table
 
+@section android_camera
+
+Android camera input device.
+
+This input devices uses the Android Camera2 NDK API which is
+available on devices with API level 24+. The availability of
+android_camera is autodetected during configuration.
+
+This device allows capturing from all cameras on an Android device,
+which are integrated into the Camera2 NDK API.
+
+The available cameras are enumerated internally and can be selected
+with the @var{camera_index} parameter. The input file string is
+discarded.
+
+Generally the back facing camera has index 0 while the front facing
+camera has index 1.
+
+@subsection Options
+
+@table @option
+
+@item video_size
+Set the video size given as a string such as 640x480 or hd720.
+Falls back to the first available configuration reported by
+Android if requested video size is not available or by default.
+
+@item framerate
+Set the video framerate.
+Falls back to the first available configuration reported by
+Android if requested framerate is not available or by default (-1).
+
+@item camera_index
+Set the index of the camera to use. Default is 0.
+
+@item input_queue_size
+Set the maximum number of frames to buffer. Default is 5.
+
+@end table
+
 @section avfoundation
 
 AVFoundation input device.
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 8228d62147..f11a6f2a86 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile

[FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/mjpegdec.c| 18 +-
 libavcodec/mjpegenc.c|  4 ++--
 libavcodec/mjpegenc_common.c |  5 +
 tests/fate/vcodec.mak| 21 ++---
 4 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index e005dd0cd3..55676d8576 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -467,7 +467,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && 
s->component_id[2] == 'A') {
 s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP : 
AV_PIX_FMT_GBRP16;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -509,7 +509,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x22122100:
 case 0x21211100:
 case 0x22211200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -517,7 +517,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x1100:
 case 0x22112200:
 case 0x1100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -549,7 +549,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 } else {
 if (pix_fmt_id == 0x1400)
 s->upscale_v[1] = s->upscale_v[2] = 1;
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV440P : AV_PIX_FMT_YUVJ440P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV440P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -562,7 +562,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 goto unk_pixfmt;
 s->upscale_h[0] = s->upscale_h[1] = 1;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV422P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -570,13 +570,13 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x3100:
 if (s->bits > 8)
 goto unk_pixfmt;
-s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV444P : 
AV_PIX_FMT_YUVJ444P;
+s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 s->upscale_h[1] = s->upscale_h[2] = 2;
 break;
 case 0x22121100:
 case 0x22111200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -584,7 +584,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x2200:
 case 0x4200:
 case 0x2400:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUVJ420P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV420P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 if (pix_fmt_id == 0x4200) {
@@ -598,7 +598,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 }
 break;
 case 0x4100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV411P : AV_PIX_FMT_YUVJ411P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV411P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index d2fcb8e191..5f7b685e56 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -415,7 +415,7 @@ AVCodec ff_mjpeg_encoder = {
 .close  = ff_mpv_encode_end,
 .capabilities   = AV_CODEC_CAP_SLICE_THREADS | 

[FFmpeg-devel] [PATCH 1/2] avfilter: steps to ditch YUVJ formats

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---

Now with fate passing for mjpeg.
Are all these changes OK?

---
 fftools/ffmpeg.c |  1 +
 fftools/ffmpeg.h |  2 ++
 fftools/ffmpeg_filter.c  | 16 +---
 libavfilter/avfilter.c   |  2 ++
 libavfilter/avfilter.h   |  2 ++
 libavfilter/buffersink.c |  1 +
 libavfilter/buffersink.h |  1 +
 libavfilter/buffersrc.c  | 13 +
 libavfilter/buffersrc.h  |  5 +
 libavfilter/vf_scale.c   |  9 +
 libavfilter/video.c  |  8 +++-
 11 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6aff3366c5..4edf3ee52f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1864,6 +1864,7 @@ static void flush_encoders(void)
 ifilter->width  = par->width;
 ifilter->height = par->height;
 ifilter->sample_aspect_ratio= 
par->sample_aspect_ratio;
+ifilter->color_range= par->color_range;
 }
 }
 
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 4e73d59082..1ad0b1eff1 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -248,6 +248,7 @@ typedef struct InputFilter {
 int format;
 
 int width, height;
+int color_range;
 AVRational sample_aspect_ratio;
 
 int sample_rate;
@@ -271,6 +272,7 @@ typedef struct OutputFilter {
 
 /* desired output stream properties */
 int width, height;
+int color_range;
 AVRational frame_rate;
 int format;
 int sample_rate;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 877fd670e6..d7b6c79d00 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -449,6 +449,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 OutputStream *ost = ofilter->ost;
 OutputFile*of = output_files[ost->file_index];
 AVFilterContext *last_filter = out->filter_ctx;
+AVDictionaryEntry *cre = NULL;
 int pad_idx = out->pad_idx;
 int ret;
 char name[255];
@@ -461,7 +462,9 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 if (ret < 0)
 return ret;
 
-if (ofilter->width || ofilter->height) {
+cre = av_dict_get(ost->encoder_opts, "color_range", NULL, 0);
+
+if (ofilter->width || ofilter->height || (cre && cre->value)) {
 char args[255];
 AVFilterContext *filter;
 AVDictionaryEntry *e = NULL;
@@ -474,6 +477,10 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 av_strlcatf(args, sizeof(args), ":%s=%s", e->key, e->value);
 }
 
+if (cre && cre->value) {
+av_strlcatf(args, sizeof(args), ":out_range=%s", cre->value);
+}
+
 snprintf(name, sizeof(name), "scaler_out_%d_%d",
  ost->file_index, ost->index);
 if ((ret = avfilter_graph_create_filter(, 
avfilter_get_by_name("scale"),
@@ -777,10 +784,11 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 av_bprint_init(, 0, 1);
 av_bprintf(,
  "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d:sws_param=flags=%d",
+ "pixel_aspect=%d/%d:sws_param=flags=%d:color_range=%s",
  ifilter->width, ifilter->height, ifilter->format,
  tb.num, tb.den, sar.num, sar.den,
- SWS_BILINEAR + ((ist->dec_ctx->flags_CODEC_FLAG_BITEXACT) ? 
SWS_BITEXACT:0));
+ SWS_BILINEAR + ((ist->dec_ctx->flags_CODEC_FLAG_BITEXACT) ? 
SWS_BITEXACT:0),
+ av_color_range_name(ist->dec_ctx->color_range));
 if (fr.num && fr.den)
 av_bprintf(, ":frame_rate=%d/%d", fr.num, fr.den);
 snprintf(name, sizeof(name), "graph %d input from stream %d:%d", fg->index,
@@ -1110,6 +1118,7 @@ int configure_filtergraph(FilterGraph *fg)
 
 ofilter->width  = av_buffersink_get_w(sink);
 ofilter->height = av_buffersink_get_h(sink);
+ofilter->color_range = av_buffersink_get_color_range(sink);
 
 ofilter->sample_rate= av_buffersink_get_sample_rate(sink);
 ofilter->channel_layout = av_buffersink_get_channel_layout(sink);
@@ -1182,6 +1191,7 @@ int ifilter_parameters_from_frame(InputFilter *ifilter, 
const AVFrame *frame)
 ifilter->width   = frame->width;
 ifilter->height  = frame->height;
 ifilter->sample_aspect_ratio = frame->sample_aspect_ratio;
+ifilter->color_range = frame->color_range;
 
 ifilter->sample_rate = frame->sample_rate;
 ifilter->channels= frame->channels;
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b98b32bacb..4a579bb49d 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -336,6 +336,8 @@ int avfilter_config_links(AVFilterContext *filter)
  

Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: Fix capability check with old drivers.

[Timo Rothenpieler]

lgtm, feel free to push or remind me to do so if I forget



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: creation of variant streams in subdirectories

[vdixit]

From: Vishwanath Dixit 

---
 doc/muxers.texi  | 33 -
 libavformat/hlsenc.c | 68 +---
 2 files changed, 92 insertions(+), 9 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f53cc10..1a22892 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -587,6 +587,20 @@ This example will produce the playlists segment file sets:
 @file{file_0_000.ts}, @file{file_0_001.ts}, @file{file_0_002.ts}, etc. and
 @file{file_1_000.ts}, @file{file_1_001.ts}, @file{file_1_002.ts}, etc.
 
+The string "%v" may be present in the filename or in the last directory name
+containing the file. If the string is present in the directory name, then
+sub-directories are created after expanding the directory name pattern. This
+enables creation of segments corresponding to different variant streams in
+subdirectories.
+@example
+ffmpeg -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
+  -map 0:v -map 0:a -map 0:v -map 0:a -f hls -var_stream_map "v:0,a:0 v:1,a:1" 
\
+  -hls_segment_filename 'vs%v/file_%03d.ts' vs%v/out.m3u8
+@end example
+This example will produce the playlists segment file sets:
+@file{vs0/file_000.ts}, @file{vs0/file_001.ts}, @file{vs0/file_002.ts}, etc. 
and
+@file{vs1/file_000.ts}, @file{vs1/file_001.ts}, @file{vs1/file_002.ts}, etc.
+
 @item use_localtime
 Use strftime() on @var{filename} to expand the segment filename with localtime.
 The segment number is also available in this mode, but to use it, you need to 
specify second_level_segment_index
@@ -715,6 +729,11 @@ set filename to the fragment files header file, default 
filename is @file{init.m
 When @code{var_stream_map} is set with two or more variant streams, the
 @var{filename} pattern must contain the string "%v", this string specifies
 the position of variant stream index in the generated init file names.
+The string "%v" may be present in the filename or in the last directory name
+containing the file. If the string is present in the directory name, then
+sub-directories are created after expanding the directory name pattern. This
+enables creation of init files corresponding to different variant streams in
+subdirectories.
 
 @item hls_flags @var{flags}
 Possible values:
@@ -831,7 +850,11 @@ Allowed values are 0 to 9 (limited just based on practical 
usage).
 
 When there are two or more variant streams, the output filename pattern must
 contain the string "%v", this string specifies the position of variant stream
-index in the output media playlist filenames.
+index in the output media playlist filenames. The string "%v" may be present in
+the filename or in the last directory name containing the file. If the string 
is
+present in the directory name, then sub-directories are created after expanding
+the directory name pattern. This enables creation of variant streams in
+subdirectories.
 
 @example
 ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
@@ -853,6 +876,14 @@ be a video only stream with video bitrate 1000k, the 
second variant stream will
 be an audio only stream with bitrate 64k and the third variant stream will be a
 video only stream with bitrate 256k. Here, three media playlist with file names
 out_0.m3u8, out_1.m3u8 and out_2.m3u8 will be created.
+@example
+ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
+  -map 0:v -map 0:a -map 0:v -map 0:a -f hls -var_stream_map "v:0,a:0 v:1,a:1" 
\
+  http://example.com/live/vs_%v/out.m3u8
+@end example
+This example creates the variant streams in subdirectories. Here, the first
+media playlist is created at @file{http://example.com/live/vs_0/out.m3u8} and
+the second one at @file{http://example.com/live/vs_1/out.m3u8}.
 
 By default, a single hls variant containing all the encoded streams is created.
 
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 27ea690..541ce88 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1479,7 +1479,8 @@ static int append_postfix(char *name, int name_buf_len, 
int i)
 
 static int validate_name(int nb_vs, const char *fn)
 {
-const char *filename;
+const char *filename, *subdir_name;
+char *fn_dup = NULL;
 int ret = 0;
 
 if (!fn) {
@@ -1487,22 +1488,38 @@ static int validate_name(int nb_vs, const char *fn)
 goto fail;
 }
 
+fn_dup = av_strdup(fn);
+if (!fn_dup) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
 filename = av_basename(fn);
+subdir_name = av_dirname(fn_dup);
 
-if (nb_vs > 1 && !av_stristr(filename, "%v")) {
+if (nb_vs > 1 && !av_stristr(filename, "%v") && !av_stristr(subdir_name, 
"%v")) {
 av_log(NULL, AV_LOG_ERROR, "More than 1 variant streams are present, 
%%v is expected in the filename %s\n",
 fn);
 ret = AVERROR(EINVAL);
 goto fail;
 }
 
+if (av_stristr(filename, "%v") && av_stristr(subdir_name, "%v")) {
+av_log(NULL, AV_LOG_ERROR, "%%v is 

[FFmpeg-devel] [PATCH 1/3] avformat/hlsenc: revamped master playlist url creation logic

[vdixit]

From: Vishwanath Dixit 

---
 libavformat/hlsenc.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7dc8f42..fa44760 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1612,28 +1612,30 @@ static int update_variant_stream_info(AVFormatContext 
*s) {
 
 static int update_master_pl_info(AVFormatContext *s) {
 HLSContext *hls = s->priv_data;
-int m3u8_name_size, ret;
-char *p;
+const char *dir;
+char *fn;
+int ret = 0;
 
-m3u8_name_size = strlen(s->filename) + strlen(hls->master_pl_name) + 1;
-hls->master_m3u8_url = av_malloc(m3u8_name_size);
-if (!hls->master_m3u8_url) {
+fn = av_strdup(s->filename);
+if (!fn) {
 ret = AVERROR(ENOMEM);
-return ret;
+goto fail;
 }
 
-av_strlcpy(hls->master_m3u8_url, s->filename, m3u8_name_size);
-p = strrchr(hls->master_m3u8_url, '/') ?
-strrchr(hls->master_m3u8_url, '/') :
-strrchr(hls->master_m3u8_url, '\\');
-if (p) {
-*(p + 1) = '\0';
-av_strlcat(hls->master_m3u8_url, hls->master_pl_name, m3u8_name_size);
-} else {
-av_strlcpy(hls->master_m3u8_url, hls->master_pl_name, m3u8_name_size);
+dir = av_dirname(fn);
+if (dir && strcmp(dir, "."))
+hls->master_m3u8_url = av_append_path_component(dir, 
hls->master_pl_name);
+else
+hls->master_m3u8_url = av_strdup(hls->master_pl_name);
+
+if (!hls->master_m3u8_url) {
+ret = AVERROR(ENOMEM);
+goto fail;
 }
 
-return 0;
+fail:
+av_freep();
+return ret;
 }
 
 static int hls_write_header(AVFormatContext *s)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/3] avformat/hlsenc: configurable variant stream index position in filenames

[vdixit]

From: Vishwanath Dixit 

---
 doc/muxers.texi  |  29 --
 libavformat/hlsenc.c | 154 ++-
 2 files changed, 126 insertions(+), 57 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 3d0c7bf..f53cc10 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -575,6 +575,17 @@ Should a relative path be specified, the path of the 
created segment
 files will be relative to the current working directory.
 When use_localtime_mkdir is set, the whole expanded value of @var{filename} 
will be written into the m3u8 segment list.
 
+When @code{var_stream_map} is set with two or more variant streams, the
+@var{filename} pattern must contain the string "%v", this string specifies
+the position of variant stream index in the generated segment file names.
+@example
+ffmpeg -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
+  -map 0:v -map 0:a -map 0:v -map 0:a -f hls -var_stream_map "v:0,a:0 v:1,a:1" 
\
+  -hls_segment_filename 'file_%v_%03d.ts' out_%v.m3u8
+@end example
+This example will produce the playlists segment file sets:
+@file{file_0_000.ts}, @file{file_0_001.ts}, @file{file_0_002.ts}, etc. and
+@file{file_1_000.ts}, @file{file_1_001.ts}, @file{file_1_002.ts}, etc.
 
 @item use_localtime
 Use strftime() on @var{filename} to expand the segment filename with localtime.
@@ -701,6 +712,10 @@ the fmp4 files is used in hls after version 7.
 @item hls_fmp4_init_filename @var{filename}
 set filename to the fragment files header file, default filename is 
@file{init.mp4}.
 
+When @code{var_stream_map} is set with two or more variant streams, the
+@var{filename} pattern must contain the string "%v", this string specifies
+the position of variant stream index in the generated init file names.
+
 @item hls_flags @var{flags}
 Possible values:
 
@@ -814,26 +829,30 @@ Expected string format is like this "a:0,v:0 a:1,v:1 
". Here a:, v:, s: are
 the keys to specify audio, video and subtitle streams respectively.
 Allowed values are 0 to 9 (limited just based on practical usage).
 
+When there are two or more variant streams, the output filename pattern must
+contain the string "%v", this string specifies the position of variant stream
+index in the output media playlist filenames.
+
 @example
 ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
   -map 0:v -map 0:a -map 0:v -map 0:a -f hls -var_stream_map "v:0,a:0 v:1,a:1" 
\
-  http://example.com/live/out.m3u8
+  http://example.com/live/out_%v.m3u8
 @end example
 This example creates two hls variant streams. The first variant stream will
 contain video stream of bitrate 1000k and audio stream of bitrate 64k and the
 second variant stream will contain video stream of bitrate 256k and audio
-stream of bitrate 32k. Here, two media playlist with file names out_1.m3u8 and
-out_2.m3u8 will be created.
+stream of bitrate 32k. Here, two media playlist with file names out_0.m3u8 and
+out_1.m3u8 will be created.
 @example
 ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k \
   -map 0:v -map 0:a -map 0:v -f hls -var_stream_map "v:0 a:0 v:1" \
-  http://example.com/live/out.m3u8
+  http://example.com/live/out_%v.m3u8
 @end example
 This example creates three hls variant streams. The first variant stream will
 be a video only stream with video bitrate 1000k, the second variant stream will
 be an audio only stream with bitrate 64k and the third variant stream will be a
 video only stream with bitrate 256k. Here, three media playlist with file names
-out_1.m3u8, out_2.m3u8 and out_3.m3u8 will be created.
+out_0.m3u8, out_1.m3u8 and out_2.m3u8 will be created.
 
 By default, a single hls variant containing all the encoded streams is created.
 
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index fa44760..27ea690 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1458,7 +1458,7 @@ static const char * 
get_default_pattern_localtime_fmt(AVFormatContext *s)
 return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || !strcmp(b, 
"%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
 }
 
-static int format_name(char *name, int name_buf_len, int i)
+static int append_postfix(char *name, int name_buf_len, int i)
 {
 char *p;
 char extension[10] = {'\0'};
@@ -1477,6 +1477,53 @@ static int format_name(char *name, int name_buf_len, int 
i)
 return 0;
 }
 
+static int validate_name(int nb_vs, const char *fn)
+{
+const char *filename;
+int ret = 0;
+
+if (!fn) {
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+filename = av_basename(fn);
+
+if (nb_vs > 1 && !av_stristr(filename, "%v")) {
+av_log(NULL, AV_LOG_ERROR, "More than 1 variant streams are present, 
%%v is expected in the filename %s\n",
+fn);
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+fail:
+return ret;
+}
+
+static int format_name(char *buf, int buf_len, int index)
+{
+char *orig_buf_dup = NULL;
+int ret = 

Re: [FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

[Hendrik Leppkes]

On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
 wrote:
> Its already done by lockmgr.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/utils.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..796d24dcbb 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp op) 
> = NULL;
>  #endif
>
>
> -static atomic_bool ff_avcodec_locked;
>  static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
>  static void *codec_mutex;
>  static void *avformat_mutex;
> @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
> AVLockOp op))
>
>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>  {
> -_Bool exp = 0;
>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>  return 0;
>
> @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const 
> AVCodec *codec)
> atomic_load(_thread_counter));
>  if (!lockmgr_cb)
>  av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set, please 
> see av_lockmgr_register()\n");
> -atomic_store(_avcodec_locked, 1);
>  ff_unlock_avcodec(codec);
>  return AVERROR(EINVAL);
>  }
> -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 1));
>  return 0;
>  }
>
>  int ff_unlock_avcodec(const AVCodec *codec)
>  {
> -_Bool exp = 1;
>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>  return 0;
>
> -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 0));
>  atomic_fetch_add(_thread_counter, -1);
>  if (lockmgr_cb) {
>  if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
> --
> 2.15.1.424.g9478a66081
>

These variables never performed any locking, they only existed as a
sanity check that lock/unlock is always called in pairs. If that is
really required is up for discussion.

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

Re: [FFmpeg-devel] [PATCH] vf_zscale: Fix alpha destination graph for floating point pixel formats

[Paul B Mahol]

On 12/7/17, Vittorio Giovara  wrote:
> This was setting the input pixel type instead of the output one,
> leading to incorrect data being fed to the library.
>
> Signed-off-by: Vittorio Giovara 
> ---
>  libavfilter/vf_zscale.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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