date:20170302

Re: [FFmpeg-devel] [PATCH] update to add preclose function, help to fix rtsp didn't send teardown after ffplay close stream

2017-03-02 Thread Hendrik Leppkes

On Thu, Mar 2, 2017 at 2:42 AM, Vincent Luo  wrote:
> From: Vincent Luo 
>
> ---
>  ffplay.c   |  1 +
>  libavformat/avformat.h | 11 ++-
>  libavformat/rtspdec.c  |  9 +
>  libavformat/utils.c| 12 
>  4 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/ffplay.c b/ffplay.c
> index 79dc768..42e538b 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -1178,6 +1178,7 @@ static void stream_component_close(VideoState *is, int 
> stream_index)
>
>  static void stream_close(VideoState *is)
>  {
> +avformat_preclose_input(>ic); //added by vincent 20170228 for send 
> teardown before close(Fix a rtsp issue)

Why would close not send a teardown, and even if it doesn't, why can't
this be fixed without adding some new API?

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

Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec: estimate output bitrate for uncompressed video codecs

2017-03-02 Thread Tobias Rapp


On 06.02.2017 13:33, Tobias Rapp wrote:

Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.

Signed-off-by: Tobias Rapp 
---
 libavcodec/r210enc.c | 15 +++
 libavcodec/rawenc.c  |  3 +++
 libavcodec/v210enc.c |  4 
 libavcodec/v308enc.c |  4 
 libavcodec/v408enc.c |  3 +++
 libavcodec/v410enc.c |  4 
 libavcodec/y41penc.c |  2 ++
 tests/ref/fate/v410enc   |  2 +-
 tests/ref/vsynth/vsynth1-bpp1|  2 +-
 tests/ref/vsynth/vsynth1-bpp15   |  2 +-
 tests/ref/vsynth/vsynth1-r210|  2 +-
 tests/ref/vsynth/vsynth1-rgb |  2 +-
 tests/ref/vsynth/vsynth1-v210|  2 +-
 tests/ref/vsynth/vsynth1-v210-10 |  2 +-
 tests/ref/vsynth/vsynth1-v308|  2 +-
 tests/ref/vsynth/vsynth1-v408|  2 +-
 tests/ref/vsynth/vsynth1-y41p|  2 +-
 tests/ref/vsynth/vsynth1-yuv |  2 +-
 tests/ref/vsynth/vsynth2-bpp1|  2 +-
 tests/ref/vsynth/vsynth2-bpp15   |  2 +-
 tests/ref/vsynth/vsynth2-r210|  2 +-
 tests/ref/vsynth/vsynth2-rgb |  2 +-
 tests/ref/vsynth/vsynth2-v210|  2 +-
 tests/ref/vsynth/vsynth2-v210-10 |  2 +-
 tests/ref/vsynth/vsynth2-v308|  2 +-
 tests/ref/vsynth/vsynth2-v408|  2 +-
 tests/ref/vsynth/vsynth2-y41p|  2 +-
 tests/ref/vsynth/vsynth2-yuv |  2 +-
 tests/ref/vsynth/vsynth3-bpp1|  2 +-
 tests/ref/vsynth/vsynth3-bpp15   |  2 +-
 tests/ref/vsynth/vsynth3-r210|  2 +-
 tests/ref/vsynth/vsynth3-rgb |  2 +-
 tests/ref/vsynth/vsynth3-v210|  2 +-
 tests/ref/vsynth/vsynth3-v210-10 |  2 +-
 tests/ref/vsynth/vsynth3-v308|  2 +-
 tests/ref/vsynth/vsynth3-v408|  2 +-
 tests/ref/vsynth/vsynth3-yuv |  2 +-
 tests/ref/vsynth/vsynth_lena-bpp1|  2 +-
 tests/ref/vsynth/vsynth_lena-bpp15   |  2 +-
 tests/ref/vsynth/vsynth_lena-r210|  2 +-
 tests/ref/vsynth/vsynth_lena-rgb |  2 +-
 tests/ref/vsynth/vsynth_lena-v210|  2 +-
 tests/ref/vsynth/vsynth_lena-v210-10 |  2 +-
 tests/ref/vsynth/vsynth_lena-v308|  2 +-
 tests/ref/vsynth/vsynth_lena-v408|  2 +-
 tests/ref/vsynth/vsynth_lena-y41p|  2 +-
 tests/ref/vsynth/vsynth_lena-yuv |  2 +-
 47 files changed, 75 insertions(+), 40 deletions(-)

[...]


I'd like to apply this patch soon, if there are no objections.

Regards,
Tobias


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

Re: [FFmpeg-devel] [PATCH v2 2/3] avcodec: estimate output bitrate for ffv1/huffyuv codecs

2017-03-02 Thread Tobias Rapp


On 06.02.2017 13:33, Tobias Rapp wrote:

Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.

Signed-off-by: Tobias Rapp 
---
 libavcodec/ffv1enc.c   |  4 
 libavcodec/huffyuvenc.c|  4 
 libavcodec/internal.h  |  6 ++
 libavcodec/utils.c | 21 +
 tests/ref/vsynth/vsynth1-ffv1  |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth1-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth1-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth1-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1  |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth2-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth2-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth2-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1  |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth3-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth3-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth3-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1  |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuvbgra   |  2 +-
 64 files changed, 95 insertions(+), 60 deletions(-)

[...]


I'd like to apply this patch soon, if there are no objections.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH] update to add preclose function, help to fix rtsp didn't send teardown after ffplay close stream

2017-03-02 Thread Vincent Luo

From: Vincent Luo 

---
 ffplay.c   |  1 +
 libavformat/avformat.h | 11 ++-
 libavformat/rtspdec.c  |  9 +
 libavformat/utils.c| 12 
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index 79dc768..42e538b 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1178,6 +1178,7 @@ static void stream_component_close(VideoState *is, int 
stream_index)
 
 static void stream_close(VideoState *is)
 {
+avformat_preclose_input(>ic); //added by vincent 20170228 for send 
teardown before close(Fix a rtsp issue)
 /* XXX: use a special url_shutdown call to abort parse cleanly */
 is->abort_request = 1;
 SDL_WaitThread(is->read_tid, NULL);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f9f4d72..c9f7a39 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -730,13 +730,18 @@ typedef struct AVInputFormat {
  */
 int (*read_packet)(struct AVFormatContext *, AVPacket *pkt);
 
+/**
+* The stream is going to be closed. The AVFormatContext and AVStreams are not
+* freed by this function
+*/
+int (*read_preclose)(struct AVFormatContext *);
 /**
  * Close the stream. The AVFormatContext and AVStreams are not
  * freed by this function
  */
 int (*read_close)(struct AVFormatContext *);
 
-/**
+/**
  * Seek to a given timestamp relative to the frames in
  * stream component stream_index.
  * @param stream_index Must not be -1.
@@ -2365,6 +2370,10 @@ int av_read_play(AVFormatContext *s);
 int av_read_pause(AVFormatContext *s);
 
 /**
+* Call before closing input AVFormatContext.
+*/
+void avformat_preclose_input(AVFormatContext **s);
+/**
  * Close an opened input AVFormatContext. Free it and all its contents
  * and set *s to NULL.
  */
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index a722b98..cdcd578 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -53,6 +53,14 @@ static const struct RTSPStatusMessage {
 { 0,  "NULL" }
 };
 
+static int rtsp_read_preclose(AVFormatContext *s)
+{
+RTSPState *rt = s->priv_data;
+
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
+   ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
+return 0;
+}
 static int rtsp_read_close(AVFormatContext *s)
 {
 RTSPState *rt = s->priv_data;
@@ -968,6 +976,7 @@ AVInputFormat ff_rtsp_demuxer = {
 .read_probe = rtsp_probe,
 .read_header= rtsp_read_header,
 .read_packet= rtsp_read_packet,
+.read_preclose  = rtsp_read_preclose,
 .read_close = rtsp_read_close,
 .read_seek  = rtsp_read_seek,
 .flags  = AVFMT_NOFILE,
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5664646..45656c2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4175,7 +4175,19 @@ void avformat_free_context(AVFormatContext *s)
 flush_packet_queue(s);
 av_free(s);
 }
+void avformat_preclose_input(AVFormatContext **ps)
+{
+   AVFormatContext *s;
+
+   if (!ps || !*ps)
+return;
 
+   s  = *ps;
+
+   if (s->iformat)
+   if (s->iformat->read_preclose)
+   s->iformat->read_preclose(s);
+}
 void avformat_close_input(AVFormatContext **ps)
 {
 AVFormatContext *s;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v5']

2017-03-02 Thread Takayuki 'January June' Suwa

From: Takayuki 'January June' Suwa 

This adds "-profile[:v] profile_name"-style option.
---
 libavcodec/omx.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..19b4f33 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
 int output_buf_size;
 
 int input_zerocopy;
+int profile;
 } OMXCodecContext;
 
 static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,19 @@ static av_cold int omx_component_init(AVCodecContext 
*avctx, const char *role)
 CHECK(err);
 avc.nBFrames = 0;
 avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile == FF_PROFILE_UNKNOWN ? avctx->profile : 
s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+default:
+break;
+}
 err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, );
 CHECK(err);
 }
@@ -884,6 +898,10 @@ static const AVOption options[] = {
 { "omx_libname", "OpenMAX library name", OFFSET(libname), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile",  "Set the encoding profile", OFFSET(profile), 
AV_OPT_TYPE_INT,   { .i64 = FF_PROFILE_UNKNOWN },   FF_PROFILE_UNKNOWN, 
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
+{ "main", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
+{ "high", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
 { NULL }
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread James Zern

On Thu, Mar 2, 2017 at 11:00 AM, Kagami Hiiragi  wrote:
> From ae3856c302284d60761c3ad122ff49b7b9b68114 Mon Sep 17 00:00:00 2001
> From: Kagami Hiiragi 
> Date: Thu, 2 Mar 2017 21:19:09 +0300
> Subject: [PATCH] lavc/libvpxenc: add -row-mt option
>
> ---
>  libavcodec/libvpxenc.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> [...]
>  [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
>  [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
>  #endif
> +#if VPX_ENCODER_ABI_VERSION >= 13

Better to use #ifdef VPX_CTRL_VP9E_SET_ROW_MT.

> [...]
> +#if VPX_ENCODER_ABI_VERSION >= 13
> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_INT, 
> {.i64 = -1}, -1, 1, VE},
> +#endif

We could use -thread_type/-slices here, though this is in line with
vpxenc. I'll leave this open to comment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-02 Thread wm4

On Fri, 3 Mar 2017 10:37:08 +0800
Wang Bin  wrote:

> It's macOS only. For iOS, we can use kCVPixelBufferOpenGLESCompatibilityKey

So what happens on iOS with the current code? If it doesn't work, could
you add support for using the iOS-specific constant on iOS? (From what
I know, GLES is exclusive to iOS, while real GL is exclusive to OSX, so
maybe not a huge problem.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avutil/md5: stop discarding the const qualifier for the src pointer

2017-03-02 Thread James Almer

The code modifying the buffer on big endian systems was removed.

Signed-off-by: James Almer 
---
 libavutil/md5.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavutil/md5.c b/libavutil/md5.c
index d3698dcb1d..1069ef1efe 100644
--- a/libavutil/md5.c
+++ b/libavutil/md5.c
@@ -98,11 +98,12 @@ static const uint32_t T[64] = { // T[i]= fabs(sin(i+1)<<32)
 a = b + (a << t | a >> (32 - t));   \
 } while (0)
 
-static void body(uint32_t ABCD[4], uint32_t *src, int nblocks)
+static void body(uint32_t ABCD[4], const uint8_t *src, int nblocks)
 {
 int i av_unused;
 int n;
-uint32_t a, b, c, d, t, *X;
+const uint32_t *X;
+uint32_t a, b, c, d, t;
 
 for (n = 0; n < nblocks; n++) {
 a = ABCD[3];
@@ -110,7 +111,7 @@ static void body(uint32_t ABCD[4], uint32_t *src, int 
nblocks)
 c = ABCD[1];
 d = ABCD[0];
 
-X = src + n * 16;
+X = (const uint32_t *)src + n * 16;
 
 #if CONFIG_SMALL
 for (i = 0; i < 64; i++) {
@@ -164,19 +165,19 @@ void av_md5_update(AVMD5 *ctx, const uint8_t *src, int 
len)
 len -= cnt;
 if (j + cnt < 64)
 return;
-body(ctx->ABCD, (uint32_t *)ctx->block, 1);
+body(ctx->ABCD, ctx->block, 1);
 }
 
 end = src + (len & ~63);
 if (!HAVE_FAST_UNALIGNED && ((intptr_t)src & 3)) {
while (src < end) {
memcpy(ctx->block, src, 64);
-   body(ctx->ABCD, (uint32_t *) ctx->block, 1);
+   body(ctx->ABCD, ctx->block, 1);
src += 64;
 }
 } else {
 int nblocks = len / 64;
-body(ctx->ABCD, (uint32_t *)src, nblocks);
+body(ctx->ABCD, src, nblocks);
 src = end;
 }
 len &= 63;
-- 
2.12.0

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

[FFmpeg-devel] [PATCH 1/2] avutil/md5: fix misaligned reads

2017-03-02 Thread James Almer

This makes ubsan happy and also considerably increases performance on
big endian systems.

Signed-off-by: James Almer 
---
 libavutil/md5.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/libavutil/md5.c b/libavutil/md5.c
index 8c36aa80c4..d3698dcb1d 100644
--- a/libavutil/md5.c
+++ b/libavutil/md5.c
@@ -86,14 +86,14 @@ static const uint32_t T[64] = { // T[i]= fabs(sin(i+1)<<32)
 \
 if (i < 32) {   \
 if (i < 16) \
-a += (d ^ (b & (c ^ d)))  + X[   i  & 15];  \
+a += (d ^ (b & (c ^ d)))  + AV_RL32(X+(   i  & 15));\
 else\
-a += ((d & b) | (~d & c)) + X[(1 + 5*i) & 15];  \
+a += ((d & b) | (~d & c)) + AV_RL32(X+((1 + 5*i) & 15));\
 } else {\
 if (i < 48) \
-a += (b ^ c ^ d)  + X[(5 + 3*i) & 15];  \
+a += (b ^ c ^ d)  + AV_RL32(X+((5 + 3*i) & 15));\
 else\
-a += (c ^ (b | ~d))   + X[(7*i) & 15];  \
+a += (c ^ (b | ~d))   + AV_RL32(X+((7*i) & 15));\
 }   \
 a = b + (a << t | a >> (32 - t));   \
 } while (0)
@@ -112,11 +112,6 @@ static void body(uint32_t ABCD[4], uint32_t *src, int 
nblocks)
 
 X = src + n * 16;
 
-#if HAVE_BIGENDIAN
-for (i = 0; i < 16; i++)
-X[i] = av_bswap32(X[i]);
-#endif
-
 #if CONFIG_SMALL
 for (i = 0; i < 64; i++) {
 CORE(i, a, b, c, d);
@@ -173,7 +168,7 @@ void av_md5_update(AVMD5 *ctx, const uint8_t *src, int len)
 }
 
 end = src + (len & ~63);
-if (HAVE_BIGENDIAN || (!HAVE_FAST_UNALIGNED && ((intptr_t)src & 3))) {
+if (!HAVE_FAST_UNALIGNED && ((intptr_t)src & 3)) {
while (src < end) {
memcpy(ctx->block, src, 64);
body(ctx->ABCD, (uint32_t *) ctx->block, 1);
-- 
2.12.0

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

[FFmpeg-devel] [PATCH 2/3] avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13

2017-03-02 Thread Michael Niedermayer

Fixes: 709/clusterfuzz-testcase-4789836449841152

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

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index d44ddb20fa..27db14c35e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -497,7 +497,7 @@ static inline int mpeg2_decode_block_intra(MpegEncContext 
*s,
 dc  = s->last_dc[component];
 dc += diff;
 s->last_dc[component] = dc;
-block[0] = dc << (3 - s->intra_dc_precision);
+block[0] = dc * (1 << (3 - s->intra_dc_precision));
 ff_tlog(s->avctx, "dc=%d\n", block[0]);
 mismatch = block[0] ^ 1;
 i = 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/adxdec: Fix runtime error: left shift of negative value -1

2017-03-02 Thread Michael Niedermayer

Fixes: 705/clusterfuzz-testcase-5129572590813184

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

diff --git a/libavcodec/adxdec.c b/libavcodec/adxdec.c
index 32cc0f005a..178ea99dcf 100644
--- a/libavcodec/adxdec.c
+++ b/libavcodec/adxdec.c
@@ -81,7 +81,7 @@ static int adx_decode(ADXContext *c, int16_t *out, int offset,
 s2 = prev->s2;
 for (i = 0; i < BLOCK_SAMPLES; i++) {
 d  = get_sbits(, 4);
-s0 = ((d << COEFF_BITS) * scale + c->coeff[0] * s1 + c->coeff[1] * s2) 
>> COEFF_BITS;
+s0 = ((d * (1 << COEFF_BITS)) * scale + c->coeff[0] * s1 + c->coeff[1] 
* s2) >> COEFF_BITS;
 s2 = s1;
 s1 = av_clip_int16(s0);
 *out++ = s1;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 3/3] avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value

2017-03-02 Thread Michael Niedermayer

Fixes: 710/clusterfuzz-testcase-5091051431788544

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

diff --git a/libavcodec/h264_mvpred.h b/libavcodec/h264_mvpred.h
index 24f250d794..339cf623d5 100644
--- a/libavcodec/h264_mvpred.h
+++ b/libavcodec/h264_mvpred.h
@@ -248,7 +248,7 @@ static av_always_inline void pred_8x16_motion(const 
H264Context *const h,
 if (IS_INTERLACED(type)) {  \
 refn >>= 1; \
 AV_COPY32(mvbuf[idx], mvn); \
-mvbuf[idx][1] <<= 1;\
+mvbuf[idx][1] *= 2; \
 mvn = mvbuf[idx];   \
 }   \
 }   \
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-02 Thread Wang Bin

It's macOS only. For iOS, we can use kCVPixelBufferOpenGLESCompatibilityKey
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] HEVC Video Transcode Transfer VUI, SEI Information

2017-03-02 Thread Ben Chang

Hi,

I posted a query regarding HDR transcode on the user forum a few weeks earlier 
and did not get a very clear answer; re-posting here in devel to see if I can 
gain more insight (sorry about duplication).

>I was wondering if ffmpeg supports transfer of VUI and SEI info between an 
>original bitstream and re-encoded bitstream (in a transcode scenario).
>I have been digging through the documentation; the closest I can find is using 
>-f metadata and -map_metadata but these don't seem to include the params I 
>need.
>This is specific to HDR bitstream transcode where I want to maintain 
>information such as color_description_present_flag, colour_primaries, 
>transfer_characteristics, etc.

In short, is there any way to transfer meta data between a decode and encode 
context in transcode scenario? If not, would it be supported in foreseeable 
future?

Thanks,
Ben



---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

2017-03-02 Thread Jun Zhao

V2: Fix the potential memory leak.2
From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 3 Mar 2017 09:25:53 +0800
Subject: [PATCH] vf_hwupload: Add missing return value check

Add missing return value checks and fix the potential memory leak.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_hwupload.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
index 08af2dd..4b63a2a 100644
--- a/libavfilter/vf_hwupload.c
+++ b/libavfilter/vf_hwupload.c
@@ -74,22 +74,28 @@ static int hwupload_query_formats(AVFilterContext *avctx)
 if (input_pix_fmts) {
 for (i = 0; input_pix_fmts[i] != AV_PIX_FMT_NONE; i++) {
 err = ff_add_format(_formats, input_pix_fmts[i]);
-if (err < 0) {
-ff_formats_unref(_formats);
+if (err < 0)
 goto fail;
-}
 }
 }
 
-ff_formats_ref(input_formats, >inputs[0]->out_formats);
+if ((err = ff_formats_ref(input_formats, >inputs[0]->out_formats)) 
< 0)
+goto fail;
 
-ff_formats_ref(ff_make_format_list(output_pix_fmts),
-   >outputs[0]->in_formats);
+if ((err = ff_formats_ref(ff_make_format_list(output_pix_fmts),
+  >outputs[0]->in_formats)) < 0) {
+ff_formats_unref(_formats);
+goto fail;
+}
 
 av_hwframe_constraints_free();
 return 0;
 
 fail:
+if (input_formats) {
+av_free(input_formats->formats);
+av_free(input_formats);
+}
 av_buffer_unref(>hwdevice_ref);
 av_hwframe_constraints_free();
 return err;
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] vf_hwupload: Add missing return value check

2017-03-02 Thread Jun Zhao



On 2017/3/1 5:44, Mark Thompson wrote:
> On 27/02/17 02:23, Jun Zhao wrote:
>> From e60a958c78ba084e0745acebec5125394387c5b1 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Mon, 27 Feb 2017 10:08:36 +0800
>> Subject: [PATCH] vf_hwupload: Add missing return value checks
>>
>> Add missing return value checks to fix the build warning.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vf_hwupload.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
>> index 08af2dd..ce39307 100644
>> --- a/libavfilter/vf_hwupload.c
>> +++ b/libavfilter/vf_hwupload.c
>> @@ -81,10 +81,12 @@ static int hwupload_query_formats(AVFilterContext *avctx)
>>  }
>>  }
>>  
>> -ff_formats_ref(input_formats, >inputs[0]->out_formats);
>> -
>> -ff_formats_ref(ff_make_format_list(output_pix_fmts),
>> -   >outputs[0]->in_formats);
>> +if ((err = ff_formats_ref(input_formats, 
>> >inputs[0]->out_formats)) < 0 ||
>> +(err = ff_formats_ref(ff_make_format_list(output_pix_fmts),
>> +  >outputs[0]->in_formats)) < 0) {
>> +ff_formats_unref(_formats);
> 
> This line doesn't do anything.
> 
>> +goto fail;
>> +}
>>  
>>  av_hwframe_constraints_free();
>>  return 0;
>> -- 
>> 2.9.3
>>
> 
> Are you trying to fix any possible leaks or just to suppress the warning?  If 
> the latter, sure.  If the former, please be aware if you aren't already that 
> the format functions are more subtle that they may appear to be - in 
> particular, note that ff_make_format_list() creates a format list with zero 
> references, and therefore calling unref on such a list does nothing.  (And 
> yes, the use of ff_formats_unref() in the loop above is also wrong, you may 
> want to fix that as well.)
> _

I just want to suppress the warning and didn't aware of calling unref is wrong, 
will submit V2 patch for this. Thanks.
__
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 11:43:15PM +0100, Carl Eugen Hoyos wrote:
> 2017-03-01 13:07 GMT+01:00 Michael Niedermayer :
> > On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
> >> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
> >> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
> >> >> Hi!
> >> >>
> >> >> Attached patch fixes ticket #6206 here.
> >> >>
> >> >> Please comment, Carl Eugen
> >> >
> >> > previous ffmpeg versions dont play these files
> >>
> >> What do you suggest?
> >
> > support this at the demuxer side, backport such support then
> > wait till its supported widely before switching the default in the
> > muxer
> 
> Agree, new patch attached.
> 
> Thank you, Carl Eugen

>  matroska.c|1 +
>  matroskaenc.c |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> f1f3a3f2c331db2bc7c9ccf2c9d9fad42b3c9467  
> 0001-lavf-matroska-Support-codec-ID-V_FFV1-for-demuxing.patch
> From 5b50e8409463b746e38b35f7ca82c6b54b3be9ee Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 1 Mar 2017 23:40:35 +0100
> Subject: [PATCH] lavf/matroska: Support codec ID V_FFV1 for demuxing.
> 
> Fixes ticket #6206.
> ---
>  libavformat/matroska.c|1 +
>  libavformat/matroskaenc.c |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)

should be ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 04:43:27PM -0500, Dave Rice wrote:
> 
> > On Mar 2, 2017, at 9:59 AM, James Almer  wrote:
> > 
> > On 3/2/2017 11:47 AM, Tobias Rapp wrote:
> >> On 02.03.2017 15:22, James Almer wrote:
> >>> On 3/2/2017 6:28 AM, Nicolas George wrote:
>  Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
> > Ah, i see there's generic code to read and write CodecPrivate elements
> > to and from raw extradata for native codecids where no special handling
> > is required.
> > 
> > In any case, the spec says
> > 
> > "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
> > 
> > The ffv1 encoder creates extradata for v2 and newer, so the muxer
> > should have a custom case for ffv1 in order to detect v2 streams and
> > avoid writing said extradata.
>  
>  I have not looked myself at the situation, I only read what you wrote
>  her. According to it, it seems here the FFV1 encoder is violating the
>  specification and needs to be fixed.
> >>> 
> >>> I can't say if the encoder exporting extradata for version 2 is right or
> >>> wrong, as muxers or bsfs could still use it for whatever reason, but at
> >>> least according to the draft ffv1 spec by Michael, it's to be stored at
> >>> the container level *only* on versions 3 and above.
> >>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1
> >> 
> >> The IETF draft explicitly excludes to specify FFV1 version 2:
> >> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1
> >> 
> >> IIRC there have been some edits to remove references to version 2 in the 
> >> IETF draft. In the older document at 
> >> http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the 
> >> section contains "version >= 2".
> >> 
> >> Regards,
> >> Tobias
> > 
> > Well, that makes things a bit more complex.
> > Maybe the Matroska spec should follow and also avoid mentioning v2?
> > That way we could just pretend those files don't exist and not bother
> > trying to drop their extradata during muxing.
> 
> I agree. In the FFV1 spec, it is careful to say that it intentionally does 
> not describe FFV1 version 2. I will submit a patch to the Matroska 
> specification to avoid using relative language based on version 2.

agree too and thx

also anyone wanting to know about version 2, the best reference is
probably what the source does 

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

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


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: move the segment files handle close before temp flags process

2017-03-02 Thread Steven Liu

2017-03-01 10:23 GMT+08:00 Steven Liu :

> fix ticket: #6204
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 9cf6211..b8122f1 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1329,13 +1329,14 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  new_start_pos = avio_tell(hls->avf->pb);
>  hls->size = new_start_pos - hls->start_pos;
>
> +ff_format_io_close(s, >pb);
> +if (hls->vtt_avf) {
> +ff_format_io_close(s, >vtt_avf->pb);
> +}
>  if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
>  if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <=
> 0))
>  if (hls->avf->oformat->priv_class && hls->avf->priv_data)
>  av_opt_set(hls->avf->priv_data, "mpegts_flags",
> "resend_headers", 0);
> -ff_format_io_close(s, >pb);
> -if (hls->vtt_avf)
> -ff_format_io_close(s, >vtt_avf->pb);
>  hls_rename_temp_file(s, oc);
>  }
>
> --
> 2.10.1 (Apple Git-78)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

will push after 24 hours
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] unsubscribe

2017-03-02 Thread Christo Grozev

unsubscribe

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Michael Niedermayer
Sent: Friday, March 3, 2017 12:02 AM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate
as a hint to the encoder

On Thu, Mar 02, 2017 at 03:35:08PM +0100, Tobias Rapp wrote:
> On 02.03.2017 03:27, Michael Niedermayer wrote:
> >On Mon, Feb 27, 2017 at 09:50:31AM +0100, Tobias Rapp wrote:
> >>On 26.02.2017 16:09, Michael Niedermayer wrote:
> >>>On Mon, Feb 20, 2017 at 04:05:00PM +0100, Tobias Rapp wrote:
> On 20.02.2017 15:09, Mark Thompson wrote:
> >On 06/02/17 12:33, Tobias Rapp wrote:
> >>Sets framerate field in output codec context if explicitly 
> >>specified on the command-line.
> >>
> >>Signed-off-by: Tobias Rapp 
> >>---
> >>ffmpeg_opt.c | 2 ++
> >>1 file changed, 2 insertions(+)
> >>
> >>diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c index 6a47d32..3b532da 
> >>100644
> >>--- a/ffmpeg_opt.c
> >>+++ b/ffmpeg_opt.c
> >>@@ -1535,6 +1535,8 @@ static OutputStream
*new_video_stream(OptionsContext *o, AVFormatContext *oc, in
> >>   av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n",
frame_rate);
> >>   exit_program(1);
> >>   }
> >>+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
> >>+video_enc->framerate = ost->frame_rate;
> >>   if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
> >>   av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can 
> >> produce invalid output files\n");
> >>
> >>
> >
> >Is there a reason not to always set this, rather than only when it is
specified explicitly on the command line as you have?
> >
> >(Like 
> > >84f58e0cd12be284b982f6>, though that is after the current merge 
> >point and I don't know if it interacts with anything else.)
> 
> I just tried to be extra cautious. Merging Libav commit
> d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more 
> general solution and might be preferred.
> >>>
> >>>that one would change fate results, are the changed results better 
> >>>or worse ?
> >>
> >>I rebased unto current master and run fate with the attached change 
> >>to ffmpeg.c applied but couldn't find any changed reference files.
> >>
> >
> >>Which fate tests had some changes and which platform did you check?
> >
> >there was a commit in origin/master that broke the tests, i realized 
> >that after sending the mail but was too busy to reply immedeaty and 
> >then forgot
> 
> No problem. So I consider my original patch 1/3 as dropped.
> 

> What is the best way to continue, assuming that the other two patches 
> in the series are OK?

> 
> Shall I merge the single Libav commit d10102d2 followed by the other 
> two patches? Or shall I wait until the general Libav merge-queue up to 
> d10102d2 has been processed (~210 commits)? Or just wait for the 
> merges affecting ffmpeg.c (~4 commits)?

waiting is generally bad for paralellism if you need a patch, cherry pick it


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

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

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 03:35:08PM +0100, Tobias Rapp wrote:
> On 02.03.2017 03:27, Michael Niedermayer wrote:
> >On Mon, Feb 27, 2017 at 09:50:31AM +0100, Tobias Rapp wrote:
> >>On 26.02.2017 16:09, Michael Niedermayer wrote:
> >>>On Mon, Feb 20, 2017 at 04:05:00PM +0100, Tobias Rapp wrote:
> On 20.02.2017 15:09, Mark Thompson wrote:
> >On 06/02/17 12:33, Tobias Rapp wrote:
> >>Sets framerate field in output codec context if explicitly specified on
> >>the command-line.
> >>
> >>Signed-off-by: Tobias Rapp 
> >>---
> >>ffmpeg_opt.c | 2 ++
> >>1 file changed, 2 insertions(+)
> >>
> >>diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> >>index 6a47d32..3b532da 100644
> >>--- a/ffmpeg_opt.c
> >>+++ b/ffmpeg_opt.c
> >>@@ -1535,6 +1535,8 @@ static OutputStream 
> >>*new_video_stream(OptionsContext *o, AVFormatContext *oc, in
> >>   av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", 
> >> frame_rate);
> >>   exit_program(1);
> >>   }
> >>+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
> >>+video_enc->framerate = ost->frame_rate;
> >>   if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
> >>   av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce 
> >> invalid output files\n");
> >>
> >>
> >
> >Is there a reason not to always set this, rather than only when it is 
> >specified explicitly on the command line as you have?
> >
> >(Like 
> >,
> > though that is after the current merge point and I don't know if it 
> >interacts with anything else.)
> 
> I just tried to be extra cautious. Merging Libav commit
> d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more
> general solution and might be preferred.
> >>>
> >>>that one would change fate results, are the changed results better or
> >>>worse ?
> >>
> >>I rebased unto current master and run fate with the attached change
> >>to ffmpeg.c applied but couldn't find any changed reference files.
> >>
> >
> >>Which fate tests had some changes and which platform did you check?
> >
> >there was a commit in origin/master that broke the tests, i realized
> >that after sending the mail but was too busy to reply immedeaty and
> >then forgot
> 
> No problem. So I consider my original patch 1/3 as dropped.
> 

> What is the best way to continue, assuming that the other two
> patches in the series are OK?

> 
> Shall I merge the single Libav commit d10102d2 followed by the other
> two patches? Or shall I wait until the general Libav merge-queue up
> to d10102d2 has been processed (~210 commits)? Or just wait for the
> merges affecting ffmpeg.c (~4 commits)?

waiting is generally bad for paralellism
if you need a patch, cherry pick it


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: update bitrates on dash_write_trailer

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 11:48:47PM +0100, Przemysław Sobala wrote:
> 23 lut 2017 21:39 "Przemysław Sobala" 
> napisał(a):
> 
> On Wednesday, February 22, 2017, Przemysław Sobala <
> przemyslaw.sob...@gmail.com> wrote:
> 
> > From: Przemysław Sobala 
> >
> > Provides a way to change bandwidth (bitrate) parameter after CRF H.264
> > encoding (details: http://ffmpeg.org/pipermail/li
> > bav-user/2017-February/010141.html)
> >
> > Signed-off-by: Przemysław Sobala 
> > ---
> >  libavformat/dashenc.c | 42 ++
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index fa56505..011d2ea 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -561,6 +561,30 @@ static int write_manifest(AVFormatContext *s, int
> > final)
> >  return 0;
> >  }
> >
> > +static int set_bitrate(AVFormatContext *s)
> > +{
> > +DASHContext *c = s->priv_data;
> > +int i;
> > +
> > +for (i = 0; i < s->nb_streams; i++) {
> > +OutputStream *os = >streams[i];
> > +
> > +os->bit_rate = s->streams[i]->codecpar->bit_rate;
> > +if (os->bit_rate) {
> > +snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
> > + " bandwidth=\"%d\"", os->bit_rate);
> > +} else {
> > +int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
> > +AV_LOG_ERROR : AV_LOG_WARNING;
> > +av_log(s, level, "No bit rate set for stream %d\n", i);
> > +if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
> > +return AVERROR(EINVAL);
> > +}
> > +}
> > +
> > +return 0;
> > +}
> > +
> >  static int dash_init(AVFormatContext *s)
> >  {
> >  DASHContext *c = s->priv_data;
> > @@ -597,6 +621,10 @@ static int dash_init(AVFormatContext *s)
> >  if (!c->streams)
> >  return AVERROR(ENOMEM);
> >
> > +ret = set_bitrate(s);
> > +if (ret < 0)
> > +return ret;
> > +
> >  for (i = 0; i < s->nb_streams; i++) {
> >  OutputStream *os = >streams[i];
> >  AVFormatContext *ctx;
> > @@ -604,18 +632,6 @@ static int dash_init(AVFormatContext *s)
> >  AVDictionary *opts = NULL;
> >  char filename[1024];
> >
> > -os->bit_rate = s->streams[i]->codecpar->bit_rate;
> > -if (os->bit_rate) {
> > -snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
> > - " bandwidth=\"%d\"", os->bit_rate);
> > -} else {
> > -int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
> > -AV_LOG_ERROR : AV_LOG_WARNING;
> > -av_log(s, level, "No bit rate set for stream %d\n", i);
> > -if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
> > -return AVERROR(EINVAL);
> > -}
> > -
> >  ctx = avformat_alloc_context();
> >  if (!ctx)
> >  return AVERROR(ENOMEM);
> > @@ -981,6 +997,8 @@ static int dash_write_trailer(AVFormatContext *s)
> >  {
> >  DASHContext *c = s->priv_data;
> >
> > +set_bitrate(s);
> > +
> >  if (s->nb_streams > 0) {
> >  OutputStream *os = >streams[0];
> >  // If no segments have been written so far, try to do a crude
> > --
> > 2.7.4
> >
> >
> Any comment on this?

please describe what this does in the commit message instead of
linking to some mail, i had no idea before i opened it in my browser

but the link might not be eternally valid, these mailman numbers
for example can get messed up, it should not happen but 
URLs are always risky

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 10:35:21AM +0100, wm4 wrote:
> On Fri, 17 Feb 2017 21:15:56 +0100
> Michael Niedermayer  wrote:
> 
> > On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:
> > > On Thu, 16 Feb 2017 10:29:36 -0800
> > > Aman Gupta  wrote:
> > >   
> > > > From: Aman Gupta 
> > > > 
> > > > This fixes playback of h264 streams with SPS changes. One such sample
> > > > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> > > > It switches mid-stream from level 4.0 to level 3.2.
> > > > 
> > > > Previously, playing this sample with the VT hwaccel on iOS would crash.
> > > > After this patch, it plays back as expected.
> > > > 
> > > > On macOS however, feeding in new SPS into an existing decompression
> > > > session does not always work, so this patch is only a partial fix.
> > > > ---
> > > >  libavcodec/h264dec.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > > > index 41c0964..e521c52 100644
> > > > --- a/libavcodec/h264dec.c
> > > > +++ b/libavcodec/h264dec.c
> > > > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > > >  break;
> > > >  case H264_NAL_SPS: {
> > > >  GetBitContext tmp_gb = nal->gb;
> > > > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> > > > AV_PIX_FMT_VIDEOTOOLBOX) {
> > > > +ret = avctx->hwaccel->decode_slice(avctx,
> > > > +   nal->data,
> > > > +   nal->size);
> > > > +if (ret < 0)
> > > > +goto end;
> > > > +}
> > > >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, 
> > > > >ps, 0) >= 0)
> > > >  break;
> > > >  av_log(h->avctx, AV_LOG_DEBUG,  
> > > 
> > > A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
> > > callback here, even if it's used by VT only.
> > > 
> > > You should probably wait for approval by michaelni.  
> > 
> > i dont really have an oppinion on hwaccel, thats not so much my
> > area
> > though i find special cases for specific hwaccel a bit ugly, i dont
> > object to it, just saying i would be in favor of not having special
> > cases if that is possible
> 
> So do you think this is tolerable in the current state or not?

i leave this entirely to the people working on hwaccel. i dont
object to it nor to a alternative


-- 
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

Re: [FFmpeg-devel] [PATCH] Revert "avutil/frame: Disallow zero sized frame side data"

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 01:02:11PM +0100, Michael Niedermayer wrote:
> Found a case where we use size==0, the other related commits
> remain needed, and should be sufficient to fix the original issue
> 
> This reverts commit 7e4f32f4e4b93c95dcc872cb844c5548e69f352e.
> ---
>  libavutil/frame.c | 2 --
>  1 file changed, 2 deletions(-)

applied

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/interplayvideo: Fix timeout from lack of bitstream end check

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 06:31:25PM +0100, Michael Niedermayer wrote:
> Fixes: 697/clusterfuzz-testcase-6111250582863872
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/interplayvideo.c | 2 ++
>  1 file changed, 2 insertions(+)

applied

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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/3] avcodec/mpegaudiodec_template: Fix runtime error: signed integer overflow: 2053224902 + 2053224902 cannot be represented in type 'int'

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 06:31:24PM +0100, Michael Niedermayer wrote:
> Fixes: 696/clusterfuzz-testcase-5853632270434304
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegaudiodec_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mjpegdec: Fix runtime error: left shift of negative value -511

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 06:31:23PM +0100, Michael Niedermayer wrote:
> Fixes: 693/clusterfuzz-testcase-6109776066904064
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mjpegdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread Kagami Hiiragi

On 03/03/17 01:16, Moritz Barsnick wrote:
> On Thu, Mar 02, 2017 at 22:00:36 +0300, Kagami Hiiragi wrote:
>> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), 
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
>^
> Woudn't a _BOOL type accept exactly the same ranges and defaults, with
> the same behavior, but document itself more nicely?
> 
> It would result in
>  -row-mt  E... Row based multi-threading (default auto)
> instead of
>  -row-mt  E... Row based multi-threading (from -1 to 1) 
> (default -1)
> 
> (Guessing, untested.)
> 
> Moritz

I copied description of "lossless" flag, but "frame-parallel" and other
encoders seems to prefer BOOL, you are right.

I'm leaving it up to commiter, it's just s/_INT/_BOOL/.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread Moritz Barsnick

On Thu, Mar 02, 2017 at 22:00:36 +0300, Kagami Hiiragi wrote:
> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_INT, 
> {.i64 = -1}, -1, 1, VE},
   ^
Woudn't a _BOOL type accept exactly the same ranges and defaults, with
the same behavior, but document itself more nicely?

It would result in
 -row-mt  E... Row based multi-threading (default auto)
instead of
 -row-mt  E... Row based multi-threading (from -1 to 1) 
(default -1)

(Guessing, untested.)

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

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Identify sub-stream ID 0xa1 as mlp

2017-03-02 Thread Hendrik Leppkes

On Wed, Mar 9, 2016 at 2:14 PM, Carl Eugen Hoyos  wrote:
> Michael Niedermayer  niedermayer.cc> writes:
>
>> >  mpeg.c |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 441c00cda76c5f59b560517115ad1677ab8061bd  patchmpegmlp.diff
>> > diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
>> > index 787d5f0..2f48459 100644
>>
>> if that works and no better way is known then it should be ok
>
> Patch applied.
>

A user shared a private sample with me that uses 0xa1 for a lpcm
stream, which gets mis-detected as mlp now.
It appears this would not be quite the final solution. AOB may use
different mappings then ordinary VOB/MPEG files, is there no way to
differentiate the different kinds?

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Dave Rice


> On Mar 2, 2017, at 9:59 AM, James Almer  wrote:
> 
> On 3/2/2017 11:47 AM, Tobias Rapp wrote:
>> On 02.03.2017 15:22, James Almer wrote:
>>> On 3/2/2017 6:28 AM, Nicolas George wrote:
 Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
> Ah, i see there's generic code to read and write CodecPrivate elements
> to and from raw extradata for native codecids where no special handling
> is required.
> 
> In any case, the spec says
> 
> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
> 
> The ffv1 encoder creates extradata for v2 and newer, so the muxer
> should have a custom case for ffv1 in order to detect v2 streams and
> avoid writing said extradata.
 
 I have not looked myself at the situation, I only read what you wrote
 her. According to it, it seems here the FFV1 encoder is violating the
 specification and needs to be fixed.
>>> 
>>> I can't say if the encoder exporting extradata for version 2 is right or
>>> wrong, as muxers or bsfs could still use it for whatever reason, but at
>>> least according to the draft ffv1 spec by Michael, it's to be stored at
>>> the container level *only* on versions 3 and above.
>>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1
>> 
>> The IETF draft explicitly excludes to specify FFV1 version 2:
>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1
>> 
>> IIRC there have been some edits to remove references to version 2 in the 
>> IETF draft. In the older document at 
>> http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the section 
>> contains "version >= 2".
>> 
>> Regards,
>> Tobias
> 
> Well, that makes things a bit more complex.
> Maybe the Matroska spec should follow and also avoid mentioning v2?
> That way we could just pretend those files don't exist and not bother
> trying to drop their extradata during muxing.

I agree. In the FFV1 spec, it is careful to say that it intentionally does not 
describe FFV1 version 2. I will submit a patch to the Matroska specification to 
avoid using relative language based on version 2.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread James Almer

On 3/2/2017 2:27 PM, wm4 wrote:
> Well, you already announced that you'd leave the project a few months
> ago or so, but nothing happened. As an (apparently involuntary) de-facto
> project leader who refuses to fix the leadership associated problems of
> the project, it's of course not strange that you get attacked once in a
> while. Even if you deny being a project leader, you hold a tad too many
> central key positions.
> 
> I realize you probably just want to write code and not deal with these
> issues. But on the other hand it seems you're stuck in this position
> whether or not you or we want it. The best idea I can come up is to
> nominate a new project leader, but I don't know who could do that _and_
> keep the project together.

Big project decisions pass through the voting committee now. Is it flawed
and too crowded? yes, but it's better than total anarchy.

Nothing Michael's doing in this thread by reviewing your patchset is even
remotely related to being a project leader. His emails and regression
reports could have come from anyone else and have the same effect on this
patchset.

I understand your frustration, as i also had to go through several
iterations of a big merge like this one after Michael pointed out some
regressions, including identifying some false positives like the timebase
change he reported earlier today, but it doesn't justify lashing out at
people who are simply pointing out issues.

> 
> Currently, we as a project can't make decisions, and nobody even knows
> the damn rules we're supposed to play by. If it's just me, could
> someone please set me straight?

This is not true, we have had several votes by now with different results.
API decisions, deprecation/removal decisions, etc.
I liked some, i hated others, but respected all of them. Everyone did.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 06:27:29PM +0100, wm4 wrote:
> On Thu, 2 Mar 2017 17:12:04 +0100
> Michael Niedermayer  wrote:
> 
> > On Thu, Mar 02, 2017 at 02:37:09PM +0100, wm4 wrote:
> > > On Thu, 2 Mar 2017 14:03:18 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:  
> > > > > These patches merge the previously skipped Libav commits, which made
> > > > > avconv lazily initialize libavfilter graphs. This means the filters
> > > > > are initialized with the actual output format, instead of whatever
> > > > > libavformat reports.
> > > > > 
> > > > > It's a prerequisite to making hardware decoding support saner, as
> > > > > hardware decoders will output a different pixfmt than the software
> > > > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > > > half of the code is removed.
> > > > > 
> > > > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > > > changes were required.
> > > > > 
> > > > > I will push this tomorrow, except if critical failures are found.
> > > > 
> > > > I think the patchset improved in terms of regressions but there are
> > > > still several
> > > >   
> > [...]
> > >  
> > > > 
> > > > also this code crashes with some private files:
> > > > ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> > > > ==7506==  Access not within mapped region at address 0x8
> > > > ==7506==at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> > > > ==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> > > > ==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> > > > ==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> > > > ==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
> > > > ==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
> > > > ==7506==by 0x43B2FD: main (ffmpeg.c:4701)  
> > > 
> > > I don't know if you're shitting me on purpose. I can't fix what I can't
> > > reproduce, and you never gave me access to those files. Fix it yourself
> > > if you think it's important. Seriously, what is this.  
> > 
> > I ofered access to this file to someone wanting to work on this
> > previously
> > "If this backtrace is not sufficient i can share the file privatly
> >  with someone who wants to work on fixing this"
> > 
> > Noone asked for the file, if you want to work on this and keep the file
> > private, i can share it with you.
> > 
> > Its not nice from you to ignore my ofer and then attack me pretending
> > there was no such offer
> 
> OK, I missed that part. Sorry. I guess I overlooked it when I tried to
> collect all the new test cases and tried to find the required samples
> (for which you only provided a path on your local disk, and I had to
> look them up from the ticker number in that path). So I apologize, but
> I'm still grumpy.
> 
> Anyway, _please_ don't report bugs to me in the future without providing
> a direct sample link (sure, you can do it privately if necessary).
> 

> In the mean time, I somehow expected you'd provide me a sample for the
> case above (in private), since you know that I obviously want and don't
> have it, but you didn't yet. Why make me ask.

because i have no permission to share the file unless its neccessary.


> 
> Btw., I've tested every single case you pointed out and which I could
> test.

you missed one case it seems
./ffmpeg -skip_frame nokey -ss 20  -i ~/tickets/2024/dvbsubtest.ts -qscale 2  
-scodec dvbsub -t 6   -an file.ts

displays fewer subtitles than before the patchset, i did report this
case previously


> 
> > 
> > >   
> > > > This one produces a silent audio channel as previous patchsets did too
> > > > ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav  
> > > 
> > > While libavformat signals a mono channel configuration, the decoder
> > > actually outputs stereo, with one channel muted. You can reproduce this
> > > with current master ffmpeg too by adding "-ac 2". If this is a bug,
> > > then it's merely an old bug that is made more obvious by this patch,
> > > rather than introducing it.
> > > 
> > > I don't know why you could not determine this yourself. It would have
> > > been easy to check.  
> > 
> > Ive a huge amount of things to do, and analyzing differences is alot
> > of work, i stated that previously yet you keep attacking me, and i
> > tried to do some light analysis on some things to help a bit but could
> > not on all
> 
> This is not the first time you're implying that your time is somehow
> more valuable than mine.

iam not implying that.
what iam implying is that if a person or group wants something its
theirs to do the work. Thats especially true in FLOSS
you seem to expect me to also want to work on the same things you
want to work on.


> 
> Anyway, I realize

[FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-02 Thread Kagami Hiiragi

From ae3856c302284d60761c3ad122ff49b7b9b68114 Mon Sep 17 00:00:00 2001
From: Kagami Hiiragi 
Date: Thu, 2 Mar 2017 21:19:09 +0300
Subject: [PATCH] lavc/libvpxenc: add -row-mt option

---
 libavcodec/libvpxenc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index de0d0b6bcb..8eefda5b5b 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -108,6 +108,7 @@ typedef struct VPxEncoderContext {
 int noise_sensitivity;
 int vpx_cs;
 float level;
+int row_mt;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -139,6 +140,9 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
 [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+[VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
+#endif
 #endif
 };
 
@@ -720,6 +724,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 12
 codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+if (ctx->row_mt >= 0)
+codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
+#endif
 }
 #endif
 
@@ -1132,6 +1140,9 @@ static const AVOption vp9_options[] = {
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 13
+{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, 1, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };
-- 
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

2017-03-02 Thread Aman Gupta

On Thu, Mar 2, 2017 at 2:04 AM, wm4  wrote:

> On Thu, 2 Mar 2017 10:47:23 +0100
> Hendrik Leppkes  wrote:
>
> > On Thu, Mar 2, 2017 at 10:35 AM, wm4  wrote:
> > > On Fri, 17 Feb 2017 21:15:56 +0100
> > > Michael Niedermayer  wrote:
> > >
> > >> On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:
> > >> > On Thu, 16 Feb 2017 10:29:36 -0800
> > >> > Aman Gupta  wrote:
> > >> >
> > >> > > From: Aman Gupta 
> > >> > >
> > >> > > This fixes playback of h264 streams with SPS changes. One such
> sample
> > >> > > is available at http://tmm1.s3.amazonaws.com/
> videotoolbox/spschange.ts.
> > >> > > It switches mid-stream from level 4.0 to level 3.2.
> > >> > >
> > >> > > Previously, playing this sample with the VT hwaccel on iOS would
> crash.
> > >> > > After this patch, it plays back as expected.
> > >> > >
> > >> > > On macOS however, feeding in new SPS into an existing
> decompression
> > >> > > session does not always work, so this patch is only a partial fix.
> > >> > > ---
> > >> > >  libavcodec/h264dec.c | 7 +++
> > >> > >  1 file changed, 7 insertions(+)
> > >> > >
> > >> > > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > >> > > index 41c0964..e521c52 100644
> > >> > > --- a/libavcodec/h264dec.c
> > >> > > +++ b/libavcodec/h264dec.c
> > >> > > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >> > >  break;
> > >> > >  case H264_NAL_SPS: {
> > >> > >  GetBitContext tmp_gb = nal->gb;
> > >> > > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt ==
> AV_PIX_FMT_VIDEOTOOLBOX) {
> > >> > > +ret = avctx->hwaccel->decode_slice(avctx,
> > >> > > +   nal->data,
> > >> > > +   nal->size);
> > >> > > +if (ret < 0)
> > >> > > +goto end;
> > >> > > +}
> > >> > >  if (ff_h264_decode_seq_parameter_set(_gb,
> avctx, >ps, 0) >= 0)
> > >> > >  break;
> > >> > >  av_log(h->avctx, AV_LOG_DEBUG,
> > >> >
> > >> > A bit ugly but ok IMHO. Maybe it would be better to add a new
> hwaccel
> > >> > callback here, even if it's used by VT only.
> > >> >
> > >> > You should probably wait for approval by michaelni.
> > >>
> > >> i dont really have an oppinion on hwaccel, thats not so much my
> > >> area
> > >> though i find special cases for specific hwaccel a bit ugly, i dont
> > >> object to it, just saying i would be in favor of not having special
> > >> cases if that is possible
> > >
> > > So do you think this is tolerable in the current state or not?
> >
> > I agree with Michael, the number of VT-specific hacks seem to be
> > piling up. Maybe it should be re-designed entirely instead of piling
> > hacks on top of hacks to keep it barely working.
>
> Would that mean reimplementing it as a full-stream decoder?
>
> That's my favorite choice as well, but apparently the VT hwaccel
> wouldn't require much more changes to work reasonably well.
>

FWIW, after these patches the VT hwaccel has been working very reliably for
me across hundreds of test streams.

I agree that re-implementing as a decoder is the correct long term
solution, but the VT api presents several technical hurdles before that can
become a viable alternative.

For this particular patch, I think it would make sense to add a new hwaccel
callback that's only used by VT. If we can agree on a name I can work up a
patch. Maybe hwaccel->upload_nal() ?

Aman


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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

2017-03-02 Thread Aman Gupta

On Thu, Mar 2, 2017 at 1:34 AM, wm4  wrote:

> On Tue, 21 Feb 2017 13:40:08 -0800
> Aman Gupta  wrote:
>
> > On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje 
> > wrote:
> >
> > > Hi,
> > >
> > > On Tue, Feb 21, 2017 at 1:48 PM, Aman Gupta  wrote:
> > >
> > >> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > >> index 41c0964392..a0ae632fed 100644
> > >> --- a/libavcodec/h264dec.c
> > >> +++ b/libavcodec/h264dec.c
> > >> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame
> > >> *dst, H264Picture *srcp)
> > >>  AVFrame *src = srcp->f;
> > >>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->
> format);
> > >>  int i;
> > >> -int ret = av_frame_ref(dst, src);
> > >> +int ret;
> > >> +
> > >> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size
> == 1)
> > >> +return AVERROR_INVALIDDATA;
> > >> +
> > >> +ret = av_frame_ref(dst, src);
> > >>  if (ret < 0)
> > >>  return ret;
> > >
> > >
> > > This is a total hack :) Is there a way to hide this into VT-specific
> code
> > > outside h264*.[ch]?
> > >
> >
> > The way the VT hwaccel works is a total hack, as noted in my commit
> message.
> >
> > AFAICT, given how the hwaccel APIs work, there's no way to do this
> outside
> > the h264 decoder. But I'm happy to try fixing this a different way if
> > anyone has a suggestion.
>
> So, should we push this?
>

I'm struggling to find a less hacky way to implement this, so my vote would
be to move forward. Changing the error to AVERROR_EXTERNAL makes sense too.


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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 17:34:11 +0100
Carl Eugen Hoyos  wrote:

> 2017-03-01 13:31 GMT+01:00 wm4 :
> > On Wed, 1 Mar 2017 13:06:29 +0100
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-03-01 12:36 GMT+01:00 wm4 :  
> >> > On Wed, 1 Mar 2017 12:20:10 +0100
> >> > Carl Eugen Hoyos  wrote:
> >> >  
> >> >> 2017-02-25 15:59 GMT+01:00 wm4 :  
> >> >> > I'm documenting existing practice.  
> >> >>  
> >> >> > -@subheading Always wait long enough before pushing changes
> >> >> > +@subheading Always wait long enough before pushing changes
> >> >> > to code actively maintained by others  
> >> >>
> >> >> I suspect this is missing an exception for security issues if you want 
> >> >> to
> >> >> document the actual practice.  
> >> >
> >> > I can add to the end of the subheading:
> >> >
> >> >   Critical security issues are an exception. These can be pushed after
> >> >   the patch has been for 24 hours on the mailing list and the maintainer
> >> >   didn't respond yet, and nobody has rejected the patch. In addition,
> >> >   if another committer has approved the patch and acknowledged the
> >> >   urgency of the fix, the patch can be pushed immediately.  
> >>
> >> I will most likely not fix a (real) security issue, but above seems quite
> >> unpractical to me (and unreasonable for real security issues).  
> >
> > How is that impractical? What do you suggest?  
> 
> Posting security issues and wait for comments does not seem
> like a useful approach.
> 
> > I certainly hope you're not suggesting that security-sensitive changes
> > to code the patch author does not maintain can be pushed without reviews
> > at all.  
> 
> I believe this is the established practice that you want to
> document iiuc.
> 
> >> > Maybe a bit long, but should cover all bases.
> >> >  
> >> >> > +@subheading Pushing patches without sending them to the mailing list
> >> >> > +If you're the maintainer of a file, or the file is not actively 
> >> >> > maintained by
> >> >> > +anyone, or the file is not covered by the MAINTAINERS file, you can 
> >> >> > just push
> >> >> > +them without asking for permission, and without sending them to 
> >> >> > ffmpeg-devel.
> >> >> > +This right only applies to developers with git push access, of 
> >> >> > course.  
> >> >>  
> >> >> > +A maintainer is considered not active if he hasn't posted a mail to 
> >> >> > ffmpeg-devel
> >> >> > +for longer than 6 months, and hasn't pushed a patch in that time 
> >> >> > period himself.  
> >> >>
> >> >> Unfortunately, there are maintainers who are happy to review patches
> >> >> sent to improve their code but the files were not touched for more than
> >> >> six months so they did not seem active for more than six months.  
> >> >
> >> > So what is a reasonable method of determining whether a maintainer
> >> > is reachable?  
> >>
> >> I fear there is no strict definition, patches can always be reverted though
> >> if a maintainer requests that.
> >>
> >> I am just (slightly) against writing "after six months, you are no more a
> >> maintainer".  
> >
> > That's not what I wrote.  
> 
> But this is how the change of text can be interpreted.
> 
> > It merely means that if you have showed no sign of activity after 6
> > months, the timeout can be skipped.  
> 
> As said, this is not a sufficient sign for non-maintenance.
> 
> >> > The worst part is that not even "active" maintainers always respond,
> >> > even if you go a timeout.  
> >>
> >> Then you push after the timeout (if no delay was requested).  
> >
> > michaelni didn't wait when pushing his vp56.c patches (didn't even send
> > them to the mailing list), even though it was a mid-sized (i.e. not
> > small) change.  
> 
> The patch did not change API (which would require the patch
> sent to the mailing list) and vp56.c is not actively maintained, so
> I don't understand what you are trying to say.
> 
> > The maintainer of vp56.c is still reachable by mail, but
> > hasn't posted or contributed anything to ffmpeg in 3.5 years. michaelni
> > didn't wait for the timeout, which does not match with what you seem to
> > demand.  
> 
> No, you misunderstand:
> I am just pointing out that a pure time-out is not sufficient to
> decide on maintenance.
> 
> > Please explain what the rules of this project are.  
> 
> As you know, I disagree with several of the rules, and I have said so.
> You have - afaict - agreed to them and I still feel that you prefer not
> to obey. I have no idea what I can explain to you.
> 
> Generally, I honestly don't understand what you are trying to
> achieve with your emails.
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I give up.

