[FFmpeg-devel-irc] IRC log for 2010-06-04

[irc at mansr.com]

[00:13:22] <Dark_Shikari> hmm, it seems that dc-only intra is common too.
[00:13:49] <mru> do you have a patch to actually use it too?
[00:15:05] <Dark_Shikari> Not one to use it non-hackily
[00:15:27] <mru> hard to test it otherwise
[00:15:43] <Dark_Shikari> You want a patch to test it with?  ok
[00:16:10] <Dark_Shikari> I'll just give you a diff of my local tree -- to test, just encode an flv (with a normal, unpatched ffmpeg) and use that as your test clip.
[00:16:28] <Dark_Shikari> idct_dc_add and idct_dc_put in mpegvideo.c are the C versions of the functions.
[00:17:33] <Dark_Shikari> mru: http://x264.nl/developers/Dark_Shikari/destroy_mpeg_decoder2.diff
[00:17:43] <Dark_Shikari> obviously not intended for commit -- but should be fine to test with.
[00:18:25] <Dark_Shikari> I may go back and merge some of the ideas from these changes though later -- e.g. clearing blocks during idct instead of decode
[00:24:21] <Dark_Shikari> And of course, given how hacky it all is, it's fine for you to hack yours in, e.g. #ifdef ARM call_arm_function #else call_c_function
[00:24:25] <Dark_Shikari> unless you're feeling non-lazy.
[00:28:35] <iive> Dark_Shikari: clearing blocks during idct, doesn't seem like good idea. one of the benefits of clearing block before using it, is that it's content should not be fetched from the main memry ;)
[00:28:47] <iive> it's its
[00:29:12] <mru> it'll still be fetched unless it's cache-line-aligned and you can store entire cachelines at a time
[00:29:52] <Dark_Shikari> iive: the decoder probably doesn't even fill L1D
[00:30:01] <Dark_Shikari> block[] probably stays in cache indefinitely
[00:30:44] <iive> Dark_Shikari: 32KB is way too small for that.
[00:31:07] <Dark_Shikari> no, 32kb is plenty, more than enough
[00:31:11] <Dark_Shikari> what would be in L1D?
[00:31:21] <Dark_Shikari> a few variables from mpegcontext (I stripped out most usage of this)
[00:31:25] <Dark_Shikari> the bitstream itself (a few cachelines)
[00:31:27] <Dark_Shikari> block[]
[00:31:37] <Dark_Shikari> about 30 cachelines of pixel data
[00:31:49] <Dark_Shikari> from the reference frame
[00:31:55] <Dark_Shikari> another 24 from the current frame
[00:32:05] <Dark_Shikari> a few cachelines for asm constants
[00:32:15] <Dark_Shikari> 32k?  probably doesn't even go over 16k.
[00:32:36] <iive> i'd believe that when i see it.
[00:33:20] <Dark_Shikari> oh, and a few kilos for vlc tables
[00:33:40] <Dark_Shikari> flv's are small though
[00:33:49] <Dark_Shikari> it only has one residual vlc table, not even varied based on intra vs inter
[00:42:01] <hyc> so it appears it's ok to commit AV_BASE64_SIZE and the three places that use it?
[00:43:23] <Dark_Shikari> ugh
[00:43:29] <Dark_Shikari> So there's no way to use gcc newer than 4.2 on apple shit?
[00:43:30] <Dark_Shikari> sucks.
[00:43:33] <Dark_Shikari> 4.2 was shit on arm
[00:43:50] <mru> compile to elf, disassemble, and feed apple's assembler
[00:44:03] <Dark_Shikari> does that actually work?
[00:44:08] <Dark_Shikari> and don't they use a different abi?
[00:44:09] <mru> no
[00:44:12] <mru> yes
[00:44:17] <Dark_Shikari> lol
[00:44:33] <mru> maybe you can instruct normal gcc to use the apple abi
[00:44:56] <Dark_Shikari> I'm going to hack the code to call your functions directly instead of using function pointers
[00:45:03] <Dark_Shikari> to avoid the pre-gcc-4.5 function pointer call penalty on ARM
[00:45:21] <mru> the fix applies nicely to 4.3
[00:45:34] <Dark_Shikari> well, it's still faster.
[00:45:48] <mru> a proper indirect call is no slower than a direct call
[00:46:49] <Dark_Shikari> You still have to load the register
[00:46:51] <Dark_Shikari> from memory
[00:47:16] <mru> I doubt that makes a measurable difference
[00:47:40] <Dark_Shikari> whatever, I'll do it anyways, not much to change.
[00:48:04] <Dark_Shikari> btw, I'm no longer using your dequant -- I integrated it into the decode instead, and it's faster
[00:48:05] <Yuvi> you have to load the function address from memory with apple too, they don't support movw/movt relocations
[00:48:07] <Dark_Shikari> I may backport that later.
[00:48:16] <Dark_Shikari> Yuvi: wow.  that sucks.
[00:48:22] <mru> Yuvi: not even for static builds?
[00:48:32] <mru> gnu ld.so refuses to support those relocs
[00:48:34] <mru> idiots
[00:48:39] <Yuvi> mru: nope, unless it's changed recently
[00:48:55] <mru> apple.. recent... hahahahaha
[00:49:52] <Yuvi> Dark_Shikari: could always try llvm-gcc or clang, those are better than 4.2 on arm nowadays
[00:50:33] <Dark_Shikari> They work with ipad/ipod?
[00:50:42] <Yuvi> yep
[00:50:46] <Dark_Shikari> and what's the difference, i.e. which should I use?
[00:50:46] <mru> iped
[00:51:08] <Yuvi> clang might have more bugs, llvm-gcc is harder to build
[00:51:30] <mru> I still haven't figured out how to make it cross-compile
[00:52:56] <Yuvi> mru: build llvm-gcc as a cross-compiler or cross-compile llvm?
[00:53:03] <Dark_Shikari> I recommended that to him and pointed him to this channel if he needs help, so... =p
[00:54:04] <mru> build as cross
[00:54:27] <Yuvi> looks like apple gcc 4.2 does indirect calls correctly
[00:54:42] <Dark_Shikari> oh, that's good.
[00:54:48] <Dark_Shikari> guess I can remove those ifdefs then
[00:55:03] <Dark_Shikari> Yuvi: are direct calls any faster on apple gcc ?
[00:55:05] <Dark_Shikari> given the code it generates
[00:57:40] <Dark_Shikari> mru: got some neon yet?
[00:58:12] <mru> 5min
[00:58:36] <Dark_Shikari> k
[00:59:00] * Dark_Shikari goes back to hack at residual decoding
[00:59:09] <Yuvi> no, it looks like what it does for inter-module direct calls is create a stub function to load the address, so it should be slower
[00:59:20] <Dark_Shikari> direct should be slower?
[00:59:22] <Dark_Shikari> or indirect
[00:59:34] <Yuvi> direct
[00:59:37] <Dark_Shikari> Wow.
[00:59:40] <Dark_Shikari> That is retarded
[01:00:05] <Yuvi> oh
[01:00:17] <Yuvi> I wasn't using -marm...
[01:00:24] <Yuvi> they're the same
[01:00:25] <mru> interworking...
[01:00:43] <mru> which isn't needed on modern arm cores
[01:00:51] <Dark_Shikari> what's "interworking"?
[01:01:04] <mru> stubs for switching between arm and thumb mode
[01:01:10] <Dark_Shikari> aha
[01:01:24] <mru> modern cores encode the mode in the lsb of the target address
[01:01:34] <mru> since like armv5
[01:01:52] <Dark_Shikari> That's a nice trick
[01:04:40] <Yuvi> mru: http://pastie.org/991385 if it helps you, I think most of those options were actually needed
[01:07:59] <mru> Dark_Shikari: http://pastebin.com/30AY5cNL
[01:09:06] <Dark_Shikari> k, so I just stuff these in simple_idc_neon
[01:09:17] <mru> that'll do
[01:09:44] <Dark_Shikari> also, am I supposed to do #ifdef ARCH_ARM or #if ARCH_ARM?
[01:09:50] <mru> if
[01:10:00] <Dark_Shikari> k
[01:12:37] <Dark_Shikari> will go test in a moment.
[01:16:00] <CIA-92> ffmpeg: hyc * r23461 /trunk/libavutil/base64.h: Add AV_BASE64_SIZE() macro
[01:16:34] <CIA-92> ffmpeg: hyc * r23462 /trunk/ (3 files in 3 dirs): Use AV_BASE64_SIZE() macro
[01:20:12] <Dark_Shikari> mru: question about arm and idct_dc
[01:20:24] <mru> go ahead
[01:20:27] <Dark_Shikari> on x86, it's faster to do paddusb/psubusb to add an int8_t to uint8_t data
[01:20:31] <Dark_Shikari> i.e. two arith ops instead of one
[01:20:37] <Dark_Shikari> this avoids having to do unpack/repack back to 8-bit
[01:20:46] <Dark_Shikari> Is this not better on ARM?
[01:20:58] <mru> I don't know what those insns do on x86
[01:21:04] <Dark_Shikari> packed add bytes with unsigned saturation
[01:21:08] <Dark_Shikari> packed sub bytes with unsigned saturation
[01:21:23] <Dark_Shikari> if you want to add int8_t Y to uint8_t X
[01:21:25] <Dark_Shikari> you can do
[01:21:29] <mru> neon doesn't have a saturating signed+unsigned
[01:21:34] <Dark_Shikari> neither does x86
[01:21:41] <Dark_Shikari> addusb( X, Y )
[01:22:04] <Dark_Shikari> subusb( X, 256 - Y )
[01:22:25] <Dark_Shikari> which gives the same results as unpacking, adding, and repacking
[01:23:02] <Dark_Shikari> hopefully you can see how this works.
[01:23:03] <mru> well, it's only 2 ops in neon
[01:23:18] <Dark_Shikari> isn't there an extra op, the vqmovun?
[01:23:19] <mru> add wide + pack/saturate
[01:23:37] <mru> load, add, pack, store
[01:23:38] <Dark_Shikari> are any of those slower than the non-complicated equivalent?
[01:23:42] <Dark_Shikari> i.e. is add faster than add wide?
[01:23:51] <mru> not in any relevant way
[01:24:02] <mru> my code shouldn't have any stalls
[01:24:09] <Dark_Shikari> couldn't you still do it faster by adding more values at once?
[01:24:12] <Dark_Shikari> i.e. 16 bytes at once instead of 8
[01:24:24] <Dark_Shikari> this would cut the number of instructions in half, not counting loads/stores
[01:24:58] <mru> it dual-issues on the load/stores anyway
[01:25:15] <mru> this code is entirely load/store-bound
[01:25:34] <Dark_Shikari> but doesn't neon code get executed "sort of" in parallel to non-neon code?  due to the 20 cycle delay
[01:25:44] <Dark_Shikari> I guess it doesn't matter
[01:25:46] <Dark_Shikari> it still is bound
[01:25:59] * Dark_Shikari curses the lack of fast scatter/gather load/store
[01:26:03] <mru> there isn't any non-neon code to execute in parallel with here
[01:26:17] <mru> do you have any idea how complicated that would be to make?
[01:26:18] <Dark_Shikari> wait a minute.  you could do half the number of loads
[01:26:21] <Dark_Shikari> load 16 bytes at a time.
[01:26:25] <Dark_Shikari> right?
[01:26:31] <mru> line_size
[01:26:34] <Yuvi> 8x8 block
[01:26:34] <mru> != 8
[01:26:35] <Dark_Shikari> From block[]
[01:26:40] <Dark_Shikari> Not from pixels.
[01:26:44] <mru> there is no block
[01:26:44] <Dark_Shikari> oh duh
[01:26:47] <Dark_Shikari> I'm stupid, ignore me.
[01:27:01] <Dark_Shikari> "there is no block, only zul"
[01:27:21] <Dark_Shikari> mru: why would, say, a strided, aligned-only gather load be horrifically bad to implement?
[01:27:33] <Dark_Shikari> e.g. "I want to load these 4 4-byte chunks, each of which is 16 bytes apart"
[01:27:45] <mru> the cache interface would become horribly complex
[01:27:45] <Dark_Shikari> and each of which is aligned to at least 4 bytes
[01:28:04] <Dark_Shikari> hmm, yeah, you'd need multiple simultaneous lookups
[01:28:05] <Yuvi> wouldn't the cpu just execute that the same as if you did it the way you do now?
[01:28:09] <mru> you'd have to be able to load from many more cachelines at once
[01:28:27] <Dark_Shikari> mru: well, my thought is, you could build from a unit that in the ideal situation could do tons of loads at once
[01:28:27] <mru> well, the cpu would have to be correspondingly more complicated
[01:28:31] <Dark_Shikari> and if ANY corner case occurs
[01:28:37] <Dark_Shikari> e.g. overlapping loads, crossing cachelines
[01:28:40] <Dark_Shikari> things that make things Hard
[01:28:43] <Dark_Shikari> you instantly stop parallelizing things
[01:28:47] <Dark_Shikari> and just do it the slow way
[01:28:57] <Dark_Shikari> that would allow you to get away with somewhat simpler hardware for tons of simultaneous loads
[01:29:05] <Dark_Shikari> since you no longer have to worry about conflicts.
[01:29:13] <mru> and how would you scoreboard that?
[01:29:18] <Dark_Shikari> "scoreboard"?
[01:29:38] <mru> track what data is where and when it's ready inside the pipelines and register files
[01:29:58] <Dark_Shikari> why would it be harder with multiple load units?
[01:30:02] <mru> I already had this discussion with a hardware designer
[01:30:11] <mru> the guy who designed neon in fact
[01:30:12] <pengvado> official reply from intel: can't read more than 1 block per cycle, and implementing even that much would add too much latency to memory accesses
[01:30:32] <pengvado> besides, what would that give you beyond pinsrd?
[01:30:32] <Dark_Shikari> why _latency_?  that seems odd
[01:30:39] <Dark_Shikari> pengvado: SAD that doesn't suck
[01:30:46] <Dark_Shikari> phenom beats the shit out of nehalem on SAD
[01:31:02] <Dark_Shikari> also, the larger your SIMD, the bigger a problem this is
[01:31:12] <pengvado> latency because that logic has to be in the memory-load unit, even if most instructions don't use it
[01:31:14] <Dark_Shikari> if you had 512-bit SIMd, how would you even _use_ it in an h264 encoder?
[01:31:48] <mru> multiple blocks in parallel probably
[01:32:01] <Dark_Shikari> blocks of what?
[01:32:06] <mru> pixels
[01:32:11] <Dark_Shikari> I mean, doing what?
[01:32:13] <mru> transforms, filters, whatever
[01:32:23] <Dark_Shikari> no matter what you'd still have to load multiple chunks into each register
[01:32:24] <mru> you could do 2 8x8 transforms side by side
[01:32:31] <Dark_Shikari> You can do that with 256
[01:32:38] <mru> so do 4
[01:32:39] <Dark_Shikari> 512 you'd need 4
[01:32:40] <pengvado> if you can only read one cacheline per cycle, and you don't even have a general 512-bit shuffle to reorder multiple nonadjacent blocks from one cacheline, what would hardware-assisted gather do?
[01:32:52] <Dark_Shikari> pengvado: you'd need more than one cacheline read per cycle, of course
[01:33:07] <mru> and that makes the cache horribly complex
[01:33:20] <Dark_Shikari> I can see why _writes_ would make it much more complex
[01:33:21] <Dark_Shikari> but why reads?
[01:33:32] <pengvado> if you can do that, why can't you execute multiple loads per cycle without any gather instruction?
[01:33:35] <mru> you'd have to couble all the tagging logic
[01:33:45] <Dark_Shikari> pengvado: instruction processing limit
[01:33:46] <mru> *double
[01:33:58] <mru> for two lines
[01:33:59] <Dark_Shikari> pengvado: also, where is this intel contact you have?  because that would be rather nice.
[01:35:00] <Dark_Shikari> also, pengvado, among the things the intel guy told you, anything interesting about what intel _can_ do?
[01:35:18] <Dark_Shikari> like "psatdb"? ;)
[01:35:35] <Dark_Shikari> psatdb xmm0, xmm1: calculates the 4x4 SATD of the bytes in xmm0 against the bytes in xmm1.
[01:35:49] <Dark_Shikari> that would totally be the best instruction ever.
[01:36:31] <pengvado> psatdb: no, they said that horizontal ops are inherently slow, and sumsub will never be faster than an add and a sub
[01:36:39] <Dark_Shikari> They can't even do it in hardware?
[01:37:27] <Dark_Shikari> they can do fancy stuff like mpsadbw that's totally useless, but they can't add ASICs for instructions that people actually care about?
[01:38:15] <Dark_Shikari> "do it in hardware" == just wire it out to a small chunk of silicon, even if there's some significant delay to doing so
[01:38:45] <Dark_Shikari> however it's done, it has to be faster than the horrible software munging.
[01:39:52] <mru> Dark_Shikari: what you describe is what companies like TI do
[01:39:57] <Dark_Shikari> Yeah, I know
[01:40:11] <Dark_Shikari> Intel does it too.  look at some of their instructions, they're insane
[01:40:17] <Dark_Shikari> They just don't do it for what we need.
[01:40:25] <pengvado> ah, it was the two dst version that they said couldn't be accelerated.
[01:40:32] <Dark_Shikari> but one dst could?
[01:41:02] <Dark_Shikari> We could say "psatdb will make x264 10-15% faster" and intel would jump on it like a graphics card company onto a pile of benchmarks
[01:41:51] <mru> the difference between benchmarks and lies is mostly indistinguishable
[01:47:49] <pengvado> just looked up the email. actually it says that there probably will be some future x86 with gather. just not any higher cache throughput that way than with ordinary loads. so if instruction decoding is the bottleneck, rather than anything involving uops, then maybe it will help.
[01:49:16] <mru> and replacing the instruction set with an easier to decode one isn't an option of course...
[01:54:03] <saintdev> maybe they should switch to arm :p
[01:55:31] <hyc> wasn't K5 based on AM29K?
[01:55:49] <hyc> they should just start exposing the micro-op engine
[01:57:45] <saintdev> yeah, but the k5 was a pos
[02:05:22] <mru> Dark_Shikari: any luck with the idct_dc?
[02:09:34] <kierank> is there an easy way to get gdb to give statistics on which is the most popular branch that is taken?
[02:12:49] <hyc> that sounds like something valgrind can give you
[02:12:55] <hyc> cachegrind
[02:14:21] <kierank> unfortunately, valgrind doesn't work with merbanan's binary loader but it's not that important
[02:38:59] <Compn> dump all cpu instructions to memory and then see whats used most? i'm probably making things up now...
[02:56:14] <astrange> try setting a gdb watchpoint on both destinations of the branch
[02:56:18] <astrange> it'll be really slow, though
[02:57:17] <kierank> that would work i guess
[03:28:26] <Dark_Shikari> mru: yup
[03:28:41] <Dark_Shikari> we're down to ~15-20ms in high motion
[03:28:43] <Dark_Shikari> 35ms peaks
[03:28:50] <Dark_Shikari> and we can basically do 30p smoothly
[03:29:06] <Dark_Shikari> Speaking of which, a coworker of mine came up with the greatest way possible to use this technology to piss off apple.
[03:29:27] <Dark_Shikari> At E3, open up an iPad, log in to a computer running OS X (via the video streamer), open Safari, and play a Flash game.
[03:30:19] <hyc> play a video off hulu while you're at it
[03:30:28] <Dark_Shikari> And open up Adobe Photoshop.
[03:30:41] <Dark_Shikari> Oh, and play a VP8 video.
[03:30:50] <ohsix> hur why would that piss them off, flash just can't be cleaned up enough to make it nice for something like the ipad
[03:31:17] <Dark_Shikari> because the things apple hates most on the ipad are flash and a desktop
[03:31:25] <Dark_Shikari> and putting flash and a desktop on the ipad will cause hilarious drama.
[03:31:38] <ohsix> sounds like a nonevent to me :[
[03:31:47] <Dark_Shikari> read techcrunch more often
[03:31:51] <Dark_Shikari> when steve jobs farts, it's front page news
[03:32:01] <ohsix> techcrunch is bullshit though
[03:32:20] <ohsix> you'll get some press, no doubt; but i wouldn't characterize it as pissing them off
[03:32:28] <Dark_Shikari> oh I know it's bullshit
[03:34:14] <Dark_Shikari> but the tech blogosphere thrives on bullshit.
[03:34:40] <ohsix> ya, techcrunch is a special breed tho
[03:35:07] <Dark_Shikari> no, it's just another valleywag
[03:35:17] <ohsix> i actually cringe at seeing stories on it getting around
[03:35:27] <Compn> Dark_Shikari : so you read these tech news sites... anyone writing articles about how ffmpeg is quickly becoming a major player in the multimedia realm? e.g. with google shipping it for chrome, youtube , nvidia/ati/intel all using it for hwaccel
[03:35:38] <Dark_Shikari> Compn: "quickly becoming"?
[03:35:41] <Dark_Shikari> it's been for half a decade
[03:36:49] <Compn> just thought more people would write about it
[03:36:51] <ohsix> every little chinese widget out there has some fun in it
[04:02:11] <hyc> hmm. ffserver doesn't parse ?date=xxx for rtsp streams, I wonder why not
[04:47:18] <CIA-92> ffmpeg: conrad * r23463 /trunk/libavcodec/x86/ (dsputil_mmx_avg_template.c dsputil_mmx.c): Add bitexact versions of put_no_rnd_pixels8 _x2 and _y2 for vp3/theora
[05:06:00] <peloverde> "Is there any chance that ffmpeg just include the libvorbis source code and just build it by default?" Blol
[05:06:49] <Dark_Shikari> lol
[05:08:16] <ohsix> build it at runtime with tcc
[05:11:03] <peloverde> I found it on the FOMS list when I found out that there is goign to be foms within a days drive of me
[05:11:12] <peloverde> but it seems to be mostly just xiph people?
[05:27:42] <_av500_> the only true free and open media people!
[05:31:37] <peloverde> Where is superdump when I need him? IIRC he went to FOMS once
[05:49:04] <peloverde> kshishkov, no distopian comments on the status quo in the ukriane this morning?
[05:52:44] <kshishkov> peloverde: I did not care much about it even when I lived there
[05:55:26] <peloverde> we always used to say "Good morning kshishkov" and you would respond "terrible morning <rabble rabble>"
[05:55:38] <peloverde> it was your thing, like bcoudurier's onjoin script
[05:56:07] <peloverde> or my love/hate relationships with MPEG and Google
[05:56:12] <kshishkov> I usually reply "god morgon" unless some Swiss Turk implies it's also wonderful
[05:57:12] * elenril thinks the morning is wonderful
[05:57:48] * kshishkov thinks this morning is not bad at least
[05:58:30] <elenril> that is except me living at the construction site
[06:00:12] * peloverde guesses he will have to fill the void by complaning about Cleveland "the mistake by the lake"
[06:00:38] <elenril> you can fill the void by removing faad ;)
[06:00:42] <kshishkov> there's no need, even I know that "gone to Cleveland" is an euphemism
[06:01:35] <kshishkov> elenril: in Ukraine I usually had neighbours doing repairs all the year round.
[06:01:52] <peloverde> In our defense "Our number one export is crippling depression" implies we still have exports
[06:06:34] <kshishkov> and once your local bank issues dollar notes...
[06:06:54] <peloverde> We still have a Federal Reserve Bank
[06:18:31] <elenril> kshishkov: http://img684.imageshack.us/img684/9641/shot0001f.png my interwebz access point
[06:20:10] <peloverde> my interwebz access point is a graveyard for broken chairs that we call "the library" (formerly "the map room")
[06:22:10] * elenril wishes he had a chair there
[06:26:45] <peloverde> my access point http://imgur.com/a/T8SR2/the_library
[06:27:37] <ohsix> did you get raided/have a search warrant executed?
[06:28:18] <ohsix> oic nm
[06:33:09] <peloverde> PS despite the xmas tree and santa clause in those pictures, they were taken today
[06:36:03] <CIA-92> ffmpeg: mstorsjo * r23464 /trunk/libavformat/http.c:
[06:36:03] <CIA-92> ffmpeg: http: Set http_code to 200 when doing a POST
[06:36:03] <CIA-92> ffmpeg: This avoids reading and comparing uninitialized memory.
[06:43:33] <CIA-92> ffmpeg: mstorsjo * r23465 /trunk/libavformat/rtspenc.c: rtspenc: Write the interleaving header in the same buffer as the packet data
[06:53:13] <kshishkov> peloverde: usually people in Ukraine get rid of Christmas tree by 1st of May
[06:55:36] <Tjoppen> brought beer to work today \o/
[06:56:12] <wbs> \o/
[06:56:23] <merbzt1> \o/
[06:56:58] <Tjoppen> summer party. about 60 people. free beer (but I had to bring some fancy ones for myself)
[07:02:41] <spaam> Tjoppen: dont you like the free ones? ;)
[07:02:51] <j0sh_> wbs: had an intersting bug when changing url_open/url_read behavior
[07:03:34] <j0sh_> when doing the initial GET, we never get a reply in the body but the cxn is kept open so the read hangs
[07:03:52] <j0sh_> and the function never returns
[07:04:23] <j0sh_> i "fixed" it by special casing the buffer and size parms for that one situation
[07:04:37] <wbs> did you try to do a simple url_read() in order to force the connection to be opened?
[07:04:55] <j0sh_> yes
[07:05:03] <wbs> what did you intend to do with the data you read back then?
[07:05:20] <j0sh_> wait, what do you mean force the connection to be opened?
[07:05:35] <j0sh_> i have to do a url_read anyway to send out the headers
[07:05:54] <wbs> yes, but whenever you do url_read, you have to _read_ some data, right?
[07:05:58] <j0sh_> but it hangs because the connection is still open and it's waiting for data in the body
[07:06:02] <wbs> yes
[07:06:18] <wbs> and I'm saying, your logic is flawed, since you can't just read some data out from a stream and discard it
[07:06:28] <wbs> let's say you actually got a reply
[07:06:39] <j0sh_> but no data is coming in, only the headers (which are stripped)
[07:06:54] <wbs> yes, but let's say the server actually did send something
[07:07:16] <wbs> I was trying to explain this to you yesterday evening too, but you didn't seem to get it then, let's try again now
[07:07:46] <wbs> let's pretend, hypothetically, that you actually sent a request on the POST channel already
[07:07:51] <wbs> you're getting a reply on the GET channel
[07:08:04] <j0sh_> ok
[07:08:20] <Tjoppen> spaam: that too. but I bought a couple of nice ones from systembolaget yesterday that I have to try
[07:09:13] <wbs> when you do the url_read() that you're doing just to force the HTTP GET request to be made, 1) what buffer do you give to url_read(), 2) how many bytes are you trying to read? 3) what are you going to do with the bytes you've read? 4) what will happen afterwards, when the real user of the data will try to read from the http urlcontext?
[07:09:36] <j0sh_> i just pass in NULL and 0 for the buffer and its size
[07:09:47] <wbs> oh, ok
[07:09:54] <wbs> I'm not sure if that's supported, or supposed to be supported
[07:10:00] <j0sh_> (the null actually segfaults)
[07:10:10] <spaam> Tjoppen: what kind of beer is the free ones?  kung and/or sofiero?
[07:10:11] <j0sh_> if i just pass in an ordinary pointer with size 0, it will work too
[07:10:43] <Tjoppen> dunno. I thought I'd at least bring an Innis & Gunn India Pale Ale :)
[07:11:04] <spaam> Tjoppen: ok :)
[07:11:13] <Tjoppen> don't think kung is sold any more. haven't seen one in years
[07:11:50] <wbs> so, BBB's point with doing it implicitly delay opened, is that normal/correct usage of the API shouldn't need to know that the connection actually is made on the first url_read, when you're actually trying to read some data that you're going to use
[07:12:01] <j0sh_> right
[07:12:05] <j0sh_> thats what im doing
[07:12:08] <spaam> Tjoppen: i have seen it here in Ronneby when i was at bolaget last weekend :)
[07:12:16] <j0sh_> lemme push my patches onto github
[07:12:20] <Tjoppen> *shudder*
[07:13:35] <wbs> for this particular case, in addition to delay opening, we actually need an API for forcing it to open the http connection right now. then it can either be a ff_http_* function, or adding extra handling of NULL/zero-sized buffers to the http_read function
[07:14:24] <j0sh_> the latter is what i did, yeah
[07:15:32] <wbs> yes, and I didn't actually think of that approach earlier - it may work, but I'm not sure. in one way, I'd prefer the much more explicit form of an ff_http_* function, since doing an url_read() with zero size feels like raping the API a bit
[07:15:55] <wbs> but I'd wait for comments from BBB on what he thinks about that
[07:17:31] <elenril> anybody can apply a patch for me?
[07:17:45] <j0sh_> wbs: yeah i wasn;t sure which way to go, new api func or special-casing params
[07:18:18] <j0sh_> so i just picked the one that was the least work :)
[07:18:29] <wbs> elenril: sure, which one?
[07:18:58] <elenril> wbs: thread  adding callbacks to metadata conversion, only patches 2 and 3
[07:19:35] <wbs> ok, one moment
[07:22:09] <wbs> ummm, doesn't seem to apply cleanly
[07:22:41] <wbs> .. since it's based on part 1 from that series
[07:24:36] <elenril> oh, one sec
[07:24:41] * elenril cherrypicks
[07:29:39] <elenril> wbs: http://filebin.ca/wtanvx/0001-metadata-make-conversion-to-the-same-format-a-noop.patch
[07:29:54] <elenril> http://filebin.ca/zbmgpw/0002-reindent-after-previous-commit.patch
[07:32:57] <CIA-92> ffmpeg: mstorsjo * r23466 /trunk/libavformat/metadata.c:
[07:32:57] <CIA-92> ffmpeg: metadata: make conversion to the same format a noop.
[07:32:57] <CIA-92> ffmpeg: Patch by Anton Khirnov, wyskas at gmail
[07:34:22] <CIA-92> ffmpeg: mstorsjo * r23467 /trunk/libavformat/metadata.c:
[07:34:22] <CIA-92> ffmpeg: reindent after previous commit.
[07:34:22] <CIA-92> ffmpeg: Patch by Anton Khirnov, wyskas at gmail
[07:36:01] <MrNaz_yma> when building ffmpeg/x264 from source with the current tarballs, Dark_Shikari once told me that to avoid issues with ffmpeg/x264 co-dependencies i can compile it either statically or non-statically but i cant remember which... which was it?
[07:36:55] <elenril> wbs: thanks
[07:38:27] <wbs> j0sh_: when updating your rtsp-tunneling branch, btw, make sure you rebase it on top of the latest stuff from earlier today... both the rtspenc update, AV_BASE64_SIZE and http post fix are useful for you
[07:43:13] <KotH> salut mes amis
[07:43:35] <j0sh_> ah, i push --forced it
[07:43:42] <j0sh_> ohh
[07:43:54] <j0sh_> alright
[07:43:57] <MrNaz_yma> oops... didn't mean to put that in -devel...
[07:44:19] <j0sh_> (push-forced my branch, so my commits from yesterday are gone)
[07:45:05] <elenril> use the reflog?
[07:48:17] <wbs> j0sh_: in the disable chunked commit, instead of the inline is_chunked check for url_write(..., temp), you could just do temp = "" where it's declared
[07:48:52] <wbs> but I guess it's a matter of taste - imo the large if statement with three url_writes is more than complex enough as it is
[07:49:52] <wbs> j0sh_: in the "add rtsp_hd_out" patch, you missed one url_close(rt->rtsp_hd) in rtspenc
[07:50:33] <wbs> and for the documentation of the rtsp_hd_out, I think hd stands for handle, not handler, but I'm just guessing
[07:51:56] <j0sh_> alright
[07:52:09] <wbs> j0sh_: in the doxy of RTSPMode, you've got tunnelled spelled with two l's, contrary to other places
[07:52:33] <j0sh_> i know, every time i say 'tunnelled' i get red sqiggly lines
[07:53:06] <j0sh_> so i think it's misspelled (which is funny because the spec specifies a header value with that spelling)
[07:53:21] <j0sh_> 'tunneled' spellchecks fine tho
[07:53:27] <wbs> yeah
[07:53:54] <wbs> you've got a similar thing in the "set up initial handshake for tunnelling" comment in ff_rtsp_connect, too
[07:54:11] <j0sh_> heh ok i'll grep it
[07:54:48] <wbs> except for those things, it looks quite good I think
[07:55:20] <j0sh_> ok awesome
[07:55:37] <wbs> I'd say move the if (!(buf && size)) return 0; to outside of the if !init clause
[07:55:47] <j0sh_> working on a last patch, lu_zero wanted to propagate send_cmd errors
[07:56:01] <wbs> since if you do allow url_read(..., NULL, 0), you should allow it consistently, not only for the first read
[07:56:40] <j0sh_> alright
[07:57:07] <wbs> and I'd reword the comment not to mention rtsp-http, since it's a generic mechanism, e.g. "Allow using a null buffer and size to force initialization of the connection"
[07:57:37] <wbs> the fact that it can make rtsp-http hang is just a rtsp specific problem that it solves
[07:57:53] <MrNaz_yma> i've heard that someone has taken up some ffserver development... if that's the case i'd like to find out who, as i am probably the most active ffserver user who frequents the channel, and have been using it in a production environment for over a year now
[07:57:59] <j0sh_> yeah the "force initialization of the connection" is why i put it in the if clause
[07:58:12] <j0sh_> caus otherwise it should already be initialized
[07:58:52] <wbs> yes, that's the intent of it, but still, a null buffer and/or size is allowed, it should always be allowed, not only for the first call
[07:59:11] <j0sh_> ok
[07:59:31] <wbs> MrNaz_yma: hyc has been working a bit on it lately
[07:59:39] <j0sh_> if someone happens to pass in one or the other (but not both), then weird things will happen :)
[07:59:40] <wbs> MrNaz_yma: and I've been trying to get some of the patches committed
[08:00:21] <wbs> j0sh_: yeah, passing a null buffer with nonzero size obviously is an error
[08:00:34] <wbs> perhaps it would be more correct simply to do if (!size) return 0;
[08:00:58] <wbs> then the buffer pointer doesn't matter at all
[08:00:58] <j0sh_> or if(!buf), even?
[08:01:06] <j0sh_> because a null buffer will segfault
[08:01:12] <j0sh_> but a zero size won't do anything
[08:01:28] <MrNaz_yma> wbs ok cool... well i'd be _very_ interested to get involved in that, i'm no coder but i can do things like patch testing and feedback on feature priority
[08:01:44] <wbs> yes, but doing url_read(c, NULL, 1234) obviously is an error
[08:02:02] <wbs> and segfaulting is better than making the API do something completely different
[08:02:18] <wbs> your patch would make that a noop that wouldn't ever be noticed
[08:02:31] <j0sh_> hm ok
[08:02:59] <wbs> but on the other hand, doing url_read(c, whatever, 0); is asking to read 0 bytes, which means you can return immediately
[08:03:09] <j0sh_> makes sense
[08:08:05] <lu_zero> good morning
[08:08:19] <wbs> morning
[08:08:22] <Honoome> good? where?
[08:08:35] <wbs> Honoome: apparently at lu_zero's place? :-)
[08:09:19] <lu_zero> =)
[08:09:34] <wbs> it's friday, so it can't be that bad anyway
[08:09:47] <lu_zero> if isn't there it's your task making it good
[08:10:51] * lu_zero is too sleepy to know if it's good or not
[08:12:41] <Honoome> well I'm going to have the beach episode of my life's anime this weekend so today I'm only arranging for the backlog…
[08:13:04] <Honoome> [and yes this writes me off as too much of a geek just for the phrase I used]
[08:14:16] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BeachEpisode ?
[08:16:37] <lu_zero> Honoome: the fact I'm not understanding is telling much
[08:17:25] * kshishkov finds only one good thing about those - watermelons
[08:18:59] <lu_zero> yawn
[08:19:16] <lu_zero> feng dies badly on high load and enough fd -_-
[08:19:26] * lu_zero should go hunting for that bug
[08:22:04] <j0sh_> lu_zero: i REALLY like the git workflow
[08:22:31] <wbs> yeah, it's quite frickin fantastic compared to just about everything else :-)
[08:22:42] <j0sh_> took me all day to get comfortable with everything (i lost a couple of commits in the process) but its really nice
[08:23:10] <wbs> j0sh_: for fixing up patch series for submission, are you familiar with rebase -i?
[08:23:12] <Honoome> elenril: that's the thing… I'm just afraid of the lack of female characters, but still…
[08:23:25] <lu_zero> =)
[08:23:34] <merbzt1>  j0sh_: a blog post about the workflow would be really nice
[08:23:35] <j0sh_> wbs: yup, thats what im doing
[08:23:42] <wbs> j0sh_: good, good. :-)
[08:24:00] <lu_zero> j0sh_: having you as testimonial might help the movement for git in ffmpeg
[08:24:01] <Honoome> lu_zero: which parameters do you use on the run_a_lot?
[08:24:01] <j0sh_> merbzt1: i can do that to inaugurate my blog :)
[08:24:08] <lu_zero> the usual 100 10
[08:24:13] <j0sh_> lol
[08:24:24] <wbs> j0sh_: instead of manually editing old commits, you can also do a new commit with the change, then rebase -i and move the new commit next to the one you want it integreated with, and change it's command to squash
[08:24:43] <Honoome> lu_zero: with 10240 filenos?
[08:24:47] <lu_zero> yes
[08:24:54] <lu_zero> let me prepare a bugreport
[08:25:05] <j0sh_> wbs: ah, that's one way to do it. i've been editing commits all along
[08:25:28] <j0sh_> but i suspect your way is less error prone
[08:25:31] <wbs> yeah, I choose either one depending on situation
[08:30:55] <Honoome> ==18898==     in use at exit: 89,426 bytes in 985 blocks
[08:30:55] <Honoome> ==18898==   total heap usage: 2,798,686 allocs, 2,797,701 frees, 3,159,623,756 bytes allocated
[08:31:02] <Honoome> valgrind didn't find anything bad with feng…
[08:31:56] <lu_zero> helgrind's turn?
[08:32:06] <Honoome> would be a nice idea to increase the clients limit of course
[08:32:44] <Honoome> k now it crashed (outside of valgrind)
[08:43:42] <lu_zero> inside valgrind is valgrind to barf ^^;
[08:43:47] <lu_zero> too big for it
[08:45:49] <Honoome> no inside valgrind it's protected… I got a straight stack overflow in gdb, and valgrind reporting uninitialized values as part of the session
[08:47:26] <wbs> Honoome: btw, are you using select() for code that uses file descriptor numbers larger than 1024?
[08:48:52] <Honoome> guess so
[08:49:20] <wbs> the fdsets for select on linux only supports file descriptor numbers up to that value, for larger values you need to use poll instead of select
[08:49:47] <Honoome> lu_zero: go rewrite the UDP send code :P
[08:58:11] <lu_zero> let me move to the office and I'll do
[08:58:32] <lu_zero> we have libev btw...
[08:58:38] <kshishkov> are you intending to replace Berlusconi with yourself?
[08:58:41] <lu_zero> so we shouldn't fall in that issue...
[08:59:05] <lu_zero> kshishkov: I'm not that fat, old, crooked and short
[08:59:07] <Honoome> kshishkov: I'm fine with replacing that with a 12-yo…
[08:59:11] <lu_zero> so couldn't
[08:59:17] <Honoome> lu_zero: but you have hair!
[08:59:25] <Honoome> [and so much of those ^^;;]
[08:59:32] <lu_zero> that is another difference
[08:59:39] <lu_zero> and I'm in late!
[08:59:41] <kshishkov> well, "let me move to the office and I'll do" sounded like election promise
[09:00:15] <lu_zero> kshishkov: its mostly a "If I start messing up code now I won't appear in the office"
[09:00:32] <lu_zero> and I'm afraid the others won't come so I should ^^;
[09:00:37] <Honoome> “and thenews would be?”
[09:00:42] <Honoome> ah that would explain it
[09:00:47] <Honoome> so go go go go go! >_<
[09:01:28] <lu_zero> Honoome: it's pointless for me be in the office if there is already some one and I don't have to work with him
[09:01:34] <lu_zero> eh eh
[09:01:47] <lu_zero> in about 30-40 min I'll be back...
[09:24:00] <Tjoppen> "Input Stream #0.0 frame size changed to 4096x3112, yuv420p"  any particular reason why this could happen, even though I set pix_fmt to rgb48be in the demuxer?
[09:24:54] <kshishkov> fourcc points on different rawvideo pixfmt?
[09:26:08] <Tjoppen> that's what I suspected. baptiste didn't like me using avcodec_pix_fmt_to_codec_tag()
[09:26:17] <Tjoppen> in mxfdec.c
[09:27:05] <Tjoppen> I changed it so it doesn't do that. the question then is if it comes up with some other codec_tag along the way (it's not set by the demuxer)
[09:29:40] <wbs> j0sh_: it looks very good now
[09:30:14] <j0sh_> awesome
[09:30:17] <wbs> j0sh_: in the custom headers http commit, though, you're filling s->headers if it isn't already set
[09:30:27] <wbs> which gives problems if you do another http request with the same urlcontext
[09:30:31] <wbs> which is done e.g. if you do seeks
[09:30:44] <j0sh_> *rubs eyes*
[09:30:57] <wbs> so for the second request, you wouldn't actually get any updated headers at all
[09:32:19] <Tjoppen> hm. rawdec.c might be responsible
[09:32:20] <j0sh_> oh i see what you mean
[09:33:10] <wbs> good :-)
[09:33:57] <wbs> also, the spelling fixes ended up partly in the wrong commit, so the rtsp_hd_out initially has a doxy with a spelling error, while the next commit fixes it
[09:34:12] <wbs> and you still have "handler" instead of "handle" at some places
[09:34:18] <j0sh_> ah missed that
[09:34:22] <Tjoppen> does checking for pix_fmt == PIX_FMT_NONE seem like a good idea to prevent rawdec.c from overriding whichever setting the demuxer detected?
[09:34:30] <j0sh_> i think thats a sign its time to get some sleep :)
[09:34:59] <wbs> heh, isn't it like 2:34 over there? ;P
[09:35:06] <j0sh_> yep
[09:35:14] <wbs> sleep probably is a very good idea, then. ;P
[09:35:15] <j0sh_> been wrking on this since like 7:30a too
[09:35:36] <j0sh_> those fixes took a loooooooong time
[09:36:01] <j0sh_> mostly caus ofmy weak git-fu
[09:36:13] <j0sh_> kept messing things up but i'm getting the hang of things
[09:36:17] <wbs> I guess it's improving fast, at least :-)
[09:37:15] <j0sh_> yeah this is a lot of fun. beats spending the summer at BigCo
[09:39:27] * j0sh_ is out
[09:39:34] <kshishkov> well, your employer for this summer is SmallSearchingCo
[09:42:10] <pJok> god middag, kshishkov :)
[09:42:38] <kshishkov> god dag, pJok
[10:05:42] * lu_zero is back
[11:39:00] <lu_zero> interesting enough using poll instead of select fixes the issue quite well
[11:39:41] <mru> on what OS?
[11:39:50] <lu_zero> linux
[11:40:26] <lu_zero> using select with fd > 1024 is a recipe for subtle disasters indeed ^^;
[11:40:32] <mru> heh, yes
[11:40:58] <lu_zero> the annoying part is that now it seems using a bit too much cpu =|
[11:41:24] <lu_zero> around 400 attached clients it starts to stutter =E
[11:41:45] <mru> try some of the more esoteric alternatives like epoll
[11:41:58] <mru> linux-specific but more efficient than plain poll
[11:42:01] <av500> e=esoteric?
[11:42:09] <mru> of course
[11:43:56] <lu_zero> uhmm
[11:44:06] * lu_zero switches to tcp to see what happens
[11:45:02] <lu_zero> doesn't break as well but crawls indeed
[11:47:53] <lu_zero> the topix box can serve properly at most ~200 clients
[11:48:12] <lu_zero> ~100 concurrent requests
[11:51:18] <lu_zero> wbs and Honoome could you pull and test on your hw?
[11:51:27] * lu_zero goes fetching something to eat
[12:19:45] * mru finally got the full TRM for the omap4 video accelerators
[12:21:27] <Kovensky> <@lu_zero> using select with fd > 1024 is a recipe for subtle disasters indeed ^^; <-- o_O
[12:21:32] * av500 finally got the tegra today :)
[12:21:44] * pJok snapdragons mru 
[12:23:34] * pJok has a snapdragon
[12:23:51] <av500> in your mobile phone?
[12:25:01] * mru has one in his
[12:25:09] <lu_zero> Kovensky: ?
[12:25:23] <av500> http://twitter.com/shitmydadsays/status/5427015317
[12:25:46] <Kovensky> lu_zero: why are large FDs magic
[12:26:01] <lu_zero> because select barfs silently on them
[12:26:03] <Kovensky> (and why did xchat copy the colors even though I didn't tell it to)
[12:26:13] <wbs> Kovensky: because select uses a data structure called fdset, which is a bit set with one bit for each possible fd
[12:26:19] <wbs> up to 1024
[12:26:43] <wbs> if you want to use fds with values higher than that, don't use select (which has such an implementation of fdsets)
[12:26:49] <Kovensky> ic
[12:26:51] <wbs> on some platforms it isn't a bitset
[12:27:18] <lu_zero> now feng seems to handle the load
[12:28:05] <lu_zero> now the problem is comparing it with dss and see which scales better
[12:39:11] <Honoome> lu_zero: if you wish we could also go to make sure that we don't allocate 1440 bytes arrays on heap…
[12:39:53] <Honoome> err s/heap/stack/
[12:44:37] <lu_zero> where?
[12:45:19] <lu_zero> Honoome: rejoice we already noticed that http might enjoy a dict type =)
[12:47:43] <Honoome> how, where and when?
[12:48:01] <Honoome> and as for where, amr.c in feng, uses a stack-allocated MAX_MTU_SIZE buffer
[12:48:17] <Honoome> sorry DEFAULT_MTU buffer
[12:48:55] <Honoome> in the rtcp read we also have a 3000 bytes buffer on stack…
[12:49:13] <Honoome> I suggest we start by using slices for the 1440-sized buffers, should reduce allocation time
[13:18:09] <lu_zero> how <- right now the http proto keeps the headers in a flat array
[13:18:12] <lu_zero> where <- ffmpeg
[13:18:25] <lu_zero> when <- once j0sh implemented http-tunnel =P
[13:18:59] <lu_zero> Honoome: regarding slices it's worth trying
[13:31:23] <lu_zero> hi BBB
[13:31:44] <BBB> hi
[13:37:16] <Honoome> I can't believe this…
[13:37:32] <Honoome> actually having enums starting from -1 (for invalid values) can increase the generated code size with gcc (-O0, but still!)
[13:37:53] <Honoome> it's minimal, but the change is there
[13:43:32] <mru> used in a switch statement?
[13:43:43] <Honoome> not limited to
[13:43:57] <mru> if the enum has no negative values defined, the compiler can treat it as unsigned
[13:44:05] <mru> which sometimes gives smaller code
[13:44:29] <Honoome> in this case most of the changes seem to relate to GINT_TO_POINTER macros (from glib)… the gain is nil with -O2, but at -O0 produces 2 bytes less per call…
[13:45:10] <Honoome> given that the code that was emitting those enums is auto-generated, and that the values can be totally random for what I'm concerned, I made it start from 0 to be unsigned ^^;;
[13:48:30] <Honoome> now if only I could have something to tell me the size of stack allocations in various cases it wouldn't be too bad
[13:49:31] <mru> objdump+perl
[13:49:55] <mru> sometimes gcc -S puts such info in comments
[13:53:41] <CIA-92> ffmpeg: mstorsjo * r23468 /trunk/libavformat/avformat.h:
[13:53:41] <CIA-92> ffmpeg: metadata: mention how to remove tags.
[13:53:41] <CIA-92> ffmpeg: Patch by Anton Khirnov, wyskas at gmail
[15:31:27] <_av500_> KotH: \\\ooo///
[15:41:02] <KotH> _av500_: :-)
[15:41:27] <KotH> _av500_: zwischen 15 und 20 grad lagern, nicht in den kühlschrank tun ;)
[15:46:28] <lu_zero> ?
[15:48:19] <mru> chocolate
[15:55:42] <BBB> ?
[15:57:08] <j0sh_> wbs: regarding sending headers ater a seek or whatever -- are you saying that we should reevrrt to the default options unless the user re-sets his custom headers again?
[16:01:40] <wbs> j0sh_: no
[16:02:26] <wbs> j0sh_: but if the user hasn't set any custom headers at all, and do the first http request, your code writes it into s->headers
[16:02:42] <j0sh_> right
[16:02:49] <wbs> so when you do the second request later on a seek, s->headers will be initialized, just in the same way as if you would have set custom headers
[16:03:39] <j0sh_> but why re-fill s->headers?
[16:04:06] <wbs> since the seek parameter is set there
[16:04:07] <j0sh_> for s->off, you mean/
[16:04:11] <j0sh_> ?
[16:04:12] <wbs> yes
[16:04:15] <j0sh_> ok
[16:04:44] <lu_zero> seek?
[16:05:05] <j0sh_> Range: header
[16:06:14] <j0sh_> do you think it's safe if we always put in the range, no matter what?
[16:06:26] <j0sh_> (which is what we were doing before anyway)
[16:06:47] <lu_zero> in http?
[16:06:54] <j0sh_> yeah
[16:07:00] <lu_zero> the proper way would be
[16:07:30] <lu_zero> -> import/write a dict/hash/whatever datatype
[16:07:51] <lu_zero> have the headers using that
[16:08:00] <lu_zero> so you can set/get them with ease
[16:08:51] * lu_zero is actually looking at http://github.com/antirez/redis/blob/master/dict.c for ideas
[16:09:48] <lu_zero> I'll be back in a while
[16:09:50] <j0sh_> if its really that important, i can make an avdictionary or something
[16:10:11] <lu_zero> if it doesn't bore you to death please do =)
[16:12:41] <j0sh_> nah, re-inventing common data structures is quite fun actually :)
[16:12:54] <lu_zero> great =)
[16:13:09] <j0sh_> ...but at the same time i want t move on to other tasks
[16:13:20] <peloverde> Does anyone have and experience streaming to iPhone using FFmpeg+Wowza? I know someone who's willing to pay for some help/consulting
[16:13:27] <j0sh_> can we add this as another todo, so i can revisit it later in the summer?
[16:13:34] <lu_zero> peloverde: why wowza?
[16:13:49] <lu_zero> j0sh_: sure
[16:14:08] <lu_zero> peloverde: streaming to iphone -> rtsp
[16:15:17] <lu_zero> probably I could be interested
[16:15:34] <lu_zero> can we chat about it in 30-40min?
[16:15:42] <peloverde> sure
[16:16:01] <lu_zero> I'd like to first know what's the purpose
[16:16:12] <lu_zero> but now I really need to move ^^;
[16:39:10] <Compn> peloverde : hyc does that i think
[16:39:33] <Compn> he was using ffserver to relay rtmp > rtsp > iphone
[16:39:54] <peloverde> thanks
[16:51:50] <wbs> Compn: no, that's for android
[16:52:14] <wbs> iphone doesn't do rtsp at all, only static mp4/3gp-files, and apples http live streaming using segmented mpegts
[16:55:44] <peloverde> The setup they have is rtmp > ffmpeg  > rtmp > wowza > http > iPhone
[16:58:24] <peloverde> iphone really needs something more flexible than http streaming
[16:58:38] <mru> iphone needs to die
[16:59:10] <peloverde> I'd rather have healthy competition between iphone and android
[16:59:25] <mru> iphone isn't healthy in way whatsoever
[16:59:26] <peloverde> iPhone just needs to get their head out of their ass on a few things
[16:59:39] <mru> like being apple
[17:00:23] <peloverde> repeal the ridiculous appstore policies and use the same ABI as the rest of the world
[17:00:41] <mru> but that's not the apple way
[17:00:51] <mru> that would give users a choice
[17:00:56] <mru> and choice isn't good for apple
[17:01:05] <mru> because then they might not choose apple
[17:02:23] <peloverde> A lot of the anti-portablilty policies seem to try to leverage their market position into a lock-in, if they become a minority player they will be forced to change
[17:17:27] <lu_zero> here I am
[17:22:39] <Compn> wbs : ah, i thought it might have been android :\
[17:23:27] <Compn> segmented mpegts, wow.
[17:30:50] <BBB> mru: you can complain for all you want, but before the iphone, arm was completely irrelevant. now, it's the killer thing. it gives you work ;)
[17:31:22] <mru> I get very little work on iphone
[17:31:37] <kierank> "arm was completely irrelevant" --> that is highly debatable
[17:31:41] <mru> iphone is a tiny sliver of the arm market
[17:32:05] <peloverde> I think you failed to notice BBB's ;)
[17:32:20] <mru> peloverde: some people actually believe that
[17:32:40] <peloverde> most people are stupid
[17:33:03] <BBB> most of those people have an iphone
[17:33:06] <mru> yes, that is my working assumption
[17:33:06] * BBB has an iphone
[17:33:21] <mru> that people are stupid, that is
[17:33:36] <kierank> BBB: do you show it off to people like you invented it? ;)
[17:34:10] <peloverde> I have an iPhone but as soon as the contract expires or att gets (a decent) android i am switching
[17:34:21] <BBB> peloverde: that's exactly the problem
[17:34:24] <BBB> I've said that for two years
[17:34:28] <BBB> I'm still friggin' waiting
[17:34:42] <BBB> that is the one and only thing that I thank apple for - they "get" it
[17:34:51] <mru> the US is a backwards place phonewise
[17:34:58] <BBB> compared to japan?
[17:35:03] <mru> compared to nigeria
[17:35:51] <BBB> I'll give you that I totally don't see the appeal of the blackberry
[17:35:56] <BBB> I mean, that thing is hideous and unusbale
[17:36:03] <mru> it's a business thing
[17:36:23] <mru> I can see the point for a large company to have a bunch of phones tethered to their servers
[17:36:58] <peloverde> blackberry's e-mail support is lightyears ahead of iPhone
[17:37:22] <BBB> I've heard that, and the messaging argument
[17:37:40] <hyc> what's so great about it?
[17:37:56] <hyc> I ssh from my phone to my server and use mutt
[17:37:56] <BBB> people tell me it's great. I don't see how it is... :)
[17:38:10] <BBB> hyc: most people don't know what ssh is (most normal people)
[17:38:21] <BBB> they think it's a word you use to hush the baby
[17:38:26] <hyc> you can't do push-based email to most phones because their IP address is NAT'd
[17:38:37] <hyc> lol
[17:38:49] <mru> my android phone does imap idle just fine
[17:39:33] <hyc> so you keep a connection open all the time?
[17:39:42] <mru> guess so
[17:39:47] <mru> doesn't bother me
[17:40:13] <hyc> it wouldn't bother me, normally, but my phone battery life sucks when the radio is active
[17:40:47] <mru> having a connection open doesn't increase radio usage notably
[17:41:04] <mru> the radio is always active for incoming calls anyhow
[17:41:16] <hyc> true
[17:41:51] <hyc> I seem to recall other problems though. like, your IP address isn't fixed, and the connection will break and need to reconnect frequently. if you move around from tower to tower.
[17:42:08] <mru> mine stays open as long as it has any signal
[17:42:21] <mru> it drops when I switch to wifi at home of course
[17:42:31] <mru> but it reconnects automatically so I don't care
[17:43:04] <mru> usually it keeps the IP address even across short signal dropouts
[17:43:08] <mru> like going through tunnels
[17:53:49] <Dark_Shikari> mru: yup, float2int16 was because the ipad need 16-bit int sound
[17:53:54] <Dark_Shikari> so we swapped CELT to fixed-point mode
[17:54:02] <Dark_Shikari> got rid of that
[17:56:10] <mru> Dark_Shikari: btw, how does 8 cycles for a 16x16 SAD sound?
[17:56:50] <Dark_Shikari> What chip?
[17:57:24] <wbs> Compn: to make things even better, microsoft did invent their own "segmented" http streaming too, using "fragmented mp4".. and adobe made yet another thing quite similar to microsoft's
[17:57:25] <mru> omap4
[17:57:35] <Dark_Shikari> mru: it's an instruction, or what?
[17:57:37] <Dark_Shikari> and is it on the dsp, arm...?
[17:57:52] <mru> motion estimation accelerator
[17:57:55] <mru> programmable
[17:58:19] <Dark_Shikari> does it have subpel?
[17:58:27] <mru> things like SAD and qpel interpolation are single instructions
[17:58:28] <Dark_Shikari> also mru http://i46.tinypic.com/11wdml4.png
[17:58:48] <mru> you have a recvfrom problem
[17:58:53] <lu_zero> wbs: uh?
[17:59:26] <lu_zero> so there are 3 incompatible ways to do a stupid/simple thing?
[17:59:35] <wbs> yes
[17:59:38] <Dark_Shikari> mru: not actually true
[17:59:39] <Dark_Shikari> [10:58:28 AM] Kelvin Yong: that # is probably a bit "fake" but I was going to test something later
[17:59:42] <Dark_Shikari> [10:59:08 AM] Kelvin Yong: recv is blocking and instruments just tracks how long each function is taking up
[17:59:54] <mru> crappy tools
[17:59:56] <Dark_Shikari> a select to test for data will probably make that # go down, but most likely won't have any effect on cpu usage
[18:00:00] <Dark_Shikari> (according to him)
[18:00:00] <wbs> lu_zero: or I'm not sure how much actually differs between the microsoft and adobe things
[18:00:02] <Dark_Shikari> so yeah, crappy tools.
[18:00:18] <Dark_Shikari> anyways, besides that, you can see how popular your idct_dc is
[18:00:23] <wbs> lu_zero: but yeah, many different ways of doing pull-based streaming in small chunks, compared to real protocols actually designed for streaming ;P
[18:00:35] <Dark_Shikari> Or, rather, it's kinda hard to see
[18:00:42] <Dark_Shikari> because it's SO FAST that it doesn't use much time even though it's called often.
[18:03:19] <Dark_Shikari> hmm, wait, clear_blocks is still being called.
[18:03:33] <Dark_Shikari> ah fuck I forgot to get rid of it.
[18:06:41] <Dark_Shikari> mru: our stream, afaik, has no 4mv.  yet put_pixels8 is being used.
[18:06:50] <Dark_Shikari> does the put_pixels16 function call put_pixels8 or something?
[18:06:51] <Dark_Shikari> (neon)
[18:07:19] <Dark_Shikari> oh... duh. chroma
[18:07:21] <Dark_Shikari> I'm stupid.
[18:10:57] <Dark_Shikari> btw, mru, _technically_ we could do something silly like multiple idct_dcs at the same time, merging the stores, to get doubled throughput.  but that would be tricky and hacky.
[18:38:06] <lu_zero> I wonder if I could/should propose a patch for chromium to support rtsp out of box
[18:38:18] <lu_zero> (once we fix our small outstanding issues)
[18:39:57] <Honoome> hmm
[18:40:12] <Honoome> after the last comment on my gcc 4.5 post, I hate C++ even more
[18:40:37] <Honoome> In C++98, in every class C, the name C exists as both a constructor and a type name, but the constructor could only be used in certain contexts such as a function declaration. In other contexts, C::C simply means C. C::C::C::C::C was also a perfectly valid way to refer to class C.
[18:40:54] <Honoome> one has to be ludicrously braindead to think about something along these lines!
[18:47:08] <lu_zero> welcome to the club
[18:47:28] <lu_zero> I'll be pleased when they'll switch to go as implementation language
[18:47:38] <lu_zero> (I mean the game)
[18:48:25] <kshishkov> GCC in Java FTW!
[18:48:27] <Honoome> rotfl
[18:48:35] <Honoome> okay I'll shut stuff down here, dinner then leaving
[18:48:35] <peloverde> GCC in ffevalapi
[18:48:35] <Honoome> byeW
[18:49:30] <hyc> anyone looking for a project, doing some code around H.264? these guys contacted me. http://totoware.com/
[18:50:50] <hyc> let me know, I will fwd you email / contact info
[18:51:26] <mru> I don't deal with such companies
[18:51:31] <mru> waste of time
[18:51:59] <hyc> what type of company is that?
[18:52:15] <mru> the clueless type that doesn't want to pay what stuff is worth
[18:53:12] <mru> those guys are clearly in that category
[18:54:03] <hyc> I guess
[18:54:21] <hyc> but you give away code for free in ffmpeg...
[18:54:26] <mru> bad grammar on the front page is a good indicator
[18:54:42] <mru> hyc: ffmpeg is advertising
[18:54:45] <hyc> seems to me that written code isn't where the value is
[18:54:58] <wbs> hyc: giving away code for free is less tiring than working with idiots, too
[18:55:05] <hyc> lol
[18:55:08] <BBB> hyc: that's about the silliest thing you could say, "free software is giving away" :)
[18:55:52] <hyc> hey, I give away all of the code I write too. sometimes it's advertising, sometimes it's just inconsequential, because using the code requires consulting.
[18:56:08] <BBB> there you go ;)
[18:56:39] <mru> my point is, when dealing paying clients, I want some professionalism
[18:56:51] <peloverde> then you get the self centered pricks who think they are entitled to free support just because the code was free
[18:57:01] <mru> I ignore those
[18:57:28] <hyc> mru: the contact from totoware is Chinese; bad grammar kinda goes with the territory
[18:57:40] <mru> chinese is out of the question entirely
[18:57:43] <BBB> chinese pay much less than americans/europeans
[18:57:48] <BBB> if they pay
[18:57:51] <mru> exactly
[18:57:53] <hyc> heh
[18:58:02] <mru> a while back I had some guys ask for help with some iphone app using ffmpeg
[18:58:04] <hyc> well, that settles that then. ;)
[18:58:07] <mru> americans
[18:58:23] <mru> they seemed friendly enough at first, so I thought I'd hear them out
[18:58:42] <mru> they wanted to encode video on an iphone and didn't like the frame rates they were getting
[18:58:56] <mru> when I saw the setting they were using I knew it was time to walk away
[18:59:11] <mru> mpeg4 asm, intra-only, 15Mbps, 480x360
[18:59:15] <mru> (asp
[18:59:36] <Dark_Shikari> lol
[19:00:03] <mru> no wonder they were spending more time in quant than in ME
[19:00:17] <mru> and in bitstream writing
[19:00:59] <mru> of course it was "very important" and they wanted results asap
[19:01:11] <BBB> isn't that resolution 2megabit/frame already?
[19:01:18] <BBB> so 15Mbps is uncompressed?
[19:01:30] <BBB> (at ~7.5fps)
[19:02:05] <BBB> it's not like the iphone camera will give you more than 7.5fps for real
[19:02:36] <mru> I don't know what they were trying to encode
[19:03:12] <mru> these guys: http://labs.laan.com/
[19:03:14] <mru> avoid
[19:08:02] <lu_zero> uhmm
[19:08:15] <lu_zero> they look quite web 2.0
[19:11:00] <lu_zero> bbl
[19:11:47] <mru> it seemed at first it would be a simple matter of writing some arm asm for the encoding functions
[19:42:26] <lu_zero> then?
[19:46:39] <mru> then it turned out they were totally clueless
[19:47:08] <Tjoppen> bcoudurier: did my PixelLayout thing make any sense to you?
[19:47:25] <Tjoppen> also, I found an analyzer which might shed some light on it
[19:47:28] <bcoudurier> yes in some way
[19:48:07] <Tjoppen> irt.de has a trial version of their analyzer, which I have access to. I've prepared a couple of variants of that item which I'm going to have it analyze
[19:48:55] <Tjoppen> failing that, maybe a mail to smpte.org could settle the matter? their standards seem rather vague regarding endianness
[19:49:46] <Tjoppen> 268m is the closest I've got, and it uses big endian. the aaf spec is even more vague
[19:50:44] <spaam> Hey.. i got this error with ffplay http://paste.lighttpd.net/1104 . report it as a bug or not? :)
[19:51:14] <mru> what are you reporting it as now? feature?
[19:51:35] <mru> does it work when not piping?
[19:51:53] <spaam> yes
[19:52:02] <Tjoppen> speaking of piping, I found a bug in mov.c today
[19:52:10] <mru> that looks like an unofficial version
[19:52:22] <Tjoppen> it assumes url_is_streamed() means url_ftell() returns meaningful values
[19:52:24] <spaam> mru: its git version from some day ago..
[19:52:33] <mru> no it's not
[19:54:03] <spaam> compiling svn now.
[19:54:03] <mru> that would say "version git-svn-rXXXX"
[19:54:23] <spaam> i got it from git.ffmpeg.org.
[19:54:37] <mru> so did I just now
[19:55:20] <ramiro_> from version.sh that seems possible
[19:55:32] <ramiro_> # check for git short hash
[19:55:46] <mru> version.sh in a git-svn tree reports git-svn-rXXXX
[19:56:07] <mru> e.g. one cloned from git.ffmpeg.org
[19:56:22] <ramiro_> mine says "FFmpeg version git-072d690"
[19:56:56] <mru> it would if you have other patches
[19:57:02] <spaam> i dont have it ;S
[19:57:13] <ramiro_> git: 'svn' is not a git-command. See 'git --help'.
[19:57:26] <mru> how did you install git?
[19:57:32] <ramiro_> sudo apt-get install git
[19:57:39] <ramiro_> or git-core or whatever
[19:57:45] <mru> and that doesn't have git-svn?
[19:57:49] <mru> silly debian
[19:57:49] <spaam> no
[19:57:58] <ramiro_> git-svn is separate
[19:57:59] <spaam> http://paste.lighttpd.net/1105 with svn..
[19:58:03] <spaam> mru
[19:58:10] <spaam> from today
[19:58:14] <ramiro_> why silly? I've never needed git-svn. I wasn't even aware of its existence
[19:58:31] <mru> it's a great replacement for plain svn
[19:58:36] <mru> makes svn usable
[19:58:59] <mru> so anyway, if you're on a crippled git installation, that could be a genuine version
[19:59:04] <mru> sorry about that
[19:59:06] <spaam> mru: so. its a bug in matroska demuxer or missing feature ? :)
[19:59:18] <mru> does it do that with any mkv file?
[19:59:22] <spaam> yes
[19:59:27] <elenril> that file looks froken
[19:59:55] <elenril> there is no 0x463d id in specs
[20:00:22] <spaam> elenril: i got some other mkv from a other site  that have the same problem
[20:00:34] <ramiro_> lol at totoware: "Totoware newly released product, CyberDash, would offer" <-- "would"? so it doesn't really...
[20:01:01] <mru> that's chinese
[20:01:08] <mru> they write like that
[20:01:34] <spaam> so if anyone else have a .mkv file that is not broken can try it? :)
[20:02:38] <elenril> hmm, broken for me too
[20:02:50] <mru> demuxer probably tries to seek
[20:02:55] <mru> Yuvi: ^^^
[20:03:26] <Yuvie> yeah, I think it will
[20:03:57] <mru> iirc it reads the seekhead block, then seeks to the various other blocks in a set order
[20:04:09] <Yuvie> matroska_execute_seekhead
[20:04:17] <mru> it would be better to simply read the blocks in whatever order they occur up to the main data
[20:04:27] <mru> then, if you still haven't found everything you need, start seeking around
[20:04:32] <mru> that's what I do
[20:05:28] <Yuvie> before mkclean existed, you'd need to seek for the cues basically 100% of the time
[20:06:49] <spaam> do i need to report it as a bug ? :)
[20:06:55] <mru> Yuvi: only if you intend to use them
[20:07:29] <spaam> elenril: :D
[20:08:04] <elenril> spaam: better send a patch ;)
[20:09:24] <spaam> sure. but im not that good and dont know where to look :)
[20:09:42] <mru> matroskadec.c I guess
[20:11:19] <spaam> then i need to understand matroska.. how it works and so on. i think ffmpeg has a maintainer for that file :)
[20:13:07] <Dark_Shikari> mru: weee, webm fun
[20:13:08] <Dark_Shikari> 04:12 < gmaxwell> We specifically asked for them to clarify that independant implementations were permitted, but the appear to have made it more explicit the other way.
[20:13:26] <Dark_Shikari> The new version is both GPL-compatible and anti-independent-implementation.  great, isn't it?
[20:13:33] <Dark_Shikari> (or, they claim it to be GPL-compatible)
[20:13:54] <mru> if it's anti-independent it can't gpl-compat
[20:14:02] <mru> that was the problem in the first place
[20:14:10] <Dark_Shikari> no, the problem was the previous one terminated ALL your rights
[20:14:12] <Dark_Shikari> not just patent rights
[20:14:19] <Dark_Shikari> if you get down to patents, it gets iffy
[20:14:21] <elenril> what? they forbid independent implementations?
[20:14:23] <Dark_Shikari> No
[20:14:30] <Dark_Shikari> The patent grant doesn't apply to independent implementations
[20:14:40] <Yuvie> hm, how to determine whether a stream can return to where it was after a seek?
[20:14:47] <elenril> nice
[20:14:58] <Dark_Shikari> 04:14 < maikmerten> btw, does that mean that if Mozilla patches their libvpx to fix a security issue they won't benefit from the license grant anymore?
[20:15:02] <mru> Dark_Shikari: did they change the spec licence too?
[20:15:04] <Dark_Shikari> weeeeeeeeeeee
[20:15:09] <Dark_Shikari> no idea, check their blog
[20:15:14] <Dark_Shikari>  http://webmproject.blogspot.com/2010/06/changes-to-webm-open-source-license.html
[20:15:32] <elenril> also yay for all the freetards in the world bashing you for saying vp8 might infringe some patents
[20:16:09] <ohsix> mpeg-la has been saying things infringe for years
[20:16:26] <mru> I wouldn't automatically trust them either
[20:16:49] <mru> but they have big enough lawyers that whatever they say is de facto truth
[20:17:00] <ohsix> yea, but they have to move or its bluster
[20:17:27] <mru> bit of fudding is exactly what they need to do at this stage
[20:17:30] <mru> make people worried
[20:17:50] <mru> people are afraid of the unknown
[20:17:54] <ohsix> it pretty much effectively segregates anyone that would challenge stuff they license from ever really competing
[20:17:55] <mru> therefore do not tell them anything
[20:18:08] <Yuvie> url_is_streamed isn't what I want since it's true for http
[20:18:15] <ohsix> if they can do it for years and not get called on it, anyways
[20:18:31] <ohsix> if it were a trademark they'd have already lost rights to it
[20:18:44] <mru> for them it's enough to keep enough uncertainty going that companies choose to license h264 instead
[20:18:49] <mru> just to be on the safe side
[20:19:09] <ohsix> not just h264, but yea; thats their racket
[20:19:48] <Dark_Shikari> mru: if you're curious and want to see how much faster we made the decoder on ARM (we don't have hard benchmarks, it's hard to get those on ipad)
[20:19:49] <mru> an h264 licence is much more affordable than a lawsuit
[20:19:52] <Dark_Shikari> bench with and without http://x264.nl/developers/Dark_Shikari/destroy_mpeg_decoder5.diff
[20:19:59] <Dark_Shikari> on some random flv file
[20:20:16] <Dark_Shikari> I will bet it's at least a 40% improvement
[20:20:22] <mru> maybe later
[20:20:39] <mru> but we should definitely get the idct_dc pushed
[20:20:40] <Dark_Shikari> oh, and I should probably remove the offset checks
[20:20:46] <Dark_Shikari> I reallocated mpegvideocontext
[20:20:50] <Dark_Shikari> breaking your code
[20:20:56] <ohsix> it is for business, but an idle threat isn't neccisarily a credible one
[20:21:17] <mru> and idle thread is worse than no threat
[20:21:20] <mru> that's all that matters
[20:21:40] <Dark_Shikari> diff updated.
[20:21:55] <mru> one of the most common words you'll hear in conversations with PHBs is "risk"
[20:21:55] <Dark_Shikari> it now breaks basically all of ffmpeg because it converts motion values to 8-bit instead of 16-bit
[20:22:00] <Dark_Shikari> because FLV's max motion vector length fits in 8-bit
[20:22:02] <mru> after BS like synergy of course
[20:22:09] <ohsix> people don't take it for what it is though
[20:22:38] <Dark_Shikari> mru: our synergistic patent-licensing option will induce a paradigm shift in the...
[20:22:55] <mru> yeah
[20:23:07] <mru> vertical market
[20:23:15] <_av500_> Dark_Shikari: you could bench it on another a8, no?
[20:23:20] <Dark_Shikari> _av500_: don't have one.
[20:23:37] <mru> Dark_Shikari: go right now and order yourself a beagleboard!
[20:23:38] <_av500_> gee
[20:23:49] <Dark_Shikari> mru: then I'd have to get all the addons and that junk
[20:23:53] <_av500_> no
[20:23:54] <mru> addons?
[20:24:01] <Dark_Shikari> to plug it into things
[20:24:07] <mru> you need an sd card and a null modem cable
[20:24:08] <_av500_> into what?
[20:24:12] <mru> stuff you already should have
[20:24:14] <Dark_Shikari> like sata?
[20:24:19] <Dark_Shikari> oh, I guess an sd card works.
[20:24:19] <hyc> Dark_Shikari: you should still have access to my machine
[20:24:25] <mru> nfs-root it
[20:24:25] <_av500_> wofor?
[20:24:26] <Dark_Shikari> hyc: yeah, but I am not about to compile ffmpeg on it
[20:24:28] <Dark_Shikari> I mean, holy shit
[20:24:36] <Dark_Shikari> I would want that cross-compiled =p
[20:24:41] <hyc> lol
[20:24:48] <mru> ffmpeg supports cross-compiling very well
[20:24:56] <Dark_Shikari> yeah, but I don't control hyc's computer
[20:25:02] <hyc> yeah... compiling the kernel *on that box* was an overnight affair
[20:25:02] <Dark_Shikari> so I can't cross compile with his system
[20:25:07] <Dark_Shikari> I only have access to his arm box
[20:25:12] <Dark_Shikari> and I don't have a cross compiling environment
[20:25:18] <_av500_> Dark_Shikari: gee
[20:25:19] <mru> have gentoo?
[20:25:44] <Yuvie> codesourcery should have windows binaries
[20:25:46] <Dark_Shikari> on my box at work I do
[20:25:50] <Dark_Shikari> I can go and try to compile it there
[20:25:53] <mru> emerge crossdev
[20:25:54] <Dark_Shikari> gentoo, that is
[20:25:55] <hyc> Dark_Shikari: what dependent libraries would it need? I can get a compile started
[20:25:59] <Dark_Shikari> hyc: none
[20:26:00] <mru> crossdev -t arm-none-linux-gnueabi
[20:26:04] <Dark_Shikari> Just ffmpeg, with and without that patch.
[20:26:06] <peloverde> vpx license update: https://review.webmproject.org/#change,78
[20:26:11] <Dark_Shikari> peloverde: already mentioned
[20:26:13] <hyc> okeydoke
[20:26:15] <Dark_Shikari> look up
[20:26:44] <kierank> peloverde joined after
[20:27:34] <Dark_Shikari> ah
[20:29:58] <lu_zero> https://review.webmproject.org/#patch,sidebyside,78,1,LICENSE
[20:30:07] <lu_zero> time to remove the nonfree?
[20:30:25] <Dark_Shikari> they still prohibit independent implementations
[20:30:30] <Dark_Shikari> or better said, their patent grant doesn't apply to them
[20:30:53] <peloverde> A) has it been committed?
[20:31:14] <peloverde> B) Since when do we care about patents as long as they are not part of the copyright license?
[20:31:32] <Dark_Shikari> this isn't really related to the nonfree, but we do care
[20:31:34] <Dark_Shikari> because it's FUD against us
[20:31:39] <peloverde> But in a similar vein: "Though, I especially don't expect to be much interest in _VP8_ derivatives, if for no other reason than Google's patent license apparently making VP8 into a development dead-end."
[20:31:42] <Dark_Shikari> it's saying "our lib is licensed, if you make your own, it's not licensed"
[20:31:49] <peloverde> For all the monopoly on open these people have, use as is but don't change doesn't seem very open to me
[20:31:57] <Dark_Shikari> in short
[20:31:59] <Dark_Shikari> it's FUD against ffmpeg.
[20:32:19] <lu_zero> how so?
[20:32:26] <_av500_> "...Additionally, we have updated the patent grant language to make it clearer that the grant includes the right to modify the code and give it to others...
[20:32:28] <lu_zero> the bitstream license is still the same
[20:32:48] <_av500_> where is the line between modify and reimplement?
[20:33:11] <mru> ---------------
[20:33:23] <_av500_> cut here?
[20:33:30] <Dark_Shikari> av500: wherever the courts say
[20:33:39] <_av500_> so the line is in texas...
[20:33:46] <Dark_Shikari> lu_zero: the patent grant does not give patent rights to anyone who makes their own decoder
[20:33:50] <Dark_Shikari> or encoder
[20:34:00] <mru> roll 2d6
[20:34:02] <Dark_Shikari> that means if we make a decoder, people can FUD that ours isn't licensed, while google's is.
[20:34:12] <peloverde> Why can't they just RAND license it like any real format?
[20:34:18] <mru> if the product is prime, you win
[20:34:39] <lu_zero> Dark_Shikari: then we can ask about it now
[20:34:44] <mru> peloverde: they thought RAND meant random
[20:34:48] <lu_zero> so far they complied with what they were asked
[20:34:51] <lu_zero> to
[20:34:51] <Dark_Shikari> lu_zero: do it
[20:34:55] <Dark_Shikari> but per what I said above
[20:34:59] <Dark_Shikari> they did exactly what xiph asked them not to do
[20:35:06] <lu_zero> uh?
[20:35:12] <Dark_Shikari> 04:12 < gmaxwell> We specifically asked for them to clarify that independant implementations were permitted, but the appear to have made it more explicit the other way.
[20:35:13] * lu_zero has to run
[20:35:18] <lu_zero> see you in some time
[20:35:19] <mru> pissing off xiph has to be worth something...
[20:35:24] <Dark_Shikari> xiph was quite right there.
[20:35:32] <peloverde> Their random license was extra because they always yammer on about license fragmentation
[20:35:49] <mru> it's a shame that even stupid people are right once in a while
[20:36:06] <Dark_Shikari> even a stopped clock is right twice a day
[20:36:06] <mru> peloverde: yes, when _others_ do it
[20:36:27] <janneg> s/even/only/
[20:36:47] <Dark_Shikari> hyc: if you get them compiled, ping me, and I can go log in and test
[20:37:01] <mru> janneg: that would be "exactly twice"
[20:38:07] <mru> and that's not true either
[20:38:07] <janneg> depends how strictly one defines right
[20:38:14] <ohsix> lawl: Also, in doing this, we effectively created a potentially new open source copyright license, something we are loath to do.
[20:38:16] <mru> a clock that runs at double speed is right twice a day too
[20:38:31] <ohsix> last i heard they were fighting with OSI over some stuff too
[20:38:43] <_av500_> yup
[20:38:51] <mru> osi are a bunch of self-righteous trolls
[20:39:15] <peloverde> They are less annoying than the FSF
[20:39:17] <ohsix> they have a fairly narrow scope and interest
[20:39:22] <mru> sure
[20:39:40] <mru> but self-appointing as the guardians of the work "open" is a bit far-reaching
[20:39:45] <mru> *word
[20:40:43] <ohsix> someone has to do it; you don't have to take their word for it, but you can find out where a given license lands; and minimize them to the extent that you can in doing so
[20:41:09] <mru> they don't define the law
[20:41:15] <mru> so their word is useless as such
[20:41:29] <kierank> both fsf and osi exist to argue stupid differences between free software and open source
[20:41:31] <peloverde> Sphinx is much better than OSI at dealing with unlicensed villains
[20:41:45] <ohsix> they say where they stand, and if people respect that then its de-facto, at least with respect to fragmentation
[20:42:03] <mru> they also have an agenda of their own
[20:42:07] <mru> don't forget that
[20:42:11] <mru> I don't know what it is
[20:42:15] <mru> since they don't publish it
[20:42:20] <ohsix> heh
[20:42:21] <peloverde> everyone has an agenda
[20:42:22] <mru> but everybody has an agenda
[20:42:59] <ohsix> if you don't know what it is, insofar as how it reflects on your conduct, then they might as well not
[20:43:14] <mru> I haven't studied them carefully
[20:43:31] <mru> but if you looked in detail at the licences they've approved and those they've not, something might emerge
[20:43:47] <ohsix> approve is a word i'd contend with
[20:43:53] <elenril> an evil conspiracy?
[20:43:55] <mru> it's a word they use
[20:45:29] <ohsix> ehh, then they aren't what i thought they were; i thought they were just aligning things to their principles, and coming down yay or nay; theres no approval or disapproval of any given license, just wether it lines up, that may be de-facto disapproval but there is no judgement in doing so
[20:46:36] <ohsix> as in, your license for your code exists, not at the behest of OSI; but it might not align with their ideals, it does not render judgement on your license, just with respect to OSI and people who align themselves with those same standards
[20:47:12] <ohsix> if you happen to agree with all the points of their brief on what is "free" or not, what they say about any given license might matter to you, not being a lawyer
[20:51:56] <mru> they maintain a list of approved licences
[20:52:14] <mru> and they act as though that list were authoritative beyond questioning
[20:52:45] <mru> and they have a noice tail of freetards ready to jump on anyone who disagrees
[20:52:52] <mru> noisy
[20:53:19] <peloverde> The freetards didn't seem to care about the flaws in the libvpx license
[20:53:24] <Dark_Shikari> On the other hand, they are useful
[20:53:38] <Dark_Shikari> it's nice to have an organization that can come out and point to something like the Microsoft shared source license
[20:53:44] <Dark_Shikari> and call them on their bullshit
[20:53:46] <mru> everything is useful on the occasions it happens to serve your purposes
[20:53:56] <mru> anyone could do that
[20:54:02] <Dark_Shikari> yes, but they have clout.
[20:54:17] <mru> that's what I'm saying they shouldn't
[20:54:22] <mru> they didn't earn it properly
[20:54:27] <ohsix> shrug; its still a matter of aligned opinions and nothing more
[20:54:43] <mru> it's a matter of self-appointing to positions of power
[20:55:10] <ohsix> heh, if a lot of people agree with what you do, that is some de-facto power; theres no self appointing about it
[20:55:24] <mru> s/people/sock puppets/
[20:55:42] <ohsix> another conspiracy :]
[20:56:02] <mru> our problem is that we are too nice
[20:56:08] <ohsix> its not a conspiracy if everyone is really out to get you
[20:56:12] <mru> we're honest about what we do
[20:56:26] <ramiro_> .svi? shit video interleave?
[20:56:33] <ohsix> i'd call it indifferent, but i happen to agree
[20:57:30] <mru> and people like gst, xiph, et al have no moral qualms about pretending to be the solution to everything
[20:57:39] <peloverde> I like the "The Software shall be used for Good, not Evil" license and then making exceptions for companies to use the software for evil
[20:57:50] <ohsix> that if i were in a real position to actually consider someones perspective with regard to patents embodied in what i actually did; i would probably do due diligence and consider it
[20:58:03] <ohsix> peloverde: then you get to define good and evil :]
[20:58:29] <ohsix> mru: i don't see anyone that works on gst making any statements to morality
[20:58:40] <mru> of course not
[20:58:42] <mru> they have none
[20:58:45] <mru> morals, that is
[20:58:47] <ohsix> and what constitutes pretending?
[20:58:59] <ohsix> "they", who in particular, fluendo? licensing an mp3 codec?
[20:59:01] <mru> they lie through their teeth
[20:59:09] <ohsix> who is they
[20:59:19] <mru> gst amongst others
[20:59:38] <ohsix> thats an unqalified statement, i'm asking for specifics
[20:59:40] <hyc> 2m27s to run ffmpeg configure on my arm touchbook
[20:59:44] <mru> they have this "we're so great" attitude
[20:59:51] <ohsix> because if there are some, i haven't heard of it
[20:59:52] <mru> never a word of appreciation for ffmpeg
[21:00:00] <ohsix> o i c
[21:00:07] <mru> when without ffmpeg they'd be nothing
[21:00:08] <mru> NOTHING
[21:00:37] <peloverde> false claims about the quality and potential quality of Theora were pretty immoral
[21:00:44] <ohsix> i haven't seen "we're so great", merely fit for purpose, and ffmpeg is combative enough that its not worth praise, as thats all it would be, not cooperation or anything
[21:01:02] <kierank> peloverde: that youtube comparison page was pretty low imo
[21:01:05] <mru> but they're the ones running around, licking corporate arses and collecting payouts
[21:01:15] <ohsix> who?
[21:01:25] <mru> gst
[21:01:28] <ohsix> fluendo?
[21:01:31] <mru> and others
[21:01:42] <peloverde> fluendo, collabora
[21:01:43] <ohsix> who's corporate ass are they licking
[21:01:56] <mru> as many as they can find I presume
[21:02:01] <_av500_> not ours...
[21:02:15] <mru> why do you think TI release gst plugins for their dsp codecs?
[21:02:26] <ohsix> fluendo is gone, collabora is making a business insofar as mru might make business providing ports or flattening a slow path for a vendor
[21:02:33] <ohsix> because they can, without hassle?
[21:02:42] <peloverde> I think it's interesting to look at who were the zero-day VP8 partners
[21:02:46] <_av500_> mru: it fits the "wrappers all the way down" mantra...
[21:03:02] <mru> becaue the gst trolls have tricked them into believing gst is everything
[21:03:13] <peloverde> Anyway we need to get the foundation website up and start shaking people down
[21:03:17] <mru> a gst plugin is utterly useless for most users
[21:03:22] <ohsix> i don't think they've "tricked" anyone; they set up clear boundaries in the way the software is constructed
[21:03:22] <mru> like, say, vlc
[21:03:31] <mru> bwhahahaha
[21:03:50] <mru> that software is a steaming turd
[21:03:53] <ohsix> so the usefullness of some gst plugins to vlc is where its drawn down to a problem? nothing in gst?
[21:03:58] <ohsix> how so
[21:04:09] <mru> ever tried using it?
[21:04:21] <mru> hint: that ghastly "totem" player uses it
[21:04:26] <ohsix> there is no try, only do; and many times, daily even
[21:04:38] <mru> then you're one of them
[21:04:40] * _av500_ sends gst users some |||||||||||||
[21:05:06] <hyc> aw come on, pipelines are a pretty decent model
[21:05:06] <ohsix> my only beef if any with gst at the moment is that it doesn't load sub/idx files right; it can't request the extra file (idx) to get the dimensions and colors of the (sub) file right, so its just broke
[21:05:10] <BBB> vp8 license is fixed
[21:05:18] <BBB> can soeone unbreak the configure for libvpx with nonfree?
[21:05:23] <BBB> without nonfree
[21:05:36] <ohsix> i wrote a few dshow components before gst even existed
[21:05:57] <twnqx> sub/idx? that is still used?
[21:05:58] <mru> both dshow and gst look good in high-level overview
[21:06:07] <mru> the implementations both suck balls
[21:06:07] <twnqx> hello, 2010 called with matroska and .ass
[21:06:24] <ohsix> well if you say so
[21:06:37] <_av500_> twnqx: ppl still use it...
[21:06:40] <ohsix> twnqx: yea, still used; resyncing is hard :]
[21:06:48] <mru> it would be much nicer of TI to release a usable library
[21:06:54] <mru> then gst could make their own wrapper for it
[21:07:00] <_av500_> ppl still encode divx311
[21:07:02] <mru> and vlc could do the same
[21:07:05] <_av500_> mru: they have, dmai
[21:07:10] <mru> I said usable
[21:07:15] <_av500_> true :)
[21:07:27] <ohsix> it would be nice, sure; but they aren't about being nice, they have a job to do, being nice costs real money on top
[21:07:46] <_av500_> ohsix: no, that is not the reason
[21:07:49] <mru> it would cost them no more than producing a half-arsed gst plugin
[21:07:53] <hyc> mru: but that would mean expecting something intelligent out of TI software...
[21:08:04] <ohsix> if they want to be nice they probably would have first class third party toolchains for their devices, and public drivers for their video socs
[21:08:10] <_av500_> s /TI/corporate/
[21:08:28] <mru> I'm using TI as an example here
[21:08:42] <mru> as companies go, TI is quite good
[21:08:47] <ohsix> _av500_: they still have a business to run
[21:08:48] <BBB> I think mru is pissef off because he knows if it wasn't for the arse-licking, ffmpeg devs would probably earn three times as much :)
[21:09:00] <BBB> right now, that money goes to corporate bimbo's who don't know what neon is
[21:09:09] <hyc> last time I tried to get all of their toolchain working on touchbook, I had to go thru 2 out of date repos on two official websites before finding the "good" version
[21:09:21] <ohsix> heh, ffmpeg as an assemblage isn't easy to digest in a corporate environment
[21:09:30] <ohsix> not in the states anyways
[21:09:38] <_av500_> ohsix: gst is very little of their "business"
[21:09:39] <mru> they all use it
[21:09:46] <BBB> ohsix: you ate the cooljuice :)
[21:09:55] <BBB> congratulations
[21:10:06] <ohsix> they get into the minutae of having to deal with things they really have no business investigating, they'd sooner take indemnification
[21:10:15] <BBB> ohsix: do you think ffmpeg makes theora invade in patents?
[21:10:18] <ohsix> no, i'm merely aware of what the situation is in the US
[21:10:20] <BBB> ohsix: I've heard that one :)
[21:10:45] <_av500_> nobody indemnifies
[21:10:47] <ohsix> BBB: no, i'm not in a position to evaluate ffmpeg for anything with respect to patents, so i do not know or care of such things; i use it, i'm not building a product using it
[21:10:51] <BBB> the situation in the US is that if you buy a patent license for ffmpeg or gst, you're safe
[21:11:09] <_av500_> relatively safe
[21:11:14] <ohsix> _av500_: indemnify, insofar as they're responsible for their portion
[21:11:18] <mru> as safe as you'll ever be
[21:11:22] <_av500_> ohsix: ?
[21:11:55] <ohsix> _av500_: that is to say, not as stated in some contract; they're insulated partly by the way the software is constructed from some issues
[21:12:22] <ohsix> when you're picking man hours to put somewhere it helps that you can ignore the minutae
[21:12:23] <mru> that's doublespeak for "the software doesn't do anything, therefore it is safe"
[21:12:39] <BBB> I want more coolaid
[21:12:40] <ohsix> nah; the software does lots, but not all parts of it are your concern
[21:12:42] <_av500_> ohsix: no codec vendor indemnifies you
[21:12:57] <_av500_> nobody would insure them
[21:12:57] <ohsix> _av500_: i know, not in contract language
[21:13:16] <mru> not in any language
[21:13:17] <BBB> mru: here's what you should do
[21:13:21] <BBB> mru: offer ffmpeg for download
[21:13:27] <mru> we already do
[21:13:30] <_av500_> fraunhofer/thomsonm did jack shit about sisvel
[21:13:31] <BBB> mru: with a patent license, or help in getting them
[21:13:36] <BBB> mru: adn ask tons of bucks
[21:13:47] <BBB> mru: that's fluendo's business model, and also dave schleef's business model
[21:13:50] <BBB> mru: that's it
[21:13:54] <BBB> oh, wait: $$$44
[21:13:55] <BBB> profit
[21:13:56] <ohsix> but practically speaking unless you meld your interest with say, ffmpeg; you aren't concerned with parts that might get you in trouble, you can reasonably get away with your own legal boundaries with your software and not be concerned with the assemblage, it won't be used in any other manner, but its also you not doing it
[21:14:26] <_av500_> BBB: sure you can be a mpegla reseller...
[21:14:29] <mru> ohsix: do you even pretend to understand what you just said?
[21:14:36] <BBB> _av500_: exactly
[21:14:49] <ohsix> i'm not the one explaining it to myself :P
[21:15:01] <mru> ohsix: I hear words, but I sense no meaning
[21:15:06] <ohsix> you don't get in trouble for selling bolts if its used in a tank that is further used to commit genocide
[21:15:20] <BBB> ffmpeg commits genocide
[21:15:24] <BBB> awesome, hadn't heard that yet
[21:15:27] <ohsix> well i can't account for your senses
[21:15:31] <BBB> when does the nazi come in?
[21:15:53] <ohsix> BBB: putting words in someones mouth isn't an effective oratory technique
[21:16:06] <ohsix> point of fact; i was speaking to gst
[21:16:46] <ohsix> you can freely concern yourself with the bolts of some assemblage that you yourself will not be concerned with making said bolt
[21:17:08] <mru> again, words without meaning
[21:17:22] <ohsix> just like someone making kitchen knives doesn't have to be concerned with women stabbing their husbands
[21:17:30] <_av500_> gee
[21:17:43] <mru> I totally fail to see the relevance
[21:17:48] <_av500_> +1
[21:17:56] <ohsix> and thats the original problem, so no harm done
[21:18:01] <mru> ffmpeg is a prerequisite for gst's existance
[21:18:05] <ohsix> companies can make knives and women wont get stabbed
[21:18:17] <_av500_> and gst does not sell mpegla or does it?
[21:18:27] <mru> it doesn't afaik
[21:18:33] <BBB> so is ffmpeg the woman or the knife?
[21:18:36] <ohsix> mru: thats a logical fallacy; if not ffmpeg, it would be anything else, ffmpeg exists; however
[21:18:50] <_av500_> BBB: the codec that encoded the stabbing...
[21:18:55] <ohsix> your tract of reasoning speaks to a past that doesn't exist
[21:18:59] <BBB> snow!!!!!11112233
[21:19:05] <BBB> sue it!
[21:19:17] <mru> ohsix: the point is gst would be nothing without the codec libs doing the real work
[21:19:18] <ohsix> BBB: ffmpeg is neither
[21:19:35] <ohsix> if anything ffmpeg is the stabbing and lots of other people made the knives :]
[21:19:48] <ohsix> mru: i take your point there, and have for some time
[21:19:49] * _av500_ fails to follow this movie plot
[21:20:05] <peloverde> I'm confused are we stabbing or being stabbed?
[21:20:18] <_av500_> and there are no women here anyways...
[21:20:29] <mru> that guy is annoying
[21:20:34] <_av500_> its a pure male stabfest
[21:22:05] <peloverde> I still support trying to avoid a culture that drives future potential women away
[21:22:24] <_av500_> future potential?
[21:22:35] <_av500_> they will be women in the future potentially?
[21:23:06] <hyc> kinda futile, I suspect
[21:23:27] <mru> I don't believe in women
[21:23:35] <mru> they're all holographic projections
[21:23:43] <hyc> women's brains and men's brains are wired differently. you're talking about such a tiny statistical outlier
[21:23:46] <_av500_> hyc: yes, pipeline is a nice concept, but i could make a living helping ppl whose gst pipeline takes 111% cpu on omap3...
[21:24:01] <hyc> as far as women who like coding, hacking, bit-twiddling...
[21:24:13] <mru> I know ~two of those
[21:24:18] <mru> and one wasn't always a woman
[21:24:27] <_av500_> loretta?
[21:25:05] <peloverde> At (previous employer) I knew a few and one was pretty brilliant
[21:25:54] <_av500_> anybody know/use flattr?
[21:26:00] <mru> I've never met a girl who'd cut it in ffmpeg
[21:26:20] <_av500_> unless she stabbed you said bolt?
[21:26:20] <peloverde> most dudes wouldn't cut it in FFmpeg
[21:26:22] <mru> not saying such a creature couldn't exist
[21:26:30] <_av500_> +with
[21:26:32] <mru> but they're extremely rare
[21:27:05] <merbanan> those who would cut it usually find more interesting things then FFmpeg to do
[21:27:18] <peloverde> _av500_, haven't use flattr, but I put a tip jar on my github
[21:27:28] <mru> merbanan: there are more interesting things?
[21:27:39] <merbanan> _av500_: I have an account
[21:27:43] <_av500_> dunno if flattr is popular, could be put on ffmpeg.org...
[21:27:44] <janneg> _av500_: I'm thinking of attaching flatr buttons to gitweb commits
[21:27:44] <merbanan> mru: no :)
[21:28:03] <mru> merbanan: so the girls in question don't exist
[21:28:53] <hyc> exactly. we're not just talking about people who *can* do it, we're talking people who *like* it.
[21:29:12] <merbanan> I would not say the don't exist just that the probability is 0
[21:29:38] <janneg> _av500_: or to resolved bugs
[21:29:44] <peloverde> _av500_, I remember people saying the same things about micropayments 10 years ago now
[21:30:01] <_av500_> peloverde: ic
[21:30:02] <merbanan> I think they there are people who like it just that they might not be ale to spare the time
[21:31:02] <BBB> mru: unban him...
[21:31:05] <BBB> that wasn't necessary
[21:32:28] <mru> ban stays until tomorrow
[21:32:46] * BBB objects lightly
[21:33:01] <mru> he's always like that
[21:33:44] <j45> howdy, saintd3v recommended i drop by here with my question.  Does anybody have any leads on the specification for putting DTS audio in mp4?
[21:34:00] <peloverde> j45, mp4ra.org
[21:34:11] <mru> first hit on google
[21:34:22] <mru> for "mp4 registration authority"
[21:34:49] <j45> been there. they point you to the dts spec which hasn't been updated in years and has nothing on putting it in mp4
[21:34:53] <BBB> mru: he'll behave, I'll give you my word
[21:35:04] <mru> BBB: he hasn't behaved in the past
[21:35:21] <mru> j45: nothing else is needed
[21:35:24] <BBB> he'll behave today... can't promise anything about tomorrow
[21:36:28] <mru> j45: I imagine all you need to do is set a codec id of 'dtsc' and put dts frames in the data section
[21:36:42] <mru> BBB: how can you possibly promise anything like that
[21:36:55] <BBB> simple, if he misbehaves today, ban me
[21:37:04] <BBB> (and him)
[21:37:11] <mru> that's not a promise
[21:37:15] <BBB> true
[21:37:42] <mru> it's not like he's ever been useful anyway
[21:38:28] <j45> mru: with ac3, there a bunch of properties that have to be set.  the specific properties and how they are set is defined by the ac3 spec.  i expected there to be something similar for dts. examples, fscod, bsid, acmod lfeon, bit_rate_code.
[21:38:48] <mru> BBB: his writing longer and longer sentences with less and less meaning eventually gets very annoying
[21:39:10] <mru> j45: aren't those fields part of the ac3 frame header?
[21:39:21] <_av500_> yes
[21:39:29] <j45> yes, and they also get set in the mp4 header
[21:39:35] <merbanan> mru: please unban him
[21:39:39] <mru> merbanan: no
[21:39:42] <BBB> mru: I agree that it wasn't useful, but I'm still asking you to please unban him, so he can listen without talking
[21:40:01] <mru> why?
[21:40:27] <mru> another time he was going on and on defending xiph with similar meaningless statements
[21:40:43] <mru> I'd say he's trying to be annoying
[21:40:46] <merbanan> I'd prefer if we try to keep all ffmpeg related communication channels as open as possible
[21:40:50] <mru> an old-school troll
[21:41:11] <mru> merbanan: well, today it's not possible for him to be here
[21:41:25] <peloverde> This channel exists to facilitate the development of FFmpeg
[21:41:38] <peloverde> The question is does his presence further or hinder that goal?
[21:41:50] <BBB> at this point his ban distracts us
[21:41:53] <BBB> but so does his presence
[21:41:56] <BBB> so it's about equal
[21:42:03] <mru> I don't find the ban distracting in the least
[21:42:08] <mru> in fact, I find it quite peaceful
[21:42:41] <peloverde> BBB has a point otoh the discussion of the ban is far more coherent than the discussion that lead to the ban
[21:43:04] <Dark_Shikari> hyc: got it working ?
[21:43:13] <Dark_Shikari> otoh, I'll go install crossdev thingy
[21:43:17] <Dark_Shikari> mru: what's it called "crossdev"?
[21:43:18] <mru> I tolerated it up the point where he likened ffmpeg to a knife-stabbing
[21:43:24] <merbanan> who is he ?
[21:43:27] <mru> Dark_Shikari: yes
[21:43:32] <mru> merbanan: no idea
[21:43:45] <hyc> Dark_Shikari: ffmpeg is still compiling
[21:43:54] <Dark_Shikari> STILL?
[21:43:58] <hyc> it's on libavcodec/nellymoser now
[21:44:04] <Dark_Shikari> what's your cross compiling machine, another ARM??
[21:44:14] <hyc> no, not cross, this is native on the box
[21:44:16] <_av500_> its not crosss
[21:44:18] <Dark_Shikari> o.0
[21:44:21] <BBB> :D
[21:44:22] <Dark_Shikari> I could have done that myself
[21:44:25] <Dark_Shikari> And it would have taken all day
[21:44:34] <_av500_> but hyc wants to share the pain...
[21:44:35] <BBB> doesn't it error out on dsputil.c?
[21:44:48] <BBB> (OOM)
[21:44:48] <hyc> no, that took a long time, but it passed
[21:44:54] <BBB> oh
[21:44:57] <BBB> that's kinda cool
[21:45:10] <hyc> this box has 512MB RAM ...
[21:45:40] <hyc> if you've ever used openembedded bitbake, it's a toss-up which is more pain.
[21:45:44] <Dark_Shikari> lol
[21:46:08] <Dark_Shikari> hyc: patched version or unpathced version?
[21:46:14] <Dark_Shikari> or do you already have the unpatched sitting around
[21:47:20] <_av500_> hyc: u dont need oe to crosscompile ffmpeg
[21:47:22] <hyc> this is unpatched build
[21:47:40] * BBB gently pokes mru again to unban the poor kid
[21:47:42] <hyc> _av500_ that's where my crosscompiler is
[21:47:52] <Dark_Shikari> hyc: lol, this will take years
[21:47:56] <hyc> I'd have to poke around to find the include and lib stuff.
[21:48:09] <Dark_Shikari> it'd be faster for mru to just compile and send it to you
[21:48:09] <Dark_Shikari> or me
[21:48:22] <hyc> well, I figured I could do other stuff in the meantime. gotta run to the store right now.
[21:48:26] <Dark_Shikari> true
[21:48:31] <Dark_Shikari> it's not like it eats much power ;)
[21:48:34] <hyc> feel free to send me binaries. you can scp it over, actually.
[21:49:10] <merbanan> mru: hmm, well if he is hindering development and annoy real contributors then I guess a one day ban might be justified
[21:49:14] <hyc> snow.o
[21:49:41] <Dark_Shikari> that will take 5 years
[21:51:37] <merbanan> but I'd prefer it if we just would ignore people and let them ramble
[21:52:05] <BBB> setthe channel as +m so only those with voice/ops can talk ;)
[21:53:52] <_av500_> and make it invite only with a password...
[22:15:24] <BBB> hmm... mru went afk
[22:15:33] <BBB> or maybe he's ignoring me now
[22:15:35] <mru> I'm here
[22:19:07] <mru> hi DonDiego
[22:19:37] <DonDiego> hi
[22:19:39] <BBB> mru: pretty please?
[22:19:46] <BBB> DonDiego: ah, can you remove libvpx from nonfree? :)
[22:19:52] <BBB> google fixed their license
[22:19:58] <DonDiego> elaborate..
[22:20:03] <DonDiego> and no, i cannot
[22:20:10] <DonDiego> i'm on hiatus until monday
[22:20:17] <BBB> monday is fine
[22:20:37] <DonDiego> janneg: when do the others arrive for linuxtag?
[22:20:50] <DonDiego> well, i'm asking everybody really..
[22:20:50] <merbanan> me Thursday
[22:21:01] <DonDiego> what time?
[22:21:58] <merbanan> 0805 at sxf
[22:22:19] <DonDiego> arriving on tuesday evening will be tight for me..
[22:22:50] <DonDiego> exam monday at 11:00, drink the evening, get a few things done before leaving.. :)
[22:24:48] <DonDiego> mru: you arrive tuesday evening, right?
[22:24:56] <DonDiego> do you need (more) help with the booth setup?
[22:25:23] <mru> tuesday afternoon
[22:25:45] <mru> any help will be appreciated
[22:26:02] <mru> _av500_: when is the beast arriving?
[22:26:30] <janneg> mru: I should pick it before tuesday
[22:26:48] <_av500_> mru: saturday evening in berlin
[22:26:58] <_av500_> then its up to janneg
[22:40:44] <DonDiego> i'll see when i can arrive..
[22:40:58] <DonDiego> ok, gnite
[22:41:27] <CIA-92> ffmpeg: conrad * r23469 /trunk/libavcodec/libvorbis.c: libvorbis: Hook up min/max bitrate
[22:41:27] <CIA-92> ffmpeg: conrad * r23470 /trunk/libavcodec/libvorbis.c:
[22:41:27] <CIA-92> ffmpeg: libvorbis: OV_ECTL_RATEMANAGE_AVG is depreciated in favor of
[22:41:27] <CIA-92> ffmpeg: OV_ECTL_RATEMANAGE2_SET
[22:41:27] <CIA-92> ffmpeg: conrad * r23471 /trunk/libavcodec/libvorbis.c:
[22:41:27] <CIA-92> ffmpeg: libvorbis: Disable strict bitrate management when not requested
[22:41:28] <CIA-92> ffmpeg: This is 3 times faster in a quick benchmark
[22:41:28] <CIA-92> ffmpeg: conrad * r23472 /trunk/MAINTAINERS: Add myself as libvorbis.c maintainer
[22:41:32] <CIA-92> ffmpeg: conrad * r23473 /trunk/ (4 files in 4 dirs):
[22:41:32] <CIA-92> ffmpeg: matroskaenc: Mux clusters better
[22:41:32] <CIA-92> ffmpeg: Start them on keyframes when reasonable, and delay writing audio packets
[22:41:32] <CIA-92> ffmpeg: to help ensure that there's audio samples available for the first frame in
[22:41:32] <CIA-92> ffmpeg: clusters.
[22:41:32] <CIA-92> ffmpeg: Patch by James Zern <jzern at google>
[22:41:33] <CIA-92> ffmpeg: conrad * r23474 /trunk/ (7 files in 4 dirs):
[22:42:03] <CIA-92> ffmpeg: conrad * r23477 /trunk/libavformat/matroskaenc.c: matroskaenc: Check that tracks was allocated
[22:42:05] <CIA-92> ffmpeg: conrad * r23478 /trunk/ (3 files in 3 dirs):
[22:42:05] <CIA-92> ffmpeg: matroskaenc: Don't write a second seekhead for the clusters; mkvalidate agrees
[22:42:05] <CIA-92> ffmpeg: with me that it's unnecessary.
[22:47:32] <bcoudurier> nice work yuvi
[22:56:23] <BBB> indeed
[23:10:40] <hyc> time make - 61m45s
[23:25:33] <hyc> Dark_Shikari: do you have a particular sample file I should use?
[23:25:43] <hyc> and what exact command should I be testing with?
[23:27:34] <Dark_Shikari> ffmpeg -i input -f rawvideo /dev/null ?
[23:27:40] <hyc> okeydoke
[23:27:56] <hyc> any specific input file you tested with?
[23:28:06] <Dark_Shikari> file:
[23:28:15] <Dark_Shikari> http://x264.nl/developers/Dark_Shikari/output.flv
[23:28:35] <hyc> grabbing it...
[23:31:25] <hyc> avg of 3 runs, ~9.5 seconds, ~ 17fps on stock code
[23:31:30] <hyc> patching now...
[23:31:48] <CIA-92> ffmpeg: bcoudurier * r23479 /trunk/libavformat/movenc.c: fix raw 555 pixel format, add abgr fourcc
[23:32:21] <Dark_Shikari> you should save the old binary
[23:32:27] <Dark_Shikari> so if you have to test again you don't have to recompile it
[23:32:35] <CIA-92> ffmpeg: bcoudurier * r23480 /trunk/libavformat/isom.c: More mov rawvideo fourcc
[23:33:12] <hyc> yeah... hmm, looks like make is remaking everything
[23:33:16] <hyc> not just the patched sources. sigh.
[23:33:53] <hyc> make -t
[23:34:27] <CIA-92> ffmpeg: bcoudurier * r23481 /trunk/libavcodec/raw.c: More mov rawvideo fourcc supported by the rawvideo decoder
[23:35:42] <bcoudurier> astrange are you around ?
[23:40:41] <hyc> Dark_Shikari: is there a makefile element to the patch? I get undefined symbol ff_simple_idct_dc_add_neon
[23:40:57] <hyc> linking ffmpeg fails
[23:44:41] <hyc> hmmm. config.mak has HAVE_NEON turned off
[23:44:50] <hyc> was I supposed to use some special configure flags?
[23:45:59] <hyc> I wonder why it didn't autodetect the platform
[23:48:03] <janneg> hyc: depends on the gcc config. following flags work probably --cpu=cortex-a8 --extra-cflags="-mfpu=neon -mfloat-abi=softfp"
[23:48:23] <hyc> ok. too bad, another 1 hour to recompile it all.
[23:52:58] <astrange> at the moment yes
[23:57:19] <Dark_Shikari> hyc: did you accidentally compile old ffmpeg without NEON?
[23:57:42] <hyc> Dark_Shikari: unfortunately, it looks that way
[23:57:47] <hyc> I ran configure with no options at all
[23:57:56] <Dark_Shikari> lol oops
[23:57:58] <Dark_Shikari> no wonder it's so slow
[23:59:39] <hyc> lemme try a cross-compile while that thing is crunching...