Re: [FFmpeg-devel] Odp: Re: [PATCH v15] avformat/dashdec: add dash demuxer base version

2017-08-27 Thread Rodger Combs 
If you know of such a vulnerability, report it to ffmpeg-secur...@ffmpeg.org. 
New code with known vulnerabilities will not be accepted.

Sent from my iPhone

> On Aug 27, 2017, at 14:04, samsamsam  wrote:
> 
> get_repl_pattern_and_format, you should have a fixed value of something like 
> `"%0*"PRId64`
> 
> If you afraid about safety then the only thing which need to be added to 
> get_repl_pattern_and_format is validation of format.
> Simple loop to validate format will be enough. Do you agree? 
> 
> Anyway we are talking about safety but parser for mp4 atoms missing checking 
> and there is quite easy to make segfault of the libavformat when try to 
> prepared mp4 file.
> 
> I understand that you want to have maximum safety with new code but I hope 
> you know that ffmpeg at all is not safety.
> 
> Regards,
> SSS
> 
> Dnia 27 sierpnia 2017 16:34 Rodger Combs  napisał(a):
> 
> You're still calling snprintf with a string derived from the XML, which is 
> still not safe. Rather than having a format copied from the source in 
> get_repl_pattern_and_format, you should have a fixed value of something like 
> `"%0*"PRId64`, and specify an additional "precision" argument you parse from 
> the XML yourself. I can't reiterate this enough: _never pass data from the 
> XML into the format-string arg of a printf-family function_.
> 
> Also, rather than calling snprintf() twice with an av_malloc() in between, 
> you can just call av_asprintf(). That's what it does internally anyway.
> 
> On Aug 27, 2017, at 09:19, Steven Liu  wrote:
> 
> ffmpeg need a dash demuxer for demux the dash formats base on
> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
> 
> TODO:
> 1. support multi bitrate dash
> 
> v2 fixed:
> 1. from autodetect to disabled
> 2. from camelCase code style to ffmpeg code style
> 3. from RepType to AVMediaType
> 4. fix variable typo
> 5. change time value from uint32_t to uint64_t
> 6. removed be used once API
> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
> av_timegm
> 8. merge complex free operation to free_fragment
> 9. use API from snprintf to av_asprintf
> 
> v3 fixed:
> 1. fix typo from --enabled-xml2 to --enable-xml2
> 
> v4 fixed:
> 1. from --enable-xml2 to --enable-libxml2
> 2. move system includes to top
> 3. remove nouse includes
> 4. rename enum name
> 5. add a trailing comma for the last entry enum
> 6. fix comment typo
> 7. add const to DASHContext class front
> 8. check sscanf if return arguments and give warning message when error
> 9. check validity before free seg->url and seg
> 10. check if the val is null, before use atoll
> 
> v5 fixed:
> 1. fix typo from mainifest to manifest
> 
> v6 fixed:
> 1. from realloc to av_realloc
> 2. from free to av_free
> 
> v7 fixed:
> 1. remove the -lxml2 from configure when require_pkg_config
> 
> v8 fixed:
> 1. fix replace filename template by av_asprintf secure problem
> 
> v9 modified:
> 1. make manifest parser clearly
> 
> v10 fixed:
> 1. fix function API name code style
> 2. remove redundant strreplace call
> 3. remove redundant memory operation and check return value from 
> get_content_url()
> 4. add space between ) and {
> 5. remove no need to log the value for print
> 
> v11 fixed:
> 1. from atoll to strtoll
> 
> v12 fixed:
> 1. remove strreplace and instead by av_strreplace
> 
> v13 fixed:
> 1. fix bug: cannot play:
> http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
> 
> v14 fixed:
> 1. fix bug: TLS connection was non-properly terminated
> 2. fix bug: No trailing CRLF found in HTTP header
> 
> v15 fixed:
> 1. play youtube link: ffmpeg -i $(youtube-dl -J 
> "https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
> ".requested_formats[0].manifest_url")
> 2. code refine for timeline living stream
> 
> Reviewed-by: Clément Bœsch 
> Reviewed-by: Michael Niedermayer 
> Reviewed-by: Carl Eugen Hoyos 
> Reviewed-by: Rodger Combs 
> Reviewed-by: Moritz Barsnick 
> Reviewed-by: Nicolas George 
> Reviewed-by: Ricardo Constantino 
> Reviewed-by: wm4 
> Tested-by: Andy Furniss 
> Reported-by: Andy Furniss 
> Signed-off-by: Steven Liu 
> Signed-off-by: samsamsam 
> ---
> configure|4 +
> libavformat/Makefile |1 +
> libavformat/allformats.c |2 +-
> libavformat/dashdec.c| 1981 ++
> 4 files changed, 1987 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/dashdec.c
> 
> diff --git a/configure b/configure
> index 05f6dcc99a..7a7d61fa13 100755
> --- a/configure
> +++ b/configure
> @@ -272,6 +272,7 @@ External library support:
>  --enable-libxcb-shapeenable X11 grabbing shape

Re: [FFmpeg-devel] [PATCH 0/2] Tile threading support for vp9

2017-08-27 Thread Michael Niedermayer 
On Mon, Aug 28, 2017 at 02:22:15AM +0700, Ilia Valiakhmetov wrote:
> These patches introduce tile threading support for vp9.
> 
> Tile threading is ~45% faster at 2 threads vs 1.
> Frame threading is ~55% faster at 2 threads vs 1.
> ffvp9 tile threading is ~25% faster than libvpx-vp9 at 2 threads
> 
> execute3() function is similar to execute2(), execept it has
> a extra argument - main function for avpriv_slicethread_create(), it is used 
> for the loopfilter.
> 
> Ilia Valiakhmetov (2):
>   avcodec: add execute3() api to utilize the main function of
> avpriv_slicethread_create().
>   avcodec/vp9: Add tile threading support

this seems to break build with mips-linux-gnu-gcc-4.4 and --disable-pthreads

In file included from src/libavcodec/vp9data.h:28,
 from src/libavcodec/vp9.c:33:
src/libavcodec/vp9dec.h:218: error: redefinition of typedef ‘VP9TileData’
src/libavcodec/vp9dec.h:89: note: previous declaration of ‘VP9TileData’ was here
src/libavcodec/vp9.c: In function ‘vp9_free_entries’:
src/libavcodec/vp9.c:115: error: implicit declaration of function 
‘pthread_mutex_destroy’
src/libavcodec/vp9.c:116: error: implicit declaration of function 
‘pthread_cond_destroy’
src/libavcodec/vp9.c: In function ‘vp9_alloc_entries’:
src/libavcodec/vp9.c:138: error: implicit declaration of function 
‘pthread_mutex_init’
src/libavcodec/vp9.c:139: error: implicit declaration of function 
‘pthread_cond_init’
src/libavcodec/vp9.c: In function ‘vp9_report_tile_progress’:
src/libavcodec/vp9.c:146: error: implicit declaration of function 
‘pthread_cond_signal’
src/libavcodec/vp9.c: In function ‘vp9_await_tile_progress’:
src/libavcodec/vp9.c:153: error: implicit declaration of function 
‘pthread_mutex_lock’
src/libavcodec/vp9.c:155: error: implicit declaration of function 
‘pthread_cond_wait’
src/libavcodec/vp9.c:156: error: implicit declaration of function 
‘pthread_mutex_unlock’
src/libavcodec/vp9.c: In function ‘vp9_decode_frame’:
src/libavcodec/vp9.c:1424: warning: ‘pkt_pts’ is deprecated (declared at 
src/libavutil/frame.h:302)
make: *** [libavcodec/vp9.o] Error 1
make: *** Waiting for unfinished jobs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

2017-08-27 Thread Daniel Glöckner 
On Thu, Aug 24, 2017 at 10:57:43AM +0200, Michael Niedermayer wrote:
> > From b4b49b6b584b33e1da95a5d72b05fd9134ab28f9 Mon Sep 17 00:00:00 2001
> > From: Dale Curtis 
> > Date: Mon, 17 Jul 2017 17:38:09 -0700
> > Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is
> >  enabled.
> 
> applied
> 
> thanks

With this commit I can no longer reproduce the problem described in
ticket 6560, but I now get lots of

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x9942020] Failed to add index entry

