[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