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

[burek]

[00:34] <saste> llogan, status? :)
[00:35] <saste> i'm going to ping mentors / backup mentors, and I'll fill the missing backup mentors with myself tomorrow
[00:39] <llogan> saste: i'm re-working the "getting started" section now.
[00:40] <saste> llogan, thanks
[00:40] <saste> i realize i mixed second and third person when writing the text
[00:40] <Daemon404> i can mentor or backup mentor <something>
[00:40] <Daemon404> i have no preference
[00:40] <saste> probably no-one will notice that anyway
[00:40] <saste> Daemon404, anything specific?
[00:40] <Daemon404> let me look at the list
[00:41] <llogan> saste: i'm s/task/project/g (except qualification task). "project" sounds more like fun and "task" sounds more like work.
[00:42] <saste> llogan: s/task/funtask/
[00:42] <Daemon404> yeah no preference really
[00:42] <Daemon404> apng sounds fairly easy.
[00:43] <Daemon404> also
[00:43] <Daemon404> "a controller filter which allows to send commands to other filters (e.g. to adjust volume, contrast, etc.), e.g. like the sendcmd filter but through an interactive GUI"
[00:44] <Daemon404> wouldnt this make more sense as a GUI using lavfi
[00:44] <Daemon404> using a filter itself for the gui sounds insane
[00:44] <saste> Daemon404, sounds like a funny proof of concept
[00:44] <saste> Daemon404, ideally that could be done with lua scripting, once we have it
[00:45] <Daemon404> heh
[00:45] <Daemon404> like i said before
[00:45] <Daemon404> the only idea i had was way too hard for a SoC student
[00:45] <Daemon404> or perhaps even mortals
[00:45] <saste> Daemon404, what?
[00:46] <saste> understanding nut specs?
[00:46] <Daemon404> "fix" libavformat so it can properly handle virtual timelines
[00:46] <Daemon404> liek edit lists in mp4
[00:46] <Daemon404> or matroska timelines
[00:46] <saste> Daemon404, what about accurate seeking in libavformat?
[00:46] <saste> otoh i don't know if that's really feasible, but definitively a popular request
[00:47] <Daemon404> its feasible
[00:47] <Daemon404> ffms2 achieves this
[00:47] <Daemon404> you just need a higher level api
[00:47] <Daemon404> which indexes
[00:48] <saste> Daemon404, do you want to propose a funtask for that, or you prefer to co-mentor some already existing ones?
[00:48] <Daemon404> i dont know if i like either idea for lavf
[00:48] <Daemon404> cause that means the SoC sudent designs a public API
[00:48] <Daemon404> history shows thats not a Great Idea
[00:49] <saste> Daemon404, yes i tend to agree...
[00:49] <saste> ideally coding tasks with a well defined area are favored
[00:50] <Plorkyeran> if you limit it too frame accurate seeking and punt on audio there's not too much space for them to fuck up
[00:50] <Plorkyeran> but yeah, gsoc api design sounds like a terrible idea
[00:50] <Daemon404> saste, perhaps a small idea for the lavfi task: vf_vapoursynth.c
[00:51] <Daemon404> its liekly not much work
[00:51] <saste> Daemon404, if you can help that's perfectly fine
[00:51] <Daemon404> i can
[00:52] <saste> i can help that to the ideas list for the lavfi-task
[00:52] <Daemon404> s/help/add/ ?
[00:52] <saste> Daemon404, wtf yes
[00:52] <Daemon404> ok
[00:52] <Daemon404> Plorkyeran, iirc a gsoc api design is how lavfi came to be
[00:53] <Daemon404> or so the Old Ones have told me
[00:57] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:c6831e2a70f7: wavpack: check K, fix assertion failure
[00:57] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:a56d963f111b: vp3: Check fps validity more completely
[00:58] <Daemon404> oh lord
[00:58] <Daemon404> mysterious j00ru fixes again
[00:59] <Daemon404> michaelni, what is "k" in "k is too large"
[00:59] <Daemon404> no value k is checked
[01:00] <Daemon404> just "add"
[01:04] <michaelni> Daemon404, the argument of get_tail() its k
[01:05] <llogan> do they just contact you directly?
[01:08] <Daemon404> well that doesnt really explain what k is
[01:08] Action: Daemon404 shrugs
[01:10] <michaelni> k is a parameter to the vlc reading function, its always called k 
[01:10] <llogan> i need some trolls to look at the "getting started" and "qualification task" sections and tell me what is unclear/retarded
[01:10] <llogan> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[01:11] <Daemon404> a lot of other things are called k too. heh.
[01:11] Action: Daemon404 goes to grab food
[01:11] <wm4> Daemon404: don't you like hating on mplayer stuff? http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2013-March/071551.html
[01:11] <wm4> I like how he defends this convoluted crap called "direct rendering"
[01:12] <wm4> which is completely horrible compared to refcounted images
[01:12] <Daemon404> fun stuff. i do use DR, but not for what mplayer does.
[01:12] <Daemon404> an it is very convolued.
[01:13] Action: Daemon404 really foods now
[01:13] <wm4> mplayer's filter chain basically works by the same principles as what you know as DR in ffmpeg
[01:13] <wm4> it makes the simplest filters hilariously complex
[01:15] <saste> llogan, looks much better to me
[01:15] <saste> but i'm no troll
[01:15] <saste> i'll have another look at it tomorrow
[01:17] <llogan> saste: i've been looking at it too long now. a sentence on "3. apply" explaining that a student that completes a qual task will more likely be picked...or similar
[01:17] <llogan> would be a good addition
[01:18] <llogan> but i think i'm basically done.
[01:25] <michaelni> llogan,  "visiting our our IRC"
[01:26] <michaelni> "Feel free to ask any questions you may have." <--- is it clear "where" ?
[01:26] <michaelni> "projects are are additional"
[01:28] <michaelni> mixed person first "Contact us. If you find a project that you are interested in " then "and a qualification task will show us that the student is motivated"
[01:31] <michaelni> "If you are new to FFmpeg, and have relatively small experience" -> little experience id say
[01:34] <michaelni> is "Optional goodies: " supposed to look bold like the other headings ?
[01:41] <llogan> thanks. These are are now fixed. except for "optional goodies"; i don't think it needs bold
[01:49] <highgod> Hi, michaelni, are you on line?
[02:07] <michaelni> highgod, yes
[02:10] <wm4> so, would it be possible to multithread libavfilter? so that, if enough frames are queued via buffersrc or so, libavfilter will automatically distribute the work load over multiple threads if possible
[02:11] <wm4> this would require filters to report if they are thread-safe and whether there are dependencies between frames, I think
[02:11] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:1831274ff1ef: electronicarts: check timebase, fix assertion failure
[02:11] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:ea9a6709a941: estimate_timings_from_bit_rate: Check timebase and bitrate
[02:13] <highgod> Hi, michaelni, about the opencl patch "this should be where the other OBJS-$(...) are" I don't get what it mean, shouldn't it be comliled when set opencl
[02:13] <michaelni> wm4, everything is possible
[02:14] <michaelni> highgod, there are several lines in the Makefile that look like "OBJS-$(...)" the one you add should be added closer to them
[02:14] <michaelni> thats purely cosmetical difference
[02:14] <highgod> OK
[02:17] <highgod> and you said ffmpeg will compile all the kernel, I don't think it is a problem, it does not cost much time
[02:19] <highgod> and about one command queue for each kernel is not need, if like this, it will awaste of resource 
[02:22] <highgod> about the thread problems, you said the empty function, I think the macro HAVE_MEMORYBARRIER HAVE_SYNC_VAL_COMPARE_AND_SWAP HAVE_MACHINE_RW_BARRIER have the system ensure for this, is it right? I reference the atomic code
[02:29] <michaelni> it doesnt cost much time with just one filter
[02:30] <michaelni> when there are many filters this design will become annoying
[02:30] <michaelni> especially on embeded hardware
[02:31] <michaelni> the command que changing functions from openCL are not thread safe
[02:32] <michaelni> so if theres just one then all access to it needs to be under a global mutex
[02:33] <michaelni> but the accesses are all set to blocking so it would be blocking with a locked global mutex
[02:33] <michaelni> thats not good design
[02:35] <michaelni> about the empty lock function, if its empty its empty and doesnt lock
[02:35] <michaelni> so no concurrency is possible in that case
[02:36] <michaelni> it basically means opencl will only work when pthreads are available or there are no threads
[02:42] <michaelni> said differently the current code will randomly fail with threading systems other than pthreads
[02:45] <wm4> shouldn't thread-safety be the concern of the caller then?
[02:46] <wm4> like it's with everything
[02:46] <michaelni> wm4, who is the caller ?
[02:46] <michaelni> the avfilter? 
[02:46] <michaelni> if so it would need a lock shared with all other possible users of the opencl code
[02:47] <michaelni> other filters, maybe codecs , ...
[02:47] <j-b> what's up?
[02:47] <wm4> the one creating the opencl context is obviously the one responsible, then
[02:47] Action: j-b kicks cone-985 
[02:48] <michaelni> wm4, the context gets created by the first filter using it and reused by all others IIRC
[02:49] <michaelni> or one could say the opencl code in libavutil creates the context
[02:50] <michaelni> but its missing some locks still
[02:51] <highgod> michaelni:about the compile time, we have a way that compile all kernel in one time and write the compile info in a binary file, when ffmpeg run the second time, it just load the binary file and use with out compile, but you have said it is not safe. we will implement this later
[02:52] <highgod> michaelni:so I think we can do it as what we do now, and add optimize it later
[02:52] <wm4> actually the nvidia driver on Linux caches OpenGL shader compilation on disk transparently
[02:53] <highgod> as you said, there are not many kernels now, if we change the method, it will make the compile operation more complex
[02:57] <michaelni> If we end up having  to  change later it will be more work
[02:58] <michaelni> also compiling after registration might allow optimizations like having user specified parameters be constants in the compile, i dont know if that makes any sense though performancewise
[02:59] <michaelni> anyway i can live with the monolithic load and compile if its hard to make it more fine grained
[03:00] <michaelni> but can you explain what is the added complexity that would have ?
[03:04] <highgod> we want to implement as the binary file to optimize the compile operation whitch can make ffmpeg compile just once. it should compile all kernels in ffmpeg. it is the best way to compile operation
[03:04] <oneal> assuming there are two caller, the firest caller has 3 kernels, the second caller has 4 kernels, if every caller need to compile and load it, then both of the 2 kernels need to run 2 compiler and load, the time for running 2 compile is longer than running 1 compile.
[03:06] <oneal> Yes, like what's hihdgod said, OpenCL kernel compile can genenrate a bin file which is a Intermediate code. there is a time reduction when building the kernel from the binary
[03:07] <oneal> now OpenCL have tow compile procedure, one the compile from kernel source code, like the c compiler, another is compile from the binary which is generated by the pre-compile.
[03:09] <oneal> the binary is a Intermediate code, this must be to be interpreted by OpenCL runtime. 
[03:09] <highgod> michaelni:about the golobal context and command queue, we have tested that it is safe for multi-threads
[03:09] <highgod> so we use like this
[03:09] <oneal> so the security of the binary code has a security guarantees
[03:11] <michaelni> the documentation explicitly states that its not safe
[03:11] <michaelni> "OpenCL API calls
[03:11] <michaelni> that queue commands to a command-queue or change the state of OpenCL objects such as
[03:11] <michaelni> command-queue objects, memory objects, program and kernel objects are not thread-safe.
[03:11] <michaelni> "
[03:12] <michaelni> and you cannot "test" thread saftey
[03:13] <michaelni> it can work a million times and crash the million+1 time
[03:14] <oneal> the commands in the command queue can change the status of OpenCL time. such as the status mechine. 
[03:15] <oneal> for every signle OpenCL objects, such buffer, command queue, context, it is not the thread-safe 
[03:16] <oneal> the user application must to do the mechanism  in multi-thread sence.
[03:21] <michaelni> the user application has no means to do it, it doesnt access filters one by one
[03:21] <michaelni> it pushes things into a filter graph
[03:22] <michaelni> consider a codec using opencl and a filter using opencl
[03:22] <michaelni> if the user application would do sync that would mean it could not run any filter or any codec at the same time as any other
[03:23] <michaelni> also that would break current API & ABI which allows codecs & filters to run at the same time
[03:24] <highgod> michaelni, I don't get what you mean, I have test two opencl kernels in this way
[03:25] <michaelni> highgod, undefined behavior is undefined behavior you cant test it. It can work perfectly now and break with a different hardware or different driver revission or maybe you are just lucky
[03:25] <michaelni> today
[03:26] <michaelni> That is if we agree that the documentation does say that this is not ok
[03:27] <wm4> michaelni: so the entire problem is that opencl is somehow global... is that because opencl forces you to, or other reasons?
[03:27] <highgod> michaelni, the document you mean OpenCL Specification Version: 1.2?
[03:28] <michaelni> hmm, seems its 1.0 
[03:28] <michaelni> where can i find 1.2 ?
[03:31] <highgod> I will send you one
[03:34] <michaelni> I found www.khronos.org/registry/cl/specs/opencl-1.2.pdf
[03:38] <highgod> michaelni, I have sent it to you
[03:41] <michaelni> highgod, it seems 1.2 extends thread saftey to all functions
[03:43] <michaelni> so it should be ok without locks on the que access if i understand it correctly
[03:44] <michaelni> that leaves the empty locks in absence of pthreads
[03:48] <michaelni> i guess for now you could make pthreads a dependancy of the opencl code 
[04:03] <highgod> ok,michaelni.
[04:04] <highgod> Hi, michaelni, do you mean I can delete the lock_opencl function?
[04:07] <michaelni> you could use pthread_mutex_lock() directly for now yes, maybe later if you want to support other threading systems we need to find another solution, we do have some generic lock manager bit its in avcodec not avutil  ...
[04:08] <highgod> michaelni, do you mean the command queue and context don't need the muti-thread, right?
[04:09] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:10ece44d0948: h264_cavlc: fix assertion failure due to reading too long vlc
[04:09] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:e234daa5180f: mlpdec: Fix reading state with 0 bit elements.
[04:10] <michaelni> highgod, the concern i had was based on the 1.0 spec, the 1.2 spec makes more gurantees so it could be ok i dont know opencl well enough to say for sure
[04:11] <llogan> i wonder why -vf works with ffplay but -filter:v is not recognized.
[04:14] <michaelni> llogan, probably because of "grep '"filter"' ffplay*c ffmpeg*c"
[04:14] <llogan> i guess i could have tried that.
[04:17] <highgod> michaelni,and about the compile operation, can you accept the recent way? it can be use in the binary way, if we change it, we will change back when we use the binary way. it add works
[04:25] <michaelni> I think its pretty much the decission of the maintainer (which would be you) if you want to support fine grained compile&load
[04:26] Action: michaelni falls asleep
[05:38] <ubitux> < michaelni> ubitux, a bit early ;)  but n8 // right, but seems i woke up early too :)
[08:26] <ubitux> michaelni: when merging the fate tests from libav, please keep our own (even if you add the ones from them)
[09:11] <highgod> why I use the sdl to compile ffplay on mingw, then the output of ffmpeg is disappear?
[09:14] <av500> ?
[09:16] <highgod> I install sdl to compile ffplay on mingw,than all the output info of ffmpeg and ffplay is now show on the screen
[09:18] <highgod> I install sdl to compile ffplay on mingw,than all the output info of ffmpeg and ffplay is not show on the screen
[09:35] <highgod> ??
[09:36] <ubitux> highgod: a user was complaining about such thing a few days ago
[09:36] <ubitux> might be a bug
[09:36] <ubitux> none of the developers are working with mingw afaik, so you're on your own
[09:37] <highgod> I tried other computers
[09:37] <highgod> the same errpr
[09:37] <highgod> error
[09:37] <highgod> is is a bug of sdl or ffmpeg?
[09:38] <ubitux> i don't know, most likely mingw
[09:49] <funman> highgod: ffmpeg as well? but it's not built with sdl, only ffplay
[09:50] <highgod> but ffmpeg's out put is disappear too
[09:51] <funman> i guessed console vs Gui windows application
[09:51] <funman> on windows if you have a GUI application it can not write to the console anymore
[09:51] <highgod> so if I unstall sdl, it will fix?
[09:52] <funman> i don't really understand what 'no output' means
[09:52] <highgod> the out put information of ffmpeg and ffplay, 
[09:53] <funman> like copyright, help?
[09:53] <funman> you're running it in cmd.exe?
[09:54] <ubitux> < funman> on windows if you have a GUI application it can not write to the console anymore // wat? oO
[09:54] <ubitux> seriously? :D
[09:54] <funman> not with cmd.exe at least
[09:54] <funman> with some msys terminals/shells combos it works
[09:56] <funman> The Windows GUI development doesn't conveniently support the access to cout, cerr, stdout, or stderr. It may be difficult to obtain these under direct control of the window program. At least there exist some tricks to obtain the information if really needed.
[11:03] <cone-938> ffmpeg.git 03Janne Grunau 07master:d767e2f96993: configure: fix dependencies of XvMC and old vdpau mpeg2 decoders
[11:03] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:021547bfcc90: Merge commit 'd767e2f969933b4e450ed4e69ea2bf8ca864838c'
[11:09] <cone-938> ffmpeg.git 03Janne Grunau 07master:757d85868b77: vdpau: fix obsolete mpeg1 vdpau decoder when mpeg2 is disabled
[11:09] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7609d42d0f46: Merge commit '757d85868b77c4fdec7b77a3b7de1faf16c031e8'
[11:19] <cone-938> ffmpeg.git 03Janne Grunau 07master:b24725392977: vdpau: wrap codec specific functions in appropiate #ifs
[11:19] <cone-938> ffmpeg.git 03Diego Biurrun 07master:1db6a080bddd: dca: Move ff_dca_convert_bitstream() to the DCA common code
[11:19] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:b1064dd783b2: Merge commit '1db6a080bddd14fed6b29140ecd2e21e42b1c022'
[11:25] <cone-938> ffmpeg.git 03Diego Biurrun 07master:b6649ab5037f: cosmetics: Remove unnecessary extern keywords from function declarations
[11:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:63a97d56748a: Merge commit 'b6649ab5037fb55f78c2606f3d23cea0867cdeaa'
[11:36] <cone-938> ffmpeg.git 03Diego Biurrun 07master:eee2000b4123: mpeg12: Move some ff_mpeg1_* function declarations to a more suitable place
[11:37] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:385ffc7650d2: Merge commit 'eee2000b41234ae9465c314e18bfec1700181f32'
[11:53] <cone-938> ffmpeg.git 03Diego Biurrun 07master:1b6d66745ac1: Split MPEG-1/2 decoder code off from MPEG-1/2 common code
[11:53] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:016c00cf68a4: Merge commit '1b6d66745ac1768adb387c2227cdcf4452271149'
[12:00] <cone-938> ffmpeg.git 03Diego Biurrun 07master:e557584aa7df: mpeg12: Move Mpeg1Context declaration to the only place it is used
[12:00] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2bfcd74ad3e3: Merge commit 'e557584aa7df6ac9f52af7ee7e5c963437da2e2f'
[12:09] <ubitux> ok, only documentation left for ivtc
[12:10] <ubitux> that was more painful than i imagined
[12:12] <cone-938> ffmpeg.git 03Martin Storsjö 07master:3891a270f5b4: msmpeg4: Split decoding related functions to a separate file
[12:12] <cone-938> ffmpeg.git 03Diego Biurrun 07master:b4d24b471bc5: build: Remove configure-generated .config file on distclean
[12:12] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2b6185cac945: Merge commit 'b4d24b471bc52f1f78a43ee330199e70483e51c3'
[12:16] <wm4> ubitux: what was painful?
[12:17] <ubitux> wm4: understanding, and different filtering logics
[12:17] <cone-938> ffmpeg.git 03Diego Biurrun 07master:7c22d0489fa4: build: Move setting of SRC_DIR to the only place it is used
[12:17] <cone-938> ffmpeg.git 03Kostya Shishkov 07master:472391b9a7e1: ape: use correct context for the bit table printed in debug
[12:17] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:dac1d92cb757: Merge commit '472391b9a7e15e3bff33b016e7b6dbfa6a555975'
[12:18] <wm4> I still don't get why ffmpeg needs a port of this, but whatever
[12:23] <ubitux> since you don't want to understand, i won't repeat myself for the nth time :P
[12:24] <wm4> you're doing it for fun and to learn
[12:25] <ubitux> you forgot some important points
[12:25] <wm4> and because ffmpeg needs an ivtc filter
[12:25] <cone-938> ffmpeg.git 03Martin Storsjö 07master:cfe5908a72e7: configure: Add error_resilience as dependency to the eatqi decoder
[12:25] <cone-938> ffmpeg.git 03Reimar Döffinger 07master:e9cc98839574: win32: Allow other programs to open the same files
[12:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e63ebaca16b7: Merge commit 'e9cc98839574c7e8d546e890ebbf57d1766e5d8a'
[12:26] <ubitux> we should be able to drop mp={detc,divtc,filmdint,pullup,ivtc} after this btw
[12:32] <ubitux> there won't be much filters left in the mp wrapper
[12:32] <ubitux> likely eq2, mcdeint and spp will be relevant
[12:32] <ubitux> that will be quite an achievement :)
[12:32] <ubitux> wm4: and so for the nth time, the main argument of using a vsynth wrapper instead of a native ivtc filter is that it will be a huge pain for users to have a ffmpeg build with an ivtc
[12:32] <ubitux> unless we copy/paste source code from vsynth and write a wrapper just like mp
[12:32] <ubitux> and i'd like to avoid that.
[12:32] <ubitux> also, writing a vsynth wrapper won't be that trivial
[12:32] <ubitux> IMO
[12:32] <ubitux> and since no one wants to do it, i'd better have a native ivtc filter and everyone will be happy
[12:33] <ubitux> especially after dropping 4.5k code of unused ivtc code in the mp wrapper
[12:33] <wm4> lol using that as argument
[12:33] <ubitux> wm4: do you understand now or i will need to repeat myself in 2-3 days?
[12:34] <cone-938> ffmpeg.git 03Reimar Döffinger 07master:ad04025987e5: win32: Make ff_win32_open more robust
[12:34] <cone-938> ffmpeg.git 03Hendrik Leppkes 07master:85a46ad68504: win32: Use 64-bit fstat/lseek variants for MSVC as well
[12:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:cf53704c5537: AVOptions: make av_set_options_string() forward options to child objects
[12:34] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:fd37a7dc3c1b: Merge commit 'cf53704c55378cc0dcfc16637cdac7d58f0b3107'
[12:34] <wm4> so when will you fix that users have to go through pain to build ffmpeg with h264 encoder enabled?
[12:35] <ubitux> wm4: what are you talking about?
[12:35] <ubitux> libx264 is packaged all over
[12:35] <wm4> so what until vapoursynth gets more popular?
[12:36] <wm4> *wait
[12:36] <ubitux> i don't know if it will ever happen in the next month
[12:36] <ubitux> it took me 1-2 week to port the filter
[12:37] <ubitux> i wonder why you insist so much on having a vsynth wrapper
[12:37] <ubitux> just write it if you want it
[12:38] <ubitux> ivtc is an essential feature, it belongs to the libavfilter core
[12:38] <wm4> because I think it'd be much better to help a young project (with the potential to become as powerful as avisynth), rather than sabotage it by porting away the useful bits?
[12:38] <ubitux> wm4: do you think we should have linked against pulseaudio for af volume because pulseaudio already had some volume normalization assembly code?
[12:38] <kierank> There are other people who'd like to use filters outside of an avisynth style framework
[12:39] <ubitux> wm4: oh so that is your actual concern?
[12:39] <wm4> ubitux: if you want to make a comparison, why don't you do that with frei0r or sox?
[12:39] <ubitux> we actually do
[12:40] <wm4> ubitux: that, and also that porting it and having it maintaining it yourself makes 0 sense
[12:40] <ubitux> we have a wrapper, but we are writing a lot of features into ffmpeg as builtin
[12:40] <ubitux> wm4: you know what is the purpose of the project right?
[12:40] <wm4> NIH on steroids?
[12:41] <ubitux> this is not NIH, it's a port
[12:41] <ubitux> with full credits
[12:42] <ubitux> wm4: i don't think it's relevant to prevent adding features in ffmpeg because it will kill younger projects
[12:42] <ubitux> and if vsynth is a good project, that will certainly not kill it
[12:42] <ubitux> i believe it's strength is not only in having useful filters ported
[12:43] <ubitux> but more like having python scripting, and a filtering scripting appreciated in various communities
[12:44] <ubitux> wm4: we should also not ever add frame seeking in ffmpeg because ffms2 has this feature, and it will kill it if we add the feature to ffmpeg?
[12:44] <ubitux> that argument is silly imo
[12:44] <ubitux> now if you don't mind, i'm going to add the documentation to the filter, which is not present in vsynth
[12:44] Action: ubitux &
[12:44] <wm4> don't worry, ffmpeg's API will always be convoluted and tricky enough that ffms2 will be needed
[12:45] <ubitux> and lavfi will be always trolled for its filtergraph, so no worry vsynth won't die
[12:45] <wm4> you mean http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/132031.html ?
[12:46] <ubitux> speaking of this, we did quite some improvements
[12:59] <cone-938> ffmpeg.git 03Paul B Mahol 07master:705b607db88f: lavfi/biquads: fix min allowed option value
[13:04] <ubitux> durandal_1707: you should give credits to the guy in these cases
[13:05] <durandal_1707> really, ask guy to send real patch
[13:05] <durandal_1707> and his name is not in ascii
[13:05] <ubitux> mine isn't either :)
[13:05] <ubitux> he actually sent a patch, not in a proper form right, but a patch anyway
[13:06] <ubitux> you could have at least mentioned it in the commit description :p
[13:11] <cone-938> ffmpeg.git 03Anton Khirnov 07master:a4208b9b7d62: avconv: add options for reading filtergraphs from a file.
[13:11] <cone-938> ffmpeg.git 03Diego Biurrun 07master:f2a59722d161: fate: filter: Add dependencies
[13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:8b9a153ef367: lavfi/gradfun: do not increment DC pointer for odd values.
[13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:2d66fc543b01: lavfi/gradfun: fix rounding in MMX code.
[13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:38a2f88d39e5: lavfi/gradfun: fix dithering in MMX code.
[13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:1ae44c87c924: lavfi/gradfun: remove rounding to match C and SSE code.
[13:11] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:ac1a1fd7088c: Merge commit '1ae44c87c924b69a0657256fbaa8ad140df2f27c'
[13:30] <jojva> can someone explain to me what is expected from a project of gsoc ? Would it be possible for me to have a summer job and contribute on ffmpeg only when I have the time ? Or is it expected that gsoc is a kind of "full-time" job ?
[13:31] <durandal_1707> its not full time job
[13:32] <durandal_1707> it does not need to be one...
[13:33] <ubitux> jojva: i remember stefano saying the students were expected to work around 6-8 hours per week
[13:33] <ubitux> depending on the project it might be required to work more
[13:33] <jojva> mvc is quite big... and i'm already working more than 6h/week on it
[13:34] <ubitux> you'll have about ~3 months
[13:34] <Compn> jojva : you are working on h264 mvc for ffmpeg ?
[13:34] <Compn> if so we should probably take mvc off our gsoc list...
[13:35] <jojva> i can't say i'm working FOR ffmpeg right now, it's a project I'm doing for university
[13:35] <ubitux> Compn: or he could do it as a student.
[13:36] <Compn> ubitux : sure
[13:37] <ubitux> he looks like the perfect candidate to me
[13:38] <av500> doing something for uni and gsoc in parallel?
[13:39] <Compn> jojva : mvc (and hevc) is probably the biggest task 
[13:39] <jojva> I must say that my first priority is to get a paid job (I have a rent^^), but then implementing mvc could be a great thing (and also on my resume)
[13:39] <jojva> I guess so
[13:40] <jojva> Although with MVC I don't even have to know how cabac/cavlc work
[13:40] <Compn> :)
[13:40] <jojva> but still big
[13:41] <jojva> av500 : not in parallel, the uni project started a month ago and will be finished in a few eeks
[13:41] <av500> ok
[13:43] <jojva> I mean the decoder won't be finished, it's just the time we have to do a bigger project (film an object like a skull head with a 3D cam, decode the video, compute the depthmaps then output a 3D model)
[13:44] <Compn> people film 3d on youtube using two webcams :)
[13:44] <Compn> ehe
[13:44] <Compn> and mplayer/ffmpeg stereo3d filter
[13:45] <jojva> what do you mean ?
[13:45] <jojva> and btw, do not take mvc off the gsoc list
[13:45] <jojva> it's still relevant
[13:46] <Compn> i mean you can use any 2 regular cameras and combine the video together later using filters
[13:46] <Compn> dont need a special 3d camera...
[13:47] <Compn> with dumb 3d h264 codec :P
[13:47] <jojva> I know, but this decoder needs to be done anyway
[13:47] <Compn> yep yep
[13:47] Action: Compn afk
[13:48] <jojva> Spec was released in 2009 I think, I was really surprised when I learnt it wasn't implemented
[13:49] <jojva> I guess it's because 3D is a dead fish
[13:49] <jojva> not the good expression, I meant it's dead before it was born
[13:51] <durandal_1707> i dont think 3d is dead
[13:54] <jojva> it's tiring, some people can't see it, it's more expensive for a 'meh' result...
[13:54] <av500> one eyed people cannot see it
[13:54] <av500> the whole real world is wasted on them
[13:54] <jojva> poor cyclops
[13:55] <durandal_1707> when was last time you go to cinema?
[13:55] <cone-938> ffmpeg.git 03Anton Khirnov 07master:7cec12748a37: FATE: add a test for the gradfun filter
[13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:a222997650eb: FATE: add a test for the boxblur filter
[13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:feb4922b257e: FATE: add a test for the drawbox filter
[13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:1a6d4bd7b607: FATE: add a test for the fade filter
[13:56] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:6f1a6a9f6ba0: Merge commit '1a6d4bd7b60761bd7d955011ce7df4dd6b87b497'
[13:56] <jojva> Django but it was 2D
[13:57] <nevcairiel> i saw a 3d movie 2 weeks ago, and maybe the cinema i go to just sucks, or its an inherent 3d problem, but i think it just looks terribly blurry
[13:57] Action: nevcairiel prefers a 2D screening any day
[13:57] <durandal_1707> perhaps you hand poor glasses
[13:57] <nevcairiel> whatever glasses they hand out
[13:58] <nevcairiel> in fact, another 3d movie tonight
[13:58] <durandal_1707> or maybe your left and right have different zooming
[13:58] <jojva> I'm just hoping we'll arrive soon to hologram cinemas, this will be actual, real, beautiful 3d, but when ?
[13:58] <nevcairiel> i actually bought my own glasses now because theirs are terribly uncomfortable as well, maybe it'll be better
[13:58] <ubitux> michaelni: are there some more stuff to merge in tests/fate/filter.mak or i can start updating our tests with the dep helpers in it?
[13:59] <durandal_1707> ubitux: gonna write test for other filters?
[13:59] <ubitux> i plan to add a video output test for ebur128 but that's all
[14:00] <ubitux> but i'd like to use the filter macro helper in that file to start with
[14:00] <michaelni> ubitux, a few more to merge left
[14:00] <ubitux> michaelni: ok
[14:01] <ubitux> michaelni: can you nudge me when you're done with it?
[14:01] <ubitux> (there is no hurry)
[14:03] <michaelni> ubitux, ok
[14:06] <ubitux> thx :)
[14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:ad85e8d9a5bb: FATE: add a test for the unsharp filter
[14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:0bdbd85e47f2: FATE: add a test for the transpose filter
[14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:71f3ede24e8c: FATE: add a test for the hqdn3d filter
[14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:ea290d919a52: FATE: add a test for the setpts filter
[14:10] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:8823ec4f9e92: Merge commit 'ea290d919a52f0f8c7e30d69328bb011ed13f61a'
[14:18] <durandal_1707> there is no api to draw font in lavfi?
[14:18] <durandal_1707> ebur128 does something on its own
[14:22] <ubitux> yes it's using an exported charmap 
[14:22] <ubitux> there are one or two functions available, but they couldn't be used in this case
[14:26] <ubitux> durandal_1707: the other solution was to use fontconfig and stuff just like drawtext
[14:27] <ubitux> but it was a real pain
[14:27] <ubitux> totally overkill :p
[14:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:3d8c80b611aa: FATE: add a test for the overlay filter
[14:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:f91742037863: FATE: add a test for the negate filter
[14:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:33942b7bdeda: FATE: add a test for the channelmap filter
[14:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:43a8333a16c7: FATE: add a test for the channelsplit filter
[14:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7a14564b2d4d: Merge commit '43a8333a16c796b3d855fb3aaa742103cb62731f'
[14:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:acaee26008c1: af_channelsplit: set output channels, fix assertion failure
[14:56] <ubitux> it would be nice to have a AV_OPT_TYPE_BOOL..
[14:57] <Plorkyeran>  @ubitux> wm4: we should also not ever add frame seeking in ffmpeg because ffms2 has this feature, and it will kill it if we add the feature to ffmpeg? <-- as the activest developer of ffms I would be fucking delighted if I could delete 90% of it and leave just a thin wrapper for a better API
[14:58] <ubitux> :)
[14:58] <wm4> so will we get that exact frame seeking?
[14:58] <Plorkyeran> killing other projects by making them redundant is great as long as they're not just replaced by something worse that isn't quite bad enough to be unusable
[14:59] <durandal_1707> wm4: once you send patch
[14:59] <wm4> k
[14:59] <ubitux> Plorkyeran: any reason you didn't try to integrate the feature to ffmpeg?
[14:59] <wm4> ffms2 also provides a stable API AFAIK
[14:59] <Plorkyeran> at the minimum it'd require completely rewriting it since it's C++
[15:00] <Plorkyeran> and I don't particularly like writing C
[15:00] <ubitux> ok
[15:00] <Plorkyeran> and contributing a new higher-level API to ffmpeg seems like a good way to get stuck in bikeshed hell
[15:00] <ubitux> Plorkyeran: how much code does it represent approximately?
[15:01] <Plorkyeran> not a ton
[15:01] <TheFluff> it's probably less than 10k lines
[15:01] <Plorkyeran> cloc says 7.6k code, ignoring avisynth/vapoursynth plugins
[15:01] <TheFluff> probably less than 5k even if you only count the really relevant stuff
[15:01] <TheFluff> right
[15:02] <TheFluff> does that count matroskaparser.c?
[15:02] <TheFluff> because that's like 2-3k right there
[15:02] <ubitux> it supports frame seeking in any formats?
[15:02] <Plorkyeran> yeah
[15:02] <Plorkyeran> 2.7k
[15:02] <Plorkyeran> so more like 5k
[15:03] <ubitux> so there is a generic frame seeking, and dedicated code for some formats?
[15:03] <ubitux> afaik the api is ready to have frame seeking; it just needs to be implemented in formats
[15:03] <ubitux> but i may be missing something
[15:03] <TheFluff> there's a complete matroska parser in there, for historical reasons
[15:03] <Plorkyeran> there's format-specific stuff for mkv and vp8
[15:03] <Plorkyeran> the mkv stuff may not actually be a good idea anymore
[15:03] <TheFluff> yeah
[15:03] <ubitux> nothing specific for mpeg and avi?
[15:04] <nevcairiel> but it implements this by re-indexing all the data, doesn't it?
[15:04] <TheFluff> there's also an interface to a directshow mpeg ts/ps parser
[15:04] <TheFluff> and ogg
[15:04] <Plorkyeran> it indexes the video, and fully decodes the audio
[15:04] <ubitux> this looks like a pretty appropriate GSoC task to me
[15:04] <ubitux> i wonder if we still have time to add it
[15:04] <TheFluff> for video only, maybe
[15:05] <Plorkyeran> yeah, the video stuff is relatively straightforward
[15:05] <Plorkyeran> audio basically requires fixing all of the decoders
[15:05] <TheFluff> trying to do format-agnostic sample accurate seeking in audio with ffmpeg is an exercise in futulity
[15:05] <TheFluff> futility*
[15:05] <Plorkyeran> since most of them don't give the slightest fuck about accurate seekability
[15:06] <Plorkyeran> which is sort of reasonable as no one will actually notice the first 1k samples after a seek being slightly wrong
[15:06] <TheFluff> https://code.google.com/p/ffmpegsource/source/browse/trunk/src/core/audiosource.cpp <-- just read the comments in this file
[15:07] <ubitux> too bad so much effort wasn't done in ffmpeg to start with, but well too late
[15:09] <TheFluff> the effort required in ffmpeg would require different skills
[15:09] <TheFluff> it'd require reading and understanding how the decoders actually work
[15:09] <TheFluff> for a bunch of different decoders
[15:10] <TheFluff> adding this kind of hack on top of the api would most likely never get accepted
[15:10] <TheFluff> but on the other hand it can be done without knowing stuff about codec internals
[15:12] <TheFluff> the video stuff on the other hand is pretty straightforward; it reads the file, stashes the pts/dts data and some other interesting stuff in an index and then just fakes it 'til it makes it
[15:13] <TheFluff> it's maybe 1k lines of code total
[15:21] <ubitux> ok
[15:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:9e9cd98aed5c: FATE: add a test for the volume filter
[15:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:8a2f5f0c6372: FATE: add a test for the join filter
[15:35] <cone-938> ffmpeg.git 03Alexandra Khirnova 07master:0afcf97e1ece: vmdav: convert to bytestream2
[15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:37bdf33cffd2: Merge remote-tracking branch 'qatar/master'
[15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e0dd8cadcc38: af_join: fix channel count and format
[15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e14f8bd07ef7: fate: Disable af_join test, as its output is not deterministic currently
[15:35] <michaelni> ubitux, merge done
[15:36] <ubitux> michaelni: ok thx
[15:37] <michaelni> ubitux, also do you want to look at  af_join  (fate issue) ?
[15:37] <ubitux> no, libav is on it
[15:37] <ubitux> i let them deal with it
[15:38] <michaelni> ok, even better, i like it when libav is working for me :)
[15:38] <ubitux> don't tell it that loud or they will keep it broken just to piss you off
[15:52] <ubitux> mateo`_: if later the extradata needs to be changed (to add some information or such), it will break with unmatching lavc and lavf version
[15:52] <ubitux> isn't it possible to make more information in that extradata?
[15:52] <ubitux> like the complete header section if not big
[15:54] <mateo`_> ubitux: which header setion ?
[15:57] <ubitux> well, the whole descriptor for instance
[15:57] <ubitux> if it makes sense
[15:57] <ubitux> (or maybe just the id of the desc and share it if hardcoded?)
[15:58] <durandal_1707> are you deinterlacing in decoder?
[16:09] <durandal_1707> ubitux: so true peak pm is missing in ebur128, why it was not implemented?
[16:09] <ubitux> i have a branch for it
[16:10] <ubitux> durandal_1707: i'm still not decided how to print it visually so...
[16:10] <ubitux> and i want to get done with the normalization
[16:10] <ubitux> durandal_1707: https://github.com/ubitux/FFmpeg/commit/ebbdf552627f4c0aa2a1a10b3e81d06efae2b9f7
[16:10] <ubitux> need to be rebased on head
[16:11] <ubitux> i'll do it when the live normalization is done
[16:16] <durandal_1707> i added some colors to "phasescope" - i still not sure how to name this filter, or perhaps split it into several filters
[16:18] <ubitux> phasescope is not good?
[16:19] <GRMrGecko> Whenever I compile FFmpeg 1.2 for i386, I'm getting the error "./libavcodec/x86/dsputil_mmx.h:31: error: redefinition of struct xmm_reg"
[16:20] <mateo`_> durandal_1707: i'm reconstructing the full frame within the decoder.
[16:20] <ubitux> GRMrGecko: please go to #ffmpeg for user questions
[16:20] <GRMrGecko> ok
[16:20] <ubitux> GRMrGecko: and try to make distclean and run ./configure again
[16:20] <durandal_1707> ubitux: there are at least 2 different meters: balance and correlation
[16:21] <ubitux> durandal_1707: "audiometers" then maybe
[16:21] <ubitux> or simply "ameters"
[16:25] <cone-938> ffmpeg.git 03Giorgio Vazzana 07master:b97f7d9d2432: lavd/v4l2: replace ioctl() with v4l2_ioctl()
[16:25] <cone-938> ffmpeg.git 03Giorgio Vazzana 07master:5009863ab5a4: lavd/v4l2: fix printing of list_formats table
[16:33] <durandal_1707> what volume meter is actually useful?
[16:40] <GRMrGecko> libavcodec/x86/dsputil_mmx.h line 31 should be "typedef struct { uint64_t a, b; } xmm_reg;"
[16:41] <ubitux> GRMrGecko: for 1.2 right?
[16:41] <ubitux> what about git/master?
[16:41] <GRMrGecko> ubitux: yes
[16:41] <GRMrGecko> I don't know...
[16:41] <GRMrGecko> Let me look
[16:43] <GRMrGecko> (I don't have it cloned yet, so give me a minute)
[16:46] <GRMrGecko> ubitux: I don't even see it being defined in the master.
[16:46] <ubitux> does it build?
[16:46] <GRMrGecko> I'll try compiling the master to see the result
[16:48] <GRMrGecko> ubitux: It was moved to ./libavutil/x86/asm.h:27
[16:48] <GRMrGecko> testing my fix
[16:50] <ubitux> where was it first defined?
[16:50] <GRMrGecko> ./libavcodec/x86/dsputil_mmx.h:31
[16:51] <GRMrGecko> that was in 1.2
[16:51] <ubitux> i mean why does it complain on redefinition?
[16:51] <ubitux> where is it already defined?
[16:52] <GRMrGecko> ubitux: On the same line. "typedef struct xmm_reg { uint64_t a, b; } xmm_reg;" vs "typedef struct { uint64_t a, b; } xmm_reg;"
[16:52] <ubitux> it's not the same
[16:53] <ubitux> one is the struct name and the other the typedef name
[16:53] <ubitux> a struct xmm_reg might exists somewhere else
[16:53] <GRMrGecko> yet, it's a redefinition of the same name. You're defining both the struct and the type with the same name.
[16:54] <ubitux> that's not a problem
[16:54] <ubitux> since the struct needs the struct prefix to be used
[16:54] <ubitux> that's legal C
[16:54] <GRMrGecko> don't know why GCC 4.2 complains then,
[16:54] <ubitux> [~]- cat a.c
[16:54] <ubitux> typedef struct foo { int a; int b; } foo;
[16:54] <ubitux> [~]- gcc -Wall -Wextra -c a.c
[16:54] <ubitux> [~]-  
[16:55] <ubitux> it's perfectly valid
[16:55] <ubitux> GRMrGecko: my guess is that the struct xmm_reg is already defined in another header
[16:55] <ubitux> what is the full error?
[16:55] <GRMrGecko> hold on
[16:57] <SenGlar> hi, i need to know if it is possible to set the encoding audio frame size to another size a little bit larger. For example, using 48kHz 2ch S16, the frame size should be 4096Bytes, but I'm getting from a camera a size of 7680. It is possible to encode such size per frame?
[16:57] <GRMrGecko> SenGlar: I think you should be asking in #ffmpeg
[16:58] <SenGlar> thanks, I was not shure where to ask this kind of question, I've done it there also! 
[16:59] <GRMrGecko> ubitux: http://p.webra.in/dn
[17:00] <ubitux> pullup oh shit :)
[17:00] <GRMrGecko> ubitux: http://p.webra.in/dj
[17:00] <ubitux> (git grep is your friend)
[17:01] <GRMrGecko> git grep? Never knew of that
[17:01] <GRMrGecko> returns the same thing
[17:01] <ubitux> yes sure
[17:01] <ubitux> it smells like a double include somewhere
[17:01] <GRMrGecko> maybe
[17:02] <GRMrGecko> ubitux: Isn't #ifndef AVUTIL_X86_ASM_H suppose to stop that?
[17:02] <ubitux> yes
[17:04] <ubitux> you say it's reproducible with --arch=i386?
[17:05] <GRMrGecko> ubitux: Let me give you the command I run for x86_64
[17:07] <ubitux> i just built with ./configure --enable-gpl --arch=i386
[17:07] <ubitux> and it worked fine
[17:07] <ubitux> are you sure it's not a compiler bug?
[17:07] <ubitux> can you try with --cc=clang or whatever?
[17:07] <GRMrGecko> x86_64 http://p.webra.in/d8
[17:07] <GRMrGecko> i386 http://p.webra.in/d1
[17:08] <ubitux> i just realized that's mac os
[17:08] <ubitux> maybe that's the problem ;)
[17:08] <GRMrGecko> :P
[17:08] <GRMrGecko> maybe I need --target-os=darwin
[17:13] <ubitux> michaelni: "fate-filter-gradfun-ubitux" is really cute
[17:13] <durandal_1707> what, not that nonsense again
[17:13] <ubitux> durandal_1707: i asked him to keep them, i'm working on it
[17:13] <durandal_1707> drop one with less coverage or rename test
[17:14] <durandal_1707> i dont want decoder/encoders/filters/test/documentation/random file with alex/clark/denzel/elviss/tux/god/sam/joe/jane name in it
[17:15] <ubitux> you forgot speedy gonzales
[17:16] <durandal_1707> if you have so little creativity to name things, ask me first
[17:17] <durandal_1707> ubitux: there is such file?
[17:18] <ubitux> no but there is such author
[17:19] <GRMrGecko> ubitux: It seems to just be the fact that it is i386 vs x86_64& I tried making the same exact command, just changing from i386 to x86_64& i386 doesn't build, but x86_64 does.
[17:20] <GRMrGecko> and it's just that one line that stops the build.
[17:24] <GRMrGecko> ubitux: Maybe it's something the configure script changes with the GCC command?
[17:24] <ubitux> i don't know; check with a make V=1
[17:25] <GRMrGecko> ok
[17:34] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:27b7bfc7b5be: avidec: Fix demuxing of non seekable avis with multiple RIFFs
[17:36] <GRMrGecko> found SDL isn't compiled for i386& Maybe that is the issue? I doubt it& But I'll check
[17:45] <cone-938> ffmpeg.git 03Clément BSsch 07master:ac00755e0af6: fate/filter: stick delogo test with its deps (cosmetics).
[17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:4694af108842: fate/filter: rename 'ubitux' rules to 'sample'.
[17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:7f19fc99e0aa: fate/filter: remove pointless indirections for gradfun and hqdn3d.
[17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:b1213c911c53: fate/filter: move some CMD below deps for consistency.
[17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:0adc93ba2b4c: fate/filter: move concat filtergraph to a dedicated script.
[17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:ef4020ca7dd4: fate/filter: move gradfun filtergraph to a dedicated script.
[17:46] <GRMrGecko> ubitux: Determined the issue to be "-mmacosx-version-min=10.4" vs "-mmacosx-version-min=10.5"
[17:47] <GRMrGecko> gcc probably changes the way it works when you say you're building for 10.4
[17:49] <GRMrGecko> I can possibly just have a patch to fix this issue when building for 10.4.
[17:50] <ubitux> no idea, i never touched a mac os
[17:53] <ubitux> Daemon404: you were looking at overlay because of the fate failure?
[17:53] <ubitux> it's likely because sws_flags are not set to bitexact
[17:53] <ubitux> in ./tests/filtergraphs/overlay
[17:55] <cone-938> ffmpeg.git 03Clément BSsch 07master:dd17843b8ab3: fate/filter: make overlay test bitexact.
[17:56] <ubitux> hopefully it will calm down fate
[20:57] <Bor0> what exactly does "crippled build" mean when specifying --disable-yasm?
[21:11] <michaelni> it means it will be very slow, you want to install yasm if you intend to "use" that build
[21:20] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:92002db3eb43: h264_refs: Check for attempts to assign pictures to short & long.
[22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:76e6b1eba1fe: wmv2: Use emu edge mode when the edge is too small
[22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:8fc52a5ef947: wmv2: drop non emu edge mode
[22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:3969b4b861ce: gmc: Always use edge emu
[23:47] <jommy> hello
[23:52] <michaelni> hallo
[23:54] <jommy> do you know of a bug in avformat/oggdec.c where start_granule is never set?
[23:55] <jommy> hence the starting timestamp is always zero
[00:00] --- Fri Mar 29 2013