messages. These messages vanish if I also apply the patch that I posted
three weeks ago ( https://patchwork.ffmpeg.org/patch/4632/ ) and that
has so far received no comments.

Best regards,

  Daniel

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

[FFmpeg-devel] [PATCH 2/2] avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered()

2017-08-27 Thread Michael Niedermayer 
Fixes: runtime error: signed integer overflow: 267 * 8388608 cannot be 
represented in type 'int'
Fixes: 2743/clusterfuzz-testcase-minimized-5820652076400640

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/snowdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 734f43e7d1..b74c468ce3 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -140,7 +140,7 @@ static inline void 
decode_subband_slice_buffered(SnowContext *s, SubBand *b, sli
 v = b->x_coeff[new_index].coeff;
 x = b->x_coeff[new_index++].x;
 while(x < w){
-register int t= ( (v>>1)*qmul + qadd)>>QEXPSHIFT;
+register int t= (int)( (v>>1)*(unsigned)qmul + qadd)>>QEXPSHIFT;
 register int u= -(v&1);
 line[x] = (t^u) - u;
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Fix undefined shift in pcm code

2017-08-27 Thread Michael Niedermayer 
Fixes: runtime error: shift exponent -1 is negative
Fixes: 3091/clusterfuzz-testcase-minimized-6229767969832960

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/hevc_ps.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 37eae226e2..ee31cc093c 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1028,10 +1028,10 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
 sps->pcm.log2_min_pcm_cb_size = get_ue_golomb_long(gb) + 3;
 sps->pcm.log2_max_pcm_cb_size = sps->pcm.log2_min_pcm_cb_size +
 get_ue_golomb_long(gb);
-if (sps->pcm.bit_depth > sps->bit_depth) {
+if (FFMAX(sps->pcm.bit_depth, sps->pcm.bit_depth_chroma) > 
sps->bit_depth) {
 av_log(avctx, AV_LOG_ERROR,
-   "PCM bit depth (%d) is greater than normal bit depth 
(%d)\n",
-   sps->pcm.bit_depth, sps->bit_depth);
+   "PCM bit depth (%d, %d) is greater than normal bit depth 
(%d)\n",
+   sps->pcm.bit_depth, sps->pcm.bit_depth_chroma, 
sps->bit_depth);
 return AVERROR_INVALIDDATA;
 }
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-27 Thread Jorge Ramirez 

On 08/27/2017 09:09 PM, Jorge Ramirez wrote:

On 08/25/2017 05:35 PM, wm4 wrote:

+static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame, V4L2Buffer *avbuf)
+{
+int i, ret;
+
+av_frame_unref(frame);
+
+/* 1. get references to the actual data */
+for (i = 0; i < avbuf->num_planes; i++) {
+ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
+if (ret)
+return ret;
+
+frame->linesize[i] = avbuf->bytesperline[i];
+frame->data[i] = frame->buf[i]->data;
+}
+
+/* 1.1 fixup special cases */
+switch (avbuf->context->av_pix_fmt) {
+case AV_PIX_FMT_NV12:
+if (avbuf->num_planes > 1)
+break;
+frame->linesize[1] = avbuf->bytesperline[0];
+frame->data[1] = frame->buf[0]->data + avbuf->bytesperline[0] * 
avbuf->context->format.fmt.pix_mp.height;
+break;
+default:
+break;
+}
+
+/* 2. get frame information */
+frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
+frame->format = avbuf->context->av_pix_fmt;
+
+/* these values are updated also during re-init in process_video_event */
+frame->height = avbuf->context->height;
+frame->width = avbuf->context->width;
+frame->pts = get_pts(avbuf);
+
+/* 3. report errors upstream */
+if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
+av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s: driver decode error\n", 
avbuf->context->name);
+frame->decode_error_flags |= FF_DECODE_ERROR_INVALID_BITSTREAM;
+}
+
+return 0;
+}

This function seems to lack setting typically required metadata like
colorspace.



ok I will retrieve the colorspace from the v4l2 format structure and 
set it in the frame.


