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

[irc at mansr.com]

[00:02:17] <jannau> ubitux: patchwork seems to have problems with your name
[00:02:50] <ubitux> just trash it if you need; é → e, œ → oe, i don't really care :p
[00:03:01] <spaam> pfff
[00:03:30] <spaam> jannau: they need to fix their stuf so it works with the future where we have unicode...
[00:04:09] <jannau> spaam: it should handle unicode just fine
[00:05:06] <spaam> it should yes.. but it does not. it have some problem with frog eating ubitux ;D
[00:05:21] <ubitux> :)
[00:05:26] <saintd3v> so now that we have new leadership, when do we get per-codec defaults
[00:05:28] * saintd3v hides
[00:11:06] <JEEB> saintd3v, watches pelcome is what was said to me
[00:12:24] <saintd3v> where's Dark_Shikari's patch?
[00:13:25] <JEEB> it was he whom said it to me ;)
[00:24:16] <ubitux> what is the queue system for? does it allows a fate-run before getting the patchs upstream?
[00:25:44] <jannau> there is no queue system. http://patchwork.libav.org is just for keeping track of patches
[00:27:20] <saintd3v> fate is in the process of breaking
[00:27:31] <mru> no
[00:27:38] <mru> a few broke and then we fixed it
[00:27:43] <saintd3v> ah
[00:28:00] * saintd3v crawls back into the shadows
[00:29:42] <ubitux> does patchwork detect incoming patchs, apply and rejection from patterns in the ml?
[00:31:22] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * rf4b1e21a63 ffmpeg/tests/ (21 files in 2 dirs):
[00:31:22] <CIA-29> ffmpeg: fate: make lavfi tests output only md5
[00:31:22] <CIA-29> ffmpeg: Instead of saving huge raw files, use the md5: output pseudo-protocol
[00:31:22] <CIA-29> ffmpeg: to calculate the checksum of the file directly. This is especially
[00:31:22] <CIA-29> ffmpeg: useful when testing on remote targets as it avoids transferring 3.6GB
[00:31:22] <CIA-29> ffmpeg: over the network.
[00:31:56] <CIA-29> ffmpeg: Clément Bœsch <ubitux at gmail.com> master * r045b80e52d ffmpeg/ (libavcodec/mpegaudiodec.c libavformat/mp3dec.c):
[00:31:56] <CIA-29> ffmpeg: Move ID3v1 skip from decoder to demuxer
[00:31:56] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[00:33:14] <jannau> it get patches and comments from the ml, apply from a git repo
[00:34:07] <ubitux> purge of rejected/invalid patchs is manual?
[00:34:41] <jannau> I have to check if it supports commands from mails
[00:36:18] <BBB> jannau: if you want to queue more patches, the last few of elenril that were not committed yet can be committed now also
[00:36:58] <BBB> oh mru is still awake
[00:37:29] <mru> I'm not the _only_ one who can push patches
[00:56:00] <jannau> BBB: care to ok them on the ml?
[00:57:48] <BBB> jannau: done
[01:06:26] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rcb6bc57681 ffmpeg/libavformat/ (id3v2.c id3v2.h mp3enc.c):
[01:06:26] <CIA-29> ffmpeg: id3v2: split tables for various ID3v2 versions
[01:06:26] <CIA-29> ffmpeg: This is needed for upcoming ID3v2.3 muxing support.
[01:06:26] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[01:06:38] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r8c3caf7fb1 ffmpeg/libavformat/mp3enc.c:
[01:06:38] <CIA-29> ffmpeg: mp3enc: handle errors in id3v2_put_ttag
[01:06:38] <CIA-29> ffmpeg: make the initialization of put clearer
[01:06:38] <CIA-29> ffmpeg: this are the differences between
[01:06:38] <CIA-29> ffmpeg: [FFmpeg-devel] [PATCH 1/3] mp3enc: add support for writing UTF-16 tags
[01:06:38] <CIA-29> ffmpeg: and the already applied 187e23478bc5c066ff8eef562925471ac179644e
[01:06:39] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[01:06:40] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r22272f61bb ffmpeg/libavformat/mp3enc.c:
[01:06:40] <CIA-29> ffmpeg: mp3enc: support for id3v2.3 tags using a per-muxer AVOption
[01:06:40] <CIA-29> ffmpeg: fixes issue2562.
[01:06:41] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[01:14:30] <mru> new fate feature
[01:15:00] <mru> build errors show the last few lines of the log directly in the index view
[01:15:05] <BBB> \o/
[01:15:07] <BBB> that is awesome
[01:16:06] <BBB> would be better if it used newlines where appropriate :-p
[01:16:13] <mru> huh?
[01:16:17] <BBB> what's all those compile errors in arm etc?
[01:16:27] <mru> random compiler crash
[01:16:39] <mru> the arm one
[01:16:44] <relaxed> mru: you added freebsd, thanks!
[01:16:52] <mru> relaxed: not me
[01:17:10] <mru> BBB: then we accidentally broke shared libs earlier
[01:17:10] <relaxed> oh, then thanks to however did.
[01:17:12] <mru> fixed now
[01:17:24] <BBB> oh that ok
[01:17:26] <mru> relaxed: michael kostylev runs those
[01:17:44] <mru> BBB: but what about newlines?
[01:17:55] <BBB> the compiler output in main view has no newlines
[01:17:59] <mru> does here
[01:18:03] <BBB> hm...
[01:18:07] <BBB> chrome doesn't display them
[01:18:08] <mru> maybe youre crappy browser doesn't support proper css
[01:18:18] * BBB goes watch movie
[01:18:19] <BBB> brb
[01:18:29] <mru> try in firefox
[01:18:41] <BBB> fix it in chrome!
[01:18:52] <mru> I can't fix what I can't see
[01:22:06] <mru> try now
[01:22:26] <jannau> updating patchwork from the post-receive hook works
[01:23:21] * jannau wonders if he should try to import patch backlog into patchwork
[01:26:12] <mru> how far back?
[01:26:33] <mru> can it handle svn diffs?
[01:37:17] <jannau> just a couple of days/weeks. It claims to be scm agnostic and creates a hash of the diff
[01:38:19] <mru> how does it deal with patch revisions?
[01:42:30] <jannau> it seems to handle them badly looking at http://patchwork.libav.org/patch/171/
[01:48:23] <jannau> mru: please mirror to gitosis at git.jannau.net:ffmpeg-pw
[01:51:02] <mru> using what credentials?
[01:51:09] <jannau> private key per mail
[01:51:40] <mru> which is the proper hook for this?
[01:52:27] <jannau> post-receive
[01:54:11] <mru> application/vnd.lotus-organizer wtf?
[01:54:11] <jannau> while read oldrev newrev refname; do
[01:54:36] <jannau>   git push patchwork $refname:$refname
[01:54:39] <jannau> done
[01:55:46] <mru> I've forbidden creation of new branches for now
[01:56:00] <mru> to guard againt accidental weird pushes
[01:57:29] <jannau> pushes for release/0.6 are not impossible
[01:57:40] <mru> right
[01:57:51] <mru> I was doing the loop anyway
[02:02:23] <mru> should be all set
[02:02:57] <mru> now we just need something to push
[02:07:52] <jannau> one of the profiles patches was oked, I'll push it
[02:11:09] <mru> what happened to patch queue?
[02:11:22] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * rb92f76e209 ffmpeg/libavcodec/libfaac.c:
[02:11:22] <CIA-29> ffmpeg: libfaac: add recognized profiles array
[02:11:22] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[02:11:42] <jannau> mru: remote: Host key verification failed.
[02:11:50] <mru> hmpf
[02:14:08] <jannau> I'm bouncing atm the last 1500 mails to patchwork, will get cleaner after updating the status from commits from same period
[02:14:22] <mru> ok
[02:14:24] <jannau> hopefully
[02:14:46] <mru> now how to debug the key problem?
[02:15:41] <jannau> is the host key in ~git/.ssh/known_hosts ?
[02:16:16] <mru> guess not
[02:16:58] <mru> now it is
[02:22:12] <mru> see any more approved patches?
[02:53:12] <jannau> "fate: add lossless h264 test" should be safe now
[03:09:37] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r76edf2c137 ffmpeg/tests/ (fate/h264.mak ref/fate/h264-lossless):
[03:09:37] <CIA-29> ffmpeg: fate: add lossless h264 test
[03:09:37] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[03:10:20] <mru> jannau: http://pastebin.com/K781TqZB
[03:11:04] <CIA-29> ffmpeg: Mike Scheutzow <mjs973 at optonline.net> master * r20ac9de3df ffmpeg/ (doc/ffmpeg.texi ffmpeg.c): (log message trimmed)
[03:11:04] <CIA-29> ffmpeg: streamid does not work with newaudio, newvideo, newsubtitle
[03:11:04] <CIA-29> ffmpeg: fixes issue2465.
[03:11:04] <CIA-29> ffmpeg: The problem is that the ffmpeg (the app) -streamid option did not work
[03:11:04] <CIA-29> ffmpeg: with -newaudio/-newvideo/-newsubtitle.
[03:11:05] <CIA-29> ffmpeg: The cause was a conflict between the feature where streamid values were
[03:11:06] <CIA-29> ffmpeg: reset to default for each output filename, and the implementation of
[03:12:31] <jannau> mru: nice, seems to work
[03:13:46] <mru> now we need to clean out applied patches
[03:13:48] <jannau> it doesn't seem to like the rewritten commit msg from svn commits
[03:47:21] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r98cfadd648 ffmpeg/libavcodec/iirfilter.c:
[03:47:21] <CIA-29> ffmpeg: 10l: reverse the biquad coefficients.
[03:47:21] <CIA-29> ffmpeg: I did not notice that the filter implementation uses a reversed history state.
[03:47:21] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[03:57:53] <BBB> uh so you guys can now remotely push?
[04:00:20] <jannau> no, my current workflow is: pwclient view $PATCH_NUM | git am -s - ; git pull --rebase ; git push
[04:01:09] <jannau> ommitting looking at the patch and building it
[05:00:55] <peloverde> Anyone know a smart visual tool for diffing binaries?
[05:04:15] <pross-au> vbindiff
[05:08:43] <peloverde> nope
[05:09:07] <peloverde> vbindiff doesn't seem to make any attempts to resynchronize
[05:12:00] <peloverde> for now I'm using gvimdiff and the debug prints in mov.c
[05:12:28] <peloverde> But I think a content aware mov/mp4 differ/hexeditor would be awesome
[05:23:20] <saintdev> not the cyborg apocalypse!
[05:23:55] <saintdev> 16saayunz must be the instigator, we must find him and destroy him.
[05:23:57] <peloverde> sadly I thought a program had locked my soundcard but it turns out I had headphones plugged in
[05:24:23] <saintdev> lol!
[05:24:46] <peloverde> Computers are dumber than humans but smarter than programmers
[05:26:18] <saintdev> fuser /dev/snd/*
[08:34:13] <_av500_> jannau: so remark on it
[08:36:11] <_av500_> jannau: i guess is ignore that since my french coworkers like epic variable names
[08:36:39] <_av500_> some derserve an ISBN even
[08:37:41] <kierank> why do french coworkers like epic variable names?
[08:44:17] <_av500_> too much lit classes in school or so
[08:55:29] <pJok> _av500_, thisvariablenameistooshortsoineededtomakeitevenlongerforittobeclosetoratherepic ?
[08:56:37] <kierank> pJok: wrong language
[08:56:51] <pJok> i dont speak french
[08:57:09] <pJok> but since french people usually don't speak anything else, it doesn't matter
[08:57:35] <pJok> or wait, i think that were actually french belgians that refused to understand anything other than french
[11:41:31] <kierank> peloverde_: does anyone use mpeg-2 aac with bandwidth extensions?
[11:51:38] <merbanan> there we go
[11:51:44] <merbanan> bugs and wishes
[11:52:37] <kshishkov> var?
[12:22:54] <merbanan> the roundup tracker
[12:25:07] <kshishkov> well, you can do it with inputting file as raw PCM16 and remuxing it into wav
[12:33:33] <elenril> wtf is bytestream_get_le16
[12:34:59] <_av500_> kshishkov: is ffpcmenc still experimental?
[12:35:18] <kshishkov> _av500_: no, it's mature enough even for you to use it
[12:36:05] <elenril> anyone?
[12:36:15] <elenril> i don't see it defined anywhere
[12:36:37] <kshishkov> elenril: it's all in bytestream.h
[12:36:44] <kshishkov> expanded from macros
[12:37:07] <lu_zero> jannau: is there anything I should know about pwclient?
[12:37:12] <kshishkov> it reads 2 bytes from buffer as 16-bit LE integer and adjusts buffer position
[12:37:22] <elenril> ah
[12:37:33] * elenril kicks aurel for using such obscure stuff in lavf
[12:38:17] <kshishkov> elenril: it's rather obvious and useful too
[12:40:43] <jannau> lu_zero: it's a command line client for patchwork
[12:40:58] <lu_zero> yup
[12:41:09] <lu_zero> I wanted to know more =)
[12:41:30] <kierank> [12:33] elenril: wtf is bytestream_get_le16 --> is it not rather self-explanatory ;)
[12:42:03] <elenril> the side effects aren't =p
[12:42:12] <jannau> lu_zero: http://patchwork.libav.org/help/pwclient/
[12:43:16] <jannau> can be used to list, view and download patches from patchwork
[12:44:08] <kierank> elenril: is aurel not worthy of a stab
[12:44:48] <elenril> :eff:
[12:45:03] <jannau> makes it easier to use in your git repo
[12:45:12] * kierank stabs elenril
[12:45:17] <_av500_> +1
[12:46:15] * kshishkov prescripts Ceasar's pill to elenril
[12:46:41] <_av500_> ceasar was on the pill?
[12:46:58] <_av500_> i thought he used the calender method...
[12:47:09] <lu_zero> jannau: could you send me the proper rc ^^;
[12:47:25] * elenril wonders what evil person wrote mov chapter code
[12:47:30] <kshishkov> _av500_: he took 22 stabs to cure him of being dictator
[12:48:20] <elenril> ah, Yuvi
[12:48:31] <elenril> how fitting for an apple minion
[12:49:59] <jannau> lu_zero: http://patchwork.libav.org/project/FFmpeg-devel/pwclientrc/
[12:51:03] * mru adds a .caesar section to elenril's elf files
[12:51:39] <mru> jannau: patchwork still shows mostly applied patches
[12:52:09] <elenril> morning our glorious BDFL
[12:55:53] <jannau> mru: untrue, I've closed > 50%. it doesn't catch svn commits and doesn't supercede patches automatically if a new version is send
[12:56:17] <mru> most of the patches listed have been applied in some form or other
[12:56:29] <mru> even though you've cleaned out many
[12:57:11] <jannau> I'm inclined to close all before 2011-01-21
[12:57:46] <lu_zero> it might be worth an announce
[12:57:46] <jannau> the other form is the problem
[12:58:18] <jannau> sure, I wanted to test it first
[13:00:24] * elenril wonders if it's just him, or mov_read_chapters really leaks like crazy
[13:00:45] <mru> a lot about mov is crazy
[13:02:47] <mru> jannau: feel free to discard old stuff
[13:03:19] <mru> I'd rather have it incomplete and usable than have it cluttered by already applied or rejected patches
[13:03:31] <mru> btw, how does are rejected patches handled?
[13:06:53] <_av500_> burned at a stake?
[13:07:05] <CIA-29> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rdb2ddd3885 ffmpeg/ffplay.c:
[13:07:05] <CIA-29> ffmpeg: Remove outdated and confusing comment.
[13:07:05] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:16:28] <elenril> what would be the best way do le/be variants of put/get_str16?
[13:16:43] <elenril> with a macro?
[13:16:49] <mru> with magic
[13:18:37] * elenril casts magic missile at mru 
[13:18:58] <microchip_> you a wizard?
[13:19:33] <kshishkov> elenril: you just don't know how "to do magic" sounds in mru's native language
[13:19:52] <mru> "trolla"
[13:20:14] <mru> so who better then elenril to do it?
[13:20:48] <kshishkov> C-E Hoyos
[14:31:57] <BBB> mru: nwlines are good now
[14:31:59] <BBB> thnks
[14:35:55] <elenril> http://tech.slashdot.org/story/11/01/22/130201/Google-Submits-VP8-Draft-To-the-IETF
[14:47:02] <mru> BBB: how can you see them? there are no errors now
[14:48:53] <elenril> kshishkov: i knew it!
[14:49:11] <kshishkov> elenril: knew what?
[14:49:18] <mru> *it*
[14:49:24] <elenril> you lied!
[14:49:34] <mru> but now av500 knows *it*
[14:50:07] <elenril> pross-au: how come your get_utf16z function doesn't call GET_UTF16/PUT_UTF8
[14:50:08] <kshishkov> elenril: not(iKnow(iT))
[14:50:48] <kshishkov> pross-au: how come there's no bink-b support patch from you?
[14:51:24] <CIA-29> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r10ed96c78f ffmpeg/doc/demuxers.texi:
[14:51:24] <CIA-29> ffmpeg: Amend documentation for the image2 demuxer, to better reflect the current behavior.
[14:51:24] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:54:11] <pross-au> keep the how comes coming please
[14:54:36] * elenril would prefer some answers
[14:54:39] <pross-au> elenril: i will rename it to get_unicodez
[14:54:46] * jannau curses mru
[14:54:53] <elenril> that doesn' really answer my question
[14:54:53] <mru> why?
[14:54:55] <kshishkov> pross-au: how come there's no cutscenes support in opensource Z engine reimplementation?
[14:55:28] <pross-au> kshishkov: somebody is rewriting Z?
[14:55:37] <mru> jannau: what did I do?
[14:55:38] <CIA-29> ffmpeg: Alex Converse <alex.converse at gmail.com> master * r8ae0fa243e ffmpeg/libavcodec/aacenc.c:
[14:55:38] <CIA-29> ffmpeg: aacenc: mark SBR absent
[14:55:38] <CIA-29> ffmpeg: Use backwards compatible explicit signalling to denote the absence of
[14:55:38] <CIA-29> ffmpeg: SBR.
[14:55:38] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[14:55:40] <elenril> pross-au: the data is guaranteed to be ascii?
[14:56:12] <jannau> mru: you pushed stefano's patch
[14:56:19] <mru> someone approved it
[14:56:25] <mru> and it didn't look too bad
[14:56:27] <pross-au> elenril: all my samples contain unicode
[14:56:44] <jannau> just before I was going to push it
[14:56:46] <elenril> pross-au: then how is it supposed to work?
[14:56:59] <mru> jannau: git should handle that just fine
[14:57:19] <jannau> git am didn't
[14:57:27] <mru> git am -3
[14:58:01] * jannau wonders why patchwork didn't catched the commit
[14:58:09] <pross-au> elenril: let me get back to you on that..
[14:58:16] <elenril> pross-au: i mean you're writing uint_16's into chars
[14:58:25] <mru> remote: remote: I: patch #449 updated using rev db2ddd38859b26c0a4e4bf92619625cd7e0e7f42.
[14:58:29] <mru> remote: remote: E: failed to find patch for rev 10ed96c78fde80da9d5bac9b267369861a4f33ba.
[14:58:44] <jannau> I blame the attachment
[14:58:55] * elenril thinks somebody should just write a common 'read an utf16 string and convert it to utf8' function
[15:00:09] * kierank thinks utf-* is a waste of time
[15:00:26] <mru> kierank: good luck converting the world to 7-bit ascii
[15:00:30] <kierank> have we seen the return of __troll__ yet?
[15:00:45] * elenril feeds the _troll_ 
[15:00:59] <kierank> BBB tried to replace you _troll_ for a while
[15:01:10] <kierank> but he wasn't very good
[15:01:27] <elenril> av500 tried too, with somewhat greater success
[15:01:37] <_troll_> there's no such thing as a dutch troll
[15:01:39] <kierank> but av500 didn't use the nick
[15:01:49] <kierank> BBB actually changed his nick to troll
[15:01:49] <_troll_> he can't, it belongs to me
[15:02:07] <kierank> he used __troll__ I think
[15:02:10] <kierank> or something like that
[15:02:24] * _troll_ needs to register more nicks
[15:03:32] <BBB> I used _troll_, and then nickserv changed me to something else because it was taken
[15:03:39] <BBB> btw, I think I found the h264 bug on roundup
[15:03:43] <BBB> still working out a proper fix
[15:03:46] <_troll_> "the"?
[15:03:52] <BBB> but at least I'm starting to truly get the internals of the code
[15:03:56] <BBB> one of the?
[15:04:01] <kierank> fix the mbaff bug kthx
[15:04:04] <kshishkov> _troll_: you should use __troll_t
[15:04:06] <BBB> #2393 is the one I'm working on right now
[15:04:24] <_troll_> kshishkov: that is reserved for the implementation
[15:04:31] <_troll_> oh right, I am the implementation
[15:04:58] <kshishkov> compliant one too
[15:05:36] <_troll_> is there an international standard for troll?
[15:05:50] <kierank> iso-3489238423432
[15:05:58] <kierank> except its impossible to find
[15:06:18] <_troll_> kshishkov: btw, we've stopped being totally anal about indentation patches
[15:07:19] <kshishkov> _troll_: iKnow but I'm still adapting
[15:07:25] <_troll_> use common sense
[15:07:41] <_troll_> sometimes it is of course easier to see what's going on if cosmetics are done afterwards
[15:09:08] <j-b> kshishkov: thanks. Will this wv 5.1 work with external demuxers or just lavf ones?
[15:10:13] <kshishkov> j-b: depends. MKV should work fine, WV demuxer should follow packet format from lavf
[15:10:54] <j-b> kshishkov: we don't have a WV demuxer, we use lavf for that.
[15:11:24] <kshishkov> j-b: keep on that
[15:11:26] <j-b> kshishkov: I will try... THis is _really_ cool
[15:12:01] * _troll_ has never seen a wavpack file in the wild, fails to feel the cool
[15:12:44] <kshishkov> _troll_: you just download your music from different source
[15:12:52] <_troll_> my music is in flac
[15:13:01] <kshishkov> exactly
[15:13:02] * j-b has received a fucking lot of request for 5.1 wv support
[15:13:11] <_troll_> j-b: if you say so
[15:13:14] <j-b> this is probably the #2 request for audio
[15:13:16] <kshishkov> j-b: me too - one request
[15:13:21] <_troll_> is it a regional thing?
[15:13:25] <j-b> _troll_: possibly
[15:13:34] <_troll_> like rv being *the* codec in china
[15:13:41] <j-b> _troll_: and remember: my users are possibly stoopid and clueless
[15:13:41] <kshishkov> j-b: if #1 is TAK go kill yourself
[15:13:49] <j-b> kshishkov: #1 is AAC encoder
[15:14:04] <j-b> #1 was amr, but this is solved now
[15:14:17] <_troll_> kshishkov: can't you troll ivan into fixing ffaacenc?
[15:14:28] <elenril> j-b: and kshishkov is to be blamed for both
[15:14:31] <kshishkov> _troll_: nope :(
[15:14:32] <elenril> coincidence?
[15:14:33] <_troll_> ivan dimkovic, that is
[15:15:08] <_troll_> kshishkov: tried?
[15:15:31] <j-b> well, faac was kind of ok
[15:15:43] <kshishkov> _troll_: no, but he's not that interested in AAC these days :(
[15:15:57] <_troll_> but he knows a lot about it
[15:16:15] <_troll_> lack of interest -> need for trolling
[15:17:07] <j-b> but, yes, wv5.1 was requested quite a bit
[15:17:41] <j-b> video is more MSS2, G2M3, vc-1 inter, some rv*
[15:17:46] <kshishkov> _troll_: maybe try your disciple first - they are of the same nationality and he has better trolling skills
[15:18:09] <kshishkov> j-b: some rv*?
[15:18:31] <j-b> kshishkov: it would seems some rv40 don't play correctly
[15:18:43] <j-b> kshishkov: but I haven't investigated, since it could be the demuxer
[15:19:21] <kshishkov> if you don't use lavf the warranty is off
[15:19:32] <kshishkov> but it's also void with lavf RM demuxer
[15:19:50] <j-b> vlc rm demuxer is crap
[15:20:02] <j-b> lavf rm demuxer is ...
[15:20:03] <kshishkov> lavf one is too
[15:20:27] <j-b> mplayer rm demuxer is kind of better, but messy, IIRC
[15:20:33] <kshishkov> maybe you should reuse the one from FFmBC - written by Frenchman even
[15:20:41] <j-b> FFmBC ?
[15:20:53] <j-b> I could, maybe
[15:21:00] <spaam> SRTP  is that some kind encrypted version of RTP ?
[15:21:17] <kshishkov> j-b: http://code.google.com/p/ffmbc
[15:21:34] <j-b> kshishkov: oh, I thought it only cared about mxf or gxf
[15:21:46] <kshishkov> j-b: it's fork by Baptiste Coudurier though he's too modest and calls it "FFmbc"
[15:21:46] <j-b> spaam: yes,
[15:21:58] <j-b> too modest?
[15:22:38] <kshishkov> I hope that's not an insult for French
[15:22:42] <j-b> this doesn't fit with "French" :)
[15:22:47] <j-b> rofl
[15:23:07] <j-b> kshishkov: so he has a newer rm demuxer?
[15:23:40] <kshishkov> yep, either written from scratch or modified from MOV demuxer
[15:26:38] <BBB> hah, I think I've got 2393 fixed
[15:26:47] <j-b> modified from mov? O_o
[15:26:52] * j-b needs to read doc then
[15:27:02] <BBB> _troll_: what's your opinion on adding roundup samples to fate once they're fixed?
[15:27:22] <_troll_> BBB: depends on what the problem was of course
[15:27:34] <kshishkov> j-b: well, its style reminded me of MOV demuxer immediately
[15:27:45] <BBB> resolution change in h264 caused a crash, apparently that's legal but no ref sample tests it
[15:27:51] <BBB> so of course it broke
[15:27:51] <_troll_> mindlessly creating a test case exactly matching each fix bug is stupid
[15:28:01] <j-b> kshishkov: why didn't he port it to "classical FFmpeg" ?
[15:28:29] <BBB> _troll_: and re: newlines, I can see the newlines for the failing fate tests also
[15:28:31] <kshishkov> j-b: 1) it's totally new and needs to replace old one 2) he didn't care much (I think)
[15:28:48] <_troll_> BBB: but there are no build failures currently
[15:28:49] <j-b> ok, makes sense
[15:29:34] <BBB> _troll_: true, but I assume that if newlines work for fate tests triangles, it'll work for build failure triangles also, no?
[15:29:43] <_troll_> no
[15:29:47] <BBB> oh
[15:29:48] <_troll_> totally different html
[15:29:51] <BBB> let me break the build
[15:29:56] <_troll_> :)
[15:30:24] <_troll_> the failed test listings use tables
[15:30:42] <BBB> ah, I see
[15:31:32] <_troll_> but I think I fixed the problem you saw
[15:31:37] <_troll_> we'll know next time a build fails
[15:31:41] <_troll_> it'll happen eventually
[15:32:05] <_troll_> actually, I might have some hidden slots with a failure
[15:32:16] <BBB> yeah
[15:32:16] <BBB> win32
[15:32:50] <_troll_> there, try now
[15:33:03] <BBB> yes works
[15:33:09] <BBB> very pretty :)
[15:33:17] <_troll_> ok, hidden again
[15:33:28] <BBB> ty
[15:33:39] <kshishkov> BBB: that's because mru had never thought of being Web designer for living
[15:33:49] <BBB> I emailed ramiro... he won't be back soon but he'll be at fosdem so you guys can get him drunk and rehypnotize him
[15:34:04] <_troll_> BBB: now there's a plan
[15:34:23] <BBB> \o/
[15:34:40] * BBB needs to resume working on the emu_edge patch
[15:35:00] <BBB> I think the problem was that the jumptable for size-specific copies didn't make it any faster, which of course sucks major ass
[15:35:08] <BBB> maybe I should do it in yasm after all...
[15:35:14] <j-b> BBB: btw, do you have any idea why projects like VLC use emu_edge?
[15:35:27] <BBB> j-b: I may be wrong here, but...
[15:35:38] <BBB> j-b: aren't some people in this channel involved in such projects?
[15:35:42] <BBB> j-b: like, maybe, ...
[15:35:44] <BBB> j-b: you?
[15:35:51] <BBB> j-b: you should be telling me dude ;)
[15:36:24] <j-b> BBB: do you actually think I know why decisions done 4 years before I join the dying project were made?
[15:36:35] <kshishkov> j-b: because you copied it from MPlayer!
[15:36:37] <BBB> good point :)
[15:36:50] <j-b> kshishkov: MPlayer use emu_edge too ?
[15:37:11] <mru> some retarded output devices don't allow stride != width
[15:37:19] <j-b> BBB: mru hinted we could do Direct Rendering without emu_edge
[15:37:20] <BBB> I believe that some versions of X RGB output had fixed alignment of 4 bytes
[15:37:23] <BBB> regardless of pixelformat
[15:37:26] <kshishkov> j-b: ask BBB but I think VP* had some problems because of it there too
[15:37:34] <BBB> and so everyone just defaulte dto always emuedge
[15:37:45] <BBB> but I don't really know
[15:37:54] <j-b> kshishkov: yes, we deactivated emu_edge on ffVP8 until 52.101.1 where it was fixed
[15:37:58] <mru> xv output easily allows padding
[15:38:02] <BBB> j-b: I don't think it matters much that you use it, it makes stuff like 0.5% slower, but not much
[15:38:05] <BBB> mru: I meant X RGB, not xv
[15:38:11] <mru> same there
[15:38:21] <BBB> well that's all I remember ;) I may be plain wrong
[15:38:34] <BBB> gst used emu_edge too at that point
[15:38:48] <mru> XPutImage (and its shm brother) take a sub-region as argument
[15:38:48] <BBB> it may just be that we did it b/c mplayer did and that was the only sample code of how to use ffmpeg at that point
[15:39:25] <BBB> our approach was "copy whatever mplayer does, that's the best chance that it won't break every other day, because at least the devs get shouted at by others than us if it breaks in mplayer"
[15:39:54] <BBB> any other bugs? going once, going twice, or I go to submitting emu_edge again
[15:40:30] <mru> how times have changed
[15:41:13] <kshishkov> mru: they change every <quantum of time>
[15:41:28] <mru> is there a time particle?
[15:41:37] <kshishkov> tachion
[15:41:45] <mru> or is it chroniton?
[15:41:53] <mru> star trek writers can't seem to make up their minds
[15:42:02] <j-b> BBB: lavc in vlc dates from before 2002, it seems
[15:42:16] <mru> the dark ages
[15:42:28] <j-b>  #if LIBAVCODEC_BUILD >= 4615
[15:42:34] <kshishkov> mru: wake me when we have dilithium-ion batteries
[15:43:12] <mru> nevermind the warp core, I want to know what powers those phasers
[15:44:04] <BBB> \o/ I can send multiple emails now
[15:44:04] <mru> and I'd also like to know how firing one can completely vapourise an object without damaging the table it was sitting on
[15:44:07] <BBB> awe some
[15:44:24] <BBB> gotta work on git am next
[15:44:45] <j-b> git obscurity
[15:44:55] <kshishkov> mru: you're too picky
[15:45:06] <mru> git: 'obscurity' is not a git command. See 'git --help'.
[15:45:40] <kshishkov> git obliviate
[15:45:53] * mru has a git assimilate command
[15:46:07] <kshishkov> git fix-it-for-me --really
[15:46:36] <mru> it's just a shorthand for merge; branch -d
[15:46:56] <mru> useful for pushing things around between non-bare repos
[16:13:03] * mru would like to push the h264enc removal patch
[16:13:15] <kshishkov> what blocks it?
[16:13:25] <kierank> nothing
[16:13:51] * kshishkov would also like mru to push lib*core removal patch
[16:14:09] <kierank> replace it with libavsequencer
[16:14:24] <kierank> most important patch ever
[16:14:46] <spaam> <3
[16:15:02] <kshishkov> not as important as Amiga asm speedup for it
[16:15:05] <spaam> kierank: then mru can join the CDBG crew
[16:15:15] <kierank> spaam: CDGS
[16:15:21] <kierank> get it right
[16:15:22] <spaam> ah so it was.
[16:15:27] <spaam> im sorry
[16:15:35] * kierank allows spaam back into CDGS
[16:15:58] <spaam> \o/
[16:16:16] <spaam> kshishkov: when will you join the CDGS crew? :D
[16:16:20] <kshishkov> now write asm 68k asm
[16:16:25] <CIA-29> ffmpeg: Alex Converse <alex.converse at gmail.com> master * rff3d43104f ffmpeg/libavcodec/ (Makefile h264.c h264dspenc.c h264enc.c):
[16:16:25] <CIA-29> ffmpeg: Remove H.264 encoder fragments
[16:16:25] <CIA-29> ffmpeg: It's incomplete, no one is working on it, and when someone asks about
[16:16:25] <CIA-29> ffmpeg: working on it we advise them not to.
[16:16:25] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:16:51] <spaam> rip ffh264enc
[16:16:57] <kshishkov> spaam: when they start making decent Trocadero in Germany
[16:17:02] <mru> jannau: why does pw tell me "2 patch(es) updated to state Accepted"?
[16:17:24] <mru> the other being the aacsbr thing you applied a few hours ago
[16:17:26] <spaam> kshishkov: :)
[16:18:11] <kierank> we should have an #ffmpeg-devel skype too
[16:18:29] <kshishkov> kierank: support at least iLBC first!
[16:18:36] <spaam> kshishkov: after you join the CDGS crew. we can fix bink-b in avsequencer
[16:18:58] * kierank reads about iLBC
[16:20:21] <kshishkov> spaam: port AdPlug-supported formats into lavseq first
[16:20:39] <spaam> kshishkov: why? :)
[16:21:43] <kshishkov> spaam: it's logical and would make me interested :-|
[16:21:51] <kierank> for anyone who knows about dvb subtitles: so the point of the dds segment is to make them not look large on HDTV channels because they were lazy when creating the first spec?
[16:23:36] <jannau> mru: delicious session cookie noticed that you last visited before I pushed the aacsbr patch? just guessing
[16:24:06] <mru> cookies in git? I don't think so...
[16:24:19] <mru> it printed that from git push
[16:24:19] <jannau> web browser
[16:24:22] <BBB> actually
[16:24:29] <BBB> kshishkov: removing libavcore is on my list also
[16:24:36] <BBB> (i.e. merging it back with libavutil)
[16:24:41] <BBB> I'd like opinions...
[16:24:46] * elenril disagrees
[16:24:57] <kshishkov> BBB: my opinion is "HELL YES!!"
[16:25:23] <spaam> Why did libavcore split out from libavutil in the first place?
[16:25:28] <jannau> ah, I think there's an error in hook it sends old^..new to patchwork
[16:25:28] <mru> spaam: michael
[16:25:45] <spaam> mru: what was the reason?
[16:25:54] <elenril> spaam: michael maintained illusions about people using libavutil standalone
[16:25:57] <BBB> it wasn't generic enough for libavutil
[16:25:59] <BBB> or so
[16:26:07] <BBB> but too specific for libavcodec
[16:26:11] <kshishkov> though it may be more reasonable to split them into libavutil, libavcore, libavkernel, libavstuff, libavcommon, libavreused and libavsomebits
[16:26:31] <kierank> I used libavcore for something
[16:26:47] <BBB> libavsequencer
[16:26:49] <BBB> libavgcc
[16:26:56] <jannau> if we are going to remove libavcore we should do it fast
[16:26:57] <kshishkov> kierank: we all make mistakes sometimes
[16:26:57] <spaam> BBB elenril : ok :)
[16:26:58] <BBB> kierank: you can now use libavutil then
[16:27:08] <spaam> jannau: why?
[16:27:09] <elenril> BBB: what's the point in merging it anyway
[16:27:19] <kierank> kshishkov: I was too lazy to write channel mapping defines
[16:27:22] <BBB> elenril: I think that 20 shlibs is not very useful
[16:27:30] <kshishkov> spaam: because it's reasonable
[16:27:33] <jannau> removing it causes trouble for downstream projects
[16:27:42] <kshishkov> spaam: and no Michael will prevent us
[16:27:44] <elenril> other than breaking api, breaking compatibility with TheOtherFFmpeg etc
[16:27:44] <BBB> jannau: like deb?
[16:28:05] <BBB> let's not do it for now
[16:28:09] <elenril> at the very least i'd wait
[16:28:09] <saste> there was a reason for libavcore
[16:28:11] <jannau> especially should remove it before we release 0.7
[16:28:11] <BBB> but keep it in mind for next time we break abi/api anyway
[16:28:15] <BBB> saste: hi :)
[16:28:27] <saste> it is even written in the commit log
[16:28:40] <jannau> BBB: like mythtv, mplayer, vlc, ...
[16:28:41] <saste> someone may want to use libavutil in a non-multimedia app
[16:28:51] <BBB> saste: ffmpeg is not non-multimedia
[16:28:52] <mru> lol
[16:28:57] <BBB> avutil is in ffmpeg
[16:28:59] <mru> nobody has ever done that
[16:29:05] <BBB> therefore, noone would ever use avutil unless in a multimedia app
[16:29:23] <saste> yes but who may know?
[16:29:27] <BBB> they'd probably just pick the pieces they need and built it in their binary directly instead of linking
[16:29:34] <kshishkov> saste: ever though about what "av" in "libav*" stands for?
[16:29:44] <jannau> saste: I don't expect libavutil to grow huge, i.e. if they need something from it, they can still use it
[16:30:16] <saste> note that i was quite indifferent to the two options
[16:30:32] <saste> but I didn't think that having a separate lib was necessarily evil
[16:30:36] <j-b> 17:25 < spaam> Why did libavcore split out from libavutil in the first place?
[16:30:43] <j-b> I had the same question
[16:30:48] <saste> now if you remove libavcore you're breaking many apps
[16:30:57] <saste> it's explained in the commit log!!
[16:31:12] <saste> there is a link to the discussion on ffmpeg-devel iirc
[16:31:13] <mru> I agree it's not nice to break apps
[16:31:30] <mru> but the only reason it was done was because michael was kicking and screaming
[16:31:42] <spaam> j-b: http://git.ffmpeg.org/?p=ffmpeg.git;a=commit;h=aac6ca6978306bf0f0254bab8a608648014ed3e5 teh commit
[16:32:42] <kshishkov> mru: I though it was a nice troll though
[16:32:51] <kshishkov> *thought
[16:36:47] <uau> speaking of library organization, what about making the ffmpeg libraries share one major version?
[16:37:33] <uau> the main problem with the current independent changes is that it forces applications to use non-matching versions (if they use a previous major version of one lib)
[16:38:11] <uau> the downside of changing that would of course be more major version changes, but they've been rare enough that unless updates become more frequent i don't think that is a big problem
[16:38:53] <BBB> saste: I remember most devs being against avcore when it came up, but nobody cared enough to fight it (me included)
[16:39:07] <BBB> saste: let's not break apps now, but let's keep this in mine for when we bump abi/api for some other reason
[16:39:10] <BBB> saste: i.e. 0.7
[16:39:11] <kshishkov> good idea, especially if somebody cleans headers out of all those #ifdef VERSION_x < y stuff
[16:39:25] <BBB> I thought reimar was doing that
[16:39:25] <elenril> yeah, let's bump major
[16:39:35] <BBB> not now
[16:39:35] <BBB> later
[16:39:37] <saste> BBB: I was mildly in favor of having it, and still am...
[16:39:39] <elenril> after mt
[16:39:44] <saste> think if you want to add DSP to libavcore
[16:39:47] <BBB> after mt yes
[16:40:05] <BBB> dsp for what?
[16:40:12] <saste> many apps may need to use it without libavcodec
[16:40:15] <BBB> avutil can have dsp also
[16:40:15] * elenril wonders if mt will get merged before DNF
[16:40:17] <saste> or fft
[16:40:25] <BBB> saste: all that can be moved to avutil
[16:40:29] <saste> but then you're blowing lavu too much
[16:40:33] <kshishkov> BBB: so you can do accelerated DCT in some demuxer
[16:40:34] <BBB> are you?
[16:40:48] <BBB> kshishkov: I think he's thinking of sharing stuff between avcodec and avfilter
[16:40:53] <saste> I recognize that this is useful only if you want to use avutil in a non multimedia app
[16:41:09] <saste> that's not likely but it's not impossible... i see the point of michael...
[16:41:12] <kshishkov> BBB: we may have separate libavdsp then
[16:42:42] <BBB> no no not before avsequencer
[16:42:58] <BBB> saste: my vision is generally to not care until it happens
[16:43:03] <mru> I can see a point to separating core stuff from specific codecs
[16:43:09] <saste> BBB: DSP may be useful in many filtering application for example, togheter with FFT
[16:43:10] <mru> but there are performance penalties for that
[16:43:20] <BBB> saste: should we prepare for the world to go down in flames in 2012, just because some idiot in a sect says so?
[16:43:31] <BBB> saste: I totally agree filters should use DSP
[16:43:40] <BBB> saste: but imo DSP in avutil is fine
[16:43:44] <saste> BBB: no I respect the will of the majority
[16:43:57] <saste> I don't think that I alone or someone else should decide for everyone
[16:44:23] <saste> so most devs want that... but I want to show which are the technical points for keeping the current layout
[16:44:32] <BBB> ok
[16:44:44] <saste> and I know that many libs are more difficult to manage than few
[16:44:45] <BBB> Dark_Shikari: please review my h264 patches again :-p
[16:44:55] <saste> but in general they allow you more flexibility
[16:46:05] <mru> let's not make any huge changes just now
[16:46:13] <mru> wait until the new order of things has settled in
[16:46:21] <saste> yes and please discuss on the ML
[16:46:28] <mru> of course
[16:46:33] <saste> nobody can stay logged on irc 24/24
[16:46:40] <mru> I can
[16:46:43] <mru> well, 24/7
[16:46:51] <saste> you're not human ;-)
[16:46:53] <kshishkov> trollbot can too
[16:47:07] <mru> my irssi has been running continously for ~20 months now
[16:47:08] <BBB> saste: we'll discuss, any change goes to ML before anything
[16:47:11] <kshishkov> saste: logged != reading that stuff
[16:54:29] <mru> uau: mind taking a look at http://patchwork.libav.org/patch/410/ ?
[16:56:06] <BBB> is that fully automated?
[16:56:10] <BBB> that is kind of awesome
[17:01:40] <jannau> patchwork announcement email sent
[17:01:44] <lu_zero> yawn...
[17:01:50] * lu_zero is feverish
[17:01:54] <lu_zero> damn
[17:02:27] <jannau> BBB: unfortunately not fully automated
[17:02:48] <lu_zero> BBB: there is as least a change from this month breaking h264 decoding
[17:02:52] <lu_zero> (noticed yesterday)
[17:05:21] <j-b> lu_zero: 24/12 and following days
[17:06:47] <BBB> lu_zero: testcase?
[17:06:55] <uau> mru: no specific comments, seems to be about what i suggested earlier
[17:07:09] <BBB> lu_zero: I'll try to fix as much as I can
[17:07:35] <mru> uau: yes, that was the idea
[17:08:04] <BBB> I think patch looks ok, I have no strong opinion on it
[17:10:14] <lu_zero> BBB: let me dig
[17:10:19] <BBB> thnks
[17:10:24] <lu_zero> j-b: if you have one please send him ^^;
[17:10:37] <BBB> regarding swscale 7/7, why do we keep templating the C functions in altivec?
[17:10:40] * lu_zero is really feeling worse now
[17:10:55] <lu_zero> BBB: one step at time ^^
[17:10:58] <BBB> so my view of the ppc/ dir is that it's basically a bunch of implementations, most counterparts of C, others are calling altivec_real impls
[17:11:13] <BBB> will that be fixed to not be c copies and not wrap altivec_real but just be altivec_real for the ones implemented as such?
[17:11:17] <lu_zero> step 8 would be make the C code completely unteplated
[17:11:20] <BBB> (I don't want to whine)
[17:11:31] <lu_zero> step 9 would fix ppc since is the easiest
[17:11:35] <lu_zero> step 10...
[17:11:43] <lu_zero> I'll need your and Dark_Shikari help.
[17:14:13] <jannau> mru: http://patchwork.libav.org/patch/410/ is ok
[17:14:56] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r96aad41e81 ffmpeg/libavcodec/dsputil.h:
[17:14:56] <CIA-29> ffmpeg: Make LOCAL_ALIGNED macro fully C99 compatible
[17:14:56] <CIA-29> ffmpeg: C99 variadic macros require more arguments than there are named
[17:14:56] <CIA-29> ffmpeg: parameters in the definition. This means we must use an extra
[17:14:56] <CIA-29> ffmpeg: indirection to avoid having two different macros for arrays with
[17:14:57] <CIA-29> ffmpeg: one resp more than one dimension.
[17:14:57] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:16:23] <lu_zero> (and that is something I wanted to do today...)
[17:24:15] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rfcb7e535dd ffmpeg/libavcodec/h264.c:
[17:24:15] <CIA-29> ffmpeg: Reindent.
[17:24:15] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[17:24:28] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r9107892624 ffmpeg/libavcodec/h264.c:
[17:24:28] <CIA-29> ffmpeg: Fix crash on resolution change (issue 2393).
[17:24:28] <CIA-29> ffmpeg: Don't free RBSP tables (containing decoded NAL units) on resolution
[17:24:28] <CIA-29> ffmpeg: change, because we actually need this data to decode the frame after
[17:24:28] <CIA-29> ffmpeg: reiniting (with new resolution). Fixed issue 2393.
[17:24:28] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[17:29:52] * mru bugs jannau for a promotion to maintainer in patchwork
[17:35:12] <BBB> lu_zero: I'll help with whatever it is
[17:35:17] <BBB> lu_zero: I assume you mean writing optimizations?
[17:35:21] <BBB> I don't mind writing a couple
[17:37:25] <lu_zero> BBB: =)
[17:37:46] <lyakh> I'm sure someone is about to finish bayer support for the rawvideo decoder?...;)
[17:38:03] <mru> lyakh: patches welcome
[17:38:03] <BBB> I don't even know what bayer is
[17:38:13] <mru> BBB: what digital cameras use
[17:38:30] <mru> each pixel contains only one colour component
[17:38:40] <mru> 1/2 green, 1/4 each red and blue
[17:38:52] <lyakh> hm, I've done it a couple of times - for mplayer and gstreamer, none of those has been accepted in the mainline...
[17:39:06] <lyakh> ok, not quite true
[17:39:07] <mru> to get a proper rgb image you need to interpolate the components
[17:39:08] <kierank> "mplayer and gstreamer" ---> there's your problem
[17:39:13] <lyakh> gstreamer has it already
[17:39:23] <lyakh> I just tried to fix its bugs...
[17:40:14] <lyakh> and in mplayer I've done it as a video-filter, they said, it was a wrong way to do it and a wrong place, and basically have sent me to ffmpeg...
[17:40:31] <mru> I guess swscale would be the natural place
[17:40:39] <mru> so help lu_zero clean it up
[17:41:32] <lyakh> that's exactly the problem - it's easy to program, but it's difficult to do it to fit respective project's understanding where and how it has to be done...
[17:43:34] <lyakh> not the rawvideo-decoder?
[17:46:52] <ruggles> lyakh: it's just another pixel format type. the decoders should output whatever format the source is in. then swscale could convert if needed.
[17:48:08] <lyakh> but what part normally does all the conversions - encoders?
[17:48:37] <mru> the converters
[17:49:54] <ruggles> usually the raw camera image is ljpeg in some tiff variant, not pure raw pixels. and also often double width/half height so the ljpeg prediction is better. decoders would handle all that. but converting to a normal rgb image or whatever would be swscale.
[17:51:38] <lyakh> ruggles: jpeg is not very "usual" for raw camera sensors
[17:52:53] <ruggles> but most of the cameras store it in whatever proprietary raw image format the company uses. and many of them are a tiff variant with ljpeg compression.
[17:52:59] <lyakh> and how is conversion normally handled in ffmpeg? you don't define a converter for each possible pair, right? so, you first decode the source format to some common one, and then encode to the target? so, a decoder, an encoder and something to match them should be used?
[17:54:00] <mru> there are direct converters between common pairs
[17:54:04] <mru> others use an intermediate format
[17:54:27] <mru> converting bayer to rgb would be natural
[17:54:35] <lyakh> ruggles: you're talking about USB cameras, I'm talking about camera (CMOS) sensors - just a sensor itself with some minimum logic to crop it, bin / skip pixels, adjust gain, exposure, etc.
[17:55:12] <mru> ruggles: many usb cameras output raw bayer data
[17:55:26] <mru> that's why people are complaining in the first place
[17:55:42] <lyakh> mru: and that would be called a converter, not a decoder? or just integrated into swscaler?...
[17:58:04] <ruggles> lyakh: i was talking about consumer-grade DSLR cameras. if you're just grabbing it from a sensor, i guess the raw video decoder would handle that. but not the conversion to something other than bayer.
[17:58:43] <mru> ruggles: consumer-grade still cameras generally save jpeg and do all conversions using their own secret algorithms
[17:59:04] <mru> ruggles: most DSLRs have an option of raw images too, however
[17:59:13] <mru> and these are just that, raw bayer data from the sensor
[17:59:37] <mru> this gives maximum control during processing
[17:59:59] <ruggles> the raw images are still losslessly compressed and wrapped in something tiff-ish.
[18:00:00] <mru> you do everything manually: debayer, white balance, gamma etc
[18:00:09] <lu_zero> ruggles: yes
[18:00:11] <mru> ruggles: depends on camera model
[18:00:19] <mru> they tend to use some compression, yes
[18:00:29] <mru> and they often use a tiff container but that's not a given
[18:00:34] <lu_zero> mru: canon and nikon should do that
[18:00:35] <ruggles> not all.
[18:00:38] <mru> nor does it matter for this discussion
[18:00:39] <ruggles> but most.
[18:01:32] <ruggles> no, either way you decode raw or you decode something compressed and end up with a bayer image, which still has to be converted to enjoy it.
[18:02:01] <mru> compressed or not is irrelevant
[18:02:14] <mru> bayer comes out of it, whatever file format was used
[18:02:20] <ruggles> yes
[18:02:50] <ruggles> but that's another reason why NOT to do conversion in a specific decoder.
[18:02:58] <mru> of course
[18:03:21] <mru> the camera files often do contain useful hints for the conversion though
[18:03:32] <ruggles> lol
[18:03:39] <mru> what's funny?
[18:03:40] <ruggles> buried in layers of crap
[18:03:50] <mru> some of it is plain old exif
[18:04:00] <mru> and some is proprietary
[18:04:06] <mru> but useful nonetheless
[18:04:19] <mru> things like white balance settings
[18:04:20] <ruggles> some of it is, but a lot of useful parts are proprietary.
[18:04:50] <mru> the point I'm trying to make is that there should be a way to feed this information to following stages
[18:04:59] <ruggles> i agree completely
[18:05:08] <mru> if the photographer had already set up white balance for instance, you'll want to use those settings
[18:06:43] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r6eabb0d3ad ffmpeg/libavcodec/ (13 files in 4 dirs):
[18:06:43] <CIA-29> ffmpeg: Change DSPContext.vector_fmul() from dst=dst*src to dest=src0*src1.
[18:06:43] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:06:45] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r3b924294ea ffmpeg/libavcodec/ (ac3enc.c ac3enc_fixed.c ac3enc_float.c):
[18:06:45] <CIA-29> ffmpeg: ac3enc: use dsputil functions in apply_window()
[18:06:45] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:06:46] <mru> jannau: please set patch 297 to committed
[18:07:01] <ruggles> :) yay
[18:07:10] <mru> ah, looks like I can do it myself
[18:07:11] <ruggles> so i did the neon part right?
[18:07:15] <mru> yes
[18:07:20] <ruggles> sweet
[18:07:27] <spaam> ruggles: gz :)
[18:08:14] <ruggles> ah, i did miss vfp. thanks mru.
[18:08:27] <ruggles> one less thing to spend an afternoon trying to figure out.
[18:22:06] <BBB> mru: can you add emu_edge h264 tests for the frext samples of the reference suite?
[18:22:51] * _av500_ has put kids in front of cartoons in order to read todays backlog...
[18:23:17] <BBB> _av500_: mine is in bouncy chair
[18:23:29] <kierank> make kids read backlog and watch cartoons yourself _av500_
[18:27:40] <kshishkov> kierank: and then he'll bug them about decoding quality and demanding them to fix h.265 decoder
[18:45:57] <cartman> av500: http://cekirdek.pardus.org.tr/~ismail/2.png
[18:47:16] <kshishkov> looks like wrong endianness
[18:47:29] <cartman> kshishkov: or Y component missing?
[18:47:33] <cartman> kshishkov: see the ref.png there
[18:49:54] <mru> looks like wrong component order and rather bad saturation
[18:50:17] <cartman> hmm ok first try ;)
[18:50:24] <cartman> I encoded a png to yuv with ffmpeg
[18:50:34] <cartman> now trying to do yuv->rgb24
[18:51:01] <cartman> I am assuming YUV-YUV-YUV… in the YUV file
[18:51:03] <cartman> is that correct?
[18:51:12] <cartman> each component an unsigned byte
[18:51:14] <kshishkov> depends
[18:51:37] <cartman> kshishkov: depends on the what? :)
[18:52:02] <kshishkov> on encoded YUV output format
[18:52:03] <wbs> cartman: if it's yuv444 packed perhaps, but normally you'd have planar yuv 420
[18:52:21] <cartman> wbs: output is YUV420P I think
[18:53:00] <cartman> ok at least it looks like the ref. png
[18:53:02] <cartman> ;)
[18:53:03] <wbs> cartman: then it's first all the Y components, then all the U components for a subsampled plane, then all the V components for a subsampled plane
[18:53:18] <cartman> wbs: ah
[18:53:33] <wbs> cartman: you really haven't touched these parts before, have you :-)
[18:53:45] <cartman> wbs: for 3-4 days now :D
[18:55:03] <cartman> thankfully you are all helping me to understand
[18:55:17] <wbs> and mocking you a bit along the way, I hope that's ok :-)
[18:55:29] <mru> s/a bit//
[18:55:51] <cartman> wbs: the master troll is back, thats expected
[18:55:52] <cartman> :p
[18:55:56] <wbs> cartman: :-)
[18:56:31] <spaam> cartman: when can we see this stuff for ffplay? :)
[18:56:38] <cartman> spaam: never? :)
[18:56:56] <cartman> hopefully never :D
[18:57:37] <kshishkov> spaam: there's one Swedish guy working on neon yuv2rgb for sws
[18:58:02] <spaam> kshishkov: who? pJok ?
[18:58:09] <cartman> kshishkov: yeah and he is hiding it :P
[18:58:42] <kshishkov> spaam: nej, en man från Norrland
[18:59:21] <spaam> kshishkov: vem kan de vara. merbanan ?
[18:59:31] <kshishkov> spaam: precis
[18:59:31] <cartman> spaam: mru
[18:59:33] <spaam> eller menar du Tjoppen +
[18:59:45] <spaam> kshishkov: okej :)
[18:59:49] * mru is not from norrland
[19:00:10] * cartman mv mru /dev/norrland
[19:00:19] <mru> ENODEV
[19:00:24] <kshishkov> mru: but your part of Sweden is crazy too - Wikipedia says you gave up runes only in 19th century
[19:00:38] <wbs> mru: where are you from then, btw?
[19:00:55] * cartman hugs Wikipedia
[19:01:01] <spaam> wbs: dalarna
[19:01:12] <wbs> ah, thought I remembered something such
[19:02:21] <lu_zero> runes are nice
[19:02:37] <BBB> speaking of swedes
[19:02:45] <BBB> I saw the girl with the dragon tattoo yesterday
[19:02:53] <mru> kshishkov: that's a lie
[19:02:57] <BBB> gives a weird picture of swedes
[19:02:59] <kshishkov> BBB: you're married
[19:03:08] <mru> BBB: stieg larsson does that
[19:03:14] <kshishkov> mru: do you still use them?
[19:03:17] <BBB> suppose so
[19:03:43] <mru> kshishkov: no, haven't for centuries
[19:03:49] <kshishkov> mru: http://sv.wikipedia.org/wiki/Dalrunor
[19:04:13] <BBB> mru: frext h264 conformance samples and -flags emu_edge fate test please?
[19:04:20] <wbs> BBB: the books are quite good, the film isn't really as good IMO
[19:04:28] <BBB> wbs: I didn't read the book
[19:04:33] <BBB> my wife has it but she's only at chapter two
[19:04:45] <BBB> it went so slow that we decided to watch the movie so at least we know what it's about :-p
[19:05:02] <wbs> BBB: they're quite long and thick.. and the first like 150 pages are boring, but then you're hooked
[19:05:20] <mru> BBB: yes, will do
[19:06:06] <kshishkov> wbs: are you talking about "H.264 The Movie"?
[19:06:32] <wbs> kshishkov: no, "Män som hatar kvinnor"
[19:06:43] <wbs> kshishkov: reading it in Swedish would probably be good for you :-)
[19:07:41] <kshishkov> wbs: indeed, but I don't know Swedish contemporary authors at all
[19:07:58] <kshishkov> wbs: except Astrid Lindgren of course
[19:08:25] <wbs> kshishkov: well, then that one would be a good place to start :-)
[19:09:57] <mru> wbs: in sweden, it's women who hate men
[19:10:06] <mru> not all of them of course
[19:10:15] <mru> but a sizable, very vocal group
[19:10:17] <Compn> so uh
[19:10:23] <mru> and they have a lot of political influence
[19:10:29] <Compn> will x264 merge into ffmpeg ? ;)
[19:10:38] <kshishkov> mru: at least you can choose some other women
[19:11:33] <lu_zero> Compn: why?
[19:11:42] <wbs> mru: did you hear about the school that was critizised for having "bad and outdated" chemistry books, when their chemistry books didn't deal enough with multicultural diversity and gender equality (or whatever you call "jämlikhet")
[19:12:05] <Compn> lu_zero : just trolling.
[19:12:38] <elenril> wbs: this channel is bad and outdated!
[19:13:01] <mru> wbs: that's exa`c
[19:13:12] <mru> exactly the kind of thing I'm talking about
[19:13:29] * mru typing on kitchen irc station
[19:14:13] <wbs> mru: yeah.. luckily it hasn't really gotten to that point over here
[19:17:44] <lu_zero> what's exa`c ?
[19:18:06] <wbs> lu_zero: someone stumbling on their enter key while typing "exactly"
[19:18:17] <mru> lu_zero: a typo caused by me using the kitchen irc station
[19:18:22] <lu_zero> ah
[19:18:41] <BBB> kitchen irc station
[19:18:44] <lu_zero> I thought it was an activism movement or something like that
[19:18:52] <mru> lol
[19:19:09] <mru> no, it's just my old laptop sitting in my kitchen
[19:19:15] <kshishkov> BBB: I also have one but only because my flat has exactly two rooms
[19:19:58] <mru> including bathroom?
[19:20:00] * lu_zero meanwhile stares as his patchset
[19:20:56] <kshishkov> mru: yes
[19:21:03] <spaam> lu_zero: how does it go with swscale? :)
[19:21:11] * lu_zero wonders why had worked before...
[19:21:13] * mru suspects his flat is bigger
[19:21:18] <lu_zero> spaam: I'm feverish
[19:21:24] <lu_zero> so damn slowly
[19:21:36] <kshishkov> mru: IIRC, apartments with joined kitchen and bathroom were built only in Soviet Union
[19:21:42] <mru> hehe
[19:22:19] <mru> studio flats are bit too claustrophobic for my taste
[19:22:30] <spaam> lu_zero: ok =/ but it going forward?
[19:22:54] <kshishkov> mru: I can't say I need much space
[19:23:16] <mru> kshishkov: just your body needs a lot more space than mine
[19:23:38] <lu_zero> spaam: it's just boring refactoring
[19:23:38] <mru> wait a few years and see how much junk you accumulate
[19:23:59] <kshishkov> I try not to accumulate junk
[19:24:15] <kshishkov> and usually I get rid of most of it when it hits some threshold
[19:24:27] <mru> but... but... surely you can't be _throwing stuff away_ !??!?!
[19:25:01] <kshishkov> I dibelieve in it being stuff before throwing away
[19:25:06] <mru> anyone interested in my pile of 2MB S3 pci gfx cards?
[19:25:06] <kshishkov> *disbelieve
[19:25:11] * elenril is
[19:25:14] <mru> or maybe some ati mach64 cards
[19:25:21] <mru> several different variants
[19:25:25] <kshishkov> mine still works somewhere
[19:25:37] <mru> 33.6kbps modem anyone?
[19:25:50] <lu_zero> mru: recyclers might
[19:25:53] <kshishkov> I reflashed mine to support V.90
[19:27:49] <kshishkov> and Ukrainian garbage bins accept any kind of junk
[19:27:59] <kshishkov> mine Acer netbook ended there, for example
[19:42:43] <elenril> wow, DonDiego advertising git
[19:42:49] <elenril> (on the mplayer ML)
[19:42:56] * elenril never thought he'd see that
[19:43:14] <mru> diego listens to reason
[19:43:24] <kshishkov> elenril: Linus did on FFmpeg-devel :P
[19:43:38] <elenril> kshishkov: ?
[19:43:42] <mru> I know he's been playing around with git for some time and apparently got used to it
[19:44:10] <mru> elenril: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/50310
[19:44:39] <elenril> o_0
[19:44:46] <kshishkov> elenril: see? That's not some Diego
[19:44:51] <elenril> that's long ago
[19:45:04] <mru> and what a flame war
[19:45:09] * elenril wonders what he was doing at the time
[19:45:24] <mru> probably reading tvtropes
[19:45:36] <wbs> or tagging his mp3's
[19:45:37] * elenril had no idea the vcs wars were going on since that ancient history
[19:45:53] <wbs> wtf, linus on ffmpeg-devel?
[19:46:00] <kshishkov> elenril: yes, our switch to git took a while
[19:46:17] <mru> wbs: yes, he's showed up there a few times
[19:51:48] <uau> elenril: diego's not doing it particularly well though (that 'git svn clone' will likely take hours, you could give a git-clonable tree and tell how to get started immediately from that with git-svn)
[19:52:19] <mru> there's already an auto-synced git-svn tree
[20:02:42] <rojas> Hi, This is my first time here. I'm having some build issues if someone could help.
[20:02:42] <mru> michael is funny... last time patchwork was discussed he declared it "unacceptable"
[20:02:58] <mru> rojas: normally such questions belong in #ffmpeg
[20:03:01] <rojas> ah
[20:03:04] <rojas> Sorry about that
[20:03:07] <mru> np
[20:04:09] <rojas> Well actually its not with building ffmpeg, its will linking. I'm using ffmpeg libraries. Still the wrong place?
[20:04:18] <mru> still #ffmpeg
[20:04:29] <mru> this channel is for hacking on ffmpeg internals
[20:04:31] <rojas> gotcha, well thanks for thel heads up
[20:04:32] <rojas> ahhh
[20:50:37] <siretart> mru: pong
[20:50:44] <siretart> (finally @home)
[20:51:13] <mru> siretart: it's time to start thinking about the next release
[20:51:26] <mru> anything in particular on your wishlist?
[20:51:45] <siretart> mru: I fully agree
[20:51:46] <_av500_> ponies
[20:52:04] <peloverde> vp9
[20:52:05] <siretart> mru: my wishlist: have libavfilter API/ABI stabilized
[20:52:27] <siretart> my todolist: now that the bzr import works, write a launchpad recipe that builds daily packages for ubuntu
[20:52:45] <siretart> with them, I can start upgrade tests and see if binaries built against 0.6 still work
[20:53:01] <mru> I suggest you run fate on those builds and only package those that pass
[20:53:03] <siretart> then I can say if we need to fix stuff or should rather bump major
[20:53:32] <mru> I think it's time we bumped major regardless
[20:53:43] <mru> the list of pending changes is endless
[20:53:43] <siretart> regarding fate, I'm considering throwing the samples in a debian package to have it available in the launchpad build daemons (they don't allow internet access at build time)
[20:53:59] <mru> whatever you need to do
[20:54:26] <siretart> are the samples freely redistributable, or do they have uncertain origins/copyright holders?
[20:54:32] <spaam> siretart: that will be a huge package...
[20:54:54] <siretart> spaam: a few hundred MB in an arch: all package. so what?
[20:54:56] <mru> the copyright status of most of the samples "nobody complained"
[20:55:00] <elenril> doesn't fair use or something apply to samples
[20:55:13] <siretart> I see
[20:55:14] <mru> possibly
[20:55:20] <mru> but we never asked anyone
[20:55:31] <mru> some of them are from iso/itu test suites
[20:55:40] <mru> they have some restrictions on them
[20:55:52] <siretart> well, then I'll probably leave that on the PPA. I don't see much use in them in a distro release anyway
[20:56:17] <mru> peloverde: you just sent a reply to me instead of list
[20:56:24] <peloverde> whoops
[20:57:22] <siretart> mru: have you seen CVE-2011-0480? I've got a bugreport filed for that here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610550
[20:57:52] <siretart> mru: I'd like to backport them to release branches. Can I push commits there, or what is the preferred way to go here?
[20:58:15] <siretart> CVE-2011-0480 is  http://roundup.ffmpeg.org/issue2548
[21:00:05] <mru> siretart: you don't currently have push access, but that can be changed
[21:00:17] <mru> I think you can be trusted not to screw up too badly
[21:00:27] <peloverde> so the corruption part is fixed and the unfixed parts are just illegal reads
[21:00:48] <siretart> mru: I think that would be the easiest for everyone. I had svn access before as well, and the only thing I've touched where the symbol versioning stuff. and backports to release branches of course.
[21:01:09] <mru> send me an ssh key then
[21:01:19] <mru> or is it already on mphq?
[21:03:03] <siretart> I've already sent it to jannau, I think. anyway, you can find it in ~siretart/.ssh/authorized_keys on mphq
[21:03:18] <mru> I don't have access to jannau's list
[21:04:41] <mru> added
[21:05:09] <siretart> thanks!
[21:05:15] <mru> I take it you know how to set up a clone to track the release branches
[21:05:36] <siretart> yes, I've been using git for packaging for quite some time now
[21:06:20] <siretart> what do you think about having debian (and possibly rpm) packaging in master? similar like in mplayer trunk?
[21:06:56] <mru> I think it's mostly pointless
[21:07:05] <mru> the rpm distros wouldn't use it
[21:07:15] <mru> since they patch it to death anyway
[21:07:17] <Compn> siretart : why not put it on a branch? ffmpeg-deb ?
[21:07:26] * Compn trolls some more
[21:07:48] <mru> packaging scripts are better handled by the distros
[21:08:00] <siretart> the point is not to have something ready for distros, but to provide easy means to create daily packages from master
[21:08:25] <siretart> have you noticed the 'make pkg-deb' target in linux?
[21:08:26] <mru> point still stands
[21:08:35] <peloverde> if they aren't going to package it we might as well let users make their own packages
[21:08:53] <siretart> peloverde: sorry?
[21:09:01] <peloverde> rpm distros
[21:09:03] <peloverde> fedora
[21:09:38] <mru> they do package their own patched versions
[21:09:59] <mru> for people building their own, there's not much point in rolling packages
[21:10:10] <peloverde> mru: fedora won't ship ffmpeg under anny circumstances
[21:10:39] <mru> I thought they shipped one with --disable-everything or similar
[21:10:49] <mru> or is that what debian used to do?
[21:10:54] <siretart> the 'upstream' packages would provide users an easy means to replace the distro versions with updated, more recent ones. I'm going to do that anyway, and I don't mind having the debian packages seperate.
[21:11:07] <siretart> I just wondered it might do a service for our users
[21:11:15] <elenril> i'd welcome it
[21:14:03] <peloverde> I thin the biggest issue is programs that abuse private symbols
[21:14:14] <peloverde> do we have some sort of list of them?
[21:14:23] <mru> no
[21:14:36] <elenril> coincidence?
[21:15:09] <siretart> well, there is the pattern of ff_* for private symbols
[21:15:17] <siretart> it's not consistent, though
[21:15:42] <peloverde> I mean a list of programs
[21:15:44] <peloverde> like audacity
[21:15:54] <mru> how could we possibly know?
[21:15:59] <mru> audit all source code?
[21:16:07] <siretart> by testing
[21:16:31] <siretart> audacity is very annoying to test, as they insist on dlopen()'ing libavcodec at runtime
[21:16:52] <peloverde> does mplayer still abuse private symbols?
[21:17:10] <siretart> of course
[21:17:59] <elenril> uau's fork shouldn't
[21:18:16] <elenril> svn version does and reimar insists it keeps doing that iirc
[21:20:41] <siretart> I remember uau claiming that, so I think that's right. however I don't remember raimar insisting on that.
[21:20:59] <siretart> at least I haven't seen (rejected) patches related to this
[21:21:18] <mru> I remember someone insisting on it
[21:21:24] <mru> might have any of the mplayer devs
[21:21:27] <mru> except diego
[21:21:28] <elenril> i recall diego trying to support external ffmpeg
[21:21:45] <siretart> thinking more about it, I think uau fixed some problems by disabling code, and I think raimar insisted on disabling otherwise working stuff
[21:21:49] <elenril> and reimar having  objection against thats
[21:22:00] <siretart> insisted on *not* disabling, that is
[21:24:12] <mru> hmm, stuff fails left and right with LIBMPEG2_BITSTREAM_READER
[21:24:48] <mru> we should either fix it or remove that bitstream reader
[21:26:36] <uau> siretart: there are some disabled video filters (fspp, mcdeint, qp, spp) that are disabled
[21:27:01] <uau> those use dsputil stuff IIRC
[21:27:09] <peloverde> I would imagine all disabled video filters are disabled
[21:27:17] <peloverde> not just some
[21:27:27] <uau> the rest i've fixed to work without using ffmpeg internals
[21:28:32] <elenril> peloverde: http://xkcd.com/703/
[21:30:06] <siretart> uau: ah, it seems that I do remember some things correctly after all ;-)
[21:30:25] <uau> siretart: i think that if you build svn against shared libavcodec there now in fact MORE disabled stuff
[21:30:32] <uau> (and it'll still depend on internals of course)
[21:30:43] <uau> /there/there's/
[21:31:44] <uau> so svn as built in debian is strictly worse: it has all those filters disable, plus MORE stuff disabled, plus it still depends on internal symbols that may change in any release
[21:32:21] <siretart> I see. will investigate later, I'm focusing on ffmpeg right now
[21:32:54] <lu_zero> 22:13 <@peloverde> I thin the biggest issue is programs that abuse private symbols
[21:32:58] <lu_zero> 22:14 <@peloverde> do we have some sort of list of them?
[21:33:07] <lu_zero> flameeyes should have one
[21:33:28] <elenril> didn't see flameeyes in ages here
[21:33:41] <lu_zero> elenril: summon him!
[21:33:53] * elenril summons some flames
[21:33:58] <elenril> and eyes
[21:34:03] <lu_zero> he's sleeping
[21:34:35] <siretart> lu_zero: is he alright?
[21:34:48] <lu_zero> overworked but fine
[21:34:53] <elenril> ask him to visit us when he's not
[21:35:25] * elenril thinks flameeyes is a pretty cool guy eh trolls gentoo and doesn't afraid of anything
[21:36:15] <lu_zero> elenril: =)
[21:36:29] <lu_zero> btw he's also keeping for me one of the automirrors for now
[21:42:24] <spaam> automirrors? :)
[21:42:59] <lu_zero> mail coming soon
[21:57:56] * Flameeyes looks around
[21:58:06] <Flameeyes> somebody called?
[21:58:18] <mru> 21:33  * elenril summons some flames
[21:58:43] <peloverde> Flameeyes: I've been told you have some sort of list of programs that abuse private FFmpeg symbols
[21:59:19] * mru curses bitstream readers
[21:59:29] <Flameeyes> peloverde: not exactly... I did make a few test on that a longish time ago
[22:00:07] <Flameeyes> otoh I have almost the whole set of packages available in gentoo built so I can easily scan for usage of a pattern of symbols that are to be considered private
[22:00:28] <mru> Flameeyes: could your symbol collision checker be set up with a list of forbidden symbols to report?
[22:00:56] <mru> does your list include version tags?
[22:01:29] <Flameeyes> mru: even easier, scanelf -gs '-ff_.*' can be used to find binaries with imported reference of all symbols starting with ff_
[22:02:25] <peloverde> A few programs use unnamespaced symbols like match_ext (now av_match_ext)
[22:02:29] <mru> could you search it for /(?!av).*@LIBAV/ ?
[22:02:47] <mru> +^
[22:02:59] <Flameeyes> mru: uhm the version tag is not matchable with scanelf -gs :(
[22:03:17] <mru> shame
[22:03:19] <Flameeyes> peloverde: if you have a list of symbols that are gone/going I can build the regex and check for those
[22:03:19] <mru> fix it!
[22:03:34] <mru> nm libav* | grep -v ^av
[22:04:12] <Flameeyes> mru: I could probably write a symgrep command that can do the libav match
[22:04:26] <Flameeyes> give me half an hour or so
[22:08:26] <mru> so on x86 only ALT_BITSTREAM_READER works at all
[22:08:32] <mru> A32 works on ARM
[22:08:40] <mru> LIBMPEG2 doesn't work at all
[22:09:10] <mru> well, it works mostly, but fails in quite a few places
[22:09:33] <mru> such as mpeg and anything using golomb.h
[22:10:18] <mru> which includes lossless audio and h264
[22:10:40] <mru> suggestions?
[22:11:22] <peloverde> ditch LIBMPEG2?
[22:11:38] <mru> that's certainly an option
[22:11:52] <mru> it would allow some cleanup round the house too
[22:12:18] <siretart> hmrpf. /me fails to reproduce the crashers in http://code.google.com/p/chromium/issues/detail?id=68115 with 0.6
[22:12:47] <mru> http://xkcd.com/583/
[22:13:38] <siretart> lol
[22:14:16] <mru> there's an xkcd for just about every situation, and he _still_ keeps churning out new ones
[22:32:11] <Flameeyes> mru: uhm ruby's regexp don't seem to accept (?!foo) syntax
[22:32:15] <Flameeyes> beside that the script would be ready
[22:32:39] <saintd3v> lol @ michael's "can you do this for the videolan repo too?"
[22:32:41] <mru> that's perl syntax
[22:33:11] <Flameeyes> it _should_ be the same syntax, that's why I'm baffled
[22:33:24] <Flameeyes> http://paste.pocoo.org/show/325080/ for an example run
[22:33:46] <Dark_Shikari> LOL @ "please get me off your mailing list"
[22:34:17] <Flameeyes> [it's an 83 line script including the license header — long live code reuse]
[22:35:01] <Jumpyshoes> Dark_Shikari: poor gmail users~
[22:35:59] <j-b> Jumpyshoes: poor gmail users with no brain
[22:36:23] <Jumpyshoes> :D
[22:36:27] <Jumpyshoes> <-- gmail user
[22:38:19] <lu_zero> saintd3v: not a _big_ problem giving him that one
[22:39:16] <saintd3v> lu_zero: yeah, but twice in one day just makes it humorous
[22:39:32] <saintd3v> Dark_Shikari: LOL
[22:39:39] <lu_zero> ?
[22:39:56] <saintd3v> Git automirrors, and patchwork
[22:40:45] <lu_zero> ah
[22:41:37] <lu_zero> well it's wiser IMHO.
[22:47:47] <saintd3v> LOL "please get me out of this shopping mall, it's full of people"
[22:47:50] <mru> michael always bitched about "root" not doing things his way
[22:47:58] <mru> let him do things himself now
[22:50:02] <lu_zero> mru: it's up to Flameeyes and jannau provide those
[22:50:29] <lu_zero> I just set up the gitorious space as common courtesy
[22:54:04] <lu_zero> uhm
[22:54:12] * lu_zero wonders why he couldn't pull
[22:57:52] <saintd3v> not holding your tongue correctly?
[22:58:25] <mru> lu_zero: how you spend your time is of course up to you
[22:59:14] <Flameeyes> mru: okay so what did you want me to look for?
[23:00:46] <mru> anything with a @LIBAV.* version tag not starting with av
[23:01:28] <Flameeyes> okay... /me adds -l/-L switches to the script
[23:03:06] <lu_zero> mru: ^^
[23:04:37] <mru> any suggestions what to run on a spare quad-core?
[23:05:04] <peloverde> Is there a way to automirror on github? IIRC they had some method that was completely on their side
[23:05:23] <mru> we can set up hooks on our side
[23:05:42] <lu_zero> peloverde: it's better use local hooks
[23:06:30] <Flameeyes> peloverde: I haven't found a way to do that on their side when I looked, yet I remembered them having one at some point
[23:06:43] <Flameeyes> for gitorious it was easier to look up the ToS and then setting up a scripts on my vserver
[23:18:45] <Flameeyes> there's a mistake on the grep(1) man page, yuppie
[23:23:21] <mru> fun
[23:28:22] <mru> Flameeyes: what virtual machine(s) do you use?
[23:28:47] <Flameeyes> mru: kvm generally — but the tinderbox and a few other things run on lxc (which is not a virtualisation system!)
[23:29:07] <mru> so nothing like vmware esx?
[23:29:48] <Flameeyes> nope
[23:29:54] <mru> lxc is just namespaces within the same kernel, right?
[23:30:08] <lu_zero> right
[23:30:21] <mru> less overhead, less isolation
[23:30:47] <lu_zero> exactly
[23:31:39] <saintd3v> i've been meaning to setup an esxi box :/
[23:31:59] <mru> I just installed it on my core2q
[23:32:08] <mru> now I'm trying to figure out how the fuck to control it
[23:32:41] <saintd3v> hak5 had some good episodes on esxi
[23:34:42] <Flameeyes> mru: I'd add "very little isolation at all"
[23:34:47] <jannau> mru: I did already before or shortly after you bugged
[23:34:55] <mru> jannau: I noticed
[23:37:22] <mru> vmware website sucks
[23:38:21] <Flameeyes> okay elfgrep running on tinderbox, will take a bit
[23:39:51] <spaam> Flameeyes: do you have all multimedia package installed?
[23:40:02] <Flameeyes> spaam: I have almost all of Gentoo installed there
[23:40:27] <mru> how much disk space does that use?
[23:40:28] <spaam> ok how much space does it take?
[23:40:34] <spaam> ;D
[23:40:46] <Flameeyes> about 80G
[23:41:14] <spaam> how much space does windows vista take?
[23:41:35] <mru> all of it
[23:42:09] <saintd3v> Flameeyes: that's why i see you everywhere on gentoo bugzilla =P
[23:42:14] <Flameeyes> vista no clue, but 7 should take no more than 8G fom base install or something
[23:42:39] <Flameeyes> saintd3v: heh likely.. if there is a build failure, I have filed a bug :)
[23:43:53] * lu_zero ponders about the windows autobuilds
[23:44:16] <spaam> Flameeyes: are you using USE="*" also? :)
[23:45:02] <Flameeyes> nope, just an half-decent combination of USE flags
[23:50:33] <spaam> how long will it take to recompile all those packages? :)
[23:53:16] <Flameeyes> about 6 weeks if nothing goes wrong
[23:53:16] <Dark_Shikari> mru / Flameeyes: ping
[23:53:19] <Flameeyes> Dark_Shikari: pong
[23:53:21] <mru> pong
[23:53:24] <Dark_Shikari> I invited you to a channel, join it
[23:56:09] <jannau> ruggles: you're also ffmpeg maintainer on patchwork