Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

[Sasi Inguva]

Thanks. Sent the corrected patch.

On Tue, Oct 31, 2017 at 7:14 PM, Michael Niedermayer  wrote:

> On Tue, Oct 31, 2017 at 04:42:56PM -0700, Sasi Inguva wrote:
> > Partially fixes t/6699.
> > ---
> >  libavformat/mov.c  | 125 ++
> +--
> >  tests/fate/mov.mak |   8 
> >  2 files changed, 90 insertions(+), 43 deletions(-)
>
> Missing: ./tests/ref/fate/mov-ibi-elst-starts-b
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite
> number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> 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] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

[Sasi Inguva]

Partially fixes t/6699.
---
 libavformat/mov.c| 125 +++
 tests/fate/mov.mak   |   8 +++
 tests/ref/fate/mov-ibi-elst-starts-b |  33 +
 3 files changed, 123 insertions(+), 43 deletions(-)
 create mode 100644 tests/ref/fate/mov-ibi-elst-starts-b

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 60f0228e2d..a295445651 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3014,34 +3014,95 @@ static int get_edit_list_entry(MOVContext *mov,
 }
 
 /**
- * Find the closest previous frame to the timestamp, in e_old index
+ * Find the closest previous frame to the timestamp_pts, in e_old index
  * entries. Searching for just any frame / just key frames can be controlled by
  * last argument 'flag'.
- * Returns the index of the entry in st->index_entries if successful,
- * else returns -1.
+ * Here the timestamp_pts is considered to be a presentation timestamp and
+ * the timestamp of index entries are considered to be decoding timestamps.
+ *
+ * Returns 0 if successful in finding a frame, else returns -1.
+ * Places the found index corresponding output arg.
+ *
+ * If ctts_old is not NULL, then refines the searched entry by searching
+ * backwards from the found timestamp, to find the frame with correct PTS.
+ *
+ * Places the found ctts_index and ctts_sample in corresponding output args.
  */
