[FFmpeg-devel] [PATCH] mpegdec: fix redundant dummy frames issue of interlaced clips
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, &h_chroma_shift, &v_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
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.
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
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(&p->buf[0]) != SYNC_WORD) > +while (2 * i + 3 < p->buf_size){ > +if (AV_RL16(&p->buf[2 * i++]) != SYNC_WORD) > return 0; > -j=AV_RL16(&p->buf[2]); > -if(j!=0x40 && j!=0x50) > +j = AV_RL16(&p->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
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
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
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
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 = &st->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.
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.
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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(&p->buf[0]) != SYNC_WORD) +while (2 * i + 3 < p->buf_size){ +if (AV_RL16(&p->buf[2 * i++]) != SYNC_WORD) return 0; -j=AV_RL16(&p->buf[2]); -if(j!=0x40 && j!=0x50) +j = AV_RL16(&p->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
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
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
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
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
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
--- 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 = &st->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
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
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
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
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
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
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
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
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
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
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
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
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
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" h264_rkmpp_decoder_select="h264_mp4toannex
Re: [FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding
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
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