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

[irc at mansr.com]

[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.