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

2017-12-14 Thread 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. I presume the same behavior applies to very old versions of
QuickTime looking at these new codepoints.

On Dec 14, 2017 6:51 PM, "Carl Eugen Hoyos"  wrote:

> 2017-12-14 20:52 GMT+01:00 Steven Robertson :
> > With FCPX 10.4, Apple has expanded the set of colorspace,
> > primaries, and trc flags officially supported in QuickTime files.
>
> What happens if new files (with new colorspace etc.) areplayed
> back with older QT?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2017-12-14 Thread Jun Zhao


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/

> ---
>  libavcodec/avcodec.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index ce089b7c4a..6d1f5ee532 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3725,6 +3725,10 @@ typedef struct AVHWAccel {
>   */
>  #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>  
> +/**
> + * Hardware acceleration can use it's software implementation.
> + */
> +#define AV_HWACCEL_FLAG_ALLOW_SOFTWARE (1 << 3)
>  /**
>   * @}
>   */

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


[FFmpeg-devel] [PATCH 09/14] videotoolbox: allow software implementation

2017-12-14 Thread wbsecg1
From: wang-bin 

hevc is supported on macOS 10.12+ and iOS11+. sw implementaion is
provided for old devices. vt sw decoder is more energy effecient than
ffmpeg sw decoder. the sum of program and vt service cpu usage is about
50% lower than ffmpeg. decoding speed is faster sometimes(if opengl
compatiblility attribute is disabled)
---
 libavcodec/videotoolbox.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index e66cd23451..9d2f0afa20 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -40,6 +40,9 @@
 #ifndef kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
 #  define kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
CFSTR("RequireHardwareAcceleratedVideoDecoder")
 #endif
+#ifndef kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder
+#  define kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder 
CFSTR("EnableHardwareAcceleratedVideoDecoder")
+#endif
 
 #if !HAVE_KCMVIDEOCODECTYPE_HEVC
 enum { kCMVideoCodecType_HEVC = 'hvc1' };
@@ -684,7 +687,9 @@ static CFDictionaryRef 
videotoolbox_decoder_config_create(CMVideoCodecType codec

&kCFTypeDictionaryValueCallBacks);
 
 CFDictionarySetValue(config_info,
- 
kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
+ (avctx->hwaccel_flags & 
AV_HWACCEL_FLAG_ALLOW_SOFTWARE)
+ ? 
kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder
+ : 
kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
  kCFBooleanTrue);
 
 CFMutableDictionaryRef avc_info;
-- 
2.15.1

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


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

2017-12-14 Thread wbsecg1
From: wang-bin 

---
 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", &value))
-s->crop_top = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-bottom", &value))
-s->crop_bottom = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-left", &value))
-s->crop_left = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-right", &value))
-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", &s->crop_top) && 
ff_AMediaFormat_getInt32(s->format, "crop-bottom", &s->crop_bottom))
+height = s->crop_bottom + 1 - s->crop_top;
+else
+height = s->height;
+
+if (ff_AMediaFormat_getInt32(s->format, "crop-left", &s->crop_left) && 
ff_AMediaFormat_getInt32(s->format, "crop-right", &s->crop_right))
+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, "
-- 
2.15.1

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


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

2017-12-14 Thread wbsecg1
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(&ref->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}
 };
 
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 03/14] configure: fix probing armv6zk

2017-12-14 Thread wbsecg1
From: wang-bin 

clang reports 6kz: https://reviews.llvm.org/D14568
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index d5bbb5b7a9..6065f01c5c 100755
--- a/configure
+++ b/configure
@@ -4521,6 +4521,7 @@ elif enabled arm; then
 elif check_arm_arch 6J;   then echo armv6j
 elif check_arm_arch 6K;   then echo armv6k
 elif check_arm_arch 6Z;   then echo armv6z
+elif check_arm_arch 6KZ;  then echo armv6zk
 elif check_arm_arch 6ZK;  then echo armv6zk
 elif check_arm_arch 6T2;  then echo armv6t2
 elif check_arm_arch 7;then echo armv7
-- 
2.15.1

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


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

2017-12-14 Thread wbsecg1
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.
---
 libavcodec/avcodec.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ce089b7c4a..6d1f5ee532 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3725,6 +3725,10 @@ typedef struct AVHWAccel {
  */
 #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
 
+/**
+ * Hardware acceleration can use it's software implementation.
+ */
+#define AV_HWACCEL_FLAG_ALLOW_SOFTWARE (1 << 3)
 /**
  * @}
  */
-- 
2.15.1

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


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

2017-12-14 Thread wbsecg1
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);
-- 
2.15.1

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


Re: [FFmpeg-devel] [PATCH] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread 吴志强
I see pts_wrap_bits must be modified in this function.   I re-submit  the
new patch, only replace avpriv_set_pts_info st->pts_wrap_bits   =
source_st->pts_wrap_bits by avpriv_set_pts_info.

Liu Steven  于 2017年12月15日周五 上午6:30写道:

>
> > 在 2017年12月15日,上午12:04,Michael Niedermayer  写道:
> >
> > On Thu, Dec 14, 2017 at 03:00:50AM -0500, mymoey...@gmail.com wrote:
> >> From: wu zhiqiang 
> >>
> >> When using concat protocal, start from middle of file will generate
> non-zero wrap reference. If seek to time less than the wrap reference, wrap
> control will be triggered and generate wrong wrapped timestamp.
> >> Copy wrap related stream properties when reading header can fix this
> problem.
> >>
> >> Signed-off-by: wu zhiqiang 
> >> ---
> >> libavformat/concatdec.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> >> index 0e189012ad..e933888661 100644
> >> --- a/libavformat/concatdec.c
> >> +++ b/libavformat/concatdec.c
> >> @@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st,
> AVStream *source_st)
> >> st->time_base   = source_st->time_base;
> >> st->sample_aspect_ratio = source_st->sample_aspect_ratio;
> >>
> >> +/* Fix wrap control problem */
> >> +st->pts_wrap_bits   = source_st->pts_wrap_bits;
> >> +st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
> >> +st->pts_wrap_reference  = source_st->pts_wrap_reference;
> >
> > why does this not use avpriv_set_pts_info() ?
>
> Add st->pts_wrap_behavior   = source_st->pts_wrap_behavior; and
> st->pts_wrap_reference  = source_st->pts_wrap_reference; into
> avpriv_set_pts_info?
> or only replace avpriv_set_pts_info st->pts_wrap_bits   =
> source_st->pts_wrap_bits; here?
>
> Thanks
>
> Steven
> >
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > There will always be a question for which you do not know the correct
> answer.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH, V2] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread mymoeyard
From: Wu Zhiqiang 

When using concat protocol, start from middle of file will generate non-zero 
wrap reference.
If seek to time before the wrap reference, wrap control will generate wrong 
wrapped timestamp.
Copy wrap related stream properties when reading header can fix this problem.

Signed-off-by: Wu Zhiqiang 
---
 libavformat/concatdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 0e189012ad..8dae2737df 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st, AVStream 
*source_st)
 st->time_base   = source_st->time_base;
 st->sample_aspect_ratio = source_st->sample_aspect_ratio;
 
+/* Fix wrap control problem */
+avpriv_set_pts_info(st, source_st->pts_wrap_bits, 
source_st->time_base.num, source_st->time_base.den);
+st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
+st->pts_wrap_reference  = source_st->pts_wrap_reference;
+
 av_dict_copy(&st->metadata, source_st->metadata, 0);
 return 0;
 }
-- 
2.15.0

___
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

2017-12-14 Thread Carl Eugen Hoyos
2017-12-14 20:52 GMT+01:00 Steven Robertson :
> With FCPX 10.4, Apple has expanded the set of colorspace,
> primaries, and trc flags officially supported in QuickTime files.

What happens if new files (with new colorspace etc.) areplayed
back with older QT?

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


Re: [FFmpeg-devel] Correction to Webpage

2017-12-14 Thread Lou Logan
On Thu, Dec 14, 2017, at 01:12 AM, Yogender Gupta wrote:
> I would like to correct a couple of lines on the following ffmpeg web
> page. Can anyone please guide me on how to do it (push patch or raise
> ticket or edit page)
[...]
> https://trac.ffmpeg.org/wiki/HWAccelIntro

As Carl tactlessly pointed out this page is part of our wiki which
anyone can edit.

First you must register to create an account:
https://trac.ffmpeg.org/register

Then after you log in you can click the "Edit this page" button at the
bottom of the page that you would like to edit.

You can view the WikiFormatting page if you need help with the syntax:
https://trac.ffmpeg.org/wiki/WikiFormatting
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Correction to Webpage

2017-12-14 Thread wm4
On Fri, 15 Dec 2017 03:11:47 +0100
Carl Eugen Hoyos  wrote:

> 2017-12-14 14:28 GMT+01:00 wm4 :
> 
> >> > This email message is for the sole use of the intended
> >> > recipient(s) and may contain confidential information.  
> >>
> >> Please remove this from emails sent to a public mailing list.  
> >
> > I can't speak for him, but I suspect it's not up to them, and added by
> > the company mail server, and fighting against it is probably futile.  
> 
> So far, it was never an issue for anybody switching the email
> provider if necessary.
> 
> Note that the footer basically means we must delete the
> message.

So you're not an intended recipient? Unregister from this list then, I
guess.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Correction to Webpage

2017-12-14 Thread Carl Eugen Hoyos
2017-12-14 14:28 GMT+01:00 wm4 :

>> > This email message is for the sole use of the intended
>> > recipient(s) and may contain confidential information.
>>
>> Please remove this from emails sent to a public mailing list.
>
> I can't speak for him, but I suspect it's not up to them, and added by
> the company mail server, and fighting against it is probably futile.

So far, it was never an issue for anybody switching the email
provider if necessary.

Note that the footer basically means we must delete the
message.

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


Re: [FFmpeg-devel] [PATCH 0/2] pkg-config detection for twolame, openal (alternate)

2017-12-14 Thread Carl Eugen Hoyos
2017-12-14 17:18 GMT+01:00 Stephen Hutchinson :
> Based on the suggestions last time*, this
> version of the patchset switches twolame and openal
> completely over to pkg-config.
>
> I personally don't care whether this version or
> the previous version with the fallbacks are the
> ones accepted, I really only care that pkg-config
> support gets added for these two.

Please use the fallback versions, so testing the libs
is still possible on less common os's.

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


Re: [FFmpeg-devel] DVD subtitles hacking

2017-12-14 Thread Carl Eugen Hoyos
2017-12-14 22:48 GMT+01:00 Matt Zagrabelny :

> I've tried a variety of convoluted processes to convert DVD
> subtitles to SRT

This does currently not work (in one easy step) with FFmpeg
and is to the best of my knowledge not related to ticket #2391.

The necessary tesseract wrapper already exists but - iiuc -
libavfilter does not yet contain the necessary subtitle code.

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.

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


Re: [FFmpeg-devel] AMD external header

2017-12-14 Thread Mironov, Mikhail
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Compn
> Sent: November 29, 2017 10:50 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 15:45:28 +, "Mironov, Mikhail"
>  wrote:
> > May I suggest to go down to business of enabling HW encoders by default?
> > Yesterday Mark submitted the initial implementation and I really want
> > to thank him for his mentoring and participation - it was very useful.
> > Question is: how to move forward on practical terms? I really don’t know
> how this team makes such decisions.
> > Or maybe it is impasse case and  all want to keep things the way they are
> today?
> 
> probably wait a few days until the maintainer of hwaccels can chime in,
> possibly with some more reviews.
> 
> please be patient.
> 
> -compn
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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.
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] HW accelerator: Indicate when hardware acceleration is used for processing encode or decode.

2017-12-14 Thread Michele Lim
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)
-- 
2.7.4

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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Reino Wijnsma
On 14-12-2017 20:51, Lou Logan  wrote:
> Also, I believe Zeranoe stopped providing XP builds in 2016 so it will
> be no issue downstream.
I still am . But 
hey, it's your call in the end.

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


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

2017-12-14 Thread Liu Steven

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

Thanks

Steven
> 
> Thanks
> 
> Steven
>> 
>> Regards,
>> Karthick
>>> 
>>> […]
>>> 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



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


Re: [FFmpeg-devel] [PATCH] avcodec/vp9: mark frame as finished on decode_tiles() failure

2017-12-14 Thread Michael Niedermayer
On Wed, Dec 13, 2017 at 11:00:37PM -0800, James Zern wrote:
> On Wed, Dec 13, 2017 at 5:02 PM, Michael Niedermayer
>  wrote:
> > Fixes deadlock with framethreads
> > Fixes: 
> > Netflix_Aerial_1080p_60fps_8bit_420.y4m.vp9.noaltref.webm.ivf.s69372_r01-05_b6-.ivf
> > Fixes: 
> > Netflix_Aerial_1080p_60fps_10bit_420.y4m.vp9.noaltref.webm.ivf.s149104_r01-05_b6-.ivf
> > Fixes: ducks_take_off_444_720p50.y4m.vp9.webm.ivf.s107375_r01-05_b6-.ivf
> >
> > Reported-by: James Zern 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp9.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> 
> lgtm. tested locally, thanks for having a look.

will apply

thanks
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


signature.asc
Description: PGP signature
___
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

2017-12-14 Thread Michael Niedermayer
On Thu, Dec 14, 2017 at 11:52:45AM -0800, Steven Robertson wrote:
> With FCPX 10.4, Apple has expanded the set of colorspace, primaries,
> and trc flags officially supported in QuickTime files. The expanded set
> matches the codepoints used in ffmpeg and many other specs.
> ---
>  libavformat/movenc.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)

will apply

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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


Re: [FFmpeg-devel] [PATCH] avfilter/drawbox+drawgrid - add option to prevent overwriting, of source pixels

2017-12-14 Thread Lou Logan
On Tue, 12 Dec 2017 18:36:29 +0530
Gyan Doshi  wrote:

> From cc2979978a8c101588c237c0bc9b6c03731b10e9 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Mon, 11 Dec 2017 22:35:18 +0530
> Subject: [PATCH] avfilter/drawbox+drawgrid - add option to prevent overwriting
>  of source pixels
> 
> If the user-supplied color in drawbox and drawgrid filters is non-opaque,
> the box & grid painting overwrites the input's pixels (including alpha).
> Users typically expect the alpha of the specified color to only act as a key
> for compositing on top of the main input.
> 
> Added option allows users to select between replacement and composition.
> Tested and documented.
> ---
>  doc/filters.texi | 10 ++
>  libavfilter/vf_drawbox.c |  7 +--
>  2 files changed, 15 insertions(+), 2 deletions(-)

LGTM and pushed. Thanks.
___
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

2017-12-14 Thread Michael Niedermayer
On Fri, Dec 08, 2017 at 10:06:13AM -0800, Jacob Trimble wrote:
> On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
>  wrote:
> > On 12/6/2017 12:36 AM, Jacob Trimble wrote:
> >> Would a 0-length array work?  Otherwise I would need to have it be a
> >> 1-length array and have to account for that when calculating the size
> >> to allocate; it would also require a comment to ignore the size of the
> >> array.
> >
> > Aren't 0-length arrays a GNU extensions? If so, I would gather that it
> > probably is not OK in a public header, either.
> 
> Yeah.
> 
> > I'm not entirely sure what way we prefer nowadays, but you can see
> > we've had side data with variable length members before with e.g.
> > AV_PKT_DATA_QUALITY_STATS, but that doesn't have a struct associated
> > with it. I'm hoping someone more up to date with the side data stuff
> > can chime in with a suggestion on what our current best practices
> > are for it.
> 
> I would prefer to avoid requiring the app to "parse" the side data, using a
> plain struct would be better.  I've updated the patch to include my other plan
> of allocating a larger bock and having the struct followed by the subsample
> array.
> 
> I have also renamed the file, I think the mailing list rejected my attachment
> before since gmail sent the MIME type as text/x-patch.  Hopefully with the
> .txt extension gmail will send the correct MIME type.

> From 740c0ccf3ed90b3d417ea25ec26cfefb93974461 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 | 60 
> 
>  1 file changed, 60 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..6f5c387556 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1112,6 +1112,53 @@ typedef struct AVCPBProperties {
>  uint64_t vbv_delay;
>  } AVCPBProperties;
>  
> +/**
> + * 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. */
> +int scheme;

uint32_t or unsigned


> +
> +/** 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 ?


> +
> +/**
> + * 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 ?


> +
> +/**
> + * 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


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


> +
>  /**
>   * The decoder will keep a reference to the frame and may reuse it later.
>   */
> @@ -1327,6 +1374,19 @@ enum AVPacketSideDataType {
>   */
>  AV_PKT_DATA_A53_CC,
>  
> +/**
> + * This side data is encryption "initialization data".
> + * For MP4 this is the entire 'pssh' box.
> + * For WebM this is the key ID.
> + */
> +AV_PKT_DATA_ENCRYPTION_INIT_DATA,
> +
> +/**
> + * This side data is an AVPacketEncryptionInfo structure and contains 
> info
> + * about how the packet is encrypted.
> + */
> +AV_PKT_DATA_PACKET_ENCRYPTION_INFO,
> +
>  /**
>   * The number of side data types.
>   * This is not part of the public API/ABI

Re: [FFmpeg-devel] [PATCH] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread Liu Steven

> 在 2017年12月15日,上午12:04,Michael Niedermayer  写道:
> 
> On Thu, Dec 14, 2017 at 03:00:50AM -0500, mymoey...@gmail.com wrote:
>> From: wu zhiqiang 
>> 
>> When using concat protocal, start from middle of file will generate non-zero 
>> wrap reference. If seek to time less than the wrap reference, wrap control 
>> will be triggered and generate wrong wrapped timestamp.
>> Copy wrap related stream properties when reading header can fix this problem.
>> 
>> Signed-off-by: wu zhiqiang 
>> ---
>> libavformat/concatdec.c | 5 +
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
>> index 0e189012ad..e933888661 100644
>> --- a/libavformat/concatdec.c
>> +++ b/libavformat/concatdec.c
>> @@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st, AVStream 
>> *source_st)
>> st->time_base   = source_st->time_base;
>> st->sample_aspect_ratio = source_st->sample_aspect_ratio;
>> 
>> +/* Fix wrap control problem */
>> +st->pts_wrap_bits   = source_st->pts_wrap_bits;
>> +st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
>> +st->pts_wrap_reference  = source_st->pts_wrap_reference;
> 
> why does this not use avpriv_set_pts_info() ?

Add st->pts_wrap_behavior   = source_st->pts_wrap_behavior; and 
st->pts_wrap_reference  = source_st->pts_wrap_reference; into 
avpriv_set_pts_info?
or only replace avpriv_set_pts_info st->pts_wrap_bits   = 
source_st->pts_wrap_bits; here?

Thanks

Steven
> 
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> There will always be a question for which you do not know the correct answer.
> ___
> 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 v6 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

2017-12-14 Thread 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.

Thanks

Steven
> 
> Regards,
> Karthick
>> 
>> […]
>> 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


[FFmpeg-devel] DVD subtitles hacking

2017-12-14 Thread Matt Zagrabelny
[Please Cc me, I am not subscribed to -devel.]

Hello!

I've tried a variety of convoluted processes to convert DVD subtitles to
SRT or WebVTT subtitle files with varying levels of success. The process
has always been painful and convoluted.

I have seen chatter about the following ticket:

https://trac.ffmpeg.org/ticket/2391

Tools like vobsub2srt need .idx and .sub files and usually a .ifo file, too.

However, it seems mplayer can easily display the subtitles of a VOB ripped
from a DVD without the IFO files. I believe that mplayer uses ffmpeg
libraries. Thus it would seem that ffmpeg could do the work of converting
the subtitle streams in a ripped DVD VOB to SRT or WebVTT (with an
appropriate OCR library, libtesseract perhaps.)

I have no experience hacking on ffmpeg, but this itch is rather bothersome.

Is anyone with ffmpeg hacking experience interested in this enhancement? We
could talk on or off list about working toward a solution.

If I were to contemplate undertaking this, I would need to:

- extract the subtitle image
- get the timestamps (image displayed, image no longer displayed)

Where would I look to get started on the above two tasks?

Thanks for any help, pointers, or feedback!

-m
___
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)

2017-12-14 Thread Thomas Mundt
2017-12-14 21:33 GMT+01:00 Thomas Mundt :

> Hi,
>
> 2017-12-14 17:01 GMT+01:00 Martin Vignali :
>
>> Hello,
>>
>>
>> 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)
>>
>> Use unaligned load, to avoid crash
>>
>
> this changes the color planes when zscale filter is in front.
>

Sorry, I mixed up some libraries. Please ignore my last mail.
Patch LGTM, thanks!

Regards,
Thomas
___
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)

2017-12-14 Thread Martin Vignali
2017-12-14 21:33 GMT+01:00 Thomas Mundt :

> Hi,
>
> 2017-12-14 17:01 GMT+01:00 Martin Vignali :
>
> > Hello,
> >
> >
> > 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)
> >
> > Use unaligned load, to avoid crash
> >
>
> this changes the color planes when zscale filter is in front.
> Compare this command line output with and without your patch:
> ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
> zscale,interlace -c:v mpeg2video -t 5 test.mpg
>
>
>
> Doesn't change the result for me.

if i run your command line with and without the patch,
and test the framecrc of the mpg file (./ffmpeg -i ./test.mpg -f framecrc -)
, i have the same result :

0,  0,  0,1,  3110400, 0x8505a4ea
0,  1,  1,1,  3110400, 0xe351f524
0,  2,  2,1,  3110400, 0x67acdc3d
0,  3,  3,1,  3110400, 0x1ab92fcd
0,  4,  4,1,  3110400, 0x708cc22c
0,  5,  5,1,  3110400, 0x065dec04
0,  6,  6,1,  3110400, 0xf96985f5
0,  7,  7,1,  3110400, 0x206ac8b9
0,  8,  8,1,  3110400, 0xfa4c0aa8
0,  9,  9,1,  3110400, 0x38b1254d
0, 10, 10,1,  3110400, 0x534efdbb
0, 11, 11,1,  3110400, 0xe33be39a
0, 12, 12,1,  3110400, 0xf5fa8725
0, 13, 13,1,  3110400, 0x708e195a
0, 14, 14,1,  3110400, 0xe3c22502
0, 15, 15,1,  3110400, 0xd0eede2c
0, 16, 16,1,  3110400, 0x6166c274
0, 17, 17,1,  3110400, 0x15378a1c
0, 18, 18,1,  3110400, 0xaaf84dd8
0, 19, 19,1,  3110400, 0xdc96d60e
0, 20, 20,1,  3110400, 0x64622f42
0, 21, 21,1,  3110400, 0x9840d5a0
0, 22, 22,1,  3110400, 0x43e41930
0, 23, 23,1,  3110400, 0x41ee87dc
0, 24, 24,1,  3110400, 0x1bc02d1f
0, 25, 25,1,  3110400, 0x7b15626f
0, 26, 26,1,  3110400, 0x75635104
0, 27, 27,1,  3110400, 0x4459c3f2
0, 28, 28,1,  3110400, 0x2f49c2ac
0, 29, 29,1,  3110400, 0x80987927
0, 30, 30,1,  3110400, 0x54dcd45e
0, 31, 31,1,  3110400, 0x69788294
0, 32, 32,1,  3110400, 0xab3032c0
0, 33, 33,1,  3110400, 0x8b21c117
0, 34, 34,1,  3110400, 0x5bd8a422
0, 35, 35,1,  3110400, 0x8d0c2815
0, 36, 36,1,  3110400, 0xb87110e0
0, 37, 37,1,  3110400, 0x6fb7344d
0, 38, 38,1,  3110400, 0x187a42e5
0, 39, 39,1,  3110400, 0xfd904944
0, 40, 40,1,  3110400, 0x49e48c3a
0, 41, 41,1,  3110400, 0x2b6382f4
0, 42, 42,1,  3110400, 0xc981115a
0, 43, 43,1,  3110400, 0xdc724670
0, 44, 44,1,  3110400, 0xb3e3eb4d
0, 45, 45,1,  3110400, 0x530dda42
0, 46, 46,1,  3110400, 0xe9891a5c
0, 47, 47,1,  3110400, 0xab7c66c1
0, 48, 48,1,  3110400, 0x55e1d487
0, 49, 49,1,  3110400, 0xb16c5105
0, 50, 50,1,  3110400, 0x30732e77
0, 51, 51,1,  3110400, 0x8688d07a
0, 52, 52,1,  3110400, 0x660a8e1e
0, 53, 53,1,  3110400, 0xa7da321c
0, 54, 54,1,  3110400, 0x600c5bb2
0, 55, 55,1,  3110400, 0xa17feaae
0, 56, 56,1,  3110400, 0xef73c1f7
0, 57, 57,1,  3110400, 0xa03d2a2f
0, 58, 58,1,  3110400, 0x3590442b
0, 59, 59,1,  3110400, 0xb2fb7fe5
___
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

2017-12-14 Thread Thomas Mundt
Hi,

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

> Hello,
>
> related to ticket 6491 (crash using crop and vf_interlace)
>
> in attach patch to fix crash when data are unaligned, with low_pass_complex
> filtering
> (the previous patch, fix crash, for low_pass_simple filtering)
>
>
> Can be test with
> For 8 bits
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
> crop=1440:1080,interlace=lowpass=2 -f null -
>
> For > 8 bits :
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p10le -vf
> crop=1442:1080,interlace=lowpass=2 -f null -
>
> i use m2 as temp xmm, in order to make an unaligned load (m2 is not use in
> the last part of the loop, and overide at the start of the loop)
>
> and in complex_12bits filtering
> i use m4, for the same reason
>

Patch LGTM, thanks!

Regards,
Thomas
___
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)

2017-12-14 Thread Thomas Mundt
Hi,

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

> Hello,
>
>
> 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)
>
> Use unaligned load, to avoid crash
>

this changes the color planes when zscale filter is in front.
Compare this command line output with and without your patch:
ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
zscale,interlace -c:v mpeg2video -t 5 test.mpg

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


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

2017-12-14 Thread Steven Robertson
With FCPX 10.4, Apple has expanded the set of colorspace, primaries,
and trc flags officially supported in QuickTime files. The expanded set
matches the codepoints used in ffmpeg and many other specs.
---
 libavformat/movenc.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 901577401e..a597b0853d 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1809,23 +1809,30 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack 
*track)
 ffio_wfourcc(pb, "nclc");
 switch (track->par->color_primaries) {
 case AVCOL_PRI_BT709: avio_wb16(pb, 1); break;
+case AVCOL_PRI_BT470BG:   avio_wb16(pb, 5); break;
 case AVCOL_PRI_SMPTE170M:
 case AVCOL_PRI_SMPTE240M: avio_wb16(pb, 6); break;
-case AVCOL_PRI_BT470BG:   avio_wb16(pb, 5); break;
+case AVCOL_PRI_BT2020:avio_wb16(pb, 9); break;
+case AVCOL_PRI_SMPTE431:  avio_wb16(pb, 11); break;
+case AVCOL_PRI_SMPTE432:  avio_wb16(pb, 12); break;
 default:  avio_wb16(pb, 2);
 }
 switch (track->par->color_trc) {
-case AVCOL_TRC_BT709: avio_wb16(pb, 1); break;
-case AVCOL_TRC_SMPTE170M: avio_wb16(pb, 1); break; // remapped
-case AVCOL_TRC_SMPTE240M: avio_wb16(pb, 7); break;
-default:  avio_wb16(pb, 2);
+case AVCOL_TRC_BT709:avio_wb16(pb, 1); break;
+case AVCOL_TRC_SMPTE170M:avio_wb16(pb, 1); break; // remapped
+case AVCOL_TRC_SMPTE240M:avio_wb16(pb, 7); break;
+case AVCOL_TRC_SMPTEST2084:  avio_wb16(pb, 16); break;
+case AVCOL_TRC_SMPTE428: avio_wb16(pb, 17); break;
+case AVCOL_TRC_ARIB_STD_B67: avio_wb16(pb, 18); break;
+default: avio_wb16(pb, 2);
 }
 switch (track->par->color_space) {
-case AVCOL_SPC_BT709: avio_wb16(pb, 1); break;
+case AVCOL_SPC_BT709:  avio_wb16(pb, 1); break;
 case AVCOL_SPC_BT470BG:
-case AVCOL_SPC_SMPTE170M: avio_wb16(pb, 6); break;
-case AVCOL_SPC_SMPTE240M: avio_wb16(pb, 7); break;
-default:  avio_wb16(pb, 2);
+case AVCOL_SPC_SMPTE170M:  avio_wb16(pb, 6); break;
+case AVCOL_SPC_SMPTE240M:  avio_wb16(pb, 7); break;
+case AVCOL_SPC_BT2020_NCL: avio_wb16(pb, 9); break;
+default:   avio_wb16(pb, 2);
 }
 
 if (track->mode == MODE_MP4) {
-- 
2.15.1.504.g5279b80103-goog

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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Lou Logan
On Thu, Dec 14, 2017, at 04:26 AM, wm4 wrote:
> The subject of the vote is:
> 
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?

I vote "yes".

(But I can't remember if I'm on the vote list and I couldn't find it.)

Also, I believe Zeranoe stopped providing XP builds in 2016 so it will
be no issue downstream.
___
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

2017-12-14 Thread wm4
On Thu, 14 Dec 2017 19:54:26 +0100
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.  
> 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.

Ah, OK. Patch 1/2 dropped then.
___
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

2017-12-14 Thread Jorge Ramirez

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.

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


[FFmpeg-devel] [PATCH 2/2] rkmppdec: move AV_CODEC_CAP_AVOID_PROBING to the correct field

2017-12-14 Thread wm4
AVCodec.caps_internal doesn't hold this field.
---
 libavcodec/rkmppdec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/rkmppdec.c b/libavcodec/rkmppdec.c
index fa522ce2ed..c57a6ded38 100644
--- a/libavcodec/rkmppdec.c
+++ b/libavcodec/rkmppdec.c
@@ -588,8 +588,7 @@ static const AVCodecHWConfigInternal *rkmpp_hw_configs[] = {
 .receive_frame  = rkmpp_receive_frame, \
 .flush  = rkmpp_flush, \
 .priv_class = &rkmpp_##NAME##_dec_class, \
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARDWARE, \
-.caps_internal  = AV_CODEC_CAP_AVOID_PROBING, \
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE, \
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_DRM_PRIME, 
\
  AV_PIX_FMT_NONE}, \
 .hw_configs = rkmpp_hw_configs, \
-- 
2.15.1

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


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

2017-12-14 Thread wm4
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.
---
 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", \
 };
 
-- 
2.15.1

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


Re: [FFmpeg-devel] [PATCH] avcodec: add metadata to identify wrappers and hardware decoders

2017-12-14 Thread wm4
On Thu, 14 Dec 2017 16:02:59 +0100
wm4  wrote:

> Explicitly identify decoder/encoder wrappers with a common name. This
> saves API users from guessing by the name suffix. For example, they
> don't have to guess that "h264_qsv" is the h264 QSV implementation, and
> instead they can just check the AVCodec .codec and .wrapper_name fields.
> 
> Explicitly mark AVCodec entries that are hardware decoders or most
> likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
> API users listing hardware decoders in a more generic way. The proposed
> AVCodecHWConfig does not provide this information fully, because it's
> concerned with decoder configuration, not information about the fact
> whether the hardware is used or not.
> 
> AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
> implementations in case the hardware is not capable.
> 
> Based on a patch by Philip Langdale .
> ---

Pushed, with some fixes.

I apologize in advance should this break anything. (Lots of external
libraries.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add metadata to identify wrappers and hardware decoders

2017-12-14 Thread Philip Langdale

On 2017-12-14 07:02, wm4 wrote:

Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name 
fields.


Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is 
allowing

API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.

AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have 
software

implementations in case the hardware is not capable.

Based on a patch by Philip Langdale .


Ship it.

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

2017-12-14 Thread wm4
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 = &amediacodec_class;   
> > > > >\
> > > > > + 
> > > > >\
> > > > > +env = ff_jni_get_env(codec); 
> > > > >\
> > > > > +if (!env) {  
> > > > >\
> > > > > +av_freep(&codec);
> > > > >\
> > > > > +return NULL; 
> > > > >\
> > > > > +}
> > > > >\
> > > > > + 
> > > > >\
> > > > > +if (ff_jni_init_jfields(env, &codec->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,
> > > > >\
> > > > > +jarg);   
> > > > >\
> > > > > +if (ff_jni_exception_check(env, 1, codec) < 0) { 
> > > > >\
> > > > > +goto fail;   
> > > > >

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

2017-12-14 Thread Jacob Trimble
On Fri, Dec 8, 2017 at 10:06 AM, Jacob Trimble  wrote:
> On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
>  wrote:
>> On 12/6/2017 12:36 AM, Jacob Trimble wrote:
>>> Would a 0-length array work?  Otherwise I would need to have it be a
>>> 1-length array and have to account for that when calculating the size
>>> to allocate; it would also require a comment to ignore the size of the
>>> array.
>>
>> Aren't 0-length arrays a GNU extensions? If so, I would gather that it
>> probably is not OK in a public header, either.
>
> Yeah.
>
>> I'm not entirely sure what way we prefer nowadays, but you can see
>> we've had side data with variable length members before with e.g.
>> AV_PKT_DATA_QUALITY_STATS, but that doesn't have a struct associated
>> with it. I'm hoping someone more up to date with the side data stuff
>> can chime in with a suggestion on what our current best practices
>> are for it.
>
> I would prefer to avoid requiring the app to "parse" the side data, using a
> plain struct would be better.  I've updated the patch to include my other plan
> of allocating a larger bock and having the struct followed by the subsample
> array.
>
> I have also renamed the file, I think the mailing list rejected my attachment
> before since gmail sent the MIME type as text/x-patch.  Hopefully with the
> .txt extension gmail will send the correct MIME type.

Ping.  Is this something that can be pushed?  I have the implementation for
mov almost ready.  I think having this info exposed would be something that
would be really useful for the project.
___
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

2017-12-14 Thread Matthieu Bouron
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 = &amediacodec_class; 
> > > >  \
> > > > +   
> > > >  \
> > > > +env = ff_jni_get_env(codec);   
> > > >  \
> > > > +if (!env) {
> > > >  \
> > > > +av_freep(&codec);  
> > > >  \
> > > > +return NULL;   
> > > >  \
> > > > +}  
> > > >  \
> > > > +   
> > > >  \
> > > > +if (ff_jni_init_jfields(env, &codec->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,  
> > > >  \
> > > > +jarg); 
> > > >  \
> > > > +if (ff_jni_exception_check(env, 1, codec) < 0) {   
> > > >  \
> > > > +goto fail; 
> > > >  \
> > > > +}  
> > > >  \
> > > > +   
> > > >  \
> > > > +codec->

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

2017-12-14 Thread Martin Vignali
Hello,

related to ticket 6491 (crash using crop and vf_interlace)

in attach patch to fix crash when data are unaligned, with low_pass_complex
filtering
(the previous patch, fix crash, for low_pass_simple filtering)


Can be test with
For 8 bits
./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
crop=1440:1080,interlace=lowpass=2 -f null -

For > 8 bits :
./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p10le -vf
crop=1442:1080,interlace=lowpass=2 -f null -

i use m2 as temp xmm, in order to make an unaligned load (m2 is not use in
the last part of the loop, and overide at the start of the loop)

and in complex_12bits filtering
i use m4, for the same reason

Martin


0004-avfilter-x86-vf_interlace-avfilter-x86-vf_interlace-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add metadata to identify wrappers and hardware decoders

2017-12-14 Thread wm4
On Thu, 14 Dec 2017 16:01:49 +
Aman Gupta  wrote:


> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index 086beb41fc..c47e5c4045 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -2599,8 +2599,9 @@ AVCodec ff_hevc_videotoolbox_encoder = {
> >  .init = vtenc_init,
> >  .encode2  = vtenc_frame,
> >  .close= vtenc_close,
> > -.capabilities = AV_CODEC_CAP_DELAY,
> > +.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARSWARE,  
> 
> 
> Typo, s/HARS/HARD/

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


[FFmpeg-devel] [PATCH v2 2/3] avformat/hlsenc: Handle NULL input in IO open and close utility functions

2017-12-14 Thread Karthick J
From: Karthick Jeyapal 

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

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 30d0285..af9d949 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -246,7 +246,7 @@ static int is_http_proto(char *filename) {
 static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
   AVDictionary **options) {
 HLSContext *hls = s->priv_data;
-int http_base_proto = is_http_proto(filename);
+int http_base_proto = filename ? 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);
@@ -262,7 +262,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 = is_http_proto(filename);
+int http_base_proto = filename ? is_http_proto(filename) : 0;
 
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
-- 
1.9.1

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


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

2017-12-14 Thread Karthick J
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 | 56 +---
 1 file changed, 27 insertions(+), 29 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index af9d949..e3442c3 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -203,6 +203,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) {
@@ -1085,7 +1087,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;
@@ -1106,8 +1107,7 @@ static int create_master_playlist(AVFormatContext *s,
 
 set_http_options(s, &options, hls);
 
-ret = s->io_open(s, &master_pb, hls->master_m3u8_url, AVIO_FLAG_WRITE,\
- &options);
+ret = hlsenc_io_open(s, &hls->m3u8_out, hls->master_m3u8_url, &options);
 av_dict_free(&options);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Failed to open master play list file 
'%s'\n",
@@ -1115,7 +1115,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++) {
@@ -1156,7 +1156,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(&m3u8_rel_name);
 }
@@ -1164,7 +1164,7 @@ fail:
 if(ret >=0)
 hls->master_m3u8_created = 1;
 av_freep(&m3u8_rel_name);
-ff_format_io_close(s, &master_pb);
+hlsenc_io_close(s, &hls->m3u8_out, hls->master_m3u8_url);
 return ret;
 }
 
@@ -1174,8 +1174,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);
@@ -1207,7 +1205,7 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 
 set_http_options(s, &options, hls);
 snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
"%s", vs->m3u8_name);
-if ((ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, &options)) 
< 0)
+if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 0)
 goto fail;
 
 for (en = vs->segments; en; en = en->next) {
@@ -1216,67 +1214,67 @@ 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 ==

[FFmpeg-devel] [PATCH v2 1/3] avformat/hlsenc: Call avio_flush during persistent http connections

2017-12-14 Thread Karthick J
From: Karthick Jeyapal 

Since close is not called, during http persistent connection,
flush needs to be called so that output is written on time.
---
 libavformat/hlsenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index fdf614b..30d0285 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -266,6 +266,8 @@ static void hlsenc_io_close(AVFormatContext *s, AVIOContext 
**pb, char *filename
 
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
+} else {
+avio_flush(*pb);
 }
 }
 
-- 
1.9.1

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


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

2017-12-14 Thread 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.
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.

Regards,
Karthick
>
>[…]
>Thanks
>
>
>Steven



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


[FFmpeg-devel] [PATCH 2/2] configure: use pkg-config to detect openal

2017-12-14 Thread Stephen Hutchinson
---
 configure | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index ec6e570472..059eae7b39 100755
--- a/configure
+++ b/configure
@@ -288,7 +288,7 @@ External library support:
   --enable-libndi_newtek   enable Newteck NDI I/O support [no]
   --enable-mediacodec  enable Android MediaCodec support [no]
   --enable-libmysofa   enable libmysofa, needed for sofalizer filter [no]
-  --enable-openal  enable OpenAL 1.1 capture support [no]
+  --enable-openal  enable OpenAL 1.1-compatible capture support via 
OpenAL-soft [no]
   --enable-opencl  enable OpenCL processing [no]
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
@@ -5949,11 +5949,7 @@ enabled mmal  && { check_lib mmal 
interface/mmal/mmal.h mmal_port_co
  check_lib mmal interface/mmal/mmal.h 
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host; } ||
die "ERROR: mmal not found" &&
check_func_headers interface/mmal/mmal.h 
"MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS"; }
-enabled openal&& { { for al_extralibs in "${OPENAL_LIBS}" 
"-lopenal" "-lOpenAL32"; do
-   check_lib openal 'AL/al.h' alGetError 
"${al_extralibs}" && break; done } ||
-   die "ERROR: openal not found"; } &&
- { check_cpp_condition "AL/al.h" 
"defined(AL_VERSION_1_1)" ||
-   die "ERROR: openal must be installed and 
version must be 1.1 or compatible"; }
+enabled openal&& require_pkg_config openal "openal >= 1.12" 
AL/al.h alGetError
 enabled opencl&& { check_lib opencl OpenCL/cl.h 
clEnqueueNDRangeKernel -Wl,-framework,OpenCL ||
check_lib opencl CL/cl.h clEnqueueNDRangeKernel 
-lOpenCL ||
die "ERROR: opencl not found"; } &&
-- 
2.14.1

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


[FFmpeg-devel] [PATCH 1/2] configure: use pkg-config to detect twolame

2017-12-14 Thread Stephen Hutchinson
---
 configure | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/configure b/configure
index d5bbb5b7a9..ec6e570472 100755
--- a/configure
+++ b/configure
@@ -5889,9 +5889,7 @@ enabled libssh&& require_pkg_config libssh 
libssh libssh/sftp.h sftp
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
-enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
- { check_lib libtwolame twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
-   die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
+enabled libtwolame&& require_pkg_config libtwolame "twolame >= 0.3.10" 
twolame.h twolame_init
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
v4l2_ioctl
 enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98" 
vid.stab/libvidstab.h vsMotionDetectInit
 enabled libvmaf   && require_pkg_config libvmaf libvmaf libvmaf.h 
compute_vmaf
-- 
2.14.1

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


[FFmpeg-devel] [PATCH 0/2] pkg-config detection for twolame, openal (alternate)

2017-12-14 Thread Stephen Hutchinson
Based on the suggestions last time*, this
version of the patchset switches twolame and openal
completely over to pkg-config.

I personally don't care whether this version or
the previous version with the fallbacks are the
ones accepted, I really only care that pkg-config
support gets added for these two.

*http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221360.html

Stephen Hutchinson (2):
  configure: use pkg-config to detect twolame
  configure: use pkg-config to detect openal

 configure | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

-- 
2.14.1

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


Re: [FFmpeg-devel] [PATCH] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread Michael Niedermayer
On Thu, Dec 14, 2017 at 03:00:50AM -0500, mymoey...@gmail.com wrote:
> From: wu zhiqiang 
> 
> When using concat protocal, start from middle of file will generate non-zero 
> wrap reference. If seek to time less than the wrap reference, wrap control 
> will be triggered and generate wrong wrapped timestamp.
> Copy wrap related stream properties when reading header can fix this problem.
> 
> Signed-off-by: wu zhiqiang 
> ---
>  libavformat/concatdec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 0e189012ad..e933888661 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st, AVStream 
> *source_st)
>  st->time_base   = source_st->time_base;
>  st->sample_aspect_ratio = source_st->sample_aspect_ratio;
>  
> +/* Fix wrap control problem */
> +st->pts_wrap_bits   = source_st->pts_wrap_bits;
> +st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
> +st->pts_wrap_reference  = source_st->pts_wrap_reference;

why does this not use avpriv_set_pts_info() ?


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

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


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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread James Almer
On 12/14/2017 10:26 AM, wm4 wrote:
> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
> 
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
> 
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
> 
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
> 
> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
> 
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
> 
> The subject of the vote is:
> 
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?
> 
> Current release branches are explicitly unaffected.
> 
> My own vote on this issue is "yes" (assuming I still have a right for a
> vote, I really don't know).

I vote yes, of course.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add metadata to identify wrappers and hardware decoders

2017-12-14 Thread Aman Gupta
On Thu, Dec 14, 2017 at 7:10 AM wm4  wrote:

> Explicitly identify decoder/encoder wrappers with a common name. This
> saves API users from guessing by the name suffix. For example, they
> don't have to guess that "h264_qsv" is the h264 QSV implementation, and
> instead they can just check the AVCodec .codec and .wrapper_name fields.
>
> Explicitly mark AVCodec entries that are hardware decoders or most
> likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
> API users listing hardware decoders in a more generic way. The proposed
> AVCodecHWConfig does not provide this information fully, because it's
> concerned with decoder configuration, not information about the fact
> whether the hardware is used or not.
>
> AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
> implementations in case the hardware is not capable.
>
> Based on a patch by Philip Langdale .
> ---
>  doc/APIchanges  |  4 
>  libavcodec/audiotoolboxdec.c|  1 +
>  libavcodec/audiotoolboxenc.c|  1 +
>  libavcodec/avcodec.h| 26 ++
>  libavcodec/cuviddec.c   |  3 ++-
>  libavcodec/libcelt_dec.c|  1 +
>  libavcodec/libfdk-aacdec.c  |  1 +
>  libavcodec/libfdk-aacenc.c  |  1 +
>  libavcodec/libgsmdec.c  |  2 ++
>  libavcodec/libgsmenc.c  |  2 ++
>  libavcodec/libilbc.c|  1 +
>  libavcodec/libkvazaar.c |  2 ++
>  libavcodec/libmp3lame.c |  1 +
>  libavcodec/libopencore-amr.c|  1 +
>  libavcodec/libopenh264dec.c |  1 +
>  libavcodec/libopenh264enc.c |  1 +
>  libavcodec/libopenjpegdec.c |  1 +
>  libavcodec/libopenjpegenc.c |  1 +
>  libavcodec/libopusdec.c |  1 +
>  libavcodec/libopusenc.c |  1 +
>  libavcodec/librsvgdec.c |  1 +
>  libavcodec/libshine.c   |  1 +
>  libavcodec/libspeexdec.c|  1 +
>  libavcodec/libspeexenc.c|  1 +
>  libavcodec/libtheoraenc.c   |  1 +
>  libavcodec/libtwolame.c |  1 +
>  libavcodec/libvo-amrwbenc.c |  1 +
>  libavcodec/libvorbisenc.c   |  1 +
>  libavcodec/libvpxdec.c  |  2 ++
>  libavcodec/libvpxenc.c  |  2 ++
>  libavcodec/libwavpackenc.c  |  1 +
>  libavcodec/libwebpenc.c |  1 +
>  libavcodec/libwebpenc_animencoder.c |  1 +
>  libavcodec/libx264.c|  3 +++
>  libavcodec/libx265.c|  1 +
>  libavcodec/libxavs.c|  1 +
>  libavcodec/libxvid.c|  1 +
>  libavcodec/libzvbi-teletextdec.c|  1 +
>  libavcodec/mediacodecdec.c  | 18 --
>  libavcodec/mmaldec.c|  3 ++-
>  libavcodec/nvenc_h264.c |  9 ++---
>  libavcodec/nvenc_hevc.c |  6 --
>  libavcodec/qsvdec_h2645.c   |  6 --
>  libavcodec/qsvdec_other.c   |  9 ++---
>  libavcodec/qsvenc_h264.c|  3 ++-
>  libavcodec/qsvenc_hevc.c|  3 ++-
>  libavcodec/qsvenc_jpeg.c|  3 ++-
>  libavcodec/qsvenc_mpeg2.c   |  3 ++-
>  libavcodec/v4l2_m2m_dec.c   |  2 ++
>  libavcodec/v4l2_m2m_enc.c   |  2 ++
>  libavcodec/vaapi_encode_h264.c  |  3 ++-
>  libavcodec/vaapi_encode_h265.c  |  3 ++-
>  libavcodec/vaapi_encode_mjpeg.c |  2 ++
>  libavcodec/vaapi_encode_mpeg2.c |  3 ++-
>  libavcodec/vaapi_encode_vp8.c   |  3 ++-
>  libavcodec/vaapi_encode_vp9.c   |  3 ++-
>  libavcodec/version.h|  4 ++--
>  libavcodec/videotoolboxenc.c|  3 ++-
>  58 files changed, 136 insertions(+), 30 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4af69c64bd..b4451ab193 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2017-xx-xx - xxc - lavc 58.7.100 - avcodec.h
> +  Add AV_CODEC_CAP_HARDWARE, AV_CODEC_CAP_HYBRID, and
> AVCodec.wrapper_name,
> +  and mark all AVCodecs accordingly.
> +
>  2017-xx-xx - xxx - lavu 56.4.100 / 56.7.0 - stereo3d.h
>Add view field to AVStereo3D structure and AVStereo3DView enum.
>
> diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
> index 3711665bbd..5c0a9de8f6 100644
> --- a/libavcodec/audiotoolboxdec.c
> +++ b/libavcodec/audiotoolboxdec.c
> @@ -597,6 +597,7 @@ static av_cold int ffat_close_decoder(AVCodecContext
> *avctx)
>  .bsfs   = bsf_name, \
>  .capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY, \
>  .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP, \
> +.wrapper_name   = "at", \
>  };
>
>  FFAT_DEC(aac,  AV_CODEC_ID_AAC, "aac_adtstoasc")
> diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
> index c47fbd1b2d..71885d1530 100644
> --- a/libavcodec/audio

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

2017-12-14 Thread Martin Vignali
Hello,


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)

Use unaligned load, to avoid crash


Doesn't fix crash when using low_pass_complex :
./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
crop=1440:1080,interlace=lowpass=2 -f null -

This "second" crash seems to be also in the asm part (doesn't happen for
me, when using -cpuflags 0)

Martin


0003-avfilter-x86-vf_interlace-avoid-crash-when-data-are-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec: add metadata to identify wrappers and hardware decoders

2017-12-14 Thread wm4
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.

Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.

AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.

Based on a patch by Philip Langdale .
---
 doc/APIchanges  |  4 
 libavcodec/audiotoolboxdec.c|  1 +
 libavcodec/audiotoolboxenc.c|  1 +
 libavcodec/avcodec.h| 26 ++
 libavcodec/cuviddec.c   |  3 ++-
 libavcodec/libcelt_dec.c|  1 +
 libavcodec/libfdk-aacdec.c  |  1 +
 libavcodec/libfdk-aacenc.c  |  1 +
 libavcodec/libgsmdec.c  |  2 ++
 libavcodec/libgsmenc.c  |  2 ++
 libavcodec/libilbc.c|  1 +
 libavcodec/libkvazaar.c |  2 ++
 libavcodec/libmp3lame.c |  1 +
 libavcodec/libopencore-amr.c|  1 +
 libavcodec/libopenh264dec.c |  1 +
 libavcodec/libopenh264enc.c |  1 +
 libavcodec/libopenjpegdec.c |  1 +
 libavcodec/libopenjpegenc.c |  1 +
 libavcodec/libopusdec.c |  1 +
 libavcodec/libopusenc.c |  1 +
 libavcodec/librsvgdec.c |  1 +
 libavcodec/libshine.c   |  1 +
 libavcodec/libspeexdec.c|  1 +
 libavcodec/libspeexenc.c|  1 +
 libavcodec/libtheoraenc.c   |  1 +
 libavcodec/libtwolame.c |  1 +
 libavcodec/libvo-amrwbenc.c |  1 +
 libavcodec/libvorbisenc.c   |  1 +
 libavcodec/libvpxdec.c  |  2 ++
 libavcodec/libvpxenc.c  |  2 ++
 libavcodec/libwavpackenc.c  |  1 +
 libavcodec/libwebpenc.c |  1 +
 libavcodec/libwebpenc_animencoder.c |  1 +
 libavcodec/libx264.c|  3 +++
 libavcodec/libx265.c|  1 +
 libavcodec/libxavs.c|  1 +
 libavcodec/libxvid.c|  1 +
 libavcodec/libzvbi-teletextdec.c|  1 +
 libavcodec/mediacodecdec.c  | 18 --
 libavcodec/mmaldec.c|  3 ++-
 libavcodec/nvenc_h264.c |  9 ++---
 libavcodec/nvenc_hevc.c |  6 --
 libavcodec/qsvdec_h2645.c   |  6 --
 libavcodec/qsvdec_other.c   |  9 ++---
 libavcodec/qsvenc_h264.c|  3 ++-
 libavcodec/qsvenc_hevc.c|  3 ++-
 libavcodec/qsvenc_jpeg.c|  3 ++-
 libavcodec/qsvenc_mpeg2.c   |  3 ++-
 libavcodec/v4l2_m2m_dec.c   |  2 ++
 libavcodec/v4l2_m2m_enc.c   |  2 ++
 libavcodec/vaapi_encode_h264.c  |  3 ++-
 libavcodec/vaapi_encode_h265.c  |  3 ++-
 libavcodec/vaapi_encode_mjpeg.c |  2 ++
 libavcodec/vaapi_encode_mpeg2.c |  3 ++-
 libavcodec/vaapi_encode_vp8.c   |  3 ++-
 libavcodec/vaapi_encode_vp9.c   |  3 ++-
 libavcodec/version.h|  4 ++--
 libavcodec/videotoolboxenc.c|  3 ++-
 58 files changed, 136 insertions(+), 30 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 4af69c64bd..b4451ab193 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-xx-xx - xxc - lavc 58.7.100 - avcodec.h
+  Add AV_CODEC_CAP_HARDWARE, AV_CODEC_CAP_HYBRID, and AVCodec.wrapper_name,
+  and mark all AVCodecs accordingly.
+
 2017-xx-xx - xxx - lavu 56.4.100 / 56.7.0 - stereo3d.h
   Add view field to AVStereo3D structure and AVStereo3DView enum.
 
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 3711665bbd..5c0a9de8f6 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -597,6 +597,7 @@ static av_cold int ffat_close_decoder(AVCodecContext *avctx)
 .bsfs   = bsf_name, \
 .capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY, \
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE | 
FF_CODEC_CAP_INIT_CLEANUP, \
+.wrapper_name   = "at", \
 };
 
 FFAT_DEC(aac,  AV_CODEC_ID_AAC, "aac_adtstoasc")
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index c47fbd1b2d..71885d1530 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -619,6 +619,7 @@ static const AVOption options[] = {
 }, \
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE, \
 .profiles   = PROFILES, \
+.wrapper_name   = "at", \
 

Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread wm4
On Thu, 14 Dec 2017 16:01:55 +0100
Michael Niedermayer  wrote:

> On Thu, Dec 14, 2017 at 02:26:31PM +0100, wm4 wrote:
> > I propose that FFmpeg sets the minimum supported Windows version to
> > Windows Vista (or maybe Windows 7). This would remove Windows XP
> > support.
> > 
> > The reason is that Windows XP does not provide certain convenient APIs,
> > in particular locking primitives that map well to pthread. There are
> > other problems, such as upstream projects dropping XP support, and
> > developers not being able to test.
> > 
> > Dropping it has advantages for us. For example, it would allow is to
> > rewrite the messy locking code for AVCodec registration, which has been
> > a topic recently.
> > 
> > Microsoft ended all support for Windows XP on January 31, 2009. That's
> > almost a decade ago. There is a lack of security updates, which makes
> > merely using Windows XP dangerous. There is no reason to put so much
> > effort into supporting an old, unsupported OS.
> > 
> > We should drop XP support, and allow unconditional use of Windows Vista
> > APIs.
> > 
> > I'm also casting an internal vote to probe for support (this vote is
> > meant for members of the FFmpeg voting committee only).
> > 
> > The subject of the vote is:
> > 
> >   Should we drop support for Windows XP starting in git master and the
> >   next FFmpeg major release?
> > 
> > Current release branches are explicitly unaffected.
> > 
> > My own vote on this issue is "yes" (assuming I still have a right for a
> > vote, I really don't know).  
> 
> I dont remember anyone opposing "droping XP support", I have to wonder
> why there is a vote on something, noone (that i remember) objected
> to. At least not recently.

To avoid flamewars and drama when someone actually makes a change that
would break Windows XP.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Michael Niedermayer
On Thu, Dec 14, 2017 at 02:26:31PM +0100, wm4 wrote:
> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
> 
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
> 
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
> 
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
> 
> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
> 
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
> 
> The subject of the vote is:
> 
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?
> 
> Current release branches are explicitly unaffected.
> 
> My own vote on this issue is "yes" (assuming I still have a right for a
> vote, I really don't know).

I dont remember anyone opposing "droping XP support", I have to wonder
why there is a vote on something, noone (that i remember) objected
to. At least not recently.


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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


Re: [FFmpeg-devel] [PATCH v6 1/3] avformat/hlsenc:addition of #EXT-X-MEDIA tag and AUDIO attribute

2017-12-14 Thread Steven Liu



> 在 2017年12月14日,下午6:52,vdi...@akamai.com 写道:
> 
> From: Vishwanath Dixit 
> 
> ---
> doc/muxers.texi   | 12 +
> libavformat/dashenc.c |  3 ++-
> libavformat/hlsenc.c  | 62 ---
> libavformat/hlsplaylist.c |  4 ++-
> libavformat/hlsplaylist.h |  2 +-
> 5 files changed, 77 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 3d0c7bf..93db549 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -834,6 +834,18 @@ be a video only stream with video bitrate 1000k, the 
> second variant stream will
> be an audio only stream with bitrate 64k and the third variant stream will be 
> a
> video only stream with bitrate 256k. Here, three media playlist with file 
> names
> out_1.m3u8, out_2.m3u8 and out_3.m3u8 will be created.
> +@example
> +ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k -b:v:1 3000k  \
> +  -map 0:a -map 0:a -map 0:v -map 0:v -f hls \
> +  -var_stream_map "a:0,agroup:aud_low a:1,agroup:aud_high v:0,agroup:aud_low 
> v:1,agroup:aud_high" \
> +  -master_pl_name master.m3u8 \
> +  http://example.com/live/out.m3u8
> +@end example
> +This example creates two audio only and two video only variant streams. In
> +addition to the #EXT-X-STREAM-INF tag for each variant stream in the master
> +playlist, #EXT-X-MEDIA tag is also added for the two audio only variant 
> streams
> +and they are mapped to the two video only variant streams with audio group 
> names
> +'aud_low' and 'aud_high'.
> 
> By default, a single hls variant containing all the encoded streams is 
> created.
> 
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5687530..f363418 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -759,7 +759,8 @@ static int write_manifest(AVFormatContext *s, int final)
> char playlist_file[64];
> AVStream *st = s->streams[i];
> get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
> i);
> -ff_hls_write_stream_info(st, out, st->codecpar->bit_rate, 
> playlist_file);
> +ff_hls_write_stream_info(st, out, st->codecpar->bit_rate,
> +playlist_file, NULL);
> }
> avio_close(out);
> if (use_rename)
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index fdf614b..273dd8a 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -144,6 +144,7 @@ typedef struct VariantStream {
> AVStream **streams;
> unsigned int nb_streams;
> int m3u8_created; /* status of media play-list creation */
> +char *agroup; /* audio group name */
> char *baseurl;
> } VariantStream;
> 
> @@ -1081,7 +1082,7 @@ static int create_master_playlist(AVFormatContext *s,
>   VariantStream * const input_vs)
> {
> HLSContext *hls = s->priv_data;
> -VariantStream *vs;
> +VariantStream *vs, *temp_vs;
> AVStream *vid_st, *aud_st;
> AVIOContext *master_pb = 0;
> AVDictionary *options = NULL;
> @@ -1115,6 +1116,34 @@ static int create_master_playlist(AVFormatContext *s,
> 
> ff_hls_write_playlist_version(master_pb, hls->version);
> 
> +/* For audio only variant streams add #EXT-X-MEDIA tag with attributes*/
> +for (i = 0; i < hls->nb_varstreams; i++) {
> +vs = &(hls->var_streams[i]);
> +
> +if (vs->has_video || vs->has_subtitle || !vs->agroup)
> +continue;
> +
> +m3u8_name_size = strlen(vs->m3u8_name) + 1;
> +m3u8_rel_name = av_malloc(m3u8_name_size);
> +if (!m3u8_rel_name) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +av_strlcpy(m3u8_rel_name, vs->m3u8_name, m3u8_name_size);
> +ret = get_relative_url(hls->master_m3u8_url, vs->m3u8_name,
> +   m3u8_rel_name, m3u8_name_size);
> +if (ret < 0) {
> +av_log(s, AV_LOG_ERROR, "Unable to find relative URL\n");
> +goto fail;
> +}
> +
> +avio_printf(master_pb, 
> "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=\"group_%s\"",
> +vs->agroup);
> +avio_printf(master_pb, ",NAME=\"audio_0\",DEFAULT=YES,URI=\"%s\"\n",
> +m3u8_rel_name);
> +av_freep(&m3u8_rel_name);
> +}
> +
> /* For variant streams with video add #EXT-X-STREAM-INF tag with 
> attributes*/
> for (i = 0; i < hls->nb_varstreams; i++) {
> vs = &(hls->var_streams[i]);
> @@ -1147,6 +1176,25 @@ static int create_master_playlist(AVFormatContext *s,
> continue;
> }
> 
> +/**
> + * Traverse through the list of audio only rendition streams and find
> + * the rendition which has highest bitrate in the same audio group
> + */
> +if (vs->agroup) {
> +for (j = 0; j < hls->nb_varstreams; j++) {
> +temp_vs = &(hls->var_streams[j]);
> +if (!temp_vs->has_video && !temp_vs

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

2017-12-14 Thread Steven Liu



> 在 2017年12月14日,下午6:55,vdi...@akamai.com 写道:
> 
> From: Vishwanath Dixit 
> 
> ---
> libavformat/Makefile  |  2 +-
> libavformat/dashenc.c |  2 +-
> libavformat/hlsenc.c  | 65 +--
> libavformat/hlsplaylist.c |  5 +++-
> libavformat/hlsplaylist.h |  3 ++-
> libavformat/reverse.c |  1 +
> tests/ref/fate/source |  1 +
> 7 files changed, 73 insertions(+), 6 deletions(-)
> create mode 100644 libavformat/reverse.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 734b703..b7e042d 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -61,7 +61,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o   
> \
> rtpdec_vp9.o\
> rtpdec_xiph.o
> OBJS-$(CONFIG_RTPENC_CHAIN)  += rtpenc_chain.o rtp.o
> -OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o
> +OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o reverse.o
> OBJS-$(CONFIG_SRTP)  += srtp.o
> 
> # muxers/demuxers
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f363418..016ada3 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -760,7 +760,7 @@ static int write_manifest(AVFormatContext *s, int final)
> AVStream *st = s->streams[i];
> get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
> i);
> ff_hls_write_stream_info(st, out, st->codecpar->bit_rate,
> -playlist_file, NULL);
> +playlist_file, NULL, NULL);
> }
> avio_close(out);
> if (use_rename)
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 273dd8a..ed64847 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -39,6 +39,7 @@
> #include "libavutil/avstring.h"
> #include "libavutil/intreadwrite.h"
> #include "libavutil/random_seed.h"
> +#include "libavutil/reverse.h"
> #include "libavutil/opt.h"
> #include "libavutil/log.h"
> #include "libavutil/time_internal.h"
> @@ -1078,6 +1079,63 @@ static int get_relative_url(const char *master_url, 
> const char *media_url,
> return 0;
> }
> 
> +static char *get_codec_str(AVStream *vid_st, AVStream *aud_st) {
> +size_t codec_str_size = 64;
> +char *codec_str = av_malloc(codec_str_size);
> +int video_str_len = 0;
> +
> +if (!codec_str)
> +return NULL;
> +
> +if (!vid_st && !aud_st) {
> +goto fail;
> +}
> +
> +if (vid_st) {
> +if (vid_st->codecpar->profile != FF_PROFILE_UNKNOWN &&
> +vid_st->codecpar->level != FF_LEVEL_UNKNOWN &&
> +vid_st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +snprintf(codec_str, codec_str_size, "avc1.%02x%02x%02x",
> + vid_st->codecpar->profile & 0xFF,
> + ff_reverse[(vid_st->codecpar->profile >> 8) & 0xFF],
> + vid_st->codecpar->level);
> +} else {
> +goto fail;
> +}
> +video_str_len = strlen(codec_str);
> +}
> +
> +if (aud_st) {
> +char *audio_str = codec_str;
> +if (video_str_len) {
> +codec_str[video_str_len] = ',';
> +video_str_len += 1;
> +audio_str += video_str_len;
> +codec_str_size -= video_str_len;
> +}
> +if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP2) {
> +snprintf(audio_str, codec_str_size, "mp4a.40.33");
> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP3) {
> +snprintf(audio_str, codec_str_size, "mp4a.40.34");
> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AAC) {
> +/* TODO : For HE-AAC, HE-AACv2, the last digit needs to be set 
> to 5 and 29 respectively */
> +snprintf(audio_str, codec_str_size, "mp4a.40.2");
> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AC3) {
> +snprintf(audio_str, codec_str_size, "mp4a.A5");
> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_EAC3) {
> +snprintf(audio_str, codec_str_size, "mp4a.A6");
> +} else {
> +goto fail;
> +}
> +}
> +
> +return codec_str;
> +
> +fail:
> +av_free(codec_str);
> +return NULL;
> +}
> +
> static int create_master_playlist(AVFormatContext *s,
>   VariantStream * const input_vs)
> {
> @@ -1088,7 +1146,7 @@ static int create_master_playlist(AVFormatContext *s,
> AVDictionary *options = NULL;
> unsigned int i, j;
> int m3u8_name_size, ret, bandwidth;
> -char *m3u8_rel_name;
> +char *m3u8_rel_name, *codec_str;
> 
> input_vs->m3u8_created = 1;
> if (!hls->master_m3u8_created) {
> @@ -1202,9 +1260,12 @@ static int create_master_playlist(AVFormatContext *s,
> bandwidth += aud_st->codecpar->bit_rate;

Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Tomas Härdin

On 2017-12-14 14:26, wm4 wrote:

I propose that FFmpeg sets the minimum supported Windows version to
Windows Vista (or maybe Windows 7). This would remove Windows XP
support.

The reason is that Windows XP does not provide certain convenient APIs,
in particular locking primitives that map well to pthread. There are
other problems, such as upstream projects dropping XP support, and
developers not being able to test.

Dropping it has advantages for us. For example, it would allow is to
rewrite the messy locking code for AVCodec registration, which has been
a topic recently.

Microsoft ended all support for Windows XP on January 31, 2009. That's
almost a decade ago. There is a lack of security updates, which makes
merely using Windows XP dangerous. There is no reason to put so much
effort into supporting an old, unsupported OS.

We should drop XP support, and allow unconditional use of Windows Vista
APIs.

I'm also casting an internal vote to probe for support (this vote is
meant for members of the FFmpeg voting committee only).

The subject of the vote is:

   Should we drop support for Windows XP starting in git master and the
   next FFmpeg major release?

Current release branches are explicitly unaffected.

My own vote on this issue is "yes" (assuming I still have a right for a
vote, I really don't know).


I'm not on the committee, but I'd vote "yes"

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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Rostislav Pehlivanov
On 14 December 2017 at 13:26, wm4  wrote:

> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
>
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
>
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
>
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
>
> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
>
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
>
> The subject of the vote is:
>
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?
>
> Current release branches are explicitly unaffected.
>
> My own vote on this issue is "yes" (assuming I still have a right for a
> vote, I really don't know).
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Steven Liu


> 在 2017年12月14日,下午10:12,Hendrik Leppkes  写道:
> 
>> On Thu, Dec 14, 2017 at 2:26 PM, wm4  wrote:
>> I propose that FFmpeg sets the minimum supported Windows version to
>> Windows Vista (or maybe Windows 7). This would remove Windows XP
>> support.
>> 
>> The reason is that Windows XP does not provide certain convenient APIs,
>> in particular locking primitives that map well to pthread. There are
>> other problems, such as upstream projects dropping XP support, and
>> developers not being able to test.
>> 
>> Dropping it has advantages for us. For example, it would allow is to
>> rewrite the messy locking code for AVCodec registration, which has been
>> a topic recently.
>> 
>> Microsoft ended all support for Windows XP on January 31, 2009. That's
>> almost a decade ago. There is a lack of security updates, which makes
>> merely using Windows XP dangerous. There is no reason to put so much
>> effort into supporting an old, unsupported OS.
>> 
> 
> End of Extended Support was April 8, 2014, but still already 3.5 years ago.
> 
>> We should drop XP support, and allow unconditional use of Windows Vista
>> APIs.
>> 
>> I'm also casting an internal vote to probe for support (this vote is
>> meant for members of the FFmpeg voting committee only).
>> 
>> The subject of the vote is:
>> 
>>  Should we drop support for Windows XP starting in git master and the
>>  next FFmpeg major release?
>> 
>> Current release branches are explicitly unaffected.
>> 
>> My own vote on this issue is "yes" (assuming I still have a right for a
>> vote, I really don't know).
> 
> 
> Yes, absolutely.
Yes too
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Hendrik Leppkes
On Thu, Dec 14, 2017 at 2:26 PM, wm4  wrote:
> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
>
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
>
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
>
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
>

End of Extended Support was April 8, 2014, but still already 3.5 years ago.

> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
>
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
>
> The subject of the vote is:
>
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?
>
> Current release branches are explicitly unaffected.
>
> My own vote on this issue is "yes" (assuming I still have a right for a
> vote, I really don't know).


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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Derek Buitenhuis
On 12/14/2017 1:26 PM, wm4 wrote:
> The subject of the vote is:
> 
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?

I am not on the voting list (which is form 2015 and contains people who have
since vanished, as well), but I would like to put forth my support for 'Yes',
even if it doesn't count as a real vote.

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


Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Rodger Combs


> On Dec 14, 2017, at 07:26, wm4  wrote:
> 
> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
> 
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
> 
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
> 
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
> 
> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
> 
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
> 
> The subject of the vote is:
> 
>  Should we drop support for Windows XP starting in git master and the
>  next FFmpeg major release?

Yes.

> 
> Current release branches are explicitly unaffected.
> 
> My own vote on this issue is "yes" (assuming I still have a right for a
> vote, I really don't know).
> ___
> 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] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Ronald S. Bultje
Hi,

On Thu, Dec 14, 2017 at 8:26 AM, wm4  wrote:

> I propose that FFmpeg sets the minimum supported Windows version to
> Windows Vista (or maybe Windows 7). This would remove Windows XP
> support.
>
> The reason is that Windows XP does not provide certain convenient APIs,
> in particular locking primitives that map well to pthread. There are
> other problems, such as upstream projects dropping XP support, and
> developers not being able to test.
>
> Dropping it has advantages for us. For example, it would allow is to
> rewrite the messy locking code for AVCodec registration, which has been
> a topic recently.
>
> Microsoft ended all support for Windows XP on January 31, 2009. That's
> almost a decade ago. There is a lack of security updates, which makes
> merely using Windows XP dangerous. There is no reason to put so much
> effort into supporting an old, unsupported OS.
>
> We should drop XP support, and allow unconditional use of Windows Vista
> APIs.
>
> I'm also casting an internal vote to probe for support (this vote is
> meant for members of the FFmpeg voting committee only).
>
> The subject of the vote is:
>
>   Should we drop support for Windows XP starting in git master and the
>   next FFmpeg major release?


Yes.

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


Re: [FFmpeg-devel] Correction to Webpage

2017-12-14 Thread wm4
On Thu, 14 Dec 2017 11:22:29 +0100
Carl Eugen Hoyos  wrote:

> 2017-12-14 11:12 GMT+01:00 Yogender Gupta :
> > I would like to correct a couple of lines on the following ffmpeg web page. 
> >  
> 
> > https://trac.ffmpeg.org/wiki/HWAccelIntro  
> 
> A wiki is a wiki.
> 
> > Can anyone please guide me on how to do it (push patch or raise
> > ticket or edit page)  
> 
> If you really need guidance to edit a wiki, I fear you are wrong here.

No reason to be this condescending.

> > This email message is for the sole use of the intended recipient(s) and may 
> > contain
> > confidential information.  
> 
> Please remove this from emails sent to a public mailing list.

I can't speak for him, but I suspect it's not up to them, and added by
the company mail server, and fighting against it is probably futile. In
any case I'd encourage nvidia people posting to this list to get the
message removed as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread wm4
I propose that FFmpeg sets the minimum supported Windows version to
Windows Vista (or maybe Windows 7). This would remove Windows XP
support.

The reason is that Windows XP does not provide certain convenient APIs,
in particular locking primitives that map well to pthread. There are
other problems, such as upstream projects dropping XP support, and
developers not being able to test.

Dropping it has advantages for us. For example, it would allow is to
rewrite the messy locking code for AVCodec registration, which has been
a topic recently.

Microsoft ended all support for Windows XP on January 31, 2009. That's
almost a decade ago. There is a lack of security updates, which makes
merely using Windows XP dangerous. There is no reason to put so much
effort into supporting an old, unsupported OS.

We should drop XP support, and allow unconditional use of Windows Vista
APIs.

I'm also casting an internal vote to probe for support (this vote is
meant for members of the FFmpeg voting committee only).

The subject of the vote is:

  Should we drop support for Windows XP starting in git master and the
  next FFmpeg major release?

Current release branches are explicitly unaffected.

My own vote on this issue is "yes" (assuming I still have a right for a
vote, I really don't know).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v6 2/3] avcodec/libx264:setting profile and level in avcodec context

2017-12-14 Thread Mark Thompson
On 14/12/17 10:54, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
> 
> ---
>  libavcodec/libx264.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 9c67c91..ac1f8bb 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -19,11 +19,13 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> +#include "libavutil/avassert.h"
>  #include "libavutil/eval.h"
>  #include "libavutil/internal.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/mem.h"
>  #include "libavutil/pixdesc.h"
> +#include "libavutil/reverse.h"
>  #include "libavutil/stereo3d.h"
>  #include "libavutil/intreadwrite.h"
>  #include "avcodec.h"
> @@ -454,6 +456,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
>  X264Context *x4 = avctx->priv_data;
>  AVCPBProperties *cpb_props;
>  int sw,sh;
> +x264_nal_t *nal;
> +uint8_t *p;
> +int nnal, s, i;

Minor style point (feel free to ignore): these variables don't all need to move 
to the outer scope.

>  
>  if (avctx->global_quality > 0)
>  av_log(avctx, AV_LOG_WARNING, "-qscale is ignored, -crf is 
> recommended.\n");
> @@ -799,12 +804,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (!x4->enc)
>  return AVERROR_EXTERNAL;
>  
> -if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
> -x264_nal_t *nal;
> -uint8_t *p;
> -int nnal, s, i;
> +s = x264_encoder_headers(x4->enc, &nal, &nnal);
> +// Assert for NAL start code and SPS unit type
> +av_assert0((nal->p_payload[0] | nal->p_payload[1] | nal->p_payload[2]) 
> == 0 && nal->p_payload[3] == 1);
> +av_assert0((nal->p_payload[4] & 0x1F) == 7);
> +// bits 0-7 LSB for profile. bits 8-11 for constrained set flags.

s/constrained/constraint/

> +if (avctx->profile == FF_PROFILE_UNKNOWN)
> +avctx->profile = ((uint32_t)nal->p_payload[5]) | 
> ((uint32_t)ff_reverse[nal->p_payload[6]] << 8);
> +if (avctx->level == FF_LEVEL_UNKNOWN)
> +avctx->level = nal->p_payload[7];
>  
> -s = x264_encoder_headers(x4->enc, &nal, &nnal);
> +if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
>  avctx->extradata = p = av_mallocz(s + AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!p)
>  return AVERROR(ENOMEM);
> 

This patch LGTM.  (No comment on the HLS patches, I'm not familiar with that 
code.)

Thanks,

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


Re: [FFmpeg-devel] [PATCH 10/24] avcodec/mjpegdec: replace YUVJ pixel formats

2017-12-14 Thread Paul B Mahol
On 12/14/17, wm4  wrote:
> On Wed, 13 Dec 2017 20:56:30 +0100 (CET)
> Marton Balint  wrote:
>
>> On Wed, 13 Dec 2017, Michael Niedermayer wrote:
>>
>> > On Wed, Dec 13, 2017 at 11:59:26AM +0100, Paul B Mahol wrote:
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavcodec/mjpegdec.c| 18 +-
>> >>  libavcodec/tdsc.c|  2 +-
>> >>  tests/fate/vcodec.mak|  4 ++--
>> >>  tests/ref/fate/api-mjpeg-codec-param |  4 ++--
>> >>  tests/ref/fate/exif-image-embedded   |  2 +-
>> >>  tests/ref/fate/exif-image-jpg|  2 +-
>> >>  6 files changed, 16 insertions(+), 16 deletions(-)
>> >
>> > this breaks ffplay playing a mjpeg in avi
>> >
>> > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec mjpeg -t 0.5  -qscale 1
>> > mjpeg.avi
>> > ./ffplay mjpeg.avi
>> >
>> > the output of ffplay looks darker than it should be
>>
>> FFplay does not specify the needed range for its buffersink. If there is a
>>
>> way to specify allowed combinations (e.g. YUV+limited, YUV+unspecified,
>> RGB+full, RGB+unspecified), then this probably can be fixed.
>>
>> (As far as I know SDL also does not specify the range of the used
>> pixel formats, but I think YUV is always limited range there, and
>> RGB is always full range)
>
> If a lavfi API user suddenly has to specify the range manually (instead
> just over AVFrame), then this is a compatibility issue too. (I'm
> talking about non-J pixfmts in both cases.) Poor Paul...

color range via api, either buffersink or buffersrc are optional and
not mandatory.

It is ffplay issue that it ignores color range, comming from AVFrame itself.
___
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

2017-12-14 Thread wm4
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 = &amediacodec_class;   
> > >\
> > > + 
> > >\
> > > +env = ff_jni_get_env(codec); 
> > >\
> > > +if (!env) {  
> > >\
> > > +av_freep(&codec);
> > >\
> > > +return NULL; 
> > >\
> > > +}
> > >\
> > > + 
> > >\
> > > +if (ff_jni_init_jfields(env, &codec->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,
> > >\
> > > +jarg);   
> > >\
> > > +if (ff_jni_exception_check(env, 1, codec) < 0) { 
> > >\
> > > +goto fail;   
> > >\
> > > +}
> > >\
> > > + 
> > >\
> > > +codec->object = (*env)->NewGlobalRef(env, object);   
> > >\
> > > +if (!codec->object) {
> > >\
> > > +goto fail;

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

2017-12-14 Thread Matthieu Bouron
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 = &amediacodec_class; 
> >  \
> > +   
> >  \
> > +env = ff_jni_get_env(codec);   
> >  \
> > +if (!env) {
> >  \
> > +av_freep(&codec);  
> >  \
> > +return NULL;   
> >  \
> > +}  
> >  \
> > +   
> >  \
> > +if (ff_jni_init_jfields(env, &codec->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,  
> >  \
> > +jarg); 
> >  \
> > +if (ff_jni_exception_check(env, 1, codec) < 0) {   
> >  \
> > +goto fail; 
> >  \
> > +}  
> >  \
> > +   
> >  \
> > +codec->object = (*env)->NewGlobalRef(env, object); 
> >  \
> > +if (!codec->object) {  
> >  \
> > +goto fail; 
> >  \
> > +}  
> >  \
> > +   
> > 

Re: [FFmpeg-devel] [PATCH v2 2/3] avcodec/libx264:setting profile and level in avcodec context

2017-12-14 Thread Dixit, Vishwanath


>On 11/24/17, 9:06 PM, "Jeyapal, Karthick"  wrote:
>
>Thanks for your comments. I have uploaded new patchset v4 with suggested 
>corrections.
>Please ignore patchset v3.
>
>On 11/24/17, 4:26 PM, "Mark Thompson"  wrote:
>[…]
>>> +s = x264_encoder_headers(x4->enc, &nal, &nnal);
>>> +avctx->profile = nal->p_payload[5];
>>
>>AVCodecContext.profile should include some of the constraint_set_flags - see 
>>.
>Great! I was not aware of this. This would also resolve my 
>constraint_set_flags problem in hlsenc.
>>
>>> +avctx->level = nal->p_payload[7];
>>
>>I don't much like the hard-coding of the offsets here.  Maybe add some 
>>asserts so that it fails very quickly if something ever changes?  (I don't 
>>think it will with libx264, but if it does then this is going to be putting 
>>nonsense in the metadata.)
>Have added asserts to check start code and nal type.
>>
>>>  
>>> -s = x264_encoder_headers(x4->enc, &nal, &nnal);
>>> +if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
>>>  avctx->extradata = p = av_mallocz(s + 
>>> AV_INPUT_BUFFER_PADDING_SIZE);
>>>  if (!p)
>>>  return AVERROR(ENOMEM);
>>> 
>>
>>I think I preferred the version which only wrote the value if it isn't 
>>already set.  If the user specifies a profile then it should use that or fail.
>I am ok with both approaches. Let us take a final decision on this based on 
>the result of the other patch submitted by carl.
>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220701.html
>
>regards,
>Karthick

I have submitted patch set version v6 https://patchwork.ffmpeg.org/patch/6771/ 
which writes profile and level only if it is not already set. Earlier Mark 
Thompson had objected to setting profile and level unconditionally, and Carl 
sent a patch in avcodec.h to change the API definition in order to set profile 
and level by encoders. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220701.html. But that 
patch has not been merged yet and that discussion has gone cold. In the 
interest of some resolution for this patchset, we propose that this patch(v6) 
which writes profile and level only if is not set, as the patch with least 
objections. In this way, the current API behavior is not changed. Could this 
patchset atleast be merged? It doesn’t make sense to hold off merging the 
entire feature, till the API definition is changed.

Regards,
Vishwanath

___
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

2017-12-14 Thread wm4
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 = &amediacodec_class;   
>\
> + 
>\
> +env = ff_jni_get_env(codec); 
>\
> +if (!env) {  
>\
> +av_freep(&codec);
>\
> +return NULL; 
>\
> +}
>\
> + 
>\
> +if (ff_jni_init_jfields(env, &codec->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,
>\
> +jarg);   
>\
> +if (ff_jni_exception_check(env, 1, codec) < 0) { 
>\
> +goto fail;   
>\
> +}
>\
> + 
>\
> +codec->object = (*env)->NewGlobalRef(env, object);   
>\
> +if (!codec->object) {
>\
> +goto fail;   
>\
> +}
>\
> + 
>\
> +if (codec_init_static_fields(codec) < 0) {   
>\
> +goto fail;   
>\
> +} 

Re: [FFmpeg-devel] [PATCH 10/24] avcodec/mjpegdec: replace YUVJ pixel formats

2017-12-14 Thread wm4
On Wed, 13 Dec 2017 20:56:30 +0100 (CET)
Marton Balint  wrote:

> On Wed, 13 Dec 2017, Michael Niedermayer wrote:
> 
> > On Wed, Dec 13, 2017 at 11:59:26AM +0100, Paul B Mahol wrote:  
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavcodec/mjpegdec.c| 18 +-
> >>  libavcodec/tdsc.c|  2 +-
> >>  tests/fate/vcodec.mak|  4 ++--
> >>  tests/ref/fate/api-mjpeg-codec-param |  4 ++--
> >>  tests/ref/fate/exif-image-embedded   |  2 +-
> >>  tests/ref/fate/exif-image-jpg|  2 +-
> >>  6 files changed, 16 insertions(+), 16 deletions(-)  
> >
> > this breaks ffplay playing a mjpeg in avi
> >
> > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec mjpeg -t 0.5  -qscale 1 mjpeg.avi
> > ./ffplay mjpeg.avi
> >
> > the output of ffplay looks darker than it should be  
> 
> FFplay does not specify the needed range for its buffersink. If there is a 
> way to specify allowed combinations (e.g. YUV+limited, YUV+unspecified, 
> RGB+full, RGB+unspecified), then this probably can be fixed.
> 
> (As far as I know SDL also does not specify the range of the used 
> pixel formats, but I think YUV is always limited range there, and 
> RGB is always full range)

If a lavfi API user suddenly has to specify the range manually (instead
just over AVFrame), then this is a compatibility issue too. (I'm
talking about non-J pixfmts in both cases.) Poor Paul...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2017-12-14 Thread vdixit
From: Vishwanath Dixit 

---
 libavformat/Makefile  |  2 +-
 libavformat/dashenc.c |  2 +-
 libavformat/hlsenc.c  | 65 +--
 libavformat/hlsplaylist.c |  5 +++-
 libavformat/hlsplaylist.h |  3 ++-
 libavformat/reverse.c |  1 +
 tests/ref/fate/source |  1 +
 7 files changed, 73 insertions(+), 6 deletions(-)
 create mode 100644 libavformat/reverse.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 734b703..b7e042d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -61,7 +61,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o 
  \
 rtpdec_vp9.o\
 rtpdec_xiph.o
 OBJS-$(CONFIG_RTPENC_CHAIN)  += rtpenc_chain.o rtp.o
-OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o
+OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o reverse.o
 OBJS-$(CONFIG_SRTP)  += srtp.o
 
 # muxers/demuxers
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f363418..016ada3 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -760,7 +760,7 @@ static int write_manifest(AVFormatContext *s, int final)
 AVStream *st = s->streams[i];
 get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
i);
 ff_hls_write_stream_info(st, out, st->codecpar->bit_rate,
-playlist_file, NULL);
+playlist_file, NULL, NULL);
 }
 avio_close(out);
 if (use_rename)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 273dd8a..ed64847 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,7 @@
 #include "libavutil/avstring.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/random_seed.h"
+#include "libavutil/reverse.h"
 #include "libavutil/opt.h"
 #include "libavutil/log.h"
 #include "libavutil/time_internal.h"
@@ -1078,6 +1079,63 @@ static int get_relative_url(const char *master_url, 
const char *media_url,
 return 0;
 }
 
+static char *get_codec_str(AVStream *vid_st, AVStream *aud_st) {
+size_t codec_str_size = 64;
+char *codec_str = av_malloc(codec_str_size);
+int video_str_len = 0;
+
+if (!codec_str)
+return NULL;
+
+if (!vid_st && !aud_st) {
+goto fail;
+}
+
+if (vid_st) {
+if (vid_st->codecpar->profile != FF_PROFILE_UNKNOWN &&
+vid_st->codecpar->level != FF_LEVEL_UNKNOWN &&
+vid_st->codecpar->codec_id == AV_CODEC_ID_H264) {
+snprintf(codec_str, codec_str_size, "avc1.%02x%02x%02x",
+ vid_st->codecpar->profile & 0xFF,
+ ff_reverse[(vid_st->codecpar->profile >> 8) & 0xFF],
+ vid_st->codecpar->level);
+} else {
+goto fail;
+}
+video_str_len = strlen(codec_str);
+}
+
+if (aud_st) {
+char *audio_str = codec_str;
+if (video_str_len) {
+codec_str[video_str_len] = ',';
+video_str_len += 1;
+audio_str += video_str_len;
+codec_str_size -= video_str_len;
+}
+if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP2) {
+snprintf(audio_str, codec_str_size, "mp4a.40.33");
+} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP3) {
+snprintf(audio_str, codec_str_size, "mp4a.40.34");
+} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AAC) {
+/* TODO : For HE-AAC, HE-AACv2, the last digit needs to be set to 
5 and 29 respectively */
+snprintf(audio_str, codec_str_size, "mp4a.40.2");
+} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AC3) {
+snprintf(audio_str, codec_str_size, "mp4a.A5");
+} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_EAC3) {
+snprintf(audio_str, codec_str_size, "mp4a.A6");
+} else {
+goto fail;
+}
+}
+
+return codec_str;
+
+fail:
+av_free(codec_str);
+return NULL;
+}
+
 static int create_master_playlist(AVFormatContext *s,
   VariantStream * const input_vs)
 {
@@ -1088,7 +1146,7 @@ static int create_master_playlist(AVFormatContext *s,
 AVDictionary *options = NULL;
 unsigned int i, j;
 int m3u8_name_size, ret, bandwidth;
-char *m3u8_rel_name;
+char *m3u8_rel_name, *codec_str;
 
 input_vs->m3u8_created = 1;
 if (!hls->master_m3u8_created) {
@@ -1202,9 +1260,12 @@ static int create_master_playlist(AVFormatContext *s,
 bandwidth += aud_st->codecpar->bit_rate;
 bandwidth += bandwidth / 10;
 
+codec_str = get_codec_str(vid_st, aud_st);
+
 ff_hls_write_stream_info(vid_st, master_pb, bandwidth, m3u8_rel_name,
-aud_st ? vs->agroup : NULL);
+codec_str, aud_st ? vs->agroup : N

[FFmpeg-devel] [PATCH v6 2/3] avcodec/libx264:setting profile and level in avcodec context

2017-12-14 Thread vdixit
From: Vishwanath Dixit 

---
 libavcodec/libx264.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9c67c91..ac1f8bb 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -19,11 +19,13 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/eval.h"
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/reverse.h"
 #include "libavutil/stereo3d.h"
 #include "libavutil/intreadwrite.h"
 #include "avcodec.h"
@@ -454,6 +456,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
 X264Context *x4 = avctx->priv_data;
 AVCPBProperties *cpb_props;
 int sw,sh;
+x264_nal_t *nal;
+uint8_t *p;
+int nnal, s, i;
 
 if (avctx->global_quality > 0)
 av_log(avctx, AV_LOG_WARNING, "-qscale is ignored, -crf is 
recommended.\n");
@@ -799,12 +804,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!x4->enc)
 return AVERROR_EXTERNAL;
 
-if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
-x264_nal_t *nal;
-uint8_t *p;
-int nnal, s, i;
+s = x264_encoder_headers(x4->enc, &nal, &nnal);
+// Assert for NAL start code and SPS unit type
+av_assert0((nal->p_payload[0] | nal->p_payload[1] | nal->p_payload[2]) == 
0 && nal->p_payload[3] == 1);
+av_assert0((nal->p_payload[4] & 0x1F) == 7);
+// bits 0-7 LSB for profile. bits 8-11 for constrained set flags.
+if (avctx->profile == FF_PROFILE_UNKNOWN)
+avctx->profile = ((uint32_t)nal->p_payload[5]) | 
((uint32_t)ff_reverse[nal->p_payload[6]] << 8);
+if (avctx->level == FF_LEVEL_UNKNOWN)
+avctx->level = nal->p_payload[7];
 
-s = x264_encoder_headers(x4->enc, &nal, &nnal);
+if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
 avctx->extradata = p = av_mallocz(s + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!p)
 return AVERROR(ENOMEM);
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v6 1/3] avformat/hlsenc:addition of #EXT-X-MEDIA tag and AUDIO attribute

2017-12-14 Thread vdixit
From: Vishwanath Dixit 

---
 doc/muxers.texi   | 12 +
 libavformat/dashenc.c |  3 ++-
 libavformat/hlsenc.c  | 62 ---
 libavformat/hlsplaylist.c |  4 ++-
 libavformat/hlsplaylist.h |  2 +-
 5 files changed, 77 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 3d0c7bf..93db549 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -834,6 +834,18 @@ be a video only stream with video bitrate 1000k, the 
second variant stream will
 be an audio only stream with bitrate 64k and the third variant stream will be a
 video only stream with bitrate 256k. Here, three media playlist with file names
 out_1.m3u8, out_2.m3u8 and out_3.m3u8 will be created.
+@example
+ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k -b:v:1 3000k  \
+  -map 0:a -map 0:a -map 0:v -map 0:v -f hls \
+  -var_stream_map "a:0,agroup:aud_low a:1,agroup:aud_high v:0,agroup:aud_low 
v:1,agroup:aud_high" \
+  -master_pl_name master.m3u8 \
+  http://example.com/live/out.m3u8
+@end example
+This example creates two audio only and two video only variant streams. In
+addition to the #EXT-X-STREAM-INF tag for each variant stream in the master
+playlist, #EXT-X-MEDIA tag is also added for the two audio only variant streams
+and they are mapped to the two video only variant streams with audio group 
names
+'aud_low' and 'aud_high'.
 
 By default, a single hls variant containing all the encoded streams is created.
 
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5687530..f363418 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -759,7 +759,8 @@ static int write_manifest(AVFormatContext *s, int final)
 char playlist_file[64];
 AVStream *st = s->streams[i];
 get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
i);
-ff_hls_write_stream_info(st, out, st->codecpar->bit_rate, 
playlist_file);
+ff_hls_write_stream_info(st, out, st->codecpar->bit_rate,
+playlist_file, NULL);
 }
 avio_close(out);
 if (use_rename)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index fdf614b..273dd8a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -144,6 +144,7 @@ typedef struct VariantStream {
 AVStream **streams;
 unsigned int nb_streams;
 int m3u8_created; /* status of media play-list creation */
+char *agroup; /* audio group name */
 char *baseurl;
 } VariantStream;
 
@@ -1081,7 +1082,7 @@ static int create_master_playlist(AVFormatContext *s,
   VariantStream * const input_vs)
 {
 HLSContext *hls = s->priv_data;
-VariantStream *vs;
+VariantStream *vs, *temp_vs;
 AVStream *vid_st, *aud_st;
 AVIOContext *master_pb = 0;
 AVDictionary *options = NULL;
@@ -1115,6 +1116,34 @@ static int create_master_playlist(AVFormatContext *s,
 
 ff_hls_write_playlist_version(master_pb, hls->version);
 
+/* For audio only variant streams add #EXT-X-MEDIA tag with attributes*/
+for (i = 0; i < hls->nb_varstreams; i++) {
+vs = &(hls->var_streams[i]);
+
+if (vs->has_video || vs->has_subtitle || !vs->agroup)
+continue;
+
+m3u8_name_size = strlen(vs->m3u8_name) + 1;
+m3u8_rel_name = av_malloc(m3u8_name_size);
+if (!m3u8_rel_name) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+av_strlcpy(m3u8_rel_name, vs->m3u8_name, m3u8_name_size);
+ret = get_relative_url(hls->master_m3u8_url, vs->m3u8_name,
+   m3u8_rel_name, m3u8_name_size);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Unable to find relative URL\n");
+goto fail;
+}
+
+avio_printf(master_pb, "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=\"group_%s\"",
+vs->agroup);
+avio_printf(master_pb, ",NAME=\"audio_0\",DEFAULT=YES,URI=\"%s\"\n",
+m3u8_rel_name);
+av_freep(&m3u8_rel_name);
+}
+
 /* For variant streams with video add #EXT-X-STREAM-INF tag with 
attributes*/
 for (i = 0; i < hls->nb_varstreams; i++) {
 vs = &(hls->var_streams[i]);
@@ -1147,6 +1176,25 @@ static int create_master_playlist(AVFormatContext *s,
 continue;
 }
 
+/**
+ * Traverse through the list of audio only rendition streams and find
+ * the rendition which has highest bitrate in the same audio group
+ */
+if (vs->agroup) {
+for (j = 0; j < hls->nb_varstreams; j++) {
+temp_vs = &(hls->var_streams[j]);
+if (!temp_vs->has_video && !temp_vs->has_subtitle &&
+temp_vs->agroup &&
+!strcmp(temp_vs->agroup, vs->agroup)) {
+if (!aud_st)
+aud_st = temp_vs->streams[0];
+if (temp_vs->streams[0]->codecpar->bit_r

Re: [FFmpeg-devel] Correction to Webpage

2017-12-14 Thread Carl Eugen Hoyos
2017-12-14 11:12 GMT+01:00 Yogender Gupta :
> I would like to correct a couple of lines on the following ffmpeg web page.

> https://trac.ffmpeg.org/wiki/HWAccelIntro

A wiki is a wiki.

> Can anyone please guide me on how to do it (push patch or raise
> ticket or edit page)

If you really need guidance to edit a wiki, I fear you are wrong here.

> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.

Please remove this from emails sent to a public mailing list.

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


Re: [FFmpeg-devel] avfilter/x86/vf_blend : add avx2 version for 8b func (WIP)

2017-12-14 Thread Martin Vignali
2017-12-13 17:37 GMT+01:00 Henrik Gramner :

> On Sat, Dec 9, 2017 at 1:11 PM, Martin Vignali 
> wrote:
> > the idea in AVX2 is to load 128bits of data (2x 64 bits)
> > then shuffle accross lane, the two 64 bits in the low part of each lane,
> to
> > keep the rest of the process similar
> > to the sse version
>
> What about using pmovzxbw instead of movu + vpermq + punpcklbw?
>

You're right, this is faster (tested on the first one with intermediate
16bits processing (grainextract)

vpermq load

grainextract_c: 22162.2
grainextract_sse2: 1160.9
grainextract_avx2: 1154.2


vpmovzxbw

grainextract_c: 22165.7
grainextract_sse2: 1155.7
grainextract_avx2: 772.9


>
> > for the store, the idea is similar in the opposite way (shuffle before
> > store)
>
> You could also do vextracti128 + 128-bit packuswb instead of 256-bit
> packuswb + vpermq.
>
>
Sorry don't understand this part
do you mean 128 bit packuswb + movh for each lane ?
or something else ?

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


Re: [FFmpeg-devel] [PATCH] Added Turing codec to ffmpeg

2017-12-14 Thread Matteo Naccari
> > I still have an issue with this patch, while it would be nice to have 
> > another
> HEVC encoder available in FFmpeg for comparisons and whatnot, I feel that
> turingcodec isn't a mature enough encoder compared to what is already in
> the project.
> >
> > Not to mention that development seems to have stalled (with only very
> minor fixes for several months). In FFmpeg it is very difficult to remove
> 'features', so if this patch were to be merged and then turingcodec to
> actually go stale we'd be left with dead code for longer than is ideal 
> (forever).
> >
> > My opinion is that you should just maintain this separately as an out-of-
> tree patch as it doesn't benefit us.
> >
> 
> Hi,
> 
> After taking a look at the commit history of the last year+ or so, issue 
> tracker
> and pull request list over at https://github.com/bbc/turingcodec I must say I
> find it somewhat hard to disagree on a general level.
> 
> Creating an encoder is great work and I applaud people for that, but
> unfortunately it - at the current point of time - looks like neither from the
> licensing, performance or project activity point of view merging a wrapper for
> this library is a good idea.

If stability of the project was your concern, you should have told us from the 
very beginning and save everyone's time. The project and its development is 
still active. We pushed additional fixes in November and we plan to add new 
features in the near future. We acknowledge that there is still a lot to do to 
get the encoder to the same level of maturity of  others both from the 
performance and the licensing/collaboration point of view. At the same time, we 
also trust you appreciate that being a small team of researchers (3) working 
part time on this project we are slow in replying to requests and progressing 
with the development. Indeed we thought having the codec interfaced to FFmpeg 
would have been a good opportunity to share our work and know-how on content 
distribution for broadcasting applications using HEVC and provide an 
alternative codec to ffmpeg. Clearly we were wrong.
We'll distribute the patch onto our website for those who are interested in 
having Turing in FFmpeg and stop pestering you with new requests.

---
Matteo Naccari, Ph.D.
Senior Technologist, BBC R&D
Block D, Centre House
56 Wood lane, W12 7SB, London (UK)
Phone: +44 (0)303 0409640
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2017-12-14 Thread Matthieu Bouron
---
 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, &codec->jfields, jni_amediacodec_mapping, 1, 
codec);  \
 av_freep(&codec);  
 \
 }  
 \
-- 
2.15.1

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


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

2017-12-14 Thread Matthieu Bouron
---
 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:
 return ret;
 }
 
-FFAMediaCodec* ff_AMediaCodec_createCodecByName(const char *name)
-{
-int ret = -1;
-JNIEnv *env = NULL;
-FFAMediaCodec *codec = NULL;
-jstring codec_name = NULL;
-jobject object = NULL;
-
-codec = av_mallocz(sizeof(FFAMediaCodec));
-if (!codec) {
-return NULL;
-}
-codec->class = &amediacodec_class;
-
-env = ff_jni_get_env(codec);
-if (!env) {
-av_freep(&codec);
-return NULL;
-}
-
-if (ff_jni_init_jfields(env, &codec->jfields, jni_amediacodec_mapping, 1, 
codec) < 0) {
-goto fail;
-}
-
-codec_name = ff_jni_utf_chars_to_jstring(env, name, codec);
-if (!codec_name) {
-goto fail;
-}
-
-object = (*env)->CallStaticObjectMethod(env, 
codec->jfields.mediacodec_class, codec->jfields.create_by_codec_name_id, 
codec_name);
-if (ff_jni_exception_check(env, 1, codec) < 0) {
-goto fail;
-}
-
-codec->object = (*env)->NewGlobalRef(env, object);
-if (!codec->object) {
-goto fail;
-}
-
-if (codec_init_static_fields(codec) < 0) {
-goto fail;
-}
-
-if (codec->jfields.get_input_buffer_id && 
codec->jfields.get_output_buffer_id) {
-codec->has_get_i_o_buffer = 1;
-}
-
-ret = 0;
-fail:
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-}
-
-if (object) {
-(*env)->DeleteLocalRef(env, object);
-}
-
-if (ret < 0) {
-ff_jni_reset_jfields(env, &codec->jfields, jni_amediacodec_mapping, 1, 
codec);
-av_freep(&codec);
-}
-
-return codec;
+#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 = &amediacodec_class; 
 \
+   
 \
+env = ff_jni_get_env(codec);   
 \
+if (!env) {
 \
+av_freep(&codec);  
 \
+return NULL;   
 \
+}  
 \
+   
 \
+if (ff_jni_init_jfields(env, &codec->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->jfiel

[FFmpeg-devel] Correction to Webpage

2017-12-14 Thread Yogender Gupta
I would like to correct a couple of lines on the following ffmpeg web page. Can 
anyone please guide me on how to do it (push patch or raise ticket or edit page)

It is definitely possible to do a complete end to end 10-bit transcode on the 
GPU pipeline without passing to system memory. I had submitted patches and 
verified this to work as well.

https://trac.ffmpeg.org/wiki/HWAccelIntro

While decoding 10 bit video is supported, it is not possible to do full 
hardware transcoding currently (see the partial hardware example below).

Partial hardware transcode, with frames passed through system memory (This is 
necessary for transcoding 10bit content):

Thanks,
Yogender


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


Re: [FFmpeg-devel] avfilter/x86/vf_hflip : make macro and add AVX2

2017-12-14 Thread Martin Vignali
2017-12-13 17:18 GMT+01:00 Henrik Gramner :

> On Wed, Dec 13, 2017 at 6:07 AM, Martin Vignali
>  wrote:
> > +vpermq  m1, [srcq + xq - mmsize + %3], 0x4e; flip each lane
> at load
> > +vpermq  m2, [srcq + xq - 2 * mmsize + %3], 0x4e; flip each lane
> at load
>
> Would doing 2x 128-bit movu + 2x vinserti128 be faster?
>
>
> Hello,

Seems to be slower for me (patch in attach, maybe i made something wrong)

With vpermq :
hflip_byte_c: 29.2
hflip_byte_ssse3: 28.4
hflip_byte_avx2: 20.2
hflip_short_c: 29.2
hflip_short_ssse3: 28.4
hflip_short_avx2: 20.2

With movu + vinserti128 :
hflip_byte_c: 29.2
hflip_byte_ssse3: 28.2
hflip_byte_avx2: 22.7
hflip_short_c: 29.7
hflip_short_ssse3: 28.2
hflip_short_avx2: 21.7

Martin


0001-avfilter-x86-vf_hflip-merge-hflip-byte-and-hflip-sho.patch
Description: Binary data


0002-avfilter-x86-vf_hflip-add-avx2-version-for-hflip_byt.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH V2] lavc/qsvenc: ICQ/VCM/QVBR are only avilable on Windows

2017-12-14 Thread Zhong Li
Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 5cfd174..fae98e1 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -44,9 +44,16 @@
 #define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
 #define QSV_HAVE_LA_DS  QSV_VERSION_ATLEAST(1, 8)
 #define QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
+
+#if defined(_WIN32)
 #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 8)
 #define QSV_HAVE_VCMQSV_VERSION_ATLEAST(1, 8)
 #define QSV_HAVE_QVBR   QSV_VERSION_ATLEAST(1, 11)
+#else
+#define QSV_HAVE_ICQ0
+#define QSV_HAVE_VCM0
+#define QSV_HAVE_QVBR   0
+#endif
 
 #define QSV_COMMON_OPTS \
 { "async_depth", "Maximum processing parallelism", OFFSET(qsv.async_depth), 
AV_OPT_TYPE_INT, { .i64 = ASYNC_DEPTH_DEFAULT }, 0, INT_MAX, VE },  
\
-- 
1.8.3.1

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


Re: [FFmpeg-devel] [PATCH] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread Steven Liu
2017-12-14 16:00 GMT+08:00  :
> From: wu zhiqiang 
>
> When using concat protocal, start from middle of file will generate non-zero 
> wrap reference. If seek to time less than the wrap reference, wrap control 
> will be triggered and generate wrong wrapped timestamp.
> Copy wrap related stream properties when reading header can fix this problem.
>
> Signed-off-by: wu zhiqiang 
> ---
>  libavformat/concatdec.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 0e189012ad..e933888661 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st, AVStream 
> *source_st)
>  st->time_base   = source_st->time_base;
>  st->sample_aspect_ratio = source_st->sample_aspect_ratio;
>
> +/* Fix wrap control problem */
> +st->pts_wrap_bits   = source_st->pts_wrap_bits;
> +st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
> +st->pts_wrap_reference  = source_st->pts_wrap_reference;
> +
>  av_dict_copy(&st->metadata, source_st->metadata, 0);
>  return 0;
>  }
> --
> 2.15.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM


Thanks

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

2017-12-14 Thread 刘歧

> 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, &options, hls);
>> 
>> 
>> - ret = s->io_open(s, &master_pb, hls->master_m3u8_url, AVIO_FLAG_WRITE,\
>> - &options);
>> + ret = hlsenc_io_open(s, &hls->m3u8_out, hls->master_m3u8_url, &options);
>> av_dict_free(&options);
>> 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(&m3u8_rel_name);
>> }
>> @@ -1160,7 +1160,7 @@ fail:
>> if(ret >=0)
>> hls->master_m3u8_created = 1;
>> av_freep(&m3u8_rel_name);
>> - ff_format_io_close(s, &master_pb);
>> + hlsenc_io_close(s, &hls->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, &options, hls);
>> snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : "%s", 
>> vs->m3u8_name);
>> - if ((ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, &options)) 
>> < 0)
>> + if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 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->segm

[FFmpeg-devel] [PATCH] avformat/concat: Fix wrong wrapped timestamp

2017-12-14 Thread mymoeyard
From: wu zhiqiang 

When using concat protocal, start from middle of file will generate non-zero 
wrap reference. If seek to time less than the wrap reference, wrap control will 
be triggered and generate wrong wrapped timestamp.
Copy wrap related stream properties when reading header can fix this problem.

Signed-off-by: wu zhiqiang 
---
 libavformat/concatdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 0e189012ad..e933888661 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -188,6 +188,11 @@ static int copy_stream_props(AVStream *st, AVStream 
*source_st)
 st->time_base   = source_st->time_base;
 st->sample_aspect_ratio = source_st->sample_aspect_ratio;
 
+/* Fix wrap control problem */
+st->pts_wrap_bits   = source_st->pts_wrap_bits;
+st->pts_wrap_behavior   = source_st->pts_wrap_behavior;
+st->pts_wrap_reference  = source_st->pts_wrap_reference;
+
 av_dict_copy(&st->metadata, source_st->metadata, 0);
 return 0;
 }
-- 
2.15.0

___
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

2017-12-14 Thread Karthick Jeyapal


> 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, &options, hls);
> 
> 
> - ret = s->io_open(s, &master_pb, hls->master_m3u8_url, AVIO_FLAG_WRITE,\
> - &options);
> + ret = hlsenc_io_open(s, &hls->m3u8_out, hls->master_m3u8_url, &options);
> av_dict_free(&options);
> 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(&m3u8_rel_name);
> }
> @@ -1160,7 +1160,7 @@ fail:
> if(ret >=0)
> hls->master_m3u8_created = 1;
> av_freep(&m3u8_rel_name);
> - ff_format_io_close(s, &master_pb);
> + hlsenc_io_close(s, &hls->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, &options, hls);
> snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : "%s", 
> vs->m3u8_name);
> - if ((ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, &options)) < 
> 0)
> + if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 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_w