[FFmpeg-devel-irc] IRC log for 2010-06-05

[irc at mansr.com]

[00:09:35] <mru> I can't believe you guys don't have proper cross-compilers
[00:10:07] <hyc> most stuff I need to build has a bitbake recipe
[00:10:35] <hyc> and I always forget the paths to the cross tools, the includes, and libs. oh well.
[00:10:51] <hyc> could just write a script for that I guess.
[00:11:02] <hyc> a fake pkg-config pkg ;)
[00:13:35] <hyc> ok, cross compiled binary, stock
[00:13:57] <hyc> ~5.9s, ~27fps
[00:14:03] <mru> with neon?
[00:14:03] <hyc> (with neon this time)
[00:17:30] <hyc> with patch, ~5.3s, ~30fps
[00:18:08] <hyc> pretty solid 10% gain
[00:18:55] <hyc> is that the degree of improvement you were expecting to see?
[00:21:15] <hyc> Dark_Shikari: is this what you expected?
[00:25:13] <Dark_Shikari> hyc: no
[00:25:17] <Dark_Shikari> I expected about 40-50%
[00:27:24] <Dark_Shikari> as that's vaguely what we got on the ipad (where I couldn't really bench)
[00:27:55] <Dark_Shikari> I wonder how much time is spent piping to /dev/null.
[00:27:59] <Dark_Shikari> try with -f null maybe?
[00:28:12] <hyc> my cross compiler is gcc 4.3.3 btw
[00:28:22] <Dark_Shikari> and I wonder how much time is spent on ffmpeg startup
[00:30:49] <hyc> ok, using -f null, original neon is ~4.2s, ~40fps
[00:31:06] <hyc> peak of 4.0s, 42fps
[00:31:41] <hyc> patched is ~3s, 55fps
[00:32:18] <Dark_Shikari> much more reasonable.
[00:34:39] <hyc> I guess rawvideo just produces too much data
[00:34:59] <Dark_Shikari> still slower than I expected though.
[00:35:16] <hyc> for a 600MHz CPU? how fast is the iPad?
[00:35:42] <Dark_Shikari> 1ghz
[00:35:57] <Dark_Shikari> on the ipad we're getting 10-20ms per frame in ultra-high-motion for 1024x768
[00:36:09] <Dark_Shikari> that's 800x600 and you're getting 18-20ms per frame
[00:37:49] <hyc> the timings varied a bit from run to run. I can drop down into single-user mode, that ought to producce identical results on each run.
[00:38:09] <astrange> run in a loop 4-5 times and take the minimum
[00:38:19] <hyc> I was reporting avg of 3
[00:38:56] <astrange> minimum is more resistant to outliers than avg (you can be slower than what's possible, you can't really be faster)
[00:38:58] <Dark_Shikari> I can give you a longer sample to test
[00:39:03] <hyc> ok
[00:39:07] <Dark_Shikari> albeit less representative
[00:39:10] <astrange> but if your system is idle they should all be pretty close anyway
[00:39:22] <Dark_Shikari> it's a re-encode of the standard (awful) victoria's secret clip
[00:39:48] <hyc> astrange: true, but avg is more representative of user experience, I think...
[00:44:49] <Dark_Shikari> hyc: same link as before, output2.flv
[00:44:53] <Dark_Shikari> warning: large
[00:44:54] <hyc> hmmm, whatabout Loongson/Godson-3 chip. If you were designing a new general purpose processor, would you start from MIPS?
[00:44:57] <hyc> ok
[00:45:05] <mru> that chip sucks
[00:45:10] <Dark_Shikari> if I were designing a new general purpose CPU, I'd start from ARM
[00:45:16] <Dark_Shikari> MIPS sucks
[00:45:29] <janneg> I get 3.141s unpatched on 600mhz omap3
[00:45:37] <mru> the MIPS ISA doesn't totally suck
[00:45:48] <Dark_Shikari> mru: the forced nops, etc...
[00:45:48] <mru> but current ARM implementations are faster
[00:45:54] <mru> forced nops?
[00:45:57] <Dark_Shikari> with branches
[00:45:59] <Dark_Shikari> that weird thing
[00:46:01] <Dark_Shikari> delay sllots
[00:46:07] <mru> that's normal
[00:46:15] <Dark_Shikari> an ISA that requires you to insert nops?
[00:46:16] <hyc> delay slots are easy to fill
[00:46:25] <mru> you can almost always put something useful there
[00:46:31] <Dark_Shikari> sure, but what's the point?
[00:46:44] <Dark_Shikari> it would not take significant on-chip logic to avoid such a stupid thing
[00:46:49] <Dark_Shikari> ARM does fine without it
[00:46:49] <hyc> you don't need to waste resources on branch preditciotn /trace history
[00:47:01] <Dark_Shikari> hyc: we said "general purpose cpu"
[00:47:05] <Dark_Shikari> not "8-bit microcontroller toy"
[00:47:20] <hyc> DECstation 3100 was a nice machine
[00:47:25] <Dark_Shikari> an ISA designed for a general-purpose CPU should be _suitable_ for chips with powerful branch prediction, OOE, etc
[00:47:37] <Dark_Shikari> ARM probably works fine for this.
[00:48:06] <mru> the delay slot reduces the penalty of mispredicted branches
[00:48:21] <mru> I wouldn't fret over it
[00:48:28] <Dark_Shikari> so does OOE
[00:48:39] <mru> no
[00:49:05] <Dark_Shikari> if there is tons of stuff before a branch that it can calculate independently of the branch
[00:49:10] <Dark_Shikari> and the comparison for the branch comes well before
[00:49:23] <Dark_Shikari> you can design a chip that figures out early which way the branch will go
[00:49:26] <mru> you obviously don't know MIPS
[00:49:28] <Dark_Shikari> (when such a thing is possible)
[00:49:28] <Dark_Shikari> I know
[00:49:29] <Dark_Shikari> Not mips.
[00:49:30] <mru> so please don't talk about it
[00:49:35] <Dark_Shikari> The point is I'm not talking about mips.
[00:49:39] <Dark_Shikari> I'm saying about why not mips.
[00:49:57] <Dark_Shikari> an ISA should not encode limitations of a particular CPU design.
[00:50:12] <mru> well, lol @ x86 then
[00:50:22] <Dark_Shikari> x86 doesn't -- that's the whole point
[00:50:25] <Dark_Shikari> of course, it goes way too far
[00:50:33] <mru> it's impossible to build a small, efficient x86
[00:50:56] <hyc> yeah, I think hiding limitations is for higher levels of abstraction, like C compilers.
[00:51:01] <Dark_Shikari> and it's possible to build a small, efficient ARM
[00:51:12] <hyc> when you want to program in machine code, you should be right on the machine.
[00:51:12] <mru> yes
[00:51:13] <Dark_Shikari> despite ARM being incredibly complex, flexible, and not encoding limitations of the CPU in the instruction set.
[00:51:24] <mru> the arm instruction set is easy to decode
[00:51:50] <mru> and it has enough registers etc that you don't need fancy OOE to get good performance
[00:52:02] <hyc> notice that most of them were in-order up till now ...
[00:52:04] <Dark_Shikari> but -- it extends find to OOE.
[00:52:06] <Dark_Shikari> *fine
[00:52:11] <mru> of course
[00:52:15] <Dark_Shikari> and the instruction set being easy to decode is just common sense
[00:52:23] <mru> modern mips cores are also OOE
[00:52:25] <Dark_Shikari> anyone making a new instruction set designs it sanely nowadays
[00:53:05] <mru> the problem with mips is not the base instruction set
[00:53:16] <Dark_Shikari> doesn't its OS-level stuff suck a lot?
[00:53:22] <Dark_Shikari> i.e. stuff like synchronization instructions, TLB, etc
[00:53:28] <hyc> output2.flv getting 23fps on original neon
[00:53:29] <Dark_Shikari> I recall something like "pure software tlb"
[00:53:33] <hyc> still running ...
[00:53:43] <mru> it relies on software to refill the tlb, yes
[00:53:47] <mru> many cpus have doen that
[00:53:49] <mru> done
[00:53:53] <mru> you can run arm like that if you want
[00:54:00] <Dark_Shikari> mru: here's a question re arm and x86
[00:54:17] <Dark_Shikari> suppose you have a big chip with a billion transistors and you can go design a fast desktop cpu on either x86 or arm
[00:54:33] <mru> you could of course build a mips with hw page table walking
[00:54:39] <mru> just nobody has done it
[00:54:42] <Dark_Shikari> suppose there's a requirement that loads be 3 clocks (from L1) on both, cache sizes be the same on both, multiplies be 3 clocks, basic arithmetic being 1 clock
[00:54:49] <Dark_Shikari> in other words, pretty standard timings for most things
[00:55:01] <mru> 3-clock load is slow
[00:55:10] <Dark_Shikari> latency, I mean
[00:55:15] <mru> yes, that's slow
[00:55:16] <Dark_Shikari> are you saying the cortex has better?
[00:55:22] <mru> 2 clocks from L1
[00:55:26] <Dark_Shikari> Wow, nice.
[00:55:27] <hyc> that's a bit of a straitjacket. you don't need as many transistors for an ARM core, you could throw the extra into cache
[00:55:29] <Dark_Shikari> anyways, let's stick with those numbers
[00:55:35] <Dark_Shikari> Could you get the ARM to run faster clock-wise than the x86?
[00:55:39] <janneg> Dark_Shikari: and 2.25s patched. 21ms / 15 ms per frame unpatched / patched
[00:55:40] <mru> loongson is 4 clocks
[00:55:50] <Dark_Shikari> And if so, roughly what % would you think?
[00:56:01] <Dark_Shikari> And if so, what about it would bottleneck x86 but not ARM?
[00:56:30] <mru> are we talking about a hypothetical new arm design?
[00:56:30] <Dark_Shikari> janneg: now that's more like it, ~40% faster.
[00:56:36] <Dark_Shikari> mru: hypothetical arm and x86
[00:56:39] <Dark_Shikari> both are built as well as possible
[00:56:49] <Dark_Shikari> both are intended to be fast, power-guzzling desktop cpus
[00:56:52] <Dark_Shikari> possibly multicore.
[00:57:00] <mru> then you'd have the same backend execution units of course
[00:57:00] <Dark_Shikari> which could clock higher, and why.
[00:57:09] <hyc> output2.flv took 4m05s, ~21fps on original neon
[00:57:23] <mru> a multiplier is a multiplier...
[00:57:33] <Dark_Shikari> mru: but is the multiplier what bottlenecks it
[00:57:34] <Dark_Shikari> ?
[00:57:37] <Dark_Shikari> instruction decoding ... etc etc
[00:57:40] <hyc> seeing 31fps with patch
[00:57:51] <mru> and an alu is an alu etc
[00:58:02] <mru> throw in as many as you want
[00:58:03] <Dark_Shikari> well, they can clearly make alus faster than what they do today
[00:58:08] <Dark_Shikari> you had the pentium 4 with its 7ghz+ adder
[00:58:30] <mru> but insanely long pipeline
[00:58:37] <Dark_Shikari> that's not related to the adder
[00:58:43] <Dark_Shikari> the adder was 0.5/0.5
[00:58:47] <mru> 7GHz doesn't do you much good when the latency is 10 cycles
[00:58:52] <Dark_Shikari> no, the latency was 0.5 cycles
[00:59:10] <Dark_Shikari> It's the only chip I've ever known to have sub-clock latency on an ALU.
[00:59:24] <mru> because they double-clock some internal paths
[00:59:27] <Dark_Shikari> yes
[00:59:38] <Dark_Shikari> is that something anyone sane does?
[00:59:49] <mru> apparently not
[00:59:53] <Dark_Shikari> lol
[01:00:38] <mru> so anyway, whatever alu, multiplier, whatever is best in an x86 is obviously best in an arm too
[01:00:46] <mru> if the design constraints are otherwise the same
[01:01:15] <Dark_Shikari> so you're saying that if you had a desktop arm, it wouldn't be much better in power or speed -- the only benefit would be the instruction set better-exposing the cpu capabilities
[01:01:19] <Dark_Shikari> and thus getting more speed
[01:01:24] <Dark_Shikari> (e.g. from more registers, free shift, etc)
[01:01:57] <hyc> more speed from simpler/faster decoders
[01:02:07] <mru> instruction decode would of course be simpler
[01:02:19] <hyc> ok, patched run finished in 3m11s 27fps
[01:02:33] <mru> after that stage the ISA is irrelevant
[01:03:19] <mru> the differences become apparent if you impose some constraints
[01:03:32] <mru> try limiting power consumption or die area
[01:03:33] <Dark_Shikari> does increasing # of registers make the instruction processing harder somehow?
[01:03:38] <Dark_Shikari> beyond just more hardware
[01:03:51] <mru> you obviously need a way to address them
[01:04:08] <mru> 16 registers means 4-bit register fields in your opcodes
[01:04:12] <Dark_Shikari> well yes, in the ISA
[01:04:16] <Dark_Shikari> I mean in the actual wiring
[01:04:20] <Dark_Shikari> does it add latency to have more registers?
[01:04:24] <mru> no
[01:04:28] <mru> just more transistors
[01:04:45] <mru> well, not for reasonable sizes at least
[01:05:01] <hyc> also I'm getting a solid 167MB/sec throughput reading from filesystem cache, so that's an upper bound on throughput - memory bandwidth...
[01:05:14] <mru> as long as the register file is a simple, direct-addressed sram the size doesn't matter
[01:05:23] <Dark_Shikari> wow, 167MB/s ?  that is incredibly slow
[01:05:36] <Dark_Shikari> sure it isn't context switches/similar?
[01:05:40] <mru> you should easily get twice that amount
[01:06:19] <hyc> that was dd if=output2.flv of=/dev/null bs/1024k
[01:06:22] <hyc> bs=
[01:16:12] <pengvado> and if the register file is a reorder buffer?
[01:18:52] <Dark_Shikari> heh, if derf is right, this has to be the single dumbest video coding patent I've seen in ages
[01:18:58] <Dark_Shikari> er, gumboot, I mean
[01:19:00] <Dark_Shikari> 09:17 < Gumboot> derf: What was that On2 patent around that area?
[01:19:00] <Dark_Shikari> 09:17 < Dark_Shikari> ...... a patent relating to how you idct?
[01:19:00] <Dark_Shikari> 09:17 < Gumboot> I think they had one on zeroing the buffer and writing to it sparsely.
[01:20:30] <Dark_Shikari> there's one that ffmpeg violates in spades ;)
[01:36:06] * lu_zero is back
[01:54:56] <lu_zero> damn you talked a lot!
[02:47:32] <bcoudurier> Dark_Shikari, what's up with this "derf" you keep talking about, is he your new idol ? ;)
[02:54:50] <hyc> btw, in singleuser mode, patched code does output.flv in 2.78s, 60fps
[02:55:14] <hyc> original neon does 3.6s, 45fps
[03:00:10] <hyc> dd output2.flv to /dev/null gives me 198MB/sec
[03:04:42] <hyc> original neon does output2 in 3m48s, 23fps
[03:14:22] <hyc> patched code does output2.flv in 2m56s, around 30fps
[03:30:25] <Dark_Shikari> bcoudurier: lol
[03:30:35] <Dark_Shikari> hyc: why is singleuser mode that much faster?
[03:30:42] <astrange> bcoudurier: what did you want?
[03:31:06] <hyc> Dark_Shikari: I guess running a full X desktop takes its toll. dunno.
[03:31:14] <saintdev> because all the other stuff isn't running the background
[03:31:58] <hyc> there's plenty of free RAM so the only other thing is contention for CPU
[03:32:10] <hyc> and in single-user mode, that's brouht to a minimum
[03:45:33] <hyc> hm, my native compiled binary is running at a solid 32fps
[03:45:47] <hyc> despite, I believe, both the native and cross compilers being gcc 4.3.3
[03:48:28] <hyc> my git pull on the touchbook must be slightly newer than my svn tree on my laptop
[07:13:17] <elenril> http://lwn.net/Articles/391087/ ?
[07:14:34] <elenril> morning btw
[07:22:32] <_av500_> gm
[07:46:49] <pross-au> so you're covered elenril
[07:49:06] <av500> elenril is writing vp8 in python?
[07:49:49] <pross-au> pftt python that's for amateurs
[07:49:59] <pross-au> real men write their codecs in XSLT
[07:53:41] * elenril should learn to program in sendmail config sometime
[08:02:38] <CIA-92> ffmpeg: diego * r23482 /trunk/ (configure LICENSE): libvpx now has an (L)GPL-compatible license.
[08:14:57] <j0sh_> lu_zero: http://github.com/j0sh/ffmpeg-soc/commits/http-headers
[08:28:27] <lu_zero> nice
[08:29:00] <lu_zero> you might change it's name to be in sync with the rest of libavutil
[08:30:10] <lu_zero> make_headers special cases make me wonder a bit
[08:30:19] <lu_zero> I'll be back in a while
[08:30:27] <lu_zero> nice job =)
[08:31:44] <CIA-92> ffmpeg: siretart * r23483 /branches/0.6/RELEASE:
[08:31:44] <CIA-92> ffmpeg: update RELEASE notes
[08:31:44] <CIA-92> ffmpeg: VP8 license issues seem to have solved, plus include wording suggestion
[08:31:44] <CIA-92> ffmpeg: from discussion on -cvslog
[08:50:30] <j0sh_> lu_zero: yeah, make_headers is kinda ugly
[08:51:31] <j0sh_> im going to bed, will be around later today
[09:14:05] <_av500_> janneg: ping
[09:14:24] <_av500_> new ate is monday evening, sorry driver had change of plans....
[09:14:34] <_av500_> err, eta
[09:31:39] <Dark_Shikari> mru: quick question.  suppose some company wanted 100,000 Cortex A8s with no fancy addons, i.e. not something nearly as fancy as an OMAP
[09:31:51] <Dark_Shikari> what kind of price would they get on one?
[09:32:02] <Dark_Shikari> and from who
[09:32:12] <Dark_Shikari> (I assume TI for example sells neutered versions at lowered prices, etc)
[09:33:29] <_av500_> 20
[09:33:33] <_av500_> 20$
[09:37:10] <janneg> _av500_: no problem as long as it's before tuesday evening
[09:45:40] <_av500_> k
[09:50:30] <twnqx> _av500_: why does nvidia claim 1080p decoding for the tegra 250 if they can't do it? or is it just low-bitrate 1080p, like 1440x1080 progressive from digital tv?
[09:55:44] <mru> twnqx: they're lying bastards, that's why
[09:56:05] <mru> Dark_Shikari: TI sitara
[09:59:02] <Dark_Shikari> mru: what are their prices?  since TI is one of those companies that never lists
[09:59:39] <Dark_Shikari> also, what does "twice the grpahics performance mean" if it's just a cortex?
[10:06:06] <mru> it means it has sgx as an option
[10:06:17] <mru> hence the "AM3715 only"
[10:07:30] <Dark_Shikari> ahhh
[10:07:32] <merbanan> IT chip ?
[10:07:51] <mru> the 3703 doesn't have sgx
[10:07:55] <mru> well, it does, but it's fused off
[10:08:50] <Dark_Shikari> ah yup, there are the prices
[10:08:56] <Dark_Shikari> their DSP selection tool is cool
[10:51:33] <_av500_> so hoe much is it?
[10:52:01] <_av500_> how
[10:55:00] <pJok> morgens _av500_ :)
[11:11:59] <_av500_> gm
[11:28:53] <CIA-92> ffmpeg: stefano * r23484 /trunk/ (libavutil/avutil.h doc/APIchanges):
[11:28:54] <CIA-92> ffmpeg: Bump lavu minor and add APIchanges entry after AV_BASE64_SIZE()
[11:28:54] <CIA-92> ffmpeg: addition.
[12:02:18] <CIA-92> ffmpeg: stefano * r23485 /trunk/ (11 files in 2 dirs):
[12:02:19] <CIA-92> ffmpeg: Move eval.c and eval.h from libavcodec to libavutil, and make the eval
[12:02:19] <CIA-92> ffmpeg: API public.
[12:07:19] <CIA-92> ffmpeg: stefano * r23486 /trunk/doc/APIchanges: Add APIchanges entry after eval API publication.
[13:53:07] <siretart> hyc: 05.06, 12:02 [  27: Archive Administrato] rtmpdump_2.2e-2_i386.changes ACCEPTED
[13:53:15] <siretart> lu_zero: ^^
[13:59:06] <CIA-92> ffmpeg: siretart * r23487 /branches/ (0.6 0.6/configure 0.6/LICENSE):
[13:59:06] <CIA-92> ffmpeg: libvpx now has an (L)GPL-compatible license.
[13:59:06] <CIA-92> ffmpeg: backport r23482 by diego
[15:23:13] <CIA-92> ffmpeg: alexc * r23488 /trunk/libavcodec/ (aac.c aac.h aacsbr.c): aacdec: Rename avccontext to avctx.
[15:28:46] <CIA-92> ffmpeg: alexc * r23489 /trunk/libavcodec/ (aac.c Makefile aacdec.c): Rename aac.c to aacdec.c.
[15:32:48] <CIA-92> ffmpeg: alexc * r23490 /trunk/libavcodec/ (aac.h aacdec.c): aac: Move an initialization macro used only by the decoder out of the header.
[15:37:06] <CIA-92> ffmpeg: alexc * r23491 /trunk/libavcodec/aac.h: Whitespace cosmetics
[16:22:07] <CIA-92> ffmpeg: stefano * r23492 /trunk/doc/ (4 files):
[16:22:07] <CIA-92> ffmpeg: Replace "Fabrice Bellard" with "The FFmpeg developers" as the authors
[16:22:07] <CIA-92> ffmpeg: of the ff* tools man pages.
[16:49:28] <ramiro_> hyc: are there any main differences in speed/functionality for the different ssl libraries librtmp supports?
[16:51:27] <ramiro_> it seems kind of ridiculous to me that openssl is gpl-incompatible because it asks for recognition in advertising material...
[17:01:23] <hyc> oramiro_: I haven't benchmarked them, no idea about speed.
[17:01:41] <hyc> gnutls is generally buggy/broken at any given time
[17:02:25] <hyc> polarssl has the smallest footprint
[17:04:53] <iive> hyc: what kind of bugs?
[17:05:23] <hyc> certificate parsing, un-terminated strings, various crap
[17:05:40] <hyc> certificate chain verification...
[17:05:50] <hyc> they mostly get fixed sooner or later
[17:06:07] <hyc> but there are also some design flaws that won't get fixed without a new API
[17:07:00] <hyc> e.g. this https://bugs.launchpad.net/bugs/305264
[17:08:38] <hyc> and https://bugs.launchpad.net/bugs/423252
[17:08:49] * iive checks
[17:15:05] <j0sh_> wbs: im thinking about michael's comments. if we stayed with a flat string approach, we'd lose the ability to seek if we set custom headers
[17:15:51] <j0sh_> short of calling ff_set_headers with a new Range before every url_seek
[17:16:39] <iive> hyc:  it's way too long... but the length of the threads is remarkable.
[17:17:10] <wbs> j0sh_: I don't think users of custom urls need to seek actually
[17:19:35] <j0sh_> hmm
[17:19:46] <wbs> j0sh_: as long as you document it in the ff_http_* interface, I think it's ok for now
[17:19:58] <j0sh_> i dunno, it just feels like a "gotcha" that whoever uses the api later needs to know
[17:20:02] <j0sh_> yeah
[17:20:05] <hyc> iive: that in itself should tell you something. first, the gnutls maintainers take too long to identify problems or admit they exist...
[17:20:33] <j0sh_> ah well. writing that dictionary was fun
[17:20:56] <hyc> and there are plenty more bug reports like those
[17:21:35] <hyc> but that's my main gripe with gnutls - they don't even recognize how bad their code is.
[17:21:39] <wbs> j0sh_: also, if you do set custom headers, chances are that you'd want to adjust them too for each request, so I don't think it's that big issue for now
[17:21:51] <hyc> how bad their *design* is, how bad their API is...
[17:23:56] <hyc> as developers they're simply too inexperienced; every time you report a problem you have to educate them about why their approach doesn't work in the real world.
[17:25:14] <hyc> gnutls is effectively a high school science project - great for them to learn, terrible to entrust your system security to
[17:25:35] <kshishkov> but it's GNU!
[17:25:36] <iive> and i thought gnutls is good alternative to openssl
[17:26:01] <hyc> you want a security library written by people who have years of experience with protocols and crypto, not people who have barely read half of the specs yet.
[17:28:33] <hyc> http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
[17:28:49] <kshishkov> you can have people with many years of experience being clueless idiots though
[17:28:59] <twnqx> like openssl has shown before :P
[17:29:46] <hyc> I guess. everyone makes mistakes now and then
[17:31:05] <hyc> and I've written enough patches for OpenSSL to know it's not perfect. but I've never had to fix something that was fundamentally broken, just fix an overlooked detail.
[17:33:01] <hyc> my biggest problem with openssl is just patch acceptance. They sit around uncommitted, and people just wind up applying them to their own builds by searching thru mailing list posts.
[17:34:34] <kierank> that doesn't sound good for a security product. at least doing that for ffmpeg isn't that bad...
[17:34:46] <lu_zero> siretart: ?
[17:42:07] <hyc> kierank: nothing serious. E.g., I ported OpenSSL to EBCDIC OS/390 back in 2003
[17:42:08] <hyc> http://osdir.com/ml/encryption.openssl.devel/2003-03/msg00004.html
[17:42:13] <ramiro_> hyc: polarssl has the smallest footprint, but does it work? =)
[17:42:29] <hyc> patches still aren't committed, even they are in wide use now. http://fixunix.com/openssl/262953-re-openssl-org-1621-patch-os390-unix-ebcdic-0-9-7m.html
[17:42:38] <hyc> ramiro_: yes, it works. :P
[17:47:08] <hyc> likewise my 68020 asm bignum code for OpenSSL, posted in 2002, in use in a number of Atari and Amiga builds. still not committed. http://www.mail-archive.com/openssl-dev@openssl.org/msg10768.html
[17:49:27] <ramiro_> oh, what a crappy makefile polarssl has... "cd library  && make all && cd .." why "cd .."?
[17:49:56] <hyc> probably working around DOS shell stupidity. dunno.
[17:50:07] <iive> hyc: maybe you should remind them... they may have forgotten about them.
[17:50:31] <hyc> iive: they were never high priority for the team, they certainly are even lower priority today.
[17:50:39] <iive> e.g. remind them once per year :)
[17:51:24] <hyc> I don't even use my 68030 systems any more, and I don't need to actively support any OS390 customers now, so not a priority to me any more either
[17:51:44] <iive> usually the problem with such minor patches is that packagers use them, but submitter stop pushing them, and developers thing that the problem went away...
[17:52:40] <hyc> between 2003 and 2007 there was a steady trickle of pings on EBCDIC support. no action, despite several sites saying they're using the patches and they work well.
[17:53:01] <humbolt> your bugtracker does not work
[17:53:10] <humbolt> I tried to register yesterday
[17:53:21] <humbolt> neither email-reply activation nor the http link activation works
[17:53:29] <_av500_> rounddown?
[17:53:43] <humbolt> just to let you know, as I can't use the bugtracker to report this
[17:59:41] <j0sh_> wbs: re: extracting x-server-ip for tunneling, could we also keep a dictionary of responses and add a ff_http_get_response_headers function?
[18:12:17] <BBB> mru: you still didn't remove this poor chap's ban!!!
[18:18:39] <ramiro_> hyc: am I supposed to be able to build with polarssl support (only in the librtmp dir) without hacking the makefile?
[18:18:48] <hyc> yes
[18:18:54] <hyc> make CRYPTO=POLARSSL
[18:19:16] <kshishkov> there's no need to shout
[18:19:29] <hyc> kshishkov: :P
[18:19:31] <ramiro_> oops, I had CRYPTO=POLAR =)
[18:19:38] <kierank> make now has voice recognition
[18:20:04] <kshishkov> ramiro, that's better than CRYPTO=EQUATORIAL
[18:36:04] <lu_zero> grr
[18:41:30] <BBB> j0sh_: let me know once you have new patches for http and I'll review them
[18:43:20] <j0sh_> ok
[18:43:33] <BBB> and sorry about not interacting about that, I should've noticed earlier
[18:44:06] <BBB> Yuvi: I don't think I understand inter-prediction at all, or I'm plain stupid, can you review a patch for me when you're awake? :)
[18:45:27] <BBB> and how do I resolve a merge conflict?
[18:45:44] <BBB> (git)
[18:45:50] <j0sh_> grep for <<< and manually fix it to whatever's the right one
[18:46:50] <lu_zero> BBB: git mergetool
[18:47:32] <lu_zero> if it's j0sh_ tree that had been rewritten
[18:47:38] <lu_zero> you might just reset it
[18:47:48] <lu_zero> git reset --hard origin && git pull
[18:47:58] <lu_zero> that wipes and fetch again
[18:48:02] <j0sh_> BBB: my latest email to the rtsp-tunneling thread had my latest changes to http
[18:48:12] <BBB> j0sh_: oh, good, let me check
[18:48:36] <j0sh_> although i think with your idea of strcasestr, we might be able to get rid of the ff_set_chunked_transfer_encoding function
[18:49:02] <BBB> hmmm
[18:49:07] <BBB> don't av_free(s) in read()
[18:49:10] <BBB> on error
[18:49:22] <BBB> that's only for init, because if init failed, all internal mallocs should be undone
[18:49:22] <BBB> t
[18:49:22] <BBB> ha
[18:49:28] <BBB> that's not the case for read
[18:50:33] <j0sh_> alright
[18:51:52] <lu_zero> BBB: linear seek on a string + resetting it somehow doesn't sound to me as robust or efficient...
[18:52:03] <BBB> lu_zero: what do you mean?
[18:52:13] <BBB> there isn't really any other way
[18:52:18] <BBB> and it's only done once per http request
[18:53:40] <lu_zero> I'm not so fond of it
[18:55:09] <lu_zero> (ok, I'm the one that forced Honoome to learn ragel so the rtsp parsing in feng is strict, so I do have the tendency of overkilling problems...)
[18:55:27] <j0sh_> ragel is really well-suited for that though
[18:56:01] <lu_zero> =)
[18:57:01] <lu_zero> anyway it's a smaller detail
[18:57:27] <j0sh_> a couple of ruby app servers (mongrel, thin) have their http parsers done entirely in ragel from some abnf dump
[18:57:45] <lu_zero> I can discuss about it with michael later about it
[18:57:54] <lu_zero> j0sh_: and the newer lighttpd as well
[18:58:11] <j0sh_> cool
[18:58:12] <lu_zero> since ragel si really handy
[18:58:14] <lu_zero> is
[18:58:32] <j0sh_> i used it as a lexer in my compilers course
[18:59:32] <lu_zero> wow
[18:59:37] <lu_zero> impressive
[19:00:27] <j0sh_> i think i also rolled my own dictionary for that course for the symbol table, lol
[19:00:49] <j0sh_> as i said, re-implementing common data structures is fun :)
[19:02:11] <BBB> I prefer plain C
[19:02:28] <BBB> but in general, to get expected behaviour where defaults are used for mssing headers and so on, you need to crossref the two anyway
[19:02:36] <BBB> so then a repeated linear search is the only way to do that
[19:02:39] <BBB> (right?)
[19:03:05] <j0sh_> what if you need to omit the defaults
[19:03:29] <BBB> is there a practical need for that?
[19:03:45] <wbs> BBB: in some cases, you could want to omit e.g. the Range header
[19:03:49] <wbs> I think
[19:03:50] <j0sh_> right now if we use the defaults + extra headers, rtsp-http will break
[19:03:59] <BBB> which defaults?
[19:04:06] <j0sh_> i havent tracked it down to which one, but its one of them :)
[19:04:18] <BBB> could it be you hardcoding content-length?
[19:04:33] <j0sh_> no, the server ignores that, the spec says its just for proxies
[19:04:42] <lu_zero> BBB: the dict approach doesn't require linear search ...
[19:04:43] <BBB> hmm...
[19:05:13] <BBB> then add a second function for "headers to ignore", or make it a flag field or so
[19:05:28] <BBB> it's a hack anyway, that we'll eventually remove for AVOptions ;)
[19:06:50] <lu_zero> avoptions used how?
[19:10:19] <BBB> to set custom headers
[19:10:24] <BBB> I don't know exactly how yet :)
[19:10:38] <BBB> you could imagine there being an avoption for range_string
[19:10:42] <BBB> and another for [etc.]
[19:10:52] <BBB> and one more for extra_headers
[19:11:08] <BBB> to remove the default ragne, set a string of "" or NULL or so
[19:12:07] <j0sh_> we could implement avoptions as a dictionary :)
[19:13:13] <j0sh_> btw, i removed the calls to av_free
[19:13:23] <j0sh_> http://github.com/j0sh/ffmpeg-soc/commit/dd1d82f6efd911caa1dde355e321965213989915
[19:14:03] <j0sh_> for rtsp-http at least, everything works the way its supposed to now. no dictionary, no string searching, we just set and replace everything
[19:15:08] <BBB> it's a little random imo
[19:15:23] <BBB> (which ones to replace, which ones to keep as defaults, etc.)
[19:15:32] <BBB> I'd rather do that in a little more predictable manner
[19:15:43] <j0sh_> i tried to document it well in http.h
[19:16:12] <j0sh_> Authorization is there for obvious reasons
[19:16:28] <BBB> documentation doesn't make it less random :)
[19:16:31] <j0sh_> Transfer-Encoding is settable on its own because it affects other parts of the data
[19:16:46] <j0sh_> User-Agent because there's no reason why we'd need to change that
[19:16:52] <j0sh_> and everything else goes
[19:17:49] <lu_zero> eh eh ^^;
[19:18:06] <lu_zero> BBB: see why I like better storing them in a dict =P?
[19:18:10] * lu_zero should go
[19:18:16] <BBB> hehe :)
[19:18:26] <BBB> I'm affraid it won't suffice for mms-http
[19:18:40] <BBB> we should talk to spyfeng about that
[19:18:52] <j0sh_> yeah
[19:19:11] <j0sh_> BBB: i dont have a blog yet :) will let you know once it's up
[19:19:49] <BBB> I'm quite sure for mms-http, you need to set the user-agent: to windows media player 7.4 or so
[19:20:03] <j0sh_> areyou serious?
[19:20:08] <BBB> or, let's just say i wouldn't be surprised if that was the case
[19:20:12] <j0sh_> lol
[19:21:09] <wbs> j0sh_: btw, until we support tunneling in muxer mode, add code at the head of ff_rtsp_connect to check for that and fail if it is chosen, we've got similar checks for udp multicast now
[19:21:29] <BBB> wbs: you will apply 4/6?
[19:21:39] <wbs> BBB: sure
[19:21:47] <BBB> good work by the way, rtsp/http is I think the most complex part of the whole gsoc task, it's progressing nicely
[19:21:51] <BBB> now if only we had autodetection :)
[19:21:56] <ramiro_> where do I get the key with which the release tarballs are signed?
[19:23:15] <wbs> j0sh_: I tried hacking in tunneling support for the muxer too. there's two gotchas there; you need to base64 the data sent in rtspenc.c too, that's simplified now that both the interleaving header and data are stored consecutively
[19:23:42] <wbs> j0sh_: you also need to base64 encod the send_data in ff_rtsp_send_cmd_with_content_async
[19:24:06] <wbs> j0sh_: ... and the small gotcha there is that you may have to base64 encode it together with the request, not as two separate base64 chunks
[19:26:08] <j0sh_> wbs: is there a reason rtspenc doesn't use ff_rtsp_send_cmd* ?
[19:26:44] <wbs> j0sh_: yes, since the data is sent as interleaved chunks, with $<channelid><2-byte-length>
[19:26:50] <wbs> j0sh_: not as an RTSP request
[19:28:41] <j0sh_> got it
[19:29:05] <j0sh_> ok for now i'll just disable rtsp-http muxing until we get that figured out
[19:29:29] <wbs> I'll apply the ok'd patches now
[19:29:50] <wbs> then you get to see the awesomeness of git when you pull the latest stuff to your master and rebase your feature branch on top of that
[19:30:21] <j0sh_> heh
[19:30:23] <wbs> and see that the matching patches aren't duplicated on your feature branch but simply removed, so you only keep the unapplied patches on the branch. :-)
[19:30:34] <j0sh_> nice
[19:31:05] <j0sh_> that is really cool actually
[19:31:20] <wbs> indeed it is
[19:32:24] <Yuvi> BBB: sure, I'm here now
[19:34:24] <wbs> j0sh_: btw, you had a minor bug in splitting the patches, #4 that I'm trying out separately before applying now, used out_buf instead of buf in ff_rtsp_send...
[19:34:28] <BBB> yuvi: http://ffmpeg.pastebin.com/uwf25uPA
[19:34:58] <BBB> yuvi: I think how I keep track of reference frames is correct, but I don't understand how to apply the mvs to do prediction, all I get is mostly-green frames
[19:35:04] <BBB> (i.e. chroma values are near-zero)
[19:35:51] <BBB> I must admit that I'm only just now starting to actually track down whether anything I've parsed so far from the bitstream is correct, so there may be many obvious bugs, but I was wondering if I was just completely misunderstanding how this is supposed to be done
[19:36:50] <j0sh_> wbs: ah, can you fix locally?
[19:36:54] <wbs> j0sh_: yeah
[19:37:32] <wbs> unfortunately, it makes your git rebase not totally as cool, you will have to do git rebase --skip when it complains about conflicts for that one
[19:37:40] <wbs> (since the one I'm applying won't be exactly the same as you have)
[19:38:08] <j0sh_> if i make the change here too, should be ok?
[19:38:18] <wbs> yeah, that works too
[19:41:12] <Yuvi> BBB: don't see anything obviously wrong to cause that, does it still happen if you disable the idct for inter frames and force 0,0 mv for everything?
[19:42:07] <Yuvi> though you will want to offset src appropriately
[19:42:35] <CIA-92> ffmpeg: mstorsjo * r23494 /trunk/libavformat/ (rtsp.c rtsp.h rtspenc.c):
[19:42:35] <CIA-92> ffmpeg: RTSP: Add a second URLContext for outgoing messages
[19:42:35] <CIA-92> ffmpeg: Done in preparation for RTSP over HTTP.
[19:42:35] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[19:42:35] <CIA-92> ffmpeg: alexc * r23495 /trunk/libavcodec/aacenc.c: Cleanup apply_window_and_mdct().
[19:43:54] <Yuvi> which could cause a lot of green if you have mainly up/left MVs and aren't handling off-frame MVs
[19:44:47] <CIA-92> ffmpeg: mstorsjo * r23496 /trunk/libavformat/ (rtsp.c rtspenc.c): Remove unused local variables
[19:44:53] <BBB> off-screen mvs are set to zero
[19:45:09] <BBB> (the code is slow, please excuse me for that but I'd like to see a picture before I care about performance :-) )
[19:45:26] <BBB> and yeah, the buffer is set to zero inside inter_predict()
[19:45:31] <BBB> so it's unrelated to idct
[19:45:45] <BBB> let's try mv=0
[19:45:52] <BBB> that should simply copy the original picture right?
[19:46:36] <CIA-92> ffmpeg: mstorsjo * r23497 /trunk/libavformat/ (rtsp.c rtsp.h):
[19:46:36] <CIA-92> ffmpeg: RTSP: Propagate errors up from ff_rtsp_send_cmd*
[19:46:36] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[19:47:14] <BBB> nope, zero-mv fixes the green
[19:47:15] <Yuvi> yeah, also s->framep[mb->ref_frame]->data[0] as src
[19:47:20] <BBB> the bottom of the screen is still garbled
[19:47:57] <BBB> so I handle mvs wrong
[19:49:12] <Yuvi> or am I reading this wrong
[19:49:15] <BBB> if I have a mv of x, y, does that mean that (relative to the src/dst coords of this mb), I should move src:-x,-y to dst:0,0? or src:x,y to dst:0,0?
[19:49:19] <BBB> which line?>
[19:49:37] <BBB> libvpx appears to move src:0,0 to dst:x,y, which sounds weird
[19:49:50] <Yuvi> it was related to what you just said: mvs are always relative to the current mb
[19:50:00] <Yuvi> or block/subpartition
[19:50:32] <BBB> oh, right, I currently do the offset of src inside predict4x4, that's ugly
[19:50:33] <Yuvi> srcx + mvx, srcy + mvy -> dstx,dsty
[19:50:51] <Yuvi> where srcx == dstx, etc
[19:50:52] <CIA-92> ffmpeg: mstorsjo * r23498 /trunk/libavformat/ (rtsp.c rtsp.h): Cosmetics: Reindent/align/wrap
[19:52:58] <BBB> so I don't think I get it
[19:53:10] <BBB> prediction moves from the "reference frame" to the "current frame" right?
[19:53:13] <BBB> just so I have that right
[19:53:16] <Yuvi> yeah
[19:53:47] <BBB> so ref_frame = src, current_frame = dst, for the first mb with coordinates 0, 0
[19:53:53] <BBB> if I have a MV of x=1, y=2
[19:53:54] <BBB> w
[19:53:59] <BBB> what should I do?
[19:54:21] <BBB> I should move src+stride*2+1 to dst+0?
[19:54:29] <Yuvi> yes
[19:54:37] <Dark_Shikari> well, if the mv is fullpel yes
[19:55:25] <BBB> right, let's just assume fullpel for now (&7==0)
[19:56:00] <BBB> my subpel code is clearly broken, if I disable that then most green pixels are gone
[19:56:13] <BBB> I still have a few bugs there but at least something looks a little right
[19:57:39] <_av500_> BBB: once it works, you should see a big furry rabbit...
[19:58:25] <BBB> I'm waiting for that rabbit to come out of the hat
[19:58:38] <BBB> right now yuvi's code shows a rabbit and mine messes it up, pretty much
[19:59:35] <Yuvi> for inter frames' bitstream, I think most of the places MODE_I4x4 is checked SPLIT_MV needs to bechecked for too
[19:59:57] <Dark_Shikari> why don't we just use the h264 modes for this?
[20:00:02] <Dark_Shikari> it would allow us to reuse existing macros
[20:00:15] <j0sh_> BBB: do you still want a separate ff_http_ignored_headers func?
[20:00:16] <BBB> Dark_Shikari: I probably will, once I understand that :)
[20:00:21] <BBB> j0sh_: if required, yes
[20:00:28] <j0sh_> if we're going to ditch all this for avoptions, we might as well keep what works now...
[20:00:29] <Dark_Shikari> BBB: i16x16, i4x4, p16x16, p16x8, p8x16, p8x8, p4x4
[20:00:30] <Dark_Shikari> we're done
[20:01:06] * BBB stares confused
[20:01:13] <Yuvi> where does h.264 store which i16x16 intra pred mode is used?
[20:01:24] <BBB> Dark_Shikari: you're talking to someone that thinks the h264 code is scary
[20:01:42] <BBB> I'm doing this so I will learn it, but the shotgun method likely won't work
[20:01:44] <Dark_Shikari> BBB: those are the names of the modes
[20:01:47] <Dark_Shikari> what do you not understand?
[20:01:57] <Dark_Shikari> "splitmv" is a fancy code term for "p16x8, p8x16, p8x8, or p4x4"
[20:02:04] <BBB> yes
[20:02:31] <Dark_Shikari> Yuvi: h->intra16x16_pred_mode
[20:02:32] <BBB> I looked, but couldn't even find where h264 mv code is stored
[20:02:41] <Dark_Shikari> BBB: same place as every other codec stores it
[20:02:48] <Dark_Shikari> oh, the code, not the mvs
[20:02:53] <Dark_Shikari> er, what "mv code" are you interested in?
[20:02:56] <Dark_Shikari> I don't know what "mv code" means
[20:02:58] <Yuvi> hm, I could've sworn that the mb mode was used for context prediction in vp8
[20:02:59] <Dark_Shikari> do what with mvs?
[20:03:08] <Dark_Shikari> Yuvi: then add another array
[20:03:21] <Yuvi> Dark_Shikari: no, now I can't find where
[20:03:27] <Yuvi> so it might not be
[20:03:54] <Dark_Shikari> imo vp8 decoder should basically share most of the h264 stuff
[20:04:03] <Dark_Shikari> like svq3
[20:04:04] <BBB> I totally agree
[20:04:16] <BBB> but I first need to understand it before it can share any code :)
[20:04:33] <Dark_Shikari> then ask questions
[20:04:33] <BBB> you're not fighting me not willing to do it; you're fighting my ignorance
[20:04:41] <Dark_Shikari> then ask questions
[20:04:41] <BBB> I just asked yuvi a question ;)
[20:04:43] <Yuvi> what order does h.264 do intra pred?
[20:04:48] <Yuvi> for 4x4
[20:04:49] <Dark_Shikari> Yuvi:
[20:04:55] <Dark_Shikari> 0 1 4 5
[20:04:56] <Dark_Shikari> 2 3 6 7
[20:05:02] <Dark_Shikari> 8 9 12 13
[20:05:04] <Dark_Shikari> 10 11 14 15
[20:05:11] <Yuvi> (vp8 does raster)
[20:05:36] <Yuvi> can 3 and 9 use the top right edge?
[20:05:41] <Yuvi> 3 and 11
[20:06:21] <Dark_Shikari> it's emulated
[20:06:36] <Dark_Shikari> e.g. if the top pixels are:
[20:06:37] <Dark_Shikari> ABCD
[20:06:41] <Dark_Shikari> the top right pixels are:
[20:06:42] <Dark_Shikari> DDDD
[20:07:09] <Yuvi> so always extended whenever they're not available?
[20:07:17] <Yuvi> and it's not the same all the way down a column?
[20:07:19] <Dark_Shikari> if top is available but top right is not, it's extended
[20:07:37] <Dark_Shikari> i.e. in 3, 7, 11, 15
[20:07:44] <Dark_Shikari> oh, well I guess 13 and 5 too.
[20:17:18] <Yuvi> Dark_Shikari: as far as sharing code, I really think vp8 will be more like rv30/40 in terms of amount of code able to be shared than svq3
[20:17:24] <Dark_Shikari> ok, true
[20:17:29] <Dark_Shikari> svq3 is way too similar to h264
[20:17:37] <Dark_Shikari> this, less so.
[20:18:50] <BBB> yuvi: since this is not outright wrong, do you mind if I commit this?
[20:18:50] <Yuvi> (actually, rv40's shared code with h.264 amount to h264pred.c/h and mpegvideo)
[20:18:58] <Yuvi> BBB: sure
[20:19:10] <hyc> hm, FLV metadata can include cuePoints which can be used to define subtitles, among other things
[20:19:21] <hyc> would be nice to add that to flvdec / flvenc
[20:19:23] <Yuvi> and put_h264_chroma_pixels_tab
[20:19:41] <j0sh_> how do i turn on assertions?
[20:20:33] * lu_zero gave up moving today =P
[20:20:49] <lu_zero> too tired =_=
[20:23:09] <BBB> yuvi: ok, it's sort of not really broken but not really correct, I'll check my mv parsing now that it looks like an image at least, there's probably a bug in it
[20:24:14] <BBB> Dark_Shikari: so what I meant was, given a reference frame src and a current frame dst and a motion vector for a MB, where is the code in h264 that moves src+MV to dst?
[20:24:24] <BBB> Dark_Shikari: or does that question make no sense whatsoever?
[20:25:50] <Yuvi> BBB: search h264.c for qpel_mc_func
[20:26:25] <Yuvi> hl_motion is close to the top iirc
[20:27:01] <BBB> it's actually the last hit :)
[20:27:03] <BBB> but yes
[20:27:26] <Dark_Shikari> hl_motion calls mc_part
[20:27:47] <Dark_Shikari> mc_dir_part is the actual thing you want
[20:59:47] <CIA-92> ffmpeg: mstorsjo * r23499 /trunk/libavcodec/avcodec.h:
[20:59:48] <CIA-92> ffmpeg: Improve grammar and readability
[20:59:48] <CIA-92> ffmpeg: Patch by Rodney Baker, rodney dot baker at iinet dot net dot au
[21:36:27] <DonDiego> moin
[21:36:41] <DonDiego> i'll arrive tuesday at 21:20 in berlin
[21:56:17] <janneg> DonDiego: noted. I guess we'll eat something somewhere then
[21:56:38] <DonDiego> how do i get from hbf to your place?
[21:56:44] <DonDiego> and who else is staying with you?
[22:09:56] <janneg> S1 to Julius-Leber-Bruecke (via Friedrichstr. Stadtbahn or Brandenburger Tor U55)
[22:13:03] <janneg> staying at my place only kostya. tuesday evening whoever we meet at the fairground
[22:35:05] <DonDiego> ok, cu, gnite
[22:36:24] <dezodorant> so it looks like no one care https://roundup.ffmpeg.org/issue1954 ;-(
[22:57:38] <astrange> did someone ever try to implement visibility in lavc?
[22:59:02] <pengvado> yes, and it was rejected because the patch was ugly
[23:01:24] <astrange> it looks like it should help on i386+pic
[23:01:46] <astrange> though unfortunately i don't see how to turn all the dsp calls into fastcall without pasting attributes on all of them
[23:03:39] <Dark_Shikari> astrange: but we don't care about x86_32+pic
[23:10:01] <astrange> i care, darwin is half-pic http://pastebin.com/nw45686L
[23:13:31] <astrange> hmm but visibility=hidden and __private_extern__ don't actually seem to work better there
[23:13:36] <astrange> still, that's fixable
[23:13:51] <pengvado> what happens when you build x264 on darwin? x264 doesn't support x86_32+pic.
[23:14:42] <CIA-92> ffmpeg: michael * r23500 /trunk/libavformat/utils.c: Fix muxing rgb rawvideo in avi regression.
[23:15:52] <astrange> works, iirc enabling shared libraries causes a lot of ld warnings about textrels
[23:16:11] <astrange> wouldn't work if you were using non-pic assembly for ppc or x86-64
[23:19:52] <Dark_Shikari> what's special about pic on ppc32?
[23:21:24] <astrange> i can't remember except that you can't turn it off
[23:30:02] <Tjoppen> ooh, rawvideo getting patches
[23:41:35] <hyc> hmm, no support for SAMI subtitles here
[23:41:51] <hyc> and mplayer's support isn't giving anything for Hulu's SAMI subtitles
[23:42:49] <hyc> :q
[23:42:55] <hyc> oops
[23:50:56] <astrange> they're really using SAMI? that's so underspecified it's nearly impossible to implement properly
[23:51:40] <hyc> yeah. it's not a big deal, the get_iplayer script munged it and spit it out as srt
[23:51:57] <hyc> (once upon a time, when get_iplayer still supported hulu)
[23:52:20] <hyc> I was just curious why it needed to be translated to srt, why we couldn't use it directly
[23:52:36] <hyc> but yes, it's really SAMI
[23:53:48] <hyc> seems like it only defines the start time of a caption, no duration.