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

[burek]

[00:31:00 CET] <cone-168> ffmpeg 03Michael Niedermayer 07master:9b9e4a71c572: avformat/mpegenc: Check for av_mallocz() failure
[04:59:49 CET] <zpc> Hi! Is there a face detection and tracking filter in ffmpeg? If not , I'd like to add one
[05:01:54 CET] <jamrial> i don't think there's one
[05:02:04 CET] <atomnuker> zpc: what would the filter do? just draw a box?
[05:02:12 CET] <zpc> mask the face
[05:02:41 CET] <zpc> Somebody is just too ugly like me, so I don't want to appear in a live video
[05:04:42 CET] <zpc> http://item.btime.com/live/51igtgb0jcn9qhpo8221d5lf1dg
[05:06:12 CET] <zpc> Our company is developing live news app, and i need a face mask function
[05:13:49 CET] <Shiz> i uh
[05:13:52 CET] <Shiz> dont think there is one
[05:44:00 CET] <rcombs> michaelni: do you know what score you're getting for each demuxer on that MPA file?
[06:43:23 CET] <Compn> get that cat off his keyboard
[09:49:20 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:4cf96c56420b: avcodec/wmaprodec: cleanup extradata dumping
[10:34:04 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:95fb9e020592: avcodec: add pcm_f16le and pcm_f24le decoder
[10:34:05 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:314269118161: avformat/wavdec: add support for decoding 24.0 and 16.8 floating point pcm formats
[10:46:10 CET] <cone-280> ffmpeg 03Nicolas George 07master:ff8b17c998dc: lavfi: take_samples: free frames after taking all samples.
[11:49:20 CET] <cone-280> ffmpeg 03Carl Eugen Hoyos 07master:0098eeaa6289: doc/filters: Fix vsbmc option name.
[12:14:29 CET] <michaelni> rcombs, http://pastebin.com/DuYJRUS5
[12:41:33 CET] <cone-280> ffmpeg 03Michael Niedermayer 07master:da73d95bad47: avutil/random_seed: Improve get_generic_seed() with higher precission clock()
[14:12:57 CET] <BBB_> michaelni: any further comments or things to test on the wmavoice bitstream checking patch?
[14:25:41 CET] <michaelni> BBB, no further comments from me
[15:47:52 CET] <wm4> this so called CoC doesn't do shit
[15:57:40 CET] <BBB> wm4: ?
[15:58:12 CET] <jamrial> wm4: the only one that bothers to invoke it is carl, and he'll never do it against nicolas
[15:59:14 CET] <BBB> ah politics again :(
[16:00:28 CET] <atomnuker> wm4: what were your concerns about the frame queue, I found it quite useful for my opus encoder?
[16:02:00 CET] <wm4> atomnuker: just details, but read the original post?
[16:02:18 CET] <atomnuker> from october?
[16:02:23 CET] <wm4> probably
[16:03:02 CET] <atomnuker> yeah, you just said you didn't know why it would be useful
[16:06:34 CET] <wm4> you mean this mail? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201657.html
[16:06:51 CET] <atomnuker> huh, I misread
[16:07:03 CET] <wm4> anyway, from now on I'll just ignore Nicolas George reviews
[16:07:11 CET] <wm4> he can start an edit war if he wants
[16:08:00 CET] <durandal_1707> I gonna push pixlet without lowres stuff
[16:12:39 CET] <BBB> are the colors fixed?
[16:33:40 CET] <jamrial> i wonder, are people here going to let nicolas willingly ignore reviews and force his patches into the repo?
[16:33:44 CET] <jamrial> last i checked, unaddressed reviews are blockers
[16:36:13 CET] <durandal_1707> I don't see issues with frame queue api if it's O(1)
[16:37:15 CET] <jamrial> i'm not talking about the implementation in question
[16:37:22 CET] <durandal_1707> BBB: output looks pretty good
[16:37:59 CET] <BBB> jamrial: its not just nicolas, Im getting tired of fighting with pitbulls
[16:38:26 CET] <BBB> durandal_1707: cool
[16:38:30 CET] <jamrial> that's the thing, he knows he can get his way if he just outlasts everyone in arguments
[16:38:56 CET] <BBB> indeed
[16:43:18 CET] <wm4> in this case my comments were rather general, so it's easy to argue that they didn't matter or were not specific enough
[16:44:11 CET] <jamrial> but he didn't even bother to do that
[16:45:58 CET] <jamrial> he in fact went and blew any chance of being in the right by saying "i'm going to ignore you"
[16:49:04 CET] <jamrial> he blabbered for months how technical arguments were the only thing that mattered, but now he intends that to only apply when they are his, and everyone else's can be ignored if they are against his code
[16:50:45 CET] <jamrial> there's an alarming lack of involvement from devs regarding netiquette and community behavior here that allows people like nicolas to pull stuff like this
[16:51:50 CET] <wm4> oh you can be sure that if someone else would pull this, but who wouldn't be considered part of the traditional ffmpeg "camp", they'd all cry loudly
[16:53:37 CET] <wm4> I guess having known each other for over a decade matters to a degree
[17:01:38 CET] <BBB> wm4: sadly, it seems so, yes
[17:04:24 CET] <jamrial> wm4: there, he finally addressed your review, sort of
[17:05:46 CET] <jamrial> he more than nothing complained about the fact you raised concerns and how you "handled it", though
[17:06:50 CET] <Compn> if you guys want to troll just review the patch line by line . much more effective way of killing a patch.
[17:07:02 CET] <Compn> than saying 'is this needed' :D
[17:09:09 CET] <Compn> [10:51] <wm4> oh you can be sure that if someone else would pull this, but who wouldn't be considered part of the traditional ffmpeg "camp", they'd all cry loudly
[17:09:13 CET] <Compn> comment goes against the CoC
[17:13:27 CET] <durandal_1707> says who?
[17:19:31 CET] <BBB> Compn: I dont think anyone wants to kill the patch
[17:20:05 CET] <BBB> Compn: were not politicians, were technically competent programmers
[17:21:43 CET] <wm4> jamrial: he responded to 1 sentence
[17:21:58 CET] <wm4> of my original reply to his patch
[17:22:27 CET] <wm4> Compn: plenty of comments go against the CoC, nobody cares
[17:22:33 CET] <wm4> except cehoyos when he can use it as weapon
[17:22:50 CET] <wm4> the CoC is a joke, like the rest of the ffmpeg development community process
[17:22:57 CET] <nevcairiel> the only time its used is when its use goes against the spirit of  such a thing in the first place
[17:24:09 CET] <wm4> what we'd need in this project is some kind of leadership
[17:24:20 CET] <wm4> there's none in sight though (and never was)
[17:27:18 CET] <jamrial> i agree the voting committee is not working as intended. it's too big right now, and full of people not well versed in the issues being raised or fully involved in the project
[17:27:36 CET] <j-b> of course
[17:27:49 CET] <j-b> because committees must be small if you want them to be effective.
[17:27:58 CET] <atomnuker> there's nothing to vote for, so there's no way to demonstrate its effectiveness
[17:28:05 CET] <atomnuker> you people just like to complain for the hell of it
[17:28:35 CET] <j-b> It's not like we have 20 years of knowledge of open source community management...
[17:29:31 CET] <durandal_1707> I'm fully involved in many FFMPEG aspects and I say let Nicolas do what he wants with lavfi up to point it become unusable then I will rewrite it
[17:29:48 CET] <nevcairiel> no amount of community management can fix arrogant people that just play the long time and hope everyone else goes "whatever" after its too much bother
[17:30:16 CET] <wm4> atomnuker: because we know on every vote people we didn't even know they exist will come out of the woodworks and vote against us
[17:30:40 CET] <j-b> nevcairiel: I disagree.
[17:32:06 CET] <jamrial> nevcairiel: a mute, removal of privileges (pushing rights in this case), and ultimately a temp or permanent ban are how you deal with arrogant people when managing a community
[17:32:08 CET] <atomnuker> wm4: and look how it made good decisions every time
[17:32:24 CET] <nevcairiel> jamrial: noone has the balls to do that
[17:32:56 CET] <atomnuker> constructing a committee of people who fully agree defeats the whole point of a committee
[17:32:57 CET] <nevcairiel> because usually afraid to lose manpower, even if its very disruptive
[17:33:03 CET] <jamrial> atomnuker: the ffserver vote should be proof of it not working. people showed up and saw a module being removed, questioned but didn't investigate why would it be removed, and voted against it while ignoring the threads and arguments that lead to the vote in question
[17:33:10 CET] <j-b> jamrial: that's exactly what we did for VideoLAN
[17:33:21 CET] <j-b> and we removed commit access until people understood it.
[17:33:36 CET] <atomnuker> jamrial: I don't mind it and I admit I pushed hard for its removal pointlessly
[17:34:02 CET] <wm4> j-b: lol, who's supposed to do anything of consequence in ffmpeg?
[17:34:08 CET] <atomnuker> however it did give result and now ffserver's back on track
[17:34:14 CET] <wm4> here we hand out commit access like candies
[17:34:18 CET] <jamrial> is it?
[17:34:28 CET] <jamrial> because ever since the vote ended, ffserver hasn't gotten a single commit
[17:34:32 CET] <wm4> lol
[17:34:36 CET] <nevcairiel> we developers are not lawyers or politicians, we don't live to argue about technicalties, so someone who missed his calling in politics will likely always manage to out-argue on sheer stamina alone
[17:34:37 CET] <jamrial> i'd like to say i'm surprised, but i can't
[17:35:07 CET] <BBB> bash-4.4$ grep internal ~/Projects/ffmpeg/ffserver.c
[17:35:08 CET] <BBB> #include "libavformat/avio_internal.h"
[17:35:09 CET] <BBB> #include "libavformat/internal.h"
[17:35:12 CET] <BBB> you mean that ffserver?
[17:35:19 CET] <BBB> /* FIXME: those are internal headers, ffserver _really_ shouldn't use them */
[17:35:24 CET] <BBB> that one, right?
[17:35:25 CET] <jamrial> now, ffserver is still on track to be removed as scheduled on the next major bump, seeing the remaining technical issues haven't been addressed
[17:35:55 CET] <jamrial> i wonder what will happen when that time comes
[17:35:56 CET] <atomnuker> well so it would get removed unless someone starts feeling the fire and spares some time to fix it
[17:36:17 CET] <wm4> also note that this all is with accepting that ffmdec/enc stay
[17:36:17 CET] <BBB> jamrial: it will be filibustered until eternity and pushed to next time, as always
[17:36:32 CET] <BBB> wm4: no, Ive brought up ffm in the relevant thread
[17:36:42 CET] <BBB> wm4: so ffm has to go, including from libavformat
[17:37:05 CET] <nevcairiel> ffm apparently doesnt use deprecated APIs anymore, but doesnt change that its still a rather terribly designed format
[17:37:19 CET] <BBB> ffm is not a multimedia format
[17:37:26 CET] <BBB> theres no reason for gstreamer to support ffm
[17:37:32 CET] <BBB> so it shouldnt live in libavformat
[17:38:03 CET] <wm4> I mean you could argue that ffmdec/enc is ok because as nevcairiel said it doesn't use deprecated API anymore, so it's in the clear in context of the argument that ffserver has to go due to deprecated APIs
[17:38:16 CET] <nevcairiel> i could list a few other formats that qualify for that same criteria, most recently ffprobe demuxer, surprisingly with a key person also involved in it =p
[17:38:19 CET] <wm4> so the argument shrinks to "ffmdec/enc is buttfuck ugly and nonsensical"
[17:38:32 CET] <wm4> which likely won't gather any acceptance from the preservation folks
[17:38:52 CET] <jamrial> ffserver still uses internal api. if it's not fixed by the next major bump, it must go
[17:39:01 CET] Action: BBB luch - brb
[17:39:05 CET] <jamrial> that's what the vote stated
[17:40:02 CET] <wm4> which vote
[17:40:07 CET] <wm4> the original one or the "revised" one
[17:40:18 CET] <jamrial> the only one. there was no "original" one
[17:40:30 CET] <durandal_1707> when merges gonna happen? libav removed some cruft
[17:40:31 CET] <wm4> oh right I keep forgetting that
[17:40:39 CET] <wm4> it was merely a patch that was merged with wide agreement
[17:44:32 CET] <jamrial> originally ffserver was going to be removed and that was it. reynaldo asked for time to fix it and move it to a separate repo (his own personal project, not something we would maintain)
[17:44:56 CET] <jamrial> that request was accepted. after that, that awful thread started and the vote changed ffserver's fate from "fix it and move it somewhere else if you want, but it wont live in our tree any longer"
[17:45:14 CET] <jamrial> to "if and only you can fix it before the next bump, it can stay in our tree. otherwise it's gone"
[17:46:21 CET] <rcombs> michaelni: try this? https://gist.github.com/041a58f6726dd80dd82b8c9d7711b2bd
[17:47:09 CET] <wm4> can't we fix mp3 probing for real
[17:48:06 CET] <rcombs> this case is one where the ID3v2 header is larger than the maximum probe buffer size
[17:49:08 CET] <rcombs> actually, this is probably slightly better: https://gist.github.com/33c688d83d1ad8e5e1dbd677485fdb35
[17:50:21 CET] <wm4> I can't comprehend why the mp3 probe function does all this stuff, instead of just skipping the id3v2
[17:50:50 CET] <wm4> in fact whatever probes should probably skip the id3v2 and feed the data after it to the prober
[17:51:00 CET] <wm4> would be sort of an API behavior change though
[17:53:11 CET] <rcombs> yeah, that would be a good idea
[17:53:17 CET] <jamrial> lol at nicolas reply
[17:53:57 CET] <rcombs> https://gist.github.com/7a5af2095d147f13ccfbe782936bc03b actually this is probably slightly better
[17:54:27 CET] <rcombs> wm4: I guess the concern is around extremely large, or corrupted, ID3v2 tags
[18:02:47 CET] <wm4> which is why skipping it early would be good for probing
[18:27:36 CET] <Chloe> when is the next major bump?
[18:31:46 CET] <Chloe> also wtf @ FFFQ thread, when will this shit end
[18:32:25 CET] <wm4> I think Libav are about to do one
[18:32:48 CET] <wm4> but who knows when this will be merged
[18:32:51 CET] <wm4> merges have stopped
[18:34:54 CET] <wm4> "From my point of view, wm4 no longer exists in this discussion." this guy sure is funny
[18:37:04 CET] <Chloe> Why is no one doing anything about this? Nicolas has been ridiculous in this thread and many previous threads lately.
[18:40:42 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:c5168b4b542b: doc/general: mention recently added PCM codecs
[18:41:19 CET] <wm4> Chloe: lack of leadership
[18:41:23 CET] <Chloe> It's not like we have a 'set way' for repercussions: doesn't this mean it's possible to enact this as-needed and at our discretion?
[18:54:29 CET] <michaelni> rcombs, the VIZ010-01_128.mups file had a mjpeg in it that got displayed which after your patchset + the linked patch is not shown anymore
[18:55:18 CET] <rcombs> &wat
[18:55:27 CET] <rcombs> is the ID3v2 code even crazier than I thought it was
[18:56:29 CET] <wm4> I don't understand how it affects that
[18:56:51 CET] <wm4> probing is run on id3v2 + data after it, but libavformat will always skip the id3v2 in the same way after probing
[19:12:18 CET] <cone-280> ffmpeg 03James Almer 07master:0abcebe3d62d: tests/avstring: free the pointer after calls to av_d2str()
[19:23:28 CET] <cone-280> ffmpeg 03Michael Niedermayer 07master:f9315ea984ef: ffserver_config: Check for failure to allocate FFServerIPAddressACL
[19:32:14 CET] <rcombs> wm4: oh, huh, yeah, that's dumb then
[19:32:57 CET] <rcombs> michaelni: is it still choosing the "mp3" demuxer like it used to, or is it using one of the new ones?
[19:33:44 CET] <wm4> in addition, the id3v2 is read for all formats, AFAIK, but including attached pictures requires cooperation from demuxers (strange shit)
[19:35:46 CET] <rcombs> wat
[19:36:54 CET] <wm4> because there are people who put id3v2 tags on .aac files etc.
[19:37:01 CET] <wm4> and mp4 files etc.
[19:37:12 CET] <wm4> (we had this discussion a longer time ago)
[19:45:32 CET] <rcombs> wait mp4 even
[19:47:31 CET] <wm4>         if (!strcmp(s->iformat->name, "mp3") || !strcmp(s->iformat->name, "aac") ||
[19:47:31 CET] <wm4>             !strcmp(s->iformat->name, "tta")) {
[19:47:31 CET] <wm4>             if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0)
[19:47:31 CET] <wm4>                 goto fail;
[19:47:50 CET] <wm4> this is in utils.c
[19:48:40 CET] <wm4> I think the intention is to prevent attached pictures from adding an attached picture AVStream for demuxers which possibly don't expect it
[19:49:31 CET] <wm4> so yeah, using an id3v2 with a mp4 file works in ffmpeg
[19:54:38 CET] <rcombs> ah
[19:55:27 CET] <rcombs> michaelni: so, yeah, is it picking MP2 or MP1? (would be strange, actually; I intended for that patch to make it pick MP3)
[19:55:40 CET] <rcombs> but based on the code wm4 pasted that would make sense as an explanation
[19:57:11 CET] <wm4> anyway this strcmp orgy should probably be at least an internal format flag, or just move the code to the demuxers
[19:57:53 CET] <Compn> id3 is evil.
[20:08:24 CET] <michaelni> rcombs, "Input #0, mp1 ..."
[20:08:41 CET] <rcombs> wm4: that would be a good plan
[20:09:27 CET] <rcombs> michaelni: is it actually MP1 data, or is my code mistagging it? If you add mp1 to the list in utils.c, does the jpeg show up?
[20:14:09 CET] <michaelni> rcombs, it looks like mp3 data: Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
[20:16:11 CET] <michaelni> rcombs, is .mups a standard file extension ? you add it to +DECLARE_LAYER(1, "mp1,mups,mpa")
[20:16:20 CET] <rcombs> I have no idea
[20:16:29 CET] <rcombs> oh, that's probably why though
[20:16:33 CET] <rcombs> what happens if you get rid of that
[20:19:41 CET] <michaelni> that seems to fix the file
[20:20:14 CET] <rcombs> \o/ OK, lemme tweak some things
[20:21:13 CET] <Compn> durandal_1707 : is your pixlet output binary identical to binary codec ?
[20:21:24 CET] <Compn> if not, should it be marked experimental ?
[20:21:27 CET] <Compn> just aksing...
[20:22:13 CET] <durandal_1707> Compn: i will mark you as experiment in human history
[20:22:31 CET] <Compn> people need to know if they will get accurate decoding 
[20:22:32 CET] <rcombs> https://gist.github.com/788e0485572441e4520e17e5565868ec alright, that ought to fix it
[20:23:12 CET] <Compn> durandal_1707 : honestly, i like incomplete decoders. i am not trying to insult
[20:24:15 CET] <durandal_1707> Compn: output is pretty much identical afaik
[20:24:27 CET] <durandal_1707> visually
[20:31:36 CET] <Compn> k
[20:36:01 CET] <cone-280> ffmpeg 03Pavel Koshevoy 07master:47cd8effea34: fate: Add test for ticket 6024, truncated decoding mode
[20:39:19 CET] <michaelni> rcombs, this looks unintended: '.extensions        = "mp1,m1a,mups",'
[20:40:10 CET] <rcombs> oh, good catch, fixed
[21:53:26 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:fdcb7a85cf2a: avfilter/vf_deband: add planes coupling mode
[22:08:03 CET] <wbs> on the topic of ffserver as I saw discussed before; one technical issue about ffm that I seldom see mentioned, is the fact that it serializes enum values (like codec ids) into the network stream, even though the actual enum values can change at any major bump
[22:08:46 CET] <wbs> so as it currently is designed, ffm can only be parsed by the same major version as it was written with. and the major version is not even written to the stream so you can't know if what you are reading is interpreted right or not
[22:09:47 CET] <wbs> it's of course not a blocking issue like using deprecated apis, but it's still a pretty bad design issue IMO, which at least should be documented and made very clear to any user of it
[22:11:45 CET] <wm4> which is why I suggested replacing ffm with the ffprobe demuxer (and add a muxer)
[22:11:50 CET] Action: wm4 head->table
[22:52:17 CET] <cone-280> ffmpeg 03Paul B Mahol 07master:73651090ca11: avcodec: add Apple Pixlet decoder
[23:43:39 CET] <atomnuker> wait, what's the difference between the framequeue and the bufferqueue?
[23:49:40 CET] <atomnuker> okay, I think I get it, framequeue is something meant to be used by something which allocates frames and puts them in a queue
[23:50:08 CET] <atomnuker> since ff_framequeue_free() will call av_frame_free() on all
[23:50:35 CET] <atomnuker> while the bufferqueue refs and unrefs them (which is what I use)
[00:00:00 CET] --- Fri Dec 23 2016