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

[burek]

[00:10] <CIA-119> ffmpeg: 03Mans Rullgard 07master * rbc92214e27 10ffmpeg/libavcodec/vc1dsp.c: 
[00:10] <CIA-119> ffmpeg: vc1dsp: mark put/avg_vc1_mspel_mc() always_inline
[00:10] <CIA-119> ffmpeg: This ensures that these functions are inlined into the per-position
[00:10] <CIA-119> ffmpeg: entry points, allowing constant propagation as needed for proper
[00:10] <CIA-119> ffmpeg: optimisation.
[00:10] <CIA-119> ffmpeg: 18% faster VC1 decoding on Cortex-A9.
[00:10] <CIA-119> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:10] <CIA-119> ffmpeg: 03Justin Ruggles 07master * r98db4e2a4e 10ffmpeg/libavcodec/ppc/ (15 files): 
[00:10] <CIA-119> ffmpeg: PPC: Move types_altivec.h and util_altivec.h from libavcodec to libavutil
[00:10] <CIA-119> ffmpeg: This will allow for easier implementation of Altivec functions in libraries
[00:10] <CIA-119> ffmpeg: other than libavcodec.
[00:10] <CIA-119> ffmpeg: 03Justin Ruggles 07master * r94d2b0d2fd 10ffmpeg/libavcodec/arm/ (39 files): 
[00:10] <CIA-119> ffmpeg: ARM: Move asm.S from libavcodec to libavutil
[00:10] <CIA-119> ffmpeg: This will allow for easier implementation of ARM-optimized functions in
[00:10] <CIA-119> ffmpeg: * qatar/master:
[00:10] <CIA-119> ffmpeg:  float_dsp: ppc: add a separate header for Altivec function prototypes
[00:10] <CIA-119> ffmpeg:  ARM: fix float_dsp breakage from d5a7229
[00:10] <CIA-119> ffmpeg:  Add a float DSP framework to libavutil
[00:10] <CIA-119> ffmpeg:  PPC: Move types_altivec.h and util_altivec.h from libavcodec to libavutil
[00:10] <CIA-119> ffmpeg: 03Mans Rullgard 07master * ra839d6abf8 10ffmpeg/libavutil/arm/ (4 files): 
[00:10] <CIA-119> ffmpeg: ARM: fix float_dsp breakage from d5a7229
[00:10] <CIA-119> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:10] <CIA-119> ffmpeg: 03Justin Ruggles 07master * rd5a7229ba4 10ffmpeg/ (39 files in 8 dirs): 
[00:11] <CIA-119> ffmpeg: Add a float DSP framework to libavutil
[00:11] <CIA-119> ffmpeg: Move vector_fmul() from DSPContext to AVFloatDSPContext.
[00:33] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r349b65eee2 10ffmpeg/ffplay.c: 
[00:33] <CIA-119> ffmpeg: ffplay: check return code of avcodec_decode_video2()
[00:33] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:33] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:33] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rcb819338d1 10ffmpeg/ffplay.c: 
[00:33] <CIA-119> ffmpeg: ffplay: reset AVFrame to defaults before decoding each new frame.
[00:33] <CIA-119> ffmpeg: This fixes: ffplay -f lavfi -i cellauto
[00:33] <CIA-119> ffmpeg: This was a regression since factorizing the filter code with ffmpeg.
[00:33] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:33] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:33] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r690ea9359d 10ffmpeg/: 
[00:33] <CIA-119> ffmpeg: Merge remote-tracking branch 'cus/stable'
[00:33] <CIA-119> ffmpeg: * cus/stable:
[00:33] <CIA-119> ffmpeg:  ffplay: reset AVFrame to defaults before decoding each new frame.
[00:33] <CIA-119> ffmpeg:  ffplay: check return code of avcodec_decode_video2()
[00:33] <CIA-119> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[00:37] <CIA-119> ffmpeg: 03J. Bohl 07master * r023c073076 10ffmpeg/libavfilter/libmpcodecs/vf_mcdeint.c: 
[00:37] <CIA-119> ffmpeg: add bracket around the argument (fixes compilation error with ICL)
[00:37] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:46] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * ra5c6349358 10ffmpeg/libswresample/rematrix.c: 
[02:46] <CIA-119> ffmpeg: swr: skip memset(0) in rematrix when the array is known to be already 0
[02:46] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:46] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r75d900d52e 10ffmpeg/libswresample/swresample.c: 
[02:46] <CIA-119> ffmpeg: swr: zero buffers on allocation
[02:46] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r04e2ac4749 10ffmpeg/libavutil/libavutil.v: 
[02:57] <CIA-119> ffmpeg: libavutil.v: add avpriv prefix
[02:57] <CIA-119> ffmpeg: This should fix the fate failure
[02:57] <CIA-119> ffmpeg: http://fate.ffmpeg.org/log.cgi?time=20120609002213&log=compile&slot=x86_64-archlinux-gcc-enableshared
[02:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:42] <Daemon404> michaelni, im working on setting up a windows fate server
[03:43] <Daemon404> but one of the tests never finishes
[03:45] <Daemon404> random_seed
[04:07] <michaelni> Daemon404, you can try to use some windows native way to get a random seed
[04:12] <Daemon404> michaelni, is this problem known?
[04:12] <Daemon404> im tryign to debug it but im finding finding nothing but being stuck in ntdll
[04:13] <ohsix> what is it calling, just srand or whatever?
[04:17] <Daemon404> im trying to find where it's actually getting stuck
[04:18] <Daemon404> it might just actually be insanely slow on windows.
[04:19] <ohsix> that's possible, the rng's are slow and the ones in the ms crt's are shining examples of being twice or more slower :D
[04:20] <ohsix> standard operating procedure when doing just about anything on windows is replacing _ftol and using your own rng
[04:20] <Daemon404> lol
[04:20] <Daemon404> yes, yes it is just slow
[04:20] <Daemon404> i can count tej loop iterations by eye it's so slow
[04:20] <Daemon404> the*
[04:22] <Daemon404> well ive got ffmpeg set up fate then
[04:23] <Daemon404> libav's fate seems to be busted on windows... guess ill fix it
[04:23] <ohsix> btw i think that's a significant difference, per our original discussion about windows vs. cross :]
[04:23] <Daemon404> which part? the libav bustedness, or the lolslow rng
[04:24] <ohsix> the wine/mingw vs. windows/cl
[04:24] <ohsix> a few weeks ago
[04:25] <ohsix> i don't think it matters, but it is a real difference
[04:25] <Daemon404> im kind of imrpessed at the order of magnitude slower it is
[04:26] <ohsix> they might have added a "secure" mode based on md5 or something, still needs to be a prng but they can do worse
[04:28] <ohsix> generating a random number has always been slow,  if you need them fast you should probably be picking among different types instead of relying on the crt
[04:32] <michaelni> Daemon404, can you fix the random_seed thing on windows ? it just needs to call windows native means to get a random number
[04:33] <michaelni> also see https://ffmpeg.org/trac/ffmpeg/ticket/653
[04:34] <ohsix> vlc has some library wrapper to print all calls to random number generator stuff cuz it's pretty much going to show up in profiles if it's being used :D
[04:34] <michaelni> the bug report above contains a link to MSDN
[04:35] <Daemon404> looks like mingw-w64 has RtlGenRandom 
[04:35] <Daemon404> ill poke it tomorrow
[04:35] <michaelni> thanks :)
[04:36] <ohsix> you might consider just getting some lsfr one in there so it's uniform, if you need something that might be expensive add specifics (there may be more useful sources for that)
[04:38] <Daemon404> the other random thing i was considering doign was vf_nnedi3 using pengvado's impl
[04:40] <michaelni> ohsix, specifically we need s random number, we have no previous value to build uppon
[04:40] <michaelni> its tricky to do this fast & portable
[04:40] <ohsix> the shift register just starts with some value and you either assume it's seeded or take what you get from it
[04:40] <michaelni> ohsix we have no seed
[04:41] <ohsix> the initial value of the shift register is the seed
[04:41] <ohsix> or do you mean you have no _state_?
[04:42] <michaelni> when ffmpeg is freshly started theres no state or seed from before
[04:42] <michaelni> and we need a string random number sometimes
[04:42] <ohsix> right, the shift register is in the bss and gets set to zero like any other value
[04:43] <ohsix> http://en.wikipedia.org/wiki/Linear_feedback_shift_register
[04:43] <ohsix> they're cheap and awful
[04:43] <michaelni> they are useless for us
[04:44] <ohsix> how much entropy do you need
[04:44] <michaelni> for the random_seed fate test ? :)
[04:44] <michaelni> let me check
[04:45] <michaelni> something between 16 and 50 kbit :)
[04:45] <ohsix> for all uses of those types of random numbers
[04:46] <michaelni> in general real uses (not fate) should survive on 64-128bit
[04:46] <ohsix> anyways, i thought you just needed some numbers, there are some other public domain rng's that are cheap and have excellent distributions and other useful properties, you can just pick one :>
[04:46] <michaelni> ohsix, you dont understand
[04:47] <michaelni> we need a number from hot air theres no previous state to build upon
[04:47] <ohsix> eh
[04:47] <ohsix> zero, without the presence of some other seed is previous state
[04:48] <michaelni> thats not helping
[04:49] <michaelni> we need a uniformly distributed number
[04:49] <ohsix> does it need to be pseudorandom?
[04:49] <ohsix> uniformity is a property of whatever rng you might pick
[04:49] <michaelni> the more random and the less pseudo the better
[04:50] <michaelni> what we need is like what you get when you flip a coin
[04:50] <ohsix> that's why i mentioned better sources earlier, some operating systems can draw from an entropy pool they build from diskio and stuff, or have some thermal source in the cpu
[04:50] <ohsix> you need that in all cases that someone would call it?
[04:52] <ohsix> just hooking up the Rtl* version that gets you a random number on windows ... is there any investigation into the quality of the random numbers? there are for the public domain rngs, it's quite possible a pseudo-rng would have better properties than one you don't quantify
[04:54] <michaelni> if you have some portable code that produces good random numbers quicker than our random_seed code, iam surely interrested
[04:54] <michaelni> that is random, no state no seed
[04:55] <ohsix> that doesn't really exist, they have state if they're pseudorandom; or you have a thermal/magic/os-entropy source, you'd need both since the latter isn't always available
[04:58] <michaelni> random_seed.c exists last i checked, it has no state and is portable the only problem is, it is LOLslow on some platforms
[04:58] <michaelni> anyway, i need to go to bed
[04:59] <ohsix> it's not really portable if you get different quality numbers on each of the platforms :D
[05:00] <ohsix> it looks like the mersenne twister is still the go-to prng, when i was actually researching this like 8 years ago i came to the same conclusion :> it is very fast.
[05:00] <ohsix> the os services could rightly return a single number and still be random, it would suck, but you don't have any idea how much until you vet them
[05:02] <ohsix> whereas a prng, like the mersenne twister is known, fast; you could use it everywhere unless you know you have a better quality source, then platform specific
[05:05] <ohsix> i'd still have separate api for either, or some way to indicate that you aren't getting a prng when you call it
[05:08] <ohsix> the one that's slow (or possibly slow) could even fetch some randomness from the web or something ;] the caller better know they need it (and they pretty much never do in this domain)
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r283cc05938 10ffmpeg/libavfilter/ (buffersink.h sink_buffer.c): buffersink: add av_buffersink_get_frame_rate().
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r7b42036b3b 10ffmpeg/libavfilter/ (avfilter.c avfilter.h): lavfi: add a frame_rate field to AVFilterLink.
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r9ca440679d 10ffmpeg/ (doc/filters.texi libavfilter/buffersrc.c): buffersrc: accept the frame rate as argument.
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r0f62125643 10ffmpeg/libavfilter/buffersrc.c: buffersrc: deprecate flat options syntax.
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r5f281e94ba 10ffmpeg/ffmpeg.c: 
[09:28] <CIA-119> ffmpeg: ffmpeg: add frame rate to the buffersrc arguments.
[09:28] <CIA-119> ffmpeg: The arguments now use the key=value syntax.
[09:28] <CIA-119> ffmpeg: 03Nicolas George 07master * r6fef82f22d 10ffmpeg/ffmpeg.c: (log message trimmed)
[09:28] <CIA-119> ffmpeg: ffmpeg: with filter_complex, avoid random in<->out mapping.
[09:28] <CIA-119> ffmpeg: With complex filters, an output can come from any input,
[09:28] <CIA-119> ffmpeg: or several inputs, including inputs of a different type.
[09:28] <CIA-119> ffmpeg: Copying the codec parameters from the first input with
[09:28] <CIA-119> ffmpeg: the same type does not make any sense.
[09:28] <CIA-119> ffmpeg: This does not change anything for simple 1->1 filters,
[09:29] <CIA-119> ffmpeg: 03Nicolas George 07master * r8362d734a3 10ffmpeg/ffmpeg.c: 
[09:29] <CIA-119> ffmpeg: ffmpeg: use the frame rate computed by lavfi.
[09:29] <CIA-119> ffmpeg: This frame rate is more reliable than the one copied
[09:29] <CIA-119> ffmpeg: from the input stream, so it is used in priority.
[09:29] <CIA-119> ffmpeg: 03Nicolas George 07master * rfbaa8fe6c6 10ffmpeg/ffmpeg.c: 
[09:29] <CIA-119> ffmpeg: ffmpeg: init icodec.
[09:29] <CIA-119> ffmpeg: With complex filter graphs, it can end up accessed
[09:29] <CIA-119> ffmpeg: without having been set.
[09:29] <CIA-119> ffmpeg: 03Nicolas George 07master * rdcaa4efcee 10ffmpeg/ (doc/filters.texi libavfilter/buffersrc.c): 
[09:29] <CIA-119> ffmpeg: buffersrc: accept key=value arguments.
[09:29] <CIA-119> ffmpeg: The current flat arguments syntax is not easily extensible
[09:29] <CIA-119> ffmpeg: due to sws_param possibly containing commas.
[09:30] <CIA-119> ffmpeg: This is also consistent with abuffersrc.