[00:34:51] <Dark_Shikari> astrange: that encoder was xvid avc? [01:16:08] <Dark_Shikari> Yuvi: you have a profile of theora now? [01:16:20] <Dark_Shikari> I wonder how much time init_frame is taking up, it seems wholly unnecessary [01:17:47] <Dark_Shikari> or at least inefficient [01:22:06] <Yuvi> Dark_Shikari: http://pastebin.com/m23eed1c8 3.5% [01:22:17] <Dark_Shikari> holy shit that's slow [01:22:21] <Yuvi> and yeah, it isn't necessary [01:22:29] <Yuvi> or won't be necessary [01:22:31] <Dark_Shikari> some of it might be [01:22:32] <Dark_Shikari> ah ok [01:22:35] <Yuvi> it's needed for the moment [01:22:37] <Dark_Shikari> so you've already factored that out in your planned overhaul? [01:22:43] <Yuvi> yeah [01:22:56] <Dark_Shikari> ah good. [01:23:07] <Dark_Shikari> did you come up with a way to make the MV decoding handling less shit? [01:23:13] <Dark_Shikari> e.g. not copying data all over the place [01:24:18] <Yuvi> figure out how many MVs there are when unpacking mb modes, decode that # in unpack_vectors and nothing else, do the rest immediately before actual MC [01:25:24] <Dark_Shikari> good, k [01:25:40] <Dark_Shikari> this already done and waiting for commit? [01:26:19] <Yuvi> done as in it's in my github repository, not done as in a clean diff from current svn [01:27:33] <Dark_Shikari> ah k [01:27:55] <Dark_Shikari> have you found a good way to deal with [01:27:55] <Dark_Shikari> #define DC_COEFF(u) (s->coeffs[u].index ? 0 : s->coeffs[u].coeff) //FIXME do somethin to simplify this [01:28:33] <Yuvi> currently, I simply store the actual DC in the fragment structure [01:28:53] <Dark_Shikari> k [01:29:00] <Dark_Shikari> so that simplifies that [01:31:40] <Dark_Shikari> any reason we don't have an sse loopfilter? [01:32:21] <Yuvi> it can't be done with width 16 due to the retarded ordering [01:32:29] <Dark_Shikari> it might be worth unpacking on faster CPUs though [01:32:34] <Dark_Shikari> to limit the amount of bitmath [01:32:43] <Dark_Shikari> penryn, nehalem, and phenom [01:32:51] <Dark_Shikari> i.e. doing it in 16-bit math [01:33:38] <Yuvi> might be worth doing, neon certainly does it with 16-bit math [01:33:57] <Dark_Shikari> note unpack in sse is very slow on core 2 conroe [01:34:07] <Dark_Shikari> and probably not worth it on anything older [01:34:10] <Dark_Shikari> but definitel worth trying [01:35:25] <Dark_Shikari> also did you fix the fixed-size tables thingy? [01:36:14] <Dark_Shikari> also,w hat are the different %s in the profile? [01:37:13] <Dark_Shikari> also put_no_rnd_pixels8_l2_c being at 4.5% is serious [01:38:00] <Yuvi> I did for the emu_edge_buffer, not qscale table [01:38:26] <Yuvi> the first % is self, second is total including sub functions [01:39:49] <Yuvi> and yeah, I haven't written dsp functions that don't need that branch, and don't really want to write asm versions of _l2 when they'll be replaced by them [01:40:10] <Dark_Shikari> the branch is nasty [01:40:24] <Dark_Shikari> unpredictable [01:41:17] <Dark_Shikari> ugh, it's hard to find things to optimize because you're changing so much of it [01:41:32] <Dark_Shikari> oh, a note about the loop filter [01:41:43] <Dark_Shikari> the loop filter code is called under if( y > 0 ) [01:41:51] <Dark_Shikari> therefore, I don't think we need the y > 0 check in the loopfilter [01:43:24] <Yuvi> (y>>3)-1 [01:44:00] <Yuvi> it's called on the previous row, so it needs the y>0 check outside so we don't call it on negative rows [01:44:04] <Dark_Shikari> oh, ew [01:45:47] <Dark_Shikari> hmm, I just realized that if you wanted to be an utter dick, you could do something trashy like this [01:45:54] <Dark_Shikari> have reference frame be the same thing as the current frame [01:46:14] <Dark_Shikari> and decode blocks in an order such that you never overwrite critical data [01:46:27] <Dark_Shikari> but the logic would probably not be worth it to save memory/cache [01:47:46] <Dark_Shikari> oh btw, what's the longest possible VLC code for a motion vector? [01:48:08] <ohsix> 42 sam hocevars [01:48:32] <Yuvi> how would that work / what would it gain? [01:48:42] <Yuvi> and 12 bits iirc, I'll check [01:49:05] <Dark_Shikari> it would save massive amounts of cache and memory. how would it work? now that I think about it, probably pretty badly [01:49:18] <Yuvi> nope 8 bits [01:49:36] <Dark_Shikari> can't we make the VLC reading function better then? [01:49:39] <Dark_Shikari> and do a direct table lookup? [01:49:59] <Dark_Shikari> motion_vector_table[show_bits(8)]; [01:50:32] <Yuvi> isn't that what get_vlc2 does if you change it to 8,1 instead of the current 6,2? [01:51:53] <Dark_Shikari> sorta but you can do better [01:51:59] <Dark_Shikari> if MIN_CACHE_BITS >= 16 [01:52:04] <Dark_Shikari> UPDATE_CACHE before reading the MV [01:52:08] <Dark_Shikari> and then SHOW_BITS(8) for the first MV [01:52:10] <Dark_Shikari> SKIP_BITS(8) [01:52:15] <Dark_Shikari> and SHOW_BITS(8) again for the second MV [01:52:27] <Dark_Shikari> this is what coreavc does for its entire cavlc code [01:52:32] <Dark_Shikari> and cabac [01:52:41] <Dark_Shikari> manual cache tracking to minimize update_cache calls [01:53:07] <Dark_Shikari> do all the bitstream readers have a MIN_CACHE_BITS of 16 or higher? [01:53:18] <Dark_Shikari> Yup they do [01:53:24] <Dark_Shikari> you're good then [01:53:57] <Dark_Shikari> also, coding_mode doesn't vary per frame, right? [01:54:02] <Dark_Shikari> you can get rid of that branch I think [01:54:40] <Dark_Shikari> i.e. merge them into the same thing, and specially construct the fixed table such that it works with a show_bits [01:54:54] <Dark_Shikari> unless the fixed mode is _common_ in which case it should probably be optimized [01:55:03] <Dark_Shikari> oh, and skip_bits(8) is obviously wrong, ignore that [01:55:42] <Dark_Shikari> this would make the VLC table bigger though. [01:55:49] <Dark_Shikari> I don't think we're lacking for cache though. [01:57:07] <Yuvi> well, the fixed mode is used if most MVs are longer than 4 pixels [01:58:25] <Yuvi> cache probably isn't too important given that only one type of data is decoded at once [01:58:58] <Dark_Shikari> true [01:59:08] <Dark_Shikari> how often is the fixed mode used in practice? [01:59:50] <Yuvi> dunno [02:03:35] <Dark_Shikari> could test it [02:11:16] * Dark_Shikari looks at unpack_vlcs [02:11:26] <Dark_Shikari> I think in general this could benefit a lot from larger VLC tables with fewer levels [02:12:43] <Yuvi> fixed is used from between 1/5 and 1/2 of the time depending on source ofc [02:21:48] <CIA-17> ffmpeg: michael * r21784 /trunk/libavcodec/h264_direct.c: [02:21:48] <CIA-17> ffmpeg: Pack MVs together from the begin for spatial direct, this simplifies the code [02:21:48] <CIA-17> ffmpeg: and is a bit faster (5-10 cpu cycles depending on what is meassured). [02:30:54] <Dark_Shikari> Yuvi: hmm. maybe the code could be templated? [02:31:17] <astrange> 19:35 <@Dark_Shikari> astrange: that encoder was xvid avc? <- it wrote XVID into a sei [02:31:35] <Dark_Shikari> astrange: or pascal just liked xvid =p [02:31:37] <astrange> it might have been a joke, i know skal did write his own h264 codec though [02:31:49] <astrange> it was on his old site [02:32:08] <astrange> er, the codec wasn't, but "i wrote one" was [02:35:06] <Dark_Shikari> yeah, templated code makes the most sense. [02:35:10] <Dark_Shikari> since it's run on the whole frame at a time [02:35:47] <Dark_Shikari> if (run_length == 4129) <--seriously needs a comment [02:48:30] <CIA-17> ffmpeg: michael * r21785 /trunk/libavcodec/h264_direct.c: [02:48:31] <CIA-17> ffmpeg: Special case for spatial direct MV predictor being 0. [02:48:31] <CIA-17> ffmpeg: a little less than 200 cpu cycles faster with the cathedral sample. [03:44:05] <CIA-17> ffmpeg: cehoyos * r21786 /trunk/libavcodec/libgsm.c: [03:44:05] <CIA-17> ffmpeg: Fix compilation with --enable-libgsm on Gentoo and OpenSUSE. [03:44:05] <CIA-17> ffmpeg: Patch by Ramiro [03:50:26] <CIA-17> ffmpeg: michael * r21787 /trunk/libavcodec/h264_direct.c: [03:50:26] <CIA-17> ffmpeg: Split spatial and temporal direct MV generation. [03:50:26] <CIA-17> ffmpeg: A little faster and needed for future optimizations. [03:50:26] <CIA-17> ffmpeg: This sadly leads to some code duplication (which i hope i can factor out [03:50:26] <CIA-17> ffmpeg: again after the optimizations on the direcr mv code are done) [03:59:35] <Yuvi> ...wow, unpack_vectors does four full traversals of the coded blocks for each 4mv macroblock [03:59:44] <Yuvi> I did not realize that [03:59:49] <Dark_Shikari> Yeah. That. [04:01:58] <Yuvi> (it doesn't in my tree, so it'll be fixed soon) [04:01:59] <Yuvi> but ugh [04:24:28] <Dark_Shikari> Yuvi: another idea is some loop unrolling or special casing in order to eliminate edge checks [04:24:35] <Dark_Shikari> or just setting up the arrays with edge buffers [04:24:47] <Dark_Shikari> reverse dc pred is a particularly good target for this [04:27:25] <Dark_Shikari> hmm. I wonder if there's a nice bitmath version of if( abs(x-y) > 128 ) taking advantage of the fact that 128 is a nice round number [04:30:26] <astrange> peloverde: some (all?) of the constant divides i noted are still there, could they not be made reciprocal multiplies? [04:33:09] <astrange> int f = abs(x-y)>128; is already branchless with a copy cr -> gpr instruction [04:33:16] <astrange> what's the if body? [04:33:37] <Dark_Shikari> if (FFABS(predicted_dc - vu) > 128) [04:33:37] <Dark_Shikari> predicted_dc = vu; [04:33:37] <Dark_Shikari> else if (FFABS(predicted_dc - vl) > 128) [04:33:37] <Dark_Shikari> predicted_dc = vl; [04:33:37] <Dark_Shikari> else if (FFABS(predicted_dc - vul) > 128) [04:33:40] <Dark_Shikari> predicted_dc = vul; [04:33:53] <Dark_Shikari> has to be done for basically every block [04:33:58] <Dark_Shikari> despite it triggering basically 0% of the time [04:34:02] <Dark_Shikari> thus, it annoys me [04:35:05] <astrange> predictably false is faster than branchless (maybe?), but three compares instead of one isn't great [04:35:20] <Dark_Shikari> but the checks themselves aren't very fast either [04:35:59] * Dark_Shikari checks the asm [04:42:20] <Yuvi> Dark_Shikari: yeah, haven't really looked at that quite yet [04:42:32] <Yuvi> the edges that is [04:42:58] <Yuvi> http://github.com/yuvi/ffmpeg/commit/01da0d178c3499f1ac6d87d644327a101f29b76... did some stuff to dc pred including only running those 3 checks for the 1 case they matter [04:43:19] <Yuvi> but which happens to be nearly every block for keyframes still [04:44:02] <Dark_Shikari> http://pastebin.com/m41ea818b [04:44:28] <Dark_Shikari> how much faster was that? [04:44:32] <Dark_Shikari> oh [04:44:34] <Dark_Shikari> I see... [04:44:46] <Dark_Shikari> btw, for reference, transform == 15 is by far the most common case [04:44:48] <Dark_Shikari> I did statistics on this [04:45:22] <Dark_Shikari> which is why the switch isn't too useful [04:47:00] <Yuvi> makes sense [04:47:11] <Dark_Shikari> oh, another thing [04:47:15] <Dark_Shikari> if we keep the current system [04:47:16] <Dark_Shikari> we could do [04:47:20] <Dark_Shikari> if( predictor_transform[transform][3] == 116 ) [04:47:29] <Dark_Shikari> it's already in a register from before, and simplifies the logic [04:47:47] <Dark_Shikari> btw, for reference, are we allowed to commit trivial optimizations to vp3 without discussion as long as we bench it? [04:48:07] <astrange> ask mike [04:48:21] <Dark_Shikari> ok [04:48:27] <astrange> btw gcc assumes if (x == y) is untaken [04:48:41] <astrange> i don't think that affects many things though [04:48:59] <Dark_Shikari> interesting. [04:49:54] <Yuvi> mike didn't say anything when michael suggested I just commit directly [04:50:22] <astrange> http://gcc.gnu.org/viewcvs/trunk/gcc/predict.def?revision=154645&view=markup [04:50:33] <Yuvi> but I guess I'll send my next set since there isn't really any speed improvement, just -100 LOC and less memory usage [04:51:38] <Yuvi> gnu commit messages... [04:52:17] <astrange> i looked for an anchor to skip it but didn't see one [04:52:41] <Dark_Shikari> hmm crap, I need a vp3/theora sample to test on again [04:52:48] <astrange> they're nice sometimes if you don't have log --stat [04:52:52] <Dark_Shikari> oh nvm, got one [04:53:52] <Yuvi> btw, tell me if you get a speedup with http://pastebin.com/m27da8328 [04:54:00] <astrange> huh, i was going to write an "enable malloc_aligned" patch for configure but it's already there [04:54:41] <Dark_Shikari> Yuvi: overall benchmarks are hard [04:54:45] <Dark_Shikari> any function you want me to test? [04:55:05] <Dark_Shikari> I'm not exactly on a system that gives stable results for large benchmarks [04:55:36] <Dark_Shikari> but even getting rid of all those stupid bad macroblock number messages is a good idea [04:55:53] <Dark_Shikari> and I like the patch [04:57:42] <Yuvi> unpack_modes/vectors I guess, but I was more interested in overall speedup [04:57:56] <Yuvi> guess I'll see if it helps on arm [05:01:35] <Dark_Shikari> hmm. I wonder how useful making keyframes long term refs would be in x264 [05:01:41] <Dark_Shikari> isn't the golden frame just the last keyframe? [05:01:48] <Yuvi> yeah [05:01:59] <Dark_Shikari> what's GOLDEN_MV vs USING_GOLDEN? [05:02:10] <Yuvi> latter impies 0,0 [05:11:21] <Dark_Shikari> hmm, I should go back through michael's optimizations and backport the relevant ones to x264 [05:11:25] <Dark_Shikari> I really like his 0,0 spatial direct one [05:11:29] <Dark_Shikari> I never thought of that before. [05:12:13] <astrange> splitting temporal and spatial up is nice. but now i have to wait until it's done again before i can merge into -mt [05:12:44] <astrange> and the theora changes probably broke that too. luckily draw_horiz_band does the same thing as what it broke so it can just go in there [05:16:36] * Dark_Shikari commits backport of mv0 spatial change [05:30:40] <Dark_Shikari> Yuvi: see my email [05:32:33] <Yuvi> I guess I should add a sample that uses multiple quants to what I check [05:33:26] <Dark_Shikari> good idea [05:45:30] <Dark_Shikari> looking through all of michael's changes, it's scary how much stuff there is [05:46:16] <Dark_Shikari> what does flatten attribute do? [05:46:33] <Yuvi> inlines everything it can that that function calls [05:46:42] <Dark_Shikari> ah, interesting [05:46:48] <Dark_Shikari> so it offers a way to inline from the opposite perspective [05:46:54] <Dark_Shikari> that might be useful. [05:46:59] <Dark_Shikari> do any other compilers support it? [05:47:04] <Yuvi> llvm doesn't [05:47:07] <Dark_Shikari> icc? [05:47:14] <astrange> llvm doesn't and tends to inline in the wrong direction too [05:47:17] <Dark_Shikari> lol [05:47:20] <astrange> didn't check icc [05:47:32] <Yuvi> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-June/072008.html doesn't look like it [05:47:33] <astrange> llvm inlines get_cabac_residual*dc back into one get_cabac_residual somehow [05:47:56] <astrange> i'll send an always_inline patch for that in a sec [06:33:56] <pJok> mornings [06:34:13] <kshishkov> goda morgnar [07:31:19] <_av500_> gm [07:32:06] <kshishkov> wyaat? [07:39:10] <astrange> 4.2%1447 memset(h->non_zero_count[mb_xy], 0, 32); [07:39:20] <astrange> hmm, that should be zero128 * 2 [07:40:03] <astrange> gcc 4.2 generates rep stosw instead [08:43:23] <siretart> Dark_Shikari: okay, now that I have tested that your proposed libx264.c works with x264 in ubuntu, can you please suggest me a newer git revision that you would think would be fit for the next ubuntu release? [08:50:30] <Dark_Shikari> what architectures will the release be on? [08:52:07] <Dark_Shikari> siretart: ? [08:57:10] <Dark_Shikari> and what's the deadline [09:07:57] <siretart> Dark_Shikari: http://wiki.ubuntu.com/ReleaseSchedule, at 'FeatureFreeze' the new version must have arrived the archive. [09:08:27] <siretart> Dark_Shikari: as for architectures, the most important are i386, amd64, and armel [09:08:55] <Dark_Shikari> armel? [09:08:56] <Dark_Shikari> what's arm el [09:09:06] <kshishkov> ARM little-endian [09:09:11] <siretart> arm with EABI and little endian. aka 'the new arm port' [09:09:27] <Dark_Shikari> oh, so you're saying I have to pick a version from before dec. 3? [09:10:03] <siretart> no, I'm saying the new version must be in the archive before next thursday [09:10:08] <Dark_Shikari> Oh [09:10:14] <Dark_Shikari> whoops, was looking in the wrong place [09:10:23] <Dark_Shikari> ok, we have an arm compile fix locally [09:10:27] <Dark_Shikari> currently arm compilation is broken [09:10:57] <Dark_Shikari> possible plan: [09:11:00] <siretart> and I'll be on a buisness trip from next wednesday to friday with probably limited internet connection [09:11:02] <Dark_Shikari> 1) feature freeze today [09:11:05] <Dark_Shikari> 2) get commits in this weekend [09:11:14] <Dark_Shikari> 3) give until tues/wed for any reported bugs [09:11:18] <Dark_Shikari> 4) upload that [09:11:29] <Dark_Shikari> of course this depends on whether pengvado shows up [09:11:37] <Dark_Shikari> I have a number of "potentially stable" revisions sitting around to pick from if he doesn't [09:11:44] <siretart> okay, that sounds reasonable. [09:11:47] <Dark_Shikari> and of course we could pick 1416 and backport the single arm fix if necessary [09:11:57] <siretart> btw, feature freeze doesn't mean that we cannot update the package anymore [09:12:12] <siretart> it is rather a syncronisation point for 'no radical changes from this point on' [09:12:18] <Dark_Shikari> ah ok [09:12:23] <Dark_Shikari> so we can still add minor fixes/etc [09:12:40] <siretart> sure [09:12:53] <Dark_Shikari> ah k. [09:14:49] <siretart> this means for me that I can just package current x264 tip and test your patch against that, is that correct? [09:14:55] <Dark_Shikari> yes. [09:15:02] <Dark_Shikari> we have no API changes planned in the near future [09:15:09] <Dark_Shikari> well, we have one locally, but nothing ffmpeg will use [09:15:10] <siretart> ok, that's what I need to know [09:15:15] <Dark_Shikari> nor does it change ABI [09:15:25] <Dark_Shikari> it just changes the capabilities of encoder_reconfig [09:15:29] <Dark_Shikari> so it's sort of a "free API change" [09:15:34] <siretart> I see that I find some time for that tonight [09:15:38] <Dark_Shikari> great [09:16:09] * thresh raises a letter plate saying 'fix arm already' [09:16:49] <Yuvi> l;o [09:17:00] <Dark_Shikari> thresh: do you want the patch? [09:17:03] <Dark_Shikari> pengvado is afk and it's annoying [09:17:35] <thresh> Dark_Shikari: i have a hack locally that worksforme (tm), so it wouldnt really change anything [09:17:45] <Dark_Shikari> k [09:19:58] <Dark_Shikari> just tell pengvado to stop disappearing randomely [09:20:04] <Dark_Shikari> or find us another BDFL [09:20:34] <kshishkov> you can always steal fenrir back ;) [09:20:44] <Dark_Shikari> that would require money [09:20:50] <Dark_Shikari> like, enough to outbid ateme [09:21:35] <kshishkov> can't you give him say 50% of your overall x264 profit? [09:22:33] <Dark_Shikari> lol [09:22:38] <Dark_Shikari> iirc the allocation is like 15% [09:29:51] <kshishkov> still, offer him CEO position, 25% shares [09:30:54] <Dark_Shikari> he hasn't done anything in 5 years [09:30:54] <Dark_Shikari> -.- [09:31:13] <kshishkov> maybe it's _your_ fault? [09:31:17] <Dark_Shikari> lol [09:31:23] <Dark_Shikari> because I was totally on the project 5 years ago ;) [09:31:29] <Dark_Shikari> (more likely, it's ateme's fault ;) ) [09:39:43] <thresh> Dark_Shikari: why do you need someone to control your patches? [09:39:57] <thresh> usually angry users with failing compiles and / or encodes do that :-) [09:42:48] <Dark_Shikari> thresh: the way we keep code quality is simple [09:42:53] <Dark_Shikari> _ALL_ changes are reviewed by both me and pengvado [09:42:56] <Dark_Shikari> no matter who wrote them [09:43:06] <Dark_Shikari> though nowadays we're adding to that, usually bugmaster reviews too. [09:43:16] <Dark_Shikari> and sometimes yuvi, kierank, and/or kemuri9. [09:43:26] <Dark_Shikari> but the main restriction is that both of the lead devs should review the code. [09:43:39] <Dark_Shikari> and I don't like violating that, it's bad form [09:43:44] <Dark_Shikari> and bad for code quality [09:44:38] <thresh> okay, maybe there should be a 'closing window' for that [09:45:45] <thresh> i mean if someone is absent and the review was done by other team members, commit those anyway [09:46:06] <thresh> but you know better, i'm sure [09:47:17] <Dark_Shikari> just from experience, everyone always has at least one thing they want changed [09:47:22] <Dark_Shikari> and in a large set of patches, it's usually more than one [09:47:33] <Dark_Shikari> so if you don't wait for them, you end up committing a fix afterwards anyways [10:37:17] <astrange> /home/fate/fate64/source/libavcodec/h264_direct.c:441:11: warning: incompatible pointer types assigning 'int16_t (*)[2]', expected 'int16_t const (*)[2]' [10:37:21] <astrange> l1mv1 = &h->ref_list[1][0].motion_val[1][h->mb2b_xy [mb_xy]]; [10:37:29] <astrange> is there a point to this warning? [10:45:28] <pJok> it expected a const rather than a non-const [10:48:09] <astrange> other way round [11:15:06] <kshishkov> pross-au: can you send me your BIKb decoder in exchange for your name in libavcodec/bink.c ? [11:17:31] <pross-au> wilco [11:18:28] <Dark_Shikari> roger [11:18:59] * kshishkov remembers Space Quest series immediately [11:19:13] <kshishkov> thanks [11:22:57] <neo01124> can someone tell me some starting points for creating/porting a demuxer for the sony playstation portable format PMP [11:22:59] <neo01124> ? [11:23:35] <kshishkov> google.com was always a good starting point for anything [11:24:38] <kshishkov> it says "skip 124 bytes of PSP metadata and decode it as an ordinary JPEG" [11:24:46] <andoma> anyone know anything about a FFmpeg implementation of WMA lossless? [11:25:10] <kshishkov> andoma: well, unless jai does it, we've BBB to do it [11:25:25] <kshishkov> andoma: also Mike showed some interest but that's all [11:26:26] <andoma> hm ok .. i see [11:26:30] <andoma> i was just curious [11:29:16] <neo01124> kshishkov: could you give me the link for that [11:30:14] <Dark_Shikari> www.google.com [11:30:19] <kshishkov> neo01124: here, first link from Google search on "PMP format" - www.klingebiel.com/tempest/hd/pmp.html [11:36:32] <neo01124> kshishkov: i was asking about the playstation portable pmp format, that is some sony camera format [12:15:57] <DonDiego> neo01124: look at other simple demuxers, check out the multimedia wiki [12:16:04] <DonDiego> and the developer documentation [14:10:42] <DonDiego> what is libaacplus? [14:10:59] <DonDiego> i stumbled across a libaacplus glue patch for ffmpeg [14:11:21] <kshishkov> reference 3GPP encoder glued to FFmpeg [14:11:55] <kshishkov> http://tipok.org.ua/node/17 [14:12:03] <mru> DonDiego: did that nellymoser guy go silent? [14:12:22] <kshishkov> (it's like a doorstop since everybody stumbled on it) [14:13:24] <tipok> ? [14:14:02] <DonDiego> mru: yes [14:14:30] <tipok> it's encoder only [14:15:02] <kshishkov> yes, but its license prevents from using it in FFmpeg [14:15:29] <tipok> hmm... it's better than nothing [14:15:50] <kshishkov> yes, it the same way as it was with AMR [14:19:20] <twnqx> what i never was sure abou [14:19:20] <twnqx> t [14:19:46] <twnqx> is using dlopen() and friends to runtime use a library the same as linking against it, licensewise? [14:20:34] <kshishkov> how much are you going to pay? [14:20:43] <twnqx> lol [14:20:48] <twnqx> i don't care enough :> [14:20:55] <thresh> you're allowed to do that [14:20:59] <thresh> IIRC [14:21:30] <kshishkov> if you are not, just tip any cop around and do it anyway [14:21:45] <twnqx> i have no intention to write a program at the moment [14:21:48] <twnqx> i just wondered. [14:22:09] <twnqx> i thought among the lines of "if the program really requires it to do anything it surely would violate the liecense, otherwise... maybe. [14:22:11] <DonDiego> twnqx: yes, it's the same, why would there be a difference [14:22:41] <kshishkov> manual dynamic linking [14:23:46] <DonDiego> the license does not care about the type of linking [14:24:01] <kshishkov> neither do I [14:24:17] <DonDiego> people keep thinking that because there is a technical difference there must be a legal difference [14:24:22] <DonDiego> this is not the case [14:24:45] <DonDiego> the law is not aligned along the same boundaries as C code [14:24:55] <twnqx> i thought the difference is "must be there" or "the user can place it there" [14:25:20] <mru> dlopen can make a difference if there are multiple libs with the same interface but different licences [14:25:30] <twnqx> as in "if the user puts the amr liberaries there we can use it, but we don't need them" [14:25:41] <DonDiego> yes [14:25:51] <DonDiego> but the difference is not the technical interface [14:25:59] <DonDiego> the difference is that in one case you ship the libs [14:26:03] <DonDiego> in the other you don't [14:26:04] <twnqx> true, but you can't to that with static linking [14:26:18] <DonDiego> but do you see the difference? [14:26:28] <twnqx> ig it's about shipping, yes [14:26:30] <twnqx> if* [14:26:36] <twnqx> but i was thinking of GPL impact, e.g. [14:27:27] <twnqx> i mean, as e.g. ffdshow enables the use of GPL'd code on windows, used by closed source players... [14:27:47] <kshishkov> DonDiego: tainted Linux kernel serves an example [14:32:24] <DonDiego> dshow is a system interface that passes data on to codec implementations that may be free or proprietary [14:32:31] <DonDiego> how would the calling application know? [14:32:45] <DonDiego> the calling app is not derived from the gpl codec code [14:35:05] * justlooking notices theres 24 patches in x264dev that look interesting once they pass review peloverde [14:37:02] * justlooking opps wrong window [16:37:22] <DonDiego> mru: why ifdef CONFIG_MPEGAUDIO_HP [16:37:26] <DonDiego> and not ifeq? [16:37:32] <DonDiego> in libavcodec/Makefile [16:37:48] <kshishkov> maybe because nobody has canged code for it? [16:37:51] <kshishkov> *changed [16:39:38] <mru> DonDiego: ifdef is correct [16:40:21] <mru> ifeq ($(FOO),) is ugly [16:41:00] <kshishkov> had anybody read MN mail to MPlayer-dev-eng ML about binary codec support in FFmpeg? [16:41:29] <DonDiego> oops [16:41:35] <DonDiego> what happened there? [16:41:39] <mru> kshishkov: that's been out of the question forever [16:42:00] <kshishkov> mru: and if I read it correctly, he is in favor of adding it [16:42:16] <mru> well, I'm not [16:42:25] <mru> it doesn't belong there [16:43:02] <kshishkov> yes, it seems to be counterproductive [16:43:11] <kshishkov> yet it's strange to see that message at all [16:44:21] <mru> subject? [16:45:34] <kshishkov> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-February/063622.htm... [16:46:33] <mru> ffmpeg is not supposed to be the one wrapper to use them all [16:47:53] <Compn> yes, but thats what ffmpeg has become [16:48:07] <Compn> and we know people like the unified api that ffmpeg gives to x264/xvid/faac/etc [16:48:23] <kshishkov> it does not permit knowlingly lowsy code to be executed though [16:49:07] <mru> I'm all for dropping the xvid wrapper [16:49:21] <Compn> seems like an anti-user opinion [16:49:26] <mru> ffmpeg policy has always been to wrap only clean libs [16:49:27] <kshishkov> you don't like redundancy? [16:49:32] <mru> and then only when no native support exists [16:49:33] <Compn> kshishkov: think of it as using binary codecs for testing (which is what you do now, just with mplayer..) [16:50:07] <kshishkov> Compn: too bad avidemux is dead [16:50:29] <kshishkov> mru: but in that case lavc encoder is also better [16:53:56] <Honoome> kshishkov: don't name avidemux again when I'm around please :P [16:55:03] <kshishkov> Honoome: why? [16:55:21] <Honoome> had a bad experience with the author… [16:55:38] <kshishkov> ah, understood [16:55:42] <astrange> lavc is better at slower settings, i don't know if it's better at xvid speeds [16:56:07] <kshishkov> more feature-complete too [16:56:11] <astrange> maybe just because i could never figure out good settings for that, it needs an AI preset generator [16:56:14] <Honoome> basically when I first joined Gentoo I was looking at fixing the bundled-libs issues with it… so I rewrote the configure to have switches to disable stuff [16:56:35] <Honoome> sent upstream… he merged part of it and broke the rest… re-did the patch from scratch on the new version… again only partly merged and broke the rest =_= [16:57:00] <mru> reminds me of broadcom [16:59:04] <Honoome> with the crystalhd stuff? [16:59:28] <mru> no [16:59:43] <mru> with their stb chips [17:00:06] <Honoome> oh, okay… sorry but my last contact with broadcom has been at the time of the iBook g4 :P [17:13:52] * elenril wonders if he should try gsoc this year [17:14:14] <kshishkov> do we have GSoC tasks on metadata? [17:14:34] <elenril> no, but we can make some :) [17:15:01] <elenril> and i'm not just meta guy [17:22:46] <kshishkov> well, what are your other achievements? [17:23:40] <elenril> a failed matroska ordered chapters patch ;) [17:24:51] <elenril> normal chapters for matroska [17:45:46] <Honoome> elenril: you name matroska and chapters and beandog appears :P [17:45:57] <beandog> whut? [17:45:59] <beandog> whatd I miss [17:46:15] <Honoome> nothing really, just poking fun :) [17:47:01] <beandog> Aww [17:47:08] * elenril doesn't see the connection [17:47:20] <kshishkov> let's see [17:47:21] <beandog> chapters are good for you [17:47:24] <Honoome> elenril: I remember beandog fighting hard about matroska chapters before :P [17:47:33] <beandog> Ah, si [17:47:56] <beandog> and metadata [17:48:15] <Kovensky> ordered chapters where =p [17:49:37] <elenril> Kovensky: repo.or.cz/mplayer =p [19:27:58] <lu_zero> .... [19:28:18] <lu_zero> seems that their service got updated in a quite annoying way... [19:29:32] <Honoome> lu_zero: their as in Freenode's? [19:29:46] <lu_zero> yes... [19:29:53] <Honoome> lu_zero: are you sure it's not tiscali? :P [19:30:00] <lu_zero> yes I am. [19:30:08] <lu_zero> I'm in too many channels [19:54:47] <DonDiego> Yuvi: i see you started merging your theora branch :) [19:54:55] <DonDiego> Yuvi: or is this something else? [21:01:05] <elenril> J_Darnley: why did you add those two mappings to vorbiscomment conv table? [21:04:35] <J_Darnley> date-year because the vorbiscomment docs suggest date [21:05:07] <elenril> and the corresponding generic tag also happens to be date [21:05:13] <elenril> so no conversion is necessary [21:05:17] <elenril> same for artist [21:05:41] <J_Darnley> But if I use -metadata year=1982 nothing is converted [21:06:05] <elenril> because you're not supposed to use year [21:06:22] <J_Darnley> That won't stop people [21:06:23] <elenril> we don't have a year tag anymore [21:06:28] <elenril> blame bcoudrier [21:06:45] <elenril> i wanted to add a compatibility layer, but he didn't [21:07:11] <J_Darnley> And I did author-artist because sources seem to be conflicted about what to use [21:07:18] <Yuvi> DonDiego: yep [21:07:20] <elenril> huh? [21:07:21] <elenril> where [21:07:38] <J_Darnley> avformat.h and metadata_compat.c [21:08:05] <elenril> metadata_compat is legacy stuff [21:08:09] <J_Darnley> oh [21:08:23] <J_Darnley> (why is it still there) [21:08:26] <elenril> it will be removed on next lavf major bump [21:08:30] <elenril> for compatibility [21:08:34] <elenril> (as the name suggests =p ) [21:09:16] <J_Darnley> I will use that argument too, "it's for compatibility" [21:10:06] <elenril> adding the date<->year mapping would convert all 'date' tag demuxed from ogg files into 'year' generic tags [21:10:15] <elenril> but there is no year generic tag anymore [21:11:31] <elenril> s/anymore// [21:13:41] <J_Darnley> oh, that is a problem [21:16:17] <elenril> feel free to send a patch adding a compatibility layer if you think it's needed [21:16:39] * elenril doesn't feel like arguing with Baptiste over this [21:19:20] <J_Darnley> Is anything printed if sonone uses a not-recommended key? [21:19:25] <J_Darnley> *someone [21:19:57] <J_Darnley> Or will anything be printed? [21:20:05] <elenril> no [21:20:16] <elenril> all keys that aren't mapped to anything will be left as is [21:24:20] <DonDiego> Yuvi: is it merged completely already? [21:24:58] <Yuvi> DonDiego: nope, still a lot left [21:29:43] <DonDiego> do you have an eta? [21:36:19] <Yuvi> probably a week or two before most of it's merged [21:37:54] <DonDiego> excellent, so we will have it for 0.6 [21:38:01] <DonDiego> "works with html 5" :) [21:42:40] <Honoome> somebody got to send me the files of the design so I can get one shirt with that myself :P [21:42:52] <DonDiego> Yuvi: did you run any benchmarks with your latest version? [21:42:55] <DonDiego> Honoome: ask mru [21:43:03] <_av500_> mru might have some left... [21:43:21] <Yuvi> DonDiego: http://pastebin.com/m3916b277 [21:43:30] <Yuvi> that's BBB 1080p [21:43:55] <elenril> nice [21:47:31] <DonDiego> Yuvi: cool, that's considerably faster... [21:47:35] <DonDiego> congrats [21:51:37] <_av500_> so theora is good for html5 after all.. :) [21:52:32] <DonDiego> gnite [21:58:20] <iive> Yuvi: do you have blog? [22:10:36] <peloverde> Has anyone ever tried to patch gecko to use ffmpeg? [22:11:49] <ShadowJK> they're working on gstreamer I think.. [22:13:00] <peloverde> But gstreamer refuses to talk to our aac decoder and probably our theora decoder as well [22:16:26] <iive> are they really doing it? [22:18:31] <ShadowJK> https://bugzilla.mozilla.org/show_bug.cgi?id=422540 [22:19:36] <peloverde> wow blizzard seemed to be way against such ideas at FOSDEM [22:21:39] <Dark_Shikari> they will probably just make it only work with theora [22:23:36] <peloverde> They seem to be pushing fluendo h.264 [22:23:46] <peloverde> why do all these people like fluendo so much? [22:24:29] <Honoome> 'cause they have good PR? :P [22:24:54] <Dark_Shikari> peloverde: because they are pro-proprietary software [22:24:56] <Dark_Shikari> and anti-open source [22:25:06] <Dark_Shikari> and they have commandeered the "free software" movement to push proprietary solutions [22:26:03] <Honoome> Dark_Shikari: which is kinda silly … if it's a Free license it's bad because patented, but if it's a proprietary license, it's okay o_O [22:26:12] <Dark_Shikari> they don't care about patents [22:26:17] <Dark_Shikari> they're all about subverting free software [22:26:31] <Dark_Shikari> and promoting proprietary binary blobs on linux is a good way to do it. [22:26:51] <Honoome> Dark_Shikari: I meant the stance that a lot of zealots seem to take nowaday [22:26:52] <Dark_Shikari> moreso, they're also anti-ffmpeg [22:26:56] <Dark_Shikari> Honoome: yes, that's the point [22:27:00] <Dark_Shikari> the zealots are anti-free-software [22:27:03] <Dark_Shikari> they're pro-whatever-they-like [22:27:36] <Honoome> Dark_Shikari: I actually meant the same zealots that send me shit because I happen to like Mono [22:27:53] <Dark_Shikari> yes, mono is free software [22:28:38] <Dark_Shikari> the zealots would rather you use microsoft .net than mono. [22:30:05] <iive> actually i think RMS should have allowed distribution with patents and mandate that each user obtain license on its own. [22:30:22] <Dark_Shikari> that's how it already is [22:30:29] <Dark_Shikari> SFLC agrees [22:30:31] <Dark_Shikari> don't bother them about it [22:30:32] <Honoome> Dark_Shikari: actually, they'd rather use Flash than Mono :P [22:30:49] <Dark_Shikari> the zealots prefer microsoft .net to mono [22:30:51] <Dark_Shikari> Flash to Gnash [22:30:54] <iive> no, it's not mandated. [22:30:57] <Dark_Shikari> Silverlight to Moonlight [22:31:12] <Dark_Shikari> they are quite simply anti-free-software [22:31:20] <Honoome> I talk of different zealots here ;) [22:31:27] <Dark_Shikari> no, they're the same. [22:31:28] <iive> the point is, when all people start paying to some other people, they would start asking question, why i should pay them? [22:31:50] <Honoome> iive: “to have something better” is the answer they give themselves… [22:32:09] <Honoome> now of course… _sometimes_ that's true (*cough* openoffice sucks big time *cough*) [22:34:12] <iive> well, my point is to make visible the hidden cost of patents. [22:34:48] <iive> and let people think of patents not in term of how profitable it is, but how much they cost them. [22:35:24] <iive> on the other hand... nobody thinks this way for health insurance... so it may be bad plan. [22:36:33] <Honoome> iive: depends in which part of the world you live of course :D [22:50:23] <Yuvi> iive: no, I keep meaning to start one maybe sometime in the future [22:51:24] <iive> Yuvi: i've been urging people around to describe all theora shortcommings. So far I got only one big list with short descriptions. [22:52:21] * Honoome should really try to find the time to set up a Planet Multimedia or something >_< [22:52:42] <iive> Explaining this so people could understand it... entirely different task. And I'd be happy if I could not mess with theora. [22:53:51] <iive> My point. You can make description of all problems you had to solve in order to make theora faster. [22:54:55] <iive> And it would be good read, even if it doesn't try to smash theora into the dust. [22:56:00] <iive> usually it is better to don't have any smashing. [22:58:25] <peloverde> Not all the problems with theora are speed related [23:09:53] <iive> peloverde: i know