Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 9:01 AM, Hendrik Leppkes  wrote:
> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
>  wrote:
>> This fixes a API regression
>> Probably fixes Ticket5451
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavformat/utils.c   |4 ++--
>>  libavformat/version.h |2 +-
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index ac056c4..7ca0a12 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>  av_codec_set_lowres(st->codec, 
>> av_codec_get_lowres(st->internal->avctx));
>>  st->codec->width = st->internal->avctx->width;
>>  st->codec->height = st->internal->avctx->height;
>> -st->codec->coded_width = st->internal->avctx->coded_width;
>> -st->codec->coded_height = st->internal->avctx->coded_height;
>>  }
>>
>>  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
>> @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>  }
>>
>>  // Fields unavailable in AVCodecParameters
>> +st->codec->coded_width = st->internal->avctx->coded_width;
>> +st->codec->coded_height = st->internal->avctx->coded_height;
>>  st->codec->properties = st->internal->avctx->properties;
>>  FF_ENABLE_DEPRECATION_WARNINGS
>>  #endif
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index c92a23f..2f79b7f 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -29,7 +29,7 @@
>>
>>  #include "libavutil/version.h"
>>
>> -// When bumping major check Ticket5467, 5421 for regressing
>> +// When bumping major check Ticket5467, 5421, 5451 for regressing
>>  // Also please add any ticket numbers that you belive might regress here
>>  #define LIBAVFORMAT_VERSION_MAJOR  57
>>  #define LIBAVFORMAT_VERSION_MINOR  37
>> --
>> 1.7.9.5
>
> The ticket in question accesses st->codec to get this field. st->codec
> is going away, so there is no point in testing this "regression",
> since they need to update their API usage first for it to even
> compile.
> Heck the same thing applies to the other tickets you listed here, all
> of those access information from st->codec which is going away
> entirely, so you can't really "test" these cases. Someone would have
> to update the code to use codecpar first, and while doing this
> migration they would need to preserve whatever behavior exists today.
>


What I forgot to write, patch is otherwise fine, exporting information
into st->codec that was previously available to avoid regressions for
people that still use st->codec is OK.

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

[FFmpeg-devel] [PATCH] lavf/os_support.h: Fix for unicode filenames on windows.

[Matt Oliver]

Fixes #819 #5256 #5281
---
 libavformat/file.c   |  4 
 libavformat/os_support.h | 24 
 2 files changed, 28 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 5765ce7..264542a 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
 ret |= AVIO_FLAG_WRITE;
 #else
 struct stat st;
+#   ifndef _WIN32
 ret = stat(filename, &st);
+#   else
+ret = win32_stat(filename, &st);
+#   endif
 if (ret < 0)
 return AVERROR(errno);

diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index a332911..9e312a5 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
 DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
 DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)

+#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
+static inline int win32_##name(const char *filename_utf8, partype par) \
+{ \
+wchar_t *filename_w;  \
+int ret;  \
+  \
+if (utf8towchar(filename_utf8, &filename_w))  \
+return -1;\
+if (!filename_w)  \
+goto fallback;\
+  \
+ret = wfunc(filename_w, par); \
+av_free(filename_w);  \
+return ret;   \
+  \
+fallback: \
+/* filename may be be in CP_ACP */\
+return afunc(filename_utf8, par); \
+}
+
+DEF_FS_FUNCTION2(access, _waccess, _access, int)
+DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
+
 static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
 {
 wchar_t *src_w, *dest_w;
@@ -231,6 +254,7 @@ fallback:
 #define rename  win32_rename
 #define rmdir   win32_rmdir
 #define unlink  win32_unlink
+#define access  win32_access

 #endif

-- 
2.8.1.windows.1


lavf-os_support.h-Fix-for-unidocde-filenames-on-wind.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Hendrik Leppkes]

On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
 wrote:
> This fixes a API regression
> Probably fixes Ticket5451
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c   |4 ++--
>  libavformat/version.h |2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index ac056c4..7ca0a12 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  av_codec_set_lowres(st->codec, 
> av_codec_get_lowres(st->internal->avctx));
>  st->codec->width = st->internal->avctx->width;
>  st->codec->height = st->internal->avctx->height;
> -st->codec->coded_width = st->internal->avctx->coded_width;
> -st->codec->coded_height = st->internal->avctx->coded_height;
>  }
>
>  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
> @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  }
>
>  // Fields unavailable in AVCodecParameters
> +st->codec->coded_width = st->internal->avctx->coded_width;
> +st->codec->coded_height = st->internal->avctx->coded_height;
>  st->codec->properties = st->internal->avctx->properties;
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
> diff --git a/libavformat/version.h b/libavformat/version.h
> index c92a23f..2f79b7f 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -29,7 +29,7 @@
>
>  #include "libavutil/version.h"
>
> -// When bumping major check Ticket5467, 5421 for regressing
> +// When bumping major check Ticket5467, 5421, 5451 for regressing
>  // Also please add any ticket numbers that you belive might regress here
>  #define LIBAVFORMAT_VERSION_MAJOR  57
>  #define LIBAVFORMAT_VERSION_MINOR  37
> --
> 1.7.9.5

The ticket in question accesses st->codec to get this field. st->codec
is going away, so there is no point in testing this "regression",
since they need to update their API usage first for it to even
compile.
Heck the same thing applies to the other tickets you listed here, all
of those access information from st->codec which is going away
entirely, so you can't really "test" these cases. Someone would have
to update the code to use codecpar first, and while doing this
migration they would need to preserve whatever behavior exists today.

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

[FFmpeg-devel] [PATCH] lavu/intmath.h: fix compilation with msvc10.

[Matt Oliver]

---
 libavutil/x86/intmath.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index f58b0d0..de177dd 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -47,6 +47,7 @@ static av_always_inline av_const int ff_log2_x86(unsigned
int v)
 #   endif
 #   define ff_log2_16bit av_log2

+#if defined(_MSC_VER) && (_MSC_VER >= 1700)
 #   define ff_ctz(v) _tzcnt_u32(v)

 #   if ARCH_X86_64
@@ -58,6 +59,7 @@ static av_always_inline av_const int ff_ctzll_x86(long
long v)
 return ((uint32_t)v == 0) ? _tzcnt_u32((uint32_t)(v >> 32)) + 32 :
_tzcnt_u32((uint32_t)v);
 }
 #   endif
+#endif /* _MSC_VER */

 #endif /* __INTEL_COMPILER */

--


lavu-intmath.h-fix-compilation-with-msvc10.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodec: bypass width/height restrictions when looking for a decoder

[Matthieu Bouron]

On Tue, May 31, 2016 at 05:41:16PM +0200, Matthieu Bouron wrote:
> On Tue, May 31, 2016 at 03:51:20PM +0200, Matthieu Bouron wrote:
> > On Tue, May 31, 2016 at 03:35:49PM +0200, Hendrik Leppkes wrote:
> > > On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
> > >  wrote:
> > > > From: Matthieu Bouron 
> > > >
> > > > Codec width/height restrictions seem hardcoded at the OMX level and
> > > > seem arbitrary. Bypassing those restrictions allows a device to decode
> > > > streams at higher resolutions.
> > > >
> > > > For example it allows a Nexus 5 to decode h264 streams with a resolution
> > > > higher than 1920x1080.
> > > 
> > > 
> > > What happens if the resolution actually exceeds the devices capabilities?
> > 
> > The patch has been tested on various devices and it has been working so
> > far. When the resolution actually exceeds the device capabilities the
> > codec just fails to configure itself.
> > 
> > However I did not try to craft samples with really high resolutions (higher
> > than ~4K) to test the patch against.
> > 
> > I will double check what is happening with both SW output and surface
> > output.
> 
> I tested on a bunch of devices with different chipsets and they all fail at
> the configuration step.
> 

If there is no objection, I will push the patchset in one day.

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

[FFmpeg-devel] [PATCH] lavc/mediacodec: improve error messages

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libavcodec/mediacodecdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 712f984..676ade7 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -198,7 +198,7 @@ static int mediacodec_wrap_buffer(AVCodecContext *avctx,
 done:
 status = ff_AMediaCodec_releaseOutputBuffer(s->codec, index, 0);
 if (status < 0) {
-av_log(NULL, AV_LOG_ERROR, "Failed to release output buffer\n");
+av_log(avctx, AV_LOG_ERROR, "Failed to release output buffer\n");
 ret = AVERROR_EXTERNAL;
 }
 
@@ -539,7 +539,7 @@ int ff_mediacodec_dec_flush(AVCodecContext *avctx, 
MediaCodecDecContext *s)
 
 status = ff_AMediaCodec_flush(codec);
 if (status < 0) {
-av_log(NULL, AV_LOG_ERROR, "Failed to flush MediaCodec %p", codec);
+av_log(avctx, AV_LOG_ERROR, "Failed to flush codec\n");
 return AVERROR_EXTERNAL;
 }
 
-- 
2.8.3

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

Re: [FFmpeg-devel] FFmpeg 3.1

[Matthieu Bouron]

On Mon, Jun 06, 2016 at 03:28:19AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> its time for making the next major release
> If you want something in dont forget to push it to git master

I'd like to have the 3 pending MediaCodec patches merged before the
release.
I'll re-send to the ml the MediaCodec hwaccel patch after the release.

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

Re: [FFmpeg-devel] [PATCH 0/5] avutil/qsv add hwcontext_qsv

[nablet developer]

ping. any feedback?

> On 25 May 2016, at 19:20, nablet developer  wrote:
> 
> added hwcontext_qsv (Intel QuickSync video)
> it will handle MFX session initialization and deinitialization,
> and will allow to share that code between libavcodec and libavfilter
> without adding new API calls for QSV, and also using similar approach
> to CUDA & VAAPI
> (VPP filter patch is postponded with suggestion to implementa hwcontext_qsv)
> 
> nablet developer (5):
>  avutil/qsv: move ff_qsv_error function from libavcodec into libavutil,
>because it's going to be shared between libavcodec (existing QSV
>encoders & decoders), libavfilter (upcoming QSV VPP filter) and
>libavutil itself (upcoming hwcontext_qsv implementation). prefix
>changed to avpriv since it's now shared between multiple libraries.
>  avutil/qsv: add hwcontext_qsv (QuickSync Video)
>  avcodec/qsvdec: use hwcontext_qsv instead of
>ff_qsv_init_internal_session
>  avcodec/qsvenc: use hwcontext_qsv instead of
>ff_qsv_init_internal_session
>  avcodec/qsv: remove no longer needed functions
>ff_qsv_init_internal_session & ff_qsv_close_internal_session,
>structure QSVSession, since they are now replaced by
>avutil/hwcontext_qsv
> 
> libavcodec/qsv.c   | 221 +--
> libavcodec/qsv_internal.h  |  35 --
> libavcodec/qsvdec.c|  36 --
> libavcodec/qsvdec.h|   4 +-
> libavcodec/qsvenc.c|  40 +--
> libavcodec/qsvenc.h|   3 +-
> libavutil/Makefile |   4 +
> libavutil/hwcontext.c  |   3 +
> libavutil/hwcontext.h  |   1 +
> libavutil/hwcontext_internal.h |   1 +
> libavutil/hwcontext_qsv.c  | 255 +
> libavutil/hwcontext_qsv.h  |  45 
> libavutil/qsv_internal.c   |  58 ++
> libavutil/qsv_internal.h   |  27 +
> 14 files changed, 452 insertions(+), 281 deletions(-)
> create mode 100644 libavutil/hwcontext_qsv.c
> create mode 100644 libavutil/hwcontext_qsv.h
> create mode 100644 libavutil/qsv_internal.c
> create mode 100644 libavutil/qsv_internal.h
> 
> -- 
> 1.8.3.1
> 
> ___
> 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/os_support.h: Fix for unicode filenames on windows.

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver  wrote:
> Fixes #819 #5256 #5281
> ---
>  libavformat/file.c   |  4 
>  libavformat/os_support.h | 24 
>  2 files changed, 28 insertions(+)
>
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 5765ce7..264542a 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
>  ret |= AVIO_FLAG_WRITE;
>  #else
>  struct stat st;
> +#   ifndef _WIN32
>  ret = stat(filename, &st);
> +#   else
> +ret = win32_stat(filename, &st);
> +#   endif

Isn't the typical way to define stat to win32_stat in the os_support
header, instead of ifdefing here?

>  if (ret < 0)
>  return AVERROR(errno);
>
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> index a332911..9e312a5 100644
> --- a/libavformat/os_support.h
> +++ b/libavformat/os_support.h
> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
>  DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
>  DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)
>
> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> +static inline int win32_##name(const char *filename_utf8, partype par) \
> +{ \
> +wchar_t *filename_w;  \
> +int ret;  \
> +  \
> +if (utf8towchar(filename_utf8, &filename_w))  \
> +return -1;\
> +if (!filename_w)  \
> +goto fallback;\
> +  \
> +ret = wfunc(filename_w, par); \
> +av_free(filename_w);  \
> +return ret;   \
> +  \
> +fallback: \
> +/* filename may be be in CP_ACP */\
> +return afunc(filename_utf8, par); \
> +}
> +
> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> +
>  static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
>  {
>  wchar_t *src_w, *dest_w;
> @@ -231,6 +254,7 @@ fallback:
>  #define rename  win32_rename
>  #define rmdir   win32_rmdir
>  #define unlink  win32_unlink
> +#define access  win32_access
>
>  #endif
>
> --
> 2.8.1.windows.1
>
> ___
> 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 2/2] lavc/mediacodec: bypass width/height restrictions when looking for a decoder

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 9:54 AM, Matthieu Bouron
 wrote:
> On Tue, May 31, 2016 at 05:41:16PM +0200, Matthieu Bouron wrote:
>> On Tue, May 31, 2016 at 03:51:20PM +0200, Matthieu Bouron wrote:
>> > On Tue, May 31, 2016 at 03:35:49PM +0200, Hendrik Leppkes wrote:
>> > > On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
>> > >  wrote:
>> > > > From: Matthieu Bouron 
>> > > >
>> > > > Codec width/height restrictions seem hardcoded at the OMX level and
>> > > > seem arbitrary. Bypassing those restrictions allows a device to decode
>> > > > streams at higher resolutions.
>> > > >
>> > > > For example it allows a Nexus 5 to decode h264 streams with a 
>> > > > resolution
>> > > > higher than 1920x1080.
>> > >
>> > >
>> > > What happens if the resolution actually exceeds the devices capabilities?
>> >
>> > The patch has been tested on various devices and it has been working so
>> > far. When the resolution actually exceeds the device capabilities the
>> > codec just fails to configure itself.
>> >
>> > However I did not try to craft samples with really high resolutions (higher
>> > than ~4K) to test the patch against.
>> >
>> > I will double check what is happening with both SW output and surface
>> > output.
>>
>> I tested on a bunch of devices with different chipsets and they all fail at
>> the configuration step.
>>
>
> If there is no objection, I will push the patchset in one day.
>

If you have confirmed that it still fails gracefully but accepts more
streams, then LGTM.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

[Andrey Turkin]

2016-06-05 21:58 GMT+03:00 Timo Rothenpieler :

> +
> +avctx->width = format->coded_width;
> +avctx->height = format->coded_height;
> +
>

This patch seems to mix bitstream picture dimensions and output picture
dimensions in several places. Can you test if the decoder works with input
video of "strange" size (say, 325x243)?

+hwframe_ctx->format = AV_PIX_FMT_CUDA;
> +hwframe_ctx->sw_format = AV_PIX_FMT_NV12;
> +hwframe_ctx->width = FFALIGN(cuinfo.ulTargetWidth, 16);
> +hwframe_ctx->height = FFALIGN(cuinfo.ulTargetHeight, 16);
>

NVENC aligns to 32 (I think hevc requires this sometimes); maybe use same
here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.1

[Timo Rothenpieler]

I'd like to merge the cuvid decoder/hwaccel for 3.1.



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

Re: [FFmpeg-devel] [PATCH 0/5] avutil/qsv add hwcontext_qsv

[Mark Thompson]

On 06/06/16 09:25, nablet developer wrote:
> ping. any feedback?

Perhaps you could comment on the merits and functionality of your version as
compared with the one here
 (with
associated series) posted at roughly the same time?

Obviously they collide, which is somewhat unfortunate.  The libav one looks more
complete to me (hwframe support with surface upload and download, notably), but
I am not a libmfx expert so there might be something significant that I have 
missed.

- Mark


>> On 25 May 2016, at 19:20, nablet developer  wrote:
>>
>> added hwcontext_qsv (Intel QuickSync video)
>> it will handle MFX session initialization and deinitialization,
>> and will allow to share that code between libavcodec and libavfilter
>> without adding new API calls for QSV, and also using similar approach
>> to CUDA & VAAPI
>> (VPP filter patch is postponded with suggestion to implementa hwcontext_qsv)
>>
>> nablet developer (5):
>>  avutil/qsv: move ff_qsv_error function from libavcodec into libavutil,
>>because it's going to be shared between libavcodec (existing QSV
>>encoders & decoders), libavfilter (upcoming QSV VPP filter) and
>>libavutil itself (upcoming hwcontext_qsv implementation). prefix
>>changed to avpriv since it's now shared between multiple libraries.
>>  avutil/qsv: add hwcontext_qsv (QuickSync Video)
>>  avcodec/qsvdec: use hwcontext_qsv instead of
>>ff_qsv_init_internal_session
>>  avcodec/qsvenc: use hwcontext_qsv instead of
>>ff_qsv_init_internal_session
>>  avcodec/qsv: remove no longer needed functions
>>ff_qsv_init_internal_session & ff_qsv_close_internal_session,
>>structure QSVSession, since they are now replaced by
>>avutil/hwcontext_qsv
>>
>> libavcodec/qsv.c   | 221 +--
>> libavcodec/qsv_internal.h  |  35 --
>> libavcodec/qsvdec.c|  36 --
>> libavcodec/qsvdec.h|   4 +-
>> libavcodec/qsvenc.c|  40 +--
>> libavcodec/qsvenc.h|   3 +-
>> libavutil/Makefile |   4 +
>> libavutil/hwcontext.c  |   3 +
>> libavutil/hwcontext.h  |   1 +
>> libavutil/hwcontext_internal.h |   1 +
>> libavutil/hwcontext_qsv.c  | 255 
>> +
>> libavutil/hwcontext_qsv.h  |  45 
>> libavutil/qsv_internal.c   |  58 ++
>> libavutil/qsv_internal.h   |  27 +
>> 14 files changed, 452 insertions(+), 281 deletions(-)
>> create mode 100644 libavutil/hwcontext_qsv.c
>> create mode 100644 libavutil/hwcontext_qsv.h
>> create mode 100644 libavutil/qsv_internal.c
>> create mode 100644 libavutil/qsv_internal.h
>>
>> -- 
>> 1.8.3.1

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodec: bypass width/height restrictions when looking for a decoder

[Matthieu Bouron]

On Mon, Jun 06, 2016 at 11:29:03AM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 6, 2016 at 9:54 AM, Matthieu Bouron
>  wrote:
> > On Tue, May 31, 2016 at 05:41:16PM +0200, Matthieu Bouron wrote:
> >> On Tue, May 31, 2016 at 03:51:20PM +0200, Matthieu Bouron wrote:
> >> > On Tue, May 31, 2016 at 03:35:49PM +0200, Hendrik Leppkes wrote:
> >> > > On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
> >> > >  wrote:
> >> > > > From: Matthieu Bouron 
> >> > > >
> >> > > > Codec width/height restrictions seem hardcoded at the OMX level and
> >> > > > seem arbitrary. Bypassing those restrictions allows a device to 
> >> > > > decode
> >> > > > streams at higher resolutions.
> >> > > >
> >> > > > For example it allows a Nexus 5 to decode h264 streams with a 
> >> > > > resolution
> >> > > > higher than 1920x1080.
> >> > >
> >> > >
> >> > > What happens if the resolution actually exceeds the devices 
> >> > > capabilities?
> >> >
> >> > The patch has been tested on various devices and it has been working so
> >> > far. When the resolution actually exceeds the device capabilities the
> >> > codec just fails to configure itself.
> >> >
> >> > However I did not try to craft samples with really high resolutions 
> >> > (higher
> >> > than ~4K) to test the patch against.
> >> >
> >> > I will double check what is happening with both SW output and surface
> >> > output.
> >>
> >> I tested on a bunch of devices with different chipsets and they all fail at
> >> the configuration step.
> >>
> >
> > If there is no objection, I will push the patchset in one day.
> >
> 
> If you have confirmed that it still fails gracefully but accepts more
> streams, then LGTM.

Thanks.

I'm working on an another patch to check what profile the codec supports
and fail at init time if the stream profile is too high (currently the
init passes but it fails afterwards while trying to decode frames, which
is annoying if an application wants to do some kind of fallback at init
time).

Matthieu

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

[Hendrik Leppkes]

