[Ffmpeg-devel-irc] ffmpeg-devel.log.20120914

[burek]

[00:05] <Daemon404> well fuck me
[00:05] <Daemon404> msvc's sscanf is derpy
[00:05] <Daemon404> the regex / format support differs from gcc
[00:05] <Daemon404> and everything else
[00:06] <Daemon404> " c%d %n" = fail
[00:06] <Daemon404> " c%d%n" = works
[00:06] <saste> msvc insanity won't never end
[00:07] <nevcairiel> why is there a space anyway?
[00:07] <Daemon404> i have no idea.
[00:07] <Daemon404> it seems wrong though
[00:07] <Yexo> depends on the exact input
[00:07] <Daemon404> it's also possible that what it gets passed may be mangled earlier on ffmpeg_opts.c
[00:07] <Daemon404> or something
[00:07] <Daemon404> since ffmpeg's option parsing gets mangled too
[00:07] <Daemon404> this doesn't happen in libav.
[00:08] <Daemon404> n = sscanf(arg, "%d.%d.%d:%d.%d",
[00:08] <Daemon404> .%d looks VERY wrong
[00:08] <Daemon404> possibly ambiguous
[00:09] <Yexo> why would that be very wrong? A dot isn't special for sscanf, is it?
[00:09] <Daemon404> formattign string
[00:09] <Daemon404> e.g.
[00:10] <Daemon404> or well wait, my brain died
[00:10] <Daemon404> derp
[00:10] <Daemon404> i almost wonder if this is not related to sscanf at all
[00:10] <Daemon404> but some other option parsing
[00:10] <Daemon404> but it's much more compelx than libavs to figure out
[00:11] <nevcairiel> i'll have a look on the weekend if you didnt find anything by then, i sometimes like some complex debugging :p
[00:11] <nevcairiel> (yes, i am weird)
[00:11] <Daemon404> ;p
[00:11] <Daemon404> but yes
[00:11] <Daemon404> that space is what was breaking af_pan
[00:11] <Daemon404> unknown whther its the format string's fault or input's fault
[00:12] <nevcairiel> its rather odd, according to sscanf msdn docs spaces are perfectly valid and just consume all whitespace in the input
[00:12] <Daemon404> oh@
[00:12] <nevcairiel> (0 is also a valid number of matches for it)
[00:12] <Daemon404> im assumign a null character is not valid whitespace to ms
[00:13] <nevcairiel> blank tab and newline
[00:13] <nevcairiel> if the docs can be trusted
[00:15] <saste> ah kierank indirectly replied to my question
[00:16] <saste> there are so many binary blob drivers/APIs out there I decided it wasn't worth it
[00:28] <Daemon404> more buggy code :<
[00:28] Action: Daemon404 checks git blame
[00:29] <Daemon404> oh lovely, it was added as part of a merge commit.
[00:30] <nevcairiel> those are the most fun
[00:30] <Daemon404> opt_qsca;e
[00:31] <Daemon404> opt_qscale *
[00:31] <Daemon404> is broken
[00:31] <Daemon404> it handles -q:v correctly, but not -qscale:v
[00:31] <Daemon404> which fate uses
[00:33] <kierank> saste: their just stick stuff through their blob mostly just because they can
[00:33] <kierank> the RF stuff I guess is their pitfall
[00:35] <Yexo> kierank: that wasn't the only reason. Another one I forgot to mention is that the driver only has some very abstract functions, like "read register". Which register you need to read/write to set stuff like bitrate is undocumented (it's hidden away in the library)
[00:36] <kierank> i know
[00:36] <Daemon404> oh hmmmmmm
[00:36] <kierank> i ask you guys every year at IBC about it
[00:36] <Daemon404> av_sprintf is b0rked
[00:36] <Daemon404> not qscale code
[00:37] <kierank> however this year i was more annoyed with streamxpert not using a dejitter buffer
[00:37] <Daemon404> av_asprintf*
[00:37] <Daemon404> ahhhh
[00:37] <Daemon404> len = vsnprintf(p, len + 1, fmt, va);
[00:37] <Daemon404> no wonder
[00:37] <Daemon404> it's relying on the broken vsnprintf impl
[00:38] <kierank> Yexo: anyway it could all be RE'd if necessary
[00:38] <Daemon404> which has a fix waiting on a another fix for va_copy
[00:38] <Daemon404> god this is convoluted
[00:38] <Yexo> sorry, what is "RE'd"?
[00:38] <Yexo> oh, nevermind
[00:38] <Yexo> kierank: I know, but that's not the point currently
[00:39] <Daemon404> nevcairiel, i figured it out i guess.
[00:39] <Yexo> I'll probably write a patch to support those devices via the library anyway, I was mostly wondering if there was any interest or objections
[00:39] <Daemon404> but its a patch that relies on a patch that relies on a patch that is needed
[00:39] <Daemon404> Bikesheds Ahead
[00:40] <kierank> Yexo: imho people should just pipe to DtPlay like they currently do
[00:42] <Yexo> well, that's indeed another solution
[01:44] <Daemon404> where would i stick a definition of va_copy for msvc?
[01:45] <Daemon404> libav just wants me to stick it in the only file that uses it, but ffmpeg uses it on one other place
[01:54] <michaelni> Daemon404, your decission
[02:05] <Daemon404> i dont know which is best by design
[02:11] <michaelni> best by design is to stick it in msvc 
[02:11] <Daemon404> heh
[02:11] <Daemon404> not feasible
[02:12] <michaelni> ok, so the best is out of the window
[02:12] <michaelni> stick it somewhere where its good enough and dont waste too much time with searching for the 2nd best pllace
[02:13] <Daemon404> it will be needed in cmdutils.c and in compat/msvcrt/snprintf.c
[02:13] <Daemon404> its a weird case
[10:45] <TimNich> anyone around experienced in using graph2dot?
[10:58] <saste> TimNich, you need to specify the inputs for the filtergraph, and the outputs
[10:58] <saste> nullsrc and nullsink may come handy for that
[10:59] <TimNich> OK cheers will try
[11:00] <TimNich> That does it, I think the docs could be  clearer!
[11:00] <saste> uhm CIA down?
[11:02] <TimNich> saste:  nullsrc seems to default to 320x240 420, is there a way to force it to be the same as my real source?
[11:02] <saste> TimNich, nullsrc=s=SIZE
[11:04] <TimNich> saste:  oops, just seen it, was looking at anullsrc :( but still no option for 422/444 etc
[11:04] <saste> TimNich, what is that? I suppose you mean yuv...
[11:05] <saste> try to add a format filter just after the nullsrc
[11:05] Action: TimNich of to a meeting
[11:05] <TimNich> saste: will try later thanks..
[17:57] <Daemon404> sure is spam
[17:58] <Daemon404> saste, is there anything akin to 'make tools' (trying to easily test that pixfmt2fourcc too)
[17:58] <saste> Daemon404, make tools/pixfmt2fourcc
[17:59] <Daemon404> wut... does that tool depend on all of libavcodec?
[17:59] <saste> I think so
[17:59] <saste> at least it links against libavcodec
[17:59] <Daemon404> guess im waiting... (slow msvc+converter is slow)
[18:00] <nevcairiel> at least not running configure!
[18:00] <Daemon404> lol
[18:00] <Daemon404> yeah
[18:00] <Daemon404> nevcairiel, for some reason i cant make -jN or converter+cl just.. block
[18:00] <Daemon404> using 1% cpu
[18:00] <nevcairiel> works for me
[18:00] <Daemon404> s/or/for/
[18:00] <Daemon404> yeah it works on my other box
[18:01] <Daemon404> but not this one
[18:01] <nevcairiel> how weird
[18:01] <Daemon404> yea
[18:01] <nevcairiel> without that it takes ages
[18:01] <Daemon404> yes
[18:01] <Daemon404> what OS is your box?
[18:01] <nevcairiel> my dev box is 7 sp1, fate is on a 2008 r2 sp1 server
[18:01] <Daemon404> ah!
[18:02] <Daemon404> my box tha tworks is 2008r2
[18:02] <Daemon404> broken is win 7
[18:02] <Daemon404> also, nevcairiel, how well do you know msvc's sscanf?
[18:02] <Daemon404> i fixed that af_pan crash, but the fix is ... weird
[18:03] <nevcairiel> I dont really work with such methods in msvc
[18:03] <nevcairiel> thats C
[18:03] <nevcairiel> msvc work for me is mostly c++ :p
[18:03] <nevcairiel> i never heard about any complaints before though
[18:04] <nevcairiel> if its really sscanf, can we reproduce in a minimalistic test case?
[18:05] <Daemon404> maybe
[18:07] <nevcairiel> how odd
[18:07] <nevcairiel> sscanf("c1", "c%d %n", &num, &len);
[18:07] <Daemon404> yes
[18:07] <nevcairiel> this should set both num and len, right?
[18:07] <Daemon404> that line
[18:07] <Daemon404> i fixed it by changing it to:
[18:07] <Daemon404> scanf("c1", "c%d%n", &num, &len);
[18:07] <Daemon404> :|
[18:07] <nevcairiel> len remains uninitialized in that call
[18:07] <Daemon404> er sscanf
[18:07] <Daemon404> the space busts it
[18:08] <Daemon404> but only in that instance...
[18:08] <nevcairiel> removing the space in my test also fixes it
[18:08] <Daemon404> yeah...
[18:09] <nevcairiel> neat, i have sources for their scanf implementation
[18:09] <nevcairiel> lets see
[18:09] <Daemon404> doesnt msvc come with the crt sources
[18:09] <nevcairiel> yea
[18:09] <nevcairiel> i just stepped in it with the debugger
[18:09] <nevcairiel> kinda expected assembly
[18:09] <Daemon404> hehe
[18:09] <nevcairiel> but no, sources!
[18:10] <Daemon404> oh nevcairiel i wanted to ask
[18:10] <Daemon404> how do you load your env for fate
[18:10] <Daemon404> env > dumpfile
[18:10] <Daemon404> and load it?
[18:10] <nevcairiel> env?
[18:10] <Daemon404> cmd to dump all env vars
[18:11] <nevcairiel> i just have a .bat file that sets up the env, and then another .bat file that runs fate with a specified configuration script, which internally calls my env.bat
[18:11] <Daemon404> olol
[18:11] <Daemon404> good old bat.
[18:11] <nevcairiel> i should really name them .cmd files now
[18:11] <nevcairiel> but old habits
[18:12] <Daemon404> people will tell you to use powershell
[18:12] <nevcairiel> i cba to learn its syntax
[18:12] <Daemon404> you dont learn it
[18:12] <Daemon404> you always have msdn open
[18:12] <nevcairiel> and all the script does is setup a few env variables, call the MSVC bat file for setting up the VS env vars, and then send bash into the game to run fate
[18:13] <nevcairiel> its not like its magic
[18:13] <Daemon404> ah
[18:13] <Daemon404> my msetup is a tad more complex
[18:13] <Daemon404> msys + msvc + strawberry perl + github git
[18:14] <saste> Daemon404, perl? why do you need perl?
[18:15] <saste> or is just for building docs?
[18:15] <Daemon404> docs
[18:16] <Daemon404> also for git send-email, the once-in-a-blue-moon i send a patch from windows
[18:20] <nevcairiel> i see whats going wrong in the sscanf implementation
[18:20] <Daemon404> oh?
[18:20] <nevcairiel> after it matched the "c1", its at EOF of the string
[18:21] <nevcairiel> what it then does is check if the next element in the format string is a %n
[18:21] <nevcairiel> and then fills it
[18:21] <nevcairiel> but there is no %n
[18:21] <nevcairiel> because tehre is a damn space
[18:22] <Daemon404> ah
[18:22] <nevcairiel> it fails to recognize that a space can also be silently discarded
[18:22] <Daemon404> oh well
[18:22] <Daemon404> ill submit a patch
[18:22] <Daemon404> i dont think it should be controversial
[18:22] <nevcairiel> i think sscanf is specified to skip spaces at start and end of string anyway
[18:23] <nevcairiel> so shouldnt be issues with other systems, one can hope
[18:23] <nevcairiel> i mean, other filters must have similar parsing
[18:23] <Daemon404> indeed
[18:23] <Daemon404> but... we have fate!
[18:24] <nevcairiel> should probably remove all stray spaces around sscanf
[18:26] <Daemon404> nevcairiel, what do i even do about skip_space
[18:26] <Daemon404> s
[18:26] <saste> uhm maybe i'll rename pixfmt2fourcc to fourcc2pixfmt
[18:27] <saste> so that will stay close to fourcc2codec if we ever implement that
[18:28] <nevcairiel> Daemon404: that one is actually no problem, i tried various combinations and it works
[18:28] <Daemon404> i see
[18:28] <nevcairiel> one thing i dont understand
[18:28] <nevcairiel> sscanf(arg, " %lf %n* %n", &gain, &len, &len)
[18:28] <Daemon404> theres a shitload of sscanf with spaces and %n in af_pan
[18:28] <nevcairiel> wth is with the double len?
[18:28] <Daemon404> i dont know at all
[18:29] <nevcairiel> also, i only know %*n as a format structure, is %n* of any significance?
[18:30] <Daemon404> i know what * does, but it doesnt make any more sense
[18:30] <Daemon404> im also unsure which sscans i should change
[18:30] Action: Daemon404 hates this stuff
[18:30] <nevcairiel> at least the two in parse_channel_name
[18:30] <Daemon404> yea
[18:30] <Daemon404> i removed the leading space too
[18:31] <Daemon404> since sscanf shoudl skip it
[18:31] <nevcairiel> no idea wth is up with the gain one i just quoted
[18:31] <Daemon404> yeah
[18:31] <Daemon404> ill cc nicolas on the patchset
[18:31] <Daemon404> *wish* he used itc
[18:31] <Daemon404> irc
[18:33] <nevcairiel> i think there needs to be a additional skip_spaces if you make parse_channel_name no longer consume it
[18:33] <nevcairiel> i smell bikeshed
[18:34] <nevcairiel> i think i know what the gain line is about
[18:34] <nevcairiel> the * is optional
[18:36] <nevcairiel> to avoid any issues it should be "%lf%n *%n"
[18:37] <Daemon404> nevcairiel, can you mak a patch
[18:37] <Daemon404> this is quickly becoming convoluted to me
[18:37] <nevcairiel> heh
[18:38] <Daemon404> or well
[18:38] <Daemon404> ill try
[18:38] <Daemon404> you can review
[18:38] Action: Daemon404 runs
[18:40] <nevcairiel> http://pastebin.com/3a7Mvmn7
[18:40] <nevcairiel> this is what i would do
[18:40] <nevcairiel> needs some good explanation in the commit message though, or people will bitch to no end :p
[18:41] <Daemon404> kk
[18:41] <Daemon404> lukcily i just wrote one
[18:41] <Daemon404> :3
[18:45] <Daemon404> nevcairiel, sent
[18:46] <Daemon404> also ran fate
[18:46] <Daemon404> (on linux)
[18:47] <nevcairiel> i checked whole avfilter, and there are no other %n with a space in front, so much for that at least
[18:48] <nevcairiel> (except the one in skip_spaces, but because %n is the first format string in it, it doesnt trigger the bug)
[18:49] <Daemon404> yea
[19:43] <ubitux> michaelni: i'm again looking at http://ffmpeg.org/pipermail/ffmpeg-devel/2012-August/129884.html i almost forget
[19:43] <ubitux> and i'm wondering if the issue you mention isn't actually already present
[19:43] <ubitux> or maybe i'm missing something obvious?
[19:44] <ubitux> is the problem accessing ogg->streams[0], even though ogg->nstreams is 1?
[19:56] Action: Daemon404 pokes nevcairiel 
[20:01] <ubitux> Daemon404: jacosub is covered by fate
[20:01] <ubitux> Daemon404: make fate-sub-jacosub
[20:02] <ubitux> (see tests/fate/subtitles.mak)
[20:03] <Daemon404> ok
[20:03] <Daemon404> let me just spend 9 years building ffmpeg again
[20:03] <ubitux> you mean running the configure?
[20:03] <Daemon404> yes
[20:03] <Daemon404> lol
[20:13] <Daemon404> cia is dead again?
[20:22] <michaelni> topic in #cia "... current status: Thinking about long-term maintenance / replacing bits and pieces ..."
[20:23] <llogan> what is cia?
[20:24] <Daemon404> bot that spams commits
[20:24] <michaelni> bot that DID ...
[20:24] <cptspiff> your worst nightmare
[20:25] <llogan> oh. the bot...
[20:25] <llogan> we still have another spam bot
[20:25] <cptspiff> it will spam you in color!
[20:26] <llogan> i like it. nice to see carl's tracstorms
[20:26] <llogan> ...in color.
[20:43] <nevcairiel> Daemon404: one thing that puzzles me, when i compile with mingw, shouldnt it also use the ms crt sscanf? Maybe because all fates are wine it was never caught..?
[20:44] <Daemon404> no
[20:44] <Daemon404> mingw people are derpy
[20:44] <Daemon404> and teh reimpl'd some of teh msvcrt funcs
[20:44] <Daemon404> also yes they are all wine
[20:55] <Daemon404> ubitux, ping
[20:56] <ubitux> pong
[20:56] <Daemon404> all the sub fate tests fail
[20:56] <Compnn> Daemon404 : you found svq3 in avi ?
[20:56] <Daemon404> do any of them use vsnprintf
[20:56] <Daemon404> Compnn, yes
[20:57] <Compnn> yuck
[20:57] <Compnn> :P
[20:57] <Daemon404> ;p
[20:57] <Compnn> do you have commit access ?
[20:57] <Compnn> wondering why you make patches for such things...
[20:57] <ubitux> Daemon404: a lot use bprintf, and all use the ass muxer
[20:57] <Daemon404> ffmpeg git repo? yes
[20:57] <Daemon404> Compnn, i do not believe in pushing without review
[20:57] <Daemon404> ubitux, so that could be why
[20:58] <ubitux> Daemon404: also, there are a lot of sscanf
[20:58] <Daemon404> yes
[20:58] <Daemon404> well i just wrote a proper vsnprintf/print fix
[20:58] <Daemon404> so ill apply and test it
[20:58] <Daemon404> :)
[20:59] <ubitux> don't miss your fix
[21:00] <nevcairiel> sscanf would most likely just crash when its hitting the same bug
[21:00] <ubitux> or you'll have to wait 9 additionnal yrs
[21:00] <Daemon404> nevcairiel, yea
[21:02] <Daemon404> make fate-bprint passes now
[21:02] <Daemon404> so do all the sub tests
[21:02] <Daemon404> :)
[21:06] <ubitux> \o/
[21:06] <ubitux> Daemon404: so even jacosub works?
[21:09] <Daemon404> ubitux, yea
[21:09] <ubitux> that's surprising
[21:13] <ubitux> Daemon404: you should protect against double inclusion in compat/va_copy.h
[21:15] <michaelni> ubitux, the ogg issue with the patch _IIRC_ was that the stream number could increase after the patch but things between lavf and ogg contexts could become inconsistent
[21:15] <michaelni> through save+restore
[21:15] <michaelni> that is save+increse+restore
[21:16] <michaelni> that is IIRC
[21:16] <ubitux> well the code creating a new stream is already present
[21:17] <ubitux> i'm going to try to understand better the demuxer anyway
[21:18] <michaelni> the demuxer is convoluted
[21:21] <michaelni> before your patch the stream adding case is limited to headers==0 
[21:21] <Daemon404> ubitux, might not need that if we end up doing -FI
[21:23] <michaelni> afterwards it can be triggered with the right flags stored in the file i think
[21:23] <ubitux> oh, right.
[21:24] <Daemon404> w00t
[21:24] <Daemon404> after the vsnprintf + bprint patches
[21:24] <Daemon404> make works cleanly in ffmpeg under msvc
[21:25] <nevcairiel> and fate passes? :p
[21:25] <Daemon404> thats waiting on the af_pan patch
[21:25] <Daemon404> and vsynth2-mpng fails
[21:25] <Daemon404> but vsynth1-mpng doesn't
[21:25] <nevcairiel> different hashes, or how fail?
[21:25] <Daemon404> diff hashes
[21:25] <ubitux> Daemon404: do you mind looking at why jacosub test actually works with the sscanf?
[21:26] <Daemon404> but it uses zlib... and encoding zlib is non-deterministic
[21:26] <Daemon404> diff systems == diff compress
[21:26] <nevcairiel> how stupid for a fate test
[21:26] <Daemon404> thats why i am against using encoder tests with zlib
[21:27] <Daemon404> it it's probably because i used the MASM asm for zlib
[21:27] <nevcairiel> isnt that what we all use?
[21:27] <Daemon404> well it's specific to windows
[21:27] <Daemon404> so it may produce different results
[21:27] <Daemon404> because zlib is cool like that
[21:29] <ohsix> have you just observed that it is, or has someone said somewhere that that's true and expected, given the same stream of bytes it should have the same encoding
[21:29] <Daemon404> ohsix, it is NOT expected that zlib on different systems and different xlib versions produce teh same stream from deflate()
[21:29] <Daemon404> this is documented and well tested
[21:30] <ohsix> changelog entries from 1995 sez "make deflate deterministic"
[21:30] <ohsix> then again in 1996
[21:31] <Daemon404> its deterministic yes
[21:31] <Daemon404> on the same system
[21:31] <Daemon404> and version,a nd binary
[21:31] <Daemon404> it will always produce the same
[21:31] <Daemon404> but not on diff arch/system/version
[21:31] <nevcairiel> a pure C compile will most likely on diff systems too
[21:31] <ohsix> ya, i'm asking for documentation
[21:31] <Daemon404> ohsix, years of seeing that this is the case
[21:31] <Daemon404> i dont expect zlib documented it themselevs
[21:31] <ohsix> heh
[21:32] <ohsix> for that sort of thing it'd be considered quite a bug to have different output
[21:32] <nevcairiel> as long as inflate(deflate(..)) is consistent, who cares
[21:32] <Daemon404> inflate is consistent
[21:32] <Daemon404> obviously
[21:33] <michaelni> is that mpng test using compression=0 ? if not that could be tried
[21:33] <ohsix> does the dictionary size or any of the compression  parameters change based on the arch?
[21:34] <Daemon404> ohsix, i think it;s mostly a version thing
[21:34] <Daemon404> not arch
[21:34] <ohsix> right, but that'd be a bug
[21:34] <Daemon404> changes to the compression algo to compress better
[21:34] <Daemon404> etc
[21:34] <Daemon404> it's nto a bug.
[21:34] <ohsix> ehh they don't change the algorithm
[21:34] <Daemon404> the tweak things sometimes
[21:34] <Daemon404> not in teh core algo probably
[21:35] <ohsix> like what? the dictionary is a set of probabilities
[21:35] <Daemon404> i cant tell you WHY
[21:35] <ohsix> all you do is inject bias or whatever, but there's no point in doing that when you can add a transform that makes it compress better (and would still be deterministic)
[21:35] <Daemon404> i can only tell you that it is 100% true that it differs betwen versions
[21:35] <ohsix> ok
[21:36] <ohsix> i'm not arguing with that, i was just looking for some documentation to that effect, cuz i'd sooner presume something was wrong, they are supposed to be determinisitic with the same input (and parameters, which may change based on the arch)
[21:37] <Daemon404> either way, id rather fix fate than fix xlib
[21:37] <Daemon404> zlib*
[21:37] <Daemon404> (ive fixed xlib in teh past and :pain:)
[21:37] <ohsix> one is definitely broke though :]
[21:38] <ohsix> think of it as a state machine, for it to produce a different output one of the internal states would have to transition differently for the same circumstances (byte stream)
[21:38] <ohsix> if any of those changes are based on the arch, that's well and good; but there's no reason to even do that
[21:38] <ohsix> documentation to that effect would confirm both
[21:39] <ohsix> it's more likely the software calling zlib sets up compression parameters differently based on the arch
[21:40] <Daemon404> ffmpeg most certainly does not/
[21:42] <nevcairiel> I'm still with the difference being in asm somewhere
[21:43] <ohsix> if it was, the output would be wrong
[21:43] <nevcairiel> why
[21:43] <ohsix> there's literally nothing to change
[21:44] <nevcairiel> as long as it decompresses everywhere to the same thing
[21:44] <ohsix> does it? there's nothing complex going on
[21:45] <ohsix> http://tools.ietf.org/html/rfc1951
[21:45] <nevcairiel> it uses huffman coding, maybe it just happens to sort the symbols slightly differently
[21:46] <ohsix> the only source of nondeterminism that i've seen in there so far is the "compressor's block buffer", since that can triger a flush at different periods and that ends up regenerating tables sometimes
[21:46] <ohsix> you don't get different huffman tables for the same data based on some funny math, or integer roundingf
[21:47] <ohsix> the decision when a new tree is "beneficial" could be different, i suppose
[21:49] <ohsix> oh well, i'd still treat it as a bug until i found out what it was, even if there weren't tests depending on it
[21:51] <ohsix> otherwise you just end up testing what the assembly does
[22:11] <Daemon404> nevcairiel, do you manually call like: C:\msys\1.0\bin\sh.exe C:\path\to\fate.sh C:\path\to\config.cfg ?
[22:12] <nevcairiel> i have msys in path
[22:12] <nevcairiel> but otherwise, i guess
[22:12] <Daemon404> cause i was gonna have all my env var stuff set up in bash itself
[22:12] <Daemon404> source /devel/buildenv
[22:12] <Daemon404> then call fate.sh
[22:15] <michaelni> cia :)
[22:15] Action: michaelni hugs CIA-57 
[22:15] Action: CIA-57 hugs michaelni
[22:16] <Daemon404> i really hope thats automated
[22:33] <gnafu> Daemon404: Didn't you know?  All CIA "bots" are actually people using Amazon Mechanical Turk.
[22:34] <gnafu> CIA-57 is a /human being/, for goodness sake.  Show some respect!
[22:34] Action: Daemon404 apologizes to CIA-57 
[22:44] Action: Compnn slaps CIA-57
[22:44] <Compnn> or is it
[22:44] Action: Compnn kicks CIA-57
[22:44] <CIA-57> ow
[22:44] <Compnn> hehe
[22:45] <gnafu> CIA is made of people!  PEEEEOPLE!
[22:45] <CIA-57> ffmpeg: 03Michael Niedermayer 07master * re2d643efcd 10ffmpeg/libavformat/utils.c: 
[22:45] <CIA-57> ffmpeg: lavf/compute_pkt_fields: only run pts by duration correction if reference ts is available
[22:45] <CIA-57> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:46] <CIA-57> ffmpeg: 03Derek Buitenhuis 07master * rfef412a24d 10ffmpeg/libavformat/riff.c: 
[22:46] <CIA-57> ffmpeg: riff: Add SVQ3 fourcc
[22:46] <CIA-57> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:46] <CIA-57> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:46] <ubitux> gnafu: that's why it's so much fun to kick it
[22:47] Action: Daemon404 waits patiently for fate...
[22:47] <Daemon404> so far only 2 failures
[22:47] <Daemon404> both expected
[22:47] <Compnn> <Daemon404> Compnn, i do not believe in pushing without review
[22:47] <Compnn> bah, wheres the fun in that?
[22:48] <Daemon404> it's called development methodology
[22:48] <Daemon404> good*
[22:54] <gnafu> PUSH BROKEN CODE [Insanity Wolf] ON PURPOSE
[22:57] <Daemon404> ubitux / nevcairiel -- http://chromashift.org/fate.txt 
[22:57] <Daemon404> only 2 failures
[22:58] <Daemon404> both may be zlib related
[22:58] <nevcairiel> something else must be wrong with your mpng, psnr changes widly
[22:58] <Daemon404> yeah
[22:58] <Daemon404> i bet its teh same thing thats wrong with lavf-png
[23:00] <Daemon404> let me inspect teh output
[23:05] <Daemon404> i cant visually see anything wrong with the lavf test
[23:06] <Daemon404> maybe a decoder issue
[23:07] <ubitux> :)
[23:10] <saste> michaelni, ping on [PATCH] lavc: add duration field to AVFrame
[23:10] <Daemon404> he
[23:10] <Daemon404> decocers fine
[23:10] <Daemon404> :|
[23:10] <Daemon404> decodes*
[23:11] <saste> what happened to the CIA bot?
[23:11] <nevcairiel> the bot has been unstable for a while now
[23:13] <Daemon404> i may have to ask for help, re: png
[23:15] <CIA-57> ffmpeg: 03Stefano Sabatini 07master * r8bdba0b3e9 10ffmpeg/ (libavcodec/Makefile libavcodec/raw.c tools/fourcc2pixfmt.c): tools: move raw-test program to tools, with the name fourcc2pixfmt
[23:23] <michaelni> Daemon404, did you try disabling asm for png ?
[23:24] <Daemon404> ill do a no asm build i guess
[23:32] <michaelni> saste, about AVFrame duration, its a bit redundant with repeat_pict, also make sure that it works with mpeg2 repeat 1 field per frame stuff
[23:32] <saste> michaelni, ok
[23:34] <iive> it is quite interesting that the CIA bot becomes unstable when the middle east becomes unstable... :O
[23:42] <beastd> saste: hi
[23:42] <saste> beastd, hi
[23:43] Action: beastd will reroll segment patches
[23:44] <saste> beastd, while at it, csv escaping code was copied from ffprobe.c, that could be simplified as well
[23:44] <Daemon404> segment = ?
[23:44] <saste> even if i vaguely  remember that i considered and discarded that approach when writing the escaping code the first time
[23:45] <Daemon404> you dont mean mp4 segments do you?
[23:45] <beastd> saste: yes, i just read you copied it from there
[23:45] <beastd> Daemon404: no, no. just some feature to export lists with the segment info from the segement muxer
[23:46] <Daemon404> o
[23:46] <Daemon404> oj
[23:46] <Daemon404> ok
[23:57] <Daemon404> michaelni, disabling asm doesnt help
[00:00] --- Sat Sep 15 2012