[00:01] <ubitux> michaelni: please bump micro after the sws default change [00:01] <ubitux> and eventually add an entry in APIChanges [00:01] <ubitux> even though that might be overkill [00:05] <michaelni> both done locally [00:08] <ubitux> thanks [00:38] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:2e2a2d8801b0: swscale/utils: dont divide by zero with zero vectors [02:39] <rcombs> how can a video filter access other tracks? (e.g. subtitles, attachments) [03:09] <rcombs> i.e. can I access input_streams and nb_input_streams from within an avfilter? [05:04] CTCP : from BBB (BBB!~rbultje@abraxo.bluebottle.net.au) to #ffmpeg-devel [05:04] <BBB>
chaelni: new w ffvp9 patch has two more fate tests, I'll send you the samples [05:58] <rcombs> OK, so: I've got a vfilter here that renders muxed-in SSA tracks onto video, using the fonts embedded in the file. It relies on being linked with ffmpeg, as it accesses input_streams and similar via C extern, and currently requires a few tweaks to ffmpeg.c (but doesn't necessarily need to). Is there any way that I could try to get this filter into ffmpeg main? [07:23] <ubitux> rcombs: i'm guessing it doesn't integrate well with the libavfilter design [07:49] <ubitux> BBB: we should not assert if they are possible [07:49] <ubitux> (even with crafted input) [07:49] <ubitux> we should return invalid_data or sth instead [09:33] <michaelni> BBB, uploaded [10:44] <ubitux> kierank, Daemon404, so, how can i use gpu to make faster encodes? [10:45] <kierank> You can buy an elemental box [10:45] <JEEB> :D [10:45] <ubitux> :D [10:46] <ubitux> no progress on the paper? :) [12:28] <BBB> ubitux: ? [12:28] <BBB> ubitux: I don't think we assert on anything that would not be a programming error [12:29] <ubitux> i misunderstood your comment then [12:29] <ubitux> > i.e. could a crafted or corrupt file trip this assert? [12:29] <ubitux> Right, the bitstream can only code 10 modes, so this is more a sanity check [12:29] <ubitux> than anything else. [12:29] <ubitux> (this one ^) [12:30] <BBB> I meant "it can only be between 0 and 9" [12:30] <BBB> so if it's not, we did something very, very silly [12:30] <ubitux> yep ok :) [12:31] <BBB> it's sort of a boolean a = ...; assert(a == false || a == true); in c++ [12:31] <ubitux> :) [12:32] <BBB> also there was a really evil bug in our tiling code, I had to pretty much rewrite the tile loop in vp9_decode_frame() to fix it [12:32] <BBB> (you may have noticed it changed substantially between the latest and previous patch versions) [12:33] <ubitux> i didn't look recently [12:33] <ubitux> i guess i'll go back on vp9 before going crazy with mpegts [12:33] <BBB> lol [12:33] <BBB> poor you [12:34] <ubitux> my job is fun but the way i spend my free time isn't at all, wth :( [12:34] <ubitux> should be contrary [12:35] <ubitux> anyway, unrelated, but someone should port the arm optim from vlc to sws [12:35] <ubitux> they seem to add optimized scaling path in arm in vlc instead of the scaling library [12:36] <BBB> that's because everyone admits sws is suboptimal and nobody is sitting down to fix it [12:36] <BBB> (I don't mean suboptimal in performance-sense here; I mean suboptimal in design-sense) [12:39] <ubitux> is it really considered that hard to have specific convert profiles? [12:40] <ubitux> s/profiles/paths/ [12:52] <BBB> the paths are good, you need that [12:52] <BBB> but sws is just a mess, it takes months to get to know that code [12:52] <ubitux> what could be improved? [12:53] <BBB> nothing that I currently care about :) [12:53] <ubitux> i see only two reasons for the current vlc patches not to be in sws: there is no ARM support, and those specific paths might not be easy to integrate [12:54] <ubitux> but if you say that the second issue doesn't stand... it shouldn't be much effort [12:54] <ubitux> it's fun that we have bfin, ppc, sparc and x286 optim but no arm [12:54] <ubitux> x86* [13:48] <rcombs> ubitux: any idea how I could redesign something like that to mesh with it better? [13:49] <rcombs> ubitux: to work properly with filter_complex (background+overlay), I'd basically need read access to the subtitle track and all attachment tracks [13:50] <ubitux> you need to inject data and subtitles streams into libavfilter [13:50] <ubitux> this is a long standing issue [13:50] <ubitux> when you have this it's simple (and it opens a loooot of awesomeness) [13:50] <rcombs> yeah, it's a tricky thing and I'm not sure how to do it properly [13:51] <ubitux> it requires reworking the subtitles API :( [13:51] <ubitux> then moving the struct somehow in a common place [13:51] <rcombs> ah, that is unfortunate [13:51] <ubitux> api breakage etc [13:51] <ubitux> we're discussing this regularly since maybe 2 years [13:52] <ubitux> if you're willing to work on this, i can assist you [13:52] <rcombs> well, for the record, I've got a fully-functional module here; here's an example of its output: https://www.dropbox.com/s/j7i5fmcc73w8xy2/Photo%20Sep%2030%2C%2018%2036%2016... [13:52] <rcombs> but it only works with some significant tweaks to ffmpeg and would almost certainly completely fall apart in libavfilter externally [13:53] <ubitux> ...and ffplay :) [13:53] <ubitux> i consider the subtitles injection in libavfilter extremely useful from a ffplay PoV [13:53] <rcombs> I don't use it with ffplay, so no comment there [13:53] <rcombs> definitely [13:53] <ubitux> (because it will allow playing video files with subtitles :p) [13:53] <ubitux> having subtitles injected in libavfilter means we can support easily muxed subtitles [13:53] <ubitux> anyway [13:54] <ubitux> we won't really accept a ffmpeg hack [13:54] <rcombs> I'm not really familiar enough with the ffmpeg codebase to make the major changes that'd be required for this [13:54] <ubitux> i can explain the issues if you're interested [13:54] <rcombs> but I'm definitely willing to modify this to work with the new APIs, whenever they're ready [13:54] <ubitux> if you give me a few minutes :p [13:55] <ubitux> rcombs: if you look at how subtitles and a/v frames are decoded, it's really different [13:55] <ubitux> also, AVSubtitle is ABI limited [13:55] <rcombs> yup [13:55] <ubitux> (on the stack) [13:55] <rcombs> I've seen a bit of that [13:55] <ubitux> (no ref counted btw..) [13:56] <rcombs> currently we're grabbing packets straight out of the stream [13:56] <ubitux> and while the decode is mostly ok (if we omit the fact that internal text representation is ass) [13:56] <ubitux> the encode is completely deprecated and unmaintained [13:56] <ubitux> the api still needs a big enough pre allocated buffer for instance [13:56] <rcombs> 0.o [13:57] <ubitux> basically, encoding/decoding API is old/broken and need to be put in sync with the a/v sync model first [13:57] <ubitux> when you have this done, adjusting libavfilter may be easier [13:58] <ubitux> maybe it's relevant to move some AVSubtitle content into AVFrame and use it directly [13:58] <ubitux> or maybe it's more relevant to create a new public struct into libavutil (where it's shared between libraries) [13:59] <rcombs> that sounds painful [13:59] <ubitux> rcombs: yup [13:59] <ubitux> but someone will have to do it [14:00] <ubitux> also, there is probably some work in progress [14:00] <ubitux> since libav is paying someone to do some work around this [14:00] <rcombs> oh, query: if using the filter_complex stuff, is everything no longer downsampled to 8bit if it was already in 10bit? [14:00] <ubitux> can't remember if he's on this channel though [14:01] <ubitux> i don't understand the relationship between filter_complex and downsampling [14:01] <ubitux> libavfilter supports 10-bits [14:01] <rcombs> well, if you do a background and an overlay, you never need to pass the existing frame through an overlaying filter [14:02] <rcombs> I was under the impression that passing video through filters currently required downsampling it, but that may be outdated [14:03] <ubitux> some filters support only a subset of pixel formats in input and output [14:03] <rcombs> ah, filter-specific [14:03] <ubitux> so if a filter doesn't support 10-bit in the filter graph [14:03] <ubitux> a scaler will be inserted [14:03] <ubitux> to downsample [14:03] <rcombs> that makes sense [14:03] <ubitux> (where appropriate) [14:21] <durandal_1707> ubitux: paying? [14:22] <ubitux> durandal_1707: i see some "funding" on ffmtech site [14:25] <durandal_1707> that page is very transparent [14:26] Action: durandal_1707 donates some money [14:33] <rcombs> OK, so it looks like it's ff_draw that's killing 10bit in the filters I'm looking at [14:35] <durandal_1707> what you need 10bit for? [14:37] <Compn> anime [14:37] <rcombs> you currently get some significant banding artifacts when downsampling 10bit input to 8bit with swscale during a transcode [14:38] <durandal_1707> but what filters you use? [14:38] <Daemon404> g 31 [14:39] <Compn> you sunk my battleship! [14:39] <xlinkz0> Could anyone please give me any pointers on this segfault ( gdb output at the end ) : http://codepad.org/HlZkiBcb [14:39] <rcombs> libass and my heavily-modified version of it that supports inline streams [14:39] <durandal_1707> you mean vf_ass ? [14:40] <rcombs> yes, that [14:40] <durandal_1707> well than you need to add >8 bit support to relevant draw code [14:40] <rcombs> yup [14:41] <rcombs> which shouldn't, in theory, be all that complicated [14:41] <durandal_1707> there is something complicated in practice? [14:41] <durandal_1707> if design of draw sucks, just rewrite it [14:41] <Compn> xlinkz0 : ask on libav-user list ? [14:41] <rcombs> good question; let's find out [14:41] <xlinkz0> Compn: i'm using the ffmpeg libs :\ [14:42] <xlinkz0> afaik they are different [14:42] <Compn> xlinkz0 : our libav-user list is for using ffmpeg libs [14:42] <Compn> very confusing ... [14:42] <xlinkz0> why would you think i was using the libav libs? [14:42] <Compn> http://lists.ffmpeg.org/pipermail/libav-user/2013-October/thread.html [14:42] <Compn> looks kind of empty, that list [14:42] <xlinkz0> october 2013 [14:42] <Compn> xlinkz0 : ffmpeg's libav-user list is for people who use libavcodec* libs [14:42] <xlinkz0> that month started today [14:43] <Compn> oh yeah :) [14:43] <Compn> stupid october [14:43] <Daemon404> rcombs, .ass is not meant for >8bit [14:43] <Daemon404> youll screw up colors [14:43] <Compn> xlinkz0 : you are thinking of libav's libav-user list, which is for whatever libav does [14:43] <xlinkz0> so i should ask in the libav channel? [14:43] <Daemon404> even if you scale 'properly' [14:43] <Compn> xlinkz0 : no, you misunderstand, but ask in #ffmpeg [14:43] <xlinkz0> i've never used mailing lists i'm scared of them :( [14:43] <Compn> ah [14:43] <Daemon404> xlinkz0, step 1: grow beard [14:44] <xlinkz0> can't :( [14:44] <rcombs> Daemon404: what would go wrong with scaling the 8bit output of libass to 10bit, then drawing that over unscaled 10bit video? [14:44] <Compn> xlinkz0 : why do you convert ms to tb anyhow [14:44] <durandal_1707> xlinkz0: is there backtrace? [14:44] <xlinkz0> durandal_1707: yes, at the end of the file [14:44] <Daemon404> rcombs, colors are all given in 8-bit BGR in .ass [14:44] <Compn> end of the paste you mean [14:44] <xlinkz0> my requests are in milliseconds [14:44] <rcombs> Daemon404: sure [14:44] <Daemon404> people typeset stuff carefully to match [14:45] <xlinkz0> as far as i can tell there's a segfault because m_video_stream was not initialized [14:45] <Compn> xlinkz0 : i dont think tb can be 1500 ? [14:45] <xlinkz0> well the segfault happens when i try to read m_video_stream->timebase [14:45] <rcombs> as long as scaling is done properly, shouldn't they still be as close to a match as possible? [14:45] <xlinkz0> not on the conversion itself.. [14:46] <rcombs> (i.e. off by no more than ~±.5 8-bit B, G, or R value) [14:46] <xlinkz0> i get a segfault here : VERBOSE("time_base.den = " << m_video_stream->time_base.den); [14:46] <Daemon404> rcombs, this depends on which order you do dither and colorspace converion [14:46] <Daemon404> for both sets [14:46] <Daemon404> it can be done pretty well yes [14:46] <Daemon404> im not sure how easy it is with current swscale [14:47] <xlinkz0> that would mean that m_video_stream is unallocated or something, that would mean that the init function is wrong [14:47] <rcombs> and yeah, I know what you mean on the close matching; I've been using this video to test the output of my filter: https://www.dropbox.com/s/j7i5fmcc73w8xy2/Photo%20Sep%2030%2C%2018%2036%2016... [14:48] <Daemon404> yes i was referring to fansubs [14:48] <rcombs> but of course, being ass and all :P [14:48] <Daemon404> scene technically allows ass [14:48] <Daemon404> but people seem to prefer vobsubs [14:48] <Daemon404> or srt [14:49] Action: rcombs hasn't tried to keep track of scene rules in a while [14:49] <Daemon404> i dont [14:49] <rcombs> call me back when torrents stop being split up into 30 r01 files [14:50] <rcombs> but that's besides the point [14:50] <Daemon404> scene doesnt use torrents, they use topsite ftps [14:50] <Daemon404> ;P [14:50] <Daemon404> and yes theyre mostly idiots WRT encoding [14:50] <Compn> xlinkz0 : force tb to 30 and see if it crashes [14:50] <xlinkz0> seems that m_video_stream is null for some reason.. [14:50] <xlinkz0> i'll look into it [14:53] <rcombs> wait WTF? [14:53] <rcombs> http://ffmpeg.org/doxygen/trunk/colorspace_8h.html#a3d2e16b9c1dc3010f9aac590... <-- hard-coded BT.601?! [14:56] <Daemon404> there's a mode for bt.709 now i believe [14:56] <Daemon404> ffms2 makes use of it i thin [14:56] <rcombs> ff_draw doesn't use it when converting colors, evidently [14:57] <Daemon404> oh [14:57] <Daemon404> i meant the public api [14:57] <Daemon404> no idea about internal use [15:02] <rcombs> AFAICT swscale does the same [15:02] <rcombs> and I have no idea how to go about fixing that [15:03] <durandal_1707> you can set colorspace in swscale [15:05] <rcombs> actually, it's only for PAL, evidently [15:06] <rcombs> when the input to swscale is PAL, it forces BT.601 [15:08] <rcombs> otherwise, it's selectable [15:09] Action: rcombs isn't familiar enough with PAL to know if that behavior is correct [15:11] <durandal_1707> what forces BT.601? [15:11] <Compn> rcombs : not everone uses 709 or whatever , you know ? [15:11] <rcombs> Compn: sure [15:16] <Daemon404> rcombs, if by PAL you mean PAL resolution, then technically, yes [15:16] <Daemon404> bt.709 is hd only. [15:16] <Daemon404> technically. [15:17] <rcombs> I'm looking at http://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00952 [15:18] <Daemon404> thats not PAL [15:18] <Daemon404> thats pallette [15:18] Action: rcombs face-faults [15:18] <rcombs> that's a pretty good signal that it's time to stop trying to do anything useful today [15:22] <durandal_1707> well if one do that every time he touch swscale..... [15:23] <rcombs> nah, not swscale's fault; mine for not looking at "usePal" and not checking to see if it actually means what I think it does [15:23] <durandal_1707> that is called: properly obfuscated code [15:36] <kierank> 14:16:47 <"Daemon404> bt.709 is hd only. [15:36] <kierank> 14:16:49 <"Daemon404> technically. [15:36] Action: kierank has some 709 hd [15:36] <kierank> sd* [15:37] <kierank> loong story [15:38] <Compn> durandal_1707 : want to rename usepal to usepalette ? :P [15:40] <durandal_1707> Compn: before commiting send patch to ml for review [16:37] <durandal_1707> wm4: watch this!!! [16:37] <wm4> ? [16:40] <durandal_1707> ^ [16:40] <ubitux> haha [16:41] <ubitux> you're so mean ;) [16:41] <wm4> durandal_1707: nice [16:49] <durandal_1707> 'recent checkout of mencoder' [16:55] <Daemon404> durandal_1707, sadly, i think the reference will go over a certain someone's head. [17:28] <Daemon404> why does ffmpeg return an exit code of 254 on some files [17:28] <Daemon404> shoulnt it only ever return 1 or 0 [17:29] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=2e084a49a0bda61287... [17:29] <Daemon404> wtf [17:30] <ubitux> Daemon404: this is to handle case with image files iirc [17:30] <ubitux> like one decode error actually means the whole file decode is considered an error [17:30] <Daemon404> .. it happens on video files [17:30] <Daemon404> this is terrible behavior [17:31] <ubitux> because it has too many decode error [17:31] <ubitux> i guess [17:31] <ubitux> so it considers the whole operation a failure [17:31] <ubitux> which kind of makes sense [17:31] <ubitux> but has a different error code for that anyway [17:31] <ubitux> so you can ignore [17:32] <Daemon404> wow @ eedcac68f31ca8d6784bb77ed5c471f04eb2301e [17:32] <Daemon404> thats horrible. [17:32] <Daemon404> bug "fix" [17:32] <ubitux> right that's what i explain then [17:32] <ubitux> what do you propose, make a special case for image2? [17:33] <ubitux> if there are too much decoding error, it kinds of make sense to consider the transcode a failure [17:33] <Daemon404> why doesnt it return 1 on error [17:36] <ubitux> because it's not due to "fatal" error Daemon404 [17:37] <Daemon404> ... [17:37] <Daemon404> thats its fucking braindead [17:37] <Daemon404> writing 0 btes certainly IS fatal [17:37] <Daemon404> it's a nop [17:37] <ubitux> 0 is fine, !0 is error [17:37] <Daemon404> standard behavior is 01 [17:37] <Daemon404> 0/1 [17:37] <ubitux> why do you care about the different !0 ? [17:37] <ubitux> no [17:37] <Daemon404> ALSO [17:37] <Daemon404> >128 [17:37] <ubitux> standard behaviour i 0/!0 [17:37] <Daemon404> er [17:37] <Daemon404> >127 [17:37] <Daemon404> is reserved for signals [17:37] <Daemon404> like SIGILL [17:38] <Daemon404> or SEGV [17:38] <ubitux> in that case we could change to 123 [17:38] <Daemon404> it's a shitty hack [17:38] <ubitux> how so? [17:38] <Daemon404> .... [17:38] <ubitux> it's an heuristic [17:38] <Daemon404> a WRONG one [17:38] <ubitux> with a different error code which you can ignore if you don't like it [17:38] <ubitux> how wrong? [17:38] <ubitux> what do you propose? [17:39] <Daemon404> it returns failure on files which still wrote byets [17:39] <ubitux> an exception for image2 files? [17:39] <ubitux> Daemon404: yeah but with a lot of decode error [17:39] <ubitux> so it's considered a failure [17:39] <Daemon404> thats a terrible idea [17:39] <Daemon404> an arbitrary decisio [17:39] <Daemon404> n [17:39] <Daemon404> detect wen 0 byte are written [17:39] <ubitux> yes [17:39] <Daemon404> not soe arbtrary decode error amount [17:39] <Daemon404> some* [17:40] <ubitux> you can't easily do that iirc [17:40] <Compn> then just map error 254 to 0 huh [17:40] <ubitux> because there are valid usage of ffmpeg without outputs [17:40] <Compn> and get over it Daemon404 [17:40] <Daemon404> thats not a good excuse for terrible hacks [17:40] <wm4> does ffmpeg coding style require adhere to a maximum column width or not? [17:41] <ubitux> wm4: when it makes sense [17:41] <Compn> wm4 : split long lines [17:41] <Daemon404> [16:40] <@ubitux> because there are valid usage of ffmpeg without outputs <-- true [17:41] <Daemon404> however introducing onstandard return codes with a heuristic is fucking retarded [17:41] <Daemon404> especially when it can still be success [17:41] <Daemon404> because literally everything in existence uses 0 == success [17:41] <ubitux> wm4: AVOptions or tables don't need max column or you actually fuck readability [17:41] <Daemon404> and ffmpeg has to be a secial snowflake [17:41] <Daemon404> with a special edge case [17:41] <ubitux> wm4: so basically at your own discretion, imo [17:42] <ubitux> Daemon404: 0 == success is maintained [17:42] <Daemon404> it is NOT [17:42] <Daemon404> it can still 'succeed' [17:42] <ubitux> too much decoding error can not be considered a success [17:42] <Daemon404> thats bullshi [17:42] <Daemon404> t [17:42] <ubitux> ok [17:42] <Daemon404> if somethin is written [17:42] <Daemon404> it is a success [17:42] <Daemon404> something succeded [17:42] <Daemon404> nto everything [17:42] <Daemon404> but something. [17:42] <Daemon404> arbitrary heurstics are a load of shit [17:42] <ubitux> can you send a patch that honor the problem in the ticket? [17:42] <Daemon404> for doing anything pragmaticallyl ike that [17:43] <Daemon404> ubitux, you do realize you don need to solve every edge case [17:43] <Daemon404> by lumping on hacks [17:43] <Daemon404> i.e. sometimes its better NOT to "solve" it [17:43] <Daemon404> i realize thats not the ffmpeg -- which is to hack every possible corner case with horrible heuristics [17:44] <ubitux> Daemon404: i don't own all the solutions of the universe [17:44] <ubitux> and i believe this patch improves things [17:44] <ubitux> if you think you can do better, please propose [17:44] <Daemon404> then youre an idiot [17:44] <ubitux> well, then fuck you :) [17:44] <Daemon404> ffmpeg shows 0 good design [17:44] <Daemon404> as p er usual [17:44] <Daemon404> :| [17:45] <Daemon404> also [17:45] <Daemon404> nice job on error code 255 below it [17:45] <Daemon404> because that is ALSO resrved code [17:45] <Daemon404> for when teh executable is not found [17:46] <Daemon404> (on some systems) [17:50] <Daemon404> ubitux, the proper solution would be soe sort of option [17:50] <Daemon404> -max_error_rate [17:50] <Daemon404> or something [17:50] <Daemon404> and a return code of 1 [17:51] <ubitux> it won't fix the issue in the ticket [17:51] <durandal_1707> what was issue in the ticket? [17:51] <Daemon404> https://trac.ffmpeg.org/ticket/2405 [17:52] <ubitux> converting images failing at decoding the only frame will fail [17:52] <ubitux> will *not* fail [17:52] <Daemon404> set a max error rate of 0 [17:52] <ubitux> defaut behaviour should fail properly [17:52] <Daemon404> thatsi NOT properly [17:53] <Daemon404> failing because of soem arbitrary heuristic satisfiees NO Defintiion for "proper" [17:53] <Daemon404> its a lump of shit [17:53] <durandal_1707> ok, can somebody write patch and move further disccussion to ml? [17:53] <ubitux> yes please [17:53] <Daemon404> im getting prett tired of ffmpegs bullshit workarounds/hacks [17:53] <Daemon404> considering asking eployer to move to avconv [17:53] <ubitux> i never said it was the best solution, it solves the problem and your suggestion doesn't [17:54] <Daemon404> no [17:54] <Daemon404> my solution at least allows both use cases to work *at all* [17:54] <Daemon404> teh current one just breaks one of them. [17:54] <durandal_1707> Daemon404: how this specific case matter for your employer? [17:55] <ubitux> it breaks a special case where it can be considered legit, and it definitely solves another [17:55] <Daemon404> bullshit [17:55] <ubitux> it's not perfect and you can suggest something else [17:55] <ubitux> instead of insulting everyone and killing productivity once again [17:56] <Daemon404> its hard to debate technical design with someone who doesnt understand what goo technical design is [17:56] <vivienschilis> hi guys, in the docs I see we can do -loop 10 -i input? I have command tho (Version 2.0.1) How do we loop the input now? [17:56] <wm4> Daemon404: what is good technical design? [17:56] <durandal_1707> vivienschilis: it doesn't work now or? [17:56] <ubitux> Daemon404: and you seem to consider your problem universal and ignore the others; i'm just explaining to you why it was done like this, and why that particular solution you propose isn't the best either [17:57] <ubitux> it's not like i'm opposed to change the code [17:57] <Daemon404> wm4, not returning a non-standard (ans reserved) exit status based on soem arbitrary heuristic [17:57] <Daemon404> which cannot be set at all [17:57] <ubitux> ...i'm not even the author of that patch [17:57] <Daemon404> by the user [17:57] <Daemon404> ubitux, yes but you tend to be a huge mini-code fanboy [17:57] <vivienschilis> durandal_1707: if i put -loop before the input, I get command not found [17:57] <durandal_1707> haha [17:57] <vivienschilis> i mean the option [17:58] <ubitux> Daemon404: no i tend to try exerce my empathy and understanding of the history of the changes [17:58] <ubitux> instead of yelling like a pig non stop [17:58] <vivienschilis> how do we loop an input on 2.0? [17:59] <vivienschilis> I need to loop X times [17:59] <durandal_1707> ubitux: do we really need to pick such naming? [17:59] <ubitux> what naming? [18:00] <ubitux> vivienschilis: where did you get that loop option? in the gif muxer? [18:00] <durandal_1707> any involving animals (but not limited to) [18:00] <ubitux> iirc there is no proper loop option available (maybe in the movie source but it doesn't work iirc) [18:00] <ubitux> durandal_1707: well i'm getting insulting since a few minutes without any progress [18:00] <durandal_1707> hmm it should work with movie [18:01] <ubitux> i don't feel like i'm being harsh here [18:01] <ubitux> insulted* [18:01] <durandal_1707> by 'mini-code fanboy' ? [18:03] <ubitux> idiot previously [18:04] <ubitux> + general aggressive behaviour [18:05] <durandal_1707> i just tried loop with movie and it works [18:06] <Compn> ubitux : mplayer -loop ? :P [18:06] <ubitux> durandal_1707: with a video? [18:07] <ubitux> durandal_1707: #1799 [18:09] <durandal_1707> vivienschilis: you want loop any input or just for some formats? [18:10] <vivienschilis> durandal_1707: I need to take a gif as an input [18:10] <vivienschilis> and loop it x time [18:10] <vivienschilis> otherwise I can't encode the mpegts [18:10] <vivienschilis> and concat the input [18:10] <durandal_1707> ah another gif image user [18:11] <wm4> how do I build ffmpeg examples in the build directory? [18:11] <vivienschilis> is that not going to create multiple streams? [18:11] <ubitux> wm4: see the README [18:11] <ubitux> wm4: everything is explained in it [18:11] <durandal_1707> vivienschilis: so loop gifs or single gif? [18:11] <vivienschilis> single gif [18:11] <vivienschilis> looping x time [18:11] <wm4> ubitux: not really... [18:11] <wm4> unless there's another README [18:11] <ubitux> doc/examples/README [18:11] <wm4> oh... k [18:12] <wm4> ok it can't do what I want [18:12] <ubitux> what do you want? [18:12] <wm4> build the examples like ffmpeg/ffplay/etc [18:12] <ubitux> (cd doc/examples && PKG_CONFIG_PATH=pc-uninstalled make) [18:13] <wm4> setting up the PKG_CONGIF_PATH is kind of involved, because your pc files are half-broken [18:13] <durandal_1707> vivienschilis: try demuxer option: '-ignore_loop 0' [18:13] <ubitux> wm4: what is broken? [18:13] <wm4> I take that back [18:13] <wm4> maybe they've got fixed since last time I checked :) [18:13] <ubitux> i don't remember any changes in them but ok [18:13] <wm4> except that libavcodec.pc still requires -lSDL [18:14] <Daemon404> wut [18:14] <wm4> ubitux: well, I still can't build them in the build dir like ffmpeg itself [18:14] <wm4> so it's inconvenient for development [18:14] <wm4> I'll use symlinks I guess (lol) [18:15] <vivienschilis> durandal_1707: any doc on this? [18:15] <Daemon404> wm4, what was broken? [18:15] <Daemon404> ive been using the .pc files for ages fine [18:15] <wm4> Daemon404: I think they didn't contain the correct paths... well maybe I'm just wrong [18:15] <Daemon404> they do [18:15] <Daemon404> ive been using them daily for years [18:16] <durandal_1707> vivienschilis: otherwise you can loop with : ffmpeg -f lavfi -i move=path/to/movie:loop=loop_number -vf setpts=.... so ffmpeg does not drop frames [18:16] <durandal_1707> s/move/movide [18:16] <durandal_1707> s/move/movie [18:16] <durandal_1707> vivienschilis: !docs [18:27] <vivienschilis> durandal_1707: thanks man I'll try it out [18:32] <wm4> haha [18:32] <wm4> now it's exist code 69 [18:33] <wm4> Daemon404 is going to complain about the random number [18:34] <durandal_1707> there is some guy(s) that constatly stole/nih my patches [18:34] <Daemon404> probably from errno [18:35] <durandal_1707> 69 is nice number, its unfortunate 1707 can't be used [18:50] <wm4> so what is the status of AVPicture [18:51] <wm4> is it good, is it bad, is it deprecated, is it fine? [18:51] <wm4> even an example uses it (muxing.c) [18:52] <durandal_1707> avoid [19:03] <ubitux> wm4: we decided to make them independant because most users want to write their own app and they need to understand what is required for the build [19:03] <ubitux> and telling them to look at ffmpeg build is not really a good idea [19:03] <ubitux> (it's like telling them to look at ffmpeg.c for example ;)) [19:04] <wm4> definitely... [19:08] <wm4> durandal_1707: if it's "avoid", it should probably not be part of muxing.c [19:14] <cone-715> ffmpeg.git 03Thilo Borgmann 07master:d3a03d90a3d5: configure: fix logic for threads in case of OpenCL is enabled. Fixes ticket 3004. [19:52] <wm4> so I'm using libavcodec to encode PNGs, and a user sometimes gets a crash when his code is used [19:52] <wm4> and he gets this backtrace with latest ffmpeg git: #0 0x00000001006a221b in ff_dsputilenc_init_mmx () [19:52] <wm4> #1 0x0000000102957a00 in ?? () [19:52] <wm4> this is on x86/OSX [19:52] <wm4> any clue what to try next to find the issue? [19:53] <durandal_1707> looks like some issue with assembly [19:54] <durandal_1707> recompile with full debuging and get full backtrace with exact instructions where it crash [19:54] <wm4> I told him to do so... well I'll try to make sure he did indeed compile with --enable-debug [19:55] <durandal_1707> how is it compiled? [19:56] <wm4> <der_richter> what fmpeg -v says [19:56] <wm4> <der_richter> configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=cc --host-cflags= --host-ldflags= --enable-ffplay --enable-vda --enable-debug ... [20:32] <xaiki> hey there, I'm reading the source of vf_mcdeint, and see it's using snowenc's memc estimator. wouldn't it make sense to be able to use other ones ? ones from motion_est.c for instance ? [20:33] <Compn> xaiki : it was done by the same dev who created snowenc [20:33] <Compn> so uh, it was his decision [20:42] <durandal_1707> omg, somene sends patches to libav-devel and then others comment with various (alphabetical order and other bikeshed) not realising libav do not have that feature at all [20:47] <wm4> durandal_1707: which feature? [20:47] <durandal_1707> exif [20:47] <iive> LOL [20:47] <durandal_1707> its better to add fate test before adding actual code [20:47] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:795eaf8d698d: avcodec/fraps: increase vlc nb_bits [20:51] <ubitux> i was also surprised the prores alph/transp test has different crc [20:51] <ubitux> but that patch won't be applied, it seems there is a duplicated test [20:53] <durandal_1707> for exif they will need frame metadata first [20:54] <ubitux> and NIH something in avprobe [21:05] <durandal_1707> Compn: you mean this ones http://ark.intel.com/products/family/71840/Intel-Xeon-Phi-Coprocessors/serve... [21:27] <ubitux> "Given how mislead are people about this we should move all the examples [21:27] <ubitux> somewhere (in /doc would be good) and use a proper stand alone Makefile [21:27] <ubitux> for them." [21:27] <ubitux> 'reminds me of something [21:30] <durandal_1707> how much image median/mean/std deviation/min/max is useful? [21:47] <saste> durandal_1707, and while at it, maybe we could have some texture descriptors as well in a dedicated filter [21:48] <durandal_1707> saste: ? [21:48] <saste> durandal_1707, just an idea [21:48] <saste> not sure we really have some use cases for that... [21:48] <durandal_1707> what is texture descriptors? [21:49] <saste> http://www.cacs.louisiana.edu/~cice/cacs508/descriptors.pdf [21:49] <saste> durandal_1707, for example [21:50] <saste> cool academic stuff, not sure about real use cases [22:01] <durandal_1707> i can't grasp how to implement single mentioned stuff in that paper [23:00] <llogan> BBB: you have some messages in ffmpeg-devel mod queue. should all of it be approved, or are some messages duplicates or outdated? [23:01] <durandal_1707> llogan: since when? [23:01] <llogan> i admit i did not do any comparisons yet as i just got back [23:02] <llogan> durandal_1707: Sun Sep 22 21:35:05 2013, Sun Sep 29 22:12:29 2013, Tue Oct 1 05:04:05 2013 [23:03] <llogan> is Timoty Gu ever here? [23:04] <durandal_1707> why? [23:04] <durandal_1707> there are more messages in queue? [23:05] <durandal_1707> you are the only one approving them? [23:06] <llogan> yes, most of the valid ones are due to ML message size restriction. i asked michaelni and compn to babysit while i was away, but they must have been busy [23:06] <llogan> i will probably increase size limit [23:06] <llogan> at 500k now [23:07] <llogan> s/500/400 [23:08] <llogan> durandal_1707: if you are interested in being backup or additional ML monkey that would be appreciated [23:15] <llogan> ...or if anyone else is interested please let me know. [23:15] <llogan> ill be gone again sometime in january, but only for a week. [23:27] <cone-715> ffmpeg.git 03Marton Balint 07master:31a8461d6462: avfilter/vf_histogram: improve waveform speed [23:27] <cone-715> ffmpeg.git 03Marton Balint 07master:cac9af68a42c: avfilter/vf_histogram: add support for subsampled planar yuv modes in waveform mode [23:27] <cone-715> ffmpeg.git 03Paul B Mahol 07master:edadda968c24: avfilter/vf_histogram: change order of histograms for planar rgb [23:33] <Compn> llogan : doh, i checked mplayer's list with 200 mails :P [23:47] <llogan> Compn: oops. don't worry about it. i went through them today (but i have yet to look at Ronald's and one from Timothy). [23:59] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:ad8fbddb94c2: Revert "Merge commit '61c31e4ee7ea79a9e74c0476b81244febf17e6d7'" (configure: Properly set zlib dependencies for all components) [00:00] --- Wed Oct 2 2013