Re: [FFmpeg-devel] Possible memory leaks in dshow capture

[Oliver Collyer]

> On 1 Jan 2019, at 23:58, James Almer  wrote:
> 
> On 1/1/2019 5:01 PM, Oliver Collyer wrote:
>> -- Block 26224 at 0x74240F70: 151 bytes --
>>  Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes
>>  Call Stack (TID 55752):
>>ucrtbased.dll!aligned_malloc()
>>c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>> + 0x10 bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
>> emu-server.exe!libAVPin_Setup() + 0xA bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
>> emu-server.exe!libAVPin_Create() + 0x9B bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
>> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
>> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
>> emu-server.exe!dshow_open_device() + 0x1C bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1150): 
>> emu-server.exe!dshow_read_header() + 0x18 bytes
>>c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
>> emu-server.exe!avformat_open_input() + 0x11 bytes
>>c:\users\oliver\perforce\non-si\emu\shared\dsdevice_streaming_session.cpp 
>> (1142): 
>> emu-server.exe!DSDEVICE_STREAMING_SESSION::CAPTURE_THREAD::thread_run() + 
>> 0x23 bytes
>>c:\users\oliver\perforce\non-si\emu\shared\thread_base.cpp (241): 
>> emu-server.exe!THREAD_BASE::thread_func() + 0xE bytes
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>> (16707566): emu-server.exe!std::_Invoker_functor::_Call> *),void *>() + 0x2B bytes
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>> (16707566): emu-server.exe!std::invoke() + 
>> 0x31 bytes
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (239): 
>> emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Execute<0,1>()
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (245): 
>> emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Run() + 0x19 bytes
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (231): 
>> emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Go()
>>c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (209): 
>> emu-server.exe!std::_Pad::_Call_func()
>>ucrtbased.dll!register_onexit_function() + 0x4A8 bytes
>>ucrtbased.dll!register_onexit_function() + 0xE1 bytes
>>KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>>ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>>  Data:
>>70 0F 24 7446 02 00 00ED ED ED EDED ED ED ED p.$tF... 
>> 
>>36 DE C8 49F7 7F 00 0068 F0 CA 49F7 7F 00 00 6..I 
>> h..I
>>8D 99 CA 49F7 7F 00 001F D6 C9 49F7 7F 00 00 ...I 
>> ...I
>>C9 9E CA 49F7 7F 00 00B7 FD C8 49F7 7F 00 00 ...I 
>> ...I
>>22 EC C9 49F7 7F 00 007E E1 C8 49F7 7F 00 00 "..I 
>> ~..I
>>3B 82 CA 49F7 7F 00 00CD CD CD CDCD CD CD CD ;..I 
>> 
>>CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>>CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>>CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>>CD CD CD CDCD CD CD   
>> 
>> 
>> 
>> -- Block 26879 at 0x74242E10: 151 bytes --
>>  Leak Hash: 0xA886255F, Count: 1, Total 151 bytes
>>  Call Stack (TID 55752):
>>ucrtbased.dll!aligned_malloc()
>>c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>> + 0x10 bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
>> emu-server.exe!libAVPin_Setup() + 0xA bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
>> emu-server.exe!libAVPin_Create() + 0x9B bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
>> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
>> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
>> emu-server.exe!dshow_open_device() + 0x1C bytes
>>c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1157): 
>> emu-server.exe!dshow_read_header() + 0x1E bytes
>>c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
>> emu-server.exe!avformat_open_input() + 0x11 byte

[FFmpeg-devel] [PATCH] avformat/dashdec: control download speed when in live stream mode

[Steven Liu]

fix ticket: 7369
check the duration is less than the fragment duration,
retry when the condition is true.

Signed-off-by: Steven Liu 
---
 libavformat/dashdec.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index f4f4e935de..11c1307b18 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -108,6 +108,7 @@ struct representation {
 int64_t cur_seg_offset;
 int64_t cur_seg_size;
 struct fragment *cur_seg;
+int64_t last_load_time;
 
 /* Currently active Media Initialization Section */
 struct fragment *init_section;
@@ -1084,6 +1085,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 }
 }
 
+if (rep)
+rep->last_load_time = get_current_time_in_sec();
 video_rep_idx += type == AVMEDIA_TYPE_VIDEO;
 audio_rep_idx += type == AVMEDIA_TYPE_AUDIO;
 subtitle_rep_idx += type == AVMEDIA_TYPE_SUBTITLE;
@@ -1382,6 +1385,9 @@ static int64_t calc_cur_seg_no(AVFormatContext *s, struct 
representation *pls)
 } else {
 num = pls->first_seq_no;
 }
+
+if (pls)
+pls->last_load_time = get_current_time_in_sec();
 return num;
 }
 
