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

[burek]

[00:00:42 CEST] <TheRyuu> whenever someone has the time can I get some feedback on the patches I sent to the ML? (re: configure+mingw-w64)
[00:10:08 CEST] <durandal_1707> why I didn't got error with clang?
[00:21:53 CEST] <J_Darnley> Aww...  there is no solution to correct the tags for this CD in one go.
[00:22:10 CEST] <J_Darnley> I guess I will have to resort to some copy-paste
[00:28:58 CEST] <nemo> Say, is CABAC usable as a generic arithmetic compressor?
[00:29:42 CEST] <nemo> was reading the code and it is not exactly commented and a little scary and with a lot of magic numbers
[00:30:06 CEST] <nemo> but, maybe that's normal for ffmpeg, haven't ever looked at the source before!
[00:30:58 CEST] <nemo> well apart from comments like:         flush_put_bits(&c->pb); //FIXME FIXME FIXME XXX wrong
[00:31:22 CEST] <nemo> which is not exactly illuminating :
[00:40:12 CEST] <nemo> eh. I should probably find something simpler to learn from
[00:41:57 CEST] <nemo> this one for example http://marknelson.us/1991/02/01/arithmetic-coding-statistical-modeling-data-compression/
[01:44:18 CEST] <cone-071> ffmpeg 03Alex Smith 07master:91b668acd6de: configure: Force mingw's ld to keep the reloc section
[02:01:40 CEST] <TheRyuu> one down, two to go
[07:32:56 CEST] <cone-398> ffmpeg 03Claudio Freire 07master:b01f3ddad31a: AAC encoder: simplify and speed up find_min_book
[07:32:56 CEST] <cone-398> ffmpeg 03Claudio Freire 07master:7ec74ae4aaf5: AAC encoder: tweak rate-distortion logic
[08:57:31 CEST] <j-b> 'morning
[09:52:25 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:43f0b1d38c1c: avfilter/af_rubberband: rename duplicate option name
[09:52:26 CEST] <cone-398> ffmpeg 03Paul B Mahol 07master:69e6ed2174bb: doc/filters.texi: add rubberband documentation
[11:41:34 CEST] <durandal_1707> which decoders need fuzzing?
[11:41:55 CEST] <ubitux> try subtitles decoders
[11:42:03 CEST] <ubitux> it's text and thus easily craftable/exploitable
[11:46:53 CEST] <kurosu> is "j00ru" or whoever still fuzzing?
[11:47:20 CEST] <kurosu> whatever the answer, it would be nice to have a list of file formats and codecs that weren't fuzzed
[11:47:58 CEST] <nevcairiel> if you really want something to fuzz, pick one of the things which are relatively new
[11:49:55 CEST] <Compn> durandal_1707 : j-b mentioned flv decoder 
[11:50:20 CEST] <Compn> i'm not sure if he mentioned it as having fuzz problems or decoding problems though, only that he said it was crap
[11:50:32 CEST] <Compn> (very helpful comments from j-b and videolan instead of just giving us samples)
[11:58:18 CEST] <durandal_1707> ubitux: what was name of fuzzer you mentioned?
[11:58:29 CEST] <ubitux> afl
[11:58:36 CEST] <ubitux> american fuzzing loop or sth like this
[11:58:38 CEST] <durandal_1707> Thx
[11:58:40 CEST] <j-b> Compn: I'm quire sure that's not what I said
[11:58:51 CEST] <ubitux> durandal_1707: http://lcamtuf.coredump.cx/afl/
[12:01:49 CEST] <ubitux> yeah, it was about the demuxer
[12:01:52 CEST] <ubitux> :D
[12:07:24 CEST] <kierank> durandal_1707: https://github.com/rillian/afl-ffmpeg-opus
[12:49:06 CEST] <Compn> j-b : apologies if misquoted.
[12:49:30 CEST] <Compn> still, fuzz testing flv decoder cannot hurt.
[13:05:41 CEST] <cone-989> ffmpeg 03zylthinking 07master:d1bbefeaa76c: avcodec/libstagefright: fix Stagefright_decode_frame() failing to exit when the source is done
[13:05:41 CEST] <cone-989> ffmpeg 03Michael Niedermayer 07master:0c7ceb1e0acc: avcodec/aacenctab: Make aac_maxval_cb const
[14:24:47 CEST] <mateo`> hello o/
[14:26:14 CEST] <j-b> ping * reimbursements
[14:26:58 CEST] <Compn> ugh
[14:27:04 CEST] <Compn> i have ticket with no price on it anywhere
[14:27:10 CEST] <Compn> reservations, no price
[14:27:13 CEST] <Compn> confirmation, no price
[14:27:22 CEST] <Compn> my ticket is the same price as last year and 2013 :P
[14:27:43 CEST] <nevcairiel> should've demanded an invoice when you bought it
[14:27:51 CEST] <mateo`> is there a filter that performs transformations on the avframe->buffer depending on the linesize if linesize < 0 (i'm thinking of what vf_vflip is doing) so external application does not have to deal with negative linesizes and offsetting frame->data
[14:27:54 CEST] <j-b> Compn: that's impossible
[14:27:58 CEST] <Compn> i will find documentation...
[14:28:30 CEST] <wm4> mateo`: maybe vf_copy? but dealing with negative linesizes is easy
[14:30:43 CEST] <mateo`> wm4: but you have to add an extra copy on the application side if you want to, for example, use the resulting buffer with glTexImage2D.
[14:30:47 CEST] <Daemon404> im pretty sure by law they have to show the price
[14:30:51 CEST] <mateo`> wm4: i'll try with vf_copy though :) thanks
[14:31:56 CEST] <wm4> mateo`: just reverse the flipping before uploading it to the texture, and then flip the texture coordinates
[14:31:59 CEST] <Compn> nevcairiel : thats the point, family bought tickets in package deal. then i drove them around france for 2 weeks in a minivan :P
[14:36:14 CEST] <mateo`> wm4: the goal is to get rid of the flip and for now  i don't have control over the texture coordinates :\
[14:38:10 CEST] <wm4> how come?
[14:42:21 CEST] <mateo`> well, too much depending on how the textures are fed to the gl pipeline (using the copy filter is temporary solution)
[14:42:46 CEST] <durandal_1707> Why vlc doesn't contribute code to ffmpeg lavf?
[14:43:20 CEST] <Compn> why vlc doesnt even use lavf...
[14:43:35 CEST] <Daemon404> why would they
[14:43:40 CEST] <wm4> because lavf is terrible
[14:43:44 CEST] <Compn> code duplication?
[14:43:48 CEST] <Daemon404> oh
[14:43:50 CEST] <Daemon404> which lavf
[14:43:54 CEST] <Daemon404> i thought you meant lavfi
[14:43:58 CEST] <nevcairiel> writing your own demuxer is also terrible
[14:44:06 CEST] <Compn> lavformat but also lavfi while we are talking about it :P
[14:44:12 CEST] <Daemon404> only if it's based on libmatroska and libebml
[14:45:19 CEST] <Compn> maybe durandal_1707 is talking about lavfi /
[14:45:24 CEST] <Compn> i dunno now...
[14:45:48 CEST] <nevcairiel> if someone says lavf, i always assume they mean avformat, because lavfi is lavfi :p
[14:46:04 CEST] <Daemon404> and lav means your dshow filters
[14:46:09 CEST] <Daemon404> and la means LA audio
[14:46:10 CEST] <nevcairiel> of course
[14:46:10 CEST] <durandal_1707> exactly
[14:47:17 CEST] <nevcairiel> I haven't had that bad of a time with lavf myself though, hacked it up here and there, but nothing too terrible
[14:47:30 CEST] <nevcairiel> only replaced the mkv demuxer because I wanted more features
[14:48:39 CEST] <nevcairiel> in related news, I had to change surprisingly little after the bumps in my code, I would've figured I would run into more
[14:49:01 CEST] <nevcairiel> just some warnings about 64-bit bitrate was most of it =p
[14:56:08 CEST] <wm4> the only thing I had to change were the pixdesc deprecations
[15:04:38 CEST] <durandal_1707> is today something special?
[15:05:25 CEST] <Daemon404> ?
[15:06:08 CEST] <durandal_1707> YouTube is full of bs
[15:06:26 CEST] <Daemon404> where?
[15:06:28 CEST] <Daemon404> looks normal to me
[15:07:55 CEST] <ubitux> http://ubitux.fr/pub/pics/_youtube-recommended.png
[15:07:58 CEST] <ubitux> looks normal to me too
[15:08:00 CEST] <ubitux> :(
[15:08:04 CEST] <Daemon404> oh wow proper chrome position support
[15:08:07 CEST] <Daemon404> chroma*
[15:09:07 CEST] <Daemon404> oh a fix.
[15:09:51 CEST] <JEEB> le wow
[15:12:51 CEST] <Daemon404> i misread; it's a regression fix
[15:13:58 CEST] <durandal_1707> will tell z.img dev to rename lib to avscale
[15:14:14 CEST] <Daemon404> rofl
[15:15:18 CEST] <durandal_1707> just need to add 4th plane and bit formats
[15:15:30 CEST] <JEEB> :D
[15:15:40 CEST] <durandal_1707> and packed support
[15:15:53 CEST] <Daemon404> you can use the lower level api to handle planes separately
[15:15:56 CEST] <Daemon404> but it's not fun at all
[15:16:28 CEST] <durandal_1707> then just add api for AVframe
[15:17:07 CEST] <durandal_1707> but no yasm... :(
[15:17:27 CEST] <Daemon404> it's intrins
[15:18:14 CEST] Action: ubitux waiting for benchmarks
[15:21:21 CEST] <durandal_1707> ubitux: they are on doom9
[15:21:29 CEST] <ubitux> url?
[15:21:57 CEST] <durandal_1707> But I think they compiled sws without yasm
[15:22:55 CEST] <Daemon404> they didnt
[15:23:02 CEST] <Daemon404> sws really is slow.
[15:23:05 CEST] <Compn> lol @ ubitux video recommendations
[15:23:46 CEST] <durandal_1707> then why zimg is so slow here up to 5 times
[15:24:20 CEST] <durandal_1707> ubitux: search for fmtconv zimg swscale
[15:24:55 CEST] <Daemon404> durandal_1707, because, as you have been told several times, *SIMD is temporariyl disabled* during the api refactor
[15:25:43 CEST] <durandal_1707> even if I compile with flag?
[15:25:53 CEST] <Daemon404> yes.
[15:26:12 CEST] <Daemon404> it's hard disabled because it needs to be fixed up for the new changes
[15:28:48 CEST] <durandal_1707> then I will need to checkout old version
[15:28:56 CEST] <Daemon404> the old version doesnt have zimg3.h
[15:29:13 CEST] <Daemon404> thats the point. the simd was disabled to write the zimg3 api.
[15:29:13 CEST] <durandal_1707> :(
[15:29:47 CEST] <durandal_1707> I can't wait
[15:30:11 CEST] <J_Darnley> fg
[15:30:18 CEST] <J_Darnley> wrong window
[15:33:03 CEST] <durandal_1707> you need to kill irc client if it is distracting you
[15:33:38 CEST] <Daemon404> alternatively, kill everyone on irc
[15:33:40 CEST] <J_Darnley> I should maximise Winamp over it, certainly
[15:33:41 CEST] <Daemon404> works just as well
[15:44:09 CEST] <durandal_1707> winamp is dead
[15:44:23 CEST] <Daemon404> and yet it's still better than the alternatives for me
[15:44:36 CEST] <fritsch> dead are only thing that are not talked about ...
[15:44:52 CEST] <wm4> ok so elvis is alive
[15:45:04 CEST] <fritsch> obviously
[15:45:23 CEST] <fritsch> have fun reading the valis trilogy :-)
[15:45:58 CEST] <J_Darnley> If Elvis (read: Winamp) is still performing then he (it) isn't dead!
[15:47:03 CEST] <fritsch> same about the schrödinger's cat :-)
[15:48:04 CEST] <Daemon404> most other music player seem to take the "xbox hueg itunes-style gui' route
[15:48:26 CEST] <wm4> but there are thousands of winamp clones
[15:48:57 CEST] <Daemon404> ones more maintained than winamp itself?
[15:48:59 CEST] <Daemon404> that actually work?
[15:49:27 CEST] <J_Darnley> At some point I am going to end up writing my own Winamp clone.
[15:49:28 CEST] <wm4> no idea, personally I'm using xmms, a shitty old unmaintained winamp clone for linux
[15:49:37 CEST] <fritsch> hehe
[15:49:38 CEST] <Daemon404> as in the gtk1 xmms?
[15:49:43 CEST] <fritsch> you can even use the winamp skins for it
[15:49:46 CEST] <fritsch> (the old ones)
[15:50:03 CEST] <fritsch> mpd + mpv also works quite nicely
[15:50:31 CEST] <nevcairiel> on windows i just use foobar, i never really found a simple music player that I liked on linux
[15:50:52 CEST] <atomnuker> I use quodlibet, it's pretty good for something written in python
[15:51:07 CEST] <fritsch> nevcairiel: yeah most are really fat ...
[15:51:13 CEST] <fritsch> others even have mono dependencies
[15:51:16 CEST] <nevcairiel> quodlibet is the one i stuck with in the end
[15:51:23 CEST] <Daemon404> nevcairiel, i know people using fb2k on linxu
[15:51:24 CEST] <Daemon404> su
[15:51:26 CEST] <wm4> Daemon404: yes that one
[15:51:26 CEST] <Daemon404> so*
[15:51:30 CEST] <nevcairiel> Daemon404: in wine or what
[15:51:33 CEST] <Daemon404> wine yes
[15:51:33 CEST] <wm4> does quodlibet use gstreamer?
[15:51:35 CEST] <Daemon404> because it is still better
[15:51:50 CEST] <fritsch> wm4: yes
[16:43:02 CEST] <durandal_1707> Compn: FLV is not codec
[16:56:07 CEST] <iive> flv1 is
[17:12:44 CEST] <BtbN> I think i'll try to add OpenCL support to that chromakey filter. Beeing able to use it in realtime would be nice, and it's something a GPU should be very good at.
[17:13:34 CEST] <BtbN> Does anybody here have any objections against pushing it? Nobody complained on the ML so far.
[17:16:59 CEST] <durandal_1707> nobody cares for lavfi
[17:19:02 CEST] <kierank> I care for lavfi
[17:20:08 CEST] <BtbN> And... https://bpaste.net/show/024ffa886cc4 what the hell is this? oO
[17:20:20 CEST] <nevcairiel> you still getting that?
[17:20:22 CEST] <BtbN> yes
[17:20:37 CEST] <BtbN> And ffplay works great with that "error" present
[17:20:43 CEST] <BtbN> It makes no sense at all
[17:21:23 CEST] <BtbN> Maybe it's not an actual error because the __APPLE__ check is false?
[17:21:30 CEST] <BtbN> So the problematic "code" is never "run"?
[17:21:31 CEST] <wm4> maybe some broken expansion in the SDL_VERSION macro
[17:21:32 CEST] <nevcairiel> but it still yells
[17:21:48 CEST] <nevcairiel> i usually dont build with SDL, so i couldnt say
[17:22:41 CEST] <BtbN> I have it installed, so a plain configure enables it
[17:29:48 CEST] <durandal_1707> there should be list of things somebody fuzzed
[18:04:36 CEST] <durandal_1707> my first hang with afl
[18:11:18 CEST] <cone-989> ffmpeg 03Timo Rothenpieler 07master:4af1f37682a7: avfilter/vf_chromakey: Add chromakey video filter
[18:25:38 CEST] <Compn> durandal_1707 : yes, but most codec in flv is flv1. no one uses vp6 anymore (hopefully) . sorry i was not clear on asking you to fuzz test the flv1 decoder.
[18:30:18 CEST] <durandal_1707> michaelni: did you got FLV files?
[18:37:25 CEST] <BtbN> Is the OpenCL stuff documented somewhere? Or it is just "read the two filters that use it"?
[18:40:56 CEST] <michaelni> durandal_1707, if what you search isnt on samples.ffmpeg.org then i probably dont have it either
[18:48:11 CEST] <saste> BtBn: probably the libavutil/opencl.h header can be useful, if you're already familiar with opencl stuff
[18:48:31 CEST] <saste> BtbN, but yes, that and read the source
[18:49:17 CEST] <BtbN> The two filters are quite complex. I'd guess it would be much simpler to setup for color/chromakey
[19:06:34 CEST] <kurosu> vp6 is clearly not bitexact, but anime & porn fans are probably the only ones left caring
[19:07:11 CEST] <kurosu> it has to do with MC on edges iirc
[19:07:26 CEST] <j-b> vp6i ?
[19:07:28 CEST] <j-b> :D
[19:08:43 CEST] <kurosu> err, I don't know the variants though - I only remember difference in inloop filtering and related syntax between them
[19:08:57 CEST] <kurosu> vp6f or something?
[19:19:30 CEST] <Compn> Balliad nickname always makes me think of bellard :P
[19:20:31 CEST] <cone-989> ffmpeg 03Paul B Mahol 07master:3441fef0f8bf: avformat/brstm: fix overflow
[19:20:45 CEST] <Compn> there is vp6f for vp6 in flash (which is flipped for some reason), vp6a for vp6 alpha .... maybe a few more. vp6 in nsv but basically its all the same stupid vp6
[19:21:09 CEST] <Compn> and vp60 / vp61 / vp62 and maybe vp63? for vp6 in avi.
[19:23:58 CEST] <kurosu> I'm probably thinking of vp60 vs vp62 - never seen vp63
[19:25:41 CEST] <Compn> ok, yeah i may have made up vp63 in my head, its been a while since i've seen any vp6 :)
[19:31:37 CEST] <Daemon404> i dont recall anime being put out in vp6.
[19:31:45 CEST] <JEEB> yeah
[19:32:03 CEST] <JEEB> it was either mpeg-4 part 2 or AVC depending on the group or age
[19:32:12 CEST] <JEEB> unless it was pre-AVC flash VoD
[19:32:34 CEST] <Compn> i recall anime in vp6 , streaming in nsv on winamp nullsoft tv years ago, but thats about it
[19:32:42 CEST] <Compn> oh, maybe crunchyroll was using vp6 too ?
[19:32:46 CEST] <J_Darnley> I think the someone loved real media formats
[19:33:05 CEST] <J_Darnley> I think someone loved the real media formats
[19:33:05 CEST] <Daemon404> J_Darnley, yes, china.
[19:33:10 CEST] <J_Darnley> ah
[19:33:27 CEST] <Compn> china loves rm or "rmvb" as they call it for some reason i have no clue why
[19:33:51 CEST] <Compn> https://en.wikipedia.org/wiki/RMVB
[19:34:01 CEST] <kurosu> I think several tickets on vp6 are anime stuff
[19:34:14 CEST] <Daemon404> certainly not from the usual suspects then (fansubbers)
[19:34:24 CEST] <Daemon404> wonder who
[19:35:41 CEST] <kurosu> probably when xvid was popular but when avc or rv9 hadn't yet emerged, that land before time
[19:36:08 CEST] <Daemon404> i was a fansubber during that time ;)
[19:36:14 CEST] <Daemon404> no realmedia there
[19:36:26 CEST] <Daemon404> er vp6
[19:36:32 CEST] <Daemon404> fffs, im getting muddled now
[19:36:38 CEST] <kurosu> there was before your time, before xvid
[19:36:45 CEST] <kurosu> people loved their 50MB episode
[19:36:52 CEST] <kurosu> oh
[19:36:53 CEST] <kurosu> ok
[19:37:03 CEST] <Daemon404> vcd era :D
[19:37:52 CEST] <kurosu> and asf too :)
[19:38:34 CEST] <kurosu> vivo also
[19:38:52 CEST] <Daemon404> never even seen a vivo file
[19:41:01 CEST] <kurosu> what do they do nowadays? hi10p or have they moved to vp9/hevc/... ?
[19:41:20 CEST] <JEEB> there is almost no real fansubbing any more
[19:41:29 CEST] <Daemon404> what little there is, is hi10p
[19:41:40 CEST] <kurosu> ok
[19:41:54 CEST] <JEEB> random rips in HEVC do surface, but most often not used for real reasons
[19:42:08 CEST] <jamrial> i remember some anime in ogm a decade ago
[19:42:17 CEST] <kurosu> I think some of the hevc samples I've came around were hindi rips, whatever the reason
[19:42:19 CEST] <JEEB> yeah, that was mpeg-4 part 2 or so
[19:42:34 CEST] <JEEB> kurosu: yeah it seems like some of the indian "scene" started using x265 right away
[19:42:41 CEST] <JEEB> like when it sucked gigantic dongs
[19:43:03 CEST] <JEEB> and probably was much more slow to use
[19:43:55 CEST] <jamrial> the english fansubber scene instead jumped straight into h264 high10 right away
[19:44:23 CEST] <JEEB> yes, except it was already relatively quick and technically superior to 8bit
[19:44:25 CEST] <jamrial> i still remember the shitstorm from smartphone users, who could watch the stuff
[19:44:36 CEST] <philipl> I must maximise the quality of this bit-rate starved tv rip!
[19:44:49 CEST] <jamrial> *couldn't
[19:45:23 CEST] <JEEB> although for a long time there was no real decoder for most folk. that only happened almost a year after x264 got 10bit support
[19:45:37 CEST] <jamrial> i think ogm was used for a while with dual audio releases, before mkv became a thing
[19:45:42 CEST] <philipl> yeah.
[19:45:48 CEST] <JEEB> + there were all those funky bit depth conversion issues too
[19:45:56 CEST] <philipl> Speaking of 'quality', I saw a bluray rip go by that was larger than the original.
[19:46:07 CEST] <JEEB> since >8bit YCbCr was a "new thing" at that point
[19:46:27 CEST] <JEEB> with vapoursynth and fmtconv/zimg that seems like such a distant past :P
[20:04:50 CEST] <BBB> Gramner: you really expect any of us to review that patch?
[20:04:55 CEST] <BBB> Gramner: I dont even know what to do
[20:07:35 CEST] <Gramner> BBB: hah, I sould say the same for your itxfm checkasm patch. do I really need to read two research papers to understand a unit test? ;)
[20:07:55 CEST] <BBB> they document the fwd txfm for the adsts
[20:08:08 CEST] <BBB> I could put an actual butterfly fwd txfm there, but itd be 1000s of lines of code
[20:08:49 CEST] <BBB> do you know which function to use as fwd dst?
[20:09:03 CEST] <BBB> (I googled it, and got to these papers, and they turned out to be correct)
[20:12:50 CEST] <Gramner> no idea. not sure if I like the use of floating-point transforms for testing integer code though, but I'm not going to complain about it since I don't have any better way of doing it
[20:48:21 CEST] <BBB> Gramner: well, dont forget, Im not testing the precision of the idct in the academic sense
[20:48:48 CEST] <BBB> Gramner: Im just trying to use minimal code to get a sensible set of output input coefs for the idct
[20:48:53 CEST] <BBB> Gramner: and this was minimal code :D
[21:01:48 CEST] <durandal_1707> j-b: do you have flv that cause crash?
[22:22:46 CEST] <BtbN> That was easier than I expected. opencl chromakey seems to work.
[22:23:01 CEST] <BtbN> It only utilizes 40% of my GPU though
[22:23:17 CEST] <BtbN> no idea if that's limited by other parts, or a problem with my kernel
[22:35:27 CEST] <BtbN> If anyone has any idea about that OpenCL stuff, i'd apreciate some feedback: https://github.com/BtbN/FFmpeg/commit/f9f883a6291eea95d6f32550c1de3dc29d787c2f
[22:36:31 CEST] <BBB> BtbN: I have no knowledge of opencl at all :(
[22:38:02 CEST] <BBB> the kernel code seems reasonable (Ive written some opengl shaders before, so I understand that much, it looks similar'ish)
[22:39:22 CEST] <BtbN> It boosts it, for a 720p video, from 16 fps on the CPU, to 86 fps on the GPU.
[22:39:27 CEST] <BtbN> On my machine
[22:39:45 CEST] <BtbN> And I can't spot a visual difference.
[22:44:20 CEST] <Compn> BtbN : you cant say that opencl act ually works for anything ?
[22:44:30 CEST] <Compn> i heard so many devels at vdd say it was worthless! :P
[22:44:33 CEST] <Compn> nice work though :)
[22:45:31 CEST] <BtbN> It's definitely usefull for the color/chromakey filters. I don't think it's possible to do that in realtime on a CPU, unless someone writes super optimized assembly for it.
[22:46:36 CEST] <BtbN> Compn, not sure if I understand your sentence correctly, but that sounds like it's refering to the OpenCL stuff in x264?
[22:46:58 CEST] <BtbN> Which isn't exactly too usefull.
[22:48:05 CEST] <Compn> ah no idea
[22:48:31 CEST] <BtbN> The problem with OpenCL in ffmpeg is that it's only implemented for two filter so far, which are rarely used.
[23:28:19 CEST] <durandal_1707> If I setup opencl I will write more ...
[23:32:38 CEST] <j-b> durandal_1707: crashes, not that I remind of.
[23:43:34 CEST] <cone-989> ffmpeg 03Christophe Gisquet 07master:552faecf4b1c: vf_scale: conditionally override chroma position
[23:45:10 CEST] <j-b> BBB: pingu
[23:48:18 CEST] <BBB> j-b: pong
[00:00:00 CEST] --- Thu Sep 24 2015