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

[irc at mansr.com]

[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_121paper144.pdf 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 at 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 at 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-In-Language-Popularity << 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