[02:22:29 CET] <J_Darnley> Is it a bad thing that while browsing/reseaching wifi routers I say "I hope one day I need that many wired ports (24) and an optican WAN port"? [02:22:43 CET] <J_Darnley> *optical [02:44:27 CET] <TD-Linux> used fiber is cheap enough around here that I've considered using it at home. but the equipment is generally power hungry and has noisy fans [03:19:51 CET] <wm4> I can't believe this side data merge shit is still being perpetuated [04:12:17 CET] <wm4> how do you run fate with threads again? does adding THREADS=4 to the make command (as argument) work? [04:25:19 CET] <jamrial> wm4: yes [04:27:36 CET] <wm4> ok [06:21:40 CET] <Ruyi> Hi, sir [06:22:34 CET] <Ruyi> When I check ֌ [06:24:21 CET] <Ruyi> When I check the GSoC website, I find that now I can't submit my application before March 21 [07:28:02 CET] <wm4> Ruyi: what's your question? [07:50:03 CET] <lei-lhg> Hi,all.I was trying to build ffplay using bitbake. But it always complaint "SDL not found". [07:50:04 CET] <lei-lhg> | DEBUG: Executing shell function do_configure [07:50:06 CET] <lei-lhg> | ERROR: SDL not found [07:50:07 CET] <lei-lhg> In fact,I have run "bitbake -c install libsdl" successfully, I don't know why ffmpeg say "sdl not found" [07:50:09 CET] <lei-lhg> Did anyone have met this problem? [07:50:10 CET] <lei-lhg> any advice and suggestions will be greatly appreciated [07:55:00 CET] <wm4> ask on #ffmpeg, or whatever help channels bitbake provides [07:58:09 CET] <lei-lhg> ok.thanks [08:09:26 CET] <cone-069> ffmpeg 03Muhammad Faiz 07master:c52638cca255: swresample/swresample: do not use s32p internally by default when resampling [08:38:54 CET] <cone-069> ffmpeg 03Rostislav Pehlivanov 07master:3796fb2692f8: lavfi: deprecate AVFilterGraph->resample_lavr_opts [10:54:56 CET] <rcombs> wm4: what do you mean by "limiting it to determine the correct codec ID." [10:55:22 CET] <wm4> having 1 mp3 demuxer, and making it set the correct codec ID in read_header [10:58:07 CET] <rcombs> codec probing doesn't call read_header [10:58:13 CET] <rcombs> it just calls the probe functions [10:58:29 CET] <rcombs> and then if one passes, then the associated codec ID is used [10:58:42 CET] <rcombs> from the list in set_codec_from_probe_data [10:58:43 CET] <wm4> let me guess, this codec probing is actually some horrible hack I don't want to know about [10:59:36 CET] <rcombs> it's mostly for MPEGTS [10:59:47 CET] <rcombs> 'cause some files don't provide any other way to determine what codec a given stream is [11:00:20 CET] <rcombs> apparently it's also used in AVI, MPEGPS, and WAV [11:00:36 CET] <rcombs> and then also in MOV with my patch [11:00:39 CET] <wm4> ok looked how it works [11:00:48 CET] <wm4> it calls the demuxer probe functions on packet data [11:00:51 CET] Action: wm4 goes vomit [11:01:07 CET] <rcombs> it's not _too_ insane since they're all "raw" formats [11:01:14 CET] <JEEB> I think that was the stuff that was added to support MPEG-TS without PMT [11:01:28 CET] <wm4> still an abuse of abstractions [11:01:44 CET] <wm4> it should probably be done by a parser [11:02:52 CET] <rcombs> that'd be nice, and then the probe functions could call into the parsers [11:03:03 CET] <rcombs> for the raw formats [11:03:39 CET] <rcombs> for MOV in particular, we _could_ use the parser for this [11:04:07 CET] <rcombs> like, set need_parsing on the stream when the ID is ambiguous [11:04:21 CET] <rcombs> the MPEG audio parser will change the codec ID in _some_ cases [11:04:21 CET] <wm4> anyway, your patch makes sense considering these things [11:04:25 CET] <rcombs> (the others should be fixed) [11:04:31 CET] <wm4> + (p->buf_size < PROBE_BUF_MAX || layer == 3)) [11:04:35 CET] <wm4> really layer==3? [11:05:02 CET] <rcombs> that was to make sure that heuristic doesn't get applied to other layers [11:05:21 CET] <wm4> why? [11:05:40 CET] <rcombs> 'cause then you'd get AVPROBE_SCORE_EXTENSION - 2 for all 3 [11:05:58 CET] <JEEB> :D [11:10:52 CET] <BtbN> I wonder if it'd be worth adding a CPU usage indicator to the progress and speed line ffmpeg prints. [11:17:55 CET] <wm4> sounds too system specific [11:22:24 CET] <BtbN> Well, Posix and win32 only. Would cover most platforms [11:23:30 CET] <wm4> ah if posix has something for this why not [11:27:10 CET] <BtbN> hm, I remember there being some way to calculate CPU usage from some posix function. But I can't find it [11:34:05 CET] <atomnuker> that would be pointless unless -re is specified, it would only tell you how inefficient the decoder/encoder is with multithreading [11:34:55 CET] <BtbN> I'm more thinking about having an indicator of stuff being slow because the system is under heavy load [11:35:03 CET] <kierank> atomnuker: what does -re actually do [11:35:07 CET] <kierank> afaik it just measures [11:35:34 CET] <kierank> atomnuker: oh i see what you mean [11:35:34 CET] <wm4> isn't that realtime mode [11:36:51 CET] <JEEB> re mostly sleeps according to input timestamps [11:36:53 CET] <JEEB> :3 [12:39:05 CET] <wbs> BtbN: the "times" function ("man 2 times" on linux) should give you the amount of cpu time spent [13:13:09 CET] <BtbN> wbs, yeah, but that's only for the current process [15:28:36 CET] <tdjones> I'm trying to use the AAC pyschoacoustic system within the vorbis encoder for the GSoC qualification task. Should the grouping used by ff_psy_init be obtained from the mapping structs within the vorbis context? I'm struggling to understand how this can be supplied in the vorbis encoder. [15:29:17 CET] <atomnuker> since the vorbis encoder is stereo/mono only just assume stereo [16:14:49 CET] <cone-270> ffmpeg 03James Almer 07master:824d4062a172: compat/atomics/gcc: use __typeof__ instead of typeof [16:20:43 CET] <wm4> jamrial: "typeof" is not C99 [16:20:51 CET] <wm4> that's why it's hidden in C99 mode [16:21:04 CET] <wm4> __typeof__ is a reserved identifier, that's why it can be always available [18:34:37 CET] <tdjones> What are the scalefactor band sizes with ff_psy_init? The vorbis specs state that frames can be powers of two from 64 to 8192, should arrays of factors be provided similar to how aac handles this? [18:36:51 CET] <atana> michaelni, ping [18:40:21 CET] <atomnuker> tjablin: for now use the aac ones (and make sure the encoder uses the same transform size as aac for non-transients which is 1024) [19:23:46 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:ec021d48445a: buffer: fix av_buffer_pool_init2() documentation [19:23:46 CET] <cone-415> ffmpeg 03Clément BSsch 07master:53587ca48280: Merge commit 'ec021d48445a414325ad59a73f9cde3212b173e4' [19:29:43 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:e9bfff1cc66c: lavc: free buffer_frame/pkt on avcodec_open2() failure [19:29:44 CET] <cone-415> ffmpeg 03Clément BSsch 07master:822f1a7913da: Merge commit 'e9bfff1cc66c85b91b262c41e8aa5e8685606225' [19:32:51 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:04763c6f8769: h264_direct: use the reference mask from the actual reference [19:32:52 CET] <cone-415> ffmpeg 03Clément BSsch 07master:39d2b4875741: Merge commit '04763c6f87690b31cfcd0d324cf36a451531dcd0' [19:35:56 CET] <ubitux> BBB: i'm going to continue to noop all the vp9 commits without much thinking [19:36:19 CET] <ubitux> at some point we'll need to make a final diff to spot all the tiny differences they put in [19:36:43 CET] <ubitux> but since the files are split in one repository and not the other, it's a pita to do it at every commit [19:36:48 CET] <ubitux> do you have any objection? [19:42:44 CET] <ubitux> anyway, feel free to look into details [19:42:48 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:bc6e0b64a910: vp9: split last/cur_frame from the reference buffers. [19:42:49 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:5b995452a63e: vp9: allocate 'b', 'block/uvblock' and 'eob/uveob' dynamically. [19:42:50 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:1730a67ab99d: vp9: add frame threading [19:42:51 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:f2143c57b6a6: vp9: reindent after last commit [19:42:52 CET] <cone-415> ffmpeg 03Clément BSsch 07master:9821aa7d3890: Merge commit 'f2143c57b6a61fef382f3128138d8558a9bdecee' [19:44:30 CET] <wm4> (I bet he'd have objections if you _did_ try to merge some of that) [19:45:27 CET] <cone-415> ffmpeg 03Luca Barbato 07master:602abe77b02f: avconv: Check the fifo allocation [19:45:28 CET] <cone-415> ffmpeg 03Clément BSsch 07master:e3b81d2d9bd8: Merge commit '602abe77b02f9702c18c2787d208fcfc9d94b70f' [19:49:29 CET] <ubitux> wm4: yeah [19:49:43 CET] <ubitux> wm4: btw, wrt f6d2fed811dea36c4ebaf991927e44c78eb0aca5; did you already included it in af1761f7b5b1b72197dc40934953b775c2d951cc? [19:52:51 CET] <ubitux> so much noop incoming [19:55:44 CET] <BBB> ubitux: I believe theyre all backports of my work, anton can confirm that [19:56:14 CET] <ubitux> yeah but sometimes backports with var renames, comments adjusts, and stuff like that, you know the story :) [19:56:23 CET] <wm4> ubitux: not sure, but probably not needed [19:56:24 CET] <BBB> ubitux: they realize at this point that forking the decoder and doing their own thing wasnt a great idea, so I think theyll go back to our version (upstream?) and then well work together on doing some work that they want (like splitting in multiple files) [19:56:34 CET] <wm4> ubitux: this part is a bit different in ffmpeg.c anyway [19:56:40 CET] <ubitux> wm4: -filter_complex testsrc works here so i'll skip it; thx [19:56:46 CET] <BBB> ubitux: I dont think their current version should be any different from ours, it should be identical [19:56:47 CET] <wm4> ubitux: I'd say skip it for now, I can verify and post a patch if needed later [19:56:51 CET] <ubitux> wm4: should i reference that commit anyway? [19:56:52 CET] <wm4> and NOPs are good [19:56:54 CET] <BBB> ubitux: but yes you can skip them [19:57:15 CET] <BBB> (I think youre just trying to decrease the backlog, and I 100% support that) [19:57:23 CET] <ubitux> BBB: would you be interested in splitting into files btw? [19:57:30 CET] <BBB> sure [19:57:30 CET] <wm4> ubitux: not sure, but maybe doesn't hurt [19:57:38 CET] <ubitux> wm4: alright, thanks [19:57:41 CET] <BBB> ubitux: I guess the correct answer is I dont care either way" [19:57:45 CET] <ubitux> back to noops [19:57:47 CET] <ubitux> BBB :) [19:57:48 CET] <BBB> ubitux: but if it makes them happy Im fine with it [19:57:57 CET] <ubitux> i doubt they care [19:58:03 CET] <BBB> ubitux: I think they prefer it [19:58:06 CET] <ubitux> but it may ease the merge effort [19:58:08 CET] <BBB> ubitux: vp9.c is pretty big [19:58:16 CET] <BBB> hevc/h264 are split also [19:58:17 CET] <ubitux> i mean they do not care what's in ffmpeg [19:58:30 CET] <BBB> I think in this case they did, because they couldnt backport our work anymore [19:58:43 CET] <BBB> things like 10/12bpc support, 422/444 support, avx2 assembly, etc. [19:58:44 CET] <ubitux> heh, yeah :) [19:58:48 CET] <BBB> thats kinda important [19:58:56 CET] <BBB> a vp9 decoder thats pretty but without simd isnt very useful [19:59:14 CET] <ubitux> if you want to do it, go ahead, i'm back to the noops, the next vp9 commits are much later [19:59:15 CET] <BBB> it also failed to decode valid 8bit content that uses some special features that are starting to become more mainstream [19:59:23 CET] <BBB> enjoy nooping ;) [20:01:04 CET] <cone-415> ffmpeg 03Luca Barbato 07master:f6d2fed811de: avconv: Make sure that inputless filtergraphs are configured [20:01:05 CET] <cone-415> ffmpeg 03Clément BSsch 07master:55dae222a0b3: Merge commit 'f6d2fed811dea36c4ebaf991927e44c78eb0aca5' [20:01:35 CET] <cone-415> ffmpeg 03Sean McGovern 07master:6fc944e6136b: Prepare for 12_alpha1 Release [20:01:36 CET] <cone-415> ffmpeg 03Clément BSsch 07master:bd37ffdbb240: Merge commit '6fc944e6136b050bf965f847bbfd69e1fe572f82' [20:02:33 CET] <cone-415> ffmpeg 03Mark Thompson 07master:121f34d5f0c8: hwcontext_vaapi: Try the first render node as the default DRM device [20:02:34 CET] <cone-415> ffmpeg 03Clément BSsch 07master:77d590cd9c5b: Merge commit '121f34d5f0c8d7d376829a467590fbbe4c228f4f' [20:03:52 CET] <cone-415> ffmpeg 03Mark Thompson 07master:03adfe913062: vaapi_h264: Constify pointers [20:03:53 CET] <cone-415> ffmpeg 03Clément BSsch 07master:54d839e80a06: Merge commit '03adfe913062c6995136eb1ca51152b6d596c0f4' [20:03:59 CET] <wm4> BBB: aw how mean [20:04:19 CET] <wm4> but as a superset-project we're in a good position to spot such things I guess [20:05:45 CET] <cone-415> ffmpeg 03Mark Thompson 07master:ee9061293e92: vaapi_mpeg2: Constify pointers [20:05:46 CET] <cone-415> ffmpeg 03Clément BSsch 07master:a6a6ed54d86b: Merge commit 'ee9061293e925916fe2e0b7c08fbbd1f981b1d29' [20:07:14 CET] <cone-415> ffmpeg 03Mark Thompson 07master:01d6f84f49a5: vaapi_vc1: Constify pointers [20:07:15 CET] <cone-415> ffmpeg 03Clément BSsch 07master:e788c50ce232: Merge commit '01d6f84f49a55fd591aa120960fce2b9dba92d0d' [20:07:50 CET] <cone-415> ffmpeg 03Mark Thompson 07master:5a667322f5cb: vaapi_vc1: Remove redundant version check [20:07:51 CET] <cone-415> ffmpeg 03Clément BSsch 07master:2c400ba7d1ab: Merge commit '5a667322f5cb0e77c15891fc06725c19d8f3314f' [20:08:41 CET] <ubitux> michaelni: any objection to 00a0419c7f7ebce9010cba93b7ff67c9f1165815? [20:08:58 CET] <ubitux> do you wish to replace that ifdefery with a comment above the "smart" code? [20:11:09 CET] <ubitux> this is actually a large serie of dead code drop [20:11:34 CET] <ubitux> http://sprunge.us/DdTB [20:11:45 CET] <ubitux> i'll merge those tomorrow unless you have some objections [20:12:07 CET] <ubitux> please be specific about the ones you wish to keep [20:12:38 CET] <ubitux> (i'm poking you because it affects most of your code, and probably no one else cares about the remaining instances) [20:13:11 CET] <atomnuker> bofh_: ping [20:16:43 CET] <BBB> wm4: can facts be mean? [20:16:51 CET] <wm4> yes [20:20:24 CET] <BBB> wm4: oh :D [20:31:53 CET] <BBB> kierank: whats up with you throwing parties with facebook? [20:32:32 CET] <kierank> BBB: blame Colleen I guess [20:32:40 CET] <BBB> it sounds like youre co-paying ;) [20:33:16 CET] <kierank> Yeah was her idea [20:33:35 CET] <BBB> it was her idea that you pay [20:33:39 CET] <BBB> amazing ideas ;) [20:33:45 CET] <BBB> hey, kierank, I have another great idea [20:33:47 CET] <BBB> ... [20:33:50 CET] <kierank> It was her idea to have a party in vegas [20:33:55 CET] <BBB> :-p [20:33:58 CET] <BBB> Im kidding you [20:34:01 CET] <BBB> so, should I go? [20:34:30 CET] <kierank> Dunno, NAB is super corporate [20:34:43 CET] <kierank> But might be good for you if you have meetings and the likes [20:35:23 CET] <BBB> I hate meetings :-p [22:27:22 CET] <michaelni> ubitux, 00a0419c7f7ebce9010cba93b7ff67c9f1165815 is basically documentation and a reference for the code, i dont see why that should be removd [23:29:54 CET] <ubitux> michaelni: that was my understanding, but while it is an easy dev helper, using an undocumented ifdefery is what makes it easily classified as cruft [23:30:30 CET] <ubitux> btw, it doesn't compile [23:31:01 CET] <ubitux> (and while break often if it can't be compiled [23:31:05 CET] <ubitux> will* [23:31:07 CET] <ubitux> ) [23:32:52 CET] <michaelni> what do you suggest ? [23:34:49 CET] <ubitux> /* (a * b + r) / c */ [23:34:51 CET] <ubitux> ? [23:36:11 CET] <ubitux> i also think it actually belongs as a comment to the doxy of the function [23:36:35 CET] <ubitux> ...but that's already the case [23:52:54 CET] <cone-302> ffmpeg 03Diego Biurrun 07master:00a0419c7f7e: mathematics: Kill non-compiling disabled cruft [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:1e1513d01aa8: lavu/mathematics: document so-called "cruft" [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:ea8efc959449: lavu/mathematics: split closing bracket out of ifdefery [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:3d5c2169e44e: Merge commit '00a0419c7f7ebce9010cba93b7ff67c9f1165815' [23:53:03 CET] <ubitux> michaelni: any other commit in the serie i should not merge? [23:59:23 CET] <michaelni> the code removed from aa37d2bf4505afc106e2a23c44afc722bb204a8e looks cleaner than the remaining code [00:00:00 CET] --- Sun Mar 19 2017