Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Łukasz Krzciuk]

I have prepared a testcase. PMT data comes from org.hbbtv_HTML50420. Please
review.

Regards,

*Łukasz Krzciuk*
Developer

Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska


On Thu, May 10, 2018 at 8:54 PM, Aman Gupta  wrote:

> On Thu, May 10, 2018 at 1:46 AM Łukasz Krzciuk  wrote:
>
> > Lets skip a testcase. It will be not easy to me to prepare it.
>
>
> It should be simple to extract a small sample containing the PMT. If you
> link some larger samples I can help extract the relevant bytes for test
> case.
>
> Aman
>
>
> >
> > Regards,
> >
> > *Łukasz Krzciuk*
> > Developer
> >
> > Vewd
> > ul. Grabarska 2
> > , Pegaz 2A,
> > 50-079 Wrocław, Polska
> >
> >
> > On Thu, May 10, 2018 at 3:09 AM, Michael Niedermayer
> >  > > wrote:
> >
> > > On Wed, May 09, 2018 at 10:19:26AM +0200, Łukasz Krzciuk wrote:
> > > > Any updates on this issue?
> > >
> > > about adding a testcase ?
> > > adding a huge sample file is not possible.
> > > It either has to be made smaller or generated by a muxer
> > > or last resort, no test
> > >
> > > [...]
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > The worst form of inequality is to try to make unequal things equal.
> > > -- Aristotle
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 43c48622594b8d868fea5180bc5a4f8b636ea24a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?= 
Date: Mon, 14 May 2018 10:16:14 +0200
Subject: [PATCH] fixup! avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for
 OIPF cases

---
 libavformat/Makefile   |   1 +
 libavformat/tests/descriptor.c | 265 +
 tests/fate/libavformat.mak |   4 +
 tests/ref/fate/descriptor  |   5 +
 4 files changed, 275 insertions(+)
 create mode 100644 libavformat/tests/descriptor.c
 create mode 100644 tests/ref/fate/descriptor

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3eeca50..373c131 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -635,6 +635,7 @@ TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
 TESTPROGS-$(CONFIG_MOV_MUXER)+= movenc
 TESTPROGS-$(CONFIG_NETWORK)  += noproxy
 TESTPROGS-$(CONFIG_SRTP) += srtp
+TESTPROGS-$(CONFIG_NETWORK)  += descriptor
 
 TOOLS = aviocat \
 ismindex\
diff --git a/libavformat/tests/descriptor.c b/libavformat/tests/descriptor.c
new file mode 100644
index 000..a9635cb
--- /dev/null
+++ b/libavformat/tests/descriptor.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright (c) 2018 Łukasz Krzciuk
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "libavutil/intreadwrite.h"
+#include "libavutil/md5.h"
+
+#include "libavformat/avformat.h"
+#include "libavformat/mpegts.h"
+
+#if HAVE_UNISTD_H
+#include 
+#endif
+
+#if !HAVE_GETOPT
+#include "compat/getopt.c"
+#endif
+
+#define HASH_SIZE 16
+
+static const uint8_t aac_extradata[] = {
+0x12, 0x10
+};
+static const uint8_t pmt_editorial_classification[] = {
+0x02, 0xb0, 0x22, 0x00, 0x02, 0xc1, 0x00, 0x00, 0xe0, 0x21, 0xf0, 0x00,
+0x1b, 0xe0, 0x21, 0xf0, 0x00, 0x11, 0xe0, 0x24, 0xf0, 0x0b, 0x7f, 0x05,
+0x06, 0x87, 0x65, 0x6e, 0x67, 0x7c, 0x02, 0x60, 0x00, 0x6f, 0xe1, 0x92,
+0xf7
+};
+
+static const char *format = "mp4";
+AVFormatContext *ctx;
+uint8_t iobuf[32768];
+AVDictionary *opts;
+
+const char *cur_name;
+int out_size;
+struct AVMD5* md5;
+uint8_t hash[HASH_SIZE];
+
+AVStream *audio_st;
+int64_t audio_dts;
+
+int64_t audio_duration;
+int force_iobuf_size;
+
+static inline int 

[FFmpeg-devel] [PATCH v2 1/3] lavc/h2645_parse: log more HEVC NAL type.

[Jun Zhao]

Signed-off-by: Jun Zhao 
---
 libavcodec/h2645_parse.c | 97 ++--
 libavcodec/hevc.h| 26 -
 2 files changed, 94 insertions(+), 29 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index dbf2435..74bbcf1 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -145,36 +145,77 @@ nsc:
 return si;
 }
 
+static const char *hevc_nal_type_name[64] = {
+"TRAIL_N", // HEVC_NAL_TRAIL_N
+"TRAIL_R", // HEVC_NAL_TRAIL_R
+"TSA_N", // HEVC_NAL_TSA_N
+"TSA_R", // HEVC_NAL_TSA_R
+"STSA_N", // HEVC_NAL_STSA_N
+"STSA_R", // HEVC_NAL_STSA_R
+"RADL_N", // HEVC_NAL_RADL_N
+"RADL_R", // HEVC_NAL_RADL_R
+"RASL_N", // HEVC_NAL_RASL_N
+"RASL_R", // HEVC_NAL_RASL_R
+"RSV_VCL_N10", // HEVC_NAL_VCL_N10
+"RSV_VCL_R11", // HEVC_NAL_VCL_R11
+"RSV_VCL_N12", // HEVC_NAL_VCL_N12
+"RSV_VLC_R13", // HEVC_NAL_VCL_R13
+"RSV_VCL_N14", // HEVC_NAL_VCL_N14
+"RSV_VCL_R15", // HEVC_NAL_VCL_R15
+"BLA_W_LP", // HEVC_NAL_BLA_W_LP
+"BLA_W_RADL", // HEVC_NAL_BLA_W_RADL
+"BLA_N_LP", // HEVC_NAL_BLA_N_LP
+"IDR_W_RADL", // HEVC_NAL_IDR_W_RADL
+"IDR_N_LP", // HEVC_NAL_IDR_N_LP
+"CRA_NUT", // HEVC_NAL_CRA_NUT
+"IRAP_IRAP_VCL22", // HEVC_NAL_IRAP_VCL22
+"IRAP_IRAP_VCL23", // HEVC_NAL_IRAP_VCL23
+"RSV_VCL24", // HEVC_NAL_RSV_VCL24
+"RSV_VCL25", // HEVC_NAL_RSV_VCL25
+"RSV_VCL26", // HEVC_NAL_RSV_VCL26
+"RSV_VCL27", // HEVC_NAL_RSV_VCL27
+"RSV_VCL28", // HEVC_NAL_RSV_VCL28
+"RSV_VCL29", // HEVC_NAL_RSV_VCL29
+"RSV_VCL30", // HEVC_NAL_RSV_VCL30
+"RSV_VCL31", // HEVC_NAL_RSV_VCL31
+"VPS", // HEVC_NAL_VPS
+"SPS", // HEVC_NAL_SPS
+"PPS", // HEVC_NAL_PPS
+"AUD", // HEVC_NAL_AUD
+"EOS_NUT", // HEVC_NAL_EOS_NUT
+"EOB_NUT", // HEVC_NAL_EOB_NUT
+"FD_NUT", // HEVC_NAL_FD_NUT
+"SEI_PREFIX", // HEVC_NAL_SEI_PREFIX
+"SEI_SUFFIX", // HEVC_NAL_SEI_SUFFIX
+"RSV_NVCL41", // HEVC_NAL_RSV_NVCL41
+"RSV_NVCL42", // HEVC_NAL_RSV_NVCL42
+"RSV_NVCL43", // HEVC_NAL_RSV_NVCL43
+"RSV_NVCL44", // HEVC_NAL_RSV_NVCL44
+"RSV_NVCL45", // HEVC_NAL_RSV_NVCL45
+"RSV_NVCL46", // HEVC_NAL_RSV_NVCL46
+"RSV_NVCL47", // HEVC_NAL_RSV_NVCL47
+"UNSPEC48", // HEVC_NAL_UNSPEC48
+"UNSPEC49", // HEVC_NAL_UNSPEC49
+"UNSPEC50", // HEVC_NAL_UNSPEC50
+"UNSPEC51", // HEVC_NAL_UNSPEC51
+"UNSPEC52", // HEVC_NAL_UNSPEC52
+"UNSPEC53", // HEVC_NAL_UNSPEC53
+"UNSPEC54", // HEVC_NAL_UNSPEC54
+"UNSPEC55", // HEVC_NAL_UNSPEC55
+"UNSPEC56", // HEVC_NAL_UNSPEC56
+"UNSPEC57", // HEVC_NAL_UNSPEC57
+"UNSPEC58", // HEVC_NAL_UNSPEC58
+"UNSPEC59", // HEVC_NAL_UNSPEC59
+"UNSPEC60", // HEVC_NAL_UNSPEC60
+"UNSPEC61", // HEVC_NAL_UNSPEC61
+"UNSPEC62", // HEVC_NAL_UNSPEC62
+"UNSPEC63", // HEVC_NAL_UNSPEC63
+};
+
 static const char *nal_unit_name(int nal_type)
 {
-switch(nal_type) {
-case HEVC_NAL_TRAIL_N: return "TRAIL_N";
-case HEVC_NAL_TRAIL_R: return "TRAIL_R";
-case HEVC_NAL_TSA_N  : return "TSA_N";
-case HEVC_NAL_TSA_R  : return "TSA_R";
-case HEVC_NAL_STSA_N : return "STSA_N";
-case HEVC_NAL_STSA_R : return "STSA_R";
-case HEVC_NAL_RADL_N : return "RADL_N";
-case HEVC_NAL_RADL_R : return "RADL_R";
-case HEVC_NAL_RASL_N : return "RASL_N";
-case HEVC_NAL_RASL_R : return "RASL_R";
-case HEVC_NAL_BLA_W_LP   : return "BLA_W_LP";
-case HEVC_NAL_BLA_W_RADL : return "BLA_W_RADL";
-case HEVC_NAL_BLA_N_LP   : return "BLA_N_LP";
-case HEVC_NAL_IDR_W_RADL : return "IDR_W_RADL";
-case HEVC_NAL_IDR_N_LP   : return "IDR_N_LP";
-case HEVC_NAL_CRA_NUT: return "CRA_NUT";
-case HEVC_NAL_VPS: return "VPS";
-case HEVC_NAL_SPS: return "SPS";
-case HEVC_NAL_PPS: return "PPS";
-case HEVC_NAL_AUD: return "AUD";
-case HEVC_NAL_EOS_NUT: return "EOS_NUT";
-case HEVC_NAL_EOB_NUT: return "EOB_NUT";
-case HEVC_NAL_FD_NUT : return "FD_NUT";
-case HEVC_NAL_SEI_PREFIX : return "SEI_PREFIX";
-case HEVC_NAL_SEI_SUFFIX : return "SEI_SUFFIX";
-default : return "?";
-}
+av_assert0(nal_type >= 0 && nal_type < 64);
+return hevc_nal_type_name[nal_type];
 }
 
 static int get_bit_length(H2645NAL *nal, int skip_trailing_zeros)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 2f20db8..670168e 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -22,7 +22,8 @@
 #define AVCODEC_HEVC_H
 
 /**
- * Table 7-3: NAL unit type codes
+ * Table 7-1 – NAL unit type codes and NAL unit type classes in
+ * T-REC-H.265-201802
  */
 enum HEVCNALUnitType {
 HEVC_NAL_TRAIL_N= 0,
@@ -66,6 +67,29 @@ enum HEVCNALUnitType {
 HEVC_NAL_FD_NUT = 38,
 HEVC_NAL_SEI_PREFIX = 39,
 HEVC_NAL_SEI_SUFFIX = 40,
+HEVC_NAL_RSV_NVCL41 = 41,
+HEVC_NAL_RSV_NVCL42 = 42,
+

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Added option for Segment file format

[Jeyapal, Karthick]

On 5/12/18 8:47 PM, Jan Ekström wrote:
> On Fri, May 4, 2018 at 9:32 AM, Karthick J  wrote:
>> From: Karthick Jeyapal 
>>
>> Right now segment file format is chosen to be either mp4 or webm based on 
>> the codec format.
>> This patch makes that choice configurable by the user, instead of being 
>> decided by the muxer.
>> ---
>>  doc/muxers.texi   |  8 
>>  libavformat/dashenc.c | 48 ++--
>>  2 files changed, 30 insertions(+), 26 deletions(-)
>>
>
> Hi,
>
> Sorry for getting to this so late, been busy on various things (as
> usual). Thanks for prodding me.
Thanks for your reply.
>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 6f03bba..2429f8e 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -282,6 +282,14 @@ corrects that index value.
>>  Typically this logic is needed in live streaming use cases. The network 
>> bandwidth
>>  fluctuations are common during long run streaming. Each fluctuation can 
>> cause
>>  the segment indexes fall behind the expected real time position.
>> +
>> +@item dash_segment_type @var{dash_segment_type}
>> +Possible values:
>> +@item mp4
>> +If this flag is set, the dash segment files will be in in ISOBMFF format. 
>> This is the default format.
>> +
>> +@item webm
>> +If this flag is set, the dash segment files will be in in WebM format.
>>  @end table
>>
>>  @anchor{framecrc}
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 1dd6333..412f074 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -48,6 +48,11 @@
>>  #include "vpcc.h"
>>  #include "dash.h"
>>
>> +typedef enum {
>> +SEGMENT_TYPE_MP4,
>> +SEGMENT_TYPE_WEBM,
>> +} SegmentType;
>> +
>
I agree with all your comments below. 
Please find the newer patch in 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229998.html which tries to 
address most of them.
> Ah yes, an enum :) I really like the checks being equality/inequality
> now. I've seen things like SEGMENT_TYPE_NB used for the stopper so
> that in the AVOption you can then set the maximum to *_NB - 1 instead
> of then having to change it if it ever gets anything added to it.
>
> Maybe consider making something like the `codecs[]` array for formats
> and make the thing in DASHContext as a char pointer, so that you can
> just point the string pointer to its value in init() instead of doing
> a run-time strncpy.
>
> This does remove the "dynamicness" of  the per-stream selection, which
> possibly should be mentioned. But at least personally I think this is
> what people actually wanted with WebM vs ISOBMFF DASH selection ;) ,
> as in not having surprises between streams.
>
> Otherwise this patch generally looks alright, leaving just the segment
> file name part not automatical just yet :) (I feel like we need to
> have separate options for the general template and the extension).
>
> Best regards,
> Jan
> ___
> 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 v2 2/3] lavc/h2645_parse: rename the nal_unit_name to hevc_nal_unit_name.

[Jun Zhao]

Rename the nal_unit_name to hevc_nal_unit_name, will add a
h264_nal_unit_name function.

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

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 74bbcf1..cdf6395 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -212,7 +212,7 @@ static const char *hevc_nal_type_name[64] = {
 "UNSPEC63", // HEVC_NAL_UNSPEC63
 };
 
-static const char *nal_unit_name(int nal_type)
+static const char *hevc_nal_unit_name(int nal_type)
 {
 av_assert0(nal_type >= 0 && nal_type < 64);
 return hevc_nal_type_name[nal_type];
@@ -264,7 +264,7 @@ static int hevc_parse_nal_header(H2645NAL *nal, void 
*logctx)
 
 av_log(logctx, AV_LOG_DEBUG,
"nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
-   nal->type, nal_unit_name(nal->type), nuh_layer_id, 
nal->temporal_id);
+   nal->type, hevc_nal_unit_name(nal->type), nuh_layer_id, 
nal->temporal_id);
 
 return nuh_layer_id == 0;
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Tomas Härdin]

ons 2018-04-25 klockan 11:42 +0200 skrev Paul B Mahol:
> On 4/25/18, Tomas Haerdin  wrote:
> > ons 2018-04-25 klockan 09:55 +0100 skrev Josh de Kock:
> > > On 2018/04/25 9:35, Paul B Mahol wrote:
> > > > On 4/25/18, Tomas Haerdin  wrote:
> > > > > [...]
> > > > > 
> > > > > I'll push this this some time later this week if I don't hear
> > > > > any
> > > > > objections
> > > > 
> > > > What is point of it if there is only one nickname?
> > > 
> > > There are two nicknames.
> > 
> > Suggest more then, or just push your own in the future
> 
> Looks like interest is very low...

Pushed what I had. Feel free to add your own nicknames if you like

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

[FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Added a warning for incorrect segment name extension

[Karthick J]

From: Karthick Jeyapal 

Applicable only to webm output format.
By default all the segment filenames end with .m4s extension.
When someone chooses webm output format, we recommend they also override the 
relevant segment name options to end with .webm extension. This patch will 
issue a warning for he same
---
 libavformat/dashenc.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9a57ad1..4e83112 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -195,6 +195,16 @@ static const char *get_format_str(SegmentType 
segment_type) {
 return NULL;
 }
 
+static int check_file_extension(const char *filename, const char *extension) {
+char *dot;
+if (!filename || !extension)
+return -1;
+dot = strrchr(filename, '.');
+if (dot && !strcmp(dot + 1, extension))
+return 0;
+return -1;
+}
+
 static void set_vp9_codec_str(AVFormatContext *s, AVCodecParameters *par,
   AVRational *frame_rate, char *str, int size) {
 VPCC vpcc;
@@ -986,6 +996,17 @@ static int dash_init(AVFormatContext *s)
 c->format_name = get_format_str(c->segment_type);
 if (!c->format_name)
 return AVERROR_MUXER_NOT_FOUND;
+if (c->segment_type == SEGMENT_TYPE_WEBM) {
+if ((!c->single_file && check_file_extension(c->init_seg_name, 
c->format_name) != 0) ||
+(!c->single_file && check_file_extension(c->media_seg_name, 
c->format_name) != 0) ||
+(c->single_file && check_file_extension(c->single_file_name, 
c->format_name) != 0)) {
+av_log(s, AV_LOG_WARNING,
+   "One or many segment file names doesn't end with .webm. 
"
+   "Override -init_seg_name and/or -media_seg_name and/or "
+   "-single_file_name to end with the extension .webm\n");
+}
+}
+
 ctx->oformat = av_guess_format(c->format_name, NULL, NULL);
 if (!ctx->oformat)
 return AVERROR_MUXER_NOT_FOUND;
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/dashenc: Added option for Segment file format

[Jeyapal, Karthick]

On 5/14/18 11:55 AM, Gyan Doshi wrote:
>
>
> On 5/14/2018 11:41 AM, Karthick J wrote:
>
>> Right now segment file format is chosen to be either mp4 or webm based on 
>> the codec format.
>> This patch makes that choice configurable by the user, instead of being 
>> decided by the muxer.
>
> Can you update the docs to reflect on the differences between using the
> dash muxer for WebM and the webm_dash_manifest + webm_chunk muxers?
That's a good question. 
I have never worked/used webm_dash_manifest + webm_chunk muxer, and hence I 
don't know the difference.
If somebody knows the difference, then patches welcome (
>
> Thanks,
> Gyan
> ___
> 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 v2 3/3] lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type.

[Jun Zhao]

Signed-off-by: Jun Zhao 
---
 libavcodec/h264.h| 23 ++-
 libavcodec/h2645_parse.c | 46 --
 2 files changed, 66 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 650580b..7a1fb6d 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -26,8 +26,12 @@
 
 #define QP_MAX_NUM (51 + 6*6)   // The maximum supported qp
 
-/* NAL unit types */
+/*
+ * Table 7-1 – NAL unit type codes, syntax element categories, and NAL unit 
type classes in
+ * T-REC-H.264-201704
+ */
 enum {
+H264_NAL_UNSPECIFIED = 0,
 H264_NAL_SLICE   = 1,
 H264_NAL_DPA = 2,
 H264_NAL_DPB = 3,
@@ -41,7 +45,24 @@ enum {
 H264_NAL_END_STREAM  = 11,
 H264_NAL_FILLER_DATA = 12,
 H264_NAL_SPS_EXT = 13,
+H264_NAL_PREFIX  = 14,
+H264_NAL_SUB_SPS = 15,
+H264_NAL_DPS = 16,
+H264_NAL_RESERVED17  = 17,
+H264_NAL_RESERVED18  = 18,
 H264_NAL_AUXILIARY_SLICE = 19,
+H264_NAL_EXTEN_SLICE = 20,
+H264_NAL_DEPTH_EXTEN_SLICE = 21,
+H264_NAL_RESERVED22  = 22,
+H264_NAL_RESERVED23  = 23,
+H264_NAL_UNSPECIFIED24   = 24,
+H264_NAL_UNSPECIFIED25   = 25,
+H264_NAL_UNSPECIFIED26   = 26,
+H264_NAL_UNSPECIFIED27   = 27,
+H264_NAL_UNSPECIFIED28   = 28,
+H264_NAL_UNSPECIFIED29   = 29,
+H264_NAL_UNSPECIFIED30   = 30,
+H264_NAL_UNSPECIFIED31   = 31,
 };
 
 
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index cdf6395..875dbae 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -28,6 +28,7 @@
 
 #include "bytestream.h"
 #include "hevc.h"
+#include "h264.h"
 #include "h2645_parse.h"
 
 int ff_h2645_extract_rbsp(const uint8_t *src, int length,
@@ -218,6 +219,47 @@ static const char *hevc_nal_unit_name(int nal_type)
 return hevc_nal_type_name[nal_type];
 }
 
+static const char *h264_nal_type_name[32] = {
+"Unspecified 0", //H264_NAL_UNSPECIFIED
+"Coded slice of a non-IDR picture", // H264_NAL_SLICE
+"Coded slice data partition A", // H264_NAL_DPA
+"Coded slice data partition B", // H264_NAL_DPB
+"Coded slice data partition C", // H264_NAL_DPC
+"IDR", // H264_NAL_IDR_SLICE
+"SEI", // H264_NAL_SEI
+"SPS", // H264_NAL_SPS
+"PPS", // H264_NAL_PPS
+"AUD", // H264_NAL_AUD
+"End of sequence", // H264_NAL_END_SEQUENCE
+"End of stream", // H264_NAL_END_STREAM
+"Filler data", // H264_NAL_FILLER_DATA
+"SPS extension", // H264_NAL_SPS_EXT
+"Prefix", // H264_NAL_PREFIX
+"Subset SPS", // H264_NAL_SUB_SPS
+"Depth parameter set", // H264_NAL_DPS
+"Reserved 17", // H264_NAL_RESERVED17
+"Reserved 18", // H264_NAL_RESERVED18
+"Auxiliary coded picture without partitioning", // H264_NAL_AUXILIARY_SLICE
+"Slice extension", // H264_NAL_EXTEN_SLICE
+"Slice extension for a depth view or a 3D-AVC texture view", // 
H264_NAL_DEPTH_EXTEN_SLICE
+"Reserved 22", // H264_NAL_RESERVED22
+"Reserved 23", // H264_NAL_RESERVED23
+"Unspecified 24", // H264_NAL_UNSPECIFIED24
+"Unspecified 25", // H264_NAL_UNSPECIFIED25
+"Unspecified 26", // H264_NAL_UNSPECIFIED26
+"Unspecified 27", // H264_NAL_UNSPECIFIED27
+"Unspecified 28", // H264_NAL_UNSPECIFIED28
+"Unspecified 29", // H264_NAL_UNSPECIFIED29
+"Unspecified 30", // H264_NAL_UNSPECIFIED30
+"Unspecified 31", // H264_NAL_UNSPECIFIED31
+};
+
+static const char *h264_nal_unit_name(int nal_type)
+{
+av_assert0(nal_type >= 0 && nal_type < 32);
+return h264_nal_type_name[nal_type];
+}
+
 static int get_bit_length(H2645NAL *nal, int skip_trailing_zeros)
 {
 int size = nal->size;
@@ -280,8 +322,8 @@ static int h264_parse_nal_header(H2645NAL *nal, void 
*logctx)
 nal->type= get_bits(gb, 5);
 
 av_log(logctx, AV_LOG_DEBUG,
-   "nal_unit_type: %d, nal_ref_idc: %d\n",
-   nal->type, nal->ref_idc);
+   "nal_unit_type: %d(%s), nal_ref_idc: %d\n",
+   nal->type, h264_nal_unit_name(nal->type), nal->ref_idc);
 
 return 1;
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/dashenc: Added option for Segment file format

[Gyan Doshi]

On 5/14/2018 11:41 AM, Karthick J wrote:


Right now segment file format is chosen to be either mp4 or webm based on the 
codec format.
This patch makes that choice configurable by the user, instead of being decided 
by the muxer.


Can you update the docs to reflect on the differences between using the 
dash muxer for WebM and the webm_dash_manifest + webm_chunk muxers?


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

[FFmpeg-devel] [PATCH v2 1/2] avformat/dashenc: Added option for Segment file format

[Karthick J]

From: Karthick Jeyapal 

Right now segment file format is chosen to be either mp4 or webm based on the 
codec format.
This patch makes that choice configurable by the user, instead of being decided 
by the muxer.

Also with this change per-stream choice segment file format(based on codec 
type) is not possible.
All the output audio and video streams should be in the same file format.
---
 doc/muxers.texi   |  8 +++
 libavformat/dashenc.c | 66 +--
 2 files changed, 46 insertions(+), 28 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 57948cf..ea80296 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -284,6 +284,14 @@ corrects that index value.
 Typically this logic is needed in live streaming use cases. The network 
bandwidth
 fluctuations are common during long run streaming. Each fluctuation can cause
 the segment indexes fall behind the expected real time position.
+
+@item dash_segment_type @var{dash_segment_type}
+Possible values:
+@item mp4
+If this flag is set, the dash segment files will be in in ISOBMFF format. This 
is the default format.
+
+@item webm
+If this flag is set, the dash segment files will be in in WebM format.
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1dd6333..9a57ad1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -48,6 +48,12 @@
 #include "vpcc.h"
 #include "dash.h"
 
+typedef enum {
+SEGMENT_TYPE_MP4 = 0,
+SEGMENT_TYPE_WEBM,
+SEGMENT_TYPE_NB
+} SegmentType;
+
 typedef struct Segment {
 char file[1024];
 int64_t start_pos;
@@ -69,7 +75,6 @@ typedef struct OutputStream {
 AVFormatContext *ctx;
 int ctx_inited, as_idx;
 AVIOContext *out;
-char format_name[8];
 int packets_written;
 char initfile[1024];
 int64_t init_start_pos, pos;
@@ -125,6 +130,8 @@ typedef struct DASHContext {
 int streaming;
 int64_t timeout;
 int index_correction;
+SegmentType segment_type;
+const char *format_name;
 } DASHContext;
 
 static struct codec_string {
@@ -138,6 +145,15 @@ static struct codec_string {
 { 0, NULL }
 };
 
+static struct format_string {
+SegmentType segment_type;
+const char *str;
+} formats[] = {
+{ SEGMENT_TYPE_MP4, "mp4" },
+{ SEGMENT_TYPE_WEBM, "webm" },
+{ 0, NULL }
+};
+
 static int dashenc_io_open(AVFormatContext *s, AVIOContext **pb, char 
*filename,
AVDictionary **options) {
 DASHContext *c = s->priv_data;
@@ -171,6 +187,14 @@ static void dashenc_io_close(AVFormatContext *s, 
AVIOContext **pb, char *filenam
 }
 }
 
+static const char *get_format_str(SegmentType segment_type) {
+int i;
+for (i = 0; i < SEGMENT_TYPE_NB; i++)
+if (formats[i].segment_type == segment_type)
+return formats[i].str;
+return NULL;
+}
+
 static void set_vp9_codec_str(AVFormatContext *s, AVCodecParameters *par,
   AVRational *frame_rate, char *str, int size) {
 VPCC vpcc;
@@ -581,13 +605,13 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 if (as->media_type == AVMEDIA_TYPE_VIDEO) {
 AVStream *st = s->streams[i];
 avio_printf(out, "\t\t\tformat_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
+i, c->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
 if (st->avg_frame_rate.num)
 avio_printf(out, " frameRate=\"%d/%d\"", 
st->avg_frame_rate.num, st->avg_frame_rate.den);
 avio_printf(out, ">\n");
 } else {
 avio_printf(out, "\t\t\t\n",
-i, os->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
+i, c->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
 avio_printf(out, "\t\t\t\t\n",
 s->streams[i]->codecpar->channels);
 }
@@ -959,27 +983,10 @@ static int dash_init(AVFormatContext *s)
 if (!ctx)
 return AVERROR(ENOMEM);
 
-// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
-// note: os->format_name is also used as part of the mimetype of the
-//   representation, e.g. video/
-if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
-snprintf(os->format_name, sizeof(os->format_name), "webm");
-
-if (s->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(s, AV_LOG_ERROR,
-   "WebM support in dashenc is experimental and has not "
-   "been validated. For testing purposes, 

[FFmpeg-devel] [PATCH v2 0/3] Enhancement NAL type debug

[Jun Zhao]

v2: - cover all h264/hevc NAL unit type
- use table replace switch when map NAL type to string/name

Jun Zhao (3):
  lavc/h2645_parse: log more HEVC NAL type.
  lavc/h2645_parse: rename the nal_unit_name to hevc_nal_unit_name.
  lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type.

 libavcodec/h264.h|  23 +++-
 libavcodec/h2645_parse.c | 147 ---
 libavcodec/hevc.h|  26 -
 3 files changed, 162 insertions(+), 34 deletions(-)

-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code (library and context) to lavu/hwcontext_amf from amfenc to be reused in other amf components

[Alexander Kravchenko]

Hi Mark, 
Thank you for your comments.
Could you see my comments bellow

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, May 13, 2018 1:41 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code 
> (library and context) to lavu/hwcontext_amf from
> amfenc to be reused in other amf components
> 
> On 12/05/18 09:48, Alexander Kravchenko wrote:
> > This patch moves AMF common parts from amfenc to hwcontext_amf.
> > Now av_hwdevice_ctx API is used for AMF context creation/destroying.
> > This patch does not change component behaviour.
> > it contains only restructurization for further patches with new amf
> > components
> >
> > ---
> > Sending updated patch based on Mark's review
> > 1) simplificated library loading/unloading logic
> > 2) minor fixes
> >
> >
> >  libavcodec/amfenc.c| 247 
> > +---
> >  libavcodec/amfenc.h|  27 +
> >  libavutil/Makefile |   2 +
> >  libavutil/hwcontext.c  |   4 +
> >  libavutil/hwcontext.h  |   1 +
> >  libavutil/hwcontext_amf.c  | 252 
> > +
> >  libavutil/hwcontext_amf.h  |  43 +++
> >  libavutil/hwcontext_internal.h |   1 +
> >  8 files changed, 338 insertions(+), 239 deletions(-)  create mode
> > 100644 libavutil/hwcontext_amf.c  create mode 100644
> > libavutil/hwcontext_amf.h
> >
> > -
> > -static int amf_load_library(AVCodecContext *avctx)
> > +static int amf_init_context(AVCodecContext *avctx)
> >  {
> > -AmfContext*ctx = avctx->priv_data;
> > -AMFInit_Fn init_fun;
> > -AMFQueryVersion_Fn version_fun;
> > -AMF_RESULT res;
> > +AmfContext *ctx = avctx->priv_data;
> > +AVAMFDeviceContext *amf_ctx;
> > +int ret;
> >
> >  ctx->delayed_frame = av_frame_alloc();
> >  if (!ctx->delayed_frame) {
> >  return AVERROR(ENOMEM);
> >  }
> > +
> 
> Stray change?
> 

amf_load_library was moved to hwcontext; code which is unrelated to library 
moved to amf_init_context (delayed_frame object allocation)


> > +
> > +static void amf_device_uninit(AVHWDeviceContext *ctx) {
> > +AVAMFDeviceContext  *amf_ctx = ctx->hwctx;
> > +AMFDeviceContextPrivate *priv = ctx->internal->priv;
> > +if (amf_ctx->context) {
> > +amf_ctx->context->pVtbl->Terminate(amf_ctx->context);
> > +amf_ctx->context->pVtbl->Release(amf_ctx->context);
> > +amf_ctx->context = NULL;
> > +}
> > +if(priv->library) {
> > +dlclose(priv->library);
> > +}
> 
> This stuff shouldn't be in the uninit function, since this runs on all 
> devices rather than just those created internally.  You want to make
> a function to set as AVHWDeviceContext.free.
> 
OK, will be fixed in coming patch


> > +#include "frame.h"
> > +#include "AMF/core/Context.h"
> > +#include "AMF/core/Factory.h"
> > +
> > +
> > +/**
> > + * This struct is allocated as AVHWDeviceContext.hwctx  */ typedef
> > +struct AVAMFDeviceContext {
> > +AMFContext *context;
> > +AMFFactory *factory;
> 
> Might be nice to have a bit more documentation than that.
> 

I will add comments to header in coming patch


> > +} AVAMFDeviceContext;
> > +
> > +

Thanks,
Alexander

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

[FFmpeg-devel] [PATCH] avfilter: add aderivative and aintegral filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |   6 ++
 libavfilter/Makefile |   2 +
 libavfilter/af_aderivative.c | 207 +++
 libavfilter/allfilters.c |   2 +
 4 files changed, 217 insertions(+)
 create mode 100644 libavfilter/af_aderivative.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 30982cb6ab..ba31ed1316 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -585,6 +585,12 @@ adelay=0|500S|700S
 @end example
 @end itemize
 
+@section aderivative, aintegral
+
+Compute derivative/integral of audio stream.
+
+Applying both filters one after another produces original audio.
+
 @section aecho
 
 Apply echoing to the input audio.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b2d6756e79..717aa83359 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -35,6 +35,8 @@ OBJS-$(CONFIG_ACOPY_FILTER)  += af_acopy.o
 OBJS-$(CONFIG_ACROSSFADE_FILTER) += af_afade.o
 OBJS-$(CONFIG_ACRUSHER_FILTER)   += af_acrusher.o
 OBJS-$(CONFIG_ADELAY_FILTER) += af_adelay.o
+OBJS-$(CONFIG_ADERIVATIVE_FILTER)+= af_aderivative.o
+OBJS-$(CONFIG_AINTEGRAL_FILTER)  += af_aderivative.o
 OBJS-$(CONFIG_AECHO_FILTER)  += af_aecho.o
 OBJS-$(CONFIG_AEMPHASIS_FILTER)  += af_aemphasis.o
 OBJS-$(CONFIG_AEVAL_FILTER)  += aeval.o
diff --git a/libavfilter/af_aderivative.c b/libavfilter/af_aderivative.c
new file mode 100644
index 00..a591515cbf
--- /dev/null
+++ b/libavfilter/af_aderivative.c
@@ -0,0 +1,207 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+
+typedef struct ADerivativeContext {
+const AVClass *class;
+AVFrame *prev;
+void (*filter)(void **dst, void **prv, const void **src,
+   int nb_samples, int channels);
+} ADerivativeContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+static const enum AVSampleFormat derivative_sample_fmts[] = {
+AV_SAMPLE_FMT_S16P, AV_SAMPLE_FMT_FLTP,
+AV_SAMPLE_FMT_S32P, AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+static const enum AVSampleFormat integral_sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+formats = ff_make_format_list(strcmp(ctx->filter->name, "aintegral") ?
+  derivative_sample_fmts : 
integral_sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_all_samplerates();
+return ff_set_common_samplerates(ctx, formats);
+}
+
+#define DERIVATIVE(name, type)  \
+static void aderivative_## name ##p(void **d, void **p, const void **s, \
+int nb_samples, int channels)   \
+{   \
+int n, c;   \
+\
+for (c = 0; c < channels; c++) {\
+const type *src = s[c]; \
+type *dst = d[c];   \
+type *prv = p[c];   \
+\
+for (n = 0; n < nb_samples; n++) {  \
+const type current = src[n];\
+\
+dst[n] = current - prv[0];  \
+prv[0] = current;

[FFmpeg-devel] [PATCH] avcodec: Disable new iterate API for ossfuzz

[Michael Niedermayer]

A few days ago ossfuzz stoped testing new FFmpeg as it run out of diskspacee

https://oss-fuzz-build-logs.storage.googleapis.com/index.html

An alternative would be to revert the API.

This changes for example
-rwxr-x--- 1 michael michael 144803654 May 14 12:54 
tools/target_dec_ac3_fixed_fuzzer*
to
-rwxr-x--- 1 michael michael  30333852 May 14 12:51 
tools/target_dec_ac3_fixed_fuzzer*

Which should massively decrease space requirements

Signed-off-by: Michael Niedermayer 
---
 libavcodec/allcodecs.c| 5 +
 tools/target_dec_fuzzer.c | 6 ++
 2 files changed, 11 insertions(+)

diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 102d99b7ea..7b7a8c71ff 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -760,7 +760,12 @@ extern AVCodec ff_vp9_cuvid_decoder;
 extern AVCodec ff_vp9_mediacodec_decoder;
 extern AVCodec ff_vp9_vaapi_encoder;
 
+// The iterate API is not usable with ossfuzz due to the excessive size of 
binaries created
+#if CONFIG_OSSFUZZ
+extern AVCodec * codec_list[];
+#else
 #include "libavcodec/codec_list.c"
+#endif
 
 static AVOnce av_codec_static_init = AV_ONCE_INIT;
 static void av_codec_init_static(void)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 62d62a9de3..26a4cc2e89 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -56,6 +56,11 @@
 
 int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
 
+AVCodec * codec_list[] = {
+NULL,
+NULL
+};
+
 static void error(const char *err)
 {
 fprintf(stderr, "%s", err);
@@ -144,6 +149,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 #define DECODER_SYMBOL0(CODEC) ff_##CODEC##_decoder
 #define DECODER_SYMBOL(CODEC) DECODER_SYMBOL0(CODEC)
 extern AVCodec DECODER_SYMBOL(FFMPEG_DECODER);
+codec_list[0] = _SYMBOL(FFMPEG_DECODER);
 avcodec_register(_SYMBOL(FFMPEG_DECODER));
 
 c = _SYMBOL(FFMPEG_DECODER);
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 5/5] doc/examples: add missing ignore files

[Zhao Zhili]

From: Zhao Zhili 

---
 doc/examples/.gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/examples/.gitignore b/doc/examples/.gitignore
index 154c841..75152cb 100644
--- a/doc/examples/.gitignore
+++ b/doc/examples/.gitignore
@@ -20,3 +20,5 @@
 /scaling_video
 /transcode_aac
 /transcoding
+/vaapi_encode
+/vaapi_transcode
-- 
2.9.5



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

[FFmpeg-devel] [PATCH 4/5] examples/filtering_video: fix memory leak

[Zhao Zhili]

From: Zhao Zhili 

---
 doc/examples/filtering_video.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 2cc55e8..324d566 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -211,18 +211,21 @@ int main(int argc, char **argv)
 {
 int ret;
 AVPacket packet;
-AVFrame *frame = av_frame_alloc();
-AVFrame *filt_frame = av_frame_alloc();
+AVFrame *frame;
+AVFrame *filt_frame;
 
-if (!frame || !filt_frame) {
-perror("Could not allocate frame");
-exit(1);
-}
 if (argc != 2) {
 fprintf(stderr, "Usage: %s file\n", argv[0]);
 exit(1);
 }
 
+frame = av_frame_alloc();
+filt_frame = av_frame_alloc();
+if (!frame || !filt_frame) {
+perror("Could not allocate frame");
+exit(1);
+}
+
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = init_filters(filter_descr)) < 0)
-- 
2.9.5



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

[FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code (library and context) to lavu/hwcontext_amf from amfenc to be reused in other amf components

[Alexander Kravchenko]

This patch moves AMF common parts from amfenc to hwcontext_amf.
Now av_hwdevice_ctx API is used for AMF context creation/destroying.
This patch does not change component behaviour.
it contains only restructurization for further patches with new amf components

---
Sending updated patch based on Mark's review
1) moved device free code from amf_device_uninit to amf_device_free 
2) added comments for AVAMFDeviceContext structure


 libavcodec/amfenc.c| 247 +---
 libavcodec/amfenc.h|  27 +
 libavutil/Makefile |   2 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 253 +
 libavutil/hwcontext_amf.h  |  54 +
 libavutil/hwcontext_internal.h |   1 +
 8 files changed, 350 insertions(+), 239 deletions(-)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..4c907ca3bc 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -21,13 +21,7 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
-#if CONFIG_D3D11VA
-#include "libavutil/hwcontext_d3d11va.h"
-#endif
-#if CONFIG_DXVA2
-#define COBJMACROS
-#include "libavutil/hwcontext_dxva2.h"
-#endif
+
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -35,14 +29,12 @@
 #include "amfenc.h"
 #include "internal.h"
 
-#if CONFIG_D3D11VA
-#include 
+#if CONFIG_DXVA2
+#include 
 #endif
 
-#ifdef _WIN32
-#include "compat/w32dlfcn.h"
-#else
-#include 
+#if CONFIG_D3D11VA
+#include 
 #endif
 
 #define FFMPEG_AMF_WRITER_ID L"ffmpeg_amf"
@@ -88,34 +80,18 @@ static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum 
AVPixelFormat fmt)
 return AMF_SURFACE_UNKNOWN;
 }
 
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
-
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
 
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
+static int amf_init_context(AVCodecContext *avctx)
 {
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
+AmfContext *ctx = avctx->priv_data;
+AVAMFDeviceContext *amf_ctx;
+int ret;
 
 ctx->delayed_frame = av_frame_alloc();
 if (!ctx->delayed_frame) {
 return AVERROR(ENOMEM);
 }
+
 // hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
 ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
 if (!ctx->timestamp_list) {
@@ -123,119 +99,9 @@ static int amf_load_library(AVCodecContext *avctx)
 }
 ctx->dts_delay = 0;
 
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(>version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, >factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported on the 
given device.\n");
-

[FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

Hello all.

This is a little rambling / stream of thought, but take it as you will,
and perhaps some discussion or change comes of it. Or, more likely, personal
attacks, flames, and no change. Or 1 few will reply and then the thread will
die and people will go on like it never happened. Sorry to be pessimistic,
but history speaks for itself.

Currently this list, and IRC, is a terrible place for developers and users.
Harassment is tolerated, and the CoC has never been enforced. There are
absolutely no repercussions as it currently stands. When develpers see others
being abused, do nothing and then continue to act and interact with the
abuses as if nothing happened, in the future.

This current set up of everybody flaming each other endlessly, and endless
harassment merely lets abuse proliferate, because nobody sticks up for each
other and no abusers have ever been removed, ever, in the history of FFmpeg.
Not one thing has changed, ever, since the introduction of the CoC. It is
an absolute failure by all metrics.

I know I am not alone having been driven away by such behavior. Even when
I started to contribute (a little, not much) again, upon joining IRC, for
example, I was immediately attacked. This is not just happening to one
person though.

To be honest, I am not really sure what can be done. Large portions of
the list simply do not support anti-abuse measures at all. Even the
concept of them. How does one manage to implement them without support
of even 50% of a community? VideoLAN managed to do this but it took a lot
of formal stuff on their board and people quitting to get it done. j-b
is some sort of wizard.

I know my opinion is not worth much, since I am now more or less an outsider
since 2015, but maybe someone cares about this stuff, too.

So, I present to you two possible options:

1. Implement a formal CoC enforcement system. This has been mostly 
copypasted
   from VideoLAN's, and is meant as more of a blueprint. This will no doubt
   be controversial.
2. Remove the CoC. If you're not going to enforce it, ever, there is 
literally
   no point in having one. I know some members of this community object to 
the
   very notion of a CoC, so this should please them, I am sure.

I'm sure this will be a civil discussion.

- Derek

-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 2/5] examples/filtering_video: drop an always true condition

[Zhao Zhili]

From: Zhao Zhili 

---
 doc/examples/filtering_video.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 225dccc..170a675 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -248,27 +248,25 @@ int main(int argc, char **argv)
 goto end;
 }
 
-if (ret >= 0) {
-frame->pts = frame->best_effort_timestamp;
+frame->pts = frame->best_effort_timestamp;
 
-/* push the decoded frame into the filtergraph */
-if (av_buffersrc_add_frame_flags(buffersrc_ctx, frame, 
AV_BUFFERSRC_FLAG_KEEP_REF) < 0) {
-av_log(NULL, AV_LOG_ERROR, "Error while feeding the 
filtergraph\n");
+/* push the decoded frame into the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, frame, 
AV_BUFFERSRC_FLAG_KEEP_REF) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while feeding the 
filtergraph\n");
+break;
+}
+
+/* pull filtered frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
 break;
-}
-
-/* pull filtered frames from the filtergraph */
-while (1) {
-ret = av_buffersink_get_frame(buffersink_ctx, 
filt_frame);
-if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
-break;
-if (ret < 0)
-goto end;
-display_frame(filt_frame, 
buffersink_ctx->inputs[0]->time_base);
-av_frame_unref(filt_frame);
-}
-av_frame_unref(frame);
+if (ret < 0)
+goto end;
+display_frame(filt_frame, 
buffersink_ctx->inputs[0]->time_base);
+av_frame_unref(filt_frame);
 }
+av_frame_unref(frame);
 }
 } else {
 av_packet_unref();
-- 
2.9.5

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

[FFmpeg-devel] [PATCH 3/5] examples/filtering_video: add missing headers

[Zhao Zhili]

From: Zhao Zhili 

---
 doc/examples/filtering_video.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 170a675..2cc55e8 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -29,6 +29,8 @@
 
 #define _XOPEN_SOURCE 600 /* for usleep */
 #include 
+#include 
+#include 
 
 #include 
 #include 
-- 
2.9.5



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

[FFmpeg-devel] [PATCH 1/5] examples/filtering_video: fix memory leak

[Zhao Zhili]

From: Zhao Zhili 

---
 doc/examples/filtering_video.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 38ff9bb..225dccc 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -233,6 +233,7 @@ int main(int argc, char **argv)
 
 if (packet.stream_index == video_stream_index) {
 ret = avcodec_send_packet(dec_ctx, );
+av_packet_unref();
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Error while sending a packet to 
the decoder\n");
 break;
@@ -269,8 +270,9 @@ int main(int argc, char **argv)
 av_frame_unref(frame);
 }
 }
+} else {
+av_packet_unref();
 }
-av_packet_unref();
 }
 end:
 avfilter_graph_free(_graph);
-- 
2.9.5



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

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Nicolas George]

Carl Eugen Hoyos (2018-05-14):
> Attached patch allows to easily enable the dash demuxer on systems
> without pkg-config.

I am rather for letting them install pkg-config.

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]configure: Support libxml2 on systems without pkg-config

[Carl Eugen Hoyos]

2018-05-14 21:58 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-05-14):
>> Sorry if this was really not clear:
>> I do not have installation rights on every system where I
>> (at least from time to time) test FFmpeg.
>
> Then install pkg-config in a local directory. If you can compile
> ffmpeg, then you can install pkg-config.
>
>> My primary point is though that I consider it completely unacceptable
>> to constantly send messages to users that their needs are completely
>> irrelevant to us.
>
> Their needs are relevant. Their ill-advised solutions to meet them are
> not.
>
>> (I already realized that nobody is interested in me testing FFmpeg
>> and I should probably be happy about it.)
>
> This is not true. I have already proposed many times to help you find a
> *good* solution to your pkg-config troubles.

No, you have many times refused to allow them being solved.

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

[FFmpeg-devel] [PATCH v5 1/2] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

From: Damien Riegel 

This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.

There is no mechanism for interlaced frames reconstruction at the rtp
demux level, so it has to be handled by the codec which needs to
partially recompose an AVFrame with every incoming field AVPacket.
A frame is ouput only when the frame is completed with the 2nd field
(bottom).

The additionnal field flags in AVPacket allow the decoder to dynamically
determine the frame format, i.e. progressive or interlaced.

Signed-off-by: Patrick Keroulas 
Signed-off-by: Damien Riegel 
---

Change v4 -> v5:
 Call ff_get_buffer only when necessary.
---
 libavcodec/avcodec.h   |   8 
 libavcodec/bitpacked.c | 127 ++---
 2 files changed, 118 insertions(+), 17 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fa..14811be 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1480,6 +1480,14 @@ typedef struct AVPacket {
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
 
+/**
+ * The packet contains a top field.
+ */
+#define AV_PKT_FLAG_TOP_FIELD  0x0020
+/**
+ * The packet contains a bottom field.
+ */
+#define AV_PKT_FLAG_BOTTOM_FIELD  0x0040
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..7c5221d 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -32,8 +32,9 @@
 #include "libavutil/imgutils.h"
 
 struct BitpackedContext {
-int (*decode)(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *pkt);
+int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt);
+AVFrame *cur_interlaced_frame;
+int prev_top_field;
 };
 
 /* For this format, it's a simple passthrough */
@@ -60,25 +61,39 @@ static int bitpacked_decode_yuv422p10(AVCodecContext 
*avctx, AVFrame *frame,
 {
 uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
+int top_field = (avpkt->flags & AV_PKT_FLAG_TOP_FIELD) ? 1 : 0;
 GetBitContext bc;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
-
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size / 2) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
 return AVERROR_INVALIDDATA;
+}
 
 if (avctx->width % 2)
 return AVERROR_PATCHWELCOME;
 
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
+
 ret = init_get_bits(, avpkt->data, avctx->width * avctx->height * 20);
 if (ret)
 return ret;
 
-for (i = 0; i < avctx->height; i++) {
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; i += 1 + interlaced) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -103,17 +118,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext 
*avctx)
 
 if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
 if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for 
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
 bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sample == 20 &&
- avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
+} else if (avctx->bits_per_coded_sample == 20 &&
+ avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
 bc->decode = bitpacked_decode_yuv422p10;
-else
+} else {
 return AVERROR_INVALIDDATA;
+}
 } else {
 return AVERROR_INVALIDDATA;
 }
 
+bc->cur_interlaced_frame = av_frame_alloc();
+
+return 0;
+}
+
+static av_cold int bitpacked_end_decoder(AVCodecContext *avctx)
+{
+

[FFmpeg-devel] [PATCH v5 2/2] avformat/rtpdec_rfc4175: handle interlace format

[Patrick Keroulas]

From: Damien Riegel 

In order to handle the interlaced formats, the demuxer has only a few
things to do:
 - parse the SDP correctly and propagate the information
 - check the field bit in the RFC4175 header, and pass that information
   to the decoder

In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.

Signed-off-by: Damien Riegel 
Signed-off-by: Patrick Keroulas 
---
 libavformat/rtpdec_rfc4175.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..9dc7b29 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -31,6 +31,8 @@ struct PayloadContext {
 int depth;
 int width;
 int height;
+int interlaced;
+int field;
 
 uint8_t *frame;
 unsigned int frame_size;
@@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream, 
PayloadContext *data)
 return AVERROR_INVALIDDATA;
 }
 
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
 stream->codecpar->format = pixfmt;
 stream->codecpar->codec_tag = tag;
 stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup / 
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup / 
data->xinc;
 
 return 0;
 }
@@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream 
*stream,
 data->sampling = av_strdup(value);
 else if (!strncmp(attr, "depth", 5))
 data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
 
 return 0;
 }
