Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2010

1 participants
23 discussions

IRC log for 2010-06-02
by irc＠mansr.com 03 Jun '10

03 Jun '10

[00:21:16] <mchinen> Sorry for spam but I ask again because new people came on :can someone tell me why is AVFormatContext's data_offset sometimes the end of the file? [00:21:30] <mchinen> I'm trying to find the first packet. Maybe there's a better way? [00:57:28] <bcoudurier> data_offset can be set by av_find_stream_info [04:36:58] <peloverde> http://sites.google.com/site/wenchiehlee1020/Papers/ComplexFB_AES_121paper1… has some good SBR filterbank derivations if anyone is interested in playing with it [04:37:03] <peloverde> (added to wiki) [04:39:45] <kshishkov> well, at least it's not from mainland China [04:56:19] <peloverde> It's basically just derivations, much more useful than the run of the mill paper [06:44:50] <KotH> morge! [06:45:09] <av500> morche [06:56:56] <wbs> hyc: no, I don't think the protocol specific options are documented anywhere [06:57:06] <wbs> hyc: I only know of ?udp and ?tcp for rtsp urls anyway [07:10:35] <CIA-92> ffmpeg: mstorsjo * r23419 /trunk/ffserver.c: [07:10:35] <CIA-92> ffmpeg: ffserver: Allow floating point audio bit rates [07:10:35] <CIA-92> ffmpeg: This allows setting bit rates that aren't an exact multiple of 1000. [07:20:09] <wbs> superdump: do you have time to give a comment on channel mapping in vorbis - the "Correct libvorbis.c behaviour with >2 channels" thread? [07:25:58] <superdump> perhaps :) [07:28:54] <superdump> wbs: ah, in the _encoder_ [07:29:22] <wbs> yeah [07:29:36] <wbs> but I guess the channel mapping issues are roughly the same in both encoder and decoder? [07:29:57] <superdump> inverted i suppose [07:30:01] <wbs> yeah [07:30:12] <wbs> aren't both decoders and encoders supposed to take their native layouts as input/output? [07:30:21] <wbs> and then the calling code do the remapping if needed [07:30:44] <superdump> and i see this is in libvorbis, not ffvorbis [07:31:03] <superdump> i'm not so sure about encoders [07:31:18] <wbs> the patch as it is suggested assumes a non-vorbis channel layout for the input, which imo seems wrong [07:31:25] <superdump> decoders are supposed to take whatever they're given but give out WAVEFORMATEX order [07:31:51] <wbs> ah, so all of that is handled within the decoder? [07:32:03] <wbs> in that case, I guess this patch is correct, too [07:32:07] <superdump> i think an encoder should receive WAVEFORMATEX order and reorder as necessary for its internal format [07:48:47] <superdump> wbs: i would assume vorbis_enc.c is doing it right [07:48:51] <superdump> at least, i hope so [07:49:43] <wbs> vorbis_enc.c doesn't seem to do any channel remapping at all [08:03:09] <j0sh_> wbs: i just finished a very useless patch for url_open, lol [08:19:36] <wbs> j0sh_: replied to that one [08:19:55] <wbs> superdump: so, do you think the remapping in libvorbis.c is ok? I can summarise your points from above and apply the patch [08:21:12] <j0sh_> wbs: so close to getting this done, the rtsp stuff works nicely with feng but dss hangs [08:22:05] <j0sh_> was going to post a patch for rtsp-http but i'll hold off oon that until i get the delayopen stuff in, since that'll clean up things [08:22:28] <j0sh_> oh and btw... how should we signal to continue after the delay? [08:24:32] <wbs> hmm, good question. if the URL_DELAYOPEN stuff would be part of the full public external API, we'd need some url_do_open() or url_continue() or something like that, with full hooking through URLProtocol so that each protocol can choose to implement it [08:25:03] <superdump> wbs: sorry, i've been wandering putting washing on and so on [08:25:07] <superdump> let's see... [08:25:27] <kshishkov> are we going to have general tunneling-over-http protocol? I have the impression it's done in almost the same way for all tunneling [08:25:49] <j0sh_> kshishkov: how is other tunneling done? [08:26:07] <wbs> kshishkov: I don't know if it's the same for all, this one at least is quite peculiar [08:26:08] <j0sh_> this is some particular rtsp over http variant that apple invented [08:26:39] <wbs> by doing two http requests, one GET and one POST, and tying them together with an x-sessioncookie header, you get a bidirectional channel [08:26:41] <Honoome> j0sh_: did you test against feng master? [08:27:07] <j0sh_> Honoome: yeah, about a week old or so [08:27:26] <wbs> j0sh_: of the more quick and dirty version would be to do a ff_http_continue() [08:27:33] <j0sh_> i can pull an update if theres something new, but feng works [08:27:35] <Honoome> j0sh_: if you feel adventurous try it with the feng+netembryo-0.2.0 branch :P [08:27:46] <j0sh_> heh alright [08:27:59] <Honoome> [doesn't need netembryo anymore] [08:28:04] <j0sh_> wbs: but then the delayopen flag couldn't be part of public api [08:29:14] <j0sh_> we could have something unofficial, but that won't stop people from trying to abuse it [08:29:53] <wbs> j0sh_: well, yes and no... the flag itself could be considered non-public api (since the function is defined in lavf and only lavf uses the non-public part), and the ff_http_* functions needed for using it would only be available for internal use anyway [08:30:11] <wbs> yes, of course they can abuse it, but they can link straight to ff_* named functions too if they really want to [08:30:37] <j0sh_> gotcha [08:31:19] <j0sh_> ok i'll check that all out after some sleep [08:31:34] <j0sh_> thanks for the help [08:31:40] <wbs> BBB is mentoring the mms protocol soc project, too, where there will be an mms-over-http variant, too, so it would perhaps be good to sync with them about what they need from the http protocol there [08:32:06] <j0sh_> will do [08:39:18] * Honoome should probably move to Microsoft variant of RTSP now that feng supports more or less well the Apple variant of it [08:40:30] <wbs> Honoome: the microsoft variant is way much messier, as far as I know... [08:40:49] <wbs> it's sending some ASF stream over one single RTP channel, with lots of hacks [08:40:51] <Honoome> wbs: where's the surprise? [08:41:09] <wbs> true :-) [08:41:19] <Honoome> seriously, you can say what you want about apple, but at least they tend to write some (vague) documentation about what they do… [08:41:28] <av500> smoothstreaming ftw? [08:41:41] <wbs> Honoome: the "add tcp interleaving id if the client didn't specify one" fix seems to work just fine, btw, thanks :-) [08:42:16] <Honoome> np … it was almost incidental at that point since I more or less rewrote most of the code there :P [08:42:48] <wbs> av500: even better, adobe's variant of it.. http://www.adobe.com/products/httpdynamicstreaming/, with links "Learn about the F4F file format specification" to a page that doesn't say a word about F4F ;P [08:43:54] <av500> btw, all this aapl/msft/adobe http streaming, does it mean that multicast is dead? [08:44:21] <Dark_Shikari> multicast was dead 15 years ago [08:44:29] <Honoome> av500: ah try not to confuse the rtsp-in-http tunnelling with apple's “http streaming” they are different things… totally [08:44:33] <Honoome> Dark_Shikari: was it _ever_ alive? [08:44:51] <av500> Honoome: I was not confusing them [08:46:03] <av500> Honoome: IPTV uses it today, no? [08:46:09] <av500> (some iptv) [08:47:00] <Honoome> not sure… I haven't seen any iptv myself [08:48:12] <superdump> wbs: i'm just checking it [08:50:16] <superdump> as i suspected, not quite right [08:50:30] <superdump> wbs: would you prefer to talk here or on the ML? [08:50:51] <wbs> superdump: move it to the ML, that's probably better so that the original patch author gets the feedback [08:50:57] <superdump> ok [08:51:05] <wbs> I'm not really involved, just trying to get the patch integrated and activating the right people ;P [08:51:10] <superdump> are you just an interested party then? :) [08:52:01] <wbs> interested in getting glaringly obvious bugs fixed (the current code does if (channels == 1) { ..} else { assume channels == 2 }) [08:52:23] <wbs> once the webm muxer and vp8 encoder wrappers are accepted, libvorbis will probably be used a lot more [09:10:04] <siretart> any native speakers around that can help a bit with the 0.6 Release Notes? [09:10:11] <siretart> please review and edit here: http://whiteboard.debian.net/ffmpeg-0.6-release-notes.wb [09:12:07] <Dark_Shikari> May? It's already June :) [09:12:35] <Dark_Shikari> also, I see no problems. [09:12:53] <siretart> correct [09:13:14] <siretart> ok. are you okay with the libvpx reference? [09:13:31] <siretart> I guess we could use that text for the website entry as well [09:14:01] <kshishkov> "are relevant for the HTML 5 [09:14:05] <kshishkov> area" - lol [09:14:28] * kshishkov checks animated SVG and extended CSS support in FFmpeg [09:14:44] <av500> siretart: HTML5, no? [09:14:51] <av500> thats how the net seems to spell it... [09:14:54] <Dark_Shikari> "are relevant for HTML5 video" maybe? [09:14:59] <Dark_Shikari> oh, and mention the faster theora decoder [09:15:09] <Dark_Shikari> and theora decoding bugfixes [09:15:16] <merbzt> proper atrac1 support [09:15:22] <siretart> that's a collaborative editor. feel free to edit! :-) [09:15:34] <av500> "we will be rectify" -> drop the be [09:15:35] <kshishkov> Dark_Shikari: unfortunately, Theora is HTML5 video as well :( [09:17:08] <siretart> I've pasted the rest of the RELEASE file as well now [09:18:24] <av500> siretart: tons of trailing whitespace!! [09:18:56] <siretart> av500: yea, that seems to be an implementation detail of whiteboard. I'll M-x whitespace-cleanup it before committing [09:19:00] <Dark_Shikari> - libswscale can now be compiled in LGPL mode [09:19:05] <Dark_Shikari> we didn't backport the full LGPL-ization? [09:19:26] <siretart> I guess no, at least I didn't [09:19:38] <Dark_Shikari> That might be nice. [09:20:24] <Dark_Shikari> anyways, I did some editing. [09:20:26] <siretart> in principle yes, but I'd prefer to defer this to either 0.6.1 or 0.7 [09:20:33] <siretart> excellent, thanks! [09:21:23] <siretart> cool. it seems that whiteboard indeed works out :-) [09:26:09] <j-b> siretart: when do you plan to release? [09:26:32] <CIA-92> ffmpeg: siretart * r23420 /branches/0.6/RELEASE: updates: introductionary and more general notes, add missing items from changelog [09:26:38] <av500> we hand out 0.6 releases on CD at linuxtag... [09:26:41] <siretart> j-b: ideally today [09:27:14] <Dark_Shikari> on CD? might as well include a copy of big buck bunny on there too [09:27:17] <Dark_Shikari> and elephant's dream [09:27:32] * av500 was probably joking [09:27:33] <Dark_Shikari> and sintel [09:27:57] <twnqx> av500: you could hand out prints of the code! [09:28:02] <KotH> apropos lt [09:28:05] <av500> md5sum at least [09:28:10] <KotH> janneg: did you get the posters? [09:28:58] <av500> janneg: when do plan to do the 6x vids for the wall? [09:29:12] <av500> mru: ping [09:29:29] <janneg> KotH: yes, already last week [09:29:37] <KotH> cool! [09:29:53] <janneg> av500: when the rendering is finished [09:30:09] <av500> eta? [09:30:40] <kshishkov> av500: but handing out 0.6 releases may help you to get rid of floppies [09:30:58] <av500> kshishkov: no, need them for the scope... [09:31:19] <kshishkov> punch cards then [09:32:38] * av500 punches some cards, cards shrug [09:32:44] <KotH> wow... 3.5h per frame [09:32:59] <av500> vp8 encoder? [09:33:08] <KotH> no, bender rendering [09:35:01] <kshishkov> av500: Changelog also lists Peter's work for Bink audio in 0.6 [09:35:08] <janneg> av500: I'll prepare the finished scenes this week, eta for the last scene is hopefully just in time [09:36:22] <janneg> KotH: that's nothing, a couple of scenes needed over 24h per frame [09:36:53] <av500> kshishkov: bink? moi? [09:37:24] <kshishkov> av500: some people thought it was quite important game format [09:37:44] <kshishkov> used in more games than Indeo 5 too [09:37:59] <KotH> janneg: o_0 [09:38:32] <av500> kshishkov: yes, but probably for siretart, no? [09:38:53] <siretart> av500: sorry? [09:38:53] <av500> or you want me to write that on the punch card? [09:39:04] <av500> [11:35] <kshishkov> av500: Changelog also lists Peter's work for Bink audio in 0.6 [09:39:07] <av500> [11:37] <kshishkov> av500: some people thought it was quite important game format [09:39:21] <av500> [11:37] <kshishkov> used in more games than Indeo 5 too [09:39:31] <kshishkov> av500: yes, you germans find common language easier [09:39:45] <Tjoppen> is ffplay supposed to be able to play rawvideo? if claims to fail to open codecs, which doesn't make sense to do for raw video [09:39:57] <Tjoppen> *it [09:40:10] * kshishkov lives in that land - http://en.wikipedia.org/wiki/File:Wirkoennenalles.jpg [09:40:31] <av500> kshishkov: "und Englisch" [09:40:34] <kshishkov> Tjoppen: yes, but you have to specify size for it at least [09:40:52] <Tjoppen> it has correct values from size (given by avi container) [09:40:53] <kshishkov> av500: yes, found that out [09:41:02] <Tjoppen> 4096x3112 [09:41:16] <Tjoppen> maybe pixel format though [09:41:23] <kshishkov> too big for swscaling [09:42:02] <av500> Tjoppen: nice size, what is that content? can we have for video wall at linuxtag? [09:42:21] <KotH> kshishkov: unfortunately, most schwaben think they speak a very good german ^^' [09:42:51] <Tjoppen> av500: it's a scan of some old movie. 19 GiB for 16 seconds :o [09:43:07] <av500> so you have high def film grain? [09:43:10] <KotH> kshishkov: on the other hand, germans often think the high german swiss people speak is their dialect and are very surprised how easy it is to understand :) [09:43:15] <Tjoppen> indeed [09:43:57] <kshishkov> KotH: could be worse - try Hochrussisch [09:44:51] <KotH> kshishkov: thanks, i'd like to first master japanese :) [09:45:19] <Tjoppen> I only have four frames on disk at the moment. our network is kinda down, so I couldn't be bothered to grab them all [09:45:52] <kshishkov> KotH: がんばれ [09:46:08] <Tjoppen> time lunch. it seems MXF will do as a container for raw video as well, although the muxer doesn't support it yet [09:46:12] * av500 thinks his LCD is scratched [09:46:13] <Tjoppen> +for [09:46:32] <Tjoppen> should be interesting.. multi-terybyte MXFs :) [09:46:43] <Tjoppen> *tera. gah, typos today [09:46:56] <av500> terrybyte [09:47:47] <kshishkov> which terry? [09:48:04] <thresh> byte. [09:48:13] <av500> gilliam, known from the gillabyte [09:48:30] <kshishkov> ah, that one [09:58:07] <Tjoppen> well, ffplay.c doesn't check for rawvideo anywhere. I'll try inserting a hack and see what it does [10:02:50] <mru> av500: pong [10:03:16] <av500> the beast has been tested this morning, work so far [10:03:38] <av500> I was thinking of a adding like a 5s trailer to the linuxtag video loop [10:03:56] <av500> like nice ffmpeg logo in the top left screen [10:04:47] <av500> sponsor logo in bottom screen :) [10:06:06] <mru> will you make the video? [10:06:18] <av500> I can [10:06:50] <av500> if you can give me ffmpeg logo that fits in 1024x768 box [10:06:56] <av500> with borders [10:07:02] <av500> or svg [10:07:04] <av500> or so [10:08:11] * kshishkov wonders why there's still no XML parser in lavu [10:08:37] <superdump> siretart: is ffmpeg in debian configured with any mpeg encoders? [10:08:42] <mru> there's an svg logo in the ffmpeg.org repo [10:09:06] <av500> and /me can access that? [10:09:22] <mru> kshishkov: lavu is supposed to be small and simple [10:09:31] <mru> av500: anon svn [10:10:05] <janneg> mru: what source format do you want for bbb? I have currently only the pngs [10:10:47] <janneg> av500: s:ffmpeg/:ffmpeg.org/: [10:12:05] <Tjoppen> odd. I'm getting codec_name == "rawvideo" but codec_id == 0 in stream_component_open() in ffplay.c [10:12:31] <mru> janneg: lossless h264? [10:12:47] <av500> mru: gimp renders it wrongly [10:12:53] <av500> the G is truncated [10:15:26] <kshishkov> wrong font then [10:15:58] <av500> kshishkov: it depends on an outside font? [10:16:25] <av500> also on my printer driver? [10:19:04] * av500 has no franklin gothic demi .... [10:22:08] <mru> av500: email? [10:49:30] * av500 has franklin gothic demi .... [10:50:00] <mru> work better? [10:50:14] <av500> yes [10:55:33] <CIA-92> ffmpeg: stefano * r23421 /trunk/ (ffprobe.c libavcodec/avcodec.h libavcodec/utils.c): Implement av_get_codec_tag_string() and use it in ffprobe. [10:55:34] <CIA-92> ffmpeg: stefano * r23422 /trunk/libavcodec/utils.c: Make avcodec_string() use av_get_codec_tag_string(). [10:55:35] <CIA-92> ffmpeg: stefano * r23423 /trunk/libavformat/utils.c: [10:55:35] <CIA-92> ffmpeg: Make the error message issued in case of invalid codec tag more [10:55:35] <CIA-92> ffmpeg: informative. [11:00:04] <CIA-92> ffmpeg: stefano * r23424 /trunk/doc/APIchanges: Add APIchanges entry for av_get_codec_tag_string(). [11:21:19] <Tjoppen> this gets more and more interesting. now I can transcode dpx to rawvideo and play it in ffplay. the avi demuxer incorrectly detects it as bgr24 though [11:23:42] <pross-au> i would argue that Bink is a very popular codec slated for 0.6 [11:23:58] <pross-au> Certainly more popular then Indeo 5 [11:25:53] <merbzt> pross-au: well alter the text then [11:28:01] <Compn> what [11:28:16] <Compn> indeo5 on mac is more important than bink, imo [11:29:06] <pross-au> Sure [11:29:14] <merbzt> there we go added [11:31:01] <mru> I would argue that neither of those is particularly important [11:37:40] <Tjoppen> woo. avi can hold a whopping one second of 48bit 4k rawvideo [11:39:30] <thresh> 1 seconds is more than enough for most todays videos... [11:39:36] <av500> +1 [11:39:42] <KotH> +23 [11:39:45] <av500> I wish utube had a 1s limit [11:40:07] <lu_zero> why? [11:40:27] <av500> it would force user created content to get to the point quickly [11:40:35] <peloverde> less of a hassle to migrate away from ffvorbis? [11:41:20] <av500> atm, it is "30s blurry/shaky + 1s <content> + 20s blurry/shaky" [11:41:59] <Tjoppen> I wonder how I'll handle all the data for a larger test. I'm downloading all 19 GiB atm, but I only have 39 GiB disk space. as rawvideo, it will grow to around 30 GiB [11:42:15] <av500> 39BG? [11:42:22] <lu_zero> what's that? [11:42:29] <av500> such small drives still exist? [11:42:35] <av500> gb [11:42:40] <Tjoppen> well, that much free space [11:42:54] * av500 sends Tjoppen shopping [11:42:57] <Tjoppen> perhaps time for a trip to the sysadmin :) [11:43:18] <Tjoppen> also, more RAM and cores would be nice. 16 GiB/8 core or so [11:45:23] <Tjoppen> anyway, time to generate proper PixelLayout data for MXF. maybe I can port that stuff to lavf later [11:45:48] <Tjoppen> also, make the demuxer output proper pix_fmt [12:02:00] <elenril> anyone got an mp3 with TIME tags? [12:05:29] <KotH> elenril: what is the fastest way to look for one? [12:05:43] <av500> scan all your mp3s [12:06:06] * mru doesn't have any mp3s [12:06:09] <elenril> KotH: good question ;) [12:06:22] <jai> make one ? [12:06:29] <elenril> ffprobe|grep TIME? [12:06:31] <mru> fake one [12:06:36] <mru> take one [12:06:43] <elenril> i want to see how are they used in the wild [12:08:22] <KotH> elenril: meh.. [12:08:31] <KotH> elenril: it takes half an hour to compile ffmpeg on this machine [12:09:12] <elenril> o_0 you don't have ffmpeg? [12:09:20] <KotH> not readily compiled [12:10:03] <elenril> packages? [12:10:37] <mru> everybody ok with troll driven t-shirts? [12:10:40] <KotH> uhmm. no [12:10:49] * elenril wants one too [12:10:57] <mru> elenril: come to berlin and get one [12:11:05] <KotH> mru: only if there is a troll drawn on it, with a zigzag hair style [12:11:14] <KotH> ;) [12:11:17] * elenril has exams^wscience to do [12:11:24] <mru> KotH: seriously, do you have a better idea? [12:11:28] <KotH> mru: nope [12:11:42] <mru> KotH: besides, you're not even coming [12:12:04] <kshishkov> mru: you can thank me for that [12:12:15] <mru> for KotH not coming? [12:12:25] <kshishkov> of course [12:12:25] <KotH> yes, it's his fault [12:12:55] <mru> kshishkov: what's your size? [12:13:05] <mru> av500: what size is your fosdem t-shirt? [12:13:06] <kshishkov> mru: told you, 3XL [12:13:27] <av500> mru: xxl? :) [12:13:51] * av500 does not want to enter another size discussion with mru.... [12:14:02] <mru> av500: could be XL, I don't remember [12:14:35] <elenril> KotH: what's wrong with packages? [12:15:06] <elenril> or you're a zomg-ricer? =p [12:15:13] <kshishkov> av500: having a t-shirt of bigger size is better and more comfortable [12:16:31] <av500> mru: you heard da man! [12:16:56] <kshishkov> av500: he's also seen me. Several times [12:17:02] <KotH> mru: 4xl ;) [12:17:19] <mru> they don't do that size [12:17:27] <KotH> doh! [12:17:38] <av500> mru: order 6 and we stitch them together [12:25:49] <lu_zero> O_O [12:26:23] <lu_zero> KotH: poing [12:26:42] <KotH> lu_zero: boing [12:26:57] <lu_zero> roundup [12:27:32] * KotH rounds down [12:27:33] <lu_zero> do you want to move it on your server or should I move it on a top-ix box like the the one hosting lscube.org ? [12:27:49] <KotH> lu_zero: what do you prefere? what do you think is more stable? [12:27:59] <KotH> lu_zero: we can also move it to natsuki [12:28:18] <KotH> lu_zero: given you can help me figure out how to install all that python stuff in a way that it is maintaibale :) [12:28:35] <lu_zero> that's the point I think [12:29:11] <lu_zero> right now 1.3G /var/db/roundup/ [12:29:24] <KotH> 1.3G?? [12:29:28] <KotH> wtf? [12:29:31] <KotH> what's in there? [12:29:37] <mru> snakes [12:29:49] <lu_zero> somebody suggested to host sample files while the ftp is being out of order... [12:30:15] <KotH> hmm? [12:30:20] <lu_zero> eh... [12:30:45] <KotH> oh.. the partition is filled up [12:30:47] <KotH> good [12:30:57] <KotH> and nobody dared to sort anything [12:31:02] * KotH blames everyone here [12:31:58] * kshishkov actually told what to do with several files [12:32:00] * elenril suggests rm -fr / [12:32:46] <KotH> kshishkov: when? where? [12:32:55] <lu_zero> looks like somebody didn't complain in the right place [12:33:00] <KotH> lu_zero: ok, i'll first take care of incomming and sort that mess [12:33:08] <kshishkov> KotH: during that time. On mplayer-dev ML [12:33:09] <mru> the AMIGA directory is the biggest in incoming... [12:33:28] <KotH> lu_zero: then i'll see whether i've still enough energy and muse to battle with python [12:33:49] <KotH> lu_zero: hmm.. there is a "this weekend" missing somewhere in that sentence [12:34:08] <lu_zero> I guess I could just get the thing moved to lscube.org [12:34:22] <KotH> mru: issue1625 is next [12:34:50] <mru> why did "someone" upload and entire fucking amiga? [12:34:53] <mru> *an [12:35:24] <lu_zero> O_o? [12:35:26] <KotH> Dear FFmpeg developers, these archives contain everything for TuComposer. [12:35:35] <av500> mru: so that all can try tucomposer in its full glory [12:35:35] <wbs> because someone thought it was a good idea, so that we could try out someones code in the proper original environment (the only one where it compiles at the moment) [12:35:39] <wbs> ;P [12:36:43] <kshishkov> wbs: yes, that was that idea [12:37:05] <av500> and download stats should show that dozens of ppl did that..... [12:37:10] <KotH> does anyone care or can that be deleted? [12:37:15] <jai> O_o [12:37:34] <av500> KotH: I bet he will just re-upload :) [12:37:54] <kshishkov> it ain't sample nor FFmpeg license offender, so delete [12:38:23] <KotH> done [12:38:31] <KotH> if anyone still cares, let me know [12:39:48] <KotH> Dark_Shikari: there are multiple facebook_* files in incomming [12:39:53] <KotH> Dark_Shikari: what is the status of them? [12:40:16] <KotH> Dark_Shikari: IIRC the conditions to use files from facebook was that they are deleted after fixing the bug? [13:07:51] <av500> mru: http://www.stanford.edu/class/ee282/handouts/lect.10.arm_soc.4pp.pdf [13:08:06] <av500> note ffmpeg reference on page5 [13:09:43] <av500> and page7 [13:29:46] <twnqx> is it still enws that Sonic bought DivX? [13:30:33] <av500> lol, 323mio$ [13:34:10] <kshishkov> what? That hedgehog buys companies now? Next thing I'll hear that Mario bought RealNetworks. [13:34:22] <twnqx> :> [13:56:15] <lu_zero> would be interesting [14:00:05] <av500> "Does WebM support SMTPE timecode?" [14:02:20] <lu_zero> O_O [14:02:22] <lu_zero> why that? [14:02:31] <av500> from wemb mailing list.... [14:02:41] <lu_zero> why ? [14:02:56] <av500> iDont know [14:03:18] <mru> that question doesn't make sense [14:03:32] <mru> smpte timecodes are not at container level [14:03:53] <mru> h264 supports it [14:03:54] <kshishkov> will WebM support kitchen sink and coffee maker? [14:03:57] <mru> vp8 probably not so much [14:04:00] <av500> its from wemb ml, not many things make sense there.. [14:04:31] <kierank> [15:03] <@mru> h264 supports it --> in the sei? [14:04:39] <mru> where else? [14:04:53] <kierank> dunno [14:05:24] <kierank> it's not an "official" sei though [14:05:48] <mru> hmm, I thought it was [14:07:12] <Yuvi> mru: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-February/007645.html <- michael rejected .p2align last time, but his reason doesn't make sense to me [14:07:42] <mru> nor to me [14:07:47] <mru> hopefully he's forgotten about that [14:10:23] <BBB> what is this get_codec_tag_string() function? [14:10:34] <mru> nobody knows [14:10:57] <BBB> that's helpful... :) [14:11:51] <mru> btw t-shirts are ordered [14:12:39] <kshishkov> mru: thanks for providing reference to MN so he can remember it after reading IRC log [14:13:09] * mru blames Yuvi [14:13:25] <mru> the log isn't mailed until midnight utc [14:13:49] <kshishkov> BBB: probably for getting codec tag in printable form [14:14:19] <BBB> printf("Tag: %4.4s\n", (char*)&uint); [14:14:38] <kshishkov> try it on BE system first [14:32:45] <Tjoppen> there we go. basic PixelLayout parsing in mxfdec.c [14:59:31] <av500> webm: "I would like to ask for supporting ASAP IMG_FMT_BGR24 and IMG_FMT_RGB24 formats in the encoder/decoder. This would make the life of who is using VP8 in OpenGL (like me) a lot easier." [14:59:49] <av500> note the friendly ASAP.... [15:00:36] <kshishkov> yep, there's no limit to idiocy [15:02:05] * elenril wants ASAP -mt merged [15:07:15] <superdump> elenril: well, i think astrange is a bit busy with other stuff at the moment [15:07:31] <superdump> and there's still stuff on the todo [15:08:42] <elenril> :( [15:08:53] <elenril> somebody should troll michael into merging it [15:09:20] <peloverde> agreed [15:09:59] <peloverde> and once it merges many more people will have motivation to work on the few outstanding issues [15:10:37] <kshishkov> who would want to merge stuff with FFmpeg while it has that horrible AAC encoder :P [15:11:07] <iive> i think i've said this before, michael needs smp machine and he'll do it without trolling. [15:11:36] <peloverde> If you throw enough bits at it the AAC encoder it is reasonably well behaved [15:11:58] * lu_zero kept reading the gcc ml [15:12:57] <lu_zero> I'm tempted to write a thank you email to mark(a)codesourcery.com for motivating me to switch to llvm [15:13:38] <elenril> can it compile ffmpeg now? [15:13:49] <peloverde> Can't the foundation buy michael a new machine? [15:14:11] <kshishkov> elenril: even icc can - but it won't work properly in all cases [15:14:14] <Yuvi> it has some issues on x86-32, but x86-64 has been fine for ages [15:14:38] <peloverde> Doesn't ICC miscompile ALS on x64 [15:14:39] <elenril> iirc it failed on asm before [15:14:48] * lu_zero tries right now [15:16:32] <lu_zero> I think if enough thank you will be sent to the ml he would reconsider [15:16:32] <mru> http://fate.multimedia.cx/index.php?build_record=234501 [15:16:35] <mru> not looking good [15:17:31] <mru> the older version fails on als [15:17:41] <lu_zero> http://fate.multimedia.cx/index.php?build_record=234410 [15:18:01] <lu_zero> and freebsd is already thinking about doing a full switch [15:18:23] <lu_zero> ffserver.c:2985:5: error: implicit declaration of function 'ff_url_split' is [15:18:26] <lu_zero> invalid in C99 [-Wimplicit-function-declaration] [15:18:28] <lu_zero> ff_url_split(NULL, 0, NULL, 0, NULL, 0, NULL, path1, sizeof(path1), url); [15:19:55] <lu_zero> builds fine [15:22:39] <elenril> <@peloverde> If you throw enough bits at it the AAC encoder it is reasonably well behaved << i hear some pretty horrible artifacts at 320kbps [15:22:47] <peloverde> stereo? [15:22:52] <peloverde> stereo is hosed [15:22:57] <peloverde> try 160 mono [15:23:12] <CIA-92> ffmpeg: mru * r23425 /trunk/libavcodec/bink.c: bink: correctly align local arrays [15:23:13] <elenril> how? [15:23:16] <av500> or encode 2x 160 mono streams... [15:23:26] <peloverde> dual mono requires PCE based configs [15:23:31] <peloverde> which no one but us supports [15:24:56] <elenril> hm, you're right, sounds much better [15:25:32] <elenril> are you planning to fix this anytime soon or at least print a warning? [15:25:57] <peloverde> I plan on tackling that soonish [15:27:32] <peloverde> I guess most people like stereo [15:27:39] <peloverde> but good mono is the funner problem [15:31:52] <elenril> clang gives me fatal error: error in backend: Ran out of registers during register allocation! [15:32:04] <elenril> on libavcodec/x86/mpegvideo_mmx.o [15:32:06] <av500> add more registers [15:32:31] * elenril steals av500's registers [15:32:33] <janneg> elenril: is requiring '-strict experimental' not warning enough? [15:33:09] <elenril> janneg: this way people might think it's worse than it actually is [15:33:16] <elenril> at least i did [15:43:49] <lu_zero> elenril: x86? [15:44:36] <elenril> yes [15:47:08] * lu_zero doesn't comment about x86 [15:47:15] <lu_zero> I hate it ^^; [15:47:30] <mru> don't we all? [15:47:54] <elenril> still most people use it =p [15:48:57] <hyc> it was kinda unavoidable. I was still using my 68030 boxes daily up til 2002 [15:49:35] <mru> it's the fastest affordable system [15:49:38] <mru> unfortunately [15:50:58] <hyc> and probably will remain so for a long time. now that globalfoundries has bought out chartered, even if you wanted to make a new chip, you have few choices where to fab it [15:51:42] <lu_zero> =\ [15:51:57] <lu_zero> the more I read that mailing list the more I'm surprised [15:53:44] <mru> nothing surprises me [15:55:21] <lu_zero> tomorrow we'll switch ffmpeg to Go [15:55:50] <peloverde> There is no reason to use x86_32 anymore for most applications [16:02:13] * elenril wonders how long does it take to compile clang+llvm [16:02:21] <peloverde> Is it possible to make on preset file source another [16:03:01] <mru> elenril: a few minutes on a fast machine [16:03:17] <lu_zero> elenril: clang: 1353 seconds average for 1 merges [16:03:28] <lu_zero> llvm: 1121 seconds average for 1 merges [16:03:40] <lu_zero> but it doesn't bootstrap [16:04:01] <lu_zero> but that won't be a gcc feature anymore so this point is moot [16:05:22] <Andrius> <lu_zero> but it doesn't bootstrap < wut? [16:05:34] <elenril> crap, it's c++ [16:05:41] <elenril> goodbye my page cache [16:06:11] <lu_zero> Andrius: gcc does take some of its time to build a mini cc that could be built by any C compiler [16:06:19] <lu_zero> then it builds the other parts [16:06:40] <lu_zero> so you can get gcc on any system even those that do not have gcc [16:07:03] <lu_zero> llvm and clang do not do something similar [16:07:15] <lu_zero> and gcc in C++ will lose it [16:07:48] <Andrius> so this mini cc only compiles C code? [16:07:52] <lu_zero> if this whole interesting idea is just to let google have gccgo [16:07:56] <lu_zero> Andrius: yes [16:10:08] <CIA-92> ffmpeg: cehoyos * r23426 /trunk/libavcodec/vorbis_enc.c: [16:10:08] <CIA-92> ffmpeg: Avoid division by zero that caused noise, typically at the beginning or [16:10:08] <CIA-92> ffmpeg: end of a file. [16:10:08] <CIA-92> ffmpeg: Patch by Frank Barchard, fbarchard google [16:10:33] <av500> doesnt division by zero cause a crash? [16:11:14] <av500> CIA-92: doesnt division by zero cause a crash? [16:13:59] <mru> not float [16:14:11] <av500> ah [16:14:16] <mru> nor int on ppc and mips [16:16:16] <mru> what I don't understand is how that change is at all equivalent [16:16:32] <mru> pow(x, 0.5) == sqrt(x), no? [16:16:47] <av500> for certain values of 0.5, yes [16:16:57] <mru> and x/200 == x*0.005 [16:17:26] <mru> oh, there's a *= becoming = too [17:14:19] <ramiro> does the iphone really not support java? [17:14:41] <av500> of course not [17:15:27] <av500> and what for? [17:21:03] <peloverde> ramiro, it breaks the rules but you probably could use gcj to make a native binary from java src [17:27:24] <lu_zero> then disasm it, mangle the symbols and build from it [17:28:40] <av500> rinse, repear [17:28:42] <av500> rinse, repeat [17:53:29] <Dark_Shikari> KotH: delete them [17:53:34] <Dark_Shikari> if you want [17:53:49] <Dark_Shikari> mru: your inter dequant function crashes on the ipad because of the hardcoded struct offsets [17:54:02] <mru> they're different? [17:54:03] <mru> wtf? [17:54:18] <Dark_Shikari> Of course they are [17:54:22] <mru> why? [17:54:26] <Dark_Shikari> the C language doesn't guarantee exact alignment of anything [17:54:33] <mru> no, but the arm abi does [17:54:33] <Dark_Shikari> the compiler is free to pad whatever it wants, however it wants [17:54:37] <Dark_Shikari> Wait what? [17:54:46] <Dark_Shikari> er, well... you know that apple doesn't use the ARM ABI, right? [17:54:55] <Dark_Shikari> not all ARM chips are required to use the ARM ABI [17:54:57] <mru> it does [17:55:05] <mru> except the stack alignment isn't maintained [17:56:39] <Dark_Shikari> Are you sure? Because it's crashing in your function. [17:56:47] <Dark_Shikari> I haven't actually confirmed this is due to th ehardcoded offsets [17:56:50] <Dark_Shikari> but fuck, I can't imagine any other reason [17:56:59] <BBB> could that be responsible for the green-screen that some people see? [17:58:44] <Yuvi> I'm pretty sure iphone/etc use the equivalent -mabi=apcs-gnu, not -mabi=aapcs(-linux) [17:59:01] <mru> and the difference? [17:59:31] <mru> the apple doc references the arm aapcs doc [17:59:57] <mru> the only difference I've found is the stack alignment [18:00:07] <mru> and on iphone os 2.x r9 is reserved [18:01:08] <Yuvi> BLOCK_LAST_INDEX and such are the hardcoded offsets? [18:01:13] <Dark_Shikari> yes [18:01:29] <Dark_Shikari> IMO using hardcoded offsets in anything but trivial structs is extraordinarily dangerous [18:01:49] <mru> then making the interface like that was extraordinarily stupid [18:02:09] <Dark_Shikari> Then go fix it [18:02:17] <mru> good luck with that [18:02:37] <mru> this is deep in the bowels of michael code [18:02:59] <av500> #ifdef IPAD? [18:03:23] <Dark_Shikari> Er, it's not that hard [18:03:28] <Dark_Shikari> you just move some parts outside of the asm [18:03:31] <Dark_Shikari> and then pass the asm the rest [18:03:48] <mru> I'm not going to fight that battle [18:05:00] <mru> oh fuck, alignment of int64 is different [18:05:29] <Dark_Shikari> in what case? [18:05:40] <mru> apple requires 4-byte, arm 8-byte [18:05:47] <mru> FUCK YOU APPLE>!!!!!!!!!!!!!!!!!!! [18:05:56] <Dark_Shikari> just ifdef it ok? [18:06:03] <Dark_Shikari> easier than fucking with the api for that function [18:06:06] <mru> yes [18:06:13] <mru> just find out the correct offsets [18:06:24] <mru> if I have to touch a mac again today I'll murder someone [18:06:40] <Dark_Shikari> do you want us to get the offsets for you? [18:06:45] <mru> yse [18:06:57] <blast_hardcheese> I feel kinda embarrassed asking this, since it's probably much less difficult than what you guys are talking about, but I really need help; I've been trying to convert x264+aac mp4 into x264+aac mpeg2ts (for streaming on the iPad using the m3u8 playlist format) [18:07:08] <av500> -> #ffmpeg [18:07:54] <blast_hardcheese> hmm. [18:08:04] <mru> it's right over there ---> [18:08:29] <Yuvi> 0x26f8 for h263_aic [18:08:56] <av500> libavhardcodedvalues? [18:09:05] <BBB> hehe :) [18:09:31] <mru> I was considering some hack that would make the build fail of the offsets are wrong [18:09:40] <Dark_Shikari> Yuvi: we need a lot more than that : [18:09:44] <Dark_Shikari> inter_scantable.raster_end [18:09:46] <Dark_Shikari> y_dc_scale [18:09:48] <Dark_Shikari> c_dc_scale [18:09:51] <Dark_Shikari> ac_pred [18:09:51] <av500> mru: that and a loop ... [18:09:54] <Dark_Shikari> block_last_index [18:09:57] <Dark_Shikari> and inter_scantable.raster_end [18:12:31] * elenril wonders how long can linking clang take [18:12:43] <av500> clong? [18:14:14] <elenril> it's been running for ~30 minutes [18:14:23] <elenril> and eaten 2/3 of my swap :/ [18:14:56] <Andrius> are you building debug version? [18:15:21] <elenril> seems i am [18:15:32] <Andrius> that's a very bad idea unless you want to debug clang [18:15:33] <elenril> i didn't pass any parameters to configure [18:15:50] <Andrius> "./configure --enable-optimized" is what you want [18:16:22] <elenril> why is it building in debug mode by default then? [18:16:56] <Andrius> no idea, but debug clang is fat and slow, I think even configure script tells you that [18:17:44] <elenril> well it didn't [18:18:04] <elenril> any other --enables i should use? [18:18:27] <Andrius> --enable-targets=host if you don't need all the fancy architectures supported by llvm, it will make compile a bit faster [18:19:33] <Andrius> actually yes, configure script doesn't tell anything about slowness of debug version anymore, weird [18:20:15] <Yuvi> Dark_Shikari: http://pastie.org/989379 should work [18:20:35] <Dark_Shikari> ok, will get him to test asap [18:20:43] <Dark_Shikari> t [18:20:45] <Dark_Shikari> -t [18:21:12] <Dark_Shikari> the guy is currently away, he'll be back in an hour probably, then if it works I'll ping mru [18:21:20] <av500> Dark_Shikari: at how many ms are you atm? [18:21:21] <mru> Yuvi: that's subtly wrong [18:21:29] <mru> you don't know that non-eabi will use apple rules [18:21:47] <Dark_Shikari> av500: depends on everything [18:21:55] <Yuvi> true, but unfortunately __APCS_32__ is always defined in gcc, according to clang [18:21:56] <Dark_Shikari> oh, you mean decoding flv [18:22:03] <Dark_Shikari> did you hear about how I butchered mpegvideo? [18:22:03] <Yuvi> even for eabi [18:22:10] <av500> yes, your use case where you have 20ms/frame [18:22:19] <Dark_Shikari> we haven't tested since [18:22:24] <av500> Dark_Shikari: yes, so where are you now? [18:22:26] <Dark_Shikari> I think I'll be able to get down to that solely by the butchering [18:22:29] <Dark_Shikari> we haven't tested yet [18:22:32] <mru> Yuvi: ifdef __apple__ ? [18:22:32] <av500> ah ok [18:23:07] <mru> I'm making an offset-checking hack [18:23:12] <mru> so it won't build with wrong offsets [18:25:03] <Yuvi> mru: whichever, doubt that anything not using eabi would use something different though [18:25:22] <Dark_Shikari> wait, why does arm align 8-byte ints to 4-byte? [18:25:34] <mru> it doesn't [18:25:35] <mru> apple does [18:25:36] <av500> because it is a 32bit [18:25:46] <Dark_Shikari> ahhhh [18:25:48] <Yuvi> apcs-gnu existed before apple [18:25:53] <mru> apple is rotten [18:26:21] <Yuvi> apple was just wrong for not paying attention to gcc's defaults [18:26:30] <Yuvi> when adding a new platform [18:26:38] <mru> apple was wrong for not reading the bloody spec [18:26:50] <av500> s/ for not reading the bloody spec// [18:26:59] <mru> that too [18:27:24] <av500> but then, "think wrong" seems to sell... [18:29:27] <kierank> av500: archos should do that [18:29:42] <av500> do what? [18:29:48] <av500> think wrong? [18:29:54] <av500> we do, just the wrong wrong [18:29:54] <kierank> yes [18:37:56] <omkiran> Hello. Is there anyone working on the libavfilter stuff actively. I think I can contribute there. [18:39:09] <av500> omkiran: you work for i*? [18:40:37] <omkiran> well i guess you know [18:40:46] <av500> right, forgot.. :) [18:40:55] <kierank> who's i*? [18:43:54] <omkiran> I was going through the ffmpeg SoC list and saw libavfilter for video was listed. If no one's taken it up I would be glad to do some stuff there. [18:44:22] <omkiran> av500: How do you know me? [18:44:34] <omkiran> kierank: i* would be ittiam. Unless av500 got it wrong [18:44:52] <omkiran> or maybe i did [18:45:20] <lu_zero> uh? [18:45:27] <av500> omkiran: no, I got it right :) [18:46:00] * av500 waves to omkiran from Darmstadt [18:46:20] <omkiran> ok. Got it. [18:46:44] <omkiran> anyways i guess I should ask on the mailing list about the libavfilter stuff [18:47:31] <mru> just send patches :-) [18:48:16] <omkiran> ok. So i should get the latest stuff from svn add the stuff test it out and send over a patch to the mailing list for approval? [18:48:34] <mru> that's the way it goes [18:48:43] <mru> then you fix the patch, resend it, and repeat [18:49:57] <elenril> except making patches with svn is :effort: [18:50:07] <mru> using git is allowed [18:50:16] <mru> encouraged, even [18:50:16] <wbs> almost encouraged, too ;P [18:50:31] <omkiran> sounds good enough. I will annouce over the mailing list what I am planning to do so that no duplicate effort is going on. [18:50:34] <omkiran> git is better with me [18:50:43] <CIA-92> ffmpeg: mru * r23427 /trunk/libavcodec/arm/ (asm-offsets.h mpegvideo_arm.c mpegvideo_neon.S): ARM: fail build if hardcoded struct offsets are wrong [18:51:07] <mru> cryptic error messages are better than broken build [18:52:06] <av500> mru: if it can check the ofsets, it can also find them, no? [18:52:17] <mru> no [18:52:46] <mru> offsetof() doesn't work so well in asm [18:56:06] <CIA-92> ffmpeg: mru * r23428 /trunk/configure: [18:56:06] <CIA-92> ffmpeg: Use .p2align in ASMALIGN() macro [18:56:06] <CIA-92> ffmpeg: The test for .align syntax was apparently unreliable with some compilers. [18:56:06] <CIA-92> ffmpeg: Using the .p2align directive instead avoids the need for this test. [18:57:12] <CIA-92> ffmpeg: stefano * r23429 /trunk/tests/lavfi-regression.sh: Remove useless variables in get_common_elements(). [19:33:19] <elenril> meh, git clang still fails :( [19:50:03] <elenril> yay, ffmpeg built with clang segfaults on any h264 video [19:51:00] <thresh> that's expected for clang [19:51:10] <Andrius> find where it miscompiles stuff, report a bug, make my life easier :P [19:51:41] <Yuvi> that's the inline asm constraint being ignored for 32-bit [19:51:47] <Yuvi> lemme find the bug [19:53:38] <Yuvi> http://llvm.org/bugs/show_bug.cgi?id=6539 [19:54:00] <nfl> BBB: http://wiki.multimedia.cx/index.php?title=Hosting_SoC_Repo_On_Github [19:55:12] <lu_zero> elenril: really? [19:55:34] <elenril> yes [19:55:39] <elenril> with --disable-mmx that is [19:55:57] <lu_zero> here is working correctly [19:56:51] <Yuvi> lu_zero: are you on 64-bit? [19:59:21] <lu_zero> yes [19:59:40] <Yuvi> that's why, llvm has multiple bugs compiling ffmpeg on x86-32 [19:59:45] <Yuvi> but not -64 [20:00:30] <lu_zero> I wonder what will happen with gcc [20:02:40] <elenril> gcc works fine [20:03:05] <lu_zero> now [20:03:30] <lu_zero> the discussions about "let's move everything to C++ just because" make me shiver [20:04:42] <BBB> nfl: thanks! [20:05:22] <Andrius> C++ in gcc looks something like "it works for llvm guys, let's do it too" [20:06:20] <CIA-92> ffmpeg: darkshikari * r23430 /trunk/ (configure libavcodec/libx264.c): [20:06:20] <CIA-92> ffmpeg: Properly initialize x264_picture_t in libx264. [20:06:20] <CIA-92> ffmpeg: Bump libx264 version requirement accordingly. [20:06:46] <ohsix> they're being very cautious about it; they're not doing a "just because", they're doing "it might be ok now, but in what form" [20:07:03] <lu_zero> and what's sucks is that they have already shown they aren't exactly great with the language with their standard libc++ [20:07:20] <lu_zero> ohsix: the mailing list isn't exactly this way [20:07:48] <lu_zero> mark(a)codesourcery.com is quite for "let's do a full conversion now" [20:08:05] <ohsix> i read the mailing list heh [20:08:17] <ohsix> you can read back a few months for the RFC's on it, too [20:08:21] <elenril> http://apple.slashdot.org/story/10/06/02/1930209/Objective-C-Enters-Top-Ten… << wut [20:08:32] <lu_zero> while others are more "ok, so some backends can use it but let other people use C" [20:09:07] * elenril didn't ever encounter a single objective c app [20:09:10] <lu_zero> elenril: objC is less annoying that C++ [20:09:25] <ohsix> objc is nice [20:09:35] <lu_zero> elenril: here you have the gnustep stuff [20:09:44] <elenril> being less annoying than c++ isn't that hard ;) [20:10:09] <ohsix> it makes the conceptual leap/break to objects pushed down that much more; and what is used there plays a different role, its not simply "everything" [20:10:13] <lu_zero> still I'd suggest to rewrite gcc using pypy [20:10:51] <lu_zero> python is a wonderful language [20:11:02] <elenril> meh, rewrite it in sendmail config [20:11:33] <lu_zero> I'm blessed to never ever having to do that [20:12:37] <ohsix> then all you need is m4 to bootstrap, genius! :D [20:13:44] <lu_zero> write a compiler using a template language... [20:13:55] <lu_zero> sigh [20:14:48] <ohsix> all you're doing is expanding sequences anyways; you'd write another tool for minifcation [20:15:04] <lu_zero> using ... [20:15:07] <lu_zero> awk [20:18:04] <wbs> hyc: ping, care to test the start_time vs cur_pts vs whatever-ffserver-patch that I posted now? it should almost be ok with baptiste now, I think.. [20:18:38] <ohsix> btw i don't remember who mentioned gccgo and google; but the guy that does it is a google employee [20:22:06] * lu_zero did [20:22:29] <lu_zero> the googler seems to love C++ [20:23:14] <ohsix> he's probably responsible for it a bit at google; i wouldn't say he's exuding fanboyism or whatever, he speaks plainly [20:23:58] <ohsix> if anything gccgo is an embodiment of what he really likes :] [20:24:23] <lu_zero> I really wonder why they don't propose a C with templates if they are that focused on performance [20:24:34] <Dark_Shikari> but C has templates. [20:24:57] <ohsix> anyone that likes c++ knows about its warts [20:25:18] <lu_zero> using preprocessor or using something more exotic? [20:25:37] <lu_zero> or C with aspects/decorators [20:25:37] <ohsix> and with gcc you can make some templates type safe :] but not generic [20:27:22] <lu_zero> I just hope with a fork once they start hosing their own systems [20:27:40] <ohsix> maybe we'll get an egcs 2.0 type schism [20:27:52] <lu_zero> would be great [20:29:51] <lu_zero> at least in the end they could pick the nice bits from each fork [20:30:01] <ramiro> where can I get a list of all ix86, pentiumpro, etc, cpu options for gcc and what each one enables? [20:30:19] <janneg> man gcc [20:30:20] <lu_zero> I wouldn't mind having g++ written in C++ [20:30:42] <lu_zero> like the ada front end is written in ada [20:31:01] <ramiro> janneg: oh, that was embarrasing =) [20:32:12] <ohsix> ada frontend being written in ada was kind of annoying for me when i wanted to play with it; i couldn' tbootstrap it on gentoo [20:33:32] <lu_zero> ohsix: guess what happens when you have everything in C++ [20:33:48] <ohsix> i can't, i'm silly! [20:34:09] <peloverde> just cross on something else to build your bootstrap compiler [20:34:09] <lu_zero> =P [20:34:11] <ohsix> the c++ subset they're looking for might well be buildable with xgcc for a long while [20:34:38] <ohsix> slippery slope arguments are dumb; but i do wonder about the timeframe [20:34:38] <lu_zero> ohsix: I hope so [20:37:30] <lu_zero> right now I read more than often discussing about virtual, not restrict anything and such [20:38:43] <lu_zero> you seem to see it quite brightly [20:39:00] <lu_zero> I'm probably overly gloomy [20:40:36] <ohsix> i'm confident they aren't set to ruin it, at least [20:41:20] <ohsix> and everyone was quite collegial in the discussion, even the "pro" c++ people had at the forefront the things that are a possible drawback [20:41:51] <ohsix> best i can hope for is that no mangling leaks into any abi i might have to use in the future [20:43:08] <mru> I'm convinced they're not _intentionaly trying_ to fuck it up [20:43:26] <mru> but they've done a good job of fucking stuff up without trying while not using c++ too [20:43:31] <Tjoppen> BBB: poke [20:44:55] <ohsix> and imo; they started slipping in this direction when they allowed plugins, they had been opposed to such things for a great length of time, c++ might just be an option in the same vein in the end [20:45:26] <mru> the reasons for disallowing plugins in the past were just as wrong as the reasons for allowing them now [20:49:45] <peloverde> In the past: trying to come up with arcane reasons to make code inseparable from GCC so it had to be GPL'ed? now: cargo-cult imitation of LLVM? [20:50:52] <lu_zero> since they did so well in a relatively short timespan why not copy? [20:51:02] <lu_zero> llvm is also bsd [20:51:07] <lu_zero> so an enemy of gnu [20:53:35] <ohsix> i'd be hard pressed to call it imitation [20:54:01] <ohsix> if anything its simply not as exciting, i don't think the c++ or the plugin thing is related [20:55:00] <ohsix> they're just softening some hard lines they've had in the past; and the long flaming threads that went with them [20:55:22] <ohsix> i couldn't say what they'd do next, though [21:03:44] <BBB> Tjoppen: pong [21:07:45] <BBB> (probably re: http, didn't finish yet :( ) [21:08:35] <Tjoppen> k [21:15:24] <KotH> Dark_Shikari: i rather wanted to know whether 1) we are allowed to keep them and 2) whether they are worth to be kept [21:15:40] <Dark_Shikari> KotH: I dunno, if the bugs haven't been fixed yet... [21:16:57] <KotH> Dark_Shikari: and are we allowed to keep them? [21:17:10] <Dark_Shikari> probably not. [21:17:21] <Dark_Shikari> I mean, if the bugs still haven't been fixed, they probably will never be fixed. [21:18:29] <KotH> ok, i'll drop a mail to -devel [21:18:32] <KotH> thanks! [21:19:56] <Dark_Shikari> KotH: why not just delete them [21:21:41] <KotH> i dont want to delete stuff someone else might be working on [21:27:09] <Dark_Shikari> KotH: if they're working on it, they already have it [21:27:12] <Dark_Shikari> feel free to back it up if you want [21:28:29] * KotH keeps a 3 months backup of the samples [21:58:29] <CIA-92> ffmpeg: stefano * r23431 /trunk/libavformat/nutenc.c: [21:58:29] <CIA-92> ffmpeg: Make write_streamheader() and write_headers() accept an [21:58:29] <CIA-92> ffmpeg: AVFormatContext * in input rather than a NUTContext *, which allows to [21:58:29] <CIA-92> ffmpeg: log messages with av_log(). [21:58:29] <CIA-92> ffmpeg: stefano * r23432 /trunk/libavformat/nutenc.c: [21:58:30] <CIA-92> ffmpeg: Make write_header() and write_header() return an error code in case of [21:58:31] <CIA-92> ffmpeg: error. [21:58:31] <CIA-92> ffmpeg: stefano * r23433 /trunk/libavformat/nutenc.c: [21:58:32] <CIA-92> ffmpeg: Make write_streamheader() return a meaningful error code if no codec [21:58:32] <CIA-92> ffmpeg: tag is defined, rather than return -1. [21:58:33] <CIA-92> ffmpeg: stefano * r23434 /trunk/libavformat/nutenc.c: [21:58:33] <CIA-92> ffmpeg: Make write_streamheader() log a message if there is no codec tag [21:58:34] <CIA-92> ffmpeg: defined. [21:59:13] <Dark_Shikari> mru: arm guy is back, so we'll get that tested. [22:00:26] <j0sh_> wbs: lu_zero: did you know there's a realplayer variant on the rtsp-http tunnel? [22:01:42] <CIA-92> ffmpeg: stefano * r23435 /trunk/libavcodec/raw.c: Remove weird empty line and perform vertical align. [22:01:53] <BBB> j0sh_: awesome, gimme [22:02:05] <BBB> j0sh_: or you can write it also ;) [22:02:40] <j0sh_> i know, just happened to find it by chance when a friend sent me some files she couldn't play [22:03:25] <j0sh_> http://cancer.ucsd.edu/DeafInfo/asl_cervical.asp [22:03:55] <j0sh_> the .rm files are like sdp files with a rtsp url, i wiresharked it, it's basically rtsp-over-http [22:05:01] <j0sh_> it doesnt play right now, they prob have other particular requirements [22:05:06] <j0sh_> for headers etc [22:06:17] <CIA-92> ffmpeg: mru * r23436 /trunk/libavcodec/arm/mpegvideo_arm.c: [22:06:17] <CIA-92> ffmpeg: ARM: check struct offsets only when they are used [22:06:17] <CIA-92> ffmpeg: The offsets differ depending on configuration, so only check them when [22:06:17] <CIA-92> ffmpeg: they will actually be used. Presently, this is when NEON is enabled. [22:08:26] <BBB> j0sh_: we support real-rdt [22:08:28] <BBB> let me look [22:08:43] <CIA-92> ffmpeg: mru * r23437 /trunk/libavcodec/arm/ (h264dsp_init_arm.c h264pred_init_arm.c): ARM: remove some unnecessary ifdefs, fix implicit declaration warnings [22:13:38] <BBB> the site is down [22:13:42] <BBB> I can't play any of the movies [22:13:49] <BBB> (the rtsp host, not the http host) [22:14:05] <j0sh_> BBB: the behavior is very similar, down to the x-rtsp-tunnelled typo [22:14:18] <j0sh_> yeah i know, it takes a while for the videos to actually start playing [22:14:22] <j0sh_> with realplayer [22:14:34] <mru> buffering [22:14:37] <j0sh_> haven't been able to make a connection with ffplay yet [22:14:43] <BBB> the site is actually down here [22:14:58] <BBB> unless the cloakport option does something weird, like a tickle-me-password [22:15:15] <mru> they have a cloaking device? [22:15:16] <j0sh_> thats what im thinking, there are a coupleof undocumented urls [22:15:32] <j0sh_> s/urls/headers [22:16:24] <BBB> I can't even connect [22:16:28] <BBB> not even an options [22:16:39] <BBB> what I mean is that the cloakport option makes it tickle the server [22:16:44] <BBB> which then opens a connection [22:16:56] <BBB> can you test that by feeding realplayer with and without the cloakport option? [22:17:15] <BBB> (the url = rtsp://137.110.125.34:554/cervicalCancer/CE_03.rm?cloakport=8080,554,7070) [22:17:23] <Dark_Shikari> mru: confirmed [22:17:24] <Dark_Shikari> your patch works. [22:17:27] <BBB> so open rtsp://137.110.125.34:554/cervicalCancer/CE_03.rm?cloakport=8080,554,7070 [22:17:32] <BBB> and then rtsp://137.110.125.34:554/cervicalCancer/CE_03.rm [22:17:33] <mru> Dark_Shikari: not my patch [22:17:36] <mru> and it no longer applies [22:17:38] <Dark_Shikari> ok whatever [22:17:40] <Dark_Shikari> wait what? [22:17:42] <Dark_Shikari> why doesn't it [22:17:46] <mru> I moved things around [22:17:49] <Dark_Shikari> oh I see [22:18:05] <Dark_Shikari> it does them on compile-time? [22:18:14] <mru> it checks them [22:18:17] <Dark_Shikari> k [22:18:27] <mru> detecting is impossible [22:18:37] <Dark_Shikari> wait, why? [22:18:46] <mru> you can't use offsetof in asm [22:18:48] <Dark_Shikari> you couldn't run a script to compile, print offsetof, and embed it into the asm? [22:18:59] <mru> can't run cross-compiled code [22:19:14] <Dark_Shikari> offsetof is a compile-time constant [22:19:17] <Dark_Shikari> you could inspect the binary for it [22:19:22] <mru> target-depedendent [22:19:26] <Dark_Shikari> OK so we're getting absurd here. [22:19:35] <Dark_Shikari> wait, there are targets where offsetof isn't compile-time constant? [22:19:39] <mru> no [22:19:57] <Dark_Shikari> but what's the deal with checking [22:20:00] <Dark_Shikari> I don't see how that solves the probelm [22:20:09] <Dark_Shikari> if you don't commit that patch, your code won't run on ipad [22:20:10] <mru> it prevents a build with wrong offsets [22:20:11] <Dark_Shikari> even if you check it [22:20:17] <Dark_Shikari> ok, yeah, but why not support it while you're at it? [22:20:29] <mru> I didn't say I wouldn't [22:20:32] <Dark_Shikari> ah k [22:21:12] <mru> but I need to know what predefined macros apple-gcc sets [22:21:21] <mru> the ifdef in yuvi's patch is wrong [22:21:28] <Dark_Shikari> k [22:22:10] <j0sh_> BBB: wireshark shows it's opening tcp connections on all 3 'cloakports', will test them without [22:22:21] <mru> does it set something like __APPLE__? [22:23:31] <j0sh_> ports are on the remote side though [22:23:45] <BBB> j0sh_: it's a tickle-me "password" [22:24:10] <BBB> we can probably implement support for that also [22:24:11] <j0sh_> is that the industry-standard term? tickle-me-password? [22:24:15] <BBB> no [22:24:17] <j0sh_> lol [22:24:18] <BBB> I forgot how it's called [22:24:26] <BBB> it's tickle-something [22:24:55] <BBB> portknocking [22:25:00] <BBB> http://www.portknocking.org/ [22:25:40] <BBB> http://en.wikipedia.org/wiki/Port_knocking [22:25:48] <BBB> I always thought it was called tickling [22:26:01] <j0sh_> ahh i see [22:27:06] <BBB> if you want, document this somewhere (links to the page having the playlists, cloakport uri, etc., maybe a wireshark log from realplayer, link to wikipedia, all on a multimediawiki page [22:27:07] <BBB> ) [22:27:18] <BBB> then later we can implement this [22:28:23] <j0sh_> ok awesome will do [22:29:06] <BBB> my mind must be dysfunctional, not sure what the tickling thing came from [22:29:07] <BBB> :) [22:29:30] <j0sh_> i like the term better at the very least [22:29:55] <j0sh_> i dont have a multimediawiki account, who do i ping for one [22:30:01] <mru> mike [22:30:06] <mru> @multimedia.cx [22:36:38] <j0sh_> thanks [22:37:09] <lu_zero> interesting [22:37:15] * lu_zero wakes up for a bit [22:41:22] <Honoome> lu_zero: what is interesting? [22:41:38] <lu_zero> rtsp-real in http [22:41:52] <lu_zero> with additional port knocking [22:42:04] <lu_zero> and tre way secret salute or something like that [22:42:22] <CIA-92> ffmpeg: mru * r23438 /trunk/libavcodec/arm/asm-offsets.h: ARM: struct offsets for Apple ABI [22:42:23] <mru> three-finger salute more likely [22:42:43] <Honoome> lu_zero: without me going over the history, care to fill me in? is it something I need to implement in feng tonight? :P [22:42:50] <lu_zero> no [22:42:57] <Honoome> mru: one finger “fuck you” is better suited to Real [22:42:57] <mru> tomorrow night [22:42:59] <lu_zero> it's something BBB will play with [22:43:16] <mru> Dark_Shikari: you got your offsets now [22:43:26] <mru> please confirm they are correct [22:43:26] <lu_zero> we should fix sctp [22:43:27] <Dark_Shikari> k, great [22:43:39] <lu_zero> and I should complete the ffmpeg side =P [22:43:52] <mru> I have no desire to attempt an actual apple build [22:44:20] <j0sh_> BBB: the port tickling doesnt seem to do anything [22:44:32] <j0sh_> plays fine without it, at least [22:46:20] <BBB> doesn't play for me :'( [22:46:29] <BBB> maybe because your host already tickled with realplayer [22:46:39] <BBB> (as you can see, it's not very secure ;-) ) [22:46:44] <j0sh_> try port 8080 [22:46:59] <lu_zero> rtsp://137.110.125.34:554/cervicalCancer/CE_03.rm is the url? [22:47:04] <j0sh_> which seems to be the default [22:47:19] <j0sh_> s/554/8080 [22:47:22] <BBB> 8080 is for the http [22:48:42] <j0sh_> the get/post handshake is done on 8080, yeah [22:48:43] <lu_zero> rtsp://137.110.125.34:8080/cervicalCancer/CE_03.rm does something [22:49:02] <j0sh_> yeah [22:49:15] <BBB> that plays like shit :-( [22:49:20] <BBB> the subscribe rule is messed up [22:49:30] <BBB> does your wireshark log have the subscribe rule used by realplayer? [22:49:37] <BBB> (part of the rtsp session) [22:50:31] <j0sh_> let me base64 decode the rtsp :) [22:51:08] <hyc> wbs: you email asking me to test attached patch had no attachment [22:51:58] <Honoome> does anybody have experience with writing Wireshark dissectors? :p [22:52:09] <Honoome> having a RTSP-in-HTTP dissector to auto-decode base64 would be nice ;) [22:52:42] <hyc> I've written EtherPeek dissectors, haven't looked at wireshark [22:55:59] <lu_zero> btw j0sh_ where are your patches? [22:56:00] <j0sh_> wireshark is a pain, it refuses to recognize anything as http [22:56:11] <j0sh_> i can send them now, but darwin still hangs [22:56:18] <lu_zero> I see [22:57:00] <j0sh_> lu_zero: wanted to fix dss first but maybe i missed something obvious you guys can spot [22:59:49] <j0sh_> lu_zero: patches sent to ffmpeg-soc [23:00:11] <Honoome> lu_zero: do you need something urgent from me? [23:00:41] <BBB> j0sh_: I'll review the patches tomorrow [23:00:43] <lu_zero> I'm about to sleep so, no [23:00:45] <BBB> or at least not today :) [23:00:54] <j0sh_> lol alright [23:01:02] <j0sh_> BBB: still trying to find that subscribe rule [23:01:05] <Honoome> good because I'm going to play snooker! :P [23:01:16] <lu_zero> if you want to fix sctp after you are welcome ^^; [23:01:18] <Honoome> hm first I'll open a bug though [23:01:24] <BBB> j0sh_: should be right before the PLAY command [23:01:29] <Honoome> lu_zero: I'll fix it tomorrow… maybe :P [23:01:38] <BBB> like this: [23:01:38] <BBB> SET_PARAMETER rtsp://137.110.125.34:8080/cervicalCancer/CE_03.rm RTSP/1.0 [23:01:39] <BBB> Subscribe: stream=0;rule=0,stream=0;rule=1,stream=1;rule=0,stream=1;rule= [23:01:43] <lu_zero> tomorrow we'll also play with the hammer and the new feng [23:01:52] <lu_zero> wbs: you are welcome to join the fun =) [23:06:16] <j0sh_> BBB: got it [23:07:00] <j0sh_> http://ffmpeg.pastebin.com/uVMzrBic [23:07:10] <j0sh_> lemme get the response [23:09:13] <j0sh_> BBB: is it normal to send more than one cseq in the same packet? [23:09:36] <BBB> not that I know [23:09:59] <BBB> what is that stuff in line 8? cseq: 5? [23:10:27] <j0sh_> i guess so, it didnt get decoded properly [23:10:36] <j0sh_> theres a lot of junk in each packet [23:10:44] <BBB> that is the actual subscribe rule, I think ;) [23:10:57] <j0sh_> response: http://ffmpeg.pastebin.com/t5r2aKRD [23:11:21] <j0sh_> (that is one 1448-byte data packet) [23:11:31] <BBB> I need the request for cseq: 5, if you have it [23:12:26] <BBB> the base64-encoded one is ok also [23:12:38] <BBB> you can just chop off characters at the front until it decodes to something normal [23:12:53] <BBB> probably, one character is missing or extra or so, causing the decoding to be out of sync [23:13:13] <BBB> (thus it leads to the crap you see in line 8) [23:13:28] <j0sh_> here's cseq 5 [23:13:31] <j0sh_> http://ffmpeg.pastebin.com/hchqW1E9 [23:14:02] <j0sh_> they were all jumbled in the same string which confused the base64 decoder [23:14:28] <BBB> right [23:14:32] <BBB> do you have the sdp also? [23:14:46] <BBB> if so, can you throw all that together in an email or issue tracker entry so I don't forget? [23:14:50] <BBB> this is an actual bug, I think :) [23:15:21] <j0sh_> the sdp is huuuuge [23:15:26] <BBB> that's ok [23:15:54] <j0sh_> will assemble something in roundup for you [23:15:59] <BBB> ok, great [23:16:23] * BBB fears he'll get addicted to mario galaxy 2 sometime soon [23:16:33] <BBB> I'm buying it next week, and I'm already addicted to the online videos of it [23:18:01] <Dark_Shikari> mru: we got it working. still have some issues unrelated to decoding, but it's a crapload faster [23:18:01] <j0sh_> the sdp has some stuff encoded in it [23:18:04] <Dark_Shikari> also got rid of a per-frame memcpy [23:18:20] <Dark_Shikari> so yes, we can now play games at full screen on the ipad. [23:29:06] <mru> per-frame memcpy is evil [23:29:16] <Dark_Shikari> Yeah [23:29:19] <Dark_Shikari> it ate a crapton of memory [23:29:29] <Dark_Shikari> it was because we were previously using swscale, and swscale refused to output in a stride opengl would accept [23:29:33] <Dark_Shikari> you can't pass opengl arbitrary strides [23:29:36] <Dark_Shikari> stride must equal width [23:29:46] <Dark_Shikari> But now that we're not using swscale, lavc _does_ output to stride == width (for mod16) [23:30:29] <mru> is opengl really that crap or is that just apple being rotten as usual? [23:30:54] <Dark_Shikari> I think they only support an old opengl [23:31:22] <hyc> is this a difference between OpenGLES and full OpenGL? [23:32:03] <mru> opengles is mostly opengl old crap removed [23:33:48] <ohsix> and some winsys stuff folded in [23:33:51] <hyc> gaah. option setting between ffserver and ffmpeg is too different, can't directly share preset loading [23:34:01] <hyc> what a pain [23:41:37] <mru> Dark_Shikari: ot, is this table not telling something? http://ark.intel.com/Compare.aspx?ids=43544,47341,43560, [23:41:47] <mru> or is the i7 price just stupidly inflated? [23:42:50] <Dark_Shikari> it's just the cache [23:43:08] <Dark_Shikari> and lcock speed [23:43:27] <mru> that's what the table says, yes [23:43:34] <mru> I didn't think that quite justified the price hike [23:43:36] <peloverde> The I-7 has an 8GB memory limit? [23:43:49] <Dark_Shikari> I doubt that [23:43:53] <Dark_Shikari> this is the i7 mobile though [23:44:20] <mru> I'm thinking adding more ram for that money makes more sense [23:52:01] <iive> intel are known for their stupidly inflated prices, at least at the high-end products. [23:52:20] <ohsix> as stupid as people will stand :] [23:53:31] <iive> yep, they use the reverse logic. if something is that expensive, it must be incredibly good. [23:55:06] <kierank> price discrimination

