[FFmpeg-devel] [PATCH] mpegdec: fix redundant dummy frames issue of interlaced clips

[Zhong Li]

It is to fix https://trac.ffmpeg.org/ticket/6677. Actucally it is a
regression of commit 99e07a4453732058df90885f80b3db3b4f37cb3c which
always inserts a dummy frame when decode the first key field picture.

Signed-off-by: Zhong Li 
---
 libavcodec/mpegvideo.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 82b94253ae..c4089972f0 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -1283,8 +1283,7 @@ int ff_mpv_frame_start(MpegEncContext *s, AVCodecContext 
*avctx)
 s->pict_type, s->droppable);
 
 if ((!s->last_picture_ptr || !s->last_picture_ptr->f->buf[0]) &&
-(s->pict_type != AV_PICTURE_TYPE_I ||
- s->picture_structure != PICT_FRAME)) {
+(s->pict_type != AV_PICTURE_TYPE_I)) {
 int h_chroma_shift, v_chroma_shift;
 av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt,
  _chroma_shift, _chroma_shift);
@@ -1294,9 +1293,6 @@ int ff_mpv_frame_start(MpegEncContext *s, AVCodecContext 
*avctx)
 else if (s->pict_type != AV_PICTURE_TYPE_I)
 av_log(avctx, AV_LOG_ERROR,
"warning: first frame is no keyframe\n");
-else if (s->picture_structure != PICT_FRAME)
-av_log(avctx, AV_LOG_DEBUG,
-   "allocate dummy last picture for field based first 
keyframe\n");
 
 /* Allocate a dummy frame */
 i = ff_find_unused_picture(s->avctx, s->picture, 0);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] maintainers: add myself to the general developers list

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 03:03:23AM +0300, Jan Ekström wrote:
> ---
> 
> It was recommended to me that I do this, as I do not maintain
> any specific functionality/module as such. 
> 
> Jan
> 
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH v4] avcodec/hevc_sei: Support HEVC paired fields.

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 08:33:03PM -0300, James Almer wrote:
> On 9/29/2017 8:01 PM, Michael Niedermayer wrote:
> > On Fri, Sep 29, 2017 at 12:30:48AM -0300, James Almer wrote:
> >> On 9/28/2017 7:09 PM, Michael Niedermayer wrote:
> >>> On Wed, Sep 27, 2017 at 08:48:42PM -0500, Brian Matherly wrote:
>  From: Brian Matherly 
> 
>  Correctly set the interlaced_frame and top_field_first fields when 
>  pic_struct
>  indicates paired fields.
>  ---
>   libavcodec/hevc_sei.c |  4 ++--
>   tests/fate/hevc.mak   |  6 +-
>   tests/ref/fate/hevc-paired-fields | 16 
>   3 files changed, 23 insertions(+), 3 deletions(-)
>   create mode 100644 tests/ref/fate/hevc-paired-fields
> >>>
> >>> this can be applied in 24h (after the fate sample is synced between
> >>> fate cliensts)
> >>> unless someone sees a issue in the patch
> >>
> >> I thought we had dropped the waiting period?
> > 
> > I think some fate clients still have issues with it but please Correct
> > me if iam wrong.
> 
> I don't know, i just recall that in the past few months we didn't bother
> waiting and just pushed the tests as soon as the samples were uploaded.
> 
> It's moot now in any case, seeing almost 24 hours have passed :p

yes, will apply

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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/bit: Fix the G.729 bit auto-detection

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 07:23:17PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> The G.729 bit auto-detection has never worked, patch attached.
> 
> Please comment, Carl Eugen

>  bit.c |   23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 1eaabbb2e56d350949d0c8c439a2ba49513069f2  
> 0001-lavf-bit-Fix-the-G.729-bit-probe-function.patch
> From 2521a9bd86d807a3e18fe930b35039beb7674b3e Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 29 Sep 2017 19:10:46 +0200
> Subject: [PATCH] lavf/bit: Fix the G.729 bit auto-detection.
> 
> ---
>  libavformat/bit.c |   23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/libavformat/bit.c b/libavformat/bit.c
> index d742a5b..f90e4a7 100644
> --- a/libavformat/bit.c
> +++ b/libavformat/bit.c
> @@ -32,20 +32,23 @@
>  #if CONFIG_BIT_DEMUXER
>  static int probe(AVProbeData *p)
>  {
> -int i, j;
> +int i = 0, j, valid = 0;
>  
> -if(p->buf_size < 0x40)
> -return 0;
> -
> -for(i=0; i+3buf_size && i< 10*0x50; ){
> -if(AV_RL16(>buf[0]) != SYNC_WORD)
> +while (2 * i + 3 < p->buf_size){
> +if (AV_RL16(>buf[2 * i++]) != SYNC_WORD)
>  return 0;
> -j=AV_RL16(>buf[2]);
> -if(j!=0x40 && j!=0x50)
> +j = AV_RL16(>buf[2 * i++]);
> +if (j != 0 && j != 0x10 && j != 0x40 && j != 0x50)
>  return 0;
> -i+=j;
> +if (j)
> +valid++;
> +i += j;
>  }
> -return AVPROBE_SCORE_EXTENSION;
> +if (valid > 10)
> +return AVPROBE_SCORE_MAX;

this looks like a g729 stream encapsulated i another container could
return AVPROBE_SCORE_MAX. This may be sub optimal

no more comments from me

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] movenc: take packet dts shifting into mention in check_pkt

[Michael Niedermayer]

On Sat, Sep 30, 2017 at 01:04:00AM +0300, Jan Ekström wrote:
> This FFmpeg-specific "fuzzer fix" was never perfect, but now it
> stopped encoding of actual content with a big enough DTS shift.
> This returns the function to its original state of results
> before negative CTS offsets were added.
> 
> I remember dealing with this function before, but somehow had
> forgotten about it during VDD. The test cases not tripping this
> over also didn't help.
> ---
>  libavformat/movenc.c | 6 ++
>  1 file changed, 6 insertions(+)

makes sense

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] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 05:08:16PM +0200, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  libavformat/wavenc.c | 5 -
>  tests/ref/lavf/wav_peak_only | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)

The commit message doest say why this chnage is done

[...]
-- 
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 1/2] avformat/wavenc: replace literal numbers with enum constants

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 05:08:15PM +0200, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  libavformat/wavenc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

LGTM

thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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] mov: fix non-monotonous DTS when fragments overlap in time

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 08:54:09AM -0700, John Stebbins wrote:
> ---
>  libavformat/mov.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index c7422cd9ed..871f10b240 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4267,6 +4267,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  int data_offset = 0;
>  unsigned entries, first_sample_flags = frag->flags;
>  int flags, distance, i;
> +AVIndexEntry *last_index_entry = NULL;
>  
>  for (i = 0; i < c->fc->nb_streams; i++) {
>  if (c->fc->streams[i]->id == frag->track_id) {
> @@ -4294,6 +4295,10 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  offset = frag->base_data_offset + data_offset;
>  distance = 0;
>  av_log(c->fc, AV_LOG_TRACE, "first sample flags 0x%x\n", 
> first_sample_flags);
> +
> +if (st->nb_index_entries)
> +last_index_entry = >index_entries[st->nb_index_entries-1];
> +
>  for (i = 0; i < entries && !pb->eof_reached; i++) {
>  unsigned sample_size = frag->size;
>  int sample_flags = i ? frag->flags : first_sample_flags;
> @@ -4302,6 +4307,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  int keyframe = 0;
>  int ctts_index = 0;
>  int old_nb_index_entries = st->nb_index_entries;
> +int index_entry_flags = 0;
>  
>  if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration = 
> avio_rb32(pb);
>  if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size = 
> avio_rb32(pb);
> @@ -4338,10 +4344,16 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  keyframe =
>  !(sample_flags & (MOV_FRAG_SAMPLE_FLAG_IS_NON_SYNC |
>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
> -if (keyframe)
> +if (keyframe) {
>  distance = 0;
> +index_entry_flags |= AVINDEX_KEYFRAME;
> +}
> +// Fragments can overlap in time.  Discard overlapping frames after
> +// decoding.

> +if (last_index_entry && last_index_entry->timestamp >= dts)

the memory last_index_entry points to can be reallocated in this loop
making the pointer invalid


[...]
-- 
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 v4] avcodec/hevc_sei: Support HEVC paired fields.

[James Almer]

On 9/29/2017 8:01 PM, Michael Niedermayer wrote:
> On Fri, Sep 29, 2017 at 12:30:48AM -0300, James Almer wrote:
>> On 9/28/2017 7:09 PM, Michael Niedermayer wrote:
>>> On Wed, Sep 27, 2017 at 08:48:42PM -0500, Brian Matherly wrote:
 From: Brian Matherly 

 Correctly set the interlaced_frame and top_field_first fields when 
 pic_struct
 indicates paired fields.
 ---
  libavcodec/hevc_sei.c |  4 ++--
  tests/fate/hevc.mak   |  6 +-
  tests/ref/fate/hevc-paired-fields | 16 
  3 files changed, 23 insertions(+), 3 deletions(-)
  create mode 100644 tests/ref/fate/hevc-paired-fields
>>>
>>> this can be applied in 24h (after the fate sample is synced between
>>> fate cliensts)
>>> unless someone sees a issue in the patch
>>
>> I thought we had dropped the waiting period?
> 
> I think some fate clients still have issues with it but please Correct
> me if iam wrong.

I don't know, i just recall that in the past few months we didn't bother
waiting and just pushed the tests as soon as the samples were uploaded.

It's moot now in any case, seeing almost 24 hours have passed :p

> None of mine needs it or needed it
> 
> 
> [...]
> 
> 
> 
> ___
> 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 v4] avcodec/hevc_sei: Support HEVC paired fields.

[Michael Niedermayer]

On Fri, Sep 29, 2017 at 12:30:48AM -0300, James Almer wrote:
> On 9/28/2017 7:09 PM, Michael Niedermayer wrote:
> > On Wed, Sep 27, 2017 at 08:48:42PM -0500, Brian Matherly wrote:
> >> From: Brian Matherly 
> >>
> >> Correctly set the interlaced_frame and top_field_first fields when 
> >> pic_struct
> >> indicates paired fields.
> >> ---
> >>  libavcodec/hevc_sei.c |  4 ++--
> >>  tests/fate/hevc.mak   |  6 +-
> >>  tests/ref/fate/hevc-paired-fields | 16 
> >>  3 files changed, 23 insertions(+), 3 deletions(-)
> >>  create mode 100644 tests/ref/fate/hevc-paired-fields
> > 
> > this can be applied in 24h (after the fate sample is synced between
> > fate cliensts)
> > unless someone sees a issue in the patch
> 
> I thought we had dropped the waiting period?

I think some fate clients still have issues with it but please Correct
me if iam wrong.
None of mine needs it or needed it


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/mov: Allow reading very large files.

[Michael Niedermayer]

On Sat, Sep 30, 2017 at 12:58:27AM +0200, Michael Niedermayer wrote:
> From: Pablo Montilla 
> 
> The Sample count in the time-to-sample table is defined as
> 32-bit unsigned integer by the QT specification.
> 
> Fixes ticket #6700.
> ---
>  libavformat/isom.h | 2 +-
>  libavformat/mov.c  | 6 +-
>  2 files changed, 2 insertions(+), 6 deletions(-)

please ignore this patch of the set ive mistakly send 3 instead of the
intended 2

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH 2/3] avcodec/x86/lossless_videoencdsp: Fix handling of small widths

[Michael Niedermayer]

Fixes out of array access
Fixes: crash-huf.avi

Regression since: 6b41b4414934cc930468ccd5db598dd6ef643987

This could also be fixed by adding checks in the C code that calls the dsp

Found-by: Zhibin Hu and 连一汉 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/x86/lossless_videoencdsp.asm | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/x86/lossless_videoencdsp.asm 
b/libavcodec/x86/lossless_videoencdsp.asm
index 3cb7dce07f..a9c7a0a73c 100644
--- a/libavcodec/x86/lossless_videoencdsp.asm
+++ b/libavcodec/x86/lossless_videoencdsp.asm
@@ -42,10 +42,11 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
 %define i t0q
 %endmacro
 
-; label to jump to if w < regsize
-%macro DIFF_BYTES_LOOP_PREP 1
+; labels to jump to if w < regsize and w < 0
+%macro DIFF_BYTES_LOOP_PREP 2
 movi, wq
 andi, -2 * regsize
+js%2
 jz%1
 add dstq, i
 addsrc1q, i
@@ -87,7 +88,7 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
 %if mmsize > 16
 ; fall back to narrower xmm
 %define regsize mmsize / 2
-DIFF_BYTES_LOOP_PREP .setup_loop_gpr_aa
+DIFF_BYTES_LOOP_PREP .setup_loop_gpr_aa, .end_aa
 .loop2_%1%2:
 DIFF_BYTES_LOOP_CORE %1, %2, xm0, xm1
 addi, 2 * regsize
@@ -114,7 +115,7 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
 INIT_MMX mmx
 DIFF_BYTES_PROLOGUE
 %define regsize mmsize
-DIFF_BYTES_LOOP_PREP .skip_main_aa
+DIFF_BYTES_LOOP_PREP .skip_main_aa, .end_aa
 DIFF_BYTES_BODYa, a
 %undef i
 %endif
@@ -122,7 +123,7 @@ DIFF_BYTES_PROLOGUE
 INIT_XMM sse2
 DIFF_BYTES_PROLOGUE
 %define regsize mmsize
-DIFF_BYTES_LOOP_PREP .skip_main_aa
+DIFF_BYTES_LOOP_PREP .skip_main_aa, .end_aa
 testdstq, regsize - 1
 jnz .loop_uu
 test   src1q, regsize - 1
@@ -138,7 +139,7 @@ DIFF_BYTES_PROLOGUE
 %define regsize mmsize
 ; Directly using unaligned SSE2 version is marginally faster than
 ; branching based on arguments.
-DIFF_BYTES_LOOP_PREP .skip_main_uu
+DIFF_BYTES_LOOP_PREP .skip_main_uu, .end_uu
 testdstq, regsize - 1
 jnz .loop_uu
 test   src1q, regsize - 1
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 3/3] avcodec/x86/lossless_videoencdsp: Fix warning: signed dword value exceeds bounds

[Michael Niedermayer]

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

diff --git a/libavcodec/x86/lossless_videoencdsp.asm 
b/libavcodec/x86/lossless_videoencdsp.asm
index a9c7a0a73c..89f20dc4e2 100644
--- a/libavcodec/x86/lossless_videoencdsp.asm
+++ b/libavcodec/x86/lossless_videoencdsp.asm
@@ -45,7 +45,7 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
 ; labels to jump to if w < regsize and w < 0
 %macro DIFF_BYTES_LOOP_PREP 2
 movi, wq
-andi, -2 * regsize
+andi, -(2 * regsize)
 js%2
 jz%1
 add dstq, i
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/3] lavf/mov: Allow reading very large files.

