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

[burek]

[00:07:43 CET] <cone-570> ffmpeg 03Steven Liu 07master:b05d0274ce7d: avformat/hlsenc: fix bug of hlsenc http delete old segments
[00:10:28 CET] <cone-570> ffmpeg 03Steven Liu 07master:90096e42e1e9: avfilter:vf_drawtext: add new line space size set parameter
[00:10:54 CET] <BBB> Gramner: but theres pshufb! :D
[00:11:01 CET] <BBB> and pshufd
[00:11:02 CET] <BBB> and shufps
[00:11:14 CET] <BBB> all of which have slightly different semantics for no reason whatsoever
[00:11:16 CET] <BBB> brb
[00:12:42 CET] <Gramner> avx-512 (or well, avx-512vbmi for bytes) finally fixes most permutation issues at least
[00:19:35 CET] <philipl> BtbN: why do any check_device steps of the index doesn't match?
[00:20:22 CET] <philipl> s/of/if
[00:23:08 CET] <philipl> BtbN: arguably, if the user passes an index, just check that device and don't bother checking any of the others at all
[00:44:39 CET] <cone-570> ffmpeg 03Paul B Mahol 07master:6c43f33ac2e7: avcodec/wmaprodec: >2 channel support for XMA
[02:52:07 CET] <cone-570> ffmpeg 03Tobias Rapp 07master:c324e2c5db26: ffmpeg: pass output stream duration as a hint to the muxer
[02:52:08 CET] <cone-570> ffmpeg 03Piotr Bandurski 07master:bcfa8551a1a1: avformat/caf: add 'aacl' codec tag
[05:18:49 CET] <Compn> wm4 : you may have banned that guy but he just keeps coming back :P
[06:12:53 CET] <wm4> Compn: dynamic ip
[06:46:14 CET] <rcombs> if all else fails ban his ISP
[09:59:14 CET] <wm4> ubitux: is it welcome when people port random yet-unmerged patches (which they need for whatever reasons) from Libav to ffmpeg?
[10:00:23 CET] <ubitux> i don't see why not, it wouldn't be the first time it happens
[10:00:31 CET] <ubitux> especially since it means the patch gets tested\
[10:00:41 CET] <ubitux> ...and we have 800+ commits to merge
[10:01:07 CET] <ubitux> and we can noop them by batch when we reach that point
[10:01:51 CET] <ubitux> of course ideally we would have everyone helping with the merge to prevent that
[10:02:09 CET] <ubitux> and we would be just a few commits behind
[10:02:42 CET] <ubitux> speaking of this, that next commit is cool but complex to merge.
[10:03:19 CET] <wm4> so I take it porting patches is actually welcome
[10:05:38 CET] <ubitux> of course?
[10:05:45 CET] <ubitux> when wasn't it?
[10:06:27 CET] <ubitux> ppl not agreeing with this can help with the merges
[10:06:56 CET] <ubitux> we're in no position to complain about that given the current state
[10:41:05 CET] <cone-577> ffmpeg 03Clément BSsch 07master:e5ac554ba7d6: lavc/h264: simplify find_unused_picture()
[10:47:24 CET] <BtbN> philipl, that's exactly what the patch does?
[10:49:11 CET] <BtbN> I still want it to list devices and stuff, so just skipping the expensive capability checks
[12:33:46 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:1daa08bd9699: avcodec/wmapro: redone stream selection for XMA1/2
[12:52:23 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:be46eb710139: avcodec/pixlet: clip chroma before shifting
[12:59:08 CET] <ubitux> durandal_1707: av_clip_uintp2(x, 15)?
[13:22:14 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:a340987e37f9: avcodec/pixlet: use av_clip_uintp2()
[13:23:07 CET] <ubitux> durandal_1707: so depth and not 15 hardcoded? does av_clip_uintp2() compiles everywhere properly now when the 2nd argument isn't const?
[13:23:12 CET] <ubitux> sorry for nagging about it :)
[13:28:40 CET] <durandal_1707> ubitux: hmm, would need to add fate test to find out
[13:29:04 CET] <ubitux> durandal_1707: it will fail at build if it's still not fixed
[13:29:29 CET] <durandal_1707> doesnt fail here
[13:29:36 CET] <ubitux> depends on the arch
[13:29:54 CET] <ubitux> like, on arm the optimised version only works with a constant
[13:30:07 CET] <ubitux> and it doesn't (didn't?) fallback on the _c version
[13:30:35 CET] <durandal_1707> then i will switch to c version explicitly
[13:34:33 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:0fe50e56e9ca: avcodec/pixlet: use av_clip_uintp2_c explicitly
[15:44:41 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:45f4bf94afb8: avcodec/wmaprodec: check number of channels for XMA streams
[16:04:45 CET] <ubitux> lol vdpau
[16:05:08 CET] <ubitux> who is available to test the old vdpau code?
[16:05:27 CET] <mateo`> do not lol again
[16:05:33 CET] <mateo`> it's not funny
[16:07:30 CET] <BBB> its that time of the day that I ask stupid questions
[16:07:37 CET] <BBB> has anyone ever looked into optimizing jpeg2k decoding?
[16:07:57 CET] <BBB> Im using the built-in decoder, and this is really excruciatingly slow
[16:08:42 CET] <BBB> (I havent profiled yet, but I can sense when something is eating my laptop, and this thing totally sucks it up)
[16:09:10 CET] <kierank> iirc all software j2k decoders are slow
[16:09:17 CET] <kierank> but no i have not
[16:09:23 CET] <BBB> why are they slow?
[16:09:33 CET] <BBB> stupid questions? :D
[16:09:42 CET] <kierank> arithmetic coder iirc
[16:09:51 CET] <kierank> and perhaps we don't have simd transforms
[16:10:36 CET] <BBB> WRITE_FRAME looks like it is like put_pixels but without simd?
[16:11:16 CET] <philipl> BtbN: Ok, sure. 
[16:11:26 CET] Action: kierank actually looks at the code instead of trying to remember stuff from years ago
[16:11:32 CET] <BBB> dequant is not simd
[16:13:52 CET] <BBB> but youre right, arithcoding would make it slow
[16:14:05 CET] <BBB> esp. for intra only at low quant ...
[16:17:54 CET] <kierank> BBB: oh your looking at that netflix thing
[16:17:56 CET] <kierank> i'm so sorry for you
[16:18:01 CET] <kierank> having to deal with j2k in mxf
[16:18:05 CET] <BBB> it works
[16:18:12 CET] <kierank> sure but it's horrid
[16:18:25 CET] <BBB> I cant deny that it could certainly be improved &
[16:21:26 CET] <mateo`> I don't remember, how can I make fate use a particular hwaccel (let's say vaapi) ?
[16:31:09 CET] <BBB> mateo`: wasnt it make HWACCEL=vaapi fate?
[16:32:53 CET] <mateo`> BBB: thx !
[16:45:25 CET] <BtbN> philipl, not sure if you've been following the conversation in #ffmpeg yesterday, but what currently happens is that if GPU #0 is fully loaded, creating a CUDA and NVENC context gets stuck and makes ffmpeg hang forever
[16:45:40 CET] <BtbN> so it's entirely impossible right now to use GPU #1 if GPU #0 is fully under load.
[17:18:05 CET] <ubitux> ETA on the next libav commit: it works for sw decoding but is broken with hwaccel
[17:18:33 CET] <ubitux> next *merge* (it probably works in libav)
[17:26:34 CET] <BBB> kierank: I see 21% in dwt_decode97_float(), which looks trivially simdable
[17:27:02 CET] <BBB> another 14% in st_qd97, which is called from dwt_decode97_float and also seems trivially simd'able
[17:28:07 CET] <wm4> ubitux: which one?
[17:28:45 CET] <mateo`> wm4: 4a9bab3db0d9ec449ebc8b5e823374d1d1df7761
[17:28:54 CET] <BBB> kierank: the arithcoder is mqc? that has no x86 assembly (which cabac or vp5/6/8/9s arithcoder do have), may speed it up slightly
[17:28:54 CET] <mateo`> h264: fix decoding multiple fields per packet with slice threads
[17:29:15 CET] <BBB> kierank: which probably accounts for 50% of total cpu time
[17:29:40 CET] <BBB> so if the arithcoder cn be sped up by 10-20% and the simd of the other 35% single function can make that a quarter, itd overall be twice as fast already
[17:30:06 CET] <BBB> mqc in particular seems strange because its not inlined& function call overhead is going to be exceptioanlly large
[17:31:50 CET] <BBB> I should also note that 5% of cpu time is spent in memset(0)
[17:32:15 CET] <BBB> and 6% in write_frame(), which is what I referred to earlier as a most trivially optimizable analog of put_pixels
[17:32:29 CET] <ubitux> BBB: is the j2k decoder mature enough now? i thought that was the main reason for the lack of optimization and stuff
[17:32:30 CET] <BBB> 2.2% in dequant_float, which is also trivially optimizable
[17:32:39 CET] <BBB> I dont know& nobody is working on it
[17:32:43 CET] <BBB> it just sits there, rotting and useless
[17:32:58 CET] <BBB> but its selected by default
[17:33:17 CET] <jamrial_> i wrote some simd for it months ago
[17:33:25 CET] <jamrial_> bah, ported some intrinsics that were submitted to libav to yasm
[17:33:38 CET] <jamrial_> don't think it made much of a difference anyway
[17:33:41 CET] <BBB> decode_refpass 6.5% ...
[17:40:35 CET] <kierank> personally I don't want to support netflix in their IMF crusade
[17:41:07 CET] <kierank> durandal_1707: sony are going to get me more samples
[17:51:22 CET] <wm4> what imf crusade?
[17:57:39 CET] <Polochon_street> Hi! I'd like to revive this issue/patch somehow, where should I go to do that? http://ffmpeg.org/pipermail/ffmpeg-devel/2015-February/168248.html
[17:58:48 CET] <Polochon_street> the patch is written, but some decision needs to be taken over the "what error should we raise" issue so I don't know which mailing to use to discuss about it...
[18:01:04 CET] <durandal_1707> wm4: interoperable multimedia format?
[18:01:36 CET] <kierank> j2k in mxf with tons of enterprise xml crap
[18:03:43 CET] <wm4> Polochon_street: ffmpeg-devel is right
[18:04:40 CET] <Polochon_street> wm4: alright, thanks. Is it alright if I link to the previous thread and sum up a bit the situation?
[18:10:38 CET] <wm4> probably
[18:43:10 CET] <philipl> BtbN: I didn't see that, but that's worth a chuckle. And that's with your patch or without it? or both?
[18:43:26 CET] <BtbN> without, that's the entire point of it.
[18:43:42 CET] <philipl> Ok. Change is fine.
[18:44:04 CET] <BtbN> Still waiting if the guy replied back testing the patch on his systems
[18:44:31 CET] <wm4> nvenc appears to exit immediately if the "maximum" usage is reached
[18:45:21 CET] <wm4> and cuvid doesn't work on my system right now (no idea why)
[18:45:54 CET] <BtbN> if the 2 sessions limit is reached, yes
[18:46:02 CET] <BtbN> but in this case it was an unlimited card
[18:46:06 CET] <BtbN> and just 100% video engine load
[18:46:29 CET] <BtbN> so it just hangs on init until the load drops
[18:46:43 CET] <wm4> didn't know there are unlimited cards (is that for server use lol)
[18:47:23 CET] <BtbN> The 2 session limit is just an artificial limit in the consumer-card drivers, so people wanting to set up a transcode server or whatever buy expensive quadro cards
[18:48:44 CET] <philipl> wm4: Which card and what error for cuvid?
[18:49:10 CET] <wm4> "cuInit(0) failed" - it's probably something driver related
[18:49:30 CET] <BtbN> nvenc calls that as well, it's the most basic cuda call there is oO
[18:49:38 CET] <wm4> nvenc also fails
[18:49:53 CET] <philipl> The driver can get wedged occasionally (especially after suspend/resume)
[18:49:56 CET] <philipl> try rebooting :-)
[18:49:57 CET] <wm4> (I tested that part a few weeks ago)
[18:50:16 CET] <wm4> I don't normally reboot
[18:50:23 CET] <philipl> It'll be an adventure.
[18:50:37 CET] <philipl> You could try unloading nvidia driver completely. No idea if that's sufficient.
[18:50:43 CET] <BtbN> unloading and re-loading the kernel modules should also revive it
[18:51:16 CET] <BtbN> unless the hardware itself is in some kind of invalid state, then it needs an actual power cycle
[18:51:57 CET] <wm4> that would probably involve stopping X
[18:52:49 CET] <philipl> It would.
[18:52:54 CET] <philipl> You can only lead a horse to water, etc.
[18:53:23 CET] <BtbN> well, you can force unload it, and spectate how X likes it
[18:53:36 CET] <wm4> tried in a different X session, same thing
[18:53:47 CET] <wm4> VT switches are normally quite... resettting
[18:53:47 CET] <BtbN> cuvid/nvenc are fully independend of X
[18:53:51 CET] <BtbN> they also run headless without X
[18:54:07 CET] <BtbN> it's just about the kernel modules
[18:54:16 CET] <wm4> if I VT switch, and mpv is running with cuda decoding, it's broken when switching back
[18:54:25 CET] <wm4> (no errors, video doesn't update)
[18:54:39 CET] <BtbN> sounds more like an issue with the video output than the decoding
[18:54:45 CET] <wm4> btw. in theory you can run headless EGL with nvidia drivers now
[18:54:54 CET] <BtbN> but without vdpau
[18:55:08 CET] <wm4> yeah, no vdpau with EGL at all
[18:55:17 CET] <wm4> nvidia stopped caring about vdpau
[19:00:45 CET] <philipl> Does the cuda interop work with egl? I assume so but never tried.
[19:03:24 CET] <philipl> wm4: there might be some pre-emption stupidity going on. but I never saw a preemption concept in cuda like vdpau has.
[19:03:47 CET] <wm4> not sure, but I think ti works with EGL (can't try now)
[19:03:53 CET] <wm4> *it
[19:03:58 CET] <philipl> I'll try tonight
[19:04:09 CET] <wm4> which is another thing that makes cuda attractive
[20:19:11 CET] <cone-577> ffmpeg 03Michael Niedermayer 07master:1df3d636d46b: avcodec/speedhq: Fix warning about "initialization from incompatible pointer type"
[20:29:29 CET] <cone-577> ffmpeg 03Aleksandr Slobodeniuk 07master:545511f57a3f: avcodec/avcodec: fix lil typo in comment
[20:59:39 CET] <Cloudef> Is there some very simple container format for muxin raw video and audio? I would like some simple intermediate format to pass data for ffmpeg without manually specifying switches for format, size and so on. Also wondering if there is interest for some sort of shm input source?
[21:00:36 CET] <Cloudef> hmm actually wrong channel I am in
[21:02:09 CET] <atomnuker> Cloudef: nut can
[21:02:30 CET] <Cloudef> atomnuker: I started writing code for nut actually, but it still seemed rather too much for simply passing raw data
[21:03:02 CET] <atomnuker> matroska can too I think but that's even more complicated
[21:03:23 CET] <Cloudef> yeah, that's I'm aware of. And apparently from ffmpeg sources raw isn't really supported in matroska officially
[21:03:34 CET] <atomnuker> (though it needs a special flag and I think only supports certain formats)
[21:05:56 CET] <atomnuker> also you could use pipes for shm input
[21:06:04 CET] <Cloudef> pipes need copy though?
[21:06:11 CET] <Cloudef> (that's what i'm doing atm anyways)
[21:07:11 CET] <atomnuker> yeah, they're not zero copy
[21:07:12 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:546e29d1f534: avcodec/exr: make it aware of 2 additional compressions
[21:07:13 CET] <cone-577> ffmpeg 03Paul B Mahol 07master:8a1759ad46f0: avcodec/exr: export writer info into frame metadata
[21:07:31 CET] <Cloudef> of course with proposed -i shm:<path> one would need some sort of synchronization protocol
[21:07:53 CET] <atomnuker> why not use the API?
[21:08:16 CET] <Cloudef> I'm passing data to ffmpeg from another program that I wrote
[21:08:56 CET] <Cloudef> I don't really want to use libraries, as they are not useful as ffmpeg unless you go through hoops
[21:10:28 CET] <Cloudef> pipe does work decently anyhow, so that isn't problem though
[21:12:52 CET] <atomnuker> if you don't care about performance then yeah, nut is okay (there's also libnut which you can copy)
[21:13:14 CET] <Cloudef> yeah I probably will just use libnut if there isn't anything else. Was hoping there was something that did not need much support code
[21:13:36 CET] <Cloudef> the whole thing I have right now is just 291 lines and it can capture video / audio from opengl/alsa program
[21:14:05 CET] <Cloudef> _I guess_ I could add this into ffmpeg as something like x11grab as well, but..
[21:14:14 CET] <Cloudef> I really like when tools are separate and work together
[21:15:02 CET] <wm4> atomnuker: isn't libnut stale and dead
[21:15:31 CET] <atomnuker> yeah, but it should still work
[22:12:48 CET] <debianuser> Cloudef: 291 lines for capturing video+audio is nice! I have samples for alsa capture (e.g. http://pastebin.com/7kk4z5F3 ) But how do you capture opengl? Do you intercept glFlush() somehow?
[22:13:01 CET] <Cloudef> debianuser: glxSwapBuffers
[22:13:21 CET] <Cloudef> I use 2 pbos to fill the pixel data
[22:13:30 CET] <Cloudef> It could be possible to hook into drm to capture even faster I guess
[22:13:40 CET] <Cloudef> but that would mean it will only work with open source drivers
[22:15:36 CET] <Cloudef> debianuser: I hook into alsa so I don't actually  read pcm
[22:15:44 CET] <Cloudef> I simply write what application outputs
[22:17:14 CET] <debianuser> How do you intercept it? LD_PRELOAD? Or do you inject your code into the process memory somehow?
[22:17:35 CET] <Cloudef> LD_PRELOAD but I plan to hook using ptrace later, so I can attach it to window anytime and not inject to bunch of processes
[22:19:02 CET] <Cloudef> that would just mean additional binary, though the meat can still be used with LD_PRELOAD anyhow
[22:21:49 CET] <Cloudef> On X11 without Composite I guess this is only way to get every frame recorded for sure, on wayland It would be possible by compositor of course
[22:26:35 CET] <debianuser> Nice! Thanks for explaining! I'm mostly about alsa, never tried to capture opengl yet. It would be interesting to try and fit the code into less than 300 lines. :)
[22:26:52 CET] <Cloudef> Hopefully I can put this somewhere soon
[22:27:07 CET] <Cloudef> I just wanted to record my card game replay :P
[22:27:24 CET] <Cloudef> and was severly dissapointed by the current offering quality
[00:00:00 CET] --- Fri Jan 20 2017