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

[irc at mansr.com]

[00:12:05] <ramiro> maybe he's sleep-typing...
[01:04:28] <CIA-1> ffmpeg: michael * r22770 /trunk/libavutil/attributes.h: av_builtin_constant_p()
[01:08:00] <CIA-1> ffmpeg: michael * r22771 /trunk/libavcodec/ (motion_est_template.c motion_est.c):
[01:08:00] <CIA-1> ffmpeg: slice dice, inline and outline cmp()
[01:08:00] <CIA-1> ffmpeg: motion_est.o is now less than half its previous size.
[01:08:00] <CIA-1> ffmpeg: No speedchange meassureable.
[01:10:01] <Dark_Shikari> lol
[01:10:09] <Dark_Shikari> It sounds like michael is reading irc
[01:12:57] <hyc> I wish someone could explain this new read_seek2 API
[01:13:41] <hyc> considering that the patch I posted exactly duplicates the current avformat_seek_file() behavior, and still michael says it results in wrong behavior...
[01:15:17] <CIA-1> ffmpeg: michael * r22772 /trunk/libavcodec/motion_est.c: Move comment that belonged to cmp() back to cmp().
[03:47:02] <pengvado> neural network range coder <-- aka paq
[03:48:48] <Dark_Shikari> lol, true
[03:49:04] <Dark_Shikari> doesn't it have a ton of separate contexts which it mixes via NN or something like that?
[03:49:37] <pengvado> yes
[04:20:26] <pengvado> ffv2 should be faster than ffvhuff overall, but not due to the entropy coder
[04:21:06] <pengvado> even with all my optimizations, the block-based coder is no faster than just coding 2 samples per token.
[04:22:10] <pengvado> though 2 samples per token is slightly faster than ffvhuff's emulation of 2 samples per token in a format that really uses only 1
[04:23:37] <pengvado> I could speedup ffvhuff by building vlc tables that aren't coherent huffman trees (i.e. prefix-full), but that's not a priority now
[04:23:44] <Dark_Shikari> explain?
[04:26:11] <pengvado> ffvhuff decoder uses tables that represent 2 or more independent consecutive vlc coded samples, in order to reduce the number of vlc tokens processed.
[04:26:23] <pengvado> but those tables are currently limited to the standard init_vlc api
[04:26:51] <pengvado> namely, that if I specify an x bit long code, then when that code is recognized, all x bits will be removed from the bitstream
[04:27:57] <Dark_Shikari> so why is ffv2 no faster?
[04:28:20] <pengvado> I don't put all possible pairs of samples in the table. that would be too large (and a pair can be up to 64 bits long, while the vlc only supports 32)
[04:29:33] <pengvado> so if A,B fits in the chosen table size, but A,C doesn't, I have to choose between including A alone, or including A,B and A,C
[04:30:07] <Dark_Shikari> so what about ffv2?
[04:30:19] <pengvado> whereas if I could build inconsistent tables, I could include A,B and A,C but make A,C's length equal to just A, so that the next bit6stream read reads C
[04:30:33] <pengvado> ffv2 adds a bunch of branches.
[04:30:42] <pengvado> fewer vlc tokens in total, but not faster
[04:31:02] <Dark_Shikari> didn't we make it so there was only one branch per 2x2?
[04:31:05] <Dark_Shikari> using a mega switch?
[04:31:31] <pengvado> there's one unpredictable jump table per 2x2
[04:31:48] <Dark_Shikari> and that's bad enough to cut performance back down?
[04:32:14] <pengvado> and one unpredictable branch per 2x2 in the CBP (changing it to a jump table per 8x2 didn't help)
[04:32:24] <Dark_Shikari> 8x2 sounds expensive, isn't it exponential?
[04:32:28] <Dark_Shikari> i.e. 16 possible jumps per 2x2
[04:32:32] <Dark_Shikari> would be 16^4 per 8x2
[04:32:37] <Dark_Shikari> oh, you mean the cpb
[04:32:51] <Dark_Shikari> wait, isn't an uncoded 2x2 block rather rare?
[04:32:58] <Dark_Shikari> i.e. rare enough that the jump table wouldn't be worth it
[04:33:05] <Dark_Shikari> and it's better to have a mostly-well-predicted branch
[04:33:17] <pengvado> 8x2 is 4 CBP flags
[04:33:24] <Dark_Shikari> yeah, got that
[04:33:48] <pengvado> if it were that rare, I wouldn't bother with CBP at all
[04:34:17] <Dark_Shikari> how about use a linked-list-like method
[04:34:19] <Dark_Shikari> i.e. instead of saying
[04:34:27] <Dark_Shikari> if( coded ) { get 2x2 block }
[04:34:28] <Dark_Shikari> do
[04:34:37] <Dark_Shikari> nextblock = somefunction of cbp
[04:34:50] <Dark_Shikari> so if there are 5 uncoded, then 1 coded
[04:34:53] <Dark_Shikari> it still only takes one step
[04:35:10] <Dark_Shikari> thus, decoding a cbp is O(number of coded blocks) not O(number of blocks in cbp)
[04:36:08] <Dark_Shikari> you could even make every cbp have a list of blocks IDs associated with it
[04:37:05] <Dark_Shikari> for( int i = 0; cbptable[CBP][i]; i++ ) { nextblock = cbptable[CBP][i] ... }
[06:08:33] <astrange> http://oss.slysoft.com/CloneDVDmobile/2009-06-15/patch-2009-06-14.patch
[06:09:22] <Dark_Shikari> heh, they added the lpthread that we _still_ haven't fixed
[06:10:14] <Dark_Shikari> hmm.  they added -pass 3
[06:10:50] <Dark_Shikari> LOL, they fixed libx264 parameter handling
[06:10:54] <Dark_Shikari> they just added a string API
[06:11:00] <Dark_Shikari> and used x264_param_parse
[06:11:03] <Dark_Shikari> I like these guys!
[06:38:16] <hyc> http://www.theinquirer.net/inquirer/news/1599506/free-html5-ipad
[06:38:26] <hyc> with any luck rtmp will be obsolete soon.
[06:38:31] <hyc> oddly enough, thanks to Apple...
[06:39:05] <kshishkov> I'd be in the first million to welcome the demise of RTMP
[06:39:21] <hyc> lol. you and me both.
[06:40:11] <hyc> crappy inefficient protocol
[06:40:54] <hyc> with security designed by morons... the internet will work a lot better when it's gone
[06:41:23] <Dark_Shikari> what does the ipad have to replace it?
[06:41:27] <Dark_Shikari> that horrific segmented mpeg-2 protocol?
[06:41:28] <hyc> htm5
[06:41:30] <hyc> html5
[06:41:34] <Dark_Shikari> html5 is not a protocol
[06:41:37] <hyc> true
[06:41:52] <hyc> but all people care about is getting movies onto their screens
[06:41:54] <Dark_Shikari> last I heard, apple still had their own equally custom equally stupid protocol
[06:42:03] <Dark_Shikari> which is incompatible with every other browser out there
[06:42:12] <Dark_Shikari> and will not work on anything but ipods and iphones
[06:42:23] <Dark_Shikari> Making it potentially even more obnoxious than rtmp.
[06:42:34] <hyc> hadn't heard about that. but this article is about streaming to iPads using html5
[06:42:41] <Dark_Shikari> that isn't streaming
[06:42:43] <Dark_Shikari> that's progressive download
[06:42:45] <hyc> and I dunno, could Apple's be worse than silverlight?
[06:42:49] <Dark_Shikari> MP4 _cannot_ be streamed
[06:43:02] <kshishkov> it can
[06:43:07] <hyc> sure it can, you just need to send the moov index first
[06:43:13] <Dark_Shikari> hyc: that's progressive download
[06:43:14] <Dark_Shikari> not streaming
[06:43:21] <hyc> fine
[06:43:25] <Dark_Shikari> there is no moov atom in a live source
[06:43:29] <hyc> end users don't care about the difference
[06:43:33] <Dark_Shikari> um, yes they do
[06:43:37] <Dark_Shikari> they care about the difference between a live football game
[06:43:41] <Dark_Shikari> and a recording a week later
[06:43:50] <hyc> heh, ok, fair point
[06:44:02] <hyc> but mp4 isn't being used anyway, it's all h.264
[06:44:08] <Dark_Shikari> um, it's h264 _in mp4_
[06:44:10] <astrange> http://74.125.113.132/search?q=cache:_2owRSuiYjUJ:tools.ietf.org/html/draft-pantos-http-live-streaming-02+http+live+streaming&cd=5&hl=en&ct=clnk&gl=us&client=safari
[06:44:36] <Dark_Shikari> astrange: yes, that's apple's MPEG-TS based streaming protocol, right?
[06:45:17] <astrange> yeah
[06:45:25] <astrange> hm, is that why quicktime x supports ts?
[06:46:09] <hyc> mpeg-ts is hardly obscure - you mean Apple is pushing some other streaming tech too?
[06:46:31] <Dark_Shikari> hyc: the playlist protocol
[06:46:34] <Dark_Shikari> it's not standard TS
[06:46:37] <Dark_Shikari> see the above link
[06:47:31] <Dark_Shikari> or better said, it's standard TS, but wrapped in a nonstandard protocol that every app will have to add support for.
[06:48:17] <hyc> ah well. Apple has always been one to do things the stupid way
[06:48:41] <_av500_> beats me why they chose ts over mp4
[06:48:48] <_av500_> and m$ uses mp4
[06:48:52] <_av500_> over asf
[06:49:58] <kshishkov> well, they also have Flip4Mac to store asf in mov :)
[06:50:24] <_av500_> but that is not from aapl itself
[06:50:26] <Dark_Shikari> _av500_: mp4 can't stream
[06:51:00] <_av500_> Dark_Shikari: if ts can stream, why do they segment and wrap it in a playlist?
[06:51:20] <_av500_> err, wait, ogg can stream!!! :)
[06:51:23] <Dark_Shikari> because they are apple and they have to do everything in a nonstandard way
[06:51:33] <Dark_Shikari> Now, more reasonably, because it allows easier bitrate adaptation
[06:51:41] <_av500_> right
[06:51:41] <Dark_Shikari> so the client can tell the server what bitrate it wants for the next chunk
[06:51:59] <_av500_> but in that case, the chunk can be mp4 as well
[06:52:04] <hyc> everyone should just transfer in ASN.1 DER ....
[06:52:08] <_av500_> so, why ts?
[06:53:07] <astrange> mp4 has to be faststarted
[06:53:18] <astrange> maybe the segmenting is for seeking?
[06:53:33] <_av500_> the segmenting is for bitrate adaption
[06:53:38] <_av500_> as Dark_Shikari said
[06:53:47] <_av500_> but once you have 10s segments
[06:54:02] <astrange> the playlist file does not seem to contain alternate bitrate urls
[06:54:07] <_av500_> the segment itself can be almost any container
[06:54:25] <_av500_> astrange: it does in the M$ case, which uses mp4 :)
[06:54:37] <Dark_Shikari> astrange: the server can update the playlist in realtime
[06:54:40] <Dark_Shikari> and actually yeah
[06:54:43] <Dark_Shikari> microsoft uses mp4 for that
[06:54:45] <Dark_Shikari> segmented mp4
[06:54:46] <Dark_Shikari> "smooth streaming"
[06:55:34] <_av500_> right, the player constanly polls the playlist file
[06:55:47] <kshishkov> WMP also can buffer as good as RealPlayer too
[06:55:53] <Dark_Shikari> "as good as realplayer"
[06:56:03] <hyc> oh boy, polling the playlist, there's a great idea
[06:56:24] <_av500_> hyc: u just need to be on goog gige :)
[06:56:33] <hyc> lol
[06:56:54] <Dark_Shikari> html5 is such a catastrophe
[06:56:56] <hyc> why doesn't the server just send a status msg when the playlist changes
[06:56:59] <Dark_Shikari> they design it to do progressive download and not streaming
[06:57:03] <Dark_Shikari> and so everyone realizes "shit, we need streaming"
[06:57:06] <hyc> oh well
[06:57:10] <Dark_Shikari> and they all come up with mutually incompatible shitty ways of doing it
[06:57:13] <Dark_Shikari> none of which will be in the spec
[06:57:19] <_av500_> ack
[06:57:40] <_av500_> so far seeking in html5 is as broken as in flash
[06:57:48] <Dark_Shikari> more broken
[06:57:50] <Dark_Shikari> flash actually works
[06:58:10] <_av500_> yes
[06:58:17] <Dark_Shikari> html5 is really pathetic because they noted a ton of shitty things about flash, went off to make something to replace it, and then managed to make a system _even worse_.
[06:58:27] <_av500_> but i guess u can always  put flash://url.swf in the video tag
[06:58:32] <Dark_Shikari> LOL
[06:59:03] <Dark_Shikari> that is bad and you are bad
[06:59:15] <_av500_> i know
[06:59:17] <hyc> http is probably the wrong transport for streaming anyway
[06:59:29] <Dark_Shikari> http works fine with flash
[06:59:38] <Dark_Shikari> it's rather barebones, without the flexibility of rtmp
[06:59:40] <Dark_Shikari> but it _works_
[06:59:42] <hyc> yes but as you say, that's just a progressive download
[06:59:44] <Dark_Shikari> no
[06:59:47] <Dark_Shikari> you can use it for actual streaming
[07:00:04] <Dark_Shikari> that's how you use ffserver to stream to flash
[07:00:35] <kshishkov> well, for me flash plugin reliably crashes firefox
[07:00:43] <Dark_Shikari> kshishkov: for me, firefox reliably crashes firefox
[07:00:57] <hyc> lol. I run my own builds of seamonkey
[07:01:05] <hyc> but yeah, it still crashes too often
[07:01:12] <kshishkov> dillo segfaults sometimes too
[07:01:21] <kshishkov> elinks works the best
[07:01:36] <_av500_> hyc: seamonkey ftw!
[07:01:50] <hyc> ;)
[07:02:19] <hyc> I could never get javascript working in elinks
[07:02:33] <hyc> otherwise I would have stuck with that
[07:02:55] <astrange> i wanted to port links to webkit
[07:03:08] <astrange> i guess that would make it crash more often, though
[07:03:14] <hyc> lol
[07:04:09] <hyc> fortunately I don't actually need to run anything with flash any more
[07:04:21] <Dark_Shikari> I don't need to, but it's sure damn nice.
[07:04:25] <hyc> get_flash_videos + rtmpdump gets anything I want to see
[07:04:34] <hyc> everything else, I didn't want to see...
[07:04:50] * Dark_Shikari likes flash animations though
[07:04:58] <kshishkov> happy tree friends?
[07:05:46] <Dark_Shikari> whatever 東方ＰＶs are out this week
[07:06:23] <Dark_Shikari> Flash actually does a pretty good job at what it was originally designed to do, you know =p
[07:06:42] <kshishkov> replacing SVN Animation?
[07:06:46] <kshishkov> *SVG
[07:06:52] <Dark_Shikari> SVG didn't even exist at the time
[07:06:59] <Dark_Shikari> and I've never even _seen_ an SVG animation
[07:07:16] <Dark_Shikari> I also doubt they're even as fast as flash, given that merely _static_ SVGs lag out my firefox
[07:07:24] <hyc> heh
[07:07:25] <Dark_Shikari> (thanks wikipedia)
[07:07:43] <Dark_Shikari> now, what I really hate is when people post Flash videos as video files instead of SWFs
[07:07:44] <hyc> yeah I have an emblem I saved as an SVG, it looks like an animation when it renders, slowly...
[07:07:50] <Dark_Shikari> they're larger, lower quality, not scalable
[07:07:59] <Dark_Shikari> just plain stupid
[07:08:08] <Dark_Shikari> (er, flash _animations_)
[07:10:40] <kshishkov> Dark_Shikari: todays XKCD seems to be strangely related to your words
[07:10:54] <Dark_Shikari> meh, xkcd.
[07:13:14] <kshishkov> bbl
[09:51:06] <ods15> hmm, from "ps aux" while compiling binutils... make "DESTDIR=" "RPATH_ENVVAR=cant_touch_this_nah_nah_nah"
[09:51:37] <ods15> ah, it's a gentoo thing
[09:52:01] <kshishkov> hello, colleague
[09:52:50] <ods15> heh
[09:53:12] <kshishkov> guess who has very lousy audio encoder in FFmpeg that everybody kicks?
[09:59:21] <Dark_Shikari> vorbis or aac?
[10:00:23] <kshishkov> AND!
[10:03:18] <bilboed> that bad ?
[10:03:59] <Dark_Shikari> bilboed: http://saintdevelopment.com/files/tests.zip
[10:04:02] * kshishkov refrains from comparing it to gstreamer
[10:04:37] <bilboed> kshishkov, you're comparing apples and pears :)
[10:05:05] <bilboed> kshishkov, btw, you're an organist (in ref to blogpost) ?
[10:05:46] <kshishkov> bilboed: on the contrary - I mentioned I don't play any instruments
[10:06:47] * bilboed facepalms
[10:06:53] <bilboed> yes, I should read entirety of blogposts
[10:07:42] <ohsix> or no blogs :]
[10:08:31] <bilboed> kshishkov, anyway, yes, that piece is a bitch to play... but JSB came up with harder pieces to play than that
[10:08:49] <kshishkov> bilboed: BTW it's mentioned in the same post
[10:08:59] <kshishkov> bilboed: for example?
[10:09:34] <bilboed> one sec, grabbing my scores
[10:11:49] <ods15> kshishkov, we have an aac encoder?...
[10:11:57] * ods15 is so out of date
[10:12:16] <kshishkov> ods15: yes, on par with your vorbis encoder currently
[10:12:59] <bilboed> ohsix, 3rd movement (vivace) of the Trio Sonata #3 in D minor (527)
[10:13:01] <ods15> obviously not a very good par..
[10:13:02] <bilboed> gah
[10:13:09] <bilboed> s/ohsix/kshikov/
[10:13:32] <ods15> i always said psychoacoustics is not my thing, i was wondering if anyone improved my vorbis encoder in the last few years, saw that noone did...
[10:14:13] <kshishkov> bilboed: well, that explains why I haven't heard triosonatas for organ performed live
[10:14:25] <ods15> kshishkov, what are these files? test1.wav etc.
[10:14:32] <Dark_Shikari> ods15: from my link?
[10:14:36] <ods15> hmm, no, Dark_Shikari
[10:14:36] <ods15> yes
[10:14:39] <Dark_Shikari> one of them is FF-AAC
[10:14:41] <Dark_Shikari> at 160kbps
[10:14:44] <Dark_Shikari> another is FAAC at 160kbps
[10:14:46] <Dark_Shikari> another is the source
[10:14:49] <Dark_Shikari> see if you can figure out which is which
[10:14:53] <ods15> which is which... am i suppose to tell?
[10:14:57] <Dark_Shikari> You will know.
[10:14:58] <Dark_Shikari> you WILL know.
[10:15:16] <Dark_Shikari> also, ods15, it's really worse than that.  ff-vorbis is not merely not psy-optimized, it's utterly atrocious buggy garbage.  But don't worry!  Because you're no longer alone!
[10:15:55] <ods15> i can definitaly tell that 2 of them are different from the other, but my hearing is so bad i can't confidentaly say which one is BETTER than the other
[10:15:56] <bilboed> kshishkov, and if you don't know it (and I'll end this parenthis here) ... Vierne's 6th symphony... *that* is the hardest piece I know of.
[10:16:17] <Dark_Shikari> ods15: ok, your hearing can't possibly be that bad
[10:16:21] <Dark_Shikari> 2 are basically identical, one is utterly awful
[10:16:36] <ods15> wait, ok...
[10:16:54] <ods15> yes i see now
[10:17:08] <ods15> dude, i could have sworn that test1 was the original until you said that
[10:17:13] <Dark_Shikari> go to 0:18 in test1
[10:17:18] <Dark_Shikari> and listen until the end
[10:17:19] <kshishkov> bilboed: for my ear Passacaglia by Max Reger is technically more difficult to perform than JSB but it does not sound like music to me
[10:17:26] <Dark_Shikari> it will HURT YOUR EARS
[10:17:43] <Dark_Shikari> there are entire chunks of the frequency spectrum that just disappear there
[10:17:43] <ods15> ahh, yeah, that's bad
[10:17:51] <Dark_Shikari> remember, this is 160kbps!
[10:17:57] <ods15> heh
[10:18:07] <Dark_Shikari> as I said, your vorbis encoder now has competition
[10:18:19] <bilboed> kshishkov, speaking of which... organ recordings are a very good test for audio encoders :)
[10:18:25] <ods15> competition for being worse? which? the aac encoder?
[10:18:30] <Dark_Shikari> ods15: yes
[10:18:40] <Dark_Shikari> Actually I should totally test it.
[10:19:03] <ods15> something you said didn't make sense
[10:19:07] <ods15> 13:14:39 <@Dark_Shikari> one of them is FF-AAC
[10:19:07] <ods15> 13:14:41 <@Dark_Shikari> at 160kbps
[10:19:07] <ods15> 13:14:44 <@Dark_Shikari> another is FAAC at 160kbps
[10:19:07] <ods15> 13:14:46 <@Dark_Shikari> another is the source
[10:19:11] <ods15> dont you mean vorbis?
[10:19:19] <Dark_Shikari> no.  yours is not in that test.
[10:19:30] <Dark_Shikari> I was just saying that ff-aac is so bad that it's competitive with ff-vorbis.
[10:19:30] <kshishkov> bilboed: depends on music and performer. Some don't even suspect that organs have pedal and more than one manual not mentioning registers
[10:19:37] <ods15> i hadn't realized that ffvorbis is buggy as well as being bad...
[10:19:46] <Dark_Shikari> ods15: well, imo anything that can sound bad at 300kbps is buggy
[10:19:47] <ods15> whats faac?
[10:19:53] <Dark_Shikari> because even optimizing for psnr won't be that bad
[10:19:56] <Dark_Shikari> faac is test_3
[10:19:59] <Dark_Shikari> source is test_2
[10:20:01] <Dark_Shikari> ff-aac is test_1
[10:20:02] <bilboed> kshishkov, obviously :)
[10:20:30] <ods15> Dark_Shikari, incomplete might be a better term...
[10:20:39] <Dark_Shikari> also, ff-vorbis seems to ignore my bitrate
[10:20:43] <peloverde> Why are we discussing ffaacenc again,it's been less than a week since last time we brought up what was wrong with it?
[10:20:43] <ods15> there's just no effort for compression at all
[10:20:43] <Dark_Shikari> I gave it 160kbps, it encodes to 84
[10:20:52] <Dark_Shikari> peloverde: it is worse than ff-vorbis
[10:20:55] <ods15> afaik it only uses -aq or something
[10:20:56] <Dark_Shikari> I just tested it
[10:21:00] <Dark_Shikari> ffvorbis sounds better at 80kbps
[10:21:08] <Dark_Shikari> than ff-aac at 160
[10:21:09] <ods15> hey! ;D
[10:21:15] <kshishkov> bilboed: well, from three constant organists here only one can play Passacaglia.
[10:21:18] <ods15> not a great triumpth
[10:21:39] <Dark_Shikari> oh wow, at 160kbps ff-vorbis sounds decent
[10:21:47] <ods15> Dark_Shikari, you used -aq?
[10:21:50] <Dark_Shikari> yes
[10:21:54] <Dark_Shikari> ok, ods15, you win
[10:21:58] <Dark_Shikari> ffvorbis is actually usable
[10:21:58] <ods15> yey!
[10:21:59] <peloverde> It's not a good comparison unless you override the filter with something sane
[10:22:18] <Dark_Shikari> it's transparent to my ears at 160kbps.
[10:22:46] <ods15> Dark_Shikari, there's a really stupid trial-and-error formula i used there for possibly better compression, but i'm too clueless to know if it really works or is the right approach
[10:23:02] <ods15> i'm actually pretty sure it isn't
[10:23:04] <Dark_Shikari> er, not transparent I guess, "almost transparent"
[10:23:14] <kshishkov> peloverde: I think that filter is not that bad. Maybe cutoff ratio calculation gone bad?
[10:23:15] <Dark_Shikari> like 96kbps mp3 I guess.
[10:23:24] <ods15> got to the ending?
[10:23:31] <peloverde> kshishkov, yes I mean the cutoff ratio
[10:23:33] <Dark_Shikari> ?
[10:24:07] <ods15> you corrected yourself on "transparent", i guess because you just got to the ending of that sample...
[10:24:11] <kshishkov> peloverde: maybe debug print it, lame does so too
[10:24:18] <ods15> vorbis_enc.c:685 -         average *= pow(tot_average / average, 0.5) * pow(1.25, position/200.); // MAGIC!
[10:24:25] <Dark_Shikari> Yeah
[10:24:44] <ods15> hmm, exponential multiplied by sqrt... humbug
[10:24:57] <Dark_Shikari> peloverde: really, rather than bitch at people who complain about it
[10:25:00] <Dark_Shikari> why not just fix it if it's so easy
[10:25:15] <Dark_Shikari> I think you are missing how #ffmpeg-devel works
[10:25:19] <Dark_Shikari> this is troll-driven development
[10:25:23] <Dark_Shikari> we troll people until they fix problems
[10:25:26] <ods15> haha
[10:25:30] <peloverde> I would rather have it be clear that it is a toy than have it be just mostly bad
[10:25:34] <Dark_Shikari> It worked with michael and ffh264
[10:25:47] <Dark_Shikari> now ffh264 is much faster and better.
[10:25:52] <Dark_Shikari> so we must troll everyone else too.
[10:25:54] <ods15> is h264 decent? is it faster than coreavc?
[10:26:01] <Dark_Shikari> no way, it was a full 50% slower prior
[10:26:06] <Dark_Shikari> (where "100% slower" means "half speed")
[10:26:13] <ods15> right
[10:26:14] <Dark_Shikari> or, better said, coreavc was 50% faster.
[10:26:21] <Dark_Shikari> I think the gain since then has been 20%, maybe a bit more.
[10:26:26] <ods15> no, coreavc was 33% faster?...
[10:26:28] <Dark_Shikari> so we've covered a bit under half the ground.
[10:26:29] <peloverde> trolling me before PS is done is only just distracting me, I'm not giving either enough attention to make a dent anymore I spend most of my time modeswitching
[10:26:46] <Dark_Shikari> ods15: 50% faster with identical asm
[10:26:48] <Dark_Shikari> on arm
[10:27:08] <ods15> Dark_Shikari, how recent was this? i'm wondering if the videos i'm barely playing now will play with updated mplayer?
[10:28:03] <ods15> Dark_Shikari, how does ffvorbis sound at 80?
[10:28:13] <Dark_Shikari> what is "80%"?
[10:28:22] <Dark_Shikari> how recent was what
[10:28:41] <ods15> err
[10:28:49] <ods15> recent - michael h264 speedups
[10:28:57] <ods15> 80 - 80kbps
[10:28:57] <ods15> 13:21:00 <@Dark_Shikari> ffvorbis sounds better at 80kbps
[10:29:09] <Dark_Shikari> it sounds pretty awful at 80, unlistenable
[10:29:12] <Dark_Shikari> but slightly better than aac I think
[10:29:24] <Dark_Shikari> michael h264 speedups?  past 2-3 months or so.
[10:29:25] <Dark_Shikari> since january.
[10:29:33] <Dark_Shikari> they're the reason vlc released 1.0.5.
[10:29:50] <ods15> ah
[10:30:37] <ods15> MPlayer SVN-r30131-4.3.4 (C) 2000-2009 MPlayer Team
[10:30:44] <ods15> looks like i haven't been using it then
[10:35:23] <peloverde> Really, according to vlc credits they haven't updated ffmpeg in three years
[10:38:32] <Dark_Shikari> no, they update with every release
[10:38:33] <kshishkov> hmm, that's when RV3/4 decoder started working....
[10:38:55] <peloverde> "FFmpeg - Copyright (c) 2000-2007 Fabrice Bellard, et al."
[10:39:18] <peloverde> that is from 1.0.5
[10:39:31] <Dark_Shikari> that's called LAZY
[10:39:38] <Dark_Shikari> aka "somebody didn't update the credits message"
[10:45:27] <hyc> I recall whining about H264 on ARM a few months back too
[10:45:49] <hyc> er, August-September, mor ethan a few months ago
[10:46:03] <Dark_Shikari> well ffmpeg has pretty much the best arm asm out there
[10:46:06] <Dark_Shikari> if by arm you mean neon
[10:46:10] <Dark_Shikari> and ARM7
[10:46:12] <hyc> the NEON stuff was a big boost
[10:46:14] <Dark_Shikari> er, ARMv7
[10:46:27] <hyc> yeah. OMAP3, AI TouchBook
[11:00:03] <thresh> http://www.rfc-editor.org/rfc/rfc5841.txt btw
[11:03:16] <hyc> cute
[11:05:20] <thresh> hyc: oh, while you're here. any plans on making librtmp shared library on linux?
[11:07:20] <CIA-1> ffmpeg: michael * r22773 /trunk/libavcodec/motion_est.c:
[11:07:20] <CIA-1> ffmpeg: Reduce the size of the bidir refine hashtable from 4096 to 256 and
[11:07:20] <CIA-1> ffmpeg: change the hash function to something more sane and simple.
[11:07:20] <CIA-1> ffmpeg: about 1/3 faster, no meassureable change in psnr or size and i gues
[11:07:20] <CIA-1> ffmpeg: its even same md5 with my test file but i forgot testing that.
[11:07:27] <hyc> thresh: hadn't made any plans, no
[11:07:52] <kshishkov> then make some to please him
[11:08:08] <hyc> all it needs is -fPIC in the CFLAGS
[11:08:09] <kshishkov> or a truckload of C4 shipped to Adobe
[11:08:46] <thresh> hyc: well, it is not only a matter of invoking ld in proper way but ensuring proper sonames, changing those when some API changes etc
[11:09:03] <thresh> not sure this should be done in a separate patchset
[11:09:08] <hyc> heh. sounds like you've made some plans. feel free to submit a patch.
[11:09:21] <thresh> well, i'm just looking from a packager POV
[11:09:22] <thresh> okay
[11:09:58] <hyc> I generally only concern myself with releasing code that compiles. installing/packaging is not my concern
[11:11:21] <hyc> and I certainly don't want to be responsible for configre/Make rules to do packaging for all the Linux distros plus all the BSD variants plus Windows from 7 back to 95 or whatnot
[11:11:54] <hyc> that's a distro's job...
[11:12:09] <Dark_Shikari> also, look at the effectiveness of troll driven development
[11:12:17] <Dark_Shikari> seriously, I just bitched about motion_est being bloated
[11:12:20] <Dark_Shikari> amd bam, michael goes and improves it
[11:12:28] <thresh> hyc: if you say so
[11:12:31] <Dark_Shikari> it's magic! ;)
[11:13:06] <hyc> Dark_Shikari: phooey. quit distracting him until he finishes reviewing my rtmp/flv seek patches
[11:13:12] <hyc> :P
[11:13:19] <Dark_Shikari> lol
[11:14:59] <iive> Dark_Shikari: yeh, it's much simpler to make michael do it, instead of you :P
[11:15:12] <Dark_Shikari> iive: well, he knows his code much better than I do
[11:15:19] <Dark_Shikari> and he can commit unilaterally in 2 minutes
[11:15:28] <Dark_Shikari> instead of posting patches that take 3 days to review
[11:16:26] <hyc> my flv duration patch seemed pretty non-controversial
[11:16:32] <peloverde> Review latency can be a killer, especially when stuff gets lost
[11:16:55] <Dark_Shikari> yeah :/
[11:17:00] <Dark_Shikari> the LATENCY is the real problem, not throughput
[11:17:14] <peloverde> And that's not just michael (for when he read this)
[11:17:22] <hyc> On OpenLDAP all committers just commit. We review after the fact.
[11:17:44] <hyc> Or complain when make test breaks...
[11:18:03] <kshishkov> peloverde: but you don't do RT*P code, why complain about latency?
[11:18:36] <kshishkov> it's in nature of OpenLDAP :)
[11:18:51] <hyc> it's frequently easier to make sense of the actual code, than the diffs
[11:19:16] <Dark_Shikari> hyc: lol
[11:19:16] <peloverde> I've at one time or another touched some big chunks of FFmpeg that I don't maintain
[11:19:25] <Dark_Shikari> I like the x264 approach
[11:19:28] <Dark_Shikari> commit once every 2 weeks or so
[11:19:32] <peloverde> As well as some stuff that I'm defacto maintainer of
[11:19:35] <Dark_Shikari> yay for git
[11:19:44] <peloverde> I wish we had git :(
[11:19:47] <Dark_Shikari> you do.
[11:20:04] <peloverde> As I've said before the current git-svn setup is lacking
[11:20:24] <peloverde> specifically the lack of dcommit
[11:20:49] <peloverde> and swscale living in it's own swscale hole but being mandatory
[11:21:10] <J_Darnley> Speaking of patch latency: I would like to hint at my patch for VorbisComment writing in ogg-vorbis files
[11:21:13] <Dark_Shikari> dcommit?
[11:21:46] <peloverde> Nothing is more fun that trying to track down an audio regression and having the post bisect make fail due to a VIDEO scaler being out of sync
[11:21:59] <Dark_Shikari> oh god swscale
[11:22:06] <peloverde> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
[11:22:22] <hyc> what's up with swscale anyway, why is it off on its own?
[11:22:28] <Dark_Shikari> for "historical reasons"
[11:22:31] <peloverde> It used to be part of mplayer
[11:22:34] <Dark_Shikari> aka bikeshed
[11:22:36] <peloverde> but didn't postproc?
[11:22:58] <hyc> hard to imagine what's worse though. could be network-manager, where the bug reports get hundreds of "this is broken for me too" comments but they still refuse to fix
[11:23:22] <peloverde> In general living by itself slows me down one time unit and complaining about it slows me down two
[11:23:55] <Dark_Shikari> I would argue that the "commit cycle" and the "test cycle" are the two most important things in development speed
[11:24:00] <hyc> I vaguely recall a time before libpostproc was around...
[11:24:06] <Dark_Shikari> 1) being "how fast can I get something committed so I can go work on something else?
[11:24:18] <Dark_Shikari> 2) being "how fast can I go from a code modification to tests on that modification being done?"
[11:24:40] <hyc> right, but 2 usually doesn't require waiting on someone else
[11:25:21] <Dark_Shikari> but it's still important
[11:25:25] <Dark_Shikari> it's why long build cycles are DEADLY
[11:27:03] <peloverde> The ongoing split up of dsputil has been helpful
[11:27:39] <peloverde> I've definitely not bothered to do things because the result will be changing dsputil.h and therefore clobbering all of avcodec
[11:28:00] <kshishkov> that's why MN builds without dependencies
[11:28:07] <Dark_Shikari> >_>
[11:28:12] <Dark_Shikari> and because he has a pentium 2
[11:28:19] <hyc> yeesh
[11:28:22] <peloverde> That is not a real solution to the problem
[11:28:36] <hyc> long build times: 16 core server, make -j, no problem.
[11:28:52] * kshishkov remembers half an hour builds on his PII-266
[11:29:21] <peloverde> I remember long builds on my P1-200
[11:29:30] <Dark_Shikari> hyc: it's hard to get build times fast enough with ffmpeg to be nice though
[11:29:33] <Dark_Shikari> if only because of the slow link step
[11:29:48] <peloverde> Dark_Shikari, gold plus make -j4
[11:29:53] <Dark_Shikari> gold?
[11:30:09] <kshishkov> gnu-off ld ?
[11:30:17] <Dark_Shikari> ?
[11:30:17] <peloverde> The new GNU ELF LD
[11:30:20] <Dark_Shikari> ah
[11:30:23] <Dark_Shikari> it's not slow as fuck?
[11:30:33] <peloverde> It's much faster than ld.bfd
[11:31:38] <peloverde> Though it is written in c++ which makes bootstrapping so much more fun
[11:31:49] <kshishkov> peloverde: it's better here - overall slow system + overall slow developer
[11:31:58] <hyc> http://www.airs.com/blog/archives/38
[11:32:12] <hyc> but he's wrong, a linker's job is not uninteresting
[11:32:31] <hyc> it's the only practical place to implement global optimization
[11:32:39] <peloverde> Also it uses less RAM when I only had 2G I couldn't link chrom(e|ium) with ld.bfd but could with gold
[11:32:47] <hyc> I hacked global optimization into M68K gnu-ld ages ago...
[11:33:15] <Dark_Shikari> global optimization is pretty useless in my experience
[11:33:19] <Dark_Shikari> gcc is too dumb to do anything with it
[11:33:29] <Dark_Shikari> hell, gcc can't even remove unused arrays from a _single C file_
[11:33:34] <Dark_Shikari> let alone do some sort of global cleanup
[11:33:40] <hyc> well, that's the point. you can't do it in gcc, you have to do it in the linker.
[11:33:53] <CIA-1> ffmpeg: mstorsjo * r22774 /trunk/libavformat/rtpdec_xiph.c:
[11:33:53] <CIA-1> ffmpeg: Change a case of CODEC_TYPE_ into AVMEDIA_TYPE_
[11:33:53] <CIA-1> ffmpeg: This was accidentally overwritten in the recent merge of the theora/vorbis codepaths
[11:33:56] <Dark_Shikari> you need communication between the compiler and linker for global optimization
[11:34:10] <Dark_Shikari> and if the compiler can't even globally optimize a _single C file_
[11:34:16] <Dark_Shikari> surely they have no chance of doing all your C files
[11:34:52] <kshishkov> ld is not linker, it's link _editor_, hence replace it with Emacs
[11:34:55] <hyc> I did pretty basic stuff - garbage collection, jump optimization, and global register allocation
[11:35:16] <hyc> all of that can be done blind, no C compiler cooperation needed
[11:35:35] <Dark_Shikari> global register allocation requires re-generating code for every function
[11:35:39] <Dark_Shikari> at least if you want good results
[11:36:10] <hyc> it was no big deal on M68K
[11:36:13] <Dark_Shikari> lol, true
[11:36:22] <hyc> movem.l <reglist>
[11:37:17] <hyc> really most of the hoops we have to jump thru today are due to crap x86 ISA
[11:37:30] <hyc> on any sane ISA you can do a lot of cool stuff without much effort
[11:38:14] <Dark_Shikari> global optimization should really be done in the compiler though
[11:38:17] <Dark_Shikari> it affects things like inlining decisions
[11:38:19] <peloverde> x86 has sane parts, like sse
[11:38:22] <Dark_Shikari> which you can't really do in a linker
[11:38:59] <hyc> but that kind of breaks the programming model, compile one source file and move on to the next
[11:39:07] <Dark_Shikari> who says you have to do that?
[11:39:09] <hyc> you have to accumulate a bunch of state instead
[11:39:24] <Dark_Shikari> "how the compiler works" and "how the programmer writes" don't have to be the same
[11:39:52] <hyc> I suppose
[11:41:10] <hyc> Anyway, certainly linkers can waste a lot of time. I liked the AIX linker, it was incremental and reasonably fast after several revisions
[11:41:32] <hyc> and their object file format didn't need to distinguish between .o, .a, or exe
[11:42:02] <kshishkov> arm from arse?
[11:42:10] <hyc> You could compile a library with however many functions in a single source file and .o, the linker would only extract what it needed.
[11:42:47] <peloverde> As long as they aren't using Mach-O, mach-o is one of those dumb reasons why I will never consider OS X
[11:42:51] <hyc> in contrast you look at the source for e.g. glibc and see thousands of 30 line source files...
[11:43:15] <hyc> just because dumb unix linkers always pull in entire .o files
[11:43:33] <peloverde> bullshit, the GNU license header is longer than 30 lines ;)
[11:43:37] <Dark_Shikari> lol
[11:43:38] <hyc> lol
[11:44:45] <hyc> but being able to relink an exe against itself was cool. ld -o exe exe patchedfile.o
[11:44:46] <kshishkov> time to switch to WTFPL2?
[11:46:12] <hyc> Hm, I remember watching a talk at Usenix about Mach-o but I didn't pay enough attention to remember any of its features
[11:46:51] * kshishkov does not care much since toolchain always finds a way to screw something else
[11:50:02] <hyc> My first several years in open source were maintaining GNU M68K toolchain
[11:50:09] <hyc> and later i860
[11:50:38] <hyc> Kind of a drag when you want to write some other program but first you need to create the tools to get there...
[11:50:52] <kshishkov> and my first several years in open source were contributing to FFmpeg
[11:52:11] <hyc> even more of a drag, I think the last bits of my code in gcc disappeared when gcc 2.x became 3.0
[11:52:15] <hyc> :P
[12:34:59] <CIA-1> ffmpeg: michael * r22775 /trunk/libavcodec/motion_est.c:
[12:34:59] <CIA-1> ffmpeg: Change bidir refine hash code so we only need to perform a single
[12:34:59] <CIA-1> ffmpeg: hash calculation for the whole function.
[12:34:59] <CIA-1> ffmpeg: negligibly faster (about 0.1%)
[12:39:14] <Kovensky> is motion_est.c still the biggest file in libavcodec?
[12:39:25] <kshishkov> too lazy to check it?
[12:39:35] <kshishkov> I thought it was vqf tables or something
[12:41:36] * Kovensky remembers it taking aeons to compile
[12:42:51] <kshishkov> ah, in compilation time it still should be outstanding
[12:43:43] * Kovensky wonders if/how it compiles in a system with 128mb ram
[12:46:02] <kshishkov> slowly
[12:46:20] <kshishkov> it was the reason I upgraded RAM on my notebook from 64M to 192M
[12:46:33] <pJok> mmmmh, 192M
[12:46:41] <pJok> that reminds me of 1997
[12:47:11] * thresh had 48M till 2001
[12:47:36] <pJok> thresh, i think i had at least 1G in 2001
[12:48:04] <thresh> so it is true what communists say about capitalists
[12:48:27] <pJok> more is better? ;)
[12:48:57] <pJok> well, to be fair, i had dialup til september 2001
[12:49:25] <thresh> till 2004, i think
[12:50:22] * Kovensky had dialup until 2005
[12:51:05] <thresh> in 2004 i paid 0.25$ per megabyte on 2MB/sec line
[12:51:29] * Kovensky had 8mb until 98, 16mb until 2002, 64mb until 2004, 128mb until 2006, 256mb until 2007, 512mb until 2008, 1gb until 2009, 2gb now ._.
[12:51:38] <Kovensky> well, 2gb minus the 256mb that this sis crap insists on stealing
[12:51:46] <pJok> hehe
[12:52:01] <pJok> my netbook has 2g
[12:52:37] <Kovensky> the *best* gpu I've had so far has been an fx5200 =p
[12:53:00] <pentanol> hi, why I've got Error: bad immediate value for half-word offset while compilation to arm uClib without flag ---disable-asm?
[12:53:06] <ohsix> thats a drag, 4/5 series were stinkers
[12:53:30] <pentanol> armv5tejl
[12:53:43] <pJok> Kovensky, that could actually run WoW ;)
[12:53:54] <Kovensky> pJok: at low fpses
[12:54:03] <Kovensky> ohsix: before the fx5200, I had an mx4000 :>
[12:54:04] <pJok> i managed about 25fps
[12:54:09] <pentanol> it  depend uClib entries?
[13:15:52] <pJok> yum
[13:16:05] <pJok> ibm thinkpad pentiums with 64mb ram
[13:18:13] <kshishkov> my case exactly
[13:18:52] <pJok> i wonder if you could use a 80386 as a microcontroller these days
[13:19:06] <kshishkov> too damn expensive
[13:19:17] <kshishkov> but it's used in space for that even now
[13:20:25] <pJok> thats because the paperwork for getting a new part certified isn't worth it
[13:21:22] <kshishkov> no, IIRC BAE produces space-proof PowerPC-based chips
[13:22:35] <pJok> that would mean rewriting software also
[13:22:47] <kshishkov> indeed
[13:23:14] <kshishkov> but it's better for software to be rewritten time from time
[13:23:45] <BBB> hello
[13:23:55] <kshishkov> hejsan
[13:34:39] <CIA-1> ffmpeg: mstorsjo * r22776 /trunk/libavdevice/beosaudio.cpp: Replace the last occurrance of CODEC_TYPE_ with AVMEDIA_TYPE_
[13:37:05] <BBB> lu_zero: thanks!
[13:38:49] <BBB> and I see now seeking is indeed broken, we should fix that (by fixing the utils.c overflow, ideally)
[13:38:54] <BBB> I'll work on that
[14:00:41] <BBB> wbs: I sent a reply to an old email of yours, we should get that patch in
[14:02:01] <Kovensky> CODEC_TYPE_ was deprecated?
[14:02:52] <kshishkov> replaced
[14:03:09] <wbs> BBB: ok, great. :-) I'll try to read up on the lavf infrastructure involved soonish
[14:03:19] <BBB> thanks
[14:03:22] <kshishkov> let Xiph call subtitle a codec, we call it "media"
[14:03:31] <Kovensky> heh
[14:04:48] <BBB> anyone here want to participate in a blind test for quality in qcelp decoder?
[14:05:06] <CIA-1> ffmpeg: michael * r22777 /trunk/libavcodec/motion_est.c:
[14:05:06] <CIA-1> ffmpeg: Optimize bidir_refine a bit.
[14:05:06] <CIA-1> ffmpeg: compiled code is less tham 1/4 the size.
[14:05:06] <CIA-1> ffmpeg: a tiny bit faster
[14:05:22] <kshishkov> I'd participate only in deaf test
[14:05:51] <BBB> ?
[14:06:31] <kshishkov> i.e. without actually hearing anything
[14:08:25] <BBB> you may use audacity to look at soundswaves also
[14:08:27] <BBB> if you so prefer
[14:09:42] <kshishkov> nah, I'll stay away from audio for a while
[14:09:45] <CIA-1> ffmpeg: michael * r22778 /trunk/ (25 files in 5 dirs): Change default for bidir_refine to 1.
[14:10:26] <BBB> will you mentor vc1-interlaced for soc?
[14:10:50] <kshishkov> co-mentor at most
[14:10:57] <BBB> you know, we have only one soc proposal so far
[14:11:01] <BBB> that's not very good ;)
[14:11:30] <kshishkov> proposal for what?
[14:11:35] <BBB> rtsp
[14:11:43] <BBB> from j0sh
[14:12:03] <kshishkov> ah, maybe you should learn more Hindi to attract proposals
[14:12:10] <BBB> I was thinking about that
[14:14:14] <kshishkov> okay, recruit jai for organizing next gsoc
[14:20:28] <CIA-1> ffmpeg: alexc * r22779 /trunk/libavcodec/psymodel.c:
[14:20:28] <CIA-1> ffmpeg: aacenc: Don't lowpass the input unless specifically requested.
[14:20:28] <CIA-1> ffmpeg: The heuristic for estimating a good cutoff is busted.
[14:20:30] <peloverde> I just dcommited from a git clone!
[14:20:46] <merbanan> \o/
[14:20:50] <wbs> \o/
[14:20:55] <iive> aacenc have been committed ?
[14:21:44] <BBB> long time ago
[14:21:44] <peloverde> The trick is to use git.mansr.com as your upstream and not git.ffmpeg.org because git.ffmpeg.org abuses local file access
[14:21:47] <BBB> but it's experimental
[14:22:13] * BBB wishes he understood git
[14:22:43] <iive> BBB: it's easy. imagine big can of worms.
[14:23:20] <peloverde> sigh, now I'm actually doing to have to work on ffmpeg instead of sitting around and complaining about svn :/
[14:24:14] <BBB> peloverde: is that the bug that caused weird buzz-noises at certain high-pitch, high-amplitude input?
[14:24:28] <BBB> (whatever you call that in real terms)
[14:24:46] <peloverde> No that is most likely a scalefactor selection issue
[14:24:59] <peloverde> possibly with bad input from the psymodel
[14:25:09] <peloverde> This is a general lack of high frequencies
[14:26:42] <BBB> oh ok
[14:27:13] <peloverde> Scalefactor selection what what i discussed in the IRC 03-27 e-mail thread
[14:28:50] <merbanan> hybrid
[14:30:58] <BBB> wooh! this is the first time since years that SVN compiles straight out of the box without the need for any nopic hacks
[14:31:04] <BBB> (on macosx)
[14:39:34] <merbanan> http://tranquillity.ath.cx/clang/2010-03-30-1/
[14:39:41] <merbanan> clang wasn't as happy
[14:42:03] <peloverde> clang is usually unhappy about many things
[14:42:08] <BBB> hm...
[14:42:13] <BBB> rmdec.c is an actual bug
[14:42:42] <merbanan> fix it
[14:43:02] <merbanan> well rm is a bug even
[14:43:06] <merbanan> hard to fix that
[14:44:00] <kshishkov> yeah, go on!
[14:49:42] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ i got a lot more warnings than you
[14:49:58] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-I1qORD.html#EndPath is this one real?
[14:50:57] <merbanan> astrange: my build failed to compile thus only ~90 issues
[14:53:29] <BBB> kshishkov: please review my rmdec.c patches ;)
[14:54:11] <merbanan> look at that, bugs in the atrac code
[14:55:58] <CIA-1> ffmpeg: rbultje * r22780 /trunk/libavformat/rdt.c: Remove dead initialization.
[14:57:10] <merbanan> astrange: looks like a valid bug
[14:57:43] <kshishkov> BBB: done
[14:57:47] <CIA-1> ffmpeg: rbultje * r22781 /trunk/libavformat/rmdec.c: Remove dead initialization.
[14:58:18] <merbanan> unless the macro does something funky
[14:58:26] <BBB> ty
[14:58:34] <kshishkov> np
[14:58:52] <CIA-1> ffmpeg: rbultje * r22782 /trunk/libavformat/rmdec.c:
[14:58:53] <CIA-1> ffmpeg: Fix uninitialized value in codepath.
[14:58:53] <CIA-1> ffmpeg: See http://tranquillity.ath.cx/clang/2010-03-30-1/report-40QvF3.html#EndPath
[15:00:00] <CIA-1> ffmpeg: rbultje * r22783 /trunk/libavformat/rmdec.c:
[15:00:00] <CIA-1> ffmpeg: Another uninitialized value.
[15:00:00] <CIA-1> ffmpeg: See http://tranquillity.ath.cx/clang/2010-03-30-1/report-e6KUTb.html#EndPath
[15:01:12] * kshishkov suspects he saw that tranquillity webserver with his own eyes
[15:03:02] <merbanan> you did :)
[15:03:12] <merbanan> but it has an older brother now
[15:03:19] <merbanan> the fit-pc2
[15:05:05] <kshishkov> s/older/yngre/ ?
[15:06:43] <merbanan> well ok
[15:06:51] <merbanan> he got a more powerful brother
[15:07:07] <kshishkov> a sequel ;)
[15:08:17] <peloverde> What is the ordering scheme in libavcodec/options.c?
[15:08:52] <superdump> have any of us ever been contacted by the mpeg-la with demands that we license codecs from them?
[15:08:54] <kshishkov> I suspect its' chronological
[15:09:10] <kshishkov> or grouped and chronological
[15:09:19] <merbanan> superdump: not that I know of
[15:09:24] <superdump> i didn't think so
[15:09:34] <kshishkov> superdump: just don't claim you use it and you'll be okay
[15:09:34] <merbanan> superdump: and it's not what they do
[15:09:38] <janneg> KotH: ^^^^
[15:09:52] <peloverde> The get their money when people productize FFmpeg
[15:10:23] <peloverde> my guess is they consider ffmpeg proper just r&d
[15:10:44] <BBB> kshishkov: "And it has functions for zeroing or copying arrays of floats written quite poorly and nowhere near as good as plain memcpy/memset." - you know each dll has that
[15:10:59] <BBB> kshishkov: you'd be surprised how many (yes, there's multiple) of those I found in wmavoice ;)
[15:11:17] <janneg> apparently they changed their mind.
[15:12:39] <merbanan> janneg: ?
[15:12:42] <superdump> so, apparently Chutt (lead dev of mythtv) has received a request for licensing from the mpeg-la for various mpeg codecs
[15:13:04] <Chutt> nice big set of docs
[15:13:16] <superdump> and requests for lots of money i expect
[15:13:35] <Chutt> to go along with the licenses, i'd assume
[15:13:37] <Chutt> heh
[15:13:42] <superdump> just to verify, you don't personally ship any products using mythtv do you?
[15:13:42] <kshishkov> BBB: WM codecs are known for duplicating every common function (like get_bits()) but this is worse
[15:13:45] <Chutt> no
[15:13:58] <janneg> not even binaries
[15:14:01] <superdump> then i wonder why they sent it to you
[15:14:04] <Chutt> i'm hardly involved in the project, even
[15:14:15] <BBB> Chutt: can you forward it to me?
[15:14:17] <Chutt> i own the domain name, probably the easiest way to contact "the project"
[15:14:23] <BBB> Chutt: I've tried for a while to get my hands on such requests
[15:14:25] <Chutt> BBB, a physical document? :p
[15:14:32] <BBB> oh, it's not email?
[15:14:34] <Chutt> no
[15:14:38] <BBB> yes, I'd love the physical document
[15:14:39] <superdump> Chutt: BBB (Ronald Bultje) has handled most of our involvement with the SFLC
[15:14:40] <merbanan> but I guess myth supplies binaries
[15:14:42] <kshishkov> BBB: memcpy should use "rep movsd", not whole idiotic loop "mov eax, [src]; mov [dst], eax; add src, 4; add dst, 4;"
[15:14:45] <Chutt> fedex
[15:14:52] <Chutt> merbanan, we do not supply binaries
[15:14:53] <iamlindoro> merbanan: source only
[15:14:54] <BBB> Chutt: I'd love to get a copy of the documents, if you can
[15:15:01] <Chutt> BBB, sure, happy to
[15:15:07] <BBB> Chutt: I'll make sure out lawyer gets them and we'll be on it
[15:15:11] <Chutt> well, i wouldn't want to send _all_ this
[15:15:17] <Chutt> i mean, it's heavy
[15:15:18] <Chutt> heh
[15:15:22] <superdump> bit of a tome is it? :)
[15:15:24] <merbanan> superdump: is there more info about this ?
[15:15:30] <superdump> ask Chutt
[15:15:31] <BBB> Chutt: I can reimburse shipping expenses
[15:15:33] <superdump> :)
[15:15:37] <Chutt> BBB, would you need the individual licenses?
[15:15:46] <BBB> Chutt: basically anything they sent you ;)
[15:15:48] <Chutt> that's most of the package
[15:16:11] <Chutt> basically, i got a cover letter
[15:16:23] <Chutt> then packets for mpeg2, h264, and mpeg4
[15:16:31] <BBB> ah, right, I see
[15:16:33] <Chutt> short overview doc for each
[15:16:38] <BBB> do you have a scanner?
[15:16:52] <Chutt> yeah
[15:16:58] <BBB> can you scan the coverletter?
[15:17:02] <Chutt> certainly
[15:17:09] <BBB> I'll discuss briefly with the lawyer whether he's interested in doing some fun stuff with this
[15:17:15] <superdump> :)
[15:17:21] <BBB> then we can discuss what we need to receive in order to continue
[15:17:21] <Chutt> awesome.
[15:17:39] <BBB> superdump: thanks for the hint ;) I've always wanted to get my hands on this ;)
[15:17:52] <superdump> i thought someone here might be interested
[15:17:59] <superdump> and now we have contacts....
[15:18:24] <KotH> janneg: ?
[15:18:28] <BBB> Chutt: send it to rsbultje gmail com
[15:18:41] <merbanan> BBB: you are such a masochist
[15:19:13] <BBB> merbanan: only when I dislike the person I'm inflicting pain upon ;)
[15:19:21] <janneg> have you received love letters from mpeg-la with requests for licensing their patents
[15:19:51] <KotH> janneg: not that i know of
[15:19:52] <merbanan> when you get the coverletter repost on legal
[15:19:54] <superdump> i don't think any of us ever have
[15:20:55] <superdump> oh, this channel is logged btw :)
[15:21:33] <BBB> merbanan: ok
[15:22:34] <KotH> janneg: why do you ask?
[15:22:40] <janneg> KotH: I somehow thought you are the Registrant of ffmpeg.org
[15:22:50] <janneg> but it's fabrice
[15:23:44] <KotH> so far, we only got a couple of cease and desist from on2
[15:24:00] <KotH> nothing else, not even adobe
[15:24:40] <superdump> i think mike would be pretty pissed if adobe tried to take us down
[15:24:43] <superdump> considering his roots
[15:25:14] <superdump> and we'd kick up a big fuss if they did
[15:26:09] <Chutt> sorry, scanning's taking a bit of effort
[15:26:15] <BBB> that's ok
[15:26:22] <Chutt> haven't used this thing in a couple years
[15:26:29] <BBB> Chutt: can you reply to my privmsg? I'm forwarding messages from my lawyer ;)
[15:26:38] <Chutt> i haven't gotten a privmsg
[15:26:48] <merbanan> switched to a wireless card that works
[15:28:57] <kshishkov> merbanan: what do you think of my short tourist guide to Sweden at http://codecs.multimedia.cx/?p=276 ?
[15:30:06] <merbanan> nice
[15:30:17] <merbanan> read it a few days ago
[15:30:46] * superdump has a look
[15:31:51] <superdump> kshishkov: s/moose/elk/
[15:32:22] <kshishkov> s/elk/älg/
[15:32:50] * kshishkov curses certain country with earls instead of counts
[15:33:48] <Kovensky> use Moose;
[15:33:51] <superdump> :)
[15:33:53] <superdump> i was going to go älg spotting with my girlfriend's dad when we were down there visiting them at the beginning of the year, but we ran out of time :/
[15:34:25] <kshishkov> I spot several at Skansen, it was not that hard
[15:35:04] <superdump> not the same as seeing them wild
[15:35:43] <kshishkov> yes, at least not for Peugeots
[15:36:41] <janneg> or Mercedes Benz
[15:37:06] <kshishkov> no, Daimler Benz produces cars
[15:37:26] <kshishkov> not some laughable parodies any elk can crash
[15:37:57] <janneg> kshishkov: http://de.wikipedia.org/wiki/Elchtest
[15:39:11] <iamlindoro> http://en.wikipedia.org/wiki/Moose_test
[15:39:47] <peloverde> Hmm... options.c does not like me reusing the same flags variable for audio and video
[15:41:09] <kshishkov> janneg: have I mentioned that I've seen several Trabants here? Says a lot about country.
[15:42:43] <janneg> kshishkov: I still see Trabants in Berlin
[15:44:30] <kshishkov> of course, it's ex-DDR
[15:45:11] <kshishkov> which is a good punishment for welcoming guys with nicknames 'Lehnin'
[15:45:28] <janneg> I'm not talking about museums
[15:45:47] <kshishkov> I also talked about streets
[15:45:58] <kshishkov> can't see that BMW 321 anymore though
[15:46:49] <janneg> I would have expected that they had vanished from the streets by now. it's 20 years
[15:47:32] <kshishkov> well, majority of cars here are clones of some "Fehler in Alle Teilen" car from sixties
[15:47:36] <merbanan> BBB: good work
[15:47:45] <BBB> this could be fun :)
[15:49:38] <kshishkov> do they really employ weasels for lawyers?
[15:51:18] <gbee> BBB: glad someone's having fun ;)
[15:51:36] <BBB> kshishkov: it's like the mpaa going after students
[15:51:41] <BBB> I mean, if you're gonna sue random people
[15:51:50] <BBB> why on EARTH would you sue the poorest of the poor?
[15:52:22] <BBB> it's completely illogical
[15:52:37] <peloverde> because they are trying to scare people into compliance
[15:52:44] <kshishkov> like Crocodile Dundee 2 movie "I you touch me I'll sue you to your last dollar! *hit* Here it is"
[15:52:58] <gbee> BBB: now don't be unreasonable, you can't start bringing logic into the argument ;)
[15:53:03] <janneg> to make an example
[15:53:13] <iamlindoro> Of the visible projects using libav*, MythTV may be the least able to defend itself at the moment
[15:53:31] <iamlindoro> They may assume they'll get less of a fight than they would from XBMC/etc. and can establish favorable case law
[15:53:40] <kshishkov> FFmpeg does not have a strict owner, good luck suing whole swarm
[15:54:08] <janneg> and the the poorest of the poor have the probably not enough for a proper defense
[15:54:49] <kshishkov> in times like this I'm proud to be not an American citizen!
[15:55:00] <peloverde> ffmpeg.org is what is actually distributing it and according to whois it belongs to fabrice, so we can all hide behind him
[15:56:06] <janneg> I think it would make more sense to go after the isp/owner of the server
[15:56:09] <peloverde> also if they shut us down they would probably actually lose money (beyond legal costs)
[15:56:09] <kshishkov> you mean Gerard Lantau?
[15:58:25] <kshishkov> and it won't really make us stay shut too
[16:27:03] <CIA-1> ffmpeg: alexc * r22784 /trunk/libavcodec/aacenc.c: aacenc: Error when an unsupported profile is requested
[16:52:48] <peloverde> siretart, What's the libmp4v2 status in debian/ubuntu?
[16:54:24] <peloverde> And why does that other project like to take a bunch of files with incompatible licenses and mash them together?
[16:54:53] <pJok> peloverde, isn't license violation the new thing these days?
[16:55:30] <peloverde> Most of these violations are pretty old and nobody noticed them for a long time
[17:02:27] <janneg> who are the mailing lists mods for -legal? please approve my subscription request
[17:03:13] <kshishkov> KotH maybe
[17:03:40] * KotH is only a free loader on -legal
[17:04:21] <kshishkov> mru then?
[17:05:06] <KotH> dunno
[17:05:13] <KotH> but i doubt it
[17:05:20] <KotH> ml admins are mostly not root
[18:00:29] <siretart> peloverde: what do you mean with 'status'?
[18:01:43] <peloverde> siretart, The concept of moving to the mp4v2 google code fork was presented and then the MPL/GPL issue came up
[18:02:01] <siretart> peloverde: debian doesn't ship it at all AFAIR, ubuntu builds it from the mpeg4ip source package
[18:02:37] <peloverde> Doesn't the mpeg4ip source have the same license issue and is super ancient?
[18:08:12] <siretart> peloverde: puh, I have to admit that I didn't follow the situation closely
[18:09:00] <peloverde> I have noticed that the number of packages depending on libmp4v2 has substantially decreased
[18:09:14] <siretart> hm. last update december 2007.
[18:09:23] <siretart> upstream update, not last upload
[18:09:39] <siretart> peloverde: what would you suggest?
[18:10:26] <peloverde> siretart, either moving to this fork: http://code.google.com/p/mp4v2/ or dropping the library entirely
[18:10:58] <peloverde> which I think was the original consensus in the fall
[18:12:44] <siretart> seems that only 3 other packages "use" mpeg4ip: easytag-aac, kid3 and faac
[18:13:09] <siretart> seems like faac is going away anyway, and hopefully the other two can be compiled against that fork
[20:15:52] <CIA-1> ffmpeg: rbultje * r22785 /trunk/libavformat/rtsp.c: ETIME -> ETIMEDOUT. Patch by Sam Gerstein <sgerstein bluefinlab com>.
[22:04:43] <troy_s> Hey folks. Trying to get sws_scale to generate fullRange instead of 16-235. What do I do before I call sws_scale?
[22:06:03] <troy_s> It looks like I need to make sure that the ColorspaceDetails is properly set in srcRange, is that correct?
[22:09:47] <CIA-1> ffmpeg: rbultje * r22786 /trunk/libavformat/httpauth.c:
[22:09:47] <CIA-1> ffmpeg: Fix buffer size; should hold 2 32-bit integers in hex = 16 chars + terminating
[22:09:47] <CIA-1> ffmpeg: zero, so should be 17 bytes, not 9.
[22:43:44] <mru> w
[22:44:24] <mru> wm
[22:44:48] <drv> aw, i was busy cutting and pasting some `w` output to make a joke ;)
[22:47:31] <mru> overzealous android softkbd
[22:48:27] <hyc> I think the proper followon would havce been "tf"
[22:49:56] <drv> i amuse myself by responding to people who type things like 'ls' into their irc clients
[22:50:21] <pasteeater> mru: talking about android, did you get my message?
[23:09:08] <Dark_Shikari> http://mirror05.x264.nl/Dark/loren.html updated.
[23:09:14] <CIA-1> ffmpeg: cehoyos * r22787 /trunk/ffmpeg.c: Use AVDISCARD_DEFAULT for 0 where appropriate.
[23:10:47] <Dark_Shikari> <pengvado> nv12 c finished. now to update the asm...
[23:10:47] <Dark_Shikari> <kemuri-_9> when do you expect to get that done pengvado?
[23:10:48] <Dark_Shikari> <pengvado> how am I supposed to be a deadly multimedia ninja if people go and *expect* me?
[23:15:34] <Dark_Shikari> peloverde: thanks for fixing the lowpass.
[23:16:54] <peloverde> np
[23:17:10] <peloverde> lowpass can still be specified manually with -cutoff
[23:18:20] <peloverde> I'm try to drag the stuff that doesn't break anything and doesn't add significant complexity out of my tree
[23:18:55] <peloverde> a window size switching option is next on the list
[23:19:08] <Dark_Shikari> it doesn't do that automatically?
[23:19:28] <peloverde> It does, but turning it off can help track down bugs
[23:20:04] <Dark_Shikari> ah k
[23:20:53] <peloverde> There are some weird dependencies between short windows that can help bugs creep in
[23:21:36] <peloverde> ideally we (me) fix the psymodel and coefficient coder for long windows first then track down short window bugs and window decision bugs
[23:21:55] <saintd3v> peloverde: now i have to update my tests :(
[23:23:08] <peloverde> If anything I think the AAC encoder is a victim of its own complexity a bunch of half finished features went in and they need to be turned off temporarily to make debuging tuning sane
[23:32:11] <saintd3v> peloverde: and don't work on the encoder on account of my tests. I'd really much rather have PS than a working aac encoder ;)
[23:34:55] <peloverde> The spec is much worse than I expected, even for mpeg audio
[23:35:21] <peloverde> Though I suppose it's not as bad as SLS
[23:43:30] <peloverde> PS is underspecified, SLS is (was?) just plain wrong
[23:44:16] <troy_s> Dark_Shikari: Can I ask you a question sir?
[23:44:51] <Kovensky> Satellite Landing System?
[23:44:56] <peloverde> I think you've proven that you can
[23:45:04] <peloverde> Scalable to Lossless
[23:53:37] <Dark_Shikari> troy_s: don't ask to ask, just ask
[23:54:11] <troy_s> WRT to 16-235 scaling for broadcast, is the best way to avoid that by calling sws_scale with the proper colorspace bits set?
[23:54:32] <Dark_Shikari> I have no idea how swscale handles fullrange vs tv range
[23:54:37] <troy_s> As in setting color_range AVCOL_RANGE_JPG
[23:54:40] <troy_s> Hrm. Ok.
[23:54:55] <troy_s> Who in your opinion is likely the best one to ask regarding how sws_scale deals with it>
[23:54:56] <troy_s> ?