[FFmpeg-devel-irc] IRC log for 2010-08-02
irc at mansr.com
irc at mansr.com
Tue Aug 3 02:00:12 CEST 2010
[00:18:29] <_skal_paris_> Dark: http://pastebin.org/439852
[00:19:03] <_skal_paris_> fate ok. now timing. What's the macros for doing some: *(uint32_t*)ptr = blah * 0x01010101u; already?
[00:20:46] <Dark_Shikari> AV_WN32A(ptr) = blah*0x01010101;
[00:21:11] <Dark_Shikari> 163: pointless change
[00:21:35] <Dark_Shikari> your code is worse in inter frames
[00:21:39] <Dark_Shikari> because inter frames don't need to store the data at all
[00:21:58] <_skal_paris_> could be fixed
[00:22:02] <Dark_Shikari> that's what the current code is optimized for -- the common case
[00:22:09] <Dark_Shikari> hence the ? at the start of the for loop
[00:23:26] <Dark_Shikari> I agree the current code can be improved, but the primary case assumed when writing the code should be inter.
[00:24:07] <_skal_paris_> why is it worse for inter?
[00:24:14] <_skal_paris_> i don't store
[00:24:51] <_skal_paris_> reminds me, i should even not reset to DC_PRED
[00:24:52] <Dark_Shikari> 121-123 yes you do
[00:24:57] <Dark_Shikari> I mean inter _frames_
[00:25:03] <Dark_Shikari> in inter frames, there is no i4x4 neighbor context
[00:25:07] <Dark_Shikari> therefore the data never needs to be stored at all
[00:25:25] <_skal_paris_> oh, i see
[00:25:38] <Dark_Shikari> hence the current code.
[00:25:44] <_skal_paris_> needs a ".. else if (s->keyframe) { ...}"
[00:26:02] <Dark_Shikari> imo the number of if(keyframe)s should be minimized
[00:26:41] <_skal_paris_> well, the current code was calling fill_rectangle() for nothing in case of inter
[00:26:57] <Dark_Shikari> er... no it wasn't
[00:27:20] <_skal_paris_> if it's not I4x4, the rectangle is not used
[00:27:24] <_skal_paris_> right?
[00:27:41] <Dark_Shikari> the ONLY place fill_rect is called:
[00:27:43] <Dark_Shikari> if (s->keyframe) {
[00:27:43] <Dark_Shikari> mb->mode = vp8_rac_get_tree(c, vp8_pred16x16_tree_intra, vp8_pred16x16_prob_intra);
[00:27:46] <Dark_Shikari> if (mb->mode == MODE_I4x4) {
[00:27:48] <Dark_Shikari> decode_intra4x4_modes(c, intra4x4, s->b4_stride, 1);
[00:27:51] <Dark_Shikari> } else
[00:27:53] <Dark_Shikari> fill_rectangle(intra4x4, 4, 4, s->b4_stride, vp8_pred4x4_mode[mb->mode], 1);
[00:27:57] <Dark_Shikari> note
[00:27:59] <Dark_Shikari> if (s->keyframe) {
[00:29:15] <_skal_paris_> oh, i see
[00:29:18] <_skal_paris_> my bad
[00:30:17] <_skal_paris_> so, 121-123 are still ok
[00:30:33] <_skal_paris_> as in: not used needlessly for inter
[00:35:10] <Dark_Shikari> yes
[00:35:18] <Dark_Shikari> In short, the current code is fine if you completely ignore intra performance
[00:35:25] <Dark_Shikari> s/intra/keyframe
[00:36:06] <_skal_paris_> i'm trying to squeeze memory here
[00:36:33] <Dark_Shikari> that's fine, just don't make inter slower
[00:36:49] <_skal_paris_> this plane of intra sitting here, doing nothing between keyframes => don't like
[00:37:18] <Dark_Shikari> memory costs nothing if it isn't being used
[00:38:18] <_skal_paris_> well, can't be used for something else
[00:39:13] <Dark_Shikari> ?
[00:39:15] <Dark_Shikari> sure it can
[00:39:27] <Dark_Shikari> if it isn't being used, it can be swapped out
[00:39:35] <Dark_Shikari> and doesn't use cache
[00:40:05] <Dark_Shikari> but yes it can't hurt to improve it
[00:40:40] <_skal_paris_> i see same speed here, on regular video
[00:40:51] <_skal_paris_> now trying on intra-only one, just to be sure
[00:42:11] <Dark_Shikari> Measuring speed is going to be very hard for such small changes
[00:42:17] <Dark_Shikari> I want to ensure that no more _code_ is executed than currently.
[00:42:37] <Dark_Shikari> I also don't want to increase memory fetch necessary for P-frames
[00:43:07] <Dark_Shikari> i.e. I don't want to change the fact that currently,in P-frames, a single 4x4 block of memory is used for all i4x4 data
[00:57:11] <_skal_paris_> yes.
[00:57:30] <_skal_paris_> sending the patch to the ML, so BBB/Yuvi can have a look later
[00:57:35] <_skal_paris_> i'm off to sleep anyway
[01:04:24] <_skal_paris_> see you
[01:08:47] <saintdev> well this really falls apart on fatboy.wav, and itunes kicks our ass
[02:58:24] <saintdev> well that (mostly) fixes fatboy, now how much did i break castanets?
[03:31:27] <saintdev> hmm, overall actually seems better. although it picks up a few more false positives :(
[04:42:39] <saintdev> kshishkov, peloverde: what is a sensible range for lambda?
[04:44:28] <kshishkov> depends on range control method
[04:44:38] <kshishkov> may be anything
[04:45:18] <saintdev> 1 billion? 1000? 6? -8000000?
[04:45:46] <kshishkov> usually it's positive
[04:45:58] <kshishkov> (i.e. > 0)
[04:46:05] <kshishkov> but can be negative too
[04:46:37] <kshishkov> at least I've used first three values during my experiments :P
[04:46:50] <saintdev> lol
[04:46:51] <saintdev> ok
[05:21:31] <CIA-92> ffmpeg: darkshikari * r24659 /trunk/libavcodec/ (vp8data.h vp8.c):
[05:21:31] <CIA-92> ffmpeg: VP8: simplify token_prob handling
[05:21:31] <CIA-92> ffmpeg: ~1.5% faster decode_block_coeffs
[05:24:46] <Dark_Shikari> hmm. I think we can eliminate vp8_coeff_band entirely.
[05:55:25] <Dark_Shikari> Yuvi: your connection seems to be having issues
[05:56:32] <Yuvi> My bouncer went down, and I can't fix it till I get home :/
[05:56:43] <Dark_Shikari> able to test a patch?
[05:56:52] <Dark_Shikari> or maybe efriedma
[05:56:59] <efriedma> Dark_Shikari: i'm around
[05:57:11] <Yuvi> Can't unfortunately, I forgot my laptop at home
[05:57:36] <Dark_Shikari> http://pastebin.org/440469
[05:57:47] <Dark_Shikari> idea: eliminate vp8_coeff_band[] dereferences.
[05:58:26] <Yuvi> Did you diff the wrong direction?
[05:58:47] <Dark_Shikari> no.
[05:59:49] <Yuvi> Oh I see
[06:00:46] <Dark_Shikari> I'm not sure if it's worth the L1 hit
[06:03:52] <efriedma> testing
[06:05:21] <Yuvi> How did skal's patch hurt p frames? It wasn't obvious to me from a brief
[06:06:15] <Dark_Shikari> a) more memory required in P-frames
[06:06:19] <Dark_Shikari> (worse caching)
[06:06:28] <Dark_Shikari> since p-frames don't need to store i4x4 data (but it did with his patch)
[06:06:39] <Dark_Shikari> b) some of the code was executed in p-frames that didn't need to be, and wasn't before
[06:11:36] <efriedma> Dark_Shikari: http://paste.pocoo.org/show/244493/ ; appears to be an improvement
[06:12:17] <efriedma> although, in the future, please don't pastebin patches with START_TIMER/STOP_TIMER in them :)
[06:12:43] <Dark_Shikari> er.... I wanted a start/stop timer of it
[06:12:44] <Dark_Shikari> lol
[06:13:15] <Dark_Shikari> (though that's good too -- I'd like both, though)
[06:13:20] <efriedma> does start_timer/stop_timer actually work right with early returns?
[06:13:27] <Dark_Shikari> there is no early return
[06:13:30] <Dark_Shikari> only in the case of invalid bitstream
[06:13:54] <efriedma> Dark_Shikari: DCT_EOB?
[06:14:09] <Dark_Shikari> oh. duh
[06:14:19] <Dark_Shikari> ok. put the timers around the call to it, instead
[06:14:22] <Dark_Shikari> pick the luma AC call
[06:14:31] <Dark_Shikari> "luma blocks"
[06:14:33] <Dark_Shikari> time that, see how it changes
[06:15:44] <Dark_Shikari> after this I'll have to try another evil idea I have involving nnz...
[06:19:10] <efriedma> Dark_Shikari: http://paste.pocoo.org/show/244496/ ; start/stoptimer around decode_block_coeffs call for luma blocks
[06:24:00] <efriedma> Dark_Shikari: you still there?
[06:26:12] <Dark_Shikari> yes, had to reboot
[06:28:00] <Dark_Shikari> I find it a bit odd that it's so much faster overall but only 1.5 cycles faster in the function where it matters...
[06:28:36] <Dark_Shikari> it doesn't seem to add up.
[06:30:02] <Dark_Shikari> do you time ffmpeg / ffmpeg_old / ffmpeg / ffmpeg_old ?
[06:30:09] <Dark_Shikari> or do you do ffmpeg ffmpeg ffmpeg ffmpeg_old ffmpeg_old ffmpeg_old ?
[06:30:14] <Dark_Shikari> I prefer to interleave runs to make sure
[06:30:53] <superdump> morning
[06:36:34] <Dark_Shikari> so efriedma, any ideas?
[06:36:44] <Dark_Shikari> Yuvi: thoughts on whether it's worth the cache?
[06:37:02] <efriedma> Dark_Shikari: the clip i'm using is relatively low bitrate... i'll try another clip
[06:37:24] <Dark_Shikari> k
[06:39:43] <efriedma> actually, let me try moving the start/stoptimer
[06:41:29] <Yuvi> Hm, probably shouldn't cost too much cachewise unless you have a fair number of coeff above index 7
[06:41:42] <Yuvi> Which means high bitrate
[06:43:00] <efriedma> Dark_Shikari: a bit more substantial: http://paste.pocoo.org/show/244502/
[06:43:20] <Dark_Shikari> that's not really more substantial %-wise
[06:43:41] <Dark_Shikari> also, my probability loading code is kinda slow
[06:43:43] <Dark_Shikari> not like it really matters
[06:47:20] <Dark_Shikari> I wonder if it's worth changing the smallest dimension of the array to simplify addressing
[06:47:23] <Dark_Shikari> probs, that is
[06:47:32] <Yuvi> I'd say it's worth it, only a couple more cachelines for when it helps the most
[06:48:58] <efriedma> Dark_Shikari: http://paste.pocoo.org/show/244505/ ; the speedup is definitely there, despite my not finding a good place to put the start/stoptimer macros
[06:50:44] <Yuvi> Yeah, try changing the smallest dimension, the current was chosen only to work with get_tree which isn't needed anymore
[06:55:42] <Dark_Shikari> efriedma: compare to http://pastebin.org/440558
[06:57:51] <efriedma> Dark_Shikari: testing
[07:01:24] <efriedma> Dark_Shikari: hard to distinguish: http://paste.pocoo.org/show/244511/
[07:01:30] <efriedma> do you want me to run longer tests?
[07:03:15] <Dark_Shikari> efriedma: I meant timer
[07:03:29] <efriedma> oh; will do
[07:03:32] <Dark_Shikari> these small changes are not measurable via "time"
[07:08:08] <efriedma> Dark_Shikari: http://paste.pocoo.org/show/244515/
[07:08:40] <Dark_Shikari> o.0
[07:08:51] <Dark_Shikari> can you do multiple runs to at least get some idea of stability?
[07:10:52] <_skal_paris_> back
[07:10:58] <efriedma> Dark_Shikari: old patch: http://paste.pocoo.org/show/244518/
[07:11:17] <Dark_Shikari> _skal_paris_: http://pastebin.org/440469 comments
[07:11:39] <Dark_Shikari> efriedma: what happened to the gains we were getting earlier?
[07:11:59] <efriedma> what do you mean?
[07:12:11] <Dark_Shikari> that pastebin you just gave me has no gains
[07:12:19] <Dark_Shikari> it has three results
[07:12:21] <Dark_Shikari> all of which are the same
[07:12:23] <efriedma> it's three runs with the first patch you gave me
[07:12:28] <Dark_Shikari> Oh
[07:12:32] <Dark_Shikari> I see.
[07:12:33] <efriedma> to give you an idea of the stability
[07:12:33] <Dark_Shikari> hmm.
[07:12:36] <Dark_Shikari> I have an idea.
[07:15:00] <_skal_paris_> Dark: sounds good
[07:15:13] <_skal_paris_> modulo the START/STOP_YOU_KNOW_WHAT :)
[07:16:19] <_skal_paris_> btw: can't the exit condition be "while (*token_prob);" instead of "while (i < 16);" ?
[07:16:25] <_skal_paris_> not sure what's bes
[07:16:27] <_skal_paris_> t
[07:23:25] <Yuvi> iirc probabilities of 0 are allowed
[07:24:35] <CIA-92> ffmpeg: benoit * r24660 /trunk/tools/patcheck: Issue a warning when fed with misformatted one-line doxygen comments.
[07:25:08] <Dark_Shikari> Yuvi: won't that still end up eating bits due to the rounding in the decoder?
[07:26:14] <CIA-92> ffmpeg: benoit * r24661 /trunk/libavcodec/libvpxenc.c:
[07:26:15] <CIA-92> ffmpeg: Fix doxygen comments.
[07:26:15] <CIA-92> ffmpeg: /**\u2264 => /**<
[07:26:26] <Yuvi> I think so
[07:26:34] <Yuvi> I'd have to check
[07:27:16] <CIA-92> ffmpeg: benoit * r24662 /trunk/libavcodec/wmaprodec.c: Change a doxy comment to a normal one.
[07:29:23] <CIA-92> ffmpeg: benoit * r24663 /trunk/libavformat/rl2.c: Fix doxygen comment.
[07:33:21] <_skal_paris_> Dark: you're not initializing the last extra token band #17 (token[4][16][...])
[07:33:52] <mru> the failometer is only ~50% green... ought we not at least try to fix something?
[07:33:58] <_skal_paris_> Dark: -> unitialized read in case of overflow (but no crash). It's just to keep valgrind happy
[07:34:20] <Dark_Shikari> I don't care about uninitialized reads on invalid data
[07:34:26] <Dark_Shikari> especially if they don't do anything
[07:34:49] <_skal_paris_> you only need to zero it once for alll at construction time
[07:35:18] <Dark_Shikari> _skal_paris_: http://pastebin.org/440625
[07:35:20] <Dark_Shikari> see if that does it.
[07:35:24] <Dark_Shikari> er
[07:35:25] <Dark_Shikari> I mean
[07:35:27] <Dark_Shikari> see if you can find my mistake
[07:35:31] <Dark_Shikari> because that patch doesn't work
[07:35:36] <Dark_Shikari> But it should get us the best of both worlds
[07:35:49] <Dark_Shikari> it (ab)uses the LUT to avoid the costly array addressing calculations
[07:36:09] <Dark_Shikari> I made some stupid error, see if you can find it
[07:37:19] <_skal_paris_> 33: isn't there a missing +1 in the size ?
[07:37:33] <_skal_paris_> (cf 46 and 55)
[07:37:45] <Dark_Shikari> ?
[07:37:57] <Dark_Shikari> oh wait, no, the padding comment should go away
[07:38:09] <Dark_Shikari> the padding is back in the lut
[07:38:22] <efriedma> Dark_Shikari: 94: doesn't vp8_coeff_band[i+1] need to be multiplied by something?
[07:38:36] <efriedma> err, wait nevermind
[07:38:42] <_skal_paris_> (it's probably time for a cool name for NUM_DCT_TOKENS-1, too :))
[07:38:45] <efriedma> that's the whole point of the patch :)
[07:40:00] <efriedma> Dark_Shikari: 68: don't you need to take into account zero_nhood?
[07:40:08] <Dark_Shikari> line 68
[07:40:09] <Dark_Shikari> yup
[07:40:12] <Dark_Shikari> found it at the same time you did
[07:41:17] <Dark_Shikari> yup. passes
[07:41:30] <Dark_Shikari> try timer-ing http://pastebin.org/440635
[07:41:35] <Dark_Shikari> vs the best of the previous patches
[07:41:46] <Dark_Shikari> I wonder if it helps extra because gcc sucks at multi-D arrays
[07:44:24] <Yuvi> I wish it didn't :/
[07:44:55] * mru wishes it didn't suck at all
[07:46:42] <efriedma> Dark_Shikari: http://pastebin.org/440647
[07:47:04] <Dark_Shikari> :/
[07:47:30] <Dark_Shikari> wtf
[07:47:33] <_skal_paris_> i still don't get the +1 at 45/54
[07:47:41] <Dark_Shikari> _skal_paris_: i hasn't been incremented yet
[07:47:41] <_skal_paris_> (is it just my lack of caeffine?)
[07:47:49] <_skal_paris_> oh, ok
[07:48:09] <Dark_Shikari> efriedma: maybe try on the other clip?
[07:48:25] <_skal_paris_> Dark: wait, it's during the init
[07:48:54] <Dark_Shikari> er, that isn't +1
[07:48:55] <Dark_Shikari> that's +l
[07:50:53] <mru> it's usually bad practice to use l as a variable name
[07:51:06] <mru> kshishkov: and 0 too
[07:51:31] <_skal_paris_> bwaha
[07:51:34] <_skal_paris_> my silly self
[07:51:37] <_skal_paris_> sorry for the noise
[07:51:44] <mru> I think I'll start calling variables true and false to fuck with those who #define those names
[07:51:46] <Dark_Shikari> mru: I agree
[07:51:53] <Dark_Shikari> but once you get through 3 loop counter
[07:51:54] <Dark_Shikari> *counters
[07:51:57] <Dark_Shikari> i, j, k...
[07:52:06] <mru> you _could_ skip to m
[07:52:14] <av500> there is always i4_i
[07:52:19] <Dark_Shikari> but where's the fun in that
[07:52:24] <mru> av500: an i 4 an i?
[07:52:43] <Dark_Shikari> ha ha
[07:52:45] <mru> Dark_Shikari: a = (b + l) >> 1;
[07:52:48] <mru> debug that!
[07:53:09] <Dark_Shikari> ha ha
[07:53:14] <av500> a = O * b;
[07:53:33] <av500> now hope gcc does not misread and optimize that away
[07:53:36] <mru> av500: gcc does a = 0 * b a lot
[07:53:44] <mru> and then compares it to zero just to be sure
[07:54:19] <av500> multiple stores to the same register for extra safety?
[07:55:03] <kshishkov> av500: I've checked Landau (Pfalz) this Saturday
[07:55:15] <efriedma> Dark_Shikari: http://pastebin.org/440661
[07:55:31] <av500> kshishkov: there is a joke in there, you know that?
[07:55:40] <efriedma> on parkjoy
[07:55:41] <Dark_Shikari> what are the 4 different runs?
[07:55:47] <Dark_Shikari> oh I see
[07:55:54] <Dark_Shikari> patcha is the latest right?
[07:56:09] <kshishkov> av500: no. It's just some German guy talked about zoos last week so I went to check theirs
[07:56:10] <efriedma> no, the first patch you gave me
[07:56:13] <Dark_Shikari> oh.
[07:56:16] <efriedma> patchnew is the latest
[07:56:17] <Dark_Shikari> I wanted to test the most recent patch.
[07:56:19] <Dark_Shikari> oh
[07:57:56] <Dark_Shikari> now I can't figure out what I prefer :/
[07:59:12] <Dark_Shikari> Yuvi: thoughts?
[08:00:57] <Yuvi> I don't really like needing to fool gcc into addressing multidensionial arrays correctly
[08:01:26] <Dark_Shikari> yeah, it's ugly
[08:01:34] <mru> I don't really like multidimensional arrays
[08:01:36] <Dark_Shikari> but I don't like all the addressing logic that comes from [11]
[08:01:57] <mru> non-power-of-two dimensions are evil
[08:04:23] <Dark_Shikari> hence my patch.
[08:04:37] <Yuvi> I guess in this case it'd be okay since it is a significant hotspot
[08:05:38] <Yuvi> (btw libvpx does something similar to avoid multidimensional addressing)
[08:06:14] <mru> int (*foo[2][8])[4][16]
[08:06:23] <Dark_Shikari> and double the cache usage?
[08:06:32] <Yuvi> No
[08:06:34] <Dark_Shikari> for no gain whatsoever?
[08:06:41] <Dark_Shikari> I mean what mru said
[08:06:50] <Yuvi> Oh
[08:07:09] <Yuvi> Thought you were asking about libvpx again
[08:07:24] <Yuvi> For the first time that is
[08:07:49] <mru> Dark_Shikari: I didn't intend that to be used
[08:08:33] <mru> I guess it's conceivable to need a 2d array of pointers to 2d arrays though
[08:08:53] <Yuvi> Anyway, nigt
[08:09:23] <pJok> note to self: always disable the Beep device under windows
[08:09:51] <mru> in the good old days I'd simply remove the damn speaker
[08:12:16] <_skal_paris_> k, committing yesterday's intra patch
[08:12:27] <_skal_paris_> ok?
[08:12:28] <Dark_Shikari> er...
[08:12:28] <Dark_Shikari> no
[08:12:31] <Dark_Shikari> I rejected it!
[08:12:35] <_skal_paris_> ah
[08:12:40] <Dark_Shikari> waiting one day does not make it less rejected
[08:13:09] <_skal_paris_> reading mail helps, too
[08:13:23] <_skal_paris_> hmm...
[08:13:27] <_skal_paris_> i still don't get it
[08:13:35] <_skal_paris_> the inter code is unchanged
[08:13:48] <_skal_paris_> not in storage, not in behaviour, nothing
[08:13:59] <_skal_paris_> Dark: care to explain (again) ?
[08:15:04] <Dark_Shikari> er, since when?
[08:15:22] <Dark_Shikari> link it again
[08:15:31] <_skal_paris_> k
[08:16:49] <_skal_paris_> http://pastebin.org/440689
[08:20:18] <Dark_Shikari> one moment
[08:21:13] <_skal_paris_> am out for coffee... back in a bit
[08:27:01] <Dark_Shikari> _skal_paris_:
[08:28:08] <Dark_Shikari> hmm, you're right
[08:28:26] <Dark_Shikari> ok, I see how this works
[08:29:13] <Dark_Shikari> patch approved
[08:46:09] <mru> WTF swscale!
[08:46:21] <mru> look at swscale.c line 1083
[08:48:12] <mru> oh, not quite as wtf, missed some parens
[08:51:47] * kshishkov though somebody has vowed not to touch swscaler
[08:51:58] <kshishkov> *thought
[08:52:10] <mru> I have to look when there's an unaligned pointer there
[09:33:07] <lu_zero> good morning
[09:34:22] <kshishkov> not especially good but it'll pass
[09:35:49] <lu_zero> kshishkov: still quite morning
[09:40:43] <_skal_paris_> back
[09:40:51] <_skal_paris_> Dark: k, committing
[09:45:46] <CIA-92> ffmpeg: skal * r24664 /trunk/libavcodec/vp8.c:
[09:45:46] <CIA-92> ffmpeg: only store intra prediction modes on the boundary for keyframes, not as a plane.
[09:45:46] <CIA-92> ffmpeg: inter-frame behaviour unchanged.
[11:41:50] <DonDiego> moin
[11:41:51] <DonDiego> say
[11:42:09] <DonDiego> what are the chances of libavutil/x86_cpu.h becoming an installed header?
[11:42:17] * DonDiego guesses 0
[11:53:06] <KotH> DonDiego: if you can calculate its exact improbability, you could feed that into an finite improbabilty generator, give it a coup of tea and be done with it ;)
[11:56:29] <av500> KotH: and then grow a 2nd head?
[11:57:43] <CIA-92> ffmpeg: stefano * r24665 /trunk/tests/ (3 files in 2 dirs):
[11:57:43] <CIA-92> ffmpeg: Sort lavfi pixdesc tests.
[11:57:43] <CIA-92> ffmpeg: Increase readability and robustness, as the test result is not going
[11:57:43] <CIA-92> ffmpeg: to differ if the order of the pixfmts codes changes.
[12:13:55] * mru wonders what diego wants with that header
[12:18:42] * kshishkov suspects it may be for MPlayer
[12:19:07] * kshishkov also suspect that if it is so, that means MPlayer is broken
[12:19:14] <thresh> mplayer is notorious for using uninstalled headers
[12:19:22] <av500> then it should come with libavstrangecpusupport
[12:19:24] <mru> that header can never be installed
[12:19:31] <mru> it uses compiler-specific tests
[12:19:46] <thresh> that is one of the reasons package maintainers usually build mplayer with in-tree ffmpeg
[12:26:51] <kshishkov> why nobody has thought about installing full configured and compiled FFmpeg to /usr/include special for MPlayer (so they can use #include <libautil/integer.o> as well)?
[12:28:00] <mru> kshishkov: they can, it's called -lavutil
[12:41:51] <Compn> kshishkov : diego is working on a full ffmpeg import to mplayer
[12:42:03] <Compn> uau's repo already has it for a long time now
[12:42:05] <mru> what does that mean?
[12:42:22] <Compn> importing all ffmpeg/ , building ffmpeg, then building mplayer
[12:42:33] <mru> what's the point?
[12:42:42] <Compn> possibly installing both at the same time
[12:42:46] <mru> why not link to whatever ffmpeg is available like any responsible person would do
[12:43:20] <Compn> i think thats already done
[12:43:55] <Compn> since mplayer already imports avcodec/avformat/avutil, this just means one svn external (ffmpeg) instead of 3
[12:44:08] <mru> why not make it zero?
[12:44:22] <kshishkov> yes, FFplay2 FTW
[12:44:44] <Compn> how do you expect mplayer to build if there is no system ffmpeg ?
[12:44:56] <mru> by the user installing ffmpeg first of course
[12:44:58] <janneg> Compn: does it resolve the recurse libswscale svn external
[12:45:12] <Compn> janneg : i dont think anything will fix that
[12:45:20] <mru> moving to git will
[12:45:30] <thresh> svn:externals are evil, mmkay
[12:45:44] <mru> evil doesn't begin to describe them
[12:46:08] <janneg> Compn: does the source tree end with 2 libswscales?
[12:47:25] <Compn> janneg : i dont know
[12:47:31] <Compn> check uau's repo
[12:47:33] <Compn> ;p
[12:54:07] <pross-au> kshishkov: ffplayer, mate.
[12:54:23] <mru> ffmplay
[12:54:40] <pross-au> Fucking Fast Mru Player?
[12:55:35] <spaam> \o/
[12:59:37] <kshishkov> that one will go with a title of "Yet Another"
[13:17:05] <Compn> if you talk about DonDiego long enough, he will show up :)
[13:17:18] <DonDiego> sup?
[13:17:35] <Compn> the ffmpeg team was just questioning the idea to include all of ffmpeg/ in mplayer tree
[13:17:57] <Compn> nothing important tho
[13:18:23] <DonDiego> why questioning the idea?
[13:18:46] <mru> yes, why question it? why not drop it without further thought?
[13:19:40] <DonDiego> propose that to the others
[13:19:49] <mru> which others?
[13:19:50] <DonDiego> i'm starting to like the idea myself..
[13:19:53] <DonDiego> other devs
[13:20:07] <mru> I thought the dark ages of library bundling were finally over
[13:20:08] <Honoome> lu_zero: what about dropping ffmpeg from mplayer? :P
[13:20:30] <Honoome> mru: you want me to look up how many libavcodec copies I got in the tinderbox?
[13:20:32] <DonDiego> while we are on the subject: what are the chances of libavutil/x86_cpu.h and libavformat/riff.h becoming installed headers?
[13:20:44] <mru> zero
[13:20:49] <Compn> riff? why riff ?
[13:20:55] <mru> riff raff
[13:21:49] <DonDiego> mru: i'm working on getting rid of bundled library copies, but every time i want to drop one, somebody finds an obscure fringe feature only available in the local copy and then trolls for long enough about feature removals that you just give up the idea..
[13:21:57] <elenril> DonDiego: why don't you cherrypick ffmpeg changes from uau's fork?
[13:22:13] <DonDiego> Compn: riff.h is used by the libavformat demuxer
[13:22:20] <DonDiego> mru: why 0?
[13:22:22] <DonDiego> elenril: ?
[13:22:31] <mru> DonDiego: becuase x86_reg.h depends on the compiler
[13:22:45] <elenril> DonDiego: it doesn't require ffmpeg sources at all
[13:22:57] <elenril> or maybe for some filters that are disabled by default
[13:23:20] <Compn> elenril : you know the choice to require ffmpeg internals was done on purpose right?
[13:23:47] <elenril> Compn: orly
[13:24:15] <Compn> elenril : any interesting thing people do with mplayer that doesnt have ffmpeg stuff?
[13:24:24] <Compn> binary codecs to raw or something?
[13:26:12] <elenril> then whoever made that choice should be trolled until he fixes it
[13:26:30] <DonDiego> elenril: that's because uoti copied some ffmpeg private headers into the ffmpeg_headers directory
[13:26:49] <DonDiego> i think we should copy x86_cpu.h to mplayer as well
[13:27:35] <DonDiego> mru: because it depends on definitions set in config.h?
[13:27:41] <DonDiego> and what about riff.h?
[13:27:48] <Compn> elenril : iirc, reimar used internal ffmpeg functions to eliminate a bunch of duplicated code, or external library dependencies like libjpeg
[13:28:05] * Compn goes afk
[13:28:14] <lu_zero> 15:20 < Honoome> lu_zero: what about dropping ffmpeg from mplayer? :P
[13:28:18] <lu_zero> uhmm
[13:28:26] <lu_zero> right now I have in my media-todo
[13:28:31] <lu_zero> snapshot ffmpeg
[13:28:40] <lu_zero> snapshot libvpx + fixes
[13:28:48] <lu_zero> mess with mplayer
[13:28:58] <mru> mplayer is already a mess
[13:29:18] <lu_zero> mru: a wonderful mess if you look at it from far away
[13:31:14] <lu_zero> uhm
[13:31:19] <lu_zero> regarding x86_cpu.h
[13:31:21] <lu_zero> I see
[13:31:26] <lu_zero> macro to define regs
[13:31:38] <lu_zero> that change between arches
[13:33:22] <DonDiego> i guess copying it will be the easiest solution
[13:33:34] <DonDiego> it is a useful layer of indirection apparently
[13:33:56] <lu_zero> and some defines that might or might not be useful or used
[13:34:07] <lu_zero> how are we using that btw?
[13:35:32] <DonDiego> we use
[13:35:41] <DonDiego> #include "libavutil/x86_cpu.h"
[13:35:46] <DonDiego> *surprise* ;)
[13:36:07] <BBB> wbs: nice catch
[13:36:14] <BBB> hi spyfeng
[13:36:37] <lu_zero> hi BBB
[13:37:10] <BBB> hi
[13:37:13] <BBB> hi *
[13:37:14] <BBB> :-p
[13:38:13] <lu_zero> ^^
[13:38:29] <lu_zero> how's going the x264-vp8 plan?
[13:51:58] <mru> trolling a long I hope...
[13:52:20] <av500> [21:04] <Dark_Shikari> If it happens, --vp8 will be a runtime option
[13:52:28] <av500> [21:04] <Dark_Shikari> which means you won't be able to distribute x264-vp8 without x264
[13:52:36] <av500> [21:04] <Dark_Shikari> creating large amounts of OMG PATENTS drama.
[13:53:01] <merbzt> we like drama
[13:53:57] <peloverde> good morning
[13:55:12] <thresh> moroning
[14:00:27] <BBB> lu_zero: I'm finishing some small stuff on ffvp8dec
[14:00:33] <BBB> then I'll start x264--vp8
[14:00:39] <BBB> it'll be so much fun
[14:00:57] <BBB> actually, Dark_Shikari already started it
[14:01:21] <DonDiego> please don't skip speeding up ffvp8..
[14:01:40] <BBB> that's why I'm holding off on x264--vp8
[14:01:48] <BBB> I want to finish my plans for ffvp8 ops before I move to something new
[14:01:52] <BBB> I have a few left
[14:02:08] <BBB> but don't worry, we already outperform libvpx on all x86 archs
[14:03:47] <lu_zero> =)
[14:04:57] <cartman> what is x364--vp8 ?
[14:05:01] <cartman> 264*
[14:06:36] <mru> it's the troll of the century
[14:10:40] <cartman> guessed so
[14:10:40] <BBB> cartman: it's a surprise
[14:10:41] <cartman> :)
[14:10:54] <cartman> its like vorbisified mp3
[14:11:00] <BBB> it's this franksteinish monster that we're doing
[14:11:04] <BBB> that's all we can say for now
[14:11:16] <cartman> a new vp8 bitstream spec?
[14:11:21] <BBB> you'll see :-p
[14:11:26] <cartman> hmmmpf
[14:11:36] * cartman goes back to embedding vlc
[14:13:26] * KotH ties cartman to the channel wall, with heavy, but rusty iron chains
[14:13:44] <cartman> KotH: man it works better than my lame libavcodec wrapper :D
[14:14:35] <KotH> what do you want to encode? your baris manco collection? :)
[14:15:50] <cartman> KotH: ah, my company needs a video player, so I am writing one (pretending to be writing one, as I just embed VLC or wrap ffmpeg,...)
[14:16:50] <DonDiego> cartman: don't forget about the license requirements please
[14:17:16] <cartman> DonDiego: with ffmpeg its easy (don't use --enable-gpl)
[14:17:25] <cartman> I need to compile vlc myself
[14:17:29] <DonDiego> that's not all there is to it..
[14:17:30] <cartman> it happily includes GPL modules
[14:17:50] <cartman> provide ffmpeg source code too? :)
[14:17:57] <cartman> since I am not modifying it
[14:18:07] <DonDiego> geez
[14:18:17] <cartman> Licensing 101 by DonDiego
[14:18:17] <DonDiego> why does *nobody* have a fucking clue?
[14:18:19] * cartman listens
[14:18:30] <DonDiego> don't listen, read..
[14:18:44] <DonDiego> your doing this for work, not for fun..
[14:19:05] <cartman> yeah since we are not doing public distribution I am exempt from all the licensing crap
[14:19:08] <cartman> for now
[14:19:11] <DonDiego> i'll translate the gpl and lgpl into a single sentence for you:
[14:19:18] <DonDiego> GPL: provide all the source
[14:19:29] <DonDiego> LGPL: provide all the source of the LGPL part(s)
[14:19:49] <DonDiego> the problem is that people think that it cannot be this simple and start inventing exceptions
[14:20:08] <DonDiego> "but i'm not modifying it" is the most common one
[14:20:17] <DonDiego> and it's complete bs of course
[14:20:27] <DonDiego> let me rephrase a bit more explicitly
[14:20:41] <DonDiego> GPL: you must provide all the source
[14:20:51] <DonDiego> LGPL: you must provide all the source of the LGPL part(s)
[14:21:01] <DonDiego> next up is trying to work around "you"
[14:21:15] <DonDiego> "but somebody else is already doing it" people say
[14:21:40] <DonDiego> unfortunately that does not change the basic fact that you != them
[14:21:43] <DonDiego> capisce?
[14:21:55] <cartman> giving out source for LGPL parts is easy and I know I have to do it
[14:21:59] * av500 offers to host cartman GPL files
[14:21:59] <cartman> thanks for reminding me anyway
[14:22:07] <DonDiego> cartman: and now go read the license top to bottom please
[14:22:13] <DonDiego> both of them
[14:22:14] <DonDiego> thx
[14:22:22] * cartman mumbles
[14:23:10] <av500> DonDiego: he is "commercial", you can send the invoice now :)
[14:23:18] * DonDiego is tempted...
[14:23:41] <DonDiego> a gave an "introduction to FOSS licensing" talk the other day
[14:24:07] <DonDiego> do you guys know anybody who might be interested in hiring me to give it to them?
[14:24:08] <DonDiego> :)
[14:28:31] <BBB> you should go to law school
[14:28:34] <BBB> then everyone will hire you
[14:29:48] <BBB> is anyone interested in helping this poor umakant guy on libav-user?
[14:29:59] <jai> ?
[14:29:59] <BBB> he wants to pay for having someone show him how to use the encoding API
[14:30:20] <jai> heh
[14:30:21] <BBB> this should trigger $$$bill$igns in everyone who's on consulting.html
[14:30:56] * jai doesnt read libav-user
[14:31:12] * mru does not work for less than $10k
[14:31:20] <av500> I can sell him my demo code for $1k
[14:31:37] <mru> in general
[14:31:47] <BBB> mru: send him an email, ask for $10k, see wha the says
[14:55:35] <KotH> does anyone here have experience with coldfire chips?
[14:55:55] <mru> sounds a bit 1993
[14:56:32] <KotH> well, they seem to be updated versions of 68k's... riscified and such
[14:56:53] <mru> yes
[14:57:12] <mru> 68k is kinda 1984
[14:57:13] * KotH ponders using one of those in a private project
[14:57:25] <mru> why?
[14:57:26] <KotH> the specs are nice (better than any atmel chip for the same money)
[14:57:28] <mru> why not arm?
[14:57:58] <KotH> do you know a nice chip with 32bit timers (at least 2), usb and ethernet?
[14:58:06] * cartman hands KotH his right arm
[14:58:12] <KotH> and it should be <15usd at single pieces
[14:58:31] <KotH> cartman: what shall i do with it, it's pretty much usless w/o a body to attach it to ;)
[14:58:42] <av500> KotH: you have no body?
[14:58:45] <cartman> use the ARM :P
[14:58:53] <cartman> its a coding arm ;=
[14:59:03] <KotH> av500: i'm not BeebleKotH
[14:59:33] <cartman> ok times up
[14:59:35] <cartman> see you
[15:08:24] <KotH> mru: what other companies have cortex-m3s beside atmel, nxp and st?
[15:08:53] <mru> there's piles of them in the omap4 :-)
[15:09:03] <KotH> oh.. right.. ti
[15:19:33] <KotH> mru: hmm.. dunno.. the only ti chips that go into the region that i'd like to are teh stelaris 9000s, but those are kind of hard to get ^^'
[15:19:57] <mru> what is your application?
[15:22:33] <KotH> a gpsdo :)
[15:22:41] <av500> do?
[15:22:49] <KotH> disciplined oscillator
[15:23:04] <av500> it comes with a cane?
[15:23:07] <KotH> mru: though, i must say that the specs of the stellaris 9ks are nice
[15:24:28] <av500> of course, TI only bought them recently
[15:24:37] <av500> no time yet to mess them up :)
[15:27:19] <KotH> from whom?
[15:27:59] <av500> from luminary micro
[15:34:25] <KotH> hmm.. actually they dont look bad... but nobody has them on stock ^^;
[15:38:33] <peloverde> janneg: pong
[15:43:20] <janneg> peloverde: hi, that was just latm patch posted ping
[15:43:52] <peloverde> ok, I sent some thoughts
[15:52:18] <KotH> fuck.. the larger stellaris chips are cool! ethernet phy integrated, all usb resistors integrated...
[15:56:25] <lu_zero> 16:30 <@BBB> this should trigger $$$bill$igns in everyone who's on
[15:56:41] <lu_zero> I doubt that would get much money ^^;
[15:57:10] <mru> I don't even talk to such people
[15:57:45] <lu_zero> KotH: stellaris?
[15:58:01] <KotH> lu_zero: ti stellaris, cortex-m3 uC
[15:58:31] <KotH> lu_zero: fucking cool specs!
[15:58:41] <lu_zero> really?
[15:58:56] <KotH> price seems to be ok (<20usd/piece), but nobody has them on stock
[15:59:01] <lu_zero> from my experience with freescale they have nice hardware, just wait one revision more
[15:59:18] <lu_zero> they are working as well?
[15:59:25] <KotH> dont know
[15:59:47] <KotH> the msp430s that we use work quite well, havent found any major bug in them, and afaik not even a minor one
[16:00:00] <lu_zero> KotH: as I said
[16:00:10] <KotH> (unlike the atmel chips we use)
[16:00:19] <lu_zero> you need to wait the revision+1 and they got really fine
[16:01:55] <lu_zero> (imx51 is really interesting as chip, the current bugless one)
[16:02:16] <lu_zero> (the imx53 looks like really great, will be with the revision following the release one)
[16:03:08] <av500> lu_zero: http://www.flickr.com/photos/av500/4837059578/
[16:03:40] <KotH> lu_zero: well... i dont trust any uC/uP to be bugfree
[16:03:53] <KotH> lu_zero: i've seen too many very stupid mistakes
[16:04:40] <KotH> well.. lets see what the local ti sales says to my inquiry
[16:05:07] <KotH> s/sales/field app eng/
[16:08:38] <lu_zero> av500: aaaargh
[16:09:28] <lu_zero> http://www.flickr.com/photos/av500/4849718893/in/photostream/ <- pumpkin?
[16:09:56] <lu_zero> is it yours?
[16:10:47] <lu_zero> DonDiego: icecream hunt?
[16:11:32] <DonDiego> hmm
[16:11:43] * DonDiego is not particularly hungry
[16:11:51] * DonDiego won't complain either..
[16:12:13] <Honoome> damn you guys >_<
[16:12:19] * Honoome is home doing accounting =_=
[16:12:33] <Honoome> and waiting for the customer to tell me whether I'm cleared of duty or not...
[16:13:12] <KotH> Honoome: working in accounting is a very bad choice for a career
[16:13:19] <KotH> Honoome: only engineering is worse ;)
[16:13:19] <lu_zero> which customer?
[16:13:25] <Honoome> lu_zero: that customer
[16:13:34] <Honoome> KotH: not working in accounting.. doing accounting :|
[16:13:39] <lu_zero> you have _many_ customers
[16:13:45] <lu_zero> that are _that_ way
[16:14:02] * Honoome is self-employed, so has to take care of his own bills and crap =_=
[16:14:25] <lu_zero> Honoome: we are telling to join us =P
[16:14:37] <KotH> Honoome: how many employees?
[16:14:44] <Honoome> KotH: myself :P
[16:14:48] <lu_zero> then you'll have to take care for the error the beautiful small secretary would do ^^
[16:14:50] <KotH> Honoome: you should expand ;)
[16:15:01] <Honoome> in another country, sure
[16:15:16] <av500> lu_zero: neighbours, growing into our side of the fence
[16:15:30] <Honoome> lu_zero: I did already a mistake... and paid (€1) for it...
[16:15:38] <lu_zero> uh
[16:16:22] * lu_zero is thirsty
[16:16:37] <Honoome> put the ex-VAT amount on the wire for the (tax) accountant
[16:17:24] <lu_zero> o_O
[16:21:28] <janneg> peloverde: do you have a good idea how I could use the audio config stuff from the decoder?
[16:23:17] <peloverde> IF you are talking about program_config_element, use ff_copy_pce_data from mpeg4audio.c
[16:23:41] <wbs> if that's in lavc, it needs to be made public with an av_ prefix
[16:24:38] <peloverde> Why, it's still not user-public, it just changes from lavc only to ffmpeg-internal
[16:26:04] <wbs> yes, but if you have shared libraries of them, they still rely on private symbols from the other shared library, and we can't change the nonpublic symbols without breaking ABI between the libraries
[16:26:12] <wbs> if you e.g. upgrade lavc.so but not lavf.so
[16:27:58] <peloverde> yes, that is true
[16:28:23] <peloverde> but current convention still uses the ff_ prefix for those type symbols
[16:29:28] <wbs> afaik, there's a few ff_-prefixed symbols used by lavf from lavc, but adding more use of them is discouraged and you should rather make it a public symbol before doing that
[16:29:52] <wbs> otherwise, you'd not necessarily know that it actually is an externally used function, and changing it may break things
[16:30:05] <peloverde> but those symbols aren't public, their behavior is allowed to change in ways that don' break lavf
[16:30:15] <peloverde> it is a bug if third party apps use them directly
[16:30:34] <wbs> yes, but you'd still need to keep track of not breaking other versions of lavf using the symbol
[16:30:35] <peloverde> they just have public linkage
[16:33:01] <peloverde> yes, that is why changing them at all without a bump is discouraged
[16:33:41] <peloverde> all the symbols in mpeg4audio.c are used by lavf
[16:33:44] <peloverde> none of them are ff_
[16:33:51] <peloverde> err all of them are ff_
[16:34:59] <wbs> yeah, there are quite a few such cases around
[16:35:29] <wbs> despite that, I'd say it would be better to convert them to proper external symbols, if feasible
[16:35:38] <peloverde> if it bothers you so much, send a patch to rename them
[16:36:55] <wbs> strictly speaking, we can't even rename them without keeping the old name around until the next bump, but it doesn't bother me enough to send a patch
[16:37:13] <wbs> I removed a few such ones earlier at least
[16:37:33] <peloverde> then stop complaining
[16:38:13] <peloverde> It seems like new functionality is always put on hold to bikeshed current policies or code quality of already existing code
[16:38:33] <DonDiego> can we please add -Wno-parentheses to CFLAGS now?
[16:38:51] <peloverde> +1
[16:39:04] <mru> btw, did anyone notice how there was no bikeshedding about the new fate?
[16:39:22] <DonDiego> either that or add the missing parentheses to kill the corresponding warnings..
[16:39:44] <wbs> don't let me stop you from doing actual progress, I just wanted to remind you about binary compatibility issues
[16:40:00] <peloverde> That particular symbol is already used by libavformat
[16:40:04] <janneg> peloverde: no, the whole AudioSpecificConfig. ff_copy_pce_data doesn't help, since I still need to parse it to get the channel configuration
[16:40:26] <janneg> but I'll use it unbreak the bitstream parsing
[16:40:36] <DonDiego> mru: you ok with adding the flag?
[16:40:51] <mru> I don't mind
[16:42:40] <DonDiego> ok, i will add it then
[17:10:45] <CIA-92> ffmpeg: diego * r24666 /trunk/configure:
[17:10:45] <CIA-92> ffmpeg: Add -Wno-parentheses to CFLAGS.
[17:10:45] <CIA-92> ffmpeg: Without this flag -Wall generates warnings that nobody wants to see fixed or
[17:10:45] <CIA-92> ffmpeg: worked around. Disabling those warnings is thus the best solution.
[17:11:52] <jai> hmm iirc i wrote a patch for that and no-one commented on that
[17:12:23] <av500> jai: did you mark it with <bikeshed>?
[17:13:07] <jai> av500: no :)
[17:13:29] <av500> see
[17:16:06] <jai> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/114093/match=warning+jai+menon
[17:16:14] <jai> av500: ^ that was it
[17:16:26] <jai> hmm, gmane is nice
[17:37:33] <peloverde> janneg: what info do you need?
[17:46:22] <janneg> peloverde: I thought I need sample rate and no of channels but apparently I don't need them
[17:46:52] <peloverde> The sample rate in the PCE should be ignored
[17:47:14] <peloverde> if it is set anywhere else
[17:47:33] <peloverde> but i guess you werent talking about the pce
[17:47:49] <janneg> no about the whole audio config
[17:47:58] <mru> anyone here keeping track of llvm development?
[17:48:05] <peloverde> somewhat
[17:48:42] <mru> are you aware of any fix in sight for that mismatched types in inline asm error?
[17:48:53] <mru> which I still think is a broken way to write code
[17:49:04] <mru> but apparenly I don't understand the deep subtleties of x86
[17:49:27] <peloverde> I haven't seen any updates about that in quite some time, I think it fell by the wayside
[17:49:53] <mru> I tried searching their bugzilla but came up empty-handed
[17:56:39] <janneg> I need the sample rate as timebase for the pts
[18:03:56] <peloverde> copy the ASC then use the shared asc reading functions
[18:03:58] <peloverde> Did we ever do anything about this issue: http://www.sei.cmu.edu/reports/10tn008.pdf?
[18:04:07] <peloverde> or just read the value as you copy it
[18:09:07] <janneg> I need to parse it before copying since the length is in one case unknown otherwise
[18:12:07] <janneg> I won't change it now, it got better with the copy_bits from mpeg4audio.c
[18:38:39] * mru notes that DonDiego is still in .it
[18:49:05] <peloverde> OT: Is cygwin/X the best choice for X on win32 these days?
[18:50:37] <gk_> is there anything else?
[18:51:13] <elenril> there's xming
[18:51:30] <elenril> we have some proprietary thing on pcs at uni
[18:52:12] <Dark_Shikari> peloverde: why woudl you want X?
[18:52:32] <mru> why not?
[18:52:45] <Dark_Shikari> it's like saying "hmm, linux is great. let me import the shittiest thing from it onto windows!"
[18:52:50] <peloverde> I'm on my windows laptop SSH'd to my dev machine and I want to run gitk
[18:53:14] <mru> X is great
[18:54:20] <elenril> X is great << i don't hear that often
[18:54:26] <mru> X is great
[18:54:27] <mru> X is great
[18:54:27] <mru> X is great
[18:54:32] <elenril> \o/
[18:54:48] <mru> anyone who says otherwise has simply misunderstood it
[18:55:08] <mru> and/or never experienced proper network transparency
[18:56:43] <Dark_Shikari> I'm pretty sure that's the only good thing about X
[18:56:56] <mru> what do you dislike about it?
[18:57:10] <Dark_Shikari> every attempt to throw hardware acceleration onto it has been a hack
[18:57:15] <mru> lies
[18:57:21] <elenril> evil lies even
[18:57:33] <Dark_Shikari> which one wasn't?
[18:57:37] <mru> X has had hw acceleration for as long has hw has been accelerated
[19:04:25] <spaam> http://video.eu.debconf.org:8000/davis_auditorium.ogv then are going to talk about Debian gnu/hurd ;D
[19:04:46] <spaam> they.
[19:05:16] <Dark_Shikari> lol
[19:05:43] <mru> those projects deserve each other
[19:06:08] <Dark_Shikari> Did you hear? Hurd will replace Linux!
[19:06:37] <elenril> will it be even more freeer?
[19:12:02] <cartman> Dark_Shikari: wth is x264--vp8 thing?
[19:12:59] <mru> xvp8
[19:16:31] <mmu_man> HD over HDMI ?
[19:16:37] <mmu_man> doesn't it require HDCP ?*
[19:16:45] <mru> of course not
[19:17:14] <mmu_man> ah
[19:17:16] <mru> an hdmi sink never mandates hdcp
[19:17:58] <mmu_man> oh well
[19:18:21] <mmu_man> it's painful seeing all those ARM devboards with only HDMI output
[19:18:29] <mmu_man> I don't want to support this crap
[19:18:33] <mru> uh why?
[19:18:40] <mru> it's only a connector
[19:18:51] <mmu_man> sadly it seems HDBaseT is going the same route of "allowing HDCP"
[19:18:55] <mru> did you take a drink from the fsf?
[19:19:14] <mmu_man> no, where ? :p
[19:19:25] <mru> their freedom koolaid
[19:19:37] <mru> the link specification doesn't care what encryptions you put on top
[19:19:37] <mmu_man> no it's a connector with signaling descriptions, and provisions for DRM
[19:19:39] <mmu_man> which sux
[19:19:50] <mru> you can encrypt on top of any link
[19:19:54] <mru> the link doesn't caare
[19:19:55] <mru> -a
[19:20:02] <Kovensky> crm0391fndposajv093rqunf <-- encrypted text
[19:20:04] <Kovensky> prove me wrong
[19:20:33] <spaam> that does say "mru is my idol"
[19:20:56] <mmu_man> still there is a difference between "any link" and a link which specifically allows it in the specs
[19:20:58] <Kovensky> no, it actually said "keyboard mashing"
[19:21:20] <mru> I find it very difficult to carae
[19:21:21] <mru> -a
[19:21:23] <mmu_man> no it's just your cat rolling over the keyboard :p
[19:21:40] <j0sh> wbs, it's always the one-line fixes...
[19:21:44] <mmu_man> well, I do care about ethics :p
[19:21:53] <mru> so ssl is unethical too now?
[19:21:54] <Kovensky> in b4 mmu_man hates matroska because it supports encryption
[19:22:02] <mru> hdcp is no more evil than ssl
[19:22:05] <mmu_man> it does ?
[19:22:38] <mru> and http is thus evil since it explicitly allows encryption
[19:22:38] <mmu_man> it doesn't have the same purpose, even if both can be used for many things
[19:22:39] <Kovensky> yes
[19:22:53] <mru> hdcp is just a link encryption, nothing more
[19:23:17] <mmu_man> except it's not made to protect the user but to protect against the user
[19:23:18] <mmu_man> anyway
[19:23:33] <Dark_Shikari> cartman: a troll
[19:23:38] <Dark_Shikari> (which doesn't mean it isn't real)
[19:23:39] <mru> mmu_man: not really
[19:23:39] <Kovensky> gpg --encrypt file.mkv
[19:23:43] <Kovensky> ???
[19:23:45] <Kovensky> PROFIT
[19:23:47] <mru> that's how it's often used
[19:23:50] <mmu_man> pff
[19:23:55] <cartman> Dark_Shikari: interesting
[19:24:05] <Dark_Shikari> yell at BBB to get working
[19:24:07] <Kovensky> altough it does have provisions for internal encryption
[19:24:16] <mru> in principle, hdcp could be replaced by ssl
[19:24:26] <Kovensky> which just encrypts the payload, still allowing splitting and other manipulations
[19:24:53] <cartman> Dark_Shikari: vp8 as it is has no value
[19:25:42] <Kovensky> cartman: imagine: the best vp8 encoder that only works if coupled with the best H.264 encoder
[19:26:13] <cartman> Kovensky: best as in faster?
[19:26:22] <cartman> since the picture quality depends on other things
[19:27:05] <saintdev> like the phase of the moon?
[19:27:25] <cartman> cosmic rays saste
[19:27:30] <cartman> saintdev*
[19:27:50] <Kovensky> cartman: I'm pretty sure x264's psy-opts would be rather useful for vp8 too, except for the bframe and multiref stuff
[19:28:09] <Kovensky> altough I don't know much about vp8 so I should just go grab some coffee and resume my hacking
[19:28:39] * cartman agrees and goes back to poking vlc
[19:33:27] <Kovensky> durf, boost is still compiling
[19:35:51] <Dark_Shikari> if we wanted to be total dicks
[19:35:55] <Dark_Shikari> we could extend vp8 using x264
[19:36:03] <Dark_Shikari> and then add support to lavc's decoder for the extensions
[19:36:09] <Dark_Shikari> and see how long it takes for everyone to go nuts
[19:36:17] <Dark_Shikari> i.e. extend ---> add b-frames, for example
[19:36:18] <mru> that's evil
[19:36:24] <Dark_Shikari> Yes, that is extraordinarily evil.
[19:36:30] <iive> i like it.
[19:36:34] <mru> no
[19:36:41] <mru> at least call it VP8+ or something
[19:36:44] <Dark_Shikari> Yeah, I think it's too evil.
[19:36:46] <mru> VP864
[19:36:48] <Dark_Shikari> agreed, you'd have to give it a new name
[19:36:53] <Dark_Shikari> Or a new profile_idc
[19:37:07] <mru> we should not pull a microsoft
[19:37:24] <Dark_Shikari> FFVP8v2
[19:37:25] * Dark_Shikari ducks
[19:38:17] <Dark_Shikari> mru: can you bench my ML patches for vp8 on arm?
[19:38:35] <mru> I doubt there's any measurable difference without neon
[19:38:39] <mru> someone's working on that btw
[19:39:13] <Dark_Shikari> I mean with start/stop timer
[19:39:16] <Dark_Shikari> and yes I know
[19:39:31] <Dark_Shikari> is there no way to do a stop/start timer bench on arm?
[19:39:38] <mru> it's a bit tricky
[19:39:46] <Dark_Shikari> why is that?
[19:40:00] <mru> ask ARM
[19:40:15] <Dark_Shikari> but isn't there a timer instruction?
[19:40:23] <Dark_Shikari> iirc yuvi was using it
[19:40:38] <mru> yes, but you have to fiddle around a bit to enable the counter
[19:40:46] <mru> easy enough if you have my kernel patches
[19:40:51] <Dark_Shikari> yes, but you already did that
[19:40:53] <Dark_Shikari> so you should have no issue
[19:41:21] <mru> where does the timer go?
[19:41:51] <Dark_Shikari> around the decode_block_coeffs call under the comment "luma blocks"
[19:42:33] <mru> line number?
[19:42:50] <Dark_Shikari> depends on whether the patch is applied or not
[19:42:54] <Dark_Shikari> nnz = decode_block_coeffs(c, s->block[y][x], s->prob->token[luma_ctx], luma_start,
[19:42:57] <Dark_Shikari> nnz_pred, s->qmat[segment].luma_qmul);
[19:43:01] <Dark_Shikari> // nnz+luma_start may be one more than the actual last index, but we don't care
[19:43:04] <Dark_Shikari> around that
[19:43:17] <mru> ok
[19:43:25] <mru> what sample?
[19:44:55] <Dark_Shikari> http://x264.nl/developers/Dark_Shikari/force.php?file=./parkjoy.ivf
[19:45:06] <mru> ok have that already
[19:45:52] <CIA-92> ffmpeg: mru * r24667 /trunk/tests/lavfi-regression.sh:
[19:45:52] <CIA-92> ffmpeg: lavfi-regression: trim \r line ends from showfiltfmts output
[19:45:52] <CIA-92> ffmpeg: This is required when cross-testing on dos-like targets.
[19:45:59] <mru> and what do you want timed?
[19:46:15] <Dark_Shikari> decoding to null?
[19:46:21] <mru> no patch, patch1, and patch2?
[19:46:23] <Dark_Shikari> yes
[19:46:32] <Dark_Shikari> with enough runs to get an idea of stddev
[19:46:41] <Dark_Shikari> like, 2 or 3 runs each
[19:50:06] <mru> inside the loop?
[19:50:40] <Dark_Shikari> yes
[19:50:43] <Dark_Shikari> right around the call
[19:54:34] <bcoudurier> hi guys
[19:55:08] <Dark_Shikari> hi bcoudurier's onjoin script
[20:08:14] <Dark_Shikari> saintd3v: ping
[20:08:54] <saintdev> sup?
[20:10:58] <saintdev> Dark_Shikari: pong
[20:11:43] <Dark_Shikari> go to #celt
[20:19:05] <CIA-92> ffmpeg: darkshikari * r24668 /trunk/libavcodec/ (vp8dsp.c x86/vp8dsp.asm x86/vp8dsp-init.c vp8.c):
[20:19:05] <CIA-92> ffmpeg: VP8: move zeroing of luma DC block into the WHT
[20:19:05] <CIA-92> ffmpeg: Lets us do the zeroing in asm instead of C.
[20:19:05] <CIA-92> ffmpeg: Also makes it consistent with the way the regular iDCT code does it.
[20:21:38] <Dark_Shikari> mru: thanks
[20:21:44] <Dark_Shikari> interesting that ARM benefits so much from avoiding the load
[20:22:12] <mru> A9 would probably look different
[20:22:24] <mru> much better memory subsystem
[20:25:51] <Dark_Shikari> some vp8 stats
[20:25:52] <Dark_Shikari> http://pastebin.org/442273
[20:25:59] <Dark_Shikari> right: number of coefficients in the dc transform
[20:26:02] <Dark_Shikari> left: count
[20:28:27] <saintdev> peloverde: probably a little better discussion for here
[20:29:02] <peloverde> TNS also gives adaptive T/F resolution
[20:29:29] <peloverde> If you start breaking your work into patches and sending it, we can glue TNS into place
[20:29:32] <saintdev> peloverde: i can clean it up, and send it it in. i haven't really done enough testing to be confident in it yet, though.
[20:29:42] <saintdev> and i haven't really done _any_ listening tests yet
[20:30:19] <peloverde> I could break pieces off, but I'm afraid that would be more work for you, not less
[20:30:20] <Dark_Shikari> hmm. mru or others, question
[20:30:30] <Dark_Shikari> vp8_luma_dc_wht does a wht for the DC coefficients, like in h264
[20:30:37] <Dark_Shikari> What if we have a DC-only version of this function?
[20:30:42] <Dark_Shikari> would that be vp8_luma_dc_wht_dc ?
[20:30:43] <Dark_Shikari> lol
[20:30:47] <saintdev> peloverde: well the window decision right now exists as it's own patch
[20:31:23] <saintdev> the only issue i have is how to glue it into 3gpp, while still being able to use it with lame psymodel
[20:32:03] <saintdev> create wrapper functions that call lame_attact_detection() ?
[20:32:10] <peloverde> It is noless 3GPP window detection than kostya's, it just has a better tuned filter
[20:32:10] <mru> Dark_Shikari: the dc of the dc coeffs...
[20:32:15] <mru> hmm
[20:32:18] <peloverde> just replace the original
[20:32:46] <saintdev> but then it will expect it's private data to be in the 3gpp struct, not the lame one..
[20:32:47] <Dark_Shikari> mru: fyi, for the normal idct
[20:32:50] <Dark_Shikari> it's called vp8_idct_dc_add
[20:32:56] <Dark_Shikari> vs vp8_idct_add
[20:36:39] <CIA-92> ffmpeg: mru * r24669 /trunk/libavcodec/vorbis_dec.c: vorbisdec: change a uint_fast32_t to 'unsigned', fix llvm-gcc build
[20:40:03] <peloverde> It can be made to talk to both... or the structs can be combined, there is (was?) a lot of overlap
[20:40:43] <mru> hey look dos is better than bsd
[20:40:53] <Dark_Shikari> mru: it has log2f?
[20:40:59] <mru> it passes all the tests
[20:41:03] <mru> freebsd doesn't
[20:41:22] <mru> freebsdos
[20:41:33] * Kovensky pats his VM
[20:41:58] <mru> all bsds we test except net fail all vorbis tests
[20:42:01] <mru> spectacularly
[20:42:23] <Dark_Shikari> wow. gcc compiled my C code for luma_dc_wht_dc well enough that it's not worth writing asm.
[20:42:28] <saintdev> peloverde: http://pastebin.org/442325
[20:46:44] <peloverde> why was mp3x never ported to gtk2?
[20:57:54] <CIA-92> ffmpeg: darkshikari * r24670 /trunk/libavcodec/ (vp8dsp.c vp8dsp.h vp8.c):
[20:57:54] <CIA-92> ffmpeg: VP8: much faster DC transform handling
[20:57:54] <CIA-92> ffmpeg: A lot of the time the DC block is empty: don't do the WHT in this case.
[20:57:54] <CIA-92> ffmpeg: A lot of the rest of the time, there's only one coefficient: make a special
[20:57:54] <CIA-92> ffmpeg: DC-only transform for that case.
[20:57:55] <CIA-92> ffmpeg: When the block is empty, don't incorrectly mark luma DCT blocks as having DC
[20:57:56] <CIA-92> ffmpeg: coefficients.
[21:47:38] <Dark_Shikari> well, I have a new project
[21:47:43] <Dark_Shikari> make libavcodec, compiled with h264 decoding only, smaller
[21:48:11] <spaam> how big is it now?
[21:48:14] <Dark_Shikari> over a meg
[21:48:19] <Dark_Shikari> because a lot of stuff gets compiled unconditionally
[21:48:21] <Dark_Shikari> when it shouldn't
[21:49:43] <peloverde> Time spent fighting auto tools -- 20 minutes, remaining time spent porting mp3x to GTK+2 -- 5 minutes
[21:49:54] <Honoome> peloverde: you could have asked.. :P
[21:50:14] <peloverde> I have bigger changes planned
[21:52:31] <saintdev> aac?
[21:52:41] <peloverde> I'm thinking about it
[21:52:57] <saintdev> that would be pretty sweet
[21:53:45] <peloverde> It's either fix up my python tools port mp3x
[21:55:29] <Dark_Shikari> quick thought about small builds of libav*
[21:55:35] <Dark_Shikari> Any libavcodec compilation requires _all_ of libavutil
[21:55:40] <Dark_Shikari> even if not all of it is needed
[21:55:44] <Dark_Shikari> is there any resolution to that?
[21:55:58] <BBB> it's considered public API
[21:56:03] <Dark_Shikari> yes, I know
[21:56:03] <BBB> that's probably one of the reasons
[21:56:09] <Dark_Shikari> But is there any resolution to that?
[21:56:15] <Dark_Shikari> besides hacking it to pieces manually?
[21:56:38] <BBB> --disable-everything should disable everything, including avutil, and then h264dec should not depend on avutil, but only on those pieces that it actually needs in avutil
[21:56:43] <BBB> it probably depends on avutil now
[21:56:45] <BBB> (all of it)
[21:56:49] <Dark_Shikari> How would that even work?
[21:56:52] <Dark_Shikari> libavutil is a separate lib
[21:56:55] <Dark_Shikari> how can you link in only parts of it?
[21:56:57] <peloverde> There are some factors that I find annoying, how to best display 8 short windows
[21:57:06] <BBB> it'd only build a few parts
[21:57:27] <Dark_Shikari> hmm. well lavu is only 75k now
[21:57:37] <peloverde> I'm wondering if I'm better of rewriting it in pylab
[21:58:02] <Dark_Shikari> Why is audioconvert.o compiled if --disable-everything is used?
[21:59:19] <Dark_Shikari> is there a CONFIG for encoders?
[21:59:26] <BBB> yes
[21:59:29] <Dark_Shikari> what is it?
[21:59:32] <BBB> CONFIG_ENCODERS :-p
[21:59:37] <Dark_Shikari> #if or #ifdef?
[21:59:38] <BBB> or at least it used to be ages ago
[21:59:41] <peloverde> Yes pick on audio when the video is generally just as bad if not worse for such things
[21:59:58] <Dark_Shikari> I'm going alphabetically
[22:00:05] <BBB> #if
[22:00:27] <peloverde> I cant wait until you get to d
[22:00:35] <Dark_Shikari> dsputil is where I am now
[22:00:40] <Dark_Shikari> and yes I know
[22:00:50] <peloverde> good luck :)
[22:01:48] <peloverde> saintdev: You don't have any philosophical objections to python, do you?
[22:01:52] <Dark_Shikari> ugh. so many of the dsputil functions are used by a billion different things
[22:02:02] <Dark_Shikari> so it's almost impossible to go figure out how to disable them
[22:02:13] <saintdev> peloverde: it insulted my sister once, but other than that, no.
[22:03:14] <peloverde> ok, because after looking at mp3x internals, I think writing an mp3x inspired tool in python is the best approach (plus I've already started it)
[22:03:44] <BBB> dsputil should be split, largely
[22:05:11] <peloverde> For now it's going to require the refdec but at some point I hope to add some analysis code to lavc
[22:05:50] <_skal_paris_> http://pastebin.org/441818
[22:05:52] <Dark_Shikari> Should I put ifdefs around static function declarations in dsputil, or just them being loaded?
[22:05:54] <_skal_paris_> that's boring
[22:06:01] <Dark_Shikari> latter will create warnings
[22:06:02] <_skal_paris_> i'm gonna forget about this one
[22:07:41] <mru> BBB: splitting dsputil is one of my ongoing projects
[22:07:54] <BBB> ooo
[22:07:54] <Dark_Shikari> mru: my boss asked me to make libavcodec smaller
[22:07:55] <BBB> cool
[22:08:01] <Dark_Shikari> should I actually try to submit a patch for dsputil to ifdef it all?
[22:08:06] <mru> no
[22:08:10] <Dark_Shikari> what should I do?
[22:08:14] <mru> that's not the right solution
[22:08:27] <Dark_Shikari> Should I hack libavcodec apart just for us?
[22:08:41] <mru> how soon do you need it?
[22:08:42] <Dark_Shikari> This is a relatively short-term demand.
[22:08:51] <Dark_Shikari> It's not really NEEDED short-term
[22:08:56] <Dark_Shikari> but...
[22:09:38] <mru> you could try playing with -ffunction-sections and -Wl,--gc-sections
[22:09:45] <Dark_Shikari> ?
[22:09:45] <mru> or whatever it's called
[22:09:52] <Dark_Shikari> how would that fix autoloaded dsp functions that are never used?
[22:10:01] <mru> guess it wouldn't
[22:10:14] <Dark_Shikari> 1.1M libavcodec/x86/dsputil_mmx.o
[22:10:17] <Dark_Shikari> HOLY FUCK
[22:10:21] <mru> that's mostly debug info
[22:10:27] <Dark_Shikari> oh, wait, I forgot to strip those
[22:10:42] <Dark_Shikari> no, my point stands
[22:10:44] <Dark_Shikari> 468K libavcodec/x86/dsputil_mmx.o
[22:10:45] <Dark_Shikari> HOLY FUCK
[22:10:57] <mru> what does the 'size' command say?
[22:11:08] <Dark_Shikari> text data bss dec hex filename
[22:11:09] <Dark_Shikari> 362736 0 4 362740 588f4 libavcodec/x86/dsputil_mmx.o
[22:11:19] <Dark_Shikari> that's over 2x larger than C dsputil
[22:18:25] <Compn> Dark_Shikari : --enable-small ?
[22:18:27] <mru> that file has way too much junk in it
[22:18:31] <mru> Compn: lol
[22:18:34] <Compn> hehe
[22:20:46] <Dark_Shikari> won't help
[22:22:14] <lu_zero> which are the functions you aren't using?
[22:22:32] <lu_zero> btw
[22:22:46] <lu_zero> what about upx for something really short term ^^?
[22:25:20] <peloverde> BBB: http://code.google.com/p/chromium/issues/detail?id=50811
[22:26:13] <BBB> Dark_Shikari: you could always change the if (codec_id == ...) to if (CONFIG_..._DECODER && codec_id == ..)
[22:26:22] <BBB> Dark_Shikari: that should disable the autoloading for at least some functions
[22:27:49] <BBB> peloverde: cool
[22:32:56] <Dark_Shikari> lu_zero: we're trying to get that working
[22:33:00] <Dark_Shikari> but it gave me a CantPackException
[22:33:02] <Dark_Shikari> on our dll
[22:33:06] <Dark_Shikari> but it won't tell me why
[22:33:09] <lu_zero> dll?
[22:33:13] <lu_zero> windows?
[22:33:14] <Dark_Shikari> yes, dll
[22:33:19] <Dark_Shikari> well, we have a mac client and linux client too
[22:33:24] <Dark_Shikari> but we primarily care about the windows one
[22:33:34] <Dark_Shikari> it's cross-platform
[22:33:36] <lu_zero> I don't have window handy =|
[22:34:22] <lu_zero> add --compress-exports=0 --strip-relocs=0
[22:34:31] <lu_zero> might help if you haven't
[22:36:13] * lu_zero is thinking about adding a feature upx for gentoo
[22:37:20] <lu_zero> on elf it works fine apparently
[22:37:28] <lu_zero> and halves the size
[22:37:47] <Dark_Shikari> it's slower because it prevents direct memory/disk mapping
[22:38:41] <lu_zero> depending on your hardware you might not care much about it
[22:39:11] <Dark_Shikari> if you have a 10MB .so
[22:39:17] <Dark_Shikari> you have to read out the entire .so from disk to call one function from it
[22:39:20] <Dark_Shikari> (when upx'd)
[22:39:50] <lu_zero> instead of just reading the parts you need
[22:40:16] <lu_zero> if the storage is slow you might prefer upx
[22:40:36] <lu_zero> still seeking across 10m or reading 5
[22:40:44] <lu_zero> not sure which is better
[22:43:15] <lu_zero> 3.05 fixes upx for libraries on ELF but not for dylibs
[22:43:54] <mru> disks are cheap
[22:45:31] <lu_zero> cheap and slow
[22:45:55] <lu_zero> so you might like to trade cpu for speeding up loading in a way or another
[22:46:02] <lu_zero> and memory is still not enough
[22:46:15] <lu_zero> so having less stuff in the cache might be good as well
[22:46:55] * lu_zero wanted to see what happens on an efikamx but the arm elf support isn't that complete apparently
[22:48:27] <DonDiego> BBB: have you investigated those chromium bug reports?
[22:49:29] <CIA-92> ffmpeg: darkshikari * r24671 /trunk/libavcodec/ (vp8data.h vp8.c): VP8: eliminate a dereference in coefficient decoding
[22:50:50] <peloverde> DonDiego: The only real suggestion I see there is splitting vp568 from vp56
[22:51:00] <DonDiego> yes
[22:51:10] <DonDiego> can you reproduce the build failure?
[22:51:32] <DonDiego> it will take me a while to finish compiling..
[22:52:01] <DonDiego> and what about the higher memory requirements?
[22:53:55] <j0sh> lu_zero: https://groups.google.com/a/webmproject.org/group/webm-discuss/msg/679a63659ceff3e7?dmode=source
[22:54:29] <j0sh> don't tell me the S is at the 9th (8) bit
[22:54:43] <peloverde> I can't reproduce the build failure
[22:55:44] <lu_zero> uhm
[22:55:47] <lu_zero> shouldn't
[22:55:53] <DonDiego> splitting vp56 is likely a good idea
[22:55:57] <peloverde> With "configure --disable-everything --enable-decoder=vp8"
[22:56:14] <DonDiego> we really should not be bigger than libvpx
[22:56:15] <lu_zero> the 9th (8) is the block on the right of the number
[22:56:36] <j0sh> eh, the numbers aren't really lined up
[22:56:42] <j0sh> or i don't know how to read a spec
[22:56:44] <j0sh> alright
[22:56:50] <j0sh> another patch on the way :)
[22:56:53] <j0sh> btw
[22:56:53] <lu_zero> 0-1
[22:56:58] <j0sh> yeah
[22:56:58] <lu_zero> first block
[22:57:02] <DonDiego> maybe Dark_Shikari's work can tie into that..
[22:57:03] <lu_zero> 0th
[22:57:14] <j0sh> i talked to sjoerd, the guy who made vp8 rtp for gst
[22:57:16] <peloverde> Their comparison also doesn't have h.264, so the growth includes cabac.o and h26pred.o
[22:57:26] <j0sh> he basically said he made up his own vp8 rtp format
[22:57:41] <j0sh> so we're going to be kinda incompatible until theres a more official spec
[23:01:50] <DonDiego> i cannot reproduce the build failure either
[23:04:57] <DonDiego> lu_zero: that's the broken func i was talking about: libavcodec/ppc/mpegvideo_altivec.c:74: warning: ‘dct_quantize_altivec’ defined but not used
[23:05:35] <peloverde> DonDiego: As far as I can tell vp56.o isn't even needed by vp8.o
[23:05:54] <peloverde> Everything it uses is inline in vp56.h
[23:08:53] <peloverde> It also seems to build without vp56data.o
[23:10:24] <peloverde> Any thoughts from the VP8 people?
[23:12:56] <DonDiego> builds here as well
[23:14:26] <DonDiego> it's not needed
[23:15:53] <lu_zero> uh
[23:17:12] <lu_zero> DonDiego: why that function isn't wired in?
[23:17:29] <DonDiego> the altivec one?
[23:17:40] <CIA-92> ffmpeg: diego * r24672 /trunk/libavcodec/Makefile:
[23:17:40] <CIA-92> ffmpeg: Remove redundant h264pred.o from VP8 objects list.
[23:17:40] <CIA-92> ffmpeg: It is already selected through the H264DSP dependency of VP8.
[23:20:39] <BBB> DonDiego: which one?
[23:20:50] <DonDiego> BBB: which one?
[23:21:49] <Dark_Shikari> found a bug in the h264 decoder
[23:22:04] <Dark_Shikari> It doesn't appear to give correct output (at least on our streams) if run in frame-at-a-time mode as AVCC
[23:22:10] <Dark_Shikari> however, if we run it in slice-at-a-time mode, it works.
[23:23:42] <BBB> dondiego: the chromium bug report?
[23:23:58] * DonDiego is now completely confused
[23:24:18] <CIA-92> ffmpeg: diego * r24673 /trunk/libavcodec/Makefile: The VP8 decoder does not depend on vp56.o and vp56data.o.
[23:24:28] <BBB> <DonDiego> BBB: have you investigated those chromium bug reports? (6:48PM)
[23:24:40] <DonDiego> does anybody have an account for the chromium bug tracker?
[23:24:48] <DonDiego> BBB: we're on it already
[23:24:53] <lu_zero> I have one =P
[23:24:59] <DonDiego> frank barchard claimed a build failure
[23:25:00] <peloverde> Any google account can post/star
[23:25:09] <DonDiego> which is unreproducible
[23:25:46] <DonDiego> and then he reported that ffmpeg needs more space than libvpx
[23:25:54] <DonDiego> i may just have fixed that..
[23:26:03] <Dark_Shikari> also, if michael is reading this, I have a STRONG suspicion that the bug in h264 is in deblock
[23:26:08] <BBB> their decoder is huge, so I'd be surprised
[23:26:18] <BBB> but anyway :-p
[23:26:20] <Dark_Shikari> "needs more space"?
[23:26:23] <Dark_Shikari> libavcodec is huuuge
[23:26:36] <DonDiego> let me see how much my commit shrunk libavcodec.a ..
[23:26:40] <BBB> libavcodec+vp8 would be expected to be smaller than libavcodec-vp8+libvpx
[23:26:45] <Dark_Shikari> BBB: yes, of course
[23:26:51] <BBB> they claim it's bigger
[23:26:56] <BBB> (chromium people)
[23:27:00] <Dark_Shikari> how about just measure it?
[23:27:01] <Dark_Shikari> it's not that hard
[23:27:03] <BBB> they did
[23:27:05] <BBB> it's bigger ;)
[23:27:07] <Dark_Shikari> no, YOU measure it
[23:27:12] <Dark_Shikari> Oh
[23:27:16] <BBB> haha :-p I'm lazy, and dondiego is already on it
[23:27:19] <Dark_Shikari> You mean because vp8 depnded on h264... er, but wait a minute
[23:27:22] <Dark_Shikari> chromuim already uses h264.
[23:27:33] <BBB> I think it's vp56data.o
[23:27:35] <BBB> that file is huge
[23:27:37] <Dark_Shikari> ah.
[23:27:39] <BBB> I'm not sure why it was there
[23:28:01] <peloverde> Their comparison is a chromium build not a chrome build so it doesn't have h.264
[23:28:13] <BBB> actually
[23:28:15] <BBB> it's only 5kb
[23:28:43] <lu_zero> peloverde: commonly provided chromium has h264 =P
[23:28:54] <lu_zero> (and soon rtsp support =P)
[23:29:34] <peloverde> "./configure --disable-everything --disable-decoders --disable-protocols --disable-parsers --disable-avfilter --disable-avcore --disable-avdevice --disable-ffmpeg --disable-ffplay --disable-ffserver --disable-ffprobe --enable-shared --disable-static --disable-debug --disable-network --disable-gpl --disable-bzlib --disable-zlib --enable-decoder=theora --enable-decoder=vorbis --enable-demuxer=ogg --enable-pthreads --enable-yasm --ena
[23:29:34] <peloverde> ble-memalign-hack --cc=gcc-sjlj --prefix=./chromium8-ffmpeg --enable-decoder=vp8 --enable-demuxer=matroska"
[23:30:10] <DonDiego> they forgot --disable-doc
[23:30:53] <lu_zero> gcc-sjlj ?
[23:31:13] <peloverde> some mingw something
[23:33:00] <Kovensky> <@Dark_Shikari> also, if michael is reading this <-- he isn't, he hopefully will be in several hours though :>
[23:34:33] <peloverde> Is my vorbis patch trivial enough or do I need to wait for Yuvi?
[23:34:51] <DonDiego> my commit reduced the lib by 25k
[23:35:00] <DonDiego> somebody please post to the bug report
[23:35:12] <peloverde> nice
[23:35:17] <DonDiego> i don't have the pw to my google account handy
[23:35:35] <peloverde> I will
[23:36:53] <DonDiego> thanks
[23:37:32] <DonDiego> post quickly, we should try to impress them with totally awesome response times..
[23:37:36] <DonDiego> :)
[23:37:39] <peloverde> http://code.google.com/p/chromium/issues/detail?id=50811
[23:38:16] <BBB> lu_zero: you're writing rtsp support for them?
[23:38:46] <peloverde> They are also considering dropping their scaler in favor of libswscale
[23:40:05] <DonDiego> peloverde: please also mention that the build failure is unreproducible from our side and that they can add --disable-doc to the build line
[23:41:09] <peloverde> Their whole configure line is somewhat wonky and redundant
[23:41:15] <lu_zero> BBB: making it pass the url to ffmpeg shouldn't be any harder
[23:45:22] <peloverde> openbsd has a new audio api, because we really need another audio api
[23:45:33] <BBB> I was about to say...
[23:46:23] <ShadowJK> Linux invents a new one once every 18 months too
[23:46:45] <DonDiego> vp8 apparently does not depend on cabac.o either..
[23:46:56] <DonDiego> who created that line in the makefile?
[23:47:27] * DonDiego longs for the days of OSS
[23:47:52] <peloverde> The OSS devs were assholes
[23:48:06] <lu_zero> DonDiego: oss isn't and wasn't that great ^^;
[23:48:13] * mmu_man points DonDiego to OSS4
[23:48:33] <DonDiego> but oss got fixed it seems..
[23:48:35] <mmu_man> http://developer.opensound.com/
[23:48:47] <DonDiego> too little too late, i'm afraid..
[23:48:59] <mmu_man> much more, OSS4 has all what ALSA folks complained about
[23:49:16] <mmu_man> and unlike ALSA, the API is understandable, documented, it works
[23:49:22] <mmu_man> and it's portable (and ported)
[23:49:34] <mmu_man> I ported it to Haiku in a month or so
[23:49:49] <mmu_man> with a native wrapper so apps see no difference
[23:49:56] <mmu_man> try that with ALSA
[23:50:37] <CIA-92> ffmpeg: diego * r24674 /trunk/libavcodec/Makefile: The VP8 decoder does not depend on cabac.o.
[23:51:01] <DonDiego> there go another 2k
[23:51:16] <mmu_man> http://revolf.free.fr/beos/shot_haiku_oss_working.003.png
[23:52:34] <mmu_man> actually I think at least one linux distro switched to OSS4
[23:52:45] <BBB> their developers pushed hard for it
[23:52:56] <BBB> I received offers to implement gstreamer plugins for cash a couple of years ago
[23:52:57] <mmu_man> and IIRC FreeBSD uses it now (it had an antique OSS, obviously not ALSA)
[23:53:09] <mmu_man> well that's the problem with ALSA
[23:53:11] <BBB> I didn't do it, alsa sucked but an audio api war was worse
[23:53:12] <mmu_man> it's linux only
[23:53:27] <BBB> maybe I should've :-p would've been fun
[23:53:27] <mmu_man> well, who started it back then ? ;)
[23:53:47] <mmu_man> surely Hannu would still like it
[23:53:48] <mmu_man> :p
[23:53:53] <peloverde> 4front started it
[23:54:19] <mmu_man> they just went closed source for some reasons
[23:54:42] <mmu_man> but they didn't started ALSA by saying OSS was crap just for the sake of it
[23:54:58] <mmu_man> anyway
[23:57:01] <j0sh> BBB: is PKT_FLAG_KEY used anywhere by vp8?
[23:57:18] <j0sh> i looked quickly, but couldnt find any reference in the code
[23:57:18] <BBB> j0sh: imagine codec-copy into avi
[23:57:27] <BBB> it could be set in the muxer then
[23:57:29] <j0sh> ok
[23:57:31] <DonDiego> BBB: so there is no gstreamer plugin? it's a shame..
[23:57:42] <BBB> there might be now
[23:57:42] <j0sh> i don't know what it does anyhow :)
[23:57:43] <lu_zero> pfff
[23:57:48] <lu_zero> btw
[23:57:53] <BBB> j0sh: indicates that the frame is a keyframe (I-frame)
[23:58:04] <lu_zero> alsa had been implemented in qnx
[23:58:23] <j0sh> BBB: ah, i can see where that could be useful for copying
[23:58:28] <j0sh> alright then
[23:59:15] <mmu_man> lu_zero was it a port or a rewrite or just an API wrapper ?
[23:59:28] <mmu_man> actually I read about a port to OS/2 but I couldn't find the sources
[23:59:41] <mmu_man> still, where do I get teh sources ?
More information about the FFmpeg-devel-irc
mailing list