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

[irc at mansr.com]

[00:57:37] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ ran the analyzer again
[00:57:45] <astrange> it's as noisy as ever though
[00:58:03] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-I1qORD.html#EndPath but this one looks like a real problem...
[01:01:18] <j-b_Venice> BBB?
[01:08:17] <Honoome> j-b: are you in venice? o_O
[01:09:14] <j-b> Honoome: I just came back from Carneval!
[01:09:24] <Honoome> j-b: and you don't warn! >_<
[01:09:44] <j-b> Honoome: you are in Venice?
[01:09:55] <Honoome> I live in the mainland of Venice ;)
[01:10:02] <j-b> OMG? Fuck
[01:10:13] <j-b> I had no idea they were geeks in Venice
[01:10:28] <j-b> Honoome: be', ho fatto la setimana sanza computer
[01:10:47] <j-b> una cosa che non faccio mai, in tempo normale
[01:10:54] <j-b> ma lì, ero stanchissimo
[01:11:14] <Honoome> j-b: buona idea ;) -- but yeah there are very few devs around here :P
[01:11:36] <Honoome> I think I have the media-related exclusive, even with me barely being involved nowadays :P
[01:11:59] <j-b> Honoome: so, next FOSS-multimedia meeting will be in Venice?
[01:12:18] <Honoome> hmm more likely Turin if lu_zero can be prodded enough ;)
[01:12:40] <j-b> buon idea
[01:12:50] <Kovensky> lolitaly
[01:12:59] <Kovensky> I think my great grandfather was from italy ._.
[01:13:36] <Honoome> Kovensky: that's something people try not to be known ;)
[01:13:45] <Kovensky> :P
[01:13:48] <Honoome> j-b: would also work out fine to get libnemesi integration in that case
[01:14:08] <Kovensky> there are lots of italians in brazil, actually
[01:14:16] <j-b> Honoome: well, did you speak to ivoire? he was testing libnemesi integration back at FOSDEM
[01:14:34] <Kovensky> they floodes são paulo before the japanese did
[01:14:40] <Kovensky> flooded*
[01:15:04] <Honoome> j-b: had a brief chat :) I was a bit spaced out at fosdem to be honest ;) mru and the others can definitely tell
[01:15:43] <j-b> anyway, Venice was nice
[01:15:48] <j-b> and my g/f loved it
[01:16:06] <j-b> so, I believe i have now 6 months of bonus for extra-geeking
[01:16:46] <Honoome> hah, that's why you wanted to have the next conference in venice ;)
[01:18:27] <j-b> :)
[01:21:00] <Honoome> I'm afraid the only conference in Venice is OpenCon
[01:21:10] <Honoome> if it's still organised, which I'm not ready to bet on
[03:29:53] <astrange> Yuvi: i think your removal of pixel_addresses_initialized actually made the vp3 decoder more resilient
[03:30:48] <astrange> i have -mt artificially failing in get_buffer to test something, the decoder crashes afterwards by trying to access null golden_frame.data[0]
[03:30:57] <astrange> since it didn't check that until your patch and i haven't merged yet
[06:35:51] <josh> i want to take a shot at the direct temporal/spatial mv fixes from michael's low-hanging fruits h264 email
[06:36:06] <kshishkov> send a patch then
[06:36:08] <josh> is it ok to ask for help with that on here? the code is pretty dense
[06:36:57] <kshishkov> yes
[06:39:02] <elenril> morning
[06:39:05] <astrange> grab http://www.savedonthe.net/avc_regression.7z, i think it has all the h264 conformance streams
[06:39:08] <kshishkov> hej
[06:39:27] <josh> alright
[06:39:58] <astrange> you can test stuff with ffmpeg -i f.h264 -vsync 0 -f framecrc blah and check the output is the same before/after
[06:40:06] * elenril sighs
[06:40:12] <elenril> nobody want a nut conversion table :(
[06:40:15] <elenril> *wants
[06:40:19] <Dark_Shikari> and conformance vectors are very bad speed test cases
[06:40:20] <Dark_Shikari> generally
[06:40:25] <Dark_Shikari> it's best to use a Real World Stream for that
[06:40:31] <Dark_Shikari> (but they're critical to test compliance of course)
[06:40:42] <astrange> i use x264 streams for benchmarking
[06:40:55] <astrange> don't have anything great that's representative of interlaced
[06:40:58] <Dark_Shikari> Yeah I know, was poking to josh
[06:41:00] <josh> will "time ffplay <video>" be a good way to benchmark?
[06:41:13] <josh> for speed
[06:41:29] <astrange> time ffmpeg is ok if you run it in a loop a few times and pick the minimum, and use user time
[06:41:43] <astrange> (not time ffplay, though)
[06:41:50] <josh> alright
[06:41:51] <astrange> for smaller changes look at START_TIMER/STOP_TIMER
[06:44:27] <Dark_Shikari> yeah, in general timer is far more reliable
[06:45:02] <josh> okay cool, got a while to go before i do any testing though
[06:45:18] <josh> trying to figure out just what the existing code does first
[06:45:47] <astrange> it's heavily optimized but maybe still more readable than that part of the spec
[06:46:00] <Dark_Shikari> it decodes h264, duh ;) ;)
[06:47:57] <josh> heh yeah i'm just getting started in the video coding space, so there
[06:48:05] <josh> 's quite a bit to learn
[06:48:11] <Dark_Shikari> feel free to ask questions
[06:48:17] <Dark_Shikari> it's how everyone else learned
[06:48:36] <josh> will do, didnt think of reading the spec... doh, looking at that part now
[06:48:46] <Dark_Shikari> spec is good to have on hand, just don't look too much at it
[06:48:51] <Dark_Shikari> it can cause permanent brain damage
[06:48:57] <josh> :)
[06:48:59] <Dark_Shikari> it is known to the state of california to cause cancer
[06:49:14] <josh> use the JM decoder as the authoritative reference?
[06:49:17] <Dark_Shikari> yes
[06:49:22] <josh> ok cool
[07:08:59] <josh> hm
[07:09:36] <josh> spec only defines spatial/temporal direct prediction for 16x16 and 8x8, and JM only implements it for 8x8 as far as i can tell
[07:09:51] <Dark_Shikari> that isn't what he means
[07:09:58] <Dark_Shikari> if you have a 16x16 direct block
[07:10:08] <Dark_Shikari> based on type_col, your MV/ref choices may match up with a 16x16 block
[07:10:09] <Dark_Shikari> 16x8
[07:10:09] <Dark_Shikari> 8x16
[07:10:10] <Dark_Shikari> or 8x8
[07:10:26] <Dark_Shikari> one optimization is to consider this when doing direct calculations.
[07:30:45] <josh> hm guess i dont understand this as well as i thought i did
[07:31:00] <josh> need to digest this for a bit (not to mention its almost 3am here)
[07:31:10] <Dark_Shikari> the MVs for, say, a temporal direct block
[07:31:20] <Dark_Shikari> are calculated by using the MVs/refs in the colocated block in the L1 ref frame.
[07:31:24] <josh> right
[07:31:25] <Dark_Shikari> If that block is 8x16
[07:31:36] <Dark_Shikari> then the MVs calculated will form an effective 8x16 block too.
[07:31:44] <Dark_Shikari> and motion compensation can be simplified accordingly
[07:31:50] <Dark_Shikari> instead of doing 4 8x8 blocks, you can do 2 8x16s
[07:32:04] <Dark_Shikari> I think ffmpeg already does the simplified motion compensation, but not the simplified direct MV calculation
[07:32:07] <josh> so its doing 4 8x8 blocks now
[07:32:15] <josh> for a 8x16 mb
[08:30:53] <josh> about the scan8 table, i understand the zigzag pattern but not the numbers
[08:31:33] <Dark_Shikari> the numbers are the mapping
[08:32:03] <josh> yeah, but the mappings dont make sense
[08:32:16] <josh> a lot of it is like
[08:32:25] <josh> &h->ref_cache[0][scan8[0]]
[08:32:32] <Dark_Shikari> what's wrong with that
[08:32:36] <josh> which is ref_cache[0][12]
[08:32:39] <Dark_Shikari> scan8[0] means "the top left partition"
[08:32:55] <Dark_Shikari> so ref_cache[0][scan8[0]] means the mv of the first partition of any block
[08:32:59] <Dark_Shikari> er, the ref
[08:33:05] <Dark_Shikari> since the first partition will always include scan8[0]
[08:34:14] <josh> just trying to understand at a fundamental level, how does the number 12 (scan8[0]) translate to the first partition
[08:34:28] <Dark_Shikari> Ignore the 12.
[08:34:46] <josh> heh ok
[08:34:49] <Dark_Shikari> perhaps this bit of ascii art will help
[08:34:51] <Dark_Shikari> here's x264's
[08:34:58] <Dark_Shikari>    0 1 2 3 4 5 6 7
[08:34:59] <Dark_Shikari>  0
[08:34:59] <Dark_Shikari>  1   B B   L L L L
[08:34:59] <Dark_Shikari>  2   B B   L L L L
[08:34:59] <Dark_Shikari>  3         L L L L
[08:35:01] <Dark_Shikari>  4   R R   L L L L
[08:35:03] <Dark_Shikari>  5   R R
[08:35:12] <Dark_Shikari> note there is a column to the left of each one, and a row to the top
[08:35:18] <Dark_Shikari> that's for top/left values to be cached
[08:35:33] <Dark_Shikari> the top left "L" is 12 because 4 + 8 = 12
[08:36:12] <Dark_Shikari> that ascii art represents how the data is stored in memory
[08:36:17] <Dark_Shikari> L being luma, B being U, R being V
[08:36:21] <josh> ah ok
[08:36:48] <Dark_Shikari> so this might also be
[08:36:49] <josh> 4:2:0, ok that's clearer
[08:36:49] <Dark_Shikari>    0 1 2 3 4 5 6 7
[08:36:49] <Dark_Shikari>  0   b b   l l l l
[08:36:49] <Dark_Shikari>  1 b B B l L L L L
[08:36:51] <Dark_Shikari>  2 b B B l L L L L
[08:36:54] <Dark_Shikari>  3       l L L L L
[08:36:56] <Dark_Shikari>  4 r R R l L L L L
[08:36:59] <Dark_Shikari>  5 r R R
[08:37:01] <Dark_Shikari> er, oops, forgot the two rs above the Rs
[08:37:04] <Dark_Shikari> but whatever
[08:37:06] <Dark_Shikari> you get the idea
[08:37:09] <Dark_Shikari> lowercase are cached from previous MBs
[08:37:12] <Dark_Shikari> uppercase are decoded/calculated for this MB
[08:37:27] <josh> yeah i think so, it stores mvs for each of the planes
[08:37:33] <Dark_Shikari> no it doesn't
[08:37:53] <Dark_Shikari> the B/R sections are only used for data relevant to them, like nnz
[08:37:59] <josh> nnz?
[08:38:01] <Dark_Shikari> mvs, refs, etc are luma only
[08:38:05] <Dark_Shikari> since they apply equally to chroma
[08:38:08] <Dark_Shikari> nonzero count
[08:38:14] <Dark_Shikari> Number of NonZero coefficients
[08:38:25] <josh> gotcha
[08:38:47] <josh> thats a lot clearer now, thanks
[08:38:48] <Dark_Shikari> so scan8[0] means "the location in the array corresponding to the first L"
[08:39:01] <Dark_Shikari> the array is constructed so that scan8[n]-1 is the value to the left of n
[08:39:09] <Dark_Shikari> and scan8[n]-8 is the value to the top of n.
[08:39:36] <josh> yup, ok, so thats how the mv_cache stuff is laid out in memory, right?
[08:40:36] <Dark_Shikari> yes
[10:09:17] <DonDiego> h264_direct.c:153: warning: ISO C90 forbids mixed declarations and code
[10:09:24] <DonDiego> the world is coming to an end..
[10:11:05] <twnqx> finally that brokenness stops. never liked it.
[10:27:17] <KotH> DonDiego: the world has already ended long ago, and we are but shadows of the past
[10:45:49] <_av500_> amen..
[10:49:42] <KotH> _av500_: ah.. while you're here
[10:50:14] <KotH> _av500_: does archos plan any mp3 player that is 1) not a big brick (aka non-video) and has 2) at least 64G memory ?
[10:50:30] <KotH> _av500_: i'm looking for a replacement for my venerable cowon iaudio x5
[11:12:44] <pross-au> Hmm, iam i seeing things, or is PIX_FMT_RGB32 'alpha' handled differently between x86 and ppc
[11:13:08] <pross-au> when alpha=0, x86 swscaler routines treat it as non-transparent (good)
[11:13:23] <pross-au> when alpha=0, ppc swscaler treats it as fully transparent (bad imho)
[11:21:46] <kshishkov> IIRC either was no settlement on how to treat alpha values or it has been changed later
[11:23:33] <pross-au> thanks k-man. (urgh disregard, i figured it out)
[11:26:24] * kshishkov wonders where that alpha is actually used except for textures
[11:30:42] <pross-au> tsk tsk kshishkov
[11:30:51] <pross-au> you forgot MPEG-4 object encoding
[11:31:04] <kshishkov> who hasn't?
[11:31:36] <pross-au> it has alpha masks
[11:33:44] <Kovensky> alpha is one of the main reasons people use lagarith on fansubbing (other than stupidity)
[11:34:06] <Kovensky> for storing after effects overlays for applying with avisynth
[11:34:42] <kshishkov> oh
[11:35:24] <pross-au> IIRC you can compress the alpha with MPEG-4 ASP
[11:35:44] <pross-au> ooops, not ASP, one of the other brain dead profiles
[11:36:08] <kshishkov> http://engrishfunny.files.wordpress.com/2010/01/engrish-funny-no-translation.jpg
[11:37:40] <pross-au> That's a bit presumptuous of them
[11:41:05] * Kovensky wonders if llvm svn still miscompiles ffmpeg
[12:36:07] <j-b> BBB?
[12:55:26] <DonDiego> Kovensky: only one way to find out..
[13:01:01] <Kovensky> heh
[13:01:10] <Kovensky> first I need to compile it :S
[13:01:28] <elenril> they don't have binary packages on fbsd? =p
[13:02:36] <Kovensky> elenril: they have of 2.6
[13:11:30] <DonDiego> mru: the table generator naming scheme in libavcodec is a mess
[13:59:05] <mru> DonDiego: I know
[14:01:05] <DonDiego> mru: fix it :)
[14:02:58] <elenril> anybody wants to write some readable documentation for -map?
[14:19:10] <KotH> i guess that someone is you ;)
[14:19:31] * elenril would have to understand it first =p
[14:27:19] <justlooking> "elenril> anybody wants to write some readable documentation for -map?" "over on ffmpeg you said * elenril was recently enlightened about how -map works" you perhaps ? or you can just take DS's text ? "woxidu_home> I tried doing -map 0.8:0.4
[14:27:19] <justlooking> <woxidu_home> but I think that wasn't enlightened enough of me
[14:27:19] <justlooking> <Dark_Shikari> no
[14:27:19] <justlooking> <Dark_Shikari> -map stream1 -map stream2 -map stream3...
[14:27:20] <justlooking> <Dark_Shikari> i.e. -map every stream you want in the output
[14:27:22] <justlooking> * paltman has quit (Quit: paltman)
[14:27:24] <justlooking> <woxidu_home> so if I want video stream 0.1 and audio stream 0.4, I'd do -map 0.1 -map 0.4 ?
[14:27:26] <justlooking> <Dark_Shikari> yes..."
[14:27:46] <J_Darnley> Simple use is simple!
[14:31:12] * justlooking unless OC your alexander the meerkat http://www.youtube.com/watch?v=4Ust9YBlEfY "Simples"
[14:34:21] <J_Darnley> "unless overclock your alexander"?
[14:37:55] <justlooking> LOL, if your Personal Computers called alexander Yes Of Course.
[15:19:57] <J_Darnley> Has anyone tested my flac-tag writing patch?
[15:21:21] <J_Darnley> I need some help finding out why av_freep() causes a segmentation fault
[15:23:24] <kshishkov> because you forgot ampersand before p0, silly
[15:23:38] <kshishkov> also since variable is local, av_free() is enough
[15:24:43] <J_Darnley> /facepalm
[15:29:44] <J_Darnley> I wonder why it worked fine when I didn't write into p
[15:36:15] <kierank> is there a macro/function to convert from channel mapping to number of channels?
[15:36:47] <kshishkov> __builtin_clz() :)
[15:37:26] <kshishkov> in channel mapping each bit represents one channel IIRC
[15:44:27] <kierank> then i need something to count bits set
[15:45:40] <Kovensky> clz =p
[15:45:57] <Kovensky> unless the bits aren't packed
[15:46:15] <kshishkov> why not use channel counnt directly?
[15:46:20] <Kovensky> (count leading zeros)
[15:46:48] <kshishkov> unfortunately, those bits are sparse
[15:46:53] <Kovensky> ic
[15:47:09] <Kovensky> too bad :(
[15:52:38] <kierank> [15:46] <@kshishkov> why not use channel counnt directly? --> because for example 6 channels in dolby e could mean 6xmono, 3xstereo or 5.1 etc
[15:55:22] <J_Darnley> kshishkov: If I don't need to set p0 to NULL, does the same apply to p?
[15:57:09] <kshishkov> of course
[16:02:22] <elenril> any news about bink decoder?
[16:02:47] <kshishkov> works fine on newer files after some changes
[16:02:57] <kshishkov> still have to add BIKb support
[16:04:11] <elenril> when will it be merged? ;)
[16:06:08] <kshishkov> who knows?
[16:06:44] <elenril> you?
[16:07:28] <kshishkov> no
[16:08:10] <iive> when would you start sending patches to ML so it could be merged?
[16:08:20] <kshishkov> I sent one
[16:08:45] <iive> so, it's all in michael's hands.
[16:10:59] <kshishkov> yes, and those are busy with H.264
[16:11:54] <elenril> did anyone benchmark latest improvements?
[16:15:58] <kshishkov> only for the first few
[16:17:19] <elenril> i know about those, it was ~10% faster
[16:51:58] <kierank> found the function to find number of channels finally
[16:51:59] <kierank> avcodec_channel_layout_num_channels
[16:58:15] <josh> doing the spatial/temporal dpred h264 optimizations. direct blocks are always the same size as their ref block?
[17:00:37] <kshishkov> should be, I think
[17:01:33] <josh> ok
[17:03:19] <pengvado> temporal direct blocks are the same size as their L1 ref
[17:03:28] <pengvado> spatial direct blocks need not share any size with anything
[17:09:28] <josh> alright
[17:37:22] <josh> can someone take a look at this and let me know if i'm on the right track, or totally off base? this is just for 16x8 temporal dpred. http://pastie.org/824526
[18:07:32] <siretart> Dark_Shikari: I'm trying to compile 0.5 with your patch against an updated libx264 without luck: http://pbot.rmdir.de/47829498a2e7662d2610acab56ada447
[18:11:48] <J_Darnley> siretart: it looks like he might have missed modifying configure
[18:12:23] <J_Darnley> change x264_encoder_open for x264_encoder_encode
[18:41:38] <Dark_Shikari> siretart: your x264.h is screwed up
[18:41:50] <Dark_Shikari> remember, the x264.h you include and the libx264 you link MUST MATCH VERSIONS
[18:42:06] <Dark_Shikari> do remember that ld _prefers shared_, even if static is newer
[18:43:40] <Honoome> unless it finds a static archive alone in a directory passed through -L
[18:44:16] <siretart> Dark_Shikari: 'my' x264.h? that is the version from current tip :-)
[18:44:25] <Dark_Shikari> siretart: this is a common newbie mistake
[18:44:30] <Dark_Shikari> a user has an old x264 installed, and a new x264 installed
[18:44:43] <Dark_Shikari> in your case, ffmpeg has #included an old x264.h header
[18:44:47] <Dark_Shikari> but you are linking to a new libx264
[18:46:23] <siretart> Dark_Shikari: I have package current x264, and that package replaced /usr/include/x264.h
[18:46:52] <Dark_Shikari> either way, something is broken, because x264.h redefines x264_encoder_open in any recent version
[18:46:55] <Dark_Shikari> so you're using a year-old x264.h
[18:47:49] <siretart> hm. but where does that come from?
[18:48:11] <siretart> obviously not from /usr/include
[18:48:32] <Dark_Shikari> probably local
[18:48:42] <siretart> Dark_Shikari: I'd rather say that ffmpeg 0.5's configure doesn't work with current x264
[18:48:57] <siretart> there is no "local" x264.h around here
[18:49:10] <Dark_Shikari> Oh, simple
[18:49:15] <Dark_Shikari> we need to modify configure very slightly
[18:49:16] <josh> siretart, you might have an older version of x264 lying somewhere? "locate libx264"
[18:49:17] <Dark_Shikari> my mistake.
[18:49:28] <Honoome> the configure is checking the symbol, not the definition, I guess
[18:49:30] <siretart> afk, (1-2h)
[18:49:31] <Dark_Shikari> s/x264_encoder_open/x264_encoder_encode in configure
[18:49:35] <Dark_Shikari> that will fix it
[18:49:41] <Honoome> [as in, not including x264.h so can't get the x264.h redefinition]
[18:50:07] <siretart> Dark_Shikari: I imagined something like that, thanks for confirming that
[18:50:23] <siretart> Dark_Shikari: can you propose a patch that would work with both api versions 67 and 84?
[18:50:38] <Dark_Shikari> that will work with both
[18:50:55] <siretart> ok, I'll try later. cu around
[19:05:57] <kierank> How would request_channel_layout work if there are multiple tracks with the same track layout in one stream?
[19:06:29] <kshishkov> huh?
[19:06:41] <kshishkov> sounds like terminology collision
[19:09:10] <kierank> e.g. 4 x stereo tracks (in the one dolby e "stream"). Each track has an AVStream but how do you signal to each decoder to decode tracks 0-1, 2-3, etc
[19:15:19] <kshishkov> tough luck, I think
[19:19:48] <kierank> hmmm I thought me and merbzt had this worked out but it turns out we dont...
[19:21:23] <kshishkov> maybe you should further split that stream?
[19:22:33] <kshishkov> ah, you do that (tracks)
[19:23:05] <kshishkov> well, you provide data, FFmpeg decides which AVStreams from it to decode
[19:24:19] <kierank> My idea was to send it the whole packet from which the decoder is told to decode x channels in y configuration.
[19:24:34] <kierank> but there's no current way to signal the index
[19:24:40] <kshishkov> why?
[19:25:00] <kshishkov> I mean, what for?
[19:26:25] <kierank> since a given packet can have 4 x stereo for example the current system won't work because the channel maps are the sample. On the other hand the demuxer could parse the dolby e packet
[19:26:58] <kshishkov> the second way is better
[19:28:13] <kierank> yes
[19:29:12] <kierank> however there will be no way to deal with the metadata
[19:29:37] <kshishkov> split it as well ;)
[19:37:56] <kierank> merbzt, ping
[19:45:46] <kierank> nice, lavc has support for afd
[20:55:44] <josh> latest attempt at 16x8 temporal direct prediction here. http://pastie.org/824731
[20:56:05] <josh> it runs fine but the framecrcs are a bit off, not sure how to track that down. any tips?
[20:56:06] <Dark_Shikari> the is intra part is pointless
[20:56:10] <Dark_Shikari> either the type_col is intra, or it isn't
[20:56:13] <Dark_Shikari> you can't have part of it be intra
[20:56:22] <Dark_Shikari> an intra type_col counts as 16x16
[20:56:43] <josh> oh wasnt sure if you could have a 16x8 intra part
[20:56:48] <Dark_Shikari> no
[20:56:50] <josh> ok
[20:58:17] <Dark_Shikari> for reference, it seems ref_cache[1] is always set to 0
[20:58:28] <Dark_Shikari> that should be split out of the per-partition code
[20:58:33] <Dark_Shikari> since it's constant
[20:58:42] <Dark_Shikari> i.e. a single 4x4 fill_rectangle
[20:58:49] <Dark_Shikari> faster too
[20:59:28] <josh> alright will do that
[20:59:46] <Dark_Shikari> it can probably be done first before anything else
[21:00:01] <Dark_Shikari> for reference, you should look at x264_mb_predict_mv_direct16x16_temporal in x264's code
[21:00:04] <Dark_Shikari> it's not as optimized
[21:00:05] <Dark_Shikari> but you may get some ideas
[21:00:11] <Dark_Shikari> it's in common/macroblock.c
[21:00:19] <Dark_Shikari> note how the _first_ thing it does is x264_macroblock_cache_ref( h, 0, 0, 4, 4, 1, 0 );
[21:00:33] <Dark_Shikari> (oh, and do note it's simplified--and explains in comments how it is--in ways that wouldn't work in ffh264)
[21:01:14] <josh> i'll check it out, my first dive into x264 code, heh
[21:01:23] <Dark_Shikari> It's also much shorter.
[21:45:21] <Dark_Shikari> hmm, how do I run backtrace on all threads in gdb?
[21:47:17] <thresh> thread apply all bt
[21:48:40] <Dark_Shikari> ah k, thx
[21:49:30] <Dark_Shikari> hmm. any reason why code would segfault in gdb but not outside of gdb?
[21:49:47] <Honoome> Dark_Shikari: are you sure it's a segfault and not a SIG33 or something like that?
[21:49:55] <Dark_Shikari> SIGSEGV
[21:51:43] <Dark_Shikari> worse, it's inside a nested macro
[22:52:55] <mt> Are there any available samples of joint-stereo atrac3 streams in rm ?
[22:54:18] <mru> if so, we have a winner for obscure sample of the month
[22:55:23] <Honoome> elenril: uhm I heard you saying something about map_meta_data and artist mapping lately?
[22:56:30] <mt> mru: So it would be impossible to test whether the decoder actually works correctly for such samples, however rare/obscure ? :)