[FFmpeg-devel-irc] IRC log for 2011-03-02

[irc at mansr.com]

[00:00:23] <Sean_McG> yeah I wonder if it's a Debian patch
[00:00:42] <Sean_McG> (or OBSD)
[00:02:06] <Sean_McG> BTW I like how that poisonous people video mentions the big names we all know for being irritating: Theo deRaadt, DJ Bernstein(sp?), and uh... the 3rd isn't coming to me
[00:05:12] <Dark_Shikari> stallman?
[00:05:32] <Sean_McG> yeah, probably.
[00:14:16] <peloverde_at_wor> I thought it was drepper
[00:14:33] <peloverde_at_wor> stallman's brand of annoying is a little more on the weird and creepy side
[00:15:02] <Sean_McG> yeah, as in: for god sakes dude, BUY A RAZOR
[00:17:19] <iive> i guess nobody invented libre razors.
[00:17:29] <Sean_McG> indeed.
[00:17:37] <mru> peloverde_at_wor, Yuvi: will you guys be in the bay area around april 10?
[00:18:12] * mru is thinking of popping over for a week or so
[00:19:01] <peloverde_at_wor> I will be
[00:20:28] <mru> going to the ELC conf by any chance?
[00:24:35] <BBB> peloverde_at_wor: do you want to mentor bsacaac again this year?
[00:24:50] <mru> BBB: oh right, you're moving to that area too...
[00:24:54] <mru> when does that happen?
[00:24:58] <BBB> not there yet at that time
[00:25:05] <BBB> actually, I may be
[00:25:06] <BBB> not sure
[00:25:12] <peloverde_at_wor> BBB: sure, if any students are interested
[00:25:15] <BBB> permanent move is a little later, but I may be around then anyway
[00:26:39] <BBB> peloverde_at_wor: ok, re-added
[00:27:37] <Jumpyshoes> sigh gsoc ;(
[00:28:01] <mru> feeling left out?
[00:28:20] <Jumpyshoes> i want to do something this summer
[00:29:16] <peloverde_at_wor> The foundation can probably find money if you are interested and unelligible for gsoc
[00:29:17] <mru> code!
[00:29:18] <BBB> we should get you to do wmalossless
[00:29:30] <BBB> Jumpyshoes: yeah, I thought a company was going to donate for wmalossless?
[00:29:38] <Jumpyshoes> waiting on that
[00:29:41] <BBB> Jumpyshoes: we can propose that the foundation helps
[00:29:51] <BBB> Jumpyshoes: just start coding, we'll find at least some funding for it
[00:29:59] <Jumpyshoes> huh, okay
[00:30:00] <vcs> mmm, the bug went away with the version i got from GIT :)
[00:30:23] <Jumpyshoes> i think the wmalossless header is an asf header
[00:30:36] <mru> what a surprise
[00:30:55] <Jumpyshoes> where is that coded in ffmpeg?
[00:41:41] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier at gmail.com> master * rfffdee89cc ffmpeg/libavformat/movenc.c:
[00:41:41] <CIA-15> ffmpeg: movenc: fix tkhd height for imx
[00:41:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:41:41] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier at gmail.com> master * r99bbc781e9 ffmpeg/libavcodec/ (dnxhdenc.c dnxhdenc.h):
[00:41:41] <CIA-15> ffmpeg: dnxhd: allow encoding with Avid Nitris compatibility.
[00:41:42] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:41:43] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier at gmail.com> master * r06ed4873e6 ffmpeg/libavformat/movenc.c:
[00:41:44] <CIA-15> ffmpeg: movenc: use correct tag for dvcpro hd
[00:41:44] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:41:53] <BBB> Jumpyshoes: nowhere
[00:42:00] <BBB> Jumpyshoes: but likely it's similar to the one in wmaprodec.c
[00:42:27] <Jumpyshoes> hrm, okay
[00:42:47] <Dark_Shikari> Hmm
[00:42:54] <Dark_Shikari> is it possible to union an array element?
[00:43:03] <mru> elaborate
[00:43:13] <Dark_Shikari> e.g. vp56mv bmv[16];
[00:43:16] <Dark_Shikari> vp56mv mv;
[00:43:19] <Dark_Shikari> make "mv" overlap bmv[15].
[00:43:49] <mru> why not just say bmv[15]?
[00:43:49] <Dark_Shikari> ... I guess that's almost more Fortran-like than C-like.
[00:45:14] <Kovensky> does the ordering of local variables affect how stack is allocated or does the compiler decides how to arrange it?
[00:45:26] <mru> unspecified
[00:45:45] <Kovensky> I also suppose that assuming the stack grows downwards is dragon territory
[00:45:52] <mru> oh yes
[00:46:01] <mru> there are 4 stack modes
[00:46:16] <Dark_Shikari> I could make a define, I guess
[00:46:24] <Dark_Shikari> just kinda ugly to use bmv[15] in 50 places
[00:46:31] <mru> #define it
[00:46:56] <Dark_Shikari> #define mv might break a lot of things.
[00:46:59] <Dark_Shikari> even within a file
[00:47:18] <mru> then don't
[00:47:29] <Kovensky> use a pointer?
[00:47:40] <mru> pointers are evil
[00:47:57] <mru> well, not the pointers as such
[00:48:03] <mru> but what they might or might not alias
[00:48:05] <Kovensky> they do their job though
[00:48:05] <Kovensky> =p
[00:49:37] <Kovensky> even if you have to just use *mv everywhere, it's still better than bmv[15], although not as cute as just mv
[00:49:50] <Dark_Shikari> pointers hurt performance
[00:49:51] <mru> that's not the issue
[00:50:01] <mru> the compiler can't know it's the same as bmv[15] anymore
[00:50:16] <mru> and will assume it migth be just about anything
[00:50:55] <Kovensky> if it's a local variable, I'm pretty sure good analysis would be able to tell whether the point is modified or not
[00:50:56] <mru> you can often gain a lot of performance by pulling struct fields into local variables, doing stuff, and writing them back
[00:51:28] <Kovensky> pointer*
[00:51:43] <mru> not the pointer, what it points to
[00:52:00] <Kovensky> ic
[00:52:03] <Kovensky> damn multithreading!
[00:52:04] <mru> take two pointers, int *a, *b;
[00:52:06] <mru> *a = 0;
[00:52:10] <mru> what is *b now?
[00:52:16] <mru> you don't know
[00:52:27] <mru> unless you can prove that a != b
[00:52:32] <mru> and more often than not, you can't
[00:52:47] <mru> multithreading has nothing to do with it
[00:53:21] <mru> this is where the restrict keyword can be used
[00:54:11] <mru> it's a promise that for the lifetime of the restrict-qualified pointer, every access to whatever it points to will be done through a pointer derived from said pointer
[00:55:12] <mru> and that's fine, ignoring for the moment that gcc ignores it
[00:55:22] <mru> but it doesn't help in the opposite situation
[00:55:47] <mru> where you have a pointer you _know_ is an alias for something but you can't tell the compiler
[00:56:11] <mru> usually you can of course simply use that other name directly
[00:57:07] <Kovensky> 21:52.30 mru: unless you can prove that a != b <-- that's a case of uninitialized pointer access though
[00:57:49] <Kovensky> if you have { int *a, b; a = b; *a = 0; }, you can be sure that *a == b
[00:59:31] <mru> void foo(int *a, int *b) { *a = 0; *b = 1; return *a; }
[00:59:37] <mru> what does that function return?
[01:00:40] <peloverde_at_wor> trick question, it's void
[01:01:32] <pasteeater> Sean_McG: your ML replies seem to be orphaned for me at least. no "References" header?
[01:01:35] <mru> s/void/int/
[01:02:12] <mru> pasteeater: blame the crackberry
[01:02:15] <Sean_McG> pasteeater: probably my BlackBerry not doing that
[01:02:36] <Sean_McG> unless you mean the code, which I used 'git send-email'
[01:03:11] <pasteeater> not the code
[01:03:24] <Sean_McG> OK it's the BB then
[01:03:51] <Kovensky> 21:59.37 mru: what does that function return? <-- ENOCLUE
[01:04:00] <Sean_McG> and I don't include the original text otherwise Diego chews me out for top-posting
[01:05:25] <mru> Sean_McG: http://cache.gawkerassets.com/assets/images/4/2010/09/500x_angrybirds.jpg
[01:05:48] <Sean_McG> mru: hahahah
[01:06:02] <mru> Kovensky: with the return type corrected, the answer depends on the values of the pointers passed in
[01:06:39] <Kovensky> yes, which is an unpredictable case since it depends on exernal data
[01:06:42] <Kovensky> external*
[01:07:23] <peloverde_at_wor> suppose they are marked restrict?
[01:07:40] * Kovensky never dealt with restrict
[01:08:01] * Kovensky reminds himself of his 11yo self which took weeks until understanding what static meant
[01:08:49] <mru> static is a storage class specifier
[01:09:04] <Kovensky> I know
[01:09:10] <Kovensky> it modifies a declaration tough :>
[01:09:16] <Kovensky> which restrict also does :E
[01:11:27] <mru> hmm, clang does something with the restrict keyword
[01:23:57] <Dark_Shikari> Hmm, I can get vp8macroblock down to 68 bytes
[01:24:00] <Dark_Shikari> 64 bytes would be awesome
[01:24:47] <mru> what have you got so far?
[01:25:17] <Dark_Shikari> ?
[01:25:43] <mru> your statement implies you've reduced it from what it is currently
[01:25:47] <Dark_Shikari> 72 -> 68
[01:25:49] <Dark_Shikari> the MVs are 64 bytes
[01:25:58] <Dark_Shikari> skip/mode/refframe/partitioning are 4
[01:26:11] <Dark_Shikari> splitting the latter out would get the mvs alone into 64 bytes, but you'd have to keep track of two separate structs
[01:26:24] <Dark_Shikari> and I don't think we can get mvs below 4 bytes each
[01:26:36] <Yuvi> mru: yep, I'll be around
[01:26:40] <Dark_Shikari> Guess I probably can't.
[01:26:52] <mru> I suppose using bit fields of <8 bits for some of those others could reduce it a little
[01:26:59] <mru> actually no
[01:27:03] <Dark_Shikari> wonder if it's worth doing a totally-confusing reordering of the mvs to save 4 bytes from 72 -> 68
[01:27:06] <Dark_Shikari> might save a few instructions too
[01:27:07] <mru> vp56mv has align(4)
[01:27:35] <Dark_Shikari> the core idea: the last MV in the macroblock is always [15]
[01:27:39] <Dark_Shikari> so 16x16: [15]
[01:27:46] <Dark_Shikari> 16x8: [7], [15]
[01:27:48] <Dark_Shikari> 8x16: [13], [15]
[01:27:50] <mru> Yuvi: cool, I'll let you know if I decide to go
[01:27:53] <Dark_Shikari> 8x8: [5], [7], [13], [15]
[01:27:57] <Dark_Shikari> 4x4: [0]...[15]
[01:28:12] <Dark_Shikari> currently it's [0], [0][1], [0][1], [0][1][2][3], and [0]..[15].
[01:29:00] <mru> depends on where I can find to stay cheaply too
[01:29:11] <Dark_Shikari> where are you heading?
[01:29:23] <mru> bay area, mid april
[01:29:32] <Dark_Shikari> what's there?
[01:29:46] <mru> bunch of ffdevs and a linux conference
[01:30:00] <Dark_Shikari> Is this that google thing?
[01:30:05] <mru> no
[01:30:06] <Dark_Shikari> Could we get that scheduled then? `-`
[01:30:17] <mru> what google thing?
[01:30:32] <Dark_Shikari> Google offering to host an ffmpegdev party
[01:30:35] <Dark_Shikari> all expenses paid
[01:31:05] <Jumpyshoes> woah what
[01:31:28] <mru> Jumpyshoes: just another day in the glamorous life of the multimedia hacker
[01:32:40] <Jumpyshoes> well i get to go to google in may which is nice
[01:32:53] <Jumpyshoes> i haven't been to san francisco before
[01:32:58] <mru> damn, I've run out of compilers to break again
[01:33:07] <Dark_Shikari> clang is probably still buggy as fuck
[01:33:17] <mru> of course
[01:33:28] <mru> I filed a bunch of bug reports earlier this week
[01:33:38] <mru> no response yet
[01:33:47] <mru> waiting for fixes on armcc
[01:33:57] <mru> got open bugs on gcc
[01:34:57] <mru> fixed a few things in path64 mips backend
[01:35:09] <Jumpyshoes> i thought gcc never did anything
[01:35:19] <mru> there was a hilarious bug there
[01:35:35] <mru> they used %d instead of %x to print some alignment values
[01:35:40] <Jumpyshoes> wat
[01:35:40] <mru> guess what happened
[01:36:06] <mru> shit got misaligned and crashed of course
[01:36:14] <Jumpyshoes> rofl
[01:36:30] <mru> unfortunately I don't have hardware to test it properly
[01:37:36] <Jumpyshoes> gcc is a wonderful compiler ;)
[01:37:41] <mru> waiting for a login on a supercomputer for that
[01:37:45] <mru> Jumpyshoes: this wasn't gcc
[01:37:49] <mru> it was pathscale
[01:37:54] <Jumpyshoes> oh
[01:38:23] <Jumpyshoes> that's a really stupid bug
[01:38:29] <Jumpyshoes> on the devs part
[01:38:40] <mru> simple typo
[01:38:44] <Sean_McG> I've been helping with gcc 4.6 on Solaris... it's not considered one of their "primary platforms" (presumably because it's not FOSS), but they've been really good about responding to the Bugzillas I've filed
[01:38:44] <mru> could happen to anyone
[01:39:08] <Sean_McG> we have *1* P1 bug left before release of 4.6, so hopefully that will be soon
[01:39:33] <mru> the rest have been downgraded so as not to taint the release
[01:39:38] <mru> that's what they usually do
[01:40:01] <Sean_McG> I'd have to look at the history, but there are some P1s that aren't really P1s
[01:40:18] <mru> and P2s that are really P1s
[01:40:47] <mru> gcc is a lottery
[01:40:51] <Sean_McG> anyways I'm not gonna argue... compilers are complicated
[01:41:02] <mru> if you get the attention of the right dev things move along
[01:41:12] <mru> otherwise they can sit ignored or even rejected for years
[01:41:36] <Sean_McG> I think any open source project can have that problem
[01:41:53] <mru> most gcc devs are paid full time
[01:41:55] <mru> to work on gcc
[01:42:02] <Sean_McG> fair point
[01:42:17] <mru> it's their job, the "but it's open source" excuse doesn't work for them
[01:42:42] <mru> so far, arm have fixed all bugs I've reported by the next release
[01:43:03] <mru> releases happen every few months
[01:48:41] <Compn> rukhsana : btw have you worked with compression or codecs or anything similar before ? jpeg2000 is wavelet and one of the harder things to master...
[01:49:28] * Compn wonders how big jp2k spec is
[01:50:40] <Yuvi> 190 pages, plus 332 pages of extensions
[01:50:49] <Compn> how big is h264 spec ?
[01:50:55] <Dark_Shikari> ~800, but that's including SVC/MVC
[01:51:02] <Dark_Shikari> AVC-only is about 300
[01:51:09] <Compn> ehe
[01:51:12] <Dark_Shikari> the actual substantive part is about 150
[01:53:02] <rukhsana> sorry Compn
[01:53:08] <rukhsana> i was away
[01:53:30] <rukhsana> i used ffmpeg a lot in my research
[01:53:45] <rukhsana> especially i used mpeg4 encoded video
[01:54:15] <rukhsana> i am reading the code too
[01:55:17] <Compn> ok, no problem. just thought i'd warn you :)
[01:55:51] <Compn> kshishkov : what are you up to now? still reverse engineering ?
[01:56:10] <rukhsana> what exactly the problem in current JPEG 2000 in ffmpeg?
[01:56:27] <Compn> the decoder is incomplete
[01:56:35] <rukhsana> could you please give little bit idea about it?
[01:56:51] <rukhsana> so, encoder is complete?
[01:56:51] <Compn> and possibly has some bugs
[01:57:07] <Compn> i dont think there is encoder at all
[01:59:30] <rukhsana> i see in the code, there is a encoder
[02:00:11] <rukhsana> and there is a decoder, however probably incomplete
[02:00:11] <Compn> ah i havent looked at it
[02:00:44] <rukhsana> ok
[02:02:14] <rukhsana> do you suggest me to work on any other stuff except jpeg 2000 as everyone is saying its hard to master
[02:02:53] <rukhsana> since i used ffmpeg before, i am a little bit familiar with it
[02:17:34] <hyc> can someone explain to me why ffmpeg can rewrap an h264 video from MP4 to MKV format, but coming back again it fails due to out of order timestamps?
[02:18:09] <kierank> hyc: because mkv doesn't have dts and ffmpeg has to guess them
[02:18:13] <hyc> if I extract the video out to raw h264 file, I can remux it as mp4 then
[02:18:26] <kierank> and at the moment it guesses them incorrectly
[02:19:26] <hyc> interesting
[02:20:13] <hyc> so why does going out to raw h264 and coming back work? is someone else doing a better job of guessing?
[02:23:48] <Compn> hyc : is there an option to disable dts whatnot in the muxer ?
[02:24:07] <hyc> there may be but I didn't specify anything
[02:24:21] <Compn> i think baptiste is mp4 maintainer
[02:24:28] <Compn> might send him an email with a sample command line
[02:24:41] <Compn> e.g. ffmpeg -i http://samples.mplayerhq.hu/mkv/blah.mkv out.mp4
[02:25:03] <Compn> of course, probably not a problem with mp4 muxer but somewhere else
[02:25:19] <hyc> yeah, I'm guessing mkv demux
[02:25:42] <hyc> but I don't understand what the actual problem is, since the demux output obviously decodes and plays
[02:25:44] <Compn> non monotone timestamp error or what ?
[02:25:50] <hyc> yes, exactly
[02:26:01] <Compn> and just vcodec copy ?
[02:26:06] <hyc> yep
[02:27:09] <Compn> ah yes
[02:27:56] <Compn> http://roundup.ffmpeg.org/issue807
[02:27:59] <Compn> theres the bug
[02:28:43] <Compn> and some patches
[02:28:43] <Compn> :)
[02:38:46] <hyc> thx
[02:41:06] <hyc> I had already found one of those patches, from roozhou. applied to current git, didn't fix the error
[02:41:19] <hyc> but I hadn't read this bug yet. will see if it sheds any more light
[02:44:55] <hyc> and currently if I try: ffmpeg -i foo.mkv -vcodec copy -acodec copy /tmp/bar.mkv it fails with
[02:45:09] <hyc> [matroska @ 0x178a160] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 30 >= 30
[02:47:38] <Compn> yeah, i can see this is an annoying bug ;\
[02:49:07] <hyc> changing the >= to > in libavformat/utils.c shuts up the error
[02:50:02] <hyc> and the resulting file plays fine
[02:50:24] <Compn> in a non-ffmpeg based player ?
[02:50:30] <hyc> hmmmmmmm
[02:50:33] <Compn> thats always the trick
[02:50:39] <hyc> dunno if I have such a thing
[02:50:41] <Compn> stupid buggy lavf will play stupid buggy lavf files :P
[02:50:49] <Compn> well... quicktime if you are lucky
[02:51:17] <hyc> flash too I suppose
[02:51:21] <Compn> maybe latest microsoft product and flash yep
[02:51:31] <Compn> silverlight does mp4/h264
[02:51:33] <Compn> iirc
[02:51:45] <hyc> hmmm, yeah, dunno what silverlight is doing
[02:52:07] <Compn> a thousand mp4 files per video because mp4 cannot be streamed live ;p
[02:52:11] <Compn> ehe
[02:52:26] <hyc> lol. yeah, saw that. so ridiculous
[02:52:46] <hyc> clearly the folks who created the mp4 format overlooked something obvious :P
[02:53:27] <hyc> much as I think rtmp is a miserable protocol, at least it supports live streaming with flv
[02:54:24] <hyc> btw http://www.metacafe.com/channels/highlandsun/
[02:54:40] <hyc> I uploaded videos from a concert my band played Feb 13
[02:55:13] <hyc> recorded in AVCHD, dropped down to 720x480 with ffmpeg
[02:55:30] <hyc> watermark added using movie filter
[02:55:38] <hyc> which hopefully will go into the main repo soon
[02:59:19] <kierank> hyc: well mp4 was meant to be a storage format
[03:00:11] <kierank> probably mpeg created a streaming system that nobody uses
[03:00:40] <kierank> and to play devils advocate a bit I don't think they anticipated the whole http progressive download thing at all
[03:01:03] <ohsix> would be quite a trick if they had
[03:01:29] <Compn> kierank : mpegts is i guess the streaming solution
[03:01:39] <Compn> thats what apple uses now
[03:02:49] <Compn> hyc : thats a lot of kilts :p
[03:02:50] <Compn> hehe
[03:03:41] <Compn> got a downloadable album or should i just rip audio out of these vids :P
[03:04:07] <Compn> my non internet-savvy dad enjoys listening to new music
[03:09:05] <kierank> Compn: yeah
[03:09:21] * kierank watches hyc's band
[03:10:35] <hyc> lol I need to go get another kilt
[03:11:13] * Compn should purchase one as well
[03:11:47] <Compn> wonder if i should look up my colors or just go camo
[03:11:54] <Compn> the 'cargo kilt' maybe
[03:12:39] <gnafu> I remember Pat on The Screensavers would always talk up Utilikilts back in the day.
[03:12:44] <gnafu> Seems so long ago now...
[03:12:46] <Compn> yes that guy
[03:12:46] <hyc> yeah, I'm not so keen on the camo thing. but don't have a clan to look up ;)
[03:12:50] <Compn> thats what i'm talkin about
[03:15:13] <Compn> metacafe keeps refreshing off your page tho, the next mvid in the lineup was a ceelo song hehe
[03:15:34] <hyc> bizarre :P
[03:15:35] <gnafu> Compn: Which one?
[03:15:43] <Compn> ceelo 'its ok'
[03:15:55] <gnafu> Fun; I just heard that for the first time the other day.
[03:15:56] <hyc> Compn: have it all on youtube too, I just didn't have the watermarks on those
[03:16:10] <hyc> takes friggin hours to upload this stuff on crap cable
[03:16:17] <Compn> watermark is unobtrusive which is nice
[03:17:19] <hyc> yeah, did several runs playing with transparency in gimp before I settled on that
[03:18:13] <Compn> i dont know when avfilter is going to be merged
[03:18:17] <Compn> stefano would know
[03:18:32] <Compn> or is it already merged, but some filters arent ?
[03:18:33] <Compn> hmm
[03:18:41] <hyc> avfilter is there, movie is not
[03:18:45] <Compn> ah
[03:19:06] <hyc> which is even more confusing because movie is in the avfilter doc on ffmpeg.org
[03:19:33] <Compn> hehe
[03:52:02] <Sean_McG> has there ever been any thought into localizing error messages in ffmpeg? using libintl or summat?
[03:52:22] <Compn> have you seen mplayer's localization ?
[03:52:31] <Sean_McG> no
[03:52:52] <Compn> not sure if its better / worse than libintl
[03:53:02] <Compn> but something to look at anyhow
[03:53:12] <mru> needless complexity
[03:53:37] <Compn> also, there was a limitation that only one language could be compiled at any time, but i think uau might have been working on it to support all langs in one binary
[03:53:47] <Sean_McG> I'm an English speaker myself, but whatever
[03:54:11] <mru> there's not much textual interaction other command line flags anyway
[03:54:16] <mru> and you don't want to translate those
[03:54:40] <Compn> i think mplayers system isnt that complex :P
[03:54:54] <mru> feel free to translate the documentation though
[03:54:59] <Sean_McG> that's fine if you don't want it, I was just curious
[03:55:10] <mru> that's my personal opinion
[03:55:23] <mru> translations take a lot of effort to maintain
[03:55:34] <Sean_McG> this is true
[03:56:07] <Compn> somehow mplayer's translations are up to date :P
[03:56:39] <mru> maybe that's because mplayer hasn't been very actively developed for some years
[03:56:57] <mru> and it doesn't contain a great deal of text either
[03:57:01] <Sean_McG> it does kinda take someone willing to "step up to the plate" for each localization, and if that's too much to ask then yeah I guess there's no point
[03:57:23] <mru> someone has to step up and stay up forever
[03:57:33] <mru> it's not a one-off task
[03:57:43] <Sean_McG> that's what I meant
[03:57:51] <Compn> thats like saying someone has to maintain the same code forever
[03:57:59] <Compn> but whatever, night
[03:58:00] <mru> no
[03:58:04] <Sean_McG> sleep well
[03:58:26] <mru> if the code is changed at all, and chances are it will, the translations will need updating
[03:58:44] <mru> but it's unlikely that every code contributor is able to update the translations for the strings he affects
[03:58:59] <Compn> its the exact same as what we have now
[03:59:08] <mru> no it's not
[03:59:29] <mru> as it is now, if you change the code you're done
[03:59:38] <mru> you don't need to _also_ fix 200 translations
[03:59:40] <Compn> just replace translation with x86/asm/ssse3/ppc/64bit/bsd
[04:00:07] <mru> stop trolling
[04:00:13] <Compn> if a translation gets changed it reverts back to the english
[04:00:23] <Sean_McG> OK OK, forget I brought it up
[04:00:26] <Compn> lol
[04:00:35] <ohsix> _() for strings you'd want to translate ftw
[04:01:02] <mru> blatantly ignoring that _ is a reserved identifier at file scope
[04:01:37] <ohsix> o noes
[04:01:46] <Compn> the only thing bad i'd say is that it makes debugging other languages somewhat harder , like 1% harder maybe :P
[04:02:14] <mru> it's a pile of maintenance burden for little or no benefit
[04:02:31] <mru> the strings people actually use most of the time, the command line flags, won't be translated anyway
[04:02:34] <Compn> i havent seen many requests for ffmpeg translations
[04:02:53] <Compn> of course i havent been looking specifically for it
[04:03:04] <mru> for a gui app it's an entirely different matter
[04:03:47] <mru> the vast majority of strings in ffmpeg are either options or error messages
[04:04:00] <mru> the former should not be translated and the latter should rarely be seen
[04:04:30] <mru> and most people understand a bit of english
[04:05:17] <ohsix> and if they don't fuck 'em
[06:28:12] <kierank> oh god, mxf over rtp
[06:35:04] <Dark_Shikari> !!!!!
[06:35:08] <Dark_Shikari> mxf over rtp jesus fucking christ
[06:35:13] <Dark_Shikari> what next, ogg over avi over mxf over rtp?
[06:40:31] <kierank> what's worse is that jpeg2000 is being put in those mxf files
[06:47:50] <peloverde> ugh, finally home from work
[06:54:21] <Dark_Shikari> Hmm, I need to write a regular expression to cover multi-line comments
[06:54:25] <Dark_Shikari> e.g. /* ... */
[06:54:43] <Dark_Shikari> so I need some way to have an expression that matches "anything that doesn't contain */" to cover the middle.
[06:54:49] <Dark_Shikari> how do I do that?  I only know how to do that for single characters.
[06:54:53] <Dark_Shikari> i.e. "not *"
[06:54:57] <Dark_Shikari> not "not */"
[06:55:10] <pengvado> I can do that in perl. dunno about posix regex.
[06:55:23] <Dark_Shikari> this is for lex
[06:55:27] <Dark_Shikari> dunno what features it does
[06:55:55] <Dark_Shikari> how would one do it in perl?
[06:56:23] <Dark_Shikari> ... though it's alex, not lex.
[06:56:43] <pengvado> the simple way is /\*.*?\*/
[06:57:44] <pengvado> however, that can fail if it's part of a larger regex, since *? prefers the smallest match possible but other constraints can make it take a larger one
[06:58:49] <pengvado> the robust way is /\*((?!\*/).)*\*/
[06:59:07] <Dark_Shikari> hmm, the ? parse-errors.
[07:30:57] <Dark_Shikari> Hmmm.  If jb_CeBIT doesn't apply for GSOC with videolan, can x264 sneak in through ffmpeg this time around?
[07:31:01] <Dark_Shikari> I assume ffmpeg is applying.
[07:31:51] <kierank> in b4 each ffmpeg fork applying for gsoc
[07:33:12] * elenril thinks there should be a gsoc project to merge x264 into ffmpeg
[07:34:01] <kierank> gl with that elenril
[07:39:00] <cartman> moin
[07:46:36] <irock> BBB, Dark_Shikari, ... : pong
[07:48:26] <irock> I've got 8-10 bit working in the same build
[07:49:33] <irock> what I need to do is basically to organize the code into good patches
[07:52:00] <irock> then maybe a few review rounds ;)
[07:53:06] <KotH> ohayou gozaimasu
[07:53:11] <spaam> hey KotH :DD
[07:53:12] <cartman> moin KotH
[07:53:16] <cartman> irock: awesomeness
[07:58:02] <spaam> cartman: do you think we will see it before summer ? :D
[08:08:02] <wbs> anyone with push access caring to push the aviobuf-fill_buffer() patch I sent a few days ago, which was ok'd?
[08:08:21] <Dark_Shikari> anyone ever going to fix threads auto with ffmpeg?
[08:08:23] <Dark_Shikari> It's still broken
[08:08:44] <Dark_Shikari> if nobody fixes it within a week, I'm going to rip out threads support from libx264.c
[08:08:57] <Dark_Shikari> also, a user is reporting -threads 32 resulting in 6 threads
[08:08:59] <Dark_Shikari> astrange: this is your fault
[08:47:22] <uau> Compn: i didn't make mplayer's old translation system work with multiple languages
[08:47:34] <uau> rather i ripped out the old system and replaced it with a libintl-based one
[08:47:39] <uau> the old system was just horrible crap
[08:48:49] <siretart> who is actually suggesting to localize ffmpeg?!
[08:49:46] <av500> locals?
[08:50:00] <siretart> are they? [citiation needed]
[08:50:20] <kierank> pfft everyone speaks english
[08:50:21] <kierank> it's fine
[08:50:30] <thresh> orly
[08:50:39] <wbs> nobody really is suggesting it, Sean_McG asked curiously about it but retracted his question ;P
[08:50:42] <av500> localized variable names please
[08:50:55] <wbs> av500: especially with hungarian notation
[08:51:03] <kierank> I don't see the need for anything like unicode
[08:51:08] <Dark_Shikari> for( int わたし=0; わたし<4; わたし++ )
[08:51:15] * Dark_Shikari hides.
[08:51:16] <kierank> people in #x264 for example should use a proper language
[08:51:24] <av500> s->opaque_réorganisés
[08:51:35] <kierank> silly non-english laguages right there with their square boxes
[08:51:41] <Dark_Shikari> use a proper font bozo
[08:51:48] <kierank> nah, who needs foreign languages
[08:51:49] <Dark_Shikari> UTF-8 is the future
[08:51:49] <av500> what is a font bozo?
[08:51:54] <kierank> pfft
[08:51:56] <kierank> english is the future
[08:52:07] <thresh> chinese looks more promising
[08:52:09] <thresh> or indian
[08:52:20] <elenril> more like utf-8 is the present
[08:52:20] <kierank> thresh: a lot of indian/chinese speak english
[08:52:21] <Dark_Shikari> Ｌｅｔ’ｓ ａｌｌ ｕｓｅ ｆｕｌｌ－ｗｉｄｔｈ Ｅｎｇｌｉｓｈ ｆｏｎｔｓ ｔｈｅｎ．
[08:52:33] <kierank> boo hoo i can't see your square text
[08:52:39] <Dark_Shikari> It's english though!
[08:52:56] <iive> actually all indian speak english.
[08:53:07] <Dark_Shikari> iive: I have a doubt about this.
[08:53:10] * Dark_Shikari ducks.
[08:53:10] <microchip_> rupee rupee?
[08:53:17] <av500> Dark_Shikari: lol, google translate detects you full width as japanese :)
[08:53:17] <Dark_Shikari> Please send me teh codez.
[08:53:46] <elenril> >full width
[08:53:46] <Dark_Shikari> "I have a doubt about the codes.  Can someone please send me the codes."
[08:53:50] <elenril> >weaboo detected
[08:53:56] <kierank> Dark_Shikari: it's not "Please", it's "plz"
[08:53:58] <iive> Dark_Shikari: they have over 48 local dialects, and they were english colony.
[08:53:58] <Dark_Shikari> 「weeaboo」?
[08:54:29] <elenril> don't they have a special rune for question mark?
[08:54:36] <av500> ¿
[08:54:50] <Dark_Shikari> ？
[08:54:54] <thresh> that's a spanish rune
[08:55:17] <thresh> i'm actually puzzled why wouldnt they just use a proper question mark
[08:55:20] <av500> ¡
[08:55:25] <Dark_Shikari> One goes at the start of the sentence
[08:55:27] <Dark_Shikari> one goes at the end
[08:55:31] <thresh> iKnow
[08:55:32] <av500> !yeah¡
[08:55:36] <Dark_Shikari> ¿Why?
[08:55:45] <av500> ¡because!
[08:56:00] <kierank> hmmm those spanish characters are not square boxes
[08:56:08] * kierank goes to delete all i8n fonts
[08:56:08] <Dark_Shikari> yes, because the problem is your font
[08:56:13] * Dark_Shikari punts kierank
[08:56:29] <av500> kierank: your gaelic font is broken
[08:56:40] <av500> or garlic?
[09:14:02] <peloverde> the only non-ascii codepoint that's worth while is U+0CA0
[09:15:16] <peloverde> (i kid)
[09:59:58] <lu_zero> good morning
[10:00:04] <lu_zero> wbs: let me pick it up
[10:16:48] <CIA-15> ffmpeg: Martin Storsjö <martin at martin.st> master * re360ada2d1 ffmpeg/libavformat/aviobuf.c: (log message trimmed)
[10:16:48] <CIA-15> ffmpeg: aviobuf: Write new data at s->buf_end in fill_buffer
[10:16:48] <CIA-15> ffmpeg: In most cases, s->buf_ptr will be equal to s->buf_end when
[10:16:48] <CIA-15> ffmpeg: fill_buffer is called, but this may not always be the case, if
[10:16:48] <CIA-15> ffmpeg: we're seeking forward by reading (permitted by the short seek
[10:16:49] <CIA-15> ffmpeg: threshold).
[10:16:50] <CIA-15> ffmpeg: If fill_buffer is writing to s->buf_ptr instead of s->buf_end (when
[10:17:06] <wbs> lu_zero: thanks :-)
[10:19:11] <lu_zero> sorry for the delay =P
[10:20:00] <wbs> care to push the av_pkt_dump patches from last week, too?
[10:20:07] <lu_zero> let me check it
[10:20:28] <lu_zero> btw I'm about to send some patches I prepared with diego
[10:40:13] <CIA-15> ffmpeg: Martin Storsjö <martin at martin.st> master * r863c471638 ffmpeg/libavformat/ (avformat.h utils.c):
[10:40:14] <CIA-15> ffmpeg: libavformat: Add av_pkt_dump{, _log}2, taking an AVStream parameter
[10:40:14] <CIA-15> ffmpeg: This removes a fixme issue, by allowing the av_pkt_dump functions
[10:40:14] <CIA-15> ffmpeg: to use the correct time base.
[10:40:14] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[10:40:26] <CIA-15> ffmpeg: Martin Storsjö <martin at martin.st> master * r5e33e7bdac ffmpeg/ffmpeg.c:
[10:40:26] <CIA-15> ffmpeg: ffmpeg: Use av_pkt_dump_log2
[10:40:26] <CIA-15> ffmpeg: This makes dumped packet timestamps proper for streams with
[10:40:26] <CIA-15> ffmpeg: timebases other than AV_TIME_BASE.
[10:40:27] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[10:50:14] <ffmpeg> how do i enable the tprintf functions in ffmpeg while debugging?
[10:50:37] <ffmpeg> is there a specific option i have to set during the configure stage?
[10:51:13] <kshishkov> go to channel named after you
[10:53:14] <av500> or just use av_log
[10:53:51] <ffmpeg> i want to see the output of the calls to the tprintf function that are already in the source code
[10:56:21] <kshishkov> uncomment #define TRACE in libavcodec/get_bits.h and rebuild FFmpeg
[11:17:45] <ffmpeg> -loglevel debug option does not seem to work, do i have to set something else?
[11:44:42] <DonDiego> [OFFTOPIC]: has anybody had issues with disappearing mouse cursors under X? this is driving me nuts here at work...
[11:44:53] <kshishkov> you?
[11:45:21] <DonDiego> +else
[11:45:24] * elenril mumbles something about unhelpful commie trolls
[11:46:08] <kshishkov> DonDiego: like https://bugs.launchpad.net/xorg-server/+bug/63905 ?
[11:47:11] <DonDiego> not sure if this is related, hmmm
[11:47:43] <kshishkov> have you tried "swcursor" option as recommended there?
[11:48:23] <DonDiego> i will in a moment...
[11:48:40] <DonDiego> i get the problem intermittently, not just after X restarts..
[11:49:23] <elenril> DonDiego: try software cursor?
[11:49:46] <DonDiego> on it, i need to reboot :-(
[11:53:30] <iive> is that on mac?
[11:54:39] <DonDiego> no, linux machine, i have two sitting under my desk here
[11:54:52] <av500> running?
[11:54:58] <kshishkov> av500: sitting
[11:55:12] <av500> sitting what distribution?
[11:55:39] <kshishkov> probably it has something to do with video card designer
[11:56:17] <iive> i mean, mac hardware. what is the video card?
[11:56:25] <cartman> av500: I got a report from a user that February firmware update for A101 did not fix the buggy DPI report problem
[12:06:20] <av500> cartman: i saw the fix in our svn
[12:06:26] <av500> i dunno to what release it maps
[12:07:12] <DonDiego> running sw cursor now - hopefully this will help...
[12:08:36] <cartman> av500: hmmmpf ok
[12:42:53] <ffmpeg> how can i set the avctx->debug flag to 1 via ffmpeg command line parameters?
[12:49:14] <ffmpeg> i m trying to print out the picture info using the -debug pict flag parameter
[12:49:32] <mru> -loglevel debug
[12:50:19] <ffmpeg> i do that too
[12:51:03] <ffmpeg> but when i debug in h264.c for example i see FF_DEBUG_PICT_INFO set (as expected) but s->avctx->debug unset
[13:01:02] <kierank> so if I need to access raw frame data from get_buffer in another thread, how do i make sure ffmpeg isn't reading the same data (e.g. as a reference frame)
[13:05:53] <mru> access for read or write?
[13:06:09] <mru> it's fine to have several readers
[13:06:09] <kierank> for read
[13:08:13] <kierank> that makes sense
[13:14:24] <mru> once ffmpeg calls release_buffer it's up to you to not return the same buffer in get_buffer until you're done with it
[13:17:56] <mru> morning DonDiego
[13:18:40] <kshishkov> he was here today (unlike his mouse cursor on X11)
[13:19:19] <mru> indeed, he left only a while ago
[13:19:52] <mru> still, I hadn't greeted him yet today
[13:22:26] <DonDiego> moin :)
[13:26:53] <pross-au> Q: anyone working on PIX_FMT_BGR48LE/BE?
[13:27:40] <Tjoppen> pross-au: a while back
[13:27:52] <pross-au> Ta
[13:28:59] <pross-au> can u post a wip patch
[13:30:15] <Tjoppen> oh, wait. you said BGR, not RGB. I thought you meant whether anyone had looked at the existing stuff
[13:30:38] <pross-au> B-G-R
[13:30:47] <pross-au> PhantomCINE uses it
[13:30:49] <Tjoppen> sry, nope
[13:30:55] <pross-au> we already have RGB48LE/BE
[13:30:57] <pross-au> Cool thanks
[13:31:58] <Tjoppen> I presume you mean support in libswscale?
[13:32:32] <Tjoppen> just adding it would be trivial, but sort of useless if you want to be able to scale it to something displayable :)
[13:33:05] <kshishkov> pross-au: it's easy, mate. Just swap order of components
[13:45:26] <pross-au> sure its easy, i dont want to redo work already done
[13:45:38] <pross-au> that okay, i can swap Red and Blu
[13:51:28] <cartman> just had a farewell party in my name \o/
[13:51:58] <DonDiego> this reminds me: my last birthday was exactly one year ago...
[13:52:08] <av500> cartman: do you also have concrete shoes on your feet?
[13:52:23] <av500> DonDiego: http://2.bp.blogspot.com/_2rl9OV3Auts/TOpwmT9ZaQI/AAAAAAAAKEI/11oBtWePFdg/s1600/Homer-says-happy-birthday.jpg
[13:52:24] <kshishkov> cartman: "we are glad to get rid of you"-type?
[13:52:38] <cartman> kshishkov: be back soon type :)
[13:52:52] <kierank> cartman: what do non-alcoholic leaving parties involve?
[13:53:03] <av500> sweet tea
[13:53:07] <cartman> kierank: congrats. and such :)
[13:53:11] <kshishkov> ayran
[13:53:25] <cartman> cola of course
[13:53:43] <av500> americas black gold
[13:53:58] <cartman> av500: call the border police for next week :P
[13:54:07] <av500> cartman: they are informded
[13:54:15] <cartman>  /o\
[13:54:17] <kierank> cartman: where are you going?
[13:54:22] <cartman> kierank: Germany!
[13:54:29] <av500> gastarbeiter!
[13:54:31] <DonDiego> saste: i reviewed the -map patch, but possibly not the latest version, i hope the comments apply nonetheless
[13:54:35] <kshishkov> cartman: I thought it would be Bavaria instead
[13:54:35] <cartman> Ich möhte delicious köfte!
[13:54:59] <cartman> kshishkov: yeah :P
[13:55:00] <kshishkov> av500: don't call him that, it's my profession
[13:55:22] <cartman> I promised to go back to home in 4 years
[13:55:28] <cartman> I'll keep my promise :P
[13:55:32] <av500> promised who?
[13:55:37] <av500> your pkk buddies?
[13:55:40] <cartman> av500: myself :P
[13:55:49] <av500> gee, ffmpeg left
[13:55:56] <cartman> lol
[13:55:57] <kierank> av500: that guy's a bit of a weird character
[13:55:59] <kshishkov> cartman: that's approved by av500
[13:56:09] <kierank> he sits in #x264dev with a username representing the problem he has
[13:56:12] <kierank> talks to nobodoy
[13:56:14] <cartman> :D
[13:56:16] <av500> kshishkov: i dont mind another döner vendor
[13:56:18] <kierank> except PMs people
[13:56:36] <cartman> kierank: /nick x264 ?
[13:56:45] <kierank> cartman: he uses the nick transcode
[13:56:49] <cartman> :D
[13:56:49] <kierank> because he has problems transcoding
[13:56:52] * thresh . o O ( /nick gottagetsomesleep )
[13:56:52] <cartman> lol
[13:57:02] <cartman>  /nick av500
[13:57:05] <cartman> bah already taken
[13:57:30] <kshishkov> kierank: "with a username representing the problem he has" <- FFmpeg is a problem!?
[13:57:46] <cartman> av500: don't worry my contract is indefinite :P
[13:57:47] <kierank> of course
[13:57:49] <kshishkov> av500: I think two or three döner vendors should be enough for you
[13:58:03] <av500> 2-3 million you mean
[13:58:15] * cartman will eat köfte
[13:59:03] <kshishkov> av500: no, personally for you
[14:00:56] * kierank forgot about the turkish people in germany cliche
[14:01:39] <cartman> kierank: never gets old
[14:02:04] <kshishkov> kierank: well, at laest they (along with Chinese and Indians) make Real British Food
[14:02:18] <kierank> Real British Food = NULL
[14:02:32] <av500> Weetabix
[14:02:43] <kierank> marmite
[14:02:49] <kierank> and crumpets
[14:02:49] <av500> scones and clotted cream
[14:02:51] <cartman> köfte
[14:03:46] <kshishkov> cartman: they are too ashamed to admit they build empire where Sun never sets off only to get better food than at the Isle
[14:09:18] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier at gmail.com> master * rfb98507126 ffmpeg/libavcodec/vc1dec.c:
[14:09:18] <CIA-15> ffmpeg: vc1: fix decoding when end sequence is present
[14:09:18] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:09:32] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * rff1efc524c ffmpeg/libavcodec/pthread.c:
[14:09:32] <CIA-15> ffmpeg: threads: allow thread count of zero
[14:09:32] <CIA-15> ffmpeg: This moves setting the thread count to a minimum of 1 to
[14:09:32] <CIA-15> ffmpeg: frame_thread_init(), allowing a value of zero to propagate
[14:09:32] <CIA-15> ffmpeg: through to the codec if frame threading is not used. This
[14:09:33] <CIA-15> ffmpeg: makes auto-threads work in libx264.
[14:09:34] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:37:36] * pross-au not happy
[14:38:05] <kshishkov> it happens
[14:38:29] <pross-au> wtv changes
[14:38:39] <cartman> what thee
[14:38:56] <kshishkov> is it M$ binary hierarchically-structured format?
[15:14:16] <siretart> greetings from TI @embedded-world
[15:14:27] <lu_zero> siretart: oh
[15:14:31] <lu_zero> who's there?
[15:14:43] <siretart> they present again the 6 monitor beasty wall running on the beagle boards
[15:14:56] <siretart> it was just me and a few collegues
[15:15:21] <siretart> I'm already back in my office, I've been just a few hours at the exhibition
[15:15:30] <lu_zero> I see
[15:16:07] <lu_zero> do you happen to know lutin at debian.org ?
[15:16:23] <siretart> it's kinda convinient to have such trade fairs in the home city :-)
[15:16:29] <lu_zero> indeed =)
[15:16:40] * siretart does a mia-query on lutin
[15:17:04] * lu_zero wants to organize something in Torino for ffmpeg
[15:17:21] <lu_zero> I let Puria try to organize first something for mongodb
[15:17:52] <lu_zero> if it goes well I'll try to redo changing the subject
[15:19:04] <siretart> lu_zero: last gpg activity from lutin on 26 Sep 2010, last activity in general on 08 Nov 2010. It seem strange that it seems that his last upload wasn't signed by himself
[15:19:20] <lu_zero> uhm
[15:19:39] <lu_zero> I wanted to ask him about evas and friend in debian
[15:19:52] <lu_zero> since I'd appreciate a lot two updates ^^
[15:24:32] <av500> siretart: so you saw Marie-Claire
[15:27:48] <in3xes> Why av_log() is not giving any output if log level is not 16?
[15:28:50] <lu_zero> in3xes: sounds strange
[15:28:56] <lu_zero> have a look at the code
[15:29:23] <siretart> av500: I met two guys only
[15:29:39] <av500> ah
[15:37:12] <DonDiego> bye
[15:52:19] <in3xes> Anyone responded to my question? I got disconnected.
[15:54:28] <J_Darnley> [Wed 16:28:50] <@lu_zero> in3xes: sounds strange
[15:54:28] <J_Darnley> [Wed 16:28:56] <@lu_zero> have a look at the code
[15:55:28] <av500> the code? outrageous!
[15:56:09] <lu_zero> wbs: ping
[16:02:00] <in3xes> It gives output if I write only av_log(NULL, AV_LOG_ERROR, ...). But, code says it works if it is less than current loglevel
[16:02:46] <in3xes> I tried passing arguments grater than 16, but nothing happened.
[16:06:10] <lu_zero> in3xes: to what?
[16:07:41] <in3xes> lu_zero: ffmpeg -loglevel "number" -i inputfile that is what I am doing
[16:08:54] <lu_zero> in3xes: use the words
[16:09:00] <lu_zero> -loglevel debug
[16:09:12] <in3xes> Tried that too
[16:09:56] <in3xes> Order of these arguments matters?
[16:12:42] <in3xes> Weird! Works now :)
[16:19:17] <lu_zero> ^^;
[16:22:20] <mru> lu_zero: do you know anything about the llvm and clang ebuilds?
[16:24:40] <lu_zero> mru: they worked for me so I didn't have to hack on them
[16:25:01] <mru> I'm just confused about the interaction between them
[16:25:11] <mru> clang depends on llvm but still pulls out all the llvm source
[16:27:54] <lu_zero> I can have a look
[16:28:34] <lu_zero> http://llvm.org/bugs/show_bug.cgi?id=4840
[16:29:15] <lu_zero> that's why it's pulling llvm apparently
[16:29:28] <lu_zero> the bug seems partially fixed but I'm not reading it fully
[16:31:37] <lu_zero> so I'm not sure it's still needed
[16:42:25] <mru> question is, does the clang ebuild link against the intalled llvm libs or does it build its own?
[16:45:09] * mru patches both just to be sure
[16:48:38] <lu_zero> should link to the system one
[16:48:58] * lu_zero spots a problem in cross building clang...
[16:48:59] <lu_zero> meh
[16:49:11] * mru is not surprised
[16:59:57] <lu_zero> wbs: I'd set the rtp enqueuing by default and expose the enqueue function by default
[17:00:18] <lu_zero> right now we are dropping rtp packets on interleave in theory
[17:07:02] * mru is nice today and sends patch to llvm
[17:17:52] <mru> uau: ping
[17:18:02] <uau> ?
[17:18:30] <mru> consider this:
[17:18:35] <mru> #define foo(x) 1-x
[17:18:38] <mru> foo(-1)
[17:18:46] <mru> is that allowed to expand to 1--1?
[17:19:06] <mru> gcc inserts spaces making it 1- -1
[17:19:14] <mru> the former obviously doesn't compile
[17:20:05] <uau> i don't remember that by heart
[17:20:14] <av500> c standard says?
[17:20:26] <av500> mru: arent you supposed to recite that by heart?
[17:20:28] <mru> it doesn't say anything explicitly
[17:21:14] <mru> adding whitespace is clearly allowed, but I don't think it's required
[17:21:21] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r8cf9a09d40 ffmpeg/libavcodec/vp3.c: vp3-mt: fix deadlock when first frame is not a keyframe.
[17:21:34] <av500> #define foo(x) 1-(x)
[17:21:34] <BBB> so astrange was going to send patches for mpeg-mt right?
[17:21:35] <av500> solved
[17:21:38] <mru> yes, I know
[17:21:47] <mru> and I have a patch for that
[17:21:48] <av500> mru: isnt one supposed to add () around macro params?
[17:22:36] <mru> well, yes
[17:22:44] <mru> but someone didn't, and it fails with some compilers
[17:25:32] <elenril> BBB: i'll send a patch with proper authorship in a sec
[17:27:11] <astrange> BBB: yes, but today i will do schoolwork
[17:31:39] <BBB> astrange: ah, who needs school :-p
[17:32:00] <peloverde> Says Dr. BBB, PhD
[17:33:02] <kshishkov> probably that's the reason
[17:33:32] <mru> look what good it did him
[17:33:43] <mru> he wasted away precious years he could've spent on coding
[17:34:01] <kshishkov> a totally useful degree he's going to use along with aquired knowledge
[17:34:16] <gnafu> mru: And who knows?  Maybe he wouldn't have had that kid if he didn't get a PhD!
[17:34:20] <gnafu> Think about it.
[17:34:46] <mru> http://xkcd.com/583/ ?
[17:35:06] * gnafu conceals his love for children by making fun of someone who has what he hopes to have in a few years...
[17:35:44] <gnafu> mru: Nice.
[17:39:12] <kshishkov> gnafu: quite possible - all that free time as a student...
[17:40:15] <lu_zero> theheh
[17:42:48] <gnafu> Speaking of babies, one of my coworkers is showing off his grandson (kids stopped in).
[17:43:16] <gnafu> kshishkov: Sure.  Late nights "studying," eh?  Eh?!
[17:43:40] <gnafu> Hittin' the "books"?
[17:43:45] * gnafu will stop now.
[17:44:48] <kshishkov> gnafu: in Ukraine students usually study only during or after the exam, so they fill the rest of time with something else
[17:46:03] <uau> mru: i think inserting spaces is required - as far as i can see the translation phases are defined in terms of preprocessing tokens (rather than having text output from the preprocessor), and nothing would merge the two '-' tokens into one '--' token
[17:47:05] <kshishkov> uau: it was common way in K&R times at least
[17:47:39] <uau> what was common? having a separate text preprocessor? maybe, but that doesn't affect the semantics
[17:48:05] <mru> it was common for preprocessors to do a literal textual replacement, nothing more
[17:48:12] <kshishkov> exactly
[17:48:17] <mru> they even expanded macro params inside string literals
[17:51:15] <kshishkov> reminds me of our C class - http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/fuer/f92.html
[17:53:59] <uau> kshishkov: that seems to demonstrate exactly the -- case - what does the comment 2.1 refer to?
[17:54:08] <Compn> KotH : i replied to your hijack mail
[17:54:53] * Compn doesnt want anyone going thinking they are ignored :p
[17:57:27] <kshishkov> uau: the fact preprocessor does exact replacement, from outer level to deeper one
[17:59:26] <mru> <@kshishkov> reminds me of our C class <-- C doesn't have classes, are you sure it wasn't c++?
[18:00:34] <kshishkov> mru: that thing is too hardcore for C++ IMO
[18:00:52] <kshishkov> mru: and we didn't have C++
[18:01:01] <mru> re the link, thank goodness russian borrowed computing words from english
[18:02:14] <kshishkov> indeed
[18:02:27] <kshishkov> that's how I understand computer German too
[18:03:50] <lu_zero> .fr made the whole thing more interesting
[18:04:02] <kshishkov> as expected from French
[18:07:16] <bilboed-pi> kshishkov, yuck, wtf is that code ?
[18:07:36] <mru> russian
[18:08:20] <bilboed-pi> no I meant who on earth teaches to program in such butt-ugly way ?
[18:08:22] <kshishkov> an excerpt from old C excercise book - guess the output from code
[18:09:19] <kshishkov> IIRC it's also from American author and was bundled with Russian K&R translation
[18:09:37] <bilboed-pi> I would just slap a Z as the mark for whoever hands that as the result to an excercise
[18:09:58] <kshishkov> you completely miss the point
[18:11:25] <lu_zero> kshishkov: language barrier I guess ^^
[18:11:50] <mru> if you call a fortran function from C, do you need a langauge barrier?
[18:12:02] <kshishkov> not on VMS
[18:13:09] <kshishkov> and what's wrong on studying not very correct code with unexpected output to demonstrate pitfalls?
[18:13:24] <mru> that's a good thing to do
[18:35:14] <KotH> Compn: thanks
[18:37:35] <Compn> oo reimar replied too
[18:37:36] <Compn> ehe
[18:57:42] <wbs> lu_zero: pong
[18:58:04] <wbs> lu_zero: could you rephrase what you tried to say about rtp interleaving, I didn't at all understand what you tried to say :-)
[18:59:16] <lu_zero> wbs: ff_rtsp_read_reply
[18:59:58] <lu_zero> it could drop useful rtp packets
[19:00:41] <wbs> if called with return_on_interleaved_data == 0 when a packet is pending to be read?
[19:01:29] <wbs> and yes, I can see that happening, not sure if I see it as a big issue, but if you could avoid it cleanly, you can give it a try :-)
[19:03:34] <lu_zero> the idea is to just queue up the packet
[19:03:44] <lu_zero> you already did most of the work =)
[19:04:03] <wbs> ah, indeed I did :-)
[19:05:45] <lu_zero> noticed today while messing with sctp support
[19:05:52] <Dark_Shikari> astrange: "I approved the patch"
[19:05:53] <Dark_Shikari> what patch?
[19:05:57] <Dark_Shikari> you didn't attach a patch to your email
[19:06:36] <astrange> takashi mochizuki's
[19:08:07] <lu_zero> it just need to enable it by default with a size of at least 3 I think
[19:12:56] <Dark_Shikari> astrange: it no longer applies
[19:14:45] <astrange> ah
[19:15:08] <astrange> because of ff1efc524cb3c60f2f746e3b4550bb1a86c65316
[19:15:17] <iive> mans committed his own fix, I think.
[19:15:17] <astrange> but that should also fix it
[19:15:21] <astrange> yes
[19:15:44] <Dark_Shikari> oh, nice.
[19:15:52] <iive> astrange: i think i said that on #x264 hours ago :P
[19:16:00] <mru> it seemed silly to set up the whole threading machinery with a single thread
[19:32:06] <lu_zero> look like the rentry_transfer_wrapper is bogus...
[19:35:45] <lu_zero> or maybe my sctp implementation...
[19:35:59] <lu_zero> I guess I'll need to reshape it more properly =P
[21:24:13] * Sean_McG makes himself a chai latte
[21:25:10] <kshishkov> Sean_McG: if it's not Trocadero it's not worth mentioning here
[21:25:38] <Sean_McG> it's not, it's just a Tassimo cartridge ;)
[21:27:32] <lu_zero> kshishkov: you should try the chinotto e gazzosa lurisia
[21:27:46] * lu_zero makes a mental note to bring a sample next time
[21:27:47] <kshishkov> lu_zero: tl;dr
[21:28:03] <lu_zero> =?
[21:28:13] <kshishkov> too long name
[21:28:27] <lu_zero> gazzosa?
[21:28:27] <Sean_McG> hahahaha
[21:28:32] <lu_zero> or chinotto?
[21:28:55] <kshishkov> three combined together
[21:29:06] <lu_zero> two different drinks
[21:29:11] <kshishkov> ah
[21:29:27] <lu_zero> lurisia being the producer
[21:29:36] <kshishkov> anyway, time to quote you and go to sleep
[21:29:39] <kshishkov> *yawn*
[21:29:44] * kshishkov goes to sleep
[21:30:00] <lu_zero> http://www.lurisia.it/index.php?method=section&id=3261
[21:30:09] <lu_zero> good night
[21:52:32] <Sean_McG> are those beers?
[22:03:21] <Sean_McG> how do I get gdb to break inside h264_mp4toannexb_filter?
[22:03:47] <Sean_McG> I'm guessing the symbol is missing because it's declared static
[22:07:22] <Tjoppen> are you runnig ffmpeg_g?
[22:07:27] <Sean_McG> yeah
[22:07:49] <Tjoppen> then my guess it has them as debug symbols anyway
[22:08:00] <Tjoppen> +is
[22:08:14] <Sean_McG> (gdb) list h264_mp4toannexb_filter
[22:08:15] <Sean_McG> Function "h264_mp4toannexb_filter" not defined.
[22:08:39] <Sean_McG> and yet I know it's being called because my error message is getting displayed
[22:08:56] <Sean_McG> I can list other functions
[22:09:03] <Tjoppen> un-staticize it then :p
[22:09:08] <Sean_McG> k
[22:10:05] <mru> static or not shouldn't matter
[22:11:36] <Sean_McG> yeah, it didn't... still no symbol
[22:12:59] <Yuvi> could always do 'break <file>:<line>'
[22:13:17] <Sean_McG> ah OK
[22:13:36] <Sean_McG> I'm not used to gdb -- too pampered by the GUI debuggers
[22:13:42] * Sean_McG *sheepish grin*
[22:15:34] <Tjoppen> *hampered
[22:16:10] <Sean_McG> I dunno, I really like the one in Xcode
[22:20:31] <Sean_McG> can I step into it from it's upstream caller somehow?
[22:31:20] <Sean_McG> what the....
[22:33:21] <Sean_McG> ahhh it's called through a function pointer... argh :|
[22:43:40] <Sean_McG> mru: should I be overly concerned about lines that cause the "cast discards qualifiers from pointer target", or just leave them be?
[22:49:39] <mru> Sean_McG: depends
[22:50:11] <Sean_McG> in this case it's discarding const
[22:50:30] <mru> some of those are unvoidable
[22:50:34] <mru> what are the types involved?
[22:50:38] <Sean_McG> that's... kinda what I figured
[22:51:51] <mru> for example, it's impossible to implement strstr() without such warnings
[22:53:28] <Sean_McG> a 'uint8_t **poutbuf' and a 'const uint8_t *buf' that's being cast just to '(uint8_t *)'
[22:53:40] <Sean_McG> in that same h264_mp4toannexb
[22:54:28] <mru> yeah, those are unfixable
[22:54:33] <Sean_McG> OK
[22:54:43] <Sean_McG> is there a way to disable the warning on just that line?
[22:55:08] <Sean_McG> (only to reduce warning noise)
[22:57:13] <mru> not that I know of
[22:57:19] <Sean_McG> OK
[23:25:30] <Sean_McG> hm, looks like it was OS X giving me grief... Solaris gladly lets me set a breakpoint