@@ -1461,6 +1467,7 @@ static int refresh_manifest(AVFormatContext *s)
 {
 
 int ret = 0, i;
+int64_t cur_time = get_current_time_in_sec();
 DASHContext *c = s->priv_data;
 
 // save current context
@@ -1505,6 +1512,11 @@ static int refresh_manifest(AVFormatContext *s)
 for (i = 0; i < n_videos; i++) {
 struct representation *cur_video = videos[i];
 struct representation *ccur_video = c->videos[i];
+if (cur_video)
+cur_video->last_load_time = cur_time;
+if (ccur_video)
+ccur_video->last_load_time = cur_time;
+
 if (cur_video->timelines) {
 // calc current time
 int64_t currentTime = 
get_segment_start_time_based_on_timeline(cur_video, cur_video->cur_seq_no) / 
cur_video->fragment_timescale;
@@ -1521,6 +1533,11 @@ static int refresh_manifest(AVFormatContext *s)
 for (i = 0; i < n_audios; i++) {
 struct representation *cur_audio = audios[i];
 struct representation *ccur_audio = c->audios[i];
+if (cur_audio)
+cur_audio->last_load_time = cur_time;
+if (ccur_audio)
+ccur_audio->last_load_time = cur_time;
+
 if (cur_audio->timelines) {
 // calc current time
 int64_t currentTime = 
get_segment_start_time_based_on_timeline(cur_audio, cur_audio->cur_seq_no) / 
cur_audio->fragment_timescale;
@@ -1629,6 +1646,8 @@ static struct fragment *get_current_fragment(struct 
representation *pls)
 av_free(tmpfilename);
 seg->size = -1;
 }
+if (pls)
+pls->last_load_time = get_current_time_in_sec();
 
 return seg;
 }
@@ -1747,6 +1766,10 @@ static int read_data(void *opaque, uint8_t *buf, int 
buf_size)
 DASHContext *c = v->parent->priv_data;
 
 restart:
+if (c->is_live && v->fragment_duration != 0 && v->fragment_timescale != 0)
+if (get_current_time_in_sec() - v->last_load_time < 
(v->fragment_duration / v->fragment_timescale)) {
+goto restart;
+}
 if (!v->input) {
 free_fragment(&v->cur_seg);
 v->cur_seg = get_current_fragment(v);
-- 
2.15.2 (Apple Git-101.1)



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

Re: [FFmpeg-devel] [PATCH V7] libavfilter: add transpose_vaapi filter

[Zhou, Zachary]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, December 31, 2018 2:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V7] libavfilter: add transpose_vaapi filter
> 
> On 25/12/2018 06:16, Zachary Zhou wrote:
> > Swap width and height when do clock/cclock rotation Add
> > reversal/reversal_flip options
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
> > -c:v h264_vaapi output.h264
> >
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure|   2 +
> >  libavfilter/Makefile |   1 +
> >  libavfilter/allfilters.c |   1 +
> >  libavfilter/transpose.h  |   2 +
> >  libavfilter/vf_transpose_vaapi.c | 338
> > +++
> >  5 files changed, 344 insertions(+)
> >  create mode 100644 libavfilter/vf_transpose_vaapi.c
> >
> > diff --git a/configure b/configure
> > index be49c19b88..04ee671a60 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3481,6 +3481,7 @@ tinterlace_pad_test_deps="tinterlace_filter"
> >  tonemap_filter_deps="const_nan"
> >  tonemap_opencl_filter_deps="opencl const_nan"
> >  transpose_opencl_filter_deps="opencl"
> > +transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
> >  unsharp_opencl_filter_deps="opencl"
> >  uspp_filter_deps="gpl avcodec"
> >  vaguedenoiser_filter_deps="gpl"
> > @@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h"
> > DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
> >
> >  check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> >  check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > +rotation_flags
> >  check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> >  check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> >  check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > 6e2658186d..4246d3480f 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -394,6 +394,7 @@ OBJS-$(CONFIG_TPAD_FILTER)   +=
> vf_tpad.o
> >  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
> >  OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  += vf_transpose_npp.o
> cuda_check.o
> >  OBJS-$(CONFIG_TRANSPOSE_OPENCL_FILTER)   += vf_transpose_opencl.o
> opencl.o opencl/transpose.o
> > +OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+= vf_transpose_vaapi.o
> vaapi_vpp.o
> >  OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
> >  OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  += vf_premultiply.o
> framesync.o
> >  OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> > a600069500..0b82ff7ced 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -373,6 +373,7 @@ extern AVFilter ff_vf_tpad;  extern AVFilter
> > ff_vf_transpose;  extern AVFilter ff_vf_transpose_npp;  extern
> > AVFilter ff_vf_transpose_opencl;
> > +extern AVFilter ff_vf_transpose_vaapi;
> >  extern AVFilter ff_vf_trim;
> >  extern AVFilter ff_vf_unpremultiply;
> >  extern AVFilter ff_vf_unsharp;
> > diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h index
> > d4bb4da1ae..87936d0512 100644
> > --- a/libavfilter/transpose.h
> > +++ b/libavfilter/transpose.h
> > @@ -29,6 +29,8 @@ enum TransposeDir {
> >  TRANSPOSE_CLOCK,
> >  TRANSPOSE_CCLOCK,
> >  TRANSPOSE_CLOCK_FLIP,
> > +TRANSPOSE_REVERSAL,
> > +TRANSPOSE_REVERSAL_FLIP,
> 
> Add the missing element of D_4 here.
> 
> It's not obvious that reversal is "rotate by half-turn" rather than some sort 
> of
> flip, maybe a comment.
> 
> I think calling the others "HFLIP"/"VFLIP" to match the standalone filters 
> would
> be clearer, too.

I am try to adding following -
enum TransposeDir {
  
+TRANSPOSE_REVERSAL,   // rotate by half-turn
+TRANSPOSE_HFLIP,
+TRANSPOSE_VFLIP,
}


> 
> >  };
> >
> >  #endif
> > diff --git a/libavfilter/vf_transpose_vaapi.c
> > b/libavfilter/vf_transpose_vaapi.c
> > new file mode 100644
> > index 00..1c7bb0c1a7
> > --- /dev/null
> > +++ b/libavfilter/vf_transpose_vaapi.c
> > @@ -0,0 +1,338 @@
> > +/*
> > + * 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
> > + * 

[FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

Hello

So this time I'm reporting some potential memory leaks in the x265 encoder. 
There are a few hundred following a short encode session, but all seem to have 
the same call stack as below but varying allocation sizes.

I am calling avcodec_open2() to open the encoder and then 
avcodec_free_context() to clean it up afterwards, as per the documentation.

My code is built against the latest from 
https://github.com/ShiftMediaProject/FFmpeg 
 
> and I'm using Visual Leak 
Detector to detect the leaks.

Or would this be better posted in whatever mailing list x265 development uses?

Regards

Oliver

-- Block 63379 at 0x8CC3A370: 262225 bytes --
  Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
  Call Stack:
ucrtbased.dll!aligned_malloc()
emu-server.exe!x265::x265_malloc() + 0x48 bytes
emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes
  Data:
70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 

7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.


Visual Leak Detector detected 236 memory leaks (25197214 bytes).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 12:58, Oliver Collyer  wrote:
> 
> Hello
> 
> So this time I'm reporting some potential memory leaks in the x265 encoder. 
> There are a few hundred following a short encode session, but all seem to 
> have the same call stack as below but varying allocation sizes.
> 
> I am calling avcodec_open2() to open the encoder and then 
> avcodec_free_context() to clean it up afterwards, as per the documentation.
> 
> My code is built against the latest from 
> https://github.com/ShiftMediaProject/FFmpeg 
>  
>  > and I'm using Visual Leak 
> Detector to detect the leaks.
> 
> Or would this be better posted in whatever mailing list x265 development uses?
> 
> Regards
> 
> Oliver
> 
> -- Block 63379 at 0x8CC3A370: 262225 bytes --
>  Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
>  Call Stack:
>ucrtbased.dll!aligned_malloc()
>emu-server.exe!x265::x265_malloc() + 0x48 bytes
>emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
>emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
>emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
>emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
>emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
>emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
>emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
>emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
>emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
>emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
>KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>  Data:
>70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 
> 
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
> 
> 
> Visual Leak Detector detected 236 memory leaks (25197214 bytes).

So looking into this some more, according to the x265 docs:

"When the application has completed all encodes, it should call x265_cleanup() 
to free process global, particularly if a memory-leak detection tool is being 
used. x265_cleanup() also resets the saved CTU size so it will be possible to 
create a new encoder with a different CTU size:
/* x265_cleanup:
 * release library static allocations, reset configured CTU size */
void x265_cleanup(void);"

This function explicitly frees the allocations being reported by VLD above.

I cannot see that this done anywhere by the ffmpeg libraries though. Maybe this 
is not considered significant as the OS deals with this on exit?

I did notice in libx265.c...

AVCodec ff_libx265_encoder = {
.name = "libx265",
.long_name= NULL_IF_CONFIG_SMALL("libx265 H.265 / HEVC"),
.type = AVMEDIA_TYPE_VIDEO,
.id   = AV_CODEC_ID_HEVC,
.init = libx265_encode_init,
.init_static_data = libx265_encode_init_csp,
.encode2  = libx265_encode_frame,
.close= libx265_encode_close,
.priv_data_size   = sizeof(libx265Context),
.priv_class   = &class,
.defaults = x265_defaults,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
.wrapper_name = "libx265",
};

...there is the concept of initialisation of static data, but looking at 
AVCodec there is no similar cleaning-up function (confirmed by looking at 
avcodec/allcodecs.c).

Is there a precedent for how to handle something like this - I don't see how I 
can access the x265_api pointer in order to call the x265_clea

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Nicolas George]

Uwe Freese (2019-01-01):
> > This can be optimized, and since it is the inner loop of the filter, I
> > think it is worth it. You can declare a pointer that will stay the same
> > for the whole y loop:
> > 
> > double *xweight = uglarmtable + (y - logo_y1) * (logo_w - 1);
> > 
> > and then use it in that loop:
> > 
> > interpd += ... * xweight[abs(bx - (x - logo_x1))];
> > 
> > It avoids a lot of multiplications.
> 
> I'm not sure about this point. First, I would absolutely assume from the
> compiler that it optimizes expressions like "(logo_w - 1)" or a fixed offset
> to access the array in the loop and that they are only calculated once.

Relying a lot on compiler optimizations is a sure way of being
disappointed. But the logo_w_minus_one variable was not about
optimization but about organization. Each time there is the same
computation at several places, it is a sign that a specific variable
should probably be used. That way, if the design changes a little, only
the initialization of the variable needs to be changed.

In this particular instance, logo_w_minus_one was not a good name (it
was for explaining); table_stride would be better. That way, if you
decide to change the structure of the table, you do not need to look at
all uses of logo_w, you just need to update the initialization of
table_stride.

> Secondly, I don't exactly understand how *xweight in your example should be
> used (and would mean smaller or easier code).

XXX

> > > +interp = (uint64_t)(interpd /
> > > +uglarmweightsum[(x - logo_x1) - 1 + (y - logo_y1 - 
> > > 1) * (logo_w - 2)]);
> > The cast to uint64_t seems suspicious. Can you explain?
> 
> Every pixel value of the inner logo area is an integer. Only for the
> calculation of the weighted average, all values use floats. At the end, it
> is rounded (truncated) to an int.

int and uint64_t are not the same thing. Why uint64_t?

> > pow(x * x * aspect2 + y * y, exponent / 2);
> 
> Hm. Again, I'm unsure if this "optimization" is worth it. I wouldn't do this
> normally.

In this particular instance, definitely yes. Compilers have very little
latitude to optimize floating point operations, and they will certainly
not optimize mathematical functions based on subtle arithmetic
properties. This is a C compiler, not a TI-89.

> > But I have a better suggestion:
> > 
> > #define MAX_SUB 2
> > 
> > double uglarmtable[MAX_SUB + 1][MAX_SUB + 1]
> > 
> > and use uglarmtable[hsub][vsub]. That way, for YUVA420P for example, the
> > table will be computed only once for Y and A and once for U and V.
> > 
> > The assert is still needed with that solution, though.
> 
> I don't understand this. Please provide a complete example, or it stays as
> it is. - and could of course be optimized later.

I do not see how it could be more complete without including code that
is irrelevant to the example. But since you insist:

#define MAX_SUB 2

typedef struct DelogoContext {
...
double uglarmtable[MAX_SUB + 1][MAX_SUB + 1]
...
}
...
av_assert0(hsub <= MAX_SUB && vsub <= MAX_SUB);
if (!s->uglarmtable[hsub][vsub])
s->uglarmtable[hsub][vsub] = av_malloc_array(...);
...
calc_uglarm_tables(s->uglarmtable[hsub][vsub],
   s->uglarmweightsum[hsub][vsub]);
...
apply_delogo(...,
 s->uglarmtable[hsub][vsub],
 s->uglarmweightsum[hsub][vsub]);

> But why should the for loop run in xy mode and check "planes count" times to
> free the memory? The code without the "if" also looks to me more like this
> is not checked by mistake.

This is the usual way this project does things: free everything
unconditionally. The rationale is that it is less likely to lead to
leaks in case of code change.


> Hope that the code is correct like this?
> 
> s->uglarmtable[plane] =
> av_malloc_array((logo_w - 1) * (logo_h - 1), 
> sizeof(s->uglarmtable[plane]));

Sorry, no: you are taking the size of the pointer uglarmtable[plane];
you need to take the size of the pointed objects *uglarmtable[plane].

Regards,

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

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

[Oliver Collyer]

> On 2 Jan 2019, at 11:30, Oliver Collyer  wrote:
> 
> 
> 
>> On 1 Jan 2019, at 23:58, James Almer  wrote:
>> 
>> On 1/1/2019 5:01 PM, Oliver Collyer wrote:
>>> -- Block 26224 at 0x74240F70: 151 bytes --
>>> Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes
>>> Call Stack (TID 55752):
>>>   ucrtbased.dll!aligned_malloc()
>>>   c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>>> + 0x10 bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
>>> emu-server.exe!libAVPin_Setup() + 0xA bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
>>> emu-server.exe!libAVPin_Create() + 0x9B bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
>>> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
>>> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
>>> emu-server.exe!dshow_open_device() + 0x1C bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1150): 
>>> emu-server.exe!dshow_read_header() + 0x18 bytes
>>>   c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
>>> emu-server.exe!avformat_open_input() + 0x11 bytes
>>>   c:\users\oliver\perforce\non-si\emu\shared\dsdevice_streaming_session.cpp 
>>> (1142): 
>>> emu-server.exe!DSDEVICE_STREAMING_SESSION::CAPTURE_THREAD::thread_run() + 
>>> 0x23 bytes
>>>   c:\users\oliver\perforce\non-si\emu\shared\thread_base.cpp (241): 
>>> emu-server.exe!THREAD_BASE::thread_func() + 0xE bytes
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>>> (16707566): emu-server.exe!std::_Invoker_functor::_Call>> *),void *>() + 0x2B bytes
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>>> (16707566): emu-server.exe!std::invoke() + 
>>> 0x31 bytes
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (239): 
>>> emu-server.exe!std::_LaunchPad>> (__cdecl*)(void *),void *>,std::default_delete>> (__cdecl*)(void *),void *> > > >::_Execute<0,1>()
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (245): 
>>> emu-server.exe!std::_LaunchPad>> (__cdecl*)(void *),void *>,std::default_delete>> (__cdecl*)(void *),void *> > > >::_Run() + 0x19 bytes
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (231): 
>>> emu-server.exe!std::_LaunchPad>> (__cdecl*)(void *),void *>,std::default_delete>> (__cdecl*)(void *),void *> > > >::_Go()
>>>   c:\program files (x86)\microsoft visual 
>>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (209): 
>>> emu-server.exe!std::_Pad::_Call_func()
>>>   ucrtbased.dll!register_onexit_function() + 0x4A8 bytes
>>>   ucrtbased.dll!register_onexit_function() + 0xE1 bytes
>>>   KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>>>   ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>>> Data:
>>>   70 0F 24 7446 02 00 00ED ED ED EDED ED ED ED p.$tF... 
>>> 
>>>   36 DE C8 49F7 7F 00 0068 F0 CA 49F7 7F 00 00 6..I 
>>> h..I
>>>   8D 99 CA 49F7 7F 00 001F D6 C9 49F7 7F 00 00 ...I 
>>> ...I
>>>   C9 9E CA 49F7 7F 00 00B7 FD C8 49F7 7F 00 00 ...I 
>>> ...I
>>>   22 EC C9 49F7 7F 00 007E E1 C8 49F7 7F 00 00 "..I 
>>> ~..I
>>>   3B 82 CA 49F7 7F 00 00CD CD CD CDCD CD CD CD ;..I 
>>> 
>>>   CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>>> 
>>>   CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>>> 
>>>   CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>>> 
>>>   CD CD CD CDCD CD CD   
>>> 
>>> 
>>> 
>>> -- Block 26879 at 0x74242E10: 151 bytes --
>>> Leak Hash: 0xA886255F, Count: 1, Total 151 bytes
>>> Call Stack (TID 55752):
>>>   ucrtbased.dll!aligned_malloc()
>>>   c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>>> + 0x10 bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
>>> emu-server.exe!libAVPin_Setup() + 0xA bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
>>> emu-server.exe!libAVPin_Create() + 0x9B bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
>>> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
>>> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
>>> emu-server.exe!dshow_open_device() + 0x1C bytes
>>>   c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1157): 
>>> emu-server.exe!dshow_read_header() + 0x1E 

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 16:03, Oliver Collyer  wrote:
> 
> 
> 
>> On 2 Jan 2019, at 12:58, Oliver Collyer  wrote:
>> 
>> Hello
>> 
>> So this time I'm reporting some potential memory leaks in the x265 encoder. 
>> There are a few hundred following a short encode session, but all seem to 
>> have the same call stack as below but varying allocation sizes.
>> 
>> I am calling avcodec_open2() to open the encoder and then 
>> avcodec_free_context() to clean it up afterwards, as per the documentation.
>> 
>> My code is built against the latest from 
>> https://github.com/ShiftMediaProject/FFmpeg 
>>  
>> > > and I'm using Visual Leak 
>> Detector to detect the leaks.
>> 
>> Or would this be better posted in whatever mailing list x265 development 
>> uses?
>> 
>> Regards
>> 
>> Oliver
>> 
>> -- Block 63379 at 0x8CC3A370: 262225 bytes --
>> Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
>> Call Stack:
>>   ucrtbased.dll!aligned_malloc()
>>   emu-server.exe!x265::x265_malloc() + 0x48 bytes
>>   emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
>>   emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
>>   emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
>>   emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
>>   emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
>>   emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
>>   emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
>>   emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
>>   emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
>>   emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
>>   KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>>   ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>> Data:
>>   70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 
>> 
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>> 
>> 
>> Visual Leak Detector detected 236 memory leaks (25197214 bytes).
> 
> So looking into this some more, according to the x265 docs:
> 
> "When the application has completed all encodes, it should call 
> x265_cleanup() to free process global, particularly if a memory-leak 
> detection tool is being used. x265_cleanup() also resets the saved CTU size 
> so it will be possible to create a new encoder with a different CTU size:
> /* x265_cleanup:
> * release library static allocations, reset configured CTU size */
> void x265_cleanup(void);"
> 
> This function explicitly frees the allocations being reported by VLD above.
> 
> I cannot see that this done anywhere by the ffmpeg libraries though. Maybe 
> this is not considered significant as the OS deals with this on exit?
> 
> I did notice in libx265.c...
> 
> AVCodec ff_libx265_encoder = {
>.name = "libx265",
>.long_name= NULL_IF_CONFIG_SMALL("libx265 H.265 / HEVC"),
>.type = AVMEDIA_TYPE_VIDEO,
>.id   = AV_CODEC_ID_HEVC,
>.init = libx265_encode_init,
>.init_static_data = libx265_encode_init_csp,
>.encode2  = libx265_encode_frame,
>.close= libx265_encode_close,
>.priv_data_size   = sizeof(libx265Context),
>.priv_class   = &class,
>.defaults = x265_defaults,
>.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
>.wrapper_name = "libx265",
> };
> 
> ...there is the concept of initialisation of static data, but looking at 
> AVCodec there is no similar cleaning-up function (confirmed by looking at 

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c

Please use git format-patch to prepare your patches. Also please try to
convince your MUA to use text/plain for patches.

> +static int open_enc_count = 0;
> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;

Static variables are unacceptable. And indeed, these are wrong: you are
counting several instances, possibly of different APIs, but with a
single counter.

The way I read things, the leak you are trying to fix does not exist: it
is global state, kept until the end but not lost.

Regards,

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 18:05, Nicolas George  wrote:
> 
> Oliver Collyer (2019-01-02):
>> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> 
> Please use git format-patch to prepare your patches. Also please try to
> convince your MUA to use text/plain for patches.
> 
>> +static int open_enc_count = 0;
>> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;
> 
> Static variables are unacceptable. And indeed, these are wrong: you are
> counting several instances, possibly of different APIs, but with a
> single counter.
> 

Yes, I see what you mean.

> The way I read things, the leak you are trying to fix does not exist: it
> is global state, kept until the end but not lost.
> 

Well, as per my earlier post - x265 provides a function to free up this memory 
which otherwise isn't freed up, hence memory debuggers report these allocations 
as leaks, and ffmpeg provides no mechanism to call this function.

I guess the OS frees it up on application exit, but that seems a messy way to 
be going about things, I guess that's why the developers of x265 provided the 
function.

> Regards,
> 
> -- 
>  Nicolas George
> ___
> 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 V4 1/2] avutil: add ROI data struct and bump version

[Vittorio Giovara]

On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:

> The encoders such as libx264 support different QPs offset for different
> MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding.
>
> The ROI info is maintained as side data of AVFrame.
>
> Signed-off-by: Guo, Yejun 
> ---
>  libavutil/frame.c   |  1 +
>  libavutil/frame.h   | 23 +++
>  libavutil/version.h |  2 +-
>  3 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 34a6210..bebc50e 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> data";
>  #endif
>  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> SMPTE2094-40 (HDR10+)";
> +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 582ac47..3460b01 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
>   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
>   */
>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> +
> +/**
> + * Regions Of Interest, the data is an array of AVROI type, the array
> size
> + * is implied by AVFrameSideData::size / sizeof(AVROI).
> + */
> +AV_FRAME_DATA_ROIS,
>

Any chance i could convince you of unfolding this acronym into
AV_FRAME_REGIONS_OF_INTEREST (and AVRegionOfInterest)?
When I first read it I thought you were talking about Return of Investments
or Request of Invention, which were mildly confusing.

The "AVFrameSideData::size" is a C++-ism, could you please use
"AVFrameSideData.size" like elsewhere in the header?

You should probably document that sizeof() of this struct is part of the
public ABI.