On Sun, Jun 5, 2016 at 8:58 PM, Timo Rothenpieler  wrote:
> ---
>  Changelog  |   2 +
>  MAINTAINERS|   1 +
>  configure  |  20 ++
>  libavcodec/Makefile|   2 +
>  libavcodec/allcodecs.c |   4 +
>  libavcodec/cuvid.c | 550 
> +
>  libavcodec/version.h   |   4 +-
>  7 files changed, 581 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/cuvid.c
>
> diff --git a/Changelog b/Changelog
> index d5228b2..35e17e5 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -38,6 +38,8 @@ version :
>  - loudnorm filter
>  - MTAF demuxer and decoder
>  - MagicYUV decoder
> +- CUDA CUVID H264/HEVC decoder
> +
>
>  version 3.0:
>  - Common Encryption (CENC) MP4 encoding and decoding support
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ce2524..bf99d0c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -163,6 +163,7 @@ Codecs:
>cpia.cStephan Hilb
>crystalhd.c   Philip Langdale
>cscd.cReimar Doeffinger
> +  cuvid.c   Timo Rothenpieler
>dca.c Kostya Shishkov, Benjamin Larsson
>dirac*Rostislav Pehlivanov
>dnxhd*Baptiste Coudurier
> diff --git a/configure b/configure
> index 7c463a5..2b2d5f8 100755
> --- a/configure
> +++ b/configure
> @@ -158,6 +158,7 @@ Hardware accelerators:
>
>  Hardware-accelerated decoding/encoding:
>--enable-cudaenable dynamically linked CUDA [no]
> +  --enable-cuvid   enable CUVID support [autodetect]
>--enable-libmfx  enable HW acceleration through libmfx
>--enable-mmalenable decoding via MMAL [no]
>--enable-nvenc   enable NVIDIA NVENC support [no]
> @@ -1567,6 +1568,7 @@ FEATURE_LIST="
>
>  HW_CODECS_LIST="
>  cuda
> +cuvid
>  libmfx
>  mmal
>  nvenc
> @@ -2328,6 +2330,7 @@ comfortnoise_encoder_select="lpc"
>  cook_decoder_select="audiodsp mdct sinewin"
>  cscd_decoder_select="lzo"
>  cscd_decoder_suggest="zlib"
> +cuvid_decoder_deps="cuda cuvid"
>  dca_decoder_select="mdct"
>  dds_decoder_select="texturedsp"
>  dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
> @@ -2522,6 +2525,7 @@ audiotoolbox_extralibs="-framework CoreFoundation 
> -framework AudioToolbox -frame
>
>  # hardware accelerators
>  crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
> +cuvid_deps="cuda"
>  d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
>  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode"
>  vaapi_deps="va_va_h"
> @@ -2539,6 +2543,7 @@ h263_vaapi_hwaccel_select="h263_decoder"
>  h263_videotoolbox_hwaccel_deps="videotoolbox"
>  h263_videotoolbox_hwaccel_select="h263_decoder"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
> +h264_cuvid_hwaccel_deps="cuda cuvid"
>  h264_d3d11va_hwaccel_deps="d3d11va"
>  h264_d3d11va_hwaccel_select="h264_decoder"
>  h264_dxva2_hwaccel_deps="dxva2"
> @@ -2564,6 +2569,7 @@ h264_vdpau_hwaccel_deps="vdpau"
>  h264_vdpau_hwaccel_select="h264_decoder"
>  h264_videotoolbox_hwaccel_deps="videotoolbox"
>  h264_videotoolbox_hwaccel_select="h264_decoder"
> +hevc_cuvid_hwaccel_deps="cuda cuvid"
>  hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
>  hevc_d3d11va_hwaccel_select="hevc_decoder"
>  hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
> @@ -2657,6 +2663,8 @@ hwupload_cuda_filter_deps="cuda"
>  scale_npp_filter_deps="cuda libnpp"
>
>  nvenc_encoder_deps="nvenc"
> +h264_cuvid_decoder_deps="cuda cuvid"
> +h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel"
>  h264_qsv_decoder_deps="libmfx"
>  h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
> h264_qsv_hwaccel"
>  h264_qsv_encoder_deps="libmfx"
> @@ -2664,6 +2672,8 @@ h264_qsv_encoder_select="qsvenc"
>  h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="vaapi_encode golomb"
>
> +hevc_cuvid_decoder_deps="cuda cuvid"
> +hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf hevc_cuvid_hwaccel"
>  hevc_qsv_decoder_deps="libmfx"
>  hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
> hevc_qsv_hwaccel"
>  hevc_qsv_encoder_deps="libmfx"
> @@ -5002,6 +5012,7 @@ die_license_disabled gpl libxvid
>  die_license_disabled gpl x11grab
>
>  die_license_disabled nonfree cuda
> +die_license_disabled nonfree cuvid
>  die_license_disabled nonfree libfaac
>  die_license_disabled nonfree libnpp
>  enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
> @@ -5572,6 +5583,11 @@ for func in $COMPLEX_FUNCS; do
>  eval check_complexfunc $func \${${func}_args:-1}
>  done
>
> +# Enable CUVID by default if CUDA is enabled
> +if enabled cuda && ! disabled cuvid; then
> +enable cuvid
> +fi
> +
>  # these are off by default, so fail if requested and not available
>  enabled avfoundation_indev && { chec

Re: [FFmpeg-devel] [PATCH] lavf/os_support.h: Fix for unicode filenames on windows.

[Matt Oliver]

On 6 June 2016 at 19:27, Hendrik Leppkes  wrote:

> On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver  wrote:
> > Fixes #819 #5256 #5281
> > ---
> >  libavformat/file.c   |  4 
> >  libavformat/os_support.h | 24 
> >  2 files changed, 28 insertions(+)
> >
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index 5765ce7..264542a 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> >  ret |= AVIO_FLAG_WRITE;
> >  #else
> >  struct stat st;
> > +#   ifndef _WIN32
> >  ret = stat(filename, &st);
> > +#   else
> > +ret = win32_stat(filename, &st);
> > +#   endif
>
> Isn't the typical way to define stat to win32_stat in the os_support
> header, instead of ifdefing here?
>

No as there is a stat struct type as well as the stat function so a define
cannot be used for the function as it will mess with the stat struct. Hence
why the only way to get around it was to manually call the appropriate
win32 function.


>
> >  if (ret < 0)
> >  return AVERROR(errno);
> >
> > diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> > index a332911..9e312a5 100644
> > --- a/libavformat/os_support.h
> > +++ b/libavformat/os_support.h
> > @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> >  DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
> >  DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)
> >
> > +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> > +static inline int win32_##name(const char *filename_utf8, partype par) \
> > +{ \
> > +wchar_t *filename_w;  \
> > +int ret;  \
> > +  \
> > +if (utf8towchar(filename_utf8, &filename_w))  \
> > +return -1;\
> > +if (!filename_w)  \
> > +goto fallback;\
> > +  \
> > +ret = wfunc(filename_w, par); \
> > +av_free(filename_w);  \
> > +return ret;   \
> > +  \
> > +fallback: \
> > +/* filename may be be in CP_ACP */\
> > +return afunc(filename_utf8, par); \
> > +}
> > +
> > +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> > +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> > +
> >  static inline int win32_rename(const char *src_utf8, const char
> *dest_utf8)
> >  {
> >  wchar_t *src_w, *dest_w;
> > @@ -231,6 +254,7 @@ fallback:
> >  #define rename  win32_rename
> >  #define rmdir   win32_rmdir
> >  #define unlink  win32_unlink
> > +#define access  win32_access
> >
> >  #endif
> >
> > --
> > 2.8.1.windows.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support.h: Fix for unicode filenames on windows.

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 11:34 AM, Matt Oliver  wrote:
> On 6 June 2016 at 19:27, Hendrik Leppkes  wrote:
>
>> On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver  wrote:
>> > Fixes #819 #5256 #5281
>> > ---
>> >  libavformat/file.c   |  4 
>> >  libavformat/os_support.h | 24 
>> >  2 files changed, 28 insertions(+)
>> >
>> > diff --git a/libavformat/file.c b/libavformat/file.c
>> > index 5765ce7..264542a 100644
>> > --- a/libavformat/file.c
>> > +++ b/libavformat/file.c
>> > @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
>> >  ret |= AVIO_FLAG_WRITE;
>> >  #else
>> >  struct stat st;
>> > +#   ifndef _WIN32
>> >  ret = stat(filename, &st);
>> > +#   else
>> > +ret = win32_stat(filename, &st);
>> > +#   endif
>>
>> Isn't the typical way to define stat to win32_stat in the os_support
>> header, instead of ifdefing here?
>>
>
> No as there is a stat struct type as well as the stat function so a define
> cannot be used for the function as it will mess with the stat struct. Hence
> why the only way to get around it was to manually call the appropriate
> win32 function.
>
>

#define stat(a,b) win32_stat(a,b) ?
Wouldn't that avoid a clash with the struct?

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

[Hendrik Leppkes]

On Sun, Jun 5, 2016 at 8:58 PM, Timo Rothenpieler  wrote:
> ---
>  Changelog  |   2 +
>  MAINTAINERS|   1 +
>  configure  |  20 ++
>  libavcodec/Makefile|   2 +
>  libavcodec/allcodecs.c |   4 +
>  libavcodec/cuvid.c | 550 
> +
>  libavcodec/version.h   |   4 +-
>  7 files changed, 581 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/cuvid.c
>
> diff --git a/Changelog b/Changelog
> index d5228b2..35e17e5 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -38,6 +38,8 @@ version :
>  - loudnorm filter
>  - MTAF demuxer and decoder
>  - MagicYUV decoder
> +- CUDA CUVID H264/HEVC decoder
> +
>
>  version 3.0:
>  - Common Encryption (CENC) MP4 encoding and decoding support
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ce2524..bf99d0c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -163,6 +163,7 @@ Codecs:
>cpia.cStephan Hilb
>crystalhd.c   Philip Langdale
>cscd.cReimar Doeffinger
> +  cuvid.c   Timo Rothenpieler
>dca.c Kostya Shishkov, Benjamin Larsson
>dirac*Rostislav Pehlivanov
>dnxhd*Baptiste Coudurier
> diff --git a/configure b/configure
> index 7c463a5..2b2d5f8 100755
> --- a/configure
> +++ b/configure
> @@ -158,6 +158,7 @@ Hardware accelerators:
>
>  Hardware-accelerated decoding/encoding:
>--enable-cudaenable dynamically linked CUDA [no]
> +  --enable-cuvid   enable CUVID support [autodetect]
>--enable-libmfx  enable HW acceleration through libmfx
>--enable-mmalenable decoding via MMAL [no]
>--enable-nvenc   enable NVIDIA NVENC support [no]
> @@ -1567,6 +1568,7 @@ FEATURE_LIST="
>
>  HW_CODECS_LIST="
>  cuda
> +cuvid
>  libmfx
>  mmal
>  nvenc
> @@ -2328,6 +2330,7 @@ comfortnoise_encoder_select="lpc"
>  cook_decoder_select="audiodsp mdct sinewin"
>  cscd_decoder_select="lzo"
>  cscd_decoder_suggest="zlib"
> +cuvid_decoder_deps="cuda cuvid"
>  dca_decoder_select="mdct"
>  dds_decoder_select="texturedsp"
>  dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
> @@ -2522,6 +2525,7 @@ audiotoolbox_extralibs="-framework CoreFoundation 
> -framework AudioToolbox -frame
>
>  # hardware accelerators
>  crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
> +cuvid_deps="cuda"
>  d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
>  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode"
>  vaapi_deps="va_va_h"
> @@ -2539,6 +2543,7 @@ h263_vaapi_hwaccel_select="h263_decoder"
>  h263_videotoolbox_hwaccel_deps="videotoolbox"
>  h263_videotoolbox_hwaccel_select="h263_decoder"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
> +h264_cuvid_hwaccel_deps="cuda cuvid"
>  h264_d3d11va_hwaccel_deps="d3d11va"
>  h264_d3d11va_hwaccel_select="h264_decoder"
>  h264_dxva2_hwaccel_deps="dxva2"
> @@ -2564,6 +2569,7 @@ h264_vdpau_hwaccel_deps="vdpau"
>  h264_vdpau_hwaccel_select="h264_decoder"
>  h264_videotoolbox_hwaccel_deps="videotoolbox"
>  h264_videotoolbox_hwaccel_select="h264_decoder"
> +hevc_cuvid_hwaccel_deps="cuda cuvid"
>  hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
>  hevc_d3d11va_hwaccel_select="hevc_decoder"
>  hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
> @@ -2657,6 +2663,8 @@ hwupload_cuda_filter_deps="cuda"
>  scale_npp_filter_deps="cuda libnpp"
>
>  nvenc_encoder_deps="nvenc"
> +h264_cuvid_decoder_deps="cuda cuvid"
> +h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel"
>  h264_qsv_decoder_deps="libmfx"
>  h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
> h264_qsv_hwaccel"
>  h264_qsv_encoder_deps="libmfx"
> @@ -2664,6 +2672,8 @@ h264_qsv_encoder_select="qsvenc"
>  h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="vaapi_encode golomb"
>
> +hevc_cuvid_decoder_deps="cuda cuvid"
> +hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf hevc_cuvid_hwaccel"
>  hevc_qsv_decoder_deps="libmfx"
>  hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
> hevc_qsv_hwaccel"
>  hevc_qsv_encoder_deps="libmfx"
> @@ -5002,6 +5012,7 @@ die_license_disabled gpl libxvid
>  die_license_disabled gpl x11grab
>
>  die_license_disabled nonfree cuda
> +die_license_disabled nonfree cuvid
>  die_license_disabled nonfree libfaac
>  die_license_disabled nonfree libnpp
>  enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
> @@ -5572,6 +5583,11 @@ for func in $COMPLEX_FUNCS; do
>  eval check_complexfunc $func \${${func}_args:-1}
>  done
>
> +# Enable CUVID by default if CUDA is enabled
> +if enabled cuda && ! disabled cuvid; then
> +enable cuvid
> +fi
> +
>  # these are off by default, so fail if requested and not available
>  enabled avfoundation_indev && { chec

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Add cuvid hwaccel support

[Andrey Turkin]

2016-06-05 21:58 GMT+03:00 Timo Rothenpieler :


> +/* check if the decoder supports CUVID and the output only goes to
> this stream */
> +if (ist->nb_filters || 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;
> +
> +for (i = 0; i < nb_output_streams; i++)
> +if (output_streams[i] != ost && output_streams[i]->source_index
> == ost->source_index)
> +goto cancel;
>

Is it possible to enhance this to support 1-to-N transcoding (usecase
solved by NVidia's patch with nvresize)? One can do the same with complex
filtergraph with several scale_npp instances. This seems like a bit of
over-restriction.

+err = cuInit(0);
> +if (err != CUDA_SUCCESS) {
> +av_log(NULL, AV_LOG_ERROR, "Could not initialize the CUDA driver
> API\n");
> +ret = AVERROR_UNKNOWN;
> +goto error;
> +}
> +
> +err = cuDeviceGet(&device, 0); ///TODO: Make device index configurable
> +if (err != CUDA_SUCCESS) {
> +av_log(NULL, AV_LOG_ERROR, "Could not get the device number
> %d\n", 0);
> +ret = AVERROR_UNKNOWN;
> +goto error;
> +}
> +
> +err = cuCtxCreate(&cuda_ctx, CU_CTX_SCHED_BLOCKING_SYNC, device);
> +if (err != CUDA_SUCCESS) {
> +av_log(NULL, AV_LOG_ERROR, "Error creating a CUDA context\n");
> +ret = AVERROR_UNKNOWN;
> +goto error;
> +}
> +
> +device_ctx = (AVHWDeviceContext*)hw_device_ctx->data;
> +device_ctx->free = cuvid_ctx_free;
> +
> +device_hwctx = device_ctx->hwctx;
> +device_hwctx->cuda_ctx = cuda_ctx;
> +
> +err = cuCtxPopCurrent(&dummy);
> +if (err != CUDA_SUCCESS) {
> +av_log(NULL, AV_LOG_ERROR, "cuCtxPopCurrent failed\n");
> +ret = AVERROR_UNKNOWN;
> +goto error;
> +}
> +


It begs to merge in device_create functionality from libav
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.1

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> If you want something in dont forget to push it to git master

I don't know if is is easily possible but checkasm should be 
disabled for ppc64 (be) in the release branch, not in git master.
This is ticket #5508.


Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

[Hendrik Leppkes]

On Sun, Jun 5, 2016 at 8:58 PM, Timo Rothenpieler  wrote:
> ---
>  Changelog  |   2 +
>  MAINTAINERS|   1 +
>  configure  |  20 ++
>  libavcodec/Makefile|   2 +
>  libavcodec/allcodecs.c |   4 +
>  libavcodec/cuvid.c | 550 
> +
>  libavcodec/version.h   |   4 +-
>  7 files changed, 581 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/cuvid.c
>
> diff --git a/Changelog b/Changelog
> index d5228b2..35e17e5 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -38,6 +38,8 @@ version :
>  - loudnorm filter
>  - MTAF demuxer and decoder
>  - MagicYUV decoder
> +- CUDA CUVID H264/HEVC decoder
> +
>
>  version 3.0:
>  - Common Encryption (CENC) MP4 encoding and decoding support
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ce2524..bf99d0c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -163,6 +163,7 @@ Codecs:
>cpia.cStephan Hilb
>crystalhd.c   Philip Langdale
>cscd.cReimar Doeffinger
> +  cuvid.c   Timo Rothenpieler
>dca.c Kostya Shishkov, Benjamin Larsson
>dirac*Rostislav Pehlivanov
>dnxhd*Baptiste Coudurier
> diff --git a/configure b/configure
> index 7c463a5..2b2d5f8 100755
> --- a/configure
> +++ b/configure
> @@ -158,6 +158,7 @@ Hardware accelerators:
>
>  Hardware-accelerated decoding/encoding:
>--enable-cudaenable dynamically linked CUDA [no]
> +  --enable-cuvid   enable CUVID support [autodetect]
>--enable-libmfx  enable HW acceleration through libmfx
>--enable-mmalenable decoding via MMAL [no]
>--enable-nvenc   enable NVIDIA NVENC support [no]
> @@ -1567,6 +1568,7 @@ FEATURE_LIST="
>
>  HW_CODECS_LIST="
>  cuda
> +cuvid
>  libmfx
>  mmal
>  nvenc
> @@ -2328,6 +2330,7 @@ comfortnoise_encoder_select="lpc"
>  cook_decoder_select="audiodsp mdct sinewin"
>  cscd_decoder_select="lzo"
>  cscd_decoder_suggest="zlib"
> +cuvid_decoder_deps="cuda cuvid"
>  dca_decoder_select="mdct"
>  dds_decoder_select="texturedsp"
>  dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
> @@ -2522,6 +2525,7 @@ audiotoolbox_extralibs="-framework CoreFoundation 
> -framework AudioToolbox -frame
>
>  # hardware accelerators
>  crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
> +cuvid_deps="cuda"
>  d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
>  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode"
>  vaapi_deps="va_va_h"
> @@ -2539,6 +2543,7 @@ h263_vaapi_hwaccel_select="h263_decoder"
>  h263_videotoolbox_hwaccel_deps="videotoolbox"
>  h263_videotoolbox_hwaccel_select="h263_decoder"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
> +h264_cuvid_hwaccel_deps="cuda cuvid"
>  h264_d3d11va_hwaccel_deps="d3d11va"
>  h264_d3d11va_hwaccel_select="h264_decoder"
>  h264_dxva2_hwaccel_deps="dxva2"
> @@ -2564,6 +2569,7 @@ h264_vdpau_hwaccel_deps="vdpau"
>  h264_vdpau_hwaccel_select="h264_decoder"
>  h264_videotoolbox_hwaccel_deps="videotoolbox"
>  h264_videotoolbox_hwaccel_select="h264_decoder"
> +hevc_cuvid_hwaccel_deps="cuda cuvid"
>  hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
>  hevc_d3d11va_hwaccel_select="hevc_decoder"
>  hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
> @@ -2657,6 +2663,8 @@ hwupload_cuda_filter_deps="cuda"
>  scale_npp_filter_deps="cuda libnpp"
>
>  nvenc_encoder_deps="nvenc"
> +h264_cuvid_decoder_deps="cuda cuvid"
> +h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel"
>  h264_qsv_decoder_deps="libmfx"
>  h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
> h264_qsv_hwaccel"
>  h264_qsv_encoder_deps="libmfx"
> @@ -2664,6 +2672,8 @@ h264_qsv_encoder_select="qsvenc"
>  h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="vaapi_encode golomb"
>
> +hevc_cuvid_decoder_deps="cuda cuvid"
> +hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf hevc_cuvid_hwaccel"
>  hevc_qsv_decoder_deps="libmfx"
>  hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
> hevc_qsv_hwaccel"
>  hevc_qsv_encoder_deps="libmfx"
> @@ -5002,6 +5012,7 @@ die_license_disabled gpl libxvid
>  die_license_disabled gpl x11grab
>
>  die_license_disabled nonfree cuda
> +die_license_disabled nonfree cuvid
>  die_license_disabled nonfree libfaac
>  die_license_disabled nonfree libnpp
>  enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
> @@ -5572,6 +5583,11 @@ for func in $COMPLEX_FUNCS; do
>  eval check_complexfunc $func \${${func}_args:-1}
>  done
>
> +# Enable CUVID by default if CUDA is enabled
> +if enabled cuda && ! disabled cuvid; then
> +enable cuvid
> +fi
> +
>  # these are off by default, so fail if requested and not available
>  enabled avfoundation_indev && { chec

Re: [FFmpeg-devel] [PATCH 0/5] avutil/qsv add hwcontext_qsv

[nablet developer]

> On 06 Jun 2016, at 16:40, Mark Thompson  wrote:
> 
> On 06/06/16 09:25, nablet developer wrote:
>> ping. any feedback?
> 
> Perhaps you could comment on the merits and functionality of your version as
> compared with the one here
>  (with
> associated series) posted at roughly the same time?
> 

as I have understood so far, hwcontext in general handles two tasks:
1. context management (context initialisation and cleanup)
2. hardware frame management (initialisation, cleanup and transfer data from/to 
system memory)

patch from libav handles both 1) and 2).
my patches just handle 1) - context management.
frame management can be added as well as additional patch set, that's no 
problem.
for my task (VPP filter) just context management was enough for now.

so yes, changes from libav are more complete in term of feature set.

> Obviously they collide, which is somewhat unfortunate.  The libav one looks 
> more
> complete to me (hwframe support with surface upload and download, notably), 
> but
> I am not a libmfx expert so there might be something significant that I have 
> missed.
> 
> - Mark
> 
> 
>>> On 25 May 2016, at 19:20, nablet developer  wrote:
>>> 
>>> added hwcontext_qsv (Intel QuickSync video)
>>> it will handle MFX session initialization and deinitialization,
>>> and will allow to share that code between libavcodec and libavfilter
>>> without adding new API calls for QSV, and also using similar approach
>>> to CUDA & VAAPI
>>> (VPP filter patch is postponded with suggestion to implementa hwcontext_qsv)
>>> 
>>> nablet developer (5):
>>> avutil/qsv: move ff_qsv_error function from libavcodec into libavutil,
>>>   because it's going to be shared between libavcodec (existing QSV
>>>   encoders & decoders), libavfilter (upcoming QSV VPP filter) and
>>>   libavutil itself (upcoming hwcontext_qsv implementation). prefix
>>>   changed to avpriv since it's now shared between multiple libraries.
>>> avutil/qsv: add hwcontext_qsv (QuickSync Video)
>>> avcodec/qsvdec: use hwcontext_qsv instead of
>>>   ff_qsv_init_internal_session
>>> avcodec/qsvenc: use hwcontext_qsv instead of
>>>   ff_qsv_init_internal_session
>>> avcodec/qsv: remove no longer needed functions
>>>   ff_qsv_init_internal_session & ff_qsv_close_internal_session,
>>>   structure QSVSession, since they are now replaced by
>>>   avutil/hwcontext_qsv
>>> 
>>> libavcodec/qsv.c   | 221 +--
>>> libavcodec/qsv_internal.h  |  35 --
>>> libavcodec/qsvdec.c|  36 --
>>> libavcodec/qsvdec.h|   4 +-
>>> libavcodec/qsvenc.c|  40 +--
>>> libavcodec/qsvenc.h|   3 +-
>>> libavutil/Makefile |   4 +
>>> libavutil/hwcontext.c  |   3 +
>>> libavutil/hwcontext.h  |   1 +
>>> libavutil/hwcontext_internal.h |   1 +
>>> libavutil/hwcontext_qsv.c  | 255 
>>> +
>>> libavutil/hwcontext_qsv.h  |  45 
>>> libavutil/qsv_internal.c   |  58 ++
>>> libavutil/qsv_internal.h   |  27 +
>>> 14 files changed, 452 insertions(+), 281 deletions(-)
>>> create mode 100644 libavutil/hwcontext_qsv.c
>>> create mode 100644 libavutil/hwcontext_qsv.h
>>> create mode 100644 libavutil/qsv_internal.c
>>> create mode 100644 libavutil/qsv_internal.h
>>> 
>>> -- 
>>> 1.8.3.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] FFmpeg 3.1

[pon pon]

hardware decoding dont work in the current git on osx. it is reported on
ticket 5595.
that with videotoolbox works in the current git on osx by the patch
http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/214982 though
hardware decoding with vda dont work.
the pacth is need.

as mentioned on the ticket, also, hardware decoding dont work with -hwaccel
auto in the current git on osx because vda is used by the default of
-hwaccel auto.
it is need to improve it.

thanks

ponpon

2016-06-06 10:28 GMT+09:00 Michael Niedermayer :

> Hi all
>
> its time for making the next major release
> If you want something in dont forget to push it to git master
>
> If theres some bug you care about or belive is important, please
> help fix them:
>
> regression bugs (all, not just since 3.0)
>
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
>
> priority=important bugs
>
> https://trac.ffmpeg.org/query?priority=important&status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
>
> really old bugs are likely hard so if you are searching for easy ones
> skip year old bugs
>
> Thanks
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: fix H.264 hwaccel init issue

[Richard Kern]

Ping. This fixes #5595. 

> On Jun 1, 2016, at 10:06 PM, Rick Kern  wrote:
> 
> Fixes VTDecompressionSessionCreate() error.
> 
> Signed-off-by: Rick Kern 
> ---
> libavcodec/videotoolbox.c | 59 ---
> 1 file changed, 45 insertions(+), 14 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 2f4d531..cadfb23 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -487,23 +487,53 @@ static CFDictionaryRef 
> videotoolbox_buffer_attributes_create(int width,
> return buffer_attributes;
> }
> 
> -static CMVideoFormatDescriptionRef 
> videotoolbox_format_desc_create(CMVideoCodecType codec_type,
> +static CMVideoFormatDescriptionRef 
> videotoolbox_format_desc_create(AVCodecContext *avctx,
> +   
> CMVideoCodecType codec_type,
>
> CFDictionaryRef decoder_spec,
>int width,
>int height)
> {
> -CMFormatDescriptionRef cm_fmt_desc;
> -OSStatus status;
> -
> -status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
> -codec_type,
> -width,
> -height,
> -decoder_spec, // Dictionary of 
> extension
> -&cm_fmt_desc);
> -
> -if (status)
> -return NULL;
> +CMFormatDescriptionRef cm_fmt_desc = NULL;
> +int status;
> +H264Context *h = codec_type == kCMVideoCodecType_H264 ? avctx->priv_data 
> : NULL;
> +
> +if (h && h->sps.data_size && h->pps.data_size) {
> +int ps_count = 2;
> +const uint8_t **ps_data = av_malloc(sizeof(uint8_t*) * ps_count);
> +size_t *ps_sizes = av_malloc(sizeof(size_t)  * ps_count);
> +
> +ps_data[0]  = h->sps.data;
> +ps_sizes[0] = h->sps.data_size;
> +
> +ps_data[1]  = h->pps.data;
> +ps_sizes[1] = h->pps.data_size;
> +
> +status = CMVideoFormatDescriptionCreateFromH264ParameterSets(NULL,
> + 
> ps_count,
> + ps_data,
> + 
> ps_sizes,
> + 4,
> + 
> &cm_fmt_desc);
> +av_freep(&ps_sizes);
> +av_freep(&ps_data);
> +
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error creating H.264 format 
> description: %d\n", status);
> +return NULL;
> +}
> +} else {
> +status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
> +codec_type,
> +width,
> +height,
> +decoder_spec, // Dictionary 
> of extension
> +&cm_fmt_desc);
> +
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error creating format description: 
> %d\n", status);
> +return NULL;
> +}
> +}
> 
> return cm_fmt_desc;
> }
> @@ -543,7 +573,8 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
> 
> decoder_spec = 
> videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
> 
> -videotoolbox->cm_fmt_desc = 
> videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
> +videotoolbox->cm_fmt_desc = videotoolbox_format_desc_create(avctx,
> +
> videotoolbox->cm_codec_type,
> decoder_spec,
> avctx->width,
> 
> avctx->height);
> -- 
> 2.7.4
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.1

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 12:11:56AM -0300, James Almer wrote:
> On 6/5/2016 10:28 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > its time for making the next major release
> > If you want something in dont forget to push it to git master
> > 
> > If theres some bug you care about or belive is important, please
> > help fix them:
> > 
> > regression bugs (all, not just since 3.0)
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> > 
> > priority=important bugs
> > https://trac.ffmpeg.org/query?priority=important&status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> > 
> > really old bugs are likely hard so if you are searching for easy ones
> > skip year old bugs
> > 
> > Thanks
> 
> The auto-bsf patchset by Rodger Combs needs to be applied for this release,
> as it fixes memleaks

