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

[irc at mansr.com]

[01:31:18] <mfg> Is there an example (other than mov and DV) of a demuxer opening another demuxer? I need this for a shoutcast demuxer, but it doesn't really look like that sort of thing is supported (except for dv/mov, but that is too specific).
[01:32:24] <Dark_Shikari> I know a format that requires that (vorbis in ogg in avi) but ffmpeg doesn't do that
[01:34:03] <mfg> any other suggestions?
[01:34:14] <mfg> I think I've run out of ideas.
[01:53:42] <Yuvi> Dark_Shikari: pretty soon, I'm merging & sending patches now actually
[02:02:56] <CIA-17> ffmpeg: conrad * r21736 /trunk/libavcodec/x86/dsputil_mmx.c:
[02:02:56] <CIA-17> ffmpeg: Enable SSE2 (put|avg)_pixels_16_sse2
[02:02:56] <CIA-17> ffmpeg: SVQ1 chroma has been special-cased aligned to 16-bytes since at least r15466
[02:02:56] <CIA-17> ffmpeg: Other architectures also assume 16-byte alignment here too but set STRIDE_ALIGN
[02:02:56] <CIA-17> ffmpeg: to 16.
[02:21:23] <Dark_Shikari> k
[02:23:00] <Dark_Shikari> Yuvi: ah nice, horizontal band approach
[02:23:06] <Dark_Shikari> 64 pixel high bands?
[02:23:34] <Dark_Shikari> how did you handle the weird deblock ordering where it's required that you deblock the bottom row in that weird order
[02:23:34] <Yuvi> 16 for the moment, rendering in coding order is next which will be 64 pixels high
[02:24:07] <Yuvi> by deblocking up to current block row - 1, then doing a separate run for the last row
[02:24:30] <Dark_Shikari> works
[02:25:58] <Yuvi> I'm tempted to just screw the order and do it sanely, but I'd imagine it would become something new for others to bitch at us about
[02:26:21] <Dark_Shikari> well it's not bit exact
[02:26:46] <Dark_Shikari> and unlike say mpeg-2, we can't get away with non-bit-exactness
[02:29:31] <Yuvi> yeah, though it'd be pretty much invisible
[02:29:55] <Yuvi> I mean, completely disabling the loop filter doesn't look horrible even at low rates surprisingly
[02:31:01] <Compn> mfg : i think thats all of them. both wmv (asx/wmx) and rm (smi/smil) have redirectors, but both of those are sane text formats...
[02:31:17] <Compn> well, more sane than binary anyways. damn xml
[02:31:38] <mfg> Compn: its not redirection.  I'm trying to cover the ogg/vorbis of shoutcast
[02:31:59] <mfg> *of=over
[02:32:04] <Compn> why would it need two demuxers ?
[02:32:18] <Compn> shoutcast is stream like http ?
[02:32:45] <mfg> yes, over http. but interleaved in normal stream data are blocks of metadata
[02:33:03] <Compn> ah
[02:33:26] <mfg> so, the shoutcast demuxer needs to rip them out, and then pass a "normal" stream along to the child demuxer (mp3/ogg/etc)
[02:33:32] <mfg> at least, this is how I envision it.
[02:33:47] <Compn> mfg : you should actually ask ffmpeg devs how they want it
[02:34:10] <Compn> because i know mplayer does shoutcast w/ metadata and its not calling two demuxers iirc
[02:34:35] <mfg> yes.  FFMPEG doesn't call any demuxers. It handles the stream outside of ffmpeg (from what I recall)
[02:34:38] <Compn> something in the streaming just says if metadata do this if mp3 pass to mp3...
[02:35:08] <mfg> sorry, mplayer doesn't call any demuxers
[02:35:15] <mfg> in teh case of shoutcast, the stream is handled in mplayer.
[02:35:40] <Dark_Shikari> Yuvi: put it under lavdopts fast?
[02:37:02] <Yuvi> does that set skip_loop_filter?
[02:39:07] <Dark_Shikari> dunno
[02:39:12] <Dark_Shikari> probably skiploopfilter=all does =p
[07:00:11] <benoit-> good (snowy) morning
[07:00:42] <kshishkov> bonjour
[07:01:04] <kshishkov> here we have ordinary slippery icey morning
[07:01:45] <thresh> moroning
[07:01:46] <thresh> i'm not even sleepy, though i slept for 12 hours
[07:02:25] <kshishkov> thresh: зимняя спячка значит, как у медведей
[07:06:38] <thresh> kshishkov: это да, я спать раза в полтора стал зимой больше, чем летом
[07:40:05] <KotH> salut
[07:40:13] <kshishkov> hej
[07:44:27] <_av500_> ho
[07:45:17] * _av500_ tries to decypher secret russian code
[07:46:04] <kshishkov> _av500_: why not learn Russian instead. It seems to be not that hard when you know German
[07:48:23] <_av500_> kshishkov: something about winter, bears, and summer (knowing cyrillic serbian helps)
[07:49:03] <kshishkov> _av500_: yes
[07:49:23] <_av500_> your secrets are safe with me
[07:51:23] <kshishkov> nah, I don't have much secrets anyway
[07:53:16] * kshishkov wonders why Serbian uses "код" and "са" particles while their counterparts in Russian are "к" and "с"
[07:53:44] <_av500_> so russian compresses more :)
[07:54:08] <kshishkov> but it does not have no-vowel words for some reasons
[07:54:52] <_av500_> it has not?
[07:55:00] <kshishkov> no
[07:55:56] <kshishkov> for example archaic word for earth is "твердь"
[07:56:25] <_av500_> sounds like "hard"
[07:57:02] <kshishkov> yep, they should be related
[07:57:12] <kshishkov> and IIRC you have simply "tvrd"
[07:57:19] <_av500_> hard(m): tvrd
[07:57:35] <_av500_> yep
[08:47:57] <merbzt> jez9999: run it through patcheck
[08:48:21] <merbzt> ops
[08:48:25] <merbzt> abit late
[08:48:41] <kshishkov> yes
[08:49:26] * kshishkov wonders if some Diego will make patcheck less GNU tools dependent
[08:50:51] <kshishkov> DonDiego: as I've said just before your join, any interest to make patcheck run well in non-GNU environment?
[08:51:09] <DonDiego> i can look at it
[08:51:55] <DonDiego> what's the error?
[08:52:16] <kshishkov> different errors with grep on BSD systems, for example
[08:52:52] <kshishkov> like MacOSX
[08:52:59] <DonDiego> paste please
[08:53:11] <DonDiego> does not look unposixlike at a glance
[08:53:27] <DonDiego> hmm, --color might not be supported
[08:54:13] <kshishkov> "egrep: Unmatched ( or \("
[08:54:21] <DonDiego> line?
[08:54:24] <kshishkov> "xargs: illegal option -- d"
[08:54:34] <kshishkov> it does not print where though
[08:59:11] <Honoome> kshishkov: uhm… grep should be GNU grep…
[08:59:29] <Honoome> yeah just confirmed, 10.6 has GNU grep still
[09:00:02] <kshishkov> yep, it is
[09:00:25] <kshishkov> maybe something wrong with shell itself?
[09:00:35] <Honoome> that might be it
[09:00:43] <Honoome> the xargs one is definitely GNUism
[09:07:26] <siretart> morning
[09:07:47] <kshishkov> guten morgen
[09:09:07] <siretart> :-)
[12:09:57] <KotH> does anyone know a mp3 player with >64GB that isnt a complete pc?
[12:11:32] <kshishkov> new iPods?
[12:13:22] <DonDiego> Andrius: bentkus?
[12:14:06] <Andrius> since I have no clue what you're talking about, probably not
[12:14:08] <kshishkov> KotH: Google seems to know, for example - http://www.china-usb.cn/productinfo.asp?id=546
[12:14:39] <KotH> kshishkov: i want an mp3 player, not shackles
[12:14:47] <elenril> why do you need that much anyway
[12:15:29] <J_Darnley> KotH: a device that supports removable memory
[12:15:31] <kshishkov> well, it's mostly the question of 128GB flash cards
[12:15:53] <J_Darnley> (but I don't know of one)
[12:16:08] <KotH> elenril: because i have about 50G of mp3s
[12:16:32] <KotH> J_Darnley: nah.. i dont want to continously change the storage media
[12:17:14] * elenril 29G music/
[12:17:48] <mru> 147G
[12:17:54] * elenril should pirate mo4r
[12:18:17] * kshishkov has it mostly as Flac and APE
[12:18:55] <KotH> elenril: i dont pirate
[12:19:00] <KotH> elenril: all was legaly downloaded!
[12:19:06] <elenril> orly
[12:19:10] <KotH> ya rly
[12:19:13] <elenril> you don't use torrents at all?
[12:19:17] <KotH> i do
[12:19:23] <KotH> lots of them
[12:19:43] <kshishkov> elenril: if you have not been prosecuted for it, it's legal
[12:19:52] <KotH> er..
[12:20:04] <KotH> kshishkov: no, i live in a sane country, where downloading is _not_ illegal
[12:20:08] <elenril> KotH: so sharing is legal in chocolateland? i somehow doubt that
[12:20:19] <KotH> elenril: nope, uploading is illegal ;)
[12:20:20] <mattg> mru: i'm having second thoughts about if that file i sent you works on arm without asm (i said it worked without asm but not with). it's still working on x86 but not on arm though, so something strange is happening for sure. i'll keep you posted
[12:20:22] <elenril> or you've disabled sharing
[12:20:28] <elenril> then you're even more evil =p
[12:20:48] <kshishkov> KotH: well, I don't know what's not illegal here.
[12:20:57] <KotH> kshishkov: breathin?
[12:21:07] <thresh> not voting for stupid persons
[12:21:08] <elenril> do they even have copyright laws in ukraine?
[12:21:37] <kshishkov> KotH: well, only because there's nothing worth to breathe either
[12:21:40] <elenril> last time i was there people were selling pirated cds in normal shops
[12:21:46] <kshishkov> elenril: of course
[12:21:55] <kshishkov> they are not pirated :(
[12:22:09] <elenril> ofc they are. they even had cracks on them
[12:22:17] <kshishkov> when we have pirated CDs they were cheaper and you could easily return or exchange one
[12:22:31] <elenril> so it's not done anymore?
[12:22:35] <elenril> how sad
[12:22:36] <kshishkov> now they all should bear that holographic sticker and cost more
[12:22:54] <kshishkov> (not talking about content though)
[12:23:29] <kshishkov> elenril: unlike some uncivilized countries, our crime is usually organized and run by government
[12:25:24] <elenril> not really
[12:25:34] <elenril> same here
[12:28:13] <iive> it's the opposite here. our crime is organized and owns the government.
[12:28:37] <kshishkov> iive: looks like it would be the way here too very soon
[12:30:31] <iive> by government i mean the whole bureaucratic  legal judicial and power branches of the country.
[12:30:48] <mru> aka criminals
[12:30:48] <kshishkov> of course
[12:31:22] <kshishkov> mru: not necessarily. They could be blatant idiots instead.
[12:31:38] <iive> our current government tries to change the things. Just today there was some hi-profile arrests.
[12:31:56] <mru> kshishkov: they are usually both
[12:32:37] <iive> they usually pretend to be idiots, while they are pure criminals.
[12:33:20] <kshishkov> mru: no, those are just ordinary citizens here. Just think about Rinkeby or Skärholmen
[12:34:33] <mru> those are the unlicensed crims
[12:35:11] <kshishkov> licensed ones work as police force here
[12:40:42] <iive> same here.
[12:42:33] <kshishkov> iive: yes, we seem to share a lot of common in recent history
[12:45:09] <CIA-17> ffmpeg: andoma * r21737 /trunk/libavformat/mp3.c: mp3: ftell() file offset for VBR tags before ID3v1 parser messes it up.
[12:52:26] <Bagder> what's the ffmpeg position on fixed point codecs? are you guys interested in that "for real" ? I'm in the Rockbox camp and we only do fixed point and we're not quite sure what kind of feedback/code you want from us in terms of codec improvements etc
[12:53:10] <kshishkov> well, we always wanted to backport your WMA decoder
[12:53:33] <DonDiego> Bagder: we're anxiously waiting for your patches
[12:53:44] <DonDiego> also, our mp3 decoder is fixed-point and much faster than libmad
[12:53:56] <DonDiego> Bagder: what do you use for mp3 decoding in rockbox?
[12:54:19] <Bagder> it is libmad based
[12:54:27] <Bagder> although rather optimized
[12:55:03] <Bagder> we use your flac I believe
[12:55:31] <kshishkov> we use your APE decoder
[12:56:25] <DonDiego> Bagder: have you compared performance of your libmad fork to ffmp3?
[12:57:02] <Bagder> I don't think so. We need a bit of work to get your code into our framework too so its a little more than "just test"
[12:57:31] <Bagder> like we work hard to never malloc
[12:57:40] <Bagder> which tend to be a bit of fiddle
[12:58:14] <jai> who forked libmad? rockbox?
[12:58:16] <DonDiego> ffmp3 is 2-3x faster than libmad in my tests on x86
[12:58:28] <DonDiego> so it should be worth investigating
[12:58:39] <Bagder> indeed
[12:59:00] <Bagder> libmad is in fact already very fast
[12:59:18] <DonDiego> no, it's slow as a dog ;)
[12:59:18] <Bagder> we're having mp3 playback in something like 30MHz arm
[12:59:36] <Bagder> well, our libmad
[12:59:44] <mru> last I checked ffmpeg was faster than libmad on arm
[12:59:54] <mru> even with hq enabled
[13:01:06] <_av500_> Bagder: hi
[13:01:11] <DonDiego> ok, a quick check shows i was exaggerating
[13:01:15] <Bagder> hey _av500_ !
[13:01:32] <DonDiego> it's more like 50% with the one sample i tested, not >200%
[13:01:39] <DonDiego> but still it's very noticeable
[13:01:50] <DonDiego> and if you use ffmpeg anyway, then it's one lib dependency less
[13:02:10] <Bagder> well, we playback mp3 at 200% realtime in 21mhz arm
[13:02:27] <Bagder> and we don't use ffmpeg "libs" anyway
[13:02:58] <Bagder> anyway
[13:03:13] <Bagder> I wasn't here to compare codecs, but to see what kind of exchange we should get going
[13:03:16] <DonDiego> if you can play it at 300% realtime you will use less battery
[13:03:29] <DonDiego> ok, let's leave that issue aside for a moment
[13:03:35] <DonDiego> we welcome you contacting us
[13:03:45] <DonDiego> we have always been hoping for this to happen
[13:03:59] <DonDiego> so, in short: we want your code
[13:04:00] <DonDiego> :)
[13:04:25] <_av500_> DonDiego: spell checked!
[13:04:48] <Bagder> DonDiego: ok, fine. That's a really good first step.
[13:04:58] <DonDiego> _av500_: urm, what?
[13:05:15] <DonDiego> we would like to see all external patches integrated
[13:05:21] <_av500_> spelling, no :)
[13:05:42] <Bagder> well, our prolem is that our code is usually a bit away from the ffmpeg original
[13:05:55] <Bagder> due to our no-malloc and only fixed-point
[13:06:04] <DonDiego> http://wiki.multimedia.cx/index.php?title=Interesting_Patches#Fixed_point_cook_decoder
[13:06:11] <DonDiego> this might interest you as well
[13:06:20] <Bagder> right, we have a fixed point cook decoder
[13:06:30] <_av500_> ys pls merge that one :)
[13:06:36] <DonDiego> http://wiki.multimedia.cx/index.php?title=Interesting_Patches#G.729_decoder_by_Vladimir_Voroshilov
[13:06:46] <DonDiego> that's fixed-point as well i think
[13:07:03] <DonDiego> Compn: why isn't the rockbox patch on the interesting patches page?
[13:07:22] <DonDiego> Bagder: i think your wma patch was submitted at some point, but never finished..
[13:07:43] <Bagder> I seem to recall that too
[13:08:18] <DonDiego> well, submit it again..
[13:08:22] <Bagder> anyway, I'll work on setting up some kind of team of people to get something going
[13:08:32] <Bagder> I think we need to work on both ends
[13:09:06] <DonDiego> what do you want us to work on?
[13:09:10] <andoma> Bagder: btw, me and merbzt are planning to attend the #foss-sthlm event
[13:09:16] <Compn> DonDiego : the wma fixed patch ?
[13:09:24] <DonDiego> Compn: yes
[13:09:25] <Bagder> DonDiego: I need to get back on that, I'm not really a codec guy
[13:09:26] <Compn> its on small tasks page i think
[13:09:39] <Bagder> andoma: ah right, cool!
[13:09:58] <DonDiego> Compn: add it to interesting patches please :)
[13:10:15] <merbzt> Bagder: the main issue is we have no good framework for fixed-point
[13:10:16] <DonDiego> Bagder: ok, let's get the ball rolling
[13:10:42] <Compn> DonDiego : but its not a patch?
[13:10:45] <Bagder> right, people in our camp expressed a concern about the fixed/float point situation it might end up in
[13:10:52] <merbzt> and then we need dsp routines
[13:10:53] <Compn> i mean, where is the patch ? all i see is a repo
[13:10:55] <Bagder> but we'll sort it
[13:11:16] <DonDiego> Compn: then just link to that..
[13:11:51] <DonDiego> Bagder: i'm sure there will be bumps on the road but nothing that we should not be able to work out..
[13:11:53] <merbzt> regtests would be so much more nice with fixed point codecs
[13:12:03] <Compn> DonDiego : done
[13:12:09] <Bagder> DonDiego: indeed!
[13:12:14] <_av500_> Bagder: btw
[13:12:31] <_av500_> our latest players are rk26xx based
[13:12:44] <_av500_> and seem to be ugly to programm...
[13:12:46] <merbzt> DonDiego: hmm, how about we added a fixed-point fft/mdct as a SoC project
[13:13:03] <Compn> DonDiego : wasnt acelp/sipro originally fixed-point too ?
[13:13:52] <kshishkov> merbzt: it's rather trivial, just replace multiplications in existing one
[13:14:33] <andoma> trivial or not, it would be rather useful for the community I guess
[13:14:38] <DonDiego> kugel: hi
[13:14:43] <DonDiego> another rockbox guy..
[13:14:51] <kugel> ;)
[13:15:03] <Bagder> surely fixed-point fft/mdct stuff can be re-used from Rockbox too?
[13:15:14] <DonDiego> i suppose
[13:15:18] <Compn> is it lgpl ? :P
[13:15:31] <Bagder> its GPLv2+
[13:15:41] <Compn> not really a problem, just curious
[13:15:43] <peloverde> Bagder, kugel: I enjoyed your guy's talk at FOSDEM btw
[13:15:58] <Bagder> cool
[13:16:10] <Compn> did anyone attend html5 talk ?
[13:16:23] <kugel> peloverde: that guy was Bagder :)
[13:16:30] <kshishkov> Compn: they said it was very crowded
[13:16:45] <DonDiego> we could not get in (html 5)
[13:18:34] <Compn> hehe
[13:18:35] <merbzt> kshishkov: well I think it is a little bit harder then that
[13:18:46] <kshishkov> merbzt: why?
[13:19:13] <peloverde> Can we reuse the fixed point mdct from tremor, that's BSD
[13:19:58] <DonDiego> Bagder: can you get it relicensed?
[13:20:11] <merbzt> peloverde: well it doesn't match the float *_half stuff
[13:20:29] <Bagder> DonDiego: not likely, most of our stuff is based on upstream stuff
[13:20:55] <Compn> DonDiego : tired of maintaining a set of gpl and a set of lgpl code ?
[13:21:13] <merbzt> kshishkov: you need to be careful about precision and scaling
[13:22:18] <DonDiego> Bagder: that does not necessarily make it unlikely, where does the code come from?
[13:22:22] <pJok> how hard would it to do a fixed point mdct at all?
[13:22:57] <merbzt> kshishkov: some fft algos are better in that sense
[13:23:01] <Bagder> DonDiego: well, pretty much all of our codecs come from different places, so it all differs.
[13:23:36] <DonDiego> well, find out about that particular piece of code
[13:24:28] <kshishkov> merbzt: could be. BTW, have I mentioned that I had not learnt anything about DSP at university?
[13:24:30] <Bagder> which code are you referring to?
[13:25:19] <merbzt> Bagder: any code :)
[13:25:39] * Bagder throws a tomato at merbzt 
[13:26:13] <merbzt> anyway, wma and cook needs a fp mdct routine
[13:26:36] <peloverde> Looking at this it looks like a slightly modified version of the Tremor code: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/lib/mdct2.c?revision=23973&view=markup
[13:26:40] <merbzt> Bagder: I'll through it back the 24:th
[13:27:01] * Bagder makes a note to bring suitable armor
[13:27:26] <kugel> aren't we going to replace the tremor mdct with something better?
[13:28:04] <Bagder> yes, that's in a branch
[13:28:22] <merbzt> the ffmpeg way ?
[13:28:37] <merbzt> mdct_half etc
[13:29:16] <Bagder> http://svn.rockbox.org/viewvc.cgi/branches/mdctexp/apps/codecs/lib/mdct.c?view=log
[13:29:20] <merbzt> I guess saratoga would know
[13:29:23] <Bagder> yes
[13:29:30] <Bagder> he and stripwax
[13:30:00] <Bagder> "In your face Tremor MDCT : now 1.5MHz faster than trunk" :-)
[13:30:08] <peloverde> "This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License" Is that correct? :)
[13:30:13] <DonDiego> Bagder: i was referring to the fixed-point dcts you talked about..
[13:31:26] <Bagder> I'd really not actually comment too much about specific codec works as I'll just make a fool of myself
[13:31:30] <merbzt> Bagder: ok that code looked really good
[13:31:56] <merbzt> or the comments
[13:32:01] <Bagder> "Copyright (c) 2002 The FFmpeg Project" even :-)
[13:32:39] <merbzt> the ffmpeg code is based on Public Domain code
[13:32:50] <superdump> andoma: when is that stockholm foss meet up again?
[13:32:58] <merbzt> 24:th
[13:33:02] <superdump> right
[13:33:21] <superdump> it's looking like i'll still be here so i'll probably wander along too ;)
[13:33:48] <andoma> cool :)
[13:33:59] <kugel> http://www.rockbox.org/wiki/FasterMDCT if it helps
[13:34:00] <andoma> Bagder: btw, are the presentations in swedish?
[13:34:08] <superdump> i may need reminding though
[13:34:17] <Bagder> andoma: yes, they'll be in Swedish
[13:34:24] <andoma> good, superdump needs to learn some
[13:34:29] <Bagder> haha
[13:34:38] <superdump> :)
[13:34:46] <superdump> i may be able to follow little bits of it
[13:35:25] <kshishkov> superdump: you can recognize "cos" even in Russian
[13:37:53] <andoma> ok .. but who will volunteer to implement SBR in fixedpoint? :)
[13:38:04] * peloverde hides
[13:38:16] <kshishkov> superdump, of course
[13:38:30] <superdump> not_peloverde: the low complexity stuff is a bit simpler than the normal sbr
[13:38:57] <not_peloverde> It's computationally less complex, But it adds new tools like aliasing detection
[13:39:01] <superdump> though i guess it's still float
[13:39:02] <superdump> right
[13:39:22] <superdump> iirc it ditches the imaginary parts and fixes it with aliasing?
[13:39:30] <not_peloverde> yes
[13:39:31] <superdump> anti-aliasing rather
[13:40:18] <superdump> still, we'd have to have a fixed point lc decoder
[13:40:57] <superdump> kugel, Bagder: does faad have a fixed point mode or did you port it or...?
[13:41:09] <not_peloverde> Faad has fixed point
[13:41:16] <not_peloverde> faad2 anyway
[13:42:35] <superdump> ok
[13:43:09] <superdump> kugel, Bagder: mdct_half brings a significant speed benefit
[13:43:13] <superdump> it's worth looking into
[13:47:16] <not_peloverde> http://arstechnica.com/media/news/2010/02/royalty-free-codec-still-needed-despite-no-cost-h264-license.ars : "Although Ogg Theora still has some technical limitations, it is advancing rapidly and could have the potential to become a competitive alternative to h264."
[13:47:27] * not_peloverde facepalm
[13:48:18] <kshishkov> why not? If they switch bitstream format away from VP3...
[13:48:31] <mru> yeah, if they switch codec
[13:48:35] <merbzt> to h264
[13:48:39] <mru> vp8
[13:48:47] <mru> vp8, if it exists, is probably not far off h264
[13:49:00] * kierank doesn't think it exists
[13:49:40] <not_peloverde> If it exists it may step on other peoples' IP
[13:51:20] <kugel> we're not really the codec guys of rockbox so we can't comment on most things
[13:52:19] <merbzt> Bagder: anyway this new code looks like it would be possible to merge into ffmpeg
[13:53:18] <DonDiego> http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
[13:53:27] <merbzt> license wise and performance wise
[13:54:47] <merbzt> DonDiego: too bad they never answer my emails ...
[13:55:10] <kierank> they don't answer anybody's emails
[13:56:01] <merbzt> feels more like a publicity stunt then something for the OS community
[13:57:29] <kierank> iirc they got goverment money to do that
[14:05:07] <superdump> a few billion lines of code? how about a few billion lines of text that i'm not going to read
[14:05:43] <kshishkov> superdump: you are lucky. We had to study "War and Peace" at school
[14:06:48] <superdump> :)
[14:07:12] <not_peloverde> superdump, How do you feel about outputting the first AAC frame? http://ffmpeg.pastebin.ca/1792552
[14:07:24] <DonDiego> bye
[14:09:00] <kshishkov> not_peloverde: I always thought that zeroing delay is enough
[14:09:02] <twnqx> nice article, nonetheless :)
[14:09:46] <Honoome> it doesn't say much more o much different than the Static Analysis book I read recently
[14:09:50] <Honoome> although I haven't tried Fortify :/
[14:11:28] <not_peloverde> kshishkov, zeroing?
[14:12:12] <kshishkov> not_peloverde: yes, what could be a reason for decoding delay?
[14:12:57] <not_peloverde> That's not a delay it's an advance
[14:13:13] <not_peloverde> Presumably it's to match the delay on a particular encoder
[14:13:54] <not_peloverde> However the right way to handle that is 14496-24
[14:19:55] <superdump> not_peloverde: go for it
[14:20:03] <superdump> iirc, that should be needed for full compliance
[14:20:13] <superdump> so i don't know why it's there in the first place really
[14:21:10] <superdump> i mean removing that code is needed for compliance
[14:26:53] <CIA-17> ffmpeg: michael * r21738 /trunk/libavformat/mpeg.c:
[14:26:53] <CIA-17> ffmpeg: Dont give up after 100kb of zero bytes but returnd EAGAIN
[14:26:53] <CIA-17> ffmpeg: fixes issue1729
[14:52:47] <CIA-17> ffmpeg: alexc * r21739 /trunk/libavcodec/aac.c: Output the first AAC frame. This is needed for SBR conformance.
[15:01:20] <kierank> does anyone know of any system that actually uses anything other than DTS/AC-3/PCM over SPDIF?
[15:01:41] <merbzt> there is a pioneer rig that uses wmapro
[15:03:15] <merbzt> and many receivers support mpeg also
[15:05:32] <twnqx> emess claims he built something on his own :>
[15:05:37] <twnqx> that can also do flac
[15:07:27] <kierank> there's no reason why it couldn't work; there are a few flags codec ids that are still reserved
[15:10:26] <twnqx> my soundcard can output 6mbit on spdif... but i don't have a receiver that understands the signal
[15:10:42] <_av500_> peloverde: made it back nicely?
[15:11:05] <peloverde> yes, travel was pretty smooth
[15:11:08] <_av500_> twnqx: you could stream H264 HD over SPDIF :)
[15:18:06] <kierank> aes3 in the broadcast world seems to be a place where you just dump stuff you can't invent another transport mechanism for
[15:18:47] <kshishkov> for non-broadcast world we have Matroska
[15:42:46] <kierank> Any idea what ATRAC-X is?
[15:43:25] <kshishkov> merbzt may have some ideas
[15:47:35] <kshishkov> it may be multichannel extension of ATRAC-3
[15:47:50] <Tass`> I'm looking through the source... what's exactly 'mdat' ?
[15:48:10] <kshishkov> an atom in MOV?
[15:48:34] <Tass`> I'm trying to fix an 3gp... and trying to get if it's imporant for mplayer to fail
[15:50:55] <jai> also seems to be geared towards n/w streaming
[15:52:02] <kierank> hmm maybe i'll just leave some of these other codecs alone because they need codec-specific demuxing
[15:52:26] <KotH> btw: anyone already working on the elf muxer/demuxer?
[15:52:55] <merbzt> I did something like it one time
[15:53:25] <kshishkov> KotH: muxer? self-converting executable?
[15:53:45] <merbzt> it added symbols to a stripped binary
[15:54:02] <KotH> kshishkov: mux a video(incl audio+subs) and ffmpeg into an elf binary, so that it self-playing :)
[15:54:20] <jai> merbzt: where did you get the symbols from?
[15:54:31] <kshishkov> KotH: s/ffmpeg/ffplay/ then
[15:54:47] <KotH> or maybe s/ffplay/mplayer/ ;)
[15:55:21] <merbzt> jai: another binary or just out of thin air
[15:55:40] <jai> merbzt: :)
[15:55:40] <kshishkov> KotH: then it's a feature for mencoder :P
[15:57:13] <merbzt> objdump uses those names
[15:57:24] <merbzt> and gdb
[15:57:42] <merbzt> made it easier to debug something
[15:57:47] <merbzt> I can't really remember
[15:59:44] <jai> merbzt: you suggested this approach to me once, i forgot all about it :|
[16:00:55] <merbzt> I forgot I even suggested that to you
[16:01:43] <kshishkov> merbzt: ever thought about adding debug capabilities to MPlayer DLL loader?
[16:02:32] <merbzt> debug how ?
[16:03:09] <kshishkov> to make it possible print register data at certain addresses, for example
[16:03:23] <kshishkov> 'twas quite useful for RV4
[16:04:31] <merbzt> ah ok, I have just patches the wrapper when I messed with mplayer
[16:08:12] <kierank> Any idea what the difference between "7.1" and "7.1 Screen" is?
[16:08:28] <kshishkov> " Screen"
[16:08:54] <kierank> :/
[16:08:58] <KotH> wtf...
[16:09:08] <kshishkov> if you talk about audio codec maybe it's studio processing and final output difference
[16:09:27] <KotH> i just looked up when linuxtag is... and was greeted by a pic of us at linuxtag community party 2007
[16:10:28] <bilboed-pi> google, now with brainreading features
[16:11:10] <kshishkov> bilboed-pi: if it also develops conscience it'll prefer kill itself than read our minds
[16:11:28] <bilboed-pi> or grow up into skynet
[16:11:33] <bilboed-pi> dunno which one is worse
[16:11:56] <mru> KotH: wasn't that the 2008 party?
[16:12:04] <kshishkov> Terminators were cool
[16:18:50] <KotH> mru: ack, 2008
[17:21:41] <CIA-17> ffmpeg: rbultje * r21740 /trunk/ (6 files in 2 dirs): RTP/AMR depacketizer, by Martin Storsj? <$firstname at $firstname dot st>.
[17:29:35] <_av500_> kshishkov: berlin is like ukraine, except for major roads, all the rest is ice fields
[17:30:08] <kshishkov> what do you expect from East Germany?
[17:30:24] <_av500_> right
[17:30:54] <kshishkov> it seems to me the best part of Germany is South-West
[17:30:59] <_av500_> each year i get more and morre strange looks calling it that
[17:31:15] <_av500_> kshishkov: !east :)
[17:31:36] <kshishkov> call it ex-DDR then
[17:32:04] <kshishkov> _av500_: also I'd like to add that North Germany seems to be less clean than South
[17:32:30] <_av500_> huh
[17:32:52] <mru> KotH would say it's further from .ch...
[17:33:27] <KotH> juup, that's definitly a disadvantage
[17:34:04] <kierank> biggest shock when going to germany is the lack of bins
[17:34:18] <kshishkov> I've been to Bavaria once
[17:34:24] <kierank> and weird road signs with pictures of tanks
[17:34:25] <_av500_> mru: brussels is north, eh?
[17:34:36] * _av500_ likes his tank
[17:34:46] <mru> that's .be, which is in a league of its own
[17:35:07] <kshishkov> mru: and who wrote that "Belgium" is the worst curse in the Universe?
[17:35:33] <_av500_> the 42 guy
[17:36:17] <kshishkov> then it must be true
[17:36:46] * _av500_ has not seen many planets though....
[17:36:56] <_av500_> except through lens
[17:38:59] <kshishkov> don't panic
[17:39:54] <Honoome> lu_zero: back home?
[17:48:27] <lu_zero> sort of
[17:48:45] <BBB> hi lu_zero
[17:48:49] * lu_zero still needs to discover how to fix his idiotic router...
[17:48:50] <BBB> is the rtp/theora spec done?
[17:49:03] <lu_zero> BBB: not yet
[17:49:04] * Honoome keeps from laughing
[17:49:09] <BBB> :)
[17:49:14] <Honoome> what about snow? :D
[17:49:17] <BBB> Honoome, why do you think I keep asking?
[17:49:32] <Honoome> BBB: hehe yeah I know :)
[17:49:43] <lu_zero> what's with snow?
[17:49:50] <lu_zero> snow is a michael toy
[17:49:51] <BBB> it'll make us look good in the freetard community
[17:50:02] <BBB> ^d^d^d
[17:50:14] <lu_zero> with almost no will to be mainstream let alone useful
[17:50:51] <lu_zero> BBB: I'd rather mess a bit with the latest flurry of patches about rtp/rtsp etc
[17:50:56] <lu_zero> (muxer included)
[17:51:28] <elenril> snow is patent encumbered and therefore evil!
[17:51:32] * elenril hides
[17:51:34] <lu_zero> how so?
[17:51:37] <lu_zero> which patent?
[17:51:44] <BBB> I didn't review martin's latest round yet
[17:51:48] <BBB> (muxer)
[17:52:12] <BBB> ps please please let me apply my rtp-crash-on-unknown-codec patch, even if you don't like it
[17:52:16] <BBB> it only removes code
[17:52:18] <BBB> doesn't add any
[17:52:36] <elenril> dunno, but somebody here said wavelets were patented beyond the impossible
[17:52:53] <lu_zero> give me a ref
[17:53:04] <_av500_> &p
[17:53:40] <Honoome> lol
[17:54:04] <elenril> wait until Dark_Shikari wake up, he probably knows something
[17:54:10] <BBB> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/074943.html
[17:54:29] <BBB> I really want that patch in :)
[17:54:58] * BBB should also resume work on getting the svq1/qdm2 depayloaders in
[17:55:03] <BBB> those are easy
[17:56:27] * Honoome should find time to make the metadata hash table generic and move it to libavutil so that feng/libnemesi can use it :P
[17:56:46] <elenril> what metadata hash table?
[17:57:06] <Honoome> elenril: well libavformat uses an hash table for metadata, doesn't it?
[17:57:14] <jai> key-value pairs
[17:57:37] <elenril> avmetadataconv?
[17:57:57] <elenril> why would you want to use it?
[17:58:32] <kierank> would be nice if you could make per packet metadata while you're at it ;)
[17:58:32] <jai> because any serious media framework needs to use av prefixed stuff ;)
[17:59:04] <Honoome> elenril: for libnemesi we're needing an hash table (key/value pairs, dictionary, call it what you wish :P) for parsing the headers… right now in feng we use glib's, but we wanted to avoid glib in libnemesi
[18:00:42] <jai> calling it a "hash table" doesnt seem right to me, because you cant do lookups in O(1)
[18:01:32] <jai> though i guess you cant hash everything perfectly :)
[18:01:37] <jai> so meh
[18:02:03] <jai> kierank: btw, do you have a bigger AOB sample?
[18:04:06] <Honoome> jai: well, it's still an hash… identity hash :D
[18:04:27] <lu_zero> s/libnemesi/robust and flexible rtsp parsing
[18:04:35] <mru> hash tables are a subset of key/value mapping systems
[18:04:48] * _av500_ wants to avoid glib in everything
[18:05:17] <mru> also in glibc
[18:05:19] <jai> Honoome: as mru said
[18:05:24] <mru> plain c is much better
[18:05:42] * _av500_ remembers libmms that invokes glib to do a couple of frakin gstrdups...
[18:06:01] <jai> a well designed hashing scheme would still be better, and i assumed you wanted something like that
[18:06:05] <Honoome> potato, potato… at the end, once generic it can as well be a hash map rather than just a lookup :P
[18:06:21] <elenril> doesn't hash table have to be sorted?
[18:06:34] * elenril has zero theoretical knowledge about programming
[18:06:35] <kshishkov> nope
[18:06:37] <jai> elenril: ?
[18:06:38] <jai> no
[18:06:43] <Honoome> what we need for libnemesi is not much different from what is needed for metadata handling
[18:07:02] <jai> Honoome: does libnemesi already use libavutil?
[18:07:03] <kshishkov> elenril: hash just maps larger keys into smaller table
[18:07:19] <Honoome> jai: should, and if not it will ;)
[18:07:39] <lu_zero> jai: libnemesi doesn't use anything right now
[18:07:46] <jai> Honoome: right, k
[18:08:06] <lu_zero> and I'd be way happier to have it merged inside libavformat in the end
[18:08:16] <jai> tbh, i dont know much about it, except that lu_zero works on it :)
[18:08:56] <lu_zero> (but given that could be a looong route because of the use of generated parsers better do that step by step...)
[18:09:57] <jai> lu_zero: while you are around, quick question : how hard would it be to paginate roundup such that i can jump to page N directly from the listing
[18:10:37] <_av500_> or offer to not paginate?
[18:10:55] <jai> or that :)
[18:11:06] <BBB> lu_zero, did you check the patch?
[18:11:11] * _av500_ has motorized mouse wheel
[18:11:55] <lu_zero> jai: I need to try to see
[18:11:57] <lu_zero> btw
[18:12:05] <lu_zero> I'd need to update it soonish
[18:12:33] <jai> lu_zero: at your pace of course :)
[18:12:44] <jai> infact maybe recent versions of roundup already do it?
[18:13:27] <lu_zero> jai: think about roundup as a library
[18:13:41] <lu_zero> BBB: still I'm not so fond of it, commit anyway
[18:13:51] <lu_zero> it shouldn't break much stuff
[18:13:58] <lu_zero> now...
[18:14:30] * lu_zero syncs and checks the new roundup
[18:15:41] <ramiro> lu_zero: with michael's bug bounty system you can get quite a lot of cash from fixing your old roundup bugs =)
[18:16:58] <jai> ramiro: hehe :)
[18:17:09] <jai> bugrot == profit
[18:17:28] <KotH> bug bounty?
[18:17:34] <KotH> did i miss something?
[18:17:45] <mru> only a proposal
[18:18:02] <jai> KotH: the thread is "[RFC] Bug Bounty"
[18:18:40] <Compn> KotH / mru : we probably need a new tag in roundup for that
[18:18:46] <Compn> bug bounty tag :)
[18:19:05] <KotH> Compn: roundup is lucas thingy
[18:19:15] <Compn> ah
[18:19:19] * Compn forgot
[18:20:58] <lu_zero> ramiro: eh...
[18:22:53] <mru> http://www.youtube.com/watch?v=9BnLbv6QYcA
[18:24:50] * _av500_ is on 56k :(
[18:25:35] * jai is on 56k as well
[18:26:59] * kshishkov is on Gdium
[18:27:07] <mru> kshishkov wins
[18:27:13] <_av500_> http://www.youtube.com/watch?v=9BnLbv6QYcA&vo=libaa
[18:27:23] <mru> lol
[18:27:40] * BBB commits quickly before lu_zero changes his mind
[18:27:53] <mru> _av500_: hey, they should do that
[18:28:15] <mru> it's no sillier than the comment text2speech preview
[18:29:03] <kshishkov> well, if you can get that proposal to xkcd, it will be implemented
[18:31:46] <CIA-17> ffmpeg: rbultje * r21741 /trunk/libavformat/rtsp.c:
[18:31:46] <CIA-17> ffmpeg: Don't forget to set known audio parameters (samplerate, etc.) if the codec is
[18:31:46] <CIA-17> ffmpeg: not supported in FFmpeg. This will cause crashes later because the samplerate
[18:31:46] <CIA-17> ffmpeg: is used to initialize the timebase.
[18:32:35] <CIA-17> ffmpeg: rbultje * r21742 /trunk/libavformat/rtsp.c: Reindent after r21741.
[18:35:15] <BBB> another crash fixed...
[18:35:17] <BBB> hmm...
[18:40:52] <_av500_> the 1st class in this train has thinkpad ratio of 95%
[18:41:26] <kshishkov> DB Regio?
[18:41:44] <_av500_> berlin frankfurt ice
[18:42:03] <_av500_> and they are doing ppt, I am the only one to write code :)
[18:42:18] <kshishkov> loser
[18:42:36] <peloverde> Which bug resolution in roundup is closest to "NOT A BUG"? invalid? wont_fix?
[18:42:48] <kshishkov> invalid
[18:42:54] <_av500_> works_for_me
[18:47:08] <jai> i'd say invalid
[18:48:24] <peloverde> I went with invalid
[18:49:00] <peloverde> issue1401 if anyone is interested
[18:55:23] <Spulit> Hi there!
[18:55:32] <peloverde> hello
[18:56:11] <Spulit> Any main developer here? I want to ask if there's any work being done in order to support Broadcom's CrystalHD...
[18:56:31] <kshishkov> no, main developer never appears here
[18:56:56] <_av500_> i am main non-dev here!
[18:57:10] <Spulit> or any one that can reply to this question? :)
[18:57:11] <Honoome> kshishkov: Fabrice? :P
[18:57:27] <kshishkov> for CrystalHD ask gb
[18:57:40] <kshishkov> Honoome: not anymore. MN
[18:57:59] <Honoome> kshishkov: yes I know I was just kidding  ;)
[18:58:47] <Spulit> My company is developing a new product that needs CrystalHD working with VLC and is willing to donate to have this implemented ASAP...
[19:01:04] <ramiro> mike melanson tried: http://multimedia.cx/eggs/installing-crystalhd-drivers-in-linux/
[19:01:31] <ramiro> someone might be interested in being hired to implement it. contact the ffmpeg-devel mailinglist.
[19:01:34] <_av500_> Spulit: what is the price of this one?
[19:02:21] <Spulit> I already saw that link...the problem for now are not the drivers, but the players support for the card...
[19:02:50] <Spulit> _av500_: what is the price of what?
[19:02:56] <kshishkov> I've heard that XBMC supports it already
[19:03:45] <Spulit> Indeed, but it only works with files. I needed it play IPTV streams (mostly interlaced contents), and xbmc doesn't handle that well...
[19:34:12] <CIA-17> ffmpeg: lucabe * r21743 /trunk/libavformat/rtpenc.c:
[19:34:12] <CIA-17> ffmpeg: Fix syncronisation for streams with a high encoding delay.
[19:34:12] <CIA-17> ffmpeg: Patch by Timo Ter?s (timo DOT teras AT iki DOT fi)
[19:44:47] <CIA-17> ffmpeg: reimar * r21744 /trunk/libavformat/seek.c:
[19:44:47] <CIA-17> ffmpeg: Use av_compare_ts from libavutil instead of the locale compare_ts, the
[19:44:47] <CIA-17> ffmpeg: calculations in the later one are not correct with large time stamps.
[19:47:48] <CIA-17> ffmpeg: reimar * r21745 /trunk/ffmpeg.c:
[19:47:48] <CIA-17> ffmpeg: Use av_compare_ts to compare against the -t end time instead of using
[19:47:48] <CIA-17> ffmpeg: floating point.
[19:47:48] <CIA-17> ffmpeg: Should fix different results between PPC and x86 for the idroq-video-encode
[19:47:48] <CIA-17> ffmpeg: FATE test.
[19:53:10] <twnqx> is the status of a variable used in a for-loop undefined on exit?
[19:53:27] <_av500_> no
[19:53:30] <_av500_> err
[19:53:45] <_av500_> where is it defined?
[19:54:16] <twnqx> http://pastebin.com/d4559e251 - i is defined at the beginning of the function
[19:54:17] <_av500_> int i is defined after the loop
[19:54:33] <twnqx> i don't lkike this new style stuff :P
[19:54:54] <twnqx> but even if the opcode is not in the array... the printf never triggers
[19:55:00] <twnqx> without the break it does
[19:55:10] <twnqx> sadly, always.
[19:55:33] <_av500_> err, you miss {}
[19:55:43] <_av500_> you always break
[19:55:57] <twnqx> *head -> desk*
[19:56:08] * _av500_ throws pillow
[19:56:18] <twnqx> thanks...
[19:56:36] <twnqx> both for the heads up and the pillow.
[19:56:51] <_av500_> :)
[19:57:07] * twnqx goes to add more than "NOP" to the opcode table
[19:57:25] <ramiro> the nopcode table?
[19:57:30] <_av500_> what do you build?
[19:57:32] <twnqx> currently it is ;)
[19:57:42] <twnqx> just a debugging tool for my radeon GPU stalls
[19:58:06] <_av500_> it stalls on NOP?
[19:58:24] <twnqx> actually i'm trying to giure that out, so i need to decode all the opcodes the driver sends
[19:58:28] <twnqx> figure*
[20:07:41] <mru> HCF?
[20:07:45] <mru> halt and catch fire
[20:27:45] <CIA-17> ffmpeg: daniel * r21746 /trunk/libavformat/wav.c: Fix demuxing of wav files with broken data header
[20:28:12] <Compn> where is kostya
[20:28:22] <Compn> i want to complain that his side of the world is sending snow to my side of the world
[20:28:44] <CIA-17> ffmpeg: daniel * r21747 /trunk/libavformat/wav.c: Reindent
[20:30:59] <elenril> snow is great
[20:32:05] * elenril has tons of snow around
[20:32:10] <peloverde> elenril, the codec or the stuff that's shut down the eastern US?
[20:32:18] <elenril> both
[20:46:19] <mru> btw, I got my tegra2 board today
[20:47:03] <_av500_> mru:rooted and jailbricked?
[20:47:21] <mru> haven't booted it yet, need psu
[20:47:37] <mru> I can steal one off something else or buy one tomorrow
[20:47:43] <_av500_> 12v?
[20:48:09] <mru> says 15V
[20:48:19] <mru> I'd be surprised if it didn't work at 12 though
[20:48:22] <_av500_> use 3 usb posrts :)
[20:52:33] <_av500_> 15v sounds supicious for mobile platform...
[20:52:38] <_av500_> +s
[21:10:04] <peloverde> When did fate turn all yellow?
[21:13:29] <Honoome> peloverde: it's having some problem with the liver…
[21:13:47] <kierank> too much drinking
[21:14:02] <peloverde> It's not just a FATE bug, a bunch of streams are actually crashing like crazy
[21:18:40] <peloverde> or maybe Yuvi
[21:43:07] <Yuvi> the number of frames decoded by -t changed recently
[21:44:55] <peloverde> Yuvi, vp6 is hard crashing
[21:45:06] <peloverde> on the first frame
[21:45:16] <Yuvi> yeah, looking at it now
[21:45:28] <Yuvi> but most of the other failing tests are due to -t
[21:46:07] <peloverde> yes but vp6 didn't start crashing until you screwed with (put|avg)_pixels_16_sse2
[21:46:19] <peloverde> which is coincidentally where the crash occurs
[21:51:33] <Yuvi> I really wanted to up STRIDE_ALIGN to 16 for that, but michael is dead set against it :/
[21:52:05] <mru> many platforms already have it at 16
[21:52:35] <Yuvi> I know, and it ought to be at 16 for sse too, but instead svq1 is special cased in get_buffer
[21:52:48] <mru> insane
[21:52:50] <Dark_Shikari> that's retarded
[21:52:55] <Dark_Shikari> for x264 we use up to 64 :/
[21:53:06] <mru> cachesplit stuff?
[21:53:08] <Dark_Shikari> yes
[21:53:23] <Dark_Shikari> 16 base, 64 max
[21:53:40] * mru points at comments in av_malloc()
[21:54:15] <Dark_Shikari> we don't actually align to 64, but we align the stride to 64
[21:54:44] <mru> what good does that do?
[21:55:02] <mru> yeah, of course
[21:55:41] <Dark_Shikari> aligning the stride lets you use cachesplit sad functions
[21:55:47] <Dark_Shikari> which assume each line of the image has the same (mis)alignment
[21:55:53] <mru> I realised that
[21:56:25] <mru> i7 finally fixed that, right?
[21:56:31] <Dark_Shikari> yes
[21:56:47] <mru> and i5 I presume
[21:57:23] <Dark_Shikari> yes, nehalem in general
[22:15:14] <CIA-17> ffmpeg: mru * r21748 /trunk/configure: configure: fix cosmetic typo in check_mathfunc
[22:15:15] <CIA-17> ffmpeg: mru * r21749 /trunk/configure:
[22:15:15] <CIA-17> ffmpeg: Stricter check for math.h functions
[22:15:15] <CIA-17> ffmpeg: GCC is sometimes able to optimise constant calls to these functions,
[22:15:15] <CIA-17> ffmpeg: incorrectly indicating that they exist. Unoptimised calls will then
[22:15:15] <CIA-17> ffmpeg: fail to link.
[22:34:48] <KotH> night boys
[22:34:51] <andoma> nite
[22:36:58] <_av500_> ramiro: welcome to linux-davinci :)
[22:39:02] <ramiro> _av500_: I've been in it for years, I've just never used it much =)
[22:39:41] <_av500_> :)
[23:09:00] <pengvado> we don't actually align to 64 <-- but I think my weird performance in plane_copy has to do with mod64, so maybe we should
[23:09:11] <pengvado> course I still don't know why the weirdness happens
[23:09:19] <CIA-17> ffmpeg: diego * r21750 /trunk/libavutil: Ignore generated header avconfig.h.
[23:37:29] <CIA-17> ffmpeg: stefano * r21751 /trunk/cmdutils.c:
[23:37:29] <CIA-17> ffmpeg: Extend show_pix_fmts(), make it show input/output support for
[23:37:29] <CIA-17> ffmpeg: conversion and other information exposed by the pixdesc API.