um, I dont see a 1:1 mapping between the colorspaces reported from v4l2 
and what ffmpeg expects (I am also not a subject matter expert on this :( ).


Could I get some guidance on the translation table below please?
btw in my simple tests - ffplay decoded vp8, vp9, mpeg4, mpeg2, h263, 
h264 and hevc I didnt need this field so I am not sure if I am getting 
it right.


TIA

static inline enum AVColorSpace get_colorspace(V4L2Buffer *buf)
{
enum v4l2_colorspace cs;

cs = V4L2_TYPE_IS_MULTIPLANAR(buf->context->type) ?
buf->context->format.fmt.pix_mp.colorspace :
buf->context->format.fmt.pix.colorspace;

/* */
switch (cs) {
case V4L2_COLORSPACE_SMPTE170M: return AVCOL_SPC_SMPTE170M;
case V4L2_COLORSPACE_SMPTE240M: return AVCOL_SPC_SMPTE240M;
case V4L2_COLORSPACE_470_SYSTEM_BG: return AVCOL_SPC_BT470BG;
case V4L2_COLORSPACE_BT2020: return AVCOL_SPC_BT2020_CL;
case V4L2_COLORSPACE_REC709: return AVCOL_SPC_BT709;
case V4L2_COLORSPACE_ADOBERGB:
case V4L2_COLORSPACE_SRGB:
case V4L2_COLORSPACE_DCI_P3:
case V4L2_COLORSPACE_JPEG:
case V4L2_COLORSPACE_RAW:
default:
return AVCOL_SPC_RGB;
}
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/2] Tile threading support for vp9

2017-08-27 Thread Ilia Valiakhmetov 
These patches introduce tile threading support for vp9.

Tile threading is ~45% faster at 2 threads vs 1.
Frame threading is ~55% faster at 2 threads vs 1.
ffvp9 tile threading is ~25% faster than libvpx-vp9 at 2 threads

execute3() function is similar to execute2(), execept it has
a extra argument - main function for avpriv_slicethread_create(), it is used 
for the loopfilter.

Ilia Valiakhmetov (2):
  avcodec: add execute3() api to utilize the main function of
avpriv_slicethread_create().
  avcodec/vp9: Add tile threading support

 libavcodec/avcodec.h |   7 +-
 libavcodec/options.c |   1 +
 libavcodec/pthread_slice.c   |  27 +-
 libavcodec/utils.c   |  13 +
 libavcodec/vp9.c | 591 +--
 libavcodec/vp9_mc_template.c | 202 +++
 libavcodec/vp9block.c| 526 +++---
 libavcodec/vp9dec.h  | 106 +---
 libavcodec/vp9mvs.c  |  97 +++
 libavcodec/vp9prob.c |  64 ++---
 libavcodec/vp9recon.c| 157 ++--
 11 files changed, 1036 insertions(+), 755 deletions(-)

-- 
2.8.3

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

[FFmpeg-devel] [PATCH 1/2] avcodec: add execute3() api to utilize the main function of avpriv_slicethread_create().

2017-08-27 Thread Ilia Valiakhmetov 
Signed-off-by: Ilia Valiakhmetov 
---
 libavcodec/avcodec.h   |  7 ++-
 libavcodec/options.c   |  1 +
 libavcodec/pthread_slice.c | 27 +--
 libavcodec/utils.c | 13 +
 4 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 650..712f40c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1089,6 +1089,10 @@ typedef struct RcOverride{
  */
 #define AV_CODEC_CAP_AVOID_PROBING   (1 << 17)
 /**
+ * Codec initializes slice-based threading with a main function
+ */
+#define AV_CODEC_SLICE_THREAD_HAS_MF (1 << 18)
+/**
  * Codec is intra only.
  */
 #define AV_CODEC_CAP_INTRA_ONLY   0x4000
@@ -3233,7 +3237,7 @@ typedef struct AVCodecContext {
  * - decoding: Set by libavcodec, user can override.
  */
 int (*execute2)(struct AVCodecContext *c, int (*func)(struct 
AVCodecContext *c2, void *arg, int jobnr, int threadnr), void *arg2, int *ret, 
int count);
-
+int (*execute3)(struct AVCodecContext *c, int (*func)(struct 
AVCodecContext *c2, void *arg, int jobnr, int threadnr), int (*m_func)(struct 
AVCodecContext *c3), void *arg2, int *ret, int count);
 /**
  * noise vs. sse weight for the nsse comparison function
  * - encoding: Set by user.
@@ -5774,6 +5778,7 @@ const char *avcodec_profile_name(enum AVCodecID codec_id, 
int profile);
 
 int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext *c2, 
void *arg2),void *arg, int *ret, int count, int size);
 int avcodec_default_execute2(AVCodecContext *c, int (*func)(AVCodecContext 
*c2, void *arg2, int, int),void *arg, int *ret, int count);
+int avcodec_default_execute3(AVCodecContext *c, int (*func)(AVCodecContext 
*c2, void *arg2, int jobnr, int threadnr), int (*m_func)(struct AVCodecContext 
*c3), void *arg, int *ret, int count);
 //FIXME func typedef
 
 /**
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 82e1217..6d63bdb 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -117,6 +117,7 @@ static int init_context_defaults(AVCodecContext *s, const 
AVCodec *codec)
 s->get_format  = avcodec_default_get_format;
 s->execute = avcodec_default_execute;
 s->execute2= avcodec_default_execute2;
+s->execute3= avcodec_default_execute3;
 s->sample_aspect_ratio = (AVRational){0,1};
 s->pix_fmt = AV_PIX_FMT_NONE;
 s->sw_pix_fmt  = AV_PIX_FMT_NONE;
diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index c781d35..08d19b9 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
@@ -38,11 +38,13 @@
 
 typedef int (action_func)(AVCodecContext *c, void *arg);
 typedef int (action_func2)(AVCodecContext *c, void *arg, int jobnr, int 
threadnr);
+typedef int (main_func)(AVCodecContext *c);
 
 typedef struct SliceThreadContext {
 AVSliceThread *thread;
 action_func *func;
 action_func2 *func2;
+main_func *m_func;
 void *args;
 int *rets;
 int job_size;
@@ -54,6 +56,12 @@ typedef struct SliceThreadContext {
 pthread_mutex_t *progress_mutex;
 } SliceThreadContext;
 
+static void main_function(void *priv) {
+AVCodecContext *avctx = priv;
+SliceThreadContext *c = avctx->internal->thread_ctx;
+c->m_func(avctx);
+}
+
 static void worker_func(void *priv, int jobnr, int threadnr, int nb_jobs, int 
nb_threads)
 {
 AVCodecContext *avctx = priv;
@@ -99,7 +107,8 @@ static int thread_execute(AVCodecContext *avctx, 
action_func* func, void *arg, i
 c->func = func;
 c->rets = ret;
 
-avpriv_slicethread_execute(c->thread, job_count, 0);
+avpriv_slicethread_execute(c->thread, job_count, !!c->m_func);
+
 return 0;
 }
 
@@ -110,10 +119,20 @@ static int thread_execute2(AVCodecContext *avctx, 
action_func2* func2, void *arg
 return thread_execute(avctx, NULL, arg, ret, job_count, 0);
 }
 
+static int thread_execute3(AVCodecContext *avctx, action_func2* func2, 
main_func* m_func, void *arg, int *ret, int job_count)
+{
+SliceThreadContext *c = avctx->internal->thread_ctx;
+c->func2 = func2;
+c->m_func = m_func;
+return thread_execute(avctx, NULL, arg, ret, job_count, 0);
+}
+
+
 int ff_slice_thread_init(AVCodecContext *avctx)
 {
 SliceThreadContext *c;
 int thread_count = avctx->thread_count;
+static void (*m_f)(void *);
 
 #if HAVE_W32THREADS
 w32thread_init();
@@ -142,7 +161,9 @@ int ff_slice_thread_init(AVCodecContext *avctx)
 }
 
 avctx->internal->thread_ctx = c = av_mallocz(sizeof(*c));
-if (!c || (thread_count = avpriv_slicethread_create(>thread, avctx, 
worker_func, NULL, thread_count)) <= 1) {
+m_f = avctx->codec->capabilities & AV_CODEC_SLICE_THREAD_HAS_MF ? 
_function : NULL;
+
+if (!c || (thread_count = avpriv_slicethread_create(>thread, avctx, 
worker_func, m_f, thread_count)) <= 1) {
 if (c)

Re: [FFmpeg-devel] [PATCH 03/11] libavutil/opencl: fix potentiall nul dereference

2017-08-27 Thread Timo Rothenpieler 

Am 14.08.2017 um 03:47 schrieb Wei Gao:

2017-06-11 22:05 GMT+08:00 Timo Rothenpieler :


Fixes CID 1396840
---
  libavutil/opencl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index af35770e06..202756516b 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -169,7 +169,7 @@ const char *av_opencl_errstr(cl_int status)
  static void free_device_list(AVOpenCLDeviceList *device_list)
  {
  int i, j;
-if (!device_list)
+if (!device_list || !device_list->platform_node)
  return;
  for (i = 0; i < device_list->platform_num; i++) {
  if (!device_list->platform_node[i])
--
2.13.0


Looks good to me, thanks.



applied



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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-27 Thread Jorge Ramirez 

On 08/25/2017 05:35 PM, wm4 wrote:

+static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame, V4L2Buffer *avbuf)
+{
+int i, ret;
+
+av_frame_unref(frame);
+
+/* 1. get references to the actual data */
+for (i = 0; i < avbuf->num_planes; i++) {
+ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
+if (ret)
+return ret;
+
+frame->linesize[i] = avbuf->bytesperline[i];
+frame->data[i] = frame->buf[i]->data;
+}
+
+/* 1.1 fixup special cases */
+switch (avbuf->context->av_pix_fmt) {
+case AV_PIX_FMT_NV12:
+if (avbuf->num_planes > 1)
+break;
+frame->linesize[1] = avbuf->bytesperline[0];
+frame->data[1] = frame->buf[0]->data + avbuf->bytesperline[0] * 
avbuf->context->format.fmt.pix_mp.height;
+break;
+default:
+break;
+}
+
+/* 2. get frame information */
+frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
+frame->format = avbuf->context->av_pix_fmt;
+
+/* these values are updated also during re-init in process_video_event */
+frame->height = avbuf->context->height;
+frame->width = avbuf->context->width;
+frame->pts = get_pts(avbuf);
+
+/* 3. report errors upstream */
+if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
+av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s: driver decode error\n", 
avbuf->context->name);
+frame->decode_error_flags |= FF_DECODE_ERROR_INVALID_BITSTREAM;
+}
+
+return 0;
+}

This function seems to lack setting typically required metadata like
colorspace.



ok I will retrieve the colorspace from the v4l2 format structure and set 
it in the frame.