-static int64_t find_prev_closest_index(AVStream *st,
-   AVIndexEntry *e_old,
-   int nb_old,
-   int64_t timestamp,
-   int flag)
+static int find_prev_closest_index(AVStream *st,
+   AVIndexEntry *e_old,
+   int nb_old,
+   MOVStts* ctts_data,
+   int64_t ctts_count,
+   int64_t timestamp_pts,
+   int flag,
+   int64_t* index,
+   int64_t* ctts_index,
+   int64_t* ctts_sample)
 {
+MOVStreamContext *msc = st->priv_data;
 AVIndexEntry *e_keep = st->index_entries;
 int nb_keep = st->nb_index_entries;
-int64_t found = -1;
 int64_t i = 0;
+int64_t index_ctts_count;
+
+av_assert0(index);
+
+// If dts_shift > 0, then all the index timestamps will have to be offset 
by
+// at least dts_shift amount to obtain PTS.
+// Hence we decrement the searched timestamp_pts by dts_shift to find the 
closest index element.
+if (msc->dts_shift > 0) {
+timestamp_pts -= msc->dts_shift;
+}
 
 st->index_entries = e_old;
 st->nb_index_entries = nb_old;
-found = av_index_search_timestamp(st, timestamp, flag | 
AVSEEK_FLAG_BACKWARD);
+*index = av_index_search_timestamp(st, timestamp_pts, flag | 
AVSEEK_FLAG_BACKWARD);
 
 // Keep going backwards in the index entries until the timestamp is the 
same.
-if (found >= 0) {
-for (i = found; i > 0 && e_old[i].timestamp == e_old[i - 1].timestamp;
+if (*index >= 0) {
+for (i = *index; i > 0 && e_old[i].timestamp == e_old[i - 1].timestamp;
  i--) {
 if ((flag & AVSEEK_FLAG_ANY) ||
 (e_old[i - 1].flags & AVINDEX_KEYFRAME)) {
-found = i - 1;
+*index = i - 1;
+}
+}
+}
+
+// If we have CTTS then refine the search, by searching backwards over PTS
+// computed by adding corresponding CTTS durations to index timestamps.
+if (ctts_data && *index >= 0) {
+av_assert0(ctts_index);
+av_assert0(ctts_sample);
+// Find out the ctts_index for the found frame.
+*ctts_index = 0;
+*ctts_sample = 0;
+for (index_ctts_count = 0; index_ctts_count < *index; 
index_ctts_count++) {
+if (*ctts_index < ctts_count) {
+(*ctts_sample)++;
+if (ctts_data[*ctts_index].count == *ctts_sample) {
+(*ctts_index)++;
+*ctts_sample = 0;
+}
+}
+}
+
+while (*index >= 0 && (*ctts_index) >= 0) {
+// Find a "key frame" with PTS <= timestamp_pts (So that we can 
decode B-frames correctly).
+// No need to add dts_shift to the timestamp here becase 
timestamp_pts has already been
+// compensated by dts_shift above.
+if ((e_old[*index].timestamp + ctts_data[*ctts_index].duration) <= 
timestamp_pts &&
+(e_old[*index].flags & AVINDEX_KEYFRAME)) {
+break;
+}
+
+(*index)--;
+if (*ctts_sample == 0) {
+(*ctts_index)--;
+if (*ctts_index >= 0)
+  *ctts_sample = ctts_data[*ctts_index].count - 1;
+} else {
+

[FFmpeg-devel] (no subject)

[Sasi Inguva]

Added the fate ref file to the commit. Thx.

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

Re: [FFmpeg-devel] [PATCH] lavf/vf_ocr: check ff_set_common_formats() return value

[Steven Liu]

2017-11-01 8:30 GMT+08:00 Moritz Barsnick :
> Signed-off-by: Moritz Barsnick 
> ---
>
> The only remaining unchecked one I could find in lavf. Fixes a warning,
> obviously.
>
>  libavfilter/vf_ocr.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_ocr.c b/libavfilter/vf_ocr.c
> index e003982f05..abfff49438 100644
> --- a/libavfilter/vf_ocr.c
> +++ b/libavfilter/vf_ocr.c
> @@ -90,9 +90,7 @@ static int query_formats(AVFilterContext *ctx)
>  AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
>  if (!fmts_list)
>  return AVERROR(ENOMEM);
> -ff_set_common_formats(ctx, fmts_list);
> -
> -return 0;
> +return ff_set_common_formats(ctx, fmts_list);
>  }
>
>  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> --
> 2.13.6
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/dca: return standard error codes in avpriv_dca_parse_core_frame_header()

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 05:27:35PM -0300, James Almer wrote:
> This prevents making the DCAParseError enum part of the ABI.
> 
> Signed-off-by: James Almer 
> ---
> Now actually paying attention to -Wempty-body warnings.
> 
>  libavcodec/dca.c | 11 ---
>  libavcodec/dca.h | 12 ++--
>  2 files changed, 18 insertions(+), 5 deletions(-)

works fine here, no more comments from me

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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/latmenc: Error out for invalid codecs

[Michael Niedermayer]

On Wed, Nov 01, 2017 at 02:17:06AM +0100, Carl Eugen Hoyos wrote:
> 2017-10-31 17:38 GMT+01:00 Michael Niedermayer :
> > On Mon, Oct 30, 2017 at 11:51:30PM +0100, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch makes sure the loas muxer does not try to write
> >> anything but aac and latm.
> >>
> >> Please comment, Carl Eugen
> >
> >>  latmenc.c |4 
> >>  1 file changed, 4 insertions(+)
> >> 2b64f3d5ecb189e77b85dbab7a6cbfe9657701f2  
> >> 0001-lavf-latmenc-Error-out-for-invalid-codecs.patch
> >> From 9f8f39b402f77b53613a395129f96feee5e873ba Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Mon, 30 Oct 2017 23:49:29 +0100
> >> Subject: [PATCH] lavf/latmenc: Error out for invalid codecs.
> >
> > isnt AV_CODEC_ID_MP4ALS supported too ? (i see ALS
> > related code in latmenc.c)
> 
> New patch attached.
> 
> Thank you, Carl Eugen

>  latmenc.c |4 
>  1 file changed, 4 insertions(+)
> c18fb099cde57aae9a9811b5ee1bf0da08cd9365  
> 0001-lavf-latmenc-Error-out-for-unsupported-codecs.patch
> From d31193d8d2702b0c340b0b4fd2f1682f09b3035c Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 1 Nov 2017 02:15:10 +0100
> Subject: [PATCH] lavf/latmenc: Error out for unsupported codecs.

probably ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 04:42:56PM -0700, Sasi Inguva wrote:
> Partially fixes t/6699.
> ---
>  libavformat/mov.c  | 125 
> +++--
>  tests/fate/mov.mak |   8 
>  2 files changed, 90 insertions(+), 43 deletions(-)

Missing: ./tests/ref/fate/mov-ibi-elst-starts-b

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

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


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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 08:24:37PM +, Derek Buitenhuis wrote:
> On 10/31/2017 2:25 AM, Michael Niedermayer wrote:
> > (though as said, this fix is not ideal or complete, I would very much
> >  prefer if this would be fixed by using a single buffer or any other
> >  solution that avoids the speedloss.)
> 
> Using a single buffer would be marginally faster, but it does not solve
> the underlying problem, which is that the NAL "cache" (nals_allocated)
> seems to be cumulative, and the size of each buffer in it seems to be
> the largest observed size of a NAL in that position.
> 
> Consider I could craft a stream that contains, in order:
> 
> Has 1999 tiny NALs, followed by 1 10MiB NAL, in packet 1.
> Has 1998 tiny NALs, followed by 1 10MiB NAL, in packet 2.
> .
> .
> .
> Has 500 tiny NALs, followed by 1 10MiB NAL, in packet 1500.
> .
> .
> .
> And so forth.
> 
> The result would be that we have 2000 10MiB buffers allocated
> in the NAL memory "pool" (nals_allocated == 2000), which will
> persist until the decode is deinitialized.
>
> Am I missing something here?

The idea would be that there would only be one uint8_t buffer and the
2000 entries from te pool would point into that.
So as a larger NAL shifts through the 2000 the pointers would get
distributed differently but the size would not grow
Any variable size buffer the H2645NAL needs would be such a "shared"
buffer

I dont know if theres anything that would make this non trivial to
implement.


>
> P.S. I see Kieran mailed the same thing as I wrote this.
> 
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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/latmenc: Error out for invalid codecs

[Carl Eugen Hoyos]

2017-10-31 17:38 GMT+01:00 Michael Niedermayer :
> On Mon, Oct 30, 2017 at 11:51:30PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch makes sure the loas muxer does not try to write
>> anything but aac and latm.
>>
>> Please comment, Carl Eugen
>
>>  latmenc.c |4 
>>  1 file changed, 4 insertions(+)
>> 2b64f3d5ecb189e77b85dbab7a6cbfe9657701f2  
>> 0001-lavf-latmenc-Error-out-for-invalid-codecs.patch
>> From 9f8f39b402f77b53613a395129f96feee5e873ba Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 30 Oct 2017 23:49:29 +0100
>> Subject: [PATCH] lavf/latmenc: Error out for invalid codecs.
>
> isnt AV_CODEC_ID_MP4ALS supported too ? (i see ALS
> related code in latmenc.c)

New patch attached.

Thank you, Carl Eugen
From d31193d8d2702b0c340b0b4fd2f1682f09b3035c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Nov 2017 02:15:10 +0100
Subject: [PATCH] lavf/latmenc: Error out for unsupported codecs.

---
 libavformat/latmenc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index 273197b..3b2d7af 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -89,6 +89,10 @@ static int latm_write_header(AVFormatContext *s)
 
 if (par->codec_id == AV_CODEC_ID_AAC_LATM)
 return 0;
+if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id != AV_CODEC_ID_MP4ALS) {
+av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are supported\n");
+return AVERROR_INVALIDDATA;
+}
 
 if (par->extradata_size > 0 &&
 latm_decode_extradata(ctx, par->extradata, par->extradata_size) < 0)
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 3/3] examples/filtering_audio: suppress the build warning.

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 04:29:02PM +0800, Steven Liu wrote:
> 2017-10-31 16:22 GMT+08:00 Jun Zhao :
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> patchset LGTM

will apply

thanks

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

Why not whip the teacher when the pupil misbehaves? -- 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] Support for h264/SVC over RTP and SVC base layer decoding in h264

[Carl Eugen Hoyos]

2017-10-31 19:53 GMT+01:00 Breeden, Joshua :
> Hello,
>
> First patch submission... hopefully I do all of this correctly.?

Your patches contain a lot of trailing whitespace (afaict...)
that cannot be committed to our repository, please remove it.

To find it you can use the script "tools/patcheck" in the
FFmpeg source.

The log message should start with "lavc/h264_parse: " and
"lavf/rtpdec_h264: " or similar, see the gitlog for the files.

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

Re: [FFmpeg-devel] [PATCH] avformat/mux: be less strict with bitstream filter failures

[Carl Eugen Hoyos]

2017-10-31 19:00 GMT+01:00 James Almer :
> This makes the autobsf feature behave the same as the manual
> bitstream filtering in ffmpeg.c
>
> Fixes ticket #6794
>
> Signed-off-by: James Almer 
> ---
>  libavformat/mux.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 77e03ee5ba..1445e7dcd6 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -876,7 +876,9 @@ static int do_packet_auto_bsf(AVFormatContext *s, 
> AVPacket *pkt) {
>  av_log(ctx, AV_LOG_ERROR,
>  "Failed to send packet to filter %s for stream %d\n",
>  ctx->filter->name, pkt->stream_index);
> -return ret;
> +if (s->error_recognition & AV_EF_EXPLODE)
> +return ret;
> +return 0;

Looks like a good idea to me.

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

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-11-01 1:34 GMT+01:00 Mark Thompson :
> On 01/11/17 00:29, Carl Eugen Hoyos wrote:
>> 2017-11-01 1:23 GMT+01:00 Mark Thompson :
>>
>>> Or libx264, which also lacks headers inside ffmpeg.  (We
>>> could dynamically load libx264 using reverse-enginereed
>>> non-GPL headers and then be able to enable it everywhere!
>>
>> But only with --enable-gpl, making the stunt less useful.
>
> With a different header and following the methods the other
> drivers are using, it would presumably be without --enable-gpl.

No.
License-wise, it of course makes not difference if linking
is done at compile-time, at startup or at run-time.

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

Re: [FFmpeg-devel] On in-tree external headers

[Michael Niedermayer]

On Wed, Nov 01, 2017 at 12:34:45AM +, Mark Thompson wrote:
> On 01/11/17 00:29, Carl Eugen Hoyos wrote:
> > 2017-11-01 1:23 GMT+01:00 Mark Thompson :
> > 
> >> Or libx264, which also lacks headers inside ffmpeg.  (We
> >> could dynamically load libx264 using reverse-enginereed
> >> non-GPL headers and then be able to enable it everywhere!
> > 
> > But only with --enable-gpl, making the stunt less useful.
> 
> With a different header and following the methods the other drivers are 
> using, it would presumably be without --enable-gpl.  This is, after all, 
> exactly what all of the proprietary drivers are doing to link proprietary and 
> GPL code while arguing that the GPL does not apply to their proprietary part.

AFAIK and IANAL
the proprietary drivers use the exception of the GPL for
"major components (compiler, kernel, and so on) of the operating system
 on which the executable runs"


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Michael Niedermayer]

Hi

On Tue, Oct 31, 2017 at 04:29:18PM +, Teresa Johnson wrote:
> It's needed for the same reason the used attribute was already added to the
> "static const" variables. For those, when building with just -O2, they
> could be removed by optimization since they had local (file) scope, and we
> couldn't see the uses in the inline assembly (without the used attribute).
> With ThinLTO we have whole program scope, so even though they are
> non-static and have global scope we can do dead code elimination on them if
> we don't see that they are used.

currently we add "used" to DECLARE_ASM_CONST()
which is specific to inline asm use.

DECLARE_ALIGNED() is not specific to use in asm.

For DECLARE_ASM_CONST() the "used" is unneeded only in the subset of
inline asm cases where it is accessed through the asm operands like:
__asm__ volatile(
"movq  %0, %%mm7\n\t"
"movq  %1, %%mm6\n\t"
::"m"(red_16mask),"m"(green_16mask));

The compiler has full vissibility here of the access and if it removes
it its a  compiler bug.

this is compared to code like:
 "pand "MANGLE(mask24l)", %%mm0\n\t"

Here the compiler has no easy vissibility of the use, it is part of
the asm string.

and comparing this to DECLARE_ALIGNED(), the big difference is
that DECLARE_ALIGNED() is used by plain C code which never should need
"used". So adding "used" to DECLARE_ALIGNED() would add alot more
"unused detection overriding" than what is needed



> 
> Teresa
> 
> On Tue, Oct 31, 2017 at 4:19 PM, Michael Niedermayer  > wrote:
> 
> > On Tue, Oct 31, 2017 at 03:52:14PM +, Thomas Köppe wrote:
> > > +Teresa, who drafted the patch initially.
> > >
> > > On 31 October 2017 at 15:38, Michael Niedermayer  > >
> > > wrote:
> > >
> > > > On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
> > > > > Variables used in inline assembly need to be marked with
> > > > attribute((used)).
> > > >
> > > > This should not be the case.
> > > > Variables referenced through in/out operands should not need that.
> > > > Only ones accessed directly bypassing operands should need this
> > > >
> > >
> > > I've added Teresa to the thread, who initially analyzed the problem. (For
> > > background on ThinLTO, see here cppcon talk:
> > > https://www.youtube.com/watch?v=p9nH2vZ2mNo.)
> > >
> > > [...]
> > > > > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned
> > (n)))
> > > > v
> > > > > +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__
> > > > ((aligned (n))) v
> > > >
> > > > which variables actually are affected/ need this ?
> > > >
> > >
> > > Without this annotation, and when compiling and linking with ThinLTO, I
> > get
> > > an undefined reference to "ff_h264_cabac_tables", and also to
> > > "ff_pw_96", "ff_pw_53",
> > > "ff_pw_42", "ff_w" and many more.
> >
> > i guess these are all accessed directly, like through MANGLE()
> >
> >
> > >
> > >
> > > > Marking all aligned variables as used makes it harder to spot unused
> > > > variables leading to accumulation of cruft
> > > >
> > >
> > > I see. Maybe we can annotate only the affected variables more granularly?
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Avoid a single point of failure, be that a person or equipment.
> >
> 
> 
> 
> -- 
> Teresa Johnson |  Software Engineer |  tejohn...@google.com |  408-460-2413
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 01/11/17 00:29, Carl Eugen Hoyos wrote:
> 2017-11-01 1:23 GMT+01:00 Mark Thompson :
> 
>> Or libx264, which also lacks headers inside ffmpeg.  (We
>> could dynamically load libx264 using reverse-enginereed
>> non-GPL headers and then be able to enable it everywhere!
> 
> But only with --enable-gpl, making the stunt less useful.

With a different header and following the methods the other drivers are using, 
it would presumably be without --enable-gpl.  This is, after all, exactly what 
all of the proprietary drivers are doing to link proprietary and GPL code while 
arguing that the GPL does not apply to their proprietary part.

> Anyway, this wasn't suggested and would not be accepted.
Indeed, it would be entirely absurd.

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

[FFmpeg-devel] [PATCH] lavf/vf_ocr: check ff_set_common_formats() return value

[Moritz Barsnick]

Signed-off-by: Moritz Barsnick 
---

The only remaining unchecked one I could find in lavf. Fixes a warning,
obviously.

 libavfilter/vf_ocr.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavfilter/vf_ocr.c b/libavfilter/vf_ocr.c
index e003982f05..abfff49438 100644
--- a/libavfilter/vf_ocr.c
+++ b/libavfilter/vf_ocr.c
@@ -90,9 +90,7 @@ static int query_formats(AVFilterContext *ctx)
 AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
 if (!fmts_list)
 return AVERROR(ENOMEM);
-ff_set_common_formats(ctx, fmts_list);
-
-return 0;
+return ff_set_common_formats(ctx, fmts_list);
 }
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
-- 
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-11-01 1:23 GMT+01:00 Mark Thompson :

> Or libx264, which also lacks headers inside ffmpeg.  (We
> could dynamically load libx264 using reverse-enginereed
> non-GPL headers and then be able to enable it everywhere!

But only with --enable-gpl, making the stunt less useful.

Anyway, this wasn't suggested and would not be accepted.

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 01/11/17 00:17, Mark Thompson wrote:
> On 01/11/17 00:07, Carl Eugen Hoyos wrote:
>> 2017-11-01 1:04 GMT+01:00 Mark Thompson :
>>> This is why I'm concerned that we are facilitating anti-open
>>> behaviour from Nvidia by making it easier to use the
>>> closed software than more open alternatives.
>>
>> But you do agree that there is nothing "open" about the AMD
>> driver in question?
> 
> True.  Neither the AMF nor libmfx drivers are really any better, though they 
> don't have the same silly hoops for the user to jump through (they have 
> different ones, though, especially for libmfx).  On the other hand, the open 
> VAAPI and VDPAU drivers are to some degree, and V4L2 could be (I'm unsure on 
> V4L2, I've never investigated the actual implementations behind any of them).

Or libx264, which also lacks headers inside ffmpeg.  (We could dynamically load 
libx264 using reverse-enginereed non-GPL headers and then be able to enable it 
everywhere!  How useful!)

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 01/11/17 00:07, Carl Eugen Hoyos wrote:
> 2017-11-01 1:04 GMT+01:00 Mark Thompson :
>> This is why I'm concerned that we are facilitating anti-open
>> behaviour from Nvidia by making it easier to use the
>> closed software than more open alternatives.
> 
> But you do agree that there is nothing "open" about the AMD
> driver in question?

True.  Neither the AMF nor libmfx drivers are really any better, though they 
don't have the same silly hoops for the user to jump through (they have 
different ones, though, especially for libmfx).  On the other hand, the open 
VAAPI and VDPAU drivers are to some degree, and V4L2 could be (I'm unsure on 
V4L2, I've never investigated the actual implementations behind any of them).

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

Re: [FFmpeg-devel] haunted by "undefined reference to `vaUnmapBuffer'"

[Moritz Barsnick]

Hi Sampsa

On Tue, Oct 31, 2017 at 21:38:42 +0200, Sampsa Riikonen wrote:
> Dear List,
> I am compiling a stripped-down, static versions of the libraries, i.e. :
> 
> libavcodec.a libavformat.a libavutil.a libswscale.a libavfilter.a 
> libswresample.a
> 
> and I'm "baking them in" into a custom shared-library.

this list, ffmpeg-devel, is for discussion of development *of* ffmpeg,
not of development *with* ffmpeg. For the latter, the list libav-users
is the appropriate one.

> All external libraries are disabled, and configure script tells me that:

You should also show your configure line used.

> CMakeFiles/Valkka.dir/src/filters.cpp.o -lX11 -lGLEW -lGLU -lGL 
> -L/home/sampsa/C/valkka/lib -Wl,--allow-multiple-definition 
> -Wl,-Bsymbolic -Wl,--start-group -Wl,--whole-archive -l:libliveMedia.a 
> -l:libgroupsock.a -l:libBasicUsageEnvironment.a -l:libUsageEnvironment.a 
> -l:libavfilter.a -l:libavformat.a -l:libavcodec.a -l:libavutil.a 
> -l:libswscale.a -l:libswresample.a -Wl,--no-whole-archive -Wl,--end-group

You need to determine the necessary dependencies from each libav*'s
pkg-config. It's not just "-lavsomething".

> There's no freaking way to get rid of these vaapi-related symbols..!

Probably, your configure picks up your locally installed libva(-devel),
and therefore enables either the vaapi encoder or a filter, or both.
Neither of these are hwaccels IIUC, so they won't show in that list.
But they should show up under encoders or filters, respectively.

You can use "--disable-vaapi" when configuring to git rid of them. Or
link your program(s) against the proper dependencies.
  I 
> the git branch
> origin/release/3.0

Why? How about 3.4 or master?

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

Re: [FFmpeg-devel] [RFC]lswr/rematrix: Support s32p

[Carl Eugen Hoyos]

2017-10-31 17:28 GMT+01:00 Michael Niedermayer :

>>  rematrix.c |   21 +++--
>>  1 file changed, 15 insertions(+), 6 deletions(-)
>> 9f50e61370cc72de000bb1174cbd8666388fdd9a  0001-lswr-Support-s32p.patch
>> From a93b9309d74f5eadece371ee1e682d266af6cd83 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 28 Oct 2017 22:52:02 +0200
>> Subject: [PATCH] lswr/rematrix: Support s32p.
>>
>> Fixes ticket #6785.
>> ---
>>  libswresample/rematrix.c |   21 +++--
>>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> should be ok

Patch applied.

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

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-11-01 1:04 GMT+01:00 Mark Thompson :
> This is why I'm concerned that we are facilitating anti-open
> behaviour from Nvidia by making it easier to use the
> closed software than more open alternatives.

But you do agree that there is nothing "open" about the AMD
driver in question?

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

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 31/10/17 23:52, Carl Eugen Hoyos wrote:
> 2017-10-31 17:52 GMT+01:00 Mark Thompson :
>> On 31/10/17 16:34, Timo Rothenpieler wrote:
> 
>>> We're not bundling entire 3rd party libs in-tree here, just
>>> API headers for system/driver APIs.
>>
>> What exactly would the policy be, then?
>>
>> "External headers for a system/driver API may be included in tree
>> if it makes building with support for this feature easier for users"
>> would cover pretty much everything.
>>
>> I'm definitely against a free-for-all where libmfx, V4L2, etc. all
>> get included.
> 
> Could you elaborate? I apparently miss something.
> Why would anybody want to put a libmfx or v4l2 header into the
> FFmpeg codebase?

For the same reason that they might add the AMD one - it would always be 
present so that no external dependencies are required for building.  The 
argument for AMD seems to be primarily "Nvidia has this so we should too" 
rather than anything to do with actual requirements (like libmfx or V4L2, it is 
easily available without bizarre hoops to jump through).  This is why I'm 
concerned that we are facilitating anti-open behaviour from Nvidia by making it 
easier to use the closed software than more open alternatives.

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: let avpriv_ac3_parse_header() allocate the AC3HeaderInfo struct

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 01:24:58AM -0300, James Almer wrote:
> This removes sizeof(AC3HeaderInfo) from the ABI.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/movenc.c | 72 
> +++-
>  1 file changed, 43 insertions(+), 29 deletions(-)

LGTM

thx

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] On in-tree external headers

[Carl Eugen Hoyos]

2017-10-31 17:52 GMT+01:00 Mark Thompson :
> On 31/10/17 16:34, Timo Rothenpieler wrote:

>> We're not bundling entire 3rd party libs in-tree here, just
>> API headers for system/driver APIs.
>
> What exactly would the policy be, then?
>
> "External headers for a system/driver API may be included in tree
> if it makes building with support for this feature easier for users"
> would cover pretty much everything.
>
> I'm definitely against a free-for-all where libmfx, V4L2, etc. all
> get included.

Could you elaborate? I apparently miss something.
Why would anybody want to put a libmfx or v4l2 header into the
FFmpeg codebase?

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

[Sasi Inguva]

Attaching the fate sample.

On Tue, Oct 31, 2017 at 4:42 PM, Sasi Inguva  wrote:

> Partially fixes t/6699.
> ---
>  libavformat/mov.c  | 125 ++
> +--
>  tests/fate/mov.mak |   8 
>  2 files changed, 90 insertions(+), 43 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 60f0228e2d..a295445651 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3014,34 +3014,95 @@ static int get_edit_list_entry(MOVContext *mov,
>  }
>
>  /**
> - * Find the closest previous frame to the timestamp, in e_old index
> + * Find the closest previous frame to the timestamp_pts, in e_old index
>   * entries. Searching for just any frame / just key frames can be
> controlled by
>   * last argument 'flag'.
> - * Returns the index of the entry in st->index_entries if successful,
> - * else returns -1.
> + * Here the timestamp_pts is considered to be a presentation timestamp and
> + * the timestamp of index entries are considered to be decoding
> timestamps.
> + *
> + * Returns 0 if successful in finding a frame, else returns -1.
> + * Places the found index corresponding output arg.
> + *
> + * If ctts_old is not NULL, then refines the searched entry by searching
> + * backwards from the found timestamp, to find the frame with correct PTS.
> + *
> + * Places the found ctts_index and ctts_sample in corresponding output
> args.
>   */
> -static int64_t find_prev_closest_index(AVStream *st,
> -   AVIndexEntry *e_old,
> -   int nb_old,
> -   int64_t timestamp,
> -   int flag)
> +static int find_prev_closest_index(AVStream *st,
> +   AVIndexEntry *e_old,
> +   int nb_old,
> +   MOVStts* ctts_data,
> +   int64_t ctts_count,
> +   int64_t timestamp_pts,
> +   int flag,
> +   int64_t* index,
> +   int64_t* ctts_index,
> +   int64_t* ctts_sample)
>  {
> +MOVStreamContext *msc = st->priv_data;
>  AVIndexEntry *e_keep = st->index_entries;
>  int nb_keep = st->nb_index_entries;
> -int64_t found = -1;
>  int64_t i = 0;
> +int64_t index_ctts_count;
> +
> +av_assert0(index);
> +
> +// If dts_shift > 0, then all the index timestamps will have to be
> offset by
> +// at least dts_shift amount to obtain PTS.
> +// Hence we decrement the searched timestamp_pts by dts_shift to find
> the closest index element.
> +if (msc->dts_shift > 0) {
> +timestamp_pts -= msc->dts_shift;
> +}
>
>  st->index_entries = e_old;
>  st->nb_index_entries = nb_old;
> -found = av_index_search_timestamp(st, timestamp, flag |
> AVSEEK_FLAG_BACKWARD);
> +*index = av_index_search_timestamp(st, timestamp_pts, flag |
> AVSEEK_FLAG_BACKWARD);
>
>  // Keep going backwards in the index entries until the timestamp is
> the same.
> -if (found >= 0) {
> -for (i = found; i > 0 && e_old[i].timestamp == e_old[i -
> 1].timestamp;
> +if (*index >= 0) {
> +for (i = *index; i > 0 && e_old[i].timestamp == e_old[i -
> 1].timestamp;
>   i--) {
>  if ((flag & AVSEEK_FLAG_ANY) ||
>  (e_old[i - 1].flags & AVINDEX_KEYFRAME)) {
> -found = i - 1;
> +*index = i - 1;
> +}
> +}
> +}
> +
> +// If we have CTTS then refine the search, by searching backwards
> over PTS
> +// computed by adding corresponding CTTS durations to index
> timestamps.
> +if (ctts_data && *index >= 0) {
> +av_assert0(ctts_index);
> +av_assert0(ctts_sample);
> +// Find out the ctts_index for the found frame.
> +*ctts_index = 0;
> +*ctts_sample = 0;
> +for (index_ctts_count = 0; index_ctts_count < *index;
> index_ctts_count++) {
> +if (*ctts_index < ctts_count) {
> +(*ctts_sample)++;
> +if (ctts_data[*ctts_index].count == *ctts_sample) {
> +(*ctts_index)++;
> +*ctts_sample = 0;
> +}
> +}
> +}
> +
> +while (*index >= 0 && (*ctts_index) >= 0) {
> +// Find a "key frame" with PTS <= timestamp_pts (So that we
> can decode B-frames correctly).
> +// No need to add dts_shift to the timestamp here becase
> timestamp_pts has already been
> +// compensated by dts_shift above.
> +if ((e_old[*index].timestamp + ctts_data[*ctts_index].duration)
> <= timestamp_pts &&
> +(e_old[*index].flags & AVINDEX_KEYFRAME)) {
> +break;
> +}
> +
> +

[FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

[Sasi Inguva]

Partially fixes t/6699.
---
 libavformat/mov.c  | 125 +++--
 tests/fate/mov.mak |   8 
 2 files changed, 90 insertions(+), 43 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 60f0228e2d..a295445651 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3014,34 +3014,95 @@ static int get_edit_list_entry(MOVContext *mov,
 }
 
 /**
- * Find the closest previous frame to the timestamp, in e_old index
+ * Find the closest previous frame to the timestamp_pts, in e_old index
  * entries. Searching for just any frame / just key frames can be controlled by
  * last argument 'flag'.
- * Returns the index of the entry in st->index_entries if successful,
- * else returns -1.
+ * Here the timestamp_pts is considered to be a presentation timestamp and
+ * the timestamp of index entries are considered to be decoding timestamps.
+ *
+ * Returns 0 if successful in finding a frame, else returns -1.
+ * Places the found index corresponding output arg.
+ *
+ * If ctts_old is not NULL, then refines the searched entry by searching
+ * backwards from the found timestamp, to find the frame with correct PTS.
+ *
+ * Places the found ctts_index and ctts_sample in corresponding output args.
  */
-static int64_t find_prev_closest_index(AVStream *st,
-   AVIndexEntry *e_old,
-   int nb_old,
-   int64_t timestamp,
-   int flag)
+static int find_prev_closest_index(AVStream *st,
+   AVIndexEntry *e_old,
+   int nb_old,
+   MOVStts* ctts_data,
+   int64_t ctts_count,
+   int64_t timestamp_pts,
+   int flag,
+   int64_t* index,
+   int64_t* ctts_index,
+   int64_t* ctts_sample)
 {
+MOVStreamContext *msc = st->priv_data;
 AVIndexEntry *e_keep = st->index_entries;
 int nb_keep = st->nb_index_entries;
-int64_t found = -1;
 int64_t i = 0;
+int64_t index_ctts_count;
+
+av_assert0(index);
+
+// If dts_shift > 0, then all the index timestamps will have to be offset 
by
+// at least dts_shift amount to obtain PTS.
+// Hence we decrement the searched timestamp_pts by dts_shift to find the 
closest index element.
+if (msc->dts_shift > 0) {
+timestamp_pts -= msc->dts_shift;
+}
 
 st->index_entries = e_old;
 st->nb_index_entries = nb_old;
-found = av_index_search_timestamp(st, timestamp, flag | 
AVSEEK_FLAG_BACKWARD);
+*index = av_index_search_timestamp(st, timestamp_pts, flag | 
AVSEEK_FLAG_BACKWARD);
 
 // Keep going backwards in the index entries until the timestamp is the 
same.
-if (found >= 0) {
-for (i = found; i > 0 && e_old[i].timestamp == e_old[i - 1].timestamp;
+if (*index >= 0) {
+for (i = *index; i > 0 && e_old[i].timestamp == e_old[i - 1].timestamp;
  i--) {
 if ((flag & AVSEEK_FLAG_ANY) ||
 (e_old[i - 1].flags & AVINDEX_KEYFRAME)) {
-found = i - 1;
+*index = i - 1;
+}
+}
+}
+
+// If we have CTTS then refine the search, by searching backwards over PTS
+// computed by adding corresponding CTTS durations to index timestamps.
+if (ctts_data && *index >= 0) {
+av_assert0(ctts_index);
+av_assert0(ctts_sample);
+// Find out the ctts_index for the found frame.
+*ctts_index = 0;
+*ctts_sample = 0;
+for (index_ctts_count = 0; index_ctts_count < *index; 
index_ctts_count++) {
+if (*ctts_index < ctts_count) {
+(*ctts_sample)++;
+if (ctts_data[*ctts_index].count == *ctts_sample) {
+(*ctts_index)++;
+*ctts_sample = 0;
+}
+}
+}
+
+while (*index >= 0 && (*ctts_index) >= 0) {
+// Find a "key frame" with PTS <= timestamp_pts (So that we can 
decode B-frames correctly).
+// No need to add dts_shift to the timestamp here becase 
timestamp_pts has already been
+// compensated by dts_shift above.
+if ((e_old[*index].timestamp + ctts_data[*ctts_index].duration) <= 
timestamp_pts &&
+(e_old[*index].flags & AVINDEX_KEYFRAME)) {
+break;
+}
+
+(*index)--;
+if (*ctts_sample == 0) {
+(*ctts_index)--;
+if (*ctts_index >= 0)
+  *ctts_sample = ctts_data[*ctts_index].count - 1;
+} else {
+(*ctts_sample)--;
 }
 }
 }
@@ -3049,7 +3110,7 @@ static int64_t 

Re: [FFmpeg-devel] haunted by "undefined reference to `vaUnmapBuffer'"

[Carl Eugen Hoyos]

2017-10-31 20:38 GMT+01:00 Sampsa Riikonen :

> I am compiling

Please post on the user mailing list:
http://ffmpeg.org/contact.html#MailingLists

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

[FFmpeg-devel] [PATCH v6 1/2 ] avformat/mpegts: opus muxing for mapping family 255

[pkv.stream]

Le 29/10/2017 à 4:44 PM, Michael Niedermayer a écrit :

On Sat, Oct 28, 2017 at 03:49:13AM +0200, pkv.stream wrote:


  mpegtsenc.c |   67 
+---
  1 file changed, 60 insertions(+), 7 deletions(-)
1423a193788547952e3c4cdcb424b4724b0f1157  
0001-libavf-mpegts-opus-muxing-for-mapping-family-255.patch
 From 105f20b8af8ce5376165ca30a81276dae2e61e40 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sat, 28 Oct 2017 02:48:08 +0200
Subject: [PATCH 1/2] libavf/mpegts: opus muxing for mapping family 255

Adds to mpegts muxer the capability  to mux libopus with mapping family
255, following the provisional spec for opus in mepg-ts
(https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).

Signed-off-by: pkviet 
---
  libavformat/mpegtsenc.c | 67 +++--
  1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fdfa544..a31663c 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -28,6 +28,7 @@
  #include "libavutil/opt.h"
  
  #include "libavcodec/internal.h"

+#include "libavcodec/put_bits.h"
  
  #include "avformat.h"

  #include "avio_internal.h"
@@ -291,6 +292,9 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  MpegTSWrite *ts = s->priv_data;
  uint8_t data[SECTION_LENGTH], *q, *desc_length_ptr, 
*program_info_length_ptr;
  int val, stream_type, i, err = 0;
+uint8_t channel_count, stream_count, coupled_stream_count, *buf;
+PutBitContext pbc;
+size_t buf_size;
  
  q = data;

  put16(, 0xe000 | service->pcr_pid);
@@ -421,8 +425,8 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 'D';
  }
  if (st->codecpar->codec_id==AV_CODEC_ID_OPUS) {
-/* 6 bytes registration descriptor, 4 bytes Opus audio 
descriptor */
-if (q - data > SECTION_LENGTH - 6 - 4) {
+/* 6 bytes registration descriptor, 6 bytes Opus audio 
descriptor */
+if (q - data > SECTION_LENGTH - 6 - 6) {
  err = 1;
  break;
  }
@@ -435,8 +439,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 's';
  
  *q++ = 0x7f; /* DVB extension descriptor */

-*q++ = 2;
-*q++ = 0x80;
+/* descriptor_length */
+if (st->codecpar->extradata[18] == 255) {
+/* dual mono */
+if (st->codecpar->channels == 2) {
+*q++ = 2;
+} else {
+/* channel_config_code 0x81 */
+*q++ = st->codecpar->channels + 6;
+}
+} else {
+*q++ = 2;
+}
+*q++ = 0x80; /* descriptor_tag_extension */
  
  if (st->codecpar->extradata && st->codecpar->extradata_size >= 19) {

  if (st->codecpar->extradata[18] == 0 && 
st->codecpar->channels <= 2) {
@@ -483,9 +498,47 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
  *q++ = 0xff;
  }
  } else {
-/* Unsupported */
-av_log(s, AV_LOG_ERROR, "Unsupported Opus channel mapping for 
family %d", st->codecpar->extradata[18]);
-*q++ = 0xff;
+/* mapping family 255 , set channel_config_code to 
0x81 except for dual-mono */
+if (st->codecpar->extradata[18] == 255) {
+/* dual mono */
+if (st->codecpar->channels == 2 && 
st->codecpar->extradata[19] == 1) {
+*q++ = 0x00;
+} else if (st->codecpar->channels == 2 && 
st->codecpar->extradata[19] == 2) {
+*q++ = 0x80;
+} else {
+/* application defined channel configuration */
+*q++ = 0x81;
+*q++ = st->codecpar->channels;
+*q++ = st->codecpar->extradata[18];
+channel_count = st->codecpar->channels;
+stream_count = st->codecpar->extradata[19];
+coupled_stream_count = 
st->codecpar->extradata[20];
+buf = av_mallocz_array( st->codecpar->channels 
+ 2 , sizeof(uint8_t));
+if (!buf) {
+av_freep(buf);

that looks wrong



+return 

[FFmpeg-devel] [PATCH v6 2/2 ] avformat/mpegts: opus demuxing for mapping family 255

[pkv.stream]

Le 31/10/2017 à 6:28 PM, Michael Niedermayer a écrit :
mpegts.c | 84 
---

  1 file changed, 70 insertions(+), 14 deletions(-)
6648bab53735f1efaf0d6cd698dbc2398b483c3f  
0002-libavf-mpegts-opus-demuxing-for-mapping-family-255.patch
 From 2e0504728b81e0f35ba856c24cff14fa70680d8b Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 29 Oct 2017 22:57:25 +0100
Subject: [PATCH 2/2] libavf/mpegts: opus demuxing for mapping family 255

Adds to mpegts muxer the capability  to demux libopus with mapping
family 255, following the provisional spec for opus in mepg-ts
(https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).

Signed-off-by: pkviet 
---
  libavformat/mpegts.c | 84 +++-
  1 file changed, 70 insertions(+), 14 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 53cbcfb..3aa06f0 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,7 @@
  #include "avio_internal.h"
  #include "mpeg.h"
  #include "isom.h"
+#include "math.h"
  
  /* maximum size in which we look for synchronization if

   * synchronization is lost */
@@ -1633,7 +1634,7 @@ static const uint8_t opus_stream_cnt[9] = {
  1, 1, 1, 2, 2, 3, 4, 4, 5,
  };
  
-static const uint8_t opus_channel_map[8][8] = {

+static const uint8_t opus_channel_map_a[8][8] = {
  { 0 },
  { 0,1 },
  { 0,2,1 },
@@ -1644,13 +1645,25 @@ static const uint8_t opus_channel_map[8][8] = {
  { 0,6,1,2,3,4,5,7 },
  };
  
+static const uint8_t opus_channel_map_b[8][8] = {

+{ 0 },
+{ 0,1 },
+{ 0,1,2 },
+{ 0,1,2,3 },
+{ 0,1,2,3,4 },
+{ 0,1,2,3,4,5 },
+{ 0,1,2,3,4,5,6 },
+{ 0,1,2,3,4,5,6,7 },
+};
+
  int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int 
stream_type,
const uint8_t **pp, const uint8_t 
*desc_list_end,
Mp4Descr *mp4_descr, int mp4_descr_count, int 
pid,
MpegTSContext *ts)
  {
  const uint8_t *desc_end;
-int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
channel_config_code;
+int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
channel_config_code, channel_count, mapping_family, stream_count, 
coupled_stream_count;
+GetBitContext gb;
  char language[252];
  int i;
  
@@ -1660,6 +1673,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int stream_type

  desc_len = get8(pp, desc_list_end);
  if (desc_len < 0)
  return AVERROR_INVALIDDATA;
+
  desc_end = *pp + desc_len;
  if (desc_end > desc_list_end)
  return AVERROR_INVALIDDATA;
@@ -1871,26 +1885,68 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
  if (st->codecpar->codec_id == AV_CODEC_ID_OPUS &&
  ext_desc_tag == 0x80) { /* User defined (provisional Opus) */
  if (!st->codecpar->extradata) {
-st->codecpar->extradata = 
av_mallocz(sizeof(opus_default_extradata) +
- 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
-
-st->codecpar->extradata_size = sizeof(opus_default_extradata);
-memcpy(st->codecpar->extradata, opus_default_extradata, 
sizeof(opus_default_extradata));
-
  channel_config_code = get8(pp, desc_end);
  if (channel_config_code < 0)
  return AVERROR_INVALIDDATA;
+
+if (channel_config_code != 0x81) {
+st->codecpar->extradata = 
av_mallocz(sizeof(opus_default_extradata) +
+AV_INPUT_BUFFER_PADDING_SIZE);
+if (!st->codecpar->extradata)
+return AVERROR(ENOMEM);
+st->codecpar->extradata_size = 
sizeof(opus_default_extradata);
+memcpy(st->codecpar->extradata, opus_default_extradata, 
sizeof(opus_default_extradata));
+}
+
  if (channel_config_code <= 0x8) {
  st->codecpar->extradata[9]  = channels = 
channel_config_code ? channel_config_code : 2;
  st->codecpar->extradata[18] = channel_config_code ? 
(channels > 2) : /* Dual Mono */ 255;
  st->codecpar->extradata[19] = 
opus_stream_cnt[channel_config_code];
  st->codecpar->extradata[20] = 
opus_coupled_stream_cnt[channel_config_code];
-memcpy(>codecpar->extradata[21], 
opus_channel_map[channels - 1], channels);
-} else {
-avpriv_request_sample(fc, "Opus in MPEG-TS - channel_config_code 
> 0x8");
-}
+memcpy(>codecpar->extradata[21], 
opus_channel_map_a[channels - 1], channels);

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Kieran Kunhya]

On Tue, 31 Oct 2017 at 22:36 Niki Bowe 
wrote:

> I was going to prepare a patch, but it sounds like Kieran is going to.
> Thank you Kieran. Let me know if there's anything you want me to do, or if
> you would prefer me to do it for the experience.
>
> As for the NAL memory pool, I think I see what you mean. You are saying
> h264dec.c is reusing the H2645Packet packet in decode_nal_units, so any
> growth in nals_allocated from previous packets carries over to later
> packets, and also the nals themselves also carry over even if the current
> packet has small pkt->nb_nals.
> Moving rbsp_buffer (and maybe skipped_bytes_pos) out of the nals and into
> H2645Packet should fix the worst of this.
>

I am not sure this is possible. I will see tomorrow.
Just FYI we are regularly seeing OOMs on some 24/7 live streams as a result
of h2645_parser.

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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Niki Bowe]

Thank you Kieran, Michael, Derek, and Carl.

I ran some benchmarks and the patch I provided really does have a speed
impact so I was considering alternative ways to achieve the same result.
After a little thought last week I came to the same conclusion as Michael
that a single rbsp_buffer per packet, with the nals pointing into that
would be ideal because
 * allows a single allocation for all the NALs, sized to the size of the
packet (+ padding. see next)
 * I think the padding is only to allow unchecked bitstream reading, so we
only need 1 unit of padding (MAX_MBPAIR_SIZE) if we have a single buffer,
rather than 1 per NAL.
Also IIRC it used to be this way a long time ago.

Likewise skipped_bytes_pos could also be made a single buffer for the
packet rather than 1 per NALU. Probably not as big a benefit to be made
there though, besides avoiding some allocations.

I was going to prepare a patch, but it sounds like Kieran is going to.
Thank you Kieran. Let me know if there's anything you want me to do, or if
you would prefer me to do it for the experience.

As for the NAL memory pool, I think I see what you mean. You are saying
h264dec.c is reusing the H2645Packet packet in decode_nal_units, so any
growth in nals_allocated from previous packets carries over to later
packets, and also the nals themselves also carry over even if the current
packet has small pkt->nb_nals.
Moving rbsp_buffer (and maybe skipped_bytes_pos) out of the nals and into
H2645Packet should fix the worst of this.




On Tue, Oct 31, 2017 at 1:28 PM, Kieran Kunhya  wrote:

> >
> > Am I missing something here?
> >
> > P.S. I see Kieran mailed the same thing as I wrote this.
> >
>
> Further to Derek's excellent explanation, I think the best way is to go
> back to the old "in-place" NAL parsing code for H264.
> I will prepare a patch to do this.
>
> Kieran
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



-- 

Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Kieran Kunhya]

>
> Am I missing something here?
>
> P.S. I see Kieran mailed the same thing as I wrote this.
>

Further to Derek's excellent explanation, I think the best way is to go
back to the old "in-place" NAL parsing code for H264.
I will prepare a patch to do this.

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

[FFmpeg-devel] [PATCH] avcodec/dca: return standard error codes in avpriv_dca_parse_core_frame_header()

[James Almer]

This prevents making the DCAParseError enum part of the ABI.

Signed-off-by: James Almer 
---
Now actually paying attention to -Wempty-body warnings.

 libavcodec/dca.c | 11 ---
 libavcodec/dca.h | 12 ++--
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dca.c b/libavcodec/dca.c
index 942fe6c3c9..a0729e61ab 100644
--- a/libavcodec/dca.c
+++ b/libavcodec/dca.c
@@ -149,9 +149,14 @@ int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, 
GetBitContext *gb)
 int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, const uint8_t 
*buf, int size)
 {
 GetBitContext gb;
+int ret;
 
-if (init_get_bits8(, buf, size) < 0)
-return DCA_PARSE_ERROR_INVALIDDATA;
+ret = init_get_bits8(, buf, size);
+if (ret < 0)
+return ret;
 
-return ff_dca_parse_core_frame_header(h, );
+if (ff_dca_parse_core_frame_header(h, ) < 0)
+return AVERROR_INVALIDDATA;
+
+return 0;
 }
diff --git a/libavcodec/dca.h b/libavcodec/dca.h
index c70598af92..b05e5f896e 100644
--- a/libavcodec/dca.h
+++ b/libavcodec/dca.h
@@ -46,7 +46,6 @@ enum DCAParseError {
 DCA_PARSE_ERROR_RESERVED_BIT= -7,
 DCA_PARSE_ERROR_LFE_FLAG= -8,
 DCA_PARSE_ERROR_PCM_RES = -9,
-DCA_PARSE_ERROR_INVALIDDATA = -10,
 };
 
 typedef struct DCACoreFrameHeader {
@@ -211,10 +210,19 @@ int avpriv_dca_convert_bitstream(const uint8_t *src, int 
src_size, uint8_t *dst,
 
 /**
  * Parse and validate core frame header
- * @return 0 on success, negative DCA_PARSE_ERROR_ code on failure
+ * @param[out] hPointer to struct where header info is written.
+ * @param[in]  buf  Pointer to the data buffer
+ * @param[in]  size Size of the data buffer
+ * @return 0 on success, negative AVERROR code on failure
  */
 int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, const uint8_t 
*buf, int size);
 
+/**
+ * Parse and validate core frame header
+ * @param[out] h   Pointer to struct where header info is written.
+ * @param[in]  gbc BitContext containing the first 54 bits of the frame.
+ * @return 0 on success, negative DCA_PARSE_ERROR_ code on failure
+ */
 int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, GetBitContext *gb);
 
 #endif /* AVCODEC_DCA_H */
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Derek Buitenhuis]

On 10/31/2017 2:25 AM, Michael Niedermayer wrote:
> (though as said, this fix is not ideal or complete, I would very much
>  prefer if this would be fixed by using a single buffer or any other
>  solution that avoids the speedloss.)

Using a single buffer would be marginally faster, but it does not solve
the underlying problem, which is that the NAL "cache" (nals_allocated)
seems to be cumulative, and the size of each buffer in it seems to be
the largest observed size of a NAL in that position.

Consider I could craft a stream that contains, in order:

Has 1999 tiny NALs, followed by 1 10MiB NAL, in packet 1.
Has 1998 tiny NALs, followed by 1 10MiB NAL, in packet 2.
.
.
.
Has 500 tiny NALs, followed by 1 10MiB NAL, in packet 1500.
.
.
.
And so forth.

The result would be that we have 2000 10MiB buffers allocated
in the NAL memory "pool" (nals_allocated == 2000), which will
persist until the decode is deinitialized.

Am I missing something here?

P.S. I see Kieran mailed the same thing as I wrote this.

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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Kieran Kunhya]

>
> This reduces memory consumption to linear from qudratic but i think
> it still can be made to allocate very large amounts of memory.
> That is with many small NAL units MAX_MBPAIR_SIZE would be allocated
> for each.in worst case.
> So this does fix the qudratic issue but not the OOM issue.
> Using the same buffer for all would fix it unless iam missing something.
> Using the same buffer avoids the padding needs for all but the last.
> So its alot less memory for many small nal units
>

This wouldn't fix the issue because the nals_allocated cache could still
grow with a crafted stream.

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

[FFmpeg-devel] haunted by "undefined reference to `vaUnmapBuffer'"

[Sampsa Riikonen]

Dear List,

I am compiling a stripped-down, static versions of the libraries, i.e. :

libavcodec.a libavformat.a libavutil.a libswscale.a libavfilter.a 
libswresample.a


and I'm "baking them in" into a custom shared-library.

All external libraries are disabled, and configure script tells me that:

-
...
Enabled programs:
ffmpeg  ffprobe ffserver

External libraries:

Enabled decoders:
h263h264vc1

Enabled encoders:
rawvideo

Enabled hwaccels:

Enabled parsers:
...
--

i.e., no external libraries, no hw accelerators, etc.

I link with

/usr/bin/c++  -fPIC -g  -shared -Wl,-soname,libValkka.so.0 -o 
lib/libValkka.so.0.1.0 CMakeFiles/Valkka.dir/src/avthread.cpp.o 
CMakeFiles/Valkka.dir/src/opengl.cpp.o 
CMakeFiles/Valkka.dir/src/openglthread.cpp.o 
CMakeFiles/Valkka.dir/src/frames.cpp.o 
CMakeFiles/Valkka.dir/src/threads.cpp.o 
CMakeFiles/Valkka.dir/src/tools.cpp.o 
CMakeFiles/Valkka.dir/src/chains.cpp.o 
CMakeFiles/Valkka.dir/src/shaders.cpp.o 
CMakeFiles/Valkka.dir/src/logging.cpp.o 
CMakeFiles/Valkka.dir/src/live.cpp.o 
CMakeFiles/Valkka.dir/src/avdep.cpp.o 
CMakeFiles/Valkka.dir/src/queues.cpp.o 
CMakeFiles/Valkka.dir/src/livethread.cpp.o 
CMakeFiles/Valkka.dir/src/decoders.cpp.o 
CMakeFiles/Valkka.dir/src/filters.cpp.o -lX11 -lGLEW -lGLU -lGL 
-L/home/sampsa/C/valkka/lib -Wl,--allow-multiple-definition 
-Wl,-Bsymbolic -Wl,--start-group -Wl,--whole-archive -l:libliveMedia.a 
-l:libgroupsock.a -l:libBasicUsageEnvironment.a -l:libUsageEnvironment.a 
-l:libavfilter.a -l:libavformat.a -l:libavcodec.a -l:libavutil.a 
-l:libswscale.a -l:libswresample.a -Wl,--no-whole-archive -Wl,--end-group


But when creating executables

/usr/bin/c++   -g CMakeFiles/threads_test.dir/test/threads_test.cpp.o  
-o bin/threads_test -rdynamic -lValkka 
-L/home/sampsa/C/valkka/build_basic/lib
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaUnmapBuffer'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaDestroyBuffer'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaCreateBuffer'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaRenderPicture'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaMapBuffer'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaEndPicture'
/home/sampsa/C/valkka/build_basic/lib/libValkka.so: undefined reference 
to `vaBeginPicture


There's no freaking way to get rid of these vaapi-related symbols..!  I 
used to be able to do this with an older (1 year+) version of the code, 
but now I'm getting way too much gray hair. I'm trying to do this with 
the git branch


origin/release/3.0

It seems they come about in the following way:


grep -nr "vaUnmap"

libavcodec/vaapi.c:79:vaUnmapBuffer(vactx->display, 
vactx->pic_param_buf_id);
libavcodec/vaapi.c:83:vaUnmapBuffer(vactx->display, 
vactx->iq_matrix_buf_id);
libavcodec/vaapi.c:88:vaUnmapBuffer(vactx->display, 
vactx->bitplane_buf_id);

Binary file libavcodec/vaapi.o matches
Binary file libavcodec/libavcodec.so.57 matches
Binary file libavcodec/libavcodec.a matches
-

My own code is in cpp and in my header files I do:

--
extern "C" {
#include 
#include 
#include 
#include 
}
--

Growing desperate.  Help appreciated!

Regards,

Sampsa


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

[FFmpeg-devel] [PATCH] avformat/utils: Look at the first 3 frames if timestamps indicate frame reorder but decoder delay does not

[Michael Niedermayer]

Fixes: Ticket6487

Signed-off-by: Michael Niedermayer 
---
 libavformat/avformat.h|  1 +
 libavformat/utils.c   | 16 
 tests/ref/fate/mov-zombie |  4 ++--
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b36e2a3bd4..e7393bdefb 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1026,6 +1026,7 @@ typedef struct AVStream {
 double (*duration_error)[2][MAX_STD_TIMEBASES];
 int64_t codec_info_duration;
 int64_t codec_info_duration_fields;
+int frame_delay_evidence;
 
 /**
  * 0  -> decoder has not been searched for yet.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index cbfb78bf4d..f5623b4137 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3626,6 +3626,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 /* check if one codec still needs to be handled */
 for (i = 0; i < ic->nb_streams; i++) {
 int fps_analyze_framecount = 20;
+int count;
 
 st = ic->streams[i];
 if (!has_codec_parameters(st, NULL))
@@ -3642,14 +3643,18 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
 fps_analyze_framecount = 0;
 /* variable fps and no guess at the real fps */
+count = (ic->iformat->flags & AVFMT_NOTIMESTAMPS) ?
+   st->info->codec_info_duration_fields/2 :
+   st->info->duration_count;
 if (!(st->r_frame_rate.num && st->avg_frame_rate.num) &&
 st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
-int count = (ic->iformat->flags & AVFMT_NOTIMESTAMPS) ?
-st->info->codec_info_duration_fields/2 :
-st->info->duration_count;
 if (count < fps_analyze_framecount)
 break;
 }
+// Look at the first 3 frames if there is evidence of frame delay
+// but the decoder delay is not set.
+if (st->info->frame_delay_evidence && count < 2 && 
st->internal->avctx->has_b_frames == 0)
+break;
 if (!st->internal->avctx->extradata &&
 (!st->internal->extract_extradata.inited ||
  st->internal->extract_extradata.bsf) &&
@@ -3799,10 +3804,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st->info->codec_info_duration_fields += st->parser && 
st->need_parsing && avctx->ticks_per_frame ==2 ? st->parser->repeat_pict + 1 : 
2;
 }
 }
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
 #if FF_API_R_FRAME_RATE
-if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
 ff_rfps_add_frame(ic, st, pkt->dts);
 #endif
+if (pkt->dts != pkt->pts && pkt->dts != AV_NOPTS_VALUE && pkt->pts 
!= AV_NOPTS_VALUE)
+st->info->frame_delay_evidence = 1;
+}
 if (!st->internal->avctx->extradata) {
 ret = extract_extradata(st, pkt);
 if (ret < 0)
diff --git a/tests/ref/fate/mov-zombie b/tests/ref/fate/mov-zombie
index e89abb1167..fef2adc354 100644
--- a/tests/ref/fate/mov-zombie
+++ b/tests/ref/fate/mov-zombie
@@ -1,6 +1,6 @@
 
packet|codec_type=video|stream_index=0|pts=0|pts_time=0.00|dts=-3004|dts_time=-0.033378|duration=3003|duration_time=0.033367|convergence_duration=N/A|convergence_duration_time=N/A|size=4133|pos=11309|flags=K_
-frame|media_type=video|stream_index=0|key_frame=1|pkt_pts=0|pkt_pts_time=0.00|pkt_dts=-3004|pkt_dts_time=-0.033378|best_effort_timestamp=0|best_effort_timestamp_time=0.00|pkt_duration=3003|pkt_duration_time=0.033367|pkt_pos=11309|pkt_size=4133|width=160|height=240|pix_fmt=yuv420p|sample_aspect_ratio=2:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=tv|color_space=smpte170m|color_primaries=smpte170m|color_transfer=bt709|chroma_location=topleft
 
packet|codec_type=video|stream_index=0|pts=5440|pts_time=0.060444|dts=-567|dts_time=-0.006300|duration=3003|duration_time=0.033367|convergence_duration=N/A|convergence_duration_time=N/A|size=1077|pos=15442|flags=__
+frame|media_type=video|stream_index=0|key_frame=1|pkt_pts=0|pkt_pts_time=0.00|pkt_dts=-567|pkt_dts_time=-0.006300|best_effort_timestamp=0|best_effort_timestamp_time=0.00|pkt_duration=3003|pkt_duration_time=0.033367|pkt_pos=11309|pkt_size=4133|width=160|height=240|pix_fmt=yuv420p|sample_aspect_ratio=2:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=tv|color_space=smpte170m|color_primaries=smpte170m|color_transfer=bt709|chroma_location=topleft
 

Re: [FFmpeg-devel] [PATCH 1/2] configure: Rename wincrypt to advapi32 for consistency with existing uses of check_lib

[Aaron Levinson]

On 10/31/2017 11:44 AM, Hendrik Leppkes wrote:

On Tue, Oct 31, 2017 at 6:50 PM, Aaron Levinson
 wrote:

Signed-off-by: Aaron Levinson 
---
  configure | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index ea22d692b9..572299c9d3 100755
--- a/configure
+++ b/configure
@@ -3327,7 +3327,7 @@ avformat_deps="avcodec avutil"
  avformat_suggest="libm network zlib"
  avresample_deps="avutil"
  avresample_suggest="libm"
-avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox 
corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox 
corefoundation corevideo coremedia advapi32"
  postproc_deps="avutil gpl"
  postproc_suggest="libm"
  swresample_deps="avutil"
@@ -5839,7 +5839,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int foo, 
bar = ATOMIC_VAR_INIT(-1)

  check_lib ole32"windows.h"CoTaskMemFree-lole32
  check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
-check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
+check_lib advapi32 "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
  check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi

  enabled appkit   && check_apple_framework AppKit


advapi32 contains many more things, while wincrypt refers to the name
of the crypt header specifically, so wincrypt seems a bit more correct
to me.

- Hendrik


I'm aware of this, but it seems to me either we use an approach that has 
many different check_lib statements for various API classes, even if the 
same library is used for each, or we have a single check_lib statement 
that picks a frequently used API from each library.  For example, how 
did someone arrive at CoTaskMemFree for ole32 when there are plenty of 
other APIs implemented in ole32?  The same goes for CommandLineToArgvW 
in shell32.  I could add a general advapi32 check_lib statement in 
addition to wincrypt, but the result will be the same--the addition of a 
dependency on advapi32.  Also, if the argument is, we want to make sure 
that we are using a specific version of advapi32 that supports 
CryptGenRandom, I could see that applying to a relatively new Win32 API, 
but CryptGenRandom has been around since Windows XP, and it is just as 
good as most APIs implemented in advapi32 for being the "principal" API 
associated with advapi32.  Adding a dependency on a component named 
"wincrypt", when all we want is access to the Registry APIs, I think is 
a bit misleading.


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

[FFmpeg-devel] [PATCH] avfilter/vf_tile: remove limit of max tile size

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_tile.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index 87e0b940cf..8eb0dc2097 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -23,6 +23,7 @@
  * tile video filter
  */
 
+#include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "avfilter.h"
@@ -44,8 +45,6 @@ typedef struct TileContext {
 uint8_t rgba_color[4];
 } TileContext;
 
-#define REASONABLE_SIZE 1024
-
 #define OFFSET(x) offsetof(TileContext, x)
 #define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
 
@@ -68,12 +67,21 @@ static av_cold int init(AVFilterContext *ctx)
 {
 TileContext *tile = ctx->priv;
 
-if (tile->w > REASONABLE_SIZE || tile->h > REASONABLE_SIZE) {
+if (tile->w > UINT32_MAX / tile->h) {
 av_log(ctx, AV_LOG_ERROR, "Tile size %ux%u is insane.\n",
tile->w, tile->h);
 return AVERROR(EINVAL);
 }
 
+if (tile->padding) {
+if ((tile->w - 1 > (UINT32_MAX - 2 * tile->margin) / tile->padding) ||
+(tile->h - 1 > (UINT32_MAX - 2 * tile->margin) / tile->padding)) {
+av_log(ctx, AV_LOG_ERROR, "Combination of Tile size %ux%u, padding 
%d and margin %d overflows.\n",
+   tile->w, tile->h, tile->padding, tile->margin);
+return AVERROR(EINVAL);
+}
+}
+
 if (tile->nb_frames == 0) {
 tile->nb_frames = tile->w * tile->h;
 } else if (tile->nb_frames > tile->w * tile->h) {
@@ -116,7 +124,7 @@ static int config_props(AVFilterLink *outlink)
 ff_draw_init(>draw, inlink->format, 0);
 ff_draw_color(>draw, >blank, tile->rgba_color);
 
-return 0;
+return av_image_check_size2(outlink->w, outlink->h, INT64_MAX, 
inlink->format, 0, ctx);
 }
 
 static void get_current_tile_pos(AVFilterContext *ctx, unsigned *x, unsigned 
*y)
@@ -142,6 +150,7 @@ static void draw_blank_frame(AVFilterContext *ctx, AVFrame 
*out_buf)
   x0, y0, inlink->w, inlink->h);
 tile->current++;
 }
+
 static int end_last_frame(AVFilterContext *ctx)
 {
 TileContext *tile = ctx->priv;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Teresa Johnson]

It's needed for the same reason the used attribute was already added to the
"static const" variables. For those, when building with just -O2, they
could be removed by optimization since they had local (file) scope, and we
couldn't see the uses in the inline assembly (without the used attribute).
With ThinLTO we have whole program scope, so even though they are
non-static and have global scope we can do dead code elimination on them if
we don't see that they are used.

Teresa

On Tue, Oct 31, 2017 at 4:19 PM, Michael Niedermayer  wrote:

> On Tue, Oct 31, 2017 at 03:52:14PM +, Thomas Köppe wrote:
> > +Teresa, who drafted the patch initially.
> >
> > On 31 October 2017 at 15:38, Michael Niedermayer  >
> > wrote:
> >
> > > On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
> > > > Variables used in inline assembly need to be marked with
> > > attribute((used)).
> > >
> > > This should not be the case.
> > > Variables referenced through in/out operands should not need that.
> > > Only ones accessed directly bypassing operands should need this
> > >
> >
> > I've added Teresa to the thread, who initially analyzed the problem. (For
> > background on ThinLTO, see here cppcon talk:
> > https://www.youtube.com/watch?v=p9nH2vZ2mNo.)
> >
> > [...]
> > > > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned
> (n)))
> > > v
> > > > +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__
> > > ((aligned (n))) v
> > >
> > > which variables actually are affected/ need this ?
> > >
> >
> > Without this annotation, and when compiling and linking with ThinLTO, I
> get
> > an undefined reference to "ff_h264_cabac_tables", and also to
> > "ff_pw_96", "ff_pw_53",
> > "ff_pw_42", "ff_w" and many more.
>
> i guess these are all accessed directly, like through MANGLE()
>
>
> >
> >
> > > Marking all aligned variables as used makes it harder to spot unused
> > > variables leading to accumulation of cruft
> > >
> >
> > I see. Maybe we can annotate only the affected variables more granularly?
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>



-- 
Teresa Johnson |  Software Engineer |  tejohn...@google.com |  408-460-2413
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dca: return standard error codes in avpriv_dca_parse_core_frame_header()

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 12:47:06AM -0300, James Almer wrote:
> This prevents making the DCAParseError enum part of the ABI.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/dca.c | 11 ---
>  libavcodec/dca.h | 12 ++--
>  2 files changed, 18 insertions(+), 5 deletions(-)

this changes fate

Test dca-xll_51_16_192_768_1 failed. Look at 
tests/data/fate/dca-xll_51_16_192_768_1.err for details.
make: *** [fate-dca-xll_51_16_192_768_1] Error 1
--- ./tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 2017-10-31 
19:40:15.168912721 +0100
+++ tests/data/fate/dca-xll_51_16_192_768_1-dmix_2  2017-10-31 
20:11:48.964935305 +0100
@@ -12,5 +12,5 @@
 0,   2048,   2048, 2048, 8192, c8ca1cff44674809d464ec39cf1bd1e9
 0,   4096,   4096, 2048, 8192, d67d26915ca86554568aac685c9a6dc3
 0,   6144,   6144, 2048, 8192, 8fdf69fdac9985ac4f9470a7b8e8529d
-0,   8192,   8192, 2048, 8192, dc8a9ca39b38c98147f2308f985ff648
-0,  10240,  10240, 2048, 8192, ea13b97373762ab16d0f664013fdc962
+0,   8191,   8191, 2048, 8192, dc8a9ca39b38c98147f2308f985ff648
+0,  10239,  10239, 2048, 8192, ea13b97373762ab16d0f664013fdc96

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

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


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

[FFmpeg-devel] Support for h264/SVC over RTP and SVC base layer decoding in h264

[Breeden, Joshua]

Hello,

First patch submission... hopefully I do all of this correctly.?

Added basic support for H264 Annex G (Scalable Video Coding) to RTP module. 
Implement splitting of PACSI NAL units (type 30).

Used existing H264 SPS decoder to parse Subset SPS NAL units (type 15) in h264 
extradata.

As a result, FFmpeg can now parse SVC over RTP. The video? base layer, which is 
AVC compatible, can be decoded.


Signed-off-by: Joshua Breeden 



Joshua Breeden

Software Engineer-Developer

SPACE AND INTELLIGENCE SYSTEMS / HARRIS CORPORATION

Office: +1-757-483-0226 x1008

From e275d21b5e00896bbcfa5383cde368789c71b041 Mon Sep 17 00:00:00 2001
From: Joshua Breeden 
Date: Tue, 31 Oct 2017 13:24:23 -0400
Subject: [PATCH 1/2] Parse NAL type 15 (subset SPS) in h264 extradata

---
 libavcodec/h264.h   | 1 +
 libavcodec/h264_parse.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 650580bf3a..cffcda7d92 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -41,6 +41,7 @@ enum {
 H264_NAL_END_STREAM  = 11,
 H264_NAL_FILLER_DATA = 12,
 H264_NAL_SPS_EXT = 13,
+H264_NAL_SUBSET_SPS  = 15,
 H264_NAL_AUXILIARY_SLICE = 19,
 };
 
diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index a7c71d9bbb..71c78684a7 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -372,6 +372,12 @@ static int decode_extradata_ps(const uint8_t *data, int size, H264ParamSets *ps,
 if (ret < 0)
 goto fail;
 break;
+case H264_NAL_SUBSET_SPS:
+ret = ff_h264_decode_seq_parameter_set(>gb, logctx, ps, 0);
+
+if (ret < 0)
+goto fail;
+break;
 default:
 av_log(logctx, AV_LOG_VERBOSE, "Ignoring NAL type %d in extradata\n",
nal->type);
-- 
2.11.0

From a9b89e1568b164031506164c2efd5533be93a56e Mon Sep 17 00:00:00 2001
From: Joshua Breeden 
Date: Tue, 31 Oct 2017 13:26:02 -0400
Subject: [PATCH 2/2] Add support for non-interleaved h264/SVC over RTP

---
 libavformat/rtpdec.c |  1 +
 libavformat/rtpdec_formats.h |  1 +
 libavformat/rtpdec_h264.c| 80 +++-
 3 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 4acb1ca629..1c5814749a 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -96,6 +96,7 @@ void ff_register_rtp_dynamic_payload_handlers(void)
 ff_register_dynamic_payload_handler(_h263_2000_dynamic_handler);
 ff_register_dynamic_payload_handler(_h263_rfc2190_dynamic_handler);
 ff_register_dynamic_payload_handler(_h264_dynamic_handler);
+ff_register_dynamic_payload_handler(_h264_svc_dynamic_handler);
 ff_register_dynamic_payload_handler(_hevc_dynamic_handler);
 ff_register_dynamic_payload_handler(_ilbc_dynamic_handler);
 ff_register_dynamic_payload_handler(_jpeg_dynamic_handler);
diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h
index a436c9d62c..b67d1e338f 100644
--- a/libavformat/rtpdec_formats.h
+++ b/libavformat/rtpdec_formats.h
@@ -64,6 +64,7 @@ extern RTPDynamicProtocolHandler ff_h263_1998_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_h263_2000_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_h263_rfc2190_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_h264_dynamic_handler;
+extern RTPDynamicProtocolHandler ff_h264_svc_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_hevc_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_ilbc_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_jpeg_dynamic_handler;
diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index 6f8148ab6d..4c3f52be05 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -308,6 +308,69 @@ static int h264_handle_packet_fu_a(AVFormatContext *ctx, PayloadContext *data, A
 return ff_h264_handle_frag_packet(pkt, buf, len, start_bit, , 1);
 }
 
+static int h264_handle_packet_pacsi(AVFormatContext *ctx, PayloadContext *data, AVPacket *pkt,
+const uint8_t *buf, int len,
+int *nal_counters, int nal_mask)
+{
+uint8_t *dst   = NULL;
+const uint8_t *src = buf;
+int src_len= len;
+int total_length   = 0;
+int ret;
+int y, t;
+int opt_offset;
+
+if (len < 5)
+return AVERROR_INVALIDDATA;
+
+// skip some NAL header info
+src += 4;
+src_len -= 4;
+
+// skip optional fields if present
+y = (src[0] >> 6) & 1;
+t = (src[0] >> 5) & 1;
+// 3 bytes indicated by y, 2 bytes for t, and skip over current byte
+opt_offset = y * 3 + t * 2 + 1;
+src   += opt_offset;
+src_len   -= opt_offset;
+
+// calculate size of NALs plus start codes
+while (src_len > 2) {

Re: [FFmpeg-devel] [PATCH 1/2] configure: Rename wincrypt to advapi32 for consistency with existing uses of check_lib

[Hendrik Leppkes]

On Tue, Oct 31, 2017 at 6:50 PM, Aaron Levinson
 wrote:
> Signed-off-by: Aaron Levinson 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index ea22d692b9..572299c9d3 100755
> --- a/configure
> +++ b/configure
> @@ -3327,7 +3327,7 @@ avformat_deps="avcodec avutil"
>  avformat_suggest="libm network zlib"
>  avresample_deps="avutil"
>  avresample_suggest="libm"
> -avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi 
> videotoolbox corefoundation corevideo coremedia wincrypt"
> +avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi 
> videotoolbox corefoundation corevideo coremedia advapi32"
>  postproc_deps="avutil gpl"
>  postproc_suggest="libm"
>  swresample_deps="avutil"
> @@ -5839,7 +5839,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int foo, 
> bar = ATOMIC_VAR_INIT(-1)
>
>  check_lib ole32"windows.h"CoTaskMemFree-lole32
>  check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
> -check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
> +check_lib advapi32 "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
>  check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
>
>  enabled appkit   && check_apple_framework AppKit

advapi32 contains many more things, while wincrypt refers to the name
of the crypt header specifically, so wincrypt seems a bit more correct
to me.

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

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

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: October 31, 2017 2:06 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 
> On Tue, 31 Oct 2017, Mironov, Mikhail wrote:
> 
> [...]
> 
> >> I see some confusion. The user can call send_frame/receive_packet in
> >> any order, and you can implement send_frame and receive_packet any
> >> way you want, the only thing you have to guarantee is that you cannot
> >> return EAGAIN for both send_frame and receive_packet. Not even
> temporarily.
> >>
> >> If you returned EAGAIN in send_frame, you must return success or a
> >> normal error in receive_packet. If you returned EAGAIN in
> >> receive_packet, you must return success or a normal error in send_frame.
> >>
> >> By returning EAGAIN in receive_packet you make sure that the API user
> >> submits as many frames as needed to fill your pipeline.
> >>
> >> The simplest solution really seems to me what Mark proposed:
> >>
> >> send_frame:
> >>
> >> if (have_stored_frame)
> >>return EAGAIN;
> >> if (amd_send_frame() == INPUT_FULL)
> >>store_frame;
> >> return 0;
> >>
> >> receive_packet:
> >>
> >> if (have_stored_frame) {
> >>if (amd_send_frame() == OK)
> >>   unstore_frame;
> >>block_until_have_packet
> >>return packet
> >> } else {
> >>return EAGAIN
> >> }
> >>
> >> I hope I did not mess it up, proper draining and error handling
> >> obviously needs some minor changes.
> >>
> >
> > The logic in receive_packet() will be slightly different but I will figure 
> > this
> out.
> > My only note is that returning EAGAIN from send_frame() will not work
> > with current ffmpeg calling code.
> > I was assured that this will never happen but I don’t like possibility
> > of the failure.  What the calling code supposed to do getting EAGAIN
> > from send_frame()? Resubmit? If so it would not work with the logic
> > described.
> > Anyway, lets try Mark's suggestion and see if alternations are needed.
> 
> ffmpeg.c is written in a way that it calls receive_packet repeatedly until it 
> gets
> EAGAIN. Due to the API requirements I mentioned (send_frame and
> receive_packet both cannot return EAGAIN), it is OK to not handle EAGAIN
> for send_frame in ffmpeg.c code.
> 
> Other applications might use other logic (e.g. call send_frame repeatedly,
> and then call receive_packet once, or call send_frame and receive packet
> alternating), in these cases the user application must be able to handle
> EAGAIN for send_frame, and resubmit the frame next time.
> 
> But if ffmpeg.c gets an EAGAIN in send_frame, that means a bug in the
> encoder because the encoder is breaking the API and it needs to be fixed.

Yes, this is exactly how I understand it and hopefully implemented it.
 
> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] configure, fftools/Makefile: Copy .pdb files to bindir for MSVC builds for make install

[Aaron Levinson]

When ffmpeg is built using MSVC, symbols are stored separately from
executables and libraries in .pdb files.  However, unlike with
gcc-based builds, when make install is invoked, symbols, in the form
of .pdb files, which are important for debugging, are not copied to
bindir.  This change corrects this deficiency for MSVC builds.  Files
are also uninstalled appropriately when make uninstall is exercised.

Note: General idea for how to properly handle the copying of PDB files
associated with programs suggested by Hendrik Leppkes.

Comments:

-- configure:
a) Leverage already existing SLIB_INSTALL_EXTRA_SHLIB facility (which
   is already pretty specific to Windows) to add .pdb files, in
   addition to .lib files, for shared libraries to bindir during make
   install.
b) Add PROG_INSTALL_EXTRA_BIN variable for MSVC builds and also add it
   to the section that causes it to be added to config.mak.  This is
   used in Makefile to copy any additional files associated with
   programs.  For MSVC, it is used to copy the pdb files associated
   with any executables that are built.  Note that such executables
   are build with _g in the file name and are later copied to a
   filename without _g in the file name.  As such, the PDB files have
   _g in the file name.

-- fftools/Makefile: Enhance install-progs and uninstall-progs targets
   to handle PROG_INSTALL_EXTRA_BIN if defined.  It uses a similar
   procedure as already in place for SLIB_INSTALL_EXTRA_SHLIB in
   library.mak.

Signed-off-by: Aaron Levinson 
---
 configure| 4 +++-
 fftools/Makefile | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 2ac6fed98a..feb86b2069 100755
--- a/configure
+++ b/configure
@@ -5101,9 +5101,10 @@ case $target_os in
 SLIB_CREATE_DEF_CMD='$(SRC_PATH)/compat/windows/makedef 
$(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
 SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
 SLIB_INSTALL_LINKS=
-SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
+SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib) 
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.pdb)'
 SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
 SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) 
-implib:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
+PROG_INSTALL_EXTRA_BIN='$(AVPROGS-yes:%=%$(PROGSSUF)_g.pdb)'
 enabled x86_64 && objformat="win64" || objformat="win32"
 ranlib=:
 enable dos_paths
@@ -7034,6 +7035,7 @@ SLIB_INSTALL_NAME=${SLIB_INSTALL_NAME}
 SLIB_INSTALL_LINKS=${SLIB_INSTALL_LINKS}
 SLIB_INSTALL_EXTRA_LIB=${SLIB_INSTALL_EXTRA_LIB}
 SLIB_INSTALL_EXTRA_SHLIB=${SLIB_INSTALL_EXTRA_SHLIB}
+PROG_INSTALL_EXTRA_BIN=${PROG_INSTALL_EXTRA_BIN}
 VERSION_SCRIPT_POSTPROCESS_CMD=${VERSION_SCRIPT_POSTPROCESS_CMD}
 SAMPLES:=${samples:-\$(FATE_SAMPLES)}
 NOREDZONE_FLAGS=$noredzone_flags
diff --git a/fftools/Makefile b/fftools/Makefile
index c867814a71..8c121b9762 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -47,11 +47,13 @@ install-progs-$(CONFIG_SHARED): install-libs
 install-progs: install-progs-yes $(AVPROGS)
$(Q)mkdir -p "$(BINDIR)"
$(INSTALL) -c -m 755 $(AVPROGS) "$(BINDIR)"
+   $(if $(PROG_INSTALL_EXTRA_BIN), $(INSTALL) -m 644 
$(PROG_INSTALL_EXTRA_BIN) "$(BINDIR)")
 
 uninstall: uninstall-progs
 
 uninstall-progs:
$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
+   $(if $(PROG_INSTALL_EXTRA_BIN), $(RM) $(addprefix "$(BINDIR)/", 
$(PROG_INSTALL_EXTRA_BIN)))
 
 clean::
$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
-- 
2.12.2.windows.2

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

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

[Marton Balint]

On Tue, 31 Oct 2017, Mironov, Mikhail wrote:

[...]


I see some confusion. The user can call send_frame/receive_packet in any
order, and you can implement send_frame and receive_packet any way you
want, the only thing you have to guarantee is that you cannot return EAGAIN
for both send_frame and receive_packet. Not even temporarily.

If you returned EAGAIN in send_frame, you must return success or a normal
error in receive_packet. If you returned EAGAIN in receive_packet, you must
return success or a normal error in send_frame.

By returning EAGAIN in receive_packet you make sure that the API user
submits as many frames as needed to fill your pipeline.

The simplest solution really seems to me what Mark proposed:

send_frame:

if (have_stored_frame)
   return EAGAIN;
if (amd_send_frame() == INPUT_FULL)
   store_frame;
return 0;

receive_packet:

if (have_stored_frame) {
   if (amd_send_frame() == OK)
  unstore_frame;
   block_until_have_packet
   return packet
} else {
   return EAGAIN
}

I hope I did not mess it up, proper draining and error handling obviously
needs some minor changes.



The logic in receive_packet() will be slightly different but I will figure this 
out.
My only note is that returning EAGAIN from send_frame() will not work with
current ffmpeg calling code.
I was assured that this will never happen but I
don’t like possibility of the failure.  What the calling code supposed to do
getting EAGAIN from send_frame()? Resubmit? If so it would not work with
the logic described.
Anyway, lets try Mark's suggestion and see if alternations are needed.


ffmpeg.c is written in a way that it calls receive_packet repeatedly until 
it gets EAGAIN. Due to the API requirements I mentioned (send_frame and 
receive_packet both cannot return EAGAIN), it is OK to not handle EAGAIN 
for send_frame in ffmpeg.c code.


Other applications might use other logic (e.g. call send_frame repeatedly, 
and then call receive_packet once, or call send_frame and receive packet 
alternating), in these cases the user application must be able to handle 
EAGAIN for send_frame, and resubmit the frame next time.


But if ffmpeg.c gets an EAGAIN in send_frame, that means a bug in the 
encoder because the encoder is breaking the API and it needs to be fixed.


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

[FFmpeg-devel] [PATCH] avformat/mux: be less strict with bitstream filter failures

[James Almer]

This makes the autobsf feature behave the same as the manual
bitstream filtering in ffmpeg.c

Fixes ticket #6794

Signed-off-by: James Almer 
---
 libavformat/mux.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 77e03ee5ba..1445e7dcd6 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -876,7 +876,9 @@ static int do_packet_auto_bsf(AVFormatContext *s, AVPacket 
*pkt) {
 av_log(ctx, AV_LOG_ERROR,
 "Failed to send packet to filter %s for stream %d\n",
 ctx->filter->name, pkt->stream_index);
-return ret;
+if (s->error_recognition & AV_EF_EXPLODE)
+return ret;
+return 0;
 }
 }
 return 1;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] configure: Fix backup libmfx MSVC build by adding advapi32 library dependency

[Aaron Levinson]

Signed-off-by: Aaron Levinson 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 572299c9d3..2ac6fed98a 100755
--- a/configure
+++ b/configure
@@ -5994,7 +5994,7 @@ enabled libkvazaar&& require_pkg_config 
libkvazaar "kvazaar >= 0.8.1" kv
 # pkg-config support.  Instead, users should make sure that the build
 # can find the libraries and headers through other means.
 enabled libmfx&& { use_pkg_config libmfx libmfx "mfx/mfxvideo.h" 
MFXInit ||
-   { require libmfx "mfx/mfxvideo.h" MFXInit 
-llibmfx && warn "using libmfx without pkg-config"; } }
+   { require libmfx "mfx/mfxvideo.h" MFXInit 
"-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
 enabled libmodplug&& require_pkg_config libmodplug libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame
 enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa 
$zlib_extralibs
-- 
2.12.2.windows.2

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

[FFmpeg-devel] [PATCH 1/2] configure: Rename wincrypt to advapi32 for consistency with existing uses of check_lib

[Aaron Levinson]

Signed-off-by: Aaron Levinson 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index ea22d692b9..572299c9d3 100755
--- a/configure
+++ b/configure
@@ -3327,7 +3327,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia advapi32"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -5839,7 +5839,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int foo, 
bar = ATOMIC_VAR_INIT(-1)
 
 check_lib ole32"windows.h"CoTaskMemFree-lole32
 check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
-check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
+check_lib advapi32 "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
 enabled appkit   && check_apple_framework AppKit
-- 
2.12.2.windows.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni vt and hv mc msa functions

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 07:00:08AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi hz and hv mc msa functions

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 07:00:03AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted copy, hz and vt mc msa functions

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 06:59:57AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma avg hv mc msa functions

[Michael Niedermayer]

On Mon, Oct 30, 2017 at 11:36:41AM +, Manojkumar Bhosale wrote:
> LGTM

applied

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 22, 11, 31, 13 and 33 msa functions

[Michael Niedermayer]

On Mon, Oct 30, 2017 at 11:36:34AM +, Manojkumar Bhosale wrote:
> LGTM

applied

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

On Mon, Oct 30, 2017 at 8:07 PM, Michael Niedermayer
 wrote:
> On Mon, Oct 30, 2017 at 02:14:35PM +0700, Muhammad Faiz wrote:
>> On Tue, Oct 24, 2017 at 4:31 PM, Muhammad Faiz  wrote:
>> > Fix tsan warnings.
>> >
>> > Signed-off-by: Muhammad Faiz 
>> > ---
>> >  libavutil/crc.c | 49 +
>> >  1 file changed, 29 insertions(+), 20 deletions(-)
>>
>> Ping.
>
> I assume james patch is faster than both ?
>
> If this code is never run in speed relevant loops then your solution is
> better. Otherwise i think james patch is better

I guess the common usage is to call av_crc() which is far more
computationally intensive after calling av_crc_get_table().
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 2/2 ] avformat/mpegts: opus demuxing for mapping family 255

[Michael Niedermayer]

On Sun, Oct 29, 2017 at 11:11:43PM +0100, pkv.stream wrote:
> minor change, adding a test for number of channels for
> mapping_family 1 when channel_config_code is > 0x82
> Passes fate + patcheck.
> Regards
> pkv

>  mpegts.c |   84 
> ---
>  1 file changed, 70 insertions(+), 14 deletions(-)
> 6648bab53735f1efaf0d6cd698dbc2398b483c3f  
> 0002-libavf-mpegts-opus-demuxing-for-mapping-family-255.patch
> From 2e0504728b81e0f35ba856c24cff14fa70680d8b Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Sun, 29 Oct 2017 22:57:25 +0100
> Subject: [PATCH 2/2] libavf/mpegts: opus demuxing for mapping family 255
> 
> Adds to mpegts muxer the capability  to demux libopus with mapping
> family 255, following the provisional spec for opus in mepg-ts
> (https://people.xiph.org/~tterribe/opus/ETSI_TS_opus-v0.1.3-draft.doc).
> 
> Signed-off-by: pkviet 
> ---
>  libavformat/mpegts.c | 84 
> +++-
>  1 file changed, 70 insertions(+), 14 deletions(-)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 53cbcfb..3aa06f0 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -37,6 +37,7 @@
>  #include "avio_internal.h"
>  #include "mpeg.h"
>  #include "isom.h"
> +#include "math.h"
>  
>  /* maximum size in which we look for synchronization if
>   * synchronization is lost */
> @@ -1633,7 +1634,7 @@ static const uint8_t opus_stream_cnt[9] = {
>  1, 1, 1, 2, 2, 3, 4, 4, 5,
>  };
>  
> -static const uint8_t opus_channel_map[8][8] = {
> +static const uint8_t opus_channel_map_a[8][8] = {
>  { 0 },
>  { 0,1 },
>  { 0,2,1 },
> @@ -1644,13 +1645,25 @@ static const uint8_t opus_channel_map[8][8] = {
>  { 0,6,1,2,3,4,5,7 },
>  };
>  
> +static const uint8_t opus_channel_map_b[8][8] = {
> +{ 0 },
> +{ 0,1 },
> +{ 0,1,2 },
> +{ 0,1,2,3 },
> +{ 0,1,2,3,4 },
> +{ 0,1,2,3,4,5 },
> +{ 0,1,2,3,4,5,6 },
> +{ 0,1,2,3,4,5,6,7 },
> +};
> +
>  int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int 
> stream_type,
>const uint8_t **pp, const uint8_t 
> *desc_list_end,
>Mp4Descr *mp4_descr, int mp4_descr_count, int 
> pid,
>MpegTSContext *ts)
>  {
>  const uint8_t *desc_end;
> -int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
> channel_config_code;
> +int desc_len, desc_tag, desc_es_id, ext_desc_tag, channels, 
> channel_config_code, channel_count, mapping_family, stream_count, 
> coupled_stream_count;
> +GetBitContext gb;
>  char language[252];
>  int i;
>  
> @@ -1660,6 +1673,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  desc_len = get8(pp, desc_list_end);
>  if (desc_len < 0)
>  return AVERROR_INVALIDDATA;
> +
>  desc_end = *pp + desc_len;
>  if (desc_end > desc_list_end)
>  return AVERROR_INVALIDDATA;
> @@ -1871,26 +1885,68 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  if (st->codecpar->codec_id == AV_CODEC_ID_OPUS &&
>  ext_desc_tag == 0x80) { /* User defined (provisional Opus) */
>  if (!st->codecpar->extradata) {
> -st->codecpar->extradata = 
> av_mallocz(sizeof(opus_default_extradata) +
> - 
> AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!st->codecpar->extradata)
> -return AVERROR(ENOMEM);
> -
> -st->codecpar->extradata_size = 
> sizeof(opus_default_extradata);
> -memcpy(st->codecpar->extradata, opus_default_extradata, 
> sizeof(opus_default_extradata));
> -
>  channel_config_code = get8(pp, desc_end);
>  if (channel_config_code < 0)
>  return AVERROR_INVALIDDATA;
> +
> +if (channel_config_code != 0x81) {
> +st->codecpar->extradata = 
> av_mallocz(sizeof(opus_default_extradata) +
> +AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!st->codecpar->extradata)
> +return AVERROR(ENOMEM);
> +st->codecpar->extradata_size = 
> sizeof(opus_default_extradata);
> +memcpy(st->codecpar->extradata, opus_default_extradata, 
> sizeof(opus_default_extradata));
> +}
> +
>  if (channel_config_code <= 0x8) {
>  st->codecpar->extradata[9]  = channels = 
> channel_config_code ? channel_config_code : 2;
>  st->codecpar->extradata[18] = channel_config_code ? 
> (channels > 2) : /* Dual Mono */ 255;
>  st->codecpar->extradata[19] = 
> opus_stream_cnt[channel_config_code];
>  st->codecpar->extradata[20] = 
> 

Re: [FFmpeg-devel] On in-tree external headers

[Mark Thompson]

On 31/10/17 16:34, Timo Rothenpieler wrote:
> Removing the nvenc/cuvid headers from the tree would imply the following 
> procedure for anyone wanting to build ffmpeg with nvenc/cuvid:
> 
> Register with nvidia to get access to their Video SDK Downloads.
> Extract the headers from their massive SDK.
> Patch them so that ffmpeg can make use of them. The vanilla headers are not 
> useful for ffmpeg, as they are not in a format that can be easily included. 
> All the headers in the tree are slightly modified to avoid some 
> type-collision, extend compatibility(for example with Cygwin) and for the 
> dynamic loading we do.
> 
> Putting that state of headers into an external repository that someone 
> maintains seems like a giant and confusing mess for every user and 
> distributor. And I don't see any benefit in doing that.
> 
> The headers are MIT licensed, so there is no license issue to be found here. 
> They don't cause any issues on any platform where they are used by default.
> 
> I also do not see any problem with including the new single-header AMD 
> encoder, it makes everyone's life easier and avoid confusing proxy libraries.
> 
> We're not bundling entire 3rd party libs in-tree here, just API headers for 
> system/driver APIs.

What exactly would the policy be, then?

"External headers for a system/driver API may be included in tree if it makes 
building with support for this feature easier for users" would cover pretty 
much everything.

I'm definitely against a free-for-all where libmfx, V4L2, etc. all get included.

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

Re: [FFmpeg-devel] [PATCH]lavf/latmenc: Error out for invalid codecs

[Michael Niedermayer]

On Mon, Oct 30, 2017 at 11:51:30PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch makes sure the loas muxer does not try to write
> anything but aac and latm.
> 
> Please comment, Carl Eugen

>  latmenc.c |4 
>  1 file changed, 4 insertions(+)
> 2b64f3d5ecb189e77b85dbab7a6cbfe9657701f2  
> 0001-lavf-latmenc-Error-out-for-invalid-codecs.patch
> From 9f8f39b402f77b53613a395129f96feee5e873ba Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 30 Oct 2017 23:49:29 +0100
> Subject: [PATCH] lavf/latmenc: Error out for invalid codecs.

isnt AV_CODEC_ID_MP4ALS supported too ? (i see ALS related code in
latmenc.c)

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] On in-tree external headers

[Timo Rothenpieler]

Removing the nvenc/cuvid headers from the tree would imply the following 
procedure for anyone wanting to build ffmpeg with nvenc/cuvid:


Register with nvidia to get access to their Video SDK Downloads.
Extract the headers from their massive SDK.
Patch them so that ffmpeg can make use of them. The vanilla headers are 
not useful for ffmpeg, as they are not in a format that can be easily 
included. All the headers in the tree are slightly modified to avoid 
some type-collision, extend compatibility(for example with Cygwin) and 
for the dynamic loading we do.


Putting that state of headers into an external repository that someone 
maintains seems like a giant and confusing mess for every user and 
distributor. And I don't see any benefit in doing that.


The headers are MIT licensed, so there is no license issue to be found 
here. They don't cause any issues on any platform where they are used by 
default.


I also do not see any problem with including the new single-header AMD 
encoder, it makes everyone's life easier and avoid confusing proxy 
libraries.


We're not bundling entire 3rd party libs in-tree here, just API headers 
for system/driver APIs.




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

Re: [FFmpeg-devel] [RFC]lswr/rematrix: Support s32p

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 12:40:24AM +0100, Carl Eugen Hoyos wrote:
> 2017-10-30 9:47 GMT+01:00 Muhammad Faiz :
> > On Sun, Oct 29, 2017 at 3:55 AM, Carl Eugen Hoyos  
> > wrote:
> >> Hi!
> >>
> >> Attached patch fixes a random testcase for ticket #6785 here but I
> >> don't know if this is the correct fix.
> >>
> >> Please review, Carl Eugen
> >>
> >> From a93b9309d74f5eadece371ee1e682d266af6cd83 Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Sat, 28 Oct 2017 22:52:02 +0200
> >> Subject: [PATCH] lswr/rematrix: Support s32p.
> >>
> >> Fixes ticket #6785.
> >> ---
> >>  libswresample/rematrix.c |   21 +++--
> >>  1 file changed, 15 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> >> index 66a43c1..a6aa6b0 100644
> >> --- a/libswresample/rematrix.c
> >> +++ b/libswresample/rematrix.c
> >> @@ -445,14 +445,23 @@ av_cold int swri_rematrix_init(SwrContext *s){
> >>  s->mix_2_1_f = (mix_2_1_func_type*)sum2_double;
> >>  s->mix_any_f = (mix_any_func_type*)get_mix_any_func_double(s);
> >>  }else if(s->midbuf.fmt == AV_SAMPLE_FMT_S32P){
> >> -// Only for dithering currently
> >> -// s->native_matrix = av_calloc(nb_in * nb_out, sizeof(double));
> >> -s->native_one= av_mallocz(sizeof(int));
> >> +s->native_one= av_mallocz(sizeof(int64_t));
> >>  if (!s->native_one)
> >>  return AVERROR(ENOMEM);
> >> -// for (i = 0; i < nb_out; i++)
> >> -// for (j = 0; j < nb_in; j++)
> >> -// ((double*)s->native_matrix)[i * nb_in + j] = 
> >> s->matrix[i][j];
> >> +s->native_matrix = av_calloc(nb_in * nb_out, sizeof(int));
> >> +if (!s->native_matrix) {
> >> +av_freep(>native_one);
> >> +return AVERROR(ENOMEM);
> >> +}
> >> +for (i = 0; i < nb_out; i++) {
> >> +double rem = 0;
> >> +
> >> +for (j = 0; j < nb_in; j++) {
> >> +double target = s->matrix[i][j] * 32768 + rem;
> >> +((int*)s->native_matrix)[i * nb_in + j] = lrintf(target);
> >> +rem += target - ((int64_t*)s->native_matrix)[i * nb_in + 
> >> j];
> >> +}
> >> +}
> >>  *((int*)s->native_one) = 32768;
> >>  s->mix_1_1_f = (mix_1_1_func_type*)copy_s32;
> >>  s->mix_2_1_f = (mix_2_1_func_type*)sum2_s32;
> >
> > The code is confusing.
> > Which is the type of native_matrix and native_one? int or int64_t?
> 
> New patch attached.
> 
> Please review, Carl Eugen

>  rematrix.c |   21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 9f50e61370cc72de000bb1174cbd8666388fdd9a  0001-lswr-Support-s32p.patch
> From a93b9309d74f5eadece371ee1e682d266af6cd83 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 28 Oct 2017 22:52:02 +0200
> Subject: [PATCH] lswr/rematrix: Support s32p.
> 
> Fixes ticket #6785.
> ---
>  libswresample/rematrix.c |   21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)

should be ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 03:52:14PM +, Thomas Köppe wrote:
> +Teresa, who drafted the patch initially.
> 
> On 31 October 2017 at 15:38, Michael Niedermayer 
> wrote:
> 
> > On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
> > > Variables used in inline assembly need to be marked with
> > attribute((used)).
> >
> > This should not be the case.
> > Variables referenced through in/out operands should not need that.
> > Only ones accessed directly bypassing operands should need this
> >
> 
> I've added Teresa to the thread, who initially analyzed the problem. (For
> background on ThinLTO, see here cppcon talk:
> https://www.youtube.com/watch?v=p9nH2vZ2mNo.)
> 
> [...]
> > > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n)))
> > v
> > > +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__
> > ((aligned (n))) v
> >
> > which variables actually are affected/ need this ?
> >
> 
> Without this annotation, and when compiling and linking with ThinLTO, I get
> an undefined reference to "ff_h264_cabac_tables", and also to
> "ff_pw_96", "ff_pw_53",
> "ff_pw_42", "ff_w" and many more.

i guess these are all accessed directly, like through MANGLE()


> 
> 
> > Marking all aligned variables as used makes it harder to spot unused
> > variables leading to accumulation of cruft
> >
> 
> I see. Maybe we can annotate only the affected variables more granularly?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size calculate.

[Mark Thompson]

On 31/10/17 16:00, Jun Zhao wrote:
> On 2017/10/31 23:45, Mark Thompson wrote:
>> On 31/10/17 15:11, Jun Zhao wrote:> On 2017/10/31 18:19, Mark Thompson wrote:
 On 31/10/17 02:37, Jun Zhao wrote:
> From 7eef9be1c8a92bf625d62a0f97f762f1342c6d78 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 31 Oct 2017 10:13:42 +0800
> Subject: [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size 
> calculate.
>
> when rc_buffer_size didn't setting, always use the max bit rate
> per second as HRD buffer size.
>
> Signed-off-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
> ---
>  libavcodec/vaapi_encode.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 590f4be4ed..d5f89ef346 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1144,19 +1144,9 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  return AVERROR(EINVAL);
>  }
>  
> -if (avctx->rc_buffer_size)
> -hrd_buffer_size = avctx->rc_buffer_size;
> -else
> -hrd_buffer_size = avctx->bit_rate;
> -if (avctx->rc_initial_buffer_occupancy)
> -hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
> -else
> -hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
> -
>  if (ctx->va_rc_mode == VA_RC_CBR) {
>  rc_bits_per_second   = avctx->bit_rate;
>  rc_target_percentage = 100;
> -rc_window_size   = 1000;
>  } else {
>  if (avctx->rc_max_rate < avctx->bit_rate) {
>  // Max rate is unset or invalid, just use the normal bitrate.
> @@ -1166,8 +1156,17 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  rc_bits_per_second   = avctx->rc_max_rate;
>  rc_target_percentage = (avctx->bit_rate * 100) / 
> rc_bits_per_second;
>  }
> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
>  }
> +rc_window_size = (rc_bits_per_second * 1000) / avctx->bit_rate;
> +
> +if (avctx->rc_buffer_size)
> +hrd_buffer_size = avctx->rc_buffer_size;
> +else
> +hrd_buffer_size = rc_bits_per_second;
> +if (avctx->rc_initial_buffer_occupancy)
> +hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
> +else
> +hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>  
>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
>  ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
> -- 
> 2.14.1
>
 Why?  If the RC buffer size is unset it currently guesses one second of 
 the target bitrate - in what way is the peak bitrate any more appropriate 
 as a guess?
>>> In VBR mode, when rc_max_rate more than bit_rate, I think HDR size need
>>> to use rc_max_rate, not the bit_rate.
>> Ok, why do you think that?  I'm not necessarily against this change (in 
>> cases where it matters the user will provide rc_buffer_size explicitly), but 
>> please provide some reasoning for it.
> I think the code logic have considered the explicit rc_buffer_size
> setting, and this patch
> correct the HRD buffer size with MAX(rc_max_rate, bit_rate) when no
> setting rc_buffer_size in
> VBR mode.

I agree that this is what your patch does.

>   In the old logic, in VBR mode, if user don't setting
> rc_buffer_size
> explicitly, the HRD buffer size always use avctx->bit_rate, it does not
> make sense.
Why not?

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: remove limit of max tile size

[Nicolas George]

Nack.

Le septidi 7 brumaire, an CCXXVI, Paul B Mahol a écrit :
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_tile.c | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
> index 87e0b940cf..5752ca080e 100644
> --- a/libavfilter/vf_tile.c
> +++ b/libavfilter/vf_tile.c
> @@ -23,6 +23,7 @@
>   * tile video filter
>   */
>  
> +#include "libavutil/imgutils.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/pixdesc.h"
>  #include "avfilter.h"
> @@ -44,8 +45,6 @@ typedef struct TileContext {
>  uint8_t rgba_color[4];
>  } TileContext;
>  
> -#define REASONABLE_SIZE 1024
> -
>  #define OFFSET(x) offsetof(TileContext, x)
>  #define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>  
> @@ -68,12 +67,6 @@ static av_cold int init(AVFilterContext *ctx)
>  {
>  TileContext *tile = ctx->priv;
>  
> -if (tile->w > REASONABLE_SIZE || tile->h > REASONABLE_SIZE) {
> -av_log(ctx, AV_LOG_ERROR, "Tile size %ux%u is insane.\n",
> -   tile->w, tile->h);
> -return AVERROR(EINVAL);
> -}
> -

>  if (tile->nb_frames == 0) {
>  tile->nb_frames = tile->w * tile->h;

This multiplication still overflows. The problem is caught later because
a tile size that results in an overflow will also result in a too large
image, but this is fragile design, since the values that are being
tested has no direct relation with the value that is being invalid.

And that is not all:

const unsigned total_margin_w = (tile->w - 1) * tile->padding + 
2*tile->margin;
const unsigned total_margin_h = (tile->h - 1) * tile->padding + 
2*tile->margin;

These computations will also overflow with a large tile size. This would
result in tile happily drawing beyond the boundaries of the image. It
does not actually happens because the frame pool is inited using
av_image_check_size() rather than av_image_check_size2() and thus uses a
stride that is larger than necessary and causes the image to seem too
large. But once this is fixed, it will happen.

I will not accept bugs added just because they are hidden by other bugs.
That would be a highway to catastrophe. If you want this change to be
accepted, you need to perform all the overflow check correctly (or prove
that they are not needed), not throw random checks around in the hope
they catch problems.

>  } else if (tile->nb_frames > tile->w * tile->h) {
> @@ -116,7 +109,7 @@ static int config_props(AVFilterLink *outlink)
>  ff_draw_init(>draw, inlink->format, 0);
>  ff_draw_color(>draw, >blank, tile->rgba_color);
>  
> -return 0;
> +return av_image_check_size2(outlink->w, outlink->h, INT64_MAX, 
> inlink->format, 0, ctx);
>  }
>  
>  static void get_current_tile_pos(AVFilterContext *ctx, unsigned *x, unsigned 
> *y)
> @@ -142,6 +135,7 @@ static void draw_blank_frame(AVFilterContext *ctx, 
> AVFrame *out_buf)
>x0, y0, inlink->w, inlink->h);
>  tile->current++;
>  }
> +
>  static int end_last_frame(AVFilterContext *ctx)
>  {
>  TileContext *tile = ctx->priv;

-- 
  Nicolas George


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] lavc/vaapi_encode: correct the HRD buffer size calculate.

[Jun Zhao]

On 2017/10/31 23:45, Mark Thompson wrote:
> On 31/10/17 15:11, Jun Zhao wrote:> On 2017/10/31 18:19, Mark Thompson wrote:
>>> On 31/10/17 02:37, Jun Zhao wrote:
 From 7eef9be1c8a92bf625d62a0f97f762f1342c6d78 Mon Sep 17 00:00:00 2001
 From: Jun Zhao 
 Date: Tue, 31 Oct 2017 10:13:42 +0800
 Subject: [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size 
 calculate.

 when rc_buffer_size didn't setting, always use the max bit rate
 per second as HRD buffer size.

 Signed-off-by: Jun Zhao 
 Signed-off-by: Wang, Yi A 
 ---
  libavcodec/vaapi_encode.c | 21 ++---
  1 file changed, 10 insertions(+), 11 deletions(-)

 diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
 index 590f4be4ed..d5f89ef346 100644
 --- a/libavcodec/vaapi_encode.c
 +++ b/libavcodec/vaapi_encode.c
 @@ -1144,19 +1144,9 @@ static av_cold int 
 vaapi_encode_init_rate_control(AVCodecContext *avctx)
  return AVERROR(EINVAL);
  }
  
 -if (avctx->rc_buffer_size)
 -hrd_buffer_size = avctx->rc_buffer_size;
 -else
 -hrd_buffer_size = avctx->bit_rate;
 -if (avctx->rc_initial_buffer_occupancy)
 -hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
 -else
 -hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
 -
  if (ctx->va_rc_mode == VA_RC_CBR) {
  rc_bits_per_second   = avctx->bit_rate;
  rc_target_percentage = 100;
 -rc_window_size   = 1000;
  } else {
  if (avctx->rc_max_rate < avctx->bit_rate) {
  // Max rate is unset or invalid, just use the normal bitrate.
 @@ -1166,8 +1156,17 @@ static av_cold int 
 vaapi_encode_init_rate_control(AVCodecContext *avctx)
  rc_bits_per_second   = avctx->rc_max_rate;
  rc_target_percentage = (avctx->bit_rate * 100) / 
 rc_bits_per_second;
  }
 -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
  }
 +rc_window_size = (rc_bits_per_second * 1000) / avctx->bit_rate;
 +
 +if (avctx->rc_buffer_size)
 +hrd_buffer_size = avctx->rc_buffer_size;
 +else
 +hrd_buffer_size = rc_bits_per_second;
 +if (avctx->rc_initial_buffer_occupancy)
 +hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
 +else
 +hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
  
  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
  ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
 -- 
 2.14.1

>>> Why?  If the RC buffer size is unset it currently guesses one second of the 
>>> target bitrate - in what way is the peak bitrate any more appropriate as a 
>>> guess?
>> In VBR mode, when rc_max_rate more than bit_rate, I think HDR size need
>> to use rc_max_rate, not the bit_rate.
> Ok, why do you think that?  I'm not necessarily against this change (in cases 
> where it matters the user will provide rc_buffer_size explicitly), but please 
> provide some reasoning for it.
I think the code logic have considered the explicit rc_buffer_size
setting, and this patch
correct the HRD buffer size with MAX(rc_max_rate, bit_rate) when no
setting rc_buffer_size in
VBR mode. In the old logic, in VBR mode, if user don't setting
rc_buffer_size
explicitly, the HRD buffer size always use avctx->bit_rate, it does not
make sense.
>
> - Mark
> ___
> 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] Fix missing used attribute for inline assembly variables

[Thomas Köppe]

+Teresa, who drafted the patch initially.

On 31 October 2017 at 15:38, Michael Niedermayer 
wrote:

> On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
> > Variables used in inline assembly need to be marked with
> attribute((used)).
>
> This should not be the case.
> Variables referenced through in/out operands should not need that.
> Only ones accessed directly bypassing operands should need this
>

I've added Teresa to the thread, who initially analyzed the problem. (For
background on ThinLTO, see here cppcon talk:
https://www.youtube.com/watch?v=p9nH2vZ2mNo.)

[...]
> > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n)))
> v
> > +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__
> ((aligned (n))) v
>
> which variables actually are affected/ need this ?
>

Without this annotation, and when compiling and linking with ThinLTO, I get
an undefined reference to "ff_h264_cabac_tables", and also to
"ff_pw_96", "ff_pw_53",
"ff_pw_42", "ff_w" and many more.


> Marking all aligned variables as used makes it harder to spot unused
> variables leading to accumulation of cruft
>

I see. Maybe we can annotate only the affected variables more granularly?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/img2enc: add frame_pts option for make output filename

[Steven Liu]

when use frame_pts option, the output image name can be set with PTS
of current frame.

Signed-off-by: Steven Liu 
---
 doc/muxers.texi   | 9 +
 libavformat/img2enc.c | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 91bbe673c5..af5349e683 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -894,9 +894,18 @@ can be used:
 ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1 
"%Y-%m-%d_%H-%M-%S.jpg"
 @end example
 
+You can set the file name with current frame's PTS:
+@example
+ffmpeg -f v4l2 -r 1 -i /dev/video0 -copyts -f image2 -frame_pts true %d.jpg"
+@end example
+
 @subsection Options
 
 @table @option
+@item frame_pts
+If set to 1, expand the filename with pts from pkt->pts.
+Default value is 0.
+
 @item start_number
 Start the sequence from the specified number. Default value is 1.
 
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index d793807b33..be87435b83 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -42,6 +42,7 @@ typedef struct VideoMuxData {
 char target[4][1024];
 int update;
 int use_strftime;
+int frame_pts;
 const char *muxer;
 int use_rename;
 } VideoMuxData;
@@ -99,6 +100,11 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 av_log(s, AV_LOG_ERROR, "Could not get frame filename with 
strftime\n");
 return AVERROR(EINVAL);
 }
+} else if (img->frame_pts) {
+if (av_get_frame_filename2(filename, sizeof(filename), img->path, 
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
+av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the 
frames.");
+return AVERROR(EINVAL);
+}
 } else if (av_get_frame_filename2(filename, sizeof(filename), 
img->path,
   img->img_number,
   AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 
0 &&
@@ -207,6 +213,7 @@ static const AVOption muxoptions[] = {
 { "update",   "continuously overwrite one file", OFFSET(update),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,   1, ENC },
 { "start_number", "set first number in the sequence", OFFSET(img_number), 
AV_OPT_TYPE_INT,  { .i64 = 1 }, 0, INT_MAX, ENC },
 { "strftime", "use strftime for filename", OFFSET(use_strftime),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
+{ "frame_pts","use current frame pts for filename", OFFSET(frame_pts), 
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { "atomic_writing", "write files atomically (using temporary files and 
renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { NULL },
 };
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size calculate.

[Mark Thompson]

On 31/10/17 15:11, Jun Zhao wrote:> On 2017/10/31 18:19, Mark Thompson wrote:
>> On 31/10/17 02:37, Jun Zhao wrote:
>>> From 7eef9be1c8a92bf625d62a0f97f762f1342c6d78 Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Tue, 31 Oct 2017 10:13:42 +0800
>>> Subject: [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size 
>>> calculate.
>>>
>>> when rc_buffer_size didn't setting, always use the max bit rate
>>> per second as HRD buffer size.
>>>
>>> Signed-off-by: Jun Zhao 
>>> Signed-off-by: Wang, Yi A 
>>> ---
>>>  libavcodec/vaapi_encode.c | 21 ++---
>>>  1 file changed, 10 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>> index 590f4be4ed..d5f89ef346 100644
>>> --- a/libavcodec/vaapi_encode.c
>>> +++ b/libavcodec/vaapi_encode.c
>>> @@ -1144,19 +1144,9 @@ static av_cold int 
>>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>>  return AVERROR(EINVAL);
>>>  }
>>>  
>>> -if (avctx->rc_buffer_size)
>>> -hrd_buffer_size = avctx->rc_buffer_size;
>>> -else
>>> -hrd_buffer_size = avctx->bit_rate;
>>> -if (avctx->rc_initial_buffer_occupancy)
>>> -hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
>>> -else
>>> -hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>>> -
>>>  if (ctx->va_rc_mode == VA_RC_CBR) {
>>>  rc_bits_per_second   = avctx->bit_rate;
>>>  rc_target_percentage = 100;
>>> -rc_window_size   = 1000;
>>>  } else {
>>>  if (avctx->rc_max_rate < avctx->bit_rate) {
>>>  // Max rate is unset or invalid, just use the normal bitrate.
>>> @@ -1166,8 +1156,17 @@ static av_cold int 
>>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>>  rc_bits_per_second   = avctx->rc_max_rate;
>>>  rc_target_percentage = (avctx->bit_rate * 100) / 
>>> rc_bits_per_second;
>>>  }
>>> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
>>>  }
>>> +rc_window_size = (rc_bits_per_second * 1000) / avctx->bit_rate;
>>> +
>>> +if (avctx->rc_buffer_size)
>>> +hrd_buffer_size = avctx->rc_buffer_size;
>>> +else
>>> +hrd_buffer_size = rc_bits_per_second;
>>> +if (avctx->rc_initial_buffer_occupancy)
>>> +hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
>>> +else
>>> +hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>>>  
>>>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
>>>  ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
>>> -- 
>>> 2.14.1
>>>
>> Why?  If the RC buffer size is unset it currently guesses one second of the 
>> target bitrate - in what way is the peak bitrate any more appropriate as a 
>> guess?
> In VBR mode, when rc_max_rate more than bit_rate, I think HDR size need
> to use rc_max_rate, not the bit_rate.

Ok, why do you think that?  I'm not necessarily against this change (in cases 
where it matters the user will provide rc_buffer_size explicitly), but please 
provide some reasoning for it.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.

[Mark Thompson]

On 31/10/17 15:18, Jun Zhao wrote:
> On 2017/10/31 18:26, Mark Thompson wrote:
>> On 31/10/17 02:37, Jun Zhao wrote:
>>> From d1e105057e93e7c2788d6d684292db9008fbf3ac Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Tue, 31 Oct 2017 10:19:08 +0800
>>> Subject: [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.
>>>
>>> As H264 Spec 2012 E.2.2, bit_rate_scale means the max input bit rate.
>>>
>>> Signed-off-by: Jun Zhao 
>>> Signed-off-by: Wang, Yi A 
>>> ---
>>>  libavcodec/vaapi_encode_h264.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>>> index 1d43e934ef..27a810c64e 100644
>>> --- a/libavcodec/vaapi_encode_h264.c
>>> +++ b/libavcodec/vaapi_encode_h264.c
>>> @@ -406,7 +406,7 @@ static int 
>>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>>  // Try to scale these to a sensible range so that the
>>>  // golomb encode of the value is not overlong.
>>>  hrd->bit_rate_scale =
>>> -av_clip_uintp2(av_log2(avctx->bit_rate) - 15 - 6, 4);
>>> +av_clip_uintp2(av_log2(FFMAX(avctx->bit_rate, 
>>> avctx->rc_max_rate)) - 15 - 6, 4);
>>>  hrd->bit_rate_value_minus1[0] =
>>>  (avctx->bit_rate >> hrd->bit_rate_scale + 6) - 1;
> 
> avctx->bit_rate will change with FFMAX(avctx->bit_rate, avctx->rc_max_rate) 
> when setting bit_rate_value_minus1.

The two values combine to specify the BitRate[0] value for this HRD instance.  
The same value has to be used for both the scale and the value parts.

>>>  
>>> -- 
>>> 2.14.1
>>>
>> Can you offer some more justification for that?  I think the change is 
>> wrong: consider under what circumstances overflow/underflow occurs.
> In VBR/CBR mode, I think max bit rate = FFMAX(bit_rate, rc_max_rate) for
> bit_rate_scale/bit_rate_value_minus1.

The bitrate here is how fast the CPB fills.  It is not the same as the RC max 
rate, which will only affect how fast the CPB can be emptied.

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

Re: [FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
> Variables used in inline assembly need to be marked with attribute((used)).

This should not be the case.
Variables referenced through in/out operands should not need that.
Only ones accessed directly bypassing operands should need this


> Static constants already were, via the define of DECLARE_ASM_CONST.
> But DECLARE_ALIGNED does not add this attribute, and some of the variables
> defined with it are const only used in inline assembly, and therefore
> appeared dead.
> ---
>  libavcodec/cabac.c | 2 +-
>  libavutil/mem.h| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> index dd2b057c6d..7321b48901 100644
> --- a/libavcodec/cabac.c
> +++ b/libavcodec/cabac.c
> @@ -32,7 +32,7 @@
>  #include "cabac.h"
>  #include "cabac_functions.h"
>  
> -const uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> +DECLARE_ALIGNED(1, const uint8_t, ff_h264_cabac_tables)[512 + 4*2*64 + 4*64 
> + 63] = {
>  9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
>  4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
>  3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index 527cd03191..c4ee11af58 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
> @@ -101,7 +101,7 @@
>  #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
> 16 v
>  #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
> ((aligned (FFMIN(n, 16 v
>  #elif defined(__GNUC__) || defined(__clang__)
> -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
> +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
> (n))) v

which variables actually are affected/ need this ?

Marking all aligned variables as used makes it harder to spot unused
variables leading to accumulation of cruft


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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.

[Jun Zhao]

On 2017/10/31 18:26, Mark Thompson wrote:
> On 31/10/17 02:37, Jun Zhao wrote:
>> From d1e105057e93e7c2788d6d684292db9008fbf3ac Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 31 Oct 2017 10:19:08 +0800
>> Subject: [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.
>>
>> As H264 Spec 2012 E.2.2, bit_rate_scale means the max input bit rate.
>>
>> Signed-off-by: Jun Zhao 
>> Signed-off-by: Wang, Yi A 
>> ---
>>  libavcodec/vaapi_encode_h264.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 1d43e934ef..27a810c64e 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -406,7 +406,7 @@ static int 
>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>  // Try to scale these to a sensible range so that the
>>  // golomb encode of the value is not overlong.
>>  hrd->bit_rate_scale =
>> -av_clip_uintp2(av_log2(avctx->bit_rate) - 15 - 6, 4);
>> +av_clip_uintp2(av_log2(FFMAX(avctx->bit_rate, 
>> avctx->rc_max_rate)) - 15 - 6, 4);
>>  hrd->bit_rate_value_minus1[0] =
>>  (avctx->bit_rate >> hrd->bit_rate_scale + 6) - 1;

avctx->bit_rate will change with FFMAX(avctx->bit_rate, avctx->rc_max_rate) 
when setting bit_rate_value_minus1.

>>  
>> -- 
>> 2.14.1
>>
> Can you offer some more justification for that?  I think the change is wrong: 
> consider under what circumstances overflow/underflow occurs.
In VBR/CBR mode, I think max bit rate = FFMAX(bit_rate, rc_max_rate) for
bit_rate_scale/bit_rate_value_minus1.
>
> - Mark
> ___
> 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 1/2] lavc/vaapi_encode: correct the HRD buffer size calculate.

[Jun Zhao]

On 2017/10/31 18:19, Mark Thompson wrote:
> On 31/10/17 02:37, Jun Zhao wrote:
>> From 7eef9be1c8a92bf625d62a0f97f762f1342c6d78 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 31 Oct 2017 10:13:42 +0800
>> Subject: [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size 
>> calculate.
>>
>> when rc_buffer_size didn't setting, always use the max bit rate
>> per second as HRD buffer size.
>>
>> Signed-off-by: Jun Zhao 
>> Signed-off-by: Wang, Yi A 
>> ---
>>  libavcodec/vaapi_encode.c | 21 ++---
>>  1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index 590f4be4ed..d5f89ef346 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -1144,19 +1144,9 @@ static av_cold int 
>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  return AVERROR(EINVAL);
>>  }
>>  
>> -if (avctx->rc_buffer_size)
>> -hrd_buffer_size = avctx->rc_buffer_size;
>> -else
>> -hrd_buffer_size = avctx->bit_rate;
>> -if (avctx->rc_initial_buffer_occupancy)
>> -hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
>> -else
>> -hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>> -
>>  if (ctx->va_rc_mode == VA_RC_CBR) {
>>  rc_bits_per_second   = avctx->bit_rate;
>>  rc_target_percentage = 100;
>> -rc_window_size   = 1000;
>>  } else {
>>  if (avctx->rc_max_rate < avctx->bit_rate) {
>>  // Max rate is unset or invalid, just use the normal bitrate.
>> @@ -1166,8 +1156,17 @@ static av_cold int 
>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  rc_bits_per_second   = avctx->rc_max_rate;
>>  rc_target_percentage = (avctx->bit_rate * 100) / 
>> rc_bits_per_second;
>>  }
>> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
>>  }
>> +rc_window_size = (rc_bits_per_second * 1000) / avctx->bit_rate;
>> +
>> +if (avctx->rc_buffer_size)
>> +hrd_buffer_size = avctx->rc_buffer_size;
>> +else
>> +hrd_buffer_size = rc_bits_per_second;
>> +if (avctx->rc_initial_buffer_occupancy)
>> +hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
>> +else
>> +hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>>  
>>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
>>  ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
>> -- 
>> 2.14.1
>>
> Why?  If the RC buffer size is unset it currently guesses one second of the 
> target bitrate - in what way is the peak bitrate any more appropriate as a 
> guess?
In VBR mode, when rc_max_rate more than bit_rate, I think HDR size need
to use rc_max_rate, not the bit_rate.
>
> - Mark
> ___
> 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> >>> +AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder,
> >> AMF_VIDEO_ENCODER_HEVC_DE_BLOCKING_FILTER_DISABLE,
> >> deblocking_filter);
> >>
> >> What about SAO?
> >
> > SAO ???
> 
> You're looking at AV_CODEC_FLAG_LOOP_FILTER to disable this, so you
> might want to consider both loop filters in H.265, not just the deblocking
> filter.
> 

At this point AMF exposes only deblocking filter.

> - Mark
> ___
> 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: October 30, 2017 9:26 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 
> 
> On Mon, 30 Oct 2017, Mironov, Mikhail wrote:
> 
> [...]
> 
>  I still think this would be much better off using the
>  send_frame()/receive_packet() API.  Even if your API doesn't expose
>  any information about the queue length, you only need to hold a
>  single input frame transiently to get around that (the user is not
>  allowed to call
>  send_frame() twice in a row without calling receive_packet()).
> 
> >>>
> >>> So to implement this I would have to:
> >>> - in the send_frame() if AMF_INPUT_FULL is returned - store input
> >>> frame (or copy?)
> >>> - In the next receive_frame() check if frame is stored
> >>> - Wait till some output is produced
> >>> - resubmit stored frame
> >>
> >> Sounds about right.
> >>
> >>> Issues I see:
> >>> - Isn't this logic defeat the purpose of independent send()/receive()?
> >>> - How can I report a error if receive() produced a compressed frame
> >>> but
> >> the delayed submission failed?
> >>
> >> Since this is asynchronous anyway, just report it at the next
> >> available opportunity.
> >>
> >>> - This logic depends on the particular logic in the calling code.
> >>
> >> The API requires this behaviour of the caller.  See the documentation
> >> in avcodec.h.
> >>
> >>> - This logic depends on the particular HW behaviour.
> >>
> >> How so?
> >>
> >>> - In the future, we would like to output individual slices of a
> >>> compressed
> >> frame.
> >>> When this added receive_frame() must be called several times to
> >>> clear
> >> space in the HW queue.
> >>> Granted, current implementation also does not cover this case but
> >>> truly independent send/receive implementation would.
> >>
> >> Note that the user is required to call receive_packet() repeatedly
> >> until it returns EAGAIN, and only then are they allowed to call
> send_frame() again.
> >
> > The implementation will be cumbersome at least. Note that calling
> > Drain() may also return AMF_INPUT_FULL and therefore will have to be
> > remembered and called again in receive(). But I will implement as you
> suggests. It is not a huge change.
> >
> 
> I see some confusion. The user can call send_frame/receive_packet in any
> order, and you can implement send_frame and receive_packet any way you
> want, the only thing you have to guarantee is that you cannot return EAGAIN
> for both send_frame and receive_packet. Not even temporarily.
> 
> If you returned EAGAIN in send_frame, you must return success or a normal
> error in receive_packet. If you returned EAGAIN in receive_packet, you must
> return success or a normal error in send_frame.
> 
> By returning EAGAIN in receive_packet you make sure that the API user
> submits as many frames as needed to fill your pipeline.
> 
> The simplest solution really seems to me what Mark proposed:
> 
> send_frame:
> 
> if (have_stored_frame)
>return EAGAIN;
> if (amd_send_frame() == INPUT_FULL)
>store_frame;
> return 0;
> 
> receive_packet:
> 
> if (have_stored_frame) {
>if (amd_send_frame() == OK)
>   unstore_frame;
>block_until_have_packet
>return packet
> } else {
>return EAGAIN
> }
> 
> I hope I did not mess it up, proper draining and error handling obviously
> needs some minor changes.
> 

The logic in receive_packet() will be slightly different but I will figure this 
out. 
My only note is that returning EAGAIN from send_frame() will not work with 
current ffmpeg calling code. I was assured that this will never happen but I
 don’t like possibility of the failure.  What the calling code supposed to do 
getting EAGAIN from send_frame()? Resubmit? If so it would not work with 
the logic described.
Anyway, lets try Mark's suggestion and see if alternations are needed.

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

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

[FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted hv mc msa functions

[kaustubh.raste]

From: Kaustubh Raste 

Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_macros_msa.h  |9 +
 libavcodec/mips/hevc_mc_uniw_msa.c | 1598 +---
 2 files changed, 965 insertions(+), 642 deletions(-)

diff --git a/libavcodec/mips/hevc_macros_msa.h 
b/libavcodec/mips/hevc_macros_msa.h
index 7dcfea0..27c69ff 100644
--- a/libavcodec/mips/hevc_macros_msa.h
+++ b/libavcodec/mips/hevc_macros_msa.h
@@ -80,6 +80,15 @@
 out_m;   \
 } )
 
+#define HEVC_FILT_4TAP_SH(in0, in1, filt0, filt1)\
+( {  \
+v8i16 out_m; \
+ \
+out_m = __msa_dotp_s_h((v16i8) in0, (v16i8) filt0);  \
+out_m = __msa_dpadd_s_h(out_m, (v16i8) in1, (v16i8) filt1);  \
+out_m;   \
+} )
+
 #define HEVC_FILT_4TAP(in0, in1, filt0, filt1)   \
 ( {  \
 v4i32 out_m; \
diff --git a/libavcodec/mips/hevc_mc_uniw_msa.c 
b/libavcodec/mips/hevc_mc_uniw_msa.c
index 28c7062f..0796b0a 100644
--- a/libavcodec/mips/hevc_mc_uniw_msa.c
+++ b/libavcodec/mips/hevc_mc_uniw_msa.c
@@ -1801,40 +1801,42 @@ static void hevc_hv_uniwgt_8t_4w_msa(uint8_t *src,
  int32_t rnd_val)
 {
 uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
+v16u8 out;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
 v8i16 filt0, filt1, filt2, filt3;
-v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v8i16 filt_h0, filt_h1, filt_h2, filt_h3;
 v16i8 mask1, mask2, mask3;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
 v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
-v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
-v4i32 dst0_r, dst1_r, weight_vec, offset_vec, rnd_vec;
-v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
-v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
-v8u16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+v8i16 dst30, dst41, dst52, dst63, dst66, dst97, dst108;
+v8i16 dst10_r, dst32_r, dst54_r, dst76_r, dst98_r;
+v8i16 dst21_r, dst43_r, dst65_r, dst87_r, dst109_r;
+v4i32 dst0_r, dst1_r, dst2_r, dst3_r;
+v4i32 weight_vec, offset_vec, rnd_vec, const_128, denom_vec;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 
 src -= ((3 * src_stride) + 3);
 filter_vec = LD_SH(filter_x);
 SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W4_SW(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
+SPLATI_W4_SH(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
 
 mask1 = mask0 + 2;
 mask2 = mask0 + 4;
 mask3 = mask0 + 6;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
-
 weight_vec = __msa_fill_w(weight);
 offset_vec = __msa_fill_w(offset);
 rnd_vec = __msa_fill_w(rnd_val);
+denom_vec = rnd_vec - 6;
+
+const_128 = __msa_ldi_w(128);
+const_128 *= weight_vec;
+offset_vec += __msa_srar_w(const_128, denom_vec);
 
 LD_SB7(src, src_stride, src0, src1, src2, src3, src4, src5, src6);
 src += (7 * src_stride);
@@ -1847,64 +1849,68 @@ static void hevc_hv_uniwgt_8t_4w_msa(uint8_t *src,
vec8, vec9, vec10, vec11);
 VSHF_B4_SB(src3, src6, mask0, mask1, mask2, mask3,
vec12, vec13, vec14, vec15);
-dst30 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst30, dst30, dst30, dst30);
-dst41 = const_vec;
-DPADD_SB4_SH(vec4, vec5, vec6, vec7, filt0, filt1, filt2, filt3,
- dst41, dst41, dst41, dst41);
-dst52 = const_vec;
-DPADD_SB4_SH(vec8, vec9, vec10, vec11, filt0, filt1, filt2, filt3,
- dst52, dst52, dst52, dst52);
-dst63 = const_vec;
-DPADD_SB4_SH(vec12, vec13, vec14, vec15, filt0, filt1, filt2, filt3,
- dst63, dst63, dst63, dst63);
-
-ILVR_H3_SH(dst41, dst30, dst52, dst41, dst63, dst52,
-   dst10_r, dst21_r, dst32_r);
-
-dst43_r = __msa_ilvl_h(dst41, dst30);
-dst54_r = __msa_ilvl_h(dst52, dst41);
-dst65_r = __msa_ilvl_h(dst63, dst52);
+dst30 = HEVC_FILT_8TAP_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2,
+  filt3);
+dst41 = 

[FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Thomas Köppe]

Variables used in inline assembly need to be marked with attribute((used)).
Static constants already were, via the define of DECLARE_ASM_CONST.
But DECLARE_ALIGNED does not add this attribute, and some of the variables
defined with it are const only used in inline assembly, and therefore
appeared dead.
---
 libavcodec/cabac.c | 2 +-
 libavutil/mem.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
index dd2b057c6d..7321b48901 100644
--- a/libavcodec/cabac.c
+++ b/libavcodec/cabac.c
@@ -32,7 +32,7 @@
 #include "cabac.h"
 #include "cabac_functions.h"
 
-const uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
+DECLARE_ALIGNED(1, const uint8_t, ff_h264_cabac_tables)[512 + 4*2*64 + 4*64 + 
63] = {
 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
diff --git a/libavutil/mem.h b/libavutil/mem.h
index 527cd03191..c4ee11af58 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -101,7 +101,7 @@
 #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
16 v
 #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (FFMIN(n, 16 v
 #elif defined(__GNUC__) || defined(__clang__)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
+#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(n))) v
 #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (n))) v
 #elif defined(_MSC_VER)
 #define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
-- 
2.15.0.rc2.357.g7e34df9404-goog

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size calculate.

[Mark Thompson]

On 31/10/17 02:37, Jun Zhao wrote:
> From 7eef9be1c8a92bf625d62a0f97f762f1342c6d78 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 31 Oct 2017 10:13:42 +0800
> Subject: [PATCH 1/2] lavc/vaapi_encode: correct the HRD buffer size calculate.
> 
> when rc_buffer_size didn't setting, always use the max bit rate
> per second as HRD buffer size.
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
> ---
>  libavcodec/vaapi_encode.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 590f4be4ed..d5f89ef346 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1144,19 +1144,9 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  return AVERROR(EINVAL);
>  }
>  
> -if (avctx->rc_buffer_size)
> -hrd_buffer_size = avctx->rc_buffer_size;
> -else
> -hrd_buffer_size = avctx->bit_rate;
> -if (avctx->rc_initial_buffer_occupancy)
> -hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
> -else
> -hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
> -
>  if (ctx->va_rc_mode == VA_RC_CBR) {
>  rc_bits_per_second   = avctx->bit_rate;
>  rc_target_percentage = 100;
> -rc_window_size   = 1000;
>  } else {
>  if (avctx->rc_max_rate < avctx->bit_rate) {
>  // Max rate is unset or invalid, just use the normal bitrate.
> @@ -1166,8 +1156,17 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  rc_bits_per_second   = avctx->rc_max_rate;
>  rc_target_percentage = (avctx->bit_rate * 100) / 
> rc_bits_per_second;
>  }
> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
>  }
> +rc_window_size = (rc_bits_per_second * 1000) / avctx->bit_rate;
> +
> +if (avctx->rc_buffer_size)
> +hrd_buffer_size = avctx->rc_buffer_size;
> +else
> +hrd_buffer_size = rc_bits_per_second;
> +if (avctx->rc_initial_buffer_occupancy)
> +hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
> +else
> +hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>  
>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
>  ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
> -- 
> 2.14.1
> 

Why?  If the RC buffer size is unset it currently guesses one second of the 
target bitrate - in what way is the peak bitrate any more appropriate as a 
guess?

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.

[Mark Thompson]

On 31/10/17 02:37, Jun Zhao wrote:
> From d1e105057e93e7c2788d6d684292db9008fbf3ac Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 31 Oct 2017 10:19:08 +0800
> Subject: [PATCH 2/2] lavc/vaapi_encode_h264: correct bit_rate_scale setting.
> 
> As H264 Spec 2012 E.2.2, bit_rate_scale means the max input bit rate.
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
> ---
>  libavcodec/vaapi_encode_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 1d43e934ef..27a810c64e 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -406,7 +406,7 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  // Try to scale these to a sensible range so that the
>  // golomb encode of the value is not overlong.
>  hrd->bit_rate_scale =
> -av_clip_uintp2(av_log2(avctx->bit_rate) - 15 - 6, 4);
> +av_clip_uintp2(av_log2(FFMAX(avctx->bit_rate, 
> avctx->rc_max_rate)) - 15 - 6, 4);
>  hrd->bit_rate_value_minus1[0] =
>  (avctx->bit_rate >> hrd->bit_rate_scale + 6) - 1;
>  
> -- 
> 2.14.1
> 

Can you offer some more justification for that?  I think the change is wrong: 
consider under what circumstances overflow/underflow occurs.

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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Kieran Kunhya]

On Tue, 31 Oct 2017 at 02:26 Michael Niedermayer 
wrote:

> On Thu, Oct 19, 2017 at 11:46:47AM -0700, Nikolas Bowe wrote:
> > Found via fuzzing.
> > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has
> many NALUs
> > Before this change:
> >   $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)"  ./ffprobe
> /tmp/poc 2>&1 | tail -n 1
> >   2158192 Max Resident Set Size (Kb)
> > After this change:
> >   $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)"  ./ffprobe
> /tmp/poc 2>&1 | tail -n 1
> >   1046812 Max Resident Set Size (Kb)
> > ---
> >  libavcodec/h2645_parse.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
>
> This patch also fixes 2145/clusterfuzz-testcase-minimized-5866217724182528
> that should be added to the commit message
>
> (though as said, this fix is not ideal or complete, I would very much
>  prefer if this would be fixed by using a single buffer or any other
>  solution that avoids the speedloss.)
>
> Also please tell me in case you choose not to work on this further.
>
> thx
>
> [...]
>

Hi,

I left the sample in https://trac.ffmpeg.org/ticket/6789 running overnight,
it still leaks with this patch, just much slower.
So there is still a related (but separate?) bug here.

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

Re: [FFmpeg-devel] [PATCH] lavfi/testsrc2: fix hang with very small sizes.

[Nicolas George]

Le decadi 10 brumaire, an CCXXVI, Martin Vignali a écrit :
> lgtm

Thanks, pushed.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/3] examples/filtering_audio: suppress the build warning.

[Steven Liu]

2017-10-31 16:22 GMT+08:00 Jun Zhao :
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 1/3] examples/transcoding: suppress build warning.

[Steven Liu]

2017-10-31 16:22 GMT+08:00 Jun Zhao :
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

From 3ee6e7f01aa2c709afa7ad23f39af919c64f85d5 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 31 Oct 2017 16:09:45 +0800
Subject: [PATCH 1/3] examples/transcoding: suppress build warning.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

suppress the "warning: assignment discards ‘const’ qualifier from
pointer target type" build warning.

Signed-off-by: Jun Zhao 
---
 doc/examples/transcoding.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index e1b3311081..e32ab20245 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -227,8 +227,8 @@ static int init_filter(FilteringContext* fctx,
AVCodecContext *dec_ctx,
 {
 char args[512];
 int ret = 0;
-AVFilter *buffersrc = NULL;
-AVFilter *buffersink = NULL;
+const AVFilter *buffersrc = NULL;
+const AVFilter *buffersink = NULL;
 AVFilterContext *buffersrc_ctx = NULL;
 AVFilterContext *buffersink_ctx = NULL;
 AVFilterInOut *outputs = avfilter_inout_alloc();
-- 
2.14.1




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

[FFmpeg-devel] [PATCH 3/3] examples/filtering_audio: suppress the build warning.

[Jun Zhao]

From 6e8dbeb70f03312deee47a3cf0b5b47a7241ffb5 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 31 Oct 2017 16:12:36 +0800
Subject: [PATCH 3/3] examples/filtering_audio: suppress the build warning.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

suppress the "warning: assignment discards ‘const’ qualifier from
pointer target type" build warning.

Signed-off-by: Jun Zhao 
---
 doc/examples/filtering_audio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index d58b9b75ea..18d6ca275c 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -89,8 +89,8 @@ static int init_filters(const char *filters_descr)
 {
 char args[512];
 int ret = 0;
-AVFilter *abuffersrc  = avfilter_get_by_name("abuffer");
-AVFilter *abuffersink = avfilter_get_by_name("abuffersink");
+const AVFilter *abuffersrc  = avfilter_get_by_name("abuffer");
+const AVFilter *abuffersink = avfilter_get_by_name("abuffersink");
 AVFilterInOut *outputs = avfilter_inout_alloc();
 AVFilterInOut *inputs  = avfilter_inout_alloc();
 static const enum AVSampleFormat out_sample_fmts[] = { AV_SAMPLE_FMT_S16, 
-1 };
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/3] examples/filtering_video: suppress the build warning.

[Jun Zhao]

From e192b42ab0fdc4b8faad50ff7bb01c6028945f19 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 31 Oct 2017 16:11:06 +0800
Subject: [PATCH 2/3] examples/filtering_video: suppress the build warning.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

suppress the "warning: assignment discards ‘const’ qualifier from
pointer target type" build warning.

Signed-off-by: Jun Zhao 
---
 doc/examples/filtering_video.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index fedb2e1c99..9b607ba016 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -92,8 +92,8 @@ static int init_filters(const char *filters_descr)
 {
 char args[512];
 int ret = 0;
-AVFilter *buffersrc  = avfilter_get_by_name("buffer");
-AVFilter *buffersink = avfilter_get_by_name("buffersink");
+const AVFilter *buffersrc  = avfilter_get_by_name("buffer");
+const AVFilter *buffersink = avfilter_get_by_name("buffersink");
 AVFilterInOut *outputs = avfilter_inout_alloc();
 AVFilterInOut *inputs  = avfilter_inout_alloc();
 AVRational time_base = fmt_ctx->streams[video_stream_index]->time_base;
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/3] examples/transcoding: suppress build warning.

[Jun Zhao]

From 3ee6e7f01aa2c709afa7ad23f39af919c64f85d5 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 31 Oct 2017 16:09:45 +0800
Subject: [PATCH 1/3] examples/transcoding: suppress build warning.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

suppress the "warning: assignment discards ‘const’ qualifier from
pointer target type" build warning.

Signed-off-by: Jun Zhao 
---
 doc/examples/transcoding.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index e1b3311081..e32ab20245 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -227,8 +227,8 @@ static int init_filter(FilteringContext* fctx, 
AVCodecContext *dec_ctx,
 {
 char args[512];
 int ret = 0;
-AVFilter *buffersrc = NULL;
-AVFilter *buffersink = NULL;
+const AVFilter *buffersrc = NULL;
+const AVFilter *buffersink = NULL;
 AVFilterContext *buffersrc_ctx = NULL;
 AVFilterContext *buffersink_ctx = NULL;
 AVFilterInOut *outputs = avfilter_inout_alloc();
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] avformat/img2enc: add frame_pts option for make output filename

[Steven Liu]

when use frame_pts option, the output image name can be set with PTS
of current frame.

Signed-off-by: Steven Liu 
---
 doc/muxers.texi   | 9 +
 libavformat/img2enc.c | 8 
 2 files changed, 17 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 91bbe673c5..af5349e683 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -894,9 +894,18 @@ can be used:
 ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1 
"%Y-%m-%d_%H-%M-%S.jpg"
 @end example
 
+You can set the file name with current frame's PTS:
+@example
+ffmpeg -f v4l2 -r 1 -i /dev/video0 -copyts -f image2 -frame_pts true %d.jpg"
+@end example
+
 @subsection Options
 
 @table @option
+@item frame_pts
+If set to 1, expand the filename with pts from pkt->pts.
+Default value is 0.
+
 @item start_number
 Start the sequence from the specified number. Default value is 1.
 
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index d793807b33..de2634119a 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -42,6 +42,7 @@ typedef struct VideoMuxData {
 char target[4][1024];
 int update;
 int use_strftime;
+int frame_pts;
 const char *muxer;
 int use_rename;
 } VideoMuxData;
@@ -99,6 +100,12 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 av_log(s, AV_LOG_ERROR, "Could not get frame filename with 
strftime\n");
 return AVERROR(EINVAL);
 }
+} else if (img->frame_pts) {
+av_log(s, AV_LOG_ERROR, "%"PRId64"\n", pkt->pts);
+if (av_get_frame_filename2(filename, sizeof(filename), img->path, 
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
+av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the 
frames.");
+return AVERROR(EINVAL);
+}
 } else if (av_get_frame_filename2(filename, sizeof(filename), 
img->path,
   img->img_number,
   AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 
0 &&
@@ -207,6 +214,7 @@ static const AVOption muxoptions[] = {
 { "update",   "continuously overwrite one file", OFFSET(update),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,   1, ENC },
 { "start_number", "set first number in the sequence", OFFSET(img_number), 
AV_OPT_TYPE_INT,  { .i64 = 1 }, 0, INT_MAX, ENC },
 { "strftime", "use strftime for filename", OFFSET(use_strftime),  
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
+{ "frame_pts","use current frame pts for filename", OFFSET(frame_pts), 
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { "atomic_writing", "write files atomically (using temporary files and 
renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
 { NULL },
 };
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi hz and hv mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Friday, October 27, 2017 6:35 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi hz and hv mc msa 
functions

From: Kaustubh Raste 

Align the mask buffer.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_bi_msa.c |  940 --
 1 file changed, 595 insertions(+), 345 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_bi_msa.c b/libavcodec/mips/hevc_mc_bi_msa.c
index ccc3f8a..9c03ef8 100644
--- a/libavcodec/mips/hevc_mc_bi_msa.c
+++ b/libavcodec/mips/hevc_mc_bi_msa.c
@@ -22,6 +22,12 @@
 #include "libavcodec/mips/hevcdsp_mips.h"
 #include "libavcodec/mips/hevc_macros_msa.h"
 
+static const uint8_t ff_hevc_mask_arr[16 * 2] __attribute__((aligned(0x40))) = 
{
+/* 8 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
+0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
+};
+
 #define HEVC_BI_RND_CLIP2(in0, in1, vec0, vec1, rnd_val, out0, out1)  \
 { \
 ADDS_SH2_SH(vec0, in0, vec1, in1, out0, out1);\
@@ -531,7 +537,7 @@ static void hevc_hz_bi_8t_4w_msa(uint8_t *src0_ptr,
 v8i16 dst0, dst1, dst2, dst3;
 v8i16 in0, in1, in2, in3, in4, in5, in6, in7;
 v8i16 filter_vec, const_vec;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v16i8 mask0 = LD_SB(_hevc_mask_arr[16]);
 
 src0_ptr -= 3;
 
@@ -557,26 +563,26 @@ static void hevc_hz_bi_8t_4w_msa(uint8_t *src0_ptr,
 ILVR_D2_SH(in5, in4, in7, in6, in2, in3);
 XORI_B8_128_SB(src0, src1, src2, src3, src4, src5, src6, src7);
 
-VSHF_B4_SB(src0, src1, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst0 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst0, dst0, dst0, dst0);
-VSHF_B4_SB(src2, src3, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst1 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst1, dst1, dst1, dst1);
-VSHF_B4_SB(src4, src5, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst2 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst2, dst2, dst2, dst2);
-VSHF_B4_SB(src6, src7, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst3 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst3, dst3, dst3, dst3);
+VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask0, mask0, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt0, filt0, filt0, dst0,
+ dst1, dst2, dst3);
+VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask1, mask1, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt1, filt1, filt1, filt1, dst0,
+ dst1, dst2, dst3);
+VSHF_B2_SB(src0, src1, src2, src3, mask2, mask2, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask2, mask2, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt2, filt2, filt2, filt2, dst0,
+ dst1, dst2, dst3);
+VSHF_B2_SB(src0, src1, src2, src3, mask3, mask3, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask3, mask3, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt3, filt3, filt3, filt3, dst0,
+ dst1, dst2, dst3);
 
 HEVC_BI_RND_CLIP4(in0, in1, in2, in3,
   dst0, dst1, dst2, dst3, 7, dst0, dst1, dst2, dst3);
@@ -604,7 +610,7 @@ static void hevc_hz_bi_8t_8w_msa(uint8_t *src0_ptr,
 v8i16 dst0, dst1, dst2, dst3;
 v8i16 in0, in1, in2, in3;
 v8i16 filter_vec, const_vec;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v16i8 mask0 = LD_SB(_hevc_mask_arr[0]);
 
 src0_ptr -= 3;
 
@@ -625,26 +631,26 @@ static void hevc_hz_bi_8t_8w_msa(uint8_t *src0_ptr,
 src1_ptr += (4 * src2_stride);
 XORI_B4_128_SB(src0, src1, src2, src3);
 
-VSHF_B4_SB(src0, src0, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst0 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst0, dst0, dst0, dst0);
-VSHF_B4_SB(src1, src1, mask0, mask1, mask2, mask3,
-   vec0, vec1, vec2, vec3);
 dst1 = const_vec;
-DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
-

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni vt and hv mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Friday, October 27, 2017 6:59 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni vt and hv mc msa 
functions

From: Kaustubh Raste 

Remove unused macro.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uni_msa.c |  744 +
 1 file changed, 499 insertions(+), 245 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uni_msa.c 
b/libavcodec/mips/hevc_mc_uni_msa.c
index 3a6c5b0..7d24858 100644
--- a/libavcodec/mips/hevc_mc_uni_msa.c
+++ b/libavcodec/mips/hevc_mc_uni_msa.c
@@ -292,20 +292,6 @@ static const uint8_t mc_filt_mask_arr[16 * 3] = {
 8, 9, 9, 10, 10, 11, 11, 12, 24, 25, 25, 26, 26, 27, 27, 28  };
 
-#define FILT_8TAP_DPADD_S_H(vec0, vec1, vec2, vec3, \
-filt0, filt1, filt2, filt3) \
-( { \
-v8i16 tmp0, tmp1;   \
-\
-tmp0 = __msa_dotp_s_h((v16i8) vec0, (v16i8) filt0); \
-tmp0 = __msa_dpadd_s_h(tmp0, (v16i8) vec1, (v16i8) filt1);  \
-tmp1 = __msa_dotp_s_h((v16i8) vec2, (v16i8) filt2); \
-tmp1 = __msa_dpadd_s_h(tmp1, (v16i8) vec3, (v16i8) filt3);  \
-tmp0 = __msa_adds_s_h(tmp0, tmp1);  \
-\
-tmp0;   \
-} )
-
 #define FILT_4TAP_DPADD_S_H(vec0, vec1, filt0, filt1)   \
 ( { \
 v8i16 tmp0; \
@@ -944,12 +930,14 @@ static void common_vt_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
 const int8_t *filter, int32_t height)  {
 uint32_t loop_cnt;
+v16u8 out0, out1;
 v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
+v16i8 src11, src12, src13, src14;
 v16i8 src10_r, src32_r, src54_r, src76_r, src98_r, src21_r, src43_r;
 v16i8 src65_r, src87_r, src109_r, src2110, src4332, src6554, src8776;
+v16i8 src1110_r, src1211_r, src1312_r, src1413_r, src1210, 
+ src14131312;
 v16i8 src10998, filt0, filt1, filt2, filt3;
-v16u8 out;
-v8i16 filt, out10, out32;
+v8i16 filt, out10, out32, out54, out76;
 
 src -= (3 * src_stride);
 
@@ -966,28 +954,45 @@ static void common_vt_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
src4332, src6554);
 XORI_B3_128_SB(src2110, src4332, src6554);
 
-for (loop_cnt = (height >> 2); loop_cnt--;) {
+for (loop_cnt = (height >> 3); loop_cnt--;) {
 LD_SB4(src, src_stride, src7, src8, src9, src10);
 src += (4 * src_stride);
+LD_SB4(src, src_stride, src11, src12, src13, src14);
+src += (4 * src_stride);
 
 ILVR_B4_SB(src7, src6, src8, src7, src9, src8, src10, src9, src76_r,
src87_r, src98_r, src109_r);
+ILVR_B4_SB(src11, src10, src12, src11, src13, src12, src14, src13,
+   src1110_r, src1211_r, src1312_r, src1413_r);
 ILVR_D2_SB(src87_r, src76_r, src109_r, src98_r, src8776, src10998);
+ILVR_D2_SB(src1211_r, src1110_r, src1413_r, src1312_r,
+   src1210, src14131312);
 XORI_B2_128_SB(src8776, src10998);
-out10 = FILT_8TAP_DPADD_S_H(src2110, src4332, src6554, src8776, filt0,
-filt1, filt2, filt3);
-out32 = FILT_8TAP_DPADD_S_H(src4332, src6554, src8776, src10998, filt0,
-filt1, filt2, filt3);
+XORI_B2_128_SB(src1210, src14131312);
+
+DOTP_SB2_SH(src2110, src4332, filt0, filt0, out10, out32);
+DOTP_SB2_SH(src6554, src8776, filt0, filt0, out54, out76);
+DPADD_SB2_SH(src4332, src6554, filt1, filt1, out10, out32);
+DPADD_SB2_SH(src8776, src10998, filt1, filt1, out54, out76);
+DPADD_SB2_SH(src6554, src8776, filt2, filt2, out10, out32);
+DPADD_SB2_SH(src10998, src1210, filt2, filt2, out54, out76);
+DPADD_SB2_SH(src8776, src10998, filt3, filt3, out10, out32);
+DPADD_SB2_SH(src1210, src14131312, filt3, filt3, out54, 
+ out76);
 SRARI_H2_SH(out10, out32, 6);
+SRARI_H2_SH(out54, out76, 6);
 SAT_SH2_SH(out10, out32, 7);
-out = PCKEV_XORI128_UB(out10, out32);
-ST4x4_UB(out, out, 0, 1, 2, 3, dst, dst_stride);
+SAT_SH2_SH(out54, out76, 7);
+out0 = PCKEV_XORI128_UB(out10, out32);
+out1 = PCKEV_XORI128_UB(out54, out76);
+ST4x4_UB(out0, out0, 0, 1, 2, 3, dst, dst_stride);
+dst += (4 * dst_stride);
+