[01:18] <cone-86> ffmpeg.git 03Paul B Mahol 07master:2952ed2b6076: doc/filters: move telecine from audio to video filters [02:25] <cone-86> ffmpeg.git 03Paul B Mahol 07master:03e2ec32b88f: lavfi: add smptehdbars source [02:27] <ubitux> - * smptebars is by Paul B Mahol. [02:27] <ubitux> + * smptebars and smptehdbars is by Paul B Mahol. [02:27] <ubitux> durandal_1707: "are" ^ [02:28] <durandal_1707> ubitux: received too late [02:31] <ubitux> sent too late [02:31] <ubitux> i'm reviewing on cvslog [02:34] <durandal_1707> i dont read cvslogs [02:35] <durandal_1707> i wondering about filter that is doing something reverse of interleave [02:36] <durandal_1707> for example see: split[a][b],[a]select=not(mod(n\,2))[aa],[b]select=(mod(n\,2))[bb],[aa][bb]blend=average' [02:37] <durandal_1707> this is suboptimal, because if you change from even/odd queue gets full [02:59] Action: ubitux just did something kinda cool [03:00] <durandal_1707> sent patch to l? [03:01] <ubitux> haha no [03:01] <ubitux> i'll send the patchset soon, just need a few more adjustments :) [03:03] <durandal_1707> saste: did explored that histeq behaviour? [03:08] <ubitux> here we go. [03:08] <ubitux> cool patch is 5/5 [03:08] <ubitux> i'm not sure it's relevant in practice but well [03:10] <ubitux> i want to add some string interpolation with bprint and dict now [03:11] <durandal_1707> isn there already better/faster one with trees? [03:11] <durandal_1707> see libavutil/dict.h [03:11] <ubitux> possibly :) [03:12] <ubitux> but since our code use a lot of av dict [03:12] <ubitux> i thought it was a good idea :p [03:13] <ubitux> maybe it would be possible to use the tree inside the dict, but i'm not sure it will really simplify that code [03:16] <durandal_1707> maybe i will port virtualdub deflicker [03:17] <ubitux> yeah [03:17] <ubitux> that would be nice :) [03:17] <ubitux> a flicker filter as well btw [03:18] <durandal_1707> doesn't that just apply curves to luma [03:19] <ubitux> i was thinking of a degradation filter actually [03:19] <ubitux> with the vertical lines and random artefacts [03:27] <durandal_1707> looking at code is soo trivial.... [03:27] <cone-86> ffmpeg.git 03Clément BSsch 07master:d9be6e69cf00: lavfi/testsrc: grammar fix in comment after 03e2ec32. [10:35] <cone-349> ffmpeg.git 03Clément BSsch 07master:f359be96cacb: lavfi/smptehdbars: fix priv_class pointer. [11:36] <cehoyos> Hi! Can somebody explain the option "-to" to me? [11:36] <cehoyos> (What is the difference between -t and -to ?) [11:38] <ubitux> -to is an absolute time [11:39] <ubitux> while -t is a duration [11:39] <cehoyos> I tested the following: [11:39] <cehoyos> ffmpeg -ss 10 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -to 20 -an out.avi [11:40] <cehoyos> ffmpeg -ss 10 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 20 -an out2.avi [11:40] <cehoyos> out.avi and out2.avi are identical. [11:40] <ubitux> what if you move the -ss as output option? [11:41] <cehoyos> I just did and it works, but I don't find that 100% obvious. [11:41] <ubitux> maybe it's a bug [11:41] <cehoyos> It's at least not a regression [12:31] <ubitux> any idea why av_dict_copy is ignoring suffixes? [12:37] <ubitux> mmh i may be able to get this stuff a bit faster [12:46] <ubitux> michaelni: speedloss only happens with the non-default -sws_flags +full_chroma_int? [12:55] <cehoyos> Iiuc: Workaround for several reported bugs is -sws_flags +full_chroma_int which causes a speed regression, Michael's patches fix output for default, but also produces speed loss [12:56] <michaelni> cehoyos, yes [12:58] <cehoyos> Ticket 2467 looks interesting if somebody works on filters... [13:31] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:662664551c80: sws/output: factor yuv2rgb_write_full() out [15:10] <ubitux> isn't it today that we can have some feedback on gsoc? [15:11] <ubitux> or i'm mistaken? [15:16] <michaelni> ubitux, dunno, this year saste & logan are admin and responsible for gsoc [15:24] <JEEB> it feels like an end of an era when you don't have ffmpeg (or its forks) nor VideoLAN and things under its umbrella in GSoC :< [15:24] <ubitux> yes but there is phpmyadmin so it's ok [15:25] <JEEB> hahaha [15:27] <michaelni> it would be interresting to know if there are other large projects that where in gsoc for long and then where no longer accepted multiple years [15:35] <michaelni> and of course whenever that "why was your project not accepted" thing is, we should have a few people at #gsoc and ask there [15:37] <michaelni> Re: [FFmpeg-devel] [RFC] Google Summer of Code 2013: We can get feedback as to [15:37] <michaelni> why we were not accepted in #gsoc (Freenode) on Friday, April 19, 2013 [15:37] <michaelni> at 16:00 UTC. [15:39] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:9204a7dc8ee6: sws/output: add +yuv2rgb_full_2_c_template() [15:39] <ubitux> ah, 19, my bad, ok [16:00] <cone-349> ffmpeg.git 03Clément BSsch 07master:ab0ad6eccf38: lavfi: rename decimate to mpdecimate. [16:00] <cone-349> ffmpeg.git 03Clément BSsch 07master:7a92ec93c650: lavfi: port IVTC filters from vapoursynth. [16:00] <cone-349> ffmpeg.git 03Clément BSsch 07master:458d956b0964: doc/filters: move mpdecimate doc to a more appropriate position. [16:09] <ubitux> ok, what remaining mp filter is important? [16:12] <ubitux> btw, did anyone look at the differences between tinterlace and interlace? [17:08] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:a4b5e45e2bbc: sws/output: add yuv2rgb_full_1_c_template() [17:08] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:41ebb64511dc: swscale/output: fix alpha scale in the new functions [19:56] <jomp16> Hey, newbie question: how to compile FFMPEG for Android ARMv7 NEON? [20:06] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:d4956b0bfbf9: sws/input: replace hardcoded rgb2yuv coefficients by table [20:08] <michaelni> jomp16, did you try google and if that fails the ffmpeg-user mailing list ? [20:09] <cehoyos> Yuvi: Do you have access to PPC64 OSX? [20:09] <michaelni> also there are android targets on http://fate.ffmpeg.org/ the parameters used to build them should be there toom these might be a startpoint as well [20:10] <cehoyos> gas-preprocessor seems to fail there. [20:10] <cehoyos> (fail: libavcodec/ppc/fft_altivec_s cannot be compiled) [20:17] <jomp16> michaelni, so, i can use the configure prefix and put a neon instruction? [20:21] <cone-349> ffmpeg.git 03Clément BSsch 07master:1e3104cd3cd1: Add avpriv_dsputil_init() and use it in lavfi where relevant. [20:33] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:fba3a3bbfba3: doc: document -opencl_options option in ff* tools manuals [20:33] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:f6c9a325b727: ffmpeg: show error message in case of av_buffersrc_add_frame_flags() failure [20:35] <ubitux> saste: so, is it possible to do some kind of timeline with interleave filter? [20:35] <ubitux> and how much can it does it? [20:35] <saste> ubitux, "timeline"? [20:36] <ubitux> basically can i blur from 1 minute to 5 minutes using the filter? [20:36] <ubitux> select='between(t,60,60*5):branch=1 [x], boxblur=2:2, [x] interleave' [20:37] <ubitux> would that work? [20:37] <cehoyos> Regarding "Add avpriv_dsputil_init": deshake currently crashes on sse2 for rx%16 != 0 - would it be a solution to pass the expected alignment to dsputil_init() ? [20:38] <saste> ubitux: I don't think so [20:38] <ubitux> saste: why does the random work then? [20:38] <ubitux> cehoyos: huh? a problem with the recent patch? or it just make you think of another issue? [20:39] <cehoyos> It just made me think of ticket 2443 [20:39] <ubitux> ok [20:39] <cehoyos> (There are two issues: It made me think of rx=20, there is a - probably different - issue with rx=64) [20:39] <saste> ubitux, interleave needs to have both inputs with available frames [20:40] <ubitux> saste: with your flickering blur effect it doesn't look like to be the case either, unless i'm missing something? [20:40] <saste> so it starts, ask for the first input, get the first frame [20:40] <saste> now the second queue still doesn't have frames, so it asks select [20:41] <saste> select will return frames from the first path, so it will fill the first queue and will start to drop frame [20:41] <saste> when the first frame arrives in the second output, you dropped already a lot of frames [20:41] <saste> of course we could extend the queue, but in that case we can end up by filling a lot of memory [20:42] <saste> right now we have a queue of 32 frames [20:42] <ubitux> right so that's the reason it works "most of the time" with the random 0.2 [20:43] <durandal_1707> hmm. cant interleave call request_frame when it actually needs one? [20:43] <saste> ubitux: yes, if you increase the decrease that value it starts to drop frames [20:43] <ubitux> durandal_1707: calling request_frame on select will only raise you the frames you don't want [20:43] <ubitux> if you're not in the range [20:43] <saste> durandal_1707, how do you know which frame to send if you don't have at least one frame in each queue? [20:44] <durandal_1707> i was wondering about reverse of interleave, but cant find good name (split is already taken, and was already bad pick, as split is more like clone) [20:44] <ubitux> anyway, so timeline not for today :( [20:44] <ubitux> durandal_1707: torn [20:44] <saste> ubitux, global enable function [20:44] <saste> and callback [20:44] <ubitux> hehe right [20:44] <durandal_1707> saste: i mean request frame inside interleave filter [20:45] <durandal_1707> and not using select because that fills queque [20:45] <saste> durandal_1707, what do you mean by "inverse" of interleave? [20:45] <saste> you could extend select, indeed i plan to do that [20:46] <durandal_1707> but avisynth have feature iirc that it does not produce frame that will be later dropped [20:46] <durandal_1707> saste: select takes frames and drop random ones .... [20:46] <saste> durandal_1707, what features do you want to achieve? [20:46] <durandal_1707> by inverse interleave i mean filter that take single input and produce multiple outputs [20:47] <saste> durandal_1707, see my branch option to select, and the idea of nicolas [20:47] <durandal_1707> and puting each input frame to one of outputs ... [20:47] <durandal_1707> saste: select should just select, and not do some other stuff ... [20:48] <durandal_1707> you are complicated already complicated filter [20:48] <saste> durandal_1707, you can have multiple outputs, and let select "selects" the output [20:48] <saste> for example [20:48] <durandal_1707> that would still fill up queque [20:48] <saste> select=n=3:e='mod(n,3)' [20:49] <saste> durandal_1707, we can avoid frame drop, but there is the possibility to fill memory [20:49] <ubitux> select=between(t,60,60*5) [a]; select=not(between(t,60,60*5)) [b]; [a][b] interleave [20:50] <saste> but i agree the queue size should be configurable [20:50] <ubitux> this would work, right? [20:50] <saste> yes [20:50] <ubitux> what if select would have 2 contexts? [20:50] <durandal_1707> queue size eats memory [20:50] <ubitux> (internally) [20:50] <ubitux> (to reproduce that behaviour) [20:50] <ubitux> is that possible? [20:51] <durandal_1707> what if i want to use blend filter on input and input+few frames forward/backward.... [20:52] <durandal_1707> what about those filter descriptions that have . at end and others that do not have? [20:53] <ubitux> i remember adding the periods to all of them [20:53] <ubitux> but maybe some new filters don't have them [20:54] <ubitux> ah i forgot in fieldmatch [20:54] <ubitux> otherwise only 3 filters are missing it, the filters from libav [20:54] <durandal_1707> codecs/formats do not have them [20:54] <durandal_1707> i find that dots little funny .... [20:55] <saste> durandal_1707, we discussed the convention [20:55] <saste> IIRC that was a suggestion from diego [20:56] <saste> that's because filter description is not a nominal form, but a full sentence with verb [20:56] <saste> note that we have the same framedrop problem with overlay as well [20:56] <saste> which is sometimes annoying [20:57] <saste> so I'd like at least to be able to extend the queue size with no recompilation [20:57] <durandal_1707> saste: that actually fix problem (to me its just band-aid) [20:58] <saste> durandal_1707, the problem is that we don't want to fill all the memory [20:59] <durandal_1707> so changing 32 to 64 is really fix? [20:59] <cone-349> ffmpeg.git 03Clément BSsch 07master:dfac37afd250: lavfi: add missing periods in filter descriptions. [21:01] <durandal_1707> michaelni: did you have patch that address that infinite loop when someone (like me) messes up .priv_class ? [21:01] <durandal_1707> ubitux: what happened to that flush patch? [21:01] <ubitux> durandal_1707: i felt uneasy :p [21:02] <ubitux> i could push it now though [21:02] <durandal_1707> i see no problem as default is to always flush .... [21:03] <ubitux> yes, but if you disable flushing it should not break [21:04] <ubitux> i'll push in a moment [21:06] <ubitux> so anyway [21:06] <ubitux> now that we have some ivtc filters [21:06] <ubitux> what do we drop? [21:06] <ubitux> cehoyos: you are interested in keeping pullup? [21:07] <ubitux> durandal_1707: what's left in mp except eq2 and spp? [21:07] <ubitux> maybe mcdeint? [21:07] <durandal_1707> ow (what/where/when/how it helps) [21:08] <ubitux> is it efficient? [21:09] <saste> perspective [21:09] <ubitux> it seems to fuck up the pts at least somehow [21:10] <ubitux> or maybe that's mp [21:10] <saste> sab? [21:10] <ubitux> ? [21:11] <durandal_1707> ubitux: its slow, its wavelet denoiser, so only reason to keep it is if it gives better output than other denoises in some if not all scenarios [21:11] <saste> mp=sab [21:11] <ubitux> saste: no, ow [21:12] <ubitux> ah, relevant filters. [21:12] <ubitux> ok [21:12] <ubitux> durandal_1707: ok [21:12] <ubitux> i want a fft denoiser... [21:12] <ubitux> :( [21:12] <ubitux> but no 2d fft (yeah i know i repeat myself) [21:12] <Compn> why is ivtc called fieldmatch? [21:12] <Compn> :P [21:13] <ubitux> Compn: because ivtc is fieldmatch+decimate [21:13] <durandal_1707> what is this phase filter? [21:13] <Compn> ubitux : what do they call it in vapoursynth ? fieldmatch ? [21:13] <ubitux> Compn: tfm in avisynth (tritical fieldmatch, tritical being the name of the dude), vfm in vsynth (i let you guess what it means) [21:14] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:bc1847addf34: doc/filters: remove mention to telecine mp filter [21:14] <Compn> lol ok [21:14] <Compn> just making sure ... [21:14] <durandal_1707> softpulldown is another teleciner [21:15] <Compn> ubitux : i just want to make sure if someone tells a user he needs 'ivtc' that he can find out it means 'field match' [21:15] <durandal_1707> Compn: they already know that ... [21:16] <ubitux> Compn: first paragraph of fieldmatch says it all [21:16] <cone-349> ffmpeg.git 03Clément BSsch 07master:8de9bb6e5e52: lavf: remove some flushing in write_packet muxers callbacks. [21:17] <durandal_1707> the only reason to keep pullup is if it is faster than fieldmatch for 3:2 case [21:17] <ubitux> yes fieldmatch is not meant to be used for realtime [21:18] <durandal_1707> and there is no realtime flag? [21:18] <ubitux> you can make it faster by playing with the combmatch mode [21:18] <ubitux> also, decimate is slow and needs to queue 5 frames [21:20] <durandal_1707> well one dont need to use decimate too [21:20] <ubitux> well actually it does [21:20] <ubitux> the flickering is visible [21:24] <ubitux> ./ffplay ~/fate-samples/smjpeg/scenwin.mjpg -vf 'split=3[a][b][c]; [a]pad=iw*3,drawtext=text=origin:fontcolor=yellow[p]; [b]hqdn3d,drawtext=text=hqdn3d:fontcolor=yellow[h]; [c]mp=ow,drawtext=text=ow:fontcolor=yellow[o]; [p][h]overlay=w[p2]; [p2][o]overlay=w*2' [21:24] <ubitux> of course, configuration etc. [21:27] <durandal_1707> ubitux: i dont have drawtext, so tell what that does [21:27] <ubitux> http://ubitux.fr/pub/pics/_orig-hqdn3d-ow.png [21:30] <durandal_1707> it read some args that are never used [21:31] <cehoyos> ubitux: Yes, you told me it is faster than ivtc [21:31] <ubitux> cehoyos: so you're porting? ;) [21:32] <cehoyos> I think that would be exceptionally unproductive [21:32] <ubitux> :) [21:33] <cehoyos> actually inefficient, sorry [21:33] <ubitux> ask l. to do it [21:33] <ubitux> and compete with them [21:33] <durandal_1707> ubitux: porting? its just select=(3 of 5) [21:33] <ubitux> durandal_1707: pullup? [21:34] <ubitux> i believe split in multiple files and the asm all around is not just a decimate [21:36] <saste> ubitux, should I still implement per-frame eval support in volume? [21:36] <saste> the same way I did in overlay [21:36] <saste> (maybe with eval=init by default) [21:37] <ubitux> as you wish, i just want av_eval_is_const [21:37] <ubitux> and i can deal with the rest [21:37] <ubitux> :D [21:37] <michaelni> ./ffplay fate-suite/smjpeg/scenwin.mjpg -vf 'noise=1:20,split=3[a][b][c]; [a]pad=iw*3[p]; [b]hqdn3d[h]; [c]mp=ow=10:16:16[o]; [p][h]overlay=w[p2]; [p2][o]overlay=w*2' [21:38] <ubitux> is it a boxblur? [21:38] <ubitux> :D [21:41] <durandal_1707> boxblur give blur output [21:43] <ubitux> ow=10:16:16 too [21:43] <ubitux> somehow :) [21:43] <michaelni> try a fft :) [21:43] <durandal_1707> ubitux: its not that blur.... [21:45] <durandal_1707> mp=ow=20 segv here [21:45] <michaelni> yes, it doesnt like large depths [21:49] <michaelni> durandal_1707, patch for handling duplicate AVClasses posted [21:50] <durandal_1707> does it slows stuff? [21:51] <michaelni> ubitux, to compare with boxblur: ./ffplay fate-suite/smjpeg/scenwin.mjpg -vf 'noise=1:20,split=3[a][b][c]; [a]boxblur=1,pad=iw*3[p]; [b]boxblur=2[h]; [c]mp=ow=10:16:16:0[o]; [p][h]overlay=w[p2]; [p2][o]overlay=w*2' [21:51] <durandal_1707> but i wanted assert/warning and not workaround ... [21:52] <ubitux> :) [21:52] <michaelni> durandal_1707, easy to do by changing the code from the patch but should we disallow it at all ? [21:53] <ubitux> i think so for now [21:53] <durandal_1707> michaelni: i dont think allowing it is smart idea [21:55] <durandal_1707> michaelni: i still wanted to know what was meant to be used with unused args like delta & mode [21:56] <michaelni> i am fine with disallowing it too but does it make that much sense? i mean assert or infloop is about the same [21:56] <michaelni> mode was for switching between hard and soft thresholding IIRC [21:56] <michaelni> was MEANT for [22:00] <durandal_1707> so pullup is actually useful? [22:01] <michaelni> about the speed effects of the dup class patch, it is probably a 50% slowdown for the function [22:02] <durandal_1707> michaelni: i was just wanted to fix loop, so assert is better than machine hang [22:03] <durandal_1707> so if it is possible to detect loop in fast way - its optimal solution to me [22:05] <michaelni> it can be done with 50% slowdown or fast with ABI break or fast with complex code, iam not really likeing any of these options though [22:08] <ubitux> saste: i'm going to try to implement the enable thing [22:08] <ubitux> unless you want to do it [22:09] <saste> ubitux, go on [22:09] <saste> i have too many pending patches to work on [22:09] <ubitux> yes [22:14] <durandal11707> hmm, could lavfi do tehnicolor/sepia ? [22:16] <saste> durandal11707, curves? [22:22] <durandal11707> example needed [22:22] <ubitux> -vf curves=vintage [22:23] <ubitux> feel free to add more profiles [22:23] <ubitux> hint: google for "photoshop + curves + technicolor|sepia" [22:24] <ubitux> grab the settings from tutorials and use them in vf curves [22:27] <Yuvi> cehoyos: nope, all my ppc machines died [22:41] <ubitux> AVOptions are real dark magic :) [22:41] <ubitux> actually, more the classes [22:56] <cehoyos> Yuvi: Does the error message help you? [22:56] <cehoyos> The problem is that I don't even know how to debug gas-preprocessor... [22:58] <cehoyos> (ie: How do I show its output?) [22:58] <Yuvi> what error message? [22:58] <saste> cehoyos, the vid.stab dev preferred to work on an external lib so he has more development freedom [22:59] <Yuvi> set GASPP_DEBUG and it'll dump the preprocessed file to stdout [22:59] <saste> and it can be used outside the scope of ffmpeg, which is perfectly fine imo [22:59] <cehoyos> And he should have been told that this is not a good idea. [22:59] <cehoyos> Of course it is "fine", but that doesn't make it a good idea. [22:59] <cehoyos> We don't even test compilation for all external libraries. [23:00] <cehoyos> Yuvi: "./configure --cc='gcc -m64'" [23:00] <saste> cehoyos, we discussed that to death on ML [23:00] <cehoyos> (OSX gcc defaults to -m32) [23:01] <saste> it is imo a good idea [23:01] <cehoyos> The library is doomed to rot imo [23:01] <cehoyos> (Sorry, I did not start the discussion) [23:01] <Yuvi> is it llvm-gcc? [23:02] <Yuvi> because I don't think llvm's ppc backend was ever fully working [23:02] <cehoyos> Yuvi: "make V=1 libavcodec/ppc/fft_altivec_s.o" fails with "libavcodec/ppc/fft_altivec_s.S:693:Invalid mnemonic 'tocbase,'" [23:02] <saste> cehoyos, when it will rot will port it [23:03] <saste> (as know, ffmpeg preys on ill and rotting projects) [23:03] <saste> *as known [23:04] <cehoyos> I am unsure, but I suspect OSX ppc predates llvm-gcc [23:04] <cehoyos> "gcc version 4.0.1 (Apple Inc. build 5493)" <- is that sufficient to know? [23:04] <cehoyos> It fails identically with 4.2 [23:04] <Yuvi> yeah, that's pure gcc (that I don't have anymore actually) [23:04] <durandal11707> ubitux: gonna write colorbalance? [23:05] <ubitux> nope [23:05] <Yuvi> set GASPP_DEBUG and paste the preprocessed output? [23:05] <cehoyos> durandal11707: Do you want to look at the fate-random failure? [23:05] <ubitux> durandal11707: the only filter remaining in my TODO list is the vignette/lens one [23:05] <cehoyos> export GASPP_DEBUG=1 ? [23:05] <Yuvi> yeah [23:05] <durandal11707> ubitux: than you are leaving? [23:05] <ubitux> nope [23:06] <ubitux> i'm adding timeline support in lavfi [23:06] <durandal11707> cehoyos: i'm in filter land now, do not disturb me [23:06] <ubitux> i would love to write more filters, but i want a better fft api :p [23:06] <ubitux> haha [23:06] <cehoyos> LOL [23:07] <cehoyos> Yuvi: ok, I have a huge asm file now [23:07] <cehoyos> But the file numbers in the error message still don't match the file... [23:08] <cehoyos> But I found: ".quad .ff_fft_calc_altivec, .TOC.@tocbase, 0" [23:08] <Yuvi> yeah they won't, but something with tocbase should be obviously wrong [23:08] <Yuvi> hm [23:08] <Yuvi> I'm not familiar with ppc relocations [23:08] <cehoyos> tocbase is there twice, and the error is shown twice. [23:09] <cehoyos> I am not sure I know what relocations are ;-) [23:10] <Yuvi> does that work for linux ppc64? [23:10] <Yuvi> I don't think it ever worked for os x ppc64 at least [23:10] <cehoyos> Yuvi; There is a second error:" libavcodec/ppc/fft_altivec_s.S:726:Invalid mnemonic 'got(r2)'" - "ld r6, fft_data@got(r2)" [23:11] <Yuvi> yeah those are coming from extfunc/movrel in asm.S; gas-preprocessor is expanding things correctly [23:11] <cehoyos> Yuvi; Could you check fate.libav.org ? (My ip is blocked) [23:11] <Yuvi> dunno if they're valid for any ppc64 or if mach-o just doen't support them [23:12] <Yuvi> OK, looks like linux ppc64 works [23:12] <cehoyos> Ticket 56 indicates that it works [23:12] <Yuvi> err but darwin ppc64 says it works too [23:13] <cehoyos> It fails here (I tested it) [23:13] <cehoyos> How does the configure line look like? [23:13] <cehoyos> (Actually: How does configure's output look like?) [23:13] <Yuvi> --enable-gpl --arch=ppc64 --cc='ccache gcc-4.2 -m64' --disable-debug --enable-shared [23:13] <cone-349> ffmpeg.git 03Paul B Mahol 07master:6ffe9113026a: lavfi/testsrc: unbreak smptebars only build [23:14] <Yuvi> http://pastie.org/7549319 [23:14] <Yuvi> so no gas preproc [23:16] <cehoyos> Yes, it works fine without gas-preprocessor ;-) - LOL [23:16] <cehoyos> It's funny that configure requests something that does not work. [23:18] <cehoyos> Yuvi: OT: Did you never receive an email from me asking to merge gas-preprocessor changes (before it was discussed on ffmpeg-devel and here)? [23:20] <Yuvi> oh looks like I did, sorry I didn't see it [23:21] <cehoyos> np, I just wanted to konw... [23:21] <cehoyos> What would you need to fix gas / how do we find out if it can be fixed? [23:22] <Yuvi> oh wait is ARCH_PPC64 set? [23:22] <Yuvi> and CONFIG_PIC [23:23] <Yuvi> err, of course it is [23:23] <Yuvi> tocbase isn't anywhere else [23:23] <cehoyos> CONFIG_PIC is 1 [23:25] <cehoyos> CONFIG_PIC can be 0 (--disable-shared) or 1 (--enable-shared), both fail [23:25] <Yuvi> easiest way would be to check for [23:25] <Yuvi> .quad .Blah, .TOC.@tocbase, 0 [23:25] <Yuvi> or just disable asm for ppc64 / darwin [23:25] <Yuvi> since it's never worked [23:25] <cehoyos> There are a few asm optimizations outside of .S files [23:26] <Yuvi> isn't there a separate flag for those? [23:26] <cehoyos> ? [23:26] <Yuvi> inline-asm or something [23:28] <Yuvi> like just disable gnu_as [23:29] <Yuvi> I'll try to figure out how to do mach-o ppc64 relocations though, but I'll just be guessing [23:29] <cehoyos> I can test;-) [23:35] <cehoyos> Reimar could theoretically help imo, but he currently explains MPlayer code to wm4 ;-) [23:36] <ubitux> rha i can't get that passthrough working :( [23:37] <durandal11707> of what? [23:38] <ubitux> i'm adding the global filter option enable [23:38] <ubitux> so far the expression works fine [23:38] <ubitux> but i'm unable to make a passthrough filter_frame working [23:38] <ubitux> it seems to assert somewhere for some reason [23:38] <ubitux> i'm almost there! :( [23:42] <ubitux> AHAH! [23:42] <ubitux> it works! [23:42] <ubitux> timelines in lavfi \o/ [23:43] <ubitux> ./ffplay ~/samples/GoneNutty.avi -vf 'curves=vintage:enable=between(t\,2\,5)' [23:43] <ubitux> \o/ [23:44] <ubitux> 50 lines of diff [23:44] <ubitux> that was too easy [23:46] <durandal11707> hmm you added that to single filter? [23:46] <ubitux> no [23:46] <ubitux> generic option [23:46] <ubitux> works theorically with every filter [23:46] <durandal11707> i cant add enable option to my filter? [23:47] <ubitux> i can adjust the code so it is possible and take the priority [23:47] <ubitux> but you should not need it [23:47] <ubitux> i'll make a special callback for the passthrough for filters who need some local updates [00:00] --- Mon Apr 15 2013