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

[burek]

[00:19:00 CET] <jya> BBB: in https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ you mentioned that on haswell the performance gap between libvpx and ffvp9 wasn't as great as on earlier CPU due to libvpx supporting AVX2.
[00:19:19 CET] <jya> is that still the case ? (ffvp9 not having avx2 optimisation)?
[00:19:37 CET] <an3k> NOW I remember that touchy and snotty guy ...
[00:20:08 CET] <jya> we've just enabled AVX2 on windows and mac finally (our build machine has yasm 1.1 only installed so couldn't enable avx2)
[00:20:28 CET] <an3k> jya: if you can tell me how to check that I quickly can check my vpx build
[00:21:38 CET] <jya> an3k: check what ? that avx2 support exists? ffmpeg by default will enable avx2 code. Question is more on the inner implementation, I wouldn't know how to check that it's actually used 
[00:22:08 CET] <jya> the blog mentioned MC and loop filtering
[00:23:54 CET] <an3k> oh ok. thought one could see the used features somewhere. I just build libvpx with yasm 1.3.0 on a avx2 machine so I could test it
[00:24:22 CET] <kierank> jya: use "perf top" or something
[00:24:23 CET] <kierank> and you can see
[00:24:39 CET] <J_Darnley> Some vp9 files in ffmpeg mention avx2 in them and I see what should be a few function definitions
[00:26:57 CET] <jya> there's a difference between looking at the code, and seeing avx2 function, and knowing for sure with the author confirming :)
[00:28:20 CET] <drv> BBB quit just before you asked your question
[00:40:33 CET] <jya> drv: oh, thanks for pointing that out ! BBB was there and auto-completion had worked
[00:42:46 CET] <jya> BBB: just in case you missed the question: BBB: in https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ you mentioned that on haswell the performance gap between libvpx and ffvp9 wasn't as great as on earlier CPU due to libvpx supporting AVX2. is that still the case ? (ffvp9 not having avx2 optimisation)?
[01:00:50 CET] <kierank> wm4: do you know if videotoolbox can convert pixel formats independent of encoding and decoding
[01:01:15 CET] <kierank> I'm still trying to figure out how to benchmark ffmpeg vs them
[01:04:31 CET] <wm4> no, I don't know too much about it
[01:05:01 CET] <wm4> pigoz: maybe you know something?
[01:09:19 CET] <rcombs> might have to go through Core Image
[01:32:07 CET] <kierank> doesn't seem to be a way :(
[01:32:56 CET] <rcombs> where there's a will there's a way
[01:33:07 CET] <BBB> jya: mostly, yes
[01:33:35 CET] <BBB> jya: I believe we have MC and intra pred (DC, H and V) coverage, but not directional intra pred, idct or loopfilter
[01:33:51 CET] <kierank> rcombs: well I wanted to compare lavc v210 vs apple v210 but it's not fair to do it by an arbitrary route
[01:36:25 CET] <Krish> Hi, could someone help me to compile libx264 in windows 10 x64. I know its not exactly ffmpeg topic, but since im not getting any support from them Im asking here.
[02:41:17 CET] <jya> BBB: have you measured the difference in speed between AVX2 on and off ?
[03:08:30 CET] <BBB> jya: with libvpx? no
[03:08:56 CET] <BBB> jya: I can if you want. I wouldnt say that I have a lot of confidence that libvpx gets the most out of avx2 TBH
[03:09:33 CET] <BBB> jya: but it may help as a ballpark figure. Id say that it will probably (overall) get about 10%, maybe 20% faster?
[03:09:55 CET] <BBB> 10% is probably closer
[03:09:58 CET] <BBB> since MC is already done
[03:10:14 CET] <BBB> yeah lets say 10% faster overall, rough guess
[03:11:39 CET] <jya> BBB: no I meant with ffvp9
[03:15:03 CET] <jya> 10% is fairly impressive improvement already
[03:49:11 CET] <BBB> jya: its hard to measure avx2 on and off since, well, the assembly hasnt been written yet
[03:49:21 CET] <BBB> jya: Id have to write the assembly from scratch, its a fair bit of work
[03:49:55 CET] <jya> sorry, I don't understand.. My question was about if avx2 code was now used in ffvp9, I thought you said yes
[03:52:16 CET] <jya> I thought the improvement was on the existing code between avx2 being on or off
[03:55:51 CET] <BBB> jya: oh sorry, no, yes was to is this still the case (ffvp9 not having avx2 optimizations)"
[03:55:55 CET] <BBB> jya: so the inverse
[03:56:05 CET] <jya> ah bugger
[03:56:10 CET] <BBB> sorry :-p
[03:56:37 CET] <jya> so the AVX2 code found in FFmpeg (and required to compile just ffvp9) isn't currently used?
[03:57:54 CET] <BBB> theres some avx2 code, but its incomplete
[03:58:06 CET] <BBB> avx2 is only used for dc/tm/h intra pred and motion compensation
[03:58:10 CET] <BBB> jamrial wrote them
[03:58:27 CET] <BBB> avx2 is not yet used for loopfilter, directional intra pred or inverse transform
[03:58:36 CET] <BBB> my guess is the idct would be the biggest win
[04:28:08 CET] <jya> BBB: so when is it due ? :)
[04:28:56 CET] <jya> BBB: my personal goal is to provide better youtube experience using MSE/vp9 than people would with chrome... Would be the perfect irony :)
[04:29:34 CET] <BBB> uh& its not planned by me so far, Im working on other things right now :-p
[04:35:05 CET] <BBB> I can do consulting work on it if youre interested, I guess?
[04:39:58 CET] <BBB> email me if youre interested, Im going to sleep, 10:40 here, bye
[09:12:48 CET] <pigoz> wm4: kierank: rcombs: yes, might try coreimage. But who knows if VT actually uses that.
[11:52:59 CET] <Cloudef> What's the maximum image size for ffmpeg? I tried to run very large image (24000x15000) through it, but seems like it can't handle it
[11:55:04 CET] <nevcairiel> x*y*8 must not exceed INT_MAX i think
[11:56:32 CET] <Cloudef> that would be around 16kx16k I guess
[11:57:47 CET] <Cloudef> does ffmpeg use ints internally for indexing?
[12:00:04 CET] <Cloudef> (not that I have usecase for such large images, but curious anyways)
[12:01:24 CET] <nevcairiel> i forgot the details
[12:01:36 CET] <nevcairiel> i think buffer sizes are at some point ints
[12:47:46 CET] <wm4> I think in general it's just because there _could_ be overflows
[12:48:09 CET] <wm4> e.g. strides are stored as ints, so a stride*height calculation could overflow
[12:52:33 CET] <Cloudef> I see
[12:55:05 CET] <wm4> (we should probably fix this)
[13:34:04 CET] <cone-973> ffmpeg 03Bela Bodecs 07master:868a2ed56841: vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
[14:11:33 CET] <durandal_1707> Compn: did you approved last devel mail?
[14:16:11 CET] <wm4> lol
[14:16:19 CET] <wm4> you mean that random one?
[14:19:56 CET] <durandal_1707> outlook one
[14:27:10 CET] <ubitux> wasn't it a star wars parody?
[14:27:23 CET] <ubitux> you are my last hope ~
[14:40:47 CET] <Compn> durandal_1707 : no
[14:41:05 CET] <Compn> unless i did it in my sleep somehow...
[14:41:08 CET] Action: Compn just woke up
[15:13:22 CET] <BtbN> wm4_, https://gist.github.com/anonymous/a0ab87bf037efc883be6 this is against libav (11.3 i think), does it not define the VP9 profile?
[15:13:56 CET] <BtbN> Or is that libav version simply too old? I have no idea about their versioning.
[15:14:26 CET] <nevcairiel> libav's vp9 decoder is plenty old
[15:14:38 CET] <nevcairiel> even on their git master
[15:15:06 CET] <BtbN> So old it doesn't even define the VP9_0 Profile?
[15:15:19 CET] <nevcairiel> dunno
[15:16:16 CET] <nevcairiel> apparently the profile defines were added a few month ago, but for libvpx, not for ffvp9
[15:16:23 CET] <nevcairiel> not in 11 either way
[15:27:08 CET] <wm4_> BtbN: oh yeah, I have to fix that
[15:27:15 CET] <wm4_> it happens with older ffmpeg versions too
[15:37:40 CET] <gener1c> hey , i am trying to pipe several videos one after the other into ffmpeg and from it to an audio encoding executable using popen , is there a certain timing or chunk size i need to pay attention to?
[15:38:00 CET] <Daemon405> not afaik
[15:39:57 CET] <gener1c> weird, when i simply connected the stdin descriptor of the main program and the stdin of ffmpeg it worked but when i read it chunk by chunk and feed it manually it doesnt work :\
[15:40:20 CET] <gener1c> will some code help?
[15:43:03 CET] <kierank> wm4: wow, updating to latest ffmpeg changes my codepath from yuv -> yuv to yuv -> rgb -> yuv
[15:43:05 CET] <kierank> this is brilliant
[15:43:12 CET] <kierank> I am so glad we roll our own swscale
[15:43:36 CET] <durandal_170> what?
[15:43:50 CET] <wm4> awesome
[15:43:55 CET] <durandal_170> what path?
[15:44:04 CET] <wm4> does the rgb happen inside of swscale?
[15:44:07 CET] <kierank> yes
[15:44:15 CET] <kierank> yuv420p -> yuv422p
[15:44:28 CET] <wm4> have you tried zimg?
[15:44:29 CET] <kierank> no idea why but it goes via rgb now!!!
[15:44:34 CET] <wm4> (I heard it's good)
[15:44:51 CET] <kierank> I did to but rolling own swscale has worked well for years
[15:44:54 CET] <kierank> and it aint broke
[15:45:01 CET] <Daemon404> .. what the hell?
[15:45:21 CET] <Daemon404> kierank, is this via api or vf_scale
[15:45:29 CET] <kierank> api
[15:45:36 CET] <nevcairiel> it got some extra scaling steps to accomodate some extra changes, are you like changing the yuv matrix or something
[15:45:42 CET] <kierank> nope
[15:45:48 CET] <kierank> haven't touched a line of code
[15:45:58 CET] <bencoh> oO
[15:46:03 CET] <nevcairiel> that doesnt mean you didnt request a conversion step that it just couldnt fullfill before
[15:46:20 CET] <kierank> bencoh: it's upipe doing this btw
[15:46:37 CET] <Daemon404> kierank, how old was the old swscale
[15:46:39 CET] <wm4> (converting to rgb just for changing the yuv matrix still makes no sense)
[15:46:56 CET] <kierank> Daemon404: certainly before gsoc
[15:47:02 CET] <kierank> but a few years old perhaps
[15:47:06 CET] <nevcairiel> wm4: feel free to write code to do it directly, but right now it wants to fullfill the requests with the things it has
[15:47:18 CET] <bencoh> kierank: I'd first check whether it's a upipe bug or not :)
[15:47:19 CET] <Daemon404> kierank, thats quite a long time to try and figure out
[15:47:30 CET] <kierank> bencoh: it might be but behaviour changed
[15:47:38 CET] <bencoh> that's possible
[15:47:58 CET] <kierank> bencoh: need to move you to the new api first...
[15:48:20 CET] <bencoh> kierank: unit-tests ;)
[15:58:16 CET] <wm4> seems like Mesa is working towards improving vaapi for AMD
[16:03:21 CET] <wm4> (and same with nouveau)
[16:15:01 CET] <BtbN> And why did they decide to go for the horrible VAAPI interface, instead of vdpau?
[16:15:14 CET] <wm4> who knows
[16:23:31 CET] <cone-973> ffmpeg 03Derek Buitenhuis 07master:712d962a6a29: mov: Add an option to toggle dref opening
[16:23:32 CET] <cone-973> ffmpeg 03Michael Niedermayer 07master:158f0545d81b: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get()
[16:36:35 CET] <cone-973> ffmpeg 03Arttu Ylä-Outinen 07master:7d1e98552888: libkvazaar: Set frame rate as a rational number
[16:42:08 CET] <Zeranoe> Does FFmpeg use JACK1 or JACK2?
[16:46:24 CET] <J_Darnley> Is that one of them there linux audio APIs?
[16:49:53 CET] <wm4> it works on win and osx too
[16:51:35 CET] <Zeranoe> I think it uses 2
[16:52:12 CET] <Cloudef> Zeranoe: jack1 and jack2 are API compatible
[16:52:20 CET] <Cloudef> jack2 is broken with 32bit clients on 64bit 
[16:52:36 CET] <Cloudef> so the question which ffmpeg uses, does not matter
[16:52:58 CET] <durandal_170> there is no such support
[17:35:18 CET] <cone-973> ffmpeg 03Michael Niedermayer 07master:7ccedc1c78c9: avformat/img2dec: do not interpret the filename by default if a IO context has been opened
[17:35:20 CET] <cone-973> ffmpeg 03Bela Bodecs 07master:dec23859b040: vf_scale: eval, param0 and param1 documentation
[17:52:05 CET] <cone-973> ffmpeg 03Rostislav Pehlivanov 07master:a72b1ea8261f: aacenc: mark LTP mode as experimental
[17:58:27 CET] <cone-973> ffmpeg 03Rostislav Pehlivanov 07master:6a505e955b29: aacenc: remove FAAC-like coder
[18:04:06 CET] <cone-973> ffmpeg 03Rostislav Pehlivanov 07master:4a3cf186b2da: tests/fate/aac: remove unneeded strict arguments from the encoder tests
[18:17:26 CET] <Timothy_Gu> atomnuker: you might want to update the docs after the FAAC removal
[18:18:11 CET] <atomnuker> checked, I had already removed the coder when I marked it as experimental a month ago
[18:18:23 CET] <atomnuker> the documentation for it, that is
[18:30:38 CET] <Daemon404> 5 away from 500
[18:31:18 CET] <Daemon404> 4
[18:31:57 CET] <nevcairiel> at least the patches of that ticket were applied now and we have a vastly superior aac encoder ;)
[18:32:15 CET] <Daemon404> all of them?
[18:32:20 CET] <atomnuker> yep
[18:32:24 CET] <Daemon404> oic
[18:32:33 CET] <nevcairiel> and more!
[18:33:32 CET] <nevcairiel> I should import a new ffmpeg build in work software, make some people happy by improving aac quality
[18:35:08 CET] <atomnuker> it's already used in production broadcasts
[18:35:15 CET] <JEEB> nice
[19:35:28 CET] <BBB> jamrial_: can we use av_clip_pixel and base it off bit_depth_template.c?
[19:35:43 CET] <BBB> jamrial_: the diracdsp patch
[19:39:16 CET] <jamrial_> is it worth it? it doesn't look like it can easily be reused with the 8bit version of the function
[19:43:22 CET] <jamrial_> maybe poke kierank about it. he's the one that added >8bit support to dirac
[19:44:25 CET] <kierank> could do that but eventually I want that clip to be merged with an in-place transform 
[20:42:09 CET] <cone-973> ffmpeg 03James Almer 07master:4c4ebeb587cc: avcodec/wavpackenc: use put_sbits
[21:21:53 CET] <cone-973> ffmpeg 03Clément BSsch 07master:d96f0fbe59ae: lavu: add pthread asserts if ASSERT_LEVEL>1
[21:22:41 CET] <cone-973> ffmpeg 03Michael Niedermayer 07master:984d58a3440d: avformat/avio: Limit url option parsing to the documented cases
[21:22:42 CET] <cone-973> ffmpeg 03Michael Niedermayer 07master:2cb8edea7c9a: avcodec/aacenc: Check all coefficients for finiteness
[21:22:43 CET] <cone-973> ffmpeg 03Michael Niedermayer 07master:b750b67d1369: avformat/img2dec: Use AVOpenCallback
[21:24:58 CET] <cone-973> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:4590811fc216: ffplay: update docs after previous changes in ffplay mouse behaviour
[21:37:00 CET] <durandal_170> so, is foo86 decoder going in?
[21:37:05 CET] <cone-973> ffmpeg 03Clément BSsch 07master:a36201564163: lavc,lavfi: use avutil/thread.h instead of redundant conditional includes
[21:38:04 CET] <durandal_170> have anybody looked at showwaves color patch?
[21:44:31 CET] <nevcairiel> durandal_170: we have not heard any opposition from anyone, so likely yes
[21:44:33 CET] <nevcairiel> re dca
[21:50:14 CET] <nevcairiel> i should comment on the patchset again tomorrow
[21:52:01 CET] <Mo_YouVisit> Hey guys!
[21:52:31 CET] <Mo_YouVisit> I am working on a FFMPEG filter and was wondering if there is a faster way to prototype changes rather than rebuild FFMPEg every time?
[21:53:13 CET] <rcombs> uh incremental builds are a thing
[21:54:09 CET] <jamrial> don't think so, but editing the one c file you're dealing with shouldn't require rebuilding ffmpeg, just recompiling that one file
[21:54:28 CET] <jamrial> unless you're also editing a header that's included by everything
[21:54:41 CET] <jamrial> also, ccache is your friend
[22:00:50 CET] <Daemon404> ccache is love, ccache is life
[22:16:44 CET] <durandal_170> ubitux: so conclusion is doing two normal streamselect filters instead of one multimedia filter?
[22:22:32 CET] <ubitux> yes that's ok with me
[22:22:36 CET] <ubitux> if it indeed works
[23:02:54 CET] <ubitux> http://ubitux.fr/pub/pics/ffthreads.png heh
[23:04:21 CET] <JEEB> looks cool, can we get moar?
[23:04:47 CET] <ubitux> i'm a bit disturbed at the number of threads for lavfi
[23:04:59 CET] <JEEB> yeah, it definitely doesn't have a lack of them
[23:05:12 CET] <ubitux> i suppose i have 8 threads per filter
[23:05:33 CET] <ubitux> including converters, sinks etc
[23:05:43 CET] <wm4> thread pool time?
[23:05:50 CET] <ubitux> :)
[23:24:09 CET] <ubitux> wm4: if i replace defined(__linux__) with defined(__linux__) && defined(__GLIBC__) would that be ok?
[23:26:40 CET] <wm4> hm that might be fine
[23:26:51 CET] <wm4> since it's a glibc extension
[23:27:10 CET] <nevcairiel> sounds like i should implement that for w32threads
[23:27:13 CET] <nevcairiel> naming them might be useful
[23:40:08 CET] <atomnuker> I remember looking into the thread naming APIs and wondering how implementations managed to mess it up so hard
[23:46:13 CET] <ubitux> :D
[23:46:50 CET] <ubitux> 16-char limitation on linux is pretty sick
[23:46:54 CET] <ubitux> reminds me of fat16
[23:47:52 CET] <kierank> is there any way of turning off colours in ffmpeg cli
[23:48:34 CET] <J_Darnley> I recall some env var can be used but not its name
[23:48:56 CET] <kierank> it ruins "script"
[23:49:13 CET] <J_Darnley> NO_COLOR
[23:49:34 CET] <atomnuker> TERM=xterm
[23:55:35 CET] <atomnuker> actually ansi-mono, but even that doesn't help with ffmpeg
[00:00:00 CET] --- Thu Jan 21 2016