Please write a patch to clarify the rules yourself.

Otherwise I'm going to assume that the rules are as fuzzy as they

Re: [FFmpeg-devel] [PATCH]lavc/sheervideo: Fix Y prediction for interlaced frames with alpha

2017-03-02 Thread Carl Eugen Hoyos

2017-03-02 11:09 GMT+01:00 Paul B Mahol :
> On 3/1/17, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6210 visually.
>>
>> Please review, Carl Eugen
>>
>
> lgtm

Patch applied.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 17:12:04 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 02, 2017 at 02:37:09PM +0100, wm4 wrote:
> > On Thu, 2 Mar 2017 14:03:18 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:  
> > > > These patches merge the previously skipped Libav commits, which made
> > > > avconv lazily initialize libavfilter graphs. This means the filters
> > > > are initialized with the actual output format, instead of whatever
> > > > libavformat reports.
> > > > 
> > > > It's a prerequisite to making hardware decoding support saner, as
> > > > hardware decoders will output a different pixfmt than the software
> > > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > > half of the code is removed.
> > > > 
> > > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > > changes were required.
> > > > 
> > > > I will push this tomorrow, except if critical failures are found.
> > > 
> > > I think the patchset improved in terms of regressions but there are
> > > still several
> > >   
> [...]
> >  
> > > 
> > > also this code crashes with some private files:
> > > ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> > > ==7506==  Access not within mapped region at address 0x8
> > > ==7506==at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> > > ==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> > > ==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> > > ==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> > > ==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
> > > ==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
> > > ==7506==by 0x43B2FD: main (ffmpeg.c:4701)  
> > 
> > I don't know if you're shitting me on purpose. I can't fix what I can't
> > reproduce, and you never gave me access to those files. Fix it yourself
> > if you think it's important. Seriously, what is this.  
> 
> I ofered access to this file to someone wanting to work on this
> previously
> "If this backtrace is not sufficient i can share the file privatly
>  with someone who wants to work on fixing this"
> 
> Noone asked for the file, if you want to work on this and keep the file
> private, i can share it with you.
> 
> Its not nice from you to ignore my ofer and then attack me pretending
> there was no such offer

