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

Sun Mar 19 03:05:02 EET 2017

[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