is there anything else I am missing?


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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-27 Thread Jorge Ramirez 

On 08/25/2017 05:35 PM, wm4 wrote:

+static inline int buffer_ops_v4l2buf_to_bufref(V4L2Buffer *in, int plane, 
AVBufferRef **buf)
+{
+if (plane >= in->num_planes)
+return AVERROR(EINVAL);
+
+/* even though most encoders return 0 in data_offset encoding vp8 does 
require this value*/
+*buf = av_buffer_create((char *)in->plane_info[plane].mm_addr + 
in->planes[plane].data_offset,
+in->plane_info[plane].lengths, free_v4l2buf_cb, 
in, 0);
+if (!*buf)
+return AVERROR(ENOMEM);
+
+in->status = V4L2BUF_RET_USER;
+
+return 0;
+}

This looks like it would trigger massive UB if you keep a frame after
the decoder is closed.  This should not happen, an AVBufferRef must
stay valid forever.


Yes you are right.

v4l2 uses a limited number of buffers in physical memory that it reuses 
during the video operation.
these buffers must be mapped to the process address space before they 
can be used.


for decoding, ffmpeg maps the V4L2 physical buffers, memcpies the input 
data to the output queue and uses the _references_ from the capture 
queue to create AVBufferRefs (these references are mmaped addresses of 
physical memory buffers).


In the current design buffers are not be reused until their 
corresponding AVBufferRefs are released (notice that freeing an 
AVBufferRef executes the callback that sets the V4L2BUF_AVAILABLE flag 
making it ready to be enqueued again).


So:

1. would it be acceptable if I stopped the codec from ummaping its 
buffers until all AVBufferRefs have been freed?

From what you are saying I think this has to be done.

2. also notice that if ffmpeg keeps all the AVBufferRefs for 'too long' 
this would cause the v4l2 pipeline to starve.


I have not seen this case (I have tested all decoders with ffplay) but 
from what you are saying it could be possible (typical hardware can 
handle 32 physical buffers although v4l2 applications rarely request so 
many).
Is there any way in ffmpeg to catch this condition and force the release 
of some of the AVBuffers?



















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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate()

2017-08-27 Thread Michael Niedermayer 
On Sat, Aug 26, 2017 at 02:26:08PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 8903997421129740175 + 
> 354481484684609529 cannot be represented in type 'long'
> Fixes: 2045/clusterfuzz-testcase-minimized-6751255865065472
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/sbrdsp_fixed.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)

patchset applied

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

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


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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

2017-08-27 Thread pkv.stream 

Le 27/08/2017 à 6:14 PM, Marton Balint a écrit :



On Wed, 23 Aug 2017, pkv.stream wrote:


Hello

the following patch extends number of output channel for decklink 
devices to 16. Previously it was limited to 2 or 8 audio channels.


Thanks for any comments.


Thanks, applied.

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


thanks Marton

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

2017-08-27 Thread Michael Niedermayer 
On Sat, Aug 26, 2017 at 01:26:58AM +0200, Michael Niedermayer wrote:
> Fixes: loop.m3u
> 
> The default max iteration count of 1000 is arbitrary and ideas for a better 
> solution are welcome
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/demuxers.texi | 18 ++
>  libavformat/hls.c |  7 +++
>  2 files changed, 25 insertions(+)

applied

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH] avformat/asfdec: Fix DoS due to lack of eof check

2017-08-27 Thread Michael Niedermayer 
On Fri, Aug 25, 2017 at 12:37:25PM +0200, Michael Niedermayer wrote:
> From: "wangchu@alibaba-inc.com" 
> 
> Fixes: loop.asf
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/asfdec_f.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH 3/6] avformat/rl2: Fix DoS due to lack of eof check

2017-08-27 Thread Michael Niedermayer 
On Fri, Aug 25, 2017 at 01:15:29AM +0200, Michael Niedermayer wrote:
> From: 孙浩 and 张洪亮(望初) 
> 
> Fixes: loop.rl2
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rl2.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

applied

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH 4/6] avformat/mvdec: Fix DoS due to lack of eof check

2017-08-27 Thread Michael Niedermayer 
On Fri, Aug 25, 2017 at 01:15:30AM +0200, Michael Niedermayer wrote:
> Fixes: loop.mv
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mvdec.c | 2 ++
>  1 file changed, 2 insertions(+)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH 2/6] avformat/rmdec: Fix DoS due to lack of eof check

2017-08-27 Thread Michael Niedermayer 
On Fri, Aug 25, 2017 at 01:15:28AM +0200, Michael Niedermayer wrote:
> From: 孙浩 and 张洪亮(望初) 
> 
> Fixes: loop.ivr
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rmdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

applied

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/cinedec: Fix DoS due to lack of eof check

2017-08-27 Thread Michael Niedermayer 
On Fri, Aug 25, 2017 at 01:15:27AM +0200, Michael Niedermayer wrote:
> From: 孙浩 and 张洪亮(望初) 
> 
> Fixes: loop.cine
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/cinedec.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

applied

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling

2017-08-27 Thread Marton Balint 



On Sat, 12 Aug 2017, Dave Rice wrote:

[..]


Also utils.c associates these field order values with the following labels:


AV_FIELD_TB  -> "top coded first (swapped)";
AV_FIELD_BT -> "bottom coded first (swapped)";


From my reading, I infer that "top coded first (swapped)” means "top 
coded first, bottom displayed first”; however in practice from files 
generated by QuickTime and FFmpeg files with a value of TB have the top 
field displayed first, so I think the labels are swapped. In the patch 
below I suggest using “top first (interleaved)” for TB and “bottom first 
(interleaved)” for BT.


Comments?


From de871b3fa891fa0ae6856461c1f8305cc889cde7 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Sat, 12 Aug 2017 12:30:43 -0400
Subject: [PATCH] libavcodec: fix field_order labelling

---
libavcodec/avcodec.h | 4 ++--
libavcodec/utils.c   | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993766..37c39072b3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1726,8 +1726,8 @@ enum AVFieldOrder {
AV_FIELD_PROGRESSIVE,
AV_FIELD_TT,  //< Top coded_first, top displayed first
AV_FIELD_BB,  //< Bottom coded first, bottom displayed first
-AV_FIELD_TB,  //< Top coded first, bottom displayed first
-AV_FIELD_BT,  //< Bottom coded first, top displayed first
+AV_FIELD_TB,  //< Interleaved coding, top displayed first
+AV_FIELD_BT,  //< Interleaved coding, bottom displayed first
};


I agree that a lot of stuff in the codebase is consistent with the updated 
descriptions. However, as far as I see libavformat/mxfdec.c seems to 
follow the existing docs, so I think that needs changing as well.


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

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

2017-08-27 Thread Maksym Veremeyenko 

27.08.2017 19:13, Marton Balint пише:



On Fri, 25 Aug 2017, Maksym Veremeyenko wrote:


25.08.2017 0:17, Marton Balint пише:
[...]
Ok. If it works in v3, then I guess it is OK to apply as is. Let me 
know when you want me to do that.


please apply


Applied with a small fix to the docs describing encoder supported pixel 
formats.

thanks

--
Maksym Veremeyenko

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

[FFmpeg-devel] [PATCH] avio: add a destructor for AVIOContext

2017-08-27 Thread James Almer 
From: Anton Khirnov 

Before this commit, AVIOContext is to be freed with a plain av_free(),
which prevents us from adding any deeper structure to it.

(cherry picked from commit 99684f3ae752fc8bfb44a2dd1482f8d7a3d8536d)
Signed-off-by: James Almer 
---
 doc/APIchanges|  3 +++
 libavformat/avio.h|  8 
 libavformat/aviobuf.c | 17 ++---
 libavformat/version.h |  2 +-
 4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 7babf5babb..880c791f5c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavf 57.79.100 / 57.11.0 - avio.h