OK, I missed that part. Sorry. I guess I overlooked it when I tried to
collect all the new test cases and tried to find the required samples
(for which you only provided a path on your local disk, and I had to
look them up from the ticker number in that path). So I apologize, but
I'm still grumpy.

Anyway, _please_ don't report bugs to me in the future without providing
a direct sample link (sure, you can do it privately if necessary).

In the mean time, I somehow expected you'd provide me a sample for the
case above (in private), since you know that I obviously want and don't
have it, but you didn't yet. Why make me ask.

Btw., I've tested every single case you pointed out and which I could
test.

> 
> >   
> > > This one produces a silent audio channel as previous patchsets did too
> > > ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav  
> > 
> > While libavformat signals a mono channel configuration, the decoder
> > actually outputs stereo, with one channel muted. You can reproduce this
> > with current master ffmpeg too by adding "-ac 2". If this is a bug,
> > then it's merely an old bug that is made more obvious by this patch,
> > rather than introducing it.
> > 
> > I don't know why you could not determine this yourself. It would have
> > been easy to check.  
> 
> Ive a huge amount of things to do, and analyzing differences is alot
> of work, i stated that previously yet you keep attacking me, and i
> tried to do some light analysis on some things to help a bit but could
> not on all

This is not the first time you're implying that your time is somehow
more valuable than mine.

