[02:03] <Compn> adobe source code leaked? hmmm [02:04] <Compn> http://techcrunch.com/2013/10/03/adobe-gets-hacked-product-source-code-and-d... [02:24] <vigneshv> i'm trying to build a static binary with libopus in it. i built libopus with --enable-static --disable-shared and have the resulting includes and libs in a separate directory. how do i tell ffmpeg's configure to look for libopus in that directory? i tried CFLAGS and it didn't work. any pointers really appreciated? [03:34] Action: Compn wonders if anyone ever worked on an updated binary codec loader in another project [08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:41fd6f07961b: avcodec/dvdsubdec: factor out rectangles reset. [08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:71e0ae22aca7: avcodec/dvdsubdec: extract every subtitle in a different file (debug). [08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:95cafeb684d7: avcodec/dvdsubdec: reconstruct incomplete SPU packets. [08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:dbfe61100bd7: avformat/vobsub: fix several issues. [08:04] <ubitux> wm4: i'll backport this eventually later, but there are large changes and i got no review, so i'd like to have a little testing time space first [09:37] <cone-320> ffmpeg.git 03Clément BSsch 07master:d4dc67345516: avformat/vobsub: raise packet even if apparently incomplete. [10:06] <burek> i'm trying to understand this answer http://superuser.com/questions/536001/variable-bit-rates-with-vb-and-minrate... in order to write an article on our wiki, about a proper usage of -minrate, -maxrate and -bufsize... one thing is not very clear to me and i would appreciate if any of you would have a moment to comment on this.. the thing i dont understand is this: "You typically only use this for streaming, since the technique [10:06] <burek> how does the "underflow" make sense in this scenario? [10:07] <burek> or was that a typo and he meant "overflow" ? [10:16] <TimNich> I think underflow was meant. You do not watn to get into the situation where the max bitrate is so high that in the time it takes to stream a high bitrate section, the buffer has emptied itself, so the decoder stalls waiting for more data. Its a balance between the buffer size, the max bit rate, and the expected streaming rate, (i.e your target bit rate). [10:19] <burek> oh, I think I understand now.. thanks :) [10:42] <saste> michaelni_, what about an AV_OPT_TYPE_CH_LAYOUT to use in swr? [10:43] <saste> this would break syntax, OTOH having to specify an int64 to code for a channel layout is not very handy [10:48] <michaelni_> why would it break synatx ? [10:54] <saste> michaelni_, right now if you want to specify a channel layout with aresample, you need to set the int64 coding for that channel layout [10:55] <saste> if we change swr options to support channel layout symbolic names, it will not recognize the integers [10:58] <michaelni_> i dont see why you cant support both ways to specify a channel layout [10:59] <saste> michaelni_, see av_get_channel_layout() [11:21] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:02a6ee51685e: avfilter/vf_frei0r: fix out of array read [11:24] <michaelni_> saste, interpreting 5 and 0x5 differently does not seem like a good idea to me [11:28] <cone-320> ffmpeg.git 03Maxim Poliakovski 07master:6a5bfd4d49e7: atrac: Add missing av_cold [11:28] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:8378aae72935: Merge commit '6a5bfd4d49e7433f6de869ccfe682940dbca8740' [11:30] <saste> michaelni_, that was settled much time ago [11:31] <saste> i'm not against changing the syntax if developers agree [11:33] <michaelni_> also AV_OPT_TYPE_CH_LAYOUT doesnt need to reproduce the av_get_channel_layout() syntax down to every detail if that causes API issues [11:33] <michaelni_> they could differ and print a warning where there is ambiguosity [11:34] <michaelni_> is anyone/ anything using the base 10 syntax for specifying "layouts" ? [11:34] <saste> michaelni_, i'm against different parsers for different contexts [11:34] <saste> michaelni_, i don't think so, but see the thread "[FFmpeg-user] aresample out_channel_layout values" [11:35] <saste> people trying to use aresample to perform channel conversion [11:35] <saste> that was previously done with aformat or aconvert, which both accept symbolic channel layout specs [11:36] <saste> so in practice i don't think it will be a problem if we change swr [11:36] <saste> not a big problem, as most users won't notice [11:39] <cone-320> ffmpeg.git 03Diego Biurrun 07master:80fefbed6234: x86: cpu: Restore some explanatory comments removed in 7160bb7 [11:39] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:1e678007800a: Merge commit '80fefbed623491b92fe59ead99225f99c0d0ca08' [11:50] <michaelni_> iam not in favor of "layout" = "5" setting layout to a value different of 5, thats a quite unexpected thing for the API user [11:51] <michaelni_> that is one who initializes things maybe with a snprintf("%d") [11:51] <ubitux> note that such changes might affect usage of filters like pan [11:51] <ubitux> where there is various mangled parsing of layouts etc [11:51] <ubitux> dunno if it's relevant in that case [11:53] <saste> so what about chaning the syntax? [11:53] <saste> cl=5 means channel layout #5 [11:53] <saste> cl=5c means default with 5 channels [11:53] <saste> we just force the optional "c" to specify the number of channels [11:54] <saste> again this is a break in a different place [11:54] <cone-320> ffmpeg.git 03Diego Biurrun 07master:47b6cfc2a033: avformat/output-example: Declare link dependency on libswscale in the Makefile [11:54] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:90e1fc8bec1b: Merge commit '47b6cfc2a0333fb24f074d27830bf35ae5007050' [11:55] <ubitux> it seems libav is slightly moving to doc/examples [11:57] <saste> ubitux, so we'll have more redundant examples [11:57] <ubitux> dunno how they're going to nih this yet [11:57] <ubitux> it seems it was triggered by an external proposing an example [11:58] <saste> yeah i wonder if the guy is aware of ffmpeg/doc/examples [11:58] <ubitux> likely not [11:59] <saste> then he sorely misses google search skills (?) [12:00] <saste> anyway having more examples could be useful [12:00] <saste> but it's more maintainance work, given the speed of API changes [12:06] <cone-320> ffmpeg.git 03Vittorio Giovara 07master:49fe9c05f97b: oggparsevorbis: K&R formatting cosmetics [12:06] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:f3968ab47ca8: Merge commit '49fe9c05f97bc2cfafd8fdcfea2f313d7c8e2c48' [12:12] <ubitux> saste: if we're not even prepared to update our small api examples, the api is moving too fast [12:19] <saste> http://ffmpeg.org/pipermail/ffmpeg-devel/2011-November/116494.html [12:24] <xlinkz0> there might be a bug when using force_key_frames and avoid_negative_ts at the same time [12:25] <xlinkz0> when not using avoid_negative_ts force_key_frames is accurate [12:25] <xlinkz0> when using it, the keyframe ends up + or - 100ms from the target timestamp [12:41] <saste> xlinkz0, as expected [12:41] <saste> avoid_negative_ts is applied at the muxer level (it is a format option), which takes place *after* packets are processed by ffmpeg [12:43] <xlinkz0> saste: on my tests i select the seek time very accurately close to the keyframe [12:43] <xlinkz0> so close that even without avoid_negative_ts the cuts i make have a 0.00000 start time [12:44] <xlinkz0> essentially i don't need avoid_negative_ts in this scenario, but even so there's a delay [12:44] <xlinkz0> is this not a bug because it is 'unavoidable'? [12:45] <saste> xlinkz0, why do you use negative_ts if you don't need it? [12:45] <saste> and then complain that things don't work if you use it? [12:45] <xlinkz0> what [12:46] <xlinkz0> how is that relevant [12:46] <xlinkz0> ok i'll test without cutting on a keyframe [12:46] <xlinkz0> will it be a bug then? [12:46] <saste> no [12:46] <saste> i can't understand why do you mention avoid_negative_ts if it is not relevant [12:47] <mateo`> hello there ! [12:47] <xlinkz0> it is relevant because with it force_key_frames isn't accurate [12:47] <xlinkz0> i doubt that it is because i cut near a key-frame [12:47] <mateo`> i would like to insert the mjpeg_parser before decoding a mjpeg frame, is there a way to do that ? [12:47] <saste> force_key_frames can't be accurate if you don't have frames around the specified time [12:48] <xlinkz0> i do have them [12:48] <xlinkz0> how else would it be accurate without avoid_negative_ts? :| [12:49] <xlinkz0> ok it might be a problem because i use avoid_negative_ts when transcoding which afaik is redundant [12:49] <xlinkz0> but it still is a bug [12:50] <saste> xlinkz0, i already explained [12:50] <saste> the avoid_ts shift is applied after ffmpeg did its processing, when the packet is written to the output file [12:51] <saste> the only solution is not to use avoid_negative_ts, for example using a suitable format [12:51] <xlinkz0> if that is so then avoid_negative_ts shouldn't break force_key_frames when the file already doesn't have negative timestamps [12:51] <saste> that's what i'd expect [12:51] <xlinkz0> then it might be a bug [12:51] <saste> might be [12:52] <cone-320> ffmpeg.git 03Diego Biurrun 07master:b2bed9325dbd: cosmetics: Group .name and .long_name together in codec/format declarations [12:52] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:ee77140afab7: Merge commit 'b2bed9325dbd6be0da1d91ffed3f513c40274fd2' [13:34] <cone-320> ffmpeg.git 03Clément BSsch 07master:b46f19100b08: cosmetics: group remaining .name and .long_name. [13:34] Action: ubitux feels so useful... [13:39] <ubitux> it's impressive the number of additional codecs we have [13:48] <Compn> but you didnt give attribution to diego [13:48] <Compn> ;P [13:49] <Compn> at least partial [13:49] <ubitux> why should I? oO [13:49] <Compn> oh nevermind [13:49] Action: Compn feels stupid [13:49] <Compn> thought it was the same commit [13:49] <Compn> didnt realize we had 60 more codecs :P [13:49] <ubitux> actually i think we have something like 100+ [13:49] <ubitux> lemme check. [13:51] Action: Compn brb afk [13:52] <xlinkz0> is reading frames with av_read_frame as fast as ffmpeg -ss <timestamp> -i input ? [13:52] <xlinkz0> without decoding [13:52] <cone-320> ffmpeg.git 03Martin Storsjö 07master:a6b361325f2b: rtmpproto: Print the error code string if there's no description [13:53] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:373d15525d3d: Merge commit 'a6b361325f2bfc8d9d4e5f761d6c1a07b209c4fb' [13:54] <ubitux> yeah well a bit less than 100 [13:54] <ubitux> http://lucy.pkh.me/diff/diff-codecs.html [13:54] <ubitux> Compn ^ [13:54] <ubitux> i was mistaken with the filters i guess [13:55] <saste> yes we have xface :) [13:55] <ubitux> :D [13:56] <saste> (and lot more subs codecs, and more fringe/special purpose codecs, and snow) [13:56] <saste> sometimes having less is considered a feature [13:58] <ubitux> http://i1.kym-cdn.com/photos/images/newsfeed/000/140/938/responsibility12%28... [13:58] <ubitux> saste ^ [14:02] <burek> in the ffmpeg documentation, this example was described as "To set the video bitrate of the output file to 64 kbit/s" and the command line is: ffmpeg -i input.avi -b:v 64k -bufsize 64k output.avi [14:02] <burek> is it missing the -maxrate ? [14:13] <cone-320> ffmpeg.git 03Martin Storsjö 07master:4d6d70292e91: rtmpproto: Pass the 'live' parameter in the right unit [14:13] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:d32eec3359da: Merge commit '4d6d70292e91a7ef027824d731b6b6570ceabf2f' [14:15] <xlinkz0> after i seek with av_seek_frame the frames i get with av_read_frame have a coded_picture_number starting at.. 0 [14:15] <Daemon404> ubitux, how new is the libav rev [14:15] <xlinkz0> can i get the real coded_picture_number? [14:15] <Daemon404> since libav sure does have a webp decoder [14:15] <ubitux> it's today pull [14:16] <ubitux> most likely a dup Daemon404 [14:16] <ubitux> since we had it a while ago [14:16] <Daemon404> heh [14:16] <Daemon404> why would allcodecs.c have dpes [14:17] <Daemon404> dupes* [14:17] <Daemon404> its ordered [14:17] <ubitux> mmh maybe the diff is not up-to-date (mis-uploaded?) [14:17] <ubitux> lemme check [14:18] <cone-320> ffmpeg.git 03Martin Storsjö 07master:72540e514cea: rtmpproto: Clear the flv allocation size on reallocp failures [14:18] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:205b6021358e: Merge commit '72540e514ceaaed8ecb97ed63637b2a2a4447ab8' [14:18] <ubitux> Daemon404: ah, should be better now [14:19] <ubitux> ah it seems we might be around 100 now [14:24] <Paranoialmaniac> xlinkz0: there is no general way to get real codec_picture_number since container may have no index of each picture/frame [14:24] <cone-320> ffmpeg.git 03Martin Storsjö 07master:24fee95321c1: rtmpproto: Move the flv header/trailer addition to append_flv_data [14:24] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:b8e44118b136: Merge commit '24fee95321c1463360ba7042d026dae021854360' [14:24] <Daemon404> i see the vp9 decode went in [14:25] <xlinkz0> Paranoialmaniac: i only need it to work on mp4, is it possible? [14:25] <Paranoialmaniac> xlinkz0: so mp4 is possible but i don't know libavformat supports that [14:26] <xlinkz0> do you know of any other mp4utilities that could do this? [14:27] <Paranoialmaniac> why do you want coded_picture_numebr? [14:27] <xlinkz0> to pass it to x264 [14:28] <Paranoialmaniac> l-smash project i manage can seek by picture number [14:28] <xlinkz0> it's complicated, i need to use the x264 binary in a very specific use case [14:28] <xlinkz0> i need to get picture number based on timestamp, can it do that? [14:29] <Paranoialmaniac> no. [14:29] <cone-320> ffmpeg.git 03Martin Storsjö 07master:8921e32f730c: rtmpproto: Readjust the end of the flv buffer if handle_metadata exited early [14:29] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:5bb3ef3b369a: Merge commit '8921e32f730c191543b84e61338bc9d549aa05a3' [14:30] <Paranoialmaniac> since timestamp thing is complicated in mp4 [14:30] <Paranoialmaniac> pts != cts [14:30] <xlinkz0> cts? [14:30] <Paranoialmaniac> composition timestamp [14:30] <xlinkz0> well, based on pts [14:30] <Paranoialmaniac> this is a thing of media layer [14:31] <Paranoialmaniac> pts is a thing of presentation, movie or track layer [14:31] <xlinkz0> so there's no way to get frame number based on pts , atleast not in a very fast way? [14:31] <xlinkz0> like < 50ms [14:31] <xlinkz0> 100ms [14:32] <Paranoialmaniac> to get frame based on pts, you need construct presentation timeline [14:32] <Paranoialmaniac> from all edits [14:32] <Paranoialmaniac> a frame can have multiple PTSs [14:32] <Paranoialmaniac> because of edits [14:33] <Paranoialmaniac> a frame can only one CTS [14:33] <Paranoialmaniac> *can have only one CTS [14:33] <xlinkz0> AVFrame has only dts and pts, you're telling me there's another thing, cts that ffmpeg doesn't expore in the api? [14:33] <xlinkz0> s/expore/expose [14:33] <Daemon404> ffmpeg doesnt handle edits at all [14:34] <Paranoialmaniac> ffmpeg doesn't expose [14:34] <Daemon404> more or less [14:34] <Paranoialmaniac> so you cant seek by pts on mp4 by using ffmpeg [14:34] <Paranoialmaniac> actually [14:34] <xlinkz0> ok so is there any way faster than <100ms to find the frame number based on pts or not? [14:36] <cone-320> ffmpeg.git 03Martin Storsjö 07master:cd818b3a5709: rtmpproto: Validate the embedded flv packet size before copying [14:36] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:74b2b0ed9fc3: Merge commit 'cd818b3a5709b9b08bd5901cb8863a8b61be265e' [14:42] <cone-320> ffmpeg.git 03Diego Biurrun 07master:6cc133ec58b8: x86: fdct: Only build fdct code if encoders have been enabled [14:42] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:9d8e8495c9d7: Merge remote-tracking branch 'qatar/master' [14:45] <Paranoialmaniac> coded_picture_number is AVFrame thing, and libavcodec resets it internally when flush_buffers. so there is no way to get coded_picture_number i think [14:46] <xlinkz0> thanks [15:04] <kierank> + [15:13] <saste> blitz review [15:21] <wm4> so what I see in "[FFmpeg-devel] [RFC] Change av_get_channel_layout() syntax" is that you're making the API more crap just to make the ffplay/ffmpeg tools more userfriendly [15:21] <wm4> Daemon404: let me join you in your AVOption hate [15:21] <Daemon404> welcome [15:21] <Daemon404> to the club [15:21] <Daemon404> \o/ [15:22] <ubitux> why do you assume it will be more crap? [15:22] <Daemon404> wait what [15:22] <Daemon404> /change/ its syntax [15:22] <Daemon404> thats a massive no-no [15:22] <Daemon404> api-wise [15:22] <ubitux> that, ok [15:22] <saste> Daemon404, how's that related to AVOptions API? [15:22] <wm4> oh wait I was misreading this mail [15:23] <wm4> I'll take back what I said [15:23] <Daemon404> saste, i just read it now, ask wm4 [15:23] <Daemon404> saste, api synta should *not* be changed. [15:23] <wm4> I was merging it with something else in my mind [15:24] <saste> in a way or another, it's gonna suck [15:24] <wm4> anyway, I'm really glad I didn't use the ffmpeg API helpers for channel layout stuff [15:24] <Daemon404> saste, changing behavior of a function with the same name between versions is gonna piss downstream right the hell off [15:24] <Daemon404> compat between diff ffmpeg versions is a massive pain as it is already [15:24] <Daemon404> without overlappinng names [15:25] <saste> but that's a feature no one is probably using [15:25] <wm4> anyway, so what is the goal: "In order to switch to symbolic names, we need to switch to a new option type for channel layout," [15:25] <Daemon404> [14:25] <@saste> but that's a feature no one is probably using <- ................ [15:25] <saste> ch_layout=1234 [15:25] <Daemon404> really, that is not a good reason to rationalize such a terrble thing [15:25] <saste> this means 1234 channels at the moment [15:26] <Daemon404> it's an api, it exists, it is public [15:26] <Daemon404> you *cannot* change its syntax [15:26] <wm4> (whoever thought passing raw numeric masks via something user-facing was a good idea...) [15:26] <saste> why, the API exists to be broken [15:26] <saste> that's our API guideline in ff*av land [15:27] <wm4> *beep* wrong attitude [15:27] <Daemon404> ......... [15:27] <Daemon404> thats a shit attitude [15:27] <Daemon404> and a terribe one for downstream [15:27] <Daemon404> and shows absolutely no regard whatsoever for actual api users [15:27] <saste> Daemon404, that's called (silly) humorism [15:27] <Daemon404> saste, poe's law. [15:28] <ubitux> saste: stop aggro mobs [15:28] <ubitux> :( [15:28] <wm4> here's a theory: most API suckage comes from low level APIs trying to satisfy the need of high level programs like ffplay/ffmpeg [15:28] <j-b> theory or troll ? :D :D [15:28] <wm4> so what you need to do is move ffmpeg and ffplay to a separate repo [15:29] <wm4> and develop it separately [15:29] <wm4> (ok, ffmpeg would collapse, oh well) [15:29] <saste> what i am actually trying to accomplish is letting user to specify symbolic channel layout names [15:30] <wm4> then fix ffplay and ffmpeg [15:30] <saste> as opposed to, say aresample=out_cl=123456 [15:30] <wm4> what does this have to do with low level APIs [15:30] <Daemon404> saste, my point was do not use the same function name [15:30] <Daemon404> and yeah, changing behavior of low level apis to facilitate cli arguments [15:30] <Daemon404> sounds batshit retarded [15:30] <Daemon404> very very mplayer-like. [15:31] <saste> Daemon404, that's probably doable, but it sucks in a different way, since I have to provide a separate parser [15:31] <saste> (and probably make the actual parser compatible at the next bump) [15:32] <wm4> not having proper API but AVOptions (even string based one) is really annoying [15:33] <saste> wm4, i know that song, still it is what we have at the moment [15:33] <saste> i won't redesign it from scratch, i already tried, and failed [16:04] <durandal_1707> burek: where is irc log of 1st in this month? [16:41] <cone-320> ffmpeg.git 03Stefano Sabatini 07master:719b4eef5db7: lavu/common: add warning to GET_UTF8 doxy [16:41] <cone-320> ffmpeg.git 03Stefano Sabatini 07master:515e651f56e8: lavu/opt: fix doxy for av_opt_get* functions about return value [16:44] <ubitux> wtf @ #3029 [16:44] <ubitux> i don't even. [16:44] <ubitux> Priority: critical, ofc. [16:54] <burek> durandal_1707, is it ok now? [17:07] <saste> durandal_1707, why to change priority if the ticket was meaningless? [17:08] <durandal_1707> because it is not critical [17:09] <wm4> saste: shouldn't the new utf-8 function be inline? [17:09] <wm4> as much as I dislike putting code in headers, it would probably be appropriate here [17:09] <saste> wm4, whatever [17:09] <wm4> because otherwise everyone will be like LOL USE THE MACRO INSTEAD FOR SPEED [17:10] <saste> also I'm not sure I understand 7ba0c1b390a6ea67ca5e9cbade3005285b51b70f [17:10] <saste> and the code probably needs more consistency checks, now that it's not speed critical [17:12] <wm4> looks like 7ba0c1b390a6 checks the length bits as part of the loop or so [17:13] <wm4> ideally, you'd have two functions [17:13] <wm4> one for raw parsing, and one that does verification [17:13] <wm4> e.g. checking for over-long sequences and invalid code points [17:14] <Daemon404> .. eta until libaviconv? [17:14] <Daemon404> or lib swiconv [17:15] <wm4> nicolas is going to need it [17:15] <wm4> libswchardet [17:15] <durandal_1707> can you propose something more constructive? [17:16] <Daemon404> wm4 has proposed plenty of constructive things to nicolas [17:16] <Daemon404> but nicolas is having none of that. [17:16] <Plorkyeran> I'd be all for libswchardet if it actually works [17:16] <Plorkyeran> none of the current options work very well [17:16] <wm4> Daemon404: again, what nicolas wants with subtitles should be ffmpeg.c/ffplay.c's problems, not libavformats [17:17] <wm4> there's no standard lib for Mozilla's code either [17:18] <Daemon404> even if there was, it would be "mozilla-style" [17:18] <Daemon404> ever tried to use NSS? :V [17:20] <durandal_1707> Daemon404: what happened with that lavfi deadlock? [17:21] <Daemon404> durandal_1707, still being looked into [17:21] <Daemon404> it happens in libav-origin code [17:21] <Daemon404> i thin [17:21] <Daemon404> k [17:23] <durandal_1707> i would like to have that fixed [17:23] <ubitux> "it's still locked! i'm waiting" [17:23] <Daemon404> durandal_1707, then learn some patience [17:24] <Daemon404> race conditions arent exactly easy or fun to debg [17:24] <Daemon404> debug* [17:24] <Daemon404> especially when helgrind shows nothing [17:24] <ubitux> there is also a tsan instance [17:24] <ubitux> which doesn't give much more insight i know [17:25] <Daemon404> ubitux, right now im trying to et it to occur on debug builds [17:25] <Daemon404> so i can get some useful info [17:32] <Daemon404> ubitux, btw its such a pain that you cant specify the # of threads in lavfi [17:32] <Daemon404> from cli [17:33] <ubitux> why do you tell me this? [17:33] <ubitux> i almost never worked on threading [17:33] <Daemon404> s/ubitux, // [17:33] <durandal_1707> it pains me too [17:33] <ubitux> ...and i think you actually can [17:33] <Daemon404> nope [17:33] <Daemon404> you cannot [17:33] <ubitux> don't we have a threads option at lavfi level? [17:34] <Daemon404> it is not exposed via ffmpeg cli [17:34] <durandal_1707> also i do not like how timeline is done [17:35] <durandal_1707> it allows it only for codecs that have some option to set [17:36] <durandal_1707> burek: much better [17:41] <ubitux> durandal_1707: huh? [17:41] <ubitux> didn't understand the codecs/lavfi-timeline thing [17:53] <durandal_1707> you can add timeline to vflip/hflip [17:53] <durandal_1707> *can not [17:54] <durandal_1707> i told you this ages ago [17:54] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:e41ea866fc26: avformat/mov: force parsing of headers if stts is absent [17:55] <ubitux> ah [18:51] <cone-320> ffmpeg.git 03Paul B Mahol 07master:a2c14ba2b19c: avfilter/vf_histogram: use const for variables that are not supposed to change [18:52] <ubitux> BBB: i'm back on vp9, but working on the asm for now [18:55] <durandal_1707> how nice, when you finish, i expect you will write asm for lavfi [18:55] <ubitux> i'd like to [18:56] <ubitux> but unfortunately a lot of things need reshaping first... [19:27] <Compn> so , twitter stock, buy or not ? [19:53] <ubitux> sounds like the config.d project is going to be an epic fail... [19:55] <durandal_1707> ? [19:56] <ubitux> durandal_1707: they're going to scatter configure all around in an attempt to make it usable by other projects [19:56] <ubitux> but unless that system is taking out of the repository, no one will use it (unless they copy more or less up-to-date versions of it in their project) [19:57] <ubitux> so i'm guessing this is going to be either moved out of the project as a dependency [19:57] <ubitux> or copied and get unsync like it was for libpostproc [19:57] <ubitux> desync* [19:58] <ubitux> if that "succeed" we're going to have some more packaging clashes between ffmpeg and libav [19:58] <durandal_1707> why? [19:58] <ubitux> if that fails, which is likely, we're just going to have a desync vapourware, and the configure exploded in multiple files [19:58] <ubitux> durandal_1707: because libav's configure doesn't support c++ for instance, to take one of the many examples [19:59] <ubitux> basically the two config.d won't work together [20:03] <durandal_1707> perhaps libav wants to compete with cmake/automake/and others? [20:03] <ubitux> yes sure that's the goal [20:03] <ubitux> which is honorable TBH [20:04] <ubitux> it just won't happen without a lot of troubles [20:04] <ubitux> durandal_1707: are you using vim? [20:05] <durandal_1707> yes? [20:05] <ubitux> k, just curious [20:06] <Compn> going to make the configure be ... the next autoconf ? [20:08] <durandal_1707> ubitux: it have blockwise visual-mode [20:08] <ubitux> durandal_1707: how do you deal with \ macro align btw? [20:08] <ubitux> durandal_1707: yes, ^v is really cool [20:09] <durandal_1707> manual work, there sure are plugins but :effort [20:09] <ubitux> k, i was wondering, because i do the same [20:30] <durandal_1707> why you hate non-anonymous structs? [20:31] <ubitux> because the name appears two times for no benefit [20:32] <durandal_1707> its needed for function i added in struct [20:32] <durandal_1707> without it clang gives warnings [20:32] <ubitux> ah, ok in that case [20:32] <ubitux> missed the func ptr, my bad [20:35] <ubitux> durandal_1707: about fate i was wondering if you tried with a aformat=s16 etc [20:35] <durandal_1707> yes, but due rounding it may be different.... [20:36] <ubitux> durandal_1707: as long as the results are mostly accurate it's good enough [20:36] <durandal_1707> for 0.1 and s16 samples all sample formats (s16/s32/flt/dbl) output is same [20:37] <durandal_1707> the idea is to add silence removal filter [20:37] <durandal_1707> its shame ffmpeg doesn't have one, and one need to use sox one [21:48] <ubitux> writing simd really feels like playing tetris, with a time dimension [21:48] <ubitux> trying to rearrange the game all over again according to the mess of pieces [21:50] <durandal_1707> one really slow tetris game [21:50] <ubitux> :) [22:27] <teratorn> anything like the testsrc avfilter except for audio? [22:29] <ubitux> aevalsrc [22:29] <durandal_1707> teratorn: see http://ffmpeg.org/ffmpeg-filters.html#Audio-Sources [22:29] <teratorn> thank you kind sirs [22:30] <ubitux> ./ffplay -f lavfi "aevalsrc='sin(440*2*PI*t)*exp(-4*mod(t,1))'" [22:31] <durandal_1707> can't do simple tone? [23:39] <cone-451> ffmpeg.git 03Lukasz Marek 07master:b611ea041de6: lavd/pulse: add MAINTAINERS entry [23:39] <cone-451> ffmpeg.git 03Michael Niedermayer 07master:e1f8184a1a97: avformat/gifdec: make GIF_APP_EXT_LABEL parsing more robust [00:00] --- Sat Oct 5 2013