[FFmpeg-devel-irc] IRC log for 2011-01-23

[irc at mansr.com]

[00:00:26] <saintd3v> lu_zero and michael sitting in a tree...
[00:02:02] <mru> g i t t i n g
[00:04:07] <lu_zero> uhm?
[00:04:22] <lu_zero> something else happened?
[00:05:03] <jannau> lu_zero: michael replied to your mirror mail in a certain way
[00:05:12] <superdump> peloverde: ping?
[00:05:37] <peloverde> pong
[00:06:01] <lu_zero> how so?
[00:06:04] <superdump> i didn't respond to your SBR signalling patch because i didn't have some specs to hand at that point
[00:06:13] <superdump> which spec is AudioSpecificConfig in again?
[00:06:23] * lu_zero doesn't have emails
[00:06:31] <superdump> subpart 1 or something?
[00:06:33] <peloverde> 14496-3 subpart 1
[00:07:05] <lu_zero> ah
[00:07:21] <superdump> i swear i used to have a full 14496-3
[00:07:28] <lu_zero> should I be scared or just afraid?
[00:09:13] <siretart> seems launchpad does build something now: https://code.launchpad.net/~motumedia/+recipe/ffmpeg-daily (uses the bzr ffmpeg mirror)
[00:15:41] <Dark_Shikari> lu_zero: check your invites, superdump as well
[00:33:50] <mru> jannau: how about we point patches.ffmpeg.org at your patchwork server?
[00:49:33] <jannau> mru: in principle yes, need to configure it accorgingly but I want first to think if/how I set one up for videolan.org/michael
[00:50:05] <mru> I'd let michael worry about himself
[00:51:33] <jannau> I tend to think that we should try to work with a single instance, there just too much manual intervention necessary
[00:51:52] <mru> we can't have a shared tracker
[00:51:57] <mru> that just doesn't work
[00:52:08] <jannau> especially if the commit messages don't match
[00:52:22] <mru> especially if the _commits_ don't match
[00:52:55] <mru> or the patches, for that matter
[00:53:16] <lu_zero> ...
[00:56:49] <jannau> I forgot btw that lu_zero had proposed to run patchwork
[00:57:08] <mru> and michael called it "unacceptable"
[00:57:24] <mru> before blurting out a rant about "root"
[00:57:55] <lu_zero> I don't recall when and where
[00:58:04] <lu_zero> michael dug something
[00:58:12] <lu_zero> but it's just a mild no
[00:58:18] <lu_zero> not the usual "unacceptable"
[00:58:49] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44000
[00:59:39] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/43995
[01:01:05] <lu_zero> ok I'm surely more worn out that should
[01:01:43] <jannau> well, I tend to agree that undocumented/missing status changes per mail are inconvenient
[01:01:45] <mru> he's been going on like that ever since me/diego/attila started running the server
[01:02:02] <mru> remember that the old admin, arpi, allowed the server to melt down completely
[01:02:28] <mru> jannau: sure, but that's beside the point
[01:02:47] <mru> he didn't like it then, why should we spend any effort on setting it up for him now?
[01:07:07] <jannau> I've added a state Committed, was planning to use Accepted as reviewed and ok
[01:10:08] <jannau> I'll look into commands per email, I can't believe nobody implemented that during the last 3 years
[01:10:51] <mru> let me just say this, michael has repeatedly stated he doesn't want me as "root"
[01:11:06] <mru> from my point of view, his wish has come true
[01:11:30] <mru> I will not do anything whatsoever for him systemwise
[01:11:42] <mru> since that's exactly how he wants it
[01:13:33] <jannau> that's fine and you're free act as you wish and I'm too
[01:13:41] <mru> of course
[01:14:00] <mru> you have no quarrel with him - yet
[01:15:39] <jannau> commands per email is something I really want for our instance
[01:15:59] <mru> I'm not disputing the utility of email commands
[01:16:13] <mru> but lack thereof shouldn't be a total blocker for using an otherwise nice tool
[01:28:26] <Tjoppen> god afton
[01:34:56] <iive> mru: actually your reply read more you are refusing to install such system on the server because of the low quality of all available solutions.
[01:35:18] <mru> I never refused anything
[01:35:29] <mru> nobody ever asked for one before that thread
[01:37:20] <iive> "Why we don't have one" "Because there is no decent one".
[01:38:08] <iive> well
[01:38:14] <iive> n8 ppl.
[01:38:23] <{V}> g'dnight iive
[01:41:34] <BBB> mru: we should give siretart commit access for 0.6.2, or figure out some way for him to be able to do 0.6.2 without us committing for him
[01:41:46] <mru> I already gave him access
[01:51:13] <BBB> ah good
[02:19:39] <saintdev> superdump: what section is that in subpart-1?
[02:20:16] <superdump> AudioSpecificConfig
[02:21:27] <superdump> 1.6.2.1, table 1.15
[02:21:31] <superdump> in my copy
[02:21:42] <superdump> the syncExtensionType
[02:22:47] <superdump> there's a special case for syncExtensionType == 0x2b7
[02:22:47] <saintdev> ok, found it.
[02:23:12] <superdump> does it say 0x2b7 there too?
[02:23:36] <saintdev> yeah, and i have the same copy as alex, so it was a typo
[02:24:58] <superdump> me too actually :)
[02:25:13] <saintdev> oh, lol
[02:25:29] <superdump> well, in any case, the document should be correct so it's still a typo
[02:26:11] <saintdev> well it _could_ be a final draft/release spec change
[02:26:49] <superdump> unless i'm mistaken, it doesn't look like they touched that bit
[02:27:06] <saintdev> about 99% more likely it was just a typo, though
[02:27:34] * superdump nods
[02:27:42] <superdump> we all know peloverde has newb typing fingers
[02:27:52] <peloverde> superdump: is correct
[02:28:00] <superdump> :)
[02:28:01] <peloverde> i will fix it tonight/tomorrow if no one beats me
[02:28:02] <Dark_Shikari> BBB: crap, accidentally spammed you
[02:28:05] <Dark_Shikari> gmail apparently copies 1000 lines when I select 5
[02:28:07] <Dark_Shikari> tell me when the spam is over :>
[02:28:19] <saintdev> spaam: get out of BBB's inbox
[02:28:37] <superdump> i have some gmail labs extension set up to only use the bit i highlighted methinks
[02:28:38] <saintdev> oh, erm his PM
[02:29:04] <mru> whatever version of the doc I have, it says 0x2b7
[02:29:30] <superdump> good job i checked :B
[02:30:05] <mru> mine is N7129
[02:30:20] <mru> I think I gave it to some of you guys in the past
[02:31:09] <superdump> we have n9500
[02:31:16] <mru> that's not fair
[02:31:24] <saintdev> ner ner
[02:31:35] * superdump dances
[02:32:44] <superdump> mru: now you do too
[02:33:20] <saintdev> aww
[02:34:04] <mru> ta
[04:23:02] <peloverde> Does this timeline seem correct: http://pastebin.com/9pTDeQp5
[04:23:32] <mru> that's ancient history
[04:23:39] <mru> how do you expect us to remember?
[04:23:44] <mru> better ask mike melanson
[04:27:12] <Compn> peloverde : why mention vp3 but not theora ? didnt the spec come first ? or am i thinking theora spec first?
[04:27:27] <mru> theora is vp3
[04:27:51] <mru> or some hacked-up version of it
[04:27:57] <Compn> hacked-up version yes
[04:28:40] <mru> peloverde: some entires aren't in order
[04:29:39] <Compn> oh theora is listed, doh
[04:29:42] * Compn blind
[04:42:30] <peloverde> I feel very frustrated when I see all kinds of nonsense from idiots gaining a ton of mindshare
[04:43:03] <mru> understandable
[04:43:29] <peloverde> like "Is there any significance to the fact that Google chose IETF instead of ISO (where MPEG-LA and M$ submitted H.264 and OOXML)?"
[04:43:50] <mru> there is, actually
[04:43:58] <ohsix> if it's vague enough then people show up to fill th eseats
[04:44:02] <mru> the process is much more rigorous with ISO
[04:44:13] <peloverde> H.264 wasn't submitted by MPEG-LA to ISO
[04:44:17] <mru> ISO/IEC in this case
[04:44:36] <mru> h264 was developed by iso, iec, and itu
[04:44:52] <mru> well, by their members
[04:45:12] <mru> but why do you read that crap anyway?
[04:45:25] <mru> idiots will never go away
[04:46:03] <peloverde> h.264 was developed by researchers from a variety of organizations, MPEG-LA went and licensed patents after the fact
[04:46:07] * Compn wonders what site's comments are getting peloverde riled up
[04:46:13] <peloverde> slashdot
[04:47:01] <mru> mpeg-la is a patent pool set up by the majority of the rights holders of patents related to the mpeg family of codecs
[04:47:13] <Compn> theora google-hating commentors ? seems like a stereotype
[04:47:26] <mru> the _only_ thing mpeg-la does is sell licenses and distribute the royalties
[04:47:34] <peloverde> mpeg-la is an independent company that tries to organize patent pools for a variety of standards
[04:47:50] <mru> aren't they owned by the patent holders?
[04:48:04] <mru> or at least originally founded by
[04:48:33] <mru> they exist as a consequence of the patent system, not the other way around
[04:48:59] <peloverde> they exist as a consequence of the patent system but as far as i know they are independent
[04:49:03] <Compn> independent company ? what ?
[04:49:13] <Compn> they are independent from sony ?
[04:49:20] <Compn> maybe i dont know your definition of independent
[04:49:21] <mru> and given the patent situation, mpeg-la is a _good_ thing
[04:49:52] <peloverde> mru: agreed
[04:50:07] <peloverde> Compn: they are not owned by sony, they negotiated a deal to sub-license sony patents along with patents owned by others
[04:51:18] <peloverde> but the whole situation is presented backwards in the blogosphere
[04:51:35] <mru> the bogosphere
[04:51:45] <peloverde> MPEG-LA is an evil company who developed H.264 in secret with Apple, patented it and forced it through ISO
[04:52:24] <peloverde> Yes but idiots like Mozilla pushed on Google until they dropped H.264 support
[04:53:51] <peloverde> As Chris Blizzard said as FOSDEM, he knows what the best codec for the web is and doesn't need any technical knowledge to make that decision
[04:54:24] <peloverde> And his mp4 that was 90% hint track was proof of his technical illiteracy on this issue
[04:55:13] <saintdev> peloverde: everybody know's that it's SVQ1
[04:55:48] <mru> the slowest encoder in ffmpeg
[05:25:41] <kshishkov> mru: I know it's icorrect to compare audio and video decoders speed but I think my AAC encoder once was even slower
[05:26:04] <kshishkov> mru: also we may write Monkey Audio encoder one day
[05:47:24] <Flameeyes> mru, peloverde: the results are on the ML for you to cry at :)
[05:49:09] <saintdev> kshishkov: your trellis is a beast
[05:50:27] <saintdev> oh no, ffmpeg is using private symbols!
[05:51:30] <kshishkov> saintdev: iKnow
[05:51:55] <Flameeyes> saintdev: or some symbols that should be public aren't prefixed with av_ :)
[05:51:59] <kshishkov> still, it's funny how APE decoding took more CPU than H.264 SD
[05:52:10] <Flameeyes> afaict at least the url_* set is a false positive, not sure about dump_format
[05:53:03] <Flameeyes> if I do exclude those two, the list of packages is six packages shorter
[05:53:14] <kshishkov> saintdev: IIRC I started with something simpler, faster and quite as effective
[05:53:46] <saintdev> then michael kept telling you 'viterbi' ?
[05:54:11] <kshishkov> you said that
[05:54:20] <saintdev> huh?
[05:54:31] <ohsix> viterbi 4 lyf
[05:54:55] <ohsix> i never quite got why everyone calls it trellis in here
[05:55:18] <kshishkov> because of certain Austrian
[05:55:40] <ohsix> no time better than the present to elaborate :]
[05:55:46] <kshishkov> and because it's most known use of it
[05:56:17] <ohsix> which austrian?
[05:56:27] <kshishkov> the one who blogged about it
[05:57:19] <ohsix> url?
[05:57:54] <saintdev> kshishkov: i seem to remember something like michael kept wanting you to trellis more and more stuff.
[05:58:06] <Dark_Shikari> ohsix: "trellis quantization"
[05:58:13] <Dark_Shikari> so everyone calls viterbi stuff in video "trellis"
[05:58:16] <Dark_Shikari> as a result.
[05:58:25] <ohsix> okie dokie
[05:58:27] <saintdev> or maybe i'm just imagining things. i wasn't part of the mailing list when all that was going down
[05:59:13] <kshishkov> saintdev: it was more like "make encoder optimal first"
[05:59:35] <kshishkov> saintdev: no matter it would be as fast as H.265
[06:01:20] <ohsix> what's the austrians name anyways i'm not up to speed
[06:02:00] <kshishkov> ohsix: Michael
[06:02:05] <saintdev> kshishkov: but the h.265 reference software is faster than JM!
[06:02:23] <kshishkov> Dark_Shikari: ^^^
[06:02:25] <saintdev> one small caveat: it's more optimized than JM =P
[06:02:25] <ohsix> k
[06:03:01] <saintdev> kshishkov: so of course, they can now claim h.265 is faster than h.264!
[06:03:58] <kshishkov> saintdev: http://x264dev.multimedia.cx/archives/360
[06:05:22] <saintdev> kshishkov: i know, that was one of the proposals. they just cherry-pick ideas from the proposals to use in the final spec
[06:06:21] <kshishkov> well, I expect them to pick only the slowest things
[06:08:21] <saintdev> <Dark_Shikari>  Alex_W: their numbers are still hilarious though
[06:08:21] <saintdev> <Dark_Shikari>  they're claiming the low complexity version is less complex than h264
[06:08:21] <saintdev> <Dark_Shikari>  because they've optimized it better than JM
[06:08:24] <saintdev> kshishkov: ^
[06:09:45] <kshishkov> well, "better than JM" means that they've implemented not in the most pessimal way
[06:13:23] <kshishkov> once I had to optimise reference G.722 codec in at least two times
[06:13:58] <kshishkov> by simply inlining functions and dropping few saturation checks I've made it four times faster
[07:26:42] <siretart> did anyone try to build a shared libswscale.so on x86_64 lately?
[07:26:51] <siretart> I get this: /usr/bin/ld: libswscale/rgb2rgb.o: relocation R_X86_64_PC32 against symbol `ff_bgr2YCoeff' can not be used when making a shared object; recompile with -fPIC
[07:37:57] <drv> siretart: seems to work ok here
[07:44:06] <siretart> hm. what did I do wrong then here? http://launchpadlibrarian.net/62653248/buildlog_ubuntu-natty-amd64.ffmpeg_0.7~~27341%2B201101230026~natty1_FAILEDTOBUILD.txt.gz
[07:45:33] <drv> maybe different binutils or gcc version?
[07:45:52] <ohsix> also gold is in play
[07:47:29] <Dark_Shikari> Flameeyes: ping
[07:47:36] <Dark_Shikari> how do we know which private symbols are being used?
[07:51:13] <Dark_Shikari> Flameeyes:
[07:51:13] <Dark_Shikari> 18:50 < j^> its about avformat.h:void dump_format
[07:51:13] <Dark_Shikari> 18:51 < j^> if thats not public, remove it from avformat.h
[07:52:35] <elenril> more like add an av_ prefix
[07:55:50] <wooster> i'm trying to port ffmpeg to perl
[07:55:57] <wooster> i'm transcoding from mpeg4 to mpeg4 to test
[07:56:00] <wooster> i get these errors http://pastebin.com/LK5wtJFw
[07:56:07] <wooster> anyone know what might be causing them?
[07:56:17] <wooster> i get video output that looks vaugly correct
[07:56:28] <wooster> but its pretty messed up
[07:56:52] <_av500_> port to perl?
[07:56:58] <wooster> yea
[07:57:12] <_av500_> you rewrote all the c code in perl?
[07:57:12] <thresh_> morning
[07:57:22] <wooster> not all of it yet, but yea kinda
[07:57:33] <kierank> erm
[07:57:37] <wooster> https://github.com/revmischa/Video-FFmpeg-Streamer
[07:57:44] <elenril> well wow, that sound lilke a totally cool and not at all braindead idea
[07:57:53] <wooster> i am wrapping the features of ffmpeg in XS
[07:57:54] <thresh_> ;)
[07:58:09] <kshishkov> elenril: my sarcasm detector melted
[07:58:21] <wooster> it IS totally cool don't hate
[07:59:04] <wooster> anyway does anyone know what those errors might be about?
[07:59:09] <elenril> kshishkov: your sarcasm detector wasn't cool enough
[07:59:52] <drv> probably using symbols in libavformat which are now in libavcodec
[08:00:03] <drv> (there is a compatibility wrapper in lavf now to call the new location)
[08:00:40] <wooster> ok, any idea what those might be? and is the "recompile" suggestion misleading?
[08:01:50] <_av500_> it misleads you into having higher performance
[08:02:09] <drv> those shouldn't cause any problems anyway, just extra noise in the log
[08:02:18] <wooster> i mean recompiling won't help me, the problem is with the code
[08:02:33] <wooster> i'm more concerned about the mpeg errors
[08:02:44] <wooster> i have no idea where to even start to look for the cause of that
[08:03:24] <_av500_> well, compare to what your perl does to some known good usage of ffmpeg
[08:03:32] <_av500_> -to
[08:03:42] <drv> as a first tack, grep for the error message and work backwards from there...
[08:04:54] <wooster> ffmpeg does it totally fine
[08:05:06] <_av500_> so compare the call sequence
[08:05:10] <_av500_> and params used
[08:05:31] <wooster> tryin'
[08:06:16] <wooster> just wondering if anyone knew of a probable cause
[08:35:41] <elenril> hey Yuvi
[08:36:59] <thresh> good morning
[08:37:53] <Yuvi> hi elenril
[08:43:02] <elenril> did you hear the news?
[08:43:25] <elenril> also is there some specs or at least samples for mov chapters?
[08:43:40] <Yuvi> news?
[08:43:50] <Yuvi> if it isn't in qtff.pdf, probably not
[08:44:03] <Yuvi> samples sure
[08:44:11] <elenril> revolution etc
[08:44:51] <Yuvi> Tunisia?
[08:45:02] <elenril> ffmpeg
[08:45:12] <elenril> there was a coup d'etat
[08:45:14] <kshishkov> elenril: wo cares?
[08:45:18] <Yuvi> hm, haven't been following the ML
[08:45:19] <elenril> the news sites were full of it
[08:48:10] <kshishkov> elenril: cnn.com? bbc.co.uk? lidovenovyny.cz?
[08:48:35] <kierank> theonion.com
[08:59:36] <Yuvi> elenril: http://www.mediafire.com/?3x5p0krks52ebao is what I like to use as an example for mov chapters+subtitles
[09:01:15] <elenril> great, thanks
[09:01:22] <Yuvi> err, closed captions actually
[09:03:08] <Yuvi> though you can do pretty funky things with chapters since they're considered a regular track; that's just the most typical way they're stored I think
[09:03:52] <elenril> i'm not going to do anything fancy with them, i was just planning to do some cleanup on your code
[09:04:24] <elenril> i.e. i want to unify all the variants of 'read utf-16 string&convert to utf-8' throughout lavf
[09:04:44] <Yuvi> sounds good
[09:05:00] <Yuvi> the file I posted might use macroman (i forget) but iirc the code ignores that
[09:10:03] <lu_zero> siretart: you should have -fPIC
[09:11:47] <siretart> lu_zero: shouldn't configure figure that out by itself? - it used to work like that in the past
[09:11:58] <siretart> btw, what's the correct clone url for people having push access?
[09:14:16] <lu_zero> git at git.ffmpeg.org:ffmpeg
[09:14:21] <lu_zero> port 2222
[09:14:26] <siretart> ah, ok. thanks!
[09:14:40] <lu_zero> siretart: it should
[09:15:23] <lu_zero> let me see
[09:15:52] <siretart> I've changed the packaging to include V=1
[09:15:59] <siretart> perhaps that gives more insight
[09:15:59] <lu_zero> CONFIG_PIC=yes
[09:16:33] <lu_zero> and the *FLAGS got PIC as well
[09:17:31] <CIA-29> ffmpeg: Reinhard Tartler <siretart at tauware.de> master * r305ca590cf ffmpeg/ffserver.c:
[09:17:31] <CIA-29> ffmpeg: ffserver: cleanup
[09:17:31] <CIA-29> ffmpeg: remove the trivial function do_switch_stream as it doesn't help to make
[09:17:31] <CIA-29> ffmpeg: the code easier to understand.
[09:18:27] <siretart> okay, let's see if this daily sync/building via bzr to launchpad ppa machinery actually works :-)
[09:21:34] <cartman> http://cekirdek.pardus.org.tr/~ismail/3.png screw UV =P
[09:40:41] <_av500_> cartman: i liked the one on drugs better
[09:41:22] <cartman> _av500_: heheh
[09:41:41] <cartman> _av500_: trying to parse 2x2 pixels correctly
[09:41:54] * cartman blames the wikipedia algo.
[09:43:21] <cartman> it says; u = yuv[(position.y / 2)* (size.width / 2) + (position.x / 2) + size.total];
[09:43:27] <cartman> but there is a note
[09:43:30] <cartman> Here "/" is Div not division.
[09:43:35] <cartman> wtf is Div not a division.
[09:44:04] <_av500_> maybe / is a "half comment"
[09:44:09] <elenril> divergence?
[09:44:15] <_av500_>  // / 2
[09:44:26] <cartman> _av500_: agreed
[09:44:26] <cartman> elenril: wut?
[09:44:48] <_av500_> its a diversion
[09:45:01] <_av500_> or a divination
[09:45:04] <cartman> uhm never heard of it
[09:46:09] <_av500_> cartman: wtf is that formula anyway?
[09:46:22] <cartman> _av500_: traversing a YUV420 frame
[09:46:30] <_av500_> packed or planar?
[09:46:33] <cartman> Planar
[09:46:43] <_av500_> ah
[09:46:53] <_av500_> but you dont do it like that anyway
[09:46:58] <cartman> doesn't work correctly for U/V as expected
[09:47:03] <_av500_> you setup a Y and U and V pointers
[09:47:04] <wbs> cartman: I think it means integer division (in contrast to real division)
[09:47:20] <_av500_> and you increment the pointers
[09:47:22] <cartman> wbs: ah my code already does that but not working :/
[09:47:48] <cartman> _av500_: since a 2x2 square has the same U/V values how do you handle that case?
[09:49:35] <cartman> _av500_: first you setup Y/U/V pointers and then you create Y,U,V tuples?
[09:49:44] <_av500_> cartman: er
[09:49:55] <_av500_> you convert 2 lines at a time
[09:50:06] <cartman> that makes sense :D
[09:50:10] <cartman> lol
[09:50:10] <_av500_> so you have Y1 and Y2 pointers
[09:50:16] <_av500_> and 2 RGB pointers
[09:50:48] <_av500_> and you use U and V for both lines
[09:50:50] <cartman> Y1,U1,V1 and Y2,U1,V1 and such...
[09:51:01] <_av500_> yep
[09:51:07] <cartman> thanks!
[09:51:24] <_av500_> if you want it extra super, you take care about the positions of U and V
[09:51:42] <_av500_> but you need to only for h264 vs theora banchmarks
[09:51:47] <cartman> lol :>
[09:52:18] <cartman> ok time to take care of the $WIFE[0], see you!;P
[09:52:46] <_av500_> i see he made it an array, just in case...
[10:31:44] <pross-au> q: i have a 1MiB sample file for inclusion in fate test suite, where do i upload to, who do i need to tell?
[10:35:23] <DonDiego> pross-au: mru handles fate
[10:36:00] <pross-au> k
[10:44:26] <siretart> drv: when testing the shared libswscale.so, did you --enable-gpl?
[10:49:59] <siretart> hm. doesn't make no difference here, linking just fails
[11:04:08] <elenril> http://pastebin.com/ndeczvuj << how evil is this?
[11:17:56] <Flameeyes> siretart: have you seen my latest mail on -devel by chance
[11:17:56] <Flameeyes> ?
[11:23:39] <royger> Is there any value in MpegEncContext to know if MPV_decode_mb has been called from encode_thread or from mpeg_decode_slice? And if possible could someone explain to me why is the decoding done twice?
[11:24:18] <Dark_Shikari> the encoder has to decode what it encodes
[11:24:22] <Dark_Shikari> in order to know what the frame will look like
[11:24:24] <Dark_Shikari> to use it as a reference
[11:24:51] <j-b> duh, url_* are not public?
[11:25:19] <royger> Dark_Shikari: but that will mean calling MPV_decode_mb one time only?
[11:25:44] <Dark_Shikari> mpeg_decode_slice sounds like you're decoding an input.
[11:25:46] <Dark_Shikari> and then encoding it
[11:26:59] <royger> Dark_Shikari: yes, I need to recompress a mpeg2 video modifying the DCT coefficients
[11:27:18] <Dark_Shikari> So naturally you call decode twice.
[11:27:23] <Dark_Shikari> To decode the input, and then to decode the encoded output.
[11:27:51] <royger> Dark_Shikari: I'm modifying the coefficients in MPV_decode_mb_internal, but I only want to do it one time, so I need to know when to do it
[11:28:37] <Dark_Shikari> you could try not doing it there
[11:28:52] <Dark_Shikari> what is with the horde of people trying to implement such a stupid feature?
[11:28:55] <Dark_Shikari> is there some class or something?
[11:29:02] <royger> Dark_Shikari: where do you recommend me to do it
[11:29:41] <royger> Dark_Shikari: I'm working at the university and they made me work on a previous project, that osmeone started as a modification of ffmpeg to add watermarking to mpeg2 videos
[11:29:54] <royger> Dark_Shikari: but the current implementation is a mess, and I'm trying to fix it
[11:30:16] <elenril> specifically to mpeg2? wtf
[11:30:38] <royger> Dark_Shikari: they modified the DCT coefficients in MPV_decode_mb_internal, but if there's a better place to do it please tell me
[11:31:24] <royger> elenril: yes, adding a fingerprinting code to the luminance blocks of I-frames, I thinks it's called a COX algorithm
[11:32:55] <pross-au> elenril: re the get_utf16le function, can u make maxlen be optional?
[11:33:20] <elenril> pross-au: it already is
[11:33:37] <elenril> i.e. it stop either on first null OR on reaching maxlen
[11:33:41] <elenril> *stops
[11:34:06] <elenril> so you just pass maxlen=INT_MAX or something
[11:34:46] <pross-au> ok
[11:37:51] <siretart> Flameeyes: I did 'tick' it :-)
[11:37:56] <royger> so any clues on where should I modify the DCT coefficients instead of MPV_decove_mb_internal?
[11:38:54] * elenril spams some patches
[11:40:09] <spaam> elenril: spam? nice. any good stuff this time? 90% off?
[11:40:32] <Flameeyes> siretart: mostly was curious if you knew why some of the symbols are not versioned
[11:46:52] * Flameeyes is implementing more grep(1)-like features on elfgrep
[11:51:48] <siretart> Flameeyes: which one aren't?
[11:52:00] <Flameeyes> siretart: see my latest mail ;)
[11:58:29] <siretart> Flameeyes: I still don't get which are versioned and which not
[11:58:33] <siretart> anyway, food time, bbl
[11:58:52] <Flameeyes> siretart: uhm my last mail has a bunch of symbols ending with @ -> those are not versioned
[12:00:16] <Flameeyes> uhm food time indeed
[12:26:55] <cartman> Ehlo
[12:27:21] <Flameeyes> hey cartman
[12:27:48] <cartman> Lo Flameeyes
[12:28:01] <spaam> cartman: time for $WIFE[1] ? :)
[12:28:33] <cartman> spaam thats my Nexus1 ;p
[12:29:00] <spaam> i thught that was $WIFE[0]
[12:29:53] <cartman> Nah
[12:32:20] <cartman> Flameeyes which side you are from ? :D
[12:32:31] <mru> the dark side
[12:32:34] <Flameeyes> Pasta!!!
[12:32:41] <cartman> Lol
[12:32:42] <Flameeyes> </hetalia>
[12:32:52] <mru> pastafarianism?
[12:33:54] <cartman> av500 btw read my CV yet? ;p
[12:34:27] <spaam> cartman: you want to work for av500 ?
[12:34:54] <cartman> spaam we all work for the evillord
[12:35:58] * mru doesn't have a cv, he has a reputation
[12:36:41] <cartman> mru av500 insisted for something written
[12:36:52] <mru> cartman: that's because you don't have a reputation
[12:37:02] <mru> other than for being a turk
[12:37:06] <spaam> cartman: i didnt have do make a cv for the job i have now ;D
[12:37:23] <cartman> mru not in AV world
[12:37:29] <mru> spaam: no, that's not required for sewage pipe cleaners
[12:37:59] <spaam> mru: pff. i dont have that kind of work.
[12:38:14] * cartman has reputation with his b/w images now
[12:39:43] <cartman> mru where is yuv2rgb neon btw?
[12:39:54] <mru> in my secret stash
[12:40:04] <Dark_Shikari> It's next to his weed.
[12:40:11] <cartman> mru sharing is caring
[12:40:29] <mru> and stashing is hashing
[12:40:37] <cartman> Right
[12:40:59] <spaam> cartman: what did you share with mru? :)
[12:41:00] <mru> I can give you the md5sum of it
[12:41:28] * Flameeyes prods mru in saying something about the unversioned symbols he saw
[12:41:53] <cartman> spaam my weed and neon lights
[12:42:27] <spaam> nice
[12:42:56] <Flameeyes> cartman: I thought for hydroponics(sp?) one has to use halogen?
[12:43:05] * cartman hash Turkish delight stack
[12:43:53] <cartman> Flameeyes weed does wonders
[12:44:27] <Flameeyes> stack? you smoke the freshest first?
[12:44:58] <cartman> Flameeyes you ever eat Turkish delights?
[12:45:26] <Flameeyes> no idea what you're referring to tbh
[12:46:10] <cartman> Flameeyes kindly noted. Will fix that sometime ;)
[12:48:35] <cartman> Nexus1 keyboard killing me
[12:49:23] <mru> Flameeyes: sodium lamps
[12:49:53] <Flameeyes> right so no neon :P
[12:54:26] <elenril>  crazy time (100ns since 1 Jan 0001) << lol
[12:54:33] <Flameeyes> uhm I think I exaggerated on the garlic in this imitation of Nando's peri-peri :(
[13:13:36] <siretart> urmpf? I managed to reproduce it, now it just works. I'm seriously confused now.
[13:14:09] <mru> blame phase of the moon
[13:19:02] <siretart> The Moon is Waning Gibbous (82% of Full)
[13:20:01] <ohsix> Today is Pungenday, the 23rd day of Chaos in the YOLD 3177
[14:06:08] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r2b39962eb6 ffmpeg/Makefile:
[14:06:08] <CIA-29> ffmpeg: Makefile: simplify test tools handling
[14:06:08] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:08:39] <mru> DonDiego: any opinions on the other getbits patches?
[14:14:34] <BBB> I'm looking at the libmpeg2 one
[14:14:38] <BBB> why is it there in the first place?
[14:14:52] <mru> nobody knows
[14:15:03] <BBB> and what's the A32_BITSTREAM_READER?
[14:15:37] <lu_zero> yawn
[14:15:39] <mru> it's allegedly faster on some machines without unaligned memory access
[14:15:40] * lu_zero wakes up
[14:16:22] <BBB> I see
[14:16:40] <BBB> and normally we use ALT_?
[14:16:54] <mru> yes
[14:17:05] <BBB> so libmpeg2 is just cruft and probably doesn't even work?
[14:17:16] <mru> it doesn't work
[14:17:18] <lu_zero> possibly
[14:17:21] <mru> I tested it yesterday
[14:17:28] <mru> fails on numerous tests
[14:17:33] <mru> as stated in the comment
[14:17:49] <BBB> mpeg, h264
[14:17:50] <BBB> yeah
[14:17:54] <BBB> important enough to me
[14:18:14] <BBB> ok, ack then
[14:18:18] <BBB> (just emailed)
[14:18:20] <mru> and at least the h264 ones are nontrivial to fix
[14:18:37] <mru> svq1 and a few other obscure ones are easily fixed
[14:18:48] <mru> but what's the point when important codecs remain
[14:19:20] <BBB> license issue also
[14:19:23] <BBB> gpl vs lgpl
[14:19:25] <BBB> just remove it
[14:19:36] <BBB> is libmpeg2 significantly faster?
[14:19:57] <mru> the code doesn't come from libmpeg2
[14:20:02] <mru> it's just using the same strategy
[14:20:14] <mru> loading 16 bits at a time from the buffer
[14:20:34] <mru> but loading 32 bits is just as fast
[14:20:36] <mru> and lasts longer
[14:20:47] <BBB> so it's slower
[14:20:55] <BBB> ok, then DEFINITELY remove it :-p
[14:21:01] <mru> it's not quite that clear-cut
[14:21:27] <mru> I did some benchmarks a few years ago, and they were all very close
[14:21:31] <lu_zero> uh?
[14:21:44] <BBB> hi lu_zero
[14:21:51] <BBB> headache better now?
[14:22:01] <lu_zero> BBB: fever almost gone \o/
[14:22:40] <BBB> good :)
[14:23:16] <lu_zero> the sample I took wasn't good
[14:23:35] <lu_zero> j-b: how to make vlc reply to requests by sending an I frame first?
[14:23:43] <BBB> h264 bug?
[14:23:44] <BBB> ugh
[14:23:52] <BBB> or well mpegts bug I hope :-p
[14:24:06] <lu_zero> BBB: vlc misconfiguration/bug first
[14:24:28] <lu_zero> mpegts could be improved to cope with that probably
[14:25:08] <j-b> lu_zero: rtsp?
[14:27:07] <lu_zero> http
[14:27:18] <j-b> http/ts streaming from vlc?
[14:27:22] <lu_zero> yes
[14:27:41] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r938f72e199 ffmpeg/libavcodec/get_bits.h: (log message trimmed)
[14:27:41] <CIA-29> ffmpeg: Remove "libmpeg2" bitstream reader
[14:27:41] <CIA-29> ffmpeg: Using the libmpeg2 reader causes errors in a multitude of places,
[14:27:41] <CIA-29> ffmpeg: including MPEG and H264 codecs. As the advantage of this reader
[14:27:41] <CIA-29> ffmpeg: is questionable, removing it seems the sensible course of action,
[14:27:42] <CIA-29> ffmpeg: especially considering the simplifications this allows elsewhere
[14:27:43] <CIA-29> ffmpeg: with the bit cache size increasing from 17 to 25 bits as minimum.
[14:28:57] <mru> btw, note the pretty right margin in the commit message
[14:29:07] <mru> I suggest we make that mandatory :)
[14:29:33] <ruggles> what is the advantage of using do{ }while(0) around a macro instead of just { } ?
[14:29:46] <mru> if (foo) macro(); else stuff;
[14:30:20] <ruggles> just putting braces would work too in that case
[14:30:23] <mru> no
[14:30:30] <mru> it would give a dangling else
[14:30:34] <ruggles> oh, yeah it would screw some stuff up
[14:31:01] <Vitor1001> Stupid git questions (not covered in doc/git.txt):
[14:31:13] <ruggles> i like to avoid using ; after macros
[14:31:19] <mru> that's stupid
[14:31:20] <Vitor1001> How do I revert my local (uncommitted) modification done in files?
[14:31:56] <mru> Vitor1001: "git checkout $file" for a single file or "git reset --hard HEAD" to discard all uncommitted changes
[14:32:13] <ubitux> ruggles: it breaks the indent of the editor if you do that
[14:32:23] <ubitux> i mean, if it's code
[14:32:45] <mru> not only that, it forces you to remember exactly which names are macros and which are functions
[14:32:47] <Vitor1001> mru: Nice, thanks. Also, is ti normal that "git diff" does not show new files?
[14:32:54] <mru> yes
[14:32:58] <mru> try git status
[14:33:02] <mru> that will list untracked files
[14:33:06] <j-b> lu_zero: no idea, then
[14:37:23] <Vitor1001> mru: works fine, thanks
[14:43:38] <Vitor1001> mru: If I just reply to an old thread with a file generated by git format-patch, will patchwork catch it up?
[14:43:56] <mru> sometimes
[14:44:17] <mru> wait, I see what you mean
[14:44:19] <mru> probably not
[14:44:25] <mru> but don't worry about that
[14:44:37] <Vitor1001> ?
[14:44:52] <mru> if you reply to a patch not in patchwork, it will probably be ignored
[14:45:24] <mru> but all new patches are picked up, so let's just deal with old ones like we always have done
[14:45:28] <Vitor1001> If the very reason I'm replying to a old patch is to make it being caught by patchwork, this is a big problem
[14:45:43] <Vitor1001> s/old pathc/old thread/
[14:45:53] <mru> just resend the patch then
[14:45:59] <Vitor1001> Ok
[14:46:24] <Vitor1001> And patchwork will take what as the short description?
[14:46:35] <Vitor1001> The subject of my email, or the one in the diff?
[14:46:47] <mru> why are they different?
[14:47:16] <Vitor1001> I'd like to use "Old patches thread for patchwork" as subject
[14:47:19] <Vitor1001> or something like that
[14:47:46] <Vitor1001> So only people interested in old patches will look at it
[14:48:08] <jannau> Vitor1001: patchwork should catch all new emails with patches
[14:48:22] <jannau> unless it has problems parsing it
[14:48:38] <Vitor1001> jannau: Nice, because just replying to the old, original thread, makes much more sense
[14:49:02] <Vitor1001> jannau: How fast does patchwork refreshes?
[14:49:16] <mru> realtime more or less
[14:49:21] <jannau> as soon as the mail get's there
[14:49:26] <Vitor1001> So I'll just try it.
[14:50:29] <Vitor1001> Nice, it works!
[14:57:02] <jannau> hmm, it just added my 'Acked-by:'
[14:57:56] <elenril> can patchwork.ffmpeg.org link to it?
[14:59:36] <tjoener> hello
[14:59:46] <tjoener> I think I found a bug in the ffmpeg h264 decoder
[15:00:06] <jannau> elenril: it will become patches.ffmpeg.org
[15:00:35] <elenril> great
[15:01:07] <tjoener> I've got a scene that gives a small artifact which does not show in DXVA
[15:02:54] <iive> tjoener: do you know what is the encoder that created this sample?
[15:04:13] <tjoener> no I do not
[15:04:17] <tjoener> it's from a bluray
[15:04:57] <tjoener> I'm trying to extract the frame that causes the issue
[15:04:58] <jannau> tjoener: it plays fine with software decoder?
[15:05:02] <tjoener> I think it's an IDR
[15:05:13] <tjoener> no it plays fine with the hardware decoder in my gpu
[15:05:30] <tjoener> the software decoder (mplayer ==> so ffmpeg) gives the artifact
[15:05:38] <tjoener> its the only one ive come across
[15:06:02] <tjoener> so maybe its a fault in the bitstream, but i was thinking maybe someone could look at it
[15:06:26] <jannau> tjoener: sorry, I can't read
[15:06:58] <tjoener> np
[15:07:07] <tjoener> H264Visa doesnt show it either
[15:07:14] <tjoener> so I guess it really has to be ffmpeg
[15:07:16] <tjoener> sorry :(
[15:08:32] <jannau> tjoener: do you know the file offset of that frame? you can probably just cut it out with 10M before and after
[15:08:43] <tjoener> yeah, been trying to find out :)
[15:08:47] <tjoener> its an intra
[15:08:51] <tjoener> or an IDR
[15:08:56] <tjoener> always get those confused
[15:09:01] <kierank> do a bisect
[15:09:09] <kierank> probably the intra asm functions
[15:10:22] <BBB> tjoener: cut out the frame and send it to roundup, I'll look at it
[15:10:40] <BBB> tjoener: also, which software do you use to play (ffplay? vlc?) what commandline and which version?
[15:10:44] <BBB> (which date)
[15:11:29] <tjoener> crap, its not an IDR
[15:11:35] <tjoener> need the others too
[15:13:26] <tjoener> so from frame 1 to 49 everything is ok, on frame 50, an I frame, it shows the little error
[15:13:42] <tjoener> dont know how legal it is to send 50 frames of a BR over the internet
[15:14:49] <kierank> it is fine
[15:16:22] <tjoener> its 5MB
[15:16:27] <tjoener> dropbox is ok?
[15:25:48] <jannau> ftp://upload.mplayer.hu would be preferred
[15:26:15] <jannau> see http://ffmpeg.org/bugreports.html
[15:28:58] <BBB> tjoener: and then ping me once it's uploaded and you've put a description on roundup
[15:31:47] <BBB> elenril: why the get_str16be()? are you going to use that?
[15:32:43] <BBB> elenril: and for asfdec 2/4, have you tested that code by artificially failing at those codepoints?
[15:33:04] <BBB> elenril: oh n/m the first comment, I see that's mov.c patch
[15:50:40] <elenril> BBB: yes, worksforme
[15:51:07] <elenril> (not like anybody cares about asf, i wonder why i'm working on it anyway)
[15:58:36] <tjoener> elenril: lot's of porn is in asf :)
[16:02:18] <tjoener> BBB: it's at upload.ffmpeg.org in the folder MPlayer/incoming (thats what the guide said)
[16:02:24] <tjoener> name is "small-artefact-on-frame-53.264"
[16:04:22] <tjoener> its between the letters p and i in "pictures"
[16:05:14] <tjoener> and my apologies, I appear to have forgotten to make a directory
[16:05:38] <BBB> mru: the ftp doesn't work well at all, I keep getting timeouts
[16:06:17] <BBB> mru: can you check permission on that file?
[16:06:36] <mru> timeouts doing what?
[16:07:13] <mru> try again
[16:12:09] <BBB> yes works now
[16:12:21] <BBB> was it a permission problem?
[16:12:25] <BBB> chrome's error reporting sucks :-p
[16:12:52] <mru> yes
[16:14:05] <BBB> tjoener: which software?
[16:14:15] <tjoener> I used mplayer to play it
[16:14:20] <tjoener> r....
[16:14:20] <tjoener> sec
[16:14:34] <tjoener> MPlayer SVN-r32492-4.2.5
[16:14:47] <tjoener> I do not know which version of ffmpeg that is sadly
[16:15:03] <tjoener> if you have an svn ffmpeg build that can play something, i'll check
[16:18:27] <Vitor1001> mru: I'm not doing your zlib patches since I'm pretty sure you have them in a git tree somewhere
[16:18:37] <mru> I do indeed
[16:18:44] <mru> and newer versions of them too
[16:18:49] <lu_zero> nice =)
[16:19:09] <mru> there's still a nasty corner-case bug I need to take care of
[16:19:27] <tjoener> BBB: if the checkout is of the same date as the revision, it could be either of 25473 or 25472
[16:19:47] <lu_zero> btw for ssl needs should we use an external lib or try to bake something out what we have?
[16:20:31] <mru> let's link to openssl and watch debian get its knickers in a twist
[16:22:17] <siretart> there are much nicer ssl implementations than openssl
[16:22:27] <lu_zero> I was thinking nss
[16:22:27] <elenril> gnutls?
[16:22:40] <lu_zero> elenril: gnutls is... icky
[16:22:41] <mru> pick your licence poison
[16:22:59] <tjoener> oh and x264 has the same issue
[16:23:02] <elenril> lu_zero: what's so bad about it?
[16:23:08] <mru> it's gnu
[16:23:12] <mru> what do you expect?
[16:23:21] <elenril> gnu make is rather nice
[16:23:26] <elenril> OrSoIHeard
[16:23:32] <mru> that's the exception
[16:23:42] <mru> and I'm sure the code is ugly as sin
[16:23:55] <mru> moreover, make isn't critical for security
[16:24:09] <tjoener> bbb: and the version I got it from (x264.nl) uses ffmpeg revision 25563
[16:24:24] <elenril> openssl isn't gpl-compatible :/
[16:24:39] <elenril> for no better reason that lolitrollu
[16:24:41] <mru> 4 minutes, not bad
[16:25:18] <kshishkov> elenril: please all well-written GNU projects
[16:27:09] <tjoener> i'm playing bfbc2
[16:27:16] <tjoener> if you find anything, let me know :)
[16:34:20] <tjoener> or if you need anything else
[16:41:48] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * rbf5f9b528b ffmpeg/libavcodec/ (get_bits.h mjpegdec.c):
[16:41:48] <CIA-29> ffmpeg: Sanitise get_bits macros, part 1
[16:41:48] <CIA-29> ffmpeg: Some of the macros in get_bits.h include a final semicolon,
[16:41:48] <CIA-29> ffmpeg: some do not. This removes these or adds do {} while(0) around
[16:41:48] <CIA-29> ffmpeg: the macros as appropriate and adds semicolons where needed in
[16:41:49] <CIA-29> ffmpeg: calling code.
[16:41:50] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:41:50] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * rfb5c841d5f ffmpeg/libavcodec/get_bits.h:
[16:41:51] <CIA-29> ffmpeg: Sanitise get_bits macros, part 2
[16:41:51] <CIA-29> ffmpeg: These whitespace changes improve the readability of the get_bits
[16:41:52] <CIA-29> ffmpeg: macros.
[16:41:52] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:41:53] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r611a6f59ce ffmpeg/libavcodec/get_bits.h:
[16:41:53] <CIA-29> ffmpeg: get_bits: move tracing macros to end of file
[16:44:56] <Vitor1001> mru: Why are you reviewing the patches I'm sending?
[16:45:10] <mru> not all
[16:45:13] <Vitor1001> Ok.
[16:45:14] <mru> that one was easy
[16:45:33] <mru> and what's the point in sending them if you don't expect a review?
[16:45:34] <Vitor1001> Just to be sure you know the original submitter say he will not be working on it
[16:45:38] <Vitor1001> Me neither.
[16:46:59] <Vitor1001> The point is that they bitrot more slower if it is easy to apply and test
[16:47:27] <Vitor1001> And a nice place where people can look for old, but interesting patches, to work on.
[16:47:54] <Vitor1001> I expect someone to work on them to get them committed
[16:48:13] <Vitor1001> but revieweing is a second step
[16:49:15] <Vitor1001> That said, working on the smush patch looks fun
[16:49:27] <mru> nice and simple
[16:49:43] <Vitor1001> Exactly
[16:49:47] <BBB> tjoener: what is the artifact?
[16:49:56] <BBB> tjoener: can you make a png and circle the artifact in photoshop or so?
[16:50:10] <BBB> tjoener: or just describe where it is
[16:51:37] <BBB> tjoener: because I don't see anything on frame 53 between the p and the i
[16:51:46] <BBB> tjoener: so it may have been fixed already or I'm looking at the wrong frame
[16:52:28] <BBB> nothing in the frames around it either
[16:52:50] <BBB> tjoener: probably it's fixed already, this is probably the plane overflow asm that I fixed 1-2 weeks ago
[17:05:47] <j-b> any know regressions on Wavepack in master?
[17:08:04] <kshishkov> ?
[17:15:33] <BBB> j-b: not that I know
[17:16:10] <j-b> ok, weird
[17:16:18] <tjoener> ah BBB: could be, i'll post an image
[17:16:30] <BBB> ok thanks
[17:20:18] <tjoener> BBB: http://tjoener.be/Upload/shot0001.png
[17:20:26] <tjoener> and http://tjoener.be/Upload/shot0002.png
[17:21:33] <tjoener> the 0001 is the first error, the 0002 is 2 frames later, and it stays that way
[17:21:41] <tjoener> until the next keyframe
[17:26:25] <tjoener> BBB: is that revision 26381 you fixed? The plane 16x16 ASM?
[17:34:58] <BBB> tjoener: I can't reproduce the bug, and I'm almost definitely sure that the plane asm fix fixed it
[17:35:25] <BBB> yes that's 26381
[17:35:45] <BBB> it looks a lot like the artifact produced by that bug
[17:36:06] <tjoener> aaah
[17:36:48] <tjoener> BBB: care to enlighten what the bug waS? I'm not really an ASM guy, but I am interested, because that has to be a cornercase if I ever saw one
[17:37:06] <tjoener> been using the software h264 decoder a while and never saw something like this
[17:37:33] <BBB> tjoener: it's an integer overflow
[17:38:19] <BBB> tjoener: for plane16x16, you take the top edge 16 pixels and multiply them by 8,7,6,5,4,3,2,1,0,-1,-2,-3,-4,-5,-6,-7,-8 (from top-left edge to end of the row above)
[17:38:26] <BBB> tjoener: then you multiply that with a constant
[17:38:26] <tjoener> indeed
[17:38:36] <BBB> tjoener: the overflow occurs on b/w boundaries
[17:38:51] <BBB> such as dark/light text on a light/dark background halfway the MB
[17:38:57] <tjoener> ah yes
[17:39:04] <tjoener> so it just needed a particular mb
[17:39:09] <BBB> what happens is that you get 8+7+6+5+4+3+2+!)*255*multiplyconstant-(8+...)*0
[17:39:18] <BBB> and that basically _just_ overflows wordsize
[17:39:23] <BBB> I was calculating that in wordsize
[17:39:29] <BBB> changing it to dwordsize fixed it
[17:39:30] <tjoener> like in 99.9% of plane i16x16s it wouldnt be a problem
[17:39:35] <BBB> exactly
[17:40:15] <tjoener> and offcourse, pixars razorsharp graphics had to contain one of those :)
[17:40:20] <BBB> \o/
[17:40:54] <tjoener> a word is 16 bits right? or are we using the modern equivalent now?
[17:45:21] <tjoener> BBB: I thank you for addressing this
[17:45:32] <tjoener> Now I'll be looking for new builds :)
[17:51:55] <BBB> tjoener: np and yes a word is 15 bits + 1 sign bit
[17:53:12] <tjoener> so a short, ok
[17:53:45] <tjoener> brb
[17:53:46] <tjoener> dinner
[17:57:16] <CIA-29> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * r2fd9035ddc ffmpeg/libavcodec/aacenc.c: aacenc: fix typo in sync extension constant in 8ae0fa2
[18:04:16] <j-b> kshishkov: does your patch support 8channels in .wv ?
[18:06:06] <kshishkov> I've tested it with 7.1, seemed to work
[18:10:55] <BBB> Vitor1001: ah thanks for the fate test :)
[18:12:24] <kshishkov> j-b: but who cares, I don't think anyone is going to review it let alone applying
[18:12:40] <j-b> kshishkov: well, I care
[18:13:05] <j-b> but, true, I cannot apply :)
[18:13:06] <kshishkov> j-b: there's somebody caring about Bink-b but he's also ignored
[18:14:52] <kshishkov> BBB: also if you're interested I've tried to add RV4 PTS parser but playback was still not ok even if parser gave correct PTSes
[18:16:28] <BBB> kshishkov: don't be so pessimistic, we're trying to review everything we get
[18:17:18] <kshishkov> BBB: well, now you have very old patches in queue, some of them because of me :(
[18:18:17] <Vitor1001> BBB: You are welcome
[18:18:34] <Vitor1001> But if you could give some help suggesting some name for the test, it would be nice
[18:18:56] <Vitor1001> I don't really understand all the details of the bug it concerns
[18:19:27] <kshishkov> bbb-ununderstood-bug
[18:19:28] <Vitor1001> (I suppose that if one do some operations in the wrong order some quantity overflows)
[18:19:49] <Vitor1001> kshishkov: descriptive.
[18:19:58] <j-b> kshishkov: ok, if you care, I've tested the 5.1 on my 5.1 system and it works fine
[18:20:00] <BBB> Vitor1001: no, the reordering just helped to prevent increasing instruction count
[18:20:09] <j-b> kshishkov: setting up my 7.1 system to test the other on
[18:20:27] <BBB> Vitor1001: the problem is plane 16x16 overflow on MBs where the left and right have sharp contrast (e.g. black/white border or so)
[18:20:28] <kshishkov> j-b: I've tested it only with mono, stereo, 4.0, 5.1, 6.1 and 7.1
[18:20:44] <BBB> Vitor1001: just call it plane-hcoeff-overflow or so
[18:20:46] <j-b> kshishkov: I meant with my 7.1 output
[18:20:47] <kshishkov> j-b: by decoding to file and using Audacity afterwards
[18:20:58] <Vitor1001> Maybe h264-issue-2547
[18:21:04] <jannau> applying is not the problem once it's reviewed
[18:21:17] <Vitor1001> It makes a nice precedent for bugs created after an issue
[18:21:20] <kshishkov> jannau: you spoil all the fun
[18:21:31] <Vitor1001> and an easy way to find out more about the sample
[18:21:55] <kshishkov> Vitor1001: h264-hiprecision or intoverflow would be better
[18:22:05] <mru> Vitor1001: just name the function that's problematic
[18:22:18] <mru> then if it fails, we know where to look
[18:22:39] <j-b> kshishkov: 5.1 order is correct
[18:22:48] <Vitor1001> I like the idea of using the issue number.
[18:22:52] <mru> I don't
[18:22:55] <Vitor1001> Does anyone see any disadvantage?
[18:23:01] <mru> that's a useless level of indirection
[18:23:23] <BBB> Vitor1001: ok also
[18:23:27] <BBB> 2393 iirc
[18:23:30] <mru> what is the name of the thing where it overflows?
[18:23:38] <kshishkov> j-b: sorry
[18:23:48] <Vitor1001> Ok, both can be done, a comment in .mak indicating the issue #
[18:23:52] <BBB> mru: hcoeff
[18:23:53] <Vitor1001> brb, dinner
[18:24:03] <jannau> mru: patches.ffmpeg.org should work once it has a dns entry
[18:24:06] <mru> so call it h264-hcoeff-range
[18:24:36] <BBB> h264-plane16x16-hceff-...
[18:24:55] <mru> fine with me
[18:25:05] <j-b> kshishkov: works with the right order, in .wv and mkv for 4.0, 5.1 and 7.1 on windows
[18:25:16] <BBB> feeding baby sorry for the typos :-p
[18:25:22] <mru> then if it fails, we know immediately where to look
[18:25:29] <BBB> right
[18:26:17] <kshishkov> j-b: I'm terribly sorry, use vanilla FFmpeg repo
[18:27:15] <j-b> can't I use the chocolate one?
[18:27:42] <kshishkov> I don't remember having Swiss fork
[18:27:56] <j-b> too bad
[18:28:02] <mru> jannau: done
[18:28:08] <kshishkov> so we have only vanilla, extrawürst and surströmming flavours
[18:28:15] <j-b> kshishkov: well, I may just apply the patch before doing the windows release and wait
[18:28:33] <wbs> DonDiego: stdint.h is implicitly included by avcodec.h iirc, individual .c files don't need to include it (no ohter ones does)
[18:29:06] <DonDiego> wbs: i disagree with that policy
[18:29:21] <mru> +1
[18:29:40] <DonDiego> when you shuffle #includes around, you will get a cascade of breakage
[18:29:48] <kshishkov> j-b: so you're going to fork and create fricasse+escargot flavour?
[18:29:59] <DonDiego> that's why i advocate making files as standalone as possible, headers more so
[18:30:18] <DonDiego> mru: still want me to look at some patch?
[18:30:36] <mru> DonDiego: my immediate queue is empty right now
[18:30:45] <mru> I have dozens more though
[18:30:53] <DonDiego> ok, keep them coming :)
[18:31:29] <wbs> generally yes, but _everything_ in ffmpeg uses stdint.h, any one of the headers will include it, especially if you explicitly include avcodec.h, I'd count on it already being included
[18:31:36] <mru> DonDiego: as you wish
[18:31:47] <wbs> but headers should be standalone yes, as make checkheaders tests
[18:36:59] <mru> wbs: never assume anything
[18:37:22] <mru> if documentation says one header includes another, then it's ok to only include the first
[18:37:30] <mru> as with inttypes.h and stdint.h
[18:38:06] <wbs> could we spec somewhere that avcodec/avformat/avutil.h do include stdint.h so individual .c files don't need to explicitly include it, then?
[18:40:04] <mru> jannau: could you hack the patch view with a link to http://news.gmane.org/find-root.php?message_id=$id ?
[18:40:24] <mru> the message is already displayed so it can't be that hard
[18:42:48] <soroushi> Hi
[18:43:02] <soroushi> I am using VLC to stream on RTP and use FFmpeg save it to file but the saved video has unacceptable jitter, freezing and, seemingly, frame drops. here is the command line and output: http://pastebin.com/hDMx3PNd
[18:43:27] <DonDiego> soroushi: #ffmpeg is your channel
[18:43:44] <soroushi> ok
[18:44:25] <mmu_man> grr stupid VLC, when asking to record all streams it plays both english and french streams also, and selecting one drops the other in the stream dump, bleh
[18:44:39] <jannau> mru: I'll look
[18:45:01] <mru> mmu_man: who needs french anyway?
[18:45:39] <spaam> mru: j-b and ubitux ...
[18:45:46] <kierank> vlc broke my mouse
[18:45:53] <kierank> i had to unplug it an replug it
[18:45:54] <kierank> :/
[18:46:01] <spaam> :(
[18:46:05] <ubitux> spaam: mmh?
[18:46:23] <spaam> ubitux: read the like above....
[18:46:27] <spaam> line
[18:46:38] <j-b> mmu_man: recording how?
[18:46:38] <ubitux> I hate dubbed audio stream
[18:47:01] <ubitux> and i really don't care about a single french thing
[18:47:11] <kshishkov> us neither ;)
[18:47:21] <mru> ubitux: not even cheese or wine?
[18:47:34] <ubitux> i don't drink alcohol :)
[18:47:46] <mru> cheese is neither alcoholic nor drunk
[18:47:49] <ubitux> and i eat cheese just because you don't need to prepare it :)
[18:47:50] <jannau> mru: done
[18:48:07] <kshishkov> mru: it's either runny or mouldy
[18:48:24] <kshishkov> mru: and for mouldy Adelost would do just as fine
[18:49:31] <_av500_> cheddar ftw
[18:49:45] <kshishkov> _av500_: tss, don't tell mru
[18:50:14] <_av500_> i wont
[18:51:27] <jannau> and committed patches have now a link to the gitweb commit too
[18:52:38] <j-b> mmu_man: seeing that they are 4 main ways of recording, this is too vague, sorry
[18:53:03] * kshishkov goes to drool over http://www.arla.se/Default____17804.aspx?SelectedMenuItem=18401
[18:53:51] <_av500_> is this genuine cheddar and D.O.C ?
[18:54:10] <mru> that's cheap swedish imitation
[18:54:27] <mru> real cheddar comes from Cheddar
[18:54:35] <kshishkov> of course
[18:54:58] <kshishkov> though I guess it's hard to find even there
[18:55:08] <mru> there are actually regulations about that
[18:55:25] <_av500_> the cheddar act
[18:55:31] <mru> indeed
[18:55:33] <mru> 1856
[18:55:46] * kshishkov likes cheese from area around Umeå
[18:55:47] <_av500_> thouc shalt not have any other cheese beside me
[18:56:10] <kshishkov> _av500_: and you are completely right - they don't have
[18:58:29] <kshishkov> mru: any word against Västerbottenost?
[18:59:17] <mmu_man_> j-b: -v --sout-all "$u" --sout '#duplicate{dst=display,dst="standard{mux=ts,dst=/Volumes/Data/continuum.ts,access=file}"}'
[18:59:33] <mmu_man_> u=rtsp://...
[19:00:14] <mmu_man_> great being able to record all audio, but not so nice having to listen to all of them at once :p
[19:01:57] <j-b> mmu_man_: because you ask display inside the sout
[19:02:06] <j-b> mmu_man_: you need to see too?
[19:03:46] <mmu_man> well it's easier to know when to cut :p
[19:04:01] <j-b> mmu_man: why not using the record button then?
[19:04:09] <mmu_man> the other option being to read the dump with another instance but it lags a bit
[19:04:10] <mru> kshishkov: västerbottenost is nice
[19:04:22] <mmu_man> record button ?
[19:04:31] <mmu_man> I don't think VLC has this in OSX yet
[19:04:40] <j-b> mmu_man: shift+'r'
[19:05:01] <j-b> and fuck, I need to change the UI
[19:05:04] <mmu_man> oh, good to know, though I'm not sure the shortcuts are the same in OSX
[19:05:21] <kshishkov> mru: and I'm not sure if I've seen decent kryddost replacement
[19:05:54] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * r7a5a168abe ffmpeg/ (libavcodec/mips/mathops.h libavutil/mips/intreadwrite.h): MIPS: use inline asm only when supported by compiler
[19:06:33] <j-b> mmu_man: KEY_MODIFIER_COMMAND|KEY_MODIFIER_SHIFT|'r' then
[19:07:05] <mmu_man> hmm yeah, the menu shows "Montrer dans le Finder" which is not really the same
[19:07:23] <mmu_man> damn I've been complaining about having to go through all the wizard each time
[19:08:02] <mmu_man> and the menu entry is even disabled
[19:08:06] <mmu_man> but it does record
[19:08:11] <mmu_man> now does it record all streams ?
[19:08:11] <j-b> mmu_man: not to mention that to sout, the short syntax is better: --sout-all --sout file/ts:///Volumes/Data/continuum.ts
[19:08:38] <mmu_man> hmm yeah but it doesn't display then, right ?
[19:08:44] <j-b> it doesn't.
[19:09:34] <BBB> kshishkov: ask alex (peloverde) to review audio stuff for now
[19:09:47] <BBB> kshishkov: I had a quick look at the wavpack patch and don't understand much of it
[19:09:55] <BBB> it looks ok but I don't get much of it
[19:10:51] <kshishkov> BBB: why? It should be clear enough
[19:11:09] <mmu_man> hmm Cmd-Shift-r only record the played channels though, not both audio
[19:11:26] <mmu_man> anyway, thx it's still useful for usual things
[19:11:50] <j-b> mmu_man: there is an option for that on Mac
[19:11:58] <j-b> I just need to find it
[19:12:32] <mmu_man_> I was too lazy to even grep the sources to see if there was
[19:12:50] <mmu_man_> I recall building vlc on BeOS once and I didn't really want to retry :D
[19:14:08] <j-b> mmu_man_: it is much easier now
[19:14:12] <j-b> mmu_man_: except on Windows
[19:14:43] <kshishkov> and BeOS - hello from FFmpeg
[19:15:19] * mmu_man_ throws an Haiku R1/alpha2 CD over kshishkov 
[19:15:40] <BBB> mru, Vitor1001: for the repeated frames, use vsync 0
[19:15:53] <BBB> looking at the timestamp code is on my list, but not high enough yet
[19:16:09] <mru> we should really do something about the timestamp mess
[19:16:18] * kshishkov just watches it to crumble into dust in mmu_man hands
[19:16:21] <mru> and I want to make -strict 1 default
[19:16:56] <siretart> wow, this ffmpeg build failure on amd64 is really strange. sometimes it happens and sometimes it doesn't. /me hates nondeterministic toolchains :-/
[19:17:01] <mmu_man_> Haiku works fine
[19:17:11] <lu_zero> Gentoo works fine
[19:17:17] <j-b> Hurd works fine
[19:17:19] * lu_zero runs
[19:17:28] <thresh> windows forks wine
[19:17:50] <lu_zero> siretart: jokes aside
[19:17:58] <mmu_man> last time I saw, Hurd crashed fine, actually
[19:18:05] <lu_zero> the config.mak
[19:18:10] <lu_zero> when it fails
[19:18:25] <lu_zero> does have PIC enabled?
[19:18:49] <siretart> lu_zero: yes. always
[19:19:18] <siretart> gcc (Ubuntu/Linaro 4.5.2-1ubuntu6) 4.5.2
[19:19:32] <kshishkov> mmu_man: there's Hurd-NG even
[19:20:09] <mmu_man> wow
[19:20:15] <mru> when will they make hurd-ds9?
[19:20:37] <kshishkov> mmu_man: http://www.gnu.org/software/hurd/hurd/ng.html
[19:20:58] <kshishkov> mru: hurd-voyager is the best you can get I fear
[19:21:10] <mru> perhaps if cisco were to fork...
[19:21:54] <lu_zero> ?
[19:22:20] <lu_zero> and the binary sometimes doesn't get built with pick nonetheless
[19:28:42] <mmu_man> lol
[19:28:47] <mmu_man> reminds me about Lunix-NG
[19:29:19] <mmu_man> http://lng.sourceforge.net/
[19:30:05] <saintdev> -ng is so oooold, everything is -Kit now
[19:32:07] <mmu_man> bleh, *Kit is nothing new
[19:32:13] <mmu_man> BeOS did it 15y ago :D
[19:33:06] <saintdev> yeah, but it's the new hotness
[19:33:44] <mru> it's the new cargo cult
[19:33:48] <mru> cargokit
[19:33:59] <mmu_man_> yeah, just like tickless, and many other things ppl claim to have invented :p
[19:34:14] <mmu_man_> LicKit :p
[19:34:34] <saintdev> mru: cultkit?
[19:48:01] <mmu_man> BreaKit
[19:52:13] <elenril> how do i configure git show to include a stat by default
[19:53:56] <DonDiego> Dark_Shikari: Subject: [FFmpeg-devel] [PATCH] set b_tff in libx264.c since it is not set now
[19:55:37] <siretart> hm. is it possible that "-Wl,-Bsymbolic-functions" in LDFLAGS breaks the shared library build?
[19:56:09] <mru> siretart: does that override -Bsymbolic?
[19:56:17] <mru> if so, it would indeed break things
[19:57:54] <siretart> if that is true, then it would explain a lot of confusion here...
[19:58:22] <mru> why are you adding that flag?
[20:00:22] <siretart> it seems dpkg is injecting this for some reason. not exactly sure why
[20:00:55] <Dark_Shikari> DonDiego: I'm working on another ML thread, moment
[20:01:18] <DonDiego> Dark_Shikari: sure, just wanted to ping you about that thread
[20:01:21] <Dark_Shikari> good idea
[20:01:24] <Dark_Shikari> keep pinging me please
[20:01:30] <DonDiego> i will :)
[20:01:40] <lu_zero> which thread?
[20:04:31] <siretart> mru: afaiu the mainpage, -Bsymbolic applies to global variables, and -Bsymbolic-functions to, well, functions.
[20:04:43] <siretart> trying another build with LDFLAGS pruned.
[20:05:30] <mru> siretart: my interpretation is that -Bsymbolic applies to all symbols, -Bsymbolic-functions only to functions
[20:08:00] <siretart> hm. I see. smells like an ld bug to me.
[20:08:33] <mru> it was a data symbol it failed on, right?
[20:09:08] <siretart>  /usr/bin/ld: libswscale/rgb2rgb.o: relocation R_X86_64_PC32 against symbol `ff_bgr2YCoeff' can not be used when making a shared object; recompile with -fPIC
[20:09:08] <Dark_Shikari> mru: ridiculous extremal plane test uploaded
[20:09:16] <mru> Dark_Shikari: thanks
[20:09:19] <Dark_Shikari> I HIGHLY recommend that you test this file with your arm asm, if you have planar pred asm
[20:09:28] <Dark_Shikari> it broke a lot of our asm in x264 on 9-bit and 10-bit (but 8-bit managed to work fine)
[20:09:28] <mru> will do
[20:09:44] <siretart> mru: indeed
[20:10:01] <mru> Dark_Shikari: so _where_ is the sample?
[20:10:10] <mru> and what is the correct output?
[20:11:41] <Dark_Shikari> mru: Just decode with JM for the correct output, what do you want
[20:11:48] <Dark_Shikari> the sample is on incoming
[20:11:52] <mru> name?
[20:11:56] <Dark_Shikari> Look at my email.
[20:13:11] <Dark_Shikari> http://pastebin.com/pBVEzkKu <--here's a framemd5 made with the yuv file
[20:13:17] <Dark_Shikari> i.e. decode with JM, then send yuv through ffmpeg
[20:13:26] <Dark_Shikari> use this to make sure your framemd5 is right (made using ffmpeg without asm or similar)
[20:16:07] <Dark_Shikari> (is this sufficient?)
[20:16:16] <mru> should be
[20:17:00] <BBB> if you find bugs, feel free to put that sample in fate instead
[20:17:13] <mru> I intend to
[20:17:15] <Dark_Shikari> It should be in fate
[20:18:07] <Dark_Shikari> also, that clip triggers another, unrelated cosmetic bug
[20:18:09] <Dark_Shikari> which causes ffmpeg to spam warnings
[20:21:49] <peloverde> Interesting that michael committed "Remove H.264 encoder fragments" I could have sworn that he was vehemently against it last time it was discussed
[20:22:00] <mru> +1
[20:22:06] <mru> same for my getbits cleanup
[20:22:14] <Dark_Shikari> lol.
[20:22:36] <mru> why do you think I have so many patches queued up?
[20:23:17] <ubitux> he does that to easier next merges imo
[20:24:17] <siretart> mru: it seems I'm right. When configure runs with LDFLAGS set to "-Wl,-Bsymbolic-functions" breaks the build with that confusing error message
[20:24:33] <mru> well, get rid of it
[20:24:34] <siretart> this is with binutils 2.21
[20:24:40] <mru> try 2.20
[20:24:40] <siretart> yes, this is what I'm going to do
[20:24:57] <siretart> i.e., getting rid of it by pruning ldflags
[20:24:58] <mru> what order are the flags?
[20:25:33] <siretart> order? I see this in the buildlog:
[20:25:47] <siretart> dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions
[20:25:58] <mru> yeah, but what ends up in the link command?
[20:27:07] <mru> Dark_Shikari: plugging your paste into fate as reference it passes on x86
[20:27:13] <mru> that's all I tested
[20:27:23] <Dark_Shikari> ok, great.
[20:27:33] <Dark_Shikari> x86 should work, it uses the same algorithm as x264 does iirc
[20:27:34] <siretart> -Bsymbolic, then a lot of search directives, then -Bsymbolic-functions
[20:27:53] <mru> siretart: so maybe the second flag disables it for data symbols
[20:28:03] <mru> ld manual isn't very informative in that regard
[20:28:34] <siretart> that's indeed a theory that would explain this mess
[20:28:49] <siretart> I'm only glad that I finally found a workaround
[20:29:54] <mru> Dark_Shikari: so there's nothing like that in the official conformance tests?
[20:30:20] <Dark_Shikari> No way
[20:30:38] <Dark_Shikari> official conformance tests also seem to be missing some things like extremal quant situations
[20:30:39] <mru> lame
[20:43:54] <merbanan> Dark_Shikari: how about we supply some to the proper place ?
[20:49:35] <merbanan> ie send them to itu or whatever org holds them
[20:55:40] <thresh> andoma: did you succeed in building ffmpeg for PS3?
[21:01:29] <andoma> thresh: not really.. the toolchains does still not build the altivec asm code
[21:01:45] <andoma> but i've not put more effort into fixing that (yet)
[21:01:49] <mru> the intrinsics or the real asm?
[21:01:52] <andoma> real asm
[21:02:10] <mru> that file is so much fun...
[21:02:32] <mru> gnu syntax, apple syntax, different abis, etc
[21:02:37] <andoma> yeah
[21:02:45] <thresh> andoma: OT: you didnt try backup stuff / games, right?
[21:02:53] <andoma> thresh: no
[21:03:12] <andoma> i've no interest whatsoever in such things
[21:20:30] <BBB> mru: wheheh that looks like the same overflow I had also
[21:20:31] <BBB> :)
[21:21:01] <BBB> mru: is that the horizontal coefficient (H in C code) right after multiplication before shift-right?
[21:21:13] <mru> not really sure
[21:21:22] <mru> it looked like a likely place for overflow
[21:21:24] <Dark_Shikari> BBB: Look at what we did in x264, btw, for 9 and 10-bit.
[21:21:29] <mru> and it was easy to expand to 32-bit there
[21:21:35] <mru> so I tried and it worked
[21:21:46] <Dark_Shikari> but it's probably not necessary here, just amusing though
[21:22:27] <kierank> [20:30] Dark_Shikari: official conformance tests also seem to be missing some things like extremal quant situations --> not as good as the 1080p50 mpeg-2 compliance tests which are actually interlaced videos encoded as progressive
[21:23:44] <Dark_Shikari> basically all the common bugs in h264 decoders are things that don't show up in conformance tests
[21:23:48] <Dark_Shikari> multi-refdupe with different weights
[21:23:59] <Dark_Shikari> delta quant over 26 (since nobody uses delta quant in ref encoders)
[21:24:05] <Dark_Shikari> delta quant + PCM blocks
[21:32:55] <DonDiego> gnite
[22:07:30] <superdump> jannau: that patchwork thing is nice :)
[22:08:21] <superdump> nice to have a patch stack thing so one can just look on there and see what needs doing rather than trawling through the ML to see what has been OKed or not
[22:08:48] <superdump> though i wonder how it will manage submission of updated patches due to reviews and stuff like that
[22:09:03] <mru> not that well is the answer
[22:09:09] <superdump> mmm
[22:09:34] <superdump> i guess there's some kind of admin method of removing stuff from the list though
[22:10:33] <mru> you can set status to superseded or whatever in the web interface
[22:10:46] <superdump> good good
[22:10:47] <superdump> i like it
[22:14:02] <ruggles> arguments in yasm seem to be loading into the wrong registers... where should i start looking for what's going wrong?
[22:14:50] <roxfan> what platform?
[22:14:56] <ruggles> x86-64
[22:15:55] <ruggles> i imagine something weird is going on in the cglobal/PROLOGUE macro, but i can't tell what...
[22:16:15] <roxfan> could it be trying to use win64 calling convention?
[22:16:52] <ruggles> o
[22:17:23] <ruggles> i'm running ubuntu 64-bit
[22:18:41] <ruggles> how do i see the pre-processed output from yasm?
[22:19:02] <mru> yasm --help
[22:59:45] <mru> hmm, someone likes ifdefs
[23:00:02] <j-b> hmm, someone likes ifdef and doesn't know how to read man
[23:00:28] <mru> and mangles patches
[23:00:53] <j-b> who will give him -D__USE_MINGW_ANSI_STDIO=1 ?
[23:01:46] <mru> j-b: feel free to reply
[23:01:51] <mru> if you know the answer
[23:02:02] <mru> is that something we should be adding to configure?
[23:02:10] <j-b> yes
[23:02:18] <mru> patches welcome
[23:02:22] <j-b> well, in case of mingw, yes
[23:02:37] <j-b> this will indeed tell mingw to not use msvcrt mess
[23:02:41] <j-b> but its own mess
[23:06:26] <j-b> and the patch will be a oneliner +        add_cppflags -D__USE_MINGW_ANSI_STDIO=1 line 2377
[23:06:39] <Kovensky> j-b: does its own mess work
[23:07:12] <j-b> Kovensky: define "work".
[23:07:38] <Kovensky> j-b: what does it do differently from windows' mess?
[23:07:54] <j-b> Kovensky: I've been using this mingw mess on VLC for Windows since 3 years, and the VLC debug messages and FFmpeg messages are outputted correctly
[23:08:16] <j-b> Kovensky: well, it doesn't use printf* from msvcrt but their own (derived from linux)
[23:08:32] <Kovensky> j-b: ah
[23:08:45] <j-b> and their own, understand %z , %t or else
[23:09:04] <Kovensky> when will they add support for UTF-8 filenames ;_;
[23:09:13] <j-b> ;)
[23:09:30] <j-b> however, some version of gcc behave differently, so it isn't always the most simple
[23:09:48] <j-b> but at least, you don't need to use %Id or other horrible things
[23:10:20] <pJok> since when did gcc behave the same between versions?
[23:50:00] <peloverde> Is there a way to make gitk show the comitter timestamp instead of the author timestamp?
[23:50:31] <mru> hack the source
[23:51:38] <j-b> use tig?