+  Add avio_context_free(). From now on it must be used for freeing AVIOContext.
+
 2017-08-08 - xxx - lavu 55.74.100 - pixdesc.h
   Add AV_PIX_FMT_FLAG_FLOAT pixel format flag.
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index f14b003ba5..ea56dad503 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -467,6 +467,14 @@ AVIOContext *avio_alloc_context(
   int (*write_packet)(void *opaque, uint8_t *buf, int 
buf_size),
   int64_t (*seek)(void *opaque, int64_t offset, int whence));
 
+/**
+ * Free the supplied IO context and everything associated with it.
+ *
+ * @param s Double pointer to the IO context. This function will write NULL
+ * into s.
+ */
+void avio_context_free(AVIOContext **s);
+
 void avio_w8(AVIOContext *s, int b);
 void avio_write(AVIOContext *s, const unsigned char *buf, int size);
 void avio_wl64(AVIOContext *s, uint64_t val);
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index ec21fc7d38..716c42eda9 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -143,6 +143,11 @@ AVIOContext *avio_alloc_context(
 return s;
 }
 
+void avio_context_free(AVIOContext **ps)
+{
+av_freep(ps);
+}
+
 static void writeout(AVIOContext *s, const uint8_t *data, int len)
 {
 if (!s->error) {
@@ -1123,7 +1128,9 @@ int avio_close(AVIOContext *s)
 else
 av_log(s, AV_LOG_DEBUG, "Statistics: %"PRId64" bytes read, %d 
seeks\n", s->bytes_read, s->seek_count);
 av_opt_free(s);
-av_free(s);
+
+avio_context_free();
+
 return ffurl_close(h);
 }
 
@@ -1356,7 +1363,9 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer)
 *pbuffer = d->buffer;
 size = d->size;
 av_free(d);
-av_free(s);
+
+avio_context_free();
+
 return size - padding;
 }
 
@@ -1399,6 +1408,8 @@ int ffio_close_null_buf(AVIOContext *s)
 
 size = d->size;
 av_free(d);
-av_free(s);
+
+avio_context_free();
+
 return size;
 }
diff --git a/libavformat/version.h b/libavformat/version.h
index 94081aca81..3029a5e767 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  78
+#define LIBAVFORMAT_VERSION_MINOR  79
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-27 Thread Jorge Ramirez 

On 08/25/2017 05:35 PM, wm4 wrote:

That looks generally OK. Is there any chance a hwaccel approach would
be possible instead? If I've learned anything about hardware decoding,
then that hwaccel is vastly superior to vendor-implemented full stream
decoders.


could you help me understand what would that entitle and what how would 
that be beneficial to the users?

I just dont feel I can answer that question properly...

v4l2 provides a generic API  which is what the patchset uses to perform 
encoding/decoding on any v4l2 supported hardware (it is completely 
vendor independent)


From the layer above (libavcodec) all it needs is a way to get the 
frame information and after processing to pass it back; so in principle, 
if the hwaccel API provides that, I could just move it all to use those 
calls if you think that fits better with ffmpeg.


but I dont think I understand the benefit of changing from the ffmpeg 
encoding/decoding API to hwaccel API.




I don't think I like the attempt of sharing the v4l helper functions
between libavdevice and libavcodec, but I can't tell how much it helps.


ok. I am of course open to suggestions on this (I didnt see any issues 
with what the patchset provides or I would have done it differently).

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-27 Thread Jorge Ramirez 

On 08/25/2017 05:35 PM, wm4 wrote:

+#define WIDTH(__ctx, __fmt) \
+(V4L2_TYPE_IS_MULTIPLANAR((__ctx)->type) ? __fmt.fmt.pix_mp.width : 
__fmt.fmt.pix.width)
+
+#define HEIGHT(__ctx, __fmt) \
+(V4L2_TYPE_IS_MULTIPLANAR((__ctx)->type) ? __fmt.fmt.pix_mp.height : 
__fmt.fmt.pix.height)

These names are a bit generic. Also, identifiers starting with __ are
always implementation reserved (i.e. using them undefined behavior).
You're forgetting to quote the __fmt macro parameter too.



ok, will just do inline functions instead. I shouldnt have done a macro...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

2017-08-27 Thread Marton Balint 



On Wed, 23 Aug 2017, pkv.stream wrote:


Hello

the following patch extends number of output channel for decklink devices to 
16. Previously it was limited to 2 or 8 audio channels.


Thanks for any comments.


Thanks, applied.

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

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

2017-08-27 Thread Marton Balint 



On Fri, 25 Aug 2017, Maksym Veremeyenko wrote:


25.08.2017 0:17, Marton Balint пише:
[...]
Ok. If it works in v3, then I guess it is OK to apply as is. Let me know 
when you want me to do that.


please apply


Applied with a small fix to the docs describing encoder supported pixel 
formats.


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

Re: [FFmpeg-devel] [PATCHv6 1/4] Move lavd/v4l2-common.* to lavc

2017-08-27 Thread Jorge Ramirez 

On 08/25/2017 09:03 PM, Paul B Mahol wrote:

Does lavd stuff now depends on lavc?

um yes, v4l2 in/out devices (lavd) do use a common file now present in
lavc (ie: v4l2_fmt.c).

see libavcodec/Makefile:

OBJS-$(CONFIG_V4L2)+= v4l2_fmt.o
OBJS-$(CONFIG_V4L2_M2M)+= v4l2_m2m.o v4l2_buffers.o

also note that the common file doesn't depend on the new V4L2_M2M
decoders/encoders being available (only on V4L2)

Than relevant devices in lavd should be marked to depend on lavc.

Hi Paul,

could you tell me how please?

I can see that the direct show capture interface (libavdevice/dshow.c) 
has similar dependencies with avcodec but I can't figure out how it 
explicitly flags that it depends on the raw.c codec in the way that you 
suggest.






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

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Evert Vorster 
Hi there, Clement.

Thanks for the reply.
Unfortunately, coding is not my strong suite, I would not even know where
to begin looking.
The "backward" switch was a big clue that this vignetting filter is more
for the effect than actually removing the vignetting effect from footage.

The lens corrections are taken care of, fortunately, by nona being able to
output an x and y pair of remap files that ffmpeg is able to use in the
remap filter.

I am aware of the lenscorrection filter, but from my reading of the manual
it deals more with lens distortions rather than chromatic aberrations.

Of course, far quicker than continually calculating the vignetting &
chromic aberrations, it would be faster to apply a color map to the images,
either before or after remapping, but I have not figured out how to do
that, either.

Currently I am exploring all the options, and hopefully I will find
something that is easy enough to use.

Kind regards.
-Evert-

On 27 August 2017 at 16:31, Clément Bœsch  wrote:

> On Sun, Aug 27, 2017 at 08:33:30AM +0100, Evert Vorster wrote:
> > Unfortunately I have a real problem with vignetting.
> > The vignette filter in ffmpeg seems to have some room for improvement.
>
> Yeah, definitely: the vignette filter was written with the fancy
> vignetting effect in mind (think of it as a filter to simulate old school
> movies to be used with an additional vf curves=preset=vintage). Making a
> backward mode was made because it was relatively trivial to make, but it
> certainly is currently pretty limited for actual corrections. Patches
> welcome. The code is not very complex, and if you can understand the
> underlying maths (which you probably do given the project you're working
> on), adding options to the filters for your needs should be accessible.
>
> Also note the existence of lenscorrection filter, which may, or may not be
> of use while trying to improve the vignette filter.
>
> [...]
>
> Regards,
>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


