[Ffmpeg-devel-irc] ffmpeg-devel.log.20170509

[burek]

[00:03:13 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:7f7ee86d5a49: avdevice/decklink: fix MSVC build issues
[00:52:17 CEST] <jkqxz> alevinsn:  Yes.
[00:53:35 CEST] <jkqxz> Do you prefer them in merge form or not?  I wasn't clear about the answer to that.  (And I don't mind at all.)
[00:54:25 CEST] <jkqxz> Or should I just apply tghem directly because we've wasted enough time back and forth on this...
[00:56:25 CEST] <jkqxz> Also, github links are kindof weird in commit messages.  There is an ffmpeg git server, and all decent client things (including gitweb) will expand hashes to links anyway.
[01:20:58 CEST] <jkqxz> Also your emails have the header twice, which does the wrong thing when applied by git (puts some of the header inside the commit messages).  If you send patches inline, don't include the header again.  (Or use git send-email, which does the Right Thing.)
[01:29:47 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:d3088e0fd874: avcodec/g723_1dec: Fix several integer related cases of undefined behaviour
[01:29:48 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:548459080b1b: avcodec/fic: Check coefficients
[01:29:49 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:159fb8ff7e40: avcodec/indeo2: Check for invalid VLCs
[01:29:50 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:28230a690e73: avcodec/clearvideo: Fix runtime error: signed integer overflow: 181 * 18050756 cannot be represented in type 'int'
[01:32:56 CEST] <nevcairiel> why are hevc profiles so annoying in the bitstream
[01:33:31 CEST] <nevcairiel> couldnt they just have added a proper profile enum  somewhere like h264 had .. no, everything beyond the basics is grouped into "rext" and you can manually figure out wtf is in the stream
[01:34:37 CEST] <nevcairiel> so if I want to know if a file is Main12 conformant, i get to read all sorts of shit
[01:38:26 CEST] <nevcairiel> (for extra fun, the values you are looking for are at the very end of the SPS)
[01:38:51 CEST] <jkqxz> It's not too bad.  You just need the lookup table for the 8 flags -> actual profile.  (Table A-2.)
[01:39:22 CEST] <nevcairiel> the really annoying part is that its hidden literally at the end of the sps
[01:39:25 CEST] <nevcairiel> its like, the last element
[01:39:34 CEST] <nevcairiel> so much crappy parsing code
[01:39:39 CEST] <nevcairiel> just to skip to there
[01:40:56 CEST] <jkqxz> Er, no?  Those are in PTL.  The flags at the end are other crazy stuff for the actual coding layer.
[01:42:00 CEST] <jkqxz> (And they are deliberately fixed-offset so you don't have to parse them properly...)
[01:43:02 CEST] <nevcairiel> the spec isnt exactly straight forward, but it does list table A.1 first with those crazy flags and their restrictions in w hat profiles
[01:43:59 CEST] <jkqxz> Those are additional restrictions rather than defining the profile, though.
[01:47:07 CEST] <jkqxz> If you aren't actually decoding, all reading them will do is allow you to do is possibly conclude that the stream is technically invalid.  How useful.
[01:48:32 CEST] <nevcairiel> i wonder if such a profile translation might be nice to have in the lavc decoder, instead of calling everything rext
[01:49:52 CEST] <jkqxz> Like how the constraint flags are applied on top of profile_idc for H.264 in lavc?  Yeah, that could be neat.
[01:55:40 CEST] <jamrial> isn't "rext" the name for a group of like 20+ profiles?
[01:55:57 CEST] <jamrial> libavcodec should probably report things like Main 12 instead of just "rext"
[01:56:13 CEST] <nevcairiel> yeah but figuring out the actual profile is a bit of work
[01:56:19 CEST] <nevcairiel> its not just a number in the bitstream
[02:00:02 CEST] <jkqxz> "general_profile_idc = get_bits(5); skip_bits(36); actual_profile = get_bits(8) << 5 | general_profile_idc;"  Done :P
[02:00:19 CEST] <nevcairiel> well thats some random number i guess =p
[02:00:31 CEST] <jkqxz> Just like H.264!
[02:00:40 CEST] <nevcairiel> although one of those numbers is variable
[02:00:45 CEST] <nevcairiel> should probably exclude it
[02:01:02 CEST] <nevcairiel> lower_bit_rate_constraint can be 0/1 for many profiles
[02:01:12 CEST] <jkqxz> Hence reading 8 bits, not 9.
[02:01:17 CEST] <nevcairiel> ah right
[02:02:29 CEST] <jamrial> trying any of the rext samples in hevc-conformance is an av_log fest of "unimplemented" and "not tested" warnings
[02:02:36 CEST] <nevcairiel> hehe
[02:02:50 CEST] <nevcairiel> well a simple main12 file should work fine
[02:03:20 CEST] <jamrial> it's curious how little development hevc has gotten since the last big openhevc contribution
[02:07:58 CEST] <nevcairiel> the openhevc thing mostly died as well, they had some hacky random branches with stupid features but nothing really happened
[02:10:41 CEST] <jamrial> yeah, kinda sucks :/
[02:12:03 CEST] <jamrial> although the general opinion i've seen a lot online is "lol software hevc"
[02:12:36 CEST] <nevcairiel> its kinda true
[02:12:50 CEST] <jamrial> with that argument nobody would have bothered with h264 back when even a 720p anime rip would bring any cpu to its knees
[02:12:54 CEST] <nevcairiel> real-time decoding of a 4k main10 stream requires a r ather high-end system
[02:13:16 CEST] <nevcairiel> and at this point, the majority of the speed is stuck in cabac
[02:25:31 CEST] <kierank> hopefully more people use high 422 hevc to troll hardware decoders
[03:43:48 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:dd8319767e16: qsvenc: Use MFXVideoENCODE_Query() to update the parameters
[03:43:49 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:ae5b67ee64be: qsvenc: Make sure the interlaced encoding works
[03:43:50 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:164e27732614: configure: Added require alternative for libmfx to support alternate installation options
[04:47:34 CEST] <philipl> BtbN: Do you understand what cuvidInit is for?
[04:48:39 CEST] <philipl> BtbN: changes look fine and work fine (and no 10bit vp9 for me). The capability check is undermined by the fact that we don't actually know the bit-depth at the time we run the check. It's only known reliably after the parser has done its work.
[06:25:46 CEST] <alevinsn> jkqxz:  sorry, I've been away
[06:26:06 CEST] <alevinsn> jkqxz:  and just got back--I'd say apply directly, since it isn't really being done as a merge
[06:26:25 CEST] <alevinsn> jkqxz:  thanks for letting me know about hashes and also the header business--I didn't know that
[06:27:12 CEST] <alevinsn> oops, looks like michaelni already applied those patches :-)
[08:31:18 CEST] <wm4> WTF
[08:31:44 CEST] <wm4> do I see an nvidia employee posting a patch adding new decls to our "free'd" compat nvenc header?
[08:32:03 CEST] <wm4> actually scratch that
[08:32:13 CEST] <wm4> the header was by nvidia and free-enough in the first place
[08:32:36 CEST] <wm4> probably confused it with the cuda/cuvid stuff
[09:41:00 CEST] <jkqxz> alevinsn:  Er, right.  Not sure why he would do that, but whatever, doesn't really matter.
[10:18:59 CEST] Action: ubitux confused at the io layers in ffmpeg
[10:46:10 CEST] <BtbN> philipl, that's why I probe and store all 3 of them.
[11:45:51 CEST] <michaelni> jkqxz, dont you think patches which were posted to the ML repeatly and said that they where reveiwed already, should be applied?
[11:47:57 CEST] <jkqxz> Not when they are still being discussed.
[11:48:51 CEST] <jkqxz> Though it was only quibbling over the commit message content.  The code is right so it doesn't really matter.
[11:48:53 CEST] <michaelni> i dont remember seeing a discussion
[11:49:30 CEST] <michaelni> greping for qsv i see nothing exept the patches since 3 weeks or so
[11:49:33 CEST] <jkqxz> See above.
[11:49:43 CEST] <michaelni> ahh ok
[11:50:11 CEST] <michaelni> sorry, i did not realize that the commit message was not as intended
[12:00:20 CEST] <BtbN> hm, how do I deprecated a parameter if its value is unchanged, only a new name for it?
[12:19:05 CEST] <nevcairiel> just support both forever
[12:19:05 CEST] <nevcairiel> :D
[12:19:30 CEST] <BtbN> that wouldn't be too terribly hard, as they just renamed them in the API as well
[12:19:35 CEST] <nevcairiel> or move the deprecated ones to a new value, warn on use, and then map to the old value
[12:19:51 CEST] <BtbN> The parameter is straight up using the values from nvEncodeApi.h
[12:19:53 CEST] <nevcairiel> if you really want to get rid of them
[12:19:57 CEST] <BtbN> and they just added defines for the old names
[12:20:01 CEST] <BtbN> so they have the exact same value
[12:20:32 CEST] <BtbN> One of the rc modes was deprecated without a replacement though
[12:20:36 CEST] <BtbN> no idea what to do with that
[12:20:40 CEST] <nevcairiel> that doesnt prevent you from inventing some fake value
[12:21:20 CEST] <BtbN> could just invent some IS_DEPRECATED flag and | them
[12:21:34 CEST] <nevcairiel> something like that, and strip that on use
[12:21:54 CEST] <nevcairiel> was the min-qp mode any useful? sounds like something low quality
[12:22:07 CEST] <BtbN> no idea, I never used it
[12:22:15 CEST] <BtbN> I'll just keep it around as long as the header offers it
[12:35:16 CEST] <durandal_1707> anybody please comment SIMD for afir filter
[12:46:43 CEST] <BtbN> Does anyone have a 12 bit sample of hevc or something cuvid supports?
[13:15:49 CEST] <nevcairiel> BtbN: https://www.dropbox.com/sh/wtmcgd5xzhwbp9r/AABALMuNausQng7T6LSqHhGHa?dl=0 the 420 12-bit works with cuvid
[14:13:37 CEST] <BtbN> philipl, I think I'm done with the SDK Update now.
[14:45:37 CEST] <j-b> so pushing again things to support without pkg-config?
[14:46:17 CEST] <j-b> even on Windows, pkg-config exists...
[14:48:30 CEST] <cone-714> ffmpeg 03Mark Thompson 07release/3.2:016064625fd5: hwcontext_vdpau: Fix missing subscripts
[14:48:52 CEST] <j-b> BtbN: did you retest the git speed?
[14:49:13 CEST] <BtbN> didn't have anything to push yet, will have soon though
[14:50:37 CEST] <j-b> BtbN: we have had a few 600Mbps requests on another server this morning
[14:51:01 CEST] <BtbN> weird... if that's some attempt to DDoS, it's quite a small one.
[14:51:12 CEST] <BtbN> Feels more like someone with a heavily misconfigured script
[15:33:22 CEST] <durandal_1707> jamrial: hi, please review simd in afir filter
[15:35:23 CEST] <jamrial> durandal_1707: nice, sse3 float instrunctions
[15:36:06 CEST] <durandal_1707> it colu
[15:36:17 CEST] <durandal_1707> it could use fma3?
[15:37:40 CEST] <jamrial> i think so, the mulps + addsubps can probably be replaced with a single vfmaddsub
[16:19:20 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:66be24262689: avfilter/vf_histogram: actually add parade display mode
[16:22:36 CEST] <philipl> BtbN: sure - but you don't actually used the saved caps results yet :-)
[16:29:56 CEST] <philipl> BtbN: Changes look good. ship it.
[17:07:44 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:3f5a68533dec: avcodec/flacdec: Return error code instead of 0 for failures
[17:07:45 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:ea627dc0949c: avcodec/snowdec: Remove unneeded {}
[17:07:46 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:78aa93807b3e: avcodec/snowdec: Check width
[18:13:47 CEST] <jamrial> durandal_1707: do you have a working example command line for the afir filter? using a fate sample or a source filter preferably
[18:15:32 CEST] <durandal_1707> jamrial: any audio as input for second input google for impulse response files or generate/record your own
[18:17:23 CEST] <jamrial> alright, but what comman line do i use to get it working? it keeps complaining about needing exactly one input and one output
[18:17:40 CEST] <durandal_1707> eg: using aevalsrc=between(n,0,0),atrim=end_sample=1024 as IR should give same audio
[18:18:35 CEST] <durandal_1707> ffmpeg -i input -i ir.wav -lavfi afir out.wav
[18:43:15 CEST] <BtbN> philipl, i do?
[18:43:27 CEST] <BtbN> in the sequence callback, to error out if the bit variant isn't supported
[18:47:10 CEST] <philipl> BtbN: I see it. When I tried it last night (as opposed to this morning), I got the failure to create decoder error. I guess you added it afterwards
[18:47:14 CEST] <philipl> Anyway. It's good to go
[19:00:56 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:78518b72cf03: compat/nvenc: bump nvEncodeAPI.h to Video Codec SDK 8.0.14
[19:00:57 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:23538ad2eb76: avcodec/nvenc: remove usage of deprecated fields
[19:00:58 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:17f63d98e679: compat/cuda: update cuvid/nvdec headers to Video Codec SDK 8.0.14
[19:00:59 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:f15129a44bcd: compat/cuda: fix cast warnings on windows
[19:01:00 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:fea471347218: avcodec/cuvid: use capability check instead of dummy decoder
[19:01:01 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:ef390e348eba: Changelog: document updated Video Codec SDK
[19:01:02 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:cfbebe9dda7d: avcodec/nvenc: deprecated old rc modes, add new ones
[19:07:22 CEST] <BtbN> philipl, I really wonder if cuvid can be used as a video filter now
[19:07:34 CEST] <BtbN> Can't find any proper documentation on that.
[19:07:37 CEST] <BtbN> Tempted to just try
[19:11:11 CEST] <BtbN> j-b, it was still taking a bit of time after "Update is fast-forward", but not several minutes.
[19:12:43 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:2f2bc2e24632: avcodec/webp: Check for VP8X after other VP8 chunks
[19:12:44 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:c4f63b78b71e: avcodec/webp: Factor update_canvas_size() out
[19:12:45 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:72810d20b74f: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[19:51:24 CEST] <durandal_1707> jamrial: so, what you tried?
[19:51:53 CEST] <alevinsn> j-b:  the libmfx patch that adds a require alternative doesn't have to do with the existence of pkg-config on Windows
[19:52:08 CEST] <alevinsn> j-b:  this was discussed on the ML
[19:52:11 CEST] <philipl> BtbN: yeah, that's definitely interesting.
[19:52:14 CEST] <alevinsn> j-b:  it is a special case
[19:52:34 CEST] <alevinsn> michaelni:  are you the maintainer of the ffmpeg tool?
[19:53:07 CEST] <alevinsn> assuming you are around
[19:54:31 CEST] <jamrial> durandal_1707: was trying to get fma3 asm working, but for an addsub as accumulator in fma3 there's no single instruction solution, so not sure if there will be any gain in performance
[19:56:17 CEST] <michaelni> alevinsn, i guess i am but there are several other people who probably  understand some parts here or there better i havnt worked much on ffmpeg.c recently
[19:57:32 CEST] <alevinsn> michaelni:  oh--well, I had submitted a patch to fix an interlaced video bug with ffmpeg and decoding some time ago, and I recently submitted a new version that allows it to pass fate on both Windows and Linux
[19:57:55 CEST] <alevinsn> is that code that you are familiar with, or would someone else be a better fit?
[20:01:35 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:62c5949beca2: avcodec/cllc: Check prefix
[20:01:36 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:f1a4dd5e4809: avcodec/scpr: Fix multiple runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
[20:04:31 CEST] <michaelni> alevinsn, where can i find the patch ? do you know some subject or so of the mail?
[20:14:48 CEST] <alevinsn> if you search for interlaced you can find it easily on the ML
[20:14:53 CEST] <alevinsn> I can get you the direct link to it though
[20:15:22 CEST] <alevinsn> Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video
[20:15:51 CEST] <alevinsn> I posted a better version last Friday
[20:16:05 CEST] <wm4> when will we have standards for commit messages
[20:16:42 CEST] <alevinsn> michaelni:  Also at https://patchwork.ffmpeg.org/patch/3574/
[20:16:50 CEST] <alevinsn> wm4:  with regard to what?
[20:20:54 CEST] <Compn> wm4 : or an easy way to fix commit messages... talk to git ?
[20:21:49 CEST] <durandal_1707> MNmpeg when??
[20:22:09 CEST] <durandal_1707> we are now CEmpeg afaik
[20:29:05 CEST] <nevcairiel> alevinsn: any commit message that says "fix bug" in any variant is usually not very good =p
[20:29:59 CEST] <alevinsn> nevcairiel:  you would prefer a trac record to correspond to it?
[20:30:05 CEST] <alevinsn> I never submitted one
[20:30:13 CEST] <nevcairiel> no, i would want a proper message :)
[20:30:21 CEST] <alevinsn> this one is complicated
[20:30:36 CEST] <alevinsn> to describe in sufficient detail in a short one-line
[20:30:50 CEST] <nevcairiel> one line doesnt have to describe it, just summarize it
[20:30:57 CEST] <nevcairiel> there is plenty space to describe it below that
[20:31:07 CEST] <alevinsn> here's the latest version of the one line btw
[20:31:25 CEST] <alevinsn> ffmpeg:  Fixed bug with decoding interlaced video
[20:31:30 CEST] <alevinsn> but I take it that isn't any better :-)
[20:31:52 CEST] <alevinsn> "ffmpeg:  Fixed issue with decoding interlaced video" -- is that better? :-P
[20:32:56 CEST] <alevinsn> I mean, in the latest version of the patch I submitted, the subject is;  "ffmpeg:  Fixed bug with decoding interlaced video"
[20:33:18 CEST] <alevinsn> I think that's a pretty good summary--it explains everything in more detail in the commit message
[20:35:14 CEST] <alevinsn> nevcairiel:  I'm not deliberately being obtuse, I just can't think of any way to describe it in one-line better than that
[20:55:31 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:49bbfb9d1393: avfilter: add arbitrary audio FIR filter
[20:56:45 CEST] <michaelni> alevinsn, review posted to ML
[20:59:47 CEST] <alevinsn> michaelni:  thanks
[20:59:57 CEST] <alevinsn> what do you mean by:  "It should be cleaner to not call check_init_output_file() from
[20:59:57 CEST] <alevinsn> init_output_stream() which avoids the new argument."
[21:02:25 CEST] <michaelni> i mean the function call could be done by the caller after the function where needed instead of passing an argument into the function to skip it
[21:03:59 CEST] <nevcairiel> alevinsn: as a general rule the top line should describe what the patch does, not what it fixes
[21:04:55 CEST] <alevinsn> nevcairiel:  I'll have to think about how to summarize that in one line.  Its not so easy in this case
[21:05:51 CEST] <alevinsn> michaelni:  true, but then I would have to modify the two other places that call init_output_stream()
[21:06:42 CEST] <alevinsn> which I already did anyway, but would have to modify even further--is that your preference?
[21:07:23 CEST] <michaelni> the seperation of that call can be done in a "cosmetic" patch prior to the rest, i think the patches would be clearer that way
[21:08:11 CEST] <alevinsn> michaelni:  that makes sense.  So a cosmetic patch that has nothing to do with the bug fix, and then the bug fix patch to follow
[21:08:28 CEST] <michaelni> yes
[21:10:10 CEST] <alevinsn> ok, will do, thanks for reviewing the patch
[21:10:38 CEST] <michaelni> np
[21:10:39 CEST] <alevinsn> michaelni:  do you think it would be useful to have a FATE test for this?  I think so
[21:10:47 CEST] <michaelni> i think so too
[21:11:16 CEST] <alevinsn> I may need some help on IRC for uploading to the rsync repository, but I'll tackle that afterwards
[22:07:57 CEST] <wbs> alevinsn: have you actually encountered real HLS streams with tags continued on the next line with backslashes?
[22:08:14 CEST] <alevinsn> no--I'm just referring to the specification
[22:08:20 CEST] <wbs> alevinsn: you're reading it wrong then
[22:08:29 CEST] <wbs> alevinsn: nothing in the spec actually describes how this works
[22:08:33 CEST] <wbs> alevinsn: it's only in one example
[22:08:51 CEST] <wbs> alevinsn: and there it is only because you're not allowed to have too long lines in an RFC
[22:08:51 CEST] <alevinsn> " A '\' is used to indicate that the tag continues on the following
[22:08:51 CEST] <alevinsn>    line with whitespace removed:
[22:08:51 CEST] <alevinsn> "
[22:08:54 CEST] <wbs> yes
[22:09:11 CEST] <wbs> the literal string written in the .m3u8 does not have the backslash, it's only for readability in the RFC
[22:09:40 CEST] <wbs> if you actually try to make such a .m3u8 and play it with apple tools, which would be the official reference implementation, you'll see that it doesn't actually work
[22:10:01 CEST] <alevinsn> I see
[22:10:27 CEST] <alevinsn> and, I guess it can be interpreted as such at https://developer.apple.com/library/content/technotes/tn2288/_index.html as well
[22:10:44 CEST] <alevinsn> well, why don't you chime in then :-)
[22:11:07 CEST] <wbs> no, I've done enough here already
[22:11:17 CEST] <wbs> if you want to add code for something that doesn't actually exist, I won't stop you
[22:11:32 CEST] <alevinsn> I wasn't doing this
[22:11:40 CEST] <alevinsn> I suggested it in a review to Steven Liu
[22:11:53 CEST] <alevinsn> and he interpreted it the same way (although, English isn't his first language)
[22:11:58 CEST] <alevinsn> and he wrote the patch
[22:12:11 CEST] <wbs> and neither of you chose to actually test if any official hls player supports it?
[22:12:31 CEST] <alevinsn> I merely provided a review--he was the one working on this
[22:13:03 CEST] <alevinsn> and that was only one small aspect to my initial review
[22:13:14 CEST] <alevinsn> the funny thing is
[22:13:25 CEST] <alevinsn> why would Apple put the '\'
[22:13:30 CEST] <alevinsn> in a non-RFC Web page
[22:13:33 CEST] <alevinsn> at https://developer.apple.com/library/content/technotes/tn2288/_index.html
[22:13:46 CEST] <alevinsn> that doesn't make sense, if the only purpose was to do that for RFC purposes
[22:14:58 CEST] <alevinsn> there is plenty of room to put the entire tag specification on one line
[22:15:06 CEST] <nevcairiel> the comment there does seem like its only a note for the example, and not something thats supposed to be a standard
[22:15:14 CEST] <nevcairiel> and who knows what kind of display sizes they design it for
[22:15:58 CEST] <wbs> yes, and like, when you read the literal spec with grammars and whatnot, there's no reference to it anywhere, except for in that example
[22:16:19 CEST] <alevinsn> it is a bit ambiguous, but if it doesn't work with the official player, then there is no point to having it in ffmpeg
[22:20:19 CEST] <alevinsn> ok, I'll respond to me review
[22:35:43 CEST] <alevinsn> wbs:  thanks for the correction
[23:30:53 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:65b710910534: Changelog: mention afir addition
[00:00:00 CEST] --- Wed May 10 2017