@@ -131,7 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext *data, 
AVPacket *pkt,
av_freep(>frame);
}
 
+   /* In the packet header, the field is set to 0 for top field
+* and 1 for bottom */
+if (data->interlaced)
+pkt->flags |= data->field ? AV_PKT_FLAG_BOTTOM_FIELD : 
AV_PKT_FLAG_TOP_FIELD;
+
data->frame = NULL;
+   data->field = 0;
 
return ret;
 }
@@ -141,7 +159,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
  const uint8_t * buf, int len,
  uint16_t seq, int flags)
 {
-int length, line, offset, cont;
+int length, line, offset, cont, field;
 const uint8_t *headers = buf + 2; /* skip extended seqnum */
 const uint8_t *payload = buf + 2;
 int payload_len = len - 2;
@@ -194,11 +212,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 return AVERROR_INVALIDDATA;
 
 length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
 line = ((headers[2] & 0x7f) << 8) | headers[3];
 offset = ((headers[4] & 0x7f) << 8) | headers[5];
 cont = headers[4] & 0x80;
 headers += 6;
 
+data->field = field;
+
 if (length % data->pgroup)
 return AVERROR_INVALIDDATA;
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Nicolas George]

Carl Eugen Hoyos (2018-05-14):
> Which - as you know - can be impossible.

I doubt there are systems where ffmpeg can be installed but not
pkg-config.

But if you really think there are, the best solution is to provide a
minimalistic emulation of pkg-config. I would not object if you propose
a patch adding such a script in tools, and I would even offer to help,
to the limit of my ability. This would have the benefit of only
impacting people who want it, not slowing everybody who runs configure.

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] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Rostislav Pehlivanov]

On 14 May 2018 at 19:23, Derek Buitenhuis 
wrote:

>
> We can agree to disagree. There's not much point in arguing
> over one specific event. This mail was not about clearing up
> a specific event, but a general problem. There's not much point
> in devolving into that.
>

We can't agree to disagree in this case, not if you seriously think that
this is an attack. Would you continue to interpret such vague events as
attacks? You gave it as an example after all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

On Mon, May 14, 2018 at 8:54 PM, Rostislav Pehlivanov
 wrote:
> We can't agree to disagree in this case, not if you seriously think that
> this is an attack. Would you continue to interpret such vague events as
> attacks? You gave it as an example after all.

You can use the example from May 2016 if you wish. It's just an example, and
not the point, which is wider.

What does it matter how *I* specifically interpret a attack? I am not the judge,
jury, and executioner. One of the points of a CoC is to have more than one
person review a supposed incident, instead of this incessant bickering we
have all come to love.

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

Re: [FFmpeg-devel] [PATCH v5 1/2] avcodec/bitpacked: add interlace support

[Rostislav Pehlivanov]

On 14 May 2018 at 20:29, Patrick Keroulas  wrote:

> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> There is no mechanism for interlaced frames reconstruction at the rtp
> demux level, so it has to be handled by the codec which needs to
> partially recompose an AVFrame with every incoming field AVPacket.
> A frame is ouput only when the frame is completed with the 2nd field
> (bottom).
>
> The additionnal field flags in AVPacket allow the decoder to dynamically
> determine the frame format, i.e. progressive or interlaced.
>
> Signed-off-by: Patrick Keroulas 
> Signed-off-by: Damien Riegel 
> ---
>
> Change v4 -> v5:
>  Call ff_get_buffer only when necessary.
> ---
>  libavcodec/avcodec.h   |   8 
>  libavcodec/bitpacked.c | 127 ++
> ---
>  2 files changed, 118 insertions(+), 17 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..14811be 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
>   */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0020
> +/**
> + * The packet contains a bottom field.
> + */
> +#define AV_PKT_FLAG_BOTTOM_FIELD  0x0040
>

Add a doc/APIchanges entry and bump lavc minor version.
Also make it a separate patch.



>  enum AVSideDataParamChangeFlags {
>  AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index f0b417d..7c5221d 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -32,8 +32,9 @@
>  #include "libavutil/imgutils.h"
>
>  struct BitpackedContext {
> -int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> -  AVPacket *pkt);
> +int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt);
> +AVFrame *cur_interlaced_frame;
> +int prev_top_field;
>  };
>
>  /* For this format, it's a simple passthrough */
> @@ -60,25 +61,39 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  {
>  uint64_t frame_size = (uint64_t)avctx->width *
> (uint64_t)avctx->height * 20;
>

20LL will promote the multiplication to 64 bits without needing to cast
both the width and the height.



>  uint64_t packet_size = (uint64_t)avpkt->size * 8;
> +int interlaced = frame->interlaced_frame;
> +int top_field = (avpkt->flags & AV_PKT_FLAG_TOP_FIELD) ? 1 : 0;
>  GetBitContext bc;
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -ret = ff_get_buffer(avctx, frame, 0);
> -if (ret < 0)
> -return ret;
> -
> -if (frame_size > packet_size)
> +/* check packet size depending on the interlaced/progressive format */
> +if (interlaced) {
> +if ((frame_size / 2) > packet_size)
> +return AVERROR_INVALIDDATA;
> +} else if (frame_size > packet_size) {
>  return AVERROR_INVALIDDATA;
> +}
>
>  if (avctx->width % 2)
>  return AVERROR_PATCHWELCOME;
>
> +/*
> + * if the frame is interlaced, the avpkt we are getting is either the
> top
> + * or the bottom field. If it's the bottom field, it contains all the
> odd
> + * lines of the recomposed frame, so we start at offset 1.
> + */
> +i = (interlaced && !top_field) ? 1 : 0;
> +

 ret = init_get_bits(, avpkt->data, avctx->width * avctx->height *
> 20);
>

You already calculate width*height*20, in frame_size, reuse it.


 if (ret)
>  return ret;
>
> -for (i = 0; i < avctx->height; i++) {
> +/*
> + * Packets from interlaced frames contain either even lines, or odd
> + * lines, so increment by two in that case.
> + */
> +for (; i < avctx->height; i += 1 + interlaced) {
>  y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
>  u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
>  v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> @@ -103,17 +118,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext
> *avctx)
>
>  if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
>  if (avctx->bits_per_coded_sample == 16 &&
> -avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> +avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> +
> +if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
> +av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported
> for 8-bit\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
>  bc->decode = 

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Jan Ekström]

On Mon, May 14, 2018 at 10:42 PM, Carl Eugen Hoyos  wrote:
> 2018-05-14 21:39 GMT+02:00, Nicolas George :
>> Carl Eugen Hoyos (2018-05-14):
>>> Attached patch allows to easily enable the dash demuxer on systems
>>> without pkg-config.
>>
>> I am rather for letting them install pkg-config.
>
> Which - as you know - can be impossible.
>
> Carl Eugen

Just out of interest, which systems are these? OS/2? While this
question could be interpreted as facetious, let me say I am wholly
just genuinely interested in such systems - where modern FFmpeg can
still build or operate.

Also for the record, some distros (including Fedora) have actually
stopped using original pkg-config since a few versions ago, instead
opting for a new re-implementation called pkgconf
(https://github.com/pkgconf/pkgconf).

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

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Nicolas George]

Carl Eugen Hoyos (2018-05-14):
> Sorry if this was really not clear:
> I do not have installation rights on every system where I
> (at least from time to time) test FFmpeg.

Then install pkg-config in a local directory. If you can compile
ffmpeg, then you can install pkg-config.

> My primary point is though that I consider it completely unacceptable
> to constantly send messages to users that their needs are completely
> irrelevant to us.

Their needs are relevant. Their ill-advised solutions to meet them are
not.

> (I already realized that nobody is interested in me testing FFmpeg
> and I should probably be happy about it.)

This is not true. I have already proposed many times to help you find a
*good* solution to your pkg-config troubles.

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]configure: Support libxml2 on systems without pkg-config

[Carl Eugen Hoyos]

2018-05-14 21:39 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-05-14):
>> Attached patch allows to easily enable the dash demuxer on systems
>> without pkg-config.
>
> I am rather for letting them install pkg-config.

Which - as you know - can be impossible.

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

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Carl Eugen Hoyos]

2018-05-14 21:46 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-05-14):
>> Which - as you know - can be impossible.
>
> I doubt there are systems where ffmpeg can be installed but not
> pkg-config.

Sorry if this was really not clear:
I do not have installation rights on every system where I
(at least from time to time) test FFmpeg.

My primary point is though that I consider it completely unacceptable
to constantly send messages to users that their needs are completely
irrelevant to us.
(I already realized that nobody is interested in me testing FFmpeg
and I should probably be happy about it.)

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Nicolas George]

Dave Gregory (2018-05-14):
> First, a bit of context on our motivation. We write software that runs on
> IP cameras to connect them to our cloud service. We started off by
> using GnuTLS to secure our connections but there's very limited disk
> space on the cameras and the relatively large binary footprint caused
> some problems. Looking around for an alternative library we discovered
> mbedTLS, a project with a good open-source heritage, suitable license
> terms and a major commercial backer (ARM Holdings).

Have you considered BearSSL? It seems that it beats mbedTLS on memory
footprint by an order of magnitude.

It is not a well-known project, but I used to know the author, and he's
really really good.

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] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

On Mon, May 14, 2018 at 7:10 PM, Rostislav Pehlivanov
 wrote:
> That's a greeting, a welcoming back. You know, you're with friends, you get
> some money together, one of you goes to the store to grab a few beers, he
> comes back, "Ah, and you're back, and you bought enough beers, great.". It
> would be an attack if someone said "Ah, and you're back, and I see you
> bought the worst flavored water they sold there and kept the change.".  You
> don't walk out with the beers as soon as you hear "Ah, and you're back"
> because that someone attacked your personal choice last time you went to
> the store and this time you made some effort to find something else for
> them.

... What? This is either the most naive interpretation of events I have ever
read, or it's disingenuous. iive has never been anything even approaching
friendly to me, ever. It also ignores context entirely.

>> That should put to rest an notion it was a friendly "welcome back".
>
> Sorry, still not seeing it as an attack. When you left, sure, but not when
> you returned.

We can agree to disagree. There's not much point in arguing
over one specific event. This mail was not about clearing up
a specific event, but a general problem. There's not much point
in devolving into that.

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Paul B Mahol]

On 5/14/18, Derek Buitenhuis  wrote:
>>> Lies, Lies and Lies.
>>
>>
>> I don't think it's a good thing to call a dev a liar based on limited
>> available information. If you have doubts, you can express it as such, but
>> don't assert doubts as truths.
>
> Hmm... there must be some reason that people continue ad hominem
> attacks even though we have a CoC... hmm.

So whatever I say, you will interpret it as attack.

So I will just ignore you from now on. As it is impossible to communicate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[wm4]

On Mon, 14 May 2018 17:50:25 +0100
Derek Buitenhuis  wrote:

> Hello all.
> 
> This is a little rambling / stream of thought, but take it as you will,
> and perhaps some discussion or change comes of it. Or, more likely, personal
> attacks, flames, and no change. Or 1 few will reply and then the thread will
> die and people will go on like it never happened. Sorry to be pessimistic,
> but history speaks for itself.
> 
> Currently this list, and IRC, is a terrible place for developers and users.
> Harassment is tolerated, and the CoC has never been enforced. There are
> absolutely no repercussions as it currently stands. When develpers see others
> being abused, do nothing and then continue to act and interact with the
> abuses as if nothing happened, in the future.
> 
> This current set up of everybody flaming each other endlessly, and endless
> harassment merely lets abuse proliferate, because nobody sticks up for each
> other and no abusers have ever been removed, ever, in the history of FFmpeg.
> Not one thing has changed, ever, since the introduction of the CoC. It is
> an absolute failure by all metrics.
> 
> I know I am not alone having been driven away by such behavior. Even when
> I started to contribute (a little, not much) again, upon joining IRC, for
> example, I was immediately attacked. This is not just happening to one
> person though.
> 
> To be honest, I am not really sure what can be done. Large portions of
> the list simply do not support anti-abuse measures at all. Even the
> concept of them. How does one manage to implement them without support
> of even 50% of a community? VideoLAN managed to do this but it took a lot
> of formal stuff on their board and people quitting to get it done. j-b
> is some sort of wizard.
> 
> I know my opinion is not worth much, since I am now more or less an outsider
> since 2015, but maybe someone cares about this stuff, too.
> 
> So, I present to you two possible options:
> 
> 1. Implement a formal CoC enforcement system. This has been mostly 
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no 
> doubt
>be controversial.
> 2. Remove the CoC. If you're not going to enforce it, ever, there is 
> literally
>no point in having one. I know some members of this community object 
> to the
>very notion of a CoC, so this should please them, I am sure.
> 
> I'm sure this will be a civil discussion.

1, please. I don't want PC reeducation camps, but not having a
kindergarten would be nice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[James Almer]

On 5/14/2018 1:50 PM, Derek Buitenhuis wrote:
> Hello all.
> 
> This is a little rambling / stream of thought, but take it as you will,
> and perhaps some discussion or change comes of it. Or, more likely, personal
> attacks, flames, and no change. Or 1 few will reply and then the thread will
> die and people will go on like it never happened. Sorry to be pessimistic,
> but history speaks for itself.
> 
> Currently this list, and IRC, is a terrible place for developers and users.
> Harassment is tolerated, and the CoC has never been enforced. There are
> absolutely no repercussions as it currently stands. When develpers see others
> being abused, do nothing and then continue to act and interact with the
> abuses as if nothing happened, in the future.

As it currently stands, the only way to enforce the CoC is with a vote,
from a committee made from a list of ~20 devs about three or so years
ago who may or may not still be active, and who may or may not even know
enough about what is being voted.
Said committee was good for a few technical decisions back in the day,
but as soon as you introduce a vote related to developer conduct, all
the flaws become evident. Hell, even an IRC meeting was called once, but
then nobody wanted to touch the subject with a ten foot pole in it.

> 
> This current set up of everybody flaming each other endlessly, and endless
> harassment merely lets abuse proliferate, because nobody sticks up for each
> other and no abusers have ever been removed, ever, in the history of FFmpeg.
> Not one thing has changed, ever, since the introduction of the CoC. It is
> an absolute failure by all metrics.
> 
> I know I am not alone having been driven away by such behavior. Even when
> I started to contribute (a little, not much) again, upon joining IRC, for
> example, I was immediately attacked. This is not just happening to one
> person though.

I suppose you're talking about some months ago when you joined and iive
said something like "oh, he's back" or some such. I personally think you
overreacted in that situation, but i also find it odd you haven't muted
someone you have never liked to deal with, seeing plenty other devs do it.

> 
> To be honest, I am not really sure what can be done. Large portions of
> the list simply do not support anti-abuse measures at all. Even the
> concept of them. How does one manage to implement them without support
> of even 50% of a community? VideoLAN managed to do this but it took a lot
> of formal stuff on their board and people quitting to get it done. j-b
> is some sort of wizard.
> 
> I know my opinion is not worth much, since I am now more or less an outsider
> since 2015, but maybe someone cares about this stuff, too.
> 
> So, I present to you two possible options:
> 
> 1. Implement a formal CoC enforcement system. This has been mostly 
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no 
> doubt
>be controversial.
> 2. Remove the CoC. If you're not going to enforce it, ever, there is 
> literally
>no point in having one. I know some members of this community object 
> to the
>very notion of a CoC, so this should please them, I am sure.
> 
> I'm sure this will be a civil discussion.
> 
> - Derek
> 

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Rostislav Pehlivanov]

On 14 May 2018 at 17:50, Derek Buitenhuis 
wrote:

> Hello all.
>
> This is a little rambling / stream of thought, but take it as you will,
> and perhaps some discussion or change comes of it. Or, more likely,
> personal
> attacks, flames, and no change. Or 1 few will reply and then the thread
> will
> die and people will go on like it never happened. Sorry to be pessimistic,
> but history speaks for itself.
>
> Currently this list, and IRC, is a terrible place for developers and users.
> Harassment is tolerated, and the CoC has never been enforced. There are
> absolutely no repercussions as it currently stands. When develpers see
> others
> being abused, do nothing and then continue to act and interact with the
> abuses as if nothing happened, in the future.
>
> This current set up of everybody flaming each other endlessly, and endless
> harassment merely lets abuse proliferate, because nobody sticks up for each
> other and no abusers have ever been removed, ever, in the history of
> FFmpeg.
> Not one thing has changed, ever, since the introduction of the CoC. It is
> an absolute failure by all metrics.
>
> I know I am not alone having been driven away by such behavior. Even when
> I started to contribute (a little, not much) again, upon joining IRC, for
> example, I was immediately attacked. This is not just happening to one
> person though.
>

iive just noticed you joined, said hi, and you left saying you were
attacked. Since when is a normal form of welcoming back considered an
attack? I agree with jamrial, you definitely overreacted.


To be honest, I am not really sure what can be done. Large portions of
> the list simply do not support anti-abuse measures at all. Even the
> concept of them. How does one manage to implement them without support
> of even 50% of a community? VideoLAN managed to do this but it took a lot
> of formal stuff on their board and people quitting to get it done. j-b
> is some sort of wizard.
>
> I know my opinion is not worth much, since I am now more or less an
> outsider
> since 2015, but maybe someone cares about this stuff, too.
>
> So, I present to you two possible options:
>
> 1. Implement a formal CoC enforcement system. This has been mostly
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no
> doubt
>be controversial.
> 2. Remove the CoC. If you're not going to enforce it, ever, there is
> literally
>no point in having one. I know some members of this community
> object to the
>very notion of a CoC, so this should please them, I am sure.
>
> I'm sure this will be a civil discussion.
>

2's a nice option.  The recent llvm fiasco demonstrated the dangers of CoCs
being used by the wrong people.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC][PATCH][Type 2] Revert "doc/developer.texi: Add a code of conduct"

[Derek Buitenhuis]

It was never enforced, and there is no documented way to enforce it,
rendering it useless.

This reverts commit 89e9393022373bf97d528e6e9f2601ad0b3d0fc1.
---
 doc/developer.texi | 29 -
 1 file changed, 29 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a0eeefe..0d72966 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -419,35 +419,6 @@ finding a new maintainer and also don't forget to update 
the @file{MAINTAINERS}
 
 We think our rules are not too hard. If you have comments, contact us.
 
-@chapter Code of conduct
-
-Be friendly and respectful towards others and third parties.
-Treat others the way you yourself want to be treated.
-
-Be considerate. Not everyone shares the same viewpoint and priorities as you 
do.
-Different opinions and interpretations help the project.
-Looking at issues from a different perspective assists development.
-
-Do not assume malice for things that can be attributed to incompetence. Even if
-it is malice, it's rarely good to start with that as initial assumption.
-
-Stay friendly even if someone acts contrarily. Everyone has a bad day
-once in a while.
-If you yourself have a bad day or are angry then try to take a break and reply
-once you are calm and without anger if you have to.
-
-Try to help other team members and cooperate if you can.
-
-The goal of software development is to create technical excellence, not for any
-individual to be better and "win" against the others. Large software projects
-are only possible and successful through teamwork.
-
-If someone struggles do not put them down. Give them a helping hand
-instead and point them in the right direction.
-
-Finally, keep in mind the immortal words of Bill and Ted,
-"Be excellent to each other."
-
 @anchor{Submitting patches}
 @chapter Submitting patches
 
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Paul B Mahol]