1 0

IRC log for 2010-06-01
by irc＠mansr.com 02 Jun '10

02 Jun '10

[00:32:38] <peloverde> I've commented on AAC mapping and SBR backporting, was anyone else waiting on stuff from me? [00:56:43] <lu_zero> welcome janneg =) [00:59:24] <janneg> lu_zero: thanks [01:00:40] <janneg> peloverde: I think I'll look into latm since paul has vanished [01:06:38] <peloverde> janneg, ok thanks [01:06:46] <peloverde> if you need PS stuff pull from my git [01:07:24] <peloverde> I integrate patch feedback there during review so it should always be best/most-correct [01:25:20] <Kovensky> <saintdev> arch broke for me within 3 days... <-- doing it wrong [01:26:00] <Kovensky> <j-b> peloverde: Arch <-- arch is mostly unpatched and has an interesting package build system, you may want to try it [01:26:48] <peloverde> I'll consider it, it does seem somewhat interesting [01:27:26] <saintd3v> Kovensky: i'm completely used to doing everything myself, all i did was inatall, then update using pacman [01:27:32] <saintd3v> and broken system [01:27:51] <saintd3v> well more specifically X died [01:28:44] <Kovensky> hm, I wonder if you did it during the Xorg 1.6 debacle [01:29:22] <Kovensky> <@Dark_Shikari> The solution involved typing a variety of commands once logged in. <@Dark_Shikari> This doesn't help, since the bug is that the KEYBOARD IS BROKEN <-- what about booting in runlevel 2 and running them there instead [01:29:25] <saintd3v> dunno, i have friends that use arch and swear by it [01:30:03] <Kovensky> oh wait, ubuntu has no root password, in b4 runlevel 2 doesn't work [01:30:18] <Kovensky> well, either that or it'll give permission to anyone that boots in runlevel 2 [01:41:44] <j0sh_> lu_zero: why do all my base64 requests get a rREVTQ1JJQkUgcnRzcDovL2xvY2FsaG9zdDo0NTY3L2NhdGhlZHJhbC5tcDQgUlRTUC8xLjANCkFj [01:41:50] <j0sh_> oops [01:42:01] <j0sh_> i mean, why do they all get a rtsp 400 error [01:42:17] * j0sh_ curses his touchpad [01:43:17] <Compn> at least you didnt paste something embarrassing [01:43:18] <Compn> :P [01:44:15] <j0sh_> this isnt the first time its happened, im waiting for the day i have something embarrassing in the copy buffer [03:27:14] <Yuvi> does intra pred in h.264 use samples from before the loop filter? [03:27:41] <Dark_Shikari> yes [03:27:50] <Dark_Shikari> hence intra_border_backup [03:28:35] <Yuvi> what does lavc do? [03:28:51] <Dark_Shikari> same as x264 [03:28:59] <Dark_Shikari> it stores the intra pred pixels in an array [03:29:05] <Dark_Shikari> called intra_border_backup [03:29:06] <Dark_Shikari> then deblocks [03:29:11] <Dark_Shikari> then it predicts out of that array [03:29:21] <Yuvi> it'd be called something else then, git grep intra_border_backup shows nothing [03:29:31] <Dark_Shikari> ok, then look in x264. [03:29:54] <Dark_Shikari> oh [03:29:58] <Dark_Shikari> backup_mb_border [03:30:00] <Dark_Shikari> xchg_mb_border [03:30:01] <Dark_Shikari> etc [05:32:58] <lu_zero> yawn [05:33:52] <lu_zero> j0sh_: how so? [05:34:11] <Tjoppen> god morgon [05:34:20] <lu_zero> yawn morning [05:35:12] <lu_zero> j0sh_: send an email with the whole messages (possibly the wireshark tcp conversation text dump) [05:48:19] <j0sh_> lu_zero: ok i'll grab some dumps [05:48:58] <j0sh_> lu_zero: its probably something stupid on my end, since im getting the same error with feng and dss [05:50:04] <lu_zero> let's find out what's wrong =) [05:50:39] <lu_zero> you can use the latest vlc (and live555) to check the http-tunnel [05:51:19] <lu_zero> bbl [06:14:15] <j0sh_> lu_zero: vlc works, but i dont see a significant difference in the wireshark at first glance [06:14:26] <j0sh_> i probably need sleep [06:27:19] <av500> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [06:27:29] <av500> google fell into the ffvorbis trap? [06:27:40] <Dark_Shikari> yup [06:27:44] <Dark_Shikari> youtube encoded all their videos with ffvorbis [06:27:46] <Dark_Shikari> and still haven't fixed it [06:27:49] <Dark_Shikari> and afaik they're still doing it [06:28:34] <peloverde> It's bloltastic [06:29:17] <CIA-92> ffmpeg: siretart * r23399 /branches/ (0.6 0.6/ffmpeg.c): [06:29:17] <CIA-92> ffmpeg: ffmpeg: fail if user selected codec is experimental and strict_std_compliance > experimental [06:29:17] <CIA-92> ffmpeg: backport r23397 by janne [06:29:29] <peloverde> ^how relevant [06:30:43] <CIA-92> ffmpeg: siretart * r23400 /branches/ (0.6 0.6/ffmpeg.c): [06:30:43] <CIA-92> ffmpeg: ffmpeg: offer alternatives for experimental codecs if they exist [06:30:43] <CIA-92> ffmpeg: backport r23398 by janne [06:36:28] <lu_zero> ^^; [06:57:47] <CIA-92> libswscale: siretart * r31298 /trunk/ (3 files in 2 dirs): [06:57:47] <CIA-92> libswscale: remove palette8torgb15 and palette8tobgr15 [06:57:47] <CIA-92> libswscale: They contain exactly the same code as their 16bit variants, so this is [06:57:47] <CIA-92> libswscale: effectively code de-duplication. [07:08:57] <andoma> peloverde: fwiw, that dupe-channel AAC patch fixes playback for one of my previously undecodable 5.1 files, looks good imho [07:09:11] <peloverde> ok, thanks [07:46:08] <vipw> what would be the consequence of changing RTSP_DEFAULT_NB_AUDIO_CHANNELS from 2 to 1? [07:47:16] <CIA-92> ffmpeg: mstorsjo * r23401 /trunk/libavformat/ (10 files): Declare the url_write buffer parameter as const [07:47:33] <vipw> i saw a few emails from a couple years back, http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-November/012266.html [07:48:35] <vipw> as i understand from the SDP rfc (2327), the default should be 1 [07:50:12] <wbs> vipw: I think that makes sense, feel free to send that as a patch with this motivation included (quoting the relevant sections of the RFC) to ffmpeg-devel [07:53:59] <KotH> salve! [07:54:06] <av500> grÃŒezi [08:01:12] <kshishkov> Ð¿ÑÐžÐ²ÐµÑ [08:08:04] <CIA-92> ffmpeg: stefano * r23402 /trunk/libavcodec/ (opt.c eval.c avcodec.h eval.h ratecontrol.c): [08:08:04] <CIA-92> ffmpeg: Make ff_parse_expr() and ff_parse_and_eval_expr() return an int [08:08:04] <CIA-92> ffmpeg: containing an error code. [08:08:04] <CIA-92> ffmpeg: Allow these functions to convey the reason of the failure to the [08:08:04] <CIA-92> ffmpeg: calling function, failure which is not always due to a parsing error [08:08:04] <CIA-92> ffmpeg: but it may depend for example on a memory problem. [08:08:05] <CIA-92> ffmpeg: Also fix several potential memleaks. [08:08:05] <CIA-92> ffmpeg: stefano * r23403 /trunk/libavcodec/ (eval.c eval.h): (log message trimmed) [08:08:06] <CIA-92> ffmpeg: Cosmetics: rename ff_parse_expr() and ff_parse_and_eval_expr() parameters: [08:08:06] <CIA-92> ffmpeg: const_name -> const_names [08:08:07] <CIA-92> ffmpeg: const_value -> const_values [08:08:07] <CIA-92> ffmpeg: func[12]_name -> func[12]_names [08:08:08] <CIA-92> ffmpeg: func[12] -> funcs[12] [08:08:08] <CIA-92> ffmpeg: All these parameters contain a list of values, using plural names for [08:08:24] <CIA-92> ffmpeg: stefano * r23406 /trunk/libavcodec/eval.c: Fix eval-test compilation. [08:09:26] <KotH> j-b: did you get your svn account for dvdnav? [08:11:16] <j-b> not yet [08:11:35] <KotH> good, i'll create you one after the coffee break :) [08:12:06] <av500> create me a coffee please [08:13:22] <superdump> jag ocksÃ¥ [08:13:26] <kshishkov> av500: .ch is not famous for coffee, ask somebody like wbs instead [08:13:30] <superdump> mmmm kaffe [08:13:43] <andoma> kaffe it is! [08:13:55] <j-b> Can I have some coffee too? [08:13:55] <av500> kshishkov: KotH is not your pure bred swiss, is he? [08:13:56] * kshishkov drycka inte kaffe [08:14:06] <superdump> jag vill ha frukost nu! [08:14:24] * superdump looks at andoma [08:14:33] <kshishkov> av500: good point but he's not in Turkey anymore [08:14:43] <av500> nor in Kansas [08:15:09] <av500> j-b: you did not have a coffee + cigarette for breakfast? [08:16:07] <j-b> I don't smoke ... (anymore) [08:23:23] <vipw> wbs: ok, i sent a patch [08:26:42] <j-b> KotH: I am just very glad the work on dvdnav is resuming [08:26:51] <j-b> and that we stop to have 20 forks of it [08:29:02] <spaam> just wait until uau make one.. [08:43:44] <KotH> j-b: that was the reason why nico originally forked it [08:44:07] <thresh> to have 20 forks? [08:44:08] <j-b> well, true, but it was quite calm since the last 4 month [08:44:27] <j-b> and handbrake and VLC had still quite a few patches [08:44:38] <j-b> it is cool that this is getting solved [08:54:10] <j-b> So far I haven't seen any lawyer or person involved with the two projects claim that it is. And random people on the internet don't count." [08:54:21] <j-b> peloverde: you are random people on the internet [08:57:34] <lu_zero> j-b: uh? [08:57:38] <lu_zero> (good morning btw) [09:00:02] <wbs> vipw: I can't see any such patch on ffmpeg-devel [09:02:18] <j-b> lu_zero: the blog from gnome [09:02:42] <KotH> j-b: where is that quote from? [09:03:14] <vipw> yeah, i can't see it either [09:03:55] <vipw> if it doesn't show up today i'll resend it [09:04:49] <vipw> ffmpeg-devel(a)mplayerhq.hu is the address, right? [09:05:30] <wbs> yes, but you need to be subscribed, too [09:06:00] <vipw> oh, just what i always wanted [09:06:09] <j-b> http://blogs.gnome.org/otte/2010/05/31/youtube-out-of-the-box/ [09:06:26] <kshishkov> wasn't it posted here yesterday? [09:06:34] <j-b> yes [09:06:47] <j-b> but the comment about 'random people' is new [09:08:49] <KotH> lol [09:09:10] <av500> j-b: the logic is good, unless a lawyer says otherwise, licences are compatible by default.... [09:09:16] <KotH> "i'm too lazy to check the facts myself, so i trust someone who is paid to lie to other people" [09:11:02] <kshishkov> KotH: yes, that's what voting is all about [09:11:26] <j-b> av500: I like that one too :D [09:15:18] <hyc> wbs: hmmm... sounds like you're saying I need to make these things into public APIs [09:15:37] <hyc> otherwise, have to split it apart again and back to square 1 re: code cuplication [09:15:42] <wbs> hyc: yes, if lavf is supposed to use something from lavc, it should be a public API [09:15:45] <wbs> yeah [09:16:46] <hyc> I figure I'd wait for Michael to comment on the h264.c patches first [09:16:54] <wbs> yeah, that's probably a good idea [09:19:28] <av500> file under "codec wrappers to hate": https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [09:22:44] <scaphilo> hi there i have a syntax error in the intreadwirte.h, has anyone an idea why? I wantet to build ffmpeg with my own makefile.http://dpaste.com/201762/ [09:23:09] <scaphilo> its because i wantet to use hardwaretimers on my embedded system [09:23:28] <av500> and therefore you need your own makefile? [09:24:05] <av500> a hardwaremakefile? [09:24:06] <scaphilo> its easyer yes, but if ffmpeg does not compile with a automakefile ill finde an other way [09:24:16] <scaphilo> for the niosII [09:24:35] <scaphilo> it already compiles and runs with the ffmpeg make file [09:24:42] <av500> so? [09:25:12] <hyc> that wasn't challenging enough... [09:25:20] <scaphilo> but now i want to get the exact time of a macroblock decoding or macroblock encoding [09:25:26] <scaphilo> :-) [09:25:37] <av500> so? [09:25:47] <av500> why do you need a different makefile for that? [09:26:55] <scaphilo> hmm when you ask me like that ... i have to think again. It works of cause but its a little bit more complicated [09:27:23] <scaphilo> because the hardware timer are defined in an other library [09:27:40] <av500> so, link against that lib [09:27:55] <scaphilo> your right hmm i was sure there is a problem... [09:28:48] <scaphilo> so you think there is no easy way to make a build of ffmpeg with a automake file [09:29:10] <scaphilo> i wrote a script to set all includes in the right way already [09:29:13] <wbs> easy or not, it's not supported and it's all up to you if you want to do it that way, but don't expect any support in that case [09:29:21] <av500> scaphilo: and what for? [09:29:56] <scaphilo> ah your right will find an other way it s better, perhaps ill have to come back because i was sure there is a problem i cant solve [09:30:56] <scaphilo> anyone here that can tell me how much faster the arm uc is with the asm files than with the c files? [09:31:11] <Dark_Shikari> "uc"? [09:31:20] <scaphilo> well the transcoding [09:31:31] <scaphilo> is that about a factor 2 or more? [09:31:48] <Dark_Shikari> wtf is a uc [09:31:53] <scaphilo> microcrontroller [09:33:04] <Dark_Shikari> but what are you doing with ffmpeg [09:33:06] <Dark_Shikari> faster at what [09:33:12] <scaphilo> how much faster is it on the i386 with the asm files? Has anyone tested that [09:33:27] <scaphilo> the frame transcoding from mpeg2 to mpeg4 [09:33:57] <scaphilo> i currently have about 10fps with a 320x180 video [09:34:14] <Dark_Shikari> what arm? [09:34:23] <scaphilo> niosII (Altera) [09:34:43] <scaphilo> on the computer its without asm about 800 fps [09:34:43] <Dark_Shikari> v7, v6, v5...? [09:35:01] <scaphilo> are there verions? [09:35:06] <Dark_Shikari> lo [09:35:08] <Dark_Shikari> l [09:35:26] <scaphilo> hey man what you mean [09:35:53] <Dark_Shikari> I mean that you should know what instruction set your own CPU uses. [09:36:49] <scaphilo> am ... no not yet. ARM processors use different instruction sets but im not sure NIOSII does [09:36:53] <hyc> aww... I don't know which SSEx my CPU supports.... [09:37:37] <scaphilo> but that does not mather now, i was just wondering if it makes sens to write asm files for the nios [09:38:02] <scaphilo> perhaps its better to leave it with c flies and make some hardware for mb-transcoding [09:38:08] <Dark_Shikari> I can't answer that until I know what instruction set it uses. [09:38:45] <av500> http://en.wikipedia.org/wiki/Nios_II [09:39:19] <Dark_Shikari> er... that's not an ARM [09:39:27] <av500> no [09:39:31] <scaphilo> yes thats what i said [09:40:10] <scaphilo> how much faster is a transcoding process with this asm files on the computer? [09:40:18] <scaphilo> is it a factor 2 or more [09:40:20] <Dark_Shikari> "asm" does not magically make things faster [09:40:22] <Dark_Shikari> SIMD makes things faster [09:40:25] <Dark_Shikari> asm is just a way to write SIMD [09:40:30] <Dark_Shikari> if your processor has no SIMD unit, asm is useless [09:40:42] <scaphilo> ah ok i see [09:40:45] <av500> scaphilo: well, you are on an FPGA, make a SIMD unit [09:40:51] <scaphilo> exaclty [09:41:00] <av500> Dark_Shikari: instruction set looks pretty basic [09:41:11] <Dark_Shikari> av500: or just make an idct unit [09:41:12] <Dark_Shikari> and dct unit [09:41:14] <Dark_Shikari> and mc unit [09:41:16] <Dark_Shikari> ;) [09:41:19] <Dark_Shikari> and sad unit [09:41:22] <scaphilo> thats what im going to do but i was wondering if there is any benefit of writing some parts in asm [09:41:24] <av500> and happy unit [09:41:36] <scaphilo> i have no dct anymore ;-) [09:41:41] <scaphilo> no mc/me anymore [09:41:54] <Dark_Shikari> then what in the world would you asm? [09:42:07] <Dark_Shikari> how about you do a profile before talking about asm? [09:42:20] <av500> asm makes everything faster [09:42:35] <wbs> it's like magic [09:42:37] <Dark_Shikari> yes, via MAGIC [09:42:42] <scaphilo> i first have to find the critical part. thats why i want to implement a hardware timer (what my first question was about) [09:42:46] <kshishkov> and [09:42:50] <scaphilo> :-) [09:42:54] <Dark_Shikari> scaphilo: er... [09:42:55] <kshishkov> gcc -O-3 makes everything slower [09:42:57] <Dark_Shikari> why not just run it on your cpu? [09:42:58] <Dark_Shikari> and oprofile it? [09:43:02] <Dark_Shikari> sure it won't be 100% accurate [09:43:05] <Dark_Shikari> but it'll be decently close. [09:43:28] <av500> not sure he runs linux [09:43:37] <av500> scaphilo: do you? [09:43:44] <scaphilo> im running linux but i dont know what oprofile does [09:43:49] <Dark_Shikari> man oprofile [09:43:49] <av500> google knows [09:43:50] <scaphilo> ah you mean on the nios [09:43:55] <av500> yes [09:44:02] <scaphilo> no theres no linux [09:44:04] <scaphilo> sorry [09:44:08] <scaphilo> missunderstood that [09:44:48] <scaphilo> the only thing this chip does is read file over usb transcode and write it back [09:44:49] <spaam> kshishkov: so with -O+9001 it going to be fast? [09:44:56] <Dark_Shikari> scaphilo: so profile it on your computer [09:44:58] <Dark_Shikari> not the nios [09:45:28] <scaphilo> that sounds like a good idea :-) [09:46:02] <scaphilo> but my customer is a bit strange as you know and he wants hardware "profiling" [09:46:35] <scaphilo> thank you for all ideas [09:46:47] <kshishkov> spaam: no, with -O9001 it will produce the same crap on any GCC version [09:46:49] <Dark_Shikari> sure, you can do hardware profiling later [09:46:55] <Dark_Shikari> But why not start with something you can do here and now [09:47:30] <av500> scaphilo: this is a commercial project? [09:47:39] <scaphilo> unfortunatly i have a meeting on frieday about that point [09:47:41] <scaphilo> yes it is [09:47:49] <Dark_Shikari> oprofiling takes 5 minutes [09:47:51] <Dark_Shikari> do it now [09:48:07] <scaphilo> ? thats that easy never did that befor [09:48:14] <scaphilo> with what tool? [09:48:31] <scaphilo> ill google [09:48:44] <Dark_Shikari> .... [09:48:45] <Dark_Shikari> WITH OPROFILE [09:48:48] <Dark_Shikari> .................. [09:49:02] <Dark_Shikari> You know how you vacuum your house? WITH A VACUUM. [09:49:11] <scaphilo> shame on me [09:49:29] <scaphilo> ill google now [09:49:48] <av500> Dark_Shikari: open gas valve, wait, then throw match works as well.... [09:50:30] <KotH> .o0(note to self, never enter a house that av500 has cleaned up) [09:50:35] <kshishkov> av500: s/throw/light a/, that's enough [09:50:52] <av500> kshishkov: if you want new haircut at the same time, yes [09:50:56] <kshishkov> KotH: but it will be cleaned really good - and disinfected in the same time too! [09:51:59] <hyc> dunno where these guys learn to be software developers, if at all. anybody who thinks you need to replace the makefile just 'cause you want to add a library or include path ... sigh... [09:52:26] <j-b> hyc: have you been to a "modern" CS course? [09:52:41] <KotH> hyc: people who learn programming in companies never learn how to do things the right way [09:52:51] <av500> hyc: at the "<random indian city> Institute of Technology" [09:53:13] <kshishkov> j-b: I don't think they learn about Makefiles at all there [09:53:13] <ohsix> or just because you don't like autotools ;] [09:53:14] <KotH> hyc: you've to be very luck to have someone to tutor you. in most companies you come fresh out of school and are expected to be a competent programmer [09:53:16] <j-b> even in the US [09:53:52] <hyc> KotH: yeah, I'd expect that too. I was a competent programmer before I got into college. [09:53:53] <j-b> kshishkov: well, once you have done the "java" course, you think that any modification of the build-system must be rewritten for a tiny change [09:54:33] <KotH> hyc: you are an exception. most people learn the basics of programming in school/college/university, then enter a company, never learning what it really means to do software development [09:54:40] <Kovensky> j-b: build system? what build system? [09:54:48] <kshishkov> j-b: actually I did [09:54:53] <Kovensky> don't you just click the green arrow on the compiler? [09:54:59] <KotH> hyc: heck, me, with my very low programming skills, am one of the most competent coders in our company [09:55:31] <av500> Kovensky: I call c:\compile.bat.... [09:55:46] <hyc> I find that bizarre. if you apply for a programming job in a company, that ought to mean you're able to do the job. :P [09:55:53] <av500> lol [09:55:59] <Kovensky> av500: better than my colleagues then; they call an IDE a "compiler" and can't do squat outside of one [09:56:05] <KotH> hyc: able != fully trained with 10y experience [09:56:08] <Kovensky> av500: blame my professors for that too <_< [09:56:18] <j-b> lol... 99% of people who apply to programming jobs don't have a clue about programming [09:56:25] <KotH> hyc: in all other jobs, people expect you to know the basics and will train you until you know the rest too [09:56:29] <av500> Kovensky: no, professor is not there to teach you how a makefile works [09:56:36] <Kovensky> all my programming professors so far have been incompetent; except for one but he quit during the first course we had with him so we were back to the incompetent ones [09:56:40] <KotH> hyc: it's just with programming that people expect that someone fresh from school has 10y of experience [09:56:43] <ohsix> hiring is a risk, too; sometimes you just have to live with the quality of the applicants, people make more money doing sillier things [09:56:49] <Kovensky> av500: no, but he shouldn't tell you that the IDE is a compiler [09:56:57] <Kovensky> and other dumb stuff [09:57:24] <Kovensky> like writing { int ary[10]; int i; for (i = 1; i <= 10; i++) { do_stuff_with(ary[i]); } [09:57:36] <av500> Kovensky: dont be so hard on them, some used to be physics phds selling fries... [09:57:39] <ohsix> he probably doesn't know what a linker is either; and barring having to work with a linker or do something outside of the ide it might as well not matter [09:57:51] <kshishkov> Kovensky: sounds like Pascal convert [09:57:56] <hyc> cripes. what did these *professors* study? most of my professors were all mainframe hackers in the '60s. [09:58:05] <Kovensky> kshishkov: he once wrote an entire program in pascal inside dev-c++ (lol) [09:58:14] <KotH> hyc: mainframe hackers died 10y ago [09:58:15] <KotH> :) [09:58:27] <Kovensky> and then spent 5 minutes trying to understand the syntax errors until he noticed what he did [09:58:27] <av500> KotH: no [09:58:37] <ohsix> died/absorbed by banking institutions still running cobol [09:58:57] <KotH> hyc: i once took a class in networking. our prof, one of the "renowed networking experts in europe" made at least one major mistake per hour... [09:59:20] <hyc> gack [09:59:31] <hyc> well, yeah, a lot of my profs did too [10:00:35] <KotH> and correcting him each time was the right decission: after that course he knew me well enough so that i got the credit points for another class of his w/o actually going there :) [10:00:47] <hyc> and some just had outdated info. my Op/Sys prof did the original work on the UMich mainframe OS, but I was also a part time employee at the Computing Center when I got to that class. [10:01:22] <hyc> so my day job was rewriting bits of ths OS, which I then got to tell him "no, it doesn't work that way any more" in the middle of lecture... [10:02:03] <hyc> KotH: nice! never got free credit before ;) [10:02:26] <spaam> KotH: so he was your new BFF? ;) [10:02:31] <KotH> hyc: you just have to be arrogant enough ;) [10:02:39] <KotH> spaam: BFF? [10:02:49] <spaam> KotH: Best Friends Forever [10:03:41] <KotH> spaam: nah.. [10:03:50] <KotH> spaam: i'm quite sure he didnt like me :) [10:04:22] <KotH> spaam: or would you like a student, not even half your age, correcting you all the time infront of 200-odd people? [10:04:56] <kshishkov> KotH: guess who was that student in my school? [10:05:04] <hyc> lol [10:05:17] <KotH> kshishkov: hmm... your brother? ;) [10:05:19] <hyc> well, he gave you credit for another course, and probably didn't have to. [10:05:28] <hyc> pr perhaps that was just his way of keeping you out of his class. [10:05:34] <kshishkov> KotH: unlike you I'm the only child [10:05:35] <spaam> KotH: no. :) [10:05:38] <KotH> hyc: more likely ;) [10:05:38] * av500 can understand that [10:06:51] <hyc> personally I was mortified that they were teaching binary arithmetic in a 300-level class, and most of my classmates had never seen it before [10:07:11] <KotH> huh? [10:07:17] <KotH> here, we had that in highschool [10:07:33] <KotH> (and a repetion in first semester math) [10:07:44] <hyc> even crazier since we had a 200-level course in logic design [10:07:50] <KotH> o_0 [10:08:23] <hyc> people who didn't make the connection between boolean,s transistors, and bits. incredible that they graduated. [10:08:25] <av500> hyc: I am sure there is non-binary logic :) [10:08:43] <Kovensky> lulz [10:08:48] <Kovensky> tales of college incompetence~ [10:08:54] <av500> inb4: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx [10:09:12] <Kovensky> kill -EOF av500 [10:09:17] <Kovensky> as if :/ [10:09:24] * Kovensky goes to college [10:09:53] <hyc> heh [10:10:09] <hyc> well, LDAP filter assertions are tri-state: true, false, undefined [10:11:15] <hyc> ooo, vdpau/vaapi/xvba [10:11:27] <KotH> hyc: 1149 9-valued logic :) [10:11:43] <hyc> I guess the most obvious point is that vdpau actually works, as opposed to xvba [10:11:52] <hyc> KotH: 1149? [10:11:59] <KotH> ieee1149 [10:12:01] <kshishkov> hyc: actually n-state logic is popular in modelling electronic schemes [10:12:18] <KotH> hyc: quite old ieee standard defining logic values for simulation in vhdl [10:12:22] <iive> hyc: do you have some link with actual content about xvba? [10:12:25] <KotH> hyc: among other things [10:12:41] <iive> all my googling ends in press releases. [10:12:53] <hyc> iive: not much beyond what I've read on phoronix [10:12:57] <hyc> which is all depressing [10:13:17] <hyc> http://www.phoronix.com/forums/showthread.php?t=19983 [10:13:43] <hyc> the last post by Gwenole Beauchesne is the clincher I think [10:14:08] <hyc> http://www.phoronix.com/forums/showpost.php?p=131086&postcount=822 [10:18:41] <hyc> well I guess we could go back to decimal computers or someesuch [10:19:07] <hyc> if this memristor stuff pans out we'll be doing analog computing... [10:19:30] <ohsix> stateless computing [10:19:31] <KotH> which reminds me, i still havent read how the memristor works ^^' [10:20:05] <KotH> ohsix: already known [10:20:11] <ohsix> its a programmable resistor; like you can program a transistor by its base, except it holds its value when its removed [10:20:14] <KotH> ohsix: search for "adeabatic switching" [10:20:30] <KotH> ohsix: i know what a memristor is, i just dont know how it works in detail [10:21:21] <iive> hyc: once again, articles... is there some code could be run, even if it have a pile of bugs? [10:21:54] <hyc> iive: yes, but according to posts in that thread, you won't get much from it [10:22:16] <iive> i want code... not articles and endless chain or url to other articles. pleaseeee [10:22:28] <hyc> http://www.splitted-desktop.com/~gbeauchesne/libva/ [10:22:59] <hyc> http://www.splitted-desktop.com/~gbeauchesne/ [10:24:54] <KotH> hyc: btw: analog computing is a dead end [10:25:06] <hyc> It also doesn't help that AMD hasn't made their API public / open source [10:25:15] <hyc> KotH: dead end? why? [10:25:26] <KotH> hyc: we've been there and it didnt work out and got replaced by digital computation in the 60s and 70s [10:25:51] <KotH> hyc: it is very hard to have fast and exact computation, heck even just exact computation is very difficult [10:26:05] <KotH> hyc: small variations in device characteristics have large effects on the results [10:26:16] <hyc> I think some of the path we've taken was dictated by the transistor [10:26:28] <hyc> memristor points down a different path... [10:26:49] <KotH> hyc: just as an example: the average transistor that comes out of a factory can have a variation in amplification in the range of two magnitutes [10:27:08] <KotH> bbl...lunch time [10:28:25] <hyc> I think binary/digital computation is hitting a wall. everything I read about going forward is about error correction and fault tolerance, because precise results cannot be relied upon at the component level [10:29:05] <hyc> magnetic disk drives have been there for years already - PRML heads... [10:30:11] <hyc> these memristor researchers are talking about them in terms of neurons - a unit is both a data storage and a computation unit at once [10:30:42] <hyc> as opposed to current transistor-based technology, processors distinct from RAM [10:31:27] <hyc> and also, nanoscale, talking about inherently unreliable / uncontrollable processes, which you make up for by massive redundancy [10:32:14] <ohsix> well you can pattern them in place into logic gates due to the way they function; or you can use that same state for memory type storage, all that persists if power is removed [10:32:22] <hyc> if they're really going to move forward with this model, emulating organic brains, it's all going to be analog [10:32:58] <twnqx> which basically means [10:33:09] <twnqx> you lose all the precision or all the speed [10:33:26] <hyc> twnqx: yes and no [10:33:32] <ohsix> nets solve problems by thresholding their inputs [10:33:36] <hyc> you have massively parallel processing [10:34:03] <twnqx> my brain has that, too [10:34:17] <twnqx> still takes me some time do calculate 16bit multiplications [10:34:21] <twnqx> to* [10:34:24] <hyc> yes. you may not be able to solve a single long sequence of calculations [10:34:27] <hyc> quickly [10:34:38] <hyc> but you can solve millions of other calculations simultaneously [10:34:51] <twnqx> that doesn't help for the applications of computers [10:34:59] <hyc> true [10:35:06] <hyc> it may very well be a dead-end in that respect. [10:35:32] <hyc> not much point in developing a machine that is just as slow and fallible as a human. [10:37:02] <hyc> and I think that's ultimately where these large mesh networks are heading... [10:37:43] <hyc> but ya never know. our brains do all these computations all the time, at a level beneath our consciousness [10:38:23] <hyc> kinda wonder why we don't have JTAG - did we really evolve this far without any form of introspection capability? [10:39:32] <hyc> it's like having a powerful CPU hidden under so many API abstraction layers that as an end-user you no longer have the ability to ask it "print x * 2" [10:40:55] <twnqx> which institution did you flee from? :X [10:41:42] <hyc> :P [10:44:17] <hyc> come on, you don't think reverse-engineering the human brain would be a cool hack? [10:48:50] <twnqx> having backup & restore would be... interesting, indeed [10:49:24] <twnqx> however there's more to it than just the neural network. [10:58:12] <Tjoppen> uncompressed 4k video in DPX format. a mere 19 GiB för 16 seconds [10:58:26] <Tjoppen> *for [11:03:42] <KotH> hyc: the error correction systems of modern cpus is not because components are a little bit out of spec, but because whole components fail [11:04:08] <KotH> hyc: this is mostly due to the extremely small sizes of todays electronics [11:04:19] <hyc> kotH: sure. and that gets worse as sizes decrease [11:04:26] <KotH> hyc: you'd have that problem with analog electronics too... in addition to the hardly controllable specs of the components [11:04:43] <merbzt> Tjoppen: care to resurrect the dpx patch ? [11:04:44] <KotH> hyc: yes, if we stick to the current technologies [11:05:05] <KotH> hyc: but all chip manufacturers know that by 2015 there needs to be a new technology to replace current CMOS [11:05:42] <KotH> hyc: if it isnt introduced by 2020, the current development of electronics and with it all of the computer and communication development will grind to a halt [11:06:29] <merbzt> KotH: so complete units in cpu's can fail ? [11:07:01] <merbzt> but continue to work via replacement paths ? [11:07:03] <KotH> merbzt: complete transistors [11:07:09] <merbzt> ok [11:07:10] <Tjoppen> merbzt: I see CODEC_ID_DPX.. I assume it's not in? [11:07:15] <KotH> merbzt: and with the transistors complete subuints [11:07:28] <Tjoppen> I have the standard in my hand (well, on screen) [11:07:30] <KotH> merbzt: which is different from the variations in the specs of analog components [11:07:39] <hyc> KotH: again, the memristor guys are talking about a mesh of billions of memristors, of which some percent are already flawed [11:08:01] <hyc> so you have to have noise tolerance / fault tolerance designed in from the start [11:08:08] <merbzt> Tjoppen: there are patches for dpx decode, just needs some fixing up, scavange the mailinglist [11:08:17] <KotH> hyc: you have that with curren CMOS processes as well :) [11:08:50] <Tjoppen> might have a look. I have to wrap DPX in MXF, and possibly transcode it later. in the latter case a codec is needed, but wouldn't hurt to get it done - it's not impossible [11:08:57] <KotH> hyc: actually, it was always necessary when driving the electronics to their technical limits, no matter which decade it was [11:09:08] <KotH> hyc: it just different effects you have to account for [11:09:09] <Tjoppen> although getting all pixel formats it can represent into lavc might be a bit.. interesting :o [11:09:39] <hyc> kotH: yeah I guess that's true [11:10:12] <merbzt> Tjoppen: the patch is in review round 13 or something, shouldn't take more then a few hours to get it in [11:10:27] <KotH> hyc: eg: until in the 80s everyone was using bipolar technology for logic. it was way better than anything cmos could do in most fields [11:10:44] <hyc> KotH: but it still sounds a little different. with ICs, get defects here and there and you scarp the entire device. [11:10:49] <hyc> scrap [11:11:02] <KotH> hyc: but things started to change when the number of transistors per cm^2 increased to a point where the power disipation couldnt be handled with bipolar anymore [11:11:22] <KotH> hyc: no, scraping whole devices is long gone [11:11:38] <KotH> hyc: even in the 80s, devices were just down-rated [11:12:17] <KotH> hyc: the distinction between different frequency classes are just the process variations (aka defects) during production. nothing else [11:12:55] <KotH> hyc: it's just that the number of parts are now so large, that you cannot reach the high specs of the circuit because 0.001% of the parts have lower specs [11:13:44] <KotH> hyc: hence they disable full subunits (eg use only 4 of teh 6 available cores). or build multiple units and select the ones used during the last step of production [11:13:51] <Tjoppen> found the dpx thread. reading it atm [11:14:06] <Tjoppen> also, might want to add raw image support to mxf demuxer [11:15:07] <KotH> hyc: the granularity of the redundancy is going down with continously, as people learn how to deal with the additional production complexity [11:15:08] <hyc> KotH: which puts an upper bound on the size and complexity of individual subunits... [11:15:18] <hyc> ok [11:15:18] <KotH> hyc: we already have that [11:15:51] <KotH> hyc: a chip is bound to about 2x2cm^2 size, due to manufacturing costs and clock distribution issues [11:16:12] <KotH> hyc: there are hardly any chips that are 3x3cm^2 or larger [11:16:14] <hyc> yes, that's a complete chip. and now a chip has multiple cores [11:16:29] <hyc> and distinct cache submodules, etc. [11:16:54] <KotH> the multi-core aproach grew exactly out of the problem that clock distribution and synchronization became impossible over the whole chip, so they split it into different clock domains [11:17:27] <KotH> (not to talk about that the signal delay for a signal crossing the chip grew into the region of one clock cycle) [11:18:05] <Tjoppen> oo, I see rgb48 was added to libswscale at least [11:18:21] <hyc> right, which is why we're not seeing massive increases in single-threaded processing speed any more [11:18:22] <Tjoppen> or.. it needs to output something else. hm [11:19:09] <KotH> hyc: increases? there has not been any increas to speak of since about 2004 :) [11:19:36] <hyc> KotH: shhhhhhhh, Intel doesn't want anyone to realize that :P [11:20:09] <KotH> we've actually reached a point where a full multiplication can be done in a single clock cycle, but getting the result anywhere takes 2-3 cylces [11:20:40] * KotH wonders when the first GALS chips will apear [11:21:30] <hyc> what, no diamond semiconductors? [11:21:30] <KotH> though, i think they will first struggle with the issues to get the feature size below 20nm [11:21:41] <KotH> diamond semiconductors? [11:21:49] <KotH> diamond has no semiconduction properties [11:22:15] <hyc> sorry, was remembering some article on how carbon was set to displace silicon [11:22:25] <hyc> graphite for conduction [11:22:42] <hyc> diamond for substrate, heat sink [11:23:16] <KotH> hmm... [11:23:26] <KotH> graphene layers maybe [11:23:54] <hyc> yeah, that was probably it [11:23:58] <KotH> but these are still in early stage of research (until iirc two years ago, there was no good way known to produce single atom graphene layers) [11:24:24] <KotH> i doubt that we see anything that will be usable for electronics in the next 5 years [11:24:42] <KotH> if not 10 years [11:25:24] <KotH> and by that time it might be already too late [11:25:41] <hyc> too late how, somethin g else better will have come along? [11:25:42] <KotH> what is an opportunity though, are nanotubes on silicon substrate [11:25:57] <KotH> yes, development in other fields isnt standing still [11:26:28] <KotH> it might very well be that we'll have molecular transistors in 10y [11:26:44] <KotH> ie, transistors implemented in organic/non-organic molecules [11:27:52] <Tjoppen> merbzt: wait a minute.. there already is a dpx decoder, and it seems to decode my files OK (could transcode to JPEG) [11:28:30] <hyc> KotH: looking forward to seeing things develop. I recall someone has already developed ATP-powered electronics [11:28:42] <twnqx> i'd want something like the archos 5 with a 1680x1050 15.4" and tegra [11:29:01] <thresh> and portable, so you can stick it in your pocket [11:29:05] <twnqx> how much would building a prototype of that cost... [11:29:28] <av500> you dont want tegra [11:29:34] <KotH> hyc: "developed" as in "i have demonstrated, that potentially it might be possible to build anything using this approach in a highly controlled lab enviroment" [11:29:52] <hyc> twnqx: I'm pretty sure we can get 1920x1080 DLP projectors that fit onto an eyeglass [11:30:03] <hyc> KotH: yeah, that. [11:30:12] <twnqx> av500: ok, anything with open source video acceleration and enough horsepower to run gentoo [11:30:27] <KotH> hyc: from the first results of a lab research it takes quite some time to industrialize it... and sometimes industrialization is not possible [11:30:36] <av500> twnqx: the tegra does not decode 1080 [11:30:42] <av500> neither open nor closed [11:30:52] <twnqx> meh [11:30:55] <KotH> hyc: not to talk about that normal newspapers and magazines exagerate results by quite a few magnitudes [11:31:15] <KotH> hyc: like the "we have created artificial life" a few weeks ago [11:31:21] <hyc> ah yes [11:31:50] <av500> twnqx: i can offer 10" [11:31:52] <twnqx> is there nothing short of ion than can really drive 2x 1920x1200 and play 1080p video with at least BD bitrates? [11:32:17] <av500> twnqx: there is ion [11:32:25] <av500> and intel chipset hw accell [11:32:31] <twnqx> 10" and HD (at least 1280x720), or something that's to lowres for browsing even? [11:32:49] <av500> 1280x600 iirc [11:32:53] <av500> std netbook res [11:32:53] <twnqx> mh [11:33:02] <twnqx> yeah, there's a reason why i don't have a netbook [11:33:07] <twnqx> and that's not money. [11:33:16] <av500> err, 1024x600 [11:33:30] <twnqx> that's pre-2000 resolutions [11:33:41] <twnqx> and one of the reasons i refuse all these gadgets [11:34:03] <av500> I'm sure you lugged around a 20"CRT with you pre 2000.... [11:34:08] <twnqx> 19" [11:34:10] <twnqx> in 1600x1200 [11:34:29] <twnqx> at 17" in 1280x1024 [11:34:43] <hyc> I still have my 19" 1280x1024 monochrome monitor [11:34:47] <av500> yes, in you pocket? [11:34:51] <hyc> on my desk [11:34:58] <twnqx> i'm not looking for "in my pocket" [11:35:15] <av500> twnqx: then you are barking up the wrong tree :) [11:35:17] <twnqx> i'm looking for useable. pocket stuff is like an ipod, play music on it [11:35:37] <twnqx> well, i asked for pretty specific number :X [11:36:05] <hyc> I want hi-rez eyeglass displays. seems like they're still a few years away from being decent. [11:36:27] <av500> and a decent collision warner [11:36:33] <twnqx> lol [11:36:43] <hyc> ok, make them semi-transparent [11:36:50] <twnqx> HUD glasses? [11:36:54] <hyc> yep [11:37:07] <KotH> hyc: they have been "a few years away" for years now :) [11:37:13] <hyc> sigh [11:37:31] * twnqx remembers laser projection into the eye [11:37:41] <hyc> last I heard the problem is they don't do well at tricking the eye into perceiving depth [11:38:13] <av500> twnqx: skip the eye, it has a low bitrate path to the brain anyway... [11:38:28] <hyc> you need to be able to selectively defocus regions so that the eye's own aiming/focusing mechanisms work [11:38:41] <twnqx> hyc: just track the eye lense [11:38:59] <hyc> which means you need several times HD rez to allow you to do the antialiasing and such [11:39:23] <twnqx> *i* don't mind [11:39:31] <twnqx> i'd buy a 150dpi 24" display immediately [11:39:46] <av500> hyc: several times HD for the eye that is said to have 18bit/s to the brain, overkill.... [11:39:47] <twnqx> there's no such thing as "enough" resolution or display space [11:39:54] <twnqx> 18mbit/s? [11:39:58] <av500> no [11:40:03] <av500> quite low bitrate [11:40:03] <twnqx> 18 bit? [11:40:13] <av500> I read that somewhere [11:40:15] <twnqx> i'd consider that unlikely... [11:40:32] <hyc> hmm.... yeah, seems off. [11:40:41] <twnqx> try to encode something with eye resolution with 18bps... [11:40:46] <hyc> would need massively long persistence to even paint an image [11:40:53] <hyc> and then you'd have massive ghosting [11:41:14] <av500> ok, seems I missremember [11:41:33] <twnqx> A 2006 University of Pennsylvania study calculated the approximate bandwidth of human retinas to be about 8960 kilobits per second, whereas guinea pig retinas transfer at about 875 kilobits. [11:41:35] <twnqx> :) [11:42:00] <twnqx> well, that's retina, not eye->brain with prefiltering, though [11:42:16] <hyc> hmm. so we only 8960kbps on video codecs? [11:42:42] <av500> twnqx: ok, I was wrong, its 16: http://fm.schmoller.net/2007/03/16_bits_per_sec.html [11:43:57] <av500> I guess 18 was made up by a journalist who was exagerating :) [11:44:18] <twnqx> that's weird [11:44:30] <hyc> eh, the diagram says 10^7 bits/sec input [11:44:33] <twnqx> but it's talking about consciousness [11:44:38] <twnqx> not signal processing [11:44:54] * av500 googles for another seemingly related article [11:45:04] <av500> :) [11:45:36] <hyc> and 10^6 for audio. someone must be heavily rounding off; we don't have 10:1 ratio between video and audio streams [11:45:48] <av500> if its all these high bitrates, how come I dont remember anything about most movies I watched a day ago? :) [11:45:50] <twnqx> nah, i can accept the number, you just have to define from where to where more precise [11:46:26] <twnqx> it basically says the brain takes 8mbit/s input from the eyes, and processes them down to extract the few bits that are relevant at the time [11:46:46] <av500> see, skip the processing and inject information at the relevant level :) [11:46:55] <twnqx> would be cool [11:47:09] <hyc> would be ... limited [11:47:30] <hyc> you can watch a movie a 2nd or 3rd time and see things you didn't notice before [11:47:36] <av500> like: "it was a movie with kate beckinsale" [11:48:14] <hyc> so just because the brain will only absorb 16 bits doesn't mean you can get away with only providing 16 bits of info in the source material [11:48:34] <twnqx> it depends on the purpose. [11:48:42] <hyc> av500: does that you mean you like Kate, or dislike? [11:49:34] <pross-au> Hii [12:53:15] <av500> 4% wrong aspect ratio, is that noticeable? [12:53:36] <mru> it might be [12:53:53] <mru> "do I look fat in this aspect ratio?" [12:53:54] <av500> my non scientific gimp test says no... [12:54:22] <thresh> mru: there is no good answer to this type of question [13:07:44] <Tjoppen> interesting.. raw images can be wrapped on a line-by-line basis in MXF [13:09:36] <_troll_> Tjoppen: that's nothing! [13:09:45] * _troll_ introduces PIXML [13:09:49] <_troll_> pixel-level xml [13:10:24] <_troll_> <pixel><component type="red">5</component>...</pixel> [13:10:41] <CIA-92> ffmpeg: stefano * r23407 /trunk/doc/ffmpeg-doc.texi: [13:10:41] <CIA-92> ffmpeg: Merge @chapter Introduction and @chapter Description into a single [13:10:41] <CIA-92> ffmpeg: section, and make the whole rendered in the man output. [13:10:41] <CIA-92> ffmpeg: Simplify layout, and make it more consistent with that of the other [13:10:41] <CIA-92> ffmpeg: man pages. Also I cannot see a good reason for keeping split the two [13:10:41] <CIA-92> ffmpeg: sections. [13:10:45] <Tjoppen> I actually have a format that is dangerously close to that. I just need to add an optional xs:hexBinary field for the essence data [13:10:49] <_troll_> and with xpath you can do MC too [13:10:56] <av500> "red" is too unspecific! [13:11:25] <kierank> it also needs a dtd to define what colours are [13:11:31] <kierank> just for semantic purposes [13:13:48] <janneg> as long as nobody tries to build displays supporting this pixel format we are safe [13:14:02] <Tjoppen> well, doing it like <line><pixel red="5" blue="10" green="20"/>...</line> would allow for a compilable schema and not too much RAM usage if using a good unmarshaller [13:14:35] <_troll_> just zip compress it! [13:15:23] <Tjoppen> btw, if I read the DPX spec correctly it allows up to eight components, each of which could be anything from the usual R, G, B, Y, .., but also things like depth (Z) or "user defined" [13:15:51] <Tjoppen> so you could define an image as a kind of translucent 3D surface [13:15:54] <kierank> "would allow for a compilable schema and not too much RAM usage if using a good unmarshaller" --> tell that to openoffice [13:16:08] <janneg> what is the alleged advantage of this format? it's xml? [13:16:23] <Tjoppen> DPX? used when scanning film. it's binary [13:16:34] <Tjoppen> still between 50-200 MiB per frame though [13:17:17] <Tjoppen> regarding XML, I see far too many systems using it for which schemas can't be written. OpenCV for one [13:17:48] <Tjoppen> "hey, let's put data in the tag names - that saves space!" [13:18:41] <_troll_> <white/><green/><brown3/><palegoldenrodyellow/> [13:19:00] <Tjoppen> indeed. MXFLib does that with its dictionaries [13:19:24] <av500> _troll_: <katebeckinsale> [13:19:50] <Tjoppen> <Foo/><Bar base="Foo"/> instead of <class name="Foo"/><class name="Bar" base="Foo"/> (that latter would be schema-able) [13:19:59] <_troll_> av500: hmm, what goes between that and </katebeckinsale>? [13:20:30] <thresh> awful acting, i assume [13:20:34] <janneg> Tjoppen: I was more wondering about pixel level xml [13:20:44] <av500> _troll_: I have no idea who she lets that close [13:21:05] <Tjoppen> god no. that'd hardly be useful [13:21:54] <Tjoppen> you could do something like <frame format="yuv420p>0123456789ABCDEF</frame> though (hexBinary with attribute), which could be mildly useful for data exchange [13:22:04] <Tjoppen> s/>/">/ [13:22:08] <_troll_> yuck [13:22:16] <_troll_> y4m anyone? [13:22:54] <janneg> well someone must have thought it would be useful or he was just completely insane [13:23:21] * kshishkov thiks it's the latter in any case and the former as a consequence [13:23:25] <kshishkov> *thinks [13:25:23] <_troll_> janneg: I was only trolling... [13:25:25] <janneg> 'completely insane' -> anything [13:26:20] <janneg> _troll_: I think you mentioned it before [13:26:42] <_troll_> it's probably a recycled troll, yes [13:27:11] <janneg> could be [13:30:45] <_troll_> http://thread.gmane.org/gmane.linux.kernel/992368 [13:31:12] <_troll_> root of the madness: http://article.gmane.org/gmane.linux.kernel/978789 [13:31:34] <av500> lol [13:33:53] <janneg> lol "jitter that is more or less constant" [13:34:20] <av500> lol "jitter related to application-startup" [13:35:07] <_troll_> "For those who posess religious knowledge, or believe in religious phenomea, lets just say that, if you don't comply to certain religious knowledge, you will be tuning psychovisuals for a spirit, and not a human, and the experience will be suboptimal." [13:35:11] <_troll_> beat that [13:35:15] <_troll_> oh, wait.. [13:35:19] <_troll_> "Just like the worshipper of one spirit, say, atheist, includes his preferences in the tuning, so does, for instance the hash-smoker, and that is reflected in his tunings. What one would optimally like, is a spirit-free tuning. No personal preference, but tuned for the universal in us all." [13:35:34] <thresh> is that from the guy's website? [13:35:42] <_troll_> from the lkml thread [13:36:00] <thresh> oh god [13:36:09] <_troll_> from the website: "Numerous studys show that a refresh rate of 72hz is the maximum discernable to the human eye. It is also shown, that this refresh rate, is the best for avoiding pschovisual disturbance, and headaches. I further tuned this refresh rate to 72.70hz, for minimal psychovisual noise. This is also where the human mind, and senses, register the most information." [13:36:46] <thresh> i suppose the guy's got too much of hash [13:36:49] <av500> +1 [13:37:20] <janneg> and the troll even has the chutzpa to write "Any answers related to this post, critisising or wasting my time, will be ignored." [13:37:38] <merbzt> Numerous studys somehow most often turn out to be 0 [13:38:00] <av500> "... Gnome seems to be a source of jitter itself,..." [13:38:05] <av500> if it was only jitter.... [13:38:18] <thresh> well you cant argue with that [13:38:18] <janneg> or 1 with a very lax definition of study [13:38:53] <janneg> i.e. I tried that and I'm convinced it's better [14:01:34] <CIA-92> ffmpeg: stefano * r23408 /trunk/doc/texi2pod.pl: [14:01:34] <CIA-92> ffmpeg: Make texi2pod.pl accept @itemize commands with no following character [14:01:34] <CIA-92> ffmpeg: or texinfo command for specifying how to generate @item marks, and [14:01:34] <CIA-92> ffmpeg: make it use by default the mark symbol "*". [14:01:34] <CIA-92> ffmpeg: This is consistent with texinfo docs: [14:01:35] <CIA-92> ffmpeg: "If you don't specify a mark command, the default is `@bullet'." [14:01:36] <CIA-92> ffmpeg: stefano * r23409 /trunk/doc/ffmpeg-doc.texi: [14:01:36] <CIA-92> ffmpeg: Fix texi2pod.pl rendering of the Tips section by putting each @item [14:01:37] <CIA-92> ffmpeg: command on its own line, and create a corresponding "TIPS" man page [14:01:37] <CIA-92> ffmpeg: section. [14:01:38] <CIA-92> ffmpeg: Note that such section is not displayed, as currently only sections [14:01:38] <CIA-92> ffmpeg: with pre-defined names are rendered. [14:03:25] <ChrisWi> can someone verify that libavcodec is compiled without -fPIC. I am not able get it with fPIC. [14:03:37] <ChrisWi> and hence I can not compile vlc [14:05:26] <ChrisWi> http://pastie.org/987263 [14:09:39] <CIA-92> ffmpeg: stefano * r23410 /trunk/doc/ffmpeg-doc.texi: [14:09:39] <CIA-92> ffmpeg: Rename @chapter "Quick Start" to "Examples", for consistency with the [14:09:39] <CIA-92> ffmpeg: corresponding man page section. [14:14:48] <BBB> ChrisWi: ?? maybe ask on #ffmpeg instead of here [14:15:05] <j-b> ChrisWi: or #videolan [14:17:43] <ChrisWi> BBB, did already [14:18:13] <ChrisWi> j-b, thanks [14:36:13] <av500> mru: I have transport!!!!!!!!!!! [14:36:21] <av500> janneg: ping [14:37:11] <mru> av500: great [14:37:46] <janneg> av500: pong [14:37:48] <av500> I have somebody going there this fri or sat [14:37:52] <av500> janneg: ^^^^^^^^^^^^ [14:38:21] <janneg> I should be available for pickup in berlin [14:38:25] <av500> great [14:38:42] <av500> schoenhauser allee 51 [14:39:02] <av500> janneg: where are u in berlin? [14:39:22] <janneg> schoeneberg, kleistpark [14:39:31] <av500> ok [14:39:39] <av500> I will update you [15:00:22] <mru> the troll on lkml goes on [15:02:40] <kshishkov> any new tricks worth borrowing? [15:04:12] <mru> "Mindless people, who set a value of 4000hz instead of 3956, because they don't believe or lack the skill, to tune a value." [15:06:05] * janneg wonders why he only uses integer Hz values [15:07:38] <lu_zero> roundup is back [15:08:17] <lu_zero> KotH: where you'd like to move it? [15:10:08] <kshishkov> janneg: http://www.xkcd.com/217/ [15:11:13] <j0sh_> wbs: it was the chunked encoding (more specifically, the prefixed length) that was the problem [15:12:13] <j0sh_> we will have to fix that, the spec saysto use http/1.0 and chunked encoding is a 1.1 feature [15:33:12] <wbs> j0sh_: ok, so that's another thing in the http protocol that needs to be changeable [15:37:21] <j0sh_> yep... but hey, it works now! [15:37:26] <wbs> great! [15:37:49] * j0sh_ needs a few nights of curling up with rfcs [15:38:05] <j0sh_> prob never would have caught that chunked problem [15:38:08] <wbs> btw, the content-length: 32767 thing, what does the spec say about that - what should the sender do if he needs to send more data than that in the POST? [15:39:08] <j0sh_> the spec says dss ignores the content-length header, its just therre because POST requires it [15:41:00] <wbs> hmm, okay.. but what if there's a proxy inbetween, then it perhaps will matter? [15:41:24] <j0sh_> from the spec: " In practice, the actual value seems to be ignored by proxy [15:41:27] <j0sh_> servers, so it is possible to send more than this amount of data in the form of RTSP requests [15:41:30] <j0sh_> " [15:41:39] <wbs> hmm, weird [15:42:33] <wbs> but I guess that isn't the biggest of concerns [15:43:27] <j0sh_> there were similar concerns here: http://blog.flameeyes.eu/2009/10/24/apple-s-http-tunnel-and-new-http-stream… [15:43:41] <wbs> have you tested it to be working with both feng and dss? [15:43:54] <j0sh_> only feng, let me fire up dss [15:44:40] <wbs> ok.. I'll read that one later tonight [16:26:18] <BBB> j0sh_: oh, yeah, did I mention our http protocol handler is pretty crappy? [16:26:22] <BBB> j0sh_: thanks for fixing it ;) [16:31:02] <BBB> Tjoppen: I'm hoping to look at the http stuff you sent me also [16:31:05] <BBB> i.e. today [16:31:27] <Tjoppen> \o/ [16:31:35] <j0sh_> heh [16:31:37] <BBB> </late> [16:31:45] <j0sh_> does our mov muxer add hinting for dss? [16:31:55] <BBB> I think martin just added that [16:31:59] <BBB> so yes [16:32:21] <BBB> j0sh_: also, for changes to http, it might make sense that you test it with ffserver, that's a major http user [16:32:31] <BBB> I'll help you with that later ocne you're ready to submit a patch [16:32:47] <j0sh_> ok cool [16:35:05] <Tjoppen> btw, "PUT" is a more correct verb for uploads, since the operation is idempotent [16:35:59] <Tjoppen> I don't recall what people thought about changing that though. might break things that incorrectly assumes POST [16:37:28] <CIA-92> ffmpeg: rbultje * r23411 /trunk/libavcodec/iff.c: [16:37:28] <CIA-92> ffmpeg: Move get_buffer() calls from decode_init() to decode_frame(). Anything else is [16:37:28] <CIA-92> ffmpeg: unsupported and causes crashes when libavfilter is enabled. [16:37:28] <CIA-92> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [16:37:52] <Tjoppen> also, url_fclose() might want to return void rather than int, since it shouldn't be able to fail (no implementation returns non-zero anyway) [16:41:54] <BBB> Tjoppen: I agree, but that's an API change [16:41:56] <BBB> so not for now :) [16:42:05] <Tjoppen> yeah [17:02:17] <Dark_Shikari> mru: is there an arm version of clear_blocks? [17:02:33] <Dark_Shikari> I'm wondering why that didn't show up on your profile [17:02:36] <Dark_Shikari> because it did here iirc [17:09:30] <mru> Dark_Shikari: it doesn't tend to show up [17:10:18] <Dark_Shikari> it showed up here [17:10:26] <Dark_Shikari> And it's trivial, so I figure it couldn't hurt. [17:10:36] <mru> what percentage? [17:11:15] <mru> and what codec? [17:12:54] <Dark_Shikari> h263, "memset" is 2.7%. [17:13:01] <Dark_Shikari> It might be from some other part of the app, but I don't know of any big memsets [17:20:23] <Dark_Shikari> yup, it seems to be from h263_decoe_mb [17:20:26] <Dark_Shikari> so it would have to be clear blocks [17:20:30] <Dark_Shikari> er, clear_block [17:20:43] <Dark_Shikari> oh, both are used, clear blocks and clear block [17:22:09] <CIA-92> ffmpeg: mru * r23412 /trunk/libavcodec/arm/ (dsputil_neon.S dsputil_init_neon.c): ARM: NEON clear_block[s] [17:22:47] <Dark_Shikari> LOL [17:22:52] <Dark_Shikari> that was fast. [17:29:57] <BBB> I'm confused as for why gcc couldn't come up with that code itself? [17:30:06] <mru> BBB: because gcc sucks [17:30:07] <BBB> or let me restate that [17:30:11] <BBB> what code did gcc come up with? [17:30:36] <mru> memset call [17:31:15] <Dark_Shikari> gcc doesn't know the source is aligned [17:31:32] <BBB> aha [17:50:18] <dezodorant> jai: u here? [18:22:50] <wbs> j0sh_: yes, we can do rtp hinting now. just transcode/remux and add -fflags rtphint [18:27:56] <j0sh_> wbs: that explains it, i ended up having to use mp4creator [18:33:24] <wbs> j0sh_: yeah.. in my tests, mp4creator created buggy hint tracks, I've used MP4Box instead, that at least seemed to work [18:34:34] <j0sh_> ah, but now ffmpeg's works perfectly, right?? :) [18:36:56] <wbs> as far as I know, yes, and if you know of any problems, let me know so that I can fix them :-) [18:37:05] <j0sh_> heh alright [19:03:16] <BBB> lu_zero, wbs: any opinions about issue1978? [19:03:20] <BBB> can I apply? [19:04:02] <wbs> BBB: I think it's the correct thing to do, so yes [19:04:38] <BBB> lu_zero? [19:09:09] <wbs> j0sh_: rtp hinting adds a few percent of extra overhead in the file, so that's why it isn't enabled by default [19:11:06] <j0sh_> gotcha [19:11:52] <j0sh_> btw i broke something (probably trivial/stupid), so i'm working on the http stuff so i dont have to hack all theheaders by hand [19:12:51] <wbs> ok [19:36:09] <CIA-92> libswscale: stefano * r31300 /trunk/libswscale/ (utils.c yuv2rgb.c): [19:36:09] <CIA-92> libswscale: Move internal scale context fields initialization from [19:36:09] <CIA-92> libswscale: sws_setColorspaceDetails() to ff_yuv2rgb_c_init_tables(). [19:36:09] <CIA-92> libswscale: Allow to factorize duplicated code. [19:36:09] <CIA-92> libswscale: siretart * r31301 /trunk/ (5 files in 2 dirs): [19:36:10] <CIA-92> libswscale: deprecate palette8topacked32 in favor of public API functions sws_convertPalette8ToPacked32 and -24 [19:36:11] <CIA-92> libswscale: additionallym deprecate palette8torgb16 and its bgr variant without [19:36:11] <CIA-92> libswscale: replacement. These functions are not meant to be used by applications. [19:36:12] <CIA-92> libswscale: Discussed at: http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/109340 [19:50:12] <CIA-92> ffmpeg: michael * r23413 /trunk/libavformat/utils.c: Print an error when MAX_STREAMS is reached. [19:55:10] <lu_zero> hi [19:55:26] <mru> lo [19:57:59] <lu_zero> the patch is ok [19:58:02] <BBB> lu_zero: ok [19:58:04] <BBB> will apply [20:01:23] <CIA-92> ffmpeg: rbultje * r23414 /trunk/libavformat/rtsp.h: [20:01:23] <CIA-92> ffmpeg: Change default number of channels (used if unspecified in the format desc) [20:01:23] <CIA-92> ffmpeg: from 2 to 1, which is the actual value used in the spec. Fixes issue1978. [20:01:23] <CIA-92> ffmpeg: Path by John Wimer <john at god dot vtic dot net>. [20:05:37] <peloverde> Are the rtmp samples on the wiki still good? [20:06:28] <CIA-92> ffmpeg: siretart * r23415 /trunk/doc/APIchanges: Add an entry to APIchanges for the addition of sws_convertPalette8ToPacked32 -24 [20:07:07] <wbs> peloverde: some of them were ok a few months ago, but not all of them [20:07:28] <peloverde> wbs, I just found one that works [20:10:42] <wbs> okay [20:14:47] <CIA-92> ffmpeg: siretart * r23416 /branches/0.6/libavcodec/allcodecs.c: disable (native) vorbis encoder for the 0.6 branch [20:27:00] <CIA-92> ffmpeg: reimar * r23417 /trunk/configure: [20:27:00] <CIA-92> ffmpeg: Do not check_lib for -lva if vaapi is disabled, having -lva in extralibs [20:27:00] <CIA-92> ffmpeg: if vaapi is disabled is at best pointless. [20:46:24] <ramiro> has anyone seen a linker error for iphone regarding ff_imdct_half_neon being referenced from _ff_synth_filter_float_neon? ld64 suggests _ff_imdct_half_neon$non_lazy_ptr. what's this non_lazy_ptr? [20:47:22] <mru> didn't I fix that one? [20:53:18] <Yuvi> mru: http://pastie.org/988110 [20:53:38] <Dark_Shikari> mru: I found a way to make decoding much faster on our ipad [20:53:53] <Dark_Shikari> I just spent 2 hours going through the mpegvideo decoder... and butchered it completely [20:53:57] <ramiro> does the iphone/ipad have a hardware h264 decoder? [20:54:01] <Dark_Shikari> aka removing about 80% of the code =p [20:54:01] <mru> Yuvi: I thought I'd done that already... [20:54:09] <mru> maybe I'm confusing it with another one [20:54:11] <Dark_Shikari> ramiro: we can't use it [20:54:22] <Dark_Shikari> so we're moving to Sorenson FLV1 for now [20:54:39] <mru> what did you do? [20:54:52] <Dark_Shikari> I saved about 800-1000 clocks per mb on my core i7 [20:54:53] <ramiro> Dark_Shikari: hm, why can't you use it? apple doesn't let us? [20:55:01] <Dark_Shikari> ramiro: they haven't answered us yet [20:55:05] <Dark_Shikari> mru: http://pastebin.com/972CxbrV ;) [20:55:13] <Dark_Shikari> 1) remove all cases that aren't used (qpel, etc, etc) to get rid of extra ifs [20:55:20] <mru> tl;dr [20:55:22] <Dark_Shikari> 2) optimize decode_block by hardcoding most stuff, like "last" [20:55:31] <Dark_Shikari> e.g. things which are normally initialized per-codec, I moved into code [20:55:46] <Dark_Shikari> Basically this is how fast it could be if the entire thing was templated 5 billion times for every possible h263 variant. [20:55:49] <ramiro> Yuvi: thanks [20:55:56] <ramiro> mru: apparently you missed a spot =) [20:56:03] <mru> Dark_Shikari: how much faster did it get? [20:56:25] <Dark_Shikari> decode_block went from about 1705 -> 1234 cycles [20:56:32] <Dark_Shikari> then I cut a hundred more off h263 mb decode [20:56:41] <Dark_Shikari> then I cut 200 or so off mpv_decode_mb [20:56:43] <mru> that doesn't answer the question [20:56:49] <mru> in total, how much faster? [20:57:00] <Dark_Shikari> I think the total number of clocks before was about 4000 per mb. it should be about 3000 now. [20:57:08] <Dark_Shikari> I didn't test a timer of the whole thing. [20:57:11] <mru> but how much per fucking frame? [20:57:19] <Dark_Shikari> That would be 25% less time you bozo. [20:57:42] <mru> there's stuff that isn't done per mb too [20:57:48] <Dark_Shikari> nothing significant. [20:57:53] <Dark_Shikari> there's no loopfilter [20:58:10] <Dark_Shikari> I'm not counting stuff outside of lavc (e.g. texture copying, etc) [20:59:29] <Dark_Shikari> also, flv is _staggeringly_ crappy [20:59:35] <Dark_Shikari> it doesn't even have DC prediction [20:59:37] <Dark_Shikari> not even for INTRA blocks [20:59:51] <Dark_Shikari> every single intra block has an 8-bit DC code [20:59:53] <CIA-92> ffmpeg: conrad * r23418 /trunk/libavcodec/arm/synth_filter_neon.S: arm neon: Add missing mangle to external symbol [21:01:04] <Dark_Shikari> here is my new mpv_decode_mb: http://pastebin.org/299549 [21:01:11] <Dark_Shikari> Can we have all the decoding functions be this simple? :) [21:19:33] <Dark_Shikari> mru: isn't there a risk to using absolute struct offsets in asm files for huge structs, like in mpegvideo_neon.s? [21:19:52] <mru> do you have a better idea? [21:20:46] <Dark_Shikari> I would pass it as a function argument [21:20:53] <mru> how would you do that? [21:20:54] <Dark_Shikari> e.g. calculate nCoeffs outside of the function [21:20:58] <Dark_Shikari> and pass that as an argument [21:21:00] <mru> gcc sucks at that [21:21:01] <Dark_Shikari> pass the dc scale as an argument [21:21:11] <Dark_Shikari> sucks at what [21:21:19] <mru> the first half of the function [21:21:25] <Dark_Shikari> also, I'd do DC quant outside the asm [21:21:27] <Dark_Shikari> it's messy and ugly [21:21:31] <mru> it spends as much time there as the entire neon loop [21:21:35] <Dark_Shikari> o.0 what the fuck [21:21:44] <mru> it branches like mad [21:21:53] <mru> and schedules like an idiot [21:21:53] <Dark_Shikari> That's largely the fault of the code [21:22:05] <Dark_Shikari> some of the branches are totally needless [21:23:21] <Dark_Shikari> but for example, in x264, as I pointed you the deblock strenght I wrote earlier [21:23:24] <Dark_Shikari> instead of [21:23:27] <Dark_Shikari> h->loopf.deblock_strength( h->mb.cache.non_zero_count, h->mb.cache.ref, h->mb.cache.mv [21:23:31] <Dark_Shikari> h->loopf.deblock_strength( h [21:23:47] <Dark_Shikari> on x86_64 it's no slower (you have to load them anyways), on x86_32 it's slower but fuck x86_32. [21:23:58] <Dark_Shikari> And that avoids your gigantic mega-offsets. [21:25:45] <Dark_Shikari> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH [21:25:50] <Dark_Shikari> Intel copied x264's SATD [21:25:58] <Dark_Shikari> they copied our asm in the latest IPP [21:26:09] <mru> legal? [21:26:14] <Dark_Shikari> Well, they converted it to intrinsics [21:26:20] <mru> lol [21:26:22] <Dark_Shikari> But the algorithm is absolutely identical [21:26:31] <Dark_Shikari> down to the exact munging and horizontal multiply tricks [21:26:53] <Dark_Shikari> I don't think it's something we can technically go _after_ them for, since we do the same thing [21:27:00] <Dark_Shikari> But it's a funny form of flattery. [21:32:56] <Tjoppen> :) [21:36:49] <BBB> Dark_Shikari: yes you can go after them for it, assuming it's non-trivial of course [21:37:23] <BBB> Dark_Shikari: and assuming it's gpl-incompl of course [21:37:55] <Dark_Shikari> it's proprietary [21:38:03] <BBB> sue the f out of them [21:38:07] <Dark_Shikari> I wouldn't go after them, that would be stupid [21:38:11] <Dark_Shikari> because I do the same thing [21:38:13] <Dark_Shikari> I read other peoples' asm [21:38:16] <Dark_Shikari> understand the algorithm [21:38:17] <Dark_Shikari> and copy it [21:38:29] <Dark_Shikari> Though this is a bit more blatant than I've ever done. [21:38:36] <BBB> sell them one of your funny proprietary licenses then [21:38:39] <Dark_Shikari> lol [21:38:45] <Dark_Shikari> we could actually do that =p [21:38:46] <BBB> are you the (c) holder of that particular piece of code? [21:38:48] <Dark_Shikari> Holger is [21:38:59] <Dark_Shikari> He's signed the contrib agreement though or whatever [21:39:05] <Dark_Shikari> but either way, I don't want any legal anything [21:39:07] <Dark_Shikari> I just want them to give credit [21:39:09] <BBB> go make money :) [21:39:52] <BBB> I should analyze that asm myself, post it on my blog and slashdot it ;) [21:40:30] <BBB> and then add some embarassingly overstated title like "Intel steals x264 algorhitms" [21:40:35] <Dark_Shikari> lol [21:40:37] <Dark_Shikari> come on [21:40:41] <Dark_Shikari> that's stupid =p [21:40:45] <BBB> or better yet, "Intel steals GPL" [21:40:50] <ohsix> channel is publicly logged eh [21:40:51] <mru> lol [21:41:24] <BBB> ok, ok, I won't :) [21:41:33] <Dark_Shikari> anyways, I don't think that copying someone's algorithm is a copyright violation [21:41:37] <Dark_Shikari> you can't copyright ideas. [21:41:45] <Dark_Shikari> But it's good form to give credit for them. [21:41:55] <mru> but where do you draw the line? [21:42:12] <iive> algorithms are covered by patents [21:43:55] <BBB> if the asm calls are identical, it's definitely copyright [21:44:04] <BBB> if it's more blurry, then it isn't [21:44:16] <BBB> but yeah, I don't know where the line is [21:44:30] <kierank> yet sflc to deal with it [21:44:32] <kierank> get* [21:44:43] <Dark_Shikari> BBB: they rewrote it as intrinsics [21:44:54] <BBB> kierank: it's not ffmpeg code [21:46:41] <iive> Dark_Shikari: is that library newer than x264 code? [21:47:28] <Dark_Shikari> yes [21:48:36] <BBB> I'd go contact them, just so you have a good contact point if you want a donation in the future ;) [21:49:33] <Dark_Shikari> should I embarass them first? [21:50:02] <kierank> threaten to do so [21:50:07] <kierank> use it as a bargaining chip [21:50:37] <Dark_Shikari> lol [21:50:40] <Dark_Shikari> come on, I'm not evil [21:51:41] <kierank> they won't accept that it's holger's code [21:51:59] <Dark_Shikari> ? [21:52:03] <Dark_Shikari> what do you mean [21:52:19] <Dark_Shikari> you mean they'll claim its their own? well of course [21:52:26] <kierank> just like they won't accept that icc compiled executables are slower on amd [21:52:56] <Dark_Shikari> lol [21:53:02] <Dark_Shikari> no, they stated that such a thing is correct [21:53:08] <Dark_Shikari> More specifically [21:53:13] <Dark_Shikari> they say that they only have CPU detection for intel chips [21:53:21] <Dark_Shikari> thus any vectorized SSE2 code or whatever won't run on AMD chips [21:53:31] <Dark_Shikari> (they also only have timings/etc for intel chips) [21:53:47] <hyc> I guess timings are believable [21:54:12] <hyc> but the fact they implemented cpu feature detection bits in the first place trashes the cpu detection argument [21:54:32] <Dark_Shikari> http://pastebin.org/299677 ok, here's the draft of the post [21:54:34] <Dark_Shikari> any comments/etc? [22:02:22] <spaam> nice [22:03:56] <iive> Dark_Shikari: you know, saying you've been on hunt for optimization ideas is not the best way to start when your goal is to complain that somebody hunted one of your sheep. [22:04:11] <iive> one of yours. [22:04:39] <Dark_Shikari> Oh, apparently holger does want to dual license his code to intel [22:04:42] <Dark_Shikari> So I won't be posting this. [22:09:17] <BBB> you shouldn't blog about it [22:09:27] <BBB> you should email the legal people at intel [22:09:34] <BBB> or the coders, if you know them :) [22:16:02] <scaphilo> hi all is anyone here who does oprofile ffmpeg? Dark_Shikari told me to do that shortly ;-) Well i think it takes a little bit more than 5 min. has anyone written a script to profile ffmpeg? [22:17:11] <Dark_Shikari> script? [22:17:17] <Dark_Shikari> just start oprofile, run ffmpeg, stop oprofile, dump results [22:18:22] <scaphilo> for the results, i only get the result of ffmpeg as a whole program then [22:18:42] <Dark_Shikari> you need to use ffmpeg_g not ffmpeg [22:18:48] <scaphilo> oh i see [22:18:48] <Dark_Shikari> and do opreport -l ffmpeg_g [22:19:17] <scaphilo> ah ok wil try that thx [22:19:36] <Dark_Shikari> btw, mru, any chance you could consider doing deblock_strength for arm? [22:19:44] <Dark_Shikari> now that we have a C version and you can test it inside x264 [22:21:54] <scaphilo> oh what good that your here do you have an idea what kind of problem i could have when i dont make the fcode mpeg4 not the same like in mpeg2 [22:22:17] <Dark_Shikari> fcode is just a way of storing mv data [22:22:18] <scaphilo> i fixed it to 4 but im not sure if that leads to some problems with other videos than i currently test [22:22:24] <Dark_Shikari> it's not a problem if you change it [22:22:28] <Dark_Shikari> it's still the same dat [22:22:29] <Dark_Shikari> *data [22:22:32] <Dark_Shikari> even if stored differently [22:23:05] <scaphilo> ah ok thx same for the b_code of cause [22:23:32] <scaphilo> i still have some errors in b frames i thought perhaps that comes from this codes but [22:23:48] <scaphilo> i think i did something wrog in the mb_type mapping then [22:24:56] <scaphilo> by the way where the hell do you come from dark_shikari your all the time on :-) [22:25:57] <hyc> hm, ffplay doc on http://ffmpeg.org/ffplay-doc.html is out of date, it lists -rtp_tcp option but there is none [22:26:28] <hyc> instead you can append a URL option to the URL "?tcp" [22:26:45] <hyc> is there a doc anywhere collecting URL/proto-specific options like this? [22:39:39] <scaphilo> YEAH thats so cool :-) Thank you very much Dark_Shikari oprofiling is really a nice way to do it [22:40:01] <scaphilo> and takes not more than 5 min [22:40:22] <Dark_Shikari> Pastebin the results when you're done [22:41:33] <scaphilo> http://dpaste.com/202060/ [22:41:56] <scaphilo> dont know why this dct_quantize_c still takes that much time [22:42:00] <Dark_Shikari> Why is dct_quantize_c even running? [22:42:08] <Dark_Shikari> That shouldn't run in a trasncode. [22:42:12] <Dark_Shikari> Nor should dct_unquantize [22:42:21] <scaphilo> i have to do the quantising because the qscale is not really the same in mpeg2 and mpeg4 [22:42:27] <Dark_Shikari> Then make it the same [22:42:35] <Dark_Shikari> mpeg4 has an mpeg2-style quant mode [22:42:39] <Dark_Shikari> Use that instead of h263-style [22:42:54] <scaphilo> not possible because mpeg4 uses this dquant not only qscale [22:43:00] <Honoome> tonight I can be quite satisfied with myselfâŠ I got feng to work with IPv6 _finally_ after months it wasn't possible to use it at all +_+ [22:43:06] <scaphilo> oh am ok [22:43:09] <Dark_Shikari> scaphilo: huh? [22:43:29] <Dark_Shikari> scaphilo: if you have to requantize, your algorithm WILL NOT WORK [22:43:33] <Dark_Shikari> thus you have to do it without requantizing. [22:43:46] <Dark_Shikari> And yes it's possible to do. [22:44:29] <scaphilo> hmm but how do i enable this mpeg2-style quant mode [22:45:02] <Dark_Shikari> it's just a header bit afaik [22:45:32] <Dark_Shikari> yup [22:45:33] <Dark_Shikari> s->mpeg_quant [22:45:41] <Dark_Shikari> s->mpeg_quant= avctx->mpeg_quant; [22:45:43] <scaphilo> ah dam is it really that easy :-( [22:45:47] <Dark_Shikari> it's just a parameter. [22:46:22] <scaphilo> ill try that thx for your help [22:46:37] <scaphilo> if you want you will of cause get a version of this oltranscoder [22:46:46] <scaphilo> when its findished [22:49:41] <scaphilo> btw:if you have to requantize, your algorithm WILL NOT WORK thats a bit hard. Of cause it works but there is an error you get (not that big if you have small new quant errors) but anyway ill better do what you said [23:03:44] <mchinen> can someone tell me why is AVFormatContext's data_offset sometimes the end of the file? [23:04:03] <mchinen> I'm trying to find the first packet. Maybe there's a better way?

