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

[irc at mansr.com]

[00:00:51] <mmu_man_> upgrade ? :p
[00:01:22] <jannau> that would also break the layout
[00:01:28] <mmu_man_> does this old one handle -number-footnotes & -number-sections ?
[00:01:44] <mmu_man_>  --number-footnotes!   1  output footnote numbers.
[00:01:44] <mmu_man_>  --number-sections!   1  output chapter and sectioning numbers.
[00:12:10] <jannau> doesn't look like it would: http://manpagez.com/man/1/texi2html/osx-10.3.php
[00:21:41] <mmu_man_> sux
[00:21:46] <mmu_man_> upgrade then :p
[00:21:57] <mmu_man_> maybe we could fallback
[00:22:10] <mmu_man_> texi2html ... -number || texi2html ...
[03:15:25] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * re5262ec44a ffmpeg/libavcodec/dsputil.c:
[03:15:26] <CIA-38> ffmpeg: Optimize C version of ff_emulated_edge_mc().
[03:15:26] <CIA-38> ffmpeg: From ~780 cycles to 551 cycles, mostly just by using libc memcpy()
[03:15:26] <CIA-38> ffmpeg: instead of manually shuffling individual bytes around.
[03:15:26] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r2e27959879 ffmpeg/libavcodec/ (15 files): Move ff_emulated_edge_mc() into DSPContext.
[03:17:18] * Sean_McG cheers
[07:36:43] <peloverde> How can SBR output scaling be correct after the latest changes to aacsbr?
[07:38:05] <peloverde> (and yes the output appears correct)
[07:43:03] <peloverde> Output scaling was completely removed
[07:46:41] <peloverde> I guess nevermind, I think I misunderstood what we were doing with the C version
[08:07:23] <peloverde> "Please note that many of the final equations presented by the paper are obviously incorrect but if you follow their work you should be able to arrive at the correct equations."
[08:07:30] <peloverde> I leave the most useless notes for myself
[08:09:00] <peloverde> I also completely failed to explain the mapping between the DCT-IV and the half IMDCT
[08:19:08] <peloverde> at some point I should finish optimizing the SBR filterbank
[08:20:58] <saintdev> thought you had given up?
[08:22:53] <peloverde> i've been remotivated lately
[08:24:21] <peloverde> There is a dropped minus sign on equation (76)
[08:26:26] <peloverde> It is one of the only useful papers on doing SBR decoding quickly and the math is so sloppy :(
[09:34:54] <lu_zero> good morning
[09:35:10] <peloverde> greetings
[09:58:50] <twnqx> we had the discussion about XXX+cue recently - is there actually a unix player that can handle those? at least wav+cue and flac+cue
[10:00:53] <twnqx> *sigh* and preferably bin+cue
[10:01:17] <Dark_Shikari> foobar2000 in wine?
[10:01:30] <peloverde> how do we handle pre-roll and gapless type stuff in general?
[10:01:31] <twnqx> ... i was kinda afraid i'd get this answer
[10:01:49] <spaam> twnqx: xmms2 ?
[10:02:28] <_av500_> urgh
[10:02:40] <twnqx> peloverde: we lack, genrally speaking, metafile support - kinda like playlist, with both multiple tracks in one file, and multiple files as one track (e.g. .mkv with ordered chapters)
[10:03:01] <twnqx> i always considered that a player thing though
[10:03:12] <twnqx> spaam: will have a look.
[10:03:36] <twnqx> foobar would have the advantage of playing ape+cue and tak+cue as well...
[10:05:11] <_av500_> and cue+cue?
[10:06:07] <Dark_Shikari> tta + cue is all that matters
[10:08:56] <lu_zero> twnqx: it isn't a player thing anymore
[10:09:00] <lu_zero> (sadly)
[10:09:18] <lu_zero> most of the segmented types are now "network pseudostreams"
[10:10:40] <wbs> lu_zero: except they're normally slightly different - the segmented streams still are the same data stream, just chopped up, while playlists easily can have data in different formats (needing close+reopen of codecs)
[10:13:48] <_av500_> lu_zero: maybe its a libavplay thing?
[10:14:49] <kshishkov> _av500_: if you mean common code from ffmpeg, ffplay and avcode then it's not there yet
[10:14:56] <_av500_> http://www.flickr.com/photos/av500/5397821774/
[10:15:12] <_av500_> kshishkov: i know that
[10:15:29] <_av500_> but i proposed it in the past
[10:15:58] <elenril> twnqx: i think mpd can
[10:16:30] <kshishkov> _av500_: WTF is that?
[10:16:48] <_av500_> kshishkov: in the past news was printed...
[10:17:07] <elenril> wtf
[10:17:19] <elenril> looks shopped
[10:17:24] <spaam> _av500_: why do you read past news?
[10:17:33] <_av500_> it came today
[10:17:35] <kshishkov> _av500_: yes, it looks like a photo of part of page from eine Zeitung but WTF with the content?
[10:17:42] <_av500_> kshishkov: ??
[10:18:02] <elenril> lu_zero: did you see the playlists branch yesterday?
[10:19:15] <kshishkov> _av500_: it doesn't look like what really happened
[10:19:39] <_av500_> kshishkov: well
[10:20:01] <_av500_> news is never about what REALLY happened
[10:20:33] <elenril> but srsly, who writes dead-tree news about open source politics
[10:20:40] <_av500_> and i dont think this is written too badly
[10:21:17] <kshishkov> elenril: people with too little news to fill the page?
[10:21:36] <_av500_> c't has one page dedicated to os news
[10:21:58] <lu_zero> elenril: I fell asleep before...
[10:22:48] <lu_zero> wbs: the segmented stuff might change in between
[10:23:00] <lu_zero> (e.g. bandwidth adaptation)
[10:23:09] <wbs> lu_zero: ah, yes
[10:23:36] <elenril> in any case, our playlist api should be able to handle both
[10:24:02] <lu_zero> and it's lovely how they mess up even the normal stuff
[10:24:47] <wbs> elenril: otoh, segmented streaming playlists have a bit of other peculiarities (such as re-polling a sliding window playlist)
[10:26:16] <wbs> and for some cases, regarding them as a pure playlist and playing each item in order doesn't yield the correct result - in some cases, the ts segment files are split in "bad" places, so that you get broken packets at the end of segments, but the correct result if you concatenate the segment files
[10:26:49] <lu_zero> wbs: that is a segmenter bug IMHO
[10:27:15] <lu_zero> and that reminds me that somebody asked me about that
[10:28:30] <wbs> lu_zero: perhaps it can be considered a segmenter bug yes, but regardless, there are such streams out there, that our current code doesn't play back well, while (afaik) iOS plays them just fine
[10:28:55] <wbs> my initial approach with an urlprotocol that feeds the data as one single long stream to the demuxer handles it fine though
[10:29:29] <lu_zero> indeed
[10:30:00] <lu_zero> and I think the mpegts demuxer can handle changes
[10:31:17] <wbs> yes, but the issue is when one segment returns EOF, and the mpegts demuxer returns an incomplete (broken?) packet from the data available, then we switch the underlying ByteIOContext to the next segment and continue reading
[10:31:40] <wbs> then we don't get the same output packets as if the segments had been one single stream and no EOF had been returned inbetween
[10:32:06] <lu_zero> agreed, I was thinking about the other scenario
[10:32:14] <bcoudu> playlist branch ? where can I see that ?
[10:32:41] <lu_zero> so you glue as a single stream
[10:32:53] <wbs> ah, yes
[10:32:57] <wbs> yes, that might work just fine
[10:33:03] <lu_zero> what isn't originally a single stream
[10:33:05] <lu_zero> ^^;
[10:33:07] <twnqx> _av500_: c't?
[10:33:22] <wbs> the only issue with that is you can't receive two different bitrate variants at once, which the current approach allows
[10:35:51] <twnqx> ah, you said it earlier
[10:36:05] <bcoudu> ?
[10:38:25] <peloverde> twnqx: so we don't have any infrastructure to support gapless audio?
[10:39:32] <twnqx> at the very least we don't have .cue support - or i'm not aware of it.
[10:39:57] <twnqx> also it would be a matter of seeking API if someone wants single tracks
[10:40:22] <twnqx> with higher precison than "codec frame"
[10:40:33] <peloverde> that is my big problem
[10:40:47] <bcoudu> so guys, where can I see the playlist branch ?
[10:40:48] <peloverde> I want to give AAC sample accurate cutting
[10:46:14] <bcoudu> elenril ?
[10:46:27] <lu_zero> bcoudu: on his github
[10:46:31] <lu_zero> let me dig
[10:47:07] <lu_zero> git://git.khirnov.net/git/ffmpeg
[10:47:09] <lu_zero> pardon
[10:47:26] <bcoudu> great, thanks
[10:47:26] <elenril> yeah
[10:47:40] <elenril> bcoudu: but it's just the latest soc patch rebased against current master
[10:48:02] <bcoudu> ah
[10:48:10] <lu_zero> elenril: could you send an email about that btw?
[10:48:20] <bcoudu> I think wbs approach is a nice one
[10:48:29] <bcoudu> (urlprotocol)
[10:49:04] <bcoudu> do you have an idea about where the bitrate switching will occur ?
[10:49:44] <lu_zero> bcoudu: we have different strategies
[10:50:02] <lu_zero> in one the switch should be a client side decision
[10:50:17] <lu_zero> in any case it happens on a segment boundary
[10:51:25] <bcoudu> having both would be nice
[10:51:29] <bcoudu> user + auto
[10:57:07] <wbs> hmmm, interesting git weirdness. I've got one branch named "symbian" - if I do "git checkout -b symbian-gcce4" in order to create a new branch named that, git refuses, saying there's already a branch with that name
[10:57:39] <wbs> this seems to be due to the way parsing of git describe style names work
[10:58:01] <wbs> since it interprets it as <branch>-g<hash>, so it looks for the commit with the hash starting with "cce4" on the branch "symbian"
[10:58:39] <wbs> if I explicitly create the branch with "git branch symbian-gcce4" it works fine though
[11:10:54] <lu_zero> and then you can checkout properly?
[11:12:02] <wbs> yes
[11:16:42] <lu_zero> really strange
[11:17:38] <wbs> checkout -b probably uses a different version for checking whether the given names matches anything in the repo already than what branch uses
[11:20:50] <lu_zero> yes
[11:55:26] <superdump> Dark_Shikari: ping?
[12:01:56] <superdump> Dark_Shikari: never mind, i located the channel mixing patches from here: http://muzso.hu/2009/02/25/downsampling-multichannel-audio-5.1-into-stereo-2-channels-with-ffmpeg
[12:03:32] <lu_zero> superdump: are you willing to repubblish them?
[12:04:01] <superdump> i'm going to have a look at them to see what's what
[12:04:18] <superdump> N channel resampling and M->N channel mixing really shouldn't be that difficult
[12:05:12] * Kovensky is also interested in that
[12:05:42] <jannau> I think the plan in regard to resampling and remixing was to wait for lavfi audio support
[12:06:11] <Kovensky> lavfi still doesn't do audio?
[12:06:25] <jannau> or at least move it out of libavcodec
[12:06:47] <jannau> which current flavour is lavfi audio
[12:06:54] <wbs> I at least see it as two different, orthogonal issues - having a function for doing that, in lavc or lavcore, that can be used easily whereever would be one step, then wrapping it up in filters for use in libavfilter filter chains is another issue
[12:07:08] <Kovensky> I wrote an audio filtering system for x264 as part of gsoc, maybe it can be used if it is correct
[12:07:14] <wbs> (I wouldn't want to have to use a full lavfi filter chain just to be able to downmix)
[12:07:25] <saste> wbs: +1
[12:07:47] <saste> there was the idea of having a separate lib lavresample
[12:07:59] <saste> in the meaningwhile the code can stay in lavc and be moved later
[12:08:42] <bcoudu> lavfi audio must be used
[12:08:49] <Kovensky> Receiving objects:   1% (2324/137093), 604.00 KiB | 3 KiB/s <-- this will take a while =p
[12:08:49] <bcoudu> and the dumb interface dropped
[12:09:17] <Kovensky> IMO any simple interface should be a wrapper around lavfi
[12:09:20] <bcoudu> now a quick solution can definitely be added the dumb interface
[12:09:48] <superdump> is libavfi audio functional?
[12:09:57] <superdump> if not, what is needed for it to be so?
[12:10:08] <bcoudu> interface is in already
[12:10:11] <saste> the patches I posted work mostly
[12:10:25] <saste> there is also a design problem to be fixed with av_samples_*
[12:10:38] <saste> see the recent thread and the reply from Michael
[12:10:47] * Kovensky had to rewrite his system thrice due to design problems
[12:10:58] <saste> once I'll get ffplay lavfi audio support I'll add support to ffmpeg
[12:11:04] <saste> togheter with a test system
[12:11:23] <saste> hels is welcome of course
[12:11:31] <saste> so feel free to pick my patches and work on them
[12:12:04] <Kovensky> I don't have much time atm, and I don't know anything about ffmpeg's codebase :(
[12:15:23] <bcoudu> also the patch in question, assumes a channel order
[12:15:30] <bcoudu> which will be wrong either for aac or for ac3
[12:15:55] <superdump> it should use the waveformatex channel order, no?
[12:16:01] <superdump> in combination with the layout
[12:16:12] <bcoudu> it should use whatever is stored in the codec first, then the container
[12:16:15] <superdump> saste: where are your patches?
[12:16:29] <saste> superdump: on the ML
[12:16:38] <saste> check for av_samples_
[12:16:42] <superdump> ok, thanks
[12:16:46] <saste> aconvert
[12:16:55] <saste> and lavfi ffplay audio support
[12:20:57] <lu_zero> saste: your patches are about 8 channels
[12:21:05] <lu_zero> iirc
[12:21:18] <saste> lu_zero: yes
[12:24:01] <lu_zero> so to handle more-than-8 you just do a staged downmix
[12:41:09] <{V}> mmu, Janne has an alternative patch for the texi2html issue, it removes the 'number' option, but wasn't tested in texi2html 5. Perhaps you'd care to test it
[12:42:12] <jannau> {V}: thanks
[12:42:30] <jannau> saste: can you check with 1.82
[12:43:32] <bcoudu> mkv is really crap with timestamps
[12:43:57] <bcoudu> it's great to claim to support nanosecond precision but if no implementation use it ...
[12:44:15] <mmu_man> {V}: sorting 90mails atm
[12:46:48] <spaam> bcoudu: do you really need nanosecond precision?
[12:46:50] <ohsix> bcoudu: it's future proof! it's ready for that day when theres 1ns wakeups
[12:47:46] <Tjoppen> spaam: ts does
[12:48:33] <spaam> Tjoppen: ok
[12:48:45] <superdump> i will have a look at the mixing stuff when i can
[12:48:51] * Kovensky goes read more fflames in the ml
[12:48:53] <superdump> have a good day
[12:49:35] <Kovensky> 09:16.12 bcoudu: it should use whatever is stored in the codec first, then the container <-- isn't ffmpeg supposed to always convert channel order to waveformatex so code outside decoders doesn't need to special case everything?
[12:50:59] <Kovensky> 09:43.57 bcoudu: it's great to claim to support nanosecond precision but if no implementation use it ... <-- it is mostly untested, but ffms2 with the haali demuxer for example support it
[12:51:03] <Kovensky> or at least I saw some commits from Plorkyeran fixing things related to timebases different from 1/1000
[12:51:30] <{V}> Kovensky, re:fflames. You mean the Donations thread? it seems to be going in a non-flaming direction. :)
[12:51:44] <bcoudu> spaam, no
[12:51:49] <bcoudu> but you need accurate timestamsp
[12:52:05] <bcoudu> and ms sucks
[12:52:28] <bcoudu> containers should use 1/sample_rate for audio
[12:52:39] <bcoudu> 1/frame_rate for video cfr
[12:52:51] <bcoudu> and for vfr, well arbitrary big value
[12:54:09] <bcoudu> pcr is 27mhz in ts
[12:54:15] <bcoudu> but timestamps are 1/90000
[12:54:39] <Kovensky> {V}: there are other threads I haven't caught up with yet :)
[12:55:19] <bcoudu> Kovensky, I'm not sure about the channel order all decoders output
[12:55:26] <{V}> Kovensky, oh okay. Well if you get tired of flames and dev talk, check the latest mails in the Donations thread :p
[12:55:26] <bcoudu> maybe you are right
[12:56:05] <bcoudu> Kovensky, it's not about the mkv demuxer
[12:56:09] <bcoudu> it's about the muxer
[12:56:19] <bcoudu> if the muxer choose 1/1000, you are fucked up
[12:56:30] <bcoudu> mov can fuck up like this as well
[12:56:33] <Kovensky> mkvmerge uses 1/1000 by default but you can specify an arbitrary time base
[12:56:37] <Kovensky> I don't know if this is well tested though
[12:56:37] <bcoudu> like FCP who likes to use 1/2997
[12:56:53] <bcoudu> because 1/30000 does not allow as much duration
[12:57:14] <bcoudu> on an uin32_t that is
[12:57:24] <Kovensky> lol
[12:57:41] <Kovensky> can matroska timebase numerators be arbitrary numbers btw? having a 1001/30000 timebase would be even more accurate =p
[12:58:40] <kierank> I wonder why ffmpeg doesn't have a sup demuxer
[13:00:26] <_av500_> sup?
[13:00:58] <kierank> a subtitle file format
[13:01:15] <Tjoppen> patch welcome?
[13:01:16] <kierank> for dvds and blu-ray
[13:01:18] <kierank> yeah
[13:01:23] <Kovensky> isn't that one also used on BDs?
[13:01:29] <Kovensky> efb
[13:01:33] <kierank> yeah, it's just a generic bitmap container
[13:01:40] <kierank> a little header with a pts at the front
[13:01:46] <Tjoppen> speaking of subtitles, I should probably take another shot at fixing dvbsub remuxing
[13:01:59] <bcoudu> dvbsub :)
[13:02:15] * Kovensky wonders when will the aurelsubs issue be fixed
[13:02:23] <Tjoppen> lavc is.. interesting in that regard. the decoder and encoder don't agree on the bitstream
[13:02:37] <bcoudu> make it consistent, please
[13:02:42] <Tjoppen> hence the demuxer/muxer don't as well, needlessly requiring a parser
[13:02:52] <bcoudu> btw, I had another look at your patch the other day for pcr only packets
[13:03:20] <kierank> i wonder why the vob demuxer doesn't pick up all the subtitle streams
[13:03:20] <bcoudu> and I didn't remember exactly what was the concern about the overhead
[13:03:33] <bcoudu> kierank, > 20 streams ?
[13:03:37] <kierank> no
[13:03:45] <Tjoppen> well, it does add a bit more overhead in rare cases. hm, let's see if I can remember
[13:03:50] * Kovensky wonders why is there a hardcoded limit in the number of streams
[13:04:15] <Tjoppen> but: I have an updated patch that I should send to the ml. still far from optimal and doesn't support < 10 fps but still
[13:04:27] <bcoudu> Kovensky, legacy, it will be removed with the next major bump
[13:04:30] <{V}> kierank, there was a patch+thread about blu-ray subtitle support on ffmpeg-devil in 2009
[13:04:38] <{V}> oops devel
[13:04:47] <bcoudu> -devil :>
[13:04:52] <kierank> we have blu-ray subtitle support, no?
[13:04:53] <Tjoppen> without rewriting half the muxer it'll be hard to get proper output. at least a QAM takes it
[13:05:07] <Tjoppen> or so someone in libav-user claimed
[13:05:09] <bcoudu> yes, pgs
[13:05:43] <kierank> Tjoppen: sounds about right
[13:05:46] <bcoudu> oh yes the muxer would love a rewrite
[13:06:11] <bcoudu> it has only be tweaked to just enough for some usage
[13:06:49] <Tjoppen> yeah.. well, I'll see if I can get my laptop hooked up somewhere so that at least the pcr period problem can be resolved
[13:07:04] <Tjoppen> since my code and mail is on there
[13:07:40] <Tjoppen> atm I'm busy with more horrible things, such as trying to get opatom muxing and aaf files that avid will take :\
[13:08:17] <bcoudu> opatom for work ?
[13:08:31] <bcoudu> standard opatom or avid crap ?
[13:08:59] <Tjoppen> both. but the avid opatom isn't too bad - at least it's (mostly) s390m compliant
[13:09:21] <Tjoppen> it's just the retardedness of having to use the same material package for all opatoms that i
[13:09:24] <kierank> If I find a student to fix the ts muxer for gsoc '11, I'm going to make the qualification task involve writing an explanation of T-STD
[13:09:26] <Tjoppen> is.. interesting
[13:10:04] <Tjoppen> one things is quite interesting though: the avid people spotted and "fixed" a but on s390m
[13:10:27] <Tjoppen> namely that VFR essence > 5 minutes or so can't be held in opatom
[13:10:42] <Tjoppen> since the index can't be larger than 64k and each entry is 11 bytes
[13:11:02] <bcoudu> kierank, lol
[13:11:07] <bcoudu> that's actually a good idea
[13:11:09] <Tjoppen> so they go "length = 0xFFFF" and have that mean "the index is the size of the rest of the klv packet"
[13:11:46] <Tjoppen> s/but on/bug in/
[13:11:58] <bcoudu> index can be larger
[13:12:02] <bcoudu> you just have to split it
[13:12:05] <Tjoppen> not for a single essence container
[13:12:08] <Tjoppen> and opatom only allows one
[13:12:15] <Tjoppen> or?
[13:12:21] <bcoudu> where is that written ?
[13:12:36] <Tjoppen> s390m, page two or three
[13:12:38] <bcoudu> xdcam op1a only uses sprinkled index tables
[13:12:48] <bcoudu> oh ok
[13:12:50] <Tjoppen> also, the index can't be sparse
[13:13:06] <bcoudu> then yes they fucked up in s390m
[13:13:09] <Tjoppen> so yeah.. a bug in the spec AFAICT
[13:13:59] <Tjoppen> if only they'd used BER lengths in local sets or something..
[13:14:36] <bcoudu> indeed
[13:15:12] <Tjoppen> btw, those opatom patches on the ml are insufficient for an opatom that has the index only in the footer
[13:15:46] <Tjoppen> since it stops on the essence container
[13:15:53] <Tjoppen> the header parsing that is
[13:16:00] <bcoudu> yes
[13:16:18] <bcoudu> I don't like this patch ...
[13:16:27] <bcoudu> especially the one adding zillions of ULs
[13:16:34] <Tjoppen> I haxed my local tree a bit, but the demuxer needs to be aware of partitions (among other things)
[13:16:55] <Tjoppen> yeah, that's why I posted my simplified patch
[13:17:09] <bcoudu> and if you seek
[13:17:16] <bcoudu> it won't work and fuck the demuxer I think
[13:17:44] <Tjoppen> well, the seeking it does is already quite dubious though :)
[13:18:06] <bcoudu> it's inacurate for vbr
[13:18:10] <bcoudu> but most mxf are cbr anyway
[13:18:22] <Tjoppen> it doesn't account for the header
[13:18:29] <bcoudu> ok ok :>
[13:18:32] <Tjoppen> and the header can be quite large
[13:18:47] <bcoudu> but it allows seeking in _all_ mxfs
[13:18:49] <Tjoppen> say you have some dms-1 metadata and a huge index there :)
[13:18:56] <bcoudu> op1a
[13:19:05] <Tjoppen> unless they're clip wrapped
[13:19:12] <bcoudu> op1a is frame wrapped
[13:19:26] <Tjoppen> always? hm, must've missed that
[13:19:29] <bcoudu> clip has to use op1b
[13:20:33] <Tjoppen> anyway, I'll have to add seeking support for clip wrapped at work the next week or so. hopefully I can get it to use an index properly
[13:21:21] <bcoudu> single essence container
[13:21:41] <bcoudu> and only one type
[13:21:46] <mmu_man> jannau: hmm can't copy-paste your patch, either my MUA or yours inserted line breaks
[13:22:09] * Kovensky pats saste
[13:22:24] <Kovensky> (for learning the meaning of "mud slinging" from fflames)
[13:22:33] <mmu_man> jannau: ah worked now
[13:22:40] <bcoudu> for clip wrap with 2 tracks you need at least 2 essence containers
[13:22:41] <mmu_man> seems Mail.app has yet another bug
[13:22:43] <bcoudu> IIRC
[13:22:50] <Tjoppen> of course
[13:22:59] * Kovensky uses Sparrow.app
[13:23:00] <bcoudu> so that is not compatible with op1a
[13:23:12] <bcoudu> you can have clip wrap op1a, but only one track
[13:23:13] <Kovensky> the way it threads is annoying though; it feels like reading top posts ;_;
[13:23:25] <Tjoppen> I was thinking a but of multi-track clip wrap demuxing. it'll have to seek like crazy
[13:23:29] <Kovensky> I should complain at them since while it tries to be close to gmail it shows threads in the opposite sort order
[13:23:44] <bcoudu> yes
[13:23:45] <bcoudu> op1b
[13:23:55] <bcoudu> this is crazy btw
[13:24:27] <Tjoppen> of course - it's mxf
[13:24:41] <saste> jannau: nice job, works fine here with  texi2html 1.82
[13:25:13] <Tjoppen> although, to be fair, they have put some thought into handling tape stuff. like where indexes can go and how to seek fast to cetain portions of the file
[13:25:50] <Tjoppen> but opatom still only requires an index in the footer, and closed header, so it can't be read from tape
[13:26:10] <Tjoppen> nor written to tape, unless you know the length on advance
[13:26:21] <bcoudu> ditch tapes
[13:26:38] <Tjoppen> s/tape/pipe then. but yeah
[13:27:30] <Tjoppen> I'm off
[13:27:40] <bcoudu> you can write a closed header at first I think
[13:27:47] <bcoudu> you just have to use the default values
[13:27:56] <bcoudu> you'll update them in the footer
[13:29:16] <bcoudu> anyway I'm off too, sleeping
[13:29:29] <Tjoppen> can't have metadata in the footer in opatom
[13:33:39] <Kovensky> 10:04.30 {V}: kierank, there was a patch+thread about blu-ray subtitle support on ffmpeg-devil in 2009 <-- freudian (kinda) slip? :)
[13:34:09] * {V} refuses to self-diagnose :p
[13:36:46] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r0745116c10 ffmpeg/libavcodec/arm/asm-offsets.h: ARM: update MpegEncContext offsets
[13:39:33] <uau> Kovensky: all Matroska time arithmetic is basically in nanoseconds
[13:40:12] <uau> it has the TimecodeScale element, which means that various other timestamps numbers will be multiplied by the given value
[13:41:35] <Kovensky> I see, so you can only touch the denum
[13:42:23] <lu_zero> saste: he use of reordered_opaque in the movie filter is on purpose?
[13:43:43] <uau> it's typical for files to specify a TimecodeScale of 1000000, which means timestamps will be in units of 1 ms (1e6 ns)
[13:48:52] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * rce20edb7bd ffmpeg/libavformat/oggparsevorbis.c:
[13:48:52] <CIA-38> ffmpeg: Vorbis-in-Ogg: Do not set timebase to invalid values
[13:48:52] <CIA-38> ffmpeg: Avoids an assert when the sample rate is invalid and the timebase
[13:48:52] <CIA-38> ffmpeg: is thus set to e.g. 1/0.
[13:48:52] <CIA-38> ffmpeg: Sample file is http://samples.mplayerhq.hu/ogg/fuzzed-srate-crash.ogg
[13:48:53] <CIA-38> ffmpeg: This is a quick fix for a crash, not a final solution.
[13:48:54] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:57:29] * mru curses flexlm
[13:58:34] <kshishkov> what's that and how it's related to gcc?
[13:58:36] <Kovensky> 10:42.24 lu_zero: saste: he use of reordered_opaque in the movie filter is on purpose? <-- wasn't it recently deprecated?
[13:59:03] <Kovensky> 10:43.43 uau: it's typical for files to specify a TimecodeScale of 1000000, which means timestamps will be in units of 1 ms (1e6 ns) <-- because that happens to be mkvmerge's default
[13:59:24] <mru> kshishkov: flexlm is a stupid licence manager used by a lot of commercial software
[13:59:57] <kshishkov> mru: then cursing it does no good - it's like trying to curse demons
[14:00:55] <jannau> kshishkov: I suppose they use it for their non-demo versions too
[14:04:45] <jannau> kshishkov, lu_zero: I suppose it's for backwards compatibility. deprecating something doesn't magically make it unused in 3rd party code
[14:04:48] <mru> the version of it armcc uses is buggy and once in a while insists that the system clock has been tampered with
[14:07:49] <kshishkov> have you tried reporting that bug?
[14:13:07] <mmu_man> jannau: seems to work fine
[14:14:08] <jannau> mmu_man: the output looks like http://ffmpeg.org/ffmpeg.html ?
[14:15:14] <mmu_man> at least it builds
[14:16:01] <mmu_man> almost like
[14:16:07] <mmu_man> with some navigational arrows
[14:16:26] <jannau> argh
[14:16:38] <mmu_man> http://revolf.free.fr/ffmpeg.html
[14:16:50] <mmu_man> it does have the summary
[14:17:15] * jannau downloads texi2html 5.0
[14:17:44] <jannau> we don't want the navigation
[14:17:49] <jannau> mmu_man: thanks
[14:18:04] <mru> wow, what a slab of nothing at the top
[14:18:35] <mru> is that the (even more) minimalist version of the wordpress default theme?
[14:19:50] <jannau> I think that is actually a bug fix, our texi files have @sp around the title which seems to be ignored with older versions
[14:20:08] <mru> it's ugly whatever the cause
[14:21:20] <jannau> wtf texi2html source tarball is 15M bz2-ipped
[14:22:02] <jannau> 1.78 was 443k
[14:22:08] <mru> hmm
[14:24:20] <mmu_man> maybe there is a photo of the author in 5000x5000 ? :p
[14:24:32] <mru> uncompressed tiff
[14:25:11] <kshishkov> or a collection of selected Stallman speeches
[14:25:16] <kshishkov> in ASCII
[14:26:02] <mmu> lokl
[14:26:08] <pengvado> ginormous regression tests
[14:29:30] <jannau> pengvado is correct, it has extracted a 147M large test directory
[14:32:17] <{V}> probably a trend that started around version 1.8. Its tar.gz is 7M
[14:32:50] <mru> do you see the word enterprise mentioned anywhere?
[14:33:49] <kshishkov> that sould be redundant
[14:34:08] <jannau> no, but it looks like it will become gnu software
[14:34:23] <jannau> so braindamage is to be expected
[14:38:44] * kshishkov likes the first three lines in http://svn.xiph.org/trunk/planarity/Makefile
[14:40:01] <mru> :)
[14:40:26] <kshishkov> mru: see, even they can write partially good makefiles
[14:40:47] <mru> recursive...
[14:42:46] <mmu> fuck automake \o/
[14:42:57] <mmu> autofools burn in hell
[14:47:16] <spaam> kshishkov mru mmu : http://fosdem.org/2011/schedule/event/autotools  something for you guys ;D
[14:47:52] <kshishkov> nothing for me
[14:48:09] <spaam> maybe for DonDiego ? :)
[14:50:12] <mmu_man> empty page here
[14:50:46] <mmu_man> seems they screwed up at #fosdem
[14:50:57] <{V}> here too. The main page works, but as soon as you try to access the schedule. blank.
[14:51:14] <{V}> just search DonDiego for weapons before he's allowed in the room. Murder charge for FFmpeg dev would not be good publicity. :p
[14:52:26] <lu_zero> autotools aren't as bad as their common usage make you think
[14:52:53] <kshishkov> what? are they even worse?
[14:53:01] <lu_zero> kshishkov: nope =P
[14:53:28] <mmu_man> ah works now
[14:53:36] <kshishkov> lu_zero: and checking for Fortran compiler is not mandatory?
[14:54:39] * {V} is suddenly curious about which build system autotools use :)
[14:55:26] <lu_zero> kshishkov: it is not mandatory...
[14:55:53] <lu_zero> as checking for C++
[14:56:06] <lu_zero> or default C99 headers one by one
[15:07:05] <Kovensky> 11:53.36 kshishkov: lu_zero: and checking for Fortran compiler is not mandatory? <-- that was an ancient automake bug that was fixed over a year ago
[15:07:39] <kshishkov> that shows how much they cared about their product
[15:09:13] <Kovensky> most of the time I spend when building a new toolchain is on workarounding custom build systems or libtool; only once in a while I need to mess with autoconf/make
[15:09:52] <lu_zero> kshishkov: the main problem with autotools are their users
[15:10:01] <lu_zero> and the anti-documentation
[15:10:39] <lu_zero> you'd notice that the oh-so-praised cmake is getting the same usage faults
[15:11:00] <lu_zero> (not to mention it's share of upstream-provided faults)
[15:11:21] <Kovensky> the only thing I like about cmake is the `make` output format
[15:11:38] <Kovensky> to this day I still have not figured out how to enable/disable features on a cmake-based build without resorting to the GUI
[15:11:58] <Kovensky> and their CMakeLists syntax is terrible ;_;
[15:12:15] <ohsix> theres an ncurses thing to poke at it
[15:12:21] <ohsix> it's all terrible
[15:13:03] <Kovensky> 12:12.15 ohsix: theres an ncurses thing to poke at it <-- which is a GUI, just no clicky
[15:13:53] <ohsix> clicks work w/ncurses here ;D
[15:25:19] <lu_zero> still the point remains...
[15:28:02] <Kovensky> you also have to hope the script supports optional stuff
[15:28:13] <Kovensky> it's not almost straightforward like on autoconf
[15:28:54] <Kovensky> I have tried maintaining a cmake build system for ffmpegsource, ended giving up and switching to autotools ._.
[15:28:55] <mru> build systems shouldn't need a gui
[15:29:17] <mru> the kernel menuconfig is another matter
[15:29:20] <Kovensky> autotools-based systems are AFAIK the only ones that are simple to cross compile
[15:29:32] <mru> that's a gui for configuring the build, not for configuring the build system
[15:29:45] <mru> Kovensky: you're forgetting the ffmpeg one
[15:29:47] <Kovensky> just give a --host=<target triplet> and a script with decentish tests will work without any further tweaking
[15:30:20] <Kovensky> mru: I don't count the ffmpeg one due to how you use pkgconfig
[15:30:21] <mru> unless libtool decides to put -L/usr/lib in every link command
[15:30:31] <mru> Kovensky: you mean not using it?
[15:30:54] <Kovensky> no, I mean having "pkg-config" hardcoded in the script with no means to change other than manual patching
[15:31:00] <Sean_McG> /usr/lib is typically a default search path for gcc, no?
[15:31:07] <Kovensky> Sean_McG: not if you have a cross-compiler
[15:31:10] <mru> Sean_McG: not when cross-compiling
[15:31:14] <Sean_McG> ah
[15:31:47] <Kovensky> it however is a default search path for pkg-config, and it will find packages on /usr/lib unless you either mess with the PKG_CONFIG_PATH envvar (NOT safe, for it will fallback to the default path if the package it looks for isn't on PKG_CONFIG_PATH), or to have a pkg-config build with a different builtin search path
[15:32:34] <Kovensky> pkg-config however does not use autoconf properly and doesn't respect --sysroot, you need to use its own custom flag and need to give the target triplet prefix to the exe "manually" with another custom flag, but if you make such a pkg-config it works without issues as long as you prefix it with the triplet
[15:33:18] <mru> sound to me like the problem is pkgconfig
[15:33:20] <Kovensky> which is how you get -L/usr/lib in your cross compiles
[15:33:27] <mru> especially since it doesn't actually solve any problem
[15:33:33] <mru> Kovensky: that's one way to get -L/usr/lib
[15:33:45] <mru> sometimes libtool decides to hardcode it into every link command
[15:34:13] <mru> the only workaround is patching the libtool.sh included in the package
[15:34:15] <ohsix> oh, that old saw
[15:34:47] <Kovensky> 12:33.27 mru: especially since it doesn't actually solve any problem <-- yes it does; it makes it trivial for you to get CFLAGS, LDFLAGS and LIBS (even though it does it wrong and just returns LIBS, and autotools' pkgconfig wrapper calls LIBS "LDFLAGS" but you have to assign to LIBS) without needing custom code for each package you want to test / having each package have to roll their own $package-config script
[15:35:17] <mru> properly written libs don't need any flags
[15:35:20] <mru> other than -lname
[15:35:29] <Kovensky> unless it isn't a shared library
[15:35:37] <mru> there are better ways to fix that
[15:35:52] <lu_zero> btw pkgconfig had been fixed properly with the current version...
[15:35:58] <ohsix> you need to put all the dependent libs in there to aboid the overlinking stuff
[15:36:04] <Kovensky> lu_zero: as in it respects --target and --sysroot?
[15:36:14] <mru> with gnu ld one way is to make libfoo.a not an actual archive but a linker script pointing to all the required bits
[15:36:27] <Kovensky> mru: keyword "gnu ld"
[15:36:49] <mru> most pkgconfig scripts return gnu-only flags anyway
[15:36:49] <Kovensky> non-GNU-based systems obviously won't have gnu ld, or if they have they won't for long since everyone else is betting on clang
[15:36:51] <mru> so there's no difference
[15:36:52] <kshishkov> why that reminds me of libtool?
[15:37:14] <Kovensky> and as kshishkov says, it is awfully reminiscent of .la files if you do it like that
[15:37:16] <mru> I'm just saying a solution already exists
[15:37:26] <mru> it could be promoted as the preferred way
[15:37:51] <mru> Kovensky: except it doesn't need a separate hell-script to parse them
[15:38:17] <mru> a nicer solution would be put a special file in the .a listing the dependencies
[15:38:21] <ohsix> distros have started running with gold
[15:38:25] <mru> and encourage linkers to look at that
[15:38:29] <Kovensky> I just think we should try and use the current widespread solution "properly", even if imperfect, and push for something better on appropriate discussion places other than code
[15:38:32] <mru> similar to the DT_NEEDED entries in elf files
[15:38:53] <twnqx> with higher precison than "codec frame"
[15:38:59] <twnqx> argh, wrong window
[15:39:12] * Kovensky resamples twnqx
[15:39:31] * twnqx compresses Kovensky lossy
[15:39:40] <Kovensky> what bitrate?
[15:39:48] <twnqx> mh
[15:39:55] <twnqx> 16kbit?
[15:40:05] <Kovensky> hm, still enough for IRC
[15:40:16] <Kovensky> your lossy codec does have PCM blocks doesn't it?
[15:40:19] <CIA-38> ffmpeg: Vitor Sessak <vitor1001 at gmail.com> master * r3af1fe829e ffmpeg/libavcodec/ppc/dsputil_altivec.c:
[15:40:19] <CIA-38> ffmpeg: Fix overread in altivec DSP function sad16
[15:40:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:08:53] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * ra8f0814a74 ffmpeg/ (10 files in 2 dirs): (log message trimmed)
[16:08:53] <CIA-38> ffmpeg: doc: modify style for texi2html 1.78+
[16:08:53] <CIA-38> ffmpeg: The generated HTML files are similar to the ones generated with
[16:08:53] <CIA-38> ffmpeg: texi2html 1.56k used on the website.
[16:08:53] <CIA-38> ffmpeg: Tested with texi2html 1.78 and 5.0. 1.78 is the minimal recommended
[16:08:54] <CIA-38> ffmpeg: version.
[16:08:55] <CIA-38> ffmpeg: The removed @sp from the titlepage section were ignored until
[16:48:52] <uau> speaking of pkg-config, i needed to do some fixes to the generated .pc files  for the mplayer-build repo
[16:48:59] <uau> those should probably be applied to upstream ffmpeg
[16:49:18] <mru> send a patch
[16:49:51] <lu_zero> the mplayer-build repo would use something like an uninstalled variant isn't it?
[16:50:14] <uau> http://repo.or.cz/w/FFMpeg-mirror/mplayer-patches.git/commitdiff/65e612b5943fe79a6aaf83c0f48a1e4a0f739ffc?hp=0d0f1bc11ec7c8f81a61c1fa4a6bc0048ad10f30 <- those are current differents, the configure ones are relevant to upstream
[16:50:31] <uau> lu_zero: it does an install to an internal dir
[16:50:59] <uau> the configure changes remaining in the current dir are changing optimization level from -O3 to -O2
[16:51:40] <mru> why do you make that change?
[16:51:46] <mru> not that I'm necessarily against it
[16:51:46] <uau> and the pkg-config fixes (basically adding missing dependencies - libm for a couple of cases, and a libavutil dependency for libpostproc)
[16:52:01] <uau> -O2 was consistently faster than -O3 on new gcc versions in my tests
[16:52:30] <uau> IIRC (though it's been a while) the main reason was that -O3 enabled various vectorization code
[16:52:32] <mru> which gcc version?
[16:52:47] <mru> we disable the vectorization separately
[16:52:48] <uau> i think i tested with early 4.4 back then, not 100% sure
[16:52:52] <mru> 4.4 is terrible
[16:53:03] <mru> 4.5 should be much better
[16:53:09] <mru> 4.3 too
[16:55:12] <mru> uau: what's with the depflags changes?
[16:56:20] <uau> hmm yes there was that one too, basically it's adding -MP to make rebuild failures less likely
[16:56:32] <mru> isn't that already fixed?
[16:57:21] <uau> is it? i haven't checked whether there have been changes - is there something in the upstream version which would prevent make failures due to missing dependencies now?
[16:57:35] <mru> yes
[16:58:51] <mru> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=11d788cadef7454bdb1ff43d73efbcaf33a4b01f
[16:59:08] <mru> that has the advantage of working with all compilers
[16:59:49] <uau> ok
[17:09:00] <uau> mru: i tested compiling mplayer-build with -O3 instead of -O2 (gcc 4.4.5 from current debian unstable), it made the binary 1.3 MB bigger and 2% slower in a h264 test
[17:09:26] <uau> build time is also slower
[17:09:29] <mru> as I said, 4.4 sucks
[17:09:46] <mru> if you have time, please try 4.5 as well
[17:09:58] <mru> we might want to make that flag version-dependent
[17:10:02] <Sean_McG> aye, do yourself a favour and build yourself a copy of 4.5.2 if there aren't any debs available for it
[17:10:20] <lu_zero> uau gcc-4.5.2 is somehow nicer (and got a plethora of fixes from 4.5.0)
[17:10:39] <Sean_McG> yeah, I helped fix up some of the Solaris bugs with 4.5.2 ^^;
[17:10:49] <Sean_McG> errr 4.5.1 that made it in to .2
[17:11:07] <uau> i'll test with debian's gcc 4.5.2
[17:11:25] <mru> thanks
[17:11:35] <Sean_McG> 4.6.0 will probably be even nicer, once we get rid of all these P1 & P2 bug reports
[17:12:00] <mru> Sean_McG: any idea about the fate failures with 4.6?
[17:12:16] <mru> the dct test is most curious
[17:12:26] <mru> half the output values have the wrong sign
[17:12:33] <Sean_McG> mru: I haven't tried it... but I'd be glad to help
[17:13:02] <lu_zero> Sean_McG: btw they backed from the gcc-4.6-all-c++ idea?
[17:13:16] <mru> some of the failures might be ffmpeg bugs of course
[17:13:26] <mru> if gcc got more aggressive with aliasing or something
[17:13:30] <Sean_McG> lu_zero: I think someone realized it was more work that it was worth
[17:13:45] <Sean_McG> lu_zero: and there are a number of dup bugzilla reports saying "c++ sucks, fix it"
[17:16:06] <mru> and here I was hoping they'd spend the next release cycle converting all code to c++, giving clang et al time to catch up
[17:16:22] <lu_zero> they might spend 1/2 the time to rationalize better the ancient bits they would had touched w/out changing it
[17:16:24] <uau> not much difference between the gcc versions at -O3
[17:16:36] <uau> same speed, 441 kB smaller binary for 4.5
[17:16:52] <mru> on arm 4.4 is 25% worse than 4.3 or 4.5
[17:16:55] <Sean_McG> binary size improvement is nice
[17:18:37] <Sean_McG> mru: yeah I'm just thinking...you could be right about aliasing in 4.6, but do any of the fate.ffmpeg.org machines use 4.6?
[17:18:56] <mru> the ones that say so
[17:19:19] <mru> click the compiler heading to sort by compiler
[17:19:23] <Sean_McG> ah, right
[17:21:31] <uau> with -O2 gcc 4.5 is 139 kB smaller binary but 1% slower than 4.4 (i think "random" variation in compile results is at least 1% for that test though)
[17:21:39] <uau> still faster than -O3
[17:22:25] <Sean_McG> OK well I'mma go have late breakfast
[17:22:26] <mru> how much difference between -O2 and -O3?
[17:22:40] <Sean_McG> best of luck folks... I'll poke at this stuff late
[17:22:45] <Sean_McG> s/late/later/
[17:22:51] <uau> mru; about 1%
[17:23:43] <uau> gcc 4.4 -O2  - - 1% --  gcc 4.5 -O2  - - 1% --  either -O3
[17:25:20] <lu_zero> uau: using -Os ?
[17:25:39] <uau> guess i could test that too
[17:28:02] <uau> with gcc 4.5 that dropped binary size from 10.5 to 9.7 MB, but it's clearly slower
[17:28:13] <lu_zero> (sorry to making you do another run)
[17:28:36] <ubitux> http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/072/7269/7269t1.jpg
[17:28:41] <mru> how are you measuring the speed btw?
[17:28:48] <ubitux> not sure it's up-to-date though
[17:29:51] <mru> ubitux: the problem is that all those optimisations are theoretically good, but in gcc they tend to have rather random interactions
[17:30:03] <mru> often resulting in code size blowing up or similar
[17:30:35] <ubitux> ok
[17:33:21] <uau> mru: measured some times the overall time it took to run a particular command
[17:35:04] <jannau> lu_zero: looks like you need a more elaborate sed command
[17:35:12] <lu_zero> wasn't enough?
[17:35:51] <jannau> renaming ff_dprintf_ref() to  ff_av_dlog_ref() seems to be unintended
[17:36:22] <mru> make sense to me
[17:36:30] <mru> look inside those functions
[17:37:19] <mru> but maybe losing the av_ on those would be appropriate
[17:37:26] <lu_zero> the resulting name might drop the av_
[17:37:30] <jannau> yes, still a strange name
[17:37:42] <jannau> ff_dbglog_ref might be better
[17:38:02] <mru> what's a db-glog?
[17:38:28] <jannau> bikesheds
[17:38:35] <kshishkov> db-glögg?
[17:40:06] <Sean_McG> are there instructions for setting up fate locally?
[17:40:19] <mru> there are, somewhere
[17:40:42] <jannau> http://wiki.multimedia.cx/index.php?title=Running_FATE
[17:40:58] <mru> I suppose you mean how to run it automatically and send reports
[17:41:02] <Sean_McG> aye
[17:41:15] <Sean_McG> I've got Solaris x86 and SPARC, if it's useful
[17:41:36] <Sean_McG> jannau: cheers for the link
[17:42:01] <mru> if you have something not already on the list, your contribution would be appreciated
[17:42:34] <Sean_McG> cool
[17:43:18] <mmu> hmm how big is it btw ?
[17:43:26] <mru> how big is what?
[17:44:39] <mmu> requirements for FATE
[17:46:39] <mru> test samples are 400M
[17:47:37] <kshishkov> and some RAM of course
[17:48:05] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rd461a47317 ffmpeg/libavcodec/ (arm/asm-offsets.h arm/mpegvideo_neon.S mpegvideo.h):
[17:48:05] <CIA-38> ffmpeg: Rearrange MpegEncContext to simplify access from asm
[17:48:05] <CIA-38> ffmpeg: This moves the fields needed by asm near the top, before any
[17:48:05] <CIA-38> ffmpeg: structs or other members which complicate the offset calculation.
[17:48:05] <CIA-38> ffmpeg: Modifying other structs will no longer require updating the offsets,
[17:48:06] <CIA-38> ffmpeg: and the asm code is slightly simpler due to the smaller offsets.
[17:48:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:48:09] <mru> kshishkov: blame gcc for that
[17:48:23] <mru> running the tests needs only 64MB
[17:49:00] <kshishkov> mru: still, that's whole 64MB RAM!
[17:49:22] <ohsix> i ated the whole thing
[17:49:54] <lu_zero> the WHOLE!!!!
[17:49:58] <lu_zero> uhm
[17:50:02] <lu_zero> which thing?
[17:50:53] <kshishkov> probably RAM
[17:51:21] <kshishkov> there are so many things that eat RAM
[17:51:32] <kshishkov> including GCC compiling motion_est.c
[17:52:35] <ohsix> thankfully it eventually regurgitates it
[17:53:10] <kshishkov> that was my primary reason to get 128MB RAM in addition to 64MB I had then
[17:53:21] <mru> no, but when it dies, the kernel cuts the ram from the dead carcass
[17:59:10] <jannau> mru or kshishkov: please join #ffmpeg and kick art|st
[17:59:54] <mru> now you can do it
[18:00:00] <jannau> thanks
[18:00:04] <elenril> too late
[18:00:16] <jannau> he left just seconds after I got op
[18:00:16] <mru> he can still do it next time
[18:00:26] <mru> got scared?
[18:00:47] <elenril> he looked too insane for that
[18:00:57] * kshishkov does not care about #ffmpeg
[18:02:00] <elenril> why are you op there then?
[18:02:20] <lu_zero> too late =P
[18:03:06] <jannau> he isn't, only in access list. probably from before we moved to #ffmpeg-devel
[18:04:09] <kshishkov> indeed
[18:10:57] <CIA-38> ffmpeg: Vitor Sessak <vitor1001 at gmail.com> master * re0eb963aaa ffmpeg/libavcodec/alsdec.c:
[18:10:57] <CIA-38> ffmpeg: Fix memory leak in ALS decoder in big endian systems
[18:10:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:11:14] <mru> jannau: why didn't patchwork find the patch for that commit?
[18:25:36] <Jumpyshoes> https://roundup.ffmpeg.org/issue2524 this was fixed in http://git.ffmpeg.org/?p=ffmpeg.git;a=commit;h=4be170c9371dfd3ae07a348b449002fc1d2b70e4 , how should i close it?
[18:40:33] <DonDiego> peloverde, peloverde_, aac ltp patch on -devel...
[18:43:36] <jannau> mru: I don't know. straight applied from patchwork?
[18:43:54] <mru> patch from ml but no changes
[18:43:59] <mru> it usually works
[18:44:05] <mru> two patches today failed, both from vitor
[18:48:54] <jannau> I've also seen mismatches from patches sent as attachment. but the als memleak patch is so simple I can't image how that could mismatch
[18:51:48] <Sean_McG> OK cool I'm done rsync'ing... need to wait for latest gcc to finish build & test
[18:59:39] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r243f8241db ffmpeg/libavcodec/libfaac.c:
[18:59:39] <CIA-38> ffmpeg: Flush final frames in libfaac encoder.
[18:59:39] <CIA-38> ffmpeg: Gives decoded output identical in length to faac commandline encoder.
[18:59:39] <CIA-38> ffmpeg: Fixes Issue 670.
[18:59:39] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[19:01:29] <lu_zero> is Hervé  on irc?
[19:02:01] <kshishkov> yep, {V}
[19:02:08] <{V}> I am
[19:02:28] <lu_zero> I was wondering
[19:03:52] <{V}> okay :)
[19:06:37] <mmu> libavfilter/avfilter.c:208: warning: 'ff_get_ref_perms_string' defined but not used
[19:06:40] <mmu> OMG a warning
[19:06:51] <lu_zero> uh
[19:07:06] <mru> the function is apparently never used
[19:07:16] <mru> or perhaps only under #ifdef DEBUG
[19:08:01] <mmu> just testing if it builds in Haiku
[19:08:19] <mru> cool, let us know of any problems
[19:08:26] <mru> preferably by sending patches
[19:08:35] <mru> mmu: btw, are you coming to fosdem?
[19:13:23] <mmu> ok so far, lotsa warnings
[19:13:29] <mmu> mru yes, got my train tickets
[19:13:35] <mmu> trolls ahead :)
[19:14:01] <mmu> lots of "is deprecated" warnings
[19:14:03] <mmu> ?
[19:14:34] <jannau> ignore warnings for now
[19:19:14] <mmu> I know, just kidding
[19:19:19] <mmu> still building
[19:26:00] <mmu> dear, that's almost as long as building the whole of Haiku itself
[19:26:36] <spaam> maybe you build it in a loop?
[19:26:43] <mmu> lol
[19:28:10] <lu_zero> EFL 1.0 released!
[19:28:11] <lu_zero> wow
[19:29:46] <spaam> Nice
[19:29:51] <spaam> about time.
[19:33:03] <mmu_man> EFL ?
[19:33:13] <mmu_man> the enlightenment stuff ?
[19:33:32] <mmu_man> how many decades have they been worked on ? :p
[19:33:47] <lu_zero> not sure
[19:33:51] <kshishkov> who asks?
[19:35:09] <kierank> really
[19:36:32] * kshishkov points to Haiku 1.0
[19:36:56] <spaam> kshishkov++
[19:37:16] * kshishkov is also proud of FFmpeg 1.0
[19:37:20] <spaam> kshishkov: do you think that ffmpeg will became 1.0 before haiku?
[19:38:07] <lu_zero> spaam: do not give him ideas
[19:38:37] <lu_zero> spaam: there is a roadmap item for 0.8 already
[19:38:55] <spaam> where?
[19:39:14] <lu_zero> it was discussed with siretart and Flameeyes
[19:39:22] <lu_zero> here
[19:40:12] <spaam> ok :)
[19:42:17] <mmu> kshishkov we're discussing beta1 :p
[19:42:27] <mmu> plus it's a whole OS, not just a toolkit :p
[19:42:37] <kshishkov> mmu: M$ or Google beta?
[19:43:06] <kshishkov> mmu: and yes, you are developing extremely fast (compared to GNU Hurd)
[19:43:24] <mmu> M$ releases are still beta quality, while Google releases "beta" stuff just to avoid doing support
[19:43:30] <mmu> eh
[19:43:31] <Sean_McG> Hurd is almost as vaporware as Duke Nukem Forever
[19:43:40] <kshishkov> ahem
[19:43:45] <mmu> I heard they were again redoing it all
[19:43:54] <kshishkov> and they have GNU Hurd NG
[19:43:57] <mmu> I Hurd this, I swear :p
[19:44:05] <Sean_McG> bad pun
[19:44:07] <Sean_McG> no cookie
[19:44:22] <siretart> pffft, FFmpeg 1.0
[19:45:12] <Sean_McG> let's release it tomorrrow ;)
[19:45:14] <spaam> when -mt will be in ffmpeg. will we change the name to ffmpeg-ng? :)
[19:45:56] <spaam> mmu: what scm are you guys using at haiku? :)
[19:46:36] <mmu> svn
[19:47:03] <mmu> there has been talks about git but well :p
[19:47:17] <spaam> ok :)
[19:47:27] <mmu> LD      ffmpeg_g
[19:47:32] <mmu> .. wait ..
[19:47:58] <spaam> *drums*
[19:48:09] <mmu> .. wait ..
[19:48:15] <Sean_McG> *trumpet fanfare*
[19:48:16] <spaam> *more drums*
[19:48:26] <mmu> "what happens now ?"
[19:48:37] <mmu> "death, slavery, more slavery, more death..."
[19:49:03] <mmu> (SG1)
[19:49:15] <spaam> SG1?
[19:49:19] <mmu> how many gigs do I need to link this ?
[19:49:19] <Sean_McG> CAKE.
[19:49:36] <mru> the cake is a lie
[19:49:42] <Sean_McG> yes, yes it is.
[19:49:47] <mmu> http://gateworld.net/movies/03.shtml
[19:52:02] <kshishkov> mmu: can you benchmark it against "emerge world"?
[19:52:39] <mmu> hmm CP takes forever as well :)
[19:52:53] <mmu> bash: emerge: command not found
[19:52:56] <kshishkov> damn, don't use floopies for source!
[19:53:19] <mmu> reminsd me I still have to finish our floppy driver
[19:53:31] <Sean_McG> people still use those things?!%^$#&
[19:53:36] <mmu> strip...
[19:53:46] <mmu> couldn't we tell strip to output to a different file ?
[19:53:49] <mmu> that'd avoid cp
[19:53:49] <spaam> Sean_McG: why not?
[19:54:03] <mmu> -o :)
[19:54:04] <Sean_McG> spaam: seriously... I think it's been 5 years since I've used one
[19:54:05] <spaam> mmu: disable striP? :)
[19:54:55] <mmu_man>         $(CP) $< $@
[19:54:55] <mmu_man>         $(STRIP) $@
[19:55:00] <mmu_man> WTF
[19:55:01] <spaam> mmu:  --disable-stripping
[19:55:23] <mmu_man> ah it set STRIP=true
[19:55:26] <mmu_man> bleh
[20:01:06] <Sean_McG> wow, 3PM already
[20:01:12] * Sean_McG heads out to anime club
[20:03:54] <mmu_mmu> mmu mmu_man ;S
[20:06:04] <Blackdown> hello
[20:07:17] <mmu> who's that immitator ?
[20:08:41] <Blackdown> ?
[20:09:00] <mmu> [21:04] *** mmu_mmu (revol at 0x86.net) has quit IRC (Client Quit)
[20:18:44] <spaam> mmu: using the same nick and user like you.. can it be you? :o
[20:19:52] <mmu> I wouldn't advertise for int<sub>e</sub>l
[20:21:01] <mmu> FFmpeg version git-d461a47, Copyright (c) 2000-2011 the FFmpeg developers
[20:21:03] <mmu> \o/
[20:21:10] <spaam> Nice
[20:21:16] <spaam> run make fate !
[20:25:09] <Vitor1001> BBB: The PPC VP8 bug can be reproduced in Mans' box using valgrind
[20:27:16] <BBB> Vitor1001: can you fix it? I think my patch that I sent to the ML fixes it, but apparently it doesn't do it completely
[20:27:24] <BBB> if you can tell me at least where it fails
[20:27:30] <BBB> the valgrind so far wasn't very good
[20:29:21] <Vitor1001> BBB: Which patch?
[20:29:36] <Vitor1001> I only find the old version, that breaks vp8 fate tests
[20:29:50] <BBB> http://ffmpeg.pastebin.com/emHDyKJU
[20:29:56] <Vitor1001> For me, valgrind points to line 59, for off==0
[20:31:11] <BBB> in which function?
[20:31:25] <BBB> is it a hxv4 function?
[20:31:37] <BBB> where x is either 4 or 6
[20:31:38] <Vitor1001> put_vp8_epel_h_altivec_core()
[20:31:54] <BBB> caller of that function?
[20:32:02] <BBB> core is called by hx, vx or hxvx functions
[20:32:07] <Vitor1001> Wait, there is something wrong
[20:32:14] <Vitor1001> put_vp8_epel4_h4_altivec()
[20:32:15] <Vitor1001> called by
[20:32:22] <Vitor1001> put_vp8_epel4_h4v4_altivec()
[20:32:30] <BBB> yes, my patch should solve that
[20:32:36] <Vitor1001> Ok, let me see
[20:32:45] <Vitor1001> It takes a lot of time to recompile
[20:32:55] <Vitor1001> I should not have make a git pull :-p
[20:33:12] <Vitor1001> I'll tell you in ~20 mins
[20:33:14] <BBB> ok
[20:33:22] <BBB> actually, my patch is wrong I think
[20:33:30] <BBB> let me fix it and give you a second one in case the first one doesn't fix it
[20:33:30] <BBB> ok?
[20:33:40] <Vitor1001> ok
[20:33:53] <Vitor1001> Have to wait the compilation anyway
[20:34:25] <BBB> http://ffmpeg.pastebin.com/Xe2wRZgV
[20:38:19] <mru> Vitor1001: are you using my ppc?
[20:38:27] <Vitor1001> mru: yep
[20:38:40] <mru> if you're brave you can use distcc
[20:38:45] <mru> specify the full compiler name
[20:38:50] <mru> my i7 will help out
[20:39:03] <Vitor1001> You mean cross-compiling?
[20:39:08] <mru> yes
[20:39:16] <mru> it usually works
[20:39:27] <Vitor1001> And it can auto-detect that it would be a cross-compilation?
[20:39:54] <lu_zero> mru: if you put the wrapper in the ppc host it should always work
[20:39:57] <mru> if you tell it --cc=powerpc-...gcc it will work
[20:41:53] <Blackdown> i'm back
[20:42:46] <Blackdown> So I have a question, it is possible to display the percentage of a video during a conversion?
[20:42:50] <Blackdown> with php
[20:43:04] <mru> wrong channel
[20:43:05] <DonDiego> Blackdown: #ffmpeg
[20:43:21] <Blackdown> okay, sorry :h
[20:45:51] <Vitor1001> BBB: invalid reads remains :-'
[20:46:14] <BBB> Vitor1001: first or second patch?
[20:46:20] <Vitor1001> Second
[20:46:30] <BBB> does it fix the crash?
[20:47:05] <Vitor1001> BBB: there is no crash in mans' box
[20:47:10] <BBB> hm...
[20:47:13] <Vitor1001> just valgrind invalid read errors
[20:47:29] <Vitor1001> But, well, OS is free to coredump in those cases
[20:47:43] <mru> it would crash if the memory mapping were a bit tighter
[20:47:52] <mru> it just happens to not be near a page boundary here
[20:48:38] <Vitor1001> mru: Indeed, but crashing would be a sane behavior
[20:48:39] <BBB> Vitor1001: is the backtrace of the invalid reads identical?
[20:49:04] <BBB> put_vp8_epel__h4/6v4_altivec() calling into v4?
[20:49:09] <BBB> (calling into core, ...)
[20:49:13] <mru> reading outside explicitly allocated memory may cause any behaviour
[20:49:26] <Vitor1001> at least the first, yes
[20:51:24] <mru> requiring any access outside allocated memory to trap would make everything as slow as valgrind
[20:53:24] <Vitor1001> mru: I know. But I hate when people say a system is buggy because it segfaults for invalid reads
[20:53:35] <mru> oh, that I agree with
[20:55:16] <BBB>     a = vec_ld((off)-2,    src); ...
[20:55:19] <BBB> that looks buggy to me
[20:55:51] <mru> that's wrong for h4
[20:55:54] <mru> should be -1
[20:56:13] <mru> if the -2 is what I think it is
[20:56:25] <BBB> exactly
[20:57:14] <BBB> although the coefficients in the multiply table are probably set up so that it expects the data to be in such a position, i.e. I don't know how to fix this
[20:57:21] <BBB> I just know this looks suspicious
[20:59:07] <lu_zero> BBB: wait for me to have back a functional X ^^;
[20:59:12] * lu_zero curses libmount
[21:11:15] * Kovensky curses X
[21:11:28] <mru> X is nice
[21:11:47] <mru> although the fd.o people are doing their best to sabotage it
[21:12:15] <spaam> fd.o?
[21:12:21] <mru> freedesktop.org
[21:12:41] <spaam> how do they sabotage it?
[21:12:44] <mru> the whole "modular X" thing was the first disaster
[21:13:06] <mru> they broke it into a million tiny pieces, each with their own autohell scripts
[21:13:11] <spaam> why ? i thought you like that kind of things.
[21:13:15] <mru> so build times exploded
[21:13:28] <mru> and you still have to match the versions carefully
[21:13:46] <mru> only now the working combinations don't even have the same version numbers
[21:15:01] <lu_zero> mru: wait
[21:15:08] <lu_zero> the build time got _reduced_
[21:15:14] <lu_zero> a LOT
[21:15:35] <lu_zero> and keep in mind that autotools made a large step in the right direction
[21:15:40] <mru> lu_zero: it spends 95% of the time in autoconf scripts now
[21:15:42] <mru> it didn't before
[21:16:01] <lu_zero> before 99% of the time was spent processing imakefile
[21:16:10] <mru> lies
[21:16:25] <lu_zero> mru: I started messing with X in gentoo
[21:16:42] <mru> and you can't deny the compatibility hell between the modules now
[21:16:43] <lu_zero> and even before gentoo I was building X myself
[21:17:00] <lu_zero> there is _lot_ that could be improved
[21:17:16] <mru> it's also much more unstable in general than it used to be
[21:17:27] <mru> simple things like keyboard drivers don't work right anymore
[21:17:29] <lu_zero> but between the current situation and the monolith I'd pick that one
[21:18:03] <mru> they should make it impossible to build mismatched versions
[21:18:04] <lu_zero> mru: only because you had the bad idea to enable hal or udev ^^
[21:18:09] <mru> I did not
[21:18:17] <lu_zero> then is strange
[21:18:27] <lu_zero> hal was a major shortcoming
[21:18:29] <mru> I have hal and dbus in my package.mask
[21:18:57] <mru> some time ago now, they broke hotplugging usb input devices
[21:19:01] <lu_zero> and udev support is largely better but still I'm not comfortable with it
[21:19:26] <mru> and every time I start X, I have to manually enable auto-repeat on some keys
[21:19:36] <mru> which ones changes with each upgrade
[21:19:47] <mru> it's usually one or more arrow keys
[21:19:52] <mru> sometimes a random letter
[21:20:06] <lu_zero> strange and stranger
[21:20:06] <mru> and xmodmap doesn't work reliably
[21:20:27] <mru> when run from my .xinitrc only parts of the settings take effect
[21:20:35] <mru> and it spits an ugly error
[21:20:41] <lu_zero> which error?
[21:20:45] <mru> forgot
[21:20:59] <mru> if I run the same command from xterm immediately after, it works
[21:21:16] <lu_zero> might be worth debugging it
[21:21:18] <mru> these things never happened before
[21:21:31] <lu_zero> well some did differently
[21:21:44] <lu_zero> they plugged a lots of old bugs
[21:21:49] <mru> all the things I said now are regressions
[21:21:55] <lu_zero> but they added a lot of brand new
[21:21:55] <mru> blatant ones
[21:22:04] <lu_zero> mru: report them
[21:22:18] <mru> they used to tell me to enable hal
[21:22:21] <mru> which I refuse
[21:22:25] <lu_zero> for my usage right now I'm quite happy about X
[21:22:37] <lu_zero> mru: who's the dick?
[21:22:41] <mru> don't remember
[21:23:16] <lu_zero> (since probably it might be the same who wrote the hal support breaking what was working relatively ok...)
[21:23:26] <mru> I always got the impression they don't care about bugs that don't affect gnome/kde on ubuntu with default settings
[21:23:35] <lu_zero> anyway the hal support now is gone...
[21:23:39] <mru> so I've seen
[21:23:55] <mru> my X setup is a bit unusual in some ways
[21:24:02] <mru> like multihead without xinerama
[21:24:40] <mru> I had to install a fake libxinerama to work around the real one telling apps the display is 3x bigger than it is
[21:24:49] <mru> 3 heads
[21:25:08] <lu_zero> xrandr shouldn't let you do that now?
[21:26:34] <saintd3v> I started to setup up xinerama, when i added my second monitor. then the next day i realized Xrandr could do it automatically for me.
[21:26:36] <mru> when I have a solution, I tend to forget about the problem after a while
[21:28:08] <mru> another weird thing, don't know where to put the blame for this one though:
[21:28:20] <mru> copy and paste from xpdf to xemacs doesn't work anymore
[21:28:57] <mru> I can open a curses window in a terminal and paste it there
[21:30:56] <lu_zero> do you have a clipboard utility in xemacs?
[21:31:04] <mru> huh?
[21:31:18] <mru> middle-click always pastes the current X selection
[21:31:26] <mru> it works with all other apps
[21:31:31] <mru> just not that pair
[21:31:50] <lu_zero> so xpdf -> world^xemacs is ok?
[21:31:56] <mru> yes
[21:32:19] <mru> and anything but xpdf -> xemacs is fine
[21:32:26] <lu_zero> world^xpdf -> xemacs works as well
[21:33:28] <lu_zero> looks like xpdf expresses the buffer in some way (image first, text later?) and xemacs isn't understanding it
[21:33:46] <mru> that's not it
[21:34:06] <mru> xemacs pastes whatever the previous selection was
[21:34:12] <mru> as if xpdf had never been there at all
[21:34:33] <lu_zero> X has a number of paste buffers
[21:34:36] <mru> I know
[21:34:50] <lu_zero> I wonder why xpdf fills them differently now
[21:35:06] <mru> xpdf apparently doesn't update the one xemacs looks at
[21:35:34] <lu_zero> install a clipboard manager to figure who's stupid
[21:35:47] <mru> clipboard managers are stupid
[21:36:23] <lu_zero> clipboard manager at least should tell which buffer got touched by who
[21:36:36] <mru> if it can be trusted
[21:36:40] <lu_zero> otherwise evince or epdf might be an alternative
[21:36:45] <mru> tried those
[21:36:46] <mru> they suck
[21:36:50] <lu_zero> uh?
[21:37:03] <mru> as in don't work nearly as well as xpdf
[21:37:21] <lu_zero> evince renders relatively better than xpdf (and it's the reason I moved to it)
[21:37:53] <mru> but the UI is unusable
[21:37:55] <lu_zero> epdfview should be smaller
[21:38:03] <lu_zero> but I didn't try it
[21:38:43] <mru> hmm, emerge evince wants to pull in some gnome stuff I've masked
[21:38:53] <mru> I don't remember why I masked it, but I'm sure there was a reason
[21:39:57] <lu_zero> check epdfview
[21:40:43] <lu_zero> seems gnome-less
[21:40:50] * lu_zero checks as well
[21:42:29] * mru tries epdfview
[21:42:44] <mru> first problem: it opens showing only 1/8 of the page
[21:42:50] <mru> or maybe that's 1/4
[21:42:52] <mru> whatever
[21:43:29] <mru> and no way to change that in preferences (which there aren't any)
[21:44:57] <mru> minimum size w/o scroll bars has a huge border around the page
[21:46:06] <mru> no selection possible at all
[21:47:15] * mru uninstalls
[21:47:20] <mru> worthless pile of crap
[21:50:33] <lu_zero> too barebone I guess
[21:51:33] <BBB> I thought xpdf was quite good, why is that out of the question?
[21:52:12] <lu_zero> BBB: xpdf has problems
[21:52:33] <lu_zero> evince has icky deps to be gentle
[21:52:42] <lu_zero> (but works for me)
[21:52:52] <lu_zero> epdfview is too barebone
[21:53:47] <spaam> maybe its time for FFpdf!
[21:54:11] <BBB> wasn't evince based on something that is x-only?
[21:55:22] * _av500_ has both evince and okular and prefers adobe
[21:56:27] <lu_zero> xpdf is X only
[21:56:40] <lu_zero> _av500_: you are scaring me
[21:56:45] <_av500_> y?
[21:56:54] <_av500_> i have to read 5000page pdfs all the time
[21:57:12] <_av500_> and those 2 os solutions suck
[21:57:19] <lu_zero> either adobe improved their viewer
[21:57:24] <_av500_> one of em insist to start search from the start alwaysa
[21:57:39] <lu_zero> it was largely inferior to evince
[21:57:51] <lu_zero> not sure about okular
[21:57:54] <_av500_> lu_zero: my i7 handles abode just fine
[21:57:59] <lu_zero> (never used it)
[21:58:05] <_av500_> adobe even
[21:58:31] <kierank> is there no foxit for linux?
[21:59:01] <_av500_> sure is
[21:59:14] <lu_zero> kierank: it's called evince, to the ones that are wondering about Preview, it's called Okular my kde-friends say
[21:59:19] <mmu> _av500_ fix them :p
[21:59:28] <mmu> you can send a patch :)
[21:59:35] <lu_zero> mmu: how's the haiku one btw?
[21:59:35] <_av500_> mmu: no time
[21:59:49] <mmu> BePDF is based on some xpdf backend
[21:59:55] <mmu> needs updates
[22:00:08] <lu_zero> poppler is still there
[22:00:11] <_av500_> its all poppler in the end :)
[22:00:19] <mmu> I think someone built poppler
[22:00:34] <lu_zero> gnupdf is quite initial and since it's gnu you never know
[22:00:35] <_av500_> we shipped poppler based pdf viewer on 240mhz arm9
[22:00:35] <mmu> the lib at least
[22:00:50] <lu_zero> mmu: that's all you need if you have already cairo bindings
[22:01:02] <mmu> _av500_ ah, would go nicely alongside NetSurf :p
[22:01:12] <mmu> lu_zero that's the problem :p
[22:01:44] <lu_zero> mmu: hack the qt backend
[22:01:47] <lu_zero> then
[22:01:50] <lu_zero> or just use it
[22:02:00] <mmu> I think we already have a port of Cairo for FF3 but don't know how much is done
[22:02:03] <mmu> plus it sux
[22:02:14] <lu_zero> the haiku-qt port should be more or less ok?
[22:02:21] <mmu> something that requires adding .5 to the coords to look correct should be trashed
[22:02:32] <mmu> maybe but this sux even more
[22:02:33] <lu_zero> .5?
[22:02:36] <mmu> we want native apps
[22:03:22] <lu_zero> mmu: native as in written in the single language supported by the BeAPI?
[22:03:28] <mmu> I recall seeing somewhere one had to add .5 to some coords with cairo to render some things less blurry
[22:03:38] <mmu> native as in using native controls
[22:03:47] <lu_zero> mmu: that means you have a rounding issue somewhere
[22:03:57] <lu_zero> and it got fixed the ugly way...
[22:04:03] <mmu> not things drawn by some QSkinWhateverItsCalled
[22:04:15] <mru> adobe reader does have the best rendering
[22:04:33] <lu_zero> so they improved it
[22:04:54] <mru> if it weren't for the bloat, the bugs, and the annoying UI, I might use it
[22:05:19] <lu_zero> if weren't for the bloat you'd try the current evince ^^;
[22:05:35] <peloverde> what about evince-gtk?
[22:06:07] <mru> I like the way adobe search gives you a list of all hits
[22:06:10] <mru> very useful
[22:06:59] <kierank> foxit is useful in that you can create your own bookmarks
[22:08:53] <mmu> Preview.app also does
[22:09:02] <mmu> show the matching pages
[22:11:24] <mru> .app, so silly
[22:12:24] <Dark_Shikari> how do I set up git send-email to work?
[22:12:33] <Dark_Shikari> I've never used it for, but it looks convenient
[22:13:15] <pross-au> Dark_Shikari: it is
[22:14:03] <Dark_Shikari> *before
[22:14:31] <pross-au> add [sendemail] block to .git/config
[22:15:46] <pross-au> i have from=, to=, smtpserver=, smtpuser=, thread=true fields set
[22:16:21] <mru> it's useful to set user.email and user.name in the global config
[22:16:45] <pross-au> does it use those too?
[22:17:10] <mru> absent any overrides in the repo config those go in the from header
[22:17:48] <mru> but he probably already has those set
[22:17:55] <mru> or his commits would have bogus author info
[22:19:06] <siretart> is there an mirror of the git on github somewhere?
[22:19:23] <mru> someone was talking about making one
[22:19:33] <mru> don't know if it ever happened
[22:34:34] <jannau> there is now https://github.com/ffmpeg/ffmpeg
[22:34:42] <jannau> not yet auto synced
[22:38:01] <lu_zero> nice =)
[22:38:25] <lu_zero> should we use a sync hook?
[22:39:22] <siretart> hmm. I hoped that https://github.com/blog/626-announcing-svn-support would work on the ffmpeg branch. seems it doesn't
[22:44:39] <lu_zero> oh
[22:44:49] <lu_zero> I'm eventually back to X ^^;
[22:47:31] <lu_zero> {V}: I appreciate your try to make the mediatior, but
[22:48:00] <lu_zero> as you can see there isn't much middle ground
[22:49:24] <mmu> beware the mediator, this medecine killed people
[22:49:56] <{V}> I think there's plenty of middle ground. Michael just doesn't seem to want to budge :)
[22:50:09] <mru> that's the point
[22:50:19] <{V}> yes, I'm starting to see that
[22:52:44] <lu_zero> =\
[22:57:07] <CIA-38> ffmpeg: Luca Barbato <lu_zero at gentoo.org> master * rdfd2a005eb ffmpeg/ (47 files in 4 dirs):
[22:57:07] <CIA-38> ffmpeg: Replace dprintf with av_dlog
[22:57:07] <CIA-38> ffmpeg: dprintf clashes with POSIX.1-2008
[23:02:57] <michaelni> {V}, mru, you guys talk about your own wrong interpretation of my mail i think
[23:03:27] <{V}> michaelni, that's possible.
[23:03:38] <michaelni> did my reply clarify it ?
[23:03:39] <lu_zero> michaelni: I have somebody that is always "misinterpreted"
[23:03:47] <iive> michaelni: this is how perceptual bias works.
[23:03:50] <{V}> michaelni, I'll check in a moment.
[23:04:14] <lu_zero> he's called Silvio Berlusconi
[23:04:36] <michaelni> :)
[23:04:47] <lu_zero> you do not want that I consider you the same as him.
[23:11:39] <kierank> hehe berlusconi
[23:18:30] <j-b> 'morning
[23:19:55] <spaam> j-b: where are you?
[23:20:08] <j-b> Paris, as usual :)
[23:20:20] <kierank> j-b: on x264 time?
[23:20:27] <j-b> being evil, as French people are, what else?
[23:20:32] <j-b> kierank: a bit, yeah :)
[23:20:38] <spaam> j-b: haha.
[23:21:40] <spaam> kierank: all the cool people follow x264 time?
[23:22:00] <kierank> yeah, haven't you heard
[23:23:10] <spaam> i didnt get that note :(
[23:23:20] <mru> then you're not cool
[23:24:46] <j-b> but you can become cool :D
[23:25:17] <spaam> how?
[23:25:40] <mru> sit in the freezer for a while
[23:25:55] <spaam> i thougt i was cool.. in the cool group CDGS with basty, kierank and kshishkov
[23:26:18] <j-b> dress like superman, commit on ffmpeg, and go on tv
[23:26:34] <j-b> then, wake up at 1pm and go to bed at 7am: done.
[23:26:43] <kierank> doing what on tv ;)
[23:28:27] <spaam> then say something cool like " I will commit AVSEQ to FFmpeg! and Måns rulgård going to like me even more!"
[23:28:44] <spaam> *rullgård
[23:33:37] <kierank> what about your amiga port of ffmpeg spaam?
[23:33:57] <j-b> or some bink-related code ?
[23:34:22] <lu_zero> bink-j since bink-b is too easy
[23:37:08] <spaam> thats way kshishkov wont do it
[23:37:21] <kierank> spaam: i don't remember inviting kshishkov to CDGS
[23:38:35] <BBB> hm, vitor left
[23:38:47] <BBB> did we figure out the source of the vp8 ppc hxv4 bug?
[23:39:32] <spaam> kierank: do you want some other guy in the group with us?
[23:40:25] <spaam> BBB: there was some talk about -1.
[23:42:22] <kierank> spaam: dunno
[23:43:24] <spaam> maybe mru ? i know he wants avseq.
[23:45:50] <kierank> mruCDGS
[23:45:59] <kierank> or maybe BBBCDGS
[23:46:04] <spaam> :DDD
[23:46:20] <kierank> or maybe BBB could invert it to BBBcdgs
[23:47:07] <spaam> or bbbCDGS
[23:47:37] * BBB kicks spaam
[23:47:41] <BBB> go sit in a corner, you
[23:48:05] <spaam> BBB: ok :(
[23:48:32] * spaam going to the corner. forever alone :'(
[23:48:46] <mru> spaam: no, you're not alone
[23:48:56] <BBB> bastyCDGS is sitting there also
[23:48:57] <mru> spaam: sacarasc is there too
[23:49:10] <spaam> woho! :D
[23:49:33] <spaam> 2/3 ppl from the CDGS group. nice nice
[23:53:25] <pross-au> u guys are too harsh, wasnt the scene guy a student after all?
[23:53:55] <mru> he was a fossil
[23:54:08] <mru> fossils do not study, they are studied
[23:54:22] <pross-au> so he gamed the gsoc program..
[23:54:38] <mru> I guess he was registered at some university
[23:54:59] <pross-au> lolz
[23:55:40] <kierank> mru: as an exhibit?
[23:56:38] <mru> lu_zero: In file included from /home/mru/src/ffmpeg.dev/libavformat/avio.c:30:
[23:56:41] <mru> /home/mru/src/ffmpeg.dev/libavformat/network.h:69: error: redefinition of 'struct sockaddr_storage'
[23:59:03] <bcoudu> god, let's pray the iphone 5 has both gsm/cdma
[23:59:21] <mru> who cares about iphone?
[23:59:34] <mru> spaam: is it called iFÃ¥n in .se?