Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

2017-11-21 Thread Jeyapal, Karthick
>On 11/22/17, 9:32 AM, "刘歧"  wrote:
>
>This patch is ok, but i see it need an API: ffio_geturlcontext
>
>it in the other patch, i see it have some thing need talk? If that is ok, this 
>patch should be apply.
Thanks for the reply. 
All concerns raised by Nicolas has been addressed in this latest patch set.
Let us wait for few days to check if anyone still has any objections.
>
>Thanks

regards,
Karthick

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


[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Option to generate hls playlist as well

2017-11-21 Thread Karthick J
This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/dashenc.c | 101 --
 2 files changed, 100 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 0bb8ad2..1cf2481 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso;
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. Applicable only for HTTP output.
+@item -hls_playlist @var{hls_playlist}
+Generate HLS playlist files as well. The master playlist is generated with the 
filename master.m3u8.
+One media playlist file is generated for each stream with filenames 
media_0.m3u8, media_1.m3u8, etc.
 @item -adaptation_sets @var{adaptation_sets}
 Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c 
id=y,streams=d,e" with x and y being the IDs
 of the adaptation sets and a,b,c,d and e are the indices of the mapped streams.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 201668a..1fa9d82 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsenc.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,13 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, const char *base_url, 
int id) {
+if (base_url)
+sprintf(playlist_name, "%smedia_%d.m3u8", base_url, id);
+else
+sprintf(playlist_name, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +272,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(>streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +333,53 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(_opts, c);
+avio_open2(_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
_opts);
+av_dict_free(_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+if (target_duration < seg->duration)
+target_duration = seg->duration;
+}
+target_duration = lrint((double) target_duration / timescale);
+
+hls_write_playlist_header (out_hls, 6, -1,
+target_duration, start_number, PLAYLIST_TYPE_NONE);
+
+hls_write_init_file(out_hls, os->initfile, c->single_file,
+os->init_range_length, os->init_start_pos);
+
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+hls_write_file_entry(out_hls, 0, c->single_file, 0,
+ (double) seg->duration / timescale,
+ seg->range_length, seg->start_pos, NULL,
+ c->single_file ? os->initfile : seg->file, 
NULL);
+}
+
+if (final)
+hls_write_end_list(out_hls);
+
+avio_close(out_hls);
+if (use_rename)
+avpriv_io_move(temp_filename_hls, filename_hls);
+}
+
 }
 
 static char *xmlescape(const char *str) {
@@ -391,7 +449,8 @@ static void format_date_now(char *buf, int size)
 }
 }
 
-static int write_adaptation_set(AVFormatContext 

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

2017-11-21 Thread Karthick J
---
 libavformat/hlsenc.c | 130 +++---
 libavformat/hlsenc.h | 158 +++
 2 files changed, 177 insertions(+), 111 deletions(-)
 create mode 100644 libavformat/hlsenc.h

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3c47ced..4e017eb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -45,6 +45,7 @@
 
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsenc.h"
 #include "internal.h"
 #include "os_support.h"
 
@@ -73,35 +74,11 @@ typedef struct HLSSegment {
 struct HLSSegment *next;
 } HLSSegment;
 
-typedef enum HLSFlags {
-// Generate a single media file and use byte ranges in the playlist.
-HLS_SINGLE_FILE = (1 << 0),
-HLS_DELETE_SEGMENTS = (1 << 1),
-HLS_ROUND_DURATIONS = (1 << 2),
-HLS_DISCONT_START = (1 << 3),
-HLS_OMIT_ENDLIST = (1 << 4),
-HLS_SPLIT_BY_TIME = (1 << 5),
-HLS_APPEND_LIST = (1 << 6),
-HLS_PROGRAM_DATE_TIME = (1 << 7),
-HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in 
segment filenames when use_localtime  e.g.: %%03d
-HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
-HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
-HLS_TEMP_FILE = (1 << 11),
-HLS_PERIODIC_REKEY = (1 << 12),
-} HLSFlags;
-
 typedef enum {
 SEGMENT_TYPE_MPEGTS,
 SEGMENT_TYPE_FMP4,
 } SegmentType;
 
-typedef enum {
-PLAYLIST_TYPE_NONE,
-PLAYLIST_TYPE_EVENT,
-PLAYLIST_TYPE_VOD,
-PLAYLIST_TYPE_NB,
-} PlaylistType;
-
 typedef struct VariantStream {
 unsigned number;
 int64_t sequence;
@@ -1022,19 +999,6 @@ static void hls_free_segments(HLSSegment *p)
 }
 }
 
-static void write_m3u8_head_block(HLSContext *hls, AVIOContext *out, int 
version,
-  int target_duration, int64_t sequence)
-{
-avio_printf(out, "#EXTM3U\n");
-avio_printf(out, "#EXT-X-VERSION:%d\n", version);
-if (hls->allowcache == 0 || hls->allowcache == 1) {
-avio_printf(out, "#EXT-X-ALLOW-CACHE:%s\n", hls->allowcache == 0 ? 
"NO" : "YES");
-}
-avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
-avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
-av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
-}
-
 static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
 {
 size_t len = strlen(oc->filename);
@@ -1101,8 +1065,7 @@ static int create_master_playlist(AVFormatContext *s,
 goto fail;
 }
 
-avio_printf(master_pb, "#EXTM3U\n");
-avio_printf(master_pb, "#EXT-X-VERSION:%d\n", hls->version);
+hls_write_playlist_version(master_pb, hls->version);
 
 /* For variant streams with video add #EXT-X-STREAM-INF tag with 
attributes*/
 for (i = 0; i < hls->nb_varstreams; i++) {
@@ -1143,18 +1106,7 @@ static int create_master_playlist(AVFormatContext *s,
 bandwidth += aud_st->codecpar->bit_rate;
 bandwidth += bandwidth / 10;
 
-if (!bandwidth) {
-av_log(NULL, AV_LOG_WARNING,
-"Bandwidth info not available, set audio and video 
bitrates\n");
-av_freep(_rel_name);
-continue;
-}
-
-avio_printf(master_pb, "#EXT-X-STREAM-INF:BANDWIDTH=%d", bandwidth);
-if (vid_st && vid_st->codecpar->width > 0 && vid_st->codecpar->height 
> 0)
-avio_printf(master_pb, ",RESOLUTION=%dx%d", 
vid_st->codecpar->width,
-vid_st->codecpar->height);
-avio_printf(master_pb, "\n%s\n\n", m3U8_rel_name);
+hls_write_stream_info(vid_st, master_pb, bandwidth, m3U8_rel_name);
 
 av_freep(_rel_name);
 }
@@ -1209,12 +1161,8 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 }
 
 vs->discontinuity_set = 0;
-write_m3u8_head_block(hls, out, hls->version, target_duration, sequence);
-if (hls->pl_type == PLAYLIST_TYPE_EVENT) {
-avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
-} else if (hls->pl_type == PLAYLIST_TYPE_VOD) {
-avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
-}
+hls_write_playlist_header(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");
@@ -1231,74 +1179,34 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 iv_string = en->iv_string;
 }
 
-if (en->discont) {
-avio_printf(out, "#EXT-X-DISCONTINUITY\n");
-}
-
 if ((hls->segment_type == SEGMENT_TYPE_FMP4) && (en == vs->segments)) {
-avio_printf(out, 

[FFmpeg-devel] Common Media Application Format

2017-11-21 Thread Karthick J
[PATCH 1/2] avformat/hlsenc: Modularized playlist creation to allow
[PATCH 2/2] avformat/dashenc: Option to generate hls playlist as well

One of the biggest applications of MPEG Common Media Application Format, is to 
have common media file/segments, that could be used by both HLS and DASH 
players.
To achieve this possibility in ffmpeg we need to have a muxer plugin that 
generates both DASH manifest and HLS playlist files. 
Two simple options that we have are
1. Modify the dashenc plugin to generate the HLS playlist files
2. Modify the hlsenc plugin to generate DASH manifest files

Both options are equally good. I have chosen option 1, just for the sake 
easiness to implement the same. 

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


Re: [FFmpeg-devel] [PATCH 3/3] avformat/opensrt: add Haivision Open SRT protocol

2017-11-21 Thread nablet developer


> On 20 Nov 2017, at 13:35, nablet developer  wrote:
> 
> 
>> 
>> Thanks for explaining. I think it is not the best decision.
>> 
>> The reason the socket API resembles TCP is because all the sockets API
>> resemble each other, since they are based on the old BSD socket API. And
>> the protocol handlers of libavformat too.
>> 
>> Therefore, I think all the trampoline code to allow TCP to call back
>> another protocol plus all the boilerplate code that you need to make
>> opensrc callable from TCP amounts to worse than implementing a protocol
>> directly.
>> 
>> Furthermore, TCP is the most important network protocol for now, while
>> opensrt is still rather obscure, so tying one with the other is not a
>> good idea.
>> 
>> Also, implementing a real protocol from scratch would possibly allow you
>> to make use of extra features of the opensrt API: maybe they have a
>> read-with-timeout function, for example, or something like that.
>> 
>> 
> 
> thanks for the feedback.
> regarding relying on TCP protocol code it's clear - I will implement protocol 
> from scratch next time.
> regarding re-using functions from network.c (like ff_network_wait_fd, 
> ff_accept, etc)
> is suggested approach acceptable? is it okay to define such socket_api 
> structure and pass to
> network.c calls?
> 

ping

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


Re: [FFmpeg-devel] [PATCH 03/15] hwcontext_opencl: VAAPI to OpenCL mapping for Intel i965+beignet

2017-11-21 Thread Jun Zhao


On 2017/11/15 3:47, Mark Thompson wrote:
> Supports all surface formats in common between the two.
> ---
>  configure|   6 +
>  libavutil/hwcontext_opencl.c | 298 
> +++
>  2 files changed, 304 insertions(+)
>
> diff --git a/configure b/configure
> index 167db274f1..dcdb5fee1f 100755
> --- a/configure
> +++ b/configure
> @@ -2121,6 +2121,7 @@ HAVE_LIST="
>  $TYPES_LIST
>  makeinfo
>  makeinfo_html
> +opencl_vaapi_beignet
>  perl
>  pod2man
>  texi2html
> @@ -6150,6 +6151,11 @@ enabled vaapi &&
>  check_cpp_condition "va/va.h" "VA_CHECK_VERSION(1, 0, 0)" &&
>  enable vaapi_1
>  
> +if enabled_all opencl vaapi ; then
> +check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> +enable opencl_vaapi_beignet
> +fi
> +
>  enabled vdpau &&
>  check_cpp_condition vdpau/vdpau.h "defined 
> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
>  disable vdpau
> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> index 0fe25d9500..7f99f5af3f 100644
> --- a/libavutil/hwcontext_opencl.c
> +++ b/libavutil/hwcontext_opencl.c
> @@ -29,6 +29,14 @@
>  #include "mem.h"
>  #include "pixdesc.h"
>  
> +#if HAVE_OPENCL_VAAPI_BEIGNET
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "hwcontext_vaapi.h"
> +#endif
> +
>  
>  typedef struct OpenCLDeviceContext {
>  // Default command queue to use for transfer/mapping operations on
> @@ -41,6 +49,10 @@ typedef struct OpenCLDeviceContext {
>  cl_platform_id platform_id;
>  
>  // Platform/device-specific functions.
> +#if HAVE_OPENCL_VAAPI_BEIGNET
> +int vaapi_mapping_usable;
> +clCreateImageFromFdINTEL_fn  clCreateImageFromFdINTEL;
> +#endif
>  } OpenCLDeviceContext;
>  
>  typedef struct OpenCLFramesContext {
> @@ -589,6 +601,40 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
>  return AVERROR(EIO);
>  }
>  
> +#define CL_FUNC(name, desc) do {\
> +if (fail)   \
> +break;  \
> +priv->name = clGetExtensionFunctionAddressForPlatform(  \
> +priv->platform_id, #name);  \
> +if (!priv->name) {  \
> +av_log(hwdev, AV_LOG_VERBOSE,   \
> +   desc " function not found (%s).\n", #name);  \
> +fail = 1;   \
> +} else {\
> +av_log(hwdev, AV_LOG_VERBOSE,   \
> +   desc " function found (%s).\n", #name);  \
> +}   \
> +} while (0)
> +
> +#if HAVE_OPENCL_VAAPI_BEIGNET
> +{
> +int fail = 0;
> +
> +CL_FUNC(clCreateImageFromFdINTEL,
> +"Intel DRM to OpenCL image mapping");
> +
> +if (fail) {
> +av_log(hwdev, AV_LOG_WARNING, "VAAPI to OpenCL mapping "
> +   "not usable.\n");
> +priv->vaapi_mapping_usable = 0;
> +} else {
> +priv->vaapi_mapping_usable = 1;
> +}
> +}
> +#endif
> +
> +#undef CL_FUNC
> +
>  return 0;
>  }
>  
> @@ -606,6 +652,52 @@ static void opencl_device_uninit(AVHWDeviceContext 
> *hwdev)
>  }
>  }
>  
> +static int opencl_device_derive(AVHWDeviceContext *hwdev,
> +AVHWDeviceContext *src_ctx,
> +int flags)
> +{
> +int err;
> +switch (src_ctx->type) {
> +
> +#if HAVE_OPENCL_VAAPI_BEIGNET
> +case AV_HWDEVICE_TYPE_VAAPI:
> +{
> +// Surface mapping works via DRM PRIME fds with no special
> +// initialisation required in advance.  This just finds the
> +// Beignet ICD by name.
> +AVDictionary *opts = NULL;
> +
> +err = av_dict_set(, "platform_vendor", "Intel", 0);
> +if (err >= 0)
> +err = av_dict_set(, "platform_version", "beignet", 0);
> +if (err >= 0) {
> +OpenCLDeviceSelector selector = {
> +.platform_index  = -1,
> +.device_index= 0,
> +.context = opts,
> +.enumerate_platforms = _enumerate_platforms,
> +.filter_platform = _filter_platform,
> +.enumerate_devices   = _enumerate_devices,
> +.filter_device   = NULL,
> +};
> +err = opencl_device_create_internal(hwdev, , NULL);
> +}
> +av_dict_free();
> +}
> +break;
> +#endif
> +
> +default:
> +err = AVERROR(ENOSYS);
> +break;
> +}
> +
> +if (err < 0)
> +return err;
> +
> 

Re: [FFmpeg-devel] [PATCH 08/13] ffmpeg: Use codec hardware config to configure hwaccels

2017-11-21 Thread Philip Langdale
On Sat, 18 Nov 2017 18:47:08 +
Mark Thompson  wrote:

> Removes specific support for all hwaccels supported by the generic
> code (DXVA2, D3D11VA, NVDEC, VAAPI, VDPAU and videotoolbox).
> ---
>  fftools/ffmpeg.c |  77 +++-
>  fftools/ffmpeg.h |  10 +--
>  fftools/ffmpeg_hw.c  | 244
> +++
> fftools/ffmpeg_opt.c |  55 ++-- 4 files changed, 250
> insertions(+), 136 deletions(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index babd85f7bc..acff815e74 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2782,45 +2782,77 @@ fail:
>  av_freep();
>  }
>  
> -static const HWAccel *get_hwaccel(enum AVPixelFormat pix_fmt, enum
> HWAccelID selected_hwaccel_id) -{
> -int i;
> -for (i = 0; hwaccels[i].name; i++)
> -if (hwaccels[i].pix_fmt == pix_fmt &&
> -(!selected_hwaccel_id || selected_hwaccel_id ==
> HWACCEL_AUTO || hwaccels[i].id == selected_hwaccel_id))
> -return [i];
> -return NULL;
> -}
> -
>  static enum AVPixelFormat get_format(AVCodecContext *s, const enum
> AVPixelFormat *pix_fmts) {
>  InputStream *ist = s->opaque;
>  const enum AVPixelFormat *p;
>  int ret;
>  
> -for (p = pix_fmts; *p != -1; p++) {
> +for (p = pix_fmts; *p != AV_PIX_FMT_NONE; p++) {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(*p);
> -const HWAccel *hwaccel;
> +const AVCodecHWConfig  *config = NULL;
> +int i;
>  
>  if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
>  break;
>  
> -hwaccel = get_hwaccel(*p, ist->hwaccel_id);
> -if (!hwaccel ||
> -(ist->active_hwaccel_id && ist->active_hwaccel_id !=
> hwaccel->id) ||
> -(ist->hwaccel_id != HWACCEL_AUTO && ist->hwaccel_id !=
> hwaccel->id))
> -continue;
> +if (ist->hwaccel_id == HWACCEL_GENERIC ||
> +ist->hwaccel_id == HWACCEL_AUTO) {
> +for (i = 0;; i++) {
> +config = avcodec_get_hw_config(s->codec, i);
> +if (!config)
> +break;
> +if (!(config->methods &
> +  AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX))
> +continue;

Just to be explicit, only METHOD_HW_DEVICE_CTX hwaccels can be
generically initialized, so that's why you exclude any other method?

> +if (config->pix_fmt == *p)
> +break;
> +}
> +}
> +if (config) {
> +if (config->device_type != ist->hwaccel_device_type) {
> +// Different hwaccel offered, ignore.
> +continue;
> +}
>  
> -ret = hwaccel->init(s);
> -if (ret < 0) {
> -if (ist->hwaccel_id == hwaccel->id) {
> +ret = hwaccel_decode_init(s);
> +if (ret < 0) {
> +if (ist->hwaccel_id == HWACCEL_GENERIC) {
> +av_log(NULL, AV_LOG_FATAL,
> +   "%s hwaccel requested for input stream
> #%d:%d, "
> +   "but cannot be initialized.\n",
> +
> av_hwdevice_get_type_name(config->device_type),
> +   ist->file_index, ist->st->index);
> +return AV_PIX_FMT_NONE;
> +}
> +continue;
> +}
> +} else {
> +const HWAccel *hwaccel = NULL;
> +int i;
> +for (i = 0; hwaccels[i].name; i++) {
> +if (hwaccels[i].pix_fmt == *p) {
> +hwaccel = [i];
> +break;

This can also overrun the NULL terminator right? Or are we lucky
because 'name' is at offset zero inside the struct and there's no
dereference taking place.

I see this pattern has been used previously so it obviously works out.

> +}
> +}
> +if (!hwaccel) {
> +// No hwaccel supporting this pixfmt.
> +continue;
> +}
> +if (hwaccel->id != ist->hwaccel_id) {
> +// Does not match requested hwaccel.
> +continue;
> +}
> +
> +ret = hwaccel->init(s);
> +if (ret < 0) {
>  av_log(NULL, AV_LOG_FATAL,
> "%s hwaccel requested for input stream
> #%d:%d, " "but cannot be initialized.\n", hwaccel->name,
> ist->file_index, ist->st->index);
>  return AV_PIX_FMT_NONE;
>  }
> -continue;
>  }
>  
>  if (ist->hw_frames_ctx) {
> @@ -2829,8 +2861,7 @@ static enum AVPixelFormat
> get_format(AVCodecContext *s, const enum AVPixelFormat return
> AV_PIX_FMT_NONE; }
>  
> -ist->active_hwaccel_id = hwaccel->id;
> -ist->hwaccel_pix_fmt   = *p;
> +ist->hwaccel_pix_fmt = *p;
>  break;
>  }
>  
> diff --git 

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

2017-11-21 Thread 刘歧

> 在 2017年11月22日,11:39,Jeyapal, Karthick  写道:
> 
>> On 11/21/17, 8:24 PM, "Steven Liu"  wrote:
>> 
> […]
>>> +if (*pb == NULL || !http_base_proto || !hls->http_persistent) {
>> What about !*pb ?
> 
> Thanks for your comments. 
> I have modified the patch as per your suggestion and have attached the same.
> 
This patch is ok, but i see it need an API: ffio_geturlcontext

it in the other patch, i see it have some thing need talk? If that is ok, this 
patch should be apply.

Thanks
> Regards,
> Karthick
> 
> 
> <0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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


Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

2017-11-21 Thread Jeyapal, Karthick
>On 11/21/17, 8:24 PM, "Steven Liu"  wrote:
>
[…]
>> +if (*pb == NULL || !http_base_proto || !hls->http_persistent) {
>What about !*pb ?

Thanks for your comments. 
I have modified the patch as per your suggestion and have attached the same.

Regards,
Karthick




0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
Description: 0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

2017-11-21 Thread Jeyapal, Karthick
>On 11/22/17, 5:06 AM, "Marton Balint"  wrote:
>
>Ok, applied the series with some minor whitespace/comment fixes.
Great! Thanks.
>
>Thanks,
>Marton

Regards,
Karthick

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


Re: [FFmpeg-devel] [PATCH 2/3] qsv/h264enc: fix cavlc option setting useless issue

2017-11-21 Thread Li, Zhong
> -Original Message-
> From: Li, Zhong
> Sent: Monday, November 13, 2017 5:30 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [PATCH 2/3] qsv/h264enc: fix cavlc option setting useless issue
> 
> No matter cavlc option is set to 0 or 1, the output bitstream is always cabac
> mode.
> Reproduce: -y -s widthxheight -i widthxheight.yuv -vcodec h264_qsv -b:v
> 2000k -maxrate 2000k -look_ahead 0 -cavlc 1 test.h264 Then check the
> entropy_coding_mode_flag of the encoded bitstream It is due to the
> dulicate option "coder" (which should be deprecated) is set to cabac
> 
> Signed-off-by: Zhong Li 

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


Re: [FFmpeg-devel] [avformat] Prevent undefined shift with wrap_bits > 63.

2017-11-21 Thread Michael Niedermayer
On Tue, Nov 21, 2017 at 03:19:38PM -0800, Dale Curtis wrote:
> Ah, realized this approach can work for wrap_bits == 64 too. Updated the
> patch.
> 
> On Mon, Nov 20, 2017 at 5:42 PM, Dale Curtis 
> wrote:
> 
> > On Mon, Nov 20, 2017 at 2:24 PM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> >>
> >> I think that could end with the correct result
> >>
> >>
> > Thanks for the review. Done.
> >
> > - dale
> >

>  utils.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 37722f8edea291bc79742519d06fbea906031074  wrap_bits_v4.patch
> From 6f087bbdb6499dc21a53fcb838348ea271d4ca5a Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Fri, 17 Nov 2017 13:35:56 -0800
> Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits > 64.
> 
> 2LL << (wrap_bits=64 - 1) does not fit in int64_t; change the
> code to use a uint64_t (2ULL) and apply the check used in other
> places to ensure wrap_bits <= 64.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/utils.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index ff5e14df6c..2cf8d61e82 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1738,9 +1738,9 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>  // current one had no dts, we will set this to 
> AV_NOPTS_VALUE.
>  int64_t last_dts = next_pkt->dts;
>  while (pktl && next_pkt->pts == AV_NOPTS_VALUE) {
> -if (pktl->pkt.stream_index == next_pkt->stream_index &&
> -(av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << 
> (wrap_bits - 1)) < 0)) {
> -if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2LL 
> << (wrap_bits - 1))) {

> +if (pktl->pkt.stream_index == next_pkt->stream_index && 
> wrap_bits <= 64 &&

I dont think wrap_bits can/should be > 64 or do i miss something ?

maybe a av_assert* for that would be better.

Static analyzers like coverity love to assume that a check implies
the possibility of a field having some value. That could lead to
strange things and false positves if its not actually possible


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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


Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-21 Thread Michael Niedermayer
On Mon, Nov 20, 2017 at 08:27:05PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 50 
> 
>  tests/fate/mov.mak   |  7 ++
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  tests/ref/fate/mov-guess-delay-3 |  3 +++
>  5 files changed, 66 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2
>  create mode 100644 tests/ref/fate/mov-guess-delay-3
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index fd170baa57..afb0d4ca5c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3213,6 +3213,54 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
> unsigned int* ctts_count, uns
>  return *ctts_count;
>  }
>  
> +static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
> +MOVStreamContext *msc = st->priv_data;
> +int ind;
> +int ctts_ind = 0;
> +int ctts_sample = 0;
> +int64_t curr_pts = AV_NOPTS_VALUE;
> +int64_t min_prev_pts = AV_NOPTS_VALUE;
> +int64_t prev_max_pts = AV_NOPTS_VALUE;
> +int num_steps = 0;
> +
> +if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
> +st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +st->codecpar->video_delay = 0;
> +for(ind = 0; ind < st->nb_index_entries && ctts_ind < 
> msc->ctts_count; ++ind) {
> +curr_pts = st->index_entries[ind].timestamp + 
> msc->ctts_data[ctts_ind].duration;
> +
> +// Everytime we encounter a new max_pts we reset num_steps and 
> compute again.
> +if (curr_pts > prev_max_pts) {
> +st->codecpar->video_delay = 
> FFMIN(FFMAX(st->codecpar->video_delay, num_steps), 16);
> +num_steps = 0;
> +prev_max_pts = curr_pts;
> +min_prev_pts = curr_pts;
> +} else {
> +// Compute delay as the length of the path from max PTS to 
> min PTS.
> +// Frames: I0 I1 B0 B1 B2
> +// PTS: 0  4  1  2  3 -> num_steps = delay = 1 (4->1)
> +//
> +// Frames: I0 I1 B1 B0 B2
> +// PTS: 0  4  2  1  3 -> num_steps = delay = 2 (4->2, 
> 2->1)
> +if (min_prev_pts != AV_NOPTS_VALUE) {
> +if (curr_pts < min_prev_pts) {
> +++num_steps;
> +min_prev_pts = curr_pts;
> +}
> +}
> +}

Can you explain why this algorithm is correct ?
(iam asking as i suspect it is not correct, but i may be wrong)

What this should do is find the minimum buffer size to sort the stream
of frame timestamps.


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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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


Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-21 Thread Michael Niedermayer
On Tue, Nov 21, 2017 at 09:59:08AM +0530, Sasi Inguva wrote:
> Reattaching Fate sample.

uploaded

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000: Dynamically allocate codeblock data

2017-11-21 Thread Michael Niedermayer
On Sat, Nov 18, 2017 at 01:33:18AM +0100, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 3541/clusterfuzz-testcase-minimized-6469958596820992
> 
> Adds support for decoding codeblock data larger than 8kb
> Reduces decoder memory consumption
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/j2kenc.c  |  8 ++--
>  libavcodec/jpeg2000.c| 12 ++--
>  libavcodec/jpeg2000.h|  4 ++--
>  libavcodec/jpeg2000dec.c | 22 +++---
>  4 files changed, 37 insertions(+), 9 deletions(-)

applied

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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


Re: [FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes

2017-11-21 Thread Rodger Combs


> On Nov 21, 2017, at 19:03, Rostislav Pehlivanov  wrote:
> 
> On 2 August 2017 at 00:35, Rodger Combs  > wrote:
> 
>> 
>>> On Aug 1, 2017, at 18:25, James Almer  wrote:
>>> 
>>> On 8/1/2017 3:33 AM, Rodger Combs wrote:
 ---
 libavformat/flacenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
 index 9768b6a..1906aee 100644
 --- a/libavformat/flacenc.c
 +++ b/libavformat/flacenc.c
 @@ -322,7 +322,7 @@ static int flac_write_trailer(struct
>> AVFormatContext *s)
if (!c->write_header || !streaminfo)
return 0;
 
 -if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
 +if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
>> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
>>> 
>>> In what situation would stream extradata or c->streaminfo be smaller
>>> than FLAC_STREAMINFO_SIZE? Nothing changes par->extradata anywhere, and
>>> c->streaminfo is always allocated with FLAC_STREAMINFO_SIZE bytes of
>> memory.
>>> I have the feeling i already asked this before, but not sure if you
>>> answered it. Apologies if you did.
>> 
>> It shouldn't happen in normal cases, but you could imagine a case with
>> remuxing a corrupted input file.
>> 
> 
> Shouldn't the demuxer handle this?

Even in e.g. MKV?

> ___
> 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] avformat/mxfdec: fix last packet timestamps

2017-11-21 Thread Marton Balint
Fixes the packet timestamps of the last packet, which was unset, or guessed by
compute_pkt_fields.

ffprobe -fflags nofillin -show_packets tests/data/lavf/lavf.mxf -select_streams 
v

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c|  8 
 tests/ref/seek/lavf-mxf_d10 | 12 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 118e3e40b4..ace5eaf687 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -3060,12 +3060,12 @@ static int mxf_set_audio_pts(MXFContext *mxf, 
AVCodecParameters *par,
 return 0;
 }
 
-static int mxf_set_pts(MXFContext *mxf, AVStream *st, AVPacket *pkt, int64_t 
next_ofs)
+static int mxf_set_pts(MXFContext *mxf, AVStream *st, AVPacket *pkt)
 {
 AVCodecParameters *par = st->codecpar;
 MXFTrack *track = st->priv_data;
 
-if (par->codec_type == AVMEDIA_TYPE_VIDEO && next_ofs >= 0) {
+if (par->codec_type == AVMEDIA_TYPE_VIDEO) {
 /* mxf->current_edit_unit good - see if we have an
  * index table to derive timestamps from */
 MXFIndexTable *t = >index_tables[0];
@@ -3152,7 +3152,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
AVPacket *pkt)
 pkt->stream_index = index;
 pkt->pos = klv.offset;
 
-ret = mxf_set_pts(mxf, st, pkt, next_ofs);
+ret = mxf_set_pts(mxf, st, pkt);
 if (ret < 0)
 return ret;
 
@@ -3217,7 +3217,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 pkt->stream_index = st->index;
 
-ret = mxf_set_pts(mxf, st, pkt, next_pos);
+ret = mxf_set_pts(mxf, st, pkt);
 if (ret < 0)
 return ret;
 
diff --git a/tests/ref/seek/lavf-mxf_d10 b/tests/ref/seek/lavf-mxf_d10
index 17cca29c03..5a682f0927 100644
--- a/tests/ref/seek/lavf-mxf_d10
+++ b/tests/ref/seek/lavf-mxf_d10
@@ -8,9 +8,9 @@ ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 
pos:4265984 size:15
 ret: 0 st: 0 flags:1  ts:-0.32
 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 
size:15
 ret: 0 st: 1 flags:0  ts: 2.576667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st: 1 flags:1  ts: 1.470833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st:-1 flags:0  ts: 0.365002
 ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos:1923072 
size:15
 ret: 0 st:-1 flags:1  ts:-0.740831
@@ -22,7 +22,7 @@ ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 
pos:5117952 size:15
 ret: 0 st: 1 flags:0  ts:-0.058333
 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 
size:15
 ret: 0 st: 1 flags:1  ts: 2.835833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st:-1 flags:0  ts: 1.730004
 ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st:-1 flags:1  ts: 0.624171
@@ -32,7 +32,7 @@ ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 
  6144 size:15
 ret: 0 st: 0 flags:1  ts: 2.40
 ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st: 1 flags:0  ts: 1.306667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st: 1 flags:1  ts: 0.200833
 ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos:1071104 
size:15
 ret: 0 st:-1 flags:0  ts:-0.904994
@@ -44,9 +44,9 @@ ret: 0 st: 0 flags:1 dts: 0.88 pts: 0.88 
pos:4691968 size:15
 ret: 0 st: 0 flags:1  ts:-0.24
 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   6144 
size:15
 ret: 0 st: 1 flags:0  ts: 2.671667
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st: 1 flags:1  ts: 1.565833
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:5117952 
size:15
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:5117952 
size:15
 ret: 0 st:-1 flags:0  ts: 0.460008
 ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos:2562048 
size:15
 ret: 0 st:-1 flags:1  ts:-0.645825
-- 
2.13.6

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


Re: [FFmpeg-devel] [PATCH 5/7] lavf/flacenc: support writing attached pictures

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 15:30, James Almer  wrote:

> On 8/2/2017 3:30 AM, Rodger Combs wrote:
> > ---
> >  libavformat/flacenc.c | 285 ++
> +---
> >  1 file changed, 250 insertions(+), 35 deletions(-)
> >
> > diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> > index b894f9e..9768b6a 100644
>
> [...]
>
> > @@ -166,23 +341,63 @@ static int flac_write_trailer(struct
> AVFormatContext *s)
> >  static int flac_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> >  {
> >  FlacMuxerContext *c = s->priv_data;
> > -uint8_t *streaminfo;
> > -int streaminfo_size;
> > +if (pkt->stream_index == c->audio_stream_idx) {
> > +if (c->waiting_pics) {
> > +/* buffer audio packets until we get all the pictures */
> > +AVPacketList *pktl = av_mallocz(sizeof(*pktl));
> > +int ret;
> > +if (!pktl) {
> > +ret = AVERROR(ENOMEM);
> > +oom:
> > +if (s->error_recognition & AV_EF_EXPLODE) {
> > +av_free(pktl);
> > +return ret;
> > +}
> > +av_log(s, AV_LOG_ERROR, "Out of memory in packet queue;
> skipping attached pictures\n");
> > +c->waiting_pics = 0;
> > +if ((ret = flac_queue_flush(s)) < 0)
> > +return ret;
> > +return flac_write_audio_packet(s, pkt);
> > +}
> > +
> > +ret = av_packet_ref(>pkt, pkt);
> > +if (ret < 0) {
> > +av_freep();
> > +goto oom;
> > +}
> > +
> > +if (c->queue_end)
> > +c->queue_end->next = pktl;
> > +else
> > +c->queue = pktl;
> > +c->queue_end = pktl;
> > +} else {
> > +return flac_write_audio_packet(s, pkt);
> > +}
> > +} else {
> > +int ret, index = pkt->stream_index;
> >
> > -/* check for updated streaminfo */
> > -streaminfo = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
> > - _size);
> > -if (streaminfo && streaminfo_size == FLAC_STREAMINFO_SIZE) {
> > -av_freep(>streaminfo);
> > +/* warn only once for each stream */
> > +if (s->streams[pkt->stream_index]->nb_frames == 1) {
> > +av_log(s, AV_LOG_WARNING, "Got more than one picture in
> stream %d,"
> > +   " ignoring.\n", pkt->stream_index);
> > +}
> > +if (!c->waiting_pics || s->streams[pkt->stream_index]->nb_frames
> >= 1)
> > +return 0;
> >
> > -c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
> > -if (!c->streaminfo)
> > -return AVERROR(ENOMEM);
> > -memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
> > +if (index > c->audio_stream_idx)
> > +index--;
> > +
> > +if ((ret = av_copy_packet(>pics[index], pkt)) < 0)
>
> Shouldn't this be av_packet_ref()?
> And they should probably be unreferenced after being consumed in
> flac_finish_header(), much like the audio packets are in
> flac_queue_flush().
>
> Also, you don't seem to be freeing c->pics anywhere.
>
>
av_packet_copy does a ref if the data is refcounted so its okay.
c->pics is indeed not freed, as well as the pictures it refs

If you free the list of pics and the pics themselves during
flac_finish_header() the patch will LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-21 Thread Rostislav Pehlivanov
On 14 November 2017 at 19:47, Mark Thompson  wrote:

> Changes since the last time this was posted:
> * Add unsharp filter (to replace existing unsharp).
> * Remove old experimental API.
> * Miscellaneous fixes.
>
> Now also tested with AMD OpenCL on Windows (DXVA2 mapping works nicely,
> D3D11 does not because it wants the Intel extension for NV12 support).
>
> Thanks,
>
> - Mark
>
>
> Silly example using everything (for i965 VAAPI + Beignet):
>
> ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device
> opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format
> vaapi -i in.mp4 -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl
> -filter_complex '[1:v]format=yuva420p,hwupload[x2];
> [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1]; [x1][x2]overlay_opencl=0:0,
> program_opencl=test.cl:rotate_image,unsharp_opencl=lx=17:ly=
> 17:la=5,hwmap=derive_device=vaapi:reverse=1,scale_vaapi=1280:720:nv12'
> -c:v h264_vaapi -frames:v 1000 out.mp4
>
> test.cl:
>
> __kernel void rotate_image(__write_only image2d_t dst,
>__read_only  image2d_t src,
>unsigned int index)
> {
>   const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
>  CLK_FILTER_LINEAR);
>
>   float angle = (float)index / 100;
>
>   float2 dst_dim = convert_float2(get_image_dim(dst));
>   float2 src_dim = convert_float2(get_image_dim(src));
>
>   float2 dst_cen = dst_dim / 2;
>   float2 src_cen = src_dim / 2;
>
>   int2   dst_loc = (int2)(get_global_id(0), get_global_id(1));
>
>   float2 dst_pos = convert_float2(dst_loc) - dst_cen;
>   float2 src_pos = {
> cos(angle) * dst_pos.x - sin(angle) * dst_pos.y,
> sin(angle) * dst_pos.x + cos(angle) * dst_pos.y
>   };
>   src_pos = src_pos * src_dim / dst_dim;
>
>   float2 src_loc = src_pos + src_cen;
>
>   if (src_loc.x < 0 || src_loc.y < 0 ||
>   src_loc.x > src_dim.x || src_loc.y > src_dim.y)
> write_imagef(dst, dst_loc, 0.5);
>   else
> write_imagef(dst, dst_loc, read_imagef(src, sampler, src_loc));
> }
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Reviewed and tested, LGTM from me
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 7/7] lavf/flacenc: generate timestamps internally

2017-11-21 Thread Rostislav Pehlivanov
On 1 August 2017 at 07:33, Rodger Combs  wrote:

> ---
>  libavformat/flacenc.c | 88 ++
> +++--
>  1 file changed, 85 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index 1906aee..f569c14 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -30,6 +30,7 @@
>  #include "internal.h"
>  #include "vorbiscomment.h"
>  #include "libavcodec/bytestream.h"
> +#include "libavutil/crc.h"
>
>
>  typedef struct FlacMuxerContext {
> @@ -46,6 +47,9 @@ typedef struct FlacMuxerContext {
>  uint8_t *streaminfo;
>
>  unsigned attached_types;
> +
> +uint64_t samples;
> +unsigned last_bs;
>  } FlacMuxerContext;
>
>  static int flac_write_block_padding(AVIOContext *pb, unsigned int
> n_padding_bytes,
> @@ -263,11 +267,17 @@ static int flac_write_header(struct AVFormatContext
> *s)
>  return ret;
>  }
>
> +static const int32_t blocksize_table[16] = {
> + 0,192, 576<<0, 576<<1, 576<<2, 576<<3,  0,  0,
> +256<<0, 256<<1, 256<<2, 256<<3, 256<<4, 256<<5, 256<<6, 256<<7
> +};
> +
>  static int flac_write_audio_packet(struct AVFormatContext *s, AVPacket
> *pkt)
>  {
>  FlacMuxerContext *c = s->priv_data;
>  uint8_t *streaminfo;
>  int streaminfo_size;
> +char header[16];
>
>  /* check for updated streaminfo */
>  streaminfo = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
> @@ -281,8 +291,77 @@ static int flac_write_audio_packet(struct
> AVFormatContext *s, AVPacket *pkt)
>  memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
>  }
>
> -if (pkt->size)
> -avio_write(s->pb, pkt->data, pkt->size);
> +if (pkt->size) {
> +uint8_t tmp;
> +uint64_t pts = c->samples;
> +int offset = 5;
> +int headerlen = 4;
> +int bscode, bs;
> +int crc;
> +if (pkt->size < FLAC_MIN_FRAME_SIZE)
> +return AVERROR_INVALIDDATA;
> +memcpy(header, pkt->data, 4);
> +if (pkt->pts == AV_NOPTS_VALUE)
> +pts = 0;
> +if ((pkt->data[4] & 0xC0) == 0xC0)
> +offset += ff_clz((unsigned char)~pkt->data[4]) - 25;
> +else if (pkt->data[4] & 0x80)
> +return AVERROR_INVALIDDATA;
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +
> +bscode = (unsigned char)header[2] >> 4;
> +bs = blocksize_table[bscode];
> +if (bscode == 0)
> +return AVERROR_INVALIDDATA;
> +if (bscode == 6) {
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +bs = pkt->data[offset] + 1;
> +} else if (bscode == 7) {
> +if (pkt->size <= offset + 2)
> +return AVERROR_INVALIDDATA;
> +bs = AV_RB16(>data[offset]) + 1;
> +}
> +if ((header[1] & 1) == 0)
> +pts /= c->last_bs ? c->last_bs : bs;
> +
> +c->last_bs = bs;
> +
> +c->samples += bs;
> +
> +PUT_UTF8(pts, tmp, header[headerlen++] = tmp;)
> +if (headerlen > 11)
> +return AVERROR_INVALIDDATA;
> +if ((bscode & 0xE) == 0x6)
> +header[headerlen++] = pkt->data[offset++];
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +if (bscode == 0x7)
> +header[headerlen++] = pkt->data[offset++];
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +if ((header[2] & 0xC) == 0xC) {
> +header[headerlen++] = pkt->data[offset++];
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +if ((header[2] & 0x3) == 0x3)
> +return AVERROR_INVALIDDATA;
> +else if (header[2] & 0x3) {
> +header[headerlen++] = pkt->data[offset++];
> +if (pkt->size <= offset + 1)
> +return AVERROR_INVALIDDATA;
> +}
> +}
> +header[headerlen] = av_crc(av_crc_get_table(AV_CRC_8_ATM), 0,
> header, headerlen);
> +headerlen++; offset++;
> +crc = av_crc(av_crc_get_table(AV_CRC_16_ANSI), 0, header,
> headerlen);
> +if (pkt->size < offset + 3)
> +return AVERROR_INVALIDDATA;
> +avio_write(s->pb, header, headerlen);
> +avio_write(s->pb, pkt->data + offset, pkt->size - offset - 2);
> +avio_wl16(s->pb, av_crc(av_crc_get_table(AV_CRC_16_ANSI), crc,
> pkt->data + offset, pkt->size - offset - 2));
> +}
>  return 0;
>  }
>
> @@ -326,7 +405,10 @@ static int flac_write_trailer(struct AVFormatContext
> *s)
>  /* rewrite the STREAMINFO header block data */
>  file_size = avio_tell(pb);
>  avio_seek(pb, 8, SEEK_SET);
> -avio_write(pb, streaminfo, FLAC_STREAMINFO_SIZE);
> +avio_write(pb, streaminfo, 13);
> +avio_w8(pb, 

Re: [FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 00:35, Rodger Combs  wrote:

>
> > On Aug 1, 2017, at 18:25, James Almer  wrote:
> >
> > On 8/1/2017 3:33 AM, Rodger Combs wrote:
> >> ---
> >> libavformat/flacenc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> >> index 9768b6a..1906aee 100644
> >> --- a/libavformat/flacenc.c
> >> +++ b/libavformat/flacenc.c
> >> @@ -322,7 +322,7 @@ static int flac_write_trailer(struct
> AVFormatContext *s)
> >> if (!c->write_header || !streaminfo)
> >> return 0;
> >>
> >> -if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> >> +if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
> >
> > In what situation would stream extradata or c->streaminfo be smaller
> > than FLAC_STREAMINFO_SIZE? Nothing changes par->extradata anywhere, and
> > c->streaminfo is always allocated with FLAC_STREAMINFO_SIZE bytes of
> memory.
> > I have the feeling i already asked this before, but not sure if you
> > answered it. Apologies if you did.
>
> It shouldn't happen in normal cases, but you could imagine a case with
> remuxing a corrupted input file.
>

Shouldn't the demuxer handle this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-21 Thread Carl Eugen Hoyos
2017-11-22 1:30 GMT+01:00 Mark Thompson :
> On 14/11/17 19:47, Mark Thompson wrote:
>> Changes since the last time this was posted:
>> * Add unsharp filter (to replace existing unsharp).
>> * Remove old experimental API.
>> * Miscellaneous fixes.
>>
>> Now also tested with AMD OpenCL on Windows (DXVA2
>> mapping works nicely, D3D11 does not because it wants
>> the Intel extension for NV12 support).
>
> I have approval for this from James and Rostislav (via IRC).

I don't exactly why vhook was removed but I would prefer
if this patch would be approved on the mailing list.

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


Re: [FFmpeg-devel] [PATCH 4/7] lavf/segment: write attached pictures to all segments by default

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 07:30, Rodger Combs  wrote:

> ---
>  doc/muxers.texi   |  4 
>  libavformat/segment.c | 40 +---
>  2 files changed, 33 insertions(+), 11 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 23ef2e7..93147e1 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1576,6 +1576,10 @@ argument must be a time duration specification, and
> defaults to 0.
>  If enabled, write an empty segment if there are no packets during the
> period a
>  segment would usually span. Otherwise, the segment will be filled with
> the next
>  packet written. Defaults to @code{0}.
> +
> +@item dup_attached_pics @var{1|0}
> +If enabled, attached-picture packets will be written to all segments,
> rather
> +than only the first. Defaults to @code{1}.
>  @end table
>
>  @subsection Examples
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index ef0a915..632476e 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -119,6 +119,7 @@ typedef struct SegmentContext {
>  int   reference_stream_index;
>  int   break_non_keyframes;
>  int   write_empty;
> +int   dup_attached_pics;
>
>  int use_rename;
>  char temp_list_filename[1024];
> @@ -126,6 +127,8 @@ typedef struct SegmentContext {
>  SegmentListEntry cur_entry;
>  SegmentListEntry *segment_list_entries;
>  SegmentListEntry *segment_list_entries_end;
> +
> +AVPacket *attached_pics;
>  } SegmentContext;
>
>  static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
> @@ -193,16 +196,15 @@ static int replace_variables(AVFormatContext *oc)
>  {
>  char name[sizeof(oc->filename)];
>  char *p = name;
> -char *out = oc->filename;
> +AVBPrint bprint;
>  strncpy(name, oc->filename, sizeof(name));
> +av_bprint_init_for_buffer(, oc->filename,
> sizeof(oc->filename));
>  while (*p) {
>  char c = *p++;
>  if (c == '$') {
>  if (*p == '$') {
> -p++;
> -goto append;
> +av_bprint_chars(, c, 1);
>  } else {
> -int len;
>  const char *val;
>  const AVDictionaryEntry *e;
>  int end = strcspn(p, "$");
> @@ -211,18 +213,13 @@ static int replace_variables(AVFormatContext *oc)
>  p[end] = '\0';
>  e = av_dict_get(oc->metadata, p, NULL, 0);
>  val = e ? e->value : "(unknown)";
> -len = strlen(val);
> -strncpy(out, val, oc->filename + sizeof(oc->filename) - 1
> - out);
> -out = FFMIN(oc->filename + sizeof(oc->filename) - 1, out
> + len);
> +av_bprint_append_data(, val, strlen(val));
>  p += end + 1;
>  }
>  } else {
> -append:
> -if (out - oc->filename < sizeof(oc->filename) - 1)
> -*out++ = c;
> +av_bprint_chars(, c, 1);
>  }
>  }
> -*out = '\0';
>  return 0;
>  }
>
> @@ -301,6 +298,7 @@ static int segment_start(AVFormatContext *s, int
> write_header)
>  av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);
>
>  if (write_header) {
> +int i;
>  AVDictionary *options = NULL;
>  av_dict_copy(, seg->format_options, 0);
>  av_dict_set(, "fflags", "-autobsf", 0);
> @@ -308,6 +306,13 @@ static int segment_start(AVFormatContext *s, int
> write_header)
>  av_dict_free();
>  if (err < 0)
>  return err;
> +for (i = 0; i < s->nb_streams; i++) {
> +if (seg->dup_attached_pics &&
> +s->streams[i]->disposition & AV_DISPOSITION_ATTACHED_PIC
> &&
> +seg->attached_pics[i].data) {
> +av_write_frame(oc, >attached_pics[i]);
> +}
> +}
>  }
>
>  seg->segment_frame_count = 0;
> @@ -680,6 +685,12 @@ static void seg_free(AVFormatContext *s)
>  ff_format_io_close(seg->avf, >list_pb);
>  avformat_free_context(seg->avf);
>  seg->avf = NULL;
> +if (seg->attached_pics) {
> +int i;
> +for (i = 0; i < s->nb_streams; i++)
> +av_packet_unref(>attached_pics[i]);
> +av_freep(>attached_pics);
> +}
>  }
>
>  static int seg_init(AVFormatContext *s)
> @@ -840,6 +851,9 @@ static int seg_init(AVFormatContext *s)
>  avpriv_set_pts_info(outer_st, inner_st->pts_wrap_bits,
> inner_st->time_base.num, inner_st->time_base.den);
>  }
>
> +if (seg->dup_attached_pics && !(seg->attached_pics =
> av_calloc(s->nb_streams, sizeof(AVPacket
> +return AVERROR(ENOMEM);
> +
>  if (oc->avoid_negative_ts > 0 && s->avoid_negative_ts < 0)
>  s->avoid_negative_ts = 1;
>
> @@ -905,6 +919,9 @@ static int seg_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  if (!seg->avf || !seg->avf->pb)
>  return AVERROR(EINVAL);
>
> +  

Re: [FFmpeg-devel] [PATCH 1/7] lavf: add cue sheet demuxer

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 07:30, Rodger Combs  wrote:

> ---
>  Changelog|   2 +
>  doc/demuxers.texi|  17 
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/cuedec.c | 246 ++
> +
>  libavformat/version.h|   2 +-
>  6 files changed, 268 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/cuedec.c
>
> diff --git a/Changelog b/Changelog
> index 187ae79..6701d30 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -29,6 +29,8 @@ version :
>  - limiter video filter
>  - libvmaf video filter
>  - Dolby E decoder and SMPTE 337M demuxer
> +- Cue sheet demuxer
> +
>
>  version 3.3:
>  - CrystalHD decoder moved to new decode API
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 29a23d4..04eaf27 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -244,6 +244,23 @@ file subdir/file-2.wav
>  @end example
>  @end itemize
>
> +@section cue
> +
> +Cue sheet demuxer.
> +
> +This demuxer reads a cue sheet (text file) and exports its track listing
> in
> +the form of AVChapters. Packet data is read from the file listed in the
> sheet,
> +which must be in the same directory. To override the path the packet data
> is
> +read from, use the @code{url} option.
> +
> +This demuxer currently only supports cue sheets with a single audio file.
> +
> +This demuxer can be used along with the segment muxer to split a
> cue+audio pair
> +into individual files for the different tracks:
> +@example
> +ffmpeg -i input.cue -f segment -segment_chapters 1 '%02d $artist$ -
> $title$.flac'
> +@end example
> +
>  @section flv, live_flv
>
>  Adobe Flash Video Format demuxer.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index b0ef82c..4381c42 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -130,6 +130,7 @@ OBJS-$(CONFIG_CDXL_DEMUXER)  += cdxl.o
>  OBJS-$(CONFIG_CINE_DEMUXER)  += cinedec.o
>  OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
>  OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
> +OBJS-$(CONFIG_CUE_DEMUXER)   += cuedec.o
>  OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
>  OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
>  OBJS-$(CONFIG_DASH_MUXER)+= dashenc.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 1ebc142..25afa8b 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -96,6 +96,7 @@ static void register_all(void)
>  REGISTER_DEMUXER (CINE, cine);
>  REGISTER_DEMUXER (CONCAT,   concat);
>  REGISTER_MUXER   (CRC,  crc);
> +REGISTER_DEMUXER (CUE,  cue);
>  REGISTER_MUXER   (DASH, dash);
>  REGISTER_MUXDEMUX(DATA, data);
>  REGISTER_MUXDEMUX(DAUD, daud);
> diff --git a/libavformat/cuedec.c b/libavformat/cuedec.c
> new file mode 100644
> index 000..11b256d
> --- /dev/null
> +++ b/libavformat/cuedec.c
> @@ -0,0 +1,246 @@
> +/*
> + * Cue sheet demuxer
> + * Copyright (c) 2016 The FFmpeg Project
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +/**
> + * @file
> + * Cue sheet demuxer
> + * @author Rodger Combs 
> + */
> +
> +#include "avformat.h"
> +#include "internal.h"
> +#include "subtitles.h"
> +#include "url.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/opt.h"
> +
> +typedef struct CueDemuxContext {
> +AVClass *class;
> +char *url;
> +AVFormatContext *avf;
> +} CueDemuxContext;
> +
> +static int cue_probe(AVProbeData *p)
> +{
> +const unsigned char *ptr = p->buf;
> +int has_file = 0, has_track = 0;
> +
> +if (AV_RB24(ptr) == 0xEFBBBF)
> +ptr += 3;  /* skip UTF-8 BOM */
> +while (*ptr && (!has_file || !has_track)) {
> +while (*ptr == ' ' || *ptr == '\t')
> +ptr++;
> +if (!strncmp(ptr, "FILE ", 5)) {
> +ptr += 5;
> +while (*ptr == ' ' || *ptr == '\t')
> +ptr++;
> +if (*ptr == '"')
> +has_file = 1;
> +} else if (!strncmp(ptr, 

Re: [FFmpeg-devel] [PATCH 3/7] lavf/segment: copy stream dispositions in output

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 07:30, Rodger Combs  wrote:

> ---
>  libavformat/segment.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 590f62b..ef0a915 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -182,6 +182,7 @@ static int segment_mux_init(AVFormatContext *s)
>  }
>  st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
>  st->time_base = s->streams[i]->time_base;
> +st->disposition = s->streams[i]->disposition;
>  av_dict_copy(>metadata, s->streams[i]->metadata, 0);
>  }
>
> --
> 2.6.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Makes sense, LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/7] lavf/segment: add option to segment by chapter

2017-11-21 Thread Rostislav Pehlivanov
On 2 August 2017 at 07:30, Rodger Combs  wrote:

> ---
>  doc/muxers.texi   |  6 +
>  libavformat/segment.c | 65 ++
> +
>  libavformat/version.h |  2 +-
>  3 files changed, 67 insertions(+), 6 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 94472ce..23ef2e7 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1538,6 +1538,12 @@ This option specifies to start a new segment
> whenever a reference
>  stream key frame is found and the sequential number (starting from 0)
>  of the frame is greater or equal to the next value in the list.
>
> +@item segment_chapters @var{1|0}
> +Split each chapter into its own segment. Metadata from the chapters
> +will be written to the corresponding segments. If this option is selected
> +and the filename contains tokens in the format @code{$varname$}, they
> +will be replaced by the corresponding metadata values.
> +
>  @item segment_wrap @var{limit}
>  Wrap around segment index once it reaches @var{limit}.
>
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 0e8bcdd..590f62b 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -106,6 +106,8 @@ typedef struct SegmentContext {
>  int frame_count;   ///< total number of reference frames
>  int segment_frame_count; ///< number of reference frames in the
> segment
>
> +int split_chapters;///< split on chapter markers
> +
>  int64_t time_delta;
>  int  individual_header_trailer; /**< Set by a private option. */
>  int  write_header_trailer; /**< Set by a private option. */
> @@ -186,6 +188,43 @@ static int segment_mux_init(AVFormatContext *s)
>  return 0;
>  }
>
> +static int replace_variables(AVFormatContext *oc)
> +{
> +char name[sizeof(oc->filename)];
> +char *p = name;
> +char *out = oc->filename;
> +strncpy(name, oc->filename, sizeof(name));
> +while (*p) {
> +char c = *p++;
> +if (c == '$') {
> +if (*p == '$') {
> +p++;
> +goto append;
> +} else {
> +int len;
> +const char *val;
> +const AVDictionaryEntry *e;
> +int end = strcspn(p, "$");
> +if (p[end] == '\0')
> +continue;
> +p[end] = '\0';
> +e = av_dict_get(oc->metadata, p, NULL, 0);
> +val = e ? e->value : "(unknown)";
> +len = strlen(val);
> +strncpy(out, val, oc->filename + sizeof(oc->filename) - 1
> - out);
> +out = FFMIN(oc->filename + sizeof(oc->filename) - 1, out
> + len);
> +p += end + 1;
> +}
> +} else {
> +append:
> +if (out - oc->filename < sizeof(oc->filename) - 1)
> +*out++ = c;
> +}
> +}
> +*out = '\0';
> +return 0;
> +}
> +
>  static int set_segment_filename(AVFormatContext *s)
>  {
>  SegmentContext *seg = s->priv_data;
> @@ -210,6 +249,9 @@ static int set_segment_filename(AVFormatContext *s)
>  return AVERROR(EINVAL);
>  }
>
> +if (seg->split_chapters)
> +replace_variables(oc);
> +
>  /* copy modified name in list entry */
>  size = strlen(av_basename(oc->filename)) + 1;
>  if (seg->entry_prefix)
> @@ -236,6 +278,8 @@ static int segment_start(AVFormatContext *s, int
> write_header)
>  if ((err = segment_mux_init(s)) < 0)
>  return err;
>  oc = seg->avf;
> +if (seg->split_chapters && seg->segment_count < s->nb_chapters &&
> (err = av_dict_copy(>metadata, s->chapters[seg->segment_count]->metadata,
> 0)) < 0)
> +return err;
>  }
>
>  seg->segment_idx++;
> @@ -659,10 +703,14 @@ static int seg_init(AVFormatContext *s)
> "you can use output_ts_offset instead of it\n");
>  }
>
> -if (!!seg->time_str + !!seg->times_str + !!seg->frames_str > 1) {
> +if (seg->segment_idx < 0)
> +seg->segment_idx = seg->split_chapters;
> +
> +if (!!seg->time_str + !!seg->times_str + !!seg->frames_str +
> !!seg->split_chapters > 1) {
>  av_log(s, AV_LOG_ERROR,
> -   "segment_time, segment_times, and segment_frames options "
> -   "are mutually exclusive, select just one of them\n");
> +   "segment_time, segment_times, segment_frames, and "
> +   "segment_chapters options are mutually exclusive; "
> +   "select just one of them\n");
>  return AVERROR(EINVAL);
>  }
>
> @@ -672,7 +720,7 @@ static int seg_init(AVFormatContext *s)
>  } else if (seg->frames_str) {
>  if ((ret = parse_frames(s, >frames, >nb_frames,
> seg->frames_str)) < 0)
>  return ret;
> -} else {
> +} else if (!seg->split_chapters) {
>  /* set default value if not specified */
>  if (!seg->time_str)
>  

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

2017-11-21 Thread Mark Thompson
On 21/11/17 23:08, Timo Rothenpieler wrote:
> Am 21.11.2017 um 16:32 schrieb Mironov, Mikhail:
>>
>> Are you all busy right now? Any hint on timing?
>> Thanks,
>> Mikhail
> 
> I cannot test this patch due to lack of hardware, but by now the code has 
> been polished for a while, and if no further comments/issues come up, I'd be 
> all for finally merging this.

I'd like to look through it again and test a bit more (will try to do so 
tomorrow, certainly by the end of the week), but I think it should be ready to 
commit with the external header removed.

Thanks,

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


Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

2017-11-21 Thread Mark Thompson
On 14/11/17 19:47, Mark Thompson wrote:
> Changes since the last time this was posted:
> * Add unsharp filter (to replace existing unsharp).
> * Remove old experimental API.
> * Miscellaneous fixes.
> 
> Now also tested with AMD OpenCL on Windows (DXVA2 mapping works nicely, D3D11 
> does not because it wants the Intel extension for NV12 support).

I have approval for this from James and Rostislav (via IRC).

If there are no further comments then I will push the whole set tomorrow.

Thanks,

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


Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-21 Thread Jim DeLaHunt

On 2017-11-21 16:05, Carl Eugen Hoyos wrote:

2017-11-22 0:59 GMT+01:00 Jim DeLaHunt:

On 2017-11-21 15:40, Carl Eugen Hoyos wrote:

2017-11-21 22:41 GMT+01:00 Jim DeLaHunt:


-@subheading Subscribe to the ffmpeg-cvslog mailing list.
-It is important to do this as the diffs of all commits are sent there
and
-reviewed by all the other developers. Bugs and possible improvements or
-general questions regarding commits are discussed there. We expect you
to
-react if problems with your code are uncovered.

I am against removing this paragraph.

[...]


2. Instead of /removing/ that paragraph, are you also against replacing it
with the same paragraph but centred on the ffmpeg-devel list?  The patch has
the following alternative:

+@section Documentation/Other
+@subheading Subscribe to the ffmpeg-devel mailing list.
+It is important to be subscribed to the
+@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
+mailing list, because any patch you contribute must be sent there
+and reviewed by the other developers. They may have comments about your
+contribution. We expect you see those comments, and to improve your
contribution
+if requested.
+Also, this list is where bugs and possible improvements or
+general questions regarding commits are discussed. That may be helpful
+information as you write your contribution. Finally, by being a list
+subscriber your contribution will be posted immediately to the list,
+without the moderation hold which messages from non-subscribers experience.

Sorry, I do not understand this paragraph / question.

If the alternative may lead to another answer than above, please consider
sending a complete patch.


Carl Eugen:

I believe I sent a complete patch.

Part of what that patch does is replace a section

   "@subheading Subscribe to the ffmpeg-cvslog mailing list."

with a similar section

   "@subheading Subscribe to the ffmpeg-devel mailing list."

Git put the delete lines first, then the replacement lines. See the 
lines labelled, "@@ -381,12 +379,19 @@". Do you see that part of the patch?


Also,
> [...]

I didn't see you answer my question 1, "Do you expect all contributors 
to ffmpeg to subscribe to the ffmpeg-cvslog email list //in addition 
to// the ffmpeg-devel list?" I think that question is relevant to 
deciding how to handle this @subheading section.

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

Best regards,
  —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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


Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-21 Thread Carl Eugen Hoyos
2017-11-22 0:59 GMT+01:00 Jim DeLaHunt :
> On 2017-11-21 15:40, Carl Eugen Hoyos wrote:
>>
>> 2017-11-21 22:41 GMT+01:00 Jim DeLaHunt:
>>
>>> -@subheading Subscribe to the ffmpeg-cvslog mailing list.
>>> -It is important to do this as the diffs of all commits are sent there
>>> and
>>> -reviewed by all the other developers. Bugs and possible improvements or
>>> -general questions regarding commits are discussed there. We expect you
>>> to
>>> -react if problems with your code are uncovered.
>>
>> I am against removing this paragraph.

[...]

> 2. Instead of /removing/ that paragraph, are you also against replacing it
> with the same paragraph but centred on the ffmpeg-devel list?  The patch has
> the following alternative:
>
> +@section Documentation/Other
> +@subheading Subscribe to the ffmpeg-devel mailing list.
> +It is important to be subscribed to the
> +@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
> +mailing list, because any patch you contribute must be sent there
> +and reviewed by the other developers. They may have comments about your
> +contribution. We expect you see those comments, and to improve your
> contribution
> +if requested.
> +Also, this list is where bugs and possible improvements or
> +general questions regarding commits are discussed. That may be helpful
> +information as you write your contribution. Finally, by being a list
> +subscriber your contribution will be posted immediately to the list,
> +without the moderation hold which messages from non-subscribers experience.

Sorry, I do not understand this paragraph / question.

If the alternative may lead to another answer than above, please consider
sending a complete patch.

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


Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-21 Thread Jim DeLaHunt

On 2017-11-21 15:40, Carl Eugen Hoyos wrote:

2017-11-21 22:41 GMT+01:00 Jim DeLaHunt:


-@subheading Subscribe to the ffmpeg-cvslog mailing list.
-It is important to do this as the diffs of all commits are sent there and
-reviewed by all the other developers. Bugs and possible improvements or
-general questions regarding commits are discussed there. We expect you to
-react if problems with your code are uncovered.

I am against removing this paragraph.

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


Thank you for the review, Carl Eugen.

Two questions for you.

1. Do you expect all contributors to ffmpeg to subscribe to the 
ffmpeg-cvslog email list /in addition to/ the ffmpeg-devel list? Even 
those who only want to contribute a bug fix or two, participate in 
review discussion, then leave?


2. Instead of /removing/ that paragraph, are you also against replacing 
it with the same paragraph but centred on the ffmpeg-devel list?  The 
patch has the following alternative:


+@section Documentation/Other
+@subheading Subscribe to the ffmpeg-devel mailing list.
+It is important to be subscribed to the
+@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
+mailing list, because any patch you contribute must be sent there
+and reviewed by the other developers. They may have comments about your
+contribution. We expect you see those comments, and to improve your 
contribution

+if requested.
+Also, this list is where bugs and possible improvements or
+general questions regarding commits are discussed. That may be helpful
+information as you write your contribution. Finally, by being a list
+subscriber your contribution will be posted immediately to the list,
+without the moderation hold which messages from non-subscribers 
experience.


Thanks,
  —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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


Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

2017-11-21 Thread Carl Eugen Hoyos
2017-11-21 18:53 GMT+01:00 Bjorn Roche :
> Support for transparencies in animated gifs requires modifying both
> libavcodec/gif.c and libavformat/gif.c because both the graphics
> control extension (handled by libavformat/gif.c) and the raw frame data
> (handled by libavcodec/gif.c) must be changed.

Does remuxing animated gif with transparency work with your patch?

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


Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-21 Thread Carl Eugen Hoyos
2017-11-21 22:41 GMT+01:00 Jim DeLaHunt :

> -@subheading Subscribe to the ffmpeg-cvslog mailing list.
> -It is important to do this as the diffs of all commits are sent there and
> -reviewed by all the other developers. Bugs and possible improvements or
> -general questions regarding commits are discussed there. We expect you to
> -react if problems with your code are uncovered.

I am against removing this paragraph.

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


[FFmpeg-devel] [mov] Increment stsd_count while processing stsd data; avoids leaks.

2017-11-21 Thread Dale Curtis
In the event of ff_mov_read_stsd_entries() failure, sc->stsd_count
is not updated, even if the function allocates extradata memory.
Instead update the sc->stsd_count as entries are parsed so that
mov_read_close() can do the right thing.

Signed-off-by: Dale Curtis 
From 3c69f724173582f48189a92c3116a6783e078961 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 21 Nov 2017 15:40:22 -0800
Subject: [PATCH] [mov] Increment stsd_count while processing stsd data; avoids
 leaks.

In the event of ff_mov_read_stsd_entries() failure, sc->stsd_count
is not updated, even if the function allocates extradata memory.
Instead update the sc->stsd_count as entries are parsed so that
mov_read_close() can do the right thing.

Signed-off-by: Dale Curtis 
---
 libavformat/mov.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index b6cdf3a52a..9e876efc8c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2464,8 +2464,10 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext *pb, int entries)
 }
 
 if (mov_skip_multiple_stsd(c, pb, st->codecpar->codec_tag, format,
-   size - (avio_tell(pb) - start_pos)))
+   size - (avio_tell(pb) - start_pos))) {
+sc->stsd_count++;
 continue;
+}
 
 sc->pseudo_stream_id = st->codecpar->codec_tag ? -1 : pseudo_stream_id;
 sc->dref_id= dref_id;
@@ -2517,6 +2519,7 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext *pb, int entries)
 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = 0;
 }
+sc->stsd_count++;
 }
 
 if (pb->eof_reached)
@@ -2566,8 +2569,6 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 if (ret < 0)
 goto fail;
 
-sc->stsd_count = entries;
-
 /* Restore back the primary extradata. */
 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = sc->extradata_size[0];
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

2017-11-21 Thread Marton Balint



On Mon, 20 Nov 2017, Jeyapal, Karthick wrote:


On 11/20/17, 12:39 AM, "Marton Balint"  wrote:



Thanks, there is one more thing I still don't get:


[...]

+// 1 second timeout
+for (i = 0; i < 10; i++) {
+av_usleep(10);
+// Sometimes VideoInputFrameArrived is called before 
VideoInputFormatChanged
+// So don't break for bmd_mode == AUTODETECT_DEFAULT_MODE



Even if you get a frame for the default mode, and
VideoInputFrameArrived is called early, the bmdFrameHasNoInputSource
flag should be set, so ctx->bmd_mode remains unknown, therefore you don't
have to handle it specially.

Are you saying that the Decklink drivers are buggy, and there are cases
where you get a frame without the bmdFrameHasNoInputSource flag, and then
a VideoInputFormatChanged callback later?


Yes, there are cases where you get a frame without the bmdFrameHasNoInputSource
flag, and then a VideoInputFormatChanged called later. And it is random.
But I don’t know if it could be called as a driver bug, since the getWidth and 
getHeight would return the correct values.
During my testing, I observed a 1080p30 would randomly get detected as,
AUTODETECT_DEFAULT_MODE because of VideoInputFrameArrived called early.
Hence I added that extra condition to handle it specially.


Ok, applied the series with some minor whitespace/comment fixes.

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


Re: [FFmpeg-devel] [avformat] Prevent undefined shift with wrap_bits > 63.

2017-11-21 Thread Dale Curtis
Ah, realized this approach can work for wrap_bits == 64 too. Updated the
patch.

On Mon, Nov 20, 2017 at 5:42 PM, Dale Curtis 
wrote:

> On Mon, Nov 20, 2017 at 2:24 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>>
>> I think that could end with the correct result
>>
>>
> Thanks for the review. Done.
>
> - dale
>
From 6f087bbdb6499dc21a53fcb838348ea271d4ca5a Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 13:35:56 -0800
Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits > 64.

2LL << (wrap_bits=64 - 1) does not fit in int64_t; change the
code to use a uint64_t (2ULL) and apply the check used in other
places to ensure wrap_bits <= 64.

Signed-off-by: Dale Curtis 
---
 libavformat/utils.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index ff5e14df6c..2cf8d61e82 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1738,9 +1738,9 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
 // current one had no dts, we will set this to AV_NOPTS_VALUE.
 int64_t last_dts = next_pkt->dts;
 while (pktl && next_pkt->pts == AV_NOPTS_VALUE) {
-if (pktl->pkt.stream_index == next_pkt->stream_index &&
-(av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0)) {
-if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2LL << (wrap_bits - 1))) {
+if (pktl->pkt.stream_index == next_pkt->stream_index && wrap_bits <= 64 &&
+av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2ULL << (wrap_bits - 1)) < 0) {
+if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2ULL << (wrap_bits - 1))) {
 // not B-frame
 next_pkt->pts = pktl->pkt.dts;
 }
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] [PATCH] Add android_capture indev

2017-11-21 Thread Michael Niedermayer
On Tue, Nov 21, 2017 at 08:16:08AM +0100, Felix Matouschek wrote:
> No more interest?

If you hear no more comments for another week, then please ping this
with CC to me and ill take a look and apply unless i spot some major
issue

also you probably want to add yourself to the MAINTAINER file if you
intend to maintain the code

thanks

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

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


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


[FFmpeg-devel] [ogm] Free extradata before reallocating.

2017-11-21 Thread Dale Curtis
Otherwise ff_alloc_extradata() just leaks any existing allocated
memory.

Signed-off-by: Dale Curtis 
From 15db35021f026296aba46699cc282d77bd1d295e Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 21 Nov 2017 15:10:08 -0800
Subject: [PATCH] [ogm] Free extradata before reallocating.

Otherwise ff_alloc_extradata() just leaks any existing allocated
memory.

Signed-off-by: Dale Curtis 
---
 libavformat/oggparseogm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index e7a501b5a7..fad093b629 100644
--- a/libavformat/oggparseogm.c
+++ b/libavformat/oggparseogm.c
@@ -110,6 +110,7 @@ ogm_header(AVFormatContext *s, int idx)
 size -= 52;
 if (bytestream2_get_bytes_left() < size)
 return AVERROR_INVALIDDATA;
+av_freep(>codecpar->extradata);
 if (ff_alloc_extradata(st->codecpar, size) < 0)
 return AVERROR(ENOMEM);
 bytestream2_get_buffer(, st->codecpar->extradata, st->codecpar->extradata_size);
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

2017-11-21 Thread Timo Rothenpieler

Am 21.11.2017 um 16:32 schrieb Mironov, Mikhail:

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


Are you all busy right now? Any hint on timing?
Thanks,
Mikhail


I cannot test this patch due to lack of hardware, but by now the code 
has been polished for a while, and if no further comments/issues come 
up, I'd be all for finally merging this.




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


Re: [FFmpeg-devel] libavcodec/huffyuvdsp(enc) : add avx2 version for add(diff)_int16

2017-11-21 Thread Michael Niedermayer
On Mon, Nov 20, 2017 at 10:07:11PM +0100, Martin Vignali wrote:
> 2017-11-04 19:31 GMT+01:00 Martin Vignali :
> 
> >
> >
> > 2017-10-22 0:26 GMT+02:00 Martin Vignali :
> >
> >> Hello,
> >>
> >> In attach patch to add avx2 version for huffyuv dsp and huffyuvdsp enc
> >> for add_int16 and diff_int16 func
> >>
> >> Check asm result for add_int16 (Kaby Lake, os 10.12)
> >> add_int16_128_c: 1607.9
> >> add_int16_128_sse2: 442.7
> >> add_int16_128_avx2: 218.9
> >>
> >> Pass fate test for me
> >>
> >>
> >> 0001-checkasm-add-test-for-huffyuvdsp-add_int16 :
> >> add a checkasm test for add_int16
> >> base on lossless_videodsp checkasm test
> >>
> >> i add a test with a fix size, to make speed test more easy to compare
> >>
> >> 0002-libavcodec-huffyuvdsp-enc-move-duplicate-macro-to-a-
> >> huffyuvdsp.asm and huffyuvdspenc.asm use the same INT16_LOOP macro
> >> with arg add for dec and sub for encoder
> >>
> >> this patch move this macro in an asm file in order to be share by both
> >> dsp asm
> >>
> >> 0003-libavcodec-huffyuvdsp-reorganize-add_int16-asm
> >> 0005-libavcodec-huffyuvdspenc-reorganize-diff_int16
> >> Code reorganization
> >>
> >>
> >> 0004-libavcodec-huffyuvdsp-add-add_int16-AVX2-func
> >> 0006-libavcodec-huffyuvdspenc-add-diff_int16-AVX2-func
> >> AVX2 version for each func
> >>
> >>
> >>
> >> ping
> >
> > Ping

as huffyuv in ffmpeg  maintainer, my oppinion is that iam happy about all
optimizations that make the code faster. Theres no need to wait for
some approval if you belive your code is correct ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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


[FFmpeg-devel] MXF AS-07 Guidelines

2017-11-21 Thread michael gates
Hello,



I was curious about any current or future plans to accept and integrate the
new AS-07 standard for MXF Archive and Preservation.
(Found at the link below:

http://www.digitizationguidelines.gov/guidelines/MXF_app_spec.html

Specifications:

http://www.digitizationguidelines.gov/guidelines/AS-07_20170908.pdf)



I have run their test files through a few tests, and was just curious what
ffmpeg's approach to the MXF wrapper according to the AS-07 guidelines is
going to be.

Kind regards,
-- 
*Mike Gates*
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

2017-11-21 Thread Marton Balint



On Thu, 9 Nov 2017, James Cowgill wrote:


Hi,

On 09/11/17 14:02, Hendrik Leppkes wrote:

On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill  wrote:

In commit 061a0c14bb57 ("decode: restructure the core decoding code"), the
deprecated avcodec_decode_* APIs were reworked so that they called into the
new avcodec_send_packet / avcodec_receive_frame API. This had the side effect
of prohibiting sending new packets containing data after a drain
packet, but in previous versions of FFmpeg this "worked" and some
applications relied on it.

To restore some compatibility, reset the codec if we receive a new non-drain
packet using the old API after draining has completed. While this does
not give the same behaviour as the old API did, in the majority of cases
it works and it does not require changes to any other part of the decoding
code.

Fixes ticket #6775
Signed-off-by: James Cowgill 
---
 libavcodec/decode.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 86fe5aef52..2f1932fa85 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
*frame,

 av_assert0(avci->compat_decode_consumed == 0);

+if (avci->draining_done && pkt && pkt->size != 0) {
+av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n");
+avcodec_flush_buffers(avctx);
+}
+


I don't think this is a good idea. Draining and not flushing
afterwards is a bug in the calling code, and even before recent
changes it would result in inconsistent behavior and even crashes
(with select decoders).


I am fully aware that this will only trigger if the calling code is
buggy. I am trying to avoid silent breakage of those applications doing
this when upgrading to ffmpeg 3.4.

I was looking at the documentation of avcodec_decode_* recently because
of this and I had some trouble deciding if using the API this way was
incorrect. I expect the downstreams affected thought that what they were
doing was fine and then got angry when ffmpeg suddenly "broke" their
code. This patch at least allows some sort of "transitional period"
until downstreams update.


I think the intent was to flush the codec by passing the NULL packets to 
it, so it makes a lot of sense to actually do that. Especially since by 
implicitly doing a flush, we can avoid the undefined behaviour/crashes on 
the codec side.


Also this is only compatibility code, which probably will be removed at 
the next bump, I see no harm in making it as compatible as realistically 
possible.


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


[FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-21 Thread Jim DeLaHunt
Previously, the Developer Documentation
 contained a single chapter,
1. Developer Guide, with all content under that single
chapter. Thus the document structure was one level deeper
and more complicated than it needed to be.  It differed
from similar documents such as /faq.html, which have
multiple chapters.

Also, the Developer Documentation had instructions to
subscribe to the ffmpeg-cvslog email list. But that is
no longer accurate. For the purposes in this section --
review of patches, discussion of development issues --
ffmpeg_devel is the appropriate email list.

1. Eliminate the single chapter, and promote each section
underneath to chapter, and each subsection to section.
Thus content and relative structure remains the same,
but the overall structure is simpler.  Anchors within the
page remain the same.

2. Change ffmpeg-cvslog to ffmpeg-devel, and rewrite the
wording of that section to match the current usage of
ffmpeg-devel and to flow smoothly.

I believe there were no links to the eliminated "Developer
Documentation" chapter, based on a search of the source
code.

There are a lot of improvements possible to the
Developer Documentation page, beyond this refactoring.
However, making those improvements is a much bigger
and more difficult task.  This change is "low hanging
fruit".

Signed-off-by: Jim DeLaHunt 
---
 doc/developer.texi | 69 +-
 1 file changed, 37 insertions(+), 32 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a7b4f1d737..9ac825ea5d 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -10,9 +10,7 @@
 
 @contents
 
-@chapter Developers Guide
-
-@section Notes for external developers
+@chapter Notes for external developers
 
 This document is mostly useful for internal FFmpeg developers.
 External developers who need to use the API in their application should
@@ -30,7 +28,7 @@ For more detailed legal information about the use of FFmpeg in
 external programs read the @file{LICENSE} file in the source tree and
 consult @url{https://ffmpeg.org/legal.html}.
 
-@section Contributing
+@chapter Contributing
 
 There are 3 ways by which code gets into FFmpeg.
 @itemize @bullet
@@ -47,9 +45,9 @@ The developer making the commit and the author are 
responsible for their changes
 and should try to fix issues their commit causes.
 
 @anchor{Coding Rules}
-@section Coding Rules
+@chapter Coding Rules
 
-@subsection Code formatting conventions
+@section Code formatting conventions
 
 There are the following guidelines regarding the indentation in files:
 
@@ -74,7 +72,7 @@ The presentation is one inspired by 'indent -i4 -kr -nut'.
 The main priority in FFmpeg is simplicity and small code size in order to
 minimize the bug count.
 
-@subsection Comments
+@section Comments
 Use the JavaDoc/Doxygen  format (see examples below) so that code documentation
 can be generated automatically. All nontrivial functions should have a comment
 above them explaining what the function does, even if it is just one sentence.
@@ -114,7 +112,7 @@ int myfunc(int my_parameter)
 ...
 @end example
 
-@subsection C language features
+@section C language features
 
 FFmpeg is programmed in the ISO C90 language with a few additional
 features from ISO C99, namely:
@@ -160,7 +158,7 @@ mixing statements and declarations;
 GCC statement expressions (@samp{(x = (@{ int y = 4; y; @})}).
 @end itemize
 
-@subsection Naming conventions
+@section Naming conventions
 All names should be composed with underscores (_), not CamelCase. For example,
 @samp{avfilter_get_video_buffer} is an acceptable function name and
 @samp{AVFilterGetVideo} is not. The exception from this are type names, like
@@ -204,7 +202,7 @@ letter as they are reserved by the C standard. Names 
starting with @code{_}
 are reserved at the file level and may not be used for externally visible
 symbols. If in doubt, just avoid names starting with @code{_} altogether.
 
-@subsection Miscellaneous conventions
+@section Miscellaneous conventions
 
 @itemize @bullet
 @item
@@ -216,7 +214,7 @@ Casts should be used only when necessary. Unneeded 
parentheses
 should also be avoided if they don't make the code easier to understand.
 @end itemize
 
-@subsection Editor configuration
+@section Editor configuration
 In order to configure Vim to follow FFmpeg formatting conventions, paste
 the following snippet into your @file{.vimrc}:
 @example
@@ -249,9 +247,9 @@ For Emacs, add these roughly equivalent lines to your 
@file{.emacs.d/init.el}:
 (setq c-default-style "ffmpeg")
 @end lisp
 
-@section Development Policy
+@chapter Development Policy
 
-@subsection Patches/Committing
+@section Patches/Committing
 @subheading Licenses for patches must be compatible with FFmpeg.
 Contributions should be licensed under the
 @uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
@@ -350,7 +348,7 @@ time-frame (12h for build failures and security fixes, 3 
days small changes,
 1 

[FFmpeg-devel] avcodec/x86/exrdsp : use ymm constant for pb_80 instead of vbroadcasti128

2017-11-21 Thread Martin Vignali
Hello,

After patch by James Almer
(pb_80 now fit an ymm)

The two mode (SSE, AVX2) for constant loading can be remove

speed seems to be similar to me

Martin


0002-avcodec-x86-exrdsp-use-ymm-constant-for-pb_80.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] checkasm/utvideo : be more explicit for WIDTH_PADDED define

2017-11-21 Thread Martin Vignali
Hello,

Patch in attach

Martin


0001-checkasm-utvideo-be-more-explicit-to-the-WIDTH_PADDE.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] RPM library deployments

2017-11-21 Thread Gardner, Greg - 0995 - MITLL
Lou,
I dug a bit further and saw that "RPMFusion" packaged the rpm.  I'll contact 
them!
--Greg

-Original Message-
From: Lou Logan [mailto:l...@lrcd.com]
Sent: Saturday, November 18, 2017 2:46 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Gardner, Greg - 0995 - MITLL 
Subject: Re: [FFmpeg-devel] RPM library deployments

On Fri, Nov 17, 2017, at 01:10 PM, Gardner, Greg - 0995 - MITLL wrote:
> Hey folks,
>
> Could someone put me in touch with whoever builds the ffmpeg-libs RPM?

It's not from us, a third-party makes that, but I'm not sure who. FFmpeg only 
provides source code.



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


Re: [FFmpeg-devel] libavcodec/utvideodsp : add avx2 version

2017-11-21 Thread Martin Vignali
Hello,

>
> > Checkasm result (Kaby Lake, os 10.12)
> > restore_rgb_planes_c: 8371.0
> > restore_rgb_planes_sse2: 6583.7
> > restore_rgb_planes_avx2: 3596.5
> >
> > restore_rgb_planes10_c: 16735.7
> > restore_rgb_planes10_sse2: 11478.5
> > restore_rgb_planes10_avx2: 7193.7
>
> Curious, on my Haswell (mingw-w64 Win10) i get
>
> restore_rgb_planes_c: 79500.7
> restore_rgb_planes_sse2: 6872.7
> restore_rgb_planes_avx2: 6715.7
>
> restore_rgb_planes10_c: 91394.7
> restore_rgb_planes10_sse2: 14494.0
> restore_rgb_planes10_avx2: 13468.7
>
> I check again, i have the same kind of result, than before
Strange, that the speed improvment is so small in Haswell


> >
> >
> > Pass fate test for me
> >
> >
> > 0001-checkasm-add-utvideodsp-test :
> > I'm not entirely sure of mine, for this checkasm,
> >
> > 0002-libavcodec-x86-utvideodsp-make-macro-for-func
> > Code reorganization
> >
> > 0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp
> > AVX2 version
> >
> > 0004-libavcodec-x86-utvideodsp.asm-cosmetic
> > Cosmetic
> >
> > Martin
> > Jokyo Images
>
> Sorry i missed this set. The asm changes look simple and good. Only
> thing I'd have done was making sure the constants were wide enough to
> avoid having to use vpbroadcast instructions.
> I noticed for that matter that said constants already exist in
> constants.c, so i just made it use them instead.
>

Thanks for all the fix.

Your comments, for the use of vpbroadcast for constantes load,
seems similar to a previous comment by James Darnley (in discussion
libavcodec/bswapdsp : add AVX2 for bswap_buf)
I use here the same way use by Henrik Gramner in exr_dsp.predictor func
(but i'm ok to modify that part if need)


Do you think we need to replace all

%if cpuflag(avx2)
vbroadcasti128  mm, [constantes]
%else
mova mm, [constantes]
%endif

by your method ? (for exr_dsp, the answer is probably yes, because it's
also use pb_80 (i will send a patch for that))

If yes, is it better to use in asm (for example for bswapdsp)

SECTION_RODATA 32
pb_bswap32: times 2 db 3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 15, 14, 13, 12

or adding a constantes (if not exists), in constant.c/h ?

Seems like this case will be common for AVX2 version of dsp func.



>
> The checkasm test is a bit ugly and could use some cosmetics, though.
>
>
Except one thing, (WIDTH_PADDED calc is strange (doesn't remember why i
write this, and only works by "luck"), need to be WIDTH + 16

Do you think, it's need more modification (considering your recent patchs) ?


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


Re: [FFmpeg-devel] [PATCH] fix bug in af_pan channel coefficient parser

2017-11-21 Thread Michael Niedermayer
On Tue, Nov 21, 2017 at 02:24:23PM +0100, Tobias Rapp wrote:
> On 20.11.2017 22:15, Michael Niedermayer wrote:
> >On Mon, Nov 20, 2017 at 05:14:15PM +0100, Nicolas George wrote:
> >>Tobias Rapp (2017-11-20):
> >>>Would it be OK to backport the fix into release/3.4? I can do the
> >>>cherry-picking but am unsure about the policies and what other older
> >>>releases should possibly be adapted, too.
> >>
> >>I do not know how backporting to releases work either, but I have of
> >>course no objection in principle.
> >
> >simple cherry pick with the hex hash in the commit message (-x)
> >test if it still all works and push
> 
> Backported the fix to release/3.4
> 
> Not sure what other releases are still maintained as the list within
> the MAINTAINERS file looks outdated (2.5 to 2.8).

The ones we list on the download page should be updated if they are
affected


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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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


Re: [FFmpeg-devel] FFmpeg 3.4.1

2017-11-21 Thread Michael Niedermayer
On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote:
> > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > >>  wrote:
> > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > >> >> :
> > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > >> >> >> :
> > >> >> >> > Hi all
> > >> >> >> >
> > >> >> >> > I intend to make 3.4.1 very soon
> > >> >> >>
> > >> >> >> Shouldn't we first decide on how to proceed with #6775?
> > >> >> >
> > >> >> > This would be ideal.
> > >> >> >
> > >> >> > IIUC this is a regression from 
> > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04
> > >> >>
> > >> >> This was confirmed by more than one developer, yes.
> > >> >>
> > >> >> > I see a patch that is said to improve 6775, can that be applied and
> > >> >> > would that resolve this ?
> > >> >>
> > >> >> Iiuc, it would not completely resolve the issue, see:
> > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > >> >>
> > >> >> > If so why was it not applied yet ?
> > >> >>
> > >> >> The patch did not get support here, see:
> > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> > >> >> in compat_decode
> > >> >
> > >> >
> > >> > Is someone working on fixing this better than with the available patch 
> > >> > ?
> > >> >
> > >>
> > >> I don't even agree this needs fixing. Those projects use the API wrong.
> > >
> > > Had we documented the correct/wrong use precissely in the past when
> > > these wrong uses where written ?
> > >
> > > Because if it was documented then few should have made the mistake.
> > > But it seems this affects multiple projects, so i wonder if our API
> > > really excluded the use
> > >
> > 
> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> > 
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> > 
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
> > avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> > longer
> >  * returns frames.
> > 
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> > 
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> > 
> 
> > For the suggested patch, draining and flushing in the middle of a
> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked).
> 
> Did the previous code really work if the frame after a flush was not a
> new keyframe or there was some use of previous references ?

ping

so what is the status of this?

Ticket 6775 is still open, neither a workaround was applied nor was
it closed as invalid. Only one workaround was proposed which was
claimed to be worse than the code before.
It seems the discussion died down.
If theres no activity on this in the next days then i intend to make
the release with whats in release/3.4 at the time. I dont think
blind waiting will do any good, id rather release early and often ...

Also if someone wants to write some release notes about this issue,
that is IMO a good idea ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] Refund request of travel costs for GSoC Summit 2017

2017-11-21 Thread Stefano Sabatini
On Mon, Nov 20, 2017 at 1:58 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-18 18:26 GMT+01:00 Thilo Borgmann :
>
> > some time ago Carl Eugen and me went to the GSoC Summit.
> > See review mail for details.
> >
> > Here comes the refund request for my flight. Costs were 478.82€ total
>
> I have sent my invoice over 932,27€ to Stefano.
>

Approved by me. Will forward the request to SPI when Michael approves it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Refund request of travel costs for GSoC Summit 2017

2017-11-21 Thread Stefano Sabatini
On Sat, Nov 18, 2017 at 6:26 PM, Thilo Borgmann 
wrote:

> Hi,
>
> some time ago Carl Eugen and me went to the GSoC Summit. See review mail
> for details.
>
> Here comes the refund request for my flight. Costs were 478.82€ total,
> I'll send the invoice to Stefano privately as usual.
>

Approved by me, still missing approval from Michael.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Refund request for FFshirt merchandise

2017-11-21 Thread Lou Logan
On Tue, Nov 21, 2017, at 08:50 AM, Thilo Borgmann wrote:
> Hi,
> 
> here comes the refund request for getting us developer T-shirts and
> sending them around the world as well as getting a stock of T-shirts for
> future developers to come and for giveaways at conferences and to honored
> users:
> 
> 
> ItemNo  Cost
> Shirt Samples672,00€
> Shirts (Thomas) 19   228,00€
> Shirts (Lou)25   300,00€
> Shipping1885,69€
> 
> Total685,69€
> 
> See the corresponding thread for more details. Will send all the invoices
> to Stefano privately (at least I hope so this time).
> 
> Thanks,
> Thilo

OK with me. €12 each isn't bad for what I'm assuming are locally made
shirts.

I wonder what the status of our hoard is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] Refund request for FFshirt merchandise

2017-11-21 Thread Thilo Borgmann
Hi,

here comes the refund request for getting us developer T-shirts and sending 
them around the world as well as getting a stock of T-shirts for future 
developers to come and for giveaways at conferences and to honored users:


ItemNo  Cost
Shirt Samples672,00€
Shirts (Thomas) 19   228,00€
Shirts (Lou)25   300,00€
Shipping1885,69€

Total685,69€

See the corresponding thread for more details. Will send all the invoices to 
Stefano privately (at least I hope so this time).

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


Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add queue option

2017-11-21 Thread Paul B Mahol
On 11/19/17, Nicolas George  wrote:
> Thilo Borgmann (2017-11-19):
>> Based on Dave's example I'd say the queue parameter defines the
>> minimum of available tiles before output is generated.
>>
>> 'queue' -> 'min'
>> 'queue' -> 'min_tiles'
>> 'queue' -> 'min_available'
>>
>> I'd suggest something like that.
>
> "min" would imply a global minimum, the names you suggest do not contain
> anything that suggests it applies only at the beginning, and neither
> does "queue". I stick with "init_padding".

This "clash" with padding option, and may confuse users.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] order T-shirts

2017-11-21 Thread Thilo Borgmann
Hi,

>>> My suggestion would be, that we could order Thomas' design for all
>>> the developers and requests I've recieved by now and that we take
>>> Lou's for our stock for give-aways during conferences. Just my
>>> thinking...
>>
>> no further comments so I did order alike. Should recieve them next week and 
>> the first of you will have their shirts soon thereafter.
> 
> today, all shirts are ready for shipping. I'll send them away early next week.

all packages are on their way now!

We have now quite some few shirts in stock in Lou's design (-1 for Lou 
himself). Find all the numbers in this thread.

Will request reimbursement separately. I'd appreciate feedback once your 
package arrived.

Thanks,
Thilo 

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


Re: [FFmpeg-devel] [PATCH] avfilter/avf_showwaves: add draw grid support

2017-11-21 Thread Paul B Mahol
On 11/21/17, Dave Rice  wrote:
>
>> On Nov 21, 2017, at 7:36 AM, Paul B Mahol  wrote:
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>> doc/filters.texi|  6 ++
>> libavfilter/avf_showwaves.c | 28 
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 62f633c6f8..9c98f1684b 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -19178,6 +19178,12 @@ Cubic root.
>> @end table
>>
>> Default is linear.
>> +
>> +@item grid
>> +Draw grid, default is disabled.
>> +
>> +@item grid_color
>> +Set grid color.
>> @end table
>>
>> @subsection Examples
>> diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
>> index 0866967984..74d4886cd4 100644
>> --- a/libavfilter/avf_showwaves.c
>> +++ b/libavfilter/avf_showwaves.c
>> @@ -69,6 +69,8 @@ typedef struct ShowWavesContext {
>> int mode;   ///< ShowWavesMode
>> int scale;  ///< ShowWavesScale
>> int split_channels;
>> +int grid;
>> +uint8_t grid_rgba[4];
>> uint8_t *fg;
>>
>> int (*get_h)(int16_t sample, int height);
>> @@ -104,6 +106,8 @@ static const AVOption showwaves_options[] = {
>> { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG},
>> .flags=FLAGS, .unit="scale"},
>> { "sqrt", "square root",   0, AV_OPT_TYPE_CONST,
>> {.i64=SCALE_SQRT}, .flags=FLAGS, .unit="scale"},
>> { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST,
>> {.i64=SCALE_CBRT}, .flags=FLAGS, .unit="scale"},
>> +{ "grid", "draw grid", OFFSET(grid), AV_OPT_TYPE_BOOL, {.i64=0}, 0,
>> 1, FLAGS },
>> +{ "grid_color", "set grid color", OFFSET(grid_rgba),
>> AV_OPT_TYPE_COLOR, {.str="0x00"}, 0, 0, FLAGS },
>> { NULL }
>> };
>>
>> @@ -562,6 +566,30 @@ static int alloc_out_frame(ShowWavesContext
>> *showwaves, const int16_t *p,
>>   outlink->time_base);
>> for (j = 0; j < outlink->h; j++)
>> memset(out->data[0] + j*out->linesize[0], 0, outlink->w *
>> showwaves->pixstep);
>> +
>> +if (showwaves->grid) {
>> +const int pixstep = showwaves->pixstep;
>> +int ystep = showwaves->split_channels ? outlink->h /
>> inlink->channels / 4 : outlink->h / 4;
>> +int channels = showwaves->split_channels ? inlink->channels :
>> 1;
>> +int x, s, c, yskip = 0;
>> +
>> +for (c = 0; c < channels; c++) {
>> +for (j = 0; j < 4; j++) {
>> +for (x = 0; x < outlink->w; x+=3) {
>> +for (s = 0; s < pixstep; s++) {
>> +out->data[0][(yskip + j * ystep) *
>> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
>> +}
>> +}
>> +}
>> +for (x = 0; x < outlink->w; x+=3) {
>> +for (s = 0; s < pixstep; s++) {
>> +out->data[0][(yskip + j * ystep - 1) *
>> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
>> +}
>> +}
>> +
>> +yskip += j * ystep;
>> +}
>> +}
>> }
>> return 0;
>> }
>> --
>> 2.11.0
>
> Seems interesting but do the gridlines convey any meaning? Perhaps a flags
> value too similar to waveform that should label the lines in dB or as a
> float. Also perhaps worth adjustment the placement of the gridlines
> depending on a scale (log vs lin).

That would be quite messy for log at least.
The meaning is to find out where is 0, 0.5, -0.5, -1 and 1 in linear scale.

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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-21 Thread Michael Niedermayer
On Mon, Nov 20, 2017 at 08:10:36PM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 20 Nov 2017 22:53:00 +0100
> Michael Niedermayer  wrote:
> 
> > On Sun, Nov 19, 2017 at 11:52:28AM -0800, Philip Langdale wrote:
> > > This was predictably nightmarish, given how ridiculous mpeg4 is.
> > > I had to stare at the cuvid parser output for a long time to work
> > > out what each field was supposed to be, and even then, I still don't
> > > fully understand some of them, particularly:
> > > 
> > > vop_coded: I think this means whether the vop has a picture shape,
> > >and therefore a picture type. I have no samples where
> > >this is not the case.
> > > divx_flags: There's obviously no documentation on what the possible
> > > flags are. I simply observed that this is '0' for a
> > > normal bitstream and '5' for packed b-frames.  
> > 
> > > gmc_enabled: This seems to map to mc_sel being non-zero, but I also
> > >  have no samples where that is true.  
> > 
> > issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
> > seems to use gmc, didnt check how compex or trivial its use is
> > 
> > [...]
> 
> I think it's as complex as you can get, and the nvidia decoder cannot
> handle it properly. With vdpau, cuvid and now nvdec, there are a lot of
> visual glitches. Interestingly, the resutls with nvdec are better than
> cuvid, so not using the nvidia parser somehow makes things less worse.
> 
> I'd love to try a single warp point sample but can't find or generate
> one.

Heres one with 2 wrap points:
~/tickets/1180/GoneNutty.avi

you can find a 1 point gmc with, iam sure we had such samples but it
seems i couldnt quickly find one

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 69f455e226..e0c904707e 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -1883,6 +1883,10 @@ static int decode_vol_header(Mpeg4DecContext *ctx, 
GetBitContext *gb)
 check_marker(s->avctx, gb, "after sprite_top");
 }
 ctx->num_sprite_warping_points = get_bits(gb, 6);
+if (ctx->num_sprite_warping_points!=3 && 
ctx->num_sprite_warping_points!=2 && ctx->num_sprite_warping_points){
+av_log(0,0, "XXX %d\n", ctx->num_sprite_warping_points);
+abort();
+}
 if (ctx->num_sprite_warping_points > 3) {
 av_log(s->avctx, AV_LOG_ERROR,
"%d sprite_warping_points\n",

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

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



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


Re: [FFmpeg-devel] [PATCH] avfilter/avf_showwaves: add draw grid support

2017-11-21 Thread Dave Rice

> On Nov 21, 2017, at 7:36 AM, Paul B Mahol  wrote:
> 
> Signed-off-by: Paul B Mahol 
> ---
> doc/filters.texi|  6 ++
> libavfilter/avf_showwaves.c | 28 
> 2 files changed, 34 insertions(+)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 62f633c6f8..9c98f1684b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19178,6 +19178,12 @@ Cubic root.
> @end table
> 
> Default is linear.
> +
> +@item grid
> +Draw grid, default is disabled.
> +
> +@item grid_color
> +Set grid color.
> @end table
> 
> @subsection Examples
> diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
> index 0866967984..74d4886cd4 100644
> --- a/libavfilter/avf_showwaves.c
> +++ b/libavfilter/avf_showwaves.c
> @@ -69,6 +69,8 @@ typedef struct ShowWavesContext {
> int mode;   ///< ShowWavesMode
> int scale;  ///< ShowWavesScale
> int split_channels;
> +int grid;
> +uint8_t grid_rgba[4];
> uint8_t *fg;
> 
> int (*get_h)(int16_t sample, int height);
> @@ -104,6 +106,8 @@ static const AVOption showwaves_options[] = {
> { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
> .flags=FLAGS, .unit="scale"},
> { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
> .flags=FLAGS, .unit="scale"},
> { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
> .flags=FLAGS, .unit="scale"},
> +{ "grid", "draw grid", OFFSET(grid), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, 
> FLAGS },
> +{ "grid_color", "set grid color", OFFSET(grid_rgba), AV_OPT_TYPE_COLOR, 
> {.str="0x00"}, 0, 0, FLAGS },
> { NULL }
> };
> 
> @@ -562,6 +566,30 @@ static int alloc_out_frame(ShowWavesContext *showwaves, 
> const int16_t *p,
>   outlink->time_base);
> for (j = 0; j < outlink->h; j++)
> memset(out->data[0] + j*out->linesize[0], 0, outlink->w * 
> showwaves->pixstep);
> +
> +if (showwaves->grid) {
> +const int pixstep = showwaves->pixstep;
> +int ystep = showwaves->split_channels ? outlink->h / 
> inlink->channels / 4 : outlink->h / 4;
> +int channels = showwaves->split_channels ? inlink->channels : 1;
> +int x, s, c, yskip = 0;
> +
> +for (c = 0; c < channels; c++) {
> +for (j = 0; j < 4; j++) {
> +for (x = 0; x < outlink->w; x+=3) {
> +for (s = 0; s < pixstep; s++) {
> +out->data[0][(yskip + j * ystep) * 
> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
> +}
> +}
> +}
> +for (x = 0; x < outlink->w; x+=3) {
> +for (s = 0; s < pixstep; s++) {
> +out->data[0][(yskip + j * ystep - 1) * 
> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
> +}
> +}
> +
> +yskip += j * ystep;
> +}
> +}
> }
> return 0;
> }
> -- 
> 2.11.0

Seems interesting but do the gridlines convey any meaning? Perhaps a flags 
value too similar to waveform that should label the lines in dB or as a float. 
Also perhaps worth adjustment the placement of the gridlines depending on a 
scale (log vs lin).
Dave Rice

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


Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

2017-11-21 Thread Mironov, Mikhail
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Are you all busy right now? Any hint on timing?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

2017-11-21 Thread Steven Liu
2017-11-21 12:54 GMT+08:00 Karthick J :
> ---
>  doc/muxers.texi  |  3 +++
>  libavformat/hlsenc.c | 48 +---
>  2 files changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 0bb8ad2..c1d753b 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -850,6 +850,9 @@ ffmpeg -re -i in.ts -f hls -master_pl_name master.m3u8 \
>  This example creates HLS master playlist with name master.m3u8 and keep
>  publishing it repeatedly every after 30 segments i.e. every after 60s.
>
> +@item http_persistent
> +Use persistent HTTP connections. Applicable only for HTTP output.
> +
>  @end table
>
>  @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 3c47ced..32c99a0 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -45,6 +45,7 @@
>
>  #include "avformat.h"
>  #include "avio_internal.h"
> +#include "http.h"
>  #include "internal.h"
>  #include "os_support.h"
>
> @@ -204,6 +205,7 @@ typedef struct HLSContext {
>  char *var_stream_map; /* user specified variant stream map string */
>  char *master_pl_name;
>  unsigned int master_publish_rate;
> +int http_persistent;
>  } HLSContext;
>
>  static int get_int_from_double(double val)
> @@ -244,10 +246,38 @@ static int mkdir_p(const char *path) {
>  return ret;
>  }
>
> +static int is_http_proto(char *filename) {
> +const char *proto = avio_find_protocol_name(filename);
> +return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
> "https")) : 0;
> +}
> +
> +static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char 
> *filename,
> +  AVDictionary **options) {
> +HLSContext *hls = s->priv_data;
> +int http_base_proto = is_http_proto(filename);
> +int err;
> +if (*pb == NULL || !http_base_proto || !hls->http_persistent) {
What about !*pb ?
> +err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
> +} else {
> +URLContext *http_url_context = ffio_geturlcontext(*pb);
> +av_assert0(http_url_context);
> +err = ff_http_do_new_request(http_url_context, filename);
> +}
> +return err;
> +}
> +
> +static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
> *filename) {
> +HLSContext *hls = s->priv_data;
> +int http_base_proto = is_http_proto(filename);
> +
> +if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
> hls->encrypt) {
> +ff_format_io_close(s, pb);
> +}
> +}
> +
>  static void set_http_options(AVFormatContext *s, AVDictionary **options, 
> HLSContext *c)
>  {
> -const char *proto = avio_find_protocol_name(s->filename);
> -int http_base_proto = proto ? (!av_strcasecmp(proto, "http") || 
> !av_strcasecmp(proto, "https")) : 0;
> +int http_base_proto = is_http_proto(s->filename);
>
>  if (c->method) {
>  av_dict_set(options, "method", c->method, 0);
> @@ -257,6 +287,8 @@ static void set_http_options(AVFormatContext *s, 
> AVDictionary **options, HLSCont
>  }
>  if (c->user_agent)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
> +if (c->http_persistent)
> +av_dict_set_int(options, "multiple_requests", 1, 0);
>
>  }
>
> @@ -1430,17 +1462,17 @@ static int hls_start(AVFormatContext *s, 
> VariantStream *vs)
>  err = AVERROR(ENOMEM);
>  goto fail;
>  }
> -err = s->io_open(s, >pb, filename, AVIO_FLAG_WRITE, );
> +err = hlsenc_io_open(s, >pb, filename, );
>  av_free(filename);
>  av_dict_free();
>  if (err < 0)
>  return err;
>  } else
> -if ((err = s->io_open(s, >pb, oc->filename, AVIO_FLAG_WRITE, 
> )) < 0)
> +if ((err = hlsenc_io_open(s, >pb, oc->filename, )) < 0)
>  goto fail;
>  if (vs->vtt_basename) {
>  set_http_options(s, , c);
> -if ((err = s->io_open(s, _oc->pb, vtt_oc->filename, 
> AVIO_FLAG_WRITE, )) < 0)
> +if ((err = hlsenc_io_open(s, _oc->pb, vtt_oc->filename, 
> )) < 0)
>  goto fail;
>  }
>  av_dict_free();
> @@ -2148,11 +2180,12 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  avio_open_dyn_buf(>pb);
>  vs->packets_written = 0;
>  ff_format_io_close(s, >out);
> +hlsenc_io_close(s, >out, vs->base_output_dirname);
>  } else {
> -ff_format_io_close(s, >pb);
> +hlsenc_io_close(s, >pb, oc->filename);
>  }
>  if (vs->vtt_avf) {
> -ff_format_io_close(s, >vtt_avf->pb);
> +hlsenc_io_close(s, >vtt_avf->pb, vs->vtt_avf->filename);
>  }
>  }
>  if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
> @@ -2337,6 +2370,7 @@ static const AVOption options[] = {
>  {"var_stream_map", "Variant 

Re: [FFmpeg-devel] libavcodec/utvideodsp : add avx2 version

2017-11-21 Thread James Almer
On 10/22/2017 9:05 AM, Martin Vignali wrote:
> Hello,
> 
> In attach patch to add AVX2 version for the utvideodsp
> 
> Checkasm result (Kaby Lake, os 10.12)
> restore_rgb_planes_c: 8371.0
> restore_rgb_planes_sse2: 6583.7
> restore_rgb_planes_avx2: 3596.5
> 
> restore_rgb_planes10_c: 16735.7
> restore_rgb_planes10_sse2: 11478.5
> restore_rgb_planes10_avx2: 7193.7

Curious, on my Haswell (mingw-w64 Win10) i get

restore_rgb_planes_c: 79500.7
restore_rgb_planes_sse2: 6872.7
restore_rgb_planes_avx2: 6715.7

restore_rgb_planes10_c: 91394.7
restore_rgb_planes10_sse2: 14494.0
restore_rgb_planes10_avx2: 13468.7

> 
> 
> Pass fate test for me
> 
> 
> 0001-checkasm-add-utvideodsp-test :
> I'm not entirely sure of mine, for this checkasm,
> 
> 0002-libavcodec-x86-utvideodsp-make-macro-for-func
> Code reorganization
> 
> 0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp
> AVX2 version
> 
> 0004-libavcodec-x86-utvideodsp.asm-cosmetic
> Cosmetic
> 
> Martin
> Jokyo Images

Sorry i missed this set. The asm changes look simple and good. Only
thing I'd have done was making sure the constants were wide enough to
avoid having to use vpbroadcast instructions.
I noticed for that matter that said constants already exist in
constants.c, so i just made it use them instead.

The checkasm test is a bit ugly and could use some cosmetics, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] 8-bit hevc decoding optimization on aarch64 with neon

2017-11-21 Thread Rafal Dabrowa

On 11/21/2017 11:51 AM, Shengbin Meng wrote:


On 19 Nov 2017, at 01:35, Rafal Dabrowa > wrote:



This is a proposal of performance optimizations for 8-bit
hevc video decoding on aarch64 platform with neon (simd) extension.


Nice to see the work for aarch64!

We are also in the process of doing NEON optimization for HEVC 
decoding. 
(http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218233.html)


Now we are just about to finish arm 32-bit work and ready to send some 
patches out. Looks like for aarch64 we can join force:) What do you think?
Why not. I started to work on aarch64 because my device, although has 
VPU, but the VPU does not support hevc. Hence the h264 format, even full 
HD one is played smoothly but playback of hevc looks poorly. I was 
curious how much hevc decoding might be optimized. I optimized one 
function, then another one...


Currently I'm focused on patch size reduction. But I'm open to cooperation.





The patch contains optimizations for most heavily used qpel, epel, 
sao and idct

functions.  Among the functions provided for optimization there are two
intensively used, but not optimized in this patch: 
hevc_v_loop_filter_luma_8

and hevc_h_loop_filter_luma_8. I have no idea how they could be optimized
hence I leaved them without optimizations.



I see that optimization for loop filter already exists for arm 32-bit 
code. Why not use that algorithm?


Maybe... Although optimization for aarch64 is a different story. I have 
noticed that gcc with -O3 option on aarch64 produces really good code. I 
was surprised how much the code execution time is reduced in some cases. 
Sometimes it is hard to optimize code better than compiler does.



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


Re: [FFmpeg-devel] [PATCH] fix bug in af_pan channel coefficient parser

2017-11-21 Thread Tobias Rapp

On 20.11.2017 22:15, Michael Niedermayer wrote:

On Mon, Nov 20, 2017 at 05:14:15PM +0100, Nicolas George wrote:

Tobias Rapp (2017-11-20):

Would it be OK to backport the fix into release/3.4? I can do the
cherry-picking but am unsure about the policies and what other older
releases should possibly be adapted, too.


I do not know how backporting to releases work either, but I have of
course no objection in principle.


simple cherry pick with the hex hash in the commit message (-x)
test if it still all works and push


Backported the fix to release/3.4

Not sure what other releases are still maintained as the list within the 
MAINTAINERS file looks outdated (2.5 to 2.8).


Regards,
Tobias

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


[FFmpeg-devel] [PATCH] avfilter/avf_showwaves: add draw grid support

2017-11-21 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 doc/filters.texi|  6 ++
 libavfilter/avf_showwaves.c | 28 
 2 files changed, 34 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 62f633c6f8..9c98f1684b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19178,6 +19178,12 @@ Cubic root.
 @end table
 
 Default is linear.
+
+@item grid
+Draw grid, default is disabled.
+
+@item grid_color
+Set grid color.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0866967984..74d4886cd4 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -69,6 +69,8 @@ typedef struct ShowWavesContext {
 int mode;   ///< ShowWavesMode
 int scale;  ///< ShowWavesScale
 int split_channels;
+int grid;
+uint8_t grid_rgba[4];
 uint8_t *fg;
 
 int (*get_h)(int16_t sample, int height);
@@ -104,6 +106,8 @@ static const AVOption showwaves_options[] = {
 { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
.flags=FLAGS, .unit="scale"},
 { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
.flags=FLAGS, .unit="scale"},
 { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
.flags=FLAGS, .unit="scale"},
+{ "grid", "draw grid", OFFSET(grid), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, 
FLAGS },
+{ "grid_color", "set grid color", OFFSET(grid_rgba), AV_OPT_TYPE_COLOR, 
{.str="0x00"}, 0, 0, FLAGS },
 { NULL }
 };
 
@@ -562,6 +566,30 @@ static int alloc_out_frame(ShowWavesContext *showwaves, 
const int16_t *p,
   outlink->time_base);
 for (j = 0; j < outlink->h; j++)
 memset(out->data[0] + j*out->linesize[0], 0, outlink->w * 
showwaves->pixstep);
+
+if (showwaves->grid) {
+const int pixstep = showwaves->pixstep;
+int ystep = showwaves->split_channels ? outlink->h / 
inlink->channels / 4 : outlink->h / 4;
+int channels = showwaves->split_channels ? inlink->channels : 1;
+int x, s, c, yskip = 0;
+
+for (c = 0; c < channels; c++) {
+for (j = 0; j < 4; j++) {
+for (x = 0; x < outlink->w; x+=3) {
+for (s = 0; s < pixstep; s++) {
+out->data[0][(yskip + j * ystep) * 
out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
+}
+}
+}
+for (x = 0; x < outlink->w; x+=3) {
+for (s = 0; s < pixstep; s++) {
+out->data[0][(yskip + j * ystep - 1) * 
out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
+}
+}
+
+yskip += j * ystep;
+}
+}
 }
 return 0;
 }
-- 
2.11.0

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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-21 Thread Moritz Barsnick
On Tue, Nov 21, 2017 at 21:45:00 +1100, Richard Ling wrote:
> Updated patch.

Nice. I personally appreciate your code comments, as I'm no big filter
author (yet).

>  doc/filters.texi   |  80 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_normalize.c | 389 
> +
>  4 files changed, 471 insertions(+)

I *believe* adding a new filter requires a Changelog entry and a
version bump, but the filter maintainers will confirm that.

> +#define MAX_HISTORY_LEN 0x1

Unused?

> +// This function is the main guts of the filter. Normalizes the input frame

Isn't "gut" the singular form? SCNR ;-)

> +if (s->history_mem != NULL)
> +av_free(s->history_mem);

No NULL check necessary, see av_free() docs.

I can't say much about the rest, leaving that to others.

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


Re: [FFmpeg-devel] [PATCH] 8-bit hevc decoding optimization on aarch64 with neon

2017-11-21 Thread Shengbin Meng

> On 19 Nov 2017, at 01:35, Rafal Dabrowa  wrote:
> 
> 
> This is a proposal of performance optimizations for 8-bit
> hevc video decoding on aarch64 platform with neon (simd) extension.

Nice to see the work for aarch64! 

We are also in the process of doing NEON optimization for HEVC decoding. 
(http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218233.html 
)

Now we are just about to finish arm 32-bit work and ready to send some patches 
out. Looks like for aarch64 we can join force:) What do you think?

> 
> The patch contains optimizations for most heavily used qpel, epel, sao and 
> idct
> functions.  Among the functions provided for optimization there are two
> intensively used, but not optimized in this patch: hevc_v_loop_filter_luma_8
> and hevc_h_loop_filter_luma_8. I have no idea how they could be optimized
> hence I leaved them without optimizations.
> 

I see that optimization for loop filter already exists for arm 32-bit code. Why 
not use that algorithm?


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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-21 Thread Richard Ling
Updated patch.
The integer overflow is avoided by limiting smoothing parameter to
MAX_INT/8. It is later multiplied by 6.
Regards
R.


0001-avfilter-add-normalize-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] How to preserve @subheading directives, and styling, when compiling doc/developer.texi ?

2017-11-21 Thread Jim DeLaHunt

Hello, doc maintainers:

Could I get some help with the Texinfo compilation which produces 
/developer.html, please?


Page  is a document which has some 
section headings displayed in green text, and some subheadings displayed 
in grey text. Section headings appear in the Table of Contents, but 
subheadings do not. For instance, at 
, the section 
begins:





   _1.4.3 Documentation/Other_


   _Subscribe to the ffmpeg-cvslog mailing list._

__

It is important to do this as the diffs of all commits are sent there 
and reviewed by all the other developers. Bugs and possible improvements 
or general questions regarding commits are discussed there. We expect 
you to react if problems with your code are uncovered.




I believe this page corresponds to file /doc/developer.html in the 
FFmpeg build tree, which is compiled from source in /doc/developer.texi 
via "make doc".


When I do "make doc" and generate /doc/developer.html from the current 
*master* branch (commit ba98f84), I get a different-looking HTML file. 
The section title is in light grey text, and the subheading is missing 
entirely.  At 
, 
the section begins:





   _1.4.3 Documentation/Other_

It is important to do this as the diffs of all commits are sent there 
and reviewed by all the other developers. Bugs and possible improvements 
or general questions regarding commits are discussed there. We expect 
you to react if problems with your code are uncovered.



The section headings come from @section and @subsection directives. The 
subheadings come from @subheading directives. In doc/developer.texi, the 
source of this section reads,



@subsection Documentation/Other
@subheading Subscribe to the ffmpeg-cvslog mailing list.
It is important to do this as the diffs of all commits are sent there and
reviewed by all the other developers. Bugs and possible improvements or
general questions regarding commits are discussed there. We expect you to
react if problems with your code are uncovered.


So, it appears that when compiling on my local machine, the @subheading 
directives are discarded, and the styling differs from what is on 
ffmpeg.org.


How can I compile /doc/developer.html from the FFmpeg sources so that:

1. the subheadings are included, and

2. the styling matches what is at ffmpeg.org/developer.html

Thanks in advance for your help.  Best regards,
   —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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