>  };
>
>  enum AVActiveFormatDescription {
> @@ -201,6 +207,23 @@ typedef struct AVFrameSideData {
>  } AVFrameSideData;
>
>  /**
> + * Structure to hold Region Of Interest.
> + *
> + * top/bottom/left/right are coordinates at frame pixel level.
>

what does  "pixel level" mean? May I suggest better wording?

Number of pixels to discard from the the top/bottom/left/right border
of the frame to obtain the region of interest of the frame.

+ * They will be extended internally if the codec requires an alignment.
> + * If the regions overlap, the last value in the list will be used.
>

Isn't this encoder dependent too?


> + *
> + * qoffset is quant offset, it is encoder dependent.

+ */
> +typedef struct AVROI {
> +size_t top;
> +size_t bottom;
> +size_t left;
> +size_t right;
> +int qoffset;
>

so int instead of float?

+} AVROI;
> +
> +/**
>   * This structure describes decoded (raw) audio or video data.
>   *
>   * AVFrame must be allocated using av_frame_alloc(). Note that this only
> diff --git a/libavutil/version.h b/libavutil/version.h
> index f997615..1fcdea9 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Nicolas George]

Nicolas George (2019-01-02):
> Uwe Freese (2019-01-01):
> > > This can be optimized, and since it is the inner loop of the filter, I
> > > think it is worth it. You can declare a pointer that will stay the same
> > > for the whole y loop:
> > > 
> > >   double *xweight = uglarmtable + (y - logo_y1) * (logo_w - 1);
> > > 
> > > and then use it in that loop:
> > > 
> > >   interpd += ... * xweight[abs(bx - (x - logo_x1))];
> > > 
> > > It avoids a lot of multiplications.
> 
> > Secondly, I don't exactly understand how *xweight in your example should be
> > used (and would mean smaller or easier code).
> 
> XXX

Sorry, forgot to fill that part before sending.

Completely untested code:

double *table_t, *table_b, *table_l, *table_r;

table_t = uglarmtable + x + table_stride * y;
table_b = uglarmtable + x + table_stride * (logo_h - y - 1);
table_l = uglarmtable + table_stride * (y - 1) + x;
table_r = uglarmtable + table_stride * (y - 1) + logo_w - x - 1;
/* top+bottom on the left of the current point */
for (bx = 0; bx < x; bx++) {
weightsum += table_t;
weightsum += table_b;
table_t--;
table_b--;
}
/* top+bottom on the right of the current point */
for (; bx < logo_w; bx++) {
weightsum += table_t;
weightsum += table_b;
table_t++;
table_b++;
}
/* left+right above the current point */
for (by = 1; by < y; by++) {
weightsum += *table_l;
weightsum += *table_r;
table_l -= table_stride;
table_r -= table_stride;
}
/* left+right below the current point */
for (; by < logo_w - 1; by++) {
weightsum += *table_l;
weightsum += *table_r;
table_l += table_stride;
table_r += table_stride;
}
av_assert2(table_t == uglarmtable + (logo_w - x) + table_stride * y);
av_assert2(table_b == uglarmtable + (logo_w - x) + table_stride * (logo_h - 
y - 1));
av_assert2(table_l == uglarmtable + table_stride * (logo_h - y - 1) + x);
av_assert2(table_r == uglarmtable + table_stride * (logo_h - y - 1) + 
logo_w - x - 1;

That makes more lines, but the lines are way simpler: no tricky
arithmetic, all blocks almost identical, with the changes easy to see
and understand.

Regards,

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

>>> +static int open_enc_count = 0;
>>> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;
>> 
>> Static variables are unacceptable. And indeed, these are wrong: you are
>> counting several instances, possibly of different APIs, but with a
>> single counter.
>> 
> 
> Yes, I see what you mean.
> 

Althoughthe data that x265_cleanup() frees is static anyway (see 
Bitcost::Destroy()), so I think this is actually desired behaviour i.e. this is 
global state across all APIs that should be freed up before exit.

Can you clarify what you mean by "static variables are unacceptable". They're 
all over the place in ffmpeg (random example 
https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
 
)...
 what am I missing?

Regards

Oliver



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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> I guess the OS frees it up on application exit, but that seems a messy
> way to be going about things, I guess that's why the developers of
> x265 provided the function.

There is nothing messy about it. Also, other parts of the project do
things like that without freeing, and even without providing an API to
free it. Including internal components.

This is not a leak, it is short-sightedness by leak detectors.

Regards,

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> Can you clarify what you mean by "static variables are unacceptable". They're 
> all over the place in ffmpeg (random example 
> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>  
> )...
>  what am I missing?

The JNI stuff is hardly an example of good practice, we are stuck with
java's awful design.

For the rest, they are not static variables, they are static constants.

There are a few cases 

Regards,

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Hendrik Leppkes]

On Wed, Jan 2, 2019 at 4:33 PM Oliver Collyer  wrote:
>
> Can you clarify what you mean by "static variables are unacceptable". They're 
> all over the place in ffmpeg (random example 
> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>  
> )...
>  what am I missing?
>

We try to clean them up where we can, and new ones are unacceptable.

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 18:38, Nicolas George  wrote:
> 
> Oliver Collyer (2019-01-02):
>> Can you clarify what you mean by "static variables are unacceptable". 
>> They're all over the place in ffmpeg (random example 
>> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>>  
>> )...
>>  what am I missing?
> 
> The JNI stuff is hardly an example of good practice, we are stuck with
> java's awful design.
> 
> For the rest, they are not static variables, they are static constants.
> 
> There are a few cases 
> 

Ok thanks for the clarification about the approach taken for static variable 
usage and memory freeing in the ffmpeg project Nicolas, that is useful to know.

So I could re-write the patch to not use static variables, and I'm perfectly 
happy to do so, but there is no point, right?

Regards

Oliver

> Regards,
> 
> -- 
>  Nicolas George
> ___
> 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] mov: Remove duration-of-last-frame heuristic hack

[Derek Buitenhuis]

On 01/01/2019 15:50, Derek Buitenhuis wrote:
> If there are no objections, I will push in a day or two.

Pushed.

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

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Steinar H. Gunderson]

On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote:
> This is not a leak, it is short-sightedness by leak detectors.

Most modern leak detectors distinguish between memory that's still reachable
(usually not a leak) and memory that's not (almost always a leak). This sounds
like an example of the former.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 19:18, Steinar H. Gunderson  
> wrote:
> 
> On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote:
>> This is not a leak, it is short-sightedness by leak detectors.
> 
> Most modern leak detectors distinguish between memory that's still reachable
> (usually not a leak) and memory that's not (almost always a leak). This sounds
> like an example of the former.
> 

Thanks Steinar. Personally I would always want the tool I am using to tell me 
about memory allocations I had made and not freed, but I guess it partly comes 
down to personal taste!

More importantly in this case though, according to the documentation it is 
necessary to call x265_cleanup() in order for the next encoder to be able to 
use a new CU size.

Here is the original x265 ticket:

https://bitbucket.org/multicoreware/x265/issues/110/add-an-api-to-reset-cached-variables-so
 


I don't know whether encoders can be opened/closed in this manner with 
different CU sizes using the ffmpeg command line tool, but they could be for 
other applications linking to the ffmpeg libraries.

So even if it's not deemed necessary to add an API for the purpose of avoiding 
spurious memory leak reports (fair enough), it might be useful for the above, 
whether though something similar to my patch or maybe just a simple global 
function.

From the docs:

https://x265.readthedocs.io/en/default/api.html 


(Search for x265_cleanup)

Regards

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

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[Vittorio Giovara]

On Wed, Jan 2, 2019 at 4:13 PM Vittorio Giovara 
wrote:

>
>
> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:
>
>> The encoders such as libx264 support different QPs offset for different
>> MBs,
>> it makes possible for ROI-based encoding. It makes sense to add support
>> within ffmpeg to generate/accept ROI infos and pass into encoders.
>>
>> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
>> generates ROI info for that frame, and the encoder finally does the
>> ROI-based encoding.
>>
>> The ROI info is maintained as side data of AVFrame.
>>
>> Signed-off-by: Guo, Yejun 
>> ---
>>  libavutil/frame.c   |  1 +
>>  libavutil/frame.h   | 23 +++
>>  libavutil/version.h |  2 +-
>>  3 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index 34a6210..bebc50e 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
>> AVFrameSideDataType type)
>>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
>> data";
>>  #endif
>>  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
>> SMPTE2094-40 (HDR10+)";
>> +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
>>  }
>>  return NULL;
>>  }
>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>> index 582ac47..3460b01 100644
>> --- a/libavutil/frame.h
>> +++ b/libavutil/frame.h
>> @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
>>   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
>>   */
>>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
>> +
>> +/**
>> + * Regions Of Interest, the data is an array of AVROI type, the
>> array size
>> + * is implied by AVFrameSideData::size / sizeof(AVROI).
>> + */
>> +AV_FRAME_DATA_ROIS,
>>
>
> Any chance i could convince you of unfolding this acronym into
> AV_FRAME_REGIONS_OF_INTEREST (and AVRegionOfInterest)?
> When I first read it I thought you were talking about Return of
> Investments or Request of Invention, which were mildly confusing.
>
> The "AVFrameSideData::size" is a C++-ism, could you please use
> "AVFrameSideData.size" like elsewhere in the header?
>
> You should probably document that sizeof() of this struct is part of the
> public ABI.
>

After thinking some more about this, it's probably a bad idea to embed an
array in a side data. Not only it constrains the structure to only change
at major bumps, but it seems very reminiscent of binary side data which
is/should be not used for newer side data. As a matter of fact side data
normally hosts either structs or simple types like ints or enums only.
Instead of this, why not creating a structure hosting the number of
elements and a pointer? Something like

AVRegionOfInterest {
 size_t top/left/right/bottom
}

AVRegionOfInterestSet {
 int rois_nb;
 AVRegionOfInterest *rois;
}
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[James Almer]

On 1/2/2019 2:18 PM, Vittorio Giovara wrote:
> On Wed, Jan 2, 2019 at 4:13 PM Vittorio Giovara 
> wrote:
> 
>>
>>
>> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:
>>
>>> The encoders such as libx264 support different QPs offset for different
>>> MBs,
>>> it makes possible for ROI-based encoding. It makes sense to add support
>>> within ffmpeg to generate/accept ROI infos and pass into encoders.
>>>
>>> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
>>> generates ROI info for that frame, and the encoder finally does the
>>> ROI-based encoding.
>>>
>>> The ROI info is maintained as side data of AVFrame.
>>>
>>> Signed-off-by: Guo, Yejun 
>>> ---
>>>  libavutil/frame.c   |  1 +
>>>  libavutil/frame.h   | 23 +++
>>>  libavutil/version.h |  2 +-
>>>  3 files changed, 25 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>>> index 34a6210..bebc50e 100644
>>> --- a/libavutil/frame.c
>>> +++ b/libavutil/frame.c
>>> @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
>>> AVFrameSideDataType type)
>>>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
>>> data";
>>>  #endif
>>>  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
>>> SMPTE2094-40 (HDR10+)";
>>> +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
>>>  }
>>>  return NULL;
>>>  }
>>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>>> index 582ac47..3460b01 100644
>>> --- a/libavutil/frame.h
>>> +++ b/libavutil/frame.h
>>> @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
>>>   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
>>>   */
>>>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
>>> +
>>> +/**
>>> + * Regions Of Interest, the data is an array of AVROI type, the
>>> array size
>>> + * is implied by AVFrameSideData::size / sizeof(AVROI).
>>> + */
>>> +AV_FRAME_DATA_ROIS,
>>>
>>
>> Any chance i could convince you of unfolding this acronym into
>> AV_FRAME_REGIONS_OF_INTEREST (and AVRegionOfInterest)?
>> When I first read it I thought you were talking about Return of
>> Investments or Request of Invention, which were mildly confusing.
>>
>> The "AVFrameSideData::size" is a C++-ism, could you please use
>> "AVFrameSideData.size" like elsewhere in the header?
>>
>> You should probably document that sizeof() of this struct is part of the
>> public ABI.
>>
> 
> After thinking some more about this, it's probably a bad idea to embed an
> array in a side data. Not only it constrains the structure to only change
> at major bumps, but it seems very reminiscent of binary side data which
> is/should be not used for newer side data. As a matter of fact side data
> normally hosts either structs or simple types like ints or enums only.
> Instead of this, why not creating a structure hosting the number of
> elements and a pointer? Something like
> 
> AVRegionOfInterest {
>  size_t top/left/right/bottom
> }
> 
> AVRegionOfInterestSet {
>  int rois_nb;
>  AVRegionOfInterest *rois;

This will go south as soon as you start copying, referencing and freeing
frames and/or frame side data.

All side data types need to be a contiguous array of bytes in memory
with no pointers.

> }
> 

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

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[James Almer]

