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

[burek]

[00:49:46 CET] <kierank> atomnuker: afaik no
[00:50:08 CET] <kierank> (yes this makes opus weird)
[00:50:41 CET] <atomnuker> nah, its cool, my encoder behaves normally
[00:50:57 CET] <kierank> You can't make the user do that though
[00:51:03 CET] <kierank> If that's what you're asking
[00:51:24 CET] <atomnuker> no, I was just wondering, doesn't matter though since my code still works
[00:51:34 CET] <kierank> Ah
[00:52:04 CET] <kierank> Do you set codec->frame_size to the lowest opus frame length?
[00:52:28 CET] <kierank> And then buffer input and output packets when you want?
[00:52:46 CET] <atomnuker> yeah, you feed it in 120 sample frames and depending on the lookahead it'll output variable sized encoded frames
[00:52:52 CET] <kierank> Ah good
[00:52:58 CET] <kierank> That's the correct way :)
[00:53:52 CET] <atomnuker> av_frame_clone()s the input avframes into a bufferqueue and then frees them when it finishes with them
[00:54:17 CET] <atomnuker> cloning just refs the actual data planes so no copying, it works great
[00:54:35 CET] <cone-619> ffmpeg 03Michael Niedermayer 07master:f28299da8d06: avcodec/h264dec: Clear ref_count on slice header processing failure
[00:58:30 CET] <atomnuker> the audioframequeue is awesome since it doesn't require the #input to match the #output samples nor the #frames to match
[00:59:10 CET] <atomnuker> you just ask it to remove #amount of samples from the buffer and it doesn't care, it'll just set the packet frame size and duration correctly
[01:05:50 CET] <kierank> I never really understood audioframequeue
[01:08:32 CET] <atomnuker> it just sets the output packet pts and duration, nothing more
[08:36:22 CET] <cone-343> ffmpeg 03Carl Eugen Hoyos 07master:fca30832828a: lavf/img2dec: Reduce the probe score for incomplete jpgs.
[10:47:42 CET] <Traktorrr> Hi people
[10:52:46 CET] <Traktorrr> we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1
[10:53:46 CET] <Traktorrr> Now we need to get more, and the phase between audio channels, left and right is it possible?
[11:08:45 CET] <Traktorrr> i need heeeeelp!!!
[11:26:25 CET] <Traktorrr> nu suki ebanie 
[11:26:30 CET] <Traktorrr> shnelya
[11:26:43 CET] <Traktorrr> hendehog
[11:26:52 CET] <Traktorrr> fuck you spilberg
[11:34:33 CET] <Traktorrr> Hi people [14:53:29]	9Traktorrr:  we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1 [14:54:29]	9Traktorrr:  Now we need to get more, and th
[11:34:51 CET] <Traktorrr>  Now we need to get more, and the phase between audio channels, left and right is it possible?
[11:38:53 CET] <Polochon_street> wm4: about the ID3 tags issue, I'm not really a specialist about ffmpeg's innards, but I'd like to give a try to correct mp3dec.c . The idea would be to keep the previous modification, and to do what you said in mp3dec.c to avoid the nasty side-effects Michael talked about?
[11:42:20 CET] <durandal_1707> atomnuker: i got some outlht with fft but samples do not line up, there is spike each 128 samples
[11:47:20 CET] <atana> michaelni: I have problem understanding the valgrind message https://dpaste.de/LheE where is the problem at line 125 in https://github.com/atana1/FFmpeg/blob/master/libavfilter/af_peakpoints.c
[11:50:31 CET] <Traktorrr> the ebur filter displays LUFS, DBFS necessary to us rovn of signals how to force it to display a phase???
[11:50:57 CET] <Traktorrr> the ebur filter displays LUFS, DBFS levels of signals necessary to us how to force it to display a phase???
[11:51:04 CET] <atomnuker> durandal_1707: each frame is 1024, right? a spike each 128 samples might mean there's a transient and they store the coeffs like [frame0_sample0...frame0_sample127] [frame1_sample0...frame1_sample127], etc.
[11:51:27 CET] <atomnuker> *coeffs, not samples
[11:51:51 CET] <atomnuker> or were you talking about the samples as in the samples you get after an inverse transform?
[11:52:02 CET] <durandal_1707> there is 128 im and re coeffs
[11:52:14 CET] <durandal_1707> yes after ifft
[11:52:35 CET] <atomnuker> is it an imdct or an ifft you have to do?
[11:53:21 CET] <durandal_1707> ifft
[11:53:45 CET] <durandal_1707> sox uses sonething called dft
[11:54:31 CET] <atomnuker> that's quite odd, I thought atrac9 was fully mdct based
[11:55:29 CET] <atomnuker> you still do windowing, right? a spike each x samples could indicate you're not windowing correctly
[11:59:32 CET] <JEEB> gotta love those probing functions, I guess? :3
[11:59:47 CET] <durandal_1707> atomnuker: i'm talking about new fir filter in lavfi, atrac9 is for later
[11:59:57 CET] <JEEB> oh, atrac9? najs
[12:00:09 CET] <JEEB> I was thinking of poking that at some point
[12:01:07 CET] <durandal_1707> JEEB: you want to write decoder?
[12:01:20 CET] <JEEB> I have other things to finish first :)
[12:01:38 CET] <JEEB> some of which have been WIP since 2012, so... yeah. not high on my priority list
[12:01:43 CET] <JEEB> so feel free if you're quicker
[12:03:21 CET] <atomnuker> durandal_1707: we have an rdft too, did you see if you can use it?
[12:04:11 CET] <durandal_1707> hmm
[12:12:50 CET] <ubitux> atana: avc is uninitialized
[12:14:42 CET] <mateo`> am i correct saying that there is no neon code for aarch64 for the simple idct code in libavcodec ?
[12:15:08 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:29fbce8f8125: doc/filters: mention recently added option
[12:16:38 CET] <mateo`> by "simple idct code" i mean ff_simple_idct_{add,put}
[12:17:33 CET] <mateo`> I guess I'll work on that for the upcoming days
[12:18:26 CET] <wm4> Polochon_street: yes, that's what I'm thinking about
[12:19:09 CET] <wm4> Polochon_street: I'm not sure if it'll lead to success - there's always the possibility something else fucks it up, but I think the idea is the right thing and worth pursuing
[12:19:26 CET] <atomnuker> mateo`: there isn't much aarch64 simd
[12:19:40 CET] <atomnuker> besides, there are no machines you can run and compile code for that
[12:20:05 CET] <atomnuker> since there are processors but few distributions support them
[12:20:27 CET] <wm4> Polochon_street: the mp3dec.c case is because it expects the id3v2 metadata in AVStream.metadata for various reasons, and there's code to read an id3v1 tag too (which uses the same logic as your code - if AVStream.metadata is not empty, skip it)
[12:20:29 CET] <atomnuker> and the ones which are supported use some ancient modified obscure distro and cost hundreds of bucks
[12:20:55 CET] <wm4> no aarch64 on rpi3 yet?
[12:20:56 CET] <mateo`> atomnuker: i use an rpi3 running arch linux in aarch64 mode for development
[12:21:10 CET] <atomnuker> you can run arch on aarch64 now?
[12:21:15 CET] <mateo`> yes
[12:21:19 CET] <Polochon_street> wm4: alright, that makes sense. I'll investigate today, thanks for the hints :)
[12:21:43 CET] <wbs> there's the $15 pine64 and $40 odroid c2 as well, both readily available
[12:22:12 CET] <wbs> so aarch64 devboard sure are available and pretty cheap these days, and the out-of-the-box distros on them work just fine
[12:22:32 CET] <wm4> I know odroid c2 has a better CPU than rpi3 but a worse video API
[12:23:03 CET] <wbs> wm4: their cpus should be pretty much identical afaik, both are quad a53
[12:23:27 CET] <wm4> "oh"
[12:23:49 CET] <michaelni> atana, the problem is that the avc variable used is not initialized, you define it as "void *avc;"
[12:24:25 CET] <wbs> the rpi3 aarch64 support is a bit icky though since it's mostly based on vanilla-linux which isn't quite as well optimized on rpi hardware as the raspberrypi foundation kernels
[12:24:35 CET] <michaelni> atana, av_log() treats the avc variable as a struct containing an AVClass pointer at its first field
[12:25:12 CET] <michaelni> and tries to access that AVClas pointer (which fails as its not a struct or anything just a uninitialized void pointer)
[12:26:59 CET] <ubitux> atomnuker: arch aarch64 also available on odroid c2, which i use
[12:27:09 CET] <wbs> and as for hardware needing aarch64 asm; all modern iphones in the last 3 years run in 64 bit mode, and most high-end android devices since the last 1-2 years as well
[12:27:10 CET] <michaelni> atana, you can use the AVFilterContext a first argument to av_log() it has a AVClass pointer
[12:28:43 CET] <atomnuker> wbs: yeah, I know about the iphone, but I thought everything else was just crap
[12:28:59 CET] <atomnuker> is there a board which can run a vanilla distribution though?
[12:29:21 CET] <wbs> atomnuker: both yes and no
[12:29:41 CET] <wbs> atomnuker: due to the differences in arm socs, you very very seldom can take a "stock vanilla" kernel and bootloader and expect it to work on anything
[12:30:04 CET] <wbs> booting is really almost device specific in all cases, so you at least want a device-specifically packaged distro
[12:30:35 CET] <wbs> but within that, you can in most cases run a vanilla distro. on rpi you can use plain debian or ubuntu if you want to
[12:30:44 CET] <rcombs> not on IBM® PC"-compatible devices!
[12:30:49 CET] <atomnuker> damn, so after a few years the distribution you're using dies out you just have to look for something new?
[12:31:06 CET] <atomnuker> I had that happen to me 3 fucking times with the rpi when it came out
[12:31:31 CET] <wbs> which distros died out?
[12:32:01 CET] <atomnuker> there was a very nice cut down yet featured enough server distribution, I forgot its name
[12:32:09 CET] <wbs> ah right
[12:32:28 CET] <atomnuker> and it was up to date compared to rasbian
[12:32:36 CET] <JEEB> yeah, ARM-specific ones tend to die easily
[12:32:42 CET] <atomnuker> which fucking sucks because rasbian is staler than 3 year old bread
[12:32:53 CET] <JEEB> I hear fedora should nowadays have rpi3 64bit thing?
[12:32:56 CET] <JEEB> officially
[12:33:07 CET] <atomnuker> heh, there was also the pidora
[12:33:23 CET] <wbs> I'm a bit curious about that, since last I saw all rpi3 64 bit kernels were based on one guys hacks from april last year, which hasn't seen any work since
[12:33:39 CET] <JEEB> I think rpi3 64bit stuff got in around 4.9 or so?
[12:33:47 CET] <JEEB> and fedora is now officially on 4.9.* with fc25
[12:33:51 CET] <wbs> oh, nice then
[12:34:02 CET] <JEEB> so in theory the pieces are in there
[12:34:03 CET] <ubitux> not much is working on aarch64 with rpi3
[12:34:13 CET] <ubitux> it's good enough for ffmpeg development though
[12:34:32 CET] <wbs> in any case, the rpi works much better with a raspberrypi foundation kernel (which is 32 bit only) than with the upstream-vanilla-kernels
[12:34:44 CET] <ubitux> and odroid c2 seems to still lack proper mainline support too afaict
[12:34:51 CET] <JEEB> yea
[12:35:03 CET] <wbs> probably yeah. so if vanilla kernel is a must, then rpi probably is at least somewhat working
[12:35:54 CET] <JEEB> also suse seems to have their enterprise distro running aarch64 on rpi3
[12:36:21 CET] <JEEB> I've been looking at the stuff recently because I want to get my rpi3 out of the box again after moving :)
[12:37:31 CET] <atomnuker> I'm looking for something aarch64 with a usb-3 port and gigabit ethernet, is there a monster like that out which won't break the bank?
[12:38:31 CET] <mateo`> isn't the odroid c2 what's your looking for ?
[12:38:43 CET] <mateo`> oh usb-3 port, nvm ...
[12:39:51 CET] <atomnuker> the pine64 (even though it doesn't have a usb-3 port) looked nice but then I saw allwinner
[12:39:58 CET] <atomnuker> I'm staying well away from allwinner
[12:40:40 CET] <atomnuker> the odroids are imo highly overpriced and if you buy them from an official distributor here they become grossly overpriced
[12:41:48 CET] <ubitux> the arm world is very much tied to the mobile world
[12:41:55 CET] <ubitux> it means everything is shit
[12:42:07 CET] <ubitux> and you'll have to deal with bad treadoff
[12:42:33 CET] <wm4> yeah
[12:42:55 CET] <wm4> and usually multimedia things will only work with android, if at all
[12:43:07 CET] <ubitux> currently my arch odroid is running 3.14
[12:43:19 CET] <ubitux> and the rpi3 is running a broken mainline one
[12:43:47 CET] <ubitux> the rest of my arm boards are various armv7 crap in various flavour
[12:44:43 CET] <mateo`> ubitux: doesn't your beagle bone board run arch with a mainline kernel ?
[12:45:08 CET] <ubitux> yes but not aarch64
[12:45:17 CET] <mateo`> indeed
[12:45:37 CET] <wbs> yeah, TI stuff had surprisingly good things merged upstream, while they still cared
[12:46:16 CET] <ubitux> the cubieboard garbage board is also mainline
[12:46:53 CET] <ubitux> (allwinner)
[12:47:41 CET] <Polochon_street> michaelni: hi, could I please have the mp3_demuxer_EOI.mp3 file you used on the duplicate ID3 to show the regression so that I can test if I fixed it?
[12:49:00 CET] <wm4> hm would have thought it's part of FATE, but apparently not
[12:50:01 CET] <atomnuker> meh, I'll just get an odroid c2
[12:52:55 CET] <michaelni> Polochon_street, see http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4003/
[12:53:06 CET] <ubitux> atomnuker: hope you're fine with running 3.14
[12:53:12 CET] <Polochon_street> thank you!
[12:53:23 CET] <michaelni> also if someone can make it a bit shorter ad still reproduce all issues i can upload it to fate
[12:53:32 CET] <atomnuker> ubitux: even on arch?
[12:53:35 CET] <ubitux> yes
[12:53:51 CET] <atomnuker> ugh, maybe not
[12:53:55 CET] <ubitux> :)
[12:54:15 CET] <ubitux> the alternative is rpi3 which is a non working mainline kernel
[12:54:18 CET] <ubitux> pick your poison
[12:54:24 CET] <atomnuker> how non-working is it?
[12:54:37 CET] <ubitux> barely manage to work without video display
[12:54:49 CET] <wbs> apparently, according to JEEB, it's pretty ok-ish around 4.9 or so
[12:54:56 CET] <atomnuker> hm, that's not too bad
[12:55:03 CET] <wbs> to the point that fedora ships something based on it
[12:55:06 CET] <ubitux> my dmesg is flooded with "i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100" currently
[12:57:40 CET] <ubitux> wbs: pretty sure you can't use it for desktop though
[12:57:49 CET] <ubitux> not sure you can even manage to have a display
[12:58:28 CET] <JEEB> I just overheard the fedora statement, and I have no idea how many patches they have on top for aarch64
[12:58:32 CET] <atomnuker> huh, apparently the c2 also is almost supported by the kernel's git master
[12:58:44 CET] <wbs> ubitux: ok
[12:59:06 CET] <ubitux> https://news.opensuse.org/2016/12/05/opensuse-leap-42-2-gets-64-bit-raspberry-image/
[12:59:08 CET] <ubitux> this is the news
[12:59:09 CET] <JEEB> seems like officially they'll be supporting aarch64 with fc26
[12:59:23 CET] <JEEB> ubitux: yeah - I mentioned suse already doing the aarch64 game
[12:59:25 CET] <ubitux> > which means that some not-yet-supported upstream features like HDMI-audio and hardware-accelerated-video decoding are not available yet in the image.
[12:59:42 CET] <ubitux> basically it's useless for a lot of things and it's likely to last
[13:00:00 CET] <ubitux> because no official support as the company behind is worse than satan and comcast together
[13:00:21 CET] <JEEB> le broadcom face
[13:00:23 CET] <ubitux> i still have some hope for c2 mainline though
[13:00:44 CET] <ubitux> but i'm pretty sure rpi3 is a lost cause overall
[13:01:05 CET] <ubitux> atomnuker: any idea what's missing btw?
[13:01:43 CET] <ubitux> i remember some stuff going in around 4.4 but that's all
[13:03:08 CET] <ubitux> atomnuker: did you also check the pine64?
[13:03:25 CET] <ubitux> i remember looking at that one a while ago, don't remember the outcome
[13:04:12 CET] <ubitux> allwinner though
[13:08:10 CET] <wm4> <ubitux> because no official support as the company behind is worse than satan and comcast together <- which one?
[13:08:18 CET] <ubitux> broadcom
[13:08:37 CET] <wm4> well RPI support and APIs are relatively good
[13:08:40 CET] <wm4> for ARM/Linux garbage
[13:08:59 CET] <ubitux> 32-bit only
[13:09:07 CET] <atomnuker> ubitux: the pine64 is allwinner and I dislike allwinner worse than broadcom
[13:09:29 CET] <wm4> most people are more interested in being able to do anything with the device (other than compiling stuff)
[13:09:59 CET] <ubitux> 32-bit proprietary userland they don't want to port to 64-bit
[13:10:27 CET] <ubitux> really love how rpi was sold as a soc with a "64-bit cpu"
[13:12:54 CET] <JEEB> yup
[13:16:41 CET] <atomnuker> ubitux: ordered a c2, I like to be optimistic (besides for now it'll do the job of exposing my external hdd to the network)
[13:18:08 CET] <ubitux> don't forget to set nographic to 0
[13:18:16 CET] <ubitux> to 1* sorry
[13:18:23 CET] <ubitux> or you'll get random kernel traces
[13:18:25 CET] <ubitux> ;)
[13:18:31 CET] <ubitux> (arm always a lot of fun)
[13:21:03 CET] <phh> for people interested in ARM boards, I recommend rockchip's SoCs. they are mostly mainlined, the VPU code is open-source (though only "real" API supported is gstreamer at the moment), the only binary blob needed is for the GPU, but it's mali, so ARM is maintaining it
[13:24:31 CET] <Polochon_street> wm4: alright, after diving a bit inside the files, I understand that the problem was, as you said, « with the patch, idv3 metadata are not written in the s->metadata field, causing ff_id3v1 read to be triggered, filling s->metadata and preventing the later copy of the id3v2 tags », right?
[13:25:11 CET] <wm4> Polochon_street: yes
[13:37:30 CET] <Polochon_street> wm4: what you had in mind was to create an id3v2-dedicated stream in utils.c, and then checking it in mp3_read_header to skip (or not) the id3v1 read?
[13:38:43 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:836c8750b313: avfilter/avf_showspectrum: fix 2 possible crashes
[13:44:03 CET] <durandal_1707> michaelni: how i can avoid stupid hook that disallows commiting text files with trailing whitespaces?
[13:44:48 CET] <wm4> Polochon_street: I meant adding an internal AVDictionary field somewhere, which contains the id3v2 contents
[13:46:36 CET] <Polochon_street> inside of the s AVFormatContext you mean? We could also check if the format name is "mp3" and then do a direct ff_id3v2_read(), but that's *really* dirty
[13:47:01 CET] <michaelni> durandal_1707, i think merges are exempt from it, also some file types possibly are
[13:48:01 CET] <michaelni> the hook is on the videolan server 
[13:48:28 CET] <durandal_1707> just remove the hook
[13:49:11 CET] <wm4> Polochon_street: yeah, I think we shouldn't do such format checks
[13:49:20 CET] <Polochon_street> definitely
[13:49:27 CET] <wm4> Polochon_street: yes in AVFormatContext, or the internal associated struct
[13:49:53 CET] <michaelni> durandal_1707, if you need changes to the hook(s) talk with jb or thresh
[13:50:19 CET] <wm4> Polochon_street: AVFormatInternal, accessible via AVFormatContext.internal
[13:50:51 CET] <Polochon_street> okay, thanks for this, I'll try to do something!
[14:16:19 CET] <Polochon_street> wm4: after looking a bit, it seems more logical to do a flag like id3v2_had somewhere, and to check it in mp3_read_header before ff_id3v1_read(), isn't it? I've looked for a place in AVFormatContext to put this flag, but I can't find anywhere suitable, even in AVFormatInternal :/
[14:16:49 CET] <wm4> Polochon_street: that won't work, mp3dec.c also reads/writes from the id3v2 tags in other places
[14:20:38 CET] <Polochon_street> ok, so that would be more like « storing id3v2 AVDictionary somewhere, check for it at the beginning of the mp3_read_header, and copy it if it exists to avoid further problems »?
[14:20:49 CET] <wm4> yeah
[14:21:33 CET] <Polochon_street> right, well I've checked for some places to put it in AVFormatInternal, but it doesn't seem to have any suitable fields (same for AVFormatContext)
[14:22:58 CET] <wm4> what are you looking for?
[14:23:47 CET] <Polochon_street> some AVDictionary ** field, or some void * place that can handle this kind of "temporary" data
[14:23:53 CET] <wm4> add one
[14:23:56 CET] <Polochon_street> but maybe I should add this field?
[14:24:03 CET] <wm4> yes
[14:24:26 CET] <Polochon_street> oh, okay. Sorry, I'm used to the user side of ffmpeg, so adding fields to AVFormatInternal is not something I'm used to :p
[15:41:28 CET] <Polochon_street> is there a special place to initialize some variables in AVFormatContext.internal ?
[15:43:20 CET] <wm4> Polochon_street: probably in some open call
[15:44:43 CET] <wm4> actually avformat_alloc_context
[15:44:49 CET] <wm4> which is strangely in options.c
[15:50:28 CET] <Polochon_street> wm4: thank you, I've made this patch http://sprunge.us/JBBC. Roughly, it sets the internal id3v2 dict to NULL and uses this to skip the « if (!s->metadata) ; else ... » conditionnal statement
[15:50:53 CET] <Polochon_street> well the first one is the patch I submitted first, which I corrected in the second
[15:51:51 CET] <Polochon_street> tell me when you have time if it could be sent to the ML, or if there is like some huge flaw I am not seeing :p
[15:52:07 CET] <wm4> did you run fate?
[15:52:44 CET] <Polochon_street> ah. Didn't know about it, I'll run that first.
[15:54:14 CET] <wm4> there's a stray 1 line removal in the patch (or at least it looks like one)
[15:54:21 CET] <wm4> an empty linr
[15:54:24 CET] <wm4> *line
[15:56:18 CET] <wm4> also it adss { } around ff_id3v1_read(s); for no reason
[15:59:01 CET] <Polochon_street> true
[16:20:20 CET] <Polochon_street> Okay, I've run make fate-rsync/make fate, but I can't seem to find where are the results, the readme only mentions how to send them to the server...
[16:21:41 CET] <wm4> Polochon_street: if you did "make fate" and it found the samples, then everything is ok if it didn't stop make with an error
[16:22:04 CET] <wm4> AFAIK "make fate" without samples will run tests that don't need samples, which isn't enough
[16:22:19 CET] <wm4> but if fate-rsync worked you probably did that correctly
[16:22:37 CET] <Polochon_street> ok, perfect. It tested the samples downloaded from fate-rsync, yep, so, perfect.
[16:22:53 CET] <Polochon_street> I'll make one single patch and try to test it again before submitting to the ML
[17:09:20 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:d1df72a7025b: fate: add SCC test
[17:14:53 CET] <ubitux> durandal_170: thanks!
[17:15:24 CET] <ubitux> she is a witch!
[17:42:59 CET] <wm4> Polochon_street: sorry, found some more things to comment on, I hope that's not annoying
[17:45:46 CET] <Polochon_street> wm4: no problem, I'll leave now but will reply tomorrow!
[18:01:39 CET] <Franciman> Hi
[19:15:03 CET] <basisbit> hey, just wanted to come by to say: screw you! stop messing around with API within version numbers. and don't chnage api names if there is no need for it. dealing with ffmpeg api is such a pain for so many developers out there.
[19:15:37 CET] <kierank> LOL
[19:22:42 CET] <JEEB> totally not surprised
[19:22:58 CET] <JEEB> both Libav and FFmpeg have derp'd without API version bumps :)
[19:29:12 CET] <BtbN> well, if there is an actual API break, it's usually fixed
[19:29:20 CET] <BtbN> Most people who complain are using non-public API
[19:29:46 CET] <JEEB> or people who just don't want to update API usage
[19:30:30 CET] <JEEB> of course that doesn't mean that some of the requests for better update documentation aren't correct
[19:35:25 CET] <durandal_170> netbsd  sub-scc failure is strange. it eats ' character
[19:58:22 CET] <BBB> durandal_170: possible that the shell eats it during the test instead of actual breakage?
[20:00:31 CET] <durandal_170> BBB: do you know how generic FIR filter should be implemented when given coefficients?
[20:00:51 CET] <BBB> dont we have generic code for that in celp/acelp decoders?
[20:01:24 CET] <durandal_170> BBB: with fft?
[20:01:42 CET] <BBB> I dont know TBH ;)
[20:03:05 CET] <BBB> check ff_acelp_interpolatef in acelp_filters.h
[20:03:22 CET] <BBB> theres MIPS DSP also \o/
[20:14:21 CET] <wm4> yeah, keeping up with ffmpeg API is very annoying
[20:14:50 CET] <wm4> I know, because until recently I was compatible down with ffmpeg 2.4 and Libav 11 or so
[20:15:13 CET] <wm4> doesn't change the fact that the API needs to change
[20:16:25 CET] <JEEB> yup
[21:43:39 CET] <Compn> i think the more interesting complaint is
[21:44:02 CET] <Compn> why not change the api names but then keep the old ones just for backwards compat and let the idiots apps crash ?D
[21:44:07 CET] <Compn> but im crazy sooo
[21:44:42 CET] <BtbN> because they are usually deprecated and throw a warning when used, and are then removed after a good while
[22:13:20 CET] <Compn> specifically talking about the renamed api, not the removed api, but thanks for playing
[22:13:23 CET] Action: Compn runs
[22:22:13 CET] <cone-343> ffmpeg 03Sasi Inguva 07master:e4a1d87ef88d: lavf/matroskaenc.c: Free dyn bufs in mkv_free. Fixes memory leaks when muxing fails.
[22:22:14 CET] <cone-343> ffmpeg 03Sasi Inguva 07master:03e42a4fecae: ffmpeg.c: Add output file index and stream index to vstats file.
[22:22:15 CET] <cone-343> ffmpeg 03Michael Niedermayer 07master:629424773054: avfilter/vf_gblur: Increase supported pixel count from 31bit to 32bit in filter_postscale()
[00:00:00 CET] --- Sat Jan 28 2017