[FFmpeg-devel-irc] IRC log for 2011-01-21

[irc at mansr.com]

[00:47:52] <mru> I made a little chart: https://spreadsheets.google.com/ccc?key=0AguHvNGaLXy9dHRYMFZpODZ5dXdyV0JNaG1XWWJ3MWc&hl=en&authkey=CJH15Y0G
[00:48:10] <mru> running 30-day average number of ffmpeg commits
[01:02:28] <lu_zero> mru: the chart is quite interesting
[01:03:41] <lu_zero> seems we have some kind of seasonal trends
[01:05:08] <mru> some might be gsoc-related
[01:05:18] <mru> qualifications tend to see a burst
[01:05:34] <lu_zero> yes
[01:08:44] <mru> and something happened in 2006
[01:25:04] <jannau> mru: cvs svn switch?
[01:25:54] <mru> something gave development a boost
[01:27:50] <jannau> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-May/011293.html
[01:29:53] <mru> maybe svn is that much better than cvs
[01:30:06] <jannau> less hassle to commit with svn than cvs seems a likely cause
[01:30:43] <jannau> I think I forgot how bad cvs really was
[01:30:51] <iive> there must be few months with zero commits.
[01:31:18] <mru> why?
[01:31:28] <iive> mphq hardware died
[01:31:45] <mru> we had it back up on new hw rather quickly
[01:32:00] <mru> that was in may/june 2006
[01:32:08] <iive> not that quickly
[01:32:15] <mru> I don't remember
[01:32:34] <uau> there was some downtime
[01:32:37] <mru> hmm, was ffmpeg still on sourceforgery at the time?
[01:32:52] <iive> most probably
[01:32:57] <uau> IIRC some extra for at least mplayer because diego wanted to prettify the svn repository history before putting it up
[01:33:13] <mru> that would have been days, not months
[01:33:16] <iive> moving files
[01:33:33] <uau> it was more than days, something like weeks IIRC
[01:33:46] <mru> must have been one ugly cvs repo
[01:35:20] <uau> there's a gap in mplayer commits from may 18 to 30
[01:40:43] <uau> i don't think the move to svn was a big factor in development btw
[01:45:04] <jannau> google soc started 2006 iirc
[01:45:13] <mru> yes
[01:45:51] <Dark_Shikari> Good news, everyone!  The Sandy Bridge is approved and will be built.
[01:47:28] * mru would rather have a bridge built from bricks
[01:56:03] <Jumpyshoes> Dark_Shikari: the communal one?
[02:06:06] <saintd3v> perhaps they should name it "thermae"?
[02:08:19] <Dark_Shikari> Jumpyshoes: probalby will be given to me but I'll give out public logins
[02:08:56] <Jumpyshoes> Dark_Shikari: okay, nice
[02:14:26] <mru> fosdem schedule preview: http://fosdem.org/2011/preview-program
[02:14:43] <saintd3v> should probably be "balnea" then :P
[02:19:19] <mru> hmm, several trolling targets there
[02:19:25] <lu_zero> where?
[02:19:33] <mru> fosdem
[02:19:36] <mru> systemd: Beyond init (Lennart Poettering)
[02:19:58] <mru> BSD-Licensed Toolchain Status (Brooks Davis)
[02:20:17] <mru> mk-configure (Aleksey Cheusov)  <-- no idea what that is, but it could be troll-worthy
[02:20:22] <mru> or perhaps it's something good
[02:20:37] <astrange> systemd: we felt like rewriting the startup sequence again without being as good as launchd?
[02:20:54] <mru> what's wrong with sysvinit?
[02:21:13] <astrange> people start all kinds of things that don't need to run on startup and it makes it take too long
[02:21:30] <mru> so they're solving the wrong problem
[02:21:52] <mru> and bundling inetd and automount into some all-singing init sounds scary to me
[02:22:06] <mru> GNU Autotools (Ralf Wilhenhues)
[02:22:18] <mru> Power, Freedom, Software (Karsten Gerloff)
[02:22:34] <mru> that last one will probably make me puke
[02:23:13] <mru> Android video streaming: Android devices as video prosumers (Fernando Garcia)
[02:23:59] <mru> The difficulty of forking (Anne Nicolas, Michael Scherer)
[02:24:21] <Dark_Shikari> lols
[02:24:25] <mru> Who the bloody hell cares about Debian? (Stefano Zacchiroli)
[02:24:54] <Jumpyshoes> :D
[02:25:56] <saintdev> mru: "for ffmpeg, we just...."
[02:25:57] <Compn> mru : where is the top10 gmane ?
[02:26:14] <mru> Compn: http://gmane.org/
[02:26:17] <Compn> oh there it is
[02:26:19] <Compn> i'm blind
[02:26:24] <mru> #3
[02:26:42] <Compn> activity or gmane accesses ?
[02:26:57] <Compn> activity probably
[02:27:25] <saintdev> mru: i doubt they cover coups in "difficulty of forking" =P
[02:35:38] <uau> astrange: how's it worse than launchd?
[02:36:23] <astrange> ah, i missed the part where it mentioned on-demand daemons
[02:36:30] <astrange> that's the major feature of launchd i notice
[02:36:55] <lu_zero> systemd sounds a _bit_ wrong for servers like apache
[02:36:59] <astrange> but it's strange that they mention "elaborate dependency systems"
[02:37:05] <lu_zero> among the rest
[02:37:08] <astrange> if everything is on-demand, you don't need those...
[02:37:18] <lu_zero> uh?
[02:38:22] <uau> astrange: which page are you talking about?
[02:39:15] <Compn> lu_zero : btw michael said he didnt review your swscale patches yet. how do you assume what he thinks about them?
[02:39:22] <uau> the fosdem extended description i guess
[02:41:11] <Compn> now i cant find that mail, hrm
[02:41:57] <uau> i think not everything can be "on demand" in a way that would remove the need for explicit dependencies
[02:42:40] <uau> and when you're not starting services but shutting them down you need to know something about the order to do that in
[02:52:00] <lu_zero> Compn: I know he dislikes that way since he told me long ago while I asked my soc student for swscale to do that ^^
[02:57:13] <Compn> ok then :P
[02:59:28] <astrange> oh, i think that's dealt with in launchd by suggesting that services be able to stop at any time via kill -QUIT
[02:59:37] <astrange> makes shutdown a lot faster if you don't have to cleanup
[02:59:41] <astrange> of course that doesn't always work
[03:00:46] <uau> are the services also supposed to deal with another service they depend on stopping first?
[03:35:19] <mru> uau: please stick your head in this bucket of sand
[03:35:33] <mru> good... now, do you see any problems?
[04:44:41] <Compn> http://vicerveza.homeunix.net/~viric/soft/bug/
[06:15:28] <peloverde> When did networking in mainstream distros get so bad
[06:16:30] <Dark_Shikari> It was never good
[06:17:14] <Dark_Shikari> much like /b/
[06:17:29] <peloverde> i've used linux for 10 years, never had a network problem until 6 months ago
[06:18:32] <peloverde> well maybe that's a bit of an embellishment, i didn't have a network problem until network manager showed up, then it's been on and off problems
[06:20:15] <saintdev> that bad? lol
[06:21:05] <thresh> network-manager? yes
[06:22:51] <saintdev> thresh: i've never had a problem with it (well, except for it's awful openvpn support)
[06:24:06] <thresh> saintdev: yeah, they somehow think there could be only one VPN at a time
[06:24:34] <saintdev> thresh: or even worse, no vpns at a time! =P
[06:24:34] <thresh> I don't like the whole idea of "first you log in, then you have the network"
[06:24:37] * elenril thinks network manager is pure evil
[06:26:00] <saintdev> i like network-manager for my netbook. i take it everywhere, and never know what network i'm going to be connecting to.
[06:27:33] <peloverde_> it's too gui centric, too wireless centric, and too opaque
[06:28:03] <saintdev> peloverde_: true, and that's why i don't use it on my desktop
[06:29:35] <peloverde__> it only took two reboots but networking is alive, yay!
[06:29:54] * saintdev misses 16saayunz
[06:30:49] <peloverde__> that guy was a dick
[06:32:56] <saintdev> maybe i'll steal his sweet nick, then
[06:48:43] <elenril> it's too gui centric, too wireless centric, and too opaque
[06:48:45] <elenril> ^YES
[06:49:11] <elenril> at least debian isn't pushing it
[06:53:45] <peloverde__> it was the default in squeeze
[06:54:23] <peloverde__> 16saayunz :Erroneous Nickname -- "oh noes!"
[06:54:53] <saintdev> doh!
[06:54:57] <saintdev> should have kept it :/
[06:55:11] <peloverde> I would have lost it anyway, i played some tf2 after work
[06:55:26] <I6SAAYUNZ> close enough
[06:55:38] <saintdev> rebooting just for steam sucks :/
[06:55:54] <peloverde> fun fact, steam ships ffmpeg
[06:55:55] <saintdev> kierank, yeah
[06:56:04] <astrange> without committers how do we tell when someone should get ops?
[06:56:13] <_av500_> peloverde: wait till they go wemb
[06:56:14] <saintdev> kierank: or l6saayunz in lowercase
[06:56:16] <kierank> peloverde: well they won't once they upgrade their chromium
[06:56:35] <astrange> did they drop ffmpeg for vp3?
[06:56:45] <astrange> + mp3 is still in i think
[06:57:04] <saintdev> peloverde: yeah, we've discussed that here before, it's because of their chromium embedded
[06:57:27] <kierank> while you're here astrange: Do I have to do anything special if I want to stick user_data in the AVFrame in ffmpeg-mt?
[06:57:53] <_av500_> user_data-mt
[06:58:05] <kierank> for mpeg-2 and h.264
[06:59:01] <elenril> peloverde: i'm pretty sure it wasn't
[06:59:18] <elenril> i installed squeeze just a few weeks ago on the machine i'm ircing from
[06:59:29] <peloverde> so did I
[06:59:51] <elenril> maybe it's installed by default with some desktop crap like gnome
[06:59:59] <peloverde> I installed gnome
[07:00:01] <elenril> just get rid of it then
[07:01:58] <astrange> i don't know when you can safely free() it
[07:03:08] <kierank> hmmm
[07:03:54] <astrange> ahh. you can free or overwrite it when it comes back from get_buffer() the next time
[07:04:22] <kierank> I'm not sure at the moment if i'm passing it to the right pointer
[07:04:30] <astrange> except it should be av_fast_malloc instead of free, of course
[07:04:49] <kierank> because internally it copies the data but the output data from the api is empty
[07:05:15] <astrange> add it to FF_COMMON_FRAME and it should come out the other end
[07:05:34] <kierank> that's what i did
[07:10:39] <kierank> http://pastebin.com/LHgzzGRW
[07:10:47] <kierank> ignore the h.264 one for now
[07:14:08] <astrange> mpeg12 isn't mt enabled so that should be the same as mainline
[07:14:23] <astrange> (it's written but turned off)
[07:14:24] <astrange> sample?
[07:16:34] <kierank> hmmm maybe something stupid in my code then
[07:18:34] <Dark_Shikari> kshishkov: we found the english equivalent to http://en.wikipedia.org/wiki/How_does_one_patch_KDE2_under_FreeBSD%3F
[07:18:43] <Dark_Shikari> someone came to #x264 to ask a question about japanese
[07:18:49] <thresh> :)
[07:20:21] <elenril> that's a natural thing to do
[07:20:32] <elenril> where else would you ask about that
[07:20:43] <Dark_Shikari> #japanese?
[07:24:39] <peloverde> ADPCM in mov is almost working now...
[07:42:21] <Tjoppen> bcoudurier: I need to implement support for opatom in the mxf demuxer. any thoughts?
[07:44:54] <cartman> moin
[07:45:40] <thresh> moroning
[07:53:24] <andoma> morning
[07:53:44] <saintdev> hi guys
[07:59:01] <peloverde> Any ideas as to why when coding the same stream to different containers I get different numbers of packets?
[08:02:47] <astrange> adpcm can have multiple frames per packet. but i don't know what would make the choice different
[08:03:06] <astrange> hmm, request to make avcodec_decode_video2 async with mt... i think that's problematic
[08:03:43] <peloverde> When writing to mov I'm getting 1142 size 1024 packets
[08:03:58] <peloverde> when writing to wav I'm getting 1300 size 1024 packets
[08:07:59] <kshishkov> Dark_Shikari: I thought that x264 was only for Touhou tips and tricks
[08:12:01] <Tjoppen> peloverde: is either of them correct?
[08:12:13] <peloverde> 1300 seems to be correct
[08:12:49] <Tjoppen> odd. I'd expect wav to be a little trickier, since both it and avi doesn't handle start_time != 0 very well
[08:29:10] <peloverde> It's ALLLLLLIVVVVE
[08:29:33] <kshishkov> whut?
[08:30:48] <peloverde> adpcm in mov
[08:31:09] <pJok> and avi in mov?
[08:32:28] <elenril> anyone knows how do per-muxer avoptions work?
[08:32:40] * wbs knows
[08:32:58] <kshishkov> pJok: you can encapsulate asf in mov, but I've not seen avi-in-mov yet :(
[08:33:13] <Tjoppen> wait - ffmpeg displays muxer avoptions without them being usable?
[08:33:27] <cartman> is there a way to check the validity of an RGB565 data?
[08:33:30] <elenril> wbs: how do i use them?
[08:33:38] <wbs> Tjoppen: they're usable, there just aren't any muxers using them yet
[08:34:00] <Tjoppen> ah, I see
[08:34:03] <wbs> elenril: as in, how do you add options to your muxer?
[08:34:26] <elenril> yes
[08:34:43] <elenril> and how do i check if the option is set
[08:35:02] <pJok> kshishkov, ah yes, it was asf that flip4mac put into mov
[08:35:17] <wbs> add a "const AVClass *class"; as the first member of the priv data struct, set the .priv_class field in AVOutputFormat for the  muxer
[08:35:47] <wbs> and in the AVClass that .priv_class points to, list AVOptions that can set fields in the priv data struct
[08:36:00] <DonDiego> kshishkov: what about those patches you wanted to send? :)
[08:36:10] <wbs> the http urlprotocol does something similar, you can have a look at that
[08:36:37] <wbs> and if they're set, the fields in the priv data struct are initialized with the desired value that the options set
[08:36:54] <cartman> anyone?
[08:37:10] <wbs> cartman: any data is valid rgb565 data
[08:37:28] <cartman> wbs: hmm
[08:37:50] <cartman> so I guess I should at least see a picture
[08:38:40] <elenril> wbs: thanks, i'll try that
[08:39:02] <cartman> wbs: any idea why glTexImage2D would return error code 0x31 ?
[08:39:06] <Tjoppen> calculate the energy of each plane and make sure they're within "reasonable" values?
[08:39:08] <kshishkov> DonDiego: send me some time first
[08:39:17] <Tjoppen> like "not too flat, not too random"
[08:39:41] <Tjoppen> but in general -> ocular inspection
[08:40:01] <av500> kshishkov: what are you using your 20% time for?
[08:40:12] <pJok> kshishkov, is ffmpeg finally getting demuxer chaining?
[08:40:52] <wbs> cartman: uhm, glTexImage2D returns void? ;P
[08:41:04] <wbs> cartman: do you mean what glGetError() returns afterwards?
[08:41:14] <cartman> wbs: yup
[08:41:19] <cartman> wbs: lots of 0x31 :/
[08:41:46] <cartman> wbs: I am passing a uint8_t* RGB data with GL_UNSIGNED_SHORT_5_6_5 type
[08:41:50] <wbs> 0x31 doesn't seem like a valid gl error code to me, they seem to either be 0 for no error, or 0x500 -> for normal errors
[08:42:11] <cartman> wbs: wonder if glGetError() call is fucked up then :D
[08:42:25] <cartman> GLint error;
[08:42:26] <cartman> 	for (error = glGetError(); error; error = glGetError())
[08:42:26] <cartman> 		LOG("after %s() glError (0x%x)\n", op, error);
[08:42:30] <cartman> looks correct though
[08:42:42] <wbs> looks right to me, too
[08:42:50] <wbs> what does your glTexImage2D line look like?
[08:43:10] <kshishkov> av500: 1) I'm not working at Google 2) You're supposed to have left - Michael had used word "leader" once again in mail
[08:43:12] <wbs> and sure you didn't have that error before calling glTexImage2D too?
[08:43:17] <cartman> wbs: http://ffmpeg.pastebin.com/raw.php?i=V5QZtzqb
[08:43:41] <cartman> wbs: yep sure,
[08:43:50] <cartman> other GL operations check for error too
[08:44:11] <wbs> cartman: well that looks right to me. sure that you've initialized the texture object and bound it prior to that? ;P
[08:44:43] <cartman> wbs: http://ffmpeg.pastebin.com/raw.php?i=pJ7i650Z
[08:44:44] <cartman> :D
[08:45:08] <wbs> cartman: looks ok to me
[08:45:22] <cartman> wbs: ok then should look for TEXTURE_WIDTH etc.
[08:45:37] <cartman> wbs: must be a power of 2 right?
[08:45:41] <spaam> is this #opengl? :D
[08:45:47] <cartman> spaam: yep
[08:45:47] <cartman> :P
[08:46:01] <cartman> spaam: working on FFmpeg indirectly :P
[08:46:15] <elenril> where is AVClass defined?
[08:46:21] <wbs> elenril: avutil somewhere
[08:46:24] <elenril> i seems to fail at grepping
[08:46:56] <elenril> ah, found it
[08:47:19] <spaam> cartman: ok ;) so #ffmpeg-opengl
[08:47:32] <cartman> spaam: yup
[08:47:36] <astrange> non power of 2 textures are allowed recently
[08:47:53] <cartman> astrange: uhm this is OpenGL ES 2 I think
[08:47:56] <cartman> how recently? :D
[08:47:57] <wbs> cartman: in ES2 it shouldn't be required
[08:48:09] <cartman> wbs: oh
[08:48:31] <cartman> then why the heck this call would return an error :(
[08:49:14] <astrange> ARB_texture_non_power_of_two, probably mandatory in 3.2 and es2
[08:49:25] <cartman> astrange, wbs thanks
[08:49:25] <astrange> either that or mandatory not in es2. i forget which
[08:50:09] <cartman> that will simplify the code
[08:50:46] <peloverde> hmm, something is still off, i'm still seeing a segfault in gstreamer and no output in quicktime
[08:51:27] <cartman> astrange: Google confirms you ;-)
[08:51:45] <cartman> kind of :P
[08:51:58] <kshishkov> peloverde: I'm not sure you're supposed to use M$ ADPCM in mov at all, hence official QT confusion
[08:52:11] <av500> does IMA adpcm work in mov?
[08:52:18] <av500> or is it AAPL ADPCM only?
[08:52:27] <peloverde> kshishkov: it's explicitly listed as allowed in the QTFF spec
[08:52:38] <av500> BBB: btw, the guy that hired you steps down now...
[08:53:11] <cartman> av500: cashing out like crazy too
[08:53:37] <kshishkov> peloverde: what kind of ADPCM is it exactly?
[08:53:46] <peloverde> -acodec adpcm_ms
[08:53:57] <av500> the 3-5 bit variant
[08:54:05] <peloverde> aka Microsoft ADPCM-ACM code 2
[08:54:15] <kshishkov> av500: he said they need no more of his adult supervision, probably because of BBB being hired
[08:54:32] <kshishkov> peloverde: it needs extradata
[08:54:36] <peloverde> DVI/Intel IMAADPCM-ACM code 17 is also allowed
[08:54:43] <peloverde> kshishkov: it has extradata
[08:55:39] <kshishkov> can FFmpeg play it?
[08:55:51] <peloverde> yes
[08:55:53] <peloverde> so can VLC
[08:56:06] <peloverde> (which couldn't play it before)
[08:56:37] <kshishkov> is "wave" atom present?
[08:56:42] <peloverde> yes
[08:57:07] <peloverde> and the extradata is in an ms$0$2 atom just like the file generated by quicktime
[08:57:48] <kshishkov> so can you print both files' structure and compare them?
[08:58:20] <peloverde> that's what I'm working on now
[08:59:18] <av500> peloverde: so you dropped AAC to work on ADPCM? :)
[08:59:28] <peloverde> hmm, only stereo seems to be broken
[08:59:35] <peloverde> just like AAC
[08:59:52] <kshishkov> peloverde: it's your karma then ;)
[08:59:59] <av500> stereo is dead, most phones have only 1 speaker...
[09:00:31] * kshishkov writes a patch for dropping stereo wavpack support
[09:01:08] <peloverde> anyone with QT (pro?) on a mac willign to make a stereo file for me?
[09:01:15] <wbs> peloverde: sure
[09:03:49] <wbs> qt pro doesn't seem to have any ms-adpcm codec out of the box at least, only their own IMA 4:1
[09:04:08] <peloverde> yesterday astrange remuxed a wav
[09:04:31] <kshishkov> probably you need qtpro for windows for that
[09:04:44] <kshishkov> and old version of it too
[09:04:52] * pJok tries qt pro on his windows
[09:04:53] <peloverde> I do have qt pro for windows
[09:06:19] <pJok> AAC, AMR-NB, ALC, IMA, PureVoice and iLBC are the only options i have
[09:06:52] <peloverde> pJok: that's all i have too
[09:07:17] <peloverde> crap I'm double natted and can;t seem to connect to FTP
[09:08:15] <peloverde> wbs: do you have an audio passthrough option?
[09:09:33] <wbs> hmmm, I remember seeing something such somewhere, but can't seem to find it now
[09:09:55] <wbs> (I'm looking in the qt player 7 "export" dialog, with the preset "Movie to QuickTime Movie")
[09:12:31] <wbs> hah, found it
[09:12:46] <wbs> http://albin.abo.fi/~mstorsjo/msadpcm.mov
[09:13:13] <wbs> if choosing "movie to hinted movie", it won't transcode anything, just remux.. and you can uncheck the actual hinting
[09:13:54] <peloverde> cool
[09:13:56] <peloverde> thanks
[09:15:43] <astrange> Save As is remux
[09:15:51] <astrange> it's difficult to reencode video and remux audio
[09:17:28] <wbs> ah
[09:17:49] <cartman> http://people.xiph.org/~xiphmont/demo/ghost/demo.html btw
[09:19:12] <peloverde> figuring out what's differnet about these files will be a task for tomorrow
[09:19:15] <peloverde> good night yall
[09:19:19] <av500> ffghostenc
[09:21:59] <peloverde> ffhowdowecashinonthepilesofmoneythatredhatandmozillashovelatxiph
[09:23:31] <av500> use the money to patent vorbis maybe :)
[09:24:06] <peloverde> we've not 'free' enough to get xiph style money and we aren't proprietary enough to get on2 style money... some sort of local minimum
[09:24:20] <cartman> peloverde: who is "we" ?
[09:24:21] <kshishkov> "First and foremost, Ghost is vapourware." <- one doesn't need to read further
[09:24:42] <kshishkov> cartman: FFmpeg
[09:24:57] <cartman> kshishkov: ah
[09:25:28] <av500> peloverde: we are screwed(tm) :)
[09:26:11] <kshishkov> av500: weKnow(tm)
[09:26:44] <av500> wiiKnow
[09:27:08] <kshishkov> av500: FFmpeg does not belong to Nintendo
[09:28:05] <av500> kshishkov: mabye it should
[09:28:09] <thresh> ..yet
[09:28:27] <peloverde> Make it so!
[09:31:35] <kshishkov> FFmario + FFzelda should fix that
[09:32:12] <av500> kshishkov: 1st game we should release is a 1st person shouter
[09:32:39] <kshishkov> and 3rd person bikeshedder
[09:37:07] <saintdev> lol
[09:37:23] <kshishkov> it should be quite popular genre out here
[09:38:34] <thresh> one should ask blizzard to add 'bikeshedder' class to diablo3
[09:38:41] <wbs> I do think some more clarifications regarding the "new maintainers" should be posted... e.g. http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2011-January/010100.html
[09:42:12] <astrange> CELT is rather good, i wonder if there's room for ghost to be better than it
[09:42:29] <kshishkov> not for coding speech, at least
[09:43:22] * av500 watches ghost in the celt
[09:43:58] <Dark_Shikari> astrange: ghost can be better with more latency and larger packet sizes
[09:44:04] <Dark_Shikari> the largest celt packet size is still tiny
[09:44:14] <Dark_Shikari> celt has to worry a lot about the size of side information
[09:44:18] <Dark_Shikari> also celt is designed for error resilience
[09:44:22] <Dark_Shikari> so they throw out a lot of possible inter prediction
[09:44:28] <Dark_Shikari> esp. entropy coder inter prediction
[09:44:31] <Dark_Shikari> e.g. contexts based on past frames
[09:47:44] <vipw> wbs: are there any plans to support encryption in http live streaming?
[09:48:28] <wbs> vipw: patch welcome I guess, I haven't run into any such and I've mostly skipped over those parts in the specs
[09:48:30] <kshishkov> Dark_Shikari: have you made any contributions to CELT spec?
[09:56:55] <DonDiego> ogg anyone? reimar is pinging patches...
[09:57:23] <Dark_Shikari> no
[09:57:28] <Dark_Shikari> I'm not an audio guy
[09:58:18] <kshishkov> Dark_Shikari: you're better than me
[09:58:50] <pJok> kshishkov, bink audio encoder?
[09:59:10] <kshishkov> pJok: only when Dark_Shikari finished Bink video encoder
[09:59:24] <saintdev> pJok: only if it's 1/2 the quality of the aac encoder
[09:59:31] * saintdev hides
[10:00:22] <kshishkov> saintdev: yes, it sports this wondeful property of stereo encoding having half quality of mono encoding
[10:03:17] <peloverde> anyone have usac RM9? they are doing a better job of hiding it
[10:03:46] <kshishkov> whut?
[10:03:51] <av500> +1
[10:04:06] <peloverde> USAC Reference Model 9
[10:04:13] <peloverde> came out today
[10:05:11] <peloverde> The only place I know where to find it is MPEG SVN and I don't have an MPEG SVN account
[10:06:59] <kierank> ask zmgorynch
[10:07:45] <kshishkov> kierank: sounds like totally Russian nick
[10:07:59] <kierank> he's israeli i think
[10:09:56] <kshishkov> kierank: there's one country that provided half of their Jews and "Jews", guess its name
[10:10:07] <peloverde> so it's just like my day job
[10:12:02] <kshishkov> peloverde: does it have something to do with MPEG Surround and its claimed 48k per 5.1 stream
[10:12:29] <peloverde> usac can use mpeg-surround for multichannel
[10:12:39] <peloverde> mpeg surround low bitrate mode is just generalized PS
[10:13:04] <kshishkov> not generalised enough - it still codes real audio even in downmix
[10:13:38] <peloverde> huh?
[10:14:22] <kshishkov> generalised PS would produce any number of channel from zero audio input (like SAOL does)
[10:14:47] <peloverde> PS is always 2:1
[10:14:57] <peloverde> MPEG surrround is N:M
[10:15:08] <peloverde> where N and M != 0
[10:15:19] <kshishkov> iKnow
[10:15:24] <peloverde> there is no Parametric synthesis in PS
[10:15:36] <kshishkov> but somehow I dislike that idea
[10:15:49] <kshishkov> and I consider DTS Neo6 to be stupid idea as well
[10:15:57] <peloverde> you don't even get a decorated signal without a non-zero input signal
[10:16:33] <peloverde> MPEG surround non 2:1 is dumb because PS is really only useful as placebo stereo
[10:17:44] <cartman> "Add --nomru switch
[10:17:47] <cartman> heheh
[10:18:04] <kshishkov> where?
[10:18:18] <cartman> MacVim , mru = most recently used :D
[10:18:46] <kshishkov> that's why mru doesn't use either Mac nor Vim
[10:18:59] <cartman> serves him right :P
[10:20:14] <thresh> he uses PPP probably though
[10:20:48] <kshishkov> pppoe
[10:21:00] <elenril> wbs: are per-muxer options supposed to show in help somewhere?
[10:21:01] <kshishkov> simple PPP is for Russians
[10:21:10] <wbs> elenril: yes
[10:21:29] <elenril> ah, here it is MP3 muxer AVOptions:
[10:21:41] <elenril> but nothing else
[10:21:49] <elenril> i guess i didn't add something somewhere
[10:22:02] <wbs> then you apparently has set the priv class properly, but not added the avoptions to the class
[10:22:28] <elenril> the options are there
[10:22:41] <elenril> i mostly coped that from http
[10:22:56] <av500> #endif comments are mandatory?
[10:23:37] <cartman> av500: they are lame
[10:24:06] <cartman> unless there is an ifdef jungle
[10:25:22] <j-b> 'morning
[10:25:28] <elenril> wbs: http options don't show in help either
[10:26:06] <wbs> elenril: no, the urlprotocol options aren't hooked up to the ffmpeg.c frontend
[10:26:06] <j-b> was this an ifdef jungle?
[10:26:26] <elenril> oh
[10:26:33] <elenril> they probably should be, no?
[10:29:00] <wbs> elenril: probably in the future, but that wasn't necessary at the time, they were useful in order to set up some private options used by the rtsp code
[10:29:42] <wbs> elenril: or mostly to be able to first allocate the urlprotocol without opening it, then set some options, then proceed with opening it
[10:29:56] <av500> I only have to go down the road for ffosdem: http://www.flickr.com/photos/av500/5375127868/
[10:30:23] <elenril> wbs: am i missing something obvious here? http://pastebin.com/gRKZwUrg
[10:30:43] <thresh> this looks shopped, no snow
[10:30:58] <av500> elenril: what, no v1 support?
[10:31:11] <wbs> elenril: no, looks just right to me
[10:31:14] <av500> ah, its id3v2 version...
[10:31:15] * elenril stabs av500 
[10:31:24] <av500> it should be iv3 version
[10:33:34] <kshishkov> av500: you mean it should be set in metadata property "version" of file metadata?
[10:33:51] * elenril meta-stabs kshishkov 
[10:34:40] <av500> cartman: a ffreind? :)
[10:35:08] <cartman> av500: we can work it out
[10:35:09] <cartman> :P
[10:35:44] * av500 presses cartman's like button
[10:36:20] <mru> moin
[10:36:28] * cartman selects a better buddy icon
[10:36:28] <av500> hi mru
[10:36:43] <cartman> lo mru
[10:36:49] <mru> z all
[10:37:08] <av500> nc the rest
[10:37:19] <wbs> elenril: ah, yeah - you need to set AV_OPT_FLAG_ENCODING_PARAM in the flags field
[10:37:28] <wbs> elenril: otherwise ffmpeg.c won't list it (and probably won't set it either)
[10:37:31] <cartman> mru: I am nearly getting frames! :)
[10:37:57] <wbs> elenril: getting that committed would be good, to get a full working example of it in place
[10:38:22] <av500> wbs: no way, the final endif lacks a comment
[10:38:34] <cartman> mru: I have one last (no kidding) problem
[10:38:35] <wbs> av500: :-(
[10:40:17] <cartman> mru: I added neon_pixconv.S add a pixconv driver, but it claims it can't open PIX_FMT_YUV420P which is my dp->pixfmt
[10:40:52] * mru not parse
[10:41:18] <cartman> mru: so I added neon_pixconv.S to my source list to use it as a pixel converter
[10:41:36] <kshishkov> cartman: have you added DRIVER() in C thingie for it?
[10:41:50] <cartman> mru: And I set dp->pixfmt to PIX_FMT_YUV420P in driver's _open method
[10:41:53] <mru> it only does 420p to 422/nv12
[10:42:02] <cartman> kshishkov: I think its not needed
[10:42:20] <mru> if you set the display format to 420p, no conversion is necessary
[10:42:37] <cartman> mru: yeah I think the code in omapfbplay should be changed
[10:42:50] <cartman> mru: it looks for a pixconv if the driver has no memman routine
[10:43:04] <mru> that is correct
[10:43:06] <cartman> mru: it shouldn't need one if frame format and display format is the same
[10:43:33] <mru> if the driver has no memman, you need at least a null pixconv, aka memcpy
[10:43:46] <cartman> mru: ah...
[10:43:49] <mru> but memcpy is evil, so there is no such pixconv
[10:43:59] <mru> think about it
[10:44:07] <mru> if the driver has no memman, malloc is used
[10:44:41] <mru> but then without a "pixconv" how would the images move from the malloc buffer to the display buffer?
[10:45:06] <av500> magic
[10:45:22] <mru> that magic is callid display->memman
[10:45:26] <mru> called
[10:45:32] <cartman> mru: long story short I need a memman even malloc based one.
[10:45:45] <mru> no
[10:45:45] <cartman> a basic*
[10:46:03] <cartman> mru: you just called memcpy evil :)
[10:46:04] <mru> if you can provide buffers suitable for decoding directly into, you should have a memman
[10:46:56] <cartman> but I my case I ask for PIX_FMT_YUV420P data
[10:47:01] <cartman> there is no need for a conversion
[10:47:18] <mru> can you provide direct rendering buffers?
[10:47:35] <cartman> mru: don't know what that means :/
[10:47:47] <mru> buffers the decoder can use directly
[10:48:07] <cartman> before usable I have to do a YUV->RGB
[10:48:16] <mru> this means they must have 16-byte aligned stride and reside in cached memory
[10:48:46] <mru> if you need to convert to rgb, you obviously can't do direct rendering
[10:48:53] <mru> so you need a yuv to rgb pixconv
[10:49:03] * elenril thinks we have too many "convert string between utf16<->utf-8" functions
[10:49:08] <cartman> ah thats what my colorconvert.c does
[10:49:11] <elenril> doesn't posix define something for this?
[10:49:13] <cartman> so it needs to be a pixconv
[10:49:19] <cartman> mru: thanks
[10:49:35] <mru> elenril: http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
[10:49:36] <av500> elenril: funny thing is, here is $work, its the same :)
[10:50:01] <mru> but iconv is overkill for converting between utf variants
[10:50:11] <av500> yep
[10:50:20] <kshishkov> and it doesn't support utf-9
[10:50:24] <cartman> mru: with a pixconv in place I don't have to do it driver's _prepare myself, right?
[10:50:39] <mru> kshishkov: is that some pdp encoding?
[10:50:55] <av500> its utf8 with a blink bit
[10:51:00] <mru> you should call pixconv->convert() in your prepare()
[10:51:07] <cartman> mru: ah true :)
[10:51:14] <kshishkov> mru: http://tools.ietf.org/html/rfc4042 it even features PDP asm
[10:51:16] <cartman> back to the coding then
[10:51:19] <cartman> thanks
[10:51:48] <av500> kshishkov: note the date
[10:53:05] <wm4> does anyone know the status of mp3 patents?
[10:53:17] <wm4> eh, I should ask in #ffmpeg, sorry
[10:53:24] <kshishkov> av500: 21st of January - national hug day in USA
[10:53:29] <mru> wm4: I'm sure sisvel has on opinion
[10:53:29] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r2611e52088 ffmpeg/libavcodec/dcadata.h:
[10:53:29] <CIA-29> ffmpeg: dca: pretty-print some tables
[10:53:29] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[10:53:52] <av500> wm4: peloverde had a chart/list
[10:54:05] <av500> but some are still valid
[10:54:41] <wm4> ah
[10:55:16] <av500> and new ones pop up all the time: http://fosspatents.blogspot.com/2010/12/hybrid-audio-llc-sues-apple-htc-and.html
[10:55:53] <wm4> how can new patents pop up, they'd all be invalid due to prior art?
[10:56:06] <mru> that's not how patents work
[10:56:16] <av500> Filed: 	February 25, 1997
[10:56:19] <mru> _anything_ can be patented
[10:56:32] <wm4> wat
[10:56:57] * av500 has a patent on saying "wat" on irc, sues wm4
[10:57:13] <kshishkov> it's Texas-based company and I suspect court will be held in South Texas as well
[10:57:22] * wm4 patented breathing and doesn't give av500 a license
[10:57:37] <mru> it's also possible to file a patent and then keep it from being approved indefinitely by filing minor amendments once in a while
[10:57:46] <av500> aka submarine patents
[10:57:58] <mru> then, when everybody thinks they're safe, you activate it
[10:58:00] <wm4> how is it possible that patents are valid, even though there's prior art? are these just courts bullshitting and not following the rules or what?
[10:58:05] <mru> and _that_ is when the 20 years start counting
[10:58:19] <mru> wm4: there's a lot of that too
[10:58:20] <av500> wm4: because checking prior art is :effort:
[10:58:31] <mru> kshishkov: eastern district of texas
[10:58:41] <av500> and proving a patent in invalid is :big effort:
[10:59:01] <kshishkov> av500: only when it's really invalid
[10:59:01] <mru> av500: although the success rate is very high when attempted
[10:59:03] <wm4> another question, are these patents about decoding, encoding, or both?
[10:59:08] <av500> both
[10:59:30] <av500> mru: yes, but most ppl settle out of court as this is cheaper :)
[11:00:12] <miasma> av500: so is there any estimated date when all mp3 (decoding) patents have really expired. no one knows?
[11:00:13] <wm4> conclusion: mp3 won't be free even after 2012?
[11:00:38] <mru> miasma: yes, it's expected they'll all be gone by year 2600
[11:00:43] <miasma> :DDD
[11:00:43] <av500> miasma: I lost track of when what expires
[11:00:56] <miasma> it's also strange that apparently they can also patent container formats
[11:01:06] <miasma> but the container is just a simple data definition
[11:01:11] <mru> miasma: _anything_ can be patented
[11:01:14] <av500> or a simple steel box
[11:01:19] <mru> or a rock
[11:01:24] <miasma> it's almost like "buy milk, sausage, yoghurt"
[11:01:29] <wm4> could they patent something that makes e.g. Vorbis suddenly "unfree"?
[11:01:33] <astrange> i think i saw someone patenting sticks
[11:01:34] <mru> oh yes
[11:01:40] <av500> wm4: no need
[11:01:44] <mru> astrange: yes, it was on HN a while ago
[11:01:55] <wm4> av500: ???
[11:01:55] <av500> wm4: M$ has nice patents on the stuff used in vorbis
[11:02:03] <wm4> oh.
[11:02:09] <mru> of course someone has patents on it
[11:02:15] <kshishkov> av500: patent "use of Xiphophorus fishes in open technologies promoting process"
[11:02:19] <mru> anything of that complexity is bound to touch a few patents
[11:02:34] <av500> vorbis is "patent-free" by fiat
[11:02:43] <wm4> does that mean there's no point in developing "patent free" technologies like xiph does?
[11:02:48] <mru> yes
[11:03:09] <mru> it's actually much safer to use codecs licensed by mpeg-la
[11:03:14] <kshishkov> BTW, how we got to http://www.webmproject.org/about/supporters/ ?
[11:03:15] <miasma> xiph has specialized on advanced container formats like ogg =D
[11:03:21] <mru> there at least most of the patent holders have come forward
[11:03:49] <mru> advanced, thereis lies the problem
[11:03:54] <mru> containers should be simple
[11:04:09] <wm4> this patent stuff is so full of fucking bullshit, it's like a license for lawyers to go crazy
[11:04:20] <mru> why do you think it was invented?
[11:04:49] <wm4> erm... to facilitate development of technology and open standards?
[11:05:00] <mru> lol
[11:05:09] <wm4> but that's what THEY say
[11:05:31] <av500> wm4: in a way yes, the only thing that they missed is that internet years are like dog years, so 20ys should be 3 for the protection period...
[11:05:55] <mru> 3 days
[11:06:21] <mru> actually, 3 years would be acceptable at least for codecs
[11:06:34] <lyakh> so, got a report from sh4-fate... anyone wants it?
[11:06:36] <mru> h264 is still king of video and it's much older than that
[11:07:01] <av500> lyakh: what does it say`
[11:07:03] <av500> ?
[11:07:07] <mru> lyakh: thanks, but manually passing reports around isn't practical
[11:07:16] <mru> lyakh: did anything fail though?
[11:07:44] <av500> lyakh: you can hand a printed report to mru at fosdem :)
[11:07:47] <lyakh> av500: how do I know? some base64-encoded stuff. or you mean in test.log?
[11:08:00] <superdump> kshishkov: because of developing a vp8 decoder and having webm support in our matroska demuxer i would guess
[11:08:01] <mru> I'll "borrow" av500's sh4 and set it up to run continuously
[11:08:12] <mru> lyakh: test.log will show if there are any errors
[11:08:24] <mru> the base64 stuff isn't much fun to read manually
[11:08:45] <av500> mru: I think *you* can even do that
[11:09:14] <mru> I've been known to read mpeg streams in hex
[11:09:41] <av500> 0x47
[11:10:21] <lyakh> so, nothing that I would interpret as an error...
[11:10:25] <mru> sync_byte
[11:10:34] <elenril> so: id3v2.3 supports only UTF-16; id3v2.4 supports also UTF-8.
[11:10:50] <elenril> anybody can think of a reason not to use UTF-16 in both cases?
[11:11:09] <lyakh> anyway, since mru will set up a periodic one, I can dismiss mine;)
[11:11:11] <mru> lyakh: does test.log consist mostly of "TEST foo" lines?
[11:11:21] <lyakh> mru: yes
[11:11:35] <mru> good
[11:11:40] <lyakh> what would it have if there were errors?
[11:11:59] <mru> can you post that file somewhere?
[11:12:03] <mru> that's simpler
[11:14:46] <lyakh> http://download.open-technology.de/fate-sh4/test.log
[11:18:07] <mru> lyakh: squeaky clean
[11:18:17] <lyakh> good, thanks
[11:19:13] <mru> so those fixes I made a couple of years ago and tested on qemu after fixing _it_ seem to work
[11:21:19] * elenril wonders why aren't avio.h functions prefixed with av/ff
[11:22:10] <mru> because nobody bothered to add them
[11:22:19] <mru> a patch would be very welcome
[11:23:13] <elenril> so i should add an av_ if i'm adding a new one
[11:23:33] <Tjoppen> and a major version check perhaps
[11:23:47] <mru> depends on whether it's meant to be used externally
[11:23:57] <mru> Tjoppen: yeah, unfortunately
[11:23:57] <Tjoppen> isn't avio.h installed?
[11:24:02] <elenril> it's an installed header
[11:24:09] <Tjoppen> yep
[11:24:15] <Tjoppen> lunch
[11:24:18] <mru> there are probably some functions in there that shouldn't be exported
[11:24:29] <mru> and thus should have ff_ prefix
[11:24:44] <pJok> mru, is someone btw going to add the android ndk to fate as well?
[11:25:09] <elenril> this one converts&writes an utf8 strings as utf-16
[11:25:09] <av500> mru: I can donate an N1 to run fate
[11:25:09] <mru> pJok: that's a scary thought
[11:25:36] <mru> do android phones have nfs and ssh?
[11:25:46] <av500> but only if we publish a fate.apk on the market :)
[11:25:57] <av500> mru: rooted ones have what you want I guess
[11:26:04] <pJok> mru, yes, but seeing as people try to compile ffmpeg for the iphone all the time and probably also for android it would make sense to have them on there
[11:26:30] <mru> it would, but when the vendors try their best to make testing impossible...
[11:27:11] <pJok> apple yes
[11:27:13] <pJok> htc not so much
[11:27:32] <pJok> most of their handsets are now one touch root on mac and linux
[11:27:45] <pJok> windows does require a driver install first
[11:27:59] <mru> android is still a huge pita
[11:28:51] <elenril> should i make LE/BE a flag or create two versions?
[11:29:05] <pJok> and for nfs, if the samples are downloaded onto the sd card, nfs shouldn't be needed, i guess?
[11:31:22] <pJok> av500, making a fate.apk would require someone to do some java coding ;)
[11:31:23] <mru> nfs is still needed
[11:31:30] <mru> or some kind of shared fs
[11:33:16] <lu_zero> a shared fs or a way to do I/O ?
[11:33:32] <av500> nfs seems to work at least on rooted phones
[11:33:33] <mru> with the current design a shared fs is required
[11:33:45] <av500> or cifs
[11:33:50] <wbs> I tried doing some hack on the test process in order to call commands for transferring files back and forth.. it was ugly, and adb randomly stuck on like 1/100 of the executions
[11:34:05] <av500> mru: in fact we can use on of our products as well
[11:34:23] <av500> a debug build is rooted already and I can add all needed kernel drivers
[11:34:27] <lu_zero> av500: ready to put a fate on your nifty tablets?
[11:34:33] <av500> why not
[11:34:50] <av500> but they are wifi only
[11:34:55] <kshishkov> mru: at least your phone is worth the price you payed for it
[11:35:03] <av500> unless we add usb2eth as well
[11:35:35] <pJok> av500, isn't really a bad idea, using a tablet for fate instead of an N1 ;)
[11:36:28] <av500> pJok: I can work on making one that does usb2eth and nfs
[11:36:35] <av500> and ssh
[11:37:07] <pJok> av500, exactly... another target for FATE \o/
[11:37:18] <av500> but its 2.2 only atm
[11:37:26] <kshishkov> av500: you can release it with model number in hexadecimal then
[11:37:30] <av500> with 2.3 I guess the NDK changes
[11:37:47] <pJok> av500, just have the targets that are possible?
[11:38:01] <av500> ?
[11:38:11] <pJok> as in, if you only have 2.2, then do 2.2
[11:38:19] <av500> sure
[11:38:19] <pJok> you can always add 2.3 later?
[11:38:52] <av500> we will have 2.3 runnig stuff soon
[11:39:00] <thresh> 3.0? :)
[11:39:21] <pJok> thresh, 2.4 will be the next newfangled thing afair
[11:39:32] <av500> thresh: can u ask you friends to get me 3.0 source code?
[11:39:52] <thresh> av500: i will bring you the cd with it
[11:39:57] <av500> thx
[11:40:23] <av500> thresh: bought at moscow street corner?
[11:40:45] <thresh> av500: where else
[11:41:31] <av500> I always thought stuff bought there had much nicer security holograms that the M$ ones... :)
[11:42:46] <cartman> mru: can my pixconv's _convert be something like (uint8_t *vdst, uint8_t* vsrc[3]) ?
[11:42:55] <cartman> mru: since my dst is a uint8_t* buffer
[11:45:00] <mru> the convert has to have whatever prototype the struct definition says
[11:45:14] <cartman> mru: ok
[11:46:10] <av500> cartman: since its you that will consume the converted buffer, you can ignore the other 2 components
[11:46:22] <cartman> av500: guessed so :) thanks
[11:46:29] <mru> no such dirty hacks
[11:46:35] <cartman> why?
[11:46:37] <av500> ?
[11:46:44] <mru> obviously only the dst[0] is used for packed formats
[11:46:53] <av500> thats what I meant
[11:46:57] <cartman> yeah
[11:46:57] <mru> oh
[11:47:02] <cartman> only use the 1st element :D
[11:47:18] <mru> and you'll only be using the virtual address pointers
[11:47:23] <av500> mru: I dont do dirty hack *all* day long
[11:47:32] <mru> anyway, I'm off to troll some old workmates over lunch
[11:47:36] <cartman> :D
[11:47:38] <av500> have fun
[12:10:38] <elenril> ok, anybody here with windows 7 or some other id3v2.3-only reader?
[12:11:50] <kshishkov> windows 7 actually does something?
[12:12:20] * elenril heard it show a picture of hitler
[12:12:23] <elenril> *shows
[12:12:34] <kshishkov> yep, XKCD proved that
[12:12:39] * elenril pokes Kovensky 
[12:12:50] * elenril also pokes JEEB 
[12:13:03] <wbs> elenril: did you get the avoption working?
[12:13:20] <elenril> yep
[12:13:23] <wbs> nice
[12:13:25] <elenril> the flag did it
[12:13:33] <elenril> at least i hope
[12:13:38] <elenril> now i need to test it
[12:20:16] <DonDiego> $dayjob daily WTF:
[12:20:19] <DonDiego> 	$(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS) \
[12:20:19] <DonDiego> 		-DKERNELVERSION="\\\"\\\"\\\"$(LINUX_VERSION)\\\"\\\"\\\"" -DVERSION="\\\"\\\"\\\"8.4.1\\\"\\\"\\\"" \
[12:20:19] <DonDiego> 		-DPPPD_VERSION="\\\"\\\"\\\"2.4.3\\\"\\\"\\\"" \
[12:20:19] <DonDiego> 		-std=gnu99 -fPIC" LDFLAGS="$(TARGET_LDFLAGS)" \
[12:20:19] <DonDiego> 		$(MAKE) -C $(PKG_BUILD_DIR)/pppd_plugin/src/
[12:20:33] <elenril> ASCII art?
[12:20:37] <DonDiego> welcome to backslash hell
[12:21:06] <DonDiego> but it does generate valid C strings, they just look slightly weird with """ around them instead of "
[12:23:37] <Kovensky> 09:12.39 elenril pokes Kovensky <-- you know I'm on osx =p
[12:23:40] <Kovensky> (the windows hdd is bust)
[12:23:55] <elenril> you said something about id3v2.3-only player
[12:25:51] <elenril> you don't have it anymore?
[12:26:26] <av500> elenril: what do you need?
[12:26:36] <av500> win7?
[12:26:51] <royger> hello
[12:26:55] <elenril> av500: yes
[12:27:03] <elenril> or anything that can only read id3v2.3
[12:27:14] <av500> I have win7, no idea what it can read
[12:27:22] <av500> but i can try your file
[12:27:26] <av500> i guess you mean wmplayer
[12:27:28] <elenril> try ftp://ftp.khirnov.net/out.mp3
[12:27:32] <elenril> no, i mean explorer
[12:27:40] <av500> oh ok
[12:27:45] <av500> after lunch
[12:27:48] <kierank> royger: hello
[12:28:00] <royger> When encoding mpeg2 video, inside the MPV_decode_mb_internal function is there anyway to know the number of DCTELEM blocks of a frame?
[12:28:53] <royger> and possibly the position of the block that I'm currently processing
[12:31:22] <royger> I've took a look at the MpegEncContext structure, but I can't find it anywhere
[12:31:42] <cartman> mru: is it correct that sysmem.c doesn't have OFBP_PHYS_MEM flag?
[12:31:51] <cartman> but I guess its still launch :/
[12:32:32] <cartman> av500: feel free to answer that one :D
[12:32:36] <av500> cartman: sysmem is malloc, so virtual
[12:32:57] <cartman> av500: what does OFBP_PHYS_MEM refers to then?
[12:33:15] <kshishkov> royger: use math - there are three planes with blocks, round their dimensions up to 8, divide by 8, multiply dimensions and sum results for all three planes and you'll get it
[12:33:32] <thresh> blocks on a plane!
[12:33:50] <kshishkov> thresh: чугуниевые бомбы?
[12:34:13] <thresh> kshishkov: не смотрел "snakes on a plane"? и правильно сделал.
[12:35:11] <cartman> av500: what is really physical? directly rendering into hw overlay?
[12:35:22] <av500> yep
[12:35:27] <kshishkov> thresh: чего я только не смотрел, и это тоже не смотрел
[12:35:32] <cartman> av500: ok, thanks :)
[12:35:50] <av500> cartman: your chain should be all non_sys_mem
[12:35:56] <av500> err, non PHYS_MEM
[12:36:12] <av500> you use lavc and user space buffers
[12:36:42] <cartman> av500: yup, fixed it after you told me malloc != !physical
[12:36:54] <av500> k
[12:36:58] <av500> lunch now
[12:37:43] <royger> kshishkov: mb_num is not it?
[12:38:24] <royger> kshishkov: I just want to get the number of luminance blocks of each frame
[12:38:55] <royger> (of each I-Frame to be more exact)
[12:38:56] <kshishkov> royger: then multiply it by four since every MB is 4 luma 8x8 blocks and some chroma blocks
[12:40:09] <royger> kshishkov: and the position of the MB inside the frame, can I get it somewhere? I could use a counter, but if it is implemented somewhere else
[12:40:38] <kshishkov> s->mb_x/mb_x
[12:40:51] <kshishkov> BTW, have you tried reading comment for MpegEncContext?
[12:41:18] <cartman> I/OMAPFBPLAY( 3628): after glTexImage2D() glError (0x8252a764)
[12:41:21] <cartman> wtf :(
[12:41:35] <cartman> looks like a Windows error :p
[12:42:40] <royger> kshishkov: yes, sorry for this. At firts I through mb_num was the size in MB (MegaBytes)
[12:42:55] <royger> kshishkov: for what I saw in the comment
[12:43:59] <royger> kshishkov: but there's mb_x and mb_y and not a single comment explaining what they mean
[12:44:44] <kshishkov> should be obvious if you see they belong to macroblock layer and can guess that mb_ stands for macroblock
[12:45:31] <royger> kshishkov: yup, sorry for that. I'm not really clever anyway
[13:03:24] <Tjoppen> trying out that mxf clip wrap on the ml. for some reason only the first dv frame is decoded still
[13:03:35] <Tjoppen> *clip wrap patch
[13:04:02] <Tjoppen> even though the muxer outputs several 144000 B packets. or is this where one has to chain the dv demuxer in somehow?
[13:04:40] <lu_zero> cartman: look that error up
[13:09:14] <cartman> lu_zero: doesn't exist anywhere
[13:16:04] <lu_zero> wonderful
[13:23:45] <Kovensky> 09:23.55 elenril: you said something about id3v2.3-only player <-- yes, I had one, but it died around a year ago
[13:24:22] <kshishkov> heavy id3v2.3 poisoning?
[13:24:25] <elenril> good for you
[13:25:02] <Kovensky> hey, it was MUCH better at tagging than any other portables I've used since then!
[13:25:22] <elenril> heh
[13:25:25] <Kovensky> well, my previous one could read id3v2.4 (I think) but it didn't have japanese fonts so I just got boxes
[13:25:33] <Kovensky> and my current one doesn't even try to read tags
[13:25:40] <Kovensky> in b4 it only supports id3v1
[13:25:53] <elenril> my current one == my cellphone ignores the tags too
[13:25:57] <Kovensky> it also doesn't have japanese fonts but instead of showing the characters as boxes it shows them as squares
[13:26:00] <Kovensky> er
[13:26:03] <Kovensky> it shows them as spaces
[13:26:07] <elenril> it also ignores non-latin1 characters in filenames
[13:30:46] <elenril> how nice, we now have one ML for two projects
[13:30:52] <elenril> this will be fun
[13:31:19] <Kovensky> michael forked the antifork?
[13:32:43] <Tjoppen> so.. how many repos now?
[13:32:47] <elenril> he committed libmpcodecs to the videolan repo
[13:33:10] <kshishkov> Tjoppen: from one to infinity
[13:33:18] <elenril> wtf, why is it rebuilding the whole lavc now
[13:33:25] * elenril blames kshishkov 
[13:33:26] <Tjoppen> to infinity and beyond
[13:33:37] <kshishkov> elenril: avcodec.h was touched, perhaps
[13:33:51] <elenril> i didn't touch it
[13:33:58] <elenril> i'm not programmer enough for that
[13:34:12] <kshishkov> what have you touched then?
[13:34:20] <elenril> maybe it's avio
[13:34:37] <elenril> oh well
[13:34:47] <Tjoppen> so if I send in a patch now, once OK'd it'll get commited to ffmpeg.org while I have to manually push to videolan (since my pubkey is in that system)?
[13:34:49] * elenril loves how make -j4 no longer renders the system unusable
[13:35:05] <thresh> try -j14 then
[13:35:11] <kshishkov> Tjoppen: precis
[13:35:26] <Tjoppen> I forsee a great mess until a compromise is reached. luckily git-merge is wonderful
[13:35:55] <kshishkov> elenril: slow CPU?
[13:36:19] <elenril> kshishkov: i upgraded the memory, remember?
[13:36:29] <kshishkov> elenril: yep, and kernel
[13:37:00] <elenril> if i tried something like that before, i'd have to spend aeons in iowait
[13:37:21] <Kovensky> swappity swap
[13:38:42] <jannau> git merge is prohibited in both repos to ensure the real commit to merge commit ratio is better than 20:1
[13:39:07] <jannau> Tjoppen: it's probably easier if you commit only to one repo
[13:39:22] <elenril> or cherry-pick
[13:39:39] <jannau> if you want to commit to both please use cherry-pich -x
[13:39:42] <kshishkov> jannau: sounds a bit like Torrent tracker conditions
[13:41:43] <superdump> did i miss something or are you just talking about michael committing to videolan.org?
[13:42:37] <{V}> commit:merge ratio is important?
[13:43:29] <Tjoppen> might look a bit like a zipper otherwise I suppose
[13:43:46] <Tjoppen> commit to either repo -> pulled and merged in other?
[13:44:14] * elenril kicks politics
[13:44:25] <cartman> If I wrote raw rgb565 data to some file
[13:44:31] <cartman> is there a viewer to open it?
[13:44:38] <Tjoppen> gimp maybe?
[13:44:39] <elenril> gimp?
[13:44:45] <Tjoppen> I win :)
[13:44:54] <cartman> any extension will do? :)
[13:44:56] <Tjoppen> try the raw import thing
[13:45:28] <Tjoppen> that is, choos "raw image data" or something like that when you open a file
[13:45:30] <cartman> okies
[13:45:34] <jannau> {V}: yes, git log will be annoying if every third commit is a merge
[13:45:43] <DonDiego> http://gabucino.be/files/ffmpeg-coup.html
[13:45:55] <jannau> also there are ways to duplicate commits with git merge
[13:45:56] <DonDiego> gabu-style mindless flaming
[13:46:59] <{V}> jannau, thanks
[13:47:47] <elenril> wow
[13:47:50] <elenril> troll troll is troll
[13:49:17] <lu_zero> DonDiego: I'm still wondering
[13:51:47] <DonDiego> what is there to wonder about?
[13:52:16] <lu_zero> about the latest reply from Michael
[13:52:38] <kshishkov> DonDiego: being called "the RMS'ish shady backstabber" - is that a compliment or not?
[13:53:49] <KotH> lu_zero: -v?
[13:55:44] <jannau> 92.5k google results for "rms backstabbing", 2180 for "stallman backstabbing"
[13:56:23] <elenril> rms == root mean square
[13:56:34] <DonDiego> kshishkov: i guess that you can consider getting flamed by gabucino an accolade
[13:56:44] <lu_zero> KotH: "So myself being 24h loged on to IRC would result in you supporting that fork"
[13:56:47] <lu_zero> and my decapitation being undone?
[13:57:02] <DonDiego> lu_zero: ETOOMANYREPLIES, which one?
[13:57:53] <lu_zero> Message-ID: <20110121090347.GZ17803 at kiste2>
[13:57:55] <superdump> i was hoping for much more after michael's initial responses, but it seems he's given up on that and is lashing out
[13:58:39] <superdump> gabu has a point though - what does fabrice think about this?
[13:59:09] <DonDiego> geez
[13:59:23] <DonDiego> you're not *seriously* falling for this troll comment, are you?
[14:00:12] <cartman> Fabrice is happy hacking qemu
[14:00:20] <pJok> is Fabrice still alive?
[14:00:20] <kshishkov> superdump: should he think about that at all?
[14:00:26] <cartman> pJok: yes
[14:00:36] <pJok> i thought he was just a myth
[14:00:38] <superdump> i just meant that if fabrice expresses distaste for what we did, it seems within his power to order us off ffmpeg.org and order us to no longer use the trademark, no?
[14:00:46] <cartman> pJok: he is hacking on qemu
[14:00:59] <pJok> ah
[14:01:03] <kshishkov> superdump: so? A bikeshed by any other name...
[14:01:43] <pJok> i bikeshed for ffmpeg to be called ffbikeshed from now on
[14:01:50] <mru> superdump: yes, fabrice control the ffmpeg name
[14:02:13] <c45t> hi
[14:02:28] <kshishkov> mru: can you register bikeshed.org if possible just for lulz?
[14:02:30] * jannau has libav.org
[14:02:38] <mru> although by not actively using the trademark himself for a very long time, his claim may be weakened
[14:02:42] <c45t> I have a question regarding ffmpeg compilation, should I ask it here or on #ffmpeg ?
[14:02:55] <elenril> argh, curses
[14:02:56] <mru> kshishkov: already taken
[14:03:06] <kshishkov> mru: ffbikeshed.org
[14:03:12] <elenril> not to self: don't write two patchsets at once
[14:03:16] <DonDiego> superdump: you're falling for classic legal troll FUD - a) this is not so easy b) he has not actively meddled in ffmpeg for years, nor is there a sign he would now
[14:03:17] <mru> besides, I have enough domain names already
[14:03:23] <Tjoppen> c45t: #ffmpeg is probably better
[14:03:36] <c45t> ok, thanks
[14:04:31] <iive> cartman: i think he is not actively developing qemu either.
[14:05:20] * kshishkov refrains from mentioning not actively maintained tcc
[14:05:39] <cartman> iive: he served enough I guess :>
[14:05:55] <kshishkov> who knew he created LZEXE
[14:06:30] <DonDiego> how do i tell git to delete directories that are now empty?
[14:06:53] <DonDiego> i'm sure this will fsck up git-svn once more *sigh*
[14:07:01] <thresh> git rm dir/*
[14:07:28] <elenril> git doesn't track empty directories
[14:07:30] <jannau> DonDiego: git doesn't track empty directories
[14:07:32] <mru> DonDiego: git normally does that
[14:07:34] <thresh> ah empty
[14:08:02] <mru> git deletes directories that were emptied by git as a ressult of a commit or merge
[14:08:19] <mru> if you create a directory and don't tell git anything about it, it'll be left alone
[14:08:35] <DonDiego> i'm using git-svn at work
[14:08:37] <av500> fabrice is mostly after pi digits these days
[14:09:10] <av500> and feeding his pleosaurus
[14:09:21] <jannau> DonDiego: you want to delete a directory in svn?
[14:09:24] <kshishkov> av500: who knows, he may calculate e digits now instead
[14:09:25] <mru> DonDiego: git-svn has settings for dealing with directories
[14:09:46] <av500> kshishkov: infact, he mihgt, his coworker told me he is "secretive" atm
[14:09:47] <jannau> I think git-svn --help has a section how to do that
[14:10:00] <DonDiego> i'm afraid the dir will be left behind in the svn repo
[14:10:14] <av500> "no dir left behind"(tm)
[14:10:20] <mru> git-svn has a setting to delete empty dirs
[14:10:37] <mru> I don't remember the name, you'll have to rtfm
[14:10:52] <jannau> av500: us laws are public domain and can't have a trademark
[14:11:19] <DonDiego> jannau: —rmdir, thx for the pointer
[14:12:04] <cartman> uhm Gimp didn't open my raw rgb file
[14:12:34] <mru> gimp should be able to open raw files if you tell it exactly what they are
[14:12:49] <cartman> hum
[14:13:33] <cartman> oh yes
[14:13:41] <cartman> and we have garbage it seems :D
[14:13:49] <kshishkov> av500: you mean he has a job?
[14:14:44] <av500> kshishkov: yes
[14:14:49] <av500> at least part time
[14:16:01] <cartman> mru: now look at that, http://cekirdek.pardus.org.tr/~ismail/raw.png
[14:16:26] <av500> cartman: nice
[14:16:31] <cartman> av500: ty
[14:16:35] <Tjoppen> hrm.. gimp can only open 24 bpp?
[14:16:43] <Tjoppen> why not filter it through ffmpeg?
[14:16:46] <cartman> Tjoppen: no my output is like that :)
[14:16:53] <Tjoppen> ah, ok :)
[14:16:54] <cartman> I think
[14:16:56] <av500> cartman: you are doing it wrong
[14:16:59] <merbzt> Tjoppen: met your "boss" today
[14:17:07] <Tjoppen> yeah, I heard
[14:17:23] <cartman> av500: seems like yuv->rgb fucked up
[14:17:35] <av500> seems so
[14:17:38] <merbzt> Tjoppen: so you are here in Stockholm now ?
[14:17:46] <av500> but that part you can test outside of android
[14:18:13] <cartman> av500: maybe
[14:18:14] <Tjoppen> merbzt: yeah, but leaving in an hour :p
[14:18:33] <cartman> image dimensions look wrong too but thats possibly my bug
[14:18:36] <Tjoppen> me and a another guy from övik/umeå
[14:19:22] <merbzt> Tjoppen: how long will you work from Stockholm ?
[14:19:30] <merbzt> just this week ?
[14:19:50] <Tjoppen> well, not next week at least
[14:20:35] <cartman> av500: is there a known/unoptimized algo. for YUV420->RGB565 conversion?
[14:20:37] <Tjoppen> might be a few until next time
[14:20:40] <cartman> ie. just to check output
[14:21:02] <mru> cartman: it's a simple matrix multiplication
[14:21:12] <av500> cartman: wikipedia should have one
[14:21:13] <mru> the coeffs are defined by half a dozen specs
[14:21:15] <mru> differently
[14:21:56] <cartman> mru: do you think yuv->rgb conversion fucked up? I had a similar output with a wrong swscale call.
[14:22:09] <mru> hard to tell
[14:22:26] <av500> cartman: as said, test it offline 1st
[14:22:30] <mru> try simply replicating the y component to all rgb
[14:22:40] <mru> that should give you a b/w image
[14:22:51] <cartman> mru: how do I do that?
[14:23:07] <mru> with code
[14:23:12] <cartman> surprisingly
[14:23:17] <cartman> ;)
[14:23:25] <cartman> ok back to debugging
[14:23:30] * elenril spams the ML
[14:23:36] <cartman> elenril: yeah :P
[14:27:10] <cartman> is there a book with such algorithms like yuv->rgb?
[14:27:22] <mru> no
[14:27:23] <wbs> cartman: wikipedia
[14:27:30] <cartman> interesting
[14:27:34] <mru> but perhaps there's half a page somewhere
[14:27:34] <cartman> would be a nice book ;>
[14:27:45] <kshishkov> cartman: it's too trivial, Wikipedia covers it almost completely
[14:27:57] <av500> cartman: 1st google hit: http://www.fourcc.org/fccyvrgb.php
[14:27:59] <cartman> kshishkov: I meant for all such algos.
[14:28:07] <cartman> av500: search string?
[14:28:16] <av500> "can haz conversion"
[14:28:18] <mru> cartman: the book you're looking for is called "linear algebra"
[14:28:33] <cartman> mru: I sadly passes that class with a A- :P
[14:28:35] <av500> cartman: http://www.google.com/search?q=yuv+to+rgb
[14:28:44] <cartman> av500: yuv2rgb fail :P
[14:28:54] <av500> cartman: not all the internet is l33t
[14:29:10] <kshishkov> cartman: even I have managed to write some bits for yuv2rgb in swscaler, so you can too
[14:29:15] <lu_zero> http://ffmpeg.pastebin.com/uTcfzsZL <- should I send it?
[14:29:22] <cartman> thank you all :)
[14:29:28] <cartman> stream
[14:29:34] <cartman> streaming RTFM ;)
[14:29:38] <mru> lu_zero: kind of pointless asking that question on a public channel
[14:29:56] <kshishkov> lu_zero: go drink a cup of coffee, reread it again and finally decide
[14:30:07] <kshishkov> lu_zero: that's the best approach with such mails
[14:30:07] <lu_zero> mru: it's just a re-re-re-hash of what had been said already
[14:30:23] <mru> I don't understand line 29
[14:30:42] <kshishkov> mru: too short line buffer?
[14:30:46] <mru> try using less italian grammar
[14:31:11] <elenril> lu_zero: can you try a less agressive tone?
[14:31:24] <kshishkov> mru: it could be German grammar instead
[14:32:02] <mru> german grammar requires lookahead
[14:32:03] <lu_zero> elenril: that's another reason I wanted a review =)
[14:32:23] <av500> hmm, gabucino blog is "refreshing"
[14:32:39] <kshishkov> av500: and as good as written in Hungarian
[14:33:01] <elenril> lu_zero: the last part feels really hostile to me
[14:33:35] <mru> elenril: well, he keeps asking for clarification
[14:33:39] <mru> can't get much clearer
[14:33:56] <elenril> it can be made clearer in a less agressive way
[14:34:14] <elenril> don't know about you, but i'd really like for him to keep contributing
[14:34:19] <elenril> as improbable as that may be
[14:34:45] <kshishkov> contributing what?
[14:34:53] <royger> kshishkov: sorry to ask another dumb question, but why is MPV_decode_mb_internal called two times during decoding with the same block as parameter?
[14:35:11] <{V}> kshishkov, any ffmpeg repository.
[14:35:11] <elenril> reviews, patches, fflames, whatever
[14:35:54] <lu_zero> elenril: I'm growing annoyied since he's swinging from "let's work together and not fragment" to "treason, I won't support you"
[14:35:55] <{V}> oops. I imagined a "to" in "contributing what?"
[14:36:11] <superdump> elenril: i was hoping that from what i said, he might perhaps distance himself from the situation for a moment, ignore what had happened, think about what positive thing he wanted to achieve for the project if he had no responsibility to it and then do that
[14:36:41] <superdump> but it seems to me from his last few responses that he's decided he's not interested in that
[14:36:48] <superdump> maybe he feels too hurt by what happened
[14:36:55] <mru> "my way or the highway"
[14:37:13] <kshishkov> royger: where?
[14:37:29] <av500> lu_zero: I understand, but I also think you should not fan the fflames
[14:37:33] <elenril> lu_zero: take a deep breath ;)
[14:37:50] <elenril> i mean look at mplayer
[14:37:53] <superdump> wear him down with relentless positivity?
[14:37:54] <av500> lu_zero: and I would not send it like that
[14:37:59] <av500> superdump: :)
[14:38:07] <elenril> superdump: yeah!
[14:38:56] <superdump> in any case, it seems the announcement was confusing to many
[14:39:06] <kshishkov> superdump: as expected
[14:39:20] <kshishkov> superdump: any major change confuses people no matter what
[14:39:39] * elenril ToldYouSo
[14:39:44] <superdump> we need to write something about the organisation, general protocol and intended use of infrastructure to clarify how we intend the project to operate
[14:40:02] <royger> kshishkov: when recompressing an mpeg2 file, MPV_decode_mb_internal is called twice with the same block as parameter (at least s->mb_x and s->mb_y are the same) and s->encoding is false
[14:40:07] <kshishkov> superdump: army principle - you said it you do it. Move!
[14:40:12] <wbs> as I said, there's much confusion about "maintainers" now, e.g. http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2011-January/010102.html
[14:40:13] <superdump> reusing the word maintainers for some different meaning was a very confusing and negative move it seems
[14:40:22] <superdump> i need to have a map
[14:40:36] <superdump> s/map/nap/
[14:40:50] * mru gives superdump a map of maintainer types
[14:40:58] <av500> not an enum?
[14:41:28] <kshishkov> royger: what about context variable itself? Encoder employs decompression too.
[14:42:25] <kshishkov> mru: should we separate something into libavsomethingcore?
[14:43:05] <royger> kshishkov: maybe that's it, I will have to take a closer look
[14:43:18] <kshishkov> mru: just to keep good old traditions
[14:43:19] <royger> kshishkov: thanks
[14:43:42] <DonDiego> is there an option for git stash that stashes away single hunks?
[14:43:49] <DonDiego> like 'bzr shelve' does?
[14:44:17] <superdump> i've wanted something like that too
[14:44:22] <DonDiego> bah
[14:44:23] <mru> DonDiego: git stash --patch
[14:44:32] <DonDiego> i need to RTFM more closely
[14:44:34] <mru> second page of manual
[14:44:42] <superdump> i think i missed it because i was using -p
[14:44:42] * DonDiego assigns himself 5 lamer points
[14:44:48] <lu_zero> http://ffmpeg.pastebin.com/Dx4un7hh <- amended
[14:44:49] <superdump> and that means something else for stash iirc
[14:58:40] <DonDiego> mru: where did you get that %= trick in makefiles from?
[14:58:47] <mru> the manual
[14:59:01] <DonDiego> my last reading of the gnu make manual was a long time ago and my memory...
[14:59:17] <kshishkov> mru: that's the last place where one would search for it
[14:59:30] <mru> the gnu make manual is quite ok
[14:59:36] <av500> info make
[14:59:49] <mru> if you skip the sections ranting about how superior it is
[15:00:14] <mru> which may be true, but I find chest-thumping unnecessary
[15:01:25] <kshishkov> mru: then you're not Stallman. FSF without hype is not that nice
[15:01:50] <DonDiego> i agree that it is well-written - only the section about recursive make needs to be rewritten
[15:02:02] <DonDiego> it is too short and contains no warnings about the pitfalls
[15:02:08] <mru> and replaced with miller's paper
[15:02:27] <lu_zero> or even better, add a section about non-recursive make patterns
[15:02:41] <mru> occasionally it is useful of course
[15:02:54] <mru> if you're building a 3rd-party lib as part of something bigger
[15:03:06] <mru> and their makefile against all odds is good enough to be used as is
[15:03:43] <av500> mru: well, android wrote an android.mk for every subproject it swallowed and people rant at that :)
[15:04:03] <av500> so its non-recursive :)
[15:04:45] <lu_zero> android.mk is overly convoluted
[15:04:51] <mru> people rant at it because they did it poorly
[15:04:54] <lu_zero> and I guess it's ant-inspired
[15:05:16] <av500> mru: s/at it because they did it poorly//
[15:06:50] <DonDiego> also, should gabu post on -devel or so, don't forget to ignore him completely, nothing works better against trolls
[15:07:16] * av500 will feed him only a little
[15:07:38] * mru stocks up on troll poison
[15:08:51] * lu_zero adds a procmail rule
[15:09:08] <kshishkov> DonDiego: BTW, why is there such activity among people who are not related to FFmpeg nor even to recent MPlayer development?
[15:09:19] <cartman> zombies
[15:09:27] <lu_zero> kshishkov: Diego got fans
[15:10:20] <kshishkov> I'd care about http://www.gameinformer.com/b/news/archive/2011/01/21/exclusive-duke-nukem-forever-has-a-release-date.aspx more
[15:13:10] <jannau> kshishkov: so 4 months for everyone who promised something for "... when duke nukem forever is released"
[15:13:31] <kshishkov> jannau: yep, kinda harsh deadline
[15:14:09] <kshishkov> jannau: that's why I prefer something like "FFmpeg 1.0 release" instead
[15:15:39] * jannau prefers TeX 4.0
[15:15:49] <lu_zero> isn't that impossible?
[15:16:03] <elenril> thatsthepoint
[15:16:11] <mru> not of some state congress decides to redefine e as 4
[15:16:28] <jannau> TeX PI woud do too
[15:16:55] <kshishkov> mru: are you afraid to say Kansas?
[15:17:20] <av500> waering red shoes?
[15:17:23] <av500> wearing
[15:17:23] <mru> that was pi
[15:17:57] <jannau> mru: TeX is PI, metafont version is e
[15:18:11] <jannau> approximately
[15:18:36] <lu_zero> at least isn't a decreasing version number
[15:18:47] <pJok> ffmplayer?
[15:18:57] * kshishkov makes elenril stab pJok
[15:19:13] <jannau> but both should be be frozen in case of Knuth's death
[15:19:43] <mru> when knuth dies we'll have the exact values of both pi and e
[15:20:31] <jannau> ah, yes, I misremembered
[15:21:00] <jannau> and all bugs are considered features
[15:21:05] <DonDiego> mru: hmm, no diff for your "prettyprint tables" commit?
[15:21:23] <mru> DonDiego: apparently it was over some threshold
[15:21:29] <mru> it was huge
[15:21:44] <DonDiego> kshishkov: what people do you mean?
[15:21:51] <pJok> kshishkov, but it makes so much sense ;)
[15:23:06] <kshishkov> DonDiego: Arpi and Gabu
[15:23:28] <mru> DonDiego: I've increased the limit
[15:23:57] <BBB> elenril: utf16 vs. utf8, how about keeping both codepaths? I don't mind utf16 for id3v2.3, but would prefer utf8 for id3v2.4, since it's smaller and generally more used
[15:24:06] <DonDiego> kshishkov: i guess they couldn't let such a great opportunity for flaming (me) pass ...
[15:24:06] <kshishkov> pJok: well, watch git.videolan.org, probably missing bits from MPlayer will be ported soon (unless written not in Austria)
[15:24:15] <mru> elenril: what BBB said
[15:24:25] <elenril> i asked here earlier today =p
[15:24:29] <BBB> ?
[15:24:32] <BBB> I wasn't there :-p
[15:24:46] <BBB> the code is already there, all you have to do is not delete it :-p
[15:25:05] <BBB> can we have two muxers, one for id3v2.3 and one for id3v2.4? or a AVOption to switch between v2.3 and v2.4?
[15:25:12] <BBB> there seems demand for it
[15:25:23] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rd08928bbea ffmpeg/libavformat/ (Makefile mp3.c mp3dec.c mp3enc.c):
[15:25:24] <CIA-29> ffmpeg: Split mp3 demuxer and muxer into separate files.
[15:25:24] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:25:25] <BBB> I don't know what the best way to integrate this is, but we support AVOptions for muxers already
[15:25:36] <elenril> BBB: read the patch names =p
[15:25:37] <BBB> so this shouldn't be terribly impossible to do
[15:26:14] <BBB> oh there, it does it
[15:26:15] <BBB> do that first
[15:26:16] <pJok> ffmp3enc?
[15:26:21] <BBB> no, I missed 5/5
[15:26:30] <BBB> elenril: perfect, but please keep using utf8 for id3v2.4
[15:26:38] <elenril> what's the point
[15:26:43] <BBB> smaller?
[15:26:44] <av500> shorter
[15:26:47] <av500> less millicycles
[15:26:51] <elenril> it involves more if()s and general ugliness
[15:27:01] <wm4> may I ask what exactly the point is michael committing libmpcodecs to ffmpeg?
[15:27:01] <BBB> and most apps read as utf8 internally, so it makes decoding easier for them
[15:27:10] <BBB> wm4: we don't know
[15:27:14] <av500> wm4: yes, please tell us
[15:27:16] <jannau> mru: do plan to send a new patch for LOCAL_ALIGNED?
[15:27:28] <mru> jannau: yes, once I've tested it on the sgi machine
[15:27:40] <BBB> elenril: I do agree the ifs are ugly, but uh, it's only a few lines of code
[15:28:02] <BBB> elenril: also it only applies to the top half of the patch, the bttom half can stay as it is
[15:28:02] <av500> elenril: please give us one more if()
[15:28:03] <mru> and harldy relevant to performance
[15:28:15] <BBB> exactly.. smaller files is worth something imo
[15:28:26] <elenril> oh well
[15:28:42] <mru> we're the maintainers, do as we say :)
[15:28:58] <elenril> i knew it!
[15:29:51] <av500> :)
[15:30:07] <av500> elenril: and please add #endif comment
[15:30:19] <lu_zero> wm4: michael thinks avfilter w/out many filters won't appeal users
[15:30:24] <mru> what's with the strz names?
[15:30:30] <mru> we're not hungarian
[15:30:36] <mru> we know strings are nul terminated
[15:30:40] <av500> czech?
[15:31:20] <mru> "strc prst skrz krk" is apparently a semantically correct sentence in czech
[15:31:28] <elenril> strč
[15:31:38] <mru> iKnow
[15:31:38] <elenril> otherwise it's correct
[15:31:39] <cartman> see you guys, have a nice weekend!
[15:31:47] <av500> cartman: slacker
[15:31:59] <elenril> anyways, there are functions named put/get_strz
[15:32:01] <cartman> av500: my eyes went mad
[15:32:05] <cartman> gotta rest :/
[15:32:16] <mru> one bad name does not excuse another
[15:32:24] <elenril> consistency is good
[15:32:31] <mru> we can rename the other one later
[15:32:34] <elenril> ok, i'll remove the z
[15:32:40] * kshishkov makes elenril stab himself
[15:32:52] <mru> we're planning on putting prefixes on them anyway
[15:34:25] <wm4> lu_zero: isn't just copying all the mplayer code a bit unclean as opposed to porting the individual filters to ffmpeg? or was that one of those discussion points
[15:34:47] <av500> wm4: indeed it was
[15:34:56] <av500> but it will port itself once integrated
[15:35:03] <uau> what's with the people wanting to make ffplay a good standalone video player? is there really any good argument why that would be desirable?
[15:35:22] <mru> none that I can think of
[15:35:35] <av500> I mplayer because ffplay has issues
[15:35:38] <av500> +use
[15:35:52] <mru> av500: wait until omapfbplay gets audio support
[15:35:58] <av500> like missing subs when I need to debug subs for $work
[15:36:39] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r583fcb528c ffmpeg/Makefile:
[15:36:39] <CIA-29> ffmpeg: Makefile: simplify setting of some variables
[15:36:39] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:36:43] <mru> who cares about subs, just learn the spoken language
[15:36:48] <kshishkov> indeed
[15:36:52] <av500> mru: $customers
[15:36:55] <av500> not me
[15:37:08] <kshishkov> av500: they should too
[15:37:10] <av500> ze french can speak no english etc..
[15:37:27] <av500> kshishkov: yes, but you know, they resistance change a lot....
[15:38:06] <kshishkov> av500: time to sell video language courses bundled with your stuff?
[15:38:23] <av500> maybe
[15:45:10] <pJok> just let everything be in swedish
[15:46:23] * elenril resolves conflicts
[15:46:26] * elenril glares at BBB 
[15:47:24] <BBB> what did I do !!!
[15:47:31] <BBB> I don't even touch mp3 files
[15:48:02] <elenril> your comments produce conflicts
[15:51:21] <BBB> uh...
[15:51:28] <BBB> which one?
[15:52:10] <elenril> the utf-8 vs utf-16 one
[15:52:20] <elenril> don't think about it too hard, it's a joke
[15:52:31] <BBB> uhm...
[15:52:32] <BBB> ok
[15:52:41] <BBB> I don't care about function names at all if that helps
[15:52:42] <av500> BBB: just /glare at elenril
[15:52:44] <BBB> since it's not public api
[15:52:51] * BBB gives elenril the evil look
[15:53:04] <elenril> it's almost public
[15:53:10] <elenril> mplayer-level public
[15:53:39] <DonDiego> bbl
[15:54:35] <BBB> elenril: it's private api, no matter what mplayer does
[15:58:22] <elenril> BBB: functions in avio.h are private?
[15:58:26] <elenril> it's an installed header after all
[15:58:40] <BBB> ff_() ones are protected by HAVE_AVCONFIG_H or so
[15:58:47] <BBB> so they are considered private
[15:59:59] <mru> private functions should not be declared in installed headers
[16:00:13] <mru> if they are, I guarantee you someone will abuse them
[16:00:39] <BBB> like mplayer :-p
[16:00:40] <BBB> I agree
[16:00:44] <BBB> but this is how it currently is
[16:00:46] <BBB> patch appreciated
[16:00:50] <mru> so we should fix that
[16:00:54] <mru> not perpetuate it
[16:01:11] <uau> elenril: is some of those used in mplayer2?
[16:01:54] * elenril wonders what's the difference between put_strz() and put_tag()
[16:01:56] <elenril> uau: ?
[16:01:58] <uau> or did you just give that as a possible example?
[16:02:10] <elenril> it was a joke
[16:02:23] <uau> i mean you said "mplayer-level public" - i wasn't sure if you meant that as mplayer actually using them or not
[16:02:27] <elenril> i have no idea if mplayer really uses them
[16:02:32] <uau> since svn actually DOES use stuff like that
[16:02:32] <BBB> it likely doesn't
[16:02:40] <uau> but i hope i have cleaned up all of those in mplayer2
[16:02:43] <BBB> because when we moved it, nobody from mplayerland complained
[16:02:54] <elenril> uau: you're calling it mplayer2?
[16:03:05] <elenril> we were hoping for RealMPlayer
[16:03:29] <uau> yes, that was the name talked about long ago and i haven't heard any better alternative
[16:03:40] <uau> i don't really like naming things
[16:03:41] <av500> mp2
[16:03:46] <uau> and haven't tried to come up with anything else
[16:03:48] <elenril> i know a better alternative
[16:03:55] <elenril> merge with mplayer =p
[16:04:14] <uau> merge how? throw svn out, replace with git contents?
[16:04:21] <uau> if you can get reimar to agree i'm all for it :)
[16:04:26] <elenril> pretty much.
[16:04:47] <elenril> but it requires you being willing to cooperate and is therefore pure fantasy
[16:04:50] <elenril> (and offtopic)
[16:05:09] <mru> elenril: let's be civil, shall we?
[16:05:15] <siretart> uau's mplayer (finally) has a name? cool
[16:05:23] <BBB> I quickly glanced over "[PATCH 4/5] id3v2: split tables for various ID3v2 version", looks ok to me
[16:05:27] <siretart> uau: is there some upstream homepage or something yet?
[16:05:29] <uau> siretart: i think i mentioned "mplayer2" to you quite a while ago
[16:05:38] <uau> siretart: should be pretty soon
[16:05:50] <uau> but not at the moment
[16:06:18] <siretart> if so, then I missed that note
[16:06:22] <wm4> uau: will it be a full-blown fork then?
[16:06:31] <mru> pitchfork
[16:06:35] <elenril> great, now we have two ffmpegs and two mplayers
[16:06:41] <uau> elenril: when the topic comes up you always seem to concentrate on me being "unwilling to cooperate"
[16:06:55] <mru> both of you, stop it
[16:07:04] <mru> if you want to fight, do it outside
[16:07:18] <uau> mru: not a fight
[16:07:40] <elenril> yeah, i'm actually siding with uau's fork
[16:07:43] * elenril shuts up now
[16:08:00] <uau> elenril: i have posted "undiplomatic" stuff, but i don't think the way i've wanted to do development has been at all unreasonable
[16:08:05] <mru> uau: I've argued with you many times, but now I think it's time to bury the hatchet
[16:08:23] <BBB> uau: side with ffmpeg - it's the new and improved version of mplayer anyway :-p
[16:08:26] <BBB> </troll>
[16:09:17] <uau> elenril: you seem to think only "diplomacy" would be needed, but i think that's completely wrong - there are real disagreements with reimar about how to do development and what direction the project should take
[16:09:26] <elenril> uau: only the way you present your views is unreasonable
[16:09:30] <uau> that are not at any "personal conflict" level
[16:09:48] <elenril> oh well, whatever
[16:10:41] <uau> btw i think it's about time to start getting interested people on separate irc channels for mplayer2
[16:11:07] <lu_zero> uau: what would be your plan?
[16:11:11] <uau> currently only #mplayer2 is registered (it's now open, the key has been removed); probably there will be a separate channel later
[16:11:19] <elenril> anyone objects to ff_put_str returning number of bytes written?
[16:11:20] <uau> separate development channel i mean
[16:11:28] <lu_zero> mplayer2-dev?
[16:11:29] <elenril> to make it consistent with ff_put_str16
[16:11:35] <BBB> mru: so how do you want to name ff_put_strz16le()?
[16:12:16] <uau> lu_zero: plan regarding what? if you mean mplayer2 release, the website should hopefully be up pretty soon
[16:12:39] <mru> _str16le() is fine with me
[16:12:42] <uau> once it's tested working i'll release about current code as a beta, then a real release hopefully pretty soon
[16:13:21] <BBB> elenril: can you rename it? otherwise the 1/6 is fine with me also
[16:13:59] <BBB> elenril: and that's all comments I have
[16:14:01] <BBB> rest looks ok
[16:15:09] <royger> kshishkov: is there any parameter in MpegEncContext to know if the decoding that is taking place is the one before the encoding? I need to modify some I-frame DCT luminance blocks before they are encoded back to mpeg2
[16:16:30] * mru watches the octane build ffmpeg, slowly
[16:20:35] <elenril> will i die a slow and painful death if i include avformat.h from avio.h?
[16:20:44] <mru> probably
[16:21:07] <mru> that pair has made my head spin on more than one occasion
[16:21:12] <mru> what's the problem?
[16:21:18] <mru> you need the version?
[16:21:19] <elenril> i want to use FF_API_OLD_FOO
[16:21:29] <mru> ok, lets fix that
[16:21:31] <mru> properly
[16:21:47] <mru> move the version macros to version.h and include that wherever needed
[16:23:14] <elenril> isn't that autogenerated?
[16:23:22] <mru> libavformat/version.h
[16:23:34] <elenril> ah
[16:23:54] <mru> curious compiler warning: "jumping out of a block containing VLAs" is not currently implemented
[16:26:01] <uau> i registered #mplayer2-dev as the development channel
[16:26:18] <uau> currently nothing like FFMPEG_VERSION is visible in installed headers right?
[16:26:42] <elenril> lol, the I return the LIBAVFORMAT_VERSION_INT constant.  You got * a fucking problem with that, douchebag?
[16:26:45] <elenril> I return the LIBAVFORMAT_VERSION_INT constant.  You got * a fucking problem with that, douchebag?
[16:26:53] <elenril> oops
[16:27:05] * av500 douches elenril
[16:27:17] <elenril> i didn't it was still there
[16:27:20] <jannau> version.h is probably too generic for a public header
[16:27:31] <mru> it's libavformat/version.h
[16:27:31] <uau> i'd like to print the ffmpeg version that mplayer2 was compiled against
[16:27:31] <merbzt> we should change that
[16:27:52] <jannau> uau: only the library versions
[16:27:59] <mru> jannau: if people put $prefix/include/libavformat in their cpp search path they should blame themselves
[16:28:01] <uau> (of course someone _could_ install different ffmpeg library headers from different versions, but i think that's not supported)
[16:28:42] <mru> I don't think version.h is any worse than common.h
[16:28:53] <mru> and we've never had anyone complain about that
[16:28:54] <uau> mru: "$ ls include/libavformat" -> "avformat.h  avio.h"?
[16:29:26] <mru> uau: yes, those headers are currently installed there
[16:29:30] <mru> I'm suggesting we add version.h
[16:29:51] <uau> ok... the "it's" didn't sound like a suggestion to me
[16:30:17] <mru> guess I got a bit ahead of myself there
[16:34:31] <elenril> how nice, avio.h already uses tons of FF_API_*
[16:34:48] <mru> elenril: yes, it's very ugly
[16:34:54] <mru> but now we're going to fix that
[16:36:50] * elenril wonders why does it keep recompiling mpegaudiodec
[16:39:49] <mru> wbs, BBB: I'm getting errors about INET_ADDRSTRLEN undefined on IRIX
[16:39:54] <mru> is there a missing check somewhere?
[16:40:28] <elenril> #include "libavformat/id3v1.h"
[16:40:30] <elenril> wait, what?
[16:40:38] <elenril> in mpegaudiodec.c
[16:40:49] <mru> wtf
[16:41:41] <elenril> git blames ubitux
[16:41:50] <elenril> and apparrently i committed it :)
[16:43:04] <elenril> anyway, http://pastebin.com/SVx8XyHf
[16:43:19] <mru> hmm, applehttp is built even with --disable-network
[16:47:17] <elenril> err, the last entry isn't supposed to be there
[16:47:35] <elenril> http://pastebin.com/s2qGeBtM
[16:47:43] <ubitux> elenril: oh it broke something?
[16:48:15] <elenril> ubitux: it added a dependency on libavformat
[16:48:32] <ubitux> is it bad?
[16:49:10] <mru> elenril: that won't work right
[16:49:22] <mru> it will pick up the top-level version.h
[16:49:32] <mru> #include "libavformat/version.h"
[16:49:39] <mru> or think of another name
[16:49:41] <elenril> compiled fine
[16:50:22] <mru> doesn't matter
[16:50:25] <uau> ubitux: i think it didn't break anything in this case as there was no runtime dependency
[16:50:26] <mru> it could still compiler
[16:50:27] <mru> -r
[16:50:57] <mru> elenril: put a #error in that file and see if it still builds
[16:51:09] <uau> ubitux: but including headers could be seen as somewhat unsafe, as if you use any _function_ from them that'd cause a runtime dependency between the libraries
[16:51:32] <elenril> /libavformat/version.h:93:2: error: #error
[16:52:06] <mru> hmm, that's odd
[16:52:20] <uau> i think the compiler prefers loading "" includes from current directory
[16:52:23] <uau> before search path
[16:52:31] <mru> even before -I flags?
[16:52:37] <elenril> maybe that depends on the compiler
[16:52:42] <mru> it does depend on the compiler
[16:52:47] <mru> so better to use the full path
[16:52:55] <mru> that's unambiguous
[16:53:05] <elenril> http://pastebin.com/yiUkX1AZ
[16:53:37] <uau> is there some compiler that behaves differently?
[16:53:53] <mru> it's explicitly unspecified in the spec
[16:54:07] <mru> if there isn't a compiler today, there could be one tomorrow that does differently
[16:54:21] <mru> and I'd rather not be the one to debug it
[16:54:24] <uau> well the C spec says very little about includes in general, it doesn't even assume a directory-structured file system IIRC...
[16:54:49] <ubitux> uau: ok
[16:55:18] <ubitux> so what would be the correct fix?
[16:55:41] <ubitux> it was just to get access to a macro definining a size
[16:55:45] <elenril> you use just one macro from the header
[16:55:50] <elenril> you could duplicate it
[16:55:57] <mru> but why is it needed at all?
[16:56:00] <ubitux> ok :/
[16:56:13] <mru> nobody should feed id3 data to the decoder
[16:56:59] <mru> uau: yes, the C standard is rather open-ended on what the name means
[16:57:08] <ubitux> well actually, i recently saw the decoder try to decode it anyway
[16:57:09] <uau> the C spec says about "" includes "file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read #include <"
[16:57:27] <elenril> ubitux: that's right, why don't you check for it in the demuxer?
[16:57:33] <uau> that sounds like the additional paths for "" should come before the ones for <> (which -I affects)
[16:57:45] <mru> that's implementation-defined
[16:58:00] <mru> the implementation may choose to apply -I paths to "" as well
[16:58:03] <ubitux> elenril: i thought it was more appropriate here but i don't remember why
[16:58:16] <BBB> mru: may be a missing configure check for networking, unless that is outside CONFIG_NETWORK
[16:58:22] <BBB> mru: what is CONFIG_NETWORK on that box' config.h?
[16:58:22] <uau> mru: of course, but then it might choose to ignore any "libavformat/" prefix in search paths as well...
[16:58:30] <ubitux> i'm home in a few hours i'll look again if you can wait :p
[16:59:02] <mru> uau: we assume directories are recognised all over the place
[16:59:17] <mru> and I've never heard som much as an ancient rumour about a compiler that didn't work like that
[16:59:34] <mru> I just prefer being on the safe side
[16:59:48] <uau> well have you actually heard of a compiler that'd prefer search path includes to local ones?
[17:00:03] <uau> i think that'd cause practical problems
[17:00:19] <mru> perhaps, but why tempt fate when it's so easy to avoid?
[17:00:42] <mru> now I have to attend a conf call
[17:05:26] <lu_zero> apple segmented mpegts should work out of fs not just network
[17:05:37] <lu_zero> (or at least that's how I used it not long ago)
[17:08:23] * elenril spams some more patches
[17:10:30] <thresh> wow, configure now almost works on hpux
[17:11:21] <BBB> oh so now we're going to remove all mentions of strz? :-p
[17:11:45] <BBB> I don't have any opinion on that honestly, so fine with me - I bet you tomorrow someone will ask us to revert it
[17:11:59] <BBB> also it's not publica (av_) api, so no reason to keep the old api
[17:12:14] <BBB> elenril: ^^
[17:14:10] <elenril> BBB: it's not all mentions of strz, i just wanted it to be compatible with the _16 version
[17:14:24] <BBB> ok
[17:14:26] <elenril> i.e. so it'd return the number of bytes written
[17:14:38] <elenril> and since i'm at it i might as well rename it
[17:15:11] <elenril> now i can use the same code for writing both utf8 and utf16
[17:19:49] <lu_zero> nice =)
[17:20:32] <BBB> elenril: ok, like I said, sounds good to me
[17:20:55] <BBB> mru: you can queue that patch imo if you have time - also let's keep queueing stefano's work
[17:21:06] <BBB> saste: let's keep compatible as much as possible fwiw
[17:26:44] <lu_zero> those function are supposed to be private?
[17:27:56] <BBB> they have no av_ prefix
[17:28:20] <lu_zero> BBB: nor ff_ ^^;
[17:28:33] <BBB> elenril is changing that :-p
[17:29:03] <lu_zero> I'd consider them useful for external usage
[17:29:13] <lu_zero> or I'm missing something?
[17:29:25] <BBB> just like dsp is useful to the outside
[17:29:28] <BBB> yet it is not public
[17:31:25] <elenril> if someone asks for them to be public, they can be changed
[17:31:36] <elenril> it's harder to change them back ;)
[17:43:37] * elenril thinking about the possibilites opening with per-muxer options
[17:45:31] <elenril> also anybody heard from aurel?
[17:58:14] <lu_zero> BBB: the header is public and I'm afraid not everybody decided to pick it
[17:58:20] <lu_zero> as private
[17:59:57] <elenril> hmm, seems i broke --disable-everything --enable-demuxers=mp3
[18:03:03] <mru> fix it!
[18:03:25] <elenril> i don't see what's wrong
[18:09:21] <elenril> ah, it depends on --enable-parser=mpegaudio
[18:09:47] <elenril> dependencies aren't enabled manually?
[18:09:49] <mru> let's make it auto-select that
[18:12:26] <mru> patch away
[18:20:22] <elenril> hmm, there's a ff_put_string in lavc
[18:20:50] <mru> that puts to different thing though
[18:20:51] * elenril wonders if it does anything exciting
[18:21:05] <elenril> PutBitContext, wtf is that
[18:21:15] * elenril should learn to libavcodec sometime
[18:31:39] * elenril sends another round of renaming patches
[18:31:52] * _av500_ renames elenril 
[18:32:25] <elenril>  [Freenode] ::: Nick av500 is already in use
[18:32:28] <elenril> curses!
[18:37:23] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * rc2dd0e9eba ffmpeg/configure:
[18:37:23] <CIA-29> ffmpeg: Make demuxers auto-select parsers they need
[18:37:23] <CIA-29> ffmpeg: This makes configure --disable-everything --enable-demuxer=foo
[18:37:23] <CIA-29> ffmpeg: work as expected.
[18:37:23] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:37:27] <mru> elenril: sorry to be annoying, but perhaps prefixing that bunch of functions with avio_ would make sense
[18:38:12] <elenril> could've said that earlier =p
[18:38:21] <mru> I only thought of it now
[18:38:57] <elenril> oh well, another round of rebasing
[18:39:00] * elenril <3 rebasing
[18:40:17] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r7aa571113f ffmpeg/libavformat/ (id3v2.c id3v2.h): (log message trimmed)
[18:40:17] <CIA-29> ffmpeg: id3v2: use an enum for encodings instead of magic numbers.
[18:40:17] <CIA-29> ffmpeg: On Fri, Jan 21, 2011 at 02:35:41PM +0000, Måns Rullgård wrote:
[18:40:17] <CIA-29> ffmpeg: > Anton Khirnov <anton at khirnov.net> writes:
[18:40:17] <CIA-29> ffmpeg: >
[18:40:17] <CIA-29> ffmpeg: > > ---
[18:40:18] <CIA-29> ffmpeg: > > libavformat/id3v2.c | 10 +++++-----
[18:40:33] <mru> fuck
[18:40:45] <elenril> haha
[18:40:51] <BBB> hahaha :)
[18:41:12] <Zor> rebase is the swiss knife of distributed source control
[18:41:23] <elenril> rewriting history is evil!
[18:41:28] <Zor> liessss
[18:41:29] <elenril> it hides embarassing mistakes
[18:42:50] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rd66eff3685 ffmpeg/libavformat/ (id3v2.c id3v2.h):
[18:42:51] <CIA-29> ffmpeg: id3v2: use an enum for encodings instead of magic numbers.
[18:42:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:42:54] <mru> terribly sorry about that
[18:43:03] <mru> I took the liberty to fix it within 30s
[18:44:20] <mru> I accidentally piped the entire mail instead of the attachment to git am
[18:47:51] <elenril> damn, wrong thread
[18:48:22] * elenril wishes mutt had some integration with git
[18:48:52] <thresh> http://img-fotki.yandex.ru/get/5003/strangestone.41/0_45160_5aec452b_orig -- check out the icons on the screen ;p
[18:50:31] <BBB> thresh: vlc?
[18:50:46] * mru sends thresh to #videolan 
[18:50:56] <thresh> BBB: yeah
[18:51:06] <thresh> mru: well, it means FFMpeg is there too
[18:51:20] <BBB> the icon of vlc is not based on ffmpeg :-p
[18:51:29] <mru> there's no zigzag icon
[18:51:35] <BBB> mru: you can queue elenril's 1/6 rename ff_put_str16bla also
[18:51:58] <mru> maybe that should be public too
[18:51:58] <wbs> mru: applehttp doesn't depend on config_network, you could just as well play a .m3u8 with its .ts files from a local directory
[18:52:05] <elenril> i made them all public
[18:52:10] <mru> wbs: oh
[18:52:13] <elenril> compiling now, will send in a sec
[18:52:15] <kshishkov> mru: make them repaint cone into green stripes first ;)
[18:52:17] <mru> wbs: http sounded rather networky
[18:52:36] <wbs> mru: and regarding INET_ADDRSTRLEN, don't think it requires any configure check, you could add an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 50 or similar in network.h
[18:52:56] <wbs> mru: yeah, it sounds kinda networky, but I didn't come up with any better name
[18:53:03] <mru> it whinged about other things too
[18:53:13] <mru> maybe I'll figure it out some day if I'm bored
[18:53:17] <wbs> ok
[18:53:19] <mru> who cares about irix anyway
[18:53:40] <lu_zero> saste: could you check a line using -pix_fmt to output raw frames?
[18:54:01] <lu_zero> during this month apparently it broke
[18:54:24] <thresh> damn, adding a -D to fix one error in HPUX ffmpeg compile results in broken struct checks
[18:54:27] <lu_zero> [buffer @ 0x978f50] Invalid pixel format string '-1'
[18:55:04] <lu_zero> ffmpeg -i sample -vcodec rawvideo -pix_fmt uyvy422 -acodec pcm_s16le -ar 48000 -f nut out.nut
[18:55:10] <lu_zero> this now breaks
[18:55:34] <mru> hpux... thresh must have been a very naughty boy to receive such punishment
[18:55:58] <wbs> or perhaps he likes kinky stuff
[18:56:08] <pJok> masochism
[18:56:18] <saste> lu_zero: what does "sample" contains?
[18:56:33] <lu_zero> let me check if it is specific
[18:56:33] <saste> lu_zero: looks like the pixel format is not recognized
[18:57:36] <thresh> mru: no, i'm just a loser who doesnt have anything better to do on Friday night
[18:58:20] <lu_zero> saste: that's what puzzles me since I have a version that works fine with it
[18:58:24] * elenril wonder if he'll EVER do this patch right
[18:59:50] <saste> saste: works here with a flv file
[19:00:07] <elenril> anyone minds if i just resend the whole patchset?
[19:00:07] <saste> lu_zero: works here with a flv file
[19:00:20] <elenril> replying to single mails is effort
[19:00:21] <lu_zero> saste: it is broken here on an rtmp stream
[19:00:48] <lu_zero> s/rtmp/http+mpegts
[19:01:08] <saste> lu_zero: post the command on pastebin
[19:02:02] <saste> saste: then sure a check should be added to ffmpeg.c
[19:02:28] <elenril> mru: one of the patches has a typo in it, don't apply them
[19:02:37] <saste> lu_zero: then sure a check should be added to ffmpeg.c
[19:02:42] <mru> elenril: ok, won't
[19:02:51] <elenril> i'll dump the whole branch again
[19:04:44] <lu_zero> looks unrelated in the end
[19:10:00] <ubitux> is there a MK(BE)TAG24?
[19:10:15] <ubitux> or doing it manually is the correct thing?
[19:10:36] <mru> you could use 32 with a 0
[19:10:37] <elenril> use MK**TAG32 with a 0
[19:11:03] <ubitux> ok
[19:11:08] <ubitux> thanks
[19:11:30] <ubitux> i'm looking for moving the tag hack, i'll send a patch asap
[19:11:39] <ubitux> (id3 tag)
[19:13:45] <elenril> ok, i really hope i did it all right this time
[19:18:32] <BBB> mru: when you say "this", in the sentence "this does", in a patch that only removes a line, what should I imagine it doing?
[19:18:55] <mru> the change does
[19:25:18] <BBB> it's a removal :-p I don't understand configure enough
[19:25:23] <BBB> will leave to diego to review
[19:25:49] <mru> stuff after patch compared to stuff before patch
[19:34:56] <mru> anyone here set up to build for iphone?
[19:35:10] * wbs 
[19:35:30] <mru> wbs: please test this patch: http://git.mansr.com/?p=ffmpeg;a=commitdiff;h=9f490b2
[19:35:41] <mru> make sure the struct offsets are correct
[19:35:56] <mru> I made a guess, but it could be wrong
[19:50:54] <_av500_> mru: cant we do the sub struct thing at least?
[19:51:11] <mru> of course we can
[19:51:22] <mru> but I don't want to hold up ruggles' patch waiting for that
[19:51:26] <_av500_> ok
[19:54:19] <mru> hmm, michael just imported a swath of commits from ffmpeg.org
[19:55:12] * elenril just saw it too
[19:55:23] <elenril> seems he didn't like me splitting mp3.c
[19:55:40] <Dark_Shikari> mru: someone make a bunch of commits that conflict wildly with his
[19:55:51] <elenril> how not nice
[19:55:56] <mru> I have  few nice ones that he rejected in the past
[19:55:57] <elenril> we want to cooperate, don't we =p
[19:56:04] <Dark_Shikari> elenril: he's pushing a fork, that's not cooperation
[19:56:08] <mru> general cleanup stuff
[19:56:20] <mru> I think I'll resend some of that
[19:56:34] <elenril> Dark_Shikari: he's still around and working on ffmpeg => we can merge his code
[19:57:01] <mru> did he skip any?
[19:57:42] <ubitux> is it ok to check for id3v1 tag in the demuxer read_packet function?
[19:57:51] <wbs> mru: compiles fine for iphone
[19:57:59] <ubitux> (the tag is expected at the end of the file)
[19:58:15] <mru> wbs: cool, then I'll push the patches
[19:58:19] <elenril> ubitux: where else would you want to check
[19:58:46] <ubitux> elenril: i don't know, i'm asking :)
[19:59:10] * elenril can't think of any other place inside lavf
[19:59:11] <_av500_> er, but then you have the tag only at the end, no?
[19:59:26] <_av500_> need to listen to all the song to have it?
[19:59:41] <ubitux> seems yes
[19:59:49] <ubitux> but there is id3v2 most of the time
[19:59:55] <ubitux> and actually there is a strange thing
[20:00:00] <mru> btw, the bsd boxes are back on fate \o/
[20:00:06] <ubitux> mp3_read_header looks for a id3v1 tag
[20:00:08] <_av500_> there is still a ton of v1 out there
[20:00:13] <ubitux> but it should nevre find one
[20:00:18] <_av500_> think asia
[20:00:19] * mru still ponders setting up something bizarre on that old quad-core
[20:00:27] <_av500_> mru: hurd
[20:00:33] <kierank> DOS
[20:00:37] <_av500_> minix3!
[20:00:54] <mru> kierank: we have dos already covered
[20:00:56] <elenril> lu_zero: i think avio.h has been public since stone age
[20:00:56] <ubitux> maybe the mp3_read_header should seek at the end of the file and try to read the id3 tag?
[20:01:01] <kierank> mru: yeah but dos on a quad core
[20:01:08] <elenril> ubitux: it already does that, no?
[20:01:09] <kierank> overkill ftw
[20:01:13] <ubitux> and also try to skip it when expecting it in mp3_read_packet?
[20:01:29] <thresh> mru: plan9
[20:01:34] <ubitux> elenril: seems not no; i don't think it seeks to the end of the file
[20:01:35] <mru> thresh: unpossible
[20:01:36] <thresh> if you're that insane
[20:01:39] <mru> plan9 sucks too much
[20:01:48] <mru> they don't even have a C compiler
[20:01:49] <elenril> ubitux: see ff_id3v1_read()
[20:01:59] <thresh> *cough*beos*cough*
[20:02:00] <elenril> it's only called if there's no v2 tag
[20:02:05] <mru> their version of C doesn't support #if FOO
[20:02:15] <mru> because they think that's unnecessary
[20:02:30] <thresh> hpux is soooo broken :(
[20:02:34] <ubitux> elenril: i missed the fact it seek to the end of the file, but ok
[20:02:39] <mru> I might try haiku
[20:02:40] <thresh> both gcc and their cc
[20:02:48] <mru> last time I tried it the installer crashed
[20:02:48] <ubitux> well so it only need to ignore the tag in mp3_read_packet
[20:03:03] <elenril> yes
[20:03:03] <mru> thresh: gcc on plan9 is very much a second-rate citizen
[20:03:11] <BBB> shit
[20:03:13] <BBB> mingw is gone
[20:03:17] <BBB> where is ramiro?
[20:03:44] <elenril> what do you mean, 'gone'
[20:04:35] <mru> the mingw slots were last updated jan 20 3am with michael's non-building tree
[20:04:44] <mru> I've hidden them from the front page
[20:05:05] <thresh> you need some protection from malicious forks
[20:05:10] <mru> eg http://fate.ffmpeg.org/i686-w64-mingw32-gcc-4.4/latest
[20:05:17] <BBB> hm
[20:05:29] <mru> thresh: I've been considering options
[20:05:30] <elenril> michael's tree doesn't build?
[20:06:22] <mru> apparently not
[20:06:22] <mru> I find that funny
[20:06:22] <thresh> although I have no idea how to do that as I never touched fate myself
[20:06:23] * elenril finds that sad
[20:06:23] <mru> I can always revoke the keys from anyone who misbehaves
[20:06:32] <Dark_Shikari> mru: wait, you're not FATEing michael?
[20:06:37] <Dark_Shikari> Now that's potentially evil
[20:07:07] <mru> I fate ffmpeg.org
[20:07:25] <Dark_Shikari> Yeah, it makes sense -- it just means michael might not be used to working without fate
[20:07:40] <mru> I think it's failing only out-of-tree builds
[20:07:44] <mru> like fate always does
[20:09:12] <BBB> b/c of libmpcodecs?
[20:10:43] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r50196a982b ffmpeg/libavformat/ (Makefile avformat.h avio.h version.h):
[20:10:43] <CIA-29> ffmpeg: lavf: move the version macros to a new header
[20:10:43] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:10:46] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r56f8952b25 ffmpeg/libavcodec/ (12 files in 3 dirs):
[20:10:46] <CIA-29> ffmpeg: Move lpc_compute_autocorr() from DSPContext to a new struct LPCContext.
[20:10:46] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:10:52] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r1c189fc533 ffmpeg/libavcodec/ (lpc.c x86/lpc_mmx.c):
[20:10:52] <CIA-29> ffmpeg: cosmetics related to LPC changes.
[20:10:52] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:11:09] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r77a78e9bdc ffmpeg/libavcodec/ (alacenc.c flacenc.c lpc.c lpc.h ra144enc.c x86/lpc_mmx.c):
[20:11:09] <CIA-29> ffmpeg: Separate window function from autocorrelation.
[20:11:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:11:32] <BBB> elenril: in order to be future-compliant, shouldn't we convert id3v2.3 tags anyway, even if none are converted right now?
[20:11:38] <BBB> maybe we'll convert 1 or 2 to generic names in the future
[20:12:45] <elenril> i don't see how adding a noop now is better than adding function call later
[20:13:35] <BBB> I guess...
[20:13:47] * BBB thinks elenril's got balls today and wants to kick ass
[20:13:56] <BBB> mru: you can queue that one too then
[20:14:13] * elenril is supposed to be studying QFT
[20:14:59] <BBB> I see you've been studying very hard
[20:15:01] <BBB> :-p
[20:15:31] <elenril> =p
[20:16:04] <elenril> still better than idly procrastinating
[20:16:08] <mru> BBB: which one?
[20:16:24] <elenril> when i'm not under pressure i waste time playing minesweeper or worse ;)
[20:16:42] <mru> watching minesweeper porn?
[20:17:12] <BBB> mru: at least the split tables and the one adding the muxer option for id3v2.3 tag writing
[20:17:27] <BBB> 1/6 rename ff_str16_nolen is fine also
[20:17:29] <BBB> (1/6)
[20:17:44] <BBB> 2/6 is fine also (rename put_str())
[20:20:39] <mru> BBB: ff_str16_nolen looks like 3/6 to me
[20:20:48] <mru> or am I looking at the wrong patch set?
[20:21:23] <BBB> oh yeah gmail bug
[20:21:29] <BBB> it shows the title of the original message
[20:21:30] <BBB> it's 3/6
[20:21:46] <elenril> wait, gmail groups my mails by subject?
[20:21:48] <elenril> lol
[20:21:53] <mru> lame
[20:21:56] <BBB> anssi's patches for profile are ok also
[20:22:03] <BBB> I didn't typocheck them
[20:22:45] <BBB> I wanted to look into reimar's patches also and cleanup that stuff some more maybe
[20:22:53] <BBB> but then again there's also the h264 regression on roundup
[20:23:40] <mru> 5/6 won't apply w/o 4/6
[20:27:21] <mru> btw, if anyone wonder what I have queued, see http://git.mansr.com/?p=ffmpeg;a=shortlog;h=master;hp=origin/master
[20:31:00] <BBB> 4/6 I'm still reviewing
[20:31:52] <elenril> you people and your error-checking =p
[20:31:53] <mru> I don't see anything immediately wrong with it
[20:31:53] <elenril> makes my nice short code longer
[20:31:53] <BBB> mru: I sent a reply already
[20:31:53] <BBB>         av_freep(&hx->rbsp_buffer[1]);
[20:31:53] <BBB>         av_freep(&hx->rbsp_buffer[0]);
[20:31:53] <BBB>         hx->rbsp_buffer_size[0] = 0;
[20:31:53] <BBB>         hx->rbsp_buffer_size[1] = 0;
[20:31:53] <BBB> why is that code there?
[20:31:53] <BBB> (h264.c)
[20:32:00] <mru> to free some buffers I presume
[20:32:26] <BBB> apparently that causes some invalid reads later on
[20:35:14] <BBB> I think the decoding is still running while that code runs...
[20:35:32] <mru> mt?
[20:35:45] <BBB> no, baseline svn
[20:35:48] <BBB> er, git
[20:35:53] <BBB> git head, or git trunk
[20:35:55] <BBB> git master?
[20:36:12] <mru> how can something "still" be doing something while something else is doing anything?
[20:36:16] <mru> if it's single-threaded
[20:36:48] <BBB> free_tables() does this:
[20:36:54] <BBB>     for(i = 0; i < MAX_THREADS; i++) {
[20:36:54] <BBB>         hx = h->thread_context[i];
[20:36:59] <BBB> ... free thread info ...
[20:37:01] <BBB>     }
[20:37:04] <mru> BBB: I have reviewed your review
[20:37:06] <BBB> so I think that it's already threaded
[20:38:01] <_av500_> elenril: u still need that win7 test?
[20:38:14] <mru> BBB: h264 is not threaded
[20:38:39] <BBB> I then have no idea what this code does
[20:38:41] <mru> or does it have slice threading?
[20:39:07] <elenril> _av500_: nah, JEEB was faster than you
[20:39:17] <_av500_> k
[20:39:20] <BBB> mru: probably slice threading
[20:39:37] <_av500_> only got that win7 tablet running now...
[20:39:52] <_av500_> had to guess the password...
[20:40:00] <mru> admin?
[20:40:07] <_av500_> Test
[20:40:13] <kierank> hunter2
[20:40:18] <mru> swordfish
[20:40:30] <_av500_> note the tricky capital T
[20:40:46] * mru did
[20:40:50] <mru> cunning
[20:42:21] <uau> h264 does have slice threading
[20:42:44] <uau> though it gets disabled for most videos as they're not encoded with independent slices
[20:43:02] <elenril> arrrgh
[20:43:11] * elenril rebuilding libavcodec for the 157th time
[20:43:26] <kierank> at least you're not building on windows
[20:43:35] <mru> siretart: ping
[20:44:18] <spaam> elenril: i hope you are using ccache ;)
[20:44:31] <ubitux> elenril: are you sure the demuxer is actually the good place? i mean, mp3_read_packet is not called at the top of the frame, so well i don't have the tag immediately unless i'm missing something
[20:44:43] <mru> spaam: I'm not using ccache
[20:45:03] <ubitux> mmh, maybe by checking the end of the packet.
[20:45:45] <spaam> mru: i now you have a good computer with --omg-optimized stuff.. elenril are just elenril ... using windows7..
[20:47:24] <elenril> this is so obvious it's even beneath stabbing or a tvtropes attack
[20:49:13] <spaam> hmm?
[20:51:51] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rdccbd97d72 ffmpeg/libavformat/ (asf.c asf.h asfenc.c avio.h aviobuf.c mmst.c):
[20:51:51] <CIA-29> ffmpeg: lavf: move ff_put_str16_nolen from asf to avio and rename it
[20:51:51] <CIA-29> ffmpeg: It will be useful in the mp3 muxer.
[20:51:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:51:54] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r4efd5cf34b ffmpeg/libavformat/ (avienc.c avio.h aviobuf.c ffmenc.c version.h):
[20:51:54] <CIA-29> ffmpeg: avio: add av_put_str and deprecate put_strz in favor of it
[20:51:54] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:51:56] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r93bb9ff08e ffmpeg/configure:
[20:51:56] <CIA-29> ffmpeg: configure: simplify exit traps
[20:51:56] <CIA-29> ffmpeg: This does the same thing and also fixes the trapping in
[20:51:56] <CIA-29> ffmpeg: some (possibly broken) shells.
[20:51:56] <CIA-29> ffmpeg: Suggested by Michael Kostylev.
[20:51:57] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:54:25] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * ra210bce298 ffmpeg/configure:
[20:54:25] <CIA-29> ffmpeg: configure: better test for mktemp
[20:54:25] <CIA-29> ffmpeg: Some variants of mktemp require a template, so provide one when
[20:54:25] <CIA-29> ffmpeg: checking for the command. We already supply a template in the
[20:54:25] <CIA-29> ffmpeg: subsequent uses of mktemp.
[20:54:26] <CIA-29> ffmpeg: Thanks to Michael Kostylev.
[20:54:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:56:35] <elenril> i wonder if a minor bump or something is in place
[20:58:03] <ubitux> uint32_t v = AV_RB32(buf) & 0xffffff00; ← any better solution than this?
[20:59:07] <ubitux> mmh, found a workaround, forget this.
[20:59:39] <mru> AV_RB24()?
[21:00:49] <jannau> http://patchwork.libav.org/project/ffmpeg/list/?order=date
[21:00:55] <ubitux> mru: yes but changing the MKBETAG used to compare to
[21:01:04] <ubitux> too
[21:01:21] <ubitux> MKBETAG(0, 'T', 'A', 'G') instead of MKBETAG('T', 'A', 'G', 0)
[21:02:06] <jannau> currently not really useful since post-commit magic purging patches is missing
[21:02:10] <ubitux> http://pastie.org/1485445 ← does this look good to you elenril?
[21:04:05] <mru> jannau: cool
[21:04:18] <mru> are you planning on adding purging?
[21:04:38] <mru> and can you have it strip the ffmpeg-devel tag?
[21:04:51] <mru> having that on all of them just makes it harder to read
[21:06:08] <jannau> yes, currently working on the purging
[21:07:34] <ubitux> (should i send the patch on ffmpeg-devel?)
[21:07:49] <elenril> ubitux: does it work? ;)
[21:07:57] <ubitux> elenril: yes it seems
[21:08:06] <ubitux> is it surprising?
[21:08:35] <elenril> somewhat
[21:08:53] <elenril> anyway, i'm not the best person to review it, i'm not very familiar with decoding magic
[21:09:25] <ubitux> ok i'm going to send it to ffmpeg-devel
[21:09:25] <mru> if you're not so good with magic you should get a spell checker
[21:22:07] <jannau> mru: http://patchwork.libav.org/project/FFmpeg-devel/list/
[21:23:13] <mru> how often does it purge committed patches?
[21:27:54] <jannau> I'm installing a post-update hook for it
[21:28:09] <mru> installing where?
[21:30:37] <mru> ouch, we messed up
[21:32:00] <jannau> on the patchwork server, which will be set up to mirror git.ffmpeg.org
[21:32:10] <mru> ah
[21:32:29] <mru> and how will that mirroring be triggered?
[21:33:13] <jannau> I was hoping by post-update hook on git.ffmpeg.org
[21:33:22] <mru> sure
[21:33:58] <jannau> but let me first check if it works
[21:35:36] <mru> something works
[21:35:44] <mru> it picked up the patch I just sent
[21:36:02] <mru> how are multiple patch revisions handled?
[21:36:08] <mru> like elenril's recent adventures?
[21:36:25] <mru> by title?
[21:46:11] <BBB> mru: latest 4/6 is ok with me
[21:51:51] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r4ad66441c9 ffmpeg/configure:
[21:51:51] <CIA-29> ffmpeg: Fix libavformat version extraction in configure
[21:51:51] <CIA-29> ffmpeg: This fixes shared library builds broken by
[21:51:51] <CIA-29> ffmpeg: 50196a982bf7c8be9b41053fa0975473c217e709
[21:51:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:51:54] * mru needs to figure out a way to do 1-click commit from patchwork
[21:52:27] <BBB> whatever you do now is quite good - your patchapplyspeed is amazing
[21:52:31] <BBB> for me it takes minutes per patch
[21:53:15] <mru> that's because I use a proper mail reader
[21:53:28] <mru> I can send a patch to git with a couple of keystrokes
[22:18:23] <spaam> BBB: you now.. mru are running gentoo in his emacs os.. super fast.
[22:18:31] <spaam> s/now/know
[22:21:09] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r187e23478b ffmpeg/libavformat/mp3enc.c:
[22:21:09] <CIA-29> ffmpeg: mp3enc: add support for writing UTF-16 tags
[22:21:09] <CIA-29> ffmpeg: Also it gets rid of some mysterious magic numbers in code.
[22:21:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:21:24] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r8f4a5d225c ffmpeg/libavcodec/dca.c: (log message trimmed)
[22:21:24] <CIA-29> ffmpeg: dca: consider a stream with XXCh/X96 in ExSS as DTS-HD HRA
[22:21:24] <CIA-29> ffmpeg: DTS-HD HRA streams do not always have an XBR extension in the extension
[22:21:24] <CIA-29> ffmpeg: substream. Instead they can have only XXCh and X96 extensions in
[22:21:25] <CIA-29> ffmpeg: there and still be considered DTS-HD HRA.
[22:21:25] <CIA-29> ffmpeg: This is also confirmed with Onkyo TX-SR607 receiver which recognizes
[22:21:26] <CIA-29> ffmpeg: such a stream as HiRes Audio.
[22:31:19] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r69915b48d6 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h):
[22:31:19] <CIA-29> ffmpeg: iir: Change dst param to float* in ff_iir_filter_flt().
[22:31:19] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:34:46] <astrange> BBB: are you using mail.app?
[22:35:15] <mmu> Mail.app suxor
[22:35:37] <mmu> OSX suxor anyway, I really need to change
[22:36:13] <mru> mmu: I thought you ran beos
[22:37:04] <mmu> on this machine
[22:37:12] <mmu> and Haiku
[22:37:15] <mmu> but I got a mac last year
[22:37:27] <mmu> was kinda forced into it
[22:37:35] <lotharkript>    
[22:37:35] <lotharkript> dw
[22:37:35] <lotharkript> aqw
[22:37:35] <lotharkript> daqw
[22:37:39] <mmu> been finding a bug a day in OSX since then
[22:37:50] <mmu> now I know my ennemy, I can switch back :)
[22:38:53] <astrange> it changes faster than haiku, the release rate is just less
[22:39:09] <mru> why would anyone decide to get a mac?
[22:39:22] <mmu> it was beyond me before
[22:39:26] <mmu> now it's even further
[22:39:35] <mru> apple fans don't make that decision, the steve does
[22:39:45] <mmu> well, some things do work fine
[22:39:46] <mmu> like suspend
[22:40:02] <mru> I care more about how well my computer works when it's running
[22:40:04] <mmu> but there are so many unfinished things
[22:40:14] <mru> and my sony suspends just fine
[22:40:23] <mmu> well yeah but it allows you to keep Safari or Firefox running for months
[22:40:37] <mmu> until you have to kill them because they eat 3GB of RAM
[22:40:46] <mru> I was getting to that part
[22:41:37] <mmu> what is even nastier is OSX allocates by default as much swap as needed
[22:42:11] <mmu> so sometimes you see a popup telling "Oh, I don't have enough disk space for swap, I stopped Firefox and Safari, free up some space, and click to resume them"
[22:42:17] <astrange> no it doesn't
[22:42:17] <mmu> supposedly they got SIGSTOP
[22:42:25] <astrange> swapfiles are dynamic in /var/vm
[22:42:30] <mmu> which is nice, but their popup doesn't work usually
[22:42:37] <astrange> did you make a really small boot partition?
[22:42:43] <mmu> so you have to send them SIGCONT manually
[22:43:12] <mru> one of the things I truly detest about macos is the global menubar
[22:43:19] <mmu> first thing I did was split the disk to have a 100Go with case sensitive HFS for real work
[22:43:33] <mru> even for a small window near the bottom of the screen, one has to mouse all the way to the top to do anything
[22:43:37] <mmu> but yeah the boot partition sometimes get filled with video recordings
[22:43:42] <mru> and that makes focus-follows-mouse useless too
[22:44:10] <astrange> if you configure it in a way nobody else does you will run into problems nobody else runs into
[22:44:12] <mmu> another thing, for a BeOS user used to 32 workspaces that do work... their Spaces thing is totally buggy
[22:44:18] <astrange> symlink /var/vm to a larger partition might work
[22:44:23] <mmu> it's clearly an afterthought
[22:44:32] <mru> 32 seems plenty indeed
[22:44:45] * mru has 6 on each of 2 monitors
[22:44:47] <mmu> that's the max as it's a bitmask
[22:44:51] <mru> independently switchable
[22:44:57] <mmu> windows can be on more than 1
[22:45:05] <mru> same here
[22:45:19] <mmu> it's actually virtual desktops, screens are handled by BScreen class, though BeOs never supported more than 1
[22:46:01] <mmu> in OSX, pressing the hotkey for changing Space rapidly will make it go nuts for several seconds due to the useless animation
[22:46:17] <mmu> then when you get back it's another window that has the focus
[22:46:29] <mmu> sometimes even one you don't see cause it's the one under all otehrs
[22:47:34] <mmu_man> wget(64427) malloc: *** error for object 0x101f8b970: pointer being freed was not allocated
[22:47:37] <mmu_man> *** set a breakpoint in malloc_error_break to debug
[22:47:49] <mmu_man> hmm wget -m on a 600MB website...
[22:47:49] <mru> valgrind
[22:48:00] <mmu_man> I don't think there is a port to OSX
[22:48:11] <mmu_man> seems it got a 404 right before
[22:48:12] <mmu_man> oh well
[22:50:53] <astrange> valgrind 3.6 works on os x
[22:50:57] <astrange> (current release)
[22:54:55] <mmu_man> ah good to know
[22:55:09] <mmu_man> should try porting it to Haiku someday
[22:55:14] <mmu_man> I think Ingo wrote a similar tool
[22:55:20] <mru> can't be terribly hard
[22:55:23] <mmu_man> he actually wrote his own full GUI debugger
[22:55:31] <mmu_man> he probably didn't like gdb
[22:55:53] <mru> can't blame him
[22:55:55] <mmu_man> but then he puts C++ in the kernel almost each commit too, so... >:-)
[22:56:05] <mru> can blame him
[22:59:32] <jannau> grrr! web stuff. I can't get the auth working for the patchwork xmlrpc stuff which is required to update patches
[23:01:21] <jannau> mru: http://wiki.openembedded.net/index.php/Patchwork has a script to feed patches from patchwork to git am
[23:01:43] <merbanan> this patchwork thingy
[23:01:50] <mru> what sort of script?
[23:02:07] <merbanan> is there some keyword one can say that will mark a sent patchs as oked ?
[23:02:25] <mru> jannau: I don't need that
[23:02:27] <jannau> shell,perl,python, whatever. that's probably easier than clicking
[23:02:42] <mru> I want a way to click the mbox link in firefox and have it fed to a script of my choosing
[23:03:07] <mru> which is possible with the somewhat unreliable "open with" option
[23:03:21] <mru> it has the habit of reverting back to save or switching apps randomly
[23:03:54] <jannau> custom mime type, x-patchwork/x-project
[23:04:30] <mru> that's something the server would have to do
[23:05:18] <jannau> sure, it shouldn't be a huge problem to add that
[23:16:53] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * rf4096bf6ee ffmpeg/libavcodec/dca.c:
[23:16:53] <CIA-29> ffmpeg: dca: add profile names
[23:16:53] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:22:08] <jannau> updating patches works, not sure if from git hook
[23:22:52] <mru> there should be a ping button that sends a ping to the ml
[23:23:57] <jannau> if someone has a patch queued it would be help if itcan be pushed
[23:25:37] <mru> as soon as some more get approved...
[23:25:47] <_av500_> mru: and a nitpick button?
[23:26:21] <mru> _av500_: send mail with randomly inserted comments like "alignment", "alphabetical order"?
[23:26:35] <_av500_> yeah
[23:27:02] <_av500_> btw, can smb review my flv review?
[23:27:46] <jannau> flvtool2 indices one, I didn't since I had more nitpicks
[23:27:52] <jannau> +the
[23:28:40] <_av500_> ?
[23:28:47] <_av500_> yes this one
[23:30:51] <_av500_> how its done looks way more complicated compared to what my stuff does
[23:30:59] <_av500_> but thats due to the overrecusrivesness
[23:41:59] <mru> send more email, we've falled to #9 on gmane top 10
[23:42:03] <mru> *fallen
[23:43:11] <jannau> patchwork missed the updated patch for http://patchwork.libav.org/patch/171/
[23:46:24] <jannau> _av500_: he seems to like long lines, defines and variable names