On 12/28/2018 7:09 AM, Guo, Yejun wrote:
> The encoders such as libx264 support different QPs offset for different MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
> 
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding.
> 
> The ROI info is maintained as side data of AVFrame.
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavutil/frame.c   |  1 +
>  libavutil/frame.h   | 23 +++
>  libavutil/version.h |  2 +-
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 34a6210..bebc50e 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum 
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table data";
>  #endif
>  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata 
> SMPTE2094-40 (HDR10+)";
> +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 582ac47..3460b01 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
>   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
>   */
>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> +
> +/**
> + * Regions Of Interest, the data is an array of AVROI type, the array 
> size
> + * is implied by AVFrameSideData::size / sizeof(AVROI).
> + */
> +AV_FRAME_DATA_ROIS,
>  };
>  
>  enum AVActiveFormatDescription {
> @@ -201,6 +207,23 @@ typedef struct AVFrameSideData {
>  } AVFrameSideData;
>  
>  /**
> + * Structure to hold Region Of Interest.
> + *
> + * top/bottom/left/right are coordinates at frame pixel level.
> + * They will be extended internally if the codec requires an alignment.
> + * If the regions overlap, the last value in the list will be used.
> + *
> + * qoffset is quant offset, it is encoder dependent.
> + */
> +typedef struct AVROI {
> +size_t top;
> +size_t bottom;
> +size_t left;
> +size_t right;

uint32_t, please. Make the struct have a fixed size so we don't repeat
the same issues we had with fate tests and AVSphericalMapping.

> +int qoffset;
> +} AVROI;
> +
> +/**
>   * This structure describes decoded (raw) audio or video data.
>   *
>   * AVFrame must be allocated using av_frame_alloc(). Note that this only
> diff --git a/libavutil/version.h b/libavutil/version.h
> index f997615..1fcdea9 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>  
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  25
> +#define LIBAVUTIL_VERSION_MINOR  26
>  #define LIBAVUTIL_VERSION_MICRO 100
>  
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> 

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

Re: [FFmpeg-devel] [PATCH] libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S

[Manoj Gupta]

On Mon, Dec 31, 2018 at 8:31 AM Michael Niedermayer
 wrote:
>
> On Fri, Dec 28, 2018 at 03:12:53PM -0800, Manoj Gupta wrote:
> > Hi All,
> >
> > I recently had a problem building ffmpeg for AArch64 where lld linker
> > complained about text relocations in readonly segment. The following
> > patch fixes the linker complains by referring to a local label instead
> > of function name.
> >
> > This is similar in nature as the following previous commits:
> > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34290.html
> > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34419.html
> >
> > Thanks,
> > Manoj
> >
> > Patch:
> >
> > libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S
> >
> > Some of the assembly functions e.g. ff_h264_idct_dc_add_neon
> > has code like:
> > movrel  x14, X(ff_h264_idct_add_neon)
> >
> > Linker cannot resolve them fully at link time and emits dynamic
> > relocations.
> > Use explicit labels instead so that no dynamic relocations are
> > needed at all.
> >
> > This avoids lld complains about text relocations.
> >
> > For background, see https://crbug.com/917919
> >
> > Signed-off-by: Manoj Gupta 
> > ---
> >  libavcodec/aarch64/h264idct_neon.S | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
>
> Has this been tested on all common aarch64 platforms ?
>
I have tested this on Chromium with clang+lld linker and Debian
aarch64 cross compiler gcc + bfd linker.
Please let me know if more testing is needed.

> Also git doesnt separate the mail from the commit message and would
> put the wholw email as the commit message, i assume that is not
> intended.

Sorry for the confusion about the commit message. Only the text
following "Patch:" is intended to be the commit message, but I had
tried to add  more context before the
patch text. I am fine with sending a v2 patch just containing the commit msg.

Thanks,
Manoj

>
> thx
>
> [...]
> --
> 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
> ___
> 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 2/2] avformat: add HCOM demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/hcom.c   | 89 
 3 files changed, 91 insertions(+)
 create mode 100644 libavformat/hcom.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c42ceb40c5..c010fc83f9 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -219,6 +219,7 @@ OBJS-$(CONFIG_H263_MUXER)+= rawenc.o
 OBJS-$(CONFIG_H264_DEMUXER)  += h264dec.o rawdec.o
 OBJS-$(CONFIG_H264_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HASH_MUXER)+= hashenc.o
+OBJS-$(CONFIG_HCOM_DEMUXER)  += hcom.o
 OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 399625fd78..06844986f3 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -176,6 +176,7 @@ extern AVOutputFormat ff_h263_muxer;
 extern AVInputFormat  ff_h264_demuxer;
 extern AVOutputFormat ff_h264_muxer;
 extern AVOutputFormat ff_hash_muxer;
+extern AVInputFormat  ff_hcom_demuxer;
 extern AVOutputFormat ff_hds_muxer;
 extern AVInputFormat  ff_hevc_demuxer;
 extern AVOutputFormat ff_hevc_muxer;
diff --git a/libavformat/hcom.c b/libavformat/hcom.c
new file mode 100644
index 00..933ecce373
--- /dev/null
+++ b/libavformat/hcom.c
@@ -0,0 +1,89 @@
+/*
+ * HCOM demuxer
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/internal.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+
+static int hcom_probe(AVProbeData *p)
+{
+if (!memcmp(p->buf+65, "FSSD", 4) &&
+!memcmp(p->buf+128, "HCOM", 4))
+return AVPROBE_SCORE_MAX;
+return 0;
+}
+
+static int hcom_read_header(AVFormatContext *s)
+{
+AVStream *st;
+unsigned data_size, rsrc_size, huffcount;
+unsigned compresstype, divisor;
+unsigned dict_entries;
+int ret;
+
+avio_skip(s->pb, 83);
+data_size = avio_rb32(s->pb);
+rsrc_size = avio_rb32(s->pb);
+avio_skip(s->pb, 128-91+4);
+huffcount = avio_rb32(s->pb);
+avio_skip(s->pb, 4);
+compresstype = avio_rb32(s->pb);
+if (compresstype > 1)
+return AVERROR_INVALIDDATA;
+divisor = avio_rb32(s->pb);
+if (divisor == 0 || divisor > 4)
+return AVERROR_INVALIDDATA;
+dict_entries = avio_rb16(s->pb);
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codecpar->channels= 1;
+st->codecpar->sample_rate = 22050 / divisor;
+st->codecpar->codec_id= AV_CODEC_ID_HCOM;
+st->codecpar->bits_per_coded_sample = 8;
+st->codecpar->block_align = 4;
+
+ret = ff_alloc_extradata(st->codecpar, dict_entries * 4 + 7);
+if (ret < 0)
+return ret;
+AV_WB16(st->codecpar->extradata, dict_entries);
+AV_WB32(st->codecpar->extradata + 2, compresstype);
+avio_read(s->pb, st->codecpar->extradata + 6, dict_entries * 4);
+avio_skip(s->pb, 1);
+st->codecpar->extradata[dict_entries * 4 + 6] = avio_r8(s->pb);
+
+avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
+
+return 0;
+}
+
+AVInputFormat ff_hcom_demuxer = {
+.name   = "hcom",
+.long_name  = NULL_IF_CONFIG_SMALL("Macintosh HCOM"),
+.read_probe = hcom_probe,
+.read_header= hcom_read_header,
+.read_packet= ff_pcm_read_packet,
+};
-- 
2.17.1

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

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

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 ++
 libavcodec/hcom.c   | 137 
 5 files changed, 147 insertions(+)
 create mode 100644 libavcodec/hcom.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 99799ceed2..bf746c143d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -362,6 +362,7 @@ OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
 OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
 OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
 OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
+OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
 OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
   hevc_cabac.o hevc_refs.o hevcpred.o  
  \
   hevcdsp.o hevc_filter.o hevc_data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4755af71b2..fe0376e27e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -424,6 +424,7 @@ extern AVCodec ff_g723_1_decoder;
 extern AVCodec ff_g729_decoder;
 extern AVCodec ff_gsm_decoder;
 extern AVCodec ff_gsm_ms_decoder;
+extern AVCodec ff_hcom_decoder;
 extern AVCodec ff_iac_decoder;
 extern AVCodec ff_ilbc_decoder;
 extern AVCodec ff_imc_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 92567ec6d0..e92d7accf4 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -646,6 +646,7 @@ enum AVCodecID {
 AV_CODEC_ID_APTX_HD,
 AV_CODEC_ID_SBC,
 AV_CODEC_ID_ATRAC9,
+AV_CODEC_ID_HCOM,
 
 /* subtitle codecs */
 AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing at 
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 2363a53283..10a639101c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2943,6 +2943,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform Acoustic 
Coding 9)"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_HCOM,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "hcom",
+.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* subtitle codecs */
 {
diff --git a/libavcodec/hcom.c b/libavcodec/hcom.c
new file mode 100644
index 00..e516d20a94
--- /dev/null
+++ b/libavcodec/hcom.c
@@ -0,0 +1,137 @@
+/*
+ * HCOM audio decoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct HEntry {
+int16_t l, r;
+} HEntry;
+
+typedef struct HCOMContext {
+AVCodecContext *avctx;
+
+uint8_t first_sample;
+uint8_t sample;
+int dict_entries;
+int dict_entry;
+int delta_compression;
+
+HEntry *dict;
+} HCOMContext;
+
+static av_cold int hcom_init(AVCodecContext *avctx)
+{
+HCOMContext *s = avctx->priv_data;
+
+if (avctx->channels != 1) {
+av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
+return AVERROR_INVALIDDATA;
+}
+
+if (avctx->extradata_size <= 7)
+return AVERROR_INVALIDDATA;
+s->dict_entries = AV_RB16(avctx->extradata);
+if (avctx->extradata_size < s->dict_entries * 4 + 7)
+return AVERROR_INVALIDDATA;
+s->delta_compression = AV_RB32(avctx->extradata + 2);
+s->sample = s->first_sample = avctx->extradata[avctx->extradata_size - 1];
+
+s->dict = av_calloc(s->dict_entries, sizeof(*s->dict));
+if (!s->dict)
+return AVERROR(ENOMEM);
+for (int i = 0; i < s->dict_entries; i++) {
+s->dict[i].l = AV_RB16(avctx->extradata + 6 + 4 * i);
+s->dict[i].r = AV_RB16(avctx->extradata + 6 + 4 * i + 2);
+}
+
+avctx->sample_fmt = AV_SAMPLE_FMT_U8;
+s->dict_entry = 0;
+
+return 0;
+}
+
+static int hcom_decode(AVCodecContext *avctx, void *data,
+   int *got_frame, AVPacket *pkt)
+{
+HCOMContext *s = avctx->priv_data;

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

[James Almer]

On 1/2/2019 3:53 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/hcom.c   | 137 
>  5 files changed, 147 insertions(+)
>  create mode 100644 libavcodec/hcom.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 99799ceed2..bf746c143d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -362,6 +362,7 @@ OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
>  OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
>  OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
>  OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
> +OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
>  OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
>hevc_cabac.o hevc_refs.o 
> hevcpred.o\
>hevcdsp.o hevc_filter.o hevc_data.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4755af71b2..fe0376e27e 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -424,6 +424,7 @@ extern AVCodec ff_g723_1_decoder;
>  extern AVCodec ff_g729_decoder;
>  extern AVCodec ff_gsm_decoder;
>  extern AVCodec ff_gsm_ms_decoder;
> +extern AVCodec ff_hcom_decoder;
>  extern AVCodec ff_iac_decoder;
>  extern AVCodec ff_ilbc_decoder;
>  extern AVCodec ff_imc_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 92567ec6d0..e92d7accf4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -646,6 +646,7 @@ enum AVCodecID {
>  AV_CODEC_ID_APTX_HD,
>  AV_CODEC_ID_SBC,
>  AV_CODEC_ID_ATRAC9,
> +AV_CODEC_ID_HCOM,
>  
>  /* subtitle codecs */
>  AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing 
> at the start of subtitle codecs.
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 2363a53283..10a639101c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2943,6 +2943,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform 
> Acoustic Coding 9)"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_HCOM,
> +.type  = AVMEDIA_TYPE_AUDIO,
> +.name  = "hcom",
> +.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
> +.props = AV_CODEC_PROP_LOSSY,
> +},
>  
>  /* subtitle codecs */
>  {
> diff --git a/libavcodec/hcom.c b/libavcodec/hcom.c
> new file mode 100644
> index 00..e516d20a94
> --- /dev/null
> +++ b/libavcodec/hcom.c
> @@ -0,0 +1,137 @@
> +/*
> + * HCOM audio decoder
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct HEntry {
> +int16_t l, r;
> +} HEntry;
> +
> +typedef struct HCOMContext {
> +AVCodecContext *avctx;
> +
> +uint8_t first_sample;
> +uint8_t sample;
> +int dict_entries;
> +int dict_entry;
> +int delta_compression;
> +
> +HEntry *dict;
> +} HCOMContext;
> +
> +static av_cold int hcom_init(AVCodecContext *avctx)
> +{
> +HCOMContext *s = avctx->priv_data;
> +
> +if (avctx->channels != 1) {
> +av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (avctx->extradata_size <= 7)
> +return AVERROR_INVALIDDATA;
> +s->dict_entries = AV_RB16(avctx->extradata);
> +if (avctx->extradata_size < s->dict_entries * 4 + 7)
> +return AVERROR_INVALIDDATA;
> +s->delta_compression = AV_RB32(avctx->extradata + 2);
> +s->sample = s->first_sample = avctx->extradata[avctx->extradata_size - 
> 1];
> +
> +s->dict = av_calloc(s->dict_entries, sizeof(*s->dict));

You're never freeing this.

> +if (!s->dict)
> +return AVERROR(ENOMEM);
> +for (int i = 0; i < s->dict_entries; i++) {
> +s->dict[i].l = AV_RB16(avc

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Michael Niedermayer]

On Sat, Dec 29, 2018 at 04:09:21PM -0500, Shaofei Wang wrote:
> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obvious
> improvement in some 1:N scenarios by CPU and GPU acceleration
> 
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)

breaks build on mingw64

CC  fftools/ffmpeg_filter.o
src/fftools/ffmpeg_filter.c: In function ‘init_simple_filtergraph’:
src/fftools/ffmpeg_filter.c:231:39: error: incompatible types when assigning to 
type ‘pthread_t’ from type ‘int’
 ist->filters[i]->f_thread = 0;
   ^
make: *** [fftools/ffmpeg_filter.o] Error 1
CC  fftools/ffmpeg.o
src/fftools/ffmpeg.c: In function ‘pipeline_reap_filters’:
src/fftools/ffmpeg.c:1534:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
 OutputStream *ost = output_streams[i];
 ^
src/fftools/ffmpeg.c: In function ‘do_streamcopy’:
src/fftools/ffmpeg.c:2179:5: warning: ‘av_copy_packet_side_data’ is deprecated 
(declared at src/libavcodec/avcodec.h:4424) [-Wdeprecated-declarations]
 av_copy_packet_side_data(&opkt, pkt);
 ^
src/fftools/ffmpeg.c: In function ‘filter_pipeline’:
src/fftools/ffmpeg.c:2412:5: warning: ‘return’ with no value, in function 
returning non-void [enabled by default]
 return;
 ^
src/fftools/ffmpeg.c: In function ‘send_frame_to_filters’:
src/fftools/ffmpeg.c:2451:42: error: invalid operands to binary == (have 
‘pthread_t’ and ‘int’)
 if(ist->filters[i]->f_thread == 0) {
  ^
src/fftools/ffmpeg.c: In function ‘init_output_stream’:
src/fftools/ffmpeg.c:3754:9: warning: ‘avcodec_copy_context’ is deprecated 
(declared at src/libavcodec/avcodec.h:4196) [-Wdeprecated-declarations]
 ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
 ^
src/fftools/ffmpeg.c:3754:9: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
src/fftools/ffmpeg.c:3800:9: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
 ost->st->codec->codec= ost->enc_ctx->codec;
 ^
src/fftools/ffmpeg.c: In function ‘check_keyboard_interaction’:
src/fftools/ffmpeg.c:4181:13: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
 debug = input_streams[0]->st->codec->debug<<1;
 ^
src/fftools/ffmpeg.c:4204:13: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
 input_streams[i]->st->codec->debug = debug;
 ^
make: *** [fftools/ffmpeg.o] Error 1
make: Target `all' not remade because of errors.



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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 01/11] doc/indevs: fix upto typo

[Lou Logan]

On Mon, Dec 31, 2018, at 12:03 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/indevs.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Ok.  Same typo is in compat/avisynth/avisynth_c.h.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[Vittorio Giovara]

On Wed, Jan 2, 2019 at 6:45 PM James Almer  wrote:

> On 1/2/2019 2:18 PM, Vittorio Giovara wrote:
> > On Wed, Jan 2, 2019 at 4:13 PM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:
> >>
> >
> > AVRegionOfInterest {
> >  size_t top/left/right/bottom
> > }
> >
> > AVRegionOfInterestSet {
> >  int rois_nb;
> >  AVRegionOfInterest *rois;
>
> This will go south as soon as you start copying, referencing and freeing
> frames and/or frame side data.
>
> All side data types need to be a contiguous array of bytes in memory
> with no pointers.
>

Hmm you're right, but embedding an entire array is pretty bad too,
especially because it locks the struct size...
Do you have any alternative ideas for this?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

On 1/2/19, James Almer  wrote:
> On 1/2/2019 3:53 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/Makefile |   1 +
>>  libavcodec/allcodecs.c  |   1 +
>>  libavcodec/avcodec.h|   1 +
>>  libavcodec/codec_desc.c |   7 ++
>>  libavcodec/hcom.c   | 137 
>>  5 files changed, 147 insertions(+)
>>  create mode 100644 libavcodec/hcom.c
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 99799ceed2..bf746c143d 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -362,6 +362,7 @@ OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+=
>> v4l2_m2m_dec.o
>>  OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
>>  OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
>>  OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
>> +OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
>>  OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
>>hevc_cabac.o hevc_refs.o
>> hevcpred.o\
>>hevcdsp.o hevc_filter.o
>> hevc_data.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index 4755af71b2..fe0376e27e 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -424,6 +424,7 @@ extern AVCodec ff_g723_1_decoder;
>>  extern AVCodec ff_g729_decoder;
>>  extern AVCodec ff_gsm_decoder;
>>  extern AVCodec ff_gsm_ms_decoder;
>> +extern AVCodec ff_hcom_decoder;
>>  extern AVCodec ff_iac_decoder;
>>  extern AVCodec ff_ilbc_decoder;
>>  extern AVCodec ff_imc_decoder;
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 92567ec6d0..e92d7accf4 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -646,6 +646,7 @@ enum AVCodecID {
>>  AV_CODEC_ID_APTX_HD,
>>  AV_CODEC_ID_SBC,
>>  AV_CODEC_ID_ATRAC9,
>> +AV_CODEC_ID_HCOM,
>>
>>  /* subtitle codecs */
>>  AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID
>> pointing at the start of subtitle codecs.
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 2363a53283..10a639101c 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -2943,6 +2943,13 @@ static const AVCodecDescriptor codec_descriptors[]
>> = {
>>  .long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform
>> Acoustic Coding 9)"),
>>  .props = AV_CODEC_PROP_LOSSY,
>>  },
>> +{
>> +.id= AV_CODEC_ID_HCOM,
>> +.type  = AVMEDIA_TYPE_AUDIO,
>> +.name  = "hcom",
>> +.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
>> +.props = AV_CODEC_PROP_LOSSY,
>> +},
>>
>>  /* subtitle codecs */
>>  {
>> diff --git a/libavcodec/hcom.c b/libavcodec/hcom.c
>> new file mode 100644
>> index 00..e516d20a94
>> --- /dev/null
>> +++ b/libavcodec/hcom.c
>> @@ -0,0 +1,137 @@
>> +/*
>> + * HCOM audio decoder
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> + */
>> +
>> +#include "libavutil/intreadwrite.h"
>> +
>> +#include "avcodec.h"
>> +#include "bytestream.h"
>> +#include "internal.h"
>> +
>> +typedef struct HEntry {
>> +int16_t l, r;
>> +} HEntry;
>> +
>> +typedef struct HCOMContext {
>> +AVCodecContext *avctx;
>> +
>> +uint8_t first_sample;
>> +uint8_t sample;
>> +int dict_entries;
>> +int dict_entry;
>> +int delta_compression;
>> +
>> +HEntry *dict;
>> +} HCOMContext;
>> +
>> +static av_cold int hcom_init(AVCodecContext *avctx)
>> +{
>> +HCOMContext *s = avctx->priv_data;
>> +
>> +if (avctx->channels != 1) {
>> +av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> +if (avctx->extradata_size <= 7)
>> +return AVERROR_INVALIDDATA;
>> +s->dict_entries = AV_RB16(avctx->extradata);
>> +if (avctx->extradata_size < s->dict_entries * 4 + 7)
>> +return AVERROR_INVALIDDATA;
>> +s->delta_compression = AV_RB32(avctx->extradata + 2);
>> +s->sample = s->first_sample = avctx->extradata[avctx->extradata_size
>> - 1];
>> +
>> +s->dict = av_calloc(s->dict_entries, sizeof(*s->dict));
>
> Yo

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[Vittorio Giovara]

On Wed, Jan 2, 2019 at 6:48 PM James Almer  wrote:

> On 12/28/2018 7:09 AM, Guo, Yejun wrote:
> > The encoders such as libx264 support different QPs offset for different
> MBs,
> > it makes possible for ROI-based encoding. It makes sense to add support
> > within ffmpeg to generate/accept ROI infos and pass into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> > generates ROI info for that frame, and the encoder finally does the
> > ROI-based encoding.
> >
> > The ROI info is maintained as side data of AVFrame.
> >
> > Signed-off-by: Guo, Yejun 
> > ---
> >  libavutil/frame.c   |  1 +
> >  libavutil/frame.h   | 23 +++
> >  libavutil/version.h |  2 +-
> >  3 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 34a6210..bebc50e 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> >  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> data";
> >  #endif
> >  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> SMPTE2094-40 (HDR10+)";
> > +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
> >  }
> >  return NULL;
> >  }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 582ac47..3460b01 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
> >   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
> >   */
> >  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> > +
> > +/**
> > + * Regions Of Interest, the data is an array of AVROI type, the
> array size
> > + * is implied by AVFrameSideData::size / sizeof(AVROI).
> > + */
> > +AV_FRAME_DATA_ROIS,
> >  };
> >
> >  enum AVActiveFormatDescription {
> > @@ -201,6 +207,23 @@ typedef struct AVFrameSideData {
> >  } AVFrameSideData;
> >
> >  /**
> > + * Structure to hold Region Of Interest.
> > + *
> > + * top/bottom/left/right are coordinates at frame pixel level.
> > + * They will be extended internally if the codec requires an alignment.
> > + * If the regions overlap, the last value in the list will be used.
> > + *
> > + * qoffset is quant offset, it is encoder dependent.
> > + */
> > +typedef struct AVROI {
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
>
> uint32_t, please. Make the struct have a fixed size so we don't repeat
> the same issues we had with fate tests and AVSphericalMapping.
>

I thought we dropped the side data size from fate tests in
21a8e751ad6abb2d423afa3041da92f8f7741997.
If so, size_t seems the better choice here.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 1/2/2019 3:53 PM, Paul B Mahol wrote:
> +static int hcom_decode(AVCodecContext *avctx, void *data,
> +   int *got_frame, AVPacket *pkt)
> +{
> +HCOMContext *s = avctx->priv_data;
> +AVFrame *frame = data;
> +GetByteContext gb;
> +uint32_t current;
> +int ret, n = 0;
> +
> +if (pkt->size > INT16_MAX)
> +return AVERROR_INVALIDDATA;
> +
> +frame->nb_samples = pkt->size * 8;
> +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> +return ret;
> +
> +bytestream2_init(&gb, pkt->data, pkt->size);
> +while (bytestream2_get_bytes_left(&gb) >= 4) {
> +int bits = 32;
> +
> +current = bytestream2_get_be32(&gb);
> +
> +while (bits-- > 0) {
> +
> +if (current & 0x8000) {
> +s->dict_entry = s->dict[s->dict_entry].r;
> +} else {
> +s->dict_entry = s->dict[s->dict_entry].l;
> +}
> +
> +current = current << 1;

This sounds like get_bits is a better fit than bytestream2 for this decoder.

> +if (s->dict[s->dict_entry].l < 0) {
> +int16_t datum;
> +
> +datum = s->dict[s->dict_entry].r;
> +
> +if (!s->delta_compression)
> +s->sample = 0;
> +s->sample = (s->sample + datum) & 0xFF;
> +
> +frame->data[0][n++] = s->sample;
> +
> +s->dict_entry = 0;
> +}
> +}
> +}
> +
> +frame->nb_samples = n;
> +
> +*got_frame = 1;
> +
> +return pkt->size;
> +}

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

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Uwe Freese]

Hi,

just an info: code didn't compile, don't know why I didn't see this... 
New patch is in work...


Regards, Uwe

Am 01.01.19 um 22:14 schrieb Uwe Freese:

Hello,

here's a new version of the patch.

Thanks for the infos. I used the raw output of a small test video 
(where delogo is applied in both modes) before and after the changes 
to make sure the output is bytewise identical (the changes don't 
change the output).



In general I want to say that it seems to me that *some* of the points 
go now in a more philosophical direction.


I prefer code easy to understand and assume that compilers optimize 
much. Yes, there may be many possibilities to probably "optimize" 
something, but I tend to believe that many times this is not needed 
nor helpful, because it doesn't really optimize and complicates the code.


Additionally, when I don't have complete and functioning code to 
replace my code (the same what's expected from me), I'm not willing to 
spend many hours to guess what could be meant.


I hope that not so many additional patches are needed anymore. I 
understand that coding styles, syntax etc. shall be corrected, but 
hope that we don't have to discuss too much alternative ways of 
implementing basically the same.




Changes since the last version of the patch (mail from 29.12. 21:38), 
according the comments since then:


- change include order at the beginning of the file
- change loop format (linebreaks)
- change loop borders
- change indentation (line 175)
- moved init code (create tables) to config_input function

- used av_malloc_array instead of av_malloc. Avoid the cast. Use 
variable in sizeof(...).

- copyright 2018, 2019 - happy new year BTW ;-)


Comments and remaining open points from the mails:


+    for (y = logo_y1 + 1; y < logo_y2; y++) {
+    for (x = logo_x1 + 1,
+    xdst = dst + logo_x1 + 1,
+    xsrc = src + logo_x1 + 1; x < logo_x2; x++, xdst++, 
xsrc++) {

I think a line break after the semicolons would make this easier to
understand.


Hm. I used the same format as in the original code.

Nonetheless, I changed the format now, because I changed the loop 
borders as requested and the loops are now different anyway.



+    for (bx = 0; bx < logo_w; bx++) {
+    interpd += topleft[bx] *
+    uglarmtable[abs(bx - (x - logo_x1)) + (y - 
logo_y1) * (logo_w - 1)];

+    interpd += botleft[bx] *
+    uglarmtable[abs(bx - (x - logo_x1)) + 
(logo_h - (y - logo_y1) - 1) * (logo_w - 1)];

+    }

This can be optimized, and since it is the inner loop of the filter, I
think it is worth it. You can declare a pointer that will stay the same
for the whole y loop:

double *xweight = uglarmtable + (y - logo_y1) * (logo_w - 1);

and then use it in that loop:

interpd += ... * xweight[abs(bx - (x - logo_x1))];

It avoids a lot of multiplications.


I'm not sure about this point. First, I would absolutely assume from 
the compiler that it optimizes expressions like "(logo_w - 1)" or a 
fixed offset to access the array in the loop and that they are only 
calculated once.


Secondly, I don't exactly understand how *xweight in your example 
should be used (and would mean smaller or easier code).


@All: What is the opinion about changing this loop regarding use of an 
additional xweight pointer?





+
+    for (by = 1; by < logo_h - 1; by++) {
+    interpd += topleft[by * src_linesize] *
+    uglarmtable[(x - logo_x1) + abs(by - (y - 
logo_y1)) * (logo_w - 1)];
+    interpd += topleft[by * src_linesize + (logo_w 
- 1)] *
+    uglarmtable[logo_w - (x - logo_x1) - 1 + 
abs(by - (y - logo_y1)) * (logo_w - 1)];

+    }

This one is more tricky to optimize, because of the abs() within the
multiplication, but it can be done by splitting the loop in two:

for (by = 1; by < y; by++) {
    interpd += ... * yweight[x - logo_x1];
    yweight -= logo_w_minus_one;
}
for (; by < logo_h_minus_one; by++) {
    interpd += ... * yweight[x - logo_x1];
    yweight += logo_w_minus_one;
}
av_assert2(yweight == the_correct_value);

In fact, I think even the x loop would be a little more readable if it
was split in two like that.
Sorry, I don't understand. Please give me a complete example that 
replaces the previous for loop.

+
+    interp = (uint64_t)(interpd /
+    uglarmweightsum[(x - logo_x1) - 1 + (y - 
logo_y1 - 1) * (logo_w - 2)]);

The cast to uint64_t seems suspicious. Can you explain?


Every pixel value of the inner logo area is an integer. Only for the 
calculation of the weighted average, all values use floats. At the 
end, it is rounded (truncated) to an int.


Should work - and did work for 17 years...




+    *xdst = interp;
+    }
+
+    dst += dst_linesize;
+    sr

Re: [FFmpeg-devel] [PATCH 01/11] doc/indevs: fix upto typo

[Michael Niedermayer]

On Wed, Jan 02, 2019 at 10:34:21AM -0900, Lou Logan wrote:
> On Mon, Dec 31, 2018, at 12:03 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/indevs.texi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Ok.  Same typo is in compat/avisynth/avisynth_c.h.

yes, you should probably report this to avisynth or whereever this is 
maintained if the
typo is still in the upstream version, otherwise our copy should maybe be 
updated

Thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: skip disabled streams

[Michael Niedermayer]

On Mon, Dec 31, 2018 at 10:33:37AM +0530, Gyan wrote:
> 
> On 31-12-2018 06:50 AM, Michael Niedermayer wrote:
> >On Sat, Dec 29, 2018 at 04:39:18PM +0530, Gyan wrote:
> >>At Michael's suggestion, earlier patch broken into two. This one stops
> >>discarded streams from being processed. A few more checks added.
> >>
> >>Gyan
> >>
> >[...]
> >>diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> >>index d4851a2cd8..4ee7dbbe01 100644
> >>--- a/fftools/ffmpeg_opt.c
> >>+++ b/fftools/ffmpeg_opt.c
> >>@@ -268,7 +268,7 @@ static int opt_map(void *optctx, const char *opt, const 
> >>char *arg)
> >>  {
> >>  OptionsContext *o = optctx;
> >>  StreamMap *m = NULL;
> >>-int i, negative = 0, file_idx;
> >>+int i, negative = 0, file_idx, disabled;
> >>  int sync_file_idx = -1, sync_stream_idx = 0;
> >>  char *p, *sync;
> >>  char *map;
> >>@@ -303,6 +303,11 @@ static int opt_map(void *optctx, const char *opt, 
> >>const char *arg)
> >> "match any streams.\n", arg);
> >>  exit_program(1);
> >>  }
> >>+if (input_streams[input_files[sync_file_idx]->ist_index + 
> >>sync_stream_idx]->user_set_discard == AVDISCARD_ALL) {
> >>+av_log(NULL, AV_LOG_FATAL, "Sync stream specification in map 
> >>%s matches a disabled input "
> >>+   "stream.\n", arg);
> >>+exit_program(1);
> >>+}
> >>  }
> >>@@ -339,6 +344,10 @@ static int opt_map(void *optctx, const char *opt, 
> >>const char *arg)
> >>  if (check_stream_specifier(input_files[file_idx]->ctx, 
> >> input_files[file_idx]->ctx->streams[i],
> >>  *p == ':' ? p + 1 : p) <= 0)
> >>  continue;
> >>+if (input_streams[input_files[file_idx]->ist_index + 
> >>i]->user_set_discard == AVDISCARD_ALL) {
> >>+disabled = 1;
> >>+continue;
> >>+}
> >>  GROW_ARRAY(o->stream_maps, o->nb_stream_maps);
> >>  m = &o->stream_maps[o->nb_stream_maps - 1];
> >>@@ -358,6 +367,10 @@ static int opt_map(void *optctx, const char *opt, 
> >>const char *arg)
> >>  if (!m) {
> >>  if (allow_unused) {
> >>  av_log(NULL, AV_LOG_VERBOSE, "Stream map '%s' matches no 
> >> streams; ignoring.\n", arg);
> >>+} else if (disabled) {
> >disabled is set to 1 and otherwise is uninitialized, this doesnt look 
> >intended
> 
> Revised.
> 

>  ffmpeg_filter.c |7 +++
>  ffmpeg_opt.c|   31 +--
>  2 files changed, 36 insertions(+), 2 deletions(-)
> 433387cfb362b3c52c8af2c0872ce10121a62622  
> v2-0001-ffmpeg-skip-disabled-streams.patch
> From b6a32a981d8bd0d77b7607a2ca61989e5bbc79cc Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sat, 29 Dec 2018 16:17:05 +0530
> Subject: [PATCH v2 1/2] ffmpeg: skip disabled streams
> 
> Fully discarded streams can't be selected for output or mapped or filtered.
> Previously, a few packets from such streams, probably buffered for
> stream probing, would get smuggled into output files.

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Derek Buitenhuis]

On 24/12/2018 16:42, Derek Buitenhuis wrote:
> Ping. Is there a decision on eitehr what to do or to ignore this?
> 
> I'll update my downstream code with an FLV edge case if need be.

Ping.

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

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[Michael Niedermayer]

On Wed, Jan 02, 2019 at 09:50:24PM +0100, Vittorio Giovara wrote:
> On Wed, Jan 2, 2019 at 6:45 PM James Almer  wrote:
> 
> > On 1/2/2019 2:18 PM, Vittorio Giovara wrote:
> > > On Wed, Jan 2, 2019 at 4:13 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:
> > >>
> > >
> > > AVRegionOfInterest {
> > >  size_t top/left/right/bottom
> > > }
> > >
> > > AVRegionOfInterestSet {
> > >  int rois_nb;
> > >  AVRegionOfInterest *rois;
> >
> > This will go south as soon as you start copying, referencing and freeing
> > frames and/or frame side data.
> >
> > All side data types need to be a contiguous array of bytes in memory
> > with no pointers.
> >
> 
> Hmm you're right, but embedding an entire array is pretty bad too,
> especially because it locks the struct size...
> Do you have any alternative ideas for this?

the array element size could be added in addition to the number of
entries. that way elements can be added after the array and also
the individual elements can be extended

int rois_nb;
int roi_size;
AVRegionOfInterest rois[rois_nb];

Alternativly some "int version" could be used but we dont use that style
elsewhere


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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S

[Michael Niedermayer]

On Wed, Jan 02, 2019 at 10:12:33AM -0800, Manoj Gupta wrote:
> On Mon, Dec 31, 2018 at 8:31 AM Michael Niedermayer
>  wrote:
> >
> > On Fri, Dec 28, 2018 at 03:12:53PM -0800, Manoj Gupta wrote:
> > > Hi All,
> > >
> > > I recently had a problem building ffmpeg for AArch64 where lld linker
> > > complained about text relocations in readonly segment. The following
> > > patch fixes the linker complains by referring to a local label instead
> > > of function name.
> > >
> > > This is similar in nature as the following previous commits:
> > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34290.html
> > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34419.html
> > >
> > > Thanks,
> > > Manoj
> > >
> > > Patch:
> > >
> > > libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S
> > >
> > > Some of the assembly functions e.g. ff_h264_idct_dc_add_neon
> > > has code like:
> > > movrel  x14, X(ff_h264_idct_add_neon)
> > >
> > > Linker cannot resolve them fully at link time and emits dynamic
> > > relocations.
> > > Use explicit labels instead so that no dynamic relocations are
> > > needed at all.
> > >
> > > This avoids lld complains about text relocations.
> > >
> > > For background, see https://crbug.com/917919
> > >
> > > Signed-off-by: Manoj Gupta 
> > > ---
> > >  libavcodec/aarch64/h264idct_neon.S | 20 
> > >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > Has this been tested on all common aarch64 platforms ?
> >
> I have tested this on Chromium with clang+lld linker and Debian
> aarch64 cross compiler gcc + bfd linker.
> Please let me know if more testing is needed.

it would be good to test on apple too

thx

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Uwe Freese]

Hello,

Here's a new version of the patch. Changes:


- My last version didn't compile because of moving code to config_input. 
Don't know why I didn't see this, sorry.
  I moved the code back to filter_frame because of two reasons. First, 
I need the "sar" to init my tables and it seems I need the "AVFrame *in" 
parameter for that. Secondly, I also need *desc, hsub0, vsub0, plane, 
logo_w, logo_h which means much duplicated code or creation of functions.


- Corrected use of sizeof in av_malloc_array

- changed calculation of the distance regarding exponent, avoid sqrt, 
use "aspect2" variable


- use double *uglarmtable[MAX_SUB + 1][MAX_SUB + 1], 
*uglarmweightsum[MAX_SUB + 1][MAX_SUB + 1]; (instead per 1-dimensional 
array for the planes)


- unconditional av_freep in uninit

- used the alternative loops as suggested by Nicolas (thanks)


Remaining points / answers / questions:

Am 02.01.19 um 16:25 schrieb Nicolas George:

+interp = (uint64_t)(interpd /
+uglarmweightsum[(x - logo_x1) - 1 + (y - logo_y1 - 1) * 
(logo_w - 2)]);

The cast to uint64_t seems suspicious. Can you explain?

Every pixel value of the inner logo area is an integer. Only for the
calculation of the weighted average, all values use floats. At the end, it
is rounded (truncated) to an int.

int and uint64_t are not the same thing. Why uint64_t?


"interp" was defined as uint64_t in the original code.

Do you see a problem here? Then let us know.


pow(x * x * aspect2 + y * y, exponent / 2);

Hm. Again, I'm unsure if this "optimization" is worth it. I wouldn't do this
normally.

In this particular instance, definitely yes. Compilers have very little
latitude to optimize floating point operations, and they will certainly
not optimize mathematical functions based on subtle arithmetic
properties. This is a C compiler, not a TI-89.


We have obviously distinct opinions here. I would leave the code because 
it's easier to understand (as written), and it runs once, taking maybe 
some microseconds more for a usual conversion of video taking seconds to 
hours.


But I have no problem changing it. - Done.


Question to "aspect2": is ^2 not good (slow) or something, or why not 
directly use


double aspect2 = ((double)sar.num / sar.den) ^ 2;



[...]
 av_assert2(table_t == uglarmtable + (logo_w - x) + table_stride * y);
 av_assert2(table_b == uglarmtable + (logo_w - x) + table_stride * (logo_h 
- y - 1));
 av_assert2(table_l == uglarmtable + table_stride * (logo_h - y - 1) + x);
 av_assert2(table_r == uglarmtable + table_stride * (logo_h - y - 1) + 
logo_w - x - 1;

That makes more lines, but the lines are way simpler: no tricky
arithmetic, all blocks almost identical, with the changes easy to see
and understand.


I took over these alternative loops for the calculations.

Question to the assert: Is this useful (compared to the running time)? I 
mean, basically it is the same expression as over the loops, only x and 
y are different by the amount the loops are counting them up. I wouldn't 
say that it is probable that one makes an error coding the loop counter 
or that it doesn't somehow function.


Is there another thing which this assert checks that I didn't see?

Regards,
Uwe

>From 7b221a27b29c7376672d4ee60092051f6b65c978 Mon Sep 17 00:00:00 2001
From: breaker27 
Date: Wed, 26 Dec 2018 18:16:48 +0100
Subject: [PATCH] avfilter/vf_delogo: add uglarm interpolation mode

---
 doc/filters.texi|  28 +++
 libavfilter/vf_delogo.c | 214 ++--
 2 files changed, 233 insertions(+), 9 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 65ce25bc18..792560ad79 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7952,6 +7952,34 @@ Specify the thickness of the fuzzy edge of the rectangle (added to
 deprecated, setting higher values should no longer be necessary and
 is not recommended.
 
+@item mode
+Specify the interpolation mode used to remove the logo.
+It accepts the following values:
+@table @option
+@item xy
+Only the border pixels in straight x and y direction are considered
+to replace any logo pixel. This mode tends to flicker and to show
+horizontal and vertical lines.
+@item uglarm
+Consider the whole border for every logo pixel to replace. This mode
+uses the distance raised to the power of the given @var{exponent} as
+weight that decides to which amount every border pixel is taken into
+account. This results in a more blurred area, which tends to be less
+distracting. The uglarm mode was first implemented in VirtualDub's
+LogoAway filter and is also known from ffdshow and is the
+abbreviation for "Uwe's Great LogoAway Remove Mode".
+@end table
+The default value is @code{xy}.
+
+@item exponent
+Specify the exponent used to calculate the weight out of the
+distance in @code{uglarm} mode (weight = distance ^ @var{exponent}).
+The value @code{0} results in a logo area which has
+the same average color everywhere.

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

[Rostislav Pehlivanov]

On Wed, 2 Jan 2019 at 19:02, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/hcom.c   | 137 
>  5 files changed, 147 insertions(+)
>  create mode 100644 libavcodec/hcom.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 99799ceed2..bf746c143d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -362,6 +362,7 @@ OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+=
> v4l2_m2m_dec.o
>  OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
>  OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
>  OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
> +OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
>  OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
>hevc_cabac.o hevc_refs.o
> hevcpred.o\
>hevcdsp.o hevc_filter.o
> hevc_data.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4755af71b2..fe0376e27e 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -424,6 +424,7 @@ extern AVCodec ff_g723_1_decoder;
>  extern AVCodec ff_g729_decoder;
>  extern AVCodec ff_gsm_decoder;
>  extern AVCodec ff_gsm_ms_decoder;
> +extern AVCodec ff_hcom_decoder;
>  extern AVCodec ff_iac_decoder;
>  extern AVCodec ff_ilbc_decoder;
>  extern AVCodec ff_imc_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 92567ec6d0..e92d7accf4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -646,6 +646,7 @@ enum AVCodecID {
>  AV_CODEC_ID_APTX_HD,
>  AV_CODEC_ID_SBC,
>  AV_CODEC_ID_ATRAC9,
> +AV_CODEC_ID_HCOM,
>
>  /* subtitle codecs */
>  AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID
> pointing at the start of subtitle codecs.
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 2363a53283..10a639101c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2943,6 +2943,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform
> Acoustic Coding 9)"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_HCOM,
> +.type  = AVMEDIA_TYPE_AUDIO,
> +.name  = "hcom",
> +.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
> +.props = AV_CODEC_PROP_LOSSY,
> +},
>
>  /* subtitle codecs */
>  {
> diff --git a/libavcodec/hcom.c b/libavcodec/hcom.c
> new file mode 100644
> index 00..e516d20a94
> --- /dev/null
> +++ b/libavcodec/hcom.c
> @@ -0,0 +1,137 @@
> +/*
> + * HCOM audio decoder
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct HEntry {
> +int16_t l, r;
> +} HEntry;
> +
> +typedef struct HCOMContext {
> +AVCodecContext *avctx;
> +
> +uint8_t first_sample;
> +uint8_t sample;
> +int dict_entries;
> +int dict_entry;
> +int delta_compression;
> +
> +HEntry *dict;
> +} HCOMContext;
> +
> +static av_cold int hcom_init(AVCodecContext *avctx)
> +{
> +HCOMContext *s = avctx->priv_data;
> +
> +if (avctx->channels != 1) {
> +av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
> +return AVERROR_INVALIDDATA;
> +}
>

You can just set avctx->channels = 1 and the layout to mono, its a decoder.


+
> +if (avctx->extradata_size <= 7)
> +return AVERROR_INVALIDDATA;
> +s->dict_entries = AV_RB16(avctx->extradata);
> +if (avctx->extradata_size < s->dict_entries * 4 + 7)
> +return AVERROR_INVALIDDATA;
> +s->delta_compression = AV_RB32(avctx->extradata + 2);
> +s->sample = s->first_sample = avctx->extradata[avctx->extradata_size
> - 1];
> +
> +s->dict = av_calloc(s->dict_entries, sizeof(*s->dict));
> +if (!s->dict)
> +return AVERROR(ENOMEM);
> +for (int i = 0; i < s->di

[FFmpeg-devel] [PATCH 1/4] x86/af_afir: fix processing the last element

[James Almer]

ff_fcmul_add_sse3() is now identical to the C version.

Signed-off-by: James Almer 
---
 libavfilter/x86/af_afir.asm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
index 849d85e70f..fcc1f426db 100644
--- a/libavfilter/x86/af_afir.asm
+++ b/libavfilter/x86/af_afir.asm
@@ -30,7 +30,6 @@ SECTION .text
 INIT_XMM sse3
 cglobal fcmul_add, 4,4,6, sum, t, c, len
 shl   lend, 3
-add   lend, mmsize*2
 add tq, lenq
 add cq, lenq
 add   sumq, lenq
@@ -57,4 +56,8 @@ ALIGN 16
 movaps[sumq + lenq+mmsize], m3
 add   lenq, mmsize*2
 jl .loop
-REP_RET
+movss xm0, [tq + lenq]
+mulss xm0, [cq + lenq]
+addss xm0, [sumq + lenq]
+movss [sumq + lenq], xm0
+RET
-- 
2.20.1

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

[FFmpeg-devel] [PATCH 2/4] avfilter/af_afir: split off fcmul_add into a DSP context

[James Almer]

Signed-off-by: James Almer 
---
 libavfilter/af_afir.c  | 15 ++-
 libavfilter/af_afir.h  | 12 +---
 libavfilter/x86/af_afir_init.c |  2 +-
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
index c4baf63c02..c755dc1f6f 100644
--- a/libavfilter/af_afir.c
+++ b/libavfilter/af_afir.c
@@ -103,7 +103,7 @@ static int fir_quantum(AVFilterContext *ctx, AVFrame *out, 
int ch, int offset)
 const float *block = (const float *)seg->block->extended_data[ch] 
+ i * seg->block_size;
 const FFTComplex *coeff = (const FFTComplex 
*)seg->coeff->extended_data[ch * !s->one2many] + coffset;
 
-s->fcmul_add(sum, block, (const float *)coeff, seg->part_size);
+s->afirdsp.fcmul_add(sum, block, (const float *)coeff, 
seg->part_size);
 
 if (j == 0)
 j = seg->nb_partitions;
@@ -753,6 +753,14 @@ static int config_video(AVFilterLink *outlink)
 return 0;
 }
 
+void ff_afir_init(AudioFIRDSPContext *dsp)
+{
+dsp->fcmul_add = fcmul_add_c;
+
+if (ARCH_X86)
+ff_afir_init_x86(dsp);
+}
+
 static av_cold int init(AVFilterContext *ctx)
 {
 AudioFIRContext *s = ctx->priv;
@@ -792,14 +800,11 @@ static av_cold int init(AVFilterContext *ctx)
 }
 }
 
-s->fcmul_add = fcmul_add_c;
-
 s->fdsp = avpriv_float_dsp_alloc(0);
 if (!s->fdsp)
 return AVERROR(ENOMEM);
 
-if (ARCH_X86)
-ff_afir_init_x86(s);
+ff_afir_init(&s->afirdsp);
 
 return 0;
 }
diff --git a/libavfilter/af_afir.h b/libavfilter/af_afir.h
index f9bec54b8c..f665c0ef80 100644
--- a/libavfilter/af_afir.h
+++ b/libavfilter/af_afir.h
@@ -53,6 +53,11 @@ typedef struct AudioFIRSegment {
 RDFTContext **rdft, **irdft;
 } AudioFIRSegment;
 
+typedef struct AudioFIRDSPContext {
+void (*fcmul_add)(float *sum, const float *t, const float *c,
+  ptrdiff_t len);
+} AudioFIRDSPContext;
+
 typedef struct AudioFIRContext {
 const AVClass *class;
 
@@ -87,11 +92,12 @@ typedef struct AudioFIRContext {
 int min_part_size;
 int64_t pts;
 
+AudioFIRDSPContext afirdsp;
 AVFloatDSPContext *fdsp;
-void (*fcmul_add)(float *sum, const float *t, const float *c,
-  ptrdiff_t len);
+
 } AudioFIRContext;
 
-void ff_afir_init_x86(AudioFIRContext *s);
+void ff_afir_init(AudioFIRDSPContext *s);
+void ff_afir_init_x86(AudioFIRDSPContext *s);
 
 #endif /* AVFILTER_AFIR_H */
diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
index 6a652b9b83..29e6f976b2 100644
--- a/libavfilter/x86/af_afir_init.c
+++ b/libavfilter/x86/af_afir_init.c
@@ -25,7 +25,7 @@
 void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
ptrdiff_t len);
 
-av_cold void ff_afir_init_x86(AudioFIRContext *s)
+av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
 {
 int cpu_flags = av_get_cpu_flags();
 
-- 
2.20.1

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

[FFmpeg-devel] [PATCH 4/4] x86/af_afir: add ff_fcmul_add_avx()

[James Almer]

fcmul_add_c: 1228.8
fcmul_add_sse3: 334.3
fcmul_add_avx: 186.3

Signed-off-by: James Almer 
---
 libavfilter/x86/af_afir.asm| 8 +++-
 libavfilter/x86/af_afir_init.c | 5 +
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
index fcc1f426db..8054ac5f10 100644
--- a/libavfilter/x86/af_afir.asm
+++ b/libavfilter/x86/af_afir.asm
@@ -27,7 +27,7 @@ SECTION .text
 ; void ff_fcmul_add(float *sum, const float *t, const float *c, int len)
 ;--
 
-INIT_XMM sse3
+%macro FCMUL_ADD 0
 cglobal fcmul_add, 4,4,6, sum, t, c, len
 shl   lend, 3
 add tq, lenq
@@ -61,3 +61,9 @@ ALIGN 16
 addss xm0, [sumq + lenq]
 movss [sumq + lenq], xm0
 RET
+%endmacro
+
+INIT_XMM sse3
+FCMUL_ADD
+INIT_YMM avx
+FCMUL_ADD
diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
index 29e6f976b2..c37212c381 100644
--- a/libavfilter/x86/af_afir_init.c
+++ b/libavfilter/x86/af_afir_init.c
@@ -24,6 +24,8 @@
 
 void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
ptrdiff_t len);
+void ff_fcmul_add_avx(float *sum, const float *t, const float *c,
+  ptrdiff_t len);
 
 av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
 {
@@ -32,4 +34,7 @@ av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
 if (EXTERNAL_SSE3(cpu_flags)) {
 s->fcmul_add = ff_fcmul_add_sse3;
 }
+if (EXTERNAL_AVX_FAST(cpu_flags)) {
+s->fcmul_add = ff_fcmul_add_avx;
+}
 }
-- 
2.20.1

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

[FFmpeg-devel] [PATCH 3/4] checkasm: add an af_afir test

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/Makefile   |  1 +
 tests/checkasm/af_afir.c  | 83 +++
 tests/checkasm/checkasm.c |  3 ++
 tests/checkasm/checkasm.h |  1 +
 tests/fate/checkasm.mak   |  1 +
 5 files changed, 89 insertions(+)
 create mode 100644 tests/checkasm/af_afir.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 9484acbbd7..47b7b06d28 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -31,6 +31,7 @@ AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
 CHECKASMOBJS-$(CONFIG_AVCODEC)  += $(AVCODECOBJS-yes)
 
 # libavfilter tests
+AVFILTEROBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
 AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
 AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
 AVFILTEROBJS-$(CONFIG_HFLIP_FILTER)  += vf_hflip.o
diff --git a/tests/checkasm/af_afir.c b/tests/checkasm/af_afir.c
new file mode 100644
index 00..54e2f68d6c
--- /dev/null
+++ b/tests/checkasm/af_afir.c
@@ -0,0 +1,83 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "config.h"
+
+#include 
+#include 
+
+#include "libavfilter/af_afir.h"
+#include "libavutil/internal.h"
+#include "checkasm.h"
+
+#define LEN 256
+
+#define randomize_buffer(buf) \
+do {  \
+int i;\
+double bmg[2], stddev = 10.0, mean = 0.0; \
+  \
+for (i = 0; i < LEN*2+8; i += 2) {\
+av_bmg_get(&checkasm_lfg, bmg);   \
+buf[i] = bmg[0] * stddev + mean;  \
+buf[i + 1] = bmg[1] * stddev + mean;  \
+} \
+} while(0);
+
+static void test_fcmul_add(const float *src0, const float *src1, const float 
*src2)
+{
+LOCAL_ALIGNED_32(float, cdst, [LEN*2+8]);
+LOCAL_ALIGNED_32(float, odst, [LEN*2+8]);
+int i;
+
+declare_func(void, float *sum, const float *t, const float *c,
+ ptrdiff_t len);
+
+memcpy(cdst, src0, (LEN*2+8) * sizeof(float));
+memcpy(odst, src0, (LEN*2+8) * sizeof(float));
+call_ref(cdst, src1, src2, LEN);
+call_new(odst, src1, src2, LEN);
+for (i = 0; i <= LEN*2; i++) {
+if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
+fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
+i, cdst[i], odst[i], cdst[i] - odst[i]);
+fail();
+break;
+}
+}
+memcpy(odst, src0, (LEN*2+8) * sizeof(float));
+bench_new(odst, src1, src2, LEN);
+}
+
+void checkasm_check_afir(void)
+{
+LOCAL_ALIGNED_32(float, src0, [LEN*2+8]);
+LOCAL_ALIGNED_32(float, src1, [LEN*2+8]);
+LOCAL_ALIGNED_32(float, src2, [LEN*2+8]);
+AudioFIRDSPContext fir = { 0 };
+
+ff_afir_init(&fir);
+
+randomize_buffer(src0);
+randomize_buffer(src1);
+randomize_buffer(src2);
+
+if (check_func(fir.fcmul_add, "fcmul_add"))
+test_fcmul_add(src0, src1, src2);
+report("fcmul_add");
+}
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 721a0912fb..c3f5160132 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -150,6 +150,9 @@ static const struct {
 #endif
 #endif
 #if CONFIG_AVFILTER
+#if CONFIG_AFIR_FILTER
+{ "af_afir", checkasm_check_afir },
+#endif
 #if CONFIG_BLEND_FILTER
 { "vf_blend", checkasm_check_blend },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index c45cfb46f8..9e8e879fd3 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -40,6 +40,7 @@
 #include "libavutil/timer.h"
 
 void checkasm_check_aacpsdsp(void);
+void checkasm_check_afir(void);
 void checkasm_check_alacdsp(void);
 void checkasm_check_audiodsp(void);
 void checkasm_check_blend(void);
diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
index a722b4a917..d59e9d293a 100644
--- a/tests/fate/checkasm.mak
+++ b/tests/fate/checkasm.mak
@@ -1,4 +1,5 @@
 FATE_CHECKASM = fate-checkasm-aacpsdsp  \
+fate-checkasm-af_afir   \
 fate-checkasm-alacdsp   \
  

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Michael Niedermayer]

On Mon, Nov 26, 2018 at 01:51:25PM +, Derek Buitenhuis wrote:
> On 23/11/2018 02:16, Michael Niedermayer wrote:
> > do we have some sample flv files that require this patchset / that have
> > discontinuites.
> 
> I have many. I've mailed you one privately, while I work on getting a public 
> one.
> 
> > another thing i just realize now, why is this discontinuity issues coming up
> > now? flv support is very old. This should be a long standing issue
> 
> Probably not many codebases check the DISCONT flag. I only just added proper
> discontinuity handling to some codebases this year, and that's why *I* 
> noticed.
> Chances are most people use the ffmpeg cli which seems to handle stuff 
> differently,
> and doesn't necessarily care about the flag. In my case, I only try to 'fix'
> discontinuities if they appear to be in a format that allows them, during 
> indexing.
> 
> I could add a workaround specific to FLV, or some threshold stuff, but I'd 
> prefer
> that demuxers which may output discontinuous timestamps say they do.

The file looks like 2 files concatenated, even with FLV main header between 
them. 

the patch below should make this work with sequential demuxing assuming the
2 files dont change streams somehow with the normal demuxer.

not sure this is the best way to do it ...

also trying a random other flv related tool, FLVTool2 1.0.6 does not seem to
demux the 2nd file of the 2 correctly. Which makes me suspect more that the
file is invalid. Not that this would fundamentally change anything

thx

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..c9423da31c 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -72,6 +72,8 @@ typedef struct FLVContext {
 int64_t *keyframe_filepositions;
 int missing_streams;
 AVRational framerate;
+int64_t last_ts;
+int64_t time_offset;
 } FLVContext;
 
 static int probe(AVProbeData *p, int live)
@@ -917,6 +919,17 @@ static int resync(AVFormatContext *s)
 flv->resync_buffer[j ] =
 flv->resync_buffer[j1] = avio_r8(s->pb);
 
+if (i >= 8) {
+uint8_t *d = flv->resync_buffer + j1 - 8;
+if (d[0] == 'F' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] < 5 && d[5] == 0) {
+av_log(s, AV_LOG_WARNING, "Concatenated FLV detected, might 
fail to demux, decode and seek %Ld\n", flv->last_ts);
+flv->time_offset = flv->last_ts + 1;
+}
+}
+
 if (i > 22) {
 unsigned lsize2 = AV_RB32(flv->resync_buffer + j1 - 4);
 if (lsize2 >= 11 && lsize2 + 8LL < FFMIN(i, RESYNC_BUFFER_SIZE)) {
@@ -1238,8 +1251,8 @@ retry_duration:
 ret = av_get_packet(s->pb, pkt, size);
 if (ret < 0)
 return ret;
-pkt->dts  = dts;
-pkt->pts  = pts == AV_NOPTS_VALUE ? dts : pts;
+pkt->dts  = dts + flv->time_offset;
+pkt->pts  = (pts == AV_NOPTS_VALUE ? dts : pts) +flv->time_offset ;
 pkt->stream_index = st->index;
 pkt->pos  = pos;
 if (flv->new_extradata[stream_type]) {
@@ -1282,6 +1295,10 @@ leave:
 }
 }
 }
+
+if (ret >= 0)
+flv->last_ts = pkt->dts;
+
 return ret;
 }
 



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH] libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S

[Manoj Gupta]

On Wed, Jan 2, 2019 at 2:33 PM Michael Niedermayer
 wrote:
>
> On Wed, Jan 02, 2019 at 10:12:33AM -0800, Manoj Gupta wrote:
> > On Mon, Dec 31, 2018 at 8:31 AM Michael Niedermayer
> >  wrote:
> > >
> > > On Fri, Dec 28, 2018 at 03:12:53PM -0800, Manoj Gupta wrote:
> > > > Hi All,
> > > >
> > > > I recently had a problem building ffmpeg for AArch64 where lld linker
> > > > complained about text relocations in readonly segment. The following
> > > > patch fixes the linker complains by referring to a local label instead
> > > > of function name.
> > > >
> > > > This is similar in nature as the following previous commits:
> > > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34290.html
> > > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34419.html
> > > >
> > > > Thanks,
> > > > Manoj
> > > >
> > > > Patch:
> > > >
> > > > libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S
> > > >
> > > > Some of the assembly functions e.g. ff_h264_idct_dc_add_neon
> > > > has code like:
> > > > movrel  x14, X(ff_h264_idct_add_neon)
> > > >
> > > > Linker cannot resolve them fully at link time and emits dynamic
> > > > relocations.
> > > > Use explicit labels instead so that no dynamic relocations are
> > > > needed at all.
> > > >
> > > > This avoids lld complains about text relocations.
> > > >
> > > > For background, see https://crbug.com/917919
> > > >
> > > > Signed-off-by: Manoj Gupta 
> > > > ---
> > > >  libavcodec/aarch64/h264idct_neon.S | 20 
> > > >  1 file changed, 12 insertions(+), 8 deletions(-)
> > >
> > > Has this been tested on all common aarch64 platforms ?
> > >
> > I have tested this on Chromium with clang+lld linker and Debian
> > aarch64 cross compiler gcc + bfd linker.
> > Please let me know if more testing is needed.
>
> it would be good to test on apple too
>

Thanks, tested on my macbook compiling to aarch64 and the build itself was fine.

Use the following configure (+ make) command, hopefully I did it the right way.

 ./configure --cc=$HOME/ffmpeg/my-clang --cxx=$HOME/ffmpeg/my-clang++
--prefix=$HOME/ffmpeg/ffmpeg_out --enable-cross-compile --arch=aarch64
--target-os=darwin
--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk
--sysinclude=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk

my-clang and my-clang++ are wrapper scripts passing the iphone SDK
headers to clang.

$ cat my-clang
#! /bin/bash
clang -isysroot $(xcrun --sdk iphoneos --show-sdk-path) -arch arm64 "$@"

Thanks,
Manoj

> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: allow disabling streams by type for inputs

[Gyan]

On 02-01-2019 10:49 AM, Gyan wrote:


On 29-12-2018 04:40 PM, Gyan wrote:

-vn/-an/-sn/-dn now work for inputs


Ping.


Plan to push tonight if no objections.

Gyan

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

Re: [FFmpeg-devel] patch for failing on WavPack DSD files

[David Bryant]

On 12/28/18 3:56 AM, Paul B Mahol wrote:
> On 12/24/18, Derek Buitenhuis  wrote:
>> On 24/12/2018 17:47, David Bryant wrote:
>>> I want to do that, but am swamped at work right now, so it will probably
>>> be a few months before I can get to that.
>>>
>>> In the meantime, I think this patch would be a safe stopgap (and prevent
>>> the Kodi crash).
>> I think it's OK for the meantime (my opinion).
> Applied.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks!

The guys at Kodi asked me to request that this patch be backported to 4.0.

I don't really know if that's a thing, but if it is then that would be great.

-David


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

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Vittorio Giovara
> Sent: Wednesday, January 02, 2019 11:13 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and
> bump version
> 
> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun  wrote:
> 
> > The encoders such as libx264 support different QPs offset for
> > different MBs, it makes possible for ROI-based encoding. It makes
> > sense to add support within ffmpeg to generate/accept ROI infos and
> > pass into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > code generates ROI info for that frame, and the encoder finally does
> > the ROI-based encoding.
> >
> > The ROI info is maintained as side data of AVFrame.
> >
> > Signed-off-by: Guo, Yejun 
> > ---
> >  libavutil/frame.c   |  1 +
> >  libavutil/frame.h   | 23 +++
> >  libavutil/version.h |  2 +-
> >  3 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c index
> > 34a6210..bebc50e 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> >  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> > data";
> >  #endif
> >  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic
> Metadata
> > SMPTE2094-40 (HDR10+)";
> > +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
> >  }
> >  return NULL;
> >  }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h index
> > 582ac47..3460b01 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
> >   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
> >   */
> >  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> > +
> > +/**
> > + * Regions Of Interest, the data is an array of AVROI type, the
> > + array
> > size
> > + * is implied by AVFrameSideData::size / sizeof(AVROI).
> > + */
> > +AV_FRAME_DATA_ROIS,
> >
> 
> Any chance i could convince you of unfolding this acronym into
> AV_FRAME_REGIONS_OF_INTEREST (and AVRegionOfInterest)?
> When I first read it I thought you were talking about Return of Investments
> or Request of Invention, which were mildly confusing.

thanks, sure, will change to AV_FRAME_DATA_REGIONS_OF_INTEREST and 
AVRegionOfInterest

> 
> The "AVFrameSideData::size" is a C++-ism, could you please use
> "AVFrameSideData.size" like elsewhere in the header?

ok, will change it.

> 
> You should probably document that sizeof() of this struct is part of the 
> public
> ABI.

thanks for catching this issue, it is not ABI compatible if a new data member 
is later added into
struct AVRegionOfInterest.  will response in following emails.

> 
> 
> >  };
> >
> >  enum AVActiveFormatDescription {
> > @@ -201,6 +207,23 @@ typedef struct AVFrameSideData {  }
> > AVFrameSideData;
> >
> >  /**
> > + * Structure to hold Region Of Interest.
> > + *
> > + * top/bottom/left/right are coordinates at frame pixel level.
> >
> 
> what does  "pixel level" mean? May I suggest better wording?
> 
> Number of pixels to discard from the the top/bottom/left/right border of
> the frame to obtain the region of interest of the frame.

thanks., much better than mine, will use it.

> 
> + * They will be extended internally if the codec requires an alignment.
> > + * If the regions overlap, the last value in the list will be used.
> >
> 
> Isn't this encoder dependent too?

yes, and will add to notes explicitly.

> 
> 
> > + *
> > + * qoffset is quant offset, it is encoder dependent.
> 
> + */
> > +typedef struct AVROI {
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
> > +int qoffset;
> >
> 
> so int instead of float?

I used float in very early version and got feedback to use int. I'm open to 
both, I'll change to float since two comments till now ask for float.

> 
> +} AVROI;
> > +
> > +/**
> >   * This structure describes decoded (raw) audio or video data.
> >   *
> >   * AVFrame must be allocated using av_frame_alloc(). Note that this
> > only diff --git a/libavutil/version.h b/libavutil/version.h index
> > f997615..1fcdea9 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -79,7 +79,7 @@
> >   */
> >
> --
> Vittorio
> ___
> 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 V4 1/2] avutil: add ROI data struct and bump version

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Vittorio Giovara
> Sent: Thursday, January 03, 2019 4:55 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and
> bump version
> 
> On Wed, Jan 2, 2019 at 6:48 PM James Almer  wrote:
> 
> > On 12/28/2018 7:09 AM, Guo, Yejun wrote:
> > > The encoders such as libx264 support different QPs offset for
> > > different
> > MBs,
> > > it makes possible for ROI-based encoding. It makes sense to add
> > > support within ffmpeg to generate/accept ROI infos and pass into
> encoders.
> > >
> > > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > > code generates ROI info for that frame, and the encoder finally does
> > > the ROI-based encoding.
> > >
> > > The ROI info is maintained as side data of AVFrame.
> > >
> > > Signed-off-by: Guo, Yejun 
> > > ---
> > >  libavutil/frame.c   |  1 +
> > >  libavutil/frame.h   | 23 +++
> > >  libavutil/version.h |  2 +-
> > >  3 files changed, 25 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavutil/frame.c b/libavutil/frame.c index
> > > 34a6210..bebc50e 100644
> > > --- a/libavutil/frame.c
> > > +++ b/libavutil/frame.c
> > > @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > >  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> > data";
> > >  #endif
> > >  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic
> > > Metadata
> > SMPTE2094-40 (HDR10+)";
> > > +case AV_FRAME_DATA_ROIS: return "Regions Of Interest";
> > >  }
> > >  return NULL;
> > >  }
> > > diff --git a/libavutil/frame.h b/libavutil/frame.h index
> > > 582ac47..3460b01 100644
> > > --- a/libavutil/frame.h
> > > +++ b/libavutil/frame.h
> > > @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
> > >   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
> > >   */
> > >  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> > > +
> > > +/**
> > > + * Regions Of Interest, the data is an array of AVROI type, the
> > array size
> > > + * is implied by AVFrameSideData::size / sizeof(AVROI).
> > > + */
> > > +AV_FRAME_DATA_ROIS,
> > >  };
> > >
> > >  enum AVActiveFormatDescription {
> > > @@ -201,6 +207,23 @@ typedef struct AVFrameSideData {  }
> > > AVFrameSideData;
> > >
> > >  /**
> > > + * Structure to hold Region Of Interest.
> > > + *
> > > + * top/bottom/left/right are coordinates at frame pixel level.
> > > + * They will be extended internally if the codec requires an alignment.
> > > + * If the regions overlap, the last value in the list will be used.
> > > + *
> > > + * qoffset is quant offset, it is encoder dependent.
> > > + */
> > > +typedef struct AVROI {
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> >
> > uint32_t, please. Make the struct have a fixed size so we don't repeat
> > the same issues we had with fate tests and AVSphericalMapping.
> >
> 
> I thought we dropped the side data size from fate tests in
> 21a8e751ad6abb2d423afa3041da92f8f7741997.
> If so, size_t seems the better choice here.

I usually choose 'size_t' for the meanings with length/size. Will keep this 
since 21a8e751ad6abb2d423afa3041da92f8f7741997 was there.

> --
> Vittorio
> ___
> 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 V8] libavfilter: add transpose_vaapi filter

[Zachary Zhou]

Swap width and height when do clock/cclock rotation
Add reversal/hflip/vflip options

ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
-c:v h264_vaapi output.h264

Signed-off-by: Zachary Zhou 
---
 configure|   2 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/transpose.h  |   3 +
 libavfilter/vf_transpose_vaapi.c | 323 +++
 5 files changed, 330 insertions(+)
 create mode 100644 libavfilter/vf_transpose_vaapi.c

diff --git a/configure b/configure
index 2205751402..bf0e435b53 100755
--- a/configure
+++ b/configure
@@ -3482,6 +3482,7 @@ tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
 tonemap_opencl_filter_deps="opencl const_nan"
 transpose_opencl_filter_deps="opencl"
+transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
 unsharp_opencl_filter_deps="opencl"
 uspp_filter_deps="gpl avcodec"
 vaguedenoiser_filter_deps="gpl"
@@ -5985,6 +5986,7 @@ check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode 
-D_WIN32_WINNT=0x0602
 
 check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
 check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
 check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
 check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..4246d3480f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -394,6 +394,7 @@ OBJS-$(CONFIG_TPAD_FILTER)   += vf_tpad.o
 OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
 OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  += vf_transpose_npp.o cuda_check.o
 OBJS-$(CONFIG_TRANSPOSE_OPENCL_FILTER)   += vf_transpose_opencl.o opencl.o 
opencl/transpose.o
+OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+= vf_transpose_vaapi.o 
vaapi_vpp.o
 OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
 OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  += vf_premultiply.o framesync.o
 OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a600069500..0b82ff7ced 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -373,6 +373,7 @@ extern AVFilter ff_vf_tpad;
 extern AVFilter ff_vf_transpose;
 extern AVFilter ff_vf_transpose_npp;
 extern AVFilter ff_vf_transpose_opencl;
+extern AVFilter ff_vf_transpose_vaapi;
 extern AVFilter ff_vf_trim;
 extern AVFilter ff_vf_unpremultiply;
 extern AVFilter ff_vf_unsharp;
diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
index d4bb4da1ae..aa262b9487 100644
--- a/libavfilter/transpose.h
+++ b/libavfilter/transpose.h
@@ -29,6 +29,9 @@ enum TransposeDir {
 TRANSPOSE_CLOCK,
 TRANSPOSE_CCLOCK,
 TRANSPOSE_CLOCK_FLIP,
+TRANSPOSE_REVERSAL,// rotate by half-turn
+TRANSPOSE_HFLIP,
+TRANSPOSE_VFLIP,
 };
 
 #endif
diff --git a/libavfilter/vf_transpose_vaapi.c b/libavfilter/vf_transpose_vaapi.c
new file mode 100644
index 00..46d193f69d
--- /dev/null
+++ b/libavfilter/vf_transpose_vaapi.c
@@ -0,0 +1,323 @@
+/*
+ * 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 
+
+#include "libavutil/avassert.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "transpose.h"
+#include "vaapi_vpp.h"
+
+typedef struct TransposeVAAPIContext {
+VAAPIVPPContext vpp_ctx; // must be the first field
+int passthrough; // PassthroughType, landscape passthrough mode 
enabled
+int dir; // TransposeDir
+
+int rotation_state;
+int mirror_state;
+} TransposeVAAPIContext;
+
+static int transpose_vaapi_build_filter_params(AVFilterContext *avctx)
+{
+VAAPIVPPContext *vpp_ctx   = avctx->priv;
+TransposeVAAPIContext *ctx = avctx->priv;
+VAStatus vas;
+int support_flag;
+VAProcPipelineCaps pipeline_caps;
+
+memset(

Re: [FFmpeg-devel] [PATCH 01/11] doc/indevs: fix upto typo

[Stephen Hutchinson]

On 1/2/2019 4:43 PM, Michael Niedermayer wrote:

On Wed, Jan 02, 2019 at 10:34:21AM -0900, Lou Logan wrote:

On Mon, Dec 31, 2018, at 12:03 PM, Michael Niedermayer wrote:

Signed-off-by: Michael Niedermayer 
---
  doc/indevs.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Ok.  Same typo is in compat/avisynth/avisynth_c.h.

yes, you should probably report this to avisynth or whereever this is 
maintained if the
typo is still in the upstream version, otherwise our copy should maybe be 
updated
For statistics' sake, the commit introducing that text was from November 
2014¹, and it happened on the
original 2.6 CVS on Sourceforge (which no longer provides CVS, and 2.6 
hasn't migrated to SVN or Git
on Sourceforge; the inactivity is generally assumed to mean AviSynth+ 
should be treated as 'upstream').


AviSynth+ merged in those changes sometime later, and are still present 
in the current/de facto development
HEAD².  The version we ship in compat is slightly older than what 
AviSynth+ currently provides, due
to some issues with MSVC/GCC client program compatibility in the 
avs/capi.h header when [the
chronically fragile support for] GCC compilation of the main AviSynth+ 
project was added in 2016.


¹a mirror of the CVS version of the file from 2015: 
https://github.com/jeeb/avisynth/blame/master/src/core/avisynth_c.h

²https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/include/avisynth_c.h#L255

tl;dr: the header shipped in compat isn't really out of date with 
upstream in its essential functions,

so if the typo just gets fixed here it's probably not a big deal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add tests/fate/hlsenc.mak for hls FATE

[Steven Liu]

Steven Liu  于2018年12月24日周一 下午5:45写道：
>
> init add three test examples:
> 1. check no endlist at the end
> 2. check endlist at the end
> 3. check hls_list_size 0 full list
>
> Signed-off-by: Steven Liu 
> ---
>  tests/Makefile|  1 +
>  tests/fate/hlsenc.mak | 43 +++
>  2 files changed, 44 insertions(+)
>  create mode 100644 tests/fate/hlsenc.mak
>
> diff --git a/tests/Makefile b/tests/Makefile
> index 24680b8150..90801b42b2 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -131,6 +131,7 @@ include $(SRC_PATH)/tests/fate/gif.mak
>  include $(SRC_PATH)/tests/fate/h264.mak
>  include $(SRC_PATH)/tests/fate/hap.mak
>  include $(SRC_PATH)/tests/fate/hevc.mak
> +include $(SRC_PATH)/tests/fate/hlsenc.mak
>  include $(SRC_PATH)/tests/fate/hw.mak
>  include $(SRC_PATH)/tests/fate/id3v2.mak
>  include $(SRC_PATH)/tests/fate/image.mak
> diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak
> new file mode 100644
> index 00..80536239fc
> --- /dev/null
> +++ b/tests/fate/hlsenc.mak
> @@ -0,0 +1,43 @@
> +tests/data/live_no_endlist.m3u8: TAG = GEN
> +tests/data/live_no_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-f lavfi -v verbose -i 
> "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls -hls_time 3 -map 0 \
> +-hls_flags omit_endlist -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_no_endlist_%03d.ts \
> +$(TARGET_PATH)/tests/data/live_no_endlist.m3u8 2>/dev/null
> +
> +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-no-endlist
> +fate-hls-live-no-endlist: tests/data/live_no_endlist.m3u8
> +fate-hls-live-no-endlist: SRC = 
> $(TARGET_PATH)/tests/data/live_no_endlist.m3u8
> +fate-hls-live-no-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false 
> -t 6 -f s24le
> +fate-hls-live-no-endlist: CMP = oneline
> +fate-hls-live-no-endlist: REF = e038bb8e65d4c1745b9b3ed643e607a3
> +
> +tests/data/live_last_endlist.m3u8: TAG = GEN
> +tests/data/live_last_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-f lavfi -v verbose -i 
> "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls -hls_time 3 -map 0 \
> +-codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_last_endlist_%03d.ts \
> +$(TARGET_PATH)/tests/data/live_last_endlist.m3u8 2>/dev/null
> +
> +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-last-endlist
> +fate-hls-live-last-endlist: tests/data/live_last_endlist.m3u8
> +fate-hls-live-last-endlist: SRC = 
> $(TARGET_PATH)/tests/data/live_last_endlist.m3u8
> +fate-hls-live-last-endlist: CMD = md5 -i $(SRC) -af 
> hdcd=process_stereo=false -t 6 -f s24le
> +fate-hls-live-last-endlist: CMP = oneline
> +fate-hls-live-last-endlist: REF = 2ca8567092dcf01e37bedd50454d1ab7
> +
> +
> +tests/data/live_endlist.m3u8: TAG = GEN
> +tests/data/live_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls 
> -hls_time 3 -map 0 \
> +-hls_list_size 0 -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_endlist_%d.ts \
> +$(TARGET_PATH)/tests/data/live_endlist.m3u8 2>/dev/null
> +
> +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-endlist
> +fate-hls-live-endlist: tests/data/live_endlist.m3u8
> +fate-hls-live-endlist: SRC = $(TARGET_PATH)/tests/data/live_endlist.m3u8
> +fate-hls-live-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -t 
> 20 -f s24le
> +fate-hls-live-endlist: CMP = oneline
> +fate-hls-live-endlist: REF = e189ce781d9c87882f58e3929455167b
> +
> --
> 2.15.2 (Apple Git-101.1)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] avcodec/fft_template: improve performance of the ff_fft_init in fft_template

[Steven Liu]

Steven Liu  于2018年12月26日周三 下午4:15写道：
>
> Before patch:
> init nbits = 17, get 1 samples, average cost: 16175 us
> After patch:
> init nbits = 17, get 1 samples, average cost: 14989 us
>
> Signed-off-by: Steven Liu 
> ---
>  libavcodec/fft_template.c | 46 +++---
>  1 file changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 762c014bc8..20a62e4290 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -261,17 +261,41 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int 
> inverse)
>  if (s->fft_permutation == FF_FFT_PERM_AVX) {
>  fft_perm_avx(s);
>  } else {
> -for(i=0; i -int k;
> -j = i;
> -if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
> -j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
> -k = -split_radix_permutation(i, n, s->inverse) & (n-1);
> -if (s->revtab)
> -s->revtab[k] = j;
> -if (s->revtab32)
> -s->revtab32[k] = j;
> -}
> +#define PROCESS_FFT_PERM_SWAP_LSBS(num) do {\
> +for(i = 0; i < n; i++) {\
> +int k;\
> +j = i;\
> +j = (j & ~3) | ((j >> 1) & 1) | ((j << 1) & 2);\
> +k = -split_radix_permutation(i, n, s->inverse) & (n - 1);\
> +s->revtab##num[k] = j;\
> +} \
> +} while(0);
> +
> +#define PROCESS_FFT_PERM_DEFAULT(num) do {\
> +for(i = 0; i < n; i++) {\
> +int k;\
> +j = i;\
> +k = -split_radix_permutation(i, n, s->inverse) & (n - 1);\
> +s->revtab##num[k] = j;\
> +} \
> +} while(0);
> +
> +#define SPLIT_RADIX_PERMUTATION(num) do { \
> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS) {\
> +PROCESS_FFT_PERM_SWAP_LSBS(num) \
> +} else {\
> +PROCESS_FFT_PERM_DEFAULT(num) \
> +}\
> +} while(0);
> +
> +if (s->revtab)
> +SPLIT_RADIX_PERMUTATION()
> +if (s->revtab32)
> +SPLIT_RADIX_PERMUTATION(32)
> +
> +#undef PROCESS_FFT_PERM_DEFAULT
> +#undef PROCESS_FFT_PERM_SWAP_LSBS
> +#undef SPLIT_RADIX_PERMUTATION
>  }
>
>  return 0;
> --
> 2.15.2 (Apple Git-101.1)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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