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

[irc at mansr.com]

[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 at google.com
[21:07:00] <Dark_Shikari> of course
[21:07:01] <Compn> can be from joeblow at 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