[00:00:39] <CIA-17> ffmpeg: mru * r21767 /trunk/configure: Add "tomi" architecture [00:09:00] <janneg> hmm, http://www.tomicpu.net/ is not that informative [00:09:48] <mru> heh, no it's not... [00:10:08] <mru> that patent is quite detailed though [00:12:33] <janneg> but a pain to read on a 3.7" screen [00:14:19] <mru> it's a pain to read on any screen [00:15:19] <mru> I have better docs [00:59:34] <iive> isn't it wonderful when you confess that you have read some patent on channel that is logged and archives are indexed by search engines. [01:08:58] <beandog> nobody can prove who was typing though [01:09:12] <beandog> not that I've thought these things through, or anything .. [01:33:48] <mru> those are patents on a cpu design [01:34:00] <mru> the owners hired me to do some work [01:34:11] <mru> everything is fine [01:38:45] <CIA-17> ffmpeg: michael * r21768 /trunk/libavformat/riff.c: Add GEOV fourcc (issue971). [02:02:34] <BBB> ok, so I fuzz'ed until it complained that it couldn't parse any frames anymore [02:02:39] <BBB> still no valgrind [02:02:41] <BBB> can I apply now? [02:31:16] <Compn> hehe [02:31:32] <BBB> damn you again :) [02:31:53] <Compn> is it... binary identical ? [02:32:08] <Compn> or 'bit-exact' as you people would say [02:33:54] <BBB> no [02:33:57] <BBB> postfilter is missing [02:34:03] <BBB> and several decoder bugs were fixed along the way [02:34:11] <BBB> apart from the binary bugs, it's bit-identical [02:34:17] <Compn> lol [02:34:23] <BBB> as in: it once was bit-identical, until I started fixing its bugs [02:34:26] <Compn> did you send your bug report to microsoft? :D [02:34:36] <BBB> I blog about them to publically ridicule ms [02:35:13] <BBB> if ms reads my blog, then they know about the bugs [02:35:22] <BBB> if they don't, well, yeah, then they don't know :) [03:48:12] <neo01124> hey! [03:48:35] <neo01124> where will i find demuxers in ffmpeg source? [03:49:28] <Dark_Shikari> libavformat [06:55:30] <siretart_> good morning! [06:57:20] <av500> gm [06:59:00] <kshishkov> as you say [07:06:04] <Dark_Shikari> siretart_: ping [07:07:13] <siretart_> Dark_Shikari: yes? [07:07:27] <siretart_> Dark_Shikari: I'm still awaiting your libx264.c patch for 0.5.1 :-) [07:07:35] <Dark_Shikari> that's what this is about [07:07:43] <Dark_Shikari> I'm nice, so I made it work with every libx264 up to the latest [07:07:51] <Dark_Shikari> and I minimized the ifdeffery [07:07:54] <siretart_> wow [07:07:56] <Dark_Shikari> and actually made clean code [07:08:21] * thresh pokes Dark_Shikari to push fixes [07:08:23] <Dark_Shikari> however, I will need you to test it [07:08:33] <siretart_> ok, will do [07:08:37] <Dark_Shikari> I assume you can do that ? :) [07:08:56] <siretart_> I can testcompile it against both x264 in ubuntu and an updated snapshot [07:09:14] <siretart_> but I'm not that interested in testing each and every intermediate version [07:09:20] <Dark_Shikari> I can give you the hashes of each to test [07:09:24] <Dark_Shikari> there's only about 5. [07:09:29] <siretart_> okay [07:09:44] <siretart_> can you please post the hashes and the patch to ffmpeg-devel@? [07:09:55] <siretart_> prefix the subject with [PATCH][0.5], so that I can easily find that [07:09:57] <Dark_Shikari> not done yet [07:10:12] <Dark_Shikari> also, I may have fucked up, so I'll give it to you on IRC first ;) [07:10:30] <Dark_Shikari> also, I'm on Windows, so configuring is so slow here that you could finish all the tests in the time it takes to configure ffmpeg [07:10:47] <siretart_> okay, but I'm now hurrying to work and will be stuck in meeting half of the day today (damn, it's friday...) [07:10:54] <Dark_Shikari> heh [07:13:08] <siretart_> okay, bbl! [07:17:34] <Dark_Shikari> 1) patch http://pastebin.com/m4fee05f6 [07:19:14] <Dark_Shikari> 2) x264 revisions to test: http://pastebin.com/m61a71336 [07:19:16] <Dark_Shikari> siretart_: ^ [07:21:28] <Dark_Shikari> ping me when you're back. [07:47:00] <kshishkov> Compn: you around? [07:52:29] <Dark_Shikari> oh wait, siretart_, I forgot the defaults from the cmdutils or whatever. [07:54:02] <Dark_Shikari> http://pastebin.com/m62729da updated patch [08:07:46] <siretart> Dark_Shikari: I've mailed me that patch now and will look at it probably this afternoon. from the very first look, I spotted some spurious cosmetic only changes [08:08:20] <siretart> I need to do regression tests with ubuntu's current libx264 [08:08:39] <Dark_Shikari> it's not spurious [08:08:44] <Dark_Shikari> the intention is to update the libx264.c to the latest libx264.c [08:08:49] <Dark_Shikari> and then backport support for all previous x264s [08:08:58] <Dark_Shikari> in other words, it's a whole-file replacement [08:10:16] <siretart> oh, I see. OTW, it is not a patch but a replacement. [08:10:33] <Dark_Shikari> yes [08:10:38] <Dark_Shikari> though it's really neither [08:10:46] <Dark_Shikari> I tried to make the new file as simple as possible [08:10:51] <Dark_Shikari> i.e. as few ifdeffed code sections as necessary [08:11:32] <siretart> what about having these ifdef's in trunk, maybe only until the 0.6 branch opens? [08:11:41] <Dark_Shikari> no [08:11:50] <Dark_Shikari> we don't do this for any other codec [08:11:53] <Dark_Shikari> why do it for x264? [08:11:57] <Dark_Shikari> and for that matter [08:12:00] <Dark_Shikari> why aren't you whining about theora? [08:12:07] <Dark_Shikari> ffmpeg broke API to support theora 1.1 [08:12:12] <Dark_Shikari> theora 1.0 will no longer work with new ffmpeg [08:12:17] <Dark_Shikari> and theora 1.1 won't work with old ffmpeg and so forth [08:12:24] <Dark_Shikari> nobody has asked to ifdef that [08:13:51] <siretart> you claim that ffmpeg 0.5 didn't compile against libtheora 1.1? interesting that I didn't notice that [08:13:58] <Dark_Shikari> I thought it was [08:14:01] <Dark_Shikari> or maybe it's the other way around [08:14:04] <Dark_Shikari> i.e. 1.1 is backwards compatible [08:14:08] <Dark_Shikari> but you dont' get the new features without the api break [08:14:11] <Dark_Shikari> like 2-pass [08:14:45] <siretart> anyway, my idea was probably just a brainfart [08:14:57] <Dark_Shikari> we don't really do that kind of ifdeffing in trunk [08:15:02] <Dark_Shikari> otherwise you get VLC [08:15:10] <Dark_Shikari> have you even seen the x264 module in VLC? it's insnae [08:15:14] <Dark_Shikari> it tries to work with x264 back to 2005 [08:15:19] <Dark_Shikari> it has more ifdefs than lines of code [08:15:43] <siretart> still, we now have a rather non-trivial change proposed against ffmpeg 0.5, which diego and I will consider [08:15:59] <siretart> no promises, though [08:16:05] <Dark_Shikari> I did this for you [08:16:09] <Dark_Shikari> if you want to reject it, I lose nothing [08:16:34] <siretart> well, distros loose the oppurtunity to update x264 [08:16:44] <siretart> which I would find rather sad [08:16:55] <Dark_Shikari> I know. You care about that, so you will get this committed [08:17:03] <Dark_Shikari> and if you don't, you can patch ffmpeg in the distro packages. [08:17:13] <siretart> as said, I need to do regression tests [08:17:24] <Dark_Shikari> yes of course [08:17:31] <Dark_Shikari> test those revisions, both for compilation and encoding [08:43:48] <KotH> moin [08:44:11] <av500> grüezi wohl [08:44:40] <kshishkov> god morgon [09:00:04] <osaft> habe die ehre [09:00:35] <kshishkov> wir habt [10:04:26] <kshishkov> mate! [10:07:28] <KotH> club mate? [10:08:28] <kshishkov> no, just Australian cobber ;) [10:11:54] <pross-au> Hi [10:34:10] <kshishkov> pross-au: I'd like to integrate your BIKb decoder [10:52:53] <pross-au> ok [10:53:14] <pross-au> its 20% complete [10:53:25] <kshishkov> my decoder seems not to handle BIKb at all [10:53:34] <pross-au> yeah, its a rare beast [10:53:51] <pross-au> do you have samples? [10:53:52] <kshishkov> fould old Heroes of Might and Magic III disc [10:53:58] <pross-au> Ah [10:54:25] <pross-au> That's the only game that I am aware of [10:54:35] <pross-au> (and there is no sound IIRC in the BIKb files) [10:55:32] <kshishkov> well, your demuxer reports sound (but your decoder can't handle it though) [10:58:15] <kshishkov> (if lavc decoder would also support BIKb, that will be a big "take this!" to RAD tools) [10:58:46] <pross-au> Not even the current RAD Tools support BIKb [10:59:15] <pross-au> It must be the ugly duckling of the BINK clan :D [10:59:16] <kshishkov> exactly [10:59:32] <kshishkov> no, just too outdated [10:59:35] <pross-au> I mean to say, the HOMM3 bik files do no contain audio [10:59:37] <pross-au> *not [11:00:13] <kshishkov> of all 4 biks in there only one does not contain audio [11:00:23] <kshishkov> the rest at least should [11:01:07] <kshishkov> for example, NWCLOGO.BIK: Stream #0.1: Audio: binkaudio_rdft, 22050 Hz, 2 channels, s16 [11:03:45] <pross-au> Oh cool [11:03:50] <pross-au> Maybe i only have the HOMM3 demo [11:14:07] * kshishkov curses for his code to draw pattern block in Bink hath coordinates swapped [11:15:54] <jez9999> question: getaddrinfo() provides a struct sockaddr * to describe the address it's parsed. how does this fit in with sockaddr_storage, which is larger? [11:17:32] <kshishkov> you can fit smaller thing into bigger thing, what's the problem? [11:17:55] <jez9999> how does it return an ipv6 addy? i thought the whole idea of the storage struct was that it could hold ipv65 [11:17:57] <jez9999> *6 [11:19:02] <kshishkov> maybe you can treat it as a union [11:19:50] <pross-au> getaddrinfo() returns a pointer to 'something' [11:21:09] <jez9999> manpages say struct sockaddr* [11:21:34] <kshishkov> first two fields are common to all sockaddr_ structs [11:21:45] <jez9999> so you're saying to cast it [11:21:54] <kshishkov> the rest can be parsed from memory by those ss_len and ss_family [11:22:01] <kshishkov> yes [11:22:12] <kshishkov> you have ss_len which tells you real size [11:22:28] <kshishkov> and ss_family gives you real struct type as well [11:22:54] <jez9999> i dont understand why _storage has to exist at all then [11:22:58] <kshishkov> so just recast returned pointer to another struct pointer type, that's all [11:23:00] <jez9999> why not just use a struct sockaddr* [11:23:49] <kshishkov> because it defines maximum sockaddr* size [11:24:00] <twnqx> mmhh [11:24:29] <jez9999> but i don't want to cast to it [11:24:35] <jez9999> i want to cast to something like sockaddr_in [11:24:49] <kshishkov> as you like [11:24:57] <jez9999> so.... i'm never actually gonna use _storage [11:25:08] <kshishkov> could be so [11:25:14] <jez9999> so what's the point in it [11:25:18] <kshishkov> at least I've not [11:25:19] <jez9999> when would you need to practically use it? [11:26:18] <kshishkov> when you work with different sockaddr and need to pass it explicitly, not pointer [11:30:52] <jez9999> c#'s so much easier :-) [11:31:25] <kshishkov> now guess why most developers here are not so fond of C#, Java or similar? [11:32:29] <CIA-17> ffmpeg: pross * r21769 /trunk/libavformat/anm.c: Make DeluxePaint Animation demuxer actually return the find_record() error code (issue 1739). [11:32:38] <Dark_Shikari> kshishkov: http://www.chunder.com/text/ididit.html ;) [11:33:52] <pross-au> Nice Dark_Shikari [11:34:01] <kshishkov> Dark_Shikari: my favourite is where C claimed to be a joke [11:34:33] <kshishkov> http://www-users.cs.york.ac.uk/susan/joke/c.htm [11:37:41] <kshishkov> Dark_Shikari: I know you'll love it - Bink idct_add is not clamped [11:38:04] <Dark_Shikari> yup, just like VP8 [11:38:09] <Dark_Shikari> designed for shit systems with no saturating math [11:38:20] <Dark_Shikari> e.g. systems without simd [11:38:27] <kshishkov> no, Because Clamping Takes Cycles! [11:38:43] <kshishkov> and yes, it was designed for all kinds of systems [11:38:58] <pross-au> VP8 is the Duke Nukem Forever of video coding :D [11:39:13] <Honoome> pross-au: I thought snow was that already [11:39:19] <pross-au> or should that be: VP(n+1) [11:39:24] <kshishkov> pross-au: no, that's x264 [11:39:37] <pross-au> Haha [11:39:45] <Dark_Shikari> but x264 exists [11:39:51] <Honoome> so we basically have so many candidates… [11:39:57] <kshishkov> wake me up when it reaches 1.0 [11:40:12] * pross-au is waiting for x264-mvc [11:41:10] <Dark_Shikari> kshishkov: we're at 84.0 [11:41:14] <Dark_Shikari> 85.0 will come out in the next release [11:41:40] <kshishkov> ah, point taken [11:42:11] <bilboed-pi> Dark_Shikari, *awesome* link ! [11:42:13] * kshishkov moves x264 into "versions crazier than Emacs" category [11:43:30] <Honoome> kshishkov, for the *crazy* versions you should look at tex [11:43:57] <kshishkov> Honoome: _that_ is sane even if a bit transcedental [11:44:53] <pross-au> The world needs x264-mvc for making Avatar 3D backups [11:45:12] <Honoome> kshishkov, I'd say that its sanity is opinable [11:45:22] <kshishkov> pross-au: your sentence lacks several other popular buzzwords [11:45:28] <Dark_Shikari> pross-au: you don't need mvc [11:45:35] <Dark_Shikari> there's an SEI for that [11:45:42] <Dark_Shikari> you just stick the two views next to each other [11:45:47] <Dark_Shikari> encode at 1920x2160 [11:45:51] <Dark_Shikari> er, on top of each other [11:45:55] <kshishkov> Honoome: next thing you'd tell me that Lewis Carrol was not sane [11:46:01] <pross-au> Great [11:46:10] <Dark_Shikari> and you stick in the SEI [11:46:16] <Dark_Shikari> we could add support if anyone ends up supporting the sei [11:46:28] <kshishkov> I saw several stereoscopic movies encoded with WMV3 [11:53:42] <pross-au> Do we have a way of decoding such streams with FFmpeg? [11:54:46] <kshishkov> of course, they are just two pictures in one frame [11:56:05] <kshishkov> do you think I'd watch it with decoder by somebody else? [11:56:19] <pross-au> the SEI flags are reported back through AVCodecContext [11:56:20] <pross-au> ? [11:56:37] <kshishkov> unlikely [11:57:42] <pross-au> we have interlacing info reported back, so the same would be required for 3d [11:57:53] <pross-au> or more generically, multi-view. [12:02:16] <kshishkov> yep, 5-field video accompanied with 9.3 audio [12:04:41] <pross-au> That was be awesome for sports [12:04:48] <pross-au> *would be [12:04:59] * kshishkov has not interest in sports [12:05:11] <kshishkov> not even in cricket [12:05:12] <pross-au> Not even Australian Rules Football (AFL) ? [12:06:10] <kshishkov> of course not [12:06:19] <jai> you mean rugby? [12:06:43] <pross-au> jai: nope [12:06:46] <kshishkov> the only good thing in AFL is that it's not shown here and has not much fans here either [12:06:47] <jai> hmm [12:07:17] <pross-au> jai: it is unlike anything you've probably seen before [12:08:04] * KotH wonders whether australian rules allow the use of weapons [12:08:45] <jai> pross-au: i guess :) [12:36:04] <merbzt> http://www.youtube.com/watch?v=mkaeU-8b2jE [12:37:07] <kshishkov> not very original [12:38:08] <kshishkov> there was a similar Russian dub focused on the fact Russian 2G providers tried to butcher Skype [12:41:23] <merbzt> the funny part is that it is true [12:46:30] <kshishkov> indeed [12:47:23] <merbzt> http://www.youtube.com/watch?v=_K9AxO5t4BE [12:49:12] <kshishkov> Bollywood Action Film #1 ? [12:49:27] <twnqx> i know that the company where i currently sits tries to block skype's voicecalls, too [12:49:33] <twnqx> sit* [12:52:07] <iive> btw, isn't it better to code 3D movies as interlaced? [12:52:27] <KotH> instead of? [12:52:37] <KotH> twnqx: uhmm.. are tehy allowed to do that? [12:52:50] <iive> i mean, left picture as top field, right picture as bottom field [12:52:53] <pross-au> interlaced mvc haha [12:53:11] <twnqx> KotH: the contract explicitly says "no voice over ip of any kind" [12:53:35] <iive> instead of 2 separate pictures on the screen. it should allow to compensate from the other picture without need for huge vectors. [12:54:33] <KotH> twnqx: the contract can say a lot of things, but still, are they allowed? [12:54:50] <twnqx> it wasn't tried in court yet [12:55:00] <twnqx> but iguess they have a legal department to sort that out [12:55:03] <KotH> twnqx: afaik in .ch no telco carrier is allowed to restrict access to the net in any kind unless absolutely necessary for the working of the network [12:55:13] <KotH> lol [12:55:32] <KotH> half of the contracts we get in .ch contain stuff that are not legally allowed [12:55:45] <KotH> most of them made by large, multinational companies [12:56:35] <KotH> heck, even my work contract contains passages that contradict the law [12:57:22] <twnqx> :P [13:00:12] <KotH> hoi DonDiego [13:00:50] <av500> hey DonDiego [13:00:57] <DonDiego> heyho [13:01:13] <DonDiego> say, have you guys talked to the rockbox people at fosdem? [13:01:19] <av500> yes [13:01:27] <av500> alex has [13:01:39] <av500> and they are here a couple of days ago [13:01:41] <av500> were [13:03:10] <DonDiego> yes, that's why i'm asking.. [13:03:14] <DonDiego> good :) [13:03:25] <DonDiego> let's see if we get some results from this, i sure hope so.. [13:03:49] <av500> there is a thread on their devel ml [13:04:15] <av500> http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-02/0019.shtml [13:43:57] <Compn> kshishkov :? [13:45:03] <kshishkov> Compn: nevermind [13:45:17] * kshishkov has compiled MPlayer with Bink audio and video support [13:45:41] <Compn> what will the bink guy say?! :) [13:46:11] <Dark_Shikari> do remember the various versions of bink for different arches ;) [13:47:29] <kshishkov> mine runs on MacOSX/PPC [14:19:28] <kshishkov> BBB: why wmavoice is not in main SVN yet? [14:19:42] <BBB> I said I' dapply today [14:19:45] <BBB> so I'll apply now [14:19:52] <BBB> people wanted me to run zzuf on it [14:19:59] <BBB> and see if it crashes [14:20:06] <DonDiego> BBB: don't forget to: [14:20:06] <kshishkov> you did. it didn't [14:20:15] <DonDiego> proprietary_codecs--; [14:20:28] <BBB> DonDiego, which header is that variable in? [14:20:49] <kshishkov> probably multimedia wiki category [14:22:16] <DonDiego> BBB: it's a global variable [14:22:23] <DonDiego> and i mean *global* [14:22:27] <BBB> :) [14:22:37] <DonDiego> as in planet-wide [14:22:38] <DonDiego> :) [14:22:53] <BBB> oh right I should remove it from the undiscovered codecs page on the wiki [14:24:03] <CIA-17> ffmpeg: rbultje * r21770 /trunk/ (8 files in 3 dirs): WMAVoice decoder. [14:24:21] <BBB> better? [14:24:49] * kshishkov waits for mail [14:24:52] <Dark_Shikari> oh nice. [14:25:25] <Dark_Shikari> BBB: now we can bug you to do WVP2 [14:25:38] <kshishkov> hear! hear! [14:25:41] <jez9999> BBB: morning [14:25:46] <Compn> so is it a feature that lavf bails when it cant recognize a fourcc ? [14:26:02] <BBB> Dark_Shikari, I'm first working on the postfilter [14:26:05] <Dark_Shikari> k [14:26:09] <BBB> I did some wor yesterady [14:26:13] <BBB> won't take too long [14:26:14] <kshishkov> Compn: it does not, framecopy works [14:26:15] <BBB> I sort of get it now [14:26:19] <mru> Compn: what would you have it do? [14:26:28] <Compn> kshishkov : must be mplayer problem then [14:26:37] <superdump> BBB: is it at all similar to the AMR and QCELP post filters? [14:26:40] <jez9999> BBB: kindly check out patch3 for issue 1740, i addressed problems you raised [14:27:29] <Compn> Playing geov.avi. [14:27:29] <Compn> libavformat file format detected. [14:27:29] <Compn> [avi @ 0p1d58010]Could not find codec parameters (Video: GEOV / 0x564F4547, 720x240) [14:27:29] <Compn> LAVF_header: av_find_stream_info() failed [14:28:29] <Compn> yeah probably mplayer problem using lavf hmmmmm [14:29:04] <kshishkov> Compn: should be cured by "svn up libavformat/riff.c" [14:29:13] <Compn> yes that particular problem should be [14:29:20] <Compn> but i am speaking generally :) [14:29:27] <Compn> michael didnt close that bug on roundup [14:29:30] <Compn> thanks for reminding me [14:29:39] <mru> http://img.thedailywtf.com/images/201002/errord/errory.png [14:30:02] <av500> a tiff exploit :) [14:30:26] <BBB> jez9999, yes, will do [14:30:39] <DonDiego> mru: rotfl :-) [14:31:07] <BBB> superdump, it's similar, they all use tilt correction, but the WMAVoice one is a little more extended from what I could see... it's huge, probably the biggest part of the decoder (hence me skipping it :) ) [14:31:12] <kshishkov> av500: easier than you think [14:31:20] <Compn> mru : just pass the fourcc onto the application for it to handle? [14:31:37] <kshishkov> BBB: it's not rv40, so the codec should work fine even without it [14:31:59] <mru> Compn: what a ridiculous thing to do [14:32:14] <BBB> kshishkov, it works fine without [14:32:23] <BBB> just a little bit of clipping here and there [14:32:39] <Compn> mru : in most cases for avi , the video codec doesnt require any more parsing... [14:32:48] <mru> oh god.... [14:32:51] <Compn> heh [14:32:54] <mru> the world is not made of avi [14:32:54] <kshishkov> Compn: you have Matroska [14:33:40] <kshishkov> why it's so hard to make codec handling in container independent on codec type? [14:33:58] <Compn> padding ? [14:34:15] <Compn> timestamps ? [14:34:35] <av500> granule [14:34:57] <kshishkov> ogg to you too [14:38:45] <lu_zero> BBB: did you ever try to issue ffmpeg -i rtsp://some/valid/url ? [14:39:15] <BBB> I only use ffplay, to be honest [14:39:18] <BBB> why, doesn't it work? [14:40:05] <lu_zero> it has a fun behaviour when you forget a / [14:40:21] * lu_zero is messing a bit with ffmpeg and feng eventually [14:40:41] <mru> kshishkov: it's not hard [14:40:50] <mru> but there is no standard on codec identifiers [14:40:58] <DonDiego> BBB: don't listen to the italian please! [14:41:02] <mru> or there are several [14:41:21] <DonDiego> wherever you have to go with him, make sure you know the way yourself! [14:41:22] <lu_zero> hi DonDiego =P [14:41:23] <mru> the mpeg registration descriptor is standard of course [14:41:26] <BBB> lu_zero, I thought I fixed that? [14:41:34] <DonDiego> lu_zero: ;-p [14:41:36] <BBB> lu_zero, earlier, I applied a patch to add the '/' when missing [14:41:41] <BBB> lu_zero, are you using latest svn? [14:41:43] <lu_zero> BBB: it works it's just funny [14:41:50] <lu_zero> let me sync [14:41:55] <lu_zero> it's 2-3 days ago [14:41:58] <BBB> what's the fun bejaviour? [14:42:06] <BBB> s/j/h/ [14:42:18] <Compn> mru : what about continuing when audio is known and just drop video stream ? [14:42:41] <bilboed-pi> BBB, congrats on getting wmavoice in [14:42:45] <mru> Compn: you can do that [14:42:48] <BBB> bilboed-pi, ty [14:42:49] <Compn> bilboed-pi : we tried to stop him :D [14:42:50] <mru> might need -vn [14:42:52] <lu_zero> rtsp:/path/to/resource gets feed as /path/path/to/resource [14:42:53] <bilboed-pi> Compn, :) [14:43:01] <mru> lavf doesn't care [14:43:14] <Kovensky> mru: http://esr.ibiblio.org/?p=1694 :D [14:43:38] <Compn> mru : ok, then probably hitting mplayer bug [14:44:20] <lu_zero> btw [14:44:26] <lu_zero> how was the troll beer? [14:44:36] <BBB> lu_zero, really? [14:44:49] <BBB> lu_zero, that sounds like a bug [14:44:55] <BBB> lu_zero, does it work? [14:44:56] <lu_zero> BBB: I was wondering [14:45:02] <lu_zero> rtsp:// works correctly [14:45:23] <BBB> submit an issue on roundup, probably a silly bug somewhere [14:47:13] <lu_zero> where is the code for parsing uris and how did you touch it? [14:47:50] <BBB> is this the time where I run away trying to stay alive? [14:48:03] <BBB> I think it's control uri parsing [14:49:00] <lu_zero> sigh [14:49:05] * lu_zero got preempted again [14:49:24] <lu_zero> anyway it should just error out if you feed rtsp:/ instead of // [14:55:24] <Compn> that it should [14:56:50] <Compn> mru : oops, it was my fault, lavf does pass the fourcc to mplayer, just the audio was broken too [14:56:54] <Compn> so it passed nothing :) [14:57:27] <Kovensky> Compn: btw, does ffmpeg://http:// work for you (on mplayer)? [14:57:31] <Kovensky> or whatever other protocols [15:00:22] <DonDiego> one quick user question: is it possible to pass mp3lame-specific params to ffmpeg, e.g. --preset normal? [15:00:38] <DonDiego> i find no hint in libavcodec/libmp3lame.c [15:00:52] <Compn> Kovensky : lets take this to #mplayer.. [15:04:02] <superdump> BBB: you're the rtsp person aren't you? well, and luca abeni [15:04:04] <superdump> rtsp://video2.multicasttech.com/AFTVSciFiH2641000.sdp [15:04:07] <superdump> have fun with that [15:05:30] <BBB> works for me? [15:06:16] <Compn> outputs 56 bytes and then dies with mplayer [15:06:17] <Compn> rtsptext [15:06:17] <Compn> rtsp://63.105.122.35:80/AFTVSciFiH2641000.sdp [15:07:09] <BBB> that's because mplayer's rtsp stack sucks [15:07:13] <BBB> works fine for me [15:07:15] * BBB ducks [15:08:30] <BBB> superdump, how long is that? :) [15:08:46] <BBB> btw the sync is bad, I think it's because it's h264, waiting for that fix luca and I were discussing on the mailinglist [15:08:47] <bilboed-pi> it's a live stream [15:08:51] <BBB> lu_zero: can you apply? [15:09:09] <superdump> BBB: works fine for you? [15:09:15] <BBB> it's live? [15:09:18] <BBB> it's an old movie! [15:09:18] <superdump> i'm using trunk ffmpeg and ffplay doesn't play anything [15:09:21] <superdump> it just sits there [15:09:34] <BBB> I'm forcing tcp, that may be why [15:09:34] <bilboed-pi> BBB, it's a tv station, that's what I meant [15:09:41] <BBB> bilboed-pi, oh, ok [15:09:43] <BBB> that makes sense [15:09:49] <BBB> superdump, try forcing tcp [15:10:01] <BBB> add ?tcp at the end [15:11:13] <Compn> lol live-old-movie [15:11:13] <Compn> :D [15:13:06] <BBB> I'm assuming that means it works for you :) [15:13:07] <BBB> \o/ [15:13:12] <BBB> let's work on the postfilter then [15:13:36] <bilboed-pi> shouldn't it figure out it should switch to tcp though ? [15:14:28] <BBB> martin has patches that lead there [15:14:32] <BBB> so that'll land [15:14:47] <BBB> (so yes) [15:16:02] <DonDiego> yv: so you remembered your nickserv pw? [15:16:04] <DonDiego> :) [15:16:25] <DonDiego> fellow fosdem visitors, say hello to yvonne.. [15:16:54] <yv> hey everybody :) [15:17:25] <mru> yv: hi [15:18:27] <av500> yv: hi [15:18:32] <av500> err, hello [15:18:41] <mru> there's a difference? [15:18:55] <av500> [16:16] <DonDiego> fellow fosdem visitors, say *hello* to yvonne.. [15:19:15] <mru> I would've assumed any synonym would do [15:19:54] <av500> yv: hallo [15:20:21] <DonDiego> av500: this somehow reminds me, where does your nickname come from? [15:20:57] <av500> its my root pwd :) [15:21:43] * av500 sees incomming traffic spike [15:22:18] <av500> DonDiego: it is one of our earlier product names [15:22:34] <mru> so you're an old model? [15:22:38] <av500> yes [15:23:04] <Compn> still under warantee? [15:23:21] <av500> voided that one long ago [15:23:36] <Compn> ack , cant spell [15:24:02] <mru> removed the sticker? [15:33:24] <av500> which of the 3 ways to specify aspect ratio in mp4 is considered the authorative? [15:33:53] <kshishkov> the one written in standard in less ambiguous way [15:35:43] * av500 sighs [15:42:13] <mru> reynaldo: http://www.theregister.co.uk/2010/02/12/chiiean_mint/ [15:45:35] <BBB> does anyone know what the meaning of applying lpcs to the synthesized speech samples is in voice codecs? [15:45:55] <kshishkov> to make it sound more realistic? [15:46:04] <BBB> like applying lpcs to the excitation signal is "speech synthesis", what happens if you apply the lpcs again to the speech synthesis? [15:46:11] <ohsix> smooth out discontinuities? [15:46:23] <BBB> hmm... [15:46:42] <mru> is that what politicians use? [15:47:30] <kshishkov> no, they simply shape noise [15:47:46] <ohsix> like fox news [15:49:12] * kshishkov thinks they should have named original company "XX century weasel" in the first place [15:50:00] * av500 watches http://hci.rwth-aachen.de/~jansen/swords.mov [15:51:30] * kshishkov watches "Monkey Dust" series [15:52:24] <BBB> seems a smoothening method indeed [15:52:29] <BBB> weird [15:53:25] <kshishkov> sounds like an analog of LTP [15:53:59] <BBB> long-term potentiation? [15:54:16] <BBB> the math is identical to speech synthesis, which is funny [15:54:23] <BBB> why would they write two functions doing the exact same thing? [15:54:43] <kshishkov> long-term prediction, you know - an additional MDCT in AAC for example [15:54:47] <BBB> the only difference is that one caches its own history through a copy to internal buffers, whereas the other uses the external buffer for history caching [15:55:08] <kshishkov> BBB: look at fspp filter in MPlayer [15:55:51] <kshishkov> applying two functions out of phase sorta cancels edge artifacts [15:57:28] * jez9999 is about to go home from work [15:57:52] <BBB> jez9999, I [15:58:01] <BBB> jez9999, I'll review the patch, but not right now yet [15:58:19] <BBB> actually, let me do it right now [15:58:21] <BBB> better that way [15:58:48] <kshishkov> BBB: if you have another codec patch, I'll review it. Especially WM-based ;) [15:59:18] <BBB> yeahyeahyeah, I'll do wvp2 if no soc student shows up [15:59:50] <kshishkov> :) [15:59:57] <kshishkov> WMAL? [16:01:53] <BBB> I thought jai was doing that [16:01:55] <BBB> I could, though [16:02:03] <BBB> I have the whole thing setup already [16:02:08] <BBB> same binary [16:04:02] <jez9999> BBB: thanks, i'll address those points soon [16:04:03] * kshishkov wants something to debug WMV decoding dll [16:04:16] * pJok hands kshishkov a hammer [16:04:32] <kshishkov> you can't hit dll with a hammer :( [16:04:48] <pJok> not directly, no [16:04:49] <kshishkov> otherwise I would have used it [16:04:54] <pJok> but you can debug things with a hammer [16:06:27] * kshishkov would like to debug WMV creators with a hammer [16:14:28] <Compn> so does wvp2 store the text in text or bitmaps or just combine them together crazily ? [16:14:46] <kshishkov> who knows? Probably bitmaps [16:15:09] <kshishkov> and it's not vector either [16:23:50] <astrange> BBB: do you know if flip4mac has a noisy wmavoice decoder? [16:24:08] <astrange> i always wondered if they used ms code [16:26:29] <kshishkov> they did [16:26:42] <DonDiego> av500: haha, the swords one is funny.. :) [16:26:47] <kshishkov> same as Linspire [16:27:17] <kshishkov> IIRC, there are only two independent decoders for Windows Media - FFmpeg and M$ [16:27:54] <av500> kshishkov: for x86 maybe [16:28:19] <kshishkov> Linspire used their source for pocketpc version [16:28:34] <av500> DonDiego: beats the usual "chicks with guns" vids :) [16:28:58] <kshishkov> av500: Windows Mobile plays .wmv on ARM after all... [16:29:32] <reynaldo> mru: good one. Didn't know about it. will see if I can find one :) [16:29:37] <DonDiego> av500: lol :) [16:36:57] <BBB> astrange, they don't have any [16:37:05] <BBB> astrange, see their website [16:38:29] <kshishkov> BBB: flip4mac features are presented at microsoft.com [16:39:10] <BBB> http://www.telestream.net/flip4mac-wmv/tech-specs.htm - bottom [16:39:24] <BBB> "Unsupported codecs: [..] voice [..]" [16:39:29] <kshishkov> http://www.microsoft.com/windows/windowsmedia/player/wmcomponents.mspx [16:39:48] <kshishkov> from some link at flip4mac.com [16:40:09] <BBB> right, so as you can see, no voice/speech [16:40:27] <kshishkov> nor MSS[12] or WMVP/WVP2 [16:40:32] <BBB> right [16:40:41] <BBB> also on that tech-specs page I just pasted [16:40:43] <BBB> unsupported: [16:40:47] <BBB> * Screen (ACELP.net) [16:40:48] <BBB> * Image [16:40:48] <BBB> * Voice [16:40:48] <BBB> * Direct Show AC3 Filter [16:40:48] <BBB> * GoToMeeting (G2M) [16:40:48] <BBB> * GoToWebinar [16:41:04] <kshishkov> WTF is the first one?!?! [16:41:56] <BBB> I dunno, it sounds like a maerge between sipro anc svp2 [16:41:59] <BBB> er, wvp2 [16:42:07] <BBB> maybe it's so complex they couldn't imlpement it [16:42:28] <kshishkov> maybe it reconds screen to speech? [16:42:52] <kshishkov> I'm pretty sure they used the same code as Linspire [16:44:21] <BBB> I have a lossless codec impl, might look into that also if jai doesn't [16:45:47] <BBB> first postfilter though [16:45:52] <BBB> it doesn't look too complicated [16:45:58] <BBB> lots of memory duplication [16:46:09] <BBB> I think the postfilter was developed separately from the codec [16:46:11] <BBB> looks horrible [16:46:28] <BBB> private memory caches for every variable, etc. [16:55:02] <kshishkov> copy-pasted from somewhere else, I think [17:00:22] <av500> mru: android switches from gcc to llvm [17:00:53] <kshishkov> av500: still better than javac [17:00:59] <mru> I still haven't figured out how to build an llvm arm cross-compiler [17:01:09] <av500> wait for gg to release one :) [17:01:47] <mru> and I'm not going to fuck around with svn checkouts that may or may not work at all [17:02:17] <peloverde> ahh, what we ask others to do [17:02:42] <kshishkov> peloverde: FFmpeg is much easier to compile [17:02:45] <mru> the difference is that our svn usually works fine [17:02:53] <av500> peloverde: we do releases now, no? :) [17:02:55] <peloverde> VP6 has been broken for quite a while now [17:03:07] <mru> and building it doesn't involve combining a dozen pieces that usually don't fit [17:04:02] * kshishkov once tried compiling Firefox on Celeron-800, 256MB RAM, ~GB free HDD [17:05:33] <av500> kshishkov: still compiling? [17:05:52] <kshishkov> av500: of course not, it ran out of disk space pretty soon [17:06:18] <kshishkov> maybe producing five copies of each component during making is not a good idea [17:07:30] <jai> llvm-svn targeted for x86 seems to work pretty decently [17:07:33] <jai> fwiw [17:07:49] <jai> (i update twice a week, no problems so far) [17:08:18] <mru> my only attempt at configuring an arm compiler still only compiled to x86 [17:08:36] <kshishkov> jai: so you update right after it finished compiling? [17:09:04] <jai> kshishkov: the compile times are quite okay, < 10mins on a core2 [17:09:20] <jai> that includes clang as well [17:09:30] <kshishkov> what is core2? [17:09:44] <mru> one more than core1 [17:09:50] <av500> jai: I can imagine that gg sits on a shitload of patches for llvm that will magically appear soon [17:10:14] <merbzt> gg ? [17:10:14] <jai> core2 duo @ 2Ghz to be precise :) [17:10:20] <av500> google [17:10:33] <av500> [18:00] <av500> mru: android switches from gcc to llvm [17:11:06] <jai> av500: hmm, well if they did have a patchset, the very least they could do is publish it somewhere [17:11:08] <kshishkov> jai: and I don't have _anything_ > 1.5GHz. And nothing x86 >= 1GHz [17:11:37] <av500> jai: yes, they will, but they like to develop for themselves and then drop it all in one [17:11:56] <jai> av500: yep, seen them do that with webkit before [17:12:07] <av500> they are "open", but not more than needed :) [17:12:15] <peloverde> I projects people that do big code dumps like that [17:13:00] <__gb__> kshishkov, what non x86 is > 1 GHz? Some newe Godson 2g or 3? :) [17:13:03] <av500> I guess they dont want to give a hint what they work on... [17:13:18] <av500> __gb__: snapdragon is 1.5 [17:13:55] <kshishkov> __gb__: 1.42GHz PowerPC of course [17:14:32] <jai> we can assign all the endianness issues on roundup to kshishkov ;) [17:14:45] <__gb__> kshishkov, all, all G4 :) [17:14:55] <__gb__> s/all/old/ [17:15:15] <av500> err, ps3 or xbox has >1 ghz powerpc, no? [17:15:24] <kshishkov> jai: you have mru for that [17:16:09] <kshishkov> __gb__: the only state of the art CPU I have is Loongson 2F. Too bad that art is Chinese. [17:16:11] * mru has a ppc g4 available to all ffmpeg devs [17:16:23] <mru> chinese state art... [17:16:31] <Honoome> haha :) [17:16:39] <DonDiego> peloverde: what about vp6? [17:16:44] <jai> kshishkov: loongson based netbook? [17:17:02] <kshishkov> jai: yes, that Gdium I occasionally mention [17:17:09] <jai> kshishkov: ah, ok [17:17:18] <kshishkov> DonDiego: it segfaults of some platforms - see FATE [17:19:34] <DonDiego> bah [17:20:28] <DonDiego> bye [18:19:28] <CIA-17> ffmpeg: reimar * r21771 /trunk/libavcodec/iff.c: Use int8_t instead of char, the signedness of char can differ between systems. [18:36:27] <peloverde> Is there ever a valid reason to use memalign-hack on linux+glibc? [18:36:42] <kshishkov> should be none [18:36:42] <mru> no [18:37:48] <peloverde> that's what I thought, they turned it on for chromium's ffmpeg for some reason [18:37:56] <mru> idiots [18:38:02] <peloverde> probably cargo-cult ./configure [18:38:15] <peloverde> I already told them to turn it off [18:38:37] <mru> did they pass --disable for every ppc and arm cpu extension too? [18:39:22] <kshishkov> probably the same configure line for all arches [18:39:57] <peloverde> no they didn't disable all that stuff [18:55:33] <Kovensky> why is memalign-hack a configure option anyway [18:55:52] <mru> so people can turn it on if it's not detected [18:56:22] <Kovensky> and why do we have to turn it on when configure does detect it is needed instead of turning it on automatically (warn, whatever, but why abort?) [18:56:39] <mru> that I don't know [19:11:28] <peloverde> It was proposed at one point but someone made a big stink about it [19:12:48] <mru> as always [19:21:24] <Compn> is the contact at chrome a google employee? [19:21:30] <Compn> chromium* [19:24:19] <peloverde> yes [19:24:32] <peloverde> why? [19:25:50] <peloverde> Also I enjoy how the changes I've made to statisfy people' [19:25:59] <peloverde> s SBR complains have made the decoder 10% slower [19:26:15] <CIA-17> ffmpeg: michael * r21772 /trunk/libavcodec/ (h264.c avcodec.h options.c): [19:26:15] <CIA-17> ffmpeg: Try to support truncated h264 frames mixed with mpeg pes headers in mkv. [19:26:15] <CIA-17> ffmpeg: Fixes issue1585 [19:26:21] <kshishkov> we can manage [19:27:10] <kshishkov> maybe it's good to be able to disable SBR decoding in runtime for lousier systems though [19:27:20] <kshishkov> (just a thought) [19:28:27] <Compn> erm , i was just hoping someone would bug another google contact re ffmpeg + youtube :D [19:29:07] <kshishkov> bug On2 about TM2X [19:30:43] <peloverde> To a degree the changes will probably make it faster in the long run but not until a huge pile of SIMD code is written [19:31:49] <astrange> youtube doesn't admit they use ffmpeg so it'd be hard to have a contact [19:32:07] <astrange> but it'd be skal anyway, i think he knows what's going on already [19:32:53] <Compn> i dont need them to admit it [19:32:55] <peloverde> I've asked the chrom(e|ium) people for youtube patches a few times [19:33:12] <Compn> i just want samples and maybe anonymous patches :P [19:38:57] <astrange> i think youtube would just sandbox absolutely everything rather than do an audit, anyway [19:39:58] <_av500_> btw utube delivers still while it uploads, nice [19:40:07] <_av500_> stills [19:54:08] <Compn> hehe [19:54:21] <Compn> kshishkov : why are you so interested in tm2x? for that one sample we have? [19:54:31] <Compn> of the upsidedown bat... :) [19:55:10] <kshishkov> two samples and proprietary_codecs-- sake [20:12:58] <Compn> hehe [20:23:05] <thresh> love it: http://9gag.com/photo/18395_full.jpg [20:27:42] <Dark_Shikari> siretart: got a chance to try my patch yet? [20:29:50] <siretart> I'm looking at it right now [20:30:20] <Compn> thresh : looks racist somewhat... [20:30:55] <mru> only if you want to [20:31:35] <mru> it's a matter of fact that tribal wars occupy a large part of africa [20:32:27] <mru> there's absolutely nothing wrong with african people [20:32:36] <mru> but the society there is pretty fucked up [20:32:53] <kierank> because europeans arbitrarily divided the country [20:32:57] <Compn> except in that picture they are represented as still being unevolved? [20:33:00] <kierank> continent* [20:33:03] <thresh> Compn: yeah, I hate how they painted Russians as kalashnikov holders [20:33:05] <mru> their society is unevolved [20:33:40] <mru> so let's all laugh at the american [20:33:42] <mru> that's safe [20:33:47] <Compn> haha [20:33:58] * Compn should lose some weight [20:34:52] <Compn> google has a killer website optimizer project going now [20:34:58] * Compn watches 5 minute demo [20:35:28] <Compn> variable html with visitor tracking statistics! [20:35:59] <twnqx> self-modifying hmtl? [20:36:22] <CIA-17> ffmpeg: michael * r21773 /trunk/libavformat/ (img2.c utils.c avformat.h): [20:36:22] <CIA-17> ffmpeg: Add flag so muxers not needing width/height can signal this. [20:36:22] <CIA-17> ffmpeg: Add this flag to img2 (fixes -vcodec copy to image2 in some cases) [20:37:03] <Compn> no, i think you just add google's tracking html [20:42:31] <siretart> Dark_Shikari: can you perhaps explain me the ffpreset changes? you mentioned two days ago that your patch doesn't bring any new functionality to libx264.c? [20:42:47] <Dark_Shikari> it allows you to use the new x264 options [20:43:03] <Dark_Shikari> If they're available. [20:44:16] <thresh> Dark_Shikari: sorry for being an ass, but what's your ETA to push x264 fixes? [20:44:40] <Dark_Shikari> what x264 fixes, you mean the backport to 0.5? [20:44:44] <Dark_Shikari> I already gave the patch to siretart [20:44:52] <Dark_Shikari> brb lunch [20:45:00] <thresh> no, that's totally unrelated, i mean arm fixes for libx264 itself [20:52:05] <BBB> Compn, re: google & youtube, I'm still trying [20:52:09] <BBB> but not getting any response [20:52:13] <BBB> just a "we'll ask" [20:52:14] <BBB> and then nothing [20:52:15] <BBB> :( [20:52:37] <lu_zero> hi tresh [20:55:37] <thresh> hey lu_zero [20:58:18] <Dark_Shikari> thresh: oh, that one [20:58:21] <Dark_Shikari> I'm waiting on pengvado [20:58:24] <Dark_Shikari> I now have 15 local commits or so [20:58:47] <Dark_Shikari> siretart: ? [20:58:53] <Compn> BBB : dang, i've been mailing daniel berlin from google and getting the same results. [20:59:03] <siretart> Dark_Shikari: yes? [20:59:15] <mru> Compn, BBB: what are you probing google about? [20:59:41] <Dark_Shikari> siretart: I answered your question about the option changes and so forth... any issues with that? [21:01:24] <siretart> Dark_Shikari: I'm still trying to do an estimation on the regression potential [21:02:13] <Dark_Shikari> siretart: well, the _reason_ why we need the changes [21:02:21] <Dark_Shikari> is that if wpredp is left at default instead of made an option [21:02:27] <Dark_Shikari> people will not be able to encode for any baseline profile device [21:02:29] <Dark_Shikari> like ipods. [21:02:35] <Dark_Shikari> because wpredp is main profile and they won't be able to turn it off. [21:02:43] <Dark_Shikari> that's why the presets have to be changed as well [21:03:38] <siretart> ah, I see [21:05:06] <Compn> mru : trying to get access to unplayable/crashing/strange samples from youtube, or any patches they may have made to ffmpeg (or its decoders, if its using mencoder) [21:05:18] <Compn> since google bought youtube... [21:05:38] <Compn> and since google has been so nice to open source these past few years [21:06:09] <mru> I thought it was official google policy to not mention ffmpeg wrt yt [21:06:40] <Dark_Shikari> yeah [21:06:42] <Compn> if so, we would still accept anonymous patches and/or samples [21:06:50] <Dark_Shikari> google official policy is to not admit they use open source [21:06:51] <Dark_Shikari> whenever possible [21:06:52] <Dark_Shikari> >_. [21:06:53] <Dark_Shikari> >_> [21:06:54] <Compn> doesnt have to be from blah@google.com [21:07:00] <Dark_Shikari> of course [21:07:01] <Compn> can be from joeblow@not-google.com [21:07:10] <Dark_Shikari> but you can feel free to harass pascal to send something anonymously if yo uwant [21:07:10] <mru> @gmail [21:07:15] <Dark_Shikari> lol [21:07:48] <Compn> is pascal high up in google heirarchchy ? [21:08:09] <Compn> daniel is google code manager... [21:08:12] <Compn> i think [21:08:17] <mru> doesn't matter where he is [21:08:23] <mru> anyone with access to the code can send patches [21:08:38] <Compn> does he have access to the code? [21:08:40] <Dark_Shikari> pascal is one of the main guys on the youtube backend [21:08:45] <Compn> ah [21:08:46] <Dark_Shikari> he wrote their bad h264 encoder [21:09:18] <mru> how bad is it? [21:09:30] <Compn> its so bad... <insert joke here> [21:09:33] <mru> "it's not x264" isn't a valid answer [21:09:54] <mru> why'd they write their own? [21:10:04] <siretart> Dark_Shikari: http://pbot.rmdir.de/81aef377e36912dd36ad70c78da6a6ce [21:11:20] <kierank> harrass the people from @youtube.com on ffmpeg/x264 mailing lists ;) [21:11:23] <Dark_Shikari> siretart: oops [21:11:26] <Dark_Shikari> one mistake in the patch [21:11:51] <Dark_Shikari> siretart: change [21:11:52] <Dark_Shikari> + x4->params.i_bframe_pyramid = avctx->flags2 & CODEC_FLAG2_BPYRAMID; [21:11:52] <Dark_Shikari> to [21:11:55] <Dark_Shikari> + x4->params.b_bframe_pyramid = avctx->flags2 & CODEC_FLAG2_BPYRAMID; [21:11:57] <Dark_Shikari> done. [21:12:47] <siretart> indeed, that helps [21:17:22] <twnqx> meh, stupid atom [21:17:26] <astrange> skal wrote an h264 encoder (xvid avc) before joining google [21:17:35] <twnqx> has problems playing video while compiling gentoo updates [21:22:51] <mru> my latest arm is probably faster [21:23:00] <mru> dual 1GHz cortex-a9 [21:23:28] <thresh> what's the device? [21:23:35] <mru> tegra2 devboard [21:26:16] <siretart> Dark_Shikari: it seems that at least "basic" encoding does work with 0.5 and x264 api version 67 [21:42:20] <Kovensky> wow, that's ancient :D [21:44:44] <siretart> Dark_Shikari: please have a look at http://pbot.rmdir.de/2b1028414d0e87dd7e3457303c1cd860 [21:45:17] <siretart> Dark_Shikari: should the preset encode to main profile? according to the output, its baseline profile [21:47:49] <twnqx> mru: you got the 250? [21:49:41] <mru> yeah [21:51:35] <twnqx> cool [21:54:23] <mru> it's a bit unfriendly [21:58:25] <Kovensky> mru: heck, your a9 is probably faster than my pentium dual-core =p [22:01:20] <CIA-17> ffmpeg: conrad * r21774 /trunk/libavcodec/vp3.c: Remove unused code that's moved elsewhere [22:02:10] <CIA-17> ffmpeg: conrad * r21775 /trunk/libavcodec/vp3.c: Theora 3.4 doesn't exist; these fields were misunderstandings of the spec [22:02:11] <CIA-17> ffmpeg: conrad * r21776 /trunk/libavcodec/vp3.c: Export Theora colorspace info if present [22:02:14] <CIA-17> ffmpeg: conrad * r21777 /trunk/libavcodec/vp3.c: Move apply_loop_filter above render_slice, it'll be used by the latter soon [22:02:14] <CIA-17> ffmpeg: conrad * r21778 /trunk/libavcodec/vp3.c: [22:02:14] <CIA-17> ffmpeg: Do loop filter per-row rather than per-frame [22:02:14] <CIA-17> ffmpeg: 3% faster on Elephants_Dream_HD-q7-aq7.ogg on my penryn [22:02:15] <CIA-17> ffmpeg: conrad * r21779 /trunk/libavcodec/vp3.c: Cosmetics: reindent [22:02:15] <CIA-17> ffmpeg: conrad * r21780 /trunk/libavcodec/vp3.c: Implement CODEC_CAP_DRAW_HORIZ_BAND for VP3 decoder [22:02:16] <CIA-17> ffmpeg: conrad * r21781 /trunk/libavcodec/vp3.c: [22:02:16] <CIA-17> ffmpeg: Don't pre-calculate first_pixel [22:02:17] <CIA-17> ffmpeg: 3.6% faster on Elephants_Dream_HD-q7-aq7.ogg on my penryn [22:02:17] <CIA-17> ffmpeg: conrad * r21782 /trunk/libavcodec/utils.c: Special case VP5/6 chroma alignment on x86 as well [22:17:44] <J_Darnley> Can someone explain a value printed in the first line of a seek test? Specifically, the "pos" value. [22:18:46] <mru> I guess it's the pos [22:20:05] <J_Darnley> Of what? I'm trying to make sure that when I cause a change, it is correct [22:20:29] <mru> rtfs [22:21:35] <J_Darnley> Yeah, thanks [22:21:48] <mru> sorry, I don't know it any better than you do [22:22:08] <mru> and now I'm going out [22:42:54] <siretart> Dark_Shikari: seems that I didn't quite grok the preset and your patch seems to work so far [23:29:26] <CIA-17> ffmpeg: michael * r21783 /trunk/libavcodec/h264.c: [23:29:26] <CIA-17> ffmpeg: Dont drop B frames without last_picture. [23:29:26] <CIA-17> ffmpeg: Fixes issue1722