On 5/14/18, Derek Buitenhuis  wrote:
> Hello all.
>
> This is a little rambling / stream of thought, but take it as you will,
> and perhaps some discussion or change comes of it. Or, more likely, personal
> attacks, flames, and no change. Or 1 few will reply and then the thread will
> die and people will go on like it never happened. Sorry to be pessimistic,
> but history speaks for itself.
>
> Currently this list, and IRC, is a terrible place for developers and users.
> Harassment is tolerated, and the CoC has never been enforced. There are
> absolutely no repercussions as it currently stands. When develpers see
> others
> being abused, do nothing and then continue to act and interact with the
> abuses as if nothing happened, in the future.
>
> This current set up of everybody flaming each other endlessly, and endless
> harassment merely lets abuse proliferate, because nobody sticks up for each
> other and no abusers have ever been removed, ever, in the history of FFmpeg.
> Not one thing has changed, ever, since the introduction of the CoC. It is
> an absolute failure by all metrics.
>
> I know I am not alone having been driven away by such behavior. Even when
> I started to contribute (a little, not much) again, upon joining IRC, for
> example, I was immediately attacked. This is not just happening to one
> person though.

Lies, Lies and Lies.

>
> To be honest, I am not really sure what can be done. Large portions of
> the list simply do not support anti-abuse measures at all. Even the
> concept of them. How does one manage to implement them without support
> of even 50% of a community? VideoLAN managed to do this but it took a lot
> of formal stuff on their board and people quitting to get it done. j-b
> is some sort of wizard.
>
> I know my opinion is not worth much, since I am now more or less an outsider
> since 2015, but maybe someone cares about this stuff, too.
>
> So, I present to you two possible options:
>
> 1. Implement a formal CoC enforcement system. This has been mostly
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no
> doubt
>be controversial.
> 2. Remove the CoC. If you're not going to enforce it, ever, there is
> literally
>no point in having one. I know some members of this community object
> to the
>very notion of a CoC, so this should please them, I am sure.
>
> I'm sure this will be a civil discussion.

I vote for 2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC][PATCH][Type 1] developers: Add a section on CoC enforcemnet

[Derek Buitenhuis]

This is currently directly copied from the VideoLAN CoC[1] in
order to spur discussion.

[1] https://wiki.videolan.org/Code_of_Conduct/#Disciplinary_actions

Signed-off-by: Derek Buitenhuis 
---
 doc/developer.texi | 83 ++
 1 file changed, 83 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index a0eeefe..50b5153 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -421,6 +421,7 @@ We think our rules are not too hard. If you have comments, 
contact us.
 
 @chapter Code of conduct
 
+@section Code of conduct text
 Be friendly and respectful towards others and third parties.
 Treat others the way you yourself want to be treated.
 
@@ -448,6 +449,88 @@ instead and point them in the right direction.
 Finally, keep in mind the immortal words of Bill and Ted,
 "Be excellent to each other."
 
+@section Escalation
+@enumerate
+
+@item
+The first violation will always result in a simple warning, except if it is a 
grave or
+deliberate violation. 
+
+@item
+The following violations will result in some of the disciplinary actions 
listed in the
+paragraphs below.
+
+@item
+For repetitive violations, the case may be escalated to a vote for further 
disciplinary
+actions. 
+@end enumerate
+
+@section Disciplinary Actions 
+The following disciplinary actions may be enforced when a direct Code of 
Conduct violation
+is reported. 
+
+NB: Before applying any of the following disciplinary policies, the FFmpeg 
members will
+try to discuss the problem with the offender in order to solve it in a more 
peaceful way.
+However, it is possible for memberss to apply the penalty without discussions 
in severe
+Code of Conduct violations. 
+
+@subheading Mailing lists
+@itemize @bullet
+
+@item
+The netiquette violations will get only a warning. Repeated netiquette 
violations will be escalated.
+
+@item
+24-hour ban from the mailing list in question.
+
+@item
+Every third violation, the contributor will get a 7-day ban.
+
+@item
+As one cannot develop without the mailing lists, a ban from the ffmpeg-devel 
mailing list will result in
+a ban from commit access for one day on the related project. For spam 
violations, the first ban can be
+longer or infinite. 
+@end itemize
+
+@subheading IRC
+@itemize @bullet
+
+@item
+Direct kick for minor violations, enforced by channels ops.
+
+@item
+Other violations will get a 24-hour ban from the IRC channel.
+
+@item
+Every third violation, the offender will have a 7-day ban. 
+@end itemize
+
+@subheading Bugtracker
+@itemize @bullet
+
+@item
+24-hour ban from trac.
+
+@item
+Removal of developer or admin rights.
+
+@item
+Every third violation, the offender will be banned for 7 days.
+
+@item
+Every third violation, a developer may lose commit access for 7 days. 
+@end itemize
+
+@subheading Code Repository
+@itemize @bullet
+
+@item
+24-hour ban from commit access. 
+
+@item
+Every third violation, the developer will lose commit access for 7 days. 
+@end itemize
+
 @anchor{Submitting patches}
 @chapter Submitting patches
 
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Ronald S. Bultje]

Hi,

On Mon, May 14, 2018 at 12:58 PM, Paul B Mahol  wrote:

> On 5/14/18, Derek Buitenhuis  wrote:
> > Hello all.
> >
> > This is a little rambling / stream of thought, but take it as you will,
> > and perhaps some discussion or change comes of it. Or, more likely,
> personal
> > attacks, flames, and no change. Or 1 few will reply and then the thread
> will
> > die and people will go on like it never happened. Sorry to be
> pessimistic,
> > but history speaks for itself.
> >
> > Currently this list, and IRC, is a terrible place for developers and
> users.
> > Harassment is tolerated, and the CoC has never been enforced. There are
> > absolutely no repercussions as it currently stands. When develpers see
> > others
> > being abused, do nothing and then continue to act and interact with the
> > abuses as if nothing happened, in the future.
> >
> > This current set up of everybody flaming each other endlessly, and
> endless
> > harassment merely lets abuse proliferate, because nobody sticks up for
> each
> > other and no abusers have ever been removed, ever, in the history of
> FFmpeg.
> > Not one thing has changed, ever, since the introduction of the CoC. It is
> > an absolute failure by all metrics.
> >
> > I know I am not alone having been driven away by such behavior. Even when
> > I started to contribute (a little, not much) again, upon joining IRC, for
> > example, I was immediately attacked. This is not just happening to one
> > person though.
>
> Lies, Lies and Lies.


I don't think it's a good thing to call a dev a liar based on limited
available information. If you have doubts, you can express it as such, but
don't assert doubts as truths.

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Rostislav Pehlivanov]

On 14 May 2018 at 18:45, Derek Buitenhuis 
wrote:

> On Mon, May 14, 2018 at 6:28 PM, Rostislav Pehlivanov
>  wrote:
> > iive just noticed you joined, said hi, and you left saying you were
> > attacked. Since when is a normal form of welcoming back considered an
> > attack? I agree with jamrial, you definitely overreacted.
>
> If you actually believe it was a welcome back, you must be willfully
> ignorant of ... well, iive. I may note I purposely was not mentioning
> specific names.
>
> Day I left:
>
> [21:34:17 CEST]  jamrial: Derek for sure will cause more
> problems, when he comes back. He will come back.
>

Yes, its an attack. A full year before you rejoined for a few minutes.



> 13:23  -!- Daemon404 [~who_knows@pdpc/supporter/student/Daemon404] has
> joined #ffmpeg-devel
> 13:46 <@iive> and Daemon404 is back.
>
>
That's a greeting, a welcoming back. You know, you're with friends, you get
some money together, one of you goes to the store to grab a few beers, he
comes back, "Ah, and you're back, and you bought enough beers, great.". It
would be an attack if someone said "Ah, and you're back, and I see you
bought the worst flavored water they sold there and kept the change.".  You
don't walk out with the beers as soon as you hear "Ah, and you're back"
because that someone attacked your personal choice last time you went to
the store and this time you made some effort to find something else for
them.



> That should put to rest an notion it was a friendly "welcome back".
>

Sorry, still not seeing it as an attack. When you left, sure, but not when
you returned.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[James Almer]

On 5/14/2018 3:10 PM, Rostislav Pehlivanov wrote:
> On 14 May 2018 at 18:45, Derek Buitenhuis 
> wrote:
> 
>> On Mon, May 14, 2018 at 6:28 PM, Rostislav Pehlivanov
>>  wrote:
>>> iive just noticed you joined, said hi, and you left saying you were
>>> attacked. Since when is a normal form of welcoming back considered an
>>> attack? I agree with jamrial, you definitely overreacted.
>>
>> If you actually believe it was a welcome back, you must be willfully
>> ignorant of ... well, iive. I may note I purposely was not mentioning
>> specific names.
>>
>> Day I left:
>>
>> [21:34:17 CEST]  jamrial: Derek for sure will cause more
>> problems, when he comes back. He will come back.
>>
> 
> Yes, its an attack. A full year before you rejoined for a few minutes.
> 
> 
> 
>> 13:23  -!- Daemon404 [~who_knows@pdpc/supporter/student/Daemon404] has
>> joined #ffmpeg-devel
>> 13:46 <@iive> and Daemon404 is back.
>>
>>
> That's a greeting, a welcoming back. You know, you're with friends, you get
> some money together, one of you goes to the store to grab a few beers, he
> comes back, "Ah, and you're back, and you bought enough beers, great.".

No, it's not a greeting or a welcoming back. It was a statement.
Now, friendly or unfriendly? I don't know. But the context doesn't
support the former option.

Still, i still think it was something that should have been ignored.

> It
> would be an attack if someone said "Ah, and you're back, and I see you
> bought the worst flavored water they sold there and kept the change.".  You
> don't walk out with the beers as soon as you hear "Ah, and you're back"
> because that someone attacked your personal choice last time you went to
> the store and this time you made some effort to find something else for
> them.
> 
> 
> 
>> That should put to rest an notion it was a friendly "welcome back".
>>
> 
> Sorry, still not seeing it as an attack. When you left, sure, but not when
> you returned.
> ___
> 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] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

On Mon, May 14, 2018 at 6:24 PM, James Almer  wrote:
> As it currently stands, the only way to enforce the CoC is with a vote,
> from a committee made from a list of ~20 devs about three or so years
> ago who may or may not still be active, and who may or may not even know
> enough about what is being voted.
> Said committee was good for a few technical decisions back in the day,
> but as soon as you introduce a vote related to developer conduct, all
> the flaws become evident. Hell, even an IRC meeting was called once, but
> then nobody wanted to touch the subject with a ten foot pole in it.

A.K.A. Nothing is enforced.

> I suppose you're talking about some months ago when you joined and iive
> said something like "oh, he's back" or some such. I personally think you
> overreacted in that situation, but i also find it odd you haven't muted
> someone you have never liked to deal with, seeing plenty other devs do it.

A little more than that, but yeah.

However, "just mute the troll/jerk/etc" is really not a valid strategy
for maintaining a healthy community. Yeah, just ignore the abuser. That's
always a great piece of advice. This is what I meant by "nothing has ever
been done".

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

>> Lies, Lies and Lies.
>
>
> I don't think it's a good thing to call a dev a liar based on limited
> available information. If you have doubts, you can express it as such, but
> don't assert doubts as truths.

Hmm... there must be some reason that people continue ad hominem
attacks even though we have a CoC... hmm.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Dave Gregory]

Hi all,

I am an engineer working at Manything (https://manything.com). We
develop software that allows users to view their security cameras over
the Internet. Thomas has been working with us to develop this mbedTLS
integration.

Thanks for your feedback on his patch; we have run some tests that I
hope will answer some of your questions. We've not been able to
produce all the detail you've requested, but hopefully what we have is
a compelling case. With some advice, I hope we could produce any other
evidence you need to support acceptance of the patch. This is our
first contribution back to FFmpeg, so we welcome guidance on how to do
the right things in the right way.

First, a bit of context on our motivation. We write software that runs on
IP cameras to connect them to our cloud service. We started off by
using GnuTLS to secure our connections but there's very limited disk
space on the cameras and the relatively large binary footprint caused
some problems. Looking around for an alternative library we discovered
mbedTLS, a project with a good open-source heritage, suitable license
terms and a major commercial backer (ARM Holdings). We were easily
able to make use of its integration with cURL but it wasn't yet
supported by the FFmpeg project, so we found Thomas via the project's
consulting page and embarked on the integration. mbedTLS is an
excellent fit for our needs; I hope this is an indicator of its potential value
to other FFmpeg users.

Below you will find our method and results. We look forward to your
feedback.

Many thanks,
Dave

--

FFmpeg TLS libraries: disk and memory footprint comparison report

Goal: Compare the memory usage and disk footprint of the new mbedTLS
integration against the three existing platform-agnostic TLS libraries
supported by FFmpeg.

Approach summary (full detail in appendix A):
 - Build FFmpeg against four TLS libraries, measure output library sizes.
- schannel (Windows) and securetransport (macOS) are excluded from
the analysis because it would be very difficult to compare results
fairly across different operating systems (and impossible on a Linux
test rig).
 - Stream well-known free video file (Big Buck Bunny) to remote rtsps
server in realtime,
collect memory statistics with valgrind/massif.
 - Interrogate massif outputs to assess relative memory consumption of
each library.

Note: The project's actual devices are mostly ARM-based but we have
found valgrind hard to run on ARM. The stats below have therefore been
created on an x86_64 box to provide memory measurements easily and
repeatably.


Results summary (full detail in appendix B):
 - GnuTLS 3.4.17
   - Peak ssl/tls/crypto-related memory allocation: 4.36MB
   - TLS library file size on disk, including dependencies: 5.5MB

 - LibreSSL 2.7.2 (libtls)
- Results
   - Peak ssl/tls/crypto-related memory allocation: 115KB
   - TLS library file size on disk, including dependencies: 3.27MB

 - mbedTLS 2.8.0
- Results
   - Peak ssl/tls/crypto-related memory allocation: 40KB
   - TLS library file size on disk, including dependencies: 828KB

 - OpenSSL 1.0.2n
- Results
   - Peak ssl/tls/crypto-related memory allocation: 151KB
   - TLS library file size on disk, including dependencies: 2.7MB

All supporting data can be downloaded from
https://assetcdn.manything.com/downloads/data/ffmpeg_tls_massif_data.tar.xz.

Conclusion: For the task of outbound interleaved RTSPS streaming,
mbedTLS uses about 35% of the memory of LibreSSL/libtls (its nearest
competitor) with only 25% of the disk footprint.


---
APPENDIX A: Test detail

Test system:
 - Linux vagrant-ubuntu-trusty-64 3.13.0-87-generic #133-Ubuntu (VM)
 - Running in virtualbox on MacBook Pro (Retina, 13-inch, Early 2015)
 - Ubuntu EGLIBC 2.19-0ubuntu6.11


Test process:
 - Compile dependencies, with configuration flags listed, and install
into custom prefix (referred to as ${DEPS_OUTDIR})
- Unless otherwise specified, steps are:
 configure --prefix=${DEPS_OUTDIR} (any extra flags specified above)
 make
 make install
 - Measure size of relevant libs
  e.g. ls -lh ${DEPS_OUTDIR}/lib/ | grep
'ssl\|crypto\|tls\|nettle\|hogweed\|gmp\|gpg\|gcrypt'
 - Compile ffmpeg against dependencies, with additional configuration
flags listed above.
  configure --prefix=${DEPS_OUTDIR} --disable-stripping
--disable-debug --enable-shared --disable-everything --enable-version3
--enable-parser=h264,hevc,aac
--enable-decoder=h264,hevc,aac,pcm_alaw,pcm_mulaw
--enable-protocol=tcp,udp,file,tls,tls_gnutls --enable-demuxer=rtsp
--enable-muxer=rtsp,mp4,mpegts,pcm_alaw,pcm_mulaw --disable-ffplay
--disable-ffprobe --disable-doc --disable-avdevice
 - Stream known free video file to remote rtsps server in realtime,
wrapped in valgrind/massif
  valgrind --tool=massif --threshold=0.1 ${DEPS_OUTDIR}/bin/ffmpeg
-re -i BigBuckBunny_320x180.mp4 -c:v copy -c:a copy -f rtsp
-rtsp_transport tcp 

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Jean-Baptiste Kempf]

Hello,

On Mon, 14 May 2018, at 19:28, Rostislav Pehlivanov wrote:

> 2's a nice option.  The recent llvm fiasco demonstrated the dangers of CoCs
> being used by the wrong people.

This is the danger with very political and very vague CoC, emphasing on 
"political correctness", like LLVM's

VideoLAN CoC is the opposite of that, and it is closer to a law (insult someone 
-> ban) than the other CoCs.
It's very precise compared to all the other CoC.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

On Mon, May 14, 2018 at 6:28 PM, Rostislav Pehlivanov
 wrote:
> iive just noticed you joined, said hi, and you left saying you were
> attacked. Since when is a normal form of welcoming back considered an
> attack? I agree with jamrial, you definitely overreacted.

If you actually believe it was a welcome back, you must be willfully
ignorant of ... well, iive. I may note I purposely was not mentioning
specific names.

Day I left:

[21:34:17 CEST]  jamrial: Derek for sure will cause more
problems, when he comes back. He will come back.

13:23  -!- Daemon404 [~who_knows@pdpc/supporter/student/Daemon404] has
joined #ffmpeg-devel
13:46 <@iive> and Daemon404 is back.

Full log here: 
http://mplayerhq.hu/pipermail/ffmpeg-devel-irc/2016-May/003572.html

That should put to rest an notion it was a friendly "welcome back".

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Dave Gregory]

> Have you considered BearSSL?
Thanks Nicolas; it sounds great but we disregarded it because the web
site declares it to be beta-quality. We will certainly keep an eye on
it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Carl Eugen Hoyos]

Hi!

Attached patch allows to easily enable the dash demuxer on systems
without pkg-config.

