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

[burek]

[00:05] <Compn> does zygo q10 deserve changelog update?
[00:12] <Compn> i guess its not big deal...
[00:28] <saste> ubitux, how is the volume normalization thing going?
[00:29] <ubitux> i don't know
[00:29] <ubitux> nicolas seems not convinced by the live normalization
[00:29] <saste> anything i should review?
[00:30] <ubitux> you can review the small 30 lines shell script to normalize a random file if you want
[00:53] <Zeranoe> A slightly off topic question here, but I just started using git. I did a git init within my project dir and I'm pretty sure my project is now "project/.git", yet I see FFmpeg's git is called "ffmpeg.git". Did I perhaps do something wrong?
[00:54] <nevcairiel> the way its hosted on git servers like that cannot be directly compared to your local repo
[00:55] <nevcairiel> if you clone ffmpeg it  will locally also be ffmpeg/.git
[00:55] <nevcairiel> ffmpeg/ then containing the checkout, and ffmpeg/.git the git data
[00:55] <nevcairiel> on the server, there is no checkout, just the git data
[00:55] <Zeranoe> So is it something to do with gitweb then? Is the clone path for mine still project.git?
[00:56] <nevcairiel> that depends entirely on the server thats hosting it and how its setup
[00:56] <nevcairiel> but its common to name it project.git on the git hosts
[02:02] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:7239b36059b5: fate: dont try to filter partial frames with yadif.
[02:02] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:d6f9610853d5: yop: use reget_buffer() as the previous contents are used
[02:02] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:058c0029322f: avutil/buffer: support memory poisoning
[02:13] <ubitux> michaelni: why is the first one needed?
[02:14] <ubitux> memory poisonning is done in the av_malloc
[02:21] <michaelni> ubitux, oops, ill remove it
[02:27] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:8e944891ce95: avutil/buffer: remove redundant memory poisoning
[02:57] <michaelni> why is valgrind so slow :/
[02:58] Action: michaelni regrets trying to run a full fate under valgrind
[03:10] <Compn> oom ?
[03:10] <Compn> you didnt do one fate section at a time? :P
[03:10] <Compn> ehe
[03:10] <Compn> or just depressed at all the leaks ?
[03:18] <ubitux> michaelni: and i guess you didn't even tried the thread mode? :)
[03:20] <michaelni> Compn, i have enough memory
[03:21] <michaelni> ubitux, i used -j12 
[03:21] <BBB> valgrind is slow because ... it is slow
[03:21] <BBB> try asan, it's quite ok
[03:21] <ubitux> michaelni: i meant helgrind vs memcheck
[03:21] <ubitux> helgrind is something like 6 or 7x slower
[03:21] <BBB> and helgrind is still utterly useless
[03:27] <michaelni> asan is nice but i wanted to check if my patch silenced most of the valgrind noise
[03:30] <ubitux> michaelni: you're working on the use of uninitialized all over the h264 tests?
[03:32] <michaelni> ubitux, yes, ive them "fixed" already
[03:32] <BBB> I heard chrome people complain about that
[03:32] <BBB> one of them was in prefetch, are u/v and y no longer in the same allocated buffer or so?
[03:33] <BBB> also I wrote a tiny_ssim version of tiny_psnr if anyone cares
[03:33] <michaelni> that sounds interresting
[03:33] <BBB> http://pastebin.com/pLknQPcy
[03:34] <BBB> it's a direct copy of the vp8 code, as you'll see
[03:34] <BBB> but it works quite well
[03:34] <ubitux> that makes me remember we need some filter for this :p
[03:34] <BBB> usage: tiny_ssim <plane_a> <plane_b> WxH
[03:34] <BBB> it's probably trivial to make it support different pixel formats or multiple planes, but all I needed was a Y version
[03:35] <Compn> did anyone check that mips guys change to the aacpsy about using faster equation ? can that be reused in other places ?
[03:35] <BBB> I use it on the output of -vcodec rawvideo -f image2 file-%d.Y
[03:36] <michaelni> posted my valgrind/h264 "fix"
[03:36] <ubitux> michaelni: note that valgrind instances disable memory poisonning
[03:37] <michaelni> i know
[03:37] <michaelni> when poisoning is on it should get poisoned when off it would be zeroed either way valgridn should be silent
[03:39] <ubitux> ah ok i see
[03:39] <michaelni> BBB, thanks for tiny_ssim, i wonder if we should put it in tools/ or something ?
[03:39] <BBB> it's not very finished, but sure, if you like it enough, go for it
[03:39] <BBB> don't forget to list the webm authors as having written some of that, plus license
[03:39] <BBB> I didn't write any of it
[03:39] <ubitux> BBB: not motivated to put it in a filter i guess?
[03:40] <BBB> ubitux: I don't really know much about filters
[03:40] <ubitux> oh it's pretty simple now
[03:40] <BBB> I'll probably finish vp9 first :)
[03:40] <ubitux> hehe
[03:40] <BBB> otherwise I'll pretty much die
[03:40] <BBB> maybe after that, if you're not in a hurry
[03:41] <michaelni> BBB, do you have a list of copyrights and or license that it should get ?
[03:41] <BBB> license: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp8/encoder/ssim.c;h=e75160836dc94a9d84231ff2db5b35aed226acc8;hb=HEAD
[03:42] <BBB> I don't see any original authors listed, it's part of an original import
[03:42] <BBB> see http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=history;f=vp8/encoder/ssim.c;h=e75160836dc94a9d84231ff2db5b35aed226acc8;hb=HEAD
[03:43] <Compn> BBB : could you ask youtube guys about rare codec samples ?
[03:43] <Compn> and letting ffmpeg have access to some ?
[03:43] <BBB> Compn: can you be specific about which codecs?
[03:43] <BBB> so... I can try
[03:43] <BBB> but there's two issues
[03:43] <Compn> codecs which youtube does not have decoders for
[03:43] <Compn> copyrights i know
[03:43] <BBB> 1) most of these won't CCL licensed
[03:44] <BBB> 2) you'll probably have to sign a NDA contract
[03:44] <BBB> within these constraints, I can try
[03:44] <BBB> but it sort of defeats the purpose ...
[03:44] <Compn> try! :)
[03:44] <BBB> truth is, most of these samples are owned by the people who uploaded them, so it'd be ... problematic to redistribute them without their explicit permission
[03:44] <BBB> but sure I'll ask
[03:44] <Compn> it should be under fair use due to ... interoperability 
[03:45] <BBB> IANAL but I don't think that's a fair use case under US law
[03:45] <Compn> hmm actually i maybe thinking of dmca :)
[03:45] <BBB> right, that's different, this is copyright, not dmca
[03:45] <Compn> yeah
[03:45] <Compn> woops
[03:46] <BBB> anywya I'll ask
[03:46] <BBB> can you be specific about which codecs?
[03:46] <BBB> I can look for stuff if I know what codec, but "anything we don't have a decoder for" is quite a wide category, a lot of people upload complete crap and it's hard to classify that in any sensible way
[03:46] <BBB> I can probably look for avis with unknown codec and known fourcc or stuff like that
[03:47] <Compn> well i could come up with a list of like 200 fourcc we dont have samples for , if thats what you want
[03:47] <BBB> yeah that might help
[03:47] <Compn> since i have a mixed list atm
[03:47] <Compn> should be easy, one sec
[03:47] <BBB> I can look for those fourccs + CCL
[03:47] <BBB> if there's any sample, I can redistribute them
[03:49] <BBB> Compn: also ask vlc
[03:49] <BBB> Compn: they have tons of samples
[03:49] <Compn> i did, j-b never keeps samples :V
[03:54] <Compn> BBB : http://pastebin.com/jivk6hNm
[03:55] <Compn> more like 350+ 
[03:55] <Compn> some dupes
[03:56] <Compn> of course, not case sensitive
[03:58] <Compn> by my estimation, there must be at least 100 more fourccs that i dont know about :)
[03:59] <Compn> i dont even know how many new codecs are created each year
[04:00] <Compn> kostya has seen quite a few new screen codecs
[04:00] <Compn> and thats just in avi. i dont have a list of quicktime codecs, but theres lots of those we need samples for too
[04:08] <BBB> j-b has tons of samples
[04:08] <BBB> check his bug tracker
[04:09] <BBB> yv16 looks like raw video
[04:09] <BBB> you should not need samples for that
[04:09] <BBB> y422 same
[04:09] <BBB> y211 same
[04:09] <BBB> y42b/t I'd be surprised if it's different
[04:10] <BBB> didn't bastysupercoder have cham samples?
[04:10] <BBB> use | uniq, some samples are there twice
[04:10] <BBB> PY44 is planar yuv 4:4:4
[04:11] <BBB> py16 is playar yuv also
[04:12] <Compn> yeah a lot of the raw codecs are in my list with info like that 
[04:12] <Compn> and we have samples for a few of them 
[04:14] <Compn> and sites like fourcc.org can be wrong too
[04:35] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:8e062fd16988: rawdec: fix memleak
[04:40] <cone-880> ffmpeg.git 03Marton Balint 07master:c46a8c613e75: ffplay: avoid frame data leak on early frame drop
[04:40] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:01a334e8857d: Merge remote-tracking branch 'cus/stable'
[08:56] <cehoyos> compn: yv16 is supported by FFmpeg, no sample needed. Samples that are needed for example include Shrx with x != 0
[12:07] <cone-454> ffmpeg.git 03Janne Grunau 07master:535c247b5718: fate: use little endian yuv444p10 in h264-reinit tests
[12:07] <cone-454> ffmpeg.git 03Martin Storsjö 07master:fe2661121e22: bktr: Add missing includes for av_gettime()
[12:07] <cone-454> ffmpeg.git 03Martin Storsjö 07master:352dbdb96c4f: x86: Remove win64 xmm clobbering wrappers for the now removed avcodec_encode_video function
[12:07] <cone-454> ffmpeg.git 03Martin Storsjö 07master:285ff1441371: x86: Change a missed occurrance of int to ptrdiff_t for strides
[12:07] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:4c6f08bd8f3c: Merge remote-tracking branch 'qatar/master'
[12:20] <xlinkz0> Hey, i would like to compile ffplay using the static libs provided by zeranoe
[12:20] <xlinkz0> but ffplay includes a config.h file.. where could i get that?
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:3ac77f67afcd: lavfi/apad: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:07b7c2a21756: lavfi/sine: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:f7324c068f48: lavfi/perms: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:8b994c8c1cd7: lavfi/select: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:67ad9fd0983e: lavfi/settb: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:3f8072886bac: lavfi/blackframe: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:a36d903601b9: lavfi/boxblur: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:1341dd2dd0a7: lavfi/cropdetect: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:7edda1a935bc: lavfi/deshake: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:a733481d0abc: lavfi/field: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:cb0fb4d04df6: lavfi/fieldorder: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:b595819cde01: lavfi/geq: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:b27a8ba13cf9: lavfi/gradfun: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:552c02f20f5b: lavfi/histeq: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:ab228f91637a: lavfi/idet: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:5dc074d32119: lavfi/kerndeint: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:e62587bc5e72: lavfi/overlay: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:15878b2b5ba7: lavfi/setfield: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:06784b737a95: lavfi/smartblur: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:9e21c89841b9: lavfi/subtitles: use standard options parsing.
[12:33] <cone-454> ffmpeg.git 03Clément BSsch 07master:cbf224b631b0: lavfi/tinterlace: use standard options parsing.
[12:41] <ubitux> xlinkz0: it's generated by the configure script
[12:44] <xlinkz0> ubitux, can i compile it without config.h?
[12:45] <xlinkz0> as i don't know what configure options zeranoe used
[12:45] <xlinkz0> or nvm the options are in the readme file, will try to configure it then
[12:49] <ubitux> the configure option should appear when running one of the ff* tool
[12:49] <ubitux> also, your questions sound like #ffmpeg question
[12:51] <xlinkz0> i've got the libs not the compiled ff tools
[12:52] <xlinkz0> i'm trying to compile the fftools using the already compiled libs
[12:53] <wm4> ubitux: I found a solution to the lavfi ffmpeg vs. libav mess... pull a libavresample
[12:53] <wm4> ubitux: rename the lib, stop merging back
[12:53] <wm4> ubitux: this is terrible advice, but it might just "work"
[12:54] <ubitux> huh?
[12:54] <ubitux> not sure what you mean here
[12:54] <wm4> declare libavfilter a different library from what's in libav
[12:54] <ubitux> what's the relationship with libavresample?
[12:58] <wm4> ubitux: wasn't libavresample just forked (or NIH'ed) from libswresample? they decided to make a "different" library from libswresample, even though it's extremely similar
[12:58] <ubitux> right, but i'm just confused at what you said actually
[13:00] <wm4> as it is, ffmpeg's libavfilter is much better than libav's, and I don't really see why you'd take the pain of merging from libav's
[13:00] <wm4> maybe I'm overestimating the volume of changes in libav's libavfilter though
[13:03] <ubitux> i don't know
[13:03] <ubitux> again, compatibility, etc.
[13:04] <Compn> wm4 : you mean call it libavfilter2 or some such. i dont think it will work due to changing other api as well
[13:04] <ubitux> i don't think that's a very good solution TBH
[13:04] <ubitux> also, i wonder what problem it is trying to solve
[13:04] <wm4> I'm saying that no compatibility will cause less pain for users at this point
[13:04] <wm4> because you pretend it's compatible, while it's nit
[13:04] <wm4> *not
[13:05] <ubitux> except the filter graph prototype thing
[13:05] <ubitux> do you see something else?
[13:05] <wm4> ubitux: well, look at libswresample... these libs are extremely similar, but you still need some amount of compatibility glue
[13:05] <ubitux> right, swr and avr is another story
[13:05] <ubitux> but for lavfi?
[13:06] <wm4> ubitux: but, a user can 1. just use libavresample in ffmpeg if that's what's sufficient, and 2. can consciously make the decision to support both (and take the pain it takes for that)
[13:06] <ubitux> 3. use swr only 4. resample through lavfi
[13:07] <ubitux> 5. contrib some glue code to ffmpeg so everyone can benefit from it and because we didn't have time to do it yet
[13:08] <ubitux> 6. commit genocide
[13:08] <ubitux> infinite possibilities
[13:08] <wm4> 7. enable libavresample by default to make it easier for users
[13:08] <wm4> but no...
[13:08] <ubitux> hey, 8. ask libav to add a swr wrapper
[13:08] <wm4> 9. make libswresample's API exactly the same as libavresample
[13:09] <ubitux> oh this is a bad idea
[13:09] <ubitux> do you prefer avr api?
[13:09] <wm4> either way, you're acting out this libav vs. ffmpeg on the user, not very nice
[13:09] <ubitux> swr is definitely simpler imo
[13:09] <wm4> heh, both APIs are the same
[13:09] <wm4> with slight differences and different names
[13:09] <ubitux> not really
[13:10] <ubitux> you need 2x the amount of parameters/info for the convert function
[13:10] <ubitux> for example
[13:11] <wm4> well that's true (and I don't know why libavresample needs these), but still
[13:11] <wm4> in exchange swr_get_delay needs one more parameter than avresample_get_delay
[13:12] <saste> . merge back libav and ffmpeg
[13:12] <saste> talking about solutions
[13:12] <wm4> but this will never happen
[13:12] <ubitux> one more parameter, but it doesn't need a call to avresample_available()
[13:13] <ubitux> so technically, that's better too
[13:13] <ubitux> or at least simpler
[13:13] <wm4> well, not like the difference is critical
[13:13] <ubitux> sure
[13:13] <ubitux> it's just better in swr :D
[13:13] <wm4> enough for a little bikeshedding, but not for having different libs and APIs
[13:13] <ubitux> yep sure
[13:13] <Compn> wm4 : you could always make a fork of ffmpeg with the 'right' apis and such 
[13:13] <Compn> :P
[13:14] <Compn> if you wanted to help users decide which libs to go with
[13:14] <wm4> Compn: I could use one of the countless stable API wrappers for ffmpeg
[13:14] <ubitux> wm4: anyway, as usual, the main problem is that we lack ressources
[13:14] <Compn> sure libffmpeg is also an alternative
[13:14] <Compn> or whatever wrapper
[13:14] <ubitux> wm4: and it's not like we're doing nothing
[13:14] <wm4> ubitux: what resources do you need to flip the default for libavresample in configure?
[13:14] <ubitux> oh this is political :)
[13:15] <wm4> it sure is
[13:15] <wm4> <ubitux> wm4: and it's not like we're doing nothing <- when will you port MVTools to libavfilter?
[13:15] <ubitux> i'm porting ivtc filters right now
[13:15] <ubitux> takes me quite some efforts already
[13:16] <wm4> there's a lot to port until you're just close to avisynth's power
[13:16] <ubitux> then i may go back on some fft filters i started writing a long while ago
[13:16] <nevcairiel> speaking about mvtools, i wonder how much those functions could benefit from the motionvectors from the decoder
[13:16] <ubitux> also, i have the subtitles thing
[13:16] <ubitux> and well, we have tons of things to do
[13:16] <ubitux> as usual, any help is welcome
[13:18] <ubitux> the main problem i had with frequency based filtering is that we don't have a fft Nd or even 2d helpers afaik
[13:19] <ubitux> can be done naively with two 1d but well
[13:20] <saste> michaelni, you ok with pushing the doc --enable-monolithic-tool doc patches?
[13:21] <ubitux> wm4: and yeah, we need motion compensation stuff
[13:21] <ubitux> saste: speaking of this, i wonder if we shouldn't add some particular filtering tasks
[13:21] <ubitux> saste: a motion compensation toolkit could be nice
[13:21] <saste> ubitux, depends on the student
[13:22] <saste> but sure feel free to add that as an idea, you're the co-mentor after all
[13:22] <ubitux> i'm not sure about adding it to the lavfi task
[13:22] <ubitux> it's starting to be some kind of meta-bomb task with everything inside
[13:23] <ubitux> i'd better dedicate a task to motion compensation
[13:23] <ubitux> like writing various filters around a common motion comp. code
[13:25] <saste> ubitux: sure, otoh i don't want to overload you with mentoring tasks
[13:25] <saste> consider that in general this rule apply: mentoring a student takes more effort than writing the thing yourself
[13:26] <ubitux> yeah maybe
[13:26] <saste> but of course it depends on the student and a lot of factor
[13:26] <ubitux> i don't think we'll have to mentor thousands students anyway
[13:27] <ubitux> we kinda lack quite a bunch of efficient filters
[13:27] <saste> ubitux, no indeed it is not even sure we'll be accepted :-)
[13:27] <ubitux> so it would be nice to make some activities around this topic
[13:27] <ubitux> saste: haha yeah...
[13:28] <ubitux> btw, we still have no introduction for students on that page?
[13:29] <saste> ubitux, feel free to add another task
[13:29] <saste> you can select the accepted tasks later, depending on students and all
[13:29] <saste> still waiting for llogan
[13:30] <ubitux> ok maybe i'll add it, if i don't feel lazy next time i wake up
[13:37] <ubitux> btw, if some feels like adding fft 2d or Nd and related routines to our api, that would be really appreciate ;)
[13:37] <ubitux> someone*
[13:37] <ubitux> i wonder if i couldn't motivate Nicolas for this since he seems to do some math stuff
[13:38] <ubitux> but i'd better see him pushing some subtitles stuff
[13:51] <saste> ubitux, do you want to migrate thumbnail to named options/shorthand?
[13:56] <michaelni> saste, replied about the monolith
[13:57] <michaelni> note i didnt check how the actual generated mono docs look
[18:43] <saste> michaelni, at some point i'll need your help with the opencl patches, since that's supposedly public interface
[18:43] <saste> and there are many parts which i still don't like
[18:49] <mateo`_> hi, can someone confirm me that there is no way to set options to a codec from a demuxer init (since the codec is not yet opened) ?
[18:53] <michaelni> mateo`_, what are you trying to do =
[18:53] <michaelni> ?
[18:54] <michaelni> "saste and there are many parts which i still don't like" <-- how could i help with that? ;)
[18:55] <mateo`_> michaelni: still working on the mxf + j2k interlaced, i would like to set a specific option to the decoder if the mxf layout is separate fields
[18:56] <michaelni> mateo`_, that sounds flawed
[18:56] <mateo`_> (considering i added separate_fields option to libopenjpegdec)
[18:56] <mateo`_> my first solution was to use the avct property field_order
[18:57] <mateo`_> but this solution will not work is the layout is segmented frame
[18:57] <mateo`_> segmented frame means = fields are stored in differents pictures but the result is progressive
[18:58] <michaelni> mateo consider there is no decoder but the frames are sent over a network together with side data, extra data, codec tag and codec id
[18:58] <mateo`_> the current solution i have is to use the extradata field
[18:58] <michaelni> and what is the problem with that ?
[18:59] <mateo`_> i don't know if it is right to allocate extradata from the the demuxer to store such information
[19:02] <michaelni> you could do many things, extradata is one option, the codec tag is another yet another is to put the 2 fields in one packet in the demuxer and handle that in the decoder
[19:02] <michaelni> but trying to set private options of the decoder from the demuxer is not a good idea
[19:04] <mateo`_> ok
[19:04] <michaelni> also can this stuff chnage mid stream ?
[19:04] <michaelni> if it can change then its more tricky
[19:04] <mateo`_> it is not supposed to change mid stream
[19:04] <michaelni> ok
[19:09] <mateo`_> the correct solution would be to put the 2 fields in a single packet (to have proper pts) + telling the decoder via extradata to handle the separate/segmented fields layout
[19:09] <mateo`_> -the+a
[19:10] <saste> michaelni, for example the wrapper generate some files (a log, and some binary files)
[19:10] <saste> i'm not sure it's a good idea for a library
[19:10] <saste> otoh we could just assume that is some sort of experimental stuff and be lax on that
[19:11] <nevcairiel> a whole new topic like opencl which ends up without an official maintainer of sorts, it will never get cleaned up properly
[19:11] <saste> nevcairiel, the idea is that the contributor will become maintainer at some point
[19:12] <michaelni> yes
[19:13] <michaelni> s/yes/yes, the author should become maintainer/
[19:13] <nevcairiel> ideally, but we don't live in an ideal world
[19:14] <michaelni> saste, is there an alternative to generating these files ?
[19:14] <saste> michaelni, which files?
[19:14] <nevcairiel> maybe he will evolve/grow into that, but right now, i would still try to guide him to some clean(er) solution
[19:14] <michaelni> saste "generate some files (a log, and some binary files)"
[19:17] <saste> michaelni, i don't know enough about opencl to say
[19:18] <saste> opencl compiles a string provided by the program and generates a binary file, so it hasn't to compute it again the next time, but just read it
[19:19] <saste> the log file is generated when compiling this file, and right now is written to a "kernel-build.log" file
[19:21] <saste> nevcairiel, you're welcome to review the patches and suggest a better design
[19:21] <saste> the most critical patch is the lavu one, since it provides a public interface
[19:24] <ubitux> saste: about thumbnail, i don't mind 
[19:24] <ubitux> whatever you prefer
[19:28] <michaelni> saste, i suspect it can be done without files, opencl would be badly misdesigned otherwise
[20:03] <ubitux> saste: so do you want me to do thumbnail?
[20:08] <saste> ubitux, would be nice
[20:08] <saste> so one filter less to do
[20:09] <ubitux> ok
[20:15] <saste> michaelni, thanks for sharing the burden of opencl review :)
[20:26] <cone-454> ffmpeg.git 03Stefano Sabatini 07master:1b140835b698: lavfi/colormatrix: add support for named options
[20:26] <cone-454> ffmpeg.git 03Stefano Sabatini 07master:3b811bcf6740: lavfi/colormatrix: reword error message in init
[20:40] <cone-454> ffmpeg.git 03Clément BSsch 07master:386dc9a3a8bc: lavfi/thumbnail: add support for named options.
[20:40] <ubitux> saste: another one where i'm a maintainer?
[22:15] <saste> ubitux: no
[22:16] <saste> missing are: pan, ocv, frei0r, mp, hue
[22:16] <saste> and hqdn3d
[22:36] <ubitux> saste: can we really change them?
[22:37] <saste> ubitux, mp -> easy
[22:37] <saste> hqdn3d: feasible but complicated, i leave that to anton so we avoid more merge conflicts
[22:38] <saste> ocv, frei0r, pan: syntax problems, since they allow ":" in their syntax
[22:38] <saste> still not sure how to deal with them
[22:38] <saste> a compatibility break may be due at some point
[22:38] <ubitux> why would you want to switch to named options for them at all cost?
[22:38] <saste> hue: should be also feasible, but i have to unroll the parsing mess
[22:38] <saste> ubitux, at all cost?
[22:38] <saste> no
[22:38] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:e2b30194bb7e: h264/field_end move progress report code after error concealment.
[22:39] <ubitux> i mean, is that really a problem to leave them without named options?
[22:39] <ubitux> for those where it makes sense like pan
[22:40] <saste> ubitux, maybe not a problem
[22:40] <ubitux> saste: any comment on the python version of the norm script btw?
[22:41] <saste> looks ok but i'm trying to do something else right now
[22:41] <ubitux> ok ok :)
[22:44] <saste> i like how libav doesn't care about breaking syntax
[23:56] <cone-454> ffmpeg.git 03Nicolas George 07master:57cb4fb0750a: lavfi: add test for concat.
[23:56] <cone-454> ffmpeg.git 03Nicolas George 07master:00da527b44a6: lavfi/af_amerge: return EAGAIN if the input layouts are not known.
[23:56] <cone-454> ffmpeg.git 03Nicolas George 07master:125acd215250: lavfi: support multiple rounds of format negotiation.
[23:56] <cone-454> ffmpeg.git 03Nicolas George 07master:4f112a8e3402: lavf/mux: add the flush_packets option.
[00:00] --- Mon Mar 25 2013