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

irc at mansr.com irc at mansr.com
Thu Feb 18 01:00:53 CET 2010


[00:00:13] <Kovensky> binutils also doesn't help
[00:00:25] <Kovensky> lots of libtool workarounds are because of ld stupidities
[00:00:42] <mru> ld is fine
[00:00:59] <mru> gnu binutils as a whole actually work pretty well
[00:01:09] <mru> appalling code aside
[00:01:29] <Honoome> mru: have you looked at gold at all?
[00:01:34] <mru> no
[00:01:38] <mru> and I don't intend to
[00:01:47] <mru> all I've heard is that it doesn't work
[00:01:52] <Honoome> “it's fast because it's in C++!!!”
[00:01:54] <mru> and exists only to solve a problem I don't have
[00:02:12] <Honoome> when actually the reason it's fast is because it doesn't use either bfd or ldscripts (focuses on ELF only)
[00:02:30] <Honoome> I'm curious to see what Drepper will pull out of his ass with elfutils' ld… right now only supports x86 though
[00:02:42] <Kovensky> loldrepper
[00:02:43] <mru> scripts are very useful with elf too...
[00:02:56] <mru> lolrich drepper...
[00:03:46] <Honoome> mru: true, but they don't care, it is indeed one of the worst parts of ld (yes, I *did* benchmark ld at one point…)
[00:04:04] <mru> I've never noticed ld taking any substantial amount of time
[00:04:07] <mru> even for c++
[00:04:07] <Honoome> so from one point of view it makes sense to sacrifice the scripts for the most common case
[00:04:09] <astrange> the author of gold doesn't claim it's faster because it's in c++, it's because it only does as many passes as needed
[00:04:26] <astrange> he did seem really proud of templating to avoid endian swaps, i think it's because he works with too many plan 9 people
[00:04:27] <Honoome> try linking webkit-gtk or chromium then tell me how ld performs :P
[00:04:51] <astrange> wow, aac sbr is really good
[00:05:00] <Honoome> astrange: beside the author a lot of people insisted gold was fast because it's C++ or because of the templates…
[00:05:13] <astrange> people are weird
[00:05:34] <Honoome> C++ fanboys are very weird :P
[00:05:50] <astrange> everyone i meet except the actual developers of llvm have some weird idea about it replacing gcc all over the world, like gcc killed their dog by being gpl
[00:05:58] <Dark_Shikari> lol
[00:06:07] <Dark_Shikari> astrange: it's not really unusual
[00:06:29] <pasteeater> Dark_Shikari: you mean a unique firstpass for each preset?
[00:06:38] <Honoome> astrange: yet another class of zealots that should really learn how to code instead of going around “evangelising”
[00:06:58] <Dark_Shikari> pasteeater: yes
[00:07:10] <Dark_Shikari> the idea being that a user can just add -firstpass to the preset
[00:07:13] <Dark_Shikari> to get the, er, first pass version
[00:08:06] <pasteeater> Dark_Shikari: that does make thinks a bit easier for the user i suppose.
[00:08:19] <pasteeater> ...and "things".
[00:11:31] <jez9999> BBB: hey... could you check in the patch for issue 1740?
[00:12:15] <mru> there, libc.a manually updated instead
[00:12:18] <mru> much easier
[00:12:55] <pasteeater> Dark_Shikari: i think _firstpass (ex: lossless_ultrafast) would follow convention more so than -firstpass.
[00:13:25] <Dark_Shikari> agreed.
[00:14:47] <Honoome> Twinings English Breakfast tea… the second best friend of the late-night developer
[00:15:26] * mru prefers earl grey
[00:15:44] <Honoome> mru: earl grey has a better taste but this has more caffeine power :P
[00:15:52] <mru> I have coffee too
[00:16:16] <Honoome> I already got three today, can't get too much coffee because of the fat content :(
[00:16:21] <pasteeater> Tea. Hot. Earl Grey.
[00:16:33] <mru> wrong order
[00:16:54] <Honoome> and I seriously hope you don't refer to the classic English coffee as that's *not* coffee
[00:17:00] * mru drinks coffee without additives
[00:17:08] <kierank> tea > coffee
[00:17:41] <Honoome> only realistic coffee I found in London was Costa and Nero…
[00:17:42] <mru> I usually make coffee in one of those octagonal pressure boilers
[00:17:52] <mru> freshly ground of course
[00:17:58] <Honoome> okay, that's _coffee_ ;)
[00:18:02] <astrange> people give me too much instant coffee in england
[00:18:04] <Honoome> [although I prefer espresso]
[00:19:42] <mru> I don't have an espresso machine
[00:21:16] <Honoome> when you'll pass by Italy, I'll show you what real coffee is like :D
[00:25:13] <Honoome> (and not what they have in Turin :P I had to suffer through when I went at lu_zero's :P]
[00:25:42] <mru> so where do I go for the Real Stuff?
[00:26:14] <ohsix> you find anyone that will mainline it and has the kit to do it
[00:27:00] <kierank> that cafe in venice in st marks square
[00:27:21] <kierank> the one where it's €50 a cup
[00:27:33] <Honoome> kierank: that's if you want to be made poor quite quickly :P
[00:27:48] <Kovensky> ^@50 a cup?
[00:27:59] <Honoome> I definitely prefer getting it at the Venice train station ^^;;
[00:28:34] <Honoome> just in north-east we have something like six or seven different brands of coffee, for all tastes ;)
[00:48:08] <Honoome> EC2 (library) nonsense: x['reservationSet']['item'][0]['instancesSet']['item'][0]['instanceState']['name'] == 'running'
[00:48:16] <Honoome> this tells me whether an instance is running (after getting x of course)
[00:58:45] <Kovensky> sure is overengineered
[00:58:50] <Kovensky> plus >python
[01:01:22] <Honoome> KotH: uh? python?
[01:02:28] <Kovensky> Honoome: that looks like python syntax
[01:02:39] <Honoome> that's a very generic syntax :) it's ruby anyway in my case :D
[01:02:49] <Kovensky> =p
[01:03:09] <Kovensky> python was the only language I knew that used undecorated variables and quoted strings between []
[01:04:28] <Honoome> after dealing with EC2, writing direct queries on psql console really feels like a welcome change
[01:05:20] <Kovensky> lol
[01:11:22] <mru> Kovensky: javascript does that too
[02:11:18] <peloverde> Anyone have any fancy tips or tricks about going from tables in a specification to some sort of machine readable format
[02:12:19] <mru> pdf?
[02:12:32] <peloverde> I have it in pdf and doc
[02:12:45] <mru> copy&paste?
[02:13:15] <kierank> copy&paste to excel usually works well
[02:13:18] <kierank> with paste special
[02:14:51] <CIA-34> ffmpeg: michael * r21860 /trunk/libavcodec/ (h264.c h264.h h264_cavlc.c h264_cabac.c):
[02:14:51] <CIA-34> ffmpeg: Move check for and call of predict_field_decoding_flag() from the mb code to
[02:14:51] <CIA-34> ffmpeg: the row code. This function would only be needed on a MB basis for MBAFF+FMO
[02:17:05] <Honoome> since Ruby does not compile, I found the conveniente excuse while working with that
[02:17:10] <Honoome> “Deploying on EC2!”
[02:17:39] <kierank> the python library is better
[02:17:40] <kierank> boto
[02:21:16] <peloverde> excel seems to choke in binary strings longer than 10 bits
[02:22:47] <mru> I usually use some combination of emacs and perl
[02:24:24] <Honoome> and perl? who needs perl when you got emacs?
[02:24:31] <peloverde> I don't understand how all these corporate types like excel, I always run into issues like this
[02:25:03] <mru> sometimes perl is easier than emacs
[02:25:18] <Honoome> peloverde: there are things that are definitely working better on Excel than, say, OpenOffice Calc
[02:25:45] <peloverde> yes, but excel also works better than an abacus
[02:25:47] <mru> there are things that smell better than a turd
[02:25:59] <CIA-34> ffmpeg: michael * r21861 /trunk/libavcodec/ (h264.c h264.h):
[02:25:59] <CIA-34> ffmpeg: Move predict_field_decoding_flag() from h264.h to .c as its only used there and belongs
[02:25:59] <CIA-34> ffmpeg: there as well.
[02:26:44] <peloverde> Replace excel with spreadsheets in general if it makes you feel better
[02:32:37] <Dark_Shikari> common/macroblock.c:281: confused by earlier errors, bailing out
[02:32:39] <Dark_Shikari> never seen that before
[02:32:50] <Honoome> peloverde: simpler to use than gnuplot :P
[02:33:19] <peloverde> I find matplotlib to be an adequate replacement for both
[02:38:02] <Honoome> okay I just screwed up my EC2 setup by mistake stopping the wrong instance =_=
[02:38:29] * kierank has done that before
[04:17:53] <peloverde> Anyone know what static_size is in INIT_VLC_STATIC?
[06:47:04] <elenril> morning
[06:49:13] <kshishkov> hej
[06:50:30] <elenril> i knew i shouldn't have involved myself with asf
[06:50:51] <kshishkov> too bad M$ didn't have that feeling
[06:53:12] <elenril> they still use it?
[06:54:54] <kshishkov> probably yes
[06:58:13] * thresh waves
[06:58:27] <thresh> kshishkov: for a self-unemployed person you wake up too early!
[06:58:43] <kshishkov> I used to wake up even earlier
[08:12:52] * av500 waves to the east
[08:13:37] * kshishkov waves back
[08:13:53] * av500 waves to the west
[08:14:16] * kshishkov waits much more time to wave back
[08:18:07] <pJok> mornings :)
[08:18:15] <kshishkov> goda morgnar
[09:18:49] * pross-au nods
[09:21:47] * kshishkov bows
[13:36:03] <elenril> how can i get to files in incoming?
[14:08:18] <Dark_Shikari> kshishkov: short response sent
[14:08:23] <Dark_Shikari> thanks for the comments on my review
[16:06:07] <twnqx> i think i obsereved rockbox devels here recently...
[16:06:15] <mru> yep
[16:06:28] * twnqx needs a rockbox for nano 4th gen :X
[16:06:44] <kshishkov> we don't produce it (yet)
[16:06:57] <twnqx> alternatively 5th
[16:06:59] <twnqx> :X
[16:07:12] <twnqx> i lost my 2nd gen locng time back
[16:07:19] <twnqx> and sold my 3rd...
[16:07:49] <av500> twnqx: the encryption is not yet broken, no way to put rockbox
[16:07:56] <twnqx> oh
[16:08:14] <twnqx> there's encryption involved?
[16:08:58] <kshishkov> av500: why do someone need it broken? It's like saying that you can't fit a screw with hammer
[16:09:31] <av500> twnqx: apple firmware is encrypted/signed
[16:09:42] <twnqx> i thought rockbox just replaces it completely.
[16:09:53] <av500> twnqx: try to convince the bootloader :)
[16:10:06] <twnqx> oh, it's THAT evil.
[16:10:20] <av500> unless the sig is valid, it will not update to the new firmware
[16:10:29] <mru> replace the bootloader too ;-)
[16:10:33] <KotH> patch the bootloader
[16:10:39] * KotH blames mru for being faster
[16:10:40] <av500> locked
[16:10:54] <KotH> remove the lock bit
[16:10:55] * mru wields lockpick
[16:10:59] <av500> u cant
[16:11:04] <KotH> replace teh hardware
[16:11:09] <twnqx> wait...
[16:11:16] * av500 waits
[16:11:17] <twnqx> now THAT would be...
[16:11:23] <mru> not even with a plasma beam?
[16:11:36] <mru> like that guy who hacked the TPM
[16:11:39] <twnqx> heh
[16:11:43] <av500> mru: for a nano?
[16:11:52] <av500> bit of too much effort
[16:12:11] <twnqx> just build a quantum computer to break the digital signature
[16:12:18] <mru> might be fun using a slightly higher power plasma beam on one...
[16:12:36] <av500> twnqx: do that and pass the key to rb team....
[16:13:12] <KotH> the encryption cant be that hard
[16:13:20] <av500> rsa...
[16:13:24] <av500> the usual
[16:13:27] <KotH> how many bits?
[16:13:38] <mru> most secret encryption schemes have stupid flaws
[16:13:39] <av500> no idea, enough I guess
[16:14:07] <merbzt> samsung soc with encryption in the cpu
[16:14:34] <KotH> go for the flaws in the chip
[16:14:34] <av500> we use the same scheme, locked bootloader and signed firmware images
[16:14:44] <av500> (at least we used too)
[16:14:48] <KotH> why?
[16:14:58] <KotH> dont you want your users to use your devices?
[16:15:11] <KotH> do you want them to switch to your competitors instead?
[16:15:11] <av500> god gracious, no
[16:15:20] <av500> KotH: ya, to apple :=
[16:15:22] <av500> KotH: ya, to apple :)
[16:15:25] <mru> someone promised /me an unlocked nexus...
[16:15:42] <av500> they should be unlocked by default
[16:15:47] <KotH> mru: i guess he took your money and run away
[16:16:13] <mru> av500: no firmware locks?
[16:16:20] <av500> I dont think so
[16:16:25] <kshishkov> me found a hidden stash of unlocked Nexuses and want to secretly transport them from Nigeria
[16:16:32] <mru> hehe
[16:16:35] <av500> http://androidandme.com/2010/01/hacks/video-how-to-unlock-and-root-a-nexus-one/
[16:16:57] <av500> make no sense for gg to lock them, they want them used for dev stuff
[16:17:20] <mru> they want people to write shitty java apps, yes
[16:17:26] <mru> not replace their OS
[16:17:51] <av500> g1 dev phone was also not locked, so nexus isnt either it seems
[16:18:16] <av500> mru: what other OS do you propose to put instead? :)
[16:18:28] <mru> rockbox  ;-)
[16:18:47] <kshishkov> mru: it can't run FFmpeg
[16:18:48] <twnqx> on a... phone?
[16:18:51] <av500> a 500$ mp3 player, not bad
[16:19:05] <mru> I was to get it for free...
[16:19:16] <mru> well, we'll see if it materialises
[16:19:18] * av500 got one for free
[16:22:53] <twnqx> can rockbox play .tta+.cue and .ape+.cue?
[16:23:05] <Dark_Shikari> hope it can.
[16:23:08] <kshishkov> ape - yes
[16:23:09] <Dark_Shikari> TTA+cue is really important
[16:23:15] <kshishkov> tta - probably not
[16:23:15] <Dark_Shikari> .... for the touhou lossless music collection ;)
[16:23:23] <Dark_Shikari> why do the japanese use their own formats for everything anyways
[16:23:23] <mru> ape is rather cpu-hungry...
[16:23:38] <mru> Dark_Shikari: ever heard of NIH?
[16:23:45] <twnqx> Dark_Shikari: just converting all the alstromeria records from it to flac >_>
[16:23:48] <kshishkov> mru: and still has not got NEON speedup in lavc
[16:23:48] <av500> NineInchHails?
[16:24:03] <twnqx> alstroemeria*
[16:24:07] <mru> av500: sounds like fun, no?
[16:24:11] <Dark_Shikari> mru: yup, ffmpeg is break isn't it
[16:24:15] <kshishkov> twnqx: rejoice - TTA is unsupported http://www.rockbox.org/wiki/SoundCodecs
[16:24:23] <Dark_Shikari> twnqx: just get the lossy collection
[16:24:24] <Dark_Shikari> fuck flac
[16:24:33] <twnqx> nah
[16:24:41] <av500> fluck
[16:24:42] <Dark_Shikari> v2 mp3 is enough for me
[16:24:45] <kshishkov> Dark_Shikari: it's got worse. Some of them use TAK now
[16:24:53] <twnqx> yeah...
[16:25:30] <Dark_Shikari> also
[16:25:35] <Dark_Shikari> the latest lossless music collection is so large
[16:25:37] <Dark_Shikari> that it breaks utorrent
[16:25:41] <Dark_Shikari> one more reason to get the lossy instead
[16:26:03] <kshishkov> or use Touhou music generator instead
[16:26:23] <Dark_Shikari> 626127863211 bytes
[16:26:26] <mru> http://xkcd.com/411/
[16:26:50] <Dark_Shikari> of course.
[16:27:01] <kshishkov> Dark_Shikari: ask andome, I think he can prod uTorrent author
[16:27:05] <kshishkov> *andoma
[16:27:10] <mru> or use rtorrent
[16:27:15] <Dark_Shikari> kshishkov: they already know
[16:27:18] <Dark_Shikari> it will be fixed in 2.0.1
[16:27:30] <Dark_Shikari> mru: today's xkcd is rather good
[16:27:38] <mru> yeah
[16:27:40] <twnqx> it breaks utorrent?
[16:27:44] <Dark_Shikari> twnqx: yes
[16:27:53] <twnqx> nooo i just have it queued up in 2.0 ;_;
[16:27:54] <Dark_Shikari> almost 600 gigabytes
[16:28:02] <Dark_Shikari> http://www.nyaatorrents.org/?page=torrentinfo&tid=113174
[16:28:03] <Dark_Shikari> read the info
[16:28:06] <twnqx> yeah, that one
[16:28:11] <elenril> wtf is TAK?
[16:28:14] <Dark_Shikari> This torrent is so large it breaks all uTorrent versions up to and including 2.0
[16:28:17] <Dark_Shikari> Also possibly affected: Bitcomet and others. Verified unaffected: Azureus.
[16:28:19] <twnqx> doesn't matter, i only have 190G disk space anyway.
[16:28:20] <Dark_Shikari> Symptoms: on nonzero completion connections drop off in handshake phase.
[16:28:32] <kshishkov> elenril: crappy lossless codec designed for Hydrogenaudio
[16:28:50] <elenril> don't we have enough crappy lossless codecs already?
[16:29:03] <kshishkov> it seems no
[16:29:23] * av500 invents PCMROT13
[16:29:28] <av500> losless
[16:29:35] <mru> Dark_Shikari: that facebook group is currently at 8100 members
[16:29:48] <Dark_Shikari> lol
[16:29:53] <kshishkov> av500: don't forget custom container for it
[16:30:08] <elenril> btw
[16:30:15] <elenril> anyone can apply nut metadata conv table for me?
[16:30:40] <av500> kshishkov: of course
[16:34:23] <KotH> Dark_Shikari: wtf? a 500G torrent?
[16:34:28] <Dark_Shikari> KotH: 580GB
[16:34:52] <kshishkov> that's more than capacity of all my HDDs combined
[16:34:58] <Dark_Shikari> those are some very small hard drives
[16:35:32] <twnqx> av500: the flash is put in in a way it's not writeable at all?
[16:35:48] <twnqx> or is it locked?
[16:35:54] <kshishkov> Dark_Shikari: why, two of them are whopping 160GB!
[16:36:17] <twnqx> :S
[16:36:25] <Dark_Shikari> kshishkov: I got a 2GB external for, like, $170
[16:36:25] <twnqx> i still have 3 of them, too
[16:36:30] <Dark_Shikari> er
[16:36:31] <Dark_Shikari> 2TB
[16:36:41] <Dark_Shikari> a 160GB isn't even worth the space it takes up
[16:36:47] <KotH> Dark_Shikari: i dont have that much free diskspace on a single disk anymore ^^'
[16:36:55] * mru has a _spare_ 1TB drive
[16:36:57] <Dark_Shikari> then get more disks
[16:37:03] * twnqx too
[16:37:05] <Dark_Shikari> my boss at facebook was setting up a 40-disk Raid Z
[16:37:08] <mru> and piles of smaller ones
[16:37:09] <Dark_Shikari> for his pirated movies
[16:37:22] <KotH> Dark_Shikari: i know.. i dropped below 10% free diskspace quite some time ago
[16:37:22] <Dark_Shikari> and he wasn't sure it would be big enough
[16:37:29] <twnqx> lol
[16:37:41] <kshishkov> Dark_Shikari: at least _I_ have free diskspace on all of them
[16:38:11] <av500> twnqx: usually you can lock parts of the flash
[16:38:20] <twnqx> i have a combined space of 553G on my two major arrays
[16:38:28] <av500> this is a SW lock that you apply right after boot
[16:38:32] <twnqx> i see
[16:38:36] <av500> but it cannot be reversed
[16:38:46] <av500> unless you power cycle the flash chip
[16:38:46] <twnqx> only by cold start?
[16:38:49] <twnqx> ok...
[16:38:49] <av500> yup
[16:39:02] <av500> difficult to do on a bga board
[16:39:06] <Dark_Shikari> well this is why I use the lossy collection
[16:39:07] <Dark_Shikari> it's only 110GB
[16:39:12] <av500> and it would only help 1 player, not all of them
[16:39:13] <twnqx> and i guess the ipod doesn't have a jtag interface?
[16:39:15] <Dark_Shikari> leaves me more free space to waste on raw yuv
[16:39:27] <twnqx> lol DS :P
[16:39:36] <av500> twnqx: nice try
[16:39:52] <twnqx> Dark_Shikari: /dev/mapper/raws      3.5T  3.4T  117G  97% /srv/nfs2 <- blurays are evil, too
[16:39:56] <av500> we dont put jtag on production boards, only on debug
[16:40:19] <twnqx> av500: many companied leave them in, just don't polace connectors on
[16:40:40] <Dark_Shikari> yeah, blu-rays too.
[16:40:41] <av500> twnqx: well, the ones that start with A dont
[16:40:43] <Dark_Shikari> but those are at least compressed
[16:41:02] <twnqx> flac is compressed, too.
[16:41:17] <av500> 50GB plyray should have lot of place to uncompressed qvga yuv.....
[16:41:18] <thresh> ur torrent so fat
[16:41:19] <av500> bluray
[16:41:55] <twnqx> unsoldering BGA is PITA
[16:42:33] <twnqx> also, beyond the gear i (currently) have
[16:42:44] <mru> unsoldering isn't so hard
[16:42:51] <mru> it's putting it back that's a bitch
[16:43:11] <twnqx> depends, if you have components on both sides and want to reuse the pcb...
[16:43:39] <mru> you didn't say keeping the rest of the parts intact was a requirement
[16:43:54] <twnqx> obviously it qould be if you want to "crack" an ipod
[16:44:29] <mru> I'll show you how to crack it, see this brick here?
[16:44:34] <kshishkov> use two of them ;)
[16:44:55] <av500> twnqx: even if you unsolder one, if the boot code is good, it will not help you to open all of them
[16:45:05] <twnqx> indeed
[16:45:18] <av500> it might help you to find an exploit....
[16:45:35] <twnqx> unless you have a quantum computer and you only need the public part of the key :P
[16:46:32] <twnqx> oh well, wanted to move away from crapple anyway
[16:47:46] * twnqx needs to look at the B&O player
[16:47:50] <Kovensky> <@Dark_Shikari> it's only 110GB <-- larger than my largest part :(
[16:48:07] <Dark_Shikari> ?
[16:49:14] <mru> twnqx: a quick look at their price tags is usually enough for me
[16:50:32] <twnqx> "only mp3 and wma" was enough for me.
[16:50:55] <twnqx> and i really doubt anyone even tries to put rockbox on :P
[17:15:08] <superdump> Dark_Shikari: did you just say that your boss at facebook has a 40-disk RAID Z for pirated movies in a logged channel?
[17:15:20] <superdump> :)
[17:15:23] <elenril> lol
[17:16:44] <Dark_Shikari> lol
[17:16:50] <Dark_Shikari> this was like a year ago
[17:16:59] <Dark_Shikari> and meh, logs
[17:17:03] <kshishkov> superdump: and it's easy to find DS resume with whom to refer at FB. Hope MPAA won't hear about that
[17:17:12] <Dark_Shikari> by pirated movies, of course, I mean pirate movies
[17:17:22] <superdump> yarrr
[17:17:25] <Dark_Shikari> yarr harrrrrrr
[17:17:28] <superdump> boy does he like pirates?
[17:17:31] <Dark_Shikari> lol
[17:17:35] <superdump> fetish?
[17:17:36] <elenril> isn't downloading legal in eagleland?
[17:17:40] <Dark_Shikari> no
[17:17:40] <superdump> well, that's his business
[17:18:39] <elenril> w00t, mass effect 2 on zero punctuation
[17:18:53] <Dark_Shikari> exactly
[17:19:02] <Dark_Shikari> it's quite funny, and highly accurate
[17:21:36] <kshishkov> would you believe that Bink Video decoder usually takes less CPU than audio?
[17:21:42] <mru> there's still time for the bofh to purge the logs
[17:21:59] <mru> of course that will require a small contribution from the offended party...
[17:23:22] <av500> hmm, for AAC HE sample rate is 0 after avcodec_open() ?!?
[17:23:31] <av500> so SDL seems to default to 22050
[17:24:04] <kshishkov> mru: do you think that KotH needs that kind of income?
[17:24:25] <mru> KotH is not the irc log bofh
[17:24:36] <kshishkov> av500: could be set after first decoded frame
[17:24:52] <av500> yes
[17:25:05] <av500> so, it is correct before we open, then 0, then correct again
[17:25:59] <av500> and we do SDL_audio foo when it is 0....
[17:28:30] <thresh> where's a 'slow down a bit' button for that yahtzee guy
[17:28:58] <kshishkov> thresh: we've discussed that today. "Turbo" buttons are gone now.
[17:44:28] <elenril> lol, chest-high walls
[17:45:11] * kshishkov remembers how "low wall" is translated into German
[17:51:03] <av500> kshishkov: how?
[17:51:27] <kshishkov> quite similar to certain Austrian last name
[17:51:40] <superdump> niedermayer?
[17:51:57] <superdump> wall is mauer isn't it?
[17:52:05] <kshishkov> it is
[17:52:11] <superdump> and low is...?
[17:52:20] <superdump> nieder? :p
[17:52:24] <kshishkov> that's why firewall is called "brandmauer" in Russian
[17:52:39] <superdump> i only knew because i'd been to berlin
[17:53:18] <superdump> niedrige mauer according to google
[17:53:23] <superdump> well... pizza!
[17:53:54] <kshishkov> superdump: you could also have learnt Ukrainian word for ham in Stockholm
[18:00:11] <av500> kshishkov: more like "lower wall"
[18:09:06] <BBB> anyone here good at ASF?
[18:09:20] <BBB> would anyone know how caption streams are detectable in asf?
[18:09:21] <jez9999> BBB: yep, as long as a patch gets checked in
[18:09:32] <jez9999> my expertise is fully available :-D
[18:09:53] <av500> BBB: have sample?
[18:09:58] <kshishkov> av500: could be, Ich kenne Deutsche nicht
[18:10:37] <kshishkov> BBB: apply patch from elenril and he'll tell you what he knows about asf
[18:11:17] <BBB> av500, rtsp://live.cumulusstreaming.com/KFOG-FM
[18:11:34] <BBB> and apply the following one-liner to libaformat/rtp_asf.c, at the end:
[18:11:48] <BBB> +RTP_ASF_HANDLER(asf_pvd, "x-asp-pf",  CODEC_TYPE_DATA);
[18:12:02] <BBB> the last stream has captions
[18:12:18] <BBB> I'm trying to figure out if we can support those without any more icky hacks in the rtp code, i.e. only modify asfdec.c
[18:15:23] <BBB> jez9999, keep pinging me if I don't reply to bugs, I'm busy reviewing various patches so I sometimes forget
[18:15:30] <BBB> I just added a response to issue1740
[18:17:43] * elenril doesn't know a thing about asf
[18:18:04] <jez9999> BBB: what's the point in copying the filename into a local buffer?
[18:25:51] <av500> BBB: ok, I see 2 streams, one audio, one unknown..
[18:28:18] <BBB> av500, right, the unknown is captions
[18:28:39] <BBB> jez9999, other parts of ffmpeg might expect the filename to remain unmodified
[18:29:18] <jez9999> BBB: its modification is opaque
[18:29:27] <jez9999> it's modified right back after the open()
[18:38:05] <BBB> jez9999, I know, it's why I didn't make an issue of it
[18:38:13] <BBB> jez9999, but it's modified, although even just for a split second
[18:38:16] <jez9999> lol
[18:38:20] <BBB> jez9999, that's not good for threaded applications
[18:38:26] <BBB> which is what Michael is concerned about
[18:38:34] <BBB> just change it, it's the right thing, even though it might sound odd
[18:38:50] <jez9999> you want me to submit a new patch?  you know it would take you 5 seconds to add it in
[18:39:05] <BBB> submit it, I'm OK with it, so wait for Michael to say yes
[18:39:08] <BBB> and I'll apply it
[18:39:11] <BBB> that's all I do apparently :)
[18:39:29] <jez9999> why does this have to go through Michael?  most stuff doesnt
[18:39:33] <BBB> note that michael didn't say "yes" or "no", he said nothing :)
[18:39:37] <BBB> because michael maintains file.c
[18:39:44] <jez9999> so he doesnt mind then
[18:39:45] <jez9999> :-)
[18:39:52] <BBB> that's not how he works :)
[18:39:53] <jez9999> neutral from Michael is a ringing endorsement
[18:40:36] * kierank likes the logic
[18:47:40] <Dark_Shikari> kshishkov: got v2 to review yet?
[18:48:15] <kshishkov> I should have attached it
[18:50:52] <kshishkov> it seems I did - in reply to your short mail
[18:51:17] <Dark_Shikari> ah there.
[19:05:45] <Dark_Shikari> kshishkov: what's with the weird run length coding in block types
[19:07:43] <Dark_Shikari> kshishkov: mind if I give you some suggestions here on IRC instead (with the assumption of quick response)?
[19:08:34] <kshishkov> it's not weird
[19:08:48] <kshishkov> it just uses some different scan orders
[19:08:55] <kshishkov> I even posted about it once
[19:09:06] <Dark_Shikari> I meant that the only run lengths allowed are 4,8, 12, and 32
[19:09:15] <kshishkov> ah, those
[19:09:31] <BBB> who's root?
[19:09:39] <BBB> I would like a svn account for someone
[19:09:42] <kshishkov> BBB: KotH+mru+DonDiego
[19:09:48] <kshishkov> ask any of them
[19:09:51] <BBB> ok
[19:10:18] <BBB> mru: ping, dondiego: ping </massping>
[19:10:24] <kshishkov> Dark_Shikari: yes, IIRC it's just high 4 of 16 possible symbols in some Huffman coding scheme are used for denoting runs
[19:10:46] <Dark_Shikari> that's weird.
[19:10:53] <Dark_Shikari> ok, so first idea
[19:10:59] <Dark_Shikari> "i" is only used as the loop counter, not in the loop
[19:11:02] <Dark_Shikari> so try this
[19:11:10] <Dark_Shikari> end = b->cur_dec + t
[19:11:16] <Dark_Shikari> while( b->cur_dec < end )
[19:11:22] <Dark_Shikari> then you don't need the i += line
[19:11:32] <Dark_Shikari> wait, something is weird there
[19:11:39] <Dark_Shikari> why does the run code increment i, but the first bit doesn't?
[19:11:43] <Dark_Shikari> oh, because of the i++.
[19:11:53] <Dark_Shikari> ok, so this will get faster with a while instead, simpler too.
[19:12:07] <BBB> end = b->cur_dec + t is still an initialization, so use for(end = ..; .. < ..;)
[19:12:13] <kshishkov> indeed
[19:12:17] <Dark_Shikari> BBB: works too.
[19:12:27] * BBB is a for()-fan
[19:12:40] * kshishkov is "whatever works" fan
[19:12:44] <BBB> :)
[19:12:46] <Dark_Shikari> ok, so that fine?
[19:13:01] <Dark_Shikari> same with read_patterns
[19:13:01] <kshishkov> yes, looks ok
[19:13:11] <Dark_Shikari> you have a lot of similar loops in which the loop counter is not used for anything
[19:13:12] * kshishkov likes approving reviews on his patches
[19:13:34] <Dark_Shikari> it might be a little bit uglier to remove the loop counter, but there's really no reason to have it.
[19:13:39] <mru> BBB: pong
[19:13:41] <Dark_Shikari> You should probably bench read_patterns for starters though
[19:13:51] <Dark_Shikari> because it's so simple that it's a good benchmark case to see if this is actually a good idea.
[19:14:02] <BBB> mru: can martin have svn access?
[19:14:08] <mru> not my call
[19:14:15] <mru> but I don't mind
[19:14:17] <BBB> who's call is that?
[19:14:21] <BBB> michael was ok with it
[19:14:45] <Dark_Shikari> lines 1039 and 1040 in the patch can be merged
[19:14:51] <Dark_Shikari> same with 1026/1027
[19:14:57] <mru> DonDiego usually handles that stuff
[19:15:45] <BBB> ok, I'll bug him then, thanks though
[19:16:04] <Dark_Shikari> kshishkov: errors like 1086 should probably have error messages, like in h264 decoding
[19:16:38] <Dark_Shikari> 1063-1072 seems a bit silly, why not just do v = get_bits(gb, start_bits - has_sign) ?
[19:16:47] <Dark_Shikari> and then if(has_Sign && v)
[19:16:58] <Dark_Shikari> it looks like the code doesn't run a lot, so it doesn't need to be optimized at the expense of size.
[19:18:18] <kshishkov> I don't like adding avctx as a parameter to each function needing it only for av_log()
[19:18:27] <Dark_Shikari> ah.
[19:18:36] <Dark_Shikari> you don't need avctx to log
[19:18:41] <Dark_Shikari> it'll just say @ NULL
[19:19:14] <kshishkov> it's frowned upon here
[19:19:40] <Dark_Shikari> is read_dct_coeffs faster if you make mode_list a 2D array instead of packing nibbles like that?
[19:19:55] <Dark_Shikari> not saying it would be for sure, but since it's local stack data only, it's not like it has cache effects
[19:19:58] <Dark_Shikari> so you should test.
[19:20:23] <kshishkov> ok
[19:20:52] <Dark_Shikari> same with read_residue
[19:21:09] <Dark_Shikari> 1238-41 can be branchless maybe?
[19:21:12] <BBB> kshishkov, don't forget gcc inlines everything into one huge big function anyway, so it's not like function arguments matter...
[19:21:43] <Dark_Shikari> this is true.
[19:21:56] <Dark_Shikari> 1265 can be branchless
[19:22:01] <Dark_Shikari> 1281 too
[19:22:12] <kshishkov> no, I think 1238-41 will be too obfuscated then
[19:22:35] <kshishkov> for 65 and 81 - yes
[19:23:12] <Dark_Shikari> why didn't you take into account my scaled block idea, i.e. sclaed blocks work exactly like normal ones
[19:23:15] <Dark_Shikari> and use the same code
[19:23:17] <Dark_Shikari> rather than duplicated code
[19:23:20] <Dark_Shikari> or is there some reason that won't work
[19:23:49] <kshishkov> first of all - they need intermediate storage
[19:24:11] <Dark_Shikari> 1402-1403: why do these lines exist?
[19:24:14] <kshishkov> second, I need to add some checks on unallowed block types
[19:24:49] <kshishkov> err, because there's no corresponding function in dsputil and I'm not sure it should be there?
[19:24:58] <CIA-90> ffmpeg: rbultje * r21862 /trunk/libavformat/rtsp.c:
[19:24:58] <CIA-90> ffmpeg: Add functions to send RTSP commands with content attached to them. This will
[19:24:58] <CIA-90> ffmpeg: be used eventually in the RTSP muxer (see thread "[PATCH] RTSP muxer, round
[19:24:58] <CIA-90> ffmpeg: 3" on mailinglist).
[19:24:58] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[19:25:15] <Dark_Shikari> there's no put_pixels_unclamped?
[19:25:53] <kshishkov> no
[19:25:59] <Dark_Shikari> there's a clamped, right?
[19:26:01] <Dark_Shikari> so make an unclamped.
[19:26:22] <Dark_Shikari> and why "unfortunately"
[19:26:38] <kshishkov> more work for me, obviously
[19:26:47] <Dark_Shikari> lol
[19:26:56] <Dark_Shikari> ok, moving on from there... pattern blocks
[19:27:01] <Dark_Shikari> this can be done far far more efficiently
[19:27:23] <Dark_Shikari> col0 = get_value()
[19:27:25] <Dark_Shikari> col1 = get_value()
[19:27:36] <Dark_Shikari> pattern = col0 + (col1<<8)
[19:27:37] <kshishkov> and multiply by two masks?
[19:28:02] <Dark_Shikari> uint64_t patternlarge = pattern * 0x10001000 .... ULL
[19:28:05] <Dark_Shikari> *(uint64_t*)ublock = pattern
[19:28:16] <Dark_Shikari> or, er, 0x000100010001
[19:28:31] <Dark_Shikari> hell, just fuck that and use fill_rectangle
[19:28:33] <Dark_Shikari> that's what it's _for_
[19:28:42] <kshishkov> it's random, not checkerboard
[19:29:00] <Dark_Shikari> ahhhh
[19:29:32] <Dark_Shikari> ok, ignore that.
[19:29:37] <Dark_Shikari> but consider fill_rectangle as an option in other places.
[19:30:19] <Dark_Shikari> dst[(pos & 7) + (pos >> 3) * stride] = v;
[19:30:21] <kshishkov> too small for fill_block, hence two new funcs in dsputil
[19:30:22] <Dark_Shikari> I thought you got rid of that?
[19:30:57] <kshishkov> only for scaled blocks
[19:31:02] <Dark_Shikari> why not for regular
[19:32:01] <kshishkov> they output straight to output plane instead of 64-byte buffer and keeping two version of 16 scans is not good
[19:32:13] <Dark_Shikari> you're already keeping two versions
[19:32:18] <Dark_Shikari> one for scaled, one for unscaled
[19:32:27] <kshishkov> same data
[19:32:34] <Dark_Shikari> ah.
[19:32:50] <Dark_Shikari> then make some nice macro to hide it
[19:32:55] <Dark_Shikari> it looks ugly and duplicated code
[19:33:42] <kshishkov> ok
[19:34:22] <Dark_Shikari> 1783/1784 should use write-combining
[19:34:56] <Dark_Shikari> 1787/1788 should just have linesize be <<=1 at the start
[19:34:59] <Dark_Shikari> rather than doing it in each iteration
[19:35:05] <kshishkov> AV_WN16(dst, pix*0x0101) ?
[19:35:09] <Dark_Shikari> I guess.
[19:35:15] <Dark_Shikari> depending on whether or not the destination is aligned or not
[19:35:24] <Dark_Shikari> pick the aligned vs unaligned macro
[19:35:28] <kshishkov> it is always 8-aligned
[19:35:48] <kshishkov> we operate on 8x8 blocks at least
[19:35:52] <Dark_Shikari> meaning each block of 2 is always 2 aligned
[19:35:56] <Dark_Shikari> which is good enough
[19:38:55] <Honoome> elenril: is the metadata/mov artist fix in svn already, or should I look into it? :P
[19:40:30] <kshishkov> Honoome: IIRC he begged to apply his patch for something, so you can help
[19:40:58] <elenril> Honoome: not yet
[19:41:10] <Honoome> kshishkov: if nobody beats me I'll do that during the weekend, no time today :/ but if it was in svn I would have asked the gentoo maintainer for a new snapshot ;)
[19:41:12] * elenril is pretending to be studying atm, will look at it tomorrow
[19:41:26] <Honoome> anyway, I'm signing off since tomorrow morning I have to wake up
[19:43:24] <DonDiego> gnite
[19:43:37] <kshishkov> as you Diegos say
[19:45:56] <twnqx> are language tags for streams possible in avi?
[19:48:09] <elenril> iirc yes
[19:51:36] <elenril> http://abcavi.kibi.ru/infotags.htm i think IAS* are supposed to do this
[19:52:11] <elenril> why would you want to create such an abomination though?
[19:52:46] <twnqx> see main channel. guy is asking how to set language tags for his avi >_>
[19:54:32] <twnqx> put_le16(pb, 0); /* language */
[19:54:33] <twnqx> hmmmm
[19:55:28] <elenril> don't expect any more documentation than that ;)
[19:58:23] <mru> that's not even doxygen
[20:03:53] <mru> anyone know what compilers do/don't support aligning stack variables to 8/16 bytes on x86?
[20:04:17] <BBB> DonDiego, ping!
[20:05:12] <DonDiego> pong
[20:07:29] <DonDiego> what's up?
[20:09:40] <Dark_Shikari> mru: MSVC, ICC
[20:09:43] <Dark_Shikari> er
[20:09:47] <Dark_Shikari> yeah, and ICL
[20:09:59] <mru> of the ones relevant for ffmpeg?
[20:10:02] <Dark_Shikari> ICC
[20:10:06] <mru> can or can't?
[20:10:09] <Dark_Shikari> can't
[20:10:13] <Dark_Shikari> those are ones that can't
[20:10:18] <mru> and gcc can?
[20:10:20] <Dark_Shikari> yes
[20:10:26] <mru> icc can't even 8?
[20:10:29] <Dark_Shikari> not sure.
[20:10:31] <mru> guess not
[20:10:35] <mru> abi requires only 4
[20:15:59] <pengvado> err, I thought ICC can align variables, it just doesn't align the stack pointer, thus breaking a few asm functions that do it the gcc way.
[20:17:58] <BBB> DonDiego, can you give martin storsjo a svn account?
[20:22:39] <Dark_Shikari> pengvado: oh, you're right
[20:22:41] <Dark_Shikari> yeah, that's true
[20:22:43] <Dark_Shikari> same with MSVC
[20:22:48] <Dark_Shikari> so yeah, both MSVC and ICC align variables but not stack
[20:23:05] <Dark_Shikari> btw, random bug report, not sure if anyone knows about this sort of thing
[20:23:13] <Dark_Shikari> suppose I have two files
[20:23:17] <Dark_Shikari> 1.mp4: h264 + aac in mp4
[20:23:21] <Dark_Shikari> 2.mp4: mjpeg in mov
[20:23:37] <Dark_Shikari> I merge these into a single mp4 using ffmpeg and vcodec copy, acodec copy, newvideo/vcodec copy.
[20:23:43] <Dark_Shikari> when muxing, for the h264 video track, it says "vidoe: 0x0021"
[20:23:47] <Dark_Shikari> instead of "video: h264"
[20:23:56] <Dark_Shikari> But it does it correctly, and when you use ffmpeg -i on the resulting file, it says h264.
[20:27:59] <DonDiego> BBB: yes
[20:28:05] <DonDiego> i can
[20:28:11] <DonDiego> now what? :)
[20:37:06] <CIA-90> ffmpeg: mru * r21863 /trunk/libavcodec/dsputil.c:
[20:37:06] <CIA-90> ffmpeg: Simplify some declarations of aligned arrays
[20:37:06] <CIA-90> ffmpeg: If DECLARE_ALIGNED_16 works on uint64_t it will work smaller types too.
[20:37:06] <CIA-90> ffmpeg: mru * r21864 /trunk/ (configure libavcodec/dsputil.h): Add LOCAL_ALIGNED() macro for declaring aligned local arrays
[20:37:06] <CIA-90> ffmpeg: mru * r21865 /trunk/configure: PPC and x86 support aligning variables on stack
[20:37:07] <CIA-90> ffmpeg: mru * r21866 /trunk/libavcodec/ (7 files): Use LOCAL_ALIGNED macro for local arrays
[20:38:47] <BBB> dondiego: if possible, could you actually do it? :)
[20:39:30] * DonDiego makes up username and password from thin air
[20:40:20] <DonDiego> isn't the procedure clear by now?
[20:40:25] * janneg hands DonDiego /dev/random
[20:41:44] <ohsix> mstorsjo `uuidgen`
[20:44:29] <peloverde> Was just changing the test specs on those demuxers really the correct answer?
[20:44:49] <mru> michael says so
[20:45:20] <peloverde> I look at for instance PVA demux and it does not look right: http://fate.multimedia.cx/index.php?test_result=44445708
[20:45:50] <peloverde> mpeg_decode_postinit() failure with 6 errors and half the previous frames
[20:46:08] <mru> send email
[20:46:29] <DonDiego> BBB: i need username and pw for martin
[20:48:21] <peloverde> I did, I tracked down the commit and michael tried to shift the blame
[20:49:03] * DonDiego bites his tongue :)
[20:49:10] <mru> bitching here won't help
[20:49:33] <mru> at least not until michael reads the logs
[20:49:39] <mru> they are mailed at midnight UTC
[20:49:58] <peloverde> I figure maybe when he greps for his name he will see it and give it another look
[20:54:36] <BBB> dondiego: dondiego: how would I know these?
[20:54:49] <DonDiego> BBB: well, how would i?
[20:54:58] <DonDiego> 21:40 <@DonDiego> isn't the procedure clear by now?
[20:55:03] <BBB> dondiego: not sure :) do you want me to ask him to email you?
[20:55:24] <DonDiego> this makes me assume the answer is "no"
[20:55:31] <BBB> indeed :)
[20:55:38] * BBB assumes there's a doc that he missed or so
[20:55:40] <DonDiego> well, then just say so :)
[20:55:47] <BBB> I have no idea :)
[20:58:22] <DonDiego> i need to have username and pw sent to me, encrypted with my gpg key
[20:58:46] <ohsix> mash his name together for the username and generate a password
[20:58:47] <DonDiego> where would be a good place to document this?
[21:01:38] <janneg> DonDiego: developer policy
[21:03:52] <janneg> s/er/ment/
[21:05:46] <CIA-90> ffmpeg: mru * r21867 /trunk/libavcodec/dsputil.h: 10l: remove stray '(' I don't know where it came from
[21:06:41] <Dark_Shikari> it came from the parenthesis factory
[21:07:29] <mru> maybe it leaked in from some lisp code
[21:07:43] <BBB> dondiego: you're talking black magic to me
[21:08:00] <BBB> dondiego: but I'll forward the msg to him anyway :)
[21:09:10] <DonDiego> what part could be black magic?
[21:09:19] <DonDiego> you do have a user account yourself..
[21:09:23] <BBB> your gpg key, for example
[21:09:35] <BBB> back then you sent me the pwd as a text msg to my cell phone
[21:09:37] <BBB> I think
[21:09:49] <BBB> I added it to my keychain and have no idea what it is
[21:09:51] <BBB> but it still works
[21:09:51] <DonDiego> that's a possibility as well
[21:10:02] <mru> BBB: yeah, but gsm encryption was hacked since then
[21:10:10] <DonDiego> i assume you do know what gpg is, don't you?
[21:10:19] <peloverde> hmm.... The mpeg_decode_postinit happens in r21624, sorry michael! fate needs a better way of tracking this stuff
[21:10:20] <mru> gpg is a misnomer
[21:10:22] <mru> you mean pgp
[21:10:42] <mru> gpg is but one implementation
[21:10:52] <DonDiego> true that..
[21:11:07] <DonDiego> but it's the free one, and the default one in our circles..
[21:11:16] <mru> so?
[21:11:29] <mru> it's like saying x264 when you mean h264
[21:11:56] <peloverde> PGP is a registered trademark h.264 isn't
[21:12:12] <mru> linux is a registered trademark
[21:12:18] <mru> and unix
[21:12:37] <peloverde> yes and when we say Linux to refer to Linux that is legit
[21:12:42] <mru> lots of standards have trademarked names
[21:12:50] <peloverde> If we use the name Linux to refer to FreeBSD that isn't
[21:12:58] <Dark_Shikari> mru: doesn't gpg use its own format?
[21:13:03] <Dark_Shikari> even though it's the same algorithm
[21:13:19] <mru> Dark_Shikari: it supports the standard key exchange format
[21:13:26] <Dark_Shikari> ah k
[21:13:31] <mru> although it normally keeps keys in a different format
[21:13:36] <mru> as does the commercial pgp app
[21:13:41] <peloverde> PGP is a program, GPG is a program OpenPGP is a format
[21:14:13] <mru> back in the old days, it was all just pgp
[21:14:23] <peloverde> it isn't 1991 anymore
[21:14:30] <mru> and you got it in printed books
[21:21:34] <CIA-90> ffmpeg: alexc * r21868 /trunk/libavcodec/get_bits.h: get_bits: Fix spelling and grammar in GET_VLC() comment.
[21:21:38] <peloverde> DonDiego: I'm surprised you never caught that one ^^
[21:21:56] <DonDiego> :)
[21:22:17] <peloverde> if...than makes my eyes bleed
[21:22:22] <mru> he's obviously never used the macro
[21:32:57] <BBB> dondiego: I sort of know pgpgpg
[21:33:00] <BBB> but I don't use it :)
[21:33:09] <BBB> DonDiego, but don't forget, this is not for me, it's for martin
[21:33:17] <BBB> might be easier if you discuss with him, perhaps by email?
[21:38:23] <CIA-90> ffmpeg: mru * r21869 /trunk/configure: configure: allow setting strip tool with --strip
[21:38:23] <CIA-90> ffmpeg: mru * r21870 /trunk/tests/regression-funcs.sh: Use stripped executable in regression tests
[21:40:17] <twnqx> is there a high chance that mjpeg in swf is broken?
[21:40:29] <twnqx> decoder, that is
[21:40:35] <Dark_Shikari> mjpeg can go in swf?
[21:40:43] <twnqx> Input #0, swf, from 'nj_chapterninjai11_bb.swf?cpcode=35395':
[21:40:43] <twnqx>   Duration: 00:19:18.59, bitrate: 128 kb/s
[21:40:44] <twnqx>     Stream #0.0: Audio: mp3, 44100 Hz, 2 channels, s16, 128 kb/s
[21:40:44] <twnqx>     Stream #0.1: Video: mjpeg, yuvj420p, 600x250 [PAR 72:72 DAR 12:5], 24 tbr, 24 tbn, 24 tbc
[21:41:20] <peloverde> Dark_Shikari: it doesn't seem like a surprise a lot of garbage can go in an swf
[21:41:22] <twnqx> just resolution flips all around, ffplay hangs after a second
[21:41:30] <twnqx> mplayer just segfaults
[21:41:54] <Dark_Shikari> maybe it's actually a bunch of jpegs
[21:42:43] <twnqx> it's chapter 11 of ninjai :X
[21:43:25] <mru> jai?
[21:43:28] <mru> ninja?
[21:43:29] <mru> hmm...
[21:44:39] <twnqx> plays in constant resolution in flash
[21:51:09] <Vitor1001> peloverde: BTW, sorry for the red herring
[21:51:10] <Vitor1001> :(
[21:51:47] <peloverde> Vitor1001: It's alright, I think I flew off the handle a little bit there
[21:52:35] <peloverde> I'm trying to get SBR landed before I finish PS
[21:53:24] <peloverde> and separating the div cases which I needed to do to try the inplace butterflies did give me a speed up so i kept that part
[21:57:04] <Vitor1001> You're working already in PS?
[21:57:07] <Vitor1001> Nice \o/
[21:57:24] <peloverde> PS is what I'm getting paid for, and I haven't been paid in quite a while
[21:57:57] <Vitor1001> Nice, even better than doing it for free ;)
[21:58:04] <peloverde> indeed
[21:58:58] <twnqx> what is that PS thing, actually? mpeg program stream?
[21:59:06] <Kovensky> Parametric Stereo
[21:59:11] <Kovensky> HE-AAC+
[21:59:13] <twnqx> ah
[21:59:16] <peloverde> mpeg4 parametric stereo
[22:00:21] <peloverde> I wonder if it's in 13818-7, that's generally 100x easier to read
[22:00:40] <peloverde> except lately 14496-3 and 13818-7 have gotten lazy about cross referencing each other
[22:01:21] <kierank> i hate it when specs cross reference each other
[22:01:30] <mru> and you have to pay for both
[22:01:32] <mru> grrr
[22:02:05] <kierank> I'm almost certain the spdif ones are deliberately done so you have to pay for about 10 specs
[22:02:25] <mru> 1. take 10 specs
[22:02:32] <mru> 2. interleave the pages
[22:02:46] <mru> 3. split the lot in equal-size chunks
[22:02:48] <mru> 4. ...
[22:02:57] <mru> 5. profit
[22:02:59] <janneg> profit
[22:03:12] <twnqx> as in "5. profit \o/"
[22:03:21] <drv> add salt to taste and serve on lightly toasted bread
[22:03:39] <kierank> it's nice however when the local government has paid for full access to all british specs. It's nice downloading one massive spec with price £350 or something and just thinking haaa screw you standards bodies
[22:04:30] <mru> which govt is that?
[22:04:38] <kierank> essex county council
[22:04:51] <kierank> only found out about it a few weeks ago
[22:04:59] <mru> you work at the council?
[22:05:02] <kierank> no
[22:05:09] <kierank> through the public library
[22:05:12] <mru> ah
[22:05:19] <mru> nice
[22:06:31] <kierank> I wonder what the most expensive spec is
[22:08:04] <mru> no "sort by price" option?
[22:08:27] <kierank> doesn't seem to be available
[22:13:47] <peloverde> blol after giving up on editing mpeg-4 audio related articles on wikipedia they are now citing stuff I wrote for wiki.multimedia.cx
[22:13:49] <twnqx> VP6F... how many VP6 variants are there? :S
[22:14:11] <mru> at least 6 ;-)
[22:32:36] <tborg> mru, you could do me a big favor and test the just posted patch for "Buffer overflow in ALS decoder" while I'm still online today... approx. one hour left...
[22:33:38] <mru> on it
[22:33:57] <tborg> :)
[22:36:16] <mru> runs cleanly now
[22:36:36] <tborg> thank you!
[22:54:17] <CIA-90> ffmpeg: thilo.borgmann * r21871 /trunk/libavcodec/alsdec.c: Fix wrong buffer allocation for MCC in ALS.
[23:27:40] <CIA-90> ffmpeg: thilo.borgmann * r21872 /trunk/libavcodec/alsdec.c: Fix sizeof()-statement to use the actual pointer type.
[23:44:37] <BBB> Vitor1001, I'm affraid postfilter will take a while, I don't understand anything of that fft stuff
[23:44:48] <BBB> Vitor1001, any advice on the best way to figure out what that fft stuff is doing?
[23:45:11] <Vitor1001> Did you suceeded in using FFmpeg fft funcs?
[23:46:02] <BBB> no
[23:46:07] <BBB> or well, I can use them
[23:46:09] <Vitor1001> :(
[23:46:12] <BBB> but the output is completely different
[23:46:24] <BBB> I tried mdct, fft, rdft and something else
[23:46:35] <BBB> I still think it's rdft
[23:46:40] <Vitor1001> And the problem is beyond some scaling?
[23:46:43] <BBB> but it probably does something after rdft
[23:46:45] <BBB> yes
[23:46:59] <Vitor1001> which func?
[23:47:05] <BBB> com_wmsfft.c, all three
[23:47:21] <Vitor1001> none of them was something familiar?
[23:47:21] <BBB> I'm working on the second now
[23:47:31] <BBB> it looks like rdft
[23:47:32] <BBB> a lot
[23:48:04] <Vitor1001> do you have something easily compilable?
[23:48:13] <BBB> ?
[23:48:23] <Vitor1001> Some patch I can give a look
[23:48:27] <BBB> ah
[23:48:37] <BBB> I can give you the RE-version of my postfilter patch
[23:48:46] <BBB> but it includes all kind of fuzzy code from the binary
[23:48:48] <BBB> is that ok?
[23:48:57] <Vitor1001> sure
[23:51:24] <BBB> you want it by mail?
[23:51:33] <Vitor1001> yes, its better...
[23:51:57] <BBB> sent
[23:52:17] <BBB> there's some debug code in com_wmsapf.c, don't pay attention to that please :)
[23:52:30] <BBB> and there's a lot of cruft in com_wmsfft.c, which is what I'm trying to do
[23:52:53] <BBB> I was thinking of making a float version of the first function and just look how similar it is to rdft in float
[23:53:09] <Vitor1001> sure, I'll give a look at it now
[23:56:34] <Vitor1001> I wonder what the hell they are doing, there are not a thousand ways to do a FFT :p
[23:58:13] <BBB> my guess is that the two bottom functions are the inverse of one another, like rdft vs. irdft
[23:58:24] <BBB> and then the top function is the fft_permute/calc
[23:58:49] <BBB> but like I said, very confusing
[23:59:53] <CIA-90> ffmpeg: mru * r21873 /trunk/libavcodec/ (get_bits.h x86/mathops.h mathops.h): Move NEG_[US]SR32 macros to mathops.h


More information about the FFmpeg-devel-irc mailing list