1 0

IRC log for 2010-05-31
by irc＠mansr.com 01 Jun '10

01 Jun '10

[01:57:13] <peloverde> Using C++ in GCC is OK http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html [01:57:49] <kierank> "Is there anyone who would like to volunteer to develop the C++ coding [01:57:49] <kierank> standards? [01:57:55] <kierank> ---> mru should do this [06:48:23] <peloverde> And another MP3 patent bites the dust... :) (US 5214678) [06:53:10] <superdump> how many left? :) [06:53:26] <peloverde> http://wiki.multimedia.cx/index.php?title=MP3_Patents [06:53:31] <superdump> peloverde: oh, and what do you think of what i said in that aac channel order thread? [06:53:36] <Tjoppen> \o/ [06:55:03] <superdump> so we have to wait until 2018 until it's patent free? [06:55:05] <superdump> :) [06:55:10] <Tjoppen> wait.. how can there be patents from 2000? [06:55:18] <peloverde> MPEG 2.5 [06:55:19] <Dark_Shikari> Tjoppen: that's why mpeg-la is being sued [06:55:26] <peloverde> LSF [06:55:30] <Tjoppen> I see [06:56:20] <peloverde> superdump, I mostly agree, I'll send out a full answer tomorrow [06:56:37] <superdump> righto [06:57:06] <peloverde> what we really need is [type][tag][count] [06:57:15] <superdump> mmm [06:57:29] <peloverde> because different tags are allowed to occur in any order, which is a retarded feature but is required [06:57:35] <superdump> mmm [06:57:50] <peloverde> al17_* specificly tests that [06:58:19] <Tjoppen> wait.. the standard was published in 1992, so almost all of those shouldn't be valid? [06:58:19] <superdump> i think that will be the most versatile, if an extension of the spec [06:58:38] <superdump> we could support more channels that the spec :B [06:58:40] <peloverde> OTOH we could assume that files with broken tags don't use that feature [06:59:04] <superdump> that's basically what i was suggesting [06:59:30] <superdump> the tags become irrelevant if multiple syntax elements are using the same tag [06:59:37] <superdump> (of the same type) [07:00:09] <superdump> maybe the tag information is still of some use [07:00:29] <superdump> but it would only be for hacking around buggy encoders [07:01:33] <peloverde> I like that approach but it unnecesarily modal [07:02:28] <peloverde> I think we could just bucket hash or autoincrement taggs [07:03:25] <peloverde> e.g. if we've already seen SCE[0] this frame then it becomes SCE[1] [07:04:19] <peloverde> I'm also interested in incompatible tag concatentation which apparently occasionally happens in the broadcast world [07:13:47] <superdump> peloverde: mmm, i don't think we can do anything much with the channel ordering though can we? unless the syntax elements are in the correct order to correspond with the default channel configuration details [07:13:57] <superdump> but i don't think that would necessarily be reliable [07:14:06] <superdump> i agree with the autoincrementing of tags though [07:14:25] <superdump> seems like the simplest way, if the most naive :) [07:27:38] <peloverde> Why did NeXT sign the FSF copyright assignment for ObjC? Legend states the ObjC front end is part of GCC because the GPL forced NeXT to release the code that they wanted to keep closed. [07:28:25] <KotH> salut [07:28:39] <kshishkov> umm, because FSF always wants inconvenient stuff like VP8 to be released? [07:30:50] <peloverde> yes, but how was NeXT forced to sign the FSF copyright assignment necessary to get ObjC merged into FSF gcc? [07:31:56] <kshishkov> could be the stage when they Jobs didn't care about NeXT anymore [07:32:15] * kshishkov knows only one good app for NeXT - original Doom [08:01:26] <astrange> i think they violated the GPL and fsf settled with them to sign the copyright assignment [08:05:42] <hyc> I got a lot of mileage out of a NeXT cube as a cross-compiler for my Atari ST stuff [08:06:23] <hyc> made building a minix image from scratch a lot more pleasant than the alternative... [08:29:08] <pJok> kshishkov, i'd say good morning, but its not a good morning [08:35:35] <av500> <adjective> morning [08:35:57] <pJok> av500, too easy... since its not morning anymore [08:36:15] <av500> <adjective> <time of day> [08:36:55] * pJok tips av500 over [08:43:14] <kshishkov> pJok: en dalig morgon? [08:48:52] <spaam> kshishkov: maybe time to get a keyboard with a swedish layout :) [08:49:17] <kshishkov> spaam: I thought about that, but they won't understand me at work [08:49:37] <kshishkov> and it's not that usable for programming [08:50:10] * kshishkov har tysk tastatur [08:50:23] <spaam> ok :) [08:52:51] <superdump> mmm, my main distaste for swedish layouts is the (to me) strange location of '/' and so on [08:53:04] <superdump> kshishkov: when do you start the new job? [08:53:26] <kshishkov> superdump: what new job? [08:53:43] <superdump> on your blog, you said you have a new job [08:53:52] <superdump> in germany [08:53:58] <kshishkov> and same distaste here - and I use semicolons quite often when programming in C [08:54:38] <kshishkov> superdump: have != simply offered. So the time is -6 weeks or so [08:55:06] <superdump> so you're already doing it? [08:55:11] <kshishkov> of course [08:55:16] <superdump> ok, then how is it going? [08:55:26] <kshishkov> quite fine [08:55:46] <superdump> good [08:56:03] <kshishkov> yes, that was a good choice even in retrospective [08:56:08] <wbs> coding on swedish layout keyboards is a bit awkward yes, but it's bearable once one has gotten used to it [08:56:33] <kshishkov> superdump: the company is so good that they even invited Mans for a day [08:56:36] <KotH> is it better or worse than german layouts? [08:56:41] <wbs> it's quite a bit difference between mac and pc layouts for swedish too, braces and brackets are placed quite differently [08:57:18] <kshishkov> KotH: better - it's qwerty [08:57:34] <KotH> lol [08:57:52] <superdump> probably better than french azerty [08:57:56] <superdump> that's just nuts [08:58:11] <KotH> you've never seen the old turkish layout [08:58:14] <KotH> that's insane [08:58:34] <superdump> iirc azerty has a lot of keys with non-shift/shift inverted [08:59:09] <spaam> KotH: so now we know why you are like you are.... :P [08:59:53] <KotH> spaam: right, i havent kicked you today [09:00:27] <spaam> KotH: cute;) [09:02:38] <hyc> hmmm. hulu is only providing 640x360 650kbps now, no more 1Mbps 720x400. I wonder if they're going to hold back their highest rez for paying subscribers [09:06:13] <lu_zero> eh eh [09:08:33] <lu_zero> wbs: we could plan the weekly backlog of j0sh_ [09:11:25] <wbs> lu_zero: yeah, that'd be a good idea [09:12:29] <lu_zero> wbs: email? [09:12:36] <lu_zero> or right here? [09:12:36] <wbs> sure [09:12:47] <wbs> irc works fine too [09:13:10] <lu_zero> right now our main topic is http-tunnelling [09:14:55] <wbs> yeah.. what other major and minor tasks do we have? [09:15:17] <wbs> untangling the rtpdec stuff as much as possible from rtsp.c is at least one of them, i think [09:15:25] <wbs> the format specific stuff that is [09:15:55] <lu_zero> I had a list somewhere... [09:17:23] <wbs> the soc wiki page has some, too: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Improv… [09:17:52] <lu_zero> that one as well http://socghop.appspot.com/gsoc/student_proposal/comment/google/gsoc2010/j0… [09:19:58] <lu_zero> we could abuse the wiki [09:20:31] <wbs> hmm, I'd better get a wiki account [09:24:28] <wbs> do you btw have any clue about the mpeg2ts/rtp stuff? restructuring the rtpdec stuff without actually being able to test that part may be a bit risky [09:26:12] <lu_zero> mpeg2ts/rtp is an abomination I don't like that much [09:26:37] <lu_zero> it should be converted to a chained demuxer [09:28:49] <wbs> yeah [09:29:01] <wbs> but doing any kind of restructuring without samples is quite hard [09:29:46] <j-b> Any news on the vpx licensing side? [09:33:39] <lu_zero> we have the spec ^^; [09:34:07] <janneg> diego backported the non-free change to 0.6 and today is memorial day in the US [09:36:19] <janneg> I don't think google will fix the license soon. probably takes a few weeks [09:55:37] <pentanol> or may be here someone knows or may point me what happens in those few looks liek private ioctls during opening V4L1 interface? http://codepad.org/NpPBdigf [10:12:45] <KotH> pentanol: it might be easier if you'd had a question that is a bit more specific [10:12:57] <KotH> pentanol: i think you understand as much as we do what's happening there [10:13:13] <mru> av500: ping [10:13:17] <KotH> pentanol: (ie opening device, sending ioctls, mmaping, sending more ioctls, etc pp) [10:14:27] <av500> pong [10:14:53] <pentanol> KotH, ok, but I've tried it with ffmpeg, put where width and height and rate [10:15:25] <mru> av500: we need a transport plan [10:15:30] <mru> any ideas? [10:15:54] <pentanol> KotH and then ffmpeg said v4l: colour=0 hue=0 brightness=0 constrast=0 whiteness=0 \n [video4linux @ 0x423d10]VIDIOCMCAPTURE: Invalid argument [10:17:15] <av500> mru: i can be 9:37 in berlin spandau on wednesday [10:17:28] <av500> or somebody else takes it a day earlier [10:17:42] <mru> I guess that will have to do if nobody else steps up [10:18:09] <pentanol> also I tries change sequence ioctls a bit, in trace which I give and in video4linux.c from lavd it in different sequence [10:18:09] <mru> kshishkov: when/how are you travelling to berlin? [10:21:26] <kshishkov> mru: night train on night before/after LinuxTag [10:23:43] <KotH> pentanol: i think you want to read 1) the code that initilizes v4l, 2) read on how v4l works [10:24:12] <av500> KotH: "works" can be debated [10:26:04] <kshishkov> KotH: s/works/supposed to work when it was not deprecated/ [10:35:00] <thresh> http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html uh oh [10:35:50] <kshishkov> why not go straight for the Lisp? [10:36:20] <pross-au> so the world will really end in 2012 [10:36:34] <kshishkov> gcc world as we know it [10:37:20] * kshishkov thinks they should use Boost as well - it will only slightly increase their codebase and slightly increases compile time [10:38:03] <pross-au> thats okay the BSD guys are writing pcc [10:38:25] <jai> bsd guys wanted to switch to clang+llvm right? [10:40:41] <pross-au> that too [10:40:56] <Andrius> jai, freebsd, yes: http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017440.html [10:41:05] <thresh> well, now they can easily go gcc way [10:41:12] <thresh> it'll be the same, C++ everywhere [10:41:35] <mru> well, expect no bugfixes or other improvements to gcc for the next 10 years [10:41:47] <mru> they'll all be masturbating over c++ [10:42:20] <mru> av500: the video wall has a single power lead, right? [10:42:38] <kshishkov> mru: why? C++ should introduce a good deal of bugs to fix [10:42:50] <mru> :-) [10:42:51] <av500> mru: yes [10:43:12] <av500> ill also get longer hdmi cables, the 1m are too short I think [10:43:18] <av500> 2m now... [10:43:31] <av500> and I'll try to make the power cable mess behave a bit more [10:43:33] <pross-au> so will a ffmpeg c++ decision be forthcoming lol [10:44:08] * av500 wants // comments NOW! [10:44:16] <mru> pross-au: it's already been made [10:44:24] <mru> pross-au: the decision is a resounding NO [10:44:29] <kshishkov> and a good one too! [10:44:29] <mru> av500: we already have that [10:44:44] * av500 wants to declare vars left and right NOW :) [10:45:08] <pross-au> operator overloading so filter chains can be built in one line [10:45:57] <jai> template metaprogramming for libsws [10:46:07] <av500> same for audioconvert [10:46:22] <av500> codecs can be float and int at the same time! [10:46:59] <pross-au> the current c templates work just fine [10:47:44] <pross-au> i hate c++ as much as the next person [10:47:48] <kshishkov> av500: "float and int at the same time" - for quantum CPUs only [10:48:15] <av500> kshishkov: just define a new datatype float_int [10:48:26] <CIA-55> ffmpeg: pross * r23392 /trunk/libavformat/au.c: Prevent au_read_packet() looping endlessly when .au file contains unsupported codec type. [10:48:33] <kshishkov> pross-au: yer cobber ain't a FFmpeg dev, mate! [10:48:53] <pross-au> why bother writing codecs. declare the format in prolog and let the computer figure out the rest. [10:49:07] <pross-au> haha [10:49:58] <kshishkov> I suspect you'll need to write bitstream to Prolog code generator for resolving it into audio data [10:51:17] <jai> peter seibel did that with lisp and id3 tags iirc [10:51:20] <pross-au> in which case C++ sound pathetically low-level [10:52:10] <mru> has prolog ever been used for anything more complex than hello world? [10:52:19] <pross-au> yes [10:52:34] <mru> count to 10? [10:53:00] <pross-au> i think you need to add the 'practical' word into that hypothesis mru [10:53:20] <mru> ok, so has it been used for anything practical? [10:53:22] <kshishkov> mru: it's good for solving those logical puzzles [10:53:32] <mru> where's the fun in that? [10:53:38] <pross-au> i recall writing such a puzzle solver in prolog [10:53:49] <mru> logic constraint solving isn't hard [10:54:21] <mru> be it "the guy in the red house smokes cigars" or the sudoku variety [10:55:17] <mru> it's just linear algebra of sorts [10:55:37] <av500> mru: your hotel? [10:55:50] <mru> av500: what of it? [10:55:54] * kshishkov remembered programming compretitions he took part at - all of them were for math knowledge or combinatorics, nothing even remotely real-world [10:55:55] <av500> which one is it? [10:56:00] <mru> ivbergs [10:56:16] <pross-au> kshishkov: did the same [10:56:28] <mru> I've looked at programming competition problems [10:56:33] <mru> they're not programming problems [10:56:33] <av500> mru: there are several? [10:56:39] <mru> they're maths/logic puzzles [10:56:50] <mru> av500: neue kantstrasse [10:58:20] <av500> k [10:59:58] <av500> what do you pay per day? [11:00:24] <mru> 70 iirc [11:00:31] <mru> probably overpriced [11:00:48] <mru> but I couldn't find anything better closer than schönefeld [11:02:50] <av500> hm [13:07:42] <CIA-55> ffmpeg: siretart * r23393 /branches/ (0.5 0.5/configure): [13:07:42] <CIA-55> ffmpeg: configure: improve temp file creation and cleanup [13:07:42] <CIA-55> ffmpeg: backport r17752 by mru [14:20:54] <siretart> hrmpf. writing mails sucks lots of time :/ [14:21:08] <kshishkov> so is talking on IRC [14:21:15] <mru> but irc is more fun [14:22:44] <jai> wow, so ffmpeg-LTS eh [14:23:12] <kshishkov> make FFmpeg EE first [14:27:49] <KotH> lts? [14:27:50] <KotH> ee? [14:28:13] <kshishkov> lts = long term shame or support [14:28:23] <kshishkov> ee = exitprise edition [14:29:11] <spaam> KotH: didnt you see ubuntu 10.04 lts ? ;D [14:29:16] <av500> dont we have to give it cute animal names too? [14:30:11] <kshishkov> cute? [14:30:39] <siretart> I need to point out here that I did *NOT* suggest the name ffmpeg-LTS [14:31:00] * KotH promote ffmpeg-lts as suggested by siretart [14:31:31] <siretart> :/ [14:31:56] <kshishkov> siretart: you can rename 0.4.9pre1 to LTS though [14:32:14] <siretart> kshishkov: why me? [14:32:18] <kshishkov> and we prefer STS where first letter stands for "shortest" [14:32:31] <kshishkov> siretart: you're maintainy guy, that's why [14:32:37] <siretart> I don't care about 0.4.9pre1. at all. [14:33:11] <jai> siretart: dont worry, you can always point them to the logs for attribution [14:33:12] <kshishkov> nobody did [14:33:37] <kshishkov> siretart: that was probably the longest supported FFmpeg release though [14:34:35] <siretart> I wasn't aware that 0.4.9pre1 got post release updates [14:34:47] <jai> it did not [14:35:02] <jai> infact, i clearly remember people being against that idea [14:35:38] <siretart> so why do you say it was "the longest supported FFmpeg release" if it wasn't updated at all? [14:35:56] <jai> 20:01 kshishkov@| and we prefer STS where first letter stands for "shortest" [14:35:59] <jai> siretart: ^ [14:36:10] <siretart> nonsense [14:37:48] <kshishkov> siretart: it was included in distros for long time, sometimes as more fresh SVN checkout [14:38:01] <kshishkov> 'twas a long road to 0.5.0 [14:38:35] <siretart> yeah, I've seen references in opencsw and bsd ports [16:01:14] <TheFluff> 12:35:00 <+thresh> http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html uh oh [16:01:17] <TheFluff> this is comedy gold [16:01:26] <TheFluff> Using multiple [16:01:26] <TheFluff> inheritance, templates (other than when using the C++ standard library, [16:01:26] <TheFluff> e.g. std::list<X>), or exceptions also seems overly aggressive to me. [16:01:26] <TheFluff> We should use features that are relatively easy for C programmers to [16:01:26] <TheFluff> understand and relatively hard for new C++ programmers to misuse. (For [16:01:29] <TheFluff> example, I think constructors and destructors are pretty easy and hard [16:01:31] <TheFluff> to misuse.) [16:01:34] <TheFluff> using constructors without using exceptions? [16:01:37] <TheFluff> oh you poor fools [16:05:13] <ln-> in practice a lot of projects do that. [16:05:39] <TheFluff> the c++ standard library does it, in fact [16:05:53] <TheFluff> like ifstream and ofstream don't report failing constructors with exceptions [16:07:06] <lu_zero> a fork would be interesting [16:07:48] * lu_zero will push to move to clang and llvm maybe they will be stabler in the short window [16:09:53] <BBB> lu_zero: you really need 2 channels? [16:10:02] <BBB> what hideous creature came up with that as a spec? [16:10:11] <BBB> must be horrible to implement a server and have session management [16:10:49] <Tjoppen> std::*stream not throwing exceptions is quite wtf [16:11:12] <Tjoppen> having to insert if(foo) everywhere gets old fast [16:11:23] <lu_zero> that thread is interesting [16:11:40] <ln-> Tjoppen: backwards-compatibility [16:11:48] <Tjoppen> also: requiring a C++ compiler to compile a C compiler? [16:12:03] <j0sh_> BBB: isnt RTSP somewhat stateful anyway? [16:12:08] <BBB> this if #ffmpeg-devel right? [16:12:10] <lu_zero> it is [16:12:18] * BBB is confused by the c++ discussion [16:12:26] <lu_zero> BBB: we hate gcc and c++ [16:12:30] <TheFluff> it's not because because of backwards compatibility [16:12:33] <BBB> rue [16:12:38] <lu_zero> newsflash -> gcc will use c++ [16:12:39] <TheFluff> it's because c++ exceptions are ??? [16:12:48] <TheFluff> http://yosefk.com/c++fqa/exceptions.html [16:12:56] <lu_zero> ffcc will appear shortly [16:13:22] <lu_zero> probably only supporting arm and amd64 [16:13:31] <lu_zero> anyway [16:13:34] <lu_zero> Honoome: poing! [16:14:27] <BBB> I'm so glad I don't have to compile gcc myself [16:14:47] <peloverde> llvm is much more plesent to build [16:15:02] <peloverde> It doesn't seem to rerun autoconf 3 dozen times [16:15:47] <Honoome> lu_zero: pong? [16:19:16] <lu_zero> BBB: has questions about http-tunnel [16:19:22] <lu_zero> and j0sh_ might as well [16:19:23] <j0sh_> BBB: do you want to reply-all to the gsoc start email? [16:19:47] <BBB> j0sh_: reply to ffmpeg-soc, if possible [16:20:07] <BBB> that way we actually use the mailinglist [16:20:13] <j0sh_> alrght [16:20:15] <lu_zero> btw j0sh_ is also interested in getting the extension you were planning in ffmpeg as well [16:20:24] <BBB> otherwise I created that silly gmail filter for nothing :) [16:21:07] <Honoome> j0sh_: fire up the questions then ;) I guess it's easier to talk about the extension later [16:21:38] <BBB> who do we ask for ffmpeg-soc repo access? [16:22:06] <j0sh_> Honoome: rtsp replies are all done on GET while requests are done on POST? [16:22:12] <Honoome> yep [16:22:20] <Honoome> and the requests are base64-encoded [16:22:20] <lu_zero> hi beandog [16:22:26] <BBB> who was on the steering commitee that did this? [16:22:31] <Honoome> [while responses are not] [16:22:33] <BBB> and can I get his address so I can shoot him? [16:22:37] <j0sh_> lol [16:22:50] <Honoome> BBB: it's apple's own stuff… be glad they documented it at all… [16:22:57] <av500> mru: I'm booked [16:23:11] <lu_zero> BBB: you were referring to C++ in gcc or what? [16:23:13] * BBB gets a shotgun and books tickets to cupertino [16:23:18] <j0sh_> docs aren't super clear, i didn't realize the get/post situation [16:23:34] <Honoome> j0sh_: yeah the original docs from Apple is almost unreadable :/ [16:23:38] <Honoome> http://docs.lscube.org/rtsp.xhtml#rtsp.http-tunneling isn't much better but at least give an idea [16:23:39] <BBB> lu_zero: no, the double-connection for rtsp-http [16:23:41] <beandog> lu_zero: lo [16:23:41] <BBB> lu_zero: :) [16:24:00] <BBB> mru: can students email you for a soc repo access? [16:24:09] <wbs> BBB: well, I find it bearable. with one infinite-sized GET request and one infinite sized POST, you effectively get a bidirectional socket [16:24:22] <wbs> BBB: and the x-sessioncookie header for tying them together... [16:24:31] <Honoome> wbs: _if_ the proxy allows you to do that [16:24:32] <BBB> bearable is an interesting term [16:24:42] <wbs> Honoome: true [16:24:43] <BBB> I wonder what ffmpeg would look like if all code in it was of "bearable" quality [16:24:51] <j0sh_> Honoome: is all rtp interleaved in rtsp? [16:24:57] <Honoome> unfortunately that's a) broken by caching proxies such as polipo b) broken by application-level firewall [16:25:12] <Honoome> j0sh_: yup, the rtp requests are sent down the GET [16:25:33] <Honoome> after the headers, the GET connection is mapped 1:1 with standard RTSP output [16:25:36] <wbs> Honoome: all such proxies are evil anyway ;P [16:25:55] <j0sh_> Honoome: got it [16:26:26] <Honoome> unless my possible extension is taken into consideration ;) as then you'd be getting base64-encoded responses as well :P [16:26:44] <j0sh_> rtp isn't base64encoded, but rtsp replies are? [16:26:47] <Honoome> http://blog.flameeyes.eu/2009/10/24/apple-s-http-tunnel-and-new-http-stream… this is where I wrote down some notes about that [16:27:10] <Honoome> j0sh_: replies are never encoded as it is… my proposed extension is to (optionally) base64-encode rtsp replies, but not rtp [16:27:24] <Honoome> by creating a special $0 interleaved channel (feng already starts counting from 1) [16:28:14] <j0sh_> ah yes, you mentioned replies werent encoded earlier, missed that [16:28:15] <j0sh_> ok [16:29:23] <Honoome> j0sh_: if you wish I can give you a wireshark-sniffed session of a quicktime http-tunnel streaming [16:29:32] <Honoome> [but it's a bit rough, never filtered out the crap :/] [16:30:29] <j0sh_> sure, i have yet been able to get past sending the base64 OPTIONS request [16:32:25] <Honoome> I'll upload it on my server, willt ake a while since it's 34MB bzip2-compressed ^^;; [16:32:58] <j0sh_> Honoome: heh, thanks! [16:51:48] <lu_zero> =) [16:52:10] <lu_zero> hyc: do you have experience with the adobe media encoder? [16:58:25] <hyc> nope [16:58:39] <hyc> anything special about it? [17:01:28] <lu_zero> curious about it [17:02:01] <lu_zero> some people would consider replacing everything but this [17:02:09] <lu_zero> so I'm wondering how good it is [17:02:46] <hyc> mebbe Dark_Shikari has an opinion of it [17:04:07] <lu_zero> Dark_Shikari: poing [17:04:33] <hyc> ffmpeg is a pretty nearly complete media suite now [17:04:53] <Dark_Shikari> lu_zero: pong [17:05:07] <hyc> add an rtmp listener to ffserver and it's got most of the streaming side covered [17:15:53] <lu_zero> Dark_Shikari: had experience with the adobe media live encoder? [17:16:02] <lu_zero> rtmp listener? [17:16:30] <lu_zero> hyc: ffserver doesn't scale at all so you have a next to perfect testbed [17:17:04] <Dark_Shikari> No, I don't want to touch that pile of shit [17:17:08] <hyc> doesn't scale? well, it's single-threaded, so yeah, it's a bit limited [17:17:09] <Dark_Shikari> seriously it's the worst encoder in the entire world [17:17:14] <Dark_Shikari> I've seen it lose to x264 at about 8 times the bitrate [17:17:29] <Dark_Shikari> it loses to its own VP6 encoder at 3 times the bitrate [17:18:29] <lu_zero> uhmm [17:18:31] <lu_zero> interesting [17:19:28] <Dark_Shikari> The best part is how every keyframe, the quality drops to zero [17:19:32] <Dark_Shikari> because its ratecontrol is broken [17:19:41] <Dark_Shikari> so the video flashes into blurriness every 3 seconds [17:19:57] <Dark_Shikari> You'd be better off with Theora than that pile of ass. [17:20:03] <av500> Dark_Shikari: about vp8 alt-ref as a replacement for b-frames, wouldnt that need to transmit an awful lot of non-displayed alt-ref frames? [17:20:12] <Dark_Shikari> Yeah =p [17:20:28] <av500> like every 3rd frame for IBBP... [17:20:44] <Yuvi> you could have the future P frame be all-skip referencing the alt-ref [17:20:51] <Yuvi> but that still doesn't get you bime [17:21:08] <av500> Yuvi: ah, it can do that... [17:21:21] <av500> so there would be not much overhead [17:21:35] <lu_zero> the altref golden frame is interesting if you consider it as a fec [17:21:50] <Dark_Shikari> not really [17:21:53] <Dark_Shikari> there are better ways to do fec [17:22:03] <lu_zero> out of box? [17:22:04] <Dark_Shikari> and that doesn't even work for a number of reasons [17:22:04] <Dark_Shikari> like [17:22:14] <Dark_Shikari> "the arithmetic coder will fail until the next keyframe if even one frame is lost" [17:22:41] <lu_zero> how so? [17:22:46] <av500> Dark_Shikari: also, about the golden frame e.g being just the unchanging background, yes, it can be that, but what encoder will figure that out? [17:23:37] <BBB> the encoder just tries it, right? [17:23:58] <Dark_Shikari> No [17:24:05] <Dark_Shikari> It just refreshes the golden frame about twice a second [17:28:40] <av500> thats what existing libvpx does? [17:30:44] <Dark_Shikari> yes [17:31:38] <av500> and altref? does it create these? [17:32:29] <Dark_Shikari> Not by default [17:34:09] <Honoome> j0sh_: I sent you via pm the URL of the sniffing log ;) [17:35:26] <j0sh_> awesome [17:45:28] <jai> siretart: the "less successfull" part was a bit uncalled for ;) [17:45:36] <jai> -l [17:47:12] <lu_zero> hyc: librtmp/rtmpdump does act as receiving rtmp server? [17:53:28] <siretart> jai: I'm referring to distros you most likely never heard of [17:56:15] <hyc> lu_zero: not completely [17:56:38] <hyc> rtmpsrv only answers the first few requests, to log what the client sent. [17:56:44] <hyc> it never actually serves any data. [17:57:09] <hyc> but that's because I didn't feel like writing all of the backend necessary for a server [17:57:31] <hyc> since ffserver already provides the backend, I could easily take the frontend from my rtmpsrv and add it [17:58:37] <hyc> also, i never finished implementing server-side rtmpt support, so that remains... [17:58:47] <j0sh_> wbs: can we use github as a defacto soc repo? [17:59:57] <wbs> j0sh_: if there are no formal problems with it, it would be much easier compared to maintaining patches in svn [17:59:58] <BBB> the disadvantage is that we won't be able to review commits [18:00:10] <BBB> but git does have some advantages [18:00:23] <j0sh_> BBB: tied to the ffmpeg-soc ML, you mean? [18:00:25] <jai> github can send commits to the ML [18:00:41] <BBB> if we can configure github to send emails to ffmpeg-soc, that'd be great [18:00:48] <jai> that's possible [18:00:50] <j0sh_> i will look into that [18:00:52] <BBB> not that I insist on that, but I do think it's generally useful [18:01:42] <jai> j0sh_: the email service hook does what you need [18:05:02] <wbs> with git, you can work in many modes, though... either you branch off from main when you start working, and then work incrementally on that branch, and send diff master..branch as a patch and get it applied [18:05:28] <wbs> or you could keep one branch as the patch series that you're suggesting to be applied, and rebase/rewrite this according to review feedback [18:05:52] <wbs> then the commit mails would be the full commits each time, with the modifications made [18:07:22] <lu_zero> j0sh_: add us to your git then [18:07:42] <j0sh_> lu_zero: creating it now [18:07:53] <wbs> for smaller features, I usually go for the second approach, for bigger stuff I usually start off with the former, and then create a second branch that recreates that state with new commits in the way I intend to submit them [18:07:54] <j0sh_> never used github before, this was a good time as any to start :) [18:08:03] <lu_zero> I have already an autosynced tree in gitorious [18:08:31] <lu_zero> btw [18:08:53] <j0sh_> wbs: i am still getting the hang of git, i really like the staging/index area though so i can do my changes incrementally and have a clean diff [18:09:48] <j0sh_> that reminds me, how is soc-svn kept in sync with trunk? [18:09:59] <lu_zero> isn't [18:10:20] <lu_zero> at least automatically [18:17:56] <wbs> BBB: where would a good place be to keep a list of j0shs tasks? somewhere on the wiki? [18:18:07] <BBB> multimediawiki? [18:18:16] <wbs> yeah [18:18:21] <BBB> a document on github is fine also [18:19:10] <wbs> here, http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Improv…, we've already got most of it, but is it ok to e.g. check things off of that list when they're done, and add new ones as we find new stuff to do? [18:21:51] <BBB> I suppose [18:22:00] <BBB> if josh is ok with that ;) [18:22:20] <BBB> but I'd make a new page, this is really his soc project, it's not a soc proposal anymore [18:22:36] <BBB> and then add a "progress" link on the main page [18:23:35] <j0sh_> sounds good to me [18:30:05] <j0sh_> i wonder if github needs to be subscribed to the ffmpeg-soc ML [18:30:47] <j0sh_> or how does that work? tried testing git's email hook, not showing up [18:34:34] <wbs> j0sh_: the sender address needs to be subscribed, and what's the sender address in those mail hooks? [18:36:38] <j0sh_> noreply(a)github.com, looks like [18:40:17] <j0sh_> can an admin force a subscribe? iirc we have to confirm subscription, which that address isn't going to do [18:46:17] <BBB> ask whoever is in charge of the ML according to the archives [18:46:23] <BBB> might be benjamin, mike or so [18:46:42] <BBB> admins can force subscribe, yes [18:46:50] <BBB> probably want nomail option also [18:46:54] <BBB> so they receive only, no sendto [18:47:04] <BBB> i.e. ml doesn't send to github, only github sends to ml [18:47:09] <j0sh_> alright [18:47:58] <BBB> yeah, merbanan/merbzt (benjamin) runs the list [18:48:00] <BBB> so ask him [18:52:09] <wbs> j0sh_: can you configure the mails per branch, too? otherwise, all other commits from the main repo that you push there will be mailed to -soc, too [18:52:48] <j0sh_> wbs: hmmm, the mail options are pretty limited, it just asks for an email address [18:53:12] <wbs> ok.. so we'll see how it works out in practice then [18:53:19] <j0sh_> it doesn't autosync at least [18:53:52] <wbs> no, of course it doesn't. that's your personal repo where you can store whatever you want, however old or new version [18:54:05] * BBB goes home [18:54:13] <BBB> enjoy figuring out github ;) [18:54:14] * lu_zero is back [18:54:18] <BBB> I hope I can see patches tomorrow [18:54:21] <BBB> :-p [18:55:21] <j0sh_> every time i want to sync, i'll just turn off email or something [18:55:38] <lu_zero> j0sh_: make more than one branch [18:56:20] <lu_zero> like an experiments one in which you keep hacks and tries [18:56:28] <j0sh_> lu_zero: ok [18:56:45] <lu_zero> so you can scrap it everytime you need that [18:57:33] <lu_zero> (and enjoy git rebase -i and/or git merge --squash) [18:57:51] * j0sh_ reads git help pages [19:29:18] <wbs> j0sh_, lu_zero: I set up a separate wiki page for the project, http://wiki.multimedia.cx/index.php?title=Improve_RTSP/RTP_layer [19:30:08] <wbs> I'm going to add a few other minor tasks there, too; untangling aac/mpeg4 from rtsp.c as mentioned before [19:30:17] <j0sh_> alright cool [19:30:34] <wbs> and also adding RTP packetizers for the formats that we have depacketizers for, to keep it balanced [19:31:13] <j0sh_> theora/vorbis are a couple i can think of [19:31:48] <wbs> yeah [19:37:29] <wbs> j0sh_: you got a wireshark capture of http tunneling, btw, or do you want another one? [19:37:56] <j0sh_> Honoome sent me one, thanks tho [19:38:40] <wbs> ok [19:43:55] <_av500_> a [19:44:02] <wbs> b [19:44:18] <av500> :) [19:59:50] <dezodorant> definitely something wrong with mp3 probing [20:00:05] <dezodorant> and good evening everyone ) [20:00:50] <dezodorant> need help with this issue https://roundup.ffmpeg.org/issue1954 [20:01:22] <dezodorant> cannot git-bissect it, working revision is a little bit far from current [20:01:43] <av500> is rounddown? [20:01:51] <av500> ah no [20:02:03] <elenril> just lolslow [20:03:16] <dezodorant> as usual, but problem is serious, i have compare decoders behavior and only lav fail [20:04:22] <pengvado> why does distance from current matter? [20:04:37] <dezodorant> swscale [20:04:52] <wbs> can you name one working revision? [20:05:02] <dezodorant> it`s impossible to synchronies lav and swscale [20:05:15] <dezodorant> ubuntu build ) [20:05:25] <dezodorant> and 0.5.2 [20:06:00] <pengvado> http://pastebin.com/Kq5xdBeA <-- here's a script, compatible with `git bisect run`, which works across swscale updates [20:06:26] <pengvado> you'll need to update the actual test part of the script, of course [20:06:57] <dezodorant> nice [20:07:00] <dezodorant> i`ll try [20:07:02] <av500> pengvado: that could be in tools? [20:10:16] <Honoome> I want to cry =_= [20:10:44] <Honoome> Wireshark seems not to be helpful to inspect SCTP traffic =_= [20:11:07] <wbs> what, a protocol that wireshark doesn't support? impossible :-) [20:11:36] <Honoome> wbs: it reports the DATA chunks as DATA… but does not inspect them further [20:11:40] <Honoome> so it doesn't find RTSP-in-SCTP [20:12:04] <wbs> ah [20:13:35] <wbs> well usually wireshark doesn't recognize RTP in UDP either, unless it did see and recognize the setup conversation [20:14:30] <Honoome> true but it doesn't _go_ to inspect RTSP-in-SCTP so it cannot identify any other protocol down to that [20:16:01] <ramiro> http://gcc.gnu.org/ml/gcc/2010-05/msg00763.html "we are in danger to get slowly degrading compiler." <-- oh, they finally noticed? [20:19:04] <peloverde> At least C++ has reasonable rules for const casts [20:19:21] <Honoome> hah; [20:19:26] <Honoome> like people actually cared… [20:20:21] <peloverde> The huge number of const warnings C spits out mask the actual important warnings [20:21:00] <Honoome> and yet people are still going on to just use (char*) casts rather than fixing underlying issues most of the time [20:21:43] <peloverde> that's not the warning I'm talking about [20:22:32] <Honoome> I was talking about the important warnings-became-errors lately [20:23:07] <Honoome> sincerely, I still feel C++ is embryonal because every minor GCC update ends up with a huge mess of packages that fail to build because they did something wrong before, but it was still accepted [20:23:41] <Honoome> e.g. with 4.5, with a class Bar in namespace Foo you can no longer do Foo::Bar b = Foo::Bar::Bar(...); because that's calling the constructor directly… [20:24:04] <Honoome> I'm pretty sure I was told that was the wrong syntax in high school already… why was it accepted _at all_ before? [20:25:29] <peloverde> http://pastebin.ca/1875025 drives me crazy [20:26:24] <Honoome> guuh okay that one I remember now… yeah it's a mess especially to get people to mark the bloody tables constant! [20:26:50] <peloverde> It super sucks if you have optional hardocded tables [20:27:50] <Honoome> like ffmpeg has ^^ [20:27:53] * Honoome whistles [20:29:48] <peloverde> indeed [20:30:35] <pengvado> av500: if you want to modularize it and document it, ok. I'm not motivated to do anything more to that script. [20:31:02] * Honoome is having accept() throwing ENOSUPP on a SCTP socket… doesn't look right [20:46:39] <DonDiego> hi [20:46:46] <DonDiego> anybody seen janneg around today? [20:46:54] <DonDiego> when are you guys arriving for linuxtag? [20:50:04] <merbanan> thursday [20:53:39] <av500> wednesday morning [20:56:18] <siretart> DonDiego: [20:57:01] <siretart> DonDiego: he was around here about 12h ago [20:58:13] <DonDiego> Yuvi: will you apply the theora bitexactness thing? [20:58:23] <DonDiego> i have gregory maxwell complaining at me... [21:02:01] <Honoome> does anybody here have a known-working sctp setup? [21:29:14] <dezodorant> aaa eee. pengvado thanks for idea, i found that fxxxing commit [21:29:17] <dezodorant> [988fbb31456dd3dbdf1ea42bbba664bd8eff9a09] Rewrite mp3 parser. New code is much simpler and does not drop stuff at random. [21:33:19] <peloverde> It's funny how fedora is willing to ship non-LGPL compatible code linked to LGPL code... http://blogs.gnome.org/otte/2010/05/31/youtube-out-of-the-box/ [21:34:28] <Dark_Shikari> BUT ITS FREEEEEEEEEEEE [21:34:39] <Honoome> Dark_Shikari: oh shut up, I was going to say that line myself! [21:35:01] <siretart> peloverde: well, technically, they don't [21:35:03] * Honoome is glad they didn't use Ogg… [21:35:03] <Dark_Shikari> YOU'RE NOT FREE ENOUGH [21:35:33] <j-b> peloverde: blog about it [21:35:38] <peloverde> siretart, what do you mean "they don't?" [21:36:55] <siretart> peloverde: the code is not dynamically linked but loaded via dlopen. so strictly speaking, the violation happens at runtime on the users system [21:37:21] <Dark_Shikari> That's not an excuse [21:37:28] <Dark_Shikari> remember clisp and readline? [21:37:29] <Dark_Shikari> Yeah. [21:37:56] <peloverde> DS is right [21:38:14] <Honoome> violation only happens if FSF feels like it does, I guess [21:38:34] <siretart> btw, for comparison: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583758 [21:42:42] <CIA-55> ffmpeg: diego * r23394 /trunk/LICENSE: Add a short note about libvpx. [21:44:36] <peloverde> Even if libgstvpx is relicensed to BSD, don't we still have the clisp situation higher up the food chain? [21:45:58] <twnqx> i thought that situation only occurs with "does not work (meaningful) without"? [21:48:37] <peloverde> with that definition of "does not work meaningfully without" we could dlopen a decent AAC encoder, no? [21:50:42] <CIA-55> ffmpeg: siretart * r23395 /branches/ (0.6 0.6/LICENSE): [21:50:42] <CIA-55> ffmpeg: Add a short note about libvpx. [21:50:42] <CIA-55> ffmpeg: backport r23394 by diego [21:50:47] <Honoome> peloverde: only if Google were to acquire Nero/ahead [21:51:29] <peloverde> These rules don't seem to be contently applied [21:52:55] <j-b> Fedora and Novell people are refusing all FFmpeg code (and refuse to package VLC until we split our packages...) but are always fine to listen to the license mess GST has [21:53:49] <Dark_Shikari> good thing nobody uses fedora for desktop linux anyways [21:53:57] <peloverde> Sometimes I wonder if it would have been better to spend all the money used on vp8 and theora to fight software patents [21:54:04] <Dark_Shikari> just host a fedora package on the videolan official site [21:54:05] <Dark_Shikari> to spite them [21:54:05] <j-b> Dark_Shikari: linus does [21:54:22] <peloverde> I'm looking for a non-ubuntu alternative [21:54:28] <Dark_Shikari> arch [21:54:29] <Dark_Shikari> gentoo [21:54:33] <j-b> peloverde: Arch [21:54:56] <saintdev> arch broke for me within 3 days....and most of my other installs are gentoo [21:55:06] <Dark_Shikari> so the gentoo installs broke in 2 hours? [21:55:35] <saintdev> only times my gentoo installs have broken is when i've done something stupid [21:55:39] <j-b> debian/sid [21:55:56] <twnqx> i have a sid in my c64 [21:56:47] <saintdev> ie: forgetting to compile root fs driver in the kernel, then attempting to boot it [21:57:09] <Honoome> saintdev: what about blindly updating the system and then forget to run the cleanup tasks? :P [21:57:32] <saintdev> i don't blindly update [21:57:41] <saintdev> that's just asking for trouble [21:58:14] <peloverde> debian/sid is a non-starter for me, last I checked they linked chromium to system ffmpeg [21:58:15] <Honoome> that's about 80% of the problems people encounter with Gentoo :/ [21:58:41] <peloverde> vanilla ffmpeg has lots of crashers that don't exist in th chromium hardened version [22:00:37] <peloverde> I like the idea of ubuntu but so much stuff breaks every release, and filing bugs against the beta doesn't seem to help [22:01:15] <Dark_Shikari> yup, latest ubuntu is still broken completely in vmware [22:01:19] <Dark_Shikari> it's impossible to make it even work [22:01:29] <Dark_Shikari> I had to roll back via a VM wipe [22:01:45] <Dark_Shikari> And the bug had been reported weeks before release. [22:01:55] <Dark_Shikari> The solution involved typing a variety of commands once logged in. [22:02:00] <Dark_Shikari> This doesn't help, since the bug is that the KEYBOARD IS BROKEN [22:02:09] <peloverde> I'm more concerned about stuff like zzuf just disappearing, and vim spamming the console, and wish not playing nice with compiz [22:02:21] <CIA-55> ffmpeg: bcoudurier * r23396 /trunk/libavcodec/h264.c: Pass codec pixel format list to get_format, if present, fix vdpau decoding [22:02:29] <kierank> use virtualbox instead? [22:02:42] <Dark_Shikari> iirc there were people reporting the same with vbox [22:02:44] <Dark_Shikari> and other vm systems [22:04:18] * Honoome just loves ubuntu… their gnome rdp server fails to work with gentoo's (and fedora's) gnome rdp client [22:20:10] <DonDiego> janneg: try leaving and reentering the channel.. [22:24:22] <DonDiego> there you go :) [22:24:33] <DonDiego> ok, make your first commit.. [22:25:00] <janneg> make still runs [22:32:01] <janneg> done [22:32:42] <CIA-55> ffmpeg: janne * r23397 /trunk/ffmpeg.c: ffmpeg: fail if user selected codec is experimental and strict_std_compliance > experimental [22:36:06] <CIA-55> ffmpeg: janne * r23398 /trunk/ffmpeg.c: ffmpeg: offer alternatives for experimental codecs if they exist [22:45:27] <DonDiego> welcome aboard [22:45:29] <DonDiego> ok, gnite

1 0