it just needs to be applied ?
if so why has it not been applied ?


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

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


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

Re: [FFmpeg-devel] FFmpeg 3.1

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 03:28:19AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> its time for making the next major release
> If you want something in dont forget to push it to git master
> 
> If theres some bug you care about or belive is important, please
> help fix them:
> 
> regression bugs (all, not just since 3.0)
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> 
> priority=important bugs
> https://trac.ffmpeg.org/query?priority=important&status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> 
> really old bugs are likely hard so if you are searching for easy ones
> skip year old bugs

also anyone who is defacto maintaining some code and needs a git
write account (this implies you have basic knowledge about git)
please contact me

If you are already listed in MAINTAINERs i will give you git write
access

If not i will ask you to send a patch to add you to MAINTAINERs
(and anyone can object to/veto that patch)


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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] libavcodec/exr : fix layer detection

[Paul B Mahol]

On 6/4/16, Martin Vignali  wrote:
> Hello,
>
> In attach patch to fix layer detection inside exr file.
> Only search a channel match, if the layer name also match. If no layer name
> is set, doesn't change the previous behaviour.
> Avoid to automatically mix channel from several layer. And when layer
> doesn't have the same pixel type, avoid a decoding error.
>
> This patch also change the log messages, when layer option is set, to know
> which channel is detected, and which is ignored.

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

Re: [FFmpeg-devel] libavcodec/exr : fix B44 when all channel doesn't have the same type

[Paul B Mahol]

On 6/4/16, Martin Vignali  wrote:
> Hello,
>
> in attach patch to fix decoding B44 exr, when there is several pixel_type.
>
> Theses patch need to be apply after the 3 patch of mail :
> libavcodec/exr : fix tile and pxr24 when all channels doesn't have the same
> type
>
>
> 004 : Move channel_line_size to thread data, in order to be use by
> b44_uncompress
> 005 : Add a test by channel, to know if we need to only copy data, or
> uncompress it before (only half data are compress en B44, float and uint32
> are store uncompress
> 006 : indentation of the previous patch.
>
> Sample can be found here : https://we.tl/DRb2rXg0a7
>
> Comments welcome
>
> Martin Vignali
> Jokyo Images
>

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

Re: [FFmpeg-devel] FFmpeg 3.1

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 03:48:43PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 06, 2016 at 03:28:19AM +0200, Michael Niedermayer wrote:
> > Hi all
> > 
> > its time for making the next major release
> > If you want something in dont forget to push it to git master
> > 
> > If theres some bug you care about or belive is important, please
> > help fix them:
> > 
> > regression bugs (all, not just since 3.0)
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> > 
> > priority=important bugs
> > https://trac.ffmpeg.org/query?priority=important&status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
> > 
> > really old bugs are likely hard so if you are searching for easy ones
> > skip year old bugs
> 
> also anyone who is defacto maintaining some code and needs a git
> write account (this implies you have basic knowledge about git)
> please contact me
>
> If you are already listed in MAINTAINERs i will give you git write
> access

to clarify this a bit (its impled above but better to say it
explicitly so its not misunderstood)

You need to be listed in MAINTAINERs AND actually also maintain the
code (like fix (fixable) reported bugs related to the code in question)
to get git write account. Because if you dont maintain the code you
wouldnt need a git write account

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] libavcodec/exr : fix tile and pxr24 when all channels doesn't have the same type

[Paul B Mahol]

