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

[burek]

[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. at 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 at 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. at 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