[Michael Niedermayer]

From: Pablo Montilla 

The Sample count in the time-to-sample table is defined as
32-bit unsigned integer by the QT specification.

Fixes ticket #6700.
---
 libavformat/isom.h | 2 +-
 libavformat/mov.c  | 6 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 9aea629293..b9380e9dcc 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -52,7 +52,7 @@ struct AVAESCTR;
  */
 
 typedef struct MOVStts {
-int count;
+unsigned int count;
 int duration;
 } MOVStts;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ede9cda9d3..899690d920 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2663,15 +2663,11 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
-int sample_count;
+unsigned int sample_count;
 
 sample_count=avio_rb32(pb);
 sample_duration = avio_rb32(pb);
 
-if (sample_count < 0) {
-av_log(c->fc, AV_LOG_ERROR, "Invalid sample_count=%d\n", 
sample_count);
-return AVERROR_INVALIDDATA;
-}
 sc->stts_data[i].count= sample_count;
 sc->stts_data[i].duration= sample_duration;
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] movenc: take packet dts shifting into mention in check_pkt

[Jan Ekström]

This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.

I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.
---
 libavformat/movenc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 9c3e6437d7..2838286141 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4989,6 +4989,12 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
 } else
 ref = pkt->dts; // Skip tests for the first packet
 
