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

[burek]

[00:53] <ubitux> http://www.iquilezles.org/blog/?p=2177
[01:08] <cone-735> ffmpeg.git 03Clément BSsch 07master:b8a5c7613194: lavfi: add frame counter into AVFilterLink and use it in filters.
[01:08] <cone-735> ffmpeg.git 03Clément BSsch 07master:fdd93eabfb26: lavfi: add timeline support.
[01:08] <cone-735> ffmpeg.git 03Clément BSsch 07master:38853169ce49: lavfi: add 'enable' command injection to filters supporting timeline.
[01:08] <cone-735> ffmpeg.git 03Clément BSsch 07master:15d2f2699890: lavfi/overlay: support timeline through the new system.
[01:18] <ubitux> michaelni_: your opinion on vid.stab?
[01:47] <michaelni_> ubitux, my oppinion is if theres a maintainer and the code has no major issues then its probably a good idea, but you reviewed it i just took a quick look, you should know it better
[01:47] <michaelni_> than ,e
[01:47] <michaelni_> me
[01:48] <ubitux> ok
[01:48] <ubitux> thank you :)
[03:24] <highgod> Hi, how can I get the download statistics of ffmpeg?
[03:37] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:a9a537b154aa: avfilter/drawtext: add pict_type support
[08:33] <highgod>  Hi, all, I want to ask a question. how can I get the download statistics number of ffmpeg?
[09:47] <durandal_1707> we gonna keep another jpeg2000 decoder?
[10:25] <cone-623> ffmpeg.git 03Janne Grunau 07master:94660c35249e: threads: always call thread_finish_setup for intra codecs
[10:25] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:7c49c8b0ac30: Merge commit '94660c35249e11c53b9a9f0c2f85c4335b21eda7'
[10:37] <cone-623> ffmpeg.git 03Janne Grunau 07master:10f1a4d9bd82: jpeg2kdec: output is native endian AV_PIX_FMT_XYZ12
[10:37] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:5056cff12597: Merge commit '10f1a4d9bd8239ac64f364e0d3b6423c28230d6d'
[10:48] <michaelni_> durandal_1707, depends on features/bugs/speed/maintaince activity of the 2. If one is clearly better in all categories the other will be droped
[10:49] <durandal_1707> michaelni_: j2kdec is not bitexact at all at any level
[10:54] <michaelni> only the 9/7 dwt should be non bitexact as it uses floats
[10:56] <michaelni> also theres are 2 integer 9/7 dwts in our codebase
[11:11] <highgod> Hi, all, I want to ask a question. how can I get the download statistics number of ffmpeg?
[11:12] <cone-623> ffmpeg.git 03Diego Biurrun 07master:c1ad70c3cb05: x86: Move some conditional code around to avoid unused variable warnings
[11:12] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:0a73803c86f6: Merge remote-tracking branch 'qatar/master'
[11:13] <michaelni> highgod, i dont think theres a statistic, why do you ask ?
[11:14] <michaelni> you could look at the download statistics of other projects using ffmpeg though, like chrome, mplayer, vlc, ... if they have a public statistic
[11:15] <j-b> chrome and VLC should give you around 500 millions users
[11:16] <highgod> OK, thanks
[11:16] <j-b> then all your SmartTVs
[11:21] <highgod> OK, thanks
[11:24] <j-b> Hello BuxiNess 
[11:27] <BuxiNess> Hello, I'm the culpable for the new jp2K decoder :-)
[11:28] <michaelni> Hi BuxiNess :)
[11:31] <BuxiNess> Hello 
[11:34] <michaelni> BuxiNess, can you send a patch that adds you to MAINTAINERS ? (iam assuming you still want to maintain it)
[11:35] <BuxiNess> michaelni, yes this afternoon. I'm on DWT optimsation right now
[11:35] <michaelni> ahh, ok, float or integer dwt ?
[11:36] <BuxiNess> float 9/7 dwt in the begining
[11:36] <BuxiNess> Than int
[11:36] <michaelni> with int be careful, there are some pitfalls with precission and coefficient quantization IIRC
[11:37] <michaelni> that is simple scalar quantization of the float wavelet lifting coefficients to integers does not work very well
[11:38] <BuxiNess> michaelni, yes. I'm not sure bitexact method for 9/7 DWT is reaaly useful for playback .
[11:38] <BuxiNess> Usefull for regression test indeed
[11:38] <michaelni> yes
[11:39] <michaelni> also snow has a 9/7 integer dwt, might be a good idea to look at that
[11:39] <michaelni> maybe it could even be used with little changes for regression testing
[11:40] <BuxiNess> dirac also, but not with the same lifting steps AFAIK
[11:40] <michaelni> IIRC the snow DWT also uses a more efficient line permutation than there was in the j2k dwt but i might misrememeber 
[11:41] <michaelni> yes but if its just for regresison testing slightly different lifting coefficients might not be important
[11:41] <michaelni> for display to the user it would be a problem though (likely)
[11:43] <michaelni> but overall the snow and j2k 9/7 dwts should be quite similar, also see: http://guru.multimedia.cx/the-snow-wavelet/
[12:34] <ubitux> BuxiNess: if node is NULL tag_tree_decode will access stack[-1]
[12:34] <ubitux> maybe that's not possible in practice, but gcc complains
[12:34] <ubitux> libavcodec/jpeg2000dec.c:126:22: warning: stack[-1] may be used uninitialized in this function [-Wmaybe-uninitialized]
[12:34] <ubitux> maybe add a av_assert0(node) at the beginning of the function or something
[12:48] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:7a617d6c17d0: avcodec/x86/sbrdsp_init: disable using the noise code in x86_64 MSVC
[14:19] <ubitux> can anyone confirm me that this is not possible with avfft api? https://gist.github.com/ubitux/5442675
[14:20] <ubitux> (just a 2d fft)
[14:21] <ubitux> (output: https://gist.github.com/ubitux/5442713)
[14:27] <merbanan> ubitux: I confirm
[14:27] <ubitux> thanks :(
[14:28] <ubitux> well i'll write my filter with fftw for now
[14:28] <michaelni> ubitux, are you doing something different than 2x 1d ffts ?
[14:29] <ubitux> michaelni: not yet, it should just be row & cols 1d fft
[14:29] <michaelni> so where is the problem ?
[14:29] <ubitux> well i can make a "slow" version with av fft api though if necessary
[14:30] <michaelni> why slow ?
[14:30] <ubitux> i guess the memcpy/transpose might be a bit slow, or i'm wrong?
[14:30] <michaelni> yes likely 
[14:30] <ubitux> that's what i had in mind, unless you think of something else?
[14:31] <merbanan> if the transform is separable then a 1d is faster
[14:31] <michaelni> it should be seperable if i understand correctly what ubitux does
[14:32] <michaelni> but a dedicated optimized transform would likely be faster
[14:33] <ubitux> i'm mostly just trying experiments; the goal is to allow eval() filtering on 2d-transformed blocks
[14:33] <ubitux> i've no idea if it's relevant or not
[14:33] <ubitux> but i need 2d fft anyway, and don't plan to mess up much with fft optims :p
[14:33] <pengvado> for instance, a single 1d fft requires some shuffles in the inner loop, whereas 4 simultaneous 1d ffts can avoid that by packing 1 value from each block into a xmmreg.
[14:35] <ubitux> (also, i will possibly need a 3d fft at some point)
[14:38] <ubitux> michaelni: i'll write the filters with fftw (because that's simpler for my purpose), and will eventually write a naive fft 2d with 2x 1d fft before submitting
[14:38] <ubitux> but don't count on me to work on a fast version.. :P
[14:38] <michaelni> fine with me ...
[15:51] <durandal_1707> michaelni: ^ that commit cehoys mentioned is ridiculous
[15:56] <ubitux> 50M should be enough for anyone ©
[15:56] <cone-623> ffmpeg.git 03Paul B Mahol 07master:ad56535dd1d7: avformat: fix orig_pos type to match pkt->pos
[15:58] <durandal_1707> that is 2gb of input ... and i could be this fixes #2494
[15:58] <durandal_1707> *bet
[16:01] <ubitux> don't you mean another ticket?
[16:12] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:8f04220df805: avfilter/geq: rgb support
[16:19] <burek> there is some kind of a bug in docs http://ffmpeg.org/download.html
[16:19] <burek> "0.10.7 was released on 2013-04-10."
[16:19] <ubitux> is that wrong?
[16:19] <burek> the date doesn't sit in between of 0.9.2 and 0.11.3
[16:19] <durandal_1707> thats not doc
[16:20] <ubitux> burek: it's the revision
[16:20] <ubitux> not the original 0.10 release
[16:20] <ubitux> check the next sentence
[16:21] <burek> i see, so it's the last stable version from that branch
[16:21] <ubitux> yes
[16:21] <burek> ok, my bad, sorry
[16:24] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:488c760091c2: doc/filters: document geq rgb mode
[16:41] <burek> [16:40:50] <b_jonas> man, this was fast, thank you (I reported a bug and a developer has fixed it within an hour) :))) #ffmpeg
[16:41] <burek> +1
[17:08] <cone-623> ffmpeg.git 03Carl Eugen Hoyos 07master:9526c9ccc3dd: Read block_align from extradata when decoding qclp in aiff.
[17:08] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:b21b2ca95b33: Merge remote-tracking branch 'cehoyos/master'
[20:51] <ubitux> there is no particular alignment or padding requirement for the fft code, right?
[22:34] Action: michaelni is trying to find the remaining bugs in vc1
[22:35] <michaelni> i hadnt realized we have random pieces of code with 0 && in there :)
[22:50] <cone-623> ffmpeg.git 03Stefano Sabatini 07master:638ffb24136d: lavfi/hue: rework logic for setting commands
[22:50] <cone-623> ffmpeg.git 03Stefano Sabatini 07master:dfdee6cab323: doc/filters: sort multimedia filters by name
[22:56] <saste> ubitux, how can I install locally a python module?
[22:57] <ubitux> with pypi possibly... i guess
[22:58] <ubitux> try something like pip2 search zmq
[22:58] <ubitux> pip2 install pyzmq might do the trick
[22:59] <ubitux> (i have pip for python3 here, and pip2 for python2)
[23:00] <saste> pip? in which package should I find it?
[23:01] <saste> python-pip
[23:01] <ubitux> i guess :)
[23:01] <ubitux> make sure it's the python2 version if you're interested in python2 packages :p
[23:07] <saste> ubitux, can I install the package in my home, so that i don't mess with the system?
[23:08] <ubitux> saste: good question; you might be able to just download the thing and put it in the script dir (the import should work)
[23:09] <saste> ubitux, script dir?
[23:09] <ubitux> yeah the zmq script i guess in your case
[23:09] <saste> note that I don't know the first thing about python installation paths
[23:09] <ubitux> otherwise there are some env path
[23:10] <ubitux> saste: iirc pip basically just download and unzip the package into /usr/lib/python-xxx/site-packages/
[23:10] <ubitux> which is part of the python import env path
[23:10] <saste> ubitux, and compiles it
[23:10] <ubitux> ah, well yeah for import to work :)
[23:10] <saste> and i don't think it was using my locally installed libzmq when compiling
[23:18] <ubitux> i have no idea :p
[23:18] <ubitux> saste: what distro are you using btw?
[23:18] <saste> ubitux, ubuntu
[23:18] <saste> 12.04
[23:18] <ubitux> oh.
[23:18] <ubitux> okay
[23:19] <saste> anyway it's mostly working but the script it's printing garbage on return
[23:19] <saste> did you try it?
[23:19] <ubitux> i didn't go up to the read() :D
[23:20] <saste> what should we ship, the C client or the python one?
[23:20] <ubitux> it was written in a few minutes and then i had to review your hue patch
[23:20] <saste> or both?
[23:20] <ubitux> dunno, i really like the shell helpers of cmd
[23:20] <ubitux> are you already done with the filter?
[23:20] <saste> btw we may make use of some readline utils
[23:20] <ubitux> gpl? :)
[23:21] <saste> or we hack our own variant?
[23:21] <saste> or we use a non-gpl lib, if exists
[23:21] <ubitux> for what? still the zmq inject c example?
[23:21] <saste> there is also ffeval
[23:21] <ubitux> saste: btw, can't you use something like netcat to send commands?
[23:22] <ubitux> which would simplify everything...
[23:23] <saste> ubitux, no, the user is supposed to use libzmq, so makes sense to provide an example script/client
[23:24] <ubitux> whatever you prefer
[23:24] <saste> we can have both
[23:24] <saste> now look at the eval read loop
[23:25] <saste> i'm duplicating most of the code reallocating the buffer size 
[23:25] <saste> don't we have a function for that?
[23:27] <ubitux> bprint? :P
[23:27] <ubitux> ah for recv.
[00:00] --- Wed Apr 24 2013