Please comment, Carl Eugen
From 896d75ec2c78580fbf65bc6718f205060afac215 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 14 May 2018 20:56:37 +0200
Subject: [PATCH] configure: Support libxml2 on systems without pkg-config.

---
 configure |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 6a9d516..b1fca23 100755
--- a/configure
+++ b/configure
@@ -6101,7 +6101,8 @@ enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
 enabled libzvbi   && require_pkg_config libzvbi zvbi-0.2 libzvbi.h vbi_decoder_new &&
  { test_cpp_condition libzvbi.h "VBI_VERSION_MAJOR > 0 || VBI_VERSION_MINOR > 2 || VBI_VERSION_MINOR == 2 && VBI_VERSION_MICRO >= 28" ||
enabled gpl || die "ERROR: libzvbi requires version 0.2.28 or --enable-gpl."; }
-enabled libxml2   && require_pkg_config libxml2 libxml-2.0 libxml2/libxml/xmlversion.h xmlCheckVersion
+enabled libxml2   && { check_pkg_config libxml2 libxml-2.0 libxml2/libxml/xmlversion.h xmlCheckVersion ||
+   require libxml2 "libxml/parser.h" xmlReadMemory -lxml2 $zlib_extralibs; }
 enabled mediacodec&& { enabled jni || die "ERROR: mediacodec requires --enable-jni"; }
 enabled mmal  && { check_lib mmal interface/mmal/mmal.h mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host ||
{ ! enabled cross_compile &&
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/3] hwcontext: Do not call device_init again when deriving an existing device

[Mark Thompson]

The change in 309d660775e2b47af6723a0477c4d753bc0c54f4 to call device_init
when doing derivation missed this case - we should only call it if we
actually made a new device.
---
 libavutil/hwcontext.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 70c556ecac..745016ed7e 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -646,6 +646,9 @@ int av_hwdevice_ctx_create_derived(AVBufferRef 
**dst_ref_ptr,
 ret = AVERROR(ENOMEM);
 goto fail;
 }
+ret = av_hwdevice_ctx_init(dst_ref);
+if (ret < 0)
+goto fail;
 goto done;
 }
 if (ret != AVERROR(ENOSYS))
@@ -658,10 +661,6 @@ int av_hwdevice_ctx_create_derived(AVBufferRef 
**dst_ref_ptr,
 goto fail;
 
 done:
-ret = av_hwdevice_ctx_init(dst_ref);
-if (ret < 0)
-goto fail;
-
 *dst_ref_ptr = dst_ref;
 return 0;
 
-- 
2.16.3

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

[FFmpeg-devel] [PATCH 2/3] lavu/Makefile: Fix alignment and ordering

[Mark Thompson]

---
 libavutil/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a63ba523c9..4fe470748c 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -160,14 +160,14 @@ OBJS = adler32.o  
  \
 OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
 OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
-OBJS-$(CONFIG_QSV)   += hwcontext_qsv.o
 OBJS-$(CONFIG_LIBDRM)   += hwcontext_drm.o
 OBJS-$(CONFIG_LZO)  += lzo.o
+OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
 OBJS-$(CONFIG_OPENCL)   += hwcontext_opencl.o
+OBJS-$(CONFIG_QSV)  += hwcontext_qsv.o
 OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
-OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
 
 OBJS += $(COMPAT_OBJS:%=../compat/%)
 
@@ -178,7 +178,7 @@ SKIPHEADERS-$(HAVE_CUDA_H) += hwcontext_cuda.h
 SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda_internal.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
-SKIPHEADERS-$(CONFIG_QSV)   += hwcontext_qsv.h
+SKIPHEADERS-$(CONFIG_QSV)  += hwcontext_qsv.h
 SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.h
-- 
2.16.3

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

[FFmpeg-devel] [PATCH] configure: error out on unsupported MSVC versions

[Rostislav Pehlivanov]

The FATE tests for MSVC versions older than 2013 are untested in FATE
and apparently are no longer supported.

This commit makes the configure process error out in case an older version
is used, and suggests to use a supported version of MSVC to compile.

As discussed on IRC:

2018-05-12 19:45:16 jamrial then again, most of those were for old msvc, 
and i think we're not supporting versions older than 2013 (first one c99 
compliant) anymore
2018-05-12 19:45:43 +JEEB   yea, I think 2013 update 2 is needed

22:53 <@atomnuker> nevcairiel: which commit broke/unsupported support for msvc 
2013?
23:23 <@atomnuker> okay, it was JEEB
23:25 <+JEEB> which was for 2012 and older
23:25 <+JEEB> and IIRC we no longer test those in FATE so that was my assumption
23:26 <+JEEB> 2013 is when MS got trolled enough to actually update their C part
23:26 <+JEEB> aand actually advertised FFmpeg support
23:26 <+JEEB> (although it was semi-failing until VS2013 update 1 or 2)

Signed-off-by: Rostislav Pehlivanov 
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index 1f7d0140e3..9f253834f3 100755
--- a/configure
+++ b/configure
@@ -3988,8 +3988,7 @@ case "$toolchain" in
 cc_default="cl"
 cxx_default="cl"
 else
-cc_default="c99wrap cl"
-cxx_default="c99wrap cl"
+die Unsupported MSVC version (2013 or newer required)
 fi
 ld_default="$source_path/compat/windows/mslink"
 nm_default="dumpbin -symbols"
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Rostislav Pehlivanov]

On 12 May 2018 at 20:49, Rostislav Pehlivanov  wrote:

>
>
> On 8 November 2017 at 21:26, Rostislav Pehlivanov 
> wrote:
>
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  doc/developer.texi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index a7b4f1d737..de7d887451 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{
>> .i = 17 @};});
>>  @item
>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>>
>> +@item
>> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
>> +
>>  @item
>>  Implementation defined behavior for signed integers is assumed to match
>> the
>>  expected behavior for two's complement. Non representable values in
>> integer
>> --
>> 2.15.0.403.gc27cc4dac6
>>
>>
> Ping.
> Apparently we don't support old msvc versions, so there's nothing stopping
> us from using them.
>

I'll apply this tomorrow unless there are any objections and will apply
some patches to convert some of my code to this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code (library and context) to lavu/hwcontext_amf from amfenc to be reused in other amf components

[Alexander Kravchenko]

This patch moves AMF common parts from amfenc to hwcontext_amf.
Now av_hwdevice_ctx API is used for AMF context creation/destroying.
This patch does not change component behaviour.
it contains only restructurization for further patches with new amf components

---
Sending updated patch based on Mark's review
1) moved device free code from amf_device_uninit to amf_device_free 
2) added comments for AVAMFDeviceContext structure
3) Fixed trailing whitespace warnings


 libavcodec/amfenc.c| 247 +---
 libavcodec/amfenc.h|  27 +
 libavutil/Makefile |   2 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 253 +
 libavutil/hwcontext_amf.h  |  54 +
 libavutil/hwcontext_internal.h |   1 +
 8 files changed, 350 insertions(+), 239 deletions(-)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..5a0fb90433 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -21,13 +21,7 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
-#if CONFIG_D3D11VA
-#include "libavutil/hwcontext_d3d11va.h"
-#endif
-#if CONFIG_DXVA2
-#define COBJMACROS
-#include "libavutil/hwcontext_dxva2.h"
-#endif
+
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -35,14 +29,12 @@
 #include "amfenc.h"
 #include "internal.h"
 
-#if CONFIG_D3D11VA
-#include 
+#if CONFIG_DXVA2
+#include 
 #endif
 
-#ifdef _WIN32
-#include "compat/w32dlfcn.h"
-#else
-#include 
+#if CONFIG_D3D11VA
+#include 
 #endif
 
 #define FFMPEG_AMF_WRITER_ID L"ffmpeg_amf"
@@ -88,34 +80,18 @@ static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum 
AVPixelFormat fmt)
 return AMF_SURFACE_UNKNOWN;
 }
 
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
 
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
+static int amf_init_context(AVCodecContext *avctx)
 {
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
+AmfContext *ctx = avctx->priv_data;
+AVAMFDeviceContext *amf_ctx;
+int ret;
 
 ctx->delayed_frame = av_frame_alloc();
 if (!ctx->delayed_frame) {
 return AVERROR(ENOMEM);
 }
+
 // hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
 ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
 if (!ctx->timestamp_list) {
@@ -123,119 +99,9 @@ static int amf_load_library(AVCodecContext *avctx)
 }
 ctx->dts_delay = 0;
 
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(>version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, >factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported 

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Mark Thompson]

On 14/05/18 22:38, Rostislav Pehlivanov wrote:
> On 12 May 2018 at 20:49, Rostislav Pehlivanov  wrote:
>> On 8 November 2017 at 21:26, Rostislav Pehlivanov 
>> wrote:
>>
>>> Signed-off-by: Rostislav Pehlivanov 
>>> ---
>>>  doc/developer.texi | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/doc/developer.texi b/doc/developer.texi
>>> index a7b4f1d737..de7d887451 100644
>>> --- a/doc/developer.texi
>>> +++ b/doc/developer.texi
>>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{
>>> .i = 17 @};});
>>>  @item
>>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>>>
>>> +@item
>>> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
>>> +
>>>  @item
>>>  Implementation defined behavior for signed integers is assumed to match
>>> the
>>>  expected behavior for two's complement. Non representable values in
>>> integer
>>> --
>>> 2.15.0.403.gc27cc4dac6
>>>
>>>
>> Ping.
>> Apparently we don't support old msvc versions, so there's nothing stopping
>> us from using them.
>>
> 
> I'll apply this tomorrow unless there are any objections and will apply
> some patches to convert some of my code to this.

On 08/11/17 23:05, Mark Thompson wrote:
> Before continuing with this patch I think you should at least:
> * Have some idea what platforms are affected.
> * Investigate whether these platforms have any significant user base (maybe 
> ask the user mailing lists, at least).
> * Propose a patch to configure which either removes support for them or 
> somehow disables them (e.g. it could test-compile a loop including a 
> declaration).

Are these done?

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

[FFmpeg-devel] [PATCH v6 2/3] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

From: Damien Riegel 

This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.

There is no mechanism for interlaced frames reconstruction at the rtp
demux level, so it has to be handled by the codec which needs to
partially recompose an AVFrame with every incoming field AVPacket.
A frame is ouput only when the frame is completed with the 2nd field
(bottom).

The additionnal field flags in AVPacket allow the decoder to dynamically
determine the frame format, i.e. progressive or interlaced.

Signed-off-by: Patrick Keroulas 
Signed-off-by: Damien Riegel 
---

Changes v5 -> v6:
 * cleanup
 * move the packet flags in a separate patch
 * bump lavc minor version in this new patch
---
 libavcodec/bitpacked.c | 122 +
 1 file changed, 103 insertions(+), 19 deletions(-)

diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..4157876 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -32,8 +32,9 @@
 #include "libavutil/imgutils.h"
 
 struct BitpackedContext {
-int (*decode)(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *pkt);
+int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt);
+AVFrame *cur_interlaced_frame;
+int prev_top_field;
 };
 
 /* For this format, it's a simple passthrough */
@@ -58,27 +59,41 @@ static int bitpacked_decode_uyvy422(AVCodecContext *avctx, 
AVFrame *frame,
 static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame *frame,
   AVPacket *avpkt)
 {
-uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
+uint64_t frame_size = avctx->width * avctx->height * 20LL;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
+int top_field = (avpkt->flags & AV_PKT_FLAG_TOP_FIELD) ? 1 : 0;
 GetBitContext bc;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
-
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size / 2) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
 return AVERROR_INVALIDDATA;
+}
 
 if (avctx->width % 2)
 return AVERROR_PATCHWELCOME;
 
-ret = init_get_bits(, avpkt->data, avctx->width * avctx->height * 20);
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
+
+ret = init_get_bits(, avpkt->data, frame_size);
 if (ret)
 return ret;
 
-for (i = 0; i < avctx->height; i++) {
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; i += 1 + interlaced) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -103,17 +118,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext 
*avctx)
 
 if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
 if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for 
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
 bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sample == 20 &&
- avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
+} else if (avctx->bits_per_coded_sample == 20 &&
+ avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
 bc->decode = bitpacked_decode_yuv422p10;
-else
+} else {
 return AVERROR_INVALIDDATA;
+}
 } else {
 return AVERROR_INVALIDDATA;
 }
 
+bc->cur_interlaced_frame = av_frame_alloc();
+
+return 0;
+}
+
+static av_cold int bitpacked_end_decoder(AVCodecContext *avctx)
+{
+struct BitpackedContext *bc = avctx->priv_data;
+
+av_frame_free(>cur_interlaced_frame);
+
 return 0;
 }
 
@@ -128,13 +161,63 @@ static int bitpacked_decode(AVCodecContext *avctx, void 
*data, int *got_frame,
 frame->pict_type 

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Mark Thompson]

On 14/05/18 23:30, Rostislav Pehlivanov wrote:
> On 14 May 2018 at 22:57, Mark Thompson  wrote:
>> On 14/05/18 22:38, Rostislav Pehlivanov wrote:
>>> On 12 May 2018 at 20:49, Rostislav Pehlivanov 
>> wrote:
 On 8 November 2017 at 21:26, Rostislav Pehlivanov 
 wrote:

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  doc/developer.texi | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index a7b4f1d737..de7d887451 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x =
>> @{
> .i = 17 @};});
>  @item
>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>
> +@item
> +for loops with variable definition (@samp{for (int i = 0; i < 8;
>> i++)});
> +
>  @item
>  Implementation defined behavior for signed integers is assumed to
>> match
> the
>  expected behavior for two's complement. Non representable values in
> integer
> --
> 2.15.0.403.gc27cc4dac6
>
>
 Ping.
 Apparently we don't support old msvc versions, so there's nothing
>> stopping
 us from using them.

>>>
>>> I'll apply this tomorrow unless there are any objections and will apply
>>> some patches to convert some of my code to this.
>>
>> On 08/11/17 23:05, Mark Thompson wrote:
>>> Before continuing with this patch I think you should at least:
>>> * Have some idea what platforms are affected.
>>> * Investigate whether these platforms have any significant user base
>> (maybe ask the user mailing lists, at least).
>>> * Propose a patch to configure which either removes support for them or
>> somehow disables them (e.g. it could test-compile a loop including a
>> declaration).
>>
>> Are these done?
>>
> 
> Yes, the only platforms mentioned were MSVC versions older than 2013, which
> are unsupported as of recent.

Do you have a link to this discussion?  I'm not sure I've seen it.

Where can I find the configure patch?

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Hendrik Leppkes]

On Tue, May 15, 2018 at 12:30 AM, Rostislav Pehlivanov
 wrote:
> On 14 May 2018 at 22:57, Mark Thompson  wrote:
>
>> On 14/05/18 22:38, Rostislav Pehlivanov wrote:
>> > On 12 May 2018 at 20:49, Rostislav Pehlivanov 
>> wrote:
>> >> On 8 November 2017 at 21:26, Rostislav Pehlivanov 
>> >> wrote:
>> >>
>> >>> Signed-off-by: Rostislav Pehlivanov 
>> >>> ---
>> >>>  doc/developer.texi | 3 +++
>> >>>  1 file changed, 3 insertions(+)
>> >>>
>> >>> diff --git a/doc/developer.texi b/doc/developer.texi
>> >>> index a7b4f1d737..de7d887451 100644
>> >>> --- a/doc/developer.texi
>> >>> +++ b/doc/developer.texi
>> >>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x =
>> @{
>> >>> .i = 17 @};});
>> >>>  @item
>> >>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>> >>>
>> >>> +@item
>> >>> +for loops with variable definition (@samp{for (int i = 0; i < 8;
>> i++)});
>> >>> +
>> >>>  @item
>> >>>  Implementation defined behavior for signed integers is assumed to
>> match
>> >>> the
>> >>>  expected behavior for two's complement. Non representable values in
>> >>> integer
>> >>> --
>> >>> 2.15.0.403.gc27cc4dac6
>> >>>
>> >>>
>> >> Ping.
>> >> Apparently we don't support old msvc versions, so there's nothing
>> stopping
>> >> us from using them.
>> >>
>> >
>> > I'll apply this tomorrow unless there are any objections and will apply
>> > some patches to convert some of my code to this.
>>
>> On 08/11/17 23:05, Mark Thompson wrote:
>> > Before continuing with this patch I think you should at least:
>> > * Have some idea what platforms are affected.
>> > * Investigate whether these platforms have any significant user base
>> (maybe ask the user mailing lists, at least).
>> > * Propose a patch to configure which either removes support for them or
>> somehow disables them (e.g. it could test-compile a loop including a
>> declaration).
>>
>> Are these done?
>>
>
> Yes, the only platforms mentioned were MSVC versions older than 2013, which
> are unsupported as of recent.

How is that? MSVC 2013 still works mostly fine (short of one test
where the Unicode handling is a bit weird, and noone bothered to work
around it).

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Rostislav Pehlivanov]

On 14 May 2018 at 23:59, Hendrik Leppkes  wrote:

> On Tue, May 15, 2018 at 12:30 AM, Rostislav Pehlivanov
>  wrote:
> > On 14 May 2018 at 22:57, Mark Thompson  wrote:
> >
> >> On 14/05/18 22:38, Rostislav Pehlivanov wrote:
> >> > On 12 May 2018 at 20:49, Rostislav Pehlivanov 
> >> wrote:
> >> >> On 8 November 2017 at 21:26, Rostislav Pehlivanov <
> atomnu...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Signed-off-by: Rostislav Pehlivanov 
> >> >>> ---
> >> >>>  doc/developer.texi | 3 +++
> >> >>>  1 file changed, 3 insertions(+)
> >> >>>
> >> >>> diff --git a/doc/developer.texi b/doc/developer.texi
> >> >>> index a7b4f1d737..de7d887451 100644
> >> >>> --- a/doc/developer.texi
> >> >>> +++ b/doc/developer.texi
> >> >>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s
> x =
> >> @{
> >> >>> .i = 17 @};});
> >> >>>  @item
> >> >>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
> >> >>>
> >> >>> +@item
> >> >>> +for loops with variable definition (@samp{for (int i = 0; i < 8;
> >> i++)});
> >> >>> +
> >> >>>  @item
> >> >>>  Implementation defined behavior for signed integers is assumed to
> >> match
> >> >>> the
> >> >>>  expected behavior for two's complement. Non representable values in
> >> >>> integer
> >> >>> --
> >> >>> 2.15.0.403.gc27cc4dac6
> >> >>>
> >> >>>
> >> >> Ping.
> >> >> Apparently we don't support old msvc versions, so there's nothing
> >> stopping
> >> >> us from using them.
> >> >>
> >> >
> >> > I'll apply this tomorrow unless there are any objections and will
> apply
> >> > some patches to convert some of my code to this.
> >>
> >> On 08/11/17 23:05, Mark Thompson wrote:
> >> > Before continuing with this patch I think you should at least:
> >> > * Have some idea what platforms are affected.
> >> > * Investigate whether these platforms have any significant user base
> >> (maybe ask the user mailing lists, at least).
> >> > * Propose a patch to configure which either removes support for them
> or
> >> somehow disables them (e.g. it could test-compile a loop including a
> >> declaration).
> >>
> >> Are these done?
> >>
> >
> > Yes, the only platforms mentioned were MSVC versions older than 2013,
> which
> > are unsupported as of recent.
>
> How is that? MSVC 2013 still works mostly fine (short of one test
> where the Unicode handling is a bit weird, and noone bothered to work
> around it).
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

MSVC 2013 is still perfectly supported and tested, this is for versions
older than that (when they didn't have proper C99 support).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Rostislav Pehlivanov]

On 14 May 2018 at 22:57, Mark Thompson  wrote:

> On 14/05/18 22:38, Rostislav Pehlivanov wrote:
> > On 12 May 2018 at 20:49, Rostislav Pehlivanov 
> wrote:
> >> On 8 November 2017 at 21:26, Rostislav Pehlivanov 
> >> wrote:
> >>
> >>> Signed-off-by: Rostislav Pehlivanov 
> >>> ---
> >>>  doc/developer.texi | 3 +++
> >>>  1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/doc/developer.texi b/doc/developer.texi
> >>> index a7b4f1d737..de7d887451 100644
> >>> --- a/doc/developer.texi
> >>> +++ b/doc/developer.texi
> >>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x =
> @{
> >>> .i = 17 @};});
> >>>  @item
> >>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
> >>>
> >>> +@item
> >>> +for loops with variable definition (@samp{for (int i = 0; i < 8;
> i++)});
> >>> +
> >>>  @item
> >>>  Implementation defined behavior for signed integers is assumed to
> match
> >>> the
> >>>  expected behavior for two's complement. Non representable values in
> >>> integer
> >>> --
> >>> 2.15.0.403.gc27cc4dac6
> >>>
> >>>
> >> Ping.
> >> Apparently we don't support old msvc versions, so there's nothing
> stopping
> >> us from using them.
> >>
> >
> > I'll apply this tomorrow unless there are any objections and will apply
> > some patches to convert some of my code to this.
>
> On 08/11/17 23:05, Mark Thompson wrote:
> > Before continuing with this patch I think you should at least:
> > * Have some idea what platforms are affected.
> > * Investigate whether these platforms have any significant user base
> (maybe ask the user mailing lists, at least).
> > * Propose a patch to configure which either removes support for them or
> somehow disables them (e.g. it could test-compile a loop including a
> declaration).
>
> Are these done?
>

Yes, the only platforms mentioned were MSVC versions older than 2013, which
are unsupported as of recent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mpegts: add merge_pmt_versions option

[Aman Gupta]

From: Aman Gupta 

This new optional flag makes it easier to deal with mpegts
samples where the PMT is updated and elementary streams move
to different PIDs in the middle of playback.

Previously, new AVStreams were created per PID, and it was up
to the user to figure out which streams had migrated to a new PID
(by iterating over the list of AVProgram and making guesses), and
switch seamlessly to the new AVStream during playback.

Transcoding or remuxing these streams with ffmpeg on the CLI was
also quite painful, and the user would need to extract each set of
PIDs into a separate file and then stitch them back together.

With this new option, the mpegts demuxer will automatically detect
PMT changes and feed data from the new PID to the original AVStream
that was created for the orignal PID. For mpegts samples with
stream_identifier_descriptor available, the unique ID is used to merge
PIDs together. If the stream id is not available, the demuxer attempts
to map PIDs based on their order and relation to the PCR pid.

With this change, I am able to playback and transcode/remux these
two samples which previously caused issues:

https://tmm1.s3.amazonaws.com/pmt-version-change.ts
https://kuroko.fushizen.eu/videos/pid_switch_sample.ts

I also have another longer sample which contains multiple PMT
changes, some of which change the ES pids and others which do not:

https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts

Demuxing this sample with the new option shows several new log
messages as the PMT changes are handled:

[mpegts @ 0x7ffe18801200] detected PMT change (version=3/4, 
pcr_pid=0xf98/0xf9b)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for 
new pid=0xf9b
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for 
new pid=0xf9c
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for 
new pid=0xf9d
[mpegts @ 0x7ffe18801200] detected PMT change (version=4/5, 
pcr_pid=0xf9b/0xfa9)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for 
new pid=0xfa9
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for 
new pid=0xfaa
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for 
new pid=0xfab

Signed-off-by: Aman Gupta 
---
 doc/demuxers.texi|   4 ++
 libavformat/mpegts.c | 105 +--
 2 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e7c2abce57..2f7d7e0f3a 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -552,6 +552,10 @@ Show the detected raw packet size, cannot be set by the 
user.
 Scan and combine all PMTs. The value is an integer with value from -1
 to 1 (-1 means automatic setting, 1 means enabled, 0 means
 disabled). Default value is -1.