Anyway, I realize I might have misinterpreted your efforts. If the
failing examples you point out don't need to be fixed and are not an
absolute requirement for the patches to get a passing mark, but are
only provided by you as some sort of "help", then that's totally fine
with me.

I have to say this might not have the effect you want.

For example, getting handed a failure case _after_ you're done with the
work is not helpful. And I'm talking about cases that could be
triggered long ago, not just with new changes in a new iteration of the
patch set. It's a bit like throwing out a new bucket of dirt after
you've just cleaned the street, just because the house obviously needs
to be clean too. It's terrible timing.

Also, even if your intention is only to point out potential problems,

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Carl Eugen Hoyos

2017-03-01 23:43 GMT+01:00 Carl Eugen Hoyos :
> 2017-03-01 13:07 GMT+01:00 Michael Niedermayer :
>> On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
>>> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
>>> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
>>> >> Hi!
>>> >>
>>> >> Attached patch fixes ticket #6206 here.
>>> >>
>>> >> Please comment, Carl Eugen
>>> >
>>> > previous ffmpeg versions dont play these files
>>>
>>> What do you suggest?
>>
>> support this at the demuxer side, backport such support then
>> wait till its supported widely before switching the default in the
>> muxer
>
> Agree, new patch attached.

Ping.

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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

2017-03-02 Thread Carl Eugen Hoyos

2017-03-01 13:31 GMT+01:00 wm4 :
> On Wed, 1 Mar 2017 13:06:29 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2017-03-01 12:36 GMT+01:00 wm4 :
>> > On Wed, 1 Mar 2017 12:20:10 +0100
>> > Carl Eugen Hoyos  wrote:
>> >
>> >> 2017-02-25 15:59 GMT+01:00 wm4 :
>> >> > I'm documenting existing practice.
>> >>
>> >> > -@subheading Always wait long enough before pushing changes
>> >> > +@subheading Always wait long enough before pushing changes
>> >> > to code actively maintained by others
>> >>
>> >> I suspect this is missing an exception for security issues if you want to
>> >> document the actual practice.
>> >
>> > I can add to the end of the subheading:
>> >
>> >   Critical security issues are an exception. These can be pushed after
>> >   the patch has been for 24 hours on the mailing list and the maintainer
>> >   didn't respond yet, and nobody has rejected the patch. In addition,
>> >   if another committer has approved the patch and acknowledged the
>> >   urgency of the fix, the patch can be pushed immediately.
>>
>> I will most likely not fix a (real) security issue, but above seems quite
>> unpractical to me (and unreasonable for real security issues).
>
> How is that impractical? What do you suggest?

Posting security issues and wait for comments does not seem
like a useful approach.

> I certainly hope you're not suggesting that security-sensitive changes
> to code the patch author does not maintain can be pushed without reviews
> at all.

I believe this is the established practice that you want to
document iiuc.

>> > Maybe a bit long, but should cover all bases.
>> >
>> >> > +@subheading Pushing patches without sending them to the mailing list
>> >> > +If you're the maintainer of a file, or the file is not actively 
>> >> > maintained by
>> >> > +anyone, or the file is not covered by the MAINTAINERS file, you can 
>> >> > just push
>> >> > +them without asking for permission, and without sending them to 
>> >> > ffmpeg-devel.
>> >> > +This right only applies to developers with git push access, of course.
>> >>
>> >> > +A maintainer is considered not active if he hasn't posted a mail to 
>> >> > ffmpeg-devel
>> >> > +for longer than 6 months, and hasn't pushed a patch in that time 
>> >> > period himself.
>> >>
>> >> Unfortunately, there are maintainers who are happy to review patches
>> >> sent to improve their code but the files were not touched for more than
>> >> six months so they did not seem active for more than six months.
>> >
>> > So what is a reasonable method of determining whether a maintainer
>> > is reachable?
>>
>> I fear there is no strict definition, patches can always be reverted though
>> if a maintainer requests that.
>>
>> I am just (slightly) against writing "after six months, you are no more a
>> maintainer".
>
> That's not what I wrote.

But this is how the change of text can be interpreted.

> It merely means that if you have showed no sign of activity after 6
> months, the timeout can be skipped.

As said, this is not a sufficient sign for non-maintenance.

>> > The worst part is that not even "active" maintainers always respond,
>> > even if you go a timeout.
>>
>> Then you push after the timeout (if no delay was requested).
>
> michaelni didn't wait when pushing his vp56.c patches (didn't even send
> them to the mailing list), even though it was a mid-sized (i.e. not
> small) change.

The patch did not change API (which would require the patch
sent to the mailing list) and vp56.c is not actively maintained, so
I don't understand what you are trying to say.

> The maintainer of vp56.c is still reachable by mail, but
> hasn't posted or contributed anything to ffmpeg in 3.5 years. michaelni
> didn't wait for the timeout, which does not match with what you seem to
> demand.

No, you misunderstand:
I am just pointing out that a pure time-out is not sufficient to
decide on maintenance.

> Please explain what the rules of this project are.

As you know, I disagree with several of the rules, and I have said so.
You have - afaict - agreed to them and I still feel that you prefer not
to obey. I have no idea what I can explain to you.

Generally, I honestly don't understand what you are trying to
achieve with your emails.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread Carl Eugen Hoyos

2017-03-02 16:03 GMT+01:00 wm4 :
> On Thu, 2 Mar 2017 14:03:18 +0100
> Michael Niedermayer  wrote:
>
>> This one looses the first displayed subtitle (the green "help")
>> ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
>> -qscale 2 -t 3 test.avi
>
> Attached patch fixes it. Will push it as part of the series tomorrow.

Please do not push the set before the crash is fixed.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 02:37:09PM +0100, wm4 wrote:
> On Thu, 2 Mar 2017 14:03:18 +0100
> Michael Niedermayer  wrote:
> 
> > On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:
> > > These patches merge the previously skipped Libav commits, which made
> > > avconv lazily initialize libavfilter graphs. This means the filters
> > > are initialized with the actual output format, instead of whatever
> > > libavformat reports.
> > > 
> > > It's a prerequisite to making hardware decoding support saner, as
> > > hardware decoders will output a different pixfmt than the software
> > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > half of the code is removed.
> > > 
> > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > changes were required.
> > > 
> > > I will push this tomorrow, except if critical failures are found.  
> > 
> > I think the patchset improved in terms of regressions but there are
> > still several
> > 
[...]
>
> > 
> > also this code crashes with some private files:
> > ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> > ==7506==  Access not within mapped region at address 0x8
> > ==7506==at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> > ==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> > ==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> > ==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> > ==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
> > ==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
> > ==7506==by 0x43B2FD: main (ffmpeg.c:4701)
> 
> I don't know if you're shitting me on purpose. I can't fix what I can't
> reproduce, and you never gave me access to those files. Fix it yourself
> if you think it's important. Seriously, what is this.

I ofered access to this file to someone wanting to work on this
previously
"If this backtrace is not sufficient i can share the file privatly
 with someone who wants to work on fixing this"

Noone asked for the file, if you want to work on this and keep the file
private, i can share it with you.

Its not nice from you to ignore my ofer and then attack me pretending
there was no such offer


> 
> > This one produces a silent audio channel as previous patchsets did too
> > ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav
> 
> While libavformat signals a mono channel configuration, the decoder
> actually outputs stereo, with one channel muted. You can reproduce this
> with current master ffmpeg too by adding "-ac 2". If this is a bug,
> then it's merely an old bug that is made more obvious by this patch,
> rather than introducing it.
> 
> I don't know why you could not determine this yourself. It would have
> been easy to check.

Ive a huge amount of things to do, and analyzing differences is alot
of work, i stated that previously yet you keep attacking me, and i
tried to do some light analysis on some things to help a bit but could
not on all



> 
> > 
> > This one looses the first displayed subtitle (the green "help")
> > ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
> > -qscale 2 -t 3 test.avi
> 
> The first time you mentioned this. Why didn't you do so a week ago?
> When I complained that you come up with a new case punctually at
> exactly the time when I want to merge the patches.

Well, either its new or i missed it previously.
you seem to assume i have a clean list of cases and withhold some,
thats not the case. There is no clean list to begin with and as you
asked me to spend time to investigate things a bit, i try to do so and
so i try to discard cases that appear to be duplicates
If iam wrong on one then theres a new case with the next patchset

Also id like to again ask for the attacks against me to stop.
I spend huge amounts of time in FFmpeg trying to
help but i get attacked on IRC and the ML. You realize that i just
reported some issues in a patchset ...
Its really strange, it feels like many people try really hard to push
me out of the project. And the really "hillarious" part is if i leave,
everyone of them will pretend its a surprise and they didnt see it
comming.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

[FFmpeg-devel] Using new decoder interface

2017-03-02 Thread Brett Tiplitz

I've tried to update my code from avcodec_decode_audio4 to the new
avcodec_send_packet.  I've got a block of data to decode, so this is not a
streaming design.

1.  When I pass a big block of data to the interface, the time required to
process the buffer goes from 1.5s to 30s.
2.  When I try and pass data to the system block by block, (or bunches of
blocks), the block size has to be a multiple of the underlying packet
size.  Otherwise, the decoder discards the incomplete packet.
3.  I also tried to detect when the buffer was getting low and add data to
the buffer, but it appears that this additional data was ignored.

I tried specifically the instructions on
https://blogs.gentoo.org/lu_zero/2016/03/29/new-avcodec-api/ but this
exhibits the same behavior, where an odd block size is discarded so I loose
the blocks using this exact approach unless the block size sent is a
multiple of the frame size.

I looks to be like the new method works well for streaming, but not so well
for non streaming decoding.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 14:03:18 +0100
Michael Niedermayer  wrote:

> This one looses the first displayed subtitle (the green "help")
> ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
> -qscale 2 -t 3 test.avi

Attached patch fixes it. Will push it as part of the series tomorrow.>From adb5854221bb55d34a225bea9c2c29c7bbbfe8c0 Mon Sep 17 00:00:00 2001
From: wm4 
Date: Thu, 2 Mar 2017 16:01:01 +0100
Subject: [PATCH] ffmpeg: delay processing of subtitles before filters are
 initialized

If a subtitle packet came before the first video frame could be fully
decoded, the subtitle packet would get discarded. This puts the subtitle
into a queue instead, and processes it once the attached filter graph is
initialized.
---
 ffmpeg.c| 22 +++---
 ffmpeg.h|  3 +++
 ffmpeg_filter.c | 13 +
 3 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 27bfc72cff..d232bbd7fd 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -226,7 +226,7 @@ static void sub2video_push_ref(InputStream *ist, int64_t pts)
  AV_BUFFERSRC_FLAG_PUSH);
 }
 
-static void sub2video_update(InputStream *ist, AVSubtitle *sub)
+void sub2video_update(InputStream *ist, AVSubtitle *sub)
 {
 AVFrame *frame = ist->sub2video.frame;
 int8_t *dst;
@@ -2468,6 +2468,7 @@ fail:
 static int transcode_subtitles(InputStream *ist, AVPacket *pkt, int *got_output)
 {
 AVSubtitle subtitle;
+int free_sub = 1;
 int i, ret = avcodec_decode_subtitle2(ist->dec_ctx,
   , got_output, pkt);
 
@@ -2502,7 +2503,21 @@ static int transcode_subtitles(InputStream *ist, AVPacket *pkt, int *got_output)
 if (!*got_output)
 return ret;
 
-sub2video_update(ist, );
+if (ist->sub2video.frame) {
+sub2video_update(ist, );
+} else {
+if (!ist->sub2video.sub_queue)
+ist->sub2video.sub_queue = av_fifo_alloc(8 * sizeof(AVSubtitle));
+if (!ist->sub2video.sub_queue)
+exit_program(1);
+if (!av_fifo_space(ist->sub2video.sub_queue)) {
+ret = av_fifo_realloc2(ist->sub2video.sub_queue, 2 * av_fifo_size(ist->sub2video.sub_queue));
+if (ret < 0)
+exit_program(1);
+}
+av_fifo_generic_write(ist->sub2video.sub_queue, , sizeof(subtitle), NULL);
+free_sub = 0;
+}
 
 if (!subtitle.num_rects)
 goto out;
@@ -2520,7 +2535,8 @@ static int transcode_subtitles(InputStream *ist, AVPacket *pkt, int *got_output)
 }
 
 out:
-avsubtitle_free();
+if (free_sub)
+avsubtitle_free();
 return ret;
 }
 
diff --git a/ffmpeg.h b/ffmpeg.h
index 59f6cb3659..06a1251124 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -337,6 +337,7 @@ typedef struct InputStream {
 struct sub2video {
 int64_t last_pts;
 int64_t end_pts;
+AVFifoBuffer *sub_queue;///< queue of AVSubtitle* before filter init
 AVFrame *frame;
 int w, h;
 } sub2video;
@@ -636,6 +637,8 @@ int filtergraph_is_simple(FilterGraph *fg);
 int init_simple_filtergraph(InputStream *ist, OutputStream *ost);
 int init_complex_filtergraph(FilterGraph *fg);
 
+void sub2video_update(InputStream *ist, AVSubtitle *sub);
+
 int ifilter_parameters_from_frame(InputFilter *ifilter, const AVFrame *frame);
 
 int ffmpeg_parse_options(int argc, char **argv);
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 816c906c7e..da2a46d3b7 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -1137,6 +1137,19 @@ int configure_filtergraph(FilterGraph *fg)
 }
 }
 
+/* process queued up subtitle packets */
+for (i = 0; i < fg->nb_inputs; i++) {
+InputStream *ist = fg->inputs[i]->ist;
+if (ist->sub2video.sub_queue && ist->sub2video.frame) {
+while (av_fifo_size(ist->sub2video.sub_queue)) {
+AVSubtitle tmp;
+av_fifo_generic_read(ist->sub2video.sub_queue, , sizeof(tmp), NULL);
+sub2video_update(ist, );
+avsubtitle_free();
+}
+}
+}
+
 return 0;
 }
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread James Almer

On 3/2/2017 11:47 AM, Tobias Rapp wrote:
> On 02.03.2017 15:22, James Almer wrote:
>> On 3/2/2017 6:28 AM, Nicolas George wrote:
>>> Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
 Ah, i see there's generic code to read and write CodecPrivate elements
 to and from raw extradata for native codecids where no special handling
 is required.

 In any case, the spec says

 "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."

 The ffv1 encoder creates extradata for v2 and newer, so the muxer
 should have a custom case for ffv1 in order to detect v2 streams and
 avoid writing said extradata.
>>>
>>> I have not looked myself at the situation, I only read what you wrote
>>> her. According to it, it seems here the FFV1 encoder is violating the
>>> specification and needs to be fixed.
>>
>> I can't say if the encoder exporting extradata for version 2 is right or
>> wrong, as muxers or bsfs could still use it for whatever reason, but at
>> least according to the draft ffv1 spec by Michael, it's to be stored at
>> the container level *only* on versions 3 and above.
>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1
> 
> The IETF draft explicitly excludes to specify FFV1 version 2:
> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1
> 
> IIRC there have been some edits to remove references to version 2 in the IETF 
> draft. In the older document at 
> http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the section 
> contains "version >= 2".
> 
> Regards,
> Tobias

Well, that makes things a bit more complex.
Maybe the Matroska spec should follow and also avoid mentioning v2?
That way we could just pretend those files don't exist and not bother
trying to drop their extradata during muxing.

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread James Almer

On 3/2/2017 5:44 AM, Carl Eugen Hoyos wrote:
> 2017-03-02 0:26 GMT+01:00 James Almer :
>> On 3/1/2017 7:18 PM, Carl Eugen Hoyos wrote:
> 
 This doesn't consider the CodecPrivate contents for FFV1 v3
 and above. It's only valid for v1 and v2.
>>>
>>> Is this comment meant for the muxer or the demuxer part?
>>>
>>> How can I reproduce the issue you see?
>>> For me, everything works as specified for default strictness.
>>
>> Ah, i see there's generic code to read and write CodecPrivate elements
>> to and from raw extradata for native codecids where no special handling
>> is required.
>>
>> In any case, the spec says
>>
>> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
>>
>> The ffv1 encoder creates extradata for v2 and newer, so the muxer
>> should have a custom case for ffv1 in order to detect v2 streams and
>> avoid writing said extradata.
> 
> Since this behaviour can only be produced with non-strict, I don't
> think it is of much relevance.

Strict experimental is only needed at the encoder level, not the muxer
level. This behavior can be reproduced just fine by remuxing existing
ffv1 v2 files into Matroska using the default strictness.

For that matter, Matroska (in V_MS/VFW/FOURCC mode), Nut and AVI
probably shouldn't store v2 extradata either as mentioned by the spec,
but they currently seem to do it.

> Anyway, this is removed from the current patch.

Fair enough.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: remove meaningless warning

2017-03-02 Thread Steven Liu

2017-03-02 18:01 GMT+08:00 wm4 :

