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

[burek]

[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 at 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.png
[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.png
[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#a3d2e16b9c1dc3010f9aac5901ed223ee <-- 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=2e084a49a0bda6128712824d37cac2294b3686c1;hb=HEAD#l3423
[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/server
[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