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

irc at mansr.com irc at mansr.com
Wed Feb 24 01:00:37 CET 2010


[00:31:35] <mru> damn apple, I can't use an evil hack
[00:32:27] <mru> which would be abusing bit 2 of the stack pointer
[00:36:20] <BBB> DonDiego, fixed
[00:36:26] * BBB goes home
[00:36:40] <CIA-46> ffmpeg: rbultje * r21974 /trunk/ (7 files in 2 dirs): Prefix non-static RTSP functions with ff_.
[01:08:32] <CIA-46> ffmpeg: michael * r21975 /trunk/libavcodec/h264.c:
[01:08:32] <CIA-46> ffmpeg: Move extradata reading code into codec init instead of doing it
[01:08:32] <CIA-46> ffmpeg: in read frame.
[01:09:42] <CIA-46> ffmpeg: michael * r21976 /trunk/libavcodec/h264.c:
[01:09:43] <CIA-46> ffmpeg: Try to set has_b_frames in codec init if we know everything alraedy.
[01:09:43] <CIA-46> ffmpeg: This fixes some issues with the first few timestamps.
[02:47:11] <astrange> Dark_Shikari: huh, i thought gnash used ffmpeg. so i did learn something from reddit
[02:47:27] <mru> what do they use?
[02:47:40] <astrange> installing bzr to find out
[02:48:00] <astrange> probably nothing, someone in a comment called it "legally dubious"
[02:48:06] <astrange> i'll have to ask if that means "not gpl3"
[02:48:32] <mru> that's a fair bet on reddit
[02:49:06] <Dark_Shikari> lol
[02:49:36] <astrange> yeah, nothing
[02:51:18] <Dark_Shikari> it was gnash devs who apparently think that a gpl flash player means that they can't play  gpl-non-compliant flash files
[02:57:13] <Dark_Shikari> siretart`: I'm about to push a revision with some bugfixes plus new features, they're ordered so bugfixes are first, then features
[02:57:16] <Dark_Shikari> so you can pick the last bufix revision
[02:57:24] <Dark_Shikari> *bugfix
[02:57:31] <Dark_Shikari> After this, any further bugfixes will have to be backported.
[02:57:56] <Dark_Shikari> so if you have any configure or similar patches you want in, hit me
[02:58:11] <astrange> no, i looked in trunk and it has ffmpeg and gst modules...
[03:06:52] <Compn> Dark_Shikari : whats this comiket music you talk of ? torrents ?
[03:07:12] <Compn> comiket = japanese manga convention iirc
[03:09:55] <Dark_Shikari> japanese Stuff convention
[03:10:06] <Dark_Shikari> notably, amateur-only, no corporate stuff allowed
[03:10:54] <Dark_Shikari> Compn: torrent is http://www.nyaatorrents.org/?page=torrentinfo&tid=113174
[03:11:04] <Dark_Shikari> "
[03:11:05] <Dark_Shikari> This torrent is so large it breaks all uTorrent versions up to and including 2.0"
[03:11:31] <Compn> crud
[03:11:37] <Compn> my ut 1.6 wont like it then
[03:12:25] <Dark_Shikari> there's the lossy version, which is "only" 109gb
[03:12:41] <Dark_Shikari> most of the music isn't that good anyways, you could probably filter it down to 1/5 the size easily
[03:12:49] <Dark_Shikari> but such is true of any sufficiently large collection
[03:12:59] <Dark_Shikari> especially since most people don't like all genres anyways
[03:13:18] <Compn> i... think i like all genres hah!
[03:13:27] <Dark_Shikari> rap?
[03:13:29] <Compn> even country (if its good, which is rare)
[03:13:35] <Compn> yep
[03:13:56] <Compn> i mostly like the rap beats, because i have trouble understanding english lyrics anyways
[03:16:45] <mru> omg, ffmpeg .bss has grown to 8MB
[03:16:51] <mru> that's unacceptable
[03:18:04] <Dark_Shikari> for what
[03:18:47] <mru> it's just unacceptable bloat
[03:18:52] <mru> it was 4MB a week ago
[03:19:40] <Dark_Shikari> yeah, I know
[03:19:41] <Dark_Shikari> why is it so big
[03:19:43] <Dark_Shikari> who fucked up
[03:20:40] <mru> static VLC table_data[8192 * 16][2];
[03:20:53] <Dark_Shikari> which codec
[03:20:59] <mru> indeo5
[03:21:02] <Dark_Shikari> .....
[03:21:07] <Dark_Shikari> THAT IS LARGER THAN THE L2 CACHE OF MOST CPUs
[03:21:17] <Dark_Shikari> WHAT THE FUCK
[03:21:20] <mru> it's larger than everything else in ffmpeg combined
[03:21:32] <Dark_Shikari> kostya's fault?
[03:21:39] <mru> or maxim
[03:22:02] <mru> explains why everything started failing on blackfin suddenly
[03:22:10] <mru> I only allocated 5MB for .bss
[03:22:45] <ramiro> oh, then that's what added around 300kb to the autobuilds 7z...
[03:23:13] <mru> no
[03:23:16] <Dark_Shikari> bss is free
[03:23:16] <mru> this is .bss
[03:23:22] <Dark_Shikari> 300kb was from bink, amr-nb, etc
[03:23:28] <mru> it's not free on nommu systems
[03:23:59] <ramiro> hmm, right. it just jumped from one day to the other.
[03:36:27] <mru> http://pastebin.ca/1806356
[03:36:44] <Dark_Shikari> what's that?
[03:37:11] <mru> slashing that table size to 1/8 of the size
[03:38:04] <Dark_Shikari> that's still big
[03:38:16] <mru> obvious typo though
[03:38:19] <Dark_Shikari> way too big
[03:38:19] <Dark_Shikari> ah
[03:46:43] <CIA-46> ffmpeg: mru * r21977 /trunk/libavcodec/ivi_common.c: Declare indeo VLC table storage with correct type
[03:47:17] <mru> back under 5MB
[05:21:11] <fizk_> hey guys,  can ffplay be written to not depend on SDL?
[05:21:26] <fizk_> just OpenGL
[05:30:26] <astrange> yes, port mplayer libvo
[05:30:40] <astrange> and ao
[06:04:12] <pavel_> anybody from ffmeg devs here??
[06:04:33] <pavel_> is it better to write to devel-list or I can as questions here??
[06:05:43] <Dark_Shikari> don't ask to ask, just ask
[06:32:07] <pavel_> i just email devel.
[06:32:15] <pavel_> i can post it here as well.
[06:32:46] <kshishkov> I believe you
[06:33:20] <pavel_> i asked if anybody was alive to see my posts... anyways, I'm really late and I have to see a dentist tomorrow morning at 8am, so I need to leave in a few mins.
[06:33:45] <pavel_> kshishkov: thanks you very much for believing me,
[06:34:59] <kshishkov> hmm, your post misses links to samples
[06:35:11] <pavel_> one of the problems was an assert that always hits in avcodec and it's related to h264 (.mov) files filmed with iphone. that was first assert in MPV_frame_start in mpegvideo.c
[06:37:14] <CIA-46> ffmpeg: kostya * r21978 /trunk/libavformat/bink.c: Make Bink demuxer pass video flags to decoder
[06:37:44] <kshishkov> nevertheless, I doubt that our H.264 dev has iPhone to make samples and fix that condition
[06:37:53] <kshishkov> same goes for JPEG
[06:40:10] <CIA-46> ffmpeg: kostya * r21979 /trunk/libavcodec/bink.c: Bink video decoder now can use extradata to detect alpha plane presence
[06:40:32] <elenril> morning
[06:40:50] <kshishkov> as you say
[06:41:58] <astrange> r21915 plays video from a 3gs for me
[06:42:06] <pavel_> http://dev5.summit-tech.ca/pavel/test.mov
[06:42:29] <astrange> plays that too
[06:42:52] <astrange> actually i thought asserts were off in that file
[06:42:56] <pavel_> As for tandberg cam I have no idea what I can do - I think I might capture raw frames to a file, write a test and mail that....
[06:43:22] <pavel_> that file doesn't have and cannot have asserts :) It's a media file, you build has to be a debug build :)
[06:43:31] <astrange> i mean mpegvideo.c
[06:43:33] <pavel_> your
[06:44:42] <pavel_> well, after I had these problems with jpeg, I decided to make a debug build to see if there was something. I hit that assert, amybe who ever wrote it could review the conditions and possible modify some code...
[07:01:38] <CIA-46> ffmpeg: kostya * r21980 /trunk/libavcodec/bink.c: Move plane decoding code into separate function in Bink decoder
[07:01:38] <CIA-46> ffmpeg: kostya * r21981 /trunk/libavcodec/bink.c: cosmetics: reindent after last commit
[07:08:42] <CIA-46> ffmpeg: kostya * r21982 /trunk/libavcodec/bink.c: Decode alpha plane in Bink video
[07:09:05] <Dark_Shikari> \o/
[07:09:11] <Dark_Shikari> Awesome, kshishkov !
[07:09:16] <Dark_Shikari> Any other remaining issues with the files I sent?
[07:09:34] <Dark_Shikari> and any progress on the speed issue?
[07:10:20] <kshishkov> two issues - speed and sound
[07:10:41] <kshishkov> and Bink version 'b'
[07:11:02] <Dark_Shikari> what's "b"?
[07:12:04] <kshishkov> Bink versions are determined by 3rd byte of file. Currently supported files begin with "BIKf", "BIKh" and "BIKi"
[07:12:23] <kshishkov> "BIKb" is an old version requiring separate decoder
[07:15:44] <Dark_Shikari> how different is it?
[07:15:58] <Dark_Shikari> and what about a,c,d,e?
[07:16:24] <kshishkov> some principles are the same, everything else differs - bundle reading, block types, etc
[07:16:55] <kshishkov> for a,c-e versions we don't have any samples
[07:25:23] <Dark_Shikari> wow.
[07:25:27] <Dark_Shikari> that's going to be a lot of work :/
[07:25:30] <Dark_Shikari> you have a lot of b samples?
[07:26:34] <kshishkov> let's see...
[07:26:48] <kshishkov> http://samples.mplayerhq.hu/game-formats/bink/bikb/ - sould be enough
[07:26:50] <kshishkov> *should
[07:28:37] <Dark_Shikari> what's the difference between f, h, and i?
[07:28:39] <Dark_Shikari> and what's g
[07:29:50] <kshishkov> never seen 'g' but it should be virtually the same
[07:30:22] <superdump> ?
[07:30:26] <kshishkov> 'i' has colour planes swapped and plane size before alpha and luma planes
[07:30:42] <kshishkov> superdump: we are discussing Bink versions
[07:30:59] <kshishkov> probably some coding methods were added for those versions
[07:31:21] <kshishkov> too lazy to verify what coding methods are not present in those old versions
[07:42:18] <CIA-46> ffmpeg: kostya * r21983 /trunk/libavcodec/ (indeo5.c ivi_common.c):
[07:42:18] <CIA-46> ffmpeg: 10l trocadero: Indeo 5 decoder did not free custom VLCs for macroblock and
[07:42:18] <CIA-46> ffmpeg: block decoding at exit, so prevent that memory leak now.
[08:05:44] <CIA-46> ffmpeg: daniel * r21984 /trunk/ (configure libavcodec/Makefile): Fix svq1 encoder dependencies
[08:10:52] <CIA-46> ffmpeg: daniel * r21985 /trunk/ (configure libavcodec/Makefile): Fix snow encoder dependencies
[08:13:19] <CIA-46> ffmpeg: daniel * r21986 /trunk/libavcodec/Makefile: Fix gif encoder dependencies
[08:16:34] <CIA-46> ffmpeg: benoit * r21987 /trunk:
[08:16:34] <CIA-46> ffmpeg: Add ffprobe to ignore rules.
[08:16:34] <CIA-46> ffmpeg: (spotted by Martin)
[08:17:41] <pJok> mornings :)
[08:17:45] <CIA-46> ffmpeg: daniel * r21988 /trunk/libavcodec/Makefile: Fix wmv2 encoder dependencies
[08:18:53] <kshishkov> goda morgnar
[08:19:36] <pJok> SJ gets quite a beating these days
[08:22:42] <kshishkov> http://www.youtube.com/watch?v=eaXm4FGbZys
[08:23:53] <KotH> trevlig morgon
[08:24:52] <CIA-46> ffmpeg: daniel * r21989 /trunk/libavcodec/Makefile: Fix mpeg4video parser dependencies
[08:25:04] <av500> kshishkov: not bad, at least you can arrest everybody for drunk driving :)
[08:26:21] <kshishkov> av500: nah, even if drunk driver kills people it's unlikely he get arrested
[08:26:25] <kshishkov> *gets
[08:33:19] <CIA-46> ffmpeg: daniel * r21990 /trunk/libavcodec/Makefile: Fix h264 parser dependencies
[08:37:58] <CIA-46> ffmpeg: daniel * r21991 /trunk/libavcodec/Makefile: Fix vc1 parser dependencies
[08:41:35] <CIA-46> ffmpeg: daniel * r21992 /trunk/libavcodec/Makefile: Fix iff demuxer dependencies
[08:41:45] <Dark_Shikari> wee dependency fixes
[08:43:02] <drv> should be all done now ;)
[08:43:33] <drv> (now time to sleep and wait for 80-column fanatics)
[08:44:46] <kshishkov> ok, we'll tell DonDiego
[08:45:11] <kshishkov> thanks for vc1 parser too
[08:45:27] <drv> in my defense, the existing makefiles are consistent on line length/breaking points, so i don't think i made it any worse...
[08:46:28] <drv> kshishkov: btw, any bink samples with > 2 audio tracks?
[08:46:37] <drv> format seems to be able to support it, but i haven't seen any
[08:46:50] <kshishkov> of course, Psychonauts samples you complained about
[08:46:59] <drv> ah really, i should take a closer look then
[08:47:45] <drv> hmm, those are multiple tracks but not individual tracks with more than stereo, i think
[08:50:02] <drv> anyway, i doubt there are such files, but the format has a field for number of channels rather than just a mono/stereo flag, so i was just wondering
[08:50:13] <drv> the encoder only supports selecting mono or stereo
[08:50:32] <kshishkov> yes, but there may be many mono/stereo tracks
[08:50:36] <drv> right
[08:50:41] <drv> i think we support that already though
[08:50:43] <kshishkov> your samples have three
[08:51:22] <kshishkov> some samples from Dark_Shikari have six audio tracks
[08:51:52] <kshishkov> Huh? "Use -h to get full help or, even better, run 'man ffplay'"
[09:19:16] <DonDiego> drv: indeed, you messed up the line length, why?
[09:19:53] <DonDiego> it's not like breaking a line is going to take you an additional hour and a half..
[09:19:55] <kshishkov> g'day, mate!
[09:19:59] <DonDiego> moin
[09:20:23] <pross-au> Morning
[09:20:49] <kshishkov> looks like people are finally starting complaining about Bink audio. Can't tell why
[09:21:10] <pross-au> That was ME
[09:21:28] <kshishkov> and that "reported data size does not match output data size" message
[09:21:37] <pross-au> oh?
[09:21:44] <pross-au> I can fix that
[09:21:47] <pross-au> the dct issue, er, no
[09:22:08] <kshishkov> well, something strange happens with demuxer too
[09:22:27] <pross-au> Yeah?
[09:22:50] <kshishkov> yes
[09:23:13] <pross-au> I need a little more detail to work on
[09:23:15] <kshishkov> I believe you've seen https://roundup.ffmpeg.org/roundup/ffmpeg/issue1767
[09:24:02] <Dark_Shikari> and the fact tha tit sounds like shit
[09:24:03] <pross-au> Yeah i read it. Need to go hunting for the password
[09:24:04] <Dark_Shikari> *that it
[09:24:31] <pross-au> DCT mismatch Dark_Shikari
[09:24:42] <Dark_Shikari> needs fixing regardless
[09:24:57] <Dark_Shikari> and if you really mean it's just a rounding error, I find that quite unlikely
[09:25:27] <pross-au> No its more than that
[09:26:05] <kshishkov> it would be nice if demuxer told duration too
[09:36:37] <Dark_Shikari> god damn I've used bisect twice today now
[09:36:39] <Dark_Shikari> the best git feature, ever
[09:37:00] <andoma> Dark_Shikari: indeed!
[09:37:51] <bilboed-tp> Dark_Shikari, you know you can have it run automatically a series of command and automatically mark revisions as good/bad ? :)
[09:38:05] <Dark_Shikari> yeah I know, but that's effort
[09:38:23] <bilboed-tp> true... but well worth it
[09:42:41] <Dark_Shikari> oh FUCK.  the bug is a fucking ARRAY OVERREAD.
[09:42:59] <Dark_Shikari> I hate shit like this.
[09:43:09] <Dark_Shikari> well, thank god for regression tests.
[09:49:16] <twnqx> wouldn't you love java with runtime bounds checking :P
[09:49:32] <kshishkov> even Pascal had that
[09:50:09] <twnqx> true, but i always turned it off for performance :P
[09:55:40] <elenril> DonDiego: ping
[09:55:49] <DonDiego> pong
[09:56:00] <DonDiego> sup?
[09:56:00] <elenril> can i get svn account?
[09:56:16] <DonDiego> for what?
[09:56:21] <elenril> for ffmpeg
[09:56:30] <DonDiego> why would you be asking me?
[09:56:31] <kshishkov> for metadata in FFmpeg ;)
[09:56:32] <elenril> patch monkeys are too lazy
[09:56:44] <elenril> i thought you handled these things
[09:56:49] <DonDiego> no
[09:57:02] <DonDiego> i'm not the boss around here, i don't hand out privileges
[09:57:33] <DonDiego> you're asking the janitor to get access to company premises
[09:57:58] <pross-au> DonDiego: that's how it sometimes works
[09:58:26] <DonDiego> your attempts at social engineering fail horribly
[09:58:41] <DonDiego> it may work if the janitor can be sure the boss won't notice
[09:58:46] <DonDiego> not the case here
[09:58:50] <elenril> heh
[09:59:02] <elenril> who should i ask then?
[09:59:35] <pross-au> kshishkov: were you able to reproduce issue1767 (inconsistent bink framerate)?
[09:59:56] <kshishkov> the usual way is to swamp FFmpeg-devel with useful (and accepted) patches so Michael says "give that guy an account"
[10:00:25] <kshishkov> pross-au: yes, many Binks start with some slowness then speed up
[10:02:51] <av500> kshishkov: with michael reading irc logs, I guess he is aware now :)
[10:02:58] <pross-au> i tried both files on mplayerhq and they looked fine
[10:03:17] <DonDiego> elenril: ask somebody who thinks you should get an account to ask michael if he agrees
[10:03:25] <DonDiego> somebody /= DonDiego
[10:03:36] <DonDiego> oh, that was haskell, let me say it in C again..
[10:03:43] <kshishkov> pross-au: it's not "looking", its subjective playing speed I think. Ask jonwil when he's able
[10:03:46] <DonDiego> somebody != DonDiego
[10:04:00] <pross-au> oh ok
[10:04:39] <elenril> ok, does anybody here think i should get an account? :)
[10:06:49] <Dark_Shikari> siretart`: 1a6d32b4 is the new target revision
[10:06:57] <Dark_Shikari> this contains many new bugfixes, including for some very old bugs.
[10:07:31] <Dark_Shikari> aka r1448
[10:08:06] <DonDiego> say
[10:08:33] <DonDiego> somebody in that thread on reddit claims that adobe no longer forbids alternative implementations
[10:08:37] <DonDiego> is that right?
[10:08:55] <av500> they opened the specs
[10:08:59] <Dark_Shikari> yes, quite some time ago
[10:13:09] <DonDiego> last time i looked at it there was a big disclaimer at the front
[10:13:22] <DonDiego> forbidding use in alternative implementations
[10:13:58] <DonDiego> i know it was still the case when kostya was working on rtmp
[10:13:58] <Dark_Shikari> of course it's not like it's an enforcable clause
[10:15:28] <DonDiego> sure, but it's still there, isn't it?
[10:15:44] <DonDiego> people are incredibly easy to scare
[10:17:10] <DonDiego> "if you run this program, you are forever banned from writing email"
[10:25:39] * KotH deletes all of DonDiego's email accoutns
[10:27:07] <DonDiego> btw, i'm starting to think that gnash is hurting a flash reimplementation
[10:27:20] <DonDiego> it's taking away mindshare and nobody else bothers working on it
[10:27:53] <KotH> whats wrong with gnash?
[10:27:56] <DonDiego> while at the same time not progressing anywhere...
[10:28:02] <DonDiego> KotH: tried using it?
[10:28:05] <av500> DonDiego: well, being open source etc, you are supposed to work on gnash, not reimplement
[10:28:11] <av500> :)
[10:28:18] <DonDiego> av500: there are alternatives
[10:28:36] <DonDiego> swfdec and the other one
[10:28:44] <DonDiego> i think gnash is based on swfdec
[10:28:49] <DonDiego> i keep confusing them
[10:29:01] <CIA-46> ffmpeg: pross * r21993 /trunk/libavcodec/binkaudio.c: Use reported_size to truncate final Bink Audio frame
[10:29:10] * av500 knows swfdec and gnash
[10:29:16] <DonDiego> KotH: i was unable to make gnash play anything and compiling stuff was terribly hard
[10:30:42] <DonDiego> gameswf was the other one
[10:30:51] <DonDiego> and gnash is based on gameswf
[10:31:10] <av500> ffswf
[10:31:42] <__gb__> lightspark starts to do things too
[10:32:39] <pross-au> It uses Boost, enough said.
[10:32:45] <KotH> DonDiego: nope
[10:32:58] <KotH> DonDiego: i use the adobe flash player... for a good reason :)
[10:33:19] <DonDiego> __gb__: what is lightspark?
[10:33:30] <DonDiego> swfdec is C, not C++ ...
[10:33:32] <kshishkov> KotH: is there any good reason in using Flash?
[10:33:43] <av500> http://sourceforge.net/projects/lightspark/
[10:34:38] <__gb__> though windows-only at this time iirc
[10:34:54] <kshishkov> also IIRC some guy managed to write Flash client purely in JavaScript
[10:34:57] <__gb__> uses llvm & glsl
[10:38:51] <DonDiego> C++ shit as well :-/
[10:39:15] <kshishkov> but it's designed by Danish
[10:39:42] <KotH> kshishkov: yeah.. and if it's just porntube
[10:41:00] <kshishkov> KotH: ahem, I'd use youtube-dl instead
[10:41:36] <av500> kshishkov: that not the right solution if you decidec to spend your friday night with "browsing utube..." :)
[10:41:59] <KotH> av500: it is
[10:42:21] <KotH> av500: for some reason, my machine is too slow to show even the most simple flash movie
[10:42:36] <KotH> av500: downloading them and playing them with mplayer works though... with less than 1% cpu usage
[10:42:49] <KotH> -> mozilla+flash sucks
[10:43:18] <kshishkov> av500: even streaming it with MPlayer should be better
[10:43:50] <av500> KotH: guess why we used to offer to our users to play the actual FLV in our video player and not in the flash one :)
[10:44:30] <DonDiego> av500: "your users"?
[10:44:32] <kshishkov> av500: please send a patch so we can use ffmpeg -i youtube://jhfddf6d outfile
[10:44:42] <av500> kshishkov: actually trivial
[10:44:52] <av500> we do that
[10:45:07] <av500> not with ffmpeg though
[10:45:22] <kshishkov> I know it's trivial, but why don't we have it supported in FFmpeg yet?
[10:45:49] <av500> DonDiego: Archos customers
[10:46:22] <DonDiego> it's trivial? what has to be done?
[10:46:45] <av500> wait a sec
[10:47:18] <av500> whet http://www.youtube.com/watch?v=XXXXXXXXXXX
[10:47:19] <kshishkov> 1) read page 2) extract info 3) construct URL 4) read it 5) ... 6) playing!
[10:47:24] <av500> wget
[10:48:28] <av500> you can even add &fmt=YY to get different formats (SD,HD...()
[10:50:30] <thresh> they break the page from time to time
[10:50:39] <thresh> like, every few months.
[10:51:01] <av500> thresh: yep
[10:51:19] <thresh> morning, btw
[10:51:21] <av500> thats why we actually host the parsing script on our website, no need to update the SW :)
[10:51:35] <thresh> ah, nice
[11:02:42] <CIA-46> ffmpeg: pross * r21994 /trunk/libavformat/bink.c: Bink audio pts starts at 0, not reported_size
[11:06:24] <CIA-46> ffmpeg: mstorsjo * r21995 /trunk/libavformat/ (rtsp.c rtsp.h): Cosmetics: reindent
[11:16:08] <CIA-46> ffmpeg: pross * r21996 /trunk/libavformat/bink.c: Set video stream duration for Bink demuxer
[11:16:18] <kshishkov> yay!
[11:16:42] <pross-au> i have isolated the 'video goes farking slow' problem
[11:16:52] <kshishkov> good
[11:17:01] <pross-au> seems to be caused by excessive buffering in the files
[11:17:48] <pross-au> e.g. the audio frames are cramed at the start, video packets are more-so at the end
[11:36:12] <DonDiego> mru: btw, i propose adding -Wmissing-prototypes to CFLAGS
[11:36:40] <Kovensky> -Wall -Wextra -pedantic? :D
[11:36:55] <DonDiego> we have -Wall
[11:37:06] <Kovensky> inb4 ffmpeg's compile spends more CPU time on stderr than on actually compiling
[11:37:19] <Kovensky> :>
[11:37:24] <DonDiego> inb4?
[11:37:39] <Kovensky> "in before", internetspeak
[11:40:30] <DonDiego> i don't see that sentence making any sort of sense
[11:41:09] <DonDiego> what english expression does "in before" translate to?
[11:42:18] <kshishkov> who said anything about English?
[11:45:53] <Kovensky> DonDiego: as I said, it isn't english, it's internetish :)
[11:46:28] <pross-au> 'netspeak, Kovensky, get with the programme
[11:48:22] <Kovensky> DonDiego: urbandictionary is your friend: http://www.urbandictionary.com/define.php?term=inb4 / http://www.urbandictionary.com/define.php?term=in%20b4
[11:50:08] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJoke
[11:50:17] <Kovensky> elenril: oic
[11:50:19] <Kovensky> oh well
[11:50:36] * Kovensky be late
[11:50:41] <Kovensky> classes started 50 minutes ago :D
[11:51:06] <Kovensky> time to do my daily 1h20m commute to college... + 1h20m to commute back <_<
[11:51:15] <Kovensky> (and that's only 20km >_>)
[11:51:19] <elenril> get a better college?
[11:51:59] <kshishkov> or better commuter
[11:52:11] <Kovensky> there are only busses here
[11:52:15] <av500> or better distance
[11:52:24] <Kovensky> and they're often so stuffed you can't even try to get on them
[11:53:05] <Kovensky> anyway, I'm out \o
[11:54:17] <Compn> carpool with some other dingus
[11:54:29] <Compn> or a professor
[11:54:30] <Compn> :P
[11:54:37] * kshishkov has half a dozen of universities in 15 min walk
[11:54:47] <pross-au> Kovensky: its a 1h15m bike ride to my work
[11:55:41] <kshishkov> I thought you can go by tram
[11:56:33] <pross-au> kshishkov: not to work
[11:56:38] <pross-au> but we have lots of 'em
[11:56:51] <pross-au> *someones* been studying AUSTRALIA :D
[11:57:03] <av500> pross-au: whereabouts?
[11:57:20] <pross-au> Melbournem, Victoria
[11:57:21] <kshishkov> well, Melbourne has a reputation of Australian Göteborg
[11:57:31] <av500> pross-au: ah, the other city :)
[11:57:46] * av500 likes Melbourne better
[11:58:02] <kshishkov> better than what?
[11:58:08] <av500> the other city
[11:58:16] <pross-au> other?
[11:58:18] <av500> they have 2 of them
[11:58:23] <kshishkov> you mean the one with tissue box opera?
[11:58:27] <av500> yep
[11:58:30] <pross-au> We have more then two my friend
[11:58:38] <av500> pross-au: I know, been there :=
[11:58:53] <pross-au> Cool
[11:59:04] <av500> I have relatives in Melbourne actually
[11:59:08] * kshishkov is unlikely to get even to Serbia
[11:59:25] <av500> kshishkov: you are more than welcome should you chose too :)
[12:00:04] <kshishkov> av500: my Serbian is nonexistent and they had no reason to learn Russian
[12:01:00] <av500> true, they rather learned english
[12:01:06] <pross-au> who in their right mind would discount life australia based on our extreeme climate
[12:01:11] <pross-au> *life in
[12:01:31] * kshishkov points to himself
[12:02:34] <av500> kshishkov: at least no ice on the roads... ;)
[12:02:40] * thresh would like to melt instead of freezing
[12:03:11] <kshishkov> av500: I can't think when the temperature is high
[12:03:59] <av500> try watercooling
[12:04:20] <kshishkov> Australia is not famous for water
[12:05:04] <kshishkov> I've even heard that when their rivers have water is an extreme situation
[12:05:17] <av500> yes
[12:05:25] <kshishkov> (and once they cancelled boat racing because of that)
[12:13:25] <pross-au> kshishkov: desal
[12:13:39] <kshishkov> what's that?
[12:13:58] <pross-au> salt water in one end, drinkable water out the other
[12:14:13] <pross-au> kinda like a video decoder
[12:14:21] <kshishkov> ah
[12:14:24] <pross-au> (making sure we stay on subject)
[12:14:40] <kshishkov> that's rather denoiser ;)
[12:15:02] <CIA-46> ffmpeg: michael * r21997 /trunk/libavutil/fifo.c: Clarify non constness of src in av_fifo_generic_write()
[13:43:33] <mru> btw, somethings wrong with vc1dec
[13:43:42] <kshishkov> what?
[13:43:47] <mru> it crashes on avr32 and valgrind complains
[13:44:14] <kshishkov> what are those complains?
[13:45:23] <mru> hmm, now it's not complaining
[13:45:39] <mru> but it crashes on avr32 while freeing memory at the end
[13:45:50] <mru> I'm guessing corruption somewhere
[13:46:38] <kshishkov> could be
[13:49:44] <mru> also leaking memory
[13:50:48] <mattg> mru: apologies for the green issue before which i attributed to ARM - it's not ARM at all. infact I can replicate it on x86.
[13:51:01] <mru> then it's just a broken file
[13:51:52] <kshishkov> mru: I was not able to trace those leaks. Valgrind says it's from some av_mallocz() but none of av_mallocz() in vc1dec.c it seems
[13:52:11] <mattg> i found that if you memset the AVFrame's data buffers each time ffmpeg asks for a new buffer (i.e. don't just throw it the old one, reset the data to 0s, and then set the age to 256*256*256*64) then x86 and arm both give the green frames i was seeing
[13:52:49] <mru> kshishkov: http://pastebin.ca/1806766
[13:54:02] <mattg> mru: do you happen to know who i could speak to regarding this? i think it may be an ffmpeg bug but i haven't pinned it down yet for sure, but i'd certainly like to find it.
[13:54:34] <mru> "Too many slices, increase MAX_SLICES and recompile"
[13:54:52] <kshishkov> mru: I suspected that. Maybe forgot to call MPV_common_close() somewhere
[13:55:18] <mru> I see an MPV_common_end() call...
[13:55:30] <mru> in fact, that's where it crashes on avr32
[13:56:20] <kshishkov> that's bad and the fact I can't find a reason is even worse
[13:57:19] <mattg> mru: it's nothing to do with MAX_SLICES. i upped to 32, checked that there were no more MAX_SLICES errors and can still reproduce.
[13:57:36] <mru> mattg: go shout at whover encoded the file
[14:22:23] <mru> http://www.4p8.com/eric.brasseur/gamma.html
[14:23:17] <av500> I wanted to paste that too
[14:28:30] <kshishkov> what's the morale? Smart browsers throw away noise on scaling leaving only gray background or what?
[14:29:10] <twnqx> smart broser use fractal scaling!
[14:29:19] <av500> I guess it would be nice to have gamma/degamma SIMD opcodes :)
[14:31:15] <Kovensky> < pross-au> Kovensky: its a 1h15m bike ride to my work <-- at least you only depend on yourself, you don't have to wait until some usable bus passes by and can avoid traffic jams ._.
[14:33:15] <kshishkov> av500: the funniest thing is that I'm on Mac and it uses different gamma value
[14:35:48] <av500> kshishkov: I'm sure intel can make a custom CPU for the fruit company...
[14:36:19] * kshishkov would like IBM to do that instead
[14:36:56] <kshishkov> with all its quirks, PowerPC is better than x86. Well, almost everything is
[14:39:41] <av500> kshishkov: well, now with apple making their own chips, you can rally them to make PPC....
[14:40:12] <kshishkov> they don't make desktop/server CPUs yet :(
[14:47:58] <superdump> can anyone remember the oprofile macros for starting/stopping profiling in-line with C code?
[14:48:28] <mru> there are such?
[14:48:53] <superdump> i think so
[14:49:00] <superdump> unless i'm thinking of something else
[14:49:52] <superdump> i want to profile some code in an isolated manner
[14:50:14] <superdump> rather than wading through piles of crap to get the information i want
[15:00:07] <mru> what kind of crap?
[15:00:32] <mru> you can restrict the output of opreport and opannotate to specific files or functions
[15:09:40] <CIA-92> ffmpeg: michael * r21999 /trunk/ffmpeg.c:
[15:09:40] <CIA-92> ffmpeg: Redesign opt_programid code.
[15:09:40] <CIA-92> ffmpeg: Its now possible to also select programs per input file and there is
[15:09:40] <CIA-92> ffmpeg: less code duplication.
[16:13:45] <CIA-92> ffmpeg: daniel * r22000 /trunk/libavcodec/Makefile: Cosmetics: break all Makefile lines at 80 columns or less
[16:22:10] <mru> kshishkov: compiler bug
[16:22:19] <mru> it's adding an array index twice
[16:22:25] <kshishkov> mru: hello to codesourcery?
[16:22:30] <mru> atmel
[16:25:49] <mru> hexedit ftw
[16:25:57] <andoma> :)
[16:26:27] <kshishkov> so that's how you patch compilers?
[16:26:54] <mru> that's how I patch the code produced by the compiler
[16:29:44] <mru> btw, is it just me are those pkgconfig trolls getting annoying?
[16:30:17] <kshishkov> just think about autoconfig trolls and relax ;)
[16:30:50] <mru> they are closely related
[16:30:57] <mru> maybe killing one will harm the other
[16:31:02] * mru loads shotgun
[16:31:12] <kshishkov> and if you mean that guy who still uses French Revolutionary calendar, that is a dead giveaway
[16:31:23] <kshishkov> prepare guillotine then ;)
[16:31:36] <mru> which one? felipe or nicolas?
[16:31:42] <av500> mru: kill them slowly, this is so much fun to read
[16:31:48] <CIA-92> ffmpeg: michael * r22001 /trunk/libavformat/utils.c:
[16:31:48] <CIA-92> ffmpeg: Count all frames with codec_info_nb_frames not just ones with non zero
[16:31:48] <CIA-92> ffmpeg: duration. I hope this breaks nothing. Its needed for my fix of issue1156
[16:31:49] <kshishkov> Nicolas
[16:32:24] <CIA-92> ffmpeg: michael * r22002 /trunk/ffmpeg.c:
[16:32:24] <CIA-92> ffmpeg: Favor streams with more packets if the user did not specify what she wants.
[16:32:24] <CIA-92> ffmpeg: Fixes issue1156
[16:33:09] <kshishkov> "she wants"?
[16:33:24] * mru looks around for girls
[16:33:41] * mru sees none
[16:35:41] <kshishkov> mru: I heard there's a rule "there are no girls among FFmpeg users"
[16:36:13] <mru> untrue: http://www.youtube.com/watch?v=iIalNEW-LQ8
[16:36:32] <av500> mru: you put that on F12?
[16:36:52] <mru> top hit when searching yt for ffmpeg
[16:37:01] <elenril> kshishkov: http://tvtropes.org/pmwiki/pmwiki.php/Main/ThereAreNoGirlsOnTheInternet
[16:37:27] <kshishkov> I thought that YouTube is itself top hit for FFmpeg (alas with <noref>)
[16:47:29] <CIA-92> ffmpeg: michael * r22003 /trunk/ffplay.c: Replace *_index by st_index[codec_type].
[16:50:05] <CIA-92> ffmpeg: ramiro * r22004 /trunk/libavdevice/vfwcap.c:
[16:50:05] <CIA-92> ffmpeg: vfwcap: support MJPG compressed streams.
[16:50:05] <CIA-92> ffmpeg: Patch by Nash Tsai <nash dot tsai at gmail dot com>
[16:55:01] <CIA-92> ffmpeg: ramiro * r22005 /trunk/libavcodec/mlp_parser.c:
[16:55:01] <CIA-92> ffmpeg: mlp_parser: Fix memleak.
[16:55:01] <CIA-92> ffmpeg: ff_combine_frame() is called, which allocates ParseContext->buffer if needed,
[16:55:01] <CIA-92> ffmpeg: so ff_parse_close() must be called to free it.
[16:55:01] <CIA-92> ffmpeg: Patch by jai.
[16:57:11] <CIA-92> ffmpeg: michael * r22006 /trunk/ffplay.c: replace wanted_*_stream by wanted_stream[CODEC_TYPE]
[17:00:06] * elenril lols at http://mailman.videolan.org/pipermail/vlc-devel/2008-June/045064.html
[17:01:18] * kshishkov likes "fix something" more
[17:02:03] * av500 has kill_all_orphans() ...
[17:02:27] * elenril always thought av500 was evil
[17:02:48] * av500 inserts evil laughter
[17:03:10] * kshishkov smiles from the dark corner
[17:03:22] <av500> dark country, no?
[17:03:40] <kshishkov> and very righteous too
[17:03:41] <elenril> you're all evil and lazy!
[17:03:49] <elenril> btw anyone wants to apply a few patches? :)
[17:04:08] <kshishkov> elenril: you should've asked when benoit- was around
[17:04:46] <elenril> :/
[17:10:41] <CIA-92> ffmpeg: michael * r22007 /trunk/ffplay.c: Dont modify wanted_stream.
[17:14:58] <Dark_Shikari> siretart`: ping
[17:15:58] <siretart`> Dark_Shikari: at work, but around
[17:17:29] <Dark_Shikari> so, we have our first problem
[17:17:32] <Dark_Shikari> r1448 had some stupid errors
[17:17:37] <Dark_Shikari> which I fixed... in r1461
[17:17:53] <Dark_Shikari> or actually wait, let me check...
[17:18:05] <Dark_Shikari> phew, we're good!  none of the changes up to r1448 broke anything
[17:18:16] <Dark_Shikari> nevermind then, you're good
[17:18:18] <Dark_Shikari> r1448 is stable.
[17:18:29] <Dark_Shikari> I guess not having big changes increases likelihood of stable :)
[17:20:21] <siretart`> Dark_Shikari:  I have filed
[17:20:21] <siretart`> https://bugs.launchpad.net/bugs/526396 for tracking this. I'll make a
[17:20:21] <siretart`> note make that r1461 instead of r1448
[17:20:37] <Dark_Shikari> er, no
[17:20:42] <Dark_Shikari> keep it at r1448
[17:20:43] <Dark_Shikari> as I said
[17:21:01] <Dark_Shikari> r1461 adds new features, and we're past the feature freeze ;)
[17:21:14] <siretart`> ah, you have fun with confusing me. ok
[17:21:19] <Dark_Shikari> I mistakenly thought r1448 had a bug
[17:21:23] <Dark_Shikari> and r1461 fixed issues in r1448
[17:21:25] <Dark_Shikari> _but_
[17:21:31] <Dark_Shikari> all the issues fixed in 1461 were created after 1448
[17:21:38] <siretart`> great
[17:21:48] <Dark_Shikari> 1a6d32b4a4 should be your revision.
[17:36:37] <CIA-92> ffmpeg: michael * r22008 /trunk/ffplay.c: Also favor streams with more packets in ffplay.
[17:37:56] <mru> "people who know how their programs work do better than those who do not", wow... such insight
[17:39:18] <av500> where?
[17:39:31] <mru> http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
[17:42:40] <Dark_Shikari> lol
[17:44:25] <elenril> http://xkcd.org/703/
[17:44:41] <mru> yeah, good one
[17:45:59] <av500> mru: you get paid to read that paper?
[17:46:09] <mru> av500: no
[17:46:28] <mru> it was linked on HN
[17:47:04] <av500> ah
[17:47:26] * av500 reloads
[17:47:34] <siretart`> HN?
[17:47:40] <av500> http://news.ycombinator.com/
[17:48:08] <siretart`> ah, thnx
[17:48:47] * mru doesn't often get paid to read stuff
[17:48:53] <mru> that's why most of my code is write-only
[17:53:55] <kshishkov> mru: not in this community
[18:21:15] <janneg> lol, I found the first error in the big buck bunny sources: http://www.jannau.net/peach_2700x1440/01_intro.mkv
[18:21:42] <Dark_Shikari> error?
[18:22:30] <janneg> the eyes aren't moving with the body in the third scene
[18:22:37] <janneg> watch the video
[18:22:49] <Dark_Shikari> fix it? ;)
[18:24:12] <janneg> how?
[18:24:31] <kshishkov> by modifying sources and rerendering
[18:24:43] <mru> or by editing the mkv with hexedit
[18:25:07] <Dark_Shikari> mru: lol
[18:25:09] <kshishkov> do you think he can reencode H.264 in his head?
[18:25:35] <Dark_Shikari> LOL @ the eyes
[18:25:38] <Dark_Shikari> lmao
[18:25:43] <Dark_Shikari> how the fuck did that happen
[18:26:49] <janneg> blender uses a binary format. or maybe just xml + compression
[18:37:02] <janneg> downloaded the source from the peach studio backup with the same error
[18:37:29] <mru> don't get the backup, get the files they used for the production render
[18:37:31] <mru> ;-)
[18:38:10] <kshishkov> or re-create them
[18:38:11] <janneg> I don't care and I won't rerender the scene
[18:41:51] <Dark_Shikari> why, because its hilarious?
[18:46:41] <janneg> because it takes too much time, there seems to be no public svn repo for blender or peach and I think they deserve being ridiculed by releasing files with such error
[18:47:18] <kshishkov> ever heard of Matrix?
[19:05:53] <_av500_> janneg: change the eyes to ffmpeg logos
[19:07:14] <FFeyes> this way? :P
[19:44:58] <elenril>  /nick Honoome fflameeyes
[19:49:21] <Kovensky> fflames
[19:49:42] <Kovensky> "/nick Honoome Shana" also works I guess
[19:50:34] * elenril thinks Kovensky is confusing #ffmpeg-devel with #mplayerdev 
[19:50:36] * Honoome is cofnused nw
[19:50:45] <Honoome> and my keyboard as well
[19:51:04] <Kovensky> elenril: =p
[19:51:18] <elenril> Honoome: your patch still not oked?
[19:52:01] <Kovensky> Honoome: Shana from Shakugan no Shana has flame eyes
[19:52:23] <Honoome> elenril: waiting for Baptiste to be sure… specially because I'm not totally sure about Michael's rebus… the only place where I see the “official” name being related to “author” is mov and 3gpp
[19:52:32] <Honoome> Kovensky: never seen that, anime I assume?
[19:54:40] <Kovensky> light novel / anime
[19:54:42] <elenril> Honoome: michael is default maintainer, everything not listed belongs to him
[19:54:44] <Kovensky> I never saw it either =p
[19:58:20] * elenril wonders wtf is rpl and vqf
[19:59:03] <Honoome> elenril: that much I know
[19:59:36] <elenril> "Regarding Bink, a lot of games use Theora nowadays (StarCraft 2, for example)." << wut
[20:00:20] <Dark_Shikari> it _is_ better than bink
[20:00:39] <Dark_Shikari> gotta be honest about that =p
[20:00:44] <elenril> lol
[20:00:46] <_av500_> and freer
[20:01:08] <j-b> Hello
[20:01:10] <elenril> but a lot of games?
[20:01:15] * elenril didn't see a single one
[20:05:15] <peloverde> A handful of old games used VP3
[20:06:29] <peloverde> Also I haven't seen the star craft 2 cinematics but the ones from starcraft 1 were way overcompresseed
[20:07:01] <kierank> maybe they got vorbis and theora confused
[20:07:10] <kierank> tons of games use vorbis
[20:07:16] <elenril> otoh it ran on 486's
[20:07:27] <Dark_Shikari> starcraft 1 used smacker
[20:08:22] <elenril> can ffmpeg play them?
[20:08:33] <Dark_Shikari> yes iirc
[20:11:30] <peloverde> If theora is as good as its advocates say it is, why are they be so concerned about VP8?
[20:12:11] <Dark_Shikari> don't apply logic to them ;)
[20:12:16] <Dark_Shikari> also, because vp8 is 50% better than h264
[20:12:17] <Dark_Shikari> obviously
[20:12:33] <Yuvi> on2 says so, it must be true!
[20:12:50] <elenril> does vp mean anything btw?
[20:13:26] <_av500_> my initials
[20:17:25] <CIA-92> libswscale: ramiro * r30722 /trunk/libswscale/swscale_template.c: Reorder buffer debug. Also print out if slice was buffered.
[20:18:16] <DonDiego> mru: what about -Wmissing-prototypes?
[21:01:58] <mru> DonDiego: go for it
[21:04:18] <CIA-92> ffmpeg: diego * r22009 /trunk/configure: Add -Wmissing-prototypes to CFLAGS if available.
[21:06:29] <peloverde> why is the uspto site so terrible?
[21:06:37] <kierank> because it's government designed
[21:07:07] <kierank> government designed back when citizen facing projects were treated like miltary projects
[21:08:10] <mru> i.e. best kept secret
[21:08:19] <mru> use google patents instead
[21:29:00] <DonDiego> now let's see if the ton of warnings generated by -Wmissing-prototypes gets ignored as usual
[21:45:57] <anhanguera> hi, where should i send a possible fix for memory leak in libavcodec?
[21:46:15] <mru> ffmpeg-devel mailing list would be fine
[21:46:41] <mru> if it's not obvious, try to describe the error and the fix as clearly as possible
[21:47:18] <anhanguera> ah, hi mru. ok thanks.
[21:53:20] <anhanguera> mru, actually commenting libavcodec/vc1dec.c lines 2998, 2999 will fix the leak, as h363_decode_init() is called twice. 1- directly from vc1dec.c:2998, 2- indirectly from v1dec.c:3001. anyway i will send an email abou that
[21:59:30] <ramiro> anhanguera: are you brazilian?
[22:01:31] <anhanguera> ramiro, no. but read about a pterosaur named anhanguera, and loved the meaning.
[22:07:36] <CIA-92> ffmpeg: michael * r22010 /trunk/ffmpeg.c: Set ist->pts to something that isnt guranteed to entangle itself with stream copying b frames.
[22:21:33] <mru> http://ie6funeral.com/
[22:22:56] <peloverde> meh, ie6 has been dead to me for years
[22:24:05] <mru> I'm getting ~8% IE6 on my blog
[22:24:22] <mru> more than any other IE version
[22:24:34] <mru> maybe my stats aren't representative...
[22:24:46] <Dark_Shikari> mru: I got like 2% last I looked
[22:24:49] <Dark_Shikari> among all IEs
[22:25:12] <mru> looking stats for all last year, I have 16% all IE
[22:25:18] <mru> 7.9% IE6
[22:25:37] <mru> that's 7.9% of total
[22:25:47] <Dark_Shikari> from the past 2 days, where I got ~20k hits
[22:25:59] <Dark_Shikari> 30% safari, 28% firefox, 25% chrome, 8% "mozilla compatible", 4% IE
[22:26:48] <mru> this month I have 10% IE
[22:26:58] <mru> equally split between 6, 7, and 8
[22:27:10] <mru> 45% firefox
[22:27:25] <mru> 14% chrome
[22:28:04] <mru> and one hit from lynx
[22:28:27] <Dark_Shikari> in the 3 weeks before my recent 20k hits
[22:28:30] <Dark_Shikari> 51% firefox
[22:28:32] <Dark_Shikari> 17% chrome
[22:28:33] <thresh> i wonder who was that pour soul with lyns
[22:28:34] <thresh> lynx
[22:28:34] <Dark_Shikari> 11% IE
[22:28:36] <Dark_Shikari> 10% safari
[22:28:41] <Dark_Shikari> 7.5% opera
[22:28:43] <mru> lynx ain't bad
[22:28:52] <Dark_Shikari> I think the high Safari % of the past 2 days is because I was linked on DaringFireball
[22:29:51] <mru> that reddit post gave me 33k hits in one day
[22:30:01] <mru> 18k the following day
[22:30:44] <Dark_Shikari> lol
[22:30:46] <Dark_Shikari> reddit ftw
[22:33:20] <Dark_Shikari> 06:32 < BugMaster> ramiro: while you here may be also look at this patch for ffmpeg and non mod4 rgb24 pixel-format: http://pastebin.com/pc62RxpF (don't have time and will to register for ffmpeg mail-list)
[22:40:59] <ramiro> Dark_Shikari: I saw that. I'll look at it now.
[23:12:44] <peloverde> Dark_Shikari, ramiro: still doesn't make up for my comment that DivX 6 is MPEG-4 ASP being downvoted to -10
[23:13:05] <Dark_Shikari> lol
[23:14:14] <mru> peloverde: comment where?
[23:14:27] <peloverde> reddit, twoish years ago
[23:14:31] <mru> oh
[23:14:38] <ramiro> peloverde: mru got similarly downvoted on reddit...
[23:14:50] <ramiro> I don't know why you guys care so much about reddit. seems like a waste of time to me.
[23:14:57] <mru> I don't care about reddit
[23:14:57] <Dark_Shikari> same
[23:15:08] <ramiro> well, but you're subscribed, and reply
[23:15:12] <ramiro> that means you do care.
[23:15:14] <kierank> only thing interesting about reddit is iama
[23:15:24] <mru> I only subscribed so I could reply to the comments about my blog post
[23:15:43] <mru> haven't touched it before or since
[23:15:56] <ramiro> to "defend yourself"?
[23:16:28] <mru> the discussion was a bit one-sided
[23:17:00] <peloverde> reddit was also all up in arms when we started going after our violators
[23:17:08] <mru> lol
[23:17:53] <mru> btw, I just found this regex in my .emacs: "/ffmpeg\\.\\([^/]*\\)/\\([^/]+\\(/[^/]+\\)/\\)?"
[23:18:32] <Kovensky> why are all the \ escaped
[23:19:20] <mru> becaue they're in a string
[23:19:22] <Kovensky> and why are the () escaped? o_O
[23:19:47] <mru> to match a literal \ you need \\\\
[23:20:12] <mru> \\( becomes \( which is the emacs-regex grouping construct
[23:20:21] <Kovensky> ic
[23:20:24] * Kovensky prefers his perl regexps
[23:20:41] <mru> just remember which is which
[23:22:35] <Kovensky> m!/ffmpeg\.([^/]*)/([^/]+(/[^/]+)/)?! <-- slightly more readable :)
[23:23:22] <mru> yes, I too slightly prefer perl regex
[23:23:31] <mru> but emacs isn't written in perl
[23:23:43] <Kovensky> libpcre?
[23:23:57] <mru> obviously not
[23:24:12] <Kovensky> :p
[23:42:02] <CIA-92> ffmpeg: michael * r22011 /trunk/ffmpeg.c: Attempt to fix issue1728 and regression of issue203
[23:48:45] <j-b> ruggles?


More information about the FFmpeg-devel-irc mailing list