+
+@item merge_pmt_versions
+Re-use existing streams when a PMT's version is updated and elementary
+streams move to different PIDs. Default value is 0.
 @end table
 
 @section mpjpeg
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 27b1c30a44..c42e564a7e 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -84,6 +84,8 @@ typedef struct MpegTSSectionFilter {
 unsigned int end_of_section_reached : 1;
 SectionCallback *section_cb;
 void *opaque;
+int orig_pcr_pid; /* pmt specific */
+int last_pcr_pid;
 } MpegTSSectionFilter;
 
 struct MpegTSFilter {
@@ -147,6 +149,7 @@ struct MpegTSContext {
 int scan_all_pmts;
 
 int resync_size;
+int merge_pmt_versions;
 
 /**/
 /* private mpegts data */
@@ -172,6 +175,8 @@ static const AVOption options[] = {
  {.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT | 
AV_OPT_FLAG_READONLY },
 {"scan_all_pmts", "scan and combine all PMTs", offsetof(MpegTSContext, 
scan_all_pmts), AV_OPT_TYPE_BOOL,
  {.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
+{"merge_pmt_versions", "re-use streams when PMT's version/pids change", 
offsetof(MpegTSContext, merge_pmt_versions), AV_OPT_TYPE_BOOL,
+ {.i64 = 0}, 0, 1,  AV_OPT_FLAG_DECODING_PARAM },
 {"skip_changes", "skip changing / adding streams / programs", 
offsetof(MpegTSContext, skip_changes), AV_OPT_TYPE_BOOL,
  {.i64 = 0}, 0, 1, 0 },
 {"skip_clear", "skip clearing programs", offsetof(MpegTSContext, 
skip_clear), AV_OPT_TYPE_BOOL,
@@ -1073,7 +1078,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
 if (ts->skip_changes)
 goto skip;
 
-pes->st = avformat_new_stream(ts->stream, NULL);
+if (!pes->st)
+pes->st = avformat_new_stream(ts->stream, NULL);
 if (!pes->st)
 return AVERROR(ENOMEM);
 pes->st->id = pes->pid;
@@ -1982,6 +1988,68 @@ int 

Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

[Jacob Trimble]

On Tue, May 8, 2018 at 3:47 PM, Michael Niedermayer
 wrote:
> On Mon, May 07, 2018 at 04:59:33PM -0700, Jacob Trimble wrote:
>> On Mon, May 7, 2018 at 3:18 PM, Michael Niedermayer
>>  wrote:
>> > On Mon, Apr 23, 2018 at 11:03:57AM -0700, Jacob Trimble wrote:
>> >> While integrating my encryption info changes, I noticed a problem with
>> >> the init info structs.  I implemented them as side-data on the Stream.
>> >> But this means there can only be one per stream.  However, there can
>> >> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
>> >> multiple key systems). (sorry for not noticing sooner)
>> >>
>> >> Attached is a patch to fix this by making the init info a
>> >> singly-linked-list.  It is ABI compatible and is still easy to use and
>> >> understand.  The alternative would be to break ABI and have the
>> >> side-data methods return an array of pointers.  I could do that
>> >> instead if that is preferable.
>> >
>> >>  encryption_info.c |  154 
>> >> +++---
>> >>  encryption_info.h |5 +
>> >>  2 files changed, 106 insertions(+), 53 deletions(-)
>> >> e5eecc73a6997bbd11541771372d38ea9c3972a7  
>> >> 0001-libavutil-encryption_info-Allow-multiple-init-info.patch
>> >> From bb941a77e882e93629d63d63059d0063b9519e29 Mon Sep 17 00:00:00 2001
>> >> From: Jacob Trimble 
>> >> Date: Mon, 23 Apr 2018 10:33:58 -0700
>> >> Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.
>> >>
>> >> It is possible for there to be multiple encryption init info structure.
>> >> For example, to support multiple key systems or in key rotation.  This
>> >> changes the AVEncryptionInitInfo struct to be a linked list so there
>> >> can be multiple structs without breaking ABI.
>> >>
>> >> Signed-off-by: Jacob Trimble 
>> >> ---
>> >>  libavutil/encryption_info.c | 154 +++-
>> >>  libavutil/encryption_info.h |   5 ++
>> >>  2 files changed, 106 insertions(+), 53 deletions(-)
>> >>
>> >> diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
>> >> index 20a752d6b4..9935c10d74 100644
>> >> --- a/libavutil/encryption_info.c
>> >> +++ b/libavutil/encryption_info.c
>> >> @@ -160,13 +160,16 @@ uint8_t *av_encryption_info_add_side_data(const 
>> >> AVEncryptionInfo *info, size_t *
>> >>  }
>> >>
>> >>  // The format of the AVEncryptionInitInfo side data:
>> >> -// u32be system_id_size
>> >> -// u32be num_key_ids
>> >> -// u32be key_id_size
>> >> -// u32be data_size
>> >> -// u8[system_id_size] system_id
>> >> -// u8[key_id_size][num_key_id] key_ids
>> >> -// u8[data_size] data
>> >> +// u32be init_info_count
>> >> +// {
>> >> +//   u32be system_id_size
>> >> +//   u32be num_key_ids
>> >> +//   u32be key_id_size
>> >> +//   u32be data_size
>> >> +//   u8[system_id_size] system_id
>> >> +//   u8[key_id_size][num_key_id] key_ids
>> >> +//   u8[data_size] data
>> >> +// }[init_info_count]
>> >>
>> >>  #define FF_ENCRYPTION_INIT_INFO_EXTRA 16
>> >>
>> >> @@ -215,6 +218,7 @@ void 
>> >> av_encryption_init_info_free(AVEncryptionInitInfo *info)
>> >>  for (i = 0; i < info->num_key_ids; i++) {
>> >>  av_free(info->key_ids[i]);
>> >>  }
>> >> +av_encryption_init_info_free(info->next);
>> >>  av_free(info->system_id);
>> >>  av_free(info->key_ids);
>> >>  av_free(info->data);
>> >> @@ -225,71 +229,115 @@ void 
>> >> av_encryption_init_info_free(AVEncryptionInitInfo *info)
>> >>  AVEncryptionInitInfo *av_encryption_init_info_get_side_data(
>> >>  const uint8_t *side_data, size_t side_data_size)
>> >>  {
>> >> -AVEncryptionInitInfo *info;
>> >> +AVEncryptionInitInfo *ret = NULL, *info;
>> >>  uint64_t system_id_size, num_key_ids, key_id_size, data_size, i;
>> >> +uint64_t init_info_count;
>> >>
>> >> -if (!side_data || side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA)
>> >> -return NULL;
>> >> -
>> >> -system_id_size = AV_RB32(side_data);
>> > [...]
>> >> +init_info_count = AV_RB32(side_data);
>> >
>> > i may be missing something but this looks like the meaning of the first
>> > field changes, this thus doesnt look compatible to me
>>
>> It changes the binary format of the side-data, but that was explicitly
>> not part of ABI.  The fields in the structs are unchanged.  This would
>> only cause a problem if the side data bytes were stored out-of-band
>> from a different version of FFmpeg.
>
> yes, right.
> its side data that is neighter a C struct nor a well defined byte stream
> its a opaque block that can only be passed to libavutil which then translates
> it into a C struct.
> its not new but it still feels clumsy to use this as means to pass data around
>

I know it's weird, but this was the design that was decided on when
this was added.  Are there any changes you want for this patch?

>
> [...]
> --
> Michael GnuPG 

[FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: fix YUV420P cuda_get_buffer

[Marton Balint]

Regression since ece068a771ac3f725e854c681ecbef08e792addc.

Signed-off-by: Marton Balint 
---
 libavutil/hwcontext_cuda.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index cb5d15c9d9..e16d0a2b4b 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -159,10 +159,13 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, 
AVFrame *frame)
 return res;
 
 // YUV420P is a special case.
-// Nvenc expects the U/V planes in swapped order from how ffmpeg expects 
them.
+// Nvenc expects the U/V planes in swapped order from how ffmpeg expects 
them, also chroma is half-aligned
 if (ctx->sw_format == AV_PIX_FMT_YUV420P) {
-FFSWAP(uint8_t*, frame->data[1], frame->data[2]);
-FFSWAP(int, frame->linesize[1], frame->linesize[2]);
+int aligned_width = FFALIGN(ctx->width, CUDA_FRAME_ALIGNMENT);
+frame->data[2] = frame->data[0] + aligned_width * ctx->height;
+frame->data[1] = frame->data[2] + aligned_width * ctx->height / 4;
+frame->linesize[1] = aligned_width / 2;
+frame->linesize[2] = aligned_width / 2;
 }
 
 frame->format = AV_PIX_FMT_CUDA;
-- 
2.13.6

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

[FFmpeg-devel] [PATCH 3/3] hwcontext: Add test for device creation and derivation

[Mark Thompson]

This uses any devices it can find on the host system - on a system with no
hardware device support or in builds with no support included it will do
nothing and pass.
---
 libavutil/Makefile |   1 +
 libavutil/tests/hwdevice.c | 234 +
 tests/fate/libavutil.mak   |   4 +
 tests/ref/fate/hwdevice|   1 +
 4 files changed, 240 insertions(+)
 create mode 100644 libavutil/tests/hwdevice.c
 create mode 100644 tests/ref/fate/hwdevice

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 4fe470748c..d0632f16a6 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -206,6 +206,7 @@ TESTPROGS = adler32 
\
 fifo\
 hash\
 hmac\
+hwdevice\
 integer \
 imgutils\
 lfg \
diff --git a/libavutil/tests/hwdevice.c b/libavutil/tests/hwdevice.c
new file mode 100644
index 00..a14c4be8a4
--- /dev/null
+++ b/libavutil/tests/hwdevice.c
@@ -0,0 +1,234 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/hwcontext.h"
+
+static int test_derivation(AVBufferRef *src_ref, const char *src_name)
+{
+enum AVHWDeviceType derived_type;
+const char *derived_name;
+AVBufferRef *derived_ref, *back_ref;
+AVHWDeviceContext *src_dev, *derived_dev;
+int err;
+
+src_dev = (AVHWDeviceContext*)src_ref->data;
+
+derived_type = AV_HWDEVICE_TYPE_NONE;
+while (1) {
+derived_type = av_hwdevice_iterate_types(derived_type);
+if (derived_type == AV_HWDEVICE_TYPE_NONE)
+break;
+
+derived_name = av_hwdevice_get_type_name(derived_type);
+
+err = av_hwdevice_ctx_create_derived(_ref, derived_type,
+ src_ref, 0);
+if (err < 0) {
+fprintf(stderr, "Unable to derive %s -> %s: %d.\n",
+src_name, derived_name, err);
+continue;
+}
+
+derived_dev = (AVHWDeviceContext*)derived_ref->data;
+if (derived_dev->type != derived_type) {
+printf("Device derived as type %d has type %d.\n",
+   derived_type, derived_dev->type);
+goto fail;
+}
+
+if (derived_type == src_dev->type) {
+if (derived_dev != src_dev) {
+printf("Derivation of %s from itself succeeded but did "
+   "not return the same device.\n", src_name);
+goto fail;
+}
+av_buffer_unref(_ref);
+continue;
+}
+
+err = av_hwdevice_ctx_create_derived(_ref, src_dev->type,
+ derived_ref, 0);
+if (err < 0) {
+printf("Derivation %s to %s succeeded, but derivation back "
+   "again failed: %d.\n", src_name, derived_name, err);
+goto fail;
+}
+
+if (back_ref->data != src_ref->data) {
+printf("Derivation %s to %s succeeded, but derivation back "
+   "again did not return the original device.\n",
+   src_name, derived_name);
+goto fail;
+}
+
+fprintf(stderr, "Successfully tested derivation %s -> %s.\n",
+src_name, derived_name);
+
+av_buffer_unref(_ref);
+av_buffer_unref(_ref);
+}
+
+return 0;
+
+fail:
+av_buffer_unref(_ref);
+av_buffer_unref(_ref);
+return -1;
+}
+
+static int test_device(enum AVHWDeviceType type, const char *name,
+   const char *device, AVDictionary *opts, int flags)
+{
+AVBufferRef *ref;
+AVHWDeviceContext *dev;
+int err;
+
+err = av_hwdevice_ctx_create(, type, device, opts, flags);
+if (err < 0) {
+fprintf(stderr, "Failed to create %s device: 

[FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Patrick Keroulas]

Signed-off-by: Patrick Keroulas 
---
 doc/APIchanges   | 3 +++
 libavcodec/avcodec.h | 8 
 libavcodec/version.h | 4 ++--
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index bbefc83..d06868e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavc 58.20.100 - avcodec.h
+  Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
+
 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
   Add AVCUDADeviceContext.stream.
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fa..14811be 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1480,6 +1480,14 @@ typedef struct AVPacket {
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
 
+/**
+ * The packet contains a top field.
+ */
+#define AV_PKT_FLAG_TOP_FIELD  0x0020
+/**
+ * The packet contains a bottom field.
+ */
+#define AV_PKT_FLAG_BOTTOM_FIELD  0x0040
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 3fda743..b9752ce 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  19
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR  20
+#define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v6 3/3] avformat/rtpdec_rfc4175: handle interlace format

[Patrick Keroulas]

From: Damien Riegel 

In order to handle the interlaced formats, the demuxer has only a few
things to do:
 - parse the SDP correctly and propagate the information
 - check the field bit in the RFC4175 header, and pass that information
   to the decoder

In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.

Signed-off-by: Damien Riegel 
Signed-off-by: Patrick Keroulas 
---
 libavformat/rtpdec_rfc4175.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..9dc7b29 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -31,6 +31,8 @@ struct PayloadContext {
 int depth;
 int width;
 int height;
+int interlaced;
+int field;
 
 uint8_t *frame;
 unsigned int frame_size;
@@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream, 
PayloadContext *data)
 return AVERROR_INVALIDDATA;
 }
 
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
 stream->codecpar->format = pixfmt;
 stream->codecpar->codec_tag = tag;
 stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup / 
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup / 
data->xinc;
 
 return 0;
 }
@@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream 
*stream,
 data->sampling = av_strdup(value);
 else if (!strncmp(attr, "depth", 5))
 data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
 
 return 0;
 }
@@ -131,7 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext *data, 
AVPacket *pkt,
av_freep(>frame);
}
 
+   /* In the packet header, the field is set to 0 for top field
+* and 1 for bottom */
+if (data->interlaced)
+pkt->flags |= data->field ? AV_PKT_FLAG_BOTTOM_FIELD : 
AV_PKT_FLAG_TOP_FIELD;
+
data->frame = NULL;
+   data->field = 0;
 
return ret;
 }
@@ -141,7 +159,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
  const uint8_t * buf, int len,
  uint16_t seq, int flags)
 {
-int length, line, offset, cont;
+int length, line, offset, cont, field;
 const uint8_t *headers = buf + 2; /* skip extended seqnum */
 const uint8_t *payload = buf + 2;
 int payload_len = len - 2;
@@ -194,11 +212,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 return AVERROR_INVALIDDATA;
 
 length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
 line = ((headers[2] & 0x7f) << 8) | headers[3];
 offset = ((headers[4] & 0x7f) << 8) | headers[5];
 cont = headers[4] & 0x80;
 headers += 6;
 
+data->field = field;
+
 if (length % data->pgroup)
 return AVERROR_INVALIDDATA;
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] configure: error out on unsupported MSVC versions

[Michael Niedermayer]

On Tue, May 15, 2018 at 12:57:00AM +0100, Rostislav Pehlivanov wrote:
> The FATE tests for MSVC versions older than 2013 are untested in FATE
> and apparently are no longer supported.
> 
> This commit makes the configure process error out in case an older version
> is used, and suggests to use a supported version of MSVC to compile.
> 
> As discussed on IRC:
> 
> 2018-05-12 19:45:16 jamrial then again, most of those were for old msvc, 
> and i think we're not supporting versions older than 2013 (first one c99 
> compliant) anymore
> 2018-05-12 19:45:43 +JEEB   yea, I think 2013 update 2 is needed
> 
> 22:53 <@atomnuker> nevcairiel: which commit broke/unsupported support for 
> msvc 2013?
> 23:23 <@atomnuker> okay, it was JEEB
> 23:25 <+JEEB> which was for 2012 and older
> 23:25 <+JEEB> and IIRC we no longer test those in FATE so that was my 
> assumption
> 23:26 <+JEEB> 2013 is when MS got trolled enough to actually update their C 
> part
> 23:26 <+JEEB> aand actually advertised FFmpeg support
> 23:26 <+JEEB> (although it was semi-failing until VS2013 update 1 or 2)
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 1f7d0140e3..9f253834f3 100755
> --- a/configure
> +++ b/configure
> @@ -3988,8 +3988,7 @@ case "$toolchain" in
>  cc_default="cl"
>  cxx_default="cl"
>  else
> -cc_default="c99wrap cl"
> -cxx_default="c99wrap cl"
> +die Unsupported MSVC version (2013 or newer required)
>  fi
>  ld_default="$source_path/compat/windows/mslink"
>  nm_default="dumpbin -symbols"

breaks configire

./configure
./configure: 3990: ./configure: Syntax error: "(" unexpected (expecting "fi")

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH 3/3] hwcontext: Add test for device creation and derivation

[Xiang, Haihao]

On Mon, 2018-05-14 at 22:58 +0100, Mark Thompson wrote:
> This uses any devices it can find on the host system - on a system with no
> hardware device support or in builds with no support included it will do
> nothing and pass.
> ---
>  libavutil/Makefile |   1 +
>  libavutil/tests/hwdevice.c | 234
> +
>  tests/fate/libavutil.mak   |   4 +
>  tests/ref/fate/hwdevice|   1 +
>  4 files changed, 240 insertions(+)
>  create mode 100644 libavutil/tests/hwdevice.c
>  create mode 100644 tests/ref/fate/hwdevice
> 
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 4fe470748c..d0632f16a6 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -206,6 +206,7 @@ TESTPROGS =
> adler32 \
>  fifo\
>  hash\
>  hmac\
> +hwdevice\
>  integer \
>  imgutils\
>  lfg \
> diff --git a/libavutil/tests/hwdevice.c b/libavutil/tests/hwdevice.c
> new file mode 100644
> index 00..a14c4be8a4
> --- /dev/null
> +++ b/libavutil/tests/hwdevice.c
> @@ -0,0 +1,234 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include 
> +
> +#include "libavutil/hwcontext.h"
> +
> +static int test_derivation(AVBufferRef *src_ref, const char *src_name)
> +{
> +enum AVHWDeviceType derived_type;
> +const char *derived_name;
> +AVBufferRef *derived_ref, *back_ref;
> +AVHWDeviceContext *src_dev, *derived_dev;
> +int err;
> +
> +src_dev = (AVHWDeviceContext*)src_ref->data;
> +
> +derived_type = AV_HWDEVICE_TYPE_NONE;
> +while (1) {
> +derived_type = av_hwdevice_iterate_types(derived_type);
> +if (derived_type == AV_HWDEVICE_TYPE_NONE)
> +break;
> +
> +derived_name = av_hwdevice_get_type_name(derived_type);
> +
> +err = av_hwdevice_ctx_create_derived(_ref, derived_type,
> + src_ref, 0);
> +if (err < 0) {
> +fprintf(stderr, "Unable to derive %s -> %s: %d.\n",
> +src_name, derived_name, err);
> +continue;
> +}
> +
> +derived_dev = (AVHWDeviceContext*)derived_ref->data;
> +if (derived_dev->type != derived_type) {
> +printf("Device derived as type %d has type %d.\n",
> +   derived_type, derived_dev->type);

back_ref might not be initialized in the error handling path,

> +goto fail;
> +}
> +
> +if (derived_type == src_dev->type) {
> +if (derived_dev != src_dev) {
> +printf("Derivation of %s from itself succeeded but did "
> +   "not return the same device.\n", src_name);

Same as above. 

> +goto fail;
> +}
> +av_buffer_unref(_ref);
> +continue;
> +}
> +
> +err = av_hwdevice_ctx_create_derived(_ref, src_dev->type,
> + derived_ref, 0);
> +if (err < 0) {
> +printf("Derivation %s to %s succeeded, but derivation back "
> +   "again failed: %d.\n", src_name, derived_name, err);
> +goto fail;
> +}
> +
> +if (back_ref->data != src_ref->data) {
> +printf("Derivation %s to %s succeeded, but derivation back "
> +   "again did not return the original device.\n",
> +   src_name, derived_name);
> +goto fail;
> +}
> +
> +fprintf(stderr, "Successfully tested derivation %s -> %s.\n",
> +src_name, derived_name);
> +
> +av_buffer_unref(_ref);
> +av_buffer_unref(_ref);
> +}
> +
> +return 0;
> +
> +fail:
> +av_buffer_unref(_ref);
> +

Re: [FFmpeg-devel] [PATCH 3/3] hwcontext: Add test for device creation and derivation

[Michael Niedermayer]

On Mon, May 14, 2018 at 10:58:58PM +0100, Mark Thompson wrote:
> This uses any devices it can find on the host system - on a system with no
> hardware device support or in builds with no support included it will do
> nothing and pass.
> ---
>  libavutil/Makefile |   1 +
>  libavutil/tests/hwdevice.c | 234 
> +
>  tests/fate/libavutil.mak   |   4 +
>  tests/ref/fate/hwdevice|   1 +
>  4 files changed, 240 insertions(+)
>  create mode 100644 libavutil/tests/hwdevice.c
>  create mode 100644 tests/ref/fate/hwdevice

does not work here (over ssh if that matters)
--- ./tests/ref/fate/hwdevice   2018-05-15 04:12:44.462164238 +0200
+++ tests/data/fate/hwdevice2018-05-15 04:13:04.606164152 +0200
@@ -1 +0,0 @@
-Passed.
Test hwdevice failed. Look at tests/data/fate/hwdevice.err for details.
X Error of failed request:  BadRequest (invalid request code or no such 
operation)
  Major opcode of failed request:  154 (DRI2)
  Minor opcode of failed request:  1 (DRI2Connect)
  Serial number of failed request:  11
  Current serial number in output stream:  11
make: *** [fate-hwdevice] Error 1

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] hwcontext: Do not call device_init again when deriving an existing device

[myp...@gmail.com]

2018-05-15 5:58 GMT+08:00 Mark Thompson :
> The change in 309d660775e2b47af6723a0477c4d753bc0c54f4 to call device_init
> when doing derivation missed this case - we should only call it if we
> actually made a new device.
> ---
>  libavutil/hwcontext.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 70c556ecac..745016ed7e 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -646,6 +646,9 @@ int av_hwdevice_ctx_create_derived(AVBufferRef 
> **dst_ref_ptr,
>  ret = AVERROR(ENOMEM);
>  goto fail;
>  }
> +ret = av_hwdevice_ctx_init(dst_ref);
> +if (ret < 0)
> +goto fail;
>  goto done;
>  }
>  if (ret != AVERROR(ENOSYS))
> @@ -658,10 +661,6 @@ int av_hwdevice_ctx_create_derived(AVBufferRef 
> **dst_ref_ptr,
>  goto fail;
>
>  done:
> -ret = av_hwdevice_ctx_init(dst_ref);
> -if (ret < 0)
> -goto fail;
> -
>  *dst_ref_ptr = dst_ref;
>  return 0;
>
> --
Patchset LGTM, thanks.
> 2.16.3
>
> ___
> 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 3/3] hwcontext: Add test for device creation and derivation

[James Almer]

On 5/14/2018 6:58 PM, Mark Thompson wrote:
> This uses any devices it can find on the host system - on a system with no
> hardware device support or in builds with no support included it will do
> nothing and pass.
> ---

I'd rather not have a fate test try to run anything on my GPU. It's
usually driver dependent and can be fragile.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] configure: error out on unsupported MSVC versions

[Rostislav Pehlivanov]

The FATE tests for MSVC versions older than 2013 are untested in FATE
and apparently are no longer supported.

This commit makes the configure process error out in case an older version
is used, and suggests to use a supported version of MSVC to compile.

As discussed on IRC:

2018-05-12 19:45:16 jamrial then again, most of those were for old msvc, 
and i think we're not supporting versions older than 2013 (first one c99 
compliant) anymore
2018-05-12 19:45:43 +JEEB   yea, I think 2013 update 2 is needed

22:53 <@atomnuker> nevcairiel: which commit broke/unsupported support for msvc 
2013?
23:23 <@atomnuker> okay, it was JEEB
23:25 <+JEEB> which was for 2012 and older
23:25 <+JEEB> and IIRC we no longer test those in FATE so that was my assumption
23:26 <+JEEB> 2013 is when MS got trolled enough to actually update their C part
23:26 <+JEEB> aand actually advertised FFmpeg support
23:26 <+JEEB> (although it was semi-failing until VS2013 update 1 or 2)

Signed-off-by: Rostislav Pehlivanov 
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index 1f7d0140e3..e52f8f850b 100755
--- a/configure
+++ b/configure
@@ -3988,8 +3988,7 @@ case "$toolchain" in
 cc_default="cl"
 cxx_default="cl"
 else
-cc_default="c99wrap cl"
-cxx_default="c99wrap cl"
+die "Unsupported MSVC version (2013 or newer required)"
 fi
 ld_default="$source_path/compat/windows/mslink"
 nm_default="dumpbin -symbols"
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] qsv: Use the installed mfx include headers if possibile

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Xiang, Haihao
> Sent: Monday, May 14, 2018 10:38 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] qsv: Use the installed mfx include
> headers if possibile
> 
> On Mon, 2018-05-14 at 00:50 +, Xiang, Haihao wrote:
> > > On 11/05/18 08:52, Haihao Xiang wrote:
> > > > Currently an extra copy of mfx include headers from
> > > > {MSDK_INSTALL_PREFIX}/include to
> {MSDK_INSTALL_PREFIX}/include/mfx
> > > > is required when using pkg-config for libmfx detection. This fix
> > > > checks the installed mfx include headers first, and falls back to
> > > > the legacy way if that fails
> > > >
> > > > Signed-off-by: Haihao Xiang 
> > > > ---
> > > >  configure|  3 ++-
> > > >  fftools/ffmpeg_qsv.c |  5 +
> > > >  libavcodec/qsv.c | 10 ++
> > > >  libavcodec/qsv.h |  4 
> > > >  libavcodec/qsv_internal.h|  4 
> > > >  libavcodec/qsvdec.c  |  4 
> > > >  libavcodec/qsvdec.h  |  4 
> > > >  libavcodec/qsvdec_h2645.c|  4 
> > > >  libavcodec/qsvdec_other.c|  4 
> > > >  libavcodec/qsvenc.c  |  5 +
> > > >  libavcodec/qsvenc.h  |  4 
> > > >  libavcodec/qsvenc_h264.c |  4 
> > > >  libavcodec/qsvenc_hevc.c |  4 
> > > >  libavcodec/qsvenc_jpeg.c |  4 
> > > >  libavcodec/qsvenc_mpeg2.c|  4 
> > > >  libavfilter/qsvvpp.h |  4 
> > > >  libavfilter/vf_deinterlace_qsv.c |  4 
> > > >  libavfilter/vf_scale_qsv.c   |  4 
> > > >  libavutil/hwcontext_opencl.c |  4 
> > > >  libavutil/hwcontext_qsv.c|  4 
> > > >  libavutil/hwcontext_qsv.h|  4 
> > > >  21 files changed, 90 insertions(+), 1 deletion(-)
> > >
> > > I don't think it's a good idea to put an #ifdef like this in every file.
> > >
> > > >
> > > > diff --git a/configure b/configure index a1f13a7109..e1f72495fb
> > > > 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -6007,7 +6007,8 @@ enabled libkvazaar&&
> require_pkg_config
> > > > libkvazaar "kvazaar >= 0.8.1" kv
> > > >  # Media SDK or Intel Media Server Studio, these don't come with
> > > > # pkg-config support.  Instead, users should make sure that the
> > > > build  # can find the libraries and headers through other means.
> > > > -enabled libmfx&& { check_pkg_config libmfx libmfx
> > > > "mfx/mfxvideo.h" MFXInit ||
> > > > +enabled libmfx&& { { check_pkg_config libmfx libmfx
> > > > "mfxvideo.h" MFXInit && add_cflags -DMFX_DEFAULT_INC_PATH; } ||
> > > > +   { check_pkg_config libmfx
> libmfx
> > > > "mfx/mfxvideo.h" MFXInit; } ||
> > > > { 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 $libm_extralibs
> > >
> > > So in the current code, the first test is for the open-source
> > > dispatcher (), which gets
> > > used everywhere that pkgconfig is supported, including mingw on
> > > Windows.  The second test is for Windows cases where you can't make
> > > make pkgconfig work.
> > >
> > > What installs the headers directly in $PREFIX/include?  Presumably
> > > this is a new change - can we ask them not to do that?  (Because
> > > organising them in a subdirectory is I think much more sensible.)
> > >
> >
> > Link below is the open-source version of MediaSDK which installs the
> > headers directly in $PREFIX/include. User needn't the open-source
> > dispatcher any more on Linux
> >
> > https://github.com/Intel-Media-SDK/MediaSDK
> >
> 
> I filed https://github.com/Intel-Media-SDK/MediaSDK/issues/199, hope they
> can change the install path for mfx headers.

Changing it in open source MSDK should be a better solution.

> 
> Thanks
> Haihao

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