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

[burek]

[00:00] <ubitux> i think i happened to see the video :)
[00:54] <JEEB> ubitux, fabulously chuuni2 logo you found there sir
[01:03] Action: BBB randomly playing with github comments
[01:05] <ubitux> BBB: saw that :)
[01:05] <ubitux> funny thing, i can edit *your* comments
[01:05] <ubitux> ..
[01:06] <ubitux> but you're already saying you like that so that's not funny
[01:09] <BBB> also with your comments on this one sample, time with -threads 1 gives us 5.5sec vs libvpx 7.5sec
[01:09] <ubitux> :)
[01:09] <BBB> so we're slightly more than 2 sec faster than libvpx, or 36%
[01:09] <BBB> and this is still with a bunch of c code, so not bad
[01:12] <ubitux> i don't know when i will receive my avx2 machine, but we probably want to have some avx2 asm before the announce as well
[01:13] <BBB> that'd be nice
[01:14] <ubitux> i'll try to get done with the transpose tomorrow
[01:14] <ubitux> then i guess i'll have to do the 8/4 ones
[01:15] <BBB> the only avx2 decoder function in libvpx is specialize vp9_lpf_horizontal_16 sse2 avx2 neon dspr2
[01:15] <BBB> (as of today)
[01:17] <BBB> the others are encoder functions
[01:17] <BBB> (fdct, fadst, variance, mse)
[01:18] <BBB> (note that horizontal for libvpx is vertical for us)
[01:18] <ubitux> it will be useful for filter6() and filter14()
[01:18] <ubitux> and probably for idct16 and 32
[01:19] <BBB> well you noticed how all loopfilter functions are mix2 right?
[01:19] <BBB> we should create mix4 versions for avx2 to be truly useful
[01:19] <BBB> which is some sort of an exponentially explosive problem, because you need a lot more mix4 variants than mix2 variants
[01:19] <ubitux> mmh yeah ok :)
[01:20] <BBB> assuming we want to operate on 32px per iteration
[01:20] <BBB> this is a great idea btw
[01:20] <BBB> I'm just saying it's not exactly trivial
[01:20] <BBB> idct16/32 are indeed very obvious candidates
[01:20] <BBB> also all 16x16/32x32 intra pred and >= 16px inter pred (subpel mc) functions
[01:21] <BBB> so yes that'll be fun, I didn't assume it to be critical before announce, but we can wait, sure
[01:22] <ubitux> well we need to be honest and be faster everywhere :p
[01:22] <ubitux> we're likely slower on arm already, so let's at least be faster on intel :)
[01:24] <ubitux> BBB: btw, i heard vp9 now has 444; we should probably support that :p
[01:36] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:53167ecfdb99: avcodec/huffyuv: support AV_PIX_FMT_YUV(A)4XYP16 and GRAY16
[01:40] <BBB> ubitux: profile 1, yes, also supports alpha, rgb and some other things
[01:40] <BBB> lots of fun
[01:41] <ubitux> i want 10-bit :(
[01:41] <BBB> not in profile 0 or 1
[01:41] <ubitux> totally useless for animes
[01:41] <ubitux> how am i supposed to watch vp9 files then
[01:42] <BBB> youtube I guess
[01:43] <ubitux> :)
[01:44] <BBB> or you have to write profile 2 for 10bit yourself
[01:49] <Compn> animes 
[01:50] <Compn> they still make that ?
[01:54] <ubitux> that's probably the only important and relevant video source
[01:58] <BBB> also we wrote 11.5k lines of code for this beast
[01:58] <BBB> and still not yet done
[01:58] <BBB> whoa
[01:58] <Compn> yeah you guys are working hard
[01:59] <Compn> way too hard
[01:59] <BBB> it's pretty solid at this point
[01:59] <BBB> I have some fuzzing issues left with scalable samples, but overall it looks fairly solid
[01:59] <BBB> I guess I should fix scalable at some point
[01:59] <BBB> that's part of profile 0
[02:00] <ubitux> i'll continue to bring you some fuzzed files ;)
[02:01] <ubitux> http://ljdchost.com/26vA1uM.gif #ffmpeg users
[02:07] <BBB> that's also half of doom9 posters
[02:07] <BBB> and many alike
[02:10] <Compn> is it bad i know thats from gravity falls ? 
[02:14] <cone-125> ffmpeg.git 03Janne Grunau 07master:fb0c9d41d685: avutil: remove timer.h include from internal.h
[02:14] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:965fa6b0d9d9: Merge commit 'fb0c9d41d685abb58575c5482ca33b8cd457c5ec'
[02:30] <BBB> ubitux: fixes for your fuz sample (and the base one) on ML
[03:18] <cone-125> ffmpeg.git 03Janne Grunau 07master:6d93307f8df8: mpeg12: check scantable indices in all decode_block functions
[03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:3e6088f7322c: avutil/internal.h: add timer.h back
[03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:20626f53e9f4: Merge commit '6d93307f8df81808f0dcdbc064b848054a6e83b3'
[03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:6a92598e149b: avcodec/mpeg12dec: Redesign index checks for mpeg2_fast_decode_block_intra
[03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:7667afffb8dd: avcodec/mpeg12dec: Revert Change to mpeg2_fast_decode_block_non_intra
[03:23] <cone-125> ffmpeg.git 03Janne Grunau 07master:fb87e69ff77f: configure: add missing x86 dependency for i686
[03:23] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:0e2dd05c22c4: Merge commit 'fb87e69ff77f96536768dbae01d82db70c8b41f3'
[03:31] <cone-125> ffmpeg.git 03Janne Grunau 07master:9e057f53aa85: configure: clang: explicitly state dep file and rule name in DEPFLAGS
[03:31] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:c46faacdf4e1: Merge remote-tracking branch 'qatar/master'
[04:07] <cone-125> ffmpeg.git 03Jean First 07master:91489d28ba27: avcodec/libfdk_aacenc: enable 7.1 channel encoding
[04:27] <BBB> do we have any sort of "rawframecrc" output that prints the size of the frame in addition to the crc of the data?
[04:27] <BBB> that would be useful as an alternative to framecrc/framemd5 for scalable fate tests
[04:35] <BBB> maybe I should just add a 'print_size' private option to framemd5 to print the size for each frame...
[05:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:bc11b2c3e6b5: fate: add test for 16bps ffvhuff
[11:51] <Rodeo> michaelni: are you around?
[11:57] <Rodeo> I'm looking at http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=91489d2;hp=c46faac
[11:57] <Rodeo> here's an excerpt from FDK_Audio.h:
[11:57] <Rodeo>   MODE_7_1_REAR_SURROUND        = 33,       /**< C, L+R, LS+RS, Lrear+Rrear, LFE */
[11:57] <Rodeo>   MODE_7_1_FRONT_CENTER         = 34        /**< C, LC+RC, L+R, LS+RS, LFE */
[11:58] <Rodeo> MODE_7_1_REAR_SURROUND is most definitely not AV_CH_LAYOUT_7POINT1_WIDE_BACK
[12:00] <Rodeo> for consistency with the rest, MODE_7_1_FRONT_CENTER would be AV_CH_LAYOUT_7POINT1_WIDE_BACK (since LS+RS is mapped to back channels in other modes)
[12:00] <Rodeo> MODE_7_1_REAR_SURROUND would probably be AV_CH_LAYOUT_7POINT1_WIDE_BACK, though here that means mapping LS+RS to side channels instead, and Lrear+Rrear to back channels
[12:01] <Rodeo> sorry, I meant MODE_7_1_REAR_SURROUND would probably be AV_CH_LAYOUT_7POINT1
[12:14] <Rodeo> sigh
[12:14] <Rodeo> not to mention, MODE_7_1_FRONT_CENTER and MODE_1_2_2_2_1 can't be used interchangeably
[12:15] <Rodeo> the latter will use the AAC channel_config 7 instead of 0+PCE if you use the former
[12:15] <Rodeo> I suppose this could be intentional
[13:43] <michaelni> Rodeo, iam not the author of that commit, did you contact jean first about this ?
[13:54] <Rodeo> michaelni: nope, sorry
[13:54] <Rodeo> but you committed it
[14:01] <BBB> ubitux: I had one more question
[14:02] <BBB> ubitux: the vp8 loopfilter uses 8x16 pixels for lf, but it does it (on x86-64 at least) entirely in registers, i.e. no stack
[14:03] <BBB> ubitux: do you think it's possible to reproduce that in the vp9 loopfilter? no-stack would remove a lot of shuffles to/from it and thus make it somewhat faster
[14:03] <BBB> (at least in the 88 and lower ones, not the 16 one)
[14:50] <michaelni> Rodeo, posted 2 patches to the ML that would make the changes you suggest
[14:51] <Rodeo> patches looks good
[14:52] <Rodeo> I guess I should subscribe to the ML, though it's too late for those 2 patches
[15:54] <Nicias> Je;;phello
[15:54] <Nicias> hello
[15:54] <Nicias> I am writing a filter and I am having a bit of a problem.
[15:54] <Nicias> All I want to do is modify the value of frame->pts. 
[15:55] <Nicias> I do this insde filter_frame.
[15:55] <Nicias> and if, inside filter_frame, I print the new frame->pts it show the correct value. 
[15:55] <Nicias> However, it doesn't end up in the file that is written out at the end.
[16:13] <Nicias> As part of my modifications, I want to change the timebase of the video stream, since all the pts are scalled by about 8.
[16:14] <Nicias> If I put in a config_output that is just outlink->timebase = inlink->timebase * 8 
[16:14] <Nicias> then it ignores the new PTS's entirely.
[16:15] <Nicias> otherwise it does the correct thing but the timebase is wrong.
[16:24] <cone-907> ffmpeg.git 03Reimar Döffinger 07release/1.2:8a38deb789ec: Fix compilation on ARM with android gcc 4.7
[16:24] <cone-907> ffmpeg.git 03Alex Sukhanov 07release/2.1:9ca79d284989: avformat/matroskadec: Fix start_time
[16:31] <Nicias> any help on my filter question?
[17:21] <ubitux> BBB: the stack is necessary only for h, and it's used partly because it's aligned, which actually helps a lot
[17:22] <ubitux> there is one specific place where i'm using pand(n?) with the direct address, and having that with an intermediate register is a real pain
[17:41] <BBB> ubitux: I didn't mean stack vs dst, rather stack vs registers
[17:42] <BBB> ubitux: I'm wondering if 16 registers is enough for the 88 (maybe it isn't, I'm not sure :) )
[17:42] <ubitux> i probably won't need the stack for the transpose
[17:43] <ubitux> dunno if i can avoid the whole stack but i doubt it since i need to re-read
[17:43] <Daemon404> is it a bog standard transpose?
[17:43] <ubitux> (and the stack is my dst in h mode)
[17:43] <Daemon404> i.e. can reuse code
[17:44] <BBB> Daemon404: sure
[17:44] <Daemon404> there exists transpose asm to reuse elsewhere...
[17:44] <Daemon404> if its useful.
[17:44] <Daemon404> (not necessarily in ffmpeg_
[17:44] <ubitux> there was no transpose16x16b in x264
[17:44] <ubitux> but i based the code on those
[17:44] <Daemon404> using 4 4x4 is too slow i take it?
[17:44] <BBB> 4 4x4 is 16x4
[17:44] <BBB> he needs 16x16
[17:45] <Daemon404> uh
[17:45] <Daemon404> well i can tread
[17:45] <BBB> but he already wrote it
[17:45] <Daemon404> yeah i know
[17:45] <Daemon404> just curious
[17:45] <Daemon404> i had ported asm to vf_transpose.c at one point
[17:45] <Daemon404> from another project
[17:45] <BBB> I think the code he wrote is shareable enough, not too worried about it
[17:45] Action: Daemon404 fades back into the bg
[17:47] <Daemon404> yeah
[17:47] <Daemon404> https://github.com/vapoursynth/vapoursynth/blob/master/src/core/asm/x86/transpose.asm
[17:47] <Daemon404> stuff i had done doesnt look suitable for you.
[17:48] <BBB> ubitux: anyway, it may be worth looking at later to see if we can eradicate stack altogether, or at least as much as possible; but can be done later I guess
[17:49] <BBB> it's not utterly urgent to get that right the first time
[17:49] <BBB> (assuming there is a right)
[17:50] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:a301bb63f05d: avcodec/huffyuvenc: fail if stats_out is too small instead of silently truncating
[17:50] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:599e629f88a0: avcodec/huffyuvenc: fix end pointer for stats_out
[17:54] <BBB> ubitux: also wanna review my two vp9 patches to fix your fuzzed6?
[17:55] <BBB> then I'll work on "real" scalable support in the near future
[17:55] <ubitux> give me about 2h :p
[17:55] <ubitux> i need to get something done
[17:55] <BBB> ok
[17:57] <Daemon404> aside: does vp9 have 10-bit yet?
[17:59] Action: Daemon404 is evaluating HEVC encoders soon-ish, and would like to include vp9, but all 4k clips he has are 10-bit
[17:59] <BBB> no
[17:59] <Daemon404> hmm ok
[18:12] <kierank> Daemon404: please deploy high-10 kthx
[18:12] <kierank> screw 8-bit
[18:13] <kierank> I guess however the chipset guys will force 8bit on you
[18:13] <Daemon404> who knows
[18:15] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:68c5ba1f052f: doc/filters: re-edit notes on filtergraph escaping
[18:15] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:9651239f6747: ffmpeg: use intermediary variables in reap_filters, increase readability
[18:33] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:37baa2af43a0: configure: add missing dependency for the remuxing example
[19:08] <saste> kierank, you gonna test my overlay patch?
[19:09] <kierank> saste: hmm forgot about that. will do it tomorrow
[19:09] <kierank> sorry
[19:09] <saste> otherwise i'll probably drop it, since i have no special interest with testing/using the patch
[19:09] Action: kierank was doing taxes this weekend
[19:09] <saste> hope you had fun
[19:09] <kierank> well i didn't owe any taxes so it was ok
[19:10] <saste> so it was easy at least
[19:10] <saste> michaelni, ping again about the timebase thing, anu comment?
[19:10] <saste> *any
[19:17] <ubitux> BBB: the 2 patches are probably ok
[19:17] <michaelni> saste, fps * ticks_per_frame * time_base = 1, i suspect your patch breaks this
[19:17] <ubitux> BBB: should i continue fuzzing or you want to write some solid sanity code first?
[19:18] Action: saste has no idea what "ticks per frame" is
[19:19] <saste> michaelni, then at least we should fix the documentation, if the time_base option is not supposed to be controllable by the user we should remove it
[19:19] <michaelni> saste, some code like ratecontrol use "ticks per frame" to decide how many bits a frame should get for the user specified bitrate
[19:19] <saste> and avoid even more confusion
[19:20] <michaelni> currently AVCodecContext.timebase cant just be randomly set by the user in general, she can set it through setting the framerate though
[19:21] <michaelni> if you want to change this so the user can set it, i dont mind at all but i cant just give you a list of files and lines of code that would need to be chnaged ;)
[19:21] <michaelni> but with the current code ticks_per_frame has to be adjusted at least
[19:21] <michaelni> i dont know if that will be enugh
[19:22] <michaelni> at least libx264.c had a bug in relation to this which i fixed
[19:23] <wm4> currently I have to set AVCodecContext.time_base in order to use the subtitle conversion "decoders"
[19:24] <saste> michaelni, ah i see, thanks for fixing libx264.c
[19:25] <michaelni> its not a problem to set AVCodecContext.time_base from user applications, the problem is if the user sets time_base through AVOptions to lets say 5000 and expects 25fps because he also specified -r 25 on the command line
[19:25] <michaelni> s#5000#1/5000#
[19:26] <saste> michaelni, ticks per frame = timebase units between each frame (assuming constant framerate)?
[19:26] <michaelni> saste, yes
[19:37] <BBB> ubitux: no keep fuzzing, each of these did expose real issues
[19:37] <BBB> ubitux: so it definitly helps
[19:38] <wm4> (stupid question) how much do you think fuzzing helps in general to find of the total amount of bugs that is assumed to exist?
[19:39] <BBB> fuzzing only helps if total code and feature coverage is great enough in the base files used for fuzz input
[19:41] <Daemon404> it could also be useful to hack an encoder to produce insane files
[19:42] <BBB> yeah absolutely
[19:43] <BBB> anyway, total amount of bugs ... I don't know if that's a measurable, but fuzzing does decrease the density of obvious and easy-to-find bugs
[19:43] <BBB> so in that way it makes the code a lot safer in practice
[19:43] <Daemon404> it also helps if you have a few thousand spare cores
[19:43] <Daemon404> a al google
[19:45] <ubitux> BBB: ok then i'll start fuzzing again when your current patches are upstream
[19:45] <BBB> wm4: I believe the nvidia defense (which is shared by some lawyers and some kernel devs, but not all) is that the nvidia binary is in itself useful outside the linux kernel also; for example, the same code (sic) is used in the windows driver also
[19:46] <BBB> wm4: so then it is not a derived work anymore
[19:46] <wm4> heh
[19:46] <wm4> interesting aspect that with the windows driver
[19:46] <BBB> not all kernel devs and not all lawyers share this sentiment
[19:46] <wm4> of course nobody can prove it
[19:50] <wm4> I guess this is also how there can be a native ZFS driver
[20:04] <BBB> michaelni: can you merge the two on the ML then?
[20:04] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:e6c0da70fc82: avcodec/huffyuvdec: optimize >8bps VLC reading
[20:17] <cone-907> ffmpeg.git 03Ronald S. Bultje 07master:d9343c348412: vp9: disable use_last_frame_mvs on resolution change (scalable).
[20:17] <cone-907> ffmpeg.git 03Ronald S. Bultje 07master:c2871568cffe: vp9: fix invalid ref frame w/h on size change.
[21:05] <nevcairiel> default vob palettes ... the reason this format sucks so bad
[21:19] <Daemon404> nevcairiel, arent you glad they did away with bitmapped subs in bluray... wait.
[21:20] <ubitux> heh, in the 2nd transpose, i have more swaps that instructions
[21:22] <wm4> bluray subs don't look so bad
[21:29] <nevcairiel> bluray subs have inband palettes and generally more useful features
[21:30] <wm4> ubitux: btw. we'll probably break ffmpeg subs... you ok with that?
[21:30] <ubitux> :(
[21:31] <ubitux> i personally don't care you know, that's for the users
[21:31] <ubitux> (you're one of them)
[21:31] <wm4> the files are definitely invalid
[21:31] <wm4> and won't play with the ASS main consumer
[21:31] <ubitux> ah you mean the libass thing
[21:31] <wm4> yes
[21:31] <ubitux> so
[21:32] <ubitux> you're saying all the "broken" ass files out there won't work anymore?
[21:32] <wm4> yes
[21:32] <ubitux> is it that much trouble to keep that support?
[21:32] <wm4> take a look at the parsing code
[21:33] <wm4> and compare it with vsfilter's
[21:33] <wm4> I guess ffmpeg itself will still be able to read the old files
[21:33] <ubitux> i think that's a very bad idea to purposely break all the files out there but well
[21:33] <wm4> they're already broken
[21:33] <wm4> it just "happens" to work with a single ASS implementation (libass)
[21:34] <ubitux> a single ASS implementation used by virtually millions of people (vlc/mplayer and friends)
[21:34] <wm4> so we can conveniently redirect the blame to ffmpeg
[21:34] <nevcairiel> i still don't understand why not simply implement a universal parser based on the header line
[21:34] <wm4> nevcairiel: it's slow and breaks in files vsfilter accepts
[21:35] <ubitux> "slow" how is parsing time relevant? oO
[21:35] <wm4> vsfilter doesn't even have anything to parse that header line and just skips it as garbage
[21:35] <wm4> ubitux: it matters a few percents
[21:35] <ubitux> anyway, i don't have time & motivation to fix that
[21:35] <wm4> IMO this whole ASS business is severely broken and insane, but whatever
[21:35] <ubitux> at least not right now
[21:36] <ubitux> yes, but we can't fix it easily
[21:36] <wm4> I mean ASS and how it's used in general
[21:36] <ubitux> i'm also not an ass expert at all
[21:56] <ubitux> is there a movq for the low part? :p
[22:06] <BBB> movlps?
[22:07] <ubitux> too late, i rewrote differently :p
[22:07] <BBB> lol
[22:17] <kierank> "Output pad "default" with type video of the filter instance "in" of smptebars not connected to any destination"
[22:17] <kierank> ??
[22:17] <kierank> wtf does that mean
[22:17] <kierank> :(
[22:20] <llogan> kierank: how did you get that message?
[22:20] <kierank> from the api
[22:21] <kierank> trying to build a filter graph
[22:21] <kierank> https://privatepaste.com/f85158bdc2
[22:22] <kierank> oh i think it's because the example is for a text graph
[22:22] <kierank> whereas I'm trying to use the API
[22:24] <llogan> useless info: i get that message using cli if i don't -map my output link label from the filtergraph
[22:25] <ubitux> oh shit
[22:25] <ubitux> it works
[22:26] <ubitux> without any debugging @_@
[22:26] <ubitux> let's benchmark the improvement of not doing full tranpose..
[22:30] <ubitux> BBB: hey, nice.
[22:30] <ubitux> 2746 decicycles in ff_vp9_loop_filter_h_88_16_ssse3, 4193698 runs, 606 skips
[22:30] <ubitux> it was 3058 before
[22:31] <ubitux> (C is 9233)
[22:31] <nevcairiel> and how much is v?
[22:31] <ubitux> 1932
[22:33] <ubitux> code is really ugly though
[22:33] <ubitux> dunno how to macrotize it in a sexy way
[22:37] <BBB> ubitux: nice
[22:38] <BBB> I wouldn't worry too much about the macro'ization, vp8 was always somewhat chaotic also and ... well, it works, so who cares
[22:41] <ubitux> BBB: i'll do in a later commit, that's gonna be a pain to squash with the original commit
[22:44] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/c67766dd3c48ac5188267e6a6f7ab3ffda008f05
[22:48] <BBB> ok cool
[22:48] <BBB> did you push the other 2 already?
[22:48] <ubitux> no :p
[22:48] <BBB> hm I think my commit msg for that latest one is also somewhat poor
[22:48] <ubitux> i have ~5 commits in queue
[22:49] <ubitux> i'll add a comment for the splat thing and probably push
[22:50] <BBB> so for the original, instead of doing punpcklbw x 8, you can movhps in the first 8 registers immediately
[22:50] <BBB> that'd be slightly faster
[22:50] <BBB> so instead of having 16 half registers, you'd have 8 registers where the lower half is the top 8 lines and the upper half (movhps) is the bottom 8 lines
[22:50] <BBB> and then fumble with that
[22:50] <ubitux> mmh
[22:51] <BBB> the butterflies then become bw, wd, dq instead of wd, dq, qdq
[22:51] <BBB> the advantage of that is that it skips the movq+punpcklXX into movhps
[22:51] <BBB> and at the end, you use movhps to get the upper half back out into the correct memory location
[22:52] <BBB> in the end, it saves you 8 punpcklXX per 16x8 transpose
[22:53] <ubitux> ok
[22:53] <ubitux> gonna try that
[22:54] <cbsrobot> Rodeo: ping
[22:56] <ubitux> BBB: so movhps m0, [P7]; movlps m1, [P6]; etc. or i misunderstood?
[22:58] <ubitux> cbsrobot: i'll review your patches this week
[22:58] <ubitux> or probably just apply
[22:58] <cbsrobot> ubitux: np - it' mostly your patch with some cosmetics from me
[22:59] <ubitux> yeah that first patch is awesome ;)
[22:59] <BBB> I think movq m0, [P7] movq m1, [P6] ... movhps m0, [Q0] movhps m1, [Q1] ...
[22:59] <cbsrobot> not sure the frame true peaks are really needed - but with it you can analyze the audio in detail
[23:01] <ubitux> BBB: mmh, isn't movq in the h part?
[23:01] Action: ubitux feels tired
[23:01] <BBB> maybe interleaved as you said, i.e. movq m0, [P7], movhps m0, [P6] movq m1, [P5] movhps m1, [P4] etc
[23:01] <BBB> no movq is in the low part
[23:01] <BBB> in gdb it's the last bits yes
[23:02] <BBB> but that's just intel vs gdb being odd, maybe endianness related
[23:02] <ubitux> mmh, yeah k
[23:03] <BBB> you know how people can be weird about that sort of stuff
[23:17] <ubitux> kierank: look at lavd/lavfi.c
[23:17] <ubitux> that's what is used when you ffplay -f lavfi testsrc
[23:17] <kierank> thanks
[23:17] <kierank> ubitux: are you going to fosdem btw?
[23:17] <ubitux> i don't think so
[23:18] <ubitux> i hate those meetings you know
[23:19] <kierank> i know you hate them
[23:19] <kierank> but fosdem is fun because you can go to interesting talks unrelated to multimedia
[23:21] <BBB> fosdem is very dirty, they really need to clean that place out
[23:21] <kierank> BBB: there are some new buildings
[23:21] <kierank> also the year you went it was snowing like hell and everyone brought water in 
[23:22] <ubitux> fosdem just sounds like another random boring geeks meeting talking about shit, drinking beer and eating crap
[23:22] <ubitux> dunno why ppl bother about taht
[23:22] <kierank> personally I am not going to many multimedia things
[23:22] <kierank> The radio stuff is quite interesting
[23:23] <ubitux> i'd better go to ccc next year, or another probably more interesting "meeting" thing
[23:23] <BBB> it's snowing in new york yet my office is spotless and clean
[23:23] <llogan> lol. people still trying to compile ffmpeg from SVN...
[23:23] <ubitux> still not disabled?
[23:24] <llogan> i'm not sure, and who knows where they get this stuff from
[23:25] <kierank> ubitux: seems very useful in fact, thanks again
[23:26] <llogan> ubitux: shit. it's still not disabled.
[23:41] <cone-907> ffmpeg.git 03Diego Biurrun 07master:50ecf1571235: avformat: utils: K&R formatting cosmetics
[23:41] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:896d6a7736c8: Merge commit '50ecf15712354a1d5b3f4dc9a57ff90ed7ee9654'
[00:00] --- Mon Jan 27 2014