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

[irc at mansr.com]

[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 at 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/6534c7b5/attachment-0002.patch
[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"