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

[burek]

[00:56] <cone-913> ffmpeg.git 03Piotr Bandurski 07master:9c50e69385e8: loco: fix rgba on big-endian
[00:57] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:9df9420dea0f: interplayvideo: Free previous frames on resolution changes.
[01:30] <shahriman> guys can anyone download the original source from here, i want to report a bug but to verify you need the source https://vimeo.com/58025358
[02:29] <Compn> shahriman : should be downloadable with youtube-dl or 
[02:43] <cone-913> ffmpeg.git 03Mirjana Vulin 07master:2b6a8187a6ae: mips: optimization for float aac decoder (core module)
[03:53] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:fe6767f849d9: asfdec: fix integer overflow in packet_replic_size check
[04:36] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:cdf0877bc341: h264/cabac: check loop index
[04:39] <Compn> nevcairiel : sorry if i missed your answer, are you planning to review dxva patch ?
[04:49] <highgod> Hi, all, I want to ask a question. Does ffmpeg has any filter to remove mosaic? Thanks
[04:51] <Compn> uncensor filter? no , it does not
[04:52] <Compn> that would be neat :)
[04:52] <Compn> nevcairiel : highgod would like it if someone would review his dxva patch :)
[06:06] <highgod> Thanks
[07:22] <nevcairiel> Compn: i volunteer you then!
[11:25] <durandal_1707> divVerent: you did anything with showspectrum?
[11:28] <divVerent> not yet, can I see the code you currently have?
[11:28] <divVerent> i.e. where is i
[11:29] <divVerent> t
[11:29] <durandal_1707> divVerent: you are not subscribed to ffmpeg-devel?
[11:29] <divVerent> no, I look in the archives
[11:29] <divVerent> ok then
[11:30] <durandal_1707> well it should be in archives
[11:30] <durandal_1707> search for showspectrum
[11:30] <divVerent> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/138172.html this is it probably
[11:30] <durandal_1707> there is only one patch that adds new funcionality ....
[11:31] <divVerent> right, this one keeps the old code there for compat though
[11:33] <durandal_1707> well old code use same row for all channels
[11:33] <durandal_1707> compat could be renamed to something better ...
[11:33] <durandal_1707> if I know nice way to map 8 ch values into 24bit number
[11:35] <divVerent> 24bit number? as in RGB?
[11:37] <durandal_1707> yes, rgb24
[11:40] <divVerent> the way I'd prefer is defining channels by hue+
[11:40] <divVerent> it seems to be the best one can do, albeit far from perfect
[11:42] <divVerent> durandal_1707: are there already HSV or HSL functions in ffmpeg?
[11:43] <divVerent> hm... there is a "hue" filter
[11:44] <divVerent> ah, this filter uses unit vectors in U,V space, scaled by Y... so I will try the same and see how it looks
[11:48] <durandal_1707> divVerent: it uses rgb24 for output, but that can be changed to yuv444p
[11:48] <divVerent> but then it's planar... I wanted to keep the code as close as possible to the original :P
[11:48] <divVerent> too bad there is no packed yuv444 format yet
[11:49] <divVerent> so I will do RGB for now
[11:49] <durandal_1707> what original?
[11:49] <durandal_1707> output format can be changed
[11:49] <divVerent> the "compat" code :P
[11:49] <durandal_1707> compat mode if legacy just for same row
[11:49] <divVerent> basically, what I am doing, is adding a "combined" mode to your patch that is SORT of like compat
[11:49] <divVerent> but supports multiple channels
[11:50] <durandal_1707> there is no point to keep if for some reason like ffplay useless code
[11:50] <durandal_1707> showspectrum is just port of ffplay one night hack session
[11:51] <durandal_1707> there is no reason to keep such pointless legacy crude whatever code
[11:51] <durandal_1707> it is just insane
[11:51] <divVerent> sure
[11:51] <durandal_1707> also ffplay when outputs rgb24 it fucks up color, everything is too bright
[11:51] <divVerent> compiling now
[11:52] <divVerent> hehe
[11:52] <divVerent> well, trying out the concept on rgb24 now, if it works out, I'll change it to yuv444p
[11:52] <divVerent> and then multiple channels will get equal brightness again
[11:53] <durandal_1707> i have bunch of ideas to add to this filter to make it actuall useful
[11:53] <divVerent> durandal_1707: another thing to notice BTW... the current (and old) code is quite slow... due to working by rows... I wonder if working by columns, and using existing SSE-optimized rotate code after it (if it exists) would be faster
[11:54] <durandal_1707> i do not think rotation is needed ...
[11:54] <divVerent> but OTOH
[11:54] <divVerent> performance is probably ok anyway
[11:54] <durandal_1707> code is slow perhaps it do not use something of x^2 +1
[11:54] <durandal_1707> or it is just writtend without performance in mind
[11:55] <divVerent> the latter
[11:55] <divVerent> probably not needed, it's just processing audio after all
[11:55] <durandal_1707> though ffplay output if faster, so port is maybe culprit
[11:56] <divVerent> hehe, the old code may indeed work faster, depending on how clever SDL_FillRect and SDL_UpdateRect are
[12:14] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:d99bc8475232: doc/eval: fix/extend documentation for root() function
[12:14] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:41e5e28daf0a: doc/eval: fix/extend documentation for taylor() function
[12:14] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:dcfbe1e0b67b: doc/eval: sort functions by name
[12:15] <divVerent> durandal_1707: http://rm.sudo.rm-f.org/img/uploaded/b86c263c5a2942382417adf786567173.png http://rm.sudo.rm-f.org/img/uploaded/b07aa627f01447270acc377d9af60b02.png
[12:15] <divVerent> is basically my idea
[12:15] <divVerent> the views are the same, the combined one is just the colors of the two added
[12:16] <divVerent> the colors themselves don't matter yet though, but they are chosen to be so they always all add up to grey
[12:17] <divVerent> https://gist.github.com/4682205 - is my code at the moment
[12:17] <divVerent> I suppose the new "combined" mode is close enough to the old "compat" so "compat" can be ignored and colorspace can be changed?
[12:19] <durandal_1707> divVerent: fine. i just want to see >2 in combined mode
[12:20] <divVerent> have no input file with more than 2 channels here, can you point me to one?
[12:21] <divVerent> could always generate one though, but it looks more useful with real data
[12:21] <durandal_1707> samples.ffmpeg.org/     lossless audio and wavpack ...
[12:22] <divVerent> ah, thanks
[12:24] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/0030d8c1a047a74683c5342464beac4f.png
[12:24] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/5adb3378906a2b8b4c08bd3174e82ff6.png
[12:25] <divVerent> 6 channel ID in the two modes (still RGB)
[12:26] <durandal_1707> hmm you render one after another?
[12:27] <divVerent> this audio file does that
[12:27] <durandal_1707> 2nd non-combined one looks buggy
[12:27] <divVerent> http://samples.ffmpeg.org/multichannel/6_Channel_ID.flac
[12:28] <divVerent> durandal_1707: no, but the 6th channel is used weird
[12:28] <durandal_1707> ahh then pick less retarded sample
[12:28] <divVerent> yes
[12:28] <divVerent> but first porting to YUV
[12:28] <durandal_1707> eva something
[12:28] <divVerent> so the color brightnesses will match
[12:28] <divVerent> is there a file list of this whole server?
[12:29] <divVerent> oh, stupid question, found it
[12:29] <durandal_1707> yes each separate color for channel is good idea for separate option ....
[12:29] <divVerent> ./A-codecs/lossless/wavpack/test_suite/num_channels/eva_2.22_6.1_16bit.wv
[12:29] <divVerent> AH, should have looked in A-codecs/
[12:29] <durandal_1707> yes i have that sample for testing ....
[12:32] <divVerent> haha, got integer overflows ;)
[12:33] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/ca583f6309bf0323fef2e786752371bc.png separate
[12:34] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/e42bb921dc915f39c369929c1e7bd63e.png combined (and divided by number of channels)
[12:34] <durandal_1707> some kind of projecting X dimenstion to 2.3 is needed
[12:34] <divVerent> 2.3?
[12:34] <divVerent> you mean the different resolution due to different FFT sizes?
[12:35] <durandal_1707> i mean best way to pick color from 8 chans
[12:36] <divVerent> what I currently do, is YUV = 1, sin(angle), cos(angle)
[12:36] <divVerent> oops, no, first cos, then sin
[12:36] <divVerent> where angle is 2pi * channel / num_channels
[12:36] <divVerent> that kind of alignment ensures that if all channels output the very same, you get grey in the sum
[12:37] <durandal_1707> nice, that could be another option, where other one would be old boring monotonic for all channels....
[12:37] <divVerent> the combined one IS the old monotonic one :P
[12:37] <divVerent> but the separate-channel one can easily be colored or uncolored
[12:38] <durandal_1707> i mean in separate mode
[12:38] <divVerent> now I am wondering... you are good in maths?
[12:38] <divVerent> I know there is a mathematical theorem about the max of weighted sums of unit roots
[12:38] <durandal_1707> and for separate mode i want something like sox does
[12:38] <divVerent> yes, separate mode should IMHO have the choice between intensity-colors (sox) and channel-colors
[12:39] <divVerent> intensity-colors being default
[12:40] <cone-469> ffmpeg.git 03Giorgio Vazzana 07master:ff23b76899b2: lavd/v4l2: add list_standards option
[12:40] <divVerent> basically, I need max real sum(i=0..n-1) omega^i * a_i, where 0 <= a_i <= 1 and omega = a complex unit root of order n
[12:40] <divVerent> I THINK there is an easy expression for this
[12:42] <divVerent> it SEEMS to be in the order of n/3
[13:05] <divVerent> ARGH, I HATE YOU, TV LEVELS, I HATE YOU
[13:06] <divVerent> what is the proper YUV black level again
[13:06] <wm4> can't you just output full range?
[13:07] <divVerent> I currently do
[13:08] <divVerent> and that means lower frequencies become all black
[13:08] <durandal_1707> debends what color range you set or application you use think you are using....
[13:08] <divVerent> because converting to RGB doesn't assume full range
[13:08] <divVerent> or can the filter specify it outputs full range?
[13:08] <wm4> I'd expect that it can set it in the picture that is output
[13:08] <durandal_1707> color_range is part of avctx
[13:09] <durandal_1707> i dont think lavfi is aware of it at all
[13:09] <durandal_1707> try YUVJ444P pix fmt
[13:10] <durandal_1707> it is 2013 and there is still no proper way to handle it in code :(
[13:11] <divVerent> yes
[13:11] <divVerent> it's deprecated
[13:11] <divVerent> but this works
[13:11] <durandal_1707> swscale have some code that converts between diferent matrix crap
[13:12] <divVerent> now wondering how to set the colors so it looks good
[13:12] <divVerent> or rather, maybe should match the old code
[13:12] <wm4> durandal_1707: swscale + levels works, for YUV
[13:12] <divVerent> it used FF0080 and 00FF80
[13:12] <wm4> at least in some cases...
[13:12] <divVerent> now what are these colors in YUV
[13:13] <divVerent> if my CAS is right, these colors are roughly +U and -U
[13:14] <durandal_1707> divVerent: you can find several nice distributions and make them configurable
[13:14] <wm4> lol that ticket
[13:14] <durandal_1707> Frodo lost his ring
[13:21] <divVerent> durandal_1707: there is not many to pick from
[13:21] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/c45edab2126015b59ff9aa6665d55427.png http://rm.sudo.rm-f.org/img/uploaded/ce6512b22561426517b5bb5728624d00.png
[13:21] <divVerent> my first attempt to match the default colors of ffplay
[13:22] <divVerent> could it be that the two filters use different windowing functions?
[13:23] <divVerent> yes, indeed
[13:23] <divVerent> your code with compat=1 also has less grey stuff around :P
[13:23] <durandal_1707> why would they use different function?
[13:23] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/e929fce848e6f0d09f841bad9183da10.png
[13:23] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/c45edab2126015b59ff9aa6665d55427.png
[13:23] <divVerent> first is compat=1
[13:23] <divVerent> second is my code
[13:23] <divVerent> and the one before was ffplay
[13:24] <divVerent> ffplay basically does SOME part of the RDFT differently
[13:24] <divVerent> most likely the window function
[13:25] <divVerent> ffplay uses a 1-x^2 window
[13:25] <ubitux> yes i used a different windowing function
[13:25] <durandal_1707> does it make sense?
[13:25] <ubitux> (hello!)
[13:25] <saste> ehi ubitux-san!
[13:25] <divVerent> the avfilter function is better
[13:25] <durandal_1707> x^2 + 1 should be used
[13:25] <ubitux> the windowing function wasn't sexy so i used a hann one iirc
[13:25] <divVerent> durandal_1707: sure not + 1 :P
[13:25] <divVerent> yes
[13:25] <divVerent> the issue you see on my screenshots :P
[13:25] <divVerent> I tested with aevalsrc
[13:26] <divVerent> and it's pure sine waves
[13:26] <divVerent> ffplay shows LOTS of grey stuff around it
[13:26] <divVerent> due to bad window function
[13:26] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/ce6512b22561426517b5bb5728624d00.png current ffplay
[13:26] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/e929fce848e6f0d09f841bad9183da10.png current showspectrum
[13:26] <durandal_1707> ok, i prefer correct code
[13:26] <divVerent> none is correct, but the better window function is less incorrect ;)
[13:27] <durandal_1707> i'm against legacy
[13:27] <divVerent> there is no way to do this correctly
[13:27] <divVerent> but it's pretty good now
[13:27] <durandal_1707> whatever, i just cant use current showspectrum as it is useless to me
[13:27] <durandal_1707> so either I gonna improve it
[13:27] <durandal_1707> or write new filter
[13:29] <durandal_1707> so i will apply modified patch of mine for showspectrum, as it got no attention at all
[13:29] <durandal_1707> and then will apply divVerent stuff
[13:29] <divVerent> you can have my patch now BTW
[13:29] <divVerent> what did you modify BTW, as I probably replaced all changed code by now
[13:30] <divVerent> https://gist.github.com/4682536
[13:30] <divVerent> is my current changes vs yours
[13:30] <divVerent> now all it needs is the intensity-coloring mode
[13:30] <divVerent> (the "sox mode")
[13:31] <durandal_1707> and then "rotated" mode, where slide goes up<->down
[13:32] <durandal_1707> dont stop there, lets your imagination work out.....
[13:32] <divVerent> I doubt it'd make sense to have both these modes... it'd duplicate too much code then probably
[13:32] <divVerent> maybe better to decide on one mode, and use rotate filter for the other
[13:32] <divVerent> but, rotated vs current display would likely be faster
[13:33] <divVerent> e.g. that memmove mess can be all done as a single block then
[13:33] <durandal_1707> duplicate? cant you just use functions?
[13:34] <durandal_1707> yes, making bad code looks good is boring and daunting task....
[13:35] <divVerent> actually... I think I will solve that inefficiency now, which would also help with rotating
[13:35] <divVerent> I will use an intermediate float buffer for each line
[13:36] <divVerent> that way, you can in the regular display also bump saturation to like 100x
[13:36] <divVerent> and then see channel differences better
[13:36] <divVerent> in the current code, the clamping to 0..255 at each step would screw that up
[13:39] <ubitux> saste: hey :)
[13:39] <ubitux> do you miss me?
[13:39] <cone-469> ffmpeg.git 03Paul B Mahol 07master:b70ea49ca32c: Port biquads filters from SoX
[13:40] <ubitux> durandal_1707: bitexact + fate tests now? ;)
[13:40] <durandal_1707> bitexact what?
[13:40] <saste> ubitux: i'm feeling a bit annoyed since i have no new subtitles to try since a while
[13:40] <ubitux> durandal_1707: integer arithmetic
[13:41] <ubitux> saste: no new subtitles patches?
[13:41] <durandal_1707> i still wait for that kerndeint improvements...
[13:41] <saste> ah yes and that...
[13:41] <durandal_1707> ubitux: i still do not get it what it means
[13:41] <wm4> hey guys I could need a stable and useful API for lavfi
[13:41] <ubitux> saste: nag beastd, he should be doing this
[13:41] <durandal_1707> wm4: ask michaelni 
[13:41] <saste> beastd: I nag you!
[13:42] <saste> wm4, you ask too much
[13:42] <durandal_1707> ubitux: filters are bixexact with sox if you use aformat=samplefmts=dblp,bass......
[13:42] <saste> what about, unstable and useless?
[13:42] <ubitux> durandal_1707: forget this, i though it wasn't supporting s16 etc
[13:43] <wm4> e.g. recently I saw a commit that fixes seeking with lavfi and ff/avplay
[13:43] <wm4> the solution was recreating the whole filter chain on seek
[13:43] Action: ubitux doesn't want to leave this country
[13:43] <ubitux> any ffmpeg work in japan for me? :(
[13:43] <wm4> is that the proper lavfi solution?
[13:49] <divVerent> durandal_1707: ok... https://gist.github.com/4682630
[13:50] <divVerent> now there's not much more of your patch left, so I diffed to master instead
[13:50] <divVerent> local copy has the missing freep added
[13:50] <divVerent> durandal_1707: the combined mode is now cool with like saturation=5
[13:53] <divVerent> so next part would be research as for how sox mode would work
[13:53] <durandal_1707> do you have branch with several commits, it it makes sense to split them in smaller funcionality steps..
[13:54] <divVerent> no, don't have that
[13:54] <divVerent> given I don't see many separate steps there
[13:54] <durandal_1707> divVerent: you mean colors or output single frame for whole duration?
[13:54] <divVerent> colors
[13:54] <divVerent> single frame for whole duration can already be done, if calculating the width "right" ;)
[13:55] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/257d3a6e6917db49fcf736ae9467da60.png with high saturation
[13:55] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/ec4ffa6febfc860cbc9aaca340237a01.png - combined mode with high saturation
[13:56] <divVerent> I can visually make out 4 channels there
[13:58] <durandal_1707> using ch to loop over data planes confused me big time
[13:58] <divVerent> I saw it as color channels
[13:58] <divVerent> but the main reason was that p for plane was taken
[13:58] <divVerent> by p for pointer ;)
[13:58] <durandal_1707> :)
[13:58] <divVerent> but sure, adding a plane var
[14:00] <divVerent> do we use C99 BTW?
[14:01] <durandal_1707> silly, but no
[14:01] <wm4> ffmpeg requires C99 though
[14:02] <divVerent> wm4: it does?
[14:02] <divVerent> was mainly asking if I can replace this sqrt(re*re+im*im) by hypot(re,im)
[14:02] <divVerent> ;)
[14:02] <divVerent> hypot() is C99 though, and MS renamed it to _hypot
[14:02] <wm4> divVerent: yes, why else do you think they wrote a c99-to-c89 converter just for libav?
[14:02] <divVerent> hypot() is not C89, but existed before C99 on many systems
[14:03] <divVerent> e.g. virtually any BSD
[14:03] <divVerent> and glibc
[14:03] <durandal_1707> i was refering to for (int plane ...) { ...
[14:03] <divVerent> durandal_1707: hehe, yes...
[14:03] <divVerent> I mainly am asking about hypot()
[14:03] <divVerent> as I am now cleaning up the ugly macros
[14:04] <durandal_1707> just send patch(es) to ffmpeg-devel when ready
[14:04] <divVerent> based on master, I suppose?
[14:05] <durandal_1707> yup
[14:05] <divVerent> well, I mainly want to know before I do that
[14:05] <divVerent> +#define CPLX_MAGNITUDE(re, im) sqrt((re)*(re) + (im)*(im)) /* is actually hypot(re, im) */
[14:05] <divVerent> do we NEED this macro at all then ;)
[14:05] <divVerent> hypot() is not on every pre-C99 libc, but on most
[14:05] <divVerent> MS is the exception, MS deprecated hypot() in favor of _hypot() in 2005
[14:05] <divVerent> so it'll warn in MSVC
[14:05] <divVerent> but C99 added hypot()
[14:05] <durandal_1707> do it in separate commit and other who carse will define hypot to something useful
[14:06] <durandal_1707> for arch where it is not present...
[14:06] <durandal_1707> *care
[14:06] <divVerent> it probably exists on all
[14:06] <divVerent> just warns on MSVC
[14:06] <divVerent> just like fopen() ;)
[14:07] <durandal_1707> dont worry, MSVC guys fill provide fix as soon something break....
[14:07] <divVerent> also, c99wrap SURE already fixes this
[14:07] <divVerent> given this one can even be fixed by -Dhypot=_hypot
[14:08] <divVerent> so hardest part now is cleaning up the history :P
[14:08] <durandal_1707> is there someone on #ffmpeg that claims native aac encoder is good?
[14:10] <saste> wm4: the "clean" solution, i guess, would be to implement a seek command in the various filters
[14:10] <saste> then you simply send a seek to the relevant filters
[14:11] <wm4> saste: I did that in mpv
[14:11] <durandal_1707> and what seek would do in each filter?
[14:11] <saste> we could even script the key-binding, so each user can choose her favored keystrokes
[14:11] <wm4> durandal_1707: reset state
[14:11] <saste> durandal_1707, it depends
[14:11] <saste> some filters don't need to be reset (e.g. hflip, vflip, etc.)
[14:11] <saste> movie could actually seek in the input
[14:11] <wm4> though I actually wonder if there any filters which really benefit from a seek command, instead of recreating the graph
[14:12] <wm4> my problem is more that recreating the graph is a complicated operation
[14:12] <saste> wm4, ffplay_input could be changed to support a seek operation
[14:13] <saste> again some scripting seems the right solution, so you can change/program the binding at the application level
[14:13] <wm4> also, I've said it before, but string commands suck
[14:13] <wm4> for both caller and filter implementations
[14:16] <saste> wm4, willing to help in that area?
[14:17] <wm4> saste: possibly...
[14:18] <saste> wm4, first step would be to make all the filters parse the argument string with av_opt_
[14:18] <saste> at that point we can switch and factorize initialization
[14:19] <saste> i don't think there are many filters left
[14:19] <saste> then we could provide a secondary init() interface, which accepts options as an AVDictionary or whatever
[14:20] <cone-469> ffmpeg.git 03Paul B Mahol 07master:402ea625ab7b: lavfi/biquads: remove pointless casts
[14:20] <saste> this could simplify scripting, since you would need no more escaping hell since each option can be specified in a separate argument
[14:21] <saste> (or you could just set options on the filter)
[14:27] <saste> is ffmpeg going to compete with sox?
[14:28] <saste> otoh sox doesn't seem to be very active
[14:29] <wm4> can't ffmpeg just use sox instead?
[14:29] <saste> wm4, yes
[14:29] <saste> and ladspa as well
[14:32] <durandal_1707> ffmpeg biquads are faster than sox ones (planar<->interleaved) sox is missing optimizations
[14:45] <Compn> someone (carl !! you there? :) want to retest if https://ffmpeg.org/trac/ffmpeg/ticket/1957 is fixed now?
[14:56] <durandal_1707> Compn: it is duplicate of ticked which is fixed
[15:05] <durandal_1707> divVerent: i like your patch
[15:06] <divVerent> will soon post it
[15:07] <divVerent> I divided it back up into a few commits, but the big change of how your method works can't really be separated out
[15:07] <divVerent> also, did I mention that I hate that YUV444P is not actually YUV444P but YVU444P? ;)
[15:12] <Compn> durandal_1707 : yes, but is it fixed or is it a mis-duplicate tag ? :P
[15:15] Action: Compn going to upset carl by reopening random bugs and turning them into feature requests :D
[15:32] <saste> Compn, we should tag tickets with a difficulty level
[15:32] <saste> so newbee contributors can pick the easy ones
[15:34] <cone-469> ffmpeg.git 03Giorgio Vazzana 07master:514216d8a928: lavd/v4l2: read the correct time per frame from devices that support a standard
[15:34] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:a842dc632eca: doc/indevs: apply misc fixes to the v4l2 documentation
[15:35] <durandal_1707> saste: can that be added to trac?
[15:35] <saste> durandal_1707, sure
[15:35] <saste> vlc trac has it at least
[15:35] <saste> a tag cloud would be fun as well
[15:36] <durandal_1707> than lets add it
[15:36] <saste> who's the designated maintainer for trac?
[15:41] <Compn> no idea
[15:41] <Compn> saste : good idea re difficulty level
[15:45] <Compn> i dont think i'm an admin on trac.
[15:45] <Compn> probably michaelni 
[16:00] <durandal_1707> hmm amovie cant use http:// .... ?
[16:01] <wm4> durandal_1707: AFAIK that should work?
[16:02] <durandal_1707> amovie cant use http:// .... ?
[16:03] <ubitux> backquote the ':'
[16:03] <ubitux> it's an option separator
[16:03] <wm4> d'oh
[16:11] <Compn> that info in the docs?
[16:11] <Compn> example with http url be nice :)
[16:11] Action: Compn gone
[16:12] <durandal_1707> what i should put before : ?
[16:14] <durandal_1707> i tried / and `
[16:14] <ubitux> \ obviously
[16:15] <durandal_1707> it does not work
[16:15] <ubitux> the \ must be present, is your shell interpreting it?
[16:15] <durandal_1707> \\ works
[16:16] <ubitux> yes because otherwise the shell "escape" the :, basically removes the \
[16:16] <durandal_1707> was waste of time, lavfi cant handle mp3 stream
[16:18] <saste> durandal_1707, no?
[16:19] <durandal_1707> i get spam:
[16:19] <durandal_1707> [mp3 @ 0x29878400] Header missing
[16:19] <durandal_1707> [Parsed_amovie_0 @ 0x29809140] Decode error: Invalid data found when processing input
[16:20] <durandal_1707> even if i download such file
[16:42] <saste> Maximum number of registered filters 128 reached,
[16:42] <saste> uh...
[16:44] <durandal_1707> lol, really?
[16:46] <durandal_1707> indeed
[16:46] <durandal_1707> saste: how you trigered it?
[16:46] <saste> durandal_1707, i just updated my ffmpeg
[16:47] <saste> it should be that i enabled more filters than you
[16:47] <durandal_1707> exactly
[16:47] <saste> patch to raise the max number incoming
[16:47] <durandal_1707> isn't it part of ABI/API , we need to bump major
[16:48] <durandal_1707> lavf does not have such limit?
[16:48] <saste> durandal_1707, no, it's internal
[16:49] <durandal_1707> it should raise on its own, so no need to increase number each time limit is reached
[16:51] <durandal_1707> i want to do this with ffmpeg: sox -n o.sox synth pl G2 pl B2 pl D3 pl G3 pl D4 pl G4 delay 0 .05 .1 .15 .2 .25 remix - fade 0 4 .1
[16:53] <saste> yes it's weird, i don't remember why we did filter registration that way
[16:56] <saste> durandal_1707, can't reproduce the mp3 issue with amovie
[16:57] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:e47114d5459a: lavfi: increment max number of registered filters from 128 to 256
[17:01] <divVerent> durandal_1707: http://rm.sudo.rm-f.org/img/uploaded/9db2af3387cdae336f6d831702da5f6e.png
[17:01] <divVerent> this is with stolen code from sox though ;)
[17:03] <durandal_1707> this is palette or?
[17:03] <divVerent> nope
[17:03] <divVerent> https://gist.github.com/4683934
[17:03] <divVerent> this is the code
[17:03] <divVerent> stolen from sox's palette generation
[17:04] <durandal_1707> good, it would be nice to make it generic so other shemes can be added...
[17:04] <divVerent> I don't like this though
[17:04] <divVerent> it's slow, and nasty (YUV conversion...)
[17:04] <divVerent> ideally I'd like to replicate the same curves but in YUV space
[17:05] <divVerent> or rather, very similar ones
[17:05] <divVerent> I tried to do it, but yellow became pink
[17:05] <divVerent> rest works
[17:05] <divVerent> wonder if I should just make it an array of (value, y, u, v) items
[17:05] <divVerent> and it'd linearily interpolate
[17:06] <divVerent> and I'd predefine it for sox's colors at all "critical" points
[17:06] <divVerent> i.e. all intensity values mentioned there, and 0.30 (middle of the sin() curve for b)
[17:06] <durandal_1707> well having sox as some kind of palette is extra feature
[17:07] <divVerent> also, as you see, i also made logarithmic scale for this one
[17:07] <durandal_1707> it uses 256 colors only, which i find too low
[17:08] <durandal_1707> but it can be used in sox mode, if one wants to have same output as sox does....
[17:09] <divVerent> well, I rather would prefer it to be a table with linear interpolation
[17:10] <divVerent> as that CAN be more accurate in the end
[17:12] <durandal_1707> sure
[17:17] <divVerent> yes, works
[17:23] <cone-469> ffmpeg.git 03Paul B Mahol 07master:22fad4e2b8c7: doc/filters: fix afade cuve types listing
[17:24] <divVerent> durandal_1707: http://rm.sudo.rm-f.org/img/uploaded/180081251f2e54275685c44b505b66bb.png sox colors with square root scale (old ffplay)
[17:24] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/d7fd80be0fd8e92c8f7941f12a87dafb.png sox colors with logarithmic scale (sox)
[17:24] <divVerent> both look useful, actually
[17:28] <durandal_1707> divVerent: yes
[17:31] <durandal_1707> shit, typo
[17:31] <durandal_1707> i hate typos
[17:39] <divVerent> https://gist.github.com/4684199 for you to test, will post it on the ML later
[17:40] <divVerent> I recommend the combinations:
[17:40] <divVerent> - showspectrum (separate, otherwise ffplay-like)
[17:40] <divVerent> - showspectrum=combined=1 (ffplay replication)
[17:40] <divVerent> - showspectrum=intensity=1:logscale=1 (sox)
[17:40] <divVerent> - showspectrum=intensity=1 (soxlike but ffplay's scale)
[17:41] <divVerent> - showspectrum=saturation=0 (what your original code did)
[17:42] <divVerent> saturation=-1 yields an alternate color scheme ;)
[17:42] <durandal_1707> my original code was just to not ignore other channels ....
[17:42] <divVerent> yes
[17:42] <divVerent> I mainly like using saturation in combined mode
[17:42] <divVerent> to exaggerate channel differences
[17:43] <durandal_1707> does this one still depends on old patch of mine?
[17:43] <divVerent> the series includes it
[17:43] <divVerent> but I could squash the first two, but didn't to keep your credit
[17:43] <durandal_1707> it is splitted?
[17:44] <divVerent> my patch has been split, but the first change that basically rewrote yours is not split
[17:44] <durandal_1707> divVerent: i dont care for my credits
[17:44] <divVerent> then I'd squash the first two
[17:47] <divVerent> https://gist.github.com/4684260 would be the same with the first two changes squashed and explained as a single commit
[17:48] <divVerent> but for finally committing it, it probably would be best to have all changes in a single commit in the end
[17:48] <divVerent> for reviewing it may be better this way though
[17:50] <durandal_1707> i'm fine with whatever combination
[17:51] <divVerent> so am I... will play around with it a bit more, but probably won't change it much any more
[17:51] <divVerent> as for the one-image-output feature, not sure... I also want to look into the Y scale though
[17:52] <divVerent> as in, where it comes from
[17:52] <divVerent> whether top is nyquist, or something else
[17:53] <divVerent> it SHOULD be nyquist ;) but I don't trust the code regarding that yet
[18:04] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:7e0fc1a24fa6: CREDITS: redirect to Git log, remove current outdated content
[18:09] <divVerent> yes indeed... nyquist is ONLY at the top when the height is a power of two (if not combined, multiplied by channel count)
[18:09] <divVerent> does FFT size HAVE to be a power of two? if yes, it's difficult to fix
[18:10] <divVerent> compare output with s=512x256 to s=512x257 ;)
[18:10] <durandal_1707> divVerent: first commit/ my code have some flaws, see av_size_mult() - this is supposed to check for overflows
[18:10] <durandal_1707> but i did not updated it ...
[18:12] <durandal_1707> also you should use av_realloc_f or otherwise leaks happens when memory alloc fails
[18:15] <divVerent> ok, committed fix for these two locally
[18:16] <divVerent> what do you suggest about the nyquist issue?
[18:16] <divVerent> the thing is, APPARENTLY only power-of-two FFT sizes are supported
[18:17] <divVerent> so if you have (evil case) 7 channels
[18:17] <divVerent> you only see the full frequency range if the output size is 7*poweroftwo
[18:17] <divVerent> issue existed before too, but then only applied to the full size
[18:17] <divVerent> default height of 480 was bad for the same reason :P
[18:18] <divVerent> ignore it, like before - but set the output height to 512 so by default, you do see the full spectrum for 1ch and 2ch at least?
[18:19] <divVerent> the only alternative would be using a scaling filter to trim the size down
[18:19] <divVerent> I'd rather not
[19:17] <cone-469> ffmpeg.git 03Ronald S. Bultje 07master:a5ba798c16d0: dsputil: remove unused functions copy_block{2, 4, 8, 16}.
[19:17] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:ed341549bbc2: Merge commit 'a5ba798c16d0614d982a76755fdd72b37d437170'
[19:27] <cone-469> ffmpeg.git 03Martin Storsjö 07master:a65f965c04bf: mpegvideo: Do REBASE_PICTURE with byte pointers
[19:27] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:324498f82470: Merge commit 'a65f965c04bfa27adedc0409c14cc05903f483d0'
[19:29] <saste> what happened to the ffmpeg -i option?
[19:30] <michaelni> saste, ?
[19:31] <saste> michaelni, I'm trying to set -user_agent, and failing
[19:31] <saste> also I can't see the "i" entry in the options array (ffmpeg_opt.h) no more
[19:31] <saste> ffmpeg_opt.c
[19:31] <michaelni> the parsing code was redesigned a few times
[19:32] <michaelni> its more convoluted now
[19:33] <saste> so now is more "evil"
[19:34] <saste> but, it seems I can't set avio options
[19:34] <saste> is that a regression or what?
[19:34] <michaelni> did it work before ?
[19:35] <saste> dunno, but I'm trying an example: ffplay -user-agent foobar URL and it seems to fail with unknown option
[19:35] <saste> the example was taken from the docs, so I thought about a regression
[19:37] <saste> but maybe it was never possible
[19:37] <saste> wm4, how can you reproduce the http cookies issue?
[19:39] <saste> in other words, how can I pass protocol options to avformat_open_input()?
[19:39] <saste> is that possible?
[19:42] <saste> wow, why all these MP3 hacks in avformat_open_input()?
[19:42] <michaelni> btw did you try -user-agent or user_agent ?
[19:43] <michaelni> ffmpeg -h full has it with - not _
[19:49] <saste> michaelni, i'm debugging the issue
[19:52] <saste> it is setting the option, but then for some "evil" reason it fails later in ffmpeg_opt.c code
[20:02] <cone-469> ffmpeg.git 03Diego Biurrun 07master:0f5b0b4178b8: avisynth: Change demuxer name to avoid conflicts with AVS
[20:02] <cone-469> ffmpeg.git 03Diego Biurrun 07master:29f1fa74225e: configure: Move newlib libc check before mingw libc check
[20:02] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:01d012ba3db9: Merge commit '29f1fa74225e9fdbab6d590857edbecb51cf74da'
[20:08] <cone-469> ffmpeg.git 03Diego Biurrun 07master:197252f1c58b: configure: Add a comment indicating why uclibc is checked before glibc
[20:08] <cone-469> ffmpeg.git 03Diego Biurrun 07master:52acd79165e7: x86: hpel: Move {avg,put}_pixels16_sse2 to hpeldsp
[20:08] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:dd87d4a318b3: Merge remote-tracking branch 'qatar/master'
[20:20] <saste> michaelni, ffplay -user-agent foobar  http://ffmpeg.org/ffmpeg-logo.png
[20:24] <saste> oh wait it's a bit of a mess
[20:25] <saste> lavf see that the url is an image file, so it doesn't open avio
[20:25] <saste> so it doesn't consume the option -> error
[20:26] <saste> so i can't see no way to pass the url options here
[20:26] <saste> also avformat_open_input() has no way to discriminate avio options from demuxer options
[21:00] <Daemon404> does lavfi have a way to generate blank input easily?
[21:00] <Daemon404> i.e. i need somthing good to test encoding threading
[21:11] <llogan> Daemon404: what do you mean by blank input?
[21:11] <Daemon404> llogan, i used /dev/zero. nevermind.
[21:12] <saste_> Daemon404, color=c=bikeshed
[21:12] <llogan> and "aevalsrc=0"
[21:15] <cone-469> ffmpeg.git 03Nicolas George 07master:6560625f0aec: lavfi/bufferqueue: add ff_bufqueue_is_full().
[21:15] <cone-469> ffmpeg.git 03Nicolas George 07master:ae14887ee7f2: lavfi/af_amerge: check for buffer queue overflows.
[21:15] <cone-469> ffmpeg.git 03Nicolas George 07master:dcce43340f45: lavfi/af_amerge: set outbuf->audio->channels.
[21:15] <cone-469> ffmpeg.git 03Nicolas George 07master:d2ccab5f8a5f: lavfi/buffersrc: forward filter_frame errors.
[21:23] Action: Compn wonders why saste has a hardcoded max filter number
[21:23] <Compn> its like hardcoding a max codec number. a foolish thing! :P
[21:30] <durandal_1707> divVerent: just send patches, and size could be set for channel height or rounded from window size so some part of window is black....
[21:31] <durandal_1707> also sox have alternative pallete, if you want to do it too....
[22:14] <durandal_1707> can somewhere help this guy who keep asking user questions in community on ffmpeg?
[22:16] <saste_> durandal_1707, what guy?
[22:16] <durandal_1707> g+ guy
[22:17] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:349e7f423f19: doc/indevs: itemize examples for the v4l2 device
[22:17] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:b999774f0b11: doc/indevs: document v4l2 options
[22:22] <durandal_1707> so to pad start of audio you use aresample, there really should be example in doc...
[22:27] <llogan> durandal_1707: link?
[22:36] <durandal_1707> llogan: what link?
[22:39] <llogan> nevermind. i see what you're referring to.
[22:40] <durandal_1707> why are there two cone- bots?
[22:41] <llogan> you already told him to get help at the mailing list. not much else to say.
[23:10] <kierank> shahriman: did you see the vc-1 interlaced patch
[23:10] <shahriman> no i did not. where is it?
[23:10] <shahriman> kierank: ^
[23:10] <kierank> on the ml
[23:11] <kierank> j-b: ^
[23:11] <shahriman> kierank: can you please give me the link?
[23:11] <kierank> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/138302.html
[23:15] <shahriman> kierank: i forgot almost everything i knew about that code, but the patch looks ok to me
[00:00] --- Fri Feb  1 2013