On 6/4/16, Martin Vignali  wrote:
> Hello,
>
> In attach patchs to fix decoding error, when all channels doesn't have the
> same pixel type.
>
> 001 : Fix tile, and simplify the tile support (remove unneed reorganisation
> of pixel).
> 002 : remove scanline_size var, is now replace by the same calc for tile
> and scanline
> 003 : Fix PXR24 uncompress, to manage several pixel type. expected_len, is
> now calculate channel by channel.
> I don't think this code have a lot of interest to be share with other
> compressor. PXR24, is the only compressor, where the float data, doesn't
> have the size of a float.
>
>
> For now, theses patchs, fix decoding tile whith half channel and float
> channel for :
> uncompress, rle, zip, zips, pxr24, piz.
>
> And fix decoding PXR24 scanline.
>
> But doesn't fix B44/B44a uncompress when all channels doesn't have the same
> pixel type (but it's related to other issues).
>
>
> Some samples with half and float channel can be found here :
> https://we.tl/iN2zKNWlzB
>
> Theses patch also pass fate test.

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

Re: [FFmpeg-devel] FFmpeg 3.1

[James Almer]

On 6/6/2016 10:30 AM, Michael Niedermayer wrote:
> On Mon, Jun 06, 2016 at 12:11:56AM -0300, James Almer wrote:
>> On 6/5/2016 10:28 PM, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> its time for making the next major release
>>> If you want something in dont forget to push it to git master
>>>
>>> If theres some bug you care about or belive is important, please
>>> help fix them:
>>>
>>> regression bugs (all, not just since 3.0)
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
>>>
>>> priority=important bugs
>>> https://trac.ffmpeg.org/query?priority=important&status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&col=time&col=changetime&order=priority
>>>
>>> really old bugs are likely hard so if you are searching for easy ones
>>> skip year old bugs
>>>
>>> Thanks
>>
>> The auto-bsf patchset by Rodger Combs needs to be applied for this release,
>> as it fixes memleaks
> 
> it just needs to be applied ?
> if so why has it not been applied ?

I think there were some comments in a review that haven't yet been addressed.
Or maybe it's just ready to be applied and he forgot. He knows better :P
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/sheervideo: Hack to extract init_vlc style tables for RGB [not to be pushed]

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/sheervideo.c |   33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/libavcodec/sheervideo.c b/libavcodec/sheervideo.c
index e41645e..88fb174 100644
--- a/libavcodec/sheervideo.c
+++ b/libavcodec/sheervideo.c
@@ -1029,14 +1029,15 @@ static int decode_frame(AVCodecContext *avctx,
 unsigned format;
 int ret;
 
-if (avpkt->size <= 20)
-return AVERROR_INVALIDDATA;
-
-if (AV_RL32(avpkt->data) != MKTAG('S','h','i','r'))
-return AVERROR_INVALIDDATA;
+// if (avpkt->size <= 20)
+// return AVERROR_INVALIDDATA;
+//
+// if (AV_RL32(avpkt->data) != MKTAG('S','h','i','r'))
+// return AVERROR_INVALIDDATA;
 
 format = AV_RL32(avpkt->data + 16);
 switch (format) {
+default:
 case MKTAG(' ', 'R', 'G', 'B'):
 avctx->pix_fmt = AV_PIX_FMT_RGB0;
 s->lut_l[0] = (uint8_t *)&lut_r;
@@ -1059,11 +1060,31 @@ static int decode_frame(AVCodecContext *avctx,
 s->lut_s[3] = (uint8_t *)&lut_sbg;
 s->decode_frame = decode_argb;
 break;
-default:
+
 avpriv_report_missing_feature(avctx, "unsupported format: 0x%X", 
format);
 return AVERROR_PATCHWELCOME;
 }
 
+for(int table=0; table < 3; table++) {
+uint8_t array[32];
+uint64_t index=0;
+int code, len;
+av_log(0,0, "Table %d\n", table);
+for(;;) {
+AV_WB64(array, index);
+if ((ret = init_get_bits8(&gb, array, sizeof(array))) < 0)
+return ret;
+code = get_vlc3(&gb, s->lut_l[table], s->lut_s[table]) & 0xFF;
+len = get_bits_count(&gb);
+av_log(0,0, "code: %5d, len:%2d, bits:%8LX\n", code, len, index >> 
(64 - len));
+index += 1ULL << (64-len);
+if(!index)
+break;
+}
+}
+exit(0);
+
+
 p->pict_type = AV_PICTURE_TYPE_I;
 p->key_frame = 1;
 
-- 
1.7.9.5

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

Re: [FFmpeg-devel] IRC meeting

[Felt, Patrick]

On 6/4/16, 4:33 AM, "ffmpeg-devel on behalf of Michael Niedermayer" 
 wrote:

>On Sat, Jun 04, 2016 at 10:30:32AM +0200, Piotr Bandurski wrote:
>> Hi,
>> 
>> The problem with this project is that it has not enough active developers. 
>> It looks like most of the devs swiched into "stand-by" mode or something
>> and sadly no new people are joining in to push development forward ;)
>
>There where new developers but i have the feeling many of them where
>treated rather hostile by the community until they decreased activity
>or disappeared examples are lukasz, ganesh and andreas
>but maybe iam misinterpreting things, iam much more a technical guy
>than a sozial one

I’m no star developer by any stretch of the imagination, nor was I treated 
poorly, but..  being a new guy in these parts, having come in right amidst all 
this excitement, has given me pause to question if I just stepped into a crazy 
minefield.

>but i have the hope that with the higherh awareness about hostilities
>we have now and less the CoC (its people not paper that makes a
>difference) this could be prevented and maybe undone in the future.

Personally.  I think this will make a bit of difference for a lot of people if 
it’s made well known.  Perhaps add a link to the ratified COC in the topic in 
the irc channel, and add it as required reading to the mailman subscribe?  (if 
that’s even possible; I’ve never administered mailman before).

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 09:01:44AM +0200, Hendrik Leppkes wrote:
> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
>  wrote:
> > This fixes a API regression
> > Probably fixes Ticket5451
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/utils.c   |4 ++--
> >  libavformat/version.h |2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index ac056c4..7ca0a12 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >  av_codec_set_lowres(st->codec, 
> > av_codec_get_lowres(st->internal->avctx));
> >  st->codec->width = st->internal->avctx->width;
> >  st->codec->height = st->internal->avctx->height;
> > -st->codec->coded_width = st->internal->avctx->coded_width;
> > -st->codec->coded_height = st->internal->avctx->coded_height;
> >  }
> >
> >  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
> > @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >  }
> >
> >  // Fields unavailable in AVCodecParameters
> > +st->codec->coded_width = st->internal->avctx->coded_width;
> > +st->codec->coded_height = st->internal->avctx->coded_height;
> >  st->codec->properties = st->internal->avctx->properties;
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> > diff --git a/libavformat/version.h b/libavformat/version.h
> > index c92a23f..2f79b7f 100644
> > --- a/libavformat/version.h
> > +++ b/libavformat/version.h
> > @@ -29,7 +29,7 @@
> >
> >  #include "libavutil/version.h"
> >
> > -// When bumping major check Ticket5467, 5421 for regressing
> > +// When bumping major check Ticket5467, 5421, 5451 for regressing
> >  // Also please add any ticket numbers that you belive might regress here
> >  #define LIBAVFORMAT_VERSION_MAJOR  57
> >  #define LIBAVFORMAT_VERSION_MINOR  37
> > --
> > 1.7.9.5
> 
> The ticket in question accesses st->codec to get this field. st->codec
> is going away, so there is no point in testing this "regression",
> since they need to update their API usage first for it to even
> compile.

IMO its neccessary to first discuss the removial of st->codec on
ffmpeg-devel before it is removed, thats a major change and should
not just happen without discussion and some sort of more or less
consensus. Or dont you want to be in "control" over the project you
work on and maintain?

Also the ticket list is meant along the lines of "This could break,
we must be conciously aware of the consequences of our actions so
we can make informed decissions"

by the time we want to bump API, Chromium might have been changed
and no longer require the coded_height/width fields
or it might still need them and a trivial update in Chromium might
fix that or it might be that it depends on these fields and an
update to the codecpar API if its lacking the field might cause a
major problem for Chromium.
We must be aware of what removing the st->codec API does to our users
so we can make a wise and informed decission.


> Heck the same thing applies to the other tickets you listed here, all
> of those access information from st->codec which is going away
> entirely, so you can't really "test" these cases. Someone would have
> to update the code to use codecpar first, and while doing this
> migration they would need to preserve whatever behavior exists today.

the first listed ticket #5467 is about ffmpeg displaying information
about the input streams losslessness
That ticket has nothing to do with codecpar as such
Either ffmpeg does display this information or it does not, it doesnt
need it from codecpar, it could obtain the information by other means

The 2nd listed ticket (#5421) of the 3 is similar about encoder and qp
range display.

By the time we want to bump, ffmpeg might not use st->codec anymore to
display these and the tickets then wont regress or it might still use
it and regress. This is important information when we want to bump the
version ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 6:09 PM, Michael Niedermayer
 wrote:
> On Mon, Jun 06, 2016 at 09:01:44AM +0200, Hendrik Leppkes wrote:
>> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
>>  wrote:
>> > This fixes a API regression
>> > Probably fixes Ticket5451
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavformat/utils.c   |4 ++--
>> >  libavformat/version.h |2 +-
>> >  2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index ac056c4..7ca0a12 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> >  av_codec_set_lowres(st->codec, 
>> > av_codec_get_lowres(st->internal->avctx));
>> >  st->codec->width = st->internal->avctx->width;
>> >  st->codec->height = st->internal->avctx->height;
>> > -st->codec->coded_width = st->internal->avctx->coded_width;
>> > -st->codec->coded_height = st->internal->avctx->coded_height;
>> >  }
>> >
>> >  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
>> > @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> >  }
>> >
>> >  // Fields unavailable in AVCodecParameters
>> > +st->codec->coded_width = st->internal->avctx->coded_width;
>> > +st->codec->coded_height = st->internal->avctx->coded_height;
>> >  st->codec->properties = st->internal->avctx->properties;
>> >  FF_ENABLE_DEPRECATION_WARNINGS
>> >  #endif
>> > diff --git a/libavformat/version.h b/libavformat/version.h
>> > index c92a23f..2f79b7f 100644
>> > --- a/libavformat/version.h
>> > +++ b/libavformat/version.h
>> > @@ -29,7 +29,7 @@
>> >
>> >  #include "libavutil/version.h"
>> >
>> > -// When bumping major check Ticket5467, 5421 for regressing
>> > +// When bumping major check Ticket5467, 5421, 5451 for regressing
>> >  // Also please add any ticket numbers that you belive might regress here
>> >  #define LIBAVFORMAT_VERSION_MAJOR  57
>> >  #define LIBAVFORMAT_VERSION_MINOR  37
>> > --
>> > 1.7.9.5
>>
>> The ticket in question accesses st->codec to get this field. st->codec
>> is going away, so there is no point in testing this "regression",
>> since they need to update their API usage first for it to even
>> compile.
>
> IMO its neccessary to first discuss the removial of st->codec on
> ffmpeg-devel before it is removed, thats a major change and should
> not just happen without discussion and some sort of more or less
> consensus. Or dont you want to be in "control" over the project you
> work on and maintain?

I do, which is why I think it should go away, keeping a duplicated and
deprecated part of API around for ever is not a good thing, and
codecpar is a much better API to cleanly export information, instead
of AVCodecContext which contains hundreds of fields of questionably
usefulness.
But this decision is still 2 years in the future either way.

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 06:14:15PM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 6, 2016 at 6:09 PM, Michael Niedermayer
>  wrote:
> > On Mon, Jun 06, 2016 at 09:01:44AM +0200, Hendrik Leppkes wrote:
> >> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
> >>  wrote:
> >> > This fixes a API regression
> >> > Probably fixes Ticket5451
> >> >
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavformat/utils.c   |4 ++--
> >> >  libavformat/version.h |2 +-
> >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> > index ac056c4..7ca0a12 100644
> >> > --- a/libavformat/utils.c
> >> > +++ b/libavformat/utils.c
> >> > @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >> >  av_codec_set_lowres(st->codec, 
> >> > av_codec_get_lowres(st->internal->avctx));
> >> >  st->codec->width = st->internal->avctx->width;
> >> >  st->codec->height = st->internal->avctx->height;
> >> > -st->codec->coded_width = st->internal->avctx->coded_width;
> >> > -st->codec->coded_height = st->internal->avctx->coded_height;
> >> >  }
> >> >
> >> >  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
> >> > @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >> >  }
> >> >
> >> >  // Fields unavailable in AVCodecParameters
> >> > +st->codec->coded_width = st->internal->avctx->coded_width;
> >> > +st->codec->coded_height = st->internal->avctx->coded_height;
> >> >  st->codec->properties = st->internal->avctx->properties;
> >> >  FF_ENABLE_DEPRECATION_WARNINGS
> >> >  #endif
> >> > diff --git a/libavformat/version.h b/libavformat/version.h
> >> > index c92a23f..2f79b7f 100644
> >> > --- a/libavformat/version.h
> >> > +++ b/libavformat/version.h
> >> > @@ -29,7 +29,7 @@
> >> >
> >> >  #include "libavutil/version.h"
> >> >
> >> > -// When bumping major check Ticket5467, 5421 for regressing
> >> > +// When bumping major check Ticket5467, 5421, 5451 for regressing
> >> >  // Also please add any ticket numbers that you belive might regress here
> >> >  #define LIBAVFORMAT_VERSION_MAJOR  57
> >> >  #define LIBAVFORMAT_VERSION_MINOR  37
> >> > --
> >> > 1.7.9.5
> >>
> >> The ticket in question accesses st->codec to get this field. st->codec
> >> is going away, so there is no point in testing this "regression",
> >> since they need to update their API usage first for it to even
> >> compile.
> >
> > IMO its neccessary to first discuss the removial of st->codec on
> > ffmpeg-devel before it is removed, thats a major change and should
> > not just happen without discussion and some sort of more or less
> > consensus. Or dont you want to be in "control" over the project you
> > work on and maintain?
> 
> I do, which is why I think it should go away, keeping a duplicated and
> deprecated part of API around for ever is not a good thing, and
> codecpar is a much better API to cleanly export information, instead
> of AVCodecContext which contains hundreds of fields of questionably
> usefulness.
> But this decision is still 2 years in the future either way.

really, I agree
what keeps annoying the hell out of me is that the new API as it is
currently has piranha filled holes where there where solid and simple
bridges one could walk over previously
and when i tried to put a board over a hole someone hit me with a
flame thrower


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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally

[Hendrik Leppkes]

On Mon, Jun 6, 2016 at 6:29 PM, Michael Niedermayer
 wrote:
> On Mon, Jun 06, 2016 at 06:14:15PM +0200, Hendrik Leppkes wrote:
>> On Mon, Jun 6, 2016 at 6:09 PM, Michael Niedermayer
>>  wrote:
>> > On Mon, Jun 06, 2016 at 09:01:44AM +0200, Hendrik Leppkes wrote:
>> >> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
>> >>  wrote:
>> >> > This fixes a API regression
>> >> > Probably fixes Ticket5451
>> >> >
>> >> > Signed-off-by: Michael Niedermayer 
>> >> > ---
>> >> >  libavformat/utils.c   |4 ++--
>> >> >  libavformat/version.h |2 +-
>> >> >  2 files changed, 3 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> >> > index ac056c4..7ca0a12 100644
>> >> > --- a/libavformat/utils.c
>> >> > +++ b/libavformat/utils.c
>> >> > @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> >> >  av_codec_set_lowres(st->codec, 
>> >> > av_codec_get_lowres(st->internal->avctx));
>> >> >  st->codec->width = st->internal->avctx->width;
>> >> >  st->codec->height = st->internal->avctx->height;
>> >> > -st->codec->coded_width = st->internal->avctx->coded_width;
>> >> > -st->codec->coded_height = 
>> >> > st->internal->avctx->coded_height;
>> >> >  }
>> >> >
>> >> >  if (st->codec->codec_tag != MKTAG('t','m','c','d'))
>> >> > @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> >> >  }
>> >> >
>> >> >  // Fields unavailable in AVCodecParameters
>> >> > +st->codec->coded_width = st->internal->avctx->coded_width;
>> >> > +st->codec->coded_height = st->internal->avctx->coded_height;
>> >> >  st->codec->properties = st->internal->avctx->properties;
>> >> >  FF_ENABLE_DEPRECATION_WARNINGS
>> >> >  #endif
>> >> > diff --git a/libavformat/version.h b/libavformat/version.h
>> >> > index c92a23f..2f79b7f 100644
>> >> > --- a/libavformat/version.h
>> >> > +++ b/libavformat/version.h
>> >> > @@ -29,7 +29,7 @@
>> >> >
>> >> >  #include "libavutil/version.h"
>> >> >
>> >> > -// When bumping major check Ticket5467, 5421 for regressing
>> >> > +// When bumping major check Ticket5467, 5421, 5451 for regressing
>> >> >  // Also please add any ticket numbers that you belive might regress 
>> >> > here
>> >> >  #define LIBAVFORMAT_VERSION_MAJOR  57
>> >> >  #define LIBAVFORMAT_VERSION_MINOR  37
>> >> > --
>> >> > 1.7.9.5
>> >>
>> >> The ticket in question accesses st->codec to get this field. st->codec
>> >> is going away, so there is no point in testing this "regression",
>> >> since they need to update their API usage first for it to even
>> >> compile.
>> >
>> > IMO its neccessary to first discuss the removial of st->codec on
>> > ffmpeg-devel before it is removed, thats a major change and should
>> > not just happen without discussion and some sort of more or less
>> > consensus. Or dont you want to be in "control" over the project you
>> > work on and maintain?
>>
>> I do, which is why I think it should go away, keeping a duplicated and
>> deprecated part of API around for ever is not a good thing, and
>> codecpar is a much better API to cleanly export information, instead
>> of AVCodecContext which contains hundreds of fields of questionably
>> usefulness.
>> But this decision is still 2 years in the future either way.
>
> really, I agree
> what keeps annoying the hell out of me is that the new API as it is
> currently has piranha filled holes where there where solid and simple
> bridges one could walk over previously
> and when i tried to put a board over a hole someone hit me with a
> flame thrower
>

Thats because we want the holes to be identified and filled up
properly, and not just boarded over, to keep with the analogy.
So to translate that, needs should be properly identified and decided
what to do about them, or if something needs to be done at all (we're
all aware we have a whole bunch of "hack solutions" that may not be
worth repeating), instead of just blindly copying some field into
codecpar (which is part of why avctx got so big in the first place,
codec-specific things that end up in a global context, hence being
reluctant to repeat such mistakes when we have a clean slate here)

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

[FFmpeg-devel] [PATCH] lavf/srtdec: fix probing files with negative first timestamps

[Rodger Combs]

---
 libavformat/srtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index 585aa6a..06061a8 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -52,7 +52,7 @@ static int srt_probe(AVProbeData *p)
 /* Check if the next line matches a SRT timestamp */
 if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0)
 return 0;
-if (buf[0] >= '0' && buf[0] <= '9' && strstr(buf, " --> ")
+if (((buf[0] >= '0' && buf[0] <= '9') || buf[0] == '-') && strstr(buf, " 
--> ")
 && sscanf(buf, "%*d:%*d:%*d%*1[,.]%*d --> %*d:%*d:%*d%*1[,.]%d", &v) 
== 1)
 return AVPROBE_SCORE_MAX;
 
-- 
2.8.3

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

Re: [FFmpeg-devel] [PATCH] lavf/srtdec: fix probing files with negative first timestamps

[Clément Bœsch]

On Mon, Jun 06, 2016 at 01:26:40PM -0500, Rodger Combs wrote:
> ---
>  libavformat/srtdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
> index 585aa6a..06061a8 100644
> --- a/libavformat/srtdec.c
> +++ b/libavformat/srtdec.c
> @@ -52,7 +52,7 @@ static int srt_probe(AVProbeData *p)
>  /* Check if the next line matches a SRT timestamp */
>  if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0)
>  return 0;
> -if (buf[0] >= '0' && buf[0] <= '9' && strstr(buf, " --> ")
> +if (((buf[0] >= '0' && buf[0] <= '9') || buf[0] == '-') && strstr(buf, " 
> --> ")

It would be more correct to just skip the '-' if present and still do the
[0-9] range check after that. So maybe if (buf[0] == '-') buf++ just
before the unchanged if.

Thanks

>  && sscanf(buf, "%*d:%*d:%*d%*1[,.]%*d --> %*d:%*d:%*d%*1[,.]%d", &v) 
> == 1)
>  return AVPROBE_SCORE_MAX;
>  

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avformat/matroskadec: force 48kHz sample rate when rescaling Opus inital padding

[James Almer]

Mkvtoolnix stores the sample rate of the original stream as reported by the
"OpusHead" stream header instead of 48kHz, the actual sample rate of the Opus
stream.
Ignoring the stored sample rate and forcing 48kHz preserves the correct initial
padding when remuxing.

Signed-off-by: James Almer 
---
OggOpus files created by opus-tools then remuxed into Matroska with mkvtoolnix
results in files like the one mentioned above. See https://0x0.st/caG.mka or 
just
use mkvtoolnix to remux fate-samples/ogg/intro-partial.opus

Before this patch:

$ mkvinfo caG.mka | grep delay
|  + Codec delay: 7.417ms (7416667ns)

$ mkvinfo caG.mka | grep Sampling
|   + Sampling frequency: 44100

$ ffmpeg -v 0 -i caG.mka -c:a copy before.webm

$ mkvinfo before.webm | grep delay
|  + Codec delay: 6.812ms (6812500ns)

$ mkvinfo before.webm | grep Sampling
|   + Sampling frequency: 48000

Firefox can't play before.webm, but Opera (Chromium based) can.

After this patch:

$ ffmpeg -v 0 -i caG.mka -c:a copy after.webm

$ mkvinfo after.webm | grep delay
|  + Codec delay: 7.417ms (7416667ns)

$ mkvinfo after.webm | grep Sampling
|   + Sampling frequency: 48000

Both Firefox and Opera play after.webm


I'm adding a check for Opus since I don't know when or if some other codec will
use the codec_delay element in the future. At least for now it seems to be Opus
exclusive.

 libavformat/matroskadec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 3270009..7880a10 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2353,7 +2353,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
 if (track->codec_delay > 0) {
 st->codecpar->initial_padding = 
av_rescale_q(track->codec_delay,
  (AVRational){1, 
10},
- (AVRational){1, 
st->codecpar->sample_rate});
+ (AVRational){1, 
st->codecpar->codec_id == AV_CODEC_ID_OPUS ?
+ 
48000 : st->codecpar->sample_rate});
 }
 if (track->seek_preroll > 0) {
 st->codecpar->seek_preroll = av_rescale_q(track->seek_preroll,
-- 
2.8.2

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: improve error messages

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 10:05:38AM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libavcodec/mediacodecdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: force 48kHz sample rate when rescaling Opus inital padding

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 04:13:51PM -0300, James Almer wrote:
> Mkvtoolnix stores the sample rate of the original stream as reported by the
> "OpusHead" stream header instead of 48kHz, the actual sample rate of the Opus
> stream.
> Ignoring the stored sample rate and forcing 48kHz preserves the correct 
> initial
> padding when remuxing.
> 
> Signed-off-by: James Almer 
> ---
> OggOpus files created by opus-tools then remuxed into Matroska with mkvtoolnix
> results in files like the one mentioned above. See https://0x0.st/caG.mka or 
> just
> use mkvtoolnix to remux fate-samples/ogg/intro-partial.opus
> 
> Before this patch:
> 
> $ mkvinfo caG.mka | grep delay
> |  + Codec delay: 7.417ms (7416667ns)
> 
> $ mkvinfo caG.mka | grep Sampling
> |   + Sampling frequency: 44100
> 
> $ ffmpeg -v 0 -i caG.mka -c:a copy before.webm
> 
> $ mkvinfo before.webm | grep delay
> |  + Codec delay: 6.812ms (6812500ns)
> 
> $ mkvinfo before.webm | grep Sampling
> |   + Sampling frequency: 48000
> 
> Firefox can't play before.webm, but Opera (Chromium based) can.
> 
> After this patch:
> 
> $ ffmpeg -v 0 -i caG.mka -c:a copy after.webm
> 
> $ mkvinfo after.webm | grep delay
> |  + Codec delay: 7.417ms (7416667ns)
> 
> $ mkvinfo after.webm | grep Sampling
> |   + Sampling frequency: 48000
> 
> Both Firefox and Opera play after.webm
> 
> 
> I'm adding a check for Opus since I don't know when or if some other codec 
> will
> use the codec_delay element in the future. At least for now it seems to be 
> Opus
> exclusive.
> 
>  libavformat/matroskadec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

should be ok
maybe wait a day or so, so others can comment too

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

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


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

[FFmpeg-devel] Changelog : add OpenExr improvements

[Martin Vignali]

Hello,

In attach, patch to add entry to the changelog, for recently add OpenExr
features

Martin
From 92fcd55e4970c50e7a7be2f23aaa42f8d07fa3d0 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 6 Jun 2016 22:48:24 +0200
Subject: [PATCH] Changelog : add OpenExr improvements

---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index d5228b2..bb376a1 100644
--- a/Changelog
+++ b/Changelog
@@ -38,6 +38,7 @@ version :
 - loudnorm filter
 - MTAF demuxer and decoder
 - MagicYUV decoder
+- OpenExr improvements (tile data and B44/B44A support)
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Michael Niedermayer]

On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote:
> Hi
> 
> It was suggested in the IRC meeting today that i start a vote to
> resolve if AVClass & AVOption should be added to AVCodecParameters
> This question needs to be awnsered before the next release because
> the ABI would be broken if its added afterwards
> the lack of any decission blocks the release which is worse than
> either decission, otherwise a vote might be silly for such technical
> question but eve a bad decission is better than no decission here
> 
> 
> The disadvanatges are:
> 1 more field in the struct
> a high level API that some feel is unneeded for AVCodecParameters
> it could be confusing to some that there are 2 different ways to
> access the fields
> people might use it as av_log() context when they intended to use a
> different context for it
> There are probably more please help fill the list if you know more
> 
> The advanatges are:
> More consistent availability of AVOptions and AVClass in public
> structs
> Makes supporting multiple FFmpeg versions and distros easier and
> cleaner for applications. (reduces lists of #if version checks)
> Provides default/min/max values, allows basic validity checking within
> min/max
> Avoids mysterious crashes if an application uses avoption functions
> on AVCodecParameters
> Introspection
> Serialization support that may be usefull for ffserver or an application
> replacing ffserver
> 
> 
> An application that doesnt want to use AVOptions or AVClass can
> completey ignore them.
> 
> Please state clearly if you agree to add AVClass&AVOption to
> AVCodecParameters or if you disagree about adding it or if you dont
> care either way
> 
> The vote will end 1 week from now, simple 50% majority (Yes vs no)
> I dont really know who should be eligible for voting, so i suggest
> everyone from the vote comittee but iam happy with anything, just
> stating somethng ...

It seems the vote is a tie 4:4
BBB suggested to add another week, i agree, vote extended by 7 days
that shouldnt affect the release as more time is needed to fix
regression bugs anyway

[...]

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

[FFmpeg-devel] [PATCH 1/2] MAINTAINERS: Add myself as maintainer for VAAPI encoders

[Mark Thompson]

---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ce2524..9d9337b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -304,6 +304,7 @@ Hardware acceleration:
   dxva2*Hendrik Leppkes, Laurent Aimar
   mediacodec*   Matthieu Bouron
   vaapi*Gwenole Beauchesne
+  vaapi_encode* Mark Thompson
   vda*  Sebastien Zwickert
   vdpau*Philip Langdale, Carl Eugen Hoyos
   videotoolbox* Sebastien Zwickert
-- 
2.8.1

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

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 11:07:22PM +0200, Michael Niedermayer wrote:
> On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > It was suggested in the IRC meeting today that i start a vote to
> > resolve if AVClass & AVOption should be added to AVCodecParameters
> > This question needs to be awnsered before the next release because
> > the ABI would be broken if its added afterwards
> > the lack of any decission blocks the release which is worse than
> > either decission, otherwise a vote might be silly for such technical
> > question but eve a bad decission is better than no decission here
> > 
> > 
> > The disadvanatges are:
> > 1 more field in the struct
> > a high level API that some feel is unneeded for AVCodecParameters
> > it could be confusing to some that there are 2 different ways to
> > access the fields
> > people might use it as av_log() context when they intended to use a
> > different context for it
> > There are probably more please help fill the list if you know more
> > 
> > The advanatges are:
> > More consistent availability of AVOptions and AVClass in public
> > structs
> > Makes supporting multiple FFmpeg versions and distros easier and
> > cleaner for applications. (reduces lists of #if version checks)
> > Provides default/min/max values, allows basic validity checking within
> > min/max
> > Avoids mysterious crashes if an application uses avoption functions
> > on AVCodecParameters
> > Introspection
> > Serialization support that may be usefull for ffserver or an application
> > replacing ffserver
> > 
> > 
> > An application that doesnt want to use AVOptions or AVClass can
> > completey ignore them.
> > 
> > Please state clearly if you agree to add AVClass&AVOption to
> > AVCodecParameters or if you disagree about adding it or if you dont
> > care either way
> > 
> > The vote will end 1 week from now, simple 50% majority (Yes vs no)
> > I dont really know who should be eligible for voting, so i suggest
> > everyone from the vote comittee but iam happy with anything, just
> > stating somethng ...
> 
> It seems the vote is a tie 4:4
> BBB suggested to add another week, i agree, vote extended by 7 days
> that shouldnt affect the release as more time is needed to fix
> regression bugs anyway

final date is “Sun, May 29, 2016 at 01:32:54AM + 14 days”

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH 2/2] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31

[Mark Thompson]

---
I'll go with Matthieu's suggestion to use INT32_MAX instead of 1 << 31.

 libavcodec/vaapi_encode_h264.c | 6 ++
 libavcodec/vaapi_encode_h265.c | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index dc7774b..2e2052b 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -731,6 +731,12 @@ static av_cold int 
vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
 int hrd_buffer_size;
 int hrd_initial_buffer_fullness;

+if (avctx->bit_rate > INT32_MAX) {
+av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
+   "higher is not supported.\n");
+return AVERROR(EINVAL);
+}
+
 if (avctx->rc_buffer_size)
 hrd_buffer_size = avctx->rc_buffer_size;
 else
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 17cd900..e4d21f0 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1158,6 +1158,12 @@ static av_cold int 
vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx
 int hrd_buffer_size;
 int hrd_initial_buffer_fullness;

+if (avctx->bit_rate > INT32_MAX) {
+av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
+   "higher is not supported.\n");
+return AVERROR(EINVAL);
+}
+
 if (avctx->rc_buffer_size)
 hrd_buffer_size = avctx->rc_buffer_size;
 else
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/tcp: support timeout for getaddrinfo For fixing stucking when resolving addrinfo

[Michael Niedermayer]

On Wed, Jun 01, 2016 at 12:03:32PM +0800, XinZheng Zhang wrote:
> On Tue, May 31, 2016 at 9:33 PM, Hendrik Leppkes  wrote:
> >
> > On Tue, May 31, 2016 at 2:58 PM, Xinzheng Zhang  
> > wrote:
> > > ---
> > >  libavformat/tcp.c | 215 
> > > ++
> > >  1 file changed, 215 insertions(+)
> > >
> >
> > This whole patch looks extremely complicated and long for something
> > hidden behind a tiny option not saying much.
> > Maybe you should start by elaborating in detail what you are trying to
> > fix, how you are fixing it, and why you choose this approach and not
> > any others that may appear simpler.
> >
> 
> For some ugly network conditions(Eg.Mobile device in a WiFi network,
> but offline from internet), getaddrinfo() could block tcp_open() for a
> long time,
> neither timeout nor interrupt callback can save us.
> 
> There are serveral way to fix this issue
> AFAIK. We can use `getaddrinfo_a` on some linux platform
> http://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html
> But, it doesn't work on other platforms.

would the getaddrinfo_a() based code be simple ?
if so i think thats the way to go

If one really wants one could implement getaddrinfo_a() emulation
with a thread on other platforms. That should still be cleaner then
stuffing this code into tcp.c

above is just a suggestion

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

[FFmpeg-devel] [PATCH] web/contact: Point to the Code of conduct

[Michael Niedermayer]

Suggested-by: Felt, Patrick
Signed-off-by: Michael Niedermayer 
---
 src/contact |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/contact b/src/contact
index 200cb67..e076222 100644
--- a/src/contact
+++ b/src/contact
@@ -11,7 +11,7 @@
   avoid https://en.wikipedia.org/wiki/Top-posting";>top-posting and
   thread hijacking (that is, replying to a thread and changing the 
subject line to
   something completely unrelated that was not being discussed within 
the original
-  thread).
+  thread) and please read the Code of conduct.
 
 
   Configuring your mail client to break lines after 70 or so 
characters is a plus.
@@ -104,6 +104,7 @@
   have voice in the channels.
   https://webchat.freenode.net/";>freenode webchat is a web
   client for these channels.
+  Please read and follow the Code of conduct.
 
   
   
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH v2 1/2] avcodec/cuvid: add cuvid decoder

