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

[burek]

[02:16:08 CEST] <cone-668> ffmpeg 03Michael Niedermayer 07master:566d64d4fbb2: avcodec/h264: Only recover from reference pictures
[05:43:07 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:82492c3a9609: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg
[05:43:07 CEST] <cone-336> ffmpeg 03Rodger Combs 07release/2.8:36e5854801a8: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354)
[05:43:07 CEST] <cone-336> ffmpeg 03Rodger Combs 07release/2.8:7aaab3687429: lavf/mov: downgrade sidx errors to non-fatal warnings; fixes trac #5216 (cherry picked from commit 22dbc1caaf13e4bb17c9e0164a5b1ccaf490e428)
[05:43:07 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:69942c4f6dfe: avformat/cache: Fix memleak of tree entries
[05:43:07 CEST] <cone-336> ffmpeg 03Boris Nagels 07release/2.8:48c25d0512e7: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT
[05:43:08 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:bf76124c51fb: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay
[05:43:08 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:d10f4744ff03: avformat/concatdec: set safe mode to enabled instead of auto
[05:43:09 CEST] <cone-336> ffmpeg 03Martin Cracauer 07release/2.8:49fc295612ef: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing
[05:43:09 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:7dac928e6165: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool
[05:43:10 CEST] <cone-336> ffmpeg 03PrzemysBaw Sobala 07release/2.8:4818e074a031: avcodec/imgconvert: Support non-planar colorspaces while padding
[05:43:11 CEST] <cone-336> ffmpeg 03Luca Barbato 07release/2.8:d2e473a245a1: indeo2data: K&R formatting cosmetics
[05:43:12 CEST] <cone-336> ffmpeg 03Luca Barbato 07release/2.8:d77e1c712bf1: indeo2: Fix banding artefacts
[05:43:13 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:e8b1ce8d1b52: avcodec/resample: Remove disabled and faulty code
[05:43:14 CEST] <cone-336> ffmpeg 03Mark Thompson 07release/2.8:5c289c932fe4: lavc/hevc: Allow arbitrary garbage in bytestream as long as at least one NAL unit is found.
[05:43:15 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:d7c15fb25a65: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored
[05:43:16 CEST] <cone-336> ffmpeg 03Ico Doornekamp 07release/2.8:a286f1a5ff5c: avformat/rtpdec_jpeg: fix low contrast image on low quality setting
[05:43:17 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:a35e6ec1bd76: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set
[05:43:18 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:ef54c144250a: avcodec/h264_slice: Check PPS more extensively when its not copied
[05:43:19 CEST] <cone-336> ffmpeg 03Aaron Boxer 07release/2.8:b5d4b1731ead: avcodec/j2kenc: Add attribution to OpenJPEG project:
[05:43:20 CEST] <cone-336> ffmpeg 03Marios Titas 07release/2.8:21fb4d128278: avfilter/src_movie: fix how we check for overflows with seek_point
[05:43:21 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:4e174d95f59d: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case
[05:43:22 CEST] <cone-336> ffmpeg 03Ivan 07release/2.8:70b3e170f97f: avcodec/h264: Fix for H.264 configuration parsing
[05:43:23 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:5127cb2e78c0: avcodec/avpacket: Fix off by 5 error
[05:43:24 CEST] <cone-336> ffmpeg 03Paul B Mahol 07release/2.8:edc61e3abad0: avcodec/apedec: fix decoding of stereo files with one channel full of silence
[05:43:25 CEST] <cone-336> ffmpeg 03Paul B Mahol 07release/2.8:e80a4ce69f0e: avcodec/takdec: add code that got somehow lost in process of REing
[05:43:26 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:c6e3682a0c19: avfilter/vf_drawtext: Check return code of load_glyph()
[05:43:27 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:05b33258e3ac: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3
[05:43:28 CEST] <cone-336> ffmpeg 03Jan Ekström 07release/2.8:3003277103a2: pgssubdec: fix subpicture output colorspace and range
[05:43:29 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:58a750049282: avcodec/ttaenc: Reallocate packet if its too small
[05:45:53 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:66443b0cf3be: update for 2.8.7
[09:11:24 CEST] <cone-961> ffmpeg 03Paul B Mahol 07master:1f62a6e7803e: avcodec/shorten: make max frame size bigger if custom block size was used
[10:06:17 CEST] <Franciman> Hi all
[10:06:29 CEST] <Franciman> Where can I find some examples that use libavfilter?
[10:15:08 CEST] <durandal_1707> mpv
[10:18:40 CEST] <Franciman> do they create their own filters too?
[10:19:19 CEST] <wm4> you can't create your own filters outside of libavfilter
[10:19:26 CEST] <Franciman> oh I see
[10:19:31 CEST] <Franciman> ok thanks a lot for your help
[10:21:56 CEST] <Franciman> Then, if I want to extract samples from an audio stream and process them in order to get the max sample for each 100 samples, is there any filter combination that does that?
[10:30:42 CEST] <DHE> https://ffmpeg.org/ffmpeg-filters.html  there's volumedetect which might be the closest thing you can use as a basis for making your own
[10:35:40 CEST] <Franciman> thanks, again
[11:12:26 CEST] Action: rcombs summons reviews
[11:16:50 CEST] <wm4> for what?
[11:20:32 CEST] <rcombs> mov auto-bsf stuff from a bit ago
[11:30:23 CEST] <wm4> there were some comments, and it doesn't seem like anyone is against those patches
[11:30:53 CEST] <wm4> so I'd just post updated patches and say that you'll apply in 2 days or so if nothing else is pointed out
[11:36:56 CEST] <rcombs> yeah, I'm poking at the comments now
[13:17:25 CEST] <cone-020> ffmpeg 03Umair Khan 07master:a2ba50b03a08: avcodec/alsdec: Fix bitstream reading
[13:41:46 CEST] <BtbN> Is there a simple way to identify how a set of libav* libraries was built? Non-Free/GPL/LGPL
[13:42:33 CEST] <nevcairiel> every library has a fucntion that gets the license string, const char *avcodec_license() etc
[13:43:16 CEST] <BtbN> meh, just opened it in a text editor
[13:43:32 CEST] <BtbN> Searched for enable-nonfree... and found it.
[13:44:13 CEST] <BtbN> "--enable-memalign-hack --enable-gpl --disable-programs --disable-doc --arch=x86_64 --enable-shared --enable-nvenc --enable-libx264 --enable-libopus --enable-libvorbis --disable-debug --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --pkg-config=pkg-config --prefix=/home/packages/win64 --disable-postproc --enable-nonfree"
[13:44:47 CEST] <BtbN> So I see a slight issue there.
[13:57:14 CEST] <Daemon404> BtbN, I like --pkg-config=pkg-config
[13:57:43 CEST] <BtbN> Except for nvenc, this also should be entirely possible to build in lgpl mode?
[13:57:54 CEST] <Daemon404> thats recent isnt it
[13:57:56 CEST] <nevcairiel> i do that when building 64-bit because mingw-w64 doesnt have a prefixed pkg-config Daemon404
[13:58:08 CEST] <Daemon404> oic
[13:58:29 CEST] <Daemon404> also i wish wed just dump memalign havk
[13:58:34 CEST] <Daemon404> or make it harder to enable
[13:58:39 CEST] <BtbN> what even is it?
[13:58:41 CEST] <nevcairiel> let idiots use it, their loss
[13:59:07 CEST] <Daemon404> BtbN,  a nonstandard hack for aligned alloc
[13:59:14 CEST] <Daemon404> technically violates c soec iirc
[13:59:17 CEST] <Daemon404> spec*
[13:59:23 CEST] <JEEB> BtbN: something for old mingw because it didn't have the windows xp sp2/3 memaligned alloc
[13:59:50 CEST] <BtbN> So on mingw w64 it's just a pointless hack?
[14:00:02 CEST] <Daemon404> yep
[14:00:03 CEST] <JEEB> it isn't enabled by default and yes, you don't need it on mingw-w64
[14:00:16 CEST] <JEEB> since mingw-w64 gives access to the proper function on the platform
[14:00:28 CEST] <nevcairiel> you dont even need it on mingw32 anymore these days
[14:00:29 CEST] <Daemon404> though funnily enough the msvcrt src does it this way..
[14:00:39 CEST] <Daemon404> but it is allowrd to technically 
[14:00:47 CEST] <nevcairiel> not to mention that configure turns it on automatically when no native aligned function is found
[14:00:54 CEST] <Daemon404> yep
[14:04:27 CEST] <rcombs> what makes it invalid C?
[14:20:49 CEST] <Daemon404> rcombs, something about a pointer no longer guaranteed being valid if its cast to an int type and back
[14:21:04 CEST] <wm4> right, because it uses long
[14:21:09 CEST] <wm4> will actually fail hard on win64
[14:21:22 CEST] <rcombs> wat
[14:21:34 CEST] <rcombs> why not intptr_t
[14:21:37 CEST] <rcombs> or just void**
[14:21:49 CEST] <wm4> because it's Old Code
[14:22:02 CEST] <Daemon404> and no real life systems i know of even need it
[14:22:04 CEST] <wm4> and it's a shitty ifdef mess so nobody dares to touch it ever
[14:22:51 CEST] <nevcairiel> it could be updated if someone cares
[14:22:54 CEST] <nevcairiel> but why would anyone
[14:23:06 CEST] <nevcairiel> apparently it doesnt explode on win64 though, as magical as that is
[14:23:39 CEST] <wm4> maybe the usual heap addresses are low enough
[14:24:22 CEST] <wbs> the long is only used as an offset
[14:24:33 CEST] <wm4> ooh.
[14:25:12 CEST] <Daemon404> coursmich went on a big rant/explanation why it's invalid once, so, ill just go with that as my reason
[14:25:22 CEST] <wbs> Daemon404: isn't that only about av_freep?
[14:25:34 CEST] <Daemon404> wbs, no there was a separate bit about the memalign hack
[14:25:40 CEST] <wbs> mmkay
[14:25:43 CEST] <Daemon404> but in the end noone cared to fix it
[14:25:48 CEST] <Daemon404> because noone uses it
[14:25:58 CEST] <wbs> (or because the concern is only theoretical?)
[14:26:11 CEST] <nevcairiel> probably
[14:26:17 CEST] <wm4>     diff              = ((~(long)ptr)&(ALIGN - 1)) + 1;
[14:26:19 CEST] <nevcairiel> but someone fixed freep
[14:26:22 CEST] <wm4> it's not just used as offset
[14:26:34 CEST] <wm4> but it affects only the lower bits I guess
[14:27:01 CEST] <Daemon404> wbs, its theoretical on the only system where it was ever used
[14:27:08 CEST] <Daemon404> like i said, msvcrt more or less does it this way
[14:27:16 CEST] <Daemon404> but a libc impl is allowed to
[14:27:29 CEST] <nevcairiel> glibc is probably not all that different
[14:27:40 CEST] <Daemon404> glibc probably has 9 more layers of abstraction
[14:27:55 CEST] <nevcairiel> probably
[14:27:59 CEST] <nevcairiel> but i dont dare to try to find out
[14:28:03 CEST] <nevcairiel> it would melt my brain
[14:28:13 CEST] <Daemon404> and ive actually found msvcrt src pretty readable
[14:28:20 CEST] <Daemon404> especially refactored one
[14:28:28 CEST] <nevcairiel> if there is a programmer hell, the first level is readin gnu code all day
[14:28:34 CEST] <Daemon404> and also a bit simple/naive for some impls
[14:29:24 CEST] <BBB> so
[14:29:30 CEST] <BBB> why did libav just rewrite get_bits?
[14:29:42 CEST] <nevcairiel> noone bothers to ask why anymore
[14:29:59 CEST] <nevcairiel> they probably decided in one of their meetings and didnt bother to talk about it on the ML until its all done =p
[14:30:06 CEST] <Daemon404> thats a good question
[14:30:09 CEST] <BBB> ok
[14:30:10 CEST] <BBB> guys
[14:30:15 CEST] <BBB> I think this is a bad idea to merge
[14:30:25 CEST] <BBB> I think we should more seriously consider stopping merges like this
[14:30:43 CEST] <wm4> merging what
[14:30:45 CEST] <wbs> BBB: before such a knee-jerk reaction, did you actually read the cover letter?
[14:30:52 CEST] <wbs> there's nothing to merge yet, it's just up for discussion
[14:31:09 CEST] <wbs> someone non-libav had a suggestion on a faster bitstream reader implementation, and now someone has tried implementing said idea
[14:31:10 CEST] <nevcairiel> wbs: i did, and i'm still not convinced its a good idea to bother changing half of avcodec =p
[14:31:14 CEST] <BBB> wbs: this is not knee-jerk, my complaint is fair
[14:31:21 CEST] <wbs> and noted that it indeed is faster or equally fast for tested cases
[14:31:24 CEST] <BBB> wbs: would you like me to discuss this on libav-devel?
[14:31:35 CEST] <Daemon404> if it is nontrivially faster there's merit
[14:31:38 CEST] <BBB> I tried before, and I got ignored
[14:31:45 CEST] <BBB> why not just amend the get_bits api?
[14:31:52 CEST] <BBB> I dont understand why everything has to be rewritten from scratch
[14:31:55 CEST] <wbs> _that_ is a good question of course
[14:32:00 CEST] <BBB> Im full of good questions
[14:32:06 CEST] <BBB> Im not some random mplayer jerk
[14:32:14 CEST] <BBB> I have fairly good brains and write pretty good code
[14:32:22 CEST] <BBB> but libav-devel ignores me when I talk on it
[14:32:23 CEST] <wbs> but the gist is "someone had a suggestion on a better implementation, I tried it", that's not something to give quite as much crap as you are giving
[14:32:34 CEST] <Daemon404> these are legitimate questions of course
[14:32:44 CEST] <wbs> exactly how/where to implement it is of course up for discussion
[14:32:53 CEST] <Daemon404> i only think it's a bit suspect to send a giant patchset
[14:32:54 CEST] <nevcairiel> wbs: thats fine, but we have seen the past, and once s omeone started doing things, they generally just force them in at some point
[14:32:58 CEST] <Daemon404> only THEN to discuss it
[14:33:06 CEST] <Daemon404> because "but hey its doen already" mentality
[14:33:12 CEST] <wbs> sure
[14:33:45 CEST] <Daemon404> i will send a thoughtful reply
[14:33:47 CEST] <nevcairiel> but BBB please mention your thoughts on the ML, its not going to change anything in here
[14:33:47 CEST] <Daemon404> i.e. not flames
[14:33:48 CEST] <wbs> BBB: also, when you say "why did libav just do X", I consider myself part of libav, and I have not known of this patchset before I saw it an hour ago, and I don't consider myself part of those who "are rewriting the bitstream reader"
[14:34:01 CEST] <Daemon404> ^
[14:34:09 CEST] <Daemon404> stuff alexa does just generally appears
[14:34:11 CEST] <BBB> nevcairiel: ok
[14:34:19 CEST] <wbs> so it's not the "please stop the merges" because this isn't in git to be merged yet even
[14:34:56 CEST] <Daemon404> urg
[14:34:59 CEST] <Daemon404> the patchste is sponsored?
[14:35:01 CEST] <Daemon404> thats a bit... uh.
[14:35:38 CEST] <nevcairiel> re-inforces the thoughts expressed earlier, doesnt it
[14:36:40 CEST] <nevcairiel> more communication would be nice, but that didnt happen, so all we can do now is discuss the finished thing, not our problem if work is lost due to not talking about it earlier
[14:37:45 CEST] <wbs> well, tbh, in most cases one could consider this a first WIP patchset as well; I see lots of people doing that on both sides
[14:38:00 CEST] <wbs> just get something done so there's something concrete to talk about, instead of talking about unwritten code
[14:38:43 CEST] <nevcairiel> one could present the idea first when it concerns a key component touching most of the codebase
[14:38:54 CEST] <wbs> sure
[14:39:07 CEST] <wbs> you'll find all the reasons you want to diss it, I don't doubt that
[14:39:27 CEST] <wbs> but if the key point, if you look beyond api and other shit, is, someone had an idea on a potentially faster bitstream reader
[14:39:31 CEST] <wm4> all what matters in the end is performance isn't it
[14:39:32 CEST] <wbs> is that a bad thing to try?
[14:39:53 CEST] <wbs> if someone on this side would have tried optimizing get_bits, it would have been all praise I'm sure
[14:40:27 CEST] <nevcairiel> i doubt reaction to such a patchset without any previous discussion would be any different from those talking here right now
[14:41:09 CEST] <BBB> there, I emailed the list
[14:41:45 CEST] <BBB> wbs: do you agree with my technical concern that a new API is not really warranted here, using this new implementation with existing API should be possible?
[14:42:30 CEST] <wbs> BBB: I haven't read it close enough to say for sure, but in general I would guess that it could be fitted into the old API
[14:42:58 CEST] <wbs> (perhaps there are functions that the old bitstream reader could implement efficiently that can't be done as neatly, while other things are faster in the new one, dunno)
[14:43:03 CEST] <wbs> but that part is a valid concern yes
[14:43:32 CEST] <BBB> ok, ty
[14:43:49 CEST] <Daemon404> it is also worth noting i wont stop merges regardless. if theres stuff we dont want, i *skip* those parts.
[14:43:51 CEST] <wbs> but the "someone posted a patch on libav, let's stop merging" is what I find knee-jerk
[14:44:02 CEST] <BBB> fair enough
[14:44:10 CEST] <wbs> also, I gotta go
[14:44:29 CEST] <BBB> on a totally different note, did we ever implement a replacement for AVFrame->dct_coef and AVFrame->mb_type?
[14:44:39 CEST] <BBB> they got removed a couple of months ago at the latest bump and I didnt see replacements
[14:44:47 CEST] <BBB> (someone on stackoverflow asked)
[14:44:53 CEST] <fritsch> i +1 what this derek guy wrote on the ML ... without those being answered ... a rewrite is worth nothing
[14:45:00 CEST] <Daemon404> fritsch, i am derek
[14:45:01 CEST] <Daemon404> thx
[14:45:21 CEST] <nevcairiel> if there is any replacement, its in sidedata, but i'm not sure it ever happened because it seems largely unused BBB
[14:45:37 CEST] <BBB> sidedata had stuff for motion_vectors only, I believe
[14:45:43 CEST] <fritsch> Daemon404: ah okay, sorry :-)
[14:45:45 CEST] <BBB> I didnt find side-data types for mb_type or dct_coef
[14:45:47 CEST] <Daemon404> who uses dct coeff and mb type?
[14:45:47 CEST] <Franciman> Hey I am using the select filter to get scenechanges. I submit frames to the src buffer with av_buffersrc_add_frame, and following an example from ffmpeg I set the frame's pts to best_effort_timestamp. Now when I retrieve the filtered frame, I am interested in its timestamp. Should I get it from best_effort_timestamp, or from FilteredFrame->pts?
[14:45:52 CEST] <Daemon404> is it for some sort of deblocking, BBB?
[14:46:29 CEST] <nevcairiel> also, when was this removed? we still have the qscale stuff which was deprecated around the same time i though
[14:46:41 CEST] <wm4> Franciman: filters use ->pts
[14:47:02 CEST] <wm4> Franciman: for both input and output
[14:47:15 CEST] <BBB> Daemon404: I dont know, its on stackoverflow&
[14:47:50 CEST] <BBB> nevcairiel: qscale became a function in frame.h, and motion_vectors became side-data; mbtype and dct_coef simply disappeared with no replacement, afaics
[14:48:16 CEST] <nevcairiel> what exported that anyway? probably only mpegvideo-derived codecs like usual?
[14:48:20 CEST] <Daemon404> BBB, SO bothers me. They reward people for answering "how to do x", but not "you should do you instead of x, x is bad"
[14:48:23 CEST] <BBB> yes
[14:48:24 CEST] <nevcairiel> (ie. mpeg1-4)
[14:48:42 CEST] <Daemon404> s/do you/do y/
[14:48:55 CEST] <Franciman> wm4, ah I see, and what's the difference between Frame's pts when decoded and best_effort_timestamp?
[14:49:28 CEST] <Daemon404> i dont think best_effort_timestamp ever returns NOPTS, for one thing
[14:49:32 CEST] <Daemon404> (dont quote me)
[14:50:00 CEST] <wm4> Daemon404: it does if there's no timestamp at all
[14:50:14 CEST] <wm4> Franciman: decoders set pkt_pts, pkt_dts, and also best_effort_timestamp
[14:50:33 CEST] <wm4> while filters only access the pts field
[14:50:47 CEST] <Franciman> I see. Last question, is best_effort_timestamp always set?
[14:51:21 CEST] <wm4> if pkt_dts or pkt_pts are set
[14:51:39 CEST] <Daemon404> wm4, ah ok
[14:52:08 CEST] <Franciman> ok, thanks a lot
[15:09:11 CEST] <BBB> so Im thinking about what anton says
[15:09:33 CEST] <Daemon404> i read taht, and i would suggest waiting a little while instead of an immediate reply
[15:09:46 CEST] Action: Daemon404 knows he writes thinsg he regrets if he doesnt let it gestate for a bit
[15:12:10 CEST] <fritsch> Daemon404: https://www.geekme.de/ <- do that ...
[15:12:24 CEST] <fritsch> will cost you some seconds for not regretting anything after directly writing
[15:12:35 CEST] <Daemon404> it just gave me a trophy in german
[15:12:39 CEST] <Daemon404> i dont know whats going on
[15:12:49 CEST] <BBB_> my kids disconnected the modem :/
[15:12:50 CEST] <fritsch> yeah, exactly, just press next
[15:12:58 CEST] <Daemon404> [14:09] <@BBB> so Im thinking about what anton says
[15:12:59 CEST] <Daemon404> [14:09] <@Daemon404> i read taht, and i would suggest waiting a little while instead of an immediate reply
[15:13:02 CEST] <Daemon404> [14:09]  * Daemon404 knows he writes thinsg he regrets if he doesnt let it gestate for a bit
[15:13:05 CEST] <Daemon404> [14:12] < fritsch> Daemon404: https://www.geekme.de/ <- do that ...
[15:13:07 CEST] <Daemon404> [14:12] < fritsch> will cost you some seconds for not regretting anything after directly writing
[15:13:10 CEST] <Daemon404> [14:12] <@Daemon404> it just gave me a trophy in german
[15:13:11 CEST] <BBB_> I said: and I can see his point that the api is kinda random
[15:13:13 CEST] <Daemon404> [14:12] <@Daemon404> i dont know whats going on
[15:13:15 CEST] <Daemon404> ^ BBB
[15:13:22 CEST] <BBB_> and then: so now, am I being a technocratic asshole if I suggest that api renaming and implementation change should probably be done separately to preserve history?
[15:13:27 CEST] <BBB_> I guess that was post modem-disconnect
[15:13:33 CEST] <Daemon404> no thats pretty sane to me
[15:13:52 CEST] <Daemon404> but
[15:14:02 CEST] <Daemon404> i dont know if the internal impl would necessitate different macro flows
[15:14:11 CEST] <Daemon404> i havent gotten that far yet
[15:14:48 CEST] <Daemon404> also you should keep your modem locked up or something
[15:14:58 CEST] <Daemon404> tricksy kids like to poke things
[15:16:38 CEST] <BBB> well, the cable is on the outside, and they simply disconnected the cable
[15:16:46 CEST] <BBB> not quite sure yet how to protect the cable
[15:17:01 CEST] <Daemon404> i dunno
[15:17:08 CEST] <Daemon404> surround it with veggies?
[15:17:11 CEST] <Daemon404> im not good with kids.
[15:18:29 CEST] <Compn> surround it with other modems and other cords
[15:18:48 CEST] <Compn> then it will be like in the scene from indiana jones and the holy grail. the kids will have to choose wisely which cable to disconnect
[15:19:01 CEST] <BBB> theyd probably disconnect all of them
[15:19:08 CEST] <BBB> Ill try the veggies or something alike that
[15:21:15 CEST] <Daemon404> BBB, that doesnt always work
[15:21:26 CEST] <Daemon404> niece/nephew of gf *love* veggies
[15:21:34 CEST] <Daemon404> just the culture of the family...
[15:21:41 CEST] <Daemon404> personally i think it's weird ;)
[15:21:57 CEST] <BBB> depends on the veggies, right?
[15:22:01 CEST] <BBB> mine love corn and carrots
[15:22:08 CEST] <BBB> but cant really be bothered with green leafy stuff
[15:22:14 CEST] <Daemon404> it's all about the greens
[15:22:22 CEST] <Daemon404> and peppers
[15:23:28 CEST] <nevcairiel> peppers are quite nice
[15:23:36 CEST] <Daemon404> as an adult :P
[15:23:46 CEST] <Daemon404> i thought they were bitter as a child
[15:53:12 CEST] <Daemon404> making tea and scones, then some merges...
[15:53:40 CEST] <wm4> so you're a typical british person
[15:54:35 CEST] <Daemon404> i usually drink coffee
[15:54:54 CEST] <Daemon404> i just decided to buy some some fresh scones at clotted cream today because ill be gone from the uk for a few weeks.
[15:54:58 CEST] <Daemon404> also it is delicious.
[15:55:36 CEST] <durandal_1707> doing Nop merges for life?
[16:05:03 CEST] <wm4> if you open a HLS webvtt stream, avformat_find_stream_info() reads the entire stream
[16:05:08 CEST] <wm4> awesome
[16:05:25 CEST] <Daemon404> O.o
[16:34:51 CEST] <Daemon404> commit bot broken?
[16:34:54 CEST] <cone-111> ffmpeg 03Ivan Uskov 07master:b577a54a7c83: qsv: Fix wrong ticks_per_frame for H.264
[16:35:02 CEST] <nevcairiel> just slow
[16:35:05 CEST] <Daemon404> indeed
[17:08:23 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:9b30f8dd8fa5: h264: remove the svq3-specific code
[17:08:24 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:15b0517da986: svq3: make the dsp functions static
[17:08:25 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:c73fb9efb22c: svq3: add all the required dsp contexts into SVQ3Context
[17:08:26 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:c2a4ca944d90: svq3: eliminate write_back_intra_pred_mode() usage
[17:08:27 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:1877712c586d: svq3: move mb_{x,y,xy} to SVQ3Context
[17:08:28 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:d6f01c61edee: Merge commit '9b30f8dd8fa5bef5f16904cb98745b4a58f8f776'
[17:08:29 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:656b071a8f01: Merge commit '15b0517da986b312fc2fcb364a92db328380b15b'
[17:08:30 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:47bb289170aa: Merge commit 'c73fb9efb22c8d66d24de2716f7f9970f234c3c3'
[17:08:31 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:7dca13428541: Merge commit 'c2a4ca944d9029a3c162f8f3ddd317b83a7bd600'
[17:08:32 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:c18535399d25: Merge commit '1877712c586df2261f2806f45388c77592b89d1e'
[17:34:56 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:ecc31f6b0864: h264: move ff_h264_check_intra[4x4]_pred_mode() to h264_parse
[17:34:57 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:a2922b5d614c: Merge commit 'ecc31f6b086453ab9811dce2ae5ceb6a7c19e4ad'
[17:45:06 CEST] <wm4> does anyone have an idea what could make ffmpeg.c set a time_base different from pkt_timebase on a decoder AVCodecContext, and why?
[17:45:50 CEST] <nevcairiel> if you force a specific fps it uses that for the decoder timebase i think
[17:46:24 CEST] <wm4> not forcing any special parameters
[17:46:35 CEST] <nevcairiel> but why do these even need to match, there is no rule for that
[17:46:35 CEST] <wm4> and it's audio
[17:46:56 CEST] <nevcairiel> is one of them just the inverse sample rate?
[17:47:05 CEST] <wm4> yes, time_base is
[17:47:22 CEST] <wm4> oh, utils.c could be setting it, maybe
[17:48:22 CEST] <wm4> yes, that's it
[17:48:24 CEST] <nevcairiel> gcc 6.1 is final now, btw
[17:48:32 CEST] <wm4> this was probably meant for encoding
[17:48:36 CEST] <wm4> 6.0 doesn't exist?
[17:48:45 CEST] <nevcairiel> they dont do x.0 anymore
[17:48:49 CEST] <wm4> lol
[17:48:53 CEST] <nevcairiel> its 6.0 during development, 6.1 is the first release
[17:50:15 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:527bf5f7c689: svq3: move the pred mode variables to SVQ3Context
[17:50:16 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:8eecae77ff6e: svq3: move edge_emu_buffer to the SVQ3Context
[17:50:17 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:89a13998a1b5: svq3: rip out the svq3-relevant parts of pred_motion() out of h264
[17:50:18 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:99dde60391ca: svq3: move {ref,mv}_cache to the SVQ3Context
[17:50:19 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:463de5625bcb: Merge commit '527bf5f7c6890664b0f1dccd42397f4d204659fe'
[17:50:20 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:fed686af2324: Merge commit '8eecae77ff6e2923de57dd883421d24fd53ca61f'
[17:50:21 CEST] <nevcairiel> The C and C++ compilers now emit saner error messages if merge-conflict markers are present in a source file.
[17:50:21 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:c0b51aa2d2c6: Merge commit '89a13998a1b5074411dff5a461dce3837057b0b8'
[17:50:22 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:f09fd96cee97: Merge commit '99dde60391cade40ae026b9e385a5280be6b9882'
[17:50:30 CEST] <Daemon404> nevcairiel, lul
[17:52:18 CEST] <nevcairiel> Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop).
[17:52:24 CEST] <nevcairiel> not breaking any big projects are we
[17:52:38 CEST] <wm4> lol
[17:52:47 CEST] <wm4> and everyone goes using clang
[17:53:11 CEST] <wm4> when can the this pointer be legally null?
[17:54:08 CEST] <nevcairiel> using -msse now automatically enables -mstackrealign on win32 builds, guess my build is broken then since stackrealign doesnt work in avcodec =p
[17:55:22 CEST] <jamrial> oh nice, gcc 6.1
[17:55:41 CEST] Action: jamrial likes to live dangerously and uses gcc 7 trunk
[17:56:02 CEST] <DHE> oh!
[17:57:31 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:549fc7727363: svq3: move mb2br_xy to the SVQ3Context
[17:57:32 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:6f784c158bd5: Merge commit '549fc77273636d0d02175362af5dcd60c79f7633'
[18:04:58 CEST] <Franciman> Hey, when using libavfilter, can I first submit all the frames to the buffersrc
[18:05:14 CEST] <Franciman> and then retrieve all the filtered frames at once, when I'm done submitting frames?
[18:28:47 CEST] <iive> jamrial: hum, i've missed 6.0
[18:29:48 CEST] <jamrial> read what nevcairiel said above
[18:30:24 CEST] <jamrial> gcc changed their numbering scheme. x.0 is development phase. first release is x.1
[18:35:38 CEST] <jamrial> iive: https://gcc.gnu.org/develop.html#num_scheme
[18:36:43 CEST] <iive> oh, so that's how they are trying to avoid the ffmpeg curse
[18:38:24 CEST] <jamrial> guess it worked, then. 4.9.0 was the last version to be released that miscompiled ffmpeg :p
[18:39:06 CEST] <jamrial> it was also the last one to miscompile the latest available version of binutils afaik
[18:40:01 CEST] <iive> i think there was more recent version that had known bug at release time. they had fix for it, but it was late for the release, or something like that
[18:42:41 CEST] <BtbN> gcc 6 breaks _a lot_ of C++ stuff though
[18:42:49 CEST] <BtbN> they came up with the next -fno-strict-aliasing
[19:03:26 CEST] <JEEB> hmm
[19:04:02 CEST] Action: JEEB looks if SPS/PPS parsing stuff is available within libavcodec
[19:06:42 CEST] <wm4> it's quite intermingled with the h264 decoder
[19:07:08 CEST] <JEEB> yeah, I remembered that but hoped it wouldn't be too cobbled together
[19:07:53 CEST] <JEEB> due to the various degrees of failure in the mediacodec back-ends I thought it would probably be a good idea to do a profile check in the mediacodec decoder
[19:08:48 CEST] <JEEB> so that the most obvious stuff can be avoided
[19:25:18 CEST] <cone-111> ffmpeg 03Andreas Weis 07master:fb9187129c3d: avutil/log: added av_log_format_line2 which returns buffer length
[19:25:19 CEST] <cone-111> ffmpeg 03Andreas Weis 07master:333207224fd8: avutil/log: added test case for av_log_format_line2
[20:01:28 CEST] <fritsch> as someone talked about gcc 6 some minutes ago:
[20:01:33 CEST] <fritsch> "Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined."
[20:03:30 CEST] <wm4> lol
[20:04:04 CEST] <JEEB> :D
[20:05:03 CEST] <nevcairiel> i quoted that already =p
[20:05:12 CEST] <fritsch> ah you did - fefe reader I assume :-)
[20:05:21 CEST] <nevcairiel> no, i dont like him
[20:05:24 CEST] <fritsch> hehe
[20:05:36 CEST] <nevcairiel> i read the release notes
[20:05:38 CEST] <jamrial> but you skipped the part about the workaround option :p
[20:05:50 CEST] <nevcairiel> thats boring :)
[20:06:20 CEST] <fritsch> the "this pointer of member functions"
[20:06:30 CEST] <wm4> just breaking major projects, I wonder if they don't want them to use their compiler
[20:08:00 CEST] <fritsch> i currently think of a minimal example where you got a member function of which this ptr is null
[20:09:08 CEST] <Daemon404> wm4, compiler devs get off on spec wanking
[20:09:11 CEST] <wm4> AcmeClass *foo = NULL; foo->moo(); // non-virtual function, this works right???
[20:09:18 CEST] <Daemon404> "well technically it is undefined so... hnnnnnng"
[20:09:21 CEST] <wm4> Daemon404: truth
[20:09:33 CEST] <rcombs> why would you do that
[20:09:51 CEST] <rcombs> (call member functions on NULL pointers)
[20:09:55 CEST] <wm4> rcombs: dunno, maybe they think a method is like a function with an implicit first arg
[20:10:04 CEST] <rcombs> well it is
[20:10:06 CEST] <wm4> I'm also not sure if this is the gcc case
[20:10:09 CEST] <rcombs> that's how it's implemented
[20:10:15 CEST] <wm4> yeah, but not how it's spec'ed
[20:10:18 CEST] <rcombs> but uh don't do that
[20:10:28 CEST] <rcombs> it's UB and always has been
[20:10:40 CEST] <fritsch> i don't think that's what they are saying
[20:11:07 CEST] <fritsch> it's rather something like: int (A::*x)(void) = &A::f;
[20:11:17 CEST] <fritsch> and now you invoke it and A does not exist?
[20:11:20 CEST] <wm4> blargh
[20:11:25 CEST] <Shiz> gross
[20:11:28 CEST] <Shiz> C++
[20:11:33 CEST] <wm4> I hate C++ syntax more than its semantics
[20:11:37 CEST] <fritsch> hehe
[20:11:47 CEST] <Daemon404> i dont hate its syntax
[20:11:52 CEST] <Daemon404> i hate its endless complexity and rules
[20:11:55 CEST] <fritsch> i thought before "ranting" about the gcc guys I wanted to understand what they actually say :-)
[20:11:56 CEST] <Shiz> wm4: i don't think anything can make me hate something more than recursive variadic templates
[20:11:57 CEST] <Daemon404> that no one man can remember
[20:12:06 CEST] <wm4> Daemon404: syntax is a very vivid expression of this apparent design goal
[20:12:23 CEST] <Shiz> like A::*x
[20:12:30 CEST] <fritsch> and then I'd wanted to see a use case in real life, where one could not just make the method static
[20:12:40 CEST] <fritsch> where the "this" ptr is obviously not needed
[20:12:58 CEST] <Shiz> fritsch: but what if you could call it with either and it does some if(this) stuff??????
[20:13:02 CEST] <Shiz> think of the potential use cases maaan
[20:13:03 CEST] <Daemon404> wm4, c++ syntax i can read, eventually
[20:13:10 CEST] <Daemon404> some languages i dont even want to try
[20:13:11 CEST] <Shiz> (i can see some lunatic implementing singletons with this)
[20:13:13 CEST] <Daemon404> (haskell)
[20:13:20 CEST] <Daemon404> (prolog)
[20:13:22 CEST] <fritsch> Shiz: i can think of some globals that might go away on destruction
[20:13:48 CEST] <fritsch> Shiz: and one needs to check if it's still there while you geave your member into some callback method
[20:13:51 CEST] <fritsch> hehe
[20:14:05 CEST] <wm4> wut
[20:14:17 CEST] <fritsch> but I honestly don't know howto code such a thing ... where I really need that :-)
[20:14:37 CEST] <fritsch> nevcairiel: ^^ you got an idea, where "the old behaviour" would be needed?
[20:19:27 CEST] <cone-111> ffmpeg 03Timo Rothenpieler 07master:bc4137d4aa3a: configure: Don't require nonfree for nvenc
[20:26:08 CEST] <rcombs> oh?
[20:26:27 CEST] <rcombs> ah
[20:26:28 CEST] <rcombs> super
[20:40:09 CEST] <RiCON> rcombs: quick question; can chromaprint use ffmpeg and be included in it statically?
[20:40:25 CEST] <rcombs> sorry?
[20:41:05 CEST] <RiCON> compiling chromaprint with avfft statically and be included in ffmpeg with --enable-chromaprint
[20:41:59 CEST] <rcombs> afaik nothing will stop you
[20:54:43 CEST] <wm4> woah new dts stuff
[20:54:45 CEST] <wm4> whatever it is
[21:04:58 CEST] <nevcairiel> DTS Express
[21:05:34 CEST] <nevcairiel> its a totally distinct codec
[21:06:37 CEST] <rcombs> "turns out piling everything on top of an ancient core bitstream format is really inefficient and some users actually care about that"
[21:10:02 CEST] <nevcairiel> its a low bitrate codec for commentary etc
[21:10:21 CEST] <nevcairiel> so not exactly HD
[21:11:03 CEST] <wm4> why did they invent a codec for that
[21:11:39 CEST] <nevcairiel> because DTS had nothing to cover that =p
[21:16:18 CEST] <rcombs> because if people use any of the existing multitude of suitable codecs, then DTS gets no money
[21:16:47 CEST] <rcombs> so they invented something useless in the hopes it'll bring them royalties through the magic of marketing and standards
[21:16:47 CEST] <wm4> and that would be sad
[21:17:16 CEST] <rcombs> with any luck it'll be about as successful as eac3
[21:18:15 CEST] <nevcairiel> eac3 is the alternative to dts express for secondary audio tracks on Blu-rays
[21:18:27 CEST] <nevcairiel> because its also much more flexible with the bitrate than plain ac3
[22:43:06 CEST] <cone-111> ffmpeg 03Timo Rothenpieler 07master:c4312b1cf44b: avcodec/nvenc: Add missing lossless presets to doc string
[23:34:56 CEST] <Angus> hmm, I'm filling a buffer incorrectly
[23:34:58 CEST] <Angus> http://i.imgur.com/N2jbBY4.png
[23:35:14 CEST] <Angus> how does the AVIO buffer store things?
[23:36:04 CEST] <Angus> I seem to be able to change one variable, and instead of the top half being corrupted, it is the bottom half instead
[00:00:00 CEST] --- Thu Apr 28 2016