[00:44:21] * Honoome wishes he could have a proper tiling wm for _just one viewport_ [00:44:52] * Dark_Shikari wonders why ptest has a 3 cycle latency [00:44:57] <Dark_Shikari> and takes two uops. [00:48:20] <Dark_Shikari> also, I love michael responses [00:48:21] <Dark_Shikari> " [00:48:21] <Dark_Shikari> this heuristic is simply poor [00:48:23] <Dark_Shikari> " [08:41:03] <KotH> ohayou gozaimasu [08:41:39] <ohsix> oh no, morning [08:43:01] <wbs> morning [08:44:50] <av500> dobro jutro [08:45:10] <thresh> доброе утро, да [08:45:30] <spaam> God morgon :) [09:56:58] <CIA-98> ffmpeg: vitor * r23646 /trunk/libavcodec/ (mpegaudiodec.c mpegaudio.h): [09:56:58] <CIA-98> ffmpeg: Factorize the mpegaudio windowing code in a function and call it by a [09:56:58] <CIA-98> ffmpeg: function pointer. Should allow for ASM optimizations. [10:01:10] <wbs> e/wii Yuvi [10:01:16] <wbs> oops ;P [10:01:24] <wbs> Yuvi: ping [11:21:33] <mru> "Unless Steve and company start genetically engineering new cats, the Mac is in serious trouble." [11:23:24] <mru> morning superdump [11:23:32] <superdump> hellos [11:23:55] <mru> how's sthlm? [11:25:19] <Dark_Shikari> http://hakuryu.jp/bin/nicky/2008/chinacapacitorek1.jpg [11:25:36] <mru> old but good [11:27:07] <Dark_Shikari> also [11:27:14] <Dark_Shikari> MPEG HRD is officially the most retarded fucking thing ever [11:27:24] <Dark_Shikari> LETS DEFINE AN ENTIRE SYSTEM THAT RUNS ON INFINITE-PRECISION REAL MATH [11:27:28] <Dark_Shikari> ... AND THEN ROUND OFF ALL THE BITS AT THE END [11:27:43] <bilboed-tp> the Turing Codec [11:27:52] <Dark_Shikari> And of course, let's make sure not to explain in the spec how you're supposed to actually implement it [11:28:08] <mru> Dark_Shikari: H is for hypothetical [11:28:10] <Dark_Shikari> And let's design it so that you need, in practice, probably at least 96 bits of internal precision [11:28:15] <mru> nobody is asking you to build one [11:28:19] <Dark_Shikari> mru: But you still have to model it [11:28:27] <Dark_Shikari> if your precision is not infinite you will get rounding error [11:28:37] <Dark_Shikari> Which will cause compliance errors [11:28:46] <mru> it doesn't have to be exact [11:28:49] <Dark_Shikari> Yes it does. [11:28:52] <Dark_Shikari> We just confirmed it does. [11:29:10] <mru> as long as you keep the error on the right side it doesn't matter [11:29:16] <Dark_Shikari> there is no right side [11:29:55] <Dark_Shikari> Manao confirmed that you absolutely need to keep full precision or you will eventually desync in hrd [11:29:58] <mru> maybe you won't achieve the most ideal rate control or muxing [11:29:58] <Dark_Shikari> And he wrote Ateme's HRD. [11:30:03] <Dark_Shikari> No, this isn't about ratecontrol [11:30:09] <mru> what then? [11:30:26] <Dark_Shikari> This is about how you write the buffer state that results from ratecontrol [11:30:52] <mru> as long as you're within bounds, where's the problem? [11:31:05] <Dark_Shikari> Because if you desync from reality, you will eventually exceed bounds when you didn't realize that you did [11:31:19] <Dark_Shikari> For example, suppose you are 0.0000001 off every frame [11:31:24] <Dark_Shikari> after 1 million frames, you're 0.1 off [11:31:29] <mru> 0.1 what? [11:31:32] <Dark_Shikari> of the buffer [11:31:34] <Dark_Shikari> i.e. 10% [11:31:43] <Dark_Shikari> that means a buffer fullness of 0.09 is actually -0.01 [11:31:50] <Dark_Shikari> And you just underflowed. [11:32:17] <mru> so round down when removing bits and up when adding them [11:32:31] <Dark_Shikari> Won't work. [11:32:35] <Dark_Shikari> That'll just slow it down [11:32:37] <mru> no it won't... [11:32:39] <mru> work [11:32:54] <Dark_Shikari> There's no guarantee roundups == rounddowns there [11:33:03] <Dark_Shikari> Or even that round ups will be proportional to round downs [11:33:10] <Dark_Shikari> Here's the problem: "buffer_rate" (the number of bits added to the buffer each frame) is a rational number (not an integer) [11:33:41] <mru> that's a bit extreme... [11:33:43] <Dark_Shikari> it is equal to (video max bitrate) * (ticks per frame) / (timebase denominator) [11:33:52] <Dark_Shikari> This is a fraction. [11:34:03] <Dark_Shikari> If you make it into a floating point number, even a double, you will have a slightly inaccurate buffer_rate value. [11:34:11] <Dark_Shikari> This slight inaccuracy will accumulate over time. [11:34:23] <Dark_Shikari> The only way to fix this is to express your buffer state as (bits) * (timebase_denominator) [11:34:27] <mru> can't you fiddle the bitrate to make it an integer? [11:34:42] <Dark_Shikari> i.e. Actual Buffer State In Bits = Buffer State / Timebase_den [11:34:44] <Dark_Shikari> that makes it an integer [11:34:49] <kshishkov> mru: is there a catch with "vcvt.f64.s32 dX, sY, #24" ? Looks like it does not do the right thing for me on doubles while "vcvt.f32.s32" works [11:35:47] <mru> kshishkov: the catch is that it doesn't work with doubles [11:36:12] <mru> wait [11:36:44] <mru> that was vector ops [11:36:50] <mru> plain vfp should work [11:37:26] <mru> but not with that syntax [11:37:33] <mru> both operands must be d regs [11:37:34] <kshishkov> it's single op in reality - converting one 32-bit int to 64-bit double [11:37:56] <mru> the assembler should've rejected that [11:38:30] <mru> so you have to put your fixed-point value in an even s reg [11:38:36] <kshishkov> it's VFP anyway - NEON does not work on them [11:38:39] <mru> then use the corresponding d reg [11:38:55] <mru> why are you doing double-precision vfp anyway? [11:39:14] <kshishkov> for the reference :) [11:40:35] <Dark_Shikari> why are you optimizing the reference [11:40:48] <mru> maybe gcc fucks it up [11:41:08] <kshishkov> unlikely - it's pure asm [11:41:08] <Dark_Shikari> um, but why do we care about speed on the reference :/ [11:41:25] <mru> maybe C code isn't exact enough [11:41:28] <kshishkov> that's for non-FFmpeg code anyway [11:42:09] <kshishkov> but it's simple "convert fixedpoint int array to double" function [11:45:40] <_av500_> mru: you are not in stockholm? [11:45:51] <mru> _av500_: no, why would I? [11:45:57] <_av500_> gee [11:46:16] <mru> well, it's a nice city [11:46:21] <mru> but I'm not usually there [11:46:39] <_av500_> my kids are watching it live now :) [11:46:49] <mru> stockholm? [11:47:01] <_av500_> yep [11:47:09] <kshishkov> good for them [11:47:52] <kshishkov> it's the second day of wedding ceremony, isn't it? [11:48:12] <_av500_> yes, the wedding it today [11:48:35] * mru is fortunate to be far away from that mess [11:49:42] * kshishkov was fortunate not to get to Kiev on the day of presidental inauguration [13:54:24] <_av500_> kshishkov: turn on zdf for swedish lessons [13:59:29] <mru> are they as "good" as swedish german lessons? [14:00:02] <_av500_> well, i can understand what they are saying from the context easily [14:00:06] <_av500_> mostly "yes" [14:00:24] <mru> what do you know about swedish german lessons? [14:00:35] <_av500_> nuthin [14:00:52] <Vitor1001> mru: just wondering, which CPU gains a lot from handwritten asm functions and have slow floats? [14:01:00] <mru> anything without an fpu [14:01:05] <mru> armv5te [14:01:07] <Vitor1001> and with a simd, no? [14:01:11] <mru> fixed-point dsps [14:01:46] <mru> gcc doesn't need simd to suck [14:01:46] <Vitor1001> I mean, if there are no simd instructions, why would we get so much gain in comparison with plain C? [14:02:25] <_av500_> gcc? [14:02:39] <Vitor1001> that's true, but it is often solved by a few MAC macros and etc, instead of rewriting a whole function, no? [14:02:53] <mru> depends [14:03:10] <mru> those mpeg audio functions are quite terrible even with the mac macros [14:03:31] <Vitor1001> :( [14:04:12] <Vitor1001> BTW, on a cpu supporting neon, which mp3 decoder is faster? [14:04:39] <mru> I'd have to write the neon code to answer that [14:04:53] <Vitor1001> I mean, with no asm optimizations [14:05:16] <Vitor1001> arm cpus that support neons have pretty fast floating-point math, no? [14:05:23] <Vitor1001> s/neons/neon/ [14:05:25] <mru> not the a8 [14:05:31] <mru> plain floats are atrociously slow on A8 [14:05:37] <mru> and gcc makes them even worse [14:05:58] <mru> right now the float version is 4x slower than fixed-point [14:06:28] <mru> it's not obvious that neonifying those functions would offset the slowdown in the non-simdable parts [14:07:13] <Vitor1001> Its funny that an arch with fast float simd has slow plain floats... [14:07:40] <mru> the A8 vfp unit is widely regarded as a mistake [14:07:53] <mru> the A9 one is much faster [14:08:09] <Vitor1001> but you can't use neon to do plain (not packed) floats? [14:08:15] <mru> A9 float performance is actually good [14:08:38] <mru> it's allegedly possible to make some single-precision ops use the neon pipeline [14:08:44] <mru> but gcc certainly doesn't do it [14:09:02] <Vitor1001> :p [14:09:43] <Vitor1001> So simd'fying float code in neon has a huge speedup even for simd standards? [14:09:58] <mru> neon fft is 12x faster than C on A8 [14:10:05] <Vitor1001> wow [14:10:18] <mru> even though it only does two float ops per cycle [14:10:48] <Vitor1001> That windowing function for mp3 is pretty simple to simdfy [14:11:00] <mru> I know [14:11:11] <Vitor1001> I'm pretty sure you can do it in no time by just "translating" my sse implementation [14:12:13] <mru> no [14:12:17] <mru> neon is very unline sse [14:12:18] <Vitor1001> And it is the single most time-consuming function for mp3 decoding... [14:12:20] <mru> much easier to use [14:12:46] <mru> although instruction scheduling is more critical [14:13:03] <mru> float ops have a latency of 4 or 5 cycles [14:13:22] <Vitor1001> After RE'ing a x86 fp-unit code, I find SSE so readable ;) [14:13:42] <Vitor1001> How can be it that much simpler? Better shuffles? [14:13:59] <mru> it's more complete [14:14:07] <mru> random things aren't inexplicably missing [14:14:18] <mru> and transposes are easy and fast [14:14:53] <Vitor1001> BTW, I have a stupid question about asm in general: [14:15:23] <Vitor1001> I often run out of registers (plain, not vector) when doing simd with a lot of pointers [14:15:45] <CIA-98> ffmpeg: alexc * r23647 /trunk/ (12 files in 2 dirs): Add HE-AAC v2 support to the AAC decoder. [14:16:01] <wbs> \o/ [14:16:01] <Vitor1001> Why don't the CPU manufacturers don't add a instruction to save the stack pointer in some temporary special register so we can use it? [14:16:08] <iive> \o/ [14:16:15] <mru> Vitor1001: what would happen on an interrupt? [14:16:55] <Vitor1001> Good question... [14:17:12] <elenril> peloverde++ [14:17:19] <mru> the stack pointer has to be _somewhere_ at all times [14:17:29] <mru> so you're really asking why isn't there one more register [14:17:59] <Vitor1001> mru: Of course, it is just a pity we have it all the time in something that is soldered to all the circuits [14:18:18] <Vitor1001> mru: It could be in somewhere "cheaper" in silicon than a register sometimes... [14:18:36] <mru> then how would you access the stack? [14:18:43] <Vitor1001> BTW, when will we get rid of FAAD? [14:18:54] <mru> as soon as peloverde commits PS [14:19:02] <Vitor1001> mru: You won't inside some inner loops that needs 7 REGS [14:19:04] <mru> oh, he just did [14:19:11] <Vitor1001> lol [14:19:18] <mru> Vitor1001: that's why real cpus have more regs [14:19:40] <Vitor1001> I thought adding more regs was easier said than done... [14:19:58] <mru> building a register file is easy [14:20:15] <mru> it's just a tiny sram [14:20:43] <Vitor1001> Yes, but isn't the problem that you have to physically connect it to a lot of things? [14:21:23] <mru> you need as many read/write ports as you can execute instructions in parallel [14:21:49] <mru> and each doubling in size needs one more bit in the opcodes to address it [14:22:11] <mru> it's mostly a tradeoff between number of registers and opcode size [14:22:36] <mru> the sweet spot seems to be 16-32 registers [14:23:09] <mru> you don't want opcodes wider than 32 bits [14:23:11] <Vitor1001> Also true for vector units? [14:23:32] <mru> and you do want 3 operands for most instructions [14:23:52] <mru> that eats 15 bits if you have 32 registers [14:24:03] <mru> leaving 17 bits to encode the instruction [14:26:42] <mru> more registers also means slower context switching [14:34:13] <mru> compare arm and mips instruction sets [14:34:37] <mru> arm has fewer registers but a richer instruction set [14:35:06] <mru> conditional everything, more powerful addressing modes etc [14:35:20] <mru> shifted operands [14:35:55] <Vitor1001> reverse vector multiplying? [14:36:17] <mru> unfortunately not [14:36:28] <mru> but it has a vector reverse instruction [14:36:44] <Vitor1001> Why not a particular case of shuffling? [14:36:57] <mru> then you need to set up the shuffle table first [14:37:06] <mru> takes time and eats registers [14:37:13] <mru> it has that too [14:37:17] <mru> but it's rarely needed [14:37:33] <Vitor1001> Indeed pretty different from sse [14:38:10] <mru> reverse, transpose, interleave, and deinterleave are usually sufficient [14:38:56] <Vitor1001> for most of the cases it's true. [14:39:07] <Vitor1001> But SSE2 pshufd is nice... [14:39:19] <mru> I wouldn't know [14:39:21] <Vitor1001> shufps is stupid in comparison... [14:39:32] <mru> sse is very unintuitive [14:39:50] <Vitor1001> I would like to lean neon one day to try [14:39:57] <Vitor1001> shame that qemu sucks for it :( [14:40:03] <mru> get a beagle [14:40:27] <Vitor1001> I know it's the easier way [14:40:50] <mru> there's no point writing code without hardware [14:42:03] <Vitor1001> Well, when you know it will be faster and you won't micro-optimize it while benchmarking... [21:18:56] <j0sh_> BBB: is there a reason there's so much sdp stuff in rtsp.c? [21:19:09] <BBB> like what? [21:19:17] <j0sh_> mostly parsing [21:19:19] <BBB> sdp really is the basis of rtsp, so it makes sense to place it there [21:19:26] <BBB> sdp is the stream description [21:19:31] <saintd3v> \o/ PS is in [21:19:48] <BBB> j0sh_: sdp.c is only sdp.c encoding/creating [21:19:51] <j0sh_> yeah, sdp can be used other places too... im just trying to figure out where to move the mp4/aac stuff [21:19:53] <BBB> rtsp.c is sdp "decoding" [21:20:03] <BBB> mp4/aac? [21:20:19] <BBB> just into a new file, most likely, just like rtp_xiph.c or rtp_whatever.c [21:20:28] <BBB> how's the vlc work going? :) [21:20:40] <j0sh_> it's only a few lines, if you think that justifies a new file, i can do that [21:20:44] <BBB> and how was your sister's wedding? :) [21:20:52] <BBB> a new file is always ok, even if it's small [21:20:59] <j0sh_> i turned in a vlc patch last friday, havent heard from anyone on it [21:21:08] <BBB> got a link? [21:21:27] <j0sh_> and sister's graduation was great... digging up the link [21:22:40] <j0sh_> BBB: http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2010-June/009265.html [21:23:13] <j0sh_> this was sent to vlc-devel, i CC'd ffmpeg-soc [21:23:19] <BBB> oh, graduation :-p I thought it was wedding [21:23:20] <BBB> sorry [21:23:26] <BBB> congratulations either way [21:23:58] <j0sh_> she's in hawaii living with her boyfriend right now... after gsoc, i just might pack up and bum out over there, heh [21:24:00] <saintd3v> mru: sorry about that, didn't see the commit message when i sent that first email :/ [21:25:10] <BBB> hawaii [21:25:12] <BBB> darn [21:25:52] <BBB> patch is simple enough, so does this make rtsp://bla work through the ffmpeg rtsp layer? [21:25:58] <j0sh_> i only need a power outlet and wifi to keep contributing to ffmpeg, hough :) [21:26:02] <BBB> or is that still handled by something else by default? [21:26:08] <BBB> you don't need wifi [21:26:10] <BBB> look at me [21:26:23] <j0sh_> are you on a modem? [21:26:29] <BBB> I have no internet at home, I go to a public lounge with internet or chat at work [21:27:12] <j0sh_> i like coding outside, my backyard is my de facto office [21:27:26] <j0sh_> but yes, i distinctly remember working on a school project in a starbucks somewhere in puerto rico [21:27:32] <BBB> hehe :) [21:27:33] <j0sh_> for the first 3 days of spring break [21:27:46] <j0sh_> anyway [21:28:02] <j0sh_> the patch will make rtsp:// work by default using ffrtsp [21:28:07] <BBB> excellent [21:28:13] <BBB> I'm guessing it [21:28:13] <BBB> ' [21:28:14] <BBB> oops [21:28:24] <j0sh_> but i disabled live555, i dont know what's selected first, ffrtsp or live555 [21:28:30] <BBB> I'm guessing they'll ask for a few more features, like e.g. some more depayloaders, before they take the patch [21:28:39] <BBB> but the patch is there, that's important [21:28:49] <BBB> we can all work on the featureset together, during and after soc [21:28:52] <j0sh_> svq3 and qdm2? [21:28:56] <BBB> those too [21:28:59] <BBB> live555 doesn't have them [21:29:19] <BBB> I RE'ed them (and gst copied my code) [21:29:39] <j0sh_> nice, nice, that feels good huh [21:31:00] <j0sh_> seeing your work somewhere else [21:31:51] <j0sh_> im looking through the live555 files real quickly, it seems like the only depacketizer we may be missing is the quicktime one [21:32:26] <BBB> yeah [21:32:40] <BBB> I added that to the end of the soc list, because I did some work and it's not easy [21:32:47] <BBB> I had a basically working version (no longer applies) [21:32:54] <j0sh_> http://people.gnome.org/~rbultje/ffmpeg-patchset/16-rtsp-x_qt.patch [21:33:01] <BBB> but it needs to interact with the qt demuxer [21:33:13] <BBB> and baptiste didn't really like my hack (and I understand why, it was a little hacky) [21:33:17] <wbs> j0sh_: regarding sdp parsing; I don't mind too much if the generic parsing routines are in rtsp.c, but I don't want the mp4 specific code there [21:33:19] <BBB> so that might need some work [21:33:42] <BBB> j0sh_: oh yeah, that's a very old set of patches by the way [21:34:08] <j0sh_> wbs: alright, i will move the mp4/aac stuff into a separate file or something [21:34:15] <wbs> j0sh_: yeah [21:34:42] <wbs> j0sh_: also, there's been some requests on getting the general parsing of a fmtp line shared between formats [21:34:54] <wbs> j0sh_: there's a bit of code duplicated between e.g. amr, h264 etc [21:34:58] <j0sh_> BBB: still a good start, it'll make my job easier [21:35:13] <BBB> wbs: you can do that too :-p [21:35:22] <j0sh_> wbs: i can look into that [21:35:25] <BBB> ;) [21:35:29] <wbs> BBB: yes, but j0sh_ can too :-) [21:36:43] <Honoome> j0sh_: please don't tell me you're going to ask us to implement the server-side in feng for that :P [21:37:07] <wbs> Honoome: nah, I guess using DSS for testing that is enough [21:37:10] <CIA-92> ffmpeg: mstorsjo * r23648 /trunk/libavformat/rtsp.c: [21:37:10] <CIA-92> ffmpeg: RTSP: Don't store the connection handles in local variables [21:37:10] <CIA-92> ffmpeg: This removes some useless copying of handles, and simplifies error handling. [21:37:10] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [21:37:27] <BBB> wbs: btw you're doing a lot of great work all around, keep doing that! :) [21:37:41] <BBB> so we have all depayloaders that live555 has? [21:37:43] <BBB> I'm surprised [21:37:48] <BBB> what about e.g. gstreamer? [21:37:50] <wbs> BBB: thanks :-) [21:37:57] <BBB> any that they have and we don't? [21:38:09] <Honoome> wbs: good, as long as my next work within feng is going to be simply rewriting the conf I'm happy :D [21:38:16] <wbs> BBB: are you ok with the rtsp/http tunnel auth patches I sent yesterday(?) [21:38:36] <j0sh_> Honoome: if i have no way to test, i just might :) [21:38:42] <BBB> wbs: didn't look yet [21:38:43] <BBB> let me check [21:38:55] <BBB> I've been a little ... shall we say ... absent on rtsp patch review :) [21:39:08] <wbs> BBB: yeah, but you're doing good job on VP8 instead :-) [21:39:28] <wbs> j0sh_: DSS has a few samples with svq3 and qdm2 out of the box iirc [21:39:38] <wbs> j0sh_: and I can generate a bunch of the other formats using quicktime broadcaster [21:39:49] <BBB> patch #1 is of course OK [21:39:56] <j0sh_> wbs: how do you find these leaks? with valgrind, i get a ton of leaks from sdl/x11 but none from ffrtsp (i tried testing the codepath you found) [21:39:57] <BBB> maybe the caller should check though [21:40:05] <BBB> but I'm ok with applying it, it's not speed-critical [21:40:17] <wbs> j0sh_: yeah, it's quite noisy with ffplay - try using ffmpeg instead [21:40:20] <BBB> please document that in the function doxy, that an empty string means no auth will be added, like NULL [21:40:34] <wbs> j0sh_: ffmpeg itself shouldn't leak at all [21:40:36] <j0sh_> wbs: ah, no ffplay. got it [21:40:51] <BBB> 2 looks simple enough, so is ok [21:41:45] <BBB> 3/4 doesn't look right [21:41:52] <wbs> BBB: yeah, for #1, I prefer it that way, doing ff_url_join(..., auth[0] ? auth : NULL, ...) looks ugly [21:42:19] <j0sh_> wbs: quicktime broadcaster requires osx... i must be the only person in the world who wiped osx on his macbook for ubuntu [21:42:42] <wbs> j0sh_: yeah. I can generate any samples you want if you list them. :-) [21:42:56] <j0sh_> cool, thanks [21:42:57] <wbs> j0sh_: on the other hand, perhaps I should create the ones I want you to fix support for. ;-) [21:43:14] <j0sh_> heh [21:46:03] <BBB> j0sh_: I did that... at some point I got bored, ubuntu doesn't do all that much more than osx itself :-p [21:46:19] <BBB> then the laptop broke and apple support removed ubuntu and reinstalled osx for me, unasked [21:46:21] <BBB> then I gave up [21:47:24] <wbs> j0sh_: also, for finding leaks - this one I found just by reading the code, it's a good trait to think about all the nitty gritty cleanup details when reading/writing it [21:47:30] <CIA-92> ffmpeg: mstorsjo * r23649 /trunk/libavformat/rtsp.c: [21:47:30] <CIA-92> ffmpeg: RTSP: Set the connection handles to null after closing them [21:47:30] <CIA-92> ffmpeg: This fixes a potential issue when doing redirects. [21:47:40] <wbs> BBB: so, what's wrong about 3/4, and how to fix it more cleanly? [21:48:37] <j0sh_> BBB: yeah, i got frustrated with macports trying to get feng to work. wiped the whole thing rather than deal with broken things [21:49:14] <BBB> heh :) [21:49:21] <BBB> wbs: thinking ;) [21:49:25] <BBB> wbs: it might be ok [21:49:34] <BBB> wbs: but I want to think for a day or so if there's a better way [21:49:36] <BBB> if not, it's ok [21:49:58] <wbs> ok, I'll apply the first parts now at least, feel free to think about those then :-) [21:50:00] <j0sh_> wbs: yup, it's a good that you're lending a second pair of eyes. would prob not have caught most of the things you've been fixing [21:50:25] <BBB> ok [21:50:28] <wbs> BBB: the problem mainly is doing proper auth when doing http posts [21:50:41] <wbs> BBB: I've been doing a bit of work on those areas in libcurl vs git [21:51:19] <wbs> since a proper http server doesn't say the "403, please use auth method foo" until you've done the full http post [21:51:20] <BBB> if they share the same auth, I'm wondering if we shouldn't just share the same object [21:51:38] <BBB> because as you say, nc/nonce would be shared [21:51:58] <wbs> yeah [21:52:02] <BBB> especially if the counter is supposed to increase regardless of which channel you send it over [21:52:09] <BBB> then it's a bad idea to make them two separate objects [21:52:11] <BBB> (imo) [21:52:44] <wbs> yes, but on the other hand, the only requests done on these two sessions is the initial get, that may get a 403 reply, then a re-request on that one with proper auth, and an initial post request on the other one, no more [21:52:57] <wbs> nobody is doing seeks on these :-) [21:55:05] <j0sh_> speaking of seeks, isn't seeking technically still broken in http? [21:55:27] <BBB> yeah [21:55:30] <wbs> it shouldn't be, as far as I know? [21:55:31] <BBB> :-( [21:55:39] <BBB> I should probably just apply tjoppen's patches [21:55:49] <BBB> I haven't had time to finish looking at it [21:55:58] <wbs> but is_streamed is still set to 1 for the demuxers, though :-( [21:57:28] <BBB> get the alloc work done so we can remove that :) [21:57:41] <CIA-92> ffmpeg: mstorsjo * r23650 /trunk/libavformat/ (utils.c internal.h): ff_url_join: Don't add any at-char if the auth is an empty string [21:57:54] <wbs> yeah, I should start looking at that ;P [21:58:06] <wbs> the latest outlines after the discussions with michael should actually be doable [21:58:33] <CIA-92> ffmpeg: mstorsjo * r23651 /trunk/libavformat/rtsp.c: RTSP: Add the auth credentials to the HTTP tunnel URL, too [22:02:04] * BBB sets up a seeking http server to test [22:02:23] <BBB> I'll be back later with patches for that :) [22:02:32] <BBB> wbs: you work on getting is_streamed fixed in the mean time :) [22:02:46] <BBB> then after that I'll do some more vp8 work [22:03:18] <wbs> I think I'll work on getting some sleep here soon, but perhaps I should give it a shot tomorrow [23:35:55] <peloverde> Why is the MPEG refsoft giving me an ld.bfd internal linker error!? [23:54:11] <CIA-92> ffmpeg: alexc * r23652 /trunk/libavcodec/ps.c: psdec: Factorize iid/icc/ipd/opd parameter bitstream reading.