-- 
Evert Vorster
Isometrix Acquistion Superchief
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Clément Bœsch 
On Sun, Aug 27, 2017 at 08:33:30AM +0100, Evert Vorster wrote:
> Unfortunately I have a real problem with vignetting.
> The vignette filter in ffmpeg seems to have some room for improvement.

Yeah, definitely: the vignette filter was written with the fancy
vignetting effect in mind (think of it as a filter to simulate old school
movies to be used with an additional vf curves=preset=vintage). Making a
backward mode was made because it was relatively trivial to make, but it
certainly is currently pretty limited for actual corrections. Patches
welcome. The code is not very complex, and if you can understand the
underlying maths (which you probably do given the project you're working
on), adding options to the filters for your needs should be accessible.

Also note the existence of lenscorrection filter, which may, or may not be
of use while trying to improve the vignette filter.

[...]

Regards,

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

2017-08-27 Thread Rodger Combs 
You're still calling snprintf with a string derived from the XML, which is 
still not safe. Rather than having a format copied from the source in 
get_repl_pattern_and_format, you should have a fixed value of something like 
`"%0*"PRId64`, and specify an additional "precision" argument you parse from 
the XML yourself. I can't reiterate this enough: _never pass data from the XML 
into the format-string arg of a printf-family function_.

Also, rather than calling snprintf() twice with an av_malloc() in between, you 
can just call av_asprintf(). That's what it does internally anyway.

