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

[burek]

[00:08] <cone-170> ffmpeg.git 03Paul B Mahol 07master:22a038606cde: dpxenc: do not set coded_frame
[00:08] <cone-170> ffmpeg.git 03Paul B Mahol 07master:ae9ef151ad77: dpxenc: simplifiy code using AVPixFmtDescriptor
[00:08] <cone-170> ffmpeg.git 03Paul B Mahol 07master:c0a30dd2e4c5: fate: increase coverage for dpx encoder
[00:12] <ubitux> michaelni: do you want to comment on vignette at some point?
[00:13] <cone-170> ffmpeg.git 03Andrey Utkin 07master:bc63a760837c: pngenc: Add 'dpi', 'dpm' options
[00:24] <durandal_1707> there were megalux samples in incoming, where they are now?
[00:32] <Compn> filenames ?
[00:32] <Compn> i mean, what filename i can search
[00:32] <durandal_1707> frm extension
[00:33] <Compn> ./game-formats/cyclemania/ACCO.FRM
[00:33] <Compn> ./game-formats/cyclemania/BIKE.FRM
[00:33] <Compn> ./game-formats/cyclemania/LOGO.FRM
[00:33] <Compn> only ones i see in samples.ffmpeg.org
[00:34] <durandal_1707> those are game formats, and i already tried them
[00:36] <Compn> well, incoming is ran by j-b , so have to ask him
[00:36] <Compn> or carl also checks a lot of samples
[00:40] <ubitux> Daemon404: seems the vid.stab guys will be away for 2 months
[00:40] <ubitux> you didn't open an issue, right?
[00:41] <Daemon404> i said i would on monday, and i will on onday
[00:41] <Daemon404> of their github tracker
[00:41] <Daemon404> busy weekend (mothers day)
[00:41] <ubitux> sorry, missed that bit
[00:42] <Daemon404> i actually would like to see it make progress
[00:43] <Daemon404> since there's no good FOSS motion tracking or stabalization
[00:43] <Daemon404> nothing even compares to nuke, mocha, etc
[00:44] <Daemon404> perhaps i should re-evaluate blender
[00:47] <ubitux> you don't want to let us NIH it, so too bad for you
[00:48] <Daemon404> i fail to see the relation
[00:48] <Compn> lol ubitux :D
[00:48] <ubitux> if we nih it, will be awesome
[00:49] <ubitux> but you don't want to :(
[00:49] <ubitux> it* will
[00:49] <Daemon404> thats a pretty awful argument...
[00:49] <Daemon404> and history shows that's not at all true.
[00:49] <ubitux> :(
[00:49] <durandal_1707> this discussion is going nowhere
[00:49] <Compn> ubitux : nih it, we can have external lib too
[00:49] <Compn> if its updated , or if ours sucks :)
[00:49] <ubitux> well we already have deshake, but it needs drastic improvements
[00:50] <Daemon404> unless you are htinking "i cannot contributed unless i rewrite it myself"
[00:50] <ubitux> i believe we can pick various good bits from vid.stab though
[00:50] <Daemon404> deshake wa never good
[00:50] <Daemon404> was*
[00:50] <Daemon404> certainly not even passable without a ton of tweaking
[00:50] <Compn> dont argue with opinion... just continue development
[00:50] <Daemon404> i dont really see why you have to NIH something
[00:50] <Daemon404> to improve
[00:50] <Daemon404> fuckng contribute back
[00:51] <ubitux> better swallow them all
[00:51] <durandal_1707> resistance is futile
[00:51] <ubitux> one code to rule them all
[00:52] <Daemon404> which is teh exact opposite of what NIH accomplishes.
[00:52] <Compn> Daemon404 : you know you cant control people forking or porting
[00:52] <Compn> get over it and love it or leave it
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:731f4bb6fd44: xbmdec: fix off by one error in scanf()
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:4427e96bb1cf: src_movie: fix scanf string
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:4a455358363f: avcodec/mpegvideo: Fix block height for lowres 3 interlaced blocks
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:0cb4887b838a: avcodec/mpegvideo: Fix edge emu with lowres
[00:52] <Daemon404> Compn, doesnt stop me fro mcalling it retarded
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:82a627c2c3d8: mjpegdec: fix overlapping memcpy with upscale_v
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:520c3d23036f: mmvideo/mm_decode_inter: check horizontal coordinate too
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:e4bae0a14067: mmvideo/mm_decode_intra: check horizontal coordinate too
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:e9d9fd1137b1: vmdav: Try to fix unpack_rle()
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:cd2d8aca8468: avutil/log: Fix context pointer used for get_category()
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:a4e3bb0106a5: avutil/intfloat_readwrite: avoid comparission with INFINITY, use isinf()
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:426715ccbd57: avutil/intfloat_readwrite: include common.h for isinf()
[00:52] <cone-170> ffmpeg.git 03Clément BSsch 07release/1.1:d9ab7c629242: cmdutils: avtool -> fftool (cherry picked from commit 7d8ad6c1fa11ec548fc63427656989e0e7c6af8b)
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:dafd8228bc0f: sanm: Check dimensions before use
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:151c2ca8c797: avcodec/cdgraphics: check buffer size before use
[00:52] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:a4681d104355: gifdec: reset previous Graphic Control Extension disposal type
[00:52] <ubitux> <o>
[00:52] <Compn> Daemon404 : sure, but you arent changing any opinions :P
[00:53] <Compn> so basically you are just whining 
[00:53] <ubitux> what was the complain about already?
[00:53] <Compn> nih syndrome
[00:53] <ubitux> about what?
[00:53] <Compn> you porting vid.stab i think
[00:53] <ubitux> ah right
[00:53] <ubitux> well i didn't really meant to port it myself
[00:54] <ubitux> i proposed the author to it instead
[00:54] <ubitux> +do
[00:54] <Daemon404> it's different if ffmpeg is the canonical home
[00:54] <Daemon404> which usually isnt the case
[00:54] <Compn> oh i thought you were gonna do it 
[00:55] <ubitux> oh no, i have other things to do
[00:55] <ubitux> i just think it's not much work
[00:55] <ubitux> though, since the author is away two months
[00:55] <Daemon404> just 'away' ?
[00:55] <ubitux> someone could make a surprise for him
[00:55] <Daemon404> i.e. if i post a bug itll have no rpely for 2 months?
[00:55] <Daemon404> :
[00:55] <Daemon404> :(
[00:55] <ubitux> "hey, your vid.stab homepage is now ffmpeg.org"
[00:55] <Daemon404> ubitux, you mean like libav did to ffmpeg?
[00:55] Action: Daemon404 runs
[00:55] <ubitux> Daemon404: i could try to reproduce it at least
[00:56] <Daemon404> well i intend to post all my samples
[00:56] <Daemon404> since i shot them all myself
[00:56] <Daemon404> and thus free of licenses
[00:56] <ubitux> Daemon404: well i'm assuming ffmpeg will provide an improvement over vid.stab
[00:56] <Daemon404> first improvement would be working at all =p
[00:57] <ubitux> :)
[00:57] <ubitux> well it actually worked with my tests
[00:57] <ubitux> ...except with ffplay, sometimes
[00:57] <Daemon404> "sometimes"
[00:57] <ubitux> some weird bug, which the dev just told me he didn't find the source
[00:57] <Daemon404> best word to hear in bug reports
[00:58] <ubitux> yeah, i tried debugging vid.stab, or reproduce it every time
[00:58] <ubitux> and didn't succeed
[00:58] <Daemon404> i dont think vid.stab is multithreaded...
[00:58] <Daemon404> but i didnt look close
[00:58] <ubitux> all the relevant code remains in two relatively small .c files
[00:59] <ubitux> it is IMO not much work to port it, and could benefit a lot from our optims
[00:59] <ubitux> the way inplace is done is pretty fishy too
[00:59] <Daemon404> not worth porting until it works tho
[00:59] <Daemon404> wait waiy
[00:59] <Daemon404> inplace?
[00:59] <Daemon404> ewwwww
[01:00] <ubitux> yeah well, if in==out it just allocates a new buffer.
[01:00] <ubitux> well anyway, the design is a bit creepy
[01:00] <Daemon404> the bugs im getting make it almost seem like its assuming width=stride somewhere
[01:00] <ubitux> <@Daemon404> not worth porting until it works tho // when it works, it's sometimes devent
[01:00] <ubitux> Daemon404: yep exactly my though
[01:00] <ubitux> and that's actually the case :)
[01:00] <ubitux> i've fixed it locally, but it didn't help
[01:01] <Daemon404> for future reference
[01:01] <ubitux> at least, not the bug i was tracking
[01:01] <Daemon404> a lto of people use // to mean parallel
[01:01] <Daemon404> :P
[01:01] <Daemon404> so careful using it
[01:01] <ubitux> i also think there are some places where src_linesize==dst_linesize is assumed
[01:01] <ubitux> but anyway, the code looked fragile
[01:01] <ubitux> it would benefit a lot from just ffmpeg dev reviews..
[01:02] <Daemon404> while i really want to see it work, not much motivation to review it and wait 2 months for a response
[01:02] <ubitux> i've made various changes to vid.stab locally
[01:02] <ubitux> do you want me to push them in a local repo so you could test?
[01:02] <ubitux> 'might require some little rebasing though
[01:03] <Daemon404> sure.
[01:03] <Daemon404> do you plan to send a PR?
[01:03] <Compn> he contributed!
[01:03] <Daemon404> Compn, no he didnt
[01:03] <Daemon404> he didnt send anything
[01:03] <Daemon404> ;p
[01:03] <ubitux> it didn't fix the bug i was looking for
[01:03] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:91138821fb67: gifdec: check that the last keyframe exists and has been successfully parsed.
[01:03] <cone-170> ffmpeg.git 03Michael Niedermayer 07release/1.1:2e00dd4d6201: Update for 1.1.5
[01:03] <Daemon404> the stride != width thing may be my bug
[01:03] <ubitux> anyway, i'll push something for you
[01:04] <ubitux> give me a few minutes
[01:04] <Daemon404> sure.
[01:04] <Daemon404> im going out tonight so no rush...
[01:06] <ubitux> Daemon404: https://github.com/ubitux/vid.stab/tree/linesize-width
[01:06] <ubitux> feel free to try this
[01:07] <ubitux> float (reference) version needs the change too iirc, but it's only for testing
[01:46] <durandal_1707> ubitux: point of sending fate patches it so try it and report if it fails 
[01:50] <ubitux> TEST    filter-pixfmts-colorchannelmixer
[01:50] <ubitux> works fine
[01:50] <ubitux> but i likely have a similar configuration as your
[02:01] <durandal_1707> doing fate-filter-pixfmts-XXXX:  CMD = pixfmts "YYYYYY,noformat=big_endian_pix_fmts" is gonna work on big-endian, for filters that support native only?
[03:42] <cone-170> ffmpeg.git 03Andrey Utkin 07fatal: ambiguous argument 'refs/tags/n1.1.5': unknown revision or path not in the working tree.
[03:42] <cone-170> Use '--' to separate paths from revisions
[03:42] <cone-170> refs/tags/n1.1.5:HEAD: pngenc: Add 'dpi', 'dpm' options
[04:10] <highgod> Hi, I want to ask a question.http://libav-users.943685.n4.nabble.com/Libav-user-RTP-RTSP-support-in-FFMPEG-td3662032.html does the problem fixed? I test the latest ffmpeg 1.2.1 using ffplay -i rtsp://192.168.0.48/out.264, the output picture is not correct
[04:45] <TheRyuu> 16:30 <@ubitux> TheRyuu: current icc instance is 13.1.1.163, i can update if necessary <---I was curious because of icl on windows (intel keeps compiler versions the same on both platforms?)
[04:45] <michaelni> highgod, did it work with older ffmpeg ? if so you could try git bisect
[04:54] <highgod> I just try the latest ffmpeg1.2.1
[04:54] <highgod> and I have paste the debug log to the mail list
[04:54] <highgod> I didn't compiled the pthreads, is it releated to the bug?
[05:10] <highgod> I enable the pthreads, but the result is sill not correct
[05:11] <highgod> I will paste the put to maillist
[11:23] <cone-739> ffmpeg.git 03Martin Storsjö 07master:b1803c79dcd6: configure: Use enable_weak when enabling pic
[11:23] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:352eb1f02f3c: Merge commit 'b1803c79dcd6d0a345fa1cbe18dd8e2149717121'
[11:29] <cone-739> ffmpeg.git 03Martin Storsjö 07master:e08c946c6860: configure: Explicitly disable PIC when targeting win32/mingw
[11:29] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:6585275e79cd: Merge commit 'e08c946c6860a78b0c479551d5f6735361160cbd'
[11:36] <cone-739> ffmpeg.git 03Diego Biurrun 07master:f54b55058a42: configure: Rename cmov processor capability to i686
[11:36] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:69d52ef8ffcf: Merge commit 'f54b55058a429c4eea5bae7e5bcb49bd29b34199'
[11:41] <ubitux> TheRyuu: ah, ok; i missed that part :)
[11:46] <cone-739> ffmpeg.git 03Diego Biurrun 07master:2c2c48a9bdbe: configure: x86: Only enable cpunop on i686
[11:46] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:df4f4fc8a50b: Merge remote-tracking branch 'qatar/master'
[12:09] <burek> it seems that the link for FFmpeg OSX Static Builds by tessus on our download page links only to ffmpeg/ dir, but there are also ffplay/ and ffprobe/
[12:09] <cone-739> ffmpeg.git 03Paul B Mahol 07master:4383e1b23926: tests/lavf-regression: fix gbrp10 dpx test on big endian
[12:09] <burek> we might update the download page perhaps to reflect that too (although the site does not have any kind of sitemap that would help people figure out those links themselves)
[12:13] <saste> ubitux: dynarray_alloc_elem -> dynarray_add_elem()?
[12:13] <ubitux> saste: i don't care much honestly :)
[12:14] <ubitux> both are fine
[12:14] <ubitux> i just wanted to avoid the 2 function being too close, but no really important
[12:14] <saste> alloc is a bit misleading, since the element is not allocated, is the array which is extended
[12:15] <durandal_1707> burek: what happened to new fate look?
[12:15] <saste> add_elem also is not fine, since the element is not really added, only the space for it
[12:15] <ubitux> saste: another possibilitym, dynarray2_add
[12:15] <burek> durandal_1707 i dunno, not much interest in it right now i guess..
[12:15] <saste> so maybe dynarray_add_space()
[12:15] <ubitux> saste: it suggests the dynarray_add_elem and dynarray_add can be used on the same data
[12:15] <ubitux> which is not fine
[12:16] <durandal_1707> burek: not much interest from you to continue work on it?
[12:16] <saste> dynarray2_add() is also fine with me
[12:16] <durandal_1707> anyone knows why alphaextract/merge fails on msvc?
[12:16] <ubitux> saste: go for it then :)
[12:16] <ubitux> durandal_1707: no :(
[12:16] <ubitux> durandal_1707: same for overlay :(
[12:16] <burek> durandal_1707, no, i can continue the work, just i need to see that you guys are consistent with wishes :)
[12:17] <burek> to avoid doing things several times from scrath :)
[12:17] <burek> scratch*
[12:17] <burek> btw, do ffmpeg preset files support -vf option in it too?
[12:18] <durandal_1707> i just want to have more usable look, do not care for colors ...
[12:18] <burek> define more usable
[12:21] <saste> ubitux, what's your position about drawgrid?
[12:21] <ubitux> commit it, then work on merging the code
[12:22] <saste> ok
[12:22] <saste> feel free to push the code
[12:22] <durandal_1707> burek: anything better than current one, like i would like that ffmpeg links located on top do not get lost
[12:22] <ubitux> saste: i don't have the thread anymore :-°
[12:23] <burek> durandal_1707, i need to go for a while, but feel free what improvements would you like to see (here or in pm) so i can analyze it later, ok? :)
[12:23] <burek> feel free to specify*
[12:29] <saste> ubitux: av_dynarray2_add(void **tab_ptr, int *nb_ptr, char *elem, size_t elem_size)
[12:29] <ubitux> char *elem??
[12:29] <saste> elem contains the pointer to data, so it's more handy if you want to add space and fill it
[12:29] <saste> it can be NULL
[12:30] <ubitux> then "const uint8_t *data" at the end?
[12:30] <saste> of course if elem_size changes,  this will crash and burn
[12:31] <saste> don't know, it seems more intuitive to have element data, and element size in this order
[12:31] <saste> about the char vs. uint8_t i'm fine with whatever
[12:32] <saste> const is sure a good idea
[12:32] <ubitux> i prefer at the end, it kind of reveals that's optional
[12:33] <durandal_1707> nobody going to silence those msvc warnings?
[12:33] <ubitux> first 3 params are for the alloc, and you have optional data at the end for a memcpy
[12:59] <cone-739> ffmpeg.git 03Paul B Mahol 07master:2dedd8988a12: fate: add colorchannelmixer test
[13:30] <cone-739> ffmpeg.git 03Carl Eugen Hoyos 07master:231b33171847: Do not read strd chunk in avi files as H264 extradata.
[13:30] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:e70e2583d071: Merge remote-tracking branch 'cehoyos/master'
[14:05] <durandal11707> saste: i will remove out_histogram from histeq as its unused, and if one really needs it, there is histogram filter
[14:14] <saste> durandal11707, it's only useful for debugging purposes
[14:14] <durandal11707> its useless, same can be gathered with histogram
[14:15] <durandal11707> it was used by histeq just to show histogram
[14:16] <durandal11707> and it also caused crash, that i fixed
[14:19] <durandal11707> because r/g/b could get grow bigger than 255
[14:21] <xlinkz0> is there a command to show GOP size with ffprobe?
[14:21] <xlinkz0> or does someone have a script?
[14:22] <saste> durandal11707, how many lines do you save? why does it bother you?
[14:23] <durandal11707> saste: it does nothing
[14:23] <durandal11707> i save 15 lines
[14:23] <durandal11707> i could put them under ifdef if you prefer that
[14:25] <saste> durandal11707, yes i prefer that, in case i need to debug that again
[14:25] <saste> which is unlikely but not impossible
[14:26] <saste> is it affecting speed?
[14:27] <cone-739> ffmpeg.git 03Stefano Sabatini 07master:84be80698227: lavu: define FF_MEMORY_POISON and use it
[14:27] <cone-739> ffmpeg.git 03Stefano Sabatini 07master:e3984166a49f: lavu/mem: add av_dynarray2_add()
[14:27] <cone-739> ffmpeg.git 03Stefano Sabatini 07master:3a4c8788e323: tools/ffeval: use av_dynarray2_add()
[14:28] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:e6b6ae46951e: vorbisdec: check codebook entry count
[14:30] <durandal11707> saste: i debuged it, and it flawed filter
[14:30] <durandal11707> *it is
[14:31] <saste> durandal11707, how much flawed
[14:33] <durandal11707> saste: it produces useless output in very dark scenes
[14:33] <saste> durandal11707, please file a ticket, or i'll discard about it
[14:33] <saste> if you have a sample, that's useful as well
[14:35] <j-b> good morning
[14:35] <durandal11707> saste: pick any normal video
[14:54] <cone-503> ffmpeg.git 03Michael Niedermayer 07master:f9db2fc84d3d: cdgraphics: initialize buffer
[15:20] <xlinkz0> can i modify the Duration metadata in the format using the ffmpeg tool?
[15:21] <durandal11707> you sure its metadata?
[15:21] <xlinkz0> dunno what it is i just need to modify a file from reporting Duration: 00:00:11.08, start: -5.000000,
[15:21] <xlinkz0> to reporting Duration: 00:00:6.08, start: 0.000000,
[15:22] <JEEB> uhh
[15:22] <JEEB> removing the metadata would mean duration keeps as-is
[15:22] <JEEB> because the -5 is delay
[15:22] <JEEB> so currently the duration with the delay applied is 6 seconds
[15:23] <xlinkz0> yes, unfortunately neither VLC nor the concat demuxer know this
[15:24] <JEEB> you shouldn't expect too much from the latter, and the first one means you'd want to do an issue on their tracker, although it might already be added. And it's just that they don't update their libraries between minor versions
[15:25] <JEEB> anyways, you wouldn't get it to "Duration: 00:00:6.08, start: 0.000000" because if you could have, ffmpeg would've cut there :P
[15:25] <xlinkz0> i need this now, if i had so much time i'd just reencode the videos to have a GOP of 25
[15:52] <ubitux> seems f54b5505 caused quite a bunch of warnings
[15:53] <ubitux> oh, mmh, forget this.
[16:37] <durandal11707> michaelni: can channelmixer test be fixed with -flags +bitexact -sws_flags +accurate_rnd+bitexact ?
[16:38] <durandal11707> or something more sophisticated is required
[16:43] <cone-975> ffmpeg.git 03Paul B Mahol 07master:8671e995c8f9: imgconvert: silence "incompatible pointer type" warning
[17:16] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:45150f90e7dc: fate: fix filter-colorchannelmixer by adding bitexact & accurate flags
[17:19] <durandal_1707> michaelni: idea by me? it was you how did same to histogram*...
[17:29] <xlinkz0> i have a AVFrame with pts = -9223372036854775808
[17:30] <xlinkz0> what should i do?
[17:30] <michaelni> durandal_1707, you sugegsted it for the channelmixer case
[17:39] <xlinkz0> is there a tool that basically is the same as ffprobe except it can edit?
[17:39] <durandal11707> xlinkz0: ask questions on #ffmpeg
[17:53] <cone-975> ffmpeg.git 03Clément BSsch 07master:b3c263e20925: lavu/common: make FF_CEIL_RSHIFT faster when shift is constant.
[17:56] <ubitux> -flags +bitexact was necessary?
[17:56] <ubitux> i guess only sws_flags was necessary
[17:56] <ubitux> but that raises a potential issue
[17:57] <ubitux> if there is an auto inserted scaler (which the commit suggests)
[17:57] <ubitux> then the perms=random likely has no effect.
[17:57] <ubitux> and btw, it's lacking a PERMS dependency
[18:00] <ubitux> durandal11707 ^
[18:00] <durandal11707> i have nothing to say
[18:01] <ubitux> do you plan to fix the problems>
[18:01] <ubitux> ?
[18:02] <durandal11707> there are many problems?
[18:03] <ubitux> potential unecessary -flags +bitexact, lack of dependencies, and perms filter with no effect
[18:03] <ubitux> afaict
[18:05] <durandal11707> there is dependency
[18:06] <ubitux> oh, my bad, i missed it
[18:12] <michaelni> "<ubitux> potential unecessary -flags +bitexact" <-- bitexact is mandatory for regression tests
[18:14] <ubitux> none of the tests with that input have it set here
[18:27] <durandal11707> saste: just to confirm, histeq is broken (even original implementation)
[19:01] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:1e00bbb10cbd: avcodec/lcldec: Check that dimensions are a multiple of the subsample factors
[19:08] <cone-975> ffmpeg.git 03Joseph Artsimovich 07master:3967f6805397: Better handling for MXF essence reading reaching EOF.
[19:10] <durandal11707> saste: so question is: write new filter, or rewrite histeq
[19:16] <durandal11707> ubitux: if you want mergeplanes filter (or something similar) write here how it should operate..
[19:39] <ubitux> durandal11707: i didn't though about it at all :p
[20:13] <durandal11707> why drawtext does not have timeline support?
[20:13] <ubitux> you need to make it run the eval on passthrough
[20:14] <ubitux> should be relatively easy to support though with the timeline internal flag
[20:14] <durandal11707> it have own draw expression
[20:15] <ubitux> actually you might not need to update the eval things
[20:16] <burek> stupid net split
[20:16] <ubitux> freenode still under ddos i guess?
[20:16] <burek> im not sure, but i was left hanging on a dead leaf
[20:17] <burek> btw, I was watching this lecture from Google I/O and I recognized myself in so many examples :D http://www.youtube.com/watch?v=-F-3E8pyjFo
[20:17] <burek> i promise i'll try to change some things :)
[20:26] <ubitux> ah i wanted to watch this a long time ago..
[20:26] <ubitux> "perfectionists", "people obsessed with process"
[20:26] <ubitux> i don't think of you while reading this burek ;)
[20:26] <ubitux> ...though it reminds me people from another project :°
[20:26] <burek> keep reading :D
[20:27] <burek> also, i wish everyone was watching that before the fork thing...
[20:29] <ubitux> i don't think it would have avoid what happened, but who knows... and who cares, won't change anything.
[20:34] <burek> bikeshed theory :)
[20:35] <durandal11707> burek: fate.ffmpeg.org should also list current number of architectures, machines, operating systems, compilers and configurations
[20:36] <burek> durandal11707, can you give a simple example of that?
[20:36] <burek> oh you mean like summary or something
[21:36] <cone-181> ffmpeg.git 03Andrey Utkin 07master:47a628bfb306: avfilter: Add 'drawgrid' video filter
[21:42] <cone-181> ffmpeg.git 03Reimar Döffinger 07master:86215c326e56: Add 128 bit murmur3 hash function.
[21:42] <cone-181> ffmpeg.git 03Reimar Döffinger 07master:7d1d596817e8: Add a generic hash API.
[21:42] <durandal11707> ubitux: so to use lut3d filter one need to get files?
[21:45] <ubitux> yes
[21:45] <durandal11707> no way to generate it?
[21:49] <ubitux> opencolorio framework possibly allow you to do it
[21:49] <ubitux> but i didn't try
[21:55] <cbsrobot> durandal11707: maybe this will work: http://www.arri.com/?id=5986
[21:57] <durandal11707> no way to generate luts not way to test filter...
[21:58] <wm4> ubitux: vf_drawtext sucks to hell
[21:58] <wm4> ubitux: I suggest making something libass based
[21:58] <wm4> just btw.
[21:58] <wm4> (I tried to use it)
[21:58] <durandal11707> vf_drawass
[21:59] <ubitux> wm4: we have vf_ass and vf_subtitles
[21:59] <wm4> that needs a subtitle
[21:59] <ubitux> wm4: what problem do you have with drawtext?
[21:59] <wm4> ubitux: wait, in a moment I'll show you my script (and it is horrible)
[22:30] <nevcairiel> hm
[22:30] <nevcairiel> something is making my fate freeze
[22:30] <nevcairiel> ffmpeg just hangs at 100% cpu and stops working
[22:30] <nevcairiel> must be a change from the last 10 hours or so
[22:31] <Daemon404> check the tst log
[22:31] <Daemon404> oh wait youre run multithreaded
[22:31] <Daemon404> guess it wont be obvious which test
[22:31] <nevcairiel> oddly enough, all 4 threads are hanging :D
[22:31] <Daemon404> o
[22:31] <Daemon404> nice.
[22:33] <nevcairiel> lets see, last successful run was on f9db2fc
[22:33] <nevcairiel> not really all that many commits since that one
[22:35] <durandal11707> b3c263e20925628eabf785afae5a9d7cc5d8bb4d ?
[22:35] <nevcairiel> thats the only one i would put my money on
[22:35] <nevcairiel> but lets test
[22:36] <ubitux> :(
[22:40] <wm4> so I noticed that remixing 2.0 -> quad with libswresample and libavresample leaves the rear speakers silent
[22:40] <wm4> is there a way to get a better upmix without setting a custom matrix?
[22:41] <nevcairiel> submit a patch to auto-generate a upmixing matrix? :)
[22:41] <nevcairiel> otherwise, no
[22:41] <wm4> from what I see in the source, both libs leave channels silent if channels are added but not removed
[22:41] <Daemon404> that seems like the best default behavior to me
[22:42] <nevcairiel> personally i think dumb matrix-upmixing sounds bad in most situations anyway
[22:42] <Daemon404> i agree
[22:42] <nevcairiel> only case where i would use it is music, so you can fill the whole sound room with the same audio
[22:42] <wm4> I don't know, I have no surround setup... but a user complained that playing stereo when forcing quad should not let the rear speakers silent
[22:43] <Daemon404> this is why ffdshow used to let yo uset a custom matrix through the GUI
[22:43] <Daemon404> to appease lusers
[22:43] <Daemon404> <.<
[22:43] <Daemon404> >.>
[22:43] <wm4> why is multi-channel audio so complex: http://ompldr.org/vaTE1dw
[22:43] <nevcairiel> people have been bugging me to do that
[22:44] <Daemon404> nevcairiel, i dunno.. i only ever used it once
[22:44] <Daemon404> to remap a wrongly-mapped flac file
[22:45] <kierank> surround sound is hard 
[22:45] <nevcairiel> ubitux: reverted your commit
[22:45] <nevcairiel> ubitux: still hangs
[22:45] <nevcairiel> :P
[22:45] <ubitux> \o/
[22:45] <Daemon404> bisect time
[22:46] <nevcairiel> i'll attach a debugger and seeeee
[22:46] <nevcairiel> wtf its doing
[22:46] Action: ubitux hope there is not another commit from him in the history
[22:46] <Daemon404> mind you
[22:46] <Daemon404> i avoid bisecting ffmpeg usually
[22:46] <nevcairiel> its horrible
[22:46] <Daemon404> because all the merge commits screw royally with it
[22:46] <nevcairiel> you end up in libav branches
[22:46] <Daemon404> yea
[22:47] <nevcairiel> ah damnit no debug symbols in this damn build
[22:47] <ubitux> _g ?
[22:47] <nevcairiel> didnt i send a patch yet
[22:47] <Daemon404> hes probably using msvc
[22:47] <nevcairiel> of course
[22:47] <nevcairiel> because thats what hangs
[22:49] <nevcairiel> now i need to rebuild \o/
[23:02] <Daemon404> ^ mine, box is down for fixin
[23:05] <nevcairiel> how odd
[23:05] <nevcairiel> it hangs in some av opt function
[23:05] <nevcairiel> in cmdutils
[23:05] <wm4>     { "6.1",         7,  AV_CH_LAYOUT_6POINT1 },
[23:05] <wm4>     { "6.1",         7,  AV_CH_LAYOUT_6POINT1_BACK },
[23:05] <wm4> shouldn't the second be named 6.1(back)
[23:05] <wm4> ?
[23:11] <durandal11707> git blame
[23:11] <durandal11707> probably yes
[23:18] <durandal11707> nevcairiel: hash api?
[23:23] <nevcairiel> yeah for some odd reason, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7d1d596817e8578cca1605f37342a4986bf70027 causes the freeze
[23:24] <nevcairiel> something must be wrong with the AVOptions setup
[23:25] <ubitux> same priv_class maybe
[23:26] <nevcairiel> it causes and endless loop if two formats have the same priv class?
[23:26] <ubitux> i remember something like that when playing with filters
[23:26] <michaelni> yes
[23:27] <Daemon404> ubitux, btw that patchset fixed my issue
[23:27] <Daemon404> in vid.stab
[23:27] <Daemon404> though vid.stab is /still/ not cropping right
[23:27] <ubitux> Daemon404: ah? cool :)
[23:27] <Daemon404> lots of big black borders
[23:27] <Daemon404> eve with optzoom
[23:27] <Daemon404> makes it essentially useless
[23:27] <ubitux> you have options to fill the gaps iirc
[23:27] <Daemon404> with old view or black.
[23:27] <Daemon404> both look like shit.
[23:27] <Daemon404> read; broken
[23:28] <Daemon404> and autozoom doesnt zoom enough ;)
[23:28] <Daemon404> i know it's possible; vdub's deshaker does it
[23:28] <Daemon404> (too bad thats not FOSS)
[23:28] <wm4> #define AV_CH_LAYOUT_5POINT0_BACK      (AV_CH_LAYOUT_SURROUND|AV_CH_BACK_LEFT|AV_CH_BACK_RI
[23:28] <wm4> GHT)
[23:28] <wm4> #define AV_CH_LAYOUT_5POINT1_BACK      (AV_CH_LAYOUT_5POINT0_BACK|AV_CH_LOW_FREQUENCY)
[23:28] <wm4> that's... confusing
[23:28] <michaelni> abput bisect & merges, see tools/bisect-create and tools/ffbisect, with them you can just say ffbisect need ffmpeg and it will give only checkouts that contain ffmpeg (or ffplay or whatever)
[23:28] <Daemon404> michaelni, thanks
[23:29] <Daemon404> thats useful
[23:30] <ubitux> nevcairiel: see how we workaround in for instance lavfi/f_perms.c
[23:31] <ubitux> it's strange that it doesn't happen on other instances though
[23:32] <Daemon404> who runs fate.ffmpeg.org btw?
[23:32] <Daemon404> i think it's in need ofr some new hw desparately...
[23:33] <Daemon404> suuuuuuuuuper slow
[23:33] <nevcairiel> fate is just super inefficient
[23:33] <nevcairiel> what it should do is purge some old build records
[23:33] <Daemon404> libav's isnt like that
[23:33] <llogan> is it baptiste? wasn't he doing something with it recently?
[23:34] <Daemon404> i know he adds keys
[23:34] <Daemon404> i dont know about the actual server though
[23:34] <Daemon404> speaking of which, since im moving to the UK soon, i figure I might donate some hardware
[23:34] <Daemon404> which i cannot bring with me
[23:36] <Compn> where are you at now ?
[23:36] <Daemon404> Ontario, Canada
[23:36] <Daemon404> northwwest
[23:36] <llogan> is that in france?
[23:36] <Compn> lol
[23:37] <Compn> not far from me, near detroit
[23:37] <Compn> well, 'far' , ontario is a big place
[23:37] <Daemon404> i dont have any plan to go to detroit
[23:37] <Daemon404> ever.
[23:37] <Compn> lol
[23:37] <nevcairiel> i send a patch splitting the priv class, fixing msvc runs
[23:38] <nevcairiel> for the record, its not only MSVC that hangs, my mingw instance also hangs
[23:38] <nevcairiel> so must be a windows thing
[23:38] <nevcairiel> or a me thing
[23:38] <nevcairiel> :)
[23:39] <Daemon404> my msvc insance has been offline for a while...
[23:41] <nevcairiel> i'm not sure everything else is running fine, a lot of things havent reached that revision yet and are overdue for a new build
[23:41] <nevcairiel> on fate, i mean
[23:42] <nevcairiel> in fact, not one fate box has build it yet =p
[23:42] <Daemon404> maybe theyre all hanging
[23:42] <Daemon404> ;)
[23:43] <nevcairiel> it should be 53031, latest on fate is 53029
[23:43] <nevcairiel> anyway, patch on ML
[23:43] <cone-181> ffmpeg.git 03Hendrik Leppkes 07master:37d978408324: md5enc: don't reuse priv_class in two formats
[23:44] <nevcairiel> all those poor fate maintainers that need to kill their fate processes now
[23:46] <Daemon404> that was fast
[23:46] <ubitux> ah indeed it seems to be stalled
[23:46] <ubitux> :))
[23:47] <nevcairiel> someone bonk reimar i suppose
[23:47] <michaelni> ubitux, you might want to set ulimit -t something on your fate boxes
[23:47] <ubitux> it was stalled just a minute ago actually
[23:48] <ubitux> i don't care much
[23:49] <ubitux> and i'd prefer to avoid ulimit with my helgrind/drd boxes taking 6-7 hours to run :p
[23:56] <j-b> michaelni: http://people.videolan.org/~jb/tmp/winrt/0002-Do-not-use-GetProcAddress-when-compiled-for-Vista.patch just in case, who could review this?
[23:57] <Compn> dont know if anyone devels on vista
[23:57] <Compn> i have a vista box tho
[23:58] <Daemon404> Compn, that is only enabled if the compiler says its targetting that
[23:58] <Daemon404> so normal builds are not affected
[23:58] <Daemon404> (mingw targets xp)
[00:00] --- Tue May 14 2013