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

[burek]

[00:31:39 CEST] <cone-150> ffmpeg 03Paul B Mahol 07master:c784b5cfdc7e: avfilter/vf_histogram: set foreground alpha if possible in destination format
[01:20:14 CEST] <cone-150> ffmpeg 03Michael Niedermayer 07master:68f4c2163ec6: avformat/movenc: Check first DTS similar to dts difference
[01:20:15 CEST] <cone-150> ffmpeg 03Michael Niedermayer 07master:24b391890139: tests/fate-run.sh: Analyze file generated in transcode()
[01:20:16 CEST] <cone-150> ffmpeg 03Michael Niedermayer 07master:ae7d4e17eb3b: fate: Add copy-trac2211-avi test
[01:21:10 CEST] <iconnor_> Howdy. I'm from the core ZoneMinder dev team.  Anyone around to help me with some issues?
[01:21:27 CEST] <DHE> this channel is for code going into ffmpeg, not third parties using libav*.so
[01:22:31 CEST] <iconnor_> well your code segfaults.  My issues are not about using the lib.. 
[01:23:09 CEST] <DHE> oh?
[01:24:50 CEST] <Chloe> iconnor_: Make a minimal testcase to trigger the bug
[01:25:01 CEST] <iconnor_> yes.  av_read_frame pulling from a remote camera over rtsp.  Reboot the camera.  libffmpeg  segfaults in av_read_frame without returning.  This in on ubuntu 1604
[01:25:26 CEST] <iconnor_> OK. 
[01:26:24 CEST] <iconnor_> C U in a couple years.
[01:26:56 CEST] <Chloe> or just paste a backtrace
[01:52:48 CEST] <llogan> that went well
[01:58:53 CEST] <CFS-MP3> You gotta love when two developers hit it off
[02:02:02 CEST] <Chloe> I don't think it was an unreasonable request tbh, a backtrace would have at least helped as well.
[02:16:36 CEST] <jamrial> libffmpeg?
[02:17:46 CEST] <llogan> if it was older ubuntu he would have been using liblibav
[02:24:31 CEST] <rcombs> clearly the segfault happening within lav* means it must not be the consumer code's fault
[02:39:52 CEST] <jamrial> rcombs: ideally it wouldn't segfault, but yeah, probably sending null pointers as argument somewhere that aren't being checked or such
[03:08:03 CEST] <cone-150> ffmpeg 03Rodger Combs 07master:1177e4212136: lavc/Makefile: g729dec: fix missing file
[03:08:04 CEST] <cone-150> ffmpeg 03Rodger Combs 07master:7c5fed15a8df: lavc/Makefile: add missing ADPCM_THP_LE objs
[05:18:44 CEST] <philipl> BtbN: FYI, the key part of your fix was using the pkt timebase. That is set to a (I think) sane value in mpv.
[05:19:05 CEST] <philipl> 1/1000000
[06:43:45 CEST] <rcombs> jamrial: re: types in AVMatroskaEncoding, they're both straight out of EBML values, which can be up to 64 bits long and are internally uint64_t; in practice, they could fit together in a single byte with the current values, and it'd be pretty absurd to have large numbers of either&
[06:44:28 CEST] <rcombs> also, in C casting uint64_t to enum technically results in an indeterminate value if it's outside the range of defined enumerations
[06:44:57 CEST] <jamrial> yeah, but the chances for it to ever need that many values is pretty much zero
[06:45:14 CEST] <rcombs> also also, it occurs to me that it's technically possible to have both encryption and compression applied, so I should adjust this to handle that
[06:47:15 CEST] <rcombs> lavf doesn't support that right now, but that's no reason make it harder to add in future
[06:51:04 CEST] <rcombs> side-note whose idea was it to have an "order" field in matroska encodings instead of& requiring them to be in order
[06:53:16 CEST] <rcombs> does a test file with multiple encodings even exist
[06:53:44 CEST] <rcombs> I could probably throw in a qsort() call and handle it pretty easily, but I'd need something to actually try it with
[11:14:33 CEST] <rcombs> >omg i wrote this
[11:14:33 CEST] <rcombs> ^ tfw
[13:22:23 CEST] <cone-365> ffmpeg 03Paul B Mahol 07master:b257266ee8b3: avfilter/af_amix: use ff_all_channel_counts() instead of ff_all_channel_layouts()
[13:32:30 CEST] <ubitux> it's a bit frustrating when you write a denoiser filter that takes a minute to process a 512² picture and the picture is almost unchanged even at maximum sigma :(
[13:32:43 CEST] <ubitux> the hell i'm doing
[13:32:53 CEST] <JEEB> :D
[13:34:42 CEST] <ubitux> and i'm pretty sure the ±1 changes i'm seeing are just shitty float approximation after summing the whole picture a million times
[13:35:04 CEST] <durandal_17> ubitux: can't you compare with other implementations?
[13:35:19 CEST] <durandal_17> also what kind of noise is your files?
[13:36:27 CEST] <ubitux> mmh i think other implementations are gpl so i'd better not (i'm basing most of my stuff on fake/broken/inconsistent/meaningless pseudo code from papers)
[13:36:32 CEST] <ubitux> generated noise
[13:36:50 CEST] <ubitux> but it's just a bug in the filter, not because of a special input
[13:36:56 CEST] <durandal_17> ubitux: generated with what?
[13:37:09 CEST] <ubitux> i don't remember, i think i got it from ipol
[13:37:14 CEST] <durandal_17> ubitux: i mean compare output of other implementations not code
[13:37:33 CEST] <ubitux> other implementations work well :)
[13:37:57 CEST] <ubitux> i'm just a dumbass, don't worry, i'll find the problem
[13:38:01 CEST] <durandal_17> ubitux: i have 2 samples with iso noise
[13:40:01 CEST] <ubitux> feel free to share them
[14:41:26 CEST] <ubitux> ok, found my problem, yey
[16:38:38 CEST] <durandal_170> what filter needs more speed?
[16:39:30 CEST] <BtbN> color/chromakey
[16:40:20 CEST] <BtbN> chromakey also needs spill reduction, which might alter the algorithm a bit once I/someone actually gets to it.
[16:42:34 CEST] <durandal_17> its using sqrt, that can't be SIMDable
[16:44:13 CEST] <BtbN> No sqrt operating on 4 or 8 ints at a time?
[16:46:28 CEST] <durandal_17> hmm, it appears there is one
[16:47:15 CEST] <durandal_17> it operates on floats...
[16:49:31 CEST] <BtbN> Hm, no idea if the algorithm somehow also works without the sqrt
[16:50:15 CEST] <BtbN> It's nice and fast when calculated on a GPU
[16:51:13 CEST] <BtbN> But it needs doubles, single-precision isn't enough, and double precision isn't supported with OpenCL everywhere, so the patches for that were never merged
[17:15:25 CEST] <durandal_170> BtbN: why it needs doubles?
[17:17:25 CEST] <BtbN> the precision of floats doesn't seem to be enough, it doesn't work for certain colors with it
[18:19:36 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/d5fff73d104b19eabc4c4f3654c8430f28875ee8
[18:19:42 CEST] <philipl> undocumented apis are fun!
[18:23:15 CEST] <durandal_170> nobody wants to review overlay patch?
[19:40:16 CEST] <durandal117> gonna apply overlay patch, anybody against?
[20:31:14 CEST] <iive> durandal117: in the past there was a rule that allowed you to commit a patch if nobody objected/reviewed in 2 days.
[20:32:24 CEST] <durandal117> iive: even in mplayer days?
[20:32:54 CEST] <iive> exactly because of mplayer days.
[20:33:27 CEST] <durandal117> mplayer years are golden years
[20:33:31 CEST] <BtbN> if somebody doesn't like it, he/she would have voiced that within that time.
[20:51:37 CEST] <durandal117> if you will be nice and review it, it could be pushed immediately, its gives nice speed boost. and it is not fringe filter
[21:00:31 CEST] <durandal117> so nobody cares, good, i will push immediately
[21:01:48 CEST] <iive> you can always ask michaelni for review
[21:02:18 CEST] <JEEB> in my client I see those patches being posted four hours ago, and it's the weekend
[21:03:26 CEST] <JEEB> while I am all for asking for reviews, but usually people start herping a derp if their patch has been on the ML for a few days
[22:28:10 CEST] <BtbN> The configure line for cuda builds is annoying.
[22:30:38 CEST] <BtbN> Kind of feel like adding a cuda based filtering infrastructure, but OpenCL already exists...
[22:35:56 CEST] <BtbN> Windows CUDA SDK is 1.2GB...
[22:36:04 CEST] <JEEB> yeah
[22:36:06 CEST] <Chloe> would the opengl outdev also have to be deprecated because it optionally uses SDL (uses it when no OpenGL context is provided)? I guess you could be forced to provide a context, but then it wouldnt be useable from ffmpeg
[22:36:25 CEST] <BtbN> There is an opengl outdev?
[22:36:39 CEST] <BtbN> What does it do? And who uses it?
[22:36:56 CEST] <JEEB> IIRC it wasn't really good. someone just wanted to externalize their code into FFmpeg
[22:37:34 CEST] <BtbN> Then just deprecate it alongside with sdl. If someone wants it, he'll complain.
[22:41:49 CEST] <cone-357> ffmpeg 03Philip Langdale 07master:4029f05c8b09: avcodec/cuvid: Always check for internal errors during parsing
[22:42:48 CEST] <BtbN> fritsch, what exactly of VP9 and HEVC10 is even missing for vaapi? I think both is already implemented and should be working as is.
[22:52:31 CEST] <Chloe> durandal117: I even said that in the email
[22:53:02 CEST] <Chloe> 'Due to how SDL2 works (it requires the main thread), there won't be able to be a replacement'
[22:53:43 CEST] <BtbN> The whole concept of having a UI player stuffed into lavd seems bad to me
[22:55:06 CEST] <Chloe> you can achieve the same result anyway by just having an extra output and piping that into mpv o.e.
[22:55:23 CEST] <JEEB> or just having a separate VO library
[22:55:25 CEST] <Chloe> I think it may even be easier with the fifo muxer (not that I've tried it)
[22:55:30 CEST] <JEEB> and using that in your app
[23:23:07 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:054f912c0d73: avfilter/avf_concat: Make independent of the channel layout
[23:52:34 CEST] <iive> what's wrong with outdev? doesn't ffplay use them?
[23:52:54 CEST] <Chloe> ffplay doesnt use them
[23:53:10 CEST] <Chloe> but ffplay cant use sdl2 until they're gone
[23:53:42 CEST] <iive> you can't have both sdl1 and sdl2?
[23:53:52 CEST] <iive> at the same time
[23:53:56 CEST] <Chloe> You can, but the ffplay maintainer doesnt want that
[23:54:45 CEST] <Chloe> I dont think it'd be wise to continue supporting sdl1 considering it's last release was 4 years ago, and it has been explicitly marked by the developers as unmaintained and superseeded
[00:00:00 CEST] --- Sun Sep 11 2016