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

[burek]

[00:35:59 CET] <DHE> I'd like to propose a 1-line change. ffmpeg_filter.c function init_complex_filtergraph: add graph->nb_threads = 1;  // near the top
[00:38:09 CET] <thardin> your proposal is under consideration
[00:47:47 CET] <thardin> (actually send a patch to the mailing list)
[00:48:46 CET] <nevcairiel> make sure to include reasoning =p
[01:28:14 CET] <DHE> git and I have a hate-hate relationship when it comes to email... wish I could make a github pull request instead.
[01:52:16 CET] <jamrial> just attach your patch to an email using your client
[02:26:21 CET] <DHE> jamrial: thanks, I sent it....
[02:27:02 CET] <DHE> for some reason I assumed attachments were not allowed
[02:28:30 CET] <jamrial> they are discouraged, but not rejected
[02:28:46 CET] <cbsrobot> I guess "git send-email" is preferred, but a attachment is better than a mangled patch 
[02:35:25 CET] <jamrial> git format-patch style patches are a must. diffs are not accepted
[02:36:25 CET] <jamrial> git send-email is indeed preferred since they are easier to apply for most devs, but as i said attached patches while discouraged are not going to be rejected
[02:46:03 CET] <jamrial> BBB: i really don't see why is it so important for a debug level message to be removed...
[02:46:30 CET] <BBB> its not one, its thousands
[02:47:12 CET] <BBB> theres too many useless, empty, pointless, poorly written debug messages that shouldnt be there and are not useful. they should not be in release builds, and I personally dont think they should be in the source code
[02:47:41 CET] <BBB> it litters the code and occludes the actual relevant code
[02:50:20 CET] <jamrial> if they are useful for debugging by the module's maintainer i don't think they are an issue
[02:50:37 CET] <jamrial> also, this is snow. i could understand if we were talking about h264/hevc/vp9
[02:55:21 CET] <beastd> BBB: your argumentation sounds a bit subjective or mood dependant. i cannot see what is so bad with this message in particular; especially under cirsumstances jamrial just stated (maintainer of that code wants to have the message).
[02:56:04 CET] <BBB> Ive made an argument a while ago about it
[02:56:05 CET] <beastd> BBB: I believe you have a point somehow. But to make it, it would be better to generate stat on the number of debug messages and there distribution. And then attack the problem on a grander scale and think about improvements and solutions
[02:56:17 CET] <BBB> I did that a while ago
[02:56:25 CET] <BBB> michael just doesnt like my point
[02:56:27 CET] <BBB> which is fine
[02:56:31 CET] <BBB> we dont always have to agree
[02:57:06 CET] <BBB> and I think to a certain extend Id like to invert the argument - to have some useful debug messages that help debug questionable files in h264 can be extremely helpful
[02:57:12 CET] <BBB> particularly when the sps or pps are slightly off
[02:57:15 CET] <BBB> that actually happens
[02:57:19 CET] <BBB> theres real files where that happened
[02:57:28 CET] <BBB> but for snow, thats just not realistic
[02:58:13 CET] <BBB> so to spend all that source code, all that binary size, or even our brainpower on discussions - for debug in snow in case some third-party encoder writes out of range values that come from fuzzing? & I just find that unrealistic
[02:58:33 CET] <BBB> I categorize that broadly as fuzz-only conditions
[02:58:38 CET] <BBB> and you dont need debug messages for that
[02:59:25 CET] <BBB> (imo)
[02:59:50 CET] <beastd> BBB: Thanks for explaining. Well than we need to compare snow to other decoders and put it in proportion
[02:59:52 CET] <BBB> but look, I just wrote 10 lines of IRC chat about this, such a waste of brain :( I couldve contributed these 10 lines on making av1 better
[03:00:09 CET] <beastd> BBB: sorry if you see it that way
[03:00:21 CET] <BBB> maybe Im being over-dramatic
[03:00:31 CET] <BBB> my point is, lets not make a bigger deal out of this than it is
[03:00:53 CET] <BBB> I think broadly speaking michael likes having a lot of debug or developer-mode code in ffmpeg
[03:00:56 CET] <beastd> I just wanted to say. I don't like the this-is-snow argumentation. Seems to narrow to me and not very useful
[03:01:12 CET] <BBB> and Im probably more broadly in favour of getting some of that old cruft out
[03:01:21 CET] <BBB> so in a way were just having a slightly different project vision
[03:01:38 CET] <BBB> in that particular way I may be a little more in the direction where libav has gone
[03:01:51 CET] <jamrial> BBB: i remember i suggested to use ff_dlog once based on that
[03:02:04 CET] <BBB> yeah, ff_dlog would be better than av_log
[03:02:06 CET] <jamrial> but i can't recall if i or someone else argued it wasn't a good solution
[03:02:37 CET] <BBB> I think its better than av_log, although it still occludes the source, but then again its snow so how often will anyone realistically look at that source, maybe its ok
[03:03:12 CET] <BBB> but beastd is right that that agument is narrow and may not work - what if the next patch is for a fuzz-only patch in a codec more people look at? e.g. ffv1? or vp8?
[03:03:23 CET] <BBB> well, nobody looks at vp8
[03:03:26 CET] <BBB> but lets say av1
[03:03:33 CET] <beastd> I personally like having those debug messages in the code, because I have done lots of remote support and bug searching in my career.
[03:03:36 CET] <BBB> (imagine that a native decoder existed)
[03:04:24 CET] <jamrial> for such modules, the maintainer could easily say "no, don't pollute my code"
[03:04:28 CET] <jamrial> and that'd be it
[03:04:56 CET] <BBB> that suggests that each module has a maintainer who is the overlord and final emperor of that piece of code
[03:05:16 CET] <BBB> Ive always assumed we were more collaborative and grouped in our decision making process
[03:05:26 CET] <beastd> we are
[03:05:28 CET] <jamrial> most important modules do, afaik
[03:05:39 CET] <jamrial> which are the modules people actuallly look at
[03:05:48 CET] <beastd> it is for conflict where we sometimes need hard maintainer decisions
[03:06:19 CET] <jamrial> yeah
[03:06:54 CET] <beastd> also think about how linus does it with the linux kernel -- he doesn't comment on every bit, but for some things he will make harsh decisions
[03:07:11 CET] <beastd> there is no one way and nothing is black and white
[03:08:05 CET] <beastd> BBB, jamrial: I have another idea about the debug log bloat
[03:08:42 CET] <jamrial> beastd: what is it?
[03:09:16 CET] <BBB> (Ill read the backlog in a bit)
[03:09:45 CET] <beastd> What about analyzing what messages there are and try to fold them into a smaller set of messages where the format strings can be re-used. That way we can save space and improve the wording of those messages (remove typos)
[03:11:22 CET] <jamrial> sounds like a lot of work
[03:11:29 CET] <jamrial> also, that kind of generic/standard message is what gets printed based on AVERROR return values
[03:11:38 CET] <beastd> Would be some effort and would maybe be that impressive at the start. though as we add more codecs and more messages it would pay sooner or later.
[03:14:37 CET] <beastd> Dunno. I don't think that's the same. And yes I am not sure it's worth it, though one could restrict the amount of work to where it is easy. There will always messages you do not want to generalize...
[03:14:46 CET] <jamrial> and i don't think we could fold all of them into a small enough set of log messages
[03:15:10 CET] <beastd> jamrial: you may be right. i don't know myself.
[03:26:20 CET] <beastd> I am sorry. Need to leave now. See you!
[03:28:49 CET] <atomnuker> jamrial: when to apply the ffserver removal patches?
[03:31:46 CET] <jamrial> next week at the earliest. the bump was made effective on oct 21
[03:32:45 CET] <jamrial> i'd like to make sure all the potential abi changes were considered/applied before the unstable abi period is declared over, but so far no one but me even bothered cleaning structs and such
[03:34:00 CET] <atomnuker> what's left to clean up apart from that + the avpriv atomics?
[03:36:06 CET] <jamrial> not sure. i cleaned what i could find
[03:36:58 CET] <jamrial> marton balint sent a patch to remove an unused field from avio, but that's it
[11:58:54 CET] <Alaggard> Hi there!
[11:59:02 CET] <Alaggard> I've got an error during the compilation of ffmpeg enabling libmp3lame. It says that I need version >= 3.98.3. I'm using CentOS 6.8 and my lame versions are 3.100. Can someone give me some help? Thanks in advice
[11:59:08 CET] <Alaggard> I've followed the guide to compile and install ffmpeg for centos from the trac site
[12:11:45 CET] <sfan5> check ffbuild/config.log
[12:12:00 CET] <sfan5> do you have the -devel package for libmp3lame installed?
[12:12:24 CET] <Alaggard> yes
[12:12:29 CET] <sfan5> also this is wrong channel for that question i think
[12:16:39 CET] <nevcairiel> i havent tried exactly, but perhaps pkg-config isnt smart enough to figure out that 3.100 > 3.98? :d
[12:17:35 CET] <Alaggard> nevcairiel i downloaded and compiled 3.98.5, 3.99.4 and 3.100, same error on all
[12:18:15 CET] <nevcairiel> then its probably just not finding it
[17:13:53 CET] <BtbN> so far nobody complained about something being broken. Seems like the subshell approach was sensible.
[17:20:57 CET] <JEEB> cool
[17:23:09 CET] <BtbN> https://0patch.blogspot.de/2017/11/did-microsoft-just-manually-patch-their.html when you lost your source code and you're MS
[17:24:49 CET] <BBB> I read that story
[17:24:55 CET] <BBB> so did they really lose the source code?
[17:25:01 CET] <BBB> that would be .. eh .. wow
[17:25:04 CET] <BtbN> who knows
[17:25:13 CET] <BtbN> Or the source code needs some _really_ nasty old toolchain to build
[17:25:21 CET] <BtbN> and the developer decided binary-patching is just easier
[17:27:46 CET] <DHE> binary patching is EASIER?
[18:16:16 CET] <undefined_> having an issue where ffmpeg 3.3 av_read_frame is returning extra bytes in AC3 payloads
[18:16:44 CET] <undefined_> as expected version 3.0 is returning 768 bytes per payload
[18:16:51 CET] <undefined_> but 3.3 is return 782
[18:18:54 CET] <undefined_> maybe a problem in the ac3 parser?
[19:07:44 CET] <LongChair> jkqxz: i just PRed the fix to mpp (again), seems like they wanted me to :)
[19:36:07 CET] <lrusak> LongChair: are you able to use rockchip decoding via ffmpeg via command line tools?
[19:49:38 CET] <cone-401> ffmpeg 03Aman Gupta 07master:80bb81a8f347: avformat/tcp: add option to enable TCP_NODELAY
[20:06:05 CET] <LongChair> Yeah there was a few commands but I need to search for them. Mostly were given by jkqxz :)
[20:10:00 CET] <lrusak> LongChair: ok, just wondering how it works with the drmprime output
[20:10:12 CET] <lrusak> because that's where I don't know what to do with v4l2 stuff
[20:34:18 CET] <cone-401> ffmpeg 03Paul B Mahol 07master:5d7c76566cdd: avfilter: add multiband compand filter
[20:37:13 CET] <atomnuker> why is there so much ML traffic now?
[20:37:39 CET] <atomnuker> it usually does ramp up during the winter
[20:38:12 CET] <cone-401> ffmpeg 03Michael Niedermayer 07master:c3b9bbcc6edf: avcodec/snowdec: Check intra block dc differences.
[20:38:13 CET] <cone-401> ffmpeg 03Michael Niedermayer 07master:4527ec221610: avcodec/snowdec: Check for remaining bitstream in decode_blocks()
[20:40:44 CET] <jkqxz> lrusak:  At the moment, the only thing you can do in the ffmpeg utility is give it to hwdownload to get it back to normal CPU memory.  With the opencl interop, you can use hwmap to import it to opencl as well.
[20:41:47 CET] <jkqxz> atomnuker:  On the subject of OpenCL, "18:26 #ffmpeg-devel: <@atomnuker> submit the patchset again with a patch to remove the old opencl stuff and I'll review and test it".
[20:46:33 CET] <lrusak> jkqxz: ok
[20:46:45 CET] <lrusak> jkqxz: did you ever see my v4l2 drmprime patch?
[20:47:24 CET] <jkqxz> No?  Is that on the ML somewhere?
[20:48:20 CET] <atomnuker> jkqxz: yep, couldn't look at it until the weekend, which happens to have just started
[20:49:07 CET] <lrusak> jkqxz: nope, here it is, http://sprunge.us/XgCT
[20:49:11 CET] <lrusak> it's very invasive
[20:49:25 CET] <lrusak> I just don't know what to do to have the option to output drmprime frames
[20:50:03 CET] <jkqxz> atomnuker:  Yay!  Not really any hurry, unless there are API-removal deadlines you might want to meet.
[20:50:27 CET] <jkqxz> lrusak:  Use the get_format() callback.
[20:51:07 CET] <lrusak> I'll take a look later. Gotta run. Thanks
[20:51:57 CET] <jkqxz> Hmm, right.  That patch is replacing the current stuff rather than adding to it.
[20:53:35 CET] <jkqxz> What set of things have you tested on, out of interest?  I was kindof expecting something based on making V4L2_MEMORY_DMABUF buffers.
[20:54:10 CET] <jkqxz> (Just using EXPBUF there is a lot of pointless mmap()ing which really should be avoided if possible.)
[20:55:58 CET] <jkqxz> Still, if that method works then with get_format() selection it should be fine for some set of devices.
[21:04:31 CET] <atomnuker> jkqxz: the bump happened on the 21st last month so there's still until next week at the earliest
[21:05:11 CET] <atomnuker> I did take a look at the opencl hwcontext and it looked so clean I wasn't able to find anything to complain about
[21:06:14 CET] <atomnuker> except that it was too clean and the prints could have stretched to over 80 chars but wasn't worth mentioning :)
[21:08:54 CET] <cone-401> ffmpeg 03James Zern 07master:3071434f4d72: lavc/libvpxenc: add tune-content option
[22:19:45 CET] <lrusak> jkqxz: I've tested on imx6
[22:20:01 CET] <lrusak> I can test on DB410c also
[23:22:48 CET] <kierank> hmmm why can't i push
[23:24:15 CET] <cone-401> ffmpeg 03Kieran Kunhya 07master:1f28a991effa: libavcodec/h264_sei: Don't log random user data. This prevents terminal junk.
[23:25:39 CET] <JEEB> that seems to have done it
[23:27:22 CET] <jamrial> maybe that could be exported as metadata or something?
[23:27:42 CET] <jamrial> it's imo useful to see when handing files created by x264
[23:29:14 CET] <kierank> you can't guarantee the validity of any of this stuff
[23:30:43 CET] <cone-401> ffmpeg 03Timo Rothenpieler 07master:6fb617077621: hwcontext_d3d11va: add missing stdint.h include
[23:30:52 CET] <rcombs> check if it's ASCII-clean?
[00:00:00 CET] --- Sat Nov 18 2017