[FFmpeg-devel-irc] IRC log for 2010-03-15

[irc at mansr.com]

[00:00:40] <CIA-92> ffmpeg: aurel * r22534 /trunk/libavformat/ (9 files):
[00:00:40] <CIA-92> ffmpeg: move ff_url_split() and ff_url_join() declarations to internal.h
[00:00:40] <CIA-92> ffmpeg: those functions are not part of the public API
[00:20:12] <CIA-92> ffmpeg: aurel * r22535 /trunk/libavformat/matroskadec.c: matroskadec: use more appropriate error code
[02:33:13] <CIA-92> ffmpeg: astrange * r22536 /trunk/ffmpeg.c: ffmpeg: Factor out redundant sync_ipts calculation
[02:34:37] <CIA-92> ffmpeg: astrange * r22537 /trunk/ffmpeg.c: ffmpeg: Combine variable declaration and definition
[06:27:39] <KotH> ohayou gozaimasu, minna-san
[06:28:14] <kshishkov> おっす
[06:53:56] <pJok> morgens :)
[06:54:08] <jai> morning pJok :)
[06:54:15] <thresh> moroning
[06:54:22] <jai> O_O
[06:55:11] <pJok> mornings jai :)
[06:55:14] <kshishkov> goda morgnar
[06:57:00] <pJok> mornings kshishkov :)
[07:59:28] <ohsix> why are ffts so magical :(
[07:59:50] <ohsix> they can do all sorts of junk, i'd like to understand their primacy beyond the basic utility
[08:00:06] <ohsix> some jerks use it for multiplying huge numbers, and i have no clue how
[08:01:08] <Dark_Shikari> ohsix: the concept is simple
[08:01:17] <Dark_Shikari> 1) FFTs are magic O(n*log(n))
[08:01:29] <Dark_Shikari> 2) there's a trick to do multiplication in the FFT domain that's faster than normal
[08:01:39] <Dark_Shikari> 3) FFTs are magic nlogn
[08:01:55] <ohsix> is the magic summingn them in scale space then transforming them back?
[08:02:01] <Dark_Shikari> basically yes I think
[08:02:13] <ohsix> hm, i didn't think about that
[08:02:22] <ohsix> that works for powers and a bunch of junk too
[08:03:04] <KotH> also keep in mind, that exp() and log() in a ring are nothing else than a FT
[08:03:11] <ohsix> i posted a bug for the free picture thing too, NONSENSICAL SYLLABLES AND PREPOSTEROUS GAY ACTS
[08:03:19] <ohsix> haha that is not it; darn my clipboard
[08:03:29] <ohsix> https://bugzilla.gnome.org/show_bug.cgi?id=612773
[08:03:44] * KotH ponders whether to ban ohsix for this outragous comment ;)
[08:04:14] <Dark_Shikari> lol
[08:04:32] <ohsix> KotH: that is the primer i was looking for, i didn't think about that; i didn't understand the transform anyways, just some uses, but if its just a power series then i guess thats how it goes
[08:05:15] <ohsix> there was a clever hack i saw some years ago that used logarithms for everything too
[08:05:31] <KotH> ohsix: uhmm.. i think you first want to learn all the properties of FT, LT and ZT, then properties of groups and rings
[08:05:43] <ohsix> i will when i need to
[08:05:43] <KotH> ohsix: the rest is pure combination of these different properties
[08:06:27] <ohsix> how they do multiplcations and shape fitting was just something i figured i'd ask about; or go without knowing at that moment
[08:09:02] <KotH> which reminds me.. i should somewhen relearn LT and ZT
[08:09:31] * KotH forgot everything about them over the years
[08:09:34] * KotH blames mru 
[08:09:44] <ohsix> i guess correlation comes cheap when its all an addition, hm, and if you transform it back you get magic
[08:10:33] <av500> KotH: same here
[08:12:28] <KotH> ohsix: a correlation is a convolution operation of two signals
[08:12:36] <KotH> ohsix: which is very expensive
[08:12:58] <KotH> ohsix: a convolution in time space is a the same as a multiplication in frequency space though
[08:14:21] <KotH> ohsix: http://en.wikipedia.org/wiki/Fourier_transform#Properties_of_the_Fourier_transform
[08:16:44] <ohsix> my understanding is too patch to actually enjoy that, i just know some terms of art
[08:25:18] <KotH> it doesn't matter whether your understanding is patchy or not. to enjoy that kind of stuff you need a form of mathematical masochism
[08:25:38] <ohsix> heh knowing what something says is pretty satisfying
[08:25:57] <ohsix> especially if it made your eyes glaze over for a significant amount of time :P
[08:26:48] <ohsix> theres a lot of open source math packages :\
[08:33:01] <KotH> like ffmpeg? ;)
[08:33:45] <ohsix> nah like yorick and octave
[08:34:17] <ohsix> they're probably all good, but it gets pretty imperative when you want to do anything complex and you have to pick one :\
[08:36:00] <CIA-92> ffmpeg: mstorsjo * r22538 /trunk/configure: Add dependencies used by the RDT and ASF/RTP code
[08:49:50] <CIA-92> ffmpeg: benoit * r22539 /trunk/libavformat/riff.c:
[08:49:50] <CIA-92> ffmpeg: riff: don't pad extradata when writing ASF.
[08:49:50] <CIA-92> ffmpeg: Patch by Anton Khirnov mirror(moc liamg saksyw)
[08:50:36] <ohsix> that guy should just use a gmail label :O
[08:50:37] * thresh would write a bot that will deobfuscate e-mails ffmpeg commit messages and spam those
[08:51:13] <kshishkov> good luck with my commits
[08:54:14] <hyc> URLProtocol handlers are kinda braindead, when you have multiple variants of a base protocol...
[08:57:46] <wbs> hyc: quick question: does your librtmp implementation support sending of video to a rtmp server?
[08:58:01] <hyc> wbs: not at the moment
[08:58:09] <hyc> but should be simple enough to add
[08:58:11] <wbs> ok
[08:58:12] <hyc> who uses that?
[08:58:25] <wbs> I may use it from time to time
[08:58:56] <hyc> what code do you use for it? what does the expected API look like?
[08:59:02] <hyc> obviously you have to mux it as FLV first
[08:59:47] <wbs> yes, I open a flv muxer and open a rtmp://server/app/name url for writing
[09:00:26] <wbs> or just ffmpeg -i foo -f flv rtmp://server/app/name
[09:00:31] <wbs> add -re to that, too
[09:00:59] <hyc> hm, cool. don't you need some kind of authentication to open a seesion with the server?
[09:01:12] <wbs> that's fully up to the server
[09:01:25] <wbs> for some servers, the url is the secret
[09:01:34] <hyc> right. but the current libavformat implementation has no security support at all
[09:01:55] <wbs> so you publish to rtmp://server/app/userspecificsecret, and the server then makes the stream available on some other publicly available url
[09:02:01] <hyc> ahh.
[09:02:34] <hyc> boy, *that'*s secure... ;)
[09:02:41] <wbs> :-)
[09:03:31] <hyc> I'll cobble something together. have nothing to test against though.
[09:07:37] <wbs> wowza test setups has something similar out of the box (or easy to enable at least, iirc), that allows everybody (or only localhost?) to send to rtmp://server/live/<whatever>
[09:07:48] <wbs> and then you can watch it at the same url
[09:09:32] <hyc> ah I see, they have a free developer edition
[09:10:32] <hyc> hm, since you're actually using this code already - does ffplay work with rtmp urls for you? just hangs for me. which is why I just decided to sidestep all of that code.
[09:11:15] <wbs> yes, it works for me. not with all servers, though, but at least with wowza (and reportedly also with FMS)
[09:11:30] <wbs> there's some problems when handshaking with red5 iirc
[09:11:53] <hyc> well, rtmpdump works with everything
[09:12:24] <hyc> doesn't seem to be worth my time to debug one when we have a fully working other
[09:12:56] <hyc> I'll get rtmp_write working in a bit then
[09:14:47] <wbs> well, in some setups, less external dependencies is a plus. but if you get it functionally equivalent on all accounts, I guess its worth considering
[09:16:11] <hyc> getting write support is trivial. so the question is simply do you want rtmpe/rtmps support or not.
[09:16:19] <hyc> if yes, then you need crypto libraries.
[09:17:28] <hyc> we can probably rewrite those bits to use gnutls/gcrypt if necessary
[09:17:40] <hyc> tho IMO, gnutls is too buggy to rely on
[09:18:18] <wbs> rtmpe/rtmps isn't a requirement for me, but if it can be enabled optionally, it's a plus of course
[09:18:53] <wbs> but please don't take my opinions as representative for the other developers :-)
[09:19:28] <hyc> no, I totally get it. I'd avoid adding new dependencies as much as possible
[09:19:55] <wbs> is librtmp generally available (e.g. in debian/ubuntu repos), btw?
[09:20:21] <hyc> as far as I know, no one has pkg'd it on its own yet.
[09:20:33] <hyc> so it's implicitly included in their rtmpdump pkgs
[09:21:10] <wbs> ah, well that's a bit of a hurdle for general acceptance I think. if I'm going to use external libraries, that should be something that I can apt-get and forget
[09:21:37] <hyc> eh... no one said it needs to be an external dependency
[09:21:48] <hyc> after all, it's homed on the mplayer servers
[09:21:54] <wbs> ah, so you're going to bundle the librtmp code within libavformat?
[09:22:09] <hyc> just another external svn reference
[09:22:17] <hyc> I think that would be the easiest way to go
[09:22:25] <wbs> ewww :-)
[09:22:42] <hyc> well, that's getting ahead of ourselves.
[09:22:51] <hyc> first someone has to decide this is ok to incorporate
[09:22:59] <wbs> yeah, true
[09:23:37] <hyc> Compn raised the question a few months ago
[09:23:39] <hyc> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-September/075579.html
[09:23:46] <hyc> and it looks like it went nowhere
[09:24:02] <hyc> perhaps because no one wanted to take the time to investigate or write the code
[09:24:24] <hyc> now I've done that, we'll see what obstacles remain
[09:29:49] <kshishkov> hyc: could be me
[09:32:23] <hyc> kshishkov: I would have expected you. ;) but you didn't reply to that email thread
[09:35:04] <kshishkov> haven't got right words yet
[09:36:33] <kshishkov> it's not that I'm against having fully working RTMP implementation but the way we get it should be discussed
[09:38:59] <hyc> yes. but the discussion in September went nowhere. possibly because there was no clear idea of what to do.
[09:39:20] <hyc> Now we have a straw-man implementation to talk about in concrete terms.
[09:40:10] <kshishkov> straw-man == dummy?
[09:41:22] <hyc> basically, yeah. it was thrown together quickly to get something working
[09:41:34] <kshishkov> I know that rtmpdump works
[09:41:55] <hyc> it shows there are still problems (e.g. seek) that need to be thought about
[09:42:00] <kshishkov> but I'd like to know what's missing from current lavf implementation
[09:43:08] <hyc> well, there's something wrong with the handshake, it hangs when trying to connect to a test rtmplite server
[09:43:30] <hyc> it doesn't have the buffer-empty recovery logic that we added to rtmpdump
[09:43:52] <kshishkov> ah
[09:43:57] <hyc> and it obviously is missing all of the crypto and tunneling support
[09:44:27] <kshishkov> yes, that's why you should have your glue code fro rtmpt/rtmpe/whatever
[09:44:31] <kshishkov> bbl
[10:30:30] <CIA-92> ffmpeg: mstorsjo * r22540 /trunk/libavformat/avformat.h:
[10:30:30] <CIA-92> ffmpeg: Add a new field AVFormatContext.start_time_realtime
[10:30:30] <CIA-92> ffmpeg: Currently intended to be used by the RTP muxer
[10:31:25] <CIA-92> ffmpeg: mstorsjo * r22541 /trunk/doc/APIchanges: Add APIchanges entry for AVFormatContext.start_time_realtime
[10:37:19] <CIA-92> ffmpeg: mstorsjo * r22542 /trunk/libavformat/ (utils.c internal.h): Move the NTP offset definitions to internal.h
[10:38:01] <CIA-92> ffmpeg: mstorsjo * r22543 /trunk/libavformat/rtpenc.c: Use AVFormatContext.start_time_realtime in the RTP muxer
[11:47:05] <superdump> does it really make sense that michael is talking about x86 asm maintenance when he has old cpus and it seems (from some mailing list comments) he prefers to actually use the older of those which is older than a p4 dual or something
[11:47:31] <pross-au> you really believe that 'dump
[11:47:39] <superdump> x86 asm maintenance without using modern x86 cpus that the majority of users have seems a bit weird to me
[11:47:43] <superdump> believe what?
[11:47:58] <jai> lol @ 'dump
[11:48:09] <superdump> yes, i do really believe that michael develops on something older than a p4 dual
[11:48:14] * kshishkov waves
[11:48:18] <superdump> hello kshishkov
[11:49:04] <pross-au> Ok
[11:49:08] <Yuvi> I think his laptop is a yonah
[11:49:14] <superdump> from my perspective, i would be happy for some hardcore modern x86 simd instruction set optimisation
[11:49:16] <kshishkov> that was just to remind you there are some FFmpeg devs with old HW and not complaining about it
[11:49:22] <Yuvi> or merom, I forget
[11:49:39] <superdump> kshishkov: understandable that you don't complain about it if only old stuff is maintained
[11:50:35] <superdump> Yuvi: mmm, i think it's a pentium D branded thing whatever it is
[11:51:14] <superdump> but still on the mailing list, michael said something like he'd have to fire up his pentium D machine to run some tests which made it sound like while he has the newer cpu, he uses whatever he had before
[11:51:21] <kshishkov> mine fastest CPU is PowerPC 1.42GHz again
[11:52:06] <superdump> Dark_Shikari and pengvado have done a great job with the asm in x264
[11:52:11] <pross-au> kshishkov: my daily rig is a 1.6Ghz dothan
[11:52:20] <superdump> it would be nice if ffmpeg was at the same level and up to date
[11:52:30] <superdump> but obviously that will take time and effort
[11:52:33] <superdump> and expertise
[11:52:35] <Yuvi> probably http://en.wikipedia.org/wiki/Pentium_Dual-Core#Merom-2M since he does 64-bit iirc
[11:52:49] <kshishkov> why not ask directly?
[11:53:28] <kshishkov> and I think if somebody can offload him of x86 maintainance and Michael is willing it would be a very good thing to do
[11:53:49] <superdump> well that has SSSE3
[11:54:09] <twnqx> kshishkov: i removed an athlon XP 1800+ from its case yesterday, wanna have? :P
[11:54:11] <superdump> mmm
[11:54:26] <superdump> someone with ninja x86 asm skills
[11:54:33] * superdump looks at pengvado and Dark_Shikari
[11:54:57] <kshishkov> twnqx: I don't have a place to fit it anyway. MacMini with aforementioned PowerPC is also my biggest computer case too
[11:55:04] <twnqx> :o
[11:55:24] <twnqx> it doesn't need a case anyway :P
[11:55:26] <superdump> just run it open
[11:55:31] <superdump> :)
[11:55:57] <twnqx> i'll even drop in a fitting AGP card
[11:56:03] <kshishkov> superdump: only if you manage to solder it somewhere
[11:56:11] <superdump> why solder it?
[11:56:26] <kshishkov> no socket for such CPU
[11:57:06] <kshishkov> also quite probably all my CPUs are soldered to MB
[11:57:25] <superdump> maybe i inferred wrongly but i assumed twnqx upgraded the motherboard/cpu/ram and just kept other stuff + case
[11:58:07] <twnqx> yeah
[11:58:16] <twnqx> gfx too :P
[11:58:26] <twnqx> got a gf 4400 with it
[11:58:36] <pross-au> kshishkov: do you have a desoldering station
[11:58:37] <twnqx> i have WAY to many obsolete comps
[11:58:49] <kshishkov> pross-au: unlikely
[11:58:58] <pross-au> yeah i hate SMT too
[11:59:03] <kshishkov> twnqx: looks like it's 100% for me
[11:59:15] <twnqx> as long as it's not BGA i'll solder it :P
[11:59:42] <jai> twnqx: you still run on agp? :)
[11:59:46] <twnqx> no
[11:59:52] <twnqx> it was my dad's PC
[11:59:56] <jai> k
[12:01:32] <twnqx> i've thrown a q6600 that was around in the cas e:P
[12:01:44] <twnqx> i'm on i7 myself
[12:01:59] <twnqx> and i traded an ipod for my dad's core 2 duo :P
[12:02:21] <twnqx> now mom needs a new comp...
[12:02:49] <twnqx> i wonder if i should get her an atom... for reading mail, surfing and keeping track of her dvd colelction
[12:03:04] <astrange> don't inflict atom on people
[12:03:08] <astrange> amd is affordable
[12:03:25] <twnqx> but atoms come in cute packaging
[12:03:26] <twnqx> :(
[12:03:27] <jai> for the listed use cases, atom should be fine right
[12:03:33] <twnqx> ell, there's youtube :X
[12:04:01] <kshishkov> twnqx: in my case it was shitty packaging, it went to a dump in less than a year of service
[12:04:09] <twnqx> :(
[12:04:37] <twnqx> i have an acer revo... but only because of the ion. i use it to watch movies only...
[12:05:23] * kshishkov is not going to touch Acer again
[12:05:31] <twnqx> heh
[12:05:34] <thresh> yeah
[12:05:39] * thresh wants thinkpad with ion
[12:05:43] <twnqx> i modded mine.
[12:05:53] <kshishkov> I dumped mine
[12:05:57] <roozhou> is it ok to run AMD X2 215 + 780G w/o fans?
[12:05:57] <twnqx> replaced the microphone in with an spdif out :P
[12:07:00] <twnqx> i still want something in the same booksize form factor with a tegra 250
[12:07:24] <twnqx> friend of mine told me that the tegra 250 devel board is horribly broken, though
[12:07:50] <thresh> i thought mru had one
[12:08:35] <twnqx> he's working on Volkswagen/Audi next generation entertainment system
[12:08:47] <mru> I do have one
[12:09:02] <twnqx> lots of bugs? on the board, not the chip?
[12:09:35] <mru> haven't played with it much
[12:10:00] <twnqx> do you know what's required to get board development specs?
[12:10:47] <mru> kernel flashed in fixed location and nda tools needed to replace it
[12:11:12] <mru> even boot args hardcoded there
[12:11:34] <kshishkov> it's a task for quantum butterfly then
[12:29:09] <twnqx> no, i meant... build an own board :X
[12:29:39] <twnqx> pinouts, sample components/BOM/schematic/board details, timing details, etc
[12:30:49] * twnqx looks at some sample board for interfacing a xilinx spartan 6 fpga to pci express... some interesting details
[12:31:14] <twnqx> but i wonder if 300mW for a pci express jitter compensator isn't a bit on the high side
[12:37:41] <KotH> prolly not
[12:37:52] <KotH> you're dealing with 2.5Gbit/s per lane
[12:38:28] <KotH> but, what the heck is a jitter compensator?
[12:43:19] <superdump> does anyone in the uk want to buy an i7 off me? i'm not really using it as i'm moving to sweden so it makes little sense to keep it
[12:43:29] <ramiro> superdump: when are you moving?
[12:43:40] <superdump> probably when i go back in a week or so
[12:44:03] <superdump> thought i had an apartment sorted but they decided to sell it instead so looking for another one
[12:46:07] <twnqx> KotH: it dies case it retiems the clock lanes
[12:46:12] <twnqx> in this case*
[12:46:27] <twnqx> to about 5ps precision
[12:47:23] <twnqx> hm
[12:50:25] <KotH> twnqx: teh clock lanes?
[12:50:33] <KotH> twnqx: each clock lane individualy?
[12:50:45] <KotH> twnqx: what chip is taht?
[12:50:48] <twnqx> there's only one differential clock in PCIe
[12:51:04] <twnqx> so, two signals
[12:51:11] <KotH> hmm? i thought there is one clock per lane?
[12:51:23] <KotH> or am i mistaken?
[12:51:37] <twnqx> i'm looking at a x1 design at the moment, so i'm not sure
[12:51:44] <twnqx> but i thought there's only one clock
[12:52:00] <twnqx> ICS874001 is the chip if you care :P
[12:52:43] <twnqx> http://pinouts.ru/Slots/pci_express_pinout.shtml shows only one clock pair, even for more lanes
[12:52:47] <KotH> maybe i'm just confusing things
[12:54:36] <twnqx> oh, and it's 50ps...
[12:55:27] <KotH> blub.. my fault
[12:55:35] <KotH> each lane is self-clocked
[12:55:47] <KotH> ie clock is recovered from the bitstream
[12:56:30] <KotH> and the "jitter compensator" is nothing more than a stable vco with a pll with a 1:1 ratio
[12:59:42] <_av500_> &win 4
[12:59:45] <_av500_> oops
[13:00:05] <twnqx> adjustable ratio, but yeah
[13:00:13] <twnqx> i just wonder if it's necessary
[13:05:56] <KotH> no idea
[13:06:08] <KotH> i know virtually nothing about pci-e
[13:07:20] <twnqx> i want to build an add-in card :]
[13:08:11] <twnqx> i just fear that it will require 6 layers minimum
[13:09:02] <av500> twnqx: 6 sounds reasonable
[13:09:58] <twnqx> i wonder if the "better" PCB software is available as a trial...
[13:10:14] <twnqx> eagle is pretty nice, but can't to impedance/length control
[13:11:12] <twnqx> and for PCIe i want something with an embedded field solver :X
[13:12:17] <KotH> rotfl
[13:12:26] <av500> twnqx: getting the impedance from lenght, width, etc should be possible, no?
[13:12:27] <KotH> hint: dont even try eagle
[13:12:43] <KotH> you'll fail with anything over 2 layers
[13:12:50] <KotH> and even two layers is a pain
[13:12:51] <twnqx> KotH: i own the pro version without autorouter
[13:13:06] <KotH> does the pro version do proper DRC check?
[13:13:08] <twnqx> 4 layers is ok, as long as it's two supply layers
[13:13:15] <KotH> ^^'
[13:13:22] <KotH> forget that with pci-e
[13:13:26] <twnqx> yeah :P
[13:13:33] <KotH> you'll need impedance matched lines
[13:13:36] <twnqx> and 324pin chipscale BGA packages, and ddr2/ddr3
[13:13:44] <KotH> best to have them within two ground planes
[13:13:54] <KotH> o_0
[13:14:05] <KotH> ok, we're talking of at least 6 layers
[13:14:29] <twnqx> yeah, possibly (likely?) 8
[13:14:44] <KotH> OGD1 is 12 layers iirc
[13:14:47] <twnqx> but i have no idea how to fit an fpga + some memory onto a mini-pcie card
[13:14:59] <KotH> though it has a 800pin bga
[13:14:59] <twnqx> with "normal size" components
[13:15:19] <KotH> what's normal size for you?
[13:15:29] <twnqx> tqfp, tssop, vqfp...
[13:15:31] <funman> hello
[13:16:24] <av500> twnqx: forget it
[13:16:26] <av500> bga
[13:16:50] * KotH thinks the same
[13:17:01] <KotH> though 1mm pitch bga should be pretty much painless
[13:17:08] <jai> hello to you too funman
[13:17:14] <KotH> 0.8mm is a bit more..challenging
[13:17:21] <funman> i am looking at issue1503 and i'm wondering who did reverse engineering of wma: i suppose Fabrice Bellard as he's the initial commiter of this code
[13:17:28] <twnqx> http://img62.imageshack.us/img62/602/img0312mo.jpg the level shifters (on the pcb) were pain to solder :P
[13:18:00] <av500> these are easy
[13:18:14] <twnqx> that was my first smd project :X
[13:18:14] <av500> given a good solder mask
[13:18:28] <av500> good solder mask is the key
[13:18:29] <funman> google & wiki.multimedia.cx didn't give me any docs about reverse engineering so i assume the decoder he wrote is the only source of documentation
[13:18:31] <twnqx> and the vendor had issues with 0.15mm solder mask width
[13:19:08] <av500> ideally, the solder mask leaves holes on the pad where the part more or less fall into place
[13:19:14] <KotH> twnqx: 1.27mm pitch ?
[13:19:21] <twnqx> 0.4mm pitch
[13:19:27] <KotH> o_0
[13:19:43] <KotH> what kind of level shifter are these, to use such an odd pitch?
[13:19:56] <av500> 16245 or so I guess
[13:20:30] <twnqx> sn74cbt3t16210
[13:20:43] <twnqx> sn74cb3t16210
[13:21:31] <av500> ah, 20bit
[13:21:43] <twnqx> yeah
[13:24:41] <KotH> those have 0.5mm pitch :)
[13:24:49] <twnqx> and regarding eagle's DRC... with the setting i had to use it flooded the space below 0603 components with the ground plane
[13:25:08] <KotH> unless you used teh tvsop ;)
[13:25:13] <twnqx> i did
[13:25:19] <KotH> masochist
[13:25:27] <twnqx> no, i was running out of space
[13:25:50] <av500> there would have been space for 0.5
[13:26:23] <twnqx> if i traded on other edges, e.g. move the fpga further out (or allow other than 45° angles
[13:26:30] <av500> but anyway, as you managed to solder it, you can now call 0.4 HUGE and move on ;)
[13:26:42] <KotH> hehe
[13:26:55] * KotH would have used a layer more
[13:27:09] <twnqx> after doing that... i soldered the 1.27mm components
[13:27:14] <twnqx> and they really felt HUGE
[13:27:46] <twnqx> KotH: 25pcbs of that were already 200€
[13:27:47] <av500> yeah, feels like pouring concete :)
[13:28:09] <twnqx> in 4 layers it would have been more, and i actually need 5-6
[13:28:09] <KotH> twnqx: i know how much pcb's cost
[13:28:15] <twnqx> and it's a damn hobby
[13:28:18] * KotH does that kind of stuff for a living
[13:28:22] <twnqx> oh
[13:28:40] <twnqx> i mean, i'd have loved to use 4 layers, would have made power/ground routing easier
[13:28:49] <twnqx> especially power.
[13:28:53] <KotH> yeah, but it doubles the cost
[13:29:04] <twnqx> indeed
[13:29:14] <twnqx> and apparently it works (for now)
[13:29:36] <twnqx> even though i'd change a LOT
[13:29:55] <twnqx> didn't consider that it's almost impossible to find non-pcb versions of the 1.27mm headers..
[13:30:07] <KotH> hint: if you ddr, stick with ddr, dont use ddr3. and use someone else design as an example for both schematic and layout
[13:30:34] <twnqx> i'd have to use ddr2
[13:30:46] <KotH> do you have such a datarate?
[13:30:48] <twnqx> but yeah, i have xilinx' reference board
[13:31:03] <twnqx> no, but spartan 6 features embedded memory controlles - that support ddr2 or 3
[13:31:48] <KotH> they support ddr too, i'd say
[13:32:13] <KotH> the lower the clock rate you've to support, the uglier your layout can be
[13:32:35] <twnqx> oh you're right
[13:32:41] <twnqx> they do.
[13:32:59] <KotH> and believe me, having high peak current components like sdram or an fpga is pain enough, no need to make it worse
[13:33:32] <twnqx> what do you use, mentor graphics?
[13:34:13] <KotH> altium
[13:34:16] <twnqx> ah
[13:34:30] <KotH> mentor graphics is a lot more expensive, with minimal advantage for us
[13:35:13] <twnqx> i wanted to look at altium for the fpga codesign options
[13:35:46] <twnqx> so far i use the ugly ISE for that part... but at least that's free
[13:36:12] * KotH has never used the co-design stuff
[13:36:24] * KotH doesnt think that it can beat hard thinking
[13:37:48] <twnqx> i'd like to have some... better options for generating the verilog code (ok, i'd be willing to learn VHDL if necessary)
[13:38:01] <twnqx> like, a visual staemachine editor
[13:38:59] <KotH> 1) learn vhdl anyways... readability of vhdl is a lot better than verilog
[13:39:21] <KotH> 2) use simulink for the state machine design
[13:39:22] <BBB___> KotH: I asked phill, no reply yet, will get back to you in a couple of hours
[13:39:23] <BBB___> (CMS)
[13:39:29] <KotH> BBB___: ack
[13:39:29] <BBB___> oh my nick is screwed up
[13:39:34] <KotH> BBB___: that too
[13:39:36] <KotH> ;)
[13:39:48] <kshishkov> BBB___: only left part of your nick is screwed
[13:40:03] <kshishkov> can't confuse three underscores with movie name
[13:40:18] <av500> B_ig B_uck B_unny
[13:42:11] <jai> thats a long tail
[13:43:18] <BBB___> the others are taken, it seems
[13:44:05] <BBB> shit I keep doing that
[13:44:14] <BBB> this irc app has confusing keybindings
[13:45:26] <jai> which one?
[13:45:38] <jai> just use irssi, and rely on muscle memory
[13:45:48] <twnqx> or fix the bindings
[13:53:44] <mru> one key to rule them all and in the darkness bind them
[13:54:00] * KotH wonders why USB stores the serial number as a UCS-2 string, while only alphanumeric ascii characters are allowed
[13:54:14] <elenril> for the lulz?
[13:54:29] <_troll_> was microsoft on the design committee?
[13:54:38] <elenril> yeah, or that
[13:54:46] <KotH> nope, intel
[13:54:52] <_troll_> difference?
[13:54:58] <KotH> 99% of that stuff is intel only
[13:55:01] <KotH> and you can feel it
[13:55:24] <KotH> the documentation is basically a listing of tables, with hardly a word describing how they are intended to be used
[13:55:41] <KotH> on the other hand, the electrical descriptions are pretty extensive
[14:00:14] <BBB> wbs: is it intended that you use av_gettime() in that patch and not ff_ntp_time()?
[14:00:43] <wbs> BBB: yes, since the field is public and should be reasonably generic, I chose to store it in av_gettime() scale instead
[14:00:43] <_troll_> wtf is "ntp time"?
[14:01:02] <BBB> different zero-point
[14:01:08] <BBB> it's like fahrenheit vs. celsius
[14:01:19] * BBB feels flamewar coming up
[14:02:29] * _troll_ goes to read RFC958
[14:03:59] <CIA-92> ffmpeg: benoit * r22544 /trunk/libavcodec/ (w32thread.c pthread.c avcodec.h os2thread.c beosthread.c):
[14:04:00] <CIA-92> ffmpeg: Remove avcodec_thread_execute from avcodec.h, and make static functions that
[14:04:00] <CIA-92> ffmpeg: need it in *thread.c.
[14:08:01] <KotH> _troll_: basically: couting days and seconds of day since apporx 5ky ago
[14:08:32] <KotH> er.. 4ky
[14:08:37] <_troll_> NTP has epoch 1900-01-01
[14:08:44] <_troll_> you're thinking MJD
[14:10:43] <KotH> hmm.. then i'm confusing it
[14:10:53] <KotH> there are way to many different time formats anyways ^^'
[14:11:15] <_troll_> "NTP timestamps are represented as a 64-bit fixed-point number, in seconds relative to 0000 UT on 1 January 1900."
[14:11:38] <_troll_> that's a 32.32-bit fixed-point
[14:12:34] <KotH> hmm...
[14:12:45] * KotH wonders what UT was used back in 1900
[14:12:58] <BBB> they used handwriting
[14:13:30] <_troll_> does RTP use the same format?
[14:13:41] <_troll_> or are they just waving acronyms around?
[14:13:55] <wbs> they use the same format in RTCP packets, yes
[14:14:23] <_troll_> ok, then it makes sense
[14:14:46] <_troll_> all that talk about "NTP time" made it sound like yet another time reference
[14:14:58] <_troll_> alongside GMT, UTC, UT1, etc, etc
[14:16:27] <kshishkov> _troll_: it sounds more like that RTP implementation should include NTP client, web server and mail forwarder
[14:19:14] <KotH> _troll_: is ntp time leap second corrected? or is it strict monotonic?
[14:19:33] <_troll_> it can signal leap seconds
[14:19:38] <_troll_> it doesn't specify a time reference
[14:20:10] <_troll_> ntp is nothing but a synchronisation protocol
[14:20:35] <_troll_> it doesn't care about the actual reading
[14:20:56] <CIA-92> ffmpeg: mstorsjo * r22545 /trunk/libavformat/ (rtsp.c rtsp.h):
[14:20:56] <CIA-92> ffmpeg: RTSP: Synchronize the start time of the chained RTP muxers
[14:20:56] <CIA-92> ffmpeg: This makes sure that the streams get correctly synchronized when viewed,
[14:20:56] <CIA-92> ffmpeg: previously the streams were out of sync by as much time as it took
[14:20:56] <CIA-92> ffmpeg: between the initialization of the individual muxers.
[14:21:44] <wbs> BBB: thanks for the review - that was the last one of the critical missing features :-)
[14:22:18] <BBB> cool :)
[14:22:31] <BBB> now we need to get all these rtp depacketizers that I and others wrote a while ago in
[14:22:34] <BBB> interested? :)
[14:22:51] <wbs> nah, I have a bunch of non-critical additional features written, just ready to be polished up and included ;P
[14:23:16] <wbs> after that, maybe :-)
[14:23:43] * BBB awaits :)
[14:23:55] <wbs> in particular; TCP support for the RTSP muxer, and digest authentication support (for both http and rtsp)
[14:24:32] <wbs> the tcp support is quite simple and not too ugly, I think I'll post that one next
[14:25:40] <kierank> Does anybody possess an AVCHD spec?
[14:26:13] <wbs> digest auth support is a bit more messy though, but principally I think it should be ok...
[14:26:13] <_troll_> I'm still struggling to figure out what avchd _is_
[14:26:25] <_troll_> apart from a trademark for a certain line of digital camcorders
[14:26:33] <kierank> Blu-ray for home movies
[14:27:40] <kierank> but only with h.264 and ac3 or lpcm
[14:27:40] <kshishkov> botched container or H.264?
[14:28:27] <kierank> It's a normal TS with a 4 byte header like blu-ray
[14:28:59] <_troll_> what's in those extra 4 bytes?
[14:29:08] <_troll_> the files I've seen played fine after stripping it
[14:29:22] <av500> some timestamp, no?
[14:29:34] <_troll_> the TS packets already have timestamps
[14:29:56] <av500> yes, but looks like whoever uses this TS variant cant be bothered to read TS
[14:29:59] <kierank> yes it's 2 copy control bits and a timestamp
[14:30:18] <kierank> but i was mainly looking to see if there were more random H.264 restrictions in avchd like blu-ray
[14:37:56] <BBB> wbs: uh...
[14:38:01] <BBB> wbs: I have code for digest auth
[14:38:05] <BBB> wbs: I should port it into ffmpeg
[14:38:14] <BBB> I wrote it for http but rtsp is identical
[14:38:22] <wbs> yeah, I've got such too, now :-)
[14:38:24] <BBB> it doesn't support msg content check
[14:38:30] <BBB> oh, darnit :)
[14:38:38] <BBB> shall we do a contest who can port it first? i'm 100% sure you'll win
[14:38:56] <wbs> I don't think mine supports msg content check either
[14:39:04] <BBB> that's because that sucks :)
[14:39:10] <wbs> :-)
[14:39:42] <wbs> and yes, it works fine in both http and rtsp, but the integration isn't totally clear, so I expect a few comments during the review :-)
[14:40:02] <BBB> oh so you ported it already?
[14:40:04] <BBB> cool
[14:40:07] <BBB> saves me having to do it
[14:40:17] <wbs> the need arose from rtsp (since password protection is much more common when sending stuff than when watching it) - cleartext password is so 1980s
[14:40:27] <BBB> well yeah
[14:40:31] <BBB> but someone gave us a patch
[14:42:46] <wbs> anyway, I'll post it sometimes soonish
[14:43:41] <BBB> cool
[15:00:39] <merbzt> janneg: I think I have a core 2 duo free for some rendering work if it is easy to set up the rendering jobs
[15:00:52] <merbzt> and how much memory is needed
[15:02:45] <av500> >4GB
[15:02:47] <av500> 6 or (
[15:02:48] <av500> 6 or 8
[15:04:03] <BBB> KotH: drupal please
[15:06:25] <BBB> (and thanks!)
[15:09:01] <merbzt> av500: >4GB to render the pictures ?
[15:09:16] <merbzt> wont 4 do it
[15:09:30] <merbzt> that's the max I can use in the box
[15:14:12] <janneg> merbzt: I would guess 50% of the frames get OOM killed with 4G + 500M swap
[15:14:59] <twnqx> Oo
[15:15:06] <twnqx> what...are you rendering?
[15:15:20] <mru> bunnies
[15:15:23] <janneg> Big Buck Bunny in 2700x1440
[15:15:35] <merbzt> janneg: :/
[15:17:18] <twnqx> ok, if it was something else i'd have chipped in :P
[15:17:38] <janneg> merbzt: but as long as there are frames which render with 4G it's useful. the script which creates the job files takes existing pictures into account
[15:18:20] <merbzt> hmmm, ok, I'll see if I can get the box working with 4 gig then
[15:18:47] <janneg> i.e. it makes sense to run a job file with 4G machine, regenerate the job and render the other frames on a machine with more RAM
[15:19:20] <janneg> mru tried that but his quad core died
[15:19:42] <mru> I'll try to revive it
[15:20:38] <janneg> merbzt: instructions are here http://www.jannau.net/bbb_videowall/, ask if something is not clear
[15:21:07] <merbzt> ok, thnx
[15:22:31] <BBB> merbzt: did you talk to that guy that wanted to RE WVP2?
[15:22:59] <merbzt> yes
[15:23:18] <BBB> what happened to the wiki page?
[15:23:27] <BBB> there used to be a wiki page that you showed me, I can't find it anymore :)
[15:23:33] <BBB> (how to get started with RE)
[15:23:49] <merbzt> I have no idea what you talk about
[15:24:23] <merbzt> elaborate
[15:24:34] <BBB> I remember there being a page on how to load self-written code at runtime into a binary dll
[15:24:43] <BBB> to replace functions one-by-one with self-written instructions
[15:25:08] <BBB> it was like a simple howto for beginners
[15:25:22] <merbzt> well I don't remember a wiki page about it
[15:25:40] <merbzt> dig ein your logs
[15:25:58] <jai> code injection?
[15:26:36] <BBB> hm, ok..
[15:26:39] <BBB> jai: yes
[15:27:27] <janneg> skype has submitted silk to ietf:
[15:27:31] <janneg> http://tools.ietf.org/html/draft-vos-silk-01
[15:28:36] <BBB> that's useful
[15:28:39] <janneg> and they have source code under a gpl incompatible license
[15:28:55] <janneg> https://developer.skype.com/silk
[15:29:21] <av500> where is the fun in that :)
[15:29:51] <KotH> BBB: could you please send a mail to -legal, then it's proberly archived :)
[15:29:58] <mru> whoever takes up that job offer gets access to all the secrets...
[15:30:14] <KotH> BBB: i'll install it as soon as i have some free time (prolly this weekend)
[15:30:15] <merbzt> janneg: do you know the owl is rendered incorrectly ?
[15:30:22] <av500> merbzt: yes
[15:31:16] <av500> janneg: oops, I read "compatible" :)
[15:31:31] <KotH> merbzt: the source files are horribly broken
[15:33:02] <janneg> av500: finding bugs in the spec/skype's implementation
[15:33:39] <merbzt> so broken it's not possible to rerender the movie ?
[15:33:49] <BBB> KotH: thanks
[15:33:57] <andoma> seems libnut was around already in 1993: http://github.com/alandipert/ncsa-mosaic/tree/master/libnut/
[15:34:15] <janneg> KotH: have you seen that blender occasionally tries to open a sound device
[15:35:28] <janneg> merbzt: yes, I haven't filled a bug yet. but if BBB was gpl licensed I would say they failed to publish the corrosponding sources
[15:35:32] <KotH> janneg: nope.. i dont care... there is no sound device :)
[15:37:43] <janneg> neither do I care, but it's strange. why would blender need sound device for rendering?
[15:38:10] <KotH> offloading of some calculations? :)
[15:38:27] <kshishkov> rendering 3D sound as well?
[15:38:36] <janneg> av500: the fun is finding bugs in the spec
[15:39:29] <av500> janneg: outputting "I need more memoryyyyy" over the sound dev?
[15:40:40] <kshishkov> janneg: reminds me of ideal patent description formula - "describe everything clearly without giving away a way to implement it"
[15:41:13] <av500> kshishkov: then nobody can infringe....
[15:41:20] <pengvado> clearly?
[15:41:51] <KotH> kshishkov: the ideal patent is as broad as possible, so that as many technologies are covered by it
[15:42:00] <KotH> kshishkov: hence, detailed descriptions are contraproductive
[15:42:46] <kshishkov> but it makes it easier to be disputed
[15:43:07] <DonDiego> hi
[15:43:14] <DonDiego> Yuvi: i stumbled across more theora testsuite samples
[15:43:17] <kshishkov> hej
[15:43:20] <DonDiego> http://wiki.xiph.org/TheoraTestsuite
[15:43:48] <DonDiego> i added the missing ones to our samples repo:
[15:43:50] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/
[15:44:01] <DonDiego> new samples:
[15:44:03] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/ducks_take_off_444_720p25.ogg
[15:44:15] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/offset_test.ogv
[15:44:21] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/sign_irene_cif-3qi-b.ogg
[15:44:28] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/stockholm-vfr.ogg
[15:44:46] <DonDiego> i haven't tested the samples yet
[15:44:49] <av500> looks like the duck need to be better encoded with wavelets....
[15:45:19] <DonDiego> av500: can you play the samples?
[15:45:28] <av500> yes, my webbrowser plays them
[15:45:47] <kshishkov> av500: don't mention that d-word. Don't you know that On2 was originally called D*ck Corporation back in VP3 times?
[15:47:48] <av500> duck duck duck
[15:47:52] <kshishkov> ni!
[15:48:54] <pJok> thee kshishkov who formerly said ni!
[15:49:08] * mru demands a shrubbery
[15:49:35] <kshishkov> pJok: yes, I've heard that since 1967 you say "du" instead of "ni"
[15:49:54] <mru> no wonder their codecs are quack
[15:50:06] <kshishkov> mru: cut the highest tree in the forest with this herring first
[16:02:46] <DonDiego> bbl, cu
[16:16:40] <CIA-92> ffmpeg: mstorsjo * r22546 /trunk/libavformat/rtsp.c: Reindent
[16:32:06] <CIA-92> ffmpeg: mstorsjo * r22547 /trunk/libavformat/ (rtsp.c rtsp.h): Make rtsp_skip_packet non-static, add ff prefix
[16:37:10] <CIA-92> ffmpeg: mstorsjo * r22548 /trunk/libavformat/rtspenc.c:
[16:37:10] <CIA-92> ffmpeg: Don't let ff_rtsp_read_reply skip interleaved RTP/TCP packets in rtsp_write_packet.
[16:37:10] <CIA-92> ffmpeg: Skip interleaved packets manually and recheck if there's more to be read.
[16:37:44] <CIA-92> ffmpeg: mstorsjo * r22549 /trunk/libavformat/rtspenc.c: Reindent
[16:37:46] <CIA-92> ffmpeg: michael * r22550 /trunk/ (7 files in 6 dirs):
[16:37:46] <CIA-92> ffmpeg: use mpeg2 quantization bias for mjpeg.
[16:37:46] <CIA-92> ffmpeg: this seems to improve RD performance.
[18:23:24] <BBB> MrNaz: ping
[19:04:43] <CIA-92> ffmpeg: jai_menon * r22551 /trunk/libavformat/matroskaenc.c: cosmetics : Print newline after error message.
[19:11:51] <jai> great, i can commit again :)
[19:26:13] <CIA-92> ffmpeg: mru * r22552 /trunk/ (353 files in 4 dirs): (log message trimmed)
[19:26:13] <CIA-92> ffmpeg: Add FATE tests
[19:26:13] <CIA-92> ffmpeg: This adds a "fate" make target which runs the full FATE test suite.
[19:26:13] <CIA-92> ffmpeg: Individual tests can be run with "make fate-$testname".
[19:26:13] <CIA-92> ffmpeg: The location of the FATE test samples must be specified with the
[19:26:14] <CIA-92> ffmpeg: --samples=PATH option to configure.
[19:26:15] <CIA-92> ffmpeg: The tests/fate-update.sh script regenerates the references files and
[19:29:39] <mru> do I get the prize for most files in a single commit?
[19:30:15] <kshishkov> yes if you manage to pry it from Diego's hands
[19:30:52] * av500 goes off to buy new hdd....
[19:31:53] <jai> mru: any idea by how much does this increases the repo size ?
[19:32:10] <jai> -s
[19:32:39] <mru> git, not noticably
[19:34:10] <mru> the samples are not checked in for obvious reasons
[19:34:27] <av500> they could not be zipped? :)
[19:34:56] <kshishkov> they are at MPHQ already
[19:35:26] <mru> the reference files are 800k total
[19:35:35] <mru> that's nothing compared to the tens of MB of code
[19:36:22] <drv> my local SVN checkout du on ext3 grew about 4 MB, and that includes some other commits
[19:36:34] <mru> that's svn power for you
[19:36:52] <mru> new slogan for them: svn makes everything look big
[19:37:07] <kshishkov> heh
[19:37:07] <drv> warning: objects in svn may be larger than they appear
[19:37:16] <mru> drv: lol
[19:37:26] <kshishkov> iceberg for SVN logo!
[19:37:34] <mru> drv: people who haven't been to the US may not understand that one
[19:37:58] <kshishkov> is that about rear view mirror warning?
[19:38:00] <drv> hehe, true, i guess that's not on mirrors everywhere
[19:38:11] <mru> haven't seen it in europe
[19:38:24] <drv> actually i don't even know if it's on my car, i should go check sometime
[19:38:25] <kshishkov> less idiots?
[19:38:34] <drv> less idiots with access to lawyers perhaps
[19:38:35] <mru> well, at least it's not known to the government of the state of california to contain lead
[19:39:05] <ramiro> svn export from 22551: 40968, 22552: 44808
[19:39:22] <ramiro> in bz2, from 6416 to 6848
[19:39:27] <ohsix> haha :( https://bugzilla.gnome.org/show_bug.cgi?id=612773
[19:39:36] <mru> ramiro: does that include filesystem overhead?
[19:39:45] <ramiro> mru: using du, so yes.
[19:39:52] <mru> 350 tiny files might take some space
[19:39:56] <jai> ramiro: thx :)
[19:40:16] <drv> i should try moving my /home to ext4 sometime
[19:40:37] <pJok> drv, isn't it just a matter of mounting it as ext4?
[19:40:52] <mru> no
[19:40:57] <mru> ext4 is not compatible at all
[19:40:58] <drv> well, you need to run a fsck to get it to enable the new features i think
[19:40:59] <jai> i wanted to try out btrfs for /tmp
[19:41:18] * mru uses tmpfs for /tmp
[19:42:00] <kshishkov> fat12 anyone?
[19:42:21] <jai> mru: low ram :|
[19:42:33] <ramiro> jai: buy some more, it's getting cheap.
[19:42:44] <jai> kshishkov: have some floppies here i think
[19:42:51] <kshishkov> jai: how low ram?
[19:42:58] <jai> kshishkov: 512mb
[19:43:07] <jai> it isnt _that_ low
[19:43:11] <kshishkov> huh? you call that low?
[19:43:15] <mru> I do
[19:43:18] <jai> i knew you would say that
[19:43:20] <mru> anything below 4G is low
[19:43:20] <jai> :)
[19:43:23] <BBB> how do I make the build non-quiet?
[19:43:26] <BBB> I want to see a gcc command
[19:43:28] <mru> make V=1
[19:43:28] <drv> make V=1
[19:43:29] <jai> BBB: V=2
[19:43:30] <BBB> thanks
[19:43:32] <jai> hmm
[19:43:44] <jai> so what happens with V=2?
[19:43:44] <mru> V=2 makes make test even noisier
[19:43:48] <drv> jai's make is one louder ;)
[19:43:56] <mru> make V=11
[19:43:57] <jai> drv: linear scale i see :)
[19:44:07] <kshishkov> only because of loud HDD
[19:46:53] <CIA-92> ffmpeg: michael * r22553 /trunk/ffmpeg.c: Allow mpeg style yuv in jpeg when strict standard compliance is small enough.
[20:42:04] <gmaxwell> Yo. I don't know if yuvi has replaced the ffmpeg oggmux in some branch of his yet, but the code in your current git is completely busted for packets which are a multiple of 65025 bytes.  It fails to terminate the packets... only creating a segment free continuation page.
[20:42:19] <gmaxwell> I'll happily send a patch if this code hasn't been trashed yet, but I sure hope it has.
[20:42:36] <Dark_Shikari> 65025 bytes? that must be an odd bug
[20:42:50] <gmaxwell> This is an example file produced by making libtheora always output that size: http://myrandomnode.dyndns.org:8080/~gmaxwell/fffail.ogv
[20:43:01] <Dark_Shikari> I don't think Yuvi has replaced it yet, but I may not have been watching carefully enough
[20:43:17] <Dark_Shikari> he seems to mostly be fixing security holes and optimizing the theora decoder
[20:43:21] <Dark_Shikari> (which is now faster than libtheora, yay)
[20:43:27] <gmaxwell> The issue is the if(size) check and page_segments computation in ogg_write_page.  It's a trivial fix— someone went out of their way to do it wrong here. :)
[20:44:14] <gmaxwell> In any case, yuvi is usually around in #theora, so I presume I'll hear from him if he wants a patch.
[20:44:35] <gmaxwell> TTYL!
[20:45:59] <gmaxwell> Oh, and thats fantastic news that the decoder is now fast.
[20:47:56] <Compn> current git you say...
[21:28:05] <CIA-92> ffmpeg: michael * r22554 /trunk/libavcodec/ (mpegvideo.h mpegvideo_enc.c mpeg12decdata.h mpegvideo.c): Support intra_dc_precision>8 in jpeg
[21:53:29] <BBB> merbzt: why does the atrac1 decoder clip to 32700/32768? and will you kill me if I chagne that to -1/1?
[21:54:19] <mru> it will kill performance for sure
[21:54:34] <mru> and you can't just go and change the clip
[21:54:38] <mru> you have to change the scaling too
[21:54:44] * mru states the obvious
[21:56:38] <BBB> it clips to -0.998
[21:56:42] <BBB> I want it to clip to -1
[21:56:45] <BBB> I don't see a problem
[21:57:06] <BBB> I'm just asking if that's what the binary does, or something else
[21:57:36] <BBB> scaling doesn't change
[21:58:23] <pengvado> even if that's what the binary does (or the standard for formats that have a standard), it's almost certainly the wrong thing to do. if the output format were float, then you shouldn't clip at all.
[21:59:49] <BBB> hmm....
[21:59:56] * BBB re-reads MN msg
[22:00:12] <BBB> oh right, he actually says that
[22:01:54] <mru> I somehow read that as clipping to ~32k, not ~1
[22:01:58] <mru> forget what I said
[22:14:01] <BBB> pengvado: you're correct, I'm removing it as we spea
[22:14:03] <BBB> +k
[22:14:43] <mru> here's a good example of why gcc intrinsics suck: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
[22:33:41] <ramiro> BBB: you will apply it 3 days ago? =)
[22:33:50] <BBB> did I really say that?
[22:33:58] <BBB> I'll just assume nobody read that :)
[22:34:08] <ramiro> you said "+/- 3 days"
[22:34:12] <ramiro> it could be -3 days...
[22:35:47] <BBB> oh
[22:35:51] <BBB> well that's not so bad
[22:36:02] <BBB> +/-, in dutch, means "approx." :)
[22:37:37] <ramiro> hmm, we usually use ~ for approx.
[22:37:58] <thresh> we use '+/-' like that too
[22:38:03] <CIA-92> ffmpeg: aurel * r22555 /trunk/libavformat/Makefile: matroskadec: fix missing dependency
[22:38:42] <hyc> I'm surprised folks are still playing with atrac1
[22:39:33] <hyc> I worked on reversing that codec back in 1998-99
[22:40:13] <hyc> still have my SCSI MD-Data drive with hacked firmware to read audio tracks
[22:42:31] <BBB> hyc: ?
[22:42:50] <BBB> hyc: it's a minor patch to the decoder, I'm not actively developing it
[22:42:59] <hyc> ah
[22:44:15] * BBB goes gome
[22:50:34] <CIA-92> ffmpeg: michael * r22556 /trunk/libavcodec/ (mpegvideo.h mpegvideo_enc.c mpeg12.c mpegvideo.c): Add ff_ prefix for mpeg2_dc_scale_table.
[22:55:13] <CIA-92> ffmpeg: michael * r22557 /trunk/libavformat/ (aviobuf.c avio.c avio.h):
[22:55:13] <CIA-92> ffmpeg: Add AVSEEK_FORCE flag to indicate that the code should attempt to seek
[22:55:13] <CIA-92> ffmpeg: by any means.
[23:01:43] <CIA-92> ffmpeg: mru * r22558 /trunk/libavcodec/h264.h:
[23:01:43] <CIA-92> ffmpeg: H264: fix signed overflow in constant multiplication
[23:01:43] <CIA-92> ffmpeg: This fixes libavcodec/h264.h:1100: warning: integer overflow in expression
[23:05:06] <CIA-92> ffmpeg: bcoudurier * r22559 /trunk/libavformat/oggenc.c: Correctly write last 0 lacing value when packet size is multiple of 255, patch by Greg Maxwell, gmaxwell at gmail dot com
[23:11:52] <CIA-92> ffmpeg: bcoudurier * r22560 /trunk/libavcodec/Makefile: mpegts muxer now needs mpeg4audio code like adts muxer
[23:14:55] <CIA-92> ffmpeg: aurel * r22561 /trunk/libavformat/ (mpegts.c utils.c internal.h):
[23:14:55] <CIA-92> ffmpeg: rename av_program_add_stream_index to ff_program_add_stream_index
[23:14:55] <CIA-92> ffmpeg: it is an internal function, not part of public API
[23:16:22] <CIA-92> ffmpeg: aurel * r22562 /trunk/libavformat/ (seek.c utils.c internal.h):
[23:16:22] <CIA-92> ffmpeg: rename av_read_frame_flush to ff_read_frame_flush
[23:16:22] <CIA-92> ffmpeg: it is an internal function, not part of public API
[23:33:29] <CIA-92> ffmpeg: daniel * r22563 /trunk/tools/patcheck: patcheck: Escape parentheses in grep calls
[23:41:41] <CIA-92> ffmpeg: bcoudurier * r22564 /trunk/libavcodec/Makefile: 100L, revert r22560, already present
[23:50:36] <mika_video> Why are the existing fields in essential structs of libavcodec and libavformat sometimes reordered ?
[23:55:34] <mru> ???
[23:55:49] <Dark_Shikari> mru: he hasn't made any sense in any channel for days...
[23:56:52] <mika_video> there was binary incompatible changes between versions  version 52.0.0, and  version 52.52.55.0 of avcodec
[23:57:23] <mika_video> the codex_type field of struct AVCodecContext has moved from offset 0xE0 to offset 0xdc
[23:59:27] <mika_video> the newer of those two should be 52.55.0 , sorry the typo.