[FFmpeg-devel-irc] IRC log for 2010-02-13

[irc at mansr.com]

[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/01da0d178c3499f1ac6d87d644327a101f29b766 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.html
[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