+if (trk->dts_shift != AV_NOPTS_VALUE) {
+/* With negative CTS offsets we have set an offset to the DTS,
+ * reverse this for the check. */
+ref -= trk->dts_shift;
+}
+
 duration = pkt->dts - ref;
 if (pkt->dts < ref || duration >= INT_MAX) {
 av_log(s, AV_LOG_ERROR, "Application provided duration: %"PRId64" / 
timestamp: %"PRId64" is out of range for mov/mp4 format\n",
-- 
2.13.6

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[James Almer]

On 9/29/2017 6:56 PM, Hendrik Leppkes wrote:
> On Fri, Sep 29, 2017 at 8:39 PM, Clément Bœsch  wrote:
>> On Fri, Sep 29, 2017 at 08:12:14PM +0200, Hendrik Leppkes wrote:
>> [...]
 Just to be clear (sorry if I make you repeat yourself), we currently have
 the following:

 - Systems without VDA (that is, almost all of them) do not have access to
   either VDA or the stub: for them, we are exposing a header with FFmpeg
   symbols not accessible.

 - Systems with VDA have access to the VDA code (assuming it still build)

 What you suggest:

 - Both systems (with and without VDA) should now use the existing stub we
   currently never build so the ABI for systems with VDA will be kept.

 Is that correct?

 If so, this means we will start introducing a deprecated API stub for VDA
 on all systems.

 Or should I start exposing the stub only for VDA systems, meaning I'll
 need to keep the VDA detection in the configure?

>>>
>>> Obivously including the stub everywhere is much easier and far saner,
>>> does it really harm to do that?
>>>
>>
>> It's just a bit weird to actually introduce deprecated symbols that
>> weren't there in the first place.
>>
> 
> Since at least BBB was slightly confused by my comments, just to clarfiy:
> I don't really care how its done, but the ABI should remain intact. If
> I do a simple build on mac today with ./configure && make and it
> includes vda symbols, then so it should afterwards, even if they are
> non-functional. How thats done, I don't mind.

Then IMO we should wait until the major bump (Which is not too far
away). Leaving a stub object for the symbols and configure clutter
should be avoided.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 8:39 PM, Clément Bœsch  wrote:
> On Fri, Sep 29, 2017 at 08:12:14PM +0200, Hendrik Leppkes wrote:
> [...]
>> > Just to be clear (sorry if I make you repeat yourself), we currently have
>> > the following:
>> >
>> > - Systems without VDA (that is, almost all of them) do not have access to
>> >   either VDA or the stub: for them, we are exposing a header with FFmpeg
>> >   symbols not accessible.
>> >
>> > - Systems with VDA have access to the VDA code (assuming it still build)
>> >
>> > What you suggest:
>> >
>> > - Both systems (with and without VDA) should now use the existing stub we
>> >   currently never build so the ABI for systems with VDA will be kept.
>> >
>> > Is that correct?
>> >
>> > If so, this means we will start introducing a deprecated API stub for VDA
>> > on all systems.
>> >
>> > Or should I start exposing the stub only for VDA systems, meaning I'll
>> > need to keep the VDA detection in the configure?
>> >
>>
>> Obivously including the stub everywhere is much easier and far saner,
>> does it really harm to do that?
>>
>
> It's just a bit weird to actually introduce deprecated symbols that
> weren't there in the first place.
>

Since at least BBB was slightly confused by my comments, just to clarfiy:
I don't really care how its done, but the ABI should remain intact. If
I do a simple build on mac today with ./configure && make and it
includes vda symbols, then so it should afterwards, even if they are
non-functional. How thats done, I don't mind.

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

Re: [FFmpeg-devel] How to tell CFR/VFR video apart, and determine frame rate

[Lou Logan]

On Fri, Sep 29, 2017, at 04:32 AM, Richard Ling wrote:
> How can I determine whether a filter input is VFR or CFR?
> 
> static int is_vfr(AVFilterLink *inlink)
> {
> return ???;
> }
[...]

ffmpeg-devel is only for discussions regarding the development of FFmpeg
and for submitting patches.

Questions about using the FFmpeg libraries should be asked at
libav-user.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information

[Marton Balint]

On Fri, 29 Sep 2017, Carl Eugen Hoyos wrote:


2017-09-29 17:35 GMT+02:00 Maksym Veremeyenko :

29.09.2017 0:20, Carl Eugen Hoyos пише:



I don't have decklink hardware but I assume it never outputs actual
transparency.
Or does it?


dual link SDI could provide fill/key, some boards could support this


(Do they or don't they?)


For output, there is definitely hardware support. For capture - I am not 
sure. I have not heard of a decklink device capturing key/fill.


Unfortunately the decklink SDK uses the same constants for both capture 
and output, and if we want to follow the SDK, we can't drop alpha channel, 
because for both RGBA and ARGB modes it explicitly mentions that the alpha 
channel might be valid. It does not differentiate between input and 
output however.


Maybe somebody should ask BlackMagic.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 8:25 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Sep 29, 2017 at 2:12 PM, Hendrik Leppkes 
> wrote:
>
>> On Fri, Sep 29, 2017 at 7:08 PM, Clément Bœsch  wrote:
>> > On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote:
>> >> On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch  wrote:
>> >> > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
>> >> >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
>> >> >> > From: Clément Bœsch 
>> >> >> >
>> >> >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement
>> for it
>> >> >> > (VideoToolbox).
>> >> >> > ---
>> >> >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix
>> fmt,
>> >> >> > Changelog entry.
>> >> >> >
>> >> >>
>> >> >> vda.h is an installed header with public API in it, removing it
>> >> >> entirely would be an API and ABI break.
>> >> >>
>> >> >
>> >> > vda.h may be exposed unconditionally, but its associated object vda.o
>> >> > isn't. Since it depends on vda to be assembled, the vda stub itself
>> >> > doesn't seem to be present ever. So we're basically exposing a header
>> for
>> >> > functions we can never link against.
>> >> >
>> >> > So should I somehow fix VDA while dropping it by providing a stub
>> that was
>> >> > never present?
>> >> >
>> >>
>> >> vda is autodetected so a "naive" build would have it, so I would argue
>> >> the ABI of such a "naive" build should probably remain constant?
>> >
>> > Just to be clear (sorry if I make you repeat yourself), we currently have
>> > the following:
>> >
>> > - Systems without VDA (that is, almost all of them) do not have access to
>> >   either VDA or the stub: for them, we are exposing a header with FFmpeg
>> >   symbols not accessible.
>> >
>> > - Systems with VDA have access to the VDA code (assuming it still build)
>> >
>> > What you suggest:
>> >
>> > - Both systems (with and without VDA) should now use the existing stub we
>> >   currently never build so the ABI for systems with VDA will be kept.
>> >
>> > Is that correct?
>> >
>> > If so, this means we will start introducing a deprecated API stub for VDA
>> > on all systems.
>> >
>> > Or should I start exposing the stub only for VDA systems, meaning I'll
>> > need to keep the VDA detection in the configure?
>> >
>>
>> Obivously including the stub everywhere is much easier and far saner,
>> does it really harm to do that?
>
>
> I don't think it's reasonable to ask people to fix a feature if all they
> want to do is deprecate and remove it.
>

Its not exactly any effort, however.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Clément Bœsch]

On Fri, Sep 29, 2017 at 08:12:14PM +0200, Hendrik Leppkes wrote:
[...]
> > Just to be clear (sorry if I make you repeat yourself), we currently have
> > the following:
> >
> > - Systems without VDA (that is, almost all of them) do not have access to
> >   either VDA or the stub: for them, we are exposing a header with FFmpeg
> >   symbols not accessible.
> >
> > - Systems with VDA have access to the VDA code (assuming it still build)
> >
> > What you suggest:
> >
> > - Both systems (with and without VDA) should now use the existing stub we
> >   currently never build so the ABI for systems with VDA will be kept.
> >
> > Is that correct?
> >
> > If so, this means we will start introducing a deprecated API stub for VDA
> > on all systems.
> >
> > Or should I start exposing the stub only for VDA systems, meaning I'll
> > need to keep the VDA detection in the configure?
> >
> 
> Obivously including the stub everywhere is much easier and far saner,
> does it really harm to do that?
> 

It's just a bit weird to actually introduce deprecated symbols that
weren't there in the first place.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Ronald S. Bultje]

Hi,

On Fri, Sep 29, 2017 at 2:12 PM, Hendrik Leppkes 
wrote:

> On Fri, Sep 29, 2017 at 7:08 PM, Clément Bœsch  wrote:
> > On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote:
> >> On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch  wrote:
> >> > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
> >> >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
> >> >> > From: Clément Bœsch 
> >> >> >
> >> >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement
> for it
> >> >> > (VideoToolbox).
> >> >> > ---
> >> >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix
> fmt,
> >> >> > Changelog entry.
> >> >> >
> >> >>
> >> >> vda.h is an installed header with public API in it, removing it
> >> >> entirely would be an API and ABI break.
> >> >>
> >> >
> >> > vda.h may be exposed unconditionally, but its associated object vda.o
> >> > isn't. Since it depends on vda to be assembled, the vda stub itself
> >> > doesn't seem to be present ever. So we're basically exposing a header
> for
> >> > functions we can never link against.
> >> >
> >> > So should I somehow fix VDA while dropping it by providing a stub
> that was
> >> > never present?
> >> >
> >>
> >> vda is autodetected so a "naive" build would have it, so I would argue
> >> the ABI of such a "naive" build should probably remain constant?
> >
> > Just to be clear (sorry if I make you repeat yourself), we currently have
> > the following:
> >
> > - Systems without VDA (that is, almost all of them) do not have access to
> >   either VDA or the stub: for them, we are exposing a header with FFmpeg
> >   symbols not accessible.
> >
> > - Systems with VDA have access to the VDA code (assuming it still build)
> >
> > What you suggest:
> >
> > - Both systems (with and without VDA) should now use the existing stub we
> >   currently never build so the ABI for systems with VDA will be kept.
> >
> > Is that correct?
> >
> > If so, this means we will start introducing a deprecated API stub for VDA
> > on all systems.
> >
> > Or should I start exposing the stub only for VDA systems, meaning I'll
> > need to keep the VDA detection in the configure?
> >
>
> Obivously including the stub everywhere is much easier and far saner,
> does it really harm to do that?


I don't think it's reasonable to ask people to fix a feature if all they
want to do is deprecate and remove it.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 7:08 PM, Clément Bœsch  wrote:
> On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote:
>> On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch  wrote:
>> > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
>> >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
>> >> > From: Clément Bœsch 
>> >> >
>> >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
>> >> > (VideoToolbox).
>> >> > ---
>> >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
>> >> > Changelog entry.
>> >> >
>> >>
>> >> vda.h is an installed header with public API in it, removing it
>> >> entirely would be an API and ABI break.
>> >>
>> >
>> > vda.h may be exposed unconditionally, but its associated object vda.o
>> > isn't. Since it depends on vda to be assembled, the vda stub itself
>> > doesn't seem to be present ever. So we're basically exposing a header for
>> > functions we can never link against.
>> >
>> > So should I somehow fix VDA while dropping it by providing a stub that was
>> > never present?
>> >
>>
>> vda is autodetected so a "naive" build would have it, so I would argue
>> the ABI of such a "naive" build should probably remain constant?
>
> Just to be clear (sorry if I make you repeat yourself), we currently have
> the following:
>
> - Systems without VDA (that is, almost all of them) do not have access to
>   either VDA or the stub: for them, we are exposing a header with FFmpeg
>   symbols not accessible.
>
> - Systems with VDA have access to the VDA code (assuming it still build)
>
> What you suggest:
>
> - Both systems (with and without VDA) should now use the existing stub we
>   currently never build so the ABI for systems with VDA will be kept.
>
> Is that correct?
>
> If so, this means we will start introducing a deprecated API stub for VDA
> on all systems.
>
> Or should I start exposing the stub only for VDA systems, meaning I'll
> need to keep the VDA detection in the configure?
>

Obivously including the stub everywhere is much easier and far saner,
does it really harm to do that?

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

[FFmpeg-devel] [PATCH]lavf/bit: Fix the G.729 bit auto-detection

[Carl Eugen Hoyos]

Hi!

The G.729 bit auto-detection has never worked, patch attached.

Please comment, Carl Eugen
From 2521a9bd86d807a3e18fe930b35039beb7674b3e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 29 Sep 2017 19:10:46 +0200
Subject: [PATCH] lavf/bit: Fix the G.729 bit auto-detection.

---
 libavformat/bit.c |   23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/libavformat/bit.c b/libavformat/bit.c
index d742a5b..f90e4a7 100644
--- a/libavformat/bit.c
+++ b/libavformat/bit.c
@@ -32,20 +32,23 @@
 #if CONFIG_BIT_DEMUXER
 static int probe(AVProbeData *p)
 {
-int i, j;
+int i = 0, j, valid = 0;
 
-if(p->buf_size < 0x40)
-return 0;
-
-for(i=0; i+3buf_size && i< 10*0x50; ){
-if(AV_RL16(>buf[0]) != SYNC_WORD)
+while (2 * i + 3 < p->buf_size){
+if (AV_RL16(>buf[2 * i++]) != SYNC_WORD)
 return 0;
-j=AV_RL16(>buf[2]);
-if(j!=0x40 && j!=0x50)
+j = AV_RL16(>buf[2 * i++]);
+if (j != 0 && j != 0x10 && j != 0x40 && j != 0x50)
 return 0;
-i+=j;
+if (j)
+valid++;
+i += j;
 }
-return AVPROBE_SCORE_EXTENSION;
+if (valid > 10)
+return AVPROBE_SCORE_MAX;
+if (valid > 2)
+return AVPROBE_SCORE_EXTENSION - 1;
+return 0;
 }
 
 static int read_header(AVFormatContext *s)
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Carl Eugen Hoyos]

2017-09-29 11:11 GMT+02:00 Clément Bœsch :
> From: Clément Bœsch 
>
> Deprecated (aka removed) in OSX 10.11, and we have a
> replacement for it (VideoToolbox).

Does this mean binaries built on older systems do not
start on 10.11?

If yes, my suggestion would be to disable auto-detection
until removal at the next major bump.

If there is no imminent issue, I wonder if waiting isn't the
simpler solution.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Clément Bœsch]

On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote:
> On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch  wrote:
> > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
> >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
> >> > From: Clément Bœsch 
> >> >
> >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
> >> > (VideoToolbox).
> >> > ---
> >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
> >> > Changelog entry.
> >> >
> >>
> >> vda.h is an installed header with public API in it, removing it
> >> entirely would be an API and ABI break.
> >>
> >
> > vda.h may be exposed unconditionally, but its associated object vda.o
> > isn't. Since it depends on vda to be assembled, the vda stub itself
> > doesn't seem to be present ever. So we're basically exposing a header for
> > functions we can never link against.
> >
> > So should I somehow fix VDA while dropping it by providing a stub that was
> > never present?
> >
> 
> vda is autodetected so a "naive" build would have it, so I would argue
> the ABI of such a "naive" build should probably remain constant?

Just to be clear (sorry if I make you repeat yourself), we currently have
the following:

- Systems without VDA (that is, almost all of them) do not have access to
  either VDA or the stub: for them, we are exposing a header with FFmpeg
  symbols not accessible.

- Systems with VDA have access to the VDA code (assuming it still build)

What you suggest:

- Both systems (with and without VDA) should now use the existing stub we
  currently never build so the ABI for systems with VDA will be kept.

Is that correct?

If so, this means we will start introducing a deprecated API stub for VDA
on all systems.

Or should I start exposing the stub only for VDA systems, meaning I'll
need to keep the VDA detection in the configure?

-- 
Clément B.


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

Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[wm4]

On Fri, 29 Sep 2017 15:04:00 +
"Mironov, Mikhail"  wrote:

> I would like to understand better the nature of the concern. The license is 
> MIT. The paragraph in question is a notice, not limiting the usage of the SDK.
> I can definitely reduce number of headers. I can merge all necessary 
> interfaces into one header, though maintenance will take more resources. 
> Which way would you prefer?

Ideally, these headers would just be easily installable by whoever
wants to build FFmpeg with AMF. This is how it works normally for
external libraries.

I don't even understand why we added those NVIDIA and avisynth headers
(the other things in compat are for basic OS compatibility, so not
comparable). For NVIDIA in particular it's probably because installing
their SDK is a major PITA and there was something about license issues.
Maybe someone else could chime in why this was done?

At least for nvenc there was an explanation given in the commit message:

As Nvidia has put the most recent Video Codec SDK behind a double
registration wall, of which one needs manual approval of a lenghty
application, bundling this header saves everyone trying to use NVENC
from that headache.

The header is still MIT licensed and thus fine to bundle with ffmpeg.

Not bundling this header would get ffmpeg stuck at SDK v6, which is
still freely available, holding back future development of the NVENC
encoder.

So basically, NVIDIA being... let's say, "not nice". I don't think this
will be a problem with AMD.

Again, we generally don't add headers for external libraries in-tree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch  wrote:
> On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
>> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
>> > From: Clément Bœsch 
>> >
>> > Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
>> > (VideoToolbox).
>> > ---
>> > Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
>> > Changelog entry.
>> >
>>
>> vda.h is an installed header with public API in it, removing it
>> entirely would be an API and ABI break.
>>
>
> vda.h may be exposed unconditionally, but its associated object vda.o
> isn't. Since it depends on vda to be assembled, the vda stub itself
> doesn't seem to be present ever. So we're basically exposing a header for
> functions we can never link against.
>
> So should I somehow fix VDA while dropping it by providing a stub that was
> never present?
>

vda is autodetected so a "naive" build would have it, so I would argue
the ABI of such a "naive" build should probably remain constant?

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

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

[John Stebbins]

When keyframe intervals of dash segments are not perfectly aligned,
fragments in the stream can overlap in time. Append new "trun" index
entries to the end of the index instead of sorting by timestamp.
Sorting by timestamp causes packets to be read out of decode order and
results in decode errors.
---
 libavformat/mov.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 899690d920..c7422cd9ed 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4340,8 +4340,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
   MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
 if (keyframe)
 distance = 0;
-ctts_index = av_add_index_entry(st, offset, dts, sample_size, distance,
-keyframe ? AVINDEX_KEYFRAME : 0);
+ctts_index = add_index_entry(st, offset, dts, sample_size, distance,
+ keyframe ? AVINDEX_KEYFRAME : 0);
 if (ctts_index >= 0 && old_nb_index_entries < st->nb_index_entries) {
 unsigned int size_needed = st->nb_index_entries * 
sizeof(*sc->ctts_data);
 unsigned int request_size = size_needed > sc->ctts_allocated_size ?
-- 
2.13.5

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

[FFmpeg-devel] [PATCH 2/2] mov: fix non-monotonous DTS when fragments overlap in time

[John Stebbins]

---
 libavformat/mov.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index c7422cd9ed..871f10b240 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4267,6 +4267,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 int data_offset = 0;
 unsigned entries, first_sample_flags = frag->flags;
 int flags, distance, i;
+AVIndexEntry *last_index_entry = NULL;
 
 for (i = 0; i < c->fc->nb_streams; i++) {
 if (c->fc->streams[i]->id == frag->track_id) {
@@ -4294,6 +4295,10 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 offset = frag->base_data_offset + data_offset;
 distance = 0;
 av_log(c->fc, AV_LOG_TRACE, "first sample flags 0x%x\n", 
first_sample_flags);
+
+if (st->nb_index_entries)
+last_index_entry = >index_entries[st->nb_index_entries-1];
+
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 unsigned sample_size = frag->size;
 int sample_flags = i ? frag->flags : first_sample_flags;
@@ -4302,6 +4307,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 int keyframe = 0;
 int ctts_index = 0;
 int old_nb_index_entries = st->nb_index_entries;
+int index_entry_flags = 0;
 
 if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration = avio_rb32(pb);
 if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size = avio_rb32(pb);
@@ -4338,10 +4344,16 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 keyframe =
 !(sample_flags & (MOV_FRAG_SAMPLE_FLAG_IS_NON_SYNC |
   MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
-if (keyframe)
+if (keyframe) {
 distance = 0;
+index_entry_flags |= AVINDEX_KEYFRAME;
+}
+// Fragments can overlap in time.  Discard overlapping frames after
+// decoding.
+if (last_index_entry && last_index_entry->timestamp >= dts)
+index_entry_flags |= AVINDEX_DISCARD_FRAME;
 ctts_index = add_index_entry(st, offset, dts, sample_size, distance,
- keyframe ? AVINDEX_KEYFRAME : 0);
+ index_entry_flags);
 if (ctts_index >= 0 && old_nb_index_entries < st->nb_index_entries) {
 unsigned int size_needed = st->nb_index_entries * 
sizeof(*sc->ctts_data);
 unsigned int request_size = size_needed > sc->ctts_allocated_size ?
-- 
2.13.5

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

Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information

[Carl Eugen Hoyos]

2017-09-29 17:35 GMT+02:00 Maksym Veremeyenko :
> 29.09.2017 0:20, Carl Eugen Hoyos пише:

>> I don't have decklink hardware but I assume it never outputs actual
>> transparency.
>> Or does it?
>
> dual link SDI could provide fill/key, some boards could support this

(Do they or don't they?)

Thank you both for the explanations!

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

Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-09-29 17:04 GMT+02:00 Mironov, Mikhail :
> I would like to understand better the nature of the
> concern. The license is MIT.

(I don't think this is correct, but see below.)

> The paragraph in question is a notice, not limiting
> the usage of the SDK.

I don't think this is true (I am not a native speaker
though), imo it sounds as if it limits the usage.
It also may have been written with the intention of
being a little ambiguous.

But this doesn't matter: If the notice is not part of the
license, please ask AMD to remove it from the SDK
- the license gets much, much easier to understand
without the notice.

If you feel 100% safe about removing it, you could
offer the driver software from your github account
without the notice, this would also solve the header
issue.

I cannot comment on the acceptable number (or
size) of external headers.

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

Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information

[Maksym Veremeyenko]

29.09.2017 0:20, Carl Eugen Hoyos пише:

Hi!

I don't have decklink hardware but I assume it never outputs actual
transparency.
Or does it?


dual link SDI could provide fill/key, some boards could support this

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

Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

I would like to understand better the nature of the concern. The license is 
MIT. The paragraph in question is a notice, not limiting the usage of the SDK.
I can definitely reduce number of headers. I can merge all necessary interfaces 
into one header, though maintenance will take more resources. Which way would 
you prefer?
Thanks,
Mikhail

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
Eugen Hoyos
Sent: September 28, 2017 5:08 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for 
AMD GPUs based on AMF SDK

2017-09-28 20:58 GMT+02:00 mmironov :

> +++ b/compat/amd/amf/LICENSE.txt
> @@ -0,0 +1,31 @@
> +Notice Regarding Standards.  AMD does not provide a license or 
> +sublicense to any Intellectual Property Rights relating to any 
> +standards, including but not limited to any audio and/or video codec 
> +technologies such as MPEG-2, MPEG-4; AVC/H.264; HEVC/H.265; AAC 
> +decode/FFMPEG; AAC encode/FFMPEG; VC-1; and MP3 (collectively, the 
> +"Media Technologies"). For clarity, you will pay any royalties due 
> +for such third party technologies, which may include the Media Technologies 
> that are owed as a result of AMD providing the Software to you.

Is this part of the software license?
If yes, this can definitely not be committed to the FFmpeg repository.
If not, please remove it.

Before removing it, please check with the original author (AMD) that it is not 
part of the software license.

> +
> +This software uses libraries from the FFmpeg project under the LGPLv2.1.
> +
> +MIT license
> +
> +Copyright (c) 2016 Advanced Micro Devices, Inc. All rights reserved.
> +
> +Permission is hereby granted, free of charge, to any person obtaining 
> +a copy of this software and associated documentation files (the 
> +"Software"), to deal in the Software without restriction, including 
> +without limitation the rights to use, copy, modify, merge, publish, 
> +distribute, sublicense, and/or sell copies of the Software, and to 
> +permit persons to whom the Software is furnished to do so, subject to the 
> following conditions:
> +
> +The above copyright notice and this permission notice shall be 
> +included in all copies or substantial portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
> +NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
> +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
> +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
> +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> +SOFTWARE

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] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 libavformat/wavenc.c | 5 -
 tests/ref/lavf/wav_peak_only | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index adb20cb..7a4acf9 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -287,7 +287,10 @@ static int peak_write_chunk(AVFormatContext *s)
 avio_wl32(pb, wav->peak_block_size);/* frames per value */
 avio_wl32(pb, par->channels);   /* number of channels */
 avio_wl32(pb, wav->peak_num_frames);/* number of peak frames */
-avio_wl32(pb, wav->peak_pos_pop);   /* audio sample frame index */
+if (wav->write_peak == PEAK_ONLY)   /* audio sample frame index */
+avio_wl32(pb, -1);
+else
+avio_wl32(pb, wav->peak_pos_pop);
 avio_wl32(pb, 128); /* equal to size of header */
 avio_write(pb, timestamp, 28);  /* ASCII time stamp */
 ffio_fill(pb, 0, 60);
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
index dccd0e7..b203d03 100644
--- a/tests/ref/lavf/wav_peak_only
+++ b/tests/ref/lavf/wav_peak_only
@@ -1,2 +1,2 @@
-b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+f1a8aeeae8069f3992c4d780436c3d23 *./tests/data/lavf/lavf.peak_only.wav
 832 ./tests/data/lavf/lavf.peak_only.wav
-- 
2.7.4


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

[FFmpeg-devel] [PATCH 1/2] avformat/wavenc: replace literal numbers with enum constants

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 libavformat/wavenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 7f3059e..adb20cb 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -331,7 +331,7 @@ static int wav_write_header(AVFormatContext *s)
 ffio_fill(pb, 0, 28);
 }
 
-if (wav->write_peak != 2) {
+if (wav->write_peak != PEAK_ONLY) {
 /* format header */
 fmt = ff_start_tag(pb, "fmt ");
 if (ff_put_wav_header(s, pb, s->streams[0]->codecpar, 0) < 0) {
@@ -363,7 +363,7 @@ static int wav_write_header(AVFormatContext *s)
 wav->maxpts = wav->last_duration = 0;
 wav->minpts = INT64_MAX;
 
-if (wav->write_peak != 2) {
+if (wav->write_peak != PEAK_ONLY) {
 /* info header */
 ff_riff_write_info(s);
 
@@ -381,7 +381,7 @@ static int wav_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 AVIOContext *pb  = s->pb;
 WAVMuxContext*wav = s->priv_data;
 
-if (wav->write_peak != 2)
+if (wav->write_peak != PEAK_ONLY)
 avio_write(pb, pkt->data, pkt->size);
 
 if (wav->write_peak) {
@@ -426,7 +426,7 @@ static int wav_write_trailer(AVFormatContext *s)
 avio_flush(pb);
 
 if (s->pb->seekable & AVIO_SEEKABLE_NORMAL) {
-if (wav->write_peak != 2 && avio_tell(pb) - wav->data < UINT32_MAX) {
+if (wav->write_peak != PEAK_ONLY && avio_tell(pb) - wav->data < 
UINT32_MAX) {
 ff_end_tag(pb, wav->data);
 avio_flush(pb);
 }
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

[Ronald S. Bultje]

Hi,

On Fri, Sep 15, 2017 at 4:47 PM, Ashish Pratap Singh 
wrote:

> From: Ashish Singh 
>
> Hi, this patch addresses the previous issues and changes it to a single
> input filter.
>
> Signed-off-by: Ashish Singh 
> ---
>  Changelog   |   1 +
>  doc/filters.texi|  14 ++
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_vmafmotion.c | 325 ++
> ++
>  libavfilter/vmaf_motion.h   |  58 
>  6 files changed, 400 insertions(+)
>  create mode 100644 libavfilter/vf_vmafmotion.c
>  create mode 100644 libavfilter/vmaf_motion.h


I made tiny changes to this patch (see attached patch). Basically, it adds
an option (similar to psnr/ssim filters) to log the per-frame scores to a
file, which can be convenient for debugging the per-frame scores, or using
them externally using CLI. Secondly, it adjusts the filter/sad so that the
calculations use a slightly higher internal depth for the fixed-point
integer calculations. This makes the score slightly closer to the
floating-point equivalent in the reference code. Lastly, it normalizes the
10-bit score back to 8-bit, which is what the reference code does also. It
also makes use of the vmafdsp.sad() function pointer instead of calling
image_sad() directly, so SIMD will be used when added later on.

This should address all review comments (the rest were basically things
that will be used in subsequent patches, so whether we address it or not
doesn't really affect the final product), so if there's no further
comments, I'll squash the two patches together and push it.

Ronald


0001-Tiny-adjustments.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Clément Bœsch]

On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
> > From: Clément Bœsch 
> >
> > Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
> > (VideoToolbox).
> > ---
> > Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
> > Changelog entry.
> >
> 
> vda.h is an installed header with public API in it, removing it
> entirely would be an API and ABI break.
> 

vda.h may be exposed unconditionally, but its associated object vda.o
isn't. Since it depends on vda to be assembled, the vda stub itself
doesn't seem to be present ever. So we're basically exposing a header for
functions we can never link against.

So should I somehow fix VDA while dropping it by providing a stub that was
never present?

-- 
Clément B.


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

[FFmpeg-devel] How to tell CFR/VFR video apart, and determine frame rate

[Richard Ling]

How can I determine whether a filter input is VFR or CFR?

static int is_vfr(AVFilterLink *inlink)
{
return ???;
}

If I determine the input is CFR, how do I get the frame rate in FPS?
Is it always the reciprocal of timebase, if not what is the correct
implementation?

static float get_constant_frame_rate(AVFilterLink *inlink)
{
return 1.0f / av_q2d(inlink->time_base);  // correct??
}

Thanks in advance...
R
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: Add format context parameter to ff_id3v2_read_dict

[Moritz Barsnick]

On Tue, Sep 26, 2017 at 08:49:44 +0200, Lukas Stabe wrote:
> - * Chapters are not currently read by this variant.
> + * Chapters are not currently only read by this variant when s is not NULL.

I believe you forgot to drop the first "not" from that sentence.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch  wrote:
> From: Clément Bœsch 
>
> Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
> (VideoToolbox).
> ---
> Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
> Changelog entry.
>

vda.h is an installed header with public API in it, removing it
entirely would be an API and ABI break.

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

[FFmpeg-devel] [PATCH] build: make h264 VT encoder select the VT encoder dependency

[Clément Bœsch]

From: Clément Bœsch 

Otherwise, it's never enabled unless the user explicitely enables it.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 8e4775be8c..6a935a5833 100755
--- a/configure
+++ b/configure
@@ -2936,7 +2936,8 @@ pcm_alaw_at_encoder_select="audio_frame_queue"
 pcm_mulaw_at_encoder_deps="audiotoolbox"
 pcm_mulaw_at_encoder_select="audio_frame_queue"
 chromaprint_muxer_deps="chromaprint"
-h264_videotoolbox_encoder_deps="videotoolbox_encoder pthreads"
+h264_videotoolbox_encoder_deps="pthreads"
+h264_videotoolbox_encoder_select="videotoolbox_encoder"
 libcelt_decoder_deps="libcelt"
 libfdk_aac_decoder_deps="libfdk_aac"
 libfdk_aac_encoder_deps="libfdk_aac"
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] lavc: drop VDA

[Clément Bœsch]

From: Clément Bœsch 

Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
(VideoToolbox).
---
Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt,
Changelog entry.

I'll apply soon since the RFC seemed to raise acceptance.
---
 Changelog   |   1 +
 MAINTAINERS |   1 -
 Makefile|   3 -
 configure   |  14 -
 ffmpeg.h|   2 -
 ffmpeg_opt.c|   6 +-
 ffmpeg_videotoolbox.c   |  45 +--
 libavcodec/Makefile |   7 +-
 libavcodec/allcodecs.c  |   3 -
 libavcodec/h264_slice.c |   5 -
 libavcodec/vda.c|  84 -
 libavcodec/vda.h| 230 -
 libavcodec/vda_h264.c   | 425 
 libavcodec/vda_h264_dec.c   | 263 ---
 libavcodec/videotoolbox.c   |  10 +-
 libavcodec/{vda_vt_internal.h => vt_internal.h} |  16 +-
 libavutil/pixdesc.c |   4 +
 libavutil/pixfmt.h  |   8 +-
 libavutil/version.h |   3 +
 19 files changed, 27 insertions(+), 1103 deletions(-)
 delete mode 100644 libavcodec/vda.c
 delete mode 100644 libavcodec/vda.h
 delete mode 100644 libavcodec/vda_h264.c
 delete mode 100644 libavcodec/vda_h264_dec.c
 rename libavcodec/{vda_vt_internal.h => vt_internal.h} (82%)

diff --git a/Changelog b/Changelog
index c64cef4c89..10ac42f0ef 100644
--- a/Changelog
+++ b/Changelog
@@ -51,6 +51,7 @@ version :
 - CUDA thumbnail filter
 - V4L2 mem2mem HW assisted codecs
 - Rockchip MPP hardware decoding
+- VDA dropped (use VideoToolbox instead)
 
 
 version 3.3:
diff --git a/MAINTAINERS b/MAINTAINERS
index 77f48b984b..8ea0568bf0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -244,7 +244,6 @@ Codecs:
   txd.c Ivo van Poorten
   vc2*  Rostislav Pehlivanov
   vcr1.cMichael Niedermayer
-  vda_h264_dec.cXidorn Quan
   videotoolboxenc.c Rick Kern
   vima.cPaul B Mahol
   vorbisdec.c   Denes Balatoni, David Conrad
diff --git a/Makefile b/Makefile
index e4eb050226..667d58ceac 100644
--- a/Makefile
+++ b/Makefile
@@ -34,9 +34,6 @@ $(foreach prog,$(AVBASENAMES),$(eval 
OBJS-$(prog)-$(CONFIG_OPENCL) += cmdutils_o
 OBJS-ffmpeg   += ffmpeg_opt.o ffmpeg_filter.o ffmpeg_hw.o
 OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
 OBJS-ffmpeg-$(CONFIG_LIBMFX)  += ffmpeg_qsv.o
-ifndef CONFIG_VIDEOTOOLBOX
-OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
-endif
 OBJS-ffmpeg-$(CONFIG_CUVID)   += ffmpeg_cuvid.o
 OBJS-ffserver += ffserver_config.o
 
diff --git a/configure b/configure
index 8e4775be8c..4a4e7c7d70 100755
--- a/configure
+++ b/configure
@@ -318,7 +318,6 @@ External library support:
   --enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
   --enable-rkmpp   enable Rockchip Media Process Platform code [no]
   --disable-vaapi  disable Video Acceleration API (mainly Unix/Intel) 
code [autodetect]
-  --disable-vdadisable Apple Video Decode Acceleration code 
[autodetect]
   --disable-vdpau  disable Nvidia Video Decode and Presentation API 
for Unix code [autodetect]
   --disable-videotoolbox   disable VideoToolbox code [autodetect]
 
@@ -1649,7 +1648,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
 dxva2
 nvenc
 vaapi
-vda
 vdpau
 videotoolbox
 v4l2_m2m
@@ -2650,10 +2648,6 @@ cuvid_deps="cuda"
 d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
 dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32"
 dxva2_extralibs="-luser32"
-vda_framework_deps="VideoDecodeAcceleration_VDADecoder_h blocks_extension"
-vda_framework_extralibs="-framework VideoDecodeAcceleration"
-vda_deps="vda_framework pthreads"
-vda_extralibs="-framework CoreFoundation -framework QuartzCore"
 videotoolbox_hwaccel_deps="videotoolbox pthreads"
 videotoolbox_hwaccel_extralibs="-framework QuartzCore"
 xvmc_deps="X11_extensions_XvMClib_h"
@@ -2675,10 +2669,6 @@ h264_mmal_hwaccel_deps="mmal"
 h264_qsv_hwaccel_deps="libmfx"
 h264_vaapi_hwaccel_deps="vaapi"
 h264_vaapi_hwaccel_select="h264_decoder"
-h264_vda_hwaccel_deps="vda"
-h264_vda_hwaccel_select="h264_decoder"
-h264_vda_old_hwaccel_deps="vda"
-h264_vda_old_hwaccel_select="h264_decoder"
 h264_vdpau_hwaccel_deps="vdpau"
 h264_vdpau_hwaccel_select="h264_decoder"
 h264_videotoolbox_hwaccel_deps="videotoolbox"
@@ -2813,8 +2803,6 @@ h264_rkmpp_decoder_deps="rkmpp"
 

Re: [FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding

[Martin Vignali]

2017-09-28 23:24 GMT+02:00 Carl Eugen Hoyos :

> 2017-09-28 21:50 GMT+02:00 Martin Vignali :
>
> > After comments about the previous patchs
>
> Please explain how this encoder and decoder can be used
> from the FFmpeg cli: What kind of input could be used, what
> could be done with the output?
>
> I believe you force every user to add an additional filter
> to do anything useful, please convince me that this is wrong.
>
> Hello,

I didn't design the HAP codec, so my answer mostly follow the comments
of Tom Butterworth. (in the previous discussion of decoding/encoding)

Like it seems that the Hap Alpha Only is only design to be use for alpha
channel encoding
(not to encode gray), it use in this new patch  : RGBA input/output (using
only the alpha channel)

In a more general way, HAP is only useful when use with GPU
decoding/compositing (specially in very big resolution, with lot of video
layer)
(not the case in the ffmpeg).

IMO, the ffmpeg support is mostly interesting to convert hap file to
something else
or to check what we can encode with the ffmpeg hap encoder.

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

Re: [FFmpeg-devel] Decklink question

[Kieran O Leary]

On 29 Sep 2017 03:22,  wrote:


I will continue to do testing..
>



This works and captures full range (data levels, but the captured data
happens to be video levels 64-940) to the output file and the out.mov file
looks good/clean. Not sure how to flag (metadata) output color space and
levels, but can always force it in most programs (KDEnlive, Resolve).


Add -color_range mpeg to your command line.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: increase fuzz for refcmp filter tests

[Tobias Rapp]

On 29.09.2017 00:10, Michael Niedermayer wrote:

On Thu, Sep 28, 2017 at 09:27:23AM +0200, Tobias Rapp wrote:

Should fix failing tests on GNU/kFreeBSD x86_32.

Signed-off-by: Tobias Rapp 
---
Michael: Have put you on CC as you seem to be the owner of the affected 
machines.


LGTM


Pushed, thanks.

Regards,
Tobias

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