> Ever since the codecpar changes, this has been always printed when
> opening a flv file. This is because the codecpar changes made all
> streams to be added lazily as read_packet is called.
> ---
>  libavformat/flvdec.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 520a3a0034..3959a3665a 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -1033,7 +1033,6 @@ skip:
>  }
>  if (i == s->nb_streams) {
>  static const enum AVMediaType stream_types[] =
> {AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE};
> -av_log(s, AV_LOG_WARNING, "%s stream discovered after head
> already parsed\n", av_get_media_type_string(stream_types[stream_type]));
>  st = create_stream(s, stream_types[stream_type]);
>  if (!st)
>  return AVERROR(ENOMEM);
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Tobias Rapp


On 02.03.2017 15:22, James Almer wrote:

On 3/2/2017 6:28 AM, Nicolas George wrote:

Le primidi 11 ventôse, an CCXXV, James Almer a écrit :

Ah, i see there's generic code to read and write CodecPrivate elements
to and from raw extradata for native codecids where no special handling
is required.

In any case, the spec says

"For FFV1 versions 2 or less, Private Data SHOULD NOT be written."

The ffv1 encoder creates extradata for v2 and newer, so the muxer
should have a custom case for ffv1 in order to detect v2 streams and
avoid writing said extradata.


I have not looked myself at the situation, I only read what you wrote
her. According to it, it seems here the FFV1 encoder is violating the
specification and needs to be fixed.


I can't say if the encoder exporting extradata for version 2 is right or
wrong, as muxers or bsfs could still use it for whatever reason, but at
least according to the draft ffv1 spec by Michael, it's to be stored at
the container level *only* on versions 3 and above.
https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1


The IETF draft explicitly excludes to specify FFV1 version 2:
https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1

IIRC there have been some edits to remove references to version 2 in the 
IETF draft. In the older document at 
http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the 
section contains "version >= 2".


Regards,
Tobias


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

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

2017-03-02 Thread Tobias Rapp


On 02.03.2017 03:27, Michael Niedermayer wrote:

On Mon, Feb 27, 2017 at 09:50:31AM +0100, Tobias Rapp wrote:

On 26.02.2017 16:09, Michael Niedermayer wrote:

On Mon, Feb 20, 2017 at 04:05:00PM +0100, Tobias Rapp wrote:

On 20.02.2017 15:09, Mark Thompson wrote:

On 06/02/17 12:33, Tobias Rapp wrote:

Sets framerate field in output codec context if explicitly specified on
the command-line.

Signed-off-by: Tobias Rapp 
---
ffmpeg_opt.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6a47d32..3b532da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1535,6 +1535,8 @@ static OutputStream *new_video_stream(OptionsContext *o, 
AVFormatContext *oc, in
   av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", frame_rate);
   exit_program(1);
   }
+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
+video_enc->framerate = ost->frame_rate;
   if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
   av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce invalid output 
files\n");




Is there a reason not to always set this, rather than only when it is specified 
explicitly on the command line as you have?

(Like 
,
 though that is after the current merge point and I don't know if it interacts with 
anything else.)


I just tried to be extra cautious. Merging Libav commit
d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more
general solution and might be preferred.


that one would change fate results, are the changed results better or
worse ?


I rebased unto current master and run fate with the attached change
to ffmpeg.c applied but couldn't find any changed reference files.




Which fate tests had some changes and which platform did you check?


there was a commit in origin/master that broke the tests, i realized
that after sending the mail but was too busy to reply immedeaty and
then forgot


No problem. So I consider my original patch 1/3 as dropped.

What is the best way to continue, assuming that the other two patches in 
the series are OK?


Shall I merge the single Libav commit d10102d2 followed by the other two 
patches? Or shall I wait until the general Libav merge-queue up to 
d10102d2 has been processed (~210 commits)? Or just wait for the merges 
affecting ffmpeg.c (~4 commits)?


Another option would be to just apply the other two patches as they are 
passing FATE without this one (framerate is guessed from stream timebase 
then).


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread James Almer

On 3/2/2017 6:28 AM, Nicolas George wrote:
> Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
>> Ah, i see there's generic code to read and write CodecPrivate elements
>> to and from raw extradata for native codecids where no special handling
>> is required.
>>
>> In any case, the spec says
>>
>> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
>>
>> The ffv1 encoder creates extradata for v2 and newer, so the muxer
>> should have a custom case for ffv1 in order to detect v2 streams and
>> avoid writing said extradata.
> 
> I have not looked myself at the situation, I only read what you wrote
> her. According to it, it seems here the FFV1 encoder is violating the
> specification and needs to be fixed.

I can't say if the encoder exporting extradata for version 2 is right or
wrong, as muxers or bsfs could still use it for whatever reason, but at
least according to the draft ffv1 spec by Michael, it's to be stored at
the container level *only* on versions 3 and above.
https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1

Michael probably knows best if version 2 is supposed to export this
extradata or not, and if what's currently exported is correct to being
with or not (I see for example that the encoder stores a crc value for
all versions that the decoder in turn purposely skips for version 2).

> 
> The way I see it, we should try to make muxers as generic and
> codec-independent as possible. Most cases where we have codec-specific
> code in muxers are when someone bungled the design, usually an
> industrial committee (but do not ask me how the Ogg people managed to
> make something even worse).
> 
> There are several ways to interpret the quote of the spec above:
> 
> 1a: Encoders SHOULD NOT return extradata to the application.
> 
> 1b: Applications SHOULD discard extradata returned by the encoder.
> 
> 2a: Applications SHOULD NOT give extradata to the muxer.
> 
> 2b: Muxers SHOULD discard extradata given by the application.
> 
> IMHO, the only reasonable one is 1a; it achieves automatically 2a and
> makes 1b and 2b completely unnecessary.

The quote is from the container spec, so it defines muxing and demuxing
guidelines only. If anything, the quote is closest to 2b.
https://github.com/Matroska-Org/matroska-specification/blob/master/codec_specs.md#v_ffv1

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

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 14:03:18 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:
> > These patches merge the previously skipped Libav commits, which made
> > avconv lazily initialize libavfilter graphs. This means the filters
> > are initialized with the actual output format, instead of whatever
> > libavformat reports.
> > 
> > It's a prerequisite to making hardware decoding support saner, as
> > hardware decoders will output a different pixfmt than the software
> > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > half of the code is removed.
> > 
> > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > changes were required.
> > 
> > I will push this tomorrow, except if critical failures are found.  
> 
> I think the patchset improved in terms of regressions but there are
> still several
> 
> ./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar 
> 22050  -shortest test.flv
> 
> looses the audio stream

This is because the test_video has an audio stream without any audio
packets. The filter is never initialized, so apad can't do its work
either. no audio is output, which in turn means that with the flv muxer
no audio stream is created.

To "fix" this you'd have to introduce a heuristic that determines that
audio is starting too late, and then maybe come up with a fake format
to initialize the filters anyway. This is out of scope of the merge,
and it's not worth fixing anyway.

> 
> also this code crashes with some private files:
> ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> ==7506==  Access not within mapped region at address 0x8
> ==7506==at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> ==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> ==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> ==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> ==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
> ==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
> ==7506==by 0x43B2FD: main (ffmpeg.c:4701)

I don't know if you're shitting me on purpose. I can't fix what I can't
reproduce, and you never gave me access to those files. Fix it yourself
if you think it's important. Seriously, what is this.

> This one produces a silent audio channel as previous patchsets did too
> ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav

While libavformat signals a mono channel configuration, the decoder
actually outputs stereo, with one channel muted. You can reproduce this
with current master ffmpeg too by adding "-ac 2". If this is a bug,
then it's merely an old bug that is made more obvious by this patch,
rather than introducing it.

I don't know why you could not determine this yourself. It would have
been easy to check.

> 
> This one looses the first displayed subtitle (the green "help")
> ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
> -qscale 2 -t 3 test.avi

The first time you mentioned this. Why didn't you do so a week ago?
When I complained that you come up with a new case punctually at
exactly the time when I want to merge the patches.

I have to analyze this one (the only real/actionable issue in your
whole post).

> This one changes timebase
> ./ffmpeg -i ~/fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec 
> mov_text -f mp4  -movflags frag_keyframe+empty_moov test.mp4

So what? If you had even bothered to read my patches, you would have
noticed that some fate tests are adjusted accordingly too. The
time_base gets more precise, which is not a bad thing.

> Also some files still require max_muxing_queue_size to be manually set
> to not fail
> [libmp3lame @ 0x31dbea0] Queue input is backward in time
> Too many packets buffered for output stream 0:1.
> [libmp3lame @ 0x31dbea0] 5 frames left in the queue on closing
> 
> This is worsened by the fact that the user has no hint towards this
> option in the error messages
> 
> [...]

No context, can't do anything about it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread Michael Niedermayer

On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:
> These patches merge the previously skipped Libav commits, which made
> avconv lazily initialize libavfilter graphs. This means the filters
> are initialized with the actual output format, instead of whatever
> libavformat reports.
> 
> It's a prerequisite to making hardware decoding support saner, as
> hardware decoders will output a different pixfmt than the software
> format reported by libavformat. This can be seen on ffmpeg_qsv.c
> and ffmpeg_cuvid.c, which don't lose any functionality, even though
> half of the code is removed.
> 
> There are some differences in how ffmpeg.c and avconv.c filter-flow
> works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> changes were required.
> 
> I will push this tomorrow, except if critical failures are found.

I think the patchset improved in terms of regressions but there are
still several

./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar 
22050  -shortest test.flv

looses the audio stream


also this code crashes with some private files:
==7506== Process terminating with default action of signal 11 (SIGSEGV)
==7506==  Access not within mapped region at address 0x8
==7506==at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
==7506==by 0x43B2FD: main (ffmpeg.c:4701)

This one produces a silent audio channel as previous patchsets did too
./ffmpeg -i ~/tickets/1726/Mono.thd out.wav


This one looses the first displayed subtitle (the green "help")
./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
-qscale 2 -t 3 test.avi

This one changes timebase
./ffmpeg -i ~/fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec 
mov_text -f mp4  -movflags frag_keyframe+empty_moov test.mp4

Also some files still require max_muxing_queue_size to be manually set
to not fail
[libmp3lame @ 0x31dbea0] Queue input is backward in time
Too many packets buffered for output stream 0:1.
[libmp3lame @ 0x31dbea0] 5 frames left in the queue on closing

This is worsened by the fact that the user has no hint towards this
option in the error messages

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

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


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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 12:44:57 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 01, 2017 at 01:31:02PM +0100, wm4 wrote:
> > On Wed, 1 Mar 2017 13:06:29 +0100
> > Carl Eugen Hoyos  wrote:
> >   
> > > 2017-03-01 12:36 GMT+01:00 wm4 :  
> > > > On Wed, 1 Mar 2017 12:20:10 +0100
> > > > Carl Eugen Hoyos  wrote:
> > > >
> > > >> 2017-02-25 15:59 GMT+01:00 wm4 :
> > > >> > I'm documenting existing practice.
> > > >>
> > > >> > -@subheading Always wait long enough before pushing changes
> > > >> > +@subheading Always wait long enough before pushing changes
> > > >> > to code actively maintained by others
> > > >>
> > > >> I suspect this is missing an exception for security issues if you want 
> > > >> to
> > > >> document the actual practice.
> > > >
> > > > I can add to the end of the subheading:
> > > >
> > > >   Critical security issues are an exception. These can be pushed after
> > > >   the patch has been for 24 hours on the mailing list and the maintainer
> > > >   didn't respond yet, and nobody has rejected the patch. In addition,
> > > >   if another committer has approved the patch and acknowledged the
> > > >   urgency of the fix, the patch can be pushed immediately.
> > > 
> > > I will most likely not fix a (real) security issue, but above seems quite
> > > unpractical to me (and unreasonable for real security issues).  
> > 
> > How is that impractical? What do you suggest?
> > 
> > I certainly hope you're not suggesting that security-sensitive changes
> > to code the patch author does not maintain can be pushed without reviews
> > at all.  
> 
> I dont know what carl meant exactly but as one doing many of the fixes
> there are a few words i should say
> 
> Posting patches is only usefull if more issues are found in the
> posted patch as a result of it being posted than if it wasnt posted.
> It seems few issues are found in patches in this category when posted.
> Posting patches interrupts the development cycle, normally i would
> debug an issue, write a fix, test and review the fix and if iam
> unsure and theres someone who knows the code better post a patch
> (either privatly or publically as the case demands)
> otherwise push and backport and then the next issue.
> The cases where no patch is posted, the pushing and local backport
> happens immediately, but if i post a patch and wait 24h by the time i
> backport it to the releases its been a longer time and there have been
> many other issues in the meantime, that makes backports harder,
> less common and lower quality. Thats what iam seeing in the last
> days not a imagined issue.
> Also i think iam more sloppy with self reviewing my code when i post
> a patch
> 
> Also adding a unconditional 24h delay for changes makes the whole
> process more work. The time i can spend on FFmpeg is limited, if i
> send a patch in every case and not just in cases were theres an
> active maitainer who wants and does review things before being
> pushed. Then the result is some other things arent done anymore simply
> due to lack of time, If you want a concrete example you can look at
> my gnu/kfreebsd fate client, it stoped working days ago and i noticed
> but simply didnt had the time to look into it, previously i always
> looked into such things quickly when i noticed.
> 
> 
> And posting about (serious) security issues in public before fixing
> them adds time for anyone wanting to exploit it
> 
> posting patches and waiting has a cost and we should only pay that
> when we get more value back.
> 
> On a slightly differnt topic, accusing other fellow developers also
> has a cost, not just everyones time but also at least for me, the
> will and interrest to work in this environment
> 
> and now ill try to stay out of this (rather timeconsuming disscussion)
> like i did before, just wanted to send one mail as the discussion was
> about security and related patches which i work on alot ...
> 
> thx
> 
> [...]

It seems you didn't read what I wrote. If another committer says ok to
the patch (even on IRC), it would be ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

2017-03-02 Thread Michael Niedermayer

On Wed, Mar 01, 2017 at 01:31:02PM +0100, wm4 wrote:
> On Wed, 1 Mar 2017 13:06:29 +0100
> Carl Eugen Hoyos  wrote:
> 
> > 2017-03-01 12:36 GMT+01:00 wm4 :
> > > On Wed, 1 Mar 2017 12:20:10 +0100
> > > Carl Eugen Hoyos  wrote:
> > >  
> > >> 2017-02-25 15:59 GMT+01:00 wm4 :  
> > >> > I'm documenting existing practice.  
> > >>  
> > >> > -@subheading Always wait long enough before pushing changes
> > >> > +@subheading Always wait long enough before pushing changes
> > >> > to code actively maintained by others  
> > >>
> > >> I suspect this is missing an exception for security issues if you want to
> > >> document the actual practice.  
> > >
> > > I can add to the end of the subheading:
> > >
> > >   Critical security issues are an exception. These can be pushed after
> > >   the patch has been for 24 hours on the mailing list and the maintainer
> > >   didn't respond yet, and nobody has rejected the patch. In addition,
> > >   if another committer has approved the patch and acknowledged the
> > >   urgency of the fix, the patch can be pushed immediately.  
> > 
> > I will most likely not fix a (real) security issue, but above seems quite
> > unpractical to me (and unreasonable for real security issues).
> 
> How is that impractical? What do you suggest?
> 
> I certainly hope you're not suggesting that security-sensitive changes
> to code the patch author does not maintain can be pushed without reviews
> at all.

I dont know what carl meant exactly but as one doing many of the fixes
there are a few words i should say

Posting patches is only usefull if more issues are found in the
posted patch as a result of it being posted than if it wasnt posted.
It seems few issues are found in patches in this category when posted.
Posting patches interrupts the development cycle, normally i would
debug an issue, write a fix, test and review the fix and if iam
unsure and theres someone who knows the code better post a patch
(either privatly or publically as the case demands)
otherwise push and backport and then the next issue.
The cases where no patch is posted, the pushing and local backport
happens immediately, but if i post a patch and wait 24h by the time i
backport it to the releases its been a longer time and there have been
many other issues in the meantime, that makes backports harder,
less common and lower quality. Thats what iam seeing in the last
days not a imagined issue.
Also i think iam more sloppy with self reviewing my code when i post
a patch

Also adding a unconditional 24h delay for changes makes the whole
process more work. The time i can spend on FFmpeg is limited, if i
send a patch in every case and not just in cases were theres an
active maitainer who wants and does review things before being
pushed. Then the result is some other things arent done anymore simply
due to lack of time, If you want a concrete example you can look at
my gnu/kfreebsd fate client, it stoped working days ago and i noticed
but simply didnt had the time to look into it, previously i always
looked into such things quickly when i noticed.

And posting about (serious) security issues in public before fixing
them adds time for anyone wanting to exploit it

posting patches and waiting has a cost and we should only pay that
when we get more value back.

On a slightly differnt topic, accusing other fellow developers also
has a cost, not just everyones time but also at least for me, the
will and interrest to work in this environment

and now ill try to stay out of this (rather timeconsuming disscussion)
like i did before, just wanted to send one mail as the discussion was
about security and related patches which i work on alot ...

thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Peter B.

On 03/01/2017 03:00 PM, Jerome Martinez wrote:
> My suggestion:
> - support by the demuxer
> - for the muxer, support only if a specific explicit option is set,
> default stays AVI compatibility layer (no break in playback by old
> players).

This sounds like a very practical approach to me:
New files can be played, but one is not accidentially/surprisingly
creating incompatible files unless they explicitly choose to do so.
:)

Regards,
Pb

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

Re: [FFmpeg-devel] [PATCH]lavc/sheervideo: Fix Y prediction for interlaced frames with alpha

2017-03-02 Thread Paul B Mahol

On 3/1/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #6210 visually.
>
> Please review, Carl Eugen
>

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

[FFmpeg-devel] [PATCH] avformat/flvdec: remove meaningless warning

2017-03-02 Thread wm4

Ever since the codecpar changes, this has been always printed when
opening a flv file. This is because the codecpar changes made all
streams to be added lazily as read_packet is called.
---
 libavformat/flvdec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 520a3a0034..3959a3665a 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1033,7 +1033,6 @@ skip:
 }
 if (i == s->nb_streams) {
 static const enum AVMediaType stream_types[] = 
{AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE};
-av_log(s, AV_LOG_WARNING, "%s stream discovered after head already 
parsed\n", av_get_media_type_string(stream_types[stream_type]));
 st = create_stream(s, stream_types[stream_type]);
 if (!st)
 return AVERROR(ENOMEM);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support QDMC

2017-03-02 Thread Paul B Mahol

On 3/1/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch allows muxing and demuxing of QDMC in mkv.
>
> Please comment, Carl Eugen
>

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 10:47:23 +0100
Hendrik Leppkes  wrote:

> On Thu, Mar 2, 2017 at 10:35 AM, wm4  wrote:
> > On Fri, 17 Feb 2017 21:15:56 +0100
> > Michael Niedermayer  wrote:
> >  
> >> On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:  
> >> > On Thu, 16 Feb 2017 10:29:36 -0800
> >> > Aman Gupta  wrote:
> >> >  
> >> > > From: Aman Gupta 
> >> > >
> >> > > This fixes playback of h264 streams with SPS changes. One such sample
> >> > > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> >> > > It switches mid-stream from level 4.0 to level 3.2.
> >> > >
> >> > > Previously, playing this sample with the VT hwaccel on iOS would crash.
> >> > > After this patch, it plays back as expected.
> >> > >
> >> > > On macOS however, feeding in new SPS into an existing decompression
> >> > > session does not always work, so this patch is only a partial fix.
> >> > > ---
> >> > >  libavcodec/h264dec.c | 7 +++
> >> > >  1 file changed, 7 insertions(+)
> >> > >
> >> > > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> >> > > index 41c0964..e521c52 100644
> >> > > --- a/libavcodec/h264dec.c
> >> > > +++ b/libavcodec/h264dec.c
> >> > > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >> > >  break;
> >> > >  case H264_NAL_SPS: {
> >> > >  GetBitContext tmp_gb = nal->gb;
> >> > > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> >> > > AV_PIX_FMT_VIDEOTOOLBOX) {
> >> > > +ret = avctx->hwaccel->decode_slice(avctx,
> >> > > +   nal->data,
> >> > > +   nal->size);
> >> > > +if (ret < 0)
> >> > > +goto end;
> >> > > +}
> >> > >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, 
> >> > > >ps, 0) >= 0)
> >> > >  break;
> >> > >  av_log(h->avctx, AV_LOG_DEBUG,  
> >> >
> >> > A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
> >> > callback here, even if it's used by VT only.
> >> >
> >> > You should probably wait for approval by michaelni.  
> >>
> >> i dont really have an oppinion on hwaccel, thats not so much my
> >> area
> >> though i find special cases for specific hwaccel a bit ugly, i dont
> >> object to it, just saying i would be in favor of not having special
> >> cases if that is possible  
> >
> > So do you think this is tolerable in the current state or not?  
> 
> I agree with Michael, the number of VT-specific hacks seem to be
> piling up. Maybe it should be re-designed entirely instead of piling
> hacks on top of hacks to keep it barely working.

Would that mean reimplementing it as a full-stream decoder?

That's my favorite choice as well, but apparently the VT hwaccel
wouldn't require much more changes to work reasonably well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

2017-03-02 Thread Hendrik Leppkes

On Thu, Mar 2, 2017 at 10:35 AM, wm4  wrote:
> On Fri, 17 Feb 2017 21:15:56 +0100
> Michael Niedermayer  wrote:
>
>> On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:
>> > On Thu, 16 Feb 2017 10:29:36 -0800
>> > Aman Gupta  wrote:
>> >
>> > > From: Aman Gupta 
>> > >
>> > > This fixes playback of h264 streams with SPS changes. One such sample
>> > > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
>> > > It switches mid-stream from level 4.0 to level 3.2.
>> > >
>> > > Previously, playing this sample with the VT hwaccel on iOS would crash.
>> > > After this patch, it plays back as expected.
>> > >
>> > > On macOS however, feeding in new SPS into an existing decompression
>> > > session does not always work, so this patch is only a partial fix.
>> > > ---
>> > >  libavcodec/h264dec.c | 7 +++
>> > >  1 file changed, 7 insertions(+)
>> > >
>> > > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>> > > index 41c0964..e521c52 100644
>> > > --- a/libavcodec/h264dec.c
>> > > +++ b/libavcodec/h264dec.c
>> > > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> > >  break;
>> > >  case H264_NAL_SPS: {
>> > >  GetBitContext tmp_gb = nal->gb;
>> > > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
>> > > AV_PIX_FMT_VIDEOTOOLBOX) {
>> > > +ret = avctx->hwaccel->decode_slice(avctx,
>> > > +   nal->data,
>> > > +   nal->size);
>> > > +if (ret < 0)
>> > > +goto end;
>> > > +}
>> > >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, 
>> > > >ps, 0) >= 0)
>> > >  break;
>> > >  av_log(h->avctx, AV_LOG_DEBUG,
>> >
>> > A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
>> > callback here, even if it's used by VT only.
>> >
>> > You should probably wait for approval by michaelni.
>>
>> i dont really have an oppinion on hwaccel, thats not so much my
>> area
>> though i find special cases for specific hwaccel a bit ugly, i dont
>> object to it, just saying i would be in favor of not having special
>> cases if that is possible
>
> So do you think this is tolerable in the current state or not?

I agree with Michael, the number of VT-specific hacks seem to be
piling up. Maybe it should be re-designed entirely instead of piling
hacks on top of hacks to keep it barely working.

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

[FFmpeg-devel] [PATCH v2 1/2] lavc: consider an error during decoder draining as EOF

2017-03-02 Thread wm4

There is no reason that draining couldn't return an error or two. But
some decoders don't handle this very well, and might always return an
error. This can lead to API users getting into an infinite loop and
burning CPU, because no progress is made and EOF is never returned.

In fact, ffmpeg.c contains a hack against such a case. It is removed
with this patch. This particular error case seems to have been fixed
since the hack was added, though.

This might lose frames if decoding returns errors during draining.
---
Minor lavc bump missing.
---
 libavcodec/utils.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1156e43079..db3adb18d4 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2807,12 +2807,12 @@ static int do_decode(AVCodecContext *avctx, AVPacket 
*pkt)
 if (ret == AVERROR(EAGAIN))
 ret = pkt->size;
 
-if (ret < 0)
-return ret;
-
 if (avctx->internal->draining && !got_frame)
 avctx->internal->draining_done = 1;
 
+if (ret < 0)
+return ret;
+
 if (ret >= pkt->size) {
 av_packet_unref(avctx->internal->buffer_pkt);
 } else {
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v2 2/2] ffmpeg: remove unnecessary hack for decoders which refuse to drain

2017-03-02 Thread wm4

Now the previous commit takes care of this instead.
---
 ffmpeg.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 38395e7598..ee791d68a3 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2529,12 +2529,6 @@ static int process_input_packet(InputStream *ist, const 
AVPacket *pkt, int no_eo
ist->file_index, ist->st->index, av_err2str(ret));
 if (exit_on_error)
 exit_program(1);
-// Decoding might not terminate if we're draining the decoder, and
-// the decoder keeps returning an error.
-// This should probably be considered a libavcodec issue.
-// Sample: fate-vsynth1-dnxhd-720p-hr-lb
-if (!pkt)
-eof_reached = 1;
 break;
 }
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

2017-03-02 Thread wm4

On Fri, 17 Feb 2017 21:15:56 +0100
Michael Niedermayer  wrote:

> On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:
> > On Thu, 16 Feb 2017 10:29:36 -0800
> > Aman Gupta  wrote:
> >   
> > > From: Aman Gupta 
> > > 
> > > This fixes playback of h264 streams with SPS changes. One such sample
> > > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> > > It switches mid-stream from level 4.0 to level 3.2.
> > > 
> > > Previously, playing this sample with the VT hwaccel on iOS would crash.
> > > After this patch, it plays back as expected.
> > > 
> > > On macOS however, feeding in new SPS into an existing decompression
> > > session does not always work, so this patch is only a partial fix.
> > > ---
> > >  libavcodec/h264dec.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > > index 41c0964..e521c52 100644
> > > --- a/libavcodec/h264dec.c
> > > +++ b/libavcodec/h264dec.c
> > > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >  break;
> > >  case H264_NAL_SPS: {
> > >  GetBitContext tmp_gb = nal->gb;
> > > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> > > AV_PIX_FMT_VIDEOTOOLBOX) {
> > > +ret = avctx->hwaccel->decode_slice(avctx,
> > > +   nal->data,
> > > +   nal->size);
> > > +if (ret < 0)
> > > +goto end;
> > > +}
> > >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 
> > > 0) >= 0)
> > >  break;
> > >  av_log(h->avctx, AV_LOG_DEBUG,  
> > 
> > A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
> > callback here, even if it's used by VT only.
> > 
> > You should probably wait for approval by michaelni.  
> 
> i dont really have an oppinion on hwaccel, thats not so much my
> area
> though i find special cases for specific hwaccel a bit ugly, i dont
> object to it, just saying i would be in favor of not having special
> cases if that is possible

So do you think this is tolerable in the current state or not?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-02 Thread wm4

On Fri, 24 Feb 2017 10:49:39 +0100
wm4  wrote:

> Makes sure the output can be mapped as OpenGL texture.
> This is what at least video players normally want.
> ---
>  libavcodec/videotoolbox.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 2ebe60fb5c..824f2d8e68 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -477,6 +477,7 @@ static CFDictionaryRef 
> videotoolbox_buffer_attributes_create(int width,
>  CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
> +CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
>  
>  CFRelease(io_surface_properties);
>  CFRelease(cv_pix_fmt);

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

2017-03-02 Thread wm4

On Tue, 21 Feb 2017 13:40:08 -0800
Aman Gupta  wrote:

> On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje 
> wrote:
> 
> > Hi,
> >
> > On Tue, Feb 21, 2017 at 1:48 PM, Aman Gupta  wrote:
> >  
> >> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> >> index 41c0964392..a0ae632fed 100644
> >> --- a/libavcodec/h264dec.c
> >> +++ b/libavcodec/h264dec.c
> >> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame
> >> *dst, H264Picture *srcp)
> >>  AVFrame *src = srcp->f;
> >>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->format);
> >>  int i;
> >> -int ret = av_frame_ref(dst, src);
> >> +int ret;
> >> +
> >> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
> >> +return AVERROR_INVALIDDATA;
> >> +
> >> +ret = av_frame_ref(dst, src);
> >>  if (ret < 0)
> >>  return ret;  
> >
> >
> > This is a total hack :) Is there a way to hide this into VT-specific code
> > outside h264*.[ch]?
> >  
> 
> The way the VT hwaccel works is a total hack, as noted in my commit message.
> 
> AFAICT, given how the hwaccel APIs work, there's no way to do this outside
> the h264 decoder. But I'm happy to try fixing this a different way if
> anyone has a suggestion.

So, should we push this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: allow not setting the kCVPixelBufferPixelFormatTypeKey

2017-03-02 Thread wm4

On Fri, 24 Feb 2017 10:44:23 +0100
wm4  wrote:

> If AVVideotoolboxContext.cv_pix_fmt_type is set to 0, don't set the
> kCVPixelBufferPixelFormatTypeKey value on the VT decoder.
> 
> This makes VT output its native format, which can be much faster on
> some hardware iterations (if the native format does not match with
> the requested format, it will be converted, which is slow).
> 
> The default is still forcing nv12.
> ---
> TODO: minor libavcodec bump
> ---
>  libavcodec/videotoolbox.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1288aa5087..2ebe60fb5c 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -472,7 +472,8 @@ static CFDictionaryRef 
> videotoolbox_buffer_attributes_create(int width,
>
> ,
>
> );
>  
> -CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferPixelFormatTypeKey, cv_pix_fmt);
> +if (pix_fmt)
> +CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferPixelFormatTypeKey, cv_pix_fmt);
>  CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc, lavf, lavu: remove AVOption requirement to access public fields

2017-03-02 Thread wm4

On Mon, 13 Feb 2017 11:51:28 +0100
wm4  wrote:

> Allow all struct fields to be accessed directly, as long as they're
> public.
> 
> Before this change, many fields were "public", but could be accessed via
> AVOption only. This meant they were effectively not public, but were
> present for documentation purposes, which was incredibly confusing at
> best.
> ---

Pushed both patches, with micro versions bumped and a note in
APIchanges.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Nicolas George

Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
> Ah, i see there's generic code to read and write CodecPrivate elements
> to and from raw extradata for native codecids where no special handling
> is required.
> 
> In any case, the spec says
> 
> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
> 
> The ffv1 encoder creates extradata for v2 and newer, so the muxer
> should have a custom case for ffv1 in order to detect v2 streams and
> avoid writing said extradata.

I have not looked myself at the situation, I only read what you wrote
her. According to it, it seems here the FFV1 encoder is violating the
specification and needs to be fixed.

The way I see it, we should try to make muxers as generic and
codec-independent as possible. Most cases where we have codec-specific
code in muxers are when someone bungled the design, usually an
industrial committee (but do not ask me how the Ogg people managed to
make something even worse).

There are several ways to interpret the quote of the spec above:

1a: Encoders SHOULD NOT return extradata to the application.

1b: Applications SHOULD discard extradata returned by the encoder.

2a: Applications SHOULD NOT give extradata to the muxer.

2b: Muxers SHOULD discard extradata given by the application.

IMHO, the only reasonable one is 1a; it achieves automatically 2a and
makes 1b and 2b completely unnecessary.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread wm4

On Thu, 2 Mar 2017 09:58:29 +0100
Carl Eugen Hoyos  wrote:

> 2017-03-02 9:53 GMT+01:00 wm4 :
> 
> > I will push this tomorrow, except if critical failures are found.  
> 
> Please give people a few days to test and / or comment.

You had 3 weeks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread Carl Eugen Hoyos

2017-03-02 9:53 GMT+01:00 wm4 :

> I will push this tomorrow, except if critical failures are found.

Please give people a few days to test and / or comment.

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

[FFmpeg-devel] [PATCH v3 6/7] ffmpeg: restructure sending EOF to filters

2017-03-02 Thread wm4

From: Anton Khirnov 

Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.

This should fix the random FATE failures for complex filtergraph tests
after a3a0230a9870b9018dc7415ae5872784d524cfe5

This merges Libav commit 94ebf55. It was previously skipped.

This is the last filter init related Libav commit that was skipped, so
this also removes the commits from doc/libav-merge.txt.

Signed-off-by: wm4 
---
 doc/libav-merge.txt |  1 -
 ffmpeg.c| 43 ---
 ffmpeg.h|  2 ++
 ffmpeg_filter.c |  9 +
 4 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
index 23b48d1e2b..39d846f8fc 100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@ -95,7 +95,6 @@ Stuff that didn't reach the codebase:
   - 0cef06df0 checkasm: add HEVC MC tests
   - e7078e842 hevcdsp: add x86 SIMD for MC
 - QSV scaling filter (62c58c5)
-- ffmpeg.c filter init decoupling (3e265ca,a3a0230,d2e56cf,94ebf55)
 
 Collateral damage that needs work locally:
 --
diff --git a/ffmpeg.c b/ffmpeg.c
index e059b88720..10c66eee75 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2197,6 +2197,34 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
 return 0;
 }
 
+static int ifilter_send_eof(InputFilter *ifilter)
+{
+int i, j, ret;
+
+ifilter->eof = 1;
+
+if (ifilter->filter) {
+ret = av_buffersrc_add_frame_flags(ifilter->filter, NULL, 
AV_BUFFERSRC_FLAG_PUSH);
+if (ret < 0)
+return ret;
+} else {
+// the filtergraph was never configured
+FilterGraph *fg = ifilter->graph;
+for (i = 0; i < fg->nb_inputs; i++)
+if (!fg->inputs[i]->eof)
+break;
+if (i == fg->nb_inputs) {
+// All the input streams have finished without the filtergraph
+// ever being configured.
+// Mark the output streams as finished.
+for (j = 0; j < fg->nb_outputs; j++)
+finish_output_stream(fg->outputs[j]->ost);
+}
+}
+
+return 0;
+}
+
 // This does not quite work like avcodec_decode_audio4/avcodec_decode_video2.
 // There is the following difference: if you got a frame, you must call
 // it again with pkt=NULL. pkt==NULL is treated differently from pkt.size==0
@@ -2498,18 +2526,11 @@ out:
 
 static int send_filter_eof(InputStream *ist)
 {
-int i, j, ret;
+int i, ret;
 for (i = 0; i < ist->nb_filters; i++) {
-if (ist->filters[i]->filter) {
-ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
-if (ret < 0)
-return ret;
-} else {
-// the filtergraph was never configured
-FilterGraph *fg = ist->filters[i]->graph;
-for (j = 0; j < fg->nb_outputs; j++)
-finish_output_stream(fg->outputs[j]->ost);
-}
+ret = ifilter_send_eof(ist->filters[i]);
+if (ret < 0)
+return ret;
 }
 return 0;
 }
diff --git a/ffmpeg.h b/ffmpeg.h
index 56e35ebb9c..5d20d453eb 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -248,6 +248,8 @@ typedef struct InputFilter {
 uint64_t channel_layout;
 
 AVBufferRef *hw_frames_ctx;
+
+int eof;
 } InputFilter;
 
 typedef struct OutputFilter {
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 4d9a4e2eb8..816c906c7e 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -1128,6 +1128,15 @@ int configure_filtergraph(FilterGraph *fg)
 }
 }
 
+/* send the EOFs for the finished inputs */
+for (i = 0; i < fg->nb_inputs; i++) {
+if (fg->inputs[i]->eof) {
+ret = av_buffersrc_add_frame(fg->inputs[i]->filter, NULL);
+if (ret < 0)
+return ret;
+}
+}
+
 return 0;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 7/7] ffmpeg_cuvid: adapt for recent filter graph initialization changes

2017-03-02 Thread wm4

From: Timo Rothenpieler 

---
 ffmpeg.c   |  13 --
 ffmpeg.h   |   1 -
 ffmpeg_cuvid.c | 141 -
 3 files changed, 30 insertions(+), 125 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 10c66eee75..27bfc72cff 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3546,19 +3546,6 @@ static int transcode_init(void)
 input_streams[j + ifile->ist_index]->start = 
av_gettime_relative();
 }
 
-/* hwaccel transcoding */
-for (i = 0; i < nb_output_streams; i++) {
-ost = output_streams[i];
-
-if (!ost->stream_copy) {
-
-#if CONFIG_CUVID
-if (cuvid_transcode_init(ost))
-exit_program(1);
-#endif
-}
-}
-
 /* init input streams */
 for (i = 0; i < nb_input_streams; i++)
 if ((ret = init_input_stream(i, error, sizeof(error))) < 0) {
diff --git a/ffmpeg.h b/ffmpeg.h
index 5d20d453eb..59f6cb3659 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -648,6 +648,5 @@ int qsv_init(AVCodecContext *s);
 int vaapi_decode_init(AVCodecContext *avctx);
 int vaapi_device_init(const char *device);
 int cuvid_init(AVCodecContext *s);
-int cuvid_transcode_init(OutputStream *ost);
 
 #endif /* FFMPEG_H */
diff --git a/ffmpeg_cuvid.c b/ffmpeg_cuvid.c
index 46540795d4..3ff3b40f17 100644
--- a/ffmpeg_cuvid.c
+++ b/ffmpeg_cuvid.c
@@ -17,138 +17,57 @@
  */
 
 #include "libavutil/hwcontext.h"
+#include "libavutil/pixdesc.h"
 
 #include "ffmpeg.h"
 
-typedef struct CUVIDContext {
-AVBufferRef *hw_frames_ctx;
-} CUVIDContext;
-
 static void cuvid_uninit(AVCodecContext *avctx)
 {
-InputStream  *ist = avctx->opaque;
-CUVIDContext *ctx = ist->hwaccel_ctx;
-
-if (ctx) {
-av_buffer_unref(>hw_frames_ctx);
-av_freep();
-}
-
+InputStream *ist = avctx->opaque;
 av_buffer_unref(>hw_frames_ctx);
-
-ist->hwaccel_ctx = 0;
-ist->hwaccel_uninit = 0;
 }
 
 int cuvid_init(AVCodecContext *avctx)
 {
-InputStream  *ist = avctx->opaque;
-CUVIDContext *ctx = ist->hwaccel_ctx;
-
-av_log(NULL, AV_LOG_TRACE, "Initializing cuvid hwaccel\n");
-
-if (!ctx) {
-av_log(NULL, AV_LOG_ERROR, "CUVID transcoding is not initialized. "
-   "-hwaccel cuvid should only be used for one-to-one CUVID 
transcoding "
-   "with no (software) filters.\n");
-return AVERROR(EINVAL);
-}
-
-return 0;
-}
-
-int cuvid_transcode_init(OutputStream *ost)
-{
-InputStream *ist;
-const enum AVPixelFormat *pix_fmt;
-AVHWFramesContext *hwframe_ctx;
-AVBufferRef *device_ref = NULL;
-CUVIDContext *ctx = NULL;
-int ret = 0;
-
-av_log(NULL, AV_LOG_TRACE, "Initializing cuvid transcoding\n");
+InputStream *ist = avctx->opaque;
+AVHWFramesContext *frames_ctx;
+int ret;
 
-if (ost->source_index < 0)
-return 0;
+av_log(avctx, AV_LOG_VERBOSE, "Initializing cuvid hwaccel\n");
 
-ist = input_streams[ost->source_index];
-
-/* check if the encoder supports CUVID */
-if (!ost->enc->pix_fmts)
-goto cancel;
-for (pix_fmt = ost->enc->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; pix_fmt++)
-if (*pix_fmt == AV_PIX_FMT_CUDA)
-break;
-if (*pix_fmt == AV_PIX_FMT_NONE)
-goto cancel;
-
-/* check if the decoder supports CUVID */
-if (ist->hwaccel_id != HWACCEL_CUVID || !ist->dec || !ist->dec->pix_fmts)
-goto cancel;
-for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; pix_fmt++)
-if (*pix_fmt == AV_PIX_FMT_CUDA)
-break;
-if (*pix_fmt == AV_PIX_FMT_NONE)
-goto cancel;
-
-av_log(NULL, AV_LOG_VERBOSE, "Setting up CUVID transcoding\n");
-
-if (ist->hwaccel_ctx) {
-ctx = ist->hwaccel_ctx;
-} else {
-ctx = av_mallocz(sizeof(*ctx));
-if (!ctx) {
-ret = AVERROR(ENOMEM);
-goto error;
+if (!hw_device_ctx) {
+ret = av_hwdevice_ctx_create(_device_ctx, AV_HWDEVICE_TYPE_CUDA,
+ ist->hwaccel_device, NULL, 0);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Error creating a CUDA device\n");
+return ret;
 }
 }
 
-if (!ctx->hw_frames_ctx) {
-ret = av_hwdevice_ctx_create(_ref, AV_HWDEVICE_TYPE_CUDA,
- ist->hwaccel_device, NULL, 0);
-if (ret < 0)
-goto error;
+av_buffer_unref(>hw_frames_ctx);
+ist->hw_frames_ctx = av_hwframe_ctx_alloc(hw_device_ctx);
+if (!ist->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "Error creating a CUDA frames context\n");
+return AVERROR(ENOMEM);
+}
 
-ctx->hw_frames_ctx = av_hwframe_ctx_alloc(device_ref);
-if (!ctx->hw_frames_ctx) {
-av_log(NULL, AV_LOG_ERROR, "av_hwframe_ctx_alloc failed\n");
-ret = AVERROR(ENOMEM);
-goto error;
-}
-av_buffer_unref(_ref);
+

[FFmpeg-devel] [PATCH v3 5/7] ffmpeg: move flushing the queued frames to configure_filtergraph()

2017-03-02 Thread wm4

From: Anton Khirnov 

This is a more appropriate place for it, and will also be useful in the
following commit.

This merges Libav commit d2e56cf. It was previously skipped.

Signed-off-by: wm4 
---
 ffmpeg.c| 11 ---
 ffmpeg_filter.c | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 2f6eed7d78..e059b88720 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2186,17 +2186,6 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
 av_log(NULL, AV_LOG_ERROR, "Error reinitializing filters!\n");
 return ret;
 }
-
-for (i = 0; i < fg->nb_inputs; i++) {
-while (av_fifo_size(fg->inputs[i]->frame_queue)) {
-AVFrame *tmp;
-av_fifo_generic_read(fg->inputs[i]->frame_queue, , 
sizeof(tmp), NULL);
-ret = av_buffersrc_add_frame(fg->inputs[i]->filter, tmp);
-av_frame_free();
-if (ret < 0)
-return ret;
-}
-}
 }
 
 ret = av_buffersrc_add_frame_flags(ifilter->filter, frame, 
AV_BUFFERSRC_FLAG_PUSH);
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index f21a8c85f8..4d9a4e2eb8 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -1117,6 +1117,17 @@ int configure_filtergraph(FilterGraph *fg)
  ost->enc_ctx->frame_size);
 }
 
+for (i = 0; i < fg->nb_inputs; i++) {
+while (av_fifo_size(fg->inputs[i]->frame_queue)) {
+AVFrame *tmp;
+av_fifo_generic_read(fg->inputs[i]->frame_queue, , 
sizeof(tmp), NULL);
+ret = av_buffersrc_add_frame(fg->inputs[i]->filter, tmp);
+av_frame_free();
+if (ret < 0)
+return ret;
+}
+}
+
 return 0;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 1/7] ffmpeg: make sure packets put into the muxing FIFO are refcounted

2017-03-02 Thread wm4

Some callers (like do_subtitle_out()) call this with an AVPacket that is
not refcounted. This can cause undefined behavior.

Calling av_packet_move_ref() does not make a packet refcounted if it
isn't yet. (And it can't be made to, because it always succeeds,
and can't return ENOMEM.)

Call av_packet_ref() instead to make sure it's refcounted.

I couldn't find a case that is fixed by this with the current code. But
it will fix the fate-pva-demux test with the later patches applied.

Signed-off-by: wm4 
---
 ffmpeg.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 38395e7598..5adec2b290 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -654,7 +654,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost)
 int ret;
 
 if (!of->header_written) {
-AVPacket tmp_pkt;
+AVPacket tmp_pkt = {0};
 /* the muxer is not initialized yet, buffer the packet */
 if (!av_fifo_space(ost->muxing_queue)) {
 int new_size = FFMIN(2 * av_fifo_size(ost->muxing_queue),
@@ -669,8 +669,11 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost)
 if (ret < 0)
 exit_program(1);
 }
-av_packet_move_ref(_pkt, pkt);
+ret = av_packet_ref(_pkt, pkt);
+if (ret < 0)
+exit_program(1);
 av_fifo_generic_write(ost->muxing_queue, _pkt, sizeof(tmp_pkt), 
NULL);
+av_packet_unref(pkt);
 return;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 2/7] ffmpeg: do packet ts rescaling in write_packet()

2017-03-02 Thread wm4

From: Anton Khirnov 

This will be useful in the following commit, after which the muxer
timebase is not always available when encoding.

This merges Libav commit 3e265ca. It was previously skipped.

There are some changes with how/when the mux_timebase field is set,
because the Libav approach often causes a too imprecise time base
to be set. This is hard, because the muxer's write_header function
can readjust the timebase, at which point we might already have
encoded packets buffered. (It might be better to buffer them after
the encoder, instead of after all the timestamp handling logic
before muxing.)

The two FATE tests change because the output time base is raised
for subtitles. (Needed to avoid certain rounding issues in other
cases.)

Includes a minor merge fix by Mark Thompson, and

avconv: Move rescale to stream timebase before monotonisation

also by Mark Thompson .

Signed-off-by: wm4 
---
 ffmpeg.c | 47 +
 ffmpeg.h |  2 +
 tests/ref/fate/binsub-movtextenc |  2 +-
 tests/ref/fate/sub2video | 88 
 4 files changed, 76 insertions(+), 63 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 5adec2b290..a617fbbca9 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -713,10 +713,12 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost)
 if (pkt->duration > 0)
 av_log(NULL, AV_LOG_WARNING, "Overriding packet duration by 
frame rate, this should not happen\n");
 pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
- ost->st->time_base);
+ ost->mux_timebase);
 }
 }
 
+av_packet_rescale_ts(pkt, ost->mux_timebase, ost->st->time_base);
+
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
 if (pkt->dts != AV_NOPTS_VALUE &&
 pkt->pts != AV_NOPTS_VALUE &&
@@ -907,13 +909,13 @@ static void do_audio_out(OutputFile *of, OutputStream 
*ost,
 
 update_benchmark("encode_audio %d.%d", ost->file_index, ost->index);
 
-av_packet_rescale_ts(, enc->time_base, ost->st->time_base);
+av_packet_rescale_ts(, enc->time_base, ost->mux_timebase);
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:audio "
"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s\n",
-   av_ts2str(pkt.pts), av_ts2timestr(pkt.pts, 
>st->time_base),
-   av_ts2str(pkt.dts), av_ts2timestr(pkt.dts, 
>st->time_base));
+   av_ts2str(pkt.pts), av_ts2timestr(pkt.pts, >time_base),
+   av_ts2str(pkt.dts), av_ts2timestr(pkt.dts, 
>time_base));
 }
 
 output_packet(of, , ost);
@@ -993,8 +995,8 @@ static void do_subtitle_out(OutputFile *of,
 av_init_packet();
 pkt.data = subtitle_out;
 pkt.size = subtitle_out_size;
-pkt.pts  = av_rescale_q(sub->pts, AV_TIME_BASE_Q, ost->st->time_base);
-pkt.duration = av_rescale_q(sub->end_display_time, (AVRational){ 1, 
1000 }, ost->st->time_base);
+pkt.pts  = av_rescale_q(sub->pts, AV_TIME_BASE_Q, ost->mux_timebase);
+pkt.duration = av_rescale_q(sub->end_display_time, (AVRational){ 1, 
1000 }, ost->mux_timebase);
 if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE) {
 /* XXX: the pts correction is handled here. Maybe handling
it in the codec would be better */
@@ -1187,7 +1189,7 @@ static void do_video_out(OutputFile *of,
 mux_par->field_order = AV_FIELD_PROGRESSIVE;
 pkt.data   = (uint8_t *)in_picture;
 pkt.size   =  sizeof(AVPicture);
-pkt.pts= av_rescale_q(in_picture->pts, enc->time_base, 
ost->st->time_base);
+pkt.pts= av_rescale_q(in_picture->pts, enc->time_base, 
ost->mux_timebase);
 pkt.flags |= AV_PKT_FLAG_KEY;
 
 output_packet(of, , ost);
@@ -1283,13 +1285,13 @@ static void do_video_out(OutputFile *of,
 if (pkt.pts == AV_NOPTS_VALUE && !(enc->codec->capabilities & 
AV_CODEC_CAP_DELAY))
 pkt.pts = ost->sync_opts;
 
-av_packet_rescale_ts(, enc->time_base, ost->st->time_base);
+av_packet_rescale_ts(, enc->time_base, ost->mux_timebase);
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:video "
 "pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s\n",
-av_ts2str(pkt.pts), av_ts2timestr(pkt.pts, 
>st->time_base),
-av_ts2str(pkt.dts), av_ts2timestr(pkt.dts, 
>st->time_base));
+av_ts2str(pkt.pts), av_ts2timestr(pkt.pts, 
>mux_timebase),
+av_ts2str(pkt.dts), av_ts2timestr(pkt.dts, 
>mux_timebase));
 }
 
 frame_size = pkt.size;
@@ -1862,7 +1864,7 @@ static void

[FFmpeg-devel] [PATCH v3 4/7] ffmpeg: fix printing of filter input/output names

2017-03-02 Thread wm4

Broken by the previous Libav commit (even in Libav, thus a separate
commit).

Signed-off-by: wm4 
---
 ffmpeg_filter.c | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 8490f4a455..f21a8c85f8 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -230,6 +230,25 @@ int init_simple_filtergraph(InputStream *ist, OutputStream 
*ost)
 return 0;
 }
 
+static char *describe_filter_link(FilterGraph *fg, AVFilterInOut *inout, int 
in)
+{
+AVFilterContext *ctx = inout->filter_ctx;
+AVFilterPad *pads = in ? ctx->input_pads  : ctx->output_pads;
+int   nb_pads = in ? ctx->nb_inputs   : ctx->nb_outputs;
+AVIOContext *pb;
+uint8_t *res = NULL;
+
+if (avio_open_dyn_buf() < 0)
+exit_program(1);
+
+avio_printf(pb, "%s", ctx->filter->name);
+if (nb_pads > 1)
+avio_printf(pb, ":%s", avfilter_pad_get_name(pads, inout->pad_idx));
+avio_w8(pb, 0);
+avio_close_dyn_buf(pb, );
+return res;
+}
+
 static void init_input_filter(FilterGraph *fg, AVFilterInOut *in)
 {
 InputStream *ist = NULL;
@@ -300,6 +319,7 @@ static void init_input_filter(FilterGraph *fg, 
AVFilterInOut *in)
 fg->inputs[fg->nb_inputs - 1]->graph = fg;
 fg->inputs[fg->nb_inputs - 1]->format = -1;
 fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
+fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
 
 fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 * 
sizeof(AVFrame*));
 if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
@@ -338,6 +358,7 @@ int init_complex_filtergraph(FilterGraph *fg)
 fg->outputs[fg->nb_outputs - 1]->out_tmp = cur;
 fg->outputs[fg->nb_outputs - 1]->type= 
avfilter_pad_get_type(cur->filter_ctx->output_pads,
  
cur->pad_idx);
+fg->outputs[fg->nb_outputs - 1]->name = describe_filter_link(fg, cur, 
0);
 cur = cur->next;
 fg->outputs[fg->nb_outputs - 1]->out_tmp->next = NULL;
 }
@@ -643,28 +664,8 @@ static int configure_output_audio_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 return 0;
 }
 
-#define DESCRIBE_FILTER_LINK(f, inout, in) \
-{  \
-AVFilterContext *ctx = inout->filter_ctx;  \
-AVFilterPad *pads = in ? ctx->input_pads  : ctx->output_pads;  \
-int   nb_pads = in ? ctx->nb_inputs   : ctx->nb_outputs;   \
-AVIOContext *pb;   \
-   \
-if (avio_open_dyn_buf() < 0)\
-exit_program(1);   \
-   \
-avio_printf(pb, "%s", ctx->filter->name);  \
-if (nb_pads > 1)   \
-avio_printf(pb, ":%s", avfilter_pad_get_name(pads, inout->pad_idx));\
-avio_w8(pb, 0);\
-avio_close_dyn_buf(pb, >name);  \
-}
-
 int configure_output_filter(FilterGraph *fg, OutputFilter *ofilter, 
AVFilterInOut *out)
 {
-av_freep(>name);
-DESCRIBE_FILTER_LINK(ofilter, out, 0);
-
 if (!ofilter->ost) {
 av_log(NULL, AV_LOG_FATAL, "Filter %s has an unconnected output\n", 
ofilter->name);
 exit_program(1);
@@ -970,9 +971,6 @@ static int configure_input_audio_filter(FilterGraph *fg, 
InputFilter *ifilter,
 static int configure_input_filter(FilterGraph *fg, InputFilter *ifilter,
   AVFilterInOut *in)
 {
-av_freep(>name);
-DESCRIBE_FILTER_LINK(ifilter, in, 1);
-
 if (!ifilter->ist->dec) {
 av_log(NULL, AV_LOG_ERROR,
"No decoder for stream #%d:%d, filtering impossible\n",
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-02 Thread wm4

These patches merge the previously skipped Libav commits, which made
avconv lazily initialize libavfilter graphs. This means the filters
are initialized with the actual output format, instead of whatever
libavformat reports.

It's a prerequisite to making hardware decoding support saner, as
hardware decoders will output a different pixfmt than the software
format reported by libavformat. This can be seen on ffmpeg_qsv.c
and ffmpeg_cuvid.c, which don't lose any functionality, even though
half of the code is removed.

There are some differences in how ffmpeg.c and avconv.c filter-flow
works. Also, avconv.c doesn't have sub2video. Relatively intrusive
changes were required.

I will push this tomorrow, except if critical failures are found.

Anton Khirnov (4):
  ffmpeg: do packet ts rescaling in write_packet()
  ffmpeg: init filtergraphs only after we have a frame on each input
  ffmpeg: move flushing the queued frames to configure_filtergraph()
  ffmpeg: restructure sending EOF to filters

Timo Rothenpieler (1):
  ffmpeg_cuvid: adapt for recent filter graph initialization changes

wm4 (2):
  ffmpeg: make sure packets put into the muxing FIFO are refcounted
  ffmpeg: fix printing of filter input/output names

 doc/libav-merge.txt|   1 -
 ffmpeg.c   | 409 +
 ffmpeg.h   |  22 +-
 ffmpeg_cuvid.c | 142 ++-
 ffmpeg_filter.c| 112 +++---
 ffmpeg_opt.c   |  44 ---
 ffmpeg_qsv.c   |  82 -
 tests/ref/fate/binsub-movtextenc   |   2 +-
 .../fate/exr-rgb-scanline-pxr24-half-uint32-13x9   |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-12x8-l1  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-12x8-l2  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-13x9-l1  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-13x9-l2  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-12x8-l1 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-12x8-l2 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-13x9-l1 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-13x9-l2 |   2 +-
 tests/ref/fate/sub2video   |  88 ++---
 tests/ref/fate/vp8-size-change |  62 ++--
 tests/ref/lavf/ffm |   2 +-
 tests/ref/lavf/mxf |   6 +-
 21 files changed, 442 insertions(+), 548 deletions(-)

-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 3/7] ffmpeg: init filtergraphs only after we have a frame on each input

2017-03-02 Thread wm4

From: Anton Khirnov 

This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.

This merges Libav commit a3a0230. It was previously skipped.

The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.

The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.

The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.

The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.

Signed-off-by: wm4 
---
 ffmpeg.c   | 338 +
 ffmpeg.h   |  17 +-
 ffmpeg_cuvid.c |   1 -
 ffmpeg_filter.c|  48 +--
 ffmpeg_opt.c   |  44 ---
 ffmpeg_qsv.c   |  82 -
 .../fate/exr-rgb-scanline-pxr24-half-uint32-13x9   |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-12x8-l1  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-12x8-l2  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-13x9-l1  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44-13x9-l2  |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-12x8-l1 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-12x8-l2 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-13x9-l1 |   2 +-
 .../fate/exr-rgba-scanline-float-half-b44a-13x9-l2 |   2 +-
 tests/ref/fate/vp8-size-change |  62 ++--
 tests/ref/lavf/ffm |   2 +-
 tests/ref/lavf/mxf |   6 +-
 18 files changed, 281 insertions(+), 337 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index a617fbbca9..2f6eed7d78 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -123,6 +123,7 @@ const char *const forced_keyframes_const_names[] = {
 static void do_video_stats(OutputStream *ost, int frame_size);
 static int64_t getutime(void);
 static int64_t getmaxrss(void);
+static int ifilter_has_all_input_formats(FilterGraph *fg);
 
 static int run_as_daemon  = 0;
 static int nb_frames_dup = 0;
@@ -472,6 +473,13 @@ static void ffmpeg_cleanup(int ret)
 FilterGraph *fg = filtergraphs[i];
 avfilter_graph_free(>graph);
 for (j = 0; j < fg->nb_inputs; j++) {
+while (av_fifo_size(fg->inputs[j]->frame_queue)) {
+AVFrame *frame;
+av_fifo_generic_read(fg->inputs[j]->frame_queue, ,
+ sizeof(frame), NULL);
+av_frame_free();
+}
+av_fifo_free(fg->inputs[j]->frame_queue);
 av_buffer_unref(>inputs[j]->hw_frames_ctx);
 av_freep(>inputs[j]->name);
 av_freep(>inputs[j]);
@@ -1377,6 +1385,8 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
 }
 }
 
+static int init_output_stream(OutputStream *ost, char *error, int error_len);
+
 static void finish_output_stream(OutputStream *ost)
 {
 OutputFile *of = output_files[ost->file_index];
@@ -1409,10 +1419,20 @@ static int reap_filters(int flush)
 AVCodecContext *enc = ost->enc_ctx;
 int ret = 0;
 
-if (!ost->filter)
+if (!ost->filter || !ost->filter->graph->graph)
 continue;
 filter = ost->filter->filter;
 
+if (!ost->initialized) {
+char error[1024];
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error initializing output stream 
%d:%d -- %s\n",
+   ost->file_index, ost->index, error);
+exit_program(1);
+}
+}
+
 if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
 return AVERROR(ENOMEM);
 }
@@ -1813,6 +1833,54 @@ static void flush_encoders(void)
 if (!ost->encoding_needed)
 continue;
 
+// Try to enable encoding with no input frames.
+// Maybe we should just let encoding fail instead.
+if (!ost->initialized) {
+FilterGraph *fg = ost->filter->graph;
+char error[1024];
+
+av_log(NULL, AV_LOG_WARNING,
+   "Finishing stream %d:%d without any data written to it.\n",
+   ost->file_index,

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Carl Eugen Hoyos

2017-03-02 0:26 GMT+01:00 James Almer :
> On 3/1/2017 7:18 PM, Carl Eugen Hoyos wrote:

>>> This doesn't consider the CodecPrivate contents for FFV1 v3
>>> and above. It's only valid for v1 and v2.
>>
>> Is this comment meant for the muxer or the demuxer part?
>>
>> How can I reproduce the issue you see?
>> For me, everything works as specified for default strictness.
>
> Ah, i see there's generic code to read and write CodecPrivate elements
> to and from raw extradata for native codecids where no special handling
> is required.
>
> In any case, the spec says
>
> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
>
> The ffv1 encoder creates extradata for v2 and newer, so the muxer
> should have a custom case for ffv1 in order to detect v2 streams and
> avoid writing said extradata.

Since this behaviour can only be produced with non-strict, I don't
think it is of much relevance.
Anyway, this is removed from the current patch.

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

Re: [FFmpeg-devel] [PATCH]lavf/flacdec: Return maximum score if a valid streaminfo header was found

2017-03-02 Thread Carl Eugen Hoyos

2017-03-02 3:09 GMT+01:00 Michael Niedermayer :
> On Wed, Mar 01, 2017 at 09:38:58AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I implemented this patch to fix ticket #6208 but it turned out the flac probe
>> function wasn't the issue. Still looks like a good idea to me.
>>
>> Please comment, Carl Eugen
>
>>  flacdec.c |9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>> 64259ee8c398e244db4174257a3f1bbad6160ca7  
>> 0001-lavf-flacdec-Return-maximum-score-if-the-streaminfo-.patch
>> From acc7558a3585d99776523ed670747597c4de99fb Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 1 Mar 2017 09:34:37 +0100
>> Subject: [PATCH 1/2] lavf/flacdec: Return maximum score if the streaminfo
>>  header is valid.
>>
>> ---
>>  libavformat/flacdec.c |9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> if this works with all flac files you have then its probably ok
> but i wouldnt be surprised if some of this will need to be tuned
> based on future tickets

Committed a variant that does not change behaviour for files
with an invalid streaminfo header (and better matches the commit
message).

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

81 matches

Mail list logo