[FFmpeg-devel-irc] IRC log for 2010-09-28

[irc at mansr.com]

[00:09:02] <mchinen> do people on mac get "xargs: illegal option --d" error messages when running patcheck?
[00:09:21] <mchinen> *illegal option -- d
[00:11:05] <lu_zero> which os are you on?
[00:27:35] <bcoudurier> mchinen, yes
[00:28:41] <mchinen> bcoudurier: is this preventing some checks?
[00:28:54] <mchinen> lu_zero: mac 10.5
[00:29:25] <mru> whoever wrote the script obviously show complete contempt of standards
[00:30:37] <mru> or possibly whoever wrote macos
[00:30:53] <mru> though they tend to follow posix pretty well, actually
[00:31:53] <mru> standard xargs has no -d option
[00:32:58] <mchinen> what does it do?
[00:33:37] <mru> in gnu xargs it changes the record delimiter
[00:34:14] <CIA-63> ffmpeg: bcoudurier * r25240 /trunk/libavformat/mov.c: In mov demuxer, check that nb_streams is valid before using it in read_dac3
[00:37:04] <lu_zero> ^^;
[00:37:25] <lu_zero> nite
[02:06:01] <CIA-63> ffmpeg: astrange * r25241 /trunk/ (ffplay.c cmdutils.c cmdutils.h): Extract timestamp correction code from ffplay.c to cmdutils.c
[03:23:23] <bcoudurier> indeed the temperature today broke the record of LA
[03:23:27] <bcoudurier> 113 high
[03:34:44] <saintdev> that's your new onjoin?!
[03:36:21] <j0sh> lol
[03:46:13] <CIA-63> ffmpeg: astrange * r25242 /trunk/cmdutils.c: (log message trimmed)
[03:46:13] <CIA-63> ffmpeg: All else being equal, prefer PTS over DTS in timestamp correction
[03:46:13] <CIA-63> ffmpeg: Because DTS values aren't passed through decoders, they tend to be
[03:46:13] <CIA-63> ffmpeg: inaccurate if decoder delay doesn't match what was expected by the encoder.
[03:46:13] <CIA-63> ffmpeg: In particular this improves timestamps for H.264 without num_reorder_frames
[03:46:14] <CIA-63> ffmpeg: set and with -strict 1, which causes DTS to be up to 16 frames ahead of the
[03:46:15] <CIA-63> ffmpeg: picture.
[03:48:54] <astrange> 4 paragraphs for 1 character commit...
[04:07:28] <astrange> bcoudurier: https://roundup.ffmpeg.org/issue2251 know anything about this?
[06:15:56] <KotH> salve
[06:27:47] <benoit-> moin
[06:28:17] <benoit-> KotH: are you interested in receiving complains from people about the website certificate?
[06:28:30] <benoit-> (I wonder if we should create a list for that)
[06:29:19] * _av500_ gives KotH a bunch of unspecific complaints
[06:30:51] <KotH> benoit-: certificate?
[06:31:03] * KotH complains to the big troll about _av500_ 
[06:31:25] <benoit-> KotH: ssl certificate
[06:31:35] <KotH> hmm..
[06:31:49] <KotH> benoit-: send the complains to diego please. he handles the certificates
[06:32:33] <benoit-> KotH: OK, I'll just send them to /dev/null then
[06:32:48] <KotH> hmm? why /dev/null?
[06:33:08] <benoit-> I don't think there is any plan having a 'signed by someone who is trusted' version of the certificate
[06:33:25] <KotH> uhmm.. no
[06:33:47] * KotH could get a x500 cert if he wanted to, but it's too much work for very little benefit
[06:33:52] <benoit-> quoting the complaint: "[the website] produces a security certificate violation.  I don't join websites that are insecure."
[06:34:04] <KotH> well....
[06:34:20] <benoit-> which is fine by me, if you ask me
[06:34:32] <KotH> benoit-: if you are in the mood, you can answer him that his security policy is flawed
[06:34:44] * benoit- checks his mood
[06:34:55] <saintdev> but someone could be eavesdropping on roundup comments!
[06:34:59] <_av500_> sm ppl prefer certs signed by NSA...
[06:35:09] <KotH> other than that... /dev/null is ok for such mails
[06:35:11] <_av500_> err, verisign
[06:35:52] <peloverde> some one at FOSDEM was doing free certs for OSS projects
[06:35:57] <benoit-> KotH: almost related: do you know who receives mails to root at ffmpeg.org?
[06:36:26] <KotH> root at mphq
[06:36:36] <KotH> hmm.. maybe
[06:36:46] <KotH> it could get rejected by natsuki too...
[06:37:13] <mru> let's try
[06:37:14] <benoit-> I'll try, we'll see
[06:37:19] <saintdev> peloverde: <mru> if someone who knows aac were to work on it, how long before it would compete with faac in quality? compete with good encoers?
[06:37:20] <saintdev> <mru> weeks, monts, years?
[06:37:47] <saintdev> it being the aac encoder
[06:38:25] <peloverde> faac probably a month, the good encoders 4-8 months
[06:38:43] <saintdev> wow i guessed right, lol
[06:38:47] <benoit-> KotH, mru: <root at ffmpeg.org>: Relay access denied (in reply to RCPT TO command)
[06:38:52] <KotH> benoit-: juup
[06:39:13] <KotH> benoit-: should these mails be handled? if yes, why? and how?
[06:39:58] <benoit-> KotH: I think that yes, they should, because the domain name is valid :)
[06:40:10] <mru> KotH: I think accepting @ffmpeg.org mail makes sense
[06:40:47] <benoit-> mru: every devel is going to claim is @ffmpeg.org email address :)
[06:40:52] <benoit-> ouch
[06:40:59] <mru> I didn't say that
[06:41:00] <benoit-> claim his
[06:41:12] <mru> only that standard aliases should be accepted
[06:41:13] <benoit-> mru: I know. I did
[06:41:16] <mru> root, webmaster, etc
[06:41:35] <saintdev> peloverde: i wasn't sure about good encoders. i was thinking about a year, but didn't state that :)
[06:41:50] <Dark_Shikari> hmm.  re the thread on legal, how much do you think getting 10-bit h264 decoding in ffmpeg would cost?
[06:42:25] <Dark_Shikari> might be hard considering ffmpeg has no non-trivial >8-bit decoders
[06:42:30] <Dark_Shikari> and assumes 8-bit everywhere
[06:50:26] <bcoudurier> it's not that hard to deal with, I've had dnxhd decoding 10bits
[06:51:00] <mru> Dark_Shikari: obviously all the asm would need rewriting
[06:51:05] <mru> and much of the C code
[06:51:06] <bcoudurier> astrange, there is a bug, the pts of the packet should not be overwriten
[06:54:35] <Tjoppen> ooh, drama on the list
[06:55:01] <astrange> -fflags +nofillin+noparse doesn't change it which should limit the code affecting it
[06:55:02] <Dark_Shikari> mru: we're doing a lot of the asm in x264
[06:55:09] <astrange> (or i just typed the option wrong)
[06:55:17] <Dark_Shikari> we can contribute deblocking, idct, and parts of the MC
[06:55:20] <Dark_Shikari> and whatever intra pred we do
[06:55:33] <Dark_Shikari> I suspect most of the C code can be kept the same
[06:55:53] <Dark_Shikari> particularly if we define stride such that if our image is a uint8_t *
[06:56:01] <Dark_Shikari> that stride = (number of pixels of stride)*2
[06:56:15] <Dark_Shikari> the other option is to template the decoder.
[06:56:26] <Dark_Shikari> or, at least, the part of the decoder that accesses pixels.
[07:04:42] <bcoudurier> that's strange I get pts 0 dts 0 for the first frame
[07:27:18] <kshishkov> Dark_Shikari: we have some >8-bit image decoders, including JPEG-LS
[07:27:53] <Dark_Shikari> yeah, but those avoid mpegvideo
[07:27:59] <Dark_Shikari> but yeah, those might be good inspiration
[07:31:43] * kshishkov wonders if "trivial" really means "not using mpegvideo stuff"
[07:32:56] <Dark_Shikari> Basically, for video, yeah
[07:32:57] <Dark_Shikari> lol
[07:33:58] <Dark_Shikari> i.e. any sufficiently complex video decoder will eventually use mpegvideo
[07:34:11] <bcoudurier> night guys
[07:35:36] * kshishkov thinks that a good troll impulse to write complex decoder without mpegvideo - probably for Indeo
[07:37:14] <Dark_Shikari> michael will reject
[07:37:14] <Dark_Shikari> lol
[07:37:50] * kshishkov looks at Indeo5 decoder - no mpegvideo so it's trivial
[07:38:04] <mru> vp568
[07:38:11] <Dark_Shikari> even vp568 calls ff_emulated_edge_mc
[07:38:15] <Dark_Shikari> an mpegvideo function
[07:38:15] <mru> oh
[07:38:26] <mru> isn't that function a bit messed up?
[07:39:45] <Dark_Shikari> >mpegvideo
[07:39:47] <Dark_Shikari> >messed up
[07:39:51] <Dark_Shikari> department of redundancy department
[07:40:06] <kshishkov> careful, you may awaken elenril
[07:40:20] <mru> is there a trope for that?
[07:40:43] <kshishkov> IIRC it's named exactly like what DS just said
[07:41:06] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/DepartmentOfRedundancyDepartment
[07:41:19] <Dark_Shikari> I love the quote
[07:41:19] <Dark_Shikari> "The offensive lineman are the biggest guys on the field. They're bigger than everyone else, that's why they're the biggest guys on the field."
[07:41:23] <Dark_Shikari> —John Madden
[07:42:17] * kshishkov is pretty sure that the next blockbuster should feature life of Captain Obvious
[07:43:32] <mru> Dark_Shikari: hmm, that page links to itself
[07:43:46] <Dark_Shikari> mru: http://tvtropes.org/pmwiki/pmwiki.php/Main/ShapedLikeItself ?\
[07:44:11] <mru> no, the DoRD
[07:44:25] <mru> "Compare ... Department Of Redundancy Department."
[07:44:27] <Dark_Shikari> well yes, but I was making a reference to that one intentionally
[07:44:27] <Dark_Shikari> =p
[07:44:28] <kshishkov> mru: isn't that just natural?
[07:44:36] <mru> of course
[07:59:39] <Tjoppen> getting crashes in the h264 decoder when I seek. I suspect it has to do with the recent reference frame thing
[07:59:59] <cartman> Tjoppen: backtrace or it didn't happen
[08:00:04] <cartman> also a sample too
[08:01:51] <Dark_Shikari> Tjoppen: yeah, in theory it should only affect seeking to non-keyframes
[08:01:54] <Dark_Shikari> which you shouldn't be doing
[08:01:58] <Dark_Shikari> And yeah, backtrace
[08:02:06] <Dark_Shikari> and feel free to revert it
[08:02:25] <mru> Dark_Shikari: the decoder should never crash
[08:03:00] <Tjoppen> I'm seeking in mpegts, and that demuxer doesn't seem to seek to keyframes
[08:03:02] <av500> mru: hey, thats what I keep tellin the indians...
[08:03:31] <Dark_Shikari> mru: it shouldn't crash either way
[08:03:42] <Dark_Shikari> and yes I'd like a backtrace
[08:03:50] <Dark_Shikari> my point is that patch shouldn't _affect_ anything unless seeking to non-keyframes.
[08:03:56] <kshishkov> av500: if it crashes then your belief in Brahma is not strong enough
[08:04:39] <Tjoppen> I'll upload a sample. just need to see if it still happens when cut down to size
[08:05:45] <Dark_Shikari> I want a backtrace
[08:06:17] <cartman> mooooaaaaar
[08:06:24] <Tjoppen> :)
[08:06:43] * cartman fixes yet another build breakage in WebKit
[08:06:51] <av500> kshishkov: my belief in Brahme is zero
[08:07:19] <kshishkov> av500: that's why your karma prevents you from having perfect Indian decoders
[08:07:41] <av500> kshishkov: they are perfectly indian decodes
[08:07:44] <av500> +r
[08:08:24] <kshishkov> "perfect (yet) Indian" and "perfectly Indian" differ a bit
[08:08:48] <av500> subtly eh? :)
[08:09:14] * kshishkov lived in European-style India so he's sure Indian code quality is the best
[08:09:49] <av500> kshishkov: usually we got asked "what is the use case and what content do you need to play"
[08:09:59] <av500> we always answered "all that is out there"
[08:10:42] <av500> and "btw, ffmpeg decodes it correctly"
[08:10:58] * kshishkov is glad FFmpeg was used for trolling
[08:11:12] <Tjoppen> making a clean compile against master. will take a few mins
[08:25:43] <lu_zero> good morning
[08:27:23] <kshishkov> buon giorno
[08:27:35] <lu_zero> god morgon kshishkov
[08:28:30] <Tjoppen> I hope an ffplay trace is ok. ffmpge -ss 10 and transcoding video didn't trigger it
[08:28:41] <spaam> lu_zero: hur är det idag? :)
[08:30:43] <Tjoppen> roundup is down?
[08:31:14] <mru> rounddown?
[08:31:17] <lu_zero> Tjoppen: uhm?
[08:31:29] <Tjoppen> I'll pastebin the trace for the time being
[08:31:58] <Tjoppen> there we go. just really slow
[08:32:02] <lu_zero> seems working
[08:32:10] <lu_zero> and fast enough
[08:32:40] <Tjoppen> 10-20 sec response time isn't my idea of fast
[08:32:49] <lu_zero> Tjoppen: uhm?
[08:33:01] <mru> welcome to the wonderful world of python
[08:33:36] <lu_zero> mru: python has nothing with roundup being stupid.
[08:33:48] <mru> there are many stupid python coders
[08:33:53] <mru> apparently some of them wrote roundup
[08:33:59] <elenril> s/python//
[08:33:59] <lu_zero> or mysql being stupid
[08:34:12] * elenril yawns
[08:34:46] <lu_zero> or roundup having ....
[08:34:55] <lu_zero> 1.7GB of trash inside it.
[08:36:21] <lu_zero> that reminds me that this beast should be migrated
[08:36:56] <lu_zero> and maybe I should figure out why it is taking this much cpu
[08:39:30] <lu_zero> apache is strange...
[08:39:57] <mru> tell me
[08:40:14] <mru> guess why we switched mphq to lighttpd
[08:40:16] * kshishkov wonders what ViewVC formerly installed on MPHQ was written with?
[08:40:22] <mru> python
[08:41:19] <kshishkov> have you found where it improted cpueater and diskdestroyer modules?
[08:41:41] <Tjoppen> Dark_Shikari: https://roundup.ffmpeg.org/issue2253
[08:42:24] <Dark_Shikari> duplicate
[08:42:26] <Dark_Shikari> see issue 2250
[08:42:52] <Dark_Shikari> Oh.  I think I know what the bug is already.
[08:42:53] <lu_zero> kshishkov: I could point you to rt if you wish
[08:44:01] * lu_zero will not write yet another bug tracker....
[08:44:37] <mru> rt is a bit weird
[08:44:42] <mru> they all are
[08:45:28] <cartman> try debbugs
[08:45:34] <cartman> and see whats really weird
[08:46:24] <mru> another contribution from the department of redundancy department
[08:46:27] <Dark_Shikari> Tjoppen: can you test a patch
[08:47:06] <Dark_Shikari> http://pastebin.com/5W1zE33p
[08:47:42] <lu_zero> bugzilla isn't bad
[08:47:45] <lu_zero> (now)
[08:48:06] <mru> it has far too many weird fields
[08:48:11] <Tjoppen> Dark_Shikari: ok
[08:48:27] <lu_zero> now you can remove and add your ones
[08:50:13] <Tjoppen> Dark_Shikari: nope. still crashes
[08:50:32] <Tjoppen> still in av_image_copy()
[08:50:59] <mru> hmm, gcc as 20 open bugs matching "ffmpeg"
[08:51:39] <lu_zero> _just_ 20?
[08:51:59] <mru> those are the _open_ ones
[08:52:26] <cartman> Trunk status -- stage 1 || Still 114 regressions in 4.3, 115 in 4.4, 118 in 4.5 and 177 in 4.6
[08:52:31] <kshishkov> were the rest of them closed with resolutions "invalid" or "wontfix"?
[08:52:32] <cartman> don't hold your breathe
[08:52:52] <mru> 96 total
[08:53:08] <Dark_Shikari> Tjoppen: http://pastebin.com/As8AhLds
[08:54:19] <Tjoppen> k
[08:54:43] <Tjoppen> nope. crash
[08:55:11] <Dark_Shikari> WTF?
[08:55:12] <Tjoppen> but: only in decode_slice_header
[08:55:19] <Dark_Shikari> er...
[08:55:26] <Dark_Shikari> wait.  it's not even crashing in the same place?
[08:55:27] <Dark_Shikari> or what
[08:56:05] <Tjoppen> indeed
[08:56:11] <Dark_Shikari> give me the backtrace
[08:56:12] <Dark_Shikari> not psychic here
[08:57:10] <Tjoppen> http://ffmpeg.pastebin.com/amZja7BH
[08:57:47] <twnqx> hm
[08:58:08] <Dark_Shikari> oh duh I'm stupid
[08:58:40] <Dark_Shikari> http://pastebin.com/grCKVXc5
[08:58:41] <twnqx> so this .pss format is a variant of mpeg-ps with WAV inside
[08:59:40] <twnqx> i have a windows tool to demux it... but i'd like something else... like, ffmpeg :P
[09:01:30] <pJok> twnqx, write your own demuxer? ;)
[09:01:46] <twnqx> if i had a format description i would
[09:01:57] <twnqx> likely it's just a small change to the .ps demuxer
[09:01:58] <Tjoppen> Dark_Shikari: works
[09:02:23] <Tjoppen> I harassed ffplay pretty good with seeking forward and backward. apart from the obvious crappy image, it handled it fine
[09:02:52] <mru> twnqx: mpegps with wav inside? wtf?
[09:03:20] <twnqx> mru: this is all i found so far: http://www.zophar.net/utilities/ps2util/pss-plex.html
[09:04:44] <kshishkov> probably it's PCM or even MP3, WAV is just container here to store audio separately
[09:05:49] <twnqx> PCM, he's explicitly talking about uncompressed audio streams
[09:05:58] <twnqx> (optionally adpcm it seems)
[09:06:23] <Dark_Shikari> Tjoppen: applied
[09:06:30] <twnqx> ffmpeg at the moment only detects the video stream
[09:07:04] <mru> pcm containers are usually easy to RE
[09:07:08] <mru> do you have a sample?
[09:07:12] <twnqx> yeah
[09:07:18] <CIA-63> ffmpeg: darkshikari * r25243 /trunk/libavcodec/h264.c:
[09:07:18] <CIA-63> ffmpeg: Try to fix crashes introduced by r25218
[09:07:18] <CIA-63> ffmpeg: r25218 made assumptions about the existence of past reference frames that
[09:07:18] <CIA-63> ffmpeg: weren't necessarily true.
[09:07:33] <twnqx> but it's somewhere inside the ps stream, so i guess it's just unsupported streams
[09:07:40] <mru> yeah
[09:07:56] <mru> but they must be identified somehow
[09:07:58] <twnqx> apparently even multiple streams (multiaudio) are possible
[09:08:11] <Tjoppen> Dark_Shikari: nice
[09:08:12] <twnqx> i'll just debug the ps demuxer in the evening
[09:08:13] <twnqx> :)
[09:08:34] <mru> I'd rather use a ps analyser and hex viewer
[09:09:52] <kshishkov> mru: I thought ps analyzer was you
[09:15:21] <twnqx> mpegps is libavformat/mpeg.c, right?
[09:19:10] <twnqx> make: *** No rule to make target `libavcodec/x86/dsputil_h264_template_mmx.c', needed by `libavcodec/x86/dsputil_mmx.o'.  Stop.
[09:19:13] <twnqx> hm
[09:19:20] * twnqx distcleans
[09:19:56] <mru> plain clean is enough
[09:32:14] <twnqx> es_type 0 startcode ff
[09:32:16] <twnqx> ok...
[09:33:58] <mru> where's the sample?
[09:34:19] <twnqx> what's the ftp again?
[09:34:46] <mru> upload.ffmpeg.org
[09:36:43] <twnqx> 80MB file - cut or do you want all?
[09:37:02] <mru> enough to contain a few frames of that audio is enough
[09:37:45] <twnqx> incoming/pss/pcm-in-mpeg-ps.pss
[09:38:15] <KotH> twnqx: dont forget the .txt file :)
[10:02:41] <twnqx> oh yeah...
[10:06:38] <twnqx> thanks for the reminder, koth :)
[10:06:46] <twnqx> mru: the large file can be deleted if you bother
[10:12:28] <twnqx> mru: should i try to grab a multilingual sample as well?
[10:41:30] <twnqx> mru: found a starting point to .pss demuxing - Arktool sourcecode
[10:42:25] <mru> seems to use private_stream_1
[10:43:17] <mru> look at offset 0x8000 in the file
[10:46:01] <twnqx> const u8 PssVgsAccess::S_FIRST_HEADER[4]        = { 0x00, 0x00, 0x01, 0xBA };
[10:46:04] <twnqx> that matches.
[10:46:16] <mru> that's the pack header
[10:46:27] <mru> the payload starts at 0x8021
[10:47:15] <twnqx> from what i grapsed by skimming through this source it's something the author alls a VGS file inside
[10:48:17] <twnqx> oh well. gonna have to play with this a bit :)
[10:51:09] <mru> some kind of header at 0x8025
[10:51:14] <mru> 4-byte tag
[10:51:21] <mru> 4-byte size (LE)
[10:51:33] <mru> some 32-bit number
[10:51:42] <mru> 32-bit LE sample rate
[10:52:11] <mru> another 32-bit number (channels?)
[10:52:16] <mru> value 2
[10:52:20] <twnqx> yeah, it's stereo
[10:52:32] <mru> the first number might be a format tag
[10:52:34] <mru> 1 = pcm?
[10:52:45] <mru> then ff padding
[10:52:49] <twnqx> it supports variants (pcm, adpcm)
[10:53:07] <mru> 0x8045 another packet header
[10:53:12] <mru> tag SSbd
[10:54:26] <mru> meaning of 00 0c 52 01 not obvious
[10:54:32] <mru> pcm samples follow
[10:55:04] <mru> s16le by the looks of it
[10:55:13] <twnqx> at least in this case, yes
[10:55:36] <mru> do you have an adpcm sample?
[10:55:55] <twnqx> not yet, guess i'd have to download one of the mentioned ps2 isos
[10:55:56] <mru> that first 32-bit value probably indicates the sample format
[10:57:12] <mru> see, pcm formats are easy to figure out
[11:10:20] <twnqx> #define PACK_START_CODE             ((unsigned int)0x000001ba) <- does that actually work on BE machines?
[11:10:36] <mru> depends on how you read the file
[11:10:41] <mru> and that cast is nonsense
[11:10:55] <twnqx> it's from mpeg.h in ffmpeg :P
[11:11:01] <mru> nonsense nonetheless
[11:11:16] <mru> ffmpeg works on BE machines btw
[11:11:30] <twnqx> interesting
[11:11:46] <av500> and ME?
[11:11:54] <mru> no
[11:12:09] <twnqx> code = (code<<8) + p->buf[i]; <- ok, it build the code it compares with byte by byte
[12:04:14] <Dark_Shikari> holy fucking retards, my intelligence is being destroyed
[12:04:18] <Dark_Shikari> someone emailed me for ffmpeg help
[12:04:21] <Dark_Shikari> I told them two things
[12:04:29] <Dark_Shikari> qt-faststart input.mp4 output.mp4
[12:04:35] <Dark_Shikari> s/-b 3000000/-crf 22/
[12:04:36] <mru> intellectual osmosis?
[12:04:45] <Dark_Shikari> They then INSERTED these LITERALLY into their commandline
[12:04:58] <Dark_Shikari> -vcodec libx264 s/-b 3000000/-crf 22/ ...
[12:05:05] <mru> lol
[12:05:12] <lu_zero> wow
[12:05:19] <mru> like the guy who ran configure --usual-options
[12:05:23] <Dark_Shikari> LOL
[12:05:23] <mru> literally
[12:05:58] <lu_zero> mru: a patch that actually replies to --usual-options with a message would be too much?
[12:06:04] <Dark_Shikari> Hah.
[12:06:32] <mru> sorry dave, I can't do that
[12:06:47] <lu_zero> mru: that would be fit
[12:07:13] <jannau> wtf micheal
[12:07:30] <jannau> "Things should be consistent, either everyone should be listed with name or noone"
[12:08:02] <kshishkov> sounds like communism
[12:10:59] <mru> wtf indeed
[12:11:13] <mru> and of course he didn't say how he wants his name
[12:11:42] <kshishkov> fried and with mustard
[12:11:48] <microchip_> signed, M. Troll
[12:11:59] <lu_zero> kshishkov: with or w/out cheese?
[12:12:28] <kshishkov> lu_zero: probably without
[12:13:34] <jannau> it'll be hard to make sure that nobody commits with full name and email after the full conversion
[12:14:03] <lu_zero> uhm?
[12:14:13] <lu_zero> I'm missing the start
[12:14:21] <jannau> mru: I would say he doesn't care
[12:14:41] <mru> I promise I will
[12:15:01] <kshishkov> lu_zero: in future official ffmpeg git repo
[12:15:37] <jannau> lu_zero: if we decide not to use full names + email for consistancy it will be doomed when all are using git to push to the central repo
[12:16:47] <benoit-> "open source people don't have any money so they don't have girlfriends and can't go to nice restaurants"
[12:17:16] <benoit-> I must admit I laughed a lot on this one
[12:17:32] <mru> desperate troll is desperate
[12:18:14] <KotH> mru: correction: this guy is that stupid
[12:18:32] <Dark_Shikari> mru: aha.  I see what happened here with the retardation
[12:18:49] <Dark_Shikari> the CEO had emailed me, and attempted to implement my instructions himself rather than, you know, give them to the guy who's actually coding
[12:19:02] <Dark_Shikari> as a "quick fix"
[12:19:05] <mru> lol
[12:20:48] <lu_zero> oh...
[12:22:16] <thresh> the real lol if it made to a product
[12:22:46] <av500> for me "--usual-options" would just be ignored
[12:23:42] <mru> sometimes with such people I'm tempted to tell them rm -rf /
[12:23:55] <mru> possibly slightly obfuscated
[12:24:03] <kshishkov> it may fail for them too
[12:24:35] <kshishkov> "leave a Russian in an empty room with two cannonball and he'll manage to break one and lose another"
[12:25:01] <av500> kshishkov: impossible, one would have been stolen before already...
[12:25:34] <kshishkov> av500: what makes you say that?
[12:45:50] <av500> err, http://ucnv.github.com/aviglitch/
[12:47:01] <cartman> how useful, reminds me of old times
[12:47:27] <thresh> av500: so the guy actually reinvented zzuf?
[12:47:36] <kshishkov> zzuf is more realistic
[12:50:20] <av500> i dont thing the purpose of this one is the same of zzuf
[12:50:24] <av500> think :)
[12:50:39] <av500> this one is more about being artistis
[12:50:41] <av500> this one is more about being artistic
[12:50:48] <kshishkov> yes, it's merely a toy while zzuf is a serious diagnostic tool
[12:52:02] <cartman> av500: say that again?
[12:53:10] <kshishkov> av500: and you're gravely wrong. Had it been artistic, it'd corrupt MOV instead.
[12:59:58] <thresh> :))
[13:03:44] <twnqx> mru: are you maintaining the mpeg-ps demultiplexer?
[13:03:52] <twnqx> there's so much stuff that doesn't make sense to me...
[13:04:02] <kshishkov> then learn it
[13:05:02] <mru> mpegps is a very simple format
[13:05:13] <twnqx> i meant the code, not the format
[13:05:23] <mru> if you ignore the never-seen-in-the-wild program stream directory
[13:05:33] <mru> yes, mpegps has an optional index
[13:05:54] <kshishkov> like NUT :)
[13:06:00] <mru> it's a bit weird
[13:06:02] <mru> like nut
[13:06:58] <twnqx> if (startcode == PRIVATE_STREAM_1 && !m->psm_es_type[startcode & 0xff]) {
[13:07:08] <twnqx> i don't quite get the second part
[13:07:21] <twnqx> startcode & 0xff would be const, no?
[13:07:47] <kshishkov> yes, but it'd be less obvious
[13:07:47] <twnqx> since startcode == const has been checked first
[13:08:36] <mru> there's a lot in that demuxer that's less obvious
[13:10:12] <lu_zero> btw
[13:10:39] <lu_zero> by default the index is not written by the ffmpeg muxer, isn't it?
[13:11:07] <mru> I have never seen anything read or write a PSD
[13:12:46] <twnqx> hm
[13:16:05] <twnqx> right, so the code doesn't handle my stream types nicely and kills the "private stream 1" startcode and replaces it with 0xff stream id - i wonder if i should keep it like that or make it keep "private stream 1" type
[13:17:21] <twnqx> because the private stream is not listed in the program stream map.
[13:17:31] <CIA-63> ffmpeg: stefano * r25244 /trunk/ (5 files in 2 dirs):
[13:17:31] <CIA-63> ffmpeg: Add the drawbox filter from the soc libavfilter repo.
[13:17:31] <CIA-63> ffmpeg: Pedagogically useful.
[13:17:38] <twnqx> (or there just is no map)
[13:19:11] <twnqx> can i undo get_byte() somehow?
[13:45:01] <CIA-63> ffmpeg: stefano * r25245 /trunk/configure: Group togheter filter dependency specifications.
[14:21:33] <jannau> bah, git cherry-pick can't pick empty commits
[14:22:40] <mru> why would you want an empty commit?
[14:24:32] <lu_zero> and how you managed to push an empty commit?
[14:24:38] <av500> they have the least bikeshedding...
[14:24:43] <twnqx> mru: why is } else if (startcode == 0x1bd) { used and not } else if (startcode == PRIVATE_STREAM_1) {?
[14:24:55] <mru> twnqx: I didn't write that code
[14:25:00] <twnqx> ah ok
[14:25:11] <jannau> the script was stopping due to 'set -e'
[14:25:12] <mru> av500: even empty bikesheds have a colour
[14:25:28] <lu_zero> interesting... av_interleave_write_frame needs an avcodec_encode_foo before =_=
[14:26:09] * lu_zero wanted to pass directly AVPackets but that confuses some of the inner logic...
[14:26:33] <twnqx> mru: so if i'd feel the urge to totally refactor some code for brokenness...
[14:26:38] <mru> lu_zero: it's lavf...
[14:26:41] <jannau> git svn created the empty commit. it was a "dos2unix" commit
[14:26:49] <mru> twnqx: it's not me you should be talking to
[14:27:04] <twnqx> like being unable to see dvd audio streams if there's no program stream map
[14:27:08] <mru> jannau: dos was already unix?
[14:27:19] <twnqx> who would i ask? just propose the patch on the mailing list?
[14:27:46] <kshishkov> probably it was Diego removing \015 from files
[14:27:53] <mru> uhm, dvd audio works fine w/o psm
[14:28:05] <twnqx> then there's redundant code.
[14:28:21] <twnqx> because no psm => different stream id then with psm.
[14:28:23] <jannau> mru: seems so, I guess git converted it already during the import
[14:28:39] <jannau> kshishkov: it was Michael
[14:30:45] <lu_zero> mru: we have already a troll going with swscale, once that reach the end I'll start bitch with lavf
[14:32:26] <Tjoppen> lavf being tightly coupled with lavc is concern for me (and probably others)
[14:32:31] <Tjoppen> +a
[14:32:51] <lu_zero> Tjoppen: it isn't tightly coupled
[14:33:10] <mru> in one direction it is
[14:33:16] <mru> lavf is unusable without lavc
[14:33:23] <mru> even if you don't intend to use the lavc codecs
[14:33:27] <Tjoppen> well.. try to mux packets from a non-lavc encoder
[14:33:48] <lu_zero> just you have to set coded_frame
[14:33:56] <lu_zero> (so I understood)
[14:34:12] <Tjoppen> you have to set a lot of poorly documented stuff in AVStream
[14:34:30] <mru> avstream isn't the problem
[14:34:35] <mru> avstream->codec is
[14:35:20] <lu_zero> and avstream->codec->coded_frame...
[14:35:27] <Tjoppen> right
[14:46:51] <twnqx> gah this code is too ugly to work with
[14:47:02] <twnqx> :(
[14:48:13] <mru> that's what I said too
[14:48:59] <twnqx> what are the procedures for refactoring?
[14:49:17] <av500> 1) refactor
[14:49:19] <av500> 2) submit
[14:49:25] <mru> 3 goto 1
[14:49:35] <av500> 4) profit (unreached)
[14:49:37] <twnqx> i meant for submitting the patches for review.
[14:50:48] <CIA-63> ffmpeg: stefano * r25246 /trunk/cmdutils.h:
[14:50:48] <CIA-63> ffmpeg: Make new doxy follows the agreed upon style and grammatical
[14:50:48] <CIA-63> ffmpeg: conventions, for consistency with the rest of the documentation.
[14:50:52] <KotH> send them to -devel and let michael take them apart :)
[14:51:18] <KotH> wtf? gramatical conventions for comments?
[14:51:34] <KotH> isnt english a strict enough standard already?
[14:52:10] <spaam> nope.
[14:53:56] <KotH> ok, then i propose that we switch to lojban as documentation language
[14:54:26] <twnqx> by the way, how do you guys make those "fix indention after code change" patches?
[14:55:08] <astrange> git commit -a; fix indentation; git commit -a
[14:56:57] <twnqx> so code, unindent, commit, reindent?
[14:57:05] <twnqx> i mean, normal editors fix the indentation as you go
[14:57:44] <jannau> define normal
[14:57:44] <lu_zero> twnqx: sort of
[14:57:44] <astrange> you have an editor that changes indentation of existing lines automatically?
[14:57:55] <twnqx> if i press ; or enter, yes
[14:57:57] <KotH> no, normal editors do not touch indentation unless you tell it to do so
[14:58:08] <lu_zero> avcodec_encode_audio is ... fun..
[14:59:58] <CIA-63> ffmpeg: stefano * r25247 /trunk/libavfilter/vf_scale.c: Cosmetics: apply nits.
[14:59:59] <CIA-63> ffmpeg: stefano * r25248 /trunk/libavfilter/vf_scale.c:
[14:59:59] <CIA-63> ffmpeg: Make init() return sensible error code rather than -1 in case of
[14:59:59] <CIA-63> ffmpeg: invalid values.
[14:59:59] <jannau> does anyone understand what michael wants?
[15:00:21] <Dark_Shikari> jannau: sorry, that's something beyond the means of any human
[15:00:50] <cartman> jannau: virgin blood
[15:02:57] <Tjoppen> bah, files with duplicate time stamps
[15:03:08] <astrange> what kind of files?
[15:03:12] <Tjoppen> mpegts again
[15:03:25] <av500> cartman: that would be easy
[15:03:26] <Tjoppen> one of the subtitle streams
[15:03:38] <cartman> av500: how come? :P
[15:03:59] <mru> cartman: stab him
[15:04:03] <Tjoppen> I haxed compute_pkt_fields2() to ignore it atm. hopefully it doesn't break too much
[15:04:06] <cartman> mru is fast
[15:04:12] <cartman> ;>
[15:04:53] <astrange> http://pastebin.com/YpmmsSfq i considered something like this to remove next_pts from ffmpeg.c
[15:05:12] <astrange> but it doesn't fix the non-monotone timestamp errors from inside lavf, yes
[15:07:00] <Tjoppen> the file is from some kind of hardware. the interesting thing is that it's only the second dvbsub stream that's broken. the other three are fine (so far)
[15:07:17] <twnqx> are hex values to be written with lowercase a-f or uppercase - or is there no policy?
[15:07:33] * mru prefers lowercase
[15:07:51] <spaam> use both
[15:08:03] <mru> camecase constants
[15:08:06] <mru> camel
[15:08:26] <mru> 0xCafeBabe
[15:08:42] <twnqx> #define o0o0o
[15:08:57] <astrange> (that patch is also one reason why the pts correction stuff didn't go in a library - the interface might change)
[15:09:20] <Tjoppen> one of my coworkers had fun with the face that java accepts unicode for pretty much all names
[15:09:35] <Tjoppen> int A = 5, A = 3; System.out.println(A+A);
[15:10:06] <Tjoppen> with one of the A's as a superficially identical but disctinct code point
[15:10:24] <av500> Tjoppen: that one is easy, a clever compiler assignd 4 to A, so the output is 8 :)
[15:10:24] <mru> try a non-breaking space for fun
[15:10:44] <mru> av500: int A=26, A=16
[15:10:46] <mru> 26
[15:10:51] <Tjoppen> mru: how about non-breaking space and dash? int A - A = 2;
[15:11:01] <kshishkov> yes, though strategically placed Cyrillic 'с' prevented compiling of sample code for many students on our Java classes
[15:11:27] <mru> is there a unicode character that looks like an equals sign?
[15:11:39] <kshishkov> yes
[15:11:43] <kshishkov> pseudographics
[15:11:43] <merbzt> mru: yes =
[15:11:46] <Tjoppen> there has to be. after all, there's a snowman
[15:12:29] <kshishkov> and basilisk stare
[15:12:37] <mru> right
[15:12:48] <mru> the compiler dies if it sees it
[15:13:25] <kshishkov> nope, it's for real (don't remember in which XKCD it was referenced)
[15:14:12] <mru> http://xkcd.com/380/
[15:14:12] <av500> 380
[15:14:35] <kshishkov> av500: do you read alt texts for XKCD strips now?
[15:14:43] <av500> read what? :)
[15:15:05] * kshishkov feared to get only the first word as question
[15:16:22] <av500> fear?
[15:17:39] <kshishkov> no, I feared you just simply refuse to read nowadays
[15:34:58] <CIA-63> ffmpeg: stefano * r25249 /trunk/doc/APIchanges: Add APIchanges entry for lsws change of r32368.
[15:40:48] <twnqx> array out of bounds on read should be fixed in ffmpeg if found, right?
[15:41:08] <mru> yes
[15:41:22] <twnqx> *sigh* this mpeg-ps code is bad.
[15:42:03] <av500> mru: btw, your mkv code lack(ed) header compression. one can save 1 byte for frame :)
[15:42:11] <av500> per
[15:42:53] <kierank> av500: <tony the tiger> greaaaat!!
[15:42:55] <mru> my mkv code?
[15:42:58] <twnqx> if((*p&0xC0) == 0x40 && p+2 < end) p+=2; <- what would be the right formatting?
[15:42:58] <mru> it's a demuxer
[15:43:02] <mru> can't save anything
[15:44:06] <av500> I have an mkv that uses header compression to not store one 0 byte at the start of each h264 frame...
[15:44:15] <av500> huge savings!
[15:44:45] <Dark_Shikari> mkv header compression also breaks every stb out there
[15:44:50] <Dark_Shikari> gg
[15:45:05] <av500> Dark_Shikari: my users tell me a lot anime uses that
[15:45:07] <kierank> then the stb should have read the mkv spec properly
[15:45:11] <av500> a lot of
[15:45:25] <Dark_Shikari> av500: that's just because mkvmerge started using it by default a few versions ago
[15:45:57] * lu_zero found his problem with avformat
[15:45:59] <av500> hmm, wouldnt that mean that it has to read the whole stream once?
[15:46:01] * lu_zero is an idiot
[15:46:19] <av500> mru: 44!
[15:46:26] <lu_zero> guess what happens when you set just the pts and stay completely oblivious of dts...
[15:46:42] <mru> av500: is that 26+26 with compression?
[15:46:49] <av500> :)
[15:47:00] <av500> but close
[15:47:08] <av500> thx for 43, I will use that a lot
[15:47:27] <kshishkov> av500: your users watch anime? I thought your products are not... designed like what they expect
[15:47:30] <Dark_Shikari> don't tell te mkv people that there are slice headers in each frame too
[15:47:39] <Dark_Shikari> they'll find a way to compress those
[15:47:54] <av500> and i thought h264 was somewhat compressed by itself :)
[15:48:47] <mru> av500: no need to scan whole file, prefixing a zero never does any harm
[15:49:11] <av500> except to add ony byte per frame, thats what I call compression...
[15:49:20] <mru> of course then we have a lossy container
[15:49:26] <mru> and that's a scary thought
[15:49:51] <av500> nothing lost, just added
[15:49:58] <av500> it adss value :)
[15:50:00] <av500> adds
[15:50:11] <kshishkov> mru: lossy container is best read with leacky buckets from HRD!
[15:50:19] <kshishkov> *leaky
[16:12:42] <twnqx> hm
[16:13:41] <twnqx> damn, i still have the pending "do not crash my ffmpeg on broken files patch"...
[16:29:14] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/kzXxdjCh please review (not bit-exact yet, but it should be approximately correct)
[16:29:29] <BBB> I'll do a sse2 version later
[16:49:09] <twnqx> <astrange> git commit -a; fix indentation; git commit -a <-- how do i do that with svn?
[16:50:35] <Tjoppen> ehm.. don't touch the indentation of existing code when you write it, then fix it up when you're commited the OK'd stuff?
[16:50:44] <twnqx> i *can* not commit stuff
[16:50:59] <twnqx> since every single single patch i want to add goes to ML for review
[16:51:00] <jannau> quilt
[16:51:01] <Tjoppen> oh
[16:51:14] <twnqx> and maybe a few weeks later is committed.
[16:51:26] <jannau> or use one of the git mirrors
[16:51:36] <Tjoppen> well, you still have post stuff on the list even if you have write access
[16:51:56] <Tjoppen> or git-svn
[16:52:25] <Tjoppen> takes half an hour or something to set up though, since it grabs every single revision
[16:52:50] <kierank> yeah git-svn takes ages
[16:53:11] <Tjoppen> whenever I have to use svn I find myself missing being able to create local branches and git-stash
[16:53:23] <Tjoppen> ever do useful
[16:53:26] <Tjoppen> `so
[16:53:47] <twnqx> whenever i use git i miss the simplicity of svn :X
[16:54:10] <mru> whenever I use svn I'm baffled at how primitive it is
[16:55:24] <twnqx> yes, those two go hand in hand
[16:56:15] <Tjoppen> also, rebase -i is awesome
[16:56:23] <mru> can't do that in svn
[16:56:29] <twnqx> can't do many things in svn
[16:56:39] <mru> so all those things are simpler in git
[16:56:49] <twnqx> yes. versioning, on the other hand, is not
[16:56:54] <mru> using git _exactly_ like you'd use svn is not easy
[16:57:00] <twnqx> because you only get random numbers that tell you... nothign
[16:57:11] <mru> because how svn forces you to work is not how most people actually want to work
[16:57:28] <twnqx> and something as simple as "svn up" fails in git with locally commit patches
[16:57:40] <mru> git pull --rebase
[16:57:43] <Tjoppen> it fails even more with svn
[16:57:49] <mru> svn destroys your work
[16:57:53] <twnqx> doesn't here
[16:58:11] <twnqx> i *still* have the never committed "don't crash on ogm" patch in here... from several months back
[16:58:40] <twnqx> the interactive merge feature from git is nice, though
[16:59:21] <Tjoppen> I keep all such little fixes as local branches until they're OK'd (or I bother mailing them in)
[16:59:36] <twnqx> yeah
[16:59:40] <twnqx> it's just annoying me atm
[16:59:46] <twnqx> the there a realtime git mirror?
[17:00:02] <twnqx> that's always up tp the latest svn, as soon as the commit pops up here?
[17:00:27] <mru> git.ffmpeg.org
[17:00:42] <mru> and now jannau's tree with proper swscale
[17:01:19] <twnqx> good
[17:01:31] <Tjoppen> yes, that looks nice
[17:01:32] <twnqx> i'll switch to that before working on the mpegps code then
[17:01:49] <twnqx> so if you have a bunch of like 20 patches
[17:02:15] <mru> git send-email rocks
[17:02:19] <twnqx> and then you're asked to edit something in 15 revisions back - can you do that and then forward the change through all newer versions?
[17:02:32] <mru> rebase -i
[17:02:43] <twnqx> powerful.
[17:02:58] <mru> powerful, useful, wonderful
[17:03:01] * twnqx needs to learn more git
[17:03:03] <Tjoppen> you can even reorder and drop changesets
[17:03:11] <mru> and merge
[17:03:11] <Tjoppen> and squash of course
[17:03:12] <mru> and edit
[17:03:34] <twnqx> and bisect, best feature :X
[17:03:42] <Tjoppen> yes. magic
[17:04:26] <twnqx> too bad if you only code once in a blue moon you forget all the commands :(
[17:08:39] <twnqx> hm
[17:08:39] <twnqx> bad idea to clone here on 3.5G :S
[17:11:50] <jannau> bisecting is only useful with integrated swscale at least when it involves more than a couple of changes
[17:13:02] <jannau> twnqx: my tree is only 50M shouldn't be too bad over 3.5G
[17:14:44] <mru> jannau: bisecting with separate swscale works as long as there were no api changes in swscale in the interval
[17:14:50] <twnqx> i'm cloning http://git.ffmpeg.org/ffmpeg
[17:25:20] <ubitux> git add -p is a must-know too
[17:26:44] <mru> I usually prefer git gui for such tasks
[17:26:52] <mru> better overview
[17:27:01] <mru> unless I'm on a slow link of course
[17:57:47] <j0sh> lu_zero: did you ever get ffrtmp hooked up?
[18:45:17] <bcoudurier> hi guys
[18:46:14] <benoit-> salut Baptiste
[18:46:26] <bcoudurier> hey benoit- la forme ?
[18:49:26] <benoit-> bcoudurier: yep yep... ça roule. still on the west side ?
[18:49:44] <bcoudurier> west coast yeah
[18:51:35] <mru> why does michael insist on relying on random, undocumented gcc behaviour?
[18:54:27] * cartman adds -fconsistency
[18:54:45] * mru raises with -mrandom
[18:55:52] <benoit-> well, nite guys... time to go !
[19:01:41] <Compn> mru : well, have you seen the bugs he reported to gcc ?
[19:02:02] <Compn> some were marked invalid or wontfix
[19:02:33] <mru> his definition of bug is a little odd
[19:02:49] <mru> he calls a bug whatever doesn't behave the way he'd like it
[19:02:56] <mru> whatever the standard says
[19:03:19] <mru> now I'm talking about gcc doing something he wants by pure chance
[19:03:24] <mru> i.e. the opposite
[19:12:06] <iive> you know, it won't hurt if you explain the context of your comments.
[19:15:47] <BBB> I know the context :-p
[19:15:49] <Compn> context? we dont need no stinking context
[19:15:55] <BBB> it's funny
[19:15:58] <BBB> anyway
[19:16:17] <Compn> iive : mostly mru comes on irc to complain about michael's posts on the mailing list
[19:16:32] <Compn> so i think we are talking about some recent posts on ffmpeg-devel ...
[19:17:01] <Compn> and i guess michael doesnt like it, since hed rather reply on the list
[19:17:13] <Compn> but maybe mru wouldnt want to complain on the list since its mostly off-topic
[19:17:37] <Compn> so the cycle continues
[19:17:55] <mru> he'll never change
[19:20:40] <iive> Compn: tell me something I don't know.
[19:30:26] * Compn likes reading michaels' gcc mails
[19:30:46] <Compn> 15 mails back and forth instead of having someone test some -msse :D
[19:30:58] <lu_zero> j0sh: got to fight with apple and their interesting ways to let you develop with their toys
[19:31:02] <Compn> changing a bunch of code around just to use that flag :)
[19:32:34] <mru> Compn: this is nothing that needs testing
[19:33:39] <Compn> i know, but just that part of it amused me
[19:33:46] * Compn is easily amused
[19:37:02] <Compn> btw mru , i think 'no one can guarentee that it will always work' swings both ways, why not just use -msse until it does break ? but thats just me trolling
[19:37:23] <mru> adding -msse is _asking_ for it to break
[19:37:38] <cartman> http://cekirdek.pardus.org.tr/~ismail/safari.png have a good laugh
[19:38:25] <Compn> web browsers have tons of memleaks :(
[19:40:37] <cartman> this one is just better :D
[19:40:44] <cartman> 1G RAM usage in 1 minute
[19:41:59] <lu_zero> Compn: memleak or usage?
[19:42:06] <mmu_man> well it does last at least a month here without restarting, but it does hog the RAM and it feels much better after a restart
[19:42:20] <cartman> lu_zero: usage
[19:42:26] <cartman> not leaking i think
[19:42:33] <mru> how do you tell the difference?
[19:42:40] <cartman> mru: its always around 1GB
[19:42:46] <mmu_man> I suppose keeping 110 tabs open for a month doesn't help
[19:42:56] <mmu_man> cartman probably it can't get more :p
[19:43:10] <lu_zero> mmu_man: that would case it to near 2GB
[19:43:11] <mru> my irssi has been running for well over a year
[19:43:12] <cartman> mmu_man: got 4GB RAM here, 3GB ready to be allocated :P
[19:43:15] <mmu_man> though Firefox crashes more than Safari on OSX
[19:43:34] <cartman> I think + 4GB RAM will make things better
[19:43:37] <mmu_man> and I usually don't have as many tabs open
[19:43:59] <mmu_man> 4GB should be enough for everyone ? :p
[19:44:06] <cartman> mmu_man: 8GB :D
[19:44:11] <Compn> lu_zero : well i dont think i know the difference between a leak and usage. sometimes its usage that goes nuts i guess? or are we talking about firefox going oom ?
[19:44:26] * Compn hates oom
[19:44:36] * cartman wants extra RAM
[19:44:53] <Compn> maybe newer windows os can handle oom stuff
[19:45:29] * mmu_man wants SwapToStore(tm)
[19:45:49] <mmu_man> need more RAM => orders it automatically :)
[19:48:57] <iive> cartman: i've read that firefox checks what is the size of the ram and uses some percentage of it. could safari be doing the same?
[19:49:19] <cartman> iive: might be, it starts allocating a huge chunk on startup
[19:50:09] <mru> so how do you trick firefox into thinking there's only 1G or so
[19:50:34] <Compn> turn off firefox ram usage, make ramdisk, point firefox at it ?
[19:50:51] * Compn hasnt tested this
[19:51:05] <mru> point?
[19:51:14] <mru> and what is the purpose of the ramdisk?
[19:51:45] <Compn> the ramdisk would have a 1G size, so firefox would only see that...
[19:51:51] <mru> eh?
[19:52:01] <mru> malloc and ramdisks are unrelated
[19:53:34] <iive> linux already have ramdisk in /dev/shm
[19:54:04] <mmu_man> NetSurf everyone ?
[19:55:35] <Compn> maybe i was thinking of running firefox in a ramdisk
[19:55:48] <mru> that doesn't make sense
[19:56:24] <mru> I suppose you could cap the ram usage with ulimit
[19:56:30] <mru> but that would probably just kill it
[20:00:11] <lu_zero> mru: which firefox are you using?
[20:00:24] <mru> latest 3.6.x
[20:00:38] <mru> as built by portage
[20:01:00] <mru> what's with the split in xulrunner and firefox packages btw?
[20:18:30] <kierank> hahaha wikipedia and p2p-next are joining forces
[20:27:35] <saintdev> mru: xulrunner is used by more than just firefox
[20:27:52] <av500> like?
[20:28:10] <kierank> basically any slow application
[20:28:16] <thresh> :)
[20:28:18] <saintdev> kierank: lol
[20:28:38] <av500> kierank: wow, must tell CEO...
[20:28:58] <kierank> av500: ceo of what?
[20:29:12] <av500> any enterprise level ceo
[20:29:28] <kierank> get some buzzwords
[20:30:00] <saintdev> av500: the packages that i have installed that depend on it are gecko-mediaplayer, and google-gadgets
[20:31:03] * mru flees in terror
[20:38:34] <ohsix> get bartab :D
[20:47:16] <CIA-63> libswscale: janne * r32392 /trunk/libswscale/utils.c: cosmetics: break long line update_flags_cpu
[20:47:16] <CIA-63> libswscale: janne * r32393 /trunk/libswscale/utils.c: swscale: clear SWS_CPU_CAPS_SSE2 in update_flags_cpu() missed in r32068
[20:47:16] <CIA-63> libswscale: bcoudurier * r32394 /trunk/libswscale/ (swscale_template.c utils.c swscale.c swscale_internal.h): Y400A (gray alpha) input support in libswscale
[20:47:16] <CIA-63> libswscale: bcoudurier * r32395 /trunk/libswscale/swscale.c: 100l fix if condition
[20:47:17] <CIA-63> libswscale: stefano * r32396 /trunk/libswscale/swscale.h:
[20:47:17] <CIA-63> libswscale: Bump minor version after the addition of sws_alloc_context() and
[20:47:18] <CIA-63> libswscale: sws_init_context() of r32368.
[21:11:56] <BBB> \o/ 660 to 159 cycles, and it mostly works
[21:12:03] <BBB> now to fix that "mostly" into "always"
[21:12:14] <kierank> BBB: what function is this?
[21:12:42] <BBB> pred16x16_plane
[21:12:50] <kierank> nice
[21:12:51] <BBB> it's high (>1.0%) on my profiling
[21:13:28] <BBB> holy fuck
[21:13:39] <BBB> apparently it speeds up cathedral by 0.3sec (out of 80 in total)
[21:13:41] <BBB> 8.0
[21:13:54] <BBB> that's almost 0.4%
[21:13:57] <Dark_Shikari> you didn't realize that?
[21:14:07] <Dark_Shikari> it's the slowest prediction function, and gains the most from asm
[21:14:10] <Dark_Shikari> now, go compare your function to x264's
[21:14:14] <BBB> no
[21:14:21] <BBB> I want to finish it myself first ;)
[21:14:31] <BBB> why didn't you port x264's to ffmpeg alrady?
[21:14:40] <BBB> it wasn't there so I thought you didn't have asm yrt
[21:14:50] <Dark_Shikari> dunno
[21:14:56] <Dark_Shikari> we have asm for every single prediction function
[21:15:00] <Dark_Shikari> (of the ones which are useful to asm)
[21:15:02] <Dark_Shikari> i.e. about 50+
[21:15:50] <BBB> that's not 0.4%; it's 3.75%
[21:15:54] <BBB> that's pretty darn good :)
[21:16:03] <BBB> that makes 5.0% btw, diego owes me a beer now
[21:16:14] <BBB> too bad he isn't here
[21:16:20] <Dark_Shikari> plane 8x8 is important too
[21:16:28] <BBB> it doesn't sow up in my profiling (?)
[21:16:33] <BBB> I'll have a look at it
[21:16:36] <BBB> it's pretty similar
[21:16:37] <Dark_Shikari> pick a different clip
[21:16:42] <Dark_Shikari> also, 16x16 shows up high because of that clip
[21:16:48] <Dark_Shikari> that clip is from an encoder addicted to i16x16 mode
[21:16:55] <Dark_Shikari> on most clips it's going to be much less
[21:16:56] <Dark_Shikari> especially x264
[21:16:59] <BBB> fair enough, give me a different clip
[21:17:45] <Dark_Shikari> fyi in x264
[21:17:50] <BBB> http://ffmpeg.pastebin.com/Nh2nHzBW
[21:17:50] <Dark_Shikari> mmx 16x16: 121 clocks
[21:17:53] <BBB> please review
[21:17:53] <Dark_Shikari> sse2: 81
[21:17:55] <Dark_Shikari> ssse3: 73
[21:18:20] <BBB> this is only the ssse3 function
[21:18:26] <BBB> I'll fill in the blanks for the rest later
[21:18:38] <Dark_Shikari> 17-52 is slow
[21:18:43] <Dark_Shikari> that would be better in scalar
[21:18:49] <Dark_Shikari> x264's version uses a hybrid of C and yasm
[21:18:58] <Dark_Shikari> converting it to pure yasm made it slower
[21:19:07] <Dark_Shikari> because I was too lazy to reorder the massive series of loads enough to get good performance
[21:19:07] <BBB> scalar?
[21:19:11] <Dark_Shikari> yes
[21:19:14] <BBB> what is that
[21:19:18] <Dark_Shikari> not vector
[21:19:20] <Dark_Shikari> not using xmmregs
[21:19:21] <BBB> oh
[21:19:22] <Dark_Shikari> ....
[21:20:37] <Dark_Shikari> you have a redundant pmaddubsw
[21:20:48] <Dark_Shikari> also you don't need pmaddubsw for that
[21:20:52] <BBB> ?
[21:20:57] <Dark_Shikari> 95-96
[21:21:03] <Dark_Shikari> protip:
[21:21:04] <Dark_Shikari>     pmullw      xmm3, [pw_76543210]
[21:21:04] <Dark_Shikari>     psllw       xmm1, 3
[21:21:04] <Dark_Shikari>     paddsw      xmm0, xmm3  ; xmm0 = {i+ 0*b, i+ 1*b, i+ 2*b, i+ 3*b, i+ 4*b, i+ 5*b, i+ 6*b, i+ 7*b}
[21:21:08] <Dark_Shikari>     paddsw      xmm1, xmm0  ; xmm1 = {i+ 8*b, i+ 9*b, i+10*b, i+11*b, i+12*b, i+13*b, i+14*b, i+15*b}
[21:22:14] <BBB> oh sweet
[21:22:59] <Dark_Shikari> the code has loren's blame on it
[21:23:04] <Dark_Shikari> if you want to copy it, ask pengvado
[21:23:11] <BBB> pff.... you showed it to me
[21:23:15] <Dark_Shikari> I mean the whole function
[21:23:16] <BBB> that's evil :)
[21:23:23] <BBB> oh right
[21:23:51] <BBB> I'll see if I can do that weird vertical part in scalar easily
[21:24:03] <Dark_Shikari> in general, repeated testing has shown scalar is faster for "weird vertical parts".
[21:24:05] <BBB> do you just use a loop + movzx etc?
[21:24:07] <Dark_Shikari> even on cpus with fast shuffle units
[21:24:12] <mru> finally x86 catching up with arm...
[21:24:28] <Dark_Shikari> I don't know.  all I know is when I tried it on a whim
[21:24:30] <Dark_Shikari> and spent 10 minutes on it
[21:24:32] <Dark_Shikari> it was slower than gcc
[21:24:36] <Dark_Shikari> so whatever gcc doing is probably better than the obvious
[21:25:07] <Dark_Shikari> I mean what gcc does to the C in x264, of course.
[21:25:14] <Dark_Shikari> and by the C I mean the C part of the sse2 function.
[21:25:19] <Dark_Shikari> Michael would go nuts if he saw it
[21:25:22] <Dark_Shikari> OMG A CALL
[21:25:27] <Dark_Shikari> CALL OVERHEAD OH SHIT
[21:25:35] <mru> AN ENTIRE CYCLE TO WASTE!!!!
[21:25:59] <Dark_Shikari> actually that function is an abomination
[21:26:02] <Dark_Shikari> it's inline asm, C, and yasm
[21:26:08] <Dark_Shikari> all in a big boulliabaise
[21:26:18] <kierank> lol boulliabaise
[21:26:33] <mru> he likes that word
[21:26:46] <kierank> yes i know
[21:26:55] <mru> it's french
[21:26:58] <Dark_Shikari> have I even used it before?
[21:27:03] <mru> yes
[21:27:04] <kierank> yes in a blog post somewhere
[21:27:22] <mru> metaphorically, of course
[21:27:25] <Dark_Shikari> the only place I remember it being used is http://hqvia.com/wp-content/uploads/Bitchin-fast-3D-2000.jpg
[21:28:14] <mru> http://x264dev.multimedia.cx/?p=360
[21:28:40] <mru> "The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter ..."
[21:28:51] <BBB> heh :)
[21:28:52] <BBB> new word
[21:29:02] <av500> http://erkie.github.com/
[21:29:02] <BBB> ok removed the pmaddubsw
[21:29:04] <av500> fun
[21:29:25] <BBB> now to redo the V part in scalar
[21:29:27] <mru> what is a bookmark bar?
[21:29:43] <Dark_Shikari> a crunchy, granola-filled treat
[21:30:13] <av500> mru: a hangout for librarians
[21:31:02] <mru> the st20 dev tools called the equilvalent of 'ar' the librarian
[21:31:40] <mru> wow, nice patch on the ml
[21:31:44] <mru> if (!ptr) free(ptr)
[21:31:53] <BBB> current one is 150 cycles
[21:32:00] <mru> get rid of those null pointers
[21:32:01] <BBB> still quite slow compared to x264 :(
[21:32:08] <mru> BBB: so steal theirs
[21:32:23] <BBB> stealing code doesn't feel as good as rewriting it from scratch
[21:33:20] <mru> and even better is selling it
[21:35:37] <Dark_Shikari> wheel, reinventing, etc
[21:36:03] <mru> would you be interested in purchasing some extra round wheels?
[21:54:36] <kierank> mru: if you can put them in a square hole I'd be interested
[22:38:43] <Dark_Shikari> holy moses
[22:38:51] <Dark_Shikari> I was wondering why my optimized version was slower than the original code
[22:38:56] <Dark_Shikari> for(x=offset; x<offset+end_x-start_x; x++) buf[x]= src[x];
[22:39:05] <Dark_Shikari> when compiling this loop, gcc recalculates "offset+end_x-start_x" every iteration.
[22:39:15] <Dark_Shikari> fml
[22:40:18] <BBB> Dark_Shikari: hmm... scalar is indeed MUCH faster
[22:40:21] <BBB> 121 cycles now
[22:41:38] <BBB> yours was 71? how on earth do you do that
[22:41:58] <BBB> oh 73
[22:41:59] <BBB> still
[22:42:01] <BBB> holy cow
[22:43:10] <Dark_Shikari> that's on an i7, 32-bit
[22:43:43] <BBB> oh this is 64bit
[22:43:48] <BBB> shouldn't that be faster?
[22:44:52] <Dark_Shikari> Yes
[22:44:55] <Dark_Shikari> well, at least equal
[22:44:59] <Dark_Shikari> my point being, your code sucks
[22:45:01] * Dark_Shikari ducks
[22:45:48] <Dark_Shikari> my god.  gcc is horrible
[22:45:51] <Dark_Shikari> a memcpy loop, according to gcc:
[22:45:52] <Dark_Shikari>   4f9480:       0f b6 01                movzx  eax,[ecx]
[22:45:52] <Dark_Shikari>   4f9483:       83 c3 01                add    ebx,0x1
[22:45:52] <Dark_Shikari>   4f9486:       83 c1 01                add    ecx,0x1
[22:45:52] <Dark_Shikari>   4f9489:       88 02                   mov    [edx],al
[22:45:55] <Dark_Shikari>   4f948b:       83 c2 01                add    edx,0x1
[22:45:57] <Dark_Shikari>   4f948e:       39 de                   cmp    esi,ebx
[22:46:00] <Dark_Shikari>   4f9490:       7f ee                   jg     0x4f9480
[22:46:14] * BBB decides to hate Dark_Shikari for the rest of the day
[22:46:21] <BBB> now be helpful, bitch!
[22:46:53] <Dark_Shikari> read x264's code
[22:47:08] <BBB> http://ffmpeg.pastebin.com/sAqqtBA6
[22:47:16] <BBB> I want to feel at least once like I wrote it
[22:47:22] <BBB> copying x264 is like the lamest thing ever
[22:47:24] <BBB> I'll never learn
[22:47:37] <Dark_Shikari> your horizontal sum sucks
[22:48:14] <BBB> this is what ffmpeg's hadamard code does
[22:48:28] <Dark_Shikari> 33-77: if you can reduce the number of ops using imul, do it
[22:48:29] <BBB> (I know: you'll tell me ffmpeg's hadamard code sucks)
[22:48:35] <Dark_Shikari> your loop should be unrolled 2x
[22:49:16] <BBB> you mean 2 lines per iter? or 4?
[22:49:29] <BBB> (or whatever is faster, I guess)
[22:49:39] <Dark_Shikari> 2
[22:49:44] <BBB> k
[22:49:45] <Dark_Shikari> did you remember to subtract out nop cycles when doing your timing?
[22:49:48] <iive> Dark_Shikari: what I don't understand is, why no CPU optimized the case of rep movsb ?
[22:49:53] <BBB> Dark_Shikari: no
[22:50:00] <Dark_Shikari> BBB: well then stop comparing different numbers =p
[22:50:08] <BBB> Dark_Shikari: this is the time h264.c START_TIMER bla->bla(); STOP_TIMER()
[22:50:15] <BBB> hm
[22:50:18] <Dark_Shikari> You need to subtract nop cycles
[22:50:20] <Dark_Shikari> the cost of an empty start_timer
[22:50:25] <BBB> that takes time
[22:50:26] * BBB lazy
[22:50:35] <pengvado> so do it once and for all
[22:50:47] <Dark_Shikari> yes, like we do in x264
[22:50:56] <Dark_Shikari> FFFFFFFFFF
[22:50:59] <Dark_Shikari> HOW CAN GCC ADD A CMP TO THIS
[22:51:00] <Dark_Shikari>         for(x=start; x>=0; x--)
[22:51:00] <Dark_Shikari>             curdst[x]= cursrc[x];
[22:51:02] <BBB> 25
[22:51:04] <Dark_Shikari> why why why why
[22:51:10] <Dark_Shikari> there is no cm pthere
[22:51:11] <BBB> so mine is 121-25=96
[22:51:22] <pengvado> http://pastebin.com/BKgq65Lm
[22:51:53] <BBB> 96 is still > 73
[22:52:01] <BBB> I'll see what else I can chew off tonight
[22:52:20] <BBB> 96 isn't too bad anyway :)
[22:53:06] <BBB> saves a good few percent
[22:55:16] <BBB> Dark_Shikari: I'm surprised you didn't optimize all h264pred stuff, I assumed you did when you did the vp8 ops
[22:55:59] <BBB> pengvado: can I peek at your code? (i.e. can I steal your pred16x16plane code and put it under lgpl, basically :-p)
[22:56:58] <Dark_Shikari> if pengvado says yes, I would prefer you:
[22:57:06] <Dark_Shikari> a) steal the code outright (don't rewrite)
[22:57:17] <Dark_Shikari> b) once you steal it, then try to eliminate the gcc part
[22:57:23] <Dark_Shikari> but only commit an elimination of the gcc part if it's faster
[22:57:30] <Dark_Shikari> c) once you're done with that, we'll backport it to x264
[22:57:31] <Dark_Shikari> lol
[23:04:11] <pengvado> agreed with Dark_Shikari
[23:05:30] <BBB> Dark_Shikari: fine with me, I already wrote the asm code for that (see my last link) :-p
[23:05:35] <BBB> let's try that
[23:06:17] <Dark_Shikari> BBB: it may not be faster ;)
[23:06:22] <BBB> true
[23:06:28] <BBB> that's why I'll try it ;)
[23:06:56] <BBB> which file is this?
[23:07:01] <Dark_Shikari> common/x86/predict-a.asm
[23:07:03] <Dark_Shikari> brb, going to plane.
[23:07:19] <BBB> uh... have a nice trip?
[23:07:23] * BBB goes home
[23:07:32] <kierank> internet on plane?
[23:10:23] <BBB> expensive
[23:10:42] <BBB> predict_16x16_p_core_sse2 has no gcc in it (in my version), it just receives b/c as arguments
[23:41:36] <Compn> lol
[23:43:43] * Compn didnt know the samsung guy posted on Dark_Shikari's blog
[23:44:39] <spaam> hmm?
[23:46:32] <kierank> the bbc guy was also on x264dev for a while
[23:57:25] <Compn> ah
[23:57:34] <j0sh> steve jobs reads x264dev
[23:57:35] <Compn> spaam : http://x264dev.multimedia.cx/?p=360