[00:09:24] <peloverde> j-b, yes I found the fix [00:10:18] <peloverde> I needed "--enable-shared --enable-pic" on ffmpeg and I had old objects left over in either ffmpeg or vlc [00:11:29] <mru> --enable-shared should have no effect on the static libs if you already had --enable-pic [00:11:34] <mru> except on ia64 [00:17:05] <j-b> peloverde: cool. [00:39:25] <ramiro> kurosu: you missed the patch =) [00:40:18] <mru> someone said gmail warns if you mention an attachment without actually attaching anything [00:40:46] <ramiro> mru: I have that enabled =) [00:41:15] <mru> do you have the full autopilot enabled? [00:41:24] <mru> http://mail.google.com/mail/help/autopilot/index.html [00:43:25] <saintd3v> mru: it's a labs feature [01:08:01] <CIA-24> libswscale: diego * r30954 /trunk/libswscale/ (utils.c swscale.c): AltiVec implies a PPC CPU, so there is no need to check for both. [06:26:36] <peloverde> kshishkov, I think I finally snapped or something because I started hacking on the AAC encoder again [06:26:59] <kshishkov> oh, welcome to dark side :) [06:27:08] * kshishkov is hacking BINKb decoder [06:28:44] <peloverde> I don't know if you heard but we found this in brussels: http://beeradvocate.com/beer/profile/3313/9157 [06:29:46] <kshishkov> have you sent a sixpack to RAD? [06:30:55] <peloverde> No, someone broke all the bottles on the table and we left in a hurry :) [06:31:20] <kshishkov> why? bar brawl is a half of fun [07:04:09] <saintd3v> peloverde: i'm pretty good at that subliminal messaging, aren't I :P [07:04:34] <peloverde> saintd3v, I guess so [07:04:56] <peloverde> I reached a point where i needed a break from PS [07:05:07] <saintd3v> hehe [08:23:05] <jermy> j-b: Yes, I have plenty of Panasonic P2 content [09:14:08] <j-b> jermy: I guessed so [09:42:47] * elenril kicks gnuplot [09:43:01] <elenril> anyone knows of a good app for 3d plots? [09:43:20] <kshishkov> gnuplot was rather fine [09:43:55] <elenril> gnuplot sucks at this [09:43:59] <kshishkov> IIRC all things like MathCAD can do 3D plots [09:44:32] * elenril wonders how hard would it be to import the data to blender ;) [09:44:51] <elenril> srsly, why can't they use normal spherical coordinates [09:45:15] <kshishkov> because they are not used even in geography [09:46:45] <kshishkov> maybe using octave as frontend helps? [09:46:57] <superdump> 'normal spherical coordinates'? [09:47:12] <kshishkov> superdump: in range -1.0..1.0 [09:47:19] <elenril> no [09:47:40] <superdump> r, theta, phi are the coordinates i always used in maths and physics [09:48:07] <kshishkov> x,y,z where x^2+y^2+z^2 <=1 is fine with me [09:48:11] <superdump> and afaik, theta and phi are (with a little translation maybe) used in geography [09:48:12] <jermy> j-b: We work with quite a number of post-production companies, so have quite a catalogue of random professional file formats [09:48:20] <elenril> x = r*sin(θ)cos(φ), y = r*sin(θ)sin(φ), z = cos(θ) [09:49:19] <elenril> gnuplot uses some other weird convention [09:53:22] <j-b> jermy: well, the only AVC-Intra files I have seen are from Panasonic, => my questions [10:07:34] * justlooking wonders if jermy can get these "post-production companies" to release some native original superHD and HD content pro clips under creative commons licences for ffmpeg/x264 use as there seems to be a lack of these around? [10:32:20] <kshishkov> hmm, if certain Haiku dev says "There are VNC servers for almost any OS out there, even BeOS." it looks like even he admits that BeOS sucks [10:39:34] <ramiro> yeah, that was funny... [10:40:52] <kshishkov> now we need Xiph devs to admit that Theora is not the best choice for streaming video [10:41:16] <elenril> it's not? [10:41:19] * elenril hides [10:41:50] * kshishkov sends full collection of RMS works to the hole where elenril is hiding [10:42:48] <CIA-24> ffmpeg: benoit * r22653 /trunk/libavformat/aviobuf.c: [10:42:48] <CIA-24> ffmpeg: Mask away AVSEEK_FORCE properly in some checks in url_fseek() [10:42:48] <CIA-24> ffmpeg: Patch by Tomas H?rdin $(name).$(s/?/a/ $(surname)) AT codemill DOT se [10:43:29] <KotH> o_0 [10:43:38] <KotH> email obfuscation reaching new heights ^^' [10:43:45] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BigNo [10:44:00] <kshishkov> KotH: nah, you have not seen my commits [10:44:00] <elenril> why don't we just md5sum them ;) [10:44:03] <twnqx> KotH: write a "fixer" plugin [10:44:18] <twnqx> that's autoreplacing with machine-readbale email addresses [10:45:14] <kshishkov> KotH: svn log libavcodec/rtmpproto.c for example [11:01:00] <KotH> you seem to have a sporty aproach [11:01:14] <kshishkov> no, got lazy [11:01:41] <kshishkov> in all days it was shell constructs and more complex C expressions [11:04:22] <Kovensky> <KotH> email obfuscation reaching new heights ^^' <-- we need to get to the level of those perl one-liner signatures on perlmonks :P [11:12:14] <CIA-24> ffmpeg: cehoyos * r22654 /trunk/libavformat/matroskaenc.c: Silence ridiculous gcc warning. [11:19:02] <jermy> justlooking: Ah, now that might be harder. We can generate plenty of Sony HDCAM-EX ourselves, but getting rights on other material would require some level of cooperation from clients [11:19:56] <jermy> on the other hand, we could probably get a reasonable chunk of test footage from the camera makers themselves - but it wouldn't be very exciting stuff [11:20:28] <jermy> we have at least 4 different sets of clips of carparks [11:22:25] <av500> jermy: it does not have to be movie content [11:22:43] <kshishkov> av500: should it be deadly boring though? [11:22:45] <av500> just something what we can use to play with, like e.g. moving traffic [11:22:49] <kshishkov> pross-au: G'day, cobber! [11:22:53] <av500> kshishkov: well, not a static scene [11:23:12] <pross-au> Evening [11:23:13] <jermy> Yeah, but it's so much nicer to have stuff that isn't just of somebody's desk [11:23:27] <kshishkov> pross-au: look at that crap - http://shishkov.homeunix.net/binkb.patch [11:23:39] <pross-au> WOOOOW [11:23:59] <kshishkov> it decodes it but it still looks like total mess [11:24:57] <kshishkov> still images are quite recognizable on samples at MPHQ [11:27:29] <pross-au> I will check it out [11:33:36] <pross-au> Nothing major kshishkov [11:34:13] <pross-au> Nice work [11:34:21] <kshishkov> patchiswelcome :) [11:34:26] <pengvado> in inter-predicted codecs, the data you get after subtracting the inter prediction is called "residual". [11:34:29] <pengvado> in LPC codecs, the data you get after subtracting LPC is called "residual". [11:34:32] <pengvado> if I do both, is there a canonical pair of names to distinguish the data after each step? [11:35:02] <kshishkov> data - all prediction = residual [11:35:49] <kshishkov> you can all it inter-decorrelated data or lpc-decorrelated data in intermediate steps though [11:36:55] <Dark_Shikari> pengvado: inter prediction and LPC? [11:37:15] <kshishkov> sounds good for subtitles [11:37:25] <pengvado> well, median isn't linear, but it's close enough to use the same names [11:37:54] <pengvado> otoh, I have considered real LPC too [11:38:24] <Dark_Shikari> kshishkov: more like PPMD [11:39:44] * kshishkov remembers those funny PPM schemes [14:38:53] <Dark_Shikari> holy fuck I hate autotools [14:39:00] <andoma> +1 [14:39:15] <kshishkov> use them in x264 and hate them even more [14:39:15] <Dark_Shikari> I'm trying to compile xzutils (successor to lzmautils) on windows to decompress a fucking file [14:39:21] <Dark_Shikari> it fails on cygwin with link errors [14:39:24] <Dark_Shikari> on mingw, it won't even configure [14:39:31] <Dark_Shikari> it says "i686-pc-mingw" isn't recognized as a host or build [14:39:45] <Dark_Shikari> and if I just pass -mno-cygwin as ld/cflags, it doesn't realize I'm building mingw and defaults back to cygwin [14:39:52] <Dark_Shikari> and then fails on build. [14:40:41] <Dark_Shikari> and of course they have no binaries on their site [14:41:35] <Compn> Dark_Shikari : what link errors on cyg? [14:41:42] <thresh> you can always safely say it is a cygwin problem [14:42:01] <Compn> Dark_Shikari : then find out what build name it wants for mingw by reading configure script or readme / install doc ? [14:42:10] <Dark_Shikari> Compn: no, the correct packages are installed [14:42:22] <Dark_Shikari> it's a link error against libintl [14:42:34] <Compn> ugh [14:42:48] * kshishkov has been hating autotools since the times he was on dialup and autocrap took up to 90% or package contents. And always required the latest version of autotools [14:42:52] <Compn> got a nix box with cygwin crosscompile ? [14:42:59] <Dark_Shikari> Compn: I'm not that insane [14:43:05] <Dark_Shikari> also, I just want to decompress a fucking file [14:43:07] <kshishkov> invoke gcc manually? [14:43:10] <Dark_Shikari> why do they have to use nonstandard formats like this [14:43:13] <Compn> what file ? [14:43:16] <Compn> format [14:43:18] <Dark_Shikari> it's a .xz file [14:43:26] <Compn> ah [14:43:27] <Compn> crazy [14:43:28] <Dark_Shikari> they should just use .7z like EVERYONE ELSE IN THE WORLD [14:43:39] <mru> and _that_ is a standard format??? [14:43:53] <mru> or is it just pkzip format in disguise? [14:43:59] <kshishkov> lzma is creeping to standard though [14:44:04] <kshishkov> mru: no, it's not [14:44:33] <mru> the pkzip format has a per-field field for compression type [14:44:43] <mru> would be trivial to define one for lzma [14:44:56] <kshishkov> mru: it's just another of your favourite "save diskspace by melting CPU" archiver. Decompression is very fast though [14:45:04] <mru> I know what lzma is [14:45:22] <mru> on its own, lzma is just a stream compressor [14:45:26] <Dark_Shikari> 7z at least has a cross-platform implementation [14:45:35] <Dark_Shikari> and is implemented by multiple programs [14:45:43] <mru> to create a proper archive, you need something more [14:45:45] <Dark_Shikari> xz is implemented by exactly one, which is not cross-platform [14:45:46] <kshishkov> mru: and 7z uses some filters to increase compression [14:45:47] <mru> like .tar.foo [14:45:54] <Dark_Shikari> mru: yeah, xz is like that too [14:45:58] <Dark_Shikari> it's like bz2, i.e. one file compression only [14:46:24] <mru> oh, xz is YET ANOTHER compression scheme? [14:46:33] <Dark_Shikari> it's lzma [14:46:35] <Compn> Dark_Shikari : what xz file is it anyways? can you get it in a diff format? :P [14:46:38] <mru> gaaaah [14:46:58] <mru> so how is it different from plain lzma? [14:47:10] <Dark_Shikari> mru: it's a container format [14:47:12] <Dark_Shikari> lzma is the codec [14:47:19] <Dark_Shikari> it's like '7z' or '.lzma' [14:47:25] <Dark_Shikari> except FUCKING ANNOYING [14:48:10] <Dark_Shikari> lets see if it works with mno-cygwin [14:48:23] <mru> just get a damn linux box already [14:48:24] <Dark_Shikari> i.e. compiled with cygwin as host, but with mno-cygwin as cflags/ldflags [14:48:26] <Dark_Shikari> aka massive fuckery [14:48:31] <Dark_Shikari> mru: that's not the issue, I have linux boxes [14:48:34] <Dark_Shikari> this is a 350 gigabyte xz file [14:48:40] <Dark_Shikari> it will decompress to my entire external hard disk [14:48:41] <mru> whoa [14:48:44] <Dark_Shikari> I can't send it over the internet [14:48:56] <twnqx> why not? [14:49:00] <Dark_Shikari> my upload is 50kbps [14:49:01] <mru> boot a livecd then [14:49:06] <twnqx> torrent it :D [14:49:09] <mru> 50k??? [14:49:23] <twnqx> yeah, it might take some time :P [14:49:27] <Dark_Shikari> er, 50KBps [14:49:34] <Dark_Shikari> woot, mno-cygwin build failed too [14:49:35] <mru> oh, 500k [14:50:13] <kshishkov> Dark_Shikari: maybe try invoking gcc directly to link it, I did that many times [14:50:13] <Dark_Shikari> fuck you XZ, claiming that your shit works on windows [14:50:14] <Dark_Shikari> it doesn't. [14:50:27] <mru> well, I still thought my 1.2Mbps was low [14:50:35] <Dark_Shikari> I have 100mbit down [14:50:50] <mru> what bizarre kind of connection are you on? [14:50:54] <Dark_Shikari> university [14:51:09] <mru> I'm getting 18M down at the moment [14:51:26] <mru> at my university connections were 100M both ways [14:51:44] <mru> and that was 10 years ago [14:51:55] <mru> shit, I'm getting old [14:51:56] <kshishkov> 1mbps/512kbps here - my connection is more symmetric than yours! [14:52:44] <kshishkov> mru: your university was Swedish, so 100M/100M may be low even for those times [14:53:08] <Dark_Shikari> oh. the xz file is only 32gb [14:53:11] <mru> it obviously sat directly on the SUNET backbone [14:53:11] <Dark_Shikari> it _decompresses_ to 350gb [14:53:28] <Dark_Shikari> oof. this may take a while [14:53:33] <mru> but the accessible connections were all 100M [14:53:39] <Dark_Shikari> in fact, screw it, I'll pipe directly to x264 [14:53:44] <Dark_Shikari> I don't want to write that much data to disk [14:54:21] <mru> what is this file? [14:54:30] <Dark_Shikari> lossless 1080p source [14:54:34] <mru> ultra-high-grade porn? [14:55:55] <kshishkov> mru: since it's in .xz archive, pornography lies in the process of extracting it [15:21:40] <ramiro> mru: what do you think about making configure detect arch/os based on cross-prefix? [15:21:54] <mru> rejected [15:21:59] <ramiro> why? [15:22:07] <mru> I have systems that don't use a cross-prefix [15:22:17] <mru> it's just a convenience [15:22:27] <mru> and there are no hard rules about it [15:46:56] <BBB___> so what's this ohloh kudos system? [15:47:02] <BBB___> oh my nick is screwy again [15:48:17] * kshishkov does not care since "oh loh" translates into Russian as "aww, sucker" [15:49:18] <kshishkov> and check your IRC client, maybe it sets "screw nickname on startup" for this channel [15:49:51] <BBB> no, there's another user BBB I think [15:49:54] <BBB> I keep ghosting him [15:49:56] <BBB> he keeps coming back [15:50:29] <mru> then you need to /exorcise him [15:51:11] <roozhou> kshishkov: When will you fix RV40 deblocking issues? [15:51:27] <kshishkov> could be some other instance from your client messing [15:51:45] <av500> or janneg's BBB becomes selfaware.. [15:52:00] <kshishkov> roozhou: never. It deblocks fine and bitexact for I/P frames IIRC [15:52:23] <kshishkov> and I don't have any power over Real to make them fix it either [15:52:23] <roozhou> kshishkov: I mean B frames [15:52:49] <kshishkov> and what's visually wrong with them? [15:54:53] <roozhou> artifact in flat area [15:58:30] <kshishkov> hmm, got images? [15:59:15] <roozhou> of course, i can make screenshot from almost all my rmvb collections [16:03:00] <kshishkov> it may be not related to deblock filter at all [16:04:08] <kshishkov> B-frames use weighted prediction (i.e. like H.264) but someone was too lazy to implement those functions for lavc RV3/4 decoder [16:04:36] <kshishkov> it can be usually spotted during fade ins or fade outs [16:09:18] <DonDiego> kshishkov: you lazy lout, you! [16:09:37] <kshishkov> yep, me! [16:10:07] <kshishkov> you can ask Dark_Shikari to RE those funcs and write SIMD counterparts for them too [16:12:24] <kshishkov> personally I don't want to touch for next N years at least [16:12:38] <DonDiego> touch what? [16:12:52] <kshishkov> RV3/4 decoder [16:17:26] <av500> N := 1 [16:18:04] <kshishkov> N is a natural number [16:18:12] <kshishkov> can be indefinitely big [16:22:05] <kshishkov> DonDiego: you can make it a small task if you want ;) [16:22:23] <DonDiego> just add it to the wiki quickly [16:22:43] <DonDiego> you know exactly what you are talking about [16:33:45] <kshishkov> added [16:44:01] <BBB> spyfeng: good work (your curernt commits)! [16:44:16] <BBB> I bet you can get that file under 800 lines of code [16:46:07] <BBB> oh darn it, you're at 693 lines of code already [16:46:14] <BBB> what was the original again? [16:46:52] <BBB> 1305 lines of code [16:46:55] <BBB> you halved it! [16:46:57] <BBB> good job [16:47:42] <kshishkov> it all depends on source code and destination coder quality ;) [16:47:52] <BBB> I think he's ok [16:47:53] <BBB> :) [16:48:00] <BBB> reviewthe patch on the mailinglist [16:55:27] <cs011> Hi, there, is ffmpeg-mt stable, or it still has timpestamp problems with H.264? [16:57:48] <astrange> timestamp problems in what program? [17:00:06] <cs011> We had a discussion over Videolan forums http://forum.videolan.org/viewtopic.php?f=2&t=42328&start=75#p235886 about why VLC doesn't support multithreaded like Mplayer does. Videolan team claims ffmpeg-mt has many timestamps problems [17:00:26] <mru> could it be that vlc has timestamp problems? [17:00:46] <astrange> sounds like vlc's problem [17:01:12] <cs011> VLC is claiming that they are still using the singlethreaded version as to avoid timestamp problems. [17:01:17] <cs011> So it doesn't have that. [17:01:19] <astrange> -mt has different decoder delay, but h264 already has different decoding delay [17:01:26] <astrange> see ffmpeg -strict 0 vs -strict 1 [17:01:40] <astrange> if it can't handle one it can't handle the other [17:02:19] <astrange> the api for tracking timestamps (has_b_frames and reordered_opaque in avcodeccontext) works right [17:02:22] <astrange> in both cases [17:03:05] <cs011> I don't know if it's the right place to say that, but multicore support in VLC had been the subject of an endless blame game [17:03:23] <mru> our blame is stronger [17:04:28] <cs011> Videolan team blames the ffmpeg team for ffmpeg-mt being allegly "broken" (see link, and the previous page), and ffmpeg says that ffmpeg-mt is fine, and it's VLC fault [17:04:36] <kierank> just ask j-b [17:05:13] <cs011> Here is the start of the soap opera http://forum.videolan.org/viewtopic.php?f=2&t=42328&start=60#p225039 [17:05:15] <mru> we often get blame when we break people's assumptions which were never promised to be true [17:05:58] <BBB> we should merge ffmpeg-mt no? [17:06:10] <mru> have all problems been fixed? [17:06:14] <astrange> yes, i'm working on it [17:06:31] <BBB> lol :) [17:06:44] <mru> last I heard there were _other_ problems [17:06:48] <mru> nothing to do with timestamps [17:07:14] <Kovensky> like crashing [17:07:21] <Kovensky> :> [17:07:36] <astrange> vp3 and dependencies are finished now [17:07:48] <astrange> i don't have any crash reports [17:08:01] <Kovensky> you fixed those [17:08:09] <astrange> about h264 and -strict, that only applies to files without num_reorder_frames set [17:08:12] <astrange> http://astrange.ithinksw.net/ffmpeg/camp_mot_mbaff0_full.264 here's one [17:08:12] <Kovensky> (the theora seeking one was the last one IIRC) [17:08:22] <elenril> svq3 refuses to play anything with more than one thread [17:09:07] <cs011> @mru: Then, it's probable those "other_problems" that keep the VLC teams from going multithreaded [17:09:46] <astrange> [svq3 @ 0x10107ce00]SVQ3 does not support multithreaded decoding, patch welcome! (check latest SVN too) [17:09:52] <astrange> huh, why doesn't it just ignore it [17:09:54] <cs011> The stability of VLC (since version 0.99) has been their pride, so they don't want to see it crashing because ffmpeg-mt has "other_problems" [17:09:55] <elenril> yes, this [17:10:11] <CIA-24> ffmpeg: alexc * r22655 /trunk/libavcodec/aaccoder.c: [17:10:11] <CIA-24> ffmpeg: aacenc: Merge quantize_band_cost() with quantize_and_encode_band(). [17:10:11] <CIA-24> ffmpeg: If these two functions aren't matched results may be unexpected. [17:10:21] <elenril> dunno, the line was added by michael, log said it fixes something [17:10:29] <superdump> \o/ [17:10:42] <superdump> peloverde: working on ffaacenc now? :) [17:11:02] <BBB> \o/ indeed [17:11:17] <BBB> what happened to that guy applying for the wvp2 soc task? [17:11:18] <peloverde> superdump, Last night I was sick of PS and wanted something different... but back to PS today [17:11:26] <superdump> :) [17:11:31] <superdump> how is PS going [17:11:34] <superdump> ? [17:12:14] <peloverde> I think I can still get it done within a week from today, which was my original goal [17:12:33] <peloverde> (otoh at one point I thought I could get SBR done for xmas) [17:12:40] <Kovensky> after PS, we'll only need LATM to drop faad2 from mplayer :3 [17:13:53] <BBB> I'm wondering, theoretically, how bad it'd be to have to RE some codec from ffmpeg if you didn't have the source [17:13:58] <BBB> just purely theoretical question [17:14:12] <BBB> would it be better or worse than a dll in windows? [17:14:31] <BBB> or compare faad2 vs ffaac [17:14:34] <BBB> which would be easier to re? [17:17:51] <mru> good ffmpeg code is probably easy to RE [17:18:58] <astrange> write-combining makes it harder to figure out structure sizes [17:19:15] <astrange> other than that, probably easy as there's little code duplication [17:20:54] <cs011> When will ffmpeg-mt be without problems? [17:21:26] <cs011> When this happens, shouldn't you merge ffmpeg with ffmpeg-mt [17:21:26] <cs011> ? [17:21:42] <astrange> when it's merged it will have only as many problems as the rest of it [17:22:24] <cs011> @astrange Any estimate when this might happen [17:22:26] <cs011> ? [17:22:31] <cs011> In a year? A decade? [17:22:43] * Kovensky thinks a decade is pretty long [17:22:53] * Kovensky goes find his Captain Obvious custome [17:23:02] <kierank> cs011, same day as duke nukem comes out [17:23:37] <peloverde> When Opera mini is accepted to the app store [17:23:44] <astrange> it already doesn't have the problems you think it does though, so that's good [17:25:52] <elenril> Host en.wikipedia.org not found: 3(NXDOMAIN) lolwut? [17:26:01] <DonDiego> astrange: so you have theora multithreading finished? [17:26:30] <BBB> lu_zero: you'll mentor josh, right? [17:26:53] <pasteeater> elenril: i too can not connect to en.wik.. [17:26:53] <DonDiego> Yuvi: you around? [17:27:18] <DonDiego> Yuvi: siretart and i would love to get a quick status update for the theora and ogg stuff for 0.6... [17:28:36] <peloverde> Any idea how we are doing student count wise? [17:29:18] <j0sh> BBB, with rtsp over tcp in ffmpeg now, i think http tunneling for gsoc should be pretty easy, don't you think? [17:43:53] <BBB> j0sh: hopefully [17:44:02] <BBB> j0sh: but I haven't ever looked at it [17:44:12] <BBB> j0sh: btw ffmpeg always supported tcp as transport [17:44:25] <BBB> j0sh: the recently committed patch was for tcp in the rtsp _muxer_, not _demuxer_ [17:48:08] <BBB> wbs: I'm almost ok with patch #1 for httpauth [17:49:58] <BBB> wbs: also, you didn't document auth.h yet (with RFC references, and also some doxy in the DigestParams struct please?) [17:50:04] <cs011> To put it bluntly: Are you intending to use the Google SoC opportunity to perfect multithreading for ffmpeg, or are you going to waste it (again) on useless network-related ideas? [17:50:22] <cs011> It's not like Google will fund Soc forever [17:50:33] <av500> they are tight with money? [17:50:39] <j0sh> cs011, network-related stuff is not useless for all of us :) [17:50:52] <cs011> Sooner or later, they will have their own products, and they will eventually stop funding ffmpeg [17:50:54] <kshishkov> and some devs are still on single-core CPUs [17:50:59] <wbs> BBB: ah, forgot to add the rfc references [17:51:05] <kshishkov> good luck reimplementing FFmpeg [17:51:06] <cs011> Just like they will stop funding Firefox now that they have Chrome [17:51:13] * elenril thinks obvious troll is obvious [17:51:19] * av500 agrees [17:51:42] <j0sh> BBB, reading the apple specs for quicktime http streaming. seems straightforward [17:51:44] <cs011> They don't re-implement it, they take the code and make their own fork. Then they put it on embedded devices This is how google rolls. [17:51:54] <av500> anyway, there is so much metadata work to be done 1st.... [17:51:55] <cs011> Chrome, Android etc [17:52:11] <wbs> BBB: and will add more doxy to the header - forgot to add the rfc reference in the last round [17:52:12] <av500> cs011: still troll [17:52:13] <DonDiego> we shall see [17:52:42] <kshishkov> forking is about devs - that's why ffmbc may live and your fork will wither [17:52:46] <BBB> j0sh: straightforward would be cool [17:52:51] <elenril> av500: yeah, metadata ftw! [17:52:53] <j0sh> BBB, i think that'll be one of my tasks. rtcp looks like another area that could use improvement [17:53:14] <kshishkov> rtmp too [17:53:15] <av500> actually, google decided to write their own mediaplayer for android now [17:53:20] <BBB> wtf @ network troll [17:53:38] <cs011> @av500 Were did they based it on? [17:53:44] * elenril looks at himself still talking when there's chapters to do [17:53:48] <av500> cs011: no idea, did not look into it yet [17:53:55] <astrange> google uses opencore or something for android [17:53:57] <av500> they call it "stagefright" [17:54:03] <astrange> i've looked and the code is absolute nonsense [17:54:03] <av500> astrange: not for long any more [17:54:18] <cs011> Where can I find a list of all the software in Android? [17:54:25] <cs011> What media player it has, what browser etc [17:54:33] <av500> but I dont know if stagefright is to be used together with opencore [17:54:45] <av500> cs011: hmm, no idea, that code is locked away, no? [17:55:06] <cs011> @av500 Android is supposed to be opensource [17:55:39] <j0sh> cs011, android sdk would be a good place to start :) [17:56:01] <cs011> Where can I get the source for Android? [17:56:13] <BBB> cs011: wrong channel [17:56:19] <BBB> go email support@google.com? [17:56:32] <cs011> Sorry [17:56:43] <av500> cs011: google also does a search engine: http://www.google.com [17:56:58] <BBB> they say that search engine is pretty decent [17:57:04] <kshishkov> not in China ;) [17:57:15] <BBB> also, we're about to start discussing ffmpeg development again here, how about that? [17:57:32] <j0sh> would rtmp enhancements also be acceptable for gsoc? sounds like that's be useful to people too [17:58:22] <j0sh> i dont know how long each of these tasks is gonna take, the theora depayloader was only about a week of on-off work [17:58:24] <cs011> Why don't you give priority to ffmpeg-mt? [17:58:34] <av500> why dont you? [17:58:36] <cs011> Everything else is minor, everybody says [17:58:36] <av500> fund it [17:59:10] <kshishkov> BBB: this channel actuall was created only for devs to chat and not hear "how can I recode stuff to Fl$*!" question [18:00:08] <jai> lol [18:00:14] <av500> \\\ooo/// [18:00:20] <BBB> my apologies [18:00:22] <elenril> BBB++ [18:01:08] <BBB> j0sh: you could do that... I would sure as hell be in favour of it, but it'd be a different set of developers that know that protocol [18:01:37] <kshishkov> BBB: here's a bit to you - WMV decoding DLLs usually have several identical or near-identical get_bits() in a single .dll [18:01:59] <BBB> j0sh: but since michael appears to be ok with an optional dependency on libssl, rtmpe would be cool [18:02:12] <kshishkov> weren't you a mentor for RTMP last summer? [18:02:15] <BBB> kshishkov: that's true [18:02:15] <av500> mru: http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/ [18:02:18] <BBB> that also [18:02:24] <BBB> kshishkov: weren't you the student implementing it? [18:02:42] <kshishkov> BBB: that's true [18:04:42] <j0sh> BBB, i can investigate rtmpe. will probably be a good stretch goal after other tasks have been done [18:05:15] <BBB> well, it'll keep you busy after soc is completed :) [18:05:24] <j0sh> true that [18:05:38] <kshishkov> especially with libssl reimplementation ;) [18:05:54] <kshishkov> (why not reimplement it if we can?) [18:06:11] <j0sh> fflibssl would be for 2011 gsoc, heh [18:06:49] * j0sh out for lunch [18:06:52] <BBB> anything that duplicates code ^d^d improves ffmpeg is good [18:06:53] <kshishkov> could be [18:07:25] <kshishkov> we don't duplicate code [18:07:49] <elenril> we're preparing for ffos [18:07:58] <kshishkov> on ffcpu [18:08:40] <av500> using fflaws of ffphysics [18:09:23] <elenril> ffftw! [18:09:45] <av500> fffeierabend! [18:09:52] <twnqx> lol [18:09:58] <twnqx> av500: i got some of the chips [18:10:03] <twnqx> via TI's sample program \o/ [18:10:08] <twnqx> for free even :P [18:11:31] <_av500_> :) [18:13:28] <kshishkov> twnqx: so when FFmpeg is ported on them? [18:13:48] <twnqx> uh [18:13:52] <twnqx> to voltage regulators? :S [18:15:27] <kshishkov> why not? it can manipulate input after all [18:15:36] <twnqx> lol [18:15:42] <DonDiego> oh [18:15:46] <DonDiego> BBB: first kick? [18:15:47] <DonDiego> :) [18:21:54] <DonDiego> wikipedia is down [18:22:12] * DonDiego awaits world's end [18:22:41] <kshishkov> once even google.com wasn't resolving [18:23:54] <BBB> DonDiego: second :) [18:24:02] <drv> wikipedia works here, somebody said just DNS was broken somewhere? [18:25:26] <elenril> yeah, i get nxdomain for *.wikipedia.org [18:25:36] <elenril> wikipedia.org itself works fine though [18:25:46] <kshishkov> works here again [18:27:32] <drv> heh, en.wikipedia.org is a CNAME pointing to a CNAME here [18:27:33] <drv> how ugly [18:27:55] <kshishkov> drv: you can work on bink-b decoder [18:28:15] <drv> are there any samples other than that heroes game? [18:28:27] <drv> i had a look at it once, audio is different from current versions too [18:28:51] <kshishkov> video too [18:29:07] <drv> yep [18:29:28] <drv> maybe someday, still have things on my TODO list though ;) [18:29:35] <drv> flashsv2 decoder is kicking around somewhere [18:29:44] <kshishkov> anything completed? [18:30:20] <drv> not yet, was trying to get a working test for the other zlib-priming mode in the encoder, but haven't yet [18:37:17] <mru> av500: I disagree with that so-called guru on quite a few points [18:37:24] <mru> including his opinions on gcc [18:37:38] <mru> there are plenty of faults with gcc, and he manages to miss all of them [18:37:44] <kshishkov> FATE disagrees too [18:38:16] <mru> I've been planning to write a blog post in defence of gcc actually [18:41:35] <CIA-24> ffmpeg: rbultje * r22656 /trunk/libavformat/ (asf.c asf.h asfenc.c): [18:41:36] <CIA-24> ffmpeg: Move put_le16_nolen() to asf.c and give it a ff_ prefix. This way, it is easier [18:41:36] <CIA-24> ffmpeg: to share it with e.g. MMS. [18:41:36] <CIA-24> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [18:42:14] <BBB> so what does an IP of 0xc0a80081 mean? [18:42:21] <BBB> is that 127.0.0.1? [18:42:28] <BBB> probably not [18:42:31] <kshishkov> no [18:42:46] <kshishkov> 192.168.0.129 [18:42:49] <astrange> 192.168.0.129 [18:43:02] <drv> just take each octet and convert to decimal [18:45:25] <peloverde> If you ever watch /The Net/ staring Sandra Bullock, there is an IP with an octet greater than 255... awkward [18:45:47] <bilboed-pi> peloverde, http://www.echopic.com/7vh :) [18:46:54] <drv> i never knew florida was made of PCB [18:47:09] <peloverde> blol [18:48:26] <kshishkov> probably black is for swamps [18:48:35] <BBB> wbs: rtcp/bye was a qualification task last year [18:48:40] <BBB> wbs: it didn't get far, unfortunately ;) [18:48:47] <wbs> BBB: oh great ;P [18:49:03] <wbs> BBB: the bugfix in the follow-up thread should be quite obvious, right? [18:49:58] <BBB> if ret<0)return ret; [18:50:03] <BBB> then it's ok, feel free to apply [18:50:19] <BBB> (I want to prepare the code for forwarding AVERROR() conditions to caller [18:50:25] <BBB> eventually [18:50:28] <wbs> ah, of course, yeah [18:50:41] <j-b> cs011 as opposite to you, I have patches for support of ffmpeg-mt in VLC. [18:51:06] <j-b> especially to export the needed extra information [18:51:09] <DonDiego> j-b: that nick was already kicked :) [18:51:15] <j-b> oh, shit [18:51:43] <astrange> do i need to see these patches? [18:51:54] <j-b> astrange: those were never showed to you ? [18:51:55] <j-b> O_o [18:51:59] <j-b> is this a joke? [18:52:07] <astrange> nope [18:52:10] <j-b> OMG [18:52:15] * j-b needs to kill a few people [18:52:21] * j-b will be back in 5minutes [18:52:58] * mru lends j-b the shotgun [18:53:16] <CIA-24> ffmpeg: mstorsjo * r22657 /trunk/libavformat/rtsp.c: Handle errors returned from ff_rtsp_read_reply in udp_read_packet properly [18:56:24] <_av500_> mru: i do not agree with this "highly paid consultat"(tm) [18:57:11] * kshishkov does not trust consultants much at all [18:57:37] <mru> that's overgeneralising [18:57:44] <mru> I've worked with a few very good ones [18:58:21] <kshishkov> their share in total number of consultants you know being? [18:58:43] <kierank> presumably only "medical consultants" [18:58:53] <mru> I'm talking about software [18:59:21] <kshishkov> I've been a consultant too [18:59:24] <mru> there are different kinds of software consultants [19:00:11] <mru> the ones that just blather about "process" and make you buy some expensive tools (which they likely get a commission on) are useless [19:00:24] <kshishkov> synergy! [19:00:27] <mru> those that have some rare expertise and actually solve the problem for you are good [19:01:06] <Dark_Shikari> [C[C[C[C[C [19:01:20] <Dark_Shikari> lol, running on local line editing is hilarious [19:01:46] <Dark_Shikari> apparently pressing "right" 6 times will move right 6 times... and then send the special characters too [19:02:08] <mru> yep [19:05:33] <Kovensky> irssi loves sending special characters when you have high ssh latency [19:05:39] <Kovensky> because it think you're pasting shit [19:05:40] <Kovensky> >_> [19:05:54] <mru> I've seen that [19:06:09] <mru> but only when there's been an interruption of a few seconds [19:06:27] <Kovensky> happens to me a lot when I'm not @ home [19:06:54] <mru> I get it mainly on the phone [19:06:56] <Kovensky> here I use xchat with several tunnels to irssi-proxy; elsewhere I use ssh directly [19:07:18] <Kovensky> and the place I can access the fastest internet is @ college, which has... a 2mbit tube for the whole campus [19:07:35] <Kovensky> fabulous speeds there <_< [19:08:04] <Kovensky> here @ home I have a 1mbit line split among 6 computers ._. [19:08:11] <kshishkov> ours had 32kbps at our department back in 2003 [19:09:13] <Kovensky> internet @ college is p. unstable too, it's often down (the domain controller is often down too, so it's also garbage internally) [19:09:17] <drv> hm, school i used to attend reportedly had an OC-48 just for the dorms [19:09:26] <Kovensky> and professors randomly turn routers off >_> [19:09:32] <Kovensky> drv: :O [19:09:39] <drv> dunno if it was actually true though :P [19:10:26] <Kovensky> sometimes the latency there is so high it takes like 2 minutes after I input text until it is echoed by ssh [19:10:26] <kshishkov> students here haven't seen internet at uni at all, dorms have something though [19:11:16] <Kovensky> we also are forced to use a severely locked down win2k with the wrong resolution (LCD native res is 1024x768 or 1280x1024 on the bigger ones; all computers are forced to 800x600) [19:11:26] <Kovensky> the gamma settings are also bad [19:11:41] <kshishkov> we have CRTs at 60Hz here [19:11:51] <Kovensky> they used to have CRTs @ 60hz there too [19:11:57] <Kovensky> but they replaced all CRTs by LCDs [19:12:20] * Kovensky has seen K6s running on LCDs just because "they look modern" [19:12:40] * kshishkov concludes that Brazil is a richg country [19:13:03] <Kovensky> lol [19:13:52] * Kovensky concludes that the only reason his college has all this luxury is because the owner/CEO is a friend of the governor's brother-in-law (and the governor is the daughter of the local political overlord) [19:14:46] <Kovensky> the southeast region (São Paulo mostly) however is rich indeed [19:15:17] <Kovensky> but the distribution is awful (IIRC one of the worst in the world) [19:15:38] <kshishkov> same here [19:16:06] <kshishkov> Dontesk region is rich, current president and mafia come from it too [19:16:12] <kshishkov> *Donetsk [19:26:48] <_av500_> mru: i dont say all consultants are bad either [19:27:52] <_av500_> but his: "'m expensive, so expensive are teh tools" annoys me a bit [19:28:22] <kshishkov> maybe it's the other way round [19:28:50] <kshishkov> here consulting is often viewed as a reason not to work [19:29:30] <_av500_> as long as ppl payfor it... [19:30:14] <kshishkov> become an IP lawyer then [19:32:34] <_av500_> cannot, Id sue myself the 1st thing and lose... [19:32:54] <kshishkov> but all your money will go to you [19:33:03] <mru> he already has his money [19:33:18] <_av500_> no, govt has my money [19:34:12] <mru> didn't we talk about that yesterday? [19:34:43] <kshishkov> _av500_: you're lucky, here you're not supposed to have money anyway [19:34:45] * _av500_ must have missed it [19:35:40] <mru> kshishkov: hmm? wasn't that communism? [19:35:45] * Kovensky made an edit to wikipedia to fix an typo and intentionally put 'fox typo' on the edit reason field [19:35:48] <Kovensky> :3 [19:36:07] <Kovensky> who was it that foxed the original typo, reimar? [19:36:09] <kshishkov> mru: no, in communist state you're not supposed to know about money at all [19:36:18] <_av500_> Kovensky: you missspelled it: fix tzpo [19:36:25] <CIA-24> ffmpeg: siretart * r22658 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:36:25] <CIA-24> ffmpeg: Check validity of channels & samplerate. [19:36:25] <CIA-24> ffmpeg: This may be security relevant. [19:36:25] <CIA-24> ffmpeg: Based on 2 patches by chrome. [19:36:25] <CIA-24> ffmpeg: backport r19975 by michael [19:36:39] <Kovensky> _av500_: wtf, what kbd layout do you use D: [19:36:58] <mru> qwertz I'd suppose [19:37:01] <mru> silly germans [19:37:10] <_av500_> azerty ftw! [19:37:26] <mru> where's awertz? [19:37:26] * Kovensky uses US layout with compose key [19:37:42] <Kovensky> I tried using dvorak in 2008 but gave up; was too lazy to type slowly [19:37:44] <kshishkov> mru: Alsase [19:38:04] <mru> dvorak is stupid [19:38:19] <mru> the arrangement of the letters makes very little difference [19:38:19] <kshishkov> Russians had "jcuken" layout [19:38:33] <mru> dvorak has been thoroughly debunked [19:38:44] <mru> what matters is where the non-alnum symbols are [19:38:59] <Kovensky> I have also used .se layout for a while, for the lulz [19:39:04] <mru> those that are frequently used in your (programming) language of choice of course [19:39:10] <mru> .se is impossible for coding [19:39:20] <Kovensky> heh [19:39:32] <Kovensky> I don't see me switching from US+compose any time soon [19:39:37] * _av500_ has := on F5 :) [19:39:37] <Kovensky> I can type whatever I want <3 [19:39:49] <Kovensky> _av500_: you dirty pascal programmer [19:39:49] <kshishkov> Kovensky: and I used it for typing Swedish and once because I had Swedish notebook for a while [19:39:58] <Kovensky> heh [19:40:04] <Kovensky> physically, my keyboard is br-abnt2 [19:40:10] * mru uses something loosely based on US + some mode_switch combos for swedish etc [19:40:23] * kshishkov uses pure US mostly [19:40:25] <Kovensky> due to my insistence on US+compose, I can't type on any other computer but mine >_> [19:40:26] <mru> physically, mine is blank [19:40:46] <kshishkov> we know [19:41:24] <Kovensky> br-abnt moves around too many important keys just to put diacritics on the right of the alnum block ._. [19:41:28] <mru> it keeps visiting relatives from borrowing my computer to read their viruses [19:41:31] <Kovensky> (and the ç) [19:41:37] <Kovensky> mru: heh [19:42:00] <DonDiego> BBB: rtpdec.h:143: warning: function declaration isn't a prototype [19:42:07] <_av500_> they cant click at virus? [19:42:14] <DonDiego> lu_zero: that also goes for you i guess :) [19:42:17] <kshishkov> mru: what about installing VMS for guest OS for their convenience? [19:42:33] <mru> on the old alpha? [19:42:58] <kshishkov> so it's IE3 under NT for them? [19:43:59] <mru> they can bring their own netbook [19:58:02] <wbs> BBB: I don't think changing auth types to weaker ones actually happen in practice - ok to skip support for that, removing the second auth_type variable? [19:59:15] <CIA-24> ffmpeg: vitor * r22659 /trunk/libavformat/nut.c: [19:59:15] <CIA-24> ffmpeg: Fix warning: [19:59:15] <CIA-24> ffmpeg: libavformat/nut.c: In function ?ff_nut_free_sp?: [19:59:15] <CIA-24> ffmpeg: libavformat/nut.c:80: warning: passing argument 4 of ?av_tree_enumerate? from incompatible pointer type [19:59:15] <CIA-24> ffmpeg: ./libavutil/tree.h:92: note: expected ?int (*)(void *, void *)? but argument is of type ?void (*)(void *, void *)? [20:10:26] <BBB> wbs: yes [20:10:31] <BBB> wbs: that's what I was hoping for ;) [20:10:46] <wbs> BBB: ok with me, too. simplifies stuff nicely :-) [20:11:31] <BBB> I think most of patch #1 was ok, you can post if you want and then I'll probably ok it [20:11:39] <BBB> then I have to review #3/#4 [20:11:53] * BBB kicks lu_zero into reviewing [20:17:56] <wbs> BBB: there, new series, with hopefully all of it fixed [20:18:19] <wbs> #1 is a bit larger now, when the realm="" parsing has been included for basic, too [20:20:43] <BBB> is there a particular reason that you're av_strdup()ing before copying the realm? [20:23:12] <BBB> I suppose it's because you write into it right? [20:23:39] * BBB replies [20:25:59] <wbs> the parser needs to be able to write into the string, for simplicity when parsing e.g. quoted strings and such [20:26:46] * BBB goes fiddle [20:56:59] <BBB> wbs: see reply, let's try to do this without any extraneous copies [20:58:28] <wbs> BBB: yeah, it struck me too that there's quite a bit of almost-similar parsing code in there [20:58:48] <BBB> probably even my code is far from optimal [20:58:55] <BBB> but should at least be a little better [20:59:06] * BBB goes take a break and look at it again in +/- 5 minutes [21:00:44] <BBB> also my callback_get_buf() is missing key and len as parameters to be used for strncmp()s [21:01:22] <BBB> the idea is that you can do a series of if (!strncmp(key, "realm=", len)) { *dest=realm; *dest_len=sizeof(realm); return;} etc. [21:13:17] <wbs> BBB: hmm, that's a relatively good idea. the choose_qop function needs to be modified for this to work, but except for that, it seems doable [21:16:37] <BBB> cool [21:17:01] <wbs> and there are a few of the loop conditions that may need tweaking, but I got the idea :-) [21:18:39] <BBB> yeah the pseudocode was a little rough [21:37:56] <wbs> BBB: any preference for formatting of the strncmp lines in callbacks? [21:38:06] <wbs> i.e., either this: [21:38:06] <wbs> } else if (!strncmp(key, "qop=", key_len)) { [21:38:06] <wbs> *dest = digest->qop; *dest_len = sizeof(digest->qop); [21:38:20] <wbs> or this: [21:38:24] <wbs> } else if (!strncmp(key, "qop=", key_len)) { [21:38:24] <wbs> *dest = digest->qop; [21:38:24] <wbs> *dest_len = sizeof(digest->qop); [21:38:37] <wbs> the former uses less lines, the latter is a bit more readable [21:39:06] <BBB> latter is better imo [21:39:36] <BBB> oh boy I have like 10 unreviewed patches [21:49:26] <mru> BBB: that's nothing, I have at least 10 _unstarted_ projects [21:49:55] <BBB> oh I have an uncounted number of those [21:50:00] <BBB> uncountable, also [21:50:11] <mru> dang, beat me to it [21:51:18] <BBB> :) [22:01:08] <BBB> wbs: in #1, remove the if (!params) return in parse_key_value() [22:01:14] <BBB> that shouldn't be needed [22:03:10] <BBB> also, your else at the bottom doesn't handle escaped chars [22:03:48] <BBB> for (; *ptr && *ptr != '\"'; ) { -> no init / incr, so make it a while [22:04:00] <BBB> almost right :) [22:17:04] <BBB> oh, and wbs, people here generally dislike '\0', I'm not sure why, but try to use 0 instead [22:17:13] <BBB> I keep making that mistake also [22:25:41] <wbs> BBB: removed the unnecessary if. the else case shouldn't handle escaped chars, they're only allowed within quoted strings iirc [22:32:55] <CIA-24> ffmpeg: mstorsjo * r22660 /trunk/libavformat/ (httpauth.h Makefile http.c httpauth.c): [22:32:55] <CIA-24> ffmpeg: Split out http authentication handling into a separate file [22:32:55] <CIA-24> ffmpeg: This prepares for adding support for more authentication methods [22:39:37] <CIA-24> ffmpeg: lu_zero * r22661 /trunk/libavformat/rtsp.c: Issue a warning if the received CSeq isn't the expected one [22:44:55] <CIA-24> ffmpeg: vitor * r22662 /trunk/libavformat/nutdec.c: [22:44:56] <CIA-24> ffmpeg: Fix warnings in NUT demuxer: [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c: In function ?read_seek?: [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c:862: warning: passing argument 4 of ?av_tree_find? from incompatible pointer type [22:44:56] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?void **? but argument is of type ?struct Syncpoint **? [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c:871: warning: passing argument 4 of ?av_tree_find? from incompatible pointer type [22:44:57] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?void **? but argument is of type ?struct Syncpoint **? [22:46:23] <BBB> wbs: if you can quote the rfc on that, patch ok with me [22:47:41] <wbs> BBB: the only non-quoted values are algorithm and stale, which have fixed, nonescaped values [22:47:50] <BBB> ok [22:47:52] <BBB> then it's fine [22:47:56] <BBB> I see you already applied it ;) [22:48:43] <BBB> #2 should be rather small, but don't forget Michael maintains that file so make sure he's ok [22:48:48] <BBB> so no inline if()s etc. :) [22:49:07] <BBB> sth. like table = lowercase ? 'abcdef' : 'ABCDEF'; and then use that [22:49:18] <BBB> and it should of course be a separate patch [22:49:24] <wbs> yeah, did something like that [22:49:25] <BBB> bonus points if you remove the hack in rdt.c ;) [22:49:31] <wbs> I did :-) [22:49:50] <BBB> \o/ [22:51:05] <BBB> so I suppose I should now review the rtsp patch? [22:51:39] <BBB> can you re-send them after #2 is done? [22:51:45] <wbs> yes, will do [22:52:29] <wbs> the first one of the rtsp patches is dead simple, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100324/6534c7... [22:52:48] <BBB> bonus point: if you rename your variable 'table' into 'hex_table', you don't need the last line of your patch [22:52:57] <BBB> (which renames hextable into table, basically) [22:54:14] <wbs> good point. :-) [22:54:17] <BBB> also: do a search for %02x in your #2 patch, there's several left [22:54:54] <BBB> oh wait that's intended of course [22:54:55] <BBB> hmm... [22:55:31] <wbs> I guess that could be done using ff_data_to_hex too, yeah [22:55:40] <BBB> what's the resoluton of lfg? [22:56:02] <wbs> 32 bit [22:56:10] <BBB> if it's 32 bit (since we don't care about endianness; it's random, after all), then just fill 4 ints with the response, and pass the resulting array to ff_data_to_hex [22:56:23] <BBB> but snprintf() is ok also [22:56:26] <BBB> don't worry about this one [22:56:29] <BBB> leave it for now ;) [22:56:38] <wbs> ok :-) [22:56:50] <BBB> any reason it's 50 bytes and not 21? [22:57:08] <BBB> and nc 10 instead of 9? [22:57:26] <BBB> rest of #2 is ok, if tested [22:57:27] <wbs> nope, they're all just rough estimates of what should be "enough" [22:58:08] <wbs> could lower them not to waste too much stack [22:58:31] <BBB> if you change these, patch ok [22:58:35] <BBB> need me to confirm on-list? :) [22:58:43] <wbs> nah, it's ok :-) [22:58:45] <BBB> I'll look at the rtsp ones tonight, I hope [22:59:02] <wbs> just waiting for an ack from someone on the ff_data_to_hex [22:59:43] <BBB> that'd be Michael [22:59:45] <BBB> #3 is ok also [23:00:53] <wbs> ok, will apply that one [23:01:50] <BBB> as for #4, I'd remove the separate allocation of rt->auth, just make it a static inline array of whatever size auth[] has in the call to ff_url_split() now [23:02:15] <BBB> ff_rtsp_send_cmd_with_content() that change should be separate from this patch [23:03:11] <BBB> wht's the purpose of the find_method_and_url() piece in there? [23:03:30] <wbs> the digest auth needs the http/rtsp verb and url separated [23:03:41] <wbs> e.g. "POST" and "/path/to/file" [23:03:54] <wbs> but they're all given as a large buffer to rtsp_send_cmd [23:04:42] <BBB> oh right [23:05:06] <BBB> how difficult would it be to change that? [23:05:17] <BBB> </crazy idea> [23:05:26] <wbs> i looked into it - in quite a few place we add extra parameters to the request by appending them to the cmd [23:05:55] <BBB> yeah, I remember [23:07:51] <CIA-24> ffmpeg: mstorsjo * r22663 /trunk/libavformat/rtsp.c: Make ff_rtsp_send_cmd simply call ff_rtsp_send_cmd_with_content [23:08:18] <wbs> as for doing the change to ff_rtsp_send_cmd_with_content separate to the rest of the patch - that'd temporarily break basic auth [23:08:46] <wbs> (currently we add the credentials blindly, but with this in place, we always first try without credentials and then add them if necessary) [23:16:33] <wbs> except for that, made rt->auth statically allocated as you suggested [23:38:21] <BBB> wbs: can you apply that first then? [23:38:35] <BBB> wbs: although... [23:38:40] <BBB> make sure it always adds it to every command [23:38:46] <BBB> not for each command "try without, then with"