> On Aug 27, 2017, at 09:19, Steven Liu  wrote:
> 
> ffmpeg need a dash demuxer for demux the dash formats base on
> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
> 
> TODO:
> 1. support multi bitrate dash
> 
> v2 fixed:
> 1. from autodetect to disabled
> 2. from camelCase code style to ffmpeg code style
> 3. from RepType to AVMediaType
> 4. fix variable typo
> 5. change time value from uint32_t to uint64_t
> 6. removed be used once API
> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
> av_timegm
> 8. merge complex free operation to free_fragment
> 9. use API from snprintf to av_asprintf
> 
> v3 fixed:
> 1. fix typo from --enabled-xml2 to --enable-xml2
> 
> v4 fixed:
> 1. from --enable-xml2 to --enable-libxml2
> 2. move system includes to top
> 3. remove nouse includes
> 4. rename enum name
> 5. add a trailing comma for the last entry enum
> 6. fix comment typo
> 7. add const to DASHContext class front
> 8. check sscanf if return arguments and give warning message when error
> 9. check validity before free seg->url and seg
> 10. check if the val is null, before use atoll
> 
> v5 fixed:
> 1. fix typo from mainifest to manifest
> 
> v6 fixed:
> 1. from realloc to av_realloc
> 2. from free to av_free
> 
> v7 fixed:
> 1. remove the -lxml2 from configure when require_pkg_config
> 
> v8 fixed:
> 1. fix replace filename template by av_asprintf secure problem
> 
> v9 modified:
> 1. make manifest parser clearly
> 
> v10 fixed:
> 1. fix function API name code style
> 2. remove redundant strreplace call
> 3. remove redundant memory operation and check return value from 
> get_content_url()
> 4. add space between ) and {
> 5. remove no need to log the value for print
> 
> v11 fixed:
> 1. from atoll to strtoll
> 
> v12 fixed:
> 1. remove strreplace and instead by av_strreplace
> 
> v13 fixed:
> 1. fix bug: cannot play:
> http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
> 
> v14 fixed:
> 1. fix bug: TLS connection was non-properly terminated
> 2. fix bug: No trailing CRLF found in HTTP header
> 
> v15 fixed:
> 1. play youtube link: ffmpeg -i $(youtube-dl -J 
> "https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
> ".requested_formats[0].manifest_url")
> 2. code refine for timeline living stream
> 
> Reviewed-by: Clément Bœsch 
> Reviewed-by: Michael Niedermayer 
> Reviewed-by: Carl Eugen Hoyos 
> Reviewed-by: Rodger Combs 
> Reviewed-by: Moritz Barsnick 
> Reviewed-by: Nicolas George 
> Reviewed-by: Ricardo Constantino 
> Reviewed-by: wm4 
> Tested-by: Andy Furniss 
> Reported-by: Andy Furniss 
> Signed-off-by: Steven Liu 
> Signed-off-by: samsamsam 
> ---
> configure|4 +
> libavformat/Makefile |1 +
> libavformat/allformats.c |2 +-
> libavformat/dashdec.c| 1981 ++
> 4 files changed, 1987 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/dashdec.c
> 
> diff --git a/configure b/configure
> index 05f6dcc99a..7a7d61fa13 100755
> --- a/configure
> +++ b/configure
> @@ -272,6 +272,7 @@ External library support:
>   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
>   --enable-libxvid enable Xvid encoding via xvidcore,
>native MPEG-4/Xvid encoder exists [no]
> +  --enable-libxml2 enable XML parsing using the C library libxml2 
> [no]
>   --enable-libzimg enable z.lib, needed for zscale filter [no]
>   --enable-libzmq  enable message passing via libzmq [no]
>   --enable-libzvbi enable teletext support via libzvbi [no]
> @@ -1576,6 +1577,7 @@ EXTERNAL_LIBRARY_LIST="
> libvpx
> libwavpack
> libwebp
> +libxml2
> libzimg
> libzmq
> libzvbi
> @@ -2937,6 +2939,7 @@ avi_muxer_select="riffenc"
> caf_demuxer_select="iso_media riffdec"
> caf_muxer_select="iso_media"
> dash_muxer_select="mp4_muxer"
> +dash_demuxer_deps="libxml2"
> dirac_demuxer_select="dirac_parser"
> dts_demuxer_select="dca_parser"
> dtshd_demuxer_select="dca_parser"
> @@ -5996,6 +5999,7 @@ enabled openssl   && {

[FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

2017-08-27 Thread Steven Liu 
ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO:
1. support multi bitrate dash

v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf

v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2

v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll

v5 fixed:
1. fix typo from mainifest to manifest

v6 fixed:
1. from realloc to av_realloc
2. from free to av_free

v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config

v8 fixed:
1. fix replace filename template by av_asprintf secure problem

v9 modified:
1. make manifest parser clearly

v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from 
get_content_url()
4. add space between ) and {
5. remove no need to log the value for print

v11 fixed:
1. from atoll to strtoll

v12 fixed:
1. remove strreplace and instead by av_strreplace

v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd

v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header

v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J 
"https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
".requested_formats[0].manifest_url")
2. code refine for timeline living stream

Reviewed-by: Clément Bœsch 
Reviewed-by: Michael Niedermayer 
Reviewed-by: Carl Eugen Hoyos 
Reviewed-by: Rodger Combs 
Reviewed-by: Moritz Barsnick 
Reviewed-by: Nicolas George 
Reviewed-by: Ricardo Constantino 
Reviewed-by: wm4 
Tested-by: Andy Furniss 
Reported-by: Andy Furniss 
Signed-off-by: Steven Liu 
Signed-off-by: samsamsam 
---
 configure|4 +
 libavformat/Makefile |1 +
 libavformat/allformats.c |2 +-
 libavformat/dashdec.c| 1981 ++
 4 files changed, 1987 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dashdec.c

diff --git a/configure b/configure
index 05f6dcc99a..7a7d61fa13 100755
--- a/configure
+++ b/configure
@@ -272,6 +272,7 @@ External library support:
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+  --enable-libxml2 enable XML parsing using the C library libxml2 [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -1576,6 +1577,7 @@ EXTERNAL_LIBRARY_LIST="
 libvpx
 libwavpack
 libwebp
+libxml2
 libzimg
 libzmq
 libzvbi
@@ -2937,6 +2939,7 @@ avi_muxer_select="riffenc"
 caf_demuxer_select="iso_media riffdec"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
+dash_demuxer_deps="libxml2"
 dirac_demuxer_select="dirac_parser"
 dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
@@ -5996,6 +5999,7 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
 enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
qtkit_indev; }
+enabled libxml2  && require_pkg_config libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
 
 if enabled gcrypt; then
 GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index f2b465cfa2..3d478749d0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -133,6 +133,7 @@ OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
 OBJS-$(CONFIG_DASH_MUXER)+= dashenc.o

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Evert Vorster 
Hi there, Paul.

The nona program can be called from the command line, with an .pto file to
tell it what corrections to do, as well as input images. It then does the
vignetting corrections first, and then re-maps the images on to a canvas.

The idea of the re-mapped images is that you can then blend them together
with either the "enblend" tool, also included in Hugin, or multiblend, or
photoshop, or whatever. The software was created to create panoramas from
stills. For this to work, vignetting also has to be corrected for.

Of course, I just want to blend pairs of images together for my
application, but vignetting is no less of a problem.
When I use the nona program to remap the images, I get a remap every two
seconds. This is not too bad where one is blending a panorama, as there are
only ever a handful of images to be remapped and blended.

When I use ffmpeg's remap filter, I get about 5 frames a second. When I
apply the best fit of ffmpeg's vignetting filter that I can manage, that
drops to 3 frames per second. Unfortunately, ffmpeg's vignetting correction
is rather limited, and I can still see the vignetting on my output images.

When I make the vignetting stronger, it only washes out the entire image,
and I still have vignetting to contend with. If I could specify a formula
for the vignetting filter in ffmpeg, then I would be able to perfectly
describe the vignetting charateristics of my lenses, or any circular lens.

This is the formula that hugin (and nona) uses:
a * r^2 + b * r^4 + c * r ^6, along with x and y for center shift.

You would set a, b, c, x and y, and r would be the distance away from x, y.
If ffmpeg can implement the same formula, that would mean that I could
re-use the values calculated by Hugin.

Kind regards,
Evert


On 27 August 2017 at 14:09, Paul B Mahol  wrote:

> On 8/27/17, Evert Vorster  wrote:
> > Hi there.
> >
> > The program's name is nona, and it is distributed in source code form
> with
> > Hugin.
> > http://hugin.sourceforge.net/docs/manual/Nona.html
> >
> > The source code and descritpions is available here:
> > http://hugin.sourceforge.net/docs/html/index.html
> >
> > I hope it helps?
>
> How is one supposed to use it to change vignetting?
>
> >
> > On 27 August 2017 at 13:35, Paul B Mahol  wrote:
> >
> >> On 8/27/17, Evert Vorster  wrote:
> >> > Hi there.
> >>
> >> Hi,
> >>
> >> >
> >> > I have asked this question on the ffmpeg-users list, but it's been
> oddly
> >> > quiet on this front.
> >> >
> >> > I am trying to create a ffmpeg command line that re-maps and stitches
> >> > together footage from the Samsung Gear 360 camera. The basic methodoly
> >> can
> >> > be applied to any 360 view camera. The reason I am doing this is that
> >> > the
> >> > software that is available to do this is closed source and extremely
> >> > expensive. For a hobbiest, this is a bad situation.
> >> >
> >> > First thing I do, is to load a specially crafted series of frames in
> >> Hugin,
> >> > and perfectly map the lenses.
> >> > Then I make the remap files that the ffmpeg remap filter uses with
> nona
> >> -c.
> >> > I hand craft a alpha map to do the blending between the lenses, and
> the
> >> > results are really good.
> >> >
> >> > Unfortunately I have a real problem with vignetting.
> >> > The vignette filter in ffmpeg seems to have some room for improvement.
> >> > In Ffmpeg there is only one variable, and the x,y center. This allows
> >> > for
> >> > only one type of vignetting correction with the "backward" option set.
> >> >
> >> > In Hugin (and the panotools) the lens is described with 3 variables,
> and
> >> an
> >> > x,y center. This enables the vignetting strength to be described as a
> >> > custom curve.
> >> >
> >> > If you are curious about the project, this is the github page, with
> >> > examples.
> >> > https://github.com/evertvorster/dualfisheye2equirectangular_
> ffmpeg_remap
> >> > There are example .pto files, that when loaded in Hugin show the lens
> >> > chataristics of the Samsung Gear 360 lenses, and some sample footage
> to
> >> > test on.
> >> >
> >> > How difficult would it be to port the panotools' vignetting correcting
> >> > filter into ffmpeg?
> >>
> >> How it is actually named?
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> >
> >
> > --
> > Evert Vorster
> > Isometrix Acquistion Superchief
> > ___
> > 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
>



-- 
Evert Vorster
Isometrix Acquistion Superchief
___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Paul B Mahol 
On 8/27/17, Evert Vorster  wrote:
> Hi there.
>
> The program's name is nona, and it is distributed in source code form with
> Hugin.
> http://hugin.sourceforge.net/docs/manual/Nona.html
>
> The source code and descritpions is available here:
> http://hugin.sourceforge.net/docs/html/index.html
>
> I hope it helps?

How is one supposed to use it to change vignetting?

>
> On 27 August 2017 at 13:35, Paul B Mahol  wrote:
>
>> On 8/27/17, Evert Vorster  wrote:
>> > Hi there.
>>
>> Hi,
>>
>> >
>> > I have asked this question on the ffmpeg-users list, but it's been oddly
>> > quiet on this front.
>> >
>> > I am trying to create a ffmpeg command line that re-maps and stitches
>> > together footage from the Samsung Gear 360 camera. The basic methodoly
>> can
>> > be applied to any 360 view camera. The reason I am doing this is that
>> > the
>> > software that is available to do this is closed source and extremely
>> > expensive. For a hobbiest, this is a bad situation.
>> >
>> > First thing I do, is to load a specially crafted series of frames in
>> Hugin,
>> > and perfectly map the lenses.
>> > Then I make the remap files that the ffmpeg remap filter uses with nona
>> -c.
>> > I hand craft a alpha map to do the blending between the lenses, and the
>> > results are really good.
>> >
>> > Unfortunately I have a real problem with vignetting.
>> > The vignette filter in ffmpeg seems to have some room for improvement.
>> > In Ffmpeg there is only one variable, and the x,y center. This allows
>> > for
>> > only one type of vignetting correction with the "backward" option set.
>> >
>> > In Hugin (and the panotools) the lens is described with 3 variables, and
>> an
>> > x,y center. This enables the vignetting strength to be described as a
>> > custom curve.
>> >
>> > If you are curious about the project, this is the github page, with
>> > examples.
>> > https://github.com/evertvorster/dualfisheye2equirectangular_ffmpeg_remap
>> > There are example .pto files, that when loaded in Hugin show the lens
>> > chataristics of the Samsung Gear 360 lenses, and some sample footage to
>> > test on.
>> >
>> > How difficult would it be to port the panotools' vignetting correcting
>> > filter into ffmpeg?
>>
>> How it is actually named?
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
>
> --
> Evert Vorster
> Isometrix Acquistion Superchief
> ___
> 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] FFmpeg 3.4

2017-08-27 Thread Marton Balint 


On Sat, 26 Aug 2017, Michael Niedermayer wrote:


On Sat, Aug 26, 2017 at 11:03:27AM -0300, James Almer wrote:

On 8/26/2017 6:28 AM, Michael Niedermayer wrote:

Hi all

Its a while since FFmpeg 3.3, so its time again to make a new release

I intend to make 3.4 in the next weeks
Name suggestions needed like always


Could this wait until after the major bump? I'm currently working on
cherry picking the relevant changes.
We really don't need another release using this set of major versions.
The less amount of releases using them we have to maintain the better.


i remember no discussion about a major bump

but assuming there would be a discussion on ffmpeg-devel and people
would agree to bump then i think releasing before is better.

It makes the new features available throgh the current API/ABI and
we would avoid making a release shortly after major changes.
That would give such changes more time to be tested before a release


Also there are the filtering regressions, the fixes for them cannot be 
backported to 3.3 easily, so +1 for releasing befor the bump.


If there are people interested in carrying on the merges, (thanks!) then 
maybe all changes before the bump should be included as well.


And ticket 6375 comes to mind, as far as I remember there were some 
fixable and some unfixable issues, it is definitely worth taking another 
look before the release.


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

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Evert Vorster 
Hi there.

The program's name is nona, and it is distributed in source code form with
Hugin.
http://hugin.sourceforge.net/docs/manual/Nona.html

The source code and descritpions is available here:
http://hugin.sourceforge.net/docs/html/index.html

I hope it helps?

On 27 August 2017 at 13:35, Paul B Mahol  wrote:

> On 8/27/17, Evert Vorster  wrote:
> > Hi there.
>
> Hi,
>
> >
> > I have asked this question on the ffmpeg-users list, but it's been oddly
> > quiet on this front.
> >
> > I am trying to create a ffmpeg command line that re-maps and stitches
> > together footage from the Samsung Gear 360 camera. The basic methodoly
> can
> > be applied to any 360 view camera. The reason I am doing this is that the
> > software that is available to do this is closed source and extremely
> > expensive. For a hobbiest, this is a bad situation.
> >
> > First thing I do, is to load a specially crafted series of frames in
> Hugin,
> > and perfectly map the lenses.
> > Then I make the remap files that the ffmpeg remap filter uses with nona
> -c.
> > I hand craft a alpha map to do the blending between the lenses, and the
> > results are really good.
> >
> > Unfortunately I have a real problem with vignetting.
> > The vignette filter in ffmpeg seems to have some room for improvement.
> > In Ffmpeg there is only one variable, and the x,y center. This allows for
> > only one type of vignetting correction with the "backward" option set.
> >
> > In Hugin (and the panotools) the lens is described with 3 variables, and
> an
> > x,y center. This enables the vignetting strength to be described as a
> > custom curve.
> >
> > If you are curious about the project, this is the github page, with
> > examples.
> > https://github.com/evertvorster/dualfisheye2equirectangular_ffmpeg_remap
> > There are example .pto files, that when loaded in Hugin show the lens
> > chataristics of the Samsung Gear 360 lenses, and some sample footage to
> > test on.
> >
> > How difficult would it be to port the panotools' vignetting correcting
> > filter into ffmpeg?
>
> How it is actually named?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



-- 
Evert Vorster
Isometrix Acquistion Superchief
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Paul B Mahol 
On 8/27/17, Evert Vorster  wrote:
> Hi there.

Hi,

>
> I have asked this question on the ffmpeg-users list, but it's been oddly
> quiet on this front.
>
> I am trying to create a ffmpeg command line that re-maps and stitches
> together footage from the Samsung Gear 360 camera. The basic methodoly can
> be applied to any 360 view camera. The reason I am doing this is that the
> software that is available to do this is closed source and extremely
> expensive. For a hobbiest, this is a bad situation.
>
> First thing I do, is to load a specially crafted series of frames in Hugin,
> and perfectly map the lenses.
> Then I make the remap files that the ffmpeg remap filter uses with nona -c.
> I hand craft a alpha map to do the blending between the lenses, and the
> results are really good.
>
> Unfortunately I have a real problem with vignetting.
> The vignette filter in ffmpeg seems to have some room for improvement.
> In Ffmpeg there is only one variable, and the x,y center. This allows for
> only one type of vignetting correction with the "backward" option set.
>
> In Hugin (and the panotools) the lens is described with 3 variables, and an
> x,y center. This enables the vignetting strength to be described as a
> custom curve.
>
> If you are curious about the project, this is the github page, with
> examples.
> https://github.com/evertvorster/dualfisheye2equirectangular_ffmpeg_remap
> There are example .pto files, that when loaded in Hugin show the lens
> chataristics of the Samsung Gear 360 lenses, and some sample footage to
> test on.
>
> How difficult would it be to port the panotools' vignetting correcting
> filter into ffmpeg?

How it is actually named?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Vignette filter limitations...

2017-08-27 Thread Evert Vorster 
Hi there.

I have asked this question on the ffmpeg-users list, but it's been oddly
quiet on this front.

I am trying to create a ffmpeg command line that re-maps and stitches
together footage from the Samsung Gear 360 camera. The basic methodoly can
be applied to any 360 view camera. The reason I am doing this is that the
software that is available to do this is closed source and extremely
expensive. For a hobbiest, this is a bad situation.

First thing I do, is to load a specially crafted series of frames in Hugin,
and perfectly map the lenses.
Then I make the remap files that the ffmpeg remap filter uses with nona -c.
I hand craft a alpha map to do the blending between the lenses, and the
results are really good.

Unfortunately I have a real problem with vignetting.
The vignette filter in ffmpeg seems to have some room for improvement.
In Ffmpeg there is only one variable, and the x,y center. This allows for
only one type of vignetting correction with the "backward" option set.

In Hugin (and the panotools) the lens is described with 3 variables, and an
x,y center. This enables the vignetting strength to be described as a
custom curve.

If you are curious about the project, this is the github page, with
examples.
https://github.com/evertvorster/dualfisheye2equirectangular_ffmpeg_remap
There are example .pto files, that when loaded in Hugin show the lens
chataristics of the Samsung Gear 360 lenses, and some sample footage to
test on.

How difficult would it be to port the panotools' vignetting correcting
filter into ffmpeg?
-- 
Evert Vorster
Isometrix Acquistion Superchief
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_amix: switch to activate

2017-08-27 Thread Paul B Mahol 
On 8/27/17, Michael Niedermayer  wrote:
> On Sat, Aug 26, 2017 at 10:22:38PM -0300, James Almer wrote:
>> On 8/26/2017 9:59 PM, Michael Niedermayer wrote:
>> > On Sat, Aug 26, 2017 at 05:53:18PM +0200, Paul B Mahol wrote:
>> >> Really fixes hangs and infinite loops.
>> >>
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavfilter/af_amix.c | 161
>> >> +-
>> >>  1 file changed, 81 insertions(+), 80 deletions(-)
>> >
>> > This breaks fate:
>> >
>> > stddev:  0.00 PSNR:inf MAXDIFF: 0 bytes:  2116800/  1056768
>> > size: |2116800 - 1056768| >= 0
>> > stddev:  0.00 PSNR:inf MAXDIFF: 0 bytes:  2116800/   704512
>> > size: |2116800 - 704512| >= 0
>> > TESTfilter-hdcd-s16p
>> > Test filter-amix-simple failed. Look at
>> > tests/data/fate/filter-amix-simple.err for details.
>> > make: *** [fate-filter-amix-simple] Error 134
>> > make: *** [fate-filter-amix-transition] Error 134
>>
>> What system? FATE looks clean.
>
> nothing special just normal ubuntu x86-64
>
> i tool a closer look and it dies here:
> Assertion !link->status_in failed at libavfilter/avfilter.c:1639
> Aborted (core dumped)
> make: *** [fate-filter-amix-simple] Error 134
>
> thats a av_assert1(), i built with --assert-level=2

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

Re: [FFmpeg-devel] [PATCH]lavf/gdv: Improve palette saturation

2017-08-27 Thread Paul B Mahol 
On 8/26/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch slightly improves the saturation of the gdv palette.
>
> Please comment, Carl Eugen
>

Does this match how it is displayed by original game?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel