Re: [FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

2019-02-25 Thread Jeyapal, Karthick

On 2/22/19 12:25 PM, joepadmiraal wrote:
> From: joepadmiraal 
>
> ---
>  libavformat/dashenc.c | 29 -
>  1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 37a7547b12..d0d0d6f030 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -122,6 +122,7 @@ typedef struct DASHContext {
>  int64_t last_duration;
>  int64_t total_duration;
>  char availability_start_time[100];
> +int64_t start_time_ms;
>  char dirname[1024];
>  const char *single_file_name;  /* file names as specified in options */
>  const char *init_seg_name;
> @@ -432,6 +433,8 @@ static void write_hls_media_playlist(OutputStream *os, 
> AVFormatContext *s,
>  const char *proto = avio_find_protocol_name(c->dirname);
>  int use_rename = proto && !strcmp(proto, "file");
>  int i, start_index, start_number;
> +time_t start_time_s = c->start_time_ms / 1000;
> +double prog_date_time = start_time_s;
>  
>  get_start_index_number(os, c, _index, _number);
>  
> @@ -464,16 +467,21 @@ static void write_hls_media_playlist(OutputStream *os, 
> AVFormatContext *s,
>  ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
> os->init_range_length, os->init_start_pos);
>  
> -for (i = start_index; i < os->nb_segments; i++) {
> +for (i = 0; i < os->nb_segments; i++) {
>  Segment *seg = os->segments[i];
> -ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
> -(double) seg->duration / timescale, 0,
> -seg->range_length, seg->start_pos, NULL,
> -c->single_file ? os->initfile : seg->file,
> -NULL);
> -if (ret < 0) {
> -av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
> error\n");
> +double duration = (double) seg->duration / timescale;
> +if (i >= start_index) {
> +double prog_date_time_copy = prog_date_time;
> +ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
> +duration, 0,
> +seg->range_length, seg->start_pos, NULL,
> +c->single_file ? os->initfile : 
> seg->file,
> +_date_time_copy);
> +if (ret < 0) {
> +av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
> error\n");
> +}
>  }
> +prog_date_time += duration;
Hi Joep,

It is great to see that you are submitting your changes back to the community 
for improving dashenc features.
Really appreciate your effort on this. Thank you very much.

In terms for the actual changes, I have review comment. The algorithmic 
complexity for calculating prog_date_time will increase with the time software 
has been running continuously. For example, if the software has been running 
for seven days continuously (with window_size parameter enabled for a live 
input), it will take smaller cpu time to compute prog_date_time on the first 
day, and much longer time on the seventh day. Such kind of algorithms affect 
the stability of the software in long-duration runs for live input. Could you 
please modify the algorithm so that the prog_date_time calculation's complexity 
doesn't increase linearly with time.

Regards,
Karthick
>  }
>  
>  if (prefetch_url)
> @@ -1583,9 +1591,12 @@ static int dash_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  os->first_pts = pkt->pts;
>  os->last_pts = pkt->pts;
>  
> -if (!c->availability_start_time[0])
> +if (!c->availability_start_time[0]) {
> +int64_t start_time_us = av_gettime();
> +c->start_time_ms = start_time_us / 1000;
>  format_date_now(c->availability_start_time,
>  sizeof(c->availability_start_time));
> +}
>  
>  if (!os->availability_time_offset && pkt->duration) {
>  int64_t frame_duration = av_rescale_q(pkt->duration, st->time_base,

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.

2019-02-25 Thread C.H.Liu
Attach one of my massif outputs.

The max memory usage is approximately 22.05MB. And the *extra *heap is not
too big.

The peak snapshot is the 7th. The H.264 decoder is responsible for 86.11%
of the memory usage.

The update_frag_index is responsible for 78,264 bytes. And the relevant
code is at line 1276 instead of line 1257. In my opinion, this is usual. It
create fragment items for every ‘moof’.


Thanks and Regards,

Charles

On Mon, Feb 25, 2019 at 7:07 PM C.H.Liu  wrote:

>  Would you mind share your input file? I still can’t reproduce the OOM.
>
>
> I have tried several types of mp4.
>
> I also tried to create a file like yours. According to the snapshot, seems
> it has no ‘sidx’ box and enable ‘use_mfra_for’.
>
> Massif didn’t report update_frag_index() function. I didn’t see an extra
> heap as big as here, either.
>
>
> The code around line 1257 creates an array of fragment indices for each
> track. It should be very small. Interesting.
>
> Sorry for disturbing.
>
>
> Thanks and Regards,
>
> Charles
>
> Michael Niedermayer  于2019年2月23日周六 下午5:35写道:
>
>> On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote:
>> > I can’t reproduce the OOM. Is it possible the problem relate to a
>> specific
>> > clip?
>> >
>> > Here is my test steps:
>> > 1. To ensure that it’s not affected by caches, delete all except the
>> .git
>> > dir in my code dir. Then checkout again.
>> > 2. To ensure that the latest test clips are used. make fate-rsync
>> > SAMPLES=fate-suite/
>> > 3. To ensure that OS environment is clean, run test in docker.
>> > Below is one of my test logs:
>>
>> heres some massif output that should show where the exessive allocation
>> happens:
>> (note the box has 14gb free and the input file is less than 4kb size)
>>
>> snapshot=70
>> #---
>> time=1856698079
>> mem_heap_B=8487679
>> mem_heap_extra_B=522580313
>> mem_stacks_B=0
>> heap_tree=peak
>> n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns,
>> etc.
>>  n2: 8298639 0x12AAF2B: av_malloc (mem.c:87)
>>   n1: 8294364 0x12AAF59: av_malloc (mem.c:126)
>>n1: 8294364 0x12AB24B: av_mallocz (mem.c:238)
>> n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195)
>>  n1: 8294364 0x743749: update_frag_index (mov.c:1257)
>>   n1: 8294364 0x756174: read_tfra (mov.c:7293)
>>n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344)
>> n1: 8294364 0x743B01: mov_read_moof (mov.c:1338)
>>  n1: 8294364 0x754A0C: mov_read_default (mov.c:6841)
>>   n1: 8294364 0x756596: mov_read_header (mov.c:7385)
>>n1: 8294364 0x8254BB: avformat_open_input (utils.c:631)
>> n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104)
>>  n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273)
>>   n1: 8294364 0x41F7F8: ffmpeg_parse_options
>> (ffmpeg_opt.c:3313)
>>n0: 8294364 0x43DFC6: main (ffmpeg.c:4869)
>>   n0: 4275 in 7 places, all below massif's threshold (01.00%)
>>  n0: 189040 in 8 places, all below massif's threshold (01.00%)
>>
>>
>> [...]
>> --
>> 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
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>


massif.out.63483.tar.bz2
Description: BZip2 compressed data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions

2019-02-25 Thread Shiyou Yin
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of gxw
>Sent: Monday, February 25, 2019 6:14 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: gxw
>Subject: [FFmpeg-devel] [PATCH v3] avcodec/mips: [loongson] mmi optimizations 
>for VP9 put and avg
>functions
>
>VP9 decoding speed improved about 60.5%(from 38fps to 61fps, tested on 
>loongson 3A3000).
>---
> libavcodec/mips/Makefile   |   1 +
> libavcodec/mips/vp9_mc_mmi.c   | 628 +
> libavcodec/mips/vp9dsp_init_mips.c |  42 +++
> libavcodec/mips/vp9dsp_mips.h  |  50 +++
> libavutil/mips/mmiutils.h  |  15 +
> 5 files changed, 736 insertions(+)
> create mode 100644 libavcodec/mips/vp9_mc_mmi.c
>

Verified, LGTM.


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


Re: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions

2019-02-25 Thread gxw

> 在 2019年2月24日,上午10:55,Shiyou Yin  写道:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel-boun...@ffmpeg.org 
>>  
>> [mailto:ffmpeg-devel-boun...@ffmpeg.org 
>> ] On Behalf Of gxw
>> Sent: Thursday, February 21, 2019 8:39 PM
>> To: ffmpeg-devel@ffmpeg.org 
>> Cc: gxw
>> Subject: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] mmi 
>> optimizations for VP9 put and avg
>> functions
>> 
>> VP9 decoding speed improved about 60.5%(from 38fps to 61fps, tested on 
>> loongson 3A3000).
>> ---
>> libavcodec/mips/Makefile   |   1 +
>> libavcodec/mips/vp9_mc_mmi.c   | 692 
>> +
>> libavcodec/mips/vp9dsp_init_mips.c |  42 +++
>> libavcodec/mips/vp9dsp_mips.h  |  50 +++
>> libavutil/mips/mmiutils.h  |  15 +
>> 5 files changed, 800 insertions(+)
>> create mode 100644 libavcodec/mips/vp9_mc_mmi.c
>> 
>> diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
>> index c827649..c5b54d5 100644
>> --- a/libavcodec/mips/Makefile
>> +++ b/libavcodec/mips/Makefile
>> @@ -88,3 +88,4 @@ MMI-OBJS-$(CONFIG_VC1_DECODER)+= 
>> mips/vc1dsp_mmi.o
>> MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o
>> MMI-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_mmi.o
>> MMI-OBJS-$(CONFIG_VP3DSP) += mips/vp3dsp_idct_mmi.o
>> +MMI-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_mmi.o
>> diff --git a/libavcodec/mips/vp9_mc_mmi.c b/libavcodec/mips/vp9_mc_mmi.c
>> new file mode 100644
>> index 000..58a920b
>> --- /dev/null
>> +++ b/libavcodec/mips/vp9_mc_mmi.c
>> @@ -0,0 +1,692 @@
>> +/*
>> + * Copyright (c) 2019 gxw 
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +#include "libavcodec/vp9dsp.h"
>> +#include "libavutil/mips/mmiutils.h"
>> +#include "vp9dsp_mips.h"
>> +
>> +#define GET_DATA_H_MMI   \
>> +"pmaddhw%[ftmp4],%[ftmp4],   %[filter1]\n\t" \
>> +"pmaddhw%[ftmp5],%[ftmp5],   %[filter2]\n\t" \
>> +"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
>> +"punpckhwd  %[ftmp5],%[ftmp4],   %[ftmp0]  \n\t" \
>> +"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
>> +"pmaddhw%[ftmp6],%[ftmp6],   %[filter1]\n\t" \
>> +"pmaddhw%[ftmp7],%[ftmp7],   %[filter2]\n\t" \
>> +"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
>> +"punpckhwd  %[ftmp7],%[ftmp6],   %[ftmp0]  \n\t" \
>> +"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
>> +"punpcklwd  %[srcl], %[ftmp4],   %[ftmp6]  \n\t" \
>> +"pmaddhw%[ftmp8],%[ftmp8],   %[filter1]\n\t" \
>> +"pmaddhw%[ftmp9],%[ftmp9],   %[filter2]\n\t" \
>> +"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
>> +"punpckhwd  %[ftmp9],%[ftmp8],   %[ftmp0]  \n\t" \
>> +"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
>> +"pmaddhw%[ftmp10],   %[ftmp10],  %[filter1]\n\t" \
>> +"pmaddhw%[ftmp11],   %[ftmp11],  %[filter2]\n\t" \
>> +"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
>> +"punpckhwd  %[ftmp11],   %[ftmp10],  %[ftmp0]  \n\t" \
>> +"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
>> +"punpcklwd  %[srch], %[ftmp8],   %[ftmp10] \n\t"
>> +
>> +#define GET_DATA_V_MMI   \
>> +"punpcklhw  %[srcl], %[ftmp4],   %[ftmp5]  \n\t" \
>> +"pmaddhw%[srcl], %[srcl],%[filter10]   \n\t" \
>> +"punpcklhw  %[ftmp12],   %[ftmp6],   %[ftmp7]  \n\t" \
>> +"pmaddhw%[ftmp12],   %[ftmp12],  %[filter32]   \n\t" \
>> +"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
>> +"punpcklhw  %[ftmp12],   %[ftmp8],   %[ftmp9]  \n\t" \
>> +"pmaddhw%[ftmp12],   %[ftmp12],  %[filter54]   \n\t" \
>> +"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
>> +"punpcklhw  %[ftmp12],   %[ftmp10],  %[ftmp11] \n\t" \
>> +"pmaddhw%[ftmp12],   %[ftmp12],  %[filter76]   \n\t" \
>> +"paddw 

[FFmpeg-devel] [PATCH] ffmpeg: explicitly handle sub2video subpicture initialization

2019-02-25 Thread Jan Ekström
Each time the sub2video structure is initialized, the sub2video
subpicture is initialized together with the first received heartbeat.
The heartbeat's PTS is utilized as the subpicture start time.

Additionally, add some documentation on the stages.
---
 fftools/ffmpeg.c| 22 +++---
 fftools/ffmpeg.h|  3 ++-
 fftools/ffmpeg_filter.c |  8 +++-
 3 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1cef..efe903cc41 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -237,7 +237,7 @@ static void sub2video_push_ref(InputStream *ist, int64_t 
pts)
 }
 }
 
-void sub2video_update(InputStream *ist, AVSubtitle *sub)
+void sub2video_update(InputStream *ist, int64_t heartbeat_pts, AVSubtitle *sub)
 {
 AVFrame *frame = ist->sub2video.frame;
 int8_t *dst;
@@ -254,7 +254,12 @@ void sub2video_update(InputStream *ist, AVSubtitle *sub)
  AV_TIME_BASE_Q, ist->st->time_base);
 num_rects = sub->num_rects;
 } else {
-pts   = ist->sub2video.end_pts;
+/* If we are initializing the system, utilize current heartbeat
+   PTS as the start time, and show until the following subpicture
+   is received. Otherwise, utilize the previous subpicture's end time
+   as the fall-back value. */
+pts   = ist->sub2video.initialize ?
+heartbeat_pts : ist->sub2video.end_pts;
 end_pts   = INT64_MAX;
 num_rects = 0;
 }
@@ -269,6 +274,7 @@ void sub2video_update(InputStream *ist, AVSubtitle *sub)
 sub2video_copy_rect(dst, dst_linesize, frame->width, frame->height, 
sub->rects[i]);
 sub2video_push_ref(ist, pts);
 ist->sub2video.end_pts = end_pts;
+ist->sub2video.initialize = 0;
 }
 
 static void sub2video_heartbeat(InputStream *ist, int64_t pts)
@@ -291,9 +297,11 @@ static void sub2video_heartbeat(InputStream *ist, int64_t 
pts)
 /* do not send the heartbeat frame if the subtitle is already ahead */
 if (pts2 <= ist2->sub2video.last_pts)
 continue;
-if (pts2 >= ist2->sub2video.end_pts ||
-(!ist2->sub2video.frame->data[0] && ist2->sub2video.end_pts < 
INT64_MAX))
-sub2video_update(ist2, NULL);
+if (pts2 >= ist2->sub2video.end_pts || ist2->sub2video.initialize)
+/* if we have hit the end of the current displayed subpicture,
+   or if we need to initialize the system, update the
+   overlayed subpicture and its start/end times */
+sub2video_update(ist2, pts2 + 1, NULL);
 for (j = 0, nb_reqs = 0; j < ist2->nb_filters; j++)
 nb_reqs += 
av_buffersrc_get_nb_failed_requests(ist2->filters[j]->filter);
 if (nb_reqs)
@@ -307,7 +315,7 @@ static void sub2video_flush(InputStream *ist)
 int ret;
 
 if (ist->sub2video.end_pts < INT64_MAX)
-sub2video_update(ist, NULL);
+sub2video_update(ist, INT64_MAX, NULL);
 for (i = 0; i < ist->nb_filters; i++) {
 ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
 if (ret != AVERROR_EOF && ret < 0)
@@ -2514,7 +2522,7 @@ static int transcode_subtitles(InputStream *ist, AVPacket 
*pkt, int *got_output,
 return ret;
 
 if (ist->sub2video.frame) {
-sub2video_update(ist, );
+sub2video_update(ist, INT64_MIN, );
 } else if (ist->nb_filters) {
 if (!ist->sub2video.sub_queue)
 ist->sub2video.sub_queue = av_fifo_alloc(8 * sizeof(AVSubtitle));
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index eb1eaf6363..b2129a3f28 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -349,6 +349,7 @@ typedef struct InputStream {
 AVFifoBuffer *sub_queue;///< queue of AVSubtitle* before filter 
init
 AVFrame *frame;
 int w, h;
+unsigned int initialize; ///< marks if sub2video_update should force 
an initialization
 } sub2video;
 
 int dr1;
@@ -646,7 +647,7 @@ int filtergraph_is_simple(FilterGraph *fg);
 int init_simple_filtergraph(InputStream *ist, OutputStream *ost);
 int init_complex_filtergraph(FilterGraph *fg);
 
-void sub2video_update(InputStream *ist, AVSubtitle *sub);
+void sub2video_update(InputStream *ist, int64_t heartbeat_pts, AVSubtitle 
*sub);
 
 int ifilter_parameters_from_frame(InputFilter *ifilter, const AVFrame *frame);
 
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..d81bb9742f 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -740,6 +740,12 @@ static int sub2video_prepare(InputStream *ist, InputFilter 
*ifilter)
 return AVERROR(ENOMEM);
 ist->sub2video.last_pts = INT64_MIN;
 ist->sub2video.end_pts  = INT64_MIN;
+
+/* sub2video structure has been (re-)initialized.
+   Mark it as such so that the system will be
+   initialized with the first received heartbeat. */
+ist->sub2video.initialize = 1;
+
 

Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/vaapi_encode: add frame-skip func

2019-02-25 Thread Mark Thompson
On 22/02/2019 03:09, Sun, Jing A wrote:
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Thursday, February 21, 2019 5:35 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/vaapi_encode: add 
> frame-skip func
> 
> On 20/02/2019 10:33, Jing SUN wrote:
>> This implements app controlled frame skipping in vaapi encoding. To 
>> make a frame skipped, allocate its frame side data of the newly added 
>> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.
>>
>> Signed-off-by: Jing SUN 
>> ---
>>  libavcodec/vaapi_encode.c | 112 
>> --
>>  libavcodec/vaapi_encode.h |   5 +++
>>  libavutil/frame.c |   1 +
>>  libavutil/frame.h |   5 +++
>>  4 files changed, 119 insertions(+), 4 deletions(-)
> 
> Have a look at 
> , 
> which tries to implement this feature in a more general way without adding 
> any ad-hoc API.
> 
> - Mark
> -Original Message-
> 
> Hi Mark,
> 
> I think the 239989 patch is quite a good one to implement VFR by adapting 
> VAAPI frame-skip feature, but it does not fulfill the feature requirement 
> that we have been asked to achieve, which is to skip the frames that are 
> selected by apps, and the purpose to skip any frames is not just to control 
> frame-rate, but also to skip duplicated ones, or to skip abandoned ones due 
> to some changes just made, etc. Could we please keep both and let users 
> decide which way they want to use?

I think these use-cases are all supported by the same method used for other 
encoders in libavcodec, by not sending the skipped frames to the encoder.  The 
linked patch is only wanted to fix the rate control in these cases - that's 
otherwise broken because VAAPI lacks any support for timestamps.

Can you explain a specific use-case which wants the extra message?

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


Re: [FFmpeg-devel] [PATCH v3 01/12] vaapi_encode: Support more RC modes

2019-02-25 Thread Mark Thompson
On 13/02/2019 03:14, Carl Eugen Hoyos wrote:
> 2019-02-10 20:46 GMT+01:00, Mark Thompson :
>> Allow setting the mode explicitly, and try to make a sensible choice
>> given the available parameters if not.
> 
> Please mention ticket #7650 if this patch fixes the assertion failure.

Yep, marked on the appropriate patch.

With that, 1-9 applied.

Thanks,

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


Re: [FFmpeg-devel] [PATCH 1/2] filter_units, trace_headers: Always use fragment from context

2019-02-25 Thread Mark Thompson
On 11/02/2019 22:47, Andreas Rheinhardt wrote:
> This is in preparation for another patch that will stop needless
> reallocations of the unit array.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/filter_units_bsf.c  |  8 
>  libavcodec/trace_headers_bsf.c | 13 +++--
>  2 files changed, 11 insertions(+), 10 deletions(-)

On 11/02/2019 22:47, Andreas Rheinhardt wrote:> Currently, a fragment's unit 
array is constantly reallocated during
> splitting of a packet. This commit changes this: One can keep the units
> array by distinguishing between the number of allocated and the number
> of valid units in the units array.
> 
> The more units a packet is split into, the bigger the benefit.
> So MPEG-2 benefits the most; for a video coming from an NTSC-DVD
> (usually 32 units per frame) the average cost of cbs_insert_unit (for a
> single unit) went down from 6717 decicycles to 450 decicycles (based
> upon 10 runs with 4194304 runs each); if each packet consists of only
> one unit, it went down from 2425 to 448; for a H.264 video where most
> packets contain nine units, it went from 4431 to 450.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  This time I have also changed VAAPI to stop reallocating the units
> array. Keep in mind that I couldn't test this at all.
>  libavcodec/av1_metadata_bsf.c   |  6 ++-
>  libavcodec/av1_parser.c |  5 ++-
>  libavcodec/cbs.c| 62 +
>  libavcodec/cbs.h| 33 +--
>  libavcodec/filter_units_bsf.c   |  7 ++--
>  libavcodec/h264_metadata_bsf.c  |  6 ++-
>  libavcodec/h264_redundant_pps_bsf.c |  6 ++-
>  libavcodec/h265_metadata_bsf.c  |  6 ++-
>  libavcodec/mpeg2_metadata_bsf.c |  6 ++-
>  libavcodec/trace_headers_bsf.c  |  5 ++-
>  libavcodec/vaapi_encode_h264.c  |  9 +++--
>  libavcodec/vaapi_encode_h265.c  |  9 +++--
>  libavcodec/vaapi_encode_mjpeg.c |  3 +-
>  libavcodec/vaapi_encode_mpeg2.c |  5 ++-
>  libavcodec/vp9_metadata_bsf.c   |  4 +-
>  15 files changed, 113 insertions(+), 59 deletions(-)

LGTM, applied.

Thank you!

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


Re: [FFmpeg-devel] fate/proresenc_aw : Add fate test for interlace and 444 encoding

2019-02-25 Thread Michael Niedermayer
On Mon, Feb 25, 2019 at 09:01:16PM +0100, Martin Vignali wrote:
> Hello,
> 
> Thanks for testing.
> Can you send me the result file vsynth3-prores_int.mov, so i can try to
> find why the result are not the same.

https://ffmpeg.org/~michael/vsynth3-prores_int.mov
https://ffmpeg.org/~michael/vsynth3-prores_444_int.mov


> 
> Only the two vsynth3 interlaced test fail ?

yes

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


[FFmpeg-devel] [PATCH] avcodec/diracdec: Correct max pixels check

2019-02-25 Thread Michael Niedermayer
Dirac internally allocates 5 images per plane and frame currently. One being 
the actual
image the other 4 being filtered for motion compensation.

Fixes: Out of memory
Fixes: 
12870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5684825871089664

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index db010b49cf..30b4bfad79 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -2137,7 +2137,7 @@ static int dirac_decode_data_unit(AVCodecContext *avctx, 
const uint8_t *buf, int
 return ret;
 }
 
-if (CALC_PADDING((int64_t)dsh->width, MAX_DWT_LEVELS) * 
CALC_PADDING((int64_t)dsh->height, MAX_DWT_LEVELS) > avctx->max_pixels)
+if (CALC_PADDING((int64_t)dsh->width, MAX_DWT_LEVELS) * 
CALC_PADDING((int64_t)dsh->height, MAX_DWT_LEVELS) * 5LL > avctx->max_pixels)
 ret = AVERROR(ERANGE);
 if (ret >= 0)
 ret = ff_set_dimensions(avctx, dsh->width, dsh->height);
-- 
2.20.1

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


Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Moritz Barsnick
Hi Yufei,
before providing large patches here, do read this mailing list and the
ffmpeg codebase for a while. It will help you to understand the
process, and to understand how ffmpeg's sources are organized.

I'm sure you missed this:
https://www.ffmpeg.org/developer.html

Read all of it thoroughly.

The content of this section:
https://www.ffmpeg.org/developer.html#Coding-Rules-1
especially comes to mind. Your code uses totally different formatting
than the rest of the ffmpeg codebase. You should take a look around as
see how others do it, and what that style guide says.

Apart from that: Everything that Nicolas wrote.

In addition this:

On Mon, Feb 25, 2019 at 19:49:43 +, Yufei He wrote:
> index c90f119..f70368b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -11,6 +11,7 @@ version :
>  - dhav demuxer
>  - PCM-DVD encoder
>  - GIF parser
> +- M264 encoder

Your patch is against an at least two months old version of ffmpeg git.
Please merge it to latest git HEAD and create a new patch. Your patch
won't apply currently, and therefore noone will bother to test it.

And even if I try to work around that, here's what happens:

LD  ffmpeg_g
/usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
`ff_m264_encode_init':
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:98: 
undefined reference to `dlopen'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:108: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:109: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:110: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:111: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:112: 
undefined reference to `dlsym'
/usr/bin/ld: 
libavcodec/libavcodec.a(m264enc.o):/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:113:
 more undefined references to `dlsym' follow
/usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
`ff_m264_encode_close':
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:264: 
undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: ffmpeg_g] Error 1

You need to get your dependencies right.

> +   if(*got_output)
> +   {
> +  if(decoded_frame->width == 0)
> +  {
> + av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
> %d,%d,%d != %d,%d,%d\n",
> +   decoded_frame->width,
> +   decoded_frame->height,
> +   decoded_frame->format,
> +   ist->dec_ctx->width,
> +   ist->dec_ctx->height,
> +   ist->dec_ctx->pix_fmt);
> +  }
> +   }

This is debug code and does not belong into a released codec.
Furthermore, ffmpeg provides av_log() functions.

> index 000..dc1852f
> --- /dev/null
> +++ b/libavcodec/.vscode/settings.json

Don't commit your local development environment's settings, please.

>  OBJS-$(CONFIG_DNXHD_DECODER)   += dnxhddec.o dnxhddata.o
>  OBJS-$(CONFIG_DNXHD_ENCODER)   += dnxhdenc.o dnxhddata.o
> +OBJS-$(CONFIG_M264_ENCODER)+= m264enc.o
> +OBJS-$(CONFIG_M264_DECODER)+= m264dec.o
>  OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
>  OBJS-$(CONFIG_DPX_DECODER) += dpx.o

Do you realize that the rest of this list is in alphabetical order?

>  OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
>  
> +
> +
> +
>  # thread libraries

Why do you add useless empty lines, and commit them?

>  extern AVCodec ff_dnxhd_encoder;
>  extern AVCodec ff_dnxhd_decoder;
> +extern AVCodec ff_m264_encoder;
> +extern AVCodec ff_m264_decoder;
>  extern AVCodec ff_dpx_encoder;
>  extern AVCodec ff_dpx_decoder;

Alphabetical order, again.

>  if (c)
> -*opaque = (void*)(i + 1);
> -
> +  *opaque = (void*)(i + 1);
> +  
>  return c;

Useless change. And please don't ever leave whitespace at your line
endings, it won't be accepted. (Your IDE surely can fix this for you.)

> +#define FF_PROFILE_M264 0

What is this?

> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
> +.profiles  = NULL_IF_CONFIG_SMALL(ff_h264_profiles),

Does the encoder even honor any of the profiles?

> +   #ifdef _WIN32
> +   av_log(avctx, AV_LOG_DEBUG, "_WIN32\n");
> +   #elif defined _WIN64
> +   av_log(avctx, AV_LOG_DEBUG, "_WIN64\n");
> +   #else
> +   av_log(avctx, AV_LOG_DEBUG, "linux\n");
> +   #endif

What for?

> +#ifdef _WIN32
> +   lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
> +#else   
> +   lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
> +#endif

I'm not sure this is acceptable within ffmpeg.

> +   if (!lib_handle)
> +   {
> +  av_log(avctx, AV_LOG_ERROR, "failed 

Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Tomas Härdin
Hi

> +void convert_to_annexb(unsigned char * dest, unsigned long
> data_size)
> +{
> +   unsigned char *current = dest;
> +   union 
> +   {
> +  unsigned char by4[4];
> +  uint32_t length;
> +   } union_u32_byte;
> +  
> +   while ((dest + data_size) > (current + 4))
> +   {
> +  if((current[0] == 0) &&
> + (current[1] == 0) &&
> + (current[2] == 0) &&
> + (current[3] == 1))
> +  {
> + // in case it is already in annex B
> + break;
> +  }
> +
> +  union_u32_byte.by4[3] = current[0];
> +  union_u32_byte.by4[2] = current[1];
> +  union_u32_byte.by4[1] = current[2];
> +  union_u32_byte.by4[0] = current[3];

This won't work on certain machines. Type punning is also undefined if
memory serves me right, and may not work right in all compilers.
Definitely not recommended. There are macros in FFmpeg for this already
(AV_RL32 and friends)

> +#ifdef _WIN32
> +   lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
> +#else   
> +   lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
> +#endif

I believe FFmpeg has policy specifically against stuff like this. Link
the dynamic library properly, and put appropriate license stuff in
configure. The resulting ffmpeg binaries will more than likely not be
redistributable, libav* might also be depending on what the Matrox
library's license is.

> +   printf("m264_encode_init_h264: avctx->width = %d\n", avctx->width);
> +   printf("m264_encode_init_h264: avctx->height = %d\n", avctx->height);
> +   printf("m264_encode_init_h264: avctx->framerate.num = %d\n", 
> avctx->framerate.num);
> +   printf("m264_encode_init_h264: avctx->framerate.den = %d\n", 
> avctx->framerate.den);
> +   printf("m264_encode_init_h264: avctx->gop_size = %d\n", avctx->gop_size);
> +   printf("m264_encode_init_h264: avctx->bit_rate = %" PRId64 "\n", 
> avctx->bit_rate);

Forgotten debug stuff? printf() is definitely not OK

There are other issues with this patch, but there's no point in looking
more for now

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


[FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Yufei He
Hi

Please review this one.

Thanks.

Yufei.


On 02/25/2019 02:58 PM, Nicolas George wrote:

Yufei He (12019-02-25):


From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
From: yhe 
Date: Mon, 25 Feb 2019 14:38:21 -0500
Subject: [PATCH] M264 codec support



Quick comments.

They are in no way to be taken as any kind of endorsement for the patch.




---
 .vscode/settings.json|  27 +++



No, thanks.



 Changelog|   1 +
 configure|   1 +
 doc/general.texi |   1 +
 fftools/ffmpeg.c |  14 ++
 libavcodec/.vscode/settings.json |   5 +
 libavcodec/Makefile  |   5 +
 libavcodec/allcodecs.c   |   6 +-
 libavcodec/avcodec.h |   3 +
 libavcodec/codec_desc.c  |   9 +
 libavcodec/m264dec.c | 476 +++
 libavcodec/m264dec.h |  42 
 libavcodec/m264enc.c | 289 
 libavcodec/m264enc.h |  39 
 libavcodec/profiles.c|   5 +
 libavcodec/profiles.h|   1 +
 16 files changed, 922 insertions(+), 2 deletions(-)
 create mode 100644 .vscode/settings.json
 create mode 100644 libavcodec/.vscode/settings.json
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..4cdd683
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,27 @@
+{
+   "files.associations": {
+  "avcodec.h": "c",
+  "nvdec.h": "c",
+  "config.h": "c",
+  "avassert.h": "c",
+  "iostream": "cpp",
+  "profiles.h": "c",
+  "swscale.h": "c",
+  "array": "c",
+  "functional": "c",
+  "hash_map": "c",
+  "initializer_list": "c",
+  "utility": "c",
+  "*.tcc": "cpp",
+  "deque": "cpp",
+  "list": "cpp",
+  "vector": "cpp",
+  "system_error": "cpp",
+  "bitset": "cpp",
+  "valarray": "cpp",
+  "adpcm_data.h": "c",
+  "blockdsp.h": "c",
+  "channel_layout.h": "c",
+  "h264chroma.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/Changelog b/Changelog
index c90f119..f70368b 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
 - dhav demuxer
 - PCM-DVD encoder
 - GIF parser
+- M264 encoder


 version 4.1:
diff --git a/configure b/configure
index b062b63..161beee 100755
--- a/configure
+++ b/configure
@@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
 dnxhd_decoder_select="blockdsp idctdsp"
 dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"





+#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"



Leftover debug.



 dolby_e_decoder_select="mdct"
 dvvideo_decoder_select="dvprofile idctdsp"
 dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..e012bad 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -828,6 +828,7 @@ following image formats are supported:
 @item Deluxe Paint Animation @tab @tab  X
 @item DNxHD  @tab   X @tab  X
 @tab aka SMPTE VC3





+@item M264   @tab   X @tab



Does not belong there.



 @item Duck TrueMotion 1.0   @tab @tab  X
 @tab fourcc: DUCK
 @item Duck TrueMotion 2.0@tab @tab  X
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6abcc57..b8fa266 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 if (!*got_output || ret < 0)
 return ret;






+   if(*got_output)
+   {
+  if(decoded_frame->width == 0)
+  {
+ av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
%d,%d,%d != %d,%d,%d\n",
+   decoded_frame->width,
+   decoded_frame->height,
+   decoded_frame->format,
+   ist->dec_ctx->width,
+   ist->dec_ctx->height,
+   ist->dec_ctx->pix_fmt);
+  }
+   }
+



Unrelated. And coding style inconsistent.



 if(ist->top_field_first>=0)
 decoded_frame->top_field_first = ist->top_field_first;

diff --git a/libavcodec/.vscode/settings.json b/libavcodec/.vscode/settings.json
new file mode 100644
index 000..dc1852f
--- /dev/null
+++ b/libavcodec/.vscode/settings.json
@@ -0,0 +1,5 @@
+{
+   "files.associations": {
+  "amfenc.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff..32d147f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -266,6 +266,8 @@ OBJS-$(CONFIG_DIRAC_DECODER)   += diracdec.o 
dirac.o diracdsp.o diractab
 OBJS-$(CONFIG_DFA_DECODER) += dfa.o
 

Re: [FFmpeg-devel] avcodec/qtrle : improve decoding speed of 24bpp and 32 bpp

2019-02-25 Thread Carl Eugen Hoyos


> Am 25.02.2019 um 20:59 schrieb Martin Vignali :
> 
> Hello,
> 
> thanks for testing and comments.
> New patch in attach
> 001 : unchanged

> 002 : use ARGB for little and big endian, and change the commit msg

I know we forgot before but this definitely needs a micro version bump.

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


[FFmpeg-devel] [PATCH] Parallelize vf_lut

2019-02-25 Thread Britt Cyr
---
 libavfilter/vf_lut.c | 106 ---
 1 file changed, 70 insertions(+), 36 deletions(-)

diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc194..14386938be 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -72,6 +72,12 @@ typedef struct LutContext {
 int negate_alpha; /* only used by negate */
 } LutContext;
 
+typedef struct ThreadData {
+  AVFrame *in;
+  AVFrame *out;
+  AVFilterLink *link;
+} ThreadData;
+
 #define Y 0
 #define U 1
 #define V 2
@@ -337,26 +343,13 @@ static int config_props(AVFilterLink *inlink)
 return 0;
 }
 
-static int filter_frame(AVFilterLink *inlink, AVFrame *in)
-{
-AVFilterContext *ctx = inlink->dst;
+static int lookup_slice(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs) {
 LutContext *s = ctx->priv;
-AVFilterLink *outlink = ctx->outputs[0];
-AVFrame *out;
-int i, j, plane, direct = 0;
-
-if (av_frame_is_writable(in)) {
-direct = 1;
-out = in;
-} else {
-out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
-if (!out) {
-av_frame_free();
-return AVERROR(ENOMEM);
-}
-av_frame_copy_props(out, in);
-}
-
+int i, j, plane = 0;
+const ThreadData *td = arg;
+const AVFrame *in  = td->in;
+AVFrame *out = td->out;
+const AVFilterLink *inlink = td->link;
 if (s->is_rgb && s->is_16bit && !s->is_planar) {
 /* packed, 16-bit */
 uint16_t *inrow, *outrow, *inrow0, *outrow0;
@@ -366,11 +359,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const int in_linesize  =  in->linesize[0] / 2;
 const int out_linesize = out->linesize[0] / 2;
 const int step = s->step;
+const int row_min = jobnr / nb_jobs * h;
+const int row_max = (jobnr + 1) / nb_jobs * h;
 
 inrow0  = (uint16_t*) in ->data[0];
 outrow0 = (uint16_t*) out->data[0];
 
-for (i = 0; i < h; i ++) {
+for (i = row_min; i < row_max; i ++) {
 inrow  = inrow0;
 outrow = outrow0;
 for (j = 0; j < w; j++) {
@@ -403,11 +398,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const int in_linesize  =  in->linesize[0];
 const int out_linesize = out->linesize[0];
 const int step = s->step;
+const int row_min = jobnr / nb_jobs * h;
+const int row_max = (jobnr + 1) / nb_jobs * h;
 
 inrow0  = in ->data[0];
 outrow0 = out->data[0];
 
-for (i = 0; i < h; i ++) {
+for (i = row_min; i < row_max; i ++) {
 inrow  = inrow0;
 outrow = outrow0;
 for (j = 0; j < w; j++) {
@@ -435,11 +432,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const uint16_t *tab = s->lut[plane];
 const int in_linesize  =  in->linesize[plane] / 2;
 const int out_linesize = out->linesize[plane] / 2;
+const int row_min = jobnr / nb_jobs * h;
+const int row_max = (jobnr + 1) / nb_jobs * h;
 
 inrow  = (uint16_t *)in ->data[plane];
 outrow = (uint16_t *)out->data[plane];
 
-for (i = 0; i < h; i++) {
+for (i = row_min; i < row_max; i++) {
 for (j = 0; j < w; j++) {
 #if HAVE_BIGENDIAN
 outrow[j] = av_bswap16(tab[av_bswap16(inrow[j])]);
@@ -463,11 +462,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const uint16_t *tab = s->lut[plane];
 const int in_linesize  =  in->linesize[plane];
 const int out_linesize = out->linesize[plane];
+const int row_min = jobnr / nb_jobs * h;
+const int row_max = (jobnr + 1) / nb_jobs * h;
 
 inrow  = in ->data[plane];
 outrow = out->data[plane];
 
-for (i = 0; i < h; i++) {
+for (i = row_min; i < row_max; i++) {
 for (j = 0; j < w; j++)
 outrow[j] = tab[inrow[j]];
 inrow  += in_linesize;
@@ -476,9 +477,42 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 }
 }
 
-if (!direct)
+return 0;
+}
+
+static AVFrame *apply_lut(AVFilterLink *inlink, AVFrame *in) {
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+AVFrame *out;
+ThreadData td;
+
+if (av_frame_is_writable(in)) {
+out = in;
+} else {
+out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
+if (!out) {
+av_frame_free();
+return NULL;
+}
+av_frame_copy_props(out, in);
+}
+td.in  = in;
+td.out = out;
+td.link = inlink;
+ctx->internal->execute(ctx, lookup_slice, , NULL, FFMIN(outlink->h, 1));
+
+if (out != in)
 av_frame_free();
 
+return out;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+

Re: [FFmpeg-devel] avcodec/qtrle : improve decoding speed of 24bpp and 32 bpp

2019-02-25 Thread Martin Vignali
Hello,

thanks for testing and comments.
New patch in attach
001 : unchanged
002 : use ARGB for little and big endian, and change the commit msg
003 and 004 : mention test platform in commit msg

I can't compile anymore for x86_32, so can't test speed in X86_32.

Martin


0004-avcodec-qtrle-improve-24bbp-decoding-speed.patch
Description: Binary data


0003-avcodec-qtrle-32bpp-dec-copy-two-raw-argb-value-at-t.patch
Description: Binary data


0001-fate-qtrle-change-32b-test-to-output-bgra-instead-of.patch
Description: Binary data


0002-avcodec-qtrle-avoid-swap-in-32bpp-decoding-on-little.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] fate/proresenc_aw : Add fate test for interlace and 444 encoding

2019-02-25 Thread Martin Vignali
Hello,

Thanks for testing.
Can you send me the result file vsynth3-prores_int.mov, so i can try to
find why the result are not the same.

Only the two vsynth3 interlaced test fail ?

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


Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Nicolas George
Yufei He (12019-02-25):
> From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
> From: yhe 
> Date: Mon, 25 Feb 2019 14:38:21 -0500
> Subject: [PATCH] M264 codec support

Quick comments.

They are in no way to be taken as any kind of endorsement for the patch.

> 
> ---
>  .vscode/settings.json|  27 +++

No, thanks.

>  Changelog|   1 +
>  configure|   1 +
>  doc/general.texi |   1 +
>  fftools/ffmpeg.c |  14 ++
>  libavcodec/.vscode/settings.json |   5 +
>  libavcodec/Makefile  |   5 +
>  libavcodec/allcodecs.c   |   6 +-
>  libavcodec/avcodec.h |   3 +
>  libavcodec/codec_desc.c  |   9 +
>  libavcodec/m264dec.c | 476 
> +++
>  libavcodec/m264dec.h |  42 
>  libavcodec/m264enc.c | 289 
>  libavcodec/m264enc.h |  39 
>  libavcodec/profiles.c|   5 +
>  libavcodec/profiles.h|   1 +
>  16 files changed, 922 insertions(+), 2 deletions(-)
>  create mode 100644 .vscode/settings.json
>  create mode 100644 libavcodec/.vscode/settings.json
>  create mode 100644 libavcodec/m264dec.c
>  create mode 100644 libavcodec/m264dec.h
>  create mode 100644 libavcodec/m264enc.c
>  create mode 100644 libavcodec/m264enc.h
> 
> diff --git a/.vscode/settings.json b/.vscode/settings.json
> new file mode 100644
> index 000..4cdd683
> --- /dev/null
> +++ b/.vscode/settings.json
> @@ -0,0 +1,27 @@
> +{
> +   "files.associations": {
> +  "avcodec.h": "c",
> +  "nvdec.h": "c",
> +  "config.h": "c",
> +  "avassert.h": "c",
> +  "iostream": "cpp",
> +  "profiles.h": "c",
> +  "swscale.h": "c",
> +  "array": "c",
> +  "functional": "c",
> +  "hash_map": "c",
> +  "initializer_list": "c",
> +  "utility": "c",
> +  "*.tcc": "cpp",
> +  "deque": "cpp",
> +  "list": "cpp",
> +  "vector": "cpp",
> +  "system_error": "cpp",
> +  "bitset": "cpp",
> +  "valarray": "cpp",
> +  "adpcm_data.h": "c",
> +  "blockdsp.h": "c",
> +  "channel_layout.h": "c",
> +  "h264chroma.h": "c"
> +   }
> +}
> \ No newline at end of file
> diff --git a/Changelog b/Changelog
> index c90f119..f70368b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -11,6 +11,7 @@ version :
>  - dhav demuxer
>  - PCM-DVD encoder
>  - GIF parser
> +- M264 encoder
>  
>  
>  version 4.1:
> diff --git a/configure b/configure
> index b062b63..161beee 100755
> --- a/configure
> +++ b/configure
> @@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
>  dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
>  dnxhd_decoder_select="blockdsp idctdsp"
>  dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"

> +#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"

Leftover debug.

>  dolby_e_decoder_select="mdct"
>  dvvideo_decoder_select="dvprofile idctdsp"
>  dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
> diff --git a/doc/general.texi b/doc/general.texi
> index 2bc33d1..e012bad 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -828,6 +828,7 @@ following image formats are supported:
>  @item Deluxe Paint Animation @tab @tab  X
>  @item DNxHD  @tab   X @tab  X
>  @tab aka SMPTE VC3

> +@item M264   @tab   X @tab  

Does not belong there.

>  @item Duck TrueMotion 1.0   @tab @tab  X
>  @tab fourcc: DUCK
>  @item Duck TrueMotion 2.0@tab @tab  X
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 6abcc57..b8fa266 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket 
> *pkt, int *got_output, int64_
>  if (!*got_output || ret < 0)
>  return ret;
>  

> +   if(*got_output)
> +   {
> +  if(decoded_frame->width == 0)
> +  {
> + av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
> %d,%d,%d != %d,%d,%d\n",
> +   decoded_frame->width,
> +   decoded_frame->height,
> +   decoded_frame->format,
> +   ist->dec_ctx->width,
> +   ist->dec_ctx->height,
> +   ist->dec_ctx->pix_fmt);
> +  }
> +   }
> +

Unrelated. And coding style inconsistent.

>  if(ist->top_field_first>=0)
>  decoded_frame->top_field_first = ist->top_field_first;
>  
> diff --git a/libavcodec/.vscode/settings.json 
> b/libavcodec/.vscode/settings.json
> new file mode 100644
> index 000..dc1852f
> --- /dev/null
> +++ b/libavcodec/.vscode/settings.json
> @@ -0,0 +1,5 @@
> +{
> +   "files.associations": {
> +  "amfenc.h": "c"
> +   }
> +}
> \ No newline at end of file
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index d53b8ff..32d147f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile

[FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Yufei He
Hi

Here is the patch.

Please check.

Thanks.

Yufei.


From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
From: yhe 
Date: Mon, 25 Feb 2019 14:38:21 -0500
Subject: [PATCH] M264 codec support

---
 .vscode/settings.json|  27 +++
 Changelog|   1 +
 configure|   1 +
 doc/general.texi |   1 +
 fftools/ffmpeg.c |  14 ++
 libavcodec/.vscode/settings.json |   5 +
 libavcodec/Makefile  |   5 +
 libavcodec/allcodecs.c   |   6 +-
 libavcodec/avcodec.h |   3 +
 libavcodec/codec_desc.c  |   9 +
 libavcodec/m264dec.c | 476 +++
 libavcodec/m264dec.h |  42 
 libavcodec/m264enc.c | 289 
 libavcodec/m264enc.h |  39 
 libavcodec/profiles.c|   5 +
 libavcodec/profiles.h|   1 +
 16 files changed, 922 insertions(+), 2 deletions(-)
 create mode 100644 .vscode/settings.json
 create mode 100644 libavcodec/.vscode/settings.json
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..4cdd683
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,27 @@
+{
+   "files.associations": {
+  "avcodec.h": "c",
+  "nvdec.h": "c",
+  "config.h": "c",
+  "avassert.h": "c",
+  "iostream": "cpp",
+  "profiles.h": "c",
+  "swscale.h": "c",
+  "array": "c",
+  "functional": "c",
+  "hash_map": "c",
+  "initializer_list": "c",
+  "utility": "c",
+  "*.tcc": "cpp",
+  "deque": "cpp",
+  "list": "cpp",
+  "vector": "cpp",
+  "system_error": "cpp",
+  "bitset": "cpp",
+  "valarray": "cpp",
+  "adpcm_data.h": "c",
+  "blockdsp.h": "c",
+  "channel_layout.h": "c",
+  "h264chroma.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/Changelog b/Changelog
index c90f119..f70368b 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
 - dhav demuxer
 - PCM-DVD encoder
 - GIF parser
+- M264 encoder
 
 
 version 4.1:
diff --git a/configure b/configure
index b062b63..161beee 100755
--- a/configure
+++ b/configure
@@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
 dnxhd_decoder_select="blockdsp idctdsp"
 dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"
+#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"
 dolby_e_decoder_select="mdct"
 dvvideo_decoder_select="dvprofile idctdsp"
 dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..e012bad 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -828,6 +828,7 @@ following image formats are supported:
 @item Deluxe Paint Animation @tab @tab  X
 @item DNxHD  @tab   X @tab  X
 @tab aka SMPTE VC3
+@item M264   @tab   X @tab  
 @item Duck TrueMotion 1.0   @tab @tab  X
 @tab fourcc: DUCK
 @item Duck TrueMotion 2.0@tab @tab  X
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6abcc57..b8fa266 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output, int64_
 if (!*got_output || ret < 0)
 return ret;
 
+   if(*got_output)
+   {
+  if(decoded_frame->width == 0)
+  {
+ av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context %d,%d,%d != %d,%d,%d\n",
+   decoded_frame->width,
+   decoded_frame->height,
+   decoded_frame->format,
+   ist->dec_ctx->width,
+   ist->dec_ctx->height,
+   ist->dec_ctx->pix_fmt);
+  }
+   }
+
 if(ist->top_field_first>=0)
 decoded_frame->top_field_first = ist->top_field_first;
 
diff --git a/libavcodec/.vscode/settings.json b/libavcodec/.vscode/settings.json
new file mode 100644
index 000..dc1852f
--- /dev/null
+++ b/libavcodec/.vscode/settings.json
@@ -0,0 +1,5 @@
+{
+   "files.associations": {
+  "amfenc.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff..32d147f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -266,6 +266,8 @@ OBJS-$(CONFIG_DIRAC_DECODER)   += diracdec.o dirac.o diracdsp.o diractab
 OBJS-$(CONFIG_DFA_DECODER) += dfa.o
 OBJS-$(CONFIG_DNXHD_DECODER)   += dnxhddec.o dnxhddata.o
 OBJS-$(CONFIG_DNXHD_ENCODER)   += dnxhdenc.o dnxhddata.o
+OBJS-$(CONFIG_M264_ENCODER)+= m264enc.o
+OBJS-$(CONFIG_M264_DECODER)+= m264dec.o
 OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
 

Re: [FFmpeg-devel] [PATCH 0/5] Clean up CUDA SDK usage and remove non-free requirement

2019-02-25 Thread Soft Works

> I've been thinking about this for a while, but I only recently made the
> realisation that compiling cuda kernels to the ptx format does not
> introduce any non-free dependencies - the ptx files are an intermediate
> assembly code format that is actually compiled to binary form at
> runtime. With that understood, we just need to switch the remaining
> users of the CUDA SDK to ffnvcodec and we will remove the non-free
> entanglements from cuda.
>
> Philip Langdale (5):
>   configure: Add an explicit check and option for nvcc
>   avfilter/vf_yadif_cuda: Switch to using ffnvcodec
>   avfilter/vf_scale_cuda: Switch to using ffnvcodec
>   avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec
>   configure: Remove cuda_sdk dependency option
>
>  configure|  36 ++-
>  libavfilter/vf_scale_cuda.c  | 168 +--
>  libavfilter/vf_scale_cuda.cu |  73 +++---
>  libavfilter/vf_thumbnail_cuda.c  | 147 +++
>  libavfilter/vf_thumbnail_cuda.cu |  25 +++--
>  libavfilter/vf_yadif_cuda.c  |  58 ++-
>  6 files changed, 281 insertions(+), 226 deletions(-)
>
> --
> 2.19.1

LGTM

We've tested the yadif_cuda and scale_cuda filters after applying all
patches and it's working fine. (Windows builds via MSYS2, CUDA SDK 8.0)

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


[FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Yufei He
Hi

I just finished a new codec for h.264, how to send patches to review ?

This  is my first piece of code  for ffmpeg.


When you submit your patch, please use git format-patch or git send-email.
/

I did "git format-patch", but where is the patch?

My git said " git: 'send-email' is not a git command. See 'git --help'."

Please help.

Thanks.

Yufei.



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


Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available

2019-02-25 Thread Mathieu Duponchelle
Ping? :)

On 2/17/19 1:23 PM, Mathieu Duponchelle wrote:
>> It would be better to test against a decoder from a unrelated codebase
>> Otherwise its a bit like testing your new language skills by talking with
>> yourself.
> I have just tested with gstreamer's mpegvideoparse element, it detects the 
> closed captions
> as expected:
>
> 0:00:00.602266814 27833   0x810400 DEBUG mpegvideoparse 
> gstmpegvideoparse.c:507:parse_user_data_packet: CEA-708 closed 
> captions, 60 bytes
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/error_resilience: Use a symmetric check for skipping MV estimation

2019-02-25 Thread Michael Niedermayer
On Tue, Feb 19, 2019 at 09:09:22PM +0100, Michael Niedermayer wrote:
> This speeds up the testcase by a factor of 4
> 
> Fixes: Timeout
> Fixes: 
> 13100/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5767533905313792
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/error_resilience.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Fix stereo3d memleak

2019-02-25 Thread Michael Niedermayer
On Mon, Feb 18, 2019 at 01:07:55AM +0100, Michael Niedermayer wrote:
> Fixes: 
> 12937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5714945346371584
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mjpegdec.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

Those who are best at talking, realize last or never when they are wrong.


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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/arbc: Check nb_tiles against dimensions

2019-02-25 Thread Michael Niedermayer
On Mon, Feb 18, 2019 at 01:07:56AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 12967/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARBC_fuzzer-5639021454163968
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/arbc.c | 6 ++
>  1 file changed, 6 insertions(+)

will apply

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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


Re: [FFmpeg-devel] [PATCH] avformat/mov: fix start_time for streams with empty edits in the middle

2019-02-25 Thread Vittorio Giovara
On Sat, Feb 23, 2019 at 1:09 PM Vittorio Giovara 
wrote:

> Empty edits can occur at any position within the edit list except for at
> the end. Empty edits in the middle should not impact the reported stream
> start_time or the video PTS adjustment, so only include empty edits at
> the start of the list in empty_edits_sum_duration.
>
> Please see attachment.
>

Any objections to pushing this later today?
Thanks
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec/aic: Check remaining bits in aic_decode_coeffs()

2019-02-25 Thread Michael Niedermayer
Fixes: Timeout (78 seconds -> 2 seconds)
Fixes: 
13186/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AIC_fuzzer-5639516533030912

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

diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index 9c6f806655..dc28c83661 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -208,6 +208,9 @@ static int aic_decode_coeffs(GetBitContext *gb, int16_t 
*dst,
 int mb, idx;
 unsigned val;
 
+if (get_bits_left(gb) < 5)
+return AVERROR_INVALIDDATA;
+
 has_skips  = get_bits1(gb);
 coeff_type = get_bits1(gb);
 coeff_bits = get_bits(gb, 3);
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.

2019-02-25 Thread C.H.Liu
 Would you mind share your input file? I still can’t reproduce the OOM.


I have tried several types of mp4.

I also tried to create a file like yours. According to the snapshot, seems
it has no ‘sidx’ box and enable ‘use_mfra_for’.

Massif didn’t report update_frag_index() function. I didn’t see an extra
heap as big as here, either.


The code around line 1257 creates an array of fragment indices for each
track. It should be very small. Interesting.

Sorry for disturbing.


Thanks and Regards,

Charles

Michael Niedermayer  于2019年2月23日周六 下午5:35写道:

> On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote:
> > I can’t reproduce the OOM. Is it possible the problem relate to a
> specific
> > clip?
> >
> > Here is my test steps:
> > 1. To ensure that it’s not affected by caches, delete all except the .git
> > dir in my code dir. Then checkout again.
> > 2. To ensure that the latest test clips are used. make fate-rsync
> > SAMPLES=fate-suite/
> > 3. To ensure that OS environment is clean, run test in docker.
> > Below is one of my test logs:
>
> heres some massif output that should show where the exessive allocation
> happens:
> (note the box has 14gb free and the input file is less than 4kb size)
>
> snapshot=70
> #---
> time=1856698079
> mem_heap_B=8487679
> mem_heap_extra_B=522580313
> mem_stacks_B=0
> heap_tree=peak
> n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
>  n2: 8298639 0x12AAF2B: av_malloc (mem.c:87)
>   n1: 8294364 0x12AAF59: av_malloc (mem.c:126)
>n1: 8294364 0x12AB24B: av_mallocz (mem.c:238)
> n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195)
>  n1: 8294364 0x743749: update_frag_index (mov.c:1257)
>   n1: 8294364 0x756174: read_tfra (mov.c:7293)
>n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344)
> n1: 8294364 0x743B01: mov_read_moof (mov.c:1338)
>  n1: 8294364 0x754A0C: mov_read_default (mov.c:6841)
>   n1: 8294364 0x756596: mov_read_header (mov.c:7385)
>n1: 8294364 0x8254BB: avformat_open_input (utils.c:631)
> n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104)
>  n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273)
>   n1: 8294364 0x41F7F8: ffmpeg_parse_options
> (ffmpeg_opt.c:3313)
>n0: 8294364 0x43DFC6: main (ffmpeg.c:4869)
>   n0: 4275 in 7 places, all below massif's threshold (01.00%)
>  n0: 189040 in 8 places, all below massif's threshold (01.00%)
>
>
> [...]
> --
> 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
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] libavformat/movenc: mov: added subtitle codec tags to codec tag list

2019-02-25 Thread Paweł Wegner
This fixes avformat_query_codec incorrectly returning 0 for
mov container and mov_text subtitles.

Signed-off-by: Paweł Wegner 
---
 libavformat/movenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 77943304b5..8969d5b170 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6858,7 +6858,7 @@ AVOutputFormat ff_mov_muxer = {
 .deinit= mov_free,
 .flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH | 
AVFMT_TS_NEGATIVE,
 .codec_tag = (const AVCodecTag* const []){
-ff_codec_movvideo_tags, ff_codec_movaudio_tags, 0
+ff_codec_movvideo_tags, ff_codec_movaudio_tags, 
ff_codec_movsubtitle_tags, 0
 },
 .check_bitstream   = mov_check_bitstream,
 .priv_class= _muxer_class,
-- 
2.17.1

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


[FFmpeg-devel] [PATCH v3] avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions

2019-02-25 Thread gxw
VP9 decoding speed improved about 60.5%(from 38fps to 61fps, tested on loongson 
3A3000).
---
 libavcodec/mips/Makefile   |   1 +
 libavcodec/mips/vp9_mc_mmi.c   | 628 +
 libavcodec/mips/vp9dsp_init_mips.c |  42 +++
 libavcodec/mips/vp9dsp_mips.h  |  50 +++
 libavutil/mips/mmiutils.h  |  15 +
 5 files changed, 736 insertions(+)
 create mode 100644 libavcodec/mips/vp9_mc_mmi.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index c827649..c5b54d5 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -88,3 +88,4 @@ MMI-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_mmi.o
 MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o
 MMI-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_mmi.o
 MMI-OBJS-$(CONFIG_VP3DSP) += mips/vp3dsp_idct_mmi.o
+MMI-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_mmi.o
diff --git a/libavcodec/mips/vp9_mc_mmi.c b/libavcodec/mips/vp9_mc_mmi.c
new file mode 100644
index 000..e7a8387
--- /dev/null
+++ b/libavcodec/mips/vp9_mc_mmi.c
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2019 gxw 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/vp9dsp.h"
+#include "libavutil/mips/mmiutils.h"
+#include "vp9dsp_mips.h"
+
+#define GET_DATA_H_MMI   \
+"pmaddhw%[ftmp4],%[ftmp4],   %[filter1]\n\t" \
+"pmaddhw%[ftmp5],%[ftmp5],   %[filter2]\n\t" \
+"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
+"punpckhwd  %[ftmp5],%[ftmp4],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[ftmp6],%[ftmp6],   %[filter1]\n\t" \
+"pmaddhw%[ftmp7],%[ftmp7],   %[filter2]\n\t" \
+"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
+"punpckhwd  %[ftmp7],%[ftmp6],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
+"punpcklwd  %[srcl], %[ftmp4],   %[ftmp6]  \n\t" \
+"pmaddhw%[ftmp8],%[ftmp8],   %[filter1]\n\t" \
+"pmaddhw%[ftmp9],%[ftmp9],   %[filter2]\n\t" \
+"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
+"punpckhwd  %[ftmp9],%[ftmp8],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp10],   %[ftmp10],  %[filter1]\n\t" \
+"pmaddhw%[ftmp11],   %[ftmp11],  %[filter2]\n\t" \
+"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
+"punpckhwd  %[ftmp11],   %[ftmp10],  %[ftmp0]  \n\t" \
+"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
+"punpcklwd  %[srch], %[ftmp8],   %[ftmp10] \n\t"
+
+#define GET_DATA_V_MMI   \
+"punpcklhw  %[srcl], %[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[srcl], %[srcl],%[filter10]   \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp6],   %[ftmp7]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter32]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter54]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp10],  %[ftmp11] \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter76]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpckhhw  %[srch], %[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[srch], %[srch],%[filter10]   \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp6],   %[ftmp7]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter32]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter54]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp10],  %[ftmp11] \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter76]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t"
+
+static void