[Timo Rothenpieler]

---
 Changelog  |   2 +
 MAINTAINERS|   1 +
 configure  |  20 ++
 libavcodec/Makefile|   2 +
 libavcodec/allcodecs.c |   4 +
 libavcodec/cuvid.c | 602 +
 libavcodec/version.h   |   4 +-
 7 files changed, 633 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/cuvid.c

diff --git a/Changelog b/Changelog
index d5228b2..35e17e5 100644
--- a/Changelog
+++ b/Changelog
@@ -38,6 +38,8 @@ version :
 - loudnorm filter
 - MTAF demuxer and decoder
 - MagicYUV decoder
+- CUDA CUVID H264/HEVC decoder
+
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ce2524..bf99d0c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -163,6 +163,7 @@ Codecs:
   cpia.cStephan Hilb
   crystalhd.c   Philip Langdale
   cscd.cReimar Doeffinger
+  cuvid.c   Timo Rothenpieler
   dca.c Kostya Shishkov, Benjamin Larsson
   dirac*Rostislav Pehlivanov
   dnxhd*Baptiste Coudurier
diff --git a/configure b/configure
index 7c463a5..2b2d5f8 100755
--- a/configure
+++ b/configure
@@ -158,6 +158,7 @@ Hardware accelerators:
 
 Hardware-accelerated decoding/encoding:
   --enable-cudaenable dynamically linked CUDA [no]
+  --enable-cuvid   enable CUVID support [autodetect]
   --enable-libmfx  enable HW acceleration through libmfx
   --enable-mmalenable decoding via MMAL [no]
   --enable-nvenc   enable NVIDIA NVENC support [no]
@@ -1567,6 +1568,7 @@ FEATURE_LIST="
 
 HW_CODECS_LIST="
 cuda
+cuvid
 libmfx
 mmal
 nvenc
@@ -2328,6 +2330,7 @@ comfortnoise_encoder_select="lpc"
 cook_decoder_select="audiodsp mdct sinewin"
 cscd_decoder_select="lzo"
 cscd_decoder_suggest="zlib"
+cuvid_decoder_deps="cuda cuvid"
 dca_decoder_select="mdct"
 dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
@@ -2522,6 +2525,7 @@ audiotoolbox_extralibs="-framework CoreFoundation 
-framework AudioToolbox -frame
 
 # hardware accelerators
 crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
+cuvid_deps="cuda"
 d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
 dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode"
 vaapi_deps="va_va_h"
@@ -2539,6 +2543,7 @@ h263_vaapi_hwaccel_select="h263_decoder"
 h263_videotoolbox_hwaccel_deps="videotoolbox"
 h263_videotoolbox_hwaccel_select="h263_decoder"
 h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
+h264_cuvid_hwaccel_deps="cuda cuvid"
 h264_d3d11va_hwaccel_deps="d3d11va"
 h264_d3d11va_hwaccel_select="h264_decoder"
 h264_dxva2_hwaccel_deps="dxva2"
@@ -2564,6 +2569,7 @@ h264_vdpau_hwaccel_deps="vdpau"
 h264_vdpau_hwaccel_select="h264_decoder"
 h264_videotoolbox_hwaccel_deps="videotoolbox"
 h264_videotoolbox_hwaccel_select="h264_decoder"
+hevc_cuvid_hwaccel_deps="cuda cuvid"
 hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
 hevc_d3d11va_hwaccel_select="hevc_decoder"
 hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
@@ -2657,6 +2663,8 @@ hwupload_cuda_filter_deps="cuda"
 scale_npp_filter_deps="cuda libnpp"
 
 nvenc_encoder_deps="nvenc"
+h264_cuvid_decoder_deps="cuda cuvid"
+h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel"
 h264_qsv_decoder_deps="libmfx"
 h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
h264_qsv_hwaccel"
 h264_qsv_encoder_deps="libmfx"
@@ -2664,6 +2672,8 @@ h264_qsv_encoder_select="qsvenc"
 h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
 h264_vaapi_encoder_select="vaapi_encode golomb"
 
+hevc_cuvid_decoder_deps="cuda cuvid"
+hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf hevc_cuvid_hwaccel"
 hevc_qsv_decoder_deps="libmfx"
 hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
hevc_qsv_hwaccel"
 hevc_qsv_encoder_deps="libmfx"
@@ -5002,6 +5012,7 @@ die_license_disabled gpl libxvid
 die_license_disabled gpl x11grab
 
 die_license_disabled nonfree cuda
+die_license_disabled nonfree cuvid
 die_license_disabled nonfree libfaac
 die_license_disabled nonfree libnpp
 enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
@@ -5572,6 +5583,11 @@ for func in $COMPLEX_FUNCS; do
 eval check_complexfunc $func \${${func}_args:-1}
 done
 
+# Enable CUVID by default if CUDA is enabled
+if enabled cuda && ! disabled cuvid; then
+enable cuvid
+fi
+
 # these are off by default, so fail if requested and not available
 enabled avfoundation_indev && { check_header_objcc AVFoundation/AVFoundation.h 
|| disable avfoundation_indev; }
 enabled avfoundation_indev && { check_lib2 CoreGraphics/CoreGraphics.h 
CGGetActiveDisplayList -framework CoreGraphics ||
@@ -5581,6 +5597,10 @@ enabled avisynth  && { { check_lib2 "windows.h" 
LoadLibrary; } ||
  

[FFmpeg-devel] [PATCH v2 2/2] ffmpeg: Add cuvid hwaccel support

[Timo Rothenpieler]

---
 Makefile   |   1 +
 ffmpeg.c   |   5 ++
 ffmpeg.h   |   3 +
 ffmpeg_cuvid.c | 217 +
 ffmpeg_opt.c   |   3 +
 5 files changed, 229 insertions(+)
 create mode 100644 ffmpeg_cuvid.c

diff --git a/Makefile b/Makefile
index 0ff4a87..4eca5d1 100644
--- a/Makefile
+++ b/Makefile
@@ -36,6 +36,7 @@ OBJS-ffmpeg-$(CONFIG_VAAPI)   += ffmpeg_vaapi.o
 ifndef CONFIG_VIDEOTOOLBOX
 OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
 endif
+OBJS-ffmpeg-$(CONFIG_CUVID)   += ffmpeg_cuvid.o
 OBJS-ffmpeg-$(HAVE_DXVA2_LIB) += ffmpeg_dxva2.o
 OBJS-ffmpeg-$(HAVE_VDPAU_X11) += ffmpeg_vdpau.o
 OBJS-ffserver += ffserver_config.o
diff --git a/ffmpeg.c b/ffmpeg.c
index 7c60075..652774f 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3063,6 +3063,11 @@ static int transcode_init(void)
 exit_program(1);
 #endif
 
+#if CONFIG_CUVID
+if (cuvid_transcode_init(ost))
+exit_program(1);
+#endif
+
 if (!ost->filter &&
 (enc_ctx->codec_type == AVMEDIA_TYPE_VIDEO ||
  enc_ctx->codec_type == AVMEDIA_TYPE_AUDIO)) {
diff --git a/ffmpeg.h b/ffmpeg.h
index 20a1bf7..f09d33b 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -66,6 +66,7 @@ enum HWAccelID {
 HWACCEL_VIDEOTOOLBOX,
 HWACCEL_QSV,
 HWACCEL_VAAPI,
+HWACCEL_CUVID,
 };
 
 typedef struct HWAccel {
@@ -585,5 +586,7 @@ int qsv_init(AVCodecContext *s);
 int qsv_transcode_init(OutputStream *ost);
 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
new file mode 100644
index 000..5c14267
--- /dev/null
+++ b/ffmpeg_cuvid.c
@@ -0,0 +1,217 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda.h"
+
+#include "ffmpeg.h"
+
+#include 
+#include 
+
+typedef struct CUVIDContext {
+AVBufferRef *hw_frames_ctx;
+} CUVIDContext;
+
+static void cuvid_uninit(AVCodecContext *avctx)
+{
+InputStream  *ist = avctx->opaque;
+CUVIDContext *ctx = ist->hwaccel_ctx;
+
+av_buffer_unref(&ctx->hw_frames_ctx);
+}
+
+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;
+}
+
+static void cuvid_ctx_free(AVHWDeviceContext *ctx)
+{
+AVCUDADeviceContext *hwctx = ctx->hwctx;
+cuCtxDestroy(hwctx->cuda_ctx);
+}
+
+int cuvid_transcode_init(OutputStream *ost)
+{
+InputStream *ist;
+const enum AVPixelFormat *pix_fmt;
+AVCUDADeviceContext *device_hwctx;
+AVHWDeviceContext *device_ctx;
+AVHWFramesContext *hwframe_ctx;
+CUVIDContext *ctx = NULL;
+CUdevice device;
+CUcontext cuda_ctx = NULL;
+CUcontext dummy;
+CUresult err;
+int ret = 0;
+
+av_log(NULL, AV_LOG_TRACE, "Initializing cuvid transcoding\n");
+
+if (ost->source_index < 0)
+return 0;
+
+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

Re: [FFmpeg-devel] Changelog : add OpenExr improvements

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 10:55:22PM +0200, Martin Vignali wrote:
> Hello,
> 
> In attach, patch to add entry to the changelog, for recently add OpenExr
> features
> 
> Martin

>  Changelog |1 +
>  1 file changed, 1 insertion(+)
> 55ad0a636012f50d19cdbe468b25a20fd9a2eb24  
> 0001-Changelog-add-OpenExr-improvements.patch
> From 92fcd55e4970c50e7a7be2f23aaa42f8d07fa3d0 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Mon, 6 Jun 2016 22:48:24 +0200
> Subject: [PATCH] Changelog : add OpenExr improvements

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] web/contact: Point to the Code of conduct

[Lou Logan]

On Mon,  6 Jun 2016 23:50:01 +0200, Michael Niedermayer wrote:

> Suggested-by: Felt, Patrick
> Signed-off-by: Michael Niedermayer 
> ---
>  src/contact |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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

Re: [FFmpeg-devel] [PATCH] web/contact: Point to the Code of conduct

[Michael Niedermayer]

On Mon, Jun 06, 2016 at 02:35:13PM -0800, Lou Logan wrote:
> On Mon,  6 Jun 2016 23:50:01 +0200, Michael Niedermayer wrote:
> 
> > Suggested-by: Felt, Patrick
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  src/contact |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Fine with me.

applied

thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] lavf/os_support.h: Fix for unicode filenames on windows.

[Matt Oliver]

On 6 June 2016 at 19:55, Hendrik Leppkes  wrote:

> On Mon, Jun 6, 2016 at 11:34 AM, Matt Oliver  wrote:
> > On 6 June 2016 at 19:27, Hendrik Leppkes  wrote:
> >
> >> On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver 
> wrote:
> >> > Fixes #819 #5256 #5281
> >> > ---
> >> >  libavformat/file.c   |  4 
> >> >  libavformat/os_support.h | 24 
> >> >  2 files changed, 28 insertions(+)
> >> >
> >> > diff --git a/libavformat/file.c b/libavformat/file.c
> >> > index 5765ce7..264542a 100644
> >> > --- a/libavformat/file.c
> >> > +++ b/libavformat/file.c
> >> > @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> >> >  ret |= AVIO_FLAG_WRITE;
> >> >  #else
> >> >  struct stat st;
> >> > +#   ifndef _WIN32
> >> >  ret = stat(filename, &st);
> >> > +#   else
> >> > +ret = win32_stat(filename, &st);
> >> > +#   endif
> >>
> >> Isn't the typical way to define stat to win32_stat in the os_support
> >> header, instead of ifdefing here?
> >>
> >
> > No as there is a stat struct type as well as the stat function so a
> define
> > cannot be used for the function as it will mess with the stat struct.
> Hence
> > why the only way to get around it was to manually call the appropriate
> > win32 function.
> >
> >
>
> #define stat(a,b) win32_stat(a,b) ?
> Wouldn't that avoid a clash with the struct?


Unfortunately not as the struct is also a preprocessor define set to a
different value and C doesnt allow an object type and function type to have
the same name (so its one or the other but not both).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_firequalizer: add zero_phase option

[Muhammad Faiz]

On Mon, Jun 6, 2016 at 6:46 AM, Muhammad Faiz  wrote:
> simply by substracting pts to compensate delay
> also handle AV_NOPTS_VALUE
>
> Signed-off-by: Muhammad Faiz 
> ---
>  doc/filters.texi  | 8 ++--
>  libavfilter/af_firequalizer.c | 9 -
>  libavfilter/version.h | 2 +-
>  3 files changed, 15 insertions(+), 4 deletions(-)
>

Applied

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: cqt_calc optimization on x86

[Muhammad Faiz]

On Sat, Jun 4, 2016 at 2:36 PM, Muhammad Faiz  wrote:
> benchmark on x86_64
> cqt_time:
> plain = 3.292 s
> SSE   = 1.640 s
> SSE3  = 1.631 s
> AVX   = 1.395 s
> FMA3  = 1.271 s
> FMA4  = not available
>
> untested on x86_32
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/avf_showcqt.c  |   7 ++
>  libavfilter/avf_showcqt.h  |   3 +
>  libavfilter/x86/Makefile   |   2 +
>  libavfilter/x86/avf_showcqt.asm| 206 
> +
>  libavfilter/x86/avf_showcqt_init.c |  63 
>  5 files changed, 281 insertions(+)
>  create mode 100644 libavfilter/x86/avf_showcqt.asm
>  create mode 100644 libavfilter/x86/avf_showcqt_init.c
>

I want to apply this patch but I'm not sure if it works on
x86_32 or not (I didn't test it on x86_32)

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

Re: [FFmpeg-devel] [PATCH v2 2/2] ffmpeg: Add cuvid hwaccel support

[Andrey Turkin]

2016-06-07 1:08 GMT+03:00 Timo Rothenpieler :

> +ost->enc_ctx->hw_frames_ctx = av_buffer_ref(ctx->hw_frames_ctx);
> +ost->enc_ctx->pix_fmt = AV_PIX_FMT_CUDA;
> +
> +if (!ist->hwaccel_ctx) {
> +ist->hwaccel_ctx = ctx;
> +ist->hw_frames_ctx = ctx->hw_frames_ctx;
> +ist->dec_ctx->hw_frames_ctx = av_buffer_ref(ctx->hw_frames_ctx);
>

ist->hw_frames_ctx should get new reference too; also all the references
should be checked in case av_buffer_ref fails.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/cuvid: add cuvid decoder

[Andrey Turkin]

2016-06-07 1:08 GMT+03:00 Timo Rothenpieler :

> +if (ctx->cudecoder) {
> +av_log(avctx, AV_LOG_ERROR, "re-initializing decoder is not
> supported\n");
> +ctx->internal_error = AVERROR(EINVAL);
> +return 0;
> +}
> +
> +if (hwframe_ctx->pool) {
> +av_log(avctx, AV_LOG_ERROR, "AVHWFramesContext is already
> initialized\n");
> +ctx->internal_error = AVERROR(EINVAL);
> +return 0;
> +}
>
Good enough for initial implementation but eventually should be revisited -
on-the-fly video parameter changes can occur in the wild.
Rest of ffmpeg might not be ready for changing hw_frames_ctx though.

+if (avpkt->size && filtered_packet.size) {
> +cupkt.payload_size = filtered_packet.size;
> +cupkt.payload = filtered_packet.data;
> +
> +if (filtered_packet.pts != AV_NOPTS_VALUE) {
> +cupkt.flags = CUVID_PKT_TIMESTAMP;
> +cupkt.timestamp = av_rescale_q(filtered_packet.pts,
> avctx->time_base, (AVRational){1, 1000});
> +}
> +} else {
> +cupkt.flags = CUVID_PKT_ENDOFSTREAM;
> +}
>
This works for this particular bsf but it is still a wrong logic.
filtered_packet has nothing to do with EOS signalling. If filtered_packet
is ever empty and avpkt isn't - that just means BSF didn't output anything
for that particular packet and there is nothing to do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: cqt_calc optimization on x86

[Michael Niedermayer]

On Tue, Jun 07, 2016 at 08:07:45AM +0700, Muhammad Faiz wrote:
> On Sat, Jun 4, 2016 at 2:36 PM, Muhammad Faiz  wrote:
> > benchmark on x86_64
> > cqt_time:
> > plain = 3.292 s
> > SSE   = 1.640 s
> > SSE3  = 1.631 s
> > AVX   = 1.395 s
> > FMA3  = 1.271 s
> > FMA4  = not available
> >
> > untested on x86_32
> >
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libavfilter/avf_showcqt.c  |   7 ++
> >  libavfilter/avf_showcqt.h  |   3 +
> >  libavfilter/x86/Makefile   |   2 +
> >  libavfilter/x86/avf_showcqt.asm| 206 
> > +
> >  libavfilter/x86/avf_showcqt_init.c |  63 
> >  5 files changed, 281 insertions(+)
> >  create mode 100644 libavfilter/x86/avf_showcqt.asm
> >  create mode 100644 libavfilter/x86/avf_showcqt_init.c
> >
> 
> I want to apply this patch but I'm not sure if it works on
> x86_32 or not (I didn't test it on x86_32)

i had tested fate with it applied on x86_32 earlier today but i think
this filter isnt tested with fate ...

testing x86_32 is easy:
--arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32  
--enable-cross-compile

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

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


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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: cqt_calc optimization on x86

[James Almer]

On 6/6/2016 11:49 PM, Michael Niedermayer wrote:
> On Tue, Jun 07, 2016 at 08:07:45AM +0700, Muhammad Faiz wrote:
>> On Sat, Jun 4, 2016 at 2:36 PM, Muhammad Faiz  wrote:
>>> benchmark on x86_64
>>> cqt_time:
>>> plain = 3.292 s
>>> SSE   = 1.640 s
>>> SSE3  = 1.631 s
>>> AVX   = 1.395 s
>>> FMA3  = 1.271 s
>>> FMA4  = not available
>>>
>>> untested on x86_32
>>>
>>> Signed-off-by: Muhammad Faiz 
>>> ---
>>>  libavfilter/avf_showcqt.c  |   7 ++
>>>  libavfilter/avf_showcqt.h  |   3 +
>>>  libavfilter/x86/Makefile   |   2 +
>>>  libavfilter/x86/avf_showcqt.asm| 206 
>>> +
>>>  libavfilter/x86/avf_showcqt_init.c |  63 
>>>  5 files changed, 281 insertions(+)
>>>  create mode 100644 libavfilter/x86/avf_showcqt.asm
>>>  create mode 100644 libavfilter/x86/avf_showcqt_init.c
>>>
>>
>> I want to apply this patch but I'm not sure if it works on
>> x86_32 or not (I didn't test it on x86_32)
> 
> i had tested fate with it applied on x86_32 earlier today but i think
> this filter isnt tested with fate ...

It's not http://coverage.ffmpeg.org/src/libavfilter/index.html
Most filters aren't, for that matter.

> 
> testing x86_32 is easy:
> --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32  
> --enable-cross-compile
> 
> [...]
> 
> 
> 
> ___
> 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] avfilter/avf_showcqt: cqt_calc optimization on x86

[James Almer]

On 6/4/2016 4:36 AM, Muhammad Faiz wrote:
> benchmark on x86_64
> cqt_time:
> plain = 3.292 s
> SSE   = 1.640 s
> SSE3  = 1.631 s
> AVX   = 1.395 s
> FMA3  = 1.271 s
> FMA4  = not available

Try using the START_TIMER and STOP_TIMER macros to wrap the s->cqt_calc
call in libavfilter/avf_showcqt.c
It will potentially give more accurate results than the current
UPDATE_TIME(s->cqt_time) check.

> 
> untested on x86_32

Do you have a sample command to test this? As Michael said FATE doesn't
cover showcqt.

> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/avf_showcqt.c  |   7 ++
>  libavfilter/avf_showcqt.h  |   3 +
>  libavfilter/x86/Makefile   |   2 +
>  libavfilter/x86/avf_showcqt.asm| 206 
> +
>  libavfilter/x86/avf_showcqt_init.c |  63 
>  5 files changed, 281 insertions(+)
>  create mode 100644 libavfilter/x86/avf_showcqt.asm
>  create mode 100644 libavfilter/x86/avf_showcqt_init.c
> 
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index b88c83c..62d5b09 100644
> --- a/libavfilter/avf_showcqt.c
> +++ b/libavfilter/avf_showcqt.c
> @@ -320,6 +320,9 @@ static int init_cqt(ShowCQTContext *s)
>  w *= sign * (1.0 / s->fft_len);
>  s->coeffs[m].val[x - s->coeffs[m].start] = w;
>  }
> +
> +if (s->permute_coeffs)
> +s->permute_coeffs(s->coeffs[m].val, s->coeffs[m].len);
>  }
>  
>  av_expr_free(expr);
> @@ -1230,6 +1233,7 @@ static int config_output(AVFilterLink *outlink)
>  
>  s->cqt_align = 1;
>  s->cqt_calc = cqt_calc;
> +s->permute_coeffs = NULL;
>  s->draw_sono = draw_sono;
>  if (s->format == AV_PIX_FMT_RGB24) {
>  s->draw_bar = draw_bar_rgb;
> @@ -1241,6 +1245,9 @@ static int config_output(AVFilterLink *outlink)
>  s->update_sono = update_sono_yuv;
>  }
>  
> +if (ARCH_X86)
> +ff_showcqt_init_x86(s);
> +
>  if ((ret = init_cqt(s)) < 0)
>  return ret;
>  
> diff --git a/libavfilter/avf_showcqt.h b/libavfilter/avf_showcqt.h
> index b945f49..588830f 100644
> --- a/libavfilter/avf_showcqt.h
> +++ b/libavfilter/avf_showcqt.h
> @@ -74,6 +74,7 @@ typedef struct {
>  /* callback */
>  void(*cqt_calc)(FFTComplex *dst, const FFTComplex *src, 
> const Coeffs *coeffs,
>  int len, int fft_len);
> +void(*permute_coeffs)(float *v, int len);
>  void(*draw_bar)(AVFrame *out, const float *h, const 
> float *rcp_h,
>  const ColorFloat *c, int bar_h);
>  void(*draw_axis)(AVFrame *out, AVFrame *axis, const 
> ColorFloat *c, int off);
> @@ -112,4 +113,6 @@ typedef struct {
>  int axis;
>  } ShowCQTContext;
>  
> +void ff_showcqt_init_x86(ShowCQTContext *s);
> +
>  #endif
> diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
> index 4486b79..b6195f8 100644
> --- a/libavfilter/x86/Makefile
> +++ b/libavfilter/x86/Makefile
> @@ -13,6 +13,7 @@ OBJS-$(CONFIG_PP7_FILTER)+= 
> x86/vf_pp7_init.o
>  OBJS-$(CONFIG_PSNR_FILTER)   += x86/vf_psnr_init.o
>  OBJS-$(CONFIG_PULLUP_FILTER) += x86/vf_pullup_init.o
>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= x86/vf_removegrain_init.o
> +OBJS-$(CONFIG_SHOWCQT_FILTER)+= x86/avf_showcqt_init.o
>  OBJS-$(CONFIG_SPP_FILTER)+= x86/vf_spp.o
>  OBJS-$(CONFIG_SSIM_FILTER)   += x86/vf_ssim_init.o
>  OBJS-$(CONFIG_STEREO3D_FILTER)   += x86/vf_stereo3d_init.o
> @@ -37,6 +38,7 @@ YASM-OBJS-$(CONFIG_PULLUP_FILTER)+= 
> x86/vf_pullup.o
>  ifdef CONFIG_GPL
>  YASM-OBJS-$(CONFIG_REMOVEGRAIN_FILTER)   += x86/vf_removegrain.o
>  endif
> +YASM-OBJS-$(CONFIG_SHOWCQT_FILTER)   += x86/avf_showcqt.o
>  YASM-OBJS-$(CONFIG_SSIM_FILTER)  += x86/vf_ssim.o
>  YASM-OBJS-$(CONFIG_STEREO3D_FILTER)  += x86/vf_stereo3d.o
>  YASM-OBJS-$(CONFIG_TBLEND_FILTER)+= x86/vf_blend.o
> diff --git a/libavfilter/x86/avf_showcqt.asm b/libavfilter/x86/avf_showcqt.asm
> new file mode 100644
> index 000..ba30786
> --- /dev/null
> +++ b/libavfilter/x86/avf_showcqt.asm
> @@ -0,0 +1,206 @@
> +;*
> +;* x86-optimized functions for showcqt filter
> +;*
> +;* Copyright (C) 2016 Muhammad Faiz 
> +;*
> +;* This file is part of FFmpeg.
> +;*
> +;* FFmpeg is free software; you can redistribute it and/or
> +;* modify it under the terms of the GNU Lesser General Public
> +;* License as published by the Free Software Foundation; either
> +;* version 2.1 of the License, or (at your option) any later version.
> +;*
> +;* FFmpeg is distributed in the hope that it will be useful,
> +;* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR