Re: [FFmpeg-devel] [PATCH] Add FITS Encoder
On 14.07.2017, at 19:04, Paras Chadha wrote:
> +static int write_keyword_value(char * header, const char * keyword, int
> value)
> +{
> +int i, len, ret;
> +len = strlen(keyword);
> +for (i = 0; i < len; i++) {
> +header[i] = keyword[i];
> +}
would suggest memcpy (especially in combination with next suggestion).
> +char header_line[80];
I would suggest memset to fill with spaces, to avoid most loops.
> +if (fitsctx->first_image) {
> +strncpy(header_line, "SIMPLE = ", 10);
> +for (i = 10; i < 80; i++) {
> +header_line[i] = ' ';
> +}
> +header_line[29] = 'T';
> +} else {
> +strncpy(header_line, "XTENSION= 'IMAGE '", 20);
> +for (i = 20; i < 80; i++) {
> +header_line[i] = ' ';
> +}
> +}
Never use strncpy, it has utterly broken behaviour that never makes sense.
av_strlcpy could be used, but just memcpy is probably best here.
> +bytestream2_put_buffer(&pbc, header_line, 80);
> +lines_written++;
Admittedly it provides some protection against buffer overflow
(but then, overflowing an on-stack buffer like header_line would be worse),
but it just feels wrong to construct the header in header_line just to then copy
it over into the packet.
It could just be written directly into the packet data, either manually or via
bytestream2 functions (but using those memset with space probably can't be used
to avoid a lot of code).
> +write_keyword_value(header_line, "NAXIS", naxis);
Either here or maybe rather in the switch it might be good to explain a bit
what the naxis stuff is used for.
For someone coming across the format for the first time, the number of
components being called "axis" seems really weird.
> +if (bitpix == 16) {
> +write_keyword_value(header_line, "BZERO", bzero);
> +bytestream2_put_buffer(&pbc, header_line, 80);
> +lines_written++;
> +}
This might also be worth a comment.
> +switch (avctx->pix_fmt) {
> +#define case_n(cas, dref) \
Macro definitions should start in column 0 (I think they actually have to?) and
be in all-uppercase.
> +case cas: \
> +for (k = 0; k < naxis3; k++) { \
> +for (i = 0; i < avctx->height; i++) { \
> +ptr = p->data[0] + (avctx->height - i - 1) *
> p->linesize[0] + k; \
> +for (j = 0; j < avctx->width; j++) { \
> +bytestream2_put_byte(&pbc, dref(ptr) - bzero); \
> +ptr += naxis3; \
> +} \
> +} \
> +} \
> +break
> +case_n(AV_PIX_FMT_RGB24, *);
> +case_n(AV_PIX_FMT_RGBA, *);
> +case_n(AV_PIX_FMT_RGB48BE, AV_RB16);
> +case_n(AV_PIX_FMT_RGBA64BE, AV_RB16);
The macro will generate the same code for RGB24 and RGBA, and respectively for
the other 2 cases.
Doing this without a macro and merging the cases with identical code seems much
better.
> +if (bitpix == 16) {
> +for (j = 0; j < avctx->width; j++) {
> +bytestream2_put_be16(&pbc, AV_RB16(ptr) - bzero);
> +ptr += 2;
> +}
Can't bzero be chosen as 0? Because then this is just a normal memcpy...
> +t = padded_data_size - data_size;
> +while (t--) {
> +bytestream2_put_byte(&pbc, 0);
> +}
Might be worth getting the bytestream pointer and memset (or adding memset
functionality to bytestream2).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add sub-srt-badsyntax test
On Tue, Jul 11, 2017 at 11:16:43PM +0200, Michael Niedermayer wrote: > Based-on: srt sample by ubitux > > Signed-off-by: Michael Niedermayer > --- > tests/fate/subtitles.mak | 3 +++ > tests/ref/fate/sub-srt-badsyntax | 22 ++ > 2 files changed, 25 insertions(+) > create mode 100644 tests/ref/fate/sub-srt-badsyntax applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
On Fri, Jul 14, 2017 at 5:38 PM, Michael Niedermayer wrote: > > I dont think CTTS is the only affected atom. > > Thanks for the response. Yes, I think that's likely true. The ctts one is just likely the most important since it controls timestamp ordering. > what you describe sounds like an option. but i might be missing something, > possibly even something significant. I dont feel that confident with > this code after quickly looking at it. > Here are my experiments thus far if you have further thoughts: https://chromium-review.googlesource.com/c/572730/ https://chromium-review.googlesource.com/c/572585/ Both fixes and the existing code seem to suffer from assuming that the sample number in the AVIndex and that of the ctts_data are the same; which seems questionable. The second experiment should be viable with the addition of memmove() when inserting in the middle of the array. Will look at it more next week. - dale ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
Hi
On Fri, Jul 14, 2017 at 02:52:23PM -0700, Dale Curtis wrote:
> After looking at this some more. I don't think the way ctts entries are
> stored is correct unless you assume all ctts entries are known prior to any
> seeks taking place. Either through reading all trun boxes ahead of time or
> content having a ctts atom.
>
> The current code is broken in the presence of seeks since seeks can not
> know the proper ctts index unless all trun boxes have been read. Instead it
> performs the seek+root switch and then ends up writing ctts entries into
> the wrong slots of the global ctts index as trun boxes are encountered
> after the seek.
>
> To fix this I think the code needs to only use the global ctts index if the
> ctts atom is present. If the ctts data is just being pulled from the trun
> boxes, then it should probably be stored in along with each
> MOVFragmentIndex.
>
> Is anyone else familiar enough with this code to have opinions on direction
> here? Rodger seems MIA.
I dont think CTTS is the only affected atom.
what you describe sounds like an option. but i might be missing something,
possibly even something significant. I dont feel that confident with
this code after quickly looking at it.
>
> - dale
>
> On Fri, Jun 30, 2017 at 2:56 PM, Dale Curtis
> wrote:
>
> > Hmm, finally got around to looking into this again and this still isn't
> > fixed. Just seeking a few times in ffplay can trigger this issue with the
> > clip linked in my original message:
> >
> > http://storage.googleapis.com/dalecurtis-shared/buck480p30_na.mp4
> >
> > ./ffplay -v debug -drp 1 ~/Downloads/buck480p30_na.mp4
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14583000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14586000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found fragment index for track 1
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found fragment index entry for
> > track 1 and moof_offset 16686198
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found frag time 14589000, using
> > it for dts
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14607000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 1461
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14622000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14631000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14634000
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> > 14643000
> >
> > Disabled sidx processing resolves this issue:
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 63f84be782..919475f12f 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -5497,7 +5497,7 @@ static const MOVParseTableEntry
> > mov_default_parse_table[] = {
> > { MKTAG('a','l','a','c'), mov_read_alac }, /* alac specific atom */
> > { MKTAG('a','v','c','C'), mov_read_glbl },
> > { MKTAG('p','a','s','p'), mov_read_pasp },
> > -{ MKTAG('s','i','d','x'), mov_read_sidx },
> > +// { MKTAG('s','i','d','x'), mov_read_sidx },
> >
> > Rodger, are you able to still look into this?
> >
> > - dale
> >
> > On Fri, Feb 12, 2016 at 2:21 AM, Rodger Combs
> > wrote:
> >
> >> This issue is fixed by this patch, but I'm unsure of possible
> >> implications on other files. It passes FATE, at least.
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 149e3b4..c5e0a1e 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -3609,7 +3609,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> >> *pb, MOVAtom atom)
> >> }
> >> av_log(c->fc, AV_LOG_DEBUG, "calculated into dts
> >> %"PRId64"\n", dts);
> >> } else {
> >> -dts = frag->time;
> >> +dts = frag->time - sc->time_offset;
> >> av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
> >> ", using it for dts\n", dts);
> >> }
> >>
> >>
> >> > On Jan 15, 2016, at 16:57, Michael Niedermayer
> >> wrote:
> >> >
> >> > On Fri, Jan 15, 2016 at 10:24:43PM +, Dan Sanders wrote:
> >> >> Michael, I wanted to check if you have you looked into this playback
> >> issue,
> >> >> or were planning to?
> >> >
> >> > i didnt look into it, i had thought rodger would look into it as it
> >> > was his patch ...
> >> >
> >> > rodger, did you look into this ?
> >> >
> >> > [...]
> >> > --
> >> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >> >
> >> > Rewriting code that is poorly written but fully understood is good.
> >> > Rewriting code that one doesnt understand is a sign that one is less
> >> smart
> >> > then the original author, trying to rewrite it will not make it better.
> >>
> >>
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-de
Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
After looking at this some more. I don't think the way ctts entries are
stored is correct unless you assume all ctts entries are known prior to any
seeks taking place. Either through reading all trun boxes ahead of time or
content having a ctts atom.
The current code is broken in the presence of seeks since seeks can not
know the proper ctts index unless all trun boxes have been read. Instead it
performs the seek+root switch and then ends up writing ctts entries into
the wrong slots of the global ctts index as trun boxes are encountered
after the seek.
To fix this I think the code needs to only use the global ctts index if the
ctts atom is present. If the ctts data is just being pulled from the trun
boxes, then it should probably be stored in along with each
MOVFragmentIndex.
Is anyone else familiar enough with this code to have opinions on direction
here? Rodger seems MIA.
- dale
On Fri, Jun 30, 2017 at 2:56 PM, Dale Curtis
wrote:
> Hmm, finally got around to looking into this again and this still isn't
> fixed. Just seeking a few times in ffplay can trigger this issue with the
> clip linked in my original message:
>
> http://storage.googleapis.com/dalecurtis-shared/buck480p30_na.mp4
>
> ./ffplay -v debug -drp 1 ~/Downloads/buck480p30_na.mp4
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14583000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14586000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found fragment index for track 1
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found fragment index entry for
> track 1 and moof_offset 16686198
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] found frag time 14589000, using
> it for dts
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14607000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 1461
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14622000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14631000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14634000
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce8c0] invalid dts/pts combination
> 14643000
>
> Disabled sidx processing resolves this issue:
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63f84be782..919475f12f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5497,7 +5497,7 @@ static const MOVParseTableEntry
> mov_default_parse_table[] = {
> { MKTAG('a','l','a','c'), mov_read_alac }, /* alac specific atom */
> { MKTAG('a','v','c','C'), mov_read_glbl },
> { MKTAG('p','a','s','p'), mov_read_pasp },
> -{ MKTAG('s','i','d','x'), mov_read_sidx },
> +// { MKTAG('s','i','d','x'), mov_read_sidx },
>
> Rodger, are you able to still look into this?
>
> - dale
>
> On Fri, Feb 12, 2016 at 2:21 AM, Rodger Combs
> wrote:
>
>> This issue is fixed by this patch, but I'm unsure of possible
>> implications on other files. It passes FATE, at least.
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 149e3b4..c5e0a1e 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -3609,7 +3609,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>> }
>> av_log(c->fc, AV_LOG_DEBUG, "calculated into dts
>> %"PRId64"\n", dts);
>> } else {
>> -dts = frag->time;
>> +dts = frag->time - sc->time_offset;
>> av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
>> ", using it for dts\n", dts);
>> }
>>
>>
>> > On Jan 15, 2016, at 16:57, Michael Niedermayer
>> wrote:
>> >
>> > On Fri, Jan 15, 2016 at 10:24:43PM +, Dan Sanders wrote:
>> >> Michael, I wanted to check if you have you looked into this playback
>> issue,
>> >> or were planning to?
>> >
>> > i didnt look into it, i had thought rodger would look into it as it
>> > was his patch ...
>> >
>> > rodger, did you look into this ?
>> >
>> > [...]
>> > --
>> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> >
>> > Rewriting code that is poorly written but fully understood is good.
>> > Rewriting code that one doesnt understand is a sign that one is less
>> smart
>> > then the original author, trying to rewrite it will not make it better.
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add VMAF filter
Hi, templatized 8-bit and 10-bit functions. Documented options in
doc/filters.texi
and fixed most of the issues with earlier patches.
Signed-off-by: Ashish Singh
---
Changelog| 1 +
configure| 5 +
doc/filters.texi | 64 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_libvmaf.c | 340 +++
6 files changed, 412 insertions(+)
create mode 100644 libavfilter/vf_libvmaf.c
diff --git a/Changelog b/Changelog
index 1778980..311b55b 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
- config.log and other configuration files moved into ffbuild/ directory
- update cuvid/nvenc headers to Video Codec SDK 8.0.14
- afir audio filter
+- vmaf video filter
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/configure b/configure
index 5ae5227..bafcd07 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
--enable-libtwolame enable MP2 encoding via libtwolame [no]
--enable-libv4l2 enable libv4l2/v4l-utils [no]
--enable-libvidstab enable video stabilization using vid.stab [no]
+ --enable-libvmaf enable vmaf filter via libvmaf [no]
--enable-libvo-amrwbenc enable AMR-WB encoding via libvo-amrwbenc [no]
--enable-libvorbis enable Vorbis en/decoding via libvorbis,
native implementation exists [no]
@@ -1569,6 +1570,7 @@ EXTERNAL_LIBRARY_LIST="
libtheora
libtwolame
libv4l2
+libvmaf
libvorbis
libvpx
libwavpack
@@ -3172,6 +3174,7 @@ uspp_filter_deps="gpl avcodec"
vaguedenoiser_filter_deps="gpl"
vidstabdetect_filter_deps="libvidstab"
vidstabtransform_filter_deps="libvidstab"
+vmaf_filter_deps="libvmaf"
zmq_filter_deps="libzmq"
zoompan_filter_deps="swscale"
zscale_filter_deps="libzimg"
@@ -5845,6 +5848,8 @@ enabled libtwolame&& require libtwolame twolame.h
twolame_init -ltwolame
die "ERROR: libtwolame must be installed and
version must be >= 0.3.10"; }
enabled libv4l2 && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl
enabled libvidstab&& require_pkg_config "vidstab >= 0.98"
vid.stab/libvidstab.h vsMotionDetectInit
+enabled libvmaf && { check_lib libvmaf "libvmaf.h" "compute_vmaf"
-lvmaf -lstdc++ -lpthread -lm ||
+ die "ERROR: libvmaf must be installed"; }
enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h
E_IF_init -lvo-amrwbenc
enabled libvorbis && require libvorbis vorbis/vorbisenc.h
vorbis_info_init -lvorbisenc -lvorbis -logg
diff --git a/doc/filters.texi b/doc/filters.texi
index 5985db6..44e95b4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14701,6 +14701,70 @@ vignette='PI/4+random(1)*PI/50':eval=frame
@end itemize
+@section vmaf
+
+Obtain the average VMAF (Video Multi-Method Assessment Fusion)
+score between two input videos.
+
+This filter takes two input videos.
+
+Both video inputs must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The obtained average VMAF score is printed through the logging system.
+
+Currently it requires Netflix's vmaf library (libvmaf) as a pre-requisite.
+After installing the library it can be enabled using:
+@code{./configure --enable-libvmaf}.
+If no model path is specified it uses the default model:
@code{vmaf_v0.6.1.pkl}.
+
+On the below examples the input file @file{main.mpg} being processed is
+compared with the reference file @file{ref.mpg}.
+
+The filter has following options:
+
+@table @option
+@item model_path
+Set the model path which is to be used for SVM.
+Default value: @code{"vmaf_v0.6.1.pkl"}
+
+@item log_path
+Set the file path to be used to store logs.
+
+@item log_fmt
+Set the format of the log file (xml or json).
+
+@item enable_transform
+Enables transform for computing vmaf.
+
+@item phone_model
+Invokes the phone model which will generate VMAF scores higher than in the
+regular model, which is more suitable for laptop, TV, etc. viewing conditions.
+
+@item psnr
+Enables computing psnr along with vmaf.
+
+@item ssim
+Enables computing ssim along with vmaf.
+
+@item ms_ssim
+Enables computing ms_ssim along with vmaf.
+
+@item pool
+Set the pool method to be used for computing vmaf.
+@end table
+
+For example:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf -f null -
+@end example
+
+Example with options:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf="psnr=1:enable-transform=1" -f null -
+@end example
+
@section vstack
Stack input videos vertically.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..1c4bd56 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -314,6 +314,7 @@ OBJS-$(CONFIG_VFLIP_FILTER) += vf_vfli
Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer
Le tridi 23 messidor, an CCXXV, Paras Chadha a écrit : > Hi, I have attached the dump of a FITS File containing 5 images and 4 > binary table xtensions. The dump is taken using fdump utility. Please take > a look. Thanks for the dump. But it is you who know the format, thus it is you who can tell the most accurate things about it. Anyway, distributing the task between the demuxer and the decoder and deciding the format of the payload is absolutely necessary before any real work can proceed on the implementation. > This is the header of the first (primary) image. > > SIMPLE =T / FITS STANDARD > BITPIX =8 / Character information > NAXIS =0 / No image data array present > EXTEND =T / There may be standard extensions > DATE= '21/09/99' / Date file was written (dd/mm/yy) 19yy > ORIGIN = 'CEA/SSL UC Berkeley' / EUVE Science Archive > CREATOR = 'STWFITS ' / Fitsio version 05-Aug-1997 > TELESCOP= 'EUVE' / Extreme Ultraviolet Explorer > INSTTYPE= 'DS/S' / Instrument type (DS/S, SCANNER) > OBJECT = '' / Name of observed object > RA_OBJ = 79.17265 / R.A. of the object (degrees) > DEC_OBJ = 45.99862 / Declination of the object (degrees) > RA_PNT = 79.17243 / R.A. of the pointing direction (degrees) > DEC_PNT = 46.007 / Declination of the pointing direction > (degrees) > RA_PROC = 79.17586 / R.A. used to process data (degrees) > DEC_PROC= 45.99578 / Declination used to process data (degrees) > DATE-OBS= '08/09/99 GMT' / Start date of observation (dd/mm/yy) 19yy > TIME-OBS= '00:14:29 GMT' / Start time of observation (hh:mm:ss GMT) > DATE-END= '13/09/99 GMT' / End date of observation (dd/mm/yy) 19yy > TIME-END= '22:07:43 GMT' / End time of observation (hh:mm:ss GMT) > OBS_MODE= 'POINTING' / Inertial pointing mode > DITHER = 'SPIRAL ' / Spacecraft dither type (DITHERED, SPIRAL, > NONE) > DETMODE = 'WSZ ' / Detector position conversion mode (WSZ or XY) > OFF-AXIS=F / Was this pointing done off-axis > MOVING =F / Did the source position vary during > observation > DAYNIGHT= 'NIGHT ' / Day/night data indicator (DAY, NIGHT, BOTH) > VALIDTIM= 132369.40583229 / Amount of telemetry present (seconds) > RA_UNIT = 'deg ' / Units for Right Ascension > DEC_UNIT= 'deg ' / Units for Declination > EQUINOX =2000. / Coordinate equinox > RADECSYS= 'FK5 ' / Frame of reference of coordinates > TIMESYS = 'MJD ' / MJD = JD - 240.5 > TIMEZERO= 0. / No time offset required for EUVE event times > TIMEUNIT= 's ' / Units for TSTART, TSTOP, TIMEZERO > CLOCKCOR= 'NO ' / Not corrected to UT > TIMEREF = 'LOCAL ' / No corrections applied (barycentric, etc.) > TASSIGN = 'SATELLITE' / Event times are assigned at the satellite > TSTART = 987466469.376002 / Time of start of observation (seconds) > TSTOP = 987977263.104001 / Time of end of observation (seconds) > MJDREF = 4. / MJD of SC clock start, 24.00 May 1968 > EGOCSVER= 'egocs1.7.2' / Software version used to produce this data > REFVERS = 'egodata1.15.2' / Reference calibration dataset version used > COMMENT ' ' > COMMENT 'This file is part of the EUVE Science Archive. It contains' > COMMENT 'images and filter limits for one EUVE observation.' > COMMENT ' ' > COMMENT 'The EUVE Science Archive contains the science data from' > COMMENT 'observations performed with the EUVE telescopes. It forms one' > COMMENT 'part of the EUVE Permanent Archive. The other part of the' > COMMENT 'permanent archive is the EUVE Telemetry Archive, which is a' > COMMENT 'complete record of the raw telemetry from the EUVE mission.' > COMMENT ' ' > COMMENT 'For documentation of the contents of the EUVE Science Archive,' > COMMENT 'see the "EUVE Science Archive User's Guide". The contents of' > COMMENT 'the EUVE Telemetry Archive are described in the "EUVE' > COMMENT 'Telemetry Archive User's Guide".' > COMMENT ' ' > COMMENT 'The EUVE Permanent Archive was produced by the Center for EUV' > COMMENT 'Astrophysics, a division of UC Berkeley's Space Science' > COMMENT Laboratory. > COMMENT ' ' > END > > This will be followed by the data part whose size (in bits) is given by - > |BITPIX| * GCOUNT * (PCOUNT + NAXIS1 * NAXIS2 * ... * NAXISm) = 0 in this > case, so no data part is there You forgot to explain what should be done with an image without data. > > This is the header of second image. > > XTENSION= 'IMAGE ' / IMAGE extension > BITPIX = 16 / 8-bit bytes > NAXIS =
[FFmpeg-devel] [PATCH] Add FITS Encoder
Signed-off-by: Paras Chadha
---
doc/general.texi | 2 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/fitsenc.c | 259 +
libavformat/img2enc.c | 1 +
5 files changed, 264 insertions(+)
create mode 100644 libavcodec/fitsenc.c
diff --git a/doc/general.texi b/doc/general.texi
index 8f582d5..7f389ce 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -591,6 +591,8 @@ following image formats are supported:
@tab Digital Picture Exchange
@item EXR @tab @tab X
@tab OpenEXR
+@item FITS @tab X @tab X
+@tab Flexible Image Transport System
@item JPEG @tab X @tab X
@tab Progressive JPEG is not supported.
@item JPEG 2000@tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index de1187f..9ad44e0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -291,6 +291,7 @@ OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
OBJS-$(CONFIG_FIC_DECODER) += fic.o
OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o
+OBJS-$(CONFIG_FITS_ENCODER)+= fitsenc.o
OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flac.o
OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o flac.o
vorbis_data.o
OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0243f47..d180dde 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -192,6 +192,7 @@ static void register_all(void)
REGISTER_ENCDEC (FFV1, ffv1);
REGISTER_ENCDEC (FFVHUFF, ffvhuff);
REGISTER_DECODER(FIC, fic);
+REGISTER_ENCDEC (FITS, fits);
REGISTER_ENCDEC (FLASHSV, flashsv);
REGISTER_ENCDEC (FLASHSV2, flashsv2);
REGISTER_DECODER(FLIC, flic);
diff --git a/libavcodec/fitsenc.c b/libavcodec/fitsenc.c
new file mode 100644
index 000..62d97fc
--- /dev/null
+++ b/libavcodec/fitsenc.c
@@ -0,0 +1,259 @@
+/*
+ * FITS image encoder
+ * Copyright (c) 2017 Paras Chadha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * FITS image encoder
+ *
+ * Specification: https://fits.gsfc.nasa.gov/fits_standard.html Version 3.0
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct FITSContext {
+int first_image;
+} FITSContext;
+
+static av_cold int fits_encode_init(AVCodecContext *avctx)
+{
+FITSContext * fitsctx = avctx->priv_data;
+fitsctx->first_image = 1;
+return 0;
+}
+
+static int write_keyword_value(char * header, const char * keyword, int value)
+{
+int i, len, ret;
+len = strlen(keyword);
+for (i = 0; i < len; i++) {
+header[i] = keyword[i];
+}
+for (; i < 8; i++) {
+header[i] = ' ';
+}
+header[8] = '=';
+header[9] = ' ';
+ret = snprintf(header + 10, 70, "%d", value);
+for (i = ret + 10; i < 80; i++) {
+header[i] = ' ';
+}
+return 0;
+}
+
+static int fits_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *pict, int *got_packet)
+{
+AVFrame * const p = (AVFrame *)pict;
+FITSContext * fitsctx = avctx->priv_data;
+PutByteContext pbc;
+uint8_t *ptr;
+uint64_t header_size = 2880, data_size = 0, padded_data_size = 0,
lines_written = 0;
+int ret, bitpix, naxis, naxis3 = 1, bzero = 0, i, j, k, t, rgb = 0;
+char header_line[80];
+
+switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GRAY8:
+bitpix = 8;
+naxis = 2;
+break;
+case AV_PIX_FMT_GRAY16BE:
+bitpix = 16;
+naxis = 2;
+bzero = 32768;
+break;
+case AV_PIX_FMT_RGB24:
+case AV_PIX_FMT_RGBA:
+bitpix = 8;
+naxis = 3;
+rgb = 1;
+if (avctx->pix_fmt == AV_PIX_FMT_RGB24) {
+naxis3 = 3;
+} else {
+naxis3 = 4;
+}
+break;
+case AV_PIX_FMT_RGB48BE:
+case AV_PIX_FMT_RGBA64BE:
+
Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV encoder
On 14.07.2017, at 16:30, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol Probably not making myself popular with that request, but maybe you could do a pass over the code and add comments for things that might be useful for people to know? If you need concrete examples I am thinking of qsort vs AV_QSORT usage, and comments sumarizing what some of those loops with large bodies do, but there might be other things valuable to dump brain -> code. Thanks, Reimar ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vorbisenc: Add pre-echo detection
On Fri, Jul 14, 2017 at 12:43:26AM +0200, Michael Niedermayer wrote: > On Wed, Jul 12, 2017 at 04:18:06PM -0600, Tyler Jones wrote: > [...] > > > > +av_cold int psy_vorbis_init(VorbisPsyContext *vpctx, int sample_rate, > > +int channels, int blocks) > > non static functions needs a prefix > in this case ff_ > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Does the universe only have a finite lifespan? No, its going to go on > forever, its just that you wont like living in it. -- Hiranya Peiri Noted, thank you for noticing. This is changed for the next revision. Tyler Jones 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/3] avcodec/get_bits: add cached bitstream reader
On Fri, Jul 14, 2017 at 05:12:25PM +0200, Hendrik Leppkes wrote:
> On Fri, Jul 14, 2017 at 4:08 PM, foo86 wrote:
> > On Thu, Jul 13, 2017 at 12:27:03PM +0200, Paul B Mahol wrote:
> >> +static inline unsigned int get_bits(GetBitContext *s, int n)
> >> {
> >> +#ifdef CACHED_BITSTREAM_READER
> >> +register int tmp = 0;
> >> +#ifdef BITSTREAM_READER_LE
> >> +uint64_t left = 0;
> >> +#endif
> >> +
> >> +av_assert2(n>0 && n<=32);
> >> +if (n > s->bits_left) {
> >> +n -= s->bits_left;
> >> +#ifdef BITSTREAM_READER_LE
> >> +left = s->bits_left;
> >> +#endif
> >> +tmp = get_val(s, s->bits_left);
> > This triggers an assert in get_val() if s->bits_left == 0.
> >
> >> +refill_32(s);
> >> +}
> >> +
> >> +#ifdef BITSTREAM_READER_LE
> >> +tmp = get_val(s, n) << left | tmp;
> >> +#else
> >> +tmp = get_val(s, n) | tmp << n;
> > This causes undefined behavior if n > 30.
>
> get_bits is only valid until n = 25 in the "non-cached" case, so its
> not a problem to impose the same limitation on the cached reader.
> In fact, if they are to share the exact same API, it should probably
> follow that they also share the same constraints, so that we can do
> proper performance comparisons between the two, instead of having to
> re-write the using code.
Cached bitstream reader currently uses get_bits() to implement
get_bits_long(), which means cached get_bits() must support reading
values up to 32 bits.
I agree however that cached/uncached bistream readers should have the
same API contraints. That means cached get_bits_long() should probably
have a separate implementation.
>
> - Hendrik
> ___
> 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 1/3] avcodec/get_bits: add cached bitstream reader
On Fri, Jul 14, 2017 at 4:08 PM, foo86 wrote:
> On Thu, Jul 13, 2017 at 12:27:03PM +0200, Paul B Mahol wrote:
>> +static inline unsigned int get_bits(GetBitContext *s, int n)
>> {
>> +#ifdef CACHED_BITSTREAM_READER
>> +register int tmp = 0;
>> +#ifdef BITSTREAM_READER_LE
>> +uint64_t left = 0;
>> +#endif
>> +
>> +av_assert2(n>0 && n<=32);
>> +if (n > s->bits_left) {
>> +n -= s->bits_left;
>> +#ifdef BITSTREAM_READER_LE
>> +left = s->bits_left;
>> +#endif
>> +tmp = get_val(s, s->bits_left);
> This triggers an assert in get_val() if s->bits_left == 0.
>
>> +refill_32(s);
>> +}
>> +
>> +#ifdef BITSTREAM_READER_LE
>> +tmp = get_val(s, n) << left | tmp;
>> +#else
>> +tmp = get_val(s, n) | tmp << n;
> This causes undefined behavior if n > 30.
get_bits is only valid until n = 25 in the "non-cached" case, so its
not a problem to impose the same limitation on the cached reader.
In fact, if they are to share the exact same API, it should probably
follow that they also share the same constraints, so that we can do
proper performance comparisons between the two, instead of having to
re-write the using code.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] webmdashenc: Fix memory leak
Signed-off-by: Derek Buitenhuis
---
libavformat/webmdashenc.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index 550ad72e4d..1280d8a763 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -288,33 +288,55 @@ static int parse_filename(char *filename, char
**representation_id,
char *period_pos = NULL;
char *temp_pos = NULL;
char *filename_str = av_strdup(filename);
-if (!filename_str) return AVERROR(ENOMEM);
+int ret = 0;
+
+if (!filename_str) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
temp_pos = av_stristr(filename_str, "_");
while (temp_pos) {
underscore_pos = temp_pos + 1;
temp_pos = av_stristr(temp_pos + 1, "_");
}
-if (!underscore_pos) return AVERROR_INVALIDDATA;
+if (!underscore_pos) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
period_pos = av_stristr(underscore_pos, ".");
-if (!period_pos) return AVERROR_INVALIDDATA;
+if (!period_pos) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
*(underscore_pos - 1) = 0;
if (representation_id) {
*representation_id = av_malloc(period_pos - underscore_pos + 1);
-if (!(*representation_id)) return AVERROR(ENOMEM);
+if (!(*representation_id)) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
av_strlcpy(*representation_id, underscore_pos, period_pos -
underscore_pos + 1);
}
if (initialization_pattern) {
*initialization_pattern = av_asprintf("%s_$RepresentationID$.hdr",
filename_str);
-if (!(*initialization_pattern)) return AVERROR(ENOMEM);
+if (!(*initialization_pattern)) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
}
if (media_pattern) {
*media_pattern = av_asprintf("%s_$RepresentationID$_$Number$.chk",
filename_str);
-if (!(*media_pattern)) return AVERROR(ENOMEM);
+if (!(*media_pattern)) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
}
-av_free(filename_str);
-return 0;
+
+end:
+av_freep(&filename_str);
+return ret;
}
/*
--
2.13.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add MagicYUV encoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 2 +-
libavcodec/magicyuvenc.c | 482 +++
3 files changed, 484 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/magicyuvenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 59029a8..af7e1f2 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -384,6 +384,7 @@ OBJS-$(CONFIG_M101_DECODER)+= m101.o
OBJS-$(CONFIG_MACE3_DECODER) += mace.o
OBJS-$(CONFIG_MACE6_DECODER) += mace.o
OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
+OBJS-$(CONFIG_MAGICYUV_ENCODER)+= magicyuvenc.o
OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
OBJS-$(CONFIG_METASOUND_DECODER) += metasound.o metasound_data.o \
twinvq.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0243f47..2fe415a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -239,7 +239,7 @@ static void register_all(void)
REGISTER_ENCODER(LJPEG, ljpeg);
REGISTER_DECODER(LOCO, loco);
REGISTER_DECODER(M101, m101);
-REGISTER_DECODER(MAGICYUV, magicyuv);
+REGISTER_ENCDEC (MAGICYUV, magicyuv);
REGISTER_DECODER(MDEC, mdec);
REGISTER_DECODER(MIMIC, mimic);
REGISTER_ENCDEC (MJPEG, mjpeg);
diff --git a/libavcodec/magicyuvenc.c b/libavcodec/magicyuvenc.c
new file mode 100644
index 000..bf79247
--- /dev/null
+++ b/libavcodec/magicyuvenc.c
@@ -0,0 +1,482 @@
+/*
+ * MagicYUV encoder
+ * Copyright (c) 2017 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
+#include
+
+#include "libavutil/pixdesc.h"
+#include "libavutil/qsort.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "put_bits.h"
+#include "internal.h"
+#include "thread.h"
+#include "lossless_videoencdsp.h"
+
+typedef enum Prediction {
+LEFT = 1,
+GRADIENT,
+MEDIAN,
+} Prediction;
+
+typedef struct HuffEntry {
+uint8_t sym;
+uint8_t len;
+uint32_t code;
+} HuffEntry;
+
+typedef struct MagicYUVContext {
+PutBitContextpb;
+int planes;
+uint8_t format;
+AVFrame *p;
+int max;
+int slice_height;
+int nb_slices;
+int correlate;
+int hshift[4];
+int vshift[4];
+uint8_t *slices[4];
+unsigned slice_pos[4];
+unsigned tables_size;
+HuffEntryhe[4][256];
+LLVidEncDSPContext llvidencdsp;
+} MagicYUVContext;
+
+static av_cold int magy_encode_init(AVCodecContext *avctx)
+{
+MagicYUVContext *s = avctx->priv_data;
+int i;
+
+switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GBRP:
+avctx->codec_tag = MKTAG('M', '8', 'R', 'G');
+s->correlate = 1;
+s->format = 0x65;
+break;
+case AV_PIX_FMT_GBRAP:
+avctx->codec_tag = MKTAG('M', '8', 'R', 'A');
+s->correlate = 1;
+s->format = 0x66;
+break;
+case AV_PIX_FMT_YUV420P:
+avctx->codec_tag = MKTAG('M', '8', 'Y', '0');
+s->hshift[1] =
+s->vshift[1] =
+s->hshift[2] =
+s->vshift[2] = 1;
+s->format = 0x69;
+break;
+case AV_PIX_FMT_YUV422P:
+avctx->codec_tag = MKTAG('M', '8', 'Y', '2');
+s->hshift[1] =
+s->hshift[2] = 1;
+s->format = 0x68;
+break;
+case AV_PIX_FMT_YUV444P:
+avctx->codec_tag = MKTAG('M', '8', 'Y', '4');
+s->format = 0x67;
+break;
+case AV_PIX_FMT_YUVA444P:
+avctx->codec_tag = MKTAG('M', '8', 'Y', 'A');
+s->format = 0x6a;
+break;
+case AV_PIX_FMT_GRAY8:
+avctx->codec_tag = MKTAG('M', '8', 'G', '0');
+s->format = 0x6b;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format: %d\n",
+ avctx->pix_fmt);
+return AVERROR_INVALIDDATA;
+}
+
+ff_llvidencdsp_init(&s->llvidencdsp);
+
+s->planes =
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader
On Thu, Jul 13, 2017 at 12:27:03PM +0200, Paul B Mahol wrote:
> +static inline unsigned int get_bits(GetBitContext *s, int n)
> {
> +#ifdef CACHED_BITSTREAM_READER
> +register int tmp = 0;
> +#ifdef BITSTREAM_READER_LE
> +uint64_t left = 0;
> +#endif
> +
> +av_assert2(n>0 && n<=32);
> +if (n > s->bits_left) {
> +n -= s->bits_left;
> +#ifdef BITSTREAM_READER_LE
> +left = s->bits_left;
> +#endif
> +tmp = get_val(s, s->bits_left);
This triggers an assert in get_val() if s->bits_left == 0.
> +refill_32(s);
> +}
> +
> +#ifdef BITSTREAM_READER_LE
> +tmp = get_val(s, n) << left | tmp;
> +#else
> +tmp = get_val(s, n) | tmp << n;
This causes undefined behavior if n > 30.
> +#endif
> +
> +#else
> register int tmp;
> OPEN_READER(re, s);
> av_assert2(n>0 && n<=25);
> UPDATE_CACHE(re, s);
> -tmp = SHOW_SBITS(re, s, n);
> +tmp = SHOW_UBITS(re, s, n);
> LAST_SKIP_BITS(re, s, n);
> CLOSE_READER(re, s);
> +#endif
> return tmp;
> }
The code under #ifdef CACHED_BITSTREAM_READER can probably be simplified
like this (analogous to show_bits()):
if (n > s->bits_left)
refill_32(s);
tmp = get_val(s, n);
This avoids UB and is simpler/faster. Or am I missing something here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff.h : remove unused function parameter "const AVCodecTag *tags" of "void ff_put_bmp_header()"
On 7/14/2017 12:12 PM, Александр Слободенюк wrote: > It was left by the history Probably OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_template: Fix undefined integer overflow in apply_tns()
Hi, On Fri, Jul 14, 2017 at 6:55 AM, Kieran Kunhya wrote: > On Thu, 13 Jul 2017 at 23:06 Michael Niedermayer > wrote: > > > On Wed, Jul 12, 2017 at 01:54:28PM +, Kieran Kunhya wrote: > > > > > > > > I actually would request a short note explaining the SUINTFLOAT type > > usage. > > > > Something like: > > > > +typedef unsignedSUINTFLOAT; // Equivalent to INTFLOAT, > > > > Used as temporal cast to avoid undefined sign overflow operations. > > > > > > > > Maybe add such note to all "signed value in unsigned type" typedefs. > > > > > > > > > > Needs to be in main documentation because nobody is going to understand > > > this in 50 years time when mailing lists have bitrotted. > > > > ill post a patch that adds this as a doxygen comment in the patch, > > that way it should be in the doxygen documentation > > > > if you meant it to be put some other place clarify where > > > I mean full documentation of the thought process behind all these changes > in doc/. > Just like James spent weeks trying to fix the undocumented IDCTs from 15 > years ago, someone will probably end up struggling to understand this SUINT > stuff in 20 years time. The IDCTs are still not documented by the way... :-). Part of that is hard because some changes are to reduce round-trip error which requires source+encoder access... Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add motion filter
On Thu, Jul 13, 2017 at 7:04 PM, Nicolas George wrote:
> Hi. Thanks for the patch. See comments below.
>
> Le quintidi 25 messidor, an CCXXV, Ashish Singh a écrit :
> > Hi, this is motion filter, one of the component filters of VMAF.
> > It takes two videos as input.
> > Run it using: ffmpeg -i main -i ref -lavfi motion -f null -
> > Currently it outputs the average motion score over all frames.
>
> This is the commit message, it is there to stay. You probably should
> have put these introductory comments between the triple-dash line and
> the start of the diff itself, below the histogram.
>
> >
> > ---
> > Changelog | 1 +
> > doc/filters.texi | 19 +++
> > libavfilter/Makefile | 2 +
> > libavfilter/allfilters.c | 1 +
>
> > libavfilter/convolution.c | 144 +
> > libavfilter/convolution.h | 29 +
> > libavfilter/motion.h | 29 +
>
> Does it really need to be in a separate file?
>
Hi, the convolution part will be used later by one more filter (vif) so I
thought it's a good idea to keep it in a separate file to avoid duplication
of code.
>
> > libavfilter/vf_motion.c | 316 ++
>
> > 8 files changed, 541 insertions(+)
> > create mode 100644 libavfilter/convolution.c
> > create mode 100644 libavfilter/convolution.h
> > create mode 100644 libavfilter/motion.h
> > create mode 100644 libavfilter/vf_motion.c
> >
> > diff --git a/Changelog b/Changelog
> > index 1778980..69657f4 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -10,6 +10,7 @@ version :
> > - config.log and other configuration files moved into ffbuild/ directory
> > - update cuvid/nvenc headers to Video Codec SDK 8.0.14
> > - afir audio filter
> > +- motion video filter
> >
> > version 3.3:
> > - CrystalHD decoder moved to new decode API
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 5985db6..011086b 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -9900,6 +9900,25 @@ Default method is @samp{fdiff}.
> > Scene change detection threshold. Default is @code{5.0}.
> > @end table
> >
>
> > +@section motion
>
> I find the name of the filter too unspecific.
>
> > +
> > +Obtain the average motion score between two input videos.
> > +
> > +This filter takes two input videos.
> > +
> > +Both input videos must have the same resolution and pixel format for
> > +this filter to work correctly. Also it assumes that both inputs
> > +have the same number of frames, which are compared one by one.
> > +
> > +The obtained average motion score is printed through the logging system.
> > +
> > +In the below example the input file @file{main.mpg} being processed is
> compared
> > +with the reference file @file{ref.mpg}.
> > +
> > +@example
> > +ffmpeg -i main.mpg -i ref.mpg -lavfi motion -f null -
> > +@end example
> > +
> > @section mpdecimate
> >
> > Drop frames that do not differ greatly from the previous frame in
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index f7dfe8a..446e367 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -13,6 +13,7 @@ OBJS = allfilters.o
> \
> > avfiltergraph.o
> \
> > buffersink.o
> \
> > buffersrc.o
> \
> > + convolution.o
> \
> > drawutils.o
> \
> > fifo.o
> \
> > formats.o
> \
> > @@ -227,6 +228,7 @@ OBJS-$(CONFIG_MESTIMATE_FILTER) +=
> vf_mestimate.o motion_estimation
> > OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o
> > OBJS-$(CONFIG_MIDEQUALIZER_FILTER) += vf_midequalizer.o
> framesync.o
> > OBJS-$(CONFIG_MINTERPOLATE_FILTER) += vf_minterpolate.o
> motion_estimation.o
> > +OBJS-$(CONFIG_MOTION_FILTER) += vf_motion.o dualinput.o
> framesync.o
> > OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
> > OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
> > OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> > index cd35ae4..7381799 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -239,6 +239,7 @@ static void register_all(void)
> > REGISTER_FILTER(METADATA, metadata, vf);
> > REGISTER_FILTER(MIDEQUALIZER, midequalizer, vf);
> > REGISTER_FILTER(MINTERPOLATE, minterpolate, vf);
> > +REGISTER_FILTER(MOTION, motion, vf);
> > REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
> > REGISTER_FILTER(NEGATE, negate, vf);
> > REGISTER_FILTER(NLMEANS,nlmeans,vf);
> > diff --git a/libavfilter/convolution.c b/libavfilter/convolution.c
> > new file mode 100644
> > index 000..5c4520d
> > --- /dev/null
> > +++ b/libavfilter/convolution.c
> > @@ -0,0 +1,144 @@
> > +/*
> > + * Copyright (c) 2017 Ronald S. Bultje
> > + * Copyright (c) 2017 Ashish Pratap Singh
>
[FFmpeg-devel] [PATCH] avformat/riff.h : remove unused function parameter "const AVCodecTag *tags" of "void ff_put_bmp_header()"
It was left by the history 0001-avformat-riff.h-remove-unused-function-parameter.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_template: Fix undefined integer overflow in apply_tns()
On Thu, 13 Jul 2017 at 23:06 Michael Niedermayer wrote: > On Wed, Jul 12, 2017 at 01:54:28PM +, Kieran Kunhya wrote: > > > > > > I actually would request a short note explaining the SUINTFLOAT type > usage. > > > Something like: > > > +typedef unsignedSUINTFLOAT; // Equivalent to INTFLOAT, > > > Used as temporal cast to avoid undefined sign overflow operations. > > > > > > Maybe add such note to all "signed value in unsigned type" typedefs. > > > > > > > Needs to be in main documentation because nobody is going to understand > > this in 50 years time when mailing lists have bitrotted. > > ill post a patch that adds this as a doxygen comment in the patch, > that way it should be in the doxygen documentation > > if you meant it to be put some other place clarify where I mean full documentation of the thought process behind all these changes in doc/. Just like James spent weeks trying to fix the undocumented IDCTs from 15 years ago, someone will probably end up struggling to understand this SUINT stuff in 20 years time. > -- > 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 What relevance do your political views have on this mailing list about FFmpeg? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff: remove useless tag correlation 'mpg2' --> AV_CODEC_ID_MPEG1VIDEO.
Also if you will write an mpeg1video , it will be created with tag 'mpg1',not'mpg2'inall cases (because correlation AV_CODEC_ID_MPEG1_VIDEO -- 'mpg1') stands before 'mpg2' tag in ff_codec_bmp_tags: ffmpeg -i whatever.mov -vcodec mpeg1video test.avi (output) ... (output) Stream #0:0: Video: mpeg1video (mpg1 / 0x3167706D), > This is actually a bug, that just doesn't affect anything. > First of all, the logic of functions that work with ff_codec_bmp_tags > is "One tag -- one codec id". > Also if you write this tag as MPEG2VIDEO, and then read the header > (all by ffmpeg), it will interpret as MPEG1VIDEO: > ffmpeg -i whatever.mxf -vcodec mpeg2video test.avi > && gdb ffprobe_g > (gdb) break avi_read_header > (gdb) r -i test.avi > (gdb) finish (gdb) p s->>streams[0]->codecpar->codec_id > $1 = AV_CODEC_ID_MPEG1VIDEO -- С уважением, Александр mailto:alexander.sloboden...@bramtech.ru ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
>That's great to hear. Is there a bug tracker for this? Please find the Bug ID 200328360 for above. > - 10 bit surface support - mapping GL surfaces as progressive frames instead of fields - getting rid of display preemption Will add these to feature request List and will take them up along with other tasks based on the priority Thanks, ManojGupta. -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of wm4 Sent: Friday, July 14, 2017 3:54 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default On Fri, 14 Jul 2017 09:55:58 + Manoj Bonda wrote: > Hi, > > Thanks i'll look into the issue and come up with an ETA ASAP. > Going on I will be the maintainer of VDPAU. Please direct any VDPAU issues to > me. That's great to hear. Is there a bug tracker for this? Other than fixing the bug that prompted my patch, on top of my wish list would be: - 10 bit surface support - mapping GL surfaces as progressive frames instead of fields - getting rid of display preemption ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
On Fri, 14 Jul 2017 09:55:58 + Manoj Bonda wrote: > Hi, > > Thanks i'll look into the issue and come up with an ETA ASAP. > Going on I will be the maintainer of VDPAU. Please direct any VDPAU issues to > me. That's great to hear. Is there a bug tracker for this? Other than fixing the bug that prompted my patch, on top of my wish list would be: - 10 bit surface support - mapping GL surfaces as progressive frames instead of fields - getting rid of display preemption ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/riff: remove useless tag correlation 'mpg2' --> AV_CODEC_ID_MPEG1VIDEO.
This is actually a bug, that just doesn't affect anything. First of all, the logic of functions that work with ff_codec_bmp_tags is "One tag -- one codec id". Also if you write this tag as MPEG2VIDEO, and then read the header (all by ffmpeg), it will interpret as MPEG1VIDEO: ffmpeg -i whatever.mxf -vcodec mpeg2video test.avi && gdb ffprobe_g (gdb) break avi_read_header (gdb) r -i test.avi (gdb) finish (gdb) p s->streams[0]->codecpar->codec_id $1 = AV_CODEC_ID_MPEG1VIDEO 0001-avformat-riff-remove-useless-tag-correlation-mpg2-AV.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
Hi, Thanks i'll look into the issue and come up with an ETA ASAP. Going on I will be the maintainer of VDPAU. Please direct any VDPAU issues to me. Thanks, ManojGupta. -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Philip Langdale Sent: Friday, July 14, 2017 3:04 PM To: FFmpeg development discussions and patches Cc: Yogender Gupta Subject: Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default On 2017-07-14 08:19, Yogender Gupta wrote: > Please help to understand what is broken with a command line, so that > we can address this issue. This is the issue that the hevc low level decoder outputs frames instead of fields - which all the other decoders do. Originally, the vdpau support didn't account for this at all - so it would take the memory allocated for the progressive frame and then treat it as two fields and return those two fields up (because vdpau assumes output frames are made up of two fields too) which lead to garbage output, as it would either return the top and bottom half in each 'field' if using the opengl interop, or it would interleave the two 'fields' when returning a frame using the read-back API or the vdpau mixer. I pointed this out to the vdpau maintainer (back when he still worked for nvidia) and he fixed the vdpau mixer case - but read-back and opengl remained broken. He then left nvidia and no work has happened ever since - that was almost two years ago. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
On 2017-07-14 08:19, Yogender Gupta wrote: Please help to understand what is broken with a command line, so that we can address this issue. This is the issue that the hevc low level decoder outputs frames instead of fields - which all the other decoders do. Originally, the vdpau support didn't account for this at all - so it would take the memory allocated for the progressive frame and then treat it as two fields and return those two fields up (because vdpau assumes output frames are made up of two fields too) which lead to garbage output, as it would either return the top and bottom half in each 'field' if using the opengl interop, or it would interleave the two 'fields' when returning a frame using the read-back API or the vdpau mixer. I pointed this out to the vdpau maintainer (back when he still worked for nvidia) and he fixed the vdpau mixer case - but read-back and opengl remained broken. He then left nvidia and no work has happened ever since - that was almost two years ago. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
On Fri, 14 Jul 2017 08:19:25 + Yogender Gupta wrote: > Please help to understand what is broken with a command line, so that we can > address this issue. With ffmpeg CLI, you can try something like: ffmpeg -hwaccel vdpau -i some_8bit_hevc_file.mkv -frames 10 -pix_fmt yuv420p out.y4m You will see quite obvious artifacts, that look like interlacing gone wrong. GL_NV_vdpau_interop has a similar bug. You can test that with e.g.: mpv --hwdec=vdpau some_8bit_hevc_file.mkv (other software which uses this extension to map VdpVideoSurface as GL textures should be affected too.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default
Please help to understand what is broken with a command line, so that we can
address this issue.
Thanks,
Yogender
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of wm4
Sent: Monday, July 03, 2017 4:29 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by
default
On Sat, 1 Jul 2017 07:10:47 -0700
Philip Langdale wrote:
> On Sat, 1 Jul 2017 11:40:38 +0200
> wm4 wrote:
>
> > NVIDIA broke its own API when using VDPAU decoding. If you retrieve
> > the decoded YUV data, or if you map the surfaces with GL interop,
> > the result are interlacing artifacts. The only way to get non-broken
> > data is by using the vdpau video mixer to convert it to RGB. There
> > is no way to block the non-working operations in a reasonable way (a
> > VdpVideoSurface has to support all operations).
> >
> > NVIDIA refuses to fix this issue (it "fixed" it by making it work
> > with the video mixer, but the rest is still broken). There is no
> > sign of that changing.
> >
> > Do not use HEVC by default with the generic hwaccle API. Detect
> > whether it's the NVIDIA native implementation, and exit with an
> > error. (The same thing work with the MESA implementation.)
> >
> > As an escape hatch and to allow applications to use the decoder if
> > they really want to (perhaps because they make sure to explicitly
> > use the video mixer), reuse AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH
> > to disable this check.
> >
> > Once NVIDIA fixes the bug, working driver versions could be
> > detected, and it could be allowed again.
> > ---
> > libavcodec/vdpau.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c index
> > 9c7804a287..42ebddbeee 100644
> > --- a/libavcodec/vdpau.c
> > +++ b/libavcodec/vdpau.c
> > @@ -127,6 +127,8 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
> > VdpDecoderProfile profile, VdpVideoSurfaceQueryCapabilities
> > *surface_query_caps; VdpDecoderQueryCapabilities *decoder_query_caps;
> > VdpDecoderCreate *create;
> > +VdpGetInformationString *info;
> > +const char *info_string;
> > void *func;
> > VdpStatus status;
> > VdpBool supported;
> > @@ -209,6 +211,23 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
> > VdpDecoderProfile profile, return AVERROR(ENOTSUP);
> >
> > status = vdctx->get_proc_address(vdctx->device,
> > +
> > VDP_FUNC_ID_GET_INFORMATION_STRING,
> > + &func);
> > +if (status != VDP_STATUS_OK)
> > +return vdpau_error(status);
> > +else
> > +info = func;
> > +
> > +status = info(&info_string);
> > +if (status != VDP_STATUS_OK)
> > +return vdpau_error(status);
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC && strncmp(info_string,
> > "NVIDIA ", 7) == 0 &&
> > +!(avctx->hwaccel_flags &
> > AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)) {
> > +av_log(avctx, AV_LOG_VERBOSE, "HEVC with NVIDIA VDPAU
> > drivers is buggy, skipping.\n");
> > +return AVERROR(ENOTSUP);
> > +}
> > +
> > +status = vdctx->get_proc_address(vdctx->device,
> >
> > VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
> > &func);
> > if (status != VDP_STATUS_OK)
>
> Go for it.
And pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add motion filter
On 13.07.2017 09:44, Ashish Singh wrote:
Hi, this is motion filter, one of the component filters of VMAF.
It takes two videos as input.
Run it using: ffmpeg -i main -i ref -lavfi motion -f null -
Currently it outputs the average motion score over all frames.
---
Changelog | 1 +
doc/filters.texi | 19 +++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/convolution.c | 144 +
libavfilter/convolution.h | 29 +
libavfilter/motion.h | 29 +
libavfilter/vf_motion.c | 316 ++
8 files changed, 541 insertions(+)
create mode 100644 libavfilter/convolution.c
create mode 100644 libavfilter/convolution.h
create mode 100644 libavfilter/motion.h
create mode 100644 libavfilter/vf_motion.c
diff --git a/Changelog b/Changelog
index 1778980..69657f4 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
- config.log and other configuration files moved into ffbuild/ directory
- update cuvid/nvenc headers to Video Codec SDK 8.0.14
- afir audio filter
+- motion video filter
Note: needs to be rebased onto current master by someone before it's
possible to integrate the patch (also for the ANSNR patch, forgot to
mention it there earlier).
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index 5985db6..011086b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9900,6 +9900,25 @@ Default method is @samp{fdiff}.
Scene change detection threshold. Default is @code{5.0}.
@end table
+@section motion
+
+Obtain the average motion score between two input videos.
+
+This filter takes two input videos.
+
+Both input videos must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The obtained average motion score is printed through the logging system.
+
+In the below example the input file @file{main.mpg} being processed is compared
+with the reference file @file{ref.mpg}.
+
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi motion -f null -
+@end example
+
@section mpdecimate
Drop frames that do not differ greatly from the previous frame in
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..446e367 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -13,6 +13,7 @@ OBJS = allfilters.o
\
avfiltergraph.o \
buffersink.o \
buffersrc.o \
+ convolution.o\
drawutils.o \
fifo.o \
formats.o\
@@ -227,6 +228,7 @@ OBJS-$(CONFIG_MESTIMATE_FILTER) +=
vf_mestimate.o motion_estimation
OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_MIDEQUALIZER_FILTER) += vf_midequalizer.o framesync.o
OBJS-$(CONFIG_MINTERPOLATE_FILTER) += vf_minterpolate.o
motion_estimation.o
+OBJS-$(CONFIG_MOTION_FILTER) += vf_motion.o dualinput.o
framesync.o
OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4..7381799 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -239,6 +239,7 @@ static void register_all(void)
REGISTER_FILTER(METADATA, metadata, vf);
REGISTER_FILTER(MIDEQUALIZER, midequalizer, vf);
REGISTER_FILTER(MINTERPOLATE, minterpolate, vf);
+REGISTER_FILTER(MOTION, motion, vf);
REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
REGISTER_FILTER(NEGATE, negate, vf);
REGISTER_FILTER(NLMEANS,nlmeans,vf);
diff --git a/libavfilter/convolution.c b/libavfilter/convolution.c
new file mode 100644
index 000..5c4520d
--- /dev/null
+++ b/libavfilter/convolution.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje
+ * Copyright (c) 2017 Ashish Pratap Singh
+ *
+ * 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
