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

[burek]

[00:06] <ubitux> erm, all the drawutils subsampling looks wrong
[00:24] <ubitux> http://pastie.org/7828756 
[00:24] <ubitux> i wonder if that will fix anything..
[00:45] <BBB> dct2d, you mean a denoiser through a higher-order dct with low q?
[00:45] <BBB> use libvpx' fdct/idct
[00:45] <BBB> michaelni: ^^
[00:46] <ubitux> yeah the purpose is a dct/idct denoiser
[00:46] <ubitux> cf dctdnoiz filter on the ml
[00:46] <ubitux> anyway, http://pastie.org/7828812  what should we prefer?
[00:47] <BBB> the question is which is faster when inlined
[00:48] <ubitux> oups forgot parenthesis
[00:48] <Skyler_> what is this code supposed to do?
[00:48] <BBB> Skyler_: rounded rightshift, looks like
[00:48] <BBB> e.g. a+1>>1 or a+2>>2 or a+4>>3 or a+8>>4
[00:48] <Skyler_> wouldn't that be x + (1<<(n-1)) >> n?
[00:49] <ubitux> http://pastie.org/7828825
[00:49] <ubitux> should be better ^
[00:49] <ubitux> it's an up rounding
[00:49] <BBB> Skyler_: ohright, then I guess it's a roundup rshift
[00:49] <Skyler_> ah
[00:49] <Skyler_> Is n usually constant or not?
[00:49] <ubitux> it's often picked from the pix desc table
[00:49] <ubitux> so not often hardcoded
[00:49] <BBB> so it isn't
[00:49] <ubitux> happens sometimes though
[00:50] <BBB> I guess neg is faster then?
[00:50] <ubitux> i didn't bench, i guess i should
[00:50] <ubitux> we use the f1 form most of the time, but i see the f2 sometimes
[00:50] <Skyler_> line 13 seems completely redundant
[00:50] <ubitux> i moved the the f1 form into a macro used everywhere, but i was wondering if it couldn't be changed to the second form
[00:51] <Skyler_> oh, I guess because it has to return
[00:51] <Skyler_> I think f1 is probably better?
[00:51] <ubitux> http://pastie.org/7828832  with llvm/clang
[00:51] <ubitux> mostly the same
[00:53] <BBB> if n is constant at compiletime, f2 is better, if n is not, f1 is better, I think
[00:54] <ubitux> ok
[00:54] <Skyler_> I agree
[00:54] <BBB> neg/sar/neg vs add/sar if n is constant, vs. neg/sar/neg vs mov/shl/lea/sar if n is not constant, in a typical inline implementation
[00:54] <BBB> but sometimes compilers can do special tricks that are way beyond my skills :)
[01:15] <iive> ubitux: I've used spp as denoiser too, it is quite good and could improve mpeg1/2/4 compression with up to 30% without any visible quality loss. (using forced quant of 2)
[01:16] <ubitux> i'll consider porting it tomorrow then
[01:16] <iive> i think i did not got so good results with h264, maybe using h264 8x8 transform would give better results.
[01:17] <ubitux> isn't libx264 able to perform such pre-filtering?
[01:18] <iive> no idea.
[01:18] <Skyler_> spp uses overlapped transforms which is kind ofwhy it's good
[01:18] <iive> spp however is quite slow because it does multiple forward and inverse tranformations, not only on block locations, but also with different offsets.
[01:18] <Skyler_> if you want something fast, try fft3dgpu maybe?
[01:19] <ubitux> if spp is slow, i wonder what dctdnoiz is :(
[01:19] <iive> fspp is supposed to be faster, as it does overlapped 1d tranforms.
[01:41] <ubitux> BBB, Skyler_: i just benched, and you were right
[01:42] <BBB> oh you benched it? that's kinda nice
[01:42] <Compn> what about uspp ? :P
[01:43] <ubitux> BBB, Skyler_: http://pastie.org/7828968
[01:43] <ubitux> hopefully my bench is not flawed
[01:44] <BBB> that looks rational
[01:44] <BBB> maybe disass to confirm, but I'd be surprised if a compiler unrolled that first one
[01:44] <ubitux> oh wait..
[01:45] <ubitux> BBB: it can't, it's a user arg
[01:45] <BBB> oh right
[01:45] <BBB> sweet
[01:45] <BBB> didn't notice that
[01:45] <BBB> ok yes that looks sane
[01:46] <BBB> results look sane also
[01:46] <ubitux> yep
[01:46] <BBB> what max_shift did you use?
[01:46] <ubitux> 13
[01:46] <ubitux> (i doubt a chroma subsampling will go up to that value though)
[01:46] <ubitux> BBB: want a patch to test?
[01:46] <Compn> did anyone ever have plans to convert all codecs/functions to yasm , even using gcc compiled asm to do it? and test if its faster ? i mean, if you convert all the code via machine and get 10% speedup... its worth it ?
[01:47] <BBB> ok so 2 vs 3 cycles per iteration roughyl for const
[01:47] <BBB> and then roughly 4 cycles for non-const
[01:47] <BBB> I guess that makes sense
[01:47] <ubitux> http://b.pkh.me/0001-rshift-test.patch
[01:47] <ubitux> make libavutil/ceilrshift-test && ./libavutil/ceilrshift-test 2 13
[01:48] <ubitux> (yes i know there is likely simpler way to bench but i like that way :p)
[01:48] <Daemon404> unrelated: ... did anyone ever test teh vid.stab filter?
[01:48] <iive> Compn: in theory different CPU have different optimization/scheduling opportunities, so the compiler is supposed to know them better.
[01:49] <Daemon404> it fucks up everything (green bars, distrted images etc)
[01:49] <BBB> lol
[01:49] <BBB> ok back to vacation
[01:49] <Daemon404> enjoy.
[01:49] <ubitux> Daemon404: yeah i tried it, it mostly works, but there was a bug with ffplay
[01:49] <Daemon404> ubitux, all 10 sampels i tried it with fucked up
[01:49] <ubitux> i'll nudge the guy again
[01:49] <Daemon404> in epic ways
[01:49] <iive> Compn: in practise, only P4 was so horrible that it was slower with existing optimized code.
[01:49] <ubitux> Daemon404: strange, it worked with 2-3 videos i tried
[01:50] <Daemon404> i also used teh defaults
[01:50] <Daemon404> so it wasnt me mucking with settings
[01:50] <ubitux> Daemon404: it needs to be ported natively anyway...
[01:50] <Daemon404> well
[01:50] <Daemon404> i disagree
[01:50] <Daemon404> but i know you guys and your NIH
[01:50] <Compn> lol
[01:50] <ubitux> Daemon404: honestly, there is not much code, and a lot of code in the lib could benefit from out optims
[01:50] <Compn> no one uses external filters. but i dont see why we should reinvent that wheel :P
[01:50] <Daemon404> ubitux, and then promptly never updated again
[01:51] <Daemon404> while teh upstream filters moves on
[01:51] <Daemon404> as per usual
[01:51] <ubitux> if ffmpeg integrates it properly the lib will die
[01:51] <Daemon404> the guy seems to care about 'transcoder'
[01:51] <ubitux> Daemon404: they seem to have not much clue anyway
[01:51] <Compn> iive : you're saying gcc compiled C is better or the same as asm  then ?
[01:51] <Daemon404> 'they' = ?
[01:51] <ubitux> the vid stab guy(s?)
[01:51] <Daemon404> guy.
[01:51] <Compn> iive : i mean, did anyone ever test it ? or lately ?
[01:52] <iive> Compn: i said, in theory.
[01:52] <ubitux> Daemon404: just have a look to the code, that's likely simpler than porting vivtc
[01:52] <Daemon404> heh
[01:52] <Daemon404> tehres no point anyway
[01:52] <Daemon404> if it doesnt even work
[01:52] <iive> Compn: it is hard to maintain complex code written in assembler.
[01:52] <ubitux> Daemon404: possibly just a bug
[01:52] <ubitux> :)
[01:52] <Compn> iive : only talking about speed here
[01:52] <Daemon404> ubitux, multiple bugs
[01:52] <Compn> i know its complex 
[01:52] <ubitux> Daemon404: yeah right
[01:52] <Daemon404> it fucks up in multiple ways
[01:52] <Daemon404> ;)
[01:53] <ubitux> Daemon404: well, open an issue, i'll nudge the maintainer
[01:53] <Compn> ubitux : Daemon404 doesnt report bugs
[01:53] <Daemon404> ill do it tmr then
[01:53] <ubitux> and threat a remove of the filter if he doesn't do anything
[01:53] <ubitux> :)
[01:53] <Daemon404> i am too lazy to connect to vpn to dl some samples
[01:53] <Daemon404> right now
[01:53] <ubitux> anyway, it worked for my use case
[01:53] <ubitux> please don't forget :)
[01:53] <iive> Compn: but e.g. cmov is quite trivial optimization for i686 cpus. the compiler would use it every time it could. You'd have to use #if #else in the code for it, or use macro... 
[01:53] <Daemon404> maybe i should invest in onenote
[01:53] <ubitux> i'm still waiting for your hudgez mp4 crashing sample
[01:54] <ubitux> ;)
[01:54] <Daemon404> mp4 crashing?
[01:54] <ubitux> or fp except 'don't remember
[01:54] <ubitux> you add an issue with a mp4/mov a while ago
[01:54] <Compn> a 6gb sample ?
[01:54] <Compn> or 4gb ?
[01:54] <Daemon404> let me check trac
[01:54] <ubitux> it was on irc
[01:55] <Daemon404> o
[01:55] <Compn> iive : i just want someone to test my theory of machine compiled asm vs c :P
[01:55] <Daemon404> ive sent most of my sampes to michaelni 
[01:55] <Daemon404> privately
[01:55] <Daemon404> maybe it was one of those
[01:55] <Daemon404> theres no outstanding issues with mp4 atm for me
[01:56] <iive> Compn: then i didn't get your theory. c compiler compiles to assembler and then the assembler is compiled to binary.
[01:59] <Compn> iive : i mean, convert c to asm, then use yasm to make it a binary
[01:59] <Daemon404> ... this all sounds retarded
[01:59] <iive> there shouldn't be any difference.
[02:00] <Compn> well thats my theory :P
[02:00] <Compn> that there may be a diff
[02:00] <Daemon404> ... then that would be an asembler bug
[02:00] <iive> there might, but it is mostly using short vs long versions, mostly for jump.
[02:00] <Daemon404> protip: assembles dont change the code
[02:00] <Daemon404> because there is nothing to change. they dont compile anything.
[02:00] <Daemon404> asslmbers*
[02:03] <Compn> well then my theory is bunk
[02:03] <Compn> :)
[02:04] <Compn> maybe i meant use different compilers to compile the same code, and compare asm cpu cycles, then take the best compiled asm and make it .asm so that the compiler cant mess it up
[02:04] <iive> Compn: btw, wine uses gcc to compile .c -> .asm and then if it finds llvm assembler it uses it for .asm->.o
[02:04] <Compn> forget it, too hard to explain :)
[02:04] <Compn> and i havent a clue what i talk about
[02:05] <iive> you want 2 compiler to compete at code generation.
[02:05] <Compn> yes
[02:45] <Compn> where are we at on that rar demuxer ?
[02:45] <Compn> :)
[03:10] <ubitux> michaelni: oh nice av_builtin_constant_p!
[10:36] <cone-272> ffmpeg.git 03Stefano Sabatini 07master:edc05698aaab: doc/filters: sort audio filters by name
[10:36] <cone-272> ffmpeg.git 03Stefano Sabatini 07master:90d35e527be3: doc/filters: remove duplicated abuffer docs
[11:19] <ubitux> saste: why is overlay not using ff_blend_mask()?
[11:20] <saste> ubitux, ff_blend_mask() was added *after* overlay
[11:20] <saste> also I suspect that the overlay blend is more sophisticated
[11:20] <saste> i agree that we should factorize that code
[11:21] <ubitux> it would be nice
[11:21] <ubitux> then export the useful bits
[11:21] <ubitux> and then omg-optimize
[11:22] <saste> sure
[11:22] <saste> well i'm working on zmq, and i don't plan to work on that soon
[11:22] <ubitux> :(
[11:25] <saste> zmq is getting ugly, after the messaging API addition...
[12:44] <ubitux> is there a wiki page were we can throw filter ideas?
[12:44] <ubitux> i have a bunch of tabs open with filters i'd like to see eventually implemented
[12:45] <durandal_1707> ffmpeg.org/trac/wiki
[12:45] <durandal_1707> or report bug
[12:45] <ubitux> well, i have likely 5 or 6 filters in my tabs
[12:46] <durandal_1707> so create bugs
[12:46] <ubitux> and some might not be relevant
[12:46] <ubitux> so i'd better make a list somewhere in the wiki
[12:46] <durandal_1707> ok, list them here
[12:46] <ubitux> don't we have a "what to do on ffmpeg?" page somewhere?
[12:47] <durandal_1707> yes, small ffmpeg tasks
[12:47] <Compn> are we supposed to use that page ?
[12:47] <durandal_1707> it mentions filters too
[12:47] <ubitux> oh well i'll open tickets
[12:47] <Compn> open tickets is good :)
[12:48] <Compn> then we can ignore them in the trac 
[12:48] <Compn> eheh
[12:48] <ubitux> do you see interesting filters in here? http://www.ipol.im/
[12:48] <ubitux> afaict there are a bunch of interesting ones
[12:48] <ubitux> (that's from where dctdnoiz comes from)
[12:49] <ubitux> is http://www.iptech-group.com/blog/locating-interesting-parts-of-an-image relevant as feature request?
[12:50] <durandal_1707> just open tickets, give cehoyos some food
[12:50] <ubitux> haha
[13:16] <ubitux> there is a bug in format negociation
[13:16] <ubitux> ./ffplay -f lavfi testsrc -vf 'scale=320:240, split[a][b]; [a]pad=iw*2[x]; [b]edgedetect[y]; [x][y]overlay=w'
[13:17] <ubitux> testsrc ’ gray only
[13:17] <ubitux> if i remove the scale it's fine
[14:11] <durandal_1707> ubitux: that also happens with ffmpeg?
[14:11] <ubitux> yes
[14:25] <saste> ubitux: now I need to assign an id to each specified filter
[14:26] <ubitux> ?
[14:26] <saste> ffplay -f lavfi "color=s=100x100:c=red [l]; color=s=100x100:c=blue [r]; nullsrc=s=200x100, zmq [bg]; [bg][l]overlay[bg+l]; [bg+l][r]overlay=x=100"
[14:26] <saste> suppose that you want to change only the left, or the right color
[14:26] <saste> how can you do it?
[14:27] <saste> right now i think it is possible to use the automatic name (parsed_color_1 or whatever)
[14:27] <saste> but 1. this is not documented anywhere
[14:27] <saste> 2. it's pretty awkward, since it depends on the parsing internals
[14:28] <ubitux> color#c0=s=100... ?
[14:28] <saste> ubitux: another option is:
[14:28] <saste> color=id=left-color:s=100...
[14:28] <saste> that is I could use a common option
[14:29] <ubitux> ah, generic option, right :)
[14:29] <ubitux> i almost forget i added them
[14:29] <ubitux> btw, "Parsed_..." is ugly
[14:30] <ubitux> saste: can you have a look to the first patch of timeline patchset when you have a minute btw?
[14:30] <saste> ok
[14:30] <saste> let me send the updated zmq patches
[14:30] <ubitux> i'd like not to wait too much since i'm going to change the api
[14:30] <ubitux> yep sure, thanks
[14:49] <saste> ubitux:  lavfi: remplace passthrough_filter_frame with a flag.?
[14:50] <ubitux> yes
[14:50] <ubitux> i posted an updated version
[14:51] <durandal_1707> real scripting nowhere in horizont?
[15:59] <ubitux> saste: any suggestion? :(
[15:59] <ubitux> "generic" : avfilter.c will call filter_frame() of the next filter
[15:59] <ubitux> "internal" : the filter itself deals with the timeline
[16:11] <durandal_1707> there is like twice more video filters than audio ones
[16:15] <ubitux> that's because there is twice dimensions
[16:23] Action: ubitux fucking hate gnuplot's syntax
[16:35] <michaelni_> av500, i have some problems with my panda board
[16:35] <michaelni_> or maybe rather several power supplies
[16:36] <michaelni_> the first that i used since a year died (gives 0 volts now) and the replacement just today died too (gives 5v but only when not connected)
[16:37] <michaelni_> i was "smart" enough to buy 2 new 4A 5V supplies from watterot so i still have 1 that i use now
[16:37] <michaelni_> but its a bit odd
[16:37] <michaelni_> theres nothing connected to the board except power, network & previously serial too
[16:38] <michaelni_> no usb devices
[16:53] <saste> ubitux: or you may call SUPPORT_TIMELINE, and SUPPORT_TIMELINE_INTERNAL the second variant
[16:53] <ubitux> like the original patch then
[16:53] <ubitux> but it was a bit long
[16:54] <saste> really, why people are concerned with long names, as they would spend their time typing rather than deciphering logic?
[16:55] <saste> drawgrid is equivalent to drawbox
[16:55] <saste> should we keep drawbox anyway?
[16:59] <cone-356> ffmpeg.git 03Michael Niedermayer 07master:efaa2e01e6d2: vf_copy: silence "incompatible pointer type" warning
[16:59] <ubitux> saste: i was concerned about the long name when i saw i had to write: !(dstctx->filter->flags & (AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL^AVFILTER_FLAG_SUPPORT_TIMELINE))
[17:00] <saste> ubitux: define a convenience macro ;-)
[17:00] Action: saste runs
[17:00] <ubitux> :)
[17:01] <ubitux> saste: i'd better redefine drawbox into drawgrid
[17:01] <ubitux> and as a second patch
[19:17] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:bb0d3a439394: avfilter/vf_mp: remove unused function
[19:17] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:44f69c0df8c1: avfilter/af_astats: fix 64bit printf type
[20:51] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:69cfe63a43f4: ffv1: Switch to ThreadFrame
[20:51] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:54602590d9e4: ffv1enc: Check the return value of ffv1_common_init()
[20:51] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:a0c0900e470f: ffv1dec: Support frame threading with gop > 1
[20:51] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:19411d32d409: ffv1enc: dont set coded_frame
[21:22] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:bd63f8f6574d: ffv1enc: Fix memleak
[21:31] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:b8a2331a70b7: ffv1: check for malloc failure.
[21:37] <cone-605> ffmpeg.git 03Michael Niedermayer 07master:9a2153894f23: ffv1enc: fix 1000l typo
[22:59] <ubitux> michaelni_: the --enable-shared seems indeed to cause issue with vc1
[22:59] <ubitux> but well, gcc 4.8 :)
[22:59] <ubitux> it's likely a gcc bug, but do you want me to try something in particular?
[23:01] <ubitux> note that valgrind doesn't complain
[23:02] <ubitux> michaelni_: here are the artifacts: http://lucy.pkh.me/vc1-gcc48-shared.nut
[23:02] <ubitux> that's particularly visible around 4 sec
[23:37] <michaelni_> ubitux, you could try -cpuflags 0 
[23:41] <ubitux> michaelni_: same
[00:00] --- Sun May 12 2013