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

[burek]

[00:00] <michaelni> or require a full match till strlen and feed it a string thats just up to to :
[00:05] <saste> michaelni, or just force the user to specify 123x456
[00:05] <saste> that syntax is useful, if you force just the use of abbreviation you're reducing the usefulness
[00:06] <michaelni> hmm
[00:06] <michaelni> true
[00:06] <michaelni> but
[00:06] <michaelni> i think av_parse_video_size() needs then more fixes than just the "x" check
[00:06] <saste> i'd also add an s/size option, for who prefer a more robust/predictable behavior
[00:07] <michaelni> saste, can i request that you call it "insane" instead of "robust" in the commit message ? ;))))
[00:07] <saste> it currently is: INT GENERIC_CHAR INT
[00:08] <saste> michaelni, more "working" versus "non-working" ;-)
[00:08] <michaelni> and it will succeed on 123x345+sin(alpha) i fear 
[00:08] <durandal_1707> mplayer asf demuxer + binary codecs decodes mss2 fine while any other combination does not
[00:09] <saste> michaelni, yes it will
[00:09] <saste> extending av_parse_video_size() would be an option, but how much is it worth it?
[00:09] <saste> while at it we could add logging, but again that would complicate the interface
[00:09] <saste> so you can't have everyone happy
[00:10] <michaelni> I think checking the middle char and the end in av_parse_video_size() is a good idea indepedant of vf_scale
[00:10] <michaelni> and once thats done it probably can be used
[00:10] <michaelni> in vf_scale
[00:11] <saste> what should be middle char be?
[00:11] <michaelni> we could allow multiple 
[00:11] <saste> docs states "w x h"
[00:11] <saste> so it is more restrictive than the implementation
[00:14] <michaelni> I think it should also allow upper case X and : and possibly ,;
[00:14] <michaelni> but thats bikeshed a bit
[00:15] <saste> should it be documented?
[00:16] <michaelni> hmm thats a good question
[00:16] <saste> but then in order to accept 123x345+sin(alpha) you need to parse the string
[00:16] <saste> so it's more than 1 line of code
[00:17] <saste> i hope you see why i tend to dislike ad-hoc rules...
[00:17] <michaelni> you misunderstood that comment from me
[00:17] <michaelni> i meant with this just that it lacks end checking not that i suggest that we support this
[00:17] <saste> ok
[00:18] <michaelni> -vf adhoc=make-coffee
[00:18] <saste> filtered coffee
[00:18] <michaelni> lol
[00:20] <saste> allright, enough bikeshedding for today, i'll sleep on it and try to get some real work starting from tomorrow
[00:20] <michaelni> ok, thx
[00:21] <michaelni> and good night :)
[00:21] <saste> thank you :)
[00:28] <durandal_1707> Daemon404: you dont free allocated memory?
[00:29] <Daemon404> durandal_1707, thank you for useless input
[00:29] <Daemon404> thats kind of exactly what it says
[00:29] <Daemon404> find_info was leaking mem
[00:30] Action: Daemon404 was asking for -why-
[01:05] <cone-856> ffmpeg.git 03Leon van Stuivenberg 07c5be6192f0a5: cmdutils: avoid using cpp directives within printf macro arguments
[03:27] <cone-856> ffmpeg.git 03Michael Niedermayer 07224afddc7c86: ismindex: check return value of avio_open_dyn_buf()
[03:27] <cone-856> ffmpeg.git 03Michael Niedermayer 07b399816d9c3d: smoothstreamingenc: fix integer overflow
[06:18] <cone-856> ffmpeg.git 03Michael Niedermayer 07a3886ea3c594: smoothstreamingenc: check return value of mkdir()
[06:18] <cone-856> ffmpeg.git 03Michael Niedermayer 07b4e6265136dd: dcadec: skip QMF on unused channels
[09:27] <ubitux> nyuhu: any reason the random state is re-initialized at each frame in histeq?
[09:58] <ubitux> "This patch is one of a few changes that are needed to get ffmpeg
[09:58] <ubitux> compiling with gcc 3.0.3 on PS2Linux"
[09:58] <ubitux> haha :)
[10:07] <TimNich> they will be wanting Rasberry Pi next...
[10:07] <nevcairiel> should already compile for rasberry pi
[10:08] <nevcairiel> i just wouldnt try compiling it "on" rasberry pi, it would probably take a day or two
[10:08] <TimNich> Quite...
[10:09] <ubitux> nevcairiel: what? gcc isn't using the gpu? :o
[10:10] <TimNich> So why not compile *for* PS2 instead of on it...
[10:10] <TimNich> gnu gncpu?
[10:12] Action: TimNich remembers he was supposed to be making toast&
[10:37] Action: TimNich ahhhh thats better
[10:40] <ubitux> :)
[10:44] <JEEB> eh, is the unofficial PS2 devkit that old :<
[10:44] <JEEB> @ gcc 3.0.3
[10:45] <JEEB> the PSP cross-toolchain is 4.6.x
[11:06] <nyuhu> ubitux : well, this is what the original VDub code is doing so&
[11:08] <ubitux> ok ok
[11:54] <ubitux> is there any reason fft/rdft/dct code is only used for audio?
[11:54] <ubitux> i don't see a single video application of this code
[11:57] <saste> ubitux: i'm pushing the quote/escaping patch
[11:58] <ubitux> okay... :p
[11:58] <cone-201> ffmpeg.git 03Stefano Sabatini 077d1e003abddf: doc/syntax: add a "Quoting and escaping" section
[11:58] <saste> i tested HTML locally and it looked fine
[11:59] <ubitux> and manpage?
[11:59] <saste> btw the local embedded CSS is the same of the Libav website, which is much nicer than FFmpeg's
[11:59] <ubitux> yes, you need to ask michaelni to update the site
[12:00] <saste> man looks fine after the texi2pod fix
[12:00] <ubitux> or well, make use what's on the repo
[12:00] <saste> ubitux: lou logan was interested in working on that
[12:00] <ubitux> great, because i'm not
[12:00] <saste> and we shouldn't copy the Libav style imho
[12:00] <saste> for several reason
[12:00] <saste> but we can borrow some of the ideas
[12:00] <ubitux> i think it's safe to copy what's in the repository
[12:00] <saste> for example header boxes are *ugly*
[12:00] <ubitux> (from a legal PoV)
[12:01] <ubitux> yeah sure, feel free to improve this
[12:01] <saste> not if you want to clarify that they are two distinct projects
[12:01] <ubitux> i don't want to touch that anymore :p
[12:01] <saste> also we had the design of herve flores, which we never considered
[12:02] <saste> but anyhow, just a few changes would improve the overall aspect
[12:06] <saste> ubitux: how was the mingw path things fixed?
[12:08] <nevcairiel> it wasnt, i changed my fate box to use a relative path
[12:41] <Compn> ubitux : no, rather not copy from libav, plus they dont have license anywhere in their xml source 
[12:41] <Compn> neither do we iirc
[12:42] <Compn> i'd rather we get some new xml/html and stop looking like that project too
[12:42] <Compn> but is my personal opinion, i cant speak for everyone
[12:43] <durandal_1707> ubitux: no copy
[12:53] <ubitux> durandal_1707: are you replying to my fft/rdft/dct question?
[12:54] <durandal_1707> no
[12:54] <durandal_1707> but web page stuff
[13:08] <ubitux> Compn, durandal_1707: i wasn't talking about the website
[13:08] <ubitux> but the style in the ffmpeg repository
[13:08] <ubitux> which is used for generating documentation
[13:35] <cone-201> ffmpeg.git 03Martin Storsjö 0748f01398ba30: rtpdec: Cosmetic cleanup
[13:35] <cone-201> ffmpeg.git 03Anton Khirnov 07f174fbac3cb1: lavc: add CODEC_CAP_DR1 to all video decoders missing them
[13:35] <cone-201> ffmpeg.git 03Michael Niedermayer 0767420b3de502: Merge remote-tracking branch 'qatar/master'
[13:42] <durandal_1707> so nobody cares about atrac3+?
[13:43] Action: av500 does not
[14:36] <durandal_1707> ahh
[14:52] <nevcairiel> who broke my fate?
[14:53] Action: av500 never had one
[14:57] <ohsix> i dunno how that stuff works :]
[14:58] <ohsix> doing that to have / in a loop file is going to be tough anyways
[14:59] <ohsix> have you looked into how fedora/debian/ubuntu does it in their livecd images? might not be the greatest example, since they get to cheat unmounting on read only media :D
[15:28] <ohsix> oh man, aborts shouldn't be in a library; there's no way for the host to handle them
[15:28] <ohsix> there's no "if you can trigger it" about it
[15:29] <saste> ohsix: same for a crash
[15:29] <ohsix> except you don't call crash()
[15:29] <ohsix> in some circumstances
[15:30] <ohsix> or maybe you do, i dunno :]
[15:31] <saste> abort just guard an unexpected condition
[15:31] <saste> it aborts (and gives a few hints) before to do wicked things, like a buffer overrun
[15:31] <ohsix> so it will crash if it's going to abort?
[15:31] <saste> it spots a programming error, so it should be fixed, cannot be handled
[15:31] <divVerent> well, abort() is probably ok to call if stuff ALREADY is corrupted
[15:31] <divVerent> so there is no way to recover
[15:32] <divVerent> basically, abort() is ok if the code would crash ANYWAY :P
[15:32] <ohsix> programming error by whom, and is it api
[15:33] <ohsix> usability as a library should be a pretty high concern
[15:33] <divVerent> let me say the abort() in sctp_write is certainly a bad one :P
[15:34] <ohsix> uh-uh
[15:34] <ohsix> wontfix all up in your grille
[15:35] <divVerent> because this one maybe can even be triggered using ffmpeg command line binary
[15:35] <divVerent> by setting max_streams in the URL, but not writing a stream prefix
[15:35] <divVerent> that one really should rather return an error code
[15:35] <ohsix> auditing all the ways abort can be triggered is a waste of time outside a case-in-point, you don't actually want to support its usage at all :p
[15:35] <divVerent> ohsix: wrong
[15:35] <divVerent> hint: glibc uses abort() too
[15:36] <divVerent> if free() discoveres corrupted pointer chains
[15:36] <ohsix> programs that scribble on the heap aren't exactly going to be working very well
[15:36] <divVerent> that is the kind of situation abort() is good for
[15:36] <divVerent> exactly
[15:36] <divVerent> call abort() to handle something "better" that would otherwise crash irrecoverably
[15:36] <divVerent> mainly to help tracking it down easier
[15:37] <ohsix> and besides tracking heap integrity, does it do it anywhere else?
[15:37] <divVerent> no idea
[15:37] <divVerent> libavcodec/bitstream.c uses abort() needlessly too
[15:37] <divVerent> this rather should be a nasty spammy log message and return -1
[15:38] <divVerent> mpegvideo.c's abort() is currently ok
[15:38] <divVerent> because it does catch something that would otherwise crash earlier
[15:38] <ohsix> a scribbled heap isn't much different for junk you'd get kill()'d with
[15:38] <divVerent> *crash later
[15:39] <ohsix> (sigsegv, fpe, bus)
[15:39] <divVerent> vp8.c's abort() is ok to me too, but it's a situation that can probably be proven to never happen at all
[15:39] <ohsix> unless of course you set up your environment to trap them and then do it deliberately \m/
[15:40] <divVerent> the code is somewhat "unclear", but I am prettty sure unless vp8_release_frame is broken, it can never occur
[15:40] <divVerent> this abort() basically catches a possible sigsegv if another function is broken
[15:41] <divVerent> and mpegvideo.c's abort() is justified, but probably should be fixed in a better way
[15:41] <divVerent> so basically, we're down to two abort()s of four that can be easily removed
[15:41] <divVerent> one that should be
[15:41] <divVerent> but is not easy at all
[15:41] <ohsix> they should all be removed, they're in a library
[15:41] <divVerent> and one that can stay there because we can prove it can'
[15:41] <divVerent> t be hit
[15:41] <Compn> durandal_1707 : kostya might care re atrac3+ , or maxsim, or whoever was working on it
[15:41] <divVerent> ohsix: wrong
[15:41] <divVerent> the issue is
[15:42] <divVerent> the one remaining one in vp8.c
[15:42] <divVerent> read the code, it can't happen currently
[15:42] <divVerent> but if someone else makes a mistake in the function called
[15:42] <divVerent> the abort() then serves to yield a better error than what would happen otherwise
[15:42] <divVerent> namely, a segv
[15:42] <divVerent> also
[15:42] Action: Compn wonders why on2 / google didnt make ffmpeg the reference en/decoder of vp8 in the first place
[15:42] <divVerent> just compile with -DNDEBUG
[15:42] <ohsix> so remove all the segvs too
[15:42] <divVerent> then assert()s are all removed
[15:42] <divVerent> ohsix: I explained it
[15:43] <Compn> probably lgpl license
[15:43] <divVerent> it's very hard to fix the mpegvideo one
[15:43] <divVerent> try sending a patch to fix this one :P
[15:43] <divVerent> also, find a good suggestion for the vp8.c one
[15:43] <divVerent> abort() is still better than stuff like
[15:43] <divVerent> else { /* can't happen */ }
[15:44] <divVerent> but the mpegvideo abort() is actually a bug, or rather, guards against a worse bug on same situation
[15:44] <ohsix> i don't even need or want to read it, it's not unlike a situation where you can avoid using a goto, or other langauge structure; it's a matter of the shape not the function, if you've painted yourself into a corner and abort() sufficies vs. refactoring then that abort might survive for a long time
[15:45] <divVerent> ohsix: that's kind of the situation in mpegvideo.c
[15:45] <ohsix> libraries shouldn't really be setting signal handlers or messing with the signal mask either
[15:45] <divVerent> it could even require a rewrite to fix the segfault the abort() "catches" earlier
[15:45] <divVerent> this abort() actually really annoys me too
[15:45] <ohsix> i wasn't disagreeing, i was just saying i'm not going to read it :]
[15:45] <divVerent> as the comment around it indicates that an invalid mpeg stream can cause it
[15:45] <divVerent> which means user/network input
[15:46] <divVerent> the other three can only happen a) not at all, or b) from bad API use
[15:46] <ohsix> you know what's really fun, when you use more than one library that does all these fun things
[15:46] <divVerent> and as for bad API use
[15:46] <divVerent> you can cause it to crash for bad API use by other ways too
[15:46] <divVerent> e.g. pass NULL :P
[15:47] <divVerent> ohsix: also, there's actually way MORE abort()s in ffmpeg :(
[15:47] <divVerent> I just saw that lots of assert() calls exist
[15:47] <divVerent> and these are basically abort()
[15:47] <ohsix> unless you are going to make everything not crash from misuse it's not worth worrying about; unless the documentation fails, or people don't really know the constraints of a function anyways
[15:47] <divVerent> what makes it even worse, snowenc.c even does #undef NDEBUG
[15:47] <ohsix> asserts are fine, you have to build with them enabled :]
[15:47] <divVerent> so there is no way to ground these asserts
[15:47] <divVerent> haha
[15:47] <divVerent> nope, snowenc.c sabotages that
[15:47] <divVerent> and it's the first file with asserts I checked
[15:48] <divVerent> vorbisenc.c does the same
[15:48] <divVerent> that I find a lot worse than the abort()s you mentioned
[15:48] <ohsix> asserts are pretty decent as documentation even, depending on how you split functions up
[15:48] <divVerent> ohsix: sure
[15:48] <divVerent> also, the four abort()s we have can easily be turned into asserts :P
[15:49] <divVerent> just that's not making them any better in terms of use by a library
[15:49] <durandal_1707> if abort happens because of input data it is bug and should be properly documented, removing all asserts is wrong
[15:49] <durandal_1707> s/documented/fixed
[15:49] <divVerent> durandal_1707: sort of wrong
[15:49] <divVerent> durandal_1707: it is a bug, with or without the assert/abort
[15:50] <divVerent> and needs fixing anyway (and be it by invalidating the decoder status and ending the stream)
[15:50] <durandal_1707> i said that
[15:50] <divVerent> ok then :)
[15:50] <divVerent> the final state should be not using ANY abort(), keep using assert(), but have NDEBUG properly remove the asserts
[15:51] <ohsix> might end up with api changes to remove them all, it really has to be done with the library task in mind
[15:51] <saste> uhm now i realize i was confusing abort with assert...
[15:51] <saste> yes abort are not very nice and should be avoided
[15:51] <durandal_1707> divVerent: av_assert0 is always enabled for the reason
[15:51] <divVerent> durandal_1707: for no good reason ;) it's sort of a temp workaround, no more and no less
[15:51] <durandal_1707> if reason is frong, seend potch that fix it
[15:52] <divVerent> there's thousands of these... it looks more like a lost cause
[15:52] <durandal_1707> divVerent: whatever, i trolleed enough, now going to do some real work
[15:52] <divVerent> sure :P
[15:53] <divVerent> and I think we all agree they need eventually be fixed, but that it is hard work to fix them all
[15:53] <divVerent> ohsix: BTW, a small hint...
[15:53] <divVerent> ffmpeg tends to merge from libav, but libav not from ffmpeg
[15:53] <divVerent> so it may help to rather make libav do the get-rid-of-assert/abort work
[15:53] <durandal_1707> wtf, did lavu major get recently bumped?
[15:54] <divVerent> that way it helps both projects, and not one
[15:54] <durandal_1707> divVerent: you want to remove all asserts?
[15:54] <divVerent> durandal_1707: long term? yes
[15:54] <divVerent> but probably impossible :P
[15:54] <durandal_1707> asserts are there to guard against cases which should not happen at all
[15:54] <divVerent> basically, categorize them into "can't happen unless code is buggy" (these can be disabled by NDEBUG then and stay there for documentation/debugging)
[15:54] <ohsix> dunno
[15:55] <divVerent> and into "can happen due to bad input" (these need actual fixing)
[15:55] <durandal_1707> if assert happens, please fill bug report for specific line of code that triggers it
[15:55] <ohsix> can't happen unless space rays
[15:55] <divVerent> durandal_1707: I don't have a test case, but the mpegvideo.c one has a comment that tells it can happen due to bad input
[15:55] <divVerent> comment may be outdated though ;)
[15:57] <divVerent> or DOES the decoder already check for stream validity in this sense? then the comment should rather be "Plus, the decoder checks stream validity..."
[15:57] <divVerent> instead of "Plus, the decoder has to check stream validity..."
[15:57] <divVerent> durandal_1707: for the sctp.c I may be able to make a test case
[15:57] <divVerent> what ffmpeg commands take URLs?
[15:58] <divVerent> and write to them
[15:58] <divVerent> other than the output file arg for which I am 100% sure without even checking that it handles the num_streams right
[15:59] <divVerent> this abort() can be caused by setting the max_streams argument but using writing code not aware of that
[16:15] <divVerent> durandal_1707: yes, I can cause the sctp abort()
[16:15] <divVerent> ./ffmpeg -f lavfi -i "life [out0]" -f nut "sctp://127.0.0.1:1234?listen=1&max_streams=42"
[16:15] <divVerent> plus
[16:15] <divVerent> withsctp nc 127.0.0.1 1234
[16:16] <divVerent> the problem is simply that max_streams is an option that shouldn't be exposed to the user, but only the calling code
[16:16] <divVerent> so calling code having use for a multi-stream connection can use it
[16:16] <divVerent> but here, the user is allowed to specify the stream count without the caller being aware of a multi stream socket
[16:17] <durandal_1707> fill bug report so it does not get lost
[16:18] <divVerent> ok
[16:30] <divVerent> there you go
[16:30] <divVerent> hm... when does it spam my ticket here
[16:32] <divVerent> no idea if any e.g. browser extensions exist that use ffmpeg to access the digital camera, and apply same-origin policy for destination... appending ?max_streams=1 would still meet the same-origin policy and thus be accepted
[16:32] <divVerent> *a webcam
[16:33] <divVerent> that'd be one case where the abort() could be remote controlled
[17:31] <cone-820> ffmpeg.git 03Tim Nicholson 078a9b48bfa915: movenc: Add required 'prof' atom to 'tapt' atom set.
[17:39] <durandal_1707> dr1 changes causes DR1 with mplayer to output nonsense
[17:45] <cone-820> ffmpeg.git 03Stefano Sabatini 0783938c3d4cb7: lavfi/scale: accept named options, make parsing more robust
[17:45] <cone-820> ffmpeg.git 03Stefano Sabatini 07c2428ada71af: lavfi/scale: return error code in case of failed reconfiguration in start_frame()
[17:45] <cone-820> ffmpeg.git 03Stefano Sabatini 07adf0cd145680: doc/filters: itemize scale examples, and create a dedicated subsection for them
[17:45] <cone-820> ffmpeg.git 03Stefano Sabatini 07d4604d10fe72: lavu/parseutils: add trailing characters check in av_parse_video_size()
[17:45] <cone-820> ffmpeg.git 03Stefano Sabatini 0719add3224f1e: lavfi/scale: implement clever/insane parsing heuristic, and add a size option
[17:49] <ubitux> would be nice to have a keep aspect ratio flag/option now :)
[17:50] Action: ubitux looks at divVerent 
[17:57] <michaelni> durandal_1707, which decoder?
[17:58] <michaelni> also the ones that fail in mplayer after the DR1 addition, likely do not support DR1 and should have the flag removed again
[18:04] <saste> what's the correct way to mark windows code?
[18:04] <saste> #ifdef _WIN32 ...
[18:04] <saste> __WIN32 is another option
[18:10] <saste> we have both WIN32 and _WIN32, and __WIN32 in the rogerdpack frei0r patch
[18:10] <saste> i wonder what's the more "correct"
[18:13] <Daemon404> saste, the correct solution is probably not tohave ifnedfs at all
[18:13] <Daemon404> er, ifdefs
[18:14] <saste> well in that case the code depends on the platform, so it seems correct
[18:14] <saste> frei0r.dyne.org/codedoc/html/group__pluglocations.html
[18:14] <Daemon404> shouldnt frie0r have a way to handle this
[18:15] <saste> dunno, but that's also the typical way to deal with path lists in Windows
[18:53] <cone-820> ffmpeg.git 03Stefano Sabatini 077691860c7374: lavfi/frei0r: update link to spec
[18:53] <cone-820> ffmpeg.git 03rogerdpack 07c1804dc4ce16: lavfi/frei0r: allow for Windows style paths
[20:06] <durandal_1707> ubitux: are there old fate coverate results?
[20:06] <ubitux> not anymore
[20:08] <durandal_1707> lol you generate unlimited number of blank reports
[20:08] <durandal_1707> what i need to run this?
[20:09] <Daemon404> ubitux, is there a way to ignore the last 2 channels of an 8 ch file
[20:09] <Daemon404> and downmix it as 5.1
[20:09] <Daemon404> (as in 5.1 -> 2 downmix)
[20:12] <durandal_1707> shouldn't that be doable in lavfi?
[20:14] <Daemon404> i think so
[20:14] <Daemon404> i just have no diea how.
[20:14] <durandal_1707> hmm maybe lavfi and samplerate combo
[20:16] <Daemon404> samplerate shouldnt come into play at all
[20:16] <durandal_1707> libswresample for downmix....
[20:21] <Daemon404> if the filter for downmixing
[20:21] <Daemon404> is called samplerate
[20:21] <Daemon404> that is a shitty name
[20:21] <durandal_1707> ubitux: and you remove all .gcno/.gcda files?
[20:22] <Daemon404> are you running gcov?
[20:22] <Daemon404> e,r lcov
[20:22] <durandal_1707> does it work with clang?
[20:22] <Daemon404> not properly, no
[20:22] <durandal_1707> so you actually got coverage results?
[20:24] <Daemon404> yes
[20:25] <Daemon404> with gcc
[20:25] <durandal_1707> Daemon404: so libswresample cant change channel layouts?
[20:25] <Daemon404> of course it can
[20:25] <Daemon404> but having channel mixing in a filter called samplerate is silly
[20:26] <Daemon404> resampling != mixing
[20:26] <durandal_1707> i never said something like that
[20:27] <Daemon404> [15:14] <@durandal_1707> hmm maybe lavfi and samplerate combo
[20:27] <Daemon404> >samplerate
[20:28] <durandal_1707> and you think samplerate is filter?
[20:28] <Daemon404> what else would it be
[20:28] <Daemon404> in that context
[20:29] <ubitux> <@durandal_1707> ubitux: and you remove all .gcno/.gcda files? // it runs from a fresh build each time so yes i believe
[20:30] <ubitux> durandal_1707: did you try it yourself?
[20:30] <durandal_1707> ubitux: trying right now....
[20:30] <Daemon404> ifr he's using clang, it wont work anyway
[20:30] <durandal_1707> michaelni: nice broken merge yet again
[20:30] <ubitux> Daemon404: yes that's possible, with pan & downmix
[20:31] <durandal_1707> and how do you do downmix?
[20:31] <ubitux> pick your channels with pan, and then request a stereo format with aformat after
[20:31] <Daemon404> ubitux, excellent
[20:32] <Daemon404> well for my purposes
[20:32] <Daemon404> i only need pan
[20:32] <Daemon404> i can downmix later
[20:32] <Daemon404> im worried that teh channel layout for the first 6 channels wont be preserved
[20:32] <ubitux> c0=c0:c1=c1:...
[20:32] <ubitux> or you can explicit it
[20:33] <ubitux> FL=FL:FR=FR:... or sth like that
[20:33] <ubitux> iirc
[20:34] <Daemon404> -af pan=c0=c0:c1=c1
[20:34] <Daemon404> like that?
[20:38] <ubitux> isn't the first parameter a channel layout or something?
[20:38] <ubitux> i think the documentation has good examples
[20:38] <ubitux> if you don't mind having a look :)
[20:39] <ubitux> http://ffmpeg.org/ffmpeg.html#Remapping-examples check these maybe
[20:40] <ubitux> it looks like you want something similar to the first example
[20:47] <Daemon404> ubitux, i was reading the filters.html doc
[20:47] <Daemon404> its kind of... hard to parse
[20:47] <durandal_1707> ugh, what?
[21:07] <cone-820> ffmpeg.git 03Paul B Mahol 0790510251027f: lavc: remove duplicated .capabilities
[21:14] <Daemon404> oh... i actually have 8 tracks with 1 channel
[21:14] <Daemon404> fun
[21:16] <llogan> Ede_123 in #ffmpeg wants to know what the standard logo is licensed as. anyone know?
[21:17] <llogan> for usage in Wikimedia Commons
[21:18] <Compn> it should be copyleft but mru made a copyright claim on it...
[21:18] <Compn> dunno what herve licensed his as 
[21:19] Action: llogan searches logs n' shit
[21:19] <Compn> llogan : try mailing herve
[21:20] <gnafu> Daemon404: wat.
[21:20] <Daemon404> welcome to broadcast
[21:21] <gnafu> DO NOT WANT.
[21:21] <Daemon404> ubitux, an i correct in thinkign -map_channel can only do stereo -> mono
[21:21] <durandal_1707> it is patented - do not use it until patent expires, which may be in 2077
[21:21] <Daemon404> and not 2 mono -> stereo
[21:21] <Compn> michaelni : btw did you ever reply to that lawyer with the copy of your hand drawn image with the zigzag ? lol
[21:22] <Daemon404> hmm yup
[21:22] <llogan> durandal_1707: don't worry, lobbyists will pay our (US) politicians to extend copyright more.
[21:23] <Daemon404> [Parsed_amerge_0 @ 0x2271100] Buffer queue overflow, dropping.
[21:23] <Daemon404> Segmentation faultepeated 12 times
[21:23] <Daemon404> yes
[21:23] <Daemon404> tried to amerge
[21:23] <Daemon404> segfault ffmpeg
[21:23] <Daemon404> \o/
[21:24] <durandal_1707> cmdline?
[21:24] <Daemon404> ffmpeg -i 124652995.mov.old -filter_complex "[0:7] [0:8] amerge" -c:a pcm_s16le -vn a.wav
[21:38] <llogan> Compn: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-May/112294.html
[21:38] <llogan> The author give all rights (for all supports - for all uses, commercial or not) to the "FFmpeg Project"
[21:39] <Compn> the ffmpeg project is not a legal entity btw
[21:39] <Compn> :P
[21:40] <ubitux> <@Daemon404> ubitux, an i correct in thinkign -map_channel can only do stereo -> mono // huh?
[21:41] <llogan> that's as far as he went with it, AFAIK, since he didn't name a specific license.
[21:47] <cone-820> ffmpeg.git 03Piotr Bandurski 07a29ed50ed735: avuidec: correct long_name
[21:47] <cone-820> ffmpeg.git 03Piotr Bandurski 07bf0d098a9886: pictordec: decode 1bpp / 4bpp images when extra header marker is missing
[21:54] <durandal_1707> Daemon404: that sample have multichannel audio?
[21:55] <Daemon404> no
[21:55] <Daemon404> it has 8 mono tracks
[21:57] Action: durandal_1707 wonders how to do same with aevalsrc
[22:17] <cone-820> ffmpeg.git 03Michael Niedermayer 07ba8adf9be5cb: truemotion2: remove unused variable
[22:17] <cone-820> ffmpeg.git 03Michael Niedermayer 0791295f03d41c: mp3dec: remove unused variable
[22:17] <cone-820> ffmpeg.git 03Michael Niedermayer 071838961357e3: qt-faststart: fix signedness of variable used to hold return code
[22:19] <ubitux> Daemon404: you still didn't find a way? oO
[22:20] <Daemon404> i used sox
[22:20] <ubitux> & ?
[22:20] <Daemon404> since ffmpeg crsshes
[22:20] <ubitux> please explain how to reproduce
[22:20] <Daemon404> look above
[22:21] <ubitux> works for me
[22:22] <ubitux> maybe a sample would help?
[22:23] <ubitux> ./ffmpeg -f lavfi -i 'aevalsrc=sin(2*PI*t*440)[out0]; aevalsrc=sin(2*PI*t*220)[out1]' -filter_complex "[0:0][0:1] amerge" -c:a pcm_s16le -t 60 -y a.wav
[22:23] <ubitux> no problem with this
[22:26] <durandal_1707> more tracks?
[22:26] <ubitux> <@Daemon404> [Parsed_amerge_0 @ 0x2271100] Buffer queue overflow, dropping. // i wonder what causes this though
[22:32] <Daemon404> ubitux, dunno
[22:39] <ubitux> can't you share a sample?
[22:40] <Daemon404> i cant
[22:40] <Daemon404> it's specifically a Do Not Share sample
[22:40] <Daemon404> unfortunately
[22:40] <nevcairiel> then tell them to sod off =p
[22:41] <Daemon404> ill try and debug it later
[22:42] <nevcairiel> i think i had someone with such files once, all he asked was for the ability to play more then one track at the same time
[22:47] <cone-820> ffmpeg.git 03Michael Niedermayer 07977cb54f941c: tree: fix type used for testing the tree
[22:47] <cone-820> ffmpeg.git 03Michael Niedermayer 0711d695d120d0: x11grab: fix mixed declaration and code
[22:47] <ubitux> Daemon404: can you give me some hint about the input?
[22:47] <ubitux> like the number of tracks, and basic properties?
[22:47] <ubitux> (codecs, sample formats, duration, etc)
[22:48] <Daemon404> 1 avc, 8 pcm_s16le mono tracks
[22:48] <Daemon404> first 6 are part of a 5.1ch track
[22:48] <Daemon404> last 2 are stereo
[22:48] <Daemon404> braindead broadcast stuff
[22:48] <ubitux> yeah i know that stuff
[22:48] <ubitux> ok
[22:48] <ubitux> average duration?
[22:48] <Daemon404> 1:30
[22:48] <Daemon404> hrs
[22:48] <ubitux> thx
[22:48] <Daemon404> it segfaults immediately though
[22:52] <ubitux> works fine :(
[22:54] <durandal_1707> ubitux: perhaps you are not doing same thing
[22:54] <ubitux> ffmpeg -i 124652995.mov.old -filter_complex "[0:7] [0:8] amerge" -c:a pcm_s16le -vn a.wav  this, right?
[22:55] <durandal_1707> yes
[22:57] <ubitux> i generated a mov with ./ffmpeg -f lavfi -i testsrc -f lavfi -i 'aevalsrc=sin(2*PI*t*440)' -c:a pcm_s16le -t 5400 -map 0 -map 1 -map 1 -map 1 -map 1 -map 1 -map 1 -map 1 -map 1 -y test.mov
[22:57] <ubitux> and got no problem with the above command
[22:59] <ubitux> and valgrind doesn't say anything
[23:04] <Daemon404> ill look at it later
[23:05] <Daemon404> when im not distracted by a hurricane 
[23:05] <Daemon404> or i get bored by it
[23:22] <durandal_1707> h264-conformance-caba1_sony_d is failing here
[23:25] <Daemon404> durandal_1707, threads > 1?
[23:27] <durandal_1707> but i have single core cpu and threads mt should be disabled
[23:28] <Daemon404> make hard sets it to 1 anyway
[23:28] <Daemon404> by default
[23:32] <durandal_1707> i'm using gcc4.2.1 crap, so it may be reason
[23:33] <Daemon404> why so old?
[23:33] <Daemon404> i thought freensd's base gcc was at least 4.3
[23:33] <Daemon404> freebsd*
[23:33] <durandal_1707> i have 4.7 installed, will try it
[23:35] <durandal_1707> bc lcov produced report for some fails after all, (fate did not passed so i do not blame lcov for failing for other stuff)
[23:47] <durandal_1707> Daemon404: are you at safe place?
[23:48] <Daemon404> technically.
[23:48] <Daemon404> im not in the evac zone
[00:00] --- Tue Oct 30 2012