Re: [FFmpeg-devel] avcodec/als: floating point support in ALS decoder

[Umair Khan]

On Sat, Jun 25, 2016 at 10:52 PM, Umair Khan  wrote:
> Hi,
>
> Patch attached.

I'm working on fixing some other bugs in the decoder and hence I'd
like to withdraw this patch from the list.

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

[FFmpeg-devel] [PATCH v2] libavcodec/dnxhd: added dnxhr profiles

[Mark Reid]

---
 libavcodec/avcodec.h|  7 +++
 libavcodec/codec_desc.c |  1 +
 libavcodec/dnxhddec.c   | 20 
 libavcodec/profiles.c   | 10 ++
 libavcodec/profiles.h   |  1 +
 5 files changed, 39 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 39713ed..8f84fd0 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3165,6 +3165,13 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_MPEG2_AAC_LOW 128
 #define FF_PROFILE_MPEG2_AAC_HE  131
 
+#define FF_PROFILE_DNXHD 0
+#define FF_PROFILE_DNXHR_LB  1
+#define FF_PROFILE_DNXHR_SQ  2
+#define FF_PROFILE_DNXHR_HQ  3
+#define FF_PROFILE_DNXHR_HQX 4
+#define FF_PROFILE_DNXHR_444 5
+
 #define FF_PROFILE_DTS 20
 #define FF_PROFILE_DTS_ES  30
 #define FF_PROFILE_DTS_96_24   40
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9d94b72..e6b8bbc 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -665,6 +665,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .name  = "dnxhd",
 .long_name = NULL_IF_CONFIG_SMALL("VC3/DNxHD"),
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+.profiles  = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
 },
 {
 .id= AV_CODEC_ID_THP,
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 1808080..33dfec2 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -33,6 +33,7 @@
 #include "dnxhddata.h"
 #include "idctdsp.h"
 #include "internal.h"
+#include "profiles.h"
 #include "thread.h"
 
 typedef struct RowContext {
@@ -567,6 +568,23 @@ static int dnxhd_decode_row(AVCodecContext *avctx, void 
*data,
 return 0;
 }
 
+static int dnxhd_get_profile(int cid)
+{
+switch(cid) {
+case 1270:
+return FF_PROFILE_DNXHR_444;
+case 1271:
+return FF_PROFILE_DNXHR_HQX;
+case 1272:
+return FF_PROFILE_DNXHR_HQ;
+case 1273:
+return FF_PROFILE_DNXHR_SQ;
+case 1274:
+return FF_PROFILE_DNXHR_LB;
+}
+return FF_PROFILE_DNXHD;
+}
+
 static int dnxhd_decode_frame(AVCodecContext *avctx, void *data,
   int *got_frame, AVPacket *avpkt)
 {
@@ -600,6 +618,7 @@ decode_coding_unit:
 }
 
 avctx->pix_fmt = ctx->pix_fmt;
+avctx->profile = dnxhd_get_profile(ctx->cid);
 ret = ff_set_dimensions(avctx, ctx->width, ctx->height);
 if (ret < 0)
 return ret;
@@ -692,4 +711,5 @@ AVCodec ff_dnxhd_decoder = {
 .capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS |
   AV_CODEC_CAP_SLICE_THREADS,
 .init_thread_copy = ONLY_IF_THREADS_ENABLED(dnxhd_decode_init_thread_copy),
+.profiles   = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
 };
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index da745e1..07fb6d6 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -46,6 +46,16 @@ const AVProfile ff_dca_profiles[] = {
 { FF_PROFILE_UNKNOWN },
 };
 
+const AVProfile ff_dnxhd_profiles[] = {
+  { FF_PROFILE_DNXHD,  "DNXHD"},
+  { FF_PROFILE_DNXHR_LB,   "DNXHR LB"},
+  { FF_PROFILE_DNXHR_SQ,   "DNXHR SQ"},
+  { FF_PROFILE_DNXHR_HQ,   "DNXHR HQ" },
+  { FF_PROFILE_DNXHR_HQX,  "DNXHR HQX"},
+  { FF_PROFILE_DNXHR_444,  "DNXHR 444"},
+  { FF_PROFILE_UNKNOWN },
+};
+
 const AVProfile ff_h264_profiles[] = {
 { FF_PROFILE_H264_BASELINE, "Baseline"  },
 { FF_PROFILE_H264_CONSTRAINED_BASELINE, "Constrained Baseline"  },
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index c86c683..eb18b40 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -23,6 +23,7 @@
 
 extern const AVProfile ff_aac_profiles[];
 extern const AVProfile ff_dca_profiles[];
+extern const AVProfile ff_dnxhd_profiles[];
 extern const AVProfile ff_h264_profiles[];
 extern const AVProfile ff_hevc_profiles[];
 extern const AVProfile ff_jpeg2000_profiles[];
-- 
2.7.3

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

[FFmpeg-devel] [PATCH v2] libavcodec/dnxhd: added dnxhr profiles

[Mark Reid]

Hi,
I hope this is a little bit saner.
Is having the multiple profiles too much?
I used the profile names from here
http://avid.force.com/pkb/articles/en_US/White_Paper/DNxHR-Codec-Bandwidth-Specifications

I've have been playing around with the encoder
and thought that the individual profiles could
be used there.

here are samples of various profiles:
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/sq_uhd.mxf
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/hq_uhd.mxf
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/hqx_uhd.mxf
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/444_uhd.dnxhr

the hqx and 444 ones won't work as they are 12bit,
but the cids (compression ids) should be correct

Mark Reid (1):
  libavcodec/dnxhd: added dnxhr profiles

 libavcodec/avcodec.h|  7 +++
 libavcodec/codec_desc.c |  1 +
 libavcodec/dnxhddec.c   | 20 
 libavcodec/profiles.c   | 10 ++
 libavcodec/profiles.h   |  1 +
 5 files changed, 39 insertions(+)

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

[FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

Finish providing SIMD versions for POWER8 VSX of functions in 
libswscale/input.c That should allow trac ticket #5570 to be closed.
The speedups obtained for the functions are:

abgrToA_c   1.19
bgr24ToUV_c 1.23
bgr24ToUV_half_c1.37
bgr24ToY_c_vsx  1.43
nv12ToUV_c  1.05
nv21ToUV_c  1.06
planar_rgb_to_uv1.25
planar_rgb_to_y 1.26
rgb24ToUV_c 1.11
rgb24ToUV_half_c1.10
rgb24ToY_c  0.92
rgbaToA_c   0.88
uyvyToUV_c  1.05
uyvyToY_c   1.15
yuy2ToUV_c  1.07
yuy2ToY_c   1.17
yvy2ToUV_c  1.05
---
 libswscale/ppc/input_vsx.c | 1021 +++-
 1 file changed, 1017 insertions(+), 4 deletions(-)

diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
index d977a32..35edd5e 100644
--- a/libswscale/ppc/input_vsx.c
+++ b/libswscale/ppc/input_vsx.c
@@ -30,6 +30,7 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/avassert.h"
+#include "libavutil/timer.h"
 #include "config.h"
 #include "libswscale/rgb2rgb.h"
 #include "libswscale/swscale.h"
@@ -54,6 +55,7 @@ static void abgrToA_c_vsx(uint8_t *_dst, const uint8_t *src, 
const uint8_t *unus
 for ( i = 0; i < width_adj; i += 8) {
 vector int v_rd0 = vec_vsx_ld(0, (int *)src_addr);
 vector int v_rd1 = vec_vsx_ld(0, (int *)(src_addr + 16));
+vector int v_dst;
 
 v_rd0 = vec_and(v_rd0, vec_splats(0x0ff));
 v_rd1 = vec_and(v_rd1, vec_splats(0x0ff));
@@ -61,8 +63,8 @@ static void abgrToA_c_vsx(uint8_t *_dst, const uint8_t *src, 
const uint8_t *unus
 v_rd0 = vec_sl(v_rd0, vec_splats((unsigned)6));
 v_rd1 = vec_sl(v_rd1, vec_splats((unsigned)6));
 
-vector int v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
-   {0, 1, 4, 5, 8, 9, 12, 13, 
16, 17, 20, 21, 24, 25, 28, 29}));
+v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
+{0, 1, 4, 5, 8, 9, 12, 13, 16, 17, 20, 
21, 24, 25, 28, 29}));
 vec_vsx_st((vector unsigned char)v_dst, 0, (unsigned char *)dst_addr);
 
 src_addr += 32;
@@ -91,6 +93,7 @@ static void rgbaToA_c_vsx(uint8_t *_dst, const uint8_t *src, 
const uint8_t *unus
 for ( i = 0; i < width_adj; i += 8) {
 vector int v_rd0 = vec_vsx_ld(0, (int *)src_addr);
 vector int v_rd1 = vec_vsx_ld(0, (int *)(src_addr + 16));
+vector int v_dst;
 
 v_rd0 = vec_sld(v_rd0, v_rd0, 13);
 v_rd1 = vec_sld(v_rd1, v_rd1, 13);
@@ -101,8 +104,8 @@ static void rgbaToA_c_vsx(uint8_t *_dst, const uint8_t 
*src, const uint8_t *unus
 v_rd0 = vec_sl(v_rd0, vec_splats((unsigned)6));
 v_rd1 = vec_sl(v_rd1, vec_splats((unsigned)6));
 
-vector int v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
-   {0, 1, 4, 5, 8, 9, 12, 13, 
16, 17, 20, 21, 24, 25, 28, 29}));
+v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
+{0, 1, 4, 5, 8, 9, 12, 13, 16, 17, 20, 
21, 24, 25, 28, 29}));
 vec_vsx_st((vector unsigned char)v_dst, 0, (unsigned char *)dst_addr);
 
 src_addr += 32;
@@ -114,6 +117,175 @@ static void rgbaToA_c_vsx(uint8_t *_dst, const uint8_t 
*src, const uint8_t *unus
 }
 }
 
+static void monoblack2Y_c_vsx(uint8_t *_dst, const uint8_t *src, const uint8_t 
*unused1, const uint8_t *unused2,
+  int width, uint32_t *unused)
+{
+int16_t *dst = (int16_t *)_dst;
+int i, j, width_adj, frag_len;
+
+vector unsigned charv_rd;
+vector signed short v_din, v_d, v_dst;
+vector unsigned short   v_opr;
+
+uintptr_t src_addr = (uintptr_t)src;
+uintptr_t dst_addr = (uintptr_t)dst;
+
+width = (width + 7) >> 3;
+
+// compute integral number of vector-length items and length of final 
fragment
+width_adj = width >> 3;
+width_adj = width_adj << 3;
+frag_len = width - width_adj;
+
+v_opr = (vector unsigned short) {7, 6, 5, 4, 3, 2, 1, 0};
+
+for (i = 0; i < width_adj; i += 8) {
+if (i & 0x0f) {
+v_rd = vec_sld(v_rd, v_rd, 8);
+} else {
+v_rd = vec_vsx_ld(0, (unsigned char *)src_addr);
+src_addr += 16;
+}
+
+v_din = vec_unpackh((vector signed char)v_rd);
+v_din = vec_and(v_din, vec_splats((short)0x00ff));
+
+for (j = 0; j < 8; j++) {
+switch(j) {
+case 0:
+v_d = vec_splat(v_din, 0);
+break;
+case 1:
+v_d = vec_splat(v_din, 1);
+break;
+case 2:
+v_d = vec_splat(v_din, 2);
+break;
+case 3:
+v_d = vec_splat(v_din, 3);
+break;
+  

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 18:03, "Michael Niedermayer" :
>   On Tue, Jul 05, 2016 at 05:45:19PM -0400, Ganesh Ajjanagadde wrote:
>>    05.07.2016, 17:29, "Michael Niedermayer" :
>>    > On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote:
>>    >>  04.07.2016, 15:55, "Ronald S. Bultje" :
>>    >>  >  Hi,
>>    >>  >
>>    >>  >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde 
>>  wrote:
>>    >>  >
>>    >>  >>   04.07.2016, 15:36, "Ronald S. Bultje" :
>>    >>  >>   > Hi,
>>    >>  >>   >
>>    >>  >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
>> 
>>    >>  >>   wrote:
>>    >>  >>   >
>>    >>  >>   >> 04.07.2016, 10:33, "Clément Bœsch" :
>>    >>  >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
>> 
>>    >>  >>   >> wrote:
>>    >>  >>   >> >> Hi,
>>    >>  >>   >> >>
>>    >>  >>   >> >> https://bestpractices.coreinfrastructure.org/.
>>    >>  >>   >> >>
>>    >>  >>   >> >> Thoughts on getting this done for FFmpeg?
>>    >>  >>   >> >
>>    >>  >>   >> > Any thing we need to adjust in the project? I don't see 
>> much things
>>    >>  >>   to
>>    >>  >>   >> > change by looking at
>>    >>  >>   >> https://bestpractices.coreinfrastructure.org/projects/1
>>    >>  >>   >>
>>    >>  >>   >> I could not either.
>>    >>  >>   >> It was something I noticed a week back, judged low-hanging 
>> and of some
>>    >>  >>   >> benefit to the project.
>>    >>  >>   >> I thus am willing to do it, provided there are no objections.
>>    >>  >>   >
>>    >>  >>   > I think if any changes are necessary to the website or 
>> documentation or
>>    >>  >>   > code, these would simply go through the relevant review 
>> process, right?
>>    >>  >>   Or
>>    >>  >>   > am I missing something?
>>    >>  >>
>>    >>  >>   True. At the moment, it seems like the relevant forms can be 
>> filled in
>>    >>  >>   directly from existing information,
>>    >>  >>   and no changes are necessary.
>>    >>  >>
>>    >>  >>   I can send a screenshot of the filled out form before submitting 
>> if people
>>    >>  >>   want.
>>    >>  >
>>    >>  >  Oh I see, I misunderstood. I personally don't have objections to 
>> that.
>>    >>
>>    >>  Turns out that the first few pages are easy to fill and we already 
>> achieve them.
>>    >>  The last few are much harder, and FFmpeg does not currently meet all 
>> of them.
>>    >>
>>    >>  Here is the progress so far: 
>> https://bestpractices.coreinfrastructure.org/projects/235.
>>    >>
>>    >>  I have filled them to the best of my ability.
>>    >>  Here is a summary of where we fail to meet the criteria,
>>    >>  and some suggestions for what we could do.
>>    >>
>>    >>  The "MUST" constraints are the ones where FFmpeg needs to improve,
>>    >>  assuming the project wishes to get to 100%.
>>    >
>>    >>  1. The project MUST have evidence that such tests are being added in 
>> the most recent major changes to the project.
>>    >>  Suggestion: enforce tests for all new filters, muxers, etc. At least 
>> 6 months back, this was not enforced for lavfi.
>>    >
>>    > The details for this reads "Major functionality would typically be 
>> mentioned in the ChangeLog. (Perfection is not required, merely evidence 
>> that tests are typically being added in practice.) "
>>    >
>>    > diffstat between 3.0 and 3.1 of make fatelist shows
>>    > fatelist-3.1 | 281 
>> +--
>>    >  1 file changed, 275 insertions(+), 6 deletions(-)
>>    >
>>    > so there are 269 more tests in 3.1 than 3.0
>>    >
>>    > limiting this to filters shows
>>    > grep filter fatelist-3.0> fatelist-3.0-filter
>>    > grep filter fatelist-3.1> fatelist-3.1-filter
>>    > diff -u fatelist-3.0-filter fatelist-3.1-filter | diffstat
>>    >  fatelist-3.1-filter | 25 +
>>    >  1 file changed, 25 insertions(+)
>>    >
>>    > we have 15 filters in the 3.0->3.1 changelog if i didnt miscount
>>    >
>>    > so i would say we are maybe a bit behind with adding tests but they
>>    > do get typically added eventually even for libavfilter.
>>    > No question, it would be better if tests would be added quicker ...
>>
>>    I do not doubt this, but at the moment we do not enforce it.
>
>>    Do you see any trouble in enforcing this requirement from major release 
>> to next major release?
>
>   thats more a question for everyone / the community than me (in case
>   this was meant as singular "you")

I was referring to the release manager(s).

Is it customary to vote on these things,
or let it pass through the standard informal review process?

I have updated the info based on the messages in this thread.
The current entries may be viewed at:
https://bestpractices.coreinfrastructure.org/projects/235.

I believe the above is the main blocker for getting to 

[FFmpeg-devel] [PATCH] avformat/oggenc: fix page size/duration calculation when granule differs from timestamp

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/oggenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index f998af3..34f7e0f 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -263,10 +263,10 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream 
*st,
 {
 AVStream *st = s->streams[page->stream_index];
 
-int64_t start = av_rescale_q(page->start_granule, st->time_base,
- AV_TIME_BASE_Q);
-int64_t next  = av_rescale_q(page->granule, st->time_base,
- AV_TIME_BASE_Q);
+int64_t start = av_rescale_q(ogg_granule_to_timestamp(oggstream, 
page->start_granule),
+ st->time_base, AV_TIME_BASE_Q);
+int64_t next  = av_rescale_q(ogg_granule_to_timestamp(oggstream, 
page->granule),
+ st->time_base, AV_TIME_BASE_Q);
 
 if (page->segments_count == 255) {
 ogg_buffer_page(s, oggstream);
-- 
2.9.0

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

Re: [FFmpeg-devel] [PATCH 6/6] libavformat/movenc: add dnxhr compatibility for apple players

[Mark Reid]

On Tue, Jul 5, 2016 at 1:53 AM, Carl Eugen Hoyos  wrote:
> Mark Reid  gmail.com> writes:
>
>>  if (track->vos_data && track->vos_len > 0x29) {
>> -if (track->vos_data[0] == 0x00 &&
>> -track->vos_data[1] == 0x00 &&
>> -track->vos_data[2] == 0x02 &&
>> -track->vos_data[3] == 0x80 &&
>> -(track->vos_data[4] == 0x01 || track->vos_data[4] == 0x02)) {
>> +if (avpriv_dnxhd_parse_header_prefix(track->vos_data) != 0) {
>
> This hunk and the two following hunks look unrelated
> to me.
> They could be ok independently of the other change.
>

sure I'll break those changes into a separate patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Michael Niedermayer]

On Mon, Jul 04, 2016 at 11:39:48PM -0500, Dan Parrot wrote:
> On Mon, 2016-07-04 at 23:31 -0500, Dan Parrot wrote:
> > On Mon, 2016-07-04 at 09:20 +, Carl Eugen Hoyos wrote:
> > > Dan Parrot  mail.com> writes:
> > > 
> > > > The dataset used was the entire FATE regression suite.
> > > 
> > > I don't think this is a particularly useful testcase:
> > > It takes very long but mostly tests other things.
> > > 
> > > Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> > > showed different results?
> > > I believe this should be both easier and faster to test.
> > > 
> > > > name: rgb24ToY_c_vsx. 
> > > > no. of calls: . min: 3832 ns. avg: 4709 ns. max: 37550 ns. 
> > > > total: 47093533 ns. 
> > > > 
> > > > name: rgb24ToY_c. 
> > > > no. of calls: . min: 3809 ns. avg: 4707 ns. max: 29041 ns. 
> > > > total: 47072923 ns.
> > > 
> > > Without any data, I would have thought that this is the most 
> > > important function (and "no. of calls" seems to confirm this).
> > > 
> > > Why is this not faster?
> 
> I believe I have answered, in earlier posts, all the questions you
> raised. Finally, just to satisfy my curiosity, I used SystemTap to probe
> during a run of the entire FATE regression. Here are the same two
> functions, this time with GCC 6.1.1 instead of 5.3.1 (it is
> representative of all other functions)
> 
> name: rgb24ToY_c_vsx. 
> no. of calls: . min: 3053 ns. avg: 3298 ns. max: 69359 ns. total:
> 32983050 ns.
> 
> name: rgb24ToY_c. 
> no. of calls: . min: 3040 ns. avg: 4056 ns. max: 79159 ns. total:
> 40561568 ns.
> 

> Non-trivial improvement is seen for the SIMD code. So: would you accept
> and apply the patch?

please add some benchmark scores to the commit message

thanks

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH]lavc/mjpeg_parser: Support jpegls parsing

[Michael Niedermayer]

On Tue, Jul 05, 2016 at 10:03:20PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer  niedermayer.cc> writes:
> 
> > LGTM,
> 
> Patch applied.
> 
> > can you add a fate test ?
> 
> Is there an example for a parser test?

something  with -c copy and -f framecrc should work

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

[Michael Niedermayer]

On Tue, Jul 05, 2016 at 12:33:34PM +, Petru Rares Sincraian wrote:
> Hi,
> 
> 
> Many thanks to all :)
> 
> 
> Here is the modified test with the first 20 frames only
> 
> 
> From: ffmpeg-devel  on behalf of James Almer 
> 
> Sent: Monday, July 4, 2016 6:39:20 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate
> 
> On 7/4/2016 1:34 PM, Petru Rares Sincraian wrote:
> > How can I do that?
> 
> Add -aframes 20 to the command line
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

>  fate/filter-audio.mak|5 +
>  ref/fate/filter-asetrate |   25 +
>  2 files changed, 30 insertions(+)
> a5c0d79b07aa2575808012a9ff50ca9937c604dd  
> 0001-fate-add-test-for-asetrate.patch
> From 8a2bd8c71dc18b80e36e37efb4f600e68f52b846 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Mon, 4 Jul 2016 17:51:54 +0200
> Subject: [PATCH] fate: add test for asetrate

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH]lavc/mjpeg_parser: Support jpegls parsing

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> LGTM,

Patch applied.

> can you add a fate test ?

Is there an example for a parser test?

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Michael Niedermayer]

On Tue, Jul 05, 2016 at 05:45:19PM -0400, Ganesh Ajjanagadde wrote:
> 05.07.2016, 17:29, "Michael Niedermayer" :
> > On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote:
> >>  04.07.2016, 15:55, "Ronald S. Bultje" :
> >>  >  Hi,
> >>  >
> >>  >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  
> >> wrote:
> >>  >
> >>  >>   04.07.2016, 15:36, "Ronald S. Bultje" :
> >>  >>   > Hi,
> >>  >>   >
> >>  >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
> >> 
> >>  >>   wrote:
> >>  >>   >
> >>  >>   >> 04.07.2016, 10:33, "Clément Bœsch" :
> >>  >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
> >> 
> >>  >>   >> wrote:
> >>  >>   >> >> Hi,
> >>  >>   >> >>
> >>  >>   >> >> https://bestpractices.coreinfrastructure.org/.
> >>  >>   >> >>
> >>  >>   >> >> Thoughts on getting this done for FFmpeg?
> >>  >>   >> >
> >>  >>   >> > Any thing we need to adjust in the project? I don't see much 
> >> things
> >>  >>   to
> >>  >>   >> > change by looking at
> >>  >>   >> https://bestpractices.coreinfrastructure.org/projects/1
> >>  >>   >>
> >>  >>   >> I could not either.
> >>  >>   >> It was something I noticed a week back, judged low-hanging and of 
> >> some
> >>  >>   >> benefit to the project.
> >>  >>   >> I thus am willing to do it, provided there are no objections.
> >>  >>   >
> >>  >>   > I think if any changes are necessary to the website or 
> >> documentation or
> >>  >>   > code, these would simply go through the relevant review process, 
> >> right?
> >>  >>   Or
> >>  >>   > am I missing something?
> >>  >>
> >>  >>   True. At the moment, it seems like the relevant forms can be filled 
> >> in
> >>  >>   directly from existing information,
> >>  >>   and no changes are necessary.
> >>  >>
> >>  >>   I can send a screenshot of the filled out form before submitting if 
> >> people
> >>  >>   want.
> >>  >
> >>  >  Oh I see, I misunderstood. I personally don't have objections to that.
> >>
> >>  Turns out that the first few pages are easy to fill and we already 
> >> achieve them.
> >>  The last few are much harder, and FFmpeg does not currently meet all of 
> >> them.
> >>
> >>  Here is the progress so far: 
> >> https://bestpractices.coreinfrastructure.org/projects/235.
> >>
> >>  I have filled them to the best of my ability.
> >>  Here is a summary of where we fail to meet the criteria,
> >>  and some suggestions for what we could do.
> >>
> >>  The "MUST" constraints are the ones where FFmpeg needs to improve,
> >>  assuming the project wishes to get to 100%.
> >
> >>  1. The project MUST have evidence that such tests are being added in the 
> >> most recent major changes to the project.
> >>  Suggestion: enforce tests for all new filters, muxers, etc. At least 6 
> >> months back, this was not enforced for lavfi.
> >
> > The details for this reads "Major functionality would typically be 
> > mentioned in the ChangeLog. (Perfection is not required, merely evidence 
> > that tests are typically being added in practice.) "
> >
> > diffstat between 3.0 and 3.1 of make fatelist shows
> > fatelist-3.1 | 281 
> > +--
> >  1 file changed, 275 insertions(+), 6 deletions(-)
> >
> > so there are 269 more tests in 3.1 than 3.0
> >
> > limiting this to filters shows
> > grep filter fatelist-3.0> fatelist-3.0-filter
> > grep filter fatelist-3.1> fatelist-3.1-filter
> > diff -u fatelist-3.0-filter fatelist-3.1-filter | diffstat
> >  fatelist-3.1-filter | 25 +
> >  1 file changed, 25 insertions(+)
> >
> > we have 15 filters in the 3.0->3.1 changelog if i didnt miscount
> >
> > so i would say we are maybe a bit behind with adding tests but they
> > do get typically added eventually even for libavfilter.
> > No question, it would be better if tests would be added quicker ...
> 
> I do not doubt this, but at the moment we do not enforce it.

> Do you see any trouble in enforcing this requirement from major release to 
> next major release?

thats more a question for everyone / the community than me (in case
this was meant as singular "you")


> This should provide sufficient time.
> Really, all it requires is changing the "informal/soft constraint" to a 
> "hard" constraint,
> and accordingly noted in the dev docs.
> 
> I treated the "must" here as a hard constraint.

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 17:29, "Michael Niedermayer" :
> On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote:
>>  04.07.2016, 15:55, "Ronald S. Bultje" :
>>  >  Hi,
>>  >
>>  >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  
>> wrote:
>>  >
>>  >>   04.07.2016, 15:36, "Ronald S. Bultje" :
>>  >>   > Hi,
>>  >>   >
>>  >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
>>  >>   wrote:
>>  >>   >
>>  >>   >> 04.07.2016, 10:33, "Clément Bœsch" :
>>  >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
>>  >>   >> wrote:
>>  >>   >> >> Hi,
>>  >>   >> >>
>>  >>   >> >> https://bestpractices.coreinfrastructure.org/.
>>  >>   >> >>
>>  >>   >> >> Thoughts on getting this done for FFmpeg?
>>  >>   >> >
>>  >>   >> > Any thing we need to adjust in the project? I don't see much 
>> things
>>  >>   to
>>  >>   >> > change by looking at
>>  >>   >> https://bestpractices.coreinfrastructure.org/projects/1
>>  >>   >>
>>  >>   >> I could not either.
>>  >>   >> It was something I noticed a week back, judged low-hanging and of 
>> some
>>  >>   >> benefit to the project.
>>  >>   >> I thus am willing to do it, provided there are no objections.
>>  >>   >
>>  >>   > I think if any changes are necessary to the website or documentation 
>> or
>>  >>   > code, these would simply go through the relevant review process, 
>> right?
>>  >>   Or
>>  >>   > am I missing something?
>>  >>
>>  >>   True. At the moment, it seems like the relevant forms can be filled in
>>  >>   directly from existing information,
>>  >>   and no changes are necessary.
>>  >>
>>  >>   I can send a screenshot of the filled out form before submitting if 
>> people
>>  >>   want.
>>  >
>>  >  Oh I see, I misunderstood. I personally don't have objections to that.
>>
>>  Turns out that the first few pages are easy to fill and we already achieve 
>> them.
>>  The last few are much harder, and FFmpeg does not currently meet all of 
>> them.
>>
>>  Here is the progress so far: 
>> https://bestpractices.coreinfrastructure.org/projects/235.
>>
>>  I have filled them to the best of my ability.
>>  Here is a summary of where we fail to meet the criteria,
>>  and some suggestions for what we could do.
>>
>>  The "MUST" constraints are the ones where FFmpeg needs to improve,
>>  assuming the project wishes to get to 100%.
>
>>  1. The project MUST have evidence that such tests are being added in the 
>> most recent major changes to the project.
>>  Suggestion: enforce tests for all new filters, muxers, etc. At least 6 
>> months back, this was not enforced for lavfi.
>
> The details for this reads "Major functionality would typically be mentioned 
> in the ChangeLog. (Perfection is not required, merely evidence that tests are 
> typically being added in practice.) "
>
> diffstat between 3.0 and 3.1 of make fatelist shows
> fatelist-3.1 | 281 +--
>  1 file changed, 275 insertions(+), 6 deletions(-)
>
> so there are 269 more tests in 3.1 than 3.0
>
> limiting this to filters shows
> grep filter fatelist-3.0> fatelist-3.0-filter
> grep filter fatelist-3.1> fatelist-3.1-filter
> diff -u fatelist-3.0-filter fatelist-3.1-filter | diffstat
>  fatelist-3.1-filter | 25 +
>  1 file changed, 25 insertions(+)
>
> we have 15 filters in the 3.0->3.1 changelog if i didnt miscount
>
> so i would say we are maybe a bit behind with adding tests but they
> do get typically added eventually even for libavfilter.
> No question, it would be better if tests would be added quicker ...

I do not doubt this, but at the moment we do not enforce it.
Do you see any trouble in enforcing this requirement from major release to next 
major release?
This should provide sufficient time.
Really, all it requires is changing the "informal/soft constraint" to a "hard" 
constraint,
and accordingly noted in the dev docs.

I treated the "must" here as a hard constraint.

>
> [...]
>
>>  5. The project security mechanisms MUST use default keylengths that at 
>> least meet the NIST minimum requirements through the year 2030 (as stated in 
>> 2012).
>>  Suggestion: add --enable-unsafe-crypt to configure, and by default not 
>> enable it.
>>  Change API's and functions accordingly, document it.
>>  Note: strictly speaking, per the sentence above, it is ok as we do not 
>> really have "default" keylengths.
>>  But the extended rationale shows why we fail.
>
> "For example, FFmpeg's DES API accepts 64 bit keys, and there is no 
> configuration option for disabling this."
>
> The low level DES API may be part of a security mechanism, for example
> 3DES used for encrypting something which is having sufficiently sized
> keys. Also the low level APIs are used for format interoperability
> outside any "security mechanisms"

Ok. 

>
>>  6. The default project security mechanisms MUST NOT 

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Michael Niedermayer]

On Mon, Jul 04, 2016 at 09:15:27PM -0400, Ganesh Ajjanagadde wrote:
> 04.07.2016, 15:55, "Ronald S. Bultje" :
> >  Hi,
> >
> >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  
> > wrote:
> >
> >>   04.07.2016, 15:36, "Ronald S. Bultje" :
> >>   > Hi,
> >>   >
> >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
> >>   wrote:
> >>   >
> >>   >> 04.07.2016, 10:33, "Clément Bœsch" :
> >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
> >>   >> wrote:
> >>   >> >> Hi,
> >>   >> >>
> >>   >> >> https://bestpractices.coreinfrastructure.org/.
> >>   >> >>
> >>   >> >> Thoughts on getting this done for FFmpeg?
> >>   >> >
> >>   >> > Any thing we need to adjust in the project? I don't see much things
> >>   to
> >>   >> > change by looking at
> >>   >> https://bestpractices.coreinfrastructure.org/projects/1
> >>   >>
> >>   >> I could not either.
> >>   >> It was something I noticed a week back, judged low-hanging and of some
> >>   >> benefit to the project.
> >>   >> I thus am willing to do it, provided there are no objections.
> >>   >
> >>   > I think if any changes are necessary to the website or documentation or
> >>   > code, these would simply go through the relevant review process, right?
> >>   Or
> >>   > am I missing something?
> >>
> >>   True. At the moment, it seems like the relevant forms can be filled in
> >>   directly from existing information,
> >>   and no changes are necessary.
> >>
> >>   I can send a screenshot of the filled out form before submitting if 
> >> people
> >>   want.
> >
> >  Oh I see, I misunderstood. I personally don't have objections to that.
> 
> 
> Turns out that the first few pages are easy to fill and we already achieve 
> them.
> The last few are much harder, and FFmpeg does not currently meet all of them.
> 
> Here is the progress so far: 
> https://bestpractices.coreinfrastructure.org/projects/235.
> 
> I have filled them to the best of my ability.
> Here is a summary of where we fail to meet the criteria,
> and some suggestions for what we could do.
> 
> The "MUST" constraints are the ones where FFmpeg needs to improve,
> assuming the project wishes to get to 100%.
> 

> 1. The project MUST have evidence that such tests are being added in the most 
> recent major changes to the project.
> Suggestion: enforce tests for all new filters, muxers, etc. At least 6 months 
> back, this was not enforced for lavfi.

The details for this reads "Major functionality would typically be mentioned in 
the ChangeLog. (Perfection is not required, merely evidence that tests are 
typically being added in practice.) "

diffstat between 3.0 and 3.1 of make fatelist shows
fatelist-3.1 |  281 +--
 1 file changed, 275 insertions(+), 6 deletions(-)

so there are 269 more tests in 3.1 than 3.0

limiting this to filters shows
grep filter fatelist-3.0> fatelist-3.0-filter
grep filter fatelist-3.1> fatelist-3.1-filter
diff -u fatelist-3.0-filter fatelist-3.1-filter | diffstat
 fatelist-3.1-filter |   25 +
 1 file changed, 25 insertions(+)

we have 15 filters in the 3.0->3.1 changelog if i didnt miscount

so i would say we are maybe a bit behind with adding tests but they
do get typically added eventually even for libavfilter.
No question, it would be better if tests would be added quicker ...


[...]

> 5. The project security mechanisms MUST use default keylengths that at least 
> meet the NIST minimum requirements through the year 2030 (as stated in 2012).
> Suggestion: add --enable-unsafe-crypt to configure, and by default not enable 
> it.
> Change API's and functions accordingly, document it.
> Note: strictly speaking, per the sentence above, it is ok as we do not really 
> have "default" keylengths.
> But the extended rationale shows why we fail.

"For example, FFmpeg's DES API accepts 64 bit keys, and there is no 
configuration option for disabling this."

The low level DES API may be part of a security mechanism, for example
3DES used for encrypting something which is having sufficiently sized
keys. Also the low level APIs are used for format interoperability
outside any "security mechanisms"


> 
> 6. The default project security mechanisms MUST NOT depend on cryptographic 
> algorithms that are broken
> (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
> Suggestion: same as 5 above.

"For example, FFmpeg provides a DES API, and there is no configuration option 
for disabling this."

the point above speaks about the "default", i would argue a user using
the DES API explicitly has made a choice and is not using a default


> 
> 7. The project security mechanisms SHOULD NOT by default depend on 
> cryptographic algorithms with known serious weaknesses (e.g., SHA-1).
> Suggestion: same as 5 above.

> 
> 8. At least one static code analysis tool MUST be applied to any proposed 
> 

Re: [FFmpeg-devel] [PATCH] x86/dcadsp: optimize lfe_fir0_float_fma3 on x86_32

[James Almer]

On 7/3/2016 6:54 PM, James Almer wrote:
> About 10% faster.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/x86/dcadsp.asm | 43 +++
>  1 file changed, 31 insertions(+), 12 deletions(-)
> 

Applied.

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 08:16, "Ronald S. Bultje" :
[...]
>>  > [..]
>>  >
>>  >> 4. If the project software is an application or library, and its
>>  primary
>>  >> purpose is not to implement cryptography,
>>  >> then it SHOULD only call on software specifically designed to implement
>>  >> cryptographic functions;
>>  >> it SHOULD NOT re-implement its own.
>>  >> Note: This is one where I am personally interested as to why we fail;
>>  is
>>  >> it for performance reasons that we reimplement crypto?
>>  >> Suggestion: No idea until I understand the above.
>>  >>
>>  >> 5. The project security mechanisms MUST use default keylengths that at
>>  >> least meet the NIST minimum requirements through the year 2030 (as
>>  stated
>>  >> in 2012).
>>  >> Suggestion: add --enable-unsafe-crypt to configure, and by default not
>>  >> enable it.
>>  >> Change API's and functions accordingly, document it.
>>  >> Note: strictly speaking, per the sentence above, it is ok as we do not
>>  >> really have "default" keylengths.
>>  >> But the extended rationale shows why we fail.
>>  >>
>>  >> 6. The default project security mechanisms MUST NOT depend on
>>  >> cryptographic algorithms that are broken
>>  >> (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
>>  >> Suggestion: same as 5 above.
>>  >
>>  > We don't use any of these for security purposes, we only use them for
>>  > checking frame hashes in automated tests. That should be totally fine.
>>
>>  We do export them though. Just because the FFmpeg CLI progs don't use them
>>  for security,
>>  does not mean a client does not, or that a client can be easily configured
>>  to not use them.
>>  See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
>>  for what I believe the intent of this requirement is.
>>
>>  Second, are you sure about your claim?
>>  md5 is used in httpauth per RFC 2617.
>>  Now this is fixed by the RFC, but it does not mean FFmpeg needs to support
>>  it by default.
>>  In particular, I don't see how this honestly takes care of 6.
>
> I don't know if we can be held responsible for what clients do. The intent
> of 6 is for our software, not client software, right?

It is a subtle point, taking your argument, openssl and libgcrypt don't need to 
provide the option.
It is needed for them, if for nothing else, for FIPS requirements.
A client could maintain their own patchset, but it is useful to do it there.

>
> We can add an option to httpauth to allow disabling md5 encryption in the
> list of supported encryption protocols (if such an option doesn't already
> exist). But I certainly wouldn't go beyond that.
>
>>  In matroskaenc, mov, 160 bit SHA-1 is used.
>>  Unless someone who knows the code well, audits the codebase, and checks
>>  that the SHA-1 and the like are not really for security here (similar to
>>  the git model),
>>  5 also has problems IMHO.
>
> This is known as "FUD" (Google it if that sounds new). Don't make such
> claims unless you have done research, the issue is that people will link to
> your email in the mailinglist archives and then claim that "ffmpeg is
> fundamentally insecure" - which is utterly untrue.

I am aware of the term "FUD".

You have done this repeatedly in the past, accusing me of making claims when 
there is no claim made.
There was a basic "Unless..." qualifier.
Anyone with a working knowledge of English who pulls the mail will realize that 
there is no such accusation
about FFmpeg.

>
> And yes, like in our tests, the sha1s in matroska are simply internal
> checksums, they are not security-related. And yes, I'm extremely familiar
> with matroska.

Matroska was given as a single example. I doubt you could make the claim of 
familiarity for everything in FFmpeg.
Nevertheless, to a reasonable degree, this is fine.

>
> As for reimplementing crypto, AES encryption is done in lavf/srtp.c.
>>  We thus do not meet 4, though this is not a "must" requirement.
>
> So there still isn't really an issue. Let's stick to issues for now.

Ok, there are a number of others in the original post.

>
> Ronald
> ___
> 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] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 08:22, "Hendrik Leppkes" :
> On Tue, Jul 5, 2016 at 1:40 PM, Ganesh Ajjanagadde  wrote:
[...]
>>>
>>>  [..]
>>>
   4. If the project software is an application or library, and its primary
   purpose is not to implement cryptography,
   then it SHOULD only call on software specifically designed to implement
   cryptographic functions;
   it SHOULD NOT re-implement its own.
   Note: This is one where I am personally interested as to why we fail; is
   it for performance reasons that we reimplement crypto?
   Suggestion: No idea until I understand the above.

   5. The project security mechanisms MUST use default keylengths that at
   least meet the NIST minimum requirements through the year 2030 (as stated
   in 2012).
   Suggestion: add --enable-unsafe-crypt to configure, and by default not
   enable it.
   Change API's and functions accordingly, document it.
   Note: strictly speaking, per the sentence above, it is ok as we do not
   really have "default" keylengths.
   But the extended rationale shows why we fail.

   6. The default project security mechanisms MUST NOT depend on
   cryptographic algorithms that are broken
   (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
   Suggestion: same as 5 above.
>>>
>>>  We don't use any of these for security purposes, we only use them for
>>>  checking frame hashes in automated tests. That should be totally fine.
>>
>>  We do export them though. Just because the FFmpeg CLI progs don't use them 
>> for security,
>>  does not mean a client does not, or that a client can be easily configured 
>> to not use them.
>>  See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
>>  for what I believe the intent of this requirement is.
>>
>>  Second, are you sure about your claim?
>>  md5 is used in httpauth per RFC 2617.
>>  Now this is fixed by the RFC, but it does not mean FFmpeg needs to support 
>> it by default.
>>  In particular, I don't see how this honestly takes care of 6.
>
> This is a rather bad example. The alternative to md5 password digests
> is not using digests at all and only use base64 "encoded" passwords.
> Would that be better? Certainly not. Its like calling every browser
> insecure because it supports md5 digests in the HTTP auth protocol.
> There just isn't a better variant, and disabling it would result in
> either incompat with HTTP servers using it, or fallback to even worse
> variants.
>
>>  In matroskaenc, mov, 160 bit SHA-1 is used.
>>  Unless someone who knows the code well, audits the codebase, and checks
>>  that the SHA-1 and the like are not really for security here (similar to 
>> the git model),
>>  5 also has problems IMHO.
>
> sha1 in matroskaenc is used to derive a hash as a bitexact fileuid -
> the alternative is a randomuid (which wouldnt result in bitexact
> files), it has no security implications whatsoever, its just a random
> identifier.
> mov uses sha1 for AAX keys (Audible files), which is mandated by the
> specification.
>
> This is really the general pattern of hash usage in avformat and
> avcodec - its used when the specification asks for it.
>
> As for re-implementing AES or hash algorithms - well those are rather
> trivial, aren't they. Its not like we re-implement TLS.
> The reasoning here is that some of those are strictly required for
> some media formats, and having a dependency on an external library for
> key features of some media formats is rather restrictive. Is there
> even a simple library that offers simple AES/SHA implementations
> without being something huge like openssl?

Note that libgcrypt is substantially smaller than openssl.
I would still not call it simple, only relatively simpler, so no issue with 
your point.

Thanks for the explanations. 

Most of it boils down to the restrictive wording in the badge app,
there are other instances where I was not too happy (redundancy, slightly 
conflicting reqs,
imprecision, etc as detailed in the original message).
As you point out, per their strict criteria no standard browser under default 
config can meet their target.

I will update the crypto stuff later tonight.

>
> - Hendrik
> ___
> 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]lavc/mjpeg_parser: Support jpegls parsing

[Michael Niedermayer]

On Tue, Jul 05, 2016 at 05:31:31PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #5691 for me.
> 
> Please comment, Carl Eugen

>  mjpeg_parser.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> facecf8bb4e902cc018a9c5fd2e6b539914eb313  
> 0001-lavc-mjpeg_parser-Allow-jpegls-parsing.patch
> From 83c4a6ac1dac871900977c8df0100c98500e06a2 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 5 Jul 2016 17:28:56 +0200
> Subject: [PATCH] lavc/mjpeg_parser: Allow jpegls parsing.

LGTM,

can you add a fate test ?

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH] Added Quadrox format

[compn]

On Tue, 5 Jul 2016 09:57:28 +0200
Michael Niedermayer  wrote:

> On Mon, Jul 04, 2016 at 06:13:50AM +0530, smitbose wrote:
> > ---
> >  libavformat/riff.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> applied
> 
> thanks

congratulations on your first contribution to ffmpeg, smitbose.

welcome to the world of open source.

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

Re: [FFmpeg-devel] [RFC] beginner difficulty bug trac tag for new open source developers

[compn]

On Mon, 4 Jul 2016 12:43:03 +0300
Sami Hult  wrote:

> My five cents would be to advice every aspiring contributor to focus
> on bugs or lacking features that are an issue for themselves. That
> ensures motivation to really fix it :)

that is good advice, thank you.

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

Re: [FFmpeg-devel] [PATCH] libavfilter/af_hdcd.c: Collect HDCD stats and report

[Burt P.]

Attached is the fourth version of this patch. I've reworked it
a bit to make it cleaner and provide more interesting/useful
information. Also, I've updated the documentation.
This includes the fix to low-level gain adjustment.

Thanks.
From 328b75b0abbc1e760a115c98d6f43dc6ff9a8fa1 Mon Sep 17 00:00:00 2001
From: Burt P 
Date: Tue, 5 Jul 2016 12:23:33 -0500
Subject: [PATCH] libavfilter/af_hdcd.c: Collect HDCD stats and report

The new HDCD filter really does nothing to show that it is working or
that HDCD control information was even detected in the stream. This
patch collects information about the decode, like which features were
used, and reports it to the user at the end.

Also,
* Fixes low-level gain adjustment
* Updates the documentation

Signed-off-by: Burt P 
---
 doc/filters.texi  | 19 +++--
 libavfilter/af_hdcd.c | 76 +--
 2 files changed, 90 insertions(+), 5 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 3cf3d7c..16f315b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8427,8 +8427,23 @@ ffplay input.mkv -vf "movie=clut.png, [in] haldclut"
 
 @section hdcd
 
-Decodes high definition audio cd data. 16-Bit PCM stream containing hdcd flags
-is converted to 20-bit PCM stream.
+Decodes High Definition Compatible Digital (HDCD) data. A 16-bit PCM stream with
+embedded HDCD codes is expanded into a 20-bit PCM stream.
+
+The filter supports the Peak Extend and Low-level Gain Adjustment features
+of HDCD, and detects the Transient Filter flag.
+
+@example
+ffmpeg -i HDCD16.flac -af hdcd OUT24.flac
+@end example
+
+When using the filter with wav, note the default encoding for wav is 16-bit, 
+so the resulting 20-bit stream will be truncated back to 16-bit. Use something
+like @command{-acodec pcm_s24le} after the filter to get 24-bit PCM output.
+@example
+ffmpeg -i HDCD16.wav -af hdcd OUT16.wav
+ffmpeg -i HDCD16.wav -af hdcd -acodec pcm_s24le OUT24.wav
+@end example
 
 @section hflip
 
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 16bdcb0..89012eb 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -31,7 +31,8 @@
 */
 
 /*
-  More information about high definition audio cds:
+  HDCD is High Definition Compatible Digital
+  More information about HDCD-encoded audio CDs:
   http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html
   http://www.audiomisc.co.uk/HFN/HDCD/Examined.html
  */
@@ -823,11 +824,29 @@ typedef struct {
 int code_counterA;
 int code_counterB;
 int code_counterC;
+
+/* For user information/stats, pulled up into HDCDContext
+ * by filter_frame() */
+int count_peak_extend;
+int count_transient_filter;
+/* target_gain is a 4-bit (3.1) fixed-point value, always
+ * negative, but stored positive.
+ * The 16 possible values range from -7.5 to 0.0 dB in
+ * steps of 0.5, but no value below -6.0 dB should appear. */
+int gain_counts[16]; /* for cursiosity, mostly */
+int max_gain;
+int cb6, cb7; /* watch bits 6 and 7 of the control code, for curiosity */
 } hdcd_state_t;
 
 typedef struct HDCDContext {
 const AVClass *class;
 hdcd_state_t state[2];
+
+/* User information/stats */
+int hdcd_detected;
+int uses_peak_extend;
+int uses_transient_filter; /* detected, but not implemented */
+float max_gain_adjustment; /* in dB, expected in the range -6.0 to 0.0 */
 } HDCDContext;
 
 static const AVOption hdcd_options[] = {
@@ -840,6 +859,8 @@ AVFILTER_DEFINE_CLASS(hdcd);
 
 static void hdcd_reset(hdcd_state_t *state, unsigned rate)
 {
+int i;
+
 state->window = 0;
 state->readahead = 32;
 state->arg = 0;
@@ -853,6 +874,13 @@ static void hdcd_reset(hdcd_state_t *state, unsigned rate)
 state->code_counterA = 0;
 state->code_counterB = 0;
 state->code_counterC = 0;
+
+state->count_peak_extend = 0;
+state->count_transient_filter = 0;
+for(i = 0; i < 16; i++) state->gain_counts[i] = 0;
+state->max_gain = 0;
+state->cb6 = 0;
+state->cb7 = 0;
 }
 
 static int integrate(hdcd_state_t *state, int *flag, const int32_t *samples, int count, int stride)
@@ -949,6 +977,7 @@ static int hdcd_envelope(int32_t *samples, int count, int stride, int gain, int
 int len = FFMIN(count, target_gain - gain);
 /* attenuate slowly */
 for (i = 0; i < len; i++) {
+++gain;
 APPLY_GAIN(*samples, gain);
 samples += stride;
 }
@@ -982,6 +1011,18 @@ static int hdcd_envelope(int32_t *samples, int count, int stride, int gain, int
 return gain;
 }
 
+/* update the user info/flags */
+static void hdcd_update_info(hdcd_state_t *state)
+{
+if (state->control & 16) state->count_peak_extend++;
+if (state->control & 32) state->count_transient_filter++;
+state->gain_counts[state->control & 15]++;
+state->max_gain = FFMAX(state->max_gain, (state->control & 15));
+
+if 

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Tue, 2016-07-05 at 15:45 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > These results for START_TIMER/STOP_TIMER are with ffmpeg 
> > compiled using GCC 6.1.1
> 
> I believe your results indicate that -cpuflags 0 has no 
> effect on vsx.
> On x86, this would be a blocker.
> 
> While I would prefer if you had tested with vanilla 
> gcc instead of a version patched by a distributor, no 
> more comments from me.

Just to be clear, I am not making any claims about any special patching
in GCC 6.1.1. All I am saying about GCC is that version 5.3.1 produces
suboptimal SIMD sequences; 6.1.1 gives much better SIMD sequences. Both
versions are preinstalled on Fedora images in the IBM cloud. I have no
way of knowing how those versions of GCC behave on different machines.

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> What kind of speedup are you seeing

His patch provides a 10% - 30% speedup for most libswscale 
input functions, but not for rgb24->yuv with gcc 5.

> and how did you measure that,

He measured it with some performance tool and with 
-benchmark and with START/STOP_TIMER().

> and why doesn't START/STOP_TIMER show these speedups?

It does show the same results as the performance tool 
afaict.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Ronald S. Bultje]

Hi,

On Tue, Jul 5, 2016 at 11:45 AM, Carl Eugen Hoyos  wrote:

> Dan Parrot  mail.com> writes:
>
> > These results for START_TIMER/STOP_TIMER are with ffmpeg
> > compiled using GCC 6.1.1
>
> I believe your results indicate that -cpuflags 0 has no
> effect on vsx.


I didn't even catch this the first time. I find this thread highly
unorganized. Dan, can you organize the data more usefully for us? What kind
of speedup are you seeing and how did you measure that, and why doesn't
START/STOP_TIMER show these speedups?

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Carl Eugen Hoyos]

Dan Parrot  mail.com> writes:

> These results for START_TIMER/STOP_TIMER are with ffmpeg 
> compiled using GCC 6.1.1

I believe your results indicate that -cpuflags 0 has no 
effect on vsx.
On x86, this would be a blocker.

While I would prefer if you had tested with vanilla 
gcc instead of a version patched by a distributor, no 
more comments from me.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 06:22 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > Finish providing SIMD versions for POWER8 VSX of functions 
> > in libswscale/input.c
> > That should allow trac ticket #5570 to be closed.
> 
> Please add some numbers:
> Either for single functions or for a single ffmpeg command.
> (for rgb/bgr, mono is irrelevant)
> 
> Carl Eugen

All questions you posed have now been answered in the thread. It here
are no new issues, could you apply the patch and close trac ticket
#5570.


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

[FFmpeg-devel] [PATCH]lavc/mjpeg_parser: Support jpegls parsing

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5691 for me.

Please comment, Carl Eugen
From 83c4a6ac1dac871900977c8df0100c98500e06a2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 5 Jul 2016 17:28:56 +0200
Subject: [PATCH] lavc/mjpeg_parser: Allow jpegls parsing.

---
 libavcodec/mjpeg_parser.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
index e548b00..07a6b2b 100644
--- a/libavcodec/mjpeg_parser.c
+++ b/libavcodec/mjpeg_parser.c
@@ -127,7 +127,7 @@ static int jpeg_parse(AVCodecParserContext *s,
 
 
 AVCodecParser ff_mjpeg_parser = {
-.codec_ids  = { AV_CODEC_ID_MJPEG },
+.codec_ids  = { AV_CODEC_ID_MJPEG, AV_CODEC_ID_JPEGLS },
 .priv_data_size = sizeof(MJPEGParserContext),
 .parser_parse   = jpeg_parse,
 .parser_close   = ff_parse_close,
-- 
1.7.10.4

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Hendrik Leppkes]

On Tue, Jul 5, 2016 at 2:22 PM, Hendrik Leppkes  wrote:
> On Tue, Jul 5, 2016 at 1:40 PM, Ganesh Ajjanagadde  wrote:
>> 04.07.2016, 22:59, "Ronald S. Bultje" :
>>> Hi,
>>>
>>> On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde  wrote:
>>>
  04.07.2016, 15:55, "Ronald S. Bultje" :
  > Hi,
  >
  > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde 
  wrote:
  >
  >> 04.07.2016, 15:36, "Ronald S. Bultje" :
  >> > Hi,
  >> >
  >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
  gajja...@mit.edu>
  >> wrote:
  >> >
  >> >> 04.07.2016, 10:33, "Clément Bœsch" :
  >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
  >> >> wrote:
  >> >> >> Hi,
  >> >> >>
  >> >> >> https://bestpractices.coreinfrastructure.org/.
  >> >> >>
  >> >> >> Thoughts on getting this done for FFmpeg?
  >> >> >
  >> >> > Any thing we need to adjust in the project? I don't see much
  things
  >> to
  >> >> > change by looking at
  >> >> https://bestpractices.coreinfrastructure.org/projects/1
  >> >>
  >> >> I could not either.
  >> >> It was something I noticed a week back, judged low-hanging and of
  some
  >> >> benefit to the project.
  >> >> I thus am willing to do it, provided there are no objections.
  >> >
  >> > I think if any changes are necessary to the website or
  documentation or
  >> > code, these would simply go through the relevant review process,
  right?
  >> Or
  >> > am I missing something?
  >>
  >> True. At the moment, it seems like the relevant forms can be filled in
  >> directly from existing information,
  >> and no changes are necessary.
  >>
  >> I can send a screenshot of the filled out form before submitting if
  people
  >> want.
  >
  > Oh I see, I misunderstood. I personally don't have objections to that.

  Turns out that the first few pages are easy to fill and we already achieve
  them.
  The last few are much harder, and FFmpeg does not currently meet all of
  them.

  Here is the progress so far:
  https://bestpractices.coreinfrastructure.org/projects/235.

  I have filled them to the best of my ability.
  Here is a summary of where we fail to meet the criteria,
  and some suggestions for what we could do.
>>>
>>> [..]
>>>
  4. If the project software is an application or library, and its primary
  purpose is not to implement cryptography,
  then it SHOULD only call on software specifically designed to implement
  cryptographic functions;
  it SHOULD NOT re-implement its own.
  Note: This is one where I am personally interested as to why we fail; is
  it for performance reasons that we reimplement crypto?
  Suggestion: No idea until I understand the above.

  5. The project security mechanisms MUST use default keylengths that at
  least meet the NIST minimum requirements through the year 2030 (as stated
  in 2012).
  Suggestion: add --enable-unsafe-crypt to configure, and by default not
  enable it.
  Change API's and functions accordingly, document it.
  Note: strictly speaking, per the sentence above, it is ok as we do not
  really have "default" keylengths.
  But the extended rationale shows why we fail.

  6. The default project security mechanisms MUST NOT depend on
  cryptographic algorithms that are broken
  (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
  Suggestion: same as 5 above.
>>>
>>> We don't use any of these for security purposes, we only use them for
>>> checking frame hashes in automated tests. That should be totally fine.
>>
>> We do export them though. Just because the FFmpeg CLI progs don't use them 
>> for security,
>> does not mean a client does not, or that a client can be easily configured 
>> to not use them.
>> See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
>> for what I believe the intent of this requirement is.
>>
>> Second, are you sure about your claim?
>> md5 is used in httpauth per RFC 2617.
>> Now this is fixed by the RFC, but it does not mean FFmpeg needs to support 
>> it by default.
>> In particular, I don't see how this honestly takes care of 6.
>
> This is a rather bad example. The alternative to md5 password digests
> is not using digests at all and only use base64 "encoded" passwords.
> Would that be better? Certainly not. Its like calling every browser
> insecure because it supports md5 digests in the HTTP auth protocol.
> There just isn't a better variant, and disabling it would result in
> either incompat with HTTP servers using it, or fallback to even worse
> variants.
>
>>
>> In matroskaenc, mov, 160 bit SHA-1 is 

Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

[Petru Rares Sincraian]

Hi,


Many thanks to all :)


Here is the modified test with the first 20 frames only


From: ffmpeg-devel  on behalf of James Almer 

Sent: Monday, July 4, 2016 6:39:20 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

On 7/4/2016 1:34 PM, Petru Rares Sincraian wrote:
> How can I do that?

Add -aframes 20 to the command line
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 8a2bd8c71dc18b80e36e37efb4f600e68f52b846 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Mon, 4 Jul 2016 17:51:54 +0200
Subject: [PATCH] fate: add test for asetrate

---
 tests/fate/filter-audio.mak|  5 +
 tests/ref/fate/filter-asetrate | 25 +
 2 files changed, 30 insertions(+)
 create mode 100644 tests/ref/fate/filter-asetrate

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index a40755a..1a52320 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -89,6 +89,11 @@ fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-asetrate
+fate-filter-asetrate: tests/data/asynth-44100-2.wav
+fate-filter-asetrate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetrate: CMD = framecrc -i $(SRC) -aframes 20 -af asetrate=2
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-asetrate b/tests/ref/fate/filter-asetrate
new file mode 100644
index 000..e4487ae
--- /dev/null
+++ b/tests/ref/fate/filter-asetrate
@@ -0,0 +1,25 @@
+#tb 0: 1/2
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 2
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x29e3eecf
+0,   1024,   1024, 1024, 4096, 0x18390b96
+0,   2048,   2048, 1024, 4096, 0xc477fa99
+0,   3072,   3072, 1024, 4096, 0x3bc0f14f
+0,   4096,   4096, 1024, 4096, 0x2379ed91
+0,   5120,   5120, 1024, 4096, 0xfd6a0070
+0,   6144,   6144, 1024, 4096, 0x0b01f4cf
+0,   7168,   7168, 1024, 4096, 0x6716fd93
+0,   8192,   8192, 1024, 4096, 0x1840f25b
+0,   9216,   9216, 1024, 4096, 0x9c1ffaf1
+0,  10240,  10240, 1024, 4096, 0xcbedefaf
+0,  11264,  11264, 1024, 4096, 0x3e050390
+0,  12288,  12288, 1024, 4096, 0xb30e0090
+0,  13312,  13312, 1024, 4096, 0x26b8f75b
+0,  14336,  14336, 1024, 4096, 0xd706e311
+0,  15360,  15360, 1024, 4096, 0x0c480138
+0,  16384,  16384, 1024, 4096, 0x6c9a0216
+0,  17408,  17408, 1024, 4096, 0x7abce54f
+0,  18432,  18432, 1024, 4096, 0xda45f63f
+0,  19456,  19456, 1024, 4096, 0x50d5ff87
-- 
1.9.1

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Hendrik Leppkes]

On Tue, Jul 5, 2016 at 1:40 PM, Ganesh Ajjanagadde  wrote:
> 04.07.2016, 22:59, "Ronald S. Bultje" :
>> Hi,
>>
>> On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde  wrote:
>>
>>>  04.07.2016, 15:55, "Ronald S. Bultje" :
>>>  > Hi,
>>>  >
>>>  > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde 
>>>  wrote:
>>>  >
>>>  >> 04.07.2016, 15:36, "Ronald S. Bultje" :
>>>  >> > Hi,
>>>  >> >
>>>  >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
>>>  gajja...@mit.edu>
>>>  >> wrote:
>>>  >> >
>>>  >> >> 04.07.2016, 10:33, "Clément Bœsch" :
>>>  >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde >>  >
>>>  >> >> wrote:
>>>  >> >> >> Hi,
>>>  >> >> >>
>>>  >> >> >> https://bestpractices.coreinfrastructure.org/.
>>>  >> >> >>
>>>  >> >> >> Thoughts on getting this done for FFmpeg?
>>>  >> >> >
>>>  >> >> > Any thing we need to adjust in the project? I don't see much
>>>  things
>>>  >> to
>>>  >> >> > change by looking at
>>>  >> >> https://bestpractices.coreinfrastructure.org/projects/1
>>>  >> >>
>>>  >> >> I could not either.
>>>  >> >> It was something I noticed a week back, judged low-hanging and of
>>>  some
>>>  >> >> benefit to the project.
>>>  >> >> I thus am willing to do it, provided there are no objections.
>>>  >> >
>>>  >> > I think if any changes are necessary to the website or
>>>  documentation or
>>>  >> > code, these would simply go through the relevant review process,
>>>  right?
>>>  >> Or
>>>  >> > am I missing something?
>>>  >>
>>>  >> True. At the moment, it seems like the relevant forms can be filled in
>>>  >> directly from existing information,
>>>  >> and no changes are necessary.
>>>  >>
>>>  >> I can send a screenshot of the filled out form before submitting if
>>>  people
>>>  >> want.
>>>  >
>>>  > Oh I see, I misunderstood. I personally don't have objections to that.
>>>
>>>  Turns out that the first few pages are easy to fill and we already achieve
>>>  them.
>>>  The last few are much harder, and FFmpeg does not currently meet all of
>>>  them.
>>>
>>>  Here is the progress so far:
>>>  https://bestpractices.coreinfrastructure.org/projects/235.
>>>
>>>  I have filled them to the best of my ability.
>>>  Here is a summary of where we fail to meet the criteria,
>>>  and some suggestions for what we could do.
>>
>> [..]
>>
>>>  4. If the project software is an application or library, and its primary
>>>  purpose is not to implement cryptography,
>>>  then it SHOULD only call on software specifically designed to implement
>>>  cryptographic functions;
>>>  it SHOULD NOT re-implement its own.
>>>  Note: This is one where I am personally interested as to why we fail; is
>>>  it for performance reasons that we reimplement crypto?
>>>  Suggestion: No idea until I understand the above.
>>>
>>>  5. The project security mechanisms MUST use default keylengths that at
>>>  least meet the NIST minimum requirements through the year 2030 (as stated
>>>  in 2012).
>>>  Suggestion: add --enable-unsafe-crypt to configure, and by default not
>>>  enable it.
>>>  Change API's and functions accordingly, document it.
>>>  Note: strictly speaking, per the sentence above, it is ok as we do not
>>>  really have "default" keylengths.
>>>  But the extended rationale shows why we fail.
>>>
>>>  6. The default project security mechanisms MUST NOT depend on
>>>  cryptographic algorithms that are broken
>>>  (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
>>>  Suggestion: same as 5 above.
>>
>> We don't use any of these for security purposes, we only use them for
>> checking frame hashes in automated tests. That should be totally fine.
>
> We do export them though. Just because the FFmpeg CLI progs don't use them 
> for security,
> does not mean a client does not, or that a client can be easily configured to 
> not use them.
> See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
> for what I believe the intent of this requirement is.
>
> Second, are you sure about your claim?
> md5 is used in httpauth per RFC 2617.
> Now this is fixed by the RFC, but it does not mean FFmpeg needs to support it 
> by default.
> In particular, I don't see how this honestly takes care of 6.

This is a rather bad example. The alternative to md5 password digests
is not using digests at all and only use base64 "encoded" passwords.
Would that be better? Certainly not. Its like calling every browser
insecure because it supports md5 digests in the HTTP auth protocol.
There just isn't a better variant, and disabling it would result in
either incompat with HTTP servers using it, or fallback to even worse
variants.

>
> In matroskaenc, mov, 160 bit SHA-1 is used.
> Unless someone who knows the code well, audits the codebase, and checks
> that the SHA-1 and the like are not really for security here (similar to the 
> git model),
> 5 also has problems IMHO.

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ronald S. Bultje]

Hi,

On Tue, Jul 5, 2016 at 7:40 AM, Ganesh Ajjanagadde  wrote:

> 04.07.2016, 22:59, "Ronald S. Bultje" :
> > Hi,
> >
> > On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde 
> wrote:
> >
> >>  04.07.2016, 15:55, "Ronald S. Bultje" :
> >>  > Hi,
> >>  >
> >>  > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  >
> >>  wrote:
> >>  >
> >>  >> 04.07.2016, 15:36, "Ronald S. Bultje" :
> >>  >> > Hi,
> >>  >> >
> >>  >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
> >>  gajja...@mit.edu>
> >>  >> wrote:
> >>  >> >
> >>  >> >> 04.07.2016, 10:33, "Clément Bœsch" :
> >>  >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde <
> gajja...@mit.edu
> >>  >
> >>  >> >> wrote:
> >>  >> >> >> Hi,
> >>  >> >> >>
> >>  >> >> >> https://bestpractices.coreinfrastructure.org/.
> >>  >> >> >>
> >>  >> >> >> Thoughts on getting this done for FFmpeg?
> >>  >> >> >
> >>  >> >> > Any thing we need to adjust in the project? I don't see much
> >>  things
> >>  >> to
> >>  >> >> > change by looking at
> >>  >> >> https://bestpractices.coreinfrastructure.org/projects/1
> >>  >> >>
> >>  >> >> I could not either.
> >>  >> >> It was something I noticed a week back, judged low-hanging and of
> >>  some
> >>  >> >> benefit to the project.
> >>  >> >> I thus am willing to do it, provided there are no objections.
> >>  >> >
> >>  >> > I think if any changes are necessary to the website or
> >>  documentation or
> >>  >> > code, these would simply go through the relevant review process,
> >>  right?
> >>  >> Or
> >>  >> > am I missing something?
> >>  >>
> >>  >> True. At the moment, it seems like the relevant forms can be filled
> in
> >>  >> directly from existing information,
> >>  >> and no changes are necessary.
> >>  >>
> >>  >> I can send a screenshot of the filled out form before submitting if
> >>  people
> >>  >> want.
> >>  >
> >>  > Oh I see, I misunderstood. I personally don't have objections to
> that.
> >>
> >>  Turns out that the first few pages are easy to fill and we already
> achieve
> >>  them.
> >>  The last few are much harder, and FFmpeg does not currently meet all of
> >>  them.
> >>
> >>  Here is the progress so far:
> >>  https://bestpractices.coreinfrastructure.org/projects/235.
> >>
> >>  I have filled them to the best of my ability.
> >>  Here is a summary of where we fail to meet the criteria,
> >>  and some suggestions for what we could do.
> >
> > [..]
> >
> >>  4. If the project software is an application or library, and its
> primary
> >>  purpose is not to implement cryptography,
> >>  then it SHOULD only call on software specifically designed to implement
> >>  cryptographic functions;
> >>  it SHOULD NOT re-implement its own.
> >>  Note: This is one where I am personally interested as to why we fail;
> is
> >>  it for performance reasons that we reimplement crypto?
> >>  Suggestion: No idea until I understand the above.
> >>
> >>  5. The project security mechanisms MUST use default keylengths that at
> >>  least meet the NIST minimum requirements through the year 2030 (as
> stated
> >>  in 2012).
> >>  Suggestion: add --enable-unsafe-crypt to configure, and by default not
> >>  enable it.
> >>  Change API's and functions accordingly, document it.
> >>  Note: strictly speaking, per the sentence above, it is ok as we do not
> >>  really have "default" keylengths.
> >>  But the extended rationale shows why we fail.
> >>
> >>  6. The default project security mechanisms MUST NOT depend on
> >>  cryptographic algorithms that are broken
> >>  (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
> >>  Suggestion: same as 5 above.
> >
> > We don't use any of these for security purposes, we only use them for
> > checking frame hashes in automated tests. That should be totally fine.
>
> We do export them though. Just because the FFmpeg CLI progs don't use them
> for security,
> does not mean a client does not, or that a client can be easily configured
> to not use them.
> See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
> for what I believe the intent of this requirement is.
>
> Second, are you sure about your claim?
> md5 is used in httpauth per RFC 2617.
> Now this is fixed by the RFC, but it does not mean FFmpeg needs to support
> it by default.
> In particular, I don't see how this honestly takes care of 6.
>

I don't know if we can be held responsible for what clients do. The intent
of 6 is for our software, not client software, right?

We can add an option to httpauth to allow disabling md5 encryption in the
list of supported encryption protocols (if such an option doesn't already
exist). But I certainly wouldn't go beyond that.


> In matroskaenc, mov, 160 bit SHA-1 is used.
> Unless someone who knows the code well, audits the codebase, and checks
> that the SHA-1 and the like are not really for security here (similar to
> the git model),
> 5 also 

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

04.07.2016, 22:59, "Ronald S. Bultje" :
> Hi,
>
> On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde  wrote:
>
>>  04.07.2016, 15:55, "Ronald S. Bultje" :
>>  > Hi,
>>  >
>>  > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde 
>>  wrote:
>>  >
>>  >> 04.07.2016, 15:36, "Ronald S. Bultje" :
>>  >> > Hi,
>>  >> >
>>  >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
>>  gajja...@mit.edu>
>>  >> wrote:
>>  >> >
>>  >> >> 04.07.2016, 10:33, "Clément Bœsch" :
>>  >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde >  >
>>  >> >> wrote:
>>  >> >> >> Hi,
>>  >> >> >>
>>  >> >> >> https://bestpractices.coreinfrastructure.org/.
>>  >> >> >>
>>  >> >> >> Thoughts on getting this done for FFmpeg?
>>  >> >> >
>>  >> >> > Any thing we need to adjust in the project? I don't see much
>>  things
>>  >> to
>>  >> >> > change by looking at
>>  >> >> https://bestpractices.coreinfrastructure.org/projects/1
>>  >> >>
>>  >> >> I could not either.
>>  >> >> It was something I noticed a week back, judged low-hanging and of
>>  some
>>  >> >> benefit to the project.
>>  >> >> I thus am willing to do it, provided there are no objections.
>>  >> >
>>  >> > I think if any changes are necessary to the website or
>>  documentation or
>>  >> > code, these would simply go through the relevant review process,
>>  right?
>>  >> Or
>>  >> > am I missing something?
>>  >>
>>  >> True. At the moment, it seems like the relevant forms can be filled in
>>  >> directly from existing information,
>>  >> and no changes are necessary.
>>  >>
>>  >> I can send a screenshot of the filled out form before submitting if
>>  people
>>  >> want.
>>  >
>>  > Oh I see, I misunderstood. I personally don't have objections to that.
>>
>>  Turns out that the first few pages are easy to fill and we already achieve
>>  them.
>>  The last few are much harder, and FFmpeg does not currently meet all of
>>  them.
>>
>>  Here is the progress so far:
>>  https://bestpractices.coreinfrastructure.org/projects/235.
>>
>>  I have filled them to the best of my ability.
>>  Here is a summary of where we fail to meet the criteria,
>>  and some suggestions for what we could do.
>
> [..]
>
>>  4. If the project software is an application or library, and its primary
>>  purpose is not to implement cryptography,
>>  then it SHOULD only call on software specifically designed to implement
>>  cryptographic functions;
>>  it SHOULD NOT re-implement its own.
>>  Note: This is one where I am personally interested as to why we fail; is
>>  it for performance reasons that we reimplement crypto?
>>  Suggestion: No idea until I understand the above.
>>
>>  5. The project security mechanisms MUST use default keylengths that at
>>  least meet the NIST minimum requirements through the year 2030 (as stated
>>  in 2012).
>>  Suggestion: add --enable-unsafe-crypt to configure, and by default not
>>  enable it.
>>  Change API's and functions accordingly, document it.
>>  Note: strictly speaking, per the sentence above, it is ok as we do not
>>  really have "default" keylengths.
>>  But the extended rationale shows why we fail.
>>
>>  6. The default project security mechanisms MUST NOT depend on
>>  cryptographic algorithms that are broken
>>  (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
>>  Suggestion: same as 5 above.
>
> We don't use any of these for security purposes, we only use them for
> checking frame hashes in automated tests. That should be totally fine.

We do export them though. Just because the FFmpeg CLI progs don't use them for 
security,
does not mean a client does not, or that a client can be easily configured to 
not use them.
See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
for what I believe the intent of this requirement is.

Second, are you sure about your claim?
md5 is used in httpauth per RFC 2617.
Now this is fixed by the RFC, but it does not mean FFmpeg needs to support it 
by default.
In particular, I don't see how this honestly takes care of 6.

In matroskaenc, mov, 160 bit SHA-1 is used.
Unless someone who knows the code well, audits the codebase, and checks
that the SHA-1 and the like are not really for security here (similar to the 
git model),
5 also has problems IMHO.

As for reimplementing crypto, AES encryption is done in lavf/srtp.c.
We thus do not meet 4, though this is not a "must" requirement. 

>
> Ronald
> ___
> 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]ffmpeg: Do not set too large bits_per_raw_sample

[Carl Eugen Hoyos]

On Tuesday 05 July 2016 12:36:53 am Michael Niedermayer wrote:
> On Sun, May 01, 2016 at 05:11:08PM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch stops setting bits_per_raw_sample if it makes no sense as
> > for example in the wmall24 -> pcm_s16 case:
> > Stream #0:0: Audio: pcm_s16le, 96000 Hz, stereo, s16 (24 bit), 3072
> > kb/s
> >
> > Mostly tested with audio.
> >
> > Please comment, Carl Eugen
> >
> >  ffmpeg.c |7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 1a672d3fd9fe8e65d2ad9a4271fe5260a888e28a  patchrawsample.diff
> > diff --git a/ffmpeg.c b/ffmpeg.c
> > index adc3ff7..86bc518 100644
> > --- a/ffmpeg.c
> > +++ b/ffmpeg.c
> > @@ -2859,7 +2859,6 @@ static int transcode_init(void)
> >  dec_ctx = ist->dec_ctx;
> >
> >  ost->st->disposition  = ist->st->disposition;
> > -enc_ctx->bits_per_raw_sample=
> > dec_ctx->bits_per_raw_sample; enc_ctx->chroma_sample_location =
> > dec_ctx->chroma_sample_location; } else {
> >  for (j=0; jnb_streams; j++) {
> > @@ -3100,6 +3099,9 @@ static int transcode_init(void)
> >  switch (enc_ctx->codec_type) {
> >  case AVMEDIA_TYPE_AUDIO:
> >  enc_ctx->sample_fmt =
> > ost->filter->filter->inputs[0]->format; +if (dec_ctx)
> > +enc_ctx->bits_per_raw_sample =
> > FFMIN(dec_ctx->bits_per_raw_sample, +
> > av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
> > enc_ctx->sample_rate= ost->filter->filter->inputs[0]->sample_rate;
> > enc_ctx->channel_layout = ost->filter->filter->inputs[0]->channel_layout;
> > enc_ctx->channels   =
> > avfilter_link_get_channels(ost->filter->filter->inputs[0]); @@ -3140,6
> > +3142,9 @@ static int transcode_init(void)
> > "Use -pix_fmt yuv420p for compatibility with
> > outdated media players.\n",
> > av_get_pix_fmt_name(ost->filter->filter->inputs[0]->format));
> > enc_ctx->pix_fmt = ost->filter->filter->inputs[0]->format; + 
> >   if (dec_ctx)
> > +enc_ctx->bits_per_raw_sample =
> > FFMIN(dec_ctx->bits_per_raw_sample, +
> >
> > av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth);
>
> these 2 are missing the stream copy case above

New patch attached.

Thank you, Carl Eugen
From fc564ed83ddf55b9ae783044ad0884803d27d9a7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 5 Jul 2016 11:50:00 +0200
Subject: [PATCH] ffmpeg: Do not set too large bits_per_raw_sample.

---
 ffmpeg.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 9ffd833..46cc14e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2859,7 +2859,6 @@ static int transcode_init(void)
 dec_ctx = ist->dec_ctx;
 
 ost->st->disposition  = ist->st->disposition;
-enc_ctx->bits_per_raw_sample= dec_ctx->bits_per_raw_sample;
 enc_ctx->chroma_sample_location = dec_ctx->chroma_sample_location;
 } else {
 for (j=0; jnb_streams; j++) {
@@ -2909,6 +2908,7 @@ static int transcode_init(void)
 }
 enc_ctx->extradata_size= dec_ctx->extradata_size;
 enc_ctx->bits_per_coded_sample  = dec_ctx->bits_per_coded_sample;
+enc_ctx->bits_per_raw_sample= dec_ctx->bits_per_raw_sample;
 
 enc_ctx->time_base = ist->st->time_base;
 /*
@@ -3110,6 +3110,9 @@ static int transcode_init(void)
 switch (enc_ctx->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
 enc_ctx->sample_fmt = 
ost->filter->filter->inputs[0]->format;
+if (dec_ctx)
+enc_ctx->bits_per_raw_sample = 
FFMIN(dec_ctx->bits_per_raw_sample,
+ 
av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
 enc_ctx->sample_rate= 
ost->filter->filter->inputs[0]->sample_rate;
 enc_ctx->channel_layout = 
ost->filter->filter->inputs[0]->channel_layout;
 enc_ctx->channels   = 
avfilter_link_get_channels(ost->filter->filter->inputs[0]);
@@ -3150,6 +3153,9 @@ static int transcode_init(void)
"Use -pix_fmt yuv420p for compatibility with 
outdated media players.\n",

av_get_pix_fmt_name(ost->filter->filter->inputs[0]->format));
 enc_ctx->pix_fmt = ost->filter->filter->inputs[0]->format;
+if (dec_ctx)
+enc_ctx->bits_per_raw_sample = 
FFMIN(dec_ctx->bits_per_raw_sample,
+ 
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth);
 
 ost->st->avg_frame_rate = ost->frame_rate;
 
-- 
1.7.10.4

___
ffmpeg-devel 

Re: [FFmpeg-devel] libavcodec/exr : add support for gray and gray A file

[Martin Vignali]

2016-06-28 0:05 GMT+02:00 Martin Vignali :

> Hello,
>
> in attach a patch to add support for Y and YA exr file
> (ticket #5621)
>
> sample can be found in this ticket,
> https://trac.ffmpeg.org/ticket/5621
>
> or in the official samples
>
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
>
> pass exr fate test.
>
>
> The second patch is only indent.
>
>
> Comments welcome
>
> Martin
> Jokyo Images
>


Ping
From 949e4fa6571229d7253a90fdd8ca3946f8cc54ac Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 27 Jun 2016 23:52:39 +0200
Subject: [PATCH 1/2] libavodec/exr : add support for Y and YA file (ticket
 #5621)

a gray channel in exr, is named Y
we admit that the file need to be interpreted as gray
only if no other channel match (except alpha)

to manage RGB and Y in the color conversion part of decode_block,
the color processing is now made with a for loop.
---
 libavcodec/exr.c | 103 ---
 1 file changed, 61 insertions(+), 42 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index c87187c..46e8312 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -129,6 +129,8 @@ typedef struct EXRContext {
 EXRTileAttribute tile_attr; /* header data attribute of tile */
 int is_tile; /* 0 if scanline, 1 if tile */
 
+int is_luma;/* 1 if there is an Y plane */
+
 GetByteContext gb;
 const uint8_t *buf;
 int buf_size;
@@ -1016,6 +1018,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 int axmax = (avctx->width - (s->xmax + 1)) * 2 * s->desc->nb_components; /* nb pixel to add at the right of the datawindow */
 int bxmin = s->xmin * 2 * s->desc->nb_components; /* nb pixel to add at the left of the datawindow */
 int i, x, buf_size = s->buf_size;
+int c, rgb_channel_count;
 float one_gamma = 1.0f / s->gamma;
 avpriv_trc_function trc_func = avpriv_get_trc_function_from_trc(s->apply_trc_type);
 int ret;
@@ -1125,9 +1128,15 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 src = td->uncompressed_data;
 }
 
+if (!s->is_luma) {
 channel_buffer[0] = src + td->xsize * s->channel_offsets[0];
 channel_buffer[1] = src + td->xsize * s->channel_offsets[1];
 channel_buffer[2] = src + td->xsize * s->channel_offsets[2];
+rgb_channel_count = 3;
+} else { /* put y data in the first channel_buffer */
+channel_buffer[0] = src + td->xsize * s->channel_offsets[1];
+rgb_channel_count = 1;
+}
 if (s->channel_offsets[3] >= 0)
 channel_buffer[3] = src + td->xsize * s->channel_offsets[3];
 
@@ -1136,11 +1145,13 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 for (i = 0;
  i < td->ysize; i++, ptr += p->linesize[0]) {
 
-const uint8_t *r, *g, *b, *a;
+const uint8_t * a;
+const uint8_t *rgb[3];
+
+for (c = 0; c < rgb_channel_count; c++){
+rgb[c] = channel_buffer[c];
+}
 
-r = channel_buffer[0];
-g = channel_buffer[1];
-b = channel_buffer[2];
 if (channel_buffer[3])
 a = channel_buffer[3];
 
@@ -1155,37 +1166,26 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (trc_func) {
 for (x = 0; x < td->xsize; x++) {
 union av_intfloat32 t;
-t.i = bytestream_get_le32();
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32();
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
 
-t.i = bytestream_get_le32();
-t.f = trc_func(t.f);
-*ptr_x++ = exr_flt2uint(t.i);
+for (c = 0; c < rgb_channel_count; c++) {
+t.i = bytestream_get_le32([c]);
+t.f = trc_func(t.f);
+*ptr_x++ = exr_flt2uint(t.i);
+}
 if (channel_buffer[3])
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 } else {
 for (x = 0; x < td->xsize; x++) {
 union av_intfloat32 t;
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)  /* avoid negative values */
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
+
+for 

Re: [FFmpeg-devel] [PATCH 6/6] libavformat/movenc: add dnxhr compatibility for apple players

[Carl Eugen Hoyos]

Mark Reid  gmail.com> writes:

>  if (track->vos_data && track->vos_len > 0x29) {
> -if (track->vos_data[0] == 0x00 &&
> -track->vos_data[1] == 0x00 &&
> -track->vos_data[2] == 0x02 &&
> -track->vos_data[3] == 0x80 &&
> -(track->vos_data[4] == 0x01 || track->vos_data[4] == 0x02)) {
> +if (avpriv_dnxhd_parse_header_prefix(track->vos_data) != 0) {

This hunk and the two following hunks look unrelated 
to me.
They could be ok independently of the other change.

Carl Eugen

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Thilo Borgmann]

Am 04.07.16 um 21:29 schrieb Ganesh Ajjanagadde:
> 04.07.2016, 10:33, "Clément Bœsch" :
>>  On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  wrote:
>>>   Hi,
>>>
>>>   https://bestpractices.coreinfrastructure.org/.
>>>
>>>   Thoughts on getting this done for FFmpeg?
>>
>>  Any thing we need to adjust in the project? I don't see much things to
>>  change by looking at https://bestpractices.coreinfrastructure.org/projects/1
> 
> 
> I could not either.
> It was something I noticed a week back, judged low-hanging and of some 
> benefit to the project.
> I thus am willing to do it, provided there are no objections.

Sounds like a good idea to me. Thanks for handling it!

-Thilo

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

Re: [FFmpeg-devel] [PATCH] Added Quadrox format

[Michael Niedermayer]

On Mon, Jul 04, 2016 at 06:13:50AM +0530, smitbose wrote:
> ---
>  libavformat/riff.c | 1 +
>  1 file changed, 1 insertion(+)

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] mediacodecdec_h264: properly convert extradata to annex-b

[Benoit Fouet]

Hi,

On 04/07/2016 10:12, Matthieu Bouron wrote:

From: Matthieu Bouron 

H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
converted to NAL units before sending them to MediaCodec.

This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
which makes the resulting NAL units correct.

Fixes codec initialization on Nexus 4 and Nexus 7.
---
  libavcodec/mediacodecdec_h264.c | 69 +
  1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 0664e49..f07c7cc 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -65,6 +65,54 @@ static av_cold int mediacodec_decode_close(AVCodecContext 
*avctx)
  return 0;
  }
  
+static int h264_ps_to_nalu(const uint8_t *src, int src_size, uint8_t **out, int *out_size)

+{
+int i;
+int ret = 0;
+uint8_t *p = NULL;
+static const uint8_t nalu_header[] = { 0x00, 0x00, 0x00, 0x01 };
+
+if (!out) {
+return AVERROR(EINVAL);
+}
+


out_size should also be checked


+*out_size = sizeof(nalu_header) + src_size;
+*out = p = av_malloc(*out_size);
+if (!*out) {
+return AVERROR(ENOMEM);
+}
+


nit: the size affectation could be done once the allocation is OK.


+memcpy(p, nalu_header, sizeof(nalu_header));
+memcpy(p + sizeof(nalu_header), src, src_size);
+
+/* Escape 0x00, 0x00, 0x0{0-3} pattern */
+for (i = 4; i < *out_size; i++) {
+if (i < *out_size - 3 &&
+p[i + 0] == 0 &&
+p[i + 1] == 0 &&
+p[i + 2] <= 3) {
+uint8_t *new;
+
+*out_size += 1;
+new = av_realloc(*out, *out_size);
+if (!new) {
+ret = AVERROR(ENOMEM);
+goto done;
+}
+*out = p = new;
+
+i = i + 3;
+memmove(p + i, p + i - 1, *out_size - i);
+p[i - 1] = 0x03;
+}
+}
+done:
+if (ret < 0)
+av_freep(out);
+
+return ret;
+}
+
  static av_cold int mediacodec_decode_init(AVCodecContext *avctx)
  {
  int i;
@@ -112,24 +160,19 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
  }
  
  if (pps && sps) {

-static const uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
-
  uint8_t *data = NULL;
-size_t data_size = sizeof(nal_headers) + FFMAX(sps->data_size, 
pps->data_size);
+size_t data_size = 0;
  
-data = av_mallocz(data_size);

-if (!data) {
-ret = AVERROR(ENOMEM);
+if ((ret = h264_ps_to_nalu(sps->data, sps->data_size, , _size)) 
< 0) {
  goto done;
  }
+ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, data_size);
+av_freep();
  
-memcpy(data, nal_headers, sizeof(nal_headers));

-memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, 
sizeof(nal_headers) + sps->data_size);
-
-memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, 
sizeof(nal_headers) + pps->data_size);
-
+if ((ret = h264_ps_to_nalu(pps->data, pps->data_size, , _size)) 
< 0) {
+goto done;
+}
+ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, data_size);
  av_freep();
  } else {
  av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from 
extradata");


LGTM otherwise

--
Ben

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

Re: [FFmpeg-devel] [PATCH 1/5] lavf: add cue sheet demuxer

[Nicolas George]

Le septidi 17 messidor, an CCXXIV, Rodger Combs a écrit :
> +- Cue sheet demuxer

This is interesting. Just a quick remark while I have time:

> +} else if (!strncmp(ptr, "FILE ", 5)) {
> +if (!cue->url || !*cue->url) {
> +char url[4096] = {0};
> +av_freep(>url);
> +ff_make_absolute_url(url, sizeof(url), s->filename, 
> get_token(ptr + 5));
> +if (!(cue->url = av_strdup(url)))
> +return AVERROR(ENOMEM);
> +}

> +if ((ret = avformat_open_input(>avf, cue->url, NULL, NULL)) < 0 ||
> +(ret = avformat_find_stream_info(cue->avf, NULL)) < 0) {
> +av_log(s, AV_LOG_ERROR, "Failed to open '%s'\n", cue->url);
> +avformat_close_input(>avf);
> +return ret;
> +}

That makes yet another format that can open arbitrary URLs depending on
external contents: security issue.

The check for safe/unsafe URLs needs to be factored.

Also, there is the matter of the io_open() callback to check, I do not
remember how it works.

Regards,

-- 
  Nicolas George


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