Re: [FFmpeg-devel] [PATCH 14/14] videotoolbox: remove opengl compatibility attribute

[Xiaolei Yu]

On 12/16/2017 02:07 PM, Wang Bin wrote:
> 2017-12-16 2:52 GMT+08:00 wm4 :
>> On Fri, 15 Dec 2017 15:02:44 +0800
>> wbse...@gmail.com wrote:
>>
>>> From: wang-bin 
>>>
>>> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl 
>>> texture, using CGLTexImageIOSurface2D for macOS, and undocumented api 
>>> texImageIOSurface(which is internally used by public api 
>>> CVOpenGLESTextureCacheCreateTextureFromImage) for iOS4.0+.
>>> 2. enabling the attribute can slow down decoding speed a lot. I tested many 
>>> video clips on my macbook air. for example: ffmpeg -ss 00:00:00 -t 00:03:00 
>>> -hwaccel videotoolbox -an -i big_buck_bunny_1080p_h264.mov -f null 
>>> ->/dev/null, result with the attribute
>>> enabled: frame= 2082 fps= 85 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>>> speed=7.34x
>>> disabled: frame= 2031 fps=104 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>>> speed=9.22x
>>> ---
>>>  libavcodec/videotoolbox.c | 5 -
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>>> index 9d2f0afa20..24631684d7 100644
>>> --- a/libavcodec/videotoolbox.c
>>> +++ b/libavcodec/videotoolbox.c
>>> @@ -664,11 +664,6 @@ static CFDictionaryRef 
>>> videotoolbox_buffer_attributes_create(int width,
>>>  CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
>>> -#if TARGET_OS_IPHONE
>>> -CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
>>> -#else
>>> -CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
>>> -#endif
>>>
>>>  CFRelease(io_surface_properties);
>>>  CFRelease(cv_pix_fmt);
>>
>> Does this have a negative effect on compatibility or performance? (In
>> both cases I'm asking about the case when actually using GL rendering.)
> 
> Disabling the attribute improves performance in my tests. I can not
> find any document about these keys. What i know is the decoded
> cvpixelbuffer is backed by iosurface, and the api to create texture
> from iosurface is available since macOS10.6

Maybe you can add a flag to make them optional?
They are documented at:
https://developer.apple.com/documentation/corevideo/kcvpixelbufferopenglescompatibilitykey
https://developer.apple.com/documentation/corevideo/kcvpixelbufferiosurfaceopengltexturecompatibilitykey

Things may still work without them but I would like to follow the documentation 
whenever possible. And I think iOS DOES require the flag for those buffers to 
be consumed through GLES.

Pure speculation here. GPU texture units usually require special memory layouts 
that may be suboptimal for the decoder. When these constraints are not met 
either the driver has to perform the conversion or you pay the penalty at 
access time.


> ___
> 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 14/14] videotoolbox: remove opengl compatibility attribute

[Wang Bin]

2017-12-16 2:52 GMT+08:00 wm4 :
> On Fri, 15 Dec 2017 15:02:44 +0800
> wbse...@gmail.com wrote:
>
>> From: wang-bin 
>>
>> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl 
>> texture, using CGLTexImageIOSurface2D for macOS, and undocumented api 
>> texImageIOSurface(which is internally used by public api 
>> CVOpenGLESTextureCacheCreateTextureFromImage) for iOS4.0+.
>> 2. enabling the attribute can slow down decoding speed a lot. I tested many 
>> video clips on my macbook air. for example: ffmpeg -ss 00:00:00 -t 00:03:00 
>> -hwaccel videotoolbox -an -i big_buck_bunny_1080p_h264.mov -f null 
>> ->/dev/null, result with the attribute
>> enabled: frame= 2082 fps= 85 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>> speed=7.34x
>> disabled: frame= 2031 fps=104 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>> speed=9.22x
>> ---
>>  libavcodec/videotoolbox.c | 5 -
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>> index 9d2f0afa20..24631684d7 100644
>> --- a/libavcodec/videotoolbox.c
>> +++ b/libavcodec/videotoolbox.c
>> @@ -664,11 +664,6 @@ static CFDictionaryRef 
>> videotoolbox_buffer_attributes_create(int width,
>>  CFDictionarySetValue(buffer_attributes, 
>> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
>> -#if TARGET_OS_IPHONE
>> -CFDictionarySetValue(buffer_attributes, 
>> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
>> -#else
>> -CFDictionarySetValue(buffer_attributes, 
>> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
>> -#endif
>>
>>  CFRelease(io_surface_properties);
>>  CFRelease(cv_pix_fmt);
>
> Does this have a negative effect on compatibility or performance? (In
> both cases I'm asking about the case when actually using GL rendering.)

Disabling the attribute improves performance in my tests. I can not
find any document about these keys. What i know is the decoded
cvpixelbuffer is backed by iosurface, and the api to create texture
from iosurface is available since macOS10.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/14] mmal: add option copy_frame to support retrieving sw frames w/o copy

[Wang Bin]

2017-12-16 2:50 GMT+08:00 wm4 :
> On Fri, 15 Dec 2017 15:05:50 +0800
> wbse...@gmail.com wrote:
>
>> From: wang-bin 
>>
>> mmal buffer->data is already in host memory. AFAIK decoders implemented in 
>> omx must
>> be configured to output frames to either memory or something directly used 
>> by renderer,
>> for example mediacodec surface, mmal buffer and omxil eglimage.
>> test result: big buck bunny 1080p fps increases from about 100 to 110 if 
>> copy_frame is
>> turned off
>> ---
>>  libavcodec/mmaldec.c | 31 +++
>>  1 file changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
>> index c1cfb09283..9cd6c6558f 100644
>> --- a/libavcodec/mmaldec.c
>> +++ b/libavcodec/mmaldec.c
>> @@ -69,6 +69,7 @@ typedef struct MMALDecodeContext {
>>  AVClass *av_class;
>>  int extra_buffers;
>>  int extra_decoder_buffers;
>> +int copy_frame;
>>
>>  MMAL_COMPONENT_T *decoder;
>>  MMAL_QUEUE_T *queue_decoded_frames;
>> @@ -139,7 +140,6 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef 
>> *pool,
>>  atomic_fetch_add_explicit(>pool->refcount, 1, 
>> memory_order_relaxed);
>>  mmal_buffer_header_acquire(buffer);
>>
>> -frame->format = AV_PIX_FMT_MMAL;
>>  frame->data[3] = (uint8_t *)ref->buffer;
>>  return 0;
>>  }
>> @@ -650,20 +650,34 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  
>> AVFrame *frame,
>>
>>  if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
>>  goto done;
>> +frame->format = AV_PIX_FMT_MMAL;
>>  } else {
>>  int w = FFALIGN(avctx->width, 32);
>>  int h = FFALIGN(avctx->height, 16);
>>  uint8_t *src[4];
>>  int linesize[4];
>>
>> -if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
>> -goto done;
>> +if (ctx->copy_frame) {
>> +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
>> +goto done;
>>
>> -av_image_fill_arrays(src, linesize,
>> - buffer->data + buffer->type->video.offset[0],
>> - avctx->pix_fmt, w, h, 1);
>> -av_image_copy(frame->data, frame->linesize, src, linesize,
>> -  avctx->pix_fmt, avctx->width, avctx->height);
>> +av_image_fill_arrays(src, linesize,
>> +buffer->data + 
>> buffer->type->video.offset[0],
>> +avctx->pix_fmt, w, h, 1);
>> +av_image_copy(frame->data, frame->linesize, src, linesize,
>> +avctx->pix_fmt, avctx->width, avctx->height);
>> +} else {
>> +if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
>> +goto done;
>> +/* buffer->type->video.offset/pitch[i]; is always 0 */
>> +av_image_fill_arrays(src, linesize,
>> +buffer->data + 
>> buffer->type->video.offset[0],
>> +avctx->pix_fmt, w, h, 1);
>> +if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
>> +goto done;
>> +memcpy(frame->data, src, sizeof(src));
>> +memcpy(frame->linesize, linesize, sizeof(linesize));
>> +}
>>  }
>>
>>  frame->pts = buffer->pts == MMAL_TIME_UNKNOWN ? AV_NOPTS_VALUE : 
>> buffer->pts;
>> @@ -842,6 +856,7 @@ AVHWAccel ff_wmv3_mmal_hwaccel = {
>>  static const AVOption options[]={
>>  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
>> extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
>>  {"extra_decoder_buffers", "extra MMAL internal buffered frames", 
>> offsetof(MMALDecodeContext, extra_decoder_buffers), AV_OPT_TYPE_INT, {.i64 = 
>> 10}, 0, 256, 0},
>> +{"copy_frame", "copy deocded data to avframe", 
>> offsetof(MMALDecodeContext, copy_frame), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 
>> 256, 0},
>>  {NULL}
>>  };
>>
>
> Didn't check too closely what exactly the patch does, but adding an
> option for it sounds very wrong. The user select in the get_format
> callback whether a GPU surface is output (MMAL pixfmt), or software.

Avoid copying data from mmal buffer->data to avframe data. Instead,
just fill strides and address of each plane in avframe, and add a
reference to mmal buffer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 07/14] mediacodec: check whether cropping is set before use

[Wang Bin]

> > +width = s->crop_right + 1 - s->crop_left;
> > +else
> > +width = s->width;
> >
> >  av_log(avctx, AV_LOG_INFO,
> >  "Output crop parameters top=%d bottom=%d left=%d right=%d, "
>
> On which device does this happen ?


None of my devices have such problem. It happens if replace jni by ndk
mediacodec functions(maybe another patch later). original code:
https://github.com/aosp-mirror/platform_frameworks_base/blob/master/media/java/android/media/MediaCodec.java#L190
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

From: ffmpeg-devel  on behalf of Compn 

Sent: Friday, December 15, 2017 9:27 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] AMD external header

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
 wrote:

> Do you think that two and half weeks is long enough to wait?
> So far except creating a repo for NVidia there is no activity.

did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.

maybe the patchset without the included header could get reviewed some
more and possibly applied while we wait for the external repo changes.

remember we are mostly volunteers working on ffmpeg. which means we all
have regular non-ffmpeg jobs.

-compn

I understand this very well and appreciate ffmpeg team spirit. I am asking just 
because I am new here and don't know what to expect.
Btw: amf encoder without headers is in the master for some time and if 
something can be improved just let me know.
Thanks,
Mikhail

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

Re: [FFmpeg-devel] [PATCH v2 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext hw_device_ctx if set

[Matthieu Bouron]

On Tue, Dec 12, 2017 at 10:33:38AM +0100, Matthieu Bouron wrote:
> On Mon, Dec 11, 2017 at 10:10:24PM +, Mark Thompson wrote:
> > On 11/12/17 12:34, Matthieu Bouron wrote:
> > >>
> > >> New patch attached fixing errors in get_format() by keeping the original
> > >> AVCodecHWConfigInternal (ad-hoc) and adding a new one (hw-device) with 
> > >> the
> > >> device_type field set to the MediaCodec.
> > >>
> > >> The updated patchset works without errors with both the old hwaccel 
> > >> method and
> > >> the new device_ctx method.
> > > 
> > > From 2bbdae2141ba8ca8db54175f4440ac8190f5953d Mon Sep 17 00:00:00 2001
> > > From: Aman Gupta 
> > > Date: Sun, 3 Dec 2017 17:32:22 -0800
> > > Subject: [PATCH 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext
> > >  hw_device_ctx if set
> > > 
> > > Signed-off-by: Matthieu Bouron 
> > > ---
> > >  libavcodec/mediacodecdec.c|  8 
> > >  libavcodec/mediacodecdec_common.c | 14 +-
> > >  2 files changed, 21 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > > index 86cc629430..c8ad0b80e7 100644
> > > --- a/libavcodec/mediacodecdec.c
> > > +++ b/libavcodec/mediacodecdec.c
> > > @@ -543,6 +543,14 @@ static const AVCodecHWConfigInternal 
> > > *mediacodec_hw_configs[] = {
> > >  },
> > >  .hwaccel = NULL,
> > >  },
> > > +&(const AVCodecHWConfigInternal) {
> > > +.public  = {
> > > +.pix_fmt = AV_PIX_FMT_MEDIACODEC,
> > > +.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX,
> > 
> > This wants to be combined with the previous entry (or together the 
> > methods): ff_get_format() looks for the first entry matching the pix_fmt, 
> > so it will never find this one.  I think this might work anyway because 
> > AD_HOC is technically "do whatever you like, I can't check it", but it also 
> > wouldn't notice e.g. a non-matching device in that case.
> 
> Patch updated with the two entries merged. Thanks.
> I tested with both methods (hw device ctx and the old hwaccel way) and no
> error came up.
> 
> -- 
> Matthieu B.

> From 7266745203a2467719f21a31c8b4f94390eaeb6b Mon Sep 17 00:00:00 2001
> From: Aman Gupta 
> Date: Sun, 3 Dec 2017 17:32:22 -0800
> Subject: [PATCH 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext
>  hw_device_ctx if set
> 
> Signed-off-by: Matthieu Bouron 
> ---
>  libavcodec/mediacodecdec.c|  5 +++--
>  libavcodec/mediacodecdec_common.c | 14 +-
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 86cc629430..7b282a1d68 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -538,8 +538,9 @@ static const AVCodecHWConfigInternal 
> *mediacodec_hw_configs[] = {
>  &(const AVCodecHWConfigInternal) {
>  .public  = {
>  .pix_fmt = AV_PIX_FMT_MEDIACODEC,
> -.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
> -.device_type = AV_HWDEVICE_TYPE_NONE,
> +.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC |
> +   AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX,
> +.device_type = AV_HWDEVICE_TYPE_MEDIACODEC,
>  },
>  .hwaccel = NULL,
>  },
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index cb2f6ae5e5..a9147f3a08 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -24,6 +24,7 @@
>  #include 
>  
>  #include "libavutil/common.h"
> +#include "libavutil/hwcontext_mediacodec.h"
>  #include "libavutil/mem.h"
>  #include "libavutil/log.h"
>  #include "libavutil/pixfmt.h"
> @@ -476,7 +477,18 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  if (pix_fmt == AV_PIX_FMT_MEDIACODEC) {
>  AVMediaCodecContext *user_ctx = avctx->hwaccel_context;
>  
> -if (user_ctx && user_ctx->surface) {
> +if (avctx->hw_device_ctx) {
> +AVHWDeviceContext *device_ctx = 
> (AVHWDeviceContext*)(avctx->hw_device_ctx->data);
> +if (device_ctx->type == AV_HWDEVICE_TYPE_MEDIACODEC) {
> +if (device_ctx->hwctx) {
> +AVMediaCodecDeviceContext *mediacodec_ctx = 
> (AVMediaCodecDeviceContext *)device_ctx->hwctx;
> +s->surface = 
> ff_mediacodec_surface_ref(mediacodec_ctx->surface, avctx);
> +av_log(avctx, AV_LOG_INFO, "Using surface %p\n", 
> s->surface);
> +}
> +}
> +}
> +
> +if (!s->surface && user_ctx && user_ctx->surface) {
>  s->surface = ff_mediacodec_surface_ref(user_ctx->surface, avctx);
>  av_log(avctx, AV_LOG_INFO, "Using surface %p\n", s->surface);
>  }
> -- 
> 2.15.1
> 

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodec_wrapper: fix potential jni global reference leak

[Matthieu Bouron]

On Thu, Dec 14, 2017 at 11:09:14AM +0100, Matthieu Bouron wrote:
> ---
>  libavcodec/mediacodec_wrapper.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 4660e895ca..f54e06b0ef 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -1194,6 +1194,9 @@ fail:
>  }
>\
>   
>\
>  if (ret < 0) {   
>\
> +if (codec->object) { 
>\
> +(*env)->DeleteGlobalRef(env, codec->object); 
>\
> +}
>\
>  ff_jni_reset_jfields(env, >jfields, jni_amediacodec_mapping, 
> 1, codec);  \
>  av_freep();
>\
>  }
>\
> -- 
> 2.15.1
> 

Rebased patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodec_wrapper: factorize MediaCodec creation functions

[Matthieu Bouron]

On Fri, Dec 15, 2017 at 04:13:22PM +0100, Matthieu Bouron wrote:
> On Thu, Dec 14, 2017 at 06:38:48PM +0100, wm4 wrote:
> > On Thu, 14 Dec 2017 18:06:11 +0100
> > Matthieu Bouron  wrote:
> > 
> > > On Thu, Dec 14, 2017 at 01:02:49PM +0100, wm4 wrote:
> > > > On Thu, 14 Dec 2017 12:53:38 +0100
> > > > Matthieu Bouron  wrote:
> > > > 
> > > > > On Thu, Dec 14, 2017 at 12:21:28PM +0100, wm4 wrote:
> > > > > > On Thu, 14 Dec 2017 11:09:13 +0100
> > > > > > Matthieu Bouron  wrote:
> > > > > >   
> > > > > > > ---
> > > > > > >  libavcodec/mediacodec_wrapper.c | 262 
> > > > > > > +++-
> > > > > > >  1 file changed, 70 insertions(+), 192 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/libavcodec/mediacodec_wrapper.c 
> > > > > > > b/libavcodec/mediacodec_wrapper.c
> > > > > > > index f34450a6d8..4660e895ca 100644
> > > > > > > --- a/libavcodec/mediacodec_wrapper.c
> > > > > > > +++ b/libavcodec/mediacodec_wrapper.c
> > > > > > > @@ -1132,200 +1132,78 @@ fail:  
> > > > > > 
> > > > > >   
> > > > > > > +#define DECLARE_FF_AMEDIACODEC_CREATE_FUNC(func, jfunc)  
> > > > > > >\
> > > > > > > +FFAMediaCodec* ff_AMediaCodec_##func(const char *arg)
> > > > > > >\
> > > > > > > +{
> > > > > > >\
> > > > > > > +int ret = -1;
> > > > > > >\
> > > > > > > +JNIEnv *env = NULL;  
> > > > > > >\
> > > > > > > +FFAMediaCodec *codec = NULL; 
> > > > > > >\
> > > > > > > +jstring jarg = NULL; 
> > > > > > >\
> > > > > > > +jobject object = NULL;   
> > > > > > >\
> > > > > > > + 
> > > > > > >\
> > > > > > > +codec = av_mallocz(sizeof(FFAMediaCodec));   
> > > > > > >\
> > > > > > > +if (!codec) {
> > > > > > >\
> > > > > > > +return NULL; 
> > > > > > >\
> > > > > > > +}
> > > > > > >\
> > > > > > > +codec->class = _class;   
> > > > > > >\
> > > > > > > + 
> > > > > > >\
> > > > > > > +env = ff_jni_get_env(codec); 
> > > > > > >\
> > > > > > > +if (!env) {  
> > > > > > >\
> > > > > > > +av_freep();
> > > > > > >\
> > > > > > > +return NULL; 
> > > > > > >\
> > > > > > > +}
> > > > > > >\
> > > > > > > + 
> > > > > > >\
> > > > > > > +if (ff_jni_init_jfields(env, >jfields, 
> > > > > > > jni_amediacodec_mapping, 1, codec) < 0) { \
> > > > > > > +goto fail;   
> > > > > > >\
> > > > > > > +}
> > > > > > >\
> > > > > > > + 
> > > > > > >\
> > > > > > > +jarg = ff_jni_utf_chars_to_jstring(env, arg, codec); 
> > > > > > >\
> > > > > > > +if (!jarg) { 
> > > > > > >\
> > > > > > > +goto fail;   
> > > > > > >\
> > > > > > > +}
> > > > > > >\
> > > > > > > + 
> > > > > > >\
> > > > > > > +object = (*env)->CallStaticObjectMethod(env, 
> > > > > > >\
> > > > > > > +   

Re: [FFmpeg-devel] [PATCH v2 1/2] libavutil/hwcontext: add AV_HWDEVICE_TYPE_MEDIACODEC

[Matthieu Bouron]

On Mon, Dec 11, 2017 at 01:27:51PM +0100, Matthieu Bouron wrote:
> On Mon, Dec 04, 2017 at 02:50:22PM +0100, Matthieu Bouron wrote:
> 
> [...]
> 
> > 
> > It works but output the following error:
> > 
> > Invalid setup for format mediacodec: does not match the type of the 
> > provided device context.
> > Invalid return from get_format(): mediacodec not in possible list.
> > 
> > avctx->get_format is set to a function that returns AV_PIX_FMT_MEDIACODEC.
> 
> New patch attached including the 2 fixes posted in my previous emails.
> 
> Regards,
> 
> --
> Matthieu B.

> From aacfb16369f4e49d67c3e8bd2528b1ebeec80d96 Mon Sep 17 00:00:00 2001
> From: Aman Gupta 
> Date: Sun, 3 Dec 2017 17:32:21 -0800
> Subject: [PATCH 1/2] libavutil/hwcontext: add AV_HWDEVICE_TYPE_MEDIACODEC
> 
> Signed-off-by: Matthieu Bouron 
> ---
>  libavutil/Makefile   |  2 ++
>  libavutil/hwcontext.c|  4 
>  libavutil/hwcontext.h|  1 +
>  libavutil/hwcontext_internal.h   |  1 +
>  libavutil/hwcontext_mediacodec.c | 50 
> 
>  libavutil/hwcontext_mediacodec.h | 36 +
>  6 files changed, 94 insertions(+)
>  create mode 100644 libavutil/hwcontext_mediacodec.c
>  create mode 100644 libavutil/hwcontext_mediacodec.h
> 
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 721784086c..66b894d66e 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -37,6 +37,7 @@ HEADERS = adler32.h 
> \
>hwcontext_drm.h   \
>hwcontext_dxva2.h \
>hwcontext_qsv.h   \
> +  hwcontext_mediacodec.h\
>hwcontext_vaapi.h \
>hwcontext_videotoolbox.h  \
>hwcontext_vdpau.h \
> @@ -166,6 +167,7 @@ OBJS-$(CONFIG_OPENCL)   += 
> hwcontext_opencl.o
>  OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
>  OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
>  OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
> +OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
>  
>  OBJS += $(COMPAT_OBJS:%=../compat/%)
>  
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index f47158f811..31ac12807b 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -55,6 +55,9 @@ static const HWContextType * const hw_table[] = {
>  #endif
>  #if CONFIG_VIDEOTOOLBOX
>  _hwcontext_type_videotoolbox,
> +#endif
> +#if CONFIG_MEDIACODEC
> +_hwcontext_type_mediacodec,
>  #endif
>  NULL,
>  };
> @@ -69,6 +72,7 @@ static const char *const hw_type_names[] = {
>  [AV_HWDEVICE_TYPE_VAAPI]  = "vaapi",
>  [AV_HWDEVICE_TYPE_VDPAU]  = "vdpau",
>  [AV_HWDEVICE_TYPE_VIDEOTOOLBOX] = "videotoolbox",
> +[AV_HWDEVICE_TYPE_MEDIACODEC] = "mediacodec",
>  };
>  
>  enum AVHWDeviceType av_hwdevice_find_type_by_name(const char *name)
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index 8d27b987df..f5a4b62387 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -35,6 +35,7 @@ enum AVHWDeviceType {
>  AV_HWDEVICE_TYPE_D3D11VA,
>  AV_HWDEVICE_TYPE_DRM,
>  AV_HWDEVICE_TYPE_OPENCL,
> +AV_HWDEVICE_TYPE_MEDIACODEC,
>  };
>  
>  typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
> index 28ff0f9ee6..332062ddaa 100644
> --- a/libavutil/hwcontext_internal.h
> +++ b/libavutil/hwcontext_internal.h
> @@ -166,5 +166,6 @@ extern const HWContextType ff_hwcontext_type_qsv;
>  extern const HWContextType ff_hwcontext_type_vaapi;
>  extern const HWContextType ff_hwcontext_type_vdpau;
>  extern const HWContextType ff_hwcontext_type_videotoolbox;
> +extern const HWContextType ff_hwcontext_type_mediacodec;
>  
>  #endif /* AVUTIL_HWCONTEXT_INTERNAL_H */
> diff --git a/libavutil/hwcontext_mediacodec.c 
> b/libavutil/hwcontext_mediacodec.c
> new file mode 100644
> index 00..b0d8993e15
> --- /dev/null
> +++ b/libavutil/hwcontext_mediacodec.c
> @@ -0,0 +1,50 @@
> +/*
> + * 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 

Re: [FFmpeg-devel] [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

[Hendrik Leppkes]

On Sat, Dec 16, 2017 at 12:04 AM, Michael Niedermayer
 wrote:
> On Fri, Dec 15, 2017 at 06:11:34PM +, Josh de Kock wrote:
>> On Fri, 15 Dec 2017 18:08:02 +
>> Josh de Kock  wrote:
>>
>> > [...]
>>
>> Attached again with the correct mime...
>>
>> --
>> Josh de Kock 
>
>>  b/libavcodec/error_resilience.c |1
>>  b/libavcodec/parser.c   |4 -
>>  b/libavcodec/utils.c|   13 ++--
>>  b/libavfilter/avfilter.c|5 +
>>  b/libavformat/format.c  |9 +--
>>  b/libavutil/Makefile|6 --
>>  b/tests/fate/libavutil.mak  |5 -
>>  libavutil/atomic.c  |  109 
>> 
>>  libavutil/atomic.h  |   79 
>>  libavutil/atomic_gcc.h  |   61 --
>>  libavutil/atomic_suncc.h|   54 ---
>>  libavutil/atomic_win32.h|   54 ---
>>  libavutil/tests/atomic.c|   38 -
>>  13 files changed, 17 insertions(+), 421 deletions(-)
>> 6c235f1bdd516f693810c7edaa8eded3e01f1405  
>> 0001-avutil-atomics-replace-avpriv-atomics-with-stdatomics.patch
>> From 2c4771a24510adfb3f6346c3fbed0554034eab3b Mon Sep 17 00:00:00 2001
>> From: Josh de Kock 
>> Date: Fri, 15 Dec 2017 09:29:55 -0800
>> Subject: [PATCH] avutil/atomics: replace avpriv atomics with stdatomics
>
> This fails to build with gcc (Ubuntu 4.8.5-2ubuntu1~14.04.1) 4.8.5
>
> make
> CC  libavfilter/avfilter.o
> libavfilter/avfilter.c: In function ‘avfilter_register’:
> libavfilter/avfilter.c:603:43: error: expected ‘)’ before ‘_Atomic’
>  while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
> >next, filter))
>^
> libavfilter/avfilter.c:603:63: warning: initialization from incompatible 
> pointer type [enabled by default]
>  while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
> >next, filter))
>^
> libavfilter/avfilter.c:603:103: error: expected ‘)’ before ‘_Atomic’
>  while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
> >next, filter))
>   
>  ^
> libavfilter/avfilter.c:603:178: error: expected ‘)’ before ‘_Atomic’
>  while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
> >next, filter))
>   
>   
>   ^
> libavfilter/avfilter.c:603:178: error: incompatible type for argument 1 of 
> ‘__sync_val_compare_and_swap’
> libavfilter/avfilter.c:603:215: error: invalid operands to binary == (have 
> ‘AVFilter’ and ‘AVFilter’)
>  while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
> >next, filter))
>   
>   
>^
> make: *** [libavfilter/avfilter.o] Error 1
>

_Atomic should probably be defined to "volatile" in both the gcc and
the msvc fallback. Still not sure the casting is really "safe" though.

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_aspect: change outlink sample aspect ratio instead of inlink

[Nicolas George]

Paul B Mahol (2017-12-15):
> More than 4 days passed.
> 
> I assume this one is OK?

Wrong assumption. If you assume instead that I had very little time
during the last five days, you are right.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

[Michael Niedermayer]

On Fri, Dec 15, 2017 at 06:11:34PM +, Josh de Kock wrote:
> On Fri, 15 Dec 2017 18:08:02 +
> Josh de Kock  wrote:
> 
> > [...]
> 
> Attached again with the correct mime...
> 
> -- 
> Josh de Kock 

>  b/libavcodec/error_resilience.c |1 
>  b/libavcodec/parser.c   |4 -
>  b/libavcodec/utils.c|   13 ++--
>  b/libavfilter/avfilter.c|5 +
>  b/libavformat/format.c  |9 +--
>  b/libavutil/Makefile|6 --
>  b/tests/fate/libavutil.mak  |5 -
>  libavutil/atomic.c  |  109 
> 
>  libavutil/atomic.h  |   79 
>  libavutil/atomic_gcc.h  |   61 --
>  libavutil/atomic_suncc.h|   54 ---
>  libavutil/atomic_win32.h|   54 ---
>  libavutil/tests/atomic.c|   38 -
>  13 files changed, 17 insertions(+), 421 deletions(-)
> 6c235f1bdd516f693810c7edaa8eded3e01f1405  
> 0001-avutil-atomics-replace-avpriv-atomics-with-stdatomics.patch
> From 2c4771a24510adfb3f6346c3fbed0554034eab3b Mon Sep 17 00:00:00 2001
> From: Josh de Kock 
> Date: Fri, 15 Dec 2017 09:29:55 -0800
> Subject: [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

This fails to build with gcc (Ubuntu 4.8.5-2ubuntu1~14.04.1) 4.8.5

make
CC  libavfilter/avfilter.o
libavfilter/avfilter.c: In function ‘avfilter_register’:
libavfilter/avfilter.c:603:43: error: expected ‘)’ before ‘_Atomic’
 while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))
   ^
libavfilter/avfilter.c:603:63: warning: initialization from incompatible 
pointer type [enabled by default]
 while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))
   ^
libavfilter/avfilter.c:603:103: error: expected ‘)’ before ‘_Atomic’
 while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))

   ^
libavfilter/avfilter.c:603:178: error: expected ‘)’ before ‘_Atomic’
 while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))


  ^
libavfilter/avfilter.c:603:178: error: incompatible type for argument 1 of 
‘__sync_val_compare_and_swap’
libavfilter/avfilter.c:603:215: error: invalid operands to binary == (have 
‘AVFilter’ and ‘AVFilter’)
 while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))


   ^
make: *** [libavfilter/avfilter.o] Error 1

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Jacob Trimble]

>> +
>> +/** The ID of the key used to encrypt the packet. */
>> +uint8_t key_id[16];
>> +
>> +/** The initialization vector. */
>> +uint8_t iv[16];
>
> what happens if the key or iv is longer ?

Both are specified by common encryption to be exactly that size.  To
be able to be
longer would require an updated spec.  Plus it avoids having to store a dynamic
string somewhere in the side data.

>
>> +
>> +/**
>> + * Only used for pattern encryption.  This is the number of 16-byte 
>> blocks
>> + * that are encrypted.
>> + */
>> +unsigned int crypt_byte_block;
>> +
>> +/**
>> + * Only used for pattern encryption.  This is the number of 16-byte 
>> blocks
>> + * that are clear.
>> + */
>> +unsigned int skip_byte_block;
>
> why is "16-byte blocks" hardcoded ?

Because that is how pattern encryption works in common encryption.  It
is specified
by number of AES blocks, not individual bytes.  I could change to
bytes, but it would
likely require the app to divide by 16 later and it runs the risk of
the value not being a
multiple of 16 like the spec requires.

>
>
>> +
>> +/**
>> + * The number of sub-samples in this packet.  If 0, then the whole 
>> sample
>> + * is encrypted.
>> + */
>> +unsigned int subsample_count;
>> +
>> +struct {
>> +  /** The number of bytes that are clear. */
>> +  unsigned int bytes_of_clear_data;
>> +
>> +  /**
>> +   * The number of bytes that are protected.  If using pattern 
>> encryption,
>> +   * the pattern applies to only the protected bytes; if not using 
>> pattern
>> +   * encryption, all these bytes are encrypted.
>> +   */
>> +  unsigned int bytes_of_protected_data;
>> +} *subsamples;
>
> Are these patterns random in practice ?
> if not they possibly would be better not repeated per packet

They are unique per packet.

For example, in H.264, certain NAL unit types should be kept in the clear, while
others should be encrypted.  Plus even for encrypted NAL units, the header
should be kept in the clear even when the payload is encrypted.

>
>
>> +} AVPacketEncryptionInfo;
>
>> +#define FF_PACKET_ENCRYPTION_INFO_SIZE(a) (sizeof(AVPacketEncryptionInfo) + 
>> sizeof(unsigned int) * a * 2)
>
> This assumes things about the padding and alignment of fields that are not
> guranteed by C i think
>

I was trying to avoid having another top-level struct.  Too bad you
can get the size
of members without an instance in c.
From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.

This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.  To allow for a
variable number of subsamples, the buffer for the side-data will be
allocated to hold both the structure and the array of subsamples.  So
the |subsamples| member will point to right after the struct.

Signed-off-by: Jacob Trimble 
---
 libavcodec/avcodec.h | 70 
 1 file changed, 70 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..ccc89345e8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1112,6 +1112,63 @@ typedef struct AVCPBProperties {
 uint64_t vbv_delay;
 } AVCPBProperties;
 
+typedef struct AVPacketSubsampleEncryptionInfo {
+/** The number of bytes that are clear. */
+unsigned int bytes_of_clear_data;
+
+/**
+ * The number of bytes that are protected.  If using pattern encryption,
+ * the pattern applies to only the protected bytes; if not using pattern
+ * encryption, all these bytes are encrypted.
+ */
+unsigned int bytes_of_protected_data;
+} AVPacketSubsampleEncryptionInfo;
+
+/**
+ * This describes encryption info for a packet.  This contains frame-specific
+ * info for how to decrypt the packet before passing it to the decoder.  If this
+ * side-data is present, then the packet is encrypted.
+ */
+typedef struct AVPacketEncryptionInfo {
+/** The fourcc encryption scheme. */
+uint32_t scheme;
+
+/** The ID of the key used to encrypt the packet. */
+uint8_t key_id[16];
+
+/** The initialization vector. */
+uint8_t iv[16];
+
+/**
+ * Only used for pattern encryption.  This is the number of 16-byte blocks
+ * that are encrypted.
+ */
+unsigned int crypt_byte_block;
+
+/**
+ * Only used for pattern encryption.  This is the number of 16-byte blocks
+ * that are clear.
+ */
+unsigned int skip_byte_block;
+
+/**
+ * The number of sub-samples in this packet.  If 0, then the whole sample
+ * is encrypted.
+ */
+unsigned int subsample_count;
+
+/** The subsample encryption info. */
+AVPacketSubsampleEncryptionInfo *subsamples;
+} AVPacketEncryptionInfo;
+/**
+ * 

[FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

[Tobias Rapp]

Based on a patch by Kieran O'Leary. Fixes ticket #6023.

Open topics:
 - is there some mapping missing in color_trc_to_dpx?
 - the default for color_trc is DPX_TRC_UNDEFINED, would it be better to
   use DPX_TRC_USER_DEFINED instead?
 - do we need a separate encoder option for the colorimetric
   specification field? If yes, do we try to map the value from frame
   color_trc/color_primaries/...?

Signed-off-by: Tobias Rapp 
---
 doc/encoders.texi   | 43 
 libavcodec/dpxenc.c | 80 +++--
 tests/ref/lavf/dpx  | 12 
 3 files changed, 127 insertions(+), 8 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 88ef8f9..f3f36bf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1312,6 +1312,49 @@ disabled
 A description of some of the currently available video encoders
 follows.
 
+@section dpx
+
+Digital Moving-Picture Exchange (DPX) image encoder.
+
+@subsection Options
+
+@table @option
+@item dpx_color_trc @var{integer}
+DPX color transfer characteristics (see Table 5A in SMPTE 268M-2003).
+
+@table @option
+@item user
+User Defined
+@item print
+Printing Density
+@item linear
+Linear
+@item log
+Logarithmic
+@item video
+Unspecified Video
+@item smpte274m
+SMPTE-274M
+@item itur709
+ITU-R 709-4
+@item itur601bg
+ITU-R 601-5 (system B or G)
+@item itur601m
+ITU-R 601-5 (system M)
+@item ntsc
+NTSC Composite Video
+@item pal
+PAL Composite Video
+@item zlinear
+Z-Linear
+@item zhomogen
+Z-Homogeneous
+@end table
+
+Default value is derived from encoder, when mapping is available.
+
+@end table
+
 @section Hap
 
 Vidvox Hap video encoder.
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index a596033..ddcd53b 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -22,17 +22,56 @@
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/pixfmt.h"
 #include "avcodec.h"
 #include "internal.h"
 
 typedef struct DPXContext {
+AVClass *class;
 int big_endian;
 int bits_per_component;
 int num_components;
 int descriptor;
 int planar;
+int color_trc;
 } DPXContext;
 
+enum DPXTransferCharacteristic {
+DPX_TRC_UNDEFINED= -1,
+DPX_TRC_USER_DEFINED = 0,
+DPX_TRC_PRINTING_DENSITY = 1,
+DPX_TRC_LINEAR   = 2,
+DPX_TRC_LOG  = 3,   // Logarithmic
+DPX_TRC_UNSPECIFIED_VIDEO= 4,
+DPX_TRC_SMPTE274M= 5,   // SMPTE 274M
+DPX_TRC_ITUR709  = 6,   // ITU-R 709-4
+DPX_TRC_ITUR601BG= 7,   // ITU-R 601-5 system B or G (625)
+DPX_TRC_ITUR601M = 8,   // ITU-R 601-5 system M (525)
+DPX_TRC_COMPOSITE_VIDEO_NTSC = 9,   // Composite video (NTSC), see SMPTE 
170M
+DPX_TRC_COMPOSITE_VIDEO_PAL  = 10,  // Composite video (PAL), see ITU-R 
624-4
+DPX_TRC_Z_LINEAR = 11,
+DPX_TRC_Z_HOMOGENEOUS= 12,
+DPX_TRC_NB
+};
+
+static int color_trc_to_dpx(enum AVColorTransferCharacteristic color_trc)
+{
+switch (color_trc) {
+case AVCOL_TRC_LINEAR:
+return DPX_TRC_LINEAR;
+case AVCOL_TRC_LOG:
+return DPX_TRC_LOG;
+case AVCOL_TRC_BT709:
+return DPX_TRC_ITUR709;
+case AVCOL_TRC_SMPTE170M:
+return DPX_TRC_COMPOSITE_VIDEO_NTSC;
+default:
+return DPX_TRC_UNDEFINED;
+}
+}
+
 static av_cold int encode_init(AVCodecContext *avctx)
 {
 DPXContext *s = avctx->priv_data;
@@ -178,6 +217,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 {
 DPXContext *s = avctx->priv_data;
 int size, ret, need_align, len;
+int color_trc = s->color_trc;
 uint8_t *buf;
 
 #define HEADER_SIZE 1664  /* DPX Generic header */
@@ -200,6 +240,14 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 return ret;
 buf = pkt->data;
 
+if (color_trc < 0)
+color_trc = color_trc_to_dpx(frame->color_trc);
+if (color_trc < 0)
+color_trc = color_trc_to_dpx(avctx->color_trc);
+av_log(avctx, AV_LOG_TRACE, "codec_color_trc:%s frame_color_trc:%s 
dpx_color_trc:%d\n",
+   av_color_transfer_name(avctx->color_trc), 
av_color_transfer_name(frame->color_trc),
+   color_trc);
+
 memset(buf, 0, HEADER_SIZE);
 
 /* File information header */
@@ -218,8 +266,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 write32(buf + 772, avctx->width);
 write32(buf + 776, avctx->height);
 buf[800] = s->descriptor;
-buf[801] = 2; /* linear transfer */
-buf[802] = 2; /* linear colorimetric */
+buf[801] = color_trc; /* transfer characteristics */
+buf[802] = color_trc; /* colorimetric specification */
 buf[803] = s->bits_per_component;
 write16(buf + 804, (s->bits_per_component == 10 || s->bits_per_component 
== 12) ?
   

Re: [FFmpeg-devel] [PATCH] compat: use external nvidia headers

[Timo Rothenpieler]

Am 15.12.2017 um 21:02 schrieb Michael Niedermayer:

On Fri, Dec 15, 2017 at 02:13:56PM +0100, Timo Rothenpieler wrote:

The external headers can be found at
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git


This installs headers without read permission

i think normally install is used instead of cp for installing files

ls -alF /usr/local/include/ffnvcodec/
total 280
drwxr-x---  2 root root   4096 Dec 15 20:55 ./
drwxr-xr-x 34 root root   4096 Dec 15 20:55 ../
-rw-r-  1 root root   3287 Dec 15 20:55 dynlink_cuda.h
-rw-r-  1 root root  44941 Dec 15 20:55 dynlink_cuviddec.h
-rw-r-  1 root root  11699 Dec 15 20:55 dynlink_loader.h
-rw-r-  1 root root  20825 Dec 15 20:55 dynlink_nvcuvid.h
-rw-r-  1 root root 189477 Dec 15 20:55 nvEncodeAPI.h

[...]



Fix pushed



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

Re: [FFmpeg-devel] [PATCH] compat: use external nvidia headers

[Michael Niedermayer]

On Fri, Dec 15, 2017 at 02:13:56PM +0100, Timo Rothenpieler wrote:
> The external headers can be found at
> https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git

This installs headers without read permission

i think normally install is used instead of cp for installing files

ls -alF /usr/local/include/ffnvcodec/
total 280
drwxr-x---  2 root root   4096 Dec 15 20:55 ./
drwxr-xr-x 34 root root   4096 Dec 15 20:55 ../
-rw-r-  1 root root   3287 Dec 15 20:55 dynlink_cuda.h
-rw-r-  1 root root  44941 Dec 15 20:55 dynlink_cuviddec.h
-rw-r-  1 root root  11699 Dec 15 20:55 dynlink_loader.h
-rw-r-  1 root root  20825 Dec 15 20:55 dynlink_nvcuvid.h
-rw-r-  1 root root 189477 Dec 15 20:55 nvEncodeAPI.h

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH v2 2/5] avformat/http: add "Opening" info logging to ff_http_do_new_request

[Aman Gupta]

On Fri, Dec 15, 2017 at 11:34 AM Michael Niedermayer 
wrote:

> On Tue, Dec 12, 2017 at 04:35:08PM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > This mimics logging that was added in 53e0d5d7247 for security
> > purposes.
> > ---
> >  libavformat/http.c | 1 +
> >  1 file changed, 1 insertion(+)
>
> iam not sure this does not cause too much noise with image sequences
> image%d.jpg for example
>
> but LGTM if that is not an issue or noone minds


Not a problem as this only affects ff_http_do_new_request, which is used
just from hls and rtmp muxers.


>
> thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Elect your leaders based on what they did after the last election, not
> based on what they say before an election.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: flag discardable packets as such

[John Stebbins]

On 12/15/2017 10:00 AM, James Almer wrote:
> On 12/15/2017 2:56 PM, John Stebbins wrote:
>> On 12/13/2017 07:14 PM, James Almer wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavformat/matroskaenc.c | 8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> This only has an effect when muxing h265 streams originating from the
>>> libx265 wrapper atm, as no other encoder or demuxer currently sets
>>> the flag.
>>>
>>> I compared the output of our muxer with the latest mkvmerge, and in
>>> the latter a few more SimpleBlocks were flagged as discardable than
>>> by our muxer after this patch.
>>> I can't say if our libx265 wrapper is not properly flagging what it
>>> should, or if mkvmerge's parser is flagging more frames than it
>>> should.
>>>
>>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>>> index f22c2ab70c..915ef3c107 100644
>>> --- a/libavformat/matroskaenc.c
>>> +++ b/libavformat/matroskaenc.c
>>> @@ -2100,7 +2100,8 @@ static void mkv_write_block(AVFormatContext *s, 
>>> AVIOContext *pb,
>>>  MatroskaMuxContext *mkv = s->priv_data;
>>>  AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
>>>  uint8_t *data = NULL, *side_data = NULL;
>>> -int offset = 0, size = pkt->size, side_data_size = 0;
>>> +const int discardable = !!(pkt->flags & AV_PKT_FLAG_DISPOSABLE);
>>> +int offset = 0, size = pkt->size, side_data_size = 0, flags = 0;
>>>  int64_t ts = mkv->tracks[pkt->stream_index].write_dts ? pkt->dts : 
>>> pkt->pts;
>>>  uint64_t additional_id = 0;
>>>  int64_t discard_padding = 0;
>>> @@ -2160,12 +2161,15 @@ static void mkv_write_block(AVFormatContext *s, 
>>> AVIOContext *pb,
>>>  blockid = MATROSKA_ID_BLOCK;
>>>  }
>>>  
>>> +if (blockid == MATROSKA_ID_SIMPLEBLOCK)
>>> +flags = (keyframe << 7) | discardable;
>>> +
>>>  put_ebml_id(pb, blockid);
>>>  put_ebml_num(pb, size + 4, 0);
>>>  // this assumes stream_index is less than 126
>>>  avio_w8(pb, 0x80 | track_number);
>>>  avio_wb16(pb, ts - mkv->cluster_pts);
>>> -avio_w8(pb, (blockid == MATROSKA_ID_SIMPLEBLOCK && keyframe) ? (1 << 
>>> 7) : 0);
>>> +avio_w8(pb, flags);
>>>  avio_write(pb, data + offset, size);
>>>  if (data != pkt->data)
>>>  av_free(data);
>> LGTM. 
>>
>> FYI, I have a pending patch that does the same thing (in a slightly 
>> different way) as well as a patch for reading the discardable flag from mkv 
>> files.
> Ah, should have known that'd be the case seeing the flag was just
> introduced.
>
>   But I wanted to wait till my other patches related to the discardable
> flag were fully reviewed and
>> accepted before adding more to the list.  As a reminder, there is still a 
>> patch to set discardable flag in the x264 encoder, a patch to read the flag 
>> in mp4 and a patch to use the flag in ffplay that are not yet accepted, 
>> though there are no unresolved
>> comments for these patch submissions.
> Do you have any idea why the output of matroskaenc differs from that of
> mkvmerge after this patch? Does libx265 (or the avcodec wrapper) not
> flag all B frames as disposable, or is mkvmerge flagging the wrong frames?
>

I'm surprised mkvmerge would flag *any* frames as disposable without the help 
of container level flags to tell it which
frames are not referenced.  Not all B frames are disposable.  And it's pretty 
difficult to determine which frames are
not referenced without actually decoding the frames (at least that's what I 
thought with my limited understanding of
hevc codec).

I ran some tests and mkvmerge is definitely marking the incorrect frames as 
disposable.  I'm able to see this with my
patches that reads the flag in matroskadec and use the flag in ffplay.  The 
weird thing is it is marking disposable
frames with the same cadence as a correctly marked file, but it's one frame too 
early.  I.e. it is marking a B-Ref and
the subsequent B frame as disposable and *not* marking the B frame that follows 
these two as disposable.  So It's not
just blindly marking B frames as disposable.

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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

Re: [FFmpeg-devel] [PATCH v2 2/5] avformat/http: add "Opening" info logging to ff_http_do_new_request

[Michael Niedermayer]

On Tue, Dec 12, 2017 at 04:35:08PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> This mimics logging that was added in 53e0d5d7247 for security
> purposes.
> ---
>  libavformat/http.c | 1 +
>  1 file changed, 1 insertion(+)

iam not sure this does not cause too much noise with image sequences
image%d.jpg for example

but LGTM if that is not an issue or noone minds

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4()

[Michael Niedermayer]

On Fri, Dec 15, 2017 at 12:30:15PM -0500, Alexander Agranovsky wrote:
> Would it be possible to cherry-pick into n3.4?

ill backport it to release/3.4

thx

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

[FFmpeg-devel] Encrypt mpeg-dash contents and Explore the headers

[Sify Browse]

I am trying to encrypt the mpeg-dash contents by passing the
encryption_scheme, encryption_key and encryption_kid to the mp4 muxer from
dash muxer. I do notice that the contents (fragmented and segmented) are
encrypted but not playable through dash players, decryption fails.

a)
Going through ffmpeg code reveals that some of the atom/box have to be
updated and added to proper atom/box (though not mandatory).
Specifications mentions that the 'senc' atom to be in the 'traf' or in
'trak' box but in the mp4 it is under the 'stbl' box. I am not sure on
which specification code was implemented. But moving 'senc' to the 'traf'
box works but for first segment as the auxiliary info's are appended and
second segment will have duplicates of first segment.So player complains
and fails to play the next chunk. Any inputs on how to segregate the 'senc'
when dash is enabled? I assume that the auxiliary information written is
for the whole file, but in the case of segmentation the 'senc' has to be
per segment and contain per segment auxiliary information. Trying to modify
auxiliary info results in the segmentation fault. Please provide some
guidance.

b) To play dash encrypted content, either we need to update the mpd file or
headers with 'pssh' atom (atom not mandatory). Do we need the 'sbgp',
'sgpd' and 'seig' boxes, inspite not mandatory? but ffmpeg is using
subsample encryption.

c) Following command generates the single file which can be playable in the
ffplay but I can not open and see the boxes through mp4 explorer. Which
tool does support to explore segmented file/s?

ffmpeg -y -loglevel info -loglevel verbose -err_detect careful
-analyzeduration 800 -probesize 400 -rtbufsize 30
-flush_packets 0 -fflags +genpts+discardcorrupt -f mpegts -i
Sample_Input.ts -i -map 0:p:1:0 -c copy -f dash -window_size 24
-min_seg_duration 4 -use_timeline true -use_template true -single_file
true live.mpd
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] DVD subtitles hacking

[Matt Zagrabelny]

On Thu, Dec 14, 2017 at 8:06 PM, Carl Eugen Hoyos 
wrote:

>
> You could implement a hack (similar to what the CC code does)
> that allows processing the subs but it is likely that the patch
> would be rejected because actual subtitle support for libavfilter
> is needed.
>

What would it take to add subtitle support to libavfilter?

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/video: pick sar from link

[Paul B Mahol]

On 12/10/17, Paul B Mahol  wrote:
> It should not be needed for each filter that sets sample aspect ratio
> to set it explicitly also for each and every frame, instead that is
> automatically done in get_buffer call.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/video.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/video.c b/libavfilter/video.c
> index 6f9020b9fe..7a8e587798 100644
> --- a/libavfilter/video.c
> +++ b/libavfilter/video.c
> @@ -43,6 +43,7 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int
> w, int h)
>
>  AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
>  {
> +AVFrame *frame = NULL;
>  int pool_width = 0;
>  int pool_height = 0;
>  int pool_align = 0;
> @@ -86,7 +87,13 @@ AVFrame *ff_default_get_video_buffer(AVFilterLink *link,
> int w, int h)
>  }
>  }
>
> -return ff_frame_pool_get(link->frame_pool);
> +frame = ff_frame_pool_get(link->frame_pool);
> +if (!frame)
> +return NULL;
> +
> +frame->sample_aspect_ratio = link->sample_aspect_ratio;
> +
> +return frame;
>  }
>
>  AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
> --
> 2.11.0
>
>

Will apply this 2 sample aspect ratio patches really soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 14/14] videotoolbox: remove opengl compatibility attribute

[wm4]

On Fri, 15 Dec 2017 15:02:44 +0800
wbse...@gmail.com wrote:

> From: wang-bin 
> 
> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl 
> texture, using CGLTexImageIOSurface2D for macOS, and undocumented api 
> texImageIOSurface(which is internally used by public api 
> CVOpenGLESTextureCacheCreateTextureFromImage) for iOS4.0+.
> 2. enabling the attribute can slow down decoding speed a lot. I tested many 
> video clips on my macbook air. for example: ffmpeg -ss 00:00:00 -t 00:03:00 
> -hwaccel videotoolbox -an -i big_buck_bunny_1080p_h264.mov -f null 
> ->/dev/null, result with the attribute
> enabled: frame= 2082 fps= 85 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
> speed=7.34x
> disabled: frame= 2031 fps=104 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
> speed=9.22x
> ---
>  libavcodec/videotoolbox.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 9d2f0afa20..24631684d7 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -664,11 +664,6 @@ static CFDictionaryRef 
> videotoolbox_buffer_attributes_create(int width,
>  CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
> -#if TARGET_OS_IPHONE
> -CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
> -#else
> -CFDictionarySetValue(buffer_attributes, 
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
> -#endif
>  
>  CFRelease(io_surface_properties);
>  CFRelease(cv_pix_fmt);

Does this have a negative effect on compatibility or performance? (In
both cases I'm asking about the case when actually using GL rendering.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/14] mmal: add option copy_frame to support retrieving sw frames w/o copy

[wm4]

On Fri, 15 Dec 2017 15:05:50 +0800
wbse...@gmail.com wrote:

> From: wang-bin 
> 
> mmal buffer->data is already in host memory. AFAIK decoders implemented in 
> omx must
> be configured to output frames to either memory or something directly used by 
> renderer,
> for example mediacodec surface, mmal buffer and omxil eglimage.
> test result: big buck bunny 1080p fps increases from about 100 to 110 if 
> copy_frame is
> turned off
> ---
>  libavcodec/mmaldec.c | 31 +++
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index c1cfb09283..9cd6c6558f 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -69,6 +69,7 @@ typedef struct MMALDecodeContext {
>  AVClass *av_class;
>  int extra_buffers;
>  int extra_decoder_buffers;
> +int copy_frame;
>  
>  MMAL_COMPONENT_T *decoder;
>  MMAL_QUEUE_T *queue_decoded_frames;
> @@ -139,7 +140,6 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
>  atomic_fetch_add_explicit(>pool->refcount, 1, memory_order_relaxed);
>  mmal_buffer_header_acquire(buffer);
>  
> -frame->format = AV_PIX_FMT_MMAL;
>  frame->data[3] = (uint8_t *)ref->buffer;
>  return 0;
>  }
> @@ -650,20 +650,34 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  
> AVFrame *frame,
>  
>  if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
>  goto done;
> +frame->format = AV_PIX_FMT_MMAL;
>  } else {
>  int w = FFALIGN(avctx->width, 32);
>  int h = FFALIGN(avctx->height, 16);
>  uint8_t *src[4];
>  int linesize[4];
>  
> -if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> -goto done;
> +if (ctx->copy_frame) {
> +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> +goto done;
>  
> -av_image_fill_arrays(src, linesize,
> - buffer->data + buffer->type->video.offset[0],
> - avctx->pix_fmt, w, h, 1);
> -av_image_copy(frame->data, frame->linesize, src, linesize,
> -  avctx->pix_fmt, avctx->width, avctx->height);
> +av_image_fill_arrays(src, linesize,
> +buffer->data + buffer->type->video.offset[0],
> +avctx->pix_fmt, w, h, 1);
> +av_image_copy(frame->data, frame->linesize, src, linesize,
> +avctx->pix_fmt, avctx->width, avctx->height);
> +} else {
> +if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
> +goto done;
> +/* buffer->type->video.offset/pitch[i]; is always 0 */
> +av_image_fill_arrays(src, linesize,
> +buffer->data + buffer->type->video.offset[0],
> +avctx->pix_fmt, w, h, 1);
> +if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
> +goto done;
> +memcpy(frame->data, src, sizeof(src));
> +memcpy(frame->linesize, linesize, sizeof(linesize));
> +}
>  }
>  
>  frame->pts = buffer->pts == MMAL_TIME_UNKNOWN ? AV_NOPTS_VALUE : 
> buffer->pts;
> @@ -842,6 +856,7 @@ AVHWAccel ff_wmv3_mmal_hwaccel = {
>  static const AVOption options[]={
>  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
> extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
>  {"extra_decoder_buffers", "extra MMAL internal buffered frames", 
> offsetof(MMALDecodeContext, extra_decoder_buffers), AV_OPT_TYPE_INT, {.i64 = 
> 10}, 0, 256, 0},
> +{"copy_frame", "copy deocded data to avframe", 
> offsetof(MMALDecodeContext, copy_frame), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 
> 256, 0},
>  {NULL}
>  };
>  

Didn't check too closely what exactly the patch does, but adding an
option for it sounds very wrong. The user select in the get_format
callback whether a GPU surface is output (MMAL pixfmt), or software.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 08/14] avcodec: add AV_HWACCEL_FLAG_ALLOW_SOFTWARE

[wm4]

On Fri, 15 Dec 2017 15:18:13 +0800
Jun Zhao  wrote:

> On 2017/12/15 15:03, wbse...@gmail.com wrote:
> > From: wang-bin 
> >
> > a hw decoder may have software or hybrid implementation, for example 
> > videotoolbox hevc.
> > the performance may be better than ffmpeg sw decoder.  
> It's confused, and I think wm4 give a other patch for this case. you can
> refer to
> https://patchwork.ffmpeg.org/patch/6773/

My patch was just static metadata, so this is different.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs()

[Michael Niedermayer]

Fixes: signed integer overflow: 2147483647 + 1073741824 cannot be represented 
in type 'int'
Fixes: 4555/clusterfuzz-testcase-minimized-4505532481142784

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

diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
index 853fd3f722..5b5da1165a 100644
--- a/libavcodec/hevc_cabac.c
+++ b/libavcodec/hevc_cabac.c
@@ -646,8 +646,10 @@ int ff_hevc_cu_qp_delta_abs(HEVCContext *s)
 suffix_val += 1 << k;
 k++;
 }
-if (k == CABAC_MAX_BIN)
+if (k == CABAC_MAX_BIN) {
 av_log(s->avctx, AV_LOG_ERROR, "CABAC_MAX_BIN : %d\n", k);
+return AVERROR_INVALIDDATA;
+}
 
 while (k--)
 suffix_val += get_cabac_bypass(>HEVClc->cc) << k;
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 2/3] avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message()

[Michael Niedermayer]

Fixes: signed integer overflow: 2147483520 + 255 cannot be represented in type 
'int'
Fixes: 4554/clusterfuzz-testcase-minimized-4843714515042304

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

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 8dd975508a..c59bd4321e 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -324,11 +324,15 @@ static int decode_nal_sei_message(GetBitContext *gb, void 
*logctx, HEVCSEI *s,
 av_log(logctx, AV_LOG_DEBUG, "Decoding SEI\n");
 
 while (byte == 0xFF) {
+if (get_bits_left(gb) < 16 || payload_type > INT_MAX - 255)
+return AVERROR_INVALIDDATA;
 byte  = get_bits(gb, 8);
 payload_type += byte;
 }
 byte = 0xFF;
 while (byte == 0xFF) {
+if (get_bits_left(gb) < 8 + 8LL*payload_size)
+return AVERROR_INVALIDDATA;
 byte  = get_bits(gb, 8);
 payload_size += byte;
 }
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 1/3] avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv()

[Michael Niedermayer]

Fixes: runtime error: left shift of negative value -3
Fixes: 4524/clusterfuzz-testcase-minimized-6055590120914944

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

diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 0623cfad89..4017af8eb0 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -1051,7 +1051,7 @@ static void FUNC(put_hevc_qpel_bi_w_hv)(uint8_t *_dst, 
ptrdiff_t _dststride, uin
 for (y = 0; y < height; y++) {
 for (x = 0; x < width; x++)
 dst[x] = av_clip_pixel(((QPEL_FILTER(tmp, MAX_PB_SIZE) >> 6) * wx1 
+ src2[x] * wx0 +
-((ox0 + ox1 + 1) << log2Wd)) >> (log2Wd + 
1));
+((ox0 + ox1 + 1) * (1 << log2Wd))) >> 
(log2Wd + 1));
 tmp  += MAX_PB_SIZE;
 dst  += dststride;
 src2 += MAX_PB_SIZE;
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH v2 0/5] avformat/hls: improve network performance

[Aman Gupta]

On Tue, Dec 12, 2017 at 4:35 PM Aman Gupta  wrote:

> From: Aman Gupta 
>
> This patchset improves the overall network performance of the hls
> demuxer when streaming from an HTTP/1.1 server, using two new
> options: http_persistent and http_multiple.
>
> Here is a very unscientific benchmark showing the throughput and fps
> increases achieved by both options (individually and together). In
> this case I was downloading 150 2s segments from another computer
> over my local network. Throughput gains over the internet would be
> considerably more dramatic as higher latencies are involved (and
> https is often used, adding tls negotiation overhead as well).
>
> $ ./ffmpeg -http_persistent 0 -http_multiple 0 \
>-i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
> frame=17967 fps=1221 time=00:04:59.99 speed=20.4x
>
> $ ./ffmpeg -http_persistent 0 -http_multiple 1 \
>-i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
> frame=17967 fps=1282 time=00:04:59.99 speed=21.4x
>
> $ ./ffmpeg -http_persistent 1 -http_multiple 0 \
>-i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
> frame=17967 fps=1727 time=00:04:59.99 speed=28.8x
>
> $ ./ffmpeg -http_persistent 1 -http_multiple 1 \
>-i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
> frame=17967 fps=1864 time=00:04:59.99 speed=31.1x
>
> Aman Gupta (5):
>   avformat/http: ff_http_do_new_request() returns EINVAL if re-used with
> different hostname
>   avformat/http: add "Opening" info logging to ff_http_do_new_request
>   avformat/hls: add http_persistent option
>   avformat/hls: allow open_input to be re-used
>   avformat/hls: add http_multiple option
>
>  doc/demuxers.texi  |   6 +++
>  libavformat/hls.c  | 131
> +++--
>  libavformat/http.c |  17 +++
>  3 files changed, 141 insertions(+), 13 deletions(-)


Ping.


>
> --
> 2.14.3 (Apple Git-98)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

[Josh de Kock]

On Fri, 15 Dec 2017 18:08:02 +
Josh de Kock  wrote:

> [...]

Attached again with the correct mime...

-- 
Josh de Kock 
>From 2c4771a24510adfb3f6346c3fbed0554034eab3b Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Fri, 15 Dec 2017 09:29:55 -0800
Subject: [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

---
 libavcodec/error_resilience.c |   1 -
 libavcodec/parser.c   |   4 +-
 libavcodec/utils.c|  13 +++--
 libavfilter/avfilter.c|   5 +-
 libavformat/format.c  |   9 ++--
 libavutil/Makefile|   6 ---
 libavutil/atomic.c| 109 --
 libavutil/atomic.h|  79 --
 libavutil/atomic_gcc.h|  61 ---
 libavutil/atomic_suncc.h  |  54 -
 libavutil/atomic_win32.h  |  54 -
 libavutil/tests/atomic.c  |  38 ---
 tests/fate/libavutil.mak  |   5 --
 13 files changed, 17 insertions(+), 421 deletions(-)
 delete mode 100644 libavutil/atomic.c
 delete mode 100644 libavutil/atomic.h
 delete mode 100644 libavutil/atomic_gcc.h
 delete mode 100644 libavutil/atomic_suncc.h
 delete mode 100644 libavutil/atomic_win32.h
 delete mode 100644 libavutil/tests/atomic.c

diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index 8f172be..55f7796 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -27,7 +27,6 @@
 
 #include 
 
-#include "libavutil/atomic.h"
 #include "libavutil/internal.h"
 #include "avcodec.h"
 #include "error_resilience.h"
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 670680e..0866eef 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -23,9 +23,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "libavutil/avassert.h"
-#include "libavutil/atomic.h"
 #include "libavutil/internal.h"
 #include "libavutil/mem.h"
 
@@ -46,7 +46,7 @@ void av_register_codec_parser(AVCodecParser *parser)
 {
 do {
 parser->next = av_first_parser;
-} while (parser->next != avpriv_atomic_ptr_cas((void * volatile 
*)_first_parser, parser->next, parser));
+} while (!atomic_compare_exchange_weak((AVCodecParser * _Atomic 
*)_first_parser, >next, parser));
 }
 
 AVCodecParserContext *av_parser_init(int codec_id)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 873f39f..ad3d79e 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -25,8 +25,9 @@
  * utils.
  */
 
+#include 
+
 #include "config.h"
-#include "libavutil/atomic.h"
 #include "libavutil/attributes.h"
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
@@ -70,7 +71,8 @@ const char av_codec_ffversion[] = "FFmpeg version " 
FFMPEG_VERSION;
 #if HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS
 static int default_lockmgr_cb(void **arg, enum AVLockOp op)
 {
-void * volatile * mutex = arg;
+void * _Atomic * mutex = (void * _Atomic *)arg;
+void *null_mutex = NULL;
 int err;
 
 switch (op) {
@@ -85,7 +87,7 @@ static int default_lockmgr_cb(void **arg, enum AVLockOp op)
 av_free(tmp);
 return AVERROR(err);
 }
-if (avpriv_atomic_ptr_cas(mutex, NULL, tmp)) {
+if (!atomic_compare_exchange_weak(mutex, _mutex, tmp)) {
 pthread_mutex_destroy(tmp);
 av_free(tmp);
 }
@@ -104,7 +106,7 @@ static int default_lockmgr_cb(void **arg, enum AVLockOp op)
 if (*mutex)
 pthread_mutex_destroy(*mutex);
 av_free(*mutex);
-avpriv_atomic_ptr_cas(mutex, *mutex, NULL);
+atomic_compare_exchange_weak(mutex, mutex, NULL);
 return 0;
 }
 return 1;
@@ -185,8 +187,9 @@ av_cold void avcodec_register(AVCodec *codec)
 p = last_avcodec;
 codec->next = NULL;
 
-while(*p || avpriv_atomic_ptr_cas((void * volatile *)p, NULL, codec))
+while(*p || !atomic_compare_exchange_weak((AVCodec *_Atomic *)p, 
>next, codec))
 p = &(*p)->next;
+
 last_avcodec = >next;
 
 if (codec->init_static_data)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b98b32b..c0dc054 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -19,7 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "libavutil/atomic.h"
+#include 
+
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
 #include "libavutil/buffer.h"
@@ -599,7 +600,7 @@ int avfilter_register(AVFilter *filter)
 
 filter->next = NULL;
 
-while(*f || avpriv_atomic_ptr_cas((void * volatile *)f, NULL, filter))
+while(*f || !atomic_compare_exchange_weak((AVFilter* _Atomic*) f, 
>next, filter))
 f = &(*f)->next;
 last_filter = >next;
 
diff --git a/libavformat/format.c b/libavformat/format.c
index 38ca2a3..9acfecd 100644
--- 

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: flag discardable packets as such

[James Almer]

On 12/15/2017 2:56 PM, John Stebbins wrote:
> On 12/13/2017 07:14 PM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/matroskaenc.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> This only has an effect when muxing h265 streams originating from the
>> libx265 wrapper atm, as no other encoder or demuxer currently sets
>> the flag.
>>
>> I compared the output of our muxer with the latest mkvmerge, and in
>> the latter a few more SimpleBlocks were flagged as discardable than
>> by our muxer after this patch.
>> I can't say if our libx265 wrapper is not properly flagging what it
>> should, or if mkvmerge's parser is flagging more frames than it
>> should.
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index f22c2ab70c..915ef3c107 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -2100,7 +2100,8 @@ static void mkv_write_block(AVFormatContext *s, 
>> AVIOContext *pb,
>>  MatroskaMuxContext *mkv = s->priv_data;
>>  AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
>>  uint8_t *data = NULL, *side_data = NULL;
>> -int offset = 0, size = pkt->size, side_data_size = 0;
>> +const int discardable = !!(pkt->flags & AV_PKT_FLAG_DISPOSABLE);
>> +int offset = 0, size = pkt->size, side_data_size = 0, flags = 0;
>>  int64_t ts = mkv->tracks[pkt->stream_index].write_dts ? pkt->dts : 
>> pkt->pts;
>>  uint64_t additional_id = 0;
>>  int64_t discard_padding = 0;
>> @@ -2160,12 +2161,15 @@ static void mkv_write_block(AVFormatContext *s, 
>> AVIOContext *pb,
>>  blockid = MATROSKA_ID_BLOCK;
>>  }
>>  
>> +if (blockid == MATROSKA_ID_SIMPLEBLOCK)
>> +flags = (keyframe << 7) | discardable;
>> +
>>  put_ebml_id(pb, blockid);
>>  put_ebml_num(pb, size + 4, 0);
>>  // this assumes stream_index is less than 126
>>  avio_w8(pb, 0x80 | track_number);
>>  avio_wb16(pb, ts - mkv->cluster_pts);
>> -avio_w8(pb, (blockid == MATROSKA_ID_SIMPLEBLOCK && keyframe) ? (1 << 7) 
>> : 0);
>> +avio_w8(pb, flags);
>>  avio_write(pb, data + offset, size);
>>  if (data != pkt->data)
>>  av_free(data);
> 
> LGTM. 
> 
> FYI, I have a pending patch that does the same thing (in a slightly different 
> way) as well as a patch for reading the discardable flag from mkv files.

Ah, should have known that'd be the case seeing the flag was just
introduced.

  But I wanted to wait till my other patches related to the discardable
flag were fully reviewed and
> accepted before adding more to the list.  As a reminder, there is still a 
> patch to set discardable flag in the x264 encoder, a patch to read the flag 
> in mp4 and a patch to use the flag in ffplay that are not yet accepted, 
> though there are no unresolved
> comments for these patch submissions.

Do you have any idea why the output of matroskaenc differs from that of
mkvmerge after this patch? Does libx265 (or the avcodec wrapper) not
flag all B frames as disposable, or is mkvmerge flagging the wrong frames?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/atomics: replace avpriv atomics with stdatomics

[Josh de Kock]

Hi,

Sorry for sending this patch as an attachment, struggling to get email working 
properly on new setup.

This patch replaces the current avpriv atomics with stdatomics. It passes fate 
on the latest macOS and the lastest LTS Ubuntu Linux. I haven't tested it on 
Windows as I don't know too much about development on the platform, but I've 
been told that _Atomic may not be available on it.

-- 
Josh de Kock 


0001-avutil-atomics-replace-avpriv-atomics-with-stdatomics.patch
Description: plain/text
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: flag discardable packets as such

[John Stebbins]

On 12/13/2017 07:14 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> This only has an effect when muxing h265 streams originating from the
> libx265 wrapper atm, as no other encoder or demuxer currently sets
> the flag.
>
> I compared the output of our muxer with the latest mkvmerge, and in
> the latter a few more SimpleBlocks were flagged as discardable than
> by our muxer after this patch.
> I can't say if our libx265 wrapper is not properly flagging what it
> should, or if mkvmerge's parser is flagging more frames than it
> should.
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index f22c2ab70c..915ef3c107 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2100,7 +2100,8 @@ static void mkv_write_block(AVFormatContext *s, 
> AVIOContext *pb,
>  MatroskaMuxContext *mkv = s->priv_data;
>  AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
>  uint8_t *data = NULL, *side_data = NULL;
> -int offset = 0, size = pkt->size, side_data_size = 0;
> +const int discardable = !!(pkt->flags & AV_PKT_FLAG_DISPOSABLE);
> +int offset = 0, size = pkt->size, side_data_size = 0, flags = 0;
>  int64_t ts = mkv->tracks[pkt->stream_index].write_dts ? pkt->dts : 
> pkt->pts;
>  uint64_t additional_id = 0;
>  int64_t discard_padding = 0;
> @@ -2160,12 +2161,15 @@ static void mkv_write_block(AVFormatContext *s, 
> AVIOContext *pb,
>  blockid = MATROSKA_ID_BLOCK;
>  }
>  
> +if (blockid == MATROSKA_ID_SIMPLEBLOCK)
> +flags = (keyframe << 7) | discardable;
> +
>  put_ebml_id(pb, blockid);
>  put_ebml_num(pb, size + 4, 0);
>  // this assumes stream_index is less than 126
>  avio_w8(pb, 0x80 | track_number);
>  avio_wb16(pb, ts - mkv->cluster_pts);
> -avio_w8(pb, (blockid == MATROSKA_ID_SIMPLEBLOCK && keyframe) ? (1 << 7) 
> : 0);
> +avio_w8(pb, flags);
>  avio_write(pb, data + offset, size);
>  if (data != pkt->data)
>  av_free(data);

LGTM. 

FYI, I have a pending patch that does the same thing (in a slightly different 
way) as well as a patch for reading the discardable flag from mkv files.  But I 
wanted to wait till my other patches related to the discardable flag were fully 
reviewed and
accepted before adding more to the list.  As a reminder, there is still a patch 
to set discardable flag in the x264 encoder, a patch to read the flag in mp4 
and a patch to use the flag in ffplay that are not yet accepted, though there 
are no unresolved
comments for these patch submissions.

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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] avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4()

[Alexander Agranovsky]

Would it be possible to cherry-pick into n3.4?

Thanks!


On 12/2/17 20:02, Michael Niedermayer wrote:

On Sat, Nov 25, 2017 at 11:08:46PM +0100, Clément Bœsch wrote:

On Sat, Nov 25, 2017 at 10:49:09PM +0100, Michael Niedermayer wrote:

Fixes: lorex.mp4

Signed-off-by: Michael Niedermayer 
---
  libavcodec/h264_parse.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index a7c71d9bbb..9216d0bdbd 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -427,8 +427,6 @@ static int decode_extradata_ps_mp4(const uint8_t *buf, int 
buf_size, H264ParamSe
  
  ret = decode_extradata_ps(escaped_buf, escaped_buf_size, ps, 1, logctx);

  av_freep(_buf);
-if (ret < 0)
-return ret;

If you don't want the return code to be reintroduced differently 10x in
the future (like, someone deciding to return ret in the function instead
of 0), I'd suggest 2 things:

- use "(void)decode_extradata_ps(...)" to explicitly ignore the code
   return; it's a hint for the compiler and the developer, typically used
   in OpenBSD (I believe that's because they warn about unchecked return
   code by default)
- add a comment above about the why

will push with these changes

thx

[...]



___
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] HW accelerator: Indicate when hardware acceleration is used for processing encode or decode.

[Mark Thompson]

On 15/12/17 00:03, Michele Lim wrote:
> Clear indication of when a hardware accelerator is in operation
> prevents false assumptions in situations when the command line
> argument inadvertently omits certain required options for
> enabling it.
> ---
>  libavutil/hwcontext_vaapi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 29698d1..0decf6d 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1193,8 +1193,11 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
>  AVVAAPIDeviceContext *hwctx = ctx->hwctx;
>  VAAPIDevicePriv  *priv  = ctx->user_opaque;
>  
> -if (hwctx->display)
> +if (hwctx->display)  {
>  vaTerminate(hwctx->display);
> +/* Indicate hardware acceleration was utilized to complete either 
> encode or decode */
> +av_log(ctx, AV_LOG_INFO, "Processing completed with HW 
> acceleration\n");
> +}
>  
>  #if HAVE_VAAPI_X11
>  if (priv->x11_display)
> 

Closing a device does not tell you anything about whether it was used.

E.g. consider:

ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i vp8-input.webm 
-an -f null -

where /dev/dri/renderD128 is a device which does not support VP8.  With this 
patch you would get:

...
Stream #0:0(eng): Video: vp8, yuv420p(progressive), 540x360, SAR 1:1 DAR 
3:2, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
...
[vp8 @ 0x564d9be02c80] No support for codec vp8 profile 1.
[vp8 @ 0x564d9be02c80] Failed setup for format vaapi_vld: hwaccel 
initialisation returned error.
...
Stream #0:0(eng): Video: wrapped_avframe, yuv420p, 540x360 [SAR 1:1 DAR 
3:2], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc (default)
...
[AVHWDeviceContext @ 0x55d57926ab00] Processing completed with HW acceleration

Except, it wasn't.

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

[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Persistent HTTP connections supported as an option

[Karthick J]

From: Karthick Jeyapal 

---
 libavformat/dashenc.c | 67 +--
 1 file changed, 54 insertions(+), 13 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5687530..e7d1a0d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -37,6 +37,9 @@
 #include "avformat.h"
 #include "avio_internal.h"
 #include "hlsplaylist.h"
+#if CONFIG_HTTP_PROTOCOL
+#include "http.h"
+#endif
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -103,7 +106,10 @@ typedef struct DASHContext {
 const char *utc_timing_url;
 const char *user_agent;
 int hls_playlist;
+int http_persistent;
 int master_playlist_created;
+AVIOContext *mpd_out;
+AVIOContext *m3u8_out;
 } DASHContext;
 
 static struct codec_string {
@@ -117,6 +123,36 @@ static struct codec_string {
 { 0, NULL }
 };
 
+static int dashenc_io_open(AVFormatContext *s, AVIOContext **pb, char 
*filename,
+   AVDictionary **options) {
+DASHContext *c = s->priv_data;
+int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
+int err = AVERROR_MUXER_NOT_FOUND;
+if (!*pb || !http_base_proto || !c->http_persistent) {
+err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
+#if CONFIG_HTTP_PROTOCOL
+} else {
+URLContext *http_url_context = ffio_geturlcontext(*pb);
+av_assert0(http_url_context);
+err = ff_http_do_new_request(http_url_context, filename);
+#endif
+}
+return err;
+}
+
+static void dashenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
+DASHContext *c = s->priv_data;
+int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
+
+if (!http_base_proto || !c->http_persistent) {
+ff_format_io_close(s, pb);
+#if CONFIG_HTTP_PROTOCOL
+} else {
+avio_flush(*pb);
+#endif
+}
+}
+
 static void set_codec_str(AVFormatContext *s, AVCodecParameters *par,
   char *str, int size)
 {
@@ -218,6 +254,8 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 {
 if (c->user_agent)
 av_dict_set(options, "user_agent", c->user_agent, 0);
+if (c->http_persistent)
+av_dict_set_int(options, "multiple_requests", 1, 0);
 }
 
 static void get_hls_playlist_name(char *playlist_name, int string_size,
@@ -273,9 +311,10 @@ static void dash_free(AVFormatContext *s)
 av_freep(>streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
AVFormatContext *s,
 int representation_id, int final)
 {
+DASHContext *c = s->priv_data;
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
 start_index  = FFMAX(os->nb_segments   - c->window_size, 0);
@@ -339,7 +378,6 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 int timescale = os->ctx->streams[0]->time_base.den;
 char temp_filename_hls[1024];
 char filename_hls[1024];
-AVIOContext *out_hls = NULL;
 AVDictionary *http_opts = NULL;
 int target_duration = 0;
 int ret = 0;
@@ -352,7 +390,7 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
 
 set_http_options(_opts, c);
-avio_open2(_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
_opts);
+dashenc_io_open(s, >m3u8_out, temp_filename_hls, _opts);
 av_dict_free(_opts);
 for (i = start_index; i < os->nb_segments; i++) {
 Segment *seg = os->segments[i];
@@ -361,15 +399,15 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 target_duration = hls_get_int_from_double(duration);
 }
 
-ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
+ff_hls_write_playlist_header(c->m3u8_out, 6, -1, target_duration,
  start_number, PLAYLIST_TYPE_NONE);
 
-ff_hls_write_init_file(out_hls, os->initfile, c->single_file,
+ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
 
 for (i = start_index; i < os->nb_segments; i++) {
 Segment *seg = os->segments[i];
-ret = ff_hls_write_file_entry(out_hls, 0, c->single_file,
+ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
 (double) seg->duration / timescale, 0,
 seg->range_length, seg->start_pos, NULL,
 c->single_file ? os->initfile : seg->file,
@@ -380,9 +418,10 @@ static void 

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc, utils: Moved is_http_proto from hlsenc to utils for re-use

[Karthick J]

From: Karthick Jeyapal 

---
 libavformat/hlsenc.c   | 12 +++-
 libavformat/internal.h |  8 
 libavformat/utils.c|  5 +
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e3442c3..03d54c7 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -240,15 +240,10 @@ static int mkdir_p(const char *path) {
 return ret;
 }
 
-static int is_http_proto(char *filename) {
-const char *proto = avio_find_protocol_name(filename);
-return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
"https")) : 0;
-}
-
 static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
   AVDictionary **options) {
 HLSContext *hls = s->priv_data;
-int http_base_proto = filename ? is_http_proto(filename) : 0;
+int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
 int err = AVERROR_MUXER_NOT_FOUND;
 if (!*pb || !http_base_proto || !hls->http_persistent) {
 err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
@@ -264,8 +259,7 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 
 static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
 HLSContext *hls = s->priv_data;
-int http_base_proto = filename ? is_http_proto(filename) : 0;
-
+int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
 } else {
@@ -275,7 +269,7 @@ static void hlsenc_io_close(AVFormatContext *s, AVIOContext 
**pb, char *filename
 
 static void set_http_options(AVFormatContext *s, AVDictionary **options, 
HLSContext *c)
 {
-int http_base_proto = is_http_proto(s->filename);
+int http_base_proto = ff_is_http_proto(s->filename);
 
 if (c->method) {
 av_dict_set(options, "method", c->method, 0);
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 36a5721..8f168c9 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -619,6 +619,14 @@ int ff_format_output_open(AVFormatContext *s, const char 
*url, AVDictionary **op
 void ff_format_io_close(AVFormatContext *s, AVIOContext **pb);
 
 /**
+ * Utility function to check if the file uses http or https protocol
+ *
+ * @param s AVFormatContext
+ * @param filename URL or file name to open for writing
+ */
+int ff_is_http_proto(char *filename);
+
+/**
  * Parse creation_time in AVFormatContext metadata if exists and warn if the
  * parsing fails.
  *
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 84e4920..f18a7c8 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5459,6 +5459,11 @@ void ff_format_io_close(AVFormatContext *s, AVIOContext 
**pb)
 *pb = NULL;
 }
 
+int ff_is_http_proto(char *filename) {
+const char *proto = avio_find_protocol_name(filename);
+return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
"https")) : 0;
+}
+
 int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp, 
int return_seconds)
 {
 AVDictionaryEntry *entry;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodec_wrapper: factorize MediaCodec creation functions

[Matthieu Bouron]

On Thu, Dec 14, 2017 at 06:38:48PM +0100, wm4 wrote:
> On Thu, 14 Dec 2017 18:06:11 +0100
> Matthieu Bouron  wrote:
> 
> > On Thu, Dec 14, 2017 at 01:02:49PM +0100, wm4 wrote:
> > > On Thu, 14 Dec 2017 12:53:38 +0100
> > > Matthieu Bouron  wrote:
> > > 
> > > > On Thu, Dec 14, 2017 at 12:21:28PM +0100, wm4 wrote:
> > > > > On Thu, 14 Dec 2017 11:09:13 +0100
> > > > > Matthieu Bouron  wrote:
> > > > >   
> > > > > > ---
> > > > > >  libavcodec/mediacodec_wrapper.c | 262 
> > > > > > +++-
> > > > > >  1 file changed, 70 insertions(+), 192 deletions(-)
> > > > > > 
> > > > > > diff --git a/libavcodec/mediacodec_wrapper.c 
> > > > > > b/libavcodec/mediacodec_wrapper.c
> > > > > > index f34450a6d8..4660e895ca 100644
> > > > > > --- a/libavcodec/mediacodec_wrapper.c
> > > > > > +++ b/libavcodec/mediacodec_wrapper.c
> > > > > > @@ -1132,200 +1132,78 @@ fail:  
> > > > > 
> > > > >   
> > > > > > +#define DECLARE_FF_AMEDIACODEC_CREATE_FUNC(func, jfunc)
> > > > > >  \
> > > > > > +FFAMediaCodec* ff_AMediaCodec_##func(const char *arg)  
> > > > > >  \
> > > > > > +{  
> > > > > >  \
> > > > > > +int ret = -1;  
> > > > > >  \
> > > > > > +JNIEnv *env = NULL;
> > > > > >  \
> > > > > > +FFAMediaCodec *codec = NULL;   
> > > > > >  \
> > > > > > +jstring jarg = NULL;   
> > > > > >  \
> > > > > > +jobject object = NULL; 
> > > > > >  \
> > > > > > +   
> > > > > >  \
> > > > > > +codec = av_mallocz(sizeof(FFAMediaCodec)); 
> > > > > >  \
> > > > > > +if (!codec) {  
> > > > > >  \
> > > > > > +return NULL;   
> > > > > >  \
> > > > > > +}  
> > > > > >  \
> > > > > > +codec->class = _class; 
> > > > > >  \
> > > > > > +   
> > > > > >  \
> > > > > > +env = ff_jni_get_env(codec);   
> > > > > >  \
> > > > > > +if (!env) {
> > > > > >  \
> > > > > > +av_freep();  
> > > > > >  \
> > > > > > +return NULL;   
> > > > > >  \
> > > > > > +}  
> > > > > >  \
> > > > > > +   
> > > > > >  \
> > > > > > +if (ff_jni_init_jfields(env, >jfields, 
> > > > > > jni_amediacodec_mapping, 1, codec) < 0) { \
> > > > > > +goto fail; 
> > > > > >  \
> > > > > > +}  
> > > > > >  \
> > > > > > +   
> > > > > >  \
> > > > > > +jarg = ff_jni_utf_chars_to_jstring(env, arg, codec);   
> > > > > >  \
> > > > > > +if (!jarg) {   
> > > > > >  \
> > > > > > +goto fail; 
> > > > > >  \
> > > > > > +}  
> > > > > >  \
> > > > > > +   
> > > > > >  \
> > > > > > +object = (*env)->CallStaticObjectMethod(env,   
> > > > > >  \
> > > > > > +
> > > > > > codec->jfields.mediacodec_class,\
> > > > > > +codec->jfields.jfunc,  
> > > > > >  \
> > > > > > +

Re: [FFmpeg-devel] [PATCH v6 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Steven Liu]

2017-12-15 16:21 GMT+08:00 Jeyapal, Karthick :
>
>
>>On 12/15/17, 4:45 AM, "Liu Steven"  wrote:
>>
>>
>>> 在 2017年12月15日，上午6:28，Liu Steven  写道：
>>>

 在 2017年12月15日，上午12:29，Jeyapal, Karthick  写道：

> On 12/14/17, 8:24 PM, "Steven Liu"  wrote:
>
>
>> 在 2017年12月14日，下午6:55，vdi...@akamai.com 写道：
>> […]
>> +libavformat/reverse.c
>
> this need double check for a better way
 The better way of doing this is to share ff_reverse function.
>>> No I don’t think that is a better way here.
 But such a patch submitted recently was not pushed due to several 
 objections. 
 http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221472.html
 Hence, we are left with only this option. Moreover like same approach was 
 used for avcodec and avdevice(to add reverse.c), as well. So, extending 
 the same approach for avformat shouldn’t deviate from ffmpeg’s principles.
>>> I think there have better way, Please don’t define the ffmpeg’s principles 
>>> to every place. you are duplicate the code from libavcodec//reverse.c to 
>>> libavformat, IMHO, that is not a good option.
>>I need some time to think about that.
> Oh sure. Thanks.
> In that case, could you please merge PATCH v6 1/3 alone, since that is a 
> relatively independent feature.


patch -p1 < 
~/Downloads/FFmpeg-devel-v6-1-3-avformat-hlsenc-addition-of-EXT-X-MEDIA-tag-and-AUDIO-attribute.patch
cd xxx/
rm -rf *
../configure --disable-network --disable-everything --enable-muxer=hls
make


CC libavformat/hlsenc.o
src/libavformat/hlsenc.c:1142:21: error: use of undeclared identifier
'master_pb'
avio_printf(master_pb, "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=\"group_%s\"",
^
src/libavformat/hlsenc.c:1144:21: error: use of undeclared identifier
'master_pb'
avio_printf(master_pb, ",NAME=\"audio_0\",DEFAULT=YES,URI=\"%s\"\n",
^
2 errors generated.
make: *** [libavformat/hlsenc.o] Error 1
make: *** Waiting for unfinished jobs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: Extend persistent http connections to playlists

[Karthick Jeyapal]

On 12/15/17 7:58 PM, Steven Liu wrote:

Patchset LGTM, i will push it after 24 hours if there are no objections.

Thanks for the reply.
But that patchset doesn’t apply with the latest master anymore.
I have rebased this patchset and sent a new version v2.



Patchset pushed,

BTW,  Your patchset need more time to make full review, so i need more
time to read and to check it, and the patchset need more time to wait
not only me review it,
so need more time to push it into master, you need read the developer
documentation. http://ffmpeg.org/developer.html#Patches_002fCommitting

Thanks.
I understand your point. The developer documentation mentioned 1 week of 
wait time for big patches.
I pinged only after waiting for 14 days. But if you are busy with 
something else and need more time to review a particular patch, I am 
perfectly fine with it. I just pinged to know the status, so that I 
could plan further tasks appropriately.


Thanks,

Steven
___
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 3/3] avformat/hlsenc: Extend persistent http connections to playlists

[Steven Liu]

>> Patchset LGTM, i will push it after 24 hours if there are no objections.
>
> Thanks for the reply.
> But that patchset doesn’t apply with the latest master anymore.
> I have rebased this patchset and sent a new version v2.
>


Patchset pushed,

BTW,  Your patchset need more time to make full review, so i need more
time to read and to check it, and the patchset need more time to wait
not only me review it,
so need more time to push it into master, you need read the developer
documentation. http://ffmpeg.org/developer.html#Patches_002fCommitting

Thanks,

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

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 15.12.2017 um 15:27 schrieb Compn:

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
 wrote:


Do you think that two and half weeks is long enough to wait?
So far except creating a repo for NVidia there is no activity.


did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.


The patchset without the included header is already merged in master.



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

Re: [FFmpeg-devel] AMD external header

[Compn]

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
 wrote:

> Do you think that two and half weeks is long enough to wait? 
> So far except creating a repo for NVidia there is no activity.

did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.

maybe the patchset without the included header could get reviewed some
more and possibly applied while we wait for the external repo changes.

remember we are mostly volunteers working on ffmpeg. which means we all
have regular non-ffmpeg jobs.

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Minor fix for persistent http connection of init fmp4

[Steven Liu]

2017-12-15 17:27 GMT+08:00 Karthick J :
> From: Karthick Jeyapal 
>
> ---
>  libavformat/hlsenc.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index fdf614b..0e2f412 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1787,7 +1787,6 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  vs->init_range_length = range_length;
>  avio_open_dyn_buf(>pb);
>  vs->packets_written = 0;
> -ff_format_io_close(s, >out);
Don't worry, i'm fixing tickets and coding something, maybe this patch
will not fix this time.


Thanks
>  hlsenc_io_close(s, >out, vs->base_output_dirname);
>  } else {
>  hlsenc_io_close(s, >pb, oc->filename);
> --
> 1.9.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] avfilter/vf_aspect: change outlink sample aspect ratio instead of inlink

[Paul B Mahol]

On 12/10/17, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_aspect.c | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
>

More than 4 days passed.

I assume this one is OK?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] v4l_m2m: add missing AV_CODEC_CAP_DELAY flags

[Jorge Ramirez]

On 12/14/2017 07:54 PM, Jorge Ramirez wrote:

On 12/14/2017 07:48 PM, wm4 wrote:

This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially could lead to issues
like missing frames at the end of a stream.
---
Untested.


ok you can add tested-by me if needed.
is all ok.

thanks!



hi,

please do not merge this (the capability was not missing, it just 
broke the codeca last time I tested it hence why it is not in the code).


I will look into this now (test/validate again); I also  have a couple 
of other things pending - in particular a patch that Mark Thompson 
sent me a couple of months back which is quite important (today we 
access free'd memory when we close the codec...we are lucky that the 
memory is not reused)


I have been off the radar doing some uboot work that couldnt be 
postponed. sorry about it. I am back on this now.



---
  libavcodec/v4l2_m2m_dec.c | 2 +-
  libavcodec/v4l2_m2m_enc.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index c4ea20ea83..8308613978 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -215,7 +215,7 @@ AVCodec ff_ ## NAME ## _v4l2m2m_decoder = { \
  .receive_frame  = v4l2_receive_frame,\
  .close  = ff_v4l2_m2m_codec_end,\
  .bsfs   = bsf_name, \
-.capabilities   = AV_CODEC_CAP_HARDWARE, \
+.capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
  .wrapper_name   = "v4l2m2m", \
  };
  diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index f62ce7cdb5..7e88f4d2e6 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -335,7 +335,7 @@ AVCodec ff_ ## NAME ## _v4l2m2m_encoder = { \
  .send_frame = v4l2_send_frame,\
  .receive_packet = v4l2_receive_packet,\
  .close  = ff_v4l2_m2m_codec_end,\
-.capabilities   = AV_CODEC_CAP_HARDWARE, \
+.capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
  .wrapper_name   = "v4l2m2m", \
  };




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

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)

[Martin Vignali]

>
> Would it be faster to instead process the unaligned pixels
> separately and use aligned access for most of the line?
>
> 
>
Probably. but the asm code will become more complex.

Without a checkasm test for these funcs, i prefer to not try to touch it !
:-)

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

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)

[Carl Eugen Hoyos]

2017-12-14 17:01 GMT+01:00 Martin Vignali :

> in attach patch to fix crash using this command line
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
> crop=1440:1080,interlace -f null -
> (ticket 6491)

Thank you!

> Use unaligned load, to avoid crash

Would it be faster to instead process the unaligned pixels
separately and use aligned access for most of the line?

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add support for more colorspaces

[Carl Eugen Hoyos]

2017-12-15 8:22 GMT+01:00 Steven Robertson :
> Actually QT has supported these codepoints for some time now internally,
> but not officially. That said, I modified this to write nonsense values and
> it interpreted everything as Rec 601 625 aka 470BG, which isn't great (I
> think the default for anything should be 709 these days) but is not crazy
> either.

Thank you for testing and reporting this!

Please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)

[Martin Vignali]

> Patch LGTM, thanks!
>
> Regards,
> Thomas
>
> Pushed thanks

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

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash in low_pass_complex

[Martin Vignali]

>
> Patch LGTM, thanks!
>
> Regards,
> Thomas
>
>
> Pushed, thanks

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

Re: [FFmpeg-devel] [PATCH 07/14] mediacodec: check whether cropping is set before use

[Matthieu Bouron]

On Fri, Dec 15, 2017 at 03:06:49PM +0800, wbse...@gmail.com wrote:
> From: wang-bin 

Hi,

> 
> ---
>  libavcodec/mediacodecdec_common.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index cb2f6ae5e5..05d3bcd4b5 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -412,20 +412,15 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> *avctx, MediaCodecDecConte
>  }
>  
>  /* Optional fields */
> -if (ff_AMediaFormat_getInt32(s->format, "crop-top", ))
> -s->crop_top = value;
> -
> -if (ff_AMediaFormat_getInt32(s->format, "crop-bottom", ))
> -s->crop_bottom = value;
> -
> -if (ff_AMediaFormat_getInt32(s->format, "crop-left", ))
> -s->crop_left = value;
> -
> -if (ff_AMediaFormat_getInt32(s->format, "crop-right", ))
> -s->crop_right = value;
> -
> -width = s->crop_right + 1 - s->crop_left;
> -height = s->crop_bottom + 1 - s->crop_top;
> +if (ff_AMediaFormat_getInt32(s->format, "crop-top", >crop_top) && 
> ff_AMediaFormat_getInt32(s->format, "crop-bottom", >crop_bottom))

Please break this line after &&.

> +height = s->crop_bottom + 1 - s->crop_top;
> +else
> +height = s->height;
> +
> +if (ff_AMediaFormat_getInt32(s->format, "crop-left", >crop_left) && 
> ff_AMediaFormat_getInt32(s->format, "crop-right", >crop_right))

Same here.

> +width = s->crop_right + 1 - s->crop_left;
> +else
> +width = s->width;
>  
>  av_log(avctx, AV_LOG_INFO,
>  "Output crop parameters top=%d bottom=%d left=%d right=%d, "

On which device does this happen ?

Thanks,

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

[FFmpeg-devel] [PATCH] avformat/hlsenc: Minor fix for persistent http connection of init fmp4

[Karthick J]

From: Karthick Jeyapal 

---
 libavformat/hlsenc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index fdf614b..0e2f412 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1787,7 +1787,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 vs->init_range_length = range_length;
 avio_open_dyn_buf(>pb);
 vs->packets_written = 0;
-ff_format_io_close(s, >out);
 hlsenc_io_close(s, >out, vs->base_output_dirname);
 } else {
 hlsenc_io_close(s, >pb, oc->filename);
-- 
1.9.1

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

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Do you think that two and half weeks is long enough to wait?
So far except creating a repo for NVidia there is no activity.


I'm not yet happy with how the external repository works, and I'm quite 
busy with other stuff at the moment.

But it will get used eventually.



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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: Extend persistent http connections to playlists

[Karthick Jeyapal]

On 12/14/17 1:46 PM, 刘歧 wrote:

On 14 Dec 2017, at 16:07, Karthick Jeyapal  wrote:




On Nov 30, 2017, at 2:36 PM, Karthick J  wrote:


From: Karthick Jeyapal 


Before this patch persistent http connections would work only for media 
segments.
The playlists were still opening a new connection everytime.
This patch extends persistent http connections to playlists as well.
---
libavformat/hlsenc.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)


diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ff982c5..350836d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -201,6 +201,8 @@ typedef struct HLSContext {
char *master_pl_name;
unsigned int master_publish_rate;
int http_persistent;
+ AVIOContext *m3u8_out;
+ AVIOContext *sub_m3u8_out;
} HLSContext;


static int mkdir_p(const char *path) {
@@ -1081,7 +1083,6 @@ static int create_master_playlist(AVFormatContext *s,
HLSContext *hls = s->priv_data;
VariantStream *vs;
AVStream *vid_st, *aud_st;
- AVIOContext *master_pb = 0;
AVDictionary *options = NULL;
unsigned int i, j;
int m3u8_name_size, ret, bandwidth;
@@ -1102,8 +1103,7 @@ static int create_master_playlist(AVFormatContext *s,


set_http_options(s, , hls);


- ret = s->io_open(s, _pb, hls->master_m3u8_url, AVIO_FLAG_WRITE,\
- );
+ ret = hlsenc_io_open(s, >m3u8_out, hls->master_m3u8_url, );
av_dict_free();
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Failed to open master play list file '%s'\n",
@@ -,7 +,7 @@ static int create_master_playlist(AVFormatContext *s,
goto fail;
}


- ff_hls_write_playlist_version(master_pb, hls->version);
+ ff_hls_write_playlist_version(hls->m3u8_out, hls->version);


/* For variant streams with video add #EXT-X-STREAM-INF tag with attributes*/
for (i = 0; i < hls->nb_varstreams; i++) {
@@ -1152,7 +1152,7 @@ static int create_master_playlist(AVFormatContext *s,
bandwidth += aud_st->codecpar->bit_rate;
bandwidth += bandwidth / 10;


- ff_hls_write_stream_info(vid_st, master_pb, bandwidth, m3u8_rel_name);
+ ff_hls_write_stream_info(vid_st, hls->m3u8_out, bandwidth, m3u8_rel_name);


av_freep(_rel_name);
}
@@ -1160,7 +1160,7 @@ fail:
if(ret >=0)
hls->master_m3u8_created = 1;
av_freep(_rel_name);
- ff_format_io_close(s, _pb);
+ hlsenc_io_close(s, >m3u8_out, hls->master_m3u8_url);
return ret;
}


@@ -1170,8 +1170,6 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
HLSSegment *en;
int target_duration = 0;
int ret = 0;
- AVIOContext *out = NULL;
- AVIOContext *sub_out = NULL;
char temp_filename[1024];
int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - vs->nb_entries);
const char *proto = avio_find_protocol_name(s->filename);
@@ -1203,7 +1201,7 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)


set_http_options(s, , hls);
snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : "%s", 
vs->m3u8_name);
- if ((ret = s->io_open(s, , temp_filename, AVIO_FLAG_WRITE, )) < 0)
+ if ((ret = hlsenc_io_open(s, >m3u8_out, temp_filename, )) < 0)
goto fail;


for (en = vs->segments; en; en = en->next) {
@@ -1212,33 +1210,33 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
}


vs->discontinuity_set = 0;
- ff_hls_write_playlist_header(out, hls->version, hls->allowcache,
+ ff_hls_write_playlist_header(hls->m3u8_out, hls->version, hls->allowcache,
target_duration, sequence, hls->pl_type);


if((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence && 
vs->discontinuity_set==0 ){
- avio_printf(out, "#EXT-X-DISCONTINUITY\n");
+ avio_printf(hls->m3u8_out, "#EXT-X-DISCONTINUITY\n");
vs->discontinuity_set = 1;
}
if (vs->has_video && (hls->flags & HLS_INDEPENDENT_SEGMENTS)) {
- avio_printf(out, "#EXT-X-INDEPENDENT-SEGMENTS\n");
+ avio_printf(hls->m3u8_out, "#EXT-X-INDEPENDENT-SEGMENTS\n");
}
for (en = vs->segments; en; en = en->next) {
if ((hls->encrypt || hls->key_info_file) && (!key_uri || strcmp(en->key_uri, 
key_uri) ||
av_strcasecmp(en->iv_string, iv_string))) {
- avio_printf(out, "#EXT-X-KEY:METHOD=AES-128,URI=\"%s\"", en->key_uri);
+ avio_printf(hls->m3u8_out, "#EXT-X-KEY:METHOD=AES-128,URI=\"%s\"", 
en->key_uri);
if (*en->iv_string)
- avio_printf(out, ",IV=0x%s", en->iv_string);
- avio_printf(out, "\n");
+ avio_printf(hls->m3u8_out, ",IV=0x%s", en->iv_string);
+ avio_printf(hls->m3u8_out, "\n");
key_uri = en->key_uri;
iv_string = en->iv_string;
}


if ((hls->segment_type == SEGMENT_TYPE_FMP4) && (en == vs->segments)) {
- ff_hls_write_init_file(out, vs->fmp4_init_filename,
+ ff_hls_write_init_file(hls->m3u8_out, vs->fmp4_init_filename,
hls->flags & HLS_SINGLE_FILE, en->size, en->pos);
}


- ff_hls_write_file_entry(out, en->discont, byterange_mode,
+ ff_hls_write_file_entry(hls->m3u8_out, en->discont, byterange_mode,
en->duration, hls->flags & HLS_ROUND_DURATIONS,
en->size, en->pos, vs->baseurl,
en->filename, prog_date_time_p);
@@ -1246,29 

Re: [FFmpeg-devel] [PATCH v6 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

>On 12/15/17, 4:45 AM, "Liu Steven"  wrote:
>
>
>> 在 2017年12月15日，上午6:28，Liu Steven  写道：
>> 
>>> 
>>> 在 2017年12月15日，上午12:29，Jeyapal, Karthick  写道：
>>> 
 On 12/14/17, 8:24 PM, "Steven Liu"  wrote:
 
 
> 在 2017年12月14日，下午6:55，vdi...@akamai.com 写道：
> […] 
> +libavformat/reverse.c
 
 this need double check for a better way
>>> The better way of doing this is to share ff_reverse function.
>> No I don’t think that is a better way here.
>>> But such a patch submitted recently was not pushed due to several 
>>> objections. 
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221472.html
>>> Hence, we are left with only this option. Moreover like same approach was 
>>> used for avcodec and avdevice(to add reverse.c), as well. So, extending the 
>>> same approach for avformat shouldn’t deviate from ffmpeg’s principles.
>> I think there have better way, Please don’t define the ffmpeg’s principles 
>> to every place. you are duplicate the code from libavcodec//reverse.c to 
>> libavformat, IMHO, that is not a good option.
>I need some time to think about that.
Oh sure. Thanks. 
In that case, could you please merge PATCH v6 1/3 alone, since that is a 
relatively independent feature.
>
>Thanks
>
>Steven
>> 
>> Thanks
>> 
>> Steven
>>> 
>>> Regards,
>>> Karthick
>>> 
>>> […]
>>> Thanks
>>> 
>>> 
>>> Steven





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