[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

From: Matthieu Bouron 

---

Hi,

This commit is likely to break fate on arm since the current C code path
seems to use less precision.

How should I proceed to fix it ?

Matthieu

---
 libswscale/arm/swscale_unscaled.c | 53 ---
 libswscale/arm/yuv2rgb_neon.S | 77 ---
 2 files changed, 119 insertions(+), 11 deletions(-)

diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index dbb0fb0..058ebea 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -63,6 +63,51 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context, 
const uint8_t *src[
 }
 #endif
 
+#define YUV_TO_RGB_TABLE(precision)
 \
+c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+
+#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)  
 \
+int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,  
 \
+ uint8_t *dst, int linesize,   
 \
+ const uint8_t *srcY, int linesizeY,   
 \
+ const uint8_t *srcU, int linesizeU,   
 \
+ const uint8_t *srcV, int linesizeV,   
 \
+ const int16_t *table, 
 \
+ int y_offset, 
 \
+ int y_coeff); 
 \
+   
 \
+static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[],\
+   int srcStride[], int srcSliceY, int 
srcSliceH,   \
+   uint8_t *dst[], int dstStride[]) {  
 \
+const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };   
 \
+   
 \
+ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
 \
+ dst[0] +  srcSliceY  * dstStride[0], 
dstStride[0], \
+ src[0] +  srcSliceY  * srcStride[0], 
srcStride[0], \
+ src[1] + (srcSliceY / 2) * srcStride[1], 
srcStride[1], \
+ src[2] + (srcSliceY / 2) * srcStride[2], 
srcStride[2], \
+ yuv2rgb_table,
 \
+ c->yuv2rgb_y_offset >> 9, 
 \
+ c->yuv2rgb_y_coeff / ((precision) == 16 ? 1 
<< 7 : 1));\
+   
 \
+return 0;  
 \
+}  
 \
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)  
 \
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS 
 \
+DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)   
 \
+DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(32)   
 \
+
+DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
+
 #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
 \
 int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h, 
 \
  uint8_t *dst, int linesize,   
 \
@@ -75,12 +120,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
 static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[], \

[FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/yuv2rgb_neon.S | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 01d8536..9f9dd2a 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -226,13 +226,7 @@ function ff_\ifmt\()_to_\ofmt\()_neon_\precision\(), 
export=1
 vsubl.u8q15, d2, d10   @ q15 = 
V - 128
 .endif
 
-.ifc \precision,16
-process_16px_16 \ofmt
-.endif
-
-.ifc \precision,32
-process_16px_32 \ofmt
-.endif
+process_16px_\precision \ofmt
 
 subsr8, r8, #16@ width 
-= 16
 bgt 2b
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
> 
> Hi,
> 
> This commit is likely to break fate on arm since the current C code path
> seems to use less precision.
> 
> How should I proceed to fix it ?

hmm
can the precission of the C code path and any asm impl of it under
bitexact (if they exist), be changed to higher precission without
speedloss?
if so that would be an option

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] Patch question

[Mats Peterson]

On 12/15/2015 05:49 PM, Moritz Barsnick wrote:

Hi Mats,

On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:

Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?


"It depends." ;-)

By the way, git handles this kind of stuff nicely.

It may or may not work. Obviously, if the file hasn't changed upstream,
your patch will still apply.

a) Best case: The files haven't changed upstream, your diff still
applies.
b) Good case: Upstream changed only unrelated parts of those file, your
diff applies, perhaps with an offset (i.e. shifted in line numbers).
b2) Almost as good: The unrelated changes are close to your changes, so
you get a so-called fuzz.
c) Bad case: Related parts were changed. Your diff won't apply, you
have to reintegrate your changes, perhaps even differently.
d) Worse case: Your patch applies, but affected methods were
incompatibly changed. This leads to build or runtime errors, or
broken functionality.

It's always a good idea to check upstream changes to see whether they
affect your patch. Most likely, a) or b) applies, but you don't know
until you've checked. :-)

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



Thanks for the enlightening answer, Moritz. Now I don't possess an 
enormous amount of Git experience, but I guess it's best to get the 
latest version from Git before providing any new patches. It makes life 
easier for the potential testers, of course.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fix http chunk encoding parsing

[Eugene Kosov]

---
 ffserver.c | 77 --
 1 file changed, 50 insertions(+), 27 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 029771c..b7f9616 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -138,7 +138,7 @@ typedef struct HTTPContext {
 int http_error;
 int post;
 int chunked_encoding;
-int chunk_size;   /* 0 if it needs to be read */
+int chunk_size; /* 0 if it needs to be read; negative if reading chunk 
footer */
 struct HTTPContext *next;
 int got_key_frame; /* stream 0 => 1, stream 1 => 2, stream 2=> 4 */
 int64_t data_count;
@@ -2598,36 +2598,37 @@ static int http_receive_data(HTTPContext *c)
 {
 HTTPContext *c1;
 int len, loop_run = 0;
+char buf[16];
+int buf_len = 0;
+
+if (c->chunked_encoding && c->chunk_size == 0) {
+for (;;) {
+/* read chunk header, if present */
+len = recv(c->fd, buf + buf_len, 1, 0);
+buf_len += len;
+
+if (len < 0) {
+if (ff_neterrno() != AVERROR(EAGAIN) &&
+ff_neterrno() != AVERROR(EINTR))
+/* error : close connection */
+goto fail;
+return 0;
+}
 
-while (c->chunked_encoding && !c->chunk_size &&
-   c->buffer_end > c->buffer_ptr) {
-/* read chunk header, if present */
-len = recv(c->fd, c->buffer_ptr, 1, 0);
-
-if (len < 0) {
-if (ff_neterrno() != AVERROR(EAGAIN) &&
-ff_neterrno() != AVERROR(EINTR))
-/* error : close connection */
+if (len == 0 || ++loop_run > 10)
+/* end of connection or no chunk size : close it */
 goto fail;
-return 0;
-} else if (len == 0) {
-/* end of connection : close it */
-goto fail;
-} else if (c->buffer_ptr - c->buffer >= 2 &&
-   !memcmp(c->buffer_ptr - 1, "\r\n", 2)) {
-c->chunk_size = strtol(c->buffer, 0, 16);
-if (c->chunk_size == 0) // end of stream
-goto fail;
-c->buffer_ptr = c->buffer;
-break;
-} else if (++loop_run > 10)
-/* no chunk header, abort */
-goto fail;
-else
-c->buffer_ptr++;
+
+if (buf_len > 1 && !memcmp(buf + buf_len - 2, "\r\n", 2)) {
+c->chunk_size = strtol(buf, 0, 16);
+if (c->chunk_size == 0) // end of stream
+goto fail;
+break;
+}
+}
 }
 
-if (c->buffer_end > c->buffer_ptr) {
+if (c->buffer_end > c->buffer_ptr && c->chunk_size > 0) {
 len = recv(c->fd, c->buffer_ptr,
FFMIN(c->chunk_size, c->buffer_end - c->buffer_ptr), 0);
 if (len < 0) {
@@ -2644,6 +2645,28 @@ static int http_receive_data(HTTPContext *c)
 c->data_count += len;
 update_datarate(>datarate, c->data_count);
 }
+
+// Reading of chunk body is done. Now read 2 bytes of chunk footer.
+if (!c->chunk_size)
+c->chunk_size = -2;
+}
+
+if (c->chunked_encoding && c->chunk_size < 0) {
+while (c->chunk_size < 0) {
+len = recv(c->fd, buf, 1, 0);
+if (len < 0) {
+if (ff_neterrno() != AVERROR(EAGAIN) &&
+ff_neterrno() != AVERROR(EINTR))
+/* error : close connection */
+goto fail;
+return 0;
+}
+if (len == 0) {
+goto fail;
+}
+
+c->chunk_size += len;
+}
 }
 
 if (c->buffer_ptr - c->buffer >= 2 && c->data_count > FFM_PACKET_SIZE) {
-- 
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Derek Buitenhuis]

On 12/15/2015 10:44 AM, Jean Delvare wrote:
> Originally I proposed this patch for performance reasons and also
> because I think it makes the code more readable. But seeing how the
> same cast is already present everywhere in the ffmpeg code, I would now
> also invoke consistency. There's no rationale for not doing the same
> here that is already done everywhere else. If it caused any problem we
> would know by now (and I verified that this patch passes the test
> suite, FWIW.)

I'd argue we should fix those instead. Some work on that has already been done,
such as 60392480181f24ebf3ab48d8ac3614705de90152.

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

Re: [FFmpeg-devel] Patch question

[Moritz Barsnick]

Hi Mats,

On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
> Sorry if this may sound idiotic, but if I provide a unified patch for a 
> file that is newer/different from the one I have here, it won't work, right?

"It depends." ;-)

By the way, git handles this kind of stuff nicely.

It may or may not work. Obviously, if the file hasn't changed upstream,
your patch will still apply.

a) Best case: The files haven't changed upstream, your diff still
   applies.
b) Good case: Upstream changed only unrelated parts of those file, your
   diff applies, perhaps with an offset (i.e. shifted in line numbers).
b2) Almost as good: The unrelated changes are close to your changes, so
   you get a so-called fuzz.
c) Bad case: Related parts were changed. Your diff won't apply, you
   have to reintegrate your changes, perhaps even differently.
d) Worse case: Your patch applies, but affected methods were
   incompatibly changed. This leads to build or runtime errors, or
   broken functionality.

It's always a good idea to check upstream changes to see whether they
affect your patch. Most likely, a) or b) applies, but you don't know
until you've checked. :-)

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

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Derek Buitenhuis]

On 12/15/2015 5:23 PM, Jean Delvare wrote:
> Looks like something different from what we were discussing here.

In which way?

That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?

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

[FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska

[Mats Peterson]

Here is a *suggestion* for how to end the QuickTime palette in Matroska 
saga. I have created a new file 'qtpalette.c' with a function 
get_qtpalette(), that will be called from both matroskadec.c and mov.c. 
So, no more calling into another demuxer to get the palette, and no 
duplicated code, since it is more or less moved from mov.c to this new 
file. The mov_parse_stsd_video() function in mov.c is rather heavily 
modified as a consequence. Now, please forgive me for not splitting it 
up, but I hope that someone will be able to try it out in spite of this.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/


libavformat-patches.tar.gz
Description: GNU Zip compressed data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Jean Delvare]

On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote:
> On 12/15/2015 10:44 AM, Jean Delvare wrote:
> > Originally I proposed this patch for performance reasons and also
> > because I think it makes the code more readable. But seeing how the
> > same cast is already present everywhere in the ffmpeg code, I would now
> > also invoke consistency. There's no rationale for not doing the same
> > here that is already done everywhere else. If it caused any problem we
> > would know by now (and I verified that this patch passes the test
> > suite, FWIW.)
> 
> I'd argue we should fix those instead. Some work on that has already been 
> done,
> such as 60392480181f24ebf3ab48d8ac3614705de90152.

Looks like something different from what we were discussing here.

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska

[Mats Peterson]

On 12/15/2015 06:51 PM, Mats Peterson wrote:

Here is a *suggestion* for how to end the QuickTime palette in Matroska
saga. I have created a new file 'qtpalette.c' with a function
get_qtpalette(), that will be called from both matroskadec.c and mov.c.
So, no more calling into another demuxer to get the palette, and no
duplicated code, since it is more or less moved from mov.c to this new
file. The mov_parse_stsd_video() function in mov.c is rather heavily
modified as a consequence. Now, please forgive me for not splitting it
up, but I hope that someone will be able to try it out in spite of this.

Mats



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



Once again, test files with palettized video, both QuickTime and 
Matroska, can be found at 
https://drive.google.com/open?id=0B3_pEBoLs0faWElmM2FnLTZYNlk


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

[Zhu Hongbo]

I found that the ffmpeg  H.265 decoder can't run on the iOS platform when I 
enable the neon assembly code, it crashed when playing the H.265 clip. When 
disable the neon assembly code it works fine. What's the problem with the H.265 
neon assembly code?

Best regards,
Zhuhb


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

Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph

[Michael Niedermayer]

On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron 
> wrote:
> 
> > From: Matthieu Bouron 
> >
> > ---
> >  libavfilter/avfilter.c |  1 +
> >  libavfilter/avfilter.h |  5 +
> >  libavfilter/video.c| 38 +++---
> >  3 files changed, 33 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index c5c3044..bec8f81 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -168,6 +168,7 @@ void avfilter_link_free(AVFilterLink **link)
> >  return;
> >
> >  av_frame_free(&(*link)->partial_buf);
> > +av_video_frame_pool_uninit(&(*link)->video_frame_pool);
> >
> >  av_freep(link);
> >  }
> > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > index 7aac3cf..e7d0a65 100644
> > --- a/libavfilter/avfilter.h
> > +++ b/libavfilter/avfilter.h
> > @@ -509,6 +509,11 @@ struct AVFilterLink {
> >   * Number of past frames sent through the link.
> >   */
> >  int64_t frame_count;
> > +
> > +/**
> > + * Video frame pool.
> > + */
> > +AVVideoFramePool *video_frame_pool;
> >  };
> >
> >  /**
> > diff --git a/libavfilter/video.c b/libavfilter/video.c
> > index 0274fc1..5b0b7f9 100644
> > --- a/libavfilter/video.c
> > +++ b/libavfilter/video.c
> > @@ -32,6 +32,8 @@
> >  #include "internal.h"
> >  #include "video.h"
> >
> > +#define BUFFER_ALIGN 32
> > +
> >  AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, int h)
> >  {
> >  return ff_get_video_buffer(link->dst->outputs[0], w, h);
> > @@ -42,21 +44,35 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link,
> > int w, int h)
> >   * alloc & free cycle currently implemented. */
> >  AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
> >  {
> > -AVFrame *frame = av_frame_alloc();
> > -int ret;
> > +int pool_width = 0;
> > +int pool_height = 0;
> > +int pool_align = 0;
> > +enum AVPixelFormat pool_format = AV_PIX_FMT_NONE;
> >
> > -if (!frame)
> > -return NULL;
> > +if (!link->video_frame_pool) {
> > +link->video_frame_pool =
> > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > +  link->format,
> > BUFFER_ALIGN);
> > +if (!link->video_frame_pool)
> > +return NULL;
> > +} else {
> > +if (av_video_frame_pool_get_config(link->video_frame_pool,
> > +   _width, _height,
> > +   _format, _align) <
> > 0) {
> > +return NULL;
> > +}
> >
> > -frame->width  = w;
> > -frame->height = h;
> > -frame->format = link->format;
> > +if (pool_width != w || pool_height != h ||
> > +pool_format != link->format || pool_align != BUFFER_ALIGN) {
> >
> > -ret = av_frame_get_buffer(frame, 32);
> > -if (ret < 0)
> > -av_frame_free();
> > +av_video_frame_pool_uninit(>video_frame_pool);
> > +link->video_frame_pool =
> > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > +
> > link->format, BUFFER_ALIGN);
> > +if (!link->video_frame_pool)
> > +return NULL;
> > +}
> > +}
> >
> > -return frame;
> > +return av_video_frame_pool_get(link->video_frame_pool);
> >  }
> >
> >  AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
> > --
> > 2.6.3
> >
> >
> New patch attached. It does not rely anymore on the public AVVideoFramePool
> but rather on a private FFVideoFramePool declared inside libavfilter since
> I would like this API to cover both audio and video and maybe have the
> ability to reconfigure itself (without the need of changing the underlying
> pools if the width and height are lower than the original ones for example)
> before having it public. The plan is also to factorize this code with the
> one in libavcodec/FramePool as much as possible.

>  Makefile|1 
>  avfilter.c  |1 
>  avfilter.h  |5 +
>  framepool.c |  189 
> 
>  framepool.h |   84 ++
>  internal.h  |1 
>  video.c |   42 -
>  7 files changed, 309 insertions(+), 14 deletions(-)
> 33310aff0621b3255a2723dd8b7388b825a8a5ae  
> 0001-lavfi-use-a-video-frame-pool-for-each-link-of-the-fi.patch
> From a307a65bfcbde03bce21928024ab53a901cf3620 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 11 Dec 2015 13:32:47 +0100
> Subject: [PATCH] lavfi: use a video frame pool for each link of the
>  filtergraph

should be ok, assuming its the same as the previous patch just privatized

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of 

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Eran Kornblau]

> 
> using a random IV value would break any regression tests
> see AVFMT_FLAG_BITEXACT
> 
Fixed, only generating a random IV when bitexact is not enabled.
Updated patch files attached.

> 
> is this filling in a random IV that later is overridden ?
> random_seed() can be slow so it would be better not to call it if
> its value isnt used
> 
I didn't think it's too significant since it happens only once per decrypted 
track, but anyway, fixed it as well.
I changed av_aes_ctr_init so that it will initialize an empty IV, and exposed 
av_aes_ctr_set_random_iv.
This later function is called only by the encoder (and only when bitexact is 
disabled).

> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thanks !

Eran


0001-libavutil-add-aes-ctr-support.patch
Description: 0001-libavutil-add-aes-ctr-support.patch


0002-movenc-support-cenc-common-encryption.patch
Description: 0002-movenc-support-cenc-common-encryption.patch


0003-mov-support-cenc-common-encryption.patch
Description: 0003-mov-support-cenc-common-encryption.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Eran Kornblau]

> are these encrypted mp4 files some kind of standard encryption?
> 
Yes, these files conform to the common encryption specification ISO/IEC 23001-7

> rephrased... will encrypted files created by ffmpeg be able to be
> decrypted/decoded and played by quicktime? or any other player?
> (assuming other player has the keys of course). 
> 
These files can be encrypted/decrypted by MP4Box:
https://gpac.wp.mines-telecom.fr/mp4box/encryption/common-encryption/

I'm not familiar with any player that can play it as is, but it can be played 
once repackaged to MPEG-DASH.
In this form, it can be played by Chrome with Widevine / Edge with PlayReady 
etc.
The nginx module we maintain (https://github.com/kaltura/nginx-vod-module/) can 
perform this repackaging
on the fly. If the file is encrypted on disk with the same key that should be 
used for playback, it will skip the
encryption / decryption and serve the data as is (if the keys are different, it 
has to decrypt + re-encrypt)

> thanks!
> 
> -compn

Thanks !

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

Re: [FFmpeg-devel] [PATCH] lavc/utils: use AVPixFmtDescriptor to probe palette formats

[Matthieu Bouron]

On Mon, Dec 14, 2015 at 6:18 PM, Michael Niedermayer 
wrote:

> On Mon, Dec 14, 2015 at 05:49:48PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> >
> > Also use the input frame format instead of the AVCodecContext one
> according
> > to the documentation of AVCodecContext.get_buffer2().
> > ---
> >
> > The current code rely on the fact that avpriv_set_systematic_pal2
> > will error out if the format is not a palette one (and that the error
> > code is not checked).
> > I find it makes more sense to probe this kind of formats using the
> > AVPixFmtDescriptor flags.
> >
> > Also the documentation of AVCodecContext.get_buffer2() mention that the
> > frame fields must be used instead of the AVCodecContext one.
> >
> > Matthieu
> >
> > ---
> >  libavcodec/utils.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
>
> probably ok
>

Pushed. Thanks.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph

[Matthieu Bouron]

On Tue, Dec 15, 2015 at 10:00 AM, Michael Niedermayer 
wrote:

> On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > From: Matthieu Bouron 
> > >
> > > ---
> > >  libavfilter/avfilter.c |  1 +
> > >  libavfilter/avfilter.h |  5 +
> > >  libavfilter/video.c| 38 +++---
> > >  3 files changed, 33 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > > index c5c3044..bec8f81 100644
> > > --- a/libavfilter/avfilter.c
> > > +++ b/libavfilter/avfilter.c
> > > @@ -168,6 +168,7 @@ void avfilter_link_free(AVFilterLink **link)
> > >  return;
> > >
> > >  av_frame_free(&(*link)->partial_buf);
> > > +av_video_frame_pool_uninit(&(*link)->video_frame_pool);
> > >
> > >  av_freep(link);
> > >  }
> > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > > index 7aac3cf..e7d0a65 100644
> > > --- a/libavfilter/avfilter.h
> > > +++ b/libavfilter/avfilter.h
> > > @@ -509,6 +509,11 @@ struct AVFilterLink {
> > >   * Number of past frames sent through the link.
> > >   */
> > >  int64_t frame_count;
> > > +
> > > +/**
> > > + * Video frame pool.
> > > + */
> > > +AVVideoFramePool *video_frame_pool;
> > >  };
> > >
> > >  /**
> > > diff --git a/libavfilter/video.c b/libavfilter/video.c
> > > index 0274fc1..5b0b7f9 100644
> > > --- a/libavfilter/video.c
> > > +++ b/libavfilter/video.c
> > > @@ -32,6 +32,8 @@
> > >  #include "internal.h"
> > >  #include "video.h"
> > >
> > > +#define BUFFER_ALIGN 32
> > > +
> > >  AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, int h)
> > >  {
> > >  return ff_get_video_buffer(link->dst->outputs[0], w, h);
> > > @@ -42,21 +44,35 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink
> *link,
> > > int w, int h)
> > >   * alloc & free cycle currently implemented. */
> > >  AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
> > >  {
> > > -AVFrame *frame = av_frame_alloc();
> > > -int ret;
> > > +int pool_width = 0;
> > > +int pool_height = 0;
> > > +int pool_align = 0;
> > > +enum AVPixelFormat pool_format = AV_PIX_FMT_NONE;
> > >
> > > -if (!frame)
> > > -return NULL;
> > > +if (!link->video_frame_pool) {
> > > +link->video_frame_pool =
> > > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > > +
> link->format,
> > > BUFFER_ALIGN);
> > > +if (!link->video_frame_pool)
> > > +return NULL;
> > > +} else {
> > > +if (av_video_frame_pool_get_config(link->video_frame_pool,
> > > +   _width, _height,
> > > +   _format, _align)
> <
> > > 0) {
> > > +return NULL;
> > > +}
> > >
> > > -frame->width  = w;
> > > -frame->height = h;
> > > -frame->format = link->format;
> > > +if (pool_width != w || pool_height != h ||
> > > +pool_format != link->format || pool_align !=
> BUFFER_ALIGN) {
> > >
> > > -ret = av_frame_get_buffer(frame, 32);
> > > -if (ret < 0)
> > > -av_frame_free();
> > > +av_video_frame_pool_uninit(>video_frame_pool);
> > > +link->video_frame_pool =
> > > av_video_frame_pool_init(av_buffer_allocz, w, h,
> > > +
> > > link->format, BUFFER_ALIGN);
> > > +if (!link->video_frame_pool)
> > > +return NULL;
> > > +}
> > > +}
> > >
> > > -return frame;
> > > +return av_video_frame_pool_get(link->video_frame_pool);
> > >  }
> > >
> > >  AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
> > > --
> > > 2.6.3
> > >
> > >
> > New patch attached. It does not rely anymore on the public
> AVVideoFramePool
> > but rather on a private FFVideoFramePool declared inside libavfilter
> since
> > I would like this API to cover both audio and video and maybe have the
> > ability to reconfigure itself (without the need of changing the
> underlying
> > pools if the width and height are lower than the original ones for
> example)
> > before having it public. The plan is also to factorize this code with the
> > one in libavcodec/FramePool as much as possible.
>
> >  Makefile|1
> >  avfilter.c  |1
> >  avfilter.h  |5 +
> >  framepool.c |  189
> 
> >  framepool.h |   84 ++
> >  internal.h  |1
> >  video.c |   42 -
> >  7 files changed, 309 insertions(+), 14 deletions(-)
> > 33310aff0621b3255a2723dd8b7388b825a8a5ae
> 0001-lavfi-use-a-video-frame-pool-for-each-link-of-the-fi.patch
> > From a307a65bfcbde03bce21928024ab53a901cf3620 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron 
> > Date: Fri, 11 Dec 2015 13:32:47 +0100

Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

[Moritz Barsnick]

On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> I found that the ffmpeg  H.265 decoder can't run on the iOS platform
> when I enable the neon assembly code, it crashed when playing the
> H.265 clip. When disable the neon assembly code it works fine. What's
> the problem with the H.265 neon assembly code?

You description is quite vague. Please read:
https://ffmpeg.org/bugreports.html

And do note that it will point you to the bug tracker (even if you
can't provide gdb or valgrind output), not to the mailing lists.

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

Re: [FFmpeg-devel] Bug #3823 (yuvj422p jpeg rtp enc) request for help

[Andrey Utkin]

On Fri, Dec 11, 2015 at 3:02 PM, Andrey Utkin
 wrote:
> On Wed, Dec 9, 2015 at 2:07 AM, Andrey Utkin
>  wrote:
>> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p
>> https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format
>> becomes popular for IP cameras having no RTSP, and there are
>> constantly issues with RTPizing it. I consider donation for fixing
>> this.
>>
>> Thanks.
>
> Up.

Sorry for annoyance, but we really need this badly.
Any help is appreciated.

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

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> Hallo Michael,
> 
> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > > As I understand it, the temporary stack buffer "src_data" was
> > > introduced solely to avoid a compiler warning. I believe that a better
> > > way to solve this warning it to explicitly cast src->data. This
> > > should be somewhat faster, and just as safe.
> > > 
> > > Signed-off-by: Jean Delvare 
> > > Cc: Anton Khirnov 
> > > ---
> > >  libavutil/frame.c |4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > --- ffmpeg.orig/libavutil/frame.c 2015-12-14 18:42:06.272234579 +0100
> > > +++ ffmpeg/libavutil/frame.c  2015-12-14 19:05:18.501745387 +0100
> > > @@ -647,7 +647,6 @@ AVFrameSideData *av_frame_get_side_data(
> > >  
> > >  static int frame_copy_video(AVFrame *dst, const AVFrame *src)
> > >  {
> > > -const uint8_t *src_data[4];
> > >  int i, planes;
> > >  
> > >  if (dst->width  < src->width ||
> > > @@ -659,9 +658,8 @@ static int frame_copy_video(AVFrame *dst
> > >  if (!dst->data[i] || !src->data[i])
> > >  return AVERROR(EINVAL);
> > >  
> > > -memcpy(src_data, src->data, sizeof(src_data));
> > >  av_image_copy(dst->data, dst->linesize,
> > > -  src_data, src->linesize,
> > > +  (const uint8_t **)src->data, src->linesize,
> > 
> > I think this may be a aliasing violation and thus undefined
> > not that i like that or consider that sane
> > so if someone says iam wrong, i would certainly not be unhappy
> 
> Why would it be an aliasing violation? We do not change the fundamental
> type of the pointer, we only add a const where the function wants it.
> For more simple pointer types the compiler would do it for us silently.

A. uint8_t and const uint8_t are distinct types
"Any type so far mentioned is an unqualified type. Each unqualified 
type has several
qualified versions of its type,38) corresponding to the combinations of 
one, two, or all
three of the const, volatile, and restrict qualifiers. The qualified or 
unqualified
versions of a type are distinct types that belong to the same type 
category and have the
same representation and alignment requirements."
B. a pointer to uint8_t and const uint8_t are not qualified types of the same 
type
   See the example in 6.2.5
"28 EXAMPLE 1 The type designated as ‘‘float *’’ has type ‘‘pointer to 
float’’. Its type category is
pointer, not a floating type. The const-qualified version of this type 
is designated as ‘‘float * const’’
whereas the type designated as ‘‘const float *’’ is not a qualified 
type — its type is ‘‘pointer to constqualified
float’’ and is a pointer to a qualified type."
C. They are not compatible
"Two types have compatible type if their types are the same. Additional 
rules for
determining whether two types are compatible are described in 6.7.2 for 
type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for declarators.46)"
D. None of the aliasing exceptions seems to apply
"An object shall have its stored value accessed only by an lvalue 
expression that has one of the following types:76)
— atype compatible with the effective type of the object,
— aqualified version of a type compatible with the effective type of 
the object,"
(its not a qualified version)
   " — a type that is the signed or unsigned type corresponding to the 
effective type of the object,
— a type that is the signed or unsigned type corresponding to a 
qualified version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned 
types among its members (including, recursively, a member of a subaggregate or 
contained union), or
— acharacter type."
(dont apply)

also:
"For two qualified types to be compatible, both shall have the 
identically qualified version
of a compatible type; the order of type qualifiers within a list of 
specifiers or qualifiers
does not affect the specified type."

"For two pointer types to be compatible, both shall be identically 
qualified and both shall
be pointers to compatible types."

I quite possible could misinterpret or miss some parts though ...


> 
> Also I can see 12 occurrences of the same cast for this parameter of
> function av_image_copy() in the ffmpeg code already. And over 20 more
> similar casts for similar parameters of other functions
> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not
> introducing anything new, just proposing one more of the same.

yes, I have no real oppinion on this except that C is insane or I am
and i dont really mind to apply the patch if thats what people prefer.
Any real compiler that 

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Jean Delvare]

On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote:
> yes, I have no real oppinion on this except that C is insane or I am

C is insane, who would dare to argue otherwise? ;-)

More than the language itself, the fact that the compilers think they
can reorder instructions the way they like has always frightened me. I
prefer when tools obey to whoever if handling them, rather than making
their own decisions.

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Eran Kornblau]

> >
> > +struct AVAESCTR;
> 
> Is this needed?
>
Indeed compiles for me without it, I matched the existing code in aes.h, and in 
general I prefer to define the structs in advance. 
If you prefer that I will remove it, please let me know
 
> > +subsample_count = AV_RB16(sc->cenc.auxiliary_info_pos);
> > +sc->cenc.auxiliary_info_pos += sizeof(uint16_t);
> 
> I find the following significantly easier to read and understand:
> 
> subsample_count = AV_RB16(sc->cenc.auxiliary_info_pos);
> sc->cenc.auxiliary_info_pos += 2;
> 
> But this may just be me, so feel free to ignore.
> 
When it's a simple type my preference is to go with the sizeof, when it becomes 
slightly more than that, e.g.:
+
+ctx->auxiliary_info_size += 6;
+ctx->subsample_count++;
+
I use a number (not sizeof(uint16_t) + sizeof(uint32_t)). But again it's all a 
matter of personal preference, 
if you want me to change it, let me know.

> I suspect a fate test will be needed but this may be an 
> independent patch.
> 
Ok, I will write one after this one gets approved :-)

> Thank you, Carl Eugen
>

Thanks !

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

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Hendrik Leppkes]

On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer  wrote:
> On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
>> Hallo Michael,
>>
>> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
>> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
>> > > As I understand it, the temporary stack buffer "src_data" was
>> > > introduced solely to avoid a compiler warning. I believe that a better
>> > > way to solve this warning it to explicitly cast src->data. This
>> > > should be somewhat faster, and just as safe.
>> > >
>> > > Signed-off-by: Jean Delvare 
>> > > Cc: Anton Khirnov 
>> > > ---
>> > >  libavutil/frame.c |4 +---
>> > >  1 file changed, 1 insertion(+), 3 deletions(-)
>> > >
>> > > --- ffmpeg.orig/libavutil/frame.c 2015-12-14 18:42:06.272234579 +0100
>> > > +++ ffmpeg/libavutil/frame.c  2015-12-14 19:05:18.501745387 +0100
>> > > @@ -647,7 +647,6 @@ AVFrameSideData *av_frame_get_side_data(
>> > >
>> > >  static int frame_copy_video(AVFrame *dst, const AVFrame *src)
>> > >  {
>> > > -const uint8_t *src_data[4];
>> > >  int i, planes;
>> > >
>> > >  if (dst->width  < src->width ||
>> > > @@ -659,9 +658,8 @@ static int frame_copy_video(AVFrame *dst
>> > >  if (!dst->data[i] || !src->data[i])
>> > >  return AVERROR(EINVAL);
>> > >
>> > > -memcpy(src_data, src->data, sizeof(src_data));
>> > >  av_image_copy(dst->data, dst->linesize,
>> > > -  src_data, src->linesize,
>> > > +  (const uint8_t **)src->data, src->linesize,
>> >
>> > I think this may be a aliasing violation and thus undefined
>> > not that i like that or consider that sane
>> > so if someone says iam wrong, i would certainly not be unhappy
>>
>> Why would it be an aliasing violation? We do not change the fundamental
>> type of the pointer, we only add a const where the function wants it.
>> For more simple pointer types the compiler would do it for us silently.
>
> A. uint8_t and const uint8_t are distinct types
> "Any type so far mentioned is an unqualified type. Each unqualified 
> type has several
> qualified versions of its type,38) corresponding to the combinations 
> of one, two, or all
> three of the const, volatile, and restrict qualifiers. The qualified 
> or unqualified
> versions of a type are distinct types that belong to the same type 
> category and have the
> same representation and alignment requirements."
> B. a pointer to uint8_t and const uint8_t are not qualified types of the same 
> type
>See the example in 6.2.5
> "28 EXAMPLE 1 The type designated as ‘‘float *’’ has type ‘‘pointer 
> to float’’. Its type category is
> pointer, not a floating type. The const-qualified version of this 
> type is designated as ‘‘float * const’’
> whereas the type designated as ‘‘const float *’’ is not a qualified 
> type — its type is ‘‘pointer to constqualified
> float’’ and is a pointer to a qualified type."
> C. They are not compatible
> "Two types have compatible type if their types are the same. 
> Additional rules for
> determining whether two types are compatible are described in 6.7.2 
> for type specifiers,
> in 6.7.3 for type qualifiers, and in 6.7.5 for declarators.46)"
> D. None of the aliasing exceptions seems to apply
> "An object shall have its stored value accessed only by an lvalue 
> expression that has one of the following types:76)
> — atype compatible with the effective type of the object,
> — aqualified version of a type compatible with the effective type of 
> the object,"
> (its not a qualified version)
>" — a type that is the signed or unsigned type corresponding to the 
> effective type of the object,
> — a type that is the signed or unsigned type corresponding to a 
> qualified version of the effective type of the object,
> — an aggregate or union type that includes one of the aforementioned 
> types among its members (including, recursively, a member of a subaggregate 
> or contained union), or
> — acharacter type."
> (dont apply)
>
> also:
> "For two qualified types to be compatible, both shall have the 
> identically qualified version
> of a compatible type; the order of type qualifiers within a list of 
> specifiers or qualifiers
> does not affect the specified type."
>
> "For two pointer types to be compatible, both shall be identically 
> qualified and both shall
> be pointers to compatible types."
>
> I quite possible could misinterpret or miss some parts though ...
>
>
>>
>> Also I can see 12 occurrences of the same cast for this parameter of
>> function av_image_copy() in the ffmpeg code already. And over 20 more
>> similar casts for similar parameters of other functions
>> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not
>> 

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Jean Delvare]

Hi Hendrik,

On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote:
> On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer  
> wrote:
> > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> >> Also I can see 12 occurrences of the same cast for this parameter of
> >> function av_image_copy() in the ffmpeg code already. And over 20 more
> >> similar casts for similar parameters of other functions
> >> (ff_combine_frame, swr_convert, copy_picture_field...) So I'm not
> >> introducing anything new, just proposing one more of the same.
> >
> > yes, I have no real oppinion on this except that C is insane or I am
> > and i dont really mind to apply the patch if thats what people prefer.
> > Any real compiler that follows this litterally and breaks the code is
> > IMHO a compiler one should avoid (quite independant of it being used
> > for FFmpeg or other things) unless one wants to language lawyer around
> > on such things instead of writing usefull code
> 
> The "speed up" from removing a copy of 4 pointers is negligible as
> well however, so maybe it should just be kept like it is.

Originally I proposed this patch for performance reasons and also
because I think it makes the code more readable. But seeing how the
same cast is already present everywhere in the ffmpeg code, I would now
also invoke consistency. There's no rationale for not doing the same
here that is already done everywhere else. If it caused any problem we
would know by now (and I verified that this patch passes the test
suite, FWIW.)

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

[Carl Eugen Hoyos]

On Tuesday 15 December 2015 11:29:58 am Moritz Barsnick wrote:
> On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> > I found that the ffmpeg  H.265 decoder can't run on the iOS platform
> > when I enable the neon assembly code, it crashed when playing the
> > H.265 clip. When disable the neon assembly code it works fine. What's
> > the problem with the H.265 neon assembly code?
>
> You description is quite vague. Please read:
> https://ffmpeg.org/bugreports.html
>
> And do note that it will point you to the bug tracker (even if you
> can't provide gdb or valgrind output), 

A crash report without gdb information and without source code makes 
very little sense.

> not to the mailing lists. 

The user mailing list is the right place for questions like the one 
above.

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 15.12.2015 14:42, Timo Rothenpieler wrote:
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?

That would be OK for me.

> Or is putting that exception-text in nvenc.c enough to make enabling it
> by default viable?

I think so.

But before doing any of this, there has to be an agreement, whether or not
the header should be included at all.

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

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Jean Delvare]

Hi Derek,

On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
> 
> In which way?
> 
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?

I see two completely different things.

The change I proposed is specific to one function, only changes const
vs non-const, and the object under discussion is being accessed for
reading only (thus the const pointer.) It would remove a memcpy but
does not introduce a direct copy (with =.)

The change you pointed us to is touching very generic functions,
handling by nature a very wide variety of pointer types for both
reading and writing.

So just because the change you pointed us to may be good and desirable,
doesn't imply that the change I am proposing is bad and undesirable.

Side note #1: if gcc really considers pointer types that only differ by
"const" as different when it comes to code optimization, it is
seriously broken IMHO. Unfortunately the man page is quite vague on the
topic ("unless the types are almost the same", can you be more vague
please.)

Side note #2: if strict-aliasing optimizations can do so much damage
to your code that you end up doing
  memcpy(arg, &(void *){ NULL }, sizeof(val));
to set a pointer to NULL, maybe you should consider building with
-fno-strict-aliasing.

Side note #3: I'm surprised this change was needed in the first place
as my understanding was that gcc would skip all strict-aliasing
optimizations for void pointers, which is what the affected functions
are handling. It's sad that the commit message is as vague as gcc's
manual page on the topic.

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffm: reject a negative codec_id

[Andreas Cadhalpun]

On 15.12.2015 03:15, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 01:19:01AM +0100, Andreas Cadhalpun wrote:
>> On 15.12.2015 00:43, Michael Niedermayer wrote:
>>  ffmdec.c |   28 
>>  1 file changed, 28 insertions(+)
>> 5a300bbcfb78b1f24b8b7c572d420577b2a1b1f3  
>> 0001-ffm-reject-invalid-codec_id-and-codec_type.patch
>> From 3e16e9c3c32c9740c8851fd22bb60175852ffc25 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Mon, 14 Dec 2015 22:11:55 +0100
>> Subject: [PATCH] ffm: reject invalid codec_id and codec_type
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

[Ganesh Ajjanagadde]

On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer  wrote:
> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>> exp2 suffices here. Some trivial (~ 4x) speedup is done in addition here by
>> reusing results.
>>
>
>> This is bit-identical to the old values.
>
> That may be true with a specific compiler and version but
> C makes no such guarantee unless iam missing something

Indeed, fpu behavior is largely uncontrolled. What I meant was that
under reasonable settings, there is no accuracy loss (tested with
clang and gcc). Basically, a priori it is not obvious that this change
is ok, but I tested and the values don't change.

For that matter, this is a rather minor point - many pow
implementations are anyway broken wrt precise < 1 ulp or better yet <
0.5 ulp rounding.

>
>
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/nellymoserenc.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>> index d998dba..e6023e3 100644
>> --- a/libavcodec/nellymoserenc.c
>> +++ b/libavcodec/nellymoserenc.c
>> @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext *avctx)
>>
>>  /* Generate overlap window */
>>  ff_init_ff_sine_windows(7);
>> -for (i = 0; i < POW_TABLE_SIZE; i++)
>> -pow_table[i] = pow(2, -i / 2048.0 - 3.0 + POW_TABLE_OFFSET);
>> +pow_table[0] = 1;
>> +pow_table[1024] = M_SQRT1_2;
>> +for (i = 1; i < 513; i++) {
>> +double tmp = exp2(-i / 2048.0);
>> +pow_table[i] = tmp;
>> +pow_table[1024-i] = M_SQRT1_2 / tmp;
>> +pow_table[1024+i] = tmp * M_SQRT1_2;
>> +pow_table[2048-i] = 0.5 / tmp;
>
> how much overall init time is gained by this ?
> that is time in ffmpeg main() from start to finish when just opening
> the file with no decoding aka ./ffmpeg -i somefile

Don't know, all I know is cycles are unnecessarily wasted. Will put in
cycle numbers.

> ?
>
> iam asking as this makes the intend of the loop harder to
> see/understand
> if this change is done then please add a comment explaining what the
> code does or maybe leave the unoptimized code in a comment

Comment will be added, sorry.

Note that the trick may be employed to a finer resolution, ie by
storing exp2(3/4) etc and utilizing in simple multiplications and
divisions. There will come a point where the overhead of the binary
size increase will dominate. I chose this as this is reasonably
readable and improves speed at minimal binary size impact.

>
> either way replacing pow -> exp2 LGTM
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> 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] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc

[Andreas Cadhalpun]

On 15.12.2015 08:17, Anton Khirnov wrote:
> Can you share the sample that shows the problem?

I could, but it's of no use for comparing with libopus, because their
decoder errors out in an unrelated check.

> From what I can see, libopus does not do any clipping at that point, so
> something else must ensure that there is no overflow.

Indeed, the real problem is just a silly typo...
It might have been caused by the fact that the specification uses
i and k in exactly the opposite way than the code.

New patch attached.

Best regards,
Andreas


>From d3b2c24d391d7871b978b3372f0f740730996ded Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 15 Dec 2015 22:00:31 +0100
Subject: [PATCH] opus_silk: fix typo causing overflow in silk_stabilize_lsf

Due to this typo max_center can be too large, causing nlsf to be set to
too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
overflow to a negative value, which is not allowed for nlsf and can
cause an out of bounds read in silk_lsf2lpc.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/opus_silk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index 841d1ed..73526f9 100644
--- a/libavcodec/opus_silk.c
+++ b/libavcodec/opus_silk.c
@@ -824,7 +824,7 @@ static inline void silk_stabilize_lsf(int16_t nlsf[16], int order, const uint16_
 
 /* upper extent */
 for (i = order; i > k; i--)
-max_center -= min_delta[k];
+max_center -= min_delta[i];
 max_center -= min_delta[k] >> 1;
 
 /* move apart */
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libswscale/arm/yuv2rgb_neon.S | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)

should be ok

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

[FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size

[Andreas Cadhalpun]

If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/sonic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 4ec7d89..8522de3 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -928,6 +928,13 @@ static av_cold int sonic_decode_init(AVCodecContext *avctx)
 s->frame_size = s->channels*s->block_align*s->downsampling;
 //avctx->frame_size = s->block_align;
 
+if (s->num_taps > s->frame_size) {
+av_log(avctx, AV_LOG_ERROR,
+   "number of taps %d larger than frame size %d\n",
+   s->num_taps, s->frame_size);
+return AVERROR_INVALIDDATA;
+}
+
 av_log(avctx, AV_LOG_INFO, "Sonic: ver: %d.%d ls: %d dr: %d taps: %d 
block: %d frame: %d downsamp: %d\n",
 s->version, s->minor_version, s->lossless, s->decorrelation, 
s->num_taps, s->block_align, s->frame_size, s->downsampling);
 
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 10:41:15PM +0100, Andreas Cadhalpun wrote:
> On 15.12.2015 08:17, Anton Khirnov wrote:
> > Can you share the sample that shows the problem?
> 
> I could, but it's of no use for comparing with libopus, because their
> decoder errors out in an unrelated check.
> 
> > From what I can see, libopus does not do any clipping at that point, so
> > something else must ensure that there is no overflow.
> 
> Indeed, the real problem is just a silly typo...
> It might have been caused by the fact that the specification uses
> i and k in exactly the opposite way than the code.
> 
> New patch attached.
> 
> Best regards,
> Andreas
> 
> 

>  opus_silk.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 253c6f7d87dcadf712840f45dde18f5698b9c1d4  
> 0001-opus_silk-fix-typo-causing-overflow-in-silk_stabiliz.patch
> From d3b2c24d391d7871b978b3372f0f740730996ded Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 15 Dec 2015 22:00:31 +0100
> Subject: [PATCH] opus_silk: fix typo causing overflow in silk_stabilize_lsf
> 
> Due to this typo max_center can be too large, causing nlsf to be set to
> too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
> overflow to a negative value, which is not allowed for nlsf and can
> cause an out of bounds read in silk_lsf2lpc.

this looks nicer then the previous fixes

thx

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] ffmpeg: Allow specifying the program number for created programs

[Michael Niedermayer]

From: Michael Niedermayer 

Signed-off-by: Michael Niedermayer 
---
 doc/ffmpeg.texi |4 ++--
 ffmpeg_opt.c|   22 +-
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6307470..a38a32e 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -355,9 +355,9 @@ To set the language of the first audio stream:
 ffmpeg -i INPUT -metadata:s:a:0 language=eng OUTPUT
 @end example
 
-@item -program [title=@var{title}:]st=@var{stream}[:st=@var{stream}...] 
(@emph{output})
+@item -program 
[title=@var{title}:][program_num=@var{program_num}:]st=@var{stream}[:st=@var{stream}...]
 (@emph{output})
 
-Creates a program with the specified @var{title} and adds the specified
+Creates a program with the specified @var{title}, @var{program_num} and adds 
the specified
 @var{stream}(s) to it.
 
 @item -target @var{type} (@emph{output})
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index fd2c051..3df46da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2418,7 +2418,7 @@ loop_end:
 for (i = 0; i < o->nb_program; i++) {
 const char *p = o->program[i].u.str;
 int progid = i+1;
-AVProgram *program = av_new_program(oc, progid);
+AVProgram *program;
 
 while(*p) {
 const char *p2 = av_get_token(, ":");
@@ -2428,6 +2428,25 @@ loop_end:
 if(*p) p++;
 
 key = av_get_token(, "=");
+if (!key || !*p2)
+break;
+p2++;
+
+if (!strcmp(key, "program_num"))
+progid = strtol(p2, NULL, 0);
+}
+
+program = av_new_program(oc, progid);
+
+p = o->program[i].u.str;
+while(*p) {
+const char *p2 = av_get_token(, ":");
+char *key;
+if (!p2)
+break;
+if(*p) p++;
+
+key = av_get_token(, "=");
 if (!key) {
 av_log(NULL, AV_LOG_FATAL,
"No '=' character in program string %s.\n",
@@ -2440,6 +2459,7 @@ loop_end:
 
 if (!strcmp(key, "title")) {
 av_dict_set(>metadata, "title", p2, 0);
+} else if (!strcmp(key, "program_num")) {
 } else if (!strcmp(key, "st")) {
 int st_num = strtol(p2, NULL, 0);
 av_program_add_stream_index(oc, progid, st_num);
-- 
1.7.9.5

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

[FFmpeg-devel] Patch question

[Mats Peterson]

Sorry if this may sound idiotic, but if I provide a unified patch for a 
file that is newer/different from the one I have here, it won't work, right?


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

[Ganesh Ajjanagadde]

On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer  wrote:
>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
[...]
>>>
>>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>> index d998dba..e6023e3 100644
>>> --- a/libavcodec/nellymoserenc.c
>>> +++ b/libavcodec/nellymoserenc.c
>>> @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext *avctx)
>>>
>>>  /* Generate overlap window */
>>>  ff_init_ff_sine_windows(7);
>>> -for (i = 0; i < POW_TABLE_SIZE; i++)
>>> -pow_table[i] = pow(2, -i / 2048.0 - 3.0 + POW_TABLE_OFFSET);
>>> +pow_table[0] = 1;
>>> +pow_table[1024] = M_SQRT1_2;
>>> +for (i = 1; i < 513; i++) {
>>> +double tmp = exp2(-i / 2048.0);
>>> +pow_table[i] = tmp;
>>> +pow_table[1024-i] = M_SQRT1_2 / tmp;
>>> +pow_table[1024+i] = tmp * M_SQRT1_2;
>>> +pow_table[2048-i] = 0.5 / tmp;
>>
>> how much overall init time is gained by this ?
>> that is time in ffmpeg main() from start to finish when just opening
>> the file with no decoding aka ./ffmpeg -i somefile
>
> Don't know, all I know is cycles are unnecessarily wasted. Will put in
> cycle numbers.
>

Here they are:
proposed: 424160 decicycles in pow_table, 512 runs,  0 skips
exp2 only: 1262093 decicycles in pow_table, 512 runs,  0 skips
old: 2849085 decicycles in pow_table, 512 runs,  0 skips

Thus old to exp2 is roughly 2.25x speedup, exp2 to proposed roughly 3x
speedup, net ~ 6.7x speedup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization

[Ganesh Ajjanagadde]

This uses ff_exp2fi to get a speedup (~ 6x).

sample benchmark (Haswell, GNU/Linux):
old:
  19102 decicycles in sbr_dequant,1023 runs,  1 skips
  19002 decicycles in sbr_dequant,2045 runs,  3 skips
  17638 decicycles in sbr_dequant,4093 runs,  3 skips
  15825 decicycles in sbr_dequant,8189 runs,  3 skips
  16404 decicycles in sbr_dequant,   16379 runs,  5 skips

new:
   3063 decicycles in sbr_dequant,1024 runs,  0 skips
   3049 decicycles in sbr_dequant,2048 runs,  0 skips
   2968 decicycles in sbr_dequant,4096 runs,  0 skips
   2818 decicycles in sbr_dequant,8191 runs,  1 skips
   2853 decicycles in sbr_dequant,   16383 runs,  1 skips

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/aacsbr.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index d1e3a91..15956e3 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -33,6 +33,7 @@
 #include "aacsbrdata.h"
 #include "aacsbr_tablegen.h"
 #include "fft.h"
+#include "internal.h"
 #include "aacps.h"
 #include "sbrdsp.h"
 #include "libavutil/internal.h"
@@ -73,15 +74,22 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
id_aac)
 {
 int k, e;
 int ch;
-
+static const double exp2_tab[2] = {1, M_SQRT2};
 if (id_aac == TYPE_CPE && sbr->bs_coupling) {
-float alpha  = sbr->data[0].bs_amp_res ?  1.0f :  0.5f;
-float pan_offset = sbr->data[0].bs_amp_res ? 12.0f : 24.0f;
+int pan_offset = sbr->data[0].bs_amp_res ? 12 : 24;
 for (e = 1; e <= sbr->data[0].bs_num_env; e++) {
 for (k = 0; k < sbr->n[sbr->data[0].bs_freq_res[e]]; k++) {
-float temp1 = exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 
7.0f);
-float temp2 = exp2f((pan_offset - 
sbr->data[1].env_facs_q[e][k]) * alpha);
-float fac;
+float temp1, temp2, fac;
+if (sbr->data[0].bs_amp_res) {
+temp1 = ff_exp2fi(sbr->data[0].env_facs_q[e][k] + 7);
+temp2 = ff_exp2fi(pan_offset - 
sbr->data[1].env_facs_q[e][k]);
+}
+else {
+temp1 = ff_exp2fi((sbr->data[0].env_facs_q[e][k]>>1) + 7) *
+exp2_tab[sbr->data[0].env_facs_q[e][k] & 1];
+temp2 = ff_exp2fi((pan_offset - 
sbr->data[1].env_facs_q[e][k])>>1) *
+exp2_tab[(pan_offset - 
sbr->data[1].env_facs_q[e][k]) & 1];
+}
 if (temp1 > 1E20) {
 av_log(NULL, AV_LOG_ERROR, "envelope scalefactor overflow 
in dequant\n");
 temp1 = 1;
@@ -93,8 +101,8 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
id_aac)
 }
 for (e = 1; e <= sbr->data[0].bs_num_noise; e++) {
 for (k = 0; k < sbr->n_q; k++) {
-float temp1 = exp2f(NOISE_FLOOR_OFFSET - 
sbr->data[0].noise_facs_q[e][k] + 1);
-float temp2 = exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
+float temp1 = ff_exp2fi(NOISE_FLOOR_OFFSET - 
sbr->data[0].noise_facs_q[e][k] + 1);
+float temp2 = ff_exp2fi(12 - sbr->data[1].noise_facs_q[e][k]);
 float fac;
 av_assert0(temp1 <= 1E20);
 fac = temp1 / (1.0f + temp2);
@@ -104,11 +112,13 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
id_aac)
 }
 } else { // SCE or one non-coupled CPE
 for (ch = 0; ch < (id_aac == TYPE_CPE) + 1; ch++) {
-float alpha = sbr->data[ch].bs_amp_res ? 1.0f : 0.5f;
 for (e = 1; e <= sbr->data[ch].bs_num_env; e++)
 for (k = 0; k < sbr->n[sbr->data[ch].bs_freq_res[e]]; k++){
-sbr->data[ch].env_facs[e][k] =
-exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
+if (sbr->data[ch].bs_amp_res)
+sbr->data[ch].env_facs[e][k] = 
ff_exp2fi(sbr->data[ch].env_facs_q[e][k] + 6);
+else
+sbr->data[ch].env_facs[e][k] = 
ff_exp2fi((sbr->data[ch].env_facs_q[e][k]>>1) + 6)
+   * 
exp2_tab[sbr->data[ch].env_facs_q[e][k] & 1];
 if (sbr->data[ch].env_facs[e][k] > 1E20) {
 av_log(NULL, AV_LOG_ERROR, "envelope scalefactor 
overflow in dequant\n");
 sbr->data[ch].env_facs[e][k] = 1;
@@ -118,7 +128,7 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
id_aac)
 for (e = 1; e <= sbr->data[ch].bs_num_noise; e++)
 for (k = 0; k < sbr->n_q; k++)
 sbr->data[ch].noise_facs[e][k] =
-exp2f(NOISE_FLOOR_OFFSET - 
sbr->data[ch].noise_facs_q[e][k]);
+

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Timo Rothenpieler]

So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?

Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?



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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Jean-Baptiste Kempf]

On 15 Dec, Timo Rothenpieler wrote :
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?

I still don't understand why you want to fork this header into the
FFmpeg tree.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/qsv: export session management functionality (variant #3)

[Ivan Uskov]

Hello All,

There is updated patch version initially introduced by Sven Dueking 


This patch expose 3 QSV functions as public.
This is needed because the VPP needs access to these functions too.

Please review.


-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-avcodec-qsv-export-session-management-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Regarding the QuickTime palette issue in matroskadec.c

[Mats Peterson]

I don't really know which is worse, calling a function in mov.c, or 
"duplicating" (because I'll have to admit that it's a form of 
duplication in a technical sense) code in it. Because *if*, against all 
odds, there would have to be a change in the QuickTime color table 
handling, it's easy to forget one of the files in the process. The best 
solution would probably be to have a file 'qtpalette.c' with a function 
that is used by both matroskadec.c and mov.c. Now this is low priority 
once again, I'm just doubtful about my own approach.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Jean-Baptiste Kempf]

On 10 Dec, Philip Langdale wrote :
> >Are we really talking about including a huge 3rd party header because
> >distros are so lazy? What's next, do we add Windows headers to the
> >FFmpeg tree, because MinGW lags severely behind the newest definitions
> >like HEVC DXVA support?
> 
> Admittedly, we are solving someone else's problem, but the header is
> buried inside the SDK download which is hidden behind a click-through on
> nvidia's web page. So it's not made available in a way that is readily
> consumable by an end user or by a distribution vendor.

Sorry, but that's true about most headers for Windows, for example, or
for the Android SDK/NDK, or for the iOS SDK.

If someone is able to compile FFmpeg, he's able to get access to a
header.

> With the new licencing, a distro vendor *could* take the header and package
> it up themselves, but that's the sort of them that's exceptionally hard to
> convince them to do.

How is that an argument? When have the distributions being lazy on such
a thing?
On the opposite, I'm quite sure most Linux distributions do not want forking
of other libraries/headers/code into other applications/libraries.
See the current debates on Debian and Fedora and CSS/JS code.

> And in the case of windows (where nvenc works too), there is no distro
> vendor and nvidia certainly won't make the header more accessible than it
> already is.

The Windows SDK is not very accessible either.

> If the goal is to make the feature as available as possible to as many users
> as possible, then this is the way to do it.

I believed the goal was to make the correct thing, not make one feature
as available as possible.
Else, why are you not forking libmfx into the tree then? or crystalhd
headers (pure dlopening on Windows)?

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
[...]

> @@ -4007,6 +4008,147 @@ static int mov_read_free(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +uint32_t format = avio_rl32(pb);
> +enum AVCodecID id;
> +AVStream *st;
> +
> +if (c->fc->nb_streams < 1)
> +return 0;
> +st = c->fc->streams[c->fc->nb_streams - 1];
> +
> +id = mov_codec_id(st, format);
> +st->codec->codec_id = id;

doesnt this allow changing the codec id to anything from anything ?
this seems potentially risky

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

[FFmpeg-devel] [PATCH] lavu/eval: remove pow and exp2 for postfixes

[Ganesh Ajjanagadde]

These postfixes can be computed statically, and there is no need to
waste runtime resources.

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/eval.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/libavutil/eval.c b/libavutil/eval.c
index 44129d6..dcb8c56 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -57,27 +57,31 @@ typedef struct Parser {
 
 static const AVClass eval_class = { "Eval", av_default_item_name, NULL, 
LIBAVUTIL_VERSION_INT, offsetof(Parser,log_offset), offsetof(Parser,log_ctx) };
 
-static const int8_t si_prefixes['z' - 'E' + 1] = {
-['y'-'E']= -24,
-['z'-'E']= -21,
-['a'-'E']= -18,
-['f'-'E']= -15,
-['p'-'E']= -12,
-['n'-'E']= - 9,
-['u'-'E']= - 6,
-['m'-'E']= - 3,
-['c'-'E']= - 2,
-['d'-'E']= - 1,
-['h'-'E']=   2,
-['k'-'E']=   3,
-['K'-'E']=   3,
-['M'-'E']=   6,
-['G'-'E']=   9,
-['T'-'E']=  12,
-['P'-'E']=  15,
-['E'-'E']=  18,
-['Z'-'E']=  21,
-['Y'-'E']=  24,
+static const struct {
+double bin_val;
+double dec_val;
+int8_t exp;
+} si_prefixes['z' - 'E' + 1] = {
+['y'-'E']= { 8.271806125530276749e-25, 1e-24, -24 },
+['z'-'E']= { 8.4703294725430034e-22, 1e-21, -21 },
+['a'-'E']= { 8.6736173798840355e-19, 1e-18, -18 },
+['f'-'E']= { 8.8817841970012523e-16, 1e-15, -15 },
+['p'-'E']= { 9.0949470177292824e-13, 1e-12, -12 },
+['n'-'E']= { 9.3132257461547852e-10, 1e-9,  -9 },
+['u'-'E']= { 9.5367431640625e-7, 1e-6, -6 },
+['m'-'E']= { 9.765625e-4, 1e-3, -3 },
+['c'-'E']= { 9.8431332023036951e-3, 1e-2, -2 },
+['d'-'E']= { 9.921256574801246e-2, 1e-1, -1 },
+['h'-'E']= { 1.0159366732596479e2, 1e2, 2 },
+['k'-'E']= { 1.024e3, 1e3, 3 },
+['K'-'E']= { 1.024e3, 1e3, 3 },
+['M'-'E']= { 1.048576e6, 1e6, 6 },
+['G'-'E']= { 1.073741824e9, 1e9, 9 },
+['T'-'E']= { 1.099511627776e12, 1e12, 12 },
+['P'-'E']= { 1.125899906842624e15, 1e15, 15 },
+['E'-'E']= { 1.152921504606847e18, 1e18, 18 },
+['Z'-'E']= { 1.1805916207174113e21, 1e21, 21 },
+['Y'-'E']= { 1.2089258196146292e24, 1e24, 24 },
 };
 
 static const struct {
@@ -105,13 +109,13 @@ double av_strtod(const char *numstr, char **tail)
 d = pow(10, d / 20);
 next += 2;
 } else if (*next >= 'E' && *next <= 'z') {
-int e= si_prefixes[*next - 'E'];
+int e= si_prefixes[*next - 'E'].exp;
 if (e) {
 if (next[1] == 'i') {
-d*= pow( 2, e/0.3);
+d*= si_prefixes[*next - 'E'].bin_val;
 next+=2;
 } else {
-d*= pow(10, e);
+d*= si_prefixes[*next - 'E'].dec_val;
 next++;
 }
 }
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 11:50:21PM +0100, Andreas Cadhalpun wrote:
> If that is the case, the loop setting predictor_state in
> sonic_decode_frame causes out of bounds reads of int_samples, which has
> only frame_size number of elements.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/sonic.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
> index 4ec7d89..8522de3 100644
> --- a/libavcodec/sonic.c
> +++ b/libavcodec/sonic.c
> @@ -928,6 +928,13 @@ static av_cold int sonic_decode_init(AVCodecContext 
> *avctx)
>  s->frame_size = s->channels*s->block_align*s->downsampling;
>  //avctx->frame_size = s->block_align;
>  
> +if (s->num_taps > s->frame_size) {

shouldt this be something like
num_taps* channels > frame_size ?

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

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


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

[FFmpeg-devel] [PATCH] Add support for HLS PLAYLIST types EVENT and VOD

[Adam Kent]

Adds HLS flags to emit the X-PLAYLIST-TYPE tag to the top of generated
M3U8 files.

See the spec:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.5

There was also an FFMPEG trac ticket #4571 that had this as a wishlist item:
https://trac.ffmpeg.org/ticket/4571

---
 doc/muxers.texi  | 6 ++
 libavformat/hlsenc.c | 9 +
 2 files changed, 15 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index b6d8823..cbbf23e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -368,6 +368,12 @@ Will produce the playlist, @file{out.m3u8}, and a single 
segment file,
 @item hls_flags delete_segments
 Segment files removed from the playlist are deleted after a period of time
 equal to the duration of the segment plus the duration of the playlist.
+
+@item hls_flags event
+Emit #EXT-X-PLAYLIST-TYPE:EVENT at the top of the M3U8 file.
+
+@item hls_flags vod
+Emit #EXT-X-PLAYLIST-TYPE:VOD at the top of the M3U8 file.
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index adcf7df..8db2088 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -61,6 +61,8 @@ typedef enum HLSFlags {
 HLS_ROUND_DURATIONS = (1 << 2),
 HLS_DISCONT_START = (1 << 3),
 HLS_OMIT_ENDLIST = (1 << 4),
+HLS_EVENT_PLAYLIST = (1 << 5),
+HLS_VOD_PLAYLIST = (1 << 6),
 } HLSFlags;
 
 typedef struct HLSContext {
@@ -411,6 +413,11 @@ static int hls_window(AVFormatContext *s, int last)
 }
 avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
 avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
+if (hls->flags & HLS_EVENT_PLAYLIST) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
+} else if (hls->flags & HLS_VOD_PLAYLIST) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
+}
 
 av_log(s, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n",
sequence);
@@ -874,6 +881,8 @@ static const AVOption options[] = {
 {"round_durations", "round durations in m3u8 to whole numbers", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E, "flags"},
 {"discont_start", "start the playlist with a discontinuity tag", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
 {"omit_endlist", "Do not append an endlist when ending stream", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX,   E, "flags"},
+{"event", "set playlist type as 'EVENT'", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_EVENT_PLAYLIST }, 0, UINT_MAX,   E, "flags"},
+{"vod", "set playlist type as 'VOD'", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_VOD_PLAYLIST }, 0, UINT_MAX,   E, "flags"},
 { "use_localtime", "set filename expansion with strftime at segment 
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING, 
{.str = NULL},  0, 0,E},
 
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

[James Almer]

On 12/10/2015 8:02 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/x86/hevc_sao_10bit.asm | 142 
> +++---
>  1 file changed, 57 insertions(+), 85 deletions(-)


Ping for patchset.

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

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
> > 
> > using a random IV value would break any regression tests
> > see AVFMT_FLAG_BITEXACT
> > 
> Fixed, only generating a random IV when bitexact is not enabled.
> Updated patch files attached.
> 
> > 
> > is this filling in a random IV that later is overridden ?
> > random_seed() can be slow so it would be better not to call it if
> > its value isnt used
> > 
> I didn't think it's too significant since it happens only once per decrypted 
> track, but anyway, fixed it as well.
> I changed av_aes_ctr_init so that it will initialize an empty IV, and exposed 
> av_aes_ctr_set_random_iv.
> This later function is called only by the encoder (and only when bitexact is 
> disabled).
> 
> > -- 
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Thanks !
> 
> Eran

>  Makefile  |2 
>  aes_ctr.c |  129 
> ++
>  aes_ctr.h |   83 +++
>  version.h |2 
>  4 files changed, 215 insertions(+), 1 deletion(-)
> 1704fc6a8cfb2922b3806a1d1e122b668f743408  
> 0001-libavutil-add-aes-ctr-support.patch
> From 8e6bc361924b6942b879b833c419bb7ea03b516f Mon Sep 17 00:00:00 2001
> From: erankor 
> Date: Mon, 7 Dec 2015 11:58:41 +0200
> Subject: [PATCH 1/3] libavutil: add aes-ctr support

patch 1 and 2 applied

if you want to maintain the code in the future then please send a